| 12:06.42 | *** join/#brlcad mafm (~mafm@126.Red-83-42-153.dynamicIP.rima-tde.net) | |
| 15:08.16 | *** join/#brlcad crazy_imp (~mj@a89-182-5-83.net-htp.de) | |
| 18:06.35 | *** join/#brlcad Elrohir (~kvirc@p5B14BA25.dip.t-dialin.net) | |
| 21:18.29 | *** join/#brlcad mafm (~mafm@126.Red-83-42-153.dynamicIP.rima-tde.net) | |
| 22:57.36 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 11:25.28 | *** join/#brlcad mafm (~mafm@91.Red-81-35-69.dynamicIP.rima-tde.net) | |
| 13:28.42 | *** join/#brlcad Elrohir (~kvirc@p5B14A5CF.dip.t-dialin.net) | |
| 14:39.33 | brlcad | what does vtkfreetype add that a) we need and b) is different than just using ftgl or freetype directly |
| 14:47.49 | CIA-48 | BRL-CAD: 03brlcad * r41902 10/brlcad/trunk/src/other/libz/ (zconf.h zlib.h): make sure _LARGEFILE64_SOURCE and _FILE_OFFSET_BITS are defined before testing their values |
| 15:07.41 | *** join/#brlcad crazy_imp (~mj@a89-182-206-37.net-htp.de) | |
| 17:41.44 | *** join/#brlcad mafm_ (~mafm@91.Red-81-35-69.dynamicIP.rima-tde.net) | |
| 21:47.05 | starseeker | brlcad: vtkfreetype is a subset of freetype that can be built with CMake |
| 21:47.46 | starseeker | it does not replace ftgl - I'm hoping it gives us the font file -> ftgl display conversion capability |
| 21:48.03 | starseeker | if freetype is installed we can use it directly, but on Windows that's a no-go |
| 21:48.29 | starseeker | and the current freetype build system doesn't look at all encouraging |
| 21:48.46 | starseeker | hopefully, vtk has already solved the problem |
| 22:27.10 | starseeker | of course, they're using some pretty old versions so I may still have to tackle the freetype build in the end |
| 22:45.58 | *** join/#brlcad mafm_ (~mafm@91.Red-81-35-69.dynamicIP.rima-tde.net) | |
| 22:45.58 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 22:45.58 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 22:55.09 | *** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net) | |
| 22:55.09 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 23:29.20 | *** join/#brlcad mafm_ (~mafm@91.Red-81-35-69.dynamicIP.rima-tde.net) | |
| 23:29.20 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 23:29.20 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 23:42.32 | *** join/#brlcad CIA-43 (~CIA@208.69.182.149) | |
| 23:58.21 | *** join/#brlcad Elrohir (~kvirc@p5B14B63F.dip.t-dialin.net) | |
| 00:50.51 | *** part/#brlcad AR_ (~AR@24.115.208.248) | |
| 04:12.46 | brlcad | starseeker: ah, then 'meh' .. :) |
| 04:13.28 | brlcad | a forked freetype isn't very interesting. |
| 04:13.56 | brlcad | they're big enough and with enough momentum/activity that any fork is pretty much busy work .. making a proper cmake build for the freetype folks would probably be more worthwhile |
| 08:37.35 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:43.58 | *** join/#brlcad mafm_ (~mafm@131.Red-83-37-155.dynamicIP.rima-tde.net) | |
| 10:55.54 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 10:55.54 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:05.17 | DaveLo-AFK | Mernin all! |
| 12:33.55 | *** join/#brlcad _psilva_ (~psilva@static-96-255-52-7.washdc.fios.verizon.net) | |
| 12:38.54 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:53.14 | *** join/#brlcad Ralith (~ralith@216.162.199.202) | |
| 12:53.14 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 12:53.14 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 14:38.49 | *** join/#brlcad mafm (~mafm@131.Red-83-37-155.dynamicIP.rima-tde.net) | |
| 15:08.00 | *** join/#brlcad crazy_imp (~mj@a89-182-195-216.net-htp.de) | |
| 15:43.59 | *** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de) | |
| 15:52.42 | CIA-43 | BRL-CAD: 03erikgreenwald * r41903 10/brlcad/trunk/src/conv/dem-g.c: remove duplicate declaration of buf3 |
| 18:40.45 | CIA-43 | BRL-CAD: 03erikgreenwald * r41904 10/brlcad/branches/bottie/src/librt/primitives/bot/btg.c: remote hitsort (should already be sorted from tie). test for maxhits earlier. |
| 18:43.16 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:18.29 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.128.58) | |
| 19:27.32 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:25.28 | *** join/#brlcad Ralith (~ralith@216.162.199.202) | |
| 21:29.09 | *** join/#brlcad mafm (~mafm@185.Red-88-15-71.dynamicIP.rima-tde.net) | |
| 22:01.37 | *** join/#brlcad cosurgi (~cosurgi@atak.bl.pg.gda.pl) | |
| 22:37.09 | *** join/#brlcad Ralith (~ralith@216.162.199.202) | |
| 22:41.59 | *** join/#brlcad crazy_imp (~mj@a89-182-195-216.net-htp.de) | |
| 23:41.58 | CIA-43 | BRL-CAD: 03starseeker * r41905 10/brlcad/branches/cmake/src/ (71 files in 9 dirs): Sync cmake branch to trunk r41904 |
| 23:45.36 | *** join/#brlcad roberthl (~robert@v001.rhl.me.uk) | |
| 23:45.36 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 00:36.22 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 01:07.43 | CIA-43 | BRL-CAD: 03starseeker * r41906 10/brlcad/trunk/regress/ (13 files): Try to structure the regress scripts so they will work both with CMake and autotools |
| 01:10.11 | starseeker | O.o the cmake build of mged in-dir is somehow pulling the /usr/brlcad versions of libraries even when mged -v reports the right versions for libs |
| 01:17.26 | CIA-43 | BRL-CAD: 03starseeker * r41907 10/brlcad/branches/cmake/regress/library.sh: Sync library.sh with trunk. |
| 01:50.42 | starseeker | no, maybe it's more subtle than that... it doesn't work right if all the dependencies aren't in place, but it still returns lscon somehow with the ? command |
| 01:56.08 | CIA-43 | BRL-CAD: 03starseeker * r41908 10/brlcad/branches/cmake/src/mged/CMakeLists.txt: Just like btclsh/bwish, mged needs to require itcl/itk be built if using local copies - build will succeed, but package require will fail. |
| 01:57.37 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 01:59.09 | CIA-43 | BRL-CAD: 03starseeker * r41909 10/brlcad/branches/cmake/regress/CMakeLists.txt: Flesh out the dependencies on the regression scripts. |
| 02:03.29 | CIA-43 | BRL-CAD: 03starseeker * r41910 10/brlcad/trunk/src/conv/iges/ (getcurve.c iges_struct.h): pull the EQUAL out of iges_struct.h, replace its use with NEAR_EQUAL |
| 02:19.06 | CIA-43 | BRL-CAD: 03starseeker * r41911 10/brlcad/branches/cmake/src/libbu/parse.c: Hmm - looks like a sync didn't quite get everything - update libbu parser.c to match trunk. |
| 02:36.36 | starseeker | growl... what's wrong with the shader regression? have to test in autotools... |
| 02:37.48 | starseeker | can't help thinking our shader code shouldn't be this fragile... |
| 02:40.14 | starseeker | hmm, cmake specific |
| 02:40.27 | starseeker | ok, that's good and bad |
| 02:45.06 | starseeker | looks like some syncs went wrong somehow... figures |
| 02:45.14 | starseeker | will sort the mess out tomorrow |
| 04:17.21 | CIA-43 | BRL-CAD: 03starseeker * r41912 10/brlcad/branches/cmake/regress/ (CMakeLists.txt shaders.sh): This may not be the whole story, but clearly this was wrong - generalize gencolor call in shaders.h |
| 04:23.04 | starseeker | yeah, that's not the only issue |
| 04:32.29 | starseeker | wonders if his FindTCL.cmake antics have broken stuff... quite possible |
| 07:22.34 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:58.14 | *** join/#brlcad Ralith (~ralith@216.162.199.202) | |
| 08:27.46 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:44.50 | *** join/#brlcad Stattrav (~Stattrav@122.172.38.200) | |
| 08:44.50 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:47.41 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 08:47.41 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 08:47.41 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 08:47.53 | *** join/#brlcad Ralith (~ralith@216.162.199.202) | |
| 08:48.49 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 08:48.49 | *** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ) | |
| 08:48.49 | *** join/#brlcad DaveLo (~claymore@BZ.BZFLAG.BZ) | |
| 08:49.04 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 08:49.04 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:26.15 | *** join/#brlcad roberthl (~robert@v001.rhl.me.uk) | |
| 09:26.15 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 09:39.29 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 10:22.22 | *** join/#brlcad roberthl_ (~robert@v001.rhl.me.uk) | |
| 10:26.37 | *** join/#brlcad roberthl (~robert@v001.rhl.me.uk) | |
| 10:26.37 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 10:57.07 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:10.07 | *** join/#brlcad mafm (~mafm@72.Red-83-54-182.dynamicIP.rima-tde.net) | |
| 11:54.15 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 11:54.15 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:03.09 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:56.00 | *** join/#brlcad Ralith_ (~ralith@216.162.199.202) | |
| 14:00.36 | CIA-43 | BRL-CAD: 03starseeker * r41913 10/brlcad/trunk/regress/shaders.sh: Add the generalization of shaders.sh to trunk too |
| 14:30.56 | CIA-43 | BRL-CAD: 03starseeker * r41914 10/brlcad/trunk/ (7 files in 4 dirs): |
| 14:30.57 | CIA-43 | BRL-CAD: Hmm. Looks like the CMake logic for liboptical/libmultispectral is |
| 14:30.57 | CIA-43 | BRL-CAD: significantly different than autotools in some fashion. This set of changes |
| 14:30.58 | CIA-43 | BRL-CAD: gets things working in trunk with regression test passing - need to reexamine |
| 14:30.58 | CIA-43 | BRL-CAD: the liboptical CMake build in detail. |
| 14:50.36 | CIA-43 | BRL-CAD: 03starseeker * r41915 10/brlcad/branches/cmake/src/ (5 files in 2 dirs): Sync cmake branch to trunk r41914 |
| 15:08.19 | *** join/#brlcad crazy_imp (~mj@a89-182-217-101.net-htp.de) | |
| 15:16.01 | CIA-43 | BRL-CAD: 03starseeker * r41916 10/brlcad/branches/cmake/src/adrt/CMakeLists.txt: Sync adrt build logic to match Makefile.am - per Erik, master and slave commands aren't really relevant anymore so removing build logic. This code is still in a state of flux, apparently. |
| 15:17.59 | CIA-43 | BRL-CAD: 03starseeker * r41917 10/brlcad/branches/cmake/src/adrt/CMakeLists.txt: Add note about needing to examine Windows build files for custom logic |
| 15:20.44 | CIA-43 | BRL-CAD: 03starseeker * r41918 10/brlcad/branches/cmake/src/ (libmultispectral/CMakeLists.txt liboptical/CMakeLists.txt): Make the liboptical/libmultispectral build match more closely the Makefile.am build. This appears to result in the shader test passing. |
| 15:40.39 | starseeker | breaths a sigh of relief |
| 15:56.43 | CIA-43 | BRL-CAD: 03starseeker * r41919 10/brlcad/branches/cmake/doc/docbook/ (CMakeLists.txt fop.xconf.in): set srcdir in the CMakeLists.txt file so we can use the fop.xconf.in that is compatible with autotools (looks like we may have had the wrong CMake variable in there anyway) |
| 16:00.25 | CIA-43 | BRL-CAD: 03starseeker * r41920 10/brlcad/trunk/ (include/raytrace.h src/proc-db/csgbrep.cpp): Have csgbrep go through the table interface. |
| 16:06.10 | CIA-43 | BRL-CAD: 03starseeker * r41921 10/brlcad/trunk/src/tclscripts/archer/images/ (Makefile.am Themes/): Archer should no longer be using the Themes directory - eliminate it. |
| 16:11.48 | CIA-43 | BRL-CAD: 03starseeker * r41922 10/brlcad/branches/cmake/src/tclscripts/archer/images/Makefile.am: Sync archer/images Makefile.am with trunk |
| 16:15.38 | CIA-43 | BRL-CAD: 03starseeker * r41923 10/brlcad/branches/cmake/src/libgcv/wfobj/ (libobj/ obj_grammar.yy obj_rules.ll): For now, put the wfobj dir back the way it was. We need a working byacc/flex solution before libobj can be hooked into the build properly. |
| 16:19.44 | CIA-43 | BRL-CAD: 03starseeker * r41924 10/brlcad/trunk/src/brlman/brlman.sh.in: We don't use AWF anymore - fix the comment in brlman |
| 22:38.43 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 22:38.43 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.0 is posted (20101209) || Happy Open Source Anniversary 2010-12-21 !!! Six years... | |
| 22:41.25 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 22:41.25 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.0 is posted (20101209) || Happy Open Source Anniversary 2010-12-21 !!! Six years... | |
| 22:50.46 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 00:53.06 | *** join/#brlcad cjdevlin1 (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 01:02.15 | *** join/#brlcad crazy_imp (~mj@a89-182-203-165.net-htp.de) | |
| 01:06.35 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 01:12.51 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 01:12.52 | *** part/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 02:04.23 | *** join/#brlcad DX^ (~DX@c-71-59-50-121.hsd1.ga.comcast.net) | |
| 02:04.56 | DX^ | If I want to convert a file from .G to another format, it asks me for a region name in the command line. I tried "top" and "all" and a bunch of other crap but I can't remember what the correct parameter is. |
| 02:05.18 | DX^ | Also, is there a command line function to list all of the names of the objects in a .G database file? |
| 02:07.16 | Ralith | I don't know the answers to your questions, but is there a reason you can't just open it in mged and list it there? |
| 02:18.15 | brlcad | DX^: the command is "tops", not "top" |
| 02:18.22 | DX^ | ah bah |
| 02:18.32 | brlcad | top just sets a top-view |
| 02:18.45 | brlcad | ls would list objects |
| 02:18.55 | brlcad | tree will list the hierarchy |
| 02:49.15 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 04:54.33 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 05:38.03 | *** join/#brlcad ntosme2 (~narf@user-105n9h9.cable.mindspring.com) | |
| 05:52.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:04.13 | ntosme2 | hey guys, I just compiled and installed brl-cad...where's the main executable? |
| 06:06.29 | ntosme2 | all I see are brlman and brlcad-config |
| 06:08.04 | ntosme2 | ah /usr/brlcad/bin/mged |
| 06:08.31 | ntosme2 | why is it not in the path? |
| 06:23.05 | *** join/#brlcad Stattrav (~Stattrav@122.167.254.119) | |
| 06:23.05 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:24.25 | Ralith | Does anyone have jonored's email? |
| 06:27.30 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 11:06.02 | *** join/#brlcad mafm (~mafm@6.Red-81-37-119.dynamicIP.rima-tde.net) | |
| 11:56.53 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 11:56.53 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.0 is posted (20101209) || Happy Open Source Anniversary 2010-12-21 !!! Six years... | |
| 12:11.46 | *** join/#brlcad Stattrav (~Stattrav@122.167.254.119) | |
| 12:11.46 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:32.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:58.25 | *** join/#brlcad mafm (~mafm@6.Red-81-37-119.dynamicIP.rima-tde.net) | |
| 15:51.09 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 16:47.36 | CIA-43 | BRL-CAD: 03starseeker * r42037 10/brlcad/branches/cmake/ (4 files in 4 dirs): Gah - per target defines didn't work so hot, revert to previous approach which special-cases src/adrt |
| 16:50.24 | starseeker | ntosme2: we don't put things in system paths because it tends to result in conflicts with already installed stuff - simpler just to add /usr/brlcad/bin to your path |
| 16:52.40 | starseeker | brlcad: is libtie viable as a src lib, or does it belong in a subdir somewhere? (haven't synced trunk yet because I'm waiting for the dust to settle before reworking CMake logic for libtie/librender) |
| 16:57.50 | CIA-43 | BRL-CAD: 03starseeker * r42038 10/brlcad/branches/cmake/src/other/openNURBS/CMakeLists.txt: Shouldn't need the opennurbs-static target with Visual C++, unless I'm missing something. |
| 17:39.58 | CIA-43 | BRL-CAD: 03starseeker * r42039 10/brlcad/branches/cmake/CMakeLists.txt: |
| 17:39.59 | CIA-43 | BRL-CAD: Try adding nologo to some more variables, although I'm not sure these will have |
| 17:39.59 | CIA-43 | BRL-CAD: much/any impact - the most annoying one currently is the Resource Compiler, |
| 17:40.00 | CIA-43 | BRL-CAD: which cannot be suppressed: |
| 17:40.00 | CIA-43 | BRL-CAD: http://social.msdn.microsoft.com/Forums/en/windowssdk/thread/88bd1f52-af7d-4aa7-982a-f8798b32288d |
| 17:46.07 | brlcad | starseeker: not sure what you're asking |
| 17:46.39 | brlcad | "yes"? |
| 18:01.39 | starseeker | ``Erik moved libtie to src as a toplevel library |
| 18:01.48 | starseeker | we weren't sure whether that was "toplevel" worthy |
| 18:10.11 | CIA-43 | BRL-CAD: 03starseeker * r42040 10/brlcad/branches/cmake/src/other/ (tcl/CMakeLists.txt tk/CMakeLists.txt): Update version to 8.5.9, also don't compile the manifest file for wish (causes errors, not sure what precisely is going on - may need some special foo for user-supplied rc file) |
| 18:11.39 | starseeker | ``Erik: somewhat to my surprise, I seem to have a build of both libtie and librender here from CMake |
| 18:12.32 | brlcad | merged as an implementation library for librt, it should either be in src or a subdir under librt |
| 20:13.53 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) | |
| 20:26.31 | CIA-43 | BRL-CAD: 03starseeker * r42041 10/brlcad/branches/cmake/include/CMakeLists.txt: opennurbs_ext.h isn't in include anymore. |
| 20:27.03 | brlcad | starseeker: the one thing that comes to mind, though, is that tie.h was NOT set up as a public interface header |
| 20:27.19 | brlcad | if it's going to live in include/ it really should be, especially since it's a new header |
| 20:28.19 | brlcad | the other headers have heritage excuse, it's a "new" library so it really doesn't have any excuse for having private macros, types, hacks and such in its public header |
| 20:29.18 | brlcad | maybe separate the private stuff in tie.h out into src/libtie/tieprivate.h |
| 00:58.11 | *** join/#brlcad ibot (ibot@rikers.org) | |
| 00:58.11 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.0 is posted (20101209) || Happy Open Source Anniversary 2010-12-21 !!! Six years... | |
| 01:02.42 | *** join/#brlcad crazy_imp (~mj@a89-182-211-75.net-htp.de) | |
| 01:53.50 | starseeker | growls... something about Tk isn't set up right |
| 01:54.13 | starseeker | gonna have to dig back into the build logic for that - I can't even package require it |
| 01:58.06 | starseeker | hmm... that could be a problem, I never added pkgIndex logic for Tk itself (turns mildly red) |
| 01:58.32 | starseeker | still not quite sure why bwish wouldn't start, but that explains some things... |
| 06:13.57 | *** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net) | |
| 06:13.57 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 09:14.07 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:47.20 | *** join/#brlcad mafm (~mafm@65.Red-79-159-0.staticIP.rima-tde.net) | |
| 12:46.30 | *** join/#brlcad Dweezahr (~Dweezahr@flits102-34.flits.rug.nl) | |
| 13:57.25 | CIA-43 | BRL-CAD: 03starseeker * r42042 10/brlcad/branches/cmake/src/other/tk/CMakeLists.txt: This may not do it for Windows, but make a stab at pkgIndex logic for Tk |
| 14:00.14 | starseeker | has a feeling the ordering of auto_path may be an issue - it MIGHT explain why I keep getting interference from system installs of Tcl/Tk |
| 14:05.49 | starseeker | wonders why he did have a pkgIndex.tcl for tk in /usr/brlcad... left over maybe? |
| 14:05.52 | starseeker | weird |
| 14:12.41 | starseeker | hmm - "On the mac we build both X11 and Aqua versions of our gui tools such that |
| 14:12.41 | starseeker | if you rsh/ssh in and set your display you get X11 and it just works, |
| 14:12.43 | starseeker | otherwise you get Aqua." |
| 14:12.59 | starseeker | that's an interesting approach - one that hadn't occurred to me |
| 14:17.02 | CIA-43 | BRL-CAD: 03starseeker * r42043 10/brlcad/branches/cmake/src/util/bwcrop.c: compiler warning about comparing types - cast abs to size_t |
| 14:27.06 | starseeker | tries to see what other damage might have been done by his FindTCL changes... |
| 15:15.25 | *** join/#brlcad mafm (~mafm@65.Red-79-159-0.staticIP.rima-tde.net) | |
| 15:19.32 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 15:22.03 | CIA-43 | BRL-CAD: 03starseeker * r42044 10/brlcad/branches/cmake/ (56 files in 56 dirs): Try to clean up the mess left by FindTCL changes... this appears to build on Gentoo, but needs more testing. |
| 15:53.58 | CIA-43 | BRL-CAD: 03starseeker * r42045 10/brlcad/branches/cmake/src/other/tk/library/CMakeLists.txt: add new spinbox.tcl file |
| 15:56.14 | CIA-43 | BRL-CAD: 03starseeker * r42046 10/brlcad/branches/cmake/src/tclscripts/mged/CMakeLists.txt: Add man.tcl to CMakeLists.txt |
| 16:04.49 | CIA-43 | BRL-CAD: 03starseeker * r42047 10/brlcad/branches/cmake/src/other/libpng/CMakeLists.txt: Sigh - need a mod to libpng's CMakeLists.txt file to account for CMAKE_LIBRARY_OUTPUT_DIRECTORY and CMAKE_ARCHIVE_OUTPUT_DIRECTORY being set. Have emailed upstream to see what their take is. |
| 16:44.53 | *** join/#brlcad crazy_imp (~mj@a89-182-211-75.net-htp.de) | |
| 16:50.32 | CIA-43 | BRL-CAD: 03starseeker * r42048 10/brlcad/branches/cmake/src/other/libpng/CMakeLists.txt: And one more libpng tweak - another issue that only showed up on the install attempt. |
| 17:29.57 | CIA-43 | BRL-CAD: 03starseeker * r42049 10/brlcad/branches/cmake/src/other/CMakeLists.txt: Append tkstub to the list rather than resetting it |
| 17:47.04 | starseeker | growl. Still some problem with tk on Windows - will have to examine our Tk build and the nmake logic tomorrow |
| 17:48.08 | ``Erik | windows is ... special |
| 20:37.17 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 22:34.51 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 23:24.24 | CIA-43 | BRL-CAD: 03brlcad * r42050 10/brlcad/trunk/ (12 files in 6 dirs): expand all BoT processing from using ints to using size_t for face/vertex/normal indices and counter variables. |
| 00:13.08 | CIA-43 | BRL-CAD: 03starseeker * r42051 10/brlcad/branches/cmake/doc/docbook/system/mann/en/CMakeLists.txt: |
| 00:13.08 | CIA-43 | BRL-CAD: Start prototyping a system to use the GLOB feature of CMake to test whether our |
| 00:13.09 | CIA-43 | BRL-CAD: lists of files are complete - may be able to work out an EXTRA_DIST like |
| 00:13.20 | CIA-43 | BRL-CAD: feature, although this should probably only be run when a specific target is |
| 00:13.20 | CIA-43 | BRL-CAD: called and needs to handle all the various directories... may or may not be |
| 00:13.20 | CIA-43 | BRL-CAD: worth it, we could just do a clean svn checkout prior to packaging up for |
| 00:13.21 | CIA-43 | BRL-CAD: distribution. |
| 00:13.40 | brlcad | mid-building here, update with caution (may break build) |
| 00:28.17 | starseeker | brlcad: np - been putting off a sync to tree |
| 00:28.45 | starseeker | just trying to decide whether I have to attempt implementation of an EXTRA_DIST-like mechanism |
| 00:34.00 | starseeker | what I've done now is a little more specific - it haults the makefile generation if it spots a stray xml file not added to the CMakeLists.txt list - intended to catch man pages added to repository but not to build logic |
| 00:38.01 | starseeker | assuming I can coax the build into a state where a full build of BRL-CAD leaves a pristine source tree behind if built out-of-dir, would that alleviate the need for the EXTRA_DIST stuff? |
| 00:50.58 | DX^ | I posted a bug about IGES a long while ago |
| 00:51.03 | DX^ | but I don't think anyone cares any more :) |
| 00:55.20 | brlcad | DX^: caring doesn't imply time available, or more specifically mean that it'll get fixed quickly |
| 00:55.58 | brlcad | moreover, there's been literally months of time and effort going into that particular problem |
| 01:02.46 | *** join/#brlcad crazy_imp (~mj@a89-183-80-79.net-htp.de) | |
| 04:38.44 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 06:57.37 | *** join/#brlcad Stattrav (~Stattrav@122.172.16.143) | |
| 06:57.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:16.13 | *** join/#brlcad mafm (~mafm@231.Red-83-38-34.dynamicIP.rima-tde.net) | |
| 11:12.04 | CIA-43 | BRL-CAD: 03davidloman * r42052 10/rt^3/trunk/HACKING: Fixt up some Engrish issues in Hacking. |
| 11:34.34 | *** join/#brlcad mafm (~mafm@231.Red-83-38-34.dynamicIP.rima-tde.net) | |
| 12:08.43 | *** join/#brlcad Stattrav (~Stattrav@122.172.16.143) | |
| 12:08.43 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:40.59 | *** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de) | |
| 15:22.56 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 15:24.31 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 15:28.23 | CIA-43 | BRL-CAD: 03d_rossberg * r42053 10/rt^3/trunk/src/coreInterface/Arb8.cpp: the VAPPROXEQUAL() macro was renamed to VNEAR_EQUAL(), so it was changed here too |
| 15:30.36 | CIA-43 | BRL-CAD: 03d_rossberg * r42054 10/brlcad/trunk/ (2 files in 2 dirs): |
| 15:30.36 | CIA-43 | BRL-CAD: libz is called zlib now |
| 15:30.37 | CIA-43 | BRL-CAD: (and opennurbs_ext.h a private header) |
| 15:42.11 | CIA-43 | BRL-CAD: 03d_rossberg * r42055 10/brlcad/trunk/src/conv/iges/brlcad_brep.cpp: another case of pullback_curve() usage and therefore opennurbs_ext.h include |
| 15:43.21 | CIA-43 | BRL-CAD: 03d_rossberg * r42056 10/brlcad/trunk/src/libbn/CMakeLists.txt: there is no screengrab.c in libbn |
| 15:48.53 | CIA-43 | BRL-CAD: 03d_rossberg * r42057 10/brlcad/trunk/src/libbu/CMakeLists.txt: |
| 15:48.53 | CIA-43 | BRL-CAD: synced with Makefile.am (timer.c) |
| 15:48.54 | CIA-43 | BRL-CAD: compiles fine with MSVC 2008 |
| 16:11.57 | CIA-43 | BRL-CAD: 03d_rossberg * r42058 10/brlcad/trunk/src/other/libz/CMakeLists.txt: |
| 16:11.57 | CIA-43 | BRL-CAD: the zconf.h has to lie in the same directory as zlib.h no matter where the binaries are build to be visible by the other libraries |
| 16:11.58 | CIA-43 | BRL-CAD: the original CMakeLists.txt makes sense for a standalone project but causes problems as a sub-project configuration in larger programs |
| 16:11.58 | CIA-43 | BRL-CAD: (nevertheless it's a good starting point) |
| 16:18.09 | starseeker | d_rossberg: I don't think we want to alter the libz CMakeLists.txt if we can help it |
| 16:18.58 | starseeker | d_rossberg: I'm using the vanilla file in the cmake branch with one tweak for MAN pages and it works fine - the trick is to include_directories both the source and the binary dirs to get both zlib.h and zconf.h (unless I'm missing something) |
| 16:19.38 | starseeker | I do that in a lot of places - my goal is to have a complete BRL-CAD build take place without the build process altering the source tree in any way |
| 16:20.08 | starseeker | I'm pretty close - the main issue is a tcl script that insists on generating files in src - I need to provide it with an output dir target |
| 16:26.57 | d_rossberg | starseeker: i'm afraid zlib's CMakeLists.txt has to be modified anyway, either as i did or it has to export its include directories |
| 16:27.31 | starseeker | but if you're doing a subproject, you know where both its src dir and its build dir are? |
| 16:28.06 | starseeker | I'm building openNURBS in the cmake branch successfully... |
| 16:29.00 | d_rossberg | i don't want to guess where zlib's include files could be all around |
| 16:29.38 | starseeker | that's just it - you don't. There are only two possibilities |
| 16:29.48 | starseeker | if you include both, you should be good |
| 16:30.33 | d_rossberg | i don't even know where zlibs binary directory is (in other libs than zlib) |
| 16:31.51 | starseeker | ah - that's probably my THIRD_PARTY_SUBDIR macro |
| 16:33.15 | d_rossberg | no, the is cmake 2.6 (?) standard behavior |
| 16:33.47 | starseeker | yeah, you're right that the default behavior works that way |
| 16:34.10 | starseeker | but we have a macro in misc/CMake in the cmake branch that lets us avoid those issues |
| 16:34.26 | starseeker | have you tried the cmake branch lately? |
| 16:35.01 | d_rossberg | no, today is my first day back in the office |
| 16:35.04 | d_rossberg | we can talk about it tomorrow, i've to catch my bus ;) |
| 16:35.09 | starseeker | cool |
| 16:35.38 | d_rossberg | ... i'll try the cmake branch later ... |
| 17:04.42 | CIA-43 | BRL-CAD: 03starseeker * r42059 10/brlcad/branches/cmake/src/other/ (6 files in 6 dirs): Generalize the logic for writing out pkgIndex files |
| 17:07.19 | brlcad | gone way down the rabbit hole with these latest size_t changes.. so much stuff! |
| 19:27.23 | *** join/#brlcad Ralith (~ralith@d142-058-093-144.wireless.sfu.ca) | |
| 19:48.19 | CIA-43 | BRL-CAD: 03starseeker * r42060 10/brlcad/branches/cmake/src/other/tk/CMakeLists.txt: Hmm - put the stubs line inside quotes, and just tclstub on Win32... |
| 19:48.41 | *** join/#brlcad Ralith (~ralith@d142-058-093-144.wireless.sfu.ca) | |
| 20:14.23 | starseeker | WOOOOT |
| 20:14.57 | starseeker | first successful run of MGED on Windows from a CMake build |
| 20:15.48 | brlcad | congratulations |
| 20:18.45 | *** join/#brlcad Ralith (~ralith@d142-058-093-144.wireless.sfu.ca) | |
| 20:24.27 | CIA-43 | BRL-CAD: 03brlcad * r42061 10/brlcad/trunk/ (24 files in 7 dirs): |
| 20:24.27 | CIA-43 | BRL-CAD: revert libtie migration until the problems are fixed. there was no build logic |
| 20:24.28 | CIA-43 | BRL-CAD: in src/libtie/ (so the build was broken) and the tie.h header included private |
| 20:24.28 | CIA-43 | BRL-CAD: implementation details not appropriate for promotion into the include/ |
| 20:24.29 | CIA-43 | BRL-CAD: directory. this reverts the remaining portion of commit r42032 not already |
| 20:24.29 | CIA-43 | BRL-CAD: reverted by r42035. |
| 21:29.12 | CIA-43 | BRL-CAD: 03johnranderson * r42062 10/brlcad/trunk/src/conv/asc/asc2g.c: |
| 21:29.14 | CIA-43 | BRL-CAD: Now accepts initial comments at start of file |
| 21:29.15 | CIA-43 | BRL-CAD: First non-comment non-blank line must still be a "title" or "put" command, |
| 21:29.25 | brlcad | woot |
| 21:47.35 | CIA-43 | BRL-CAD: 03starseeker * r42063 10/brlcad/branches/cmake/src/other/tkhtml/CMakeLists.txt: Tweak building of tkhtml for Windows |
| 22:56.41 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 23:03.18 | CIA-43 | BRL-CAD: 03starseeker * r42064 10/brlcad/branches/cmake/CMakeLists.txt: Start setting up logic for CPack. Start slowly - this is just the tar.gz, tar.bz2 and .zip files, to match what make distcheck produces (that will need to be confirmed). |
| 23:36.40 | CIA-43 | BRL-CAD: 03starseeker * r42065 10/brlcad/branches/cmake/src/tclscripts/CMakeLists.txt: |
| 23:36.41 | CIA-43 | BRL-CAD: Try moving the generated script files into the bin dir - this should, in theory, |
| 23:36.41 | CIA-43 | BRL-CAD: be the last thing that was writing back to the source tree during build. Will |
| 23:36.42 | CIA-43 | BRL-CAD: need to try in an svn or git repository with no ignore settings. |
| 23:51.17 | starseeker | woo-hoo, that looks like it may be it - untarred one of the cpack tarballs, built using the untarred result as the src dir, untarred again into another dir, and a diff -r of the two directories reported no differences |
| 01:02.11 | *** join/#brlcad crazy_imp (~mj@a89-182-209-17.net-htp.de) | |
| 02:02.12 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 03:21.19 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 03:23.26 | *** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net) | |
| 03:23.34 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 03:27.42 | *** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 03:37.23 | *** join/#brlcad Dweezahr (~Dweezahr@flits102-34.flits.rug.nl) | |
| 03:37.23 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 03:37.23 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 03:37.23 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 03:37.23 | *** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ) | |
| 03:37.23 | *** join/#brlcad DaveLo (~claymore@BZ.BZFLAG.BZ) | |
| 05:08.07 | starseeker | finally finds a workable way to splice multiple videos into one and convert them to mpeg2 |
| 05:14.24 | *** join/#brlcad Stattrav (~Stattrav@122.172.16.143) | |
| 05:14.24 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:00.10 | CIA-43 | BRL-CAD: 03brlcad * r42066 10/brlcad/trunk/src/mged/Makefile.am: the bot face/normal arrays should probably be reverted back to integers, but turn off strict in here in the meantime to fix the build. |
| 06:31.54 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:33.32 | CIA-43 | BRL-CAD: 03brlcad * r42067 10/brlcad/trunk/ (20 files in 9 dirs): more size_t cascading. put the type to use throughout much of libbn and most caller code. other code affected was sketch object code, vertex and curve counts. |
| 07:45.31 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 07:45.31 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.0 is posted (20101209) || Happy Open Source Anniversary 2010-12-21 !!! Six years... | |
| 07:52.55 | CIA-43 | BRL-CAD: 03brlcad * r42068 10/brlcad/trunk/src/conv/asc/ (asc2g.c g2asc.c): isspace() needs ctype.h |
| 08:19.04 | CIA-43 | BRL-CAD: 03brlcad * r42069 10/brlcad/trunk/src/librt/primitives/ (extrude/extrude.c nmg/nmg_misc.c): size_t quellage |
| 08:33.45 | CIA-43 | BRL-CAD: 03brlcad * r42070 10/brlcad/trunk/ (23 files in 11 dirs): |
| 08:33.46 | CIA-43 | BRL-CAD: revert the conversion of the bot face/vertex/normal arrays from being size_t |
| 08:33.46 | CIA-43 | BRL-CAD: back to int. additionally, convert the remainder of bot struct size types over |
| 08:33.47 | CIA-43 | BRL-CAD: to size_t completely. this propagates hundreds of ancillary changes (more than |
| 08:33.47 | CIA-43 | BRL-CAD: 400) but provides the added benefits of more extensive value range on some |
| 08:33.53 | CIA-43 | BRL-CAD: platforms, better warning/bug detection, and more consistently making size types |
| 08:33.53 | CIA-43 | BRL-CAD: be unsigned so no negative values is inherent. |
| 08:33.53 | CIA-43 | BRL-CAD: 03brlcad * r42071 10/brlcad/trunk/src/libged/bot_merge.c: quellage, use size_t |
| 08:33.56 | CIA-43 | BRL-CAD: 03brlcad * r42072 10/brlcad/trunk/src/libged/bot.c: use EQUAL() for exact floating point comparison |
| 08:49.45 | CIA-43 | BRL-CAD: 03brlcad * r42073 10/brlcad/trunk/src/mged/ (animedit.c chgtree.c edars.c edsol.c titles.c usepen.c): more size_t quellage |
| 10:44.09 | *** join/#brlcad Stattrav (~Stattrav@117.192.240.10) | |
| 10:44.09 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:46.42 | *** join/#brlcad mafm (~mafm@134.Red-83-35-148.dynamicIP.rima-tde.net) | |
| 11:29.24 | *** join/#brlcad Stattrav (~Stattrav@122.172.16.143) | |
| 11:29.24 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:48.46 | *** join/#brlcad Stattrav (~Stattrav@122.172.16.143) | |
| 11:48.46 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:52.46 | *** join/#brlcad Axman6_ (~Axman6@pdpc/supporter/student/Axman6) | |
| 12:09.44 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 12:27.16 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:47.31 | starseeker | d_rossberg: any luck with the cmake branch? |
| 14:12.34 | d_rossberg | starseeker: i'm still looking for a way to set the install directory |
| 14:13.36 | *** join/#brlcad AlecTaylor (~Tauk@unaffiliated/alectaylor) | |
| 14:13.37 | AlecTaylor | hi |
| 14:16.50 | AlecTaylor | How do I create this http://i55.tinypic.com/1606amg.jpg in BRL-CAD? |
| 14:48.34 | starseeker | d_rossberg: install directory? BRLCAD_PREFIX may be what you want |
| 14:49.26 | starseeker | AlecTaylor: the sketch, or a 3D object? |
| 14:53.27 | d_rossberg | starseeker: but BRLCAD_PREFIX isn't present in the cmake gui |
| 14:54.48 | d_rossberg | i could probable add it, however it is an important value which should be there |
| 14:55.19 | starseeker | um... |
| 14:56.15 | starseeker | weird |
| 14:56.29 | starseeker | i've been using CMake from the command line... |
| 14:56.38 | starseeker | I see it isn't there, one second... |
| 15:01.08 | CIA-43 | BRL-CAD: 03starseeker * r42074 10/brlcad/branches/cmake/CMakeLists.txt: Make a stab at getting BRLCAD_PREFIX displayed in the CMake gui |
| 15:01.43 | starseeker | see if that helps - I've been using cmake almost exclusively from the command line, so there are probably other tweaks needed to clean up the gui presentation |
| 15:02.26 | starseeker | incidently, there is a known limitation right now about spaces in pathnames - they will almost certainly cause failures with the Tcl/Tk build |
| 15:02.41 | starseeker | I'm working on that, but it's not fixed yet |
| 15:03.30 | starseeker | reflects that should probably be renamed to BRLCAD_INSTALL_PREFIX... |
| 15:05.01 | d_rossberg | i'll have a look at it as soon as the compile jobs ended |
| 15:05.09 | starseeker | no problem :-) |
| 15:05.32 | starseeker | which platform are you building on? |
| 15:06.51 | AlecTaylor | starseeker: 3D object |
| 15:07.12 | starseeker | I'd use a series of cylinders |
| 15:07.23 | starseeker | are you new to BRL-CAD? |
| 15:07.33 | AlecTaylor | starseeker: Here's the top view http://i56.tinypic.com/24bklds.jpg |
| 15:07.43 | AlecTaylor | starseeker: Never used it before |
| 15:08.18 | starseeker | AlecTaylor: ah, then you'll want to start with this: http://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf |
| 15:09.08 | starseeker | that object looks pretty straightforward, so you should be able to do it with the techniques described in that tutorial |
| 15:09.34 | d_rossberg | starseeker: MS Windows XP (32bit) with MSVS 2008 |
| 15:09.47 | starseeker | winces - ah, the toughest platform |
| 15:24.56 | CIA-43 | BRL-CAD: 03erikgreenwald * r42075 10/brlcad/trunk/src/adrt/ (5 files in 2 dirs): new tieprivate.h, clean up of tie.h |
| 15:27.17 | CIA-43 | BRL-CAD: 03erikgreenwald * r42076 10/brlcad/trunk/src/adrt/Makefile.am: add STRICT_FLAGS |
| 15:31.33 | AlecTaylor | starseeker: How long will it take (about) to learn how to do it, then to create it? |
| 15:31.50 | AlecTaylor | won't be able to work on it after tonight, and it's 2:30am already |
| 15:32.17 | brlcad | AlecTaylor: there have been new users / students that have gotten through all of the mged tutorials in just a couple hours |
| 15:32.51 | brlcad | you won't be very good, but you should be able to make a model as simple as the one you sketched in under an hour once you have the basics |
| 15:33.29 | brlcad | the hardest part is usually learning all of the various modeling commands, learning how to use them |
| 15:33.51 | AlecTaylor | hmm |
| 15:34.00 | brlcad | someone proficient in mged could probably make that model in less than 10 minutes |
| 15:34.15 | AlecTaylor | brlcad: 10 minutes? |
| 15:34.20 | brlcad | less than |
| 15:35.11 | CIA-43 | BRL-CAD: 03erikgreenwald * r42077 10/brlcad/trunk/src/adrt/libtie/ (tie.c tieprivate.h): Move the win32 near/far fix to the right place |
| 15:35.27 | AlecTaylor | is a volunteer putting in 8 hours a day, 6 days a week for a robotics competetion [mentoring]. Would you be able to do me a [massive] favour by modelling it for me? |
| 15:35.31 | AlecTaylor | brlcad^ |
| 15:35.38 | brlcad | once you climb the steep learning curve, you can be just as efficient as you'd be in other CAD/modeling systems |
| 15:37.07 | AlecTaylor | brlcad: I'll read the entire guide + more in a week, I just need something working [literally in the next little while; as I'm going in for surgery tomorrow and want to show my students my Robot design in CAD] |
| 15:37.26 | brlcad | AlecTaylor: heh, sorry ... I put a lot of volunteer time into BRL-CAD as it is; my skills are better put to use doing software development |
| 15:37.50 | AlecTaylor | Same, that's my area of expertise! |
| 15:37.57 | AlecTaylor | Swap for 10mins? :P |
| 15:38.25 | AlecTaylor | is an avid C++ programmer and enthusiast, everything from Qt to Wt and CLI! |
| 15:38.30 | brlcad | it wouldn't be 10 minutes for *me* .. I'm certainly not a proficient modeler :) |
| 15:38.48 | AlecTaylor | I see! :) |
| 15:39.43 | brlcad | you know, if you're just showing off a design, you might have better luck quickly whipping up something in sketchup |
| 15:40.00 | brlcad | it'd be crappy for CAD purposes, but it'd showcase your design in 3D |
| 15:48.17 | CIA-43 | BRL-CAD: 03erikgreenwald * r42078 10/brlcad/trunk/src/adrt/librender/ (13 files): const propogation |
| 15:51.27 | AlecTaylor | brlcad: ended up just showing them something I wrote in Blender [the stand for the telescope] and the aforementioned side-view and top-view mockups |
| 15:52.15 | AlecTaylor | Thanks though |
| 15:53.20 | brlcad | AlecTaylor: if you hang around, someone might be willing to help you out |
| 16:04.45 | CIA-43 | BRL-CAD: 03starseeker * r42079 10/brlcad/branches/cmake/src/tclscripts/CMakeLists.txt: Don't cram two commands on one line - make use of CMake's support for multiple COMMAND lines executed in order. |
| 16:04.55 | d_rossberg | starseeker: it looks like there is a clean-up somewhere in the cmake build which makes looking for errors uncomfortable |
| 16:05.07 | CIA-43 | BRL-CAD: 03brlcad * r42080 10/brlcad/trunk/TODO: cp command should take multiple copy names |
| 16:05.18 | starseeker | d_rossberg: what do you mean? |
| 16:07.24 | d_rossberg | i'm using the batch build in VS, there i got 3 errors, then i started the batch build again to see these errors but it started to compile the successfull builds too |
| 16:09.32 | starseeker | hmm |
| 16:10.15 | starseeker | I'm seeing a few errors on my first pass, but I'm not sure what those are because my second pass comes up clean |
| 16:10.23 | starseeker | not sure why it's rebuilding everything |
| 16:10.36 | starseeker | you're using the ALL_BUILD target? |
| 16:13.39 | d_rossberg | ALL_BUILD and INSTALL are switched off |
| 16:21.25 | brlcad | too bad AlecTaylor wasn't more patient, http://brlcad.org/tmp/stand.png |
| 16:21.58 | brlcad | half hour, not too shabby but I still suck |
| 16:22.16 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 16:22.53 | starseeker | d_rossberg: um... |
| 16:23.08 | starseeker | maybe I'd better write up how I'm building so we can compare notes |
| 16:24.22 | d_rossberg | starseeker: don't worry, i've completely different problems at the moment ;) |
| 16:28.40 | starseeker | d_rossberg: with the cmake branch or other stuff? |
| 16:29.21 | d_rossberg | with other stuff |
| 17:31.40 | CIA-43 | BRL-CAD: 03brlcad * r42081 10/brlcad/trunk/src/libged/ (38 files): massive quantities of quellage. size_t upgrades, unused params, exact floating point comaprisons, and more. 300+ fixes. oh my. |
| 17:33.15 | *** join/#brlcad mafm_ (~mafm@134.Red-83-35-148.dynamicIP.rima-tde.net) | |
| 17:38.53 | CIA-43 | BRL-CAD: 03starseeker * r42082 10/brlcad/branches/cmake/CMakeLists.txt: |
| 17:38.53 | CIA-43 | BRL-CAD: Take the first steps to 'properly' handle CMAKE_INSTALL_PREFIX and the issue of |
| 17:38.54 | CIA-43 | BRL-CAD: find_package searching in it when cmake is re-run. Don't really want to |
| 17:38.54 | CIA-43 | BRL-CAD: manhandle CMAKE_INSTALL_PREFIX any more than we have to, so try this. |
| 18:01.41 | DX^ | I hate modeling |
| 18:01.45 | DX^ | thank god for CAD operators |
| 18:26.21 | CIA-43 | BRL-CAD: 03starseeker * r42083 10/brlcad/branches/cmake/src/tclscripts/CMakeLists.txt: Try explicit copy and remove steps - apparently rename causes some issue with NFS, let's see if it's specific to rename |
| 18:36.44 | CIA-43 | BRL-CAD: 03starseeker * r42084 10/brlcad/branches/cmake/ (4 files in 4 dirs): Try to migrate more towards standard CMake variables - BRLCAD_PREFIX should now be only for the purposes of removal from find_package search paths. |
| 19:01.22 | *** join/#brlcad merzo (~merzo@53-11-94-178.pool.ukrtel.net) | |
| 20:04.10 | *** join/#brlcad AlecTaylor (~Tauk@unaffiliated/alectaylor) | |
| 20:11.51 | brlcad | AlecTaylor: welcome back |
| 20:12.24 | brlcad | AlecTaylor: if you'd waited 10 more minutes, I had this up right after you left: http://brlcad.org/tmp/stand.png |
| 20:42.44 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 20:50.29 | AlecTaylor | brlcad: Perfect! |
| 20:50.30 | AlecTaylor | Thanks |
| 20:55.03 | AlecTaylor | has never been happier about setting up his auto-connect! |
| 20:55.32 | AlecTaylor | brlcad: Would you be able to share the actual CAD file? |
| 21:20.47 | CIA-43 | BRL-CAD: 03brlcad * r42085 10/brlcad/trunk/src/conv/g-xxx.c: |
| 21:20.47 | CIA-43 | BRL-CAD: refactor the example converter to leave all of the more advanced and deprecated |
| 21:20.48 | CIA-43 | BRL-CAD: primitives as an exercise to the reader since we don't actually do anything with |
| 21:20.48 | CIA-43 | BRL-CAD: the object variables pulled from the idb_ptr. quell remaining warnings too. |
| 21:21.06 | brlcad | AlecTaylor: it's in that same directory |
| 21:22.03 | brlcad | AlecTaylor: and a word of caution, I didn't really use any best practices or structure the geometry in any way, just made a shape approximation to your sketch |
| 21:23.08 | CIA-43 | BRL-CAD: 03brlcad * r42086 10/brlcad/trunk/src/librt/db_path.c: off_t's may be signed, accommodate. |
| 21:26.37 | CIA-43 | BRL-CAD: 03erikgreenwald * r42087 10/brlcad/trunk/src/adrt/ (38 files in 3 dirs): favor direct struct use instead of hiding them behind a typedef. |
| 21:38.02 | CIA-43 | BRL-CAD: 03brlcad * r42088 10/brlcad/trunk/ (3 files in 2 dirs): make ars parameters be unsigned size_t types as well. |
| 21:38.51 | CIA-43 | BRL-CAD: 03brlcad * r42089 10/brlcad/trunk/src/adrt/libtie/tie.c: eliminate exact floating point comaprison |
| 21:39.12 | CIA-43 | BRL-CAD: 03brlcad * r42090 10/brlcad/trunk/src/adrt/libtie/tie_kdtree.c: quell warnings on 'index' and undefined preprocs. |
| 22:15.40 | CIA-43 | BRL-CAD: 03brlcad * r42091 10/brlcad/trunk/src/adrt/adrt.h: unused variables, dunno if safe to remove |
| 22:15.58 | CIA-43 | BRL-CAD: 03brlcad * r42092 10/brlcad/trunk/src/adrt/librender/render_internal.h: remove trailing semi so uses have to have semi. quiets warnings about ISO C not allowing floating semis outside of functions. |
| 22:17.37 | CIA-43 | BRL-CAD: 03brlcad * r42093 10/brlcad/trunk/src/adrt/load.c: static init no-go |
| 22:18.24 | CIA-43 | BRL-CAD: 03brlcad * r42094 10/brlcad/trunk/src/adrt/ (load.h load_g.c): remove unused dlen param, mark other unused params. |
| 22:32.42 | CIA-43 | BRL-CAD: 03brlcad * r42095 10/brlcad/trunk/src/adrt/librender/camera.c: |
| 22:32.43 | CIA-43 | BRL-CAD: ouch, tricky one. ISO C doesn't actually permit dlsym() to work the way it |
| 22:32.43 | CIA-43 | BRL-CAD: works with the need to convert a void* to a function pointer so the compiler has |
| 22:32.44 | CIA-43 | BRL-CAD: to be cajouled. we trick it with a cast through an intptr_t, which is a type |
| 22:32.44 | CIA-43 | BRL-CAD: big enough to hold a pointer address, albeit not necessarily a function pointer. |
| 22:32.45 | CIA-43 | BRL-CAD: the rest of the changes are just consistency with the callback mechanism type |
| 22:32.45 | CIA-43 | BRL-CAD: returning an int and constness. |
| 22:33.15 | ``Erik_ | ffffu |
| 22:38.04 | CIA-43 | BRL-CAD: 03erikgreenwald * r42096 10/brlcad/trunk/src/adrt/ (30 files in 3 dirs): major migration to use significantly more vmath types/macros |
| 22:42.44 | brlcad | ``Erik: heh, hope that's not causing too much grief |
| 22:42.56 | ``Erik | a few conflicts |
| 22:43.03 | brlcad | you enabled strict in there, so my build's busted -- it was either fix em or turn it back off |
| 22:44.21 | ``Erik | hm, which compiler? it works for me on fbsd (gcc4.2.1), linux (gcc4.1.2, mac (gcc4.2.1) and win32(msvc80 |
| 22:44.25 | ``Erik | s/0$/)/ |
| 22:45.01 | ``Erik | anyways, I think I'm done with it for the night, all committed up O.o |
| 22:45.11 | brlcad | hermes is failing |
| 22:45.50 | brlcad | gcc 4.1.2 linux |
| 22:46.04 | brlcad | maybe you didn't --enable-warnings (goes hand-in-hand with STRICT_FLAGS) |
| 22:53.14 | CIA-43 | BRL-CAD: 03brlcad * r42097 10/brlcad/trunk/src/adrt/ (13 files in 2 dirs): mark a bunch of unused params |
| 22:55.56 | brlcad | looks like your only parially done with the migration? the render work() function takes a TIE_3* but you're passing it vect_t* (camera.c:511) |
| 23:05.30 | CIA-43 | BRL-CAD: 03brlcad * r42098 10/brlcad/trunk/src/adrt/Makefile.am: looks like just few warnings remaining (be sure to --enable-warnings), about 65 on 64-bit linux, but saving them for later to minimize conflict. remove strict_flags in the meantime. |
| 23:18.36 | brlcad | now you'll get 'em |
| 23:18.57 | CIA-43 | BRL-CAD: 03brlcad * r42099 10/brlcad/trunk/configure.ac: |
| 23:18.58 | CIA-43 | BRL-CAD: now that more than 2/3rds of the package compiles completely free of warnings, |
| 23:18.58 | CIA-43 | BRL-CAD: go ahead and make verbose warnings the default. fully sync the warning flags |
| 23:18.59 | CIA-43 | BRL-CAD: with strict so if strict is enabled, you're getting everything that |
| 23:18.59 | CIA-43 | BRL-CAD: --enable-warnings was providing along with -Werror. |
| 23:25.12 | CIA-43 | BRL-CAD: 03brlcad * r42100 10/brlcad/trunk/src/conv/ (24 files in 9 dirs): |
| 23:25.13 | CIA-43 | BRL-CAD: this huge update represents the remainder compilation quieting of all the |
| 23:25.13 | CIA-43 | BRL-CAD: converters. missing params, exact floating point comparisons, shadowed |
| 23:25.38 | CIA-43 | BRL-CAD: variables, unused params, long string literals, signedness mismatching, size_t |
| 23:25.38 | CIA-43 | BRL-CAD: updates and more so that STRICT_BUILD works clean (on Mac gcc 4.0.1). several |
| 23:25.38 | CIA-43 | BRL-CAD: days to complete, more than 1300 (minor) changes. |
| 23:45.29 | ``Erik | hm, I had the flags in the compile lines, odd *shrug* I'll dig into it some more tomorrow |
| 23:47.44 | CIA-43 | BRL-CAD: 03brlcad * r42101 10/brlcad/trunk/src/other/openNURBS/ (7 files): |
| 23:47.44 | CIA-43 | BRL-CAD: the ON_OBJECT_IMPLEMENT() and ON_VIRTUAL_OBJECT_IMPLEMENT() macros are followed |
| 23:47.45 | CIA-43 | BRL-CAD: in code with semicolons so the macro itself needs to end with a statement that |
| 23:47.45 | CIA-43 | BRL-CAD: requires a semicolon. a simple reordering of the first line suffices. |
| 23:47.46 | CIA-43 | BRL-CAD: remainder of fixes are stray semicolons mysteriously following functions. |
| 00:06.04 | CIA-43 | BRL-CAD: 03johnranderson * r42102 10/brlcad/trunk/src/libbu/simd.c: Since we are using -Wundef option, we must use defined( __SSE__ ) |
| 00:32.49 | CIA-43 | BRL-CAD: 03brlcad * r42103 10/brlcad/trunk/src/libbn/bntester.c: init vars. potential for function_num and test_case_line_num to be accessed without initialization |
| 00:33.08 | CIA-43 | BRL-CAD: 03brlcad * r42104 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: trailing comma at end of enumerator list makes gcc unhappy |
| 00:33.59 | brlcad | ``Erik: --enable-warnings (before r42099) had two or three extra warnings that weren't enabled by default |
| 00:45.23 | CIA-43 | BRL-CAD: 03brlcad * r42105 10/brlcad/trunk/src/libbn/bntester.c: (log message trimmed) |
| 00:45.24 | CIA-43 | BRL-CAD: this is a really tricky one. quell warnings about variables getting clobbered |
| 00:45.24 | CIA-43 | BRL-CAD: after a longjmp or vfork by making them all static. we can do this here because |
| 00:45.50 | CIA-43 | BRL-CAD: they're all just main() variables fortunately. bu's jump mechanism uses |
| 00:45.51 | CIA-43 | BRL-CAD: setjump, so an implementation could clobber local non-static non-volatile |
| 00:45.51 | CIA-43 | BRL-CAD: variables. this tricking making them static works or it would have also worked |
| 00:45.51 | CIA-43 | BRL-CAD: to wrap the BU_SETJUMP/BU_UNSETJUMP calls into functions that are passed |
| 00:59.50 | CIA-43 | BRL-CAD: 03brlcad * r42107 10/brlcad/trunk/src/libbu/simd.c: no guarantee that __GNUC__ will be defined either. |
| 00:59.52 | CIA-43 | BRL-CAD: 03brlcad * r42106 10/brlcad/trunk/src/conv/ (3 files in 2 dirs): |
| 00:59.53 | CIA-43 | BRL-CAD: behold the annoyance of -pedantic. believe it or not, even for ISO C++, |
| 00:59.54 | CIA-43 | BRL-CAD: variable sized arrays are but a mere gcc extension. if you want variable-sized, |
| 00:59.55 | CIA-43 | BRL-CAD: you either have to new/delete/malloc/free (bleh) or leverage std::vector |
| 00:59.56 | CIA-43 | BRL-CAD: templatization. the latter is fortunately a trivial declaration tweak and the |
| 00:59.57 | CIA-43 | BRL-CAD: rest should behave accordingly. |
| 00:59.59 | CIA-43 | BRL-CAD: 03starseeker * r42108 10/brlcad/branches/cmake/TODO.cmake: Sigh. Update the TODO list for CMake with more known items. |
| 01:02.34 | *** join/#brlcad crazy_imp (~mj@a89-182-195-57.net-htp.de) | |
| 01:06.40 | CIA-43 | BRL-CAD: 03starseeker * r42109 10/brlcad/branches/cmake/CMakeLists.txt: Want to set to /usr/brlcad as default instead of the CMake default. |
| 01:12.02 | CIA-43 | BRL-CAD: 03brlcad * r42110 10/brlcad/trunk/src/conv/iges/ (g-iges.c main.c usage.c): more string literals that are way too long. convert to usage() functions. |
| 01:12.26 | CIA-43 | BRL-CAD: 03brlcad * r42111 10/brlcad/trunk/src/conv/comgeom/tools.c: curious one, untested. |
| 01:13.56 | CIA-43 | BRL-CAD: 03brlcad * r42112 10/brlcad/trunk/src/vdeck/vdeck.c: more size_t |
| 01:19.21 | CIA-43 | BRL-CAD: 03brlcad * r42113 10/brlcad/trunk/NEWS: john added support for comments as the first line(s) of a .asc file. previously was using title/units as keywords to recognize a .asc file, now it's the first non-comment line that has to have a title/units command. |
| 01:27.21 | CIA-43 | BRL-CAD: 03starseeker * r42114 10/brlcad/branches/cmake/ (45 files in 45 dirs): Generalize the INSTALL_* variables - gives a parent project the chance to do its own setting, in principle, without having to use the BRLCAD specific variables. Not sure how useful it really is, but why not. |
| 01:28.16 | CIA-43 | BRL-CAD: 03starseeker * r42115 10/brlcad/branches/cmake/TODO.cmake: reminder - need to rework SCL CMake logic |
| 01:30.28 | CIA-43 | BRL-CAD: 03starseeker * r42116 10/brlcad/branches/cmake/src/libbu/CMakeLists.txt: Add timer.c to libbu CMakeLists.txt file |
| 01:45.26 | CIA-43 | BRL-CAD: 03starseeker * r42117 10/brlcad/branches/cmake/src/tclscripts/ (hv3/pkgIndex.tcl hv3/tclIndex swidgets/scripts/tclIndex): Add back in some of the tclIndex and pkgIndex files - this should all go when CMake becomes mainline, but for now put them back to avoid difference with trunk. |
| 01:46.27 | CIA-43 | BRL-CAD: 03brlcad * r42118 10/brlcad/trunk/ (6 files in 5 dirs): |
| 01:46.28 | CIA-43 | BRL-CAD: differentiate BU_PTBL_LEN() from BU_PTBL_END() such that the prior is not a |
| 01:46.28 | CIA-43 | BRL-CAD: valid lvalue. this makes it more appropriate for loop testing and can be an |
| 01:46.29 | CIA-43 | BRL-CAD: unsigned type instead of the potentially signed off_t offset type of the |
| 01:46.29 | CIA-43 | BRL-CAD: underlying struct member. update references accordingly. |
| 01:48.48 | CIA-43 | BRL-CAD: 03starseeker * r42119 10/brlcad/branches/cmake/ (37 files in 14 dirs): Update cmake branch to trunk r42052. This is known to be a non-working CMake state, but this sync is being done in stages to avoid some conflicts from the trunk CMakeLists.txt files. |
| 01:55.04 | CIA-43 | BRL-CAD: 03brlcad * r42120 10/brlcad/trunk/src/ (5 files in 4 dirs): more quieting of the compilation |
| 01:58.46 | CIA-43 | BRL-CAD: 03starseeker * r42121 10/brlcad/branches/cmake/ (197 files in 44 dirs): Update cmake branch to trunk r42119 |
| 02:33.16 | CIA-43 | BRL-CAD: 03starseeker * r42122 10/brlcad/branches/cmake/ (7 files in 6 dirs): Update cmake branch to trunk r42120 |
| 02:58.06 | CIA-43 | BRL-CAD: 03starseeker * r42123 10/brlcad/branches/cmake/ (CMakeLists.txt misc/CMake/BRLCAD_Util.cmake): Tweaks - seems to produces better results for make package. |
| 03:12.51 | CIA-43 | BRL-CAD: 03starseeker * r42124 10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: Add the deprecated Tcl/Tk vars into the handle-standard-args logic - they apparently aren't visible to other projects otherwise. |
| 03:27.43 | CIA-43 | BRL-CAD: 03starseeker * r42125 10/brlcad/branches/cmake/TODO.cmake: Tweaks to settings seem to have CPack behaving better - need to study results a lot more, but at least the bin directory has more than a couple dozen binaries now. |
| 03:29.07 | CIA-43 | BRL-CAD: 03brlcad * r42126 10/brlcad/trunk/src/conv/dxf/dxf-g.c: init vars before testing |
| 03:33.24 | CIA-43 | BRL-CAD: 03brlcad * r42127 10/brlcad/trunk/src/conv/g-acad.c: |
| 03:33.25 | CIA-43 | BRL-CAD: massive restructure in order to fix a bug assuming that variables are accessible |
| 03:33.25 | CIA-43 | BRL-CAD: after a longjmp. quite a chore to quell the warning due to a bug in pre 4.3 |
| 03:33.26 | CIA-43 | BRL-CAD: gcc, but seems to be possible to quiet the warning if we start a new frame (and |
| 03:33.26 | CIA-43 | BRL-CAD: don't access the var/arg after that call). some testing, seems to work. |
| 03:33.55 | CIA-43 | BRL-CAD: 03brlcad * r42128 10/brlcad/trunk/src/conv/Makefile.am: not quite intentional to enable strict in here just yet. -pedantic is a bitch. |
| 04:17.10 | CIA-43 | BRL-CAD: 03brlcad * r42129 10/brlcad/trunk/src/librt/primitives/bot/bot.c: off-by-one copypaste typo. 2, not k. |
| 04:32.48 | CIA-43 | BRL-CAD: 03starseeker * r42130 10/brlcad/branches/cmake/CMakeLists.txt: Tweak generator list, vars for CPack |
| 04:33.57 | CIA-43 | BRL-CAD: 03starseeker * r42131 10/brlcad/branches/cmake/src/other/ (tcl/doc/install_man.cmake.in tk/doc/install_man.cmake.in): the Tcl/Tk man page script was installing to CMAKE_INSTALL_DIR even during make package - make it respect DESTDIR if it's set. |
| 04:56.43 | starseeker | hmm... that won't do either, CPack ignores those man pages as not being from a target |
| 05:03.26 | *** join/#brlcad Stattrav (~Stattrav@122.172.16.143) | |
| 05:03.32 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:29.12 | CIA-43 | BRL-CAD: 03starseeker * r42132 10/brlcad/branches/cmake/src/other/ (4 files in 2 dirs): Make another stab at the Tcl/Tk man pages, this time doing the generation up front and using FILE(GLOB to grab the results and put them into install targets. |
| 05:35.57 | CIA-43 | BRL-CAD: 03starseeker * r42133 10/brlcad/branches/cmake/src/other/ (tcl/doc/CMakeLists.txt tk/doc/CMakeLists.txt): |
| 05:35.58 | CIA-43 | BRL-CAD: Only do the generation once. If we really want to do this right we need some |
| 05:35.59 | CIA-43 | BRL-CAD: kind of custom commands, targets, output files to signify completed commands, |
| 05:35.59 | CIA-43 | BRL-CAD: etc - not worth it, and this avoids repeated processing we don't need. |
| 05:50.14 | CIA-43 | BRL-CAD: 03starseeker * r42134 10/brlcad/branches/cmake/src/other/tcl/CMakeLists.txt: Tcl link workaround isn't working for make package - need to re-examine. |
| 05:54.07 | CIA-43 | BRL-CAD: 03starseeker * r42135 10/brlcad/branches/cmake/src/other/tcl/doc/CMakeLists.txt: Arrrrgh - make package is still not grabbing these files. May have to go all out with custom commands and targets. |
| 07:26.22 | *** join/#brlcad AlecTaylor (~Tauk@unaffiliated/alectaylor) | |
| 09:54.50 | *** join/#brlcad mafm_ (~mafm@166.Red-83-45-72.dynamicIP.rima-tde.net) | |
| 11:38.09 | DaveLo | Mernin! Anyone at work yet? |
| 13:36.40 | CIA-43 | BRL-CAD: 03d_rossberg * r42136 10/brlcad/trunk/misc/win32-msvc/Dll/BrlcadCore.def: added bu_vls_trunc2() for asc2g conversion program |
| 13:40.40 | starseeker | hmm... KDE on Windows |
| 13:41.06 | starseeker | is intrigued, but hesitates to mess with his Windows partition too much because it would be hard to fix |
| 13:46.02 | starseeker | huh - kinda looks like bzflag with some enhancements: http://www.ubuntugamer.com/2011/01/zero-ballistics-a-rather-addictive-native-3d-tank-shooter/ |
| 13:51.15 | *** join/#brlcad mafm (~mafm@166.Red-83-45-72.dynamicIP.rima-tde.net) | |
| 13:52.13 | CIA-43 | BRL-CAD: 03starseeker * r42137 10/brlcad/branches/cmake/src/other/ (tcl/doc/CMakeLists.txt tk/doc/CMakeLists.txt): Ah, was shooting myself in the foot. We only GENERATE the man pages once, but we add them to the INSTALL list every time cmake is run. |
| 14:04.21 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 14:15.09 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 14:36.21 | CIA-43 | BRL-CAD: 03starseeker * r42138 10/brlcad/branches/cmake/CMakeLists.txt: |
| 14:36.22 | CIA-43 | BRL-CAD: Small change, but important for CPack packages - don't use absolute dirs as |
| 14:36.22 | CIA-43 | BRL-CAD: targets for install, which allows CPack to put things in the package without |
| 14:36.23 | CIA-43 | BRL-CAD: hard-coding the prefix (in essence building a subdirectory structure inside the |
| 14:36.23 | CIA-43 | BRL-CAD: archive |
| 14:55.59 | CIA-43 | BRL-CAD: 03starseeker * r42139 10/brlcad/branches/cmake/src/ (7 files in 7 dirs): |
| 14:56.00 | CIA-43 | BRL-CAD: Strip out more absolute paths for installs. The src/other/step directory isn't |
| 14:56.00 | CIA-43 | BRL-CAD: with the program yet, but that needs major cleanup anyway so leave it for now. |
| 14:56.01 | CIA-43 | BRL-CAD: Probably shouldn't be hardcoding bin and lib in as DESTINATIONS, may want to do |
| 14:56.01 | CIA-43 | BRL-CAD: a sweep for that too. |
| 15:02.21 | brlcad | starseeker: have you looked at tom's crash? have a question on tedit for you |
| 15:03.17 | brlcad | what's the intent around line 986 where it calls: editor = bu_which(EMACS_EDITOR); if (!strcmp(editor, bu_which(EMACS_EDITOR)) ... |
| 15:03.54 | d_rossberg | i could reproduce the crash, now i'm looking for a work-around |
| 15:04.15 | brlcad | d_rossberg: I have a simplistic fix for the crash that at least avoid strcmp() |
| 15:05.53 | CIA-43 | BRL-CAD: 03brlcad * r42140 10/brlcad/trunk/src/mged/tedit.c: |
| 15:05.54 | CIA-43 | BRL-CAD: strcmp() doesn't like NULL and bu_which() may produce NULL, so don't feed the |
| 15:05.54 | CIA-43 | BRL-CAD: output of the latter directly into the prior. should at least avoid the |
| 15:05.55 | CIA-43 | BRL-CAD: specific crash reported by tom browder to the devel mailing list, albeit |
| 15:05.55 | CIA-43 | BRL-CAD: probably not the full fix needed. |
| 15:09.27 | starseeker | brlcad: ah, thanks - I neglected to check if strcmp would handle null. Looks like it's platform dependent, and therefore not to be relied on |
| 15:11.03 | brlcad | there's not many stdc calls that can be trusted to accept null, even ones that are documented to accept null |
| 15:11.17 | d_rossberg | on Windows strcmp(0) will crash |
| 15:13.02 | CIA-43 | BRL-CAD: 03starseeker * r42141 10/brlcad/branches/cmake/src/archer/CMakeLists.txt: Archer's CMakeLists.txt file needs a lot of love to make it work in the build dir - these are just the first tweaks, lots more will be needed. |
| 15:13.02 | starseeker | sigh |
| 15:13.25 | starseeker | launching an editor from C code really seems to be a pain |
| 15:13.32 | brlcad | I believe posix strcmp() is undefined if passed a null anyways, so crashing is acceptable behavior |
| 15:13.45 | d_rossberg | whot do you think about a bu_strcmp()? |
| 15:14.27 | brlcad | you mean adding one? |
| 15:14.45 | d_rossberg | yes |
| 15:15.16 | starseeker | d_rossberg: (bty - more to be done, but hopefully CMAKE_INSTALL_PREFIX will behave more normally now and you won't need BRLCAD_PREFIX anymore." |
| 15:15.41 | starseeker | leftover garbage from early in the learning process |
| 15:15.44 | d_rossberg | strcmp() is really annoying |
| 15:17.49 | starseeker | gets ready to head in... |
| 15:17.56 | CIA-43 | BRL-CAD: 03starseeker * r42142 10/brlcad/branches/cmake/TODO.cmake: Add note about archer to TODO.cmake |
| 15:18.08 | d_rossberg | starseeker: i've still the problem of huge rebuilds ... |
| 15:21.25 | brlcad | d_rossberg: bu_strcmp() and/or bu_strlcmp() would be good additions to make given there is already bu_str(lcat|lcpy|dup) |
| 15:21.44 | brlcad | starseeker: any insight on that question? |
| 15:22.15 | d_rossberg | brlcad: i'm already working on it |
| 15:22.27 | starseeker | brlcad: the strcmp or the rebuilds? |
| 15:22.35 | brlcad | what's the intent around line 986 where it calls: editor = bu_which(EMACS_EDITOR); if (!strcmp(editor, bu_which(EMACS_EDITOR)) ... |
| 15:22.46 | brlcad | now line 904 or something |
| 15:23.18 | brlcad | it sets editor to the path to emacs, then checks if editor is .. the path to emacs |
| 15:23.33 | starseeker | looks... |
| 15:24.16 | brlcad | I added the "(editor &&" part just to check the result from bu_which .. wasn't there before |
| 15:24.24 | brlcad | *just* added it in the last commit |
| 15:24.33 | brlcad | d_rossberg: okay, cool |
| 15:26.52 | starseeker | I believe what was going on there was a check (once in classic mode) to see if any of the known editor configurations that would work in classic mode were viable |
| 15:27.30 | brlcad | I think I see that, but those two specific lines don't make sense to me |
| 15:28.22 | starseeker | um. |
| 15:28.28 | starseeker | yeah, not sure what was going on there |
| 15:28.40 | starseeker | that strcmp does look kinda pointless |
| 15:29.16 | starseeker | I think you have the right answer |
| 15:29.20 | brlcad | well what I'm reading is that IF you have emacs, then all of the other editor tests will fail |
| 15:29.26 | brlcad | which maybe was the intent |
| 15:29.31 | d_rossberg | brlcad: there is no strlcmp |
| 15:29.41 | brlcad | d_rossberg: I meant to write one :) |
| 15:30.13 | starseeker | brlcad: probably it was something like that |
| 15:30.21 | brlcad | with similar intent of the strlcpy functions, strlcmp checks for null, maybe has a length specifier |
| 15:30.33 | d_rossberg | there are strl*() functions for writing on buffers only |
| 15:31.47 | brlcad | okay |
| 15:32.19 | brlcad | fair enough, it was just a thought for consistency with our own bu functions, but matching the replacement is probably more important |
| 15:32.44 | ``Erik | now that's a lot of breakage |
| 15:33.13 | starseeker | brlcad: I think I may have some rather convoluted logic there - I'm not sure what the whole idea was with the count thing |
| 15:33.21 | brlcad | I could see bu also providing a BU_STREQ() macro so that all of the equality testing could be simplified consistent |
| 15:34.12 | brlcad | starseeker: yeah, that is pretty funky ... search for everything, then if you found anything, search for something |
| 15:34.46 | starseeker | oh, wait |
| 15:35.11 | starseeker | I think I might have been looking to see if a preset editor from above was a potential bad case for classic mode |
| 15:35.43 | starseeker | looks at the previous revision of the code |
| 15:36.05 | brlcad | hm, maybe if(BU_EQUALS(str1, str2)) or if (BU_EQUAL_STR(str1, str2)) |
| 15:36.55 | starseeker | yeah, that was it |
| 15:36.57 | ``Erik | using vls's? |
| 15:37.07 | brlcad | there are approximately 1418 calls to strcmp() in the code |
| 15:38.12 | starseeker | brlcad: the idea was to check the editor variable to spot cases which might be a problem, and if it WAS a problem case then force-feed it something known to be safe |
| 15:38.58 | starseeker | so it blew up due to the bu_which finding nothing to compare editor TO |
| 15:39.17 | brlcad | right |
| 15:39.36 | brlcad | so then my fix should, in theory, work and fall through correctly |
| 15:39.38 | starseeker | so your fix is actually correct |
| 15:39.41 | starseeker | yes :-) |
| 15:39.59 | starseeker | shudders in memory - that was a long night sorting all that logic out |
| 15:41.08 | brlcad | those first two lines inside the if (count > 0) block still don't make sense though |
| 15:41.39 | brlcad | because editor = bu_which(EMACS_EDITOR) will have unlikely changed between the first and second lines.. :) |
| 15:41.47 | starseeker | right :-) |
| 15:42.20 | starseeker | I think that was brain-overload coding - it functioned, so go with it |
| 15:42.28 | starseeker | removes the stray strcmp |
| 15:42.49 | brlcad | did you actually see "editor[0] == '\0'" ? |
| 15:43.02 | starseeker | uh - don't recall |
| 15:43.04 | brlcad | bu_which() certainly shouldn't be returning that -- could even test for that |
| 15:43.11 | brlcad | (in bu_which()) |
| 15:43.25 | starseeker | probably not - I think it was more stupidity on my part |
| 15:46.16 | CIA-43 | BRL-CAD: 03brlcad * r42143 10/brlcad/trunk/src/libbu/ (whereis.c which.c): add code to make sure, even though it's a very unlikely event, that we never return an empty string. |
| 15:46.18 | CIA-43 | BRL-CAD: 03starseeker * r42144 10/brlcad/trunk/src/mged/tedit.c: |
| 15:46.18 | CIA-43 | BRL-CAD: We can trust bu_wish not to return \0, so we don't need that check there. May |
| 15:46.24 | CIA-43 | BRL-CAD: not need it anywhere, but we are getting returns from other functions early on |
| 15:46.24 | CIA-43 | BRL-CAD: so would need more careful checking. Also remove the useless strcmp for editor |
| 15:46.24 | CIA-43 | BRL-CAD: just after setting it to emacs. |
| 15:47.05 | starseeker | brlcad: uh, it's close to a certainty that my brain said "check for an empty char array here" and did something colossally stupid - I doubt bu_which is at fault |
| 15:48.10 | brlcad | starseeker: it's still a reasonable "guarantee" that bu_which() should be able to say, NULL if not found, non-NULL non-empty if found |
| 15:48.17 | starseeker | has been doing too much build logic... s/bu_wish/bu_which |
| 15:48.35 | starseeker | cool |
| 15:52.34 | starseeker | does head in this time... |
| 15:52.49 | d_rossberg | i like the NULL as a return value because i haven't to provide memory for it |
| 15:57.04 | CIA-43 | BRL-CAD: 03brlcad * r42145 10/brlcad/trunk/src/conv/iges/iges.c: make sure initd before use, compiler doesn't see the bu_bomb(). |
| 15:58.29 | CIA-43 | BRL-CAD: 03brlcad * r42146 10/brlcad/trunk/src/conv/ (euclid/g-euclid.c iges/g-iges.c): restructure exception handling into try/catch form |
| 16:07.55 | CIA-43 | BRL-CAD: 03d_rossberg * r42147 10/brlcad/trunk/ (include/bu.h src/libbu/str.c): |
| 16:07.56 | CIA-43 | BRL-CAD: introduced bu_strcmp() with a more graceful string comparison as strcmp() does |
| 16:07.56 | CIA-43 | BRL-CAD: "" and NULL are considered as equal |
| 16:08.08 | d_rossberg | i've always wanted to do that |
| 16:25.11 | CIA-43 | BRL-CAD: 03d_rossberg * r42148 10/brlcad/trunk/include/bu.h: |
| 16:25.12 | CIA-43 | BRL-CAD: the BU_STR_EMPTY() macro tests a string for emptiness ("" or NULL) |
| 16:25.13 | CIA-43 | BRL-CAD: its result is either true or false |
| 16:43.19 | CIA-43 | BRL-CAD: 03brlcad * r42149 10/brlcad/trunk/src/conv/iges/ (91 files): cleanup of the old and new iges codes. ws, consistency, de-k&r, indent, authorship, etc. |
| 16:47.55 | brlcad | starseeker: I take it back, the old iges code is so much more extensive than the new that it'd be just ridiculous to dump it for the new one |
| 16:48.25 | brlcad | the new one does have some nice stucture to it, but it's so devoid of implementation that it seems better just because there is so little complexity (or value) involved |
| 16:56.52 | CIA-43 | BRL-CAD: 03brlcad * r42150 10/brlcad/trunk/include/bu.h: (log message trimmed) |
| 16:56.53 | CIA-43 | BRL-CAD: follow suit and provide another BU_STR_EQUAL() macro for comparing two strings |
| 16:56.53 | CIA-43 | BRL-CAD: for equality. this is similar to the STREQ recommendation by the ibm |
| 16:56.54 | CIA-43 | BRL-CAD: developerworks best practices article |
| 16:56.54 | CIA-43 | BRL-CAD: (http://www.ibm.com/developerworks/aix/library/au-hook_duttaC.html) so that |
| 16:56.55 | CIA-43 | BRL-CAD: developers can use equality as a truthfulness return value consistently. there |
| 16:57.09 | CIA-43 | BRL-CAD: are approximately 1400 present uses of strcmp() in BRL-CAD that can use this |
| 17:32.49 | starseeker | brlcad: so... gradually refactor the old code to use better structure and convert to the new nurbs? |
| 17:33.10 | starseeker | or I suppose do so as part of merging it into libgcv |
| 17:40.22 | CIA-43 | BRL-CAD: 03starseeker * r42151 10/brlcad/branches/cmake/ (102 files in 9 dirs): Update cmake branch to trunk r41250 |
| 17:45.29 | brlcad | starseeker: there is always possibility for better structure, particularly the bigger, older, and more complex code becomes ... so that's a given |
| 17:46.01 | brlcad | but yeah, merge in capability for new nurbs would probably be better -- it'll just be more costly up front to learn the existing code |
| 17:48.03 | brlcad | unrelated topic, the compiler is reporting that it cannot inline the opennurbs_ext BBNode bounding box routine (GetBBox()), so there is possibly some significant performance to be gained by fixing that |
| 18:06.55 | CIA-43 | BRL-CAD: 03starseeker * r42152 10/brlcad/branches/cmake/src/conv/iges/revolve.c: PI is coming up as undefined on OSX - use M_PI |
| 18:10.58 | CIA-43 | BRL-CAD: 03brlcad * r42153 10/brlcad/trunk/src/librt/opennurbs_ext.h: force inlining on the bounding box routines since gcc (4.0.1) complains that it cannot without increasing an inline limit. remove inline from destructors (gcc is similiarly complaining that it cannot). |
| 18:11.50 | CIA-43 | BRL-CAD: 03brlcad * r42154 10/brlcad/trunk/src/librt/ (bool.c comb/comb.c): sign matching |
| 18:32.42 | CIA-43 | BRL-CAD: 03erikgreenwald * r42155 10/brlcad/trunk/src/libbn/ (bntester.c poly.c tabdata.c): fix various warnings |
| 18:35.08 | CIA-43 | BRL-CAD: 03starseeker * r42156 10/brlcad/branches/cmake/src/other/tcl/ (4 files in 4 dirs): Start the process of taking things out of -D defines and putting them in config headers. |
| 18:48.27 | CIA-43 | BRL-CAD: 03starseeker * r42157 10/brlcad/branches/cmake/src/other/ (5 files in 5 dirs): |
| 18:48.27 | CIA-43 | BRL-CAD: more -D elimination - a lot of these defines probably aren't even needed in |
| 18:48.28 | CIA-43 | BRL-CAD: CMake builds, as they don't seem to be used by the C code and CMake is handling |
| 18:48.29 | CIA-43 | BRL-CAD: the generation of whatever config files are needed itself... for the ones that |
| 18:48.33 | CIA-43 | BRL-CAD: are, the only code change is to include the generated header. Definitely more |
| 18:48.33 | CIA-43 | BRL-CAD: cleanup to do on these to reduce the build logic to the functioning minimum. |
| 18:53.19 | CIA-43 | BRL-CAD: 03starseeker * r42158 10/brlcad/branches/cmake/CMakeLists.txt: Let's try a space on Windows again and see if those defines fixed it... |
| 18:59.41 | CIA-43 | BRL-CAD: 03brlcad * r42159 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: size_t |
| 19:00.09 | CIA-43 | BRL-CAD: 03brlcad * r42160 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: VMOVE before we print the value. |
| 19:01.24 | CIA-43 | BRL-CAD: 03brlcad * r42161 10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: init max_pt too, quell warning |
| 19:06.31 | CIA-43 | BRL-CAD: 03brlcad * r42162 10/brlcad/trunk/ (8 files in 2 dirs): make a slew of other object count struct data members be size_t instead of long and int so that can be properly unsigned and higher bound. match signedness in librt accordingly. |
| 19:14.49 | CIA-43 | BRL-CAD: 03brlcad * r42163 10/brlcad/trunk/src/ (9 files in 2 dirs): another BU_PTBL_LEN caller, size_t it up. |
| 19:17.10 | CIA-43 | BRL-CAD: 03brlcad * r42164 10/brlcad/trunk/include/bu.h: just call bu_strcmpm() directly instead of macro. didn't get the preproc syntax right anyways. |
| 19:26.35 | brlcad | is excited that we're SO CLOSE to a strict clean build! |
| 19:29.16 | brlcad | improved security, maintainability, conformance/verification/validation, .. yum |
| 19:34.56 | brlcad | envisions a day where the source code is completely 100% lintian free with best practices enforced across the entire 1M+ body of code |
| 19:37.36 | CIA-43 | BRL-CAD: 03brlcad * r42165 10/brlcad/trunk/src/conv/iges/revolve.c: didn't starseeker already fix this? M_PI is the new coke. |
| 19:39.50 | CIA-43 | BRL-CAD: 03brlcad * r42166 10/brlcad/trunk/src/conv/iges/iges.c: multicharacter string constants are not valid to cpp, so move the literal to a define in order to catch future auto-expansions |
| 20:23.25 | *** join/#brlcad ibot (~ibot@198.60.114.207) | |
| 20:23.25 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.0 is posted (20101209) || Happy Open Source Anniversary 2010-12-21 !!! Six years... | |
| 20:28.16 | CIA-43 | BRL-CAD: 03brlcad * r42170 10/brlcad/trunk/src/fb/pp-fb.c: init to zero pixels |
| 20:28.17 | CIA-43 | BRL-CAD: 03starseeker * r42169 10/brlcad/branches/cmake/CMakeLists.txt: Interesting - the -c option causes the time delta compile to fail. |
| 20:30.20 | CIA-43 | BRL-CAD: 03brlcad * r42173 10/brlcad/trunk/src/util/ (pc_test.c pixborder.c pixcount.c pixdsplit.c): more unset before use insanity. |
| 20:30.49 | CIA-43 | BRL-CAD: 03brlcad * r42174 10/brlcad/trunk/bench/pixcmp.c: test of conversion to BU_STR_EQUAL() instead of directly calling strcmp(). |
| 20:31.23 | DaveLo | getting an error in arbn.c: |
| 20:31.37 | DaveLo | primitives/arbn/arbn.c: In function ?rt_arbn_describe?: |
| 20:31.37 | DaveLo | primitives/arbn/arbn.c:1026: error: format ?%lu? expects type ?long unsigned int?, but argument 3 has type ?size_t? |
| 20:31.40 | DaveLo | primitives/arbn/arbn.c:1037: error: format ?%lu? expects type ?long unsigned int?, but argument 3 has type ?size_t? |
| 20:32.32 | ``Erik | lots of those |
| 20:32.33 | ``Erik | lots and lot |
| 20:32.34 | ``Erik | s |
| 20:33.48 | ``Erik | thinks he's about to get very involved with GS O>o |
| 20:33.54 | CIA-43 | BRL-CAD: 03erikgreenwald * r42175 10/brlcad/trunk/src/adrt/ (27 files in 3 dirs): warning quellage. formatting fixes. |
| 20:34.19 | DaveLo | what makes you say that? |
| 20:35.07 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 20:35.07 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.0 is posted (20101209) || Happy Open Source Anniversary 2010-12-21 !!! Six years... | |
| 20:35.10 | ``Erik | (k keeps building after failure) |
| 20:35.23 | ``Erik | or didja mean GS? |
| 20:35.58 | DaveLo | huh? |
| 20:36.21 | starseeker | what made him say what? |
| 20:36.33 | DaveLo | whos a what? |
| 20:36.40 | ``Erik | forshizzle? |
| 20:36.48 | DaveLo | forrizzle! |
| 20:40.58 | DaveLo | FYI: I was updating the repos on my Ubuntutututu box and ran into some size_t compile errors in brlcad |
| 20:41.27 | DaveLo | figured I'd mention it since brlcad is in the mist of some massive size_t work |
| 21:13.20 | CIA-43 | BRL-CAD: 03starseeker * r42176 10/brlcad/branches/cmake/src/tclscripts/CMakeLists.txt: Remove old files before making new ones... |
| 21:37.00 | CIA-43 | BRL-CAD: 03starseeker * r42177 10/brlcad/branches/cmake/src/other/ (6 files in 6 dirs): Remove all the -c flags from the Tcl/Tk builds |
| 21:40.31 | *** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de) | |
| 21:56.14 | brlcad | DaveLo: I've got a clean build on mac and linux, but size_t is going to be pretty sensitive to platform differences so some failures undoubtedly need weeding out |
| 21:56.29 | brlcad | should be trivial fixes, at least |
| 21:57.00 | brlcad | DaveLo: and --enable-warnings is now the default (as of yesterday) |
| 22:08.21 | CIA-43 | BRL-CAD: 03starseeker * r42178 10/brlcad/branches/cmake/CMakeLists.txt: For whatever reason, CMAKE_C_FLAGS is upsetting VC++ 2010 - comment it out |
| 22:15.44 | CIA-43 | BRL-CAD: 03erikgreenwald * r42179 10/brlcad/trunk/src/libfb/if_ogl.c: signed/unsigned comparison fixes |
| 22:41.39 | ``Erik | brlcad: if'n ya get bored, http://brlcad.org/~erik/r42179/ :D *heads home* |
| 22:49.49 | brlcad | heh |
| 22:49.52 | CIA-43 | BRL-CAD: 03brlcad * r42180 10/brlcad/trunk/src/libbu/CMakeLists.txt: sync timetester to cmake build for distcheck |
| 22:50.41 | starseeker | growls... CMake build doesn't run as of 42152 |
| 22:50.55 | starseeker | seems to run at 42150, confirming that |
| 22:51.15 | starseeker | what could possibly have changed... |
| 22:52.47 | brlcad | i've done so much fast typing for over a week now that my rsi is starting to act up |
| 22:53.08 | starseeker | winces - that's not good |
| 22:54.40 | brlcad | not too bad just yet, just having to take more breaks |
| 22:55.04 | brlcad | editing thousands of files will do that |
| 22:56.01 | brlcad | starseeker: i'd be cautious on any failure -- those size_t changes could easily have (and undoubtedly have in some places) caused a bug to get injected somewhere/anywhere |
| 22:56.19 | brlcad | along with the changes before I got on the size_t rampage even |
| 22:56.49 | starseeker | nods - I'm trying to isolate when it happend |
| 22:57.23 | starseeker | will cheerfully revert the source of cmake branch to a known good state and work on that, if he can find such a state |
| 23:02.53 | starseeker | OK, NOT working at 42150 |
| 23:09.52 | starseeker | 42139 working |
| 23:09.58 | starseeker | did that archer change mess things up somehow??? |
| 23:25.10 | CIA-43 | BRL-CAD: 03starseeker * r42181 10/brlcad/branches/cmake/src/archer/CMakeLists.txt: Hmm - this makes mged REALLY unhappy, so don't do it... |
| 23:26.46 | CIA-43 | BRL-CAD: 03brlcad * r42182 10/brlcad/trunk/src/mged/hideline.c: protect from peculiar setjmp() use in here by making the variables set before and accessed afterwards as static. candidate for removal. |
| 23:29.17 | CIA-43 | BRL-CAD: 03brlcad * r42183 10/brlcad/trunk/src/mged/dodraw.c: |
| 23:29.17 | CIA-43 | BRL-CAD: one of the more complicated ways to handle BU_SETJUMPing so that variables set |
| 23:29.18 | CIA-43 | BRL-CAD: before the jump and accessed afterwards do not have their values clobbered when |
| 23:29.18 | CIA-43 | BRL-CAD: a jump occurs. solution is to pull just exactly the try/catch code out into |
| 23:29.19 | CIA-43 | BRL-CAD: their own functions so there are no variables in that frame that might be |
| 23:29.19 | CIA-43 | BRL-CAD: clobbered in the first place. this is done twice here. |
| 23:29.52 | CIA-43 | BRL-CAD: 03brlcad * r42184 10/brlcad/trunk/src/mged/cmd.c: size_t upconvert argc |
| 23:30.17 | starseeker | O.o - that's some scary sounding logic - why are we need jumps like that, speed? |
| 23:30.51 | starseeker | breaths a sigh of relief - MGED runs again |
| 23:39.13 | CIA-43 | BRL-CAD: 03brlcad * r42185 10/brlcad/trunk/src/mged/rtif.c: wrong comment to the wrong file. protect from peculiar setjmp() use in here by making the variables set before and accessed afterwards as static. candidate for removal. |
| 23:39.56 | CIA-43 | BRL-CAD: 03brlcad * r42186 10/brlcad/trunk/src/mged/mged.c: make sure we have an out if we don't have an out. |
| 23:40.51 | CIA-43 | BRL-CAD: 03brlcad * r42187 10/brlcad/trunk/src/mged/ (cad_parea.c chgview.c clone.c): init vars before they're used, especially when they're only set within conditionals. |
| 23:42.19 | starseeker | heh 42186 sounds like Yogi Berra |
| 23:46.32 | CIA-43 | BRL-CAD: 03brlcad * r42188 10/brlcad/trunk/src/mged/cad_boundp.c: one more needing to be initialized |
| 23:47.46 | brlcad | starseeker: jumps are the old school way to perform exception handling |
| 23:48.11 | brlcad | c++'s exception handling was originally implemented using setjmp/longjmp and macros |
| 23:48.37 | brlcad | you just have to know what you're doing and what happens when a jump occurs |
| 23:49.02 | brlcad | some of our code was making assumptions which work in practice, but aren't guaranteed |
| 23:49.20 | starseeker | ah |
| 23:49.50 | brlcad | basically, IF a jump happens, variables are reset back to their state when the jumppoint was *set* .. so if you modify them after the set and then jump, their values are clobbered |
| 23:50.17 | brlcad | most of the time, that's perfectly fine |
| 23:51.03 | brlcad | and whether it's fine or not, doing the "wrap the try/catch" in a function trick makes the problem pretty much moot because there are no longer any stack variables getting clobbered |
| 23:51.52 | starseeker | nods |
| 23:53.17 | brlcad | I want to rewrite our macros so we're not setting and unsetting jumps, instead providing BU_TRY/BU_CATCH macros |
| 23:53.39 | starseeker | how many places in the code will that touch? |
| 23:56.28 | starseeker | worries about brlcad's wrists |
| 23:56.47 | brlcad | I don't remember how many places, not too many |
| 23:56.54 | starseeker | cool |
| 23:56.58 | brlcad | unfortunately not really scriptable though :) |
| 23:57.03 | starseeker | heh |
| 23:57.13 | brlcad | just scan on BU_SETJUMP though and you'll find them all |
| 23:58.32 | starseeker | popular in the convertors |
| 23:58.52 | brlcad | yep, nmg stuff throws exceptions as part of normal business |
| 23:59.43 | brlcad | BU_SETJUMP is the way to catch a bu_bomb() so it doesn't actually exit |
| 00:05.30 | CIA-43 | BRL-CAD: 03starseeker * r42189 10/brlcad/branches/cmake/src/tclscripts/ (18 files in 18 dirs): |
| 00:05.30 | CIA-43 | BRL-CAD: Alright, I'm tired of fighting with trying to get the custom tclscripts to run |
| 00:05.31 | CIA-43 | BRL-CAD: cleanly in parallel when they're doing copy commands after the btclsh script |
| 00:05.31 | CIA-43 | BRL-CAD: runs. Put copies of the tcl files in the build dir and run the scripts there. |
| 00:05.32 | CIA-43 | BRL-CAD: Simplifies the logic and avoids the hackery of copying things around as part of |
| 00:05.32 | CIA-43 | BRL-CAD: the custom command. |
| 00:06.20 | starseeker | mmm... bu_brlcad_data clearly isn't up to what I'm trying with archer... |
| 00:12.03 | brlcad | how so? |
| 00:12.15 | brlcad | it has a pretty well-defined usage contract |
| 00:12.53 | starseeker | it may just be I don't have the right things in place in the build dir |
| 00:13.29 | brlcad | if which in reality should end up in just one or two file/dir stats if everything is set up right, the rest of the logic being just for failure backup |
| 00:13.30 | starseeker | rror in startup script: couldn't read file "/usr/brlcad/share/tclscripts/itk_redefines.tcl": no such file or directory while executing |
| 00:13.33 | starseeker | "source [file join [bu_brlcad_data "tclscripts"] itk_redefines.tcl]" (file "./bin/archer" line 62) |
| 00:14.05 | starseeker | prefix isn't /usr/brlcad for this build either, but once I do a make install it finds things OK |
| 00:14.15 | brlcad | it shouldn't need to be /usr/brlcad |
| 00:14.21 | starseeker | right |
| 00:14.35 | brlcad | bu.h has the search priority ordering |
| 00:14.46 | starseeker | checks... |
| 00:15.01 | brlcad | first step is to make sure itk_redefines.tcl is actually in /usr/brlcad/share/brlcad/version/tclscripts/itk_redefines.tcl (or whatever your data root is) |
| 00:15.32 | brlcad | then can make sure bu_brlcad_data "." is reporting the data root just by running bwish |
| 00:15.48 | brlcad | then bu_brlcad_data "tclscripts" to make sure it's there, etc |
| 00:17.05 | brlcad | that looks right to me, the archer logic might be wrong |
| 00:17.59 | starseeker | weird... from the build directory it's returning /usr/brlcad/share/. but once installed it's /Users/user/brlcad-install-svn/share/. |
| 00:18.17 | starseeker | will look into it later, not a huge deal |
| 00:18.26 | starseeker | dunno if archer is even set up to run from the build dir at all |
| 00:18.59 | brlcad | if it cannot find it pre-install, it will fall back on /usr/brlcad where it's undoubtedly finding an old root |
| 00:19.13 | starseeker | ah |
| 00:19.17 | brlcad | http://pastebin.mozilla.org/930556 |
| 00:19.48 | starseeker | nods |
| 00:20.31 | brlcad | yeah, I'm not seeing that file anywhere |
| 00:20.47 | starseeker | yep - if I make a share directory, it finds it. That's also why that archer CMakeLists.txt change played such havoc with mged - it found a data dir with nothing in it |
| 00:21.17 | starseeker | brlcad: that file is specific to the CMake branch so far - it's what allows archer to run with vanilla Itcl/Itk |
| 00:21.31 | brlcad | ahh, okay |
| 00:22.10 | starseeker | it looks like if I want to do this right I'll have to fully populate the share dir in the build dir |
| 00:22.11 | brlcad | if you're working on pre-install build states and with partial empty install trees, you probably should familiarize with the search path rules it uses |
| 00:22.30 | starseeker | nods |
| 00:22.59 | starseeker | I don't recall ever trying - does archer run from the build dir in trunk? |
| 00:23.12 | starseeker | maybe I should worry about this later |
| 00:23.26 | brlcad | it has for me |
| 00:23.38 | starseeker | crud |
| 00:23.40 | brlcad | haven't tested latestly |
| 00:29.00 | CIA-43 | BRL-CAD: 03starseeker * r42190 10/brlcad/branches/cmake/TODO.cmake: Update TODO.cmake |
| 00:32.29 | brlcad | hm, looks like trunk has problems running uninstalled, but it's due to ... Tkhtml3 :) |
| 00:32.46 | starseeker | growl |
| 00:33.17 | starseeker | wonders what possessed him to ever fool with tkhtml... |
| 00:33.39 | brlcad | ah, looks like tktable too |
| 00:34.22 | brlcad | you can't just add dependencies and everything gets found -- you have to tell the code that looks for things where to look for the new things when they're added |
| 00:35.01 | starseeker | wants the computer to be smart, doggone it |
| 00:36.01 | brlcad | royal you, not you specifically :) |
| 00:36.11 | brlcad | not that you aren't royal |
| 00:36.12 | starseeker | ah :-) |
| 00:36.28 | starseeker | <- royal pain |
| 00:37.32 | starseeker | I'll dig into this, but it looks like studying usage of bu_brlcad_data will be the key - thanks! |
| 00:39.57 | brlcad | don't be shy to fix archer |
| 00:40.46 | starseeker | brlcad: I'm more concerned about the notion of a build-dir share directory and how it fits (or doesn't fit) with how bu_brlcad_root and bu_brlcad_data are working |
| 00:41.05 | brlcad | bu_brlcad_data/bu_brlcad_root *should* be suitable for any use .. there are lots of places in archer that probably don't use it yet or call it correctly |
| 00:42.12 | brlcad | there is no such notion to bu_brlcad_root/bu_brlcad_data other than to check the current directory |
| 00:42.20 | starseeker | the thing is, I'm going to want bu_brlcad_root to return the build directory root if I'm not running installed, but the installed root directory if I am |
| 00:42.28 | brlcad | the package require system is completely separate foo |
| 00:42.42 | starseeker | package require I'm getting a handle on |
| 00:43.34 | starseeker | I can already package require Tkhtml/tkpng/etc from ./bin/bwish |
| 00:44.16 | brlcad | an easy solution is to make the resources locatable w.r.t. archer |
| 00:44.41 | starseeker | nods |
| 00:45.15 | *** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net) | |
| 00:45.16 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 00:45.19 | starseeker | that itk_redefines.tcl file should probably fold straight into archer itself |
| 00:45.21 | brlcad | so if something does rely on bu_brlcad_data, calling bu_brlcad_data "tclscripts/archer" is going to find src/archer/tclscripts/archer or something similar |
| 00:45.57 | starseeker | um |
| 00:46.12 | brlcad | you build instal an uninstalled install root? |
| 00:46.51 | starseeker | basically - the build dir is a pseudo-install tree |
| 00:47.07 | brlcad | but are they only binaries or also data files? |
| 00:47.18 | brlcad | like tclscripts |
| 00:47.28 | starseeker | so far binaries, libraries and whatever tcl/tk stuff I've needed to get package require working |
| 00:47.48 | starseeker | I haven't rebuilt the tclscripts install dir yet, but even if I did I'm not sure it would work |
| 00:47.51 | brlcad | well that'd be most of our tclscripts dir too then |
| 00:48.41 | brlcad | our tclscripts dir has a slew of packages defined in there, package require Archer for example, package require GeometryBrowser, etc |
| 00:49.18 | starseeker | right - it was trying to get those working that I ran into the problem with a share dir in the toplevel build dir blowing up mged |
| 00:49.59 | starseeker | tclAutoPath has a bunch of paths for the tclscript dirs - I figured I could leverage that |
| 00:50.35 | brlcad | yeah, that's the separate system |
| 00:51.02 | brlcad | what about just making the build tree be an *exact* replica of the install tree? |
| 00:51.04 | starseeker | even copying the complete installed share dir from the install back into the build dir didn't make mged happy, which worries me |
| 00:51.24 | brlcad | so installing is literally the same as cp -R buildTree /usr/brlcad |
| 00:51.35 | starseeker | brlcad: that gets back to the bu_brlcad_root - in that instance, it would have to use the toplevel build dir as its root dir |
| 00:51.48 | starseeker | and it's not set up to do that right now, unless I'm missing something |
| 00:52.02 | starseeker | I could make it do that, but I figured I'd get in trouble :-P |
| 00:52.32 | brlcad | no, that'd definitely work if it's a full root |
| 00:52.49 | brlcad | the third rule for bu_brlcad_root |
| 00:53.11 | starseeker | tries again... |
| 00:53.26 | brlcad | it searches an env override if set first, then the compile-time install path if it exists, then the current RUN TIME path if it doesn't .. that'd match |
| 00:54.01 | starseeker | ah - what if the compile-time install path exists but is empty? |
| 00:54.08 | brlcad | then that's a problem |
| 00:54.16 | brlcad | it looks for directories |
| 00:54.34 | brlcad | the code calling bu_brlcad_root/data is then supposed to verify files |
| 00:55.17 | starseeker | I always use brlcad-install-svn for my target, so that directory already exists |
| 00:55.33 | brlcad | delete the dir? |
| 00:55.54 | brlcad | install should create it |
| 00:55.56 | starseeker | I can, but shouldn't it be robust enough to recognize that there is nothing in there and try the next possibility? |
| 00:56.16 | brlcad | it has no idea what you're looking for |
| 00:56.22 | brlcad | e.g., bu_brlcad_root . |
| 00:56.44 | brlcad | how do you know if it found root or not, other than it exists? |
| 00:56.55 | brlcad | at least maintainably without some random assumption |
| 00:56.59 | starseeker | sure, but a totally empty root may as well not exist |
| 00:57.28 | brlcad | right, so ideally, code calling bu_brlcad_root should be more specific than "." |
| 00:57.35 | brlcad | and most places are |
| 00:57.45 | brlcad | bu_brlcad_data tclscripts, for example |
| 00:58.11 | starseeker | ok, but if it doesn't find tclscripts in the first possiblity will it move on to the second? |
| 00:58.18 | brlcad | yep |
| 00:58.33 | brlcad | bu_brlcad_root (subdir) |
| 00:58.57 | brlcad | it searches for (subdir) in those search-order paths returning the first found |
| 00:59.28 | starseeker | then how can an empty share dir in the toplevel build make mged crash, and removing it allows it to run? |
| 01:00.24 | brlcad | it wouldn't make sense to assume if ROOT/some/subdir is empty, then skip it (e.g., ROOT/.) .. because it just as easily could be a read/write location we're using, (e.g., ROOT/caches/rt) |
| 01:00.58 | brlcad | you've got the crash, debug it! :) |
| 01:01.05 | brlcad | shouldn't crash regardless |
| 01:01.13 | brlcad | that should be easy to stack trace fix |
| 01:02.06 | starseeker | package require Itcl is failing |
| 01:02.58 | *** join/#brlcad crazy_imp (~mj@a89-182-24-66.net-htp.de) | |
| 01:03.33 | starseeker | uh... why? bwish and btclsh do fine... |
| 01:04.19 | brlcad | cutting a narrow path through the forest just wide enough to slip through isn't going to be safe route for travel |
| 01:05.56 | starseeker | hmm? Right now I've got no path |
| 01:06.59 | starseeker | also has to get home |
| 01:09.55 | brlcad | right, but the goal isn't just getting any path and then later widening it too |
| 01:10.08 | brlcad | that's the super-expensive way |
| 01:10.31 | starseeker | brlcad: oh, I'm going to try and figure out what's going on and what the right way is to handle it |
| 01:11.25 | starseeker | but this seems to be right in that ugly underbelly of interaction between data path searching, tcl/tk weirdness, and application initialization from a build directory - that's pretty much a poster child for "tangled web" |
| 01:11.32 | brlcad | I know, just noting that you found a crash but aren't actually working on fixing the crash :) |
| 01:12.07 | starseeker | <snort> I will tomorrow - I've got a 6:30am gym session, and if I'm up late tonight I might never make it in at all tomorrow :-P |
| 01:12.21 | brlcad | because even if the right way masks the problem for now, it's almost guaranteed to bite someone down the road |
| 01:12.28 | brlcad | and the older a bug gets, the harder they bit |
| 01:12.39 | brlcad | even ones you rediscover later |
| 01:13.12 | brlcad | mm.. gym is the perfect excuse, stay healty ;) |
| 01:13.31 | starseeker | well, it remains to be seen if this is truely a bug, since I'm in a very different setup than the autotools build and I could quite easily being doing Something Wrong with the build logic |
| 01:13.46 | starseeker | I doubt this behavior has ever been observed with autotools |
| 01:13.53 | brlcad | I seem to be having a lot of one-byte erors tonight :) |
| 01:14.15 | starseeker | ouch |
| 01:14.25 | brlcad | "something wrong" that makes mged crash is still mged's fault |
| 01:14.29 | brlcad | and preventable |
| 01:15.02 | brlcad | that just means mged/archer/whatever was assuming something -- there should be no assumptions, you test everything |
| 01:15.08 | starseeker | this is an altered mged though - remember how I switched it from using Itcl's C interface to using package require? |
| 01:15.29 | starseeker | so it's almost certainly my fault |
| 01:15.54 | brlcad | the code is still at fault for crashing -- you can catch the problem state in code before crashes occur |
| 01:16.17 | starseeker | nods |
| 01:16.37 | brlcad | you may have made it more brittle or just differently brittle, but the code is still at fault for crashing |
| 01:17.03 | starseeker | was hoping that using package require instead of the C api would make the migration to 8.6 easier, when it comes |
| 01:17.12 | brlcad | even if you feed it /dev/random, or bang on they keyboard and randomly move files around while they're being read, it shouldn't crash |
| 01:17.31 | starseeker | nods |
| 01:18.01 | brlcad | package require should be better |
| 01:18.06 | brlcad | just means you're not done :) |
| 01:18.22 | brlcad | though time really is running out, GS is REALLY going to be hurting |
| 01:18.42 | starseeker | this can be put on hold |
| 01:18.48 | brlcad | says to pot to the kettle as I make some more size_t fixes |
| 01:19.07 | brlcad | s/to pot/the pot/ |
| 01:19.28 | starseeker | last time I talked to DaveLo, it sounded like the code wasn't in any shape to be talking to any test harness... |
| 01:19.57 | starseeker | still, I guess if that's the case step one will be to rewrite it until it is... |
| 01:20.03 | brlcad | your test harness should show that, it's fully independent effort |
| 01:20.19 | brlcad | and once you get to the point where you see where it's not, you can help with exactly that next step |
| 01:21.15 | brlcad | coupled development is a major no-no for any project of value |
| 01:23.24 | brlcad | starseeker: I see why archer is failing to load (at least current set of problems) |
| 01:23.37 | brlcad | it is just blindly setting the data root and trying to load |
| 01:24.04 | brlcad | the previous code checked if it was running in a source configuration with a neat bu_brlcad_data "src" trick :) |
| 01:24.16 | brlcad | see src/archer/plugins/Wizards/humanwizard.tcl for an example |
| 01:25.01 | brlcad | basically it's falling back onto the last rule that bu_brlcad_data uses, looking for paths relative to the current directory |
| 01:25.49 | starseeker | that doesn't get hijacked by the presence of /usr/brlcad? |
| 01:26.36 | brlcad | sorry, second to last rule ;) |
| 01:26.45 | brlcad | /usr/brlcad is checked even if it's not the build dir |
| 01:26.50 | brlcad | er install dir |
| 01:28.30 | starseeker | yeah - isn't that kinda a bad idea? the presence of /usr/brlcad will kill any possibility of the current directory being used |
| 01:29.43 | CIA-43 | BRL-CAD: 03starseeker * r42191 10/brlcad/branches/cmake/TODO.cmake: Few more notes about current state of CMake - will probably have to leave this for a while. |
| 01:29.48 | starseeker | ok, I really do have to go |
| 01:33.36 | brlcad | starseeker: no, it'll check current dir before it |
| 01:33.44 | brlcad | see the search order rules in bu.h |
| 01:42.51 | CIA-43 | BRL-CAD: 03brlcad * r42192 10/brlcad/trunk/src/archer/archer: try a little harder to find data resources so archer can run uninstalled |
| 01:43.27 | CIA-43 | BRL-CAD: 03brlcad * r42193 10/brlcad/trunk/src/tclscripts/archer/LoadArcherLibs.tcl: if hv3/tkhtml won't load, it's not the end of the world. |
| 01:45.28 | brlcad | aha, that is the problem, looking for "." is not what you'd expect for a multi-root install since it'll find the /usr/brlcad hail mary case |
| 01:54.48 | CIA-43 | BRL-CAD: 03brlcad * r42194 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: search harder here too for aboutArcher.png and mike-tux.png |
| 01:55.02 | CIA-43 | BRL-CAD: 03brlcad * r42195 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: look for src dir too |
| 01:59.59 | CIA-43 | BRL-CAD: 03brlcad * r42196 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: hopefully not lost in the indentation cleanup, make bu_brlcad_data only check for one subdir, then use [file join] on the rest |
| 02:21.47 | brlcad | heh, interesting |
| 02:22.05 | brlcad | src/tclscripts/nirt/prototype.sh <-- starseeker, you might find that amusing |
| 02:22.25 | brlcad | a prototype interface around nirt by pjt |
| 02:22.30 | brlcad | check it out before updating, because I'm killing it |
| 02:27.21 | CIA-43 | BRL-CAD: 03brlcad * r42197 10/brlcad/trunk/src/tclscripts/ (13 files in 3 dirs): |
| 02:27.21 | CIA-43 | BRL-CAD: bu_brlcad_root should ideally only be called with one subdirectory for |
| 02:27.22 | CIA-43 | BRL-CAD: portability, then use tcl's [file join] on the rest of the path. this is likely |
| 02:27.22 | CIA-43 | BRL-CAD: the problem that necessitated adding '.exe' extensions to the binaries for |
| 02:27.23 | CIA-43 | BRL-CAD: windows because the lower-level C code was trying to stat the file. this should |
| 02:27.23 | CIA-43 | BRL-CAD: simplify things nicely. |
| 02:28.35 | CIA-43 | BRL-CAD: 03brlcad * r42198 10/brlcad/trunk/ (configure.ac src/tclscripts/Makefile.am src/tclscripts/nirt/): |
| 02:28.35 | CIA-43 | BRL-CAD: remove the nirt tclscripts directory. there was just one source file in there, |
| 02:28.36 | CIA-43 | BRL-CAD: prototype.sh, which was a prototype interface by pjt for nirt. long since |
| 02:28.36 | CIA-43 | BRL-CAD: overcome by events and not that great a prototype anyways... sorry paul. :) |
| 02:30.25 | CIA-43 | BRL-CAD: 03brlcad * r42199 10/brlcad/trunk/src/tclscripts/rtwizard/lib/ (FbPage.itk PictureTypeE.itcl): unnecessary but consistent |
| 02:31.14 | CIA-43 | BRL-CAD: 03brlcad * r42200 10/brlcad/trunk/src/tclscripts/rtwizard/lib/PictureTypeF.itcl: missed one, wrap in quotes for consistency |
| 02:42.41 | CIA-43 | BRL-CAD: 03brlcad * r42201 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): |
| 02:42.42 | CIA-43 | BRL-CAD: remove brlcadDataPath since you really don't want to look for '.' unless you |
| 02:42.42 | CIA-43 | BRL-CAD: absolutely have to, otherwise you risk getting a non-usable /usr/brlcad default. |
| 02:42.43 | CIA-43 | BRL-CAD: looking for the subdirectories individually makes them try the run-time relative |
| 02:42.43 | CIA-43 | BRL-CAD: path first, which means we don't even need to try a separate 'src' search unless |
| 02:42.44 | CIA-43 | BRL-CAD: it's for items that are in a different place hierarchically in the source tree |
| 02:42.45 | CIA-43 | BRL-CAD: than they are after install. |
| 03:02.45 | CIA-43 | BRL-CAD: 03brlcad * r42202 10/brlcad/trunk/src/tclscripts/lib/Command.tcl: gracefully handle a failure to create a slave interpreter |
| 03:13.13 | CIA-43 | BRL-CAD: 03brlcad * r42203 10/brlcad/trunk/src/tclscripts/lib/Command.tcl: catch the other place we create an interpreter too |
| 03:28.22 | CIA-43 | BRL-CAD: 03brlcad * r42204 10/brlcad/trunk/src/libtclcad/tclcadAutoPath.c: |
| 03:28.23 | CIA-43 | BRL-CAD: for some reason, 'create interp' goes through a different initialization process |
| 03:28.24 | CIA-43 | BRL-CAD: which causes a failure to find init.tcl if we try to run uninstalled. it checks |
| 03:28.25 | CIA-43 | BRL-CAD: [tcl::pkgconfig get scriptdir,runtime] but does not respect $tcl_library. it |
| 03:28.26 | CIA-43 | BRL-CAD: DOES, however, respect env(TCL_LIBRARY) so make sure we set that too when we're |
| 03:28.27 | CIA-43 | BRL-CAD: initializing unless the user already has it set to something. |
| 03:36.13 | CIA-43 | BRL-CAD: 03brlcad * r42205 10/brlcad/trunk/src/libtclcad/ged_obj.c: |
| 03:36.14 | CIA-43 | BRL-CAD: error message is very obtuse. is the type printed not supported for a given |
| 03:36.15 | CIA-43 | BRL-CAD: use, or not supported because it wasn't compiled. the latter was meant but not |
| 03:36.15 | CIA-43 | BRL-CAD: stated. reword for clarity and provide some instruction for when things go bad. |
| 03:36.18 | brlcad | there, that should bring archer back into a working state |
| 03:36.24 | brlcad | uninstalled |
| 03:36.40 | DX^ | "Several BRL-CAD developers are working on implementing a full STEP converter." |
| 03:36.43 | DX^ | who are these developers? |
| 03:37.40 | brlcad | DX^: http://www.ohloh.net/p/brlcad/contributors <-- developers with activity in the past year |
| 03:38.39 | brlcad | there is already initial support for import, with more work happening this year to complete it |
| 03:39.04 | brlcad | there has been rumbling talks about an exporter (which is WAY easier), but nobody is working on it yet |
| 03:42.48 | CIA-43 | BRL-CAD: 03brlcad * r42206 10/brlcad/trunk/src/libbu/Makefile.am: wow, long time since I've seen THIS particular build system bug.. heh. add missing \ line continuation after timetester.c in EXTRA_DIST so CMakeLists.txt isn't left out. |
| 03:49.45 | DX^ | brlcad: I did minor modificiations to g_xxx-facets.c to output JSON (javascript) |
| 03:50.25 | DX^ | I am very interested in IGES/STEP import/export |
| 03:50.57 | DX^ | I also think there should be a tool/script that takes one file format directly to another, without having to do foo->g->newfoo, but haven't really figured out how this would work yet |
| 03:51.13 | DX^ | the code is massive and complicated, and I have difficulty understanding what is going on most of the time to be honest |
| 03:52.09 | brlcad | DX^: you know we have pretty extensive support for iges import/export |
| 03:52.34 | DX^ | I submitted an IGES bug not too long ago |
| 03:52.35 | brlcad | it was (and still is in some ways) our most extensive converter |
| 03:52.44 | brlcad | just quite aged and lacking attentino |
| 03:52.59 | DX^ | it won't import the 2011/2012 Autodesk versions of IGES for whatever reason |
| 03:53.19 | brlcad | not surprising, it was written around version 5.1 |
| 03:53.30 | DX^ | brl-cad or autodesk? |
| 03:53.35 | brlcad | probably something very very minor |
| 03:53.37 | brlcad | iges |
| 03:53.39 | brlcad | iges 5.1 |
| 03:54.03 | brlcad | current/last iges is 5.3 or 6.0 draft if they were on the drafting committee before it collapsed |
| 03:54.22 | DX^ | hmm |
| 03:54.42 | brlcad | so it could be something as simple as a header having a 5.3 in it and our converter choking on it |
| 03:54.43 | DX^ | I wonder the amount of work required to support IGES 5.3 |
| 03:54.53 | brlcad | more than likely a "little" more complicated than that, but probably not much more |
| 03:55.21 | brlcad | there weren't huge changes, the format itself is the same -- just slightly different entity details |
| 03:55.57 | brlcad | the spec is available: http://www.uspro.org/documents/IGES5-3_forDownload.pdf |
| 03:56.00 | DX^ | http://sourceforge.net/tracker/?func=detail&aid=3125119&group_id=105292&atid=640802 |
| 03:56.02 | brlcad | so you could review and compare |
| 03:56.05 | DX^ | was what I submitted |
| 03:56.10 | DX^ | Add_nurb_loop_to_face: Edgeuse/vertex mixup! |
| 03:56.59 | brlcad | yeah, that's not even format-related -- it parsed all of the entities as shown in the summary |
| 03:57.31 | DX^ | yep, not sure what the deal is |
| 03:57.41 | brlcad | it's some deficiency or bug in importing that specific object type |
| 03:57.56 | DX^ | but the same file imported into older versions of inventor and exported as IGES imported into BRL-CAD just fine |
| 03:58.09 | DX^ | so I think they changed something (obviously) |
| 03:58.26 | brlcad | the method it uses isn't the best because when the converter was written it had to turn most iges entities into polygons during import -- so that's what it's trying to do and failing on |
| 03:58.53 | brlcad | that's the (eu == edge use) toplogy failure |
| 03:59.42 | brlcad | DX^: could be LOTS of reasons why it failed really |
| 03:59.54 | DX^ | yeah |
| 04:00.02 | brlcad | simple subtle changes in the floating point alone after reconverting could have made it work |
| 04:00.16 | brlcad | would have to compare the summary reports from the one that worked |
| 04:00.24 | DX^ | I need to brush up on more advanced C before I can touch this code base |
| 04:00.32 | DX^ | I'd love to help but I'm afraid my meddling hands would break too much |
| 04:00.52 | brlcad | anything you did would get reviewed by others, so don't be too afraid to dig in ;) |
| 04:01.09 | brlcad | you're not going to break anythign that will hurt anyone but yourself :D |
| 04:01.12 | DX^ | thing is that I just don't know what the hell is going on yet |
| 04:01.46 | DX^ | I'm more focused on the converters.. I think a solid suite of geometry converters would bring more attention to BRL-CAD |
| 04:01.48 | brlcad | you should turn your g_xxx-facets.c work to a proper g-json tool |
| 04:02.11 | DX^ | I will make it more robust and submit it |
| 04:02.21 | brlcad | it would, we have more converters than anyone, and the hardest ones at that (iges, step, dxf, etc) |
| 04:02.58 | DX^ | an export to COLLADA would be immensely powerful, but that spec is confusing as all hell |
| 04:03.36 | brlcad | for what it's worth, your tracker item hasn't been commented on mostly because the library that iges-g is using there is undergoing a massive review for robustness/stability |
| 04:03.43 | brlcad | collada would be easy |
| 04:04.39 | DX^ | think so? |
| 04:04.54 | brlcad | there's an MIT-licensed SDK, so it would just be a matter of wiring it up |
| 04:05.02 | brlcad | no more complicated than writing json really |
| 04:05.14 | DX^ | hmm I'll look into the SDK |
| 04:05.21 | DX^ | another problem I was having is finding the top level object |
| 04:05.33 | DX^ | I got it from mged, but its kind of confusing that you have to type it in manually at the command line |
| 04:05.48 | brlcad | common point of confusion for new users |
| 04:05.58 | DX^ | I get the robustness of having it typed in, but shouldn't it default to all objects if the arg is omitted? |
| 04:06.11 | brlcad | there's a todo-item to make all of the converters work on all top-level objects by default, but that's pretty low priority |
| 04:06.47 | brlcad | one of the reasons (though not the whole story) is that many formats only have support for single object export |
| 04:06.51 | brlcad | e.g., stl |
| 04:07.32 | brlcad | so do you export one of the top-levels, which one? combine all of them into a new top-level and export that? it's not well-defined |
| 04:07.47 | brlcad | so the user has to learn what their situation is and decide |
| 04:08.38 | brlcad | not great, but not terrible -- everyone figures it out pretty quickly, even faster if they go through any of the intro tutorials |
| 04:13.57 | DX^ | yeah I certainly understand the dilemma |
| 04:14.06 | DX^ | perhaps list all top level objects and allow the user to choose one |
| 04:14.07 | DX^ | ? |
| 04:14.22 | DX^ | or write each one to a separate file |
| 04:21.03 | brlcad | yeah, ideally you'd just write each one to a separate file and make the usage default to specifying a filename template so it's defined and not surprising |
| 04:21.13 | brlcad | and scriptable |
| 04:21.44 | brlcad | not an insurmountable problem, just nobody working in that particular area at the moment -- sounds like a great patch though ;) |
| 04:22.08 | brlcad | src/libged/tops.c shows how to get a list of top-level objects |
| 04:22.23 | brlcad | plenty of folks here to help walk through code |
| 04:23.41 | brlcad | ``Erik: the very first error on the mac issues file is a failure in metaball.c saying parameter mismatch. they match here, so maybe not up-to-date or something? many of the errors that followed were just cascade failures from librt not compiling |
| 04:52.25 | ``Erik | I looked at it and the types all looked correct, I'd verified with svn revert and svn diff before running that build... I just recall lots of signed/unsigned, lots of %lu vs size_t, and lots of unused parameter stuff showing up *shrug* I'll look at it some more tomorrow after the GS meeting |
| 05:03.29 | CIA-43 | BRL-CAD: 03brlcad * r42207 10/brlcad/trunk/src/adrt/slave/slave.c: another BU_STR_EQUAL() conversion |
| 05:03.54 | brlcad | the linux log looks valid |
| 05:04.15 | brlcad | for whatever reason, the machine I tested isn't kicking those out with my build |
| 05:04.55 | CIA-43 | BRL-CAD: 03brlcad * r42208 10/brlcad/trunk/src/burst/ (burst.c error.c fb.c ui.c): a lot more manual BU_STR_EQUAL conversions |
| 05:06.59 | CIA-43 | BRL-CAD: 03brlcad * r42209 10/brlcad/trunk/src/util/ (6 files): fix a slew of warnings from erik's linux build log. don't ignore the return values from fread/fwrite/read/write/scanf. |
| 05:07.58 | CIA-43 | BRL-CAD: 03brlcad * r42210 10/brlcad/trunk/src/fb/ (cat-fb.c fb-bw.c pl-fb.c pp-fb.c): more fixing of warnings from erik's linux build log. don't ignore the return values from fread/fwrite/read/write/scanf. |
| 05:08.18 | CIA-43 | BRL-CAD: 03brlcad * r42211 10/brlcad/trunk/src/bwish/cmd.c: BU_STR_EQUAL |
| 05:08.42 | CIA-43 | BRL-CAD: 03brlcad * r42212 10/brlcad/trunk/src/anim/chan_permute.c: strcmp -> BU_STR_EQUAL |
| 05:09.45 | CIA-43 | BRL-CAD: 03brlcad * r42213 10/brlcad/trunk/src/util/Makefile.am: remove strict flags until all i/o funcs have return values checked |
| 05:37.34 | *** join/#brlcad Stattrav (~Stattrav@122.172.16.143) | |
| 05:37.34 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:38.23 | CIA-43 | BRL-CAD: 03brlcad * r42214 10/brlcad/trunk/src/util/ (29 files): fix the remainder of the fread/fwrite/scanf/read/write return value warnings, adding simple diagnostic perror() error reporting if a failure is detected. |
| 05:42.42 | brlcad | awesome, only about 3000 issues remaining (TOTAL) |
| 05:43.25 | brlcad | should compile 7.0 to see how far we've come along |
| 05:44.06 | brlcad | ``Erik: that should be all of the linux error issues unless I missed something |
| 05:46.32 | CIA-43 | BRL-CAD: 03brlcad * r42215 10/brlcad/trunk/src/conv/iges/readglobal.c: another COMMA case |
| 06:33.46 | CIA-43 | BRL-CAD: 03brlcad * r42216 10/brlcad/trunk/src/ (77 files in 32 dirs): mass conversion from \!strcmp() to rossberg's newly added bu_strcmp() via the related BU_STR_EQUAL() macro. improved readability. 300+ calls modified. |
| 07:05.54 | CIA-43 | BRL-CAD: 03brlcad * r42217 10/brlcad/trunk/misc/win32-msvc8/Makefile.am: pixcmp and pixblend missing from dist |
| 07:06.19 | CIA-43 | BRL-CAD: 03brlcad * r42218 10/brlcad/trunk/src/libbn/Makefile.am: bntester.dat missing from dist |
| 07:08.11 | CIA-43 | BRL-CAD: 03brlcad * r42219 10/brlcad/trunk/src/other/tktable/Makefile.in: misc directory is missing from dist |
| 07:10.50 | CIA-43 | BRL-CAD: 03brlcad * r42220 10/brlcad/trunk/src/other/libz/Makefile.am: another trailing slash missing |
| 07:25.21 | CIA-43 | BRL-CAD: 03brlcad * r42221 10/brlcad/trunk/src/ (146 files in 29 dirs): another even massiver conversion from strcmp()==0 to rossberg's newly added bu_strcmp() via the related BU_STR_EQUAL() macro. improved readability and consistency. 800+ calls modified. |
| 07:39.06 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 07:44.28 | CIA-43 | BRL-CAD: 03brlcad * r42222 10/brlcad/trunk/src/ (27 files in 12 dirs): a smaller conversion from strcmp()!=0 to rossberg's newly added bu_strcmp() via the related BU_STR_EQUAL() macro. improved readability and consistency. 70+ calls. |
| 07:56.47 | CIA-43 | BRL-CAD: 03brlcad * r42223 10/brlcad/trunk/src/ (9 files in 7 dirs): even smaller conversion from strcmp()==0 to rossberg's newly added bu_strcmp() via the related BU_STR_EQUAL() macro. improved readability and consistency. 20+ calls. |
| 07:58.38 | CIA-43 | BRL-CAD: 03brlcad * r42224 10/brlcad/trunk/src/mged/tedit.c: what the hell.. !(!(!(really???))) |
| 08:09.53 | CIA-43 | BRL-CAD: 03brlcad * r42225 10/brlcad/trunk/src/ (17 files in 6 dirs): more conversion from !strcmp() to rossbergs new bu_strcmp() func via the related BU_STR_EQUAL() macro. improved readability and consistency. 30+calls. |
| 08:22.45 | CIA-43 | BRL-CAD: 03brlcad * r42226 10/brlcad/trunk/src/ (12 files in 8 dirs): handle a few more strcmp cases where the value returned is indeed important, so convert to bu_strcmp() intead of macro. |
| 08:33.56 | CIA-43 | BRL-CAD: 03brlcad * r42227 10/brlcad/trunk/src/ (38 files in 14 dirs): and yet even more. set !BU_STR_EQUAL() for handling a few remaining strcmp cases used to test for non-matching. |
| 08:36.12 | CIA-43 | BRL-CAD: 03brlcad * r42228 10/brlcad/trunk/HACKING: prevent null crashes and improve readability. strcmp() gets added to the avoidance list. |
| 08:40.17 | CIA-43 | BRL-CAD: 03brlcad * r42229 10/brlcad/trunk/TODO: add distribution test for the HACKING-listed functions/globals to be avoided in favor of bu_* routines |
| 08:44.14 | CIA-43 | BRL-CAD: 03brlcad * r42230 10/brlcad/trunk/src/other/ (Makefile.am fonts/): |
| 08:44.15 | CIA-43 | BRL-CAD: might as well disable the fonts for now until it's time for them to be actively |
| 08:44.15 | CIA-43 | BRL-CAD: worked on. hopefully by then cmake system will be up and running and we won't |
| 08:44.16 | CIA-43 | BRL-CAD: have to fix the distcheck failure due to spaces in names. otherwise, revision |
| 08:44.16 | CIA-43 | BRL-CAD: history will hold them in trust even if their web sources asplode. |
| 08:54.30 | *** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de) | |
| 08:59.54 | *** join/#brlcad mafm (~mafm@27.Red-83-45-72.dynamicIP.rima-tde.net) | |
| 10:45.02 | *** join/#brlcad mafm_ (~mafm@27.Red-83-45-72.dynamicIP.rima-tde.net) | |
| 12:38.25 | *** join/#brlcad mafm (~mafm@27.Red-83-45-72.dynamicIP.rima-tde.net) | |
| 13:34.09 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 13:36.21 | d_rossberg | compiler error on debian squeeze: primitives/arbn/arbn.c:1026: error: format '%lu' expects type 'long unsigned int', but argument 3 has type 'size_t' |
| 13:41.23 | starseeker | anybody know if we can convert cline primitives to something else? |
| 13:47.34 | brlcad | d_rossberg: short fix is just to cast since %z isn't really portable |
| 13:49.50 | d_rossberg | starseeker: cmake's INSTALL ignores BRLCAD_PREFIX, CMAKE_INSTALL_PREFIX is empty |
| 13:50.26 | brlcad | d_rossberg: or --disable-warnings if you have other things to deal with :) |
| 14:06.04 | brlcad | looks like I did quite a bang-up job last night .. and now I can reproduce erik's failures on linux (had to be optimized, I think) |
| 14:06.20 | brlcad | kicks CIA-43 |
| 14:06.21 | CIA-43 | ow |
| 14:06.49 | brlcad | at least a dozen commits its not reporting |
| 14:12.30 | d_rossberg | it looks like CIA-43 is still asleep |
| 14:12.38 | brlcad | doing a review on all of the %lu's now |
| 14:13.10 | starseeker | brlcad: what about incorporating some printing logic that does handle %z into libbu? |
| 14:13.25 | brlcad | starseeker: we already handle %z in libbu |
| 14:13.57 | brlcad | I really don't want to wrap every single call to scanf/sscanf/printf/fprintf/... |
| 14:14.07 | starseeker | ah |
| 14:33.22 | CIA-43 | BRL-CAD: 03brlcad * r42231 10/brlcad/trunk/src/libpkg/pkg.c: libpkg doesn't depend on libbu |
| 14:44.49 | CIA-43 | BRL-CAD: 03brlcad * r42232 10/brlcad/trunk/include/bu.h: error: macro bu_strcmp passed 2 arguments, but takes just 1. now it takes 2. |
| 14:47.57 | CIA-43 | BRL-CAD: 03brlcad * r42233 10/brlcad/trunk/src/conv/fast4-g.c: oops, there is no bu_strlen() |
| 14:50.52 | CIA-43 | BRL-CAD: 03brlcad * r42234 10/brlcad/trunk/src/irprep/irdisp.c: need bu.h |
| 14:51.05 | CIA-43 | BRL-CAD: 03brlcad * r42235 10/brlcad/trunk/src/gtools/g_diff.c: renamed everyone except the first, ret_eq. |
| 14:53.54 | CIA-43 | BRL-CAD: 03brlcad * r42236 10/brlcad/trunk/src/sig/ (d-a.c dwin.c ihist.c): more that need bu.h |
| 14:54.27 | CIA-43 | BRL-CAD: 03brlcad * r42237 10/brlcad/trunk/src/util/pixrect.c: helps to actually set the variable. |
| 14:54.37 | brlcad | heh, cia must be really overloaded |
| 14:55.39 | brlcad | yeah, looks like someone rebased a git repo (it ends up replaying all commits) |
| 14:57.04 | starseeker | ow |
| 14:58.18 | brlcad | ah, fork of mandriva linux |
| 15:03.06 | CIA-43 | BRL-CAD: 03d_rossberg * r42238 10/brlcad/trunk/misc/win32-msvc/Dll/BrlcadCore.def: export the new bu_strcmpm() too |
| 15:06.01 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 15:07.53 | CIA-43 | BRL-CAD: 03d_rossberg * r42239 10/brlcad/trunk/src/libbu/CMakeLists.txt: fixed CMake configuration for library-testing tools |
| 15:31.24 | brlcad | starseeker: I just noticed your changes to the mged/bwish startup .. remind me what was the issue was there? |
| 15:33.00 | starseeker | basically I did a fair bit of reworking of how libtclcad was setting paths - I don't know that I did the right thing, but the upshot for mged was I made changes to bwish to accomidate my changes to tclcad but never went back around and did it for mged |
| 15:33.13 | CIA-43 | BRL-CAD: 03starseeker * r42240 10/brlcad/branches/cmake/ (374 files in 75 dirs): Update cmake branch to trunk r42239 |
| 15:33.21 | brlcad | reason I ask is because setting tclcad_auto_path() is a crutch, one that shouldn't be needed, so the code was trying to start without it before, then retrying if that fails -- new code seems to just punt |
| 15:34.00 | starseeker | uh. maybe I'm abusing the mechanism, but package require mechanisms need the extra paths... |
| 15:34.48 | starseeker | except for archer, it's working pretty reliably now |
| 15:34.56 | brlcad | package require needs them because they've not been setup correctly |
| 15:34.59 | CIA-43 | BRL-CAD: 03starseeker * r42241 10/brlcad/branches/cmake/src/tclscripts/CMakeLists.txt: nirt subdirectory is no more. |
| 15:35.32 | starseeker | by "set up correctly" do you mean placed where Tcl will seem them by default? |
| 15:35.53 | brlcad | something to that effect, but not necessarily a system installed path |
| 15:36.20 | brlcad | using one of tcl's various searching rules, a means to specify beyond auto_path |
| 15:36.40 | starseeker | where are those rules defined? |
| 15:36.54 | starseeker | I had a heck of a time trying to figure out what governed search paths |
| 15:36.58 | brlcad | technically, we should be able to get away with one init_mged.tcl and with the right pkgIndex.tcl and tclIndex files, everything is found |
| 15:37.29 | brlcad | tclcad_auto_path() is the painful way to do all that in C code |
| 15:37.51 | brlcad | embedding search dirs into C code isn't a good idea |
| 15:38.28 | starseeker | sure - I thought about just having tclcad_autopath point to one guaranteed to be there tcl file to do all the path extensions... |
| 15:38.56 | starseeker | but figured I'd stay as close as i could to our current setup while doing what I wanted to do with it |
| 15:41.00 | brlcad | as close to current would have left the two-pass loop -- that seems unrelated to any changes made in tclcad_auto_path() |
| 15:41.42 | brlcad | why was mged failing as it was written? |
| 15:41.56 | brlcad | (that prompted r42244) |
| 15:49.56 | starseeker | without tclcad_auto_path, auto_path had only the install directories |
| 15:50.56 | starseeker | it got as far as trying to load libitcl.dylib from the install directory and wiped out |
| 15:52.07 | starseeker | however those initial pre-tccad_auto_path paths are being set, even running from the build dir it was picking up the installed directory's paths |
| 15:53.40 | starseeker | that's why it succeeds if I remove the install dir - without the install dir in place, auto_path ends up populated with the build dir paths |
| 15:55.38 | starseeker | rather than depend on the black magic that seems to be the Tcl paths, I used the tclcad_auto_path mechanism to always ensure it was looking where it needed to look, based on current conditions |
| 15:57.26 | starseeker | the question of course is how a build dir execution of ./bin/mged was getting the install paths - I've been searching |
| 15:58.46 | starseeker | my best guess is the Tcl_FindExecutable("mged") line - if that's picking up the system path mged, it's pulling in the wrong lib paths |
| 15:59.22 | CIA-43 | BRL-CAD: 03starseeker * r42242 10/brlcad/branches/cmake/src/conv/fast4-g.c: bu_strlen undefined, not seeing it in libbu - probably something going on, use strlen for now in cmake branch. |
| 16:02.05 | brlcad | starseeker: but there's part of my confusion -- if init failed without tclcad_auto_path() (e.g. libitcl.dylib not loading), the very next thing it should have been trying was to run tclcad_auto_path() to try again -- or are you saying the second pass also failed? |
| 16:02.46 | starseeker | I'm saying the first pass crashed - it never got to the second pass. It crashed somewhere in Tcl itself |
| 16:03.55 | brlcad | that sounds familiar, there was a bug in earlier versions of tcl that necessitated a private Tcl library call in order to not crash |
| 16:05.43 | brlcad | my biggest concern is complacency because if it works, nobody is going to go back and look at the init code until something breaks yet again |
| 16:06.21 | brlcad | I don't have a big problem with the change, but do want to make sure we are moving closer towards no tclcad_auto_path and no btclsh/bwish .. not tighter assumed/required coupling |
| 16:06.23 | starseeker | that's why I thought the tclcad_auto_path approach might be worthwhile - then we don't care what Tcl is doing, because we're feeding it exactly what we know it needs |
| 16:06.32 | starseeker | oh |
| 16:07.07 | brlcad | what you mentioned about calling a tcl init and having all the logic there would be a great decoupling |
| 16:07.30 | brlcad | theoretically, we could embed a generic Tcl_Interp(), load that file, and have everything we need |
| 16:07.40 | brlcad | that's the cleanliness goal |
| 16:07.40 | starseeker | nods |
| 16:08.00 | starseeker | OK, that's probably doable - I had assumed there were reasons we weren't trying that |
| 16:08.23 | starseeker | Bu_Init, Bn_Init and friends are definitely C... |
| 16:08.43 | starseeker | although even there we could probably make a package require mechanism that would work |
| 16:08.47 | brlcad | those are one step closer towards "package require bu", "package require bn" |
| 16:08.50 | starseeker | did it for isst after all |
| 16:08.55 | starseeker | nods |
| 16:09.10 | starseeker | I can work towards package require bu if that's the goal - I'd vastly prefer that |
| 16:09.12 | brlcad | I believe they're actually sufficient, they just don't have a pkgIndex.tcl file |
| 16:09.19 | starseeker | messing with the C underbelly of Tcl is nasty |
| 16:10.42 | brlcad | mged should just "package require brlcad" or something similar, and have our core libs load up as sub-packages including bu, bn, rt, wdb, ged |
| 16:12.02 | starseeker | yeah, $5 that's it - bu_getprogname is returning mged, which in turn is causing Tcl_FindExecutable to find the installed mged (which is in the path) and populate based on the installed exe name, not the local one |
| 16:12.53 | starseeker | if mged isn't installed, Tcl_FindExecutable isn't coming back with anything usable (or possibly it's finding /usr/brlcad/bin/mged and is smart enough not to use that, not sure which) |
| 16:13.29 | starseeker | since there's nothing, Itcl fails to load and it comes back around for the auto_path enhancements (which does work) |
| 16:15.57 | starseeker | bingo. If I force-feed Tcl_FindExecutable the full path to the build-dir mged, it works |
| 16:22.38 | CIA-43 | BRL-CAD: 03starseeker * r42243 10/brlcad/branches/cmake/src/ (gtools/g_diff.c tclscripts/archer/LoadArcherLibs.tcl): Restore some CMake branch tweaks I wiped out with the previous update. |
| 16:40.57 | brlcad | starseeker: there's a separate bu routine to get the full path so perhaps the bug is calling bu_getprogname() |
| 16:41.42 | brlcad | bu_argv0_full_path() |
| 16:42.50 | brlcad | I believe bu_getprogname() was set up to mirror what getprogname() returns, which is just the name instead of the full path |
| 16:47.00 | brlcad | <PROTECTED> |
| 16:47.00 | brlcad | <PROTECTED> |
| 16:47.01 | brlcad | Failures: 95595 NMG, 99486 BoT |
| 16:47.01 | brlcad | NMG conversion: 84.2% (508474 of 604069 objects) |
| 16:47.01 | brlcad | BoT conversion: 83.5% (504583 of 604069 objects) |
| 16:47.03 | brlcad | <PROTECTED> |
| 16:47.07 | brlcad | hehe, that's just terrible :) |
| 17:00.14 | CIA-43 | BRL-CAD: 03starseeker * r42244 10/brlcad/branches/cmake/src/mged/setup.c: |
| 17:00.14 | CIA-43 | BRL-CAD: <smack> why'd I fix the bwish startup to account for the changes to the |
| 17:00.15 | CIA-43 | BRL-CAD: libtclcad logic but not mged? Make mged init look more like the bwish init - |
| 17:00.15 | CIA-43 | BRL-CAD: this whole setup probably needs review but mged should at least behave better |
| 17:00.16 | CIA-43 | BRL-CAD: now. Archer still isn't happy yet. |
| 17:10.25 | brlcad | poor CIA |
| 17:11.10 | brlcad | an hour and a half behind |
| 17:34.32 | *** join/#brlcad Elrohir (~kvirc@p5B14B2AE.dip.t-dialin.net) | |
| 17:39.10 | brlcad | downloads 7.0.2 |
| 18:05.06 | CIA-43 | BRL-CAD: 03starseeker * r42245 10/brlcad/branches/cmake/src/mged/setup.c: OK, revert to the previous two pass code, but use bu_argv0_full_path instead of bu_getprogname to prevent the build dir mged from getting the path info from the installed mged. |
| 18:07.04 | starseeker | returns from lunch |
| 18:07.28 | starseeker | brlcad: yeah, stumbled onto argv0 and tested - works |
| 18:07.38 | starseeker | oh, heh - there's the commit message |
| 18:30.50 | CIA-43 | BRL-CAD: 03brlcad * r42246 10/brlcad/trunk/src/halftone/main.c: fb.h for fb_common_file_size() |
| 18:44.51 | starseeker | ah, there we go - thanks Sean for the examples of how to do it right. Archer now runs from the build dir |
| 18:52.57 | brlcad | awesome |
| 19:04.20 | CIA-43 | BRL-CAD: 03starseeker * r42247 10/brlcad/branches/cmake/src/bwish/ (cadAppInit.c main.c): |
| 19:04.24 | CIA-43 | BRL-CAD: Migrate the btclsh/bwish logic back closer to the trunk. Of course, if we get |
| 19:04.24 | CIA-43 | BRL-CAD: proper package require handling working for all of BRL-CAD these may reduce |
| 19:04.25 | CIA-43 | BRL-CAD: entirely to setting up tcl and loading one .tcl file, but that's for later. |
| 19:05.52 | CIA-43 | BRL-CAD: 03starseeker * r42248 10/brlcad/branches/cmake/src/archer/ (CMakeLists.txt archer): Follow Sean's lead with making Archer better about looking for files - archer now runs successfully from the build dir. |
| 19:14.34 | brlcad | ahh, I remember those days... 7.0 built in about 2 min :) |
| 19:15.23 | CIA-43 | BRL-CAD: 03erikgreenwald * r42249 10/rt^3/trunk/src/other/sqlite_3_7_4/CMakeLists.txt: conditionalize libdl based on OS (should probably be an explicit test eventually) |
| 19:24.41 | CIA-43 | BRL-CAD: 03brlcad * r42250 10/brlcad/trunk/NEWS: |
| 19:24.42 | CIA-43 | BRL-CAD: myself, daniel, and cliff arrived at a(n unverified) fix for the mged crash |
| 19:24.42 | CIA-43 | BRL-CAD: reported by tom browder on the devel mailing list where it'd crash if you didn't |
| 19:24.43 | CIA-43 | BRL-CAD: have one of the default editors installed due to unreliable strcmp() behavior |
| 19:24.43 | CIA-43 | BRL-CAD: when provided NULL arguments. fix was propagated throughout brl-cad code with |
| 19:24.50 | CIA-43 | BRL-CAD: new bu_strcmp() interface from daniel. |
| 19:39.18 | starseeker | hmm... may have spoken too soon |
| 19:40.57 | starseeker | archer is using /usr/brlcad/ files |
| 19:52.46 | starseeker | brlcad: I must still be doing something wrong :-( |
| 19:56.43 | brlcad | starseeker: you can verify before by kicking of btclsh and running the same commands, test bu_brlcad_data with the parameters provided, for example |
| 19:58.53 | starseeker | <PROTECTED> |
| 19:58.54 | starseeker | btclsh> bu_brlcad_data tclscripts |
| 19:58.54 | starseeker | /usr/brlcad/share/tclscripts |
| 19:58.54 | starseeker | btclsh> bu_brlcad_data src |
| 19:58.54 | starseeker | ./src |
| 19:59.13 | brlcad | yeah, that's the issue |
| 19:59.21 | brlcad | bu_brlcad_data tclscripts on trunk doesn't do that |
| 19:59.37 | brlcad | so something's different |
| 20:00.01 | starseeker | gotta be me messing with libtclcad |
| 20:00.04 | brlcad | sushi:~/brlcad morrison$ src/bwish/btclsh |
| 20:00.04 | brlcad | Using Tcl library at /Users/morrison/brlcad/src/other/tcl/library |
| 20:00.04 | brlcad | btclsh> bu_brlcad_data tclscripts |
| 20:00.07 | brlcad | ./src/tclscripts |
| 20:07.44 | brlcad | starseeker: you can set BU_DEBUG_PATHS to see the actual start-up search logic being used |
| 20:08.14 | starseeker | is that a compile flag? |
| 20:08.26 | brlcad | run-time flag |
| 20:09.16 | starseeker | so just export it into the environment? |
| 20:09.42 | brlcad | btclsh> set bu_debug 0x1000 |
| 20:09.42 | brlcad | 0x1000 |
| 20:09.42 | brlcad | btclsh> bu_brlcad_root . |
| 20:09.42 | brlcad | bu_brlcad_root: searching for [.] |
| 20:09.42 | brlcad | Does [/usr/brlcad/dev-7.18.1] exist? NO |
| 20:09.44 | brlcad | Does [lt-btclsh] exist? NO |
| 20:09.47 | brlcad | Does [/usr/brlcad] exist? YES |
| 20:09.50 | brlcad | Does [/usr/brlcad/.] exist? YES |
| 20:09.52 | brlcad | Found: /usr/brlcad default path [/usr/brlcad/.] |
| 20:09.55 | brlcad | /usr/brlcad/. |
| 20:09.57 | brlcad | btclsh> |
| 20:10.12 | starseeker | O.o - would never have thought of set bu_debug 0x1000 |
| 20:10.28 | brlcad | all the bu_debug flags are listed in bu.h |
| 20:10.47 | brlcad | almost every tool exposes debug flags through -x and -X command-line options |
| 20:11.10 | starseeker | the 0x1000 is a hex value? |
| 20:12.45 | brlcad | yeah |
| 20:12.57 | brlcad | -\! for bu debugging on most commands |
| 20:13.14 | starseeker | brlcad: what's the sequence in your build tree for the search? |
| 20:13.29 | brlcad | rt -\!0x1 sets coredumping, for example |
| 20:13.39 | brlcad | which search? |
| 20:13.46 | starseeker | the bu_debug |
| 20:13.52 | starseeker | root |
| 20:14.22 | brlcad | sequence for what though? |
| 20:14.47 | starseeker | I guess it finds lt-btclsh before /usr/brlcad? |
| 20:15.18 | starseeker | nevermind - I'll build trunk |
| 20:18.46 | brlcad | http://pastebin.mozilla.org/937127 |
| 20:20.39 | starseeker | thanks :-) |
| 20:21.16 | starseeker | ah - it's using the version number of brlcad |
| 20:21.36 | starseeker | that could be one of my problems |
| 20:22.23 | starseeker | checks to see whether he incorporated version numbers into his data setup... |
| 20:22.25 | brlcad | /usr/brlcad/dev-7.18.1 is my prefix for that build, but other prefixes should work too iirc |
| 20:23.12 | brlcad | the only version incorporation are the tests on lines 3 and 53 |
| 20:23.20 | brlcad | the rest of the version numbers are just part of prefix |
| 20:24.48 | starseeker | it's looking for share/brlcad/7.18.1 though, not share/brlcad |
| 20:25.12 | brlcad | right |
| 20:25.43 | brlcad | src/libbu/brlcad_path.c |
| 20:27.52 | brlcad | uses BRLCAD_DATA if set, or BRLCAD_ROOT/share/brlcad/VERSION if unset .. those two should match, though since BRLCAD_DATA == ${bc_prefix}/share/brlcad/${BRLCAD_VERSION} |
| 20:27.58 | brlcad | from m4/prefix.m4 |
| 20:28.53 | starseeker | here's what I'm seeing: |
| 20:28.54 | starseeker | http://pastebin.mozilla.org/937149 |
| 20:29.16 | brlcad | remember intentionally configuring the search logic so that there was a highly minimized chance of getting the wrong install of something, unless there really was just nothing else left to try |
| 20:31.48 | brlcad | if you have a /usr/brlcad/share/tclscripts then that sounds like that's a problem -- it's already so far down the failure list that it thinks it found a usable install |
| 20:32.47 | brlcad | s/a problem/the problem/ .. if you actually have an install in the standard install place, then it's going to prefer that before it attempts to fall back on source installations |
| 20:33.06 | starseeker | great. I can't do anything about that |
| 20:33.09 | brlcad | it has to do that for proper user behavior, their paths come first, then devs |
| 20:33.21 | starseeker | isn't sure he agrees |
| 20:33.39 | starseeker | would expect to try local files first, then installed |
| 20:33.43 | brlcad | I'm not sure I understand why you have a /usr/brlcad/share/tclscripts in the first place.. |
| 20:34.24 | brlcad | that'd be a security vulnerability |
| 20:34.35 | brlcad | applications that try local files first can be easily exploited |
| 20:35.32 | starseeker | but if we're running from a build directory, isn't using files in that build directory first reasonable? |
| 20:36.04 | starseeker | I agree if the binary is installed that makes sense, but if it's not installed... |
| 20:36.05 | brlcad | sure, but there's no reliable way to tell you're running from a build directory or someone who actually installed into their build directory |
| 20:36.21 | brlcad | your build directory is another person's home directory |
| 20:37.13 | starseeker | huh? I've never seen anyone build using their homem directory toplevel |
| 20:37.32 | brlcad | build *into* thier home somewhere |
| 20:38.05 | starseeker | sure - but if the build path and the install path are both known to the program, it knows exactly when it is installed and when it isn't |
| 20:38.07 | brlcad | I've done that plenty of times, seen others do it where install dir is a subdir under brlcad/src or brlcad/ or somewhere else |
| 20:39.04 | brlcad | only the compile-time install path is known |
| 20:39.04 | brlcad | where the application actually ends up is not known |
| 20:39.25 | brlcad | you have absolutely no guarantee that it'll end up in the install location and that's desirable (to the user) -- application relocatability |
| 20:39.38 | brlcad | that's what lets you drag a mac app all around and it just works |
| 20:40.25 | brlcad | a lot of work went into the current setup so it similarly works in a deterministic safe manner too |
| 20:40.46 | starseeker | that's really a problem for development though - you can't develop on a machine that has an installed BRL-CAD |
| 20:41.02 | brlcad | I do it all the time without problem... :) |
| 20:42.02 | brlcad | the log I showed you has an existing install and /usr/brlcad/{bin|share|man|etc} symlinks |
| 20:42.53 | brlcad | so again, my claim is that you should not have a /usr/brlcad/share/tclscripts unless you modified the install paths from what autoconf does |
| 20:44.52 | brlcad | if you think the search logic should change, feel free to write it down .. but I can pretty much guarantee a use case exposed to exploit if you look for dev paths before the existing search ordering .. bu.h has the high-level ordering |
| 20:46.10 | starseeker | OK, I'll buy that |
| 20:46.22 | starseeker | but it means I'm stymed for now |
| 20:48.51 | brlcad | not necessarily |
| 20:49.03 | brlcad | the search ordering provides several ways to override |
| 20:49.30 | brlcad | you still haven't read the search ordering in bu.h yet have you? :) |
| 20:49.47 | starseeker | I know, the environment variables |
| 21:09.40 | CIA-43 | BRL-CAD: 03starseeker * r42251 10/brlcad/branches/cmake/CMakeLists.txt: We need to append the BRL-CAD version to the data install dir. |
| 21:14.42 | brlcad | not strictly necessary -- the only requirement I think is that BRLCAD_ROOT/share/* should not be the same as BRLCAD_DATA/* |
| 21:15.02 | brlcad | though having the version does match the autotools build presently |
| 21:15.47 | brlcad | it's on the build-system-to-do list, though to sort out multi-version installs vs single-version install defaults. right now it's a mix of the two. |
| 21:17.40 | starseeker | well, if you have a scheme in mind now's the time :-) |
| 21:17.51 | starseeker | is about ready to rip his hair out |
| 21:18.01 | brlcad | having a build option so that it will default to /usr/brlcad/{rel|dev}-VERSION for ROOT with DATA being simple "ROOT/share/brlcad" ;; and another option that inverts the version so you can install into ROOT as /usr/brlcad with DATA as ROOT/share/brlcad/VERSION |
| 21:18.58 | brlcad | the latter being the one that would allow multi-version installs into a /usr prefix for example |
| 21:21.22 | starseeker | nods |
| 21:23.50 | brlcad | would be nice to have a version management system like 'alternatives' where there's a base root (e.g. /usr or /usr/brlcad) that has symlinks IN /usr/bin or /usr/brlcad/bin to some other place like /usr/share/brlcad/rel-7.20.2/bin/ and you could toggle the symlinks to different versions installed in a given location |
| 21:24.40 | starseeker | could probably add an option to add or not add the symlinks |
| 21:27.01 | starseeker | brlcad: if I may, a stupid question - why do the debug flags require setting via hex numbers? |
| 21:30.41 | ``Erik | debug flags are designed as bit masks, so it's easiest to refer to them in hex... dunno if the parser can take decimal, but bitwise ANDing 32768 and 256 can be a bit tedious |
| 22:14.19 | CIA-43 | BRL-CAD: 03brlcad * r42252 10/brlcad/trunk/src/conv/nastran-g.c: replace commas with a #define COMMA since multichar string literals are not valid to the preprocessor and will be caught more easily during compilation if they get expanded with a space. |
| 22:15.41 | brlcad | starseeker: they are scanf("%x") iirc |
| 22:18.40 | brlcad | plus they are recorded in bu.h and raytrace.h in hex format where they are compact and it's easy to make sure there is no bitwise overlap -- so what you see in the public header is what you can feed to the application |
| 22:41.59 | starseeker | combines environment variable overrides with a test of a local share directory and sees (mostly) success |
| 22:42.32 | starseeker | so be it - the build tree will become a duplicate of the install tree, insofar as it's possible/sensible |
| 23:04.13 | brlcad | awesome, that'll make it really easy to test out a BRL-CAD.app |
| 23:31.28 | CIA-43 | BRL-CAD: 03brlcad * r42253 10/brlcad/trunk/src/fb/ (cat-fb.c fbcolor.c pl-fb.c): more COMMA preprocessor conversions for safety |
| 23:32.19 | CIA-43 | BRL-CAD: 03brlcad * r42254 10/brlcad/trunk/src/ (21 files in 13 dirs): cast size_t's to unsigned long ints during printing, use %zu if it's a bu_log or other bu_* routine since they have support for the 'z' size_t specifier. |
| 00:11.54 | starseeker | O.o http://vimperator.org/vimperator |
| 00:14.05 | starseeker | is torn between a desire to try that and fear that a random key combination or the cat walking on the keyboard would result in changing the entire internet :-P |
| 00:24.58 | ``Erik | neat |
| 00:53.43 | CIA-43 | BRL-CAD: 03brlcad * r42255 10/brlcad/trunk/ (2735 files in 155 dirs): all hail the International Year of Forests, plant ourselves nicely into 2011. tree you later! |
| 01:02.20 | *** join/#brlcad crazy_imp (~mj@a89-182-210-95.net-htp.de) | |
| 02:54.44 | ``Erik | http://www.youtube.com/watch?v=Ex5dhhpSHCw O.O |
| 02:55.47 | ``Erik | d'no how good the overlay matching is, but yowza |
| 02:58.22 | Ralith | Anybody know what happened to jonored's toolpathing utility? |
| 03:02.50 | *** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) | |
| 03:15.52 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 03:31.07 | Ralith | Where's the specification for the current binary database file format stored? |
| 03:33.00 | ``Erik | src/brlcad/librt/ O.o |
| 03:35.20 | ``Erik | http://brlcad.org/wiki/Documentation has a link to an old draft doc, but it's incomplete (and might even be slightly wrong on some things) |
| 03:35.27 | ``Erik | #13 on that page |
| 03:57.00 | Ralith | suspected that was the case; thanks. |
| 03:57.39 | Ralith | ``Erik: so there's no complete doc beyond the code? |
| 04:06.38 | ``Erik | not that I know of... there've been things added and I don't think any docs have been updated to reflect the changes |
| 04:17.44 | Ralith | ah well. |
| 04:18.02 | Ralith | I hope libwdb is being kept in sync, at least. |
| 06:02.55 | CIA-43 | BRL-CAD: 03brlcad * r42256 10/brlcad/trunk/src/mged/mged.c: some cleanup, simplification, and documenting of f_opendb(). |
| 06:04.38 | *** join/#brlcad kanzure_1 (~kanzure@bioinformatics.org) | |
| 06:06.58 | CIA-43 | BRL-CAD: 03brlcad * r42257 10/brlcad/trunk/src/mged/mged.c: use bu_booleanize() to test the value (even though we only looked for ynYN just earlier in this func to pass arg validation. |
| 06:09.52 | brlcad | Ralith: the draft spec is probably more than 99% accurate -- but most access is supposed to go through API instead of directly anyways |
| 06:10.21 | brlcad | libwdb is 100% in sync, it calls through to librt which IS the implementation |
| 06:10.52 | brlcad | libwdb is for write-only access, librt is for slightly lower-level read/write access |
| 06:11.09 | brlcad | libged is for high level read/write access |
| 06:15.08 | Ralith | I see; thanks. |
| 06:44.28 | *** join/#brlcad Stattrav (~Stattrav@122.172.16.143) | |
| 06:44.28 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:13.27 | CIA-43 | BRL-CAD: 03d_rossberg * r42258 10/brlcad/trunk/src/libbu/timetester.c: |
| 10:13.27 | CIA-43 | BRL-CAD: there is no inttypes.h in MSVC |
| 10:13.27 | CIA-43 | BRL-CAD: however it should not be necessary anyway, int64_t has to be declared via bu.h |
| 10:50.00 | *** join/#brlcad mafm (~mafm@17.Red-83-40-127.dynamicIP.rima-tde.net) | |
| 11:32.20 | DaveLo | yawns |
| 12:27.01 | CIA-43 | BRL-CAD: 03Dloman 07http://brlcad.org * r2403 10/wiki/Geometry_Service_Project_Main: Cleaned up verbage, removed some vague hints to functionality now that we are more concrete in our vision. |
| 12:28.06 | DaveLo | Question to brlcad: is it possible to get a GS:: namespace on the wiki? |
| 12:41.05 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:45.59 | starseeker | hmm... libpng 1.5.0 is out |
| 12:46.18 | starseeker | wonder if it's worth trying to upgrade... bet it breaks things |
| 13:10.42 | CIA-43 | BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:Developer 128px.png]]" |
| 13:10.43 | CIA-43 | BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:Users 128px.png]]" |
| 13:19.03 | CIA-43 | BRL-CAD: 03Dloman 07http://brlcad.org * r2406 10/wiki/Geometry_Service_User_Main: New page: Place Holder |
| 13:20.07 | CIA-43 | BRL-CAD: 03Dloman 07http://brlcad.org * r2407 10/wiki/Geometry_Service_Dev_Main: New page: Subbed in! |
| 13:24.53 | CIA-43 | BRL-CAD: 03Dloman 07http://brlcad.org * r2408 10/wiki/Geometry_Service_Project_Main: Add in some purty images in prep for cleanup/reorg |
| 13:36.07 | DaveLo | Hrm, seems the BRL-CAD.org wiki wont accept the syntax for making [[Image: tags accept the |link= override parameter :/ |
| 13:36.13 | DaveLo | thats kinda annoying! |
| 13:37.22 | CIA-43 | BRL-CAD: 03Dloman 07http://brlcad.org * r2409 10/wiki/Geometry_Service_Project_Main: Add some to open up the page a bit (Temporary) |
| 13:44.11 | CIA-43 | BRL-CAD: 03starseeker * r42259 10/brlcad/branches/cmake/ (10 files in 10 dirs): Start updating the CMake logic to re-create the installed file layout, insofar as practical. First step - header placement (cause there are fewer of these). |
| 14:11.55 | *** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de) | |
| 14:49.17 | brlcad | DaveLo: it's a wiki.. so any namespaces, categories, taggings .. if they make sense, then go for it |
| 14:56.59 | CIA-43 | BRL-CAD: 03starseeker * r42260 10/brlcad/branches/cmake/misc/CMakeLists.txt: local copy logic for db and misc - just have db build straight into the share dir target instead of the local binary dir, since they're built targets. |
| 14:57.33 | CIA-43 | BRL-CAD: 03starseeker * r42261 10/brlcad/branches/cmake/doc/html/CMakeLists.txt: Make local copies of the html docs. |
| 15:02.45 | CIA-43 | BRL-CAD: 03starseeker * r42262 10/brlcad/branches/cmake/doc/docbook/ (10 files in 10 dirs): Get docbook generation working in such a way that it puts files in the proper places for build-dir hierarchy. |
| 15:03.20 | brlcad | DaveLo: it's also mediawiki 1.11 so link= just some features might require upgrading to the latest mediawiki |
| 15:03.46 | brlcad | s/just some/and some other/ |
| 15:06.12 | ``Erik | crit has 1.16.1 :D |
| 15:07.10 | DaveLo | Well I ask about the namespace because one must do some editing of LocalSettings.php |
| 15:07.14 | DaveLo | ....which I cannot. |
| 15:10.04 | brlcad | two questions |
| 15:10.30 | brlcad | 1) why does creating a namespace require editing LocalSettings (or more specifically, what edit is needed?) |
| 15:10.38 | brlcad | 2) what makes you think you cannot? |
| 15:11.04 | DaveLo | http://www.mediawiki.org/wiki/Manual:Using_custom_namespaces |
| 15:11.14 | DaveLo | thats the answer to #1 |
| 15:11.35 | DaveLo | and #2 is: I have no idea where the wiki server 'ware is installed, let alone if I have write perms to it. |
| 15:11.47 | DaveLo | otherwise, I'd have done it already :) |
| 15:12.06 | CIA-43 | BRL-CAD: 03Dloman 07http://brlcad.org * r2410 10/wiki/Geometry_Service_Project_Main: Move links to user pages. |
| 15:12.15 | CIA-43 | BRL-CAD: 03Dloman 07http://brlcad.org * r2411 10/wiki/Geometry_Service_User_Main: Moved links from main page |
| 15:12.49 | brlcad | what's the benefit of a namespace over a category? |
| 15:12.54 | brlcad | there's at least one downside ;) |
| 15:13.34 | brlcad | as for 2) it's in the web root and all perms are shared via the www user: sudo -u www |
| 15:15.22 | DaveLo | heh, well i thought that categories == namespaces.... but guess that aint so =D *reads more* |
| 15:15.38 | brlcad | decent page: http://www.packtpub.com/article/mediawiki-content-organizing-features-namespaces-categories |
| 15:16.15 | brlcad | namespace benefit would be to prevent name collisions or assign specific security roles |
| 15:16.24 | brlcad | which I'm not sure is relevant/useful here |
| 15:17.42 | brlcad | with an expanded role, I could see there being a "Geometry" namespace .. looks like it's well-suited for differentiating types of content ala mime typing |
| 15:18.47 | brlcad | category is as simple as adding [[Category:Geometry Service]] to each GS page |
| 15:19.08 | DaveLo | okie cool, I think category tagging will work just fine. danke! |
| 15:20.33 | CIA-43 | BRL-CAD: 03Dloman 07http://brlcad.org * r2412 10/wiki/Geometry_Service_User_Main: Remove Design Doc tag |
| 15:20.36 | CIA-43 | BRL-CAD: 03Dloman 07http://brlcad.org * r2413 10/wiki/Geometry_Service_Project_Main: Remove Design Doc tag |
| 15:21.21 | CIA-43 | BRL-CAD: 03Dloman 07http://brlcad.org * r2414 10/wiki/Geometry_Service_User_Main: Fix Category Tag |
| 15:21.25 | CIA-43 | BRL-CAD: 03Dloman 07http://brlcad.org * r2415 10/wiki/Geometry_Service_Project_Main: Fix Category Tag |
| 15:29.07 | CIA-43 | BRL-CAD: 03bob1961 * r42263 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Move raytracePlus to the public section. |
| 15:31.33 | CIA-43 | BRL-CAD: 03erikgreenwald * r42264 10/brlcad/trunk/src/mged/mged.c: avoid redefine on windows |
| 15:41.49 | *** part/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 16:00.01 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 16:08.47 | CIA-43 | BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:GS Symbol.png]]": (Very) Rough first draft of the Geometry Service logo |
| 16:19.34 | CIA-43 | BRL-CAD: 03Dloman 07http://brlcad.org * r2417 10/wiki/Geometry_Service_Project_Main: Add graphic and section titles. Rearrange a bit. Im thinking the Implementation Particulars could go elsewhere...... |
| 16:22.37 | CIA-43 | BRL-CAD: 03Dloman 07http://brlcad.org * r2418 10/wiki/Geometry_Service_Project_Main: Hrm, looks like a width var on the table is neeed for InternetExplorer |
| 16:23.25 | CIA-43 | BRL-CAD: 03starseeker * r42265 10/brlcad/branches/cmake/db/CMakeLists.txt: Hmm, missed db dir in that commit. |
| 16:24.33 | CIA-43 | BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[IBME Main]]": Antiquated page. Superseded buy the Geometry Service pages |
| 16:34.38 | DaveLo | lol, s/buy/by/ |
| 16:36.08 | CIA-43 | BRL-CAD: 03Dloman 07http://brlcad.org * r2419 10/wiki/Geometry_Service_User_Main: Add graphic + table |
| 16:37.58 | CIA-43 | BRL-CAD: 03Dloman 07http://brlcad.org * r2420 10/wiki/Geometry_Service_Dev_Main: Add graphic + table + links |
| 16:41.09 | CIA-43 | BRL-CAD: 03bob1961 * r42266 10/brlcad/trunk/ (18 files in 5 dirs): Mods for overriding the display manager's auto font selection mechanism. Implemented for ogl and wgl. |
| 16:45.04 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 16:56.11 | CIA-43 | BRL-CAD: 03Dloman 07http://brlcad.org * r2421 10/wiki/URL_URI_URN_Implimentations: Updated URL page with current information |
| 17:14.54 | *** join/#brlcad mafm_ (~mafm@17.Red-83-40-127.dynamicIP.rima-tde.net) | |
| 17:31.09 | DaveLo | http://www.youtube.com/watch?v=kKrtbUinWOU |
| 17:47.12 | brlcad | starseeker: https://sourceforge.net/projects/brlcad/forums/forum/362510/topic/4053804 |
| 18:38.42 | CIA-43 | BRL-CAD: 03starseeker * r42267 10/brlcad/branches/cmake/ (12 files in 12 dirs): More logic for building up the share dir in the build tree. |
| 18:41.48 | starseeker | looks like a bug in ted |
| 18:42.14 | starseeker | doggone it, I'm sick of ted and red |
| 18:55.25 | brlcad | the user might just be running an old buggy version, or it's still busted |
| 18:56.04 | starseeker | it's busted in 16.8 - I don't have a newer workign compile at the moment |
| 18:56.54 | brlcad | can at least ask that user which version they're using since it "should" be fixed with the latest, then you can have them test if they're not on the latest |
| 19:00.21 | starseeker | nods |
| 19:02.11 | brlcad | has apparently worked more than 65 hours this week, and there's still more to go! |
| 19:02.28 | starseeker | eeep! |
| 19:06.35 | starseeker | looks forward to archer/mged making ted obsolete |
| 19:10.49 | brlcad | that's a tough proposition even for archer/mged |
| 19:11.14 | brlcad | implies some seriously well thought out usability and performance efficiency |
| 19:12.35 | brlcad | there's ways to do everything ted can do now without a text editor, even bulk processing tools, but they're still just not as efficient as what an editor will let you do, in bulk, and programmably |
| 19:12.53 | brlcad | just "ted" isn't the best way to do it |
| 19:13.06 | CIA-43 | BRL-CAD: 03starseeker * r42268 10/brlcad/branches/cmake/ (5 files in 5 dirs): Tweaks to accomidate changes resulting from the new logic - get us building again. |
| 19:26.36 | CIA-43 | BRL-CAD: 03brlcad * r42269 10/brlcad/trunk/ (5 files in 2 dirs): separate out the v4 database conversion routines that were oddly in tree.c out into their own db_float.c (since they mostly deal with converting to/from the dbfloat_t type). |
| 19:45.35 | starseeker | yeah, it's a current ted bug |
| 19:47.53 | CIA-43 | BRL-CAD: 03starseeker * r42270 10/brlcad/branches/cmake/ (3 files in 3 dirs): Few more fixes to CMake logic. |
| 19:50.12 | CIA-43 | BRL-CAD: 03erikgreenwald * r42271 10/rt^3/trunk/src/ (6 files in 3 dirs): start stubbing in stuff for a client side lib jar |
| 19:50.24 | starseeker | interesting - ted is still in mged |
| 20:02.10 | CIA-43 | BRL-CAD: 03brlcad * r42272 10/brlcad/trunk/ (5 files in 2 dirs): separate out rt_rpp_region() and rt_bound_tree() into bbox.c so we can consolidate bounding box routines into one place. |
| 20:07.38 | CIA-43 | BRL-CAD: 03brlcad * r42273 10/brlcad/trunk/ (BUGS TODO): ted command needs fixing. |
| 20:08.27 | CIA-43 | BRL-CAD: 03brlcad * r42274 10/brlcad/trunk/TODO: ability to open binary-incompatible v4 databases |
| 20:08.57 | CIA-43 | BRL-CAD: 03brlcad * r42275 10/brlcad/trunk/src/librt/ (bbox.c shoot.c): move rt_in_rpp() into bbox.c given the related functionality, remove the rt_DB_rpp() debugging function. |
| 20:10.43 | CIA-43 | BRL-CAD: 03starseeker * r42276 10/brlcad/trunk/ (NEWS src/mged/tedit.c): |
| 20:10.43 | CIA-43 | BRL-CAD: editit in mged is returning TCL_OK, so check for that when using it in ted; |
| 20:10.44 | CIA-43 | BRL-CAD: without that check, if statement was failing and readsolid was never being |
| 20:10.44 | CIA-43 | BRL-CAD: called - this fixes issue reported by ogloth on the sourceforge forums. |
| 20:11.32 | brlcad | that was quick |
| 20:12.04 | starseeker | luckly, the backtrace was easy to follow on that one :-) |
| 20:13.02 | starseeker | was afraid it would turn into another red-command style rewrite... |
| 20:15.28 | CIA-43 | BRL-CAD: 03brlcad * r42277 10/brlcad/trunk/ (BUGS TODO): ted was fixed quick by starseeker |
| 20:17.20 | CIA-43 | BRL-CAD: 03johnranderson * r42278 10/jbrlcad/trunk/ (124 files in 26 dirs): jbrlcad is now a maven project. |
| 20:19.49 | CIA-43 | BRL-CAD: 03johnranderson * r42279 10/jbrlcad/trunk/src/test/resources/ (. ktank.g logging.config test.asc test.g): Added test/resources. |
| 20:25.55 | CIA-43 | BRL-CAD: 03johnranderson * r42280 10/jbrlcad/trunk/ (5 files in 5 dirs): Eliminated test and lib directories. |
| 21:16.09 | CIA-43 | BRL-CAD: 03starseeker * r42281 10/brlcad/branches/cmake/src/libtclcad/tclcadAutoPath.c: |
| 21:16.09 | CIA-43 | BRL-CAD: May be a few stray files remaining (need a systematic diff) but this is the last |
| 21:16.10 | CIA-43 | BRL-CAD: major piece to create a duplicate of the installed share directory in the build |
| 21:16.10 | CIA-43 | BRL-CAD: dir. tclcadAutoPath simpilfies down to a question of where the root and data |
| 21:16.11 | CIA-43 | BRL-CAD: dirs are, if I'm understanding their usage correctly - I don't think I've got it |
| 21:16.43 | CIA-43 | BRL-CAD: right yet but clearly this should simplify things dramatically. |
| 22:10.49 | CIA-43 | BRL-CAD: 03erikgreenwald * r42282 10/brlcad/trunk/misc/win32-msvc8/libbu/libbu.vcproj: add booleanize |
| 23:42.22 | *** join/#brlcad kanzure2 (~kanzure@131.252.130.248) | |
| 23:46.39 | CIA-43 | BRL-CAD: 03tbrowder2 * r42283 10/brlcad/trunk/src/libged/attr.c: sort attribute-value set array by attribute name |
| 23:50.55 | CIA-43 | BRL-CAD: 03tbrowder2 * r42284 10/brlcad/trunk/NEWS: updated NEWS for adding sort to mged attr show command |
| 00:01.49 | starseeker | Oooo http://www.mail-archive.com/pdcurses-l@lightlink.com/msg00129.html |
| 00:02.04 | starseeker | http://www.projectpluto.com/win32a.htm |
| 00:04.53 | CIA-43 | BRL-CAD: 03tbrowder2 * r42285 10/brlcad/trunk/AUTHORS: added my name and details to developer list |
| 00:06.31 | CIA-43 | BRL-CAD: 03brlcad * r42286 10/brlcad/trunk/NEWS: |
| 00:06.32 | CIA-43 | BRL-CAD: tom added sorting to the mged attr show command so that attributes are now |
| 00:06.32 | CIA-43 | BRL-CAD: displayed in alphabetical order instead of unsorted creation order. should |
| 00:06.33 | CIA-43 | BRL-CAD: improve readability. rewording NEWS line to fit on one line (two line comments |
| 00:06.33 | CIA-43 | BRL-CAD: are the exception when there are multiple authors) and moving to top of stack so |
| 00:07.03 | CIA-43 | BRL-CAD: it's in proper chronological order. |
| 00:08.33 | brlcad | starseeker: give it a try, pick one of the curses apps and try to compile against it by hand |
| 00:09.00 | starseeker | nods |
| 00:09.34 | starseeker | wonders... if that works, why not combine it with something like the netbsd curses library to have one portable curses |
| 00:10.13 | brlcad | because we don't really use curses.. :) |
| 00:10.35 | starseeker | our build requires curses.h though |
| 00:10.45 | brlcad | we use the predecessor that was absorbed into curses |
| 00:11.02 | brlcad | strictly speaking, we don't need curses.h |
| 00:11.10 | starseeker | blinks |
| 00:11.13 | brlcad | it's sufficient, not required |
| 00:11.22 | brlcad | so we look for it |
| 00:11.36 | starseeker | what do we do if it isn't found? |
| 00:11.58 | brlcad | we look for all the other various alternatives |
| 00:12.06 | brlcad | surely you reviewed that part of configure.ac |
| 00:12.17 | brlcad | cmake needs the same logic |
| 00:12.45 | starseeker | yeah - I think I just call the find_package(Curses) logic |
| 00:13.32 | brlcad | we have four main sections in configure.ac written for the search logic needed to do it right |
| 00:14.00 | brlcad | it's not equivalent to just search for curses by any stretch |
| 00:14.09 | starseeker | mutter... |
| 00:14.22 | starseeker | votes we stuff curses in src/other and call it done |
| 00:15.04 | brlcad | if that's less work than adding in the header/lib checks, then the build system has something wrong with it |
| 00:15.23 | brlcad | curses is way overkill |
| 00:15.32 | brlcad | we already have libtermlib which is sufficient for all but windows |
| 00:15.54 | starseeker | ah, so libtermlib is the fallback if all else fails? |
| 00:16.13 | brlcad | you really should be more familiar with the configure.ac |
| 00:16.15 | brlcad | locig |
| 00:16.19 | brlcad | logic! |
| 00:16.25 | starseeker | that part had me somewhat confused |
| 00:16.42 | brlcad | four big sections, follow "curses" |
| 00:18.56 | starseeker | something's gummed up then, 'cause I did a build on Linux with trunk (autotools) and it died due to not having any of the term related headers (iirc) |
| 00:20.05 | starseeker | ah - both HAVE_NCURSES_H and HAVE_TERM_H were not defined |
| 00:22.21 | brlcad | now if you could get *one* curses impl that was cross-platform, that might be a contender for replacing termlib, but it'd need to be small and basically portable to everything |
| 00:22.28 | brlcad | right now, windows is the only odd-ball out |
| 00:22.35 | starseeker | nods |
| 00:23.14 | brlcad | pulling in that win32-specific pdcurses and pdcurses would be a bit ridiculous |
| 00:24.00 | starseeker | shakes his head - pdcurses doesn't sound very good for unix/linux terminals |
| 00:24.05 | brlcad | since termlib is already sufficient, already managed, and has been trivial to maintain |
| 00:24.43 | starseeker | perhaps we can bolt the win32 parts of that win32 native pdcurses onto libtermlib |
| 00:25.23 | starseeker | hrm - libcursor is failing because both of those two HAVE_* defines aren't set |
| 00:25.32 | brlcad | possible, but it'd likely amount to a good bit of libtermlib work -- don't see it just dropping in |
| 00:26.03 | brlcad | libcursor is ours |
| 00:26.26 | starseeker | right, but shouldn't it be falling back on libtermlib in the absence of the other two? |
| 00:30.48 | starseeker | O.o |
| 00:30.51 | brlcad | it does |
| 00:30.58 | starseeker | not here - build haulted |
| 00:31.16 | brlcad | which build? |
| 00:31.22 | starseeker | trunk, autotools |
| 00:31.57 | brlcad | you have to look at the configure testing results |
| 00:32.33 | brlcad | whether it thinks there's a usable library, headers, etc |
| 00:33.18 | brlcad | how it ended up enabling/disabling termblib building |
| 00:33.28 | starseeker | oh, it's enabled |
| 00:33.59 | brlcad | it's got the most complex testing logic because it's the oldest dependency |
| 00:34.48 | brlcad | huh, looks like a HAVE_TERMLIB_H define was removed at some point |
| 00:35.31 | brlcad | ah, no I'm wrong -- it's still there |
| 00:35.42 | starseeker | but am I understanding correctly that with libtermlib enabled, ncurses.h and term.h are not required? |
| 00:35.53 | brlcad | right |
| 00:36.02 | starseeker | so something is haywire |
| 00:36.23 | brlcad | it should be hitting line 3380, which turns on libtermlib aka termcap |
| 00:37.26 | brlcad | everything you need should to figure it out should be in the config log |
| 00:43.04 | starseeker | the termlib functionality tests failed, and libtermlib is enabled |
| 00:45.00 | starseeker | it's almost as if it's only looking at HAVE_NCURSES_H and HAVE_TERM_H without going to the else case on the HAVE_NCURSES_H test |
| 00:49.12 | starseeker | brlcad: it IS turning on libtermlib, and building it. |
| 00:50.08 | brlcad | I presume you mean curses.c is failing compilation? |
| 00:50.19 | starseeker | here's the failed configure test that turned it on: http://pastebin.mozilla.org/941860 |
| 00:50.26 | starseeker | cursor.c |
| 00:50.32 | starseeker | in libcursor |
| 00:50.35 | brlcad | right, that's what I meant |
| 00:51.16 | brlcad | well that error is certainly informative |
| 00:51.44 | brlcad | it's exactly why one should never ignore warnings |
| 00:52.16 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 00:52.17 | brlcad | it's directly reporting no less than two bugs, possibly more |
| 00:52.26 | starseeker | is the problem using if instead of ifdef? |
| 00:59.10 | starseeker | bingo |
| 01:00.00 | starseeker | shakes his head - I thought perhaps you could get away with if or ifdef... |
| 01:02.43 | *** join/#brlcad crazy_imp (~mj@a89-182-28-13.net-htp.de) | |
| 01:03.27 | CIA-43 | BRL-CAD: 03starseeker * r42287 10/brlcad/trunk/src/ (burst/Sc.c libcursor/cursor.c): Fixes to ifdef in cursor.c, expand the logic for Sc.c in burst. |
| 01:04.57 | CIA-43 | BRL-CAD: 03starseeker * r42288 10/brlcad/trunk/configure.ac: fix if->ifdef in configure.ac too... |
| 01:11.24 | starseeker | O.o - that line in libcursor dates back to 2005... apparently a long time since someone's had a system config that hit that case |
| 01:11.42 | starseeker | gets outta here before he gets in any worse trouble... |
| 01:16.53 | brlcad | yeah, that's very VERY curious that the preprocessor skips both the if AND the else clause because it's not defined |
| 01:17.06 | brlcad | but then it warned about it too ;) |
| 01:18.05 | brlcad | that's the first I've seen a preprocessor do that actually.. usually "if empty" will hit the else, that's probably why it never got caught |
| 01:40.26 | ``Erik | interesting, those metaball type errors I was seeing only show up in --enable-optimized |
| 01:49.31 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 02:26.57 | brlcad | yeah, all the uninitialized use warnings only occur during optimized too |
| 02:54.52 | Ralith | hm |
| 02:54.56 | Ralith | can't seem to compile latest svn |
| 03:09.45 | CIA-43 | BRL-CAD: 03tbrowder2 * r42289 10/brlcad/trunk/doc/docbook/system/mann/en/oed.xml: add note about using in a script |
| 03:31.26 | CIA-43 | BRL-CAD: 03brlcad * r42290 10/brlcad/trunk/AUTHORS: rewrite the introduction with more details on the purpose and content of the authorship file. |
| 03:39.14 | CIA-43 | BRL-CAD: 03brlcad * r42291 10/brlcad/trunk/AUTHORS: |
| 03:39.14 | CIA-43 | BRL-CAD: not quite so fast... :) getting listed as a developer is reflective not |
| 03:39.15 | CIA-43 | BRL-CAD: prospective. generally takes several hundred commits over sustained effort. |
| 03:39.15 | CIA-43 | BRL-CAD: you can track progress at http://www.ohloh.net/p/brlcad/contributors in the |
| 03:39.16 | CIA-43 | BRL-CAD: meantime (and you're already credited under code contributors). |
| 03:39.31 | brlcad | Ralith: you have the power to fix that ;) |
| 03:39.44 | Ralith | brlcad: yep, 'cept it didn't seem to be giving me an error O.o |
| 03:39.48 | Ralith | does make redirect stdout/stderr? |
| 03:40.07 | brlcad | make doesn't, but gcc sends different messages to each |
| 03:45.56 | CIA-43 | BRL-CAD: 03brlcad * r42292 10/brlcad/trunk/doc/docbook/system/mann/en/oed.xml: the 'e' command is discouraged in documentation, instead referring to its synonym, 'draw' |
| 03:52.29 | Ralith | well, make was failing with no obvious output whatsoever :/ |
| 03:52.40 | Ralith | is GBS still supported? |
| 03:53.21 | CIA-43 | BRL-CAD: 03starseeker * r42293 10/brlcad/branches/cmake/ (CMakeLists.txt db/CMakeLists.txt doc/CMakeLists.txt): Few left over updates that didn't get committed from the home machine. |
| 03:59.10 | starseeker | woot - broke into top 5 on ohloh |
| 03:59.24 | starseeker | did they start tracking the CMake branch or something? :-P |
| 04:09.02 | Ralith | debug mode didn't compile either O.o |
| 04:20.34 | brlcad | Ralith: --disable-warnings |
| 04:20.45 | brlcad | or fix whatever warning is halting the build |
| 04:21.36 | brlcad | strict build is now enabled on several more directories so it'll be a little while as platforms we don't regularly test on get weeded out |
| 04:27.47 | starseeker | loooves merging in date changes... |
| 04:28.04 | starseeker | one at work apparently didn't go through, trying again |
| 05:03.55 | CIA-43 | BRL-CAD: 03starseeker * r42294 10/brlcad/branches/cmake/ (2749 files in 159 dirs): Update cmake branch to trunk r42293. Also got some preliminary efforts at improving the libtermlib handling in the mix, but they aren't ready yet (probably don't work.) |
| 05:08.11 | Ralith | ah. |
| 05:29.26 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 06:09.14 | *** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net) | |
| 06:09.14 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 07:10.37 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 08:34.30 | *** join/#brlcad WhiteCalf (~MK@whitecalf.net) | |
| 08:41.45 | *** join/#brlcad PrezKennedy (~MK@whitecalf.net) | |
| 08:53.40 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) | |
| 08:58.52 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) | |
| 09:18.51 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 12:42.28 | CIA-43 | BRL-CAD: 03tbrowder2 * r42295 10/brlcad/trunk/doc/docbook/articles/en/oed.xml: add info on used of oed when scripting |
| 12:44.20 | CIA-43 | BRL-CAD: 03tbrowder2 * r42296 10/brlcad/trunk/doc/docbook/system/mann/en/qorot.xml: correct typo |
| 12:50.22 | CIA-43 | BRL-CAD: 03tbrowder2 * r42297 10/brlcad/trunk/src/burst/Hm.c: quell warning about unused function HmPrntLList |
| 12:58.09 | CIA-43 | BRL-CAD: 03tbrowder2 * r42298 10/brlcad/trunk/src/fb/cat-fb.c: remove duplicate assignment (which also quells compiler warning) |
| 12:59.32 | CIA-43 | BRL-CAD: 03tbrowder2 * r42299 10/brlcad/trunk/src/librt/tree.c: correct typo |
| 13:00.51 | CIA-43 | BRL-CAD: 03tbrowder2 * r42300 10/brlcad/trunk/src/util/bwcrop.c: add cast to unsigned to quell compiler warnings |
| 13:02.11 | CIA-43 | BRL-CAD: 03tbrowder2 * r42301 10/brlcad/trunk/HACKING: correct typo; add missing word |
| 13:04.18 | CIA-43 | BRL-CAD: 03tbrowder2 * r42302 10/brlcad/trunk/INSTALL: correct typo; grammar |
| 13:50.39 | CIA-43 | BRL-CAD: 03tbrowder2 * r42303 10/brlcad/trunk/src/conv/g-xxx_facets.c: change main to standard form; add informative output about tesselation parameters |
| 15:50.55 | CIA-43 | BRL-CAD: 03brlcad * r42304 10/brlcad/trunk/src/burst/Hm.c: dead code can be eliminated. revision control has our back. |
| 15:51.13 | brlcad | awesome browder :) |
| 19:06.45 | CIA-43 | BRL-CAD: 03starseeker * r42305 10/brlcad/branches/cmake/src/other/CMakeLists.txt: That's not the way to handle libtermlib. |
| 19:09.04 | starseeker | is going to have to face the fact that he has at least one more major piece of work ahead of him for CMake... |
| 19:14.56 | starseeker | brlcad: I've been studying the termlib logic, and one thing puzzles me a bit - why does the term.h header test need the other headers included? |
| 19:50.18 | CIA-43 | BRL-CAD: 03erikgreenwald * r42306 10/brlcad/branches/bottie/ (3115 files in 225 dirs): MFC 42305 |
| 20:36.05 | *** join/#brlcad waprat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 20:42.05 | *** join/#brlcad epileg1 (~epileg@188.119.210.222) | |
| 21:08.08 | *** join/#brlcad CIA-29 (~CIA@208.69.182.149) | |
| 22:41.20 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 23:44.08 | *** join/#brlcad mafm_ (~mafm@12.Red-80-26-128.dynamicIP.rima-tde.net) | |
| 23:47.35 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 00:12.45 | starseeker | auuuuugh |
| 00:12.58 | starseeker | somehow the cmake tclscripts stuff didn't get committed |
| 01:03.05 | *** join/#brlcad crazy_imp (~mj@a89-182-201-14.net-htp.de) | |
| 01:38.25 | CIA-29 | BRL-CAD: 03starseeker * r42307 10/brlcad/branches/cmake/src/other/libtermlib/CMakeLists.txt: Put etc/termcap in the BRL-CAD data dir, not a toplevel etc - remains to be seen if this will work, but if it can work it's the way to go. |
| 01:39.10 | CIA-29 | BRL-CAD: 03starseeker * r42308 10/brlcad/branches/cmake/src/vfont/CMakeLists.txt: For completeness, duplicate vfont data in build tree. |
| 01:40.58 | CIA-29 | BRL-CAD: 03starseeker * r42309 10/brlcad/branches/cmake/src/tclscripts/ (17 files in 17 dirs): Gah. Committed the libtclcad change, but didn't commit any of the CMakeLists.txt files that might have made it work. Change where things are put in the build tree for tcl scripts. |
| 04:42.29 | CIA-29 | BRL-CAD: 03starseeker * r42310 10/brlcad/branches/cmake/CMakeLists.txt: For now we need Curses in the CMake build, but that needs to be fixed. |
| 05:07.17 | *** join/#brlcad recyclops (~erin@cpe-024-163-114-145.nc.res.rr.com) | |
| 05:29.03 | CIA-29 | BRL-CAD: 03starseeker * r42311 10/brlcad/branches/cmake/src/tclscripts/geometree/CMakeLists.txt: Whoops, spelling error. |
| 05:34.19 | CIA-29 | BRL-CAD: 03starseeker * r42312 10/brlcad/branches/cmake/src/libtclcad/tclcadAutoPath.c: |
| 05:34.19 | CIA-29 | BRL-CAD: Have tclcadAutoPath look for share/brlcad/ - should have the same impact as |
| 05:34.19 | CIA-29 | BRL-CAD: using bu_brlcad_root in the tcl scripts. This has the drawback of only allowing |
| 05:34.19 | CIA-29 | BRL-CAD: the build dir executables to run when run from the build toplevel, so perhaps |
| 05:34.19 | CIA-29 | BRL-CAD: the share/brlcad path should be augmented by knowledge based on the executable |
| 05:34.19 | CIA-29 | BRL-CAD: path and the current working dir... |
| 05:40.23 | CIA-29 | BRL-CAD: 03johnranderson * r42313 10/jbrlcad/trunk/ (4 files in 3 dirs): Runner script now uses maven dependency plugin to construct classpath. |
| 06:02.16 | CIA-29 | BRL-CAD: 03brlcad * r42314 10/brlcad/trunk/BUGS: g2asc+asc2g of .g with colortable fails. |
| 07:23.03 | CIA-29 | BRL-CAD: 03brlcad * r42315 10/brlcad/trunk/configure.ac: |
| 07:23.03 | CIA-29 | BRL-CAD: really can't think of a better way to do this. suggestions? still need to |
| 07:23.03 | CIA-29 | BRL-CAD: verify, but different versions of Mac OS X use different debug symbols types and |
| 07:23.03 | CIA-29 | BRL-CAD: are not in sync with gdb (i.e., -ggdb3 doesn't work across library boundaries on |
| 07:23.03 | CIA-29 | BRL-CAD: 10.4). cheat and call the sw_vers command to get the system version, used that |
| 07:23.03 | CIA-29 | BRL-CAD: to test for a debug debug flag type. |
| 07:34.04 | CIA-29 | BRL-CAD: 03brlcad * r42316 10/brlcad/trunk/ (BUGS src/libged/wdb_obj.c): |
| 07:34.04 | CIA-29 | BRL-CAD: apply a fix for sf bug 3159020 reported by jra regarding asc2g's failure to |
| 07:34.04 | CIA-29 | BRL-CAD: recognize the 'color' command. this was due to libged refactoring where 'db |
| 07:34.04 | CIA-29 | BRL-CAD: color' was no longer valid. this fix restores the migrated commands as |
| 07:34.04 | CIA-29 | BRL-CAD: subcommands of db, iterating over the list and running the command against the |
| 07:34.05 | CIA-29 | BRL-CAD: current wdbp nad stashing the result. should once again be able to successfully |
| 07:34.06 | CIA-29 | BRL-CAD: run: g2asc ktank.g new.asc && asc2g new.asc newtank.g |
| 07:48.20 | CIA-29 | BRL-CAD: 03brlcad * r42317 10/brlcad/trunk/NEWS: |
| 07:48.20 | CIA-29 | BRL-CAD: fixed asc2g color command lines. this is a fix for sf bug 3159020 reported by |
| 07:48.20 | CIA-29 | BRL-CAD: jra where he showed g2asc + asc2g on ktank resulted in an error message. bug |
| 07:48.20 | CIA-29 | BRL-CAD: was due to libged refactoring where 'db color' was no longer valid. the fix |
| 07:48.20 | CIA-29 | BRL-CAD: restored several migrated commands as subcommands of db, iterating over the list |
| 07:48.20 | CIA-29 | BRL-CAD: and running the command against the current wdbp nad stashing the result. |
| 08:25.48 | CIA-29 | BRL-CAD: 03brlcad * r42318 10/brlcad/trunk/src/gtools/g_diff.c: |
| 08:25.48 | CIA-29 | BRL-CAD: seems over-complicated, simplify. just compare the first to the second, and the |
| 08:25.48 | CIA-29 | BRL-CAD: second to the first since all we do is print both if there's a difference. fix |
| 08:25.48 | CIA-29 | BRL-CAD: two bugs in the process, one that caught colortable changes with g2asc + asc2g |
| 08:25.48 | CIA-29 | BRL-CAD: of ktank when there were none due to resetting the wrong found1 var to zero in |
| 08:25.48 | CIA-29 | BRL-CAD: the found2's loop. the second was printing color commands if we're v4. |
| 08:28.31 | CIA-29 | BRL-CAD: 03brlcad * r42319 10/brlcad/trunk/NEWS: |
| 08:28.32 | CIA-29 | BRL-CAD: discovered a bug in g_diff during the testing of jra's g2asc+asc2g ktank bug |
| 08:28.32 | CIA-29 | BRL-CAD: report on colortables. it reported differences where there were none due to |
| 08:28.32 | CIA-29 | BRL-CAD: resetting the wrong variable. also fixed a bug printing color lines for v4, but |
| 08:28.33 | CIA-29 | BRL-CAD: much less noticable. |
| 08:41.16 | Ralith | hacking machine |
| 08:44.12 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 09:49.46 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 10:09.34 | *** join/#brlcad mafm (~mafm@32.Red-83-49-86.dynamicIP.rima-tde.net) | |
| 14:22.58 | *** join/#brlcad electioneered (~erin@cpe-024-163-114-145.nc.res.rr.com) | |
| 15:05.01 | *** join/#brlcad electioneered_ (~erin@cpe-024-163-114-145.nc.res.rr.com) | |
| 15:50.20 | starseeker | brlcad: Can I suggest one file thing for bu_brlcad_root to try? If a path is supplied and not found in the current dir, what about looking in bu_argv0_full_path() - bu_getprogname + ../ ? |
| 15:51.12 | starseeker | (i.e. if the invocation binary is /usr/weirdpath/bin/bwish, the last rule would look in /usr/weirdpath/bin/../ |
| 15:53.15 | starseeker | this would result in a build-dir BRL-CAD being runnable from anywhere the binary is invoked (if I'm thinking about this right) and offhand I'm not seeing how it's any more of a security problem than checking in the current dir after everything has failed. |
| 15:53.58 | starseeker | I'm willing to take a stab at implementing it, but wanted to run it by you first |
| 16:17.26 | brlcad | starseeker: it already does that |
| 16:17.34 | brlcad | third search |
| 16:26.10 | starseeker | brlcad: that's only using bu_getprogname() |
| 16:27.56 | brlcad | not exactly |
| 16:31.03 | brlcad | hm, actually you might have caught something there |
| 16:31.12 | brlcad | getprogname used to return the full path |
| 16:32.43 | brlcad | so when the whereis search moved to a different function, bu_getprogname() isn't the right call any more |
| 16:32.51 | brlcad | root is probably no longer became relocatable |
| 16:33.01 | brlcad | needs some testing |
| 16:34.41 | starseeker | this works for me: |
| 16:34.43 | starseeker | <PROTECTED> |
| 16:34.43 | brlcad | because what you suggest is the third (and most important) search path -- so need to verify what it's actually searching now and what that'll look like with a bu_argv0_full_path() replacement |
| 16:34.43 | starseeker | <PROTECTED> |
| 16:35.59 | starseeker | bu_argv0_full_path will return "." if you invoke in the same dir as the binary, which doesn't help |
| 16:36.27 | brlcad | that sounds like a bug then, doesn't it? |
| 16:36.35 | starseeker | was devoutely hoping so :-P |
| 16:37.43 | starseeker | would be nice if I'm actually beginning to understand this... |
| 16:38.06 | brlcad | like I said, have to diagnose exactly what it's doing presently before changing it in case the code is being misread |
| 16:38.21 | brlcad | specifically, what that third test path looks like |
| 16:40.07 | starseeker | when I debug, it's always just the name of the program (bwish, mged, etc.) |
| 16:43.42 | brlcad | that doesn't sound right |
| 16:43.54 | brlcad | what does the argv0 variable end up being? |
| 16:44.29 | CIA-29 | BRL-CAD: 03starseeker * r42320 10/brlcad/branches/cmake/src/libbu/brlcad_path.c: |
| 16:44.29 | CIA-29 | BRL-CAD: Have bu_brlcad_root take advantage of realpath - bu_getprogname returns no path |
| 16:44.29 | CIA-29 | BRL-CAD: information now, and so is almost completely useless for this purpose. This |
| 16:44.29 | CIA-29 | BRL-CAD: needs more testing and may not be the final 'approved' way to get this working, |
| 16:44.29 | CIA-29 | BRL-CAD: so it's only going into CMake branch for now, but it works in every case tried |
| 16:44.30 | brlcad | the bu_find_path for search 3 |
| 16:44.30 | CIA-29 | BRL-CAD: so far for both installed and build dir. |
| 16:44.48 | starseeker | uh, hang on - I'll revert back and try it |
| 16:48.40 | brlcad | the path searching is critical to understand and get right, not just find something that seems to work |
| 16:50.20 | brlcad | sounds like you have a possible fix, just needs to be validated |
| 16:51.10 | brlcad | one problem though, is that you've added a memory leak |
| 16:51.51 | starseeker | argv0 as fed to bu_find_path for case 3 when starting bwish is: |
| 16:51.53 | starseeker | argv0: bwish |
| 16:54.07 | brlcad | okay, I can see that |
| 16:54.22 | brlcad | never did like that manual trimming off of the binary name |
| 16:56.06 | brlcad | do you see the memory leak? |
| 16:56.46 | starseeker | is looking |
| 16:57.00 | starseeker | checking bu_dirname and realpath to see how they work... |
| 16:57.07 | starseeker | or is it more obvious than that? |
| 16:57.25 | brlcad | also, no need to add another array |
| 16:58.18 | brlcad | ahh, you removed argv0 |
| 16:58.49 | brlcad | the localized array fits the context better since it's just for that tests |
| 16:59.12 | brlcad | bu_dirname returns managed memory, so yeah, that's the problem |
| 16:59.50 | brlcad | can do something similar to what the previous was doing, print into argv0, free the dirname, print into argv0, free the dirname |
| 17:00.44 | brlcad | have to check whether bu_argv0_full_path() is managed memory or not too |
| 17:03.09 | starseeker | wait, if I don't have the real_path array where did you want to return the realpath results to? |
| 17:03.52 | brlcad | "ahh, you removed argv0" |
| 17:04.11 | brlcad | so you really just renamed the array and moved it to the top of the scope |
| 17:04.40 | brlcad | don't care what it's named, but probably doesn't make sense at the top scope |
| 17:05.21 | starseeker | oh, got it |
| 17:05.47 | starseeker | think I stuck it up there 'cause of some C90 complaint about having it lower |
| 17:06.20 | brlcad | dude, you are too funny |
| 17:07.01 | brlcad | your knowledge is getting broad enough to be dangerous but only 2 inches deep ;) |
| 17:07.11 | brlcad | "some c90 complaint" heh |
| 17:08.07 | brlcad | don't fall victim to cargo cult programming: http://en.wikipedia.org/wiki/Cargo_cult_programming |
| 17:09.20 | starseeker | the specific error was forbidding mixed declarations and code |
| 17:09.31 | brlcad | which means what? :) |
| 17:09.52 | starseeker | I had assumed it didn't like the array being declared in the middle of the function |
| 17:10.07 | brlcad | well strictly speaking, that is true |
| 17:10.28 | brlcad | why didn't it complain about the previous argv0 array then? |
| 17:10.38 | starseeker | it was inside an if statement |
| 17:11.34 | brlcad | which is the start of a new scope, so you just need a new scope -- which you should have again if you check your return values |
| 17:11.47 | brlcad | or you could have manually added a new scope even |
| 17:14.41 | starseeker | nods |
| 17:15.17 | starseeker | didn't think it made much of a difference (and I suppose if I'm honest I recall Bob moving a bunch of things to the top to make Windows happy...) |
| 17:15.21 | brlcad | raises another question -- is bu_dirname() or bu_argv0_full_path() capable of returning NULL? |
| 17:15.47 | starseeker | will look - hang on, trying to rework to avoid the memory leak |
| 17:15.51 | brlcad | they're moved to top of scopes, not arbitrary |
| 17:16.23 | brlcad | declarations after logic code will kick off an error only when compiling in strict c90 mode, which we don't so it'd even work for linux/mac |
| 17:16.51 | brlcad | but now that warnings are errors, you can't ignore gcc (which was at least reporting the potential issue) |
| 17:17.04 | starseeker | right |
| 17:17.30 | brlcad | after curlies, even mid-function, declarations are perfectly fine |
| 17:17.34 | starseeker | I knew it was top of scope, I just didn't attach enough importantce to keeping the declaration close to where it was used |
| 17:18.17 | starseeker | (and again to be honest, declaring a new scope mid-code was not something I would have thought of...) |
| 17:18.21 | brlcad | localized data is one of the best changes c++ made |
| 17:18.43 | brlcad | it usually doesn't matter |
| 17:19.44 | brlcad | it's when they're containers for data, particularly buffers of memory, that you run the risk of reuse bugs and memory management problems |
| 17:20.07 | CIA-29 | BRL-CAD: 03starseeker * r42321 10/brlcad/branches/cmake/src/libbu/brlcad_path.c: Localize the real_path var, free bu_dirname results - still need to see if bu_argv0_full_path needs memory management help. |
| 17:21.43 | starseeker | bu_argv0_full_path will not return null (returns "(unknown)" if the header's got it right) |
| 17:24.47 | brlcad | okay, the header is the contract |
| 17:24.50 | brlcad | so you're good there |
| 17:25.30 | starseeker | I don't believe bu_dirname will return NULL - it's not documented as such, but looking at the code I'm not seeing where it would return NULL |
| 17:25.56 | starseeker | I can check for the NULL case regardless, but perhaps bu_dirname should be guaranteed not to return NULL? |
| 17:26.25 | brlcad | looks like it can to me |
| 17:26.47 | brlcad | maybe at least, since it calls getprogname |
| 17:27.12 | starseeker | bu_dirname? |
| 17:27.14 | brlcad | but since it does a null check after, should fall back to (unknown) as well |
| 17:27.28 | brlcad | oh, dirname |
| 17:27.43 | starseeker | which ones did you ask about? |
| 17:27.48 | starseeker | scrolls up... |
| 17:27.51 | brlcad | that's fine |
| 17:28.46 | brlcad | I think you're right |
| 17:29.03 | starseeker | should that be documented in the header then? |
| 17:29.33 | brlcad | sure |
| 17:29.42 | brlcad | looks like the header also fails to mention memory management |
| 17:30.24 | starseeker | is that implied in "returns a pointer to dynamic string"? |
| 17:30.29 | brlcad | especially since it deviates from dirname(2)'s behavior in that regard |
| 17:30.35 | brlcad | ahh, yeah |
| 17:31.09 | brlcad | should probably be more obvious, heh |
| 17:31.21 | brlcad | "Free your memoriees!!!11!" |
| 17:31.40 | starseeker | nods |
| 17:34.50 | brlcad | bu_basename is wrong! |
| 17:35.19 | starseeker | what'd I do? |
| 17:35.20 | CIA-29 | BRL-CAD: 03starseeker * r42322 10/brlcad/branches/cmake/include/bu.h: Clarify the documentation for bu_dirname, explicitly mention no NULL and responsibility to free memory. |
| 17:35.35 | brlcad | you didn't do anything |
| 17:35.38 | brlcad | just saying |
| 17:35.45 | brlcad | bu_basename is wrong :) |
| 17:35.55 | starseeker | oh, I see it |
| 17:36.02 | starseeker | basename.c ? |
| 17:37.14 | starseeker | uh... will that work on Windows? |
| 17:37.26 | brlcad | what? |
| 17:37.35 | starseeker | explicitly uses '/' |
| 17:37.43 | starseeker | isn't there a BU_DIR_SEPARATOR or some such? |
| 17:38.38 | brlcad | it should probably check BU_DIR_SEPARATOR, but didn't have windows to test it out on when it was being written |
| 17:38.55 | starseeker | ah. I take it you saw another problem? |
| 17:39.12 | brlcad | yeah |
| 17:39.24 | brlcad | bu_brlcad_root looks much better now |
| 17:40.14 | brlcad | you going to fix bu_brlcad_data next? :) |
| 17:41.07 | brlcad | (just kidding) |
| 17:41.18 | starseeker | heh |
| 17:41.40 | starseeker | was hoping bu_brlcad_data would follow once root was behaving |
| 17:41.58 | brlcad | data calls root for that case |
| 17:42.13 | starseeker | I see one problem with bu_basename, I think - a/ won't return a |
| 17:42.19 | brlcad | bingo |
| 17:42.54 | starseeker | will sync trunk then with the libbu cmake changes |
| 17:43.28 | starseeker | arguably, is a/ -> a expected? |
| 17:43.33 | starseeker | I suppose it is |
| 17:44.11 | brlcad | it's a drop-in replacement for basename(3), so it should |
| 17:44.47 | brlcad | I think the intent was even supporting cross-platform and no-NULL returns |
| 17:45.13 | brlcad | I have trouble believing that the code was originally written the way it is now.. |
| 17:46.04 | starseeker | heh - well, since it explicitly returns NULL in once case that kinda nullfiies the non-NULL returns |
| 17:46.29 | brlcad | intent, not action :) |
| 17:47.08 | brlcad | bu_basename(NULL) is kind of weird |
| 17:49.19 | brlcad | but sure enough, seems to have been originally written that way |
| 17:49.50 | CIA-29 | BRL-CAD: 03starseeker * r42323 10/brlcad/trunk/ (include/bu.h src/libbu/brlcad_path.c): Fix the behavior of bu_brlcad_root for run-time path identification - was calling bu_getprogname, which no longer returns path information. Also expand header documentation for bu_dirname. |
| 17:50.19 | starseeker | brlcad: does that fall into the user visible category? It's kinda borderline |
| 17:51.53 | CIA-29 | BRL-CAD: 03brlcad * r42324 10/brlcad/trunk/TODO: bu_basename() needs some love |
| 18:00.11 | CIA-29 | BRL-CAD: 03brlcad * r42325 10/brlcad/trunk/include/bu.h: minor rewording since the type of free matters. plus remove the warning since it conflicts with the need to free the memory. |
| 18:00.26 | brlcad | starseeker: I don't think so |
| 18:01.12 | brlcad | it fixes a bug, but not likely one that would have been noticed, and more importantly not a bug with the default install into a specified path |
| 18:01.23 | starseeker | that's what I figured |
| 18:01.48 | brlcad | technically borderline, in that sense you're right, but not practically |
| 18:03.05 | brlcad | http://code.google.com/p/brl-cad-packages/ |
| 18:03.11 | starseeker | by the way - there's a lot of logic in tclcadAutoPath specifically looking at either *_LIBRARY variables or hunting for tcl files - is that due to not being able to rely on the package require mechanism or are there users who actually override that stuff? |
| 18:03.36 | brlcad | yes |
| 18:03.54 | starseeker | heh |
| 18:04.34 | brlcad | and 3) different versions of *tcl behaving differently with how well they use auto_path, tcl var, or env(var) |
| 18:04.57 | brlcad | the snippet I just added a few days ago for archer is a prime example |
| 18:05.21 | brlcad | tcl is ignoring auto_path AND tcl_library during "interp create" |
| 18:05.27 | brlcad | but would respect TCL_LIBRARY |
| 18:06.17 | brlcad | a bug only because it goes through really low-level init routines in tcl that bypass the usual stuff |
| 18:06.45 | starseeker | ah - so if we did our stuff in a .tcl file that was loaded normally, we wouldn't see those issues? |
| 18:07.09 | brlcad | actually, for that particular case, I'm not so sure |
| 18:07.41 | brlcad | archer uses sub-interpreters for some command processing, which gets tricky |
| 18:08.27 | brlcad | if it was system tcl, sure -- because the default low-level searching is basically looking where it was supposed to be installed |
| 18:09.21 | brlcad | similar to our bu_brlcad_* routines actually -- just it was failing to perform a few searches that their docs say it should be performing |
| 18:09.37 | brlcad | good stuff: http://code.google.com/p/brl-cad-packages/downloads/list |
| 18:09.58 | starseeker | hah, sweet |
| 18:11.21 | starseeker | can we at least either ditch the tclcad_tcl_library function or rework it somehow? |
| 18:12.06 | starseeker | it looks like with that bu_brlcad_root fix I might be able to just use the existing logic from trunk, except for that function |
| 18:14.13 | brlcad | can give it a try |
| 18:14.20 | starseeker | ponders... hmm, I wonder if we really need those internal C calls... |
| 18:14.38 | starseeker | to the Tcl docs |
| 18:16.28 | brlcad | if mged runs and starts cleanly from a variety of installs, we're probably good -- the only thing I'd worry about is relying on 8.6 behavior for something that might not work in 8.5 |
| 18:16.37 | brlcad | right now 8.5 is our minimum req |
| 18:16.56 | brlcad | upgrading that to 8.6 might take us out of some package management systems |
| 18:18.37 | starseeker | uh... does tclcad_tcl_library help us avoid requiring 8.6? |
| 18:19.09 | starseeker | has never actually had a successful BRL-CAD run with tcl/tk 8.6, actually |
| 18:19.19 | starseeker | s/never actually/never |
| 18:23.01 | starseeker | hmm, actually I may stand corrected - it's using Tcl internals, but the real trouble might have been the itcl/itk headers |
| 18:23.15 | starseeker | does some experiments in trunk |
| 18:25.13 | starseeker | riping out supports to see how the bridge crashes down... |
| 19:29.52 | starseeker | yeah, still valid concern on the use of internal functions but the build-haulting issues were due to itcl/itk header inclusion |
| 19:31.27 | CIA-29 | BRL-CAD: 03starseeker * r42326 10/brlcad/trunk/src/libtclcad/tclcadAutoPath.c: Tweak includes for tclcadAutoPath.c - I think this may be a version both the CMake build and autotools build can live with, but needs more testing. |
| 19:33.10 | CIA-29 | BRL-CAD: 03starseeker * r42327 10/brlcad/branches/cmake/src/libtclcad/tclcadAutoPath.c: Sync tclcadAutoPath.c with trunk's version - trying to get a version both can live with/use. |
| 20:49.34 | CIA-29 | BRL-CAD: 03starseeker * r42328 10/brlcad/branches/cmake/ (17 files in 12 dirs): Update cmake branch to trunk r42327 |
| 20:53.36 | *** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net) | |
| 20:53.36 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 20:56.32 | CIA-29 | BRL-CAD: 03starseeker * r42329 10/brlcad/branches/cmake/src/other/libtermlib/CMakeLists.txt: Put the termcap stuff where it belongs. |
| 21:11.00 | CIA-29 | BRL-CAD: 03starseeker * r42330 10/brlcad/branches/cmake/ (930 files in 930 dirs): |
| 21:11.00 | CIA-29 | BRL-CAD: Sure as heck don't want to merge THIS change into trunk, but in principle the |
| 21:11.00 | CIA-29 | BRL-CAD: CMake branch should be leaving a pristine tree behind it. Set all svn ignore |
| 21:11.00 | CIA-29 | BRL-CAD: properties to empty - if I got this right we should see ANY files that appear in |
| 21:11.00 | CIA-29 | BRL-CAD: the source branch after a build. |
| 21:14.24 | CIA-29 | BRL-CAD: 03brlcad * r42331 10/brlcad/trunk/AUTHORS: special thanks to jordi sayol for making 32-bit and 64-bit .deb files for release 7.18.0 |
| 21:18.36 | CIA-29 | BRL-CAD: 03starseeker * r42332 10/brlcad/trunk/misc/enigma/ (Makefile.am crypt.c enigma.c): |
| 21:18.36 | CIA-29 | BRL-CAD: The enigma stuff from CMake should be harmless - trunk doesn't build enigma on |
| 21:18.36 | CIA-29 | BRL-CAD: Windows, and it would need the stuff if it did - even though this isn't working, |
| 21:18.36 | CIA-29 | BRL-CAD: it's at least a start. Sync it to bring the two branches closer. |
| 21:20.22 | brlcad | o.O ... brlcad_config.h ? |
| 21:20.43 | brlcad | shouldn't ever be including that file directly |
| 21:20.51 | brlcad | distcheck should have caught that |
| 21:22.40 | starseeker | ah, my bad |
| 21:24.10 | CIA-29 | BRL-CAD: 03starseeker * r42333 10/brlcad/trunk/src/libtclcad/tclcadAutoPath.c: Whoops - don't include brlcad_config.h directly. |
| 21:34.21 | CIA-29 | BRL-CAD: 03starseeker * r42334 10/brlcad/branches/cmake/ (5 files in 4 dirs): Sync cmake to trunk r42333. |
| 21:36.05 | CIA-29 | BRL-CAD: 03starseeker * r42335 10/brlcad/branches/cmake/AUTHORS: Hmm, AUTHORS wasn't fully synced. fix |
| 21:48.17 | CIA-29 | BRL-CAD: 03starseeker * r42336 10/brlcad/branches/cmake/src/tclscripts/ (23 files in 12 dirs): Add canned pkgIndex.tcl files and tclIndex files from trunk - won't need them for CMake (if the generation routines work correctly) but trunk needs 'em. |
| 21:51.28 | CIA-29 | BRL-CAD: 03starseeker * r42337 10/brlcad/branches/cmake/src/util/pixrect.c: pixrect.c change slipped through. |
| 21:52.15 | CIA-29 | BRL-CAD: 03starseeker * r42338 10/brlcad/branches/cmake/src/other/libz/ (12 files): No significant differences here, but sync to avoid cluttering diffs. |
| 21:59.20 | CIA-29 | BRL-CAD: 03starseeker * r42339 10/brlcad/branches/cmake/src/other/libz/contrib/minizip/Makefile: Add file present in trunk |
| 22:02.36 | CIA-29 | BRL-CAD: 03starseeker * r42340 10/brlcad/branches/cmake/src/other/libz/contrib/iostream2/zstream.h: another minor sync from libz |
| 22:18.41 | CIA-29 | BRL-CAD: 03starseeker * r42341 10/brlcad/trunk/ (7 files in 7 dirs): Put iwidgets in the incrTcl subdirectory, since they're associated with that proejct. |
| 22:21.17 | CIA-29 | BRL-CAD: 03starseeker * r42342 10/brlcad/trunk/src/other/incrTcl/Makefile.am: Whoops, use the variable. |
| 22:24.00 | CIA-29 | BRL-CAD: 03starseeker * r42343 10/brlcad/trunk/src/other/ (Makefile.am incrTcl/Makefile.am): Move itcl into the incrTcl subdir as well. |
| 22:25.09 | CIA-29 | BRL-CAD: 03starseeker * r42344 10/brlcad/trunk/src/other/incrTcl/Makefile.am: change ITCLDIR to actually be the itcl dir. |
| 22:31.34 | CIA-29 | BRL-CAD: 03starseeker * r42345 10/brlcad/branches/cmake/ (6 files in 6 dirs): Grab some of the changes from trunk - incrTcl is hopelessly messed up between cmake and trunk, so will probably have to script out CMake's and put trunk's in place. |
| 22:34.42 | CIA-29 | BRL-CAD: 03starseeker * r42346 10/brlcad/branches/cmake/src/other/incrTcl/iwidgets/.cvsignore: stray .cvsigonre file |
| 22:40.29 | Ralith | Is there some way to get a sketch corresponding to the intersection between a plane and a region? |
| 22:43.36 | brlcad | Ralith: depends what kind of sketch |
| 22:43.48 | starseeker | um... intersect a thin arb8 with the region and use rtedge? |
| 22:43.49 | brlcad | you can get a cross-section hidden-line rendering very easily |
| 22:44.31 | brlcad | starseeker: curious move with iwidgets... |
| 22:44.45 | starseeker | it's associated with the incrtcl project on sourceforge |
| 22:44.47 | brlcad | they're certainly related, but iwidgets isn't part of incrTcl |
| 22:45.05 | Ralith | brlcad: I mean as in a sketch primitive |
| 22:45.26 | brlcad | Ralith: then no, not outside of manual methods |
| 22:45.31 | Ralith | :/ |
| 22:45.39 | brlcad | http://incrtcl.cvs.sourceforge.net/incrtcl/ |
| 22:45.42 | brlcad | separate module |
| 22:46.01 | brlcad | would be like putting rt^3 underneath a brlcad checkout |
| 22:46.10 | brlcad | they're related, but not in that way |
| 22:46.18 | starseeker | hmm. |
| 22:46.31 | brlcad | no biggie either way, just odd |
| 22:46.48 | brlcad | src/other/incrTcl is no longer the incrTcl source tarball |
| 22:47.05 | starseeker | our trunk incrTcl hasn't been for a long time, as understand it |
| 22:47.11 | starseeker | ``Erik made a lot of changes |
| 22:47.30 | brlcad | quantify "a lot" |
| 22:47.54 | starseeker | I'd have to do diffs - was based on conversation with him at work about it |
| 22:47.55 | brlcad | we have a Makefile.am, and maybe a dozen lines |
| 22:48.04 | starseeker | he said he pulled stuff out of cvs |
| 22:48.09 | starseeker | not just the tarballs |
| 22:48.36 | starseeker | CMake branch does use the vanilla source - that's what prompted the itk_defines.tcl file for archer |
| 22:48.38 | brlcad | that's not a lot of mods then |
| 22:49.03 | brlcad | source tarball == source checkout in this particular instance, doesn't matter that the .tar.gz is out of date |
| 22:49.11 | brlcad | their code vs our code |
| 22:49.52 | brlcad | or if it suits the conversation better, "our trunk incrTcl is no longer an incrTcl source checkout (+ our Makefile.am)" |
| 22:50.08 | starseeker | ok |
| 22:50.56 | brlcad | like I said, minor point, I don't care strongly on it |
| 22:50.57 | starseeker | so do I have your OK to make incrTcl a vanilla cvs checkout/tarball + Makefile.am? That's what I'd prefer to do, and then work around issues using itk_defines.tcl and the like |
| 22:51.34 | brlcad | that's close to what it is now |
| 22:51.56 | brlcad | if it's not, sure |
| 22:52.00 | starseeker | sweet |
| 22:52.07 | starseeker | I'll revert back to the original structure then |
| 22:53.54 | brlcad | looking through the logs, the only recent mod I see other than our Makefile.am, was to make it work with tcl/tk 8.4 out of the box, 8.4 compat headers |
| 22:54.22 | brlcad | requirement is since upped to 8.5, so no longer relevant |
| 22:54.27 | starseeker | nods |
| 22:55.41 | brlcad | erik's upgrade to cvs was in 2007 |
| 22:56.24 | starseeker | alrightie |
| 22:56.53 | starseeker | given a choice between tarballs and cvs, do you have a preference? |
| 22:57.04 | brlcad | cvs |
| 22:57.23 | brlcad | unless they updated the tarball recently |
| 22:57.58 | starseeker | not really - 2009 for itcl |
| 22:58.16 | brlcad | so it's at least a tarball 2 years newer, but still 2 years behind |
| 22:58.39 | brlcad | not beenmany commits since then |
| 22:58.54 | starseeker | nope - what new work has been going on I think is in the 4.0 branch |
| 22:58.54 | brlcad | but does have an updated TEA |
| 22:59.02 | brlcad | http://www.ohloh.net/p/incrtcl/commits |
| 22:59.11 | brlcad | 5 commits |
| 22:59.35 | brlcad | could ask them which they recomment |
| 22:59.37 | brlcad | could ask them which they recommend |
| 22:59.47 | brlcad | but I suspect 4.0 is going to req. 8.6 |
| 22:59.52 | starseeker | yes |
| 23:00.02 | starseeker | uses the new tclOO setup, iirc |
| 23:01.45 | brlcad | if it gave us some benefit, I'd say go for it .. but i'm not sure there is any yet |
| 23:01.59 | brlcad | by the time they're done, it might just get absorbed |
| 23:02.35 | starseeker | which, 4.0? |
| 23:02.43 | brlcad | hmmm... this one might need to be kept or pushed upstream: svn log -r27960:27959 src/other/incrTcl |
| 23:02.47 | brlcad | 4.0 |
| 23:03.44 | starseeker | yeah, I don't think we're ready for 8.6 yet |
| 23:04.09 | starseeker | would vastly prefer to not be using the C itcl/itk api for the next run at 8.6 |
| 23:05.12 | brlcad | wow .. I apparently made that change, but totall don't remember it |
| 23:05.51 | brlcad | the crash I vaguely recall, and it was hard -- so should be easy to see if the patch is still needed |
| 23:06.52 | starseeker | has half a notion to ditch the mess for tkpng in LoadArcherLibs.tcl and require that package require tkpng Just Work... ick |
| 23:07.25 | brlcad | that's how it should be |
| 23:07.34 | brlcad | the loading of the .so directly was just a halfassing |
| 23:09.46 | starseeker | brlcad: do you recall if we tried to push the itcl patch upstream at the time? |
| 23:21.27 | CIA-29 | BRL-CAD: 03starseeker * r42347 10/brlcad/trunk/ (687 files in 19 dirs): Put iwidgets back - might as well match the incrTcl cvs project hierarchy. |
| 23:33.06 | starseeker | mutter - looks like we still need that patch |
| 23:33.54 | starseeker | brlcad: it wasn't something about the way we were doing itcl/itk logic that could be changed? |
| 23:34.26 | starseeker | must admit it doesn't look like it based on C patches |
| 23:36.41 | CIA-29 | BRL-CAD: 03starseeker * r42348 10/brlcad/trunk/src/tclscripts/archer/LoadArcherLibs.tcl: Use package require tkpng. If it's not working, let's figure out why. |
| 23:38.42 | CIA-29 | BRL-CAD: 03starseeker * r42349 10/brlcad/branches/cmake/ (6 files in 6 dirs): Put itcl/itk logic back, pull in trunk's LoadArcherLibs.tcl. |
| 23:40.49 | starseeker | Odd... I'm using system tcl/tk and itcl/itk here, and Archer is coming up and will bring up the preferences dialog... I think we took out the comb editor in its old form, so probably can't test that... |
| 23:42.06 | starseeker | ah, mged |
| 23:47.54 | starseeker | with system itcl/itk and tcl/tk on gentoo combination editor comes up, but of course they may be patched |
| 23:49.08 | starseeker | huh, weird |
| 23:55.01 | starseeker | don't see a patch specific to that issue... may be missing it |
| 23:55.14 | starseeker | goes on dinner run |
| 01:03.27 | *** join/#brlcad crazy_imp (~mj@a89-182-3-165.net-htp.de) | |
| 01:05.27 | CIA-29 | BRL-CAD: 03johnranderson * r42350 10/brlcad/trunk/src/util/Makefile.am: bwhist needs libbu. |
| 01:09.46 | CIA-29 | BRL-CAD: 03johnranderson * r42351 10/brlcad/trunk/ (26 files in 5 dirs): fixed a bunch of size_t issues. |
| 01:55.21 | CIA-29 | BRL-CAD: 03johnranderson * r42352 10/brlcad/trunk/src/conv/asc/g2asc.c: |
| 01:55.21 | CIA-29 | BRL-CAD: The region color table is no longer output as part of the GLOBAL object. |
| 01:55.21 | CIA-29 | BRL-CAD: If no attributes of the GLOBAL object are output, the GLOBAL object itself is not output. |
| 01:55.21 | CIA-29 | BRL-CAD: fixed some size_t issues. |
| 02:37.41 | CIA-29 | BRL-CAD: 03starseeker * r42353 10/brlcad/branches/cmake/ (30 files in 8 dirs): Update cmake to trunk r42352 |
| 02:44.15 | brlcad | starseeker: I don't remember what the problem was beyond what's in the commit log |
| 02:44.32 | brlcad | vague recollection that tcl/tk had to be patched too so there might be a commit log message there with more info |
| 03:52.51 | CIA-29 | BRL-CAD: 03johnranderson * r42354 10/brlcad/trunk/doc/docbook/log4j.properties: Added a configuration for log4j to stop the constant blather about it not being configured. |
| 04:49.52 | CIA-29 | BRL-CAD: 03starseeker * r42355 10/brlcad/trunk/src/other/incrTcl/ (4 files in 4 dirs): Tcl 8.4 doesn't cut it anymore, so we shouldn't need the compat headers. |
| 04:53.49 | CIA-29 | BRL-CAD: 03starseeker * r42356 10/brlcad/trunk/src/other/incrTcl/makefile.bc: makefile.bc isn't present in cvs incrtcl anymore. |
| 05:23.33 | CIA-29 | BRL-CAD: 03starseeker * r42357 10/brlcad/trunk/src/other/incrTcl/ (13 files in 5 dirs): Start merging in changes from latest cvs incrTcl - will try to do this carefully, as there are a few changes that will need to be preserved. |
| 05:27.58 | starseeker | hah - itcl/itk upstream DID take the patch |
| 05:28.01 | starseeker | http://incrtcl.cvs.sourceforge.net/viewvc/incrtcl/incrTcl/itcl/generic/itcl_methods.c?r1=1.20&r2=1.21 |
| 05:28.13 | starseeker | sweet |
| 05:34.13 | CIA-29 | BRL-CAD: 03starseeker * r42358 10/brlcad/trunk/src/other/incrTcl/itcl/ (14 files in 5 dirs): Remainder of changes from itcl subdir - itcl/itk upstream applied changes made to itcl_methods.c, so they are no longer a local BRL-CAD mod. |
| 05:35.35 | CIA-29 | BRL-CAD: 03starseeker * r42359 10/brlcad/trunk/src/other/incrTcl/itcl/doc/Makefile.am: Add new man pages to makefile.am |
| 05:37.18 | CIA-29 | BRL-CAD: 03starseeker * r42360 10/brlcad/trunk/src/other/incrTcl/itk/ (4 files in 3 dirs): Just a few changes in the itk subdir |
| 05:42.32 | CIA-29 | BRL-CAD: 03starseeker * r42361 10/brlcad/trunk/src/other/incrTcl/ (9 files in 2 dirs): Most of the remaining changes should be captured here. |
| 05:45.53 | CIA-29 | BRL-CAD: 03starseeker * r42362 10/brlcad/trunk/src/other/incrTcl/ (4 files in 4 dirs): Files not present in cvs incrTcl |
| 05:48.49 | CIA-29 | BRL-CAD: 03starseeker * r42363 10/brlcad/trunk/src/other/incrTcl/itk/library/pkgIndex.tcl: Probably need this pre-generated file for our current Windows build... |
| 05:55.48 | starseeker | that must be why my system setup is working... |
| 05:56.24 | CIA-29 | BRL-CAD: 03starseeker * r42364 10/brlcad/trunk/src/other/iwidgets/ (246 files in 11 dirs): Sync iwidgets with latest cvs - mostly whitespace in this one. |
| 05:59.02 | CIA-29 | BRL-CAD: 03starseeker * r42365 10/brlcad/trunk/src/other/iwidgets/pkgIndex.tcl.in: Ah, right - use our variable. |
| 06:01.02 | CIA-29 | BRL-CAD: 03starseeker * r42366 10/brlcad/trunk/src/other/iwidgets/iwidgets.tcl.in: Use our version of iwidgets.tcl.in too |
| 06:03.25 | CIA-29 | BRL-CAD: 03starseeker * r42367 10/brlcad/trunk/src/other/iwidgets/ (Makefile.am tcl.m4): Remove tcl.m4 - no longer in cvs. |
| 06:09.55 | CIA-29 | BRL-CAD: 03starseeker * r42368 10/brlcad/branches/cmake/src/other/incrTcl/ (8 files in 6 dirs): Wipe the incrTcl slate clean in CMake branch. Need to get trunk's version in here and working. |
| 06:18.25 | CIA-29 | BRL-CAD: 03starseeker * r42369 10/brlcad/trunk/src/other/incrTcl/itcl/generic/itclInt.h: We still need common.h in itclInt.h |
| 06:24.20 | CIA-29 | BRL-CAD: 03starseeker * r42370 10/brlcad/branches/cmake/src/other/incrTcl/ (189 files in 22 dirs): Put trunk's version of incrTcl in cmake - need to add back in CMake logic. |
| 06:29.36 | CIA-29 | BRL-CAD: 03starseeker * r42371 10/brlcad/branches/cmake/src/other/incrTcl/ (15 files in 4 dirs): Restore old CMake logic |
| 06:32.33 | CIA-29 | BRL-CAD: 03starseeker * r42372 10/brlcad/trunk/src/util/bw-imp.c: Cast size_t to int for printing. |
| 06:37.08 | CIA-29 | BRL-CAD: 03starseeker * r42373 10/brlcad/trunk/src/other/incrTcl/ (Makefile.am itk/Makefile.am): Update incrTcl makefiles |
| 06:42.49 | CIA-29 | BRL-CAD: 03starseeker * r42374 10/brlcad/branches/cmake/src/other/ (346 files in 15 dirs): Add iwidgets dir from trunk |
| 06:50.05 | CIA-29 | BRL-CAD: 03starseeker * r42375 10/brlcad/branches/cmake/src/other/incrTcl/itcl/CMakeLists.txt: Mutter - need the brlcad include dir due to common.h inclusion |
| 06:58.31 | CIA-29 | BRL-CAD: 03starseeker * r42376 10/brlcad/branches/cmake/src/other/incrTcl/itk/CMakeLists.txt: itk needs common.h too |
| 07:04.00 | CIA-29 | BRL-CAD: 03starseeker * r42377 10/brlcad/branches/cmake/ (6 files in 6 dirs): Update cmake branch to trunk r42376 |
| 07:27.22 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) | |
| 07:33.24 | CIA-29 | BRL-CAD: 03starseeker * r42378 10/brlcad/trunk/ (4 files in 3 dirs): autotools build needs a pkgIndex.tcl for tkpng, provide it. |
| 07:35.34 | CIA-29 | BRL-CAD: 03starseeker * r42379 10/brlcad/branches/cmake/ (6 files in 4 dirs): Sync cmake to trunk r42378 |
| 07:39.01 | CIA-29 | BRL-CAD: 03starseeker * r42380 10/brlcad/trunk/ (configure.ac src/other/tkpng/generic/tkImgPNGInit.c): Go with 0.8, since that was what was in the source file - bit confusing, since the ChangeLog seems to have tagged 0.9? |
| 07:40.39 | CIA-29 | BRL-CAD: 03starseeker * r42381 10/brlcad/branches/cmake/ (4 files in 3 dirs): sync cmake to r42380 |
| 07:46.07 | CIA-29 | BRL-CAD: 03starseeker * r42382 10/brlcad/branches/cmake/AUTHORS: Thought I got this - sync CMake copy of AUTHORS file. |
| 07:56.16 | CIA-29 | BRL-CAD: 03starseeker * r42383 10/brlcad/branches/cmake/src/gtools/g_diff.c: Put the trunk version of g_diff back, now that we're using trunk's tclcad |
| 07:57.01 | starseeker | ah, getting down to the last pieces, mostly having to do with config header files and using package require Itcl instead of C apis |
| 09:10.04 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 09:57.50 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 11:55.23 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:33.49 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 12:38.48 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 12:41.12 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 12:45.48 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 12:47.44 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 12:50.59 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 12:56.06 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 12:58.39 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 13:05.04 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 13:06.51 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 13:09.19 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 13:10.27 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 13:12.41 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 13:17.22 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 13:21.58 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 13:25.23 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 13:31.54 | *** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de) | |
| 13:31.59 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 13:35.03 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 13:39.22 | CIA-29 | BRL-CAD: 03starseeker * r42384 10/brlcad/trunk/src/libtclcad/tclcadAutoPath.c: Typo. |
| 13:40.40 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 13:44.39 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 13:44.53 | CIA-29 | BRL-CAD: 03starseeker * r42385 10/brlcad/branches/cmake/src/mged/setup.c: Try to move mged's setup.c closer to trunk version. |
| 13:50.13 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 13:54.50 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 14:00.25 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 14:07.06 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 14:08.19 | CIA-29 | BRL-CAD: 03starseeker * r42386 10/brlcad/trunk/src/mged/ (attach.c cmd.c setup.c): Try using the package require statements for itcl/itk in MGED. |
| 14:09.42 | CIA-29 | BRL-CAD: 03starseeker * r42387 10/brlcad/trunk/doc/docbook/Makefile.am: Add log4j.properties to EXTRA_DIST |
| 14:10.25 | *** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net) | |
| 14:14.05 | CIA-29 | BRL-CAD: 03starseeker * r42388 10/brlcad/trunk/src/other/ (4 files in 4 dirs): Changes to allow CMake + Visual C++ to work on Windows - should have zero impact on any build except CMake. |
| 14:15.02 | CIA-29 | BRL-CAD: 03starseeker * r42389 10/brlcad/branches/cmake/src/other/ (6 files in 6 dirs): Wrap the CMake generated headers in a define that is only set in the CMake build. |
| 14:28.02 | CIA-29 | BRL-CAD: 03starseeker * r42390 10/brlcad/branches/cmake/src/bwish/main.c: Tweaks |
| 14:29.52 | CIA-29 | BRL-CAD: 03starseeker * r42391 10/brlcad/trunk/src/bwish/ (cadAppInit.c main.c): Try using package require for itcl/itk in bwish |
| 14:31.11 | CIA-29 | BRL-CAD: 03starseeker * r42392 10/brlcad/trunk/src/libtclcad/tclcad.c: Same deal for tclcad.c - try using package require. |
| 14:35.40 | CIA-29 | BRL-CAD: 03starseeker * r42393 10/brlcad/branches/cmake/src/ (5 files in 2 dirs): Put itk_redefines.tcl with the other archer tcl scripts |
| 14:37.37 | CIA-29 | BRL-CAD: 03starseeker * r42394 10/brlcad/branches/cmake/src/tclscripts/archer/CMakeLists.txt: Put lower case at end, bit easier to find things. |
| 14:38.28 | CIA-29 | BRL-CAD: 03starseeker * r42395 10/brlcad/trunk/src/ (3 files in 2 dirs): Put itk_redefines.tcl into trunk version of archer |
| 14:49.10 | *** join/#brlcad Stattrav (~Stattrav@117.202.27.44) | |
| 14:49.10 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:49.58 | CIA-29 | BRL-CAD: 03starseeker * r42396 10/brlcad/trunk/include/ (Makefile.am config_win_cmake.h): Add a config_win header that will work with cmake - for now this looks like the simplest way to make both systems happy, but eventually config_win_cmake.h will become config_win.h |
| 14:50.46 | CIA-29 | BRL-CAD: 03starseeker * r42397 10/brlcad/branches/cmake/ (4 files in 2 dirs): Use config_win_cmake.h for CMake build. |
| 14:54.03 | CIA-29 | BRL-CAD: 03starseeker * r42398 10/brlcad/branches/cmake/ (6 files in 6 dirs): Update cmake to trunk r42397 |
| 15:01.00 | CIA-29 | BRL-CAD: 03starseeker * r42399 10/brlcad/trunk/include/common.h: Tweak common.h from CMake and add to trunk. |
| 15:03.30 | CIA-29 | BRL-CAD: 03starseeker * r42400 10/brlcad/branches/cmake/ (. CMakeLists.txt include/common.h src/other/tkhtml/): Hopefully this will allow the same common.h to be used in both cmake and autotools. |
| 15:05.41 | starseeker | and if everything's working, that should do it |
| 15:06.00 | starseeker | except for the CMake logic, that ought to sync both trees |
| 15:06.11 | starseeker | now for distcheck, etc. |
| 15:34.29 | CIA-29 | BRL-CAD: 03starseeker * r42401 10/brlcad/trunk/src/tclscripts/archer/Makefile.am: need file extension |
| 15:50.25 | CIA-29 | BRL-CAD: 03d_rossberg * r42402 10/brlcad/trunk/ (configure.ac src/libbu/brlcad_path.c): there is no realpath() in MSVC, so replaced it by a trivial string-copy then |
| 16:03.37 | brlcad | re 42382 -- you did get it but then you undid it with a subsequent commit saying you didn't match trunk |
| 16:03.52 | brlcad | your diff was probably not against an up-to-date checkout |
| 16:07.12 | CIA-29 | BRL-CAD: 03brlcad * r42403 10/brlcad/trunk/src/util/bw-imp.c: keep the cast size as large as possible, fix the format |
| 16:08.34 | starseeker | ah, whoops |
| 16:12.52 | starseeker | growls... apparently there is no good solution for something like realpath on Windows |
| 16:16.08 | starseeker | oh well |
| 16:19.14 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:19.26 | starseeker | yeah, these guys pretty much punt: https://www.securecoding.cert.org/confluence/display/seccode/FIO02-C.+Canonicalize+path+names+originating+from+untrusted+sources |
| 16:20.20 | starseeker | and the closest thing isn't recommended for use in multithreaded applications or shared library code by Microsoft: http://msdn.microsoft.com/en-us/library/aa364963%28VS.85%29.aspx |
| 16:20.21 | ``Erik | looks like there's a com idl for it |
| 16:20.34 | starseeker | hmm? |
| 16:20.34 | ``Erik | IShellLink |
| 16:20.57 | ``Erik | has a GetPath() method, dunno what the C approach is |
| 16:22.23 | ``Erik | I'm seeing c# and delphi ways to do it without the com bridge to the 'power shell' thingie |
| 16:23.03 | starseeker | give the issue mainly shows up when running build dir binaries and that other fallbacks should (mostly) cover the Windows cases, I'm thinking a huge effort is probably not needed |
| 16:23.32 | starseeker | cygwin command line might be the main issue, and I would guess they have a realpath? |
| 16:24.13 | ``Erik | there was a patch to try to give it a better approach I saw googling, under the mingw32 set I think |
| 16:28.07 | CIA-29 | BRL-CAD: 03starseeker * r42404 10/brlcad/branches/cmake/ (7 files in 5 dirs): Update cmake branch to r42403, add realpath check to CMakeLists.txt |
| 16:35.39 | starseeker | hmm... http://msdn.microsoft.com/en-us/library/aa364962%28v=VS.85%29.aspx |
| 16:38.19 | starseeker | or perhaps http://msdn.microsoft.com/en-us/library/aa364966%28v=VS.85%29.aspx |
| 16:39.36 | starseeker | well, if we need to we'll go there |
| 16:39.41 | starseeker | but only if we need to |
| 16:42.27 | brlcad | you could implement a bu_normalize() function |
| 16:42.53 | brlcad | which could call realpath() or implement it if unavailable |
| 16:43.23 | starseeker | nods - that would be the way to go, if it's needed |
| 16:43.56 | starseeker | give we were surviving without the rule working at all, I'm thinking we should expend that effort only when there's a clear need |
| 16:44.15 | brlcad | sure |
| 16:44.31 | brlcad | didn't know if you were addressing an issue by adding realpath() in the first palce |
| 16:44.59 | starseeker | was addressing the "I can't run my build dir archer script in the CMake build" issue :-P |
| 16:45.27 | brlcad | how does realpath fix that? |
| 16:45.47 | brlcad | gets the absolute path of something? |
| 16:45.52 | brlcad | that was relative |
| 16:45.56 | starseeker | yes |
| 16:46.17 | starseeker | if I ran (say) ../../bin/bwish, the argv0 full path was that |
| 16:46.34 | brlcad | bu_argv0_full_path() shouldn't have been that |
| 16:48.06 | brlcad | if it was, it's a bug that needs to be fixed |
| 16:48.17 | starseeker | checks... |
| 16:49.53 | brlcad | now, bu_argv0_full_path() could/should be calling realpath() in its implementation, but it just appends relative to pwd now (punts, but a valid absolute path) |
| 16:50.34 | starseeker | yeah, launching "../../bin/bwish", bu_argv0_full_path returns "../../bin/bwish" |
| 16:50.49 | brlcad | wow |
| 16:51.36 | starseeker | had figured getprogname was just "bwish", and argv0 was the full string that invoked bwish, and if I wanted a canonical path it was up to me to use argv0's results |
| 16:52.10 | brlcad | not sure how that's even possible |
| 16:52.22 | brlcad | nah, that bu function is specifically to get an absolute path |
| 16:54.11 | starseeker | so then the realpath logic, if it really is needed, probably belongs there and not in bu_brlcad_root |
| 16:57.02 | brlcad | probably, or possibly both depending on which path is being tested (e.g., do we support relative paths in BRLCAD_ROOT) |
| 16:57.42 | starseeker | what the... |
| 16:57.58 | brlcad | inclination is probably not support them |
| 16:58.02 | starseeker | in gdb, it DOES look like it's returning full path |
| 16:58.18 | starseeker | what the *BLEEP* was bu_log printing? |
| 17:01.38 | starseeker | O.O |
| 17:02.02 | starseeker | the result changes depending on whether I'm launching bwish from within gdb |
| 17:02.30 | starseeker | looks for a handy wall to bash his head into... |
| 17:06.03 | starseeker | oh, looks like gdb is expanding out the path before running it |
| 17:06.05 | starseeker | cute |
| 17:15.20 | starseeker | brlcad: as near as I can trace this back, the sequence is: |
| 17:15.51 | starseeker | bwish/tcl.c - bu_setprogname takes argv[0] and assignes it to bu_progname |
| 17:16.11 | starseeker | argv[0] at that time is ../../bin/bwish |
| 17:17.51 | starseeker | bu_argv0_full_path calls three functions: _bu_argv0, _bu_ipwd and bu_which |
| 17:18.29 | starseeker | they return, respectively, ../../bin/bwish . ../../bin/bwish |
| 17:21.07 | starseeker | because the which result from bu_which is non-null and _bu_argv0's result does not appear to be a full path, the which result is the returned value |
| 17:21.19 | starseeker | there is no check on whether which is a full path |
| 17:27.12 | starseeker | looking over bu_which, it doesn't seem to be designed to return a full path... |
| 17:29.02 | starseeker | yeah, once that relative argv[0] was put into bu_progname, I don't see any logic that would make it a full path... |
| 17:33.03 | starseeker | if the which thing hasn't stopped the logic, it would have tried to use ipwd |
| 17:33.19 | starseeker | but ipwd was "." |
| 17:34.22 | starseeker | so I don't think that would have worked even if which hadn't short circuited the processs |
| 17:40.51 | *** join/#brlcad Elrohir (~kvirc@p5B14A3BB.dip.t-dialin.net) | |
| 18:09.33 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 18:47.41 | brlcad | looks like ipwd is wrong |
| 18:50.01 | brlcad | "." as an initial (full) path to the current working directory sounds like a fall-back path |
| 18:51.30 | brlcad | yeah, looks like getenv() was probalby empty and HAVE_POPEN was not defined |
| 18:52.04 | brlcad | realpath would probably be good there |
| 18:53.17 | brlcad | realpath(getenv("PWD")) or even realpath(".") |
| 19:31.01 | *** part/#brlcad crazy_imp (~mj@a89-182-3-165.net-htp.de) | |
| 20:09.23 | *** join/#brlcad Ralith (~ralith@d142-058-094-139.wireless.sfu.ca) | |
| 20:14.37 | Ralith | brlcad: do you know anything about how jonored's gcode generator was going to work, or where I could read up on that? Since he appears to have disappeared for good, I may try to pick up where he left off. |
| 20:16.04 | Ralith | hm, probably should have asked that when I wasn't about to disconnect. |
| 20:25.57 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 20:30.05 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 20:56.15 | *** join/#brlcad mafm (~mafm@171.Red-83-37-177.dynamicIP.rima-tde.net) | |
| 21:13.20 | CIA-29 | BRL-CAD: 03brlcad * r42405 10/brlcad/trunk/TODO: preliminary stab at current/next release plans: temp rt/rtedge/rtwizard colors, upgrade repo, and more |
| 21:21.16 | starseeker | brlcad: what about bu_which? that's the one that was actually responsible for the bwish path I saw, although it looked like none of the possible paths would actually have gotten us there... |
| 21:22.20 | starseeker | doesn't look like most of these functions could have returned a full path if a relative path was specified... |
| 22:08.38 | brlcad | starseeker: bu_which attempts to mimic the 'which' command-line too |
| 22:08.55 | brlcad | which has nothing to do with relative or absolute paths |
| 22:09.07 | brlcad | it attempts to find a path to the object specified |
| 22:09.39 | brlcad | e.g. if you run "mged" .. it does the search across the dirs in PATH to find it (which can be relative dirs) and returns the match |
| 22:51.17 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 22:51.22 | Ralith | okay, back for the day |
| 22:56.35 | starseeker | brlcad: then for the purposes of bu_argv0_full_path the which results should be wrapped in realpath too |
| 23:02.46 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 23:28.37 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 23:45.43 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 23:50.04 | Ralith | brlcad: you didn't answer while I was pinging out, did you? |
| 23:54.55 | starseeker | no, he didn't |
| 00:01.15 | Ralith | okay |
| 03:33.38 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 04:56.44 | *** join/#brlcad Stattrav (~Stattrav@122.172.16.143) | |
| 04:56.44 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:55.10 | brlcad | Ralith: was waiting since you were gone and not away -- he didn't write up any of his plans or work from anything written up |
| 07:55.38 | brlcad | if he made any progress, it wasn't made publicly available that I'm aware of |
| 07:56.10 | Ralith | brlcad: just got ahold of him after a month of trying, actually. Will be resuming his work. |
| 07:56.17 | Ralith | he sent me his full git repo |
| 07:56.58 | brlcad | excellent |
| 07:57.07 | brlcad | I have a copy of some python code he wrote |
| 07:57.20 | brlcad | don't know if it's the same as what was in his repo |
| 07:57.35 | Ralith | nope, this is C |
| 07:57.38 | brlcad | but at a glance, it was mainly a way to do in python some of the things you can do in mged |
| 07:57.45 | brlcad | k |
| 07:57.57 | Ralith | this is a partly complete slicer based on the raytracer |
| 07:58.06 | Ralith | not sure how partly; I suspect mostly. |
| 07:58.08 | brlcad | that's good |
| 07:58.20 | Ralith | outputs a sequence of line segments and circular arcs |
| 07:58.24 | brlcad | that's one of two respectable approaches, the easier of the two |
| 07:58.33 | Ralith | what's the other, out of curiosity? |
| 07:59.09 | brlcad | we'll, you're either using ray-tracing and sampling the space to determine an approximation for toolpaths |
| 07:59.57 | brlcad | or you're projecting a contour image to 2D (either sampled or in parametric form) and using that for toolpaths |
| 08:00.46 | Ralith | contour image being something along the lines of the sketch-from-plane-region-intersection thing I was asking about earlier? |
| 08:00.54 | Ralith | projected contour image* |
| 08:01.13 | brlcad | basically |
| 08:01.26 | brlcad | that'd be one way to attempt it |
| 08:01.54 | Ralith | that was what I was planning on doing had I not been able to recover this code. |
| 08:02.04 | brlcad | three or four come to mind but they all involve projecting an object onto a viewing plane, not a simple thing to do |
| 08:02.05 | Ralith | looks like that will be unnecessary, though |
| 08:02.28 | brlcad | the sampled approach is MUCH much easier and doable today |
| 08:02.35 | Ralith | nod |
| 08:02.37 | Ralith | good to know |
| 08:02.45 | brlcad | and only limited by the resolution you're willing to sample |
| 08:03.05 | Ralith | and I have a concrete upper limit to that: the precision of the target machine. |
| 08:03.19 | Ralith | typically worse than 0.1mm. |
| 08:03.32 | brlcad | you can probably even sample below some specified machining tolerance and it'd never matter |
| 08:03.37 | brlcad | yeah |
| 08:03.48 | Ralith | and a typical build volume of 20cm means quite reasonable sample counts, I believe. |
| 08:04.22 | brlcad | yeah, that'd just be a 2k x 2k sample grid |
| 08:04.34 | Ralith | trickier on ultraprecise CNC lathes and such, but my first priority is reprap support, which means relatively low-res additive. |
| 08:04.42 | brlcad | that'd take just a second or two to calculate them all |
| 08:04.47 | Ralith | sweet |
| 08:05.08 | Ralith | if the line/arc approximation math jonored's already finished isn't too heavy, this'll easily outstrip everything else people are using |
| 08:05.29 | Ralith | all of which are improvised STL processors |
| 08:05.54 | brlcad | crank that up to a 200cm piece or 20cm at a 0.01mm tolerance, and you jack up the grid to 20k x 20k |
| 08:06.11 | brlcad | which would be a couple minutes (10x order of mag. increase) |
| 08:06.55 | Ralith | jonored also mentioned that he was put off by some bug wherein the second derivative of toroids was mis-reported? |
| 08:06.59 | Ralith | know anything about that? |
| 08:07.14 | brlcad | nope |
| 08:07.41 | Ralith | okay, will see about hunting it down if/when I encounter it myself |
| 08:07.41 | brlcad | first I've heard of toroids having a problem |
| 08:08.03 | Ralith | it sounded like a minor one: |
| 08:08.16 | Ralith | 19:56:53 <jonored> Yep. Either puts them in the wrong slots, or gives a direction of the larger curvature at right angles to what it should, don't recall which. |
| 08:08.44 | brlcad | there is one thing that comes to mind, but it's not second-derivative related. it's failure to converge on a hit/miss if you perfectly graze a torus under certain math conditions |
| 08:08.52 | brlcad | but then it just counts it as a miss |
| 08:09.04 | Ralith | seems like a pretty minor issue, at least for my purposes |
| 08:09.16 | brlcad | ah, curvature is a different routine |
| 08:09.46 | Ralith | he referred to it as having the "curvature flipped" |
| 08:09.51 | brlcad | not used by much, so that would be a little less surprising -- but also trivial to investigate -- one tiny func |
| 08:09.58 | Ralith | okay then |
| 08:10.10 | Ralith | will mention it if I find anything |
| 08:10.28 | Ralith | hopefully with a patch in tow, though I'm still a bit worried about my ability to keep up with the math |
| 08:10.35 | brlcad | src/librt/primitives/tor/tor.c:831 |
| 08:10.39 | brlcad | rt_tor_curve() |
| 08:10.45 | Ralith | thanks :) |
| 08:10.52 | brlcad | if there's a curvature bug, that's where it'd be |
| 08:11.45 | brlcad | it'd be easy to get a sign wrong |
| 08:12.32 | Ralith | looks like this might well be pretty straightforward. |
| 08:14.29 | brlcad | "rt -l4 -s1024 file.g object" will render 'object' in 'file.g' to a window 1024x1024 with a curvature visualization lighting model, so you can see them in an image |
| 08:14.52 | Ralith | ooh, fun! |
| 08:17.49 | Ralith | hm, behaves oddly. |
| 08:17.54 | Ralith | perhaps I should install a stable version |
| 08:18.50 | Ralith | frame buffers are hanging around and not responding to close requests, and display sharply skewed output despite it appearing normal mid-render |
| 08:19.17 | brlcad | are you (or your window manager) resizing the window? |
| 08:19.24 | Ralith | window manager is. |
| 08:19.42 | brlcad | that'd be a problem |
| 08:19.58 | Ralith | tiling wm; tends to be more forceful about that than much code expects |
| 08:20.05 | Ralith | not a very well behaved tiling wm, though. |
| 08:20.20 | brlcad | fb windows aren't resizable unfortunately |
| 08:20.23 | Ralith | will switch to something more compliant and with float support in the near future |
| 08:20.28 | brlcad | sucks, but nobody has fixed |
| 08:20.31 | brlcad | try fbserv instead |
| 08:20.39 | brlcad | fbserv 0 /dev/X & |
| 08:20.49 | brlcad | rt -F0 -s1024 file.g object |
| 08:21.35 | Ralith | that works nicely! |
| 08:21.36 | Ralith | thanks :) |
| 08:22.47 | brlcad | manpage shows other options if the need arises |
| 08:22.50 | Ralith | nod |
| 09:43.04 | *** join/#brlcad mafm (~mafm@5.Red-83-45-73.dynamicIP.rima-tde.net) | |
| 10:38.21 | CIA-29 | BRL-CAD: 03tbrowder2 * r42406 10/brlcad/trunk/src/libged/attr.c: modify and rename attr sort comp function for extern use |
| 10:40.01 | CIA-29 | BRL-CAD: 03tbrowder2 * r42407 10/brlcad/trunk/src/libged/ged_private.h: add extern for attr comp function; add flags for extension of mged tree command args |
| 10:42.17 | CIA-29 | BRL-CAD: 03tbrowder2 * r42408 10/brlcad/trunk/src/libged/ls.c: cast to int to quell compiler warnings about signed/unsigned comparison |
| 10:44.21 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 11:13.47 | *** join/#brlcad mafm (~mafm@5.Red-83-45-73.dynamicIP.rima-tde.net) | |
| 11:14.02 | CIA-29 | BRL-CAD: 03tbrowder2 * r42409 10/brlcad/trunk/HACKING: list extensions for Perl code |
| 11:44.18 | DaveLo | Mernin all |
| 12:32.38 | CIA-29 | BRL-CAD: 03Dloman 07http://brlcad.org * r2422 10/wiki/GeometryServiceNetworkProtocol: |
| 13:07.39 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 13:37.10 | DaveLo | opens a new can of Photoshop-fu. Will need lots today. |
| 13:38.50 | CIA-29 | BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:GSNetProtocol.png]]" |
| 13:55.05 | CIA-29 | BRL-CAD: 03Dloman 07http://brlcad.org * r2424 10/wiki/GeometryServiceNetworkProtocol: Added in specifics about GSNet Header stufff. WIP still. |
| 13:57.11 | CIA-29 | BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:GSNetMsgBreakdown.png]]" |
| 13:59.45 | CIA-29 | BRL-CAD: 03Dloman 07http://brlcad.org * r2426 10/wiki/GeometryServiceNetworkProtocol: New image name, down size a bit. |
| 14:03.33 | starseeker | is probably going to end up volunteering to maintain a few Find*.cmake modules |
| 14:09.06 | DaveLo | that'll be fun! |
| 14:10.03 | starseeker | apparently back in 07 they switched to a system where people volunteer to maintain specific modules, on the (quite reasonable) theory that Kitware didn't have the resources to properly test them all |
| 14:10.59 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 14:11.04 | starseeker | submitted patches for Tcl, OpenGL and X11 anyway on the theory that Kitware probably wouldn't want to trust them to a 3rd party maintainer, give how core they were |
| 14:11.07 | starseeker | silly me |
| 14:11.17 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 14:11.20 | *** join/#brlcad 15SABD4WY (~CIA@208.69.182.149) | |
| 14:12.26 | starseeker | in one sense though it's not too big a deal, since I'll either be maintaining our local copy of those files as a "mini-fork" or doing it for CMake proper |
| 14:13.28 | *** join/#brlcad CIA-38 (~CIA@208.69.182.149) | |
| 14:13.32 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 14:13.48 | starseeker | X11 and OpenGL should be pretty mature anyway, but the FindTCL module is a radical departure |
| 14:14.42 | DaveLo | Hows the roads down there? |
| 14:15.45 | CIA-38 | BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:GSNet Symbol.png]]" |
| 14:15.53 | *** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net) | |
| 14:15.53 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 14:17.59 | *** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 14:18.33 | *** join/#brlcad epileg1 (~epileg@188.119.210.222) | |
| 14:20.36 | *** join/#brlcad mafm (~mafm@5.Red-83-45-73.dynamicIP.rima-tde.net) | |
| 14:21.53 | starseeker | grits his teeth and does a reboot into Windows for another test round... |
| 14:22.49 | CIA-38 | BRL-CAD: 03Dloman 07http://brlcad.org * r2428 10/wiki/GeometryServiceNetworkProtocol: Add in GSnet graphic and align. |
| 14:23.13 | DaveLo | starseeker: Hows the roads down there? made the trek in to work yet? |
| 14:24.11 | *** join/#brlcad Elrohir (~kvirc@p5B14977D.dip.t-dialin.net) | |
| 14:27.59 | starseeker | no, not yet - they plowed but there is a lot of slush in our area |
| 14:28.13 | starseeker | just got done scraping the driveway |
| 14:29.16 | CIA-38 | BRL-CAD: 03Dloman 07http://brlcad.org * r2429 10/wiki/GSNet_String: Stub in GSNet String page. |
| 14:31.33 | starseeker | will head in once he sees what happens on Windows... |
| 14:33.09 | starseeker | oooo - lot of updates to pull |
| 14:37.44 | *** join/#brlcad Elrohir (~kvirc@p5B14977D.dip.t-dialin.net) | |
| 14:59.43 | DaveLo | lotsa ice up here as well. |
| 15:00.00 | DaveLo | just called in to leave a telework notice. Heh, no one answered! =D |
| 15:06.09 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 15:10.43 | ``Erik_ | snow line said post was closed until 9 |
| 15:13.05 | CIA-38 | BRL-CAD: 03erikgreenwald * r42410 10/brlcad/trunk/src/librt/Makefile.am: move nmg_junk to EXTRA_DIST |
| 15:28.03 | CIA-38 | BRL-CAD: 03starseeker * r42411 10/brlcad/branches/cmake/src/CMakeLists.txt: Put the CMAKE_HEADERS variable in the src add_definitions (Windows seems to like this better, needs more testing.) |
| 15:36.01 | DaveLo | ``Erik: righto, but I called at 10 and still no answer :) |
| 15:39.33 | CIA-38 | BRL-CAD: 03erikgreenwald * r42412 10/brlcad/trunk/src/libged/ged.c: type fix |
| 15:44.38 | *** join/#brlcad Stattrav (~Stattrav@117.202.19.46) | |
| 15:44.38 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:22.12 | CIA-38 | BRL-CAD: 03starseeker * r42413 10/brlcad/branches/cmake/CMakeLists.txt: |
| 16:22.12 | CIA-38 | BRL-CAD: Successfully generate an NSIS installer, although it doesn't work yet due to |
| 16:22.12 | CIA-38 | BRL-CAD: src/other libraries being installed to the wrong dir - need to correct the CMake |
| 16:22.12 | CIA-38 | BRL-CAD: files in question or add additional logic in src/other/CMakeLists.txt, whichever |
| 16:22.12 | CIA-38 | BRL-CAD: makes sense. |
| 18:03.41 | DaveLo | whoooo doggy. There's some serious ice out there! Im still chipping away at getting clear. |
| 18:03.49 | CIA-38 | BRL-CAD: 03starseeker * r42414 10/brlcad/branches/cmake/ (11 files in 11 dirs): Make the CMake library target logic a bit more generic. A lot of these files should probably be worked into being proper stand-alone CMakeLists.txt files. |
| 18:03.56 | DaveLo | looks like two layers of ice then snow. Blech |
| 18:04.12 | starseeker | nods - I'll be heading in soon, but yeah - figured the more melted the better |
| 18:04.21 | starseeker | at least it's above freezing, or moving would be out of the question |
| 18:04.37 | DaveLo | Temps up here are cycling above then below here. |
| 18:04.45 | starseeker | ah, we're a few degrees above |
| 18:04.59 | DaveLo | half the stuff that melted and ran off the jeep refroze on the ground :/ |
| 18:05.18 | DaveLo | We're getting more this evening, right? i havent checked the forecast in a bit. |
| 18:05.27 | starseeker | still had to shovel - if it had re-frozen tonight, would have had 3/4 inch or better of ice all over the driveway |
| 18:05.42 | starseeker | dunno - haven't seen any indications of more, but perhaps that's changed |
| 18:06.09 | starseeker | makes one file stab at Windows before heading in |
| 18:07.02 | DaveLo | checks forecast |
| 18:07.56 | DaveLo | heh, yeah. Starting around 10pm, more ice and snow... at least up here. |
| 18:08.40 | DaveLo | looks like mostly rain down your way, with temps never dipping below freezing. |
| 18:08.53 | DaveLo | have a nice day at work! muwahahaha =P |
| 18:09.35 | CIA-38 | BRL-CAD: 03Dloman 07http://brlcad.org * r2430 10/wiki/GeometryServiceNetworkProtocol: Change links to start eliminating the iBME references. |
| 18:10.01 | CIA-38 | BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[IBME NETWORKPROTO STRING]]": iBME references are antiquated and being updated. |
| 18:20.41 | *** part/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 18:20.53 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 18:49.54 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 19:24.53 | CIA-38 | BRL-CAD: 03Dloman 07http://brlcad.org * r2431 10/wiki/GeometryServiceNetworkProtocol: Spacing |
| 19:30.10 | CIA-38 | BRL-CAD: 03Dloman 07http://brlcad.org * r2432 10/wiki/GeometryServiceNetworkProtocol: Specifics about the libPKG header implementation |
| 19:48.20 | brlcad | starseeker: note that the current nsis installer is "wrong" in several aspects as to where files are placed |
| 19:49.22 | brlcad | you don't need to accommodate the existing mistakes -- keep the install tree like it is supposed to be so it's the same on all platforms |
| 19:49.25 | brlcad | the nsis installer can be fixed to accomodate |
| 19:52.00 | CIA-38 | BRL-CAD: 03Dloman 07http://brlcad.org * r2433 10/wiki/GeometryServiceNetworkProtocol: Use CSS to make the table purty. |
| 19:55.41 | CIA-38 | BRL-CAD: 03brlcad * r42415 10/brlcad/trunk/src/libged/ (attr.c ged.c ged_private.h): |
| 19:55.41 | CIA-38 | BRL-CAD: private functions used across commands should be in the _ged_ namespace, |
| 19:55.41 | CIA-38 | BRL-CAD: otherwise, they don't need to be declared in ged_private.h and can remain HIDDEN |
| 19:55.41 | CIA-38 | BRL-CAD: _cmd_ prefixed. rename _attr_cmpstringp() to _ged_cmpattr() to reflect that it |
| 19:55.41 | CIA-38 | BRL-CAD: specifically compares bu_attribute_value_pair objects. |
| 20:12.27 | CIA-38 | BRL-CAD: 03brlcad * r42416 10/brlcad/trunk/src/libged/ (attr.c ged.c ged_private.h): ws consistency update, elim forward decls |
| 20:15.04 | starseeker | nods |
| 20:15.30 | starseeker | trying to figure out why mged isn't finding anything on Windows... |
| 20:15.47 | starseeker | needs to generalize the pkgIndex.tcl files a bit, doing that first |
| 20:19.42 | CIA-38 | BRL-CAD: 03brlcad * r42417 10/brlcad/trunk/src/libged/ (ged_private.h ls.c): convert up to size_t instead of down to int. |
| 20:56.07 | CIA-38 | BRL-CAD: 03brlcad * r42418 10/brlcad/trunk/src/librt/parse.c: quell warnings, size_t upconversions |
| 20:58.54 | CIA-38 | BRL-CAD: 03brlcad * r42419 10/brlcad/trunk/src/librt/Makefile.am: |
| 20:58.55 | CIA-38 | BRL-CAD: compile parse.c and nmg_junk.c so we make sure that they keep compiling as the |
| 20:58.55 | CIA-38 | BRL-CAD: library evolves. they don't need to be installed, but they should still be |
| 20:58.55 | CIA-38 | BRL-CAD: maintained until they're integrated or removed. (alas, they both have useful |
| 20:58.55 | CIA-38 | BRL-CAD: routines that should be integrated) |
| 20:59.38 | brlcad | starseeker: be wary of #ifdef _WIN32 and if {$platform == "windows"} statements in C/Tcl code that Bob added to override search paths |
| 21:00.33 | brlcad | some of them are sprinkled in unsuspecting places, have to trace the logic when something fails to load that should be loading to make sure it's not a hack job screwing things up |
| 21:00.54 | starseeker | nods - will do |
| 21:22.42 | CIA-38 | BRL-CAD: 03starseeker * r42420 10/brlcad/branches/cmake/src/other/ (6 files in 6 dirs): Fix/generalize pkgIndex.tcl logic, make incrTcl libs follow convention. |
| 21:40.08 | CIA-38 | BRL-CAD: 03brlcad * r42421 10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: |
| 21:40.09 | CIA-38 | BRL-CAD: not entirely clear what the compiler is complaining about here with the two |
| 21:40.09 | CIA-38 | BRL-CAD: (const point_t *) parameters to rt_metaball_find_intersection(). the problem |
| 21:40.09 | CIA-38 | BRL-CAD: has something to do with point_t being an array typedef. instead of getting the |
| 21:40.09 | CIA-38 | BRL-CAD: address during the call, get the point_t address beforehand with an explicit |
| 21:40.09 | CIA-38 | BRL-CAD: cast to keep things quiet. (gcc 4.2.1) |
| 21:49.15 | ``Erik | hm, I disabled nmg_junk.c last week due to 'defined but not used' warnings stopping the compile |
| 22:08.28 | brlcad | everything in librt_xxx.la is not used, so maybe it'll be quiet -- seems to work here with 4.2.1 |
| 22:08.46 | brlcad | otherwise, I can add some extern decls |
| 22:08.54 | brlcad | that'll definitely make it shut up |
| 22:15.54 | CIA-38 | BRL-CAD: 03starseeker * r42422 10/brlcad/branches/cmake/src/libbu/brlcad_path.c: |
| 22:15.54 | CIA-38 | BRL-CAD: Interesting... when launching bwish from the root install dir (e.g. ./bin/bwish) |
| 22:15.54 | CIA-38 | BRL-CAD: the return of bu_brlcad_data was not a full path (or even strictly speaking a |
| 22:15.54 | CIA-38 | BRL-CAD: relative path unless you add an implicit '.') and archer didn't start. This is |
| 22:15.54 | CIA-38 | BRL-CAD: a bit of a corner case, but still should work - try to make it more robust. |
| 22:29.09 | CIA-38 | BRL-CAD: 03starseeker * r42423 10/brlcad/branches/cmake/src/archer/plugins/Utility/botUtilityP.tcl: shouldn't need brlcadDataPath variable here. |
| 22:38.48 | CIA-38 | BRL-CAD: 03starseeker * r42424 10/brlcad/branches/cmake/src/libbu/brlcad_path.c: Whoops, try to do snprintf right |
| 22:47.42 | starseeker | mutter... bwish starts, but it's auto_path is rather underpopulated |
| 22:50.13 | starseeker | and bu_brlcad_data doesn't know what's up on Windows (at least from build-dir, which I suppose isn't too surprising) |
| 23:06.08 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 23:46.11 | brlcad | starseeker: that could be related to path separator, or trying to mix one style of separator with another |
| 00:09.53 | ``Erik | votes for '>' :D (vms) |
| 00:11.25 | CIA-38 | BRL-CAD: 03brlcad * r42425 10/brlcad/trunk/BUGS: rt crashes when it shouldn't |
| 00:41.22 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 00:44.36 | ``Erik | http://brlcad.org/~erik/codenorris.jpg |
| 00:52.49 | CIA-38 | BRL-CAD: 03starseeker * r42426 10/brlcad/branches/cmake/src/libbu/dirname.c: Don't hardcode '/' into bu_dirname, it's wrong on Windows |
| 00:53.52 | *** join/#brlcad merzo (~merzo@94-43-108-20.dsl.utg.ge) | |
| 01:20.56 | CIA-38 | BRL-CAD: 03brlcad * r42427 10/brlcad/trunk/ (4 files in 4 dirs): |
| 01:20.56 | CIA-38 | BRL-CAD: enable a test for -std=c99 since we cannot compile glx/gl.h-using code on Mac OS |
| 01:20.56 | CIA-38 | BRL-CAD: X 10.6 with -pedantic due to // comments in the gl.h header. use the flag in |
| 01:20.56 | CIA-38 | BRL-CAD: the dirs where we interface with glx (src/mged src/libdm src/libfb) |
| 01:29.14 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 01:37.47 | CIA-38 | BRL-CAD: 03starseeker * r42428 10/brlcad/branches/cmake/src/ (libbu/brlcad_path.c mged/mged.c mged/setup.c): Use GetFullPathName on Windows, and remove a couple of the Win32 specific bits in mged - this results in mged launching successfully. Still a lot more to do, including figuring out why archer silently crashes. |
| 01:48.41 | starseeker | hmm - I wonder if the itcl/itk upgrade did something, or if it's just how I'm building them with CMake |
| 02:01.23 | brlcad | <windows.h> .. system header |
| 02:52.34 | starseeker | in common.h then? |
| 03:17.28 | starseeker | huh - maxima is in the top 25 projects on sourceforge |
| 03:31.13 | Ralith | didn't know it was that active |
| 03:31.14 | Ralith | neat |
| 03:38.47 | starseeker | huh - another cad project based on opencascade: http://sourceforge.net/projects/narocad/ |
| 03:41.44 | starseeker | woot - someone is porting qcad to qt4 |
| 03:51.51 | starseeker | http://sourceforge.net/projects/librecad/ |
| 03:51.56 | starseeker | even builds |
| 05:10.26 | CIA-38 | BRL-CAD: 03brlcad * r42429 10/brlcad/trunk/include/raytrace.h: remove duplicate rt_dirbuild declaration |
| 06:01.42 | Ralith | opencascade gets all the attention ._. |
| 07:48.02 | CIA-38 | BRL-CAD: 03brlcad * r42430 10/brlcad/trunk/ (include/raytrace.h src/librt/db5_scan.c src/librt/db_open.c): rename db_get_version() to simply db_version(). there's no need for the getter name convention (inconsistent with api), especially when there's no putter. |
| 07:59.23 | CIA-38 | BRL-CAD: 03brlcad * r42431 10/brlcad/trunk/src/libged/ (draw.c erase.c): upcast argc iteration comparisons to size_t |
| 08:07.45 | CIA-38 | BRL-CAD: 03brlcad * r42432 10/brlcad/trunk/doc/deprecation.txt: renamed db_get_version() to db_version() as a minimally impacting change. |
| 08:10.55 | CIA-38 | BRL-CAD: 03brlcad * r42433 10/brlcad/trunk/ (6 files in 4 dirs): rename db_get_directory_size() to just db_directory_size() for similar motivations. there is no corresponding put routine, so simplify. |
| 08:27.59 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 08:27.59 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 08:27.59 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 08:27.59 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 08:27.59 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 08:28.01 | CIA-38 | BRL-CAD: 03brlcad * r42434 10/brlcad/trunk/ (doc/deprecation.txt include/raytrace.h src/librt/db_lookup.c): db_get_directory() renamed to db_alloc_directory() to be a little more consistent with other (non-macro) routines that don't do much except allocate memory. |
| 08:29.27 | CIA-38 | BRL-CAD: 03brlcad * r42435 10/brlcad/trunk/src/librt/ (db_alloc.c db_lookup.c): move the allocation routine into db_alloc.c |
| 08:32.51 | CIA-38 | BRL-CAD: 03brlcad * r42436 10/brlcad/trunk/ (doc/deprecation.txt include/raytrace.h src/librt/db_alloc.c): be more specific. match the resource struct member name, allocating more than one directory. |
| 08:35.03 | CIA-38 | BRL-CAD: 03brlcad * r42437 10/brlcad/trunk/include/raytrace.h: make it clear that these affect one global timer |
| 08:41.10 | CIA-38 | BRL-CAD: 03brlcad * r42438 10/brlcad/trunk/ (doc/deprecation.txt include/raytrace.h src/librt/storage.c): rename rt_get_set() similarly to rt_alloc_seg_block() since it doesn't actually get andthing or have an equivalent put/set. it's purpose is to allocate a block of segs so just say that. |
| 08:46.17 | CIA-38 | BRL-CAD: 03brlcad * r42439 10/brlcad/trunk/include/raytrace.h: declare db_alloc_directory_block() properly according to the rename. |
| 08:49.15 | CIA-38 | BRL-CAD: 03brlcad * r42440 10/brlcad/trunk/include/raytrace.h: move the related decls closer to each other for the two rt/db_alloc routines |
| 08:50.33 | CIA-38 | BRL-CAD: 03brlcad * r42441 10/brlcad/trunk/src/librt/ (db_alloc.c storage.c): move rt_alloc_seg_block from storage.c to db_alloc.c so db_alloc_directory_bloc() doesn't get lonely. |
| 08:51.55 | CIA-38 | BRL-CAD: 03brlcad * r42442 10/brlcad/trunk/ (4 files in 2 dirs): storage.c is no longer needed. |
| 08:57.36 | Ralith | I'd like to find a series of line segments along a given line, within the inside of a region, such that no point on any line segment is closer than a certain to the surface. Anyone have any thoughts on how this might be done? |
| 08:58.18 | Ralith | something like the intersection between a line and a verison of the object slightly shrunk along all surface normals, I think |
| 09:17.31 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 09:38.57 | CIA-38 | BRL-CAD: 03d_rossberg * r42443 10/brlcad/trunk/src/librt/CMakeLists.txt: |
| 09:38.58 | CIA-38 | BRL-CAD: synced with Makefile.am: removed nmg_junk.c from the actual build |
| 09:38.58 | CIA-38 | BRL-CAD: nmg_junk.c is a resting place for unfinished subroutines that are not a part of the current NMG library |
| 09:56.06 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 10:29.43 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 10:44.58 | *** join/#brlcad mafm (~mafm@62.Red-81-32-105.dynamicIP.rima-tde.net) | |
| 11:18.32 | *** join/#brlcad juanman (~quassel@201.255.21.86) | |
| 11:18.35 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:03.48 | DaveLo | Mernin all! |
| 13:06.33 | CIA-38 | BRL-CAD: 03ronaldbowers * r42444 10/jbrlcad/trunk/src/main/java/org/brlcad/geometryservice/: Making an interface |
| 13:08.03 | ``Erik | now what the heck is ron up to? I've been putting that in rt^3 |
| 13:09.32 | DaveLo | tee hee |
| 13:39.02 | brlcad | <PROTECTED> |
| 13:39.26 | *** join/#brlcad Stattrav (~Stattrav@117.202.19.79) | |
| 13:39.26 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:55.11 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 14:00.35 | CIA-38 | BRL-CAD: 03brlcad * r42445 10/brlcad/trunk/src/librt/db5_scan.c: if the database version has already been calculated, don't bother recalculating it. avoids rewind+fseek. |
| 14:03.22 | CIA-38 | BRL-CAD: 03brlcad * r42446 10/brlcad/trunk/src/librt/db_open.c: make sure db_version() calculates the version during db_open(), init to zero. |
| 14:08.51 | CIA-38 | BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Image:GSNetProtocol.png]]": Incorrectly named image. Should have been named GSNetMsgBreakdown |
| 14:29.48 | CIA-38 | BRL-CAD: 03davidloman * r42447 10/rt^3/trunk/docs/ (GS_Symbol.png GS_Symbol.psd): Add in rough draft of GS graphic. |
| 14:37.47 | CIA-38 | BRL-CAD: 03Dloman 07http://brlcad.org * r2434 10/wiki/Geometry_Service_Project_Main: Update definitions |
| 14:38.26 | CIA-38 | BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[IBME GeometryEngine]]": Dropping antiquated definition as well as eliminating an iBME reference. |
| 14:38.46 | CIA-38 | BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[IBME GeometryService]]": Dropping antiquated definition as well as eliminating an iBME reference. |
| 15:10.15 | *** join/#brlcad Elrohir (~kvirc@p5B14BCFC.dip.t-dialin.net) | |
| 15:11.21 | CIA-38 | BRL-CAD: 03brlcad * r42448 10/brlcad/trunk/include/raytrace.h: move the alloc functions down with the other alloc functions |
| 15:25.37 | starseeker | O.O http://www.40fires.org/Wiki.jsp?page=Hyrban%20CAD%20models |
| 15:26.54 | starseeker | http://www.40fires.org/Wiki.jsp?page=TermsOfUse |
| 15:27.09 | ``Erik | neat |
| 15:28.13 | starseeker | I thinke we just found a test case for our iges convertor :-P |
| 15:28.55 | starseeker | waits for his headache to subside so he can go in... |
| 15:30.22 | ``Erik | hm, from their blog, 9/10/09, "One day we'll have a wonderful, open source, free or nearly free, collaborative, version controlling 2D/3D CAD system (any suggestions?) and a wiki that you can all contribute to but it's still early days." |
| 15:32.55 | ``Erik | can't find what CAD system they're using, and don't know 'nuff to guess from the pictures |
| 15:33.19 | starseeker | CATIA, I think |
| 15:33.24 | starseeker | newest blog entry mentions it |
| 15:33.29 | ``Erik | that was my gut feeling heh |
| 15:33.46 | ``Erik | the blue gradient background in some p ics is catia style |
| 15:35.22 | ``Erik | hm, shuttleworth has talked to 'em |
| 15:45.00 | CIA-38 | BRL-CAD: 03brlcad * r42449 10/brlcad/trunk/src/ (52 files in 9 dirs): put db_version() to use, particularly for callers outside of librt since it's a private API member that isnt' supposed to be directly accessed. this sets the stage for using dbi_version in other ways. |
| 15:57.54 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:11.00 | CIA-38 | BRL-CAD: 03brlcad * r42450 10/brlcad/trunk/src/conv/dbupgrade.c: get the version number just once, then reference it |
| 16:19.18 | DaveLo | Hrm, might be a decent idea: http://www.cnn.com/2011/TECH/innovation/01/19/smart.roads/index.html?eref=mrss_igoogle_cnn |
| 16:19.53 | CIA-38 | BRL-CAD: 03ronaldbowers * r42451 10/jbrlcad/trunk/src/main/java/org/brlcad/geometryservice/GeometryServiceSPI.java: - Version 0.1 of the GeometryServiceSPI. Implementations should match the behavior defined here. |
| 16:32.24 | CIA-38 | BRL-CAD: 03brlcad * r42452 10/brlcad/trunk/src/librt/db5_scan.c: idiot |
| 16:32.45 | CIA-38 | BRL-CAD: 03brlcad * r42453 10/brlcad/trunk/src/librt/db5_io.c: can't call db_version because the dbip is const |
| 16:37.09 | CIA-38 | BRL-CAD: 03brlcad * r42454 10/brlcad/trunk/src/ (10 files in 5 dirs): improve consistency on how the version numbers are checked. avoiding <= and >= where unnecessary. |
| 17:26.43 | CIA-38 | BRL-CAD: 03brlcad * r42456 10/brlcad/trunk/src/mged/ (cmd.c mged.c): rename db_warn, db_upgrade, and db_version to have an mged_ prefix so they don't collide with librt db_*() functions (e.g., db_version()) |
| 18:02.35 | CIA-38 | BRL-CAD: 03bob1961 * r42458 10/brlcad/trunk/src/tclscripts/lib/RtControl.tcl: Added a configbody for the -color option. |
| 18:02.35 | CIA-38 | BRL-CAD: 03bob1961 * r42457 10/brlcad/trunk/src/tclscripts/lib/TkTable.tcl: Tweaked cadwidgets::TkTable::toggleSelect to behave better after a <Button-1> event occurs in a different cell. |
| 18:03.07 | CIA-38 | BRL-CAD: 03bob1961 * r42459 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Added a preference for the framebuffer's background color. |
| 18:31.12 | starseeker | DaveLo: problem with solar powered roads is 1) cost and 2) keeping 'em clean |
| 18:31.58 | DaveLo | Well if a state manages to get a leader in place that actually has LONG term planning skills, cost may be less of a problem. |
| 18:32.17 | DaveLo | as for cleaning, just wrap swiffer pads around tires :) |
| 18:32.24 | starseeker | heh |
| 18:33.14 | starseeker | might be more workable to have the sides of the road be solar panels |
| 18:33.41 | starseeker | no car oil and crap being dropped on them (or less, anyway) and they'll be exposed to the sun more |
| 18:33.45 | CIA-38 | BRL-CAD: 03brlcad * r42460 10/brlcad/trunk/ (NEWS m4/patch.m4): (log message trimmed) |
| 18:33.45 | CIA-38 | BRL-CAD: wow, now that I can finally reproduce and investigate ... FIX the |
| 18:33.45 | CIA-38 | BRL-CAD: several-year-old bug where compilation would fail on some Mac OS X systems |
| 18:33.45 | CIA-38 | BRL-CAD: (10.6+?) with a 'dyld: Library not loaded: |
| 18:33.45 | CIA-38 | BRL-CAD: /usr/brlcad/dev-7.18.1//lib/libwdb.19.dylib' message (and subsequent crash |
| 18:33.46 | CIA-38 | BRL-CAD: report). the problem is actually due to a bug in libtool where their temp_rpath |
| 18:33.47 | CIA-38 | BRL-CAD: variable was getting appended to another path variable but without a : between |
| 18:34.52 | starseeker | also would avoid the concerns mentioned about glass strength and traction |
| 18:34.58 | brlcad | it's only a matter of time, I can see it easily being cost effective for cities |
| 18:36.57 | brlcad | very 'spensive to have a fleet of trucks rolling through city streets scooping up snow and ice, took hundreds of trucks nearly a month to clear baltimore last year working 24/7 |
| 18:37.30 | starseeker | nods - cities could also heat the roads using solar panels on buildings and such (or even other sources of heat, once the heating element infrastructure itself was in place) |
| 18:38.34 | brlcad | that's easily a couple million in annual expenses just to cover salary, double/triple to cover equipment, maintenance, supplies, insurance |
| 18:39.38 | brlcad | city streets get repaved regularly (there are just so many), so they'd just need to be installable in sections as upgrades occur and be fault tolerant to big trucks, pot holes, etc |
| 18:41.10 | starseeker | brlcad: regarding windows.h - ``Erik was saying including it at the common.h level causes conflicts |
| 18:41.51 | ``Erik | may cause |
| 18:42.12 | ``Erik | many annoying things come from windows.h, like #define near and #define far for example |
| 18:42.26 | ``Erik | and #define DELETE more recently |
| 18:42.54 | ``Erik | isn't happy about the #ifdef WIN32 #undef symbol #endif pattern we have a few places :/ |
| 18:46.37 | starseeker | unless I'm missing something, wouldn't the only way forward be to include windows.h up front in config_win, and then undef everything that may cause us trouble later? |
| 18:49.04 | ``Erik | or rename our stuff |
| 19:06.06 | brlcad | now with that old bug fixed.. time for lunch! |
| 19:18.49 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 19:18.49 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 19:18.50 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 19:18.50 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 19:18.50 | *** join/#brlcad DaveLo (~claymore@BZ.BZFLAG.BZ) | |
| 19:18.50 | *** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ) | |
| 19:18.50 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 19:18.50 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 19:57.19 | DaveLo | heh, forgot about this one: http://www.youtube.com/watch?v=u-6ph7NWoBM |
| 21:04.13 | starseeker | brlcad: thath BU_STR_EQUAL thing seems to have broken search |
| 21:11.17 | Ralith | brlcad: that's good for entry/exit points, but doesn't account for points when a surface passes very close to but does not intersect the ray while it's inside the region |
| 21:30.55 | CIA-38 | BRL-CAD: 03starseeker * r42461 10/brlcad/trunk/src/other/tkpng/Makefile.am: I doubt we need the -module flag here - CMake build doesn't need it, so try it without |
| 21:31.35 | ``Erik | hah, now it fails with the expected issue |
| 21:31.41 | ``Erik | src/other/tkpng/Makefile.am:8: `tkpng.la' is not a standard libtool library name |
| 21:31.41 | ``Erik | src/other/tkpng/Makefile.am:8: did you mean `libtkpng.la'? |
| 21:32.49 | starseeker | bah |
| 21:32.52 | CIA-38 | BRL-CAD: 03erikgreenwald * r42462 10/brlcad/trunk/src/other/tkpng/Makefile.am: tkpng -> libtkpng |
| 21:34.48 | CIA-38 | BRL-CAD: 03erikgreenwald * r42463 10/brlcad/trunk/configure.ac: tkpng -> libtkpng |
| 21:36.08 | brlcad | starseeker: okay, I'll look into it (search) |
| 21:44.48 | starseeker | tried to include bu.h in search.c, but so far that doesn't seem to have done it... |
| 21:46.58 | brlcad | including a header won't usually change behavior ... just declarations and defines |
| 21:49.05 | brlcad | ah, that's what did it |
| 21:49.26 | brlcad | typecompare() is a callback, e.g. for qsort() |
| 21:49.56 | brlcad | needs to return >=< 0, not boolean |
| 22:04.49 | CIA-38 | BRL-CAD: 03brlcad * r42464 10/brlcad/trunk/src/libged/search.c: the typecompare() callback passed to bsearch() needs to return value <0, ==0, >0 depending on the comparison, not just a boolean. use bu_strcmp() instead of !BU_STR_EQUAL() |
| 22:07.50 | CIA-38 | BRL-CAD: 03erikgreenwald * r42465 10/brlcad/trunk/src/burst/prnt.c: #ifdef, not #if DEBUG |
| 22:32.57 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 22:32.57 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 22:32.58 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 22:32.58 | *** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ) | |
| 22:32.58 | *** join/#brlcad DaveLo (~claymore@BZ.BZFLAG.BZ) | |
| 22:38.18 | CIA-38 | BRL-CAD: 03brlcad * r42466 10/brlcad/trunk/src/libwdb/Makefile.am: libwdb seems to be compiling cleanly on mac and linux, so enable enforcement of strict build |
| 22:43.49 | *** join/#brlcad cosurgi (~cosurgi@atak.bl.pg.gda.pl) | |
| 22:51.40 | *** join/#brlcad mafm (~mafm@62.Red-81-32-105.dynamicIP.rima-tde.net) | |
| 22:56.57 | CIA-38 | BRL-CAD: 03brlcad * r42467 10/brlcad/trunk/src/libged/attr.c: er, so soon? use the new bu_strcmp() function so we properly handle null strings. |
| 23:03.26 | CIA-38 | BRL-CAD: 03brlcad * r42468 10/brlcad/trunk/configure.ac: er, STRICT_FLAGS should match the flags we actually tested for. |
| 23:25.09 | CIA-38 | BRL-CAD: 03brlcad * r42469 10/brlcad/trunk/src/libged/search.c: ws |
| 23:25.50 | CIA-38 | BRL-CAD: 03brlcad * r42470 10/brlcad/trunk/src/ (8 files in 4 dirs): |
| 23:25.50 | CIA-38 | BRL-CAD: more cases similiar to the search failure (affecting a bunch of commands |
| 23:25.50 | CIA-38 | BRL-CAD: including the likes of ls, the tedit commands, tops, and others) where we cannot |
| 23:25.50 | CIA-38 | BRL-CAD: use BU_STR_EQUAL since we actually need to use the real return value from |
| 23:25.50 | CIA-38 | BRL-CAD: bu_strcmp() instead of !BU_STR_EQUAL(). nice early catch. |
| 00:59.18 | CIA-38 | BRL-CAD: 03brlcad * r42471 10/brlcad/trunk/src/libgcv/Makefile.am: seems to build clean here, turn on strict |
| 01:00.22 | CIA-38 | BRL-CAD: 03brlcad * r42472 10/brlcad/trunk/src/libanalyze/Makefile.am: another dir that compiles clean, strictify |
| 01:09.19 | CIA-38 | BRL-CAD: 03brlcad * r42473 10/brlcad/trunk/ (3 files in 2 dirs): there doesn't seem to be any clear reason why load_dynamic_shader() takes the length of the shader name given it only prints the length for diagnostic purposes. remove the mlen parameter. |
| 01:41.12 | CIA-38 | BRL-CAD: 03brlcad * r42474 10/brlcad/trunk/src/liboptical/ (38 files): ws indent comment consistency update |
| 01:45.26 | CIA-38 | BRL-CAD: 03erikgreenwald * r42475 10/brlcad/trunk/src/libged/search.c: fix some... "creative" punctuation |
| 01:51.13 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 02:43.48 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 03:39.44 | CIA-38 | BRL-CAD: 03brlcad * r42476 10/brlcad/trunk/src/libged/ (Makefile.am dg_obj.c): save another curtree from clobberage by encapsulating the BU_SETJUMP/BU_UNSETJUMP logic into separate functions. |
| 03:39.45 | CIA-38 | BRL-CAD: 03brlcad * r42477 10/brlcad/trunk/src/libged/Makefile.am: not so fast |
| 03:45.35 | CIA-38 | BRL-CAD: 03brlcad * r42478 10/brlcad/trunk/src/libged/dg_obj.c: stash the return value so we clean up properly |
| 03:48.24 | CIA-38 | BRL-CAD: 03brlcad * r42479 10/brlcad/trunk/src/libged/draw.c: bom bom bom, and another one bites the dust. quell warning about curtree getting clobbered due to longjmp by breaking jumping out into separate frames. |
| 03:54.00 | CIA-38 | BRL-CAD: 03brlcad * r42480 10/brlcad/trunk/src/libged/facetize.c: sometimes the fix is simple. making three vars static made the compiler sufficiently happy. |
| 04:01.46 | CIA-38 | BRL-CAD: 03brlcad * r42481 10/brlcad/trunk/src/libged/human.c: |
| 04:01.46 | CIA-38 | BRL-CAD: heh, some seriously sketchy string initialization in here, but punt on cleaning |
| 04:01.46 | CIA-38 | BRL-CAD: it up. keep the compiler happy, though, by making the initialization explicit |
| 04:01.46 | CIA-38 | BRL-CAD: with a strlcpy. other %lf and 509 string limit quellage too. untested. |
| 04:04.36 | CIA-38 | BRL-CAD: 03brlcad * r42482 10/brlcad/trunk/src/libged/preview.c: eliminate non-c90 // comments |
| 04:05.20 | CIA-38 | BRL-CAD: 03brlcad * r42483 10/brlcad/trunk/src/libged/mirror.c: gcc is lazy. be explicit about setting up the argv array. |
| 04:05.48 | CIA-38 | BRL-CAD: 03brlcad * r42484 10/brlcad/trunk/src/libged/inside.c: make sure we init our vectors before using them. |
| 04:18.38 | CIA-38 | BRL-CAD: 03brlcad * r42485 10/brlcad/trunk/src/libged/select.c: more var init before use. |
| 04:24.32 | CIA-38 | BRL-CAD: 03brlcad * r42486 10/brlcad/trunk/src/libged/ (ps.c qray.c rect.c tire.c wdb_qray.c): more quelling compilation woes due to string lengths exceeding c90's 509 char limit, break em up. |
| 04:27.06 | CIA-38 | BRL-CAD: 03brlcad * r42487 10/brlcad/trunk/src/libged/wdb_obj.c: woo hoo, this makes for the last strict quellage in libged. another longjmp protection, fortunately made very simple since they're just flags that get initialized every time and can just be made static. |
| 04:27.17 | CIA-38 | BRL-CAD: 03brlcad * r42488 10/brlcad/trunk/src/libged/Makefile.am: turn on ... STRICT! |
| 04:28.20 | CIA-38 | BRL-CAD: 03brlcad * r42489 10/brlcad/trunk/src/libfb/fb_generic.c: need strings.h, not the older string.h for strcasecmp() |
| 04:39.10 | CIA-38 | BRL-CAD: 03brlcad * r42490 10/brlcad/trunk/src/liboptical/ (photonmap.c sh_plastic.c): remove two trailing unused parameters to IrradianceEstimate(), mark unused params, shine light onto the shadows. |
| 04:59.07 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:23.40 | CIA-38 | BRL-CAD: 03brlcad * r42491 10/brlcad/trunk/src/libfb/ (fb_generic.c fb_obj.c tcl.c): need string.h from some things, strings.h for others. likely needs revisiting for windows |
| 05:24.19 | brlcad | fg |
| 05:24.40 | CIA-38 | BRL-CAD: 03brlcad * r42492 10/brlcad/trunk/src/libfb/if_X24.c: ftruncate is not available during posix-compliant complication, so just settle for (untested) lseeking. |
| 05:30.15 | CIA-38 | BRL-CAD: 03brlcad * r42493 10/brlcad/trunk/src/libged/ (dg_obj.c draw.c): these are supposed to be static |
| 05:31.36 | CIA-38 | BRL-CAD: 03brlcad * r42494 10/brlcad/trunk/src/liboptical/Makefile.am: oops, didn't mean to enable strict here just yet |
| 05:37.47 | CIA-38 | BRL-CAD: 03brlcad * r42495 10/brlcad/trunk/include/photonmap.h: sync missing update for liboptical |
| 05:39.19 | *** join/#brlcad Stattrav (~Stattrav@122.172.31.168) | |
| 05:39.19 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:55.04 | CIA-38 | BRL-CAD: 03brlcad * r42496 10/brlcad/trunk/src/libdm/dm-plot.c: define __USE_POSIX2 so we get a declaration of popen() on Linux. |
| 08:10.34 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 08:44.05 | *** join/#brlcad mafm (~mafm@234.Red-81-43-146.staticIP.rima-tde.net) | |
| 08:56.45 | *** join/#brlcad Stattrav (~Stattrav@122.172.31.168) | |
| 08:56.46 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:06.17 | *** join/#brlcad mafm (~mafm@234.Red-81-43-146.staticIP.rima-tde.net) | |
| 09:31.07 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 09:47.45 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 11:17.29 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 11:21.04 | *** join/#brlcad Elrohir (~kvirc@p5B149C53.dip.t-dialin.net) | |
| 11:46.14 | *** join/#brlcad mafm (~mafm@239.Red-83-49-86.dynamicIP.rima-tde.net) | |
| 12:54.35 | CIA-38 | BRL-CAD: 03d_rossberg * r42497 10/brlcad/trunk/misc/win32-msvc/Dll/BrlcadCore.def: added db_version() for some conversion programs |
| 16:10.29 | CIA-38 | BRL-CAD: 03erikgreenwald * r42498 10/rt^3/trunk/ (6 files in 6 dirs): use FindTCL before FindBRLCAD |
| 16:18.49 | CIA-38 | BRL-CAD: 03starseeker * r42499 10/brlcad/branches/cmake/src/other/ (3 files in 3 dirs): Make a stab at better build logic for itcl/itk on Windows, although this does not yet get Archer running |
| 16:59.20 | *** join/#brlcad Stattrav (~Stattrav@117.202.22.82) | |
| 16:59.20 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:00.07 | CIA-38 | BRL-CAD: 03brlcad * r42500 10/brlcad/trunk/include/raytrace.h: clarify that db_version() only returns 4 or 5 presently, though callers shouldn't assume support for newer or older versions won't be added. |
| 17:01.33 | CIA-38 | BRL-CAD: 03brlcad * r42501 10/brlcad/trunk/src/liboptical/ (30 files): |
| 17:01.33 | CIA-38 | BRL-CAD: quell all verbose compilation warnings within liboptical, enable strict mode |
| 17:01.33 | CIA-38 | BRL-CAD: compilation. this adds missing initializer values, marks unused params, |
| 17:01.33 | CIA-38 | BRL-CAD: addresses exact floating point comparisons, and eliminates unused variables. |
| 17:04.30 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 17:04.57 | *** join/#brlcad cosurgi (~cosurgi@atak.bl.pg.gda.pl) | |
| 17:27.07 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.132.186) | |
| 17:58.25 | *** join/#brlcad PrezWhiteCalf (MK@whitecalf.net) | |
| 18:04.45 | *** join/#brlcad Stattrav (~Stattrav@117.192.128.94) | |
| 18:04.46 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:14.13 | CIA-38 | BRL-CAD: 03brlcad * r42502 10/brlcad/trunk/configure.ac: add another section to force 32-bit compilation flags if 64-bit build is specifically disabled. undoubtedly more needed, but this moves us forward. |
| 18:28.07 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 18:40.00 | CIA-38 | BRL-CAD: 03erikgreenwald * r42503 10/rt^3/trunk/tests/libpkgcpp/CMakeLists.txt: add TCL include path |
| 18:44.55 | *** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ) | |
| 18:45.13 | *** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ) | |
| 18:45.42 | *** join/#brlcad DaveLo (~claymore@BZ.BZFLAG.BZ) | |
| 19:06.29 | CIA-38 | BRL-CAD: 03erikgreenwald * r42504 10/brlcad/trunk/src/libfb/ (fb_generic.c fb_obj.c tcl.c): wrap #include <strings.h> in #ifdef HAVE_STRINGS_H, since msvc does not. |
| 19:23.39 | Ralith | O.o |
| 19:23.44 | Ralith | MSVC doesn't have strings.h? |
| 19:23.51 | Ralith | isn't that required by the standard? |
| 19:41.00 | brlcad | msvc is not c99 compliant (they only care about c++) |
| 19:41.16 | Ralith | :/ |
| 19:41.58 | CIA-38 | BRL-CAD: 03brlcad * r42505 10/brlcad/trunk/src/librt/CMakeLists.txt: ignore nmg_junk.c |
| 19:43.15 | CIA-38 | BRL-CAD: 03brlcad * r42506 10/brlcad/trunk/configure.ac: mac wants i386 for universal binaries |
| 20:05.26 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 20:21.27 | CIA-38 | BRL-CAD: 03starseeker * r42507 10/brlcad/branches/cmake/src/other/incrTcl/ (itcl/CMakeLists.txt itk/CMakeLists.txt): Try using STUBS, looking at the makefile.vc files... still not functioning |
| 20:37.44 | CIA-38 | BRL-CAD: 03starseeker * r42508 10/brlcad/branches/cmake/doc/html/CMakeLists.txt: Put the archer ico file where it is expected - this probably belongs in tclscripts with the other archer image files. |
| 21:43.24 | CIA-38 | BRL-CAD: 03starseeker * r42509 10/brlcad/branches/cmake/src/other/tk/CMakeLists.txt: Try using TK_VERSION here, not the two individual numbers |
| 21:56.54 | *** part/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 22:30.26 | *** join/#brlcad mafm_ (~mafm@239.Red-83-49-86.dynamicIP.rima-tde.net) | |
| 22:42.20 | starseeker | hmm - if I manually redefine itk::Toplevel, archer loads |
| 22:42.27 | starseeker | <PROTECTED> |
| 23:16.56 | CIA-38 | BRL-CAD: 03starseeker * r42510 10/brlcad/branches/cmake/src/tclscripts/archer/itk_redefines.tcl: |
| 23:16.56 | CIA-38 | BRL-CAD: This is NOT the solution to Archer not starting up on Windows - there is |
| 23:16.56 | CIA-38 | BRL-CAD: something fundamentally wrong with the Itk that bwish reports as loaded with a |
| 23:16.56 | CIA-38 | BRL-CAD: 'package require Itk'. This appears to work, so add it primarily to identify |
| 23:16.56 | CIA-38 | BRL-CAD: the nature of the issue. |
| 23:57.26 | CIA-38 | BRL-CAD: 03starseeker * r42511 10/brlcad/branches/cmake/src/tclscripts/archer/itk_redefines.tcl: |
| 23:57.26 | CIA-38 | BRL-CAD: It's the quantum bug, when you look at it it changes. A recompile now produces |
| 23:57.26 | CIA-38 | BRL-CAD: a whole new problem - Splash is not recognized as a command despite (apparently) |
| 23:57.26 | CIA-38 | BRL-CAD: it being in the path, and despite running successfully with the old compile. |
| 23:57.26 | CIA-38 | BRL-CAD: Commenting out the splash screen results in a series of Archer errors. Auuuugh. |
| 01:44.26 | *** join/#brlcad packrat (~sierpinsk@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 03:03.37 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 04:47.48 | CIA-38 | BRL-CAD: 03brlcad * r42512 10/brlcad/trunk/src/libbu/brlcad_path.c: realpath() may return an error, have to test for it. fall back to bu_strlcpy() if it does. |
| 04:49.51 | brlcad | sounds like you need to control for more variables in your build/runtime environment |
| 04:50.58 | brlcad | e.g., compiling on a machine with no previous version compiled or installed, running and installing fully and running from specified install dir so behavior is well-defined, etc |
| 04:51.31 | brlcad | if that's not repeatable after taking those measure, you're probably not accounting for something or simply doing something wrong |
| 05:36.48 | *** join/#brlcad Stattrav (~Stattrav@122.172.31.168) | |
| 05:36.48 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:03.56 | *** join/#brlcad Stattrav (~Stattrav@122.172.31.168) | |
| 06:03.56 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:08.27 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 08:36.34 | *** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) | |
| 10:11.41 | *** join/#brlcad mafm_ (~mafm@72.Red-83-49-86.dynamicIP.rima-tde.net) | |
| 10:51.43 | CIA-38 | BRL-CAD: 03LanderCardenasumf 07http://brlcad.org * r2435 10/wiki/User:LanderCardenasumf: New page: ===cool wiki site=== Love watching the [http://www.bbc.co.uk/ '''bbc'''] |
| 11:37.36 | *** join/#brlcad Elrohir (~kvirc@p5B14B475.dip.t-dialin.net) | |
| 12:26.33 | CIA-38 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User:LanderCardenasumf]]": content was: '===cool wiki site===Love watching the [http://www.bbc.co.uk/ '''bbc''']' (and the only contributor was '[[Special:Contributions/LanderCardenasumf|LanderCardenasumf]]') |
| 12:27.05 | CIA-38 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:LanderCardenasumf]] with an expiry time of infinite (account creation disabled): Spamming links to external sites |
| 12:46.01 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:21.51 | CIA-38 | BRL-CAD: 03starseeker * r42513 10/brlcad/branches/cmake/src/other/incrTcl/ (itcl/CMakeLists.txt itk/CMakeLists.txt): old Windows build didn't use the STUB flags but did have dllEntryPoint.c - try that. |
| 15:42.39 | CIA-38 | BRL-CAD: 03tbrowder2 * r42514 10/brlcad/trunk/src/libged/attr.c: ensure avpp is initialized in for loops (also tidy formatting) |
| 16:17.53 | CIA-38 | BRL-CAD: 03starseeker * r42515 10/brlcad/branches/cmake/src/ (2 files in 2 dirs): Well, not doing the stubs builds gets us back to the itk Toplevel not being defined right in some subtle way. Probably should test an installed version, as all this has been running from build dir only. |
| 16:28.08 | ``Erik | weee, slip&slide O.O |
| 16:40.35 | CIA-38 | BRL-CAD: 03starseeker * r42516 10/brlcad/branches/cmake/src/conv/ (6 files): Hmm, latest visual studio refuses to accept the extra . in its output name even with an explicit OUTPUT_NAME setting in CMake - it is a rather odd name so go with a dash |
| 16:41.48 | CIA-38 | BRL-CAD: 03starseeker * r42517 10/brlcad/branches/cmake/src/conv/ (g-shell-rect.1 g-shell-rect.c): rename command in files too. |
| 16:42.11 | ``Erik | weeeee, ice, snow, slicks, power, ... slip&slide! |
| 16:42.38 | ``Erik | oversteer once, a couple dozen understeers, a lot of idling in first to navigate, ... stupid weather, stupid gubmint |
| 16:44.28 | ``Erik | (ok, most of the understeers were on purpose... a little fun) |
| 16:44.53 | ``Erik | starseeker: when're you revamping the FindBRLCAD.cmake file? |
| 16:45.17 | starseeker | I had figured next week - you can hit it earlier if you like? |
| 16:46.07 | ``Erik | I added an explicite FindTCL.cmake to GS |
| 16:46.29 | ``Erik | um, GS nees the QT network stuff, not just the base QT stuff, that's the hostaddress issue I was seeing |
| 16:46.30 | starseeker | nods - probably a good idea |
| 16:46.46 | starseeker | we're using the Qt networking layer? |
| 16:46.56 | ``Erik | yes |
| 16:47.00 | starseeker | thought we were using libpkg... |
| 16:47.09 | ``Erik | QtHostAddress |
| 16:47.21 | starseeker | ah |
| 16:47.25 | ``Erik | I'd be more than happy to migrate that to straight libpkg and *nix structs |
| 16:47.39 | ``Erik | but that's what dave put in... I do tend to be the most brutal acid test for these things :D |
| 16:47.39 | starseeker | nods |
| 16:48.03 | starseeker | was probably the simplest way to get what he needed at the time - i'd say go for it |
| 16:48.37 | ``Erik | *shrug* I'm not going to concern myself until monday... have lots of other projects to busy me |
| 16:49.43 | ``Erik | the mac bundle issue, for example... the bzflag solution is inadequate, so'z I'll be nose deep in that kinda stuff, trying to figure out how to make it appealing to the sbcl guys |
| 16:50.44 | ``Erik | if I get teh sbcl distributable approach down in a clean way... I think that'll be big stuff, like, ... huge... muves3 in a week big |
| 16:57.34 | starseeker | sweet |
| 17:17.50 | ``Erik | gorram |
| 19:28.36 | *** join/#brlcad stevegt` (~stevegt@cislunar.TerraLuna.Org) | |
| 19:49.58 | *** join/#brlcad Stattrav (~Stattrav@117.192.133.29) | |
| 19:49.58 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:53.25 | CIA-38 | BRL-CAD: 03starseeker * r42518 10/brlcad/trunk/src/conv/ (5 files): change g-shell.rect to g-shell-rect in trunk too. |
| 20:09.46 | brlcad | starseeker: nice update/fix on g-shell.rect, but should probably at least document the change as a minimally impacting change (probably doesn't need news given how minor, but should be documented somewhere) |
| 20:36.08 | starseeker | hmm... doc/deprecation.txt maybe? |
| 20:37.36 | CIA-38 | BRL-CAD: 03starseeker * r42519 10/brlcad/trunk/doc/deprecation.txt: Make a note of g-shell.rect rename |
| 21:12.08 | *** join/#brlcad mafm (~mafm@72.Red-83-49-86.dynamicIP.rima-tde.net) | |
| 22:21.46 | CIA-38 | BRL-CAD: 03brlcad * r42520 10/brlcad/trunk/src/libbu/vls.c: (log message trimmed) |
| 22:21.46 | CIA-38 | BRL-CAD: fix a bug tom found where a '-' left-justify specifier was getting ignored if |
| 22:21.46 | CIA-38 | BRL-CAD: the value was positive. the code already supported negative lengths for |
| 22:21.46 | CIA-38 | BRL-CAD: left-justified printing, so the fix is really trivial to just record the flag |
| 22:21.46 | CIA-38 | BRL-CAD: and justify accordingly. interestingly enough, at least with the bsd libc on |
| 22:21.47 | CIA-38 | BRL-CAD: mac os x 10.6, -* with a negative length (i.e., a double-negative) also |
| 22:21.48 | CIA-38 | BRL-CAD: left-justifies, so we match that behavior here as well. technically not user |
| 22:32.15 | ``Erik | brlcad: ya testing on bz or crit, as well? |
| 22:32.34 | ``Erik | those'll probably be some of the more pedantic os's |
| 22:33.51 | CIA-38 | BRL-CAD: 03bob1961 * r42521 10/brlcad/trunk/src/tclscripts/lib/RtControl.tcl: Modified RtControl::raytrace to honor the subwindow if active (.i.e. use rt's -j option). |
| 22:34.57 | CIA-38 | BRL-CAD: 03bob1961 * r42522 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Updated Ged::init_button_no_op_prot to not disable rect draws. |
| 00:04.15 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 01:29.57 | CIA-38 | BRL-CAD: 03bob1961 * r42523 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Added a preference to Archer for setting the display font size. |
| 01:44.12 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 03:11.48 | CIA-38 | BRL-CAD: 03tbrowder2 * r42524 10/brlcad/trunk/src/libged/attr.c: initialize len at declaration |
| 03:23.36 | CIA-38 | BRL-CAD: 03tbrowder2 * r42525 10/brlcad/trunk/src/libged/attr.c: improve (and simplify) format of attr show after bu_vsl_printf bug fix |
| 05:59.30 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:09.44 | *** join/#brlcad Stattrav (~Stattrav@122.172.47.92) | |
| 07:09.44 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:05.10 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 10:01.21 | *** join/#brlcad mafm (~mafm@144.Red-88-23-77.staticIP.rima-tde.net) | |
| 10:33.22 | *** join/#brlcad mafm (~mafm@144.Red-88-23-77.staticIP.rima-tde.net) | |
| 11:43.13 | *** join/#brlcad mafm (~mafm@144.Red-88-23-77.staticIP.rima-tde.net) | |
| 12:50.06 | CIA-38 | BRL-CAD: 03tbrowder2 * r42526 10/brlcad/trunk/src/libged/ged.c: update preferred macro names; titdi code format |
| 12:58.58 | CIA-38 | BRL-CAD: 03tbrowder2 * r42527 10/brlcad/trunk/src/libged/ged.c: complete missing brace for putting for loop in a block; add comment |
| 14:20.06 | CIA-38 | BRL-CAD: 03Tbrowder 07http://brlcad.org * r2436 10/wiki/Contributor_Quickies: |
| 15:30.57 | *** join/#brlcad yagami_i (~yagami_i@FL1-119-244-163-89.okn.mesh.ad.jp) | |
| 16:07.05 | CIA-38 | BRL-CAD: 03tbrowder2 * r42528 10/brlcad/trunk/src/libged/tree.c: prepare tree to use a new '-a' option;\nchanging to a flags variable to allow multiple flag args |
| 16:07.42 | CIA-38 | BRL-CAD: 03tbrowder2 * r42529 10/brlcad/trunk/src/libged/ged.c: prepare tree to use a new '-a' option;\nchanging to a flags variable to allow multiple flag args |
| 16:18.51 | CIA-38 | BRL-CAD: 03tbrowder2 * r42530 10/brlcad/trunk/src/libged/ged.c: added '-a' option to mged tree command: lists attributes |
| 16:23.42 | CIA-38 | BRL-CAD: 03tbrowder2 * r42531 10/brlcad/trunk/NEWS: mged 'tree -a' option lists object attributes and is a user visible change |
| 16:35.35 | CIA-38 | BRL-CAD: 03tbrowder2 * r42532 10/brlcad/trunk/doc/docbook/system/mann/en/tree.xml: update docs for the mged tree command for the new '-a' option |
| 17:52.17 | *** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ) | |
| 18:32.11 | CIA-38 | BRL-CAD: 03johnranderson * r42533 10/brlcad/trunk/ (3 files in 3 dirs): dbconcat now has additional options to process the title, units, and color table from the incoming database. |
| 19:10.22 | *** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net) | |
| 19:10.22 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 19:16.19 | CIA-38 | BRL-CAD: 03brlcad * r42534 10/brlcad/trunk/src/libdm/dm-X.c: leave a note where mac apps often crash if you end up linking against the system Tcl/Tk frameworks. should convert to funcs instead of calling macros so the crash can be avoided. |
| 19:20.46 | CIA-38 | BRL-CAD: 03brlcad * r42535 10/brlcad/trunk/include/bu.h: |
| 19:20.46 | CIA-38 | BRL-CAD: fix a compilation warning where gcc 4.2+ warns about using void*'s in |
| 19:20.46 | CIA-38 | BRL-CAD: arithmetic. intel compiler did the same thing and the change made was to simply |
| 19:20.46 | CIA-38 | BRL-CAD: assume that the pointer address is the memory offset. not a great assumption, |
| 19:20.46 | CIA-38 | BRL-CAD: but go with that for now. |
| 19:37.32 | CIA-38 | BRL-CAD: 03brlcad * r42536 10/brlcad/trunk/ (187 files in 26 dirs): |
| 19:37.32 | CIA-38 | BRL-CAD: eat our own dogfood. all of the DIR_* macros were deprecated a couple years ago |
| 19:37.32 | CIA-38 | BRL-CAD: in r32755 and renamed to include an RT_ prefix. even though this is a minimally |
| 19:37.32 | CIA-38 | BRL-CAD: impacting change according to our present-day deprecation rules, continue with |
| 19:37.32 | CIA-38 | BRL-CAD: the deprecation since this will likely affect third-party code. update all of |
| 19:37.32 | CIA-38 | BRL-CAD: our uses to use RT_DIR_*. |
| 20:14.04 | CIA-38 | BRL-CAD: 03brlcad * r42537 10/brlcad/trunk/NEWS: |
| 20:14.04 | CIA-38 | BRL-CAD: john anderson added support to the mged dbconcat command for improting title, |
| 20:14.04 | CIA-38 | BRL-CAD: units, and color tables from the _GLOBAL attribute object via -t, -u, -c options |
| 20:14.04 | CIA-38 | BRL-CAD: respectively. this lets you import a .g database and bring those values in to |
| 20:14.04 | CIA-38 | BRL-CAD: the current database. |
| 21:06.41 | CIA-38 | BRL-CAD: 03brlcad * r42538 10/brlcad/trunk/src/liboptical/photonmap.c: clean up function sig decl, style consistency |
| 21:13.11 | CIA-38 | BRL-CAD: 03brlcad * r42539 10/brlcad/trunk/src/liboptical/photonmap.c: reorder to avoid forward decls |
| 23:03.36 | CIA-38 | BRL-CAD: 03starseeker * r42540 10/brlcad/branches/cmake/ (298 files in 48 dirs): Update cmake branch to trunk r42539 |
| 23:26.11 | CIA-38 | BRL-CAD: 03brlcad * r42541 10/brlcad/trunk/src/liboptical/ (photonmap.c wray.c): check the return values of fwrite() and fread() for failures. |
| 23:31.36 | CIA-38 | BRL-CAD: 03brlcad * r42542 10/brlcad/trunk/src/conv/step/ (4 files): initialize values that might otherwise get accessed unintentionally. |
| 23:33.51 | CIA-38 | BRL-CAD: 03brlcad * r42543 10/brlcad/trunk/src/libged/ (10 files): check a slew of return values for libc i/o functions that warrant checking including fscanf, scanf, system, dup, pipe, read, write, fread, and fwrite. |
| 23:45.19 | CIA-38 | BRL-CAD: 03brlcad * r42544 10/brlcad/trunk/src/conv/iges/g-iges.c: untested fix for the problem of curtree being potentially clobbered during bu exception handling. separate jump logic out into a separate function frame. |
| 23:52.47 | CIA-38 | BRL-CAD: 03brlcad * r42545 10/brlcad/trunk/src/conv/iges/g-iges.c: don't need to check curtree, db_free_tree accepts null trees. |
| 00:16.47 | *** join/#brlcad DX^ (~DX@c-71-59-50-121.hsd1.ga.comcast.net) | |
| 00:21.43 | CIA-38 | BRL-CAD: 03tbrowder2 * r42546 10/brlcad/trunk/ (5 files in 3 dirs): change it's to its for proper spelling of possessive form of 'it' |
| 00:42.39 | CIA-38 | BRL-CAD: 03brlcad * r42547 10/brlcad/trunk/include/vmath.h: |
| 00:42.39 | CIA-38 | BRL-CAD: add four new macros: VINITALL(), VINIT_ZERO, MAT_INIT_IDN, and MAT_INIT_ZERO. |
| 00:42.39 | CIA-38 | BRL-CAD: they create initialization statements suitable for declaration initialization so |
| 00:42.39 | CIA-38 | BRL-CAD: you don't have to declare variables and then initialize them on separate lines |
| 00:42.39 | CIA-38 | BRL-CAD: with corresponding VSETALL(), VSETALL(0.0), MAT_IDN(), and MAT_ZERO() calls. |
| 00:42.39 | CIA-38 | BRL-CAD: this idea was prompted by former Joe Doliner (via an otherwise unusable patch |
| 00:42.40 | CIA-38 | BRL-CAD: 2805742) for common vector/matrix initialization. |
| 00:57.47 | CIA-38 | BRL-CAD: 03brlcad * r42548 10/brlcad/trunk/src/libged/tables.c: put MAT_INIT_ZERO to work |
| 00:58.35 | CIA-38 | BRL-CAD: 03brlcad * r42549 10/brlcad/trunk/src/libbn/mat.c: a thing of beauty. reduction via MAT_INIT_IDN. |
| 01:41.54 | CIA-38 | BRL-CAD: 03brlcad * r42550 10/brlcad/trunk/src/mged/tedit.c: er, there's not much value in comparing a pointer with a string literal for equality. probably meant compare the strings themselves. |
| 03:00.17 | CIA-38 | BRL-CAD: 03tbrowder2 * r42551 10/brlcad/trunk/src/ (75 files in 41 dirs): change it's to proper spelling of its for possession |
| 04:25.25 | CIA-38 | BRL-CAD: 03brlcad * r42552 10/brlcad/trunk/BUGS: mouse bindings on 10.6 are wrong. no zoom in? |
| 04:26.52 | CIA-38 | BRL-CAD: 03brlcad * r42553 10/brlcad/trunk/src/libdm/dm-X.c: remove debug code |
| 05:24.40 | *** join/#brlcad yagami_i (~yagami_i@FL1-119-244-163-89.okn.mesh.ad.jp) | |
| 05:29.31 | CIA-38 | BRL-CAD: 03brlcad * r42554 10/brlcad/trunk/src/rt/view_bot_faces.c: initialize all structparse fields |
| 05:30.17 | CIA-38 | BRL-CAD: 03brlcad * r42555 10/brlcad/trunk/src/rt/ (hurt.c opt.c rtexample.c rtwalk.c sh_tcl.c): mark unused params, make get_args take a const char *[], eliminate some exact floating point comparisons. |
| 05:35.16 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 05:40.07 | CIA-38 | BRL-CAD: 03brlcad * r42556 10/brlcad/trunk/include/rtprivate.h: rtprivate has a reference to get_args() so update with constness change. |
| 05:40.17 | CIA-38 | BRL-CAD: 03brlcad * r42557 10/brlcad/trunk/src/ (21 files in 7 dirs): use the new vmath VINITALL(), VINIT_ZERO, MAT_INIT_IDN, MAT_INIT_ZERO macros pervasively for reduction refactor savings. reduced 160 initialization lines to less than 60. |
| 05:40.47 | CIA-38 | BRL-CAD: 03brlcad * r42558 10/brlcad/trunk/src/proc-db/ (brep_cube.cpp brep_simple.cpp): quell warnings -- mark unused params and check init args. |
| 05:46.48 | CIA-38 | BRL-CAD: 03brlcad * r42559 10/brlcad/trunk/src/ (10 files in 6 dirs): |
| 05:46.49 | CIA-38 | BRL-CAD: quell verbose compilation warnings by checking the return status for libc i/o |
| 05:46.49 | CIA-38 | BRL-CAD: functions like fread/fwrite/system. avoid clobbering variables due to bu |
| 05:46.49 | CIA-38 | BRL-CAD: exception handling by marking variables static and moving the critical section |
| 05:46.49 | CIA-38 | BRL-CAD: into its own function frame. make sure variables are initialized before use |
| 05:46.49 | CIA-38 | BRL-CAD: (even when the compiler is wrong). |
| 06:48.34 | CIA-38 | BRL-CAD: 03brlcad * r42560 10/brlcad/trunk/src/conv/ (17 files in 7 dirs): (log message trimmed) |
| 06:48.34 | CIA-38 | BRL-CAD: slew of the remainder verbose compilation warnings for src/conv. ridiculous |
| 06:48.34 | CIA-38 | BRL-CAD: repetition on the converters, yet frustratingly slightly inconsistent enough to |
| 06:48.34 | CIA-38 | BRL-CAD: require careful manual review and tweaking. added process_boolean() and |
| 06:48.34 | CIA-38 | BRL-CAD: sometimes process_triangulation() functions to all of the converters that |
| 06:48.34 | CIA-38 | BRL-CAD: perform libbu exception handling so that we can quell warnings about data be |
| 06:48.35 | CIA-38 | BRL-CAD: clobbered if an exception occurred. all of the process_boolean() functions are |
| 06:48.55 | CIA-38 | BRL-CAD: 03brlcad * r42561 10/brlcad/trunk/src/conv/Makefile.am: all clear now compiling on mac and linux. woo hoo. |
| 10:25.29 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 14:22.11 | brlcad | woo hoo! .. down to approximately 2000 warnings |
| 14:23.18 | brlcad | considerable considering we were at least high-five-digits to begin with |
| 17:59.02 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 20:38.16 | Ralith | high-five digits |
| 20:38.16 | Ralith | heh |
| 21:10.17 | *** part/#brlcad CIA-38 (~CIA@208.69.182.149) | |
| 21:31.06 | *** join/#brlcad CIA-4 (~CIA@208.69.182.149) | |
| 21:33.02 | CIA-4 | BRL-CAD: 03starseeker * r42562 10/brlcad/branches/cmake/ (12 files in 9 dirs): Get the NSIS installer from CMake closer to the old BRL-CAD installer |
| 21:35.40 | starseeker | Getting much closer: http://bzflag.bz/~starseeker/BRLCAD-7.18.1-win32.exe |
| 21:36.44 | starseeker | probably some details to tweak, and need docbook docs, but at least here it launches MGED and Archer |
| 21:37.24 | starseeker | heads back to Linux... |
| 21:39.37 | starseeker | ah, much better |
| 22:25.26 | *** join/#brlcad CIA-58 (~CIA@208.69.182.149) | |
| 23:22.23 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 23:26.43 | *** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net) | |
| 23:26.43 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 03:43.27 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 04:07.41 | brlcad | Ralith: even where we started from is still *way* better than most .. it was the extent at which warnings were enabled (basically almost everything gcc will report, far more than the default) ... plus the sheer size of the codebase |
| 04:15.20 | Ralith | nod |
| 05:24.55 | Ralith | BRL-CAD can be built without X, right? |
| 05:25.08 | Ralith | or its underlying components, anyway |
| 05:29.25 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:27.00 | brlcad | Ralith: yes, that's possible |
| 06:27.35 | brlcad | not a frequently tested configuration, so there may be a minor edit you'll have to make here or there to make sure the x11 components are disabled |
| 06:27.51 | brlcad | but it should be as simple as --without-x |
| 06:28.24 | brlcad | gets support for binary-incompatible v4 geometry database working |
| 06:29.04 | Ralith | great |
| 07:03.34 | CIA-58 | BRL-CAD: 03brlcad * r42564 10/brlcad/trunk/ (11 files in 11 dirs): (log message trimmed) |
| 07:03.35 | CIA-58 | BRL-CAD: implement initial support for reading in binary-incompatible v4 geometry |
| 07:03.35 | CIA-58 | BRL-CAD: database files without the need for performing a dbupgrade on matching hardware. |
| 07:03.36 | CIA-58 | BRL-CAD: user specifies a flip via a flag to opendb within mged that flips the version |
| 07:03.36 | CIA-58 | BRL-CAD: number (i.e., dbi_version changes from 4 to -4), marks the database read-only |
| 07:03.37 | CIA-58 | BRL-CAD: (mixed encodings would be disaster), and proceeds to flip the floating point |
| 07:03.37 | CIA-58 | BRL-CAD: falues during import. possibly only works for arbs, halfspaces, tgc, grips, |
| 07:52.14 | *** join/#brlcad yagami_i (~yagami_i@FL1-119-244-163-89.okn.mesh.ad.jp) | |
| 10:13.05 | *** join/#brlcad Stattrav (~Stattrav@122.172.17.180) | |
| 10:13.06 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:27.19 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 10:51.15 | *** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no) | |
| 11:22.33 | *** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ) | |
| 11:49.57 | CIA-58 | BRL-CAD: 03Dloman 07http://brlcad.org * r2437 10/wiki/GeometryServiceNetworkProtocol: Rename title for clarity |
| 11:51.17 | DaveLo | Mernin all. |
| 12:07.46 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 12:07.52 | CIA-58 | BRL-CAD: 03Dloman 07http://brlcad.org * r2438 10/wiki/GeometryServiceNetworkProtocol: Enter more of the libPKG header use description. |
| 12:41.48 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:09.29 | CIA-58 | BRL-CAD: 03d_rossberg * r42565 10/brlcad/trunk/src/libged/nirt.c: _WIN32 needs the ret variable too |
| 13:47.02 | starseeker | brlcad: awesome! |
| 14:17.38 | DaveLo | go go no dbupgrade! |
| 14:17.39 | CIA-58 | BRL-CAD: 03Dloman 07http://brlcad.org * r2439 10/wiki/GeometryServiceNetworkProtocol: Define libPKG header components |
| 15:14.19 | CIA-58 | BRL-CAD: 03Dloman 07http://brlcad.org * r2440 10/wiki/GeometryServiceNetworkProtocol: More details in libPKG header part. |
| 16:37.55 | CIA-58 | BRL-CAD: 03starseeker * r42566 10/brlcad/branches/cmake/src/other/incrTcl/itk/CMakeLists.txt: Er, that's not win32 specific. |
| 16:41.12 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 16:49.43 | *** join/#brlcad Nohla (~Nohla@64.76.19.227) | |
| 17:16.56 | CIA-58 | BRL-CAD: 03Dloman 07http://brlcad.org * r2441 10/wiki/GeometryServiceNetworkProtocol: Flesh out the GSNet portion of the Header info a bit. |
| 17:42.56 | CIA-58 | BRL-CAD: 03brlcad * r42567 10/brlcad/trunk/ (53 files in 6 dirs): |
| 17:42.56 | CIA-58 | BRL-CAD: copy-paste code hell. remove the proliferation of rtprivate.h inclusion from a |
| 17:42.57 | CIA-58 | BRL-CAD: slew of places where it actually isn't used; they just needed the optical.h |
| 17:42.57 | CIA-58 | BRL-CAD: header. for the rest that did use it, remove the half-assing k&r-style |
| 17:42.58 | CIA-58 | BRL-CAD: declarations in rtoptical. this cascades a slew of updates to rtuif code that |
| 17:42.58 | CIA-58 | BRL-CAD: didn't match the signature, and didn't match the caller. |
| 17:59.09 | CIA-58 | BRL-CAD: 03brlcad * r42568 10/brlcad/trunk/include/rtprivate.h: remove the doxygen comments since this isn't public header API. |
| 18:17.15 | CIA-58 | BRL-CAD: 03brlcad * r42569 10/brlcad/trunk/ (34 files in 4 dirs): move rtprivate out of include/ into src/rt/ and update references accordingly. looks like remrt and rttherm are the only two deep referencers. |
| 18:53.34 | CIA-58 | BRL-CAD: 03brlcad * r42570 10/brlcad/trunk/src/ (33 files in 3 dirs): rename rtprivate.h to rtuif.h to better match the intended purpose. expand the API documentation with the comments from http://brlcad.org/w/images/3/3d/Application_Development.pdf by Anderson and Butler. |
| 18:55.20 | CIA-58 | BRL-CAD: 03starseeker * r42571 10/brlcad/branches/cmake/src/other/incrTcl/itk/CMakeLists.txt: Add STATIC flag |
| 19:03.21 | brlcad | this is restaurant week in baltimore, lots of great dinner deals to be had... |
| 19:03.51 | brlcad | starseeker: made it to fogo yet? :-) |
| 19:04.17 | starseeker | not yet - hoping to go soon |
| 19:04.22 | brlcad | thinks he might have to make it there sometime this week |
| 19:04.32 | starseeker | had wedding this Friday to go to... |
| 19:04.33 | brlcad | their $50 dinner is $35 all week :) |
| 19:05.13 | brlcad | again?? didn't you just get married? <wry grin> |
| 19:07.21 | starseeker | heh - yeah, been going to a lot of weddings |
| 19:07.56 | starseeker | wife's family is local, and somewhat older than my side (where I'm the oldest) so it's kinda a perfect storm generationally speaking |
| 19:11.19 | CIA-58 | BRL-CAD: 03starseeker * r42572 10/brlcad/branches/cmake/ (misc/CMake/FindTCL.cmake src/other/CMakeLists.txt): Don't go through the whole search song and dance if we already have the TCL variables we need - should help when FindTCL is called multiple times too |
| 19:20.08 | CIA-58 | BRL-CAD: 03brlcad * r42573 10/brlcad/trunk/src/rt/ (do.c ext.h opt.c rtuif.h): move the non-rtuif functions and globals from rtuif.h into ext.h header. found inconsistent size_t decls on incr_level and incr_nlevel along the way. |
| 19:22.46 | CIA-58 | BRL-CAD: 03brlcad * r42574 10/brlcad/trunk/src/rt/do.c: remove unnecessary declarations |
| 19:24.45 | CIA-58 | BRL-CAD: 03brlcad * r42575 10/brlcad/trunk/src/rt/ (ext.h viewfrac.c viewrad.c viewscat.c): remove authorship per hacking |
| 19:28.49 | CIA-58 | BRL-CAD: 03brlcad * r42576 10/brlcad/trunk/src/rt/ext.h: ws cleanup |
| 19:35.23 | CIA-58 | BRL-CAD: 03brlcad * r42577 10/brlcad/trunk/src/rt/ (hurt.c main.c reshoot.c rtshot.c rtuif.h rtwalk.c): eliminate RT_BUFSIZE. it's not RT API and not necessary regardless since rt_dirbuild() is fed sizeof(idbuf). arbitrarily increase from 1024 to 2048 (v4 was 132). |
| 20:00.12 | epileg | hello |
| 20:00.25 | brlcad | howdy epileg ! |
| 20:00.42 | epileg | hi brlcad! |
| 20:01.50 | epileg | well, today i've done some compilation but without success till enabling everything |
| 20:01.57 | brlcad | :) |
| 20:02.13 | brlcad | it definitely gets a lot more tricky when you leave our management of dependencies |
| 20:03.00 | brlcad | do you describe the required dependencies when you disable their compilation? |
| 20:04.06 | epileg | how? |
| 20:04.49 | brlcad | I don't have a debian system available to tell you that :) |
| 20:04.59 | epileg | ok |
| 20:05.45 | epileg | just a question. how i can know the minimun version of shared libraries needed by brlcad |
| 20:05.47 | epileg | ? |
| 20:06.21 | brlcad | for what mafm worked on, dependencies are described in the "control" file, see misc/debian/control |
| 20:06.43 | brlcad | that has minimums listed too |
| 20:07.55 | CIA-58 | BRL-CAD: 03brlcad * r42578 10/brlcad/trunk/src/mged/ (Makefile.am chgview.c dir.c): remove a slew of dead code unveiled after searching for callers. |
| 20:08.36 | CIA-58 | BRL-CAD: 03brlcad * r42579 10/brlcad/trunk/src/mged/qray.c: entire file is no longer used, logic migrated to libged |
| 20:09.09 | epileg | brlcad: do you mean "control" file of misc/debian/? |
| 20:09.36 | brlcad | yes |
| 20:10.17 | epileg | well, here aren't all the needed libraries |
| 20:11.49 | epileg | a want to know, i.e. the minimun version of png dev library. in ubuntu the actual version is 1.2.44, but brlcad may need some newer one, isn't it? |
| 20:13.44 | brlcad | not really |
| 20:13.46 | CIA-58 | BRL-CAD: 03brlcad * r42580 10/brlcad/trunk/src/mged/fbserv_win32.c: more dead code elimination. looks like the fbserv_win32 interface was a big hack job. |
| 20:19.00 | brlcad | it's not clear what the actual minimum required is .. feature wise, probably anything 1.0+ will work; code wise, probably anything 1.2+ |
| 20:19.28 | epileg | aha |
| 20:21.37 | epileg | ok, is there a way to test every component (i.e. png) of an installed brlcad? |
| 20:44.21 | brlcad | "make benchmark" is the core competency test, "make test" will also work on some platforms |
| 20:44.50 | epileg | ok |
| 20:45.08 | brlcad | after install, testing becomes a manual process -- HACKING file describes the testing steps near the end |
| 20:47.22 | epileg | thank You brlcad |
| 21:27.11 | CIA-58 | BRL-CAD: 03brlcad * r42581 10/brlcad/trunk/src/mged/ (7 files): more dead code elimination. more than 800 lines poof. |
| 21:42.44 | CIA-58 | BRL-CAD: 03erikgreenwald * r42582 10/brlcad/trunk/src/libged/editit.c: avoid shadowing stat |
| 21:52.04 | CIA-58 | BRL-CAD: 03brlcad * r42583 10/brlcad/trunk/ (6 files in 4 dirs): db_shader_mat() renamed to rt_shader_mat() |
| 22:03.17 | CIA-58 | BRL-CAD: 03brlcad * r42584 10/brlcad/trunk/src/libbn/globals.c: replace all of the numeric literals with vmath references. |
| 22:15.23 | CIA-58 | BRL-CAD: 03starseeker * r42585 10/brlcad/branches/cmake/src/other/togl/: Remove old togl dir in preparation for attempt at CMake togl |
| 22:26.20 | CIA-58 | BRL-CAD: 03brlcad * r42586 10/brlcad/trunk/src/ (23 files in 16 dirs): use libbn math constants. use vmath's M_PI and related defines along with DEG2RAD & RAD2DEG conversions where appropriate. |
| 22:42.56 | *** join/#brlcad Ralith (~ralith@d142-058-093-041.wireless.sfu.ca) | |
| 23:20.37 | CIA-58 | BRL-CAD: 03starseeker * r42587 10/brlcad/branches/cmake/src/other/ (169 files in 17 dirs): |
| 23:20.38 | CIA-58 | BRL-CAD: Initial stab at togl + CMake, based off my github fork with some changes. In |
| 23:20.39 | CIA-58 | BRL-CAD: particular, scary change to glxext.h to work around a conflict with glx.h on the |
| 23:20.39 | CIA-58 | BRL-CAD: Mac - need to see what glfw does with that situation and make it less scary. |
| 23:20.40 | CIA-58 | BRL-CAD: Almost certainly this isn't portable yet. |
| 00:02.35 | CIA-58 | BRL-CAD: 03starseeker * r42588 10/brlcad/branches/cmake/src/other/togl/ (demo/CMakeLists.txt src/Xmu/LookupCmap.c src/Xmu/StdCmap.c): Tweaks for building on Linux |
| 00:33.53 | CIA-58 | BRL-CAD: 03starseeker * r42589 10/brlcad/branches/cmake/src/other/togl/src/CMakeLists.txt: Conditionalize the Xmu sources to X11 |
| 00:57.55 | *** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net) | |
| 00:57.55 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 02:30.04 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 03:03.42 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 03:24.54 | CIA-58 | BRL-CAD: 03brlcad * r42590 10/brlcad/trunk/src/conv/Makefile.am: |
| 03:24.55 | CIA-58 | BRL-CAD: this is likely the cause of the build failure that tom browder expressed on the |
| 03:24.55 | CIA-58 | BRL-CAD: mailing list where compilation in src/conv failed due to some c++ warning. |
| 03:24.56 | CIA-58 | BRL-CAD: while the majority of c++ code (step, intaval) compiles without -Werror, the |
| 03:24.56 | CIA-58 | BRL-CAD: 3dm-g converter sources were being compiled with the same AM_CPPFLAGS which now |
| 03:24.57 | CIA-58 | BRL-CAD: includes -Werror. to make 3dm-g not compile without the strict flags, they have |
| 03:24.57 | CIA-58 | BRL-CAD: to be distributed to all the other binaries accordingly. |
| 03:55.52 | CIA-58 | BRL-CAD: 03brlcad * r42591 10/brlcad/trunk/src/burst/Sc.c: curious new failure. termios.h may define VMIN which conflicts vmath, so undef it. |
| 05:01.14 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 05:22.09 | *** join/#brlcad Stattrav (~Stattrav@122.172.15.195) | |
| 05:22.09 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:58.31 | *** join/#brlcad Stattrav (~Stattrav@122.172.15.195) | |
| 05:58.36 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:18.32 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 09:11.27 | *** join/#brlcad Stattrav (~Stattrav@122.172.15.195) | |
| 09:11.27 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:17.15 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 09:17.15 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:20.49 | *** join/#brlcad jay_ (~jay@212.96.10.253) | |
| 09:22.17 | jay_ | anyone here? |
| 10:17.39 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:42.39 | jay_ | anyone here |
| 11:46.02 | DaveLo | mernin all! |
| 11:46.12 | DaveLo | howdy jay_ ! What's up? |
| 11:48.45 | jay_ | DaveLo: looking for a good tutorial on drawing a floor plan |
| 11:49.38 | jay_ | DaveLo: have you tried using qcad |
| 11:50.35 | DaveLo | Nope, can't say that I have. I'm primarily a BRL-CAD modeler, with some exp in Blender, 3DSmax and Maya. |
| 11:51.23 | jay_ | ok. thnx |
| 11:52.26 | alex_joni | jay_: floor plan as in for a house? |
| 11:53.03 | jay_ | alex_joni: yes |
| 11:53.41 | alex_joni | there are some programs specialized in that |
| 11:53.52 | alex_joni | I used 3D-Home a long time ago |
| 11:54.51 | jay_ | does it do 2d and is it as advanced as autocad |
| 11:55.35 | alex_joni | nope |
| 11:55.58 | jay_ | ok. thnx |
| 11:56.12 | alex_joni | but I think I remember some Autocad plugins for that |
| 11:56.44 | jay_ | ok. i'll check it out. |
| 14:57.42 | CIA-58 | BRL-CAD: 03erikgreenwald * r42592 10/brlcad/trunk/misc/win32-msvc8/ (g2shellrect/g2shellrect.vcproj mged/mged.vcproj): reflect renaming/dead code removal |
| 15:27.10 | *** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de) | |
| 15:52.37 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 15:53.13 | DaveLo | This is actually pretty darn good for a fan film: http://www.joystiq.com/2011/01/24/fallout-nuka-break-fan-film/ |
| 15:57.02 | ``Erik | is that what all the noise was earlier? |
| 15:57.19 | DaveLo | guns and stuff? |
| 15:57.35 | ``Erik | yeah, richard said it sounded like a video game and was wondering if it was my computer O.o :D |
| 15:58.08 | DaveLo | so...i need to pipe it thru the big speakers and run the video again... is that what you're saying? =D |
| 15:59.13 | ``Erik | was joking about cranking up my system and having a sub war, he didn't seem thrilled |
| 15:59.26 | ``Erik | and the dudes upstairs would come down and say "can you turn it down? we can't feel our feet anymore" |
| 16:00.04 | DaveLo | simple: Lock your door! |
| 16:20.47 | CIA-58 | BRL-CAD: 03brlcad * r42593 10/brlcad/trunk/TODO: can open binary-incompatible v4 |
| 16:36.44 | CIA-58 | BRL-CAD: 03Dloman 07http://brlcad.org * r2442 10/wiki/GeometryServiceNetworkProtocol: Flesh out Data a bit. |
| 16:43.35 | CIA-58 | BRL-CAD: 03brlcad * r42594 10/brlcad/trunk/src/libbu/brlcad_path.c: expand ipwd so that it uses realpath() if available. expand paths found with getenv() and attempt expanding '.' if that fails or is skipped. |
| 16:45.19 | CIA-58 | BRL-CAD: 03brlcad * r42595 10/brlcad/trunk/TODO: needs testing, but ipwd should be better now |
| 16:48.55 | CIA-58 | BRL-CAD: 03brlcad * r42596 10/brlcad/trunk/TODO: save g_ renaming until 7.20 |
| 16:53.23 | CIA-58 | BRL-CAD: 03brlcad * r42597 10/brlcad/trunk/src/conv/Makefile.am: everyone needs CFLAGS, and fastf4-g isn't quite what was intended |
| 18:23.56 | CIA-58 | BRL-CAD: 03starseeker * r42598 10/brlcad/branches/cmake/ (9 files in 9 dirs): Use the more specific and thorough test for termlib, instead of Curses. While we're at it, add (conditionally) togl to the build. |
| 19:00.08 | CIA-58 | BRL-CAD: 03erikgreenwald * r42599 10/rt^3/trunk/tests/utility/configTest.cxx: QString is in .../QtCore/ |
| 19:00.24 | CIA-58 | BRL-CAD: 03erikgreenwald * r42600 10/rt^3/trunk/tests/libNet/CMakeLists.txt: add tcl include path |
| 19:00.37 | CIA-58 | BRL-CAD: 03erikgreenwald * r42601 10/rt^3/trunk/CMakeLists.txt: search for QT Networking up front |
| 19:03.56 | CIA-58 | BRL-CAD: 03starseeker * r42602 10/brlcad/branches/cmake/misc/CMake/NSIS.template.in: Make a stab at conditionalizing the installation of the Desktop icons for NSIS installer |
| 19:05.29 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 19:29.47 | *** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de) | |
| 19:33.33 | *** join/#brlcad alex_jon1 (~alex_joni@81.196.65.201) | |
| 21:13.32 | CIA-58 | BRL-CAD: 03erikgreenwald * r42603 10/brlcad/trunk/src/conv/nmg/asc-nmg.c: change stat to status to avoid shadowing. indent. |
| 21:14.32 | CIA-58 | BRL-CAD: 03starseeker * r42604 10/brlcad/branches/cmake/misc/CMake/NSIS.template.in: Try pointing to the installed readme file |
| 21:30.54 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 21:31.57 | CIA-58 | BRL-CAD: 03Dloman 07http://brlcad.org * r2443 10/wiki/NetMsgTypes: |
| 21:36.25 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 21:43.57 | CIA-58 | BRL-CAD: 03Dloman 07http://brlcad.org * r2444 10/wiki/NetMsgTypes: First round of formatting/editing for NetMsg Types. Eventually, this will be a Doxy file. |
| 22:09.53 | CIA-58 | BRL-CAD: 03starseeker * r42605 10/brlcad/branches/cmake/misc/CMake/NSIS.template.in: |
| 22:09.54 | CIA-58 | BRL-CAD: Still doesn't work even after removing inappropriate SetOutPath command - |
| 22:09.55 | CIA-58 | BRL-CAD: apparently this has NEVER worked, even with the old installer, so don't worry |
| 22:09.55 | CIA-58 | BRL-CAD: about it. May require something like renaming the README file to have a .txt |
| 22:09.59 | CIA-58 | BRL-CAD: extension or some such on Windows, but not worth experimenting with - just |
| 22:09.59 | CIA-58 | BRL-CAD: remove. |
| 22:20.07 | CIA-58 | BRL-CAD: 03starseeker * r42606 10/brlcad/branches/cmake/src/other/tk/CMakeLists.txt: Don't keep appending more TK_CFLAGS on multiple runs - let's see if this is why tk keeps rebuilding every time |
| 23:00.01 | CIA-58 | BRL-CAD: 03starseeker * r42607 10/brlcad/branches/cmake/CMakeLists.txt: Cache either way, so it doesn't pop up in the gui (hopefully, untested) |
| 23:09.30 | CIA-58 | BRL-CAD: 03starseeker * r42608 10/brlcad/branches/cmake/ (CMakeLists.txt src/other/togl/src/CMakeLists.txt): Remove debug messages. |
| 23:11.01 | CIA-58 | BRL-CAD: 03Dloman 07http://brlcad.org * r2445 10/wiki/NetMsgTypes: Added TODO |
| 23:23.40 | CIA-58 | BRL-CAD: 03erikgreenwald * r42609 10/brlcad/branches/bottie/ (859 files in 134 dirs): MFC 42604 |
| 23:28.56 | starseeker | yay huge merges |
| 23:29.14 | starseeker | can't wait for the next rel8 sync |
| 23:52.45 | ``Erik | heh |
| 23:56.20 | starseeker | merges trunk into cmake and watches the crawl... |
| 00:16.47 | ``Erik | heh, yeah, uh, the bottie merge there took a few hours |
| 00:17.51 | ``Erik | I imagine I'll have to do a quick followup tomorrow along with the "number_of_triangles" hack and backing the ray up a micron, then see how bad I screw trunk up |
| 00:20.54 | starseeker | hrm |
| 00:21.31 | starseeker | possible issue... |
| 00:21.52 | starseeker | libbn/mat.c:54: error: MAT_INIT_IDN undeclared here (not in a function) |
| 00:26.15 | starseeker | tries a clean build |
| 00:29.37 | ``Erik | did any conflicts list? |
| 00:29.52 | starseeker | not in CMake (at least not that I saw) |
| 00:29.58 | ``Erik | during the merge |
| 00:30.10 | starseeker | yeah, didn't see any |
| 00:30.31 | ``Erik | funky, I always seem to get at least one |
| 00:31.00 | starseeker | I do get some on occasion, usually when I've done something in the cmake branch first and then in trunk |
| 00:31.11 | starseeker | yeah, libbn builds now |
| 00:31.34 | starseeker | oh, bet it was using the old copy in the build directory's include dir |
| 00:31.40 | starseeker | dur |
| 00:32.47 | CIA-58 | BRL-CAD: 03starseeker * r42610 10/brlcad/branches/cmake/ (249 files in 76 dirs): Update cmake branch to trunk r42609 |
| 00:34.12 | CIA-58 | BRL-CAD: 03starseeker * r42611 10/brlcad/branches/cmake/ (include/CMakeLists.txt src/mged/CMakeLists.txt): Remove files no longer present from CMakeLists.txt files |
| 00:43.00 | starseeker | brlcad: is that new rtuif.h header supposed to be installed? |
| 00:43.39 | ``Erik | it's the new rt_private.h, I don't think it is |
| 00:43.53 | starseeker | k |
| 00:44.08 | starseeker | ah, right |
| 00:44.14 | starseeker | in src/rt, not include |
| 00:45.53 | brlcad | it's a private header, fixed a problem |
| 00:46.18 | starseeker | nods - yeah, was reading the list wrong, my bad |
| 01:00.33 | starseeker | interesting I'm getting a bu_ipwd crash with the cmake build on mac |
| 01:02.41 | brlcad | hm, entirely possible -- I didn't get the chance to test my fix before heading in to the meeting |
| 01:02.56 | brlcad | any particular test sequence? |
| 01:03.01 | starseeker | Program received signal EXC_BAD_ACCESS, Could not access memory. |
| 01:03.01 | starseeker | Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 |
| 01:03.01 | starseeker | 0x93a266b7 in realpath$DARWIN_EXTSN () |
| 01:03.12 | brlcad | realpath was given a null |
| 01:03.17 | starseeker | libbu/brlcad_path.c:100 |
| 01:03.34 | starseeker | I don't see how, and gdb doesn't think ipwd is null... |
| 01:04.09 | brlcad | hm |
| 01:04.18 | brlcad | might be a difference between bsd and linux realpath() |
| 01:04.27 | brlcad | what does your manual page say for the second argument? |
| 01:05.09 | brlcad | I pass NULL for the result since bsd realpath() will use that as a key to malloc and pass the result back as the return value |
| 01:05.19 | brlcad | the first param shouldn't be null.. |
| 01:05.39 | brlcad | oh, DARWIN .. you're on mac too.. |
| 01:05.53 | starseeker | ah, that could be why - I think the proper handling of second argument being NULL in realpath is only guaranteed by POSIX 2008 |
| 01:08.31 | starseeker | considered snarfing GNU's canonicalize_file_name function and putting that into libbu, but it kinda seemed like overkill... |
| 01:10.37 | CIA-58 | BRL-CAD: 03brlcad * r42612 10/brlcad/trunk/include/bu.h: check for PATH_MAX before _MAX_PATH |
| 01:13.17 | CIA-58 | BRL-CAD: 03starseeker * r42613 10/brlcad/branches/cmake/src/libbu/brlcad_path.c: realpath + NULL is not happy on Mac, apparently - will this work? |
| 01:17.39 | starseeker | brlcad: that seems to work here, if you don't mind the static solution - IIRC realpath only runs into trouble on operating systems like HURD that have unlimited path length, and somehow I doubt we'll be worried about running on HURD anytime soon... |
| 01:17.54 | starseeker | heads out |
| 01:19.40 | CIA-58 | BRL-CAD: 03brlcad * r42614 10/brlcad/trunk/src/libbu/brlcad_path.c: unlike 10.6 and recent linux, realpath() on Mac OS X 10.5 is not set up to take NULL for the second paramter so pass in our path buffer and adjust logic accordingly. |
| 01:20.50 | brlcad | similar solution |
| 01:24.20 | brlcad | usually best to avoid function call return values as expressions unless the function specifically returns a boolean (e.g., isspace()); unintentional pointers and integers are common logic bugs |
| 01:59.22 | CIA-58 | BRL-CAD: 03brlcad * r42615 10/brlcad/trunk/TODO: promote plate mode nurbs since it's scheduled for Q2, create a new project section for NURBS with added tasks for implementing implicit CSG to NURBS CSG, documenting the new primitive, and boolean evaluation. |
| 02:15.23 | CIA-58 | BRL-CAD: 03brlcad * r42616 10/brlcad/trunk/TODO: expand, consolidate and clean up the section for NMG/BoT too |
| 02:43.53 | *** join/#brlcad yukonbob (~bch@S0106001cf044d085.ok.shawcable.net) | |
| 02:43.54 | yukonbob | oh hai |
| 03:08.31 | DX^ | Anyone alive that could explain to me how NURBS are rendered |
| 03:08.40 | DX^ | does the program break it up into triangles? |
| 03:08.52 | DX^ | I don't understand how it could otherwise show smooth surfaces |
| 03:20.48 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 03:58.11 | starseeker | DX^: it doesn't break it up into triangles |
| 03:58.40 | starseeker | it builds a surface tree, which provides an initial guess for a hit point which is then iterated to a solution |
| 03:59.15 | starseeker | we'll get triangles eventually for tessellation and shaded displays, but the are only an approximation - the NURBS surface itself is more accurate |
| 04:21.38 | starseeker | brlcad: doesn't that patch return the success/fail value of realpath instead of the result in buffer? |
| 04:24.11 | starseeker | oh, nevermind - I see |
| 04:29.31 | starseeker | nifty - realpath returns what you need as the result. not bad |
| 04:30.53 | CIA-58 | BRL-CAD: 03starseeker * r42617 10/brlcad/branches/cmake/ (5 files in 4 dirs): Sync to trunk 42616 (mostly, brlcad_path.c patch is approximate since the Windows version of realpath is unaddressed in trunk). |
| 05:16.25 | CIA-58 | BRL-CAD: 03brlcad * r42618 10/brlcad/trunk/TODO: little section for STEP-related tasks |
| 08:16.33 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 09:13.26 | *** join/#brlcad Stattrav (~Stattrav@117.192.131.143) | |
| 09:13.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:48.06 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 12:18.21 | starseeker | glares at falling snow and unplowed roads |
| 12:31.08 | starseeker | hmm... slashdot redesigned again |
| 12:35.01 | starseeker | gets introduced to the Stylish Firefox plugin... nifty |
| 13:12.24 | CIA-58 | BRL-CAD: 03starseeker * r42619 10/brlcad/trunk/src/tclscripts/ (archer/Archer.tcl mged/man.tcl): Tweak man page viewer to work in-build-dir |
| 13:47.07 | brlcad | <PROTECTED> |
| 13:47.28 | brlcad | I'd think the embedded path separators will cause problems on windows |
| 13:47.36 | brlcad | that's what file join is supposed to resolve |
| 13:47.42 | DaveLo | Mernin all |
| 13:47.53 | brlcad | howdy DaveLo |
| 13:48.12 | DaveLo | Hows you? take the test yet? |
| 13:49.40 | brlcad | not yet, still have another week or two of studying |
| 13:49.55 | DaveLo | ah, okie. |
| 13:50.02 | CIA-58 | BRL-CAD: 03davidloman * r42620 10/rt^3/trunk/docs/ (4 files): Adding in some .psd's for the wiki graphics. |
| 13:50.24 | DaveLo | stares at the falling snow and is eager to get out there later and make the Ultimate Snow Fortress |
| 14:01.48 | starseeker | brlcad: ok, I can try that |
| 14:06.11 | CIA-58 | BRL-CAD: 03starseeker * r42621 10/brlcad/trunk/src/tclscripts/ (archer/Archer.tcl mged/man.tcl): Don't assume '/' for dir separators |
| 14:08.39 | starseeker | ah, the mged one was just a typo (not sure why it didn't show up before...) archer wasn't using file join where it needed to |
| 14:09.29 | CIA-58 | BRL-CAD: 03starseeker * r42622 10/brlcad/branches/cmake/ (5 files in 4 dirs): Update cmake branch to trunk r42621 |
| 14:39.20 | *** join/#brlcad Stattrav (~Stattrav@117.192.146.62) | |
| 14:39.20 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:41.48 | DaveLo | ``Erik: why is TCL needed in rt3? |
| 14:45.33 | brlcad | DaveLo: tcl.h is included by raytrace.h and bu.h |
| 14:46.09 | brlcad | hoping we can eliminate that inclusion at some point in the future, but decoupling from tcl in the public API is a job in itself |
| 14:46.40 | DaveLo | ah, i see. |
| 14:47.29 | DaveLo | is the tcl libsj included in the windows brlcad binaries install? |
| 14:47.49 | brlcad | should be |
| 14:47.57 | brlcad | won't run without em |
| 14:48.09 | DaveLo | thats what I thought. |
| 14:48.29 | DaveLo | for somereason, i was building rt3 just fine, but now that there is a findTCL.cmake in the works, its failing. |
| 14:48.33 | DaveLo | :/ |
| 14:49.57 | brlcad | might have been pulling some system tcl.h |
| 14:50.25 | DaveLo | not likely, as i don't have tcl.h on my windows system ;) |
| 14:50.35 | brlcad | hm, that's curious then |
| 14:51.12 | brlcad | not only why it's now needing it, but how it worked before too |
| 14:51.34 | DaveLo | i know cmake can find the brlcad include and libs, i just don't think the cmake find is smart enough to dive down in to a subdir of brlcad/include |
| 14:52.02 | DaveLo | I think it was working before because if cmake can find bu.h, then bu.h knows where the tcl headers |
| 14:52.05 | DaveLo | are |
| 14:52.28 | DaveLo | cmake, however, doesn't use bu.h to gain a clue where the tcl headers are. |
| 14:52.29 | DaveLo | :/ |
| 14:54.42 | DaveLo | bah, that's too deep of a rabit hole to dive in atm :/, i'll leave windows till later i guess. |
| 14:56.13 | brlcad | bu.h doesn't know, it just does a #include "bu.h" |
| 14:56.16 | brlcad | er, tcl.h |
| 14:58.07 | brlcad | so something else, something really basic, is going on |
| 14:59.30 | DaveLo | likely something else. :/ |
| 15:01.47 | brlcad | fwiw, include paths are build system trivialities, any dev should be able to diagnose/understand/override fix with ease |
| 15:02.39 | brlcad | otherwise it's like a builder not knowing how a power drill works :) |
| 15:03.48 | DaveLo | heh, well in that case, Im still learning about the power drills, so don't make fun =P |
| 15:04.31 | brlcad | not making fun, just saying "don't fear the power drill" |
| 15:04.51 | brlcad | or treat it like it's untouchable black magic that will take a long time to figure out |
| 15:04.55 | ``Erik | dlo: tcl is required for bu.h |
| 15:05.16 | ``Erik | when using a system that doesn't have tcl.h in /usr/include or /usr/brlcad/include, it was failing |
| 15:07.01 | ``Erik | *readreadread* heh, yeh |
| 15:07.08 | brlcad | cmake adds a little extra complexity, but it's akin to adding a pneumatic compressor to your drill .. it's still a drill though ;) |
| 15:07.19 | DaveLo | well wait... if tcl.h is installed into a non standard location, it was failing? |
| 15:07.25 | ``Erik | probably need a -DTCL_INCLUDE_DIR=C:\some\path\to\brlcad\include |
| 15:07.48 | DaveLo | either of you two going to be in on Friday? |
| 15:07.57 | ``Erik | the problem was that it was failing when tcl was installed to the standard include path... not the path that linux and BRL-CAD expect |
| 15:08.22 | DaveLo | what 'standard include path' are you talking about/ |
| 15:08.24 | DaveLo | ? |
| 15:08.30 | ``Erik | I have no plans to not be in on friday... depends on weather |
| 15:08.33 | ``Erik | /usr/local/ |
| 15:09.43 | ``Erik | mac and linux both abuse the system header directory for user packages like package managed tcl |
| 15:14.11 | ``Erik | O.O gtk3? hmmm |
| 15:35.18 | DaveLo | configure --enable-all or configure --enable-everything |
| 15:35.21 | DaveLo | i cannot remember |
| 15:50.48 | brlcad | they're aliases for the same flag if it was either of those |
| 17:27.39 | DaveLo | 5" on the ground so far. Second wave is coming in a few hours! |
| 17:45.25 | *** join/#brlcad Stattrav (~Stattrav@117.192.143.147) | |
| 17:45.25 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:26.48 | DaveLo | Okay, round one is shoveled. Now, bring on round two! |
| 18:50.13 | CIA-58 | BRL-CAD: 03Dloman 07http://brlcad.org * r2446 10/wiki/GSNet_String: |
| 18:55.03 | CIA-58 | BRL-CAD: 03Dloman 07http://brlcad.org * r2447 10/wiki/GSNet_String: Update table styling |
| 18:56.10 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 18:57.43 | CIA-58 | BRL-CAD: 03Dloman 07http://brlcad.org * r2448 10/wiki/GSNet_String: Adjust table width |
| 19:02.00 | CIA-58 | BRL-CAD: 03Dloman 07http://brlcad.org * r2449 10/wiki/GeometryServiceNetworkProtocol: Fixed headline |
| 19:30.12 | CIA-58 | BRL-CAD: 03Dloman 07http://brlcad.org * r2450 10/wiki/NetMsgTypes: headline fixes and spacing. |
| 19:49.33 | *** join/#brlcad Stattrav (~Stattrav@117.192.143.147) | |
| 19:49.33 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:07.41 | *** join/#brlcad CIA-53 (~CIA@208.69.182.149) | |
| 20:15.24 | CIA-53 | BRL-CAD: 03brlcad * r42623 10/brlcad/trunk/src/libged/ls.c: eliminate dead code |
| 20:18.57 | *** join/#brlcad Ralith (~ralith@d142-058-078-138.wireless.sfu.ca) | |
| 20:22.52 | CIA-53 | BRL-CAD: 03brlcad * r42624 10/brlcad/trunk/src/librt/db_lookup.c: calloc our ptbl so we're initialized to zero |
| 20:34.59 | CIA-53 | BRL-CAD: 03brlcad * r42625 10/brlcad/trunk/src/librt/db_lookup.c: v4 geometry database do not use d_major_type and d_minor_type, so zero-set accordingly as a preventive measure. |
| 20:39.47 | brlcad | https://github.com/mcneel/rhinocommon |
| 20:40.04 | brlcad | (they just released another sdk as open source) |
| 20:41.37 | brlcad | it's the C# portion of Rhino 5.0's new cross-platform SDK |
| 20:47.06 | CIA-53 | BRL-CAD: 03brlcad * r42626 10/brlcad/trunk/src/conv/asc/g2asc.c: do not check values directly. _GLOBAL is merely an attribute-only object. |
| 22:17.18 | *** join/#brlcad Ralith (~ralith@142.58.92.37) | |
| 22:20.43 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 22:20.49 | yukonbob_ | hello, #brlcasd |
| 22:20.56 | yukonbob_ | #brlcad, even. |
| 22:25.04 | yukonbob_ | png.h has 2 diff't prototypes for PNG_EXPORT(). |
| 22:25.44 | yukonbob_ | or... 1s; /me reviews |
| 22:29.20 | *** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net) | |
| 22:29.20 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 22:38.13 | yukonbob_ | :P nn --- conflicting header files from diff't versions of libpng. |
| 22:38.25 | yukonbob_ | *nm |
| 22:51.02 | yukonbob_ | q: how far along in the build process is one if asc2g conversions are running? |
| 23:16.10 | brlcad | http://itmanagement.earthweb.com/osrc/article.php/3922041/50-Open-Source-Applications-for-Sci-Tech-Education.htm |
| 23:16.22 | brlcad | yukonbob_: basically the build is done |
| 23:16.39 | brlcad | all of the sources have compiled by that point |
| 23:23.08 | yukonbob_ | brlcad: congratulate me, then. I've got brlcad built on netbsd for first time in ~2 years. |
| 23:23.28 | yukonbob_ | then fails, but I think I know why. I'll have some patches forthcoming. |
| 23:25.44 | CIA-53 | BRL-CAD: 03brlcad * r42627 10/brlcad/trunk/TODO: |
| 23:25.44 | CIA-53 | BRL-CAD: pull up annotation primitive since it's soon. also relaly need to upgrade the |
| 23:25.44 | CIA-53 | BRL-CAD: back-end svn repo so branches can be tracked better (especially since there is a |
| 23:25.44 | CIA-53 | BRL-CAD: major merge coming soon). push down dbcp/merg and exporting all top-level |
| 23:25.44 | CIA-53 | BRL-CAD: objects in the converters. |
| 23:25.44 | brlcad | excellent |
| 23:25.53 | brlcad | it's been a while since I've done a netbsd build myself |
| 23:27.07 | yukonbob_ | I've been working on this now for last ~24 hours (not non-stop :) ) and think I've got the roadblocks solved for this particlar case... which is NetBSD -current, Tcl8.6b, and some other oddities. |
| 23:28.53 | yukonbob_ | runtime will be another test itself... I'm not intimately familiar w/ itcl/itk, and it's a major-version bump over what brl-cad ships with... so that's be interesting. |
| 23:32.26 | CIA-53 | BRL-CAD: 03brlcad * r42628 10/brlcad/trunk/src/libged/ls.c: |
| 23:32.26 | CIA-53 | BRL-CAD: fix a bug with the ls command where it was printing NULL or garbage for the |
| 23:32.26 | CIA-53 | BRL-CAD: object type if you requested an ls -la long listing. this only occurred for v4 |
| 23:32.26 | CIA-53 | BRL-CAD: geometry databases but was due to an assumption in the code that d_minor_type is |
| 23:32.26 | CIA-53 | BRL-CAD: a suitable index into the rt_functab[] (which it's not). other commands need |
| 23:32.26 | CIA-53 | BRL-CAD: fixing too. |
| 23:44.02 | CIA-53 | BRL-CAD: 03brlcad * r42629 10/brlcad/trunk/src/libged/attr.c: attributes aren't valid for v4, but don't use d_minor_type as an index into rt_functab[] regardless. |
| 23:53.55 | yukonbob_ | default installation == /usr/local/*? |
| 23:58.09 | yukonbob_ | sees is /usr/brlcad |
| 00:05.48 | CIA-53 | BRL-CAD: 03brlcad * r42630 10/brlcad/trunk/src/libged/ls.c: simplify. even though this is libged, there's no compelling reason to use GED_DB_GET_INTERNAL() here since it assumes a GED_OK/ERROR return value if the get fails. we don't actually care much if the get fails. |
| 00:06.16 | CIA-53 | BRL-CAD: 03brlcad * r42631 10/brlcad/trunk/src/libged/wdb_obj.c: match ls.c and attr.c files. ugh, duplication. when can this file die? |
| 00:06.55 | starseeker | brlcad: hmm - don't know how much use rhinocommon will be as C# - don't see a license either, unless I'm missing something |
| 00:10.42 | *** part/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 00:12.45 | CIA-53 | BRL-CAD: 03starseeker * r42632 10/brlcad/branches/cmake/ (8 files in 5 dirs): Update cmake branch to trunk r42631 |
| 00:18.58 | starseeker | brlcad: what do you want to do about needing windows.h for that Win version of the realpath functionality? |
| 00:29.25 | brlcad | starseeker: rhinosommon didn't seem very useful to us at all, was just interesting that they're expanding their opensourceness |
| 00:29.38 | brlcad | their press release was emphasizing that angle |
| 00:29.59 | brlcad | starseeker: condtionally include windows.h in the files that call realpath? |
| 00:30.19 | CIA-53 | BRL-CAD: 03starseeker * r42633 10/brlcad/trunk/src/other/togl/ (336 files in 16 dirs): togl is extradisted in trunk anyway, so stick the cmake branch version in to minimize differences |
| 00:34.11 | starseeker | brlcad: I think that's what I did initially? unless I misread, you didn't seem happy about a system header in libbu |
| 00:41.40 | starseeker | what the heck... what happened to the togl directory? |
| 00:47.42 | starseeker | checks out other again... |
| 00:50.20 | starseeker | there we go |
| 01:16.53 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 01:36.27 | epileg | brlcad: ping |
| 02:08.48 | *** join/#brlcad yukonbob (~bch@S0106002129e399fc.ok.shawcable.net) | |
| 02:08.54 | yukonbob | hello, #brlcad |
| 02:09.24 | CIA-53 | BRL-CAD: 03starseeker * r42634 10/brlcad/branches/cmake/ (CMakeLists.txt misc/CMake/CompilerFlags.cmake): Start trying to hammer the C/CXX flags logic into shape. More to do here, but getting better (should actually be using more of the flags now...) |
| 02:09.27 | starseeker | yukonbob: howdy :-) |
| 02:09.32 | yukonbob | starseeker: :) |
| 02:09.40 | starseeker | so you have things running with tcl/tk 8.6? |
| 02:09.45 | yukonbob | starseeker: indeed. |
| 02:09.50 | starseeker | trunk? |
| 02:09.55 | yukonbob | first time I've had brlcad running natively on this box in ~2years |
| 02:10.01 | yukonbob | <PROTECTED> |
| 02:10.06 | starseeker | heh |
| 02:10.16 | starseeker | are you using trunk or an older version? |
| 02:10.20 | yukonbob | fwiw that fscking *sucked* *sucked* *sucked* *sucked* *sucked*. |
| 02:10.45 | starseeker | 8.5 gives us modern stuff like the new tree widget |
| 02:11.02 | yukonbob | moving to 8.5 while it was in beta had me fall off the wagon. |
| 02:11.15 | starseeker | ah, back in the day |
| 02:11.24 | starseeker | (was gonna say, 8.5 has been stable for a while...) |
| 02:11.27 | yukonbob | not trying to be a drama queen, just stating the facts. |
| 02:11.55 | starseeker | yukonbob: you should be happy then we haven't gone leaping onto the 8.6 bandwagon yet :-P |
| 02:12.01 | yukonbob | was helping push the boundaries of tcl 8.4 back in the day :P |
| 02:12.16 | yukonbob | starseeker: what's the holdup -- I'm here now!!!1! |
| 02:12.24 | yukonbob | ;) |
| 02:12.30 | starseeker | what were the issues with 8.6? |
| 02:12.37 | starseeker | the one attempt I made didn't go so well |
| 02:13.06 | yukonbob | I *just* fired up mged... and have done *some* runtime patching, but haven't tested exhaustively. |
| 02:13.14 | starseeker | nods |
| 02:13.18 | starseeker | further than I got |
| 02:13.24 | starseeker | are you using trunk? |
| 02:13.27 | yukonbob | y |
| 02:13.42 | yukonbob | I've been running trunk for.... maybe a year now? |
| 02:13.48 | yukonbob | on NetBSD cvs -head. |
| 02:13.49 | starseeker | cool - hopefully using only package require for things like itcl/itk helped... |
| 02:14.04 | yukonbob | heh -- thats one of the things I patched ;) |
| 02:14.17 | starseeker | hmm? you went back to the C api? |
| 02:14.57 | yukonbob | no, but had to adjust for version #s |
| 02:15.01 | starseeker | ah |
| 02:15.28 | starseeker | when I tried 8.6 we were still talking to itcl/itk at the C level... Something Wasn't Happy |
| 02:15.52 | yukonbob | anyway... it's literally been a few years since I've been in mged -- I'm going to re-introduce myself to it, and shake-out bugs as they present themselves |
| 02:16.05 | starseeker | wasn't urgent enough for me to dig deep, since package require was obviously a better way and the main benefit of 8.6 was the Cocoa backend on Mac |
| 02:16.13 | starseeker | welcome back :-) |
| 02:16.20 | yukonbob | ya, thanks ;) |
| 02:16.24 | starseeker | you might check out archer - it's had a lot of work done |
| 02:16.46 | yukonbob | is going to get his name back into the changelogs... |
| 02:17.00 | yukonbob | archer != tcl/tk, correct? |
| 02:17.28 | yukonbob | ya -- when I was last using brlcad, I think archer was in design phase, or maybe "Hey, I've got an idea' phase. |
| 02:18.39 | starseeker | no, archer is tcl/tk |
| 02:18.46 | CIA-53 | BRL-CAD: 03starseeker * r42635 10/brlcad/branches/cmake/CMakeLists.txt: Uh, whoops - add the flags if the build type IS set, not when it isn't... |
| 02:18.48 | starseeker | one of the drivers for using 8.5, actually |
| 02:19.12 | starseeker | it's not all the way there yet, but there's some cool new stuff |
| 02:19.18 | starseeker | tree widget is especially nifty |
| 02:19.36 | yukonbob | cool. |
| 02:20.41 | yukonbob | Tcl is what brought me to brl-cad in the first place, and I haven't lost my love of Tcl... the joy of brl-cad is what kept me hacking to get it back working, but I'm exceptionally interested in Tcl/BRL-CAD, and C/BRL-CAD |
| 02:21.37 | yukonbob | holy fsck, I don't remember a single mged-specific command :P |
| 02:30.02 | starseeker | remember where the quick reference card is? :-P |
| 02:30.03 | CIA-53 | BRL-CAD: 03starseeker * r42636 10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: Better - don't need if wrappers now, fix spacing |
| 02:31.46 | yukonbob | grabbing mged tutorial, documentation... |
| 02:32.30 | CIA-53 | BRL-CAD: 03starseeker * r42637 10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: Er - wrap the message so it doesn't blather every time |
| 02:36.21 | yukonbob | ahhhhhh... nice. |
| 02:43.11 | yukonbob | thank $deity there's restraint and good sense wrt display and interface on brlcad... |
| 02:43.40 | yukonbob | my screen happens to be slow, but the wireframe display and kb controls make everything still so easy to manage... |
| 02:44.24 | yukonbob | computers may be 100x faster than they were $x years ago, but there are always "resource constrained" systems, or just people (like me) who want to pretent they're one one... |
| 02:52.36 | CIA-53 | BRL-CAD: 03starseeker * r42638 10/brlcad/branches/cmake/CMakeLists.txt: enable optimized flags for Release build, and warn if they are disabled - also set up 64 bit flag for MSVC, although this is untested and the CompilerFlags.cmake file doesn't yet incorporate MSVC flags (it should, TODO) |
| 02:53.01 | starseeker | much better |
| 03:08.08 | CIA-53 | BRL-CAD: 03starseeker * r42639 10/brlcad/branches/cmake/ (CMakeLists.txt misc/CMake/CompilerFlags.cmake): Get most of the remaining summary report entries functioning, although need to check what compilation progress means in configure.ac. Also will need to re-sync warning/strict flag logic to match new autotools settings. |
| 03:28.50 | CIA-53 | BRL-CAD: 03starseeker * r42640 10/brlcad/branches/cmake/CMakeLists.txt: Enable the CMake counterpart to the verbose output option. Also, finally turn off the static libraries when doing a debug build unless they're specifically requested (non MSVC builds) |
| 03:34.04 | yukonbob | ? no more "tor" in mged? |
| 03:45.41 | brlcad | there's still torii |
| 03:46.24 | epileg | hello brlcad |
| 03:46.28 | brlcad | howdy epileg |
| 03:47.14 | yukonbob | re-familiarizing self w/ mged... I think I'll have to work through tutorial briefly front-> back :} |
| 03:47.47 | yukonbob | brlcad: I've *finally* got a running instance here again... happy days ;) |
| 03:48.12 | brlcad | great |
| 03:48.20 | brlcad | going to write some code then? |
| 03:48.29 | yukonbob | yes. |
| 03:48.33 | brlcad | fantastic |
| 03:48.38 | yukonbob | I've already got some patches for 8.6 |
| 03:48.50 | yukonbob | ...and some cross-platform tweaks for consideration. |
| 03:49.23 | brlcad | can't wait to see them |
| 03:49.57 | yukonbob | and some features that I've had since 7.x that are still applicable... |
| 03:50.19 | brlcad | there's now also a slew of "contributor quickies" that are meant to be tiny projects only lasting a few days, to help someone get emmersed |
| 03:50.22 | brlcad | http://brlcad.org/wiki/Contributor_Quickies |
| 03:51.09 | brlcad | slowly expanding that list as topics come up |
| 03:51.50 | yukonbob | nods. |
| 03:52.14 | yukonbob | well, looking forward to working w/ you again :) it's been a long time. |
| 03:52.28 | brlcad | yeah, it has been a while |
| 03:53.20 | yukonbob | 2 or three years, off top of head :P |
| 03:54.54 | yukonbob | needs to update hub for new decade ;P |
| 03:57.08 | CIA-53 | BRL-CAD: 03brlcad * r42641 10/brlcad/trunk/src/librt/db_float.c: ws |
| 03:58.59 | yukonbob | wow... rt is fast |
| 04:00.13 | yukonbob | (though I crashed it on first try; I'll try to remember (and bother)) to keep logs/fixes of problems... |
| 04:02.40 | CIA-53 | BRL-CAD: 03starseeker * r42642 10/brlcad/branches/cmake/src/other/togl/ (src/CMakeLists.txt tools/genStubs.tcl): |
| 04:02.41 | CIA-53 | BRL-CAD: Fix togl build to only re-build on re-run of CMake, which is inevitable because |
| 04:02.41 | CIA-53 | BRL-CAD: we're handling header template generation with CMake. This tweak, however, |
| 04:02.41 | CIA-53 | BRL-CAD: results in proper termination instead of regenerating the header with every make |
| 04:02.41 | CIA-53 | BRL-CAD: call. |
| 04:02.53 | brlcad | epileg: sure, usually :) |
| 04:02.56 | CIA-53 | BRL-CAD: 03brlcad * r42643 10/brlcad/trunk/ (doc/deprecation.txt include/db.h): rt_fastf_float(), rt_mat_dbmat() and rt_dbmat_mat() are deprecated since they pertain to old v4 file i/o and are platform endian dependent. |
| 04:04.33 | CIA-53 | BRL-CAD: 03brlcad * r42644 10/brlcad/trunk/doc/deprecation.txt: add the version number for the other 7.18 deprecations |
| 04:06.27 | epileg | to build debian packages with sh/make_deb.sh is not so dificult but there is a problem, if You are in a 64 bit platform, it will create just hte 64 bit and non-architecture dependents packages |
| 04:07.53 | epileg | is this a problem brlcad? |
| 04:07.55 | brlcad | epileg: well right now it doesn't really do anything, right? ;) |
| 04:08.02 | epileg | yes |
| 04:08.11 | brlcad | so it's an improvement ;) |
| 04:08.15 | CIA-53 | BRL-CAD: 03starseeker * r42645 10/brlcad/branches/cmake/TODO.cmake: Archer now runs from the build dir. |
| 04:09.53 | epileg | ok, then, and if You are agree, we can try to create the deb packages just in to the /usr/brlcad/ directory |
| 04:10.54 | brlcad | yeah, the make_deb.sh script should be like our other non-package-management system binary distributions, just building an --enable-all dependency-free build that can be posted up for users |
| 04:11.19 | CIA-53 | BRL-CAD: 03starseeker * r42646 10/brlcad/branches/cmake/ (5 files in 5 dirs): Update cmake branch to trunk r42645 |
| 04:11.53 | brlcad | ideally, we'd post a 32-bit and 64-bit verison, but you've got a lot of room to decide how to manage things best since you're maintaining that platform |
| 04:13.00 | brlcad | epileg: if you've not yet read it, you should read "NAMING A BINARY RELEASE" and "MAKING A RELEASE" in the HACKING file |
| 04:13.14 | epileg | ok |
| 04:13.41 | brlcad | just to be familiar with the usual release steps we take for other builds |
| 04:13.54 | epileg | aha |
| 04:14.36 | brlcad | the only part not documented there is that some platforms use a --prefix=/usr/brlcad/rel-7.18.0 and symbolic links are created in /usr/brlcad after install |
| 04:14.47 | brlcad | that way multi-version installs work |
| 04:15.44 | epileg | so, to do that in debian like systems, We must put the version as a par of the name |
| 04:16.00 | epileg | part* |
| 04:16.23 | brlcad | what do you mean? |
| 04:16.50 | brlcad | it's not the same convention as /usr/brlcad-7.18.0 |
| 04:16.54 | brlcad | that'd suck |
| 04:16.56 | epileg | ordinary package: brlcad_7.18.0-1_i386.deb |
| 04:17.03 | brlcad | ah, the file name, that's fine |
| 04:17.14 | brlcad | that's actually what NAMING A BINARY RELEASE talks about |
| 04:17.24 | brlcad | there's a specific format we try to make most of them match |
| 04:17.34 | epileg | not just the file name but the project name |
| 04:18.17 | brlcad | are you referring to what apt does or .deb files in general? |
| 04:18.30 | brlcad | I know apt has it's own rules, but it didn't sound like you were trying to address apt |
| 04:20.11 | epileg | exactly, in debian You can only have installed one release of a project at the same time |
| 04:23.03 | brlcad | mm, okay |
| 04:23.08 | brlcad | that's fine, the /usr/brlcad it is then |
| 04:23.18 | brlcad | s/the /then / |
| 04:25.42 | epileg | one question, simbolic links are overwritten with the last installation? |
| 04:27.49 | CIA-53 | BRL-CAD: 03starseeker * r42647 10/brlcad/trunk/ (4 files in 4 dirs): Put the archer.ico file where it belongs |
| 04:28.27 | brlcad | with multiple version installs, yes usually .. so the last installed is always "default" yet you can get to any version |
| 04:29.03 | epileg | well, this is not allowed by apt too :-/ |
| 04:29.04 | brlcad | note that the symlinks wouldn't necessarily have to be bundled files, they could be a post-install script |
| 04:29.56 | epileg | well, no problem like this |
| 04:31.05 | brlcad | more important to be reliably available and well integrated (like your other usability improvements) |
| 04:31.40 | brlcad | multi-versions is for stand-alone binary installs -- if people really want that behavior, they should be able to download one of the other linux binaries |
| 04:31.52 | brlcad | so not a big deal |
| 04:31.54 | epileg | sure |
| 04:33.38 | epileg | about the package name, can I keep the debian style on it? :-) |
| 04:34.22 | brlcad | from what you wrote, it already is almost a match |
| 04:34.56 | brlcad | only difference would be to prefer the project long name instead of the short name, unless there was a technical limitation |
| 04:35.50 | brlcad | i.e., BRL-CAD_7.18.0-1_i386.deb |
| 04:37.12 | yukonbob | brlcad: OK -- i'm being lazy -- what's cmd to select an obj from mged (using kb cmds to mged prompt) |
| 04:37.15 | yukonbob | ? |
| 04:37.52 | brlcad | yukonbob: depends if it's a primitive or not, sed or oed |
| 04:38.08 | yukonbob | ah -- those are familiar |
| 04:38.13 | yukonbob | brlcad: thx ;) |
| 04:38.15 | brlcad | those two have different syntax |
| 04:38.21 | yukonbob | it'll all come back. |
| 04:38.44 | yukonbob | is one of those guys who doesn't like to have to use mouse. |
| 04:39.51 | CIA-53 | BRL-CAD: 03brlcad * r42648 10/brlcad/trunk/TODO: sed+oed, right hand begone |
| 04:39.54 | brlcad | then you should implement the 'select' command, it's on our todo list :) |
| 04:40.04 | brlcad | highly useful command for keyboard modelers |
| 04:40.40 | yukonbob | will look into it. |
| 04:41.03 | yukonbob | after he finds out how to get out of 'sed' mode... (but not *immediately* after) ;) |
| 04:41.14 | brlcad | "reject" |
| 04:41.18 | brlcad | "accept" |
| 04:42.20 | yukonbob | oh hey -- you mentioned call for papers other week... did I ask if was for something specific, or you're just collecting material? |
| 04:43.23 | brlcad | doesn't recall mentioning a call for papers recently |
| 04:44.23 | yukonbob | you asked if I'd write up something -- (but wasn't a specific request) -- must've been for general tutorial library or such... |
| 04:48.27 | brlcad | well, there are the quickie documentation ideas |
| 04:48.58 | brlcad | and there is http://brlcad.org/wiki/Community_Publication_Portal |
| 04:49.05 | brlcad | which has more ideas pending publication |
| 04:50.44 | yukonbob | will familiarize self w/ outstanding issues/requests over next few weeks... |
| 04:50.46 | brlcad | ``Erik: on that same note, any possibility you'd write up a brief draft on the adrt/libtie integration work -- doesn't have to be fancy or finished, I can wordsmith it, but something that describes what you did, why, basic results .. the same stuff you were talking about yesterday would be perfect |
| 04:50.50 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 04:51.32 | brlcad | yukonbob: I wouldn't dwell too much on outstanding issues -- there are hundreds -- more useful to just pick one issue and try to fix it |
| 04:52.21 | brlcad | otherwise, you could be familiarizing for months and never actually get to anything useful |
| 04:52.41 | yukonbob | oh indeed... I won't dwell --- I'm familar w/ the project (and my interests), so I'll marry the two -- I'm just rusty atm ;) |
| 04:53.00 | brlcad | pretty much *anything* in the TODO or BUGS file or Quickies page or publication page |
| 04:54.17 | epileg | brlcad: what do You prefer, four packages or just one? |
| 04:54.48 | brlcad | epileg: which four? |
| 04:55.06 | CIA-53 | BRL-CAD: 03starseeker * r42649 10/brlcad/branches/cmake/ (8 files in 7 dirs): Get cmake branch a bit closer to trunk |
| 04:55.55 | epileg | brlcad-data, brlcad-bin, brlcad-dev and brlcad-doc |
| 04:56.02 | CIA-53 | BRL-CAD: 03starseeker * r42650 10/brlcad/trunk/src/libbu/dirname.c: Pull in the change from cmake to make dirname a bit more cross platform |
| 04:57.02 | CIA-53 | BRL-CAD: 03starseeker * r42651 10/brlcad/trunk/src/ (9 files in 6 dirs): Various cmake branch tweaks to bat files, tcl scripts - also remove some WIN32 hacks. |
| 04:59.26 | brlcad | yukonbob: here's a great one to start with |
| 04:59.30 | brlcad | "let the cp command take multiple arguments for simultaneously creating multiple named copies" |
| 05:00.15 | brlcad | cp command is src/libged/copy.c |
| 05:00.19 | yukonbob | ie: cp existing1 new1 new2 new3 new4? |
| 05:00.36 | brlcad | exactly |
| 05:03.39 | yukonbob | oh noes --- is there a reason "animate" cmd is spelled "animmate"? |
| 05:05.02 | epileg | brlcad: brlcad-data, brlcad-bin, brlcad-dev and brlcad-doc |
| 05:06.00 | epileg | brlcad: this is the actual deb packaging distribution made by Manuel |
| 05:18.33 | *** join/#brlcad Stattrav (~Stattrav@122.172.40.92) | |
| 05:18.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:19.05 | CIA-53 | BRL-CAD: 03starseeker * r42652 10/brlcad/trunk/configure.ac: manuals/archer isn't there anymore |
| 05:22.23 | CIA-53 | BRL-CAD: 03starseeker * r42653 10/brlcad/trunk/doc/html/manuals/Makefile.am: update manuals/Makefile.am too |
| 05:30.33 | yukonbob | is there a [red] for editing params of a primitive? |
| 05:30.52 | yukonbob | (i.e.: resetting a torus' radii, etc.) |
| 05:33.32 | yukonbob | sees ted... |
| 05:44.01 | yukonbob | ok -- why are sed/ted not having the params "stick". |
| 05:44.03 | yukonbob | ? |
| 06:38.40 | *** join/#brlcad yukonbob (~bch@S0106001cf044d085.ok.shawcable.net) | |
| 06:38.59 | epileg | brlcad: I understand that You prefer only one package, isn't it? |
| 08:48.30 | CIA-53 | BRL-CAD: 03ThedaHouser 07http://brlcad.org * r2452 10/wiki/Help:Navigation: /* Sidebar */ |
| 12:19.10 | CIA-53 | BRL-CAD: 03Sean 07http://brlcad.org * r2453 10/wiki/Help:Navigation: Reverted edits by [[Special:Contributions/ThedaHouser|ThedaHouser]] ([[User talk:ThedaHouser|Talk]]); changed back to last version by [[User:Sean|Sean]] |
| 12:19.29 | CIA-53 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:ThedaHouser]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 12:21.29 | brlcad | epileg: that only makes sense for managed integration, not for stand-alone .deb files |
| 12:21.38 | brlcad | they can be combined into one... |
| 12:45.54 | epileg | thanks brlcad. I ask You all this things because I feel as a someone who's nearly to "destroy" the previous deb work. That's all. |
| 12:46.28 | epileg | brlcad: but if You are agree, me too. |
| 13:13.52 | *** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de) | |
| 13:46.22 | CIA-53 | BRL-CAD: 03starseeker * r42654 10/brlcad/branches/cmake/src/ (CMakeLists.txt libpc/CMakeLists.txt): Add CMakeLists.txt file for libpc |
| 13:52.01 | CIA-53 | BRL-CAD: 03starseeker * r42655 10/brlcad/branches/cmake/src/tclscripts/mged/CMakeLists.txt: Add botedit.tcl to the CMakeLists.txt file |
| 13:53.03 | CIA-53 | BRL-CAD: 03starseeker * r42656 10/brlcad/branches/cmake/src/tclscripts/archer/CMakeLists.txt: Add DataUtils.tcl to CMakeLists.txt |
| 14:00.03 | CIA-53 | BRL-CAD: 03starseeker * r42657 10/brlcad/branches/cmake/include/CMakeLists.txt: Add fft.h to header list. |
| 14:29.03 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 14:33.10 | CIA-53 | BRL-CAD: 03starseeker * r42658 10/brlcad/branches/cmake/src/other/ (7 files in 7 dirs): add some headers and other files, LIBTERM->TERMLIB |
| 14:38.53 | CIA-53 | BRL-CAD: 03starseeker * r42659 10/brlcad/branches/cmake/doc/docbook/lessons/ (en/CMakeLists.txt es/CMakeLists.txt): Fix a couple of docbook target paths |
| 14:53.38 | CIA-53 | BRL-CAD: 03starseeker * r42660 10/brlcad/branches/cmake/sh/CMakeLists.txt: Add conversion.sh to the scripts list |
| 14:58.03 | CIA-53 | BRL-CAD: 03starseeker * r42661 10/brlcad/branches/cmake/src/libpc/CMakeLists.txt: Copy/paste error |
| 15:04.41 | CIA-53 | BRL-CAD: 03starseeker * r42662 10/brlcad/trunk/doc/ (4 files in 2 dirs): Not sure how far it got, but VolIV in docbook now has a 'correct' place to go, so put it there. |
| 15:07.13 | CIA-53 | BRL-CAD: 03starseeker * r42663 10/brlcad/trunk/ (configure.ac doc/Makefile.am doc/book/): And remove the book directory |
| 15:16.10 | CIA-53 | BRL-CAD: 03starseeker * r42664 10/brlcad/trunk/doc/docbook/books/en/BRL-CAD_Tutorial_Series-VolumeIV.xml: Point to local docbook resources |
| 15:19.35 | CIA-53 | BRL-CAD: 03starseeker * r42665 10/brlcad/branches/cmake/ (6 files in 4 dirs): Update cmake branch to trunk r42664 |
| 17:03.32 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 17:39.25 | CIA-53 | BRL-CAD: 03tbrowder2 * r42666 10/brlcad/trunk/src/mged/setup.c: ws |
| 19:22.59 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 19:23.01 | yukonbob_ | oh hai |
| 19:28.04 | yukonbob_ | q: re: sed/ted. when I'm presented w/ objects attibutes in ted-spawned editor, none of my changes seem to take effect. Is something basic I'm missing? |
| 19:32.57 | starseeker | yukonbob_: auugh |
| 19:33.01 | starseeker | this is with trunk? |
| 19:33.15 | starseeker | you're saving the text file before closing the editor? |
| 19:36.26 | yukonbob_ | starseeker: heh. I know you have to ask these questions. Yes. and my computer is plugged in and turned on. |
| 19:36.38 | yukonbob_ | starseeker: is 7.18.0 |
| 19:37.38 | yukonbob_ | fwiw, my remember my platform is still "unique" in the sense I'm running tcl 8.6b, and itl/itk 4, among other things. |
| 19:37.49 | yukonbob_ | *itcl/itk |
| 19:45.06 | yukonbob_ | starseeker: let me know if you can confirm bug... |
| 19:47.59 | yukonbob_ | starseeker: ping? |
| 20:46.56 | yukonbob_ | starseeker: ping |
| 21:58.57 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 22:18.06 | yukonbob_ | starseeker: ping -- curious to know if you see same issues re: sed/ted. |
| 22:22.27 | starseeker | yukonbob_: sorry, passed out (lot of snow shoveling) |
| 22:22.44 | yukonbob_ | heh |
| 22:23.05 | yukonbob_ | starseeker: curious --- do you see same effect on what you'd consider to be a stable system? |
| 22:23.18 | starseeker | don't mean to seem insulting - we've had problems with both ted and red in recent history, but thought we had them fix |
| 22:23.21 | starseeker | ed |
| 22:23.22 | starseeker | tries... |
| 22:23.24 | yukonbob_ | I did something like: |
| 22:23.34 | yukonbob_ | make x tor ... |
| 22:23.45 | yukonbob_ | then: sed x; ted |
| 22:24.06 | yukonbob_ | [edit], [save], [exit]. No changes. |
| 22:24.18 | yukonbob_ | subsequent "ted" indicate no changes, too. |
| 22:24.46 | yukonbob_ | re: insulting -- no offence taken; likewise, I hope :) |
| 22:24.53 | starseeker | ah - there was a post 7.18.0 fix to ted |
| 22:25.09 | yukonbob_ | starseeker: can you point me to diff? |
| 22:25.12 | starseeker | 'course not |
| 22:25.15 | starseeker | is looking |
| 22:25.28 | yukonbob_ | wants his super-dumb primitives!!!1! :) |
| 22:25.56 | starseeker | r42276 |
| 22:28.50 | starseeker | it seems to work in my 7.18.1 build (ted) |
| 22:35.45 | CIA-53 | BRL-CAD: 03starseeker * r42667 10/brlcad/trunk/src/mged/tedit.c: Add nano to the list of editors we know about |
| 22:36.18 | starseeker | yukonbob_: any luck? |
| 23:14.58 | CIA-53 | BRL-CAD: 03starseeker * r42668 10/brlcad/branches/cmake/ (3 files in 3 dirs): fill in some of the variables pkgconfig files expect - once CMake is the main build system, need to revisit the issue of pkgconfig |
| 23:19.10 | yukonbob_ | starseeker: I'll have to try later. |
| 23:19.32 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 23:20.00 | yukonbob_ | but r42276 has my changes ( or collection of changes ), correct? |
| 23:23.45 | starseeker | those are the changes that made ted work forme |
| 23:31.45 | yukonbob_ | ok; did you observe the broken behaviour I described above in prev. (7.18.0) code? |
| 23:33.31 | CIA-53 | BRL-CAD: 03starseeker * r42669 10/brlcad/branches/cmake/src/brlman/CMakeLists.txt: Get cute with brlman - write one version out for the build bin dir that will work locally, and put the one to be installed in src/brlman/brlman |
| 23:35.53 | yukonbob_ | starseeker: ----^ |
| 23:42.32 | starseeker | yukonbob_: yes - we got a bug report of ted not applying changes |
| 23:42.50 | starseeker | the red thing was a bit further back - let me see if red is working... |
| 23:44.34 | starseeker | seems to accept a change here in a quick test |
| 23:46.01 | yukonbob_ | starseeker: re: bug -- ok -- that's good. I'm considering my whole system "suspect" because it's 1) quite non-standard 2) using beta software at it's core, so to corelate events/behaviour w/ other systems is important for me... |
| 23:46.14 | yukonbob_ | s/re: bug/re: bug report/ |
| 23:55.53 | CIA-53 | BRL-CAD: 03starseeker * r42670 10/brlcad/trunk/src/other/jove/ (Makefile.am jove_main.c mkversion.sh): That's an aweful lot of logic just to set a version number, which isn't particularly important for our uses anyway - set it to 2.1 in jove_main.c (the only place that appears to use it) and call it done. |
| 23:56.29 | starseeker | yukonbob_: to be fair, it's quite possible our new editor logic isn't happy on that particular OS |
| 23:58.05 | yukonbob_ | can't imagine that would be too difficult... it's basically an exec to a tmpfile, no? |
| 23:58.41 | starseeker | yes, but it's surprisingly annoying |
| 23:58.48 | yukonbob_ | ie: exec "$env(editor) $tmpfile"; # blocking call to editor |
| 23:58.53 | yukonbob_ | read $tmpfile. |
| 23:59.38 | starseeker | take a look at tedit.c in mged and src/libged/editit.c |
| 00:00.46 | CIA-53 | BRL-CAD: 03starseeker * r42671 10/brlcad/branches/cmake/ (6 files in 3 dirs): Update cmake to trunk r42670 |
| 00:28.22 | CIA-53 | BRL-CAD: 03starseeker * r42672 10/brlcad/branches/cmake/ (3 files in 3 dirs): sigh. jove is explicitly referenced as the editor of last resort in other code, so go ahead and build it. wonder if this actually works on Windows... |
| 00:40.23 | CIA-53 | BRL-CAD: 03starseeker * r42673 10/brlcad/trunk/src/other/libz/zconf.h.cmakein: add the fix from 41902 to zconf.h.cmakein too |
| 00:48.45 | yukonbob_ | starseeker: re: jove -- in case of ted, it says it'll run "ed" by default. |
| 00:48.59 | yukonbob_ | <PROTECTED> |
| 00:49.21 | starseeker | nods |
| 00:52.57 | CIA-53 | BRL-CAD: 03starseeker * r42674 10/brlcad/trunk/src/other/step/src/ (7 files in 3 dirs): Hmm - warning flags got passed to step, which isn't happy - maybe could ignore, but since we're maintaining the code anyway might as well... |
| 01:00.19 | CIA-53 | BRL-CAD: 03starseeker * r42675 10/brlcad/branches/cmake/ (11 files in 6 dirs): |
| 01:00.19 | CIA-53 | BRL-CAD: OK, this should bring the compiler flags logic pretty darn close to the latest |
| 01:00.19 | CIA-53 | BRL-CAD: autotools, with this possible exception of not isolating the src/other dir quite |
| 01:00.19 | CIA-53 | BRL-CAD: well enough - on the other hand, may be OK since it built successfully on gentoo |
| 01:00.19 | CIA-53 | BRL-CAD: with these settings. |
| 01:22.56 | CIA-53 | BRL-CAD: 03starseeker * r42676 10/brlcad/trunk/src/mged/dm-rtgl.c: interp->INTERP in rtgl |
| 01:23.35 | CIA-53 | BRL-CAD: 03starseeker * r42677 10/brlcad/branches/cmake/ (CMakeLists.txt src/mged/CMakeLists.txt src/mged/dm-rtgl.c): Allow the enabling of RTGL, although things look to be a tad broken at the moment - need to check trunk. |
| 01:49.11 | CIA-53 | BRL-CAD: 03starseeker * r42678 10/brlcad/trunk/src/libdm/dm-rtgl.c: (log message trimmed) |
| 01:49.11 | CIA-53 | BRL-CAD: This gets past the initial bu_malloc error, but we've got some kind of weirdness |
| 01:49.11 | CIA-53 | BRL-CAD: going on here. The RT_CK_SEGS test in recordHit fails with what looks like a |
| 01:49.11 | CIA-53 | BRL-CAD: bad magic error - printing out the seg list in debug shows a lot of strange |
| 01:49.11 | CIA-53 | BRL-CAD: looking numbers, and commenting out the check shows a lot of one hit reports and |
| 01:49.12 | CIA-53 | BRL-CAD: a visible rtgl raytrace (e.g. aside from the errors it largely succeeds.) rtgl |
| 01:49.13 | CIA-53 | BRL-CAD: code hasn't changed in quite a while, so something must have changed out from |
| 01:50.47 | CIA-53 | BRL-CAD: 03starseeker * r42679 10/brlcad/branches/cmake/src/libdm/dm-rtgl.c: Might as well sync this from trunk... |
| 01:52.55 | CIA-53 | BRL-CAD: 03starseeker * r42680 10/brlcad/branches/cmake/TODO.cmake: Getting down there - add note on opensolaris |
| 01:59.08 | CIA-53 | BRL-CAD: 03starseeker * r42681 10/brlcad/branches/cmake/TODO.cmake: add note about library versions in src/other builds |
| 02:02.13 | CIA-53 | BRL-CAD: 03starseeker * r42682 10/brlcad/branches/cmake/TODO.cmake: note wish exe on Windows needs work |
| 02:07.20 | brlcad | starseeker: you threw in a new logic scope, but didn't fix the indentation in dm-rtgl.c |
| 02:07.31 | starseeker | oh, sorry |
| 02:07.33 | starseeker | fixes |
| 02:07.43 | brlcad | and if( isn't the right style |
| 02:08.24 | brlcad | otherwise, that looks like a good fix for a category of alloc failures |
| 02:12.34 | CIA-53 | BRL-CAD: 03starseeker * r42683 10/brlcad/trunk/src/libdm/dm-rtgl.c: ws, indent |
| 02:13.13 | brlcad | wow, that hit a lot more than expected |
| 02:14.31 | brlcad | er, yeah.. that's not right |
| 02:15.15 | brlcad | starseeker: how'd you auto-indent that? |
| 02:15.24 | starseeker | indent.sh and ws.sh |
| 02:15.35 | brlcad | huh, it looks like it's using 2-char indent |
| 02:16.19 | brlcad | odd, indent.sh here reverts your changes |
| 02:16.29 | starseeker | blinks |
| 02:16.33 | brlcad | you might have something in your .emacs |
| 02:16.40 | starseeker | or .vimrc |
| 02:16.52 | starseeker | go ahead and commit - I won't argue |
| 02:17.10 | starseeker | is more concerned about what's happening with the rtgl raytrace |
| 02:18.11 | brlcad | try running indent.sh on vers.c |
| 02:18.16 | brlcad | does it modify the file? |
| 02:18.52 | starseeker | yes - just the return brlcad_ident line |
| 02:19.10 | starseeker | which is the only one there, of course... |
| 02:19.18 | brlcad | svn revert vers.c, move your .emacs out of the way, and retry |
| 02:19.40 | brlcad | it shouldn't modify |
| 02:20.12 | starseeker | still did |
| 02:20.29 | brlcad | what platform are you on? |
| 02:20.34 | starseeker | gentoo |
| 02:20.47 | brlcad | emacs --version |
| 02:20.54 | CIA-53 | BRL-CAD: 03brlcad * r42684 10/brlcad/trunk/src/libdm/dm-rtgl.c: revert and fix formatting. |
| 02:20.55 | starseeker | GNU Emacs 23.2.1 |
| 02:22.34 | brlcad | hm, okay -- so the indent.sh is unusable by you for some reason -- is there any clue in the output when you run it? some warning or error? |
| 02:26.10 | starseeker | no - just "Loading vc-svn..." |
| 02:26.20 | starseeker | Indenting region... |
| 02:26.23 | starseeker | Indenting region... done |
| 02:26.30 | brlcad | hm, darn |
| 02:26.31 | starseeker | saving and wrote lines |
| 02:26.35 | brlcad | suspect something in misc/batch-indent-region.el is getting interpreted differently causing the variable block to be ignored |
| 02:26.51 | brlcad | well, so it's just unusable for you until debugged |
| 02:26.57 | starseeker | nods |
| 02:27.16 | brlcad | you'll have to stick with manually indenting or vim (the vi-line mode should be respected if you turn it on) |
| 02:27.42 | starseeker | that's the mode name? vi-line? |
| 02:27.47 | brlcad | only an issue because that last edit is a prime example that can lead to a logic bug later |
| 02:28.19 | brlcad | no, it's not |
| 02:31.24 | starseeker | hmm - my default vim setup doesn't work gg=G indents everything wrong |
| 02:36.43 | brlcad | :help 'modeline' |
| 02:36.59 | brlcad | turning that on should make it respect the modeline at the bottom of every file |
| 02:37.32 | brlcad | otherwise, you can set the style in your .vimrc with rules similar to this: http://drupal.org/node/29325 |
| 02:37.52 | brlcad | except it's shiftwidth=4 tabstop=8 |
| 02:48.42 | starseeker | the modeline gets close |
| 03:13.49 | brlcad | there's probably more variables that could/should be set for vim users |
| 03:14.02 | brlcad | but the two there are the critical ones for consistent indentation |
| 03:14.10 | starseeker | nods |
| 03:14.18 | brlcad | the stylistic ones were left as an exercise to the reader :) |
| 03:14.26 | starseeker | heh |
| 03:14.33 | brlcad | continues working on rt_db_corrupt() |
| 03:16.19 | CIA-53 | BRL-CAD: 03starseeker * r42685 10/brlcad/branches/cmake/ (3 files in 3 dirs): Pick up sunmath if it's there for tcl/tk |
| 03:20.35 | starseeker | yow |
| 03:20.44 | starseeker | opennurbs and sun studio don't get along at all |
| 03:22.03 | starseeker | hah - actually, that's the same issue clang saw |
| 03:22.04 | starseeker | cool |
| 03:45.39 | *** join/#brlcad yukonbob (~bch@S0106002129e399fc.ok.shawcable.net) | |
| 03:45.42 | yukonbob | oh hai. |
| 03:46.38 | yukonbob | q: re problems w/ sed/ted in 7.18.0 (apparently fixed in 7.18.1) -- does anybody remember roughly (or better, acutely and accurately) what the fix was? |
| 04:03.05 | starseeker | needed to test for TCL_OK, as opposed to just using the return val for the if statement (IIRC) |
| 04:03.26 | starseeker | return val of editit in tedit.c I believe, but not sure |
| 04:04.10 | starseeker | yukonbob: recommend setting up gdb, breaking just before the edit is to be applied to disk (as a start) and tracing back where the failure is |
| 04:04.20 | starseeker | grrrr |
| 04:04.52 | starseeker | sun stuido gives this error: "The function "_finite" must have a prototype" |
| 04:05.00 | starseeker | what on earth... |
| 04:05.04 | yukonbob | starseeker: thanks for the clues... I was going to try to get away w/ least-invasive patch possible. |
| 04:14.55 | CIA-53 | BRL-CAD: 03starseeker * r42686 10/brlcad/branches/cmake/src/libdm/dm-rtgl.c: grab dm-rtgl ws/indent fixes |
| 04:37.40 | CIA-53 | BRL-CAD: 03starseeker * r42687 10/brlcad/branches/cmake/src/other/openNURBS/ (4 files): These are minimal 'get opennurbs compiling on sun studio' hacks - commiting them because I accidently erased one last go-around, but need cleanup and conditional wrappers |
| 04:53.11 | brlcad | starseeker: sun studio is notorious for having drastically different compilation behavior when you change standard compliance levels |
| 04:54.00 | brlcad | the default does not match gcc behavior but there is a mode that does match pretty closely iirc |
| 05:06.11 | yukonbob | sees some interesting header changes in bwish -- stripping itk.h and replacing w/ tk.h alone? |
| 05:07.46 | yukonbob | crosses fingers, configs 7.18.1 |
| 05:08.15 | *** join/#brlcad Stattrav (~Stattrav@122.172.46.55) | |
| 05:08.16 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:08.43 | yukonbob | feh -- immediate 'make' failure :P |
| 05:09.16 | yukonbob | missing rtprivate.h |
| 05:26.41 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 05:36.45 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:00.19 | *** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net) | |
| 06:00.19 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 06:00.52 | *** join/#brlcad yukonbob (~bch@S0106001cf044d085.ok.shawcable.net) | |
| 06:49.23 | yukonbob | starseeker: that TCL_OK on editit() was the problem/fix. Thx. |
| 07:15.24 | yukonbob | is there such a process as a lathe yet, like povray? |
| 07:17.17 | brlcad | yukonbob: yes, though much more general (and much less tested) :) |
| 07:17.24 | brlcad | 'revolve' primitive |
| 07:17.32 | yukonbob | brlcad: hello :) |
| 07:17.37 | brlcad | takes a 2D 'sketch' object, and an axis of rotation |
| 07:17.47 | yukonbob | how old is revolve? |
| 07:17.54 | brlcad | few years |
| 07:17.55 | yukonbob | <2years |
| 07:17.57 | yukonbob | ? |
| 07:18.08 | yukonbob | cool |
| 07:18.32 | yukonbob | brlcad: how're things? |
| 07:18.33 | brlcad | r31599 | pacman87 | 2008-06-24 13:34:05 -0400 (Tue, 24 Jun 2008) | 1 line |
| 07:18.33 | brlcad | beginning of revolve primitive, with shot() algorithm for straigh line sketches (untested) |
| 07:19.17 | yukonbob | that makes sense -- probabably ~the time I became less involved... |
| 07:19.29 | brlcad | http://brlcad.org/wiki/Revolve_Primitive |
| 07:19.43 | yukonbob | povray "lathe" operation is quite nice -- looking forward to playing w/ revolve... |
| 07:20.52 | brlcad | http://brlcad.org/tmp/revolve/ has a sample |
| 07:21.01 | yukonbob | brlcad: you see the ted bug that shipped w/ 7.18.0 :P |
| 07:21.11 | brlcad | yep |
| 07:21.16 | brlcad | what about it? |
| 07:21.42 | yukonbob | ted doesn't work :P |
| 07:21.45 | brlcad | ted isn't best practice |
| 07:21.54 | brlcad | more of a crutch |
| 07:22.03 | yukonbob | the return code is incorrectly checked, and the edits are effectively thrown away. |
| 07:22.30 | brlcad | I'm aware of what the bug is and how it was fixed -- I helped diagnose and fix when it was reported |
| 07:22.32 | yukonbob | what do the cool kids use instead of ted? |
| 07:23.09 | brlcad | it depends on the type of edit, there are different commands for different operations |
| 07:23.22 | brlcad | most of the common ones are listed on the quick ref card |
| 07:23.49 | yukonbob | will have to get to a printer and print all these again... I used to carry them with me ;) |
| 07:23.56 | brlcad | e.g., sca, rot, tra |
| 07:24.45 | yukonbob | scale, rotate, translate, sure... will those let one redefine the second radius of a torus, though? |
| 07:24.55 | brlcad | the only tricky edits are the refined parameter edits displaed on the Edit menu when you go into edit mode, but even those are selectable on the command line using the "press" command |
| 07:25.10 | yukonbob | ah |
| 07:26.24 | yukonbob | why is ted considered !Best Practice ? |
| 07:26.52 | brlcad | press "Set Radius 2" |
| 07:26.58 | brlcad | for that specific action |
| 07:27.04 | brlcad | p 10 |
| 07:27.24 | brlcad | ted basically punts on providing a user interface, kicking off a dump to a text file |
| 07:27.54 | yukonbob | so is just non-elegant, in at least one way... |
| 07:28.01 | brlcad | that's fine for some things, like diagnostics, but a really crappy and supremely error-prone way to go about things |
| 07:28.30 | brlcad | the errors it causes tend to far outweigh the warm fuzzy feeling some people get working in their favorite text editor |
| 07:28.46 | brlcad | it's a crutch |
| 07:29.03 | yukonbob | nods |
| 07:29.39 | yukonbob | anyway, is broken crutch in latest .tgz; I've got it working here, now, but will train self to use alternatives. |
| 07:34.15 | brlcad | wow, my corruption detection routine is actually working... woot! |
| 07:59.48 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 08:51.07 | CIA-53 | BRL-CAD: 03brlcad * r42688 10/brlcad/trunk/src/librt/ (Makefile.am db_corrupt.c): |
| 08:51.07 | CIA-53 | BRL-CAD: add an initial working implementation of a routine to help detect when a v4 |
| 08:51.07 | CIA-53 | BRL-CAD: geometry file seems corrupt due to endianness. this walks over all matrices of |
| 08:51.07 | CIA-53 | BRL-CAD: combinatino members and tests whether they preserve axis perpendicularity and |
| 08:51.07 | CIA-53 | BRL-CAD: that scaling/rotation elements are unitized. if a matrix fails, it flips it and |
| 08:51.08 | CIA-53 | BRL-CAD: tries again to see if flipping fixes the problem. if ALL failures were |
| 08:51.09 | CIA-53 | BRL-CAD: successfully fixed by flipping, then true is returned. |
| 09:00.12 | CIA-53 | BRL-CAD: 03brlcad * r42689 10/brlcad/trunk/include/raytrace.h: provide declaration and documentation for rt_db_flip_endian(), to be used for detecting binary-incompatible v4 geometry database files. |
| 10:38.42 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 12:18.19 | epileg | brlcad: hello. I've made the needed changes in /misc/debian folder and in sh/make_deb.sh file, to make it working. Now I've to commit |
| 13:31.05 | CIA-53 | BRL-CAD: 03starseeker * r42690 10/brlcad/branches/cmake/src/other/openNURBS/ (4 files): Wrap sun studio stuff in conditionals |
| 13:41.47 | CIA-53 | BRL-CAD: 03starseeker * r42691 10/brlcad/branches/cmake/src/other/openNURBS/ (CMakeLists.txt opennurbs_system.h): Whoops - opennurbs build isn't using the CONFIG_H_FILE at the moment, so add definitions explicitly. Perhaps this is why ieeefp.h wasn't getting picked up, so comment out the define - if this works remove it. |
| 13:44.50 | CIA-53 | BRL-CAD: 03starseeker * r42692 10/brlcad/branches/cmake/src/other/openNURBS/opennurbs_system.h: Nope, HAVE_IEEEFP_H wasn't enough |
| 14:52.45 | brlcad | epileg: okay, go for it :) |
| 14:53.13 | brlcad | you didn't have to wait until you were done, you could/can commit incrementally |
| 14:54.00 | epileg | brlcad: Do have I commit acces to trunk/sh/ folder? |
| 15:34.43 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 15:39.47 | CIA-53 | BRL-CAD: 03brlcad * r42693 10/brlcad/trunk/src/libbu/mappedfile.c: checking the wrong debug flag |
| 15:51.07 | CIA-53 | BRL-CAD: 03brlcad * r42694 10/brlcad/trunk/include/bu.h: BU_DEBUG_DB is no longer used, mark as such to free up the slot. |
| 15:52.22 | CIA-53 | BRL-CAD: 03brlcad * r42695 10/brlcad/trunk/include/raytrace.h: mark the private db_i members as such more explicitly, ws consistency migration to keep names associated with their type for db_i and directory structs. |
| 15:57.15 | CIA-53 | BRL-CAD: 03starseeker * r42696 10/brlcad/branches/cmake/src/other/CMakeLists.txt: Don't mess with jove on Windows |
| 15:59.02 | CIA-53 | BRL-CAD: 03starseeker * r42697 10/brlcad/branches/cmake/src/other/CMakeLists.txt: Say something about it instead of turning off silently |
| 16:06.35 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 16:06.59 | brlcad | epileg: the only way to know that for sure is to try, right? |
| 16:07.12 | epileg | right :-) |
| 16:07.40 | epileg | about the commit comment. some rule to follow? |
| 16:08.09 | brlcad | sure, make it something useful to the other developers and to yourself 5 years from now |
| 16:09.01 | brlcad | briefly describing what *and* why/impact/reasoning |
| 16:22.02 | CIA-53 | BRL-CAD: 03starseeker * r42698 10/brlcad/branches/cmake/src/bwish/CMakeLists.txt: tweak bwish build logic |
| 16:24.13 | CIA-53 | BRL-CAD: 03brlcad * r42699 10/brlcad/trunk/src/librt/namegen.c: lots of dead code, mostly dead code |
| 16:26.43 | CIA-53 | BRL-CAD: 03brlcad * r42700 10/brlcad/trunk/src/librt/db5_scan.c: |
| 16:26.43 | CIA-53 | BRL-CAD: change db_dirbuild() to no longer directly check the file header and calculate |
| 16:26.43 | CIA-53 | BRL-CAD: the version. let db_version() be the (only) place that happens. should reduce |
| 16:26.43 | CIA-53 | BRL-CAD: a few petty file i/o operations but more importantly avoid overriding |
| 16:26.44 | CIA-53 | BRL-CAD: dbi_version since it needs to be negative for flipped v4 files. |
| 16:28.19 | CIA-53 | BRL-CAD: 03brlcad * r42701 10/brlcad/trunk/ (3 files in 2 dirs): enable db_corrupt for librt compilation |
| 16:31.31 | CIA-53 | BRL-CAD: 03brlcad * r42702 10/brlcad/trunk/src/librt/db5_scan.c: right, 'header' is no longer used. |
| 16:37.11 | CIA-53 | BRL-CAD: 03starseeker * r42703 10/brlcad/branches/cmake/ (10 files in 10 dirs): Add version number logic for some of the src/other libs |
| 16:47.31 | CIA-53 | BRL-CAD: 03brlcad * r42704 10/brlcad/trunk/src/fbserv/fbserv.c: return from main instead of exiting |
| 16:49.20 | CIA-53 | BRL-CAD: 03brlcad * r42705 10/brlcad/trunk/src/other/tnt/tnt_fortran_array3d.h: quell warning about having no space on the empty for loop before the semicolon. |
| 17:09.51 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 18:21.39 | CIA-53 | BRL-CAD: 03starseeker * r42706 10/brlcad/branches/cmake/src/other/ (tcl/CMakeLists.txt tk/CMakeLists.txt): Hmm endian test isn't happy with VC2010 |
| 18:27.59 | CIA-53 | BRL-CAD: 03starseeker * r42707 10/brlcad/branches/cmake/src/other/incrTcl/ (itcl/CMakeLists.txt itk/CMakeLists.txt): itcl/itk too |
| 18:28.30 | CIA-53 | BRL-CAD: 03erikgreenwald * r42708 10/brlcad/branches/cmake/src/libpc/CMakeLists.txt: add TCL_INCLUDE_DIRS to make bu.h happy |
| 18:36.05 | CIA-53 | BRL-CAD: 03starseeker * r42709 10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: Hmm - was this the issue with the endian test? |
| 18:47.04 | starseeker | hmm. nope |
| 18:47.10 | starseeker | does fix another problem though |
| 18:48.09 | starseeker | sees other indications that TestBigEndian may be quirky with VC2010... well, not likely to be needed anyhow with MSVC |
| 19:18.20 | CIA-53 | BRL-CAD: 03starseeker * r42710 10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: More flag tweaking... |
| 19:55.49 | CIA-53 | BRL-CAD: 03starseeker * r42711 10/brlcad/branches/cmake/misc/CMake/test_srcs/report_username.c.in: Tweak WIN32 conditional define to _WIN32 |
| 20:06.53 | CIA-53 | BRL-CAD: 03bob1961 * r42712 10/brlcad/trunk/ (include/tclcad.h src/libtclcad/ged_obj.c): Added a callback for when the view changes to libtclcad. |
| 20:13.13 | CIA-53 | BRL-CAD: 03starseeker * r42713 10/brlcad/branches/cmake/src/other/step/ (11 files in 6 dirs): Simplify the SCL CMake logic, grab some of the updates from newer BRL-CAD logic |
| 20:14.43 | CIA-53 | BRL-CAD: 03bob1961 * r42714 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Added methods to expose libtclcad's view_callback function. |
| 20:18.38 | CIA-53 | BRL-CAD: 03starseeker * r42715 10/brlcad/branches/cmake/include/config_win_cmake.h: This is defined in newer MSVC compilers - conditionalize to quell warnings |
| 20:29.05 | CIA-53 | BRL-CAD: 03starseeker * r42716 10/brlcad/trunk/src/libbu/backtrace.c: Let's not do the assignment in the if statement - quell MSVC warning |
| 20:29.38 | CIA-53 | BRL-CAD: 03starseeker * r42717 10/brlcad/trunk/src/libbu/backtrace.c: typo |
| 20:32.20 | CIA-53 | BRL-CAD: 03brlcad * r42718 10/brlcad/trunk/src/tclscripts/mged/text.tcl: can't just directly call 'bind' since procedures might be called without ::tk:: namespace loaded. catch any error. |
| 20:34.11 | CIA-53 | BRL-CAD: 03brlcad * r42719 10/brlcad/trunk/src/tclscripts/mged/dbupgrade.tcl: make dbupgrade work once again in classic console mode where there is no ::tk |
| 20:36.10 | CIA-53 | BRL-CAD: 03starseeker * r42720 10/brlcad/branches/cmake/src/other/CMakeLists.txt: try adding xlib to TCL_INCLUDE_DIRS (untested) |
| 20:38.19 | CIA-53 | BRL-CAD: 03starseeker * r42721 10/brlcad/branches/cmake/src/other/CMakeLists.txt: typo |
| 20:44.52 | CIA-53 | BRL-CAD: 03bob1961 * r42722 10/brlcad/trunk/src/tclscripts/archer/CombEditFrame.tcl: Fixed CombEditFrame::updateGeometry. It's now able to turn off inherit. |
| 20:52.06 | CIA-53 | BRL-CAD: 03brlcad * r42723 10/brlcad/trunk/src/conv/asc/g2asc.c: check ==0 instead of ==DB5_MINORTYPE_RESERVED since the value may change. zero suffices for unset. |
| 20:53.03 | CIA-53 | BRL-CAD: 03brlcad * r42724 10/brlcad/trunk/src/conv/dbupgrade.c: |
| 20:53.04 | CIA-53 | BRL-CAD: dbupgrade with a coredump flag makes the automatic endianness flip test fail |
| 20:53.04 | CIA-53 | BRL-CAD: since low-level libbn routines will bomb if they encounter a bad matrix. |
| 20:53.04 | CIA-53 | BRL-CAD: instead of bombing, let them return their error so we upgrade cleanly. |
| 20:53.43 | CIA-53 | BRL-CAD: 03brlcad * r42725 10/brlcad/trunk/src/tclscripts/mged/help.tcl: improve help, dbupgrade will begin processing if it's followed by 'upgrade' |
| 21:00.48 | CIA-53 | BRL-CAD: 03brlcad * r42726 10/brlcad/trunk/src/tclscripts/mged/help.tcl: list all three upgrade commands |
| 21:01.38 | CIA-53 | BRL-CAD: 03brlcad * r42727 10/brlcad/trunk/src/tclscripts/mged/dbupgrade.tcl: display the entire detailed help if the user requests help. 'help dbupgrade' will still just report a brief usage message. |
| 21:03.17 | CIA-53 | BRL-CAD: 03jordisayol * r42728 10/brlcad/trunk/ (31 files in 2 dirs): Upgraded the debian package build proccess. Added mged, archer, rtwizard, documentation and examples menus. Added brlcad mime type. Added brlcad mime file association. |
| 21:09.13 | CIA-53 | BRL-CAD: 03starseeker * r42729 10/brlcad/branches/cmake/src/ (CMakeLists.txt irprep/subroutines.c other/CMakeLists.txt): more Windows stuff... |
| 21:10.44 | CIA-53 | BRL-CAD: 03brlcad * r42730 10/brlcad/trunk/src/tclscripts/mged/dbupgrade.tcl: support all variations of 'yes' and inform the user that upgrade was cancelled and database is being reopened. this way, if it's a corrupt database, the warning makes sense. |
| 21:10.56 | brlcad | epileg: congratulations :) |
| 21:11.06 | epileg | thanks brlcad |
| 21:11.29 | epileg | but it do not compile on trunk |
| 21:11.46 | epileg | in 7.18.0 compile without problem |
| 21:12.30 | brlcad | you have to be way more specific for that to mean anything |
| 21:13.06 | epileg | ok, just a moment |
| 21:13.12 | brlcad | there are dozens or even hundreds of commits nearly every day, and they won't all work -- that's the nature of working on trunk |
| 21:14.08 | brlcad | first step is to always check and see if there's an update, read the recent commits from in here to see if the commit message says anything about breaking things |
| 21:15.02 | brlcad | then just read the failure to see what happened, because 90% of the time, it's a very simple syntax mistake that can be easily fixed by anyone |
| 21:15.38 | brlcad | then, if you can't make sense of the error, you can paste your build log somewhere and ask for help in here :) |
| 21:17.20 | brlcad | epileg: you also need to update misc/Makefile.am to list all of the file changes you made |
| 21:17.30 | brlcad | additions and deletions |
| 21:17.34 | brlcad | it's a simple list |
| 21:17.53 | epileg | ok, I'll do right now |
| 21:21.33 | CIA-53 | BRL-CAD: 03brlcad * r42731 10/brlcad/trunk/src/librt/db_open.c: |
| 21:21.33 | CIA-53 | BRL-CAD: enable automatic flipping of a binary-incompatible v4 geometry database if |
| 21:21.33 | CIA-53 | BRL-CAD: rt_db_flip_endian() returns true. this should only occur if flipping the |
| 21:21.33 | CIA-53 | BRL-CAD: database was observed to fix ALL matrix member failures during a quick db_open() |
| 21:21.33 | CIA-53 | BRL-CAD: scan of the file. the user should be able to force flipped values in mged with |
| 21:21.34 | CIA-53 | BRL-CAD: 'opendb -f'. |
| 21:26.33 | brlcad | epileg: you can check a build's suitability for distribution, particularly whether you missed any files, with "make distcheck" |
| 21:28.16 | epileg | ok |
| 21:28.55 | epileg | now i'm modifying misc/Makefile.am |
| 21:29.35 | brlcad | cool |
| 21:31.14 | brlcad | epileg: can you describe what all the changes were -- new menus, mime type file association, desktop icons, ... anything else? |
| 21:33.33 | epileg | brlcad: where i've to describe this? |
| 21:34.04 | brlcad | heh, here -- just asking for general info |
| 21:34.11 | epileg | ah |
| 21:34.32 | CIA-53 | BRL-CAD: 03starseeker * r42732 10/brlcad/branches/cmake/misc/CMakeLists.txt: whoopsie - to run in the build dir, need archer.ico in the build dir... |
| 21:36.10 | epileg | configure was changed from shared to build-in libraries |
| 21:37.20 | epileg | changed --prefix from /usr/ to /usr/brlcad/ |
| 21:39.06 | CIA-53 | BRL-CAD: 03starseeker * r42733 10/brlcad/branches/cmake/TODO.cmake: Update TODO.cmake |
| 21:39.06 | brlcad | anything else? |
| 21:43.56 | CIA-53 | BRL-CAD: 03brlcad * r42734 10/brlcad/trunk/AUTHORS: add epileg's aliases |
| 21:47.28 | *** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net) | |
| 21:47.28 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 21:50.24 | CIA-53 | BRL-CAD: 03brlcad * r42735 10/brlcad/trunk/NEWS: |
| 21:50.24 | CIA-53 | BRL-CAD: extensive work for the debian platform by jordi sayol (epileg). there are new |
| 21:50.24 | CIA-53 | BRL-CAD: application menus, icons, mime-type associations, and other usability essentials |
| 21:50.24 | CIA-53 | BRL-CAD: for a self-contained .deb installer. this should make it easier for a platform |
| 21:50.24 | CIA-53 | BRL-CAD: maintainer to publish .deb files on a more regular basis. |
| 21:58.18 | CIA-53 | BRL-CAD: 03brlcad * r42736 10/brlcad/trunk/NEWS: |
| 21:58.18 | CIA-53 | BRL-CAD: you can now run 'ls -la' on a v4 database and have it properly report primitive |
| 21:58.18 | CIA-53 | BRL-CAD: types. it was reporting NULL and even potential crash-inducing garbage due to |
| 21:58.18 | CIA-53 | BRL-CAD: directly indexing into the rt_functab based on an unset d_minor_type. |
| 21:59.09 | CIA-53 | BRL-CAD: 03erikgreenwald * r42737 10/brlcad/branches/bottie/src/librt/primitives/bot/ (bot.c btg.c btg.h btgf.c tie.c tie_kdtree.c): warning quellage |
| 22:20.08 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 22:22.16 | CIA-53 | BRL-CAD: 03jordisayol * r42738 10/brlcad/trunk/misc/Makefile.am: Updated debian/ files list |
| 22:22.53 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 22:25.29 | CIA-53 | BRL-CAD: 03brlcad * r42739 10/brlcad/trunk/NEWS: |
| 22:25.29 | CIA-53 | BRL-CAD: mged's opendb command now has a -f flip option for reading in a |
| 22:25.29 | CIA-53 | BRL-CAD: binary-incompatible v4 geometry database with a flipped endianness translation. |
| 22:25.29 | CIA-53 | BRL-CAD: the files are made read-only but may then be run through keep or dbupgrade to |
| 22:25.29 | CIA-53 | BRL-CAD: clean them up. this closes out a long-standing request from users and a class |
| 22:25.30 | CIA-53 | BRL-CAD: of modeling/rendering failures due to the platform-specific nature of v4 files, |
| 22:25.31 | CIA-53 | BRL-CAD: albeit only minimally tested with a few sample files. |
| 22:27.45 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 22:27.45 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.0 is posted (20101209) || Happy Open Source Anniversary 2010-12-21 !!! Six years... | |
| 22:29.07 | CIA-53 | BRL-CAD: 03starseeker * r42740 10/brlcad/branches/cmake/src/other/tk/CMakeLists.txt: Doesn't look like winMain.c belongs in libtk, but that's not the only issue. |
| 22:29.23 | CIA-53 | BRL-CAD: 03brlcad * r42741 10/brlcad/trunk/NEWS: (log message trimmed) |
| 22:29.23 | CIA-53 | BRL-CAD: dbupgrade (along with ALL other BRL-CAD commands) now supports reading in |
| 22:29.23 | CIA-53 | BRL-CAD: binary-incompatible v4 files. the low-level librt db_open() inteface for |
| 22:29.23 | CIA-53 | BRL-CAD: reading in files will now auto-convert a v4 file to an alternate endian format |
| 22:29.24 | CIA-53 | BRL-CAD: if it finds that flipping all combination member matrices makes them valid. for |
| 22:29.24 | CIA-53 | BRL-CAD: safety, that means if an old v4 has even one actual bad matrix (so that it's |
| 22:29.25 | CIA-53 | BRL-CAD: invalid regardless of being flipped), then the dbupgrade cannot be performed |
| 22:46.23 | CIA-53 | BRL-CAD: 03brlcad * r42742 10/brlcad/trunk/misc/Makefile.am: M-x sort-lines |
| 22:46.53 | epileg | ops, sorry |
| 22:47.01 | brlcad | no problem |
| 22:51.04 | CIA-53 | BRL-CAD: 03brlcad * r42743 10/brlcad/trunk/TODO: dbupgrade support is done |
| 22:53.39 | CIA-53 | BRL-CAD: 03brlcad * r42744 10/brlcad/trunk/src/tclscripts/mged/help.tcl: document the new -f option to opendb |
| 23:02.47 | CIA-53 | BRL-CAD: 03brlcad * r42745 10/brlcad/trunk/doc/docbook/system/mann/en/opendb.xml: document the opendb -f option |
| 23:11.05 | CIA-53 | BRL-CAD: 03r_weiss * r42746 10/brlcad/trunk/src/libbn/bntester.c: Added to 'bntester' support for testing function 'bn_isect_line3_line3'. |
| 23:15.18 | CIA-53 | BRL-CAD: 03brlcad * r42747 10/brlcad/trunk/include/ged.h: |
| 23:15.18 | CIA-53 | BRL-CAD: refactor principle of DRY -- Don't Repeat Yourself. user usage statements don't |
| 23:15.18 | CIA-53 | BRL-CAD: belong in the public header regardless, but they're also already listed in the |
| 23:15.18 | CIA-53 | BRL-CAD: manual pages and src/tclscripts/mged/help.tcl and the bastard replications for |
| 23:15.18 | CIA-53 | BRL-CAD: archer and rtwizard (Db.tcl and Ged.tcl). approx 700 line reduction. |
| 23:15.18 | CIA-53 | BRL-CAD: ultimately, usage should be defined in the source C file directly in src/libged |
| 23:17.33 | brlcad | hm, distcheck does not like the misc/debian/brlcad-db.png symbolic link |
| 23:18.48 | epileg | is this a problem? |
| 23:19.05 | epileg | well, I can make a copy of the png |
| 23:22.40 | ``Erik | some os's don't support symlinks, can it cp when running the makedeb script shtuff? |
| 23:26.07 | brlcad | epileg: yeah, a copy would be better |
| 23:26.35 | CIA-53 | BRL-CAD: 03jordisayol * r42748 10/brlcad/trunk/misc/debian/ (brlcad-db.png brlcad-db.png): |
| 23:27.02 | brlcad | should always have *some* comment message, at least say why :) |
| 23:27.30 | epileg | ok. sorry |
| 23:28.33 | brlcad | could have been "copy instead of symlink" or "distcheck hates symlinks or even "sean complained so make a copy" .. all fine :) |
| 23:29.13 | brlcad | i.e., what would be useful to someone looking at that change years from now when the reason is no longer obvious |
| 23:30.06 | *** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.0 is posted (20101209) || http://itmanagement.earthweb.com/osrc/article.php/3922041/50-Open-Source-Applications-for-Sci-Tech-Education.htm | |
| 23:54.54 | Ralith | I'll be needing to do inward polygon+arc offsetting in the gcode generator; a bit of research has pointed me towards M. Held. "On the Computational Geometry of Pocket Machining", LNCS500, Springer-Verlag, 1991, which "uses a Voronoi Diagram (VD) to produce rounded or constant-radius offset curves." I can get a copy of this at my univ library. Sound like I'm on the right track? |
| 23:55.13 | Ralith | ... which describes how to use "..., rather |
| 00:05.35 | epileg | brlcad: here is the problem: |
| 00:05.36 | epileg | backtrace.c:313: error: ‘else’ without a previous ‘if’ |
| 01:05.57 | brlcad | hm, I have no else on backtrace.c:313 |
| 01:12.02 | starseeker | brlcad: oh, that's me |
| 01:39.58 | starseeker | what the bleep... sf password issue |
| 01:45.21 | starseeker | I can't fix it - my password is being rejected |
| 01:51.35 | starseeker | brlcad: can you commit? |
| 01:52.02 | starseeker | tried to reset my password - can reach the website but the commits still fail |
| 02:03.22 | starseeker | well, here's the diff anyway... http://paste.lisp.org/display/119160 |
| 04:03.38 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 04:03.44 | starseeker | ``Erik: around? |
| 05:50.22 | *** join/#brlcad yukonbob (~bch@S0106002129e399fc.ok.shawcable.net) | |
| 05:50.24 | yukonbob | oh hai |
| 05:51.33 | yukonbob | I've got a 101 question: I want a "tool" that I use later in CSG operations. How do I create this tool itself? I can create it, but when I try to clone/tra it, I'm told it's not a solid. |
| 05:52.07 | yukonbob | I tried combinations and regions, no dice. |
| 06:02.15 | brlcad | starseeker: there's exactly the indentation problem I was commenting on yesterday -- fortunately the logic was actually invalid this time, but had it not been invalid that would have been a superbly obscure bug injection |
| 06:02.27 | brlcad | (in backtrace.c) |
| 06:02.34 | brlcad | should fix your indentation |
| 06:16.08 | brlcad | that said, the login problems are site-wide -- sf reset all passwords and an updated password will take a while to propagate |
| 06:17.42 | brlcad | yukonbob: if you post the exact steps you're trying, it'll be easier to help but I suspect that you're not using the 'oed' command correctly (sed only works with primitives) |
| 06:17.59 | brlcad | there's an extensive tutorial on oed on the website that starseeker wrote up a while back |
| 06:18.02 | brlcad | good reading |
| 06:20.35 | yukonbob | has that oed... |
| 06:20.40 | yukonbob | *oed manual |
| 06:21.07 | yukonbob | and Chapter II, and quick ref (which happened to have printed out in complete gibberish for me, except for imagages) |
| 06:21.27 | yukonbob | ... but what I'm doing: |
| 06:21.59 | yukonbob | I want a bar (arb8, like a popsicle stick), but with rounded ends. |
| 06:22.30 | yukonbob | so I create another arb8, and difference it w/ an rcc., |
| 06:23.33 | yukonbob | then I think: ok - I want two copies of this, and I want one rotated on X axix 180 degrees. |
| 06:23.49 | yukonbob | now.. is this something I ought to be doing w/ oed? |
| 06:24.15 | yukonbob | I can't "sed" the obj (wrong type) |
| 06:25.14 | yukonbob | ultimately, I think I want to rot one, tra both, difference them w/ end of "popsicle stick" and have that popsicle be a nice bar w/ rounded ends. |
| 06:25.23 | yukonbob | hits oed... |
| 06:25.57 | yukonbob | the tool I have could be as such: |
| 06:26.07 | yukonbob | make circ rcc |
| 06:26.13 | yukonbob | make box arb8 |
| 06:26.22 | yukonbob | [make sure geometry/orientation are good] |
| 06:26.39 | yukonbob | c cutter box - circ |
| 06:27.32 | yukonbob | now I want to select "cutter" and apply tra, then: c nicerStick stick - cutter |
| 06:38.19 | yukonbob | yay, oed. |
| 06:38.20 | yukonbob | ...though, I need to get some oed-fu together to make my regions behave atomically |
| 06:45.45 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:14.35 | *** join/#brlcad bch_ (~bch@S0106001cf044d085.ok.shawcable.net) | |
| 07:49.33 | *** join/#brlcad yukonbob (~bch@S0106001cf044d085.ok.shawcable.net) | |
| 08:00.09 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 09:01.11 | yukonbob | oed, I'm getting to know you again... |
| 10:35.30 | *** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ) | |
| 11:53.29 | *** join/#brlcad Stattrav (~Stattrav@122.172.33.253) | |
| 11:53.34 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:15.28 | CIA-53 | BRL-CAD: 03jordisayol * r42749 10/brlcad/trunk/misc/debian/changelog: update debian changelog |
| 14:00.22 | CIA-53 | BRL-CAD: 03starseeker * r42750 10/brlcad/trunk/src/libbu/backtrace.c: Whoops, compile then commit - fix if/else logic |
| 14:01.43 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 14:02.48 | starseeker | brlcad: heh, actually I had the modeline activated on my home box but forgot to add it at work |
| 14:02.59 | starseeker | will get it monday |
| 14:06.13 | CIA-53 | BRL-CAD: 03starseeker * r42751 10/brlcad/branches/cmake/ (CMakeLists.txt src/other/step/CMakeLists.txt): One the path is non-default, make sure the default test fails subsequently, even in the same CMake run (in case a subproject sets it in the default case, like step) |
| 15:18.28 | CIA-53 | BRL-CAD: 03starseeker * r42752 10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: Tweak the flags, add comments - don't include -w, misses the whole point |
| 15:30.12 | starseeker | brlcad: looking at the comments for your gstabs+/ggdb3 logic, the comment suggests 10.4 and less would go with gdb3 but the logic seems to use gstabs+ for lower versions and ggdb3 for higher? |
| 15:31.06 | brlcad | it's hard to keep them straight |
| 15:31.56 | brlcad | iirc, I verified that gstabs+ worked with 10.4 |
| 15:32.14 | brlcad | implying gstabs+ should work for 10.[43210] |
| 15:32.40 | brlcad | haven't tested as carefully what 10.5 and 10.6 want |
| 15:32.53 | CIA-53 | BRL-CAD: 03starseeker * r42753 10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: Untested - try to duplicate configure.ac version based check for correct mac debug flag |
| 15:33.41 | brlcad | moreover, I'm pretty sure 10.6 isn't happy with -ggdb3 .. :) |
| 15:33.52 | starseeker | auugh |
| 15:34.24 | starseeker | nods - not a big deal, I'll have to test that logic on monday anyway when I have a mac, so I imagine I'll find out then |
| 15:34.45 | starseeker | what does the -W flag do without any argument? |
| 15:35.02 | starseeker | is trying to find it in the gcc docs, but not having much luck yet |
| 15:44.14 | ``Erik | additional warnings |
| 15:44.53 | ``Erik | um, it looks like the proper name for it is now -Wextra |
| 15:44.57 | ``Erik | http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html |
| 15:47.54 | starseeker | ah, that makes sense |
| 15:47.57 | starseeker | adds Wextra |
| 15:49.19 | CIA-53 | BRL-CAD: 03starseeker * r42754 10/brlcad/branches/cmake/misc/CMake/ (BRLCAD_Util.cmake CompilerFlags.cmake): Add Wextra to warning and strict flags |
| 16:17.51 | CIA-53 | BRL-CAD: 03starseeker * r42755 10/brlcad/branches/cmake/ (29 files in 29 dirs): There we go - optionally turn off warnings for src/other globally (on by default) and add lots of strict flags |
| 16:18.23 | brlcad | cool |
| 16:18.42 | starseeker | yep, that's got it - itcl is quiet and librt fails :-P |
| 16:20.04 | CIA-53 | BRL-CAD: 03starseeker * r42756 10/brlcad/branches/cmake/misc/CMake/BRLCAD_Util.cmake: whoops, remove debug printing |
| 16:21.06 | starseeker | yow src/sig and libpc got noisy |
| 16:50.01 | CIA-53 | BRL-CAD: 03starseeker * r42757 10/brlcad/branches/cmake/ (7 files in 4 dirs): Get librt building with strict, but need to check some of the changes with Keith - particularly vdot in opennurbs_ext.cpp - before merging into trunk |
| 17:29.55 | CIA-53 | BRL-CAD: 03starseeker * r42758 10/brlcad/branches/cmake/ (8 files in 8 dirs): |
| 17:29.55 | CIA-53 | BRL-CAD: Getting too cute for my own good - OK to copy the headers in order to duplicate |
| 17:29.55 | CIA-53 | BRL-CAD: the install dir, but don't use them to compile BRL-CAD itself - if you want to |
| 17:29.55 | CIA-53 | BRL-CAD: edit a header, the error message should report the location of the copy that |
| 17:29.55 | CIA-53 | BRL-CAD: will be edited and checked into subversion, not the build-dir copy. |
| 17:30.47 | CIA-53 | BRL-CAD: 03starseeker * r42759 10/brlcad/branches/cmake/src/other/jove/CMakeLists.txt: Point jove to the source dir |
| 17:41.13 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 19:08.28 | *** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net) | |
| 19:08.37 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 19:29.07 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 20:21.02 | *** join/#brlcad yukonbob (~bch@d207-6-21-57.bchsia.telus.net) | |
| 20:21.07 | yukonbob | :) |
| 22:00.35 | CIA-53 | BRL-CAD: 03jordisayol * r42760 10/brlcad/trunk/misc/debian/ (5 files): updated debian menu desktop files |
| 22:08.34 | CIA-53 | BRL-CAD: 03jordisayol * r42761 10/brlcad/trunk/sh/make_deb.sh: more accurate tests in debian changelog and menu desktop files |
| 00:46.21 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) | |
| 01:28.19 | CIA-53 | BRL-CAD: 03starseeker * r42762 10/brlcad/branches/cmake/ (62 files in 19 dirs): Update cmake branch to trunk r42761 |
| 01:53.12 | CIA-53 | BRL-CAD: 03johnranderson * r42763 10/brlcad/trunk/src/conv/asc/asc2g.c: Yet another size_t issue. This time just changed the declaration of to temporary variabes from size_t to unsigned long. |
| 02:07.01 | ``Erik | interesting exercise video: http://www.youtube.com/watch?v=b_KHh_c6Ha4 |
| 02:34.00 | CIA-53 | BRL-CAD: 03brlcad * r42764 10/brlcad/trunk/misc/debian/ (5 files): change mime-type to text/plain so that diff history can be reviewed. |
| 03:32.06 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 03:42.57 | CIA-53 | BRL-CAD: 03starseeker * r42765 10/brlcad/trunk/doc/docbook/resources/standard/xsl/ (428 files in 21 dirs): Update docbook-xsl to version 1.76.1 |
| 04:18.20 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 06:11.12 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) | |
| 12:36.07 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 15:48.44 | CIA-53 | BRL-CAD: 03starseeker * r42766 10/brlcad/trunk/doc/docbook/resources/standard/xsl/ (284 files in 16 dirs): Switch to xsl-ns - had to use dos2unix to avoid inconsistent line ending failures |
| 15:51.33 | CIA-53 | BRL-CAD: 03starseeker * r42767 10/brlcad/trunk/doc/docbook/ (298 files in 12 dirs): (log message trimmed) |
| 15:51.33 | CIA-53 | BRL-CAD: Take the plunge... Docbook 4.5 is getting old and development efforts in the |
| 15:51.33 | CIA-53 | BRL-CAD: Docbook community have shifted to 5.0, which came out in Feb 2008. Updated |
| 15:51.33 | CIA-53 | BRL-CAD: docbook-xsl to docbook-xsl-ns (same version, 1.76.1) and convert xml files to |
| 15:51.33 | CIA-53 | BRL-CAD: Docbook 5. The local copy of the dtd does not appear to be needed any longer. |
| 15:51.33 | CIA-53 | BRL-CAD: Note that the conversion to Docbook 5 was done automatically using the upgrade |
| 15:51.34 | CIA-53 | BRL-CAD: tool, so review will be needed - the 'Converted by db4-upgrade' comment has been |
| 16:30.03 | CIA-53 | BRL-CAD: 03starseeker * r42768 10/brlcad/branches/cmake/ (815 files in 38 dirs): Update cmake branch to trunk r42767, fix docbook CMake logic for new setup. |
| 17:05.51 | CIA-53 | BRL-CAD: 03starseeker * r42769 10/brlcad/trunk/doc/docbook/system/man1/mged_cmd_template.xml: Update template |
| 17:07.29 | CIA-53 | BRL-CAD: 03starseeker * r42770 10/brlcad/trunk/doc/docbook/ (4 files in 4 dirs): Move the template |
| 18:10.53 | CIA-53 | BRL-CAD: 03starseeker * r42771 10/brlcad/branches/cmake/doc/docbook/ (4 files in 4 dirs): Update and move template |
| 18:14.07 | CIA-53 | BRL-CAD: 03starseeker * r42772 10/brlcad/trunk/doc/docbook/system/ (245 files in 4 dirs): Use info section to handle authors |
| 18:17.44 | CIA-53 | BRL-CAD: 03starseeker * r42773 10/brlcad/branches/cmake/doc/docbook/system/ (245 files in 4 dirs): Sync cmake branch to trunk r42772 |
| 18:24.18 | CIA-53 | BRL-CAD: 03starseeker * r42774 10/brlcad/branches/cmake/doc/docbook/CMakeLists.txt: Ah hah - to have the custom command go out of date when a file is updated, make the command depend on the source file explicitly |
| 19:15.28 | CIA-53 | BRL-CAD: 03starseeker * r42775 10/brlcad/branches/cmake/src/tclscripts/ampi.tcl: Verbose output from this script is quite annoying - don't be verbose by default, perhaps it can be made a setting later or redirected to a log file... |
| 19:26.34 | *** join/#brlcad yukonbob (~bch@d207-6-21-57.bchsia.telus.net) | |
| 19:46.35 | CIA-53 | BRL-CAD: 03starseeker * r42776 10/brlcad/branches/cmake/ (4 files in 4 dirs): Add a few more dependencies on source files to custom commands |
| 19:49.54 | CIA-53 | BRL-CAD: 03starseeker * r42777 10/brlcad/branches/cmake/src/tclscripts/ (17 files in 17 dirs): (log message trimmed) |
| 19:49.55 | CIA-53 | BRL-CAD: This results in a bit of a proliferation of build targets, but make all of the |
| 19:49.55 | CIA-53 | BRL-CAD: tclscripts and data part of the actual build logic. The effect of this should |
| 19:49.55 | CIA-53 | BRL-CAD: be to allow the developer to edit the tcl script in the source dir, type 'make' |
| 19:49.55 | CIA-53 | BRL-CAD: in the build dir, and have the build dir copy use the updated tclscript without |
| 19:49.55 | CIA-53 | BRL-CAD: any manual copying or running of CMake. In principle, this should be done for |
| 19:49.56 | CIA-53 | BRL-CAD: all data in the build dir - it's less likely to be seen on less frequently |
| 20:00.39 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 20:19.30 | CIA-53 | BRL-CAD: 03starseeker * r42778 10/brlcad/branches/cmake/doc/docbook/ (10 files in 10 dirs): Add CMakeLists.txt files to the various docbook directories that contain subdirectories, so make will do something in them |
| 20:34.56 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 20:39.00 | CIA-53 | BRL-CAD: 03starseeker * r42779 10/brlcad/branches/cmake/ (misc/CMake/BRLCAD_Util.cmake src/nirt/CMakeLists.txt): Using the technique from tclscripts, make a generic macro for BRL-CAD. Use it for nirt - may just replace the tclscripts version altogether |
| 23:30.46 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) | |
| 00:43.31 | CIA-53 | BRL-CAD: 03starseeker * r42780 10/brlcad/branches/cmake/src/tclscripts/ (17 files in 17 dirs): Switch to using BRLCAD_ADDDATA in tclscripts |
| 00:52.36 | CIA-53 | BRL-CAD: 03starseeker * r42781 10/brlcad/branches/cmake/src/archer/CMakeLists.txt: Few more uses of BRLCAD_ADDDATA - really need to make the plugins less sprawling in directory layout |
| 01:03.20 | CIA-53 | BRL-CAD: 03starseeker * r42782 10/brlcad/branches/cmake/ (misc/CMake/BRLCAD_Util.cmake src/archer/CMakeLists.txt): BRLCAD_ADDFILE for single files |
| 01:29.54 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) | |
| 01:52.42 | CIA-53 | BRL-CAD: 03starseeker * r42783 10/brlcad/branches/cmake/ (17 files in 17 dirs): (log message trimmed) |
| 01:52.42 | CIA-53 | BRL-CAD: Get a little more sophisticated. Still do the FILE(COPY up front, which is much |
| 01:52.42 | CIA-53 | BRL-CAD: quicker and doesn't slow the build down, but allow the user to optionally enable |
| 01:52.42 | CIA-53 | BRL-CAD: the data target generation, which will add the data and documentation files to |
| 01:52.42 | CIA-53 | BRL-CAD: the make logic at the expense of a large increase in make targets (and |
| 01:52.43 | CIA-53 | BRL-CAD: corresponding build slowdown). The initial build will still copy all the files |
| 01:52.44 | CIA-53 | BRL-CAD: even with the FILE(COPY if the targets are on, since the timestamps will be |
| 02:23.04 | *** join/#brlcad ibot (ibot@rikers.org) | |
| 02:23.05 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.0 is posted (20101209) || http://itmanagement.earthweb.com/osrc/article.php/3922041/50-Open-Source-Applications-for-Sci-Tech-Education.htm | |
| 02:25.31 | CIA-53 | BRL-CAD: 03starseeker * r42784 10/brlcad/branches/cmake/ (CMakeLists.txt misc/CMakeLists.txt misc/Doxyfile.in): Take a quick stab at adding Doxygen build logic. |
| 02:26.14 | CIA-53 | BRL-CAD: 03starseeker * r42785 10/brlcad/branches/cmake/TODO.cmake: update CMake TODO |
| 02:26.23 | starseeker | brlcad: have you had a chance to try the CMake build yet? |
| 02:27.27 | starseeker | seems to be behaving pretty well here |
| 02:33.51 | CIA-53 | BRL-CAD: 03starseeker * r42786 10/brlcad/branches/cmake/ (CMakeLists.txt misc/CMakeLists.txt): Don't need an option for doxygen - just don't make it part of the ALL target. |
| 02:40.54 | CIA-53 | BRL-CAD: 03starseeker * r42787 10/brlcad/branches/cmake/src/other/CMakeLists.txt: Will eventually need to handle step better, but no need right now and these vars are just garbage. |
| 03:01.40 | CIA-53 | BRL-CAD: 03starseeker * r42788 10/brlcad/branches/cmake/ (5 files in 3 dirs): Start cleaning up - mark some things as advanced so they don't show in the default view, more to go |
| 03:02.06 | brlcad | starseeker: nope, not yet |
| 03:02.39 | brlcad | BRLCAD_ADDDATA? |
| 03:03.02 | starseeker | substitutes for a bunch of file copy and install commands |
| 03:04.17 | starseeker | I suppose it could be BRLCAD_ADD_DATA if that looks better |
| 03:05.19 | starseeker | hunts dinner |
| 03:05.48 | brlcad | oh, cmake macro |
| 03:06.24 | brlcad | that's fine, was thinking it was new code logic |
| 03:06.29 | brlcad | like BRLCAD_DATA |
| 03:06.33 | starseeker | ah, nope |
| 03:07.12 | starseeker | blegh, lots of advanced markings to do on the src/other variables |
| 03:07.37 | brlcad | I've been sorting through tons of computer and electrical equipment this weekend, exhausting |
| 03:07.52 | starseeker | nods - that's some heavy crap |
| 03:07.57 | brlcad | weeking out old stuff I don't need, trying to get under a half dozen 'puters :) |
| 03:08.03 | starseeker | hehe |
| 03:08.20 | starseeker | needs to find a good home for his old sun ultra1 boxes - never did get them running |
| 03:08.32 | brlcad | not going to happen if I count laptops, but desktops should hit the mark |
| 03:08.45 | starseeker | hehe - laptops are easy to store/hide |
| 03:09.12 | starseeker | heads to Applebees for a salad... bbl |
| 03:26.28 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 05:18.08 | CIA-53 | BRL-CAD: 03starseeker * r42789 10/brlcad/branches/cmake/misc/CMake/ThirdParty.cmake: Don't force the third party lib off if it's been set on elsewhere, mark vars as advanced |
| 06:00.10 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:44.17 | CIA-53 | BRL-CAD: 03starseeker * r42790 10/brlcad/branches/cmake/ (14 files in 10 dirs): (log message trimmed) |
| 07:44.17 | CIA-53 | BRL-CAD: A variety of fixes and cleanups - had broken Tcl/Tk search, got it working - |
| 07:44.17 | CIA-53 | BRL-CAD: more advanced options cleanup, got things pretty much where they should be now. |
| 07:44.17 | CIA-53 | BRL-CAD: Move termlib logic into FindTERMLIB.cmake so it can work in the third party |
| 07:44.17 | CIA-53 | BRL-CAD: logic. Added new ability to the ThirdParty.cmake code - can now FORCE enabling |
| 07:44.18 | CIA-53 | BRL-CAD: and disabling of any given library, over and above the ENABLE_ALL style logic. |
| 07:44.19 | CIA-53 | BRL-CAD: Hopefully that will allow mimicking the autotools ./configure --enable-all |
| 08:09.56 | starseeker | woo-hoo |
| 08:25.09 | starseeker | can sleep now - invite folks to try out the cmake branch and see what still isn't up to par |
| 11:05.37 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 12:03.56 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 12:47.09 | CIA-53 | BRL-CAD: 03jordisayol * r42791 10/brlcad/trunk/misc/debian/source/include-binaries: add debian binary list to properly debian source build |
| 12:55.15 | dloman | Mernin all! Ready for some ice? ;) |
| 13:08.40 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:53.42 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 14:12.40 | *** join/#brlcad roberthl (~robert@v001.rhl.me.uk) | |
| 14:12.40 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 15:01.10 | starseeker | crawls back to a state of quasi-awake... |
| 15:01.23 | starseeker | d_rossberg: is your build still doing the extensive re-build thing? |
| 15:06.14 | d_rossberg | starseeker: now it looks to me as some build targets (e.g. INSTALL?) require a complete rebuild but a simple mged with its depending libraries won't |
| 15:06.47 | starseeker | d_rossberg: that might be... what does the ALL_BUILD target do for you? |
| 15:07.11 | starseeker | ususally does ALL_BUILD, PACKAGE and then uses the installer |
| 15:08.46 | starseeker | if I rerun ALL_BUILD multiple times, it does terminate here |
| 15:09.24 | CIA-53 | BRL-CAD: 03starseeker * r42792 10/brlcad/branches/cmake/CMakeLists.txt: Shouldn't need these any more, now that bu_brlcad_root and bu_brlcad_data are pretty much sorted out. |
| 15:11.48 | d_rossberg | i haven't checked it recently, last time i tested it it showed a "mystcal" behavior: long times of full system load with no output |
| 15:12.14 | d_rossberg | maybe i should check it again |
| 15:12.18 | starseeker | um. What version of Visual Studio are you using? |
| 15:12.30 | starseeker | has been doing a lot of cleanup |
| 15:13.19 | starseeker | d_rossberg: I'm getting very close to being "finished", and I'd like not to derail all you're stuff when we "go live" with the new CMake logic in the trunk |
| 15:13.23 | d_rossberg | 2008 |
| 15:13.54 | starseeker | hmm. Well, I'll try my copy here once... |
| 15:13.56 | starseeker | reboots |
| 15:17.15 | d_rossberg | ok, then i'll do some more intensive testing (beside my other work, you know, so be lenient) |
| 15:18.14 | starseeker | 'course |
| 15:18.39 | starseeker | just wanting to give you a heads up that we're getting quite close, and I know it'll probably impact you |
| 15:18.53 | starseeker | yech, windows |
| 15:22.43 | starseeker | I do still need to add the 64bit flags for Windows... |
| 15:29.58 | CIA-53 | BRL-CAD: 03starseeker * r42793 10/brlcad/branches/cmake/TODO.cmake: Note Windows 64 bit build as something to check/setup |
| 15:31.30 | CIA-53 | BRL-CAD: 03starseeker * r42794 10/brlcad/branches/cmake/CMakeLists.txt: Remove stray debug message |
| 15:47.26 | CIA-53 | BRL-CAD: 03starseeker * r42795 10/brlcad/branches/cmake/ (7 files in 7 dirs): Do a little more thorough wrapping of TERMLIB stuff. |
| 15:50.02 | brlcad | starseeker: if you had to run dos2unix (regarding r42766), then you likely did not set the right proplist on those files when they were added |
| 15:50.43 | brlcad | there should be an svn:mime-type and svn:eol-style set on all text files |
| 15:51.25 | brlcad | text/plain and native respectively |
| 15:51.57 | starseeker | brlcad: I did set those - a few files contained mixed line endings |
| 15:52.12 | brlcad | hm |
| 15:52.54 | brlcad | that's rather unusual it itself, but okay good to konw |
| 15:53.24 | starseeker | yeah, threw me for a minute - I actually had to install that tool, hadn't encountered that situation before |
| 15:54.14 | brlcad | mixed endings in our files, or xml dtd files, or docbook schema files? |
| 15:54.25 | starseeker | docbook xsl files |
| 15:54.35 | starseeker | or docbook-xsl-ns, to be specific |
| 15:55.09 | brlcad | k |
| 15:55.49 | CIA-53 | BRL-CAD: 03starseeker * r42796 10/brlcad/branches/cmake/CMakeLists.txt: mark as advanced for GUI |
| 16:04.31 | CIA-53 | BRL-CAD: 03starseeker * r42797 10/brlcad/branches/cmake/src/other/CMakeLists.txt: Don't try the termlib tests on Windows. |
| 16:06.11 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 16:09.14 | starseeker | ggrrrrrr... wish, what is your problem?? |
| 16:11.25 | starseeker | at least bwish works |
| 16:12.11 | starseeker | saddles up and heads in |
| 16:14.08 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:16.36 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.154) | |
| 18:16.36 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:40.36 | CIA-53 | BRL-CAD: 03erikgreenwald * r42798 10/brlcad/branches/cmake/src/other/togl/CMake/FindTCL.cmake: throw in some extra quotes on variables to avoid "wrong # of arguments" issues |
| 19:33.13 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.154) | |
| 19:33.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:44.48 | *** join/#brlcad Ralith (~ralith@d142-058-093-090.wireless.sfu.ca) | |
| 20:11.42 | CIA-53 | BRL-CAD: 03starseeker * r42799 10/brlcad/branches/cmake/src/other/step/src/ (5 files in 3 dirs): Remove stray semicolons |
| 20:36.31 | CIA-53 | BRL-CAD: 03erikgreenwald * r42800 10/brlcad/branches/bottie/ (5 files in 2 dirs): incorporate changes from trunk |
| 21:01.04 | CIA-53 | BRL-CAD: 03brlcad * r42801 10/brlcad/trunk/src/librtserver/ (Makefile.am rtserver.c): quell verbose warnings. mark unused parameters, remove dead code, remove unused variables. upgrade size variables to size_t except leave parameters as int and cast accordingly. |
| 21:06.08 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:13.53 | CIA-53 | BRL-CAD: 03brlcad * r42802 10/brlcad/trunk/src/libtclcad/tclcad.c: need to include tk.h too for Tk_Init() |
| 21:17.56 | CIA-53 | BRL-CAD: 03brlcad * r42803 10/brlcad/trunk/src/libtclcad/ged_obj.c: mark the slew of unused parameters. huge indicator that these callbacks are screwed up if so many have to be marked as unused |
| 21:25.31 | CIA-53 | BRL-CAD: 03brlcad * r42804 10/brlcad/trunk/src/libtclcad/Makefile.am: compiling clean on osx, enable strict |
| 21:30.55 | starseeker | brlcad: is it correct that there isn't a way to make a binary tar.gz distribution on unix systems and have the exectutables know to look for local relative library paths without setting LD_LIBRARY_PATH first? |
| 21:50.45 | CIA-53 | BRL-CAD: 03starseeker * r42805 10/brlcad/branches/cmake/CMakeLists.txt: Add ORIGIN into RPATH |
| 22:06.36 | starseeker | brlcad: nevermind :-) |
| 22:08.04 | brlcad | starseeker: ok |
| 22:08.21 | starseeker | google and CMake list to the rescue |
| 22:08.45 | starseeker | brlcad: finish digging through the mountain of computer gear yet? |
| 22:10.50 | brlcad | yep |
| 22:11.00 | starseeker | awesome - what was the final count? |
| 22:11.37 | brlcad | oh, I didn't keep exact count, more important was to sort and organize everything |
| 22:11.50 | brlcad | now on to the few remaining strict dirs |
| 22:11.59 | starseeker | cool |
| 22:12.24 | starseeker | did you get under half a dozen desktops in the end? |
| 22:17.27 | brlcad | yeah, I think it's five |
| 22:17.58 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) | |
| 22:18.01 | starseeker | that'll save some space |
| 22:22.59 | CIA-53 | BRL-CAD: 03brlcad * r42806 10/brlcad/trunk/src/halftone/ (6 files): mark unused params, rename 'new' param to be 'newrow' |
| 22:23.36 | CIA-53 | BRL-CAD: 03brlcad * r42807 10/brlcad/trunk/src/halftone/Makefile.am: passing mac, enable strict |
| 22:24.04 | CIA-53 | BRL-CAD: 03brlcad * r42808 10/brlcad/trunk/src/irprep/all_sf.c: mark unused params, avoid exact floating point comparisons |
| 22:26.22 | CIA-53 | BRL-CAD: 03brlcad * r42809 10/brlcad/trunk/src/irprep/showtherm.c: unused params, index->idx |
| 22:27.59 | *** join/#brlcad Ralith (~ralith@d142-058-080-092.wireless.sfu.ca) | |
| 22:34.43 | CIA-53 | BRL-CAD: 03starseeker * r42810 10/brlcad/trunk/src/other/step/src/ (7 files in 3 dirs): This isn't the right fix for this - revert |
| 22:36.40 | CIA-53 | BRL-CAD: 03brlcad * r42811 10/brlcad/trunk/src/librtserver/Makefile.am: linux issues to resolve, not yet |
| 22:40.14 | CIA-53 | BRL-CAD: 03starseeker * r42812 10/brlcad/branches/cmake/src/other/step/ (8 files in 4 dirs): revert r42674 in cmake too |
| 23:03.13 | CIA-53 | BRL-CAD: 03bob1961 * r42813 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Added cadwidgets::Ged::tk_to_rgb |
| 23:06.50 | CIA-53 | BRL-CAD: 03erikgreenwald * r42814 10/brlcad/branches/bottie/src/librt/primitives/bot/btg.c: throw in the global variables |
| 23:21.02 | CIA-53 | BRL-CAD: 03starseeker * r42815 10/brlcad/branches/cmake/ (4 files in 4 dirs): Tweaks for BSD - closer to building, though not fully tested |
| 23:25.01 | *** join/#brlcad Ralith (~ralith@d142-058-080-092.wireless.sfu.ca) | |
| 23:32.04 | starseeker | ``Erik: ok, that looks like it's got it |
| 23:32.14 | starseeker | (for non-strict on BSD anyway) |
| 23:35.58 | starseeker | yep, togl runs (remotely even) |
| 23:36.31 | starseeker | heads out before it decides to ice |
| 01:02.46 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 01:46.53 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 02:20.33 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 03:17.42 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 04:35.58 | CIA-53 | BRL-CAD: 03starseeker * r42816 10/brlcad/branches/cmake/CMakeLists.txt: |
| 04:35.58 | CIA-53 | BRL-CAD: Going to have to use a global property for the build targets lists - functions |
| 04:35.58 | CIA-53 | BRL-CAD: have local variable scope, not sure why it ever worked originally. This needs |
| 04:35.58 | CIA-53 | BRL-CAD: more testing, not sure it stays constant over multiple cmake runs and need to |
| 04:35.58 | CIA-53 | BRL-CAD: verify it's doing 'the right things'. Also, test noprod rule. |
| 05:07.48 | CIA-53 | BRL-CAD: 03brlcad * r42817 10/brlcad/trunk/src/librtserver/rtserver.c: add missing footer |
| 05:08.39 | CIA-53 | BRL-CAD: 03brlcad * r42818 10/brlcad/trunk/src/librtserver/rtserver.c: ws/indent consistency cleanup |
| 05:33.13 | CIA-53 | BRL-CAD: 03starseeker * r42819 10/brlcad/branches/cmake/CMakeLists.txt: |
| 05:33.14 | CIA-53 | BRL-CAD: This is a long shot, but see if a per-directory noprod can be set up. Just |
| 05:33.14 | CIA-53 | BRL-CAD: exploring the preliminary steps as yet - if this does work it will involve a |
| 05:33.14 | CIA-53 | BRL-CAD: hideous abuse of the old CMP0002 policy allowing non-unique target names, so not |
| 05:33.14 | CIA-53 | BRL-CAD: ideal even if it does work... |
| 05:35.51 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 05:57.58 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) | |
| 05:59.49 | *** join/#brlcad Stattrav (~Stattrav@122.172.33.253) | |
| 05:59.50 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:44.58 | CIA-53 | BRL-CAD: 03jordisayol * r42820 10/brlcad/trunk/ (misc/debian/control misc/debian/rules sh/make_deb.sh): add the option to build debian source packages and change debian configuration. |
| 09:14.39 | CIA-53 | BRL-CAD: 03jordisayol * r42821 10/brlcad/trunk/ (4 files in 2 dirs): add two new doc menu entries |
| 09:58.29 | cjdevlin | !info xubuntu-desktop |
| 11:19.43 | dloman | Well, i must admit that this storm is rather disappointing :/ |
| 11:20.11 | dloman | snow was supposed to start at 1700 yesterday and accumulate 5 inches.. so far, just a dusting. |
| 11:20.34 | dloman | But the ice has finally started..... yay. |
| 12:38.49 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:29.54 | *** join/#brlcad Stattrav (~Stattrav@117.192.135.87) | |
| 13:29.54 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:36.57 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:38.13 | ``Erik | hm, the cul de sac is a sheet of ice, no one else in my cul de sac has tried venturing out, one of my neighbors said he heard about lots of accidents on tv and was going to wait until it warms up later to try |
| 13:38.17 | ``Erik | O.O wee |
| 13:48.35 | dloman | time to take the M3 out for a 'spin' eh? =D |
| 13:51.29 | ``Erik | heh, it wouldn't be able to get out of the driveway, still too much snow and ice |
| 13:59.09 | dloman | fun fun! |
| 14:19.47 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 14:57.07 | dloman | Icy here, icy there...but at least post is open! lol |
| 15:34.16 | ``Erik | once I got out of my neighborhood (I think about a mile?), it was all good |
| 15:34.43 | ``Erik | I don't think they salt back in my development, or the one I have to go through to get from mine to the highway |
| 15:35.43 | ``Erik | 0.7 miles according to google maps heh |
| 15:41.40 | CIA-53 | BRL-CAD: 03starseeker * r42822 10/brlcad/branches/cmake/CMakeLists.txt: (log message trimmed) |
| 15:41.40 | CIA-53 | BRL-CAD: Eeek. This appears to be a working per-directory noprod solution. Done the |
| 15:41.40 | CIA-53 | BRL-CAD: best I can for convenience vs. policy - CMP0002 forbids non-unique target names, |
| 15:41.40 | CIA-53 | BRL-CAD: and hence excludes a 'make noprod' rule for each directory. Even forcing that |
| 15:41.40 | CIA-53 | BRL-CAD: to OLD, get some odd behavior with the toplevel 'make noprod' rule (not |
| 15:41.41 | CIA-53 | BRL-CAD: surprisingly, the policy is there for a reason). Hence, there is a toplevel |
| 15:41.42 | CIA-53 | BRL-CAD: make noprod command and in subdirectories 'make noprod' becomes 'cmake -P |
| 15:42.56 | starseeker | brlcad: that appears to be the best I can do for noprod - you can achieve (I think) the effects of make noprod in a directory but you'll have to do the cmake -P thing instead of make noprod |
| 16:11.14 | CIA-53 | BRL-CAD: 03starseeker * r42823 10/brlcad/branches/cmake/ (9 files in 5 dirs): Fix step build properly - surprise, surprise using scl_cf.h correctly actually helped |
| 16:20.15 | CIA-53 | BRL-CAD: 03starseeker * r42824 10/brlcad/branches/cmake/src/conv/step/CMakeLists.txt: Add the output include dir for step |
| 17:05.17 | CIA-53 | BRL-CAD: 03starseeker * r42825 10/brlcad/branches/cmake/src/other/tcl/CMakeLists.txt: Nevermind the dash - this symlink logic is too fragile, so just go with CMake standard practice |
| 17:08.52 | CIA-53 | BRL-CAD: 03jordisayol * r42826 10/brlcad/trunk/misc/Makefile.am: add two debian doc menu entries |
| 17:53.08 | CIA-53 | BRL-CAD: 03starseeker * r42827 10/brlcad/branches/cmake/ (5 files in 5 dirs): Ah - remove files based on version number properties as well for noprod. Start using the exec list to strip executables for CPack |
| 18:28.15 | *** join/#brlcad andrecastelo (~andre@187.115.160.108) | |
| 18:33.10 | CIA-53 | BRL-CAD: 03erikgreenwald * r42828 10/brlcad/trunk/src/librt/primitives/nmg/nmg_junk.c: Remove the HIDDEN from these junk functions to avoid "unused symbol" failures when debugging is off. |
| 18:43.21 | CIA-53 | BRL-CAD: 03starseeker * r42829 10/brlcad/branches/cmake/src/other/step/CMake/SCL_Utils.cmake: Don't use absolute install paths |
| 18:54.28 | CIA-53 | BRL-CAD: 03starseeker * r42830 10/brlcad/branches/cmake/ (4 files in 4 dirs): another absolute install path |
| 19:12.52 | ``Erik | http://punditkitchen.files.wordpress.com/2011/01/1fe680f4-203b-47af-bb23-8bb0e0f2a623.jpg |
| 19:20.16 | CIA-53 | BRL-CAD: 03starseeker * r42831 10/brlcad/branches/cmake/ (3 files in 2 dirs): Little more tweaking to mark variables as advanced |
| 19:25.14 | CIA-53 | BRL-CAD: 03starseeker * r42832 10/brlcad/branches/cmake/src/tclscripts/ampi.tcl: verbose flag is intentional to highlight problems - restore |
| 19:29.26 | CIA-53 | BRL-CAD: 03johnranderson * r42833 10/jbrlcad/trunk/ (10 files in 2 dirs): Point and Vector3 now have a common base class (Triple) |
| 19:36.29 | CIA-53 | BRL-CAD: 03starseeker * r42834 10/brlcad/branches/cmake/ (25 files in 11 dirs): MFC 42833 |
| 19:43.05 | CIA-53 | BRL-CAD: 03starseeker * r42835 10/brlcad/trunk/src/libbu/brlcad_path.c: realpath tweak, add ifdef wrapped Windows logic |
| 19:45.49 | CIA-53 | BRL-CAD: 03starseeker * r42836 10/brlcad/trunk/src/libbn/anim.c: initialize dir (quiet a warning) |
| 19:57.47 | starseeker | um... |
| 19:57.49 | starseeker | cc1plus: warnings being treated as errors |
| 19:57.49 | starseeker | src/other/openNURBS/opennurbs_array.h: In function ?ON_Curve* brlcad::pullback_curve(ON_BrepFace*, const ON_Curve*, brlcad::SurfaceTree*, double, double)?: |
| 19:57.52 | starseeker | src/other/openNURBS/opennurbs_array.h:353: error: inlining failed in call to ?virtual ON_2dPointArray::~ON_2dPointArray()?: call is unlikely and code size would grow |
| 19:57.55 | starseeker | src/librt/opennurbs_ext.cpp:2400: error: called from here |
| 19:58.12 | starseeker | huh? |
| 20:11.00 | brlcad | c++ should not be compiling with strict |
| 20:11.29 | brlcad | though that warning is a valid "issue" |
| 20:12.01 | brlcad | destructors shouldn't be inline anyways |
| 20:12.27 | starseeker | doesn't see where it's being inlined |
| 20:33.08 | CIA-53 | BRL-CAD: 03brlcad * r42837 10/brlcad/trunk/misc/debian/ (7 files): switch to text/plain and set eol-style to native |
| 20:42.24 | CIA-53 | BRL-CAD: 03brlcad * r42838 10/brlcad/trunk/src/libbn/anim.c: VINIT_ZERO instead of {} |
| 20:50.00 | CIA-53 | BRL-CAD: 03starseeker * r42839 10/brlcad/branches/cmake/src/libfft/CMakeLists.txt: Yow - optimized is what kills fft - don't go above 256 until there's a demonstrated need |
| 20:51.28 | brlcad | hehe |
| 20:53.02 | brlcad | the autotools build only goes up to 256 |
| 20:53.10 | CIA-53 | BRL-CAD: 03starseeker * r42840 10/brlcad/branches/cmake/src/libtclcad/CMakeLists.txt: Make libtclcad strict |
| 20:53.31 | brlcad | those generated sources get big fast |
| 20:53.37 | starseeker | indeed |
| 20:54.26 | brlcad | but it's clever, iirc one of the fastest implementation methods |
| 20:54.43 | starseeker | neat |
| 20:54.54 | starseeker | hmm |
| 20:54.57 | starseeker | src/liboptical/sh_noise.c:174: error: ‘noise_render’ declared ‘static’ but never defined |
| 20:54.58 | brlcad | would be ineteresting to revisit some comparisons to see if we're still one of the best |
| 20:55.56 | brlcad | the curse of forward declarations |
| 20:56.17 | brlcad | there shouldn't be any forward declarations |
| 20:59.26 | starseeker | must have missed an update |
| 21:01.47 | CIA-53 | BRL-CAD: 03starseeker * r42841 10/brlcad/trunk/src/liboptical/sh_noise.c: Forward declarations bad. - move mfuncs down and get rid of them |
| 21:01.58 | starseeker | sh_points.c:79: error: useless storage class specifier in empty declaration |
| 21:04.09 | CIA-53 | BRL-CAD: 03starseeker * r42842 10/brlcad/trunk/src/liboptical/sh_points.c: Hidden causes a warning here about useless storage class specification |
| 21:05.11 | *** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net) | |
| 21:05.11 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 21:10.51 | epileg | I can not create pdf files in Linux. is this normal? |
| 21:11.06 | starseeker | epileg: you mean the build won't make them? |
| 21:11.14 | epileg | yes, this is |
| 21:11.21 | starseeker | what is the error? |
| 21:11.35 | epileg | no error, on config says... |
| 21:11.39 | epileg | just a moment |
| 21:11.46 | starseeker | oh - you need to install Apache FOP |
| 21:13.03 | epileg | starseeker: thanks! I'll check |
| 21:14.54 | starseeker | brlcad: uh, this one has me puzzled... |
| 21:14.58 | starseeker | src/conv/g-vrml.c:821: error: variable ‘__stream’ might be clobbered by ‘longjmp’ or ‘vfor |
| 21:25.46 | brlcad | starseeker: you didn't see all of those longjmp commits last week? |
| 21:26.20 | brlcad | or at least read the commit messages .. I blathered quite a bit about that :) |
| 21:26.27 | starseeker | thought he recalled something |
| 21:26.30 | starseeker | checks... |
| 21:30.28 | starseeker | brlcad: r42544? |
| 22:00.51 | starseeker | cannot follow what this logic is doing |
| 22:01.06 | starseeker | q |
| 22:12.34 | CIA-53 | BRL-CAD: 03starseeker * r42844 10/brlcad/trunk/src/conv/dem-g.c: Compiler doesn't like this inline |
| 22:19.40 | CIA-53 | BRL-CAD: 03starseeker * r42843 10/brlcad/trunk/src/liboptical/sh_text.c: Need a little more careful look here, but this removes enough forward decls to get it building |
| 22:20.39 | CIA-53 | BRL-CAD: 03brlcad * r42845 10/brlcad/trunk/ (4 files in 3 dirs): check for GetFullPathName() and conditionalize on HAVE_GETFULLPATHNAME instead of _WIN32 accordingly |
| 22:21.44 | CIA-53 | BRL-CAD: 03brlcad * r42846 10/brlcad/trunk/src/libbu/ (brlcad_path.c timer.c): include bio.h instead of direclty including windows.h; keying off _WIN32 is bad form |
| 22:21.44 | CIA-53 | BRL-CAD: 03brlcad * r42847 10/brlcad/trunk/src/mged/mged.c: ERR... really? somehow this commit didn't make it through. give mged the ability to forcibly flip the version number even if librt doesn't do it automatically. |
| 22:21.44 | CIA-53 | BRL-CAD: 03brlcad * r42848 10/brlcad/trunk/src/bwish/ (consoleMain.c winMain.c): another bio.h inclusion instead of windows.h |
| 22:21.45 | CIA-53 | BRL-CAD: 03erikgreenwald * r42849 10/brlcad/branches/bottie/ (4 files in 3 dirs): mimic rt_bot_minpieces for TIE algorithm |
| 22:27.20 | CIA-53 | BRL-CAD: 03starseeker * r42850 10/brlcad/trunk/src/conv/g-vrml.c: work around potential clobber in g-vrml |
| 22:27.20 | CIA-53 | BRL-CAD: 03starseeker * r42851 10/brlcad/trunk/src/conv/g-x3d.c: Same issue with g-x3d |
| 22:28.37 | CIA-53 | BRL-CAD: 03starseeker * r42852 10/brlcad/trunk/src/libdm/ (dm-plot.c dm-ps.c dm-tk.c): reorder to remove forward declarations |
| 22:39.41 | CIA-53 | BRL-CAD: 03starseeker * r42853 10/brlcad/branches/cmake/misc/CMake/BRLCAD_Util.cmake: Turn off Werror when we see cpp files in a strict library, unless CXX_STRICT is on. Leave the warnings unless the warnings option is off. |
| 22:42.31 | CIA-53 | BRL-CAD: 03starseeker * r42854 10/brlcad/branches/cmake/CMakeLists.txt: Add the BRLCAD-ENABLE_CXX_STRICT option |
| 22:44.30 | CIA-53 | BRL-CAD: 03brlcad * r42855 10/brlcad/trunk/src/mged/mged.c: tweak the message to let the user know whether -f had any affect. only mark as read-only and flip if we need to. |
| 22:45.16 | CIA-53 | BRL-CAD: 03starseeker * r42856 10/brlcad/trunk/src/ (4 files in 2 dirs): Few misc tweaks - turn off some unused libged code, UNUSED in brep.cpp |
| 22:46.55 | CIA-53 | BRL-CAD: 03starseeker * r42857 10/brlcad/branches/cmake/ (26 files in 10 dirs): Put various fixes into CMake branch |
| 22:46.57 | CIA-53 | BRL-CAD: 03brlcad * r42858 10/brlcad/trunk/include/config_win.h: file wasn't saved for r42845. set HAVE_GETFULLPATHNAME |
| 22:49.11 | CIA-53 | BRL-CAD: 03starseeker * r42859 10/brlcad/trunk/src/libtclcad/ged_obj.c: not defined |
| 22:50.05 | CIA-53 | BRL-CAD: 03starseeker * r42860 10/brlcad/branches/cmake/src/bwish/ (consoleMain.c winMain.c): More fixes from trunk |
| 22:50.36 | CIA-53 | BRL-CAD: 03starseeker * r42861 10/brlcad/branches/cmake/src/libtclcad/ged_obj.c: remove this on cmake branch too |
| 22:50.54 | brlcad | should delete unused code |
| 22:51.13 | starseeker | brlcad: thought I'd check with Bob/Richard before nuking |
| 22:51.42 | brlcad | it's in revision history |
| 22:51.49 | starseeker | true |
| 22:52.07 | brlcad | if there's no comment, then there's definitely no reason to keep it |
| 22:52.07 | CIA-53 | BRL-CAD: 03starseeker * r42862 10/brlcad/branches/cmake/src/mged/mged.c: update from trunk |
| 22:52.47 | brlcad | commented out code, #if 0'd code |
| 22:53.41 | brlcad | it's a maintenance burden and just makes the files messy and often error prone, the code falls out of sync quickly and can cause bugs if re-enabled |
| 22:57.02 | CIA-53 | BRL-CAD: 03starseeker * r42863 10/brlcad/trunk/src/libged/ (bigE.c human.c): Go ahead and remove the code from libged, instead of commenting itout |
| 22:57.45 | brlcad | ah yeah, covered by HACKING under the refactoring section too :) |
| 23:00.50 | CIA-53 | BRL-CAD: 03starseeker * r42864 10/brlcad/trunk/src/ (4 files in 4 dirs): |
| 23:00.50 | CIA-53 | BRL-CAD: Let's try this again - see if we can do without tclcad_tcl_library. Using |
| 23:00.50 | CIA-53 | BRL-CAD: private Tcl functions is Not Good, particularly when it's for debug printing. |
| 23:00.50 | CIA-53 | BRL-CAD: also removing the found_init_tcl call to TclSetLibraryPath - same basic problem |
| 23:00.50 | CIA-53 | BRL-CAD: and the comment says it doesn't do what we might expect it to anyway. |
| 23:02.20 | CIA-53 | BRL-CAD: 03starseeker * r42865 10/brlcad/branches/cmake/src/ (4 files in 4 dirs): remove tclcad_tcl_library in CMake branch too |
| 23:02.37 | starseeker | brlcad: is that alternative way to do the make noprod thing acceptable? |
| 23:04.18 | brlcad | doing a "make noprod" from the top-level would even probably work if you can relink a given binary (e.g. "make mged") with one step |
| 23:05.57 | brlcad | hard to say without trying it in practice really, wasn't clear what the final step(s) needed were going to be |
| 23:06.29 | starseeker | uh... you just do cmake -P ./cmake_noprod.cmake instead of make noprod |
| 23:07.12 | brlcad | heh, might just end up with an sh/noprod.sh script then that runs that |
| 23:08.13 | starseeker | cmake will relink the libraries required by mged before linking mged |
| 23:08.23 | starseeker | following its dependency logic |
| 23:09.13 | brlcad | so what about a simple rule that wipes out all products? |
| 23:09.23 | starseeker | that's the toplevel make noprod |
| 23:09.25 | starseeker | that works |
| 23:09.41 | starseeker | it's just in the subdirectories you need to run the specific script |
| 23:09.48 | starseeker | I can't define a noprod target for every directory |
| 23:11.00 | CIA-53 | BRL-CAD: 03bob1961 * r42866 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Updated Archer::constructor to properly set the view of the command window (i.e. how much command window to display verses geometry window etc. |
| 23:13.04 | starseeker | O.o the toy jeep is giving out Bend radii errors |
| 23:15.10 | brlcad | the toplevel make noprod sounds like it might end up being more practical than cmake -P ./cmake_noprod.cmake |
| 23:15.31 | starseeker | well, they're both there |
| 23:15.45 | starseeker | it's not an either/or situation |
| 23:16.04 | brlcad | it just feels way too long and prone to being forgotten |
| 23:16.19 | starseeker | what about cmake -P noprod |
| 23:16.39 | starseeker | the last arg is a file name, I can just call it noprod if that's better |
| 23:16.40 | brlcad | that'd probably be better |
| 23:17.01 | brlcad | no way to inject custom make rules? |
| 23:17.26 | brlcad | some "if target is makefile, #include Makefile.inc" |
| 23:17.44 | brlcad | similar to what is done for "make fast" |
| 23:17.59 | starseeker | not that I've found so far... |
| 23:18.00 | brlcad | and make noprod for that matter, iirc |
| 23:20.00 | brlcad | my gut feeling is if all products are unique, then cd'ing down into the hierarchy isn't going to be as important |
| 23:20.31 | brlcad | since I can "make noprod && make rt" and it'll relink rt (along with all of rt's dependencies) |
| 23:20.37 | starseeker | nods |
| 23:20.50 | starseeker | well, the cmake -P option is there if it's needed |
| 23:21.12 | starseeker | was quite the operation to set up |
| 23:21.18 | brlcad | not quite as ideally targetted as *only* relinking rt, but possibly workable |
| 23:21.28 | brlcad | have to see in practice, but it's a minor point |
| 23:21.55 | brlcad | I don't doubt it |
| 23:22.56 | brlcad | unfortunately, cmake makes some things much harder to do |
| 23:23.09 | brlcad | a known limitation going into this |
| 23:23.29 | starseeker | a few maybe, but I haven't had too much trouble on the whole... |
| 23:23.35 | brlcad | heh |
| 23:23.44 | starseeker | main trouble was Tcl/Tk |
| 23:23.45 | brlcad | says you more than 6 months later :) |
| 23:24.19 | starseeker | <snort> If I'd been re-creating the autotools logic, I'd bet on a year easy (for me, anyway) |
| 23:25.58 | CIA-53 | BRL-CAD: 03starseeker * r42867 10/brlcad/branches/cmake/CMakeLists.txt: no reason to use cmake_noprod.cmake - just call it noprod so it's more like a make target |
| 23:27.01 | starseeker | you super scripting gurus are more comfortable with sh and friends - for me it might as well be perl |
| 23:28.40 | brlcad | autotools was a learning hurdle too |
| 23:29.03 | brlcad | both erik and I put several months whipping configure.ac and friends into shape |
| 23:30.55 | brlcad | the cmake effort is probably on-par, seems like even a bit more given it's not as mature and flexible |
| 23:31.29 | brlcad | but then higher short-term with the hope that maintenance is lower in the long-term |
| 23:31.48 | starseeker | nods |
| 23:33.11 | brlcad | realistically speaking, there's undoubtedly months of work still remaining to bring it on-par cross-platform in a low-maintenance fashion with all the bugs squeezed out |
| 23:34.06 | starseeker | I suppose. On the whole I'm rather happy with how it's turned out, but of course I haven't done extensive options testing and such |
| 23:34.21 | starseeker | knows turning off X11 won't quite work yet, for example - it still builds Tk |
| 23:35.29 | brlcad | simple code metrics -- no code is perfect, there will be bugs even aside from incompleteness |
| 23:37.40 | brlcad | new code is pretty consistently reliable to have bugs on the order as bad as 1% to as good as 0.1% (on average) |
| 23:38.35 | starseeker | brlcad: what are the remaining hurdles for me to be able to merge into trunk? |
| 23:39.33 | brlcad | lines-of-code of course isn't really strictly reliable, but it's pretty reasonable to assume that if 10000 new lines of logic were written, that there's at least a dozen bugs in there if not more |
| 23:42.45 | brlcad | starseeker: well whenever you're confident that you're "done done", that should mean that someone else should be able to do a code review to see if there are any show-stopper code differences, things that were turned on/off, that a release can be produced and verified, that everything is properly documented (which is really part of release verification) |
| 23:45.10 | CIA-53 | BRL-CAD: 03starseeker * r42868 10/brlcad/branches/cmake/src/ (bwish/CMakeLists.txt other/CMakeLists.txt): Don't enable Tk even with ENABLE_ALL if we aren't supposed to build it |
| 23:45.39 | starseeker | brlcad: so I need the equalivent to our documentation of the configure options for the significant CMake variables |
| 23:46.27 | starseeker | ponders... hmm... |
| 23:46.41 | brlcad | ideally, yes -- but more specifically, README, INSTALL, HACKING, doc/* have to be updated |
| 23:47.24 | brlcad | places that refer to "autogen.sh", or "configure", "make", "Makefile.am", etc |
| 23:47.43 | brlcad | we have to be able to push out a source release |
| 23:47.59 | brlcad | compilation docs are part of that |
| 23:47.59 | starseeker | nods. |
| 23:52.04 | brlcad | notes that it's time to prepare a release |
| 23:53.00 | brlcad | how extensively did you test r42864 ? |
| 23:53.18 | brlcad | tclcad_tcl_library() removal |
| 23:53.45 | starseeker | I've had it gone in the CMake branch for a while, but less extensively than I'd like |
| 23:54.15 | starseeker | unless its documentation was wrong, it's a debug output function? |
| 23:54.26 | brlcad | it's not |
| 23:54.43 | brlcad | it prevents a runtime crash for some versions of tcl |
| 23:56.14 | brlcad | TclGetLibraryPath() initializes some things internal to the Tcl library that were not otherwise getting initialized by Tcl_Init or other calls and would result in a non-catchable run-time crash |
| 23:56.59 | brlcad | iirc, not visible during --enable-all but was reproducible if you used a system tcl/tk |
| 23:57.51 | brlcad | don't know if it was specific to any tcl version, 8.4 or 8.5 but it was a hard show-stopper crash of mged |
| 23:58.32 | brlcad | it was a while ago too, so if it works with --enable-all and --disable-all now with 8.5+ for example, then we can just move forward |
| 23:58.57 | starseeker | ok, I'll see what happens with a system tcl/tk |
| 23:59.15 | starseeker | We can put it back in if we have to, but I really don't like calling private Tcl/Tk functions |
| 23:59.26 | brlcad | putting it back isn't the issue |
| 23:59.34 | brlcad | given it's a hard crash, we can't do a release until verifying |
| 23:59.40 | starseeker | ah |
| 23:59.43 | brlcad | because it's otherwise DOA |
| 00:00.35 | brlcad | need to check at least linux with and without system tcl, and mac (without of course) |
| 00:01.37 | brlcad | fwiw, make test and make distcheck aren't sufficient, have to kick off the GUI |
| 00:01.46 | starseeker | nods |
| 00:06.57 | brlcad | I had distchecks passing with all options on/off for 64-bit linux, testing mac now |
| 00:31.44 | CIA-53 | BRL-CAD: 03starseeker * r42869 10/brlcad/branches/cmake/TODO.cmake: Add a few more TODO items for CMake |
| 00:35.08 | CIA-53 | BRL-CAD: 03starseeker * r42870 10/brlcad/trunk/src/mged/mged.c: dbip_filename -> dbi_filename |
| 00:50.59 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 00:53.33 | starseeker | brlcad: I think I may have messed up. I am using BRLCAD_DATA as a relative path from BRLCAD_ROOT, but I'm seeing in trunk that both BRLCAD_DATA and BRLCAD_ROOT are full paths |
| 01:09.54 | *** join/#brlcad DX^ (~DX@c-71-59-50-121.hsd1.ga.comcast.net) | |
| 01:10.01 | DX^ | I can't find the configure flag to disable compiling with X11 |
| 01:10.40 | starseeker | --disable-x11 ? |
| 01:14.14 | DX^ | I tried --disable-x |
| 01:14.19 | DX^ | but that didn't work, I'll try that.. |
| 01:15.55 | DX^ | still says its enabled |
| 01:16.40 | starseeker | --without-x11 ? |
| 01:17.34 | DX^ | trying |
| 01:17.58 | starseeker | brlcad: my apologies - I think I made my own trouble with the path logic, after all |
| 01:22.19 | DX^ | that worked, awesome |
| 01:22.38 | CIA-53 | BRL-CAD: 03starseeker * r42871 10/brlcad/trunk/src/libbu/brlcad_path.c: Dur. BRLCAD_DATA is supposed to be a full path, but I had a relative path in the CMake logic... hilarity ensued. Put it back the way it should be and make CMake do it right. |
| 01:29.59 | CIA-53 | BRL-CAD: 03starseeker * r42872 10/brlcad/trunk/configure.ac: Add note that BRLCAD_DATA must be a full path |
| 01:39.41 | CIA-53 | BRL-CAD: 03starseeker * r42873 10/brlcad/branches/cmake/ (CMakeLists.txt configure.ac src/libbu/brlcad_path.c): Do BRLCAD_DATA the right way in CMake. |
| 01:49.51 | CIA-53 | BRL-CAD: 03starseeker * r42874 10/brlcad/trunk/ (7 files in 4 dirs): Apply 42757 to trunk - without this, getting failures on gentoo with warnings enabled. |
| 01:55.54 | CIA-53 | BRL-CAD: 03starseeker * r42875 10/brlcad/trunk/configure.ac: Whoops - manuals/archer is still gone |
| 02:12.14 | CIA-53 | BRL-CAD: 03starseeker * r42876 10/brlcad/trunk/doc/docbook/Makefile.am: catalog.xml is no more |
| 02:35.33 | brlcad | starseeker: hm, yeah they should be full paths but it's an interesting thought |
| 02:35.51 | brlcad | relative path "should" work, but I can see how an assumption may be in there |
| 02:36.40 | starseeker | relative is already sort of there with the root/share/brlcad/version check - that's what you get with a relative BRLCAD_DATA |
| 02:36.52 | brlcad | BRLCAD_ROOT and BRLCAD_DATA are environment variables so they could conceivably be relative if we allow it |
| 02:37.10 | brlcad | bu_brlcad_root() and bu_brlcad_data() probably have assumptions otherwise |
| 02:37.27 | brlcad | ah, yeah, that would work |
| 02:37.36 | brlcad | though full-path root and relative data should work too |
| 02:37.58 | brlcad | or the limitation should be documented |
| 02:38.04 | starseeker | that's what I was doing with CMake (albeit accidentally) |
| 02:38.12 | starseeker | mentioned it in configure.ac |
| 02:38.22 | brlcad | yeah, i saw |
| 02:38.39 | brlcad | I mean to users though -- the environment variable isn't set by configure |
| 02:38.46 | brlcad | it sets the "hard wired" default |
| 02:38.48 | starseeker | wouldn't be too hard to make it accept a relative path - I did it initially before I realized |
| 02:38.59 | starseeker | ah, point |
| 02:39.52 | starseeker | Windows might be a problem if they stick a drive letter at the beginning of a path though |
| 02:40.33 | starseeker | brlcad: distcheck passes here |
| 02:41.00 | starseeker | although come to think of it, it did work on Windows |
| 02:48.18 | brlcad | cool |
| 02:48.22 | brlcad | mged runs? |
| 02:48.33 | brlcad | what platform/settings? |
| 02:49.02 | starseeker | gentoo x86_64 with --enable-all |
| 02:49.11 | starseeker | mged seems to run |
| 02:49.16 | starseeker | will build again with system tcl/tk |
| 02:49.59 | brlcad | okay, testing mac here |
| 02:50.08 | brlcad | 10.6 |
| 02:56.38 | brlcad | everyone ready for GSoC? |
| 02:57.09 | starseeker | ah, that's on again? |
| 02:57.10 | starseeker | sweet |
| 03:06.21 | starseeker | brlcad: just a thought - with the cmake build, all the final build products are right there in lib or bin |
| 03:08.21 | DX^ | IGES/STEP converters are segfaulting on me |
| 03:08.23 | DX^ | with the newest code |
| 03:08.51 | starseeker | on files that worked previously? |
| 03:09.02 | DX^ | no, but the STEP file I'm trying is just a box |
| 03:09.06 | DX^ | don't think it can get much simpler |
| 03:09.14 | starseeker | what's the error? |
| 03:09.35 | DX^ | "Segmentation fault" |
| 03:09.42 | starseeker | ah, that's it? |
| 03:09.56 | DX^ | yep |
| 03:09.59 | starseeker | DX^: can you post the file on a bug report at sourceforge? |
| 03:10.15 | starseeker | brlcad: local tcl/tk seems to work too |
| 03:10.32 | DX^ | starseeker: yeah |
| 03:10.47 | starseeker | cool - we'll need to hook up a debugger to see what happened |
| 03:32.13 | brlcad | starseeker: that's good to hear -- what version of tcl? |
| 03:32.16 | CIA-53 | BRL-CAD: 03brlcad * r42877 10/brlcad/trunk/misc/Makefile.am: include debian/source/include-binaries in dist |
| 03:32.27 | brlcad | suspects the crashes were 8.4 specific |
| 03:33.24 | starseeker | 8.5.9 |
| 03:37.28 | brlcad | starseeker: that's a good point regarding cmake build -- noprod might be obsolete via that alone since you could run targetted rm's and remake |
| 03:37.58 | brlcad | have to put it through the paces with use to see what's most efficient |
| 03:39.41 | CIA-53 | BRL-CAD: 03starseeker * r42878 10/brlcad/branches/cmake/src/other/togl/CMakeLists.txt: Stray character |
| 03:39.53 | CIA-53 | BRL-CAD: 03tbrowder2 * r42879 10/brlcad/trunk/HACKING: added info on using in-tree executables without installing\nadded words about developer responsibilities |
| 03:48.10 | CIA-53 | BRL-CAD: 03starseeker * r42880 10/brlcad/branches/cmake/src/other/togl/demo/gears.tcl: Just package require Togl for the gears demo - don't need to manually load anything if we're set up correctly. |
| 03:53.17 | CIA-53 | BRL-CAD: 03tbrowder2 * r42881 10/brlcad/trunk/INSTALL: added information about where file check sums are to be found |
| 04:14.11 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) | |
| 05:08.29 | CIA-53 | BRL-CAD: 03starseeker * r42882 10/brlcad/branches/cmake/bench/CMakeLists.txt: benchmark needs pixcmp |
| 05:36.33 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:33.42 | *** join/#brlcad Stattrav (~Stattrav@122.172.33.253) | |
| 06:33.42 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:26.28 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 07:35.18 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) | |
| 09:59.48 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:49.28 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:52.28 | epileg | brlcad: what's better? build deb packages with or without pdf files? |
| 12:52.28 | epileg | with (≃ 85 MB.), without (≃ 55 MB.) |
| 13:58.38 | starseeker | epileg: for now I'd say without |
| 13:58.55 | epileg | ok, thanks! |
| 13:58.55 | starseeker | we have some work to do before the pdf output from most of our stuff is fit for consumption |
| 14:21.00 | CIA-53 | BRL-CAD: 03erikgreenwald * r42883 10/brlcad/branches/bottie/ (1260 files in 90 dirs): MFC 42842 |
| 14:37.09 | *** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202) | |
| 14:37.26 | brlcad | starseeker: did "make test" pass for you? |
| 14:37.56 | brlcad | I'm getting all sorts of failures here, but still have to look into why |
| 14:42.33 | starseeker | hmm - it's failing to create solids.rt, shaders.rt... |
| 14:44.42 | *** join/#brlcad Stattrav (~Stattrav@117.192.140.121) | |
| 14:44.42 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:46.21 | CIA-53 | BRL-CAD: 03brlcad * r42884 10/brlcad/trunk/src/halftone/main.c: enable-optimized linux strictness failure, check fwrite() return value |
| 14:47.15 | starseeker | brlcad: opendb isn't creating solids.g |
| 14:48.02 | starseeker | when it runs opendb solids.g y the command completes, but a database is not opened |
| 14:48.28 | brlcad | okay, that should be easy to fix |
| 14:48.37 | brlcad | maybe even my doing with the -f flag |
| 14:48.48 | starseeker | that was my first guess |
| 14:49.00 | brlcad | an argc check off by one or something |
| 14:49.33 | brlcad | cool, optimized and unoptimized distchecks now all passing on linux |
| 14:56.54 | starseeker | brlcad: I'm guessing it's in 42564 |
| 14:57.21 | brlcad | hah, looks like the logic is just reversed |
| 14:57.34 | brlcad | opendb files.g n creates a database :) |
| 14:57.42 | starseeker | lol |
| 14:58.11 | starseeker | ok, so probably not that commit then |
| 15:01.21 | ``Erik | well, damn, I just spent the last 2 days trying to get things together and working to move bottie to trunk O.o |
| 15:01.38 | starseeker | why is that a problem? |
| 15:02.08 | ``Erik | if we're in the middle of release cycle, it might not be the best time to do it |
| 15:02.08 | brlcad | it can be the highlight feature for 7.18.4 or 7.20 even |
| 15:02.33 | brlcad | get more attention that way anyways |
| 15:02.46 | *** join/#brlcad mafm (~mafm@72.Red-83-45-72.dynamicIP.rima-tde.net) | |
| 15:02.51 | ``Erik | apparently some weirdness happened, or svn sucks for this kinda merge, royal pain :/ |
| 15:03.28 | brlcad | ``Erik: it sucks until that last to-do item is dealt with, which I'm planning as soon as release is posted |
| 15:03.44 | brlcad | our repo is too old to support merge tracking |
| 15:03.52 | ``Erik | ah, --reintegrate? |
| 15:03.54 | brlcad | that's what has been causing some of the merge headache |
| 15:03.56 | ``Erik | fsfs 2 vs 3 or something |
| 15:04.07 | brlcad | 1.5+ backend repo |
| 15:04.12 | brlcad | we're a 1.4 repo or something iirc |
| 15:04.24 | starseeker | ``Erik: were you going to try and track down the big missing pieces in bottie raytracing prior to merge? |
| 15:04.49 | starseeker | or just stick with the insane high threshold for now |
| 15:05.23 | ``Erik | starseeker: was going to have an obnoxiously high # and work it after merge, I seem to spend way more time merging and resolving conflicts to try to track trunk than getting to actually work on it |
| 15:06.06 | ``Erik | wonders if there's a darcs/svn bridge O.o |
| 15:09.56 | starseeker | ``Erik: then you should be pretty safe to merge, yes? |
| 15:11.14 | ``Erik | probably *shrug* |
| 15:16.13 | brlcad | I wouldn't call that merge-safe in the least .. heh |
| 15:16.20 | brlcad | it's a huge body of change to code and a new feature |
| 15:18.38 | brlcad | release safe things are like minor bug fixes, updating documentation, tweaking a bu_log, removing dead code, adding comments, ... |
| 15:21.13 | brlcad | that really is great feature for the next release where it can be spoken to and highlighted, maybe erik can write up a mini article about it all even |
| 15:22.00 | CIA-53 | BRL-CAD: 03erikgreenwald * r42885 10/brlcad/trunk/src/halftone/main.c: more missed size_t changes |
| 15:24.38 | CIA-53 | BRL-CAD: 03erikgreenwald * r42886 10/brlcad/trunk/src/libged/ (vdraw.c wdb_vdraw.c): cast to long unsigned int to match wdb_vdraw.clu |
| 15:25.05 | ``Erik | ugh, tons of those in src/conv |
| 15:26.01 | brlcad | want me to disable strict or you going to hit em up? |
| 15:26.30 | brlcad | I don't have a plat that warns on that one opt or non-opt |
| 15:26.37 | ``Erik | I can hit them, bit nervous about casting read pointers like that blindly |
| 15:26.41 | ``Erik | crit should do it |
| 15:27.14 | ``Erik | FreeBSD 8.2-PRERELEASE #3: Thu Dec 2 13:59:53 EST 2010 |
| 15:28.08 | ``Erik | using system tcl, tk, tnt, debug off (that seems to be a big one), optimized on |
| 15:28.50 | CIA-53 | BRL-CAD: 03brlcad * r42887 10/brlcad/trunk/TODO: two release issues being worked on now, opendb failure and strict failures on fbsd |
| 15:28.57 | brlcad | ah, debug off .. haven't tries that in a while |
| 15:29.52 | CIA-53 | BRL-CAD: 03erikgreenwald * r42888 10/brlcad/trunk/src/libtclcad/tkImgFmtPIX.c: more size_t fixing |
| 15:40.57 | CIA-53 | BRL-CAD: 03erikgreenwald * r42889 10/brlcad/trunk/src/conv/ (6 files in 3 dirs): casts/changes to cope with size_t vs vprintf |
| 15:46.12 | ``Erik | that seems to be all the type warnings, there is still the tcl85 vs tcl8.5 link error when building tcl with BRL-CAD, though :/ |
| 15:49.35 | CIA-53 | BRL-CAD: 03brlcad * r42890 10/brlcad/trunk/src/libbu/booleanize.c: |
| 15:49.36 | CIA-53 | BRL-CAD: bu_booleanize() FAIL. several problems: 1) \!str == 0 means we return false for |
| 15:49.36 | CIA-53 | BRL-CAD: all non-null strings, 2) strtol() will return 0 if there are no numbers (boo, |
| 15:49.36 | CIA-53 | BRL-CAD: hiss), and 3) it wasn't taking whitespace into consideration. stash the input |
| 15:49.36 | CIA-53 | BRL-CAD: into a vls, trim whitespace, then perform our tests. |
| 15:49.49 | starseeker | brlcad: heh, you just beat me to it |
| 15:49.53 | starseeker | was writting my commit message |
| 15:50.55 | CIA-53 | BRL-CAD: 03brlcad * r42891 10/brlcad/trunk/src/libbu/booleanize.c: remove debug statements |
| 15:51.35 | brlcad | starseeker: ah, heh -- what was your change? |
| 15:51.41 | brlcad | there's another problem in mged.c |
| 15:52.09 | starseeker | was doing str == NULL instead of !str |
| 15:52.24 | starseeker | !str was returning 0 here even for a valid string |
| 15:52.39 | starseeker | good call on the whitespace |
| 15:53.34 | CIA-53 | BRL-CAD: 03brlcad * r42892 10/brlcad/trunk/src/mged/mged.c: logic is reversed. if NOT true, i.e. the user responded 'n', then report that no database is open. |
| 15:53.41 | brlcad | !str is 0 for all valid strings ;) |
| 15:53.49 | brlcad | !str is only true if str is null :) |
| 15:54.03 | starseeker | ah, gotcha |
| 15:54.38 | starseeker | one possible improvement I can still make... |
| 15:54.43 | brlcad | it should have been "str == NULL" or "!str" .. but "!str == NULL" (i.e., "!str == 0") means that all valid strings will return negative |
| 15:54.51 | starseeker | hehe |
| 15:54.53 | CIA-53 | BRL-CAD: 03starseeker * r42893 10/brlcad/trunk/src/libbu/booleanize.c: Can still use strtol, but need to make sure endptr is '\0' (i.e., that a valid number was actually processed). |
| 15:55.53 | starseeker | brlcad: if I'm reading the strtol documentation right, that will work |
| 15:56.23 | brlcad | hm |
| 15:56.25 | brlcad | "If there were no digits at all, however, strtol() stores the original value of str in *endptr. |
| 15:56.39 | starseeker | right |
| 15:56.48 | brlcad | okay, I think I see it |
| 15:58.42 | CIA-53 | BRL-CAD: 03starseeker * r42894 10/brlcad/trunk/src/libbu/booleanize.c: whoops - val is an int |
| 15:59.07 | brlcad | what do you think about bu_true() instead of bu_booleanize() ? |
| 15:59.22 | brlcad | for readability, if (bu_true(some_string)) ... |
| 15:59.43 | starseeker | it's a bit shorter... does true imply anything that booleanize doesn't? (or vice versa?) |
| 16:00.15 | starseeker | have expects bu_true to always return true, but that's just a silly reflex |
| 16:00.21 | starseeker | s/have/half |
| 16:00.26 | brlcad | the name bu_booleanize() doesn't imply a truth return value, so it's funky to read and get the logic right |
| 16:00.46 | brlcad | the mged.c change for example |
| 16:01.09 | starseeker | I'm cool with bu_true |
| 16:01.13 | brlcad | bu_str_true() |
| 16:01.22 | starseeker | ah, yeah that's better |
| 16:01.25 | starseeker | little more specific |
| 16:04.08 | CIA-53 | BRL-CAD: 03starseeker * r42895 10/brlcad/trunk/src/libbu/booleanize.c: Let's stay consistent - long, not int |
| 16:04.18 | brlcad | namingwise, bu_str_to_rgb() is the only other bu_str_ along with the C wrappers bu_strdup, bu_strcpy, etc |
| 16:05.02 | starseeker | well, either way |
| 16:05.12 | starseeker | doesn't have a real strong opinion |
| 16:05.46 | brlcad | bu_str_to_bool() is no better than bu_booleanize() |
| 16:06.13 | brlcad | heh, bu_truthify() |
| 16:06.46 | brlcad | bu_test_whether_string_is_yes() |
| 16:07.00 | *** join/#brlcad Zaebos (~irc@217.91.127.94) | |
| 16:07.10 | ``Erik | why do I feel like the description needs the phrase "and truthishly" in it |
| 16:07.27 | CIA-53 | BRL-CAD: 03starseeker * r42896 10/brlcad/trunk/src/adrt/libtie/tie.c: tie.h includes common.h, so don't need to include it twice - fixes regress common.h inclusion order error. |
| 16:09.16 | starseeker | brlcad: we still have bio.h in cmd.h - I guess the thing to do is take it out and see what fails on Windows? |
| 16:11.25 | brlcad | sure, though the comment says why it's there |
| 16:11.29 | brlcad | timeval from windows.h |
| 16:11.31 | starseeker | was included in 41077... if it does need to be there (and since some guy called brlcad committed it I'm guessing we really do) we should probably special case exempt that in the regression test |
| 16:12.12 | brlcad | so either cmd.h needs the same windows wrapper logic like bio.h has or bio.h has to be included before all instances of cmd.h |
| 16:12.35 | starseeker | or we tweak the regression test... |
| 16:12.49 | brlcad | just because I committed it does mean it's right.. looks wrong to me :) |
| 16:13.18 | brlcad | having to put exceptions usually implies something is wrong |
| 16:14.42 | starseeker | mutter... mged has its own cmd.h file, clutters up grep |
| 16:14.49 | starseeker | tunes... |
| 16:16.12 | starseeker | wow, cmd.h is popular |
| 16:17.00 | brlcad | to be a self-contained header including what it needs, cmd.h should probably just have the windows.h logic |
| 16:17.11 | starseeker | is doing that now... |
| 16:19.02 | CIA-53 | BRL-CAD: 03starseeker * r42897 10/brlcad/trunk/include/cmd.h: grab the relevant part of bio.h's windows.h inclusion logic and put it in cmd.h, rather than including bio.h (should fix regression test failure. |
| 16:21.51 | CIA-53 | BRL-CAD: 03brlcad * r42898 10/brlcad/trunk/ (include/bu.h src/libbu/booleanize.c src/mged/mged.c): |
| 16:21.51 | CIA-53 | BRL-CAD: rename bu_booleanize() to bu_str_true() which is not only two chars shorter but |
| 16:21.51 | CIA-53 | BRL-CAD: reads much better within if-statements. not as cool a name, but hopefully less |
| 16:21.51 | CIA-53 | BRL-CAD: prone to logic errors. also add the counterpart bu_str_false() to have a |
| 16:21.52 | CIA-53 | BRL-CAD: matching set and for readability. |
| 16:24.13 | CIA-53 | BRL-CAD: 03starseeker * r42899 10/brlcad/branches/cmake/ (22 files in 14 dirs): Update cmake branch to trunk r42898 - need to do some manual checking, probably missed a few things earlier when working in both trees at once. |
| 16:42.20 | CIA-53 | BRL-CAD: 03starseeker * r42900 10/brlcad/trunk/regress/repository.sh: have repository.sh look in TOPSRC for the INSTALL file too, not just configure.ac. |
| 16:43.55 | CIA-53 | BRL-CAD: 03starseeker * r42901 10/brlcad/trunk/INSTALL: blt is no more |
| 16:44.38 | CIA-53 | BRL-CAD: 03bob1961 * r42902 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Modified ArcherCore::updateRtControl to call rtcntrl's updateControlPanel instead of configuring -size. |
| 16:45.31 | CIA-53 | BRL-CAD: 03starseeker * r42903 10/brlcad/trunk/ (INSTALL configure.ac): It's just tkhtml now |
| 16:47.03 | CIA-53 | BRL-CAD: 03bob1961 * r42904 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added code to remember Archer's window size. |
| 16:48.00 | CIA-53 | BRL-CAD: 03starseeker * r42905 10/brlcad/trunk/INSTALL: tkimg -> tkpng |
| 16:49.41 | brlcad | ``Erik: ah, I see what you're saying about the casts |
| 16:49.52 | CIA-53 | BRL-CAD: 03starseeker * r42906 10/brlcad/trunk/configure.ac: remove togl logic from configure.ac altogether - togl CMake logic is succeeding, and it is unlikely we will go back to do autotools version. |
| 16:49.53 | brlcad | yeah, casting a scanf probably isn't safe |
| 16:50.20 | brlcad | probably need a temp var that can be set to the size_t after the scanf |
| 16:52.00 | brlcad | printing casts should be fine, scanning casts probably not |
| 16:52.08 | brlcad | reviewing now |
| 16:52.30 | CIA-53 | BRL-CAD: 03starseeker * r42907 10/brlcad/trunk/configure.ac: add alias for tktable |
| 16:52.48 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:54.13 | CIA-53 | BRL-CAD: 03starseeker * r42908 10/brlcad/trunk/ (INSTALL configure.ac): add tkpng-build alias |
| 17:01.13 | brlcad | that alias already exists |
| 17:01.15 | brlcad | "tktable-build" |
| 17:01.23 | brlcad | see the comment before |
| 17:01.39 | brlcad | (it's not an alias, it's the actual) |
| 17:01.52 | brlcad | same for tkpng |
| 17:01.57 | starseeker | oh, ok - sorry |
| 17:03.26 | CIA-53 | BRL-CAD: 03starseeker * r42909 10/brlcad/trunk/configure.ac: remove unneeded alias lines |
| 17:10.11 | *** join/#brlcad mafm_ (~mafm@72.Red-83-45-72.dynamicIP.rima-tde.net) | |
| 17:17.42 | CIA-53 | BRL-CAD: 03starseeker * r42910 10/brlcad/trunk/configure.ac: I imagine there are more of these issues, but it looks like rtgl should be a 'with', not an 'enable' in the build logic. |
| 17:20.05 | CIA-53 | BRL-CAD: 03starseeker * r42911 10/brlcad/trunk/INSTALL: remainder of INSTALL documentation options - repository-regress should now succeed. |
| 17:22.29 | CIA-53 | BRL-CAD: 03starseeker * r42912 10/brlcad/branches/cmake/ (5 files in 3 dirs): MFC 42911 |
| 17:35.50 | CIA-53 | BRL-CAD: 03starseeker * r42913 10/brlcad/branches/cmake/regress/CMakeLists.txt: Ah right, DEPENDS can't tell if the target's done anything if it's set up this way - just have regress run 'em all. Regression test fully succeeded. |
| 17:35.52 | starseeker | woo-hoo! |
| 17:35.56 | starseeker | heads in |
| 17:41.09 | dloman | Ice clearing up? |
| 17:42.31 | brlcad | starseeker: awesome, thanks for fixing those! |
| 17:46.13 | brlcad | --enable-* turns compilation of things on/off |
| 17:46.26 | brlcad | s/things/code/ |
| 17:46.53 | brlcad | --with-* turns usage of system components on/off |
| 17:48.02 | brlcad | with/without X11, OpenGL, Mac Frameworks, particular threading types, etc |
| 17:50.09 | brlcad | enable/disable compiling things in our code like building src/other, compilation modes, subcompiles, etc |
| 17:50.46 | brlcad | another way to think of it is --enable/--disable => internal and --with/--without => external |
| 17:53.31 | CIA-53 | BRL-CAD: 03brlcad * r42914 10/brlcad/trunk/configure.ac: rtgl was okay as an --enable flag. enable/disable for inward code selection, with/without for outward system selection. |
| 17:53.50 | ``Erik | mmm, pröst coma |
| 17:54.57 | brlcad | mmm |
| 17:55.26 | brlcad | I need to stop coding and get back to studying soon |
| 18:04.43 | CIA-53 | BRL-CAD: 03erikgreenwald * r42915 10/brlcad/trunk/bench/pixcmp.c: break help message into two strings to bring it under 509 characters (ISO C90) |
| 18:10.39 | CIA-53 | BRL-CAD: 03brlcad * r42916 10/brlcad/trunk/INSTALL: document rtgl and expand the explanation of configuration options to detail what is different between the enable and with options. reword a little for clarity too. |
| 18:11.05 | CIA-53 | BRL-CAD: 03brlcad * r42917 10/brlcad/trunk/configure.ac: comment on rtgl option |
| 18:30.29 | CIA-53 | BRL-CAD: 03brlcad * r42918 10/brlcad/trunk/src/libged/vdraw.c: scanning into a coerced pointer probably isn't a good idea, so revert back down to unsigned long for the scan and upconvert the comparisons accordingly |
| 18:33.07 | CIA-53 | BRL-CAD: 03brlcad * r42919 10/brlcad/trunk/src/libged/wdb_vdraw.c: this duplication of effort really sucks. fix the same size_t uind issues that were in vdraw.c |
| 18:34.50 | brlcad | that should do it, beginning another round of testing |
| 18:36.16 | CIA-53 | BRL-CAD: 03tbrowder2 * r42920 10/brlcad/trunk/HACKING: stick with rough English translation--rest is covered in later parts |
| 18:39.15 | brlcad | mm, crit is full |
| 18:40.05 | ``Erik | in /home ? there's some issue with rsync duping things or something |
| 18:40.21 | brlcad | intentional |
| 18:40.27 | brlcad | not duping, just not deleting |
| 18:40.34 | brlcad | i'm cleaning up some space |
| 18:41.23 | brlcad | easy enough to clear out the big offenders and let them re-rsync later .. checking usage now |
| 18:51.45 | dloman | anything i did? |
| 18:53.17 | *** join/#brlcad Ralith (~ralith@d142-058-094-230.wireless.sfu.ca) | |
| 18:53.18 | ``Erik | nah |
| 18:53.56 | ``Erik | stuff like me doing BRL-CAD builds, people collating/cleaning/deleting irc logs on bz and having dups show up on crit, etc |
| 18:54.45 | ``Erik | the way it's set up, if I go on bz and decide to compress every text file in a directory, crit will have both the compressed and uncompressed ones sitting next to eachother |
| 18:57.11 | CIA-53 | BRL-CAD: 03brlcad * r42921 10/brlcad/trunk/HACKING: |
| 18:57.11 | CIA-53 | BRL-CAD: split the difference. emphasize build breaking and maintainability concern in |
| 18:57.11 | CIA-53 | BRL-CAD: the second point as developer mantra. also, add a brief hint to the first point |
| 18:57.11 | CIA-53 | BRL-CAD: that it's speaking to people's character and the community, not just the code. |
| 18:58.27 | epileg | is there someone working on the creation of rpm package for fedora? |
| 19:02.52 | brlcad | there, lots of space |
| 19:03.11 | brlcad | ``Erik: big offender was a massive core dump that got syncd :) |
| 19:03.58 | brlcad | there's 40GB |
| 19:04.01 | ``Erik | ahhh |
| 19:04.21 | ``Erik | that'd do it |
| 19:05.50 | ``Erik | epileg: I think starseeker tried to set up a fedora image to try to get the spec.in up to date, it's not exactly a priority for us unless someone wants to step up and take care of it |
| 19:06.33 | brlcad | epileg: go for it ;) |
| 19:06.57 | brlcad | sh/make_rpm.sh :D |
| 19:12.59 | epileg | Ok, I'll try, but in rpm systems the situation is different than in debian like ones. They share the same packaging system (rpm), but the package nomenclature is different between distributions. |
| 19:14.25 | epileg | so, the fedora rpm package will be only for fedora, and not installable in opensuse |
| 19:14.37 | ``Erik | starseeker: dm-rtgl is chock full of GLX stuff, allowing it to try to build on winderz won't work |
| 19:16.57 | CIA-53 | BRL-CAD: 03Sean 07http://brlcad.org * r2454 10/wiki/Community_Publication_Portal: update date, still in draft |
| 19:17.50 | brlcad | epileg: ah, interesting -- didn't know that |
| 19:18.32 | brlcad | there can be a --fedora or --generic flag to the script for making the other type |
| 19:19.27 | brlcad | right now, there is no rpm generation whatsoever, so it almost goes without saying that anything you do will be an improvement ;) |
| 19:23.09 | ``Erik | well, brlcad.spec.in and just run rpm -someflag on it, iirc, but it needs write access to like /usr/src/redhat/SOURCES/ and stuff, iirc |
| 19:25.33 | brlcad | so the script is probably a one-liner or maybe few-liner with error-checking on environment assumptions |
| 19:25.49 | brlcad | that's still one line I don't want to memorize :) |
| 19:26.43 | ``Erik | yeh, I built it into a make target a long time ago, um, dunno if it still exists in BRL-CAD, but I can dig it up in other old projects (if it's still even pertinent... I think the spec format changed, that's why starseeker was trying to work on it) |
| 19:34.58 | brlcad | *shrug* |
| 19:35.36 | brlcad | I don't think there's anything in brl-cad any more -- if something doesn't get maintained and can't be verified that it works, I generally yank it so it doesn't slow down the next guy |
| 19:48.59 | ``Erik | misc/brlcad.spec.in is there and it's still in the AC_OUTPUT *shrug* |
| 19:50.33 | CIA-53 | BRL-CAD: 03brlcad * r42922 10/brlcad/trunk/HACKING: set jordi up as the .deb maintainer |
| 19:50.38 | brlcad | but no rpm line hooking it in |
| 19:50.45 | brlcad | just there for those that know what a spec file is |
| 19:51.09 | ``Erik | line 159 of /Makefile.am |
| 19:51.16 | ``Erik | :D |
| 19:51.48 | brlcad | ah, okay very good then |
| 19:51.57 | brlcad | probably should move that up into the make_rpm.sh script |
| 19:52.17 | brlcad | hm, distcheck is not happy on fbsd |
| 19:52.50 | brlcad | apparently its doing a "make distdir" on something in src/other that doesn't have that rule |
| 19:57.25 | starseeker | ``Erik: gaaaahhh. OK. |
| 19:57.33 | starseeker | rtgl is busted anyway |
| 20:03.41 | CIA-53 | BRL-CAD: 03starseeker * r42923 10/brlcad/branches/cmake/CMakeLists.txt: Don't try rtgl unless we've got X11 |
| 20:06.16 | starseeker | grrrrr.... now unistd.h and glxext.h are arguing on my Mac |
| 20:07.10 | starseeker | may be time to upgrade this baby |
| 20:10.43 | brlcad | ``Erik: soo, guess what |
| 20:10.56 | brlcad | I'm upgrading crit to better hardware :) |
| 20:11.16 | brlcad | they're going to attach the current hard drive via USB to the new hardware |
| 20:11.21 | brlcad | should more than double the performance |
| 20:13.12 | ``Erik | hah, cool |
| 20:13.30 | ``Erik | wonders how many hw iterations the 'new server' will go through before migration O:-) |
| 20:14.09 | ``Erik | might try doing "gmake distcheck" instead of "make distcheck"? |
| 20:14.28 | ``Erik | there're still a couple flakey rough spots between bsdmake and auto* |
| 20:18.18 | brlcad | I'm hoping this motivates me since it's in context now |
| 20:18.30 | brlcad | plus hella faster and bigger |
| 20:18.49 | brlcad | less bandwidth, but even .bz will only consume about 50% on average |
| 20:19.22 | brlcad | 1TB disk, dual P4 3.0, 2GB, 100Mbs |
| 20:19.45 | brlcad | 500GB transfer cap |
| 20:20.24 | ``Erik | nice, enough cpu that the load may drop below the number of cores O.O |
| 20:21.17 | ``Erik | and enough memory that it won't be in swapland like bz |
| 20:23.43 | *** join/#brlcad Ralith (~ralith@d142-058-076-096.wireless.sfu.ca) | |
| 20:29.04 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 20:37.01 | *** join/#brlcad Ralith_ (~ralith@d142-058-076-096.wireless.sfu.ca) | |
| 20:46.00 | CIA-53 | BRL-CAD: 03starseeker * r42924 10/brlcad/trunk/ (NEWS src/nirt/command.c): Ow. nirt units command was reporting all unit changes as invalid (even 'm') - this seems to fix it, but someone else should verify. |
| 20:46.41 | CIA-53 | BRL-CAD: 03starseeker * r42925 10/brlcad/trunk/NEWS: # -> * |
| 20:57.54 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 21:08.34 | CIA-53 | BRL-CAD: 03bob1961 * r42926 10/brlcad/trunk/src/ (libged/rect.c libtclcad/ged_obj.c): Call dm_draw_rect() only if grs_draw and grs_line width are not zero. |
| 21:22.36 | brlcad | server transfer under way |
| 21:25.41 | epileg | who's the maintainer of "misc/brlcad.spec.in"? |
| 21:26.19 | brlcad | epileg: "svn log misc/brlcad.spec.in" will say who all has edited the file |
| 21:26.43 | epileg | thanks |
| 21:27.09 | brlcad | starseeker: remember that the last comment is the one that will show up in the configuraiton review report |
| 21:29.05 | brlcad | looks like distcheck and release tests are passing on mac now with only one test needing investigating |
| 21:29.24 | brlcad | fastgen test is reporting "realpath: No such file or directory" several times |
| 21:29.36 | brlcad | followed by a Tcl_Init failure |
| 21:30.13 | starseeker | brlcad: oh, sorry |
| 21:30.32 | brlcad | http://pastebin.mozilla.org/1015503 |
| 21:31.06 | CIA-53 | BRL-CAD: 03starseeker * r42927 10/brlcad/branches/cmake/src/other/step/CMake/SCL_Utils.cmake: Make the SCL install commands more generic |
| 21:31.26 | brlcad | ``Erik: 8.1 is no longer pre-release, stable okay? |
| 21:31.48 | ``Erik | stable is 8.2RC3 right n ow |
| 21:32.01 | ``Erik | once 8.2 comes out, I'll upgrade the system |
| 21:32.12 | ``Erik | so any old 8.x, right? um |
| 21:32.22 | brlcad | crit is presently 8.1-prerelease |
| 21:32.42 | ``Erik | it's running 8.1-prerelease, it has 8.2rc2 installed iirc, I just haven't been rebooting it |
| 21:32.44 | brlcad | you want 8.2RC3 or 8.1 stable? |
| 21:32.54 | brlcad | or doesn't matter |
| 21:32.59 | ``Erik | doesn't matter |
| 21:33.02 | brlcad | k |
| 21:33.28 | ``Erik | we'll upgrade when 8.2 goes stable and lock on that branch for security updates until 8.3 comes out, right? |
| 21:33.39 | starseeker | would be happy never to have to deal with path logic again... |
| 21:33.45 | starseeker | brlcad: that's on a 10.6 mac? |
| 21:33.51 | ``Erik | http://www.freebsd.org/releases/8.2R/schedule.html |
| 21:38.32 | CIA-53 | BRL-CAD: 03starseeker * r42928 10/brlcad/trunk/NEWS: nirt units command was reporting all units as invalid - fixed |
| 21:41.36 | brlcad | starseeker: yes |
| 21:41.58 | starseeker | nevermind, I see it here too. |
| 21:42.02 | starseeker | g_diff is failing |
| 21:42.56 | starseeker | that may be the tclcad_tcl_library() removal |
| 21:44.23 | starseeker | no, wait... |
| 21:44.31 | starseeker | maybe not g_diff... |
| 21:44.47 | brlcad | g_diff probably has its own tcl interpreter |
| 21:45.00 | brlcad | so if a change was made to bwish and mged, might need something there too |
| 21:45.02 | starseeker | it does, but running it in isolation succeeds |
| 21:47.22 | starseeker | ah, there we go |
| 21:47.36 | starseeker | running it from toplevel dir succeeds, not from regress |
| 21:47.40 | starseeker | digs... |
| 21:55.00 | starseeker | that's why... |
| 21:55.05 | brlcad | realpath blather found/fixed |
| 21:55.10 | CIA-53 | BRL-CAD: 03brlcad * r42929 10/brlcad/trunk/src/libbu/brlcad_path.c: there's no need to perror() on realpath failure |
| 21:56.59 | CIA-53 | BRL-CAD: 03starseeker * r42930 10/brlcad/trunk/src/gtools/g_diff.c: By the time g_diff was doing Tcl_FindExecutable, argv[0] referred to the first file supplied and not the executable name. Instead, use the 'invoked_as' string |
| 21:57.00 | starseeker | brlcad: that should do it. |
| 21:57.37 | starseeker | has to go take cats to vet... |
| 21:57.50 | CIA-53 | BRL-CAD: 03brlcad * r42931 10/brlcad/trunk/configure.ac: comment tweak |
| 21:57.55 | brlcad | awesome, thanks! |
| 21:58.13 | brlcad | enjoy your delicious dinner ;) |
| 22:06.22 | brlcad | well now that's really odd |
| 22:07.07 | brlcad | running "../src/gtools/g_diff fastgen_unix.g fastgen_dos.g" stand-alone works, but inside the script with the same pwd it blathers a tcl failure |
| 22:09.46 | brlcad | er... someone changed the fastgen regression script |
| 22:10.37 | brlcad | supposed to create a unix line-ending fastgen conversion, create a dos line-ending fast conversion, and compare the two |
| 22:10.51 | brlcad | it's creating the dos version by simply copying the unix version! |
| 22:11.50 | epileg | @MAJOR_VERSION@, @MINOR_VERSION@ and @PATCH_VERSION@ variables do not change when "misc/brlcad.spec" is created |
| 22:14.10 | brlcad | ahh, my bad .. was reading the script wrong .. turning my internal alarm off |
| 22:15.27 | brlcad | epileg: those don't sound like the right variables |
| 22:15.32 | ``Erik | hm, not being AC_SUBST'd anymore |
| 22:15.33 | brlcad | probably out of date |
| 22:15.50 | epileg | aha |
| 22:15.52 | ``Erik | probably switch the version to @BRLCAD_VERSION@ and the release to '1' or something, or take release out |
| 22:16.46 | epileg | yes. where can i find the variable list? |
| 22:18.06 | ``Erik | configure.ac |
| 22:18.12 | epileg | ok, thanks! |
| 22:18.14 | ``Erik | grep AC_SUBST configure.ac |
| 22:31.30 | CIA-53 | BRL-CAD: 03Sean 07http://brlcad.org * r2455 10/wiki/Community_Publication_Portal: less is more. be briefer. |
| 22:33.05 | CIA-53 | BRL-CAD: 03Sean 07http://brlcad.org * r2456 10/wiki/Community_Publication_Portal: move note down to publication section |
| 22:35.19 | CIA-53 | BRL-CAD: 03Sean 07http://brlcad.org * r2457 10/wiki/Community_Publication_Portal: reduce intro further |
| 23:34.44 | starseeker | growls... worst traffice I think I've ever run into on 22 |
| 23:34.50 | starseeker | missed the appointment |
| 23:35.04 | *** join/#brlcad Ralith (~ralith@d142-058-094-230.wireless.sfu.ca) | |
| 23:36.04 | starseeker | brlcad: it's still failing? that should have fixed it... |
| 23:47.33 | CIA-53 | BRL-CAD: 03starseeker * r42932 10/brlcad/branches/cmake/ (15 files in 9 dirs): MFC r42931 |
| 23:50.26 | CIA-53 | BRL-CAD: 03starseeker * r42933 10/brlcad/branches/cmake/ (. src/other/step/ src/other/tkhtml/): mergeinfo property is annoying, not using it - remove from cmake branch |
| 00:28.45 | brlcad | starseeker: I just finished a clean recompile to test |
| 00:28.48 | brlcad | it's working |
| 00:29.01 | brlcad | the problem is running tcl applications without having installed BRL-CAD first |
| 00:29.21 | brlcad | have to make install BEFORE make test or it'll fail on OS X .. haven't figured out how to fix that yet |
| 00:30.17 | brlcad | it finds the system-installed Tcl at runtime |
| 00:31.37 | starseeker | ah |
| 00:32.21 | starseeker | yeah, I'll usually test in CMake if I'm doing a non-installed trial.. |
| 00:35.03 | brlcad | it should fail in cmake just the same actually unless they modify the LD paths accordingly |
| 00:36.33 | starseeker | I've got some RPATH settings enabled that seem to do wonders |
| 00:37.24 | starseeker | you should give it a try sometime :-P |
| 00:40.08 | brlcad | oh, I believe ya -- another plus if they have better rpath management |
| 00:41.12 | CIA-53 | BRL-CAD: 03brlcad * r42934 10/brlcad/trunk/m4/patch.m4: (log message trimmed) |
| 00:41.13 | CIA-53 | BRL-CAD: sigh, no response from the libtool mailing list on this issue so restore the |
| 00:41.13 | CIA-53 | BRL-CAD: hack that makes libtool binary wrapper scripts work on Mac OS X. we sneak in |
| 00:41.13 | CIA-53 | BRL-CAD: paths to the Tcl/Tk compile-time lib directories so that they'll get |
| 00:41.13 | CIA-53 | BRL-CAD: automatically added to DYLD_LIBRARY_PATH. due to suck in the way temp_rpath is |
| 00:41.13 | CIA-53 | BRL-CAD: handled, the trailing ':' is required otherwise the path will get munged with |
| 00:41.14 | CIA-53 | BRL-CAD: the next pathlist incorrectly. document why this oddity is even in here, why |
| 00:42.50 | starseeker | brlcad: about the --enable-only-benchmark option... does that actively squash other options and turn on just what's needed for the benchmark build? |
| 00:43.04 | starseeker | (also, what's the advantage of that over a normal configure and make benchmark?) |
| 00:45.09 | brlcad | it only enables and builds exactly enough to run the benchmark |
| 00:46.06 | brlcad | greatly shortens the build time (by less than a 10th iirc) |
| 00:46.52 | brlcad | reduces the configure tests and reduces compilation to approximately the minimum |
| 00:47.37 | starseeker | so the configure time is the difference between that and just doing a normal configure + make benchmark? |
| 00:48.55 | brlcad | make benchmark still builds everything, then runs cd bench && make bench |
| 00:49.15 | brlcad | "everything" for an --enable-only-benchmark build is the bare minimum |
| 00:49.26 | brlcad | mged, asc2g, pixcmp, etc |
| 00:49.26 | starseeker | ah. |
| 00:50.00 | starseeker | The CMake build is set up so that a normal configure + make benchmark will build just what is needed for the benchmark and run it - is this an acceptable alternative? |
| 00:50.13 | brlcad | in theory, with cmake you should be able to describe a new benchmark rule that has the proper minimal dependencies |
| 00:50.22 | starseeker | did :-) |
| 00:50.29 | brlcad | yep, that's fine |
| 00:50.34 | starseeker | sweet |
| 00:51.12 | brlcad | the only difference is probably that "make install" would only install the benchmark too :) |
| 00:51.19 | ``Erik | less than 1/10th... before opennurbs? :) |
| 00:51.54 | brlcad | heh, don't know |
| 00:52.13 | starseeker | is betting yes - librt needs opennurbs, which is a large percentage of time |
| 00:52.40 | brlcad | still gets to avoid step dir, half of src/other, hundreds of other utils |
| 00:52.58 | starseeker | true |
| 00:53.00 | ``Erik | um, it blindly does src/conv which has the step stuff, right? |
| 00:53.13 | brlcad | don't recall |
| 00:53.18 | brlcad | it might |
| 00:53.33 | starseeker | well, make benchmark is pretty quick in CMake - that does avoid step |
| 00:53.44 | starseeker | but there's no escaping opennurbs :-P |
| 00:53.57 | brlcad | easy enough for someone to test the difference if it mattered |
| 00:54.20 | brlcad | starseeker: you have rough idea of how long a full build and benchmark-only build take? |
| 00:57.32 | starseeker | with cmake or autotools? |
| 00:57.55 | starseeker | also, benchmark skips all the static libs which makes a big difference |
| 00:58.21 | brlcad | either |
| 00:58.23 | brlcad | both |
| 00:58.29 | brlcad | <PROTECTED> |
| 00:58.29 | brlcad | <PROTECTED> |
| 00:58.52 | brlcad | ouch.. that's a sad v4 flip case |
| 00:59.18 | brlcad | 1 plithy object that failed to validate whether flipped or not causing trouble for everything else |
| 00:59.24 | starseeker | brlcad: let me do some tests... |
| 00:59.31 | starseeker | ouch |
| 00:59.43 | starseeker | that reminds me - does the flip routine handle ars primitives? |
| 01:00.02 | brlcad | I talked to D, that's what I'm looking into |
| 01:01.09 | starseeker | ah, cool |
| 01:03.02 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) | |
| 01:14.14 | starseeker | CMake make -j3 benchmark, from beginning to start of actually running the benchmarks, not including configure time - ~2 minutes, maybe a bit less |
| 01:18.33 | starseeker | hmm - pulled in libpc on autotools... |
| 01:20.57 | starseeker | little over 4 minutes for the same thing with autotools |
| 01:21.24 | starseeker | appears it did not pull in step in either case |
| 01:22.04 | starseeker | both of those times used system libs instead of building local copies |
| 01:32.46 | brlcad | starseeker: technically, librt needs libpc |
| 01:33.13 | starseeker | 8.5 minutes for an autotools build, no docbook |
| 01:33.44 | brlcad | full cmake build takes how long? |
| 01:33.44 | starseeker | brlcad: ah - I haven't set up that dependency in CMake yet - not a problem, just haven't done so yet |
| 01:33.51 | starseeker | trying that next |
| 01:34.00 | starseeker | (usually leave docbook on, messes with numbers) |
| 01:34.10 | brlcad | sure |
| 01:34.57 | CIA-53 | BRL-CAD: 03brlcad * r42935 10/brlcad/trunk/regress/fastgen.sh: add diagnostic 'command prompts' to let you know what the important steps being taken are |
| 01:36.06 | starseeker | again, using system libs for all builds (not enable-all) |
| 01:36.20 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 01:43.34 | starseeker | about 6.5 minutes for the cmake build |
| 01:45.15 | starseeker | so about half the time for a benchmark build (once I throw libpc into the CMake build) |
| 01:46.02 | starseeker | maybe a bit less |
| 01:46.35 | starseeker | actually, the autotools build reports exact time - 8 min, 33 seconds |
| 01:46.49 | starseeker | looks at CMake build... |
| 01:56.02 | starseeker | ah right, only got it going for configure... |
| 01:59.05 | brlcad | you don't calculate compilation time?! :) |
| 02:02.26 | brlcad | perhaps ironic, but I actually think cleanly and clearly reporting build time is very important for a variety of reasons |
| 02:03.55 | brlcad | passive vs active metrics, interface feedback, completion confirmation |
| 02:11.28 | starseeker | brlcad: it's a little tricky... working on it now |
| 02:28.22 | *** join/#brlcad yukonbob (~bch@S0106002129e399fc.ok.shawcable.net) | |
| 02:29.43 | CIA-53 | BRL-CAD: 03brlcad * r42936 10/brlcad/trunk/include/raytrace.h: note the three unused debug bits remaining |
| 02:34.31 | CIA-53 | BRL-CAD: 03brlcad * r42937 10/brlcad/trunk/src/lgt/lgt.h: lgt should not replicate raytrace.h debug values |
| 02:35.42 | CIA-53 | BRL-CAD: 03brlcad * r42938 10/brlcad/trunk/ (include/raytrace.h src/librt/cut.c src/librt/prep.c): rename DEBUG_PLOTSOLIDS and DEBUG_PLOTBOX to DEBUG_PL_SOLIDS and DEBUG_PL_BOX respectively just because it's 1-char shorter and matches nmg.h |
| 02:51.56 | CIA-53 | BRL-CAD: 03brlcad * r42939 10/brlcad/trunk/src/librt/ (db_corrupt.c librt.3): (log message trimmed) |
| 02:51.56 | CIA-53 | BRL-CAD: the user needs SOME mechansim to override automatic behavior in case there is |
| 02:51.56 | CIA-53 | BRL-CAD: some pressing need, so provide for a LIBRT_V4FLIP boolean environment variable. |
| 02:51.56 | CIA-53 | BRL-CAD: if set, the value will be interpreted as an override to enable or disable |
| 02:51.56 | CIA-53 | BRL-CAD: flipping so you can flip a file irrespective of the automatic detection. |
| 02:51.56 | CIA-53 | BRL-CAD: setting the flag to false will revert to old behavior. setting to true will |
| 02:51.57 | CIA-53 | BRL-CAD: flip even if the application provided no override and automatic detection would |
| 02:54.39 | CIA-53 | BRL-CAD: 03starseeker * r42940 10/brlcad/branches/cmake/CMakeLists.txt: Remove the benchmark and rtserver-only options - benchmark is handled by proper dependencies for make benchmark. rtserver will also build minimally due to dependencies. |
| 03:11.09 | CIA-53 | BRL-CAD: 03starseeker * r42941 10/brlcad/branches/cmake/src/CMakeLists.txt: Without the build options for benchmark and framework, the src/CMakeLists.txt logic simplifies down nicely |
| 03:13.58 | CIA-53 | BRL-CAD: 03starseeker * r42942 10/brlcad/branches/cmake/ (4 files in 2 dirs): |
| 03:13.58 | CIA-53 | BRL-CAD: Add a mechanism to print out the compilation time for CMake build. Works only |
| 03:13.58 | CIA-53 | BRL-CAD: for make (e.g. make all) which appears to be consistent with autotools. Summary |
| 03:13.58 | CIA-53 | BRL-CAD: information isn't as elaborate as the autotools output, but that can be added if |
| 03:13.58 | CIA-53 | BRL-CAD: it's needed. |
| 03:14.07 | starseeker | brlcad: there we go |
| 03:48.56 | brlcad | example output? |
| 03:49.25 | brlcad | omg, this is delicious .. |
| 03:49.42 | brlcad | spam musubi |
| 03:49.53 | brlcad | "hawaiian sushi" |
| 04:17.06 | CIA-53 | BRL-CAD: 03brlcad * r42943 10/brlcad/trunk/configure.ac: still having woes with debugging, perhaps the flip was to gstabs+ for 10.4+? |
| 04:52.44 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 05:21.34 | *** join/#brlcad Stattrav (~Stattrav@122.172.33.253) | |
| 05:21.34 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:51.29 | CIA-53 | BRL-CAD: 03Sean 07http://brlcad.org * r2458 10/wiki/Backstaff: backstaff beginnings |
| 06:58.41 | CIA-53 | BRL-CAD: 03brlcad * r42944 10/brlcad/trunk/src/librt/db_open.c: past tense on endianness flippage |
| 07:03.35 | CIA-53 | BRL-CAD: 03brlcad * r42945 10/brlcad/trunk/src/librt/db_corrupt.c: |
| 07:03.35 | CIA-53 | BRL-CAD: be a lot more eager to flip the endian interpretation of v4 files now that |
| 07:03.35 | CIA-53 | BRL-CAD: there's an environment variable override. if we merely detect that it'll help a |
| 07:03.35 | CIA-53 | BRL-CAD: majority of objects, let the flip occur. Moreover, report all objects |
| 07:03.35 | CIA-53 | BRL-CAD: containing matrices that are invalid regardless of flipping since they may just |
| 07:03.35 | CIA-53 | BRL-CAD: actually be invalid. summarize how many objects are like that. |
| 07:13.07 | CIA-53 | BRL-CAD: 03brlcad * r42946 10/brlcad/trunk/TODO: confirmed that ARS has a problem importing because it manages its own b-record serialization of dbfloat_t data. looks like old POLY objects will have a similar problem too. opendb is now fixed. |
| 07:18.59 | CIA-53 | BRL-CAD: 03brlcad * r42947 10/brlcad/trunk/src/librt/primitives/ars/ars.c: there is no reason for rt_ars_rd_curve() to be public api. rename sans rt_ prefix and mark HIDDEN. |
| 07:30.54 | CIA-53 | BRL-CAD: 03brlcad * r42948 10/brlcad/trunk/include/db.h: B_solid records don't actually seem to be used anywhere anymore. should be safe to remove from the union. |
| 07:36.57 | CIA-53 | BRL-CAD: 03brlcad * r42949 10/brlcad/trunk/include/db.h: apparently not true. nothing refers to struct B_solid, but the bspline primitive does refer to and use the B union record. revert. |
| 07:41.20 | CIA-53 | BRL-CAD: 03brlcad * r42950 10/brlcad/trunk/include/db.h: rename the B_resolution confusion starting point as it doesn't look to be actually used (at least by bspline). update comment and name, however, instead of changing the struct size just in case that matters. |
| 07:43.41 | CIA-53 | BRL-CAD: 03brlcad * r42951 10/brlcad/trunk/TODO: that means bsplines won't auto-flip either |
| 08:01.54 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 08:14.51 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 08:22.05 | d_rossberg | starseeker: because of the CMake build: i set BRLCAD_PREFIX to something (in the GUI) but "Prefix:" is empty in the configuration summary |
| 09:07.17 | *** join/#brlcad mafm_ (~mafm@193.153.53.189) | |
| 13:06.05 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:21.28 | starseeker | d_rossberg: you shouldn't need to use BRLCAD_PREFIX for anything anymore |
| 13:21.44 | starseeker | CMAKE_INSTALL_PREFIX should be respected now |
| 13:27.03 | starseeker | brlcad: http://pastebin.mozilla.org/1018272 |
| 13:27.09 | starseeker | very simple right now |
| 13:27.43 | d_rossberg | there is no CMAKE_INSTALL_PREFIX declared, i can't access it via the CMake GUI |
| 13:28.03 | starseeker | um |
| 13:28.11 | starseeker | this is on Windows? |
| 13:29.58 | starseeker | updates his copy on windows to the latest... |
| 13:30.31 | CIA-53 | BRL-CAD: 03d_rossberg * r42952 10/brlcad/trunk/include/common.h: there are unused parameters which are asserted |
| 13:30.45 | d_rossberg | the cmake gui should be similar on all systems |
| 13:31.08 | starseeker | yes, it should |
| 13:31.28 | starseeker | but there is conditional logic for path setup |
| 13:31.49 | starseeker | is checking |
| 13:32.05 | starseeker | I usually run from the command line, so it's possible I missed something |
| 13:32.45 | d_rossberg | following my documentation CMAKE_INSTALL_PREFIX isn't a standard variable but CMAKE_ROOT is |
| 13:35.28 | starseeker | uh... http://www.cmake.org/cmake/help/cmake-2-8-docs.html#variable:CMAKE_INSTALL_PREFIX |
| 13:36.11 | starseeker | am I missing something? |
| 13:36.58 | starseeker | I'm seeing CMAKE_INSTALL_PREFIX as the last entry in my gui here |
| 13:40.54 | CIA-53 | BRL-CAD: 03d_rossberg * r42953 10/brlcad/trunk/src/conv/asc/g2asc.c: |
| 13:40.54 | CIA-53 | BRL-CAD: B_resolution (now B_unused) seams to be unused |
| 13:40.54 | CIA-53 | BRL-CAD: removed it |
| 13:44.13 | d_rossberg | i'm removing all my cache, build etc. files ... |
| 13:44.50 | starseeker | is trying on Windows to see if CMAKE_INSTALL_PREFIX perhaps isn't coming up there |
| 13:49.31 | *** join/#brlcad mafm_ (~mafm@193.153.53.189) | |
| 13:50.40 | CIA-53 | BRL-CAD: 03d_rossberg * r42954 10/brlcad/trunk/misc/win32-msvc/Dll/BrlcadCore.def: removed disappeared function |
| 13:54.04 | starseeker | CMAKE_INSTALL_PREFIX is visible in my Windows setup too |
| 13:57.58 | d_rossberg | now here too, it was probable a problem with an outdated configuration |
| 14:00.36 | starseeker | nods. Yeah, a lot has changed over the past week |
| 14:01.23 | ``Erik | brlcad: did you take crit offline? |
| 14:04.09 | CIA-53 | BRL-CAD: 03starseeker * r42955 10/brlcad/trunk/src/conv/asc/g2asc.c: fix formatting string |
| 14:10.21 | CIA-53 | BRL-CAD: 03erikgreenwald * r42956 10/brlcad/trunk/TODO: The 'freebsd' (actually NDEBUG) strict issues are fixed. The metaball "shelling" bug is, as well. |
| 14:35.17 | CIA-53 | BRL-CAD: 03starseeker * r42957 10/brlcad/branches/cmake/misc/CMake/BRLCAD_Util.cmake: Don't assume -Wno-error will always work, check for it first |
| 14:57.31 | CIA-53 | BRL-CAD: 03starseeker * r42958 10/brlcad/trunk/src/liboptical/sh_toyota.c: Hmm - gamma shadows something in math.h on OSX 10.5, apparently... |
| 15:00.23 | CIA-53 | BRL-CAD: 03starseeker * r42959 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: These ARE used, at least on Windows... |
| 15:04.54 | CIA-53 | BRL-CAD: 03starseeker * r42960 10/brlcad/branches/cmake/ (18 files in 11 dirs): MFC r42959 |
| 15:35.45 | CIA-53 | BRL-CAD: 03starseeker * r42961 10/brlcad/branches/cmake/src/util/CMakeLists.txt: Can't do libpc on MSVC yet, so can't very well test it... |
| 15:44.05 | d_rossberg | starseeker * r42955: ups :{ |
| 15:44.21 | starseeker | np, happens |
| 15:53.10 | brlcad | ``Erik: nope, they did |
| 15:53.19 | brlcad | new server is now online |
| 15:54.07 | brlcad | mounting the drive and working on restoring passwd |
| 15:54.14 | ``Erik | aight |
| 15:54.27 | brlcad | new IP |
| 15:59.54 | ``Erik | going to give it a new name and remove the old one, or update? |
| 16:08.04 | CIA-53 | BRL-CAD: 03bob1961 * r42962 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Remember whether or not to show things like the view axes, model axes, view params, scale etc. |
| 16:10.46 | brlcad | yes :) |
| 16:11.15 | brlcad | just got the drives mounted |
| 16:11.25 | brlcad | letting /home copy now |
| 16:26.05 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 16:55.42 | CIA-53 | BRL-CAD: 03brlcad * r42963 10/brlcad/trunk/src/librt/primitives/ars/ars.c: this brings the ARS online with automatic v4 detection, though not a final solution since htons() will do nothing on other endian. |
| 18:11.59 | CIA-53 | BRL-CAD: 03starseeker * r42964 10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: Do a better job of generalizing the exec search options |
| 18:14.33 | CIA-53 | BRL-CAD: 03starseeker * r42965 10/brlcad/branches/cmake/ (misc/CMake/FindTCL.cmake src/other/togl/CMake/FindTCL.cmake): ws, update togl copy of FindTCL.cmake |
| 18:17.04 | ``Erik | starseeker: that did the trick |
| 18:17.21 | starseeker | cool |
| 18:17.26 | starseeker | is building now |
| 18:32.07 | ``Erik | hm, more failures on fbsd, linux, and osX.6 |
| 18:32.23 | ``Erik | 'src/other/tcl/unix/tclUnixPort.h:91:5: error: "TIME_WITH_SYS_TIME" is not defined' seems common |
| 18:32.38 | starseeker | CMake build or autotools? |
| 18:32.51 | ``Erik | cmkae |
| 18:48.19 | ``Erik | weeee, osX.6 GL.h has // style comments, so ogl fb craps itself with strict flags |
| 18:48.28 | ``Erik | /System/Library/Frameworks/OpenGL.framework/Headers/gl.h:37:1: error: C++ style comments are not allowed in ISO C90 |
| 19:06.20 | CIA-53 | BRL-CAD: 03brlcad * r42966 10/brlcad/trunk/src/libbu/xdr.c: group pairings together. makes it more obvious that bu_glonglong() was never implemented (though there is a macro) but doesn't matter since this is all getting deprecated. |
| 19:06.40 | CIA-53 | BRL-CAD: 03starseeker * r42967 10/brlcad/branches/cmake/misc/CMake/FindGL.cmake: We're not doing aqua based GL in these searches, so let's stay out of the opt/graphics directory and try /usr/X11 |
| 19:10.16 | CIA-53 | BRL-CAD: 03brlcad * r42968 10/brlcad/trunk/ (doc/deprecation.txt include/bu.h): deprecate the old eXternal Data Representation (xdr) API. the byteorder libc functions became IEEE Std POSIX.1-200x (with the exception of the long long pairing?) so set up the migration path. |
| 19:14.14 | CIA-53 | BRL-CAD: 03brlcad * r42969 10/brlcad/trunk/src/librt/primitives/ars/ars.c: note the problem |
| 19:15.38 | brlcad | ``Erik: yeah, that sucks |
| 19:16.11 | brlcad | where are you seeing it? |
| 19:16.29 | brlcad | I updated all of the places that gl.h gets included with ${STD_C99_FLAGS} |
| 19:16.57 | brlcad | that should squash that error |
| 19:17.10 | brlcad | libfb, libdm, and I think mged already have it |
| 19:20.31 | brlcad | ahh, if you're testing cmake build -- starseeker, you'll have to add similar logic |
| 19:21.32 | brlcad | you could actually just set c99 project-wide for cmake build since I'm close to doing that for autotools -- was waiting to squash the few remaining warnings after this release |
| 19:24.01 | ``Erik | osX.6 using cmake, grabbing OpenGL.framework instead of /usr/X11R6/include/GL |
| 19:24.58 | ``Erik | always amusing hearing starseeker use words you never think he'd use :> |
| 19:28.25 | CIA-53 | BRL-CAD: 03starseeker * r42970 10/brlcad/branches/cmake/misc/CMake/FindGL.cmake: Try the CMAKE_FIND_FRAMEWORK variable in FindGL |
| 19:47.17 | ``Erik | brlcad: using htons in ars.c will require winderz to link winsock.dll to librt |
| 19:47.41 | ``Erik | and include Winsock2.h apparently |
| 20:05.45 | CIA-53 | BRL-CAD: 03starseeker * r42971 10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: Need to reset variables if results aren't valid |
| 20:08.50 | ``Erik | (and arpa/inet.h on *nix) |
| 20:26.52 | starseeker | ``Erik: here's why it's crashing: 0x00000001004ea2bb in _X11TransWritev () |
| 20:29.09 | starseeker | ah, there's no escape - /usr/X11R6/include/GL/gl.h includes the framework gl.h |
| 20:31.06 | starseeker | that's trying to display mac to mac |
| 20:31.20 | starseeker | mac to Linux, wish itself gives up with a bad atom |
| 20:40.35 | brlcad | ``Erik: that htons is not going to stay there |
| 20:40.59 | brlcad | working on replacing that with something that'll actually work on big endian systems |
| 20:44.22 | CIA-53 | BRL-CAD: 03brlcad * r42972 10/brlcad/trunk/src/librt/primitives/ars/ars.c: switch over to the xdr functions while the FIXME is being fixed so that we don't have windows build fail. don't want to hook up winsock for windows. |
| 21:14.08 | starseeker | ``Erik: odd... runs on Windows for me here (VC++2010) |
| 21:32.50 | brlcad | ``Erik: loads of reallocated sectors on the old filesystem .. apparently a bad or failing drive? |
| 21:32.58 | brlcad | they're attempting a clone/recovery now |
| 21:33.38 | brlcad | it stalled hard 22GB into the restore earlier today and had to go diagnosing |
| 21:43.07 | ``Erik | old fs? on crit or bz? bz was falling apart hardcore |
| 21:43.08 | ``Erik | is |
| 21:43.17 | CIA-53 | BRL-CAD: 03erikgreenwald * r42973 10/brlcad/branches/cmake/src/other/tcl/ (5 files in 2 dirs): regex.h -> regextcl.h to avoid fighting with /usr/include/regex.h |
| 22:09.59 | CIA-53 | BRL-CAD: 03brlcad * r42974 10/brlcad/trunk/src/libbu/convert.c: |
| 22:09.59 | CIA-53 | BRL-CAD: address FIXME, make cv() be public API, so rename to bu_cv(). provides a |
| 22:09.59 | CIA-53 | BRL-CAD: simplified API means for converting between two specified formats, e.g. htons() |
| 22:09.59 | CIA-53 | BRL-CAD: would be something like bu_cv(outbuf, "nss", sizeof(short), val, "hss", 1); |
| 22:10.17 | CIA-53 | BRL-CAD: 03brlcad * r42975 10/brlcad/trunk/include/bu.h: expose the new bu_cv() function. |
| 22:15.30 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 22:27.33 | CIA-53 | BRL-CAD: 03brlcad * r42976 10/brlcad/trunk/src/libbu/convert.c: no longer vert.c |
| 22:39.42 | CIA-53 | BRL-CAD: 03starseeker * r42977 10/brlcad/branches/cmake/src/other/togl/src/CMakeLists.txt: Install the headers as well |
| 22:45.30 | *** join/#brlcad mafm_ (~mafm@203.Red-88-22-160.staticIP.rima-tde.net) | |
| 23:04.38 | CIA-53 | BRL-CAD: 03brlcad * r42978 10/brlcad/trunk/src/librt/db_float.c: implement a simple flip_short() routine for flipping the bytes of a short. htons() isn't suitable because it won't flip bytes if host endain is network (i.e. big endian). this is private API. |
| 23:05.44 | CIA-53 | BRL-CAD: 03brlcad * r42979 10/brlcad/trunk/src/librt/ (Makefile.am librt_private.h): add a new private header, librt_private.h, so we can have a common header for providing functions that can be used within librt but that shouldn't be public API. |
| 23:09.04 | CIA-53 | BRL-CAD: 03brlcad * r42980 10/brlcad/trunk/src/librt/db_float.c: prepare for a rename to db_flip.c |
| 23:10.50 | CIA-53 | BRL-CAD: 03brlcad * r42981 10/brlcad/trunk/ (5 files in 2 dirs): rename from db_float.c to db_flip.c since the file is being expanded with a few more flip functions that have nothing to do with floats |
| 23:16.41 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 23:25.34 | CIA-53 | BRL-CAD: 03starseeker * r42982 10/brlcad/branches/cmake/src/other/togl/ (12 files in 5 dirs): Let's see if glew can handle some of the cross platform annoyances |
| 23:28.51 | CIA-53 | BRL-CAD: 03starseeker * r42983 10/brlcad/branches/cmake/CMakeLists.txt: Turn Tk X11 requirement on if appropriate |
| 23:41.43 | starseeker | ``Erik: hmm: http://www.geodynamics.org/pipermail/cig-commits/2010-March/011594.html |
| 23:52.19 | starseeker | ``Erik: here's a backtrace, if that helps: http://pastebin.mozilla.org/1020171 |
| 23:57.06 | CIA-53 | BRL-CAD: 03brlcad * r42984 10/brlcad/trunk/src/librt/primitives/ars/ars.c: |
| 23:57.06 | CIA-53 | BRL-CAD: this should fix interpretation for both big and little endian platforms. if |
| 23:57.06 | CIA-53 | BRL-CAD: flipping is requested, we need to flip the bytes regardless of host/network |
| 23:57.06 | CIA-53 | BRL-CAD: endianness. call the new private flip_short() function from db_flip.c |
| 00:12.54 | CIA-53 | BRL-CAD: 03starseeker * r42985 10/brlcad/branches/cmake/ (CMakeLists.txt src/libbu/brlcad_path.c src/libbu/simd.c): Turn on C99 for CMake, plus two related tweaks |
| 00:16.12 | brlcad | brlcad_path.c fix isn't right |
| 00:17.34 | CIA-53 | BRL-CAD: 03brlcad * r42986 10/brlcad/trunk/src/libbu/brlcad_path.c: convert to an integer expression |
| 00:20.50 | CIA-53 | BRL-CAD: 03starseeker * r42987 10/brlcad/branches/cmake/src/libbu/brlcad_path.c: Grab proper fix for brlcad_path from trunk |
| 00:20.56 | starseeker | my this is depressing: http://yro.slashdot.org/story/11/02/03/2044211/NC-Official-Sics-License-Police-On-Computer-Scientist-For-Too-Good-a-Complaint |
| 00:33.50 | brlcad | heh, and someone naturally posts his phone number, e-mail, and web link to a complaint form. outstanding smack back expected. |
| 01:13.04 | CIA-53 | BRL-CAD: 03jordisayol * r42988 10/brlcad/trunk/sh/ (make_deb.sh make_rpm.sh): |
| 01:13.04 | CIA-53 | BRL-CAD: added the option to create Fedora binary rpm files |
| 01:13.04 | CIA-53 | BRL-CAD: minor changes on deb creation |
| 01:14.17 | CIA-53 | BRL-CAD: 03starseeker * r42989 10/brlcad/branches/cmake/CMakeLists.txt: Not ready for C99 yet - variety of failures on Linux. Will need to rework this to apply C99 only to C files of BRL-CAD targets. |
| 01:27.33 | CIA-53 | BRL-CAD: 03brlcad * r42990 10/brlcad/trunk/src/librt/librt_private.h: make the header safe for c++ compilation units too |
| 01:30.12 | CIA-53 | BRL-CAD: 03brlcad * r42991 10/brlcad/trunk/src/librt/primitives/bspline/bspline.cpp: add support for importing binary-incompatible v4 bspline objects. this flips all short record data values but still leaves the trailing dbfloat arrays that have no record id. |
| 02:16.32 | CIA-53 | BRL-CAD: 03brlcad * r42992 10/brlcad/trunk/src/librt/ (db_flip.c librt_private.h): const on an intrinsic value is meaningless |
| 02:29.24 | CIA-53 | BRL-CAD: 03brlcad * r42993 10/brlcad/trunk/src/librt/ (db_flip.c librt_private.h): implement flipping of single dbfloats (similar to rt_fastf_float but that one assumes triplets) |
| 02:30.00 | CIA-53 | BRL-CAD: 03brlcad * r42994 10/brlcad/trunk/src/librt/primitives/bspline/bspline.cpp: flip the first of two data arrays that trail after a bspline surface record |
| 02:55.25 | CIA-53 | BRL-CAD: 03brlcad * r42995 10/brlcad/trunk/src/librt/db_flip.c: utilize flip_dbfloat() within to reduce the other functions substantially |
| 03:21.27 | starseeker | blinks - in if_ogl.c with C99, ipc.h is asking for either _SVID_SOURCE or _XOPEN_SOURCE |
| 03:21.43 | starseeker | also, error: implicit declaration of function ‘getpagesize’ |
| 03:22.08 | starseeker | (have to check if they're CMake problems, I suppose...) |
| 05:12.03 | brlcad | http://www.ehow.com/how_7870235_build-blueprint-software.html |
| 05:12.17 | brlcad | that is just fscking ridiculous funny |
| 05:12.37 | brlcad | just whip up some pseudocode, that's all it takes |
| 05:33.22 | CIA-53 | BRL-CAD: 03brlcad * r42996 10/brlcad/trunk/src/librt/primitives/bspline/bspline.cpp: and with this, bspline conversion should be complete. untested, though, because I don't have a sample corrupt v4 with a bspline. |
| 05:55.14 | CIA-53 | BRL-CAD: 03brlcad * r42997 10/brlcad/trunk/src/librt/primitives/ehy/ehy.c: fix comment |
| 06:23.05 | CIA-53 | BRL-CAD: 03brlcad * r42998 10/brlcad/trunk/src/librt/primitives/ehy/ehy.c: looks like a few other rarely used primitives might need some help too. more v4 conversion support sans testing due to lack of sample geometry. |
| 06:29.10 | CIA-53 | BRL-CAD: 03brlcad * r42999 10/brlcad/trunk/src/librt/primitives/epa/epa.c: v4 conversion support for epa |
| 06:33.14 | CIA-53 | BRL-CAD: 03brlcad * r43000 10/brlcad/trunk/src/librt/primitives/eto/eto.c: v4 conversion support for eto |
| 06:37.16 | CIA-53 | BRL-CAD: 03brlcad * r43001 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: fix copy-paste typo |
| 06:39.13 | CIA-53 | BRL-CAD: 03brlcad * r43002 10/brlcad/trunk/src/librt/primitives/rhc/rhc.c: v4 conversion support for rhc |
| 06:39.58 | CIA-53 | BRL-CAD: 03brlcad * r43003 10/brlcad/trunk/TODO: down to just poly |
| 06:42.27 | CIA-53 | BRL-CAD: 03brlcad * r43004 10/brlcad/trunk/src/librt/primitives/rpc/rpc.c: v4 conversion support for rpc |
| 06:44.11 | CIA-53 | BRL-CAD: 03brlcad * r43005 10/brlcad/trunk/src/librt/primitives/sph/sph.c: remove dead code |
| 06:45.39 | CIA-53 | BRL-CAD: 03brlcad * r43006 10/brlcad/trunk/src/librt/primitives/submodel/submodel.c: more dead code |
| 06:48.24 | CIA-53 | BRL-CAD: 03brlcad * r43007 10/brlcad/trunk/src/librt/primitives/superell/superell.c: not bloody likely there are any v4 super ellipsoids, but go ahead and fix the two parameters that weren't being serialized properly anyways |
| 07:00.24 | CIA-53 | BRL-CAD: 03brlcad * r43008 10/brlcad/trunk/src/librt/primitives/poly/poly.c: aaaand, this should be the last solid. add support for v4 conversion of polysolids |
| 07:02.45 | CIA-53 | BRL-CAD: 03brlcad * r43009 10/brlcad/trunk/src/librt/primitives/ (ars/ars.c bspline/bspline.cpp ehy/ehy.c epa/epa.c): didn't catch this until part-way through. private headers should be relative references (src/librt should not be on search path). |
| 07:06.39 | CIA-53 | BRL-CAD: 03brlcad * r43010 10/brlcad/trunk/TODO: should be good to go! beginnning final round of distchecking and testing. |
| 07:12.27 | CIA-53 | BRL-CAD: 03brlcad * r43011 10/brlcad/trunk/src/librt/comb/db_comb.c: fix region ids, air codes, material ids, and line of sight values so they'll open via corrupt v4 flippage too |
| 07:13.21 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 07:16.45 | CIA-53 | BRL-CAD: 03brlcad * r43012 10/brlcad/trunk/src/librt/db_scan.c: material records have high/low shorts that need to be accounted for |
| 07:51.10 | *** join/#brlcad yukonbob1 (~bch@20-144.wireless.kamloops.net) | |
| 08:30.31 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 10:35.34 | *** join/#brlcad ibot (ibot@rikers.org) | |
| 10:35.34 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202) | |
| 11:00.32 | *** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 12:37.20 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:03.07 | starseeker | d_rossberg: on what platform? They should turn on by default if not detected |
| 13:13.26 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 13:40.01 | starseeker | d_rossberg: what variable specifically are you looking for? |
| 13:54.55 | CIA-53 | BRL-CAD: 03brlcad * r43013 10/brlcad/trunk/src/librt/comb/db_comb.c: missing header |
| 15:59.59 | *** join/#brlcad ibot (ibot@rikers.org) | |
| 15:59.59 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202) | |
| 16:28.32 | CIA-53 | BRL-CAD: 03jordisayol * r43021 10/brlcad/trunk/ (5 files in 2 dirs): update desktop on install/remove scripts. changes deb/rpm description |
| 17:31.28 | epileg | I've created and uploaded 2 tested Fedora rpm packages at: |
| 17:31.28 | epileg | http://code.google.com/p/brl-cad-packages/downloads/list |
| 17:31.28 | epileg | You can to upload to sourceforge, if You want. |
| 18:21.29 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 18:36.50 | CIA-53 | BRL-CAD: 03brlcad * r43022 10/brlcad/trunk/misc/debian/ (brlcad.postinst brlcad.postrm brlcad.sh): use text/x-sh instead of application/x-shellscript for shell script mime types so that subversion will calculate text diffs |
| 18:37.26 | brlcad | epileg: awesome |
| 18:37.54 | brlcad | epileg: try to use text/* mime types when you add new files if they're text files, otherwise they'll get processed as binary files |
| 18:38.12 | brlcad | text/plain text/xml text/x-sh all pretty common |
| 18:38.56 | brlcad | there's no utility in setting a binary mime-type; especially if it's something readable by a text editor |
| 19:07.29 | epileg | sorry, just i add the exactly same mime type that linux report |
| 19:07.37 | epileg | did you correct this? |
| 19:08.12 | epileg | hmmmm, yes...... :-/ |
| 19:24.03 | CIA-53 | BRL-CAD: 03brlcad * r43023 10/brlcad/trunk/src/ (librt/db_open.c mged/mged.c): let the user know that the database was intentionally converted to read-only. not a permissions issue. mixed encoding would be very bad. |
| 19:25.22 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 19:45.15 | CIA-53 | BRL-CAD: 03brlcad * r43024 10/brlcad/trunk/include/ged.h: add some rather old high-level whiteboard data structure notes on a simple organization for libged. |
| 19:45.36 | brlcad | epileg: yeah, I realize that -- not a problem, just not a useful mime type for revision control |
| 19:47.15 | epileg | well, there are some other binary mime type files that are really text, from my other day commit |
| 19:47.24 | epileg | I'll check all of them |
| 19:49.23 | CIA-53 | BRL-CAD: 03davidloman * r43025 10/rt^3/trunk/tests/GS/GeometryServiceTest.cxx: More remnants of work that are attempts in getting the test harness working with the gs libs. |
| 19:52.30 | *** join/#brlcad mafm (~mafm@115.Red-81-32-105.dynamicIP.rima-tde.net) | |
| 20:00.53 | *** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de) | |
| 20:30.32 | CIA-53 | BRL-CAD: 03bob1961 * r43026 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added an fbclear command. |
| 20:59.38 | ``Erik | http://www.youtube.com/watch?v=67tNwTtH0qE |
| 21:00.10 | epileg | ``Erik: can You help me please? |
| 21:12.17 | epileg | I've a problem, I try to upload two new rpm files to sourceforge, but my firefox frozen during the process, and now the files are downloadable but with less than HALF size!!! |
| 21:12.53 | epileg | how do I proceed? |
| 21:26.06 | ``Erik | can you delete them? |
| 21:28.07 | epileg | Yes, i can, but brlcad tell me that Is almost forbidden to delete files, and now I do not now what to do. |
| 21:28.34 | ``Erik | a partial upload would need to be deleted and re-uploaded |
| 21:29.09 | epileg | Are You sure that this is the correct procedure? |
| 21:30.34 | ``Erik | reasonably |
| 21:31.12 | epileg | I'm a bit stressed right now, and I don't wan to make something wrong. Hope You understand me |
| 21:31.52 | ``Erik | yeh, I getcha, I'd delete them but I'm having some computer issues at the moment |
| 21:32.11 | ``Erik | if you have a pointy stick, you can jab brlcad until he helps? :D |
| 21:33.30 | epileg | ok, answer from Sean, I can delete them. puffffff |
| 21:35.57 | epileg | thank a lot ``Erik ;-) |
| 21:40.45 | CIA-53 | BRL-CAD: 03erikgreenwald * r43027 10/brlcad/trunk/src/bwish/main.c: verify the ::itcl namespace exists before trying to delete it. |
| 22:06.24 | CIA-53 | BRL-CAD: 03erikgreenwald * r43028 10/brlcad/trunk/src/libfb/if_ogl.c: __BSD_VISIBLE has to be before sys/types.h |
| 22:15.08 | starseeker | ``Erik: nice |
| 22:19.55 | CIA-53 | BRL-CAD: 03erikgreenwald * r43029 10/brlcad/trunk/src/mged/setup.c: verify the ::itcl namespace exists before trying to delete it. |
| 22:22.53 | ``Erik | hm, archer issues, but ah surpose that can wait |
| 22:23.00 | starseeker | it's possible that the package require failure is nicer about cleanup than the old C call to Itcl |
| 22:23.07 | starseeker | ``Erik: what issues? |
| 22:24.12 | ``Erik | http://paste.lisp.org/display/119385 |
| 22:24.37 | ``Erik | on fbsd, installed to /usr/brlcad/HEAD with ln -s /usr/brlcad/HEAD/* /usr/brlcad/ |
| 22:25.01 | starseeker | hmmm |
| 22:25.12 | starseeker | CMake or trunk? |
| 22:26.37 | ``Erik | trunk |
| 22:26.44 | starseeker | sounds like it's not finding the archer tcl scripts |
| 22:27.02 | ``Erik | yeah, there was a dialog that said unable to find plugins or something |
| 22:27.03 | starseeker | hopes like heck it's not yet another bu_brlcad_data problem... |
| 22:27.20 | ``Erik | *shrug* time to head home, though... hasta |
| 22:27.25 | starseeker | later |
| 22:32.34 | CIA-53 | BRL-CAD: 03starseeker * r43030 10/brlcad/branches/cmake/ (14 files in 9 dirs): MFC 43029 |
| 23:31.47 | *** join/#brlcad ibot (ibot@rikers.org) | |
| 23:31.47 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202) | |
| 01:04.13 | CIA-53 | BRL-CAD: 03starseeker * r43031 10/brlcad/branches/cmake/misc/CMake/test_srcs/builddelta_end.c.in: Eh, why not. Make the CMake build summary match the autotools printout. |
| 01:44.55 | starseeker | brlcad: there is a bit of a philosophical issue with CPack vs the dist logic - CPack just packs whatever is in the source tree into the source tarball, except for what you tell it to exclude. The autotools build lists every file that is supposed to be included |
| 01:45.41 | starseeker | to me, this looks like a consequence of autotools not doing a fully clean out-of-directory build, or rather allowing an in-source-tree build that also generates a clean tarball |
| 01:46.57 | starseeker | wouldn't it be cleaner to just go with the separate build directory and allow the source tarball generation to just pack the source tree? |
| 05:53.10 | *** join/#brlcad ibot (ibot@rikers.org) | |
| 05:53.10 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202) | |
| 08:52.30 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 09:51.57 | *** join/#brlcad mafm (~mafm@85.Red-83-38-35.dynamicIP.rima-tde.net) | |
| 12:26.22 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 14:58.56 | CIA-53 | BRL-CAD: 03starseeker * r43036 10/brlcad/branches/cmake/bench/CMakeLists.txt: Tack on 'how to clean' message to benchmark output |
| 15:07.41 | CIA-53 | BRL-CAD: 03starseeker * r43037 10/brlcad/branches/cmake/CMakeLists.txt: Try adding the benchmark to distcheck |
| 15:21.19 | starseeker | oh, I see now... files added to the repository but not added to the build logic... |
| 15:21.23 | starseeker | hrm |
| 15:25.34 | CIA-53 | BRL-CAD: 03starseeker * r43038 10/brlcad/branches/cmake/CMakeLists.txt: Whoops, tell it to run |
| 15:26.27 | starseeker | accidents like new .tcl scripts not being copied, that logic avoids those issues... |
| 15:26.35 | starseeker | ho boy |
| 15:26.39 | starseeker | starts thinking |
| 16:42.25 | *** join/#brlcad WhiteCalf (~MK@whitecalf.net) | |
| 22:59.42 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 01:21.50 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 04:01.39 | *** join/#brlcad DX^ (~DX@c-71-59-50-121.hsd1.ga.comcast.net) | |
| 04:37.33 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 14:40.01 | *** join/#brlcad Elrohir (~kvirc@p5B149628.dip.t-dialin.net) | |
| 14:48.52 | CIA-53 | BRL-CAD: 03starseeker * r43039 10/brlcad/branches/cmake/ (CMakeLists.txt misc/CMake/distcheck_buildsys.cmake.in): |
| 14:48.53 | CIA-53 | BRL-CAD: First steps towards a comprehensive system to check for files missing from the |
| 14:48.53 | CIA-53 | BRL-CAD: build logic. Still quite a lot to do here, and even when the system is fully in |
| 14:48.53 | CIA-53 | BRL-CAD: place have to go back and list all the stuff not referred to now (what in |
| 14:48.53 | CIA-53 | BRL-CAD: autotools would be the EXTRA_DIST entries) |
| 15:28.33 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 16:24.25 | CIA-53 | BRL-CAD: 03starseeker * r43040 10/brlcad/branches/cmake/ (7 files in 6 dirs): |
| 16:24.26 | CIA-53 | BRL-CAD: Add more of the machinery for distcheck file checking - modify macros, add |
| 16:24.26 | CIA-53 | BRL-CAD: specific macros for ignoring things not otherwise covered by macros or build |
| 16:24.26 | CIA-53 | BRL-CAD: logic. Fail in distcheck if an ignored file is represented elsewhere in the |
| 16:24.26 | CIA-53 | BRL-CAD: build logic - may indicate a previously unused file is now in use and shouldn't |
| 16:24.26 | CIA-53 | BRL-CAD: be ignored any longer. |
| 16:27.12 | *** join/#brlcad Guest66717 (~peppe@host101-161-dynamic.10-87-r.retail.telecomitalia.it) | |
| 16:29.47 | CIA-53 | BRL-CAD: 03starseeker * r43041 10/brlcad/branches/cmake/misc/CMake/BRLCAD_Util.cmake: Don't allow ignoring of files that don't exist - enforces a 'no clutter' policy |
| 18:42.29 | CIA-53 | BRL-CAD: 0370.239.88.156 07http://brlcad.org * r2459 10/wiki/STEP: /* Existing Open Source Tools */ - add NIST/NASA/ESA info |
| 18:43.34 | CIA-53 | BRL-CAD: 0370.239.88.156 07http://brlcad.org * r2460 10/wiki/STEP: /* These tools generate C++ from an EXPRESS schema */ |
| 18:45.57 | CIA-53 | BRL-CAD: 0370.239.88.156 07http://brlcad.org * r2461 10/wiki/STEP: /* Existing Open Source Tools */ |
| 18:57.06 | CIA-53 | BRL-CAD: 03starseeker * r43042 10/brlcad/branches/cmake/ (6 files in 6 dirs): Take things one step further - if a CMakeLists.txt file is including files from subdirectories, scanning those subdirectories for un-accounted-for files becomes the responsibility of that CMakeLists.txt file. |
| 18:58.49 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 19:04.56 | CIA-53 | BRL-CAD: 03starseeker * r43043 10/brlcad/branches/cmake/misc/CMake/ (BRLCAD_Util.cmake distcheck_buildsys.cmake.in): tweaks, remove debug printing |
| 19:38.20 | CIA-53 | BRL-CAD: 03starseeker * r43044 10/brlcad/branches/cmake/ (4 files in 3 dirs): Start the slog of listing files. cheat a little with iwidgets - use the macro even though it's in src/other, otherwise it's totally ignored by the system. |
| 20:26.20 | CIA-53 | BRL-CAD: 03starseeker * r43045 10/brlcad/branches/cmake/src/other/CMakeLists.txt: First pass at setting up src/other. Probably should separate out this file into various .cmake files that are included, just to improve readibility. |
| 20:53.38 | CIA-53 | BRL-CAD: 03jordisayol * r43046 10/brlcad/trunk/misc/debian/application-x-brlcad-extension.xml: changed mime type from binary to text |
| 21:38.44 | CIA-53 | BRL-CAD: 03starseeker * r43047 10/brlcad/branches/cmake/ (59 files in 58 dirs): Not perfect, but demonstrates a working mechanism to spot files present in the source tree but not accounted for in CMakeLists.txt files. |
| 21:51.14 | CIA-53 | BRL-CAD: 03starseeker * r43048 10/brlcad/branches/cmake/misc/CMake/distcheck_buildsys.cmake.in: Flesh out the error message a little more - make it fatal now. |
| 21:53.04 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 21:57.54 | CIA-53 | BRL-CAD: 03starseeker * r43049 10/brlcad/branches/cmake/CMakeLists.txt: Add some cleanup to the distcheck target |
| 22:34.08 | CIA-53 | BRL-CAD: 03starseeker * r43050 10/brlcad/branches/cmake/CMakeLists.txt: Clean up benchmark, add printout for successful distcheck. |
| 22:34.48 | CIA-53 | BRL-CAD: 03starseeker * r43051 10/brlcad/branches/cmake/misc/CMake/distcheck_success_message.cmake.in: Whoops, add the cmake file. |
| 22:42.30 | CIA-53 | BRL-CAD: 03starseeker * r43052 10/brlcad/branches/cmake/CMakeLists.txt: Whoops - install, not build for this test. |
| 22:50.43 | CIA-53 | BRL-CAD: 03starseeker * r43053 10/brlcad/branches/cmake/CMakeLists.txt: It's a better test if the install directory is on its own. |
| 23:05.41 | CIA-53 | BRL-CAD: 03starseeker * r43054 10/brlcad/branches/cmake/ (CMakeLists.txt misc/CMake/svncheck.cmake): More tweaks |
| 23:31.37 | *** join/#brlcad ibot (ibot@rikers.org) | |
| 23:31.37 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202) | |
| 23:36.12 | CIA-53 | BRL-CAD: 03starseeker * r43055 10/brlcad/branches/cmake/ (CMakeLists.txt misc/CMake/distcheck_buildsys.cmake.in): Ah, toplevel directory was escaping. Probably a cleaner way to do this, but this will work. |
| 23:37.17 | *** join/#brlcad roberthl (~robert@v001.rhl.me.uk) | |
| 23:37.17 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 23:59.01 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 00:10.08 | *** join/#brlcad roberthl (~robert@v001.rhl.me.uk) | |
| 00:10.09 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 01:14.44 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) | |
| 02:50.34 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) | |
| 03:33.24 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) | |
| 03:44.22 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) | |
| 04:22.42 | CIA-53 | BRL-CAD: 03starseeker * r43056 10/brlcad/branches/cmake/ (3 files in 2 dirs): Nevermind the ignore thing for now - it's of questionable use and a complication |
| 04:23.55 | CIA-53 | BRL-CAD: 03starseeker * r43057 10/brlcad/branches/cmake/misc/CMake/distcheck_buildsys.cmake.in: More simplification |
| 04:29.29 | CIA-53 | BRL-CAD: 03starseeker * r43058 10/brlcad/branches/cmake/misc/CMake/distcheck_buildsys.cmake.in: Whoops, don't break the logic in the process... |
| 05:06.06 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 11:26.28 | CIA-53 | BRL-CAD: 03davidloman * r43059 10/rt^3/trunk/src/other/sqlite_3_7_4/: Added the sqlite .so to svn:ignore. |
| 11:27.18 | dloman | Mernin all! |
| 12:05.09 | starseeker | dloman: morning! |
| 12:13.35 | CIA-53 | BRL-CAD: 03starseeker * r43060 10/brlcad/branches/cmake/ (CMakeLists.txt src/other/CMakeLists.txt): Tweak settings for Jove |
| 12:24.19 | CIA-53 | BRL-CAD: 03starseeker * r43061 10/brlcad/branches/cmake/src/libfb/CMakeLists.txt: Conditionalize building of specific if_* files on build settings. |
| 12:27.08 | starseeker | brlcad: have you tried building lately without X11 enabled? I'm seeing some warnings in libfb about unused parameters, which I think are due to all the code being conditionalized out by the IF_* wrappers not being turned on |
| 12:34.10 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 12:35.39 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:38.02 | CIA-53 | BRL-CAD: 03starseeker * r43062 10/brlcad/branches/cmake/src/libdm/CMakeLists.txt: Same deal with libdm - don't build files we don't need |
| 12:49.19 | CIA-53 | BRL-CAD: 03starseeker * r43063 10/brlcad/branches/cmake/src/other/CMakeLists.txt: If we aren't using Tk, then as far as C is concerned we don't have it. |
| 12:50.22 | CIA-53 | BRL-CAD: 03starseeker * r43064 10/brlcad/branches/cmake/src/mged/attach.c: Without the tk.h header, Tk_GenericProc isn't a valid type - wrap in ifdef. This lets mged compile without any display manager (except nu) or gui |
| 12:53.28 | CIA-53 | BRL-CAD: 03starseeker * r43065 10/brlcad/branches/cmake/db/CMakeLists.txt: Respect the BRLCAD-INSTALL_EXAMPLE_GEOMETRY flag |
| 13:04.34 | CIA-53 | BRL-CAD: 03starseeker * r43066 10/brlcad/branches/cmake/TODO.cmake: Update TODO.cmake |
| 13:54.08 | CIA-53 | BRL-CAD: 03starseeker * r43067 10/brlcad/branches/cmake/configure.cmake.sh: Add beginnings of simple wrapper to allow '../configure --stuff' invocation of CMake configure process. |
| 14:05.58 | CIA-53 | BRL-CAD: 03davidloman * r43068 10/rt^3/trunk/cmake/ (7 files): First round of year 2010 to 2011 text updates. Will be in a series of commits because, for some reason, one large commit seems to continually fail. |
| 14:07.04 | CIA-53 | BRL-CAD: 03davidloman * r43069 10/rt^3/trunk/ (CMakeLists.txt COPYING tests/CMakeLists.txt): Continuing year 2010 to 2011 text updates. |
| 14:10.42 | CIA-53 | BRL-CAD: 03davidloman * r43070 10/rt^3/trunk/tests/ (15 files in 4 dirs): Continuing year 2010 to 2011 text updates. |
| 14:11.42 | CIA-53 | BRL-CAD: 03davidloman * r43071 10/rt^3/trunk/tests/ (8 files in 4 dirs): Continuing year 2010 to 2011 text updates. |
| 14:15.10 | CIA-53 | BRL-CAD: 03davidloman * r43072 10/rt^3/trunk/ (6 files in 2 dirs): Continuing year 2010 to 2011 text updates. |
| 14:18.16 | CIA-53 | BRL-CAD: 03davidloman * r43073 10/rt^3/trunk/m4/ (9 files): Continuing year 2010 to 2011 text updates. |
| 14:20.37 | CIA-53 | BRL-CAD: 03davidloman * r43074 10/rt^3/trunk/include/brlcad/ (20 files): Continuing year 2010 to 2011 text updates. |
| 14:21.41 | CIA-53 | BRL-CAD: 03davidloman * r43075 10/rt^3/trunk/include/ (21 files): Continuing year 2010 to 2011 text updates. |
| 14:41.37 | CIA-53 | BRL-CAD: 03davidloman * r43076 10/rt^3/trunk/include/ (18 files): Continuing year 2010 to 2011 text updates. |
| 14:44.27 | CIA-53 | BRL-CAD: 03davidloman * r43077 10/rt^3/trunk/include/ (29 files): Continuing year 2010 to 2011 text updates. |
| 14:47.38 | CIA-53 | BRL-CAD: 03davidloman * r43078 10/rt^3/trunk/ (9 files in 2 dirs): Continuing year 2010 to 2011 text updates. |
| 14:51.35 | CIA-53 | BRL-CAD: 03davidloman * r43079 10/rt^3/trunk/src/ (133 files in 13 dirs): Continuing year 2010 to 2011 text updates. |
| 14:55.19 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 15:02.41 | CIA-53 | BRL-CAD: 03davidloman * r43080 10/rt^3/trunk/src/ (60 files in 13 dirs): Last of year 2010 to 2011 text updates. |
| 15:02.41 | ``Erik | huh, debian 6.0 GNU/kFreeBSD O.o |
| 15:34.03 | CIA-53 | BRL-CAD: 03starseeker * r43081 10/brlcad/branches/cmake/CMakeLists.txt: Heh - distcheck caught it. Add the new configure script to the ignore list. |
| 15:36.24 | ``Erik | is this release done yet? O.o |
| 15:37.08 | starseeker | hmm? dunno, that's the new distcheck in the CMake branch |
| 15:37.41 | ``Erik | yeah, wasn't referring to the cmake branch... TODO says 'nada!', and I'm itching to commit this merge :D |
| 15:37.55 | starseeker | oh, gotcha |
| 15:46.45 | CIA-53 | BRL-CAD: 03davidloman * r43082 10/rt^3/trunk/: Added the CmakeTmp folder to svn:ignore. |
| 15:47.56 | CIA-53 | BRL-CAD: 03starseeker * r43083 10/brlcad/branches/cmake/src/ (CMakeLists.txt libdm/CMakeLists.txt libfb/CMakeLists.txt): Couple more distcheck tweaks. |
| 15:57.07 | CIA-53 | BRL-CAD: 03starseeker * r43084 10/brlcad/branches/cmake/ (CMakeLists.txt misc/CMake/svncheck.cmake): Try conditionalizing the svn part of the distcheck - only want to do this if a) we have svn and b) we're building from an svn repository |
| 16:07.17 | CIA-53 | BRL-CAD: 03starseeker * r43085 10/brlcad/branches/cmake/ (3 files in 2 dirs): Fix and simplify svn checking logic - doing it this way, temp file isn't needed. |
| 16:08.50 | dloman | brlcad: I 'hate' you now. I'm hooked on Zombie Trailer park..... |
| 16:33.51 | *** join/#brlcad dli (~dli@66.49.141.114) | |
| 16:42.13 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 17:52.08 | ``Erik | hah |
| 17:56.11 | CIA-53 | BRL-CAD: 03starseeker * r43086 10/brlcad/branches/cmake/src/other/CMakeLists.txt: Few more distcheck files from checking on Mac. |
| 18:17.29 | CIA-53 | BRL-CAD: 03starseeker * r43087 10/brlcad/branches/cmake/CMakeLists.txt: provide a make distclean target for cleanup after an aborted make distcheck |
| 18:20.25 | CIA-53 | BRL-CAD: 03starseeker * r43088 10/brlcad/branches/cmake/misc/CMake/distcheck_buildsys.cmake.in: Don't be completely quiet in the case of success. |
| 18:26.21 | *** join/#brlcad Ralith (~ralith@d142-058-095-100.wireless.sfu.ca) | |
| 19:19.53 | CIA-53 | BRL-CAD: 03starseeker * r43089 10/brlcad/branches/cmake/CMakeLists.txt: (log message trimmed) |
| 19:19.53 | CIA-53 | BRL-CAD: Clean up the Aqua logic a little. Punt on Aqua for now, since a) it's not |
| 19:19.53 | CIA-53 | BRL-CAD: working anyway b) there's a fair bit of work to do with the tcl/tk CMake logic |
| 19:19.53 | CIA-53 | BRL-CAD: to enable Aqua c) the Aqua layer for Tcl/Tk is in flux (moving from Carbon to |
| 19:19.53 | CIA-53 | BRL-CAD: Cocoa) and it's not clear that the older Carbon backend in 8.5 will work on |
| 19:19.54 | CIA-53 | BRL-CAD: newer OSX systems (all new development effort is focused on the Cocoa backend). |
| 19:19.55 | CIA-53 | BRL-CAD: Togl will need to be made to work with the new Cocoa backend once it appears as |
| 19:25.22 | CIA-53 | BRL-CAD: 03starseeker * r43090 10/brlcad/branches/cmake/ (CMakeLists.txt TODO.cmake): Mark aqua option as advanced regardless, move TODO.cmake item |
| 19:28.17 | CIA-53 | BRL-CAD: 03starseeker * r43091 10/brlcad/branches/cmake/ (CMakeLists.txt configure.cmake.sh): remove stray debug message |
| 19:32.06 | *** join/#brlcad Ralith (~ralith@d142-058-095-100.wireless.sfu.ca) | |
| 19:33.50 | CIA-53 | BRL-CAD: 03starseeker * r43092 10/brlcad/branches/cmake/CMakeLists.txt: else, not elseif |
| 19:34.08 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 19:39.20 | brlcad | dloman: hahaha |
| 19:39.33 | brlcad | that fourth level took me quite a while to finally beat |
| 19:40.48 | brlcad | for release, I had a final build distcheck going on saturday and haven't checked in on it since -- looking now |
| 19:44.08 | dloman | brlcad: Getting my rear end handed to be on level 3. |
| 19:44.24 | dloman | Looks like, in a zombie apocalypse, I wouldn't last long as a leader :) |
| 19:49.03 | CIA-53 | BRL-CAD: 03brlcad * r43093 10/brlcad/trunk/BUGS: |
| 19:49.03 | CIA-53 | BRL-CAD: this might be intentional behavior but it feels like a bug. create a jumbled |
| 19:49.03 | CIA-53 | BRL-CAD: mess of primitives all at the origin and they'll seem to render wrong, |
| 19:49.03 | CIA-53 | BRL-CAD: particularly if you union them all into a region. might have something to do |
| 19:49.03 | CIA-53 | BRL-CAD: with the halfspace. |
| 19:49.23 | brlcad | the key to all the levels is to build those money-maker's as fast as absolutely possible |
| 19:50.17 | brlcad | only sending guys and only building the bare minimum until they're all built |
| 19:54.00 | CIA-53 | BRL-CAD: 03starseeker * r43094 10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: Tweak OSX hack for debug flags |
| 20:01.01 | CIA-53 | BRL-CAD: 03starseeker * r43095 10/brlcad/branches/cmake/ (CMakeLists.txt configure.cmake.sh): Add a few more config options, remove commented out C99 stuff (belongs in CompilerFlags.cmake) |
| 20:05.20 | CIA-53 | BRL-CAD: 03brlcad * r43096 10/brlcad/trunk/BUGS: more details on how to reproduce the badness. the rendering of 'primitives' is presently crashing inside rt_bot_makesegs_double() for me. |
| 20:27.35 | CIA-53 | BRL-CAD: 03brlcad * r43097 10/brlcad/trunk/src/librt/primitives/bot/g_bot_include.c: remove dead code. not documented why we'd keep old or new. |
| 20:49.21 | CIA-53 | BRL-CAD: 03starseeker * r43098 10/brlcad/branches/cmake/src/other/tcl/CMakeLists.txt: Add a couple flags identified in the old libtcl.vcproj file for 64 bit |
| 20:52.32 | CIA-53 | BRL-CAD: 03starseeker * r43099 10/brlcad/branches/cmake/src/other/tk/CMakeLists.txt: Add same flags for tk |
| 21:09.48 | starseeker | dloman: is d_rossberg actively using anything in the rt^3 branch in production? |
| 21:10.07 | starseeker | if so, I'd probably better branch before I start mucking too much |
| 21:25.42 | brlcad | yes, he is -- the geometry engine code is in there |
| 21:25.58 | brlcad | the c++ interface he's been working on |
| 21:26.10 | starseeker | k |
| 21:26.40 | starseeker | brlcad: I seem to have a fairy functional distcheck now |
| 21:26.55 | brlcad | great |
| 21:30.22 | starseeker | I'll update the various docs, and then I'll need someone to do a review for merge |
| 22:06.01 | CIA-53 | BRL-CAD: 03starseeker * r43100 10/brlcad/branches/cmake/CMakeLists.txt: Set policy CMP0007 so FindTCL won't trigger warning messages |
| 22:18.53 | brlcad | (still build-testing) |
| 22:19.14 | brlcad | epileg: you can download the current and re-upload |
| 22:19.26 | epileg | ok |
| 22:30.03 | CIA-53 | BRL-CAD: 03starseeker * r43101 10/brlcad/branches/cmake/src/librt/opennurbs_ext.h: Hmm - looks like this attribute line isn't entirely portable. |
| 22:33.03 | starseeker | https://bugzilla.redhat.com/show_bug.cgi?id=147446 |
| 22:45.17 | *** join/#brlcad Ralith (~ralith@d142-058-081-182.wireless.sfu.ca) | |
| 23:36.20 | CIA-53 | BRL-CAD: 03starseeker * r43102 10/brlcad/branches/cmake/src/other/tcl/CMakeLists.txt: |
| 23:36.20 | CIA-53 | BRL-CAD: Comment out the parts that break Xcode generator in Tcl build - will have to |
| 23:36.20 | CIA-53 | BRL-CAD: figure out something else, probably limited config.h header (perhaps this is why |
| 23:36.20 | CIA-53 | BRL-CAD: there is logic in the tcl/tk makefiles on apple for a config header) |
| 00:32.33 | CIA-53 | BRL-CAD: 03starseeker * r43103 10/brlcad/branches/cmake/TODO.cmake: Add todo note for XCode |
| 01:14.48 | CIA-53 | BRL-CAD: 03starseeker * r43104 10/brlcad/branches/cmake/CMakeLists.txt: try ORIGIN first - if the binary is running locally, pulling a system lib would be both subtly unexpected and potentially subtly wrong. |
| 01:47.14 | *** part/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 01:52.31 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 02:03.14 | CIA-53 | BRL-CAD: 03starseeker * r43105 10/brlcad/branches/cmake/CMakeLists.txt: quote the flag string - it's not a list in the CMake sense |
| 02:05.11 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) | |
| 02:10.02 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 02:12.37 | CIA-53 | BRL-CAD: 03starseeker * r43106 10/brlcad/branches/cmake/ (INSTALL README configure.cmake.sh): Start working on docs - part way through install, but there are a lot of options to cover... |
| 02:27.22 | CIA-53 | BRL-CAD: 03starseeker * r43107 10/brlcad/branches/cmake/CMakeLists.txt: |
| 02:27.23 | CIA-53 | BRL-CAD: Was right the first time - can't be sure what impact symbolic links and the |
| 02:27.23 | CIA-53 | BRL-CAD: links may have on ORIGIN. Have to go with the install path first, and just make |
| 02:27.23 | CIA-53 | BRL-CAD: sure it doesn't conflict with a system path if the idea is to make something |
| 02:27.23 | CIA-53 | BRL-CAD: relocatable. |
| 03:53.51 | brlcad | starseeker: that bug doesn't seem entirely relevant |
| 03:54.27 | brlcad | or did you hit the "unimplemented" message? |
| 03:55.01 | brlcad | either way, a different fix is likely going to be needed -- merging that back to trunk will likely break optimized (strict) build |
| 03:59.01 | brlcad | s/likely/should/ |
| 03:59.22 | brlcad | that was specifically added to fix an inline failure |
| 04:07.06 | starseeker | I hit the unimplemented message |
| 04:07.11 | starseeker | refused to compile at all |
| 04:38.38 | *** join/#brlcad jmoore (~jmoore@cpe-184-57-8-75.columbus.res.rr.com) | |
| 04:45.24 | jmoore | Hi. Is their a simple way to get a list of leaf's and combs using c? tying to duplicate the functionality ls in mged for use in another function. I found the tree walk function but they take a starting dir and I am having truble figering out how to exrract all of the used ones in dbi_Head |
| 04:56.27 | brlcad | starseeker: goes without saying, though, that another fix will be needed -- you just shifted the failure from one platform over to another |
| 04:57.55 | brlcad | jmoore: there are about a half dozen differen tree walkers for that purpose -- you can see how the ls command does it, for example, in src/libged/ls.c (ged_ls()) |
| 04:59.34 | brlcad | the src/libged commands build on top of the underlying librt API |
| 05:01.01 | brlcad | jmoore: probably more useful than the ls command, however, is the "l" aka "list" command -- src/libged/list.c |
| 05:01.45 | brlcad | ends up calling rt_functab[id].ft_describe() which writes the listing to a string |
| 05:02.17 | jmoore | thanks |
| 05:03.29 | brlcad | jmoore: have you seen this: http://brlcad.org/wiki/Example_db_walk_tree |
| 05:04.10 | brlcad | not entirely what you're asking as you don't need to walk recursively to just display members of a combinatino |
| 05:08.19 | brlcad | jmore: db_lookup() + rt_db_get_internal() + db_flatten_tree() will give you a simple array of the combination elements listing the CSG operator and the name of the object |
| 05:08.50 | jmoore | No I had not. I looks like a starting point good you all redy have a base shape's name. |
| 05:10.00 | brlcad | a couple more useful dev resources including a ray-shooting example at http://brlcad.org/wiki/Developing_applications |
| 05:10.08 | jmoore | been piling threw http://brlcad.org/wiki/Example_db_walk_tree |
| 05:10.16 | jmoore | http://brlcad.org/xref/ident |
| 05:11.13 | brlcad | it's a huge API to traverse that way -- encourage you to ask questions here or on the devel mailing list |
| 05:16.08 | brlcad | 2000+ public functions across a dozen different libraries, numerics, generic routines, ray tracing, geometry, image processing, .... it's easy to get lost |
| 05:17.19 | jmoore | k thanks. |
| 05:17.40 | jmoore | that is for suer. |
| 08:40.49 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 08:42.53 | d_rossberg | starseeker: first the good news: i was able to build ALL_BUILD in reasonable time, INSTALL it, run mged, load a database there and raytrace into a pupup window :) |
| 08:44.20 | d_rossberg | and i was able to reproduce the OPENNURBS & UTAHRLE error: http://paste.ubuntu.com/564291/ |
| 08:45.45 | d_rossberg | after removing all from the installation directory the configuration went through |
| 11:24.45 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 11:40.28 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 12:31.24 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:03.39 | starseeker | d_rossberg: what's happening there is the find routines are identifying previously installed BRL-CAD files |
| 13:04.18 | starseeker | is your CMAKE_INSTALL_PREFIX set to C:/brlcad.cmake/aInstall ? |
| 13:06.13 | starseeker | looks like the summary thinks it is... |
| 13:10.01 | CIA-53 | BRL-CAD: 03starseeker * r43108 10/brlcad/branches/cmake/src/other/CMakeLists.txt: Don't try getting properties from openNURBS unless we're actually building it. |
| 13:10.28 | starseeker | that may fix the error (and was legit enough) but the real issue is why it's looking in the install path |
| 13:11.04 | starseeker | logic in the root CMakeLists.txt file starting line 116 is intended to prevent that |
| 13:49.46 | d_rossberg | right: my CMAKE_INSTALL_PREFIX is set to C:/brlcad.cmake/aInstall |
| 13:50.31 | d_rossberg | my build directory is C:/brlcad.cmake/aBuild |
| 13:51.11 | d_rossberg | my brlcad checkout directory is C:/brlcad.cmake (for the cmake build) |
| 14:32.19 | CIA-53 | BRL-CAD: 03starseeker * r43109 10/geomcore/: Since parts of rt^3 are being used, make a branch of it to thrash around in. |
| 14:36.06 | CIA-53 | BRL-CAD: 03starseeker * r43110 10/geomcore/trunk/src/other/ (CMakeLists.txt ogre/ ois/): Don't need ogre and ois in here right now, dated anyway |
| 14:36.55 | CIA-53 | BRL-CAD: 03starseeker * r43111 10/geomcore/trunk/src/g3d/: This is in the other branch, not the focus of current efforts - remove from this one |
| 14:38.17 | CIA-53 | BRL-CAD: 03starseeker * r43112 10/geomcore/trunk/src/ (rt^3/ rt^3d/ rt^3dbd/ scratch/): Not added by CMakeLists.txt, confusingly named - remove |
| 15:01.11 | CIA-53 | BRL-CAD: 03jordisayol * r43113 10/brlcad/trunk/sh/ (make_deb.sh make_rpm.sh): add the option to build openSUSE rpm packages |
| 15:12.20 | *** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de) | |
| 15:39.45 | dloman | oh, one last thing starseeker and ``Erik : No laughing at my code, I have thin skin and a violent temper! |
| 15:39.49 | dloman | =D |
| 15:39.56 | starseeker | you too? |
| 15:40.06 | ``Erik | I laugh at everyones code, even my own :D |
| 15:41.16 | starseeker | dloman: is the signals and slots TODO taken care of? |
| 15:41.39 | dloman | quite likely |
| 15:41.48 | starseeker | k - rewording to make more general |
| 15:41.53 | dloman | i haven't been keeping that file uptodate |
| 15:43.36 | dloman | checks out Geomcore.... |
| 15:43.43 | dloman | ...slowly, lol |
| 15:43.53 | starseeker | should be faster without ogre in there... |
| 15:44.27 | dloman | yeah, it is. Network pipe or SF is slow though. |
| 15:44.46 | dloman | I keep my personal projects/code on a friends server... svn is wiked fast. |
| 15:44.57 | dloman | only has to deal with 10 or so projects, nothing like SF's load |
| 15:44.57 | CIA-53 | BRL-CAD: 03Sean 07http://brlcad.org * r2462 10/wiki/Community_Publication_Portal: article on rpm/deb efforts by jordi |
| 15:45.12 | dloman | so.... Im super spoiled and think that SF svn is wicked slow |
| 15:45.18 | starseeker | heh |
| 15:45.28 | starseeker | it is a bit slow, must admit |
| 15:45.53 | brlcad | svn from sf.net is slow, but it still far beats having to manage it ourselves |
| 15:47.14 | brlcad | server availability, svn upgrades, security, web services, hardware backup recovery, ... lots of "one less thing" to worry about at the cost of a little waiting during update/checkin |
| 15:47.39 | dloman | roger that. Just sayin' =D |
| 15:48.00 | CIA-53 | BRL-CAD: 03starseeker * r43114 10/geomcore/trunk/ (AUTHORS COPYING HACKING INSTALL NEWS README TODO): Lot more to do here - quick scrub to set up focus on geometry engine and geometry server. |
| 15:48.28 | brlcad | it actually encourages better commit practices, since the delay is worse with bigger commits |
| 15:48.54 | brlcad | smaller frequent commits and the delays aren't really an issue, especially svn commit -m "asdf" & |
| 15:49.10 | starseeker | true |
| 15:49.15 | starseeker | hadn't thought of that |
| 15:51.39 | dloman | brlcad: I'm spreading the infection. Got a friend in WA hooked on Zombie Trailer Park now :) |
| 15:51.55 | brlcad | excellent |
| 15:52.01 | dloman | and he works at MS with a bunch of guys, so lets see how viral it will go! |
| 15:52.06 | brlcad | dloman: beat level 4 yet? |
| 15:52.11 | dloman | ha, nope. |
| 15:52.39 | dloman | verizon started screwing with the lines in my development yesterday afternoon. Internet and phone dropped out around 3pm :/ |
| 15:54.52 | starseeker | dloman: are the docs you've been working on the last couple weeks in the docs subdirectory, or just on the wiki? |
| 15:56.03 | dloman | been keeping thr graphics in the docs dir, text on the wiki |
| 15:56.10 | dloman | s/thr/the/ |
| 15:56.37 | starseeker | dloman: k. I may snarf it and stick in docbook, if that's OK |
| 15:56.57 | dloman | sure, they were quickei photochop's, so take that for what it is :) |
| 15:57.15 | starseeker | no problem :-) |
| 15:57.38 | CIA-53 | BRL-CAD: 03ronaldbowers * r43115 10/jbrlcad/trunk/src/main/java/org/brlcad/geometryservice/ (5 files): - splitting GeometryService into basic functionality and a caching layer. The caching will be relocated to Gomez. |
| 16:02.56 | dloman | ``Erik: would it be good/bad practice to make a dir (save level as src/) to hold all the 'interface' libs? |
| 16:03.21 | ``Erik | um, ya mean src/client/{c,java,python,ruby}/ ? |
| 16:03.43 | dloman | ya those |
| 16:03.54 | dloman | or would src/interfaces/* be better? |
| 16:05.02 | ``Erik | d'no *shrug* |
| 16:05.53 | CIA-53 | BRL-CAD: 03erikgreenwald * r43116 10/geomcore/trunk/src/client/ (CMakeLists.txt c/ c/CMakeLists.txt c/gsclient.c c/gsclient.h): C stuff stubbed |
| 16:12.32 | dloman | preference? |
| 16:12.48 | starseeker | likes interfaces |
| 16:30.08 | dloman | ``Erik: preference? |
| 17:45.35 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 17:56.13 | ``Erik | have none |
| 17:57.52 | CIA-53 | BRL-CAD: 03starseeker * r43117 10/geomcore/trunk/src/ (client/ interfaces/): move client to interfaces |
| 17:58.49 | CIA-53 | BRL-CAD: 03starseeker * r43118 10/geomcore/trunk/src/CMakeLists.txt: Update build reference |
| 18:10.08 | CIA-53 | BRL-CAD: 03starseeker * r43119 10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: Try finline-limit expansion instead of the always_inline attribute - perhaps this will be more portable |
| 18:10.28 | dloman | okie then |
| 18:10.53 | dloman | starseeker: we dropping coreInterface out of Geomcore? |
| 18:14.27 | starseeker | dloman: uh, whoops - did I chop too much? |
| 18:15.05 | dloman | nope. Just saw coreInterface in geomcore/src and figured i'd ask. |
| 18:15.19 | starseeker | are we using it? |
| 18:15.31 | dloman | not to my knowledge |
| 18:16.06 | starseeker | um... not sure about that one yet. It's not a slam dunk the way ogre was |
| 18:16.30 | dloman | okie, no worries. like I said, just askin. |
| 18:16.47 | starseeker | nods - fair question, I just don't know enough to answer it yet |
| 18:23.34 | CIA-53 | BRL-CAD: 03davidloman * r43120 10/geomcore/trunk/src/interfaces/java/README: Add README with small blurb about intent and design |
| 18:23.58 | CIA-53 | BRL-CAD: 03davidloman * r43121 10/geomcore/trunk/src/interfaces/java/CMakeLists.txt: Removed iBME verbage. Stopped using that acronym a while ago as it doesn't describe the GS project correctly. |
| 18:25.18 | CIA-53 | BRL-CAD: 03davidloman * r43122 10/geomcore/trunk/src/interfaces/java/src/ (. org/ org/brlcad/ org/brlcad/geometryservice/): Add in packages |
| 18:25.39 | dloman | Hrm. Should the interfaces ALL bewired into cmake? That might make the cmake build a living hell.... |
| 18:26.02 | starseeker | dloman: how so? |
| 18:26.38 | dloman | ruby, java, etc... wouldn't cmake need to know how to compile all of those languages? ...or does it already? |
| 18:26.55 | ``Erik | ruby isn't compiled, there're hacks to call javac for java |
| 18:27.08 | ``Erik | (but not all machines necessarily have java) |
| 18:27.16 | dloman | well that's my point. |
| 18:27.28 | starseeker | you conditionalize on finding java - BRL-CAD cmake build already does that |
| 18:27.33 | dloman | plus, those that do might not have the same java.... but thats a different can of worms. |
| 18:28.02 | starseeker | dloman: don't worry too much - we have to do SOMETHING to build them all, and CMake is probably as good as any |
| 18:28.04 | ``Erik | well, I'd hope the implementation would be in java 1.4, which should be an ok baseline for everywhere |
| 18:28.26 | dloman | the other angle i was thinking about was: if someone is looking for an interface to the GS, they might not be interested building the rest of hte code. |
| 18:29.05 | ``Erik | so'z they copy the file(s) and wire them into their own build systems? :) |
| 18:29.14 | starseeker | OPTION(ENABLE_INTERFACES "Enable external language interfaces" OFF) |
| 18:29.24 | dloman | okie. |
| 18:29.58 | dloman | just thinking about 'should the interfaces be wired into the main build or not' ...thats all :) |
| 18:30.09 | starseeker | nods - it's OK if they aren't initially |
| 18:30.48 | CIA-53 | BRL-CAD: 03davidloman * r43123 10/geomcore/trunk/src/interfaces/java/ (. GSClient.java src/org/brlcad/geometryservice/GSClient.java): Move GSClient into proper package structure. |
| 18:31.00 | CIA-53 | BRL-CAD: 03erikgreenwald * r43124 10/geomcore/trunk/src/GE/CMakeLists.txt: no QT used here, remove flags for it |
| 18:38.29 | CIA-53 | BRL-CAD: 03davidloman * r43125 10/geomcore/trunk/src/interfaces/java/README: Keep it simple and, rather than copy classes that are under development, make jBRLCAD an dependency. Hopefully this will change in the near future. |
| 18:40.36 | CIA-53 | BRL-CAD: 03davidloman * r43126 10/geomcore/trunk/src/interfaces/java/test/ (. org/ org/brlcad/ org/brlcad/geometryservice/): Add in test dir structure |
| 18:42.14 | CIA-53 | BRL-CAD: 03davidloman * r43127 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ (. msg/): Add in net and net.msg packages for upcoming work on implementing the GSNet protocol in java. |
| 18:58.06 | CIA-53 | BRL-CAD: 03davidloman * r43128 10/geomcore/trunk/src/interfaces/java/auto-props.cfg: Add an autoprops file |
| 19:08.03 | CIA-53 | BRL-CAD: 03davidloman * r43129 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/ (GSClient.java GSStatics.java): Create dedicated statics class. Move statics into it. |
| 19:13.01 | CIA-53 | BRL-CAD: 03erikgreenwald * r43130 10/geomcore/trunk/src/ (date/CMakeLists.txt libPkgCpp/CMakeLists.txt): remove unnecessary QT references |
| 19:26.39 | CIA-53 | BRL-CAD: 03bob1961 * r43131 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Override ArcherCore::zap |
| 19:28.28 | CIA-53 | BRL-CAD: 03starseeker * r43132 10/geomcore/trunk/src/date/: Remove date - not been used in a while, and if it's for build config we have other approaches |
| 19:32.05 | CIA-53 | BRL-CAD: 03davidloman * r43133 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ (3 files): Add in ByteBuffer helper classes. These will be needed for serialization/deserialization of AbstractNetMsg subclasses. |
| 19:36.10 | CIA-53 | BRL-CAD: 03davidloman * r43134 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ (ByteBufferReader.java ByteBufferWriter.java): Add read/write support for java's UUID to ByteBuffer helper classes. |
| 19:37.10 | CIA-53 | BRL-CAD: 03starseeker * r43135 10/geomcore/trunk/src/other/ (CMakeLists.txt sqlite/ sqlite_3_7_4/): Let's not use the version number in the directory name |
| 19:40.22 | CIA-53 | BRL-CAD: 03davidloman * r43136 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ (ByteBufferReader.java ByteBufferWriter.java): Add explicit read/write support for java's Boolean to ByteBuffer helper classes. |
| 19:40.23 | CIA-53 | BRL-CAD: 03starseeker * r43137 10/geomcore/trunk/src/other/sqlite/ (shell.c sqlite3.c sqlite3.h): Update sqlite to sqlite-amalgamation-201101281703, add sqlite3.h |
| 19:55.16 | CIA-53 | BRL-CAD: 03davidloman * r43138 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/ (GSClient.java net/msg/NetMsgTypes.java): Move NetMsg types out of GSClient and into a dedicated class in the .net.msg package. |
| 19:56.21 | CIA-53 | BRL-CAD: 03davidloman * r43139 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/AbstractNetMsg.java: First cut at implementation of AbstractNetMsg in java. |
| 20:02.00 | CIA-53 | BRL-CAD: 03davidloman * r43140 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ByteBufferReader.java: Add helper cstr to ByteBufferReader that defaults endian flip to false. |
| 20:02.14 | *** join/#brlcad PrezKennedy (MK@2607:f0d0:3001:68::2) | |
| 20:04.46 | CIA-53 | BRL-CAD: 03erikgreenwald * r43141 10/geomcore/trunk/src/CMakeLists.txt: date is gone |
| 20:09.18 | CIA-53 | BRL-CAD: 03davidloman * r43142 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/NetMsgFactory.java: Stub in the skeleton for a simple netMsg factory. |
| 20:43.08 | CIA-53 | BRL-CAD: 03davidloman * r43143 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: Stub in the first round of GSConnection work. Nowhere near functional yet, still building infrastructure. |
| 20:43.56 | CIA-53 | BRL-CAD: 03davidloman * r43144 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: Import cleanup. |
| 21:35.26 | ``Erik | cd src/libNe |
| 21:35.28 | ``Erik | woops |
| 21:38.15 | CIA-53 | BRL-CAD: 03starseeker * r43145 10/geomcore/trunk/ (41 files in 14 dirs): Start rework of the CMake build - no longer generating libutility.h and friends, so update the code accordingly |
| 21:47.10 | CIA-53 | BRL-CAD: 03starseeker * r43146 10/brlcad/branches/cmake/ (6 files in 5 dirs): MFC 43145 |
| 22:16.15 | brlcad | outstanding, looks like distcheck is clean 32-bit and 64-bit now |
| 22:16.26 | brlcad | starting release |
| 22:41.08 | CIA-53 | BRL-CAD: 03starseeker * r43147 10/geomcore/trunk/src/other/uuid/ (50 files): Preliminary steps to getting off of using Qt's uuid feature - use ossp uuid, but there's a complex test for va_copy that I haven't reproduced in CMake yet. |
| 22:46.16 | CIA-53 | BRL-CAD: 03starseeker * r43148 10/geomcore/trunk/src/other/uuid/CMakeLists.txt: give uuid a project setting. Also note that there was a change to the source of uuid_str.c - a couple of #if statements were changed to #ifdef |
| 23:07.01 | CIA-53 | BRL-CAD: 03starseeker * r43149 10/geomcore/trunk/src/other/ (CMakeLists.txt uuid/CMakeLists.txt uuid/uuid_ac.h): Add uuid to build, also switch uuid's config.h to uuid_config.h to avoid conflicts with the main config file |
| 01:00.15 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 01:45.21 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 01:53.11 | starseeker | ``Erik: unless BSD has done some serious hacking, APR and APR-util are mandatory for subversion |
| 02:01.49 | *** join/#brlcad dli (~dli@66.49.141.114) | |
| 02:07.28 | dli | hi, I wonder whether it's possible to add openGL support for brlcad, so rendering, can be in real time |
| 02:11.30 | starseeker | that depends on what you mean by rendering |
| 02:11.51 | starseeker | if you mean 3D shaded display, the hard part is converting our geometry to the triangles needed to feed OpenGL |
| 02:12.15 | starseeker | if you mean raytracing, you may want to take a look at adrt |
| 02:12.55 | dli | starseeker, raytracing is still slow, I know this part. I just mean to use more features from modern video cards |
| 02:13.35 | starseeker | robust tessellation is a foundation for any shaded display using OpenGL, unless you're talking about raytracing using the GPL |
| 02:13.39 | starseeker | er GPU |
| 02:13.59 | starseeker | we haven't done much in the raytracing with GPU direction |
| 02:14.22 | dli | starseeker, no, I don't expect raytracing on GPU, too much work :( |
| 02:15.21 | dli | starseeker, so, you think it's possible. if true, it would very much exciting, CAD can be a real time simulator then |
| 02:15.50 | starseeker | it's certainly possible, but robust tessellation of CSG geometry is not a simple problem |
| 02:17.04 | dli | starseeker, which level is the cause of problems? conceptual, algorithm, or just have to rewrite a lot? |
| 02:19.07 | CIA-53 | BRL-CAD: 03starseeker * r43150 10/geomcore/trunk/src/other/subversion/COPYING: Whoops - add the subversion COPYING file |
| 02:19.22 | starseeker | dli: both algorithmic and lot of code to wrangle |
| 02:19.33 | starseeker | take a look at the nmg code in librt to get an idea |
| 02:20.47 | dli | starseeker, I will try. I hope I can understand something first |
| 02:21.23 | starseeker | dli: brlcad may be able to give you a better overview of the various options and where a good starting point is |
| 02:21.53 | starseeker | most of the issues I'm familiar with involving tessellation and shaded displays involve "diving off the deep end" |
| 02:22.44 | dli | starseeker, yes, long time ago, I wanted to contribute to this project, but too busy at that time. now, I have should have some time for algorithm and coding |
| 02:23.22 | dli | starseeker, thanks a lot, I will talk to brlcad later |
| 02:23.33 | starseeker | dli: awesome :-) |
| 02:24.09 | starseeker | dli: one good starting point might be to look at one of the convertors in src/conv |
| 02:24.21 | starseeker | most of them invoke tessellation logic |
| 02:24.50 | dli | starseeker, sure, I will try to read as much as possible, to help understanding |
| 02:33.36 | starseeker | looks at the apr configure process and turns white |
| 02:36.56 | starseeker | checks the subversion code a little... |
| 02:41.07 | starseeker | ``Erik: yeah, there's no way they've avoided requiring apr - the entire code base is thick with apr types and calls |
| 02:41.20 | starseeker | removing apr would amount to a total rewrite |
| 03:35.52 | brlcad | dli: technically, we already have opengl support -- you can see it in action with a private debug setting on an opengl-enabled build |
| 03:36.54 | brlcad | the problem is that the way it's currently implemented is at least np-hard, error-prone to numeric drift, slow as balls, and not robust (because it's np-hard) |
| 03:37.25 | dli | brlcad, I see, so, it's not really useful as is |
| 03:37.32 | brlcad | so you can either work on making it more robust (which would be fantastic, but hard) then make it faster (probably the easiest part) |
| 03:38.10 | brlcad | the problem is mostly algorithmic |
| 03:39.12 | brlcad | consider two overlapping spheres, for example, simply defined by a point and a radius, unioned together |
| 03:39.16 | dli | brlcad, I will read the code first :) |
| 03:40.21 | brlcad | current approach basically turns each of the two spheres into a set of polygons (trivial) then evaluates interior, exterior, and overlapping polygons |
| 03:40.36 | starseeker | reluctantly concludes libgit2 is too immature feature wise to be an option for some time, even if we could switch horses now (which we can't) |
| 03:40.36 | brlcad | that's also trivial/easy |
| 03:41.04 | dli | brlcad, how could this be NP? |
| 03:41.06 | brlcad | since it's a union, it throws away the interior polygons, keeps the exterior, and stitches together the overlapping ones trimming away and splicing together correctly |
| 03:41.33 | brlcad | dli: I'm showing you one of the very most simple cases just for understanding of the basic algorithm |
| 03:42.00 | brlcad | it's actually a relatively simple algorithm, but the devil is in the details |
| 03:42.53 | dli | brlcad, because we build the geometry part by part, I suppose the complexity of adding one more primitive is O(N), for N existing primitives |
| 03:42.57 | brlcad | it's not robust for a variety of problems, including floating point drift during the trimming/splicing stage but also because we're evaluating the boolean AFTER tessellating all primitives where we're no longer matching the original surface |
| 03:43.30 | brlcad | that'd be linear complexity, which it is not :) |
| 03:43.52 | brlcad | it's exponential to evaluate the N+1 primitive against the previous N set |
| 03:45.24 | brlcad | there are tons of optimizations possible, you could get the performance down to reasonable levels with some basic space partitioning -- in fact the current code does this for some cases |
| 03:45.31 | dli | brlcad, the complexity of voronoi cell analysis is N log(N), I feel it's similar |
| 03:45.57 | brlcad | the problem with the approach, however, is that it's still basically a lossy approach |
| 03:46.47 | brlcad | so even if you solved the robustness problem with careful numerics and consistently handling all edge cases, there are STILL going to be some comparisons that fundamentally cannot be solved without making a blind guess |
| 03:47.00 | brlcad | that's where NURBS comes in |
| 03:47.26 | brlcad | it's the new approach that will eventually make the current approach obsolete -- the boolean is evaluated prior to tessellation |
| 03:48.49 | brlcad | instead of converting each primitive to a mesh, each is converted to a spline surface, surface-surface intersection calculations are performed (just like done with meshes, marking interior/exterior/overlapping surfaces), surfaces are trimmed according to the boolean, and the resulting *evaluated* surfaces are then trivially tessellated |
| 03:48.51 | dli | brlcad, sounds very interesting to me, I feel I could contribute something here. I did molecular dynamics, genetic aglorithm, voronoi cells, and have some time for coding now |
| 03:49.54 | brlcad | dli: that's fantastic, there are plenty of places you could jump in |
| 03:50.47 | dli | brlcad, give me some clues :) |
| 03:51.12 | brlcad | basically you can either work on our mesh support (i.e., the current approach, which will still be needed even with nurbs, for polygonal surfaces) or.. |
| 03:51.37 | brlcad | you can work on the various outstanding issues with our new nurbs support |
| 03:52.36 | brlcad | surface-surface intersection calculations to derive an intersection curve is one problem still TBD -- robustly tessellating a nurbs surface is another |
| 03:53.07 | dli | brlcad, under src/others/openNURBS/ ? |
| 03:53.10 | brlcad | the mesh processing is much more approachable but will require systematically reviewing thousands and thousands of lines of code, hundreds of functions |
| 03:53.46 | brlcad | depends what your exact goal is :) |
| 03:54.33 | brlcad | I'd set a specific small goal and then it'll be easier to point you in the right direction towards implementing that goal |
| 03:55.09 | dli | brlcad, I think I would try the surface-surface intersection first |
| 03:55.59 | brlcad | okay |
| 03:56.34 | brlcad | then your starting point is probably: http://en.wikipedia.org/wiki/Surface-to-surface_intersection_problem |
| 03:57.13 | brlcad | there are tons of approaches and research on the subject, but that's a good primer |
| 03:57.55 | starseeker | dli: I have a few links to papers I can dig up tomorrow |
| 03:57.57 | brlcad | code-wise, src/other/openNURBS is a good starting point along with where we hook openNURBS into our code for ray-tracing at src/librt/primitives/brep |
| 03:58.24 | dli | starseeker, thanks |
| 03:58.54 | brlcad | you're basically writing a function that takes two ON_Brep objects and returns an ON_Curve |
| 03:59.11 | brlcad | or an ON_Surface or similar "intersection result" |
| 03:59.19 | starseeker | dli: ah, wait - found it :-) http://www.cs.berkeley.edu/~hling/research/paper/intersection.htm |
| 03:59.47 | dli | brlcad, nice, quite specific at this stage |
| 04:00.13 | brlcad | dli: you can start with src/proc-db/brep_simple.cpp |
| 04:00.29 | brlcad | that shows how one manually creates a b-rep box using openNURBS |
| 04:01.04 | brlcad | you could easily extend that example to just create two surfaces, then evaluate their intersection |
| 04:02.03 | brlcad | a summer student attempt this about a year and a half ago, their effort is in src/proc-db/surfaceintersect.cpp |
| 04:02.20 | CIA-53 | BRL-CAD: 03starseeker * r43151 10/geomcore/trunk/src/other/subversion/CMake/ThirdParty.cmake: |
| 04:02.20 | CIA-53 | BRL-CAD: Chop third party macro stuff down to just autoconf - need to sync with the newer |
| 04:02.20 | CIA-53 | BRL-CAD: one in BRL-CAD, but this has specific improvements to the autoconf routines that |
| 04:02.20 | CIA-53 | BRL-CAD: will need to be merged back into the main version (BRL-CAD trunk no longer does |
| 04:02.20 | CIA-53 | BRL-CAD: third party builds with autoconf, but apr and friends look to be very difficult |
| 04:02.21 | CIA-53 | BRL-CAD: conversion prospects for CMake.) |
| 04:03.09 | dli | brlcad, good enough :) so, I will read the brep_simple.cpp, and figure out the data structures, then, write a function to to find intersection of two ON_Brep objects |
| 04:03.30 | starseeker | brlcad: we may have to settle for building apr using their Visual Studio files on Windows as a precursor to building our subversion stuff - I don't know that I've found any successful examples of external projects in Visual Studio, although I can't yet say that for certain |
| 04:08.55 | brlcad | more info at http://mae.ucdavis.edu/~farouki/foils.pdf or with more rigor ftp://ftp.cs.unc.edu/pub/users/manocha/PAPERS/INTERSECT/IJCGA.pdf (he's published an update in 1997, but don't have a link for it) |
| 04:09.53 | brlcad | starseeker: not worried about external deps for GS until it's fully implemented -- dev rule can simply be "install it first" in the meantime |
| 04:10.06 | dli | brlcad, got them. some reading time now |
| 04:10.26 | brlcad | run cmake test(s), if not found -- print a message saying they need to install it |
| 04:11.30 | brlcad | build system integration isn't an issue until it's time for public deployment (which isn't on the table this year) |
| 04:11.38 | brlcad | dli: great |
| 04:17.37 | brlcad | dli, if you start making progress on code, let me know and we can get you set up with commit access so your efforts can be incrementally visible to others, traceable, and easier to understand the end-result |
| 04:18.31 | dli | brlcad, sure, we will see :) |
| 04:25.55 | *** join/#brlcad jmoore (~jmoore@cpe-184-57-8-75.columbus.res.rr.com) | |
| 04:25.55 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 04:25.55 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 04:25.55 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 04:25.55 | *** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ) | |
| 04:25.55 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 04:25.55 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 04:25.55 | *** join/#brlcad cosurgi (~cosurgi@atak.bl.pg.gda.pl) | |
| 04:25.55 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 04:30.27 | *** join/#brlcad IriX64 (~IriX64@70.52.228.89) | |
| 04:32.38 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 05:26.40 | CIA-53 | BRL-CAD: 03brlcad * r43152 10/brlcad/trunk/NEWS: include write-up highlights for 7.18.2 emphasizing the v4 compatibility work along with the platform integration efforts from new contributor jordi sayol. |
| 05:28.08 | CIA-53 | BRL-CAD: 03brlcad * r43153 10/brlcad/trunk/NEWS: jordi also improved platform support on Fedora, so call it out. leave openSUSE for the next release since it's not as well-tested. |
| 05:31.51 | CIA-53 | BRL-CAD: 03brlcad * r43154 10/brlcad/trunk/include/conf/PATCH: bump patch to .2 for release 7.18.2, final stages |
| 05:32.23 | CIA-53 | BRL-CAD: 03brlcad * r43155 10/brlcad/trunk/ChangeLog: update ChangeLog for release 7.18.2 |
| 05:42.04 | CIA-53 | BRL-CAD: 03Sean 07http://brlcad.org * r2463 10/wiki/Community_Publication_Portal: initial notes for 7.18.2 |
| 05:44.38 | CIA-53 | BRL-CAD: 03Sean 07http://brlcad.org * r2464 10/wiki/Community_Publication_Portal: not a pre section |
| 06:09.59 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 06:15.41 | CIA-53 | BRL-CAD: 03Sean 07http://brlcad.org * r2465 10/wiki/Community_Publication_Portal: /* Sean Morrison: Release 7.18.2 */ expand, reorganize, and reword accordingly |
| 06:15.58 | brlcad | gah, svn: Revision 43155 doesn't match existing revision 43150 in 'src/other/togl' |
| 06:17.28 | brlcad | that's why it's bad to delete and readd directories, even when updating revisions -- they have to be merged |
| 06:20.06 | CIA-53 | BRL-CAD: 03Sean 07http://brlcad.org * r2466 10/wiki/Community_Publication_Portal: /* Sean Morrison: Release 7.18.2 */ |
| 06:27.01 | CIA-53 | BRL-CAD: 03Sean 07http://brlcad.org * r2467 10/wiki/Community_Publication_Portal: final draft, ready for posting as soon as merge completes |
| 06:37.07 | brlcad | apparently a problem that was fixed in a later 1.4 version of subversion |
| 06:40.09 | *** join/#brlcad jmoore (~jmoore@cpe-184-57-8-75.columbus.res.rr.com) | |
| 11:47.51 | dloman | Merning all! |
| 11:57.01 | dloman | *readreadread* |
| 12:10.52 | dloman | starseeker / ``Erik either of you good with threading? I just remembered that GS's JobManagement system is backed by QThread objects |
| 12:37.48 | CIA-53 | BRL-CAD: 03davidloman * r43156 10/jbrlcad/trunk/libs/ (. jscience-4.3.1.jar junit-4.1.jar): Added a libs dir with the two required .jars for compilation. jScience 4.3.1 is antiquated and no longer available to the general public but we still want the average jBRLCAD to be able to jump in, compile and help out. |
| 12:38.53 | CIA-53 | BRL-CAD: 03davidloman * r43157 10/jbrlcad/trunk/src/test/java/org/brlcad/ShootTest.java: Add in missing package statement. |
| 12:40.33 | CIA-53 | BRL-CAD: 03davidloman * r43158 10/jbrlcad/trunk/src/test/java/org/brlcad/geometry/HitTest.java: Import cleanup. |
| 12:54.23 | starseeker | dloman: probably want to look at pthread-win32 + system pthreads on other platforms |
| 12:54.38 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:10.42 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 13:37.19 | dloman | Yeah, but isn't that swapping the dep on QT for a dep on something else? |
| 13:38.35 | dloman | hangs a Chicken Bone Necklace on his monitor. |
| 13:38.40 | dloman | go go slow network! |
| 13:41.31 | dloman | finishes 1.5 hours of timesheets and other red tape :/ |
| 14:02.42 | brlcad | finishes resolving his first tree conflict |
| 14:04.11 | brlcad | at least one of the new svn 1.6 variety |
| 14:05.17 | starseeker | dloman: pthread-win32 is much smaller than Qt |
| 14:07.15 | brlcad | dloman: you know that jbrlcad doesn't have support for all object / primitive types? |
| 14:07.24 | brlcad | it has support for just four of them |
| 14:07.29 | dloman | yuppers :) |
| 14:07.50 | brlcad | k |
| 14:08.07 | dloman | the OCD in me couldn't stand the fact that jbrlcad is linked against libraries that are only stored in 'their' private repositories |
| 14:08.46 | dloman | so i pulled the antiquated version of jScience (4.3.1) and checked it into the jBRLCAD module. |
| 14:09.02 | brlcad | saw that but was more referring to a commit I saw yesterday |
| 14:09.08 | dloman | this way, 'anyone' can compile jbrlcad properly. |
| 14:09.10 | dloman | which one? |
| 14:09.15 | brlcad | looked like you're using jbrlcad in the java bridge to GS? |
| 14:09.36 | dloman | ...not to my knowledge. That's not my intent. Likely bad wordage on my part then. |
| 14:09.46 | dloman | Im not very good at engrish |
| 14:10.29 | brlcad | r43125 |
| 14:10.38 | brlcad | "Keep it simple and, rather than copy classes that are under development, make jBRLCAD an dependency. Hopefully this will change in the near future." |
| 14:11.31 | dloman | was talking about the interface that Ron created in jbrlcad/src/geometryservice |
| 14:11.47 | dloman | thats the 'interface' we are both coding to. |
| 14:12.10 | dloman | since its likely going to change, i figured copy/paste from jbrlcad into rt3 was a maintenance issue. |
| 14:12.30 | dloman | I need to work with Ron on getting all the java source into one place. |
| 14:13.03 | brlcad | where the java code lives isn't really a major concern |
| 14:13.34 | dloman | true, but if its living in two places, that's annoying and makes life harder. But that's my problem =D |
| 14:13.36 | brlcad | it's the reliance on there basically needing to be a librt written in java (which is basically what jbrlcad is) |
| 14:14.37 | dloman | ... that's 'their' issue... right? |
| 14:15.55 | brlcad | well, yes and no -- more than likely a misuse of the geometry service since it's supposed to avoid managing geometry on their end |
| 14:16.05 | brlcad | geomcore/trunk/src/interfaces/java |
| 14:16.12 | brlcad | is that what ron is working on? |
| 14:16.24 | brlcad | or is that the bridge you're working on? |
| 14:21.38 | dloman | sorry, got attacked by red tape again |
| 14:21.52 | dloman | geomcore/trunk/src/interfaces/java is what I/we are working on |
| 14:22.16 | dloman | Ron checked his 'bridge definition' into jbrlcad |
| 14:22.31 | brlcad | so r43125 applied to that path and is where you have the comment about it using jbrlcad |
| 14:23.05 | dloman | correct. in jbrlcad/src/main/org/brlcad/geometryservice |
| 14:23.27 | dloman | there is a java Interface (aka pure virtual class) called GeometryService.java |
| 14:23.31 | brlcad | if it's using jbrlcad, then it sounds like there's a problem -- what's it using? |
| 14:24.20 | dloman | rather than copying that file over to geomcore/src/interfaces/java, i chose to simply make jbrlcad an ext dep untill we can get all the java code into one place. |
| 14:24.22 | brlcad | the issue is the dev path forward -- if it's using it for geometry management, while only supporting 10% of geometry, then there's a future cost that will have to be realized before it's complete |
| 14:24.29 | dloman | its a temporary thing for now. |
| 14:24.46 | dloman | heh, you're way over thinking it :) |
| 14:24.52 | brlcad | probably |
| 14:25.13 | dloman | i just need that file and don't want to (possibly) dev against antiquated Interface |
| 14:25.29 | brlcad | just trying to understand what's going on, since this is potentially a low risk / high risk changer that I'd have to report on and/or address |
| 14:25.41 | dloman | its a non-factor |
| 14:25.48 | brlcad | so if it's just that one interface, why not move it? |
| 14:26.11 | dloman | cause 'they' need it to, and 'they' are developing in jbrlcad module |
| 14:26.19 | dloman | s/to/too/ |
| 14:29.02 | brlcad | sounds like something that will need to be discussed in more detail |
| 14:29.19 | brlcad | that's their perrogative, but implies the GS isn't doing something they need |
| 14:30.32 | brlcad | or that they're crossing over into geometry management land on the java side, which they're not supposed to be doing |
| 14:31.53 | brlcad | either way -- a "GeometryService" class makes no sense in jbrlcad other than as a commit location for all java code |
| 14:32.52 | brlcad | it'd imply either moving the java code you're working on over to the jbrlcad module or moving that class out of jbrlcad into where you're using it and providing it as an interface from there |
| 14:33.32 | brlcad | I suspect it was just added just as a dumping ground for all geometry-related java code, not because it made sense |
| 14:34.57 | dloman | naming-wise, I agree. GeometryService is a rather incorrect name for an Interface that will be sitting in their code base |
| 14:36.05 | dloman | GSAccessPoint perhaps |
| 14:36.45 | brlcad | even with that name, that doesn't really have anything to do with "jbrlcad" |
| 14:36.54 | dloman | true :) |
| 14:37.08 | brlcad | it's a GS thing so it should live with the GS code |
| 14:37.57 | dloman | i think i am going to 'out-dev' them rather rapidly, so I'll likely just take any/all GS related java code out of jBRLCAD module anyways. |
| 14:38.58 | brlcad | it's basic "separation of concerns" |
| 14:39.18 | brlcad | sounds like a communication needing to be had regardless |
| 14:39.42 | dloman | agreed. I'll zip an email up to Ron John (*snicker*) or walk up there later |
| 14:40.24 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 14:41.43 | CIA-53 | BRL-CAD: 03brlcad * r43159 10/brlcad/trunk/misc/debian/application-x-brlcad-extension.xml: set eol-style |
| 14:42.02 | brlcad | 15 minute commit ruined by a single line ending failure |
| 14:42.52 | dloman | http://assets.head-fi.org/f/fd/fd9be1b5_fuuuuuuuu.jpg =D |
| 14:43.50 | CIA-53 | BRL-CAD: 03davidloman * r43160 10/geomcore/trunk/src/interfaces/java/.settings/ (. org.eclipse.jdt.ui.prefs): Putting in Eclipse .settings directory. Contains project settings that are not machine specific, but allows for auto insertion of BRLCAD header. |
| 14:45.21 | dloman | FYI, Ed's in today. |
| 14:47.04 | CIA-53 | BRL-CAD: 03davidloman * r43161 10/geomcore/trunk/src/interfaces/java/auto-props.cfg: Update sample auto-props file with more mime-types. |
| 14:49.53 | CIA-53 | BRL-CAD: 03davidloman * r43162 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/ (9 files in 3 dirs): Clean up existing and add missing headers. |
| 14:59.35 | brlcad | dloman: heh, what's with the sample auto-props? |
| 15:00.47 | dloman | getting autoprops on winderz is a PITA, especially here at work. so i figgered i'd put in a file to help |
| 15:00.52 | brlcad | much more extensive "sample" on the website: http://brlcad.org/wiki/Mime-types |
| 15:01.55 | dloman | kk, i'll link that. danke. |
| 15:03.48 | brlcad | begins final release distcheck |
| 15:04.37 | dloman | the word 'distcheck' still makes me take look twice |
| 15:06.33 | brlcad | you have to look twice to find it? |
| 15:06.45 | brlcad | oh SNAP! no he didn't |
| 15:07.17 | dloman | ohnoe u dint! (repeat x4) |
| 15:09.23 | CIA-53 | BRL-CAD: 03brlcad * r43163 10/brlcad/branches/STABLE/ (4855 files in 354 dirs): merge trunk to STABLE from r41558 to HEAD r43158 |
| 15:18.04 | starseeker | brlcad: heh - ruined commits due to prop issues suck - I still wish svn let us check that before we go through the network process... |
| 15:18.18 | starseeker | especially fun when upgrading tcl/tk |
| 15:21.55 | ``Erik | *readreadread* np my ass |
| 15:23.39 | dloman | eh? |
| 15:25.03 | ``Erik | dlo: I think, uh, we'll move GS to bu, then fix win32 bu threading |
| 15:25.20 | dloman | okie. |
| 15:25.33 | dloman | I was just thinking about all the areas that QT is in |
| 15:25.41 | dloman | and realized its in the threading also. |
| 15:25.51 | ``Erik | jbrlcad is, uh, ... probably not very relevant |
| 15:28.42 | ``Erik | aight, all caught up |
| 15:29.10 | ``Erik | yeh, I'm de-qt'ing it pretty heavily, it winds all up and down, but we'll get there :) 'sall good |
| 15:30.22 | ``Erik | (the np comment was about tesselation, I'm fairly certain it's not np, I'm thinking more in the n^2 or nlgn if done right... we have a feeble implementation) |
| 15:38.58 | CIA-53 | BRL-CAD: 03starseeker * r43164 10/geomcore/trunk/src/other/sqlite/ (CMake/ CMake/ResolveCompilerPaths.cmake CMakeLists.txt): Try looking for dl for sqlite |
| 15:41.26 | starseeker | dloman: does that help? |
| 15:41.33 | dloman | one sec |
| 15:42.43 | dloman | Sure does! *thumbs up* |
| 15:47.52 | CIA-53 | BRL-CAD: 03starseeker * r43165 10/geomcore/trunk/cmake/FindTCL.cmake: |
| 15:47.52 | CIA-53 | BRL-CAD: Ironically, our new FindTCL isn't suitable for finding BRL-CAD's tcl/tk, since |
| 15:47.52 | CIA-53 | BRL-CAD: it requires the .sh config files from Tcl and the new CMake build isn't |
| 15:47.52 | CIA-53 | BRL-CAD: generating or installing them (did our autotools build, for that matter?). Need |
| 15:47.52 | CIA-53 | BRL-CAD: to have the CMake build for tcl/tk generate those .sh files |
| 15:55.38 | ``Erik | heh |
| 16:08.03 | CIA-53 | BRL-CAD: 03Dloman 07http://brlcad.org * r2468 10/wiki/NetMsgTypes: Update MsgType chart with accurate info. |
| 16:09.12 | CIA-53 | BRL-CAD: 03erikgreenwald * r43166 10/geomcore/trunk/ (89 files in 9 dirs): removal of some unnecessary QT-isms |
| 16:09.17 | CIA-53 | BRL-CAD: 03Dloman 07http://brlcad.org * r2469 10/wiki/NetMsgTypes: Changed verbage and added 8byte generic msgtype |
| 16:34.09 | CIA-53 | BRL-CAD: 03Dloman 07http://brlcad.org * r2470 10/wiki/NetMsgTypes: Typo fix |
| 16:39.52 | CIA-53 | BRL-CAD: 03davidloman * r43167 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ (NetMsgFactory.java msg/NetMsgTypes.java): Sync msgTypes with GeomCore module. |
| 17:15.22 | *** join/#brlcad jay_ (~jay@212.96.10.253) | |
| 17:18.00 | jay_ | hello |
| 17:19.35 | jay_ | you guys know of any linux architectural CAD app? |
| 17:55.36 | starseeker | jay_: depends on what you're after - commercially, there's this http://www.cycas.de/ |
| 17:56.24 | starseeker | maybe this is of interest? http://sourceforge.net/projects/sweethome3d/ |
| 17:59.16 | CIA-53 | BRL-CAD: 03erikgreenwald * r43168 10/geomcore/trunk/src/utility/DataStreamUtils.cxx: fix ambiguous overload error |
| 18:03.28 | brlcad | ``Erik: with floating point math, solving boolean evaluation for polygonal topology is not just n^2 even though the core algorithm is |
| 18:03.31 | starseeker | ``Erik: that's got it on the mac |
| 18:04.45 | brlcad | it becomes a search problem, you have to make blind guess decisions at which point there's no longer a single "final solution" .. there's a set of solutions and you're looking for a valid solution, which is not easy |
| 18:05.19 | starseeker | still one in Linux - GenericEightBytesMsg.c:31: prototype not matching |
| 18:05.45 | starseeker | error: prototype for 'GenericEightBytesMsg::GenericEightBytesMsg(uint32_t, quint64)' does not match any in class 'GenericEightBytesMsg' |
| 18:06.33 | starseeker | few others... |
| 18:07.55 | brlcad | consider the simple example of the subset sum problem, which is np-complete -- it states given a set of integers, do any non-empty subset of them add up to zero |
| 18:08.49 | brlcad | that same characterization can be made of vertices during evaluation, given a set of points, do any non-empty subset of them coincide (i.e., are the same point) |
| 18:09.55 | brlcad | that and other hard questions get repeatedly asked, a decision is made, and the underlying O(N^2) algorithm continues to the next edge/vertex/face/shell/object |
| 18:12.58 | CIA-53 | BRL-CAD: 03davidloman * r43169 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/RemoteNodeNameSetMsg.java: Implement RemoteNodeNameSetMsg in java. |
| 18:14.54 | jay_ | starseeker: thnx |
| 18:21.01 | dli | brlcad, do you mean any repeated point? |
| 18:21.22 | dli | brlcad, or give a list of subsets, any repeated? |
| 18:21.30 | CIA-53 | BRL-CAD: 03erikgreenwald * r43170 10/geomcore/trunk/src/libNet/PortalManager.cxx: add missing parameter |
| 18:25.05 | CIA-53 | BRL-CAD: 03erikgreenwald * r43171 10/geomcore/trunk/src/ (3 files in 2 dirs): snprintf type fixes |
| 18:32.49 | brlcad | dli: given a set of points, which are equal to other points within a given tolerance |
| 18:34.45 | brlcad | even with exact non-floating point computation, if you add a "within tolerance" qualifier, you suddenly have np-hard decision searching |
| 18:35.04 | brlcad | floating point just adds an implicit tolerance on top of a geometric tolerance |
| 18:36.03 | dli | brlcad, partition the coordinates according the tolerance, so, from real x -> integer i_x = [ x/dr +0.5], now, you only have to search within i_x plus/minus 1, j_y plus/minus 1, etc. O(N) |
| 18:40.16 | dli | brlcad, if we can waste on memory, partition points to a 3d array, search is still O(N) |
| 18:42.19 | CIA-53 | BRL-CAD: 03erikgreenwald * r43172 10/geomcore/trunk/ (40 files in 9 dirs): switch from QT typedefs to standard typedefs |
| 18:43.12 | dli | brlcad, suppose the wanted tolerance is tiny, partitioning to 1/dr is impractical, we can simply use an intermediate (dr0), now, only have to search within neighbours of (dr0), divide and conquer |
| 18:57.11 | CIA-53 | BRL-CAD: 03starseeker * r43173 10/geomcore/trunk/cmake/ (10 files): Clean out some of the unneeded .cmake files - may be more scrubbing to do here. |
| 18:57.28 | brlcad | dli: the tolerance is generally very very tiny in relation to the value |
| 18:57.53 | brlcad | moreover, depending on how you group points will affect the resulting decision |
| 18:57.58 | dli | brlcad, then, use a reasonable intermediate dr0 |
| 18:58.29 | brlcad | there is no definition of reasonable that applies to arbitrary geometry |
| 18:58.36 | dli | brlcad, only search within neighborhood of dr0 |
| 18:58.46 | CIA-53 | BRL-CAD: 03starseeker * r43174 10/geomcore/trunk/ (12 files in 9 dirs): Start working on getting the tests running again - leave them off for now, as there's a fair bit of work to do. |
| 18:58.47 | brlcad | define neighborhood |
| 18:58.55 | dli | brlcad, no, but as far as it's fast for most cases |
| 18:59.13 | brlcad | so you get a wrong answer fast .. that's not very useful :) |
| 18:59.31 | dli | brlcad, no, this algorithm doesn't get any wrong answer |
| 18:59.41 | brlcad | this is a problem best explained with a white board |
| 18:59.50 | dli | brlcad, anything outside of dr0 wont be within dr |
| 19:00.17 | brlcad | if you have a proof, then you'd have a ground-breaking research paper -- the geometry is nowhere near as rigorous or clean as it sounds like you're presuming |
| 19:00.46 | brlcad | the tolerance has to be big enough so points will merge together, this is a good thing |
| 19:01.01 | brlcad | but too big, and it'll join topology that should not be joined |
| 19:01.34 | brlcad | in practice that is a weighted local tolerance that might take curvature, topology, and other factors into account |
| 19:01.48 | brlcad | just assuming a hard 0.000# tolerance just doesn't work |
| 19:01.56 | brlcad | no matter how small you make it |
| 19:03.07 | brlcad | and it STILL doesn't address the impact of deciding a coinciding point that are within tolerance |
| 19:03.22 | brlcad | consider three points: A, B, C |
| 19:03.24 | dli | brlcad, http://num-meth.srcc.msu.ru/english/zhurnal/tom_2010/v11r135.html |
| 19:03.42 | brlcad | A is within tolernace of B, B is within tolerance of C, but A is not within tolerance of C |
| 19:04.37 | brlcad | how you join those will result in different topology, and there is no knowledge about which choice is right other than the final geometry being considered "valid" or not |
| 19:04.49 | dli | brlcad, I'm still not clear whether voronoi cell is relevant here, voronoi is n log(n), more robust than neighbor searching algorithms |
| 19:06.37 | brlcad | dli: not sure what you're trying to show with that paper, but at a glance it looks like a simple spatial partitioning of your comparisons -- that's merely optimization (and not particularly relevant since you're generally not comparing that many neighboring points) |
| 19:07.17 | dli | brlcad, neighbor searching is not robust, I know that, but voronoi is robust |
| 19:07.19 | brlcad | it's the same problem even if you try to carve up voronoi neighborhoods |
| 19:07.47 | brlcad | you have to decide where to split and there is no definition of how/where to split |
| 19:07.58 | brlcad | take that three-point example -- that's about as basic as it gets |
| 19:08.34 | dli | brlcad, original voronoi problem doesn't require definition of neighbors, http://en.wikipedia.org/wiki/Voronoi_diagram |
| 19:09.14 | brlcad | how is that helping? |
| 19:09.24 | dli | brlcad, it will generate voronoi diagram on any 3 points on plane, I'm not clear how the algorithm with behavior with repeated points |
| 19:09.42 | brlcad | how is that helping? |
| 19:09.59 | dli | brlcad, let's suppose no repeated points, all points a different by tiny distance |
| 19:10.24 | brlcad | sure |
| 19:10.31 | dli | brlcad, then, generate voronoi cells, find the small cells, test the points with its neighbors (as defined by voronoi) |
| 19:11.02 | brlcad | test them for what? |
| 19:11.31 | brlcad | take the simple ABC case, what's being tested? |
| 19:11.32 | dli | brlcad, for each point, get the distance to its voronoi neighbors |
| 19:11.46 | brlcad | okay, that's distance AB, BC, and AC |
| 19:11.54 | brlcad | now what? |
| 19:12.10 | dli | brlcad, now, decide whether within tolerance |
| 19:12.26 | brlcad | okay, AB are within tol, BC are within tol, AC are not |
| 19:12.26 | dli | brlcad, the good thing is that, after voronoi, it's O(N) |
| 19:12.28 | brlcad | now what? |
| 19:12.54 | dli | brlcad, oh, that's another question :( |
| 19:13.12 | brlcad | follow this through, you're still not getting the problem -- I know what voronoi are and do, but finding neighbors isn't the problem |
| 19:13.44 | dli | brlcad, I thought the problem is finding neighbor, now, it's the definition of neighbor |
| 19:13.52 | brlcad | bingo |
| 19:15.28 | brlcad | topologically with A, B, and C, you might want to join A+B and keep C separate .. or join B+C and leave A separate .. or loosen the tolerance and join A+B+C |
| 19:15.34 | dli | so, what about just give it tighter tolerance? then, just randomly combine points, until no overlap exists |
| 19:16.07 | brlcad | tighten the tolerance, and you avoid joining A B and C altogether, and your topology is broken/invalid |
| 19:16.52 | brlcad | in practice, you'll want either [A+B, C] or [A, B+C] .. but you just don't know which one is right (or if either of them is right) |
| 19:17.13 | brlcad | generally one of them is right, the other is not but it becomes a decision tree |
| 19:17.20 | dli | brlcad, no, I don't understand this. tighter tolerance shouldn't break anything |
| 19:17.56 | brlcad | understandable, hard to see with just three points |
| 19:18.17 | brlcad | topologically, you're stitching together geometry -- polygon faces or spline surfaces |
| 19:18.37 | brlcad | you're trying to decide whether polygon 1 attaches to polygon 2 |
| 19:18.53 | brlcad | so you might compare the vertices of 1 with the vertices of 2 |
| 19:19.35 | brlcad | for solid geometry, all meshes must enclose space |
| 19:19.44 | brlcad | otherwise they are just infinitely thin dangling faces |
| 19:20.37 | dli | brlcad, yes, I see the rough picture now |
| 19:20.41 | brlcad | if you tightened your tolerance to .. 0 .. then only vertices that are exact-exact matches join (which isn't practical with floating point), so it basically won't think those two faces are topologically connected when they should be |
| 19:21.18 | brlcad | loosen the tolerance too much and you end up joining faces that are "close" but shouldn't be joined _toplogically_ |
| 19:21.52 | brlcad | it really is a pretty fucking hard problem (pardon my language) to make robust |
| 19:22.29 | dli | brlcad, I suppose to write a function to generate intersection, so, I have to handle this problem |
| 19:22.47 | brlcad | in an ideal world, you'd keep track of your decision tree as you progress through the evaluations, use a floating/variable tolerance that adjusts to topology, and have a means to unroll back through decisions when you end up with invalid results |
| 19:23.22 | brlcad | strictly speaking yes you will, but it's not nearly as bad for surface surface evaluations |
| 19:23.53 | brlcad | it's a problem for the code that will USE your surface-surface function :) |
| 19:24.30 | dli | brlcad, let try and see how it works out |
| 19:24.35 | CIA-53 | BRL-CAD: 03starseeker * r43175 10/geomcore/trunk/tests/GS/GeometryServiceTest.cxx: Make a stab at GeometryServiceTest |
| 19:25.48 | brlcad | dli: mind you, in practice, you can generally find a "sweet spot" tolerance or set of tolerances that will make it all work and evaluate correctly for a given input -- my ranting is merely addressing the np-hardness of the underlying decision problem |
| 19:26.06 | brlcad | you can make AB/BC/AC decisions for 99% of geometry just fine |
| 19:26.48 | brlcad | the issue is usually error accumulation, that's where NMG (our polygon library) has problems |
| 19:27.10 | dli | brlcad, if so, can we use integer instead? |
| 19:27.14 | brlcad | like I said earlier with the [A+B, C] or [A, B+C] decision case, you'll probably pick one of those two results |
| 19:27.32 | brlcad | but whether you join A+B or B+C .. what value do you actually use? |
| 19:27.48 | dli | brlcad, 64bit integer would be good enough |
| 19:27.52 | brlcad | A+B -> A's value? B's value? the midpoint of A+B? |
| 19:28.09 | brlcad | all three options results in point drift |
| 19:28.54 | dli | brlcad, still error accumulating |
| 19:31.52 | CIA-53 | BRL-CAD: 03erikgreenwald * r43176 10/geomcore/trunk/tests/ (libEvent/BasicEventTest.cxx utility/configTest.cxx): de-QT some more |
| 19:34.05 | brlcad | dli: yep, the all _potentially_ accumulate error |
| 19:34.55 | brlcad | if "A" is right, then C won't be merged ... if you pick B's value or midpoint of A+B, then you might actually even now be within tolerance of C .. which effectively collapses to A+B+C |
| 19:36.13 | brlcad | whether you use floating point or integer comparisons won't really make much of a difference is my gut feeling. it might give you locally stable behavior but not algorithmic stability |
| 19:36.56 | brlcad | the best results I've seen use interval arithmetic, which can be done with floating just fine |
| 19:37.12 | brlcad | it's basically a way to track the error |
| 19:38.30 | brlcad | you can get the same result by recording a ULP and the local per-vertex error |
| 19:44.17 | dli | brlcad, instead of seeing error accumulating, I feel it can be self-healing, to adjust points according to the direction/side of solid |
| 19:45.03 | dli | brlcad, whatever the adjustment, it never gives broken topology |
| 19:46.30 | CIA-53 | BRL-CAD: 03erikgreenwald * r43177 10/geomcore/trunk/tests/utility/CMakeLists.txt: copy test config file to bin dir |
| 19:51.01 | CIA-53 | BRL-CAD: 03starseeker * r43178 10/geomcore/trunk/ (6 files in 4 dirs): Gets the tests almost building, although not sure how correct the changes are. |
| 19:51.19 | brlcad | dli: that's not a bad idea, and probably possible, but definitely not easy |
| 19:51.41 | brlcad | our NMG library does something like that now, trying to make sure it's never broken as evaluation progresses |
| 19:52.34 | dli | brlcad, nice, good enough for me to try |
| 19:52.40 | brlcad | the problem is that it's still a decision tree and there are invalid decision nodes that might lead to valid (desireable) final states, or numerous competing valid states ( like [A+B, C] or [A, B+C] ) |
| 19:53.55 | CIA-53 | BRL-CAD: 03starseeker * r43179 10/geomcore/trunk/tests/libEvent/BasicEventTest.cxx: There we go - get BasicEventTest compiling too. |
| 19:56.49 | CIA-53 | BRL-CAD: 03davidloman * r43180 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/ (AbstractNetMsg.java RemoteNodeNameSetMsg.java): Updated AbstractNetMsg's deserial cstr to take the msg type. Type will be deserialized in order to determine how to construct an AbstractNetMsg object anyways, so it needs to be set by a subclass. |
| 19:59.43 | CIA-53 | BRL-CAD: 03brlcad * r43181 10/brlcad/trunk/src/libfb/if_ogl.c: linux is using __USE_BSD and __USE_XOPEN_EXTENDED in order to get to the getpagesize() declaration. |
| 20:00.35 | CIA-53 | BRL-CAD: 03davidloman * r43182 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSStatics.java: Add a static for libpkg's header size. |
| 20:00.55 | starseeker | GenericEightBytesMsg.cxx:44: error: no match for 'operator>>' in '* ds >> ((GenericEightBytesMsg*)this)->GenericEightBytesMsg::data' |
| 20:01.55 | CIA-53 | BRL-CAD: 03brlcad * r43183 10/brlcad/branches/STABLE/src/libfb/if_ogl.c: merge r43181 from trunk |
| 20:02.26 | CIA-53 | BRL-CAD: 03erikgreenwald * r43184 10/geomcore/trunk/src/utility/Config.cxx: simplify and correct line parsing logic |
| 20:03.26 | brlcad | bah |
| 20:20.56 | CIA-53 | BRL-CAD: 03brlcad * r43185 10/brlcad/trunk/src/libfb/if_ogl.c: it actually needs __USE_XOPEN and __USE_BSD to get to the decl, so add them both with ifndef protection. this suckage belongs in libbu. |
| 20:21.54 | CIA-53 | BRL-CAD: 03brlcad * r43186 10/brlcad/branches/STABLE/src/libfb/if_ogl.c: merge r43183 from trunk for the getpagesize() fix when compiling with ogl enabled on linux |
| 20:22.23 | epileg | I want to improve the brlcad mime type on Linux. It appears that all geometry db files begin with "76 01 00 00 00 00 01 35 76". Is this correct? |
| 20:24.02 | CIA-53 | BRL-CAD: 03davidloman * r43187 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/NewSessionReqMsg.java: Implement NewSessionReqMsg in java. |
| 20:26.29 | ``Erik | not necessarily... 0x76 is the magic for our version 5 db, but the second byte is flag information |
| 20:26.38 | ``Erik | um, include/db5.h shows the on disk header |
| 20:26.56 | brlcad | the first 8 bytes should be right |
| 20:27.22 | CIA-53 | BRL-CAD: 03davidloman * r43188 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/SessionInfoMsg.java: Implement SessionInfoMsg in java. |
| 20:27.28 | brlcad | but yeah, that only applies v5 too -- v4 looks rather different |
| 20:28.43 | epileg | but the db version is so variant? |
| 20:29.28 | epileg | and what's the header bytes on v4? |
| 20:30.00 | brlcad | don't worry about v4, they're older files |
| 20:30.58 | epileg | just for people who has some db v4 files |
| 20:32.45 | brlcad | if you really want to be flexible, you can only count on the first byte being 76 and the eigth byte being 35 for v5 |
| 20:35.12 | ``Erik | I don't think there is head magic for v4 |
| 20:35.31 | epileg | hmmmm, I'll try just for v5. |
| 20:37.46 | brlcad | v4 files start with an 'ident' record |
| 20:38.12 | brlcad | so it'll be something like 'I?v4' 49 01 76 34 |
| 20:38.44 | brlcad | version key again being 76 and 34 |
| 20:39.22 | ``Erik | should probably have a bit more magic for v6 O.o |
| 20:39.22 | epileg | aha |
| 20:40.35 | brlcad | yeah, [0]==76 [7]==36 :) |
| 20:41.02 | epileg | for v4? |
| 20:41.09 | brlcad | that'd be "v6" :) |
| 20:41.14 | brlcad | which doesn't exist yet |
| 20:41.33 | epileg | ops, ok |
| 20:43.52 | CIA-53 | BRL-CAD: 03davidloman * r43189 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: |
| 20:43.52 | CIA-53 | BRL-CAD: Implement first pass at a GSConnection object. GSConnection contains a static |
| 20:43.53 | CIA-53 | BRL-CAD: factory method that will create a GSConnection, handshake and authenticate with |
| 20:43.53 | CIA-53 | BRL-CAD: a GS Server. Socketing is blocking as the responsibility for polling/selecting |
| 20:43.53 | CIA-53 | BRL-CAD: is tossed to the user of this interface. |
| 20:47.16 | brlcad | initial release build seems to work |
| 20:47.57 | brlcad | funkyness in archer (rt crashes, display doesn't update on start) but rtwizard and mged seem to be doing alright |
| 20:57.08 | CIA-53 | BRL-CAD: 03starseeker * r43190 10/brlcad/branches/cmake/include/config_win_cmake.h: This should be coming from src/other now... |
| 21:37.19 | CIA-53 | BRL-CAD: 03brlcad * r43191 10/brlcad/tags/rel-7-18-2/: tagging release 7.18.2 |
| 21:53.26 | CIA-53 | BRL-CAD: 03brlcad * r43192 10/brlcad/trunk/include/conf/PATCH: release is tagged, bump to 7.18.3 |
| 21:53.57 | CIA-53 | BRL-CAD: 03brlcad * r43193 10/brlcad/trunk/ (NEWS README): prepare for next expected 7.18.4 release |
| 21:58.55 | brlcad | would someone else mind sanity testing the 7.18.2 tag? |
| 21:59.11 | brlcad | BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.2 is posted (20110209) |
| 22:06.56 | brlcad | have at it ``Erik |
| 22:07.09 | starseeker | brlcad: I'm compiling now |
| 22:09.43 | brlcad | thx |
| 22:15.38 | ``Erik | hm, solids.sh regress 3 off by many |
| 22:15.55 | ``Erik | on 32b fbsd, but not on 64b linux |
| 22:16.00 | ``Erik | interesting |
| 22:17.42 | brlcad | yeah, I've seen that one before too |
| 22:18.33 | brlcad | I put a note in the BUGS file for it, been failing with an (one) off-by-many error on an optimized mac build |
| 22:18.57 | brlcad | iirc it was grazing the edge of an arb8 |
| 22:22.18 | CIA-53 | BRL-CAD: 03starseeker * r43194 10/brlcad/branches/cmake/src/other/ (tcl/CMakeLists.txt tk/CMakeLists.txt): Looks like these flags may be causing trouble - comment out for now... |
| 22:27.38 | starseeker | urm. Getting Itcl_Init ERROR |
| 22:28.30 | starseeker | looks like libitcl3.4.la is there, but not the .so |
| 22:31.13 | starseeker | installed version does OK though |
| 22:31.17 | starseeker | just build dir |
| 22:31.43 | ``Erik | does a fresh checkout to see how bad he broke it |
| 22:32.13 | *** join/#brlcad CIA-62 (~CIA@208.69.182.149) | |
| 22:43.19 | CIA-62 | BRL-CAD: 03starseeker * r43196 10/brlcad/branches/cmake/src/other/ (tcl/CMakeLists.txt tk/CMakeLists.txt): Let's try this again without nuking all the TK_FLAGS in the process... |
| 00:12.08 | starseeker | notes this might be a useful tidbit down the road with ogre: http://www.ogre3d.org/forums/viewtopic.php?f=2&t=60677 |
| 00:28.33 | CIA-62 | BRL-CAD: 03starseeker * r43197 10/geomcore/trunk/include/ (DataStreamUtils.h Event.h JobManager.h Logger.h NetMsg.h): Should probably add some HAVE_* logic for this, but need some stdint and stdio inclusions |
| 01:07.18 | starseeker | humph - the beta 8.6 tcl/tk link on the main website dates to Dec 2008 |
| 01:09.32 | starseeker | eyes the new sf.net/projects/brlcad look after the update... |
| 01:56.22 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 02:57.40 | *** part/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 04:03.07 | CIA-62 | BRL-CAD: 03starseeker * r43198 10/brlcad/branches/cmake/ (3 files in 3 dirs): Instead of one target per file, try to get one per list working for data copying. More reasonable target count, but some of them aren't terminating even though files appear to be copies successfully. |
| 04:19.38 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2471 10/wiki/Community_Publication_Portal: 7.18.2 posted |
| 04:46.56 | brlcad | nice refactoring on the de-qt'ing ``Erik |
| 05:08.41 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 06:25.53 | *** join/#brlcad cosurgi (~cosurgi@atak.bl.pg.gda.pl) | |
| 07:11.36 | CIA-62 | BRL-CAD: 03jordisayol * r43199 10/brlcad/trunk/ (21 files in 4 dirs): add magic mime-type association to geometry db file in GNU/Linux |
| 07:11.53 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 07:27.31 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 07:46.10 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 12:52.45 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:11.51 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 13:19.29 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 15:50.56 | starseeker | Huh, interesting: http://neugierig.org/software/chromium/notes/2011/02/ninja.html |
| 16:06.28 | brlcad | which part, someone reinventing the wheel or that a reduction of a few seconds off a short build is significant? :) |
| 16:57.09 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 17:36.46 | starseeker | brlcad: more the minimalist nature and the possibility of something like CMake generating it to make long builds faster |
| 17:43.45 | CIA-62 | BRL-CAD: 03erikgreenwald * r43200 10/geomcore/trunk/src/ (CMakeLists.txt coreInterface/): remove coreInterface |
| 17:48.54 | brlcad | coreInterface for all intensive purposes is the Geometry Engine |
| 17:51.33 | ``Erik | eh? it's not in the current build path, I thought it was Dan's thing? |
| 17:51.53 | brlcad | all true |
| 17:52.14 | brlcad | but it's still basically almost the exact embodiment of what the GE is supposed to be |
| 17:52.34 | brlcad | an OO wrapper over librt, similar to the ACIS engine |
| 17:52.56 | brlcad | no service/user/network concepts, that's all GS territory |
| 17:53.38 | ``Erik | vs src/GS/libGeometry ? |
| 17:53.49 | brlcad | not saying it needs to be in geomcore, but it definitely is the direction we should be moving towards |
| 17:53.59 | brlcad | right |
| 17:54.31 | ``Erik | *shrug* it's in the history as well as rt^3, figure it out when we get there, I guess |
| 17:54.53 | starseeker | what's the relationship with src/GE ? |
| 17:55.52 | brlcad | dave really didn't look at coreInterface afaik, as he doesn't yet have it doing any geometry processing .. the little bit that is in there he rolled on his own |
| 17:56.15 | brlcad | coreInterface, however is MUCH farther along and in the right direction |
| 17:56.21 | brlcad | it really should just be named "GE" |
| 17:56.49 | brlcad | merging it in should be on our short-term todo |
| 17:56.51 | starseeker | nods - so coreInterface -> GE, merge in whatever bits in current GE might be needed |
| 17:58.29 | brlcad | it really is a brilliantly clean design, daniel did some nice work there leveraging libbu, libbn, librt, and libwdb |
| 17:58.55 | brlcad | has proper bu exception handling, uses rt_db_internal data types as private member data, good object relationships |
| 18:00.11 | starseeker | cool |
| 18:01.11 | brlcad | if you look in the current GE/libGeometry work, it's basically all stubbed empty and unused or it's old classes that I wrote years ago when starting the GE |
| 18:02.38 | brlcad | that was way back when the goal was focusing on a ray trace service (hence the raytrace daemon, rt^3d, and the database daemon, rt^3dbd) |
| 18:09.50 | starseeker | brlcad: ok, I'll take a look at at moving coreInterface to GE |
| 18:12.03 | brlcad | some of what's in libGeometry could be merged, other parts can be removed .. would take some basic code review to see what's of value |
| 18:15.30 | CIA-62 | BRL-CAD: 03bob1961 * r43201 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Reset output handler when going to/from a separate command window configuration. |
| 18:32.27 | CIA-62 | BRL-CAD: 03erikgreenwald * r43202 10/geomcore/trunk/ (57 files in 12 dirs): Eliminate QT map/list/string/stringlist in favor of std:: |
| 18:36.14 | brlcad | woot |
| 18:37.27 | brlcad | thinks it's hilarious that most of the std:: conversions for qt are search-n-replaceable .. there's really no reason to replicate the standard library these days |
| 18:41.33 | ``Erik | mostly :%s, but some algorithmic changes had to happen, too... and some still need reworked |
| 18:47.54 | CIA-62 | BRL-CAD: 03starseeker * r43203 10/brlcad/branches/cmake/ (3 files in 3 dirs): (log message trimmed) |
| 18:47.54 | CIA-62 | BRL-CAD: Use a sentinel file instead of listing all of the output directories - approach |
| 18:47.54 | CIA-62 | BRL-CAD: suggested by David Cole on the CMake list, seems to work and build doesn't keep |
| 18:47.54 | CIA-62 | BRL-CAD: recopying files. Also tweak the tclscript routines to depend on the file used |
| 18:47.54 | CIA-62 | BRL-CAD: by the copy target. Disable the option to turn targets on/off - now needed for |
| 18:47.55 | CIA-62 | BRL-CAD: tclscripts build, no longer spewing one target for file, and anyway the build |
| 18:47.56 | CIA-62 | BRL-CAD: should ensure changes made to data files in the src dir are reflected in the |
| 21:11.49 | CIA-62 | BRL-CAD: 03starseeker * r43204 10/geomcore/trunk/ (data/ m4/ media/ misc/ sandbox/): Remove some more stuff that's either unused or not related to geomcore |
| 21:14.17 | CIA-62 | BRL-CAD: 03starseeker * r43205 10/geomcore/trunk/src/GE/coreInterface/ (22 files): Put coreInteface back as a subdirectory of GE - eventually this should become the core of GE |
| 22:32.30 | CIA-62 | BRL-CAD: 03erikgreenwald * r43206 10/geomcore/trunk/src/utility/Config.cxx: eliminate QFile/QFileInfo in favor of standard ansi C |
| 23:13.04 | *** join/#brlcad dli (~dli@dyn-216-076.wireless.concordia.ca) | |
| 00:01.15 | CIA-62 | BRL-CAD: 03starseeker * r43207 10/geomcore/trunk/cmake/ (FindBRLCAD.cmake FindCPPUNIT.cmake): Start playing with FindBRLCAD.cmake - still quite a lot to do here, this is an intermediate state. |
| 00:22.06 | CIA-62 | BRL-CAD: 03jordisayol * r43208 10/brlcad/trunk/sh/ (make_deb.sh make_rpm.sh): correct an error on deb and rpm scripts |
| 00:29.42 | starseeker | Hmm, interesting: http://www.geometrictools.com/ |
| 00:31.15 | starseeker | lot of writeups: http://www.geometrictools.com/Documentation/Documentation.html |
| 00:31.52 | starseeker | sweet, boost license |
| 00:53.30 | *** part/#brlcad cosurgi (~cosurgi@atak.bl.pg.gda.pl) | |
| 00:59.30 | brlcad | starseeker: nice link |
| 00:59.58 | starseeker | was poking around looking for stuff to help Richard |
| 01:00.26 | brlcad | he's stuck? |
| 01:00.39 | brlcad | he's certainly stopped committing |
| 01:01.07 | starseeker | he's looking for a really robust line-line intersection routine (or more correctly, closest distance between two 3D lines) |
| 01:01.18 | dli | brlcad, I'm reading the files in src/pro-db, need more time for understanding, but I can see the complexity of work done is still quite light, like 2,000 lines to me |
| 01:01.33 | brlcad | starseeker: and libbn's is insufficient? |
| 01:01.39 | starseeker | apparently |
| 01:02.07 | starseeker | he wasn't set up to take me through all the details tonight |
| 01:02.12 | dli | brlcad, also, the idea of "self-healing" I mentioned was already there, "linear perturbation" in the poster link you posted |
| 01:02.58 | brlcad | starseeker: if ours isn't sufficient, then he should be able to characterize how/why and fix it .. not duplicate the code with another function |
| 01:03.23 | brlcad | validating ours against an algorithm would be cool, but definitely shouldn't just be snarfing in another function |
| 01:03.46 | brlcad | rewriting ours would even be fair game -- that's the point of the testing framework |
| 01:03.49 | starseeker | nods - he can't do that with that link anyway, that's C++ code |
| 01:04.38 | dli | brlcad, I need to understand how it works now, then, I will try to see what is a good approach from here |
| 01:04.41 | starseeker | I think he's identified come failing test cases but isn't sure what to do to fix them |
| 01:04.48 | brlcad | http://www.geometrictools.com/Documentation/DistanceLine3Line3.pdf isn't c++ |
| 01:05.10 | starseeker | true - I sent him that link to see if it would help |
| 01:05.26 | brlcad | dli: sounds good |
| 01:05.58 | brlcad | dli: I'd hope it's not too heavy .. then people's brains shut off and they tend to start from scratch |
| 01:06.17 | brlcad | wasted effort |
| 01:07.22 | starseeker | I just ment he couldn't snarf the geometrictools code directly - he'll still need to figure out how to do it in our code |
| 01:07.47 | dli | brlcad, should be fine, I expected like 10,000 lines, it's not that bad, 2,000 lines, if comments not counted, and rewrite in C++ style (now, it's like C style C++), my guess is like 500 lines, fair for me to start |
| 01:09.58 | brlcad | dli: note that's just one function you're working on -- there's several other routines that will be needed later :) |
| 01:11.51 | dli | brlcad, okay, I will concentrate on that part |
| 01:12.33 | brlcad | surface,surface->curve is really surface,surface->surface|curve|point .. which is really also a parent case of surface,point->point + surface,curve->curve|point + surface,surface->surface|curve |
| 01:12.57 | brlcad | at least when you consider the grazing cases |
| 01:14.59 | dli | brlcad, I added this to my note, talk to you later |
| 01:30.19 | starseeker | huh http://code.google.com/p/poly2tri/ - I don't recall stumbling on that before |
| 01:35.50 | starseeker | this one too http://www.netlib.org/voronoi/hull.html |
| 03:50.40 | brlcad | the first is interesting, but doesn't look too much different than our current triangulation |
| 05:06.54 | CIA-62 | BRL-CAD: 03brlcad * r43209 10/brlcad/trunk/doc/deprecation.txt: SMALL was deprecated a long time ago, but is a minimally impacting change |
| 05:08.38 | CIA-62 | BRL-CAD: 03brlcad * r43210 10/brlcad/trunk/include/vmath.h: |
| 05:08.38 | CIA-62 | BRL-CAD: provide a ZERO() macro that corresponds with the EQUAL() macro. tolerance is |
| 05:08.38 | CIA-62 | BRL-CAD: defined at compile-time so it's not the best to use, but still more reliable |
| 05:08.38 | CIA-62 | BRL-CAD: than exact floating point comparisons. it'll also permit cleaning up numerous |
| 05:08.38 | CIA-62 | BRL-CAD: NEAR_ZERO() callers that arbitrarily use SMALL, SMALL_FASTF, and |
| 05:08.39 | CIA-62 | BRL-CAD: SQRT_SMALL_FASTF when the intent is just a nearness to zero. |
| 05:25.50 | CIA-62 | BRL-CAD: 03brlcad * r43211 10/brlcad/trunk/src/libbu/units.c: convert from NEAR_ZERO() to ZERO() |
| 05:26.54 | CIA-62 | BRL-CAD: 03brlcad * r43212 10/brlcad/trunk/src/libbn/ (9 files): lots of conversions from NEAR_ZERO() to the new ZERO() macro where the tolerance test is merely against SMALL_FASTF or used to test for zero-division. |
| 05:28.06 | CIA-62 | BRL-CAD: 03brlcad * r43213 10/brlcad/trunk/src/anim/ (anim_fly.c anim_hardtrack.c): start of larger covnersion over to new ZERO() macro. |
| 05:34.27 | CIA-62 | BRL-CAD: 03brlcad * r43214 10/brlcad/trunk/src/librt/ (49 files in 24 dirs): convert from NEAR_ZERO() to ZERO() where SMALL, SMALL_FASTF, and sometimes even where SQRT_SMALL_FASTF is used. simplify. reduction also made where intent seems to be a zero-test for a subsequent division. |
| 07:53.54 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 10:49.23 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 11:48.39 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:06.40 | dloman | Mernin all. |
| 12:58.04 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 14:17.29 | CIA-62 | BRL-CAD: 03davidloman * r43215 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/ (. Main.java MinimalGSClient.java): Beginnings of a minimal test client. Gui looks ok but doesn't do anything.... yet |
| 14:32.48 | CIA-62 | BRL-CAD: 03brlcad * r43216 10/brlcad/trunk/src/libged/ (21 files): another conversion from NEAR_ZERO() to ZERO() where SMALL, SMALL_FASTF, and sometimes where SQRT_SMALL_FASTF is used. simplify. reduction also made where intent seems to be a zero-test for a subsequent division. |
| 14:35.15 | CIA-62 | BRL-CAD: 03davidloman * r43217 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/ (3 files in 2 dirs): Break out gui components into dedicated, individual subclasses of JPanel. This gives better control and expansion flexibility. |
| 14:36.17 | CIA-62 | BRL-CAD: 03starseeker * r43218 10/brlcad/branches/cmake/src/other/openNURBS/ (opennurbs_array_defs.h opennurbs_math.h): Keep tripping on this - just move it, can always put it back if there's a need to keep it in opennurbs_math.h |
| 15:10.42 | ``Erik | jabs brlcad with a pointy stick some |
| 15:17.45 | CIA-62 | BRL-CAD: 03starseeker * r43219 10/brlcad/branches/cmake/src/ (41 files in 35 dirs): |
| 15:17.45 | CIA-62 | BRL-CAD: Tweaks to get BRL-CAD compiling with the latest clang/clang++ - a few things |
| 15:17.45 | CIA-62 | BRL-CAD: that look legit, lot of adding of UNUSED and removal of self assignments - if |
| 15:17.45 | CIA-62 | BRL-CAD: there was a reason to avoid UNUSED in these cases will have to revert and try |
| 15:17.45 | CIA-62 | BRL-CAD: something else. Somewhat mysteriously, bu_byte_offset didn't cause a compiler |
| 15:17.45 | CIA-62 | BRL-CAD: failure - that's probably incorrect and we still need to do some sort of #if |
| 15:17.48 | CIA-62 | BRL-CAD: defined(__clang__) specific logic there. |
| 15:22.27 | *** join/#brlcad kanzure_ (~kanzure@bioinformatics.org) | |
| 15:22.27 | *** join/#brlcad roberthl (~robert@v001.rhl.me.uk) | |
| 15:22.27 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 15:22.27 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 15:22.27 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 15:22.27 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 15:22.28 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 15:22.28 | *** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no) | |
| 15:22.28 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 15:22.28 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 15:22.28 | *** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ) | |
| 15:22.28 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 15:22.28 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 15:25.37 | *** join/#brlcad d_rossbe1g (~rossberg@BZ.BZFLAG.BZ) | |
| 15:26.18 | *** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ) | |
| 15:26.19 | *** join/#brlcad CIA-6 (~CIA@208.69.182.149) | |
| 15:27.00 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 15:29.31 | CIA-62 | BRL-CAD: 03starseeker * r43220 10/brlcad/branches/cmake/src/other/tnt/ (tnt_array1d.h tnt_fortran_array1d.h tnt_matrix.h): Whoops, missed a couple tnt tweaks |
| 15:29.40 | CIA-6 | BRL-CAD: 03davidloman * r43221 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/CmdConsolePanel.java: Make default prompt work correctly. |
| 15:31.05 | CIA-6 | BRL-CAD: 03davidloman * r43222 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/MinimalGSClient.java: Remove antiquated JText* code |
| 15:31.22 | CIA-6 | BRL-CAD: 03davidloman * r43223 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/RepositoryViewerPanel.java: Swap the JTextArea for a real JTree |
| 15:34.14 | starseeker | saddles up and heads in |
| 16:25.24 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 19:53.46 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 19:53.46 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202) | |
| 20:31.18 | brlcad | epileg: is there a way to specify the dependencies instead of having them auto-specified via dh_shlibdeps ? |
| 20:32.48 | brlcad | for .deb files we put on the website, it makes perfect sense for them to be --enable-all ... for integration with apt, it makes more sense to --disable-all and specify all dependencies |
| 21:13.30 | epileg | I'll change this, and for the next release, I'll try to compile then in a earlier release of ubuntu. |
| 21:14.53 | epileg | yes, manually |
| 21:15.06 | epileg | ...about dependencies |
| 21:17.34 | epileg | but the solid way is to create the deb in a earlier ubuntu/debian release, and auto detect dependencies |
| 21:17.50 | epileg | is just my opinion |
| 21:31.48 | brlcad | you're managing it, so you get to decide .. they're both fine approaches for the project :) |
| 21:32.03 | epileg | thanks |
| 22:10.49 | CIA-6 | BRL-CAD: 03brlcad * r43265 10/brlcad/trunk/include/vmath.h: big cleanup adding in missing 2D 'V2' and 4D 'H' macros that correspond with the 3D 'V' macros. incomplete, but adds a dozen or so that were missing. |
| 22:11.21 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 22:14.24 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 23:20.18 | *** part/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 23:31.07 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 00:00.42 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 03:00.07 | starseeker | O.o openNURBS 5.0 is out |
| 03:00.28 | starseeker | Feb 2nd apparently |
| 04:07.10 | *** join/#brlcad ultra- (~no@cpe-65-25-205-157.new.res.rr.com) | |
| 04:07.13 | ultra- | hi |
| 04:07.20 | ultra- | can someone answer a simple catia question? |
| 07:59.24 | Ralith | starseeker: was that unexpected? |
| 12:13.22 | CIA-6 | BRL-CAD: 03tbrowder2 * r43266 10/brlcad/trunk/src/nirt/nirt.c: quash C90 too-long-stringg warnings |
| 12:33.11 | CIA-6 | BRL-CAD: 03tbrowder2 * r43267 10/brlcad/trunk/include/tie.h: correct macro for externing an int (tie_check_degenerate is not a function) |
| 12:41.32 | louipc | starseeker: wasn't it opennurbs 5.0 before that as well? |
| 13:02.50 | brlcad | ultra-: sorry, no |
| 13:06.01 | brlcad | unless you want to pay me their license fee, then it depends on the question.. ;) |
| 13:33.21 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 13:43.15 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 14:44.23 | starseeker | Ralith: er, yeah - it's an update to 5.0 |
| 14:55.00 | starseeker | oh, great... Nokia and Microsoft announce a "broad strategic partnership" |
| 14:55.28 | starseeker | confound it, that's all we need a danger to Qt |
| 14:56.07 | louipc | you think people won't fork Qt? |
| 15:23.13 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 16:51.05 | ultra- | brlcad sorry i just don't know where else to go with catia questions |
| 16:51.09 | ultra- | for a live chat, at least |
| 17:02.08 | louipc | ultra-: shouldn't you get some kind of live support for the price you pay for that software? hehe |
| 17:03.13 | ultra- | <PROTECTED> |
| 17:03.14 | ultra- | i'm a student |
| 17:04.10 | louipc | ah I guess you're supposed to ask the instructors then |
| 17:09.16 | ultra- | yeah |
| 17:09.20 | ultra- | class is only once a week |
| 17:09.23 | ultra- | i will figure it out :) |
| 17:14.59 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 17:47.42 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 18:13.50 | starseeker | louipc: they probably will, but having all those full time professional developers was one of the major reasons for the polish of Qt across multiple platforms |
| 18:15.04 | starseeker | would really prefer for Trolltech to be spun off from Nokia back to its own company |
| 18:15.50 | starseeker | a fork would mean that the professionally developed changes to Qt would have to be merged into a diverging fork, much like the libreoffice/openoffice situation |
| 18:16.26 | starseeker | and unlike the openoffice setup, Qt has been developed quite effectively up until now |
| 18:25.45 | CIA-6 | BRL-CAD: 03brlcad * r43268 10/brlcad/trunk/src/conv/Makefile.am: make iges and intaval dirs set through a variable so that they can be overridden (and skipped) during make |
| 18:30.00 | CIA-6 | BRL-CAD: 03brlcad * r43269 10/brlcad/trunk/src/conv/Makefile.am: alpha order |
| 18:32.38 | CIA-6 | BRL-CAD: 03brlcad * r43270 10/brlcad/trunk/src/irprep/firpass.c: index->idx |
| 18:34.52 | starseeker | at the very least, I hope an alliance of open source players can announce they'll take over if Nokia drops the ball |
| 20:09.41 | starseeker | ``Erik: what was that you said about a McCLIM based gui? :-P |
| 23:11.57 | CIA-6 | BRL-CAD: 03tbrowder2 * r43271 10/brlcad/trunk/src/librt/primitives/metaball/metaball_tri.c: cleanup format spacing per HACKING |
| 23:34.12 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 23:35.09 | CIA-6 | BRL-CAD: 03tbrowder2 * r43272 10/brlcad/trunk/src/rt/main.c: cleanup format spacing per HACKING |
| 01:20.36 | *** join/#brlcad IriX64 (~IriX64@bas2-sudbury98-1177593317.dsl.bell.ca) | |
| 05:44.06 | *** join/#brlcad Stattrav_ (~Stattrav@122.172.6.241) | |
| 06:41.48 | CIA-6 | BRL-CAD: 03brlcad * r43273 10/brlcad/trunk/ (12 files in 4 dirs): |
| 06:41.48 | CIA-6 | BRL-CAD: implement an initial shp-g shapefile importer for BRL-CAD. this was developed |
| 06:41.48 | CIA-6 | BRL-CAD: in less than a day during Civic Hack Day in order to visualize Baltimore City |
| 06:41.48 | CIA-6 | BRL-CAD: data made available to the public. the converter takes the shapefile input |
| 06:41.49 | CIA-6 | BRL-CAD: (using shapelib) and imports the data as sketch/extrude geomettry. sketches |
| 06:41.49 | CIA-6 | BRL-CAD: working great, extrudes need some debugging love. |
| 09:26.42 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 10:08.00 | *** join/#brlcad ibot (ibot@rikers.org) | |
| 10:08.00 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202) | |
| 10:52.40 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 10:59.39 | dloman | yawns. |
| 12:11.53 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 12:14.39 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:23.50 | CIA-6 | BRL-CAD: 03davidloman * r43274 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/ (5 files in 2 dirs): Add stylized text printing. |
| 12:25.35 | CIA-6 | BRL-CAD: 03davidloman * r43275 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/MinimalGSClient.java: Comment out this local var for now. Will likely remove ActionListener implements in the near future. |
| 13:26.33 | CIA-6 | BRL-CAD: 03tbrowder2 * r43276 10/brlcad/trunk/src/rt/heatgraph.c: eliminate unused variable |
| 13:31.29 | CIA-6 | BRL-CAD: 03tbrowder2 * r43277 10/brlcad/trunk/src/rt/reshoot.c: eliminate unused variable\nclean up space format per HACKING |
| 13:47.33 | CIA-6 | BRL-CAD: 03jordisayol * r43278 10/brlcad/trunk/misc/debian/ (6 files): add magic mime-type for geometry db files v4 on deb/rpm packages |
| 13:58.51 | CIA-6 | BRL-CAD: 03jordisayol * r43279 10/brlcad/trunk/ (misc/debian/rules sh/make_deb.sh sh/make_rpm.sh): switch to build-in for all libraries in deb/rpm packages |
| 14:16.18 | CIA-6 | BRL-CAD: 03d_rossberg * r43280 10/rt^3/tags/rel-7-18-2/: tag the C++ core interface with the corresponding BRL-CAD version (i.e. 7.18.2) |
| 15:20.58 | CIA-6 | BRL-CAD: 03brlcad * r43281 10/brlcad/trunk/src/ (75 files in 27 dirs): convert the remaining NEAR_ZERO(val, SMALL_FASTF) callers to ZERO(val) since the tolerance bound is minimally-defined. lower maintenance, easier to read. |
| 15:31.47 | CIA-6 | BRL-CAD: 03erikgreenwald * r43282 10/brlcad/trunk/src/rt/main.c: fix various cast issues and a missing paren. |
| 15:34.13 | CIA-6 | BRL-CAD: 03erikgreenwald * r43283 10/brlcad/trunk/src/nirt/nirt.c: There is no USAGE or USAGE2 defined, assuming it's broken to the set of bu_log calls. |
| 16:04.08 | CIA-6 | BRL-CAD: 03starseeker * r43284 10/brlcad/branches/cmake/ (114 files in 36 dirs): MFC r43283 - still need to add conv/shp to CMake logic |
| 16:09.30 | ``Erik | sweet, pine segfault |
| 16:09.35 | CIA-6 | BRL-CAD: 03tbrowder2 * r43285 10/brlcad/trunk/src/sig/dpeak.c: clean up space format per HACKING |
| 16:09.58 | CIA-6 | BRL-CAD: 03tbrowder2 * r43286 10/brlcad/trunk/src/sig/dpeak.c: clean up space format per HACKING |
| 16:10.58 | CIA-6 | BRL-CAD: 03tbrowder2 * r43287 10/brlcad/trunk/src/sig/dpeak.c: clean up space format per HACKING |
| 16:11.09 | CIA-6 | BRL-CAD: 03tbrowder2 * r43288 10/brlcad/trunk/src/sig/dpeak.c: clean up space format per HACKING |
| 16:18.56 | CIA-6 | BRL-CAD: 03tbrowder2 * r43289 10/brlcad/trunk/src/sig/dpeak.c: clean up space format per HACKING |
| 16:36.40 | CIA-6 | BRL-CAD: 03tbrowder2 * r43290 10/brlcad/trunk/src/rt/heatgraph.c: correct check for non-negative floating point value |
| 16:38.44 | CIA-6 | BRL-CAD: 03tbrowder2 * r43291 10/brlcad/trunk/src/rt/heatgraph.c: C90 prohibits mixed declarations and code |
| 16:40.10 | CIA-6 | BRL-CAD: 03tbrowder2 * r43292 10/brlcad/trunk/src/rt/heatgraph.c: C90 prohibits mixed declarations and code |
| 16:41.33 | CIA-6 | BRL-CAD: 03tbrowder2 * r43293 10/brlcad/trunk/src/rt/heatgraph.c: correct check for minimum floating point value |
| 16:48.43 | CIA-6 | BRL-CAD: 03tbrowder2 * r43294 10/brlcad/trunk/src/sig/dmod.c: need definition of NEAR_ZERO macro |
| 16:58.25 | CIA-6 | BRL-CAD: 03tbrowder2 * r43295 10/brlcad/trunk/src/sig/dmod.c: need comparisin of NEAR_ZERO with FLT_MIN |
| 18:17.32 | CIA-6 | BRL-CAD: 03tbrowder2 * r43296 10/brlcad/trunk/src/irprep/firpass.c: use float equality comparison macros (with some space formatting along the way) |
| 18:22.25 | CIA-6 | BRL-CAD: 03tbrowder2 * r43297 10/brlcad/trunk/src/irprep/firpass.c: more space formatting per HACKING |
| 18:32.34 | CIA-6 | BRL-CAD: 03jordisayol * r43298 10/brlcad/trunk/sh/make_rpm.sh: add magic mime-type for geometry db files v4 on rpm packages |
| 18:43.41 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 18:50.40 | CIA-6 | BRL-CAD: 03starseeker * r43299 10/brlcad/branches/cmake/src/conv/CMakeLists.txt: Add shp-g to cmake logic |
| 18:51.40 | willdye | Thanks for mentioning http://neugierig.org/software/chromium/notes/2011/02/ninja.html in this channel. I didn't know about it, and now I'm very glad that I do. |
| 18:54.26 | starseeker | willdye: how does it work? |
| 18:54.27 | CIA-6 | BRL-CAD: 03starseeker * r43300 10/brlcad/branches/cmake/src/other/step/ (CMakeLists.txt include/scl_cf_cmake.h.in): Whoops - alter the file in the build dir, not the src dir |
| 18:54.31 | starseeker | has yet to try it |
| 18:57.27 | willdye | starseeker: Too soon to say if we'll use it here, but it looks very promising. I don't handle the build system here at work, so the final decision won't be up to me, but anything that speeds up builds will be very welcome here. |
| 18:58.02 | willdye | I forwarded it to the powers that be. Time will tell if they decide to give it a try. |
| 19:26.00 | starseeker | willdye: there's interest from a couple folks at getting CMake go generate ninja output, which is my main interest - in principle that would mean faster building with no extra work |
| 20:11.20 | CIA-6 | BRL-CAD: 03starseeker * r43301 10/brlcad/trunk/src/other/step/ (CMakeLists.txt include/conf/ include/scl_cf_cmake.h.in): Fix step files in trunk |
| 20:35.18 | CIA-6 | BRL-CAD: 03jordisayol * r43302 10/brlcad/trunk/sh/make_rpm.sh: corrects wrong mged icon file name |
| 20:36.06 | CIA-6 | BRL-CAD: 03davidloman * r43303 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSStatics.java: Put in a user overrideable PrintStream set to log to. Devauls to StdOut and StdErr |
| 20:38.34 | CIA-6 | BRL-CAD: 03davidloman * r43304 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/MinimalGSClient.java: Start wiring in the GSClient's ability to establish comms with a GS |
| 20:45.30 | CIA-6 | BRL-CAD: 03davidloman * r43305 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/ (3 files in 2 dirs): Make all System.out and System.err calls go thru the assigned PrintStreams in GSStatics. Added in trapped Exception reason printing to aid in debugging. |
| 20:59.54 | CIA-6 | BRL-CAD: 03Sean 07http://brlcad.org * r2473 10/wiki/NURBS_TODO: add a few references, space them out |
| 20:59.57 | CIA-6 | BRL-CAD: 03davidloman * r43306 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/ (4 files in 2 dirs): Make command console style strings into statics and make all calls to printToConsole and printLnToConsole use these statics. This should minimize bugs later. |
| 21:06.49 | CIA-6 | BRL-CAD: 03Sean 07http://brlcad.org * r2474 10/wiki/NURBS_TODO: turn them into sections so we have a table of contents |
| 21:08.39 | CIA-6 | BRL-CAD: 03Sean 07http://brlcad.org * r2475 10/wiki/NURBS_TODO: remove superfluous bullets |
| 21:08.58 | CIA-6 | BRL-CAD: 03Sean 07http://brlcad.org * r2476 10/wiki/NURBS_TODO: |
| 22:23.39 | CIA-6 | BRL-CAD: 03starseeker * r43307 10/brlcad/branches/cmake/src/other/tcl/CMakeLists.txt: Don't override LIB_DIR if already set - need windows specific logic for this eventually. |
| 23:01.13 | CIA-6 | BRL-CAD: 03128.63.32.5 07http://brlcad.org * r2477 10/wiki/NURBS_TODO: add link to Martin paper |
| 01:26.52 | louipc | hmm step files are text eh |
| 01:31.54 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 01:43.24 | *** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no) | |
| 02:58.15 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 03:05.09 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) | |
| 05:07.39 | CIA-6 | BRL-CAD: 03Sean 07http://brlcad.org * r2478 10/wiki/NURBS_TODO: stub in the rest |
| 05:35.22 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:50.38 | CIA-6 | BRL-CAD: 03Sean 07http://brlcad.org * r2479 10/wiki/NURBS_TODO: expand time estimates, references, and benefits on most tasks |
| 07:18.40 | CIA-6 | BRL-CAD: 03brlcad * r43308 10/brlcad/trunk/src/irprep/firpass.c: |
| 07:18.40 | CIA-6 | BRL-CAD: replace all of the NEAR_*() calls with an arbitrary FLT_MIN (which is basically |
| 07:18.40 | CIA-6 | BRL-CAD: one ulp step up from 0) to their corresponding ZERO() and EQUAL() calls. |
| 07:18.40 | CIA-6 | BRL-CAD: FLT_MIN shouldn't be used anyways unless 1ulp is the goal (in which case there's |
| 07:18.40 | CIA-6 | BRL-CAD: a libbn function for it), SMALL_FASTF is our base computation tolerance. |
| 07:19.44 | CIA-6 | BRL-CAD: 03brlcad * r43309 10/brlcad/trunk/src/sig/dmod.c: prefer ZERO() over NEAR_ZERO() when the tol is merely FLT_MIN or (better) SMALL_FASTF. |
| 07:23.03 | CIA-6 | BRL-CAD: 03brlcad * r43310 10/brlcad/trunk/src/rt/heatgraph.c: <= and >= are still comparing floating point values for equality, which is not reliable. call EQUAL() and ZERO() accordingly. |
| 07:25.52 | CIA-6 | BRL-CAD: 03brlcad * r43311 10/brlcad/trunk/src/rt/heatgraph.c: technically more simple to just test for less than zero .. though unsafe. (some comparisons need to compare against +-SMALL_FASTF instead of 0) |
| 11:48.40 | dloman | Mernin! |
| 11:52.37 | dloman | Question to anyone in the know: Has anyone taken a deep look into how/if current GPU processing techniques could benefit our raytracer? |
| 12:26.34 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:31.56 | *** join/#brlcad WhiteCalf (MK@2607:f0d0:3001:68::2) | |
| 12:33.06 | *** join/#brlcad kanzure_ (~kanzure@bioinformatics.org) | |
| 12:38.30 | CIA-6 | BRL-CAD: 03davidloman * r43312 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/MinimalGSClient.java: Add null check for the GSClient's GSConnection to ensure a 1:1 GSConnection per GSClient ratio. |
| 12:46.08 | CIA-6 | BRL-CAD: 03davidloman * r43313 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/MinimalGSClientGUI.java: Breakout GUI elements into their own class. Keeps things clean and easier to manage. |
| 12:47.56 | CIA-6 | BRL-CAD: 03davidloman * r43314 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/ (Main.java MinimalGSClient.java): Implement new MinimalGSClient class (without gui components) and roll down the changes to the main() method. |
| 12:56.59 | CIA-6 | BRL-CAD: 03d_rossberg * r43315 10/brlcad/trunk/src/libged/CMakeLists.txt: |
| 12:56.59 | CIA-6 | BRL-CAD: there are references to libregex here |
| 12:56.59 | CIA-6 | BRL-CAD: added libregex headers search path |
| 12:59.50 | CIA-6 | BRL-CAD: 03d_rossberg * r43316 10/brlcad/trunk/src/librt/CMakeLists.txt: synced with Makefile.am: "bottie modifications moved to trunk" |
| 13:24.13 | CIA-6 | BRL-CAD: 03davidloman * r43317 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/Main.java: Removed stray debugging statement. |
| 13:26.08 | CIA-6 | BRL-CAD: 03davidloman * r43318 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/cmd/AbstractCmd.java: Put in usage and help printing methods. Keeps formatting consistent and removes potential future formatting bug points. |
| 13:26.46 | CIA-6 | BRL-CAD: 03davidloman * r43319 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/MinimalGSClient.java: Quick Comment... |
| 13:27.14 | CIA-6 | BRL-CAD: 03davidloman * r43320 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSStatics.java: Add tabs and newlines for this lib. More efforts to promote consistency. |
| 13:27.45 | CIA-6 | BRL-CAD: 03davidloman * r43321 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/cmd/ (CmdManager.java HelpCmd.java LoginCmd.java): Clean up console printing formats. Use helper methods and statics. |
| 13:32.30 | CIA-6 | BRL-CAD: 03davidloman * r43322 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/cmd/LoginCmd.java: Import cleanup. |
| 14:17.36 | CIA-6 | BRL-CAD: 03davidloman * r43323 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSJavaInterface.java: Create GSJavaInterface, the class that implements the interface 'GeometryService' as defined in jBRLCAD. This will be the public API for this GS interface |
| 14:31.49 | CIA-6 | BRL-CAD: 03davidloman * r43324 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/ (7 files in 2 dirs): Propagate use of GSJavaInterface throughout. Allow for AbstractCmd subclasses to gain access to the associated GSJavaInterface, so as to be able to act upon it. |
| 15:09.12 | CIA-6 | BRL-CAD: 03erikgreenwald * r43325 10/geomcore/trunk/ (include/Logger.h src/utility/Logger.cxx): simplify, atomicize, remove mutex stuff |
| 15:10.28 | CIA-6 | BRL-CAD: 03erikgreenwald * r43326 10/geomcore/trunk/ (25 files in 13 dirs): remove some mutex stuff. remove redundant sleep wrapping. adjust to cope with new include paths sent from FindBRLCAD.cmake |
| 15:54.59 | CIA-6 | BRL-CAD: 03davidloman * r43327 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/cmd/LoginCmd.java: Implement minimal client's ability to login to a gs |
| 16:09.24 | dloman | starseeker: you around? |
| 16:10.04 | dloman | in geomcore/src/other/uuid, there are two headers being generated: uuid_config and uuid.h |
| 16:10.19 | dloman | should those be svn:ignored? |
| 16:12.17 | CIA-6 | BRL-CAD: 03davidloman * r43328 10/geomcore/trunk/src/interfaces/ (. c/ java/): Modified SVN:IGNORE to exclude configure and build byproducts. |
| 16:13.44 | CIA-6 | BRL-CAD: 03davidloman * r43329 10/geomcore/trunk/src/other/uuid/: Modified SVN:IGNORE to exclude configure and build byproducts. |
| 16:47.38 | dloman | starseeker: Since you are endeavoring for an out of build setup, would it be desireable for me to go and remove all the cmake related entries in svn:ignore |
| 16:49.09 | starseeker | dloman: yeah, that'd be good |
| 16:49.15 | starseeker | I can do it if you like |
| 16:50.45 | dloman | nah, I need a few mins break from what I am doin anyways :) |
| 16:51.56 | dloman | looking at the svn:ignore list, is there anything besides cmake_install.cmake, CMakeCache.txt and CMakeFiles that you think sould be removed? |
| 16:52.17 | starseeker | dloman: I' |
| 16:52.26 | starseeker | I've been clearing it entirely |
| 17:00.35 | dloman | prepares nuklar bomb for svn:ignore.... |
| 17:01.50 | CIA-6 | BRL-CAD: 03davidloman * r43330 10/geomcore/trunk/ (36 files in 36 dirs): Drop a nuklar bomb on svn:ignore. Pushing for out of source builds. |
| 17:02.02 | dloman | boom |
| 17:02.08 | starseeker | heh |
| 17:03.20 | dloman | starseeker: cmake's INSTALL cmd should be used for copying a file to the install bin dir? |
| 17:03.32 | dloman | aka, I have two .configure files i need copied over with the build |
| 17:03.58 | starseeker | no, INSTALL is for the final make install |
| 17:04.22 | starseeker | if you want something copied over with the build, used either configure_file, FILE(COPY or |
| 17:04.40 | starseeker | (if you want it to be copied by make and not the cmake configure) make a custom command and custom target |
| 17:05.01 | starseeker | the latter is a bit more complex because you're essentially telling CMake how to tell Make/Visual Studio/etc. to do it |
| 17:05.38 | dloman | okay, so making cmake tell make == hard, using cmake to do it == easymode ? |
| 17:06.57 | starseeker | it's worth it if the file is one you want to edit and copy over to the build tree a lot |
| 17:07.19 | starseeker | it's not that hard, just a few more lines |
| 17:07.29 | dloman | its a default .configure file, thats all. |
| 17:13.01 | dloman | using FILE(COPY src dest) |
| 17:13.04 | dloman | awesome thanks :) |
| 17:16.36 | starseeker | np :-) |
| 17:19.07 | dloman | crud, i ran into a brlcad install problem, but i cant remember how to fix it. |
| 17:21.21 | dloman | nm, stale build |
| 17:39.29 | dloman | installs! |
| 18:10.28 | *** join/#brlcad indianla1ry (~indianlar@63.246.136.16) | |
| 18:10.28 | *** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no) | |
| 18:10.28 | *** join/#brlcad kanzure_ (~kanzure@bioinformatics.org) | |
| 18:10.28 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 18:10.28 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 18:10.28 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 18:10.28 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 18:10.28 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 18:10.28 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 18:10.28 | *** join/#brlcad poolio_ (~poolio@BZ.BZFLAG.BZ) | |
| 18:10.28 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 18:10.28 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 18:10.28 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 18:10.28 | *** join/#brlcad WhiteCalf (MK@2607:f0d0:3001:68::2) | |
| 18:10.28 | *** join/#brlcad juan_man (~quassel@186.136.168.73) | |
| 18:10.28 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 18:10.28 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 18:10.28 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 18:10.28 | *** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ) | |
| 18:10.31 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 18:10.31 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 18:10.31 | *** join/#brlcad 45PABR1J4 (~CIA@208.69.182.149) | |
| 18:10.31 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 18:10.31 | *** mode/#brlcad [+o ChanServ] by anthony.freenode.net | |
| 18:24.06 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 18:24.07 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 18:24.07 | *** mode/#brlcad [+o ChanServ] by anthony.freenode.net | |
| 18:34.53 | CIA-77 | BRL-CAD: 03davidloman * r43331 10/geomcore/trunk/src/GS/CMakeLists.txt: CMake needs to copy over the template config files during its run. |
| 18:37.56 | CIA-77 | BRL-CAD: 03starseeker * r43332 10/geomcore/trunk/ (11 files in 10 dirs): More changes to geomcore CMake logic. Need to handle BRLCAD_FOUND properly, conditionally look for things like terminal library based on WIN32 and check for libbrlcad again but getting closer. |
| 18:54.05 | brlcad | dloman: System.getProperty("line.separator"); unless it's a JTextArea... then it's just \n .. or %n if it's in a String.format() |
| 18:55.03 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 18:57.03 | CIA-77 | BRL-CAD: 03davidloman * r43333 10/geomcore/trunk/include/GeometryService.h: Default listening addy should be 127.0.0.1 not 0.0.0.0 |
| 19:01.21 | CIA-77 | BRL-CAD: 03erikgreenwald * r43334 10/geomcore/trunk/ (src/GS/CMakeLists.txt tests/utility/CMakeLists.txt): add TCL_INCLUDE_PATHS |
| 19:02.23 | CIA-77 | BRL-CAD: 03davidloman * r43335 10/geomcore/trunk/include/PortalManager.h: Default listening addy should be 127.0.0.1 not 0.0.0.0 (again) |
| 19:02.32 | CIA-77 | BRL-CAD: 03erikgreenwald * r43336 10/geomcore/trunk/ (3 files in 2 dirs): add GSUuid wrapper |
| 19:11.03 | CIA-77 | BRL-CAD: 03davidloman * r43337 10/geomcore/trunk/ (include/GeometryService.h src/GS/GeometryService.cxx): Remove GeometryService class fields for listenPort and listenAddy. Pass both to GeometryService's PortalManager. |
| 19:13.42 | CIA-77 | BRL-CAD: 03erikgreenwald * r43338 10/geomcore/trunk/ (26 files in 7 dirs): eliminate QUuid in favor of local GSUuid wrapper |
| 19:16.52 | CIA-77 | BRL-CAD: 03erikgreenwald * r43339 10/geomcore/trunk/tests/GS/GeometryServiceTest.cxx: last QUuid is gone |
| 19:19.23 | dloman | ``Erik: /GSUuid.h:32:19: error: uuid.h: No such file or directory |
| 19:22.05 | CIA-77 | BRL-CAD: 03brlcad * r43340 10/geomcore/trunk/src/utility/Logger.cxx: if it's a stack trace you want, a stack trace ye shall have. uhm, why? |
| 19:23.45 | ``Erik | on which OS? |
| 19:24.10 | dloman | Linux |
| 19:24.28 | ``Erik | hm, the one OS I can't test on due to horribly out of date QT stuff, heh |
| 19:24.52 | dloman | it was compling fine over here till that last ci of yours. |
| 19:24.57 | dloman | ...if that helps :) |
| 19:25.50 | CIA-77 | BRL-CAD: 03erikgreenwald * r43341 10/geomcore/trunk/include/GSUuid.h: disable the #include for now |
| 19:27.31 | dloman | Im doing an out of source build. that .h was a file I noticed earlier today that was being generated by CMake |
| 19:28.18 | ``Erik | there is one made from src/other/uuid/, but I'm trying to use the system ones |
| 19:28.31 | dloman | okie! |
| 19:37.12 | CIA-77 | BRL-CAD: 03starseeker * r43342 10/geomcore/trunk/ (3 files in 3 dirs): Include uuid directory for all the source paths, now that it's being (potentially) used. |
| 19:37.21 | starseeker | dloman: does that work? |
| 19:41.19 | dloman | netMsgSerialText.cxx->NetMsg.h->GSUuid.h->uuid.h still fails. |
| 19:45.00 | ``Erik | O.o um, does 0 != 0 on linux? |
| 19:45.12 | ``Erik | ah, starseeker is mucking things up |
| 19:47.26 | CIA-77 | BRL-CAD: 03starseeker * r43343 10/geomcore/trunk/tests/CMakeLists.txt: Give tests the include dirs too. |
| 19:48.09 | dloman | werkin! |
| 19:59.25 | CIA-77 | BRL-CAD: 03erikgreenwald * r43344 10/geomcore/trunk/src/GS/geoserv.cxx: remove the random failure... |
| 20:00.19 | dloman | ack, you suck ``Erik |
| 20:00.26 | dloman | i was just about to commit those fixes |
| 20:04.09 | ``Erik | hrm? |
| 20:04.33 | starseeker | hehe |
| 20:04.34 | ``Erik | ponders grinding indent on thos |
| 20:05.02 | starseeker | dloman: he beat you to the draw huh? |
| 20:05.06 | dloman | yeah :( |
| 20:09.51 | CIA-77 | BRL-CAD: 03davidloman * r43345 10/geomcore/trunk/src/GS/geoserv.cxx: Make port value pulled from config file validate correctly. |
| 20:11.27 | ``Erik | sok, I put ! instead of ~, so he'll dump my changes and put his own in *shrug* then I'll "simplify" his later |
| 20:12.05 | dloman | That was a neat trick though :) |
| 20:12.18 | dloman | proves that I don't think bitwise :) |
| 20:14.52 | CIA-77 | BRL-CAD: 03davidloman * r43346 10/geomcore/trunk/src/utility/Config.cxx: Fix config parser bug so that parser detects EOF correctly and exits. |
| 20:22.59 | *** join/#brlcad roberthl_ (~robert@v001.rhl.me.uk) | |
| 20:34.55 | CIA-77 | BRL-CAD: 03bob1961 * r43347 10/brlcad/trunk/src/ (3 files in 3 dirs): Tweaks to get the windows batch files working better. That is, they can handle filenames with spaces and the windows prompt gets removed from the screen. |
| 21:17.27 | *** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ) | |
| 21:20.34 | *** join/#brlcad kanzure__ (~kanzure@bioinformatics.org) | |
| 21:57.51 | CIA-77 | BRL-CAD: 03starseeker * r43348 10/geomcore/trunk/ (9 files in 7 dirs): Optionally enable the subversion build and subversion test, move svntest into the geomcore tests dir. |
| 22:03.52 | *** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net) | |
| 22:04.01 | _psilva | hey brlcad |
| 22:04.22 | _psilva | u there? |
| 22:31.37 | CIA-77 | BRL-CAD: 03erikgreenwald * r43349 10/geomcore/trunk/tests/utility/ (CMakeLists.txt threadTest.cxx): add simple threading test for GSThread |
| 22:33.20 | CIA-77 | BRL-CAD: 03erikgreenwald * r43350 10/geomcore/trunk/ (include/GSThread.h src/utility/GSThread.cxx): basic threading class implementation |
| 22:34.05 | CIA-77 | BRL-CAD: 03erikgreenwald * r43351 10/geomcore/trunk/ (11 files in 4 dirs): QThread -> GSThread |
| 22:53.22 | *** join/#brlcad IriX64 (~IriX64@bas2-sudbury98-1177593317.dsl.bell.ca) | |
| 22:55.18 | CIA-77 | BRL-CAD: 03erikgreenwald * r43352 10/geomcore/trunk/ (23 files in 7 dirs): stub in GSMutex and GSMutexLocker, still need impl |
| 22:59.40 | CIA-77 | BRL-CAD: 03erikgreenwald * r43353 10/geomcore/trunk/ (12 files in 10 dirs): remove references to QT libs |
| 23:03.40 | CIA-77 | BRL-CAD: 03erikgreenwald * r43354 10/geomcore/trunk/TODO: notes |
| 23:14.42 | CIA-77 | BRL-CAD: 03erikgreenwald * r43355 10/geomcore/trunk/ (include/GSThread.h src/utility/GSThread.cxx): implement GSMutex and GSMutexLocker on pthreads |
| 00:06.18 | CIA-77 | BRL-CAD: 03starseeker * r43356 10/geomcore/trunk/ (3 files in 2 dirs): Proof of concept code to chop the toplevel objects out of a .g file, write them to individual .g files in the svn repository, and commit them. |
| 01:08.04 | brlcad | _psilva: nope |
| 01:22.17 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) | |
| 01:36.04 | CIA-77 | BRL-CAD: 03brlcad * r43357 10/brlcad/trunk/TODO: list the slew of requested and useful converters including step export, dae, x3d, g-code, u3d, 3D pdf, sat, ply, json, and xml formats |
| 02:23.25 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 02:34.22 | brlcad | starseeker: nice proof of concept chop-blocking |
| 02:34.58 | brlcad | would be good exercise to convert to db_walk_tree or one of the other walkers since the next step is probably to stop at the region level |
| 03:05.56 | starseeker | brlcad: ah, from what dloman was saying it sounded like we would break out every object in the first round |
| 03:07.09 | starseeker | also, if we stop at the region level, does that mean we do a full keep of each tree below the region level, even if it means duplicating geometry? |
| 03:09.27 | ``Erik | json? really? |
| 03:09.46 | brlcad | about as useful as xml ;) |
| 03:11.02 | brlcad | starseeker: either way but I think it's pretty much inevitable, also makes us parallel other cad packages (a region is a part) |
| 03:12.10 | brlcad | intermediate dev would be fine, but we probably shouldn't deploy down to the prim level since we haven't yet sorted out database upgrades |
| 03:12.24 | brlcad | and our next step given the new timeline is pretty much deployment ;) |
| 03:16.04 | brlcad | as for the duplication issue, i've had a plan in place to address that for about 7 years now -- effectively instantiating a more robust concept of a part (one with and without the region bit set) |
| 03:18.55 | starseeker | brlcad: so... first step is full keep and eat the duplication, then follow on later with the proper solution? |
| 03:19.10 | brlcad | and even without that concept, the duplication issue can become a non-issue by inverting the region-parent relationships (instead of C1->R1,R2,R3->subC1, you have C1->subC1,subC2,subC3->R1) |
| 03:19.55 | brlcad | basically, but it fortunately doesn't really require changes under the hood, just changes how geometry is managed on import |
| 03:20.35 | starseeker | kinda - but we'll have to migrate broken-out-at-region setups to the final solution |
| 03:20.51 | starseeker | is fine with it, just wants to be sure he's hacking the right thing |
| 03:21.00 | brlcad | not necessarily, it'll just be duplicate data |
| 03:21.16 | brlcad | we could automate remerging duplication later as a backend job |
| 03:21.22 | starseeker | nods |
| 03:21.46 | starseeker | all rightie, tree walking it is |
| 03:22.43 | brlcad | there would be one benefit of going all the way down to the primitive level, if you actually calculate the call overhead on a full vehicle with a checkin->breakout->commit->checkout->recombine scenario, see what the numbers look like, then redo stopping at region level |
| 03:23.19 | brlcad | see if it's actually a significant issue in practice on given arch, like macosx, that has bad i/o performance |
| 03:23.54 | brlcad | if it's not, then we could reasonably punt with confidence that it doesn't matter and let all objects get tracked uniformly |
| 03:24.04 | starseeker | nods |
| 03:24.20 | starseeker | it would simplify re-constructing a .g file - just dbconcat all the pieces |
| 03:24.39 | starseeker | building a bunch of regions with full trees back into the original .g is a bit of a chore |
| 03:24.52 | brlcad | without the metrics, though, I would definitely just stop at regions since there is pretty significant data overhead at the primitive level: 104 bytes per object |
| 03:25.20 | starseeker | nods - at least until we can get our own custom svn backend, anyway |
| 03:25.34 | brlcad | most objects in implicit form aren't even 104 bytes ;) |
| 03:26.18 | brlcad | the metrics are critical, though .. because the performance could be an outright show-stopper for a full vehicle |
| 03:26.22 | starseeker | overheads probably higher than that in the proof of concept code - I'm making everything its own .g file |
| 03:26.32 | brlcad | .g overhead is 104 bytes |
| 03:26.36 | starseeker | oh, gotcha |
| 03:26.47 | brlcad | and most of that is _GLOBAL, so there are other ways to optimize too |
| 03:27.12 | starseeker | the other approach is to do a more custom write - I took the quick and simple way to write out object data, but I could customize a routine to write JUST the object info |
| 03:27.29 | brlcad | though file ops likely dominate on files that small |
| 03:28.23 | starseeker | ('course if I do custom IO I might as well start looking at an FS-G backend now, and that's not the priority) |
| 03:28.38 | starseeker | will see if he can get the tree walker going and do the metrics |
| 03:28.59 | brlcad | the other benefit of constructing this region/non-region organization is that we can enforce proper DAG structures more easily -- CSG recipes would only be valid at/below region level, for example |
| 03:29.09 | brlcad | above, they're just assemblies, groups |
| 03:29.25 | brlcad | unions |
| 03:30.16 | brlcad | would effectively make it not possible to subtract assemblies from assemblies without pushing the operations down to the region level |
| 03:31.16 | starseeker | how would we combine region files of that type back into one .g file? scan for duplicate primitives and selectively import the ones not already present? |
| 03:31.35 | starseeker | what about changes to a multiply referenced primitive? how do we make sure we hit all the copies? |
| 03:35.35 | brlcad | the region file stored would already be the pushed result |
| 03:35.50 | brlcad | so the file being combined back on read is just cat-able |
| 03:36.03 | starseeker | you mean we wouldn't support unpushed geometry? |
| 03:36.12 | starseeker | ouch |
| 03:36.16 | brlcad | not following |
| 03:36.22 | brlcad | no no |
| 03:37.02 | brlcad | the ONE high-level operation (subtract assemb1 (with r1, r2) from assemb2 (with r3, r4)) |
| 03:37.16 | brlcad | would result in r3 and r4 getting modified |
| 03:38.02 | starseeker | right... I'm thinking a little lower level. let's say r3 and r4 both include sph1, and I change sph1 |
| 03:38.05 | brlcad | a "dumb" implementation would simply import r1/r2 into r3 and r4 and subtract them |
| 03:38.31 | starseeker | if r3 and r4 are both full tree copies in the repository, there are two independent copies of sph1 |
| 03:38.37 | starseeker | both of which need to be updated |
| 03:40.11 | brlcad | for example, you mean two 'sph1' instances in r3 ? |
| 03:40.52 | starseeker | no - I'm thinking I "break" model.g with two regions r1 and r2 into the repository: |
| 03:41.07 | starseeker | model.g (toplevel object) and two region files r1.g and r2.g |
| 03:41.28 | starseeker | both r1 and r2 union in the same primitive, sph1 |
| 03:41.45 | starseeker | if I'm doing a deep keep to create r1.g and r2.g, BOTH files have identical copies of sph1 |
| 03:42.06 | starseeker | if I then edit sph1 in my modeler, the implication is I'm changing both r1.g and r2.g |
| 03:42.13 | brlcad | that's not possible in the stop-at-region-level setup, the sph1 would be duplicated across the two regions |
| 03:42.30 | brlcad | if it needs to be reusable, then the definition of the region changes |
| 03:43.08 | starseeker | so you're saying that by definition a region does not contain any geometry objects that are used in any other regions? |
| 03:43.11 | brlcad | and you have model.g (toplevel), c1.g (was r1.g), c2.g (was r2.g) and a new r.g (containing the one sph1 instance) |
| 03:43.42 | brlcad | yes, all regions become fully self-contained namespaces |
| 03:44.06 | starseeker | shakes his head - I highly doubt that's how things work out in practice |
| 03:44.11 | brlcad | you can convert any existing model to that structure with the flip inversion I mentioned without loss of generality |
| 03:44.27 | starseeker | I'm not quite parsing the flip inversion |
| 03:45.03 | brlcad | I'll draw |
| 03:47.29 | starseeker | oh, wait - you're turning regions that are not self contained into assemblies, and creating regions below them of the shared subset? |
| 03:47.44 | brlcad | yes |
| 03:47.57 | starseeker | won't that really mess with region_id information>? |
| 03:48.23 | starseeker | if a geometry was set up with r1 and r2 having different region ids and shared geometry... |
| 03:48.47 | brlcad | not necessarily |
| 03:50.30 | brlcad | important note, though, that the progression is towards the minimization of region ids -- S2 will need updating to accommodate, but M3 uses different tracking mechanisms |
| 03:51.23 | starseeker | that definition of a region strikes me as a bit limiting - let's say I have a model of a screw, and I want to make 10 different regions using the same geometry but different material properties (aluminum screw, steel screw, etc...) - intentionally the same size and geometry but different regions, and the desire to have any change to screw dimensions propogate to all regions |
| 03:51.37 | brlcad | region id's in this new system become mostly irrelevant -- it's just attribute data |
| 03:51.47 | starseeker | brlcad: OK, we're assuming S2 changes as well - that's different |
| 03:52.23 | brlcad | the concept of a "part" is more that there's a point where they're no longer assemblies and become self-contained part data |
| 03:52.59 | brlcad | I really probably just need to write all this up in a document since it's a discussion that's come up before |
| 03:53.23 | starseeker | what happens to the different-materials same-geometry sceario? |
| 03:55.30 | brlcad | that's either multiple parts (which is what most cad packages do and matches our current "region" concept), or we have to implement support for multiple-segment regions |
| 03:55.57 | brlcad | the latter would be great for things like the vol primitive |
| 03:57.50 | brlcad | at this point, most of the issues on regions/materials/ids/etc can be punted so long as the routine that breaks up a .g has a means to stop at some level in the hierarchy -- whether at prim, region, one below region, one above, etc |
| 03:58.36 | brlcad | one solution to the multiply reference region was to invert downwards instead of upwards |
| 04:00.20 | brlcad | so every region becomes a region comb containing just one member, the former region hierarchy -- basically injects a comb node and pushes the region bit up and the "part" becomes a non-region |
| 04:00.41 | starseeker | nods |
| 04:01.20 | brlcad | so then S2 keeps doing what they're doing -- regions are unaffected |
| 04:01.27 | brlcad | region count is unchanged |
| 04:02.18 | brlcad | lil harder to ensure database integrity, so every region has one and only one member, a part |
| 04:03.27 | starseeker | hmm. Well, regardless it sounds like the first stage is to get a tree walker going and be able to control the break points |
| 04:05.26 | starseeker | likes the sound of multiple-segment regions, even if he doesn't know exactly what that would entail |
| 04:06.20 | starseeker | must sleep - early morning gym appointment (ugh) |
| 04:07.58 | brlcad | yeah, definitely |
| 04:39.55 | CIA-77 | BRL-CAD: 03brlcad * r43358 10/brlcad/trunk/TODO: consolidate the other conversion tasks |
| 06:33.18 | *** join/#brlcad Stattrav (~Stattrav@117.192.132.151) | |
| 06:33.18 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:07.49 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 09:31.11 | *** join/#brlcad Stattrav (~Stattrav@117.192.132.151) | |
| 09:31.11 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:44.05 | dloman | starseeker: brlcad: I'm not quite grasping at what problem we are solving by stopping the disassembly of the .g file at the region level.... |
| 09:44.26 | dloman | it seems to me it would cause much more problems than is worth the gain in simplicity... |
| 09:45.10 | dloman | Modelers frequently use a single prim from a region (r1) to subtract from another region (r2) for overlaps. |
| 09:46.27 | dloman | so, but keeping all the prims in the region level file, the GS would have to load two region .g's (entirely with all their geometry) just to get at the solid in r1 for r2... seems a bit clunky and complex |
| 09:46.57 | dloman | what was the 'gain' for keeping the geometry in the region level .g file? |
| 11:50.37 | ``Erik | hm, there's been argument that subtracting a region itself is incorrect, the proper way for that hack would be to make a subregion group, have the region contain the group, and subtract the group from other geometry O.o |
| 11:52.47 | ``Erik | dlo: I'm not making it in today, I'll be at upper chesapeake most of the day, I think the last fugly wart I left is the UUID shtuff if it's a show stopper and you want to regain functionality... my intent is to try to use the system uuid (e2fs or ossp, depending on os) with some cmake checks and #if e2fs #if ossp fu, if you need something rolling today |
| 11:53.43 | dloman | not likely, I'll probably be leaving early today... |
| 11:54.12 | dloman | the senario I am talking about is: r1 = s1 u s2 u s3 u s4 |
| 11:54.26 | dloman | r2 = s5 u s6 - s1 |
| 11:55.13 | dloman | I don't see why we would want to keep all the prims in the r1.g and r2.g file, such that we have a duplicate of s1 |
| 11:55.51 | ``Erik | hasn't read backlog and is getting ready to head to the hospital, will catch it all later O.o |
| 11:56.00 | dloman | ack, everything okay? |
| 11:56.20 | ``Erik | it's not for me |
| 13:19.56 | starseeker | dloman: if I understand correctly, the notion is that each region would be a fully independent piece of geometry |
| 13:20.31 | starseeker | by definition, there would be no shared geometry between regions, so subtractions to avoid overlaps would become a somewhat problematic way to handle things |
| 13:22.02 | starseeker | The main practical concern with breaking up the entire .g file into all its objects is IO performance (lots and lots of small files) |
| 13:23.03 | starseeker | brlcad also seems to have some ideas about enforcing region policy and .g structure |
| 13:23.31 | starseeker | isn't sure if that logic should live at the svn level or above it |
| 13:24.40 | starseeker | as far as the policy stuff, what I understand of it sounds OK but I'm not sure current modeling practices like you describe are really compatible with it |
| 13:27.02 | starseeker | e.g. subtracting parts of one interfering region from another region will result in a copy of the subcomponents needed for the subtraction appearing in the region being subtracted from, and those components will lose their relationship to the region being subtracted |
| 13:28.02 | starseeker | so if you have r1 and r2, and need to subtract c2 that is part of r2 from r1 to avoid an overlap, r1 would get a copy of c2 |
| 13:29.01 | starseeker | and changes to the original c2 in r2 would not be automatically propogated back to r1, unless we implement something to do that (which kinda violates the notion of each region being its own independent entity) |
| 13:42.21 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 13:44.04 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 14:15.23 | _psilva | hiyo |
| 14:31.07 | CIA-77 | BRL-CAD: 03brlcad * r43359 10/brlcad/trunk/src/irprep/ir-sgi.c: HAS_SGIGL .. isn't going to be around much longer. but test for it being set instead of being true until it's gone. |
| 14:32.23 | CIA-77 | BRL-CAD: 03brlcad * r43360 10/brlcad/trunk/src/irprep/ (firpass.c ir-X.c secpass.c shapefact.c): quell verbose warnings. mark unused params, size_t signage promotions, index shadows, and exact floating point comparisons. |
| 14:36.56 | CIA-77 | BRL-CAD: 03brlcad * r43361 10/brlcad/trunk/src/lgt/ (do_options.c execshell.c): need to include unistd.h |
| 14:47.22 | dloman | Hrm, well, putting a combination between a region and its prims doesn't solve the problem. |
| 14:48.14 | dloman | I can 99.99% gurantee that dupicating geometry (in the example, s1) will be *adding* a substantial maintenance burden on the modelers |
| 14:48.24 | dloman | especially if s1 is a somewhat sizable bot. |
| 14:50.19 | dloman | additionally, although diskspace is 'cheap' and we should only solve problems when they become a problem |
| 14:51.07 | dloman | wouldn't duplicating s1 in two spots actually end up as a net negative performance on IO, since we would technically have to read that prim twice? |
| 14:51.32 | dloman | We can't ignore overlaps, as the are GOING to happen. Of this, I am 110% certain. |
| 14:52.15 | starseeker | dloman: I may be missing some of the implications of what brlcad is describing, so he should weigh in |
| 14:52.27 | dloman | add in the increasing data sizes due to bots and the impending complex nurbs, and I don't see 'each region as its own, idependent, entity' as being a good idea. |
| 14:52.35 | dloman | sure thing. |
| 14:53.12 | dloman | I am just trying to understand how brlcad and i got our wires crossed.... cause this is not the impression i got, walking away from our last discussion on the subject :/ |
| 14:53.27 | dloman | or more specificly, what brlcad's notion is. |
| 14:53.59 | dloman | is remote today, so Im not in office. |
| 14:54.07 | starseeker | dloman: did you read the scrollback from last night? |
| 14:54.33 | dloman | yuppers. |
| 14:54.37 | starseeker | you might be able to follow it better than me |
| 14:54.58 | CIA-77 | BRL-CAD: 03brlcad * r43362 10/brlcad/trunk/src/nirt/ (command.c interact.c nirt.c nirt.h parse_fmt.c read_mat.c): eliminate the rtip global. propagate api changes throughout. |
| 14:55.09 | dloman | and keeping the prims in the region .g's is, in my opinion, going to cause a ****-ton of issues. |
| 14:56.12 | dloman | keeping all the solids in their own file, just like the c's and r's, but in a directory named after the associated r, is what i understood our approach was. |
| 14:57.05 | dloman | yes, it creates many more files, but i honestly think its more flexible and will be lower IO in the long run. |
| 14:58.35 | CIA-77 | BRL-CAD: 03brlcad * r43363 10/brlcad/trunk/src/nirt/showshot.c: convert %F to %lf. not optimal, but gefn |
| 14:58.38 | *** join/#brlcad Stattrav (~Stattrav@117.192.132.151) | |
| 14:58.38 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:20.43 | dloman | starseeker: do you know if its bad to change an #include <string> to #include <string.h> ? |
| 15:21.08 | starseeker | uh. isn't the first one C++ and the second one C? |
| 15:21.29 | dloman | thats what i thought too. just checking. |
| 15:21.55 | dloman | hard to google things with a 13 month old in one arm :) |
| 15:23.14 | starseeker | heh |
| 15:23.21 | starseeker | winces |
| 15:23.54 | starseeker | havoc checkout takes 35 megs doing the write-out-every-object scheme |
| 15:24.31 | CIA-77 | BRL-CAD: 03brlcad * r43364 10/brlcad/trunk/src/proc-db/ (brickwall.c masonry.c): quell warnings, exact floating point comparisons |
| 15:24.37 | starseeker | guess the every-object-is-a-g-database thing isn't so hot |
| 15:24.53 | starseeker | commits anyway... |
| 15:25.10 | starseeker | oh, took several minutes to commit and checkout, too |
| 15:25.18 | dloman | why is that bad? whats the original filesize? |
| 15:25.37 | CIA-77 | BRL-CAD: 03brlcad * r43365 10/brlcad/trunk/src/proc-db/kurt.c: !EQUAL instead of != for floating point comparison |
| 15:25.37 | starseeker | 580K |
| 15:26.25 | dloman | looks like the per file overhead is a bit more than 104 bytes eh? |
| 15:26.36 | dloman | or are there a bajillion files? |
| 15:26.55 | starseeker | yeah, there's a lot of files |
| 15:26.55 | CIA-77 | BRL-CAD: 03brlcad * r43366 10/brlcad/trunk/src/proc-db/ (16 files): quell verbose compilation warnings mostly related to unused params and vars, shadowings, and checking usage. |
| 15:27.16 | starseeker | plus the .svn checkout keeps a baseline copy of each file and a properties file for each file |
| 15:27.28 | starseeker | .svn is 23 Megs, rest is checkout |
| 15:28.43 | dloman | idealisticly, we could boil the whole repo down to one or two baseline versions of each prim, and just use a ton of matricies :) |
| 15:28.45 | CIA-77 | BRL-CAD: 03starseeker * r43367 10/geomcore/trunk/tests/svntest/main.c: Try writing out every object, and directory organization. Use havoc for more of a stress test - performance doesn't look promising |
| 15:29.10 | starseeker | somewhat amusingly, the actual repository (as opposed to the checkouts) is 1.7 megs |
| 15:31.06 | dloman | thought: if we are using dbobject names to link to other files, why can't a region contain all its own prims, but still be able to link to other region .g's for prims too ? whats wrong with that? |
| 15:31.34 | starseeker | uh... |
| 15:31.50 | starseeker | that gets back to the whole "redefine what a region means" problem |
| 15:34.52 | dloman | Well, what ever the solution is, having two copies of the same solid, one to construct r1, one to be a overlap subtraction for r2, is going to make a bunch of people really upset. |
| 15:35.09 | starseeker | hmm... so if the count is right, there were just shy of 3000 objects, which means counting the base files and props files just shy of 9000 files for havoc, not counting any other svn files in the checkout |
| 15:36.34 | dloman | as in 9000 in the repo and 3000 end user visible? |
| 15:36.41 | starseeker | yep |
| 15:37.16 | dloman | well, thats better than I thought :) brlcad and I were thinking an average of 10k per model. |
| 15:37.25 | dloman | granted, its just havoc |
| 15:37.31 | starseeker | nods |
| 15:37.37 | starseeker | simple model |
| 15:37.47 | dloman | but converted geometry is like to have less objects, but larger size per |
| 15:38.18 | dloman | i think the last conversion i worked with had about 1500 db objects, but the .g file size was 280 mges |
| 15:38.24 | starseeker | I suppose committing and checking out an entire model in one gulp could also be regarded as worst case |
| 15:38.24 | dloman | megs |
| 15:38.41 | dloman | yeah, untill the multi-system projects start hooking in :) |
| 15:39.15 | starseeker | "checking out" in this case is also creating the repository on disk |
| 15:39.29 | brlcad | that overhead is pretty much what I expected |
| 15:39.48 | brlcad | so the checkout is 1.7, repo is 23 .. original was? |
| 15:39.49 | starseeker | it might be worth investigating if there are ways to talk to the repo without an explicit checkout to disk |
| 15:40.11 | starseeker | no, checkout is 35, repo is 1.7, original was 580K |
| 15:40.21 | starseeker | 35 Meg, 1.7 Meg |
| 15:40.39 | brlcad | checkout includes .svn dir data |
| 15:40.42 | brlcad | what's the export size? |
| 15:40.45 | starseeker | running the test as currently committed on the Mac takes 4.5 minutes |
| 15:41.02 | starseeker | about 12 Megs, I think... |
| 15:41.10 | brlcad | figure the mac should be worst case performance, so it's a good baseline |
| 15:42.07 | brlcad | the reason for stopping at the region level was to fight some of that performance, I expect it to knock that at least in half if not more |
| 15:42.47 | dloman | so with stopping at the r level, how does one handle using s1 from r1 as a subtraction in r2? |
| 15:43.04 | brlcad | putting the repo more on par with the .g size (maybe 25% expansion, minor), and checkout around an order larger |
| 15:43.40 | brlcad | in the short term or long term? :) |
| 15:43.59 | brlcad | and under the hood, or exposed-to-user? |
| 15:44.05 | dloman | exposed to user |
| 15:45.10 | brlcad | going to take a sec to write |
| 15:51.27 | dloman | gets his grub on while he waits. Grilled Cheeze == nom nom nom |
| 15:52.57 | brlcad | so "s1" is some member of this 'part' object "r1", which I'm going to intentionally avoid calling a region for reasons that will hopefully become evident. so this piece of solid part r1 is being used as a subtraction shape on solid part r2. previously both in their same namespace, but no longer with this new 'part' concept -- each part is a unique namespace. so the subtraction of r1/s1 from r2 becomes a cross-namespace reference for the overlapping portions ( |
| 15:53.41 | CIA-77 | BRL-CAD: 03r_weiss * r43368 10/brlcad/trunk/src/libbn/bntester.c: Added to 'bntester' support for testing function 'bn_isect_lseg3_lseg3'. |
| 15:54.01 | brlcad | cross-reference namespace then become a conscious decision of modelers to import data (breaking the need for a cross-namespace reference), or refactor into a new base part that both r1 and r2 reference |
| 15:54.36 | brlcad | basically what they do now, just with an implicit single namespace |
| 15:55.02 | brlcad | I'll have to revisit our notes from that half-day discussion we had -- because we had it pretty lock solid then |
| 15:55.43 | brlcad | I might have a minor detail off, but shouldn't be far off .. but then it was a couple months ago :) |
| 15:56.14 | dloman | okay, will the end user have to maintain two 's1's or just one? |
| 15:56.15 | brlcad | the whole problem revolved around solving mergability of .g files |
| 15:56.31 | brlcad | they get to decide -- default would be just one s1 |
| 15:57.07 | brlcad | an s1 from the r1 namespace, r1::s1 |
| 15:57.27 | brlcad | if imported as r1::s1 and r2::s1, then they have to make a decision whether those are mergable or not |
| 15:57.52 | dloman | so a modeler uses s1 from part1, or part1::s1, in part2 as a subtraction, or part2 = part2::s1 - part1::s1 |
| 15:57.53 | brlcad | but then we can provide tools to assist with that decision process -- auto-merge identical geometry, for instance |
| 15:58.10 | brlcad | right |
| 15:58.16 | dloman | and the modeler doesn't want to make a new part.... how do we store that on our end? |
| 15:58.41 | starseeker | if I'm going to sort assemblies out from combinations, I'll probably have to get search set up to return a list of directory pointers - the ged results string won't cut it |
| 15:58.42 | brlcad | then it's a configuration option as to what they might want to auto-do with that type of operation -- auto-import/copy, keep the reference, etc |
| 15:59.13 | brlcad | it literally just becomes a named reference, part1::s1 in part2 |
| 16:00.27 | brlcad | part2 was just "u s1" with s1 being an implicit part2::s1 -- with the subtraction and absent any automerging, it becomes: "u s1 - part1::s1" as string data in the .g file |
| 16:00.53 | brlcad | the part that's escaping me at the moment (no pun intended) is how we solved the "where's my namespace" problem |
| 16:01.02 | dloman | so we wont be storing two copies of part1::s1 ? |
| 16:01.11 | brlcad | nope |
| 16:01.27 | dloman | okay then. |
| 16:01.53 | dloman | so by this logic, the overall svn dir structure wont ever exceed two dirs deep? (but be very wide) ? |
| 16:01.53 | brlcad | only if they request exactly that as an operation -- "cut my external refs" .. "import external refs", etc |
| 16:02.09 | brlcad | that's the part that I'm not remembering without our notes |
| 16:02.20 | brlcad | we'd solved that issue |
| 16:02.35 | brlcad | I think it was with top-level namespacing |
| 16:02.53 | brlcad | so not a part1 namespace, but some higher tank1 namespace and tank2 namespace |
| 16:03.16 | dloman | right, per my understanding and notes and diagrams, we left our last talk thinking the repo will be three layers deep: projects->combs/regs->prims |
| 16:03.31 | dloman | now i'm hearing different, hence my confusion :) |
| 16:03.57 | brlcad | s/projects/namespaces/ and I can see that :) |
| 16:04.26 | brlcad | yeah, I wasn't being entirely precise last night as the focus was more just that there needs to be "some" mechanism to halt traversal part-way down the DAG |
| 16:04.45 | brlcad | because of the horrid performance impact I was anticipating |
| 16:04.50 | dloman | namespaces->regions/combs .... thats it, since all the prims will be stored in the files in the regions/combs level |
| 16:05.54 | dloman | ..if I am understanding correctly. |
| 16:05.55 | brlcad | yeah, the details are starting to come back to me now :) |
| 16:06.12 | starseeker | I can probably get a rough idea of how expensive writing out regions will be, but it won't be meaningful until I can sort out the assemblies and that's not so straightforward |
| 16:06.59 | *** join/#brlcad roberthl (~robert@v001.rhl.me.uk) | |
| 16:06.59 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 16:07.18 | starseeker | almost feels like the search logic needs to move from ged to somewhere else |
| 16:07.23 | starseeker | and have ged wrap it |
| 16:07.27 | starseeker | but not sure where to move it |
| 16:07.30 | brlcad | yep, librt |
| 16:07.38 | starseeker | heh, that works |
| 16:07.43 | brlcad | mged -> libged -> librt is the progression of logic |
| 16:07.52 | brlcad | there's a lot in libged that belongs in librt |
| 16:08.14 | starseeker | ok, I'm gonna have to move that as a first step - I need the search filters to do an intelligent breakout |
| 16:08.19 | brlcad | libged in a final state would actually end up with very little, just state container wrappers and string parsing really |
| 16:09.37 | brlcad | daniel's comment was a good one, libged isn't really optimal underneath the GE -- it's at the same level, so most of the geometry manipulation it performs is logic that should be in librt (and is, in a way) |
| 16:10.19 | brlcad | it becomes more of a transaction management interface that bridges and simplifies all that's possible with librt |
| 16:13.07 | brlcad | dloman: will have to revisit the notepad next time I'm in the office (maybe friday) to make sure we're fresh on the solution we came up with, it was pretty tight and there are a few particulars I'm not remembering at the moment |
| 16:13.18 | dloman | so GE *isn't* a C++ wrapper for libged? |
| 16:13.29 | dloman | I likely won't be back in the office till next Wednesday |
| 16:13.57 | brlcad | it could be as an interim solution, but really shouldn't be |
| 16:14.56 | brlcad | libged is really a transactional command parsing library .. that string parsing foo is major suck for any sort of performance geometry processing |
| 16:15.02 | brlcad | GE is more akin to ACIS |
| 16:15.05 | dloman | so if the GE is side by side with ged, then any/all common functionality needs to be pushed down into librt (and possibly elsewhere too) otherwise we're duplicating code? (Did i capture the concept correctly?) |
| 16:15.19 | brlcad | you got it |
| 16:15.55 | brlcad | alternatively, pushed into GE and libged sits on top of GE .. but librt makes more sense at the moment |
| 16:16.29 | dloman | isn't libged primarily c? |
| 16:16.38 | brlcad | basically "libged > GE > librt" or "libged,GE > librt" (current plan) |
| 16:16.53 | brlcad | right, that's why it makes more sense to stay that way |
| 16:17.24 | brlcad | it could easily be an encapsulated wrapper, where the GE c++ness would be mere implementation detail like opennurbs in librt |
| 16:17.42 | dloman | in order to keep the code from getting wicked stupid, then GE would also need to be c, not C++ ...? |
| 16:17.52 | brlcad | not at all |
| 16:18.25 | brlcad | because libged's api is presently a single data container and argc/argv string data |
| 16:18.41 | brlcad | what goes on under the hood stays under the hood |
| 16:18.50 | brlcad | (bom chika wah wah) |
| 16:21.59 | CIA-77 | BRL-CAD: 03brlcad * r43369 10/brlcad/trunk/src/remrt/ihost.c: if DEFINED, not if NOT defined |
| 16:22.04 | brlcad | oof, that took a while to see... |
| 16:30.11 | dloman | alright, Im going afk for a few days. I expect the GS to be finished when I return. Hop to it! :P |
| 16:31.26 | dloman-afk | (I only say that cause its now very apparent to me that I have (and had) no idea what I'm doing, heh ) |
| 16:41.24 | brlcad | we need to get rolling on gsoc preparations if you all are interested in mentoring again -- the ideas page needs major updating |
| 16:51.45 | CIA-77 | BRL-CAD: 03brlcad * r43370 10/brlcad/trunk/src/remrt/ihost.h: include the headers this header requires, self containment |
| 16:52.26 | starseeker | sounds like fun |
| 16:52.33 | CIA-77 | BRL-CAD: 03brlcad * r43371 10/brlcad/trunk/src/remrt/ (remrt.c rtsrv.c): mark unused params, check argc params, terminal sentinel with NULL instead of 0, and other quellage |
| 17:21.15 | _psilva | hey brlcad |
| 17:21.20 | _psilva | got some news for you |
| 17:24.42 | brlcad | sup? |
| 17:25.16 | brlcad | you spawned a child process? :) |
| 18:25.45 | _psilva | then it's two thing |
| 18:25.48 | _psilva | hah |
| 18:25.54 | _psilva | due march 16 ish |
| 18:26.08 | _psilva | but even bigger and more relevant |
| 18:26.20 | _psilva | we got bought by autocad |
| 18:26.23 | _psilva | er |
| 18:26.25 | _psilva | autodesk |
| 18:26.55 | _psilva | http://usa.autodesk.com/adsk/servlet/index?id=16284057&siteID=123112 |
| 18:27.11 | _psilva | is now autodesk employee |
| 19:31.35 | starseeker | _psilva: do we offer condolances? |
| 20:05.30 | brlcad | _psilva: heh, well congrats on the 16th and condolences on the 30th (april) |
| 20:09.46 | _psilva | heh |
| 20:10.23 | _psilva | at least we're not being relocated |
| 20:10.30 | _psilva | :) |
| 20:15.10 | _psilva | we'll see |
| 20:15.19 | _psilva | gonna stick around until something more interesting pops up |
| 20:31.35 | CIA-77 | BRL-CAD: 03jordisayol * r43372 10/brlcad/trunk/ (misc/debian/control sh/make_deb.sh): modify dependencies to build deb packages |
| 21:01.58 | CIA-77 | BRL-CAD: 03starseeker * r43373 10/brlcad/trunk/ (7 files in 3 dirs): Make a stab at moving search logic to librt |
| 21:22.17 | CIA-77 | BRL-CAD: 03starseeker * r43374 10/brlcad/branches/cmake/ (56 files in 18 dirs): MFC r43373 |
| 21:33.37 | CIA-77 | BRL-CAD: 03starseeker * r43375 10/brlcad/trunk/src/librt/search.c: Fix order of inputs, UNUSED some inputs |
| 21:37.27 | CIA-77 | BRL-CAD: 03starseeker * r43376 10/brlcad/branches/cmake/src/librt/search.c: MFC r43375 |
| 21:38.15 | CIA-77 | BRL-CAD: 03brlcad * r43377 10/brlcad/trunk/src/librt/bool.c: |
| 21:38.15 | CIA-77 | BRL-CAD: call NEAR_EQUAL() with a 0.001 tolerance instead of rt_fdiff() since that |
| 21:38.15 | CIA-77 | BRL-CAD: function is deprecated. this potentially affects fastgen platemode overlap |
| 21:38.15 | CIA-77 | BRL-CAD: reporting since it's no longer performing a relative tolerance comparison, but |
| 21:38.16 | CIA-77 | BRL-CAD: the impact shouldn't be too significant since the absolute tolerance is rather |
| 21:38.16 | CIA-77 | BRL-CAD: loose at 0.001 |
| 21:40.26 | CIA-77 | BRL-CAD: 03starseeker * r43378 10/brlcad/branches/cmake/src/ (libged/CMakeLists.txt librt/CMakeLists.txt): Fix CMake logic for search file changes |
| 21:41.25 | CIA-77 | BRL-CAD: 03brlcad * r43379 10/brlcad/trunk/src/librt/db_flip.c: |
| 21:41.25 | CIA-77 | BRL-CAD: use a bridge pattern to separate the deprecated function logic into new private |
| 21:41.25 | CIA-77 | BRL-CAD: functions. this lets us continue to be able to flip v4 files, even after the |
| 21:41.25 | CIA-77 | BRL-CAD: deprecated rt_* functions become obsolete, yet allows for the API to continue |
| 21:41.25 | CIA-77 | BRL-CAD: working for now. |
| 21:41.35 | CIA-77 | BRL-CAD: 03brlcad * r43380 10/brlcad/trunk/src/librt/librt_private.h: declare the new flip functions |
| 21:42.24 | CIA-77 | BRL-CAD: 03brlcad * r43381 10/brlcad/trunk/src/librt/binunif/db5_bin.c: call ntohl() and htonl() instead of the deprecated libbu functions. |
| 21:42.53 | CIA-77 | BRL-CAD: 03brlcad * r43382 10/brlcad/trunk/src/librt/comb/db_comb.c: call the new private flip funcs instead of the deprecated api. |
| 22:33.32 | brlcad | starseeker: librt api should not have argc/argv parameters |
| 22:34.29 | starseeker | brlcad: all right, I'll have to revert then - reworking the code to not use them could be a significant effort |
| 22:34.39 | brlcad | yeah, moving search to librt is not going to be a simple move |
| 22:34.45 | brlcad | it needs to work on data |
| 22:35.22 | starseeker | well, that's a days work down the drain |
| 22:35.29 | brlcad | data in, data out -- no printing to console (except diagnostic) |
| 22:36.03 | starseeker | uh... it's not printing to console |
| 22:36.10 | brlcad | so you'd get back, for example, an array of rt_db_internal pointer's from a given query -- the search front-end would iterate over a result and print their names |
| 22:37.09 | starseeker | that's edging dangerously close to a complete rework |
| 22:37.28 | brlcad | I was surprised that you were heading down that road :) |
| 22:37.42 | starseeker | well, is there another way to spot assemblies? |
| 22:37.45 | brlcad | it's doable, not necessarily a rewrite |
| 22:38.10 | brlcad | the hardest part of search is building up that query filtering logic, stopping criteria -- that all stays the same |
| 22:38.31 | starseeker | if I'm going to do the one .g per region, I have to be able to identify the assembly combinations - they will need to be written out as their own objects, since the region .g files won't handle them |
| 22:40.05 | brlcad | search still sounds like a good approach for that |
| 22:40.27 | brlcad | you just have to split things up some |
| 22:40.47 | CIA-77 | BRL-CAD: 03starseeker * r43383 10/brlcad/trunk/src/librt/search.c: |
| 22:40.47 | CIA-77 | BRL-CAD: Add logic to append directory pointer entries to a list - will allow for |
| 22:40.47 | CIA-77 | BRL-CAD: manipulation of objects found in C code without having to re-parse string. For |
| 22:40.47 | CIA-77 | BRL-CAD: now, only return pointer to leaf node of path - could conceivably be expanded if |
| 22:40.47 | CIA-77 | BRL-CAD: there is a need. |
| 22:40.50 | brlcad | somewhere in search, I'm sure it's taking the input argc/argv and turning that into an in-memory expression of some sort |
| 22:41.08 | starseeker | brlcad: it is. I'm quite sure it can be done, but it's... tangled |
| 22:41.27 | brlcad | that logic stays in libged's search front-end, librt takes that in-memory expression as a parameter to rt_search() |
| 22:41.45 | brlcad | layers, like an onion ;) |
| 22:41.56 | starseeker | brlcad: what should I do - full revert, put everything back in libged? |
| 22:42.23 | starseeker | I'm pretty sure I won't have time until next month to do that kind of sorting out of the search logic |
| 22:46.26 | brlcad | might as well |
| 22:46.39 | starseeker | k |
| 22:46.59 | CIA-77 | BRL-CAD: 03starseeker * r43384 10/brlcad/branches/cmake/src/librt/ (6 files in 3 dirs): MFC r43383 |
| 22:48.17 | brlcad | at a glance, looks like it's pretty close already -- find_formplan() would become something like rt_search_plan(), find_execute() would probably become something like rt_search(). that'd be your two new api hooks |
| 22:48.59 | brlcad | ged_search() looks rather peculiar to me.. how does it know how many expression arguments there are?? |
| 22:50.00 | starseeker | what, the altered one or the original? |
| 22:50.47 | starseeker | OK, everything should be back in place |
| 22:51.03 | brlcad | I don't know -- I'm just looking at my current checkout with is r42551 |
| 22:51.22 | starseeker | oh, yeah that's the original |
| 22:51.42 | brlcad | Oh.. is the entire expression in argv[1]?? |
| 22:51.45 | brlcad | heh |
| 22:51.47 | starseeker | yeah |
| 22:51.49 | brlcad | wow |
| 22:51.55 | starseeker | it's up to the search functions to make sense of it |
| 22:52.21 | brlcad | so yeah.. a few changes |
| 22:53.59 | brlcad | ged_search() should take variable argc/argv, one per actual argument .. that would get parsed into an "rt_search_plan" struct of some sort (basically a custom "PLAN *"), that'd get passed to rt_search() |
| 22:54.29 | CIA-77 | BRL-CAD: 03starseeker * r43385 10/geomcore/trunk/tests/svntest/main.c: |
| 22:54.30 | CIA-77 | BRL-CAD: Add some commented out code based on the test code used in ged_search to test |
| 22:54.30 | CIA-77 | BRL-CAD: directory pointer list printing. Will need to construct argc/argv input for |
| 22:54.30 | CIA-77 | BRL-CAD: rt_search, but this should in principle allow the identification in C code of |
| 22:54.30 | CIA-77 | BRL-CAD: assemblies. |
| 22:54.55 | brlcad | librt could provide rt_search_plan() as a helper function to turn the string data into an rt_search_plan, but you'd be able to bypass that and do it all string-less with rt_search() then if you wanted |
| 22:54.57 | starseeker | brlcad: we need to be careful there - the find command has its own option handling logic, I don't know how similar it is to our normal stuff |
| 22:56.16 | brlcad | not too careful -- at worse, ged_search() and/or rt_search_plan() would just join all of the argv parameters together into one bit string and pass to find's plan making code |
| 22:56.45 | starseeker | uh... if we're doing that, why bother splitting them up in the first place? |
| 22:57.02 | brlcad | ahh, I see -- it's not one big string |
| 22:57.12 | brlcad | it's iterating afterall |
| 22:57.20 | brlcad | but requires a NULL-terminated argv |
| 22:57.46 | brlcad | you're not splitting them up, they start out split up |
| 22:58.18 | starseeker | sort of - formplan gets argv[2] |
| 22:59.10 | brlcad | but as a char **, it then iterates over the argv elements individually |
| 22:59.18 | starseeker | right |
| 22:59.35 | brlcad | so it's not all in argv[1]/argv[2] |
| 22:59.43 | brlcad | it's already a proper argv list |
| 22:59.57 | starseeker | brlcad: as long as we're at this... is there a function somewhere to do for bu_lists or some other bu data structure what uniq does on the unix command line? |
| 23:00.53 | starseeker | you hand mentioned wanting to fix some search behavior that was unexpected, and iirc it required always doing a full path iteration, so to simulate searching through ls results we would need to do some kind of uniq filtering |
| 23:00.57 | CIA-77 | BRL-CAD: 03starseeker * r43386 10/brlcad/trunk/ (7 files in 3 dirs): Sigh. Put search back in libged for now - need to split out the argument parsing logic into libged and the backend logic into librt first. |
| 23:01.03 | brlcad | bu_ptbl's have unique awareness for pointer tracking |
| 23:01.30 | brlcad | bu_ptbl_ins_unique() |
| 23:01.34 | starseeker | hmm... can I stash directory pointers in a bu_ptbl? |
| 23:01.45 | brlcad | ptbl == pointer table |
| 23:01.48 | brlcad | arbitrary pointer container |
| 23:02.19 | starseeker | ok, that might do then |
| 23:02.23 | brlcad | redblack trees have similar uniqueness insertion routines |
| 23:02.39 | brlcad | depends what sort of O behavior you need |
| 23:03.21 | brlcad | so search is already pretty close to what you'd need for librt from what I'm seeing here |
| 23:03.58 | brlcad | the biggest change is just fixing the routine names, creating corresponding rt_ prefix names for the api |
| 23:04.26 | starseeker | and making sure everything functions in libged/librt respectively |
| 23:04.29 | brlcad | the code already has that separation I referred to |
| 23:05.07 | starseeker | ah, good :-) |
| 23:05.19 | brlcad | think of it as only migrating find_formplan() and find_execute() to librt, but not with those names |
| 23:05.48 | brlcad | ged_search() stays in libged exactly as it is, just pointing to the new names instead of find_formplan() and find_execute() |
| 23:06.02 | starseeker | well, I've got tomorrow so I'll do what I can |
| 23:06.14 | brlcad | instead of find_formplan() returning a PLAN*, it should be some rt_plan_t or somesuch |
| 23:06.57 | starseeker | hmm - db_plan_t maybe? |
| 23:07.01 | brlcad | find_formplan() would get renamed to something like rt_search_plan(); find_execute() would get renamed to something like rt_search() |
| 23:07.13 | starseeker | doesn't really have much to do with raytracing - db_ prefix may make more sense |
| 23:07.17 | brlcad | it could be db_ api instead of rt_ api |
| 23:07.18 | brlcad | sure |
| 23:07.31 | brlcad | unless it's going to return rt_db_internal objects |
| 23:07.34 | brlcad | then it's rt_ api |
| 23:07.47 | brlcad | I think |
| 23:07.51 | brlcad | have to check on that one |
| 23:08.11 | brlcad | ah, yes, find_execute() would have to be refactored to not have a gedp parameter |
| 23:08.23 | brlcad | same with findplan |
| 23:08.49 | starseeker | will probably return a list of db_full_path structs and a bu_ptbl of directory pointers |
| 23:09.07 | starseeker | yeah, ged structs are everywhere in there |
| 23:09.20 | starseeker | I got those out once, so I'm not too worried about that - just takes time |
| 23:10.30 | starseeker | or if directory pointers make it rt_ specific, could just return db_full_path list and let the calling function sort it out |
| 23:11.18 | starseeker | that's probably cleaner |
| 01:33.34 | *** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) | |
| 04:34.49 | *** join/#brlcad dtidrow (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) | |
| 04:41.39 | brlcad | yeah, db_full_path list sounds perfect |
| 05:03.20 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 05:47.18 | CIA-77 | BRL-CAD: 03brlcad * r43387 10/brlcad/trunk/src/rttherm/spectrum.c: more ZERO() conversion for exact floating point comparisons |
| 05:48.34 | CIA-77 | BRL-CAD: 03brlcad * r43388 10/brlcad/trunk/src/irprep/irdisp.c: init before use |
| 05:49.31 | CIA-77 | BRL-CAD: 03brlcad * r43389 10/brlcad/trunk/src/proc-db/ (brepintersect.cpp lens.c surfaceintersect.cpp): init before use |
| 05:49.54 | CIA-77 | BRL-CAD: 03brlcad * r43390 10/brlcad/trunk/src/lgt/ir.c: VINIT_ZERO love |
| 05:50.13 | CIA-77 | BRL-CAD: 03brlcad * r43391 10/brlcad/trunk/src/nirt/showshot.c: more VINIT_ZERO love |
| 06:17.23 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:54.42 | *** join/#brlcad PrezWhiteCalf (MK@whitecalf.net) | |
| 07:08.36 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 12:41.58 | *** join/#brlcad Elrohir (~kvirc@p5B14BA30.dip.t-dialin.net) | |
| 13:50.30 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 14:27.20 | CIA-77 | BRL-CAD: 03d_rossberg * r43392 10/brlcad/trunk/misc/win32-msvc/Dll/brlcad.def: there was a request to export some additional functions |
| 14:43.59 | CIA-77 | BRL-CAD: 03brlcad * r43393 10/brlcad/trunk/src/rt/ (Makefile.am hurt.c): hurt is hurting no more. remove the research project since it's inactive and a maintenance burden to bring up to strictness standards. |
| 14:46.06 | ``Erik | starseeker: http://news.slashdot.org/story/11/02/16/1740257/Compared-and-Contrasted-OpenOffice-V-LibreOffice |
| 14:47.44 | *** join/#brlcad Stattrav (~Stattrav@117.192.142.157) | |
| 14:47.44 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:17.39 | CIA-77 | BRL-CAD: 03brlcad * r43394 10/brlcad/trunk/src/librt/db_flip.c: not return, just run the function |
| 15:33.29 | CIA-77 | BRL-CAD: 03erikgreenwald * r43395 10/brlcad/trunk/src/librt/binunif/db5_bin.c: add arpa/inet.h for ntohl/htonl |
| 18:14.59 | CIA-77 | BRL-CAD: 03brlcad * r43396 10/brlcad/trunk/src/ (29 files in 2 dirs): |
| 18:15.00 | CIA-77 | BRL-CAD: major quellage cleanup including missing struct elements, unused parameters, |
| 18:15.00 | CIA-77 | BRL-CAD: exact floating point comparisons, unused vars, and much more. big honkin commit |
| 18:15.00 | CIA-77 | BRL-CAD: because of two changes that ripple through. ap global changed to APP so that |
| 18:15.00 | CIA-77 | BRL-CAD: params passing an ap can use ap for the param name. also replaced convention of |
| 18:15.00 | CIA-77 | BRL-CAD: using a version char* global with a version() function. |
| 18:28.00 | CIA-77 | BRL-CAD: 03brlcad * r43397 10/brlcad/trunk/src/rttherm/viewtherm.c: missed one. quellage cleanup including version conversion. |
| 18:47.08 | starseeker | ``Erik: yeah, saw that - rather premature. Libreoffice hasn't had time to diverge much from OO.org |
| 19:05.58 | CIA-77 | BRL-CAD: 03brlcad * r43398 10/brlcad/trunk/src/rttherm/viewtherm.c: usage is no longer static |
| 19:13.54 | *** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net) | |
| 19:14.04 | _psilva | test |
| 19:14.09 | _psilva | huh |
| 19:14.54 | _psilva | anyone know these guys? http://www.cfdesign.com/ |
| 19:24.46 | CIA-77 | BRL-CAD: 03bob1961 * r43399 10/brlcad/trunk/src/libfb/if_wgl.c: This fixes a bug on windows where drawing strings breaks. |
| 19:38.49 | CIA-77 | BRL-CAD: 03bob1961 * r43400 10/brlcad/trunk/src/tclscripts/lib/RtControl.tcl: Accommodate possible spaces in . |
| 20:53.00 | CIA-77 | BRL-CAD: 03starseeker * r43401 10/brlcad/branches/cmake/ (54 files in 14 dirs): MFC r43400 and fixes to CMakeLists.txt files |
| 21:03.32 | CIA-77 | BRL-CAD: 03starseeker * r43402 10/brlcad/branches/cmake/ (CMakeLists.txt src/conv/CMakeLists.txt): Get distcheck working for CMake |
| 21:34.29 | CIA-77 | BRL-CAD: 03brlcad * r43403 10/brlcad/trunk/src/rttherm/ (pixtest.c spectrum.c ssampview.c): remove dead code, remove rt_ prefix on functions that aren't actually in librt (curiously relevent to librt/spectrum.c but not librt api nonetheless). |
| 21:35.18 | brlcad | _psilva: nope |
| 21:47.53 | CIA-77 | BRL-CAD: 03brlcad * r43404 10/brlcad/trunk/src/shapes/ (coil.c fence.c): handle a slew of exact floating point comparisons for zero and equality |
| 21:51.03 | CIA-77 | BRL-CAD: 03brlcad * r43405 10/brlcad/trunk/src/shapes/wire.c: make sure there aren't unexpected params |
| 21:51.24 | CIA-77 | BRL-CAD: 03brlcad * r43406 10/brlcad/trunk/src/shapes/picket_fence.c: quellage, shadow on osx |
| 22:06.06 | brlcad | can feel it getting close... |
| 22:06.07 | CIA-77 | BRL-CAD: 03brlcad * r43407 10/brlcad/trunk/src/sig/ (24 files): squelch the quellch. simple floating point exactness conversions. |
| 22:09.35 | CIA-77 | BRL-CAD: 03brlcad * r43408 10/brlcad/trunk/src/tab/script.l: squelch warning about not using yyunput() by not outputting that function |
| 22:13.01 | CIA-77 | BRL-CAD: 03brlcad * r43409 10/brlcad/trunk/src/tab/txyz-pl.c: de-k&r, use argv and remove authorship |
| 22:18.11 | CIA-77 | BRL-CAD: 03brlcad * r43410 10/brlcad/trunk/src/tab/ (Makefile.am txyz-pl.c): |
| 22:18.12 | CIA-77 | BRL-CAD: remove the txyz-pl program outright as it is nearly identical to the util/xyz-pl |
| 22:18.12 | CIA-77 | BRL-CAD: program. it merely parses and ignores an additional starting column. trivially |
| 22:18.12 | CIA-77 | BRL-CAD: achieved with cut, awk, or other tools, so remove this deviant in favor of the |
| 22:18.12 | CIA-77 | BRL-CAD: one in util where it more appropriately belongs anyways. |
| 22:21.23 | CIA-77 | BRL-CAD: 03brlcad * r43411 10/brlcad/trunk/NEWS: minor, but unfortunately user visible. removed the txyz-pl tool because it is a redundant minor variation of our xyz-pl tool easily replaced with an awk, sed, or cut pipe. |
| 23:19.37 | CIA-77 | BRL-CAD: 03r_weiss * r43412 10/brlcad/trunk/src/libbn/bntester.c: Updates to bntester.c for testing function bn_isect_lseg3_lseg3. |
| 04:38.01 | CIA-77 | BRL-CAD: 03brlcad * r43413 10/brlcad/trunk/src/other/URToolkit/cnv/rletorla.c: check if defined before checking value |
| 04:41.22 | brlcad | is in disbelief, I think that's a complete clean strict build now |
| 04:54.51 | CIA-77 | BRL-CAD: 03brlcad * r43414 10/brlcad/trunk/configure.ac: |
| 04:54.52 | CIA-77 | BRL-CAD: want to enable strict building on all sources now that all dirs are passing, but |
| 04:54.52 | CIA-77 | BRL-CAD: can't due to src/other needing -w .. and passing that cleanly to the |
| 04:54.52 | CIA-77 | BRL-CAD: subconfigures is a bit of suckage. maybe something cmake can handle better |
| 05:10.29 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 05:10.29 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:16.42 | *** join/#brlcad Stattrav (~Stattrav@122.172.6.241) | |
| 05:16.42 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:13.04 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 08:57.05 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 12:31.56 | *** join/#brlcad kanzure_ (~kanzure@bioinformatics.org) | |
| 12:55.53 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:39.03 | CIA-77 | BRL-CAD: 03starseeker * r43415 10/brlcad/branches/cmake/ (4 files in 4 dirs): (log message trimmed) |
| 13:39.03 | CIA-77 | BRL-CAD: We don't want any of the CFLAGS being added to the BRL-CAD build to make it to |
| 13:39.03 | CIA-77 | BRL-CAD: src/other - from what I'm seeing on the CMake list the correct way to do this |
| 13:39.03 | CIA-77 | BRL-CAD: seems to be adding the src/other subdirectory before any CFLAGS are set at the |
| 13:39.03 | CIA-77 | BRL-CAD: top level. This also means that the src/other CMakeLists.txt files have to |
| 13:39.04 | CIA-77 | BRL-CAD: 'stand on their own' a bit more than before - i.e. they can't depend on the |
| 13:39.05 | CIA-77 | BRL-CAD: toplevel settings to give them what they need. This is fine (indeed it's the |
| 13:40.03 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 13:41.11 | CIA-77 | BRL-CAD: 03starseeker * r43416 10/brlcad/branches/cmake/CMakeLists.txt: Need arpa/inet.h test |
| 13:45.17 | starseeker | hmm... everything's getting rebuilt after a cmake run, may need to study why that src/other change had that impact |
| 13:46.10 | starseeker | will have to make sure the parent C_FLAGS aren't getting in there on the second pass... |
| 13:49.46 | starseeker | oh, I see - CFLAGS and CXXFLAGS keep getting variables appended |
| 14:16.24 | ``Erik | CFLAGS="$(sed s/ /^M/g ${CFLAGS} | sort | uniq | xargs)" ? too unix? |
| 14:20.34 | starseeker | ``Erik: it's not that, it's just that I'm not resetting properly... |
| 14:21.17 | CIA-77 | BRL-CAD: 03starseeker * r43417 10/brlcad/branches/cmake/CMakeLists.txt: initialize CFLAGS like we mean it |
| 14:21.29 | starseeker | some of the macros are appending too aggressively, but I'll have to sort that out later |
| 14:21.38 | starseeker | in the meantime, that should do |
| 15:27.05 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 15:35.52 | *** join/#brlcad dli (~dli@dsl-67-204-45-87.acanac.net) | |
| 16:09.55 | *** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de) | |
| 16:44.11 | CIA-77 | BRL-CAD: 03bob1961 * r43418 10/brlcad/trunk/src/libtclcad/ged_obj.c: Minor tweak to go_refresh_view(). |
| 17:10.12 | CIA-77 | BRL-CAD: 03bob1961 * r43419 10/brlcad/trunk/src/tclscripts/ (6 files in 2 dirs): Moved cursor.tcl from archer to lib. |
| 18:36.45 | brlcad | starseeker: include headers got updated -- that'll cause a rebuild |
| 18:37.02 | brlcad | ahh, you sorted it out, flags |
| 18:37.10 | brlcad | crawls back in a hole |
| 18:42.01 | _psilva | :( |
| 19:01.17 | CIA-77 | BRL-CAD: 03erikgreenwald * r43420 10/brlcad/trunk/src/gtools/remapid.c: remove function defined as static but never used |
| 19:12.10 | CIA-77 | BRL-CAD: 03erikgreenwald * r43421 10/brlcad/trunk/src/ (8 files in 7 dirs): warning quellage |
| 19:19.06 | CIA-77 | BRL-CAD: 03erikgreenwald * r43422 10/geomcore/trunk/tests/CMakeLists.txt: park tests in a seperate directory |
| 19:27.42 | *** join/#brlcad WhiteCalf (~MK@whitecalf.net) | |
| 19:53.51 | *** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de) | |
| 21:06.47 | *** part/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 21:15.35 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 00:02.33 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 00:02.33 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202) | |
| 05:07.58 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 05:33.07 | *** join/#brlcad Stattrav (~Stattrav@122.167.175.247) | |
| 05:33.07 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:01.17 | *** join/#brlcad Stattrav (~Stattrav@122.172.14.69) | |
| 06:01.17 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:17.58 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 06:17.59 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202) | |
| 09:23.01 | *** join/#brlcad PrezWhiteCalf (~MK@whitecalf.net) | |
| 13:07.09 | *** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ) | |
| 13:08.43 | *** join/#brlcad alex_jon1 (~alex_joni@81.196.65.201) | |
| 16:31.38 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 16:58.39 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 18:39.55 | *** join/#brlcad mafm (~mafm@222.Red-83-49-87.dynamicIP.rima-tde.net) | |
| 19:22.48 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 03:23.28 | *** join/#brlcad Yoshi47 (~jan@d72-39-60-53.home1.cgocable.net) | |
| 09:27.11 | *** join/#brlcad Stattrav (~Stattrav@117.192.150.90) | |
| 09:27.12 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:16.55 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 10:39.43 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:43.48 | *** join/#brlcad Stattrav (~Stattrav@117.192.150.90) | |
| 14:43.48 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:41.47 | *** join/#brlcad PrezWhiteCalf (MK@whitecalf.net) | |
| 17:25.47 | *** join/#brlcad Stattrav (~Stattrav@117.192.150.90) | |
| 17:25.47 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:31.22 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.129.182) | |
| 02:33.13 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 06:26.50 | *** join/#brlcad Stattrav (~Stattrav@122.172.167.195) | |
| 06:26.50 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:35.07 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 08:28.32 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 08:53.23 | *** join/#brlcad Stattrav (~Stattrav@122.172.167.195) | |
| 08:53.23 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:24.16 | ``Erik | 1/cl |
| 14:51.45 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 22:33.06 | *** join/#brlcad Ralith (~ralith@d142-058-083-162.wireless.sfu.ca) | |
| 22:35.42 | *** join/#brlcad Ralith_ (~ralith@d142-058-083-162.wireless.sfu.ca) | |
| 22:49.17 | *** join/#brlcad Ralith (~ralith@d142-058-095-035.wireless.sfu.ca) | |
| 23:28.00 | *** join/#brlcad merzo (~merzo@107-96-94-178.pool.ukrtel.net) | |
| 03:41.34 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 06:06.46 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:42.21 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 07:36.04 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 08:34.16 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) | |
| 13:23.43 | *** join/#brlcad WhiteCalf (MK@174.36.224.242) | |
| 14:02.37 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 14:53.31 | CIA-77 | BRL-CAD: 03SearchenginopT 07http://brlcad.org * r2480 10/wiki/Search_Engine_Optimisation_-_Easiest_way: New page: '''[http://www.searchengineoptimisationaustralia.com.au/ Search engine optimisation]''' can be the easiest way to gain popularity but can also be the most dangerous one to have. Since it i... |
| 15:09.18 | _psilva | 3h |
| 15:09.22 | _psilva | eh |
| 15:27.32 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 15:43.58 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 16:02.44 | CIA-77 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 16:02.44 | CIA-77 | BRL-CAD: deleted "[[Search Engine Optimisation - Easiest way]]": content was: |
| 16:02.44 | CIA-77 | BRL-CAD: ''''[http://www.searchengineoptimisationaustralia.com.au/ Search engine |
| 16:02.44 | CIA-77 | BRL-CAD: optimisation]''' can be the easiest way to gain popularity but can also be the |
| 16:02.44 | CIA-77 | BRL-CAD: ...' (and the only contributor was |
| 16:02.45 | CIA-77 | BRL-CAD: '[[Special:Contributions/SearchenginopT|SearchenginopT]]') |
| 16:02.46 | CIA-77 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:SearchenginopT]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 16:08.39 | *** join/#brlcad Stattrav (~Stattrav@117.202.26.145) | |
| 16:08.46 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:34.54 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:57.50 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 17:11.19 | CIA-77 | BRL-CAD: 03brlcad * r43423 10/brlcad/trunk/src/librt/primitives/table.c: will rt_generic_xform() work here? |
| 17:11.43 | CIA-77 | BRL-CAD: 03brlcad * r43424 10/brlcad/trunk/src/librt/db_corrupt.c: call new private flip_mat_dbmat() function instead of deprecated rt_mat_dbmat() |
| 17:13.24 | CIA-77 | BRL-CAD: 03brlcad * r43425 10/brlcad/trunk/configure.ac: check for htonll() and ntohll() functions since they're not included in posix.1 with the other byteorder functions. |
| 18:52.30 | *** join/#brlcad roberthl_ (~robert@93-97-176-250.zone5.bethere.co.uk) | |
| 20:26.37 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 21:07.14 | *** join/#brlcad dli (~dli@dsl-67-204-45-87.acanac.net) | |
| 21:07.14 | *** join/#brlcad kanzure_ (~kanzure@bioinformatics.org) | |
| 21:07.14 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 21:07.14 | *** mode/#brlcad [+o ChanServ] by anthony.freenode.net | |
| 21:08.11 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 21:08.11 | *** join/#brlcad dloman-afk (~claymore@BZ.BZFLAG.BZ) | |
| 21:08.11 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 21:08.11 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 21:08.11 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 21:08.11 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 21:08.11 | *** join/#brlcad WhiteCalf (MK@174.36.224.242) | |
| 21:08.12 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 21:08.12 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 21:08.12 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 21:08.12 | *** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ) | |
| 21:08.12 | *** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net) | |
| 21:08.12 | *** join/#brlcad poolio_ (~poolio@BZ.BZFLAG.BZ) | |
| 21:08.12 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 21:08.12 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 21:08.12 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 21:08.12 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 21:09.01 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 21:09.01 | *** join/#brlcad CIA-77 (~CIA@208.69.182.149) | |
| 21:20.47 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 21:20.47 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202) | |
| 21:50.21 | *** join/#brlcad dloman-afk (~claymore@BZ.BZFLAG.BZ) | |
| 21:50.21 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 01:29.29 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 03:19.15 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 05:01.08 | CIA-77 | BRL-CAD: 03brlcad * r43426 10/brlcad/trunk/include/bu.h: not true, they expect pointers |
| 05:54.33 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 06:23.09 | *** join/#brlcad Stattrav (~Stattrav@122.172.31.214) | |
| 06:23.09 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:31.44 | *** join/#brlcad _psilva_ (~psilva@h-67-103-183-185.mclnva23.static.covad.net) | |
| 07:44.33 | *** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net) | |
| 08:30.32 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 10:58.11 | *** join/#brlcad dli (~dli@dsl-67-204-45-87.acanac.net) | |
| 12:24.26 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:25.04 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 14:26.28 | CIA-77 | BRL-CAD: 03brlcad * r43427 10/brlcad/trunk/src/librt/binunif/db5_bin.c: this might have worked, but it was a bad way. don't work with truncated values, cast the char array to the corresponding type being read/written |
| 17:17.30 | CIA-77 | BRL-CAD: 03brlcad * r43428 10/brlcad/trunk/src/librt/binunif/db5_bin.c: typo, supposed to be a pointer. odd. |
| 17:43.58 | *** join/#brlcad mafm (~mafm@100.Red-88-22-160.staticIP.rima-tde.net) | |
| 18:36.56 | *** join/#brlcad mafm_ (~mafm@100.Red-88-22-160.staticIP.rima-tde.net) | |
| 18:37.25 | *** join/#brlcad Ralith (~ralith@d142-058-093-103.wireless.sfu.ca) | |
| 19:26.27 | *** join/#brlcad roberthl (~robert@cpc1-flit1-0-0-cust67.9-1.cable.virginmedia.com) | |
| 19:26.27 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 19:47.33 | *** join/#brlcad roberthl (~robert@v001.rhl.me.uk) | |
| 19:47.33 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 20:14.16 | *** join/#brlcad Ralith (~ralith@d142-058-093-103.wireless.sfu.ca) | |
| 20:39.54 | CIA-77 | BRL-CAD: 03brlcad * r43429 10/brlcad/trunk/ (11 files in 9 dirs): |
| 20:39.54 | CIA-77 | BRL-CAD: convert the bu_external byte buffer from being a genptr_t (i.e., void*) array to |
| 20:39.54 | CIA-77 | BRL-CAD: being a uint8_t* array. this fixes some coercion problems attempting to pass |
| 20:39.54 | CIA-77 | BRL-CAD: data through a void pointer and, more importantly, better reflects the intent of |
| 20:39.54 | CIA-77 | BRL-CAD: the container. |
| 21:26.20 | ``Erik | -:q |
| 21:26.41 | CIA-77 | BRL-CAD: 03erikgreenwald * r43430 10/geomcore/trunk/ (12 files in 7 dirs): wire in OSSF uuid stuff into GSUuid, with minor api changes |
| 21:52.15 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 21:52.16 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 21:52.16 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 21:52.16 | *** join/#brlcad kanzure_ (~kanzure@bioinformatics.org) | |
| 21:52.16 | *** join/#brlcad CIA-77 (~CIA@208.69.182.149) | |
| 21:52.16 | *** mode/#brlcad [+o ChanServ] by anthony.freenode.net | |
| 21:53.19 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 22:20.02 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 22:36.00 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 22:36.24 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 22:40.50 | *** join/#brlcad 50UAAACRT (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 22:40.50 | *** join/#brlcad dloman-afk (~claymore@BZ.BZFLAG.BZ) | |
| 22:40.50 | *** join/#brlcad Ralith (~ralith@d142-058-093-103.wireless.sfu.ca) | |
| 22:40.50 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 22:40.50 | *** join/#brlcad mafm_ (~mafm@100.Red-88-22-160.staticIP.rima-tde.net) | |
| 22:40.50 | *** join/#brlcad dli (~dli@dsl-67-204-45-87.acanac.net) | |
| 22:40.50 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 22:40.50 | *** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net) | |
| 22:40.50 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 22:40.50 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 22:40.50 | *** join/#brlcad 5EXAB9F0G (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 22:40.50 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 22:40.50 | *** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ) | |
| 22:40.50 | *** join/#brlcad poolio_ (~poolio@BZ.BZFLAG.BZ) | |
| 22:40.50 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 22:40.50 | *** join/#brlcad 5EXAB5O7U (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 22:40.50 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 22:41.42 | *** join/#brlcad tofu_ (~sean@BZ.BZFLAG.BZ) | |
| 22:41.43 | *** join/#brlcad dli_ (~dli@dsl-67-204-45-87.acanac.net) | |
| 22:41.44 | *** join/#brlcad kanzure__ (~kanzure@bioinformatics.org) | |
| 22:41.44 | *** join/#brlcad dloman-a1k (~claymore@BZ.BZFLAG.BZ) | |
| 02:33.23 | CIA-77 | BRL-CAD: 03Sean 07http://brlcad.org * r2481 10/wiki/Building_from_SVN: add --enable-all and notes on the install dir |
| 04:10.52 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 04:34.20 | CIA-77 | BRL-CAD: 03brlcad * r43431 10/brlcad/trunk/src/librt/vlist.c: progressive conversion of libbu xdr routines over to posix.1 byteorder functions. note an abuse of vls in here, being used as a byte buffer. |
| 04:39.44 | CIA-77 | BRL-CAD: 03brlcad * r43432 10/brlcad/trunk/src/librt/db_scan.c: progressive conversion of libbu xdr routines over to posix.1 byteorder functions. simple conversion when getting (net -> host) values. |
| 04:42.43 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 04:43.32 | CIA-77 | BRL-CAD: 03brlcad * r43433 10/brlcad/trunk/src/librt/primitives/ (13 files in 13 dirs): call flip_fastf_float() instead of rt_fastf_float() so we can deprecate the old rt api routine. include private header as needed. |
| 04:50.46 | CIA-77 | BRL-CAD: 03brlcad * r43434 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: convert from bu xdr routines to ntohl()/htonl() |
| 04:53.17 | CIA-77 | BRL-CAD: 03brlcad * r43435 10/brlcad/trunk/src/librt/primitives/arbn/arbn.c: convert from bu xdr routines to ntohl()/htonl() |
| 04:56.09 | CIA-77 | BRL-CAD: 03brlcad * r43436 10/brlcad/trunk/src/librt/primitives/ (dsp/dsp.c pipe/pipe.c pnts/pnts.c): more conversion from xdr routines to ntohl()/htonl() |
| 04:57.09 | CIA-77 | BRL-CAD: 03brlcad * r43437 10/brlcad/trunk/src/librt/primitives/ars/ars.c: more conversion from xdr routines to ntohl()/htonl() |
| 04:59.27 | CIA-77 | BRL-CAD: 03brlcad * r43438 10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: more conversion from xdr routines to ntohl()/htonl() being careful to increment the buffer as char pointers, not as uint32_t pointers. |
| 05:02.45 | CIA-77 | BRL-CAD: 03brlcad * r43439 10/brlcad/trunk/src/librt/primitives/bot/bot.c: |
| 05:02.45 | CIA-77 | BRL-CAD: big deprecation conversion from xdr routines to posix.1 byteorder functions. |
| 05:02.45 | CIA-77 | BRL-CAD: taking the address of element zero isn't strictly necessary but does make the |
| 05:02.45 | CIA-77 | BRL-CAD: code more self-consistent given the slew of face and normal arrays that do |
| 05:02.45 | CIA-77 | BRL-CAD: require element indexing. |
| 05:05.48 | *** join/#brlcad Stattrav (~Stattrav@117.192.140.118) | |
| 05:05.49 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:53.22 | CIA-77 | BRL-CAD: 03brlcad * r43440 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: |
| 05:53.22 | CIA-77 | BRL-CAD: by far the most complex to date, deprecation conversion away from using xdr |
| 05:53.22 | CIA-77 | BRL-CAD: routines to using posix.1 ntohl/htonl and friends. take care to increment as |
| 05:53.22 | CIA-77 | BRL-CAD: char pointers and not long pointers. nmg apparently requires a LOT of |
| 05:53.22 | CIA-77 | BRL-CAD: conversions... |
| 05:59.22 | *** join/#brlcad Stattrav (~Stattrav@122.172.31.214) | |
| 05:59.22 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:03.18 | CIA-77 | BRL-CAD: 03brlcad * r43441 10/brlcad/trunk/src/librt/primitives/sketch/sketch.c: update the last of the xdr to posix.1 byteorder function conversions. increment using our SIZEOF constants instead of hard-coding sizes too. |
| 06:19.39 | CIA-77 | BRL-CAD: 03brlcad * r43442 10/brlcad/trunk/src/librt/primitives/tgc/tgc.c: |
| 06:19.39 | CIA-77 | BRL-CAD: need librt_private.h for private flip func, also change call from rt_reldiff() |
| 06:19.39 | CIA-77 | BRL-CAD: to a NEAR_EQUAL() due to deprecation. benchmark validation required but the use |
| 06:19.39 | CIA-77 | BRL-CAD: here seems to be a fairly safe since we're considerably tightening the test |
| 06:19.39 | CIA-77 | BRL-CAD: whether the vectors reduces the ellipse equation down to quadratic form. might |
| 06:19.40 | CIA-77 | BRL-CAD: affect worst case performance but should provide the same results. |
| 06:20.39 | CIA-77 | BRL-CAD: 03brlcad * r43443 10/brlcad/trunk/src/librt/primitives/tor/tor.c: torus also needs the private header and makes a call to the deprecated rt_fdiff() function. this becomes a simple loose tolerance comparison for equality. |
| 06:25.26 | CIA-77 | BRL-CAD: 03brlcad * r43444 10/brlcad/trunk/include/db.h: formally deprecate the flip functions as API: rt_fastf_float(), rt_mat_dbmat(), and rt_dbmat_mat(). |
| 06:27.10 | CIA-77 | BRL-CAD: 03brlcad * r43445 10/brlcad/trunk/include/rtfunc.h: a callback for requesting an objects 'class' was never implemented. formally mark deprecation in header with compiler hints so warnings are issued on used. |
| 06:27.59 | *** join/#brlcad dli (~dli@dsl-67-204-45-87.acanac.net) | |
| 06:37.15 | *** join/#brlcad Stattrav (~Stattrav@117.192.239.174) | |
| 06:37.15 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:47.41 | *** join/#brlcad Stattrav (~Stattrav@117.192.231.70) | |
| 07:47.41 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:16.26 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 11:35.44 | *** join/#brlcad mafm_ (~mafm@242.Red-81-32-97.dynamicIP.rima-tde.net) | |
| 12:36.38 | *** join/#brlcad Elrohir (~kvirc@p5B14B620.dip.t-dialin.net) | |
| 14:25.26 | *** join/#brlcad mafm (~mafm@242.Red-81-32-97.dynamicIP.rima-tde.net) | |
| 14:40.40 | CIA-77 | BRL-CAD: 03bob1961 * r43446 10/brlcad/trunk/src/tclscripts/lib/TkTable.tcl: Added cadwidgets::TkTable::handleEnter and -entercommand |
| 14:44.20 | *** join/#brlcad Stattrav (~Stattrav@117.202.23.211) | |
| 14:44.20 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:56.45 | CIA-77 | BRL-CAD: 03erikgreenwald * r43447 10/brlcad/trunk/ (include/bio.h src/librt/primitives/pnts/pnts.c): include headers for hton[ls]/ntoh[ls] family |
| 19:04.09 | CIA-77 | BRL-CAD: 03erikgreenwald * r43448 10/brlcad/trunk/include/bio.h: winsock.h gets included via the windows.h megaheader, don't need to explicitly #include |
| 19:11.28 | CIA-77 | BRL-CAD: 03erikgreenwald * r43449 10/brlcad/trunk/misc/win32-msvc8/libged/libged.vcproj: add fb2pix.c, pix2fb.c and libfb.lib |
| 19:18.49 | CIA-77 | BRL-CAD: 03erikgreenwald * r43450 10/brlcad/trunk/misc/win32-msvc8/ (brlcad/brlcad.sln libtie/): libtie no longer exists, it's now part of librt |
| 19:24.08 | CIA-77 | BRL-CAD: 03erikgreenwald * r43451 10/brlcad/trunk/misc/win32-msvc8/Makefile.am: automake should probably know that libtie.vcproj isn't around, too... |
| 19:28.17 | *** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net) | |
| 19:29.00 | CIA-77 | BRL-CAD: 03erikgreenwald * r43452 10/brlcad/trunk/misc/win32-msvc8/librt/librt.vcproj: Add winsock library for htonl/ntohl/etc. Add tie/btg files. |
| 19:41.39 | *** join/#brlcad dli (~dli@dsl-67-204-45-87.acanac.net) | |
| 20:20.31 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 20:34.14 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 22:55.21 | CIA-77 | BRL-CAD: 03erikgreenwald * r43453 10/isst/trunk/cmake-modules/FindBRLCAD.cmake: libtie is no longer part of BRL-CAD |
| 23:37.43 | CIA-77 | BRL-CAD: 03r_weiss * r43454 10/brlcad/trunk/src/libbn/bntester.c: Updates to bntester.c for testing functions bn_isect_line3_line3 and bn_isect_lseg3_lseg3. |
| 02:37.00 | tofu_ | hmmm |
| 02:37.12 | tofu_ | jansson is a pretty nice C lib |
| 02:38.21 | brlcad | that might actually work as a table data container for nirt/gqa/rtcheck sortable formattable tabular output |
| 02:43.44 | brlcad | mm, and there's an even simpler boost templatized c++ header version too .. hmm |
| 05:15.04 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 06:44.30 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:27.36 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:53.52 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:36.16 | *** join/#brlcad Stattrav (~Stattrav@122.172.159.245) | |
| 08:36.16 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:05.19 | *** join/#brlcad mafm (~mafm@119.Red-88-15-70.dynamicIP.rima-tde.net) | |
| 10:24.10 | *** join/#brlcad mafm_ (~mafm@119.Red-88-15-70.dynamicIP.rima-tde.net) | |
| 10:42.32 | *** join/#brlcad dli (~dli@dsl-67-204-45-87.acanac.net) | |
| 10:56.59 | *** join/#brlcad roodolph (4dec0ed6@gateway/web/freenode/ip.77.236.14.214) | |
| 10:57.57 | roodolph | is anybady try to compile Brl-CAD under Windows? |
| 10:58.23 | roodolph | is it possible? |
| 11:10.14 | dli | roodolph, yes, what have you tried? |
| 11:11.16 | roodolph | i try to compile brl cad source on dev c++ |
| 11:11.34 | roodolph | but it doesnt work |
| 11:13.16 | roodolph | there was working many hours and nothing, just working, few days , nothig |
| 11:13.36 | roodolph | i dont know whats wrong |
| 11:13.49 | roodolph | what i have to do first |
| 11:14.16 | roodolph | to compile brlcad from source |
| 11:14.20 | dli | roodolph, have you tried cygwin/mingw, as doc says |
| 11:14.34 | roodolph | no |
| 11:16.23 | roodolph | so i have to run under linux for example |
| 11:16.30 | dli | roodolph, http://sourceforge.net/projects/brlcad/forums/forum/362511/topic/1681738?message=4180493 |
| 11:18.06 | dli | roodolph, cygwin/mingw are under windows |
| 11:23.20 | roodolph | thanks a lot |
| 11:23.59 | roodolph | i m instaling cygwin |
| 11:25.09 | *** join/#brlcad tofu_ (~sean@BZ.BZFLAG.BZ) | |
| 11:26.08 | dli | roodolph, if you want it look more native, mingw might be the way. |
| 11:28.34 | roodolph | hello |
| 11:30.33 | *** join/#brlcad roodolph (4dec0ed6@gateway/web/freenode/ip.77.236.14.214) | |
| 11:31.16 | dli | roodolph, please stay in channel and don't PM |
| 11:31.47 | roodolph | ok |
| 11:32.36 | roodolph | so cygwin is the best way to compile brl cad on windows |
| 11:33.44 | roodolph | I run this program but i dont know what next i have to do |
| 11:34.42 | roodolph | i write mingw but program says mingw : command not found |
| 11:36.07 | dli | roodolph, http://www.mingw.org |
| 11:39.17 | roodolph | first i have to instal mingw on cygwin? |
| 11:39.40 | roodolph | or it's already there? |
| 11:41.05 | dli | roodolph, if you haven't done, you need to install them |
| 11:45.32 | roodolph | but the idea is to compile brlcad source to get executable file (with .exe extension) for windows |
| 11:46.22 | roodolph | is it posssible wohever? |
| 11:47.47 | roodolph | probably Visual Basic is neccecery, but im not sure |
| 11:52.44 | roodolph | thanks a lot for all |
| 11:53.06 | roodolph | i try done it under cygwin |
| 11:53.21 | roodolph | i will see what happend |
| 11:58.27 | roodolph | main problem in this moment ; how can i move files from windows to emulated linux |
| 12:01.00 | dli | roodolph, find the installation folder |
| 12:01.41 | dli | roodolph, cgywin/mingw are within the File system windows |
| 12:01.42 | roodolph | thx i find it, C:\cygwin\home\Konrad |
| 12:02.22 | dli | roodolph, you can mv files around, in cygwin or in windows |
| 15:21.41 | CIA-77 | BRL-CAD: 03erikgreenwald * r43455 10/geomcore/trunk/tests/libNet/netMsgSerialTest.cxx: verify msg02 is not null before calling a method on it |
| 15:22.23 | CIA-77 | BRL-CAD: 03erikgreenwald * r43456 10/geomcore/trunk/ (4 files in 2 dirs): wrap bu_vlb instead of re-implementing |
| 15:27.46 | CIA-77 | BRL-CAD: 03erikgreenwald * r43457 10/geomcore/trunk/ (5 files in 4 dirs): eliminate redundant method |
| 16:00.53 | CIA-77 | BRL-CAD: 03erikgreenwald * r43458 10/geomcore/trunk/ (include/DataStreamUtils.h src/utility/DataStreamUtils.cxx): simplify (and comment out) printByteArray |
| 16:01.27 | CIA-77 | BRL-CAD: 03erikgreenwald * r43459 10/geomcore/trunk/ (include/ByteArray.h src/utility/ByteArray.cxx): remove the at method |
| 18:30.19 | CIA-77 | BRL-CAD: 03erikgreenwald * r43460 10/geomcore/trunk/tests/GS/CMakeLists.txt: need tcl includes for BRL-CAD includes |
| 18:32.34 | CIA-77 | BRL-CAD: 03erikgreenwald * r43461 10/geomcore/trunk/ (10 files in 3 dirs): eliminate DataStreamUtils |
| 18:36.03 | CIA-77 | BRL-CAD: 03erikgreenwald * r43462 10/geomcore/trunk/src/utility/StringUtils.h: remove unused header |
| 20:15.29 | CIA-77 | BRL-CAD: 03erikgreenwald * r43463 10/geomcore/trunk/src/libNet/netMsg/NetMsg.cxx: copy datastream into bytearray |
| 20:17.02 | CIA-77 | BRL-CAD: 03erikgreenwald * r43464 10/geomcore/trunk/ (include/ByteArray.h src/utility/ByteArray.cxx): add assign method |
| 20:18.52 | CIA-77 | BRL-CAD: 03erikgreenwald * r43465 10/geomcore/trunk/ (include/DataStream.h src/utility/DataStream.cxx): add size, fix up |
| 20:31.10 | CIA-77 | BRL-CAD: 03erikgreenwald * r43466 10/geomcore/trunk/src/libNet/netMsg/NetMsg.cxx: fix reversed logic O.o |
| 20:47.53 | CIA-77 | BRL-CAD: 03erikgreenwald * r43467 10/geomcore/trunk/tests/ (7 files in 7 dirs): name consistency |
| 20:57.21 | CIA-77 | BRL-CAD: 03erikgreenwald * r43468 10/geomcore/trunk/src/libNet/netMsg/NetMsg.cxx: set reUUID to NULL in deserialize. Use hasReUUID instead of testing reUUIDsvn diff NetMsg.cxx=NULL in toString. |
| 21:14.55 | CIA-77 | BRL-CAD: 03erikgreenwald * r43469 10/geomcore/trunk/tests/libNet/netMsgSerialTest.cxx: weee, colors |
| 21:16.28 | CIA-77 | BRL-CAD: 03erikgreenwald * r43470 10/geomcore/trunk/tests/libNet/netMsgSerialTest.cxx: conditionalize some verbosity shtuffz |
| 21:18.28 | CIA-77 | BRL-CAD: 03erikgreenwald * r43471 10/geomcore/trunk/tests/libNet/netMsgSerialTest.cxx: argv setting of verbose flag |
| 21:20.43 | CIA-77 | BRL-CAD: 03erikgreenwald * r43472 10/geomcore/trunk/src/libNet/netMsg/GeometryManifestMsg.cxx: shortcircuit the string comparisons; if the lists are different lengths, then they're not equal. |
| 21:21.08 | CIA-77 | BRL-CAD: 03erikgreenwald * r43473 10/geomcore/trunk/src/libNet/netMsg/NetMsg.cxx: woops, a little more reversed logic |
| 21:26.34 | CIA-77 | BRL-CAD: 03erikgreenwald * r43474 10/geomcore/trunk/src/libNet/netMsg/GenericTwoBytesMsg.cxx: fix deserialize bug |
| 21:31.31 | CIA-77 | BRL-CAD: 03erikgreenwald * r43475 10/geomcore/trunk/src/libNet/netMsg/SessionInfoMsg.cxx: use equals method instead of (nonexistant) overloaded ==/svn diff SessionInfoMsg.cxx= |
| 21:59.00 | CIA-77 | BRL-CAD: 03erikgreenwald * r43476 10/geomcore/trunk/src/libNet/netMsg/GenericMultiByteMsg.cxx: Use memcpy and big appends instead of iterating (and making method calls) for each byte. Rewrite the constructor so it deserializes, instead of serializes (???). |
| 22:02.02 | CIA-77 | BRL-CAD: 03erikgreenwald * r43477 10/geomcore/trunk/src/libNet/netMsg/GeometryManifestMsg.cxx: cast the char* to uint32_t* for the ntohl. Huzzah, gNetMsgSerialTest is 100% again! |
| 03:20.34 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 05:08.05 | *** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net) | |
| 05:40.52 | *** join/#brlcad Stattrav (~Stattrav@117.192.227.117) | |
| 05:40.52 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:08.20 | *** join/#brlcad Stattrav (~Stattrav@122.172.159.245) | |
| 06:08.20 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:03.08 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 10:15.14 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 10:15.14 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:41.36 | *** join/#brlcad mafm_ (~mafm@137.Red-81-32-104.dynamicIP.rima-tde.net) | |
| 11:13.13 | *** join/#brlcad Stattrav (~Stattrav@122.172.159.245) | |
| 11:13.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:04.29 | *** join/#brlcad mafm (~mafm@137.Red-81-32-104.dynamicIP.rima-tde.net) | |
| 18:11.33 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 21:17.48 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) | |
| 23:57.36 | *** join/#brlcad Yoshi47 (~jan@d72-39-60-53.home1.cgocable.net) | |
| 01:23.53 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 04:25.36 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 08:43.52 | *** join/#brlcad Pline (~Aashim@61.153.16.162) | |
| 08:43.52 | *** part/#brlcad Pline (~Aashim@61.153.16.162) | |
| 08:45.52 | *** join/#brlcad Pline (~Aashim@61.153.16.162) | |
| 08:45.52 | *** part/#brlcad Pline (~Aashim@61.153.16.162) | |
| 10:28.20 | *** join/#brlcad mafm (~mafm@193.153.52.96) | |
| 12:30.25 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 14:36.13 | *** join/#brlcad Stattrav (~Stattrav@117.192.153.39) | |
| 14:36.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:58.06 | *** join/#brlcad mafm (~mafm@193.153.52.96) | |
| 16:35.05 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 22:05.34 | *** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) | |
| 23:57.11 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 01:30.01 | *** join/#brlcad Elrohir (~kvirc@p5B14BB8B.dip.t-dialin.net) | |
| 01:47.35 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) | |
| 02:50.55 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 04:51.06 | CIA-77 | BRL-CAD: 03brlcad * r43478 10/brlcad/trunk/src/libfb/if_remote.c: convert libfb's remote framebuffer from using libbu's xdr routines to using the posix.1 byteorder functions, using hton*/ntoh* |
| 05:10.56 | CIA-77 | BRL-CAD: 03brlcad * r43479 10/brlcad/trunk/src/conv/ (asc/asc2g.c asc/g2asc.c poly-bot.c stl/g-stl.c stl/stl-g.c): convert converters using the libbu xdr routines to using the posix.1 byteorder functions, using hton*/ntoh* |
| 05:20.42 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:21.00 | CIA-77 | BRL-CAD: 03brlcad * r43480 10/brlcad/trunk/src/rt/viewray.c: call NEAR_EQUAL() instead of rt_fdiff() |
| 05:21.35 | *** join/#brlcad Stattrav_ (~Stattrav@122.172.159.245) | |
| 05:24.06 | CIA-77 | BRL-CAD: 03brlcad * r43481 10/brlcad/trunk/src/librtserver/rtserver.c: more xdr to posix.1 byteorder function conversions, bu_plong to htonl |
| 05:32.04 | CIA-77 | BRL-CAD: 03brlcad * r43482 10/brlcad/trunk/src/ (gtools/g_transfer.c remrt/rtsrv.c): since ext_buf buffers are now uint8_t*'s we need to cast them to char*'s for libpkg (until libpkg is upgraded). |
| 05:49.32 | CIA-77 | BRL-CAD: 03brlcad * r43483 10/brlcad/trunk/src/libged/bot_dump.c: convert from xdr bu_plong() to byteorder htonl() |
| 05:51.29 | CIA-77 | BRL-CAD: 03brlcad * r43484 10/brlcad/trunk/include/raytrace.h: |
| 05:51.29 | CIA-77 | BRL-CAD: now that all usages should be weeded out, formally deprecate rt_fdiff() and |
| 05:51.29 | CIA-77 | BRL-CAD: rt_reldiff() in the header. not 100% equivalent, so use with caution, but |
| 05:51.29 | CIA-77 | BRL-CAD: recommend most conversions change to NEAR_EQUAL(a,b,0.001) and EQUAL(a,b) |
| 05:51.29 | CIA-77 | BRL-CAD: respectively. |
| 05:55.23 | CIA-77 | BRL-CAD: 03brlcad * r43485 10/brlcad/trunk/ (include/bu.h src/librt/db5_io.c): |
| 05:55.24 | CIA-77 | BRL-CAD: formally deprecate the old eXternal Data Representation (XDR) functions via API |
| 05:55.24 | CIA-77 | BRL-CAD: markers. all of the bu_p(long|short|etc) and bu_g(long|short|etc) functions |
| 05:55.24 | CIA-77 | BRL-CAD: have comparable byteorder functions provided standard via posix.1 as hton(l|s) |
| 05:55.24 | CIA-77 | BRL-CAD: and ntoh(l|s). the one exception is support for converting 64-bit long long |
| 05:55.24 | CIA-77 | BRL-CAD: types, so use the recently added configure.ac tests and define htonll() and |
| 05:55.25 | CIA-77 | BRL-CAD: ntohll() respectively as macros supporting big and little endian platforms. |
| 06:04.19 | CIA-77 | BRL-CAD: 03brlcad * r43486 10/brlcad/trunk/src/librt/primitives/bspline/bspline.cpp: convert from xdr to standard byteorder functions casting accordingly. |
| 06:05.26 | CIA-77 | BRL-CAD: 03brlcad * r43487 10/brlcad/trunk/doc/deprecation.txt: minimally impacting change, renaming V2APPROXEQUAL() to V2NEAR_EQUAL() in order to match the other *NEAR_EQUAL() macros. |
| 06:10.49 | CIA-77 | BRL-CAD: 03brlcad * r43488 10/brlcad/trunk/ (include/vmath.h src/proc-db/surfaceintersect.cpp): minimally impacting API change, rename V2APPROXEQUAL to V2NEAR_EQUAL so the api is more self-consistent. |
| 10:12.29 | starseeker | brlcad: you're referring to the C JSON library jansson? |
| 10:16.18 | dloman-a1k | Mernin all |
| 10:16.49 | starseeker | dloman-a1k: morning! |
| 10:20.16 | dloman | ugh, lots to read, heh |
| 10:20.33 | starseeker | hehe |
| 10:20.47 | dloman | so, in my interwebz wandering, i found a QT wrapper for the svn libs :) |
| 10:20.56 | dloman | bookmarked it, didnt have time to look at it. |
| 10:21.18 | dloman | just thought it was funny since erik is mostly done with the ripout |
| 10:22.55 | dloman | starseeker: what version of cmake are you using? |
| 10:23.04 | starseeker | 2.8.3 |
| 10:23.11 | dloman | just got a 'new' used laptop and am re-installing *everything* |
| 10:23.18 | starseeker | I think 2.8.4 is out |
| 10:23.43 | dloman | kk, so 2.8.2 won't cause the world to end then. |
| 10:24.03 | starseeker | *probably* not, but there do tend to be legitimate bug fixes/improvements in each release |
| 10:24.10 | starseeker | particularly with respect to VS2010 |
| 10:24.12 | dloman | right on |
| 10:24.33 | starseeker | If 2.8.2 is the easy install, go for it |
| 10:24.41 | dloman | exactly :) |
| 10:24.48 | dloman | one click == my kinda install |
| 10:24.54 | starseeker | the only thing I know that has issues with 2.8.2 is the Windows visual studio stuff |
| 10:25.16 | starseeker | there may be others though - I'd have to check |
| 10:25.54 | dloman | that fine by me. I dont have any plans on doing anything with VS2xxx |
| 10:26.01 | dloman | in the immediate future that is.. |
| 10:26.09 | dloman | eventually, I'll have to deal with it |
| 10:26.10 | starseeker | If possible, I tend to prefer fixing CMake as opposed to ugly workarounds in our logic, and we do do some fairly funky stuff in a few cases, so let me know if you see any issues |
| 10:26.22 | dloman | kk |
| 10:26.33 | starseeker | CMake is pretty easy to install if it comes to that |
| 10:26.35 | dloman | verizon dsl sucks, so the checkout will take time :/ |
| 10:26.41 | starseeker | nods |
| 10:27.17 | starseeker | dloman: of course, if you're just doing geomcore and not all of BRL-CAD that should be simpler |
| 10:27.42 | dloman | I am soooooo going with xfinity or fios when they hit my area... |
| 10:27.53 | starseeker | mmmm, fiber |
| 10:27.53 | dloman | I think I will get and try cmake on both of those. |
| 10:28.18 | dloman | I have resigned myself to the fact that a bulk of today will be spent downloading/config-ing/t-shooting |
| 10:28.24 | starseeker | heh |
| 10:28.35 | starseeker | has a week of email to read |
| 10:28.49 | dloman | you take last week off as well? |
| 10:28.54 | starseeker | honeymoon |
| 10:29.23 | starseeker | that's why I'm awake right now |
| 10:29.33 | dloman | right on! |
| 10:29.35 | dloman | have fun? |
| 10:29.36 | starseeker | time zones are still messed up |
| 10:29.47 | dloman | oh, you are currently ON your honeymoon? |
| 10:29.56 | starseeker | it was awesome, aside from me being an idiot and losing my ticket for one event |
| 10:30.01 | starseeker | nope, got back last night |
| 10:30.06 | dloman | nice. |
| 10:30.12 | dloman | mind if I ask where u went? |
| 10:30.19 | starseeker | got yelled at by the cats... oh boy |
| 10:30.22 | starseeker | Spain |
| 10:30.32 | dloman | sweet! |
| 10:30.41 | dloman | fun then? |
| 10:30.45 | starseeker | yep |
| 10:30.49 | starseeker | did a lot of tours |
| 10:30.53 | dloman | nice :) |
| 10:31.25 | starseeker | getting put back together - will have to hit the store on the way home tonight |
| 10:32.26 | dloman | watch the weather. somehow a big nasty t-storm snuck up on me/PA/MD without me noticing it on the weather map :) |
| 10:32.30 | starseeker | dloman: was this the binding you found? |
| 10:32.32 | starseeker | http://kdesvn.alwins-world.de/ |
| 10:32.39 | starseeker | ow |
| 10:33.12 | dloman | no, i don';t think that was it. |
| 10:33.38 | dloman | let me dig really quick |
| 10:34.50 | dloman | libsvnqt4 |
| 10:34.54 | dloman | me thinks it was |
| 10:35.06 | dloman | like i said. I saw it, bookmarked it... and that's it. |
| 10:35.08 | starseeker | that sounds like debian packaging of a subset of kdesvn |
| 10:35.11 | dloman | didn't take a look. |
| 10:36.38 | starseeker | we'll probably be talking directly to the C api of the various subversion sub-libraries |
| 10:37.26 | starseeker | I'm pondering whether the best approach would be to actually "port" both the svn fs-fs backend and the checkout logic itself to work inside of a .g instead of files |
| 10:38.16 | starseeker | that's probably one *bleeping* lot of work, particularly the checkout (which I expect makes lots of assumptions about files on a filesystem being the intended checkout output) |
| 10:38.50 | dloman | might be the best, but def not the fastest. |
| 10:39.07 | starseeker | doesn't matter too much right now, since most of the work needed for the break it down to regions and make files approach is still needed for other approaches |
| 10:39.16 | dloman | right on. |
| 10:39.26 | dloman | I plan on diving headlong into that very aspect asap |
| 10:39.48 | starseeker | dloman: I need to get search to behave as proper db functions first |
| 10:40.07 | starseeker | that'll be the best/only(?) way to get a list of assemblies (combinations above regions) |
| 10:40.08 | dloman | first... meaning before what? |
| 10:40.37 | starseeker | once I have that list, and a list of regions, I can keep each into its own file |
| 10:40.39 | dloman | def not the only. a tree/dag walk would be one. |
| 10:40.58 | starseeker | shakes head - we need to write out the assemblies as their own files |
| 10:41.09 | dloman | ya |
| 10:41.20 | starseeker | they aren't below regions (in a proper .g anyway) and won't be kept by a "save the regions" approach |
| 10:41.40 | starseeker | we need to identify the subset of combs that aren't below any regions and save those |
| 10:41.42 | dloman | okay, i think I am missing something then. |
| 10:41.48 | starseeker | hmm? |
| 10:42.18 | dloman | if we do a depth first search, everything in the path leading up to the region *must* be a combination..... yes? |
| 10:42.27 | dloman | s/search/walk/ |
| 10:42.51 | starseeker | oh, you mean take the tops list and work with that as the starting point? |
| 10:42.56 | dloman | ya |
| 10:43.14 | starseeker | ponders... |
| 10:43.19 | dloman | since this is sometihng that will only be run once per file, speed shouldn't be a major concern |
| 10:44.17 | starseeker | yeah, that would probably work, but the search approach is still worthwhile because it can also be used to spot problems |
| 10:44.31 | starseeker | (regions under regions, non-union operations in assemblies) |
| 10:44.43 | dloman | sure. Im thinking timeline wise though, since end of march is our target |
| 10:45.15 | starseeker | dloman: I actually got search working as a C function just before I left, but I didn't do it "right" from an API standpoint |
| 10:45.45 | starseeker | and since we're supposed to be "done" at end of march, I want search's ability to identify near-arbitrary subsets of things |
| 10:45.56 | starseeker | that power may be necessary for robustness |
| 10:46.20 | dloman | oh it will :) |
| 10:46.37 | dloman | but robustness isn't on the list of things needed for the deliverable :P |
| 10:46.41 | dloman | (that was a joke btw) |
| 10:46.45 | starseeker | hehe |
| 10:47.14 | dloman | go go gadget timesheet :/ |
| 10:48.24 | starseeker | dloman: one thing that would help quite a lot is if you and brlcad could summarize the "finalize" approach you two cooked up |
| 10:48.44 | dloman | heh, well, we have to sit down and powwow again. |
| 10:48.45 | starseeker | the functionality needed for that is essentially the TODO lsit |
| 10:48.50 | starseeker | s/lsit/list/ |
| 10:49.16 | dloman | what I have the notes for and what was 'understood' by both parties is not in sync. |
| 10:49.31 | starseeker | nods |
| 10:49.33 | dloman | i think maybe brlcad ``Erik you and i should all sit in |
| 10:49.51 | dloman | perhaps later this week if our schedules align |
| 10:51.05 | starseeker | sure - I'd mainly be listening, because it sounds like most of the major problems were conceptually resolved - what we need now is a "do this to librt to support namespaces, hook this up to svn, do this to combine invidual .g region files into an assembly .g object to satisfy a geomclient request, etc |
| 10:52.20 | starseeker | we also need to decide what has to be in GE (if anything) to achieve basic functionality |
| 10:52.23 | dloman | exactly. task breakdown! |
| 10:52.55 | dloman | heh, I don't know why I ever said yes to the gs project... it was waaaay over my head for a newbie :/ |
| 10:53.05 | starseeker | hehe |
| 10:53.10 | starseeker | trial by fire |
| 10:53.40 | starseeker | probably would have been less tramatizing to do it the way I did - spend a month making tires :-P |
| 10:53.54 | dloman | nice |
| 10:54.08 | dloman | i still want to make the proc-db for making houses. |
| 10:54.14 | dloman | that'd be fuuuun |
| 10:54.53 | dloman | curses at the vpn |
| 10:55.23 | starseeker | puts stuff together and heads out... the rumble you will hear soon will be me being buried under email |
| 11:16.56 | *** join/#brlcad Stattrav (~Stattrav@122.167.254.137) | |
| 11:16.56 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:34.16 | dloman | so... offsite is posponed? |
| 11:55.13 | *** join/#brlcad Stattrav (~Stattrav@122.167.254.137) | |
| 11:55.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:12.26 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:12.46 | CIA-77 | BRL-CAD: 03davidloman * r43489 10/jbrlcad/trunk/: Modify svn:ignore to ignore .settings directory (generated by eclipse) |
| 12:14.59 | CIA-77 | BRL-CAD: 03davidloman * r43490 10/geomcore/trunk/src/interfaces/java/: Modify svn:ignore to ignore .classpath and .project files (generated by eclipse) |
| 12:24.15 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:25.09 | dloman | Xi is the x lib's input lib, right? |
| 12:29.05 | *** join/#brlcad Stattrav (~Stattrav@122.167.254.137) | |
| 12:29.05 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:42.36 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 12:54.06 | dloman | Noob question: brlcad's config can't seem to find libXi, but i know its installed and where its at. How do i tell brlcad's config where it is? |
| 13:12.35 | starseeker | --with-x and the X11 location may work |
| 13:13.01 | starseeker | also, if you just installed libXi-dev you may need to clear cache and reconfigure |
| 13:15.50 | dloman | awesome, tanks! |
| 13:19.47 | starseeker | Does anyone remember if gecode (http://www.gecode.org/) was discussed back when the parametric constraint Google Summer of Code project was being worked? |
| 13:21.11 | starseeker | also, http://www.g12.cs.mu.oz.au/minizinc/ |
| 13:23.42 | dloman | is there a standard lex that we should use for brlcad? |
| 13:24.11 | starseeker | uh... not really, but I'd be very surprised if you've got anything except flex |
| 13:25.43 | dloman | thanks, you answered my quetion indirectly =D |
| 13:39.40 | starseeker | confesses he is not up on the constraint stuff, but geocode and friends sound at first glance like they are quite relevant and interesting |
| 13:50.06 | CIA-77 | BRL-CAD: 03starseeker * r43491 10/brlcad/branches/cmake/ (114 files in 60 dirs): MFC r43490 |
| 13:54.32 | dloman | starseeker: the TERMLIB cmake flag.... is it looking for libterm? |
| 13:55.26 | starseeker | dloman: not just libterm - it's supposed to look for a whole bunch of possible suppliers for the subset of termlib we need, and if it's not found enable our local copy |
| 13:55.31 | starseeker | what's the error? |
| 13:56.00 | dloman | config is saying 'Could NOT find TERMLIB' |
| 13:56.10 | starseeker | autotools? |
| 13:56.12 | dloman | just trying to figure out what i should install. |
| 13:56.14 | dloman | cmake |
| 13:56.28 | starseeker | that's surprising |
| 13:56.38 | starseeker | if it's not found it should just fall back on src/other |
| 13:57.02 | dloman | its not erroring out, im just trying to fill out as many libs as possible. |
| 13:57.05 | starseeker | just install the ncurses dev package if you want something on the system |
| 13:57.08 | dloman | this is a brandy new install of ubuntu |
| 14:05.49 | CIA-77 | BRL-CAD: 03starseeker * r43492 10/brlcad/branches/cmake/src/tab/CMakeLists.txt: Clear out txyz-pl from src/tab CMakeLists.txt file |
| 14:30.22 | CIA-77 | BRL-CAD: 03starseeker * r43493 10/brlcad/branches/cmake/misc/enigma/CMakeLists.txt: enigma is not, properly speaking, a BRL-CAD program - don't use BRLCAD_ADDEXEC macro (we don't want to hit it with the strict flags, same as src/other |
| 14:33.38 | *** join/#brlcad Stattrav (~Stattrav@122.167.254.137) | |
| 14:33.48 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:37.40 | CIA-77 | BRL-CAD: 03starseeker * r43494 10/brlcad/branches/cmake/src/tclscripts/ (archer/CMakeLists.txt lib/CMakeLists.txt): cursor.tcl moved |
| 14:48.45 | starseeker | hmm... http://www.cs.washington.edu/research/constraints/cassowary/ |
| 14:49.51 | starseeker | needs this http://www.fim.uni-passau.de/fileadmin/files/lehrstuhl/brandenburg/projekte/gtl/GTL-1.2.4-lgpl.tar.gz |
| 14:51.27 | starseeker | geocode sounds more modern and supported, if the domains overlap properly |
| 15:53.04 | CIA-77 | BRL-CAD: 03starseeker * r43495 10/brlcad/branches/cmake/src/tab/CMakeLists.txt: Problem - the lex generated output is triggering warnings. Gonna have to go with -Wno-error until we get a flex/byacc solution in place we can rely on/tweak to generate error free code. |
| 15:56.24 | brlcad | starseeker: what were the warnings? during my cleanup a couple weeks ago, several of the lex-generated output warnings were controlled by settings in the lex/yacc files |
| 15:56.32 | brlcad | i.e., they were easily quellable |
| 15:56.40 | brlcad | welcome back too :) |
| 15:58.44 | starseeker | brlcad: thanks :-) |
| 15:58.46 | starseeker | script.c:34:5: warning: "__STDC_VERSION__" is not defined |
| 15:59.01 | starseeker | script.c:1020: warning: label ‘find_rule’ defined but not used |
| 15:59.14 | starseeker | script.c:1439: warning: comparison between signed and unsigned |
| 15:59.23 | starseeker | script.c:2138: warning: ‘yy_flex_strlen’ defined but not used |
| 16:01.21 | CIA-77 | BRL-CAD: 03starseeker * r43496 10/brlcad/trunk/src/ (canon/canonize.c librtserver/rtserver.c rt/view.c sig/fhor.c): Various quellage |
| 16:04.13 | CIA-77 | BRL-CAD: 03d_rossberg * r43497 10/brlcad/trunk/src/ (conv/CMakeLists.txt conv/stl/stl-g.c librt/CMakeLists.txt): ntohl(): missing includes and libraries for the MSVC CMake build (needs WinSock 2) |
| 16:04.21 | CIA-77 | BRL-CAD: 03starseeker * r43498 10/brlcad/branches/cmake/ (32 files in 31 dirs): There we go - strict compile flags are now the default throughout the BRL-CAD src directories, with the exception of src/other |
| 16:09.07 | brlcad | thanks, interesting diff set of warnings |
| 16:10.47 | starseeker | brlcad: do you recall if gecode was ever mentioned in the parametric constraint lib discussions? |
| 16:11.43 | dloman | starseeker: the cmake command to find x was: cmake --with-x <pathToSrc> ?? |
| 16:11.44 | brlcad | nah, I don't really recall |
| 16:11.49 | brlcad | starseeker: what's the gain? |
| 16:12.36 | starseeker | i'm thinking it might actually have a working constraint solver on top of which we would define our constraints |
| 16:12.49 | brlcad | isn't keen on bio.h having networking, that expands the scope a bit.. |
| 16:12.53 | starseeker | (i.e. it sounds kind of like what the gsoc project was trying to develop) |
| 16:13.04 | dloman | tryin to fix a linker error: cannot find -lXss (-lXft and -lXrender) |
| 16:13.42 | starseeker | um. Ubuntu might break those out into separate packages... |
| 16:14.03 | dloman | did a find and I have them... so how do I supply paths to cmake? |
| 16:14.08 | brlcad | starseeker: it's definitely related -- there are dozens of constraint solver libraries out there |
| 16:14.21 | brlcad | each with their merits and deficiencies.. |
| 16:15.15 | starseeker | brlcad: that's what I was wondering - presumably there must have been a review of those before we went for writing our own... |
| 16:16.04 | brlcad | possibly, but that would have been pre-submission |
| 16:16.05 | starseeker | dloman: it's rather disturbing they aren't being found |
| 16:16.16 | starseeker | nuts |
| 16:16.51 | starseeker | dloman: can you post the results of make VERBOSE=1 that are related to the failure? |
| 16:16.57 | dloman | starseeker: if it helps, all the libs are in /usr/lib and /usr/lib32 |
| 16:17.00 | dloman | kk, will do |
| 16:17.39 | brlcad | starseeker: it's kinda the same situation as writing a solver for nurbs surface evaluation -- "surely there was a review of existing root solvers before we went for writing our own" |
| 16:17.50 | brlcad | the answer is "yes and no" |
| 16:18.14 | brlcad | the solver is fairly tied to the data structures, same with constraints |
| 16:19.48 | starseeker | ah |
| 16:20.02 | brlcad | fwiw, much of libpc isn't the actual constraint solving but the data structures for representing a constraint, the bridge for librt to use |
| 16:20.14 | brlcad | so you could conceivably hook in any constraint solver under the hood |
| 16:20.25 | starseeker | nods - that might be interesting to look at |
| 16:20.47 | brlcad | as would determining where the current implementation is actually at |
| 16:21.05 | starseeker | was doing some reading of SICP, and their description of what a constraint system does/is good for kind of set off a light bulb |
| 16:21.06 | brlcad | for all we know, it could be done and working perfectly for our needs |
| 16:21.48 | starseeker | not that I have time to fool with it now of course, but it sounds quite interesting |
| 16:22.15 | brlcad | when I reviewed his work back during gsoc, it actually seemed to be working very well |
| 16:22.48 | brlcad | the problems he was working on were problems we were not yet faced with, solving multiple constraints simultaneously |
| 16:23.06 | brlcad | there are sample test driver programs in the tree that show it working |
| 16:23.45 | starseeker | nods. I'm just wondering how hard it would be to shake out bugs and demonstrate robustness there vs. using something like gecode under the hood for the actual solving part... |
| 16:23.57 | starseeker | but the only way to know that is to dig into it |
| 16:24.34 | brlcad | you won't know whether gecode is better or worse without writing a test driver that evaluates the current state of affairs regardless |
| 16:24.42 | starseeker | right |
| 16:25.20 | brlcad | given there are already some simple test drivers, it would be an intersting comparison |
| 16:25.30 | brlcad | useful too, it's a current year task |
| 16:25.50 | starseeker | nods - maybe I can dive in after the geometry service gets beaten into submission |
| 16:25.50 | brlcad | someone will have to investigate and evaluate before the year's up |
| 16:26.03 | brlcad | has the same deadline as the GS iirc :) |
| 16:26.12 | starseeker | O.o |
| 16:26.12 | brlcad | much smaller task, though |
| 16:26.34 | starseeker | crawls under his desk and hides... |
| 16:26.46 | starseeker | and then realizes that's a bad place to code from |
| 16:26.51 | brlcad | frack.. end of month |
| 16:26.54 | brlcad | time to release! |
| 16:27.01 | brlcad | damn short month |
| 16:27.12 | starseeker | winces |
| 16:28.02 | brlcad | gsoc org submissions opens up today too |
| 16:28.23 | brlcad | if we're going to participate, someone is going to have to get started on writing up a new task list on the wiki |
| 16:28.24 | starseeker | do you want me to do the librt search port in CMake to avoid messing with trunk? |
| 16:28.35 | brlcad | heck no :) |
| 16:28.59 | brlcad | search port? |
| 16:29.07 | brlcad | sounds rather un-cmakeing |
| 16:29.20 | starseeker | sure, but it's a nasty thing to do during a release cycle |
| 16:29.29 | starseeker | whoops, bbl |
| 16:29.55 | brlcad | just have to be more careful to not break build or functionality during commits, just talking a day or two to test and tag |
| 16:37.13 | CIA-77 | BRL-CAD: 03brlcad * r43499 10/brlcad/trunk/TODO: |
| 16:37.13 | CIA-77 | BRL-CAD: release tasks were not completed by the end of the month, so push to the next |
| 16:37.13 | CIA-77 | BRL-CAD: iteration. only remaining task that comes to mind is removing the network dep |
| 16:37.13 | CIA-77 | BRL-CAD: from bio.h (need a separate header since it's just for standard i/o) |
| 17:04.38 | CIA-77 | BRL-CAD: 03brlcad * r43500 10/brlcad/trunk/src/libged/CMakeLists.txt: add fb2pix.c and pix2fb.c |
| 17:18.41 | CIA-77 | BRL-CAD: 03jordisayol * r43501 10/brlcad/trunk/misc/debian/changelog: update debian changelog |
| 18:11.41 | CIA-77 | BRL-CAD: 03brlcad * r43502 10/brlcad/trunk/include/ (Makefile.am bin.h): |
| 18:11.41 | CIA-77 | BRL-CAD: add an initial corrollary header file similar to bio.h but for internet |
| 18:11.41 | CIA-77 | BRL-CAD: networking instead of input/output. it's similarly a 'private' self-contained |
| 18:11.41 | CIA-77 | BRL-CAD: header (so no HAVE_* defines), but should help consolidate the header |
| 18:11.41 | CIA-77 | BRL-CAD: preprocessor logic into one place. this header is effectively treated as a |
| 18:11.42 | CIA-77 | BRL-CAD: system header coming before inclusions of brl-cad public/private headers. |
| 18:14.23 | CIA-77 | BRL-CAD: 03brlcad * r43503 10/brlcad/trunk/src/librt/Makefile.am: missing the tieprivate.h header |
| 18:16.50 | CIA-77 | BRL-CAD: 03brlcad * r43504 10/brlcad/trunk/src/librtserver/rtserver.c: include headers for htonl |
| 18:20.17 | CIA-77 | BRL-CAD: 03brlcad * r43505 10/brlcad/trunk/src/librt/primitives/pnts/pnts.c: include bin.h instead of bio.h for htonl and friends |
| 18:22.32 | CIA-77 | BRL-CAD: 03brlcad * r43506 10/brlcad/trunk/include/bio.h: |
| 18:22.32 | CIA-77 | BRL-CAD: remove inclusion of arpa/inet.h from bio.h since it's not desirable to bundle |
| 18:22.32 | CIA-77 | BRL-CAD: networking routines in with the input/output routines. this is in part due to |
| 18:22.32 | CIA-77 | BRL-CAD: the implied dependency on the windows socket library on the windows platform, |
| 18:22.32 | CIA-77 | BRL-CAD: which isn't necessarily true for inclusions only needing standard i/o. the new |
| 18:22.33 | CIA-77 | BRL-CAD: bin.h internet networking header now covers networking. |
| 18:28.16 | CIA-77 | BRL-CAD: 03brlcad * r43507 10/brlcad/trunk/src/librt/db5_io.c: need bin.h instead of bio.h |
| 18:29.24 | CIA-77 | BRL-CAD: 03brlcad * r43508 10/brlcad/trunk/src/librt/db_scan.c: ditto, bio.h -> bin.h for networking |
| 18:34.20 | CIA-77 | BRL-CAD: 03brlcad * r43509 10/brlcad/trunk/src/libged/bot_dump.c: need networking and i/o functions here, so also include bin.h |
| 18:34.30 | CIA-77 | BRL-CAD: 03brlcad * r43510 10/brlcad/trunk/src/librt/ (11 files in 11 dirs): promulgation continues, switch from bio.h to bin.h where byteorder functions are being used. |
| 18:34.34 | ``Erik | the arpa inet header in bio.h was for htonl/ntohl |
| 18:35.00 | ``Erik | *readreadread* |
| 18:36.11 | ``Erik | hm, *update;compile* O.o |
| 18:36.42 | CIA-77 | BRL-CAD: 03brlcad * r43511 10/brlcad/trunk/src/conv/ (asc/asc2g.c asc/g2asc.c poly-bot.c stl/g-stl.c): and maybe the last batch of bin.h inclusions needed. |
| 18:36.51 | brlcad | I know - but that made the header pull in more than just i/o |
| 18:37.06 | brlcad | the wrapper header was needed, just made a new file |
| 18:37.19 | brlcad | one for just networking |
| 18:37.41 | brlcad | so anything that includes that file is implicitly requiring ws2_32.lib |
| 18:38.56 | brlcad | sucks that byteorder is in winsock on windows .. the bu xdr funcs provided a nice encapsulation from that perspective, but still probably better unwrapped |
| 18:40.18 | CIA-77 | BRL-CAD: 03starseeker * r43512 10/brlcad/branches/cmake/CMakeLists.txt: Try InstallRequiredSystemLibraries on Windows MSVC |
| 18:41.14 | CIA-77 | BRL-CAD: 03brlcad * r43513 10/brlcad/trunk/src/conv/stl/stl-g.c: nope, missed one |
| 18:46.58 | *** join/#brlcad Ralith (~ralith@d142-058-095-076.wireless.sfu.ca) | |
| 19:00.17 | CIA-77 | BRL-CAD: 03starseeker * r43514 10/brlcad/branches/cmake/ (36 files in 24 dirs): MFC r43513, update CMakeLists.txt files to include winsock in more places (untested) |
| 19:04.13 | starseeker | ah, homovulgaris mentioned gecode back in 2008 |
| 19:16.03 | CIA-77 | BRL-CAD: 03erikgreenwald * r43515 10/brlcad/trunk/include/bin.h: need sys/types.h for netinet/tcp.h |
| 19:21.41 | ``Erik | probably should be wrapping some #ifdef HAVE_SOME_H in there *shrug* |
| 19:24.30 | CIA-77 | BRL-CAD: 03erikgreenwald * r43516 10/brlcad/trunk/include/bin.h: #define <winsock2.h> doesn't quite work |
| 19:25.21 | brlcad | heh |
| 19:26.14 | brlcad | ``Erik: bio.h and bin.h intentionally do not have HAVE_* defines since they're not supposed to be tied to configure -- more like system header replacements |
| 19:27.10 | brlcad | they could be converted / coupled with configure feature testing, but it would change a few things |
| 19:41.18 | CIA-77 | BRL-CAD: 03davidloman * r43517 10/brlcad/branches/cmake/: Modify svn:ignore to ignore .classpath and .project files (generated by eclipse) |
| 19:59.10 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 19:59.10 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202) | |
| 20:29.05 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 20:53.07 | CIA-77 | BRL-CAD: 03brlcad * r43518 10/brlcad/trunk/src/mged/attach.c: include bin.h instead of including winsock2.h directly |
| 20:55.25 | CIA-77 | BRL-CAD: 03brlcad * r43519 10/brlcad/trunk/configure.ac: |
| 20:55.25 | CIA-77 | BRL-CAD: there's no reason to leave out the gnu extensions other than to try and avoid |
| 20:55.25 | CIA-77 | BRL-CAD: non-standard functions. in practice, however, c99 compliance means we also |
| 20:55.25 | CIA-77 | BRL-CAD: don't get the posix functions, which is somewhat problematic. change the |
| 20:55.25 | CIA-77 | BRL-CAD: compliance from std99 to gnu99. |
| 21:13.11 | CIA-77 | BRL-CAD: 03brlcad * r43520 10/brlcad/trunk/src/util/dunncomm.c: wrong comment |
| 21:21.30 | CIA-77 | BRL-CAD: 03brlcad * r43521 10/brlcad/trunk/src/libfb/if_ogl.c: no longer need the __BSD_VISIBLE/__USE_XOPEN/__USE_BSD hacking to get the extension decls with configure using gnu99. |
| 21:35.36 | CIA-77 | BRL-CAD: 03brlcad * r43522 10/brlcad/trunk/src/tab/script.l: overcome flex stupidities, define undefined to false in order to appease preprocessor logic. |
| 21:48.56 | CIA-77 | BRL-CAD: 03brlcad * r43523 10/brlcad/trunk/src/ (16 files in 16 dirs): |
| 21:48.56 | CIA-77 | BRL-CAD: enable the remainder of strict flags now that the build is verified across mac |
| 21:48.56 | CIA-77 | BRL-CAD: and linux. now all of brl-cad's source code builds strict-clean for improved |
| 21:48.56 | CIA-77 | BRL-CAD: security, maintainability, conformance compliance, stability, reliability, and |
| 21:48.56 | CIA-77 | BRL-CAD: more. |
| 21:54.40 | CIA-77 | BRL-CAD: 03brlcad * r43524 10/brlcad/trunk/src/remrt/ihost.c: replace the net headers with bin.h |
| 22:31.23 | *** join/#brlcad guest_tttt (~rm@123.136.11.66) | |
| 22:31.45 | guest_tttt | ..... |
| 22:33.48 | *** part/#brlcad guest_tttt (~rm@123.136.11.66) | |
| 22:37.11 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 23:02.16 | *** join/#brlcad dtidrow_ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) | |
| 23:02.17 | CIA-77 | BRL-CAD: 03brlcad * r43525 10/brlcad/trunk/src/conv/Makefile.am: missing the shapefil.h header |
| 23:09.15 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 23:13.59 | CIA-77 | BRL-CAD: 03starseeker * r43526 10/brlcad/trunk/include/raytrace.h: search will need regex.h once it is moved to librt |
| 23:16.52 | CIA-77 | BRL-CAD: 03starseeker * r43527 10/brlcad/trunk/src/librt/ (Makefile.am search.c search.h): Add work done so far on search move to librt - not being added to the compile until after the release. |
| 23:28.54 | CIA-77 | BRL-CAD: 03starseeker * r43528 10/geomcore/trunk/tests/svntest/CMakeLists.txt: fix install target for svnTest |
| 23:38.27 | CIA-77 | BRL-CAD: 03starseeker * r43529 10/brlcad/branches/cmake/ (CMakeLists.txt src/other/CMakeLists.txt): Move the TERMLIB option to src/other - we need this set in advance of the third party logic. |
| 00:13.24 | CIA-77 | BRL-CAD: 03starseeker * r43530 10/brlcad/branches/cmake/CMakeLists.txt: Remove the complex and only partially successful noprod logic - with targets in toplevel bin dirs anyway the utility is minimal, and not worth the complexity. |
| 00:36.45 | CIA-77 | BRL-CAD: 03starseeker * r43531 10/brlcad/branches/cmake/ (3 files in 3 dirs): Ignore other in src |
| 00:39.42 | CIA-77 | BRL-CAD: 03starseeker * r43532 10/brlcad/branches/cmake/src/librt/CMakeLists.txt: Ignore search.h |
| 00:50.20 | *** join/#brlcad Klebel (~mk@w73.RIC.Berkeley.EDU) | |
| 00:50.49 | Klebel | I can't find 'Set H' in the Edit menu |
| 00:57.36 | Klebel | press "Set H" - says unknown operation. |
| 00:57.45 | Klebel | on the command line |
| 00:58.31 | starseeker | Klebel: we need more context |
| 00:59.29 | Klebel | page 60 in the Introduction to MGED manual. |
| 00:59.29 | Klebel | |
| 01:00.22 | Klebel | I created a right circular cylinder, then it tells me to do, "Edit and then Set H" |
| 01:00.33 | Klebel | and click the middle mouse button several times |
| 01:01.02 | starseeker | to edit a primitive, you need to use sed |
| 01:01.08 | starseeker | that puts you in edit mode |
| 01:02.05 | starseeker | if you aren't seeing Set H you probably aren't in edit mode |
| 01:02.08 | Klebel | ah, so sed base1.s |
| 01:02.08 | Klebel | thanks, Set H is now in the menu, and works |
| 01:02.29 | starseeker | that tutorial was created with an older version of BRL-CAD, so there are occasional differences |
| 01:02.43 | Klebel | yea I've noticed that :/ |
| 01:07.15 | Klebel | is there a command to get out of edit mode? |
| 01:07.26 | starseeker | accept or reject |
| 01:07.40 | Klebel | ok thanks |
| 01:09.02 | CIA-77 | BRL-CAD: 03starseeker * r43533 10/brlcad/branches/cmake/ (27 files in 22 dirs): MFC r43532 |
| 01:10.42 | CIA-77 | BRL-CAD: 03starseeker * r43534 10/brlcad/branches/cmake/src/other/CMakeLists.txt: Uncomment -w again for src/other |
| 01:17.39 | CIA-77 | BRL-CAD: 03starseeker * r43535 10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: We're going for gnu99 now |
| 02:01.02 | CIA-77 | BRL-CAD: 03brlcad * r43536 10/brlcad/trunk/src/bwish/cadAppInit.c: include bin.h instead of winsock2.h |
| 03:28.05 | *** join/#brlcad guest_tttt (~rm@123.136.11.66) | |
| 03:34.43 | *** part/#brlcad guest_tttt (~rm@123.136.11.66) | |
| 04:32.23 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 04:33.44 | CIA-77 | BRL-CAD: 03brlcad * r43537 10/brlcad/trunk/src/rttherm/pixtest.c: check fwrite return value |
| 04:36.11 | CIA-77 | BRL-CAD: 03brlcad * r43538 10/brlcad/trunk/src/sig/ (24 files): check fwrite return values for failure |
| 04:39.55 | CIA-77 | BRL-CAD: 03brlcad * r43539 10/brlcad/trunk/src/proc-db/brepintersect.cpp: compiler is complaining about the first param to SegmentPolylineIntersect possibly being NULL. as this is dev code, just comment out for now in leu of removing the code. |
| 04:44.14 | CIA-77 | BRL-CAD: 03brlcad * r43540 10/brlcad/trunk/src/mged/points/points_parse.y: bison is being stupid with some output code generating size_t comparisons against >= 0. quell that warning along with a couple other preprocessor symbols that are not defined but being used in expressions. |
| 04:45.52 | CIA-77 | BRL-CAD: 03brlcad * r43541 10/brlcad/trunk/src/ (mged/points/points_scan.l tab/script.l): quell flex lameness where fwrite() is being called without checking the return value. this quiets the compiler. |
| 04:51.08 | CIA-77 | BRL-CAD: 03brlcad * r43542 10/brlcad/trunk/src/ (23 files in 7 dirs): |
| 04:51.09 | CIA-77 | BRL-CAD: categorically check return values for some of the stdio and stdlib routines |
| 04:51.09 | CIA-77 | BRL-CAD: (e.g. fwrite, scanf, system, dup, pipe, ...). not willing to put forth |
| 04:51.09 | CIA-77 | BRL-CAD: time/effort to do anything more than print the error since would have to |
| 04:51.09 | CIA-77 | BRL-CAD: evaluate each call on a case by case basis (and that's not fun). |
| 05:10.50 | *** join/#brlcad dli (~dli@dsl-67-204-45-87.acanac.net) | |
| 05:35.23 | *** join/#brlcad Stattrav (~Stattrav@122.167.254.137) | |
| 05:35.23 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:08.23 | CIA-77 | BRL-CAD: 03brlcad * r43543 10/brlcad/trunk/src/libfb/if_X24.c: fix keybindings on Mac OS X so that cmd-click will produce button 3 events (so we can close framebuffers) without needing the user to set X11.app to emulate a three button mouse. |
| 06:09.28 | CIA-77 | BRL-CAD: 03brlcad * r43544 10/brlcad/trunk/src/libfb/if_ogl.c: do the same mouse-3 binding for ogl |
| 06:51.11 | Klebel | 1 thing I keep noticing in the Introduction manual, is that when I copy primatives through the command line then run sed on the newly copied primative it says: Error sph2.s not being displayed |
| 06:51.37 | Klebel | the only way I am able to copy is through the Primitive Editor |
| 07:01.04 | CIA-77 | BRL-CAD: 03brlcad * r43545 10/brlcad/trunk/src/tclscripts/mged/bindings.tcl: |
| 07:01.04 | CIA-77 | BRL-CAD: fix mged zoom bindings on mac os x with default X11 (where 3-button mouse |
| 07:01.04 | CIA-77 | BRL-CAD: emulation is disabled) so that you can actually zoom out. make cmd-click behave |
| 07:01.04 | CIA-77 | BRL-CAD: the same as button-3. unfortunately, the same binding does not seem possible |
| 07:01.04 | CIA-77 | BRL-CAD: with option-click for mouse 2 (in fact, option seems to act like mod2 aka the |
| 07:01.04 | CIA-77 | BRL-CAD: command-key. none of the other mod types seem to help. |
| 07:07.37 | CIA-77 | BRL-CAD: 03brlcad * r43546 10/brlcad/trunk/NEWS: |
| 07:07.38 | CIA-77 | BRL-CAD: fixed a problem being able to zoom in with the default x11.app configuration |
| 07:07.38 | CIA-77 | BRL-CAD: where you could zoom out, but not back in without enabling 3-button emulation. |
| 07:07.38 | CIA-77 | BRL-CAD: this binds command+button1 the same as button3. couldn't get option+button1 to |
| 07:07.38 | CIA-77 | BRL-CAD: behave as button2 though. |
| 07:10.21 | CIA-77 | BRL-CAD: 03brlcad * r43547 10/brlcad/trunk/src/librt/primitives/table.c: tested and rt_generic_xform() is NOT sufficient. wrong plot and trace with loads of error. |
| 07:10.47 | brlcad | Klebel: when you copy something, it's not automatically drawn |
| 07:10.57 | brlcad | cp old new ; e new |
| 07:11.07 | brlcad | then sed and friends will work |
| 07:11.12 | brlcad | (on new) |
| 07:11.25 | brlcad | e == draw |
| 07:13.30 | brlcad | starseeker: mged regression is failing with "Tcl_Import ERROR: unknown namespace in import pattern "::itcl::*" |
| 07:14.09 | brlcad | wondering if you're seeing that on your end |
| 07:14.50 | brlcad | only namespace or itcl change that comes to mind is the mged/bwish setup routine |
| 07:15.47 | brlcad | yeah, namespace import fails because itcl_init is failing, can't find/load the itcl .so file (testing on linux atm) |
| 07:52.39 | Klebel | thanks brlcad |
| 10:18.24 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 10:38.35 | *** join/#brlcad Elrohir (~kvirc@p5B149820.dip.t-dialin.net) | |
| 11:07.56 | *** join/#brlcad Elrohir (~kvirc@p5B149820.dip.t-dialin.net) | |
| 11:13.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:30.56 | dloman | Mernin all. |
| 11:46.40 | CIA-77 | BRL-CAD: 03d_rossberg * r43548 10/brlcad/trunk/include/bin.h: |
| 11:46.40 | CIA-77 | BRL-CAD: undef some windows defines which are used in an other context here |
| 11:46.40 | CIA-77 | BRL-CAD: (same as in bio.h) |
| 11:49.56 | CIA-77 | BRL-CAD: 03d_rossberg * r43549 10/brlcad/trunk/ (3 files in 3 dirs): raytrace.h got a regex.h include -- added the corresponding search path |
| 12:14.00 | starseeker | brlcad: I'll have to check - I'm doing most of my development work with CMake these days, so I haven't tried the autotools regression in a while |
| 12:14.12 | starseeker | I thought it worked, but maybe it was a fluke... |
| 12:27.29 | dloman | Huh. Neato: http://sewelldirect.com/Sewell-Minideck-USB-to-DVI-Display-Adapter.asp |
| 12:45.21 | CIA-77 | BRL-CAD: 03starseeker * r43550 10/brlcad/trunk/src/fbserv/fbserv.c: Shadowing a global - fixed |
| 12:47.24 | CIA-77 | BRL-CAD: 03starseeker * r43551 10/brlcad/trunk/src/lgt/ (hmenu.c lgt.c): Remove defined-but-unused functions causing lgt failures. |
| 12:49.29 | starseeker | brlcad: still getting a script.c failure: |
| 12:49.40 | starseeker | script.c: In function ‘yy_get_next_buffer’: |
| 12:49.40 | starseeker | script.c:1414: error: comparison between signed and unsigned integer expressions |
| 13:07.12 | starseeker | brlcad: OK, I see a failure |
| 13:07.22 | starseeker | looks like a different one though |
| 13:07.38 | starseeker | brlcad: are you doing an in-dir or out of dir build? |
| 13:09.15 | CIA-77 | BRL-CAD: 03starseeker * r43552 10/brlcad/trunk/src/mged/chgview.c: Don't shadow basename |
| 13:11.16 | starseeker | god I wish we could switch to CMake |
| 13:12.26 | starseeker | out of dir autotools build can't find the tclscripts to initialize the gui, from the looks of it |
| 13:13.49 | starseeker | bizarrely enough, if I start up with nu, package require Itcl DOES succeed |
| 13:15.27 | starseeker | confound it, autopath STILL has /usr/lib at the head of the auto_path search path |
| 13:21.18 | dloman | so, brlcad (autotools) doesn't like out of src builds atm? |
| 13:22.00 | starseeker | oh, I builds OK but it doesn't seem to run |
| 13:23.27 | starseeker | auto_path is getting all the paths set to the build dir versions of tclscript paths, which doesn't work because they're still in the src dir |
| 13:25.57 | starseeker | we can either copy the tclscripts over into the build dir (which is a variation on what CMake does currently) or tweak the path logic to point back to the src dir |
| 13:26.32 | starseeker | but that won't fix the issue of /usr/lib being up front in the search path, which is an excellent way to pull in system installed things and mix the tcl/tk environment up royally |
| 13:30.10 | CIA-77 | BRL-CAD: 03starseeker * r43553 10/brlcad/branches/cmake/ (66 files in 21 dirs): MFC r43552 |
| 13:33.10 | starseeker | nice little subtle issues, particularly when we have to use a local tweaked version of something and there's a vanilla system version getting pulled in instead |
| 13:40.23 | starseeker | saddles up |
| 13:56.42 | ``Erik | <PROTECTED> |
| 14:14.45 | dloman | I love it. |
| 14:15.05 | dloman | the IT guys are trying to tell me that its not possible to drive 4 monitors from two video cards. |
| 14:17.24 | dloman | stares at brlcad's 5 monitor setup and laughs at IT. |
| 14:17.55 | dli | dloman, two video cards for 5 monitor? |
| 14:18.09 | dloman | brlcad actually has 3 cards |
| 14:18.39 | dloman | but the point remains the same. the IT guys I'm emailing obviously dunt know what they are talking about. |
| 14:18.41 | dli | dloman, so X-server can handle as many as you can provide? |
| 14:19.07 | dloman | should |
| 14:22.00 | dli | dloman, nice to know |
| 14:22.51 | dloman | stumbled upon a USB to DVI converter (see link above) that allows up to 6 external monitors :) |
| 14:22.57 | dloman | ....i really want to try that out. |
| 14:24.07 | dli | dloman, I got a thinkpad with faulty video card, maybe, I can drive up a monitor by USB, but I'm not sure |
| 14:24.40 | dloman | Might be worth a look. |
| 14:24.51 | dloman | is the video card integrated or dedicated? |
| 14:25.38 | CIA-77 | BRL-CAD: 03erikgreenwald * r43554 10/brlcad/trunk/src/libfb/if_ogl.c: event is a struct, not a pointer |
| 14:29.08 | dloman | ahahaha, just found a MB that has 7 x16 PCIe slots. Get 7 Eyefinity6's and thats... 42 monitors plus 6 on USB. 48 screens. Awesome. |
| 14:30.05 | dloman | Heh, i wonder if that would actually work :) |
| 14:31.28 | starseeker | consideres the power demand and winces slightly |
| 14:31.57 | dloman | If you can afford all those cards and displays, the Powersupply becomes trivial :) |
| 14:32.09 | ``Erik | mr fusion |
| 14:32.18 | dli | dloman, it's deciated video, but still integrated on the mobo |
| 14:32.40 | ``Erik | 1.21 jiggawatts (whatever a jigga is) |
| 14:32.54 | dloman | dli: suckage. You opened the case to ensure the gfx card isn't removable? |
| 14:33.58 | dloman | ``Erik: you're borderline racist, so be careful :) |
| 14:34.11 | ``Erik | O.o |
| 14:34.12 | dli | dloman, yes, I opened it several times :) right now, the thinkpad works as a file server, and a wireless router for my VoIP |
| 14:34.20 | dloman | ahaha, nice. |
| 14:35.12 | dli | dloman, the VoIP box supports only wired net, so the thinkpad hooks VoIP to wifi. |
| 14:35.20 | dloman | well that usb2dvi thingy costs about 100 bucks, and you might be able to get an entire replacement laptop (depending on how old it is) for that. |
| 14:35.42 | dloman | hates wifi. too slow. |
| 14:36.36 | CIA-77 | BRL-CAD: 03starseeker * r43555 10/brlcad/branches/cmake/src/libfb/if_ogl.c: MFC r43554 |
| 14:37.27 | dli | dloman, then, forget it, it's a 4-year-old core2duo level. |
| 14:37.53 | dloman | heh, i just replaced my old core2 |
| 14:38.09 | dli | dloman, wifi is orders faster than VoIP requires |
| 14:38.37 | dloman | understood |
| 14:39.19 | dloman | and wifi is normally 'good enough' but the wife and I work with large photoshop files and getting them on/off the fileserver via wifi is.... annoying at best. |
| 14:40.28 | dli | dloman, does wifi-N help? |
| 14:40.37 | dloman | some. |
| 14:40.51 | dloman | we're in the process of wiring the house for gig-e |
| 14:41.01 | dloman | so we can plug in when we need speed. |
| 14:41.34 | dli | dloman, that's wonderful :( when I get the budget to redo my home, I will see how to make giga-e possible at home |
| 14:42.29 | dloman | we're doing it slowly. |
| 14:42.31 | dli | dloman, do you work with NURB objects? |
| 14:42.36 | dloman | negative. |
| 14:42.49 | dloman | I know next to nothing about nurbs. |
| 14:42.57 | dloman | its on the long 'tolearn' list. |
| 14:44.32 | dli | dloman, brlcad suggests me to start with NURB intersection problem. I'm too slow here to start :( |
| 14:47.56 | CIA-77 | BRL-CAD: 03erikgreenwald * r43556 10/brlcad/trunk/src/irprep/ir-X.c: size_t casting fixes |
| 14:51.46 | CIA-77 | BRL-CAD: 03erikgreenwald * r43557 10/brlcad/trunk/src/mged/clone.c: size_t casting |
| 14:52.13 | CIA-77 | BRL-CAD: 03erikgreenwald * r43558 10/brlcad/trunk/src/mged/dm-ogl.c: fill out entire struct in table |
| 15:12.03 | brlcad | starseeker: cool, what platform gave you the defined but unused failures? |
| 15:14.00 | brlcad | dloman: you'd saturate the bus before you could drive that many, but it would be fun to see |
| 15:15.05 | brlcad | 4 smaller displays are possible on one dual-dual, or two big'uns |
| 15:15.28 | brlcad | dli: making any progress? |
| 15:15.48 | starseeker | brlcad: was on gentoo |
| 15:15.56 | starseeker | I'm not sure if it was pulling in system itcl or not |
| 15:16.09 | starseeker | those friggin auto_path settings make it problematic |
| 15:16.28 | brlcad | dli: atually the suggestion was based purely on your interest and background -- otherwise, I would have suggested something much smaller to start with :) |
| 15:16.38 | brlcad | starseeker: did it work once installed? |
| 15:16.39 | starseeker | but the gui issue at least was clear - paths were set to build dir, files were in src dir - boom |
| 15:17.02 | starseeker | didn't try an install - was working on regress - but I would expect that it did |
| 15:17.25 | brlcad | k |
| 15:17.29 | brlcad | I'll run a test here too |
| 15:17.47 | brlcad | if install works, then I can at least still tag release |
| 15:18.17 | starseeker | I'm trying to wait for the switch to cmake to really mess with the auto_path settings - they should really simplify down now that we're duplicating the install layout everywhere |
| 15:18.42 | brlcad | true, but it also needs to be relocatable |
| 15:18.54 | starseeker | sure |
| 15:19.05 | brlcad | so an "uninstalled" build tree should also work -- that's the main concern |
| 15:19.06 | starseeker | the CMake build, in my testing, is already relocatable |
| 15:19.42 | brlcad | hm |
| 15:20.05 | starseeker | I just meant we'd have one set of dir paths that list all the tclscripts subdirs, and then use either build root or install root to id them for auto_path |
| 15:21.13 | starseeker | plus, I've got to figure out how to strip those /usr/lib based paths out of the front of the auto_path list |
| 15:22.18 | brlcad | it's not build or install root, it'd be the runtime root for it to be relocatable |
| 15:22.25 | starseeker | er, right |
| 15:22.40 | starseeker | the bu_brlcad_data/bu_brlcad_root logic |
| 15:22.43 | brlcad | k |
| 15:23.28 | brlcad | shouldn't need to strip paths off auto_path -- someone is adding it, that's the point of attack |
| 15:23.58 | starseeker | right - I'm just concerned it might be tcl itself initializing auto_path to those values |
| 15:24.04 | starseeker | at this point I don't know |
| 15:24.11 | brlcad | sounds to me like a system pkgIndex.tcl getting loaded |
| 15:24.52 | starseeker | uh... it can't do that until it has paths to load pkgIndex.tcl files from - that's why it needs that C init process |
| 15:25.23 | brlcad | sure, but there are the built-ini *_Init() routines in the libraries that are loaded |
| 15:25.37 | starseeker | nods |
| 15:25.39 | brlcad | if it pulls a system .so, then it conceivably can modify the auto_path |
| 15:26.36 | starseeker | it would help if there was a debug setting to let us see where package require was finding its .so files |
| 15:26.46 | starseeker | (for a given package require operation) |
| 15:29.02 | brlcad | there are ways to introspect tcl from the interpreter |
| 15:29.15 | brlcad | "info loaded", "into library" |
| 15:29.31 | brlcad | man n info |
| 15:30.15 | starseeker | ah, excellent |
| 15:30.22 | brlcad | "package names" |
| 15:32.05 | starseeker | I have a hunch my gentoo box has a system itcl/itk that happened to work, and it found that (since it didn't have the auto_path information needed to bridge the divide between build and src dirs, based on the gui behavior) |
| 15:32.39 | starseeker | would almost be better if we could somehow reject libraries not in the "BRL-CAD expected" location for Tcl packages |
| 15:32.58 | starseeker | would avoid the accidentally, silently working issue |
| 15:54.58 | CIA-77 | BRL-CAD: 03erikgreenwald * r43559 10/brlcad/trunk/src/mged/ (edsol.c mged.h): de-const due to possible deletion |
| 16:00.21 | CIA-77 | BRL-CAD: 03erikgreenwald * r43560 10/brlcad/trunk/src/mged/fbserv.c: Move the forward declaration into the #if section that uses it, to avoid the "declared 'static' but never defined" error. |
| 16:08.04 | CIA-77 | BRL-CAD: 03erikgreenwald * r43561 10/brlcad/trunk/src/proc-db/vegetation.c: size_t cast fix |
| 16:17.37 | dloman | ``Erik: I think i found it. in GSThread::start(), the pthread was being created in a detached state. In ~GSThread, pthread_join() was called. According to the man page, calling _join on a detached thread is a no no. |
| 16:19.09 | CIA-77 | BRL-CAD: 03davidloman * r43562 10/geomcore/trunk/src/utility/GSThread.cxx: Commented out the pthread_join() call in GSThread::~GSThread. Man page says that a pthread created in a detached state cannot be used as a sync point via pthread_join() |
| 16:19.24 | dloman | see if that messes anything up on bsd and/or mac |
| 16:29.39 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:39.39 | CIA-77 | BRL-CAD: 03davidloman * r43563 10/geomcore/trunk/src/utility/GSUuid.cxx: Fix a bug where the buffer used to export the uuid was being free'd prior to that buffer being used to generate a std::string. |
| 17:18.06 | dli | brlcad, yes, I'm still interested on the NURB intersection part. I will have more time now to work on it. Had to go to hospital often in past weeks |
| 17:19.38 | dli | brlcad, at this stage, I'm still reading through the ON wiki: http://wiki.mcneel.com/developer/opennurbs/home |
| 17:20.11 | dli | brlcad, still, I will report my success as well as my failure to you when it's time |
| 17:21.18 | brlcad | naturally, I'd hope we can choose the best development path so we achieve success instead of failur ;) |
| 17:22.02 | brlcad | that might mean not biting on one of the hardest problems first, there are lots of places where some progress could be made that would help get you familiarized with the source code |
| 17:23.16 | dli | brlcad, sure, through evolution is good, but the code base overall is huge, it might easier for me to start by writing something new |
| 17:24.04 | brlcad | new vs old isn't as important as starting with something very small |
| 17:24.25 | brlcad | nurbs intersection is not small ... |
| 17:24.38 | dli | brlcad, if you can point to some place, I would be glad to see whether I can fix some small things in parallel with my intersection problem |
| 17:24.48 | brlcad | so that was probably over-ambitious without having touched any other code |
| 17:26.33 | CIA-77 | BRL-CAD: 03brlcad * r43564 10/brlcad/trunk/doc/README.Linux: include instructions to force 32-bit on platforms that default to 64-bit as well. |
| 17:26.47 | brlcad | hm, something came up just this week that is a nice small task |
| 17:27.23 | brlcad | and it's in a similar section of library code as the brep/nurbs primitive |
| 17:27.28 | brlcad | the revolve primitive |
| 17:28.57 | dli | brlcad, sounds good. is there a bug tracking thread for this task? |
| 17:29.06 | brlcad | basically, it's a very new primitive so it doesn't yet have support for matrix transformations (scaling, translation, rotation) |
| 17:29.46 | brlcad | support for matrix transforms is in one function, which revolve doesn't presently implement |
| 17:30.12 | brlcad | https://sourceforge.net/projects/brlcad/forums/forum/362510/topic/4372998 |
| 17:30.49 | brlcad | that's merely a day or two project, unlike nurbs which is several weeks :) |
| 17:31.34 | dli | brlcad, so, rt_generic_xform(), that's specific enough for me. I will report what I can do later |
| 17:31.53 | brlcad | rt_generic_xform() isn't sufficient, which was my last comment |
| 17:32.13 | brlcad | have to implement rt_revolve_xform() similar to rt_extrude_xform() |
| 17:32.46 | brlcad | src/librt/primitives/revolve/revolve.c and src/librt/primitives/extrude/extrude.c respectively, with the function listed in src/librt/primitives/table.c |
| 17:33.00 | dli | brlcad, I get some rough idea about what's needed here, need to read the code first |
| 17:33.40 | CIA-77 | BRL-CAD: 03brlcad * r43565 10/brlcad/trunk/src/other/tkhtml/Makefile.am: |
| 17:33.40 | CIA-77 | BRL-CAD: the clean rule was overriding autoconf's default clean rule, which calls |
| 17:33.40 | CIA-77 | BRL-CAD: clean-am. this should fix the build where you follow a 32-bit build with a |
| 17:33.40 | CIA-77 | BRL-CAD: 64-bit built and vice versa. stale .o build files were getting left in the |
| 17:33.40 | CIA-77 | BRL-CAD: .libs dir causing the build to halt. |
| 17:33.53 | brlcad | working on that will introduce you to how primitives are implemented, some basic structures, the callback interface, and some light math |
| 17:34.03 | brlcad | all useful and relevant for working on nurbs |
| 17:34.21 | dli | brlcad, let's see. :) |
| 17:38.12 | brlcad | starseeker: do you have a clean build? |
| 17:38.24 | brlcad | ``Erik: when was the last time you tried a windows build? |
| 17:38.33 | brlcad | needs a windows build test |
| 17:38.45 | brlcad | mac/linux are clean here |
| 17:40.24 | brlcad | and ``Erik, what can you tell me about the libtie integration? working on the writeup |
| 17:48.54 | ``Erik | tried one yesterday, broke a lot using msvc8, will try another |
| 17:49.41 | ``Erik | libtie's functions are in librt, bots that are oriented or have normals should pass to tie if you set the rt_min_tie (emulated rt_min_piece) |
| 17:50.13 | *** join/#brlcad Stattrav (~Stattrav@117.192.128.118) | |
| 17:50.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:50.15 | ``Erik | the rt_min_tie is set to 4 billion and some change right now pending more testing |
| 17:50.15 | brlcad | how does one set rt_min_tie? |
| 17:50.23 | ``Erik | uh, -c I think? |
| 17:50.36 | brlcad | ah, so it'll auto-kick over to tie for 4M+ models now |
| 17:51.21 | ``Erik | 4m+ bot primitives |
| 17:51.28 | brlcad | right, okay |
| 17:51.32 | ``Erik | 0xffffffff |
| 17:51.39 | brlcad | ah, heh |
| 17:52.09 | brlcad | interesting, so no way to turn it off then or is 0 special? :) |
| 17:52.19 | ``Erik | from when that was an int, not a size_t |
| 17:54.01 | brlcad | and rough performance impact on a 4M model is what? 10%-500%? average 50%? |
| 17:55.06 | ``Erik | didn't have a 4m primitive, at ~2000 it was 200% (100% gain), 200 was like 150% (+50%), 12 was 70% (-30%) |
| 17:56.01 | brlcad | so on a real model, should see the time about cut in half |
| 17:56.43 | ``Erik | that was tesselating a sphere, the 'real' models I tried were tesselations of lots of arbs, not NURBS tesselations from an importer |
| 17:57.03 | ``Erik | the benchmark numbers were from tesselated spheres |
| 17:57.37 | ``Erik | jabs cia |
| 17:58.17 | ``Erik | 0 disables tie as of 6 minutes ago |
| 17:59.01 | brlcad | hehe, awesome |
| 17:59.39 | brlcad | so I'll run a quick test on some bot model I have, see what things look like |
| 18:00.07 | ``Erik | there're a couple rough edges that need cleaned up before I'm comfortable impacting customers with it |
| 18:00.13 | brlcad | any other caveats or useful info other than maybe not so hot for tiny models? |
| 18:00.36 | ``Erik | on occasion, it misses :D |
| 18:00.47 | brlcad | rt_min_tie is coming up empty, what's the real name? :) |
| 18:01.13 | ``Erik | rt_bot_mintie |
| 18:01.23 | brlcad | thx |
| 18:01.24 | ``Erik | (to mimic rt_bot_minpieces) |
| 18:05.36 | CIA-77 | BRL-CAD: 03brlcad * r43566 10/brlcad/trunk/TODO: |
| 18:05.36 | CIA-77 | BRL-CAD: attr command now sorts alphabetically, but then other users reportedly |
| 18:05.36 | CIA-77 | BRL-CAD: also/still want sorting based on creation order (because it makes it easy to |
| 18:05.36 | CIA-77 | BRL-CAD: diff and/or find new additions. need a sorting option. kicking off an EDITOR |
| 18:05.36 | CIA-77 | BRL-CAD: should now be better too now that the invocation has been re-reviewed recently. |
| 18:10.12 | ``Erik | script.c:1414: warning: comparison between signed and unsigned |
| 18:10.19 | ``Erik | src/remrt/remrt.c:752: warning: comparison between signed and unsigned |
| 18:11.10 | CIA-77 | BRL-CAD: 03brlcad * r43567 10/brlcad/trunk/TODO: WE ARE FREE OF COMPILATION WARNINGS! woot. |
| 18:14.51 | CIA-77 | BRL-CAD: 03erikgreenwald * r43568 10/brlcad/trunk/src/librt/primitives/bot/bot.c: rt_bot_mintie=0 now means do not use tie |
| 18:16.43 | brlcad | my 752 is an FD_MOVE line.. doesn't seem right |
| 18:17.11 | ``Erik | I know, I've been grepping around, fbsd might have a bad header |
| 18:17.41 | brlcad | maybe line index from 0 and it's complaining about the tcp_listen_fd int fd |
| 18:19.29 | ``Erik | oohhhhh |
| 18:20.42 | ``Erik | got it |
| 18:21.15 | ``Erik | (#ifndef FD_MOVE ... we had our own for os's like fbsd which don't provide) |
| 18:21.54 | brlcad | interesting |
| 18:24.38 | brlcad | looks like rt_bot_mintie is only exposed via mged tcl var, not -c |
| 18:25.42 | ``Erik | hm, I used rt_bot_minpieces as a template, thought the librt tcl.c was called on rt's startup |
| 18:26.04 | brlcad | i added it |
| 18:26.34 | brlcad | it is a tcl var inside the tcl interp that libtcl has running, but that's not exposed to rt |
| 18:26.53 | brlcad | they are manually wired to the global |
| 18:27.07 | ``Erik | ah |
| 18:27.56 | ``Erik | win32 just built, had to remove regex.h from raytrace.h (or update the include paths for most projects) and add ws2_32.lib to a handful of converters |
| 18:29.55 | brlcad | yeah, regex.h inside raytrace.h doesn't sound like a good idea |
| 18:30.14 | brlcad | should be an implementation detail, not public api requirement |
| 18:31.30 | brlcad | poor CIA-77 |
| 18:31.39 | starseeker | ``Erik: guess you're right, I'll have to do the void thing |
| 18:32.56 | CIA-77 | BRL-CAD: 03erikgreenwald * r43569 10/brlcad/trunk/include/raytrace.h: conditionalize regex.h |
| 18:35.04 | starseeker | brlcad: I'm still getting failures on Mac with script.c from src/tab |
| 18:35.16 | starseeker | script.c:33:5: error: "__STDC_VERSION__" is not defined |
| 18:35.26 | starseeker | script.c: In function ‘yy_get_next_buffer’: |
| 18:35.27 | starseeker | script.c:1389: warning: comparison between signed and unsigned |
| 18:40.38 | ``Erik | the windows comment in rt/do.c is due to "initializer not static". might need to assign those in cm_set() as a runtime dealie |
| 18:41.05 | brlcad | aha, that makes more sense |
| 18:41.16 | brlcad | those variables are in librt, so it can't bind them |
| 18:41.22 | CIA-77 | BRL-CAD: 03erikgreenwald * r43570 10/brlcad/trunk/include/raytrace.h: remove regex.h for now, windows would need most vcproj files updated. |
| 18:41.24 | brlcad | dll import suckage |
| 18:46.44 | CIA-77 | BRL-CAD: 03erikgreenwald * r43571 10/brlcad/trunk/src/remrt/remrt.c: fdset uses unsigned, so fix if we need FD_MOVE defined |
| 18:52.33 | CIA-77 | BRL-CAD: 03brlcad * r43572 10/brlcad/trunk/src/rt/do.c: add support for -c rt_bot_mintie |
| 18:53.22 | CIA-77 | BRL-CAD: 03erikgreenwald * r43573 10/brlcad/trunk/misc/win32-msvc8/ (5 files in 5 dirs): link ws2_32.lib for ntohl/htonl |
| 19:00.18 | CIA-77 | BRL-CAD: 03brlcad * r43574 10/brlcad/trunk/src/nirt/ (command.c nirt.c nirt.h): add support for setting rt_bot_mintie from within nirt, similar to rt_bot_minpieces. add new -T option in addition to new bot_mintie nirt command. |
| 19:08.24 | CIA-77 | BRL-CAD: 03brlcad * r43575 10/brlcad/trunk/NEWS: added -T and bot_mintie options to nirt that correspond with controlling when erik's new support for optimized BoT raytacing kicks on |
| 19:12.50 | CIA-77 | BRL-CAD: 03brlcad * r43576 10/brlcad/trunk/src/rt/do.c: expand the comment now that the cause is known. need to set during runtime, not compiletime. |
| 19:13.28 | CIA-77 | BRL-CAD: 03brlcad * r43577 10/brlcad/trunk/misc/win32-msvc/CMakeLists.txt: back to not needing libregex search dir |
| 19:25.46 | CIA-77 | BRL-CAD: 03brlcad * r43578 10/brlcad/trunk/NEWS: (log message trimmed) |
| 19:25.46 | CIA-77 | BRL-CAD: reword tie integration from user-visible perspective. erik integrated the |
| 19:25.46 | CIA-77 | BRL-CAD: former 'libtie' high-performance triangle intersection engine (tie) into librt |
| 19:25.46 | CIA-77 | BRL-CAD: as a way to get optimized BoT raytracing. initial results showing a halfing |
| 19:25.46 | CIA-77 | BRL-CAD: reduction of raytrace time for models at 2k+ triangles. erik added an |
| 19:25.47 | CIA-77 | BRL-CAD: 'rt_bot_mintie' option (exposed via mged and rt -c) for toggling when the |
| 19:25.48 | CIA-77 | BRL-CAD: optimization kicks in. currently set really high at 4M until further testing |
| 19:41.00 | CIA-77 | BRL-CAD: 03starseeker * r43579 10/brlcad/branches/cmake/src/ (libged/search.c librt/search.c): |
| 19:41.01 | CIA-77 | BRL-CAD: Not in final form yet (for one thing, the regex in db_plan_t will have to become |
| 19:41.01 | CIA-77 | BRL-CAD: void and be cast as needed) but this can run searches now. Can't be committed |
| 19:41.01 | CIA-77 | BRL-CAD: to trunk until after release in this form, but committing now in cmake to have |
| 19:41.01 | CIA-77 | BRL-CAD: it checked in somewhere |
| 19:45.23 | CIA-77 | BRL-CAD: 03starseeker * r43580 10/brlcad/branches/cmake/src/libged/search.c: Whoops, need memory here too. |
| 19:52.04 | dloman | brlcad: do we have any Display port to DVI or VGA adapters around the office? |
| 19:52.10 | dloman | (if yo uknow off hand) |
| 19:53.17 | CIA-77 | BRL-CAD: 03starseeker * r43581 10/brlcad/branches/cmake/ (include/raytrace.h src/librt/search.h): Stick regex in the private search header for now... |
| 20:23.41 | starseeker | ``Erik: bob says tcl is wonderful |
| 20:24.22 | ``Erik | especially on windows? |
| 20:25.54 | starseeker | heh |
| 20:51.56 | CIA-77 | BRL-CAD: 03starseeker * r43582 10/brlcad/branches/cmake/ (4 files in 3 dirs): This approach keeps the plan data structure out of raytrace.h, and thus isolates regex. |
| 21:43.55 | CIA-77 | BRL-CAD: 03starseeker * r43583 10/brlcad/branches/cmake/ (23 files in 16 dirs): MFC r43582 |
| 21:48.02 | *** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 21:58.38 | CIA-77 | BRL-CAD: 03starseeker * r43584 10/brlcad/trunk/ (7 files in 3 dirs): Put the new search routines into trunk |
| 21:59.05 | brlcad | hope you cross-compile tested that :) |
| 22:00.39 | starseeker | brlcad: just mac so far - working on it |
| 22:00.55 | starseeker | had to re-implement the search . ... stuff |
| 22:01.03 | starseeker | I think it behaves the way you wanted it to now |
| 22:01.16 | *** join/#brlcad Klebel (~mk@169.229.55.243) | |
| 22:02.11 | brlcad | I actually just hope it works with it being injected right before the release, and isn't like that nirt "fix" made right before release |
| 22:02.32 | starseeker | brlcad: sorry, I know it's a rotten time... |
| 22:02.56 | starseeker | I can back it out in trunk and just work in cmake branch |
| 22:03.49 | CIA-77 | BRL-CAD: 03starseeker * r43585 10/brlcad/branches/cmake/src/ (4 files in 2 dirs): MFC r43584 |
| 22:03.53 | brlcad | committing is fine, you should just be extra care and be testing more than usual |
| 22:04.24 | starseeker | nods - it's hot off the press, I just now got it running, so I'm starting the testing now |
| 22:05.03 | starseeker | if you've got a working compile, you might check if the new behavior of (say) search . -maxdepth=0 does what you expect |
| 22:05.34 | starseeker | I think we can squash that TODO item, but since you spotted the issue confirmation would be good :-) |
| 22:05.58 | brlcad | I can check it (and you should too given the timing) |
| 22:06.04 | starseeker | oh, I am |
| 22:06.41 | starseeker | I just ment I wanted to make sure I had the behavior you wanted, given how hard you had to work to explain it to me :-P |
| 22:07.44 | brlcad | at release time, it becomes more like how trunk development used to be -- trunk HEAD should be treated like stable: changes tested on multiple platforms before commit, runtime tested on everything |
| 22:07.49 | brlcad | I know |
| 22:08.12 | brlcad | I mean "you too" should be making extra sure that all of search still works, maybe run through the documented examples |
| 22:08.20 | brlcad | not just the new feature |
| 22:08.21 | starseeker | ah |
| 22:08.26 | starseeker | gotcha |
| 22:09.50 | starseeker | how |
| 22:09.59 | starseeker | bot.c isn't happy |
| 22:11.13 | brlcad | ah right, warnings |
| 22:11.22 | brlcad | compile had -w in effect |
| 22:11.53 | brlcad | perfect example :) |
| 22:13.34 | starseeker | got those, moving on... |
| 22:15.53 | brlcad | you mean you already got those? |
| 22:17.35 | starseeker | think so - just remove the unused and cast to size_t for comparisons |
| 22:17.53 | starseeker | (don't want to mess with bot->faces... types right now) |
| 22:18.26 | brlcad | have them fixed here too |
| 22:19.21 | starseeker | ah - feel free to stomp mine |
| 22:19.35 | brlcad | yours matched mine |
| 22:19.40 | starseeker | cool |
| 22:19.48 | brlcad | but you apparently weren't getting unused var warnings like I have here |
| 22:20.00 | starseeker | really? you got more? |
| 22:20.05 | brlcad | yep |
| 22:20.09 | starseeker | weird |
| 22:20.25 | brlcad | to be expected |
| 22:21.32 | brlcad | one of the lessons from all the cleanup is that even minor version number differences in gcc result in different warnings, along with changes to compilation options, 32-bit vs 64-bit, optimized vs non-optimized |
| 22:22.24 | brlcad | and they're not a combination that is exactly a superset, so there ends up being something like 3! possible configurations |
| 22:22.35 | brlcad | 3! or 4! |
| 22:25.04 | starseeker | nods |
| 22:30.06 | _psilva | :( |
| 22:30.21 | starseeker | _psilva: ? |
| 22:35.17 | starseeker | brlcad: my mac compile is still failing in src/tab on script.c |
| 22:37.14 | starseeker | search completes all the examples from the man page on potential |
| 22:38.23 | starseeker | brlcad: what version of flex and bison (or lex/yacc) are you working with? |
| 22:55.22 | starseeker | oh, right |
| 22:55.34 | starseeker | can't really test well on the mac because of that messed up install |
| 22:59.44 | starseeker | with autotools anyway... |
| 22:59.57 | starseeker | search looks ok with the cmake build on the mac |
| 23:16.15 | CIA-77 | BRL-CAD: 03starseeker * r43586 10/brlcad/trunk/src/libged/search.c: Re-add support for the '.' option (e.g. search . -name s*) but this time do it at the ged level with post-processing of the full search. Also doesn't print the leading '/' character for the '.' searches. |
| 23:17.27 | CIA-77 | BRL-CAD: 03brlcad * r43587 10/brlcad/trunk/src/conv/patch/patch-g.c: curious that thick_no only shows up as a potential longjmp clobber var when compiling in 32-bit mode |
| 23:17.47 | CIA-77 | BRL-CAD: 03brlcad * r43588 10/brlcad/trunk/src/librt/primitives/bot/bot.c: damnits, found a bug during release testing. disable the optimization so release can proceed. |
| 23:17.51 | CIA-77 | BRL-CAD: 03brlcad * r43589 10/brlcad/trunk/TODO: resolve the crash post-release |
| 23:22.18 | CIA-77 | BRL-CAD: 03starseeker * r43590 10/brlcad/trunk/src/librt/primitives/bot/bot.c: Clear some warnings on bot.c |
| 23:24.29 | CIA-77 | BRL-CAD: 03brlcad * r43591 10/brlcad/trunk/src/librt/primitives/bot/bot.c: quell unused var warnings for the non-optimized case. split vars across impls. |
| 23:26.07 | _psilva | gdc crunch sucks |
| 23:26.45 | _psilva | need more comp days from this |
| 23:32.00 | *** join/#brlcad Klebel (~mk@w72.RIC.Berkeley.EDU) | |
| 23:53.03 | brlcad | sushi:~ morrison$ flex --version |
| 23:53.03 | brlcad | flex 2.5.35 |
| 23:53.03 | brlcad | sushi:~ morrison$ bison --version |
| 23:53.03 | brlcad | bison (GNU Bison) 2.3 |
| 00:20.51 | starseeker | will have to test with newer versions on mac to see if it makes a difference |
| 00:23.45 | CIA-77 | BRL-CAD: 03starseeker * r43592 10/brlcad/branches/cmake/ (5 files in 4 dirs): MFC r43591 |
| 00:28.44 | CIA-77 | BRL-CAD: 03starseeker * r43593 10/brlcad/trunk/src/libged/search.c: gentoo wants search_results initialized |
| 00:33.39 | brlcad | that's just fantastic.. mged crash |
| 00:34.03 | starseeker | winces - what's the issue? |
| 00:34.14 | brlcad | don't know yet, just crashed opening an nmg |
| 00:34.19 | starseeker | ah |
| 00:34.30 | starseeker | fwiw - search seems to be working on gentoo |
| 00:55.57 | brlcad | excellent |
| 01:07.46 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 02:49.35 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 02:49.35 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202) | |
| 02:51.00 | starseeker | nods - I'll have to look at the current tests and see what he got running |
| 02:51.17 | starseeker | he breaks things out into analytical and numerical categories in the wiki page |
| 02:51.57 | starseeker | I'm assuming numerical would involve either floating point or some form of quantizing |
| 02:55.44 | starseeker | huh - looks numerical... |
| 03:04.01 | starseeker | wait... gecode has a flatzinc support setup, which does have some sort of Float support... |
| 03:51.28 | CIA-77 | BRL-CAD: 03brlcad * r43594 10/brlcad/trunk/NEWS: release write-up on the integration of TIE with LIBRT and the new shp-g shapefile importer. |
| 04:10.03 | CIA-77 | BRL-CAD: 03brlcad * r43595 10/brlcad/trunk/BUGS: encountered an infinite loop bug trying to smooth a bot. might be the same traversal bug encountered earlier, but needs testing / investigating. |
| 04:42.01 | brlcad | ``Erik_: harrumph.. I can't seem to get a render through to the tie code |
| 04:42.35 | brlcad | created a volume bot, smoothed it, rh orientation, mintie set to 1 .. still kicks over to old way |
| 04:42.41 | brlcad | any suggestions? |
| 04:42.51 | *** join/#brlcad yukonbob (~bch@S0106002129e399fc.ok.shawcable.net) | |
| 04:42.53 | yukonbob | oh hai |
| 04:42.56 | brlcad | howdy |
| 04:43.31 | yukonbob | my friend. |
| 04:43.35 | yukonbob | how're things? |
| 04:44.31 | brlcad | crazy busy, trying to push a release out and hitting speed bumps left and right |
| 04:44.33 | brlcad | bbl |
| 04:46.03 | yukonbob | working through a bump w/ .2 current release + tk... |
| 04:49.20 | ``Erik_ | does it prep for tie? I may've borked some logic... |
| 04:49.50 | yukonbob | ``Erik_: that for me? |
| 04:50.14 | ``Erik_ | no, unless you're trying to do bot/tie raytracing |
| 04:50.16 | brlcad | ``Erik_: prep is where I've added some debug and it's not getting there |
| 04:50.48 | yukonbob | stands back from the prep ties. |
| 04:51.05 | ``Erik_ | hm, bot.c:208 is untested logic... I can look tomorrie |
| 04:51.44 | CIA-77 | BRL-CAD: 03brlcad * r43596 10/brlcad/trunk/src/librt/primitives/bot/bot.c: commit the debug code so it's clear what's going on with the tie integration |
| 04:53.07 | ``Erik_ | should be in really early tomorrow, so I'll be able to crank up the tunes, chill the office and be somewhat productive |
| 05:38.10 | yukonbob | brlcad: can I squeak in a patch for configure? |
| 05:38.48 | yukonbob | will see if still has commit bit... |
| 05:54.24 | CIA-77 | BRL-CAD: 03bharder * r43597 10/brlcad/trunk/configure.ac: Direct use of interp->result is deprecated; Use Tcl_GetStringResult(). |
| 06:05.04 | yukonbob | I'll look for more later... is not an immediate problem, but will be in future. |
| 06:32.15 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) | |
| 06:47.18 | brlcad | ``Erik: nod, i'll be in probably late morning after a package arrives, but will poke at it some more with the debugger |
| 06:47.41 | brlcad | addressing a couple other bugs at the moment too |
| 06:49.36 | *** join/#brlcad Stattrav (~Stattrav@122.172.12.71) | |
| 06:49.36 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:52.21 | CIA-77 | BRL-CAD: 03brlcad * r43598 10/brlcad/trunk/TODO: |
| 06:52.21 | CIA-77 | BRL-CAD: bio.h header was de-netted, bin.h added. found a few other show-stoppers, |
| 06:52.21 | CIA-77 | BRL-CAD: though. nmg is busted due to a host/net bug. have to test tie optimization for |
| 06:52.21 | CIA-77 | BRL-CAD: release notes (as it's the major highlight). search implements '.' so it needs |
| 06:52.21 | CIA-77 | BRL-CAD: a quick test. and finally, verify red/ted work since tom is reporting a failure |
| 06:52.22 | CIA-77 | BRL-CAD: in .2 with red. |
| 07:15.15 | brlcad | it looks like the tclvar hook into rt_bot_mintie isn't sticking if set from mged |
| 07:16.59 | brlcad | heh, got it to go in and it crashed |
| 07:17.32 | brlcad | (during prep) |
| 07:20.10 | brlcad | aha, possibly completely unrelated! |
| 07:33.36 | brlcad | ooor, maybe it is related.. |
| 07:36.53 | yukonbob | getting build failure on ./src/libbu/bitv.c, w/ "array subscript has type 'char'" at lines 251, 255... |
| 07:37.03 | yukonbob | also hitting hay.... ciao. |
| 07:44.16 | CIA-77 | BRL-CAD: 03brlcad * r43599 10/brlcad/trunk/src/librt/primitives/bot/btg.c: not sure if this is right, but it takes care of rt bombing out with a bad matrix during do_ae() due to zero-sized bounding box |
| 07:53.02 | CIA-77 | BRL-CAD: 03brlcad * r43600 10/brlcad/trunk/src/rt/do.c: add a sanity check in case code ends up computing an empty bounding box, so we don't bomb out during bn_mat_inv(). make sure the viewsize is at least not zero. |
| 07:53.59 | brlcad | that takes care of the crash and bomb, but still no picture, reports invalid segments |
| 08:14.35 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 10:24.35 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 11:28.17 | CIA-77 | BRL-CAD: 03starseeker * r43601 10/brlcad/branches/cmake/CMakeLists.txt: New policy in 2.8.4 - we prefer the old behavior for now |
| 11:31.39 | CIA-77 | BRL-CAD: 03starseeker * r43602 10/brlcad/branches/cmake/src/other/libutahrle/ (4 files in 2 dirs): Can't lean on the BRL-CAD checks for subdirs now - utah needs M_LIBRARY |
| 11:33.40 | CIA-77 | BRL-CAD: 03starseeker * r43603 10/brlcad/branches/cmake/ (9 files in 4 dirs): MFC r43602 |
| 11:36.33 | dloman | Merning all |
| 11:37.04 | CIA-77 | BRL-CAD: 03starseeker * r43604 10/brlcad/trunk/src/rt/do.c: Comment needs terminating |
| 11:43.35 | CIA-77 | BRL-CAD: 03starseeker * r43605 10/brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c: gentoo seems to want cmax initialized - hopefully max is ok... |
| 11:45.59 | CIA-77 | BRL-CAD: 03starseeker * r43606 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: initalize points in dsp |
| 11:48.07 | *** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no) | |
| 11:54.28 | starseeker | O.o |
| 11:54.34 | starseeker | src/librt/primitives/extrude/extrude.c: In function ?classify_sketch_loops?: |
| 11:54.34 | starseeker | src/librt/primitives/extrude/extrude.c:394: error: ?center2d? may be used uninitialized in this function |
| 11:54.37 | starseeker | src/librt/primitives/extrude/extrude.c:1509: note: ?center2d? was declared here |
| 11:54.39 | starseeker | src/librt/primitives/extrude/extrude.c:394: error: ?rb? may be used uninitialized in this function |
| 11:54.42 | starseeker | src/librt/primitives/extrude/extrude.c:1507: note: ?rb? was declared here |
| 11:54.43 | dloman | ``Erik: Hey man, is there still a tiny proxy running somewhere on seans box? |
| 11:54.45 | starseeker | src/librt/primitives/extrude/extrude.c:394: error: ?ra? may be used uninitialized in this function |
| 11:54.48 | starseeker | src/librt/primitives/extrude/extrude.c:1507: note: ?ra? was declared here |
| 11:54.49 | starseeker | that's got me puzzled |
| 11:55.04 | dloman | that is pretty wierd? |
| 11:55.11 | dloman | oops :/ |
| 11:56.01 | starseeker | unless I'm missing something, line 394 doesn't have center2d in it |
| 12:02.32 | dloman | starseeker: in fn isect_2D_loop_ray(..) on line 1545, isect_line_earc(..) is called and center2d is passed in. |
| 12:03.25 | dloman | isect_line_earc(..) in turn calls isect_line2(..), again passing in center2d |
| 12:03.39 | starseeker | but at that point... why is it reporting uninitalized? |
| 12:03.45 | dloman | and line 394 is in isect_line2_ellipse() |
| 12:04.22 | starseeker | I tried a V2SET on center2d right after it's declared, and it changes nothing |
| 12:05.31 | dloman | ....so that means what? center2d is initialized? |
| 12:06.18 | starseeker | it means I don't know what to do to convince the compiler it is initialized |
| 12:07.57 | starseeker | even better, it's only on the static build |
| 12:08.05 | starseeker | they dynamic lib succeeds |
| 12:08.44 | dloman | nice. |
| 12:09.01 | dloman | well, outside of tracing things visually, im of no use :) |
| 12:09.50 | starseeker | the only difference I see in the extruce.o compile lines is the presence of -Dlibrt_EXPORTS in the dynamic line |
| 12:11.01 | starseeker | no, that's not it... |
| 12:11.03 | starseeker | what am I missing |
| 12:14.24 | ``Erik | <PROTECTED> |
| 12:14.29 | starseeker | oh -fPIC |
| 12:16.41 | starseeker | I don't believe it |
| 12:16.45 | starseeker | -fPIC is the difference |
| 12:16.51 | starseeker | why would that matter??? |
| 12:17.52 | starseeker | gcc version 4.4.5 |
| 12:23.14 | ``Erik | -fPIC instructs the linker to generate position independent code |
| 12:23.27 | ``Erik | relative jmp's instead of absolute, etc |
| 12:23.50 | ``Erik | gcc -E and gcc -S might be handy if you wanna figure it |
| 12:25.28 | CIA-77 | BRL-CAD: 03starseeker * r43607 10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: More initializations (why doesn't VSETALL get old_pl[3]??) |
| 12:26.45 | CIA-77 | BRL-CAD: 03starseeker * r43608 10/brlcad/trunk/src/librt/primitives/nmg/nmg_plot.c: another initialization |
| 12:27.32 | CIA-77 | BRL-CAD: 03erikgreenwald * r43609 10/brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c: force cmin/cmax using VSETALL. This should be unnecessary, but some compiler/OS combinations aren't smart enough to catch "int a; if(something) a=0; else a=1;" and assume a is unset. |
| 12:28.15 | CIA-77 | BRL-CAD: 03starseeker * r43610 10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: whoops, plane not point |
| 12:28.28 | ``Erik | the amin vs min in btg.c was important, they're different numbers :/ (actual geometric min vs fpu friendly padding min, iirc) |
| 12:33.41 | CIA-77 | BRL-CAD: 03starseeker * r43611 10/brlcad/trunk/src/librt/search.c: initialize new to NULL |
| 12:44.32 | CIA-77 | BRL-CAD: 03starseeker * r43612 10/brlcad/branches/cmake/CMakeLists.txt: Hmm - how did this not trigger before? make sure HAVE_STRINGS_H actually makes it into brlcad_config.h |
| 12:54.01 | CIA-77 | BRL-CAD: 03starseeker * r43613 10/brlcad/branches/cmake/src/librt/CMakeLists.txt: I can't believe it, but without -fPIC in the static build possibly uninitialized warnings appear with gcc 4.4.5 on gentoo. Only on extrude.c |
| 12:58.02 | CIA-77 | BRL-CAD: 03starseeker * r43614 10/brlcad/trunk/src/liboptical/sh_toyota.c: another initialization |
| 13:02.59 | ``Erik | hm, musta lost that in merge *sigh* |
| 13:05.18 | CIA-77 | BRL-CAD: 03erikgreenwald * r43615 10/brlcad/trunk/ (include/tie.h src/librt/primitives/bot/tie_kdtree.c): remove obsolete kdtree cache stuff |
| 13:09.38 | CIA-77 | BRL-CAD: 03starseeker * r43616 10/brlcad/branches/cmake/src/conv/intaval/CMakeLists.txt: Use BRLCAD_ADD_EXEC for tgf-g |
| 13:10.26 | brlcad | I'l make sure you have access to the new server sometime this week |
| 13:11.02 | brlcad | after release is posted |
| 13:12.04 | CIA-77 | BRL-CAD: 03starseeker * r43617 10/brlcad/trunk/src/conv/nastran-g.c: initializations |
| 13:13.43 | CIA-77 | BRL-CAD: 03erikgreenwald * r43618 10/brlcad/trunk/ (3 files in 2 dirs): revive the actual min/max (amin/amax) |
| 13:14.12 | brlcad | starseeker: zombie is back to life: https://sourceforge.net/tracker/?func=detail&atid=640802&aid=3197208&group_id=105292 |
| 13:18.13 | CIA-77 | BRL-CAD: 03starseeker * r43619 10/brlcad/branches/cmake/src/conv/iges/CMakeLists.txt: Use BRLCAD_ADDEXEC for iges |
| 13:21.06 | CIA-77 | BRL-CAD: 03starseeker * r43620 10/brlcad/trunk/src/conv/iges/ (conv_drawings.c trimsurf.c): initializations for iges |
| 13:21.18 | starseeker | brlcad: oh god |
| 13:21.22 | starseeker | ok, I'll have a look |
| 13:26.51 | CIA-77 | BRL-CAD: 03starseeker * r43621 10/brlcad/trunk/src/librtserver/rtserverTest.c: Quell a few warnings - rts_clean doesn't seem to be defined anywhere |
| 13:31.56 | CIA-77 | BRL-CAD: 03starseeker * r43622 10/brlcad/trunk/src/anim/anim_hardtrack.c: initializations for anim |
| 13:32.09 | CIA-77 | BRL-CAD: 03erikgreenwald * r43623 10/brlcad/trunk/src/librt/primitives/bot/btg.c: woops, point_t, not TIE_3 |
| 13:36.36 | CIA-77 | BRL-CAD: 03starseeker * r43624 10/brlcad/trunk/src/burst/grid.c: initialization for burst |
| 13:37.56 | CIA-77 | BRL-CAD: 03erikgreenwald * r43625 10/brlcad/trunk/include/raytrace.h: set RT_DEFAULT_MINTIE to 0 (disabled) |
| 13:41.46 | CIA-77 | BRL-CAD: 03starseeker * r43626 10/brlcad/trunk/src/fbed/fbed.c: initializations for fbed |
| 13:42.25 | brlcad | wishes one of his compilation environments would have picked up those warnings |
| 13:42.54 | CIA-77 | BRL-CAD: 03starseeker * r43627 10/brlcad/trunk/src/gtools/remapid.c: initialization for remapid |
| 13:46.12 | CIA-77 | BRL-CAD: 03starseeker * r43628 10/brlcad/trunk/src/shapes/picket_fence.c: initialize matrix |
| 13:48.45 | CIA-77 | BRL-CAD: 03starseeker * r43629 10/brlcad/trunk/src/util/pixborder.c: initialize for pixborder |
| 13:49.14 | starseeker | finally. there we go |
| 13:50.18 | brlcad | ~starseeker++ |
| 13:50.23 | brlcad | thanks |
| 13:50.53 | starseeker | dingnabbit. red problem confirmed |
| 13:55.11 | CIA-77 | BRL-CAD: 03starseeker * r43630 10/brlcad/branches/cmake/CMakeLists.txt: Don't care about warnings on the time delta utilties |
| 13:57.15 | starseeker | brlcad: interesting thing about those warnings - they popped up only when I did a release build - optimizations flags, etc |
| 13:57.31 | starseeker | (well, some of them) |
| 13:59.35 | ``Erik | um, lots of funky things go on depending on debug.. like 'HIDDEN' is "" on debug and "static" in release, etc |
| 14:03.25 | starseeker | actually, cancel that - red problem is NOT confirmed, with one possible exception |
| 14:03.36 | starseeker | you can't rename the region during a red command |
| 14:03.43 | starseeker | other than that, I have success using it here |
| 14:05.43 | starseeker | IIRC, I decided not to allow changing the object name during a red - it complicated things a bit |
| 14:07.08 | brlcad | starseeker: heh, I just saw yesterday's commit -- didn't realize that you just deleted all of those variables :) |
| 14:07.53 | ``Erik | scrum ~1300 |
| 14:07.59 | ``Erik | er, ~1330 |
| 14:08.07 | brlcad | if it can't be changed, it should probably not be in the file ... or it should allow it ;) |
| 14:08.27 | brlcad | otherwise people are going to try |
| 14:08.51 | brlcad | shouldn't be too hard to allow, just keep a copy before and after |
| 14:08.59 | starseeker | ugh |
| 14:09.00 | brlcad | apply edits to old, and if name changed, rename |
| 14:10.26 | brlcad | interesting approach to search "." .. I think I like it |
| 14:18.54 | starseeker | brlcad: adding renaming support will take a little time - is that something you want prior to release? |
| 14:22.37 | starseeker | brlcad: if you decide search looks good we can nuke the TODO item for that particular tweak and update NEWS - I was waiting until I was sure it was "done" |
| 14:25.07 | starseeker | saddles up |
| 14:40.55 | brlcad | starseeker: if it works, then that's stable for release -- but would you follow up with tom to see if that's what he was running into? |
| 14:41.45 | brlcad | the search todo is my action to look at since I had that particular request |
| 15:37.06 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 15:38.17 | CIA-77 | BRL-CAD: 03tbrowder2 * r43631 10/brlcad/trunk/src/tab/script.l: eliminate unused function warning |
| 15:55.28 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:33.41 | starseeker | brlcad: I thought I emailed him for more details, but I see it didn't pop up... |
| 16:34.29 | starseeker | huh - sent over 2 hours ago |
| 16:43.04 | CIA-77 | BRL-CAD: 03starseeker * r43632 10/brlcad/branches/cmake/ (21 files in 17 dirs): MFC -r43631 |
| 16:46.58 | CIA-77 | BRL-CAD: 03starseeker * r43633 10/brlcad/branches/cmake/CMakeLists.txt: Lovely - check cmake version before we set CMP0017 |
| 16:55.18 | starseeker | heh: http://spacewar.oversigma.com/ |
| 16:55.47 | starseeker | also http://spacewar.oversigma.com/html5/ |
| 16:56.30 | starseeker | ``Erik: whadya think, original BRL-CAD on a PDP1 emulator in html5? :-P |
| 17:00.45 | ``Erik | I don't think it ever ran on a pdp1... mebbe an 11/70, though it might need a vax11/780 by the time it did anything interesting |
| 17:01.09 | ``Erik | um, jove appeared in the repo in '83, then mid 85 is when really basic raytracing started happening |
| 17:02.00 | ``Erik | the date flag to svn up makes for some amusing code spelunking if ya find yourself with a bit of free time :D |
| 17:03.48 | starseeker | heh |
| 17:08.12 | CIA-77 | BRL-CAD: 03brlcad * r43634 10/brlcad/trunk/src/librt/primitives/nmg/nmg_plot.c: use VINIT_ZERO macro symbol instead of {0.0, 0.0, 0.0} for point_t/vect_t. less error-prone, less typing, and supports converion to fixed point arithmetic down the road. |
| 17:08.39 | starseeker | brlcad: oops, sorry - there'll be a few of those |
| 17:09.13 | CIA-77 | BRL-CAD: 03brlcad * r43635 10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: same with HINIT_ZERO for 4D vector initialization. |
| 17:43.32 | CIA-77 | BRL-CAD: 03erikgreenwald * r43636 10/brlcad/trunk/src/librt/primitives/bot/btg.c: rewrite prep to be correct and only make one tie_push call |
| 18:26.59 | CIA-77 | BRL-CAD: 03erikgreenwald * r43637 10/brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c: reincorporate some of the lost changes |
| 21:23.41 | CIA-77 | BRL-CAD: 03starseeker * r43638 10/brlcad/branches/cmake/src/mged/points/CMakeLists.txt: Ugh. Go vanilla with the cflags in points dir until it's clear what the issue is |
| 21:57.55 | starseeker | hmm http://www.research.ibm.com/haifa/projects/verification/fpgen/papers/plsrange.pdf |
| 22:02.19 | starseeker | http://portal.acm.org/citation.cfm?id=1048200 |
| 22:03.19 | starseeker | maybe we can recruit this guy :-) http://johnsogg.blogspot.com/2011_01_01_archive.html |
| 22:16.12 | starseeker | http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.112.3073 |
| 22:18.41 | starseeker | http://code.google.com/p/sketchsolve/ |
| 22:28.59 | starseeker | hah, cool - not related directly to geometric constrants but possibly useful for other things: http://adaptagrams.sourceforge.net/ |
| 22:38.04 | starseeker | reflects that the constraint system is going to require some paper diving... |
| 22:42.20 | starseeker | hmm http://www.cs.purdue.edu/homes/cmh/electrobook/intro.html |
| 23:16.50 | CIA-77 | BRL-CAD: 03starseeker * r43639 10/brlcad/branches/cmake/src/conv/step/CMakeLists.txt: Use BRLCAD_ADDEXEC for step-g |
| 23:17.47 | CIA-77 | BRL-CAD: 03starseeker * r43640 10/brlcad/branches/cmake/src/libpc/CMakeLists.txt: Yes boost, we know, be quiet already |
| 23:21.03 | CIA-77 | BRL-CAD: 03starseeker * r43641 10/brlcad/branches/cmake/ (5 files in 3 dirs): |
| 23:21.03 | CIA-77 | BRL-CAD: Rework handling of compile flags - no longer setting strict flags at the |
| 23:21.03 | CIA-77 | BRL-CAD: individual target levels, since BRL-CAD is going fully strict. There are a few |
| 23:21.03 | CIA-77 | BRL-CAD: local overrides for issues not yet resolved, but the default will now be that |
| 23:21.03 | CIA-77 | BRL-CAD: anything new automatically gets the struct flags with all warnings unless |
| 23:21.03 | CIA-77 | BRL-CAD: options are turned off. |
| 23:25.29 | CIA-77 | BRL-CAD: 03starseeker * r43642 10/brlcad/branches/cmake/misc/CMake/test_srcs/time.c.in: Add the zero for day, not just month. |
| 23:59.25 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 00:16.22 | CIA-77 | BRL-CAD: 03starseeker * r43643 10/brlcad/trunk/src/libged/combmem.c: Do some initializations for combmem.c, but it's not enough - getting some more of the weird complaints that identify line numbers that don't seem directly related to uninitialized aetvec and tvec |
| 00:21.50 | CIA-77 | BRL-CAD: 03starseeker * r43644 10/brlcad/trunk/src/libged/combmem.c: This does it - init 'em all |
| 00:32.38 | CIA-77 | BRL-CAD: 03starseeker * r43645 10/brlcad/branches/cmake/src/ (5 files in 3 dirs): MFC r43644 |
| 01:28.27 | CIA-77 | BRL-CAD: 03starseeker * r43646 10/brlcad/trunk/ (include/raytrace.h src/libged/search.c src/librt/search.c): Move the unique object logic out of libged into a librt function. renaming and cleanup for clarity, more comments in raytrace.h header. |
| 01:31.22 | CIA-77 | BRL-CAD: 03starseeker * r43647 10/brlcad/branches/cmake/ (include/raytrace.h src/libged/search.c src/librt/search.c): MFC r43646 |
| 01:38.17 | CIA-77 | BRL-CAD: 03starseeker * r43648 10/geomcore/trunk/tests/svntest/main.c: Start laying out the search plan for svn geometry testing. |
| 02:05.27 | CIA-77 | BRL-CAD: 03starseeker * r43649 10/brlcad/trunk/src/ (libged/search.c librt/search.c): Shift responsibility for making the default toplevel list of objects to librt from libged - this is sensible default behavior and will save doing this every time search logic is used to search the whole database. |
| 02:06.54 | CIA-77 | BRL-CAD: 03starseeker * r43650 10/brlcad/branches/cmake/src/ (libged/search.c librt/search.c): MFC r43649 |
| 02:08.06 | CIA-77 | BRL-CAD: 03starseeker * r43651 10/geomcore/trunk/tests/svntest/main.c: tweak plan - search should iterate over everything by default now. |
| 02:34.59 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 06:26.48 | *** join/#brlcad Stattrav (~Stattrav@122.172.12.71) | |
| 06:26.49 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:57.01 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 09:49.48 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 09:49.49 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202) | |
| 10:20.45 | CIA-77 | BRL-CAD: 03d_rossberg * r43652 10/brlcad/trunk/ (4 files in 4 dirs): |
| 10:20.45 | CIA-77 | BRL-CAD: fixed release 43577 changes "back to not needing libregex search dir" |
| 10:20.45 | CIA-77 | BRL-CAD: - re-enabled the libregex build |
| 10:20.45 | CIA-77 | BRL-CAD: - removed the unnecessary libregex search dirs |
| 11:51.31 | CIA-77 | BRL-CAD: 03starseeker * r43653 10/brlcad/branches/cmake/CMakeLists.txt: VERSION_GREATER, not GREATER |
| 11:58.45 | CIA-77 | BRL-CAD: 03starseeker * r43654 10/brlcad/branches/cmake/misc/CMake/test_srcs/builddelta_end.c.in: do something with fscanf return to quiet compiler. |
| 12:11.33 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 12:11.33 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202) | |
| 12:11.43 | CIA-77 | BRL-CAD: 03starseeker * r43656 10/brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c: whoops, that should have been in trunk - init min and max |
| 12:14.37 | CIA-77 | BRL-CAD: 03starseeker * r43657 10/brlcad/trunk/include/raytrace.h: comment tweak |
| 12:40.55 | CIA-77 | BRL-CAD: 03starseeker * r43658 10/brlcad/branches/cmake/ (. include/raytrace.h): fix comment in cmake too |
| 12:59.55 | CIA-77 | BRL-CAD: 03starseeker * r43659 10/brlcad/trunk/ (include/raytrace.h src/libged/search.c src/librt/search.c): Ah, that's better - don't wipe out the path name list passed to the search functions - that's the responsibility of the function that created the list. provide db_free_full_path_list to make that easier. |
| 13:00.40 | CIA-77 | BRL-CAD: 03starseeker * r43660 10/brlcad/branches/cmake/ (include/raytrace.h src/libged/search.c src/librt/search.c): MFC r43659 |
| 14:09.45 | brlcad | MISSING from src/librt/CMakeLists.txt: search.c |
| 14:09.45 | brlcad | NEED TO SYNC CMAKELISTS.TXT |
| 14:10.09 | starseeker | once sec... |
| 14:10.16 | starseeker | updates local autotools branch |
| 14:11.49 | CIA-77 | BRL-CAD: 03starseeker * r43661 10/brlcad/trunk/src/librt/CMakeLists.txt: Sync autotools branch CMakeLists.txt file |
| 14:11.54 | starseeker | there we go |
| 14:19.50 | ``Erik | ponders removing strict from tab since script.c complains on both osX.6 and fbsd :/ |
| 14:24.14 | brlcad | holy shit that's a lot of "lost changes" erik .. heh |
| 14:24.38 | brlcad | some of it is ws, but a lot not |
| 14:26.45 | ``Erik | yeah, it was a merge from trunk that stomped stuff, unfortunately :/ |
| 14:28.07 | brlcad | cool, retesting |
| 14:28.16 | starseeker | needs to try compiling d_rossberg's CMake stuff to figure out what it is/does, and see if it can be made to do that with cmake branch files - if it can, the new CMake logic can be moved to trunk (even if it doesn't get enabled as the default system) |
| 14:28.30 | brlcad | starseeker: r43630 .. heh, there are warnings that were that bad in time testing code that YOU wrote?? |
| 14:30.00 | brlcad | same reason they're maintenance burden for production code holds true for build system code too |
| 14:31.40 | brlcad | r43607 also isn't right, it's a hvect, not a vect, so VSETALL doesn't apply ([3] is the fourth H element) |
| 14:33.44 | starseeker | brlcad: keep reading :-) |
| 14:35.17 | starseeker | 43610 should fix 43607 |
| 14:36.45 | starseeker | and I fixed the compile warnings on those timing utilities - I took out all the warning flag suppression for them in one of the later commits |
| 14:38.07 | CIA-77 | BRL-CAD: 03brlcad * r43662 10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: pl is a plane_t, fix a couple places where it's being treated like it's a vect_t. |
| 14:43.33 | brlcad | I see, there were still other problems in that file |
| 14:43.50 | brlcad | one that wasn't immediately evident what [H] should be set to |
| 14:44.03 | starseeker | nods |
| 14:44.07 | starseeker | that is odd |
| 14:44.48 | starseeker | does some of that nmg code predate the establishment of the plane_t and vect_t types? |
| 14:45.13 | brlcad | not really |
| 14:45.26 | starseeker | sees if 7.18.2 builds... |
| 14:45.42 | starseeker | or r43153 anyhow |
| 14:45.49 | brlcad | the problem is probably more code evolution, someone coming in years later and thinking that a particular fastf_t * was one type vs another |
| 14:46.57 | brlcad | for a long while, some compilers did not like having vect_t or plane_t listed as parameters, wanted the untypedef'd type (fastf_t*) |
| 14:47.08 | brlcad | even today, I think some compilers still have a problem with it |
| 14:47.11 | brlcad | (gcc) |
| 14:47.24 | starseeker | huh |
| 14:47.46 | brlcad | ideally should change those pl parameters to be plane_t, and see who breaks |
| 14:48.04 | starseeker | probably after release? ;-) |
| 14:48.31 | brlcad | 43613 (-fPIC) is concerning up there with r43630 (-w on build infrastructure) |
| 14:49.03 | brlcad | probably, more like the next time someone is in that file making logic changes where it can be more carefully tested |
| 14:49.46 | starseeker | brlcad: 43613 is beyond my debug skills, at least without putting a lot of time into it |
| 14:50.07 | brlcad | fPIC isn't going to be valid for some compilers |
| 14:50.20 | brlcad | and doesn't make sense for static code regardless |
| 14:50.56 | brlcad | paste the (actual) compilation line and build failure |
| 14:51.09 | starseeker | I'll yank it - I primarily needed to get by it to do other stuff at the time |
| 14:51.28 | starseeker | build failure was posted earlier... |
| 14:51.43 | starseeker | I don't have the compilation line handy - it was only on my home gentoo box I saw the issue |
| 14:52.28 | brlcad | kind of one-liner tweak that gets ignored and is fine for a while, then bites someone years down the road taking days to debug and discover |
| 14:53.00 | brlcad | having some issue that's PIC/non-PIC related can be disastrous debugging for dynamic loading |
| 14:53.15 | CIA-77 | BRL-CAD: 03starseeker * r43663 10/brlcad/branches/cmake/src/librt/CMakeLists.txt: remove the fPIC flag for extrude.c |
| 14:55.55 | starseeker | brlcad: http://pastebin.mozilla.org/1122628 |
| 14:55.57 | starseeker | that's the error |
| 14:56.34 | brlcad | can you paste the whole log, from compile line to the end of the error? |
| 14:56.47 | starseeker | not right now - I can tonight |
| 14:57.01 | brlcad | k |
| 14:57.14 | brlcad | ahh, looks like it's out of date to, line numbers aren't matching up |
| 14:57.51 | starseeker | uh - that was one of the fun parts of the error - line numbers reported didn't seem to have anything to do with the variables that might be unitialized |
| 14:59.51 | brlcad | I mean the easy fix is to initialize all those vars it mentions |
| 14:59.58 | starseeker | ah |
| 14:59.59 | brlcad | if that's indeed the issue |
| 15:00.20 | brlcad | that might at least hone the warning to something else, leading towards the root cause |
| 15:00.56 | starseeker | let me see if a release build here can reproduce it... doubtful but you never know |
| 15:05.26 | CIA-77 | BRL-CAD: 03brlcad * r43664 10/brlcad/trunk/include/vmath.h: add missing V2INITALL and V2INIT_ZERO macros providing the 2D versions of VINITALL and VINIT_ZERO |
| 15:06.15 | CIA-77 | BRL-CAD: 03brlcad * r43665 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: initialize a few 2d vars to zero, just because we like it that way |
| 15:08.26 | starseeker | yeah, thought so - doesn't show up here |
| 15:08.40 | CIA-77 | BRL-CAD: 03erikgreenwald * r43666 10/brlcad/trunk/src/librt/primitives/bot/tie.c: reincorporate lost changes |
| 15:10.20 | CIA-77 | BRL-CAD: 03brlcad * r43667 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: slew of functions not marked static that should be static. make the compiler's job easier, those functions don't need to be exported. |
| 15:10.38 | brlcad | that will probably fix the failure between those changes |
| 15:10.48 | starseeker | brlcad: cool, thanks! |
| 15:19.32 | brlcad | yeah, reading through the code, it's looking like there might be some obscure way that they'd get called without initialization or the compiler was getting confused by sub-scope variables getting passed in as arguments to other functions that had parameters with the same name |
| 15:19.51 | brlcad | or it was cleverly following the call tree use and found some path of potential uninitialization |
| 15:20.30 | brlcad | either way, the "why" doesn't matter so much in this instance since we can simply initialize like it's saying we should without harm |
| 15:20.50 | starseeker | nods |
| 15:22.05 | CIA-77 | BRL-CAD: 03brlcad * r43668 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: init ra/rb to zero too, pull them back up to the top scope since they're double-declared in the same function. |
| 15:23.26 | CIA-77 | BRL-CAD: 03erikgreenwald * r43669 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: get_indices can't be static, it's also used in sketch |
| 15:23.48 | cjdevlin | any chance of a losethos <http://www.losethos.com/> port? |
| 15:26.24 | starseeker | cjdevlin: I'm guessing probably not |
| 15:26.37 | starseeker | never heard of it before - how did you come across it? |
| 15:27.25 | cjdevlin | i think i got a new release announcement on a mailing list i am on. it's . . . interesting |
| 15:27.48 | starseeker | it's intended for recreational programming, not "production" use |
| 15:28.31 | starseeker | http://www.losethos.com/doc/Constitution.html would seem to pretty much rule it out as a worthwhile platform to port to |
| 15:28.33 | cjdevlin | he created a custom version of c . . . i don't think anything will be ported to this ever . . . |
| 15:30.23 | starseeker | Haiku is a lot more interesting, but someone(tm) would have to get Tk ported to their graphics system |
| 15:31.56 | starseeker | brlcad got (iirc) all the non-graphical components of BRL-CAD compiled on Haiku at one point, including tcl, but Tk is a whole 'nother animal |
| 15:32.05 | cjdevlin | haiku is the new beos right? |
| 15:34.12 | starseeker | pretty much |
| 15:40.57 | cjdevlin | who maintains the .debs on the brlcad site? |
| 15:40.59 | starseeker | winces thinking about a Haiku compile with the new flags... |
| 15:41.23 | starseeker | we've had some new work done on those recently... |
| 15:42.12 | starseeker | don't recall if we actually got new debs uploaded to sf - the only Debian based system I have is my laptop, and even there I compile... |
| 15:42.27 | *** join/#brlcad Stattrav (~Stattrav@117.202.27.184) | |
| 15:42.27 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:43.06 | cjdevlin | well, here's the motivation for me asking . . . i am trying to learn how to program. with some assistance from the people in this room i was able to get source compiled a few times. i figured working on just the packaging will be a way to get my feet wet. i am an ubuntu user, but ubuntu is basically debian. |
| 15:43.18 | cjdevlin | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=289632 |
| 15:43.33 | cjdevlin | and it seems like people have been trying to get it into debian for quite a while |
| 15:43.51 | starseeker | take a look in misc/debian |
| 15:45.14 | cjdevlin | i also don't want to step on toes or reinvent the wheel if someone is actively working on it |
| 15:45.15 | starseeker | ah, right - Jordi Sayol |
| 15:45.30 | starseeker | back in January |
| 15:45.54 | starseeker | most recent commit was actually 2/28, so fair to say he's active :-) |
| 15:46.22 | cjdevlin | does he spend much time here? |
| 15:46.27 | brlcad | cjdevlin: chances are greatly increased if you attempt the port ;) |
| 15:48.16 | cjdevlin | brlcad: well then, based on my current working knowledge of programming and the graphics libraries available on the target platform: expect commits around 2020 (ish) :) |
| 15:49.05 | cjdevlin | brlcad the program is only what? a million lines of code? |
| 15:49.25 | CIA-77 | BRL-CAD: 03d_rossberg * r43670 10/brlcad/trunk/misc/win32-msvc/Dll/BrlcadCore.def: export rt_bot_mintie() for nirt |
| 15:49.53 | starseeker | brlcad: I tried compiling 43153 on Redhat and can't reproduce it |
| 15:51.21 | brlcad | cjdevlin: approximately, yep |
| 15:51.38 | brlcad | twice that if you count all our dependenceis |
| 15:52.07 | brlcad | this losethos guy is pretty awesome |
| 15:52.09 | brlcad | hilarious |
| 15:52.34 | starseeker | ah HAH! |
| 15:52.39 | starseeker | system regex doesn't work |
| 15:53.09 | cjdevlin | brlcad: isn't 2million the lines of code that run (ran) Jurassic Park :) ? |
| 15:53.46 | cjdevlin | he's been working on it full time for more than 7 years . . . |
| 16:00.14 | starseeker | blinks |
| 16:00.20 | starseeker | system regex works with trunk?? |
| 16:03.06 | brlcad | define "works"? |
| 16:03.20 | brlcad | should work.. |
| 16:04.10 | starseeker | yes, but that looks like the change - 7.18.2 failed with system, trunk succeeds |
| 16:05.21 | brlcad | so the good news is 7.18.2 binaries might not be working if they're enable all, but an enable all build should work for .2 and trunk |
| 16:05.38 | brlcad | er, if they're NOT enable all |
| 16:06.11 | starseeker | right |
| 16:06.13 | brlcad | that begs the question why system regex would fail -- perhaps a non-portable regex expression being used |
| 16:06.25 | brlcad | red/ted use regex? |
| 16:06.32 | starseeker | I am using some features only supported by newer regex installs |
| 16:06.34 | starseeker | yes |
| 16:06.40 | starseeker | red does anyway |
| 16:07.05 | brlcad | that should be easy to fix then |
| 16:07.27 | starseeker | uh, define fix... |
| 16:07.41 | brlcad | finds the expressions |
| 16:08.01 | starseeker | the part that's throwing me is it succeeds in trunk |
| 16:08.05 | brlcad | there's no "new" regex feature that isn't supported by older regex in another form |
| 16:08.18 | brlcad | yeah, that's interesting |
| 16:08.31 | brlcad | if trunk succeeds with system regex, then maybe a red herring |
| 16:08.42 | starseeker | wait, let me try trunk autotools |
| 16:08.43 | brlcad | coincidental, but not the problem |
| 16:08.49 | starseeker | right |
| 16:08.59 | _psilva | ugh.. cant login to 'new' account.. i left large corporations to avoid this crap :( |
| 16:09.15 | brlcad | and then got bought out by one |
| 16:09.26 | _psilva | cries |
| 16:09.45 | brlcad | president was a pussy? sold out? |
| 16:10.02 | _psilva | he wanted his millions? |
| 16:10.03 | _psilva | heh |
| 16:10.25 | _psilva | flash needs to be replaced ;) |
| 16:11.05 | brlcad | join the html5 committee? |
| 16:11.15 | _psilva | we'll see |
| 16:11.58 | _psilva | bunch of flash 'experts' are moving to html5 |
| 16:12.13 | _psilva | and are implementing similar constructs via js/canvas |
| 16:12.19 | brlcad | this Terry Davis losethos guy is pretty funny, wonder how he had so much time to dedicate to something like that |
| 16:13.02 | brlcad | classic hacking, for just the hell of it all on his own from scratch |
| 16:13.42 | brlcad | random custom constructs, caveats, and inconsisties all over the place, but fun nontheless |
| 16:14.12 | _psilva | what's this? |
| 16:14.15 | cjdevlin | it has a cool flight sim though |
| 16:14.32 | brlcad | _psilva: dude that wrote his own OS http://www.losethos.com/ |
| 16:14.47 | brlcad | not general purpose, just for fun |
| 16:14.49 | _psilva | ah |
| 16:15.07 | brlcad | the "command line" is actually a C-variant live interpreter |
| 16:15.26 | _psilva | we had quite a time dealing with the creator of atheos, who's working at funcom atm |
| 16:16.44 | _psilva | wow that's a lot of effort |
| 16:17.15 | cjdevlin | it seems like you guys are maintaining both autotools and cmake? mind if i ask why? (purely a personal info question, not trying to start an argument) |
| 16:17.18 | brlcad | all three videos are pretty intersting |
| 16:17.36 | brlcad | cjdevlin: we're migrating to cmake, but autotools is the oldstay until we switch |
| 16:17.53 | brlcad | years went into autotools, so it's pretty lock solid, but cmake is the new coke |
| 16:18.23 | cjdevlin | helps the cross platform effort also? |
| 16:18.30 | brlcad | that's the main motivation |
| 16:18.51 | _psilva | did u ever make a new gui for brlcad? |
| 16:19.00 | brlcad | getting a unified build that'll span linux, mac, other unices, AND windows .. which has been the lone child out |
| 16:19.14 | brlcad | _psilva: two of them, but both still under development |
| 16:19.21 | _psilva | screens? |
| 16:19.35 | brlcad | archer is about to go into alpha |
| 16:19.36 | brlcad | http://brlcad.org/tmp/archer.png |
| 16:20.11 | starseeker | if I got that right, r43400 seems to work with system regex |
| 16:20.19 | _psilva | interesting.. tcl? |
| 16:20.29 | brlcad | http://brlcad.org/~starseeker/archer_latest.png |
| 16:20.37 | brlcad | http://brlcad.org/~starseeker/archer_ronja1.png |
| 16:21.40 | brlcad | _psilva: yeah, archer is .. the "3rd gen" one isn't, but the screenshots are more simple -- pre-pre alpha |
| 16:22.49 | _psilva | archer looks nice |
| 16:22.56 | _psilva | better than what i remember |
| 16:23.07 | _psilva | any info on the 3rd gen ui? |
| 16:23.12 | brlcad | _psilva: most of the time has been spent implementing support for NURBS and STEP, library and source code refactoring, and the Geometry Service |
| 16:23.55 | brlcad | most of the GUI things you'd want require robust NURBS support, CSG evaluation of NURBS, and reliable fast surface tessellation |
| 16:24.19 | brlcad | so the focus has been on NURBS more than the GUI itself, so we can still have verifiable CAD constructs |
| 16:24.29 | _psilva | ic |
| 16:24.55 | brlcad | some screenies of 3rd gen at http://brlcad.org/wiki/User:Ralith |
| 16:25.50 | brlcad | the screenie at the bottom actually has an embedded mged command interpreter, input bindings mimicing mged, blender, and a game controller |
| 16:26.04 | _psilva | cool |
| 16:26.10 | brlcad | otherwise, mostly basic infrastructure |
| 16:29.13 | cjdevlin | was the unix/linux version done in gtk? and now you are writing a new gui in Qt? |
| 16:29.31 | starseeker | original gui work was in Tk |
| 16:29.44 | starseeker | new effort uses a combination of Qt and Ogre |
| 16:38.53 | starseeker | 43200 exhibits the failure... |
| 16:55.11 | starseeker | 43310 works... |
| 16:56.42 | *** join/#brlcad tofu_ (~sean@BZ.BZFLAG.BZ) | |
| 16:56.50 | *** join/#brlcad yukonbob1 (~bch@20-144.wireless.kamloops.net) | |
| 17:01.04 | *** join/#brlcad alex_jon1 (~alex_joni@81.196.65.201) | |
| 17:05.44 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 17:23.49 | starseeker | ok, 43213 exhibits the failure |
| 17:35.46 | starseeker | hah, cool: http://prod.nais.nasa.gov/eps/eps_data/137203-SOL-001-005.pdf |
| 17:39.24 | *** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ) | |
| 17:40.49 | *** join/#brlcad kanzure_ (~kanzure@131.252.130.248) | |
| 17:41.08 | starseeker | even cooler: http://simplesat.gsfc.nasa.gov/drawings.html |
| 17:47.24 | starseeker | wonder if there are public cad drawings for that simplesat... |
| 17:51.36 | alex_joni | starseeker: nice :) |
| 17:55.31 | starseeker | not a drawing itself, but possibly interesting as a source of layout conventions: http://mscweb.gsfc.nasa.gov/543web/files/GSFC-X-673-64-1F.pdf |
| 17:57.04 | starseeker | 43214 fails... |
| 18:02.04 | alex_joni | heh, if I would have followed that doc I probably would have never finished with my design :) |
| 18:06.27 | starseeker | hmm... http://hesperia.gsfc.nasa.gov/hessi/reference/drawings/hessi10_26_99%20Archive/ |
| 18:06.37 | alex_joni | starseeker: http://juve.ro/blog-files/projects/01298803577/steadycam.pdf |
| 18:07.11 | *** join/#brlcad epileg (~epileg@188.119.210.222) | |
| 18:07.11 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 18:16.53 | starseeker | alex_joni: hah, cool! |
| 18:16.53 | starseeker | what license is the model? |
| 18:16.56 | starseeker | looks like it might be a solid model? http://juve.ro/blog/projects/01298803577 |
| 18:16.57 | starseeker | 43216 fails... |
| 18:26.47 | *** join/#brlcad tofu_ (~sean@BZ.BZFLAG.BZ) | |
| 18:29.25 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 18:32.08 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 18:39.39 | starseeker | 43235 fails |
| 18:39.48 | starseeker | gets lunch |
| 18:58.22 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 19:00.51 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 19:13.27 | alex_joni | starseeker: haven't decided on the license yet, but something open |
| 19:19.04 | alex_joni | not even sure what licenses are aplicable to solid models and cad drawings |
| 19:28.50 | starseeker | usually I see creative commons |
| 19:29.01 | starseeker | (see openmoko for an example) |
| 19:44.38 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 20:31.34 | CIA-77 | BRL-CAD: 03starseeker * r43671 10/brlcad/trunk/TODO: The reported red failure was due to disabling compile of local regex, resulting in interference from tcl regex. After commit 43259, this is no longer occurring and proper behavior is restored. |
| 20:51.29 | CIA-77 | BRL-CAD: 03starseeker * r43672 10/brlcad/branches/cmake/ (5 files in 5 dirs): MFC r43671 |
| 20:59.40 | CIA-77 | BRL-CAD: 03erikgreenwald * r43673 10/brlcad/trunk/src/librt/primitives/bot/tie.c: indent |
| 21:11.19 | CIA-77 | BRL-CAD: 03erikgreenwald * r43674 10/brlcad/trunk/src/librt/primitives/bot/ (tie_kdtree.c tieprivate.h): de-magic the haschildren/leafnode bit and comment some on bitpacking |
| 21:11.59 | alex_joni | starseeker: sounds good |
| 21:25.34 | CIA-77 | BRL-CAD: 03starseeker * r43675 10/geomcore/trunk/src/other/subversion/other/apr-util/xml/expat/Makefile.in: Looks like a Makefile.in got ignored. |
| 21:35.52 | CIA-77 | BRL-CAD: 03erikgreenwald * r43676 10/brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c: check alignment on kd nodes |
| 21:40.40 | *** join/#brlcad vtts (~vytautas@diz.ktu.lt) | |
| 21:44.51 | vtts | hi, is such problem known on mac os x? http://pastie.org/1630246 |
| 21:45.47 | CIA-77 | BRL-CAD: 03starseeker * r43677 10/geomcore/trunk/src/other/subversion/other/apr-util/ (87 files in 15 dirs): Sync apr-util directory with apr-util-1.3.10 |
| 21:56.11 | CIA-77 | BRL-CAD: 03starseeker * r43678 10/geomcore/trunk/src/other/subversion/ (CMake/ThirdParty.cmake CMakeLists.txt): third party build logic ain't happy - get closer, but this won't be enough |
| 22:31.03 | starseeker | vtts: yow. Is that with OpenGL enabled? |
| 22:33.26 | vtts | agl |
| 22:36.15 | starseeker | uh... we don't use agl yet - we work with X11 opengl on the mac |
| 22:36.47 | vtts | ok then, I'll try skipping OpenGL and see if it works |
| 22:36.59 | alex_joni | starseeker: now with license info: http://juve.ro/blog/projects/01298803577 |
| 22:37.11 | starseeker | not sure if that'll do anything, but worth a try... that's a pretty new version of OSX |
| 22:37.54 | starseeker | alex_joni: cool! what cad system are you modeling in? |
| 22:38.01 | alex_joni | I'll put the solid up in a couple days (when I get a round-tuit) |
| 22:38.04 | alex_joni | starseeker: alibre |
| 22:38.17 | starseeker | does it export to step? (drool...) |
| 22:38.21 | alex_joni | yes |
| 22:38.34 | starseeker | awesome |
| 22:39.02 | alex_joni | I found it very nice/cheap (about 2k for the expert version which does CAE, CAM, unlimited everythings, etc) |
| 22:39.22 | alex_joni | limited CAM though.. |
| 22:39.27 | starseeker | nods |
| 22:39.38 | starseeker | hey, if it works it works |
| 22:39.40 | alex_joni | right |
| 22:39.48 | alex_joni | "only" 2.5D and 3D |
| 22:40.09 | alex_joni | anyways, I used SW a bit before this, and Inventor |
| 22:40.20 | alex_joni | but I like alibre better, and it's less than half the price |
| 22:40.31 | starseeker | wonder what engine they're using |
| 22:40.39 | alex_joni | oh, did I mention you get 5 seats for that price? |
| 22:41.09 | starseeker | heh - amazing. A far cry from the $30,000 per set licensing (back when that was real money) |
| 22:41.23 | alex_joni | heh |
| 22:41.50 | alex_joni | they use step as the internal datatype |
| 22:41.57 | alex_joni | some step variant anyways |
| 22:42.03 | starseeker | sweet |
| 22:44.34 | alex_joni | they used to have a limited free version |
| 22:44.45 | alex_joni | now it's 99$/seat for the personal version |
| 22:45.02 | starseeker | nods - lot like Mathematica in that respect |
| 22:45.11 | starseeker | suck in the students, then *wham* |
| 22:46.02 | starseeker | always preferred the open solutions, even if they weren't as full-featured/glitzy, but sometimes you need the functionality (especially for "real work") |
| 22:46.46 | alex_joni | yeah, I know.. |
| 22:47.02 | alex_joni | well.. there's Octave out there ;) |
| 22:47.34 | starseeker | :-). That's the Matlab-alike - for phyics (my undergrad) Maxima was the major player |
| 22:47.50 | starseeker | Axiom later made an appearance, and then Reduce as well |
| 22:48.05 | alex_joni | ah right, was thinking of Matlab |
| 22:50.41 | brlcad | vtts: opengl is fine, but you have to enable compilation of tcl/tk (--enable-all) |
| 22:50.59 | alex_joni | starseeker: step 203 / step 214 ? |
| 22:51.00 | brlcad | the system tk on 10.6 is compatible, but will crash because we assume an X11 binding |
| 22:51.14 | brlcad | 203 at the moment |
| 22:51.20 | starseeker | alex_joni: I believe 203, but if it's easy why not put up both? |
| 22:52.14 | starseeker | is a greedy sucker when it comes to test cases :-P |
| 22:53.08 | alex_joni | coming up in a sec |
| 22:54.13 | alex_joni | I can also export ACIS and parasolid (x_t) |
| 22:54.23 | alex_joni | if those are valid test cases let me know |
| 22:54.42 | starseeker | urm. Interesting, but I don't know if those formats are documented? |
| 22:55.08 | brlcad | sure, why not -- x_t would be useful |
| 22:55.22 | brlcad | it's a text-based format, somewhat easy to parse |
| 22:55.37 | starseeker | they'd all be handy for "Rosetta stone" work if someone wanted to start figuring out the formats, but for now we've got all we can do to support the ones that are :-P |
| 22:55.46 | starseeker | having the same model in multiple formats is quite handy |
| 22:57.33 | starseeker | 's jaw hits the floor... |
| 22:59.10 | vtts | brlcad, make install fails if i enable tcl/tk :( |
| 22:59.12 | CIA-77 | BRL-CAD: 03starseeker * r43679 10/geomcore/trunk/tests/svntest/main.c: Commit svntest quick before it changes it's mind - got what appears to be a working assembly search. Not doing much intelligent with it yet, but that went surprisingly smooth. |
| 22:59.43 | alex_joni | ok, models uploaded |
| 23:00.57 | starseeker | alex_joni: awesome, thanks! |
| 23:02.12 | brlcad | vtts: what's the failure? |
| 23:03.09 | alex_joni | starseeker: let me know if you can open them |
| 23:08.26 | starseeker | oooh, wow - step-g doesn't like the 203 file |
| 23:09.23 | starseeker | excellent - good test case |
| 23:09.41 | alex_joni | heh |
| 23:10.52 | starseeker | actually is quite a good test - lots of objects, but not huge |
| 23:10.55 | alex_joni | well, good night all |
| 23:11.04 | starseeker | night, and thanks again! |
| 23:11.06 | alex_joni | has to get up early |
| 23:11.11 | starseeker | yuck |
| 23:11.25 | alex_joni | not _that_ early.. around 7am (early for me) |
| 23:11.45 | starseeker | heh - for me that's the dead zone - either 5am or 9am work |
| 23:12.03 | alex_joni | I'm more the 9am guy :) |
| 23:12.05 | vtts | brlcad, I didn't save it :(, will pastebin it tomorrow |
| 23:12.11 | alex_joni | but it's after 1am here.. so :/ |
| 23:12.19 | starseeker | alex_joni: cool, night! |
| 23:14.41 | starseeker | must head out too... |
| 01:36.29 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 03:00.15 | starseeker | brlcad: http://pastebin.mozilla.org/1124576 |
| 04:44.32 | brlcad | starseeker: thanks |
| 04:44.37 | brlcad | try with that fix |
| 04:44.44 | CIA-77 | BRL-CAD: 03brlcad * r43680 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: |
| 04:44.44 | CIA-77 | BRL-CAD: pull the declaration of center2d (and his friends) up to the top scope to make |
| 04:44.44 | CIA-77 | BRL-CAD: sure the warning reflects the current file state. preprocessor directive in |
| 04:44.44 | CIA-77 | BRL-CAD: that function was missing a semicolon, so perhaps that was confusing gcc? see |
| 04:44.44 | CIA-77 | BRL-CAD: if we still get an uninitialized use warning now that it's outside of the loop. |
| 04:44.52 | brlcad | I think I understand what it's detecting |
| 04:45.29 | brlcad | it is really obscure and apparently not without bugs if those line numbers are to be believed |
| 04:46.30 | brlcad | but the center2d var was declared inside a loop, which I believe is only initialized once, but not per iteration like one might expect so it's possibly warning based on the future use. |
| 04:47.08 | brlcad | the only thing unique about that function, however, was an inconsistent macro call, so still a little bit of a mystery |
| 04:47.26 | brlcad | that'd be a good one to see the post-preprocessor output being fed to gcc |
| 05:45.01 | *** join/#brlcad roberthl_ (~robert@v001.rhl.me.uk) | |
| 05:52.40 | brlcad | outstanding spelunking on the red failure, great to know exactly why it was failing but working with HEAD |
| 05:53.12 | brlcad | starseeker: so do you know which regex feature wasn't supported? |
| 05:54.02 | brlcad | curious how our regex worked and theirs didn't, because theirs is actually a never derivative |
| 05:54.16 | brlcad | unless if it's something like the regex enums don't match, hmm |
| 05:54.52 | brlcad | aha, yep that's it |
| 05:56.22 | brlcad | REG_NEWLINE is 300 for Tcl and 10 for ours |
| 05:56.28 | brlcad | REG_EXTENDED matches |
| 05:59.12 | brlcad | so that mystery is solved |
| 06:00.15 | brlcad | one take-home lesson to keep in mind for cmake is that it will have to make sure include directories are NOT listed if a src/other dep is not going to be compiled, otherwise that same type of problem can happen with any of them (png, libz, ..) |
| 06:54.44 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 06:58.14 | *** join/#brlcad Robert___ (~robert@v001.rhl.me.uk) | |
| 07:06.46 | vtts | any way to fix this? http://pastebin.com/rFeVqwHG |
| 07:07.51 | vtts | happens when I click on Edit -> Combination Editor |
| 07:09.12 | vtts | same goes for "Attribute Editor" and similar oneline error in command window for geometree command |
| 07:09.36 | vtts | (mac os x) |
| 07:12.33 | vtts | version from svn r43679 |
| 08:04.12 | *** join/#brlcad Stattrav (~Stattrav@122.172.12.71) | |
| 08:04.12 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:14.20 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 12:52.07 | starseeker | brlcad: is this what you need? http://bzflag.bz/~starseeker/extrude.preprocess |
| 12:52.24 | starseeker | (that's without applying you're latest fix) |
| 12:53.16 | starseeker | brlcad: as a rule, the include directory variables should do the right thing when a src/other dep is turned on or off |
| 12:53.20 | starseeker | (for cmake) |
| 12:53.46 | starseeker | that one is a particular problem because we can have the situation where regex is off and tcl is on |
| 12:54.20 | starseeker | (or was until the rename anyway) |
| 12:58.58 | starseeker | bah s/you're/your/ |
| 13:00.52 | starseeker | sweet - that last tweak to extrude looks like it got it |
| 13:00.56 | dloman | @anyone: How are tcl scripts 'automatically' loaded when mged launches? Aka, if I have a tcl script or two I'd like to put in a few of my scripts i've written and make them load whenever mged launches.... |
| 13:01.07 | starseeker | thanks for following that up brlcad - that was waaay out of my depth :-P |
| 13:01.35 | starseeker | uh... I think you can do that by putting source statements in .mgedrc? |
| 13:01.46 | dloman | righto, got that part |
| 13:02.03 | dloman | just with no user configging, aka 'its part of mged' |
| 13:02.49 | starseeker | uh... you'd have to stick them in one of the directories that libtclcad's autopath logic (or the system tcl/tk) know about and alter the pkgIndex.tcl file (I think?) |
| 13:03.07 | starseeker | take a look at what src/tclscripts files do |
| 13:03.36 | dloman | awesome, thanks. |
| 13:06.28 | starseeker | eyes the failure of toyjeep.g to convert with release flags turned on... http://pastebin.mozilla.org/1126164 |
| 13:06.51 | starseeker | that seems to happen ONLY when I turn on release build flags - with debug flags it succeeds |
| 13:09.01 | starseeker | is that another one specific to my system or has someone else seen it? |
| 13:14.13 | starseeker | this is the problem child: http://bzflag.bz/~starseeker/pipeproblem.asc |
| 13:20.45 | d_rossberg | starseeker: what do you mean with "convert"? |
| 13:27.25 | starseeker | asc2g |
| 13:32.37 | starseeker | d_rossberg: oh - have you had any chance to see if your particular cmake logic can work with the new cmake build? |
| 13:33.49 | d_rossberg | no, haven't tested yet |
| 13:34.17 | starseeker | hmm - maybe I'm wrong, asc2g failed with both builpes... |
| 13:35.07 | starseeker | d_rossberg: k. I'll try to take a look myself if I get a chance - that's the main hurdle for being able to move the CMake logic to trunk (even if we don't use it as the "default" build logic) |
| 13:35.54 | starseeker | s/builpes/both build configs/ |
| 13:37.31 | starseeker | here's a little more detail on the pipe failure: http://pastebin.mozilla.org/1126269 |
| 13:39.32 | starseeker | looks like VDOT is coming back with -1, which acos doesn't like... |
| 13:42.43 | d_rossberg | maybe it's -1.0000000..0001 ? |
| 13:44.19 | d_rossberg | btw, i'll update may brlcad cmake branch for a short code review ... |
| 13:48.43 | dloman | wow, 35 mins to svn up. that's just painful :/ |
| 13:50.52 | CIA-77 | BRL-CAD: 03starseeker * r43681 10/brlcad/branches/cmake/misc/CMake/test_srcs/timedelta_end.c.in: check fscanf here too to make compiler happy |
| 13:53.07 | starseeker | ah, good - just needed a clean build - still avoids erroring out with debug and does with release |
| 13:56.24 | starseeker | this is as much as I know currently: http://pastebin.mozilla.org/1126326 |
| 14:02.26 | starseeker | why is acos(-1) not happy... |
| 14:03.57 | starseeker | d_rossberg: you may be right... let's see... |
| 14:11.21 | starseeker | yep |
| 14:11.27 | starseeker | d_rossberg: thanks :-) |
| 14:11.33 | starseeker | now, what to do... |
| 14:15.44 | CIA-77 | BRL-CAD: 03starseeker * r43682 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: |
| 14:15.44 | CIA-77 | BRL-CAD: acos isn't happy if we go outside the domain -1,1 and it looks like floating |
| 14:15.44 | CIA-77 | BRL-CAD: point fuzz is taking us inside in some cases and out in others - peg it to -1 or |
| 14:15.44 | CIA-77 | BRL-CAD: 1 if we're within VUNITIZE_TOL to avoid uncertainty principle effects in |
| 14:15.44 | CIA-77 | BRL-CAD: conversion behavior |
| 14:16.58 | starseeker | actually, that may not be enough... |
| 14:18.36 | d_rossberg | starseeker: how about "angle = bn_pi - acos(min(1., max(-1., VDOT(v1, v2))));"? |
| 14:20.49 | ``Erik | or vmath's CLAMP() |
| 14:22.20 | starseeker | it's tricky, because we DO want pipes to fail the check if they really do define a pipe that's not within floating point fuzz of sane limits |
| 14:22.46 | starseeker | I'm just worried that borderline cases will still crop up... |
| 14:24.24 | starseeker | if the value is less than -1.0 + fuzz it should fail... but whether a particular value hits that threshold will vary from system to system... |
| 14:24.36 | starseeker | -1.0 - fuzz rather |
| 14:25.53 | starseeker | it's almost like if it starts straying into bad (fuzzy) territory we need to clamp not the VDOT result but the input geometry values themselves to keep them out of the danger zone |
| 14:27.21 | starseeker | but how do we do that? |
| 14:28.19 | d_rossberg | first you have to put meaningful values to acos() and tan() |
| 14:29.10 | d_rossberg | only if this was the case you may evaluate new_bend_dist |
| 14:30.03 | d_rossberg | and in my opinion the VDOT() problem is a double precision problem |
| 14:30.19 | d_rossberg | there you have to "help" a little bit |
| 14:32.22 | starseeker | I'm betting what happened was a modeler in mged pushed the pipe right to its limits, which worked on that system but not on another. We need another category of return value from the check which says "valid but dangerous" to keep the modeler in MGED from setting to that value but to allow existing geometry that already has the borderline values to work |
| 14:34.29 | brlcad | starseeker: yeah, that's what I would have needed wrt extrude.c |
| 14:39.48 | starseeker | uh... has somebody been monkeying with MGED mouse bindings? |
| 14:40.30 | starseeker | both left and right mouse buttons zoom in, and perspective is on whether I ask for it or not... |
| 14:41.53 | starseeker | needs to head in here... |
| 14:43.49 | brlcad | starseeker: yeah, I messed with mouse bindings recently because of that problem, but maybe didn't get it right |
| 14:44.07 | brlcad | let me know when you're stable to test a change |
| 14:45.39 | CIA-77 | BRL-CAD: 03brlcad * r43683 10/brlcad/trunk/TODO: report that comb editor isn't working and jeep conversion failure |
| 14:46.33 | starseeker | brlcad: go ahead - I'm done monkeying for the moment |
| 14:49.07 | starseeker | uh, pipe not torus (or are you seeing torus failures?) |
| 14:49.19 | brlcad | ups, right |
| 14:49.31 | brlcad | "torus bend" failure |
| 14:49.45 | starseeker | that change I made to pipe.c does work, but I don't know if it's "right" |
| 14:52.43 | starseeker | we need an "editing" check I think that is tighter than the import check, but will allow movement of settings towards safer directions |
| 14:54.55 | starseeker | in the case of an import that has settings meeting import tolerance (i.e. "this was valid on some system but is fuzzy/dodgy here") but not editing tolerance "on this system we don't want this value, but since we already have it don't fail" |
| 14:56.41 | starseeker | hits the road |
| 14:56.53 | d_rossberg | starseeker: you may move the cmake logic to trunk, the brlcad.dll won't work but it looks like it can be fixed with reasonable effort |
| 14:57.40 | d_rossberg | and don't bother the user with your numerical problems ;) |
| 14:58.16 | d_rossberg | prefer to solve the numerics to writing a dialog |
| 14:58.33 | starseeker | one last note - I dunno how reproducible it is, but perspective was on with the jeep in release build and off in debug build |
| 14:59.23 | d_rossberg | on my system (MSVC) acos() accepts invalid values, the result is a nan |
| 15:00.28 | d_rossberg | anyway, this kind of problem may arise always |
| 15:03.30 | d_rossberg | if you can not be sure that the result of VDOT() is between -1 and 1 (as the theory would say) _and_ acos() has a problem with it you have to test it |
| 15:15.29 | d_rossberg | btw, your test isn't optimal: e.g. local_vdot = -1.5 would still crash |
| 15:18.09 | brlcad | oops, there he goes :) |
| 15:22.19 | CIA-77 | BRL-CAD: 03bob1961 * r43684 10/brlcad/trunk/src/libtclcad/ged_obj.c: Fixed a problem with rect_mode that was causing an offset rectangle to be drawn. |
| 15:26.35 | *** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ) | |
| 15:26.36 | *** join/#brlcad starseek1r (~starseeke@BZ.BZFLAG.BZ) | |
| 15:28.02 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 15:39.27 | CIA-77 | BRL-CAD: 03brlcad * r43685 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: |
| 15:39.27 | CIA-77 | BRL-CAD: why there are custom blocks of code to unitize the vector instead of calling |
| 15:39.27 | CIA-77 | BRL-CAD: VUNITIZE() is curious and potentially related to the fuzzy instability. |
| 15:39.27 | CIA-77 | BRL-CAD: regardless, tweak the dot product result if it just barely over/under-shoots due |
| 15:39.27 | CIA-77 | BRL-CAD: to precision problems. using NEAR_ZERO/NEAR_EQUAL here isn't optimal since |
| 15:39.28 | CIA-77 | BRL-CAD: it'll clamp values already within the valid [1.0,-1.0] range to the limit of |
| 15:39.29 | CIA-77 | BRL-CAD: that range. |
| 15:40.26 | brlcad | d_rossberg: good point about the range, but the dot should be between 1,-1 since they're both unit vectors .. code just wasn't obvious that they were being unitized |
| 15:45.01 | CIA-77 | BRL-CAD: 03brlcad * r43686 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: still need the lengths of v1/v2 for subsequent input validation |
| 15:55.43 | d_rossberg | brlcad: if vdot > 1.0 => vdot = 1.0 and if vdot < -1.0 => vdot = -1.0 otherwise acos() may crash the program! |
| 15:57.04 | brlcad | they're already unit vectors so vdot shouldn't be more than fuzz, or you saying check it anyways because it may crash (e.g., if there is REALLY bad fuzz) |
| 15:57.21 | brlcad | works for me |
| 15:57.46 | d_rossberg | check it the simple way, you do not know for sure what "small" is |
| 16:00.13 | d_rossberg | otherwhise the code is hard to understand (why he checks for 1.0+VUNITIZE_TOL? what happens if vdot is >= 1.0+VUNITIZE_TOL?) |
| 16:01.20 | CIA-77 | BRL-CAD: 03brlcad * r43687 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: daniel has a good point, they're already unit so no harm saying anything outside of range is clamped to the range limit |
| 16:06.37 | CIA-77 | BRL-CAD: 03brlcad * r43688 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: um, call CLAMP() dummy |
| 16:09.42 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 16:18.35 | *** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ) | |
| 16:18.35 | *** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 16:18.35 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 16:18.35 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 16:18.36 | *** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ) | |
| 16:18.36 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 16:18.36 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 16:18.36 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 16:18.36 | *** join/#brlcad vtts (~vytautas@diz.ktu.lt) | |
| 16:18.36 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 16:18.36 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 16:18.36 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 16:18.36 | *** join/#brlcad kanzure_ (~kanzure@131.252.130.248) | |
| 16:18.36 | *** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no) | |
| 16:18.36 | *** join/#brlcad dtidrow_ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) | |
| 16:18.36 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 16:18.36 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 16:18.36 | *** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net) | |
| 16:18.36 | *** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ) | |
| 16:18.36 | *** join/#brlcad kanzure__ (~kanzure@bioinformatics.org) | |
| 16:18.36 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 16:18.36 | *** mode/#brlcad [+o ChanServ] by verne.freenode.net | |
| 16:19.59 | *** join/#brlcad WhiteCalf (MK@2607:f0d0:3001:68::2) | |
| 16:20.13 | *** join/#brlcad CIA-14 (~CIA@208.69.182.149) | |
| 16:22.13 | *** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) | |
| 16:22.39 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 16:30.01 | *** join/#brlcad starseek1r (~starseeke@BZ.BZFLAG.BZ) | |
| 16:30.01 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 16:30.01 | *** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) | |
| 16:30.01 | *** join/#brlcad CIA-14 (~CIA@208.69.182.149) | |
| 16:30.01 | *** join/#brlcad WhiteCalf (MK@2607:f0d0:3001:68::2) | |
| 16:30.01 | *** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ) | |
| 16:30.01 | *** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 16:30.01 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 16:30.01 | *** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ) | |
| 16:30.01 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 16:30.01 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 16:30.01 | *** join/#brlcad vtts (~vytautas@diz.ktu.lt) | |
| 16:30.01 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 16:30.01 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 16:30.01 | *** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no) | |
| 16:30.01 | *** join/#brlcad dtidrow_ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) | |
| 16:30.01 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 16:30.01 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 16:30.02 | *** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net) | |
| 16:30.02 | *** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ) | |
| 16:30.02 | *** join/#brlcad kanzure__ (~kanzure@bioinformatics.org) | |
| 16:30.02 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 16:30.02 | *** mode/#brlcad [+o ChanServ] by verne.freenode.net | |
| 16:42.00 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 16:45.19 | *** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ) | |
| 16:55.14 | *** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ) | |
| 17:05.01 | CIA-14 | BRL-CAD: 03brlcad * r43689 10/brlcad/trunk/TODO: torus bend pipe failure should be working now, needs one final test on the platform that had the float fail. |
| 17:36.21 | dloman | question about the tclIndex file: is that generated by something or do we/can we manually edit that (to add tcl scripts) ? |
| 17:37.29 | tofu | it's autogenerated |
| 17:38.43 | *** join/#brlcad ezzieyguywuf (~wolfie@cpe-071-070-255-232.nc.res.rr.com) | |
| 17:39.25 | ezzieyguywuf | how do I delete a shape after I have made it with in? I know I can remove it from the framebuffer thing with erase, but I want to get rid of it completely. |
| 17:39.50 | brlcad | dloman: if you delete the file, it'll get regenerated |
| 17:40.24 | brlcad | same for pkgIndex.tcl |
| 17:40.31 | dloman | kk, so how do i add a new tcl script then... just put the .tcl file into the src/tclscripts dir? |
| 17:40.52 | brlcad | depends on what the script is |
| 17:41.07 | brlcad | somewhere in the src/tclscripts hierarchy, but the routines are organized by purpose |
| 17:41.27 | dloman | i fixed the 'grouper' script (by request) so it now works with 7.18 |
| 17:41.52 | dloman | figured id finally put it in the repo |
| 17:42.13 | brlcad | that'd be the mged subdir then, or a subdir under there |
| 17:43.00 | dloman | kk. danke |
| 17:43.01 | brlcad | suggest reading a few of the other tcl files in here |
| 17:43.05 | brlcad | *there |
| 17:43.14 | brlcad | to make sure that it'll self-validate and load correctly |
| 17:45.05 | brlcad | src/tclscripts/mged/reid.tcl is a simple example of mged-command validation |
| 17:45.15 | ezzieyguywuf | waits |
| 17:45.34 | brlcad | solclick.tcl is another |
| 17:46.00 | brlcad | ezzieyguywuf: kill |
| 17:46.12 | ezzieyguywuf | brlcad: excellent thanks. |
| 17:46.16 | brlcad | the mged quick reference sheet lists all of the basic commands |
| 17:46.23 | brlcad | avail on the website under docs |
| 17:46.40 | ezzieyguywuf | bah, I should look at that. I was going through the docs in order, and I'm still on the tutorial thing. |
| 17:46.44 | ezzieyguywuf | Making a mug as we speak :-P |
| 17:47.00 | brlcad | excellent |
| 17:48.47 | ezzieyguywuf | incidentally, I have a sort of general question about brl-cad: is it a good replacement for, say, SolidWorks or Pro/E. i.e. will I be able to make solid model represenations of parts, put assemblies together, and generate drawings in a relatively quick manner (once I'm proficient of course)? |
| 17:50.10 | brlcad | ezzieyguywuf: you will be able to make solid model representations of parts, put assemblies together, and do so in a relatively quick manner once you ar proficient, but it does take some time and practice to become proficient |
| 17:50.25 | brlcad | wouldn't say any worse than sw or proe, but definitely different |
| 17:50.37 | brlcad | now drawing, though, are a different matter. |
| 17:50.58 | brlcad | you can generate drawings, but not with dimensioning information |
| 17:51.02 | brlcad | at least not yet |
| 17:51.08 | ezzieyguywuf | brlcad: is there perhaps a third-party program you would recommend for doing drawings? with dimensioning and tolerances etc. |
| 17:51.44 | brlcad | open source options are pretty limited, qcad comes to mind for 2D |
| 17:52.11 | ezzieyguywuf | hm, but in that case I'd have build the part from scratch anew? |
| 17:52.19 | brlcad | we're the next closest, but then annotations and dimensioning are still under development (my task for the upcoming month actually) |
| 17:52.58 | yukonbob_ | annotations ++ |
| 17:53.11 | ezzieyguywuf | interesting. Well, I plan on spending some time getting familiar and proficient with brl-cad (or whichever open source CAD package I settle on) before I try using it for any big projects. That will probably be a year + out. |
| 17:53.18 | brlcad | ezzieyguywuf: example of what you can get now: http://brlcad.org/gallery/s/renderings/havoc_rtedge.png.html |
| 17:53.32 | brlcad | run "rtedge" in mged (or outside of mged) and you'll get a hidden-line rendering |
| 17:54.23 | ezzieyguywuf | nice. But say I wanted to get that rapid-prototyped: could I export it into an appropriate file format for doing so? |
| 17:55.18 | ezzieyguywuf | obviously if it was a part I wanted to have machined, I would need a drawing. but if it was going to be machined on a C&C machine, I think those just take solid-model files as well. |
| 17:58.28 | brlcad | ezzieyguywuf: http://brlcad.org/tmp/converters_page23.jpg |
| 17:58.49 | brlcad | we've had things rapid-prototyped from our files before with relative ease |
| 17:58.58 | brlcad | it depends how well modeled the object is |
| 17:59.22 | brlcad | most of the rapid prototypers handle STL (or iges for some of the better ones) |
| 18:00.16 | starseek1r | ezzieyguywuf: if you can't run qcad (I don't think the free version ever got updated to Qt4) you might try the fork librecad |
| 18:00.24 | brlcad | facetizing a model is REALLY tricky business, only working without assistance about 85-95% of the time |
| 18:00.41 | brlcad | (most exporters require facetization) |
| 18:00.55 | ezzieyguywuf | hm, I see. |
| 18:01.17 | brlcad | note even packages like proe aren't 100%, they're around 90-95% |
| 18:01.23 | ezzieyguywuf | I use gnome as my graphical environment, and gentoo just pulls in w/e qt libs it needs when I install stuff, so I don't think qcad will be a problem. |
| 18:01.30 | ezzieyguywuf | are you familiar with free-cad? how does that stack up? |
| 18:02.32 | brlcad | decent project, leverages opencascade for nearly everything is actually useful .. but not something I'd consider useful for production work |
| 18:03.09 | ezzieyguywuf | hm I see. |
| 18:03.21 | brlcad | really depends on your specific use case and data, though |
| 18:03.30 | brlcad | they might have just enough to do what you need |
| 18:03.32 | ezzieyguywuf | well thank you for your time. I'll keep working through the tutorials, and see where that takes me as far as long-term brl-cad use. |
| 18:03.35 | brlcad | they're just really in their infanccy |
| 18:03.48 | brlcad | no problem |
| 18:04.01 | brlcad | feedback is definitely welcome as you work your way through |
| 18:04.05 | *** join/#brlcad ezzieyguywuf (~wolfie@unaffiliated/ezzieyguywuf) | |
| 18:04.24 | brlcad | if you run into a problem, folks are usually here to help |
| 18:05.42 | ezzieyguywuf | yea, well first bit of feedback would be that I've found some very minor discrepencies between the tutorial and the prog, i.e. the first time it tells you to do 'Edit >> Set H' it says "Hit Accept when you're done" but doesn't tell you that Accept is in the Edit menu :-P |
| 18:06.25 | brlcad | good point |
| 18:06.36 | brlcad | the "accept" command will also work |
| 18:09.00 | ezzieyguywuf | ah, good to know. |
| 18:09.56 | ezzieyguywuf | I'm kinda beating myself up for not taking notes on these discrepencies. Also when it mentions colors in the Combination Editor, you have to first click on Show Shader to get that option. |
| 18:11.24 | CIA-14 | BRL-CAD: 03brlcad * r43690 10/brlcad/trunk/doc/docbook/lessons/en/ (mged06_creating_a_goblet.xml mged09_globe_in_display_box.xml): apply suggestion from ezzieyguywuf to make sure we refer to the Edit *Menu* when telling then to select Accept. |
| 18:12.16 | ezzieyguywuf | brlcad: the menu itself is actually mentioned, but on about the third accept, two lessons later (I think. just for clarity) |
| 18:14.32 | brlcad | nods |
| 18:14.42 | CIA-14 | BRL-CAD: 03brlcad * r43691 10/brlcad/trunk/doc/docbook/lessons/en/ (2 files): update other references to Accept on the edit menu, change click to select |
| 18:15.08 | ezzieyguywuf | :-D |
| 18:16.13 | ezzieyguywuf | so BRL-CAD was originally written and used by the 'ballistics research laborator' right? And one of the selling points (that I read on the site) is that its more than just 'skin deep'. What does all this mean though? I mean, does it mean I can design a mug and then drop a rock on it and see what happens? |
| 18:18.44 | brlcad | the "Ballistic Research Laboratory" (BRL), yes |
| 18:19.17 | brlcad | more than just skin deep is a reference to our solid modeling underpinnings |
| 18:19.37 | brlcad | as well as complete modeling of object interiors |
| 18:20.23 | brlcad | so if I'm modeling a vehicle, we're geared to represent every little bit of detail, do so with incredible efficiency, and still be able to analytically evaluate the model |
| 18:21.06 | brlcad | every nut, bolt, wire, interior and exterior, and have it actually be volumetrically accurate and mathematically well-defined |
| 18:23.40 | *** join/#brlcad ezzieyguywuf (~wolfie@unaffiliated/ezzieyguywuf) | |
| 18:23.50 | ezzieyguywuf | wow, irssi just froze for the first time in...years |
| 18:23.57 | brlcad | welcome back ;) |
| 18:24.05 | ezzieyguywuf | thanks :-) |
| 18:27.18 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 18:27.25 | brlcad | so don't know when you got cut off there, but hopefully answered your question |
| 18:28.34 | starseeker | awesome - DOJ is starting an antitrust investigation of MPEG-LA |
| 18:38.24 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 18:38.24 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 18:38.24 | *** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ) | |
| 18:38.24 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 18:38.24 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 18:38.24 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 18:38.24 | *** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) | |
| 18:38.24 | *** join/#brlcad CIA-14 (~CIA@208.69.182.149) | |
| 18:38.24 | *** join/#brlcad WhiteCalf (MK@2607:f0d0:3001:68::2) | |
| 18:38.24 | *** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 18:38.24 | *** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ) | |
| 18:38.24 | *** join/#brlcad vtts (~vytautas@diz.ktu.lt) | |
| 18:38.24 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 18:38.24 | *** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no) | |
| 18:38.24 | *** join/#brlcad dtidrow_ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) | |
| 18:38.24 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 18:38.24 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 18:38.24 | *** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net) | |
| 18:38.24 | *** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ) | |
| 18:38.24 | *** join/#brlcad kanzure__ (~kanzure@bioinformatics.org) | |
| 18:38.24 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 18:38.25 | *** mode/#brlcad [+o ChanServ] by verne.freenode.net | |
| 18:40.25 | ezzieyguywuf | I don't know where we got cut off either, let me check my logs |
| 18:40.52 | ezzieyguywuf | <PROTECTED> |
| 18:44.32 | ezzieyguywuf | ah yea, another quirk of the tutorial (and this is the second case of this, lesson 11. can't recall the frist): tute says to run mater mug.r<ENTER> but the mater command expects Usage: mater region_name shader r g b inherit |
| 18:45.10 | brlcad | just two lines missed then |
| 18:45.15 | brlcad | 13:20 < brlcad> so if I'm modeling a vehicle, we're geared to represent every little bit of detail, do so with incredible efficiency, and still be able to analytically evaluate the model |
| 18:45.19 | brlcad | 13:21 < brlcad> every nut, bolt, wire, interior and exterior, and have it actually be volumetrically accurate and mathematically well-defined |
| 18:45.49 | ezzieyguywuf | brlcad: but the actual analytical evaluation is done outside of brl-cad? |
| 18:45.51 | brlcad | ezzieyguywuf: yeah, that's a relatively recent change to 'mater' that I'm not happy with -- it's not supposed to require all usage parameters |
| 18:45.54 | brlcad | basically a bug |
| 18:46.20 | ezzieyguywuf | brlcad: ah. I thought maybe I (read gentoo) compiled it wrong, and this it wasn't interactive as it should have been. |
| 18:46.37 | brlcad | brl-cad performs _geometric_ evaluation quite robustly, more complex analytic evaluation is performed outside |
| 18:46.39 | ezzieyguywuf | I agree: why take away the interactive option of the tool? leave it in. |
| 18:46.54 | brlcad | it wasn't intentional |
| 18:46.57 | ezzieyguywuf | ah ok. |
| 18:47.05 | brlcad | just an oversight during a code change a while back |
| 18:47.53 | ezzieyguywuf | these complex analytic evaluations that are performed outside, they'd have to be done reading the brl-cad database though, right? or does brl-cad provide an api to easily access the data that the external program would be? also, what are some examples of external programs for performing these analyses? ansys? |
| 18:48.17 | brlcad | API |
| 18:48.22 | CIA-14 | BRL-CAD: 03brlcad * r43694 10/brlcad/trunk/TODO: mater command lost interactive functionality, need to restore |
| 18:48.42 | brlcad | there are literally dozens |
| 18:49.08 | brlcad | we provide a ray query interface which allows you to sample geometry in any matter you need for an analysis |
| 18:49.27 | brlcad | so lots of codes use that interface for a whole range of advanced purposes |
| 18:49.48 | brlcad | medical dosage analysis, vulnerability/lethality analysis, signal analysis, heat studies, structural |
| 18:50.14 | ezzieyguywuf | hrm, interesting. very interesting. |
| 18:50.16 | brlcad | our closest link is V/L, the code's name is MUVES -- a closed code developed by the usgov |
| 18:51.14 | brlcad | the geometric analyses we directly perform are presented and exposed area calculations, volume, weight/mass, moments of inertia, centroids, and aforementioned shotline queries |
| 18:51.43 | brlcad | ah, also overlap/interference detection |
| 18:51.50 | brlcad | maybe a couple others, but those immediately come to mind |
| 18:53.10 | ezzieyguywuf | so I can do a lot with a solid-model mode in BRL-CAD. |
| 18:53.56 | brlcad | right |
| 18:54.19 | brlcad | our weakness is converting to a surface model (polygonal) and direct design |
| 18:54.49 | brlcad | http://brlcad.org/Industry_Diagram.png might give you an idea |
| 18:55.50 | brlcad | still mostly accurate though we have expanded to right a little bit with NURBS and STEP support |
| 18:56.17 | ezzieyguywuf | hrm, I can't make heads or tails of that diagram :-P |
| 18:56.30 | brlcad | lots of layers of information to digest |
| 18:56.47 | ezzieyguywuf | ah, I see tha BRL-CAD shaded region now. |
| 18:57.03 | ezzieyguywuf | so, I'm most familiar with SolidWorks: where would that fall on that diagram? |
| 18:57.33 | ezzieyguywuf | or, more importantly, I'm starting work as a Mechanical Engineer soon: which aspects of that diagram would you think would be most useful to me professionaly? |
| 18:57.36 | ezzieyguywuf | for design work. |
| 18:58.05 | brlcad | might help to read it this way: CADD is basically AutoCAD industry, MCAD is systems like GibbsCAM, the center 'CAD' domain is where you'd place Solidworks, ProE, NX, CATIA |
| 18:59.05 | brlcad | CAID is rather specialized systems, but that'd be systems like Rhino3D |
| 18:59.54 | ezzieyguywuf | ah hah. the diagram is now making more sense. |
| 18:59.58 | brlcad | the dotted domains are different purposes that those domains tend to cater to |
| 19:00.47 | ezzieyguywuf | what is NURBS and STEP? |
| 19:01.08 | ezzieyguywuf | and can BRL-CAD produce a mesh to use in, say, OpenFOAM? |
| 19:01.22 | brlcad | STEP is a file exchange format |
| 19:02.13 | brlcad | similar to IGES, successor |
| 19:02.16 | brlcad | NURBS is a boundary representation format -- what a lot of commercial CAD systems use to represent surfaces |
| 19:02.27 | starseeker | (Non-Uniform Rational BSplines) |
| 19:02.33 | ezzieyguywuf | ah, I see. |
| 19:02.41 | brlcad | ezzieyguywuf: http://brlcad.org/d/node/82 <-- talks about converters in a bit more depth |
| 19:03.55 | ezzieyguywuf | ok, question about the tutorial (sorry to keep shifting the convo back and forth): I'm still working on the mug, and when I do tree mug.r it shows that body.c is composed of u bodyout.s - bodyin.s, but a) the inner rcc is not dotted and b) when I raytrace the inner rcc is not cut out from the outer one. rather they seem to be merged into one. |
| 19:04.06 | ezzieyguywuf | is it maybe that I have more things drawn on the screen than I want? |
| 19:04.14 | ezzieyguywuf | is there a way to ls everything that is currently active? |
| 19:04.29 | ``Erik_ | heh, pixdiff of regular vs -c "set rt_bot_mintie=1" ... http://brlcad.org/~erik/bot20110304.png (vs a while back with http://brlcad.org/~erik/bot20101229.png) |
| 19:04.44 | brlcad | ezzieyguywuf: type "who" .. you might have multiple objects displayed |
| 19:05.35 | brlcad | ``Erik: not too shabby! |
| 19:05.42 | ezzieyguywuf | who lists bodyout.s, bodyin.s, handle.s |
| 19:05.45 | ``Erik | (only on 64b, crashes on 32b still) |
| 19:05.48 | brlcad | ``Erik: mirrors fail to convert? |
| 19:06.05 | ``Erik | same source model, not sure why they're off |
| 19:06.27 | brlcad | looks like you fixed all of the original failures |
| 19:06.52 | ``Erik | yeah, backing off a tiny bit did that... more concerned about the 32b issue, then I need to get back to geomcore |
| 19:06.56 | brlcad | ezzieyguywuf: so when you raytrace, you're raytracing those three primitives, not mug.r |
| 19:07.34 | ezzieyguywuf | ah |
| 19:07.41 | brlcad | B mug.r will erase those three you're viewing and draw mug.r, then it should go to dotted for the subtracted objects and raytrace as you're expecting |
| 19:07.48 | ezzieyguywuf | B mug.r...you beat me to it :-P |
| 19:08.09 | brlcad | :) |
| 19:08.28 | ezzieyguywuf | ok. mug looks proper, and yet the inner rcc is still not dotted. |
| 19:08.49 | ezzieyguywuf | I guess its a 'minor' thing but it bugs me because the dots would make things easier to visualize pre-raytrace |
| 19:09.05 | brlcad | can you post up your .g file somewhere? |
| 19:09.32 | vtts | howdy, r43679 gives http://pastebin.com/BmmDXE2u when selectin Edit->Combination Editor (and few others), does anybody know how to fix it? |
| 19:09.36 | brlcad | anon ftp to brlcad.org if you don't |
| 19:09.39 | ezzieyguywuf | yea, one sec. wait, I can't exactly pastebin it... |
| 19:09.53 | brlcad | vtts: saw your report last night, it's on our list to verify |
| 19:10.12 | vtts | ok, thanks |
| 19:10.24 | brlcad | thanks for reporting it |
| 19:10.37 | ezzieyguywuf | http://ompldr.org/vN25zOQ <--- mug.g |
| 19:10.56 | brlcad | vtts: is this your own compile? |
| 19:11.12 | brlcad | vtts: if it is, retry with an --enable-all build |
| 19:11.28 | vtts | brlcad, it is with --enable-all |
| 19:11.38 | brlcad | okay, good to know |
| 19:12.18 | vtts | to be precise: --enable-optimized --enable-threads --enable-all --with-agl |
| 19:13.50 | vtts | is there a way to define a custom phong based custom shader (like plastic but with custom defaults)? |
| 19:14.24 | ezzieyguywuf | does brl-cad have a facility by which I can say, for example, "insert an rcc with its center at the same location as rcc1, a diameter that is 0.2 less, and a height that is 2 more (than that rcc1)" or do I have to manually check the dims of the first in order to make the second? |
| 19:14.27 | ``Erik | 'define' like write your own C evaluator, or just set different defaults? |
| 19:15.02 | vtts | i'd just like to assign my_plastic to a region |
| 19:15.17 | vtts | multiple regions that is |
| 19:15.53 | vtts | or any other way to change properties for multiple objects |
| 19:16.22 | vtts | i'm thinking about custom shader and change'ing it's default settings, but not sure if it is possible |
| 19:16.50 | brlcad | vtts: yes there is, you can customize any of the phong parameters |
| 19:16.57 | CIA-14 | BRL-CAD: 03erikgreenwald * r43695 10/brlcad/trunk/src/librt/primitives/bot/bot.c: we actually trigger this correctly now, so remove the extra debugging info |
| 19:17.28 | brlcad | vtts: the combination editor has a shader button, select it, enter your object name, hit enter, and you should see all of the parameters available |
| 19:17.42 | vtts | yeah i'm using it now |
| 19:17.58 | brlcad | ezzieyguywuf: does your wireframe look like this: http://brlcad.org/tmp/mug.png |
| 19:18.39 | *** join/#brlcad roberthl (~robert@v001.rhl.me.uk) | |
| 19:18.42 | brlcad | (besides the line thickness) the inner rcc looks dashed here |
| 19:18.50 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 19:18.54 | vtts | but have few objects and was thinking if it would be possible to define custom shader, assign it to regions, and modify its parameters (instead of settings for every object) |
| 19:19.37 | ezzieyguywuf | brlcad: it does not. let me take a screenshot. |
| 19:20.06 | brlcad | vtts: ah, that'd be "shader objects" which we don't yet implement but is on our wish list |
| 19:20.17 | vtts | ok then |
| 19:20.23 | brlcad | vtts: you can copy shaders from objects to objects without too much difficulty |
| 19:20.54 | ezzieyguywuf | brlcad: http://ompldr.org/vN25zYw |
| 19:20.54 | vtts | ok, i guess i'll catch up with that with tutorials |
| 19:21.19 | ezzieyguywuf | vtts: which tutorial are you on? I'm on the mug :-P |
| 19:21.27 | brlcad | ezzieyguywuf: huh, that is bizzare |
| 19:21.29 | vtts | ezzieyguywuf, i guess the same |
| 19:21.46 | ezzieyguywuf | brlcad: crazy huh? Maybe I have an odd version? how can I check my vers? |
| 19:21.47 | brlcad | ezzieyguywuf: try "Z" |
| 19:22.01 | brlcad | then redraw the mug |
| 19:23.00 | brlcad | your version is on the window titlebar, 7.16.8 -- wireframe code hasn't really changed |
| 19:23.16 | ezzieyguywuf | brlcad: http://ompldr.org/vN25zZg |
| 19:23.20 | brlcad | you can try opening one of the example geometry database files, havoc.g for example, |
| 19:23.32 | vtts | what could you recommend to generate something like first/third-angle projections (with measurements if possible)? |
| 19:24.32 | brlcad | ezzieyguywuf: yeah, at a glance I would say we didn't have the same .g so apparently a bug of some sort |
| 19:24.54 | brlcad | ezzieyguywuf: hate to say it, but try restarting mged, redraw |
| 19:25.18 | ezzieyguywuf | I'll try, though this has persisted across multiple sessions of mged with different databases |
| 19:25.20 | brlcad | note that the raytrace rendering not changing underneath is correct, not a bug |
| 19:25.54 | brlcad | vtts: first/third-angle projections? |
| 19:25.55 | ezzieyguywuf | brlcad: yea I know, I zoomed into the wireframe to make it easier to see, but left the raytrace so you could see it really was hollowed out. |
| 19:26.09 | brlcad | vtts, do you mean a perspective view? |
| 19:26.20 | brlcad | ezzieyguywuf: k, just making sure :) |
| 19:26.25 | brlcad | some are confused by that |
| 19:26.30 | brlcad | it's intentional |
| 19:26.33 | vtts | brlcad, yes, but for printing with measurements and so on. |
| 19:27.22 | brlcad | vtts: Misc -> Perspective will turn on perspective viewing |
| 19:27.32 | ezzieyguywuf | http://ompldr.org/vN25zZw brlcad: also, I sometimes get a garbled mged screen, as seen in this screenshot. if I shift-translate the object, though, it draws appropriately. |
| 19:27.58 | brlcad | you can set the exact angle on the command line with "set perspective [value]" or "set perspective" to see the current value |
| 19:27.59 | ezzieyguywuf | brlcad: yea, restarted, still not dashed. |
| 19:28.03 | ezzieyguywuf | I'm doing 'draw mug.r' |
| 19:28.49 | brlcad | ezzieyguywuf: that's probably with the framebuffer enabled and you resize the window, yes? |
| 19:28.50 | vtts | brlcad, view'ing is not the problem, multiplane is quite good |
| 19:29.05 | vtts | but i'd like to generate some specs. with measurements |
| 19:29.25 | brlcad | ezzieyguywuf: you're seeing uninitialized framebuffer memory -- can either turn the framebuffer off, or (as you found out) refresh |
| 19:29.42 | brlcad | not the best, but has been low priority to address since data isn't affected |
| 19:30.03 | ezzieyguywuf | brlcad: ah ok. is framebuffer something that is brl-cad specific, or is it the same framebuffer that is referred it in my linux kernel etc? |
| 19:31.09 | brlcad | ezzieyguywuf: it's the same concept as referred to in the kernel, but different construct |
| 19:31.10 | CIA-14 | BRL-CAD: 03brlcad * r43696 10/brlcad/trunk/TODO: resizing embedded framebuffer sucks, fix it |
| 19:31.11 | ezzieyguywuf | === load framebuffer; +++ refresh framebuffer; === <rest of code> :-P |
| 19:32.08 | brlcad | vtts: ezzieyguywuf just asked about that earlier today (as do many) .. annotations and dimensions are currently being worked on but not yet ready |
| 19:32.39 | brlcad | you can get the model rendered as a hidden line rendering but annotations would have to be added manually in another tool unfortunately until that support is complete |
| 19:33.08 | vtts | ok, thanks |
| 19:33.24 | ezzieyguywuf | what does 'mater' stand for? |
| 19:34.00 | vtts | physical substance :) |
| 19:34.19 | ezzieyguywuf | :-P and how are the mater and shade commands different? |
| 19:34.28 | brlcad | until then, this is about as close as you'll get http://brlcad.org/gallery/s/renderings/havoc_rtedge.png.html and http://brlcad.org/gallery/s/screenshots/extractor.png.html |
| 19:34.46 | brlcad | easily scripted for a series of views, but still no annotations |
| 19:35.02 | vtts | ok, np |
| 19:35.11 | CIA-14 | BRL-CAD: 03starseeker * r43697 10/brlcad/trunk/TODO: Got a report of nirt not working correctly on Windows - Bob has reproduced this and is working on it |
| 19:35.46 | brlcad | 'help mater' .. mater is short for material |
| 19:35.52 | ezzieyguywuf | ah ok. |
| 19:36.29 | brlcad | which is a bit of a misnomer in that context, because it's technically just the shader for visualization -- the actual material code is set/used elsewhere |
| 19:36.57 | ezzieyguywuf | yea, I was getting confused. "Where's the density? Material properties? Etc?" |
| 19:37.41 | starseeker | brlcad: should we add a rename of mater->shader to the deprecation.txt file? |
| 19:37.56 | brlcad | oof |
| 19:38.13 | brlcad | probably, but that's hard even for me to swallow .. because it's been 'mater' forever :) |
| 19:38.37 | ezzieyguywuf | lol. its cool, I'll just keep thinking of that character from the Cars (tm) movie :-P |
| 19:39.05 | brlcad | mater is still better way to set the other combination properties, object color and inheritance |
| 19:39.12 | brlcad | shader only sets the shader |
| 19:39.18 | brlcad | so would have to resolve the other two |
| 19:40.42 | brlcad | starseeker: probably best to just hit up the lower hanging fruit first, that one requires figuring out new command(s) and options to cover mater's existing commands |
| 19:40.50 | brlcad | s/commands/settings/ |
| 19:41.05 | starseeker | nods |
| 19:41.11 | starseeker | just a thought while it came up |
| 19:44.47 | brlcad | yeah, I think you're right |
| 19:44.51 | brlcad | just maybe "not now" |
| 19:46.20 | ezzieyguywuf | so is there a way to print out the geometry of a given object? i.e. if I create an rcc and later want to see what its vertex, height and radius are? |
| 19:48.07 | brlcad | 'l' |
| 19:48.11 | *** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ) | |
| 19:48.12 | brlcad | for list |
| 19:49.16 | brlcad | ezzieyguywuf: oh, and to answer your question from earlier, there are a few custom commands for creating objects based on cylinder end points |
| 19:49.31 | brlcad | rcc[tab][tab] should show them, help should describe them |
| 19:50.18 | starseeker | brlcad: sweeeeet. The head of the old simplesat project sent me about 180 autocad dwg files detailing the simplesat |
| 19:50.30 | ezzieyguywuf | I was asking more for in general though. For example, in SolidWorks I usually create an object, draw some costruction lines, and then place things 'tangen' or in the 'middle' or 'coincident' etc. |
| 19:50.43 | ezzieyguywuf | s/tangen/tangent/ |
| 19:50.47 | brlcad | starseeker: AWESOME! |
| 19:50.55 | brlcad | are they solid or drawings only? |
| 19:51.01 | ezzieyguywuf | I wonder if I can build things relative to other things in brl-cad as well. |
| 19:51.12 | starseeker | drawings only, but he says it was all him so they should be public domain |
| 19:51.21 | starseeker | awesome material for a modeling project :-) |
| 19:51.22 | ezzieyguywuf | brlcad: well, I guess drawings. but then I can 'mate' solid things in an assembly using similar relations. |
| 19:51.36 | ezzieyguywuf | oh, nwm you were asking him. |
| 19:52.05 | starseeker | ezzieyguywuf: heh, sorry - irc conversations are often kinda jumbled |
| 19:52.06 | brlcad | ezzieyguywuf: there are ways, but they're fairly manual ways and they won't (yet) stay constrained |
| 19:52.22 | ezzieyguywuf | hrm I see. |
| 19:52.40 | ezzieyguywuf | I can see that being an issue if I make a part and end up wanting to scale it, for whatever reason. |
| 19:52.48 | ezzieyguywuf | how would you approach that in brl-cad? |
| 19:53.00 | ezzieyguywuf | edit the database directly? |
| 19:53.04 | brlcad | they'll scale up just fine |
| 19:53.35 | brlcad | because you'll have combined associated objects together into common regions or groups, and the scale would apply to all members |
| 19:53.44 | ezzieyguywuf | well, in the mug example: if I wanted a mug twice as big, I'd have to double the size of the inner rcc, the outer rcc, and resize the handle appropriately. |
| 19:53.55 | brlcad | ah, no you woudln't |
| 19:54.06 | brlcad | you'd just apply a matrix edit to the mug, and scale it |
| 19:54.32 | ezzieyguywuf | hrm i see. the subject of a later lesson in the tutorial maybe? |
| 19:55.08 | brlcad | if you select Edit -> Matrix Edit, then select mug.r, then select any one of your primitives in the next window, you'll be able to select Scale on the Edit menu among a whole other range of edit options |
| 19:55.12 | brlcad | yep |
| 19:55.31 | ezzieyguywuf | cool cool, I'll keep trudging along then. |
| 19:55.32 | brlcad | it starts out really basic just because there are so many foreign concepts |
| 19:55.40 | ezzieyguywuf | yea I gotcha. |
| 19:55.49 | brlcad | even for people with CAD experience, we deviate in some respects |
| 19:55.53 | brlcad | s/some/many/ :) |
| 19:55.55 | ezzieyguywuf | its like learning to walk again, except its learning te solid model again :-P |
| 19:56.09 | ezzieyguywuf | lol. |
| 19:56.42 | brlcad | nods, I hear ya |
| 19:57.12 | brlcad | working on improving our usability is a bigger-picture area we're working on, but that's major long-term complicated work :) |
| 19:57.50 | brlcad | developing a new easier-to-use gui while not alienating existing expert modelers is pretty tricky.. |
| 19:58.10 | ezzieyguywuf | meh, I'm not afraid to spend a week or two learning a new software. |
| 19:58.19 | ezzieyguywuf | kinda got used to it working with linux :-P |
| 19:58.51 | ezzieyguywuf | brlcad: I kind of like that I can do everything from a command-line if I want |
| 19:59.05 | brlcad | with the exception of two of them, all the models on http://brlcad.org/gallery/s/renderings/ were completely designed within BRL-CAD in anywhere from a couple days to a couple months for the more complex models (which some of the experts have down to just a couple weeks for even the most complex) |
| 19:59.11 | ezzieyguywuf | one of the reasons I stuck around: I was mucking about in SolidWorks last week and had to do some repetitive stuff and thought to myself, "hey, this would be so easy to script" |
| 19:59.39 | brlcad | now scripting is actually one of our strengths! :) |
| 19:59.50 | brlcad | we do that better, more flexibly, than most |
| 20:00.15 | brlcad | you just have to know the command layer basics first :) |
| 20:00.16 | ezzieyguywuf | yea! that's why I want to learn brl-cad. |
| 20:02.18 | brlcad | the goliath is a pretty good example of what's possible in a short amount of time -- that was modeled by a summer student from scratch (starting with a ruler and pad of paper, and the mged tutorials) in about 6 weeks |
| 20:02.33 | brlcad | http://brlcad.org/gallery/s/renderings/goliath/ |
| 20:04.08 | ezzieyguywuf | so theoretically, I could take that goliath model and run it through an FEA program do a heat-transfer analysis on it somehow? |
| 20:04.22 | ezzieyguywuf | i.e. the project is useful for than just pretty pictures? |
| 20:05.07 | CIA-14 | BRL-CAD: 03starseeker * r43698 10/brlcad/branches/cmake/ (20 files in 6 dirs): MFC r43697 |
| 20:05.31 | brlcad | the actual one they measured: http://armor.callihan.cc/gallery/goliath/06-Aberdeen_0165.JPG |
| 20:05.42 | brlcad | sure |
| 20:06.48 | brlcad | the bridge to FEA is a pain because most require conversion from solid model to polygonal, but we do have a stable export path through Sandia National Lab's Cubit tool, which is one of the best at finite element meshing |
| 20:06.49 | ezzieyguywuf | mulitpane mode = awesome. |
| 20:11.11 | vtts | it would be even better if there was a way to make secondary planes react to view changes of the primary one :) |
| 20:11.54 | ezzieyguywuf | vtts: ah hah, that would be sweet |
| 20:12.06 | ezzieyguywuf | I like how its un-coupled though, that comes in handy too. |
| 20:12.14 | ezzieyguywuf | but I see how coupling two or more views would be nice. |
| 20:12.37 | brlcad | vtts: how would they react? |
| 20:13.58 | vtts | well they all have a center point |
| 20:14.14 | vtts | it would be nice to see changes relative to it |
| 20:14.46 | vtts | e.g. moving view, or changing azimuth |
| 20:15.52 | vtts | I'm not used to it, so shortly after starting using it got confused about orientation of the object in secondary panes |
| 20:16.00 | vtts | but thats just me |
| 20:16.17 | ezzieyguywuf | if I am in edit mode, how do I shift the screet without resizing the object I'm editing? |
| 20:16.26 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 20:16.26 | *** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ) | |
| 20:16.28 | ezzieyguywuf | I can zoom it/out with left/right click, but I want to pan too |
| 20:16.48 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 20:17.09 | vtts | ezzieyguywuf, try using "x", "y", "z" keys |
| 20:17.14 | vtts | ezzieyguywuf, or ae command |
| 20:17.36 | brlcad | ezzieyguywuf: there are a slew of bindings (including pan) |
| 20:17.51 | brlcad | shift grips document lists them |
| 20:18.34 | starseeker | thinks tonight would be a good time to see how the libredwg project is coming... I can convert these to something else on-by-one if I have to, but scripting it would be so much nicer/easier... |
| 20:18.42 | vtts | by the way, ctrl+alt+mouse-click doesn't work as it's supposed to on mac :( |
| 20:27.16 | CIA-14 | BRL-CAD: 03erikgreenwald * r43699 10/brlcad/trunk/ (5 files in 2 dirs): more tfloat->fastf_t/TIE_3->vect_t|point_t conversion |
| 20:27.46 | ezzieyguywuf | so the diff between combinations and regions is that a combination is a combination of primitave objects to make a particular, more complex geometry, whereas a region is a combination of combinations and/or primitative objects to create a complex object with material props right? |
| 20:28.36 | starseeker | ezzieyguywuf: a region is regarded as a solid object - if two regions overlap, it is a modeling error |
| 20:28.52 | starseeker | combinations under a region can overlap |
| 20:31.38 | ezzieyguywuf | but how come I go to the combination editor to edit shading etc, and not the 'region editor' |
| 20:32.03 | starseeker | because the same editor can edit both regions and combinations |
| 20:32.08 | starseeker | regions are just combinations with a flag set |
| 20:32.09 | ezzieyguywuf | hrm, I see. |
| 20:32.50 | starseeker | in hindsight it would probably have been better to make the user interface respect the whole "regions are special" mantra a bit more, but it currently reflects the implementation reality (regions are combs with a flag) |
| 20:33.24 | ezzieyguywuf | also: is sloppy focus hard coded into mged? I have my window-manager set up so that focus does NOT follow the mouse, only mouse clicks. but between my framebuffer and mged command-line I see sloppy focus. |
| 20:33.40 | ezzieyguywuf | starseeker: good to know. |
| 20:33.50 | starseeker | not sure about the focus |
| 20:35.22 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 20:36.17 | ezzieyguywuf | ok question: how come when I change the color via the combination editor, I have to blash the respective region/combination in order to see the new color? |
| 20:36.53 | starseeker | you mean why isn't the color update reflected in the wireframe? |
| 20:37.53 | CIA-14 | BRL-CAD: 03erikgreenwald * r43700 10/isst/trunk/configure.ac: libtie is no more, just librt |
| 20:37.57 | ezzieyguywuf | starseeker: yea. |
| 20:38.26 | starseeker | if we're drawing a model with a LOT of lines (BoT models can have huge numbers) a wireframe view update is non-trivial from a resource perspective |
| 20:38.35 | starseeker | that'd be my guess |
| 20:38.39 | ezzieyguywuf | hrm, I see. |
| 20:38.44 | ezzieyguywuf | what is BoT? |
| 20:38.50 | starseeker | bag of triangles |
| 20:38.50 | CIA-14 | BRL-CAD: 03erikgreenwald * r43701 10/isst/trunk/gtk/ (gui.c isst.h local_worker.c main.c net_worker.c): update to compile against latest BRL-CAD |
| 20:39.22 | brlcad | ezzieyguywuf: in brl-cad language groups are assemblies, regions are parts, and combinations are the mechanism for structuring regions and groups |
| 20:39.55 | vtts | starseeker, is there a command to check if regions overlap? |
| 20:39.55 | ezzieyguywuf | so combinations are like drawings. |
| 20:40.08 | ezzieyguywuf | in SolidWorks that is (I caught the assemblies and parts reference) |
| 20:40.14 | starseeker | vtts: rtcheck |
| 20:40.20 | vtts | superb |
| 20:40.45 | brlcad | man, lot of irc network issues today |
| 20:40.56 | ezzieyguywuf | silly irc. |
| 20:42.15 | brlcad | ezzieyguywuf: sort of like "drawings", but since we're strictly 3D-only, we refer to them more as "shapes" |
| 20:42.36 | ezzieyguywuf | gotcha gotcha. |
| 20:42.38 | brlcad | a shape becomes solid and occupies space when you put it in a region |
| 20:43.11 | ezzieyguywuf | so it makes sense to use a 'region editor' then, and not a 'combination editor' yea? |
| 20:43.31 | ezzieyguywuf | since strictly speaking combinations are just representations of what will eventually be a solid object. |
| 20:43.56 | brlcad | it really should just be an "object editor" and show you parameters accordingly based on the object you're editing |
| 20:44.22 | brlcad | the next generation interface eliminates that distinction |
| 20:44.32 | brlcad | just shows a panel of parameters |
| 20:44.37 | ezzieyguywuf | ah hah. b/c I can change the color of the wireframe which represents the combination. |
| 20:44.43 | ezzieyguywuf | cool. |
| 20:44.49 | CIA-14 | BRL-CAD: 03erikgreenwald * r43702 10/isst/trunk/sdl/ (Makefile.am event.c isst.h main.c myplugin.c): disable texture fonts, make compile with current BRL-CAD |
| 20:46.58 | brlcad | notes our release TODO is getting LONGER faster than it's getting shorter.. urg! |
| 20:47.31 | ezzieyguywuf | lol. |
| 20:54.39 | CIA-14 | BRL-CAD: 03starseeker * r43703 10/geomcore/trunk/tests/svntest/main.c: Got lists of assemblies and regions, but a deep keep of the region is not quite so simple. This seems like it might be another case where librt functionality is in order, but might already be there... need to check |
| 21:22.52 | brlcad | starseeker: sorry to say it but search is nfg |
| 21:23.44 | brlcad | actually seems royally busted, all three tests failed on a simple model |
| 21:24.58 | starseeker | you're kidding |
| 21:25.08 | starseeker | what tests? |
| 21:26.40 | brlcad | tried: search . -name mug.g (returned error about failing to make a plan) search / -name mug.g (returned nothing) search . (crashed mged) |
| 21:26.41 | starseeker | debates between screaming and crying... |
| 21:28.20 | brlcad | probably best to just revert trunk to prior state for release, get it into the next release .. assuming tie bot raytracing works; if it doesn't then we have more time still |
| 21:28.48 | brlcad | s/mug.g/mug.r/ .. was using the .g ezzie posted earlier |
| 21:29.00 | brlcad | http://ompldr.org/vN25zOQ |
| 21:30.48 | brlcad | looks like "search /" has plan problems, returns unknown option passed to find_create() |
| 21:31.05 | brlcad | then Error: Failed to build find plan. |
| 21:31.22 | starseeker | I don't believe it |
| 21:31.30 | starseeker | how did it go south so fast? |
| 21:31.38 | starseeker | or maybe I was dreaming... |
| 21:31.41 | starseeker | will revert |
| 21:32.25 | brlcad | the librt code can probably stay, doesn't have to be full revert |
| 21:33.03 | starseeker | will need to revert raytrace.h |
| 21:33.14 | starseeker | grinds teeth... |
| 21:34.09 | CIA-14 | BRL-CAD: 03starseeker * r43704 10/geomcore/trunk/tests/svntest/main.c: something not right here... keep isn't creating much of anything in the way of geometry... |
| 21:34.28 | starseeker | not good... can't afford this right now |
| 21:35.07 | brlcad | you're in good company, lots of hard show-stoppers |
| 21:35.23 | brlcad | see if bob can fix the combination editor while's he's in there working on nirt :) |
| 21:36.57 | starseeker | brlcad: real quick - does search in its current form work on the command line? |
| 21:37.07 | CIA-14 | BRL-CAD: 03erikgreenwald * r43705 10/brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c: clean up #if 0 stuff |
| 21:37.10 | starseeker | e.g. mged mug.g search . -name mug.r |
| 21:38.18 | brlcad | . works, / doesn't |
| 21:38.25 | brlcad | interesting |
| 21:38.45 | brlcad | search . also still crashes |
| 21:40.41 | starseeker | sees one error right off |
| 22:02.57 | starseeker | brlcad: before I revert, can you give r43706 a go? |
| 22:03.09 | CIA-14 | BRL-CAD: 03starseeker * r43706 10/brlcad/trunk/src/ (libged/search.c librt/search.c): Variety of fixes to both libged and librt search logic. |
| 22:04.59 | brlcad | sure |
| 22:07.57 | CIA-14 | BRL-CAD: 03erikgreenwald * r43707 10/brlcad/trunk/ (5 files in 2 dirs): revert to 43698, caused weird errors in output |
| 22:09.03 | CIA-14 | BRL-CAD: 03starseeker * r43708 10/brlcad/trunk/src/libged/search.c: Catch another odd input case |
| 22:09.18 | brlcad | wow, isn't that like all of your changes ``Erik |
| 22:10.55 | ``Erik | heh, this was a really weird one, bunches of misses showing up even on cubes |
| 22:11.02 | ``Erik | bastage O.o |
| 22:16.51 | starseeker | waits in suspense... |
| 22:19.24 | ezzieyguywuf | how can I do a primitive selection from the command-line? |
| 22:21.26 | brlcad | starseeker: rebuilding now, testing in a few |
| 22:21.35 | brlcad | ezzieyguywuf: sed |
| 22:21.35 | CIA-14 | BRL-CAD: 03brlcad * r43709 10/brlcad/trunk/TODO: combination editor bug confirmed, mged init on mac DISPLAY issue wasn't specific to mged so not a show-stopper (mged stall if started from Terminal, restarting X11 fixed it) |
| 22:21.57 | brlcad | sed and oed are the two ways to go into an edit mode from the command line |
| 22:22.17 | brlcad | the latter being pretty powerful, but a bit obtuse to use -- there is a tutorial dedicated to it on the website |
| 22:22.40 | brlcad | it's how you'd scale up, translate, rotate groups of geometry |
| 22:24.00 | ezzieyguywuf | brlcad: ah, thanks. |
| 22:24.20 | ezzieyguywuf | heh, funny how so many of mged commands are the same as unix commands. |
| 22:24.21 | CIA-14 | BRL-CAD: 03erikgreenwald * r43710 10/brlcad/trunk/ (4 files in 2 dirs): shift tie min/max to point_t |
| 22:39.28 | brlcad | starseeker: that's looking MUCH better already |
| 22:39.56 | brlcad | 'search .' and 'search /' don't do the right thing, but quick test with -name and -type seem to work as expected |
| 22:41.16 | brlcad | globbing doesn't seem to be working right |
| 22:41.38 | brlcad | e.g.: search . -name * |
| 22:42.31 | starseeker | try search . -name \* maybe? |
| 22:42.36 | brlcad | hm. same test that worked on the simple model is returning nothing for havoc for both "search . -type c" and "search / -type c" .. |
| 22:42.39 | starseeker | or from the command line search . -name \\* |
| 22:42.40 | brlcad | tried that, nothing |
| 22:43.02 | brlcad | yeah, variety of regression failures even for / |
| 22:43.06 | starseeker | odd, works here... |
| 22:43.22 | starseeker | oh wait, type... |
| 22:43.37 | starseeker | no, that works too... |
| 22:43.54 | brlcad | worked on the mug model, but not havoc |
| 22:44.35 | starseeker | tries havoc |
| 22:45.10 | starseeker | seems to work... |
| 22:45.32 | starseeker | uh... |
| 22:45.36 | starseeker | what platform? |
| 22:46.03 | brlcad | 10.6 |
| 22:46.39 | CIA-14 | BRL-CAD: 03starseeker * r43711 10/geomcore/trunk/tests/svntest/main.c: Woot - that was it, ignore nref in node write and we get content |
| 22:46.56 | brlcad | hm, worked if I restarted mged |
| 22:47.10 | brlcad | hope you're not using static variables somewhere... |
| 22:47.42 | starseeker | not intentionally... |
| 22:51.59 | brlcad | there we go, got it to repeat |
| 22:51.59 | brlcad | not sure how it's caused, but eventually, I can get it into a state where it stops working |
| 22:52.04 | starseeker | great |
| 22:52.11 | starseeker | starts reverting... |
| 22:52.32 | brlcad | sounds like it's really close, but just not very stable |
| 22:52.55 | starseeker | it just returns nothing? |
| 22:53.01 | brlcad | yea |
| 22:53.11 | brlcad | opened havoc, everything I tried worked |
| 22:53.13 | starseeker | and you just did searches for a while? |
| 22:53.14 | brlcad | including globbing |
| 22:53.40 | brlcad | then swapped to mug.r, repeated random -type -name searches |
| 22:54.07 | brlcad | some intentionally working but some not working (that should, like "search ." and "search /") |
| 22:54.22 | brlcad | then switched back to havoc (via opendb), and it was dead |
| 22:54.43 | starseeker | uh... what do you expect for search . and search / - there's no plan there |
| 22:54.54 | brlcad | plan is optional |
| 22:55.17 | brlcad | according to usage at least, which is how 'find' is too -- should return everything |
| 22:55.24 | brlcad | no plan |
| 22:57.15 | starseeker | I doubt that has ever been true - if it was, it was accidental |
| 22:57.15 | brlcad | search . becomes very similar to "ls *", search / becomes like "tree [tops]" |
| 22:57.15 | brlcad | I remember trying it earlier at one point and you had it working :) |
| 22:57.19 | starseeker | not intentionally |
| 22:57.24 | brlcad | subpath searching seemed to have issues too, search /havoc -type c |
| 22:57.36 | brlcad | search /havoc/. -type c was fun |
| 22:57.51 | brlcad | fun as in didn't do anything :) |
| 22:58.30 | starseeker | it's a pretty good bet the option parsing for the strings isn't up to all those options |
| 22:59.22 | brlcad | nods |
| 22:59.57 | starseeker | I had to be getting lucky on how things fell through earlier, 'cause I sure didn't have anything sophisticated in place |
| 23:00.08 | brlcad | that last one would have been fine, heck could even limit usage to just "search [.|] [plan]" but having it stop outright after a bit is disconcerting :) |
| 23:00.09 | starseeker | the "do nothing" thing worries me more |
| 23:00.24 | brlcad | yep |
| 23:00.35 | starseeker | you can't hook a debugger up and track it somehow? |
| 23:00.45 | starseeker | will try to reproduce... |
| 23:01.04 | brlcad | not at the moment, have build working on the other issue, but can poke on it some more in a bit |
| 23:01.34 | starseeker | cool - I'll lay off reverting for now then. From what ``Erik was saying, it sounds like he's got a bit more to go there |
| 23:02.05 | brlcad | ``Erik: think it'll be this weekend or you'll need more time? |
| 23:03.01 | starseeker | think he's on his way home |
| 23:10.23 | brlcad | k, sending an update to the list then |
| 23:18.35 | *** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ) | |
| 23:20.19 | ezzieyguywuf | you know, I start mged from a terminal. unless I explicitly type exit into mged, though, the process stays alive. i.e. I can X out the framebuffer window (which destroys the mged prompt window as well) and kill the term that I launched mged from and the process persists. I feel like this is a serious issue. |
| 23:20.38 | starseeker | brlcad: the iteration over dbip->dbi_Head is failing - all the directory pointers are coming back null |
| 23:20.49 | starseeker | how could that happen? |
| 23:33.20 | brlcad | starseeker: maybe something is freeing memory |
| 23:34.10 | starseeker | it's not that... I checked ls, it's working |
| 23:34.19 | starseeker | most are null, but clearly not all |
| 23:34.22 | ``Erik | it works for 64b, 32 gets off... I think there may be a rogue ptr += sizeof(bah*) that's not quite right or something... feel free to take a look if ya want, there's not that much code... the optimized split routine is a major portion, and it's not used with the default path |
| 23:34.26 | starseeker | forgot it's a hash table |
| 23:34.41 | ``Erik | (mebbe I'm too deep in it, fresh eyes might spot something obvious) |
| 23:35.43 | ``Erik | (my only 32b box is fbsd, which might align things different than other platforms, too...) |
| 23:36.34 | starseeker | is down in the pattern matching in the back trace now, which is scary scary turf... |
| 23:36.49 | brlcad | ezzieyguywuf: if you can characterize exact steps to reproduce the problem and what you're expecting it to do (even if it's exactly the steps you just mentioned), please report it as a bug to the bug tracker: https://sourceforge.net/tracker/?func=add&group_id=105292&atid=640802 |
| 23:37.09 | ezzieyguywuf | brlcad: sure. |
| 23:37.12 | brlcad | closing the graphics window is supposed to shut down mged (whereas closing the command window is not) |
| 23:37.30 | brlcad | I known issue on Mac OS X makes it not close there, but should work for linux |
| 23:37.47 | brlcad | and windows, don't know that it's been tested there in a while |
| 23:37.50 | ezzieyguywuf | maybe its cuz I'm running it in gnome and not a qt-based DE |
| 23:38.07 | brlcad | shouldn't matter, but can describe your setup in the report |
| 23:38.37 | ezzieyguywuf | you sure that link you gave me is right? |
| 23:44.11 | CIA-14 | BRL-CAD: 03brlcad * r43712 10/brlcad/trunk/TODO: yet another, gqa gets in line |
| 23:46.53 | brlcad | iirc, it's actually the job of the terminal program to decide whether to kill or detact processes that are still running if a terminal session is closed |
| 23:46.54 | brlcad | so that might be a gnome-terminal issue |
| 23:46.54 | brlcad | but closing the graphics window should have exited mged |
| 23:46.54 | brlcad | it's right if you already have an sf account, otherwise, can go here: https://sourceforge.net/tracker/?group_id=105292&atid=640802 |
| 23:46.54 | brlcad | bug reports require an sf account so we can interact with the submitter |
| 23:53.39 | starseeker | aaand I wiped out the process that reproduced it |
| 23:53.40 | starseeker | lovely |
| 23:55.31 | starseeker | ah ha |
| 23:55.58 | brlcad | needs a good shader example |
| 23:59.30 | CIA-14 | BRL-CAD: 03starseeker * r43713 10/brlcad/trunk/src/librt/search.c: |
| 23:59.31 | CIA-14 | BRL-CAD: Looks like that doggone global was stuck in 'on', and because it started that |
| 23:59.31 | CIA-14 | BRL-CAD: way the plans never formed properly - they assumed no output command was needed |
| 23:59.31 | CIA-14 | BRL-CAD: when it was. The global was inherited from the design of find, and I never |
| 23:59.31 | CIA-14 | BRL-CAD: cared for it, but it'll be a bit of work to do it any other way so for now just |
| 23:59.31 | CIA-14 | BRL-CAD: make sure it's zero before we start forming plans. |
| 00:02.30 | starseeker | brlcad: I can't get it to enter the bad state again, but I just managed to see that that variable was on before I lost the other debug session |
| 00:02.44 | starseeker | pretty sure that's it - it would make sense |
| 00:07.57 | brlcad | what variable? |
| 00:08.03 | starseeker | db_search_isoutput |
| 00:08.14 | brlcad | static? |
| 00:08.27 | starseeker | checks... |
| 00:08.49 | brlcad | shouldn't really be anything static in the code pushed up into librt, or even the code in libged really |
| 00:08.49 | starseeker | no |
| 00:09.01 | brlcad | as that implies statefulness |
| 00:09.12 | starseeker | search.c in librt, line 103 |
| 00:09.44 | starseeker | it does control state during the building of the plan, iirc |
| 00:10.12 | brlcad | ahh, worse! |
| 00:10.13 | brlcad | global |
| 00:10.18 | brlcad | that's statefulness |
| 00:10.21 | starseeker | nods |
| 00:10.29 | starseeker | that's been thre |
| 00:10.33 | starseeker | s/thre/there |
| 00:10.36 | starseeker | from the get-go |
| 00:11.05 | starseeker | so probably we never stressed the other search implementation enough to spot it, or we got lucky and avoided any badness accidentally |
| 00:11.24 | brlcad | you have full controll of the calling params, should be easy to eliminate |
| 00:11.39 | starseeker | you mean pass it around? |
| 00:11.48 | brlcad | better than a global |
| 00:12.00 | brlcad | especially in a lib |
| 00:12.01 | starseeker | can do that, but it means changing a lot of function arg lists to match a new template |
| 00:12.08 | starseeker | nods |
| 00:12.44 | starseeker | I can do it, but not tonight - I'm a half hour late now :-/ |
| 00:12.57 | brlcad | at a minimum, the global could be changed to be a static scope global, so it's only accessible via those functions |
| 00:13.01 | brlcad | nods |
| 00:13.11 | brlcad | no worries, we have at least a couple days of debugging |
| 00:13.23 | starseeker | gqa blew up too... augh |
| 00:13.55 | starseeker | making sure the formation of the plan starts with it at zero should do for now, and next week I'll eliminate the global |
| 00:14.03 | brlcad | suspect gqa will be easy |
| 00:14.35 | starseeker | at least the pipe fix was kinda nifty - nice work on that (you and d_rossberg) |
| 00:14.59 | starseeker | (and ``Erik for suggesting clamp) |
| 00:16.48 | starseeker | while I'm at it, I'll try to get search . and search / to work - could cheat and just supply -name * by default if no plan is available |
| 00:17.21 | starseeker | or probably just -print |
| 00:18.01 | starseeker | actually, come to think of it that should be the result of calling db_search_formplan with an empty argv list - will have to confirm that |
| 00:18.15 | starseeker | heads out |
| 00:18.39 | brlcad | yeah, I suspect it'll just happen if you specify no plan |
| 00:29.04 | CIA-14 | BRL-CAD: 03brlcad * r43714 10/brlcad/trunk/src/librt/db5_types.c: put bu_vls_true() to use so that we can more robustly detect true/false string values for standard attributes. note that the bu_str_true() will match 'R' as true too since only clearly negative values constitute false. |
| 00:30.48 | CIA-14 | BRL-CAD: 03bob1961 * r43715 10/brlcad/trunk/src/libged/nirt.c: Fixed a bug in libged/nirt.c that was tripping in the /* skip commands */ section of the windows specific code when an object being passed to nirt contained -e in its name. |
| 00:36.29 | brlcad | pretty awesome: http://www.engineeringtv.com/video/Opposed-Piston-Opposed-Cylinder |
| 00:44.06 | CIA-14 | BRL-CAD: 03brlcad * r43716 10/brlcad/trunk/src/librt/db5_types.c: ws cleanup |
| 00:50.28 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 01:57.29 | *** join/#brlcad dloman_ (~claymore@BZ.BZFLAG.BZ) | |
| 01:58.33 | *** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ) | |
| 02:30.09 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 03:44.09 | starseeker | tofu: looks like the pipe fix is confirmed |
| 03:47.43 | CIA-14 | BRL-CAD: 03starseeker * r43717 10/brlcad/branches/cmake/ (10 files in 5 dirs): MFC r43716 |
| 04:23.47 | starseeker | aaaand libredwg doesn't get to first base |
| 04:30.28 | starseeker | growl... http://www.opendesign.com/teigha_viewer can view 'em but not export 'em |
| 04:31.29 | brlcad | starseeker: those are prime for import into autocad or proe then export as iges, step, and dxf |
| 04:32.42 | starseeker | nods - proe can read them and export them as a number of things (including pdf, which is probably most immediately useful since they aren't solid) but it'll be a long slog to do 180 one by one (especially into multiple formats) |
| 04:33.08 | starseeker | installed rpm on gentoo just to get that viewer, too... grumble |
| 04:33.18 | brlcad | iirc, proe on the linux side can be scripted |
| 04:52.14 | CIA-14 | BRL-CAD: 03brlcad * r43718 10/brlcad/trunk/src/libbu/booleanize.c: |
| 04:52.14 | CIA-14 | BRL-CAD: expand on bu_str_true() so that we can distinguish more strongly between values |
| 04:52.14 | CIA-14 | BRL-CAD: that seem to be false or true and 'everything else'. Unrecognized responses |
| 04:52.14 | CIA-14 | BRL-CAD: still return as true, but should return as >1 so callers can distinguish yes/no |
| 04:52.14 | CIA-14 | BRL-CAD: from possible input exceptions. return the first character as the exception |
| 04:52.15 | CIA-14 | BRL-CAD: value for posterity. |
| 04:52.49 | CIA-14 | BRL-CAD: 03brlcad * r43719 10/brlcad/trunk/include/bu.h: document that callers can distinguish potential exceptions with return values >1 |
| 05:24.33 | CIA-14 | BRL-CAD: 03brlcad * r43720 10/brlcad/trunk/src/mged/cmd.c: even with the plain wrapper, if the ged func returns GED_MORE, respect its authoritah |
| 06:09.56 | CIA-14 | BRL-CAD: 03brlcad * r43721 10/brlcad/trunk/src/mged/cmd.c: (log message trimmed) |
| 06:09.56 | CIA-14 | BRL-CAD: implement some nifty redraw code that looks at what objects are displayed and |
| 06:09.56 | CIA-14 | BRL-CAD: what command-line arguments were specified. if displayed objects are being |
| 06:09.56 | CIA-14 | BRL-CAD: listed on the command line, then they are potentially being edited so go ahead |
| 06:09.57 | CIA-14 | BRL-CAD: and redraw them. while this might cause redraw lag for huge models on commands |
| 06:09.57 | CIA-14 | BRL-CAD: that are merely read-only, the more common problem is the display not being |
| 06:09.58 | CIA-14 | BRL-CAD: refreshed when it should for commands that DO edit the geometry, leading to user |
| 06:14.10 | CIA-14 | BRL-CAD: 03brlcad * r43722 10/brlcad/trunk/NEWS: |
| 06:14.10 | CIA-14 | BRL-CAD: with the automatic redraw code now in the base wrapper, about 120 mged commands |
| 06:14.10 | CIA-14 | BRL-CAD: will potentially refresh the display that would have otherwise including dozens |
| 06:14.10 | CIA-14 | BRL-CAD: that modify geometry. display updates on changes should improve usability, |
| 06:14.11 | CIA-14 | BRL-CAD: reduce confusion, and help mged be more consistent |
| 06:18.25 | CIA-14 | BRL-CAD: 03brlcad * r43723 10/brlcad/trunk/src/libged/mater.c: (log message trimmed) |
| 06:18.25 | CIA-14 | BRL-CAD: restore incremental prompting functionality to the mater command. even better |
| 06:18.25 | CIA-14 | BRL-CAD: than before. leverage GED_MORE for additional prompting for any unspecified |
| 06:18.25 | CIA-14 | BRL-CAD: arguments. also takes advantage of bu_str_true()'s ability to detect input |
| 06:18.25 | CIA-14 | BRL-CAD: exceptions. this feature was prompted by discussions with ezzieyguywuf via IRC |
| 06:18.25 | CIA-14 | BRL-CAD: and having run into the problem myself several times, where mater |
| 06:18.26 | CIA-14 | BRL-CAD: unintentionally stopped prompting for missing arguments when it was migrated to |
| 06:23.41 | CIA-14 | BRL-CAD: 03brlcad * r43724 10/brlcad/trunk/NEWS: |
| 06:23.41 | CIA-14 | BRL-CAD: restored interactive prompting for mged's 'mater' command, which was |
| 06:23.41 | CIA-14 | BRL-CAD: functionality lost during the migration to libged.this feature was prompted |
| 06:23.41 | CIA-14 | BRL-CAD: after discussions with ezzieyguywuf via IRC and after having run into the |
| 06:23.41 | CIA-14 | BRL-CAD: problem myself several times while modeling. tutorial documentation was |
| 06:23.41 | CIA-14 | BRL-CAD: inconsistent as it relied on the interactive prompting for instruction. |
| 06:24.55 | *** join/#brlcad Stattrav (~Stattrav@122.167.249.60) | |
| 06:24.55 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:52.55 | CIA-14 | BRL-CAD: 03brlcad * r43725 10/brlcad/trunk/src/libged/mater.c: restore the previous mater command behavior to report the current values being set when prompting the user for new values. approximate the old text not worry too much about getting a perfect match. |
| 06:59.31 | CIA-14 | BRL-CAD: 03brlcad * r43726 10/brlcad/trunk/src/libged/mater.c: go ahead and expand the green and blue component values. also make it clear that the values being shown are the current values. |
| 07:04.01 | *** join/#brlcad Stattrav (~Stattrav@122.167.168.51) | |
| 07:04.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:59.27 | CIA-14 | BRL-CAD: 03brlcad * r43727 10/brlcad/trunk/src/libged/mater.c: |
| 07:59.28 | CIA-14 | BRL-CAD: further efforts to mime the old behavior or better. make the g and b color |
| 07:59.28 | CIA-14 | BRL-CAD: components optional once again if the color is being deleted. add back support |
| 07:59.28 | CIA-14 | BRL-CAD: for deleting the shader string and color setting. use '.' to skip parameters |
| 07:59.28 | CIA-14 | BRL-CAD: (here we deviate from original since we can't yet set default more parameters. |
| 08:00.25 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 08:02.00 | CIA-14 | BRL-CAD: 03brlcad * r43728 10/brlcad/trunk/src/libged/mater.c: fix the prompt if we're skipping/deleting the color, account for an offset of two. |
| 08:02.10 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:10.22 | *** part/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 08:17.43 | CIA-14 | BRL-CAD: 03brlcad * r43729 10/brlcad/trunk/src/libged/mater.c: offset pushing towards the wrong direction, be positive. also catch the error case where color has been deleted but then later is 'skipped'. |
| 08:25.46 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 08:29.56 | CIA-14 | BRL-CAD: 03brlcad * r43730 10/brlcad/trunk/src/libged/mater.c: tweak the usage, let user know which channel is teh suck |
| 08:30.36 | CIA-14 | BRL-CAD: 03brlcad * r43731 10/brlcad/trunk/doc/docbook/lessons/en/mged11_refining_mug.xml: update tutorial example interactive output for the mater command to reflect new form |
| 08:32.15 | CIA-14 | BRL-CAD: 03brlcad * r43732 10/brlcad/trunk/TODO: mater now properly prompts for missing parameters interactively |
| 08:35.51 | *** join/#brlcad Stattrav (~Stattrav@122.172.15.235) | |
| 08:35.51 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:37.26 | CIA-14 | BRL-CAD: 03brlcad * r43733 10/brlcad/trunk/ (NEWS TODO): |
| 08:37.26 | CIA-14 | BRL-CAD: bob reportedly fixed the bug causing nirt to not work on windows. user reported |
| 08:37.26 | CIA-14 | BRL-CAD: that nirt on windows was failing if run in a command window. bob found a |
| 08:37.26 | CIA-14 | BRL-CAD: problem where it was getting tripped up on objects with '-e' in their name. |
| 09:22.29 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 09:57.52 | *** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) | |
| 11:13.16 | CIA-14 | BRL-CAD: 03jordisayol * r43734 10/brlcad/trunk/sh/ (make_deb.sh make_rpm.sh): update copyright to 2011 |
| 13:11.14 | starseeker | makes a note to check into Pro/Batch |
| 13:30.42 | starseeker | yeah... the Tegiha file convertor worked under wine, and librecad can open the dxf files (so can we with dxf-g) but there aren't any good ways I can find to get decent pdf output - gonna have to use Pro/Batch or something like it |
| 13:46.46 | starseeker | O.o freecad is in main portage now? (wrong category, media-gfx, but still...) |
| 13:47.16 | starseeker | tries it... haven't had great luck with the sci overlay builds to date... |
| 14:34.06 | CIA-14 | BRL-CAD: 03starseeker * r43735 10/brlcad/branches/cmake/src/librt/ (search.c search.h): |
| 14:34.06 | CIA-14 | BRL-CAD: Globals are evil - need to pass db_search_isoutput around as a parameter during |
| 14:34.06 | CIA-14 | BRL-CAD: the process of forming the plan. As a side benefit, it shouldn't be necessary |
| 14:34.06 | CIA-14 | BRL-CAD: for f_print to reset the value anymore, since the scope of the variable is now |
| 14:34.06 | CIA-14 | BRL-CAD: limited to the plan forming process |
| 14:34.30 | starseeker | brlcad: I think that's got it |
| 14:34.44 | starseeker | still need to fix behavior for search . and friends |
| 14:50.27 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 15:01.40 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 15:03.31 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 15:03.46 | *** part/#brlcad piksi (piksi@pi-xi.net) | |
| 15:40.28 | ezzieyguywuf | wow, brlcad you've been busy. |
| 15:40.36 | ezzieyguywuf | I still need to submit that bug report... |
| 16:04.03 | ezzieyguywuf | ah, another discrepency I noticed in the tutorials is when it tells you to cp certain shapes, it never tells you that you have to draw them first before you can do anything to them. |
| 16:31.30 | starseeker | those hessi dwg files may be even more extensive than simplesat... |
| 16:31.35 | starseeker | sweet |
| 16:48.18 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 17:35.17 | ezzieyguywuf | heh, I'm running mged vers 7.16.8 which is > vers 6.0 so according to the tute the order of inside should be botto-top-rear-front-right-left but instead I got front-rear-right-left-bottom-top |
| 17:36.50 | vtts | are all menu actions executable from command line? e.g. is it possible to enter multi pane mode, set active pane, show model axes on it and so on? |
| 17:41.44 | ezzieyguywuf | vtts: pretty sure you can. checkout the quick reference card. |
| 17:42.11 | vtts | didn't find it there |
| 17:42.14 | ezzieyguywuf | hrm. |
| 17:42.42 | vtts | i can change view options of an active pane, but don't know how tu change mode or switch to other pane |
| 17:43.30 | vtts | found a few functions in the source, but don't know where to get id from (e.g. setmv id) |
| 17:44.43 | vtts | eh... silly me... id is on the title bar |
| 17:44.59 | vtts | does a face-palm action |
| 17:45.24 | ezzieyguywuf | :-D |
| 18:04.20 | ezzieyguywuf | hrm, still no dotted lines for me.... |
| 18:33.23 | ezzieyguywuf | so man, its taking a while for the raytracer to raytrace this toy truck. sometimes it even fails. Could it be I'm doing something wrong? |
| 18:33.38 | ezzieyguywuf | I would expect perfermance for something of this simple geometry to be pretty good. |
| 18:36.08 | ezzieyguywuf | http://ompldr.org/vN29hYw screenshot of raytrace after ~1min |
| 19:40.56 | *** join/#brlcad Stattrav (~Stattrav@117.192.133.151) | |
| 19:40.56 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:15.05 | ezzieyguywuf | so....what are my chances of modelling an airfoil using brl-cad? |
| 22:22.24 | CIA-14 | BRL-CAD: 03jordisayol * r43736 10/brlcad/trunk/ (10 files in 3 dirs): add new GNU/Linux mime-type icons for geometry db file v.4 and v.5 |
| 23:13.39 | Ralith | Would there be any interest in an effort to add GPU accelereation to the raytracer? |
| 23:58.35 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 00:07.51 | starseeker | Ralith: I'm sure there would be, but I doubt it would be easy |
| 00:07.56 | starseeker | what did you have in mind? |
| 00:08.38 | starseeker | ezzieyguywuf: with what fidelity? real airfoil modeling is usually done with NURBS as far as I know, due to the need for precision surface contour control |
| 00:12.32 | starseeker | we can raytrace NURBS, but we can't yet model them |
| 00:14.05 | starseeker | brlcad: this looks interesting: http://snap.lbl.gov/pubdocs/SNAP_Solid_Model_Rev_A.stp |
| 00:15.02 | starseeker | another one here: http://planetquest.jpl.nasa.gov/documents/TPF-C_assy.stp |
| 00:15.49 | starseeker | http://www.pppl.gov/tritium/ |
| 00:19.27 | Ralith | starseeker: been playing around with OpenCL lately and having fun, mostly |
| 00:19.35 | starseeker | cool |
| 00:19.56 | starseeker | Ralith: brlcad knows more about how that would apply - I know it's of interest |
| 00:20.01 | Ralith | kk |
| 00:25.25 | starseeker | brlcad: if step-g is right, the snap, tpf-c, and tritium models all contain solid breps |
| 00:32.13 | starseeker | http://des-docdb.fnal.gov/cgi-bin/ShowDocument?docid=4041&version=1 - iges files |
| 00:34.51 | starseeker | http://www-eng.lbl.gov/~hoff/ALICE/ |
| 01:04.39 | starseeker | that's actually fairly nifty: http://des-docdb.fnal.gov/0040/004041/001/BLANCO-DECAM%20MODEL.bmp |
| 01:25.01 | starseeker | oh, wow |
| 01:25.05 | starseeker | http://des-docdb.fnal.gov/cgi-bin/ShowDocument?docid=336&version=22 |
| 01:25.11 | starseeker | http://des-docdb.fnal.gov/0003/000336/022/BLANCO%20STEP%20FILE%20AUG%2031%202009.jpg |
| 01:40.57 | brlcad | ezzieyguywuf: you shouldn't have to draw to cp -- you only have to draw if you intend to modify/edit them |
| 01:49.32 | brlcad | vtts: yes, they pretty much are all accessible, though some are really tricky on the command line or are completely undocumented or assume tk or ... |
| 01:52.04 | brlcad | vtts: to turn model axes on/off, see the 'rset' command -- in particular "rset ax", "rset ax model_draw 1" |
| 02:06.07 | brlcad | to set multipane, it takes two commands: set mged_gui(id_0,multi_pande) 1 ; setmv id_0 |
| 02:07.50 | brlcad | oops, not pande :) pane |
| 02:13.14 | brlcad | setting the active pane is similar: set mged_gui(id_0,dm_loc) ul ; set_active_dm id_0 |
| 02:13.27 | brlcad | ul | ur | ll | lr |
| 02:17.38 | brlcad | ezzieyguywuf: yeah, something doesn't sound right -- that should be nearly instantaneous, can post your .g and I'll take a look at it, but from your cpu monitor something is definitely fishy with them both reporting ~90% |
| 02:18.59 | brlcad | Ralith: there's always interest in improving raytrace performance, so long as it's validated too ... it's really easy to go fast, it's a lot harder to go fast and be verifiably correct |
| 02:20.48 | brlcad | starseeker: woot! that's an awesome iges find ... |
| 02:21.07 | brlcad | 220MB engine model |
| 02:26.08 | Ralith | brlcad: what all's involved in ensuring validity? |
| 02:28.01 | brlcad | depends on the type of changes |
| 02:29.41 | brlcad | but usually, current behavior is considered a baseline, regression tests are set up, then the new implementation is compared to the existing/old implementation, and any differences beyond floating point tolerance have to be explainable (or ideally, no differences) |
| 02:30.28 | brlcad | basically the new has to be compared to the current and differences have to be explainable |
| 02:30.42 | brlcad | even subtle grazing cases |
| 02:32.26 | brlcad | for our practical purposes, the common testing we usually perform are to have baseline raytrace images, then generate a new set of images with the new code |
| 02:33.16 | cjdevlin | could this (eventually) be useful in maintaining a windows build: http://coapp.org/ ?\ |
| 02:33.45 | brlcad | 1 RGB value difference in any one channel ("off-by-one") is considered ok; anything more is considered a deviation that is an error in one of the two implementations |
| 02:34.45 | brlcad | cjdevlin: for smaller projects that don't do proper external dependency management, probably |
| 02:35.22 | brlcad | otherwise, it's not very interesting since we ship an exe that has everthing needed to run, and we have everything needed to compile from source with a checkout |
| 03:14.14 | Ralith | sounds fairly straightforward |
| 03:17.54 | brlcad | yep, the process is pretty simple -- actually figuring out why something ends up different is the hard part |
| 03:18.08 | brlcad | especially for grazing |
| 03:18.34 | brlcad | can't brush anything off as just computation difference |
| 03:41.54 | brlcad | starseeker: I think I've now downloaded almost everything you listed and a lot more :) |
| 04:17.43 | starseeker | brlcad: heh - what else did you find? |
| 04:18.23 | starseeker | concentrated on the BLANCO models from fermi due to bandwidth issues... |
| 04:19.49 | starseeker | dunno for the life of me why they didn't gzip the step/iges files, it makes an enormous difference |
| 06:05.45 | brlcad | just more models |
| 06:06.04 | brlcad | all related to those projects |
| 06:06.17 | brlcad | a few other peripheral items, drawings |
| 06:19.11 | ezzieyguywuf | brlcad: still want to see the .g for my toy truck? I moved on to the walkie-talkie and had no slowness with that. |
| 06:19.36 | ezzieyguywuf | as far as my airfoil questions, I have some x-y coordinate files with about, I dunno, 200 points. That's as high a fidelity as I need. |
| 06:19.53 | ezzieyguywuf | I know NACA airfoils have an equation associated with them, and it'd be great to be able to model those... |
| 06:20.11 | ezzieyguywuf | http://ompldr.org/vN29sMg <--- truck.g |
| 07:29.26 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 09:23.10 | *** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no) | |
| 12:24.50 | starseeker | ezzieyguywuf: airfoil shapes are a little bit tricky |
| 12:26.34 | starseeker | you might be able to get close-ish with ell, rpc, rhc, and friends in various combinations but the primitive paramaters there aren't likely to correspond to the airfoil parameters, and to really do an airfoil shape properly you almost certainly need NURBS |
| 12:27.18 | starseeker | if you have xy points, an interesting possibility might be to create a proc-db that took those xy points and generated spline curves with them... |
| 12:27.42 | starseeker | but that's not going to be easy |
| 12:33.04 | vtts | whats is the command equivalent for "Move Face 1234" for later use with tra? |
| 12:36.14 | starseeker | vtts: um... unfortunately, I don't know of any way to select a particular face other than the gui |
| 12:36.37 | starseeker | there may be one, but if so I don't know offhand what it is |
| 12:37.01 | starseeker | would have to dig into the source code |
| 12:37.27 | vtts | the menu executes: press "Move Face 1234" |
| 12:38.40 | vtts | or something like that |
| 12:40.05 | vtts | although facedef does something like that in one shot |
| 12:43.17 | vtts | just would be nice to have an alternative which works with offsets |
| 16:13.34 | *** join/#brlcad Stattrav (~Stattrav@117.192.130.135) | |
| 16:13.34 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:43.06 | starseeker | turns on all the warnings for opennurbs and watches the slaughter... ho boy |
| 17:44.14 | starseeker | lot of unsafe floating point comparisons... wonder if I can safely script a search/replace for those with a near_zero macro... |
| 17:45.27 | starseeker | mutter... unused params too... may need the UNUSED macro |
| 17:46.16 | starseeker | yeah, probably not scriptable |
| 19:38.44 | ezzieyguywuf | starseeker: so, tl;dr is that there is not really a good way to make an accurate airfoil using brl-cad at the moment? |
| 19:38.55 | ezzieyguywuf | I'll be rapid-prototyping this thing, so a 'ruff estimate' won't suffice. |
| 19:39.32 | starseeker | ezzieyguywuf: yeah, that's an accurate statement |
| 19:43.53 | ezzieyguywuf | grumbles. |
| 20:00.38 | brlcad | ezzieyguywuf: you could import your 200ish points into BRL-CAD directly as a point cloud or polygonal mesh data, but the problem will be deriving a smooth surface that fit those points |
| 20:01.09 | brlcad | without knowing the equations, anything you create is going to be an approximation |
| 20:01.28 | ezzieyguywuf | brlcad: I know the equation, I found it in wikipedia :-P |
| 20:01.39 | brlcad | you can make a perfect-fit surface for those 200ish points (using a smoothed mesh), but it'll still be a mesh |
| 20:02.02 | ezzieyguywuf | I see where the problem is though: usually, I import the 2D airfoil data and extrude it, but in brl-cad we work with solid primitives from the get-go |
| 20:02.25 | brlcad | we support extrusions from 2D |
| 20:02.33 | ezzieyguywuf | really? how? |
| 20:02.38 | brlcad | our 2D shapes support points, polylines, arcs, and bsplines |
| 20:03.09 | brlcad | it's not great for interactive editing, to say the least -- meant more for data import -- but it's possible |
| 20:03.12 | brlcad | http://brlcad.org/wiki/Sketch |
| 20:03.36 | ezzieyguywuf | Hrm, maybe I haven't read enough of the documenation, but from everything I've done its 'create a box, create another smaller one and subtract that from the first' etc etc |
| 20:03.48 | brlcad | easier would probably be to mode the 2D sketch in QCAD, export that as dxf, import into BRL-CAD as a sketch, then extrude |
| 20:04.06 | brlcad | sketch isn't going to be covered by that tutorial series |
| 20:04.19 | brlcad | there are a half dozen or more advanced primitives like that |
| 20:04.55 | ezzieyguywuf | interesting. |
| 20:07.55 | starseeker | needs to study doxygen some.. will have to be careful here. |
| 20:08.11 | starseeker | conversion isn't automatable, from the looks of it |
| 20:09.35 | starseeker | icu is a good example at least... *read*read*read* |
| 21:07.42 | *** join/#brlcad Stattrav (~Stattrav@117.192.135.227) | |
| 21:07.42 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:12.06 | vtts | how to make wireframe with hidden lines? "z clipping" doesn't seem to work :/ |
| 21:52.20 | *** join/#brlcad kanzure_ (~kanzure@bioinformatics.org) | |
| 21:53.02 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 01:14.33 | starseeker | vtts: rtedge |
| 03:43.26 | brlcad | starseeker: so good news is I figured out the cause for why the combination editor no longer works, bad news is it was the pacakge require replacements you put in leu of ITcl_Init() in mged's setup.c |
| 03:56.28 | CIA-14 | BRL-CAD: 03brlcad * r43737 10/brlcad/trunk/ (NEWS TODO src/mged/setup.c): |
| 03:56.29 | CIA-14 | BRL-CAD: fixed the combination editor. didn't achieve understanding into the underlying |
| 03:56.29 | CIA-14 | BRL-CAD: cause (left as an exercise to the reader), but changing Itcl_Init() to a |
| 03:56.29 | CIA-14 | BRL-CAD: 'package require Itcl' was not equivalent. iwidgets ends up attempting to |
| 03:56.29 | CIA-14 | BRL-CAD: create a class twice (LabeledFrame) causing a runtime error. changed back so |
| 03:56.29 | CIA-14 | BRL-CAD: release can progres. |
| 04:03.00 | CIA-14 | BRL-CAD: 03brlcad * r43738 10/brlcad/trunk/src/util/: rtwizard moved to tclscripts |
| 04:08.36 | CIA-14 | BRL-CAD: 03brlcad * r43739 10/brlcad/trunk/src/tclscripts/rtwizard/rtwizard.tcl: use the same initialization approach archer uses so rtwizard will run prior to installation |
| 04:19.24 | CIA-14 | BRL-CAD: 03brlcad * r43740 10/brlcad/trunk/src/bwish/ (cadAppInit.c main.c): |
| 04:19.24 | CIA-14 | BRL-CAD: same patch applied to mged for unbreaking the Combination Editor applies here. |
| 04:19.24 | CIA-14 | BRL-CAD: confirmed that archer and rtwizard were non-functional, would not start, due to |
| 04:19.24 | CIA-14 | BRL-CAD: multiple class errors. this reverts the package require back to an Itcl_Init(), |
| 04:19.24 | CIA-14 | BRL-CAD: itk too. archer/rtwizard now start up again. |
| 04:23.05 | brlcad | vtts: the bug you reported here is now fixed, thanks |
| 04:26.52 | CIA-14 | BRL-CAD: 03brlcad * r43741 10/brlcad/trunk/NEWS: (log message trimmed) |
| 04:26.53 | CIA-14 | BRL-CAD: may or may not be specific to Mac OS X, but the bug report and confirmation were |
| 04:26.53 | CIA-14 | BRL-CAD: both on Mac OS X. the bug prevented both archer and rtwizard (both bwish-based) |
| 04:26.53 | CIA-14 | BRL-CAD: from running. they'd abort out during initialization with a multiple class |
| 04:26.53 | CIA-14 | BRL-CAD: error. problem was isolated as a change to the way bwish initialized. thanks |
| 04:26.53 | CIA-14 | BRL-CAD: to vtts for reporting the related combination editor bug via IRC. Runtime |
| 04:26.54 | CIA-14 | BRL-CAD: release testing for the previous release presumably happened on Linux, so this |
| 04:30.52 | starseeker | is getting rather tired of Itcl/Itk |
| 04:31.04 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 04:31.10 | brlcad | oops |
| 04:31.15 | starseeker | is getting rather tired of Itcl/Itk |
| 04:32.19 | brlcad | I presume those package require changes were tested on Linux? |
| 04:32.39 | starseeker | I've been using them to do everything for a while now |
| 04:32.58 | starseeker | Windows, Mac and Linux |
| 04:33.14 | brlcad | on Mac? rtwizard loads? |
| 04:33.33 | starseeker | dunno about rtwizard - will have to check tomorrow if I can make it in |
| 04:33.42 | starseeker | has a leak somewhere |
| 04:33.47 | brlcad | mged would start just fine, it wasn't until it hit a panel that used iwidgets |
| 04:33.49 | starseeker | basement carpet is wet |
| 04:33.55 | brlcad | fun! |
| 04:33.57 | brlcad | not |
| 04:34.07 | starseeker | and we found out one of our cats has gone blind |
| 04:34.13 | starseeker | this has been a real kicker of a weekend |
| 04:34.14 | brlcad | aw |
| 04:43.46 | CIA-14 | BRL-CAD: 03brlcad * r43742 10/brlcad/trunk/TODO: search seems to be working much better now, but noticed several non-critical test failures that current usage docs (and reasonable expectations) indicate they should work. most are pretty simple. |
| 07:10.55 | *** join/#brlcad ibot (~ibot@198.60.114.207) | |
| 07:10.55 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202) | |
| 09:06.27 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 09:15.17 | *** join/#brlcad Stattrav (~Stattrav@117.192.250.99) | |
| 09:15.17 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:23.05 | *** join/#brlcad Stattrav (~Stattrav@122.172.203.101) | |
| 10:23.05 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:06.05 | dloman | yawns |
| 11:08.33 | dloman | So.... if a cmake find script isn't finding libraries... where should i put the paths to the libs? in PATH or LD_LIBRARY_PATH ? |
| 11:21.26 | Ralith | might as well try and see |
| 11:27.04 | *** join/#brlcad Stattrav (~Stattrav@117.192.225.133) | |
| 11:27.04 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:56.19 | *** join/#brlcad Stattrav (~Stattrav@117.192.238.155) | |
| 11:56.19 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:13.44 | starseeker | dloman: depends on the script |
| 12:13.49 | starseeker | which script is failing? |
| 12:19.21 | dloman | findqt |
| 12:19.38 | starseeker | try putting the bin directory that has the qt binaries in PATH |
| 12:19.39 | dloman | at i verified qt is in /usr/lib32 |
| 12:19.44 | dloman | right on |
| 12:19.49 | dloman | just sat back down |
| 12:19.54 | dloman | gonna try that very thing :) |
| 12:20.01 | starseeker | heh |
| 12:22.08 | dloman | so yeah.... lots of rain + sudden temp drop + stupid winds == nastly little mess up here. |
| 12:22.41 | dloman | one entire side of my jeep is coated in 1/2" of snow/ice stuff that's hard as a rock. |
| 12:22.48 | starseeker | ow |
| 12:22.50 | dloman | broke both my ice chippers on it. |
| 12:23.15 | starseeker | is trying to figure out where the water that soaked his closet carpet is coming from... |
| 12:23.35 | dloman | check the walls. |
| 12:23.42 | dloman | we just had a leak fixed. |
| 12:23.42 | starseeker | guessing either the roof finally gave up the ghost or a hole in the siding over the front door... |
| 12:23.54 | starseeker | walls are pretty dry |
| 12:24.00 | dloman | ours were too :) |
| 12:24.12 | dloman | leaking in the second story (of 3 stories) |
| 12:24.24 | dloman | was running down a beam or two in the main load bearing wall. |
| 12:24.28 | dloman | crazy |
| 12:24.38 | starseeker | dloman: who did you call to get it taken care of? |
| 12:24.57 | dloman | oh man. Its the contractor that originally put our roof on. |
| 12:25.08 | starseeker | ah |
| 12:25.11 | dloman | name is down stairs, but its a MD contractor |
| 12:25.28 | dloman | $200 min visit fee, but that covers 90% of leak fixes and shingle replacements. |
| 12:25.55 | starseeker | sounds interesting |
| 12:30.07 | dloman | ill dig up the name the next time I head downstairs. |
| 12:32.35 | starseeker | dloman: awesome, thanks |
| 12:36.34 | dloman | So who knew: Batman Begins score == great coding music :) |
| 12:37.01 | starseeker | hehe |
| 12:37.20 | starseeker | probably won't be in today, or if he is it'll be later |
| 12:37.41 | starseeker | need to schedule leak fix due and get dehumidifier rented |
| 12:47.21 | dloman | Cranford Contractors: 410 792 7663 |
| 12:47.40 | dloman | they got here pretty quick (2 day turnaround) considering all the wind we've been having lately |
| 12:48.02 | dloman | this is my first experience with them, but they seemed to have fixed up the roof pretty well. |
| 12:50.52 | starseeker | hmm... I probably need somebody to deal with siding as well as roof |
| 12:53.40 | dloman | ah bloody hell. |
| 12:53.52 | dloman | :/ gotta get QT. |
| 12:53.59 | starseeker | hehe |
| 12:54.17 | dloman | thought it was installed, but noooooo. nothing can be that easy |
| 12:55.28 | dloman | I so need an 8 core laptop..... |
| 13:12.38 | brlcad | PATH is binaries, LD_LIBRARY_PATH is libraries (for linux/bsd, not other platforms) |
| 13:13.17 | dloman | brlcad: kk awesome |
| 13:23.34 | dloman | hahaha, just a a film trailer for "Inner city vs Outer space" |
| 13:23.47 | dloman | street thugs vs space aliens |
| 13:23.54 | dloman | aaaahahahaha, i love it. |
| 13:24.06 | dloman | "Attack the Block" i think its called. |
| 14:38.20 | *** join/#brlcad ezzieyguywuf (~wolfie@unaffiliated/ezzieyguywuf) | |
| 14:42.36 | epileg | brlcad: actual trunk successfully compile in ubuntu and fedora, but i get errors in opensuse, and i'm a bit lost. Can You help me please? |
| 14:42.36 | epileg | http://paste.debian.net/109872/ |
| 15:08.37 | ezzieyguywuf | [10:08:27] IRCnet: irc.freenode.net:6667 (IRCnet) |
| 15:08.39 | ezzieyguywuf | whoops |
| 15:14.57 | CIA-14 | BRL-CAD: 03davidloman * r43743 10/geomcore/trunk/src/utility/ (Config.cxx GSUuid.cxx): Add some includes to make compiling on Ubuntu 10.10 work. |
| 15:21.33 | CIA-14 | BRL-CAD: 03davidloman * r43744 10/geomcore/trunk/ (2 files in 2 dirs): More includes to make compiling on Ubuntu 10.10 work. |
| 15:25.38 | CIA-14 | BRL-CAD: 03davidloman * r43745 10/geomcore/trunk/src/GS/GSClient.cxx: cast uint64_t to long long to make printf happy |
| 15:30.43 | CIA-14 | BRL-CAD: 03davidloman * r43746 10/geomcore/trunk/ (3 files in 2 dirs): Final round of adding includes to make compiling on Ubuntu 10.10 work. |
| 15:49.30 | CIA-14 | BRL-CAD: 03erikgreenwald * r43747 10/brlcad/trunk/misc/win32-msvc8/librt/librt.vcproj: add search.c |
| 16:12.37 | brlcad | epileg: sure, the key there is "warnings being treated as errors" |
| 16:13.21 | brlcad | so either "make STRICT_FLAGS=" or run configure with --disable-strict |
| 16:14.41 | epileg | ok, i'll try with "--disable-strict" |
| 16:31.24 | CIA-14 | BRL-CAD: 03brlcad * r43748 10/brlcad/trunk/src/libfb/tcl.c: expand the function declarations from K&R form to complete 'real' prototypes. these probably belong in a lifb_private.h header or (better) wrapped into a callback btable. |
| 16:31.46 | brlcad | that should quell the warning too |
| 16:41.08 | epileg | brlcad: solved! successfully compile and install on openSUSE |
| 16:42.34 | epileg | BTW I do not find the way to make an application as default for some mime-type in KDE. no problem in GNOME. Someone nows how to do it? |
| 16:42.46 | epileg | *knows |
| 16:50.36 | *** join/#brlcad Stattrav (~Stattrav@117.192.144.236) | |
| 16:50.36 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:03.13 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.145.13) | |
| 17:11.23 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:30.51 | dloman | Is there a built in try/catch framework inside the TCL we use? |
| 17:40.24 | vtts | brlcad, thanks for the fix, just checked it, works like a charm |
| 17:43.54 | vtts | if you are in the mood, there is another one, with "archer -h": http://pastebin.com/unDAYkfJ |
| 17:44.17 | vtts | mac os x, r43748 build with --enable-all |
| 17:45.00 | vtts | although launching it with other options doesn't cause this |
| 17:45.47 | vtts | unfortunately i don't have ogl support, so cannot see anyting past the startup screen |
| 18:03.01 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.142.105) | |
| 18:12.10 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.168) | |
| 18:12.10 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:25.43 | ``Erik | well, poop, tcl ignores --disable-64bit-build |
| 18:35.13 | dloman | So it turns out that the Children of Dune OST is pretty darn good. |
| 18:41.15 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.138.0) | |
| 18:51.14 | CIA-14 | BRL-CAD: 03davidloman * r43749 10/geomcore/trunk/src/libJob/JobManager.cxx: QT ripout cleanup: JobManager *should* start workers when JobManager::start() is called. |
| 18:57.43 | CIA-14 | BRL-CAD: 03brlcad * r43750 10/brlcad/trunk/BUGS: archer's kill command seems to be working better now |
| 18:59.04 | CIA-14 | BRL-CAD: 03brlcad * r43751 10/brlcad/trunk/TODO: write up a bunch of archer to-do tasks that are necessary before archer can go into beta (some are even alpha blockers). mostly focusing on usability and migration. |
| 19:01.33 | CIA-14 | BRL-CAD: 03davidloman * r43752 10/geomcore/trunk/ (include/AbstractJob.h src/libJob/AbstractJob.cxx): Wire UUIDs back into abstractjob. |
| 19:13.19 | CIA-14 | BRL-CAD: 03davidloman * r43753 10/geomcore/trunk/tests/libJob/ (BasicJMTest.cxx PrintToStdOutJob.cxx): Get BasicJMTest working again. |
| 19:15.04 | CIA-14 | BRL-CAD: 03davidloman * r43754 10/geomcore/trunk/tests/libJob/BasicJMTest.cxx: Bad Developer: Redundant delete calls for JM. Forgot to delete PrintToStdOutJob objects on exit. |
| 19:25.38 | CIA-14 | BRL-CAD: 03davidloman * r43755 10/geomcore/trunk/docs/CMakeLists-Template.txt: Drop template. Very outdated. |
| 19:29.11 | CIA-14 | BRL-CAD: 03davidloman * r43756 10/geomcore/trunk/tests/coreInterface/: Drop coreInterface test ....dunno how I missed removing this earlier. |
| 19:30.35 | CIA-14 | BRL-CAD: 03davidloman * r43757 10/geomcore/trunk/tests/ (libEvent/BasicEventTest.cxx libNet/PrintingMsgHandler.h): Remove a few lingering QT ghosts |
| 19:34.46 | CIA-14 | BRL-CAD: 03davidloman * r43758 10/geomcore/trunk/src/ (CMakeLists.txt adminpanel/): Drop Adminpanel. Old research project that is no longer useful. |
| 19:36.53 | CIA-14 | BRL-CAD: 03davidloman * r43759 10/geomcore/trunk/include/ (AppLauncher.h BaseApp.h): Drop unused application launch framework. |
| 19:37.36 | CIA-14 | BRL-CAD: 03davidloman * r43760 10/geomcore/trunk/src/libJob/ (JobWorker.cxx JobWorker.h): Remove a few more lingering QT ghosts |
| 19:43.14 | CIA-14 | BRL-CAD: 03davidloman * r43761 10/geomcore/trunk/CMakeLists.txt: Remove CMake's search for QT. ....and with that, Geomcore is 100% qt free. |
| 19:43.45 | brlcad | woot |
| 19:44.03 | brlcad | horay for simplified dependency management ;) |
| 19:46.47 | CIA-14 | BRL-CAD: 03brlcad * r43762 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: unnecessary cast |
| 19:48.05 | ``Erik | adminpanel doesn't require qt? or is it not part? |
| 19:48.32 | dloman | it was a research thingy |
| 19:48.39 | dloman | already been superseded |
| 19:48.48 | dloman | so i just deleted it. |
| 19:49.43 | ``Erik | aight, cool.. saw some gui pieces, so I wasn't touching it |
| 19:54.54 | dloman | ``Erik: starseeker thanks for all the help! |
| 19:57.33 | starseeker | that reminds me - the assembly and region trial on Friday succeed in something like 30 seconds as opposed to 5 minutes for havoc |
| 19:59.08 | starseeker | dloman: you're welcome :-) |
| 20:01.14 | starseeker | brlcad: are you volunteering to make new icons? :-P |
| 20:01.15 | CIA-14 | BRL-CAD: 03jordisayol * r43763 10/brlcad/trunk/misc/debian/brlcad.sh: add brlcad man path to manpath env. variable in GNU/Linux |
| 20:25.12 | *** join/#brlcad ezzieyguywuf (~wolfie@cpe-071-070-255-232.nc.res.rr.com) | |
| 20:43.37 | *** join/#brlcad Stattrav (~Stattrav@117.192.129.10) | |
| 20:43.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:48.41 | brlcad | starseeker: if it's holding up beta, sure |
| 20:48.57 | brlcad | that one isn't an alpha hold-up, but should be fixed by beta |
| 20:49.51 | starseeker | <PROTECTED> |
| 20:50.10 | CIA-14 | BRL-CAD: 03erikgreenwald * r43764 10/brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c: clean up #if0 blocks, commented out printfs, etc |
| 20:50.11 | starseeker | those were mostly just "better than grey pixels" |
| 20:54.37 | brlcad | I noticed that there were a bunch of icons missing, I only listed the few that had some bigger issue |
| 20:55.29 | brlcad | isolates the nmg bug down to ~100 lines |
| 21:01.52 | yukonbob1 | brlcad: what's the script and what are it's requirements (ie: needs certain database, certain brl-cad version, certain env?) |
| 21:11.40 | brlcad | yukonbob1: it's our tcl test suite |
| 21:11.55 | brlcad | runs hundreds of commands through mged |
| 21:12.20 | brlcad | one of the hundreds is crashing, and it wasn't immediately obvious which one exactly |
| 21:25.06 | *** join/#brlcad Ralith (~ralith@d142-58-35-248.burnaby.sfu.ca) | |
| 21:33.37 | *** part/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 21:36.43 | yukonbob1 | brlcad: ah -- is this only w/ most recent versions of brl-cad, or would I be able to witness w/ 7.18.0 |
| 21:36.47 | yukonbob1 | ? |
| 21:41.45 | brlcad | it's been in there for over a year, it's part of our regression testing |
| 21:41.50 | starseeker | brlcad: missing? you mean primitives without icons? |
| 21:43.00 | brlcad | yeah |
| 21:43.31 | brlcad | e.g., not a big deal that rpp doesn't have an icon |
| 21:43.37 | starseeker | ah |
| 21:44.01 | brlcad | expecially since it'd then have to be rectified against arb8's icon since they'd look identical |
| 21:44.05 | starseeker | tried to at least get something for most of the significant ones, although adimttedly some of them suck... |
| 21:44.46 | brlcad | I was just listing the things that might affect release, not a critique or comment on the progress made to great |
| 21:44.56 | brlcad | to *date .. great stuff |
| 21:45.16 | starseeker | nods - we really need a proper graphic artist for "release quality" graphics |
| 21:45.27 | starseeker | that's a skill all its own |
| 21:45.51 | brlcad | since we were talking about release issues the other day, I thought I'd offload several things that I've noticed |
| 21:47.29 | starseeker | cool - thanks! |
| 21:47.30 | brlcad | making proper graphics isn't hard - you just have to be hyper observant, obsessive attention to detail, or decent amount of experience |
| 21:47.38 | starseeker | now if only we could get time to work on them... |
| 21:48.25 | brlcad | yep |
| 21:48.43 | brlcad | it takes a long time to make good graphics |
| 21:49.37 | brlcad | coders undervalue graphics designers (oh that's easy, just takes a couple hours..) as often as managers undervalue coders (oh that's easy, just takes a couple days) |
| 21:50.12 | CIA-14 | BRL-CAD: 03starseeker * r43765 10/brlcad/branches/cmake/ (27 files in 15 dirs): MFC r43764 |
| 21:52.52 | *** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ) | |
| 21:55.16 | starseeker | brlcad: I don't suppose we can bsd license common.h by any chance? |
| 22:00.08 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 22:00.08 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202) | |
| 22:22.21 | CIA-14 | BRL-CAD: 03brlcad * r43766 10/brlcad/trunk/src/librt/ (Makefile.am primitives/nmg/nmg.c): partial revert of the ntohl/htonl conversions made to NMG since they cause a crash. turn off strict since we're temporarily reverting back to bu xdr routines. |
| 22:23.08 | starseeker | brlcad: after release, do you mind if I try to straighten out whatever the issue was with package require Itcl and go back to that approach? |
| 22:23.38 | starseeker | is taking a stab at updating the CMake logic for current code and now remembers why he went the other route... |
| 22:27.09 | brlcad | starseeker: there's not really copyright-worthy in common.h, at least nothing I'd worry about reusing on a whim :) |
| 22:27.21 | starseeker | ah, cool :-) |
| 22:27.39 | starseeker | will need the UNUSED macro or something like it to make openNURBS happy with strict flags... |
| 22:28.02 | brlcad | starseeker: you can sort it out before or after the release (preferably on a platform where you can reproduce), the issue was really just getting back to a stable point |
| 22:28.21 | starseeker | nods - I'll wait for now |
| 22:28.32 | brlcad | i have my suspicion as to the cause |
| 22:28.43 | starseeker | what's that? |
| 22:28.46 | brlcad | it's double declaration of classes |
| 22:28.53 | brlcad | so basically inconsistency |
| 22:28.57 | starseeker | ah |
| 22:29.03 | brlcad | I think you just didn't take it far enough |
| 22:29.14 | brlcad | you make itcl and itk package require but not iwidgets |
| 22:29.29 | brlcad | so iwidgets was static loaded, but the other two not |
| 22:29.31 | starseeker | O.o |
| 22:29.45 | brlcad | so something went awry in tcl's book-keeping of what is loaded |
| 22:29.47 | starseeker | I didn't realize there was a library to be statically loaded with iwidgets |
| 22:29.59 | starseeker | thought it was just a bunch of tcl scripts |
| 22:30.19 | brlcad | it is |
| 22:30.37 | brlcad | but it does a Tcl_Import of iwidgets |
| 22:30.50 | starseeker | ahhh |
| 22:31.14 | brlcad | I don't know -- I could be way off, but that's something that came to mind |
| 22:31.33 | starseeker | wonders how the heck it works for him... |
| 22:31.44 | brlcad | should frankly be able to remove itcl/itk/iwidgets from bwish/mged |
| 22:31.54 | brlcad | make the scripts package require correctly |
| 22:32.16 | starseeker | oh, you mean do it "normally" in the src/tclscripts files? |
| 22:32.25 | brlcad | right |
| 22:32.52 | brlcad | there's no benefit for the cad commands to be auto-loaded on instantiation of an interpreter |
| 22:33.00 | brlcad | I mean, no major one at least |
| 22:36.11 | starseeker | should be fair to package require BRL-CAD or some such... |
| 22:38.29 | CIA-14 | BRL-CAD: 03brlcad * r43767 10/brlcad/trunk/src/fbed/Makefile.am: per-target cppflags wasn't added until 1.7+ so use AM_CPPFLAGS instead |
| 22:42.35 | starseeker | rtwizard runs here - I wonder if that's due to the screwy install setup I have... |
| 22:48.36 | starseeker | brlcad: remind me why we're importing itcl/itk/iwidgets into the global namespace? |
| 22:49.33 | brlcad | better question is what will break if we don't import it, and that I do not know |
| 22:49.49 | starseeker | hmm |
| 22:50.28 | brlcad | plenty broke from what should have been an equivalent change ;) |
| 22:52.53 | starseeker | Oh, I wasn't planning on doing it now :-P |
| 22:53.03 | starseeker | we have enough release problems without borrowing more |
| 22:53.29 | starseeker | I'd just really like to get to where our Tcl/Tk stuff isn't so cranky and fragile anymore |
| 22:54.57 | starseeker | O.o I can't reproduce the failure here - what platform did you see it on? |
| 22:57.04 | brlcad | mac, 10.6 |
| 22:57.25 | brlcad | vtts was also on mac iirc, dunno which version |
| 22:57.48 | brlcad | mine is usually an enable-all build for testing |
| 23:18.28 | brlcad | starseeker: when you wrote the tcl mged tests .. what state did you leave them in? |
| 23:18.43 | brlcad | i.e., were they working? |
| 23:23.18 | starseeker | at the time they were, I believe |
| 23:23.25 | starseeker | that was a long time ago |
| 23:23.50 | starseeker | Pro/Batch sucks |
| 23:24.40 | brlcad | interesting |
| 23:25.06 | brlcad | because I got a magic bomb translating halfspaces, null parameter, that I can't see having ever worked |
| 23:26.16 | starseeker | huh |
| 23:26.34 | starseeker | shrugs - I may have messed it up somehow |
| 23:27.26 | brlcad | no no |
| 23:27.33 | brlcad | the problem was in librt |
| 23:28.01 | starseeker | oh, you mean an actual problem with the halfspace, not the test scripts? |
| 23:28.12 | brlcad | I added the support, I just don't see how translating a half ever worked with the out pointer was null |
| 23:28.18 | brlcad | right |
| 23:39.21 | brlcad | hm, well that's positive.. seems to be crashing on linux too |
| 23:39.37 | brlcad | starseeker: if you have a build, can you test what make test in regress/mged does? |
| 23:43.31 | CIA-14 | BRL-CAD: 03brlcad * r43768 10/brlcad/trunk/src/librt/primitives/half/half.c: how did this ever work? if the out pointer is null, we need to initialize and create one. nearly identical to what extrude does now. |
| 23:43.43 | starseeker | um... need to make an autotools build, one sec |
| 23:45.32 | brlcad | try without that change first |
| 23:45.35 | CIA-14 | BRL-CAD: 03starseeker * r43769 10/brlcad/branches/cmake/src/ (bwish/cadAppInit.c bwish/main.c mged/cmd.c mged/setup.c): CMake branch isn't set up to build with itcl/itk C api - need to resolve the package require issues. |
| 23:45.43 | starseeker | k |
| 23:48.16 | starseeker | brlcad: when rtwizard is crashing, is it from an installed location or the build dir? |
| 23:49.17 | starseeker | heh - just noticed, shapelib is actually an lgpl dependency |
| 23:49.25 | starseeker | looks like our first |
| 23:54.13 | starseeker | interesting - comb.tcl already has a package require Iwidgets |
| 23:54.21 | brlcad | starseeker: actually it's dual-licensed |
| 23:54.22 | brlcad | MIT |
| 23:54.29 | starseeker | ah, cool |
| 23:54.44 | brlcad | an odd dual-license, but I wasn't going to complain |
| 23:54.46 | starseeker | wonders what the point of a dual LGPL/MIT license is... |
| 23:55.16 | starseeker | autotools build clunking along |
| 23:55.31 | starseeker | will have to remember how to run those tests again - completely forgotten |
| 23:56.55 | brlcad | cd regress/mged && make test :) |
| 23:56.56 | starseeker | iirc, I had notions of replacing the sh regression logic with tcl regression logic for cross-platform compatibility... |
| 23:57.04 | starseeker | oh, I got it that far? cool |
| 23:57.19 | brlcad | looks like my linux failure has been fixed with recent changes |
| 23:57.55 | starseeker | rtwizard appears to have package require calls too |
| 23:58.48 | starseeker | somewhat bemusingly, I don't see such a call in archer |
| 23:59.46 | brlcad | iirc, my rtwizard invoke was pre-install |
| 00:01.05 | brlcad | I rarely test from install unless I'm nearing release testing, several extra minutes saved per compile, which adds up fast |
| 00:04.42 | starseeker | nods - I'm the same way |
| 00:05.06 | starseeker | it's a possible difference to check - the cmake build and the autotools build runs are quite different |
| 00:05.56 | brlcad | nods |
| 00:06.45 | brlcad | yeah, I just verified that your halfspace test failed for half on linux too |
| 00:06.56 | brlcad | it's the oed.mged set of tests |
| 00:07.04 | starseeker | hmm - wonder if I just commented it out and moved on... |
| 00:07.19 | brlcad | I was running them manually since they're easier to isolate |
| 00:07.23 | starseeker | some of those were a little tricky to set up, so I may have just assumed I had done it wrong |
| 00:07.30 | starseeker | nods |
| 00:07.37 | brlcad | so it maybe always has failed |
| 00:08.10 | brlcad | thing is, it stops the whole testing progression and stops pretty early on with it trying to move a half |
| 00:08.24 | starseeker | possibly - that has to be over a year since I've touched those, and probably longer, so I don't recall much |
| 00:08.24 | brlcad | with the fix, it gets all the way to the end |
| 00:08.29 | starseeker | sweet! |
| 00:08.39 | brlcad | successfully even |
| 00:08.45 | brlcad | now the log is another matter... |
| 00:09.00 | brlcad | heh, it lists slews of errors and failures, but it's not clear which are intentional and which are not |
| 00:09.12 | brlcad | e.g., saw a "killall*" in there |
| 00:09.35 | brlcad | but then that might have been a prefix or something too |
| 00:09.38 | starseeker | urm... don't recall if I got to the intentional failure checking or not... |
| 00:10.00 | starseeker | mainly recalls a lot of time spent on primitives and quick reference card commands |
| 00:10.52 | starseeker | brlcad: you still build primarily in the source tree? |
| 00:11.01 | brlcad | well then, it looks like I maybe just implemented non-pushed matrix edit support for halfspaces |
| 00:12.27 | brlcad | depends on the platform, maybe half the time but I wouldn't say it's primarily in or out |
| 00:13.11 | brlcad | some platforms are almost exclusively out of dir (linux), some are mix in/out depending on what I'm doing (mac), and others still are almost always in dir (release) |
| 00:13.19 | starseeker | k - don't know why that would still matter but also something to keep in mind |
| 00:14.03 | brlcad | possible, but it was a pretty isolated failure with the double-class error |
| 00:14.35 | brlcad | i'll give it another test post-release |
| 00:16.02 | starseeker | brlcad: I think we found your new commuter car: http://blogs.wsj.com/tech-europe/2011/03/07/the-car-faster-than-a-speeding-bullet/ |
| 00:21.57 | starseeker | brlcad: yep: ERROR: NULL rt_half_internal pointer, file primitives/half/half.c, line 505 |
| 00:22.13 | starseeker | updates to confirm fix |
| 00:22.18 | brlcad | cool |
| 00:22.28 | brlcad | pretty much confirms, awesome |
| 00:22.49 | brlcad | hm, I don't see how/where oed actually applies the matrix |
| 00:31.10 | starseeker | brlcad: for which test? |
| 00:31.44 | starseeker | oh, confirmed that regression is fixed with the latest update |
| 00:32.58 | brlcad | that's bizzare though too |
| 00:33.10 | brlcad | the test does oed / oed_half.c/oed_half.s |
| 00:33.35 | brlcad | then merely presses accept |
| 00:33.47 | brlcad | that results in the halfspace import fail |
| 00:33.53 | brlcad | fishy |
| 00:33.57 | starseeker | O.o |
| 00:35.13 | brlcad | *sigh* .. back to gdb for understanding |
| 00:37.10 | starseeker | technically we don't have to pass those for release, they were never added to the "offical" regression testing... |
| 00:37.58 | brlcad | it's not a matter of passing the test, it's a failure related to code that changed |
| 00:38.23 | brlcad | the tests are simple enough, they're worth checking into to make sure something else wasn't horked |
| 00:38.57 | starseeker | nods - just noting that some of the "failures" may be nothing new... |
| 00:39.31 | brlcad | sure |
| 00:39.42 | brlcad | but they're the closest thing to a test at this point for all the librt code that was changed |
| 00:39.49 | starseeker | ah, point |
| 01:10.52 | starseeker | hmm... cmake build succeeds in running rtwizard and archer on 10.6, although I do see those kCGError messages |
| 01:11.03 | starseeker | will have to try autotools tomorrow |
| 01:15.27 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 02:48.01 | CIA-14 | BRL-CAD: 03brlcad * r43770 10/brlcad/trunk/NEWS: |
| 02:48.01 | CIA-14 | BRL-CAD: inadvertently reviewing and fixing bugs for release, fixed a never-implemented |
| 02:48.01 | CIA-14 | BRL-CAD: feature of halfspaces. if you put them into a combination and apply a matrix to |
| 02:48.01 | CIA-14 | BRL-CAD: the combination, librt would bomb with an invalid magic error. the half |
| 02:48.01 | CIA-14 | BRL-CAD: primitive was updated to handle that case which is used by mged to apply |
| 02:48.02 | CIA-14 | BRL-CAD: matrices to wireframes without writing to a disk record. |
| 02:49.00 | CIA-14 | BRL-CAD: 03brlcad * r43771 10/brlcad/trunk/TODO: technically unbusted though only because it's half-reverted. still investigating the cause, but todo is todone. |
| 03:16.09 | brlcad | gives bottie a final round of testing |
| 03:16.32 | starseeker | brlcad: the last report on bottie was "consistently crashing" |
| 03:17.47 | CIA-14 | BRL-CAD: 03brlcad * r43772 10/brlcad/trunk/src/librt/primitives/half/half.c: oops, wrong cast |
| 03:19.10 | brlcad | heh, k |
| 03:29.04 | brlcad | just worked with a simple sphere test case |
| 03:30.04 | brlcad | 50% speedup |
| 03:30.46 | brlcad | (of tie vs bot .. sph was around 200% faster) |
| 03:33.58 | starseeker | cool |
| 03:34.14 | starseeker | huh, this is interesting: http://www.cs.mtu.edu/~shene/COURSES/cs3621/NOTES/ |
| 03:34.16 | brlcad | nice 300% improvement on a model with just 9k tris |
| 03:34.25 | brlcad | 600k rtfm vs 200k rtfm |
| 03:35.15 | brlcad | I think I've seen that site |
| 03:37.16 | starseeker | needs to read through that |
| 03:37.18 | brlcad | and it scales nicely on a big image, 21 sec vs 7 sec |
| 03:37.23 | starseeker | awesome :-) |
| 03:37.26 | brlcad | the whole team should read through that |
| 03:37.41 | brlcad | about once a year ;) |
| 03:37.52 | starseeker | hehe |
| 03:38.24 | starseeker | will probably rediscover it around this time next year |
| 03:57.13 | brlcad | wow, actual 10x increase on a 0.5M poly bot (simple sphere) |
| 04:00.28 | brlcad | and on a 1.2M poly... |
| 04:02.41 | brlcad | 3 sec vs 62 sec |
| 04:02.58 | brlcad | hawt |
| 04:04.33 | brlcad | so that's about as good as it will probably get comparison-wise since it's a simple shape that's best for kdtree being compared with a bot not using pieces optimization (default) and is but a single simple shape |
| 04:09.00 | brlcad | nice, 5x increase on t62 |
| 04:09.13 | brlcad | (after removing the silly "I want normals" limitation) |
| 04:10.05 | brlcad | hm, maybe not on that one ... |
| 04:23.32 | brlcad | yeah, that wasn't right, looking to be about 40% faster (about 13s vs 21s) on a fully hierarchical bot t62 |
| 04:44.20 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 04:44.20 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202) | |
| 05:55.51 | CIA-14 | BRL-CAD: 03brlcad * r43773 10/brlcad/trunk/NEWS: looks like today is the day. reword the BoT-TIE metrics having directly observed (valid) performance from 40% to 20x faster. include details that the acceleration is presently disabled by default. |
| 05:58.37 | CIA-14 | BRL-CAD: 03brlcad * r43774 10/brlcad/trunk/TODO: peformance tested, results very promising |
| 06:00.02 | ``Erik | bottie breaks on 32b |
| 06:00.40 | ``Erik | took some work to get a 32b linux build (needs fixing), but it breaks there, too, not just fbsd |
| 06:01.55 | CIA-14 | BRL-CAD: 03brlcad * r43775 10/brlcad/trunk/src/librt/primitives/bot/bot.c: since it's disabled by default, is there really any point in requiring normals and orientation? tested on several unoriented and normal-free bots with success too. |
| 06:02.04 | ``Erik | (--disable-64bit-build causes failed build on a 64b linux build, -m32 is not being added correctly to src/other) |
| 06:02.22 | brlcad | yep, see README.Linux about that |
| 06:02.58 | brlcad | you basically have to force it kicking and screaming |
| 06:03.54 | ``Erik | heh, had to ./configure CFLAGS=-m32 CXXFLAGS=m32 and then force compile tk and another with /usr/lib/libfonconfig.so.1 instead of -lfontconfig |
| 06:04.25 | brlcad | probably because you need LDFLAGS-m32 too |
| 06:04.45 | ``Erik | no, there is no /usr/lib/libfontconfig.so ... mebbe an arl screwup |
| 06:05.02 | brlcad | probably, I manually fixed a couple bad X11 libs |
| 06:05.11 | brlcad | bad == missing symlink |
| 06:05.47 | brlcad | either way, results looking pretty good now |
| 06:05.53 | ``Erik | aaanyways, 32b tie crashes where I tried it, I've a lot of mods at work digging into it, but if you wanna dig in, knock yourself out... imma go unconcious |
| 06:06.25 | brlcad | i'm satisfied with it, I'm pressing for release tagging -- one last thing to check on |
| 06:06.51 | brlcad | it was working well enough to put numbers on the gains |
| 06:07.14 | brlcad | t62 is pretty darn close to real-world, it was around 40% |
| 06:07.15 | ``Erik | it takes a bit of work to trigger, so whatever... I'm not keen on release notes when it doesn't work 32b, but *shrug* I have more important stuff to worry about |
| 06:07.33 | brlcad | the notes say it's disabled by default and preliminary |
| 06:07.44 | brlcad | so there can be a future not when it's not off by default |
| 06:09.43 | CIA-14 | BRL-CAD: 03erikgreenwald * r43776 10/brlcad/trunk/TODO: note 32b issue for bottie |
| 06:10.21 | ``Erik | tomorrow; geomcore. |
| 06:12.16 | CIA-14 | BRL-CAD: 03brlcad * r43777 10/brlcad/trunk/TODO: huzzah! .. looks like the nmg failures were related to one of the other failures (probably nmg) because now everything is working again. |
| 07:00.49 | brlcad | tomorrow; tag. |
| 07:00.53 | brlcad | er, today |
| 07:46.36 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:28.59 | *** join/#brlcad epileg (~epileg@188.119.210.222) | |
| 08:29.02 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 09:13.01 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 12:39.23 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 12:51.07 | *** join/#brlcad Stattrav (~Stattrav@117.192.248.2) | |
| 12:51.07 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:58.10 | *** join/#brlcad Stattrav (~Stattrav@122.167.250.138) | |
| 12:58.10 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:59.37 | starseeker | reflects that a function to find all local maximums and minimums in a dsp dataset would probably be a good start at more intelligent spline surface generation... |
| 13:16.35 | *** join/#brlcad Stattrav (~Stattrav@122.167.250.138) | |
| 13:16.35 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:22.07 | *** join/#brlcad Stattrav (~Stattrav@122.167.250.138) | |
| 13:22.07 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:22.30 | *** join/#brlcad dli (~dli@dsl-173-248-211-229.acanac.net) | |
| 13:31.37 | *** join/#brlcad Stattrav (~Stattrav@122.167.250.138) | |
| 13:31.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:42.51 | *** join/#brlcad Stattrav (~Stattrav@117.192.248.2) | |
| 13:42.51 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:49.34 | CIA-14 | BRL-CAD: 03starseeker * r43778 10/brlcad/branches/cmake/CMakeLists.txt: Add some documentation on what the distcheck routine does |
| 13:50.20 | CIA-14 | BRL-CAD: 03jordisayol * r43779 10/brlcad/trunk/ (misc/debian/rules sh/make_rpm.sh): change the number of simultaneous jobs on "make", during deb/rpm building process |
| 13:53.19 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:52.22 | ``Erik | hm, dns issues with brlcad.org ? |
| 15:04.18 | CIA-14 | BRL-CAD: 03brlcad * r43780 10/brlcad/trunk/misc/Makefile.am: debian/application-x-brlcad.png was replaced with two v4/v5 png files |
| 15:05.30 | brlcad | shouldn't be |
| 15:06.35 | ``Erik | I can't resolve from several different machines |
| 15:06.39 | ``Erik | including bz |
| 15:08.40 | brlcad | working for me |
| 15:08.55 | ``Erik | on bz? tried other machines to avoid cache artifacts? |
| 15:09.06 | epileg | ``Erik: not working here in Spain |
| 15:09.33 | brlcad | just reset named, try again |
| 15:12.08 | ``Erik | "no servers could be reached" |
| 15:12.52 | ``Erik | (from several different machines using different dns servers, other domains resolve) |
| 15:13.08 | brlcad | what query you using? |
| 15:13.19 | brlcad | does "nslookup google.com - bzflag.bz" work for you? |
| 15:13.25 | ``Erik | "nslookup brlcad.org" and "dig brlcad.org" |
| 15:13.41 | ``Erik | yes, that works |
| 15:14.43 | brlcad | oh my |
| 15:14.58 | epileg | here in spain, exactly same as ``Erik |
| 15:15.07 | ``Erik | on one machine, I got, um |
| 15:15.17 | ``Erik | ;; reply from unexpected source: 76.96.5.201#53, expected 68.87.71.230#53 |
| 15:15.20 | ``Erik | stuff like that |
| 15:15.46 | brlcad | could be related to zoneedit migration |
| 15:17.00 | ``Erik | *shrug* we'll see if it clears up, ah surpose |
| 15:19.16 | brlcad | yeah, NS1.ZONEEDIT.COM is not responding |
| 15:20.05 | brlcad | all three appear to be snookered |
| 15:20.08 | *** join/#brlcad ezzieyguywuf (~wolfie@cpe-071-070-255-232.nc.res.rr.com) | |
| 15:20.12 | ``Erik | they don't have site redundant secondaries? O.o |
| 15:21.29 | ``Erik | ah, pay per secondary, lame :) |
| 15:22.15 | ``Erik | jabs some code for a while |
| 15:23.17 | brlcad | is paying for a secondary |
| 15:23.28 | brlcad | that's why there's three, one's even in the uk |
| 15:23.37 | brlcad | all three are unreachable |
| 15:23.56 | ``Erik | heh, 99.998, guess this is that .002 |
| 15:27.29 | ``Erik | irssi for noobs lessons *sigh* :D |
| 15:32.51 | brlcad | of 7 dns servers, looks like 5 of them are down |
| 15:35.08 | brlcad | er, 13 of 19 |
| 15:39.46 | starseeker | ``Erik: oh, don't worry - in another 10 years or so I may not be a noob anymore |
| 15:46.01 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 15:47.03 | ``Erik | so'z I gotta enjoy it while I can, right? :> |
| 15:47.21 | starseeker | heh |
| 15:49.10 | brlcad | note that brlcad.org is still reachable as bzflag.bz (at least for now) |
| 15:50.04 | brlcad | http://63.246.136.17/d/ will get you to the website |
| 15:50.19 | ``Erik | ayup, that's what I did earlier for my comic page, before calling out the dns issue (was poking around to see if the httpd was having issues, if'n ya look at the sudo log) |
| 15:51.13 | CIA-14 | BRL-CAD: 03erikgreenwald * r43781 10/geomcore/trunk/TODO: UUID is wired in and QT is gone |
| 15:58.19 | ``Erik | http://www.youtube.com/watch?v=xQqQ-Kcjowg "rental car olympics" |
| 16:12.21 | brlcad | heh |
| 16:21.27 | *** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de) | |
| 16:23.08 | *** join/#brlcad Nohla (~Nohla@64.76.19.227) | |
| 16:33.58 | dli | brlcad, my first try for rt_revolve_xform(), http://pastebin.com/Tf3Qsg7J |
| 16:34.53 | dli | brlcad, still reading include/rtgeom.h |
| 16:57.27 | *** join/#brlcad Stattrav (~Stattrav@117.202.21.22) | |
| 16:57.27 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:19.38 | starseeker | O.o |
| 17:25.11 | starseeker | What the... I'm seeing warning messages on OSX that are suppressed by adding -Werror |
| 17:34.32 | starseeker | no, that's not it... |
| 17:37.08 | starseeker | Ah - it's the presence or absence of STRICT_FLAGS in brlcad_config.h |
| 17:37.48 | starseeker | Ohhhhh. I see. |
| 17:38.22 | starseeker | bu.h linen 160 |
| 18:05.24 | CIA-14 | BRL-CAD: 03starseeker * r43782 10/brlcad/branches/cmake/ (6 files in 5 dirs): (log message trimmed) |
| 18:05.24 | CIA-14 | BRL-CAD: Rework how CFLAGS are assigned in CMake. Major changes are using build type |
| 18:05.24 | CIA-14 | BRL-CAD: specific flags to hold things instead of the catch-all, and changing the |
| 18:05.24 | CIA-14 | BRL-CAD: STRICT_FLAGS brlcad_config.h include to WARNING_FLAGS. The way CMake sets |
| 18:05.24 | CIA-14 | BRL-CAD: things up, turning on the warnings but not strict just means you're expecting to |
| 18:05.24 | CIA-14 | BRL-CAD: see all the same output without failing. Conditionalizing the bu.h |
| 18:05.24 | CIA-14 | BRL-CAD: undef/redefine logic on strict and not warning violated that principle, because |
| 18:18.32 | CIA-14 | BRL-CAD: 03starseeker * r43783 10/brlcad/branches/cmake/CMakeLists.txt: Setting linker flags now, not compiler flags |
| 18:20.45 | CIA-14 | BRL-CAD: 03starseeker * r43784 10/geomcore/trunk/tests/svntest/main.c: don't do a region subdirectory |
| 18:21.23 | CIA-14 | BRL-CAD: 03erikgreenwald * r43785 10/geomcore/trunk/src/utility/GSThread.cxx: destroy the mutex in the GSMutex destructor |
| 18:51.15 | starseeker | brlcad: I still can't reproduce the rtwizard/archer/bwish issue |
| 19:25.47 | *** join/#brlcad Nohla (~Nohla@64.76.19.227) | |
| 19:45.24 | *** join/#brlcad Nohla (~Nohla@64.76.19.227) | |
| 19:50.52 | CIA-14 | BRL-CAD: 03starseeker * r43786 10/brlcad/branches/cmake/ (10 files in 9 dirs): MFC r43785 |
| 20:01.18 | CIA-14 | BRL-CAD: 03starseeker * r43787 10/brlcad/branches/cmake/src/other/ (13 files in 6 dirs): Ah, right - src/other builds actually have to do their thing properly now. Get tkpng, tktable and tkhtml set up with some find_package calls. |
| 20:12.37 | CIA-14 | BRL-CAD: 03starseeker * r43788 10/geomcore/trunk/ (CMake/ CMakeLists.txt cmake/): Do like most other projects and put our CMake modules in a CMake directory |
| 20:21.28 | *** part/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 20:37.01 | CIA-14 | BRL-CAD: 03starseeker * r43789 10/geomcore/trunk/ (3 files in 2 dirs): Make realpath happy on OSX |
| 20:49.58 | CIA-14 | BRL-CAD: 03jordisayol * r43790 10/brlcad/trunk/ (3 files in 2 dirs): add an "update gtk icon cache" and some minor improvements on "install" and "remove" scripts of deb/rpm packages |
| 20:59.53 | *** join/#brlcad dli_ (~dli@dsl-69-171-148-245.acanac.net) | |
| 21:01.21 | CIA-14 | BRL-CAD: 03bob1961 * r43791 10/brlcad/trunk/src/tclscripts/lib/TkTable.tcl: Added a TkTable::see method. |
| 21:06.09 | CIA-14 | BRL-CAD: 03erikgreenwald * r43792 10/geomcore/trunk/src/libNet/NetMsgRouter.cxx: update getListOfHandlers to work correctly with STL maps |
| 21:20.05 | CIA-14 | BRL-CAD: 03brlcad * r43793 10/brlcad/trunk/src/libged/gqa.c: |
| 21:20.06 | CIA-14 | BRL-CAD: add some error recovery to gqa so that we don't bomb out during |
| 21:20.06 | CIA-14 | BRL-CAD: bu_malloc/bu_calloc when passed a zero size allocation. probably means |
| 21:20.06 | CIA-14 | BRL-CAD: something earlier went awry but check here regardless so we can be more graceful |
| 21:20.06 | CIA-14 | BRL-CAD: about halting. |
| 21:20.29 | starseeker | ``Erik: that's got it, thanks! |
| 22:34.36 | CIA-14 | BRL-CAD: 03starseeker * r43794 10/geomcore/trunk/tests/svntest/main.c: Put each geometry object into its own directory. |
| 22:39.03 | starseeker | brlcad: about 50 seconds when I put each object in its own directory (regions and assemblies) |
| 23:10.30 | CIA-14 | BRL-CAD: 03starseeker * r43795 10/brlcad/branches/cmake/include/bu.h: Go ahead and keep the old comment |
| 23:13.47 | CIA-14 | BRL-CAD: 03starseeker * r43796 10/brlcad/trunk/ (configure.ac include/bu.h): STRICT_FLAGS -> WARNING_FLAGS - just a rename as far as autotools is concerned, no behavior change |
| 23:45.26 | CIA-14 | BRL-CAD: 03starseeker * r43797 10/geomcore/trunk/src/GS/ (9 files): First step of renaming geoclient and geoserv to geomclient and geomserv |
| 23:47.36 | CIA-14 | BRL-CAD: 03starseeker * r43798 10/geomcore/trunk/src/GS/ (geomclient.cxx geomserv.cxx): geoclient and geoserv renamed to use geom prefix - sounds less like geospatial related software |
| 00:00.55 | CIA-14 | BRL-CAD: 03brlcad * r43799 10/brlcad/trunk/TODO: add a couple tasks I've had squirreled away for a couple years, visualization requests from external application devs |
| 00:01.17 | ``Erik | wait, what? we're not making map software? |
| 00:01.39 | starseeker | ``Erik: yeah, yeah... it was bothering me |
| 00:02.29 | starseeker | although come to think of it, whadya bet there's something somewhere out there called geoserv? |
| 00:03.16 | ``Erik | quite a bit, it'd seem |
| 00:04.26 | starseeker | you're kidding - no one grabbed it? |
| 00:04.41 | ``Erik | there's a company, a .org, a lot of GIS stuff, ... |
| 00:16.47 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 00:16.47 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202) | |
| 00:21.51 | CIA-14 | BRL-CAD: 03starseeker * r43804 10/geomcore/trunk/TODO: Add some notes and thoughts about immediate next steps to the TODO for geomcore |
| 00:24.42 | brlcad | looks like DNS is restored |
| 00:26.42 | starseeker | yep - sweet |
| 00:26.49 | ``Erik | should probably have unified test output and a shell script to fire them all off and make a dashboard |
| 00:27.09 | ``Erik | let's do it in xml... wrapped in couchdb... :D |
| 00:27.15 | starseeker | heh |
| 00:27.31 | starseeker | really should look at CDash |
| 00:28.09 | starseeker | especially for geometry service, it's output would be a nice "ooo, shiny" progress report |
| 00:32.44 | CIA-14 | BRL-CAD: 03starseeker * r43805 10/geomcore/trunk/ (doc/ docs/): docs->doc |
| 00:48.07 | CIA-14 | BRL-CAD: 03starseeker * r43806 10/geomcore/trunk/ (. doc/Doxyfile doc/Doxyfile.in doc/docbook/): |
| 00:48.07 | CIA-14 | BRL-CAD: Nifty tweak for doc directory - although it's early to be thinking along the |
| 00:48.07 | CIA-14 | BRL-CAD: lines of docbook, set up an svn:externals property to pull the xsl sheets and |
| 00:48.07 | CIA-14 | BRL-CAD: any other resources from BRL-CAD's doc/docbook directory, instead of duplicating |
| 00:48.08 | CIA-14 | BRL-CAD: them in geomcore. Also rename Doxyfile - that will need to have some hardcoded |
| 00:48.08 | CIA-14 | BRL-CAD: paths replaced with CMake variables. |
| 00:48.58 | brlcad | zoneedit was hit was a DDoS earlier, hence the downtime |
| 00:49.47 | brlcad | script is chugging along .. :) |
| 00:54.23 | ``Erik | how goeth account migration? |
| 00:54.56 | ``Erik | slaps on his booties and heads into town O.o |
| 00:55.07 | brlcad | release bugs |
| 00:55.46 | brlcad | have taken six days longer than expected now, so a bit backed up |
| 00:56.17 | CIA-14 | BRL-CAD: 03starseeker * r43807 10/geomcore/trunk/doc/doxygen/: add doxygen dir |
| 00:59.31 | CIA-14 | BRL-CAD: 03starseeker * r43808 10/geomcore/trunk/doc/ (Doxyfile.in doxygen/CMakeLists.txt doxygen/Doxyfile.in): Add a CMakeLists.txt file for doxygen building |
| 01:07.38 | CIA-14 | BRL-CAD: 03starseeker * r43809 10/geomcore/trunk/ (CMakeLists.txt doc/CMakeLists.txt doc/doxygen/Doxyfile.in): Add some logic for doxygen building - dunno if it works yet |
| 01:12.31 | brlcad | initial stats coming in on the raw filesystem overhead |
| 01:14.57 | brlcad | creating 526 dirs takes approximately 1.25 seconds |
| 01:15.16 | CIA-14 | BRL-CAD: 03starseeker * r43810 10/geomcore/trunk/tests/svntest/CMakeLists.txt: May need TCL_INCLUDE_DIRS for svnTest |
| 01:15.42 | brlcad | keeping all objects in havoc above and at region is approximately 62 seconds |
| 01:16.44 | brlcad | file size expands from 576k to 2420k |
| 01:20.50 | brlcad | of those 62s keeping geometry, 60s comprised overhead time reinvoking mged and re-reading the .g file -- so the actual keep operation (create file, traverse tree, write to file) is only about 2s of time |
| 01:21.32 | CIA-14 | BRL-CAD: 03starseeker * r43811 10/geomcore/trunk/doc/doxygen/ (CMakeLists.txt Doxyfile.in): Exclude src/other. Doxygen generation works now for geomcore, but turned off by default. |
| 01:22.06 | starseeker | huh - so maybe I am doing something wrong with the svn stuff |
| 01:22.18 | brlcad | or svn overhead is just that much |
| 01:24.05 | brlcad | ov the 60s spend reinvoking mged and re-reading the .g, approximately 56s is spent reinvoking mged .. so about 4s to read the .g 526 times |
| 01:24.37 | brlcad | undoubtedly cache'd fs data making that fast |
| 01:25.10 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 01:25.51 | brlcad | takes approx 0.05s to open, read all 526 .g files, and cat them together |
| 01:29.00 | brlcad | interestingly, havoc.g: 586k, uncompressed into dirs: 2420k, reconstituted into single .g: 870k |
| 01:29.41 | CIA-14 | BRL-CAD: 03starseeker * r43812 10/geomcore/trunk/doc/doxygen/CMakeLists.txt: Whoops, add the headers to the party |
| 01:30.43 | brlcad | that model apparently has a decent amount of sub-region reuse going on to cause a 42% expansion |
| 01:30.58 | brlcad | so it'll be a good test case later too |
| 01:34.26 | brlcad | and I think that's about all we need to know for now.. the best case overhead is going to be about 3s-4s to do a round-trip dir breakout, traverse tree, write out objects, read them back in, and recreate .g -- the rest is overhead elsewhere |
| 01:35.05 | starseeker | nods - cool |
| 01:35.12 | brlcad | considering the vast majority of that 4s is only during import with <1s during export, that sounds entirely reasonable |
| 01:37.46 | brlcad | for anyone else looking to play with a .g break-out, this script will do the trick: |
| 01:37.51 | brlcad | file=whatever.g ; for i in `mged -c $file search / 2>&1 ` ; do obj="`basename $i`" ; reg="`mged -c $file search $i -type r 2>&1`" ; if test "x$reg" = "x$i" ; then echo "mkdir $obj" ; echo "mged -c $file keep $obj/${obj}.g $obj" ; elif test "x$reg" = "x" ; then echo "# skipping $obj" ; else echo "mkdir $obj" ; echo "mged -c $file keep -R $obj/${obj}.g $obj" ; fi ; done | tee doit.sh |
| 01:38.48 | brlcad | from there you can sh the script or cat the mkdirs to a new script or count regions, non-regions, skipped sub-objects, etc |
| 01:39.00 | brlcad | hugs search |
| 01:40.06 | brlcad | and if I'd had a newer install on hand, I could have skipped the silly "basename $i" with 'search .' instead of 'search /' |
| 01:46.07 | starseeker | except those no-arg search requests are still busted... |
| 01:46.30 | starseeker | there's some subtlty there I haven't figured out yet |
| 02:02.08 | brlcad | actually, "search /" that I'm using there works just fine with 7.16.10 |
| 02:02.30 | starseeker | nods - I know, the new setup broke it |
| 02:02.33 | brlcad | so I'd wager it's some new checks for args you've added |
| 02:02.57 | brlcad | maybe a simple check that just needs to be removed, or an off-by-one argc |
| 02:03.00 | starseeker | there's something more to it than that |
| 02:03.20 | starseeker | I passed in a null argv, and got some kind of crash |
| 02:03.35 | starseeker | in the paren squish logic, if memory serves |
| 02:03.45 | starseeker | haven't had time to hunt it down |
| 02:03.48 | brlcad | ok |
| 02:04.01 | brlcad | runs away |
| 05:49.55 | brlcad | starseeker: curious changes to the WARNING_FLAGS/STRICT_FLAGS for the attr params -- is strict vs warning compilation options in cmake dependent or independent on each other? |
| 05:51.18 | brlcad | in autotools, the two options are dependent so you can have warn but not strict, warn and strict, not warn and not strict, or not warn and strict |
| 05:52.55 | brlcad | that change on the cmake branch looked like it made 'warn and strict' not possible (because our own bu_log cannot compile with the attr warnings, but we want attr warnings for stdio functions (the warn and not strict case) so they can be fixed |
| 05:54.11 | brlcad | of the four cases, warn+strict is the most important to make default since it keeps things the most clean, but that's where the printf-attr warning becomes problematic |
| 06:02.37 | *** join/#brlcad Stattrav (~Stattrav@117.192.242.239) | |
| 06:02.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:05.50 | *** join/#brlcad Stattrav_ (~Stattrav@122.167.250.138) | |
| 10:53.00 | *** join/#brlcad Stattrav (~Stattrav@122.172.4.189) | |
| 10:53.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:13.17 | starseeker | brlcad: um... warn + strict should be the default |
| 12:14.00 | starseeker | brlcad: you can have all four combinations with cmake too |
| 12:14.29 | brlcad | except by tying attr_format123 to warnings, that should stop the build |
| 12:14.41 | starseeker | uh... how? |
| 12:14.46 | starseeker | OH |
| 12:14.59 | starseeker | my definiton of warning and strict are probably slightly different |
| 12:15.11 | starseeker | in cmake, struct is JUST -Werror |
| 12:15.49 | brlcad | and your warnings probably doesn't include -Wformat |
| 12:15.55 | starseeker | checks |
| 12:16.02 | starseeker | I believe it does |
| 12:16.43 | starseeker | It's part of Wall |
| 12:16.47 | starseeker | checks gcc docs |
| 12:16.50 | brlcad | then it should halt the build :) |
| 12:17.06 | starseeker | without Werror, it's just a warning |
| 12:18.05 | brlcad | our own print-style functions (e.g., bu_log()) declare themselves to be printf-style functions, so some versions of gcc recognize that and validate the arguments against the format specifier |
| 12:18.27 | starseeker | right - that was happening on the mac as a warning with -Wall (not an error) |
| 12:18.45 | brlcad | which is fine and dandy for all the stdio functions, even fine for most of our functions, except where we've extended the format specifier and added %V, which will kick off a warning |
| 12:19.18 | brlcad | so our own bu_log() statements will issue a warning where we don't want one, halting the build if strict is enabled |
| 12:19.28 | starseeker | are you expecting -Wformat, on its own without -Werror, to error out in the case of bu_log? Because that's not the behavior I saw |
| 12:19.37 | starseeker | right |
| 12:21.14 | brlcad | that's a bad thing :) |
| 12:21.37 | starseeker | Uh... why? -Werror makes it hault |
| 12:21.48 | starseeker | without -Werror, it's just informative |
| 12:21.55 | starseeker | I thought it made sense |
| 12:22.07 | brlcad | I don't think you're seeing the issue yet |
| 12:22.42 | brlcad | we want strict+warning to be the default, yes? |
| 12:22.51 | starseeker | yes - it is |
| 12:23.15 | *** join/#brlcad Stattrav_ (~Stattrav@122.172.4.189) | |
| 12:23.39 | brlcad | if warning implies Wformat warnings, which it should, then Wformat will issue warnings on our exisiting bu_log() calls |
| 12:24.02 | starseeker | but we don't want that and never will |
| 12:24.02 | brlcad | as currently written, warnings that cannot be quelled because we have no way to tell gcc about %V |
| 12:24.36 | brlcad | we don't want that, but gcc is going to give us that because we turn on Wformat |
| 12:24.40 | starseeker | right - the STRICT_FLAGS trick quelled them for strict builds |
| 12:26.15 | brlcad | and now they're toggled based on whether warnings are on/off, yes? |
| 12:26.27 | brlcad | (in cmake branch) |
| 12:27.15 | starseeker | the workaround in bu.h for -Wformat is toggled ONLY when the warnings themselves are on, independend of whether STRICT is also specified (i.e. whether -Werror is added to the mix, which is all STRICT does in CMake) |
| 12:27.22 | brlcad | they being the attr_format attributes in particular |
| 12:27.49 | starseeker | in CMake, STRICT doesn't duplicate the WARNING flags the way configure.ac does |
| 12:27.55 | brlcad | I get that Werror is all strict is, that's fine and entirely expected |
| 12:28.17 | brlcad | the issue is whether the warnings settings turns those attributes on/off |
| 12:28.49 | starseeker | don't we always want them turned off anytime -Wformat is there, regardless of whether we're strict or not? |
| 12:28.50 | brlcad | if attribute is on when warnings is on, then warnings+strict won't be possible (because gcc will issue warnings where we use %V) |
| 12:29.23 | starseeker | right |
| 12:29.25 | brlcad | if attribut is off when warningsa is on, then nowarn+strict won't be possible (same issue) |
| 12:30.33 | starseeker | now you've lost me - if attribute is off, then why does nowarn+strict fail? |
| 12:30.43 | starseeker | nowarn+strict doesn't include -Wall |
| 12:31.08 | starseeker | it does in autotools, but not in cmake |
| 12:32.32 | brlcad | maybe that's the distinction, because there's two types of "no warn" in the autotools build |
| 12:32.44 | starseeker | oh, there are? |
| 12:33.19 | brlcad | --enable-warnings turns on "extra" warnings |
| 12:34.13 | brlcad | so let me understand this, the ATTR_FORMAT* defines -- you have them getting turned on/off when? |
| 12:35.07 | starseeker | OK - there are two compiler related options in CMake that impact this |
| 12:35.28 | starseeker | BRLCAD-ENABLE_COMPILER_WARNINGS and BRLCAD-ENABLE_STRICT, defined in misc/CMake/CompilerFlags.cmake |
| 12:36.01 | starseeker | COMPILER_WARNINGS turns on Wall, Winline, etc. but does not include Werror |
| 12:36.19 | starseeker | so the compile will blather like crazy but not error out |
| 12:36.51 | starseeker | If you set BRLCAD-ENABLE_STRICT, it will make sure BRLCAD-ENABLE_COMPILER_WARNINGS is set to ON and then add -Werror to the party |
| 12:38.36 | brlcad | sure, all sounds how I thought -- it's boils down to those attribute flags, when are they turned on/off? |
| 12:39.07 | brlcad | are they coupled to ENABLE_COMPILER_WARNINGS or ENABLE_STRICT ? |
| 12:39.13 | brlcad | presumably the prior? |
| 12:39.37 | brlcad | and are they toggled on when ENABLE_COMPILER_WARNINGS is 'on' or 'off'? |
| 12:41.16 | starseeker | the attribute flags are toggled on when ENABLE_COMPILER_WARNINGS is off (i.e. -Wall is not present) |
| 12:41.22 | starseeker | (sorry, network hickup |
| 12:42.15 | starseeker | if ENABLE_COMPILER_WARNINGS is on, we've got -Wall and we're going to get complaints about %V |
| 12:42.23 | starseeker | so we want the attribute flags off |
| 12:43.06 | starseeker | when ENABLE_STRICT is on, ENABLE_COMPILER_WARNINGS is also on, so they're off then too |
| 12:45.51 | starseeker | in bu.h, we're keying off the warning flags because they contain -Wall, but it has the same effect as keying off of STRICT because STRICT always turns on Warnings |
| 12:46.27 | starseeker | the benfit to doing it this way is that when Warnings are on but STRICT is off, we still don't want the %V reports |
| 12:46.45 | starseeker | and this gets rid of them |
| 12:47.57 | starseeker | brlcad: I didn't really change the behavior from autotools that much |
| 12:48.31 | starseeker | I'm just suppressing the %V error reporting in one additional case |
| 12:52.06 | starseeker | I suppose ideally the thing to do would be to check for -Wall or -Wformat in the compiler flags after configure and key off of that as to whether or not to enable/disable the ATTR_FORMAT* stuff |
| 12:52.29 | brlcad | basically it sounds like it's suppressing ATTR_FORMAT* entirely then, yes? |
| 12:52.40 | starseeker | yes, except when warnings are off |
| 12:53.24 | starseeker | I was getting an unexpected behavior on the Mac of getting warnings without STRICT on that disappeared when I turned on STRICT |
| 12:53.27 | brlcad | they're on when warnings are off, they off when warnings are on, so they have no effect |
| 12:53.59 | starseeker | they're on when the additonal warnings we supply are on |
| 12:54.12 | starseeker | any warnings gcc or CMake's default flags put in there are still present |
| 12:54.34 | starseeker | sorry - they're OFF when our additional warnings are ON |
| 12:55.20 | starseeker | if by off we mean the %V warnings are suppressed |
| 12:56.11 | brlcad | I think "STRICT always turns on Warnings" might be a key distinction, is that true or is strict only -Werror? :) |
| 12:56.43 | starseeker | Right now, STRICT will kick on the extra warnings |
| 12:56.52 | starseeker | it does not have to be that way |
| 12:57.00 | brlcad | will turning off warnings turn off strict? |
| 12:57.26 | starseeker | Hmm... I don't believe so |
| 12:58.04 | starseeker | but turning off warnings with strict on won't work, because strict will catch it and turn them back on |
| 12:58.32 | brlcad | to be continued then.. the overarching issue is this: |
| 12:58.50 | starseeker | the logic flow is in misc/CMake/CompilerFlags.cmake |
| 13:00.31 | brlcad | we want the ATTR_FORMAT warnings to be reported for a bu_log calls, but we also want verbose warnings and strict all of the time (and by default) ... so there's a whole category of warnings that we can't enable when strict is on because our own code will trip them |
| 13:00.58 | starseeker | right |
| 13:01.33 | *** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de) | |
| 13:01.34 | brlcad | if there's a way for the format warnings (on bu_log) to be issued whenever strict is off (ideally when warnings are on), then we should be fine |
| 13:02.12 | starseeker | Oh... you DO want to see the %V warnings if strict is off? |
| 13:02.20 | starseeker | found that a serious distraction |
| 13:02.48 | brlcad | only because I fixed the 100's of other valid warnings that provided by adding it |
| 13:03.20 | starseeker | then what about adding -Wno-format to STRICT? |
| 13:03.30 | brlcad | because we want Wformat for stdio calls |
| 13:03.37 | starseeker | hmm |
| 13:04.17 | starseeker | valid warnings in bu_log functions? |
| 13:04.26 | brlcad | yep, tons of them |
| 13:04.42 | brlcad | there was just that one niche that couldn't be quelled |
| 13:05.01 | brlcad | so it's good to have reported otherwise they won't get fixed |
| 13:05.09 | brlcad | it just can't be a build stopper |
| 13:05.23 | brlcad | that's why it only toggled off with strict |
| 13:06.06 | starseeker | what about adding -Wno-error=format |
| 13:06.15 | starseeker | to just the strict build |
| 13:06.34 | starseeker | then strict and warning outputs will be consistent |
| 13:06.41 | brlcad | that still turns off stdio format warnings being errors, and they're more problematic than our bu calls |
| 13:06.52 | brlcad | might be fine |
| 13:07.12 | starseeker | what threw me was the warnings being more verbose on just warning than on strict |
| 13:07.21 | starseeker | i'd rather the warnings still be present in strict |
| 13:07.52 | brlcad | but therein they fundamentally can't unless ATTR_ is always disabled |
| 13:08.01 | brlcad | it's either reporting for our bu funcs or it's not |
| 13:08.24 | starseeker | so the risk of Wno-error=format is that it won't hault on non-bu_log specific errors? |
| 13:08.34 | starseeker | and hence we ignore them |
| 13:08.40 | brlcad | right |
| 13:09.24 | starseeker | we're paying a high price for %V - is it really that useful? |
| 13:09.37 | brlcad | I *really* just want some way to tell the compiler about %V :) |
| 13:10.50 | brlcad | I think it is -- that's a lot of bu_vls_addr() calls that make reading bu_log statements long and messy |
| 13:11.09 | starseeker | what about some kind of macro? |
| 13:11.20 | brlcad | o.O |
| 13:11.45 | brlcad | crap, late .. to be continued :) |
| 13:11.55 | starseeker | k, gotta get moving myself |
| 13:12.02 | starseeker | I'll put it back |
| 13:13.45 | CIA-14 | BRL-CAD: 03starseeker * r43813 10/brlcad/trunk/ (4 files in 3 dirs): Sigh. %V is a pain, but we do want the warnings if -Werror isn't around. |
| 13:16.05 | CIA-14 | BRL-CAD: 03starseeker * r43814 10/brlcad/trunk/src/librt/ (search.c search.h): yipe, stray librt/search code got sucked in by mistake |
| 13:17.44 | starseeker | gah! |
| 13:17.55 | starseeker | what'd I do to search |
| 13:20.53 | CIA-14 | BRL-CAD: 03starseeker * r43815 10/brlcad/trunk/src/librt/ (search.c search.h): Whoops, looks like I only committed the global variable removal to cmake branch. Silly me. |
| 13:30.18 | CIA-14 | BRL-CAD: 03starseeker * r43816 10/brlcad/branches/cmake/ (8 files in 5 dirs): (log message trimmed) |
| 13:30.19 | CIA-14 | BRL-CAD: MFC r43815, put STRICT_FLAGS back where it was - apparently the presence of %V |
| 13:30.19 | CIA-14 | BRL-CAD: warnings only in non-strict builds is expected - we want to see other bu_log |
| 13:30.19 | CIA-14 | BRL-CAD: related warnings that are valid, and cannot separate the wheat from the chaff |
| 13:30.19 | CIA-14 | BRL-CAD: when it comes to the error reporting, so we have to make that tradeoff in order |
| 13:30.19 | CIA-14 | BRL-CAD: to add -Werror. This is very unfortunate since it means a strict build isn't |
| 13:30.20 | CIA-14 | BRL-CAD: sufficent to catch all valid warnings and a NON-strict build is also required |
| 13:34.36 | *** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net) | |
| 13:52.31 | starseeker | brlcad: ok, so a macro probably isn't workable/useful |
| 13:53.20 | starseeker | what about having bu_log accept %s for a VLS and a normal string, and then checking which it is on the backend and doing the right thing? |
| 13:57.58 | starseeker | couldn't it check the vls_magic to identify whether the input was a vls or not? |
| 14:06.39 | CIA-14 | BRL-CAD: 03starseeker * r43817 10/brlcad/branches/STABLE/ (565 files in 146 dirs): Sync STABLE to trunk r43816 |
| 14:06.52 | starseeker | ah, fairly painless - phew |
| 14:07.02 | starseeker | heads in |
| 14:21.23 | brlcad | awesome, thanks! |
| 14:21.27 | brlcad | tests |
| 14:36.52 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.140) | |
| 14:36.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:36.54 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.137.140) | |
| 15:25.10 | dloman | anyone else having issues with the cmake brlcad branch? |
| 15:36.29 | *** join/#brlcad Nohla (~Nohla@64.76.19.227) | |
| 16:00.34 | CIA-14 | BRL-CAD: 03davidloman * r43818 10/geomcore/trunk/src/GS/GSCmdLineClient.cxx: Cmd line parsing is adding an extra element to the end of the std:list. Pop it off prior to passing list to cmd processor. |
| 16:01.53 | CIA-14 | BRL-CAD: 03davidloman * r43819 10/geomcore/trunk/src/GS/GSCmdLineClient.cxx: Remove the debug printer |
| 16:09.02 | brlcad | starseeker: 43814 reverted the removal of the librt global too |
| 16:09.17 | brlcad | ahh, you caught, never mind :) |
| 16:10.28 | CIA-14 | BRL-CAD: 03davidloman * r43820 10/geomcore/trunk/src/GS/GSCmdLineClient.cxx: Since the cmd was copied from the front of the stack, pop off the first element prior to passing to the cmd processor. |
| 16:12.47 | dloman | looks like thats the last of the qt ripout bugs.... |
| 16:22.15 | starseeker | dloman: what's the issue with the cmake branch? |
| 16:23.01 | dloman | during config, it was failing when 'trycompile'-ing the base types like int and short and long |
| 16:23.12 | starseeker | O.o |
| 16:23.17 | starseeker | what platform? |
| 16:23.26 | dloman | i verified (via the brlcad trunk) that i actually had that support :) |
| 16:23.30 | dloman | ubuntu 10.10 |
| 16:23.36 | starseeker | is this a new failure? |
| 16:23.41 | dloman | lemme get the specific failure. |
| 16:23.44 | dloman | yeah |
| 16:23.55 | dloman | worked fine last time I compiled (...firday i think) |
| 16:23.59 | dloman | err friday |
| 16:24.03 | starseeker | probably has something to do with the cflags rework, but that's a bit surprising |
| 16:26.21 | dloman | starseeker: http://pastebin.com/FsMdxkuP |
| 16:26.31 | dloman | yeah, it was rather odd, imho |
| 16:26.46 | dloman | "Wait, I don't have an int anymore? WTF.." |
| 16:27.25 | starseeker | dloman: I can't see that - can you try pastebin.mozilla.org? |
| 16:27.59 | dloman | sure thing. |
| 16:28.12 | dloman | is there a 'paste bin of choice for BRLCAD-ers' ? |
| 16:28.40 | starseeker | not really - I think the bzflag one was taken down a while ago, so usually the lisp or the mozilla one get used |
| 16:29.56 | dloman | http://pastebin.mozilla.org/1140041 |
| 16:31.09 | starseeker | dloman: is that a clean build dir? |
| 16:31.17 | starseeker | i.e. a clean cmake run? |
| 16:31.29 | dloman | yuppers! |
| 16:31.41 | dloman | lemme svn up, nuke and redo one more time.... justincase |
| 16:31.44 | starseeker | what's you're cmake line? |
| 16:31.54 | starseeker | cmake ../brlcad-cmake or some such? |
| 16:32.10 | starseeker | s/you're/your |
| 16:32.40 | dloman | interesting.... |
| 16:32.48 | dloman | on the SVN UP |
| 16:33.03 | dloman | it told me it 'restored' src/other/zlib/zconf.h |
| 16:33.08 | dloman | that normal? |
| 16:33.09 | starseeker | that's expected |
| 16:33.13 | dloman | kk |
| 16:33.28 | starseeker | zconf.h needs to not be present for CMake but must be present for autotools |
| 16:33.29 | dloman | ...so something is altering the src tree? isn't that naughty? |
| 16:33.54 | starseeker | until we're not building autotools anymore, it has to stay in the repository - so CMake gets rid of it for a cmake build |
| 16:34.05 | dloman | kk |
| 16:34.20 | dloman | fyi the cmake line is: cmake ../brlcad-cmake/ |
| 16:34.29 | starseeker | yes, it's naughty - I don't like it, but as long as we need both autotools and cmake support there's not much I can do |
| 16:34.35 | starseeker | k |
| 16:34.37 | dloman | just did a clean checkout, clean build. same error. |
| 16:35.02 | starseeker | hmm |
| 16:35.14 | starseeker | it wants TERMLIB... |
| 16:35.22 | dloman | in classic Chris Farley: "What'd you DO?!?!" |
| 16:35.27 | dloman | =P |
| 16:36.51 | starseeker | dloman: can you post... one sec... |
| 16:37.24 | starseeker | well, for starters, can you post the full build log from cmake../brlcad-cmake to failure? |
| 16:41.16 | dloman | console capture or is there a specific log file you want? |
| 16:41.44 | starseeker | console capture for starters |
| 16:41.49 | starseeker | may need something more specific |
| 16:42.03 | dloman | http://pastebin.mozilla.org/1140086 |
| 16:42.40 | dloman | nice. malloc failure. turns out i really dont have 1.76TB of ram... hrm... |
| 16:42.46 | dloman | debugs |
| 16:43.57 | starseeker | dloman: do you have a CMakeError.log file in CMakeFiles? |
| 16:46.32 | dloman | lemme look |
| 16:47.10 | dloman | yup. u want? |
| 16:47.17 | starseeker | please |
| 16:47.19 | CIA-14 | BRL-CAD: 03starseeker * r43821 10/geomcore/trunk/include/ (5 files): Don't think they're in the right places yet, but start putting some of the docs into doxygen comments. |
| 16:47.33 | starseeker | TERMLIB needs to be defined, and it isn't |
| 16:48.24 | dloman | http://pastebin.mozilla.org/1140101 |
| 16:52.27 | starseeker | ummm. |
| 16:52.30 | starseeker | weird |
| 17:23.25 | CIA-14 | BRL-CAD: 03starseeker * r43822 10/brlcad/branches/cmake/src/other/ (4 files in 4 dirs): Ah, that was where the extra m64s were coming from - don't use FORCE when setting CFLAGS. Tcl/Tk build logic needs a revisit |
| 17:29.52 | starseeker | dloman: by the way, geomcore should generate doxygen docs for you now with "make doxygen" |
| 17:47.52 | CIA-14 | BRL-CAD: 03starseeker * r43823 10/geomcore/trunk/doc/URL_URI_URN: Add examples for url type requests |
| 17:55.36 | *** join/#brlcad _psilva_ (~psilva@12.160.193.229) | |
| 18:01.09 | starseeker | Program received signal EXC_BAD_ACCESS, Could not access memory. |
| 18:01.09 | starseeker | Reason: KERN_INVALID_ADDRESS at address: 0x746e6575 |
| 18:01.20 | starseeker | 0x0018572a in ControlledThread::start (this=0x6024e0) at geomcore/src/utility/ControlledThread.cxx:40 |
| 18:01.27 | starseeker | 40 bool preRetVal = this->preStartupHook(); |
| 18:07.42 | *** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net) | |
| 18:34.51 | *** join/#brlcad ezzieyguywuf (~wolfie@unaffiliated/ezzieyguywuf) | |
| 18:53.44 | ``Erik | heh http://games.slashdot.org/story/11/03/09/1546225/Cloud-Gaming-With-Ray-Tracing |
| 19:52.15 | *** join/#brlcad Ralith (~ralith@d142-058-095-082.wireless.sfu.ca) | |
| 19:59.40 | *** join/#brlcad dtidrow_ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) | |
| 22:20.46 | *** join/#brlcad dli (~dli@132.205.216.62) | |
| 22:27.19 | *** join/#brlcad yukonbob (~bch@20-144.wireless.kamloops.net) | |
| 23:01.56 | CIA-14 | BRL-CAD: 03starseeker * r43824 10/brlcad/trunk/src/libged/red.c: Bah. Windows complicates our matching - need to allow for carriage returns as well as newlines. This exposes other problems, as apparently red was never able to successfully parse a Windows text file. |
| 23:02.54 | starseeker | the regular expression matching is failing on Windows on the last item before the end of the file - it's almost as if it doesn't recognize that it needs to stop |
| 23:03.20 | starseeker | dunno if that's regex, the bu_mapped_file, or what |
| 23:38.01 | starseeker | it's suggestive that the debugger in windows didn't know how to print the last line cleanly but the one on Mac does print cleanly (i.e. no trailing garbage after the last comb tree entry) |
| 23:45.04 | *** join/#brlcad Ralith (~ralith@d142-058-095-082.wireless.sfu.ca) | |
| 00:21.21 | starseeker | probably shouldn't need this but wants to read it anyway: http://www.amazon.com/Art-Debugging-GDB-DDD-Eclipse/dp/1593271743 |
| 00:47.36 | brlcad | starseeker: did the file have a trailing newline? |
| 00:47.45 | brlcad | er, newline+cr |
| 00:48.37 | brlcad | Ahh.. ddd ... the first debugger I ever used. |
| 00:48.51 | brlcad | that was a neat debugger, pretty memory graphs |
| 00:48.59 | Ralith | oo, it has graphs? |
| 00:49.01 | Ralith | install |
| 00:49.24 | brlcad | yeah, if you had a linked list, you'd see your memory nodes and how they link together |
| 00:49.59 | brlcad | very simple ones, but enough to get the idea of what the data is doing |
| 00:50.36 | starseeker | brlcad: it did, but that shouldn't matter |
| 00:50.40 | brlcad | http://v3.sk/~lkundrak/grub2-gdb/ddd-ls.png |
| 00:51.03 | brlcad | starseeker: so red is still busted on windows? |
| 00:51.14 | starseeker | yes - in fact it never worked |
| 00:51.47 | starseeker | wonders how many white hairs he has racked up due to red... |
| 00:52.18 | brlcad | 'never' is a very long time with brl-cad, you sure? :) |
| 00:52.59 | starseeker | well, the new regex based version never worked |
| 00:53.08 | brlcad | that I'd believe :) |
| 00:53.21 | CIA-14 | BRL-CAD: 03starseeker * r43825 10/brlcad/branches/cmake/src/libged/red.c: MFC r43824 |
| 00:53.28 | starseeker | the regex didn't account for the brain-dead windows approach to line endings, and once we got past that the EOF situation causes a crash |
| 00:54.23 | brlcad | that's right, you are using some regex extension to match lines right? |
| 00:54.36 | CIA-14 | BRL-CAD: 0386.163.157.31 07http://brlcad.org * r2482 10/wiki/Main_Page: /* Getting started */ |
| 00:54.37 | starseeker | match across multiple lines, yes |
| 00:55.26 | starseeker | it LOOKS like regexec is running right off the end of the bu_mapped_file buffer |
| 00:55.32 | Ralith | pretty |
| 00:55.43 | Ralith | and by pretty I mean useful |
| 00:55.55 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2483 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/86.163.157.31|86.163.157.31]] ([[User talk:86.163.157.31|Talk]]); changed back to last version by [[User:Paulcs|Paulcs]] |
| 00:56.01 | brlcad | Ralith: :) |
| 00:56.16 | starseeker | wonders if he can convince work to pick up a copy of that book... |
| 00:56.29 | brlcad | ddd got its groove on back in the early 90's |
| 00:56.36 | brlcad | hasn't really ever changed unfortunately, lot of potential there |
| 00:57.08 | brlcad | starseeker: it very well may be running off the end if it's looking for an EOF |
| 00:57.19 | CIA-14 | BRL-CAD: 0386.163.157.31 07http://brlcad.org * r2484 10/wiki/Error_Messages: Initial stub |
| 00:57.27 | Ralith | suddenly SLIME doesn't hold all the cards anymore |
| 00:59.28 | starseeker | terminating with \0 may work too... that's what OSX shows me after the mapped file, anyway... |
| 01:00.03 | starseeker | had hoped the bu_mapped_file routines would have some kind of guarantee about sanity at the end of the buf, but maybe not |
| 01:04.26 | brlcad | it's just a buffer of data |
| 01:06.13 | starseeker | then I'm gonna have to do something else with it |
| 01:06.24 | starseeker | because on every platform but Windows, regexec knows to stop |
| 01:06.33 | brlcad | now what could be happening is that on windows, it doesn't have mmap() so bu_mapped_file() is falling back to simple write() calls |
| 01:06.54 | brlcad | and if it was off-by-one, it could leave off the trailing '\0' |
| 01:08.10 | brlcad | you'd probably not even notice that on code that processed one line at a time |
| 01:11.21 | starseeker | looks like it used read() to pull it in |
| 01:13.23 | CIA-14 | BRL-CAD: 03brlcad * r43826 10/brlcad/trunk/src/libbu/mappedfile.c: make sure the buffers zero-terminate in case the files being mapped do not |
| 01:14.09 | brlcad | don't know if that'll fix it, but easy enough to test |
| 01:14.16 | starseeker | is on it |
| 01:16.19 | CIA-14 | BRL-CAD: 03starseeker * r43827 10/brlcad/branches/cmake/src/libbu/mappedfile.c: MFC r43826 |
| 01:18.28 | starseeker | yep, that's got it |
| 01:18.33 | starseeker | brlcad: thanks!! |
| 01:18.59 | starseeker | will have to check for other cases were n isn't enough in regex expressions |
| 01:20.42 | starseeker | looks like red may be the only case... |
| 01:21.31 | brlcad | your regex doesn't look right |
| 01:21.48 | brlcad | [[:blank:]\r?\n] |
| 01:22.08 | brlcad | presumably implying \r is optional, but that's not what ? means there |
| 01:22.21 | brlcad | it's a char class |
| 01:22.30 | brlcad | [[:blank:]\r\n]* |
| 01:22.40 | brlcad | or [[:blank:]\r\n]+ |
| 01:22.56 | starseeker | hmm... wonder why it worked |
| 01:23.08 | brlcad | because you're matching a literal '? |
| 01:23.16 | brlcad | exactly once |
| 01:23.32 | brlcad | ? or space or \r or \n |
| 01:24.14 | brlcad | several places that pattern repeats |
| 01:25.32 | starseeker | ah |
| 01:25.41 | starseeker | so I probably don't need the ? then |
| 01:27.35 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 01:27.35 | CIA-14 | BRL-CAD: deleted "[[Error Messages]]": there needs to be more purpose than just itemizing |
| 01:27.35 | CIA-14 | BRL-CAD: possible error messages coming from brl-cad tools. the one you listed isn't |
| 01:27.35 | CIA-14 | BRL-CAD: even exactly an 'error' as it is an explanation why it skips _GLOBAL |
| 01:30.54 | CIA-14 | BRL-CAD: 03starseeker * r43828 10/brlcad/trunk/src/libged/red.c: Tweak the regex expressions for carriage return correctness - hopefully that's closer |
| 01:34.08 | starseeker | has to head out, will try new regex stuff tomorrow |
| 01:34.27 | CIA-14 | BRL-CAD: 03starseeker * r43829 10/brlcad/branches/cmake/src/libged/red.c: MFC r43828 |
| 01:34.49 | CIA-14 | BRL-CAD: 03brlcad * r43830 10/brlcad/trunk/src/libged/red.c: |
| 01:34.50 | CIA-14 | BRL-CAD: simplify with the [:space:] character class which already includes newline and |
| 01:34.50 | CIA-14 | BRL-CAD: carriage return. [:blank:] is a gnu extension and won't necessarily be |
| 01:34.50 | CIA-14 | BRL-CAD: supported for a given vendor regex library. also fix a missed character class |
| 01:34.50 | CIA-14 | BRL-CAD: '?' inclusion with the [:space:] swappage. |
| 01:38.45 | starseeker | sighs - someday I'll understand regex... |
| 01:38.57 | CIA-14 | BRL-CAD: 03starseeker * r43831 10/brlcad/branches/cmake/src/libged/red.c: MFC r43830 |
| 01:42.29 | starseeker | huh - apparently Kitware has a free CDash service: http://my.cdash.org/ |
| 01:43.39 | starseeker | wow http://my.cdash.org/index.php?project=OpenStudio |
| 01:43.41 | brlcad | yep |
| 01:43.49 | CIA-14 | BRL-CAD: 03brlcad * r43832 10/brlcad/trunk/src/libged/red.c: semper fi, er, simplify. let things fall through so there is only one copy of the cleanup code and a consolidated simplified return location. |
| 01:44.24 | starseeker | brlcad: would that serve for a BRL-CAD reporting setup or would we want our own CDash server? |
| 01:44.26 | brlcad | man that looks like ass |
| 01:44.43 | brlcad | I *want* to love cdash .. but that ui is a bit of an eyesore :) |
| 01:44.51 | starseeker | hehe |
| 01:45.06 | brlcad | I'd think we'd still want our own, but still up to whomever does the work in my book |
| 01:45.28 | starseeker | well, we could always rip off the CruiseControl generated html and teach CDash to output that instead... |
| 01:45.28 | brlcad | that way we could hook scripting into the loop for custom actions |
| 01:46.00 | brlcad | it is just the reporting front-end, so you still have to have compilation nodes set up and sending in results |
| 01:46.12 | starseeker | right |
| 01:46.18 | brlcad | cruisecontrol is the other one I couldn't remember |
| 01:46.23 | brlcad | buildbot the third |
| 01:46.36 | starseeker | cruisecontrol had the GUI you liked? |
| 01:47.06 | brlcad | http://cruisecontrol.sourceforge.net/ |
| 01:47.18 | brlcad | it's really easy to use |
| 01:47.55 | brlcad | features neatly grouped together with simplified reporting, then options to dive into more detail or even raw build logs only when you ask for it |
| 01:47.57 | CIA-14 | BRL-CAD: 03starseeker * r43833 10/brlcad/branches/cmake/src/libged/red.c: MFC r43832 |
| 01:48.19 | starseeker | hmm... guess we could use their exec builder to fire off cmake |
| 01:48.49 | CIA-14 | BRL-CAD: 03brlcad * r43834 10/brlcad/trunk/src/libged/red.c: ws cleanup |
| 01:49.38 | brlcad | yep |
| 01:49.49 | brlcad | though again, strong emphasis on "no strong preference" |
| 01:50.20 | brlcad | if you or anyone else wanted to even just play with a small random pet-project CI system, I'd take no issue |
| 01:50.40 | starseeker | is wary of a tool brlcad doesn't like the looks of (*memories of font discussions and graphical layout issues*) |
| 01:50.53 | brlcad | it's much more important that we have continuous integration than we have "the best" |
| 01:51.21 | brlcad | I'd get used to any dashboard so long as it wasn't a maintenance burden or timesink |
| 01:51.50 | starseeker | wonder where we can run enough virtual machines to hit all the configs and not create a pool of molten metal... |
| 01:51.59 | brlcad | their whole purpose is to report failures simply and *quickly* so they get caught as early as possible, so they can get isolated and fixed as early/easily as possible |
| 01:52.06 | starseeker | pity sourceforge took down that server farm |
| 01:52.45 | brlcad | any desktop machine with a few corew would be sufficient enough to crank out a half-dozen builds an hour |
| 01:53.24 | starseeker | dynamic lib only and no docs, maybe... |
| 01:54.07 | starseeker | unless maybe virtual machine overhead is lower these days than I remember |
| 01:55.04 | brlcad | anything that can presently compile the package in less than 10 minutes should be sufficient |
| 01:55.37 | starseeker | wonder if we could prepare stripped down virtual box/qemu images set up to build BRL-CAD and report, then set them up as downloadable goodies for people who want to pile in and and automatically test... setiathome for BRL-CAD :-P |
| 01:56.29 | brlcad | at worse, you get another box or two or have different types of test builds -- quick fast simple reduced builds across everything on one box, then a more extensive slower build box that runs the full regression, docs, bench, etc at a slower rate |
| 01:57.00 | brlcad | heh, I'm not sure that'd be useful :) |
| 01:57.16 | brlcad | if it was a vm image, we'd get tons of reports testing the exact same thing |
| 01:57.35 | starseeker | well, we wouldn't need hundereds of testers - but we could have a list of "images we need testing and need volunteers for" |
| 01:58.06 | brlcad | better would be a build target or even a shell script that took a given checkout or source tarball through all the paces, and reported back |
| 01:58.35 | brlcad | so we could basically get a report anytime someone tried to build |
| 01:58.48 | starseeker | that'd be configuration explosion though |
| 01:59.02 | brlcad | sure, so? :) |
| 01:59.07 | brlcad | entries in a db is all |
| 01:59.17 | brlcad | we hit up the most common failure reports |
| 01:59.28 | brlcad | till there are none |
| 01:59.32 | starseeker | that sounds a bit different than cruisecontrol/cdash... |
| 01:59.44 | brlcad | they'd report to cc/cd |
| 02:00.04 | starseeker | I got the impression cc/cd didn't know the details about the machine/os/etc... |
| 02:00.12 | starseeker | maybe I didn't look close enough |
| 02:00.48 | brlcad | doesn't really have to know, it just has to send in results -- we could easily put machine details into a log that is sent back |
| 02:00.56 | brlcad | benchmark suite does exactly that now |
| 02:01.05 | starseeker | nods |
| 02:01.18 | brlcad | speaking of such |
| 02:01.40 | brlcad | we're going to have to really kick in gear things into gear thursday if gsoc app is going to happen |
| 02:01.58 | starseeker | ah, we're coming up on the deadline? OK |
| 02:02.10 | starseeker | hunts for the wiki page with project ideas |
| 02:02.16 | brlcad | deadline is friday mid-day |
| 02:02.35 | brlcad | it'll take me a couple hours to write up the application submission |
| 02:02.50 | starseeker | k - what do you need me to do firstist and mostist? |
| 02:02.57 | brlcad | few hours for someone to work up a (VERY) detailed project ideas page |
| 02:03.43 | brlcad | they gave feedback in '09 that our ideas page needed a lot more ideas and detail (but that they were going to accept us anyways) |
| 02:03.48 | starseeker | update http://brlcad.org/wiki/Google_Summer_of_Code/Project_Ideas or start over? |
| 02:04.07 | starseeker | s/update/expand upon |
| 02:04.18 | brlcad | I'd start with http://brlcad.org/wiki/Google_Summer_of_Code/, update any references to dates/times/requirements |
| 02:04.31 | brlcad | add new section for 2011 where there are dated sections |
| 02:04.46 | starseeker | right |
| 02:05.22 | brlcad | the project ideas page for 2008 was moved to http://brlcad.org/wiki/Google_Summer_of_Code/2008/Project_Ideas |
| 02:05.43 | brlcad | so can do the same for 2009 and either start a new http://brlcad.org/wiki/Google_Summer_of_Code/Project_Ideas or expand on it |
| 02:06.30 | brlcad | I think we should strongly de-emphasize projects that let devs code alone like we've had in the past |
| 02:06.30 | starseeker | they wanted MORE ideas?? we've got quite a few here |
| 02:06.38 | brlcad | yeah, ironic, eh? |
| 02:07.17 | starseeker | so, no going off in the corner and working on iges or step? |
| 02:07.33 | brlcad | we get compared against other big-boys, they expect more |
| 02:07.36 | brlcad | e.g., http://www.freebsd.org/projects/summerofcode.html#ideas |
| 02:07.54 | brlcad | freebsd's whole set of gsoc pages is arranged decently |
| 02:08.06 | brlcad | notice how those idea links expand to something even more impressive |
| 02:09.16 | brlcad | yeah, ideally not things like iges/step unless they have some exceptional familiarity in that area |
| 02:09.21 | starseeker | brlcad: they can code almost anything alone if they put their minds to it... |
| 02:09.38 | brlcad | something that will make them explore the code better, reuse, refactor, integrate |
| 02:10.06 | brlcad | the only project that might be an exception would be continuation of new gui |
| 02:11.06 | starseeker | nods... I'll do my best... |
| 02:11.31 | starseeker | would continuation of the constraints work fall under the integrate category or the isolated category? |
| 02:12.54 | starseeker | crud - I've gotta get outta here |
| 02:13.30 | brlcad | starseeker: better example of an "integrated" projects that would benefit us you can add/expand: ogre display manager, qt display manager, qt framebuffer, cross-platform adrt, libged transactions, .. maybe a quick scan down TODO for the bigger tasks |
| 02:13.45 | brlcad | constraint continuation would be integrated |
| 02:14.14 | brlcad | goal would have to be something precise like prep or parameters hooked into mged menus, etc |
| 02:15.44 | brlcad | also need mentors to step up: dloman indianlarry ``Erik louipc yukonbob poolio or anyone else |
| 02:15.59 | brlcad | since I'll need your google id again |
| 03:22.13 | starseeker | brlcad: oh - any opinion on using %s for both strings and vls in bu_log? |
| 03:28.30 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Google Summer of Code/Project Ideas]] moved to [[Google Summer of Code/2009 Project Ideas]]: Moving old Project Ideas page to a date specific location - time for a new one. |
| 03:38.01 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2487 10/wiki/Google_Summer_of_Code/Project_Ideas: Start layout setup for the new Project Ideas iteration |
| 03:49.01 | brlcad | erp, missing slash |
| 03:51.00 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 03:51.00 | CIA-14 | BRL-CAD: deleted "[[Google Summer of Code/Project Ideas]]": content was: 'The list of |
| 03:51.00 | CIA-14 | BRL-CAD: possible projects below should serve as a good starting point for new developers |
| 03:51.00 | CIA-14 | BRL-CAD: that would like to get involved in working on BRL-CAD. Th...' (and the only |
| 03:51.00 | CIA-14 | BRL-CAD: contributor was '[[Special:Contributions/Starseeker|Starseeker]]') |
| 03:51.09 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Google Summer of Code/2009/Project Ideas]]": Deleted to make way for move |
| 03:51.11 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Google Summer of Code/2009 Project Ideas]] moved to [[Google Summer of Code/2009/Project Ideas]]: consistency with 2008 |
| 03:51.42 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2490 10/wiki/Google_Summer_of_Code/2009: refere to old ideas page |
| 03:52.40 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: restored "[[Google Summer of Code/Project Ideas]]": 2 revision(s) restored: hrm, looks like mw or I was confused with a bogus url |
| 03:53.30 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2491 10/wiki/Google_Summer_of_Code/2009: historic ref |
| 03:54.04 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2492 10/wiki/Google_Summer_of_Code/2009/Project_Ideas: historic ref |
| 03:56.34 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2493 10/wiki/Google_Summer_of_Code/2009: past tense |
| 04:00.25 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2494 10/wiki/Google_Summer_of_Code: reword for past tense |
| 04:04.26 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2495 10/wiki/Google_Summer_of_Code: reword for more awesome |
| 04:05.57 | brlcad | starseeker: my inclination is that would be bad (overloaded behavior, inconsistent, probably more confusing than warnings) and probably wouldn't even work since the compiler is supposed to validate that typeof() is a char* for %s, which it wouldn't be |
| 04:10.17 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2496 10/wiki/Google_Summer_of_Code/2011: stub in for 2011 |
| 04:13.37 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2497 10/wiki/Google_Summer_of_Code/Checklist: numbered list |
| 04:14.17 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2498 10/wiki/Google_Summer_of_Code/Checklist: retitle |
| 04:15.28 | starseeker | growl... so we're permenantly stuck with the %V warnings then |
| 04:16.23 | starseeker | unless we get the gcc devs to add a new feature, and even then it'll only be in the newest gcc versions |
| 04:16.53 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2499 10/wiki/Google_Summer_of_Code/Checklist: regroup for clarity |
| 04:17.44 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2500 10/wiki/Google_Summer_of_Code/Checklist: subtasks don't need to be numbered |
| 04:21.57 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2502 10/wiki/Google_Summer_of_Code: KISS |
| 04:23.14 | brlcad | wonders if dloman would be willing to work up this year's gsoc flyer |
| 04:24.04 | brlcad | ( prior examples at http://brlcad.org/wiki/Google_Summer_of_Code#BRL-CAD_participation_in_GSoC ) |
| 04:31.58 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2503 10/wiki/Google_Summer_of_Code/Checklist: add deadline dates |
| 04:33.11 | brlcad | that's about all I can push through for tonight |
| 04:33.18 | brlcad | need to get back to release |
| 04:33.20 | starseeker | nods |
| 04:35.10 | brlcad | thinks we need at least 30 fleshed out ideas, perhaps categorized similar to http://brlcad.org/wiki/Contributor_Quickies |
| 04:35.29 | brlcad | (EASY, MEDIUM, HARD) |
| 04:36.06 | brlcad | or Web, C, C++, Tcl |
| 04:36.15 | brlcad | both |
| 04:36.36 | starseeker | brlcad: OK... I'm just tossing stuff up right now, I'll sort it once it's more fleshed out |
| 04:36.42 | brlcad | nods |
| 04:37.11 | brlcad | you can probably utilize the entire 2009 list and just keep adding more, remove the one or two that are no longer relevant |
| 04:38.03 | starseeker | oh - I was starting with the whole "more interactive" thing and was gonna review the 2009 list to see what qualified... |
| 04:39.26 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2504 10/wiki/Google_Summer_of_Code/Project_Ideas: More ideas - this isn't anything like final form, probably - just scratchpad |
| 04:40.30 | brlcad | typo in the top title section |
| 04:40.45 | brlcad | sure, however you wanna do it :) |
| 04:40.58 | starseeker | the "AN IDEA" one? |
| 04:40.59 | brlcad | aim for 50, hopefully we'll get to 40 :) |
| 04:41.05 | brlcad | "=." |
| 04:41.17 | starseeker | oh, good eye |
| 04:41.41 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2505 10/wiki/Google_Summer_of_Code/Project_Ideas: |
| 04:41.47 | starseeker | kinda liked FreeBSD's grouping by larger scale topic |
| 04:42.09 | starseeker | I'll take a whack, then you can tell me why it's wrong :-P |
| 04:42.26 | starseeker | brlcad: did you want to get those red changes into this release? |
| 04:45.59 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 04:56.00 | *** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net) | |
| 04:57.26 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2506 10/wiki/Google_Summer_of_Code/Project_Ideas: list a few more things... |
| 04:58.00 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2507 10/wiki/Google_Summer_of_Code/Project_Ideas: Constraint solver needs its own page |
| 04:58.33 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2508 10/wiki/Geometric_Constraint_Solver: Put description on individual page |
| 05:09.28 | starseeker | brlcad: do you happen to know whether or not its possible to recognize an arbitrary NURBS surface as being a component of (say) a sphere or a torus? |
| 05:10.30 | Ralith | starseeker: is BRL-CAD doing SoC this year? |
| 05:10.35 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2509 10/wiki/Google_Summer_of_Code/Project_Ideas: More tasks to flesh out... |
| 05:10.43 | starseeker | we'll see :-) |
| 05:11.24 | Ralith | if so, will almost certainly submit a GPU accel proposal. |
| 05:18.59 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2510 10/wiki/Google_Summer_of_Code/Project_Ideas: Couple more NURBS ideas... |
| 05:26.26 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2511 10/wiki/Ayam_Editor_Feature_Integration: Toss a few notes into the Ayam/NURBS entry |
| 05:53.25 | brlcad | starseeker: did someone report red? |
| 05:53.31 | starseeker | Victor |
| 06:06.27 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2512 10/wiki/Google_Summer_of_Code/Project_Ideas: That's around 30 ideas... some work to do tomorrow |
| 06:50.18 | brlcad | Ralith: one never knows until orgs are announced |
| 06:51.02 | Ralith | yeah, meant to ask "applying" |
| 06:51.07 | Ralith | and wiki confirms |
| 06:51.44 | brlcad | starseeker: not definitively unless the surfaces are tagged with originating geometry |
| 06:53.02 | brlcad | Ralith: yeah, it looks like we're probably applying if I can get a couple more mentors to sign on |
| 06:53.10 | Ralith | awesome |
| 06:53.32 | Ralith | would be a great way to spend the summer |
| 06:54.36 | brlcad | Ralith: I'd be cautious about a gpu accel project for the same aforementioned "prefer integrated code, minimal 'new code'" concerns -- it'd have to be very specific about how it'd be integrated and beneficial |
| 06:55.35 | brlcad | and from a former gsoc'er, you'll have to work twice as hard to convince |
| 06:56.19 | Ralith | hm, that's a shame |
| 06:57.12 | brlcad | not really, it's only fair to the 3k other students :) |
| 06:57.21 | Ralith | hah |
| 06:57.23 | Ralith | yeah |
| 06:58.23 | brlcad | if someone had been more actively commiting over the past year and a half, it'd be a totally different story ;) |
| 06:58.24 | Ralith | may play with it anyway, depending on what else I end up doing |
| 06:58.27 | brlcad | hell, even passively :) |
| 06:59.29 | Ralith | looks slightly regretful |
| 07:00.08 | brlcad | the point of gsoc is to get students engaged in open source, even if it's not brl-cad ... http://www.ohloh.net/p/brlcad/contributors/17162689320215 tells a sad story |
| 07:00.45 | Ralith | yes, it's quite true |
| 07:00.51 | Ralith | though I've been plenty active elsewhere |
| 07:00.56 | Ralith | not sure why ohloh hasn't picked up on that |
| 07:01.10 | brlcad | not intending to pick on you personally, just saying that puts you back into the boat with everyone else on level standing |
| 07:01.18 | Ralith | I know |
| 07:01.30 | brlcad | you can combine accounts |
| 07:02.07 | Ralith | I think most of the projects simply aren't on ohloh |
| 07:02.11 | Ralith | which can be remedied, certainly |
| 07:02.37 | Ralith | but anyway, not too relevant |
| 07:03.24 | brlcad | yeah, the project itself is more the issue, it'd have to be carefully spelled out |
| 07:03.50 | Ralith | nod |
| 07:04.19 | brlcad | for example, most of the gpgpu research is on accellerating triangle raytracing -- that's just not very interesting any more, especially now that we have our new TIE library integrated with LIBRT |
| 07:04.23 | Ralith | mainly it strikes me as a good opportunity to learn more about raytracing and rt's internals in particular, as well as GPU frobbery |
| 07:04.52 | Ralith | hm. |
| 07:05.03 | Ralith | I wasn't aware it was a research area per se |
| 07:05.04 | brlcad | so it'd have to be some other means to accellerate librt, which would be either in the spatial partitioning, the boolean weaving, the primitive evaluations, etc |
| 07:05.14 | brlcad | oh hell yeah, a huge one |
| 07:05.40 | Ralith | isn't raytracing embarassingly parallel across each ray? |
| 07:05.55 | brlcad | nvidia and intel fighting it out, both trying to push gpgpu raytracing into gaming, it's been five years+ in the making |
| 07:06.02 | brlcad | yes? |
| 07:07.06 | Ralith | perhaps I drastically misunderstand the problem, but wouldn't simply mapping rays across GPU compute units—with fairly straight port of the relevant rt code—be a huge gain? |
| 07:07.39 | brlcad | mapping rays to the gpu is trivial, days work |
| 07:07.52 | brlcad | you have to evaluate and march those rays |
| 07:07.57 | brlcad | against geometry |
| 07:08.06 | Ralith | right, I meant mapping the entire process |
| 07:08.48 | brlcad | so how does one evaluate whether a ray intersects with a torus on the gpu? |
| 07:09.00 | brlcad | heck, even a simple sphere |
| 07:09.27 | brlcad | it's doable, but it's not a 1-1 mapping or a mere matter of "porting" anything |
| 07:09.49 | brlcad | you generally have to completely rethink how data is packed and evaluated |
| 07:10.46 | Ralith | I guess it should have been obvious that the hardware is ill-optimized for the subtleties of geometry more complex than triangles. |
| 07:10.49 | brlcad | that's why most of the research is just with triangles -- only have to deal with one entity type that is very trivial to evaluate, has a fixed constant data size, etc |
| 07:11.10 | Ralith | that sounds a bit beyond what I can accomplish based on what I know, at least in a single summer. |
| 07:11.22 | brlcad | the hardware isn't even really geared for triangles, but the calculations are so few |
| 07:11.31 | Ralith | well |
| 07:11.37 | Ralith | sketchy understanding here |
| 07:12.02 | brlcad | you actually *can* do spheres even easier if you apply the same techniques you apply for triangles, but then a beast like a torus becomes super problematic because it requires a root solver |
| 07:12.03 | Ralith | but aren't GPUs pretty much all about vector ops, and triangles trivial to work with within those? |
| 07:12.21 | brlcad | yep, that's where fixed data size becomes a win |
| 07:12.30 | brlcad | *small* fixed data size |
| 07:12.43 | Ralith | and the math, surely? |
| 07:12.58 | Ralith | well, I suppose you just said that |
| 07:13.12 | Ralith | alright, thanks for the explanation; sounds like this was ill-conceived. |
| 07:14.03 | Ralith | an interesting problem to be sure, but I don't have the background to do original work in that sort of thing. |
| 07:14.45 | brlcad | it's a great feature, a great research project, but very non-trivial to say the least -- you'd probably be able to publish in an journal or even siggraph if you got it working for general implicit geometry |
| 07:15.21 | brlcad | easier attack vector would be accelerating our boolean weaving step |
| 07:15.30 | Ralith | haven't a clue what that is O.o |
| 07:15.36 | brlcad | exactly :) |
| 07:16.19 | Ralith | ah well. |
| 07:16.23 | brlcad | that's where the "you'd have to work twice as hard to convince" came from |
| 07:16.48 | brlcad | because it could take a month just to get schooled up on the background knowledge needed |
| 07:17.08 | Ralith | knowing the scope of the problem, even that seems generous |
| 07:17.18 | Ralith | for weak values of knowing even now |
| 07:18.06 | brlcad | that's where if you were already familiar with even the basic mechanics of librt working on portions of the code consistently, that'd make for an easier case to dive into such a hard problem |
| 07:19.30 | brlcad | you'd know the application structure's purpose, how hit callbacks work, when boolean evaluation is performed, what that means, how the implicits evaluate, types of CSG dag nodes, etc |
| 07:20.22 | Ralith | perhaps continuing jonored's work on a toolpather would be more realistic? |
| 07:20.38 | brlcad | fairly complex code, highly optimized, and critical code at that which would require 100% validation |
| 07:20.49 | Ralith | though I'm not certain of my ability to find a footing with the (as far as I can tell, currently buggy) math there either |
| 07:21.11 | brlcad | what toolpather? |
| 07:21.20 | Ralith | I suppose he never posted it here |
| 07:21.31 | Ralith | you recall a while back that he was working on a gcode generator? |
| 07:21.34 | Ralith | couple years ago or so? |
| 07:21.45 | brlcad | not specifically |
| 07:21.50 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 07:21.58 | Ralith | he was, and it got abandoned in favor of his studies |
| 07:22.09 | Ralith | but I got ahold of him a few months back and got him to send me a tarball of the git repo |
| 07:22.28 | brlcad | I do recall that discussion |
| 07:22.44 | Ralith | he claims outline tracing is mostly working, though in my limited experiments I've not gotten correct output |
| 07:22.51 | brlcad | that wasn't based on brl-cad iirc, though, no? |
| 07:23.09 | Ralith | er, it uses librt to interrogate BRL-CAD databases |
| 07:23.21 | brlcad | hrm |
| 07:23.22 | Ralith | not sure how much more 'based on' it gets |
| 07:23.36 | Ralith | want a look at the tarball? |
| 07:23.55 | brlcad | not at the moment, but it is interesting |
| 07:23.59 | Ralith | kk |
| 07:24.12 | Ralith | I'll see if I can take a better look at it in the coming month and work out what state it's really in |
| 07:26.20 | brlcad | yeah, that was back in january we were talking about it |
| 07:26.28 | brlcad | you were asking about curvature |
| 07:28.31 | Ralith | yeah, jonored mentioned that torus curvature was the standing bug; I had planned to dive in and fix that if I could get it to behave for simpler primitives |
| 07:28.52 | Ralith | haven't managed that yet, though haven't put much time in it |
| 07:37.13 | brlcad | if it really is non-gui based (which an old post of his indicated), that would be a good one to get working and fully integrate |
| 07:37.25 | brlcad | basically a "g-gcode" converter |
| 07:45.21 | Ralith | it is indeed commandline. |
| 07:46.00 | Ralith | in fact it even follows the naming scheme |
| 07:46.01 | Ralith | g2gcode |
| 07:46.08 | Ralith | bear in mind, though, that additive and subtractive toolpaths are differnet beasts |
| 07:46.16 | Ralith | different* |
| 07:57.27 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 07:58.53 | Ralith | gah. |
| 07:59.14 | Ralith | journal website lists this article as 'full text available,' but when I log in through my univ it's preview only :| |
| 07:59.42 | Ralith | gunna have to get a physical copy I guess. |
| 08:08.57 | Ralith | (trying to get ahold of Martin Held's "On the computational geometry of pocket machining") |
| 08:21.55 | *** join/#brlcad Stattrav (~Stattrav@122.167.172.122) | |
| 08:21.56 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:38.38 | *** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net) | |
| 11:16.19 | d_rossberg | i get fringes on ray-tracing cones |
| 11:17.26 | d_rossberg | e.g. the havoc's tail (ae 300 0) |
| 13:47.57 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2513 10/wiki/Google_Summer_of_Code/Project_Ideas: add subversion idea |
| 13:55.10 | starseeker | brlcad: would search exec be a viable GSoC project? |
| 14:45.37 | CIA-14 | BRL-CAD: 03Erik 07http://brlcad.org * r2514 10/wiki/Google_Summer_of_Code/Project_Ideas: /* BRL-CAD Core Library Enhancement */ |
| 14:57.37 | ``Erik | cdash is heavily css driven. if it's the look and not the structure, it should be easy to make it less ugly |
| 15:20.32 | CIA-14 | BRL-CAD: 03erikgreenwald * r43835 10/geomcore/trunk/tests/utility/threadTest.cxx: programmatically test for functional threading instead of spewing junk to the screen for human analysis |
| 15:21.46 | starseeker | ``Erik: you good to mentor? |
| 15:23.06 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2515 10/wiki/Google_Summer_of_Code/Project_Ideas: Couple more line items - that's 38... |
| 15:23.19 | ``Erik | yup, msg'd brlcad my id |
| 15:24.34 | starseeker | ``Erik: can you scan that list and see if I left out any juicy items? brlcad was talking about wanting 50... |
| 15:24.55 | ``Erik | yeah, I looked over it t his morning, um |
| 15:25.16 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 15:25.17 | ``Erik | I'll splat some stuff on and if someone doesn't like it, they can remove it O.o |
| 15:25.25 | *** join/#brlcad Stattrav (~Stattrav@117.192.159.181) | |
| 15:25.25 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:31.44 | CIA-14 | BRL-CAD: 03Erik 07http://brlcad.org * r2516 10/wiki/Google_Summer_of_Code/Project_Ideas: /* BRL-CAD Core Library Enhancement */ |
| 15:32.33 | CIA-14 | BRL-CAD: 03Erik 07http://brlcad.org * r2517 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Tools */ |
| 15:36.03 | CIA-14 | BRL-CAD: 03Erik 07http://brlcad.org * r2518 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Tools */ |
| 15:36.47 | ``Erik | is [[NURBS Intersections]] an evaluation of a CSG of NURBS into a single one? |
| 15:37.10 | starseeker | no, that's just the surface/surface problem and related subproblems |
| 15:37.40 | starseeker | I doubt a summer of code student could get all the way to the final evaluated model |
| 15:37.57 | CIA-14 | BRL-CAD: 03Erik 07http://brlcad.org * r2519 10/wiki/Google_Summer_of_Code/Project_Ideas: 'csg' makes more sense than 'boolean' here |
| 15:38.58 | CIA-14 | BRL-CAD: 03Erik 07http://brlcad.org * r2520 10/wiki/Google_Summer_of_Code/Project_Ideas: /* BRL-CAD Core Library Enhancement */ |
| 15:39.25 | ``Erik | hm, can always harvest TODO and http://brlcad.org/~sean/ideas.html for some more |
| 15:39.40 | starseeker | nods - I grabbed a few out of there |
| 15:39.49 | starseeker | was trying to look for things that would be 'integrated' |
| 15:39.53 | ``Erik | orange page, too? |
| 15:39.59 | starseeker | nods |
| 15:40.20 | starseeker | for example, I'd worry that a Blender plugin would kinda be off in its own little world... |
| 15:41.01 | starseeker | now if they want to snarf the Blender file import that game kit implemented and turn it into a BRL-CAD importer... :-) |
| 15:41.24 | ``Erik | a little bit, but it would need a fair amount of communication to figure out how to translate and what functionality |
| 15:42.06 | starseeker | nods - well, we've probably got close to enough lined up there - now we need to start filling 'em in |
| 15:42.11 | ``Erik | ooh, they have one now? last I looked, their format was basically a swizzle of memory dumped to disk |
| 15:42.37 | starseeker | yeah, pretty much - apparently someone figured out how to do something intelligent with it... |
| 15:42.41 | starseeker | one sec... |
| 15:42.55 | ``Erik | starts writing a test for ControlledThread O.o |
| 15:43.06 | starseeker | http://code.google.com/p/gamekit/ |
| 15:45.15 | ``Erik | yeah, saw that before, hm |
| 15:48.18 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2521 10/wiki/Google_Summer_of_Code/Project_Ideas: |
| 16:21.27 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2522 10/wiki/OGRE_Display_Manager: Flesh out OGRE task (I think this is low difficulty?) |
| 16:21.40 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 16:45.24 | brlcad | starseeker: sure, search exec would be viable |
| 16:47.28 | brlcad | most of the index card tasks are decent gsoc tasks |
| 16:47.33 | brlcad | should do a quick scan |
| 16:48.12 | brlcad | since they're < month for us, that easily scales up to 3 months for someone else including communication, reporting, testing, and documentation |
| 17:11.35 | dli | brlcad, http://paste.pocoo.org/show/351409/ |
| 18:36.43 | CIA-14 | BRL-CAD: 03erikgreenwald * r43836 10/geomcore/trunk/tests/utility/threadTest.cxx: start stubbing in ControlledThread test |
| 18:41.51 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2523 10/wiki/Qt_Display_Manager: Qt display manager |
| 18:42.31 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2524 10/wiki/Qt_Display_Manager: Qt, not ogre |
| 18:53.59 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2525 10/wiki/Qt_Framebuffer: Qt framebuffer |
| 18:56.07 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2526 10/wiki/Qt_Framebuffer: Grr - framebuffer, not display manager |
| 19:08.51 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2527 10/wiki/Other_Cross_Platform_Framebuffer: Cross Platform framebuffer |
| 19:21.20 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2528 10/wiki/High_Dynamic_Range_Support: HDR output support |
| 19:21.27 | starseeker | ``Erik: mind reviewing the HDR one if you have a sec? |
| 19:21.57 | ``Erik | sure, um, and I just changed the css to mark the 'new' class as red, so'z you can tell which ones you've done |
| 19:22.11 | starseeker | thanks :-) |
| 19:22.30 | ``Erik | (we can revert it once this exercise is over if brlcad wants, it's in RCS) |
| 19:23.12 | ``Erik | "There is not fundamental reason" ... wow, right out of the gate :> |
| 19:23.29 | starseeker | heh, sorry - distracted |
| 19:23.35 | starseeker | (house is leaking again) |
| 19:23.50 | ``Erik | other than the picasso grammar, looks decent... |
| 19:28.10 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2529 10/wiki/High_Dynamic_Range_Support: |
| 19:40.18 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2530 10/wiki/MGED_to_Archer_Command_Migration: Command migration |
| 20:09.10 | CIA-14 | BRL-CAD: 03erikgreenwald * r43837 10/geomcore/trunk/tests/GS/GeometryServiceTest.cxx: indent |
| 20:23.33 | CIA-14 | BRL-CAD: 03erikgreenwald * r43838 10/geomcore/trunk/tests/GS/GeometryServiceTest.cxx: purdee kulurz |
| 21:01.24 | CIA-14 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2531 10/wiki/Talk:Error_Messages: wikibook |
| 21:27.22 | brlcad | dli: oh snap |
| 21:27.28 | brlcad | aua he left |
| 21:31.19 | brlcad | debates trying an application form this year |
| 21:31.34 | starseeker | for GSoc you mean? |
| 21:31.38 | brlcad | yeah |
| 21:31.49 | starseeker | does seem kinda rushed |
| 21:32.14 | brlcad | many of them just have no idea on how to pitch an idea, so there ends up being a lot of information we have to keep asking for |
| 21:33.35 | brlcad | it has helped in the past to separate out those who HAVE thought through their idea and have a lot to say, but many of those devs tend to have trouble integrating their thoughts with our codebase |
| 21:33.50 | brlcad | or worse, the ones that can write great, but can't actually code |
| 21:34.45 | starseeker | had thought about some basic "submit this code with your application" kinda things, but that takes time to define |
| 21:35.22 | CIA-14 | BRL-CAD: 03erikgreenwald * r43839 10/geomcore/trunk/tests/GS/GeometryServiceTest.cxx: more indentation, staticizing, etc |
| 21:35.26 | starseeker | ``Erik: what's your take? |
| 21:35.55 | ``Erik | *shrug* |
| 21:36.33 | ``Erik | we tried "submit a patch" a couple years back, seems it was a bit of a pain |
| 21:37.15 | starseeker | ``Erik: should we rush to get it "ready" or punt until next year? |
| 21:37.47 | brlcad | submit a patch worked pretty well I thought -- the strong patches ended up being the strong coders |
| 21:38.09 | brlcad | kept the application count down, but I think it worked |
| 21:38.23 | ``Erik | the weak patches were a depressing time sink, though :) |
| 21:38.41 | brlcad | so we be more agressive in reviewing them |
| 21:39.03 | ``Erik | starseeker: doesn't hurt to try, they're usually fairly easy going if minor tweaking is needed |
| 21:39.04 | brlcad | we can point them to the quickies this year |
| 21:39.22 | starseeker | brlcad: good idea |
| 21:39.26 | brlcad | no quickie should take more than a day or few |
| 21:39.35 | starseeker | whoops, contractor is here |
| 21:39.37 | brlcad | we can certainly expand that list |
| 21:57.01 | CIA-14 | BRL-CAD: 03erikgreenwald * r43840 10/geomcore/trunk/ (59 files in 3 dirs): footer.sh |
| 22:00.37 | ``Erik | damnit, thought I broke that soon enough |
| 22:33.17 | starseeker | brlcad: expand the projects list? I've still got to get all those fleshed out |
| 22:47.33 | *** join/#brlcad dli (~dli@dyn-216-212.wireless.concordia.ca) | |
| 23:56.42 | brlcad | starseeker: I meant the quickies list, no worries -- that'd be before they start applying, not before tomorrow |
| 00:05.57 | dli | brlcad, my second try for rt_revolve_xfrom(): http://paste.pocoo.org/show/351409/ |
| 00:10.30 | starseeker | Gah, what happened to Project Ideas |
| 00:11.10 | starseeker | oh, that's the Code_In |
| 00:11.13 | starseeker | nevermind, carry on |
| 00:21.30 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2532 10/wiki/MGED_Sketch_Editor_Migration_and_Enhancement: Sketch editor |
| 00:34.47 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2533 10/wiki/Ayam_Editor_Feature_Integration: Ayam editor integration |
| 00:45.37 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2534 10/wiki/Analytical_Raytracing_Visualization: analytical raytracing GUI |
| 00:59.07 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2535 10/wiki/Level_of_Detail_Wireframes: LOD wireframes |
| 01:10.07 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2536 10/wiki/BoT_Editing: BoT editing |
| 01:21.16 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 02:27.28 | *** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net) | |
| 02:33.12 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2537 10/wiki/NMG_Editing: NMG editing |
| 02:48.30 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2538 10/wiki/Graph_layout_based_geometry_hierarchy_view: graph based viewing |
| 02:49.33 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2539 10/wiki/Google_Summer_of_Code/Project_Ideas: |
| 02:50.10 | starseeker | Well, at this rate I'll be done in a few more days :-/ |
| 02:50.40 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 02:55.02 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2540 10/wiki/Geometric_Constraint_Solver: |
| 02:57.00 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2541 10/wiki/Google_Summer_of_Code/Project_Ideas: move HDR entry |
| 02:57.46 | KimK | On the brlcad.org homepage,what does it mean "...licensed at over 2,000 sites..."? Licensed how? |
| 02:58.11 | starseeker | KimK: I think that refers to the pre-open-source days |
| 03:00.07 | KimK | OK, thanks. I could only find BSD, GNU, and similar in the FAQs, Wiki, etc. , and I was confused. |
| 03:00.37 | starseeker | KimK: BRL-CAD being open source is a relatively recent thing (compared to its overall history) |
| 03:01.25 | starseeker | http://developers.slashdot.org/article.pl?sid=05/01/08/1823248 |
| 03:01.56 | KimK | OK, very good what year did it open? I missed that part. So that text should perhaps read "...in use at over 2,000 sites..."? Oops, I'm typing too slow again, I'll bet you're ahead of me. |
| 03:10.20 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2542 10/wiki/Analysis_Library: analysis library |
| 03:21.04 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2543 10/wiki/Geometry_Conversion_Library: geometry conversion |
| 03:24.16 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2544 10/wiki/Geometry_Conversion_Library: |
| 03:24.51 | brlcad | dli: I saw that, commented right after you left -- that's totally awesome |
| 03:26.08 | brlcad | dli: can you post that patch file to our patches tracker? |
| 03:26.38 | brlcad | https://sourceforge.net/tracker/?func=add&group_id=105292&atid=640804 |
| 03:40.07 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2545 10/wiki/GED_Transactions: GED transactions |
| 04:04.59 | KimK | I tried installing the BRL-CAD .deb (Ubuntu 10.04), Gdebi says I need libncurses5 (>= 5.7+20100313), I have what must be the latest, it is 5.7, but it's 20090803-2ub. Any advice? |
| 04:10.50 | KimK | Go plead my case to the Ubuntu libncurses5 maintainers, I guess? Please post any advice and I'll check back later. Thanks in advance. |
| 04:11.41 | louipc | you sure the deb is appropriate for your distro? |
| 04:13.05 | louipc | as far as I understand debian and ubuntu are not quite interchangable anymore |
| 04:13.53 | dli | brlcad, thanks, still testing it, need to get it work before posting to tracker |
| 04:13.57 | louipc | so you may need to alter some things if you want a debian package to work with ubuntu |
| 04:14.14 | brlcad | dli: ah, thought you already had it finished :) |
| 04:15.20 | dli | brlcad, not yet. still have to test how it work. also, I'm still not sure I can simply keep the 2d vectors |
| 04:15.21 | brlcad | louipc: are you interested in being a gsoc mentor? |
| 04:16.41 | brlcad | ~seen jordisayol |
| 04:16.42 | ibot | brlcad: i haven't seen 'jordisayol' |
| 04:16.47 | louipc | brlcad: I would, but I don't have much free time unfortunately :( |
| 04:18.02 | KimK | louipc: OK, thanks, I had not considered that I might not be able to use a .deb on Ubuntu anymore, I'll look into that. |
| 04:18.17 | louipc | brlcad: Not really sure how I could mentor either since I'm not horribly active in the project :/ |
| 04:18.39 | louipc | KimK: you can use .deb packages, but they should be packaged specifically for Ubuntu |
| 04:19.38 | brlcad | louipc: anyone who has contributed enough to be trusted enough with commit access is eligible, participation is voluntary for everyone |
| 04:20.16 | KimK | louipc: Do you know if there a BRL-CAD developer who packages for ubuntu? Maybe from his own web page or PPA? |
| 04:20.28 | louipc | I could mentor as in "It works" "it doesn't work, fix it" :D |
| 04:20.41 | louipc | KimK: not sure |
| 04:21.03 | KimK | louipc: OK, thanks. |
| 04:21.19 | brlcad | KimK: jordi put together the recent .deb files |
| 04:21.36 | brlcad | ~seen epileg |
| 04:21.37 | ibot | epileg <~epileg@unaffiliated/epileg> was last seen on IRC in channel #brlcad, 2d 13h 6m 39s ago, saying: 'here in spain, exactly same as ``Erik'. |
| 04:21.45 | brlcad | that's him |
| 04:23.34 | brlcad | louipc: good to know -- we have a decent number of "auditing" mentors this year, so just putting out feelers for folks in our community interested in taking on a student |
| 04:23.43 | brlcad | which is generally 10-20 hours a week |
| 04:24.13 | louipc | oh man that would be too much |
| 04:26.08 | brlcad | add's up fast -- just an hour or two a day of discussion on IRC will add up to around that much |
| 04:26.33 | brlcad | but no problem, figured worth asking -- let me know if you change your mind |
| 04:26.58 | louipc | is that like a 3mo gig? |
| 04:27.20 | brlcad | roughly |
| 04:27.59 | brlcad | http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/timeline |
| 04:49.30 | starseeker | brlcad: If I can't get to 40, we may just have to live with it... |
| 04:49.39 | starseeker | I've got to sleep soon, been a long day here |
| 04:49.45 | brlcad | heh, that's great |
| 04:50.07 | brlcad | it's plenty, better to have 30 that are solid than 40 that are all half-arsed |
| 04:50.36 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 04:51.22 | starseeker | I'm at 16 now, and given I need to review them all once more... I'll work it tomorrow morning too, of course |
| 04:51.49 | brlcad | me too, started on the application a while ago |
| 04:52.40 | starseeker | moron former homeowners claimed they didn't need the sump pump, and we didn't have to worry about it |
| 04:52.56 | starseeker | Wrong |
| 04:53.20 | ``Erik | lame |
| 04:53.29 | ``Erik | you're not in a designated flood area, I imagine? |
| 04:53.47 | starseeker | no, but the front half of our home is partially underground |
| 04:53.53 | ``Erik | so'z no flood insurance or anything... |
| 04:54.01 | starseeker | nah, we'll have to eat it |
| 04:54.06 | ``Erik | 4 days of solid rain is weird for md |
| 04:54.11 | brlcad | you also believed them :) |
| 04:54.29 | starseeker | brlcad: Oh, I know - I'm not claiming any medals |
| 04:54.47 | ``Erik | I'm glad mine is a slab, back yard turns to swamp, but no flooding :) |
| 04:54.48 | brlcad | any hole in the ground is subject to water pressure |
| 04:55.25 | starseeker | figured if they had gotten away with it so long, must mean the local lay of the land was such that there wasn't significant water presence |
| 04:55.37 | starseeker | turns out they were just really friggin lucky |
| 04:55.52 | brlcad | or they never went down there ;) |
| 04:56.08 | starseeker | <snort> yeah, that may be too |
| 04:56.35 | starseeker | also, they only added the carpet in 2008 (we found out today) so perhaps they wouldn't have noticed earlier incidents |
| 04:56.44 | brlcad | I'm wanting to dig and install a french drain down mine, plenty of hydrostatic pressure here |
| 04:57.04 | brlcad | really just wants an excuse to buy a jackhammer |
| 04:57.05 | ``Erik | I'm sure you're well above the aquafer and have permeable soil, these last few days have been massive with the consistent rainfall, the soil is all saturating and there's nowhere for it to go... |
| 04:57.10 | starseeker | hehe |
| 04:57.33 | starseeker | ``Erik: yeah, noticed that - grounds as wet as squishy as I can ever remember seeing it here |
| 04:58.11 | starseeker | we may be "lucking out" and getting that right set of circumstances the former owners never happened to get |
| 04:58.14 | ``Erik | um, I kinda got a bit stuck at work... in the grass/mud... with 4wd :D tore up a bit of grass this evening |
| 04:58.25 | starseeker | but still, I should have known better - they didn't add the sump system for nothing |
| 04:58.39 | starseeker | it cost money to add, and lord knows nothing in this place cost more than it had to... |
| 04:58.42 | ``Erik | standing water all along the grass strip there |
| 04:59.13 | starseeker | nods - when I had to park in grass this morning, I didn't even consider going in front first |
| 04:59.48 | ``Erik | was able to get out fine for lunch, it was after another few hours of rain that it just turned to mud |
| 05:00.41 | starseeker | brlcad: you're getting as bad as Bob, considering the relative sizes of your properties - for you a jackhammer would take almost as much relative storage space as Bob's backhoe |
| 05:00.56 | ``Erik | gonna have to wetvac one of the carpet bits, van drug in all sorts of mud O.o |
| 05:01.09 | starseeker | ick |
| 05:01.21 | brlcad | naw, they don't take that much space |
| 05:01.32 | ``Erik | heh, jackhammer would fit down brlcad's suicide hole |
| 05:01.47 | brlcad | that's exactly where I intend to start |
| 05:02.16 | brlcad | if i'm going to install a sauna down there, I want the hydrostatic pressure released |
| 05:03.47 | ``Erik | gym has a sauna, make it a combo wine cellar/humidor :D |
| 05:04.56 | brlcad | it'll have a wine rack, shower, sauna, sink, and toilet; still debating on the hot tub |
| 05:05.03 | ``Erik | or put a rack down there to hang your car |
| 05:05.28 | brlcad | oh I totally thought about installing an elevator to lower my car into "the pit" |
| 05:05.34 | ``Erik | has been wondering about putting in a slab under his deck to put a hot tub on |
| 05:06.16 | brlcad | kind of like these: http://dornob.com/secret-agent-style-stealth-lift-patio-car-elevator/ |
| 05:06.46 | brlcad | ah, right -- this one almost exactly: http://dornob.com/hydraulic-living-room-car-lift-rides-right-into-your-home/ |
| 05:07.29 | ``Erik | just bolt a couple handles on the side and pick it up :D |
| 05:12.23 | ``Erik | brlcad: do you have the gsoc corrospondance concerning 'more detail' available for starseeker? is it volume, or information density? |
| 05:13.02 | brlcad | what? |
| 05:13.05 | ``Erik | (or did everyone get the same 'guidance' to push the mentors?) |
| 05:14.01 | brlcad | oh that was a private conversation directly to me while they were reviewing our application in '09 |
| 05:14.48 | ``Erik | hm, so nothing to help steer starseeker with that olympian task |
| 05:15.22 | brlcad | it's not quite as bad as it sounds, it's not really volume or density, just sufficient variety to attract a wide range of students |
| 05:16.03 | brlcad | what was there for '09 is what we ended up with *after* I expanded the list in response to them saying we need more |
| 05:16.13 | ``Erik | ah, 'k |
| 05:16.14 | brlcad | so that's about par |
| 05:16.17 | starseeker | ah, that's different |
| 05:16.41 | ``Erik | clarification, w00t |
| 05:17.24 | brlcad | it should basically have at least that much detail, but more importantly be clear that there is a wide range of skills and it is easy for -randome_student- to figure out which topics might be of interest at a glance |
| 05:18.43 | ``Erik | also; starseeker has been breaking things down into a heirarchy with links to the meat, are the goog reviewers going to be cool with that, or do they want a single page view? it'd be fairly simple sql to generate a single "big honkin' page", I'd think |
| 05:19.16 | brlcad | they're unlikely to dive deep |
| 05:19.39 | brlcad | they have hundreds of these to go through, they're going to sweep through the site in all of 30 seconds |
| 05:19.52 | starseeker | we can flatten it at the end, if we must - this is a better way for me to keep track of what is and isn't done yet |
| 05:20.32 | brlcad | hence the focus on clarity and organization, dumb simple clear that there's a lot of topics and possibilities |
| 05:20.50 | brlcad | maybe a shallow hierarchy would be a good balance |
| 05:21.15 | brlcad | like grouping each of the major categories all onto one page together |
| 05:21.41 | ``Erik | they already are, under === == = headers, but the task description is a link |
| 05:21.41 | brlcad | then just have to consider what type of variety those top-level categories convey |
| 05:22.35 | brlcad | right but instead of kicking you off to a page with just one topic (which is kinda useful), it'd kick you over to a page for that category with the other dozen ideas in that topic area |
| 05:23.02 | brlcad | so even if they only click one level deep, they get to see that there are lots of project ideas |
| 05:23.47 | brlcad | I'd stick with the one per page and massive top index for now until they're mostly all fleshed out and named in non-brl-cad-technical terms |
| 05:23.54 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2546 10/wiki/Geometry_Selection_Functionality: geometry selection |
| 05:37.57 | brlcad | an iges task would be good |
| 05:38.42 | starseeker | I'll see what I can do - convert iges to spit out openNURBS nurbs? |
| 05:41.27 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2547 10/wiki/Libsvn_within_Geometry_Database_Format: libsvn in .g |
| 05:42.32 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2548 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Tools */ |
| 05:50.03 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2549 10/wiki/IGES_import_improvements: IGES updates |
| 05:50.31 | starseeker | ok, I gotta sleep now |
| 05:51.21 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2550 10/wiki/Talk:Error_Messages: |
| 06:15.39 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:12.18 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 09:43.21 | CIA-14 | BRL-CAD: 03davidloman * r43841 10/geomcore/trunk/src/libNet/Portal.cxx: Cleaned up a bit of messageLen checking logic. twas wrong. |
| 09:46.28 | CIA-14 | BRL-CAD: 03davidloman * r43842 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/ (4 files in 2 dirs): Performing some java<->c/c++ bug troubleshooting. Added the ability to down sample 16bit character strings to 8bit character strings. |
| 10:48.38 | dli | how do I disable -Werror? |
| 10:54.57 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 11:07.18 | dli | src/conv/patch/patch-g.c in 7.18.2 fails with -Werror |
| 13:28.20 | dloman | my prayers to all of you in or have family near the Pacific..... |
| 13:35.08 | dli | dloman, no wonder 'tsunami' is a japanese word. no news of tsunami losses out of japan yet |
| 13:42.06 | starseeker | dli: disable strict |
| 13:44.12 | dli | starseeker, yes, I found out that, but someone may still have to fix patch-g.c |
| 13:44.44 | dli | or it's my compiler, patch-g.c looks alright to me |
| 13:47.08 | starseeker | 7.18.4 should have a lot of strictness fixes |
| 13:49.22 | dli | starseeker, the warning is about uninitilized variables, but it should not happen to me. I will try whether some reorganizing helps the compiler |
| 13:50.22 | starseeker | dli: I'd suggest checking out the lastest subversion trunk and trying that |
| 13:50.46 | dli | starseeker, I will try that |
| 13:57.18 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2551 10/wiki/Space_Partitioning_for_Tessellation: tessellation space paritioning |
| 14:02.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:09.21 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2552 10/wiki/STEP_Libraries: STEP improvements |
| 14:10.44 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2553 10/wiki/STEP_Libraries: |
| 14:21.59 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2554 10/wiki/NURBS_Intersections: surface/surface |
| 14:27.33 | dloman | dli: death toll (worst guess i've read thus far) is at 60 and climbing. |
| 14:27.50 | dloman | based only on the video footage i've seen, that number's going to go waaay up. |
| 14:28.27 | starseeker | it's bad, but fortunately Japan is accustomed to dealing with earthquakes |
| 14:28.53 | dloman | heh, the quake was nothing, its the tsunami that's destroying everything |
| 14:29.03 | starseeker | nods |
| 14:29.27 | starseeker | if large waves hit less prepared areas of the world, the results could get a lot worse |
| 14:30.02 | dloman | reuter's is reporting that country's oil refineries are on fire, most of their nuclear power plants have experienced an emergency shutdown, etc. |
| 14:30.33 | dloman | righto, that's what most people are saying. the warning system has been greatly enhanced since the indonesia disaster in 2004 |
| 14:30.40 | starseeker | nods - 8.9 is a bad earthquake no matter how prepared you are |
| 14:31.25 | dloman | waiting on news from my cuson Josh. he's station at the naval medical hospital in Okinawa |
| 14:31.47 | dloman | heh s/cuson/cousin/ |
| 14:32.02 | starseeker | I imagine he's probably OK |
| 14:32.28 | starseeker | probably rather busy though |
| 14:32.29 | dloman | he is, i'm just wanting to hear it from him, not his Command :) |
| 14:32.35 | starseeker | ah |
| 14:32.50 | dloman | oh yeah, that slacker is going to finally earn his pay :) |
| 14:38.00 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2555 10/wiki/NURBS_Tessellation: nurbs tessellatoin |
| 14:40.12 | dloman | wow.... a whirlpool... http://www.cnn.com/video/#/video/world/2011/03/11/vo.whirlpool.earthquake.nhk?hpt=C2 |
| 14:41.59 | starseeker | grr s/tessellatoin/tessellation |
| 14:54.04 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2556 10/wiki/Generalized_abstracted_spacial_partitioning_capability: abstracted space partitioning |
| 14:56.03 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2557 10/wiki/Google_Summer_of_Code/Project_Ideas: |
| 15:03.39 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2558 10/wiki/Rework_of_libbu/libbn_to_not_require_Tcl: tcl scrubbing |
| 15:13.05 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2559 10/wiki/Complete_bu_image/libicv_and_redo_all_pix_tools_to_use_it: libicv |
| 15:14.23 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2560 10/wiki/Google_Summer_of_Code/Project_Ideas: |
| 15:31.30 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2561 10/wiki/Add_exec_option_to_search: search exec |
| 15:34.13 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2562 10/wiki/Add_exec_option_to_search: |
| 15:34.54 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2563 10/wiki/Add_exec_option_to_search: |
| 15:59.36 | brlcad | dloman: so what would a tsunami feel like from inside a sub near the surface but not on the surface? a can of beans? |
| 16:00.27 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2564 10/wiki/SVG_renderer: vector line rendering |
| 16:00.29 | dloman | probably be a lot of rocking and rolling (angles n dangles) but no real biggy. |
| 16:00.45 | dloman | we were at 100ft under a cat 4 hurricane once |
| 16:00.55 | dloman | was lots of pitching, but thats it. |
| 16:00.59 | brlcad | don't think you could get a barrel roll? |
| 16:01.03 | dloman | heh |
| 16:01.24 | dloman | nuclear sub does a barrel roll and you'd have a pretty sizeable nuclear accident :) |
| 16:02.04 | ``Erik | http://seemslegit.com/_images/61b896b4384935498227a03c54b85370/93%20-%20barrel-roll%20ship.jpg |
| 16:03.32 | dloman | not loading for me :/ |
| 16:03.38 | dloman | but I think i have seen that one before. |
| 16:03.51 | ``Erik | cargo ship heeling at 80 or so? |
| 16:03.59 | dloman | ya |
| 16:05.32 | dloman | but on the note of nuclear accidents, seems Japan is going to have one of those too :/ |
| 16:05.54 | dloman | once of their plants scrammed out and they can't get emergency cooling established to the core :( |
| 16:06.18 | brlcad | "shut it off! SHUT IT OFF!" |
| 16:06.25 | dloman | =D |
| 16:06.27 | brlcad | fuck, RUN! |
| 16:06.48 | starseeker | that's Not Good |
| 16:07.02 | dloman | Yeah, they learned something from the chernobyl plants :) |
| 16:07.13 | starseeker | I thought modern plants were supposed to fail safe |
| 16:07.19 | brlcad | dli: curious, now have two impls that are nearly identical but with interesting differences |
| 16:07.27 | dloman | "Whats that big red light and that alarm for?" "Nothing, just keep on with the test" |
| 16:07.46 | dloman | it is 'safe' from a meltdown standpoint. |
| 16:08.03 | dloman | pressurized water reactors shut themselves down on high temp |
| 16:08.30 | starseeker | so what's the accident part? ruin all the core machinery? |
| 16:08.42 | dloman | but the byproducts of the fission process are always activated and have to shed their energy |
| 16:08.54 | dloman | so even a shutdown core will generate heat for weeks. |
| 16:09.16 | brlcad | weenie roast party! |
| 16:09.23 | dloman | run a core at 100% for a few months then scram it and you will see about 7% heat generation for a few hours. |
| 16:10.07 | dloman | that 7% decays to 0% (aka heat gen is < than the losses to ambient) in usually about 15-21 days. |
| 16:10.18 | dloman | the entire time, however, you must provide heat removal |
| 16:10.32 | dloman | which is the problem the Japanese plan is having. |
| 16:10.50 | dloman | the tsunami flooded a lot of their facilities and messed up a bunch of equipment |
| 16:11.05 | dloman | so they are having trouble removing the decay heat. |
| 16:11.54 | dloman | which, if let go unchecked, could reach a high enough temperature to start melting some of the cladding around the fuel rods, thus releasing activated fission products into the coolant. |
| 16:12.00 | ``Erik | read that most of japan's nukes went emergency shutdown and oil refineries are on fire |
| 16:12.07 | dloman | still contained, but a naaaaaaaaaasty cleanup. |
| 16:12.49 | dloman | however, if the tsunami has damaged any of the coolant piping, that nasty stuff could get out.... |
| 16:13.42 | dloman | But, unles they build 'em stupid over there in Japan (not likely) there is usually a backup to the backup to the backup |
| 16:14.11 | dloman | and if their emergency cooling system has failed, then they will prbably fallback on the emergency emergency cooling system :) |
| 16:15.50 | dloman | </AccidentialNukeTheoryClass> ...sorry |
| 16:16.36 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2565 10/wiki/NMG_Raytracing_Performance_Improvement: nmg raytrace performance |
| 16:17.39 | starseeker | hopes they get it handled, and not just for their sake - last thing the world needs is another reason to be skittish about nuclear power |
| 16:18.40 | starseeker | crap - sounds like that death toll from Japan is going to get a lot higher |
| 16:18.50 | dloman | seen the videos on cnn ? |
| 16:19.04 | CIA-14 | BRL-CAD: 03brlcad * r43843 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: apply an initial (reportedly non-working) version of rt_revolve_xform() from dli |
| 16:19.11 | dloman | i watched over 20 cars get swallowed by water.... its going to be really bad |
| 16:21.08 | starseeker | good god - what IS that whirlpool from? |
| 16:21.24 | dloman | dunno, but it stops toward the end. really wierd. |
| 16:21.48 | ``Erik | small fissure opening up? tsunami water draining strangely? |
| 16:21.55 | dloman | http://www.myvisitingcard.com/2011/onagawa-fire-broke-out-declared-nuclear-power-emergency-situation.html |
| 16:22.18 | starseeker | wondered if it was some subterranian crack in the sea floor... |
| 16:22.37 | dloman | Dr evil's secret lair flooded? |
| 16:22.42 | CIA-14 | BRL-CAD: 03brlcad * r43844 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: move up in order to compare patch |
| 16:24.00 | starseeker | dloman: what's a "nuclear emergency situation"? |
| 16:24.10 | dloman | intentionally vauge |
| 16:24.15 | dloman | =D |
| 16:24.19 | starseeker | humph |
| 16:24.30 | dloman | the article states that they 'cooling the reactor is not going as planned' |
| 16:24.49 | dloman | which means they got th reactors safelt shutdown, but are having issues mantaining cooling to the core. |
| 16:25.00 | dloman | to remove the above mentioned 'decay' heat |
| 16:26.05 | dloman | push comes to shove, the did just have a tsunami, so they have plenty of water to use for cooling. :/ |
| 16:35.07 | CIA-14 | BRL-CAD: 03brlcad * r43845 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: |
| 16:35.07 | CIA-14 | BRL-CAD: and then merge in his version that reportedly works with a couple changes. we |
| 16:35.07 | CIA-14 | BRL-CAD: do need a copy of the bu_vls, so init and cat accordingly. skt was apparently a |
| 16:35.07 | CIA-14 | BRL-CAD: typo and MAT4X3VEC instead of MAT4X3PNT is probably what got it working. |
| 16:35.38 | dloman | ah, looks like the waves have finally reached cali |
| 16:38.22 | CIA-14 | BRL-CAD: 03brlcad * r43846 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: doxygen + ws |
| 16:39.54 | CIA-14 | BRL-CAD: 03brlcad * r43847 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: eip/eop was specific to extrude. use rip/rop for revolve. |
| 16:40.49 | CIA-14 | BRL-CAD: 03brlcad * r43848 10/brlcad/trunk/src/librt/primitives/table.c: dli implemented rt_revolve_xform and it compiles, so turn it on for testing |
| 16:42.48 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2566 10/wiki/Plate_Mode_NURBS_raytracing: plate mode NURBS |
| 16:44.00 | starseeker | Just under 20 to go |
| 16:45.23 | CIA-14 | BRL-CAD: 03brlcad * r43849 10/brlcad/trunk/ (AUTHORS NEWS): Dongxu Li implemented support for applying matrix transformations (scale, translate, rotate) to the revolve primitive. promote him up from the special thanks section to being recognized as a code contributor. |
| 16:45.47 | brlcad | kicks off a final release build while he works on the gsoc application |
| 16:48.11 | brlcad | really curious to know whether the the libbu mmap bug affects other tools on windows |
| 16:51.48 | CIA-14 | BRL-CAD: 03brlcad * r43850 10/brlcad/trunk/NEWS: (log message trimmed) |
| 16:51.48 | CIA-14 | BRL-CAD: cliff and I apparently (hopefully) squished the 'red' command bug where it |
| 16:51.48 | CIA-14 | BRL-CAD: wasn't working on windows. the problem was two-fold. the regex code wasn't |
| 16:51.48 | CIA-14 | BRL-CAD: breaking on newlines and (apparently) libbu's mapped_file fallback support had |
| 16:51.49 | CIA-14 | BRL-CAD: an off-by-one error where it wasn't terminating the mapped file with a zero |
| 16:51.49 | CIA-14 | BRL-CAD: byte. that was causing regex to scan beyond the buffer extent. that issue very |
| 16:51.49 | CIA-14 | BRL-CAD: likely affects other tools and interfaces that use our mapped file support on |
| 16:51.55 | brlcad | amazing, went from being a tiny patch release to looking more and more like a full minor update |
| 16:55.46 | brlcad | ``Erik: you have any gimp skill? need a small image to represent the TIE BoT enhancement (max 256x256) |
| 16:57.34 | brlcad | was thinking maybe a two 128x128 images in opposite corners of the 256x256 space, one partially rendered 20%, the other at 100%, with text above/below each respectively saying old mesh rendering and new approach |
| 16:58.11 | brlcad | or maybe a new validation image of the truck showing the pixdiff differences, scaled down |
| 16:58.20 | brlcad | (or rendered at that size even better) |
| 17:10.15 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2567 10/wiki/CSG_to_NURBS_conversion: finish up CSG->Brep |
| 18:01.24 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2568 10/wiki/Google_Summer_of_Code/Project_Ideas: Remove a few entries - getting down to the wire |
| 18:26.06 | ``Erik | nope, no gimp skill at all, I can click on 'script-fu' and click 'scale', that's about it |
| 18:26.18 | ``Erik | starseeker: vic reports red is not working on mac |
| 18:26.35 | ``Erik | a very recent change broke it |
| 18:54.27 | brlcad | probably the regexes |
| 18:55.21 | brlcad | will look after the application is done |
| 19:27.03 | ``Erik | hm, too late for new ideas for gsoc? |
| 19:28.18 | ``Erik | "voxelize", like facetize, to spew out a big honkin' union of arb8's, mebbe using the marching cubes grid stuff... to feed cfd's and stuff |
| 19:31.09 | starseeker | ``Erik: not too late if you want to add it |
| 19:31.43 | starseeker | had to take down some stuff in his house - I'll try to get a couple more done.. |
| 19:32.15 | starseeker | still got work going on - drywall out everywhere... |
| 19:33.20 | dloman | ever find that leak? |
| 19:33.39 | starseeker | dloman: it was the friggin sump pump (or rather, lack thereof) |
| 19:33.48 | dloman | broke or missing? |
| 19:33.54 | starseeker | previous homeowners assured us they'd never needed it (they took it out) |
| 19:34.02 | starseeker | we though "well, OK..." |
| 19:34.06 | starseeker | oops |
| 19:34.11 | dloman | oh man..... |
| 19:34.20 | starseeker | one of my more expensive mistakes |
| 19:34.24 | dloman | i thought it was regulation to have one? |
| 19:34.31 | starseeker | ? |
| 19:34.33 | starseeker | dunno |
| 19:34.52 | dloman | looking to build my next house, so i have a reg book at home. I'll check :) |
| 19:34.57 | dloman | SUE THEM!!!! |
| 19:34.59 | dloman | j/k |
| 19:35.19 | dloman | is the piping/wiring to a sump pump still in place? |
| 19:35.38 | starseeker | <snort> I doubt it's "on the books" - we asked about it durning the home buying process, and one of the pros would have said something if it was actually required... |
| 19:36.06 | starseeker | dloman: sure - there's a sump, an outside pipe and an outlet. They just took out the indoor pipe and pump and turned it into a closet |
| 19:36.45 | starseeker | now that I've got the mirror wall off the staircase, there's a much bigger mold spot |
| 19:37.01 | starseeker | too high for recent activity, so looks like the pipe to the faucet outside may be having issues |
| 19:37.11 | dloman | oh hell.... mold... im so sorry man :( |
| 19:40.26 | starseeker | they cut out like four feet of drywall and sprayed some stuff, so the mold is gone, but we look like a home rennovation show down there |
| 19:42.21 | CIA-14 | BRL-CAD: 03Erik 07http://brlcad.org * r2569 10/wiki/Google_Summer_of_Code/Project_Ideas: /* BRL-CAD Core Library Enhancement */ |
| 19:45.47 | ``Erik | what was the name of that thing mike did? uh, qubit or something? |
| 19:45.58 | starseeker | cubit |
| 19:46.22 | starseeker | http://cubit.sandia.gov/ |
| 19:46.41 | starseeker | was never much interested in it, as it's not open source |
| 19:47.00 | starseeker | (at least, the interesting parts related to mesh generation don't seem to be) |
| 19:47.30 | brlcad | ``Erik: I need your link_id not your google id this year |
| 19:48.06 | brlcad | dloman: did you see my message about a poster? :) |
| 19:48.20 | dloman | message? |
| 19:48.22 | dloman | negative |
| 19:49.18 | brlcad | we're going to need another gsoc poster this year, it's a chance to take some creative artistic liberty and make a neat page enticing students to apply |
| 19:49.37 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2570 10/wiki/Material_and_Shader_Objects: material and shader objects |
| 19:49.38 | brlcad | you'd be perfect for that, as shown by other graphics you've worked on of late ;) |
| 19:49.41 | CIA-14 | BRL-CAD: 03Erik 07http://brlcad.org * r2571 10/wiki/Voxelize: New page: Voxel data sets are commonly used in computational fluid dynamic simulations. The current technique for creating voxels from BRL-CAD geometry is to use the proprietary cubit framework. Th... |
| 19:49.42 | dloman | where was the message? Or was that it? |
| 19:49.47 | starseeker | and you don't want me doing it :-P (see archer icons) |
| 19:50.09 | dloman | yeah, starseeker MS paint isnt that great of an editor :P |
| 19:50.25 | brlcad | you can see the previous two years posters by me and cliff at http://brlcad.org/wiki/Google_Summer_of_Code#BRL-CAD_participation_in_GSoC |
| 19:50.49 | starseeker | <snort> Gimp + inkscape + http://www.openclipart.org/ baby |
| 19:51.17 | brlcad | cool, the initial submission is DONE |
| 19:51.22 | brlcad | now to tweak |
| 19:51.24 | starseeker | awesome |
| 19:52.41 | starseeker | ``Erik: any of the existing ones you want to fill in? (shader enhancements might be a good one, you have more knowledge about 'em than I do) |
| 19:52.47 | ``Erik | huzzah, a menu items appear, it is effective! |
| 19:53.47 | ``Erik | nah, starseeker, I'm good :D (not sure what the shader thing is about) |
| 19:58.12 | CIA-14 | BRL-CAD: 03Erik 07http://brlcad.org * r2572 10/wiki/GUI_Animation_editor/creator: New page: Creating animations using BRL-CAD is currently a very manual and tricky process. A GUI editor to create Bezier splines for moving objects, lights and the camera and generating rt scripts a... |
| 19:58.39 | starseeker | ``Erik: I was thinking investigate Open Shader Language and how we can benefit from it |
| 19:58.46 | starseeker | maybe too vague for a gsoc project though |
| 19:58.51 | CIA-14 | BRL-CAD: 03Erik 07http://brlcad.org * r2573 10/wiki/GUI_Animation_editor/creator: |
| 19:59.08 | ``Erik | I dunno the open shader language... similiar to renderman? |
| 19:59.16 | starseeker | yeah... |
| 19:59.18 | starseeker | <PROTECTED> |
| 19:59.33 | starseeker | http://opensource.imageworks.com/?p=osl |
| 19:59.40 | starseeker | was a big thing at siggraph |
| 19:59.57 | brlcad | mm, shader objects |
| 20:00.21 | starseeker | brlcad: did I miff that one? |
| 20:00.27 | starseeker | may be typing too fast here... |
| 20:00.41 | brlcad | I haven't read any of them yet, delegation my dear watson |
| 20:00.45 | brlcad | taking a lot of time just to prep the app |
| 20:00.49 | starseeker | nods |
| 20:01.00 | brlcad | it's in, but I still have at least an hour of editing and re-reviewing to go |
| 20:01.04 | starseeker | got it |
| 20:01.18 | brlcad | leaving it all on you guys :) |
| 20:01.23 | starseeker | well, if it gets buy gsoc review we can polish it later |
| 20:01.27 | CIA-14 | BRL-CAD: 03jordisayol * r43851 10/brlcad/trunk/sh/ (make_deb.sh make_rpm.sh): modify deb/rpm building packages dependencies |
| 20:06.03 | dloman | brlcad: when u need the poster by? |
| 20:06.46 | brlcad | whenever it's ready really |
| 20:06.53 | ``Erik | yesterday morning |
| 20:06.59 | CIA-14 | BRL-CAD: 03Erik 07http://brlcad.org * r2574 10/wiki/Shader_Enhancements: New page: Shaders for the ray-tracer are currently coded in C and explicitly added to the active shader list. A shader to bridge the RT shader system to the BSD licensed implementation of OSL ( [htt... |
| 20:07.18 | brlcad | if you want to make sure you don't waste time, then as soon as org applications are approved |
| 20:07.29 | starseeker | ``Erik: heh, beat me too it - thanks! |
| 20:07.39 | brlcad | since ours has a high chance of acceptance, then anytime really |
| 20:07.40 | ``Erik | probably needs cleanup/editing anyways |
| 20:07.58 | ``Erik | I'm just spewing out rough draft quality stuff here... :D |
| 20:08.22 | starseeker | checks... |
| 20:08.28 | starseeker | ``Erik: you think I'm not? |
| 20:08.35 | starseeker | I tend to ramble in the best of times |
| 20:08.40 | starseeker | writing fast makes it worse |
| 20:10.14 | CIA-14 | BRL-CAD: 03Erik 07http://brlcad.org * r2575 10/wiki/General_Tree_Walker: New page: There are currently several slightly different functions to recursively walk the CSG tree. This task would be to implement a new tree walking function capable of replacing them all and alt... |
| 20:12.22 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2576 10/wiki/Shader_Enhancements: Tweak shader enhancements entry |
| 20:13.19 | starseeker | hits blender-g |
| 20:16.09 | brlcad | should probably be blend-g ;) |
| 20:16.17 | starseeker | er, right |
| 20:16.35 | starseeker | heh - blender-g, toaster-g, eggbeater-g... |
| 20:16.35 | brlcad | remember to try and avoid brl-cad specific conventions at least in the project titles and initial sentance descriptions |
| 20:16.54 | CIA-14 | BRL-CAD: 03Erik 07http://brlcad.org * r2577 10/wiki/Converter_completion_so_all_current_formats_have_both_import_and_export: New page: BRL-CAD implements numerous importers and exporters for a wide variety for formats, but not every format has both an importer and an exporter. An old list is available in the repository [h... |
| 20:17.05 | brlcad | it should be worded as if BRL-CAD did not exist (e.g., "Blender geometry importer") |
| 20:17.15 | starseeker | brlcad: I'll try to make a pass and eliminate as much of that as I can... |
| 20:17.22 | brlcad | then can go into detail on the specific page |
| 20:17.27 | ``Erik | next time I make a disposable geometry format, I am so calling it spatula. |
| 20:17.57 | brlcad | really liked avoCADo :) |
| 20:18.17 | brlcad | (dead for 3 years now) |
| 20:18.36 | starseeker | is it on sourceforge? we could try a takeover :-P |
| 20:18.37 | brlcad | there's some nurbs code you could look into snarfing starseeker |
| 20:18.44 | starseeker | what license? |
| 20:18.55 | brlcad | sourceforge project name sucks -- "avocado-cad" |
| 20:19.21 | brlcad | ah right, gpl |
| 20:19.26 | brlcad | bleh |
| 20:19.46 | starseeker | there are least two other nurbs libs I'm aware of that are will remaing GPL |
| 20:19.49 | starseeker | very frustrating |
| 20:19.56 | starseeker | (especially SISL...) |
| 20:21.10 | brlcad | dloman: the only stipulation is that the poster should be predominantly made with brl-cad imagery ;) |
| 20:21.17 | brlcad | which shouldn't be hard for you of all people |
| 20:25.04 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2578 10/wiki/Blender-g_importer: blend-g |
| 20:28.11 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[SVG renderer]] moved to [[Vector output from raytracing]]: retitle |
| 20:29.28 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Blender-g importer]] moved to [[Blender file format converter]]: retitle |
| 20:29.38 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2583 10/wiki/Google_Summer_of_Code/Project_Ideas: |
| 20:30.24 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2584 10/wiki/General_Tree_Walker: |
| 20:37.42 | *** join/#brlcad Stattrav (~Stattrav@117.192.148.157) | |
| 20:37.43 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:49.05 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2585 10/wiki/Overlap_tool: overlap tool |
| 20:52.23 | CIA-14 | BRL-CAD: 03jordisayol * r43852 10/brlcad/trunk/ (misc/debian/rules sh/make_deb.sh sh/make_rpm.sh): update "make" simultaneous jobs, during deb/rpm building process |
| 20:52.29 | ``Erik | pics http://www.theatlantic.com/infocus/2011/03/earthquake-in-japan/100022/ |
| 20:53.10 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2586 10/wiki/Automated_exploded_view_tool: exploded view |
| 20:53.46 | brlcad | i guess it did happen |
| 20:58.49 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2587 10/wiki/Automated_cutaway_view_tool: cutaway view |
| 20:59.52 | starseeker | pants - thanks ``Erik for the assist |
| 20:59.56 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2588 10/wiki/Google_Summer_of_Code/Project_Ideas: remove stray links |
| 21:01.36 | starseeker | just before 4pm EST |
| 21:02.13 | starseeker | now has to head in - ``Erik if you want to flatten the page in some way shape or form you're welcome |
| 21:02.45 | brlcad | thanks starseeker, tis great rogress |
| 21:05.23 | starseeker | brlcad: your welcome, my pleasure - we'll hope it's enough |
| 21:11.20 | ``Erik | http://www.youtube.com/watch?v=vs2l38DoqsQ |
| 22:41.30 | brlcad | dloman: do you have a link_id? |
| 22:45.34 | CIA-14 | BRL-CAD: 03128.63.32.5 07http://brlcad.org * r2589 10/wiki/Google_Summer_of_Code/Project_Ideas: stray text |
| 22:57.18 | starseeker | hmm: http://www.nasa.gov/open/source/ |
| 23:00.08 | brlcad | adds the final finishing touches |
| 23:03.31 | CIA-14 | BRL-CAD: 03starseeker * r43853 10/brlcad/branches/cmake/ (8 files in 6 dirs): MFC r43852 |
| 23:03.44 | starseeker | wonders if he can attend a two day virtual conference... |
| 23:06.56 | brlcad | that's probably the best-worded GSoC application to date |
| 23:07.20 | brlcad | invariably reorganize every time, clean up the organization and writeup structure |
| 23:07.29 | starseeker | cool :-) |
| 23:09.18 | starseeker | yeow, what the heck... |
| 23:09.29 | brlcad | 430 orgs applied |
| 23:09.34 | starseeker | rebuilds clean - hopefully this is just a messed up build... |
| 23:09.44 | starseeker | brlcad: is that more than last year? |
| 23:09.54 | brlcad | yeah |
| 23:10.04 | brlcad | but then org acceptance has increased every year too |
| 23:10.19 | starseeker | how long typically before we find out? |
| 23:12.01 | brlcad | http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/timeline |
| 23:12.19 | starseeker | ah, right |
| 23:12.33 | brlcad | ~gsoc |
| 23:12.33 | ibot | gsoc is probably the Google Summer of Code, a program run annually by Google to provide (paid for) jobs to students to code on open source projects over summer. See http://code.google.com/soc/ for details. |
| 23:12.46 | brlcad | ~timeline |
| 23:13.15 | brlcad | ~timeline is the GSoC 2011 timeline is at http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2011/timeline |
| 23:13.15 | ibot | okay, brlcad |
| 23:20.43 | starseeker | interesting... red works on my Mac |
| 23:20.53 | starseeker | let's try with system regex |
| 23:21.26 | brlcad | that is interesting |
| 23:21.39 | brlcad | he wouldn't have likely compiled with system regex on mac |
| 23:21.44 | brlcad | because of system tcl/tk |
| 23:21.54 | brlcad | unless he specifically turned on system regex |
| 23:22.25 | starseeker | that's cmake build... suppose I should try autotools |
| 23:22.58 | brlcad | at least, auto doesn't work on 10.6 because system tcl IS a compatible .6, but mged/libdm crashes trying to make X11 calls |
| 23:24.35 | starseeker | ah... in principle, the CMake FindTCL should spot that system Tcl/Tk isn't X11 - will have to try that out |
| 23:28.03 | starseeker | may have to ask him more specifically what failed |
| 23:28.24 | brlcad | technically, configure is checking correctly |
| 23:28.27 | brlcad | our code is wrong |
| 23:30.08 | brlcad | hopes for an ogre/qt dm project |
| 23:30.35 | starseeker | That'd be awesome |
| 23:31.43 | starseeker | no, system regex worked too |
| 23:32.02 | starseeker | wonder if his build got into a weird state - I had to flush my cmake build and redo |
| 23:32.28 | starseeker | will check with him on Monday, assuming he doesn't have to be home for more contractor fun |
| 23:52.51 | dli | starseeker, how big is the whole svn repository? it has been downloading for two hours |
| 23:52.58 | starseeker | uh oh |
| 23:53.09 | starseeker | dli: you don't want the whole thing |
| 23:53.31 | starseeker | try svn co https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/trunk brlcad-svn |
| 23:55.21 | dli | starseeker, oh, I only put https://brlcad.svn.sf.net/svnroot/brlcad/ there :( my bad |
| 23:55.33 | starseeker | ouch |
| 23:55.48 | starseeker | yeah, that'll pull all tags, all branches, all of everything |
| 23:56.46 | starseeker | I'll generally use the svn browse functionality to check the structure of a repository prior to downloading |
| 23:59.59 | dli | starseeker, I'm putting this together for a gentoo ebuild:( |
| 00:00.36 | starseeker | I thought there was a gentoo ebuild? |
| 00:00.42 | brlcad | dli: hehehe, yeah... you definitely don't want the whole thing |
| 00:01.13 | dli | starseeker, I think I had been updating the one on gentoo bugs for years :( |
| 00:01.23 | starseeker | ah |
| 00:01.30 | brlcad | dli: you've seen http://packages.gentoo.org/package/sci-misc/brlcad yes? |
| 00:01.45 | brlcad | bicatali is looking for a maintainer |
| 00:02.10 | dli | brlcad, 7.16.8, I should submit an updated copy to gentoo BTS |
| 00:02.25 | brlcad | you should become a gentoo dev ;) |
| 00:02.30 | brlcad | then just update it yourself |
| 00:02.39 | brlcad | process isn't too complex |
| 00:02.44 | dli | brlcad, but I switched to archlinux long ago :( |
| 00:02.52 | brlcad | ah, heh |
| 00:03.25 | dli | brlcad, just still got a gentoo leftover in house, a thinkpad with broken video card. so I playing the ebuild there |
| 00:05.20 | dli | brlcad, still I will try to maintain brlcad on gentoo :( helping brlcad on archlinux as well |
| 00:06.37 | brlcad | I used to notify an archlinux maintainer, but after a couple years of failing to update, I removed them from our notification list |
| 00:07.20 | brlcad | hm, hadn't seen this http://aur.archlinux.org/packages.php?ID=8320 |
| 00:08.04 | brlcad | looks like it's not too far out of date any longer, or perhaps I'm thinking of a different distro |
| 00:08.35 | dli | brlcad, yes, they got 7.18.0, and the PKGBUILD works for 7.18.2, which I'm using |
| 00:09.03 | brlcad | starseeker: http://download.rhino3d.com/openNURBS/5.0/release/download/ |
| 00:09.12 | brlcad | louipc hangs out here |
| 00:10.35 | CIA-14 | BRL-CAD: 03brlcad * r43854 10/brlcad/trunk/TODO: update to openNURBS 5.0 |
| 00:13.13 | starseeker | brlcad: I know - haven't had the time to merge and test in BRL-CAD yet |
| 00:14.22 | starseeker | think I got most of the changes that still need applying sorted in the libnurbs project, but not completely sure yet and didn't want to bugger anything up |
| 00:50.31 | starseeker | ``Erik: hmm |
| 00:50.34 | starseeker | Program received signal EXC_BAD_ACCESS, Could not access memory. |
| 00:50.34 | starseeker | Reason: KERN_PROTECTION_FAILURE at address: 0x00006f28 |
| 00:50.37 | starseeker | 0x00186010 in Logger::instance () |
| 00:50.45 | starseeker | (running gsTest on a mac) |
| 00:55.27 | brlcad | nods -- I recalled you mentioning it, I was just reminded when I got their newsletter update |
| 00:55.47 | starseeker | ah, cool |
| 00:57.57 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2590 10/wiki/Google_Summer_of_Code: emphasize checklist |
| 00:57.57 | dli | starseeker, so it says more than 'segfault' on mac? |
| 00:58.32 | starseeker | hmm? what does? |
| 00:58.45 | starseeker | oh - that's the gdb message |
| 00:58.53 | dli | starseeker, I see |
| 00:58.58 | louipc | brlcad: Hah I haven't been that negligent. You must be thinking of another distro |
| 00:59.17 | brlcad | louipc: yeah, probably |
| 00:59.23 | louipc | I couldn't get 7.18.2 to build last time I tried, so I haven't updated the archlinux build |
| 00:59.24 | dli | louipc, so, you do archlinux? |
| 00:59.30 | louipc | yep |
| 00:59.33 | brlcad | really? that's odd |
| 00:59.34 | starseeker | aaaaa, poop. the openmoko on ebay (with developer board and accessories, mind you) went for $74 |
| 00:59.44 | brlcad | louipc: I suspect you need --disable-strict |
| 00:59.46 | louipc | didn't have a chance to investigate |
| 00:59.50 | starseeker | got distracted by house |
| 00:59.54 | dli | louipc, I just copied 7.18.0 PKGBUILD, and it builds for me with 7.18.2 |
| 01:00.14 | louipc | brlcad: yeah that's probably what it is, it was also failing in svn for a little while after release |
| 01:01.04 | dli | louipc, http://paste.pocoo.org/show/352245/ |
| 01:01.34 | starseeker | http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=110656800112 |
| 01:01.36 | louipc | dli: ah yeah disable strict |
| 01:02.08 | louipc | will there be a new release soon? |
| 01:11.39 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2591 10/wiki/Google_Summer_of_Code: simplify, move application details to the guidelines page |
| 01:19.26 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2592 10/wiki/Google_Summer_of_Code/Application_Guidelines: move info from main intro page to here for applicants |
| 01:21.21 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2593 10/wiki/Google_Summer_of_Code: /* Preparing an application */ |
| 01:29.23 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2594 10/wiki/Google_Summer_of_Code: gsoc is not a job |
| 01:30.11 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2595 10/wiki/Google_Summer_of_Code: retitle |
| 01:31.36 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2596 10/wiki/Google_Summer_of_Code: sublisted |
| 01:31.47 | brlcad | louipc: yeah, we just passed all tests -- tarball possible later tonight |
| 01:32.52 | starseeker | ``Erik: hmm, traditionally our build system is BSD licensed, not LGPL - looks like I need to fix geomcore headers for CMakeLists.txt files |
| 01:33.23 | starseeker | things we should also have a simple Geometry Service client that is BSD licensed to make it easier for people to build clients... |
| 01:33.30 | starseeker | s/things/thinks |
| 01:33.56 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2597 10/wiki/Google_Summer_of_Code/Checklist: link back to parent |
| 01:34.46 | brlcad | http://brlcad.org/d/node/85 |
| 01:35.31 | *** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 under way (20110311) || BRL-CAD applying to participate in GSoC 2011! http://brlcad.org/d/node/85 | |
| 01:41.42 | *** join/#brlcad waprat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 01:43.52 | louipc | woo! |
| 02:20.53 | CIA-14 | BRL-CAD: 03starseeker * r43855 10/geomcore/trunk/ (7 files in 3 dirs): |
| 02:20.53 | CIA-14 | BRL-CAD: Set up the support structure for a basic GS client that is independent from the |
| 02:20.53 | CIA-14 | BRL-CAD: rest of geomcore, but still built as part of the geomcore build. In essence, |
| 02:20.53 | CIA-14 | BRL-CAD: it's a src/other style build but with our own code. No functionality yet. |
| 02:22.33 | starseeker | well, now that I'm set up to build a tool that knows nothing but the GS protocol docs I guess I'd better figure out how to write it |
| 02:22.47 | starseeker | forsees a busy week |
| 04:28.24 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 04:39.37 | CIA-14 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2598 10/wiki/Contributor_Quickies: Sean stomped the strict compiler warnings |
| 06:06.27 | *** join/#brlcad Stattrav (~Stattrav@122.172.156.61) | |
| 06:06.27 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:25.15 | brlcad | interesting rant by bryan bishop on the openmanufacturing group |
| 06:25.25 | brlcad | starts packing |
| 06:27.33 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 06:27.51 | brlcad | howdy kink |
| 06:27.54 | brlcad | er, kimk |
| 06:28.05 | KimK | Hi |
| 06:28.41 | KimK | I haven't done anything about installing brlcad yet, but still hope to |
| 06:29.02 | brlcad | nods |
| 06:30.10 | KimK | I'm hoping to gently request that the Ubuntu maintainer of (whatever it was) update his 2009 install. |
| 06:30.42 | KimK | Because that would be the easiest thing from *my* point of view, lol! |
| 06:31.01 | brlcad | usually can't hurt |
| 06:32.05 | KimK | Ha, I feel bad about that: (1) I have a problem (2) somebody else fixes problem (3) No problem! |
| 06:32.39 | KimK | Oh, well. |
| 06:33.26 | KimK | Anyway, hope you don't mind if I hang around. I'm not usually this noisy. |
| 07:04.43 | *** join/#brlcad Stattrav (~Stattrav@122.172.156.61) | |
| 07:04.43 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:17.31 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 13:08.24 | *** join/#brlcad Stattrav (~Stattrav@117.192.156.73) | |
| 13:08.24 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:23.43 | starseeker | Huh - the CIA bot came from picogui originally? |
| 15:17.19 | brlcad | not really |
| 15:17.22 | brlcad | but the same author |
| 15:17.28 | starseeker | cool |
| 15:17.54 | brlcad | KimK: you can hang around any time, that's not noisy ;) |
| 15:18.07 | starseeker | brlcad: thanks for mentioning that Bryan Bishop posting |
| 15:18.53 | brlcad | he's not been in here in a while |
| 15:19.11 | brlcad | but I certainly liked the sound of capable dev interest ;) |
| 15:19.17 | starseeker | dangled a lure to see if he can interest them in working to enhance openNURBS instead of doing Yet Another Small Cad Kernel... |
| 15:20.00 | brlcad | suspects nurbs is but a tiny part of what they care about |
| 15:20.17 | starseeker | oh, probably, but worst case they ignore me :-) |
| 15:23.17 | starseeker | his post mentioned specifically "a need for more mathematical geometry work |
| 15:23.20 | starseeker | before all standard NURBS manipulation routines are finished" |
| 16:39.37 | *** join/#brlcad Stattrav (~Stattrav@117.202.19.158) | |
| 16:39.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:46.15 | *** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net) | |
| 19:33.58 | *** join/#brlcad piksi (~piksi@pi-xi.net) | |
| 00:49.48 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 03:47.15 | starseeker | hah - SISL modernized their build with CMake |
| 03:47.24 | starseeker | and doxygen |
| 03:47.27 | starseeker | cool |
| 03:49.47 | starseeker | still GPL though |
| 03:51.08 | dli | starseeker, I try to clean up the strict-build problems, seems to be caused by tcl |
| 03:51.34 | starseeker | dli: uh... we shouldn't be trying to build Tcl with strict flags |
| 03:52.18 | dli | starseeker, or, should we clean up the code, and let tcl to handle the 32bit/64bit problem |
| 03:53.09 | starseeker | dli: you can try making patches to Tcl/Tk if you're finding problems and send them back to them... |
| 03:53.21 | starseeker | or try the 8.6 branch of the code |
| 03:54.24 | dli | starseeker, I need tcl-8.6 first then |
| 03:54.58 | dli | starseeker, 8.5.9 is what in gentoo |
| 03:55.04 | starseeker | right |
| 03:55.19 | dli | starseeker, the same 8.5.9 in archlinux |
| 03:55.39 | starseeker | yeah, 8.6 is still in development - has been for quite a while |
| 03:55.49 | starseeker | has to run... |
| 03:56.28 | dli | :) |
| 04:49.49 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 06:40.48 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 08:03.17 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 10:45.20 | *** join/#brlcad piksi (~piksi@pi-xi.net) | |
| 14:46.55 | *** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net) | |
| 16:17.30 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.236) | |
| 16:17.30 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:26.36 | *** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net) | |
| 16:27.32 | dli | from trunk: I got ditsplitc.c:(.text+0x301): undefined reference to `sincos' |
| 16:27.37 | dli | -lm ? |
| 16:36.39 | dli | Makefile:LIBM = |
| 16:36.42 | dli | that's why |
| 16:54.51 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.140.54) | |
| 19:07.39 | CIA-14 | BRL-CAD: 03starseeker * r43856 10/geomcore/trunk/src/GS/testclient/ (CMakeLists.txt gstestclient.c): It's a bit confusing. Trying to send the simplest thing possible to the server, and it's getting SOMETHING, but doesn't recognize it. |
| 20:19.08 | *** join/#brlcad Stattrav (~Stattrav@117.192.140.54) | |
| 20:19.08 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:31.57 | CIA-14 | BRL-CAD: 03starseeker * r43857 10/geomcore/trunk/src/GS/testclient/gstestclient.c: Ah, progress - need to pack the message using pkg_pshort |
| 20:32.34 | starseeker | why do I need to supply the port as the first element of pkg_send?? |
| 20:43.33 | dli | starseeker, my first try to get strict build: basically, try to use intptr_t instead of int. but I don't understand tcl/tk enough to be sure I'm not break anything |
| 20:43.37 | dli | starseeker, http://paste.pocoo.org/show/353112/ |
| 20:43.52 | dli | starseeker, it compiles at least |
| 20:44.16 | starseeker | dli: I'm still not clear, why are you trying to build Tcl/Tk strict? |
| 20:44.44 | dli | starseeker, no, just want to enable -Werror generally |
| 20:45.09 | dli | starseeker, the problem seems to be within tkTable part |
| 20:45.28 | starseeker | dli: src/other shouldn't be built with -Werror on |
| 20:45.32 | starseeker | it is expected that it would fail |
| 20:46.30 | dli | starseeker, then, better to set that in autotools/cmake, so, users don't have to be worried |
| 20:46.52 | starseeker | CMake build should work correctly - it does in my testing here |
| 20:47.03 | starseeker | If autotools is feeding -Werror to src/other it's a bug |
| 20:47.50 | starseeker | dli: you can try the CMake branch, if you like: svn co https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/branches/cmake brlcad-cmake |
| 20:48.18 | dli | starseeker, just noticed the archlinux maintainer failed to update package version, because of -Werror |
| 20:49.15 | dli | starseeker, I can submit a cmake ebuild to gentoo for brlcad-svn |
| 20:49.23 | starseeker | dli: what are you trying to do - enable -Werror or disable it? |
| 20:49.59 | dli | starseeker, I want users never get the -Werror trouble :( |
| 20:50.06 | starseeker | supplying --disable-strict to the autotools build should do that |
| 20:50.13 | starseeker | ./configure --disable-strict |
| 20:50.43 | dli | starseeker, I knew the solution, because I had to investigate and find out. |
| 20:52.12 | starseeker | that should be documented in the INSTALL file |
| 20:53.00 | dli | starseeker, also, I feel if -Werror should be enabled by correcting the code itself, if possible |
| 20:54.58 | starseeker | for src/other that's a VERY large task |
| 20:55.18 | starseeker | we don't maintain those codebases (with a couple exceptions) so you'd have to get the patches accepted upstream |
| 20:56.06 | dli | starseeker, if so, probably, upstream will address the problem, just have to wait |
| 20:56.15 | starseeker | the BRL-CAD code itself is very clean (thanks mostly to brlcad) but the src/other code is another story |
| 20:56.40 | starseeker | dli: it's pretty rare, in my experience, to have code bases that build well using strict flags |
| 20:57.38 | starseeker | admittedly things are slowly getting better, both in the compiler world and overall open source community, but it takes time - if it works, it's usually not a high priority to clean up all those pesky warnings |
| 20:58.30 | dli | starseeker, the tktable part keeps casting int to a pointer, it may be undefined behavior eventually :( |
| 20:58.49 | starseeker | yeah, tktable code I remember as being a tad noisy |
| 20:59.04 | starseeker | they're actively developed though, IIRC - you might try talking to them direct |
| 20:59.10 | dli | starseeker, as far as the pointer has to go beyond 32bit |
| 20:59.38 | starseeker | yeah, I think this is it: http://tktable.sourceforge.net/ |
| 21:00.05 | starseeker | http://sourceforge.net/projects/tktable/ |
| 21:00.41 | *** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net) | |
| 21:01.31 | starseeker | if they don't want to take patches that are genuine bug fixes, we can patch our tree - but better to try upstream first |
| 21:02.07 | dli | starseeker, I will try cmake tree first |
| 21:02.34 | starseeker | dli: that doesn't have any different code in src/other |
| 21:02.49 | starseeker | it quiets the warnings, but the code that prompted them is still there |
| 21:03.21 | dli | starseeker, as far as the -Werror trouble is shielded from users, it's good enough for me |
| 21:04.12 | starseeker | feedng disable-strict to configure will also achieve that goal |
| 21:04.25 | starseeker | and not require using an experimental branch ;-) |
| 21:05.44 | dli | starseeker, it works, but if I still don't like to see it in building scripts, even better, user can even enable strict build, but -Werror will be auto off for src/other/ |
| 21:07.53 | starseeker | well, you can give the CMake branch a whirl and see if it does what you want, but remember it's an experimental development branch |
| 21:09.38 | dli | starseeker, I want to work on something of relevant openNURBS, to help me understand the code base, so I can get to the intersection part |
| 21:10.18 | dli | starseeker, any suggestion within an area relevant to oN for me to work on? |
| 21:10.26 | louipc | is disable-strict for the top configure script really needed anymore? |
| 21:10.38 | louipc | I thought all the warnings were cleaned up recently |
| 21:10.50 | dli | louipc, needed:( |
| 21:11.17 | dli | louipc, but it works for 7.18.2 and -svn |
| 21:11.35 | dli | louipc, I mean --disable-strict-build works |
| 21:12.02 | starseeker | louipc: from what dli is saying, it sounds like -Werror is leaking down into src/other somehow |
| 21:12.14 | louipc | hmm ok |
| 21:12.27 | starseeker | dli: do you want to start coding right away? |
| 21:12.42 | dli | starseeker, I thought I already started :( |
| 21:12.54 | starseeker | I mean, writing openNURBS related C code |
| 21:12.58 | louipc | :D |
| 21:13.10 | dli | starseeker, yes |
| 21:14.07 | dli | starseeker, have been reading oN wiki, still need more exercises to understand more |
| 21:15.10 | starseeker | dli: brlcad is the better one to ask - I'm a little biased when it comes to openNURBS. I'm trying to make a standalone NURBS library based on it with the intersection and tessellation functionality added on |
| 21:15.22 | louipc | starseeker++ |
| 21:15.35 | louipc | fork opennurbs? |
| 21:15.52 | starseeker | not really a fork, except insofar as is necessary to cleanly add functionality |
| 21:15.52 | dli | starseeker, forking oN sounds too much :( |
| 21:15.55 | starseeker | more like build on |
| 21:16.06 | louipc | ah |
| 21:16.28 | starseeker | dli: For BRL-CAD, I'd suggest looking into taking a NURBS surface and generating BoTs from it |
| 21:16.45 | starseeker | dli: that would be a relatively straightforward, high impact task |
| 21:17.17 | louipc | dli: the problem I find with opennurbs is that the development actually seems quite closed |
| 21:17.45 | dli | starseeker, I will try that first, then |
| 21:18.17 | starseeker | dli: we can generate surface trees from NURBS already (we need that for raytracing) so they may help you |
| 21:18.26 | starseeker | where's that tessellation paper... |
| 21:18.54 | starseeker | http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.142.3042 |
| 21:20.10 | starseeker | I'd suggest not trying for closed volumes in the first attempt - just get a non-closed BoT representation of a brep primitive by generating triangles from all of its surfaces |
| 21:20.29 | starseeker | if you do that, that's enough for basic shaded display |
| 21:21.00 | dli | starseeker, I will try :) |
| 21:21.03 | starseeker | louipc: the openNURBS model for development is indeed closed - they aren't really running an open source project in the classic sense |
| 21:21.23 | starseeker | they're just making it (much) easier for people to deal with 3dm files |
| 21:23.19 | starseeker | louipc: if you're curious, my preliminary efforts are here: http://libnurbs.git.sourceforge.net/git/gitweb.cgi?p=libnurbs/libnurbs;a=summary |
| 21:24.33 | louipc | oh nice |
| 21:25.10 | starseeker | that's just a "starseeker's experimental project" thing, not related to BRL-CAD |
| 21:25.35 | starseeker | hopefully it'll someday be good enough to replace src/other/openNURBS, but we'll see :-) |
| 21:27.06 | starseeker | louipc: I summarized the overall goals in this post: |
| 21:27.09 | starseeker | http://groups.google.com/group/openmanufacturing/browse_thread/thread/1895cc2eb4d98b6f/a2f3d29238dbcb08#a2f3d29238dbcb08 |
| 22:58.57 | starseeker | grr |
| 22:59.18 | starseeker | anybody know anything about libpkg? how does a client get a message back from a server? |
| 23:00.56 | starseeker | is dubious that the geometry service can successfully talk over pkg... there's some test code that throws stuff from a client to a server, but I see no printout of responses FROM the server and the test works only with its own internal server setup |
| 23:13.37 | *** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com) | |
| 01:13.33 | *** join/#brlcad dli_ (~dli@dsl-69-171-148-245.acanac.net) | |
| 01:57.41 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 02:22.30 | ``Erik | um, tpkg.c is a trivial libpkg client/server thingiemajigger |
| 05:33.33 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:43.04 | *** join/#brlcad Stattrav (~Stattrav@122.172.156.61) | |
| 05:43.04 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:00.49 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 06:00.49 | *** join/#brlcad dtidrow_ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) | |
| 08:44.25 | *** join/#brlcad dli_ (~dli@dsl-69-171-148-245.acanac.net) | |
| 11:57.05 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 11:57.43 | dloman | Mernin all |
| 12:01.54 | starseeker | ``Erik: looked at that - but it appears to be a "the client talks, the server listens" setup |
| 12:02.21 | starseeker | dloman: did we ever get the geometry service to the point where the client and server communicate back and forth over the network? |
| 12:03.10 | dloman | starseeker: oh ya, one second |
| 12:03.17 | starseeker | based on what I've seen so far, the client and server will each have to run both a server instance, with the client sending its info to the server in order for the server to communicate back |
| 12:03.41 | starseeker | (to the client' |
| 12:03.45 | starseeker | s server) |
| 12:04.07 | dloman | ....um, no :) |
| 12:04.25 | starseeker | no? |
| 12:04.30 | starseeker | no what? :-P |
| 12:05.02 | dloman | one second, psudo afk |
| 12:05.08 | starseeker | k |
| 12:05.49 | starseeker | I've got to return some fans anyhow - if you can post how to get geomclient and geomserv to communicate meaningfully it would be a big help |
| 12:06.05 | starseeker | the C++ code is hard to follow |
| 12:07.13 | dloman | both use libNet. |
| 12:08.38 | starseeker | dloman: I'm trying to write a client that doesn't use libnet |
| 12:09.01 | dloman | already got one in progress. |
| 12:09.07 | starseeker | I can send stuff to the server, but I can't figure out how to get responses back |
| 12:09.37 | dloman | if you want, I can run u thru the code tomorrow |
| 12:09.44 | starseeker | that'd be great |
| 12:10.35 | starseeker | you're not in today, I take it? |
| 12:11.29 | dloman | not, telework |
| 12:11.59 | dloman | okay, sorry |
| 12:12.10 | dloman | was moving the laptops upstairs, hooking up, etc. |
| 12:12.18 | starseeker | that's OK |
| 12:13.29 | dloman | Okay, I am doing the java inteface thingy for ``Erik / guys upstairs |
| 12:13.35 | dloman | and am using that as a protocol validation |
| 12:13.44 | starseeker | nods |
| 12:13.45 | dloman | i have a minimal client already going in there. |
| 12:13.52 | dloman | that doesnt use libNet |
| 12:14.03 | starseeker | the bit I'm interested in right now is how you're getting responses back from the server |
| 12:14.21 | starseeker | pkg_send I figured out finally, but it seems to be a one way street so far |
| 12:20.10 | starseeker | I send the "RUALIVE" thing, but where do I look in the pkg setup for the response? |
| 12:20.43 | dloman | ...granted its a similar incarnation, java style. |
| 12:20.50 | dloman | one second. |
| 12:21.00 | dloman | lost mt Mt Dew, had to find it. Priorities ya know |
| 12:21.05 | starseeker | hehe |
| 12:21.13 | starseeker | of course - cars don't run without fuel |
| 12:21.33 | dloman | heh, well getting my 2 cyls going dunt take much :) |
| 12:21.46 | dloman | okay, |
| 12:21.47 | dloman | so |
| 12:21.53 | dloman | on the geomserv |
| 12:22.21 | dloman | we will assume that a connection has already been established and that the server side has a valid Portal to communicate thru |
| 12:23.04 | dloman | the server also will have a PortalManager that will do all the selecting on all sockets (FDs) |
| 12:23.16 | dloman | the PM has a FD<->Portal mapping. |
| 12:23.49 | dloman | when select returns a FD that is ready for read |
| 12:24.01 | dloman | a lookup on the mentioned map occurs |
| 12:24.11 | dloman | and the Portal::read() fn is called. |
| 12:24.33 | dloman | Portal::read() is simply a set of PKG calls |
| 12:24.46 | dloman | process(), suckin(), process() |
| 12:25.15 | dloman | now, the process() call will make pkg attempt to form a complete PKG msg |
| 12:25.39 | dloman | due to C++ limitations in the arena of function pointers, I had to short circuit the PKG's callback functionality |
| 12:26.15 | dloman | normally, when a pkg_conn is instantiated, it is fed a routing table |
| 12:26.44 | dloman | pkg then routes incoming pkg msgs according to the 16bit pkg_type and this routing table |
| 12:27.48 | dloman | in libNet, that routing table consists of a single type, and thus ALL pkg msgs are routed to Portal::callbackSpringboard |
| 12:27.53 | dloman | ..which is static |
| 12:28.59 | dloman | at this point, the bytes from the pkg data load are putinto a ByteArray object and the GS type is read |
| 12:29.14 | dloman | GS type is the first 16 bits of the pkg data load. |
| 12:29.18 | starseeker | ok, I think I'm with you |
| 12:29.43 | starseeker | it then deserializes the message and figures out what it's dealing with |
| 12:29.58 | dloman | the GSType is used in the NetMsg Factory to figure out which NetMsg deserial cstr to call. |
| 12:30.03 | dloman | exactly. |
| 12:30.24 | dloman | after a successful deserial, the NetMsg Factory hands the completed message over to the NetMsgRouter |
| 12:30.49 | dloman | NetMsgRouter is (right now) a simple subscriber/publisher setup |
| 12:31.56 | dloman | so if there is no routing data for a GS NetMsg, then it's discarded |
| 12:32.12 | dloman | looking at GeometryService::registerMsgRoutes, |
| 12:32.17 | starseeker | ok... where would it get routing data? |
| 12:32.33 | dloman | i see there is no mapping (currently) for RUALIVE |
| 12:32.59 | CIA-14 | BRL-CAD: 03starseeker * r43858 10/geomcore/trunk/src/GS/CMakeLists.txt: Whoops, copy paste typo |
| 12:33.35 | dloman | hrm, there are two netmsg types that are supposed to be handled by the Portal object, RemNodeNameSet and RUALIVE |
| 12:33.46 | dloman | i wonder why its not working... |
| 12:34.03 | dloman | i am debugging the gs with all the changes still, might be something there. |
| 12:34.09 | starseeker | k |
| 12:34.18 | starseeker | was going insane on Sunday |
| 12:34.36 | dloman | but to answer your 'where does it get routing data from ' question: its all configurable. |
| 12:34.56 | dloman | the geomserve does it in GeometryService.cxx line 58 |
| 12:35.21 | starseeker | dloman: as an aside, it sounds like we're paying a fairly high complexity price for being able to use C++ |
| 12:35.52 | dloman | eh, kinda. |
| 12:36.09 | starseeker | not a criticism, just curious - how come C++ instead of C? |
| 12:36.14 | dloman | the pkg complexity has been minimized (with lots of hairpulling and pain) |
| 12:36.28 | starseeker | right, but why not just do it the libpkg way in C? |
| 12:36.34 | dloman | from what I understand, its from a few differnt sources. |
| 12:37.02 | dloman | desire to have a C++ interface for the general public |
| 12:37.22 | dloman | C++ lends itself to a plugin-able style app arch better than C |
| 12:37.27 | dloman | and a few others i've forgotten. |
| 12:37.31 | starseeker | urm. For the GS, that's kinda moot - the interface is the network protocol |
| 12:37.44 | dloman | ping brlcad, im sure he remembers all the reasons :) |
| 12:37.55 | dloman | not really. |
| 12:38.14 | dloman | the design for the GS is to have modules of functionality that can be 'plugged in' |
| 12:38.27 | dloman | aka, the STEPConverter plugin |
| 12:38.32 | starseeker | uh... that's on the backend |
| 12:38.46 | dloman | yeah |
| 12:39.35 | starseeker | dloman: ok, well I've got to get those fans back - if you can debug why RUALIVE isn't doing anything I'd appreciate it :-) |
| 12:39.44 | dloman | kk |
| 12:39.50 | starseeker | thanks, bbl |
| 12:47.19 | *** join/#brlcad Stattrav (~Stattrav@122.172.156.61) | |
| 12:47.19 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:33.57 | ``Erik | hm, the build stuff I added was just copying another file and updating it... BSD license is dandy with me *shrug* (I think that technically, my contributions are considered public domain) |
| 13:44.23 | dloman | ``Erik: segfaulting in your magic endian converter in geomcore |
| 13:45.10 | dloman | the whole dat[0] ^= data[7] ^= data[0] ^= data[7] block |
| 13:47.48 | dloman | need a little help there since i verified the data its manipulating is not NULL, but all those bitwise ops are beyond me :/ |
| 13:48.21 | ``Erik | hmmmm |
| 14:07.06 | CIA-14 | BRL-CAD: 03erikgreenwald * r43859 10/geomcore/trunk/src/libNet/netMsg/GenericEightBytesMsg.cxx: use ntohll instead of the xor hack |
| 14:12.50 | dloman | excellent, thanks! |
| 14:13.02 | ``Erik | that fixed it? O.o |
| 14:13.30 | dloman | well, i had to put the htohll call down in the _serialize() fn too, but yeah, it seems to be working |
| 14:13.36 | dloman | well, it doesnt segfault anymore |
| 14:13.47 | dloman | im going to validate the values in a second |
| 14:13.56 | ``Erik | cool |
| 14:14.24 | ``Erik | http://www.cnn.com/2011/POLITICS/03/13/crowley.stepping.down/index.html?hpt=T2 |
| 14:54.37 | starseeker | dloman: is there a client/server setup anywhere (test app, whatever) that I can start up a server and client, type "ping" in the client and have the *client* (not the server) print out the server's *PONG* response? |
| 14:55.10 | starseeker | i.e. not a log message being generated by the server, but a command line report in the client of what the server's response was? |
| 14:57.49 | dloman | yes, Im debugging that very thing atm |
| 14:58.32 | starseeker | cool, thanks |
| 14:59.04 | starseeker | feels another hair turn grey... |
| 14:59.29 | dloman | hows the basement dewatering going? |
| 14:59.57 | starseeker | we're pretty much dried out - the test now is to see what will happen with the pump actually in place |
| 15:00.16 | dloman | did you do an op test of the pump? |
| 15:00.40 | starseeker | heh - that's what finally stopped the flooding from getting worse Thursday |
| 15:00.47 | starseeker | pump was working for a while to clear the backlog |
| 15:01.04 | dloman | well, nothing like a burn in :) |
| 15:01.11 | dloman | good to hear you are all dried out. |
| 15:01.27 | dloman | sucky thing to be happening in a 'new' home :/ |
| 15:01.46 | starseeker | no kidding - we're probably looking a this, roof and gutters this spring |
| 15:11.06 | dloman | he he, neat. somehow, my PING messages are all originating from the same time... a long time ago, resulting in roundtrip times in the 3 million seconds range, lol |
| 16:03.00 | dloman | is htonll a libbu thing? |
| 16:03.13 | starseeker | I don't believe so |
| 16:03.47 | dloman | i cant find info on htonll.... htonl, sure but not the ll version |
| 16:03.59 | starseeker | http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.commtechref/doc/commtrf2/htonll.htm |
| 16:04.35 | dloman | bah, bloody google was replacing text for me :/ |
| 16:04.55 | starseeker | also, see bu.h line 661 or thereabouts |
| 16:04.56 | dloman | thanks :) |
| 16:05.06 | starseeker | not all platforms have it |
| 16:05.11 | starseeker | (apparently) |
| 17:21.21 | CIA-14 | BRL-CAD: 03davidloman * r43860 10/geomcore/trunk/src/GS/GSClient.cxx: Clean up PING and PONG logging. |
| 17:22.34 | CIA-14 | BRL-CAD: 03davidloman * r43861 10/geomcore/trunk/src/GS/GeometryService.cxx: Clean up PING and PONG logging on server side also. |
| 17:25.22 | CIA-14 | BRL-CAD: 03davidloman * r43862 10/geomcore/trunk/src/libNet/netMsg/GenericEightBytesMsg.cxx: Fix a network/host ordering issue. |
| 17:38.00 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.246) | |
| 17:38.00 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:55.28 | starseeker | gets back to basics: http://beej.us/guide/bgnet/output/html/multipage/index.html |
| 20:15.22 | ``Erik | http://bravenewclimate.com/2011/03/13/fukushima-simple-explanation/ |
| 20:38.03 | ``Erik | starseeker: ISC license (like the new BSD), specifically for the mdoc macro package, http://mdocml.bsd.lv/ |
| 20:47.54 | starseeker | awesome |
| 20:49.45 | *** part/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 21:01.08 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 22:01.23 | Ralith | why do we need a new BSD? |
| 22:02.07 | starseeker | Ralith: new BSD license (a.k.a Modified BSD license) - no advertising clause |
| 22:02.39 | Ralith | oh, so the "new BSD", not the new "BSD" |
| 22:04.41 | starseeker | right |
| 01:40.16 | KimK | Hi, I can't install the 7.18.2 .deb in Ubuntu 10.04 due to dependency issues (my libncurses5 is too old, it's current). Would it be a reasonable project to compile BLR-CAD from source on my machine, or would I hit the same libncuses5 wall anyway? |
| 01:40.52 | KimK | s/libncuses5/libncurses5/ |
| 01:41.38 | KimK | s/BLR-CAD/BRL-CAD/ |
| 01:42.26 | KimK | is sure glad he caught those mispellings before that went out, whew! |
| 02:19.33 | starseeker | might be able to get his hands on a neo1973 phone... |
| 04:02.21 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 04:23.18 | dli_ | KimK, still couldn't get 7.18.2? |
| 05:35.40 | KimK | dli_: Hi, I have the .deb of course, but gDebi says my libncurses5 is too old, I have 5.7+2009xxxx and it wants 5.7+2010xxxx or something. So I thought I might be able to persuade a dev to freshen the Ubuntu 10.04 libncurses5, but I haven't managed that yet either. I think even the Debian libncurses5 is too old. So then I thought, maybe compile from source on my machine? Anyway, no, BRL-CAD still not installed here. |
| 05:39.57 | KimK | dli_: And I have the source tarball, but I'm trying to learn git and brlcad is on Sourceforge with SVN. So I've been fiddling with git-svn to load the development source, I have done that several times, lol. Maybe Sourceforge's SVN doesn't play nice with git-svn? I haven't got that sorted out yet. |
| 05:43.16 | KimK | dli_: Thanks for checking on me. Any and all comments and advice appreciated. Again, I would like to install BRL-CAD on Ubuntu 10.04 LTS by any method. No hurry, I just wanted to try it and see what all the fuss is about, lol! |
| 05:49.59 | KimK | dli_: Pursuing this problem from another angle, I wonder if you could help me find out what OS the BRL-CAD developers are using, where they got this new libncurses5? I have virtualbox, and I'm getting the new Debian 6.0 DVD (slowly). If I installed Debian 6.0 in VBox, would I be able to install BRL-CAD there? Just thinking about other ways to skin the cat. |
| 05:54.15 | Ralith | there's fuss? |
| 06:16.08 | KimK | Haha, sure! Powerful and free/open, if perhaps not easy to learn and use? Such are the reports I hear, anyway. |
| 06:21.54 | KimK | If it's in the same class as SolidWorks, and is free/open and Linux-friendly, I'd certainly like to have a look at it. |
| 06:50.15 | *** join/#brlcad Stattrav (~Stattrav@122.172.156.61) | |
| 06:50.15 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:20.39 | *** join/#brlcad Stattrav (~Stattrav@122.172.156.61) | |
| 09:20.39 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:33.51 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 11:01.59 | dli_ | KimK, you may try to rebuild it. First make sure you have deb-src lines in your sources.list, then: apt-get build-dep brlcad; apt-get -b source brlcad |
| 11:25.11 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2599 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Non-Uniform Rational B-Splines */ |
| 11:29.02 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2600 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Display Managers / Framebuffers */ |
| 11:35.11 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2601 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Graphical Interface Enhancements */ |
| 11:40.50 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2602 10/wiki/Google_Summer_of_Code/Project_Ideas: |
| 11:49.36 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2604 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Project Ideas */ |
| 11:50.38 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2605 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Graphical User Interface Infrastructure Projects */ |
| 11:50.52 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2606 10/wiki/Google_Summer_of_Code/Project_Ideas: /* User Interface Enhancement Projects */ |
| 11:54.19 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2607 10/wiki/Google_Summer_of_Code/Project_Ideas: separate into two categories |
| 11:56.57 | CIA-14 | BRL-CAD: 03Sean 07http://brlcad.org * r2608 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Tool Projects */ |
| 12:32.14 | ``Erik | it should build fine from source on any reasonably recent *nix... the developers use mac, freebsd, rhel and gentoo for the most part |
| 12:53.49 | cjdevlin | KimK: i have installed on 10.04 several times from source. i had no issues. |
| 13:17.13 | *** join/#brlcad Stattrav (~Stattrav@122.172.156.61) | |
| 13:17.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:19.11 | cjdevlin | i just did a wget on this link: http://sourceforge.net/projects/brlcad/files/BRL-CAD%20Source/7.18.2/brlcad-7.18.2.tar.gz/download |
| 13:19.11 | cjdevlin | and the tarball i got was 7.18.0? |
| 13:31.54 | KimK | dli_ , cjdevlin: OK, I will try building from source. I did try installing Debian 6.0 in Vbox and then installing BRL-CAD there, that seemed to work, but I'd prefer to have BRL-CAD on my main screen. So this MGED is the main app screen? Are there tutorials on the Wiki? I looked at the wiki and downloaded a bunch of manuals, but I'm starting from zero here, and this doesn't look like any other CAD program I've ever run across. Anything on YouTub |
| 13:31.54 | KimK | e? Where do you recommend newbies begin? |
| 13:31.57 | KimK | Opps |
| 13:32.01 | KimK | Oops |
| 13:32.37 | cjdevlin | there is a tutorial on the wiki. before you try to build run: sh autogen.sh |
| 13:33.25 | cjdevlin | the tutorial is still *pretty* close, but there are some inconsistencies. |
| 13:33.36 | cjdevlin | did you ask about this in the ubuntu forums a week or so ago? |
| 13:33.41 | cjdevlin | ubuntu irc* |
| 13:36.29 | KimK | OK, thanks, I will. That's not in the wiki? I may have asked about updating libncurses5, were you there? I didn't really get anywhere with that though. Where does everybody put the tarball if they might want to have SVN later too? I presume SVN (devel) is broken once in awhile? |
| 13:37.50 | KimK | Or do I have to pick one or the other and use only ~/brlcad/ ? |
| 13:38.26 | cjdevlin | the tutorial is available . . . let me see if i can find it. i kind of remember something like that when i first tried to build. autogen took care of it. you can use checkinstall to install programs as a 'package' |
| 13:40.43 | cjdevlin | http://brlcad.org/wiki/Documentation |
| 13:41.13 | cjdevlin | the introduction to mged is a complete tutorial. you can be up and running in a few hours if you can sit that long :-) |
| 13:41.59 | cjdevlin | and the code is hosted on sourceforge: http://sourceforge.net/projects/brlcad/files/BRL-CAD%20Source/ |
| 13:42.13 | cjdevlin | sourceforge went down a few weeks ago, but that is very uncommon |
| 13:42.22 | KimK | OK, thanks for looking. I was just thinking that it would be nice to have both the tarball source for the latest release version and the SVN source for the devel version, even if broken sometimes, but I don't want to do anything that's non-standard. Who knows, maybe I can even help later on. |
| 13:43.41 | cjdevlin | i am not a developer. i am relatively new myself. the guys that really know what they are doing read the logs, so if you stay logged on long enough you will definitely get the help you need/want |
| 13:44.24 | cjdevlin | are you building now? |
| 13:44.25 | KimK | Yes, I was wondering about sourceforge. I'm a git fan and I tried to download with git-svn, which I've done before other places. But it didn't seem to work, it started, then stalled out. If I use SVN, it works fine. |
| 13:44.56 | cjdevlin | for sourceforge i usually just do a wget |
| 13:45.23 | KimK | That doesn't work for SVN, does it? |
| 13:45.27 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:47.25 | cjdevlin | not sure. i have never tried it. i have just stuck with the stable releases so far. |
| 13:48.49 | KimK | Ha, thanks for the tip about staying logged on. I'll add this channel to my auto sign-on. A friend of mine has access to 1 seat of SolidWorks, but that may turn out to be temporary, who knows? So it would be good if I could learn BRL-CAD as an alternate. But I'm more in favor of it becasue of the free/open thing. SW may be nice, but I don't own it. I can own BRL-CAD. |
| 13:50.20 | cjdevlin | i know a windows version is in the works and they are converting from autotools to cmake for cross platform-ability </madeupword> |
| 13:50.49 | cjdevlin | are you trying to build now? |
| 13:53.08 | KimK | No, I haven't tried yet. I was still wondering about whether the tarball/scripts/automake/etc will be happy if I put them someplace besides ~/brlcad/ ? Can I put it anywhere? |
| 13:54.46 | cjdevlin | yes. |
| 13:54.58 | KimK | How about ~/brlcad7182/ ? Would that be OK? |
| 13:55.18 | cjdevlin | i download all of the files i build into ~/source/<nameofprog> |
| 13:56.05 | cjdevlin | when you extract it, it will create a directory in a format of: brlcad-7.18.2 |
| 13:56.21 | KimK | OK, I'll try that. I usually use git, so I haven't done a tarball for anything yet. But that sounds OK. |
| 13:56.53 | cjdevlin | it's just a compressed version. |
| 14:00.29 | KimK | The wiki mentions ./autogen.sh is that what you meant when you wrote sh autogen.sh ? |
| 14:01.37 | cjdevlin | yes, that does the same thing |
| 14:02.06 | KimK | OK. I hadn't seen that sh before, just the ./ |
| 14:03.06 | cjdevlin | ./ runs executables, sh invokes the shell directly. *.sh is the shell file type, so ./ will call the shell anyways |
| 14:03.19 | dloman | Mernin all. |
| 14:03.32 | KimK | Wait, before I do that, wasn't there some brlcad-build-essentials or something? Let me scroll back... |
| 14:03.59 | cjdevlin | regular build-essentials |
| 14:04.41 | KimK | brlcad-dev maybe? I thought there was something. No? |
| 14:05.09 | KimK | I should already have build-essentials |
| 14:05.32 | KimK | OK, I'll try it and see if it warns me |
| 14:05.36 | dloman | I know i'm jumping in the middle of this and havent read the backlog yet, but are you trying to get brlcad built from source? |
| 14:05.46 | KimK | Yes, I am. |
| 14:05.54 | KimK | HI, thanks for asking |
| 14:06.02 | cjdevlin | there are no ubuntu brl-cad dev packages. |
| 14:06.14 | KimK | OK, thanks. |
| 14:06.29 | dloman | KimK: having problems then? |
| 14:09.10 | KimK | Well, had some other problems before, but just starting to build from source right now. OK, it says it's prepared and to run ./configure and then make. I'll start it. |
| 14:09.49 | dloman | you have multicore machine? |
| 14:12.07 | dloman | My oh my, things are looking grim at the Dai-Ichi plant in Japan.... |
| 14:13.27 | KimK | No, one core. And I run 32-bit Ubuntu even though it's an AMD64 (small, cheap one though) because I stick with the EMC2 folks and 64-bit real-time isn't quite soup yet. |
| 14:14.05 | dloman | okay then, you're in for a bit of a wait. brl-cad takes a while to build. |
| 14:15.39 | KimK | I saw one medium-sized warning about >>>>>>>>>>>>>Floating Point May not be Compatible>>>>>>>>>>>> or something. And a couple of small warnings. But it didn't stop, it completed. It said type make, so I did. |
| 14:15.50 | dloman | right on. |
| 14:16.11 | dloman | if configure succeeded, then you are probably good to go. |
| 14:16.20 | dloman | the make will take some time, though. |
| 14:16.58 | cjdevlin | KimK: i had the same issue w/ the libncurses i think. running autogen.sh took care of it for me. i had the same floating point warning, but haven't run into an issue yet. |
| 14:17.42 | cjdevlin | just built on a sempron: Elapsed compilation time: 1 hour, 5 minutes, 24 seconds |
| 14:17.42 | cjdevlin | Elapsed time since configuration: 1 hour, 7 minutes, 30 seconds |
| 14:17.46 | cjdevlin | not too crazy :) |
| 14:20.28 | KimK | OK, no problem. cjdevlin , dloman , thanks very much for your help. Ha, I was just going to ask if it would be about an hour or more. I have a recent but unremarkable motherboard, 4G of ram (well, 3.7after the on-board-graphics robbery), and a cheap proc. |
| 14:21.22 | dloman | as long as you can afford the time, then 1+ hrs is no biggie :) |
| 14:22.04 | cjdevlin | KimK: the machine i built on is a fossil of sorts. it shouldn't take you quite that long. |
| 14:22.28 | cjdevlin | but if you are planning on upgrading/working on release code often, i would recommend using checkinstall |
| 14:22.33 | KimK | Don't feel like you guys have to stick around. If you've got someplace to go, go. Thanks for your help. I might let it run and come back later myself. Should I follow the wiki "build from SVN" (skipping the SVN part) to finish the install? I saw some stuff about adding symbolic links and so forth. |
| 14:23.23 | dloman | oh I work here, so I'll be here all day =D |
| 14:23.34 | KimK | Ha, OK, thanks. |
| 14:26.20 | *** join/#brlcad PrezKennedy (MK@2607:f0d0:3001:68::2) | |
| 14:28.57 | dloman | simply put, after the 'make' is finished, you can 'make install' to install the compiled binaries to your machine. |
| 14:29.11 | dloman | then just run any of them from the command line. |
| 14:29.24 | dloman | its likely you are looking for the graphical editor: mged |
| 14:31.00 | KimK | Ha, you're ahead of me, but I had already started typing: OK, so (reading from wiki) when make is done, make test, make benchmark, make install, bunch of symbolic links, fis the path, benchmark, mged. Does that sound about right? |
| 14:31.21 | KimK | s/fis/fix/ |
| 14:31.27 | dloman | could even be easier than that. |
| 14:31.29 | dli_ | KimK, I still suggest you run the debian/rules script to build, better than checkinstall |
| 14:32.11 | dloman | if you are installing to a dir that is already on your PATH, (and you have perms to do so) then it should be as simple as 'make install' then, once finished, 'mged' |
| 14:33.27 | KimK | dli_: OK, how do I do that? What do you suggest? dloman: Shall I fix the path first, when make is done? |
| 14:33.49 | dloman | what os are you running anyways? |
| 14:34.01 | dli_ | KimK, apt-get build-dep brlcad |
| 14:34.14 | dli_ | KimK, apt-get -b source brlcad |
| 14:34.26 | KimK | Ubuntu 10.04 LTS 32-bit with EMC2 special-patched RTAI real-time kernel. |
| 14:35.30 | dloman | KimK: at the end of the ./configure run, did you happen to see where it said it was set to install to? |
| 14:35.39 | KimK | dli_: OK, can I do that while make is running? |
| 14:36.29 | dli_ | KimK, oh, I didn't realize brlcad is not in ubuntu :( |
| 14:36.35 | KimK | dloman: No I didn't think to check, and I'm pretty sure it's scrolled off now. But I had deleted my ~/brlcad/ dir, so if it's back, it created it. |
| 14:36.47 | dloman | dli_: if KimK is already configured and compiling, why try getting packages via apt? |
| 14:37.01 | dloman | nm |
| 14:37.30 | dloman | KimK: do you have sudo perms on this machine? |
| 14:38.11 | dli_ | dloman, make install is basically bypassing apt, checkinstall should be avoided, whenever possible |
| 14:39.00 | cjdevlin | dli_: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=289632 |
| 14:39.21 | dloman | what are the detremental effects of compiling and installing manually? Its never cause me a problem..... |
| 14:40.08 | KimK | dloman: Yes, my machine. I'm the owner. Hey, I really appreciate the help you guys. You probably all have a lot of experience with BRL-CAD now, but think back to when you first started with it. How long did it take before you could make simple cubes and cones and sort of have a clue what's going on with it? |
| 14:40.21 | cjdevlin | dli_: why do you recommend avoiding checkinstall (just curious - as i have said, i'm pretty new)? |
| 14:40.55 | cjdevlin | KimK: if you work through that tutorial you can make a simple radio in the first 1/2 hour |
| 14:41.57 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 14:41.58 | dli_ | cjdevlin, if you have the debian/ script folder in source |
| 14:42.02 | KimK | cjdevlin: OK, I'll find it. I downloaded about any PDF I ran across. |
| 14:43.40 | cjdevlin | dli_: i would think just running checkinstall would be easier for someone new that is just trying it out over dpkg-buildpackage or debuild? |
| 14:44.55 | dli_ | cjdevlin, we need a debian/ubuntu repository, so user can do: apt-get build-dep, and apt-get -b source |
| 14:46.55 | cjdevlin | dli_: i don't disagree with that, but at this point, afaik, that isn't an option? |
| 14:47.09 | KimK | dli_: I did apt-get --dry-run on those packages. It was as you guys suspected, they were both "E: Unable to find a source package for brlcad" |
| 14:47.34 | dli_ | cjdevlin, I have no idea, I thought there must be a repository for brlcad already:( |
| 14:47.53 | dli_ | couldn't believe it, gentoo seems to be the only one has brlcad in main tree |
| 14:48.05 | KimK | (And I've got something like 109 repos cranked in!) |
| 14:48.19 | cjdevlin | there is not, the previous link i posted is the 'request for packaging' in debian (which will then make it into ubuntu) |
| 14:48.57 | cjdevlin | if the group would be so kind as to help me out, i wouldn't mind building/maintaining a ppa for brl-cad on launchpad |
| 14:49.50 | CIA-14 | BRL-CAD: 03davidloman * r43863 10/geomcore/trunk/tests/utility/uuidTest.cxx: Minor print verbage change. Removed WS. |
| 14:50.29 | KimK | Oh, BTW, make is done. Probably for a few minutes now. (Put your money into more RAM, every time, lol!) |
| 14:51.28 | KimK | cjdevlin: That would be great, ppa's are always a great convenience. |
| 15:00.30 | CIA-14 | BRL-CAD: 03davidloman * r43864 10/geomcore/trunk/src/utility/Config.cxx: WS and Formatting. |
| 15:00.40 | dli_ | cjdevlin, KimK just want to double check before 'checkinstall', what is your prefix during ./configure |
| 15:01.30 | *** join/#brlcad PrezKennedy (MK@2607:f0d0:3001:68::2) | |
| 15:01.51 | cjdevlin | after make, just do: sudo checkinstall |
| 15:02.06 | cjdevlin | for checkinstall you shouldn't have to do anything different |
| 15:03.36 | cjdevlin | (outside of making sure checkinstall is there: sudo apt-get install checkinstall) |
| 15:12.31 | KimK | Oh, sorry guys, I was following the wiki. So far I've done make test and make benchmark. And I skipped ahead to fix the paths because I haven't quite figured out what to do with that bunch of symbolic links yet. Different versions installed at the same time? dli_ OK, how can I check the prefix? The directory I was building in was ~/source/brlcad-7.18.2 I have no knowledge of checkinstall, but I'll check up on it. OK, I have checkinstall now. I |
| 15:12.31 | KimK | <PROTECTED> |
| 15:15.24 | dli_ | KimK, better to check config.log |
| 15:17.02 | dli_ | KimK, if your prefix is /usr it mean mess up the whole system, better in /opt/brlcad, or /usr/brlcad |
| 15:18.28 | KimK | There's a bunch of stuff in config.log, I'm not sure what you're asking for. |
| 15:19.12 | dloman | can easily just run ./config again, and note the install paths at the end |
| 15:19.44 | KimK | Would you like me to pastebin the config.log file? |
| 15:21.09 | KimK | Especially, how can I tell if this "mess up the whole system" thing has occurred? |
| 15:21.31 | dloman | KimK: did you do a 'make install' ? |
| 15:25.07 | CIA-14 | BRL-CAD: 03davidloman * r43865 10/geomcore/trunk/ (include/Config.h src/utility/Config.cxx): Added int and short getter to Config. Simplify via code consolidation |
| 15:25.43 | dli_ | KimK, you can pastebin config.log |
| 15:26.10 | KimK | dloman: No, I haven't. I did the autogen thing, configure, make, make test, make benchmark, passed on make install, took a pass on the symbolic links, skipped ahead to fix the paths and wait for more advice, haven't got to benchmark and mged yet. |
| 15:27.19 | dloman | The sym links are an optional setup for having multiple versions of the brlcad libraries installed. (its just standard ops for any libraries installed that require olderversions to remain on the system) |
| 15:27.36 | dloman | so from this point on, if all you are trying to do is get mged up and running: |
| 15:28.17 | dloman | 1) Verify your installation path by: either runing ./config again or check the config.log to see where the PREFIX path is set to. |
| 15:28.28 | dloman | 2) 'mged' |
| 15:28.33 | dloman | and you should be good to go. |
| 15:28.57 | dli_ | dloman, what's the default prefix? /usr/loca/? |
| 15:29.20 | KimK | Apparently that file is too big for pastebin. Do you guys have a place you like to post that file? |
| 15:29.27 | dloman | I believe so. |
| 15:30.09 | dloman | im on RHEL, but I'll check the default prefix here. |
| 15:30.21 | KimK | OK, running ./config again |
| 15:30.36 | dli_ | KimK, only beginning part, like: head -100 config.log|wgetpaste |
| 15:31.05 | dloman | looks like /usr/brlcad/ is default for RHEL.. and likely ubuntu also. |
| 15:31.53 | cjdevlin | it is |
| 15:32.16 | dli_ | ac_default_prefix=/usr/local |
| 15:32.23 | KimK | prefix: /usr/brlcad Does that sound right? |
| 15:32.32 | dloman | so as long as you have perms to install to /usr/brlcad, you should be gtg. |
| 15:32.37 | dloman | sure does. |
| 15:32.40 | dli_ | AC_PREFIX_DEFAULT([/usr/brlcad]) |
| 15:32.50 | KimK | There are some subs below that too |
| 15:33.06 | dloman | right. standard stuff: lib, include, share..... |
| 15:33.38 | KimK | Still need the short pastebin? |
| 15:33.55 | cjdevlin | in the directory where you ran the config and make scripts, if brl-cad is something you sure you want, you can just do: sudo make install |
| 15:34.13 | cjdevlin | if you aren't sure (it's something you might want to remove) then you can look into using checkinstall |
| 15:34.57 | dli_ | cjdevlin, always use checkinstall instead of 'make install', whenever possible |
| 15:35.12 | dloman | even if someone does a 'make install' and want to uninstall it later.... its as simple as rm -fr /usr/brlcad |
| 15:35.18 | dloman | or even 'make uninstall' |
| 15:35.25 | KimK | I want it, but I might at some point want to upgrade to the next newer tarball. How would that affect things? |
| 15:36.06 | dli_ | KimK, do checkinstall and let apt to handle it :( |
| 15:36.20 | cjdevlin | agrees with dli_ |
| 15:36.43 | KimK | Oh, OK. So just delete the dir ~/source/brlcad-7.18.2 and install new in ~/source/brlcad-7.18.4 (or whatever?) |
| 15:37.18 | KimK | OK, so use the checkinstall? |
| 15:37.34 | KimK | Sorry, I'm a slow typer. Or I type to long. |
| 15:37.44 | cjdevlin | KimK: yes, use checkinstall |
| 15:37.49 | KimK | s/to long/too long/ |
| 15:37.55 | cjdevlin | sudo apt-get install checkinstall |
| 15:38.36 | cjdevlin | then in the directory where you did the config and make do: sudo checkinstall (and then just go w/ the defaults and a simple package desc. i.e. 'brl-cad') |
| 15:38.38 | KimK | I have checkinstall now. And abandon the make install that I never did? |
| 15:39.04 | KimK | And abandon the symbolic link business? |
| 15:39.16 | dloman | not to argue, because checkinstall certainly is a good tool, but brlcad has its own uninstall rule plus it installs to its own directory, so its non-intrusive. *shrug* |
| 15:39.38 | dloman | i use make install and make uninstall on my ubuntu 10.10 machine all the time. never had an issue. |
| 15:39.39 | cjdevlin | KimK: checkinstall will essentially do the make install for you, but it will treat the install as if you had installed it via synaptic/apt |
| 15:39.58 | KimK | I don't mind running out of a directory. The EMC folks call that running-in-place. |
| 15:40.03 | dloman | KimK: Yes, the sym link stuff is optional. |
| 15:40.28 | cjdevlin | dloman: i agree with you also, but it's nice to have it come up when you do dpkg -l (esp when newer people need other help that this may affect) |
| 15:41.00 | KimK | The EMC folks use run-in-place to have assorted versions of their programs all installed at once. |
| 15:41.34 | KimK | Maybe some call it compiled-in-place? |
| 15:44.01 | KimK | Let me ask you this. Assuming in the future there might be a release of brlcad-7.18.4 (as above), then I could have both .2 and .4 installed at once if I leave apt-get out of it? But if I use checkinstall twice, then apt-get will want to remove the older version, even though it's in a separate directory, is that right? |
| 15:45.01 | cjdevlin | KimK: both options allow for multiple installs. at this point it is up to you to determine which method is easiest for you. |
| 15:45.13 | KimK | Sorry, I'm not really familiar with checkinstall, I'm just trying to get a handle on all this. |
| 15:45.36 | cjdevlin | but either way it is very possible to have multiple versions of brl-cad installed concurrently |
| 15:45.57 | cjdevlin | and neither choice is really the *wrong* one. |
| 15:48.54 | KimK | Well, I don't mind whether I type 20 characters or 30 characters on the command line, but what I do know is that I'm pretty new at BRL-CAD, and I expect to install it again on other PCs, and there's a written procedure on the wiki that I can refer to again, however imperfect it might be. So I think I'd like to refer to the wiki just because it's written on the wall there, if you guys don't mind. |
| 15:50.01 | cjdevlin | it is your computing machine :-) and people will be here to help either way. |
| 15:50.56 | KimK | And this should not be taken as any type of criticism of you guys, I appreciate your help very much and am just trying to stumble my way through the jungle here. |
| 15:51.03 | dloman | download->autogen.sh->configure->make->make install |
| 15:51.22 | dloman | if everything goes well, it should be that easy |
| 15:51.52 | dloman | if some of the libs that brlcad needs are not present on the machine, then './config --enable-all' |
| 15:52.04 | dloman | and brlcad will build everything it needs to run |
| 15:53.37 | KimK | OK, easy is good, lol! And until there's a PPA or a repo or something better, installing by tarballs in ~/source/brlcad_revision_number/ seems like an OK thing to do? |
| 15:53.53 | dloman | yuppers. |
| 15:54.10 | dloman | if you have any Winderz machines, the binaries are precompiled. == even easier |
| 15:54.54 | dli_ | looks like Nishchay is working on brlcad in debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=289632 |
| 15:55.41 | KimK | OK. So now to tidy up the loose ends here, I should just have to say make install? Then benchmark and mged? |
| 15:56.04 | dli_ | KimK, checkinstall |
| 15:56.18 | cjdevlin | KimK: sudo make install |
| 15:56.24 | cjdevlin | that will install it |
| 15:56.43 | KimK | checkinstall? sudo make install? |
| 15:57.06 | cjdevlin | if you are trying to stick to the wiki, just do: sudo make install |
| 16:03.24 | KimK | I finally got around to the short pastebin, I just grabbed the first several hundred lines and pasted them. http://pastebin.com/WpBLDK6T |
| 16:10.11 | KimK | I looked at the bugs.debian link above, there was a git repo of BRL-CAD at Debian, at least in Aug 2010? Nice! It would be nice to think it's still there. |
| 16:10.35 | dli_ | --prefix=/usr |
| 16:18.00 | KimK | dli_: What's that? |
| 16:19.31 | dli_ | KimK, redo it :( |
| 16:20.50 | dli_ | ./configure --prefix=/opt/brlcad --with-opengl=/usr/lib --with-tcl=/usr/lib --disable-strict-build |
| 16:21.04 | dli_ | KimK, this is what I use for archlinux |
| 16:28.44 | dli_ | KimK, ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/brlcad/lib64 --prefix=/usr/brlcad --enable-strict-build --datadir=/usr/brlcad/share --mandir=/usr/brlcad/man --disable-almost-everything --disable-regex-build --disable-png-build --disable-zlib-build --disable-urt-build --disable-tcl-b |
| 16:28.44 | dli_ | uild --disable-tk-build --disable-itcl-build --disable-tkimg-build --disable-jove-build --disable-tnt-install --disable-iwidgets-install --enable-opennurbs-build --with-ldflags=-L/usr/lib64/itcl3.4 -L/usr/lib64/itk3.4 --with-x --with-x11 --disable-debug --disable-optimization --disable-runtime-debug --disable-verbose --disable-warnings --disable-progress --disable-documentation --enable-models-install --enable-parallel --with-ogl --with-jdk=/opt/ |
| 16:28.45 | dli_ | sun-jdk-1.6.0.24 |
| 16:29.42 | dloman | wow, thats a heck of a config line... why you need all that? |
| 16:31.54 | KimK | OK, it ran the benchmarks in 9:23 and mged gives me a big black screen and a smaller white screen. Of course, I have no clue what to do with either of them, lol! But I think it's working. And I do thank all you guys for your help, I really appreciate it. I'll keep hanging around here, but first I've got a lot of intro manuals and tutorials to look at. Thanks! |
| 16:32.44 | dli_ | dloman, not sure, it's autogenerated from gentoo ebuild |
| 16:49.37 | KimK | I have to go now, but I'll leave this window open in case you guys think of any advice for me while I'm gone. Thanks again. |
| 16:52.27 | dli_ | Benchmark results indicate an approximate VGR performance metric of 4859 |
| 18:16.42 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.203) | |
| 18:16.42 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:27.13 | starseeker | dloman: as long as I'm asking dumb questions, is this of any interest to us? http://s11n.net/ |
| 18:30.37 | dloman | maybe, i had looked at generalized object serialization, but thre are some limitations associated with it. Not to mention that we really dont need to send an entire object across the net, usually just specific pieces fo data. |
| 19:23.31 | CIA-14 | BRL-CAD: 03starseeker * r43866 10/geomcore/trunk/src/GS/testclient/gstestclient.c: Nothing useful yet with testclient - just a note that raw msg types down the socket isn't going to cut it for any msg type, even simple cases. |
| 21:26.59 | CIA-14 | BRL-CAD: 03starseeker * r43867 10/geomcore/trunk/src/GS/testclient/ (CMakeLists.txt gstestclient.c tpl.c tpl.h): OK, start over with testclient. First job is to put together a valid GSNet Msg to send. Have a look at tpl and see if it can be of any help for this. |
| 21:53.41 | CIA-14 | BRL-CAD: 03starseeker * r43868 10/geomcore/trunk/src/GS/testclient/gstestclient.c: get as far as getting what's expected into a struct. |
| 22:04.06 | CIA-14 | BRL-CAD: 03starseeker * r43869 10/geomcore/trunk/tests/CMakeLists.txt: Don't want the value in the cache - just set it locally so only the tests directory gets it. |
| 22:46.39 | starseeker | O.o http://automagically.de/g3dviewer/ |
| 23:34.55 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 00:05.42 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 07:19.39 | *** join/#brlcad Moonies (~Bongle@unaffiliated/moonies) | |
| 07:33.43 | *** join/#brlcad Stattrav (~Stattrav@122.172.6.40) | |
| 07:33.44 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:07.08 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 09:43.44 | *** join/#brlcad Moonies (~Bongle@unaffiliated/moonies) | |
| 10:35.55 | dloman | Mernin all |
| 10:46.36 | dloman | lol, awesome: http://www.myfoxboston.com/dpp/news/boy-body-slams-bully-20110315# |
| 11:07.39 | *** join/#brlcad Stattrav (~Stattrav@122.172.6.40) | |
| 11:07.39 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:18.30 | brlcad | sends greetings from Scotland |
| 11:18.40 | dloman | hey there slick! Vacation? |
| 11:19.02 | brlcad | yep |
| 11:19.17 | dloman | awesome! Whereabouts in Scotland are ya? |
| 11:19.36 | brlcad | western highlands, argyll by tarbert |
| 11:20.13 | brlcad | *really* close to Islay .. going to take the ferry and check out the Morrison distillery tomorrow :) |
| 11:20.28 | dloman | tee hee. awesome stuff man. |
| 11:20.31 | dloman | enjoy! |
| 11:21.12 | dloman | I never made it up to the western side. I stuck near Edinbough and north |
| 11:21.19 | dloman | ..well, and Glasgow |
| 11:21.48 | dloman | but there was a Football riot in the streets at the time and police wouldnt let us 'obvious americans' out of the train station :) |
| 11:22.30 | dloman | whats the itinerary? |
| 11:38.12 | *** join/#brlcad Elrohir (~kvirc@p5B14A350.dip.t-dialin.net) | |
| 11:51.36 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 12:01.05 | *** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net) | |
| 12:18.59 | *** join/#brlcad juan_man (~quassel@201.255.35.237) | |
| 12:19.06 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) | |
| 12:25.31 | *** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ) | |
| 12:26.13 | *** join/#brlcad poolio_ (~poolio@BZ.BZFLAG.BZ) | |
| 13:38.19 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:44.16 | *** join/#brlcad Stattrav_ (~Stattrav@122.172.6.40) | |
| 13:56.06 | dloman | starseeker: so that whole IDE issue i was having yesterday is due to the most recent java 'upgrade' ...grrrr. |
| 14:48.31 | dloman | starseeker: two compile errors in geomcore: |
| 14:48.37 | dloman | CMakeFiles/gstestclient.dir/gstestclient.o: In function `create_new_msg': |
| 14:48.38 | dloman | /home/dloman/devel/geomcore/trunk/src/GS/testclient/gstestclient.c:61: undefined reference to `uuid_generate' |
| 14:48.41 | dloman | /home/dloman/devel/geomcore/trunk/src/GS/testclient/gstestclient.c:63: undefined reference to `uuid_unparse' |
| 14:58.49 | CIA-14 | BRL-CAD: 03davidloman * r43870 10/brlcad/trunk/: Add some IDE (Eclipse) config files to svn:ignore. They are personal prefs and don't belong in the repo... ever. |
| 15:06.22 | CIA-14 | BRL-CAD: 03starseeker * r43871 10/geomcore/trunk/src/GS/testclient/CMakeLists.txt: Look for a UUID library |
| 16:14.53 | dloman | neat, visual SVN commit history: http://www.youtube.com/watch?v=rh7uo2gxLdA&feature=player_embedded#at=41 |
| 16:55.44 | CIA-14 | BRL-CAD: 03starseeker * r43872 10/geomcore/trunk/src/GS/testclient/ (tpl.c tpl.h): Hmm forgot to remove the executable bit from these |
| 16:57.08 | CIA-14 | BRL-CAD: 03starseeker * r43873 10/geomcore/trunk/src/GS/testclient/ (tpl.c tpl.h): Re-add without exe flag set |
| 17:33.16 | CIA-14 | BRL-CAD: 03starseeker * r43874 10/geomcore/trunk/src/GS/testclient/CMakeLists.txt: Hrm. Probably can't use tpl unless both client and server use it |
| 17:33.43 | CIA-14 | BRL-CAD: 03starseeker * r43875 10/geomcore/trunk/src/GS/testclient/ (tpl.c tpl.h): remove files too |
| 18:05.21 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 18:08.11 | CIA-14 | BRL-CAD: 03starseeker * r43876 10/geomcore/trunk/src/GS/testclient/gstestclient.c: Remove tpl.h include |
| 18:14.09 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 18:19.10 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 18:23.47 | CIA-14 | BRL-CAD: 03bob1961 * r43877 10/brlcad/trunk/src/libged/rt.c: Fixed a Windows related bug in _ged_run_rt (i.e. no longer using a fixed size char array to hold the command for CreateProcess. |
| 19:26.25 | CIA-14 | BRL-CAD: 03starseeker * r43878 10/geomcore/trunk/src/GS/testclient/gstestclient.c: Sigh. give libpkg another try in the interests of time. This is still not the way to form the correct buffer for geomserv - serialization needs to work correctly for anything to happen. |
| 19:33.50 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 19:44.13 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 21:43.51 | *** join/#brlcad dli (~dli@dyn-216-212.wireless.concordia.ca) | |
| 22:46.33 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 23:01.39 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 03:30.37 | *** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net) | |
| 03:40.54 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 03:53.04 | *** join/#brlcad Nohla (~Nohla@64.76.19.227) | |
| 08:40.55 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 10:25.29 | *** join/#brlcad Stattrav (~Stattrav@122.172.6.40) | |
| 10:25.29 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:02.54 | *** join/#brlcad dnk-88 (dnk-88@79.170.106.89) | |
| 12:12.41 | *** join/#brlcad Stattrav (~Stattrav@122.172.6.40) | |
| 12:12.41 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:46.41 | starseeker | dloman: around? |
| 13:50.21 | CIA-14 | BRL-CAD: 03starseeker * r43879 10/brlcad/trunk/src/other/tcl/ (3 files in 2 dirs): Try and work around http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44981 for Tcl |
| 14:39.45 | CIA-14 | BRL-CAD: 03starseeker * r43880 10/brlcad/trunk/src/other/tcl/unix/configure.in: This flag apparently isn't supported by some versions of gcc on OSX... |
| 14:41.53 | CIA-14 | BRL-CAD: 03starseeker * r43881 10/brlcad/trunk/TODO: need to fix dem-g... |
| 14:45.21 | *** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de) | |
| 14:46.03 | CIA-14 | BRL-CAD: 03starseeker * r43882 10/brlcad/trunk/src/other/tk/unix/configure.in: Remove this flag from tk too. |
| 15:07.03 | CIA-14 | BRL-CAD: 03starseeker * r43883 10/brlcad/trunk/src/libdm/focus.c: Hmm - looks like we need the workaround in focus.c too |
| 15:07.29 | starseeker | confound it, that may not work after all... not getting redefined, must have been hidden by -w in src/other/tcl |
| 15:25.05 | starseeker | auugh, autotools is annoying... |
| 15:36.29 | CIA-14 | BRL-CAD: 03starseeker * r43884 10/brlcad/branches/cmake/ (9 files in 6 dirs): MFC r43883 |
| 17:30.43 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 17:39.22 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:42.35 | *** join/#brlcad dnk-88 (~dnk-88@79.170.106.89) | |
| 18:22.45 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 18:34.47 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 18:42.51 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 18:48.21 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 18:53.22 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 18:59.57 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 19:05.07 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 20:10.37 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 21:30.15 | CIA-14 | BRL-CAD: 03starseeker * r43885 10/geomcore/trunk/src/GS/testclient/gstestclient.c: This all needs to go in as one buffer... |
| 21:35.54 | *** join/#brlcad dli (~dli@dyn-216-243.wireless.concordia.ca) | |
| 21:56.40 | CIA-14 | BRL-CAD: 03starseeker * r43886 10/brlcad/trunk/src/other/iwidgets/generic/scrolledwidget.itk: Use ttk scrollbars in iwidgets |
| 22:06.29 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 22:12.21 | *** join/#brlcad dli (~dli@dyn-216-243.wireless.concordia.ca) | |
| 22:36.24 | *** join/#brlcad micges (~ddd@bxq170.neoplus.adsl.tpnet.pl) | |
| 22:40.44 | *** part/#brlcad micges (~ddd@bxq170.neoplus.adsl.tpnet.pl) | |
| 23:13.38 | brlcad | the food here is so awesome |
| 23:13.56 | brlcad | burps and awol for a lil while longer |
| 02:45.26 | *** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net) | |
| 03:22.24 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 09:44.57 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 10:31.38 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:30.00 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 15:18.58 | CIA-14 | BRL-CAD: 03starseeker * r43887 10/brlcad/branches/cmake/src/other/iwidgets/generic/scrolledwidget.itk: MFC r43886 |
| 15:21.38 | CIA-14 | BRL-CAD: 03starseeker * r43888 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Enable 'q' for quit in Archer |
| 16:13.12 | CIA-14 | BRL-CAD: 03starseeker * r43889 10/geomcore/trunk/src/GS/testclient/gstestclient.c: Another failed attempt at packing and sending a gsnet msg |
| 18:44.23 | *** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net) | |
| 19:52.00 | *** join/#brlcad flyanarchy (~chatzilla@46.112.188.170) | |
| 19:52.55 | *** part/#brlcad flyanarchy (~chatzilla@46.112.188.170) | |
| 20:29.06 | yukonbob_ | yay BRL-CAD!!1! |
| 20:29.19 | yukonbob_ | congratulations on Yet Another GSoC :) |
| 20:29.28 | starseeker | hmm? |
| 20:29.32 | starseeker | did they announce something? |
| 20:29.41 | yukonbob_ | http://www.google-melange.com/gsoc/program/accepted_orgs/google/gsoc2011 |
| 20:30.58 | starseeker | hmm - cant' get it to load |
| 20:31.05 | starseeker | yukonbob_: thanks for the news! |
| 20:31.27 | starseeker | woo-hoo! |
| 20:31.33 | yukonbob_ | of course :) |
| 20:31.50 | starseeker | apparently I wrote fast enough last week :-P |
| 20:32.08 | yukonbob_ | now to find out how many positions are allotted... |
| 20:34.11 | starseeker | we'll have to wait til brlcad sobers up :-P |
| 20:35.40 | starseeker | hehe - Google Open Source Programs Office is listed as an organization |
| 20:35.49 | starseeker | now THAT's an "inside track" :-P |
| 20:36.49 | starseeker | hmm - CGAL is accepted too |
| 20:37.06 | starseeker | there'll be some competition for the geometry-aware students |
| 20:37.18 | dli | good job |
| 20:37.41 | dli | support for how many students? |
| 20:37.46 | starseeker | Aha - Isabelle is listed. Wonder if that's the theorem prover |
| 20:37.53 | starseeker | dli: don't know yet |
| 20:38.11 | starseeker | sweet - hugin is back |
| 20:38.40 | starseeker | LibreOffice too - wonder what ideas they're pitching for students. |
| 20:40.06 | dli | Theoretical Biophysics @ Humboldt University , this one is weird |
| 20:40.13 | dli | google supporting university directly |
| 20:40.26 | starseeker | dli: Google's been pretty good about supporting scientific stuff in the past |
| 20:40.40 | starseeker | ah, here we go: http://wiki.documentfoundation.org/Development/Gsoc/Ideas |
| 20:41.04 | starseeker | R Stastical program is good to see there - that's a nice tool |
| 20:41.58 | starseeker | Ah, OGRE too - wonder if some student will volunteer to replace FreeImage... |
| 20:42.32 | starseeker | Rockbox! sweet |
| 20:48.07 | Ralith | rockbox is still alive, huh? |
| 22:28.19 | starseeker | runs rockbox on his ipod |
| 23:12.20 | willdye | Congrats on making the Google Summer of Code. |
| 23:52.12 | Ralith | ran it on his old iriver |
| 23:52.17 | Ralith | was awesome but slightly unstable |
| 23:52.23 | Ralith | playing doom on it was hilarious, though |
| 01:13.03 | *** join/#brlcad niels_horn (~niels@189.106.85.17) | |
| 01:14.32 | niels_horn | Hi. I'm having an issue building brlcad 7.18.2 on Slackware (I'm the package maintainer of brlcad on Slackware) |
| 01:16.16 | niels_horn | it complains in /src/conv/patch/patch-g.c when buildind |
| 01:16.28 | niels_horn | *building |
| 01:17.35 | niels_horn | The message is [xxx] "may be used uninitialized in this function" |
| 01:18.46 | niels_horn | in line 1936, where [xxx] = abi, aci or adi |
| 01:19.56 | niels_horn | I "solved" it with a sed command in the SlackBuild script (=build script) |
| 01:20.33 | niels_horn | sed -i "/patch_g_CFLAGS/s|\${STRICT_FLAGS}||" src/conv/Makefile.in |
| 01:21.11 | niels_horn | essentially removing the "${STRICT_FLAGS}" for patch-g.c |
| 01:21.37 | niels_horn | (sorry for the flood...) Any comments or suggestions? |
| 01:28.26 | dli | niels_horn, it's a known issue. do ./configure --disable-strict-build |
| 01:33.51 | niels_horn | dli: great, will try that... |
| 01:34.20 | niels_horn | is there a forum or any place to find the "known issues"? :) |
| 01:35.03 | dli | niels_horn, I don't know. just come here. people are quite supportive for end users |
| 01:35.38 | niels_horn | dli: ok, np... I hang out on freenode for the other channels anyway... Thanks! |
| 04:10.43 | *** part/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 04:20.20 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 05:56.20 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 07:22.25 | *** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net) | |
| 07:51.55 | *** join/#brlcad Stattrav (~Stattrav@122.172.6.40) | |
| 07:51.55 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:29.00 | *** join/#brlcad CIA-52 (~CIA@208.69.182.149) | |
| 14:00.45 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.188) | |
| 14:00.46 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:23.12 | ``Erik | swank, we're back in gsoc |
| 15:26.17 | ``Erik | niels_horn: I maintain the fbsd port with a reasonable amount of vigor, http://www.freebsd.org/cgi/cvsweb.cgi/ports/cad/brlcad/ for hints, and if you have any questions/concerns/issues, make some noise and we'll respond, usually within a few hours :) |
| 15:28.55 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.188) | |
| 15:28.55 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:37.58 | niels_horn | ``Erik: OK, thanks. I'll take a look there later! |
| 15:38.50 | ``Erik | sure, and I read all the backlog, so just be patient waiting for a response :) |
| 15:39.16 | niels_horn | OK, np... :) |
| 18:24.26 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.188) | |
| 18:24.26 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:47.23 | *** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no) | |
| 20:40.48 | *** join/#brlcad Jesselnz (~jesse@ool-435573a5.dyn.optonline.net) | |
| 22:07.19 | *** join/#brlcad jarray52 (~bigbear@c-98-228-150-135.hsd1.in.comcast.net) | |
| 22:27.32 | *** part/#brlcad jarray52 (~bigbear@c-98-228-150-135.hsd1.in.comcast.net) | |
| 00:21.07 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 05:53.56 | *** join/#brlcad Stattrav (~Stattrav@117.192.147.2) | |
| 05:53.56 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:25.24 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:42.10 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 08:20.48 | *** join/#brlcad merzo (~merzo@237-129-133-95.pool.ukrtel.net) | |
| 09:04.47 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 14:40.07 | *** join/#brlcad Stattrav (~Stattrav@117.192.147.2) | |
| 14:40.07 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:46.26 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:10.11 | *** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 17:53.27 | *** join/#brlcad Stattrav (~Stattrav@117.192.147.2) | |
| 17:53.27 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:07.27 | *** join/#brlcad Stattrav (~Stattrav@117.192.147.2) | |
| 18:07.28 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:17.10 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:31.21 | *** join/#brlcad Stattrav (~Stattrav@117.192.147.2) | |
| 18:31.21 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:42.11 | *** join/#brlcad Stattrav (~Stattrav@117.192.147.2) | |
| 18:42.11 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:50.21 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 20:31.51 | *** join/#brlcad Jesselnz (~jesse@ool-435573a5.dyn.optonline.net) | |
| 20:33.52 | Jesselnz | I'm hoping to participate in Google Summer of Code, and my idea is to implement a DWG importer based on LibreDWG. I'd appreciate some feedback on how valuable such a tool would be, and whether or not this could viably get accepted as a GSoC project. |
| 20:43.30 | brlcad | hello Jesselnz |
| 20:43.40 | Jesselnz | Hi |
| 20:43.57 | brlcad | the idea sounds interesting, but the approach using libredwg is a problem (for us) |
| 20:44.08 | Jesselnz | Why is that? |
| 20:44.09 | brlcad | license is no good for integration |
| 20:45.20 | brlcad | that library is GPL, so any tool developed against it would also need to be GPL or go through obtuse release integration steps making it practically infeasible |
| 20:45.48 | brlcad | there are plenty of other, more interesting, converters needed -- is that your only interest? |
| 20:46.17 | Jesselnz | Doesn't BRL-CAD have different components released under the GPL and BSD licenses? |
| 20:46.25 | Jesselnz | At least, that's the impression I was under. |
| 20:47.27 | Jesselnz | What other converters are needed? |
| 20:47.35 | brlcad | Jesselnz: the majority of source code is LGPL, build system and data files are BSD |
| 20:48.53 | brlcad | the main ones desired is a step exporter, improving our step importer, and updating our existing iges importer/exporter |
| 20:49.33 | Jesselnz | Alright, thanks. I'll look into those. |
| 20:50.01 | brlcad | others are listed here: http://brlcad.org/~sean/ideas.html |
| 20:51.43 | brlcad | Jesselnz: if you're inspired, we're REALLY interested in code refactoring/cleanup projects -- one of which is establishing a code conversion library |
| 20:52.31 | brlcad | nuts and bolts infrastructure |
| 20:53.20 | brlcad | e.g., turning our 20+ existing converters into library API with 100% clean common code reuse instead of self-contained binaries like they are now |
| 20:53.53 | Jesselnz | Sure, that sounds like an interesting project. |
| 20:54.51 | brlcad | if it's done perfectly, you wouldn't necessarily end up with an end-user visible change other than maybe some subtle consistency cleanup across converters |
| 20:55.36 | brlcad | more details at http://brlcad.org/wiki/Geometry_Conversion_Library from our Project Ideas page |
| 20:58.51 | *** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 ETA 20110321 || BRL-CAD is participating in the 2011 Google Summer of Code! Students: speak up, ask quesions! :) | |
| 20:58.57 | Jesselnz | I'll definitely look into it. Thanks for the suggestion. |
| 20:59.02 | brlcad | no problem |
| 21:00.11 | brlcad | starseeker: CGAL has been participating for the past 2-3 years goo, not direct competition usually due to their funky license problems |
| 21:00.45 | brlcad | willdye: thanks |
| 21:11.30 | brlcad | mmm, so I see nobody sync'd to trunk and posted the release! |
| 21:21.35 | brlcad | hah, gource uses ftgl |
| 23:23.48 | starseeker | hates global variables... grr... |
| 23:24.27 | brlcad | kill them! |
| 23:26.45 | starseeker | is trying, but it's not in our codebase |
| 23:26.57 | brlcad | this is freaking awesome |
| 23:27.07 | brlcad | pulling up a visualization of brl-cad source history |
| 23:27.13 | starseeker | cool! |
| 23:27.28 | starseeker | brlcad: back I take it? how was it? |
| 23:27.38 | brlcad | awesome |
| 23:27.57 | starseeker | hehe - welcome back to the letdown that is american food |
| 23:28.53 | starseeker | what's the visualization? |
| 23:31.16 | starseeker | scowls at sqlite... don't tell me... |
| 23:34.52 | starseeker | hrm. No wonder they were using a global, that commit_hook doesn't pass any info... |
| 23:35.41 | starseeker | ah, wait |
| 23:35.56 | starseeker | pCommitArg... what's that... |
| 23:38.32 | starseeker | bingo |
| 01:04.12 | *** join/#brlcad Nohla (~Nohla@64.76.19.227) | |
| 04:16.11 | starseeker | O.o https://github.com/pyb/zen |
| 04:16.26 | starseeker | too bad it's GPL, but that's still nifty |
| 06:57.52 | Ralith | oo, neat |
| 06:58.08 | Ralith | mightn't it be better to target that X replacement canonical is backing though? |
| 07:37.49 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 07:42.48 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 09:07.45 | *** join/#brlcad Stattrav (~Stattrav@122.172.6.40) | |
| 09:07.45 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:03.06 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 11:10.21 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 11:32.13 | dloman | Mernin |
| 11:36.54 | dloman | brlcad: gource is a fun little tool =D |
| 11:37.20 | dloman | brlcad: did you do all of the brlcad commit history? If, so, I'd love to see the visualization! |
| 12:30.18 | brlcad | dloman: yeah, the whole thing -- had to modify the source to get it to behave, but it works reasonably well |
| 12:31.29 | brlcad | the physics unfortunately goes nuts with the whole tree causing the graph to get stuck |
| 12:37.22 | dloman | so did it turn out at all? |
| 12:37.54 | brlcad | oh yeah, it works great "most" of the time |
| 12:38.27 | brlcad | it might work if it's allowed to incrementally build up from scratch |
| 12:38.52 | brlcad | it'll rebuild the tree from any point on the timeline, which is how you skip forward/backward .. and those tend to get stuck |
| 12:39.01 | brlcad | trying to rebuild the massive tree after massive edits |
| 12:39.18 | dloman | cool, drop something on youtube if/when you get a chance :) |
| 12:39.31 | brlcad | haven't found a good way to capture to video yet |
| 12:40.21 | brlcad | plus, even sped up to about 4days per sec, it's still like a half-hour video :) |
| 12:40.38 | brlcad | any faster and it's just a ton of whizzing about |
| 12:41.00 | dloman | tee hee |
| 12:43.55 | starseeker | hah, that is cool |
| 12:44.12 | starseeker | like how it uses the little figures to indicate who's changing what |
| 12:45.20 | starseeker | brlcad: if you could capture video(s), that'd be a really cool briefing tool |
| 12:45.32 | starseeker | dloman: you in today? |
| 12:46.08 | brlcad | starseeker: I'm working on getting video .. I have one video screencast tool working, but it's shareware and watermarks the video |
| 12:46.31 | brlcad | the tool itself will output ppm that would be a hell of a lot of frame data |
| 12:46.44 | starseeker | brlcad: ah. I think I stumbled on one or two tools that do opengl video specifically |
| 12:47.18 | starseeker | http://taksi.sourceforge.net/ |
| 12:47.31 | brlcad | just found that :) |
| 12:48.24 | brlcad | the question du jour is whether it'll run .... bah, looks like it's windows only? |
| 12:48.47 | brlcad | dloman: so we're good to go needing a poster ;) |
| 12:49.08 | brlcad | one page of awesome |
| 12:49.10 | dloman | starseeker: not today no, tomorrow. Whats up? |
| 12:49.16 | starseeker | yukon might be an option: https://devel.neopsis.com/projects/yukon/ |
| 12:49.38 | starseeker | dloman: I'm wondering how close we are to having commands in geomclient that could retrieve and send .g files |
| 12:49.47 | dloman | brlcad: I can work on it *after* march 31 =D |
| 12:49.51 | dloman | close. |
| 12:50.03 | brlcad | oh, that's way too late :( |
| 12:50.07 | dloman | can't promise COB today, but def by COB tomrrrow |
| 12:50.39 | Ralith | looks like gource can output a ppm stream itself |
| 12:50.46 | Ralith | which could then be encoded |
| 12:50.47 | starseeker | is trying to remember if yukon is how he made the videos of g3d... |
| 12:51.07 | brlcad | Ralith: 08:46 < brlcad> the tool itself will output ppm that would be a hell of a lot of frame data |
| 12:51.27 | brlcad | missing a 'but' in there |
| 12:51.47 | dloman | brlcad: sorry, but RL has kicked me square in the nuts and I have had to take a lot of time off... so i am behind with the GS. |
| 12:54.21 | brlcad | someone else will have to come up with something then, hopefully |
| 12:54.22 | Ralith | that's what I get for not keeping up. |
| 12:54.24 | brlcad | students are submitting applications by the 28th, so that's just way too late |
| 12:54.31 | Ralith | still, too much data? |
| 12:55.24 | starseeker | brlcad: ah - https://devel.neopsis.com/projects/yukon/wiki/RewriteBranch |
| 12:55.36 | brlcad | looks |
| 12:56.51 | brlcad | starseeker: looks like that only works with x11 glx contexts? |
| 12:57.36 | starseeker | possibly |
| 12:57.56 | brlcad | I'd hate to go through all the steps again, but I might be able to crunch the frames out on a remote linux box with tons of disk, and convert to video there |
| 12:58.53 | brlcad | it was just a bit of a time sink to compile with all its deps, paying some lil shareware dev becomes appealing :) |
| 12:58.55 | starseeker | nods - surprisingly, there just aren't a whole lot of good solutions (that I know of, anyway) |
| 13:01.25 | starseeker | dloman: do you think you could spare a little time from the java side to get the .g files moving back and forth? |
| 13:04.25 | dloman | that's what Im doing ;) |
| 13:04.36 | starseeker | dloman: cool, thanks :-) |
| 13:05.06 | starseeker | got his butt kicked by a bunch of topics he knows disturbingly little about last week - sorry for not being of more concrete assistance |
| 13:05.21 | dloman | no worries |
| 13:05.33 | dloman | i havent exactly been productive recently |
| 13:06.04 | starseeker | dloman: that's not up to you - hope everything is going a little bette |
| 13:06.07 | starseeker | better even |
| 13:07.54 | dloman | heh, its when things start going better that i get scared. Murphey and his laws are having a field day ;) |
| 13:09.07 | dli | starseeker, like undo/redo? |
| 13:09.25 | starseeker | dli: how's that? |
| 13:09.53 | dli | starseeker, when you mentioned 'moving back and forth' |
| 13:10.31 | starseeker | dli: the most basic function of any client/server system is to communicate between client and server |
| 13:10.53 | dloman | brlcad: is there a quick way to print a bu_vlb to console or string as HEX ? |
| 13:11.01 | starseeker | dli: we have that (thanks to dloman) but we need to be able to send geometry back and forth |
| 13:11.29 | starseeker | dli: once we can communicate geometry files, we can think about how to store revisions of them |
| 13:12.15 | starseeker | dli: the next stage beyond that is to communicate just specific changes to parts of the .g files, and be able to retrieve specific versions of geometry from the server |
| 13:12.27 | starseeker | dli: the latter means revision control and is not easy |
| 13:13.31 | starseeker | dloman: yeah, if I ever run into Murphy I'm gonna have a word with him... |
| 13:13.51 | dli | starseeker, not easy with .g format :( maybe, easier as database entries |
| 13:14.31 | starseeker | dli: basically what's needed is to customize version control software for our specific purposes |
| 13:16.41 | starseeker | gathers up his stuff and heads in - first stop gym... |
| 13:25.09 | ``Erik | unsigned char *p = bu_vlb_addr(myvlb); for(i=0;i<bu_vlb_buflen(myvlb);i++){ printf("%02x ",*p); p++; } |
| 13:28.07 | dloman | ``Erik: thanks |
| 13:30.37 | ``Erik | (there're tricks to make that shorter, but starseeker starts sobbing when I do those) |
| 13:36.08 | CIA-52 | BRL-CAD: 03brlcad * r43890 10/brlcad/trunk/src/libbu/bitv.c: don't try to cat the str/title if it is null |
| 13:38.37 | CIA-52 | BRL-CAD: 03brlcad * r43891 10/brlcad/trunk/ (include/bu.h src/libbu/vlb.c): |
| 13:38.37 | CIA-52 | BRL-CAD: add a new bu_pr_vlb() routine for printing out diagnostic information for vlb |
| 13:38.37 | CIA-52 | BRL-CAD: structures. optionally prefixed with a title, this prints out each byte as a |
| 13:38.37 | CIA-52 | BRL-CAD: space-separated hex value. could probably use some pretty printing to group |
| 13:38.38 | CIA-52 | BRL-CAD: together for readability, but go simple for starters. |
| 13:38.55 | brlcad | dloman: turned erik's one-liner into a new bu routine, bu_pr_vlb(), see if that's suitable |
| 13:40.43 | dloman | kk will try |
| 13:40.44 | brlcad | dli: unless I missed part of the conversation, it's not specific to .g data |
| 13:41.34 | brlcad | the service allows transactional edits with history preserved, so it's just a matter of how to encode the transactions as commits |
| 13:42.55 | brlcad | the simple way is to commit the honking .g file after each change, but that's not really efficient since it's an opaque entity to revision control systems - it's not easy to extract the semantic differences between two changes |
| 13:47.42 | dli | brlcad, does it make sense to use a database backend, so, database queries can be logged (reverted), efficiency problem left to the database side |
| 13:48.26 | brlcad | that's basically what's being done with the revision control system -- it uses a database backend |
| 13:49.23 | dli | brlcad, oh, didn't realize that :( |
| 13:49.37 | brlcad | we could implement revision tracking on top of some existing rdbms, but then that would basically amount to reimplementing a version control system (like git, svn, whatever) |
| 13:50.09 | brlcad | and even then, you'd still have the problem of storing/retrieving *semantic* information from the commit |
| 14:00.13 | CIA-52 | BRL-CAD: 03davidloman * r43892 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ (GSConnection.java msg/AbstractNetMsg.java): Move message serialization entirely over to AbstractNetMsg. Consolidates serialization logic. |
| 14:16.44 | *** join/#brlcad Nohla (~Nohla@64.76.19.227) | |
| 14:26.42 | CIA-52 | BRL-CAD: 03davidloman * r43893 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/AbstractNetMsg.java: Forgot to serialize type. Ooops. |
| 14:27.22 | CIA-52 | BRL-CAD: 03davidloman * r43894 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: Remove debug printing. Kills performance when trying to print large bytebuffers. |
| 14:27.54 | brlcad | could maybe add a size parameter |
| 14:28.30 | dloman | it was a t-shooting debug print statement anyways :) |
| 14:28.48 | dloman | turns out, printing a 1 meg byte array to console is slow. who knew?! |
| 14:32.23 | brlcad | probably someone ;) |
| 14:32.33 | dloman | most likely everyone :) |
| 14:54.58 | ``Erik | a lot faster if you dump it in a screen and swap, or pipe through less O.o the effort to display a linux kernel build in an xterm was a significant slowdown on my old 120mhz cyrix, went way faster when I put it in a screen and dropped it :) |
| 14:56.41 | dloman | now that's a new one. localhost just resolved to 127.0.1.1 |
| 14:57.07 | ``Erik | neat |
| 16:02.17 | dloman | oh bloody hell. the silly null character at the end of the string has the UUID parsing all bent out of shape :/ |
| 16:06.35 | CIA-52 | BRL-CAD: 03davidloman * r43895 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ByteBufferReader.java: Validate parsed string is == 36 characters long to allow for proper UUID generation. The UUID 'standard' for the GSNet Proto needs to be standardized. |
| 16:09.50 | CIA-52 | BRL-CAD: 03davidloman * r43896 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/NetMsgFactory.java: Fill out the NetMsgFactory's switching table so that NetMsg's can actually be deserialized |
| 17:13.07 | CIA-52 | BRL-CAD: 03starseeker * r43897 10/brlcad/trunk/BUGS: Need to do some testing and confirm this, but have a report that keep is changing units to unknown on output files and dbconcating a file with unknown units wipes out the units in the parent .g |
| 17:34.55 | *** join/#brlcad Stattrav (~Stattrav@117.192.135.62) | |
| 17:34.56 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:02.45 | *** join/#brlcad chinu (~chinu@27.97.161.172) | |
| 19:11.32 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.134.3) | |
| 19:26.47 | *** join/#brlcad chinu (~chinu@27.97.124.40) | |
| 19:28.15 | *** join/#brlcad sofichinu (~sofichinu@27.97.124.40) | |
| 19:46.10 | sofichinu | hii all, can anyone help me out for gsoc 2011 project idea - Qt Display Manager |
| 19:47.13 | starseeker | sofichinu: you've seen the posting on the website? |
| 19:48.27 | starseeker | http://brlcad.org/wiki/Qt_Display_Manager |
| 19:51.12 | sofichinu | yes i have gone through that link, and it says to review current display manager code. From where do i get to access that code? |
| 19:51.36 | starseeker | BRL-CAD's subversion repository: http://sf.net/projects/brlcad |
| 19:51.48 | starseeker | specifically, the trunk branch: |
| 19:52.01 | starseeker | svn co https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/trunk brlcad |
| 19:52.42 | starseeker | also a good idea to get BRL-CAD (specifically MGED) compiled and running to see what a display manager does |
| 19:52.46 | sofichinu | thnx :) |
| 19:52.58 | starseeker | no problem |
| 19:56.01 | sofichinu | do one has to use any ide for compiling the code, because I usually use g++ compiler in ubuntu for coding in c++ |
| 19:56.23 | starseeker | nope - most of use go with command line gcc |
| 19:57.10 | sofichinu | ok |
| 19:57.48 | starseeker | sofichinu: you have Qt experience? |
| 19:59.11 | sofichinu | nopes, I started using it only after getting to know about it via gsoc |
| 19:59.33 | starseeker | nods. Just curious - what appealed to you about that project? |
| 20:01.08 | sofichinu | to be honest , requirement skills for the project is C++ and I am good at this only :P |
| 20:01.46 | sofichinu | this all made me interested in this |
| 20:02.00 | starseeker | fyi, OGRE is also C++ |
| 20:03.17 | sofichinu | yes, many other organizations are, and I am trying to go deep into project ideas to find out which one is best for me. |
| 20:03.35 | starseeker | I was thinking more about the other display manager task - the OGRE display manager :-P |
| 20:04.10 | sofichinu | oh i am sorry, |
| 20:04.19 | sofichinu | I had started using Qt |
| 20:04.29 | starseeker | the openNURBS library is also C++, if you're into mathematical stuff |
| 20:04.33 | starseeker | sofichinu: Qt is fine too |
| 20:04.34 | sofichinu | before and heard about OGRE now only |
| 20:04.48 | starseeker | we're interested in both - if you're more comfortable with Qt that's great |
| 20:05.28 | starseeker | openNURBS would pertain to the NURBS tasks on that list |
| 20:06.24 | sofichinu | which one gives more chance for getting into gsoc ? |
| 20:06.38 | starseeker | depends on your proposal and the other proposals |
| 20:07.02 | starseeker | Qt vs. OGRE won't be a make-or-break |
| 20:07.09 | sofichinu | hm... |
| 20:08.30 | sofichinu | do i need to make out some patch like usually many organizations demand that? |
| 20:08.31 | starseeker | sofichinu: I'd suggest taking a quick look at both and see which one looks more managable to you |
| 20:09.18 | starseeker | see step 9: http://brlcad.org/wiki/Google_Summer_of_Code/Checklist |
| 20:10.21 | starseeker | sofichinu: what's your background/interest? |
| 20:11.07 | sofichinu | I am a student of 2nd year in Computer Science and Engineering |
| 20:13.20 | starseeker | well, my advice would be to take a very quick look at Qt and OGRE - get a basic window up and draw a line, say, in both - just to get a feel which one you would prefer working with |
| 20:14.55 | sofichinu | ok |
| 20:15.39 | starseeker | OGRE is an accelerated 3D context, and Qt is unaccelerated but runs (or should run) pretty much anywhere without requiring any fancy hardware |
| 20:16.09 | starseeker | sort of the difference between our dm-ogl and dm-X |
| 20:16.44 | starseeker | (which is why OpenGL embedded in Qt is ruled out - the point of a Qt display manager would be "it always works") |
| 20:17.03 | sofichinu | sorry but i did not get the difference still. |
| 20:17.55 | starseeker | OpenGL provides an accelerated graphics context - when you see objects rotating around in real time in 3D, it's usually OpenGL based (unless you're on Windows, which tends to use DirectX more these days) |
| 20:18.15 | starseeker | typically, the graphics card in the computer is assisting with the drawing when OpenGL is used |
| 20:18.42 | starseeker | Raw X11 (dm-X) does NOT use any specialized acceleration hardware - it uses only the X calls themselves |
| 20:19.41 | starseeker | which means the CPU has to do a lot of work instead of offloading it to the graphics card, but ALSO means if the graphics card (or drivers) aren't working you can still bring up the display |
| 20:20.29 | sofichinu | so can we say that Qt is better |
| 20:21.12 | starseeker | Qt will work under more conditions |
| 20:21.40 | starseeker | but it also won't be able to do things like shaded display and take advantage of graphics hardware when displaying really large models |
| 20:21.52 | starseeker | it's a tradeoff - that's why we're interested in both |
| 20:22.13 | starseeker | Ideally, you do accelerated when it's available and fall back to unaccelerated when it's not |
| 20:23.10 | sofichinu | hmm.... |
| 20:23.43 | starseeker | so Qt would be using the 2D graphics stack: http://cworth.org/talks/lca_2009/html/lca-2009-006.html |
| 20:23.57 | starseeker | and OGRE would be using the 3D http://cworth.org/talks/lca_2009/html/lca-2009-007.html |
| 20:24.23 | starseeker | (OK so those are Linux specific, but the general idea is the same) |
| 20:25.40 | sofichinu | and what about in windows terms |
| 20:27.12 | starseeker | The Windows stacks look similar, just with different components at the various stages |
| 20:27.14 | starseeker | (e.g. DirectX instead of OpenGL) |
| 20:27.24 | starseeker | OGRE and Qt should abstract all that for us |
| 20:27.38 | sofichinu | ok |
| 20:28.29 | sofichinu | cant we implement the similar thing for OpenGL too? |
| 20:28.35 | starseeker | sofichinu: I'd try playing with QtCanvas and see how it behaves - for example, can you get it to draw and update 2D lines quickly? |
| 20:29.01 | starseeker | sofichinu: we can (in fact, we do - that's dm-ogl and dm-wgl) but OpenGL itself is not a fully cross platform API |
| 20:29.36 | starseeker | that's why we have one for wgl (Windows), one for GLX (Linux), and we would need one for Mac if we wanted to get the native Aqua interface running |
| 20:30.33 | sofichinu | oh, I am actually downloading Qt, for sum reasons, I lost it |
| 20:31.14 | starseeker | Ideally, we would replace all of the platform specific display managers with one accelerated (OGRE) and one unaccelerated (Qt) display manager - between those two, we should get broad coverage of machine configurations and operating systems for minimal code |
| 20:32.34 | starseeker | My guess would be that the main challenge with Qt will be figuring out how to do "fast enough" 2D drawing without relying on OpenGL |
| 20:33.22 | dli | or ogre simply figure out how to run without no 3d support underneath |
| 20:33.54 | starseeker | dli: that's a bit like saying you're going to figure out how to drive without a car :-P |
| 20:34.22 | dli | starseeker, yes, because a bike is always available |
| 20:34.54 | starseeker | the main point and benefit of OGRE is that it does take advantage of 3D acceleration |
| 20:35.57 | starseeker | if someone wants to propose an alternative toolkit for either the unaccelerated or the accelerated display manager that's fine, but they'll need to make a very good case for it |
| 20:37.40 | starseeker | issues to consider there are license compatibility, portability, how well maintained and widely used the toolkit is, etc. |
| 20:38.34 | starseeker | we don't want to take over maintainance for a cross platform graphical toolkit - we want to use one that is already in good shape |
| 20:39.02 | starseeker | OGRE and Qt have a lot of momentum behind them and are licensed in a way we can use them |
| 20:39.51 | sofichinu | Its just like making a best deal from both of them. |
| 20:46.57 | starseeker | sofichinu: this may be of interest: http://labs.qt.nokia.com/2009/12/16/qt-graphics-and-performance-an-overview/ |
| 20:52.30 | *** join/#brlcad niels_horn (~niels@187.14.62.166) | |
| 22:32.38 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 22:32.38 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 ETA 20110321 || BRL-CAD is participating in the 2011 Google Summer of Code! Students: speak up, ask quesions! :) | |
| 23:23.12 | brlcad | thinks we're good with a simple socket connection for the forseeable next couple years |
| 23:23.54 | brlcad | local port performance is going to be the main customer at first, not even over tcp, for the beginning (e.g., mged use) |
| 23:24.57 | brlcad | getting beyond that and I'd want to start considering more advanced network services like automatic replication and persistance .... but only long after the protocol is established for simple net |
| 00:24.54 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2609 10/wiki/Google_Summer_of_Code: /* [[Google_Summer_of_Code/2009|GSoC 2011]] */ |
| 00:25.09 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2610 10/wiki/Google_Summer_of_Code: accepted |
| 00:29.33 | brlcad | in theory, you should be able to get an accelerated and non-accelerated context from both Qt and OGRE -- it's really just what toolkit does someone want to use and which one will integrate best (be easiest to maintain) |
| 00:30.21 | *** join/#brlcad Ralith (~ralith@d142-058-172-039.wireless.sfu.ca) | |
| 00:30.42 | brlcad | e.g., qt with an ogl context could be accelerated or it could be a pure raster context; ogre might be harder to get unaccelerated, but there's always software render ogl :) |
| 00:32.41 | starseeker | ah, ok - I had assumed we would want to go with something like OGRE for accelerated in order to support more advanced work to come |
| 00:37.59 | CIA-52 | BRL-CAD: 03starseeker * r43898 10/geomcore/branches/fossil/: Add a branch for some experiments |
| 00:38.43 | brlcad | ogl for the dm definitely makes the most sense |
| 00:38.55 | brlcad | something that has scenegraph management |
| 00:38.58 | starseeker | plain opengl? |
| 00:39.18 | brlcad | plain ogl with custom scenegraph management is a bitch |
| 00:39.33 | brlcad | that's where ogre becomes a big win over qt for the dm side |
| 00:39.41 | brlcad | for the fb side, either would be a win |
| 00:39.48 | brlcad | fossil scm? |
| 00:39.48 | starseeker | oh, you mean OGRE for the dm? |
| 00:39.54 | starseeker | yes |
| 00:39.59 | brlcad | heh, neat |
| 00:40.06 | starseeker | BSD licensed as of mid last year |
| 00:40.16 | brlcad | nods |
| 00:40.22 | starseeker | I didn't notice at the time - would have hopped on it quicker |
| 00:40.35 | brlcad | you know it's almost entirely built on sqlite? |
| 00:40.37 | starseeker | yep |
| 00:41.30 | starseeker | wasn't so worried about its backend storage mechanism as long as it doesn't cause us some kind of significant trouble |
| 00:42.06 | starseeker | more annoying is his fondness for global variables |
| 00:42.12 | starseeker | that's what I was grousing about earlier |
| 00:47.40 | CIA-52 | BRL-CAD: 03starseeker * r43899 10/geomcore/branches/fossil/ (17 files in 6 dirs): For now, clear other contents - keep the build logic simple during early phases. |
| 00:53.22 | CIA-52 | BRL-CAD: 03starseeker * r43900 10/geomcore/branches/fossil/ (48 files in 8 dirs): |
| 00:53.22 | CIA-52 | BRL-CAD: Add what work has been done so far - the first goal is to get db.c and |
| 00:53.22 | CIA-52 | BRL-CAD: everything it needs compiling without warnings about implicit definitions. No |
| 00:53.22 | CIA-52 | BRL-CAD: global 'g' structure with settings either - pass it properly, even if it does |
| 00:53.22 | CIA-52 | BRL-CAD: mean updating all the functions to do it. |
| 01:08.11 | CIA-52 | BRL-CAD: 03starseeker * r43901 10/geomcore/branches/fossil/ (CMakeLists.txt src/CMakeLists.txt): comment out dirs not active yet |
| 01:15.41 | CIA-52 | BRL-CAD: 03starseeker * r43902 10/geomcore/branches/fossil/ (3 files in 2 dirs): add a content.h header to manifest and diff, fix accordingly. |
| 01:56.57 | brlcad | ah, yeah |
| 01:57.20 | brlcad | it's endemic of fast but lazy coding |
| 01:57.54 | brlcad | great for getting things done, but crazy maintainability for new developers |
| 01:58.32 | starseeker | my favorite bit is he generates the headers based on what the .c files need |
| 01:59.40 | starseeker | brlcad: is sqlite a concern? |
| 02:00.02 | brlcad | nope |
| 02:00.25 | starseeker | breaths a sigh of relief |
| 02:00.31 | brlcad | implementation detail that might affect scalability, but not a problem until it's a problem |
| 02:01.16 | brlcad | have trouble seeing it scale to multiGB databases, but maybe |
| 02:01.33 | starseeker | yeah, huge meshes could be a problem |
| 02:01.50 | brlcad | single models could be a problem |
| 02:02.06 | brlcad | not to even consider hundreds or thousands |
| 02:02.45 | starseeker | well, ``Erik has some wicked test cases we can toss in |
| 02:03.06 | starseeker | brlcad: I was kind of thinking one sqlite file per .g namespace... |
| 02:04.23 | starseeker | under the hood, of course |
| 02:04.31 | brlcad | single db by itself is probably fine, thinking db with full revision history, hundreds of edits like you'd have if you start from scratch - that's where it'd get big |
| 02:04.39 | brlcad | yeah, possibly |
| 02:04.48 | brlcad | that'd definitely be better than one honking db |
| 02:05.14 | brlcad | but then merging/branching and linking across namespaces becomes really nasty, no? |
| 02:05.23 | starseeker | ah, yeah - was thinking a few rotates and translates at the toplevel plus lots of xpushing for edit testing |
| 02:05.26 | brlcad | with svn it was just across files using path convention |
| 02:05.36 | brlcad | all still within the revision system |
| 02:06.09 | brlcad | either way, interesting test |
| 02:06.09 | starseeker | brlcad: not sure how nasty it would be - I've been thinking about it, but nothing concrete to toss on the whiteboard yet |
| 02:06.48 | brlcad | get stuck with svn libs? |
| 02:07.04 | brlcad | or looking for better performance? |
| 02:07.14 | brlcad | or just having fun? :) |
| 02:07.37 | starseeker | heh - combination of the latter two |
| 02:08.42 | starseeker | I was hoping a "speak .g language" approach to the revision control would let us avoid the region breakout and still have reasonable performance, but looking at that level of subversion/apr just got downright scary |
| 02:09.22 | starseeker | fossil appealed because it's smaller, distributed and for a bonus has that web server stuff integrated |
| 02:09.50 | starseeker | thought it might be more practical to get it commiting individual geometry objects as binary blobs and checking out into .g files |
| 02:10.45 | starseeker | however screwed up its "yay global variables" approach is, once straightened out it should build portably and without fun like the apr libs |
| 02:12.49 | brlcad | be sure to consider the big picture management advantages/disadvantages too then, user management isn't nearly as well integrated, generic properties, proven stability across massive dbs, repository mirroring, efficient binary management, .. ;) |
| 02:14.06 | starseeker | actually it does seem to have some user management abilities, although I haven't looked hard at that |
| 02:14.30 | starseeker | I'm assuming it's got to be fairly good at mirroring, being a dvcs... |
| 02:14.31 | brlcad | if performance were the only consideration, that new libgit toy would be a viable candidate |
| 02:14.38 | brlcad | it has user management |
| 02:14.41 | starseeker | <snort> I took a look at that |
| 02:14.45 | brlcad | it's not just nearly as well integrated |
| 02:14.46 | starseeker | doesn't have the feature set yet |
| 02:14.56 | brlcad | svn's is pretty extensive |
| 02:15.19 | brlcad | there's a whole lib dedicated to it that can be coupled to the various remote connection mechanisms |
| 02:15.55 | starseeker | brlcad: is user management a big deal at the revision control level? I thought user management stuff was gonna live higher up the food chain, but maybe I was wrong |
| 02:16.13 | brlcad | initial stab was a complete punt, just let svn do what it does |
| 02:16.32 | brlcad | anything we do higher up is just going to suck |
| 02:16.38 | starseeker | ah |
| 02:16.52 | brlcad | that's trickty to get right, even stupid username+password management |
| 02:17.14 | starseeker | fossil does have at least some capability for username+password |
| 02:17.20 | brlcad | it has to :) |
| 02:17.39 | brlcad | it's an unintegrated home-grown solution iirc |
| 02:18.12 | starseeker | yeah, it's self-containment is one of its selling points |
| 02:18.23 | brlcad | yep |
| 02:18.30 | brlcad | it's a plus and a negative tradeoff |
| 02:18.42 | brlcad | super limited, but super simple |
| 02:19.42 | brlcad | to me spells "super inadequate" for long-term without hacking a completely separate user management layer on top, but that's not a concern for a while |
| 02:20.00 | brlcad | it's worth testing regardless |
| 02:20.33 | brlcad | anything we implement shouldn't be so tightly integrated that we cannot switch out to a different versioning engine without a couple weeks effort |
| 02:21.48 | starseeker | my plan was to get it refactored/reworked to the point where I could directly pass it librt's db byte arrays as objects, and check them out into a .g file instead of files |
| 02:22.05 | starseeker | then see what performance was like |
| 02:32.48 | CIA-52 | BRL-CAD: 03starseeker * r43903 10/geomcore/branches/fossil/src/libgeomvcs/ (CMakeLists.txt checkin.c): Still problems with this file, but can't continue tonight - check in what I've got. |
| 02:33.50 | brlcad | starseeker: the scrolledwidget ttk fix .. is that from upstream? |
| 02:34.07 | brlcad | worth pushing to upstream? |
| 03:50.22 | starseeker | brlcad: if you can call it a "fix" - just going for uniform ttk usage when possible |
| 05:28.52 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 06:53.06 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 06:53.06 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:21.59 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 08:14.11 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 08:14.11 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:38.49 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 10:22.03 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 10:37.15 | dloman | Mernin all. |
| 10:50.16 | brlcad | so approximately 92 seconds of that 30min animation took up about 5GB of disk in image frames... think I'm going to need a bigger disk |
| 10:51.16 | brlcad | or I'm going to need to make a smaller animation (was aiming for 720p) |
| 10:52.23 | dloman | yikes. |
| 10:52.31 | dloman | that's totally raw image data i take it? |
| 10:53.12 | brlcad | basically, it's a ppm stream |
| 10:53.20 | dloman | at 5GB per 92 seconds, you're looking at about 100GB for the 30 min stretch. |
| 10:53.42 | dloman | I've got a 2TB external you can borrow if ya need :) |
| 10:54.18 | brlcad | yeah, which by itself isn't too shabby, except it's not exactly something I can upload to vimeo :) |
| 10:54.40 | brlcad | i'll figure something out |
| 10:56.22 | dloman | I have Adobe Premere elements and I *think* it can encode a ppm stream to something like mp4, avi, wmv, etc. |
| 10:56.26 | dloman | if ya need. |
| 10:57.33 | brlcad | that part I'm actually not worried about at all, plenty of ways to encode from the stream |
| 10:57.51 | brlcad | more the processing size and size of end result video |
| 10:58.33 | dloman | well, its not ideal, but you can always hack it into parts if its too big for upload. |
| 10:58.40 | brlcad | this should work.. just need to make some room :) |
| 10:59.14 | dloman | hehehe. |
| 10:59.45 | dloman | on that note: I am seriously considering picking up a pair of 2TB internals... time for some upgrading of the data server! |
| 11:00.28 | dloman | <Tangent> brlcad: Have you neard of a group called Improv Everywhere? |
| 11:06.49 | *** join/#brlcad sofichinu (~sofichinu@115.69.147.65) | |
| 11:15.10 | dloman | http://www.youtube.com/watch?v=lYJ9zOyzI4w&feature=player_embedded |
| 11:15.18 | dloman | That's the kinda stuff IE does :) |
| 11:15.25 | dloman | basically, hilarious stuff :) |
| 12:04.09 | CIA-52 | BRL-CAD: 03Tbrowder 07http://brlcad.org * r2611 10/wiki/Google_Summer_of_Code/Project_Ideas: |
| 12:15.06 | CIA-52 | BRL-CAD: 03Rossberg 07http://brlcad.org * r2612 10/wiki/Google_Summer_of_Code: probable a copy-and-paste error |
| 12:21.21 | CIA-52 | BRL-CAD: 03davidloman * r43904 10/geomcore/trunk/ (include/Config.h src/utility/Config.cxx): Added some zero length string checks for the UInt and UShort helper functions in Config class to keep from attempting to parse an empty string. Added a hasConfigValue() for performing simple mapping checks. |
| 12:27.14 | CIA-52 | BRL-CAD: 03davidloman * r43905 10/geomcore/trunk/src/utility/Config.cxx: Made getConfigValue() perform a check to see if the internal config map actually has the key prior to attempting to return the value. |
| 12:29.08 | CIA-52 | BRL-CAD: 03davidloman * r43906 10/geomcore/trunk/src/GS/geomserv.cxx: Simplify startup of geomserv by making Config do all the data conversions for the 'port' parameter. |
| 12:29.15 | starseeker | brlcad: I'll try and sync to stable today |
| 12:41.10 | CIA-52 | BRL-CAD: 03davidloman * r43907 10/geomcore/trunk/ (3 files in 3 dirs): Reordered GemetryService args to be more intuitive. Removed GeometryService's need to store a localnodename as it was redundant (it was being stored as the thread name anyways) |
| 12:43.54 | CIA-52 | BRL-CAD: 03davidloman * r43908 10/geomcore/trunk/src/GS/geomserv.cxx: Geomserv now correctly parses config file for listenAddy and listenPort. If not present, use defaults. |
| 13:12.40 | starseeker | here's a quick stab at a poster - I don't expect it'll pass muster but maybe it'll prod somebody: |
| 13:12.44 | starseeker | http://bzflag.bz/~starseeker/poster_2011_1st_draft.png |
| 13:13.16 | dloman | Im instantly grooving on the TRON font =D |
| 13:13.41 | ``Erik | yeah, int he lower right, that's cool |
| 13:14.04 | ``Erik | but the drop shadows? ortho view of a ginormous screenshot? (not saying I could do better, just being the peanut gallery) |
| 13:14.16 | starseeker | that's the GSoC logo - I'm not sure how to do that font |
| 13:14.32 | starseeker | ``Erik: that's why it's to prod, not proposed as a final |
| 13:15.10 | ``Erik | hm, matt wanted to do german today, you should call him up and go, bring up the poster, he or nikki might be interested in chattering about it, if not helping :) |
| 13:15.23 | starseeker | ``Erik: heh |
| 13:15.34 | starseeker | unfortunately, I doubt I'll be up there in time |
| 13:15.39 | ``Erik | we're programmers, not artists :D |
| 13:15.41 | ``Erik | ah, bummer |
| 13:15.44 | starseeker | amen |
| 13:15.59 | ``Erik | (or, rather, our art is code and math, not visual) |
| 13:16.06 | starseeker | the drop shadow effect was a stand in until someone figures out how to do that google font thing |
| 13:16.36 | ``Erik | looks like the tron font done in gimp with the glow and outline script-fu smacked on it? |
| 13:16.48 | starseeker | shrugs - maybe |
| 13:16.56 | ``Erik | script-fu is neat, it used to all be scheme, d'no if they've "fixed" that |
| 13:16.59 | starseeker | doesn't have strong script-fu |
| 13:17.21 | starseeker | ``Erik: if you want to hack around with it I can send you the xcf |
| 13:17.38 | ``Erik | nah, getting ready to shower and head down to union memorial |
| 13:17.52 | starseeker | a good visual for this might be a nice full-screen isst view of something cool |
| 13:18.55 | ``Erik | hm, what about a handful of keen images (archer, isst, stryker/rise, a few rt's) canted at like ~20 degrees in the z (so they're all parallelograms in outline) |
| 13:19.18 | starseeker | cool - can you do that? |
| 13:19.21 | ``Erik | semi-randomly placed |
| 13:19.23 | ``Erik | um, no? :D |
| 13:19.30 | ``Erik | just throwing ideas, dude |
| 13:19.32 | dloman | starseeker: you in today? |
| 13:19.37 | starseeker | later today, yes |
| 13:19.39 | dloman | kk |
| 13:19.40 | starseeker | dloman: what's up? |
| 13:20.09 | dloman | well brlcad is here already, so i figure the three of us + Photoshop CS5 can get hte job done relatively quickly. |
| 13:20.24 | starseeker | dloman: you don't need me for that |
| 13:20.31 | starseeker | you and brlcad can handle it fine |
| 13:20.36 | dloman | collective input |
| 13:20.47 | dloman | is stupid busy. |
| 13:21.04 | starseeker | nods - I won't speed up the process much, trust me |
| 13:21.36 | ``Erik | photo shop? that's the windows imitation of gimp, rgiht? :> |
| 13:21.56 | dloman | lol |
| 13:22.04 | dloman | i use both pretty extensively |
| 13:22.21 | dloman | and, this is the one area where the Commercial package spanks the FOSS version. |
| 13:22.46 | starseeker | ``Erik: I know - we could use a snapshot from brlcad's gource visualization :-P should be guaranteed to scare off the weak |
| 13:25.21 | ``Erik | hm, don't hvae gimp on my laptop, compiling it and it's chain would take too long, and sketchup looks wrong for what I want to say, damn |
| 13:25.36 | starseeker | inkscape? |
| 13:25.52 | starseeker | or xfig? :-P |
| 13:26.13 | dloman | ``Erik: you run a gui of any sorts? |
| 13:26.35 | ``Erik | dlo: mac. |
| 13:26.50 | dloman | ..theres no precompiled GIMP binaries? |
| 13:26.54 | ``Erik | probably are |
| 13:27.00 | dloman | kk |
| 13:27.09 | ``Erik | http://www.gimp.org/macintosh/ heh |
| 13:27.21 | CIA-52 | BRL-CAD: 03starseeker * r43909 10/brlcad/branches/STABLE/ (27 files in 17 dirs): Sync STABLE to trunk r43908 |
| 13:27.31 | starseeker | there we go |
| 13:27.36 | starseeker | gets moving |
| 13:27.47 | starseeker | lots to do, too few hours... |
| 13:30.37 | ``Erik | mebbe brlcad will go to prost and talk to matt about critiquing what we do or hints on how to not suck? |
| 13:31.20 | ``Erik | hits the rainlocker and heads off, hasta |
| 13:43.29 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 13:54.38 | CIA-52 | BRL-CAD: 03davidloman * r43910 10/geomcore/trunk/ (4 files in 2 dirs): Rework DataSource interface to better represent current repo design initiative. (plus cascading changes.) |
| 14:05.54 | CIA-52 | BRL-CAD: 03davidloman * r43911 10/geomcore/trunk/ (3 files in 2 dirs): Stub in SvnDataSource class |
| 14:06.55 | ``Erik | 10:06AM up 313 days, 16:43, 2 users, load averages: 0.05, 0.11, 0.14 |
| 14:07.18 | ``Erik | doh, wrong machine :D |
| 14:07.21 | dloman | thats good to know ``Erik , thanks! |
| 14:07.22 | ``Erik | 10:06AM up 414 days, 4:55, 17 users, load averages: 1.91, 2.03, 2.02 |
| 14:07.44 | ``Erik | starting to get heavy again, might break the old record |
| 14:08.25 | dloman | ``Erik: whats your FB post about? |
| 14:08.56 | ``Erik | just everything all happening at once, crazy couple of months |
| 14:09.03 | dloman | ah, got ya. |
| 14:09.35 | ``Erik | I mean, that whole area is lighting up like ww3 is about to start, natural disasters of unprecidented scale elsewhere, ... |
| 14:10.33 | dloman | maybe, just maybe, there will be some finality to the (seemingly) endless conflict in/around the middle easy. |
| 14:10.36 | dloman | lol |
| 14:10.37 | dloman | east |
| 14:11.19 | ``Erik | perhaps, if they modernize, but we're regressing on the flipside, so... |
| 14:11.48 | ``Erik | (mebbe that's the REAL pole shift to be scared about :D ) |
| 14:12.03 | dloman | =D |
| 14:12.55 | dloman | That would make a decent 'what if' scifi story: Earth's axial tilt gets knocked to near 90 degrees..... |
| 14:15.03 | ``Erik | ever read "lucifers hammer"? pournelle and niven, I think? |
| 14:15.15 | dloman | can't say that I have. |
| 14:15.28 | ``Erik | similar situation, amusing enough book :) |
| 14:16.07 | dloman | wonders if there is an audiobook for it..... |
| 14:16.47 | dloman | if pournelle can tame niven's habit for painful science detail, then it could be good :) |
| 14:17.13 | ``Erik | hehehe, I dig niven, I like the detail |
| 14:17.19 | dloman | the ringworld series was interesting, but it felt like i was reading a tech manual / textbook at times ;) |
| 14:17.36 | dloman | "Screw plot development, lets talk about cool geeky things" |
| 14:17.40 | ``Erik | needs to pick up pratchets discworld series |
| 14:17.40 | dloman | =D |
| 14:17.51 | dloman | heh, we have all of them |
| 14:17.54 | dloman | well, most of them. |
| 14:18.04 | dloman | he got really preachy in his latests books. |
| 14:18.34 | dloman | He's a faithfully devout Athiest and started to use his books to evangelize :/ |
| 14:18.55 | ``Erik | hm |
| 14:19.00 | dloman | that was kinda annoying, but the first, oh, 8-10 books in the series were great. |
| 14:19.09 | ``Erik | also need to restock on harry harrison and mercedes lackey O.o |
| 14:19.20 | ``Erik | does robert asprin still write? is he still alive? O.o |
| 14:19.23 | dloman | I have a few audio books for pratchet if you want. |
| 14:19.31 | ``Erik | oh, he died in '08 :( |
| 14:19.33 | dloman | no idea. Who's that? |
| 14:19.46 | ``Erik | the 'myth' series and 'phules company' |
| 14:19.54 | ``Erik | camp comedy scifi |
| 14:20.15 | ``Erik | http://en.wikipedia.org/wiki/MythAdventures was his big series |
| 14:20.54 | ``Erik | kinda mel brookes goofy |
| 14:21.30 | dloman | hrm, looks interesting. |
| 14:21.37 | dloman | bookmarks. |
| 14:21.52 | dloman | so I was wondering... |
| 14:21.57 | ``Erik | the blue pill |
| 14:22.05 | dloman | i found a website pertaining to the whole Ringworld thing |
| 14:22.22 | dloman | some guy, back in the 80's, tried to do a simulation of the Ringworld. |
| 14:22.34 | dloman | but hit a wall due to computer limitations |
| 14:22.44 | dloman | ....think we could model it in brlcad? |
| 14:22.46 | ``Erik | hm, we do have a hair more computational power these days, I think |
| 14:22.50 | dloman | simply of course |
| 14:23.06 | ``Erik | model it? sure, um |
| 14:23.12 | dloman | although, an algo that would generate terrain in addition to the ring would be neat. |
| 14:23.15 | ``Erik | accuracy will get gimpy due to the sizes |
| 14:23.26 | ``Erik | I thought we had a few of those |
| 14:23.37 | dloman | ....but on that scale? :) |
| 14:23.44 | ``Erik | fractal noise generators that create dsp's, etc |
| 14:23.53 | ``Erik | sure, big enough fractal, it's just a memory constraint |
| 14:24.12 | dloman | ponders |
| 14:24.22 | dloman | down to what resolution though.... |
| 14:24.31 | dloman | 1km ? 10m ? |
| 14:24.36 | ``Erik | could alter one to do 'bound' fractals to chain them along by preseeding one side and generate a metric buttload of dsps' to cover the inner surface |
| 14:25.04 | dloman | i think its funny how you can spew tech stuff and still work the word 'buttload' into it. |
| 14:25.10 | dloman | =D |
| 14:25.39 | ``Erik | 10m should be okish, I'd start getting nervous about 1m... um, the estimated orbital distance is about jupiters orbit, and we store purely in mm |
| 14:26.11 | ``Erik | I'm under the impression that jupiter is (let me figure a better word) a whole metric assload of mm's from the center of the sun |
| 14:26.28 | ``Erik | so double precision will start stretching out a fair bit |
| 14:26.43 | dloman | right, but we have 64 bits of storage to work with right? And with doubles, we get what.... 15 decimals of precision? |
| 14:26.54 | ``Erik | 15 decimals is a falacy |
| 14:27.09 | dloman | ...hence the question mark :P |
| 14:27.18 | ``Erik | it's a logorithmic encoding, with the most accuracy right at 1.0ish |
| 14:27.34 | ``Erik | if you get too small or too big, the discernable difference increases |
| 14:27.44 | dloman | well forget float then, why not go with pure integer? |
| 14:28.36 | ``Erik | I was actually trying to come up with a system in the late 90's, wanting to right an xwing/wingcommander type game for an entire solar system, did the math and double was 'good enough', after being mocked for trying to come up with a tiered integer system |
| 14:29.25 | ``Erik | but that was a space fighter sim, the speeds and distances were assumed to be significant, so mapping between model and world space ... I don't recall :/ |
| 14:29.27 | dloman | what was your minimum accuracy with that system? 1m 10m? |
| 14:29.58 | ``Erik | I want to think a full double was down to a handful of cm, but I really don't remember |
| 14:30.17 | ``Erik | that's 64b packed, 80b computation, the norm for intel |
| 14:31.10 | ``Erik | of course, a ringworld model could hold translation matrices all up the chain to gain accuracy, ya just might get weirdness if you xpush'd |
| 14:31.23 | dloman | hehehe |
| 14:31.43 | ``Erik | might be a fun diversion in april :D |
| 14:31.53 | dloman | that'd be a pretty awesome ISST demo |
| 14:32.00 | dloman | april == offsite? |
| 14:32.29 | ``Erik | nah, offsite should be serious, but we all have too much to worry about this month, can't have diversions like that |
| 14:33.23 | ``Erik | (mebbe we shoulda made geomserv the offsite, it was postponed because geomserv was more important, from what I understand) |
| 14:42.09 | dloman | well now, work on the Infinity engine has certainly come along nicely. Eye candy: http://www.youtube.com/watch?v=h7eREddMjt4 |
| 14:52.54 | CIA-52 | BRL-CAD: 03davidloman * r43912 10/geomcore/trunk/ (5 files in 4 dirs): Modify GeometryReqMsg to carry 'Path' and 'Recurse' vars instead of 'ReqType' and 'Path' vars |
| 15:08.55 | *** part/#brlcad sofichinu (~sofichinu@115.69.147.65) | |
| 15:09.17 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 16:23.07 | CIA-52 | BRL-CAD: 03starseeker * r43913 10/brlcad/branches/cmake/ (5 files in 4 dirs): MFC r43912 |
| 16:57.06 | CIA-52 | BRL-CAD: 03davidloman * r43914 10/geomcore/trunk/src/GS/ (geomserv.config geomserv.cxx): Clean up and standardize Datasource declarations in the .config file |
| 17:02.45 | CIA-52 | BRL-CAD: 03davidloman * r43915 10/geomcore/trunk/ (include/DataManager.h src/GS/DataManager.cxx): Simplify DataManager by only allowing it to handle a single DataSource.... for now. |
| 17:42.57 | CIA-52 | BRL-CAD: 03starseeker * r43916 10/brlcad/trunk/src/ (libbu/booleanize.c libged/red.c): Two things to fix red behavior - need blank and not space in one place in the regex matching, and recognize (null) as a boolean 0 in bu_str_true |
| 17:48.01 | starseeker | pwd |
| 17:48.10 | starseeker | whoops |
| 17:50.41 | CIA-52 | BRL-CAD: 03starseeker * r43917 10/brlcad/branches/STABLE/src/ (libbu/booleanize.c libged/red.c): Sync STABLE to trunk r43916 |
| 17:52.48 | CIA-52 | BRL-CAD: 03starseeker * r43918 10/brlcad/branches/cmake/src/ (libbu/booleanize.c libged/red.c): MFC r43917 |
| 18:09.14 | CIA-52 | BRL-CAD: 03davidloman * r43919 10/rt^3/trunk/ (27 files in 25 dirs): Purge out all GeometryService related stuff. This now lives in the GeomCore module. |
| 18:10.16 | *** join/#brlcad Nohla (~Nohla@64.76.19.227) | |
| 18:11.37 | CIA-52 | BRL-CAD: 03starseeker * r43920 10/brlcad/trunk/src/libged/color.c: edcolor was eating the colors - check for the right number of digits in the scan line |
| 18:14.38 | CIA-52 | BRL-CAD: 03starseeker * r43921 10/brlcad/trunk/NEWS: edcolor was removing old color tables and not accepting new ones - fixed scan logic to expect the actual number of digits being scanned for. |
| 18:16.50 | CIA-52 | BRL-CAD: 03starseeker * r43922 10/brlcad/branches/cmake/ (NEWS src/libged/color.c): MFC r43921 |
| 18:17.45 | CIA-52 | BRL-CAD: 03starseeker * r43923 10/brlcad/branches/STABLE/ (NEWS src/libged/color.c): Sync STABLE to trunk r43921 |
| 19:23.31 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-125-83-101.dsl.bkfd14.sbcglobal.net) | |
| 19:44.19 | bhinesley | Hello everyone, I'm a student participating in the GSoC. I would appreciate any suggestions for project proposals. I have about 5 years of professional experience in 3d CAD design (designing commercial plumbing systems in AutoCAD). I have minimal experience with C++ and Java, but I have coded dozens of VBA programs for the companies I have worked for. I use Linux all the time, personally, and I also have about 3 years of |
| 19:44.19 | bhinesley | experience administering a Linux server on a ~25 workstation network. |
| 19:45.49 | bhinesley | Also, I am somewhat familiar with Python, and I believe I could get up to speed quickly. |
| 19:50.50 | *** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net) | |
| 19:50.53 | starseeker | do you have particular interests? |
| 19:51.56 | starseeker | bhinesley: if you have experience with modeling interfaces, you might want to take a look at our ideas for GUI enhancement |
| 19:52.42 | starseeker | We're using Tcl/Tk, which is a bit different from Python, but not tremendously difficult |
| 19:54.35 | starseeker | http://brlcad.org/wiki/Google_Summer_of_Code/Project_Ideas |
| 19:55.00 | bhinesley | I don't have any particular interests, that I can think of yet. I don't have experience with modeling interfaces. |
| 19:55.15 | starseeker | well, you used AutoCAD yes? |
| 19:55.17 | bhinesley | Learning a new language isn't really a problem |
| 19:55.23 | bhinesley | yes |
| 19:55.29 | starseeker | that's experience :-) |
| 19:56.00 | starseeker | bhinesley: the first thing I'd suggest is compiling BRL-CAD and taking a look at MGED and Archer |
| 19:56.11 | starseeker | they're where the current GUI development action is |
| 19:56.31 | bhinesley | I think I misunderstood you, I thought you meant programmer-modeling user interfaces |
| 19:56.51 | bhinesley | okay |
| 19:56.55 | starseeker | Was your pipe design work in 2D or 3D (drawings, or three space)? (there's no wrong answer) |
| 19:57.01 | bhinesley | 3d |
| 19:57.07 | bhinesley | for fabrication |
| 19:57.09 | starseeker | nods |
| 19:57.42 | bhinesley | although, obviously I am proficient in 2d drawings as well |
| 19:57.55 | starseeker | If you're not afraid to get down and dirty with Tcl/Tk, I'd suggest taking a look at the sketch editing task and possibly the Ayam task |
| 19:58.05 | starseeker | do you have any mathematical background? |
| 19:58.29 | bhinesley | yes, I have finished calculus 2 (out of 3; I'm on a semester system) |
| 19:58.48 | starseeker | OK - Ayam is related to NURBS, which is pretty heavy duty in the mathematical department |
| 20:00.29 | bhinesley | interesting... I am assuming it involves more mathematics than I am familiar with(?) |
| 20:01.42 | starseeker | It depends... the mathemathical requirements may not be absolutely essential for mapping Ayam nurbs editing to our nurbs editing, but you'll have to become familiar with NURBS structures |
| 20:03.12 | starseeker | Our sketch editor needs help rather badly, so if you're more comfortable with 2D drafting you can take a look at our sketch editor, at what TkCAD can do, and where to go from there |
| 20:04.33 | starseeker | http://brlcad.org/wiki/MGED_Sketch_Editor_Migration_and_Enhancement |
| 20:04.44 | starseeker | http://brlcad.org/wiki/Ayam_Editor_Feature_Integration |
| 20:05.13 | starseeker | those will have links to get you started |
| 20:05.18 | bhinesley | thank you |
| 20:05.44 | bhinesley | not sure if this helps, but here is a picture of some of my work: http://stashbox.org/manage_file/1087048/pipe |
| 20:05.48 | starseeker | remember those are just suggestions - be sure to pick something you find interesting |
| 20:06.12 | bhinesley | certainly |
| 20:06.49 | starseeker | I base those suggestions on the fact that you've worked at modeling tasks before, and thus have background interacting with graphical modeling tasks |
| 20:07.40 | bhinesley | that's great, that is exactly what I was looking for |
| 20:08.16 | starseeker | If you're familiar with Python Tcl/Tk shouldn't seem too alien, although Archer in particular makes heavy use of Itcl/Itk |
| 20:09.31 | starseeker | bhinesley: you'll want to get BRL-CAD built first and foremost, since everything follows from that, and get MGED and Archer running |
| 20:09.47 | bhinesley | yes, I'll do that right now. |
| 20:10.17 | starseeker | then explore the sketch editor (I'll offer a shortcut - when you have mged running, create a basic sketch and then edit it to get the gui) |
| 20:11.00 | starseeker | from the MGED command line: |
| 20:11.03 | starseeker | make sketch.s sketch |
| 20:11.14 | starseeker | sed sketch.s |
| 20:11.51 | starseeker | (remember to compile using --with-ogl to get Archer working) |
| 20:12.19 | starseeker | bhinesley: I can't seem to see that stashbox.org link |
| 20:14.05 | bhinesley | Hmm, I was afraid of that. I'm trying to find an alternative. |
| 20:16.22 | bhinesley | try this: https://picasaweb.google.com/lh/photo/_dWpWLr1esGb16X7_4DlNHMyrgI048JfNwPx7Dl9cn0?feat=directlink |
| 20:17.11 | bhinesley | that doesn't show much solids modeling, but I've done that too |
| 20:17.37 | bhinesley | let me clarify: a tool was used for sizing the pipe |
| 20:17.58 | bhinesley | all routing/placement was done manually |
| 20:18.36 | bhinesley | I modeled all of the pumps/tanks to spec though |
| 20:21.05 | starseeker | cool |
| 20:26.45 | bhinesley | so what kind of stuff do you do for BRL-CAD, if you don't mind me asking/ |
| 20:26.49 | bhinesley | *? |
| 20:29.29 | starseeker | bug fix, development, support |
| 20:30.11 | starseeker | the guy to really listen to is brlcad, he'll probably appear in channel later |
| 20:30.38 | bhinesley | oh okay. founder? |
| 20:30.58 | starseeker | he's the lead of the open source project |
| 20:31.08 | starseeker | the actual founder of BRL-CAD itself is Mike Muuss |
| 20:31.43 | starseeker | it's a very old project: http://brlcad.org/d/about |
| 20:32.05 | starseeker | is a newbie, relatively speaking :-) |
| 20:33.06 | starseeker | bhinesley: if you want to ask questions, go ahead and post them - it may be a few hours before anyone responds, but that's normal - we read backlogs |
| 20:33.36 | bhinesley | hey, that's cool |
| 20:33.37 | bhinesley | is a newbie, in absolute terms |
| 20:33.51 | bhinesley | thanks for your help |
| 20:34.00 | starseeker | no problem - any of that look interesting? |
| 20:34.58 | bhinesley | I haven't looked yet, I'm working on getting the source |
| 20:35.09 | starseeker | nods |
| 20:35.25 | starseeker | remember not to check out the whole thing - you only want the latest development sources: |
| 20:35.38 | starseeker | svn co https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/trunk brlcad |
| 20:35.53 | bhinesley | oh thanks, I wasn't sure which to checkout |
| 20:37.04 | starseeker | the toplevel files have instructions for building - ideally, ./autogen.sh && ./configure --enable-all --with-ogl && make && make install will do it |
| 20:39.10 | CIA-52 | BRL-CAD: 03starseeker * r43924 10/geomcore/branches/fossil/ (4 files in 3 dirs): Get checking building, albeit with a lot of implicit warnings |
| 20:39.59 | starseeker | bhinesley: be sure you review the checklist - do you have a sourceforge account? |
| 20:41.38 | bhinesley | I will in about 30 seconds |
| 20:51.33 | CIA-52 | BRL-CAD: 03starseeker * r43925 10/geomcore/branches/fossil/ (4 files in 2 dirs): Add find_option to basic, but this does not belong in a library (none of the argc/argv stuff does) and will be part of a restructuring |
| 20:56.01 | CIA-52 | BRL-CAD: 03starseeker * r43926 10/geomcore/branches/fossil/src/libgeomvcs/checkin.c: update find_option |
| 21:31.51 | *** join/#brlcad Emma (~Emma@p5.eregie.pub.ro) | |
| 22:30.35 | CIA-52 | BRL-CAD: 03starseeker * r43927 10/geomcore/branches/fossil/ (10 files in 2 dirs): Declare some more functions. |
| 03:17.17 | *** part/#brlcad niels_horn (~niels@187.14.62.166) | |
| 03:26.00 | *** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ) | |
| 03:26.08 | *** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ) | |
| 03:26.31 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 03:26.36 | *** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ) | |
| 03:33.57 | *** mode/#brlcad [+o brlcad] by ChanServ | |
| 03:42.08 | brlcad | starseeker: thanks for the sync to stable, can hopefully test tomorrow |
| 03:45.06 | *** join/#brlcad IriX64 (~IriX64@bas2-sudbury98-1096601295.dsl.bell.ca) | |
| 03:45.44 | brlcad | bhinesley: welcome |
| 03:47.08 | bhinesley | brlcad: thank you, hello |
| 03:50.06 | brlcad | bhinesley: so I read the backlog, have you had a chance to look around at things in BRL-CAD yet? |
| 03:50.40 | brlcad | there really are nearly a limitless range of areas where valuable projects can be worked |
| 03:51.44 | bhinesley | I actually just got back from class. Before I left, I was working on getting BRL-CAD compiled; still a couple errors, but close. |
| 03:51.49 | brlcad | from a project-perspective, I can share that this year there is a strong emphasis on projects that are tightly integrated and part of BRL-CAD, refacting and improvements being more interesting than new code that could be developed in isolation |
| 03:52.03 | brlcad | errors? pastebin? |
| 03:52.11 | brlcad | should be a clean checkout/build from latest svn |
| 03:53.00 | bhinesley | I didn't save it, but I'm re-"make"ing right now |
| 03:58.08 | bhinesley | I will hopefully have more to say about the projects that were presented to me, soon. I feel that I should do a bit more research before I understand. |
| 03:58.28 | bhinesley | *will need to to a bit more research |
| 04:05.37 | bhinesley | I am certainly interested in contributing to BRL-CAD, though. Now that I know more about it, I will try to help where I can, GSoC or no. |
| 04:05.54 | bhinesley | here we go: http://pastebin.com/8SgPkDtK |
| 04:07.51 | brlcad | huh, interesting -- that's from svn trunk? |
| 04:07.58 | brlcad | what version of gcc is that? |
| 04:08.15 | bhinesley | 4.5.1 |
| 04:08.33 | brlcad | mm, nice 'n fresh |
| 04:08.35 | bhinesley | it's from here: https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk brlcad |
| 04:08.38 | brlcad | k |
| 04:10.10 | bhinesley | that is the version that came with the stable brach of Fedora. Should I try a newer version? |
| 04:14.12 | CIA-52 | BRL-CAD: 03brlcad * r43928 10/brlcad/trunk/src/proc-db/clutter.c: |
| 04:14.12 | CIA-52 | BRL-CAD: clear a strict compilation warning from gcc 4.5.1 (reported by bhinesley via |
| 04:14.12 | CIA-52 | BRL-CAD: irc) where a warning about an operation within the random number generator may |
| 04:14.12 | CIA-52 | BRL-CAD: be undefined. it's undoubtedly due to multiple increment calls being passed as |
| 04:14.12 | CIA-52 | BRL-CAD: function args, so evaluation order might not be what one would expect. simple |
| 04:14.13 | CIA-52 | BRL-CAD: enough to get the random number prior to the function. |
| 04:14.15 | brlcad | so that's just a compilation warning, halting because we specify "cc1: warnings being treated as errors" |
| 04:14.22 | brlcad | fixes are usually trivial |
| 04:16.39 | bhinesley | that's what I thought, but I figured the "warnings being treated as errors" was there for a valid reason |
| 04:18.04 | bhinesley | oh, I see now. I'll remove it. |
| 04:18.39 | brlcad | the --disable-strict configure flag will get you past those warnings, though there really shouldnt be many/any .. it's almost complete in your build to have gotten as far as it did only halting in proc-db (one of the last dirs) |
| 04:19.20 | brlcad | it's there to weed those issues out by default, instead of ignoring and/or allowing to accumulate |
| 04:19.30 | bhinesley | makes sense |
| 04:21.13 | brlcad | took several months to bring the code base into full compliance |
| 04:22.06 | brlcad | but in the end, having rigid conformance to all warnings across multiple configurations, platforms, and compilation environments really helps maintainability |
| 04:22.25 | brlcad | and pushes back against lazy coding habits |
| 04:24.22 | bhinesley | hard to argue against paying attention to warnings |
| 04:26.29 | brlcad | bhinesley: so in addition to the project ideas page, there is also http://brlcad.org/~sean/ideas.html |
| 04:27.13 | bhinesley | wow, great |
| 04:27.17 | brlcad | of everything in that list and the project ideas page, priority is generally given to topics that fall into one of our four major focus areas (described in detail at http://brlcad.org/BRL-CAD_Priorities.png ) |
| 04:29.09 | brlcad | our main interest isn't so much in getting code, but towards getting you actively developing (long after gsoc is over) |
| 04:32.01 | bhinesley | assisting in active development is precisely what I am interested in |
| 04:32.04 | brlcad | if that interest is mutual, then the project is really just a catalyst excuse to keep you fed while you code and becaome a proper new dev and we can make a lot more headway on a successful gsoc submission |
| 04:38.50 | bhinesley | to be honest, though, with all the hype surrounding the competitive nature of the GSoC, I feel like I am competing with a bunch of guys polishing up the last 6 months of their PhD's |
| 04:39.21 | bhinesley | not to say that I am not going to put forth the maximum effort. |
| 04:39.40 | brlcad | it's a really wide range of talent and experience |
| 04:39.45 | bhinesley | has used a double negative |
| 04:40.57 | brlcad | having worked with a couple students in previous years whose projects loosely related to their dissertation, I can say that is definitely not something very interesting to entertain again this year unless it was just an outright stellar proposal |
| 04:41.27 | brlcad | those students tend to work on their project and disappear |
| 04:41.55 | bhinesley | expensive, then |
| 04:48.17 | brlcad | feel free to probe any questions on what you might be interested in working on, whether it's something on the list or not -- keeping in mind the "prefer to fix/improve/integrate existing code over writing new code" inclination as a general guideline |
| 04:50.02 | bhinesley | will do; when are you usually here? |
| 04:50.06 | brlcad | and of course, ask all the questions that come to mind - several of us read backlog and comment when time is available |
| 04:50.14 | brlcad | usually all the time ;) |
| 04:50.18 | bhinesley | :) |
| 04:50.25 | brlcad | just sometimes too busy to talk |
| 04:51.09 | brlcad | UTC-4 at the moment |
| 04:52.02 | bhinesley | good to know, I'm -8 |
| 04:54.42 | brlcad | really?? that's alaska |
| 04:55.09 | brlcad | maybe +8? |
| 04:55.49 | bhinesley | california http://upload.wikimedia.org/wikipedia/commons/3/39/Timezones2008_UTC-8.png |
| 04:59.24 | bhinesley | compile successful :) |
| 05:01.57 | brlcad | ah right, so actually UTC-7 then .. (daylight savings) |
| 05:02.51 | bhinesley | huh, I didn't realize the UTC code changed for daylight savings |
| 05:03.05 | bhinesley | makes sense |
| 05:29.10 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 08:14.52 | brlcad | finishes our gsoc flyer: http://brlcad.org/gsoc/BRL-CAD_GSoC2011_flyer.pdf |
| 08:15.13 | brlcad | feedback welcome, holding off sending it in to google until after morning |
| 08:16.47 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 09:24.41 | bhinesley | looks good/professional. Maybe change the color of "GET PAID". Goodnight. |
| 10:46.53 | starseeker | brlcad: nice, I like it |
| 10:47.19 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 10:55.31 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 11:06.27 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 11:17.26 | dloman | mernin |
| 11:47.54 | starseeker | morning |
| 12:55.54 | yiyus | I'm thinking about applying for the gsoc project "GED Transactions" |
| 12:56.08 | yiyus | looking at libged source it looks like a lot of work |
| 12:57.47 | yiyus | I think most of the transactions would be trivial, but there will probably be some difficult ones... |
| 12:58.04 | yiyus | any idea of where i should be looking at to figure out the dimension of the project? |
| 12:59.53 | brlcad | yiyus: hello! |
| 13:00.05 | yiyus | hi |
| 13:02.39 | brlcad | yiyus: the general idea is to incrementally unroll how each of the commands so they no longer modify geometry |
| 13:02.51 | brlcad | it's a LOT of refactoring, but not hard code fortunately |
| 13:03.47 | brlcad | so, for example, there is a 'kill' command for deleting geometry .. |
| 13:04.26 | brlcad | presently, that command will search for the specified object(s) and it deletes them from the geometry file if it finds them |
| 13:05.30 | brlcad | tranactionally, that would change to having the kill command still search for the specified object(s) like it was doing before, but when it finds them, it records a "delete OBJECT" action |
| 13:06.46 | yiyus | i have worked in text editors with infinite undo before, we made something similar (though a bit simpler): apply the modification and push the inverse function to an undo stack |
| 13:07.08 | yiyus | iiuc your idea is the same, but having also a "done" stack |
| 13:07.51 | brlcad | a wrapper function kill would have been called through gets a resulting action list back from every command, which would then revalidate that all actions can be performed, perform them on a copy, then make the copy replace the original |
| 13:08.50 | yiyus | ah, ok, i think i got it |
| 13:08.57 | brlcad | it's similar to infinite undo (and the wrapper function would also need to record the action and the inverse action to a log) |
| 13:09.21 | yiyus | validating that the operations can be performed would be refactored or would i have to write it from scratch? |
| 13:09.23 | brlcad | the only complexity is that the transactions are nestable |
| 13:10.25 | yiyus | nestable, in the same sense that solidworks transformations are nestable, for example? |
| 13:10.35 | brlcad | I might call one command, which might call another, which might call another, etc.. each of them potentially pushing actions of delete, create, or modify of geometry and views |
| 13:10.49 | brlcad | yes |
| 13:11.25 | yiyus | well, everything sounds quite well, i will have a deeper look to get some familiarity with brlcad and the libged code |
| 13:11.33 | yiyus | one last thing |
| 13:11.56 | yiyus | I also saw the "Geometry Selection Functionality" project |
| 13:12.25 | yiyus | which of them would be preferable? ged transactions or geometry selection? |
| 13:13.03 | brlcad | yes :) |
| 13:13.07 | brlcad | both are high priority |
| 13:13.56 | brlcad | geometry selection is a lot more tangible for gsoc in terms of complexity |
| 13:14.06 | brlcad | so what's your background? |
| 13:14.52 | yiyus | i'm industrial engineer. programming all my real experience is in C |
| 13:15.05 | yiyus | though i also know some other languages |
| 13:15.26 | yiyus | i participated in gsoc 2010, with Plan 9 from Bell Labs, writing a virtual machine |
| 13:15.38 | yiyus | but I don't think that can be applied here |
| 13:15.52 | yiyus | i also know many other languages, but not c++ |
| 13:15.57 | brlcad | how did you like working with the plan 9 guys? |
| 13:16.20 | yiyus | it was great. actually, i have been quite involved in plan9 related projects for some years |
| 13:16.32 | brlcad | are you still working on plan9 too? |
| 13:17.08 | yiyus | yes |
| 13:17.25 | yiyus | i still maintain what i wrote last year, and we have some plans to improve it |
| 13:17.47 | yiyus | as a matter of fact, i'm considering applying there again too |
| 13:18.29 | dli | plan9 still alive? I thought they have stopped it |
| 13:20.17 | yiyus | it is alive, but the team working on it at the labs is very small |
| 13:20.17 | brlcad | dli: oh yeah, their core devs are quite committed .. |
| 13:21.09 | yiyus | there is not any interest in turning it into a mainstream os (which i think is fine) |
| 13:21.27 | brlcad | i've wanted to attempt of port of brl-cad to plan9 |
| 13:21.43 | brlcad | we'd probably compile right out of the box with 80% functionality |
| 13:21.59 | brlcad | tk would be the one tough part |
| 13:22.16 | brlcad | so probably no gui services, but all command-line commands |
| 13:22.32 | brlcad | or at least most, the non-curses ones |
| 13:22.47 | yiyus | there is a tk port for inferno, which runs on top of plan9 |
| 13:22.54 | yiyus | but it is not tcl/tk, it is in limbo |
| 13:24.15 | brlcad | yiyus: so for gsoc submission, both sound like great ideas -- if you were going to tackle the libged one, I'd want to see a lot of up-front planning and testing on just one command before hitting up the 399+ other commands, maybe even having an initial refactoring plan spelled out in the application |
| 13:24.35 | brlcad | that's an important one to "get right" so there's not a lot of time wasted refactoring over and over and over |
| 13:24.53 | brlcad | libged refactoring is another project all in itself (and also high priority) :) |
| 13:26.12 | brlcad | that's also a project that would extend beyond gsoc so it'd be good to hear what dev plans would look like for beyond gsoc timeframe |
| 13:26.40 | yiyus | i will have to get familiar with libged before i can say too much, but will definitively have a look |
| 13:27.05 | brlcad | if that sounds like a lot of work (and it frankly IS, but would rather both of us be honest about it) .. then select may be a much better proposal or a library refactoring proposal since they're much more incremental |
| 13:31.59 | yiyus | may i ask what is your approximate student proposals/gsoc slots ratio? |
| 13:33.41 | brlcad | never know exactly, it really depends on the quality of the proposals more than the count |
| 13:34.00 | brlcad | we do a quick culling to the quality proposals |
| 13:35.05 | brlcad | one year that knocked 50 applications down to about 10 where we selected 4, another year that knocked 35 down to about 15 and we selected 5 |
| 13:35.37 | yiyus | thanks, that's all i wanted to know |
| 13:36.02 | yiyus | some projects cooperate with university departments and such, and have hundreds of applications per slot |
| 13:36.05 | brlcad | if it's a high quality application from a student we've been interacting with and we think is willing to be committed beyond gsoc, will instantly be in that final running |
| 13:36.37 | brlcad | ah yeah, no .. we're way more niche |
| 13:37.19 | brlcad | those sorts of applications rarely result in students that hang around after the summer is up .. interesting for getting academic code, but not so hot for growing the dev team |
| 13:37.44 | yiyus | i would like to stick on the project after gsoc |
| 13:38.07 | brlcad | we would like that as well :) |
| 13:38.08 | yiyus | i work at a department in the university (phd student) and would like to convince my collegues to use free software |
| 13:38.27 | yiyus | that's why i'd prefer brlcad over plan9 |
| 13:40.11 | brlcad | brl-cad's in production use today, but our usability is really tough especially compared to commercial cad systems, very steep learning curve |
| 13:40.27 | brlcad | something actively being worked on, but that's a lot of work that's going to take several years to address |
| 13:42.21 | yiyus | well, i don't expect to substitue autocad this year, but i'm sure it is good enough for easy tasks like test samples |
| 13:42.27 | brlcad | http://brlcad.org/BRL-CAD_Priorities.png is a useful read to know how the various gsoc projects fit into our "big picture" overarching priorities |
| 13:42.39 | brlcad | libged fits in under geometry services |
| 13:50.20 | starseeker | brlcad: so for an undo system, the delete OBJECT action would also record the inverse action (e.g. create OBJNAME OBJTYPE [params...]) in a log somewhere? |
| 14:00.10 | brlcad | right |
| 14:25.59 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 14:30.38 | brlcad | howdy PrezKennedy |
| 14:30.54 | PrezKennedy | howdy! how's life treating you brlcad? |
| 14:31.02 | brlcad | pretty fantastic |
| 14:31.28 | PrezKennedy | great! |
| 14:31.39 | brlcad | hows work? |
| 14:32.06 | PrezKennedy | meh, we're wrapping up at the 5 sided building come august |
| 14:32.34 | PrezKennedy | we're at the beginning of a dev cycle so it's not hectic at the moment |
| 14:32.40 | brlcad | nods |
| 14:32.57 | brlcad | hopefully employment is not reduced after the 5side is completed ;) |
| 14:33.25 | PrezKennedy | hopefully, but ive been looking at things up there |
| 14:33.37 | PrezKennedy | im not opposed to moving back, not much keeping me down here |
| 14:33.45 | brlcad | bhinesley: good suggestion, added a little color |
| 14:34.13 | brlcad | PrezKennedy: your brother might appreciate this: http://brlcad.org/gsoc/BRL-CAD_GSoC2011_flyer.pdf |
| 14:35.09 | starseeker | brlcad: how'd you do the blue halo? |
| 14:36.02 | PrezKennedy | brlcad, something he worked on? |
| 14:56.13 | brlcad | PrezKennedy: yeah, he made that model and rendered the image from scratch |
| 14:57.37 | brlcad | went to the ordnance museum, took measurements, modeled it, set up all the rendering infrastructure, did several massive distributed renderings -- this one being one of the more awesome lighting setups |
| 14:58.10 | brlcad | starseeker: I used the blue pill |
| 14:58.17 | starseeker | heh |
| 14:58.26 | brlcad | i mean, blue 'part'icles |
| 14:59.39 | brlcad | it's actually several composite effects -- a 0-offset shadow, a 2px antialiased stroke, and a light underglow effect |
| 15:00.18 | starseeker | cool |
| 15:02.50 | starseeker | hmm... it looks like I may have been using svn_add very very badly... |
| 15:03.10 | brlcad | heh |
| 15:03.17 | starseeker | or was I... hmm... |
| 15:03.30 | brlcad | wondered that .. an order of magnitude overhead is pretty substantial :) |
| 15:10.51 | starseeker | commit is still an IO hog |
| 15:12.18 | brlcad | one commit or N commits? |
| 15:12.27 | brlcad | hopefully just one |
| 15:12.44 | starseeker | well, I added the full breakout of havoc recursively, and am committing the whole thing |
| 15:12.47 | CIA-52 | BRL-CAD: 03davidloman * r43929 10/geomcore/trunk/ (include/ByteArray.h src/utility/ByteArray.cxx): Add a printHexString(...) method. Helps a tons during t-shooting. |
| 15:15.12 | CIA-52 | BRL-CAD: 03davidloman * r43930 10/geomcore/trunk/src/libNet/Portal.cxx: Add in some commented out ByteArray printHex calls. There's some issue with c++ and java not liking eachother byte orders. T-Shooting continues... |
| 15:16.24 | starseeker | so yeah, just doing one commit ;-) |
| 15:17.58 | CIA-52 | BRL-CAD: 03starseeker * r43931 10/geomcore/trunk/tests/svntest/main.c: Let's not individually add everything - use the svn_depth_infinity parameter setting, and go back to a full breakout - still expensive, but add is a lot quicker |
| 15:19.25 | dloman | so, realistically, are we viewing full model commits as a common occurance? |
| 15:19.42 | dloman | I always invisioned them as part of the 'upfront' cost for using the svn backend. |
| 15:21.08 | dloman | starseeker: if i wanted to 'steal' a root level CMakeList.txt for reworkign the cmake system in rt3, which would be a better fit? the CMakeLists.txt from geomcore or brlcad? |
| 15:21.25 | starseeker | geomcore |
| 15:21.54 | starseeker | dloman: full model commits are only a common occurance if you do things like frequent xpushing :-P |
| 15:22.29 | brlcad | starseeker: it'd be interesting to see what the cost difference is after an xpush, how long commit takes |
| 15:22.51 | brlcad | whether the cost is in the book-keeping to add new nodal entries or whether it's the commit book-keeping itself |
| 15:23.14 | starseeker | once I get the point where I can do something with the broken out .g I can try - my guess is it'll be murder |
| 15:23.45 | starseeker | I edited one primitive and committed it, and it took a while (less than a minute, but still) |
| 15:25.01 | starseeker | maybe 10-12 seconds |
| 15:53.26 | CIA-52 | BRL-CAD: 03davidloman * r43932 10/rt^3/trunk/ (6 files in 4 dirs): Steal Starseeker's geomcore cmake work and apply it to RT3. This is the first step in making RT3 into 'the GeometryEngine' module. |
| 15:53.53 | starseeker | dloman: were you planning to move the ogre/Qt work elsewhere? |
| 15:55.44 | dloman | Dunno.... |
| 15:55.56 | dloman | its currently disabled from any build system.... so.... |
| 15:56.13 | dloman | i think it would warrent discussion at some point :) |
| 15:56.48 | starseeker | liked the idea of having a toplevel geomengine module, that is svn:external included in geomcore |
| 15:57.35 | starseeker | or failing that, scrap geomcore and have two toplevels - geomengine and geomservice |
| 15:58.17 | starseeker | as I understand it, the idea is to reduce temptation to mingle GE and GS code and libraries? |
| 15:59.41 | dloman | nods |
| 15:59.55 | dloman | and singe coreInterface calls rt3 home.... |
| 15:59.58 | dloman | wow |
| 16:00.04 | dloman | s/singe/since/ |
| 16:00.34 | starseeker | I like leaving rt3 as the "repository for random ideas"... geometry engine and geometry service are starting to firm up |
| 16:01.31 | starseeker | conceptual neatness aside, I prefer to have the GE and GS build logic stay fully clean and not be polluted with "other" stuff that may be commented out |
| 16:02.00 | starseeker | but brlcad may have a different take |
| 16:03.28 | dloman | to be fair, the rt3 module was not intended to be the 'sandbox' that it has become. so why not make a 'sandbox' repo? |
| 16:03.47 | starseeker | that's fine too |
| 16:03.48 | dloman | err not repo, but module |
| 16:04.16 | starseeker | would still prefer calling it geomengine or GE instead of rt^3, but I suppose that's a bikeshed issue |
| 16:04.41 | dloman | agreed |
| 16:04.51 | dloman | 'ge' is nice and short :) |
| 16:05.01 | starseeker | dloman: want me to set it up that way? |
| 16:05.09 | starseeker | ge, gs and sandbox? |
| 16:05.34 | dloman | lets get some buy in from brlcad and perhaps Ed et al. |
| 16:05.42 | starseeker | nods - fair enough |
| 16:05.45 | dloman | renaming rt3 effects more than just us :) |
| 16:06.15 | dloman | ...although we could pull a nice prank on Dr Daniel by removing RT3 :) |
| 16:06.24 | starseeker | winces |
| 16:06.46 | starseeker | point - we should probably get GE at least up to parity with his existing rt3 functionality first |
| 16:16.05 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:BRL-CAD GSoC2011 flyer.png]]": This flyer was designed by Christopher Sean Morrison with Google logo and Goliath rendering provided with permission by Google Inc and Stephen Kennedy respectively. |
| 16:16.39 | dloman | currently, all i plan on doing is copying the GeometryEngine class files over (which are stubs) and then make a libge that is nothing but coreInterface files. |
| 16:16.59 | dloman | so, in essence, libge == coreInterface |
| 16:17.05 | dloman | ..initially |
| 16:17.13 | dloman | we will/can grow libge from there. |
| 16:17.38 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2614 10/wiki/Google_Summer_of_Code/2011: add a link to this year's flyer with details on acceptance |
| 16:17.58 | starseeker | nods |
| 16:18.18 | dloman | almost got rt3 to that point. |
| 16:21.00 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2615 10/wiki/Google_Summer_of_Code: link to 2011 flyer, scaled appropriately for landscape |
| 16:21.14 | *** join/#brlcad phani (7ab32f27@gateway/web/freenode/ip.122.179.47.39) | |
| 16:22.27 | starseeker | dloman: go ahead and do what you need to - we can always sort it out later |
| 16:22.32 | phani | i am student interested in participating in Google Summer of Code ... are there any admins around ? |
| 16:22.56 | starseeker | the fundamental cleanup was handled in rt3->geomcore, so subsequent refactoring should be fairly simple |
| 16:22.59 | starseeker | phani: howdy! |
| 16:23.29 | phani | Hi ! I am good . I am a masters student from india. |
| 16:23.33 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2616 10/wiki/Google_Summer_of_Code: /* [[Google_Summer_of_Code/2011|GSoC 2011]] */ |
| 16:23.44 | phani | My area of spcialization in image processing |
| 16:23.46 | dloman | starseeker: nice assertion that I'm going to screw it up :P |
| 16:23.55 | starseeker | dloman: hehe - I didn't mean it like that |
| 16:24.06 | starseeker | phani: have you looked over our projects page? |
| 16:24.14 | phani | yes .. |
| 16:24.21 | starseeker | what do you find interesting? |
| 16:24.24 | phani | http://brlcad.org/wiki/Complete_bu_image/libicv_and_redo_all_pix_tools_to_use_it |
| 16:24.26 | dloman | ..although, with the run of luck i've been having lately, its probably not a bad assertion to make :) |
| 16:24.30 | phani | i am interested in this |
| 16:24.45 | starseeker | dloman: I just ment sorting out directory organization and whatnot |
| 16:25.02 | starseeker | phani: ah - ``Erik knows the most about that subject |
| 16:25.08 | dloman | heh, i added a libge/ dir to src/ .....thats about it! |
| 16:25.26 | starseeker | dloman: cool, that should be fine for now |
| 16:26.04 | phani | ok... will contact eric then |
| 16:26.07 | starseeker | phani: did you have any particular questions? |
| 16:27.01 | starseeker | phani: another image related task would be openexr support |
| 16:27.07 | phani | i wanted to ask more about the project |
| 16:27.33 | starseeker | phani: go ahead - ``Erik and brlcad both read backlogs |
| 16:28.02 | phani | i could not find any other project on image processing there |
| 16:28.05 | starseeker | IRC isn't always real-time communication - you generally stay logged in, post a question, and sometimes get a response later |
| 16:28.07 | phani | can you give me the link to it ? |
| 16:28.36 | starseeker | http://brlcad.org/wiki/High_Dynamic_Range_Support |
| 16:29.17 | phani | thanks |
| 16:30.05 | starseeker | phani: one of the first things to do for any project is to make sure you can compile and run BRL-CAD |
| 16:30.53 | starseeker | the work that has been done so far for the libbu image task is in src/libbu and src/libicv, if I recall correctly |
| 16:30.54 | phani | ok. Will do that now. |
| 16:31.40 | starseeker | phani: since any project will involve a lot of work in the codebase, you want to make sure it's something you feel like you can work in/with |
| 16:32.34 | phani | i like image processing very much and i have considerable command over it. I would like to get some experience on open source coding on that subject |
| 16:32.46 | starseeker | phani: when you check out the subversion source, be sure to get just trunk: |
| 16:32.57 | starseeker | svn co https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/trunk brlcad |
| 16:33.27 | starseeker | phani: note that BRL-CAD is a solid modeler, not primarily an image related system |
| 16:34.01 | phani | yes, of course ... |
| 16:34.10 | CIA-52 | BRL-CAD: 03davidloman * r43933 10/rt^3/trunk/src/ (5 files in 3 dirs): Okay, I think i have libGE piggybacking ontop of coreInterface correctly now. Changes to build system have been made. Daniel, please let me know if I broke anything for ya! |
| 16:34.44 | dloman | okay, so how does one setup an svn external? |
| 16:35.19 | starseeker | phani: not to drive you away, but in the interests of covering your options you've also looked at the OpenCV project? |
| 16:37.02 | starseeker | you can submit multiple applications |
| 16:37.54 | CIA-52 | BRL-CAD: 03davidloman * r43934 10/geomcore/trunk/src/ (13 files in 10 dirs): Move some older dev files into an appropriate directory for now. |
| 16:38.35 | phani | yes ... opencv and astronomy.net are the other organizations i am interested in ... |
| 16:47.01 | CIA-52 | BRL-CAD: 03davidloman * r43935 10/geomcore/trunk/src/ (CMakeLists.txt GE/ libNet/CMakeLists.txt): Remove GE from Geomcore. Its going to be its own module.... eventually. |
| 16:47.53 | dloman | Okay, there. GE should be completely in rt3 now, and is piggy backed off of coreInterface. |
| 16:48.32 | dloman | Now on to wiring up geomcore to find libGE and start working the DataManager/DataSource stuff..... |
| 16:48.44 | starseeker | nods |
| 16:53.09 | brlcad | how about simply ge, gs, and gui? |
| 16:53.42 | starseeker | works for me |
| 16:53.43 | brlcad | not really fond of the word sandbox as it implies there are few/no rules and that shouldn't really be the case for any code committed to the repository |
| 16:53.56 | brlcad | relaxed, sure, but sandbox implies more free-for-all to me |
| 16:54.41 | brlcad | hello phani |
| 16:55.14 | starseeker | ge/gs/gui works for me |
| 16:56.54 | brlcad | phani: there are lots of potential image processing related projects in BRL-CAD |
| 16:57.42 | brlcad | there are a few other orgs that are interested in image processing, fwiw, but we definitely have at least two of high interest -- the two mentioned already |
| 16:59.43 | phani | i am looking at the links given by starseeker ... I am also compiling BRL-CAD now. |
| 16:59.51 | brlcad | phani: if you're looking through our source tree, also of interest will be src/util where there are more than 100 image processing tools from image converters, wavelet transforms, filters, scalers, and much more |
| 17:00.31 | brlcad | most of them have man pages and are simply one file per binary |
| 17:00.43 | brlcad | so you can just scan through the *.c or *.1 files |
| 17:00.54 | phani | ok... |
| 17:01.24 | starseeker | brlcad: I chimed in in the Qt discussion on the list, so you may need to smack me down ;-) |
| 17:01.31 | brlcad | there's also src/sig for more general "signal processing" which generally applies to 1D data stremas, but sometimes to 2D streams as well |
| 17:02.58 | phani | I will look at these things now and will contact you back as soon as possible. Its already late night here. |
| 17:02.58 | brlcad | phani: as you're probably already finding out, BRL-CAD is a *very* large system -- we know that and don't expect you to know what's there or how to find things easily, so please do ask questions if you have them |
| 17:03.02 | CIA-52 | BRL-CAD: 03Willdye 07http://brlcad.org * r2617 10/wiki/Building_from_SVN: Give an example for Ubuntu users who don't have autoconf installed |
| 17:03.36 | phani | Thanks for letting me know where to start. I got a very good intro. Will look at it in detail |
| 17:03.47 | phani | and will ask you doubts soon |
| 17:03.51 | brlcad | starseeker: comments sounded spot on to me |
| 17:03.59 | brlcad | matched up with what I was saying in not so many words |
| 17:04.04 | starseeker | brlcad: heh |
| 17:04.40 | starseeker | had viewed the Qt approach as replacing the X11 dm, in the same way that OGRE "replaces" dm-ogl/wgl |
| 17:05.41 | starseeker | growls at subversion... come on, how do I get a list of files... |
| 17:05.48 | brlcad | phani: if you're really into image processing, you have the potential to turn BRL-CAD into your playground (regardless of GSoC) implementing ideas, research, new tools, etc |
| 17:06.46 | brlcad | so while libicv might be something we're interested in from an architecture standpoint, we're more interested getting new long term developers -- so if you have a long term interest there -- then cater your project proposal around that long term interest so you can and will want to keep working on it long after GSoC is over |
| 17:07.05 | brlcad | we want devs more than we want their code ;) |
| 17:08.02 | brlcad | gsoc participants that can convince us of that are an easy shoe-in |
| 17:17.53 | *** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 ETA 20110325 || Welcome GSoC 2011 participants! Speak up, ask questions, start here: http://brlcad.org/wiki/Google_Summer_of_Code/2011 | |
| 17:33.42 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2618 10/wiki/Google_Summer_of_Code: /* Overview */ |
| 17:44.02 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2619 10/wiki/Google_Summer_of_Code: don't repeat ourselves, we list the application guidelines on the checklist. link to the 2011 page. |
| 17:48.32 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2620 10/wiki/Google_Summer_of_Code/2011: link back to main page |
| 18:16.51 | *** join/#brlcad crazy_imp (~mj@a89-182-15-254.net-htp.de) | |
| 18:16.53 | crazy_imp | heyho |
| 18:17.08 | crazy_imp | is it possible to export everything from a .g file with g-stl ? |
| 18:31.17 | CIA-52 | BRL-CAD: 03starseeker * r43936 10/geomcore/trunk/tests/svntest/main.c: Switch back to ktank, make some initial progress on listing out directory contents. |
| 18:32.37 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2621 10/wiki/Google_Summer_of_Code: mention 2010 |
| 18:34.12 | brlcad | crazy_imp: sure, assuming there are no geometry errors and you don't hit a problematic conversion case |
| 18:34.38 | brlcad | you need to know the names of the top-level objects, which can be obtained with: mged -c file.g tops |
| 18:37.15 | crazy_imp | brlcad: i thought of something like this: g-stl .. -o foo.stl foo.g `mged -c foo.g tops` but it doesn't work |
| 18:37.46 | crazy_imp | (i really want something like "g-stl .... foo.g \*" :) |
| 19:12.22 | brlcad | crazy_imp: mged's output by default goes to stderr, so you'd have to run mged -c foo.g tops 2>&1 for that to work |
| 19:13.45 | brlcad | a problem and one of the reasons why you have to specify which geometry objects is because the .g container supports multiple models (multiple hierarchies of models at that) whereas STL only supports a single model |
| 19:15.07 | crazy_imp | brlcad: so i should simply design everything inside one file (at least if it's logical to do so) inside one group for easier converting? |
| 19:17.34 | brlcad | IFF you convert your model to BoT (mesh) format, you might have better luck with something like: mged -c foo.g bot_dump -t stl -o foo.stl |
| 19:17.42 | brlcad | that will dump all BoT objects to files |
| 19:18.13 | brlcad | converting objects to BoT beforehand is done with the facetize command or during import from a polygonal converter |
| 19:19.10 | brlcad | and yes, you very likely will design everything in one file and construct objects together based on their material compositions that need to be differentiated |
| 19:19.31 | brlcad | the principles of effective modeling go into proper modeling best practices in more detail |
| 19:20.34 | *** join/#brlcad Ralith (~ralith@d142-058-175-170.wireless.sfu.ca) | |
| 19:20.42 | crazy_imp | right now i just want to use it for 2.5D modeling ;) |
| 19:44.37 | CIA-52 | BRL-CAD: 03starseeker * r43937 10/geomcore/trunk/tests/svntest/main.c: Re-assemble ktank.g into a staging area. |
| 20:17.10 | PrezKennedy | brlcad, i sent my brother a link to that picture you showed me |
| 21:03.18 | *** join/#brlcad dli (~dli@dyn-216-087.wireless.concordia.ca) | |
| 21:14.03 | CIA-52 | BRL-CAD: 03bob1961 * r43938 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Minor mod to Ged::handle_data_move to not load data for _pane. |
| 21:22.10 | CIA-52 | BRL-CAD: 03brlcad * r43939 10/brlcad/trunk/HACKING: add CADCAM insider to our distribution list |
| 21:24.38 | CIA-52 | BRL-CAD: 03starseeker * r43940 10/geomcore/trunk/tests/svntest/main.c: |
| 21:24.38 | CIA-52 | BRL-CAD: Handle naming (very) slightly better. Maybe need UUID to ensure each connection |
| 21:24.38 | CIA-52 | BRL-CAD: can get its own workspace for assembling geometry from checkouts for return |
| 21:24.38 | CIA-52 | BRL-CAD: shipment down the socket? Or do I need recursive checkout and dbconcat based on |
| 21:24.39 | CIA-52 | BRL-CAD: comb contents for sub-checkouts? (or both?) |
| 21:33.12 | CIA-52 | BRL-CAD: 03starseeker * r43941 10/geomcore/trunk/tests/svntest/main.c: Supply the .g file as an argument, so we can try multiple files without recompiling |
| 22:16.49 | brlcad | starseeker: where do all of the palloc() allocations in src/librt/search.c get freed? |
| 22:20.51 | CIA-52 | BRL-CAD: 03brlcad * r43942 10/brlcad/trunk/NEWS: per r43399, bob fixed a bug in the wgl display manager where it was broken when drawing strings with line breaks in them. now skips no pixels or rows. |
| 22:23.47 | CIA-52 | BRL-CAD: 03brlcad * r43943 10/brlcad/trunk/src/burst/grid.c: VINIT_ZERO instead of constant init. |
| 22:24.40 | starseeker | brlcad: hmm - I think it's up to the function that called db_search_formplan to free it |
| 22:25.02 | brlcad | starseeker: also plan on submitting the iwidgets ttk change upstream, any reason not to? |
| 22:26.04 | brlcad | hm, so search.c has a leak then? it doesn't free the dbplan that it received |
| 22:26.12 | brlcad | looks like it's some sort of nested allocation structure? |
| 22:26.45 | starseeker | brlcad: urm, yeah it's possible search has a leak (may have always had it, for that matter) |
| 22:27.06 | starseeker | brlcad: I can try - don't know what the iwidgets take is on ttk |
| 22:27.15 | brlcad | if you have a valgrind handy, that'd probably be a good one to slip in sometime |
| 22:27.40 | brlcad | don't know how much allocation that is, or if it's just a matter of free'ing the main pointer |
| 22:28.45 | brlcad | it can't introspect it at the libged level because it's a void*, all callers can do is free that |
| 22:30.53 | starseeker | nods - I'm knee deep in subversion at the moment, but I'll try to take a look) |
| 22:31.05 | brlcad | np |
| 22:35.11 | brlcad | yeah, looks like the db_plan_t is a linked list |
| 22:45.07 | brlcad | starseeker: huh, the find implementation that you used apparently never bothers to free any memory |
| 22:45.22 | starseeker | oops |
| 22:45.23 | brlcad | undoubtedly because the application quickly exits |
| 22:45.31 | starseeker | sorry about that |
| 22:45.34 | brlcad | which is fine, bad form but fine, for a binary |
| 22:45.45 | brlcad | problem for a library, since the leak will accumulate |
| 22:45.52 | brlcad | not your fault |
| 22:45.57 | starseeker | should have checked that <puts on programmer dunce cap> |
| 22:55.33 | CIA-52 | BRL-CAD: 03starseeker * r43944 10/geomcore/trunk/tests/svntest/main.c: Add some timing code in. Also try to get cute and call g_diff on the reassembled file, but that's not perfect yet. |
| 22:58.03 | CIA-52 | BRL-CAD: 03brlcad * r43945 10/brlcad/trunk/ (include/raytrace.h src/librt/search.c): |
| 22:58.03 | CIA-52 | BRL-CAD: implement a db_search_freeplan() to go with the db_search_formplan() function. |
| 22:58.03 | CIA-52 | BRL-CAD: releases the allocated db_plan_t linked list structures acquired during a given |
| 22:58.03 | CIA-52 | BRL-CAD: plan formulation. looks like the original source code for find never bothered |
| 22:58.03 | CIA-52 | BRL-CAD: to release any memory, but we have to be more careful since we're in a library. |
| 22:58.36 | starseeker | brlcad: awesome, thanks for swatting that |
| 23:00.14 | CIA-52 | BRL-CAD: 03brlcad * r43946 10/brlcad/trunk/src/libged/search.c: call db_search_free() to release our dbplan allocations. this should prevent/reduce memory leakness across subsequent calls. untested but testing now. |
| 23:00.38 | brlcad | nods |
| 23:03.49 | CIA-52 | BRL-CAD: 03brlcad * r43947 10/brlcad/trunk/NEWS: bob added pix2fb and corresponding fb2pix commands to archer as a means to capture the contents of the framebuffer to a pix image file. useful for screenshots and image overlaying |
| 23:03.54 | brlcad | all commits now reviewed, testing release |
| 23:05.46 | starseeker | brlcad: this should be up your alley: http://pastebin.mozilla.org/1190541 |
| 23:07.16 | brlcad | starseeker: what was the benefit for the ttk scrollbar change? |
| 23:07.36 | brlcad | looks |
| 23:08.17 | brlcad | hm, odd |
| 23:08.25 | brlcad | shouldn't take 38 seconds to reassemble |
| 23:09.24 | brlcad | cat **/*.g only took 0.05 seconds or something from the shell, that's the base time to scan all dirs, open all files, read/write all file data |
| 23:09.38 | brlcad | (for havoc) |
| 23:10.29 | starseeker | I'm using the svn list function, which may introduce some overhead |
| 23:10.43 | starseeker | I don't think I'm going to keep doing it with that function, it's not well suited to this use |
| 23:11.09 | starseeker | is cat faster than db_concat? |
| 23:11.21 | brlcad | not much difference |
| 23:11.27 | starseeker | brlcad: uniformity of appearance in archer |
| 23:11.46 | starseeker | we had switched all our other scrollbars to ttk - the iwidget window was the odd man out |
| 23:11.53 | brlcad | don't want to just cat them, that's more to understand that it's not in the file I/O at least |
| 23:12.02 | brlcad | dbconcat makes sure there aren't name collisions |
| 23:12.15 | brlcad | that might take a sec or two, but definitely not 38s |
| 23:12.18 | starseeker | nods |
| 23:12.31 | brlcad | okay, cool wrt iwidgets |
| 23:12.37 | brlcad | was just wondering what I should write them :) |
| 23:12.43 | starseeker | heh |
| 23:12.49 | brlcad | you make the edits or bob or both? |
| 23:13.08 | starseeker | thinks back... that was me, but Bob told me where to look |
| 23:13.18 | starseeker | and what to remove to avoid some errors |
| 23:13.55 | brlcad | k |
| 23:14.12 | starseeker | has yet to integrate itcl into his working knowledge base |
| 23:15.30 | brlcad | https://sourceforge.net/tracker/?func=detail&aid=3238914&group_id=13244&atid=383689 |
| 23:15.32 | starseeker | I was trying to use svn's list command as a convenient way to get a list of the files I needed to work with, but it's optimized to print out results to the command line |
| 23:16.15 | starseeker | brlcad: cool, thanks! |
| 23:16.44 | brlcad | http://www.devmaster.net/news/index.php?storyid=2663 |
| 23:16.46 | starseeker | bets they're surprised to see anyone still using it |
| 23:17.21 | brlcad | bets they're not |
| 23:17.26 | brlcad | have you met any of the tcl guys? :) |
| 23:17.31 | starseeker | hehe - point |
| 23:18.16 | starseeker | had kind of gotten the impression that tcllib and tklib were gaining more of a following |
| 23:18.27 | starseeker | http://www.tcl.tk/software/tcllib/ |
| 23:21.41 | starseeker | 'course, bwidget still gets used too... oh, well |
| 23:21.48 | starseeker | if it works it works |
| 23:24.09 | brlcad | cool, looks like I didn't bust search |
| 23:47.24 | CIA-52 | BRL-CAD: 03starseeker * r43948 10/geomcore/trunk/tests/svntest/main.c: Add a note on what to do about replacing svn_client_list2 |
| 00:11.20 | bhinesley | what handles the main mged exit "X" GUI button? |
| 00:13.33 | bhinesley | is done grepping :) |
| 00:13.58 | starseeker | heh - you found it? |
| 00:14.10 | bhinesley | no, I've been looking for a while |
| 00:14.21 | bhinesley | I figured it was time to ask |
| 00:14.52 | starseeker | IIRC that involves either signal handling or Tk bindings |
| 00:15.22 | starseeker | take a look at the exit or quit commands |
| 00:15.55 | bhinesley | yeah, that's what I've been doing. That, and the tcl files |
| 00:16.17 | starseeker | I'll have to ask our expert tomorrow - I confess I don't know the details of that right offhand |
| 00:16.40 | starseeker | Tcl/Tk is kind of annoying in that respect - debugging usually involves lots of print statements |
| 00:17.04 | starseeker | most of the debuggers I know about are commercial :-( |
| 00:17.47 | starseeker | The only open source one I know of is http://www.compassis.com/ramdebugger/ |
| 00:18.00 | starseeker | and I've never actually gotten it working with MGED or Archer |
| 00:18.10 | starseeker | ('course I didn't try real hard) |
| 00:20.37 | starseeker | bhinesley: oh, I'll bet this is it - look for instances of WM_DELETE_WINDOW |
| 00:21.02 | bhinesley | I have been |
| 00:21.33 | starseeker | http://www.tcl.tk/man/tcl8.5/TkCmd/wm.htm |
| 00:21.50 | bhinesley | I guess I'll pursue that a little further |
| 00:21.58 | starseeker | the details of the window distruction are handled by Tk, IIRC |
| 00:22.44 | starseeker | the "X" button is actually the responsibility of the window manager |
| 00:23.17 | starseeker | so when you click on that "X", a WM_DELETE_WINDOW event (or something similar) is generated |
| 00:23.57 | starseeker | supposes if he's suggesting Tcl/Tk projects he should make another stab at figuring out how to hook up RamDebugger... |
| 00:24.35 | starseeker | bhinesley: are you running into problems with closing windows? |
| 00:25.26 | bhinesley | well, I was trying to work on a bug |
| 00:25.37 | starseeker | ah, very good :-) |
| 00:25.40 | starseeker | which bug? |
| 00:26.42 | bhinesley | I believe these two may be related, and not specific to Windows as it appears: |
| 00:26.44 | bhinesley | https://sourceforge.net/tracker/?func=detail&aid=2278072&group_id=105292&atid=640802 |
| 00:26.44 | bhinesley | https://sourceforge.net/tracker/?func=detail&aid=1961127&group_id=105292&atid=640802 |
| 00:28.25 | starseeker | bhinesley: note that at least the second one reports using a VERY old version of BRL-CAD, so it might be worth trying to reproduce the problem first |
| 00:28.59 | bhinesley | I am experiencing a similar problem in Fedora |
| 00:29.07 | starseeker | ah, really! |
| 00:29.12 | bhinesley | actually... I've tested it in windows, too |
| 00:29.21 | starseeker | very good |
| 00:29.53 | starseeker | brlcad may have more insight on how all that's wired together |
| 00:30.41 | starseeker | bhinesley: a possible suggestion would be to try to simplify the problem down - if you create a tk window displaying a png file (say) and close it, does it have the same problem? |
| 00:30.56 | starseeker | that might indicate a Tk issue |
| 00:31.33 | bhinesley | hmm, okay, I will try that in a little bit If I cannot isolate it to one of the WM_DELETE_WINDOW's |
| 00:32.15 | starseeker | another question is is it Tk specific? |
| 00:32.20 | bhinesley | the code for the 'q', 'quit', and 'exit' commands works properly |
| 00:32.37 | bhinesley | so does file-> exit (oddly) |
| 00:32.53 | starseeker | so one possibility is to make sure the WM_DELETE_WINDOW calls are triggering the same logic |
| 00:33.05 | starseeker | if you want to try without Tk, do mged -c |
| 00:33.10 | starseeker | then pick nu |
| 00:33.17 | starseeker | non-graphical mged ;-) |
| 00:33.58 | starseeker | do that in one terminal, close the terminal without quitting, the check the status of the file from a different terminal |
| 00:34.41 | brlcad | bhinesley: which platform are you on? |
| 00:34.59 | brlcad | ah, fedora .. just catching up |
| 00:35.10 | bhinesley | :) hello |
| 00:35.37 | brlcad | yeah, the issue is cross platform -- I think our code that used to pick up with window-close event from tk-land is no longer being handled or at least no longer being handled sufficiently, so mged doesn't shut down |
| 00:37.27 | brlcad | lets see if I can get this right -- it's supposed to close the application if the graphics window is closed, but keep mged running if only the command window is closed |
| 00:38.06 | starseeker | blinks - really? is there a way to start up a new command window from the GUI? |
| 00:38.28 | brlcad | I'm not real keen on that behavior frankly, so it's fair game to change -- I think it should either close both windows if you close either, or not shut down mged until both windows are closed regardless of which is closed first |
| 00:38.59 | brlcad | yeah, it would make total sense the other way around since you can keep reattaching new graphics windows |
| 00:39.17 | brlcad | I think the old reasoning was that you'd shut down the command window and just end up with a pure viewer |
| 00:39.41 | starseeker | votes for the other way |
| 00:39.52 | brlcad | that's fine, but closing the graphics window shouldn't close the command window.. |
| 00:39.55 | starseeker | the minimize button is a powerful tool |
| 00:39.59 | bhinesley | if closing the command window closes the graphics window, then perhaps the command window should just be modal, and only allow closing from the graphics window |
| 00:40.18 | bhinesley | wait, closing the graphics window should leave the command window up? |
| 00:40.39 | starseeker | that would be my vote. you can launch multiple graphics windows from the command prompt |
| 00:40.56 | bhinesley | hm okay, sounds backwards to me, but I'm from AutoCAD-world |
| 00:41.12 | starseeker | we're a trifle command line centric :-P |
| 00:41.16 | bhinesley | yeah |
| 00:41.43 | brlcad | depends if we're talking about what it "should" do, what it's "supposed" to do, or what it "presently" does? :) |
| 00:42.19 | starseeker | Archer is currently organized more around the traditional desktop app paradigm, but we hadn't gotten to addressing desired behavior there with respect to this question |
| 00:43.19 | bhinesley | well the Archer command window is embedded |
| 00:43.28 | brlcad | if we ignore "presently" and "supposed" behavior, what I'd want it to do is not have either the graphics window or command window close button quit the application unless it's the last window open |
| 00:43.30 | starseeker | bhinesley: you can detach it :-) |
| 00:43.34 | bhinesley | ah I see now :) |
| 00:44.14 | bhinesley | brlcad: ok |
| 00:44.17 | starseeker | brlcad: yeah, I was thinking that too - as long as you can launch display managers from the command prompt, and command prompts from the display, you're fully up as long as you have a window |
| 00:44.21 | bhinesley | I have to leave guys, I'll bbl |
| 00:44.27 | bhinesley | thanks, bye |
| 00:44.30 | starseeker | bhinesley: bye! |
| 00:44.37 | brlcad | bhinesley: something to keep in mind while testing is you can "attach X" as many times as you like from the command window, you can also run mged -c to get classic mode and then run "gui" to start up the tcl/tk gui |
| 00:45.23 | starseeker | realizes he has to get up at 5am and heads home... |
| 00:45.32 | brlcad | wee |
| 00:45.48 | brlcad | encounters compilation success! |
| 00:57.04 | brlcad | pretty impressive mesh manipulation tool http://www.meshmixer.com/ |
| 01:02.53 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2622 10/wiki/Google_Summer_of_Code/Project_Ideas: de-emphasize an idea of their own. want integrated code |
| 01:09.03 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2623 10/wiki/Google_Summer_of_Code/Project_Ideas: add programming languages potentially involved |
| 01:09.56 | *** join/#brlcad crazy_imp (~mj@a89-183-78-5.net-htp.de) | |
| 03:27.15 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2624 10/wiki/OGRE_Display_Manager: combine ogre and qt into the same topic |
| 03:27.24 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Qt Display Manager]]": merged in with the ogre idea |
| 03:27.50 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[OGRE Display Manager]] moved to [[Cross Platform Display Manager]]: rename post-merge |
| 03:28.13 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2627 10/wiki/Google_Summer_of_Code/Project_Ideas: merged |
| 03:29.12 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Other Cross Platform Framebuffer]] moved to [[Cross Platform Framebuffer]]: simplify |
| 03:36.46 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2630 10/wiki/Cross_Platform_Framebuffer: merge in qt |
| 03:37.06 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Qt Framebuffer]]": no longer needed, merged with the more general cross-platform tasker |
| 03:37.39 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2631 10/wiki/Google_Summer_of_Code/Project_Ideas: merged framebuffer tasks, only need one |
| 03:44.24 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2632 10/wiki/Google_Summer_of_Code/Project_Ideas: recategorize the gui projects |
| 03:48.44 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 04:09.56 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Cross Platform Display Manager]] moved to [[New Cross-Platform 3D Display Manager]] |
| 04:10.13 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Cross Platform Framebuffer]] moved to [[New Cross Platform 2D Framebuffer]] |
| 04:10.53 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[New Cross Platform 2D Framebuffer]] moved to [[New Cross-Platform 2D Framebuffer]] |
| 04:12.33 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2639 10/wiki/Google_Summer_of_Code/Project_Ideas: make the task descriptions sub-context information |
| 04:22.28 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:BRL-CAD Priorities.png]]": Overview of our project scope, vision, mission, and main priorities. |
| 04:28.25 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2641 10/wiki/Google_Summer_of_Code/Project_Ideas: link in project priorities image |
| 04:43.42 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2642 10/wiki/Google_Summer_of_Code/Project_Ideas: bump up nurbs, priority |
| 06:16.43 | bhinesley | brlcad: is the project idea labeled "MGED to Archer Command Migration" considered a priority? |
| 06:25.26 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 06:47.23 | bhinesley | I'm leaning towards the MGED Sketch Editor Migration and Enhancement project, as suggested by starseeker |
| 06:54.56 | *** join/#brlcad bhinesley (~bhinesley@99.125.83.101) | |
| 07:19.50 | bhinesley | is there a mentor assigned to the MGED Sketch Editor Migration and Enhancement project? |
| 08:04.08 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 08:57.40 | *** join/#brlcad piksi (piksi@83.145.207.200) | |
| 09:55.40 | CIA-52 | BRL-CAD: 0399.125.83.101 07http://brlcad.org * r2643 10/wiki/User:Bhinesley: First profile post |
| 11:26.35 | dloman | Mernin all |
| 11:30.14 | dloman | bah, blast it all! I can't 'apply' to be a mentor cause their application process is 'down' in preps for the launch of their new GUI later this week. :/ |
| 11:40.40 | *** part/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 12:22.03 | brlcad | dloman: it's been that way since monday |
| 12:23.25 | brlcad | bhinesley: note that I would consider that project "hard" so you should define lots of small milestones |
| 12:24.14 | brlcad | we generally perform group mentoring so that you're not reliant upon getting answers from any one mentor |
| 12:24.34 | brlcad | bhinesley: as the current code is all Tcl and archer is predominantly Tcl, I hope you like Tcl :) |
| 12:25.40 | brlcad | that said, the three people most likely able to help you or get answers to your questions are going to be myself, starseeker, and "bob" who you'll probably only be able to talk to via e-mail (but is the foremost knowledgeable on all things Tcl) |
| 12:28.17 | brlcad | bhinesley: ah, missed your first question -- I would consider the command migration higher priority than sketch editing |
| 12:28.51 | brlcad | intends to spend a lot more time hashing out more ideas onto the ideas list today |
| 12:39.31 | dloman | brlcad: can the project lead send invites? ...or is that disabled also? |
| 12:42.08 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2644 10/wiki/New_Cross-Platform_3D_Display_Manager: |
| 12:43.56 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2645 10/wiki/Google_Summer_of_Code/Project_Ideas: put the ideas into a table for more concise readability |
| 12:48.48 | CIA-52 | BRL-CAD: 03davidloman * r43949 10/geomcore/trunk/ (2 files in 2 dirs): Verbage change: 'Data' to 'Path' ...makes more better cents. |
| 12:52.20 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2646 10/wiki/Google_Summer_of_Code/Project_Ideas: impact |
| 12:52.46 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2647 10/wiki/Google_Summer_of_Code/Project_Ideas: tablify |
| 12:54.09 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2648 10/wiki/Google_Summer_of_Code/Project_Ideas: Undo revision 2647 by [[Special:Contributions/Sean|Sean]] ([[User talk:Sean|Talk]]) |
| 12:55.43 | dloman | brlcad: are there any file IO functions in the brlcad libs for reading/writing plain ol files? |
| 12:59.31 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2649 10/wiki/Google_Summer_of_Code/Project_Ideas: tablify redux |
| 13:04.18 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2650 10/wiki/New_Cross-Platform_3D_Display_Manager: |
| 13:05.36 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2651 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Graphical User Interface (GUI) Projects */ |
| 13:05.56 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2652 10/wiki/New_Cross-Platform_2D_Framebuffer: new layout |
| 13:08.34 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2653 10/wiki/MGED_to_Archer_Command_Migration: new layout |
| 13:10.07 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2654 10/wiki/MGED_Sketch_Editor_Migration_and_Enhancement: new layout |
| 13:11.42 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2655 10/wiki/New_Cross-Platform_3D_Display_Manager: ogre/qt as refs |
| 13:12.26 | brlcad | dloman: also disabled |
| 13:13.35 | brlcad | dloman: if they're really "plain", then libc would be the most appropriate |
| 13:14.14 | brlcad | otherwise we have routines to read lines from files and map files to memory buffers that are commonly used |
| 13:16.48 | brlcad | routines for creating temp files, locating files, logging to a file, reading/writing strings to files |
| 13:17.31 | brlcad | what are you trying to do? |
| 13:19.38 | dloman | simple check if a directory exists |
| 13:19.54 | dloman | wanted to use a brlcad way to do it since there's a larger chance it will be cross platform ;) |
| 13:20.05 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2656 10/wiki/Google_Summer_of_Code/Project_Ideas: bgcolor |
| 13:21.06 | *** join/#brlcad Elrohir (~kvirc@p5B14BA4E.dip.t-dialin.net) | |
| 13:23.14 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2657 10/wiki/Google_Summer_of_Code/Project_Ideas: smaller priorites link, push to top |
| 13:28.45 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2658 10/wiki/New_Cross-Platform_3D_Display_Manager: medium |
| 13:30.43 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2659 10/wiki/NURBS_Intersections: new layout, add references |
| 13:32.47 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2660 10/wiki/Google_Summer_of_Code/Project_Ideas: kiss |
| 13:34.50 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2661 10/wiki/NURBS_Tessellation: new layout, add references |
| 13:35.37 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2662 10/wiki/NURBS_Tessellation: redundant to repeat title |
| 13:36.05 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2663 10/wiki/NURBS_Intersections: dry |
| 13:36.23 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2664 10/wiki/New_Cross-Platform_3D_Display_Manager: dry |
| 13:38.01 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2665 10/wiki/CSG_to_NURBS_conversion: refs |
| 13:41.56 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2666 10/wiki/New_Cross-Platform_3D_Display_Manager: dry |
| 13:42.08 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2667 10/wiki/NURBS_Intersections: dry |
| 13:42.19 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2668 10/wiki/NURBS_Tessellation: dry |
| 13:43.59 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2669 10/wiki/Plate_Mode_NURBS_raytracing: code refs |
| 13:46.33 | brlcad | dloman: search include/bu.h for "directory" .. there are two or three specifically for that |
| 13:49.19 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2670 10/wiki/Google_Summer_of_Code/Project_Ideas: CSG is the operator, not the entity type |
| 13:49.48 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[CSG to NURBS conversion]] moved to [[Implicit to NURBS conversion]]: CSG is an operator, not a type |
| 14:05.11 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2673 10/wiki/Google_Summer_of_Code/Project_Ideas: add a code refactoring section, move refactoring tasks up into it |
| 14:05.31 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2674 10/wiki/New_Cross-Platform_2D_Framebuffer: dry |
| 14:05.53 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2675 10/wiki/MGED_to_Archer_Command_Migration: dry |
| 14:06.09 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2676 10/wiki/MGED_Sketch_Editor_Migration_and_Enhancement: dry |
| 14:08.16 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2677 10/wiki/Ayam_Editor_Feature_Integration: new layout, add refs |
| 14:09.10 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2678 10/wiki/New_Cross-Platform_2D_Framebuffer: consistency |
| 14:10.44 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2679 10/wiki/Analytical_Raytracing_Visualization: new layout, refs |
| 14:13.21 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2680 10/wiki/Level_of_Detail_Wireframes: new layout, add references |
| 14:14.17 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2681 10/wiki/BoT_Editing: new layout, add references |
| 14:15.52 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2682 10/wiki/NMG_Editing: new layout, add references |
| 14:16.23 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2683 10/wiki/NMG_Editing: /* Requirements */ |
| 14:17.31 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2684 10/wiki/Graph_layout_based_geometry_hierarchy_view: new layout, add references |
| 14:18.07 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2685 10/wiki/Graph_layout_based_geometry_hierarchy_view: /* References */ |
| 14:29.42 | dloman | starseeker: http://svnbook.red-bean.com/en/1.5/svn.developer.usingapi.html#svn.developer.usingapi.urlpath |
| 14:30.20 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2686 10/wiki/Google_Summer_of_Code/Project_Ideas: expand all of the gui projects |
| 14:46.33 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2687 10/wiki/Google_Summer_of_Code/Project_Ideas: expand the rest of the sections with table views, impact, and difficulty |
| 14:48.16 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2688 10/wiki/Google_Summer_of_Code/Project_Ideas: move step up |
| 15:04.21 | dloman | brlcad: thanks! |
| 15:05.35 | bhinesley | brlcad: thanks for all of the info and new updates. I will reconsider my project choice in the light of this. |
| 15:08.32 | starseeker | brlcad: has subversion moved to the Apache license? |
| 15:09.56 | starseeker | http://svn.apache.org/repos/asf/subversion/trunk/LICENSE |
| 15:11.01 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2689 10/wiki/Google_Summer_of_Code/Project_Ideas: terse is so much more informative here. combine title with description and reduce to no more than two lines (on my wide screen) |
| 15:12.52 | starseeker | ah, crap - yep http://svn.apache.org/viewvc/subversion/trunk/LICENSE?revision=878444&view=markup |
| 15:14.35 | starseeker | yeah, this was the old one: http://svn.apache.org/viewvc/subversion/trunk/COPYING?revision=875073&view=markup&pathrev=878443 |
| 15:16.26 | *** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net) | |
| 15:16.33 | dloman | ...so are we incompatable with apache? |
| 15:19.06 | starseeker | http://www.apache.org/legal/3party.html |
| 15:19.33 | CIA-52 | BRL-CAD: 0399.125.83.101 07http://brlcad.org * r2690 10/wiki/User:Bhinesley: reconsidering project choice |
| 15:21.34 | CIA-52 | BRL-CAD: 0399.125.83.101 07http://brlcad.org * r2691 10/wiki/User:Bhinesley: /* BRL-CAD Project Proposal */ remove superfluous blank line |
| 15:22.19 | dloman | starseeker: that really reads for people trying to package stuff instde Apache products... not the other way around. :/ |
| 15:25.59 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2692 10/wiki/Google_Summer_of_Code/Project_Ideas: another awesome reduction |
| 15:36.46 | starseeker | dloman: yeah, but it works both ways, unless I'm missing something |
| 15:36.55 | starseeker | (quite possible) |
| 15:41.29 | starseeker | brlcad: I don't suppose you have those scripts you used to benchmark breaking up a file and reassembling it from the command line? Those might be a good way to try fossil with just a little tweaking |
| 15:45.32 | brlcad | using apache isn't a problem because we're not deriving or integrating, no more compatible/incompatible than a proprietary system using an apache product |
| 15:46.22 | brlcad | now that they've switched from a bsd-like license to apache, that does represent a problem to us in terms of integrating their code into ours and making updates -- has to stay separate or we have to change our license |
| 15:46.29 | brlcad | we can, however, still use them |
| 15:46.43 | brlcad | they can't use us is the bigger incompatibility |
| 15:47.03 | dloman | so... what about the eventual plan to make a FS-G back end? |
| 15:47.19 | dloman | with the current liscense... isn't that plan now out the window? |
| 15:47.20 | starseeker | brlcad: I thought we had been avoiding apache licensed stuff to avoid uncertainties about what code moved where... |
| 15:47.24 | brlcad | that's fine, we just can't bundle their sources together with ours |
| 15:47.52 | starseeker | so I should take the subversion directory out of geomcore |
| 15:48.26 | brlcad | if it's the full sources, probably -- should be fine in a separate module with svn:external set up |
| 15:49.04 | brlcad | source repo isn't a big deal, it's any published/distributed source tarballs where we'd have to be careful and not bundle them together |
| 15:49.22 | brlcad | and that's more just for perception, not necessarily legal requirement |
| 15:49.39 | dloman | So, if we put the svn code in a top level module licensed Apache, and make our FS-G code there.... then that's okay? |
| 15:50.03 | dloman | so long as GS and the FS-G 'products' are distinctly different... even though GS requires the FS-G ? |
| 15:50.21 | dloman | (Just making sure I understand things....) |
| 15:51.09 | brlcad | yeah, that can work |
| 15:51.35 | brlcad | it's really not that big a problem for us because apache is not viral like gpl/lgpl in imposing requirements on code it's combined with |
| 15:52.27 | brlcad | their license merely applies to their code, so if we ever combined their code with ours, the license terms would conflict (lgpl isn't a superset of apache) |
| 15:53.36 | brlcad | our lgpl can't apply to their code and their license can't apply to our code |
| 15:53.43 | dloman | okay then, so if our mythical fs-g module needs to have brlcad libraries as a dependancy... that's okay since the LGPL won't impose any restrictions on the fs-g's Apache license? |
| 15:54.15 | brlcad | so we can't make a blanket statement if it was bundled into a source tarball to say that "this collective work is lgpl" .. because we can't apply lgpl to their code -- it would merely be two projects with two licenses in one tarball |
| 15:55.05 | brlcad | it's "okay" in the sense that we can develop that module, make it lgpl, use our libs .. but it could never be integrated into svn proper |
| 15:55.58 | dloman | I am pretty sure the fs-g would need to be a *modified* version of svn, rather than something that uses svn as a dep |
| 15:56.38 | starseeker | would tend to agree |
| 15:59.02 | brlcad | it'd probably make more sense for fs-g to be apache licensed, and merely use brl-cad's libs as an installed but not bundled dependency |
| 15:59.31 | brlcad | as we'd be deriving from their existing fs-fs or other code anyways |
| 16:00.49 | brlcad | notes that many of these concerns become moot if we switched to the BSD license :) |
| 16:01.06 | dloman | 'we' being brlcad code? |
| 16:02.54 | brlcad | all brl-cad code, yes |
| 16:03.13 | brlcad | or mit |
| 16:03.19 | brlcad | or apache 2.0 for the patent grant |
| 16:03.27 | brlcad | either way, more flexibility |
| 16:03.56 | starseeker | brlcad: the original motivator for LGPL was to ensure some reciprocity, correct? |
| 16:05.25 | brlcad | and to abate concerns at the time of any entity forking brl-cad, making extensive valuable modifications, then trying to sell that derived version back to the gov't |
| 16:05.54 | brlcad | thinks he might have picked up whatever ed has |
| 16:06.01 | starseeker | doesn't that risk still exist? |
| 16:06.05 | starseeker | uh-oh |
| 16:07.25 | brlcad | sure, it still exists |
| 16:07.31 | brlcad | but it's not nearly as much of a concern any more |
| 16:08.06 | starseeker | we've established enough momentum now? |
| 16:08.20 | brlcad | after 7 years open source, I think so |
| 16:08.42 | brlcad | at worse, the risk is minimized as much as reasonably possible |
| 16:08.51 | starseeker | nods |
| 16:09.30 | brlcad | moreover, the benefits of allowing unencumbered use, whether commercial or not, would still benefit the brl-cad open source community and gov't regardless |
| 16:10.12 | brlcad | even if their changes were never released or integrated, it would be more .g files floating around, brl-cad libraries being used, etc |
| 16:10.18 | brlcad | anyways, not a problem that needs solving today |
| 16:10.23 | starseeker | right |
| 16:47.47 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2693 10/wiki/Google_Summer_of_Code/Project_Ideas: more awesome |
| 16:51.21 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2694 10/wiki/General_Tree_Walker: new layout, add references |
| 16:52.20 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2695 10/wiki/Rework_of_libbu/libbn_to_not_require_Tcl: new layout, add references |
| 16:55.18 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2696 10/wiki/Complete_bu_image/libicv_and_redo_all_pix_tools_to_use_it: new layout, add references |
| 16:55.58 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Complete bu image/libicv and redo all pix tools to use it]] moved to [[Consolidate image processing]] |
| 16:57.09 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2699 10/wiki/Google_Summer_of_Code/Project_Ideas: new name |
| 16:57.50 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2700 10/wiki/Consolidate_image_processing: |
| 17:02.18 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[MGED Sketch Editor Migration and Enhancement]] moved to [[2D Sketch Editor]] |
| 17:04.36 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Analytical Raytracing Visualization]] moved to [[GUI Integration of Analysis Tools]] |
| 17:05.02 | starseeker | brlcad: wow that looks nice |
| 17:05.09 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Graph layout based geometry hierarchy view]] moved to [[Visualizing Constructive Solid Geometry (CSG)]] |
| 17:05.27 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2707 10/wiki/Google_Summer_of_Code/Project_Ideas: new names |
| 17:07.53 | ``Erik | hm, apache license 2.0 is compatible with GPLv3, if that means anything |
| 17:08.09 | starseeker | ``Erik: yeah, I think it primarily has to do with the patent stuff |
| 17:08.53 | starseeker | sucky that some projects are LGPL2 only, some are LGPL3 only - makes me appreciate the simplicity of BSD/MIT |
| 17:09.20 | starseeker | I finally (belatedly) contacted the NURBS++ author, but wasn't able to sell him on BSD |
| 17:11.14 | ``Erik | the fork risk is probably greatly diminished, there was a core competency migration from the dangerous group O.o :D |
| 17:12.01 | starseeker | hehe |
| 17:12.31 | starseeker | 'course, NURBS++ was LGPL2 with the later version clause, so that's somewhat better |
| 17:12.36 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2708 10/wiki/Google_Summer_of_Code/Project_Ideas: another one bites the dust |
| 17:12.38 | starseeker | s/was/is |
| 17:14.12 | starseeker | wish I could have found him before the takeover request went through, but only dug up his contact info months later |
| 17:14.22 | starseeker | oh, well - not like there was much going on with it |
| 17:14.56 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2709 10/wiki/Geometry_Conversion_Library: new layout, add references |
| 17:16.29 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2710 10/wiki/Voxelize: new layout, add references |
| 17:17.47 | CIA-52 | BRL-CAD: 03erikgreenwald * r43950 10/geomcore/trunk/src/GS/DataManager.cxx: getData changed to getPath |
| 17:20.42 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2711 10/wiki/IGES_import_improvements: |
| 17:21.50 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2712 10/wiki/STEP_Libraries: new layout, add references |
| 17:22.01 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2713 10/wiki/IGES_import_improvements: ws |
| 17:22.24 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2714 10/wiki/IGES_import_improvements: |
| 17:36.21 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2715 10/wiki/Google_Summer_of_Code/Project_Ideas: more awesome expansion |
| 17:36.49 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2716 10/wiki/GED_Transactions: new layout, add references |
| 17:37.49 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2717 10/wiki/Add_exec_option_to_search: new layout, add references |
| 17:38.54 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2718 10/wiki/Geometry_Selection_Functionality: new layout, add references |
| 17:40.45 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2719 10/wiki/Geometric_Constraint_Solver: new layout, add references |
| 17:43.38 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2720 10/wiki/Space_Partitioning_for_Tessellation: new layout, add references |
| 17:46.33 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2721 10/wiki/Libsvn_within_Geometry_Database_Format: new layout, add references |
| 17:56.39 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2722 10/wiki/Google_Summer_of_Code/Project_Ideas: final awesome restructure |
| 17:57.43 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2723 10/wiki/Shader_Enhancements: new layout, add references |
| 17:58.36 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2724 10/wiki/Shader_Enhancements: refs |
| 17:59.40 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2725 10/wiki/Material_and_Shader_Objects: new layout, add references |
| 18:01.21 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2726 10/wiki/NMG_Raytracing_Performance_Improvement: new layout, add references |
| 18:02.25 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2727 10/wiki/Generalized_abstracted_spacial_partitioning_capability: new layout, add references |
| 18:03.59 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2728 10/wiki/High_Dynamic_Range_Support: new layout, add references |
| 18:05.23 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2729 10/wiki/Vector_output_from_raytracing: new layout, add references |
| 18:07.01 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2730 10/wiki/Analysis_Library: new layout, add references |
| 18:08.01 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2731 10/wiki/Analysis_Library: /* References */ |
| 18:11.44 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2733 10/wiki/Google_Summer_of_Code/Project_Ideas: overlap tool is geometry processing |
| 18:12.55 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2734 10/wiki/Overlap_tool: new layout, add references |
| 18:13.31 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2735 10/wiki/Google_Summer_of_Code/Project_Ideas: ws |
| 18:25.22 | CIA-52 | BRL-CAD: 03davidloman * r43951 10/geomcore/trunk/ (3 files in 2 dirs): Move DataManager Initialization over to the DataManager itself. |
| 18:28.59 | *** join/#brlcad Stattrav (~Stattrav@117.192.129.170) | |
| 18:29.08 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:30.12 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 18:40.16 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2736 10/wiki/Google_Summer_of_Code/Project_Ideas: add mentors |
| 18:40.50 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2737 10/wiki/Google_Summer_of_Code/Project_Ideas: |
| 18:40.58 | brlcad | woot, done |
| 18:42.29 | brlcad | "the patent thing" is actually what makes it incompat with gpl/lgpl v2, adds a new requirement which those licenses say you can't do |
| 18:42.38 | dloman | Nice! Im an 'expert modeler' ! |
| 18:42.43 | dloman | nice page btw brlcad ! |
| 18:42.52 | brlcad | also why gpl v2 and v3 are only compat in one direction |
| 18:42.58 | brlcad | thanks dloman |
| 18:43.21 | brlcad | starseeker and ``Erik did most of the hard work writing up all those topics |
| 18:44.30 | brlcad | felt kinda dirty putting 'guru' after NMG, but the poor guy needed something there |
| 18:45.04 | CIA-52 | BRL-CAD: 03starseeker * r43952 10/geomcore/trunk/tests/svntest/main.c: |
| 18:45.05 | CIA-52 | BRL-CAD: Start major reworking of our approach to svn - use lower level api. Whole new |
| 18:45.05 | CIA-52 | BRL-CAD: learning curve here, so everything that was previously working isn't - got it to |
| 18:45.05 | CIA-52 | BRL-CAD: compile, so checkpointing. Also gut all the old svn client code we were using |
| 18:45.05 | CIA-52 | BRL-CAD: to avoid license questions - figure out how to use the APIs from scratch with |
| 18:45.05 | CIA-52 | BRL-CAD: examples. |
| 18:45.38 | brlcad | heh |
| 18:46.04 | starseeker | one step forward, two steps back... sigh |
| 18:46.42 | dloman | and turn your self around... that's what its all about! |
| 18:47.10 | starseeker | oh, I'm alredy dizzy |
| 18:47.39 | brlcad | paula abdul loves you |
| 18:48.31 | starseeker | aaand another reference sails right over my head... :-P |
| 18:48.57 | brlcad | heh |
| 18:49.00 | brlcad | opposites attract! |
| 18:49.13 | brlcad | http://www.youtube.com/watch?v=xweiQukBM_k |
| 18:49.25 | starseeker | safe for work? |
| 18:49.29 | brlcad | just a song |
| 18:51.09 | brlcad | ahh, good ol' 80's music videos |
| 18:53.41 | CIA-52 | BRL-CAD: 03erikgreenwald * r43953 10/geomcore/trunk/src/GS/testclient/gstestclient.c: start cleaning up and simplying things |
| 18:56.30 | ``Erik | is there any reason to be pushing strings across the pipe as unicode16 instead of ascii? |
| 18:57.00 | starseeker | I was doing that because of the definition of the string type on the wiki |
| 18:57.04 | starseeker | or were you asking dloman ? |
| 18:57.10 | ``Erik | open question |
| 18:57.20 | dloman | i down graded them to 1 byte char strings.... last week i think. |
| 18:57.21 | ``Erik | suspects it's a qstring thing |
| 18:57.38 | dloman | qstring and java thing |
| 18:57.54 | starseeker | http://brlcad.org/wiki/GSNet_String |
| 18:58.06 | ``Erik | java has some dandy unicode16/ascii conversion stuff already in it |
| 18:58.25 | dloman | starseeker: thats out of date :( |
| 18:59.26 | CIA-52 | BRL-CAD: 03Dloman 07http://brlcad.org * r2738 10/wiki/GSNet_String: |
| 18:59.26 | starseeker | oh - are we all agreed on GS, GE and GUI for toplevel modules? |
| 18:59.49 | dloman | shakes magic 8ball. |
| 18:59.59 | dloman | .....Sounds good starseeker! |
| 19:00.26 | starseeker | magic8 ball... haven't seen one of those for many years |
| 19:02.45 | CIA-52 | BRL-CAD: 03davidloman * r43954 10/geomcore/trunk/ (include/FileDataSource.h src/GS/FileDataSource.cxx): Stub in init routine for FileDataSource |
| 19:06.23 | CIA-52 | BRL-CAD: 03davidloman * r43955 10/rt^3/trunk/include/ (70 files): Dump all the old GS header files. No longer needed here. |
| 19:14.26 | CIA-52 | BRL-CAD: 03starseeker * r43956 10/geomcore/trunk/tests/svntest/main.c: Oh yeah, need to init apr and friends. |
| 19:21.21 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2739 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Geometry Conversion Projects */ |
| 19:25.32 | CIA-52 | BRL-CAD: 03starseeker * r43957 10/geomcore/trunk/tests/svntest/main.c: Somewhat surprisingly, this approach to subdirectory addition works too. Files still aren't right |
| 19:27.27 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2740 10/wiki/Google_Summer_of_Code/Project_Ideas: add a couple more STEP tasks |
| 19:28.06 | CIA-52 | BRL-CAD: 03starseeker * r43958 10/geomcore/trunk/tests/svntest/main.c: And we can create empty files. |
| 19:28.45 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2741 10/wiki/Google_Summer_of_Code/Project_Ideas: |
| 19:35.59 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2742 10/wiki/STEP_exporter: New page: STEP is the current standard for exchange of CAD data between different software packages. BRL-CAD makes use of the NIST STEP Class Libraries code to support its step-g converter, but we ... |
| 19:40.22 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2743 10/wiki/STEP_importer_improvements: New page: STEP is the current standard for exchange of CAD data between different software packages. BRL-CAD makes use of the NIST STEP Class Libraries code to support its step-g converter, but th... |
| 19:42.45 | *** join/#brlcad hyarion (c05ben@peppar.cs.umu.se) | |
| 20:09.58 | CIA-52 | BRL-CAD: 03erikgreenwald * r43959 10/geomcore/trunk/src/GS/testclient/ (CMakeLists.txt gstestclient.c): complete rewrite. (hey, it works) |
| 20:11.59 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2744 10/wiki/Benchmark_Performance_Database: initial benchmark web interface idea |
| 20:17.14 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2745 10/wiki/Materials_Database: New page: BRL-CAD uses simple material properties, presently limited to density, for calculating weights, moments of inertia and other geometric analyses. There is presently no centralized reposito... |
| 20:18.23 | CIA-52 | BRL-CAD: 03erikgreenwald * r43960 10/geomcore/trunk/src/GS/testclient/gstestclient.c: cleanup the socket |
| 20:19.19 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2746 10/wiki/Materials_Database: |
| 20:19.55 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2747 10/wiki/Google_Summer_of_Code/Project_Ideas: add a couple web tasks with discouraging wording |
| 20:28.02 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2748 10/wiki/Fix_Bugs: initial bugs idea |
| 20:35.12 | CIA-52 | BRL-CAD: 03erikgreenwald * r43961 10/geomcore/trunk/src/GS/testclient/gstestclient.c: parse and print response packet |
| 20:37.06 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2749 10/wiki/Code_Reduction: code reduction |
| 20:37.16 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2750 10/wiki/Google_Summer_of_Code/Project_Ideas: add code reduction |
| 20:38.20 | brlcad | awesome, up to 42 project ideas now -- 47 if you count the other tool projects .. I think that's sufficient now :) |
| 20:38.33 | brlcad | has the new catch-all ones too |
| 20:39.59 | brlcad | starseeker: I'd prefer lowercase for top-level modules just for consistency (probably less error-prone for newbies), but not strong preference |
| 20:41.07 | brlcad | 16 byte strings across the wire will be 50% waste 99.9% of the time :) |
| 20:42.07 | brlcad | don't know of anyone even attempting to deal with 16-bit stringery at the moment |
| 20:42.23 | brlcad | maybe catia, but then they're french |
| 21:02.40 | starseeker | brlcad: sure, lower is fine |
| 21:06.11 | starseeker | ouch - Apple is now going to avoid Samba because of GPLv3 |
| 21:07.40 | starseeker | brlcad: the dynamic range one... IIRC (and I may not) another point there was to generate output images that fit better into image processing pipelines that make use of HDR |
| 21:08.23 | starseeker | not that that changes priority or anything, but I think that may have been the envisioned immediate practical consequence |
| 21:08.34 | starseeker | (HDR displays would be neat though...) |
| 21:08.59 | ``Erik | or like CMYK or YUV for printing or something |
| 21:46.05 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2751 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Mentors */ |
| 21:48.06 | brlcad | starseeker: the labels aren't really weighted well |
| 21:48.49 | brlcad | in the big scheme of things with the dozens of other "high" priority high impact topics on there, I think HDR is still *relatively* low impact yet it'd still be useful and cool to have |
| 21:48.54 | brlcad | immediately useful even |
| 21:49.09 | brlcad | the description can be reworded, didn't mean to downplay it if it comes off that way |
| 21:49.33 | starseeker | nah, it's cool |
| 21:49.46 | starseeker | don't know how much role it will play in submissions anyway |
| 21:49.54 | brlcad | as for the high/medium/low, I was actually considering a simple two-level instead of three |
| 21:50.24 | brlcad | HIGH and LOW do sound like they're being discouraged, though, when it's really meant to just emphasize the high ones |
| 21:50.26 | starseeker | baby-bottle and skull+crossbones? :-P |
| 21:50.33 | brlcad | heh |
| 21:51.06 | brlcad | maybe BIG and BIGGER |
| 21:52.04 | brlcad | ha, winner .. BIG and HUGE |
| 21:55.03 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2752 10/wiki/Google_Summer_of_Code/Project_Ideas: BIG AND BIGGEREST! |
| 21:58.08 | starseeker | wangs his head on the wall... why can't I get file content into files??? auugh |
| 22:30.03 | *** join/#brlcad dli (~dli@dyn-217-029.wireless.concordia.ca) | |
| 22:35.21 | CIA-52 | BRL-CAD: 03starseeker * r43962 10/geomcore/trunk/tests/svntest/main.c: OK, we're getting non-zero sized files now. No way to know if they're anything like correct yet. |
| 23:53.14 | CIA-52 | BRL-CAD: 03starseeker * r43963 10/geomcore/trunk/tests/svntest/ (CMakeLists.txt main.c): start working out how to reassemble using the lower level api... |
| 00:52.30 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 01:10.34 | *** join/#brlcad crazy_imp (~mj@a89-182-14-228.net-htp.de) | |
| 02:33.28 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 02:58.06 | *** join/#brlcad IriX64 (~IriX64@bas2-sudbury98-1096601295.dsl.bell.ca) | |
| 03:00.46 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 03:12.43 | *** join/#brlcad dli_ (~dli@dsl-173-248-203-45.acanac.net) | |
| 04:09.01 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 06:02.25 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 06:02.25 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:02.19 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 10:10.31 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 12:29.25 | CIA-52 | BRL-CAD: 03Rossberg 07http://brlcad.org * r2753 10/wiki/Google_Summer_of_Code/Project_Ideas: corrected my irc name |
| 13:26.07 | CIA-52 | BRL-CAD: 0368.34.98.23 07http://brlcad.org * r2754 10/wiki/Google_Summer_of_Code/Project_Ideas: group method of communicatio together |
| 13:41.06 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2755 10/wiki/Google_Summer_of_Code/Project_Ideas: extra info |
| 13:53.19 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 13:53.19 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:09.55 | *** join/#brlcad AbhijitKane7 (~Abhijit@111.93.5.194) | |
| 15:22.52 | *** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194) | |
| 15:23.27 | AbhijitKane | Hi, I intend to apply to BRLCAD thru the GSOC program, and work for the "Materials Database" project. |
| 15:23.37 | AbhijitKane | Is there any specific mentor associated with the project? |
| 15:32.13 | *** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de) | |
| 15:38.33 | brlcad | hi AbhijitKane, what draws you to that particular project? |
| 15:38.47 | brlcad | hello Zaebos |
| 15:39.02 | brlcad | saw your message on the mailing list as well |
| 15:40.10 | AbhijitKane | I've always been interested in web-related projects, and I think that a web interface would help a lot of people access the data that you have. |
| 15:40.31 | Zaebos | hi |
| 15:40.32 | brlcad | AbhijitKane: what are your thoughts for that project? |
| 15:40.41 | brlcad | what do you envision it entailing? |
| 15:41.46 | AbhijitKane | actually, thats what I wanted to clear |
| 15:41.52 | *** part/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de) | |
| 15:42.11 | AbhijitKane | At first glance, i thought it was a simple front-end to query the database |
| 15:43.03 | AbhijitKane | but I'm not sure what else is required to be done |
| 15:43.42 | brlcad | how much do you know about materials? |
| 15:43.49 | brlcad | and material properties |
| 15:44.15 | brlcad | it is a simple front-end to the database, but it also entails establishing the database |
| 15:44.28 | brlcad | setting up the schema |
| 15:44.58 | AbhijitKane | Not much. I've just done one course related to material properties - I haven't got any other exposure to the subject |
| 15:45.02 | brlcad | there was someone that actually worked on this project five or so years ago, but they never finished |
| 15:45.15 | brlcad | made great progress, but never got to production status |
| 15:45.34 | AbhijitKane | Oh, is that the "proof-of-concept web work of relevance" mentioned on the website? |
| 15:45.40 | brlcad | yes |
| 15:46.19 | brlcad | so your project could either leverage all that previous work as a starting point or you could start from scratch |
| 15:47.24 | brlcad | if you start from scratch, you'll need to do some basic research on materials science, so our database captures common properties sufficiently |
| 15:47.24 | AbhijitKane | Is the database schema / website source code included in the BRLCAD code? |
| 15:47.29 | brlcad | it is not |
| 15:47.52 | brlcad | I'll have to dig around for it in our archives -- it was quite a while ago |
| 15:48.10 | brlcad | it's available (somewhere), it'll just take a little while to find it |
| 15:48.26 | brlcad | regardless -- it was a homegrown setup |
| 15:48.37 | brlcad | how were you envisioning the implementation? |
| 15:49.11 | brlcad | using a content management system, rapid dev toolkits, or also from scratch? something else? |
| 15:49.48 | AbhijitKane | I have the most experience with MySQL. I also have a fair idea about UML, so if there are UML diagrams that I could look at, it would be advantageous. |
| 15:50.24 | AbhijitKane | Not a CMS, but I could take a look at the old code or work from scratch |
| 15:50.34 | brlcad | heh, no UML |
| 15:51.41 | brlcad | personally (and others may have different opinions), I'd prefer that IFF you are not going to use any web toolkits or CMS that you then leverage the old code and pick up where they left off |
| 15:51.55 | brlcad | otherwise there'd be no difference if it was all just from scratch again, effort wasted |
| 15:52.09 | brlcad | rather, duplicate effort .. not necessarily wasted |
| 15:52.19 | AbhijitKane | i agree |
| 15:52.55 | brlcad | have you ever used a revision control system before for web development? |
| 15:53.10 | AbhijitKane | I used subversion for a project that I did last year |
| 15:53.26 | brlcad | it'll be required for this, as will creating a simple patch showing your ability |
| 15:53.33 | brlcad | oh? |
| 15:53.36 | brlcad | who'd you work with? |
| 15:53.56 | AbhijitKane | It wasn't a part of gsoc. I was interning with a start-up |
| 15:55.14 | brlcad | anything on-line that we can take a look at? |
| 15:56.33 | brlcad | AbhijitKane: also, what got you interested in BRL-CAD? |
| 15:56.41 | AbhijitKane | I helped with this: http://www.vindev.net/phototourv2/public/apps/html5 |
| 15:56.51 | AbhijitKane | its an HTML5 implementation of www.phototour.in |
| 15:56.59 | brlcad | be sure to put that in your application |
| 15:57.19 | AbhijitKane | ok |
| 15:58.16 | AbhijitKane | I was just looking through all the organisations that wanted back-end web development, and BRL-CAD was one of the few |
| 16:00.05 | brlcad | nods |
| 16:01.05 | AbhijitKane | Is there any reading material related to material properties that you can recommend? |
| 16:02.05 | brlcad | there are some references on the detail page |
| 16:02.34 | brlcad | there are several online commercial material database websites that you could look through for comparison/reference, see what all they include |
| 16:02.48 | AbhijitKane | ok |
| 16:02.52 | brlcad | few google searches will lead you to two or three of them |
| 16:03.56 | AbhijitKane | i'll take a look at them |
| 16:04.14 | AbhijitKane | I have to go - be back in an hour or so |
| 16:04.22 | brlcad | nods |
| 16:04.24 | brlcad | cya later! |
| 16:04.28 | AbhijitKane | bye! |
| 16:04.45 | brlcad | can't wait to see the proposal |
| 16:07.19 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 16:09.59 | adityag | i am pretty fluent in C & web related projects. i would love to contribute if im guided by some one experienced |
| 16:10.44 | adityag | brlcad : i would love to work here |
| 16:11.11 | brlcad | adityag: howdy and welcome |
| 16:11.34 | brlcad | the C background is great, we have tons of C projects ;) |
| 16:11.49 | brlcad | suggest you scan down through our project ideas page and see if anything catches your interest |
| 16:11.59 | adityag | in fact, i won a national level C/C++ programming contest |
| 16:12.10 | brlcad | which nation? :) |
| 16:14.47 | *** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net) | |
| 16:15.04 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 16:16.26 | brlcad | adityag1: connection problems? :) |
| 16:16.40 | brlcad | waves hello to dli |
| 16:17.02 | dli | brlcad, hi |
| 16:18.11 | dli | brlcad, I am trying to become a gentoo developer to update the brlcad package, but they are very slow there |
| 16:18.24 | brlcad | dli: awesome! |
| 16:18.31 | starseeker | dli: my sympathies |
| 16:18.33 | brlcad | I was just about to ask if you were you |
| 16:19.07 | brlcad | a Lin Di just messaged the mailing list, thought they might have used your irc nick :) |
| 16:20.06 | dli | brlcad, couldn't be me :( my family name is Li :( |
| 16:22.09 | dli | brlcad, the gentoo story, andreas Huettel told me he would be my mentor for gentoo-scicence, but I have to wait for him to start the recuiting process |
| 16:22.32 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 16:22.52 | starseeker | adityag: welcome back :-) |
| 16:24.22 | brlcad | his peers don't like him |
| 16:24.48 | adityag | brlcad starseeker: connection problem + dinner time |
| 16:25.24 | brlcad | dli: that's great news either way, you're well on your way |
| 16:25.37 | *** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194) | |
| 16:25.43 | brlcad | adityag: understandable |
| 16:26.17 | brlcad | we're here all day -- we don't expect immediate and perpetual connectivity/responses, neither should you ;) |
| 16:26.57 | adityag | yes cool |
| 16:29.02 | dli | brlcad, for me to test the intersection program (from previous GSoC?), is it possible for me to skip building the whole brlcad package. my gentoo is on a slow core 2 thinkpad, got to speed up the process |
| 16:30.58 | brlcad | dli: you can build by hand, you just cd to the dir and build from there |
| 16:32.18 | brlcad | "make depends" and "make" in src/proc-db should get you built |
| 16:34.49 | dli | brlcad, maybe, I should write some cmake or autotools for the folder first |
| 16:35.45 | starseeker | dli: it shouldn't be necessary |
| 16:36.10 | brlcad | dli: what's the problem? |
| 16:36.24 | brlcad | cmake branch should work as should trunk's autotools build |
| 16:37.09 | brlcad | adityag: so if you didn't see my question, which nation? :) |
| 16:38.06 | dli | brlcad, want to limit the range of code base for me to work on |
| 16:39.56 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 16:40.40 | starseeker | dli: just cd into the directory with the code in question and type make there - it should only build what is needed |
| 16:40.41 | adityag | brlcad: India.... & u ? |
| 16:41.24 | adityag | brlcad: for more info about me http://aditya.ritzsoftec.com |
| 16:41.57 | dli | starseeker, let me play with it more |
| 16:42.11 | brlcad | adityag: maryland (usa) |
| 16:45.25 | brlcad | adityag: thanks (also good to include in your proposal) |
| 16:45.38 | brlcad | adityag: what platform do you work on? |
| 16:46.42 | adityag | <PROTECTED> |
| 16:48.02 | brlcad | k |
| 16:48.11 | brlcad | what is slmbk? |
| 16:50.01 | adityag | its a social network site which i had lauched in 2008 which revolves around filling scrap/slam books for students |
| 16:54.19 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 16:54.46 | adityag1 | brlcad: i tried working on a few start ups.. i failed every time, so i want to contribute now |
| 16:56.15 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 16:59.00 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 17:01.27 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 17:02.30 | brlcad | adityag: okay thanks! |
| 17:03.44 | AbhijitKane | brlcad: hi again |
| 17:04.09 | AbhijitKane | went thrrough a few material database sites - most of them focus on their querying abilities |
| 17:04.24 | AbhijitKane | ranges for value of various properties and things like that |
| 17:05.23 | AbhijitKane | :adityag: hi! where are you from? |
| 17:06.57 | brlcad | AbhijitKane: great |
| 17:07.13 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 17:09.06 | brlcad | AbhijitKane: it'd be great to include a rough mock-up of the layout with your application -- wouldnt' have to be anything too complex or fancy but it would give the reviewers a sense of the project goal |
| 17:09.55 | AbhijitKane | ok sure |
| 17:10.21 | AbhijitKane | i don't know if im supposed to ask - but is adityag applying for the same project? |
| 17:10.35 | brlcad | no idea :) |
| 17:10.42 | brlcad | sounded like he was interested in a C project |
| 17:10.49 | AbhijitKane | ohk |
| 17:11.03 | adityag | im interested in any cool projects |
| 17:11.33 | adityag | brlcad : suggest me the coolest idea from brlcad's list |
| 17:12.17 | brlcad | helps to include the '-' when referring to the project and without when referring to me .. otherwise just gets confusing ;) |
| 17:12.36 | brlcad | hm, depends how you defined 'cool' |
| 17:13.24 | brlcad | the first one on the list, NURBS surface-surface intersection calculations is pretty freaking cool, but really frickin' hard too |
| 17:13.43 | adityag | :-D. Whats the best idea about brl-cad ? |
| 17:13.48 | brlcad | otherwise, what's cool to me isn't necessarily cool to you :) |
| 17:13.58 | adityag | let me check out |
| 17:14.39 | brlcad | spend an hour or so and go down the list |
| 17:14.50 | brlcad | if the short summary doesn't catch your attention, move on to the next one |
| 17:15.35 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 17:16.09 | brlcad | might have missed me saying "spend an hour of so and go down the list, if the short summary doesn't catch your attention, move on to the next one.." |
| 17:16.22 | brlcad | should have a great idea by the end which two or three sound the most interesting |
| 17:16.34 | brlcad | rather you pick something YOU like, than it be something I like |
| 17:17.06 | brlcad | even if it's something simple sounding like cleanup or something complex like nurbs |
| 17:17.25 | adityag | ok cool |
| 17:18.08 | brlcad | we don't really care what you work on -- we want you to become a brl-cad developer merely enjoying what you work on, so maybe you'll keep working on it |
| 17:19.20 | CIA-52 | BRL-CAD: 03starseeker * r43964 10/geomcore/trunk/tests/svntest/main.c: OK, get as far as printing out what's in the toplevel directory... |
| 17:26.29 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 17:37.38 | *** join/#brlcad Ralith (~ralith@d142-058-094-084.wireless.sfu.ca) | |
| 17:38.28 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 17:41.32 | adityag | brlcad : can i get my couple of my friends to work with me on Code Refactoring, GUI, Web Developments ? we can work on others too but im pretty sure that we can work on the mentioned topics. |
| 17:47.42 | *** join/#brlcad Ralith (~ralith@d142-058-094-084.wireless.sfu.ca) | |
| 17:58.07 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 18:31.53 | *** join/#brlcad Ralith (~ralith@d142-058-094-084.wireless.sfu.ca) | |
| 18:45.45 | CIA-52 | BRL-CAD: 03erikgreenwald * r43965 10/geomcore/trunk/src/GS/testclient/gstestclient.c: try to send a disconnect request |
| 18:50.37 | CIA-52 | BRL-CAD: 03erikgreenwald * r43966 10/geomcore/trunk/src/GS/testclient/gstestclient.c: glue header magic together. make package display a little more readable |
| 19:03.32 | CIA-52 | BRL-CAD: 03bob1961 * r43967 10/brlcad/trunk/src/libged/ged.c: Initialize libged's _FreeSolid list if not already initialized. |
| 19:12.26 | brlcad | adityag: if they're gsoc students, their work has to be independent of yours, but otherwise they're welcome to apply too |
| 19:13.28 | brlcad | there's no guarantee that any student will be selected really, it really depends how each student is evaluated, how many proposals, what sort of interest there is, etc |
| 19:17.38 | adityag | brlcad : we could apply to 3 different projects as i mentioned you. |
| 19:27.53 | *** join/#brlcad kunigami (~kunigami@201.53.192.197) | |
| 19:32.51 | brlcad | you could apply to 3 different projects each -- they'll all still be evaluated independently ;) |
| 19:33.25 | brlcad | do generally recommend that seriously interested students should apply to at least two topics in case there is a conflict that needs resolving |
| 19:35.12 | CIA-52 | BRL-CAD: 03erikgreenwald * r43968 10/geomcore/trunk/src/GS/testclient/gstestclient.c: read node name msg and test magics |
| 19:39.39 | kunigami | hi, I'm interested in the vector output from raytracing: http://brlcad.org/wiki/Vector_output_from_raytracing -- Question: do I have to know beforehand algorithms to fit curves to points or I could learn them during the project? |
| 19:40.16 | brlcad | kunigami: hello! saw your message to the mailing list |
| 19:41.05 | brlcad | you can learn them during the project, but you should have some basic references already researched |
| 19:41.39 | kunigami | Perfect! |
| 19:41.52 | brlcad | two or three research papers that do exactly that, understanding the tradeoffs so that you spend most of your time figuring out how to implement the algorithm |
| 19:42.56 | brlcad | then your proposal should reflect that time with baby milestone steps, more than pure coding projects, so that we can make sure you're making progress |
| 19:43.00 | kunigami | Ok! I'll research some papers on the subject and ask back if they are enough! |
| 19:43.13 | brlcad | like if you find a particular paper, break the algo up into a bunch of steps that could all be testable |
| 19:45.02 | kunigami | hmm ok. splitting the algorithm is also good for debugging purposes :) |
| 19:56.46 | brlcad | kunigami: how'd you come to our project ideas page? what's your interest? |
| 20:06.44 | kunigami | well, I found BRL-CAD through GSoC page - I didn't know BRL-CAD before. I just searched for "computer graphics" keyword. which is also my interest. |
| 20:09.35 | kunigami | I've also interest in computational geometry. Last year I tried CGAL, but I couldn't get in touch with them, so I sent my proposal without their review :( Obvisusly it was rejected. |
| 20:11.53 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 20:13.25 | kunigami | I've a particular interest in raytracers. I was going to contribute to yafaray, but this year they didn't get accepted to gsoc. glad to see there's another project that involves ray-tracing \o/ |
| 20:18.00 | CIA-52 | BRL-CAD: 03erikgreenwald * r43969 10/geomcore/trunk/include/Portal.h: 5309!=0x5309, change this to match the spec. |
| 20:23.46 | CIA-52 | BRL-CAD: 03starseeker * r43970 10/geomcore/trunk/tests/svntest/main.c: not working, but checkpointing |
| 21:21.18 | CIA-52 | BRL-CAD: 03starseeker * r43971 10/geomcore/trunk/tests/svntest/main.c: Ah, right - path from root, not from model_name |
| 21:46.35 | Ralith | brlcad: would it be worthwhile for me to apply to work on the toolpath generator? I'd be happy to discuss the results of my previous participation, if it'd help. |
| 21:50.33 | CIA-52 | BRL-CAD: 03starseeker * r43972 10/geomcore/trunk/tests/svntest/main.c: Woot! re-assembles the file, althought we're losing some information at the moment. |
| 21:55.00 | starseeker | about one minute fifty seconds with that code to process havoc.g |
| 21:56.14 | starseeker | that's disassembly and insertion, committing, and reconstruction |
| 21:56.50 | starseeker | not handling units correctly yet, or _GLOBAL - probably some other issues |
| 21:58.25 | starseeker | this API communication may be below the "safe for multiple clients" level, but does give a decent baseline. There are no working copies used either for insertion or reassembly. A traditional svn checkout does succeed |
| 22:03.37 | CIA-52 | BRL-CAD: 03starseeker * r43973 10/geomcore/trunk/tests/svntest/main.c: Remove some debug statements, use 1 for unit conversion factors... |
| 22:08.42 | starseeker | humph. OK, not preserving title, units, color tables, or "region_id" attributes - otherwise g_diff reports nothing |
| 22:10.01 | starseeker | that's a good note to call it a week on |
| 22:38.18 | brlcad | starseeker: wow, so 4.5 min reduciton |
| 22:38.21 | brlcad | that's substantial. |
| 22:40.52 | brlcad | pretty awesome progress, so that's apparently as fast as it'll get for the svn server overhead |
| 22:41.43 | brlcad | presumably most of that time is spent inserting and committing |
| 22:44.55 | brlcad | kunigami: that's cool, those are sister projects we don't interact with very often, but are in related domains |
| 22:46.01 | brlcad | cgal mostly just because their license is incompatible |
| 22:46.18 | brlcad | kunigami: did you see our yafaray-related project? |
| 22:49.12 | kunigami | no, I didn't. Is it listed in the project ideas? |
| 22:49.20 | brlcad | not sure.. ;) |
| 22:50.27 | brlcad | there was an idea at one point to hook into yafaray using our raytracer to shoot the ray, find hit point, then pass off to yafray (I need to get used to using their new name...) for optics calculations |
| 22:50.59 | brlcad | basically so we can render our geometry using their global illumination model as a plugin to our tracer |
| 22:51.26 | kunigami | interesting! |
| 22:51.30 | brlcad | yeah very |
| 22:51.33 | brlcad | BUT ...probably wouldn't recommend it for gsoc unless you were already really familiar with |
| 22:51.38 | brlcad | brl-cad or yafray |
| 22:51.55 | brlcad | at the source code level, since it's undoubtedly a tricky integration of data management |
| 22:52.30 | brlcad | though that could be a great out-year project after becoming familiar with the code this summer |
| 22:52.42 | kunigami | hmm ok. I'll consider helping with it afterwards |
| 22:53.17 | brlcad | the first render project would be a good step towards becoming familiarized with the code |
| 22:53.24 | kunigami | yes! I hope to learn a lot about ray-tracers :) |
| 22:54.06 | kunigami | you mean the "shader enhancements" one? |
| 22:54.11 | brlcad | yeah |
| 22:54.26 | kunigami | hmmm, I'll take a look on it too |
| 22:54.29 | brlcad | hooking in something like OSL would cover related code |
| 22:55.27 | kunigami | ok! |
| 22:56.25 | brlcad | kunigami: what projects were you considering before I mentioned that? :) |
| 22:58.34 | kunigami | actually only the "vector output from raytracing", but when I joined the room, I got the end of a conversation about applying to more than one project |
| 22:58.39 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2756 10/wiki/Shader_Enhancements: link to main wikipedia article and yafaray |
| 22:58.51 | brlcad | ah excellent |
| 22:58.55 | kunigami | so I'm looking for two projects |
| 22:59.10 | brlcad | yeah, that's perfect |
| 22:59.47 | brlcad | because usually we narrow down to the individual first, then pray we've not narrowed down to two students that have proposed the same project |
| 22:59.59 | brlcad | submitting two makes that never an issue |
| 23:00.35 | kunigami | hmm ok. good to know that |
| 23:01.02 | brlcad | wow, wikipedia page on shaders doesn't mention OSL |
| 23:01.38 | brlcad | they're the hot cool new kid on the block for ray tracing |
| 23:02.40 | kunigami | OSL = open shading language? |
| 23:03.06 | brlcad | yeah |
| 23:03.21 | brlcad | sony imageworks released that project about two or three years ago |
| 23:03.37 | brlcad | it's a shader language specifically tuned to ray tracing |
| 23:03.46 | kunigami | hmm nice! didn't know it |
| 23:04.08 | brlcad | unlike renderman, which was designed for pixar-style micropolygon raster engines |
| 23:05.46 | brlcad | ahh, that's why it's not on our ideas list .. it was a discussion with the yafaray devs |
| 23:06.21 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2757 10/wiki/Shader_Enhancements: typo |
| 23:24.05 | starseeker | brlcad: I'll probably have to have a third go at it using the svn_ra layer (svn_fs most likely doesn't have the multi-client safty features) |
| 23:24.55 | starseeker | that requires a little more understanding of things like batons though, so I went for the svn_fs approach as faster (and the same split-and-recombine-without-using-files issues had to be addressed, so that will apply) |
| 23:26.45 | starseeker | I think the majority of the time was committing, but inserting was also significant |
| 23:33.08 | brlcad | ok |
| 23:33.49 | brlcad | locking wouldn't amount to 4 min of activity .. had to be lots of i/o, book-keeping, unnecessary allocations, etc |
| 23:34.02 | brlcad | hard to say, would need to profile |
| 23:34.14 | brlcad | the good news is that the raw server layer is very promising |
| 23:34.48 | brlcad | if we had to, we lock the write session or even lock per node |
| 23:35.05 | brlcad | or profile and optimize their code |
| 23:35.11 | brlcad | either way, very promising |
| 23:35.36 | brlcad | still waiting for that magical "holy crap" moment where it drops to sub 5sec :) |
| 00:09.54 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2758 10/wiki/Backstaff: kiss down to 3 |
| 01:10.21 | *** join/#brlcad crazy_imp (~mj@a89-183-83-230.net-htp.de) | |
| 01:14.30 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2760 10/wiki/Backstaff: add the backstaff image with left/right alignment now working on images (style.css was missing juju) |
| 02:00.37 | starseeker | brlcad: <snort> not with Mac file IO and a filesystem based backend |
| 02:02.14 | starseeker | hmm - apparently, all public subversion APIs are concurrent-safe, both interprocess and intraprocess |
| 02:03.44 | starseeker | http://mail-archives.apache.org/mod_mbox/subversion-users/201103.mbox/%3C20110325234038.GA12220@daniel3.local%3E |
| 02:06.27 | starseeker | will have to decide what to do about _GLOBAL, since it doesn't work as an exported object |
| 03:26.34 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 03:33.18 | *** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194) | |
| 03:37.38 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 03:44.57 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 03:59.58 | *** part/#brlcad kunigami (~kunigami@201.53.192.197) | |
| 04:13.47 | brlcad | starseeker: my timing tests manually breaking up the file and recombining were all on mac |
| 04:16.16 | brlcad | _GLOBAL is really just a collection of attributes on the file namespace |
| 04:18.10 | brlcad | so for now you can just create a dir/comb representing the file (e.g., "havoc.g") that unions all of the top-level objects that were in that file and assign all _GLOBAL attributes to it, perhaps one additional "cad::namespace=true" attribute |
| 05:17.07 | brlcad | starseeker: I'm trying to recall, what was the issue you ran into using opengl to tessellate/render NURBS? was it the trim curves? |
| 05:58.18 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 05:58.18 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:25.30 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 08:25.30 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 ETA 20110325 || Welcome GSoC 2011 participants! Speak up, ask questions, start here: http://brlcad.org/wiki/Google_Summer_of_Code/2011 | |
| 08:27.57 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 08:47.23 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 08:58.08 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 10:14.56 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 13:00.16 | *** join/#brlcad kunigami (~kunigami@201.53.192.197) | |
| 13:50.28 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 15:16.17 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 15:23.50 | kunigami | hi all, I'm studing mged code in order to fix the bug "gets stdin myinVar" fails - ID: 3087665 http://sourceforge.net/tracker/?func=detail&aid=3087665&group_id=105292&atid=640802 |
| 15:24.01 | kunigami | <PROTECTED> |
| 15:24.05 | kunigami | I though that input was read through a callback too (stdin_input) but it seems that in mode interactive and not classic_mged, the callback isn't set |
| 15:24.09 | kunigami | <PROTECTED> |
| 15:24.12 | kunigami | thanks! |
| 15:39.45 | *** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194) | |
| 16:02.31 | brlcad | AbhijitKane: glad to hear the research continues, and expected regarding alloys and polymers -- from our perspective we treat materials as strictly homogeneous matter |
| 16:03.23 | brlcad | bhinesley: yeah, don't worry about line length |
| 16:04.38 | brlcad | kunigami: oof, that's a tricky one since mged input is handled in a variety of ways |
| 16:04.48 | brlcad | input is left up to tcl most of the time iirc |
| 16:44.15 | kunigami | hmm ok. One thing I noticed is that when we don't redirect stdout/stderr to tclchannels (I commented out in the code). The output, now printed to terminal, does not show that bug |
| 16:52.55 | kunigami | I'll try to go back to this bug another time. I'm switching to the to-do list of brlcad :) |
| 16:53.04 | kunigami | There's this one: bu_basename() says it'll return things that it probably won't |
| 16:53.05 | kunigami | <PROTECTED> |
| 16:53.05 | kunigami | <PROTECTED> |
| 16:53.05 | kunigami | <PROTECTED> |
| 16:54.21 | kunigami | indeed, it says that "/" should return "/" and "a/" return "a", but for both cases the actual code is returning the empty string |
| 16:54.42 | kunigami | what is to be done: change commentaries or the code? |
| 17:14.50 | brlcad | kunigami: the redirection is definitely the "cause" of the bug -- it's more making sure the logic is appropriate for both console mode (where there shouldn't be redirection) and graphical mode (where there is redirection) and console mode that invokes the graphical mode (where there are multiple output streams) |
| 17:15.10 | brlcad | kunigami: the code should be fixed |
| 17:15.55 | brlcad | for bu_basename() .. it should basically behave identical to basename(); it's really just a wrapper for platforms that don't have basename() |
| 17:16.18 | brlcad | the initial naive implementation was just a little too hastily coded |
| 17:17.00 | brlcad | that would should be pretty easy to code from scratch or find a bsd reference impl |
| 17:19.22 | kunigami | I see. I'll do it then! thanks |
| 17:34.40 | brlcad | thank you, awesome |
| 18:05.34 | kunigami | hmm there are some issues though: I need to modify the string if it is for instance "a/" (it should return "a"). An option would be allocating space for a new char array, it that ok? |
| 18:06.29 | kunigami | this memory will probably never be deallocated, but I not sure if it's a problem |
| 18:06.32 | *** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194) | |
| 18:09.45 | AbhijitKane | brlcad: any updates on the database schema? |
| 18:20.19 | starseeker | for those interesting in watching an animation of part of the BRL-CAD source code history (a small part, admittedly): |
| 18:20.26 | starseeker | http://bzflag.bz/~starseeker/brlcad-gource.avi |
| 18:20.40 | starseeker | that's the gource tool brlcad found |
| 18:23.05 | brlcad | starseeker: awesome! |
| 18:23.39 | brlcad | starseeker: what settings did you use? |
| 18:23.49 | brlcad | and how did it take you to render it to video? |
| 18:29.55 | brlcad | AbhijitKane: I found everything, so no worries there |
| 18:30.30 | starseeker | brlcad: was a combination of yukon video capture, seom-filter, mencoder |
| 18:30.33 | brlcad | in fact, the dev site is still on-line .. just no means for online auth |
| 18:30.36 | brlcad | mater.brlcad.org |
| 18:30.41 | starseeker | don't seem to have the exact settings used for gource |
| 18:31.28 | starseeker | grabbed mencoder settings from here: http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html |
| 18:31.43 | starseeker | seom-filter yukon.seom | mencoder - -ovc x264 subq=6:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid:weight_b -vf scale=512:384 -o file.avi |
| 18:32.23 | brlcad | oh, it's not the whole video |
| 18:32.28 | starseeker | right |
| 18:32.44 | AbhijitKane | brlcad: great. i checked a few material databases - they bascially divide all their data into polymers and alloys |
| 18:32.52 | starseeker | just thought I'd put up a subset for those interested in seeing something |
| 18:32.53 | brlcad | ahh, looks like you have the same settings too |
| 18:33.01 | AbhijitKane | then there are different methods for searching through each subset |
| 18:33.04 | brlcad | i made a few source code mod improvements |
| 18:33.23 | brlcad | never used seom-filter |
| 18:33.34 | starseeker | it goes along with the yukon thing |
| 18:33.47 | starseeker | https://devel.neopsis.com/projects/yukon/wiki/HowTo/Install?version=15 |
| 18:33.49 | brlcad | also a tiny video relative to what I was trying to capture |
| 18:33.54 | brlcad | was going for 720p |
| 18:34.01 | brlcad | well, originally 1080p :) |
| 18:34.09 | starseeker | https://devel.neopsis.com/projects/yukon/wiki/HowTo/Capture |
| 18:34.09 | brlcad | that would have filled this hd fast |
| 18:34.42 | starseeker | nods - yeah, mine is just the "here's something cool" sample, not the canonical video |
| 18:34.43 | brlcad | maybe I can just send you my mods and settings.. :) |
| 18:35.09 | starseeker | heh - and watch my pathetic little PC fry ;-) Still may be worth a shot |
| 18:35.28 | starseeker | however, the raw capture on just that part of the animation was 8 gigs |
| 18:35.46 | brlcad | well your video still looks better than mine, I was going to resort to the built-in ppm stream |
| 18:36.26 | starseeker | what were your source mods? |
| 18:36.48 | brlcad | nothing major, the big one was to make the nodes have a little more separation |
| 18:36.54 | brlcad | and I think that one was a data mod |
| 18:37.04 | brlcad | the other was control on the font size |
| 18:37.21 | starseeker | nods - cool. If you want to tar it up, I can give it a whirl |
| 18:37.32 | brlcad | there is an advanced font-size option, but it doesn't affect any of the node labels, just the title |
| 18:37.58 | starseeker | did you send them back upstream? |
| 18:38.03 | brlcad | the way it is now, it's a jumbled mess if the dir has more than about a dozen files in it and they're all edited |
| 18:38.33 | brlcad | with this, you can read most of them without overlap just by increasing the spacing slightly and decreasing the font slightly |
| 18:38.34 | starseeker | oh, there's my gource terminal |
| 18:38.41 | starseeker | yukon ~/gource-0.32/gource -p 0.8 -a 1 -s 1 |
| 18:39.35 | starseeker | this thing would make an awesome screensaver |
| 18:39.48 | brlcad | erm, now to remember what the short-hand opts were |
| 18:40.31 | starseeker | I think those were just to keep things moving rather than pause while waiting for the time to advance to the next commit |
| 18:40.37 | brlcad | settings I was using last: brlcad.org/tmp/CONFIG.gource |
| 18:40.45 | brlcad | though I was constantly tweaking |
| 18:41.21 | brlcad | ah right hilighting too |
| 18:41.39 | brlcad | made it so that commiters were slightly larger and always highlighted so you could distinguish them from the source nodes |
| 18:41.53 | brlcad | they get really lost with the defaults and a big tree |
| 18:42.00 | starseeker | nods |
| 18:42.13 | brlcad | lemme see if I can pull a patch |
| 18:42.32 | starseeker | can gource handle our full history? |
| 18:43.05 | starseeker | that's a stress test and a half |
| 18:43.53 | brlcad | if you skip forward in time, it gets totally screwed up -- the layout engine can't solve a suitable graph fast enough so it oscillates horribly |
| 18:44.09 | brlcad | it does handle the full history, takes a couple min to load |
| 18:44.22 | brlcad | if you let it build up the graph incrementally, works just fine |
| 18:44.51 | brlcad | wanted to compare two videos, one where we don't remove any nodes -- let the additions and deletions remove them instead of the time-based removal it uses by default |
| 18:45.06 | brlcad | then let it do something more like the default for unchanged nodes face away |
| 18:45.29 | brlcad | so you see where the action is at, instead of full view of the project |
| 18:45.45 | brlcad | AbhijitKane: haven't forgotten about you -- just a few secs |
| 18:45.52 | AbhijitKane | haha...sure |
| 18:46.08 | starseeker | brlcad: if it can do the full node graph, that'd be cool |
| 18:46.56 | brlcad | I think it can .. that's where the ppm stream frame dump may be required though |
| 18:47.17 | brlcad | on mine it really bogs down to < 1fps if there's a massive tree edit |
| 18:47.26 | starseeker | ah, so definitely beyond my machine for that one then |
| 18:47.28 | brlcad | like in 2004 during the conversion |
| 18:47.44 | brlcad | it catches back up, just slows the animation to a halt |
| 18:47.58 | brlcad | so if you're capturing video directly from the window, it'd suck |
| 18:48.00 | starseeker | yeah, that's gonna need a ppm dump |
| 18:48.08 | brlcad | but letting it take its time and compute frames, it'd be fine |
| 18:48.14 | brlcad | how much disk you have? |
| 18:48.15 | brlcad | :) |
| 18:48.21 | starseeker | not that much :-P |
| 18:48.47 | starseeker | my biggest drive is an external 1 terabyte, and that's got all my backup stuff |
| 18:48.51 | brlcad | I think I calculated it'd be around 90GB for the stream at 720p |
| 18:48.53 | starseeker | plus it's slow as a dog |
| 18:49.11 | starseeker | ah - I've got over a 100 gigs on my main drive |
| 18:49.32 | brlcad | that should compress down to less than 1GB for the full video |
| 18:49.43 | brlcad | but just take a day or so to process |
| 18:50.08 | brlcad | uploaded to http://brlcad.org/tmp/gource |
| 18:50.16 | starseeker | how much disk space do you have handy? |
| 18:50.17 | brlcad | replaces one of the files in data/ |
| 18:50.24 | brlcad | i only have 5GB at the moment |
| 18:50.43 | starseeker | can gource give me ppm frames as it currently stands? |
| 18:50.49 | brlcad | yep |
| 18:50.52 | brlcad | one of the options |
| 18:51.34 | brlcad | ffmpeg will read the ppm stream as is |
| 18:52.05 | starseeker | uh... I don't have a config file in data |
| 18:52.41 | brlcad | gource --load-config CONFIG.gource --output-ppm-stream frames.ppm |
| 18:52.56 | brlcad | no, that config file is a cmd-line option |
| 18:52.57 | starseeker | oh, gotcha |
| 18:53.01 | brlcad | the file.png goes into data |
| 18:53.08 | starseeker | (thought that was one of the source code mods) |
| 18:54.41 | kunigami | hi, I just sent a patch to the patch tracker. Any commentaries and suggestions are welcome. Thanks :) |
| 18:55.23 | brlcad | starseeker: pulling the source mods now |
| 18:57.54 | starseeker | ah, ok - you're filtering out src/other I see |
| 18:58.21 | brlcad | starseeker: uploaded patch.diff |
| 18:59.05 | brlcad | kunigami: fantastic .. it'll definitely get reviewed |
| 18:59.36 | brlcad | kunigami: include a web link in your application to your patch, that helps save some time figuring out who is who |
| 18:59.59 | brlcad | (not to mention your irc name, contact info, etc..) |
| 19:00.14 | starseeker | bhinesley: be sure to link to your patch(es) too |
| 19:00.58 | brlcad | AbhijitKane: glad to hear the research continues, and expected regarding alloys and polymers -- from our perspective we treat materials as strictly homogeneous matter |
| 19:02.06 | AbhijitKane | oh, so i guess you don't store many of the properties that the other databases do |
| 19:02.41 | brlcad | AbhijitKane: right now today, we only really care about density directly, and indirectly care about a half dozen other props like young's modulus |
| 19:02.55 | kunigami | ok! |
| 19:03.28 | kunigami | I'll turn now on composing my proposal. |
| 19:03.42 | brlcad | great |
| 19:04.00 | AbhijitKane | ohk |
| 19:04.35 | AbhijitKane | so the searching will just be based on these properties right? |
| 19:04.42 | brlcad | starseeker: patch apply alright? |
| 19:04.54 | brlcad | I didn't scrutinize it too closely |
| 19:04.59 | starseeker | the sketch one? Haven't had a chance to try it yet |
| 19:05.07 | brlcad | no, the gource patch |
| 19:05.14 | starseeker | oh :-) |
| 19:05.31 | starseeker | yep, just my ftgl.h was in a slightly different location then configure.ac wanted |
| 19:05.42 | brlcad | my patch changed that too |
| 19:05.54 | brlcad | just turned off the check and linked -lftgl :) |
| 19:06.01 | starseeker | ah :-) |
| 19:06.21 | starseeker | well, just compiled file - so about to give it it's initial trial |
| 19:06.36 | brlcad | was nice to see that it works cleanly against ftgl trunk |
| 19:07.02 | brlcad | we'd restructured things quite a bit, but trying to preserve the compile-time interface |
| 19:07.19 | brlcad | even run-time should be backwards-compatible |
| 19:08.58 | starseeker | brlcad: where's a good place to grab BRL-CAD_64x64.png? |
| 19:09.09 | brlcad | oh right |
| 19:09.21 | brlcad | http://brlcad.org/images/logo/ |
| 19:11.06 | brlcad | skips src/other, also skips dpk commits (jove dev) |
| 19:11.14 | starseeker | nods |
| 19:11.32 | starseeker | bit of a shame to skip the step and opennurbs work, but saves a lot of other cruft |
| 19:11.45 | brlcad | yeah |
| 19:12.05 | brlcad | could get more creative with the regex, but it's pretty darn complex as it is |
| 19:12.15 | starseeker | nods |
| 19:12.24 | brlcad | bigger issue is the length and speed of the animation |
| 19:12.29 | starseeker | alrightie, let's see what happens here... |
| 19:12.35 | starseeker | Reading Log... |
| 19:13.05 | starseeker | is this the config that keeps all the nodes? |
| 19:13.10 | brlcad | next thing I was going to try was allowing a bigger timescale .. it won't let you go over 4x right now .. 4 days per second |
| 19:13.44 | brlcad | I think so |
| 19:14.09 | starseeker | can I get away with piping this into ffmpeg, or will that preserve all the pauses for the long builds? |
| 19:15.15 | brlcad | ah, this one was a balance .. keeps nodes for 5min .. which should pretty much keep the whole graph most of the time |
| 19:15.50 | brlcad | since 5min is 300 sec is 1200 days is a lil over 3 years |
| 19:16.02 | starseeker | nods |
| 19:16.26 | brlcad | all source code is edited annually for the copyright update, so should keep the bulk of the tree at least from 2000 forward |
| 19:16.38 | brlcad | you should be able to pipe directly |
| 19:16.52 | brlcad | but I'd check the output first, letting it run |
| 19:17.07 | brlcad | hm! |
| 19:17.23 | brlcad | didn't think of that.. that might even be a way to avoid writing out 100GB .. duh |
| 19:17.28 | starseeker | still loading... |
| 19:17.38 | brlcad | yeah, takes a couple min |
| 19:18.48 | starseeker | is going with the default ffmpeg string on their site for now |
| 19:20.05 | brlcad | cool |
| 19:20.11 | starseeker | brlcad: you realize I won't be able to give ``Erik a hard time when he complains about how much space docbook takes up? |
| 19:20.43 | brlcad | I'm motivated to try it streaming here myself, but need to get my butt over to the gym.. haven't been sick like this in a while, probably due to gym slacking |
| 19:20.59 | starseeker | winces - I should be in the gym too |
| 19:21.53 | starseeker | ah, there we go |
| 19:21.59 | starseeker | it begins with mike |
| 19:22.27 | brlcad | yep |
| 19:22.36 | starseeker | 1993 |
| 19:22.40 | brlcad | the begining year or two is actually pretty cool |
| 19:22.54 | brlcad | I had it skip .1 |
| 19:23.33 | brlcad | was initial attempt at skipping dpk's commits, but then later found the other option, so can probably remove it back to skipping 0 |
| 19:24.06 | brlcad | how does it look? |
| 19:24.28 | starseeker | on screen it's OK - not sure about the video yet |
| 19:25.18 | starseeker | will stop it and restart - that shoudl be enough to test |
| 19:25.54 | starseeker | hah, awesome |
| 19:26.03 | starseeker | that should do it! |
| 19:26.09 | starseeker | sets up for the full run |
| 19:36.51 | brlcad | awesome |
| 19:36.53 | brlcad | set the skip to zero? |
| 19:41.06 | starseeker | uh - opps - was just using your settings |
| 19:42.21 | starseeker | restarts again |
| 19:44.54 | starseeker | brlcad: which setting are you referring to? |
| 19:44.56 | starseeker | start potition? |
| 19:45.03 | starseeker | er start-position? |
| 19:45.04 | brlcad | the one that says 0.1 |
| 19:45.07 | brlcad | or .1 |
| 19:45.10 | starseeker | ok, I see it |
| 19:45.56 | starseeker | hopefully screensaver won't bother this... not sure how to disable power save... |
| 20:08.18 | *** join/#brlcad sachi1325 (75d3557b@gateway/web/freenode/ip.117.211.85.123) | |
| 20:57.25 | *** join/#brlcad sachi1325_ (75d3557b@gateway/web/freenode/ip.117.211.85.123) | |
| 21:07.33 | *** part/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 22:52.09 | kunigami | is there any reference on brlcad system or do I have to study the code? |
| 22:53.01 | kunigami | oops |
| 22:53.17 | kunigami | I mean brlcad shader system |
| 22:53.47 | ``Erik | going to just have to look, they're in src/liboptical/ |
| 22:54.35 | kunigami | ok |
| 22:54.38 | kunigami | thanks |
| 22:57.15 | kunigami | forgive my ignorance, but there are two distinct things: shader language and a shader system, right? |
| 00:12.47 | brlcad | kunigami: they imply different concepts, so yes |
| 00:13.07 | brlcad | the language just describe *how* something should be rendered |
| 00:13.21 | brlcad | the shader system implements the rendering |
| 00:23.11 | kunigami | hmm, in liboptical we have a shader language or a shader system? |
| 00:33.38 | brlcad | heh, system |
| 00:35.38 | brlcad | the shader strings we set on objects could be construed as a primitive language, example: "plastic di=0.4 sp=0.2" another "stack {{plastic} {texture src="file" name="foo.png"}}" |
| 00:39.42 | kunigami | cool. I think I'm understanding |
| 01:05.44 | kunigami | I saw your commentary on my patch. I'm switching from malloc/strncpy to the wrapped version. bu_malloc has a const char *parameter, but I couldn't get its meaning from the commentaries. Looking its definition, it seems that it has debug purposes (or not?). So I'm passing NULL to this function. Is that ok? |
| 01:10.44 | *** join/#brlcad crazy_imp (~mj@a89-182-222-119.net-htp.de) | |
| 02:25.29 | *** part/#brlcad kunigami (~kunigami@201.53.192.197) | |
| 03:21.48 | starseeker | full movie clocks in at just over a gig |
| 03:34.14 | starseeker | and just over 45 minutes |
| 03:34.36 | starseeker | layout's a bit skewed by trunk and brlcad always being present |
| 03:36.25 | starseeker | brlcad: I'll probably have to bring you a dvd - I don't know that my upload connection will tolerate such a huge upload even if bzflag has room |
| 06:18.42 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-125-83-101.dsl.bkfd14.sbcglobal.net) | |
| 06:20.51 | bhinesley | I'm having build issues in Windows/Cygwin. Is Cygwin used to build the releases of BRL-CAD? |
| 06:23.58 | bhinesley | *windows releases |
| 06:33.39 | CIA-52 | BRL-CAD: 0399.125.83.101 07http://brlcad.org * r2761 10/wiki/User:Bhinesley: /* Checklist */ Updated status |
| 06:34.33 | CIA-52 | BRL-CAD: 0399.125.83.101 07http://brlcad.org * r2762 10/wiki/User:Bhinesley: /* Checklist */ removed item no longer working on |
| 06:43.12 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 06:52.58 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 07:28.05 | bhinesley | Nevermind, found README.Windows |
| 10:05.04 | brlcad | starseeker: more importantly, does the graph go nuts after 2004? |
| 10:06.13 | brlcad | bhinesley: it's not, but it 'should' build .. it's just not a configuration that's tested very often at all. shouldn't be more than a few minor tweaks but if it is, that could be a patch submission |
| 10:12.42 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 10:13.16 | brlcad | hello sachinjain, what's your question? |
| 10:13.57 | sachinjain | yeah... |
| 10:14.27 | sachinjain | I was talking about the project....."Vector output from raytracing" |
| 10:15.31 | sachinjain | I wanted to know.....how does brlcad generates raster images? |
| 10:15.40 | brlcad | through raytracing :) |
| 10:16.05 | dloman | Mernin all! |
| 10:16.14 | sachinjain | so....it generates a set of pixels? |
| 10:16.17 | brlcad | so a ray is fired for every pixel, if it hits something, that pixel is shaded according to the properties of what it hits |
| 10:16.21 | brlcad | hello dloman |
| 10:16.46 | sachinjain | ok... |
| 10:17.22 | sachinjain | so...what do u mean by "generate vector drawings" |
| 10:17.42 | sachinjain | we can only generate vector drawings if we assume that we have raster image |
| 10:18.12 | brlcad | the idea with getting vector output is two-fold -- you either are going to still shoot rays and interpolate vector lines (i.e., edge/object detection) ... OR ... you're not really going to shoot rays but instead extrace outline representations "somehow" and project those onto a vector image plane |
| 10:18.44 | brlcad | s/extrace/extract/ |
| 10:20.07 | sachinjain | I have done a project....where I have to a construct a vector image out of raster image |
| 10:20.18 | sachinjain | by using bezier splines |
| 10:20.30 | brlcad | that would be the first method I mentioned |
| 10:20.37 | sachinjain | hmmm |
| 10:21.08 | brlcad | it can work that way, but you have to be really careful about how those curves are constructed |
| 10:21.36 | brlcad | they don't tend to sample well for small resolution images |
| 10:21.43 | sachinjain | yeah |
| 10:21.57 | sachinjain | how small resolution images are we talkin about? |
| 10:22.07 | brlcad | you either need to really increase the grid size or you need adaptive sampling where there are areas of large derivatives |
| 10:22.24 | brlcad | it's user-specified, so pretty much anything |
| 10:22.33 | brlcad | it should still give a sensible result though |
| 10:22.59 | brlcad | if it's basically giving the raster image scaled, that's rather useless |
| 10:23.18 | brlcad | the whole point is to have smooth edges that scale and interpolate cleanly |
| 10:24.43 | brlcad | that's why the method that doesn't involve sampling is superior, but a bit harder |
| 10:25.09 | sachinjain | so what other method you can suggest? |
| 10:25.33 | brlcad | you extract outline representations "somehow" and project those onto a vector image plane |
| 10:25.45 | sachinjain | you mean the second approach |
| 10:25.45 | sachinjain | ? |
| 10:26.01 | brlcad | that would be the other method |
| 10:26.35 | brlcad | note that there are lots of degrees of freedom here |
| 10:27.14 | sachinjain | what do you mean by "extracting outline representations"? |
| 10:27.31 | brlcad | you could, for example, query each individual primitive, shoot a grid of rays at it, evaluate bezier curves for that outline, then perform boolean evaluation of the bezier curves all the way back up to the resulting vector iamge |
| 10:28.28 | brlcad | or instead of shooting a grid of rays, you could use the conversion to a boundary representation format (NURBS) and then calculate the edge contours from the NURBS surface, and once again, perform boolean eval of those curves up the hierarchy |
| 10:30.45 | *** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194) | |
| 10:31.44 | brlcad | sachinjain: feel free to post any more questions if they come up -- it's a tricky subject but if you already know how to interpolate bezier curves then you already have an advantage |
| 10:31.57 | sachinjain | yeah.....I know |
| 10:32.01 | brlcad | otherwise, I have to go walkabout for a bit to tame this congestion |
| 10:32.02 | sachinjain | how to interpolate |
| 10:32.54 | sachinjain | but...I am still trying to understand your above suggestion |
| 10:37.10 | sachinjain | ok.... |
| 10:37.21 | sachinjain | so what I understood from your explaination |
| 10:37.24 | sachinjain | is that |
| 10:37.36 | sachinjain | for every object in a scene |
| 10:37.51 | sachinjain | we find the outline of that object |
| 10:38.09 | sachinjain | construct a bezier curve on that outline |
| 10:38.10 | brlcad | yes |
| 10:38.29 | sachinjain | n then do some...."boolean evaluation" |
| 10:38.41 | sachinjain | what is this boolean evaluation? |
| 10:39.12 | brlcad | http://en.wikipedia.org/wiki/Constructive_solid_geometry |
| 10:39.42 | brlcad | so look at that image on the bottom right |
| 10:40.04 | brlcad | that's basically our CSG hierarchy, with primitives at the bottom, boolean operations that combine them up to the final image on the top |
| 10:40.10 | sachinjain | http://en.wikipedia.org/wiki/File:Csg_tree.png |
| 10:40.12 | sachinjain | this one? |
| 10:40.16 | brlcad | we want a vector version of what is on top |
| 10:40.24 | brlcad | yes |
| 10:41.08 | sachinjain | hmm |
| 10:41.15 | sachinjain | that seems pretty interesting |
| 10:41.22 | brlcad | gotta run, others in here should be able to help further .. look forward to talking more! |
| 10:42.21 | sachinjain | yeah sure |
| 10:42.26 | sachinjain | some specific time? |
| 10:43.01 | sachinjain | last question...what do I need to have...to work upon this project? |
| 10:44.44 | sachinjain | Hi starseeker |
| 10:45.52 | dloman | sachinjain: 'what do I need to have' ....as in software installed on your computer? |
| 10:46.24 | sachinjain | dloman: I didn't got u |
| 10:46.25 | sachinjain | ? |
| 10:48.00 | dloman | your question: "What do I need to have...to work upon this project?" |
| 10:48.12 | sachinjain | yeah |
| 10:48.15 | dloman | do you mean: "What software do i need to have installed to work on this project?" |
| 10:48.30 | sachinjain | I already have that software installed |
| 10:48.51 | sachinjain | trying to go through its documentation |
| 10:49.16 | sachinjain | is there any specific part of documentation which I need to go through...for this project |
| 10:50.25 | dloman | you are working on the "generate vector drawings" that you and brlcad were talking about just a few minutes ago? |
| 10:50.35 | sachinjain | yup |
| 10:50.54 | sachinjain | I think I got the whole idea of the project |
| 10:51.38 | dloman | I'm no expert, but I'd suggest diving into the code. libbu was the most informative library for me when I started, and I'd imagine libRT will be very good for you also. |
| 10:54.42 | sachinjain | where can I find these libraries? |
| 10:55.04 | dloman | in the source code: /src/libbu and /src/librt |
| 10:55.32 | dloman | their header files would also be good to start with: /include/bu.h and /include/rt.h |
| 10:59.46 | sachinjain | there is no such file in this path |
| 10:59.57 | sachinjain | :-/ |
| 11:00.16 | sachinjain | I am working on windows |
| 11:00.33 | sachinjain | and the version installed is 7.14.8 |
| 11:00.45 | dloman | ah, winderz. |
| 11:00.59 | sachinjain | should I do my work in linux? |
| 11:01.03 | dloman | okay then, wherever you have it installed: |
| 11:01.13 | dloman | <installpath>/include/bu.h |
| 11:01.25 | dloman | <installpath>/include/rtfunc.h |
| 11:01.32 | dloman | <installpath>/include/rtgeom.h |
| 11:01.33 | sachinjain | no file with name "bu.h" |
| 11:01.58 | sachinjain | I can only find "rtgeom.h" |
| 11:01.59 | dloman | well that's not right |
| 11:02.11 | dloman | did you download binaries or the source? |
| 11:02.32 | sachinjain | just the exe files |
| 11:02.33 | sachinjain | :D |
| 11:02.36 | sachinjain | file* |
| 11:02.47 | dloman | ah, well then that's the issue. |
| 11:02.58 | dloman | if you are going to develop, you are going to need to get an SVN checkout |
| 11:02.59 | sachinjain | hmm |
| 11:03.08 | sachinjain | on eclipse? |
| 11:03.41 | dloman | that's one way to do it, however, I have never built brlcad using eclipse... so i dunno if its possible. |
| 11:03.55 | dloman | most windows developers for brlcad use some flavor of visual studio |
| 11:04.02 | sachinjain | ohhh |
| 11:04.14 | sachinjain | btw...is it easy to do through linux? |
| 11:04.28 | dloman | in my opinion, yeah, much easier. |
| 11:05.03 | sachinjain | ok...so I can work on one of my servers.... |
| 11:05.06 | sachinjain | it has got linux |
| 11:05.40 | sachinjain | how do I get binaries or source on linux? |
| 11:05.56 | dloman | how familiar with *nix are you? |
| 11:06.22 | sachinjain | never heard of it |
| 11:06.24 | sachinjain | :-/ |
| 11:06.45 | dloman | *nix == unix, linux, bsd, etc |
| 11:06.48 | dloman | general term |
| 11:06.52 | dloman | aka 'not windows' |
| 11:06.56 | sachinjain | kk |
| 11:06.57 | sachinjain | kk |
| 11:07.09 | sachinjain | very familiar |
| 11:07.10 | sachinjain | then |
| 11:07.25 | sachinjain | I do all my coding on unix only |
| 11:07.42 | dloman | just get an svn checkout of the brlcad repository. |
| 11:08.27 | dloman | http://sourceforge.net/scm/?type=svn&group_id=105292 |
| 11:08.59 | dloman | aka: svn co https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk directoryOnYourHD |
| 11:10.13 | sachinjain | so...I have to just run this command.... |
| 11:10.18 | sachinjain | "svn co https://brlcad.svn.sourceforge.net/svnroot/brlcad brlcad" |
| 11:10.40 | dloman | well, that's the generic 'svn checkout' command that sourceforge gives |
| 11:10.49 | dloman | the proper version of it is what i wrote above |
| 11:11.03 | dloman | are you familiar with using Subversion at all? |
| 11:11.12 | sachinjain | kk |
| 11:11.19 | sachinjain | I have used once |
| 11:11.24 | sachinjain | while building a compiler |
| 11:11.31 | dloman | okie |
| 11:11.42 | dloman | there's plenty of tutorials on the net |
| 11:11.49 | dloman | but all you really need to know are: |
| 11:12.02 | dloman | svn checkout (or: svn co) |
| 11:12.10 | dloman | svn commit (or: svn ci) |
| 11:12.12 | dloman | and |
| 11:12.15 | dloman | svn up |
| 11:12.20 | sachinjain | okie |
| 11:12.32 | sachinjain | I am following them |
| 11:12.58 | dloman | however, commit permissions are not automatically granted and you will likely have to 'submit a patch' via the sourceforge website. |
| 11:13.14 | dloman | once you get the code checked out, lemme know. |
| 11:13.21 | sachinjain | kk |
| 11:13.23 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 11:13.26 | dloman | i *should* be here for the next 8 (ish) hours. |
| 11:13.44 | sachinjain | I will try to do that...as soon as possible |
| 11:15.00 | dloman | is diggin the new GSoC web UI. |
| 11:24.32 | dloman | hrm... where's my profile editing link? Not liking the new UI that much anymore... its pretty, but that's about it. |
| 11:27.33 | dloman | Nice... I can't 'apply' to be a mentor without first applying to be part of GSoC. But the only way to be part of GSoC is to apply to be a mentor. LOL i love it. |
| 11:30.30 | sachinjain | hey dloman....where are you from? |
| 11:30.53 | dloman | I am currently living in Pennsylvania, USA |
| 11:30.54 | dloman | you? |
| 11:31.30 | sachinjain | I am living in Hyderabad, india |
| 11:32.21 | sachinjain | so...you are one of the developer in BRL-CAD? |
| 11:33.58 | dloman | A newbie, but yeah :) |
| 11:34.24 | sachinjain | it seems a very big open source project |
| 11:39.05 | sachinjain | how much time does it generally takes to download all the source and binaries... |
| 11:39.19 | sachinjain | through brl-cad repository |
| 11:39.48 | sachinjain | its taking a hell lot of time |
| 11:43.54 | dloman | its abig repo. we maintain nearly all required deps internally in case they are not present on the current system. |
| 11:54.52 | sachinjain | okie....while other files are being downloaded |
| 11:54.57 | sachinjain | I have |
| 11:55.01 | sachinjain | "ru.h" |
| 11:55.09 | sachinjain | "rtedge.h" |
| 11:55.15 | sachinjain | n "rgeom.h" |
| 11:55.22 | sachinjain | what should I do with them? |
| 11:55.39 | dloman | I'd say read them. Get to know the code base a bit. |
| 11:56.04 | dloman | before you can do any develop that's worth anything, you have to get familiar with the existing code. |
| 11:56.18 | dloman | not *all* of it, but enough to know where you will be primarily working. |
| 11:57.53 | sachinjain | "ru.h" is very big |
| 11:58.05 | sachinjain | how can I get familiar with something like that |
| 11:58.07 | dloman | bu.h? |
| 11:58.12 | sachinjain | yeah.... |
| 11:58.15 | sachinjain | "bu.h" |
| 11:58.52 | dloman | I'd think that looking at the build system, seeing what executables and libraries are made is a good start |
| 11:59.19 | dloman | launch mged and get a feel for what brlcad's primary modeler looks like. |
| 11:59.39 | dloman | then start tracing backwards from the build system. |
| 11:59.50 | dloman | see what the app touches in the way of source files. |
| 12:00.15 | dloman | that should give you a feel for where your project fits in to the big picture, 'source-wise' |
| 12:00.54 | dloman | its a big code base and takes years to get familiar with, so don't sweat it if its still mostly foriegn to you at the end of hte summer :) |
| 12:01.14 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 12:04.04 | CIA-52 | BRL-CAD: 03davidloman * r43974 10/geomcore/trunk/include/IDataSource.h: Require classes implementing IDataSource to have a init() fn. (Even if its a stub). This is needed for both the FS data source(DS) and SVN DS. |
| 12:05.06 | CIA-52 | BRL-CAD: 03davidloman * r43975 10/geomcore/trunk/ (include/FileDataSource.h src/GS/FileDataSource.cxx): Implement minimal init() checks for the FS DataSource. |
| 12:05.53 | sachinjain | is there any README file? |
| 12:06.06 | dloman | yes, should be in the root of the checkout. |
| 12:12.34 | CIA-52 | BRL-CAD: 03davidloman * r43976 10/geomcore/trunk/include/FileDataSource.h: Oops. Can't make an interface mandated function private. Change visibility to public. |
| 12:22.42 | CIA-52 | BRL-CAD: 03davidloman * r43977 10/geomcore/trunk/src/GS/FileDataSource.cxx: Log success/failure of IO tests on the repo path. |
| 12:24.37 | dloman | brlcad: How does Ohloh know about the brlcad repo? Did you have to add the url to ohloh's database or did it just all happen automagically? |
| 12:25.00 | dloman | I only ask cause it seems that ohloh isn't seeing the /geomcore module. |
| 12:25.13 | dloman | and was wondering if that new module needs to be added somewhere |
| 12:26.40 | dloman | hah, nevermind. |
| 12:58.19 | CIA-52 | BRL-CAD: 03davidloman * r43978 10/geomcore/trunk/src/GS/GeometryService.cxx: Quick Type Fix |
| 12:59.53 | CIA-52 | BRL-CAD: 03davidloman * r43979 10/geomcore/trunk/src/GS/DataManager.cxx: Wire in FileDataSource init() call and return check. |
| 13:08.51 | dloman | digs into coreInferface. Need to get ejumakated on dis. |
| 13:15.43 | *** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194) | |
| 13:30.23 | CIA-52 | BRL-CAD: 03Dloman 07http://brlcad.org * r2763 10/wiki/TypeOnlyMsg: Enter the simple wiki page for TYPEONLYMSG |
| 13:32.03 | CIA-52 | BRL-CAD: 03Dloman 07http://brlcad.org * r2764 10/wiki/NetMsgTypes: Admit that this list is not up to date :( |
| 13:36.02 | ``Erik | *readreadread* yowza, blew out my buffer this weekend O.o |
| 13:37.28 | CIA-52 | BRL-CAD: 03Dloman 07http://brlcad.org * r2765 10/wiki/GenericFourBytesMsg: Remove caps |
| 13:37.40 | sachinjain | Dloman: From where should I start checking binary files |
| 13:37.45 | sachinjain | I am stuck all along |
| 13:37.53 | dloman | 'stuck' ? |
| 13:38.00 | dloman | as in you are lost in the code ? |
| 13:38.06 | sachinjain | I mean...I dont know from where should I start |
| 13:38.17 | sachinjain | which file should I look into |
| 13:38.28 | sachinjain | first |
| 13:38.42 | dloman | have you compiled yet? |
| 13:38.45 | CIA-52 | BRL-CAD: 03Dloman 07http://brlcad.org * r2766 10/wiki/GenericEightByteMsg: Write up description for GenericEightByteMsg |
| 13:39.12 | sachinjain | I have run.... |
| 13:39.15 | sachinjain | sh autogen.sh |
| 13:39.19 | sachinjain | ./configure |
| 13:39.22 | CIA-52 | BRL-CAD: 03Dloman 07http://brlcad.org * r2767 10/wiki/GenericEightByteMsg: Drat! CopyPaste strikes again! Fixed. |
| 13:39.31 | sachinjain | n now.."make" is running |
| 13:40.17 | dloman | ``Erik: any 'esssssspert' advice on where a good starting point for learning the code is? |
| 13:40.42 | ``Erik | um, to what end? there're lots of good starting points for different end pionts |
| 13:40.43 | ``Erik | points |
| 13:41.13 | dloman | "generate vector drawings" |
| 13:41.45 | sachinjain | yeah...erik... |
| 13:41.46 | ``Erik | hrm, like an svg outputting tool with an rt interface? lemme read the wiki |
| 13:41.49 | sachinjain | please help |
| 13:42.57 | ``Erik | obviously, check out http://brlcad.org/wiki/Google_Summer_of_Code/Checklist |
| 13:42.59 | CIA-52 | BRL-CAD: 03Dloman 07http://brlcad.org * r2768 10/wiki/NetMsgTypes: Add in some descriptions for the simpler messages |
| 13:43.45 | dloman | ``Erik: FYI the wiki was correct on the PING and PONG. HEADER + a single 8byte field. |
| 13:43.56 | ``Erik | doh, musta missed that |
| 13:44.11 | ``Erik | http://brlcad.org/wiki/Vector_output_from_raytracing lists some useful tools/files to look at |
| 13:44.32 | dloman | no worries, i only write wiki pages in bad-engilsh and stupid. You should feel good you're not fluent in those :) |
| 13:45.18 | ``Erik | nah, I'm used to seeing pings only done as "send a ping, save my time locally... wait for the response, compare it to the local time", since clock drift between two machines is inevitable |
| 13:46.13 | ``Erik | my guess is that brlcad means to take an approach similar to rtedge (src/rt/viewedge.c) to sample and then string it together into a vector set by line/curve fitting |
| 13:47.02 | ``Erik | so running rtedge and looking at viewedge.c would be the right beginning point for the BRL-CAD side, the papers good for the algorithm, then figuring out the ps/pdf/svg format for the write phase |
| 13:47.18 | sachinjain | just these two files |
| 13:47.28 | sachinjain | "src/rt/viewedge.c" |
| 13:47.36 | sachinjain | "src/rt/view.c" |
| 13:47.37 | sachinjain | ?? |
| 13:47.54 | ``Erik | that's the starting point... in understanding how it works, many other files will be involved :) all the way down to libbu stuff |
| 13:48.33 | ``Erik | a tool like cscope (or an IDE that does that kind of thing) can be very useful in exploring |
| 13:50.38 | ``Erik | I wonder if finishing up the 'time per ray' raytracer would be a good "acceptance patch" |
| 13:52.58 | dloman | hey brlcad: Can i write the GS in java? I'd be done by the end of the day! ;) |
| 13:53.16 | dli | looks like brlcad need to update 7.18.4 ETA daily :) |
| 14:00.14 | d_rossberg | dloman: any questions about the coreInferface? |
| 14:00.28 | *** join/#brlcad sachi1325_ (75d3557b@gateway/web/freenode/ip.117.211.85.123) | |
| 14:02.52 | dloman | d_rossberg: not yet, still reading :) |
| 14:09.30 | starseeker | dloman: depending on where we are Wednesday, you may have to try it :-/ |
| 14:09.53 | dloman | i just cant seem to program fast in c or c++ :/ |
| 14:10.13 | starseeker | is down the svn rabbithole |
| 14:10.41 | starseeker | dloman: if it really would help, can you prototype the whole thing in java in a day and have something working? |
| 14:10.55 | dloman | quite likely |
| 14:11.26 | starseeker | unless ``Erik disagrees, I'd say having SOMETHING that runs is critical right now |
| 14:11.42 | dloman | currently, it runs just fine =D |
| 14:11.50 | starseeker | geometry is moving across the wire? |
| 14:12.05 | dloman | .... it runs just fine! =D |
| 14:12.23 | starseeker | lol |
| 14:13.05 | starseeker | I can disassemble and reassemble most (not all) of the .g, but I can't yet apply changes |
| 14:13.37 | starseeker | that's what I'll be having to tackle over the next few days |
| 14:14.39 | starseeker | I'm hoping the file backend will suffice to iron out the "moving bits of geometry across the wire" issues (even if the .g file is a rather... large bit of geometry) |
| 14:15.50 | starseeker | dloman: I'm guessing byte arrays of the bu_external variety are well suited to your needs? |
| 14:16.22 | dloman | so long as its got ALL the data for the dbobject, yup! |
| 14:16.43 | starseeker | one of the outstanding issues is why the region_id information is getting stripped by the approach I am taking |
| 14:17.27 | starseeker | I'm using the internal to external and external to internal routines, which is pretty much the same level the dbio layer uses |
| 14:18.12 | starseeker | unfortunately, that means where precisely I'm losing the region_id info is a bit murky |
| 14:19.08 | dloman | ``Erik: lynx is pretty neat :) |
| 14:20.52 | CIA-52 | BRL-CAD: 03erikgreenwald * r43980 10/geomcore/trunk/src/GS/testclient/gstestclient.c: add start (clientside) timestamp |
| 14:22.00 | CIA-52 | BRL-CAD: 03davidloman * r43981 10/geomcore/trunk/prototyping/: Add in a prototyping directory for in process work. |
| 14:33.45 | dloman | starseeker: so what did we descide: we are, or are NOT compatable with the Apache license? |
| 14:33.53 | dloman | Apache v2.0 that is. |
| 14:33.57 | starseeker | we're fine to use it, we just can't mix code |
| 14:34.32 | starseeker | that's why the big change with the svnTest app |
| 14:34.57 | starseeker | I originally started by taking the svn client code and modifying, but now I'm just using the library APIs |
| 14:35.21 | dloman | kk |
| 14:35.42 | starseeker | which would have had to happen eventually anyhow, since the client APIs are too high level for us, but it kills two birds with one stone |
| 14:36.13 | starseeker | if we ever do a geometry specific backend, that'll probably have to be Apache |
| 14:36.14 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 14:36.32 | starseeker | but as with most things, we'll do that if/when need to so it's not an immediate concern |
| 14:36.59 | CIA-52 | BRL-CAD: 03erikgreenwald * r43982 10/geomcore/trunk/src/GS/testclient/gstestclient.c: woops, bufp, not buf |
| 14:38.32 | starseeker | ``Erik: do you know enough about the db read/write interface to know why rt_db_cvt_to_external5 would strip out region_id? |
| 14:39.43 | starseeker | I thought the functions it called would preserve attributes... |
| 14:42.05 | starseeker | I know why _GLOBAL information isn't there, but the region_id thing I don't get |
| 14:59.10 | ``Erik | region_id isn't an attribute, though.. it's a field, no? |
| 15:03.21 | ``Erik | hrm, hm, looks like it's also in the standard attribute set |
| 15:06.30 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 15:06.30 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:06.49 | CIA-52 | BRL-CAD: 03davidloman * r43983 10/geomcore/trunk/ (3 files in 2 dirs): Stub in interface requirements for and FileDataSource implementation of putObj(...), the ability to put a single db object into the datasource |
| 15:07.27 | ``Erik | looks like there's stuff to set the attribute to be the same as the GIFT region_id code in rt_comb_export5 |
| 15:07.47 | ``Erik | librt/comb/comb.c:405 |
| 15:14.36 | dloman | d_rossberg: are there samples of how to use your classes to load/save/create .g files anywhere? |
| 15:14.54 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 15:20.21 | d_rossberg | http://brlcad.org/wiki/CoreInterface_PrintTitle_Example is a simple example of how to load a database and perform a simple operation on it |
| 15:21.07 | dloman | awesome thanks |
| 15:21.20 | d_rossberg | however, first you have to decide which kind of database you want: |
| 15:21.41 | d_rossberg | readonly file, read/write file or in memory |
| 15:21.54 | dloman | reading thru your code, I think 'memory' is best for what I am working on. |
| 15:22.07 | d_rossberg | there it depends if you may or have to save you changes |
| 15:22.31 | dloman | just looking to to read/write from/to disk quickly |
| 15:24.35 | d_rossberg | to get an in memory database in the above example you have to replace BRLCAD::ConstDatabase by BRLCAD::MemoryDatabase, that's all |
| 15:25.17 | dloman | and, to verify, i can still dump an in memory dtaabase to file simply by calling save()... correct? |
| 15:25.33 | d_rossberg | correct |
| 15:25.41 | dloman | awesome. thanks! =D |
| 15:25.54 | d_rossberg | for creating elements and saving the database see e.g. http://brlcad.org/wiki/CoreInterface_Hallo_World_Example |
| 15:28.13 | d_rossberg | and http://brlcad.org/wiki/CoreInterface_Tree_Walker_Example for walking down the tree and writing the elements names to stdout (as an example) |
| 15:29.27 | dloman | nice. just read all your wiki pages. Dunno why i didn't think to check there, lol |
| 15:30.45 | d_rossberg | you may find the Get(objectName) and Set(object) methods handy too (in Constdatabase.h and Database.h) |
| 15:39.48 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 15:44.56 | CIA-52 | BRL-CAD: 03erikgreenwald * r43984 10/geomcore/trunk/src/GS/testclient/gstestclient.c: add more display stuff |
| 15:57.28 | *** part/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 15:59.09 | CIA-52 | BRL-CAD: 03erikgreenwald * r43985 10/geomcore/trunk/src/GS/testclient/gstestclient.c: indent |
| 16:00.11 | CIA-52 | BRL-CAD: 03davidloman * r43986 10/geomcore/trunk/include/ (brlcad/ conf/): Drop unused headers |
| 16:00.30 | dloman | ``Erik: got a second to swing by? |
| 16:00.41 | ``Erik | sure |
| 16:01.21 | CIA-52 | BRL-CAD: 03erikgreenwald * r43987 10/geomcore/trunk/src/GS/ (21 files in 2 dirs): indent |
| 16:05.56 | *** part/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 16:09.06 | dloman | Hrm... too bad d_rossberg logged off. it looks like his common.h is trying to clobber brlcad's common.h :/ |
| 16:12.57 | dloman | never mind on that, it looks as thought coreInterface's common.h isn't being installed! Ack! |
| 16:16.39 | CIA-52 | BRL-CAD: 03davidloman * r43988 10/rt^3/trunk/ (7 files in 3 dirs): Change core interface's common.h to cicommon.h and add it to cmake's install routine. It is needed for using the coreInterface libraries. |
| 16:17.30 | dloman | There. that's a quick fix. renamed common.h to cicommon.h and installed it :) |
| 16:18.27 | dloman | ``Erik: FYI, im wiring up geomcore to have libge as an external dep. So soon, you will need to have rt3 compilied and installed for geomcore to compile nad link. |
| 16:18.36 | dloman | i haven't committed that yet, just giving a heads up |
| 16:18.59 | dloman | 'compile nad link' ....lol that paints a funny picture. |
| 16:36.09 | dloman | starseeker: you still around? |
| 16:37.39 | *** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194) | |
| 16:38.13 | CIA-52 | BRL-CAD: 03erikgreenwald * r43989 10/geomcore/trunk/src/GS/testclient/gstestclient.c: add login |
| 16:42.25 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.238) | |
| 16:42.25 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:45.52 | CIA-52 | BRL-CAD: 03erikgreenwald * r43990 10/geomcore/trunk/src/libNet/netMsg/NetMsg.cxx: print msgType as hex |
| 17:06.36 | *** join/#brlcad siddharth (~siddharth@117.211.88.150) | |
| 17:13.52 | dloman | starseeker: Had a thought. You could hack that video into 10 minute segments and put it on youtube.... let them deal with the storage. |
| 17:20.04 | CIA-52 | BRL-CAD: 03Erik 07http://brlcad.org * r2769 10/wiki/NetMsgTypes: guessing at payloads |
| 17:20.33 | starseeker | figured to run it by brlcad and see what he thinks of it - probably more tweaking to do |
| 17:20.50 | starseeker | now that the streaming thing appears to work, he can tweak it on his own box too |
| 17:25.59 | CIA-52 | BRL-CAD: 03erikgreenwald * r43991 10/geomcore/trunk/src/utility/GSUuid.cxx: Tricky, uuid returns the length including the trailing 0 where std::string does NOT want it. Was causing an extra byte to be written into the packets. |
| 17:29.01 | dloman | ``Erik: was that was was causing the lockup? |
| 17:29.21 | dloman | ...cause I thought I fixeded that one already... :/ |
| 17:29.48 | brlcad | thx starseeker -- I was thinking that there'd probably need to be some more tweaking |
| 17:30.24 | brlcad | i guess sachinjain was having quite a tough time with some basic concepts |
| 17:31.22 | ``Erik | nah, but it was causing issues... caused an extra 0 to be written behind the uuid, since the geomclient used the same function, it worked (both sides expected the extra byte) O.o |
| 17:31.49 | dloman | righto, but I caught that one with the java junk i was making for the guys upstairs.... |
| 17:31.55 | dloman | guess i didnt commit it :/ |
| 17:32.24 | ``Erik | hm, *shrug* goes to show that completely seperate implementations are valuable :D |
| 17:32.24 | brlcad | region_id is stored as an attribute in v5 during comb export, but in memory, it's both an attribute and a field in the comb internal structure |
| 17:33.58 | brlcad | dloman: anyone can add new projects to ohloh, I forget how brl-cad was added but I took ownership and set up the svn repo links |
| 17:34.07 | brlcad | you do specify checkout points for them to track |
| 17:34.33 | dloman | yeah, i saw that right after i posted in the channel :) |
| 17:34.56 | brlcad | for the statistics to work, the specifically mention not listing branches unless they're fully self-contained/separate codes |
| 17:35.18 | starseeker | brlcad: I'm using rt_db_cvt_to_external5 to export and rt_db_external5_to_internal5 to import, but somehow g_diff is reporting region_id differences |
| 17:35.26 | brlcad | which geomcore would qualify, but not rt^3 with all of the other code |
| 17:35.37 | brlcad | starseeker: why so low? |
| 17:36.19 | starseeker | getting miminal bu_external byte arrays to feed directly into the subversion fs |
| 17:38.08 | brlcad | db_get_external() should give you the appropriate bu_external() |
| 17:38.34 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 17:39.23 | starseeker | do I still use rt_db_external5_to_internal5 to reassemble? |
| 17:39.40 | brlcad | not sure what rt_db_external5_to_internal5()'s purpose specifically is |
| 17:39.45 | brlcad | have to look it up |
| 17:39.49 | starseeker | k |
| 17:39.49 | brlcad | I've used db5_get_raw_internal_ptr() in the past |
| 17:40.09 | brlcad | it'll take that raw bu_external and give you an uncracked internal |
| 17:40.10 | starseeker | actually, looking closer it's only the region_id -1 cases where it didn't preserve it |
| 17:40.39 | brlcad | you still probably uncovered api inconsistency |
| 17:40.47 | brlcad | what'd it do with then? |
| 17:41.08 | starseeker | either didn't preserve them or didn't assign them on import, not sure which |
| 17:41.23 | starseeker | wonder if it's a signed/unsigned assumption somewhere |
| 17:41.25 | brlcad | so just no attribute |
| 17:41.29 | starseeker | right |
| 17:41.59 | starseeker | region_id WAS preserved on regions that had region flag and non-negative region id, from the looks of it |
| 17:42.51 | brlcad | there's no definition of valid region_id values, so technically, that's just like it dropping a region id of 1000 |
| 17:43.11 | starseeker | nods |
| 17:43.36 | starseeker | I can try the db_get_external and db5_get_raw_internal and see if that does the trick... |
| 17:43.50 | sachinjain | hi brlcad |
| 17:44.11 | starseeker | is a little itchy operating at this level of dbio - new turf |
| 17:44.31 | starseeker | plus I've still got to start slogging through how to do and apply diffs... |
| 17:44.36 | dloman | brlcad: if I wanted to get the byte equivalent of a memory database out of an rt_i, where would I look? |
| 17:44.59 | *** join/#brlcad sachi1325 (75d3557b@gateway/web/freenode/ip.117.211.85.123) | |
| 17:45.03 | brlcad | starseeker: looks like your routine calls my routine :) |
| 17:45.14 | starseeker | heh |
| 17:45.16 | starseeker | phooey |
| 17:45.21 | brlcad | plus does some more work |
| 17:45.26 | starseeker | so much for dodging the bullet that way |
| 17:45.37 | sachinjain | brlcad : do you remember me |
| 17:45.43 | sachinjain | we had a talk |
| 17:45.44 | starseeker | what I am doing seems to work surprisingly well, except for that one case |
| 17:45.48 | brlcad | the docs on rt_db_external5_to_internal5() sound like it should do what you want |
| 17:45.57 | brlcad | so it's more who's messing up |
| 17:46.07 | starseeker | nods - was afraid of that |
| 17:46.12 | brlcad | sachinjain: yes |
| 17:46.15 | starseeker | yech - bug hunt |
| 17:46.39 | starseeker | at least that -1 thing is a clue |
| 17:46.42 | brlcad | isolated and trivial to reproduce... doesn't get much better |
| 17:46.55 | sachinjain | brlcad : what should I do to get myself considered for that project? |
| 17:47.04 | starseeker | mutter... I suppose |
| 17:47.09 | brlcad | dloman: what do you mean by the "byte equivalent"? |
| 17:47.11 | starseeker | starts setting up the simple test case |
| 17:47.38 | brlcad | sachinjain: we provide a detailed checklist and lots of info on the website |
| 17:48.23 | dloman | brlcad: preferably, a byte array of bytes read from disk that constitute the database file |
| 17:48.48 | brlcad | starseeker: db5_import_attributes() seems to be completely unaware of attribute values so it's got to be during export |
| 17:48.52 | dloman | im working with Daniel's classes now, and am planning on using them to load a .g in |
| 17:49.14 | dloman | at that point, i'd like to simply dump the entire DB into a byte array and sling it down the socket. |
| 17:49.56 | dloman | or could i just read the entire db_i struct from memory? |
| 17:50.00 | starseeker | brlcad: sounds good - I did a keep with one of the -1 combs and am stepping through now |
| 17:50.13 | brlcad | dloman: there are lots of routines related to this (several that starseeker and I are talking about right now) ... it depends |
| 17:50.23 | brlcad | dloman: do you want there to be object awareness? |
| 17:50.31 | dloman | not at this point no. |
| 17:50.37 | brlcad | as in, "im expecting 10 and I received 10 objects"? |
| 17:50.53 | brlcad | then it has absolutely nothing to do with the rt_i |
| 17:51.24 | brlcad | the db_i has a pointer to both a disk pointer and a byte array |
| 17:51.27 | dloman | well right now, I am trying to just get an entire file read and sent. next step is to break the db into objects then send. |
| 17:51.45 | brlcad | dloman: the g_transfer tool does the latter already |
| 17:51.48 | dloman | and be able to cat it togeher on the other side. |
| 17:51.59 | brlcad | src/gtools/g_transfer.c |
| 17:52.06 | brlcad | that's a sender and a receiver all in one |
| 17:52.13 | brlcad | with object counting |
| 17:52.13 | dloman | kk |
| 17:52.17 | dloman | danke |
| 17:53.11 | brlcad | it also works entirely with in-memory databases on the receiving in, which is what you want for service handling |
| 17:53.24 | brlcad | starseeker: curious, what has a -1 region_id set? |
| 17:53.45 | dloman | heh, g_transfer looks strikingly similar to a pkg test file i saw once..... ;) |
| 17:53.51 | brlcad | that could very well be some signed/unsigned nasty |
| 17:54.29 | brlcad | dloman: yeah, it was based off of it .. tpkg implemented ttcp over libpkg, g_transfer implements the same thing but with .g object awareness |
| 17:54.58 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.136.134) | |
| 17:55.27 | starseeker | brlcad: ktank.g has a number of assemblies that have that setting |
| 17:55.36 | brlcad | very preliminary "geometry service" work way back when long before geometry service was being pushed, making sure that in-memory database processing worked |
| 17:55.39 | starseeker | possibly havoc too, but haven't confirmed that yet |
| 17:55.40 | brlcad | (it didn't originally) |
| 17:55.47 | brlcad | k |
| 17:56.55 | starseeker | Oooo! |
| 17:57.11 | starseeker | a keep on the same object also wipes out that region_id setting |
| 17:57.26 | starseeker | so it's not just my low level stuff, it looks like a legit bug |
| 18:00.28 | brlcad | so now, does the in-mem have it set as -1? |
| 18:01.03 | brlcad | looks like the attribute import/export code is ignorant, just treats them as strings |
| 18:01.18 | brlcad | that leaves the comb code |
| 18:02.54 | CIA-52 | BRL-CAD: 03Erik 07http://brlcad.org * r2770 10/wiki/NetMsgTypes: GSPONG is 0x62, not 0x61 |
| 18:05.41 | CIA-52 | BRL-CAD: 03Erik 07http://brlcad.org * r2771 10/wiki/GeometryServiceNetworkProtocol: Message Length does not include magic/length values. |
| 18:06.35 | CIA-52 | BRL-CAD: 03erikgreenwald * r43992 10/geomcore/trunk/src/GS/testclient/gstestclient.c: add transmission of remote node name. Fix off by 8 error causing lockup. Formatting cleanup |
| 18:06.46 | dloman | brlcad: looking at Daniel's code. He loads a database by calling rt_dirbuild and getting back a db_i* |
| 18:06.57 | dloman | and a err, |
| 18:07.14 | dloman | i ment 'and getting back an rt_i*' |
| 18:07.55 | dloman | since you're the expert, will the db_i* that the rt_i* have be in a condition where I can use it to get the data I need? |
| 18:08.02 | CIA-52 | BRL-CAD: 03brlcad * r43993 10/brlcad/trunk/src/librt/comb/comb.c: use atol() instead of atoi() since the fields are long. adjust printing routines to print long too. |
| 18:08.20 | brlcad | dloman: yes |
| 18:08.30 | brlcad | an rt_i contains a db_i |
| 18:08.40 | dloman | sexy, thanks! |
| 18:09.00 | dloman | btw, heard you're under the weather. Hope you feel better soon! |
| 18:09.45 | brlcad | the db_i is your handle to the database, it uses a plain FILE * or memory buffer or mapped file, depending on how the data is being managed (e.g., an in-memory-only database has no FILE *) |
| 18:09.58 | brlcad | there are routines for getting the memory buffer or traversing objects on a db_i |
| 18:10.16 | brlcad | it's easy to get both but iterating over objects is actually problably a little easier |
| 18:10.27 | brlcad | yeah, I think ed gave me a cold |
| 18:10.46 | dloman | well, if its any form of justice, he's out again today. ;) |
| 18:10.47 | brlcad | at least, I'm comfortable blaming him for it :) |
| 18:10.51 | dloman | lol |
| 18:10.52 | dloman | nice |
| 18:11.08 | brlcad | I slept for 14 hours last night trying to recover |
| 18:11.25 | dloman | see, now you've gone and made me insanely jealous |
| 18:11.51 | brlcad | I'll gladly come in and cough all over you so you too can feel this "blessing" |
| 18:11.57 | dloman | aahahaha. |
| 18:12.14 | dloman | i have 1600% DV c vitamins coursing thru my veins |
| 18:12.26 | dloman | (dont forget i have virus generators, err, kids, at home) |
| 18:13.00 | brlcad | I rarely ever get sick and get tons of exposure to sick kids too |
| 18:13.36 | brlcad | I'm chaulking this one up to weakened immune system from the long travel combined with complete lack of exercise |
| 18:14.30 | dloman | brlcad: how familiar are you with Daniel's coreInterface stuff? |
| 18:14.44 | brlcad | i've read through it a few times |
| 18:14.48 | dloman | kk |
| 18:14.57 | brlcad | pretty awesome use of in-mem db's |
| 18:15.17 | dloman | is an rt_db_internal* the representation of an object? |
| 18:15.45 | brlcad | that gets a database object in "internal representation" form |
| 18:15.53 | sachinjain | brlcad : is it necessary to submit a patch? |
| 18:16.09 | brlcad | sachinjain: it's highly recommended, however small and simple |
| 18:16.17 | brlcad | just to make sure you can actually read and write code |
| 18:17.14 | brlcad | most orgs have a similar request of applicants, it helps characterize your ability to become familiarized with the source code and communicate a trivial change |
| 18:18.08 | CIA-52 | BRL-CAD: 03erikgreenwald * r43994 10/geomcore/trunk/src/GS/testclient/gstestclient.c: more display stuff |
| 18:18.29 | brlcad | dloman: there are two types of internal representation -- an uncracked and a cracked form -- the GS should never have to deal with a cracked form (i.e. where it becomes aware of the radius value on a sphere) |
| 18:19.03 | dloman | nods. |
| 18:19.05 | brlcad | iirc, rt_db_get_internal is going to be the uncracked from, where you have the name and entity type |
| 18:19.49 | brlcad | major performance win to not deserialize fully |
| 18:19.55 | dloman | right no. |
| 18:20.01 | dloman | err, right on. |
| 18:20.53 | dloman | I am trying to use coreInterface as much as possible, fyi. The Object class has a db_i* pointer, rt_db_internal*, directory* and resource* |
| 18:21.02 | *** part/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 18:21.28 | brlcad | sounds like the appropriate minimum |
| 18:21.50 | dloman | from what little I know (via crash course over the last 24 hours) I think i have to grab the 'serialized' data out of the rt_db_internal.... correct? |
| 18:22.46 | brlcad | db_i is a pointer to the object's container, rt_db_internal is a pointer to the object's data, directory is a pointer to a tree-prep'd record from the db_i, and resource is "magic" that makes it all work faster on multiprocessor systems |
| 18:23.16 | CIA-52 | BRL-CAD: 03Erik 07http://brlcad.org * r2772 10/wiki/NewSessionReqMsg: New page: Two (GS style network order uint32_t followed by ascii, no terminating 0) strings First is username Second is password (in plain text) |
| 18:23.29 | dloman | "Object's Container" ... as in the database file? |
| 18:23.36 | brlcad | the rt_db_internal IS the object in a half-serialized, half-deserialized form .. for schlepping it over the wire, you want to convert from internal to external form |
| 18:23.41 | starseeker | ok, rt_db_get_intern returns an intern that DOES have a populated idb_avs structure... |
| 18:23.49 | brlcad | dloman: it's not necessarily a file, but yes |
| 18:23.56 | brlcad | it's just "the database" |
| 18:24.09 | dloman | doh. I used the word file. ;) |
| 18:24.40 | starseeker | and correctly populated |
| 18:25.18 | CIA-52 | BRL-CAD: 03Erik 07http://brlcad.org * r2773 10/wiki/Common_NetMsg_Exchanges: list initial connect pattern |
| 18:25.35 | dloman | brlcad: the internal->external conversion somewhere in raytrace.h ? |
| 18:26.08 | ``Erik | rt_*_export5 |
| 18:26.45 | brlcad | dloman: of course :) |
| 18:26.53 | brlcad | dloman: see send_to_server() in g_transfer.c |
| 18:27.03 | brlcad | does exactly what you should be needing |
| 18:27.28 | siddharth | hello |
| 18:27.37 | ``Erik | ah, db_get_external |
| 18:27.50 | siddharth | for the patch thing,what should we do exactly? |
| 18:27.54 | siddharth | any ideas? |
| 18:28.04 | brlcad | you can go lower-level and use the export routines, but db_get_external() is a lot simpler, just taking a directory pointer |
| 18:28.18 | brlcad | siddharth: it's entirely up to you |
| 18:28.30 | brlcad | the more impressive your patch, the more impressive your submission |
| 18:28.39 | dloman | ``Erik: thanks for all the wiki-fu. My heads spinning :/ |
| 18:28.46 | brlcad | something simple to show that you can read/write code is a minimum basic, siddharth |
| 18:28.57 | siddharth | ok thanks :) |
| 18:29.06 | brlcad | siddharth: you can start with just about anything in our BUGS file or TODO file or something in one of our trackers |
| 18:29.12 | ``Erik | complete circles? will there be split pea soup vomit, I skipped lunch :/ |
| 18:29.38 | brlcad | starseeker: jeez, I'm not seeing anything reading code on my end |
| 18:29.41 | dloman | okay, see... there's the 'line'... and you just crossed it. |
| 18:29.49 | brlcad | hopefully you have better luck with the debugger |
| 18:30.56 | siddharth | Ok..one more question,what can we do in BUGS file? |
| 18:31.35 | brlcad | siddharth: next you're going to ask me where and how to fix the bug? |
| 18:31.38 | brlcad | is this 20 questions? :) |
| 18:31.48 | siddharth | lol :P |
| 18:31.57 | brlcad | you can do any of them... |
| 18:32.33 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 18:32.34 | brlcad | some are hard, some are easy -- you have to figure that out |
| 18:32.35 | siddharth | ok ill try them out :) |
| 18:32.40 | starseeker | brlcad: yeah, this is an annoying bugger |
| 18:33.10 | brlcad | siddharth: if you need more specific hand-holding, there are some code projects listed at http://brlcad.org/wiki/Quickies |
| 18:33.39 | siddharth | thanks |
| 18:33.47 | brlcad | some of those, however, are harder than the BUGS and TODO items |
| 18:34.33 | starseeker | brlcad: ah HAH |
| 18:34.48 | starseeker | the internal representation is being altered by rt_comb_export5 |
| 18:35.09 | starseeker | that's where the ip->idb_avs.count changes from 1 to 0 |
| 18:39.03 | dloman | Hrm, hitting a C++ knowledge wall. The only way to know what type class you are dealing with is to attempt a dynamic_cast<> and then check the result for NULL ? |
| 18:39.08 | dloman | ...anyone? |
| 18:39.29 | starseeker | brlcad: I think I've got it |
| 18:39.43 | starseeker | not sure what to do about it though |
| 18:40.14 | starseeker | comb.c:358 - encodes "other stuff" as attributes |
| 18:40.37 | starseeker | the region_id of the comb itself (internally) is out of sync with the region_id string attribute |
| 18:41.38 | starseeker | line 405 checks for a non-zero comb->region_id |
| 18:42.05 | starseeker | it doesn't find it (because it's checking the comb's data structure, not the string attribute) |
| 18:42.36 | starseeker | so it runs bu_avs_remove on the avsp and strips region_id |
| 18:44.14 | starseeker | in effect, this aspect of the comb export makes it impossible to have separate values in the comb data structure and the associated attribute |
| 18:44.45 | starseeker | dloman: uh, not sure |
| 18:45.07 | ``Erik | for c++, you can enable rtti and do 'isInstanceOf()' or something |
| 18:45.32 | ``Erik | but there's overhead to enabling rtti |
| 18:45.35 | dloman | just looked it up. FYI dynamic cast will return a NULL if a type cast fails and you're dealing with pointers, but throws an Exception if you're dealing with references. |
| 18:45.45 | starseeker | does typeid help any? |
| 18:46.27 | starseeker | http://en.wikipedia.org/wiki/Typeid |
| 18:56.06 | CIA-52 | BRL-CAD: 03erikgreenwald * r43995 10/geomcore/trunk/src/GS/testclient/gstestclient.c: hoist time function |
| 19:05.40 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 19:06.45 | *** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 19:07.33 | brlcad | starseeker: it's saying you have to create a profile before I can add you (on socghop.appspot.com) |
| 19:07.58 | starseeker | k, one sec |
| 19:08.50 | brlcad | same thing for ed's account |
| 19:09.03 | brlcad | dloman: did you create a link_id yet? |
| 19:09.09 | dloman | neat. coreInterface just bombed me out: http://pastebin.mozilla.org/1193575 |
| 19:09.17 | dloman | ....can't say that I have. |
| 19:09.31 | dloman | socghop.appspot.com? |
| 19:10.02 | dloman | I've registered that site and applied to be a brlcad mentor. |
| 19:10.07 | dloman | ...is that a link_id ? |
| 19:10.46 | dloman | man, what a terrible day. |
| 19:11.02 | dloman | im missing blantantly obivous things |
| 19:11.09 | dloman | brlcad: yes, i have a link_id |
| 19:11.14 | dloman | do you want it? |
| 19:11.14 | starseeker | brlcad: uh... where do I create a profile? |
| 19:11.16 | brlcad | dloman: when did you submit the request? |
| 19:11.21 | starseeker | this new site is less than helpful |
| 19:11.34 | dloman | http://socghop.appspot.com/gsoc/profile/google/gsoc2011 |
| 19:11.37 | brlcad | if you sent it before the site change, then you'll have to resubmit it |
| 19:11.49 | dloman | brlcad: this morning, if it didn't mess up on me. |
| 19:11.56 | brlcad | regardless you'll need to resubmit it because you're not in the pending requests queue :) |
| 19:11.59 | dloman | brlcad: am i not showing up? |
| 19:12.05 | dloman | okie, will do. |
| 19:12.11 | brlcad | daniel's came through |
| 19:12.21 | starseeker | dloman: that site isn't accessible because I don't have a profile |
| 19:12.38 | starseeker | Oh, I see it |
| 19:12.45 | starseeker | growl |
| 19:12.50 | brlcad | likes the new look |
| 19:12.56 | brlcad | work in progress, but it's better |
| 19:13.10 | dloman | i like the look also, the navigation needs a bit of work |
| 19:13.12 | brlcad | just not quite ready for production |
| 19:13.18 | dloman | brlcad: submitted |
| 19:13.36 | brlcad | got it and approved |
| 19:13.47 | dloman | smashing old chap! |
| 19:15.37 | brlcad | note that anything that redirects to www.google-melange.com may be blocked ... but socghop.appspot.com works, just edit the url manually |
| 19:15.58 | brlcad | someone needs to send a request in to get it unblocked |
| 19:17.04 | ``Erik | beat, I broke it :D |
| 19:17.07 | ``Erik | neat, even |
| 19:17.15 | brlcad | yeah I see that |
| 19:17.33 | brlcad | I can withdraw it, but not approve |
| 19:17.41 | brlcad | looks like admins are auto-mentors this year |
| 19:17.41 | ``Erik | when I click anything either 'accept' or 'reject', I get "You cannot be a mentor for BRL-CAD to access this page." |
| 19:18.12 | brlcad | heh, it let me withdraw the request |
| 19:18.12 | starseeker | brlcad: sent |
| 19:19.22 | brlcad | just need to get ed, larry, tom, and curly registered |
| 19:20.00 | dloman | Moe? |
| 19:20.08 | brlcad | that'd be ed |
| 19:20.15 | dloman | *snicker* |
| 19:20.29 | brlcad | although he does a great curly |
| 19:21.50 | starseeker | brlcad: what do you think about comb and attributes? |
| 19:21.57 | brlcad | was just looking at that |
| 19:24.02 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 19:35.35 | bhinesley | FYI, ACM student membership is dirt cheap, and it comes with a MSDN Academic Alliance account, which provides Visual Studio 2005 Professional (and many others) for free. |
| 19:42.01 | brlcad | dloman: FileDataSource::getObj() .. when is the iterator incremented? |
| 19:42.41 | brlcad | during Good()?? |
| 19:42.48 | dloman | nice catch, thanks :) |
| 19:43.01 | brlcad | same in FileDataSource::getObjs() |
| 19:43.31 | dloman | getObj() is only supposed to get ONE object, so no inrementing needed. |
| 19:43.44 | dloman | this is still just a 'proof' that I can actually do this :) |
| 19:43.50 | dloman | cleanup to follow |
| 19:43.56 | *** part/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 19:44.25 | brlcad | should toss-in FIXME's though when the code doesn't do what the function suggests, so it's not lost down the road |
| 19:44.36 | dloman | right on |
| 19:44.37 | brlcad | and ends up being a multi hour/day debugging |
| 19:45.21 | dloman | Hrm, even with the iterator incrementor, it still bombs. |
| 19:45.48 | brlcad | it's bombing an uninitialized vls .. which could be lots of things |
| 19:46.09 | dloman | righto. I'll check it out tomarrow.... I'm fried :( |
| 19:46.11 | CIA-52 | BRL-CAD: 03davidloman * r43996 10/geomcore/trunk/CMake/FindBRLCAD.cmake: Make FindBRLCAD.cmake find libge. Likely not the best spot for this lib, since its in the rt3 module, but it works for now. |
| 19:46.13 | CIA-52 | BRL-CAD: 03davidloman * r43997 10/geomcore/trunk/ (8 files in 2 dirs): Wire in libge (aka coreInterface) classes for loading and saving .g databases. Implement bare bones read/write for .g files in the FileDataSource class. |
| 19:46.35 | CIA-52 | BRL-CAD: 03davidloman * r43998 10/geomcore/trunk/tests/GS/ (CMakeLists.txt FileDataSourceTest.cxx): |
| 19:46.35 | CIA-52 | BRL-CAD: Implement basic test for FileDataSource class. A database with a primitive at |
| 19:46.35 | CIA-52 | BRL-CAD: top works fine, however a combination at top with a primitive as a child causes |
| 19:46.36 | CIA-52 | BRL-CAD: a bomb: http://pastebin.mozilla.org/1193575 Will investigate asap. |
| 19:46.36 | dloman | well that took a while. |
| 19:52.42 | ``Erik | this is requiring rt^3 now? |
| 19:53.29 | dloman | ya, just put that in |
| 19:53.40 | dloman | rt3 should compile and install with no problem. |
| 20:03.19 | ``Erik | heh, libge doesn't seem to be linking libbu :/ |
| 20:08.45 | CIA-52 | BRL-CAD: 03erikgreenwald * r43999 10/rt^3/trunk/src/ (coreInterface/CMakeLists.txt libge/CMakeLists.txt): add BRL-CAD link libraries |
| 20:25.58 | CIA-52 | BRL-CAD: 03Erik 07http://brlcad.org * r2774 10/wiki/GSNet_String: mention lack of terminating NULL |
| 20:26.34 | CIA-52 | BRL-CAD: 03Erik 07http://brlcad.org * r2775 10/wiki/Category:Geometry_Service: New page: Pages related to the GeometryService |
| 20:28.36 | CIA-52 | BRL-CAD: 03Erik 07http://brlcad.org * r2776 10/wiki/NetMsgTypes: fix link |
| 20:29.24 | kunigami | hi, how do I add a regression test? I want to implement one for a function of a library. Should I provide a code with main function calling this function and perform some assertions? |
| 20:31.58 | ``Erik | <PROTECTED> |
| 20:33.19 | kunigami | ok! thanks! |
| 20:33.35 | brlcad | kunigami: if it's only testing the interface, then it's just a unit test and can be added as a noinst binary in any directory (e.g. the examples erik mentioned) |
| 20:34.01 | brlcad | if it's going to compare an interface with known good input that might change down the road, then it can be added as a regression test in the regress/ directory |
| 20:34.24 | brlcad | most of those are shell scripts that perform integration testing and/or regression testing |
| 20:36.05 | CIA-52 | BRL-CAD: 03erikgreenwald * r44000 10/rt^3/trunk/src/ (coreInterface/CMakeLists.txt libge/CMakeLists.txt): woops, old cache, update to new variable names |
| 20:44.02 | kunigami | the function I'm referring to is 'bu_basename', which I think lies on "testing interface" case. What do you mean by 'noinst' binary? |
| 20:44.36 | starseeker | a noinst binary refers to a binary that has build logic to create it but not install it |
| 20:44.44 | starseeker | e.g. a "make install" won't do anything with it |
| 20:45.03 | starseeker | check the Makefile.am in src/libbn for bntester, for example |
| 20:45.40 | kunigami | hmm perfect! thank you |
| 21:02.22 | kunigami | ok, so I also have to modify Makefile.am template. I need to add a rule to compile my tester program and declare it to be noinst_PROGRAM. one more doubt: what means FAST_OBJECTS on the Makefile at src/libbu? |
| 21:02.40 | kunigami | *Makefile.am |
| 22:51.51 | *** join/#brlcad Ralith (~ralith@d142-058-175-056.wireless.sfu.ca) | |
| 00:51.01 | starseeker | huh - asymptote has the ability to plot a NURBS surface, apparently: http://asymptote.sourceforge.net/gallery/ |
| 01:10.22 | *** join/#brlcad crazy_imp (~mj@a89-182-15-178.net-htp.de) | |
| 01:40.23 | brlcad | kunigami: you don't really need to worry about FAST_OBJECTS -- you can either list there or not, inconsequential |
| 01:44.45 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 01:56.59 | brlcad | how goes the application sachinjain |
| 02:08.18 | sachinjain | I just woke up |
| 02:08.34 | sachinjain | I have started to get familiar with the application |
| 02:08.58 | sachinjain | even the installation tool so much of my time |
| 03:14.29 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 03:14.29 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 03:18.16 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-125-83-101.dsl.bkfd14.sbcglobal.net) | |
| 03:18.21 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 03:18.49 | *** join/#brlcad crazy_imp (~mj@a89-182-15-178.net-htp.de) | |
| 03:18.49 | *** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 03:18.49 | *** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net) | |
| 03:18.49 | *** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ) | |
| 03:18.49 | *** join/#brlcad poolio_ (~poolio@BZ.BZFLAG.BZ) | |
| 03:19.14 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 03:19.15 | *** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ) | |
| 03:19.15 | *** join/#brlcad kanzure_ (~kanzure@bioinformatics.org) | |
| 03:19.15 | *** join/#brlcad vtts (~vytautas@diz.ktu.lt) | |
| 03:19.16 | *** join/#brlcad hyarion_ (c05ben@peppar.cs.umu.se) | |
| 03:19.16 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 03:19.16 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 03:19.35 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 03:19.35 | *** join/#brlcad siddharth (~siddharth@117.211.88.150) | |
| 03:20.04 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 03:20.35 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 03:56.17 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 04:18.55 | *** part/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 04:37.27 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 04:57.40 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 05:00.36 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 05:30.57 | CIA-52 | BRL-CAD: 03davidloman * r44001 10/geomcore/trunk/src/GS/FileDataSource.cxx: Remove the simplistic (likely poor) read/write locks in FileDataSource for now. |
| 05:44.18 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 05:47.52 | *** part/#brlcad siddharth (~siddharth@117.211.88.150) | |
| 05:56.23 | dloman | Anyone still around? |
| 05:57.21 | bhinesley | probably not who you're looking for, but I am :) |
| 05:57.59 | dloman | Well now, you're correct, but nice to meet ya :) |
| 05:58.33 | bhinesley | you too |
| 05:59.30 | dloman | so, hang out here much? |
| 05:59.39 | bhinesley | pretty much constantly |
| 06:00.13 | dloman | quiet then? I don't see you chatting much. |
| 06:00.45 | bhinesley | I try not to interfere unless I have an important question, or significant contribution to the conversation. |
| 06:01.34 | bhinesley | I'm working on understanding the source, patches, and my GSoC proposal. |
| 06:01.53 | dloman | how long you been involved with brlcad? |
| 06:02.17 | bhinesley | just a week or two |
| 06:03.30 | bhinesley | probably closer to a week |
| 06:03.32 | bhinesley | how about you? |
| 06:04.06 | dloman | oh wow.... um. close to 3 years now, i think? |
| 06:04.11 | dloman | i lost track a long time ago |
| 06:04.14 | dloman | heh |
| 06:04.52 | bhinesley | that's cool. where are you? |
| 06:05.00 | bhinesley | (geographically) |
| 06:05.20 | dloman | 'south central' PA, usa. joo? |
| 06:05.34 | bhinesley | California |
| 06:06.24 | dloman | brlcad: I've narrowed that vls bad magic down to a bu_vls_free() call on lin 757 of Combination.cpp (coreInterface) |
| 06:06.57 | dloman | brlcad: I just don't know where to go from here (at this point), although Im gonna keep picking away at it. |
| 06:07.07 | dloman | bhinesley: first year at GSoC? |
| 06:07.46 | bhinesley | yeah |
| 06:08.33 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 06:08.33 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:09.23 | dloman | well enjoy it, its a blast. |
| 06:09.56 | dloman | we got a good crew here, so i hope you stick around |
| 06:10.08 | dloman | what caught your interest in brlcad anyways? |
| 06:10.16 | bhinesley | I plan to, and I hope I can help. |
| 06:11.16 | bhinesley | I have a fair amount of experience modeling 3D in AutoCAD, which I really loved doing. I like coding even more. |
| 06:12.07 | bhinesley | putting the two together sounds like a lot of fun |
| 06:12.44 | dloman | could be :) |
| 06:14.08 | dloman | where oh where is d_rossberg when ya need him! :) |
| 06:32.46 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 06:34.27 | dloman | hullo d_rossberg ! |
| 06:34.52 | dloman | if you got a few moment's, I'd like to chat a bit. |
| 06:35.02 | d_rossberg | dloman: ? it's half past two! |
| 06:35.23 | d_rossberg | about common.h? |
| 06:35.36 | dloman | actually its a bu_vls failure |
| 06:36.20 | d_rossberg | ok, where is the problem? |
| 06:37.36 | dloman | Combination.cpp:757 is seemingly causing a 'ERROR: bad pointer 0x1454eb10: s/b bu_vls(x89333bbb), was Zero_Magic_Number(x0)' failure |
| 06:38.30 | dloman | geomcore/trunk/tests/GS/FileDataSourceTest.cxx is the file I was using to perform a simple test |
| 06:38.47 | dloman | to open a .g, and iterate over the top items |
| 06:38.55 | dloman | err, 'top objects' |
| 06:39.01 | dloman | with a single object it works just fine |
| 06:39.34 | dloman | with two objects in the db, it bombs out with this backtrace: http://pastebin.mozilla.org/1193575 |
| 06:40.06 | dloman | I am admittedly not very familiar with the inner workings of the brlcad libraries. |
| 06:40.14 | dloman | all the C and Macros really really confuse me. |
| 06:41.24 | d_rossberg | i'm looking at it right now, may take some moments ... |
| 06:41.40 | dloman | I appriciate it! |
| 06:59.32 | CIA-52 | BRL-CAD: 03d_rossberg * r44002 10/rt^3/trunk/src/coreInterface/Combination.cpp: improved test for an only partly generated m_internalp (rt_comb_internal) after a long jump (C exception) |
| 06:59.49 | d_rossberg | this is not the entire solution, it only solves the error after the long jump |
| 07:00.41 | d_rossberg | i think, that db_dup_subtree fails if the database was removed (or something like this) |
| 07:03.52 | d_rossberg | i'll test it ... |
| 07:11.38 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 07:18.12 | dloman | thanks d_rossberg ! |
| 07:18.24 | dloman | i got a bit side tracked from the irc window, my apologies! |
| 07:41.56 | CIA-52 | BRL-CAD: 03d_rossberg * r44003 10/rt^3/trunk/src/coreInterface/Combination.cpp: initialize the VLS before first usage (in bu_vls_strcpy here) |
| 07:42.15 | d_rossberg | this should solve it, sorry ;} |
| 07:47.43 | dloman | Awesome thanks! |
| 07:48.07 | dloman | I'm gonna crash get some sleep, but I'll check it out later today. Thanks d_rossberg!! |
| 07:56.06 | d_rossberg | dloman: something for the notes: |
| 07:57.34 | d_rossberg | you should delete the object at the end with its Delete() method (not so important for your example, but if you have a real server ...) |
| 08:25.40 | d_rossberg | the common.hs: i've never installed the basic BRL-CAD's and and the C++ interface's headers into the same directory, i.e. there was always a distinction between common.h and brlcad/common.h |
| 08:42.38 | d_rossberg | see also the rt^3/include/brlcad/readme.txt file |
| 08:44.37 | d_rossberg | if there is a need to install both into the same directory i need to think over the C++ interface's naming conventions |
| 09:11.19 | d_rossberg | next: every Object has a static ClassName() and virtual Type() method (see Object.h) |
| 09:12.01 | d_rossberg | they can be compared by == (guess why ;) |
| 09:12.42 | d_rossberg | e.g.: if (obj->Type() == BRLCAD::Combination::ClassName()) then ... |
| 10:23.23 | dloman | d_rossberg: great stuff! You really did a bang up job on the coreInterface. |
| 10:50.48 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 11:23.35 | CIA-52 | BRL-CAD: 03davidloman * r44004 10/geomcore/trunk/src/GS/FileDataSource.cxx: Add iterator incr for proper iterating. |
| 12:07.50 | CIA-52 | BRL-CAD: 03davidloman * r44005 10/geomcore/trunk/tests/GS/FileDataSourceTest.cxx: Expand test out to getting a single object and then getting a list of all objects at top. |
| 12:09.24 | dloman | so... who can pick me up a Mt Dew on the way to work? ;) |
| 12:09.46 | dloman | has the need... the need for caffene! |
| 12:11.19 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 12:19.56 | dloman | d_rossberg: still around? |
| 12:21.53 | d_rossberg | yes |
| 12:22.20 | dloman | okay, so I've moved on to Add() ing objects to a memorydatabase. |
| 12:22.27 | d_rossberg | and probable the next 3 hours |
| 12:22.30 | dloman | and, as usual, i broke things, lol |
| 12:23.00 | dloman | made an Arb8 using two vector3d objects, but failed to give the arb8 a name. |
| 12:23.18 | dloman | and attempting to add that is causing a segfault. |
| 12:24.16 | dloman | I can see why at Database.cpp:229 |
| 12:24.19 | d_rossberg | the name is a property of the Object |
| 12:24.36 | d_rossberg | see http://brlcad.org/wiki/CoreInterface_Hallo_World_Example for example |
| 12:24.38 | dloman | where the call to object.Name() is returning a null char* |
| 12:24.56 | dloman | okie. Is this expected behavior then? |
| 12:26.06 | dloman | btw, great wiki entries. They'ev been most helpful. |
| 12:27.10 | dloman | I am wondering, in the event that someone like me attempts to .Add() an Object before setting its name, should there be a check or default name? |
| 12:27.28 | d_rossberg | that Name() returns 0 is OK, but i should probable test for a valid name before calling wdb_export |
| 12:32.10 | CIA-52 | BRL-CAD: 03d_rossberg * r44006 10/rt^3/trunk/src/coreInterface/Database.cpp: test for the presence of a name before trying to add a new object to the database |
| 12:49.28 | d_rossberg | dloman: every Object has a virtual Valid() method to test if it's ok |
| 12:51.21 | dloman | alirghty, good to know |
| 12:51.28 | dloman | hehe, more questions: |
| 12:53.27 | dloman | it seems that if I try to add two Arb8's in a row, the second one clobbers the first. |
| 12:54.03 | CIA-52 | BRL-CAD: 03d_rossberg * r44007 10/rt^3/trunk/src/coreInterface/Database.cpp: |
| 12:54.03 | CIA-52 | BRL-CAD: corrected the test for a non empty object name |
| 12:54.03 | CIA-52 | BRL-CAD: not using object.Valid() here because it should be possible to add "broken" objects e.g. during copying a broken database |
| 12:54.30 | d_rossberg | it looks like you add the arb8s always to an empty database |
| 12:54.59 | dloman | so should I add, save, add ? |
| 12:56.14 | d_rossberg | BRLCAD::MemoryDatabase md; creates an empty database |
| 12:56.47 | dloman | lol, duh. Okay. Thanks, i see my mistake. |
| 12:57.35 | d_rossberg | if you want to save the database after every operation you should consider using FileDatabase instead |
| 12:58.05 | dloman | Righto, I have seen my mistake. Error with the wetware :) |
| 13:03.09 | CIA-52 | BRL-CAD: 03davidloman * r44008 10/rt^3/trunk/ (3 files in 2 dirs): Make the GeometryEngine header file installable since this will serve as an excellent search point for FindLibGE.cmake |
| 13:17.52 | CIA-52 | BRL-CAD: 03davidloman * r44009 10/geomcore/trunk/ (CMake/FindBRLCAD.cmake CMake/FindLIBGE.cmake CMakeLists.txt): Give libGE its own cmake FIND file. Un-hack the ge find routines out of FindBRLCAD.cmake |
| 13:17.55 | dloman | there we go ``Erik give it a shot now. Unless you installed rt3 in some silly place, it should be found. Also, you will need to update rt3 as i changed it a bit so it will install GeometryEngine.h |
| 13:20.00 | dloman | oh dayum: http://www.cnn.com/2011/WORLD/asiapcf/03/29/japan.nuclear.reactors/index.html |
| 13:20.22 | dloman | 100 R water in a tunnel. Oh yeah, that's a core containment breach.... |
| 13:27.49 | kunigami | hi, I've updated my patch to basename. Comments are welcome. thanks. |
| 13:40.51 | CIA-52 | BRL-CAD: 03erikgreenwald * r44010 10/geomcore/trunk/CMake/FindLIBGE.cmake: allow libge directory to be fed explicitely |
| 13:41.05 | dloman | didnt work eh? |
| 13:42.52 | ``Erik | not quite yet |
| 13:43.25 | CIA-52 | BRL-CAD: 03erikgreenwald * r44011 10/geomcore/trunk/src/GS/CMakeLists.txt: add LIBGE_INCLUDE_DIRS |
| 13:49.35 | CIA-52 | BRL-CAD: 03erikgreenwald * r44012 10/geomcore/trunk/CMake/FindLIBGE.cmake: we already refer to brlcad/header.h, so do not include the brlcad/ in the search path |
| 13:53.54 | CIA-52 | BRL-CAD: 03erikgreenwald * r44013 10/geomcore/trunk/ (CMake/FindLIBGE.cmake src/GS/CMakeLists.txt): adjust include dir name to be consistent |
| 13:56.26 | CIA-52 | BRL-CAD: 03erikgreenwald * r44014 10/geomcore/trunk/src/GS/CMakeLists.txt: link libraries from Find* variables |
| 13:56.43 | ``Erik | there we go |
| 13:56.58 | CIA-52 | BRL-CAD: 03erikgreenwald * r44015 10/geomcore/trunk/tests/GS/CMakeLists.txt: add new libge stuff |
| 13:59.10 | CIA-52 | BRL-CAD: 03erikgreenwald * r44016 10/geomcore/trunk/src/libNet/netMsg/GenericEightBytesMsg.cxx: fix type warning |
| 14:01.14 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 14:28.31 | CIA-52 | BRL-CAD: 03starseeker * r44017 10/geomcore/trunk/tests/svntest/main.c: Start figuring out repo level commits, as opposed to doing it manually - not working yet |
| 14:29.20 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 14:29.20 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:39.33 | brlcad | first couple applications are in! |
| 14:39.45 | brlcad | thinks this cold nonesense needs to stop |
| 14:40.59 | *** join/#brlcad Jesselnz (~jesse@ool-435573a5.dyn.optonline.net) | |
| 14:41.10 | *** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 ETA 20110401 || Welcome GSoC 2011 Students! Speak up, ask questions, start here: http://brlcad.org/wiki/Google_Summer_of_Code/2011 | |
| 14:41.23 | brlcad | hello Jesselnz |
| 14:41.28 | Jesselnz | Hi |
| 14:42.54 | Jesselnz | A summer of code application involves doing a small task and sending in a patch, correct? |
| 14:42.56 | brlcad | starseeker: so a refresher from yesterday now that my head has cleared up a little bit and the tiny little hammers have taken a lunch break |
| 14:43.12 | Jesselnz | Do you have any suggestions for a task to get started with? |
| 14:43.12 | brlcad | Jesselnz: not *strictly* required, but highly highly recommended |
| 14:43.29 | Jesselnz | Alright |
| 14:43.32 | brlcad | you should get your proposal in first and say you're working on a patch at a minimum |
| 14:44.06 | brlcad | otherwise, I'd suggest just picking something tangible from our BUGS list or TODO file |
| 14:44.29 | Jesselnz | Okay |
| 14:45.12 | Jesselnz | I'm still trying to familiarize myself with the codebase for my proposal. |
| 14:45.16 | brlcad | sure |
| 14:45.25 | CIA-52 | BRL-CAD: 03brlcad * r44018 10/brlcad/trunk/TODO: there is a pending patch from Guilherme Kunigami (kunigami-dev) that should fix this issue, so remove the todo on bu_basename() |
| 14:45.27 | brlcad | if you find some that sound easy and want confirmation, just speak up |
| 14:45.54 | Jesselnz | I was planning to work on the conversion library, but I noticed it involves C++ (which I have no experience with) |
| 14:46.29 | brlcad | the patch shouldn't take more than a couple hours -- we just want to make sure you can actually code, at it gives you the opportunity to shine above other applicants if everything else is equal |
| 14:46.42 | brlcad | Jesselnz: what languages do you have experience with? |
| 14:47.02 | brlcad | it doesn't have to involve C++, it could be pure C |
| 14:47.09 | Jesselnz | Aside from scripting languages (Javascript, Per, Tcl), only C |
| 14:47.16 | Jesselnz | * Perl |
| 14:47.30 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 14:47.42 | brlcad | at least one of our converters has an implementation in C++, so that's why C++ is also listed, not because the library has to be in C or C++ |
| 14:47.50 | brlcad | a good design can arise from either |
| 14:47.54 | Jesselnz | Alright |
| 14:49.59 | brlcad | so are you really from new zealand? :) |
| 14:50.25 | Jesselnz | Me? |
| 14:50.34 | brlcad | you |
| 14:50.44 | Jesselnz | No, I'm from New Jersey |
| 14:50.52 | brlcad | aha, k |
| 14:51.23 | *** join/#brlcad Elrohir (~kvirc@p5B14B1EA.dip.t-dialin.net) | |
| 14:52.06 | brlcad | Jesselnz: how strong is your math? |
| 14:52.34 | Jesselnz | Well, first-year university level |
| 14:52.36 | Jesselnz | I'm a math major |
| 14:52.38 | brlcad | and do you have any computational geometry or computer graphics background? |
| 14:52.47 | brlcad | okay, cool |
| 14:53.14 | Jesselnz | Not really, but I've researched the basics |
| 14:54.06 | brlcad | instead of the geometry conversion library, you might want to consider proposing the image conversion library |
| 14:54.28 | brlcad | or the de-tcl project |
| 14:54.43 | Jesselnz | I'll look into those |
| 14:54.50 | brlcad | both don't involve any c++ |
| 14:55.30 | brlcad | what brought your interest to brl-cad? |
| 14:55.50 | Jesselnz | I just find CAD interesting |
| 14:56.00 | Jesselnz | Since I'm going into engineering, and I enjoy math |
| 14:56.40 | brlcad | how'd you come to learn Tcl as a first-year? |
| 14:56.55 | brlcad | covered in some first semester scripting class or something? |
| 14:57.30 | Jesselnz | I haven't taken any programming classes - just projects I've done on the side |
| 14:57.41 | brlcad | interesting |
| 14:58.30 | Jesselnz | I tried to write a 2d CAD program in high school using Tcl's C library |
| 14:58.47 | brlcad | then I'd definitely like to see some code or even work through some code with you, just to see exactly where you're at -- all skill levels are welcome if you have the passion, but need to make sure the project is scoped accordingly |
| 14:59.55 | Jesselnz | From the project I just mentioned? |
| 15:00.01 | brlcad | hah, then removing Tcl C api calls from our core library would essentially be the opposite :) |
| 15:00.25 | brlcad | no, I mean in terms of developing a patch to go with your proposal |
| 15:00.38 | brlcad | and scoping your proposal appropriately |
| 15:00.38 | Jesselnz | Alright |
| 15:01.18 | Jesselnz | Yeah, after looking through what exists of the gometry conversion library, it's a bit more algorithm-intensive than I was expecting |
| 15:03.16 | brlcad | and huge, that project entails wrangling up over 250k lines of code into an API |
| 15:03.33 | brlcad | the image processing library is less than half that |
| 15:18.01 | CIA-52 | BRL-CAD: 03davidloman * r44019 10/geomcore/trunk/ (4 files in 3 dirs): Implement FileDataSource's putObj() function. |
| 15:31.00 | CIA-52 | BRL-CAD: 03davidloman * r44020 10/geomcore/trunk/tests/GS/ (CMakeLists.txt SimpleCoreInterfaceTest.cxx): Implement a simple core interface test. |
| 15:36.39 | *** join/#brlcad |Elrohir| (~kvirc@p5B14B378.dip.t-dialin.net) | |
| 16:08.50 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 16:37.33 | CIA-52 | BRL-CAD: 03davidloman * r44021 10/geomcore/trunk/ (3 files in 3 dirs): GeometryChunk needs to be aware of its path. Added a path field, modified associated test. |
| 16:42.54 | dloman | brlcad: i get a byte[] from a socket... whats the quickest way to turn it into a brlcad struct that i can write to disk as a .g ? |
| 16:45.31 | dloman | i just noticed that starseeker isn't around today. |
| 16:51.16 | CIA-52 | BRL-CAD: 03r_weiss * r44022 10/brlcad/trunk/src/conv/dem-g.c: Fixed two bugs in the dem-g converter which were introduced in recent edits. One was a correction to the parameters for 'bu_calloc/bu_malloc' and the other was several duplicate 'bu_free'. |
| 16:56.54 | starseeker | brlcad: I took a look at the red problems on OSX 10.6.7 - it's a bit scary |
| 16:57.12 | starseeker | it's not anything I can pin down - the gedp pointer itself seems to have corrupt information |
| 16:57.40 | starseeker | at least according to gdb, but if it were going to wipe out I would have expected it to do so sooner than what I saw |
| 16:57.57 | starseeker | do you have a 10.6 mac by any chance? |
| 17:02.06 | starseeker | dloman: I'm around, just getting yanked here, there and everywhere |
| 17:12.45 | brlcad | dloman: you've really not spent any time reading g_transfer.c have you? once again, the answer to your question is in there, server_geom() |
| 17:13.52 | brlcad | there are a few ways you can turn (presumably bu_exported bytes) back into an object |
| 17:14.04 | dloman | i'm very tired, i got no sleep last night and am having trouble concentraiting. thanks for the reminder where it was. |
| 17:14.25 | brlcad | sure :) |
| 17:14.58 | brlcad | transfer uses a low-level method, cliff's test program used a slightly higher level function call that should work too |
| 17:15.31 | brlcad | starseeker: I do, although I've not updated to .7 yet |
| 17:15.50 | brlcad | any specific reproduction steps to try? |
| 17:22.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:27.29 | CIA-52 | BRL-CAD: 03brlcad * r44023 10/brlcad/trunk/ (doc/deprecation.txt include/raytrace.h): formally deprecate the GIFT field elements on rt_comb_internal objects: region_id, aircode, GIFTmater, and los. they are now stored as attributes. |
| 17:31.58 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.136.132) | |
| 17:38.52 | brlcad | starseeker: what steps were you using to debug the keep issue? |
| 17:40.00 | *** join/#brlcad Stattrav (~Stattrav@117.192.150.102) | |
| 17:40.00 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:43.38 | brlcad | man, the comb5 export function is messed up |
| 17:43.58 | brlcad | forcibly deconsts, clobbers data |
| 17:44.04 | brlcad | hate to fix this before a release |
| 17:44.41 | brlcad | starseeker: all of that logic in comb.c doesn't even belong there |
| 18:04.38 | *** join/#brlcad Stattrav (~Stattrav@117.192.139.178) | |
| 18:04.38 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:09.29 | starseeker | brlcad: for red, just try to edit a combination - hard crashes mged |
| 18:09.47 | starseeker | for keep - tried a keep of computer in ktank.g |
| 18:10.17 | starseeker | was watching the status of the avs list |
| 18:10.38 | brlcad | okay |
| 18:11.17 | brlcad | I'm getting a handle on the import/export problem |
| 18:11.25 | starseeker | awesome |
| 18:11.41 | CIA-52 | BRL-CAD: 03brlcad * r44024 10/brlcad/trunk/TODO: two issues to resolve now |
| 18:11.41 | starseeker | sorry we kept pestering you yesterday when you felt like crap :-/ |
| 18:11.53 | brlcad | comb export sucks, but that's old code so I don't want to edit any more than I have to this release |
| 18:12.02 | starseeker | nods |
| 18:12.15 | starseeker | it's not any more broken than it ever was |
| 18:12.27 | starseeker | only shows up when region_id and the comb struct aren't in sync |
| 18:12.28 | brlcad | no way to verify that :) |
| 18:12.35 | brlcad | well, there is a way, but would take too much time |
| 18:12.51 | brlcad | so the question is exactly when/where they get out of sync |
| 18:13.01 | brlcad | because that export code is just fine assuming they are in sync |
| 18:13.11 | brlcad | still sucks, but it's not wrong with that assumption |
| 18:13.25 | brlcad | so the problem is either during import or elsewhere |
| 18:19.01 | starseeker | I suppose in principle you might have some asc2g type thing where you import a comb and then set the region_id to -1 after creating the comb itself |
| 18:20.36 | starseeker | iirc red was capable of doing things like that before I added all that sync logic... and the .g files ktank.g and havoc.g are the product of running asc2g |
| 18:22.09 | starseeker | interesting - getting a more useful backtrace |
| 18:24.25 | starseeker | http://pastebin.mozilla.org/1194067 |
| 18:26.15 | starseeker | wooot - it DOES crash on my 10.5 mac |
| 18:26.21 | starseeker | wonder when that happened? |
| 18:26.24 | starseeker | ok, phew |
| 18:26.30 | starseeker | starts binary search |
| 18:36.31 | brlcad | while you're progressing from that direction, i'll see if I can find where the two get out of sync |
| 18:37.40 | starseeker | k - it looks like (surprise) some of the recent regex tweaking for red broke something |
| 18:39.34 | starseeker | yep - r43832 |
| 18:41.01 | brlcad | hmmm, interesting |
| 18:43.04 | brlcad | so either freeing something that shouldn't be or not initializing something after free |
| 18:46.40 | CIA-52 | BRL-CAD: 03brlcad * r44025 10/brlcad/trunk/src/libged/red.c: revert r43832 since it reportedly is causing red to crash. needs more investigating since this should have been a safe refactoring change. |
| 18:48.09 | brlcad | waits for builds to recompile so he can debug appropriately |
| 18:51.09 | CIA-52 | BRL-CAD: 03starseeker * r44026 10/brlcad/branches/cmake/ (14 files in 10 dirs): MFC r44025 |
| 18:51.46 | brlcad | oh shizzle |
| 18:51.51 | brlcad | how'd that happen |
| 18:52.08 | brlcad | looks like an == 0 got turned into a != 0 in that commit |
| 18:52.58 | starseeker | ah, line 164? |
| 18:53.21 | brlcad | yeah |
| 18:53.50 | brlcad | if that's the culprit, then r44025 should still crash |
| 18:54.00 | brlcad | since it's still != |
| 18:54.21 | starseeker | it's not - at least not in my build here - 44025 works |
| 18:54.30 | starseeker | (well, 44026 in cmake0 |
| 18:54.36 | brlcad | huh |
| 18:55.09 | brlcad | per the logic, == 0 should be right == if regex is successful |
| 18:55.29 | brlcad | i think :) |
| 18:55.43 | starseeker | it may not handle a matrix right, but it doesn't crash and does apply the changes in the simple case |
| 18:56.58 | starseeker | Ohhhhh |
| 18:57.21 | starseeker | I think my logic on red.c around line 425 may be screwy |
| 18:57.46 | starseeker | you have ret=0, and I was counting on -1 or 1 |
| 18:58.23 | brlcad | it was ret 0 previously |
| 18:58.26 | brlcad | I see what i did |
| 18:58.36 | brlcad | I swapped the if/else so != become an == case |
| 18:58.47 | brlcad | http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/libged/red.c?r1=43830&r2=43832&pathrev=43832 |
| 18:58.53 | starseeker | oh, ok |
| 18:59.22 | brlcad | so it's just back to being confusing as to why one works and the other doesn't |
| 18:59.47 | brlcad | functionally equivalent ... unless... |
| 19:01.04 | starseeker | matrix_substring is inited inside an if test... |
| 19:01.34 | starseeker | no, that doesn't look like it... |
| 19:04.22 | brlcad | smelling more like red herring |
| 19:10.03 | CIA-52 | BRL-CAD: 03starseeker * r44027 10/brlcad/trunk/src/libged/red.c: Take another stab at the refactor - this seems to work, but needs more testing |
| 19:13.35 | brlcad | hm, I just don't believe that to be the direct cause of any crash |
| 19:13.46 | brlcad | that's functionally equivalent |
| 19:14.10 | brlcad | init of the vls earlier was the only change, but that vls isn't accessed outside that one block |
| 19:14.18 | starseeker | nods |
| 19:14.27 | starseeker | can you confirm the crash prior to 44025? |
| 19:14.40 | brlcad | haven't tested |
| 19:14.46 | starseeker | k |
| 19:16.00 | brlcad | oh there's something different |
| 19:16.12 | brlcad | you made it always return 1 :) |
| 19:16.20 | brlcad | ignoring the ret var |
| 19:17.07 | brlcad | now that I'd believe .. that code elsewhere is at fault for not handling other return values correctly |
| 19:17.13 | starseeker | ah whooops |
| 19:18.28 | CIA-52 | BRL-CAD: 03brlcad * r44028 10/brlcad/trunk/src/libged/red.c: return the value that was set |
| 19:22.17 | starseeker | urm... still working here |
| 19:23.10 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:24.35 | starseeker | I take that back - it's not handling an example with a matrix right |
| 19:24.38 | starseeker | growl... |
| 19:31.32 | *** join/#brlcad Stattrav (~Stattrav@117.192.133.184) | |
| 19:31.32 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:36.10 | starseeker | blast it the full matrix regex isn't matching |
| 19:36.18 | starseeker | I could have sworn I tested all that |
| 19:36.30 | CIA-52 | BRL-CAD: 03brlcad * r44029 10/brlcad/trunk/src/librt/db5_io.c: init the external before trying to fill it. random stack memory is evil. |
| 19:36.43 | CIA-52 | BRL-CAD: 03brlcad * r44030 10/brlcad/trunk/src/librt/dir.c: save some time, don't init until we need to |
| 19:36.56 | brlcad | starseeker: maybe also related to the [:blank:] vs [:space:] change |
| 19:37.15 | brlcad | should be the same for any value that might continue to another line |
| 19:37.27 | brlcad | this begs for a proper regression |
| 19:37.35 | brlcad | bunch of input red files |
| 19:38.35 | CIA-52 | BRL-CAD: 03brlcad * r44031 10/brlcad/trunk/src/librt/db5_io.c: ws |
| 19:39.28 | CIA-52 | BRL-CAD: 03brlcad * r44032 10/brlcad/trunk/src/librt/dir.c: ws cleanup |
| 19:40.58 | starseeker | "[[:space:]]+([+-]?[0-9]*[.]?[0-9]+([eE][+-]?[0-9]+)?[[:space:]]+) {15}([+-]?[0-9]*[.]?[0-9]+([eE][+-]?[0-9]+)?)" |
| 19:42.02 | brlcad | for what it's worth, I get a rather different stack trace from yours |
| 19:42.41 | brlcad | same all the way up to rt_db_put_internal5(), mine never gets to rt_db_free_internal() |
| 19:43.10 | brlcad | so it's going wrong somewhere before there |
| 19:43.15 | starseeker | hmm |
| 19:45.35 | starseeker | hates regex |
| 19:48.23 | starseeker | it's not blank vs space |
| 19:49.15 | brlcad | we must gain deeper understanding as to what is failing and why, not just chase symptoms |
| 19:49.39 | starseeker | brlcad: I know - I'm after why it's not matching the matrix |
| 19:50.01 | starseeker | that has to be fixed toto |
| 19:50.03 | starseeker | to even |
| 19:50.06 | brlcad | nods |
| 19:50.24 | starseeker | I take it you're still crashing? |
| 19:50.37 | brlcad | i've been in the debugger on the same crash |
| 19:50.44 | starseeker | ah |
| 19:50.59 | brlcad | cleaning up code as I review up and down the stack |
| 19:50.59 | starseeker | jeez what a lousy time for this |
| 19:51.09 | starseeker | nods |
| 19:58.35 | CIA-52 | BRL-CAD: 03brlcad * r44033 10/brlcad/trunk/src/librt/db5_io.c: cleanup rt_db_cvt_to_external5(). make sure we check all inputs and initialize our bu_externals. |
| 20:09.09 | CIA-52 | BRL-CAD: 03starseeker * r44034 10/brlcad/trunk/src/libged/red.c: Ooops. one logical if statement error and a stray space in the full_matrix regex string |
| 20:13.28 | kunigami | brlcad: I'm taking a look at your comments of my patch. How do I enforce that callers of bu_basename release memory? Are there something like smart_pointers in c? |
| 20:14.03 | brlcad | kunigami: no way to enforce, just have to give them a quick sanity check |
| 20:14.14 | brlcad | s/way/need/ |
| 20:14.36 | brlcad | it's only because it's an api change (and deviation from basename()) that it even needs to occur |
| 20:14.49 | starseeker | bhinesley: did you get a chance to play with the Tcl/Tk code? |
| 20:15.56 | kunigami | hmm, what do you mean by "sanity check"? |
| 20:18.15 | brlcad | kunigami: a grep through the code to find all the callers, make sure the string is released or copied and released |
| 20:19.07 | brlcad | iirc, that routine is not called in more than a couple places -- if it's more than 15 min work, lemme know |
| 20:20.00 | kunigami | ok! |
| 20:20.00 | kunigami | One thing: if we're going to change interface, I'd suggest we also change the input to non-const (like basename). I think it would do less harm. Also, it would be compliant with basename (3), which may change the input string. |
| 20:20.49 | kunigami | then there's no need to allocate memory |
| 20:28.02 | CIA-52 | BRL-CAD: 03starseeker * r44035 10/brlcad/branches/cmake/src/ (libged/red.c librt/db5_io.c librt/dir.c): MFC r44034 |
| 20:31.30 | bhinesley | starseeker: Yes, I changed the export->ASCII to a tk_getSaveFile. It stands alone without the bug fix, so I'm submitting it in a few minutes. |
| 20:31.53 | bhinesley | I have gotten closer to finding the bug, but it is not in Tcl/Tk. |
| 20:32.04 | starseeker | brlcad: awesome :-) |
| 20:32.14 | starseeker | er bhinesley: awesome :-) |
| 20:32.41 | starseeker | note to self - read then post :-P |
| 20:33.12 | bhinesley | at least he wasn't talking about a family member dying or something |
| 20:33.48 | starseeker | heh |
| 20:36.36 | brlcad | kunigami: that's a good thought but then there are a couple issues |
| 20:36.41 | bhinesley | part of the problem, is that Windows 7 moves files into VirtualStore that are exported anywhere but the user profile. To the user, they're just not there. |
| 20:37.13 | brlcad | one being that dirname/basename suck .. they're the way they are because they were implemented that way a LONG time ago and it's painful to change API that old |
| 20:37.17 | bhinesley | the other problem is incorrect handling of windows paths, which is what I'm still tracking down |
| 20:37.24 | brlcad | they're not re-entrant or thread-safe, for example |
| 20:38.04 | starseeker | bhinesley: ah yes, Windows paths |
| 20:38.34 | starseeker | bhinesley: how are you building on Windows? |
| 20:38.40 | brlcad | kunigami: the other issue is consistency -- we have to be self-consistent so whatever is done for bu_basename() needs to be done for bu_dirname() too |
| 20:39.37 | brlcad | kunigami: so either both match dirname/basename or both match each other, provide thread safety, but require callers to bu_free() |
| 20:39.49 | bhinesley | starseeker: I started with Cygwin, but ran into build errors. Anyways, once I read that releases are built in Visual Studio, that's what I started using. I just finished building for the first time, and there are some errors. I have yet to see how bad. |
| 20:40.48 | kunigami | wow I didn't think of these issues! ok. I'll keep the interface and add a commentary at bu.h and also perform sanity checks. do we have any such automatic checker, where I could add these tests? |
| 20:42.04 | brlcad | kunigami: what sort of tests? |
| 20:42.05 | starseeker | bhinesley: the cmake branch may be a good bet for building on Windows with Visual C++ |
| 20:42.35 | brlcad | kunigami: bu_dirname() already takes const, returns nonconst, and documents the need for bu_free() so it would be a good example to follow |
| 20:42.59 | brlcad | the issue is just making sure bu_basename() callers are calling bu_free() like bu_dirname() callers are |
| 20:43.31 | bhinesley | starseeker: in the repo? |
| 20:44.32 | kunigami | brlac: hhm nevermind I don't think such sanity checkings could be automated. |
| 20:44.33 | bhinesley | I see it now |
| 20:44.47 | kunigami | brlcad: ok. I'll follow that example |
| 20:45.15 | starseeker | bhinesley: svn co https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/branches/cmake brlcad-cmake |
| 20:46.47 | *** join/#brlcad siddharth_ (~siddharth@117.211.88.150) | |
| 20:47.31 | siddharth_ | brlcad, How to apply for gsoc brlcad? |
| 20:48.17 | brlcad | siddharth_: see http://brlcad.org/wiki/Google_Summer_of_Code/2011 |
| 20:49.25 | starseeker | bhinesley: you'll need cmake (2.8.4 is probably a good idea) and Visual C++ (or Visual Studio should work) |
| 20:49.37 | starseeker | If you want to build the installer you'll also need NSIS |
| 20:50.09 | CIA-52 | BRL-CAD: 03erikgreenwald * r44036 10/geomcore/trunk/src/interfaces/cl/ (. gsclient.asd gsclient.lisp): quick and dirty lithp client |
| 20:50.17 | bhinesley | starseeker: alright, thank you |
| 20:57.20 | *** join/#brlcad Marjo_ (~Marjo@71.141.133.50) | |
| 20:57.46 | starseeker | ``Erik: that's pretty cool, actually |
| 21:04.08 | Marjo_ | Hello, everyone! |
| 21:05.51 | brlcad | hello Marjo_ |
| 21:23.21 | CIA-52 | BRL-CAD: 03brlcad * r44037 10/brlcad/trunk/src/librt/comb/comb.c: check in the order passed |
| 21:26.47 | CIA-52 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2777 10/wiki/MGED_CMD_who: displayed objects |
| 21:38.25 | brlcad | there's a gsoc project I forgot to add .. syncronize wiki pages with doxygen pages ;) |
| 21:39.35 | brlcad | er, docbook |
| 21:40.04 | starseeker | yeah! that's a really good candidate for those interested in web stuff |
| 21:42.54 | Marjo_ | I'm very intersted in the code maintenance project. Filling out a proposal right now. |
| 21:44.04 | brlcad | Marjo_: fantastic, which one? |
| 21:44.30 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2778 10/wiki/Google_Summer_of_Code/Project_Ideas: sync docbook and wiki docs |
| 21:45.06 | Marjo_ | brlcad: I'm very interested with Code Reduction / General Tree Walker / Fixing Bugs under Code Refactoring Projects. |
| 21:45.46 | Marjo_ | I'm only a 2nd year Computer Engineering Undergrad so I'm still a novice. |
| 21:56.13 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2779 10/wiki/Synchronize_Wiki_with_Docbook: initial wikidocbook idea |
| 21:56.21 | brlcad | Marjo_: then code refactoring sounds like a great place to begin |
| 21:56.30 | brlcad | that said, you could have 10 years experience and still be a novice ;) |
| 21:57.33 | brlcad | if experience is limited, I wouldn't necessarily recommend starting with code reduction since that usually entails a lot of careful testing and API design |
| 21:57.36 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 21:57.45 | brlcad | the other two ideas, however, bug fixes and tree walking, are more tangible |
| 21:58.11 | Marjo_ | brlcad: Haha, agreed. I would love to get a small taste of what real-world programming looks like. |
| 21:59.11 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r2780 10/wiki/Main_Page: there is no support, neat showing dead links in red erik |
| 22:00.36 | brlcad | Marjo_: it's mostly about taking things to completion -- proof-of-concept is never enough |
| 22:01.14 | brlcad | docs, testing, performance profiling, tweaking, more docs, more testing |
| 22:02.54 | Marjo_ | brlcad: To test this code, what kind of IDE would you recommend? Is either Microsoft Visual C++ 2010 or Eclipse on Ubuntu a proper IDE? |
| 22:03.17 | brlcad | whatever you're comfortable and productive with is fine |
| 22:03.28 | brlcad | it's worth investing the time and effort to learning how to use one of them well, though |
| 22:03.51 | brlcad | personally, I prefer emacs, eclipse, or vim (in probably that order) |
| 22:04.49 | brlcad | most graphical IDEs are just a crutch, and tend to get in the way more than they help -- learn the underlying concepts first and it won't matter |
| 22:07.56 | brlcad | if you end up not understanding build failures or avoiding looking into compilation failures, then you probably shouldn't be using an IDE yet |
| 22:11.16 | Marjo_ | How would students address code maintenance if they don't see the errors through an IDE? Throughout the duration of my 2 years we've only been using Eclipse and Visual Studio to write code and debug. |
| 22:19.01 | brlcad | Marjo_: your confusion is exactly what I'm referring to :) |
| 22:19.22 | brlcad | the IDE isn't a magical black box, it's making calls and performing operations under the hood |
| 22:20.06 | brlcad | as a young developer, it's critical to learn what those things are otherwise "when things go wrong", deciphering what's going wrong can seem impossible |
| 22:20.14 | brlcad | or worse, lead to cargo cult programming |
| 22:20.45 | Marjo_ | brlcad: OH! I see what you're talking about. Does it basically boil down to white box testing? |
| 22:21.25 | brlcad | you should be able to write and debug software with a simple text editor, a compiler, and a linker .. next learn a decent debugger and you'll be more experienced than most developers |
| 22:22.12 | brlcad | it's not related to white box testing -- it's knowing how your tools work |
| 22:23.53 | Marjo_ | Ahh, my current Data Structures and Algorithms professor touched upon this subject during the beginning of the semester, but she said that is probably too advanced for our class right now. |
| 22:23.54 | brlcad | car analogy: it's like being a car mechanic but not knowing how to use a wrench, avoiding wrenches or even anything with a bolt on it because you've never used a wrench before |
| 22:24.39 | Marjo_ | I wonder why we didn't start out our curriculum by "learning the insides" first... |
| 22:25.09 | brlcad | a power wrench might save time and effort, but damn .. it's just a wrench .. don't fear learning how to use a wrench first ;) |
| 22:26.18 | brlcad | Marjo_: that's because the average CS student is stupid (because the average person is stupid) and they try to not scare people away too quickly, ease them into core concepts |
| 22:26.46 | Marjo_ | Haha, I fully understand. :) |
| 22:26.48 | brlcad | decades of people before you learned the basic tools just fine, you'll do just fine too |
| 22:34.24 | CIA-52 | BRL-CAD: 03brlcad * r44038 10/brlcad/trunk/include/raytrace.h: (log message trimmed) |
| 22:34.24 | CIA-52 | BRL-CAD: yay understanding. document how RT_GET_TREE() and RT_FREE_TREE() are/were |
| 22:34.24 | CIA-52 | BRL-CAD: working. it's basically a linked list that reuses free'd tree items so we never |
| 22:34.24 | CIA-52 | BRL-CAD: allocate more than the largest amount in use at any one time. pretty nifty. |
| 22:34.24 | CIA-52 | BRL-CAD: (allocating in batches might be even better) add a new RT_INIT_TREE macro that |
| 22:34.25 | CIA-52 | BRL-CAD: will initialize a union tree to zero with the magic set, make RT_GET_TREE init |
| 22:34.26 | CIA-52 | BRL-CAD: every tree returned so callers never have to deal with the magic number |
| 22:35.13 | CIA-52 | BRL-CAD: 03brlcad * r44039 10/brlcad/trunk/src/librt/ (comb/db_comb.c db_tree.c tree.c): now that RT_GET_TREE initializes, we don't need to manually set RT_TREE_MAGIC any more. should also help guarantee that reused tree nodes have zero'd memory. |
| 22:37.39 | Marjo_ | Wow, thank you for the inspiration. I will still apply for the project so that I can learn of the different ways to program. |
| 22:45.58 | adityag | brlcad: is it cool if i have not submitted patches in BRL-CAD ? . i have submited a few patches in drupal. will that help ? |
| 22:49.51 | brlcad | Marjo_: great, look forward to seeing your application |
| 22:50.52 | brlcad | again, you can use whatever you like |
| 22:50.54 | brlcad | we'll only push you towards specific tools if you're taking too long |
| 22:51.08 | brlcad | the tool is just a tool, better to obsess over code than over the tools :) |
| 22:51.19 | brlcad | adityag: are you serious? :) |
| 22:53.25 | brlcad | "is it cool if I didn't do the assignment for your class ? . i did the assignment for another class. will that help ?" |
| 22:53.28 | brlcad | you tell me ;) |
| 22:55.04 | adityag | <PROTECTED> |
| 23:01.20 | brlcad | a patch isn't technically "required", so you should submit your application with or without it regardless (you can attach a link to the patch later) |
| 23:01.48 | brlcad | but trying to pawn off work for another org isn't cool or useful, the point is seeing how you deal with our code |
| 23:04.37 | CIA-52 | BRL-CAD: 03brlcad * r44040 10/brlcad/trunk/src/librt/ (4 files in 3 dirs): no longer need to set RT_TREE_MAGIC now that RT_GET_TREE() sets it. |
| 23:05.57 | CIA-52 | BRL-CAD: 03brlcad * r44041 10/brlcad/trunk/src/libged/ (8 files): no longer need to set RT_TREE_MAGIC in here too now that RT_GET_TREE() sets the magic. |
| 23:09.22 | adityag | brlcad: yeah cool. |
| 23:17.00 | CIA-52 | BRL-CAD: 03brlcad * r44042 10/brlcad/trunk/src/libged/red.c: functions that use zero for success result in reverse boolean expressions. less error-prone to explicitly test for zero. go a step further and document intent with matched/no match labels. |
| 23:21.10 | CIA-52 | BRL-CAD: 03brlcad * r44043 10/brlcad/trunk/src/libged/red.c: aha, source of the errant space. auto-formatting sees the ){ and wants to clean up the formatting. break up the string. |
| 23:57.09 | starseeker | brlcad: nice. I didn't realize you could feed two separate strings into the printf logic like that |
| 23:58.01 | adityag | brlcad: Im interested in these project ideas : Code Reduction, Fix Bugs, Benchmark Performance Database. Can i submit multiple applications ? |
| 00:02.52 | brlcad | adityag: you sure can |
| 00:03.08 | brlcad | you can submit up to 20 apps total to any number of orgs |
| 00:03.22 | brlcad | I don't recommend submitting more than three |
| 00:03.32 | brlcad | focus on quality, not quantity |
| 00:03.53 | adityag | ok cool thanks |
| 00:03.55 | brlcad | better to have two really good applications with a strong patch than four crappy applications with a crappy patch ;) |
| 00:05.16 | brlcad | starseeker: *nod* all string literals are equivalent to the concatenation of them broken up like that |
| 00:05.48 | brlcad | so you can't use it to get over the 509 char limit in C90, but it is useful if you need to inject comments or assist with layout |
| 00:07.33 | CIA-52 | BRL-CAD: 03starseeker * r44044 10/brlcad/trunk/src/libged/red.c: Rename to avoid confusion - the point of that regex is to look for anything except whitespace, not whitespace. |
| 00:13.02 | starseeker | please please please let this be the last of the showstopper red bugs... |
| 00:15.31 | brlcad | i'm still chasing the logic through for how it was causing that crash in the first place |
| 00:15.59 | brlcad | for my trace, it was deep in libbn checking if a mat is identity .. so it was bogus memory |
| 00:16.06 | brlcad | hopefully the zero-init will make that not happen |
| 00:16.50 | starseeker | nods |
| 00:17.08 | starseeker | maybe that would explain why the different crash on 10.6 vs. 10.5? |
| 00:19.26 | brlcad | sure, it's just random memory |
| 00:19.38 | brlcad | something is wrong with the tree structure |
| 00:19.50 | brlcad | i'm guessing that the regex fails to parse a matrix, so it never sets the matrix |
| 00:19.58 | brlcad | then gets to code that attempts to validate the matrix |
| 00:20.10 | brlcad | and boom |
| 00:20.38 | brlcad | but you could also get a boom from any of the other fields too, or the tree structure might happen to be a valid previous tree node and you'd get further, etc |
| 00:22.18 | brlcad | so far, though, I don't see how we've actually fixed a bug yet other than you finding the space in the regex |
| 00:25.38 | starseeker | one if the if statements was backwards too |
| 00:25.57 | starseeker | but yeah, neither of those seem to relate directly to that weird issue |
| 00:28.40 | brlcad | it wasn't though, the return statements was swapped |
| 00:28.47 | brlcad | unless it was wrong before all of this too |
| 00:28.57 | brlcad | http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/libged/red.c?r1=43830&r2=43832&pathrev=43832 flipped them |
| 00:34.18 | CIA-52 | BRL-CAD: 03brlcad * r44045 10/brlcad/trunk/src/ (30 files in 12 dirs): consistently call BU_GETUNION() to allocate a new union tree node and RT_INIT_TREE() to initialize that node instead of setting the magic value directly. |
| 00:36.20 | brlcad | okay, now to rebuild and see if that makes any difference whatsoever |
| 00:52.05 | starseeker | brlcad: oh, I was referring to a different one - I think it was wrong to start with |
| 00:54.46 | brlcad | starseeker: so recap, you can't change the name during red right? |
| 00:57.57 | brlcad | also, matrix edits during red are not working in my testing, they get ignored |
| 00:58.34 | brlcad | good/bad news, though .. can't get it to crash |
| 01:00.49 | CIA-52 | BRL-CAD: 03brlcad * r44046 10/brlcad/trunk/TODO: keep seems to be working, red is no longer crashing but isn't editing matrices either |
| 01:01.03 | brlcad | at least, keep tested clean on linux |
| 01:09.08 | *** join/#brlcad yukonbob (~bch@S0106002129e399fc.ok.shawcable.net) | |
| 01:09.18 | yukonbob | hello, #brlcad |
| 01:11.02 | *** join/#brlcad crazy_imp (~mj@a89-182-208-48.net-htp.de) | |
| 01:27.03 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 01:57.29 | brlcad | howdy yukonbob |
| 01:57.54 | brlcad | starseeker: just noticed that your crash report was on the same tree node member, the matrix |
| 01:58.10 | brlcad | so undoubtedly related to setting it during red |
| 02:09.48 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601295.dsl.bell.ca) | |
| 02:26.28 | CIA-52 | BRL-CAD: 03brlcad * r44047 10/brlcad/trunk/src/libbu/stat.c: |
| 02:26.28 | CIA-52 | BRL-CAD: treat empty strings the same as null, i.e., a special case similar to NaN |
| 02:26.28 | CIA-52 | BRL-CAD: implying not a file so never will match true even if stat() might. similarly, |
| 02:26.28 | CIA-52 | BRL-CAD: for comparing to files, empty strings should never match. (two empty string |
| 02:26.29 | CIA-52 | BRL-CAD: filenames are not the same file, they are no file). |
| 02:29.38 | starseeker | brlcad: that's very odd - I was able to edit a matrix earlier today... |
| 02:30.17 | starseeker | yeah, logic for name change isn't present yet |
| 02:30.30 | CIA-52 | BRL-CAD: 03brlcad * r44048 10/brlcad/trunk/include/bu.h: document the behavior on empty strings |
| 02:31.25 | brlcad | k |
| 02:31.36 | CIA-52 | BRL-CAD: 03brlcad * r44049 10/brlcad/trunk/src/libged/red.c: |
| 02:31.38 | CIA-52 | BRL-CAD: another attempt at a logic cleanup, this time consolidating the memory cleanup |
| 02:31.38 | CIA-52 | BRL-CAD: and unlinking of the temp file to one place so that the file is consistently |
| 02:31.38 | CIA-52 | BRL-CAD: closed. some conditions weren't closing the file. this only modifies ged_red() |
| 02:31.38 | CIA-52 | BRL-CAD: and shouldn't be a change to flow logic. |
| 02:34.12 | starseeker | unfortunately, something about the ged string handling results in the error messages from ged_red getting squashed |
| 02:34.27 | starseeker | I recall Bob saying something about why that was once, but I don't recall |
| 02:34.59 | brlcad | all part of the refactoring suck |
| 02:35.10 | brlcad | some ged functions reset the result string, some don't |
| 02:35.23 | brlcad | so if you have a ged func that calls another ged func, it may or may not reset the result |
| 02:35.30 | starseeker | ah |
| 02:35.45 | brlcad | if the clean refactoring was complete, there'd be no need to reset the result in any func |
| 02:36.13 | brlcad | except the one top-level wrapper executing the main command |
| 02:36.32 | brlcad | if even then, could be a result array |
| 02:39.29 | CIA-52 | BRL-CAD: 03starseeker * r44050 10/brlcad/branches/cmake/ (46 files in 19 dirs): MFC r44049 |
| 02:39.42 | brlcad | starseeker: another curiosity, I edited a region with red and it listed rgb and color as an attribute |
| 02:39.55 | starseeker | both of them? |
| 02:39.57 | brlcad | looking at the logic in write_comb(), that shouldn't be possible since it's a standard attribute |
| 02:40.01 | brlcad | yep |
| 02:40.08 | starseeker | growl... |
| 02:40.34 | starseeker | it might be doing that if a pre-existing region has both... I don't recall |
| 02:41.02 | brlcad | fwiw, it was havoc, rt_r.pyl1 |
| 02:41.41 | brlcad | attr show only lists rgb |
| 02:42.25 | starseeker | if it's pulling color from the comb struct and rgb from attributes that MIGHT do it |
| 02:42.29 | starseeker | more likely I screwed up |
| 02:42.55 | brlcad | looks like write_comb() doesn't look at the struct members |
| 02:43.35 | starseeker | it's probably in the standardization routines then |
| 02:46.15 | brlcad | curious that you manually list the standard attributes just to get the max length for pretty printing |
| 02:47.38 | starseeker | brlcad: those routines are certainly candidates for improvement |
| 02:49.22 | brlcad | if I'm reading the correctly, it looks like it may even potentially update a read-only database |
| 02:49.44 | starseeker | winces |
| 02:50.02 | brlcad | ah, it'll try but then get bitched at lower-level by librt |
| 02:50.16 | brlcad | still.. the in-mem is modified |
| 03:01.40 | CIA-52 | BRL-CAD: 03brlcad * r44051 10/brlcad/trunk/TODO: note a few of the red issues remaining |
| 03:04.32 | CIA-52 | BRL-CAD: 03brlcad * r44052 10/brlcad/trunk/src/libged/ (ged_private.h put_comb.c): delims is only used in put_comb.c so it doesn't need to be an extern'd global. same for ged_tmpcomb. |
| 03:05.49 | CIA-52 | BRL-CAD: 03brlcad * r44053 10/brlcad/trunk/src/libged/red.c: |
| 03:05.49 | CIA-52 | BRL-CAD: delims was moved to put_comb, not used here. refactor the Combination Tree |
| 03:05.49 | CIA-52 | BRL-CAD: separator so it's only in one place. put the matching regexp up next to it so |
| 03:05.49 | CIA-52 | BRL-CAD: changes to one can be reflected in the other, otherwise will be brittle to |
| 03:05.49 | CIA-52 | BRL-CAD: future edits. |
| 03:07.12 | CIA-52 | BRL-CAD: 03brlcad * r44054 10/brlcad/trunk/src/libged/red.c: if the regex is going to have the newline, make the separator have it too |
| 03:30.12 | CIA-52 | BRL-CAD: 03brlcad * r44055 10/brlcad/trunk/src/libged/red.c: ouch. write_comb() needs a rewrite. it's modifying data it should not be modifying at this point in our processing. just asking for trouble. |
| 03:42.08 | CIA-52 | BRL-CAD: 03brlcad * r44056 10/brlcad/trunk/NEWS: with r44022, richard fixed two memory management issues introduced during a code audit that reduced the size of an allocation after a conversion from bu_malloc to bu_calloc as well as double-free on exit. |
| 03:47.24 | CIA-52 | BRL-CAD: 03brlcad * r44057 10/geomcore/trunk/src/GS/FileDataSource.cxx: if one iterator needs it, don't they both? |
| 04:00.46 | CIA-52 | BRL-CAD: 03brlcad * r44058 10/geomcore/trunk/src/GS/ (25 files in 2 dirs): attack of ws indent format consistency. remove useless header metadata. |
| 05:26.37 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 05:41.45 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 06:16.51 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 06:18.19 | *** join/#brlcad siddharth__ (~siddharth@117.211.88.150) | |
| 06:33.05 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:00.27 | *** join/#brlcad siddharth_ (~siddharth@117.211.88.150) | |
| 07:07.53 | *** join/#brlcad siddharth__ (~siddharth@117.211.88.150) | |
| 08:51.39 | *** join/#brlcad pawleeq (~pavel@pc119.iabrno.cz) | |
| 10:21.28 | *** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194) | |
| 10:58.10 | dloman | Merin all |
| 11:10.05 | *** join/#brlcad siddharth__ (~siddharth@117.211.88.150) | |
| 11:21.04 | dloman | brlcad: Is there some 'good coding practice' that I am unaware of coming to play at FileDataSource.cxx:53 ? Why do we need to incr the iterator if its not going to be used again? |
| 11:28.10 | *** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194) | |
| 11:34.37 | CIA-52 | BRL-CAD: 03davidloman * r44059 10/geomcore/trunk/ (include/Portal.h src/libNet/Portal.cxx): Add convenience method for sending a typeonly msg to client. |
| 11:38.14 | CIA-52 | BRL-CAD: 03davidloman * r44060 10/geomcore/trunk/ (include/DataManager.h src/GS/DataManager.cxx): Stub in BRLCAD::Object <-> GeometryChunkMsg functions. Simplfy Msg handling by using new Portal::sendTypeOnly() method. |
| 12:23.17 | brlcad | dloman: not really, only if someone came to that block later and turned it into a loop |
| 12:27.43 | brlcad | I presume that function is incomplete in some fashion? |
| 12:27.43 | CIA-52 | BRL-CAD: 03brlcad * r44061 10/geomcore/trunk/src/GS/FileDataSource.cxx: not a loop, no need to increment. odd pulling first 'top' object though. |
| 12:27.58 | *** join/#brlcad Elrohir (~kvirc@p5B14A416.dip.t-dialin.net) | |
| 12:33.11 | dloman | brlcad: just the way the core interfaces are setup leads to the only real way to arbitrarily get top objects is via an iterator and the only way to get the iterator is to use the TopObjectIterator() |
| 12:33.39 | dloman | when i have the time, i plan on expanding the ConstDatabase/Database/MemoryDatabase functionality. |
| 12:34.40 | dloman | getObj() assumes you only want 1 object, and that's because in our design, many of the .g files in the repo are going to only have 1 object. |
| 12:37.10 | dloman | FFA question: If i want to use memcpy to copy to a char*, but start at the 5th char into the array, can i word it like: memcpy(dest+4,src,length) ? |
| 12:38.32 | brlcad | I saw getObj as give me any object from a .g, not necessarily a top object |
| 12:39.26 | brlcad | and yes re. memcpy |
| 12:41.08 | dloman | the coreInterface classes don't allow you to directly get an object with out knowing its (string) name, and there is no way to get that name unless you iterate, starting at the top. |
| 12:42.09 | dloman | tree walking to build an array of Objects hasn't been implemented yet, but thats ultimately what getObjs will do. |
| 12:42.17 | brlcad | sure, that's the same with librt too |
| 12:42.20 | dloman | likely get to that today. |
| 12:42.30 | brlcad | that getObj() routine sounds like a routine to get a specific named object |
| 12:43.40 | dloman | the fn documentation will come soon, no worries. |
| 12:43.43 | brlcad | so if it has the name, there should be no involvement of TopObjectIterator() |
| 12:44.43 | brlcad | heh, so fix the problem by changing the function definition? .. the name alone implied that (which is a good thing) |
| 12:46.29 | dloman | dude, its a name. can be changed at any time. small potatoes at this point, especially when everything isn't solidified quite yet. |
| 12:47.47 | brlcad | of course, that's expected |
| 12:47.53 | brlcad | just looking for clarification |
| 12:48.31 | brlcad | trying to work on the code too, and if that's not a function that gets an object by name, then that obviously changes things |
| 12:49.42 | brlcad | if it is supposed to get an object by name, which is what seemed the more plausible (and useful) .. then the implementation didn't seem right |
| 12:50.06 | dloman | getObj() gets the single object at the repo 'path' |
| 12:50.21 | dloman | getObjs() gets multiple object at the repo 'path' |
| 12:51.10 | dloman | after implementing things now, it seems the use of getObj is nearly nothing, since getObjs can perform the same funciton by returning a list with one element. |
| 12:51.22 | brlcad | nods |
| 12:51.29 | brlcad | okay, that makes more sense then |
| 12:51.34 | dloman | performance and memory wise i am sure they are different. |
| 12:51.38 | brlcad | meh |
| 12:51.44 | dloman | but im just going to leave them both for now |
| 12:52.15 | brlcad | seems error prone to allow a getObj when there may be more than one object to randomly be given "the first one" |
| 12:53.59 | dloman | exactly why im thinking its going to go away soon, provided some profound reason to keep it. |
| 12:54.58 | brlcad | now a general getObj() that returns a specific object by name would be more useful |
| 12:55.16 | brlcad | but that gets into what you've named a path there and how that differs from a geometry path |
| 12:55.51 | brlcad | something to talk about later perhaps |
| 13:22.15 | CIA-52 | BRL-CAD: 03brlcad * r44062 10/brlcad/trunk/src/librt/db5_types.c: |
| 13:22.15 | CIA-52 | BRL-CAD: add a new routine that will return a standard attribute name by an index number, |
| 13:22.15 | CIA-52 | BRL-CAD: so that we have a way to iterate over all the standard attribute names. this |
| 13:22.15 | CIA-52 | BRL-CAD: simplifies db5_is_standard_attribut() iteration and lets us reuse the iteration |
| 13:22.15 | CIA-52 | BRL-CAD: elsewhere. |
| 13:27.37 | CIA-52 | BRL-CAD: 03brlcad * r44063 10/brlcad/trunk/src/librt/db5_types.c: swap los and air so that the index coincidentally matches the ATTR_* returned from db5_standardize_attribute() |
| 13:31.49 | dloman | d_rossberg: are you around? |
| 13:34.42 | CIA-52 | BRL-CAD: 03brlcad * r44064 10/brlcad/trunk/src/librt/db5_types.c: even better, make the index-based lookup exactly match the ATTR_* index value. convert to an enum for proper numeric indexing. |
| 13:38.18 | CIA-52 | BRL-CAD: 03brlcad * r44065 10/brlcad/trunk/src/librt/db5_types.c: document the need for these needing to not have gaps in their value. only specify the starting point to make is less error prone. add null case so gcc thinks we're covering all our bases. |
| 13:50.36 | CIA-52 | BRL-CAD: 03brlcad * r44066 10/brlcad/trunk/src/librt/db5_types.c: simplify db5_standardize_attribute() by unrolling the loops. we have to perform all the comparisons anyways until we get a match, so just list them. |
| 13:54.48 | dloman | d_rossberg: I'm having an issue with a Database.Get() call. |
| 13:55.34 | dloman | whenever i get an Object using .Get(), the object's internal db_i* and diectory* are NULL. |
| 13:56.11 | CIA-52 | BRL-CAD: 03brlcad * r44067 10/brlcad/trunk/src/librt/db5_types.c: shorten to attr |
| 13:58.37 | dloman | ConstDatabase::Get(char*)->ConstDatabase::get(char* ObjectCallback)->ObjectCallbackIntern::operator()->Arb8::Clone()->Arb8::Arb8->Object::Object->Object::Copy() |
| 13:58.41 | dloman | thats the stack trace |
| 13:59.20 | dloman | I don't ever see the m_dbip, m_pDir, or m_ip get copied. |
| 13:59.24 | dloman | ...is that by design? |
| 14:01.18 | brlcad | starseeker: can you help? what is db5_standardize_avs() supposed to do? I don't understand the comment |
| 14:01.57 | starseeker | brlcad: one sec... |
| 14:03.47 | CIA-52 | BRL-CAD: 03starseeker * r44068 10/brlcad/branches/cmake/ (6 files in 3 dirs): MFC r44067 |
| 14:04.17 | starseeker | hrm... yeah, looks like brain backfired on that comment |
| 14:04.21 | starseeker | checks code... |
| 14:05.20 | starseeker | OK, I think this was the thinking... |
| 14:05.30 | brlcad | see if that says it |
| 14:05.34 | CIA-52 | BRL-CAD: 03brlcad * r44069 10/brlcad/trunk/src/librt/db5_types.c: update comment for db5_standardize_avs(). is my understanding correct? |
| 14:06.14 | starseeker | yeah, that's pretty much it |
| 14:06.41 | starseeker | I think it might remove the old attribute that it's replacing with the new one, but will leave additional matches alone |
| 14:06.45 | starseeker | let me check that though |
| 14:07.08 | brlcad | yeah, I was thinking it should remove all the matches |
| 14:07.25 | starseeker | the problem with that is if an existing comb has both color and rgb |
| 14:07.29 | starseeker | with different values |
| 14:07.41 | brlcad | sure, but what does that mean? |
| 14:08.06 | starseeker | who knows? but picking one means destroying one of the color settings, if we erase both of the old ones |
| 14:08.41 | starseeker | yesh, looks like that one isn't doing any erasing |
| 14:08.47 | starseeker | so your comment is right |
| 14:08.50 | brlcad | okay,that's cool |
| 14:09.05 | brlcad | i'd think we'd either wipe them all out with the new or leave them all intact and add new |
| 14:09.30 | brlcad | we don't know what that data is but technically "we own it" because it's in the reserved namespace |
| 14:09.37 | starseeker | nods - that MIGHT be why you were seeing multiple color settings on that havoc region... |
| 14:09.51 | brlcad | possibly |
| 14:10.12 | brlcad | though later in red, you go through the whole update/apply thing that should have consolidated |
| 14:10.17 | brlcad | maybe |
| 14:10.28 | brlcad | hello hyarion |
| 14:10.57 | hyarion | hi |
| 14:11.52 | d_rossberg | dloman: see the docu of Get() in ConstDatabase.h: this method returns a copy of the object |
| 14:12.09 | dloman | the copy is disconnected from any database then? |
| 14:12.15 | dloman | ...by design? |
| 14:12.18 | d_rossberg | this seams to be a good idea because you close the database after each operation ;) |
| 14:13.02 | dloman | righto, that part is sensible. |
| 14:13.26 | dloman | just want to make sure I'm understanding your code correctly. |
| 14:14.48 | d_rossberg | the deeper reason is the following: |
| 14:16.27 | d_rossberg | rt_db_get_internal() (as used in the Get()) always gives you a copy of the database object on a rt_db_internal structure |
| 14:17.39 | d_rossberg | therefore you have to carefully choose the moment when to write back rt_db_internal into the database |
| 14:17.49 | starseeker | brlcad: yeah, it looks like what's happening is db5_update_std_attributes is ensuring that all of the standard attributes correspond to the comb structure values - in the process, it's creating any that aren't already there (like color in the case of rt_r.pyl1) |
| 14:18.47 | d_rossberg | i'm doing it usually when the callback returns (see the callback version of Get()) |
| 14:19.21 | d_rossberg | i.e. the non-const Get() in Database.h |
| 14:19.32 | starseeker | but since I was trying to go with the "don't destroy information" policy, rgb got left |
| 14:20.46 | brlcad | that's great |
| 14:21.04 | brlcad | defaulting to don't destroy is always right :) |
| 14:21.20 | d_rossberg | another possibility is to take a copy of the Object explicitely (as you did) and leave it to the user to write it back to the database with Set() |
| 14:21.41 | starseeker | also, I don't think db5_apply_std_attributes will remove excess extra settings... |
| 14:21.48 | starseeker | so that part of the comment may need updating |
| 14:21.53 | brlcad | k |
| 14:22.17 | starseeker | we can make a function to do that, but I'd prefer it to be a separate call so the decision to possibly destroy data is isolated |
| 14:22.17 | brlcad | i'm simplifying standardize_avs() a bit now, given there's a function that will return the name by type |
| 14:22.23 | starseeker | cool |
| 14:22.35 | brlcad | reduces almost all of the cases to just add |
| 14:22.47 | d_rossberg | or for short: Object is the C++ form of rt_db_internal which contains a copy of an database element |
| 14:23.06 | starseeker | now remember why that took so long... lots of annoying little questions to sort out... |
| 14:23.37 | *** join/#brlcad Stattrav (~Stattrav@117.192.156.60) | |
| 14:23.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:23.59 | dloman | d_rossberg: awesome, thanks man. I figured out that in order to properly extract a bu_external from an Object, i should use an ObjectCallback |
| 14:24.34 | starseeker | brlcad: probably the correct thing to do is if there is just one color attribute (e.g. rgb) it should get renamed |
| 14:24.40 | starseeker | so that may be a bug |
| 14:25.04 | brlcad | hm |
| 14:25.19 | starseeker | I thought I had some "first hit for type T" logic that would rename, but maybe I took it out as too complicated in the inital cut |
| 14:25.32 | brlcad | it's half in there :) |
| 14:25.37 | brlcad | some of the types don't use it |
| 14:25.50 | starseeker | ah, crud |
| 14:26.02 | d_rossberg | dloman: btw: Object has full attribute support including iteration |
| 14:26.44 | starseeker | we can get fancier by checking the value of subsequent hits of the same type against the stored standard type, and only keep them (and display them) if they're different |
| 14:27.05 | brlcad | still, I see this as an in-memory "upgrade my avs" routine .. so it can convert any it finds, consolidate any that are the same value, and otherwise rename the first to standard form |
| 14:27.06 | starseeker | that's probably the best case - preserve and display conflicting data if it actually conflicts, otherwise standardize |
| 14:27.22 | starseeker | er, yeah :-) |
| 14:33.24 | brlcad | had a memory leak in there bu_avs_add() already copies the value for you |
| 14:33.49 | starseeker | ah |
| 14:34.02 | CIA-52 | BRL-CAD: 03starseeker * r44070 10/brlcad/trunk/include/raytrace.h: Update db5_is_standard_attribute in raytrace.h |
| 14:39.13 | CIA-52 | BRL-CAD: 03starseeker * r44071 10/brlcad/trunk/src/libged/red.c: fix red.c extern too |
| 14:40.29 | d_rossberg | dloman: ps: this way you can copy an Object from one database to another: Get() from the first one and Add() to the other one |
| 14:40.53 | dloman | excellent |
| 14:41.14 | dloman | I am actually looking to properly create a bu_external, which requires a valid db_i* and directory* |
| 14:41.59 | brlcad | dloman: only that one routine required a db_i, there are other routines that work with data in other stages of the i/o process |
| 14:42.13 | brlcad | might be something else that can be used |
| 14:42.33 | brlcad | looks |
| 14:45.38 | brlcad | what data do you have now? |
| 14:45.47 | brlcad | an rt_db_internal *? |
| 14:47.08 | dloman | well, if hook into ab Object before it gets .Clone()-ed, then i will have everything (db_i, rt_db_internal*, resource* and directory*) |
| 14:47.16 | dloman | otherwise, i have none of those. |
| 14:47.46 | brlcad | none? if it made a copy, you ahve at least the rt_db_internal I'd think |
| 14:48.00 | d_rossberg | dloman: for low level operations you should consider to use the C API directly, the C++ interface is definitely not the place for such tasks |
| 14:49.10 | d_rossberg | no, he has nothing because the database will be closed after getting the object |
| 14:49.30 | brlcad | d_rossberg: we could still encapsulate serialization as something inherent to an Object, a Serialize() routine that returns a bu_external for example |
| 14:50.17 | brlcad | d_rossberg: then how'd it 'get' the object? extracts values into private member data from the db_intern? |
| 14:52.25 | d_rossberg | it has a private char* for the name, bu_attribute_value_set for the attributes and rt_~_internal for the element specific stuff |
| 14:53.10 | brlcad | ah, so it fully uncracks the rt_db_internal |
| 14:53.19 | d_rossberg | and serialization isn't trivial, it depends on the protocol used and purpose |
| 14:53.51 | d_rossberg | e.g. i would prefer a serialization in xml |
| 14:54.10 | brlcad | heh |
| 14:54.36 | d_rossberg | or with other words: this is something for the level above the core interface |
| 14:55.34 | brlcad | and/or below it |
| 14:56.24 | brlcad | i could still see it providing some default serialization capability that it could use for persistence and reconstruction |
| 14:56.26 | d_rossberg | for the network my first idea would be to use something like corba |
| 14:57.13 | brlcad | but that's so much overhead ... |
| 14:57.45 | brlcad | and nobody likes writing corba code :) |
| 14:58.00 | d_rossberg | this point is on you :) |
| 14:58.01 | brlcad | except businesses that are paid/forced to :) |
| 14:59.15 | *** join/#brlcad Elrohir (~kvirc@p5B14A416.dip.t-dialin.net) | |
| 15:01.27 | dloman | who knew the Dune soundtrack makes cood coding music..... |
| 15:02.18 | d_rossberg | however, the "default serialization" should >mainly< (whatever this will mean) be database independend because it is used in an abstraction layer |
| 15:03.21 | brlcad | yeah, I'd think you'd want it to be a black box serialization |
| 15:04.11 | brlcad | either to a generic form (like xml, shudder!) or to an opaque type that you aren't supposed to inspect beyond passing to a Deserialize() call |
| 15:04.47 | brlcad | I was thinking more the latter and just ganging up on the existing serialization routines used for disk since they're compact and really fast |
| 15:05.29 | starseeker | yeah... I thought the external disk format was a serialization - is there some situation where that's not appropriate? |
| 15:05.45 | starseeker | xml I can see only as an archival ascii format (maybe)\ |
| 15:05.54 | brlcad | starseeker: it's "not appropriate" if you don't want to deal with binary data :) |
| 15:06.06 | starseeker | ah heh |
| 15:06.20 | brlcad | or want to pass it through some other parsing engine |
| 15:06.49 | brlcad | converting to asc is technically a serialization too, just a not very interesting one |
| 15:07.42 | d_rossberg | it is the most interesting one: ican read it |
| 15:08.02 | brlcad | how about json then? even easier to read ;) |
| 15:08.14 | brlcad | and less verbose |
| 15:08.18 | d_rossberg | json who? |
| 15:08.20 | brlcad | runs and hides |
| 15:08.40 | dloman | should I call BU_INIT_EXTERNAL on a bu_external prior to passing the bu_external into db_get_external(..) ? |
| 15:09.16 | d_rossberg | wasn't there a windows ini-file format? |
| 15:09.53 | brlcad | dloman: not necessary |
| 15:10.11 | brlcad | d_rossberg: heh, now you're just talking crazy ;) |
| 15:10.50 | brlcad | that's about as bad as a self-unarchiving shell script |
| 15:12.44 | starseeker | d_rossberg: http://www.json.org/ |
| 15:13.33 | starseeker | http://oss.metaparadigm.com/json-c/ would probably be useful |
| 15:13.46 | brlcad | I think he was being facetious |
| 15:13.52 | starseeker | ah |
| 15:19.27 | starseeker | brlcad: fwiw, a comb with only one entry and a matrix on that entry DOES allow me to save the change |
| 15:19.44 | starseeker | it's where there are multiple entries in the comb tree with matricies that I can confirm the failure |
| 15:19.52 | brlcad | okay |
| 15:23.12 | dloman | anyone familiar with a Segfault dealing with _dl_fixup() in /lib64/ls-linux-x86-64.so.2 ? |
| 15:29.12 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 15:29.26 | brlcad | er... ld is trying to dynamically load something and it can't? |
| 15:29.39 | brlcad | shouldn't be any dynamic loading that I know if |
| 15:30.05 | dloman | i hate this crap :/ |
| 15:30.35 | brlcad | what'd you change that got you into that state? |
| 15:31.03 | brlcad | just back up to the previous commit, work forward in smaller steps |
| 15:31.13 | dloman | i literally copy/pasted a class, changed the guts of one function. |
| 15:32.59 | brlcad | are you using run-time type inference? |
| 15:33.06 | brlcad | in that class |
| 15:34.30 | dloman | i don't think i am |
| 15:34.57 | dloman | noob question: is subclassing considered type inferencing? |
| 15:35.30 | brlcad | then it "probably" was more than a simple copy/paste change, even if that's all you may have intended .. |
| 15:35.57 | brlcad | in general no, but subclassing a class that uses rtti might get you into trouble |
| 15:35.58 | dloman | heh, obviously something got messed up. :/ |
| 15:36.58 | brlcad | without sitting at a debug console, "back it up" is probably the easiest debug route to see where you went wrong |
| 15:37.33 | dloman | i've got it isolated down to a function call, but it doesnt make sense atm. still trying to figger it out. |
| 15:37.44 | brlcad | that error sounds like the dynamic linker saying "I can't find a class I'm told to use" |
| 15:39.45 | dloman | hrm, if I comment out the call to db_get_external(), everything works ..... |
| 15:40.13 | brlcad | are you linking librt? |
| 15:40.46 | brlcad | could be a bonefide crash due to bad data or bug and the _dl_fixup is just a red herring |
| 15:48.33 | brlcad | starseeker: I think I see how the attibute got double-listed |
| 15:48.55 | brlcad | rewriting db5_standarize_avs() is pretty tricky with all of the various cases |
| 16:05.25 | dloman | so its not a linker issue... i'm linking ALL of brlcad libraries. |
| 16:05.46 | dloman | but _dl_fixup is throwing the segfault, according to gdb |
| 16:11.41 | dloman | brlcad: you still around? |
| 16:14.35 | brlcad | yep |
| 16:15.00 | brlcad | where's it segfaulting, what's the rest of the stack? |
| 16:15.04 | dloman | Pro tip: Turns out that bu_malloc is handy for allocating memory for pointers. |
| 16:15.09 | dloman | just fyi |
| 16:15.14 | dloman | facepalms |
| 16:15.24 | brlcad | haha |
| 16:15.33 | brlcad | bu_calloc() is even better |
| 16:15.43 | dloman | yeah, whats the diffference? |
| 16:15.48 | brlcad | zeros the memory |
| 16:16.10 | dloman | costs a bit more cpu time? |
| 16:16.15 | brlcad | malloc will allocate you a memory buffer, but there could be any random garbage in that buffer |
| 16:16.28 | brlcad | insignificant |
| 16:16.49 | dloman | so there really is no reason to ever use anything other than calloc? |
| 16:16.53 | brlcad | the system call itself is two orders more expensive, so might as well spend one or two clock cycles and have fresh zero'd memory |
| 16:17.31 | brlcad | well, if the very first thing I was going to do with the memory was clear it or set it, then bu_malloc makes sense |
| 16:18.01 | brlcad | but talking full-allocation set, which doesn't happen very often |
| 16:19.30 | brlcad | basically, if you want to be a little more cautious and avoid some obscure bugs, use bu_calloc() until you know better :) |
| 16:20.00 | brlcad | it's never "wrong", it just might be unnecessary |
| 16:20.04 | dloman | bugs like me, thus i like calloc |
| 16:20.31 | brlcad | it's like initializing all your variables when you declare them |
| 16:20.38 | dloman | right on |
| 16:20.39 | brlcad | I tend to init to zero and/or NULL |
| 16:20.52 | brlcad | but if the very next thing I'm going to do with them is set their value, it was pointless |
| 16:21.19 | brlcad | if I don't set their value until later down in the function, it might actually save my butt some day to init them |
| 16:21.29 | brlcad | it might save me down the road anyways if I just init them |
| 16:22.15 | brlcad | starseeker: if you care to double-check my logic on this, I think I have it |
| 16:24.12 | CIA-52 | BRL-CAD: 03davidloman * r44072 10/rt^3/trunk/ (4 files in 2 dirs): Added the ability to get a bu_external* from a ConstDatabase and Object. Needed for serialization |
| 16:25.42 | CIA-52 | BRL-CAD: 03brlcad * r44073 10/brlcad/trunk/ (include/raytrace.h src/librt/db5_types.c): |
| 16:25.42 | CIA-52 | BRL-CAD: document the db5_standard* functions, pulling comments from source to header and |
| 16:25.42 | CIA-52 | BRL-CAD: expanding with a note that they're new/private. reimplement |
| 16:25.42 | CIA-52 | BRL-CAD: db5_standardize_avs() using simple two-pass logic so standard attributes take |
| 16:25.42 | CIA-52 | BRL-CAD: precedence. use db5_standard_attribute() in conjunction with |
| 16:25.42 | CIA-52 | BRL-CAD: db5_standardize_attribute() in leu of tables so we don't have to repeat any |
| 16:25.43 | CIA-52 | BRL-CAD: values or even be aware of what is standard or not. |
| 16:25.47 | brlcad | that should prevent the double-listing |
| 16:46.50 | *** join/#brlcad Stattrav (~Stattrav@117.192.156.60) | |
| 16:46.50 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:15.22 | starseeker | brlcad: looks good |
| 17:25.02 | CIA-52 | BRL-CAD: 03davidloman * r44074 10/geomcore/trunk/ (7 files in 4 dirs): Clean up a few bugs in ByteArray. Added ByteArray copy cstr. Converted GenericMultibyteMsg and GeometryChunk to use ByteArray objects (since they are thin wrappers around bu_vls) |
| 17:26.32 | CIA-52 | BRL-CAD: 03starseeker * r44075 10/brlcad/trunk/src/libged/red.c: Looks like this might be the culprit - combtree_op_regex with blank seems to work for matricies |
| 17:27.04 | starseeker | brlcad: does that let you edit matricies? |
| 17:43.19 | CIA-52 | BRL-CAD: 03erikgreenwald * r44076 10/brlcad/trunk/src/libged/red.c: include raytrace.h for prototype. remove extern func decl |
| 17:52.42 | CIA-52 | BRL-CAD: 03davidloman * r44077 10/geomcore/trunk/ (include/DataManager.h src/GS/DataManager.cxx): put in bu_external<->GeometryChunkMsg conversion functions. |
| 18:06.54 | CIA-52 | BRL-CAD: 03davidloman * r44078 10/geomcore/trunk/include/GeometryChunkMsg.h: Forgot a file in the ByteArray cleanup.... |
| 18:20.15 | brlcad | starseeker: testing |
| 18:24.26 | starseeker | brlcad: I see you listed red comb renaming as something to support for the next release? |
| 18:25.10 | brlcad | with all this attention needing to go towards red, might as well finish it while it's all in context |
| 18:25.33 | brlcad | otherwise it'll never get done unless there's another set of bugs |
| 18:25.36 | starseeker | so we should make write_comb work on copies as well? |
| 18:26.17 | brlcad | yeah, I was basically reviewing from top to bottom |
| 18:26.48 | brlcad | got to the attr stuff, and a bit more to finish up in there |
| 18:27.40 | brlcad | sorting out what this std avs api should look like now |
| 18:29.05 | brlcad | if you want to hit up write_comb in the meantime, you're welcome to but might be less conflict if you work either on recognizing the name change or making sure the read-in is robust |
| 18:29.28 | starseeker | is working on the rename |
| 18:30.04 | brlcad | basically just trying to get things to a no-hack "done" state without adding any new functionality/features |
| 18:30.48 | brlcad | nice work on the std avs stuff by the way -- the functions work pretty well together |
| 18:30.57 | brlcad | just that one missing so far, and maybe some name cleanup |
| 18:31.12 | starseeker | thanks :-) |
| 18:32.07 | CIA-52 | BRL-CAD: 03brlcad * r44079 10/brlcad/trunk/include/raytrace.h: add the other 'new' attr funcs that are needed for the symbols to get published. still a work-in-progress. |
| 18:32.49 | CIA-52 | BRL-CAD: 03brlcad * r44080 10/brlcad/trunk/include/raytrace.h: private funcs till names get changed |
| 18:32.59 | starseeker | is there a case-insenstivie version of the bu string comparison macro? |
| 18:33.54 | brlcad | we use something in a few other places, maybe strcasecmp |
| 18:35.48 | brlcad | yeah, we surprisingly don't do a lot of string-insensitive comparisons |
| 18:35.59 | brlcad | libfb options |
| 18:39.08 | brlcad | might be simple enough to add a BU_STRI_EQUAL and friends |
| 18:39.40 | brlcad | or BU_STRCASE_EQUAL |
| 18:45.16 | brlcad | starseeker: the other thing I wanted to change .. you have all that logic in write_comb for pretty-printing, but standard printf has options that do most of that built-in |
| 18:48.32 | *** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194) | |
| 18:49.16 | AbhijitKane | brlcad: do you have any info on the old material database / website? |
| 18:52.12 | brlcad | AbhijitKane: yes, I do |
| 18:52.13 | CIA-52 | BRL-CAD: 03erikgreenwald * r44081 10/geomcore/trunk/src/interfaces/cl/gsclient.lisp: Flush output buffer at end of msg write. Implement implement ping, info, fail, ok, rualive and imalive. |
| 18:52.52 | AbhijitKane | brlcad: i've started with a draft proposal, and was wondering what i could add to it |
| 18:58.39 | kunigami | hi, which string should be passed to bu_malloc and bu_free? |
| 18:59.17 | ``Erik | anything that explains what the memory is for, it's to help in debugging |
| 19:00.34 | brlcad | AbhijitKane: the existing dev interface is at mater.brlcad.org |
| 19:00.56 | starseeker | brlcad: ah, figures |
| 19:01.16 | AbhijitKane | nods |
| 19:01.24 | starseeker | wades into the rename logic... |
| 19:01.31 | kunigami | ok. I'll pass the name of the first pointer for which the memory is being allocated |
| 19:01.36 | starseeker | let there be build failures! |
| 19:02.04 | brlcad | kunigami: just something short but descriptive "alloc foo", "free foo" |
| 19:02.35 | brlcad | the bu_calloc/bu_malloc string should pair up with the bu_free() string |
| 19:03.15 | brlcad | not necessarily the same string, but if you were reading a log file, some reasonable pairing so you could check the pairings if you needed to |
| 19:04.26 | kunigami | hmm what if I allocated in bu_basename as bu_malloc(..., "foo"), then I tell in the documentation that bu_free(..., "foo") should be called? |
| 19:05.09 | brlcad | not necessary |
| 19:05.39 | brlcad | maybe "bu_basename alloc" |
| 19:08.40 | kunigami | then bu_free(..., "bu_basename free")? |
| 19:10.39 | brlcad | well the free happens in userland code, not library code so you don't really have any control over that |
| 19:14.26 | kunigami | hmm, understood. so I'll just do bu_free(var, "var free"). sounds good? |
| 19:15.33 | brlcad | kunigami: but where are you calling bu_free? |
| 19:15.57 | AbhijitKane | brlcad: regarding the materials site, could there be google/openID integration as well? |
| 19:15.57 | AbhijitKane | <PROTECTED> |
| 19:16.27 | kunigami | right before the scope of the variable returned by bu_basename ends |
| 19:16.28 | CIA-52 | BRL-CAD: 03davidloman * r44082 10/geomcore/trunk/src/libNet/NetMsgRouter.cxx: Use the word 'routing' instead of 'forwarding' when talking about the routing of NetMsgs. Confused some people, this is better. |
| 19:16.32 | brlcad | AbhijitKane: the issue there is we presently have accounts in drupal and mediawiki ... there was an effort to integrate them into one ldap but that's incomplete |
| 19:17.35 | brlcad | adding in google/openID adds more account auth but doesn't integrate with the other two, so not much of a benefit integration-wise |
| 19:17.52 | brlcad | now if you also update our drupal/MW installs to use google/openID, then that'd be different |
| 19:18.07 | brlcad | could be a little subtask |
| 19:18.59 | AbhijitKane | ok |
| 19:19.00 | brlcad | otherwise, auth is a much lesser concern to getting add/edit/inherit/view/delete working cleanly |
| 19:20.14 | AbhijitKane | yes, getting the crud operations working properly will be the first priority |
| 19:20.57 | brlcad | crud? :) |
| 19:22.30 | AbhijitKane | create read update delete. but i'm not sure whether i'm using it in the right context, lol |
| 19:22.36 | CIA-52 | BRL-CAD: 03Erik 07http://brlcad.org * r2781 10/wiki/NetMsgTypes: add more info |
| 19:23.48 | kunigami | in brlcad_path.c there's a line: return bu_basename(bu_progname); --- where bu_progname is a global variable. how to proceed? |
| 19:24.27 | CIA-52 | BRL-CAD: 03Erik 07http://brlcad.org * r2782 10/wiki/GeometryReqMsg: New page: Message sent to the server to request data. Single GSString with a URI/URN style encoding of the geometry (path/to/file.g/top). (Should this be a multistring message?) |
| 19:26.27 | brlcad | kunigami: probably something similar to bu_argv0_full_path() where it has an internal static buffer, get the basename, copy into buffer, free the basename, return the buffer |
| 19:27.42 | CIA-52 | BRL-CAD: 03Erik 07http://brlcad.org * r2783 10/wiki/GeometryManifestMsg: New page: Sent after a geometry req is recv'd, but before the chunks are sent. uint32 number of objects/strings/chunks. List of GSStrings for returned objects. ReUUID is the same as the GeometryR... |
| 19:30.24 | CIA-52 | BRL-CAD: 03Erik 07http://brlcad.org * r2784 10/wiki/GeometryChunkMsg: New page: Actual raw binary V5 .g goodness. ReUUID is the same as the associated GeometryReqMsg's UUID. There will be the same number of these as there were entries in the GeometryManifest. NOT ... |
| 19:31.41 | CIA-52 | BRL-CAD: 03Erik 07http://brlcad.org * r2785 10/wiki/GeometryChunkMsg: mention length in stream |
| 19:33.24 | kunigami | brlcad: hmm good idea |
| 19:33.35 | CIA-52 | BRL-CAD: 03starseeker * r44083 10/brlcad/trunk/src/libged/red.c: Add the ability for changing name assignment in the red.c text file to rename the comb being edited. |
| 19:33.41 | starseeker | brlcad: there we go |
| 19:33.50 | brlcad | starseeker: awesome |
| 19:34.22 | brlcad | btw, just found (and hopefully fixed) a particularly egregious bu avs iterator bug |
| 19:34.23 | starseeker | needs another set of eyes, but it seems to work here |
| 19:34.39 | starseeker | in red or in libbu? |
| 19:34.45 | brlcad | libbu |
| 19:34.50 | starseeker | ow |
| 19:34.58 | brlcad | the BU_AVS_FOR() macro iterates from the end to the front, from count-1 |
| 19:35.08 | brlcad | so if count == 0 ... poof |
| 19:35.14 | starseeker | winces |
| 19:35.31 | starseeker | yeah, that's not good... |
| 19:38.04 | CIA-52 | BRL-CAD: 03starseeker * r44084 10/brlcad/trunk/TODO: r_weiss fixed dem-g crashes |
| 19:38.14 | CIA-52 | BRL-CAD: 03brlcad * r44085 10/brlcad/trunk/include/bu.h: |
| 19:38.14 | CIA-52 | BRL-CAD: bad AVS, no donut for you. BU_AVS_FOR() macro iterator starts from the end of |
| 19:38.14 | CIA-52 | BRL-CAD: the avs to the beginning. however, if the avs is empty, this would result in |
| 19:38.14 | CIA-52 | BRL-CAD: indexing into a -1 index and potentially cause a segfault. make the loop safe |
| 19:38.15 | CIA-52 | BRL-CAD: by setting it to null if count is zero, so it should kick right out of the loop. |
| 19:39.21 | brlcad | hm, that's insufficient |
| 19:43.47 | CIA-52 | BRL-CAD: 03davidloman * r44086 10/geomcore/trunk/ (include/SvnDataSource.h src/GS/SvnDataSource.cxx): Implement required functions for SvnDataSource as spelled out by IDataSource |
| 19:50.56 | CIA-52 | BRL-CAD: 03davidloman * r44087 10/geomcore/trunk/ (3 files in 2 dirs): Update data sources to pass back bu_externals instead of Objects. This isn't optimal, nor do i think it will be permanent, but its the best approach at the moment. |
| 19:52.40 | CIA-52 | BRL-CAD: 03erikgreenwald * r44088 10/geomcore/trunk/src/interfaces/cl/gsclient.lisp: implement geomreqmsg and geommanifestreq. stub geomchunkmsg. |
| 19:54.37 | CIA-52 | BRL-CAD: 03davidloman * r44089 10/geomcore/trunk/src/GS/DataManager.cxx: Make DataManager handle bu_externals rather than Objects |
| 19:56.46 | CIA-52 | BRL-CAD: 03brlcad * r44090 10/brlcad/trunk/include/bu.h: need to make sure we don't enter the loop with that NULL pointer. halt if iterator or target is NULL |
| 19:57.54 | brlcad | there, that should allow looping over empty avs |
| 19:57.58 | CIA-52 | BRL-CAD: 03davidloman * r44091 10/geomcore/trunk/tests/GS/ (CMakeLists.txt FileDataSourceTest.cxx): lots of cascading changes to FileDataSourceTest |
| 20:01.37 | CIA-52 | BRL-CAD: 03brlcad * r44092 10/brlcad/trunk/include/bu.h: go a step further and don't try to dereference the avs if we get handed a NULL pointer. one more example of the lengths we go to for you. because we care. |
| 20:04.34 | dloman | lol nice one. |
| 20:04.51 | dloman | that's a bumper sticker if i've ever seen one. |
| 20:06.29 | *** join/#brlcad volock (~chatzilla@174.46.225.138) | |
| 20:07.39 | CIA-52 | BRL-CAD: 03brlcad * r44093 10/brlcad/trunk/include/bu.h: document BU_AVS_FOR() macro with an example code snippet. |
| 20:10.59 | CIA-52 | BRL-CAD: 03brlcad * r44094 10/brlcad/trunk/include/bu.h: tweakage |
| 20:11.52 | kunigami | in nirt/if.c there's a external array, ValTab. There are at least two elements of ValTab that store the output of bu_basename. should I use the static buffer trick? |
| 20:13.37 | CIA-52 | BRL-CAD: 03brlcad * r44095 10/brlcad/trunk/src/librt/db5_types.c: use db5_standard_attribute() instead of hard-coding the standard attribute names in db5_apply_std_attributes(). also check our inputs in db5_standardize_avs(). |
| 20:16.17 | volock | <PROTECTED> |
| 20:16.18 | volock | ...though I've also used BSP and Oct Trees. I'm trying to think out how an API like is asked for should work. IE. What kind of data it'd be expecting, etc for crafting my proposal |
| 20:16.49 | brlcad | kunigami: at a glance, you can either wrap the output in bu_strdup() then free the memory at the end (see 'need_to_free' for similar issue) ... or you can reuse the existing regionPN buffer presuming ValTab is not used after that function |
| 20:16.54 | brlcad | hello volock |
| 20:17.44 | volock | hello brlcad. You're Chris right? |
| 20:18.03 | brlcad | some people call me that |
| 20:18.06 | brlcad | most call me Sean :) |
| 20:19.09 | volock | Ah. I was going from memory from reading the wiki you set up for us prospective GSoC people. You guys definitely have a lot of interesting coding to do, that looks like a lot of fun. Then again as an Applied Math and CS double major, my view may be a little skewed. |
| 20:20.58 | brlcad | thanks, most of us tend to think it's a lot of fun too |
| 20:21.24 | brlcad | as for the spatial partitioning project, the #1 difficulty there is going to be careful integration |
| 20:22.26 | brlcad | that gets at the very heart of our core library, which is highly optimized for our current purposes, customers, raytracing, etc |
| 20:23.22 | brlcad | ideally, you'd not only have pretty good familiarity with spatial partitioning but also with our LIBRT library and how it does what it does currently |
| 20:24.15 | brlcad | even something as simple as abstracting out what it currently does without affecting performance could be very tricky |
| 20:24.46 | brlcad | much harder to implement a completely different modular partitioning scheme that actually out-performs :) |
| 20:25.15 | brlcad | so that's not mean to scare or entice you, it's just the matter-of-facts surrounding that particular project |
| 20:26.39 | volock | Yeah. I have experience with Spatial Partitioning both from a raytracer and working for someone doing particle physics. Those were considerably simpler than this would be obviously. Not only because your problem contains performance constraints compared to what has probably been highly optimized code over years, but in the variety of data you'd want to easily send to the API |
| 20:32.07 | brlcad | the other kicker is that our spatial partitioning has to be at least partially aware of the construction hierarchy since we use constructive solid geometry (CSG) where there may be void regions or unknown overlap conditions |
| 20:32.15 | brlcad | we only rarely deal with polygons so all you really have for binning things together is a primitive's overall bounding box or bounding sphere |
| 20:32.17 | brlcad | so, what brought you to brl-cad's ideas list? |
| 20:32.21 | brlcad | or not |
| 20:32.41 | *** join/#brlcad volock (~chatzilla@174.46.225.138) | |
| 20:33.21 | kunigami | brlcad: is there any guarantee that after the 'need_to_free' region the memory allocated won't be used? |
| 20:33.45 | brlcad | didn't look through the code that closely, good question :) |
| 20:36.06 | kunigami | well, yesterday you said that if refactoring the code would take more than 15 minutes I should tell you :P I think I spent at least an hour on it :) |
| 20:38.06 | *** join/#brlcad volock (~chatzilla@174.46.225.215) | |
| 20:38.29 | volock | Sorry my internet connection decided to go out |
| 20:38.57 | brlcad | kunigami: yes, fair enough -- it's a task for someone, that doesn't necessarily need to be you right now |
| 20:39.25 | brlcad | if you're selected, maybe you can finish the job on your own patch if someone else hasn't by then :) |
| 20:41.05 | kunigami | hmm, ok. that's the only file that is not that trivial to change. All other ocurrences of bu_basename I've already changed. Should I re-submit the patch with this new changes for registration? |
| 20:42.35 | brlcad | absolutely |
| 20:43.04 | brlcad | helps to give them new name either on the file or the comment, so can tell which is the latest |
| 20:56.32 | CIA-52 | BRL-CAD: 03erikgreenwald * r44096 10/geomcore/trunk/src/interfaces/cl/gsclient.lisp: implement chunking protocol. Add "getgeom" conviencience function |
| 20:58.50 | kunigami | brlcad: ok, I'll append a version on it |
| 21:11.03 | kunigami | If I write more than one proposal and both are accepted, will you take into consideration the priority of my choices? |
| 21:13.50 | brlcad | both can't be accepted -- we'd narrow it down to one or the other |
| 21:14.15 | brlcad | but that said, your interest definitely matters too, so write down your priority in the proposal too |
| 21:15.54 | kunigami | hmm ok |
| 21:17.52 | brlcad | proposals often do get changed throughout the course of the summer too, so long as we're both in agreement on the goals and approach as things change |
| 21:18.43 | brlcad | again, we care more about integrating new developers than we do about getting a particular chunk of code written |
| 21:22.21 | CIA-52 | BRL-CAD: 03starseeker * r44097 10/brlcad/branches/cmake/ (5 files in 4 dirs): MFC r44096 |
| 21:25.33 | kunigami | perfect! |
| 21:27.31 | kunigami | hmm, does anyone know if melange allows editing the proposal? or if I want my proposal to be reviewed I should write it in other place (google docs for example) and send only the final revision to melange? |
| 21:28.57 | brlcad | yes, you can continue to edit up to the deadline |
| 21:29.09 | brlcad | we will write questions and comments there too |
| 21:29.28 | brlcad | if you want feedback beforehand, suggest wiki or google docs |
| 21:29.50 | brlcad | otherwise, not much difference when/where the comments occur -- other than the earlier the better |
| 21:30.01 | brlcad | gets really hectic in the last few days |
| 21:39.48 | *** join/#brlcad ``Erik (~erik@BRLCAD.ORG) | |
| 21:39.51 | CIA-52 | BRL-CAD: 03erikgreenwald * r44098 10/geomcore/trunk/src/interfaces/cl/ (gsclient.asd gsclient.lisp gsnet.lisp): break GS net ops into seperate package |
| 21:56.29 | CIA-52 | BRL-CAD: 03starseeker * r44099 10/geomcore/trunk/tests/svntest/ (CMakeLists.txt main.c): Get as far as deleting and adding files via the commit editor - still don't have the ability to apply diffs. |
| 22:01.28 | CIA-52 | BRL-CAD: 03brlcad * r44100 10/brlcad/trunk/src/librt/db5_types.c: check our inputs for sanity on all the avs standard attribute functions |
| 22:06.04 | volock | How many people can BRL-CAD hire through GSoC? And how many typically apply (out of curiosity)? |
| 22:17.26 | brlcad | volock: we don't consider them as "hires", it's not just a summer job |
| 22:17.47 | brlcad | if it's just a summer job to you, then GSoC (with any org) might not be right for you |
| 22:18.18 | brlcad | the intention is to get you involved in open source development as a long-term contributor |
| 22:20.12 | brlcad | otherwise, we talk about it some at http://brlcad.org/wiki/Google_Summer_of_Code and this year's slot count specifically at http://brlcad.org/wiki/Google_Summer_of_Code/2011 |
| 22:25.16 | CIA-52 | BRL-CAD: 03starseeker * r44101 10/geomcore/trunk/tests/svntest/main.c: OK, this creates a new file and gets contents into it. Next step will be to change the contents of an existing file. |
| 22:41.25 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 23:01.09 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 23:01.09 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 ETA 20110401 || Welcome GSoC 2011 Students! Speak up, ask questions, start here: http://brlcad.org/wiki/Google_Summer_of_Code/2011 | |
| 23:14.33 | *** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no) | |
| 23:25.13 | CIA-52 | BRL-CAD: 03starseeker * r44102 10/geomcore/trunk/tests/svntest/main.c: grr - need to figure out how to handle svn_txdelta_run, apparently... |
| 23:31.40 | brlcad | for anyone that missed our logo limelite: http://imagepaste.nullnetwork.net/viewimage.php?id=1980 |
| 23:32.33 | brlcad | to be repeated in a few hours :) |
| 23:33.28 | CIA-52 | BRL-CAD: 03starseeker * r44103 10/geomcore/trunk/tests/svntest/main.c: Hmm - doesn't look like reading file contents from the repo was the issue - maybe the md5 checksum is really necessary. |
| 01:10.50 | *** join/#brlcad crazy_imp (~mj@a89-182-194-151.net-htp.de) | |
| 01:38.13 | *** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194) | |
| 03:20.51 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 03:26.31 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 03:57.24 | dloman | getting a failure in libged/list.c |
| 03:57.36 | dloman | ../../../brlcad-trunk/src/libged/list.c: In function ?_ged_do_list?: |
| 03:57.36 | dloman | ../../../brlcad-trunk/src/libged/list.c:146: error: the address of ?avs? will always evaluate as ?true? |
| 03:57.49 | dloman | replace ? with ' |
| 03:58.31 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 04:02.55 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 04:05.30 | brlcad | looking |
| 04:09.25 | brlcad | dloman: try that |
| 04:09.37 | CIA-52 | BRL-CAD: 03brlcad * r44104 10/brlcad/trunk/include/bu.h: attempt to quell warning about stack avs reference address always evaluating as true. |
| 04:10.12 | dloman | kk |
| 04:12.01 | dloman | compile has gotten farther than i did last time, so itink u got it. |
| 04:12.39 | brlcad | lil ridiculous |
| 04:25.14 | CIA-52 | BRL-CAD: 03brlcad * r44105 10/brlcad/trunk/include/bu.h: add parens |
| 04:37.54 | sachinjain | hey brlcad |
| 04:38.28 | sachinjain | I am trying to do one of the "quickies" to understand BRL-CAD |
| 04:40.10 | sachinjain | there is this project "Fix 'analyze' command output formatting" |
| 04:40.33 | sachinjain | I have made some changes in the file "src/libged/analyze.c" |
| 04:40.58 | sachinjain | bt when I am compiling, I am not able to see those changes |
| 04:41.19 | sachinjain | I think...there is problem with compiling part |
| 04:41.42 | sachinjain | can you tell me what are all the files that I need to recompile |
| 04:41.43 | sachinjain | ? |
| 04:43.01 | sachinjain | please help me |
| 04:43.23 | sachinjain | I have already run the "makefile" of "libged" directory |
| 04:47.56 | dloman | from the root of the project, all you should have to do is type 'make' |
| 04:48.13 | dloman | and any changes to source should recompile and link autojmaticaly |
| 04:50.04 | sachinjain | bt that is taking so much time |
| 04:50.33 | dloman | do yo uhave a multi core computer? |
| 04:51.12 | sachinjain | core 2 duo |
| 04:51.19 | dloman | okay then |
| 04:51.33 | dloman | try using the command: 'make -j2' or 'make -j3' |
| 04:51.53 | dloman | that will start 2 or 3 compiling jobs simultaneously. |
| 04:51.54 | dloman | things go a lot faster that way |
| 04:51.59 | sachinjain | ok |
| 04:52.07 | dloman | many things in brlcad rely on others being compiled. |
| 04:52.17 | sachinjain | hmmm.... |
| 04:52.22 | dloman | take the time and do a full compile and things will work better. |
| 04:52.30 | sachinjain | I thought of recompiling the whole thing earlier |
| 04:52.44 | dloman | have you compiled the entire suite yet? |
| 04:52.48 | sachinjain | yup |
| 04:52.52 | dloman | kk |
| 04:52.54 | dloman | so 'make |
| 04:53.06 | dloman | from the root of the checkout dir shouldn't take too long |
| 04:53.45 | sachinjain | gonna ask one question.... |
| 04:53.54 | sachinjain | if I would do this project.... |
| 04:54.12 | sachinjain | then...your requirement of "making a patch" will be fulfilled |
| 04:54.24 | sachinjain | or do I need to do something more? |
| 04:55.19 | dloman | I'll defer that question to brlcad himself, he's the GSoC Admin for us. |
| 04:55.34 | sachinjain | yeah...I am asking to him only |
| 04:55.39 | sachinjain | no offence to you dloman |
| 04:55.40 | sachinjain | :) |
| 04:55.44 | dloman | non taken |
| 05:28.49 | brlcad | poor sachin |
| 05:32.01 | bhinesley | lol |
| 05:36.13 | CIA-52 | BRL-CAD: 03davidloman * r44106 10/rt^3/trunk/ (5 files in 2 dirs): |
| 05:36.13 | CIA-52 | BRL-CAD: Stub in MinimalDatabase and MinimalObject. After some thought, reading and |
| 05:36.13 | CIA-52 | BRL-CAD: notes, a cleaner/simpler way to interface GS and CoreInterface with eachother is |
| 05:36.13 | CIA-52 | BRL-CAD: needed. These two classes will form the bulk of this new approach. |
| 06:18.24 | brlcad | calls it a night |
| 06:24.59 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 06:24.59 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:52.26 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 07:39.42 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 07:47.24 | sachinjain | hey brlcad |
| 07:51.11 | sachinjain | brlcad : are you there? |
| 08:05.55 | sachinjain | hey...is there a way to decrease the compiling time? |
| 08:06.33 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 08:19.19 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 08:24.48 | CIA-52 | BRL-CAD: 03davidloman * r44107 10/rt^3/trunk/ (4 files in 2 dirs): Match up cstr and dstr signatures with superclass. |
| 08:29.51 | sachinjain | hey...dloman |
| 08:29.58 | sachinjain | that recompiling is taking so much time |
| 08:47.49 | sachinjain | dloman : I am getting some error while recompiling |
| 10:33.02 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:49.34 | dloman | sachinjain: .....and the error is? |
| 11:10.25 | sachinjain | "libtool: link: `../../src/libwdb/libwdb.la' is not a valid libtool archive |
| 11:10.25 | sachinjain | make: *** [libged.la] Error 1" |
| 11:10.30 | sachinjain | this is the error |
| 11:17.51 | sachinjain | dloman : are you there? |
| 11:18.38 | CIA-52 | BRL-CAD: 03davidloman * r44108 10/rt^3/trunk/ (6 files in 4 dirs): Add tests into build. Clean up remnants of old cmake system. Add libge tests. |
| 11:21.47 | dloman | sachinjain: did you do a clean prior to the rebuild? |
| 11:24.43 | sachinjain | no |
| 11:25.10 | dloman | try a 'make clean' |
| 11:25.17 | dloman | then a 'make -j3' |
| 11:25.24 | dloman | actually |
| 11:25.29 | dloman | 'make clean' |
| 11:25.32 | dloman | 'svn up' |
| 11:25.38 | dloman | then 'make -j3' |
| 11:27.56 | sachinjain | why am I not able to see those changes which I had made in a file? |
| 11:28.19 | dloman | what file? |
| 11:28.38 | sachinjain | /src/libged/analyze.c |
| 11:30.22 | sachinjain | do I have to recompile the whole thing.... |
| 11:30.51 | sachinjain | or can I run just the "makefile" in /src/libged directory |
| 11:37.00 | CIA-52 | BRL-CAD: 03davidloman * r44109 10/rt^3/trunk/ (include/MinimalDatabase.h src/libge/MinimalDatabase.cxx): Stub in desired functions for MinimalDatabase |
| 11:38.18 | dloman | all you should have to do is type 'make' form the top level directory for any changes. |
| 11:38.26 | ``Erik | you can do it in just the libged directory, but you'll need to make sure the dependancies for libged are built first... we usually do a big "make" after configure, then just keep running make when we update things. Make won't rebuild files it doesn't have to (my old mac takes about 14 seconds over nfs) |
| 11:43.31 | CIA-52 | BRL-CAD: 03davidloman * r44110 10/rt^3/trunk/ (include/MinimalObject.h src/libge/MinimalObject.cxx): Fill out MinimalObject fields and associated Getters. |
| 11:46.59 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 11:49.56 | CIA-52 | BRL-CAD: 03davidloman * r44111 10/rt^3/trunk/include/MinimalObject.h: Protect MinimalObject cstr, should not be public. |
| 11:54.56 | CIA-52 | BRL-CAD: 03davidloman * r44112 10/rt^3/trunk/tests/libge/ (CMakeLists.txt GeometryEngineTest.cxx): Add libge to cmake link list. Flesh out GE Test a bit more. Make fn for standard db generation for testing. |
| 11:55.43 | CIA-52 | BRL-CAD: 03davidloman * r44113 10/rt^3/trunk/ (include/MinimalObject.h src/libge/MinimalObject.cxx): Add a temporary debug fn for printing MinimalObject's internal state. |
| 11:57.30 | CIA-52 | BRL-CAD: 03davidloman * r44114 10/rt^3/trunk/src/libge/MinimalDatabase.cxx: Stub in NULL returns in all functions till implemented. |
| 12:12.24 | brlcad | sachinjain: you can rebuild in just the subdir, but you may have to run make depends first |
| 12:12.38 | brlcad | ``Erik: all sorts of tinyproxy errors |
| 12:22.20 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 12:25.32 | sachinjain | dloman : did you get my messages? |
| 12:26.02 | dloman | nope. /msg here or email or.... ? |
| 12:26.23 | sachinjain | I have made some changes to the file "/src/libged/analyze.c" |
| 12:26.30 | sachinjain | and then rebuild the whole thing |
| 12:26.38 | sachinjain | bt now...when I am running "analyze" command through mged terminal... |
| 12:26.46 | sachinjain | I am not able to see those changes |
| 12:27.04 | starseeker | sachinjain: are you running from the build directory or the install directory? |
| 12:27.08 | starseeker | e.g. did you run make install? |
| 12:27.30 | sachinjain | from the root directory? |
| 12:27.42 | starseeker | how are you running mged? |
| 12:27.46 | starseeker | just typing mged? |
| 12:27.59 | sachinjain | yeah |
| 12:28.14 | starseeker | type "which mged" (no quotes) |
| 12:28.19 | starseeker | what does it report? |
| 12:29.38 | sachinjain | /usr/brlcad/bin/mged |
| 12:30.04 | starseeker | that's why your not seeing changes - when you type mged you're getting the installed version |
| 12:30.12 | sachinjain | so? |
| 12:30.28 | starseeker | you either have to run make install so your altered version is installed, or specifically run the version in the build directory |
| 12:30.29 | sachinjain | what do I do now? |
| 12:31.19 | starseeker | just typing "make" does not put mged in /usr/brlcad/bin/mged |
| 12:31.41 | sachinjain | okie... |
| 12:31.44 | sachinjain | I got you |
| 12:31.46 | sachinjain | let me try now |
| 12:35.55 | sachinjain | starseeker : thanks a lot....it worked |
| 12:55.28 | ``Erik | brlcad: errors? there was a bit of a fit getting it installed and configured right (used to use crit for that... how's the user migration, btw?) |
| 13:01.41 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:04.43 | brlcad | d_rossberg: you raise a lot of good points, I'm responding to the them now -- some conceptual, some more short-term work-in-progress mes |
| 13:15.48 | sachinjain | brlcad : I am working on one of the quickies "Fix 'analyze' command output formatting".... |
| 13:16.25 | sachinjain | will that complete your requirement of "making a patch" |
| 13:16.27 | sachinjain | ?? |
| 13:20.04 | brlcad | sachinjain: it's not our requirement, it's you showing us how well you code |
| 13:20.32 | brlcad | when you're satisfied that you've shown your ability, submit it |
| 13:21.05 | sachinjain | okie |
| 13:32.20 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 13:33.26 | d_rossberg | brlcad: i've a lot of ideas for if you plan to support a new API, e.g. a NetDatabase which implements the client side and provides an application the same interface as the other Databases in coreInterface |
| 13:34.09 | d_rossberg | this makes it easy to write client programs for stand-alone and network applications |
| 14:07.31 | dloman | d_rossberg: Didn't mean to cause you alarm. I'm simply trying to find a way to leverage your coreInterface work for what we need the GeometryService to do. Cleanup to follow shortly. |
| 14:34.29 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 14:39.56 | CIA-52 | BRL-CAD: 03davidloman * r44115 10/rt^3/trunk/ (8 files in 4 dirs): |
| 14:39.56 | CIA-52 | BRL-CAD: New approach on getting bu_externals out of coreinterface. last idea broke the |
| 14:39.56 | CIA-52 | BRL-CAD: API and encapsulation. Using private methods this time around in a |
| 14:39.56 | CIA-52 | BRL-CAD: non-intrusive manner. CoreInterface should be returned to its previous state. |
| 14:45.48 | d_rossberg | dloman: i just got an idea on how to solve all your problems with the coreInterface but the page margin is to small to write it down here ;) |
| 14:46.31 | dloman | the approach I just committed involved extending MemoryDatabase with my own class, outside of coreInterface |
| 14:46.52 | d_rossberg | that's why i will write it in a reply to Sean's mail |
| 14:50.09 | d_rossberg | the core of the idea was to get the memory out of the memory database, this would be analogous to getten a file from the FileDatabase |
| 14:50.34 | dloman | righto, i just want the bytes |
| 14:51.27 | d_rossberg | sending this data over a network and reloading it into a MemoryDatabase would give you the database (or a single element in it) back |
| 14:52.36 | dloman | correct. The only stipulation is that we are not enforcing the need to use a MemoryDatabase object on the other end. client could be written in another language. |
| 14:53.29 | d_rossberg | but then you need a specific data format (not black box) |
| 14:54.20 | dloman | correct. We have a protocol defined to transport the data across the network. |
| 14:54.53 | dloman | in the case of transporting the geometry, the protocol equates to a header + geometrydata. |
| 14:55.12 | d_rossberg | it is not about the protocol, it is the data the client must be able to decipher |
| 14:56.01 | dloman | okay then. Is there something incomplete about the data contained in a bu_external? (something i missed?) |
| 14:57.10 | d_rossberg | you need BRL-CAD core's C API to decipher bu_external |
| 14:57.39 | dloman | nods, that makes sense :) |
| 14:58.08 | d_rossberg | i.e. at least a part of the client has to be written in C |
| 14:58.41 | starseeker | d_rossberg: unless you want to use asc2g, I don't think we have anything suitable that isn't bu_external for this kind of thing... |
| 14:59.13 | dloman | I believe there is some java code that can decipher an external, but for the most part yes, use the brlcad libs or implement their own version of them in the language of choice |
| 15:00.32 | d_rossberg | and then you are not far away from reinventing the wheel (now in Java, not C++) |
| 15:00.35 | starseeker | we could update our database format definition document... |
| 15:01.01 | starseeker | then there's a spec people can code deserializers to |
| 15:01.27 | CIA-52 | BRL-CAD: 03davidloman * r44116 10/rt^3/trunk/tests/CMakeLists.txt: Cmake file for the libGE tests needed to include the BRLCAD include dirs |
| 15:02.13 | CIA-52 | BRL-CAD: 03davidloman * r44117 10/rt^3/trunk/tests/libge/CMakeLists.txt: Cmake file for the libGE tests needed to include the BRLCAD include dirs (Missed a file) |
| 15:04.07 | d_rossberg | my approach would be to have a high level interface to the database in C++ to the programmers with the other languages |
| 15:04.40 | starseeker | then they still need one or more of our libraries to decode it though |
| 15:04.49 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 15:05.42 | d_rossberg | for a good Java programmer it isn't easy to understand all the rt_~ and bu_~ but it is easy to wrap coreInterface with some Java classes |
| 15:06.16 | d_rossberg | it is simply straight forfard |
| 15:07.53 | starseeker | that might make it simpler for people to wrap functionality in other languages, but isn't that orthogonal to the question of how to do a language agnostic wire protocol? |
| 15:08.24 | CIA-52 | BRL-CAD: 03davidloman * r44118 10/rt^3/trunk/ (include/MinimalObject.h src/libge/MinimalObject.cxx): Drop filename as its redundant with filePath. |
| 15:08.29 | d_rossberg | or look at my .net example: it requires some typing to write the wrapper but not much thinking |
| 15:09.36 | d_rossberg | i wouldn't call bu_extern language agnostic, it is quit C |
| 15:10.17 | d_rossberg | on the other side, simply reading the messages isn't very useful |
| 15:10.31 | CIA-52 | BRL-CAD: 03starseeker * r44119 10/geomcore/trunk/tests/svntest/main.c: grr. Try a different approach to svn changes. |
| 15:10.47 | dloman | starseeker: if the network stuff was in the CoreInterface and a 'bunch of other languages' could then use it... in theory at least ;) |
| 15:10.55 | d_rossberg | you had to reimplement all the knowledge about the elements and their behavior |
| 15:11.45 | d_rossberg | and all this to come out with something veri similar to coreInterface |
| 15:12.13 | starseeker | that's true for anyone wanting to do a client that doesn't use our libraries though - are you saying bu_external is worse than some other encoding for transporting that information? |
| 15:14.45 | d_rossberg | the problem is that i have to go now ;} and the yort answer to your question is: yes and no; i'll try to clarify it tomorrow |
| 15:15.10 | dloman | bah, i *hate* cliff hangers |
| 15:15.15 | dloman | ba-doom ching |
| 15:15.27 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 15:28.19 | CIA-52 | BRL-CAD: 03starseeker * r44120 10/geomcore/trunk/tests/svntest/main.c: Get set up to test application of diffs - early results promising |
| 15:37.39 | *** part/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 15:43.22 | CIA-52 | BRL-CAD: 03davidloman * r44121 10/rt^3/trunk/ (include/MinimalObject.h src/libge/MinimalObject.cxx): Fill out protected constructor properly. This cstr is the one that the MinimalDatabase will use to instantiate MinimalObjects |
| 15:48.42 | CIA-52 | BRL-CAD: 03davidloman * r44122 10/rt^3/trunk/ (include/MinimalDatabase.h src/libge/MinimalDatabase.cxx): |
| 15:48.42 | CIA-52 | BRL-CAD: Add/override Load() and Save() as well as make loading and non loading |
| 15:48.42 | CIA-52 | BRL-CAD: constructors. This must be done in order to preserve filename + path in the |
| 15:48.42 | CIA-52 | BRL-CAD: MinimalDatabase object. filename and path is required to have so that |
| 15:48.42 | CIA-52 | BRL-CAD: MinimalObjects generatedd by this MinimalDatabase have all they required |
| 15:48.42 | CIA-52 | BRL-CAD: information to be transmitted across a network |
| 16:16.23 | CIA-52 | BRL-CAD: 03davidloman * r44123 10/rt^3/trunk/ (TODO src/libge/MinimalDatabase.cxx): Implement getAllTopObjects(). Inefficient, but quick. Time is of the essence. Added TODO item for tracking purposes. |
| 16:42.37 | *** join/#brlcad Stattrav (~Stattrav@117.202.21.195) | |
| 16:42.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:11.09 | CIA-52 | BRL-CAD: 03davidloman * r44124 10/rt^3/trunk/ (3 files in 3 dirs): Implemented getAllObjects(), getAllTopObjects, getAllObjectsBelow(). Updated test to reflect. |
| 17:13.47 | CIA-52 | BRL-CAD: 03davidloman * r44125 10/rt^3/trunk/tests/CMakeLists.txt: Remove some debug console printing that accidently made it in. |
| 17:33.07 | CIA-52 | BRL-CAD: 03starseeker * r44126 10/geomcore/trunk/tests/svntest/main.c: move things around a bit so we can test whether changes to a .g are actually applied. |
| 17:33.10 | CIA-52 | BRL-CAD: 03davidloman * r44127 10/geomcore/trunk/src/GS/ (CMakeLists.txt GeometryProcessor.cxx GeometryProcessor.h): Drop GeometryProcessor. We have the GeometryEngine for this. |
| 17:37.50 | starseeker | wooot! |
| 17:38.11 | dloman | starseeker > svn ? |
| 17:40.52 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.138.254) | |
| 17:40.58 | starseeker | kinda |
| 17:42.02 | starseeker | I still can't get svn to do it's diff logic, but as long as individual objects aren't crazy huge it doesn't matter too much - I'm just checking to see whether the in-repository binary contents match the incoming binary contents, and if they don't overwrite the old with the new |
| 17:42.43 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 17:43.08 | starseeker | still need a refinement in that each object diff is currently its own commit (bad if you just changed 3000 objects) but the proof-of-concept is there |
| 17:43.51 | starseeker | if you take ktank, edit a couple objects and combs and save that as ktank2.g (e.g. keep the original ktank.g too, just edit the copy) |
| 17:44.32 | starseeker | you can do ./svnTest ktank.g ktank2.g |
| 17:44.40 | starseeker | it will 1. check in all of ktank.g |
| 17:45.02 | starseeker | 2. iterate through ktank2.g comparing objects found there to those in the repository |
| 17:45.19 | starseeker | 3. apply any modifications |
| 17:45.39 | starseeker | 4. re-assemble the repository into GS_staging/ktank.g |
| 17:46.45 | starseeker | still haven't handled globals yet |
| 17:50.43 | CIA-52 | BRL-CAD: 03davidloman * r44128 10/rt^3/trunk/src/libge/CMakeLists.txt: Change where some libge headers get installed to. brlcad/include instead of brlcad/include/brlcad |
| 17:56.27 | *** join/#brlcad Stattrav (~Stattrav@117.192.145.2) | |
| 17:56.27 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:01.40 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 18:06.22 | *** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net) | |
| 18:09.23 | CIA-52 | BRL-CAD: 03davidloman * r44129 10/geomcore/trunk/ (8 files in 2 dirs): Add a recursion flag to IDataSource::getObjs() and make the cascading changes. |
| 18:12.16 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.129.35) | |
| 18:12.26 | CIA-52 | BRL-CAD: 03davidloman * r44130 10/rt^3/trunk/ (include/MinimalObject.h src/libge/MinimalObject.cxx): Implement helper method: MinimalObject::getFullRepoPath(). This fn combines the path to the .g file, the .g file name and the object's name. |
| 18:13.56 | kunigami | hi, one of my proposals will be on the project "consolidate image processing". the idea is rectoring the code so all individual tools on src/util will be part of a library? if yes, should them be part of image.c or libicv? |
| 18:14.21 | CIA-52 | BRL-CAD: 03davidloman * r44131 10/geomcore/trunk/src/libNet/netMsg/GeometryChunkMsg.cxx: Consolidate code by using helper function. |
| 18:18.45 | kunigami | *refactoring |
| 18:24.52 | CIA-52 | BRL-CAD: 03davidloman * r44132 10/rt^3/trunk/include/MinimalObject.h: MinimalObject cstr need not be protected any longer. GeometryService classes will need to instantiate MinimalObjects. |
| 18:25.20 | CIA-52 | BRL-CAD: 0346.251.64.228 07http://brlcad.org * r2787 10/wiki/User:391_buy_cialis: |
| 18:45.20 | CIA-52 | BRL-CAD: 03starseeker * r44133 10/geomcore/trunk/tests/svntest/main.c: refactor logic that gets bu_external from svn file into its own function. |
| 18:53.15 | starseeker | huh - https://github.com/tpaviot/oce |
| 19:02.53 | CIA-52 | BRL-CAD: 03davidloman * r44134 10/geomcore/trunk/ (2 files in 2 dirs): Rename chunk<->ext converters to chunk<->obj converters. Updated implementation for new data types. |
| 19:20.17 | CIA-52 | BRL-CAD: 03davidloman * r44135 10/geomcore/trunk/CMake/FindLIBGE.cmake: Forgot to update the libGE search logic. |
| 19:36.32 | CIA-52 | BRL-CAD: 03erikgreenwald * r44136 10/geomcore/trunk/src/interfaces/cl/gsnet.lisp: Fix readuint64. Return t instead of type for automagically handled packets. Handle disconnect requests. Fix method mapping. |
| 19:39.58 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 19:54.13 | CIA-52 | BRL-CAD: 03davidloman * r44137 10/geomcore/trunk/src/libNet/netMsg/GeometryChunkMsg.cxx: Worked out a silly allocation bug in GeometryChunkMsg::chunkToObj() |
| 19:56.41 | CIA-52 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:46.251.64.228]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 20:07.59 | CIA-52 | BRL-CAD: 03erikgreenwald * r44138 10/geomcore/trunk/src/interfaces/cl/ (gsserver.asd gsserver.lisp): basic server |
| 20:11.04 | CIA-52 | BRL-CAD: 03davidloman * r44139 10/geomcore/trunk/tests/ (GS/CMakeLists.txt libNet/CMakeLists.txt): Fix libs linked. |
| 20:13.35 | CIA-52 | BRL-CAD: 03davidloman * r44140 10/geomcore/trunk/ (include/FileDataSource.h src/GS/FileDataSource.cxx): Start wiring up FileDataSource to GeometryEngine |
| 20:16.19 | CIA-52 | BRL-CAD: 03davidloman * r44141 10/geomcore/trunk/src/GS/DataManager.cxx: Add a list of strings to use to build a manifest. |
| 20:17.09 | CIA-52 | BRL-CAD: 03davidloman * r44142 10/geomcore/trunk/tests/GS/FileDataSourceTest.cxx: Update test with all recent changes |
| 20:17.31 | kunigami | #2 question: I suppose libicv stands for image conversion. I saw there's already a rotation implementation there, so, it the objective provide all sort of transformations such as filter, scaling, threshold? |
| 20:18.30 | kunigami | #3 question: will it contain conversion between different types of image (such as bw and pix)? |
| 20:23.08 | CIA-52 | BRL-CAD: 0399.125.83.101 07http://brlcad.org * r2793 10/wiki/User:Bhinesley: /* BRL-CAD Project Proposal */ Updated progress |
| 20:26.04 | CIA-52 | BRL-CAD: 0399.125.83.101 07http://brlcad.org * r2794 10/wiki/User:Bhinesley: /* Who I am / Experience */ Reworded |
| 20:33.34 | CIA-52 | BRL-CAD: 03starseeker * r44143 10/geomcore/trunk/tests/svntest/main.c: No clue if this is correct, but it compiles so checkpoint |
| 20:37.53 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 00:03.25 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 00:14.18 | starseeker | to my considerable surprise, that actually seems to have worked |
| 00:26.08 | CIA-52 | BRL-CAD: 03starseeker * r44144 10/geomcore/trunk/tests/svntest/main.c: whoops, double free |
| 01:11.32 | *** join/#brlcad crazy_imp (~mj@a89-182-208-175.net-htp.de) | |
| 01:23.40 | CIA-52 | BRL-CAD: 03starseeker * r44145 10/geomcore/trunk/src/other/uuid/CMakeLists.txt: This should probably be sleep, not Sleep? need to check |
| 01:24.30 | CIA-52 | BRL-CAD: 03starseeker * r44146 10/geomcore/trunk/src/GS/testclient/gstestclient.c: Don't need pkg.h here anymore |
| 01:28.43 | CIA-52 | BRL-CAD: 03starseeker * r44147 10/geomcore/trunk/src/ (4 files in 2 dirs): |
| 01:28.44 | CIA-52 | BRL-CAD: Start setting up for a library to handle subversion like we need it to be |
| 01:28.44 | CIA-52 | BRL-CAD: handled. Lots more to do here that a test program didn't have to worry about - |
| 01:28.44 | CIA-52 | BRL-CAD: svn error handling and making sure memory handling is sane are high on the list. |
| 01:36.20 | CIA-52 | BRL-CAD: 03starseeker * r44148 10/geomcore/trunk/src/libgeomsvn/breakout.c: Add a few more notes on things that need to be done. |
| 01:42.58 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601295.dsl.bell.ca) | |
| 01:44.40 | starseeker | ok, yeah - there's quite a bit of work here |
| 02:01.10 | CIA-52 | BRL-CAD: 03starseeker * r44149 10/geomcore/trunk/src/libgeomsvn/breakout.c: There's going to be a fair bit of sanity checking needed... |
| 02:29.16 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 03:03.09 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) | |
| 03:05.24 | brlcad | kunigami: libicv but they work with image.c (and that file may need to move to libicv) |
| 03:06.34 | brlcad | kunigami: #2 yes |
| 03:07.18 | brlcad | kunigami: #3 yes, that probably being the most important aspect of the library and important to "get it right" |
| 03:08.17 | brlcad | considerably time should be allotted to design, review, and critique of the API for libicv (e.g., writing all the headers before any implementation code, having a plan for how to plug in new formats) |
| 03:09.16 | brlcad | s/considerably/considerable/! |
| 03:33.48 | *** join/#brlcad WhiteCalf (MK@2607:f0d0:3001:68::2) | |
| 03:34.38 | brlcad | STUDENTS: you really should try to get draft versions of your applications uploaded to google by friday so mentors can review and comment on them before next week |
| 03:36.17 | bhinesley | Hi, brlcad. I'm working on a proposal for the MGED to Archer Command Migration project. I'm still figuring out how things work, but so far it seems that much of the migration should be pretty straightforward. |
| 03:36.27 | bhinesley | I'm trying to ascertain what level of detail would be appropriate for the proposal. For the section in which I'm explaining my migration "plan", am I just supposed to tell you what you need to understand what I plan to do, or should I elaborate to show that I know what I'm doing? |
| 03:36.43 | bhinesley | s/am I/should I |
| 03:37.13 | bhinesley | */ |
| 04:22.56 | brlcad | "yes" |
| 04:23.33 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-30-66-238.dsl.bkfd14.sbcglobal.net) | |
| 04:23.40 | brlcad | bhinesley: "yes" |
| 04:24.06 | bhinesley | yes, I should elaborate? |
| 04:24.07 | brlcad | the more detail the better but if you like, you can put up what is needed to understand the plan |
| 04:24.21 | brlcad | then if more detail is needed, someone will ask for it |
| 04:24.53 | brlcad | more important to have good testable milestons defined |
| 04:25.17 | bhinesley | Okay, sounds good. By having a draft up tomorrow, do you mean on the wiki or submitted to Google? |
| 04:25.27 | bhinesley | n/m |
| 04:25.37 | bhinesley | reread it |
| 04:25.45 | brlcad | yeah, would get it up to google by this point |
| 04:25.54 | brlcad | just to have the app "in" |
| 04:26.30 | bhinesley | Alright, thank you, that's all I needed to know. |
| 07:43.44 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 08:31.37 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 08:31.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:39.53 | *** part/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 10:06.24 | *** join/#brlcad crazy_imp (~mj@a89-182-208-175.net-htp.de) | |
| 10:37.30 | *** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) | |
| 11:36.28 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 12:40.58 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:01.14 | kunigami | hi, one more question: is there any possibility to rewrite image library in c++? |
| 13:19.06 | brlcad | kunigami: can't be rewritten because it's not written yet |
| 13:22.50 | brlcad | kunigami: you'd have to sell your case design-wise, what the benefits would be, what that design would look like |
| 13:23.21 | brlcad | libicv could be designed with a c++ implementation backend, but the front-end API (i.e., the public headers) needs to provide a pure C interface so C codes don't have to turn into C++ codes during refactoring |
| 13:24.51 | brlcad | that'd basically be like implementing full libicv in C++, then wrapping the whole library with a C API .. which may or may not actually be beneficial depending on how strong your C and C++ magic are ;) |
| 13:24.53 | starseeker | notes to take a look at this if he needs mph code for C++ someday... https://github.com/sile/mphf |
| 13:26.44 | brlcad | starseeker: interesting in itself that it's a simple hash container .. might make for a good libbu bu_hash generic bucket container |
| 13:27.00 | kunigami | hmm, perfect. I'll include that as a possibility on my proposal. I think we can delay this decision when designing |
| 13:27.15 | kunigami | ... the proposed library |
| 13:29.20 | brlcad | it'd basically be doubling the amount of design work, so it might not be worth it (or doable) for the timeframe given |
| 13:29.53 | brlcad | most of the time is really going to be spent refactoring and moving code around .. and API design |
| 13:30.31 | brlcad | (better to get a solid design with only one or two concepts refactored than to get a half-assed design with 100 concepts factored in |
| 13:30.47 | kunigami | haha ok :) |
| 13:31.53 | kunigami | hmm... could you tell me for which reason you want to unit all those stand-alone applications into a single library? |
| 13:32.46 | kunigami | doesn't it go against the philosophy that programs should do one thing and do it well? |
| 13:58.05 | ``Erik | those programs would still exist, but there's been demand for our image generating tools to output to a variety of formats, and we'd like to reduce the duplication of read/write code |
| 13:58.47 | ``Erik | (so pix-png would turn into 'bu_image *b = read_pix; write_png(b);', etc) |
| 14:14.30 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 14:18.09 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 14:36.18 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 14:45.36 | CIA-52 | BRL-CAD: 03erikgreenwald * r44150 10/geomcore/trunk/src/interfaces/cl/gsserver.lisp: implement reading the file and sending it as a chunk msg |
| 15:12.58 | kunigami | ok, thanks for the clarification |
| 15:15.57 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 16:13.07 | CIA-52 | BRL-CAD: 03bob1961 * r44151 10/brlcad/trunk/ (9 files in 2 dirs): Added the dm_reshape function to struct dm. This splits out the bits of code in dm-ogl and dm-wgl that reconfigure the openGL window after a resize. |
| 16:56.48 | willdye | Job openings at Google! http://www.google.com/intl/en/jobs/uslocations/mountain-view/autocompleter/index.html |
| 16:57.25 | willdye | And for fans of object-oriented programming: http://blog.mezeske.com/?p=377 |
| 17:17.17 | kunigami | ouch, I'm having a bad time with melange auto-formatting "feature" :P |
| 17:27.47 | kunigami | I've submitted my first proposal. Please, let me know if it's accessible for mentors. Suggestions are mostly welcome :) Thanks |
| 17:38.15 | *** part/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 17:47.02 | CIA-52 | BRL-CAD: 03starseeker * r44152 10/geomcore/trunk/src/libgeomsvn/ (CMakeLists.txt geomsvn.h repo.c): Checkpoint again - got a ways to go here. Take Sean's suggestion and work on the API/header first. |
| 17:52.44 | kunigami | I'm working on the proposal of http://brlcad.org/wiki/Vector_output_from_raytracing project. |
| 17:55.24 | kunigami | If I understood the information well, it's possible to calculate vector forms from models *with* raytracing |
| 17:58.05 | kunigami | ... but not with rtedge not. So an alternative is to interpolate rtedge output into splines since splines would be vector representation. Is that right? |
| 18:28.09 | *** join/#brlcad Ralith (~ralith@d142-058-173-143.wireless.sfu.ca) | |
| 19:03.50 | CIA-52 | BRL-CAD: 03bob1961 * r44153 10/brlcad/trunk/ (18 files in 4 dirs): Begin refactoring relevant code in libtclcad and libdm to live in libged. |
| 19:13.48 | CIA-52 | BRL-CAD: 03bob1961 * r44154 10/brlcad/trunk/src/libtclcad/ (Makefile.am ged_obj.c tclcad_obj.c): Move ged_obj.c to tclcad_obj.c in libtclcad. |
| 19:13.50 | CIA-52 | BRL-CAD: 03starseeker * r44155 10/geomcore/trunk/src/libgeomsvn/geomsvn.h: List out some more possible functions, tweak structures, etc... |
| 19:41.07 | *** part/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 20:03.04 | *** part/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 20:15.24 | *** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no) | |
| 20:24.00 | CIA-52 | BRL-CAD: 03erikgreenwald * r44156 10/brlcad/trunk/src/libged/red.c: quell uninitialized variable warning |
| 20:33.08 | CIA-52 | BRL-CAD: 03starseeker * r44157 10/geomcore/trunk/src/libgeomsvn/geomsvn.h: Checkpoint again. |
| 20:35.26 | CIA-52 | BRL-CAD: 03starseeker * r44158 10/geomcore/trunk/src/ (8 files in 2 dirs): Stake the claim - Geometry Version Management library - libgvm |
| 20:36.27 | CIA-52 | BRL-CAD: 03erikgreenwald * r44159 10/geomcore/trunk/ (src/libNet/CMakeLists.txt tests/libNet/CMakeLists.txt): add libge info |
| 20:36.32 | CIA-52 | BRL-CAD: 03starseeker * r44160 10/geomcore/trunk/src/libgvm/ (geomsvn.h gvm.h): rename the header before we change anything else (conflicts suck) |
| 20:54.24 | CIA-52 | BRL-CAD: 03starseeker * r44161 10/geomcore/trunk/src/libgvm/gvm.h: De-svnify gvm.h |
| 20:58.56 | CIA-52 | BRL-CAD: 03starseeker * r44162 10/geomcore/trunk/src/libgvm/gvm_svn.h: Add the specific subversion bits as a private header. |
| 21:02.38 | CIA-52 | BRL-CAD: 03erikgreenwald * r44163 10/geomcore/trunk/src/interfaces/cl/gsnet.lisp: add info message. fix manifest message off by 1 bug. |
| 21:05.10 | CIA-52 | BRL-CAD: 03starseeker * r44164 10/geomcore/trunk/src/libgvm/gvm.h: repository, not svn |
| 21:08.58 | CIA-52 | BRL-CAD: 03erikgreenwald * r44165 10/geomcore/trunk/src/interfaces/cl/gsnet.lisp: cleanup |
| 21:26.21 | CIA-52 | BRL-CAD: 03erikgreenwald * r44166 10/geomcore/trunk/src/interfaces/cl/gsserver.lisp: use read-sequence instead of looping with read-byte |
| 21:55.20 | CIA-52 | BRL-CAD: 03erikgreenwald * r44167 10/geomcore/trunk/src/interfaces/cl/gsnet.lisp: fix warnings, use read-sequence instead of iterating bytes |
| 21:58.26 | CIA-52 | BRL-CAD: 03erikgreenwald * r44168 10/geomcore/trunk/src/interfaces/cl/gsclient.lisp: fix handshake. use write-sequence instead of looping on write-byte. |
| 21:59.02 | CIA-52 | BRL-CAD: 03erikgreenwald * r44169 10/geomcore/trunk/src/interfaces/cl/gsserver.asd: force serial loading, since gsserver depends on gsnet |
| 23:33.09 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-30-66-238.dsl.bkfd14.sbcglobal.net) | |
| 00:35.53 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 01:11.19 | *** join/#brlcad crazy_imp (~mj@a89-182-193-252.net-htp.de) | |
| 02:15.47 | bhinesley | Whew, my proposal is in. Best of luck to you all. I'm taking the rest of the night off. |
| 02:49.13 | brlcad | bhinesley: awesome! |
| 02:49.31 | brlcad | perfect timing too |
| 02:57.24 | brlcad | kunigami: that's sort of the gist ... but not exactly interpolating rtedge output |
| 02:58.09 | brlcad | rtedge shoots a grid of rays, one ray per pixel, keeping track of what is hit |
| 02:59.26 | brlcad | anywhere there are two neighboring rays that hit two different objects, it colors one of the two pixels so an edge is drawn |
| 02:59.47 | brlcad | repeat over all pixels and you have an edge outline of the model in raster image form |
| 03:00.38 | brlcad | to make a vector image instead of a raster image, you need spline curves, so you're trying to evaluate and "fit" a curve that will match the edges that you detect |
| 03:01.39 | brlcad | you could use rtedge's output, but that will generally result in a very crappy set of curves unless you shoot a very very dense grid (i.e., a big image) |
| 03:03.22 | brlcad | better would be to detect edges at a given resolution, then refine to even higher resolution so you "hone in" on the real edge, then use that for the spline curve control points, trying to find a balance of not too many or too few control points, and producing a vector image within a reliable timeframe |
| 03:11.44 | starseeker | brlcad: would it be correct to say that the focus for an image conversion library would be on robustness and efficienty rather than covering a lot of formats? |
| 03:16.54 | starseeker | (robustness referring to things like handling very large images without wiping out on ram limitations and dealing with corrupt data...) |
| 03:29.30 | brlcad | starseeker: my priorities would be on 1) API design, 2) robustness, 3) breadth of support, and 4) performance |
| 03:30.12 | brlcad | it's hard to perform slow image processing, I'm not too worried about that unless it's abysmal :) |
| 03:30.38 | brlcad | getting the API right is the hardest part that probably deserves a couple solid weeks attention |
| 03:31.33 | brlcad | surveying and overviewing/reviewing all of the current image processing tools, figure out how they might fit into the API ... |
| 03:31.54 | brlcad | figure out a way to make the library emminently extensible pluggable |
| 03:32.41 | brlcad | bhinesley: really nice work on your proposal, additional feedback should be sometime this weekend |
| 03:37.09 | starseeker | was under the impression that handling really large images in low memory situations was something of a problem... |
| 03:40.19 | brlcad | sure, I think every one of our image converters presently assumes the image will fit in-core |
| 03:40.36 | brlcad | if the API is right, then it's just an implementation detail to optimize that later |
| 03:40.47 | starseeker | ah, k |
| 03:40.48 | brlcad | where you tile and use scratch disks or whatever |
| 03:41.12 | brlcad | we don't exactly hit that limit very often |
| 03:41.48 | starseeker | true |
| 03:42.22 | starseeker | guess I'm thinking about it due to those gargantuan scans from the National Archives, but that's a one-off situation |
| 03:43.33 | brlcad | yeah, you scan data that big .. but you rarely render an image that big :) |
| 03:43.58 | starseeker | heh - high res posters ftw |
| 03:44.49 | brlcad | still if it's done right, then merging in support for a given filter or conversion format could make sure the iterators are all 64bit unsigned ints |
| 03:45.43 | brlcad | or at least 32bit unsigned ints .. 4294967295 x 4294967295 is a pretty big image.. |
| 04:11.39 | bhinesley | brlcad: thank you, I look forward to it |
| 04:28.46 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 04:36.05 | *** join/#brlcad kasuga5 (~kasuga5@wlnt-02-042.dsl.netins.net) | |
| 05:02.12 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 06:50.03 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 07:26.02 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 07:34.18 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 08:02.22 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 08:08.56 | *** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net) | |
| 09:33.10 | *** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net) | |
| 10:39.33 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 11:08.43 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 12:05.09 | *** join/#brlcad crazy_imp (~mj@a89-182-193-252.net-htp.de) | |
| 14:49.15 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) | |
| 14:52.43 | *** join/#brlcad ``Erik__ (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 15:12.09 | ``Erik | huzzah, I has intarwebz again |
| 15:57.52 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 16:11.09 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 17:22.45 | starseeker | ``Erik: do you know of any lisp or scheme implementation that bootstraps itself using only assembly and has no C code? |
| 17:23.42 | ``Erik | most schemes |
| 17:23.49 | ``Erik | oh, wait, no C? hrm, no |
| 17:24.18 | ``Erik | C is lingua de franca, it's hard to find anything at all that doesn't use it to bootstrap :/ |
| 17:24.53 | ``Erik | ooooold lisp 1.5 is asm only, but for the, uh, ibm 704 and pdp1 iirc |
| 17:25.42 | ``Erik | graham says you can be working with 7 primitives, right? self-bootstrapping shoudln't be TOO hard |
| 17:25.53 | starseeker | yeah, that's why I was wondering if someone had done it |
| 17:26.03 | starseeker | maybe movitz, have to check |
| 17:27.11 | ``Erik | (mebbe we shoulda asked sbcl to submit a self-bootstrap to gsoc O.o) |
| 17:27.36 | starseeker | 7 primitives is very basic though - don't know if you can get to threads or system file io stuff with that... |
| 17:27.39 | starseeker | hehe |
| 17:28.15 | starseeker | is goofing off by digging around the whole "minimal bootstrap, literate lisp" thing again |
| 17:29.26 | starseeker | two most interesting sources so far are the islisp spec (which unlike ANSI is explicitly public domain, albeit quite a bit smaller) and sacla |
| 17:29.47 | ``Erik | given that on most os's, any syscall is a C function, I don't know how well you'll do avoiding C without working directly on the metal |
| 17:30.14 | starseeker | what about writing directly in assembly? |
| 17:30.40 | ``Erik | doable, if you happen to match the kernels call convention... which can be tricky |
| 17:31.18 | ``Erik | my brainfuck compiler to asm has "if mac, do this, if bsd, do this, if this version of linux, do this, if that versino of linux, do that..." |
| 17:31.56 | starseeker | hmm |
| 17:32.20 | ``Erik | most of that is just frontmatter... generally, it breaks down to unix/bsd/mac style vs linux/dos style... but there're still gotchas |
| 17:32.43 | ``Erik | (yes, linux is closer to dos than unix at that level.) |
| 17:32.48 | starseeker | ow |
| 17:34.31 | starseeker | huts for old lisp 1.5 sources... |
| 17:34.46 | ``Erik | I got mine at the simh site |
| 17:39.59 | starseeker | hah - no license info though http://www.softwarepreservation.org/projects/LISP/lisp1.5/ |
| 17:41.06 | starseeker | this one still has unisys propritary notes on it: http://www.frobenius.com/source.htm |
| 17:52.55 | starseeker | ah: ftp://ftp.informatimago.com/pub/free/develop/lisp/lisp15-0.0.2.tar.gz |
| 17:54.04 | starseeker | probably would have to check with MIT, but that might be usable... |
| 18:11.03 | starseeker | hmm. http://c2.com/cgi/wiki?LispImplementationsWrittenInLisp |
| 18:40.53 | kunigami | brlcad: thank you for the clarification. I couldn't get a draft of the proposal. I'm considering focusing in the two other proposals I've submitted. |
| 20:13.47 | CIA-52 | BRL-CAD: 0399.30.66.238 07http://brlcad.org * r2795 10/wiki/User:Bhinesley: GSoC proposal information removed (has been submitted) |
| 20:25.19 | *** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194) | |
| 20:25.43 | AbhijitKane | I've submitted a draft proposal on the GSOC website. |
| 21:40.23 | kunigami | hi, is there some reference on rt stand-alone usage? I've seen mged reference, but I'm confused with rt, specially with defining the objects. thanks! |
| 21:44.40 | *** join/#brlcad Ralith (~ralith@d142-058-173-143.wireless.sfu.ca) | |
| 22:21.28 | *** join/#brlcad Ralith (~ralith@d142-058-173-143.wireless.sfu.ca) | |
| 22:21.50 | kunigami | sorry, I was too hasty in asking that. I found a lot of documentation in brlcad/doc/. |
| 22:24.04 | brlcad | np |
| 23:28.36 | *** join/#brlcad dassouki (~ahmed@142.167.162.112) | |
| 23:29.39 | dassouki | this might seem like a silly question, but where can I find sets of plans for architecture related projects |
| 23:29.42 | dassouki | like full projects |
| 23:51.11 | *** join/#brlcad dassouki (~ahmed@142.167.162.112) | |
| 00:48.14 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 01:08.39 | *** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 01:11.07 | *** join/#brlcad crazy_imp (~mj@a89-182-205-145.net-htp.de) | |
| 01:33.14 | brlcad | dassouki: I've heard about this place called the internet, there might be some plans there |
| 02:22.03 | dassouki | brlcad: I've heard of that place too but can't find any architectural full sets .. |
| 04:24.00 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net) | |
| 04:52.53 | *** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194) | |
| 05:36.19 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 08:33.54 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 08:37.01 | *** part/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 09:25.23 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 09:28.44 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 10:56.35 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 13:53.19 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:15.21 | *** join/#brlcad kunigami1 (~kunigami@187.106.4.220) | |
| 14:35.30 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 15:16.38 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 15:17.45 | *** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194) | |
| 15:18.53 | adityag1 | brlcad : can i submit the application today ? |
| 15:49.39 | brlcad | adityag1: yes, the sooner the better |
| 16:02.30 | *** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194) | |
| 17:26.39 | CIA-52 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2796 10/wiki/MGED_Commands: /* B */ |
| 17:31.11 | CIA-52 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2797 10/wiki/MGED_Commands: /* C */ |
| 17:36.22 | CIA-52 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2798 10/wiki/MGED_Commands: /* D */ |
| 17:37.46 | CIA-52 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2799 10/wiki/MGED_Commands: /* D */ |
| 17:40.40 | CIA-52 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2800 10/wiki/MGED_Commands: /* E */ |
| 17:42.12 | CIA-52 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2801 10/wiki/MGED_Commands: /* F */ |
| 17:47.40 | CIA-52 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2802 10/wiki/MGED_Commands: /* G */ |
| 17:48.24 | *** part/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 17:50.26 | CIA-52 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2803 10/wiki/MGED_Commands: /* L */ |
| 17:54.03 | CIA-52 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2804 10/wiki/MGED_Commands: /* M */ |
| 18:21.45 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:37.21 | CIA-52 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2805 10/wiki/MGED_Commands: /* N */ |
| 18:39.40 | CIA-52 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2806 10/wiki/MGED_Commands: /* P */ |
| 18:42.50 | CIA-52 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2807 10/wiki/MGED_Commands: /* Q */ |
| 18:52.12 | CIA-52 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2808 10/wiki/MGED_Commands: /* R */ |
| 18:55.55 | CIA-52 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2809 10/wiki/MGED_Commands: /* S */ |
| 18:57.41 | CIA-52 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2810 10/wiki/MGED_Commands: /* U */ |
| 19:29.21 | *** join/#brlcad Stattrav (~Stattrav@117.192.130.12) | |
| 19:29.21 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:29.39 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:35.29 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:52.26 | CIA-52 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2811 10/wiki/MGED_Commands: /* R */ |
| 19:53.43 | CIA-52 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2812 10/wiki/MGED_Commands: /* D */ |
| 19:56.19 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:02.09 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:37.53 | kunigami1 | hi, I learning to use the rt tool and noticed that when using incremental mode (-i), the image is not saved if we specify output. I know it doesn't make sense to use incremental mode if we're not visualizing the output, but is this behaviour expected? Would be bad if we just ignore flag -i whenever -o is specified? |
| 22:15.49 | CIA-52 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2813 10/wiki/MGED_CMD_closedb: Initial import from markhobley.yi.org |
| 22:49.08 | *** join/#brlcad juanman (~quassel@201.255.61.144) | |
| 22:49.18 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 22:52.40 | CIA-52 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2814 10/wiki/MGED_CMD_dbversion: initial import from markhobley.yi.org |
| 23:53.10 | *** join/#brlcad kasuga5 (~kasuga5@wlnt-02-042.dsl.netins.net) | |
| 23:54.07 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 00:06.54 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 00:38.22 | *** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) | |
| 00:38.43 | *** join/#brlcad alex_jon1 (~alex_joni@81.196.65.201) | |
| 00:39.38 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 01:11.52 | *** join/#brlcad crazy_imp (~mj@89.182.223.38) | |
| 02:55.29 | *** join/#brlcad vtts_ (~vytautas@diz.ktu.lt) | |
| 02:55.51 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 03:01.45 | *** join/#brlcad kanzure_ (~kanzure@bioinformatics.org) | |
| 03:01.45 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 03:01.45 | *** join/#brlcad alex_jon1 (~alex_joni@81.196.65.201) | |
| 03:01.45 | *** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ) | |
| 03:01.45 | *** join/#brlcad poolio_ (~poolio@BZ.BZFLAG.BZ) | |
| 03:04.51 | *** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ) | |
| 03:44.43 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 03:44.43 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 ETA 20110401 || Welcome GSoC 2011 Students! Speak up, ask questions, start here: http://brlcad.org/wiki/Google_Summer_of_Code/2011 | |
| 04:04.54 | *** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ) | |
| 04:06.15 | *** join/#brlcad kanzure__ (~kanzure@bioinformatics.org) | |
| 04:07.11 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 04:07.17 | *** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ) | |
| 04:20.17 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 04:38.50 | *** join/#brlcad kasuga5 (~kasuga5@wlnt-02-042.dsl.netins.net) | |
| 05:43.33 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 07:00.00 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 07:25.28 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 07:25.57 | *** join/#brlcad kasuga5 (~kasuga5@wlnt-02-042.dsl.netins.net) | |
| 07:46.25 | *** join/#brlcad kasuga5 (~kasuga5@wlnt-02-042.dsl.netins.net) | |
| 08:23.38 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 08:23.38 | *** join/#brlcad CIA-105 (~CIA@208.69.182.149) | |
| 08:23.38 | *** join/#brlcad dtidrow__ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) | |
| 08:23.38 | *** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) | |
| 08:23.39 | *** join/#brlcad kasuga5 (~kasuga5@wlnt-02-042.dsl.netins.net) | |
| 08:23.39 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 08:23.39 | *** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ) | |
| 08:23.39 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 08:23.39 | *** join/#brlcad kanzure__ (~kanzure@bioinformatics.org) | |
| 08:23.39 | *** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ) | |
| 08:23.39 | *** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ) | |
| 08:23.39 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 08:23.39 | *** join/#brlcad vtts (~vytautas@diz.ktu.lt) | |
| 08:23.39 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 08:23.39 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net) | |
| 08:23.39 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 08:23.39 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) | |
| 08:23.39 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 08:23.39 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 08:23.39 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 08:23.39 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 08:23.39 | *** join/#brlcad hyarion (c05ben@peppar.cs.umu.se) | |
| 08:23.39 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 08:23.39 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 08:23.39 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 08:23.39 | *** mode/#brlcad [+o ChanServ] by verne.freenode.net | |
| 08:45.14 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 09:11.20 | dloman | reads GSOC proposals..... |
| 09:17.18 | dloman | Whoa, a Head System Admin for a university doesn't know what IRC is? oh dear..... |
| 09:35.05 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 09:37.36 | dloman | okay, now that's done. |
| 09:37.39 | dloman | interesting reads |
| 09:39.14 | dloman | needs about 10 more cores in my laptop :) |
| 09:44.00 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 09:44.41 | *** join/#brlcad vtts (~vytautas@diz.ktu.lt) | |
| 09:45.06 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 10:46.35 | kunigami | hi, any comments on my proposals? thanks :) |
| 10:47.46 | CIA-105 | BRL-CAD: 03davidloman * r44170 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: GSConnection need not extend Thread. Limits implementation and restricts the end user's design. |
| 10:51.56 | CIA-105 | BRL-CAD: 03davidloman * r44171 10/geomcore/trunk/src/interfaces/java/test/org/brlcad/geometryservice/ (LoginTest.java SerialTest.java UUIDSerialResearch.java): Add in some tests and research. These were created some time ago but were never committed. |
| 10:53.34 | CIA-105 | BRL-CAD: 03davidloman * r44172 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSJavaInterface.java: Update for starting of worker thread. |
| 11:06.46 | dloman | kunigami: other than the lisencing issues starseeker mentioned, I'd offer the idea of providing a detailed list of the standalone apps you are consolodating. |
| 11:07.41 | kunigami | ok! could you confirm that my proposal for 'shader enhancements' is visible for you? |
| 11:08.23 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 11:08.33 | dloman | i can see it yes. |
| 11:09.19 | kunigami | ok, thanks. I'll edit my proposal ASAP |
| 11:10.34 | dloman | a detailed list of apps provided in the begining gives you a better way to gauge your progress and, overall, helps to more definitively determine success or not. |
| 11:10.38 | dloman | just an idea |
| 11:12.00 | kunigami | perfect, I agree |
| 11:13.09 | *** join/#brlcad kasuga5 (~kasuga5@wlnt-02-042.dsl.netins.net) | |
| 11:37.36 | *** join/#brlcad kasuga5_ (~kasuga5@wlnt-02-042.dsl.netins.net) | |
| 11:40.16 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 11:43.36 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 11:56.21 | *** part/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 11:57.56 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 12:17.08 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:33.25 | CIA-105 | BRL-CAD: 03brlcad * r44173 10/brlcad/trunk/src/libged/screengrab.c: |
| 12:33.25 | CIA-105 | BRL-CAD: identify that this is a major encapsulation problem. this introduced a new |
| 12:33.25 | CIA-105 | BRL-CAD: dependency on libdm/libfb, which totally sucks and blows library encapsulation. |
| 12:34.55 | CIA-105 | BRL-CAD: 03brlcad * r44174 10/brlcad/trunk/src/libged/Makefile.am: gah, as expected, this introduced a new dependency. regression fail. maybe need a test to prevent this from occurring on all the core libraries (making calls to libraries that shouldn't be linked. |
| 12:39.43 | brlcad | is really in disbelief ... seriously? there shouldn't have to be training wheels to prevent this sort of crap coding |
| 12:52.01 | CIA-105 | BRL-CAD: 03brlcad * r44175 10/brlcad/trunk/TODO: cliff added support for name changes on red (needs NEWS). still need to indep test matrix edit. more importantly, need to undo the mess added to libged. |
| 12:59.28 | ``Erik | O.o |
| 13:08.44 | brlcad | wonders how libged is even compiling without a libdm link, is it all really header macros? |
| 13:10.01 | brlcad | begs for further separation of include into subdirs, so you can't get away with this so easily |
| 13:10.56 | ``Erik | <-- has always been a fan of keeping the headers with the source, src/libbu/bu.h etc |
| 13:11.13 | brlcad | but then you can't distinguish public from private |
| 13:11.53 | brlcad | at least without making it stupid obvious like bu_private.h or bu_don_t_use_me.h |
| 13:11.58 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 13:12.06 | ``Erik | not without having a convention in naming or looking at the .am, but *shrug* hasn't bothered me |
| 13:12.31 | brlcad | then someone just renames the file or worse, just includes it |
| 13:12.45 | ``Erik | heh, tieprivate.h librt_private.h ged_private.h :D |
| 13:13.02 | brlcad | exactly, taking double measures to make it stupid obvious |
| 13:13.29 | ``Erik | so what're you thinking, include/bu/bu.h ? |
| 13:13.43 | brlcad | and how many of those are STILL bing included where they shouldn't be .. #include "../librt/librt_private.h" |
| 13:14.52 | ``Erik | *ponder* #ifndef BUILDING_LIBRT #error "Stopit." #endif |
| 13:15.17 | brlcad | yeah, exactly that, then adding include/bu to the cppflags so "bu.h" still works, maybe BU_CPPFLAGS |
| 13:15.51 | brlcad | might have to do something that obtuse really |
| 13:16.37 | brlcad | seriously, I totally expect better .. that sort of training wheels shouldn't be needed |
| 13:17.55 | brlcad | there's only one or two commiters that might not know better and they're not even the ones doing this |
| 13:20.23 | CIA-105 | BRL-CAD: 03brlcad * r44176 10/brlcad/trunk/TODO: need to group together library headers into public subdirs. will need to set up proper cppflags as well similar to the LIBS flags. |
| 13:21.07 | ``Erik | know anything about, uh, .dot and graphviz? I wonder if we could use the DEPENDS line to generate a map |
| 13:21.40 | CIA-105 | BRL-CAD: 03brlcad * r44177 10/brlcad/trunk/TODO: help cliff not go bald. |
| 13:21.42 | ``Erik | (assuming that line is generally correct... it's manual, so it does get out of sync on occasion) |
| 13:21.56 | brlcad | yes, I used graphviz to visualize the CSG graph before .. pretty awesome for small models |
| 13:22.17 | brlcad | had a g-dot script I wrote up (didn't commit it) |
| 13:22.24 | brlcad | havoc was insane |
| 13:23.00 | brlcad | a graphviz of the libs would be interesting |
| 13:23.05 | ``Erik | so when is the cmake merge? I've been using his branch on fbsd mac and win32 without issue |
| 13:23.17 | brlcad | after release |
| 13:23.38 | brlcad | which was today, but now have to undo bob's junk and mabye move screengrab |
| 13:27.54 | CIA-105 | BRL-CAD: 03brlcad * r44178 10/brlcad/trunk/TODO: if we do the subdir, then there's risk of people going lazy and including via subdir. add a regression to make sure it's clean code using CPPFLAGS. |
| 13:36.16 | CIA-105 | BRL-CAD: 03brlcad * r44179 10/brlcad/trunk/ (10 files in 2 dirs): (log message trimmed) |
| 13:36.16 | CIA-105 | BRL-CAD: I get it. It was an April Fool's Joke, right?? Revert to r44152 since it makes |
| 13:36.16 | CIA-105 | BRL-CAD: all sorts of calls to LIBDM macros and the dm struct, requires libdm header. |
| 14:04.00 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 14:04.33 | ``Erik | ahm, that commit removed struct tclcad_obj, which is flipping out libtclcad/tclcad_obj.c |
| 14:14.50 | brlcad | hrm,k |
| 14:15.35 | brlcad | ah, I apparently wasn't up to date |
| 14:17.59 | brlcad | now to hunt down a couple tires before I blow out my slicks |
| 14:18.18 | ``Erik | heh, noticed that :) I need to order a full set, myself :/ |
| 14:20.17 | CIA-105 | BRL-CAD: 03brlcad * r44180 10/brlcad/trunk/src/libdm/ (Makefile.am adc.c axes.c grid.c labels.c rect.c scale.c): rest of revert to r44152. helps to be fully up-to-date during merge. continuation of r44179. |
| 14:27.52 | CIA-105 | BRL-CAD: 03bob1961 * r44181 10/brlcad/trunk/src/libged/ged.c: typo in comment |
| 14:39.51 | CIA-105 | BRL-CAD: 03Erik 07http://brlcad.org * r2815 10/wiki/NetMsgTypes: add bot geometry request |
| 14:45.27 | CIA-105 | BRL-CAD: 03erikgreenwald * r44182 10/geomcore/trunk/ (3 files in 3 dirs): add GeometryBoTReqMsg |
| 14:53.03 | CIA-105 | BRL-CAD: 03erikgreenwald * r44183 10/geomcore/trunk/src/interfaces/cl/ (gsclient.lisp gsnet.lisp gsserver.lisp): add geombotreqmsg |
| 15:18.34 | Ralith | there's a CL API? awesome |
| 15:19.17 | ``Erik | it's just me dorking around with the protocol, it's a keen test bed :) |
| 15:24.15 | CIA-105 | BRL-CAD: 03erikgreenwald * r44184 10/geomcore/trunk/src/interfaces/cl/gsserver.lisp: break the connection loop out so it can be updated with a live session going |
| 15:25.25 | *** mode/#brlcad [+o brlcad] by ChanServ | |
| 15:58.49 | dloman | feels like garbage. might have to take the rest of the day as leave .... |
| 16:10.40 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 16:27.54 | brlcad | kunigami: which of those two proposals is your main interest? |
| 16:31.13 | kunigami | brlcad: I prefer shader enhancement! |
| 16:31.42 | brlcad | oh really? |
| 16:31.51 | brlcad | wouldn't have guessed that from the proposals :) |
| 16:32.06 | brlcad | you plan on filling out the rest of the details you'd left out then? |
| 16:32.38 | kunigami | :P I think I mentioned somewhere on "shader enhancement" that this one would have the greatest priority. let me check |
| 16:33.13 | brlcad | you may have, hadn't gotten to reading it word-for-word yet |
| 16:34.09 | kunigami | hmm ok. And yes, I'm planning to filling out the details. I just wanted to submit the draft for possible reviews. I've been studying rt's code this weekend and I already learned something to add on there :) |
| 16:34.33 | brlcad | as they currently stand written, at a glance, the image processing is much more clearly composed with goals, scope, integration, plan of attack, etc |
| 16:34.41 | brlcad | okay, good to know |
| 16:36.26 | kunigami | oh yes, I had a much clearer idea on what to do on image processing. I think I had the necessary knowledge to write the proposal. For the shader enhancement one, I have some research to do yet :) |
| 16:37.57 | kunigami | but anyway, I think that the shader enhancement is more challenging. Since I'm not sure if will be able to write a compelling proposal for this one, I also did one for the image processing. |
| 16:40.07 | brlcad | it definitely is more challenging :) |
| 16:40.47 | brlcad | so part of the reason is so that we scope to the summer timeframe accordingly so you can actually make progress and enjoy what you're working on :) |
| 16:41.33 | brlcad | wouldn't want you to get accepted to work on a hard task and then spend all summer flailing about in liboptical not making any progress, getting frustrated in a sea of code :) |
| 16:42.05 | brlcad | you won't likely keep working on that code after the money stops, and that's not something either of us benefits from :) |
| 16:47.53 | brlcad | bhinesley: comments posted |
| 16:50.40 | kunigami | hmm my idea was actually to keep working (there are a couple of other rt-related projects that I got interested), but unfortunately I don't know how will be my time after I finish my masters. |
| 16:51.23 | kunigami | but let us see what can I offer until the end of the week so you can better judge if I'll be able to do that in a summer |
| 16:52.52 | brlcad | application deadline is friday so we'll have the following two weeks to review and elaborate |
| 16:55.03 | kunigami | cool! I din't notice that during after deadline we could add further details to the proposal! |
| 16:56.05 | brlcad | it's supposed to be more to elaborate, but yes -- there is still some time to elaborate but at that point it should be in response to our questions |
| 16:56.49 | brlcad | I wouldn't bank on it -- your proposal should be substantially "done" (i.e. fully written) by Friday from your perspective |
| 16:57.18 | brlcad | no telling what sort of restrictions the new google-melange interface may impose after the deadline |
| 16:59.00 | kunigami | hmm ok! |
| 17:03.53 | CIA-105 | BRL-CAD: 03erikgreenwald * r44185 10/geomcore/trunk/src/interfaces/cl/gsserver.lisp: Enable multi-threading. New 'stop' function. Hoist session loop. Use specified dir for geometry instead of cwd. |
| 17:05.22 | brlcad | kunigami: have you read the shaders presentation? |
| 17:05.30 | brlcad | it's on the website somewhere |
| 17:15.42 | brlcad | kunigami: in order to get a quick grasp on shaders for your proposal, I'd recommend taking the following steps: |
| 17:15.59 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 17:16.04 | brlcad | 1) download http://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf and perform at least lessons 1 through 4 |
| 17:17.31 | brlcad | 1a) through lesson 7 to get to some basic (phong) shader options |
| 17:17.41 | brlcad | 2) download and read http://brlcad.org/w/images/2/2c/Optical_Shaders.pdf |
| 17:19.01 | brlcad | 3) download and read appendix B in http://brlcad.com/downloads/documentation/BRLCAD_VolumeIII.pdf |
| 17:22.29 | brlcad | that should give a pretty good survey of what's presently available, should help reading the code |
| 17:23.25 | kunigami | wow, thanks for the links! I'll surely read them! I've already taken exactly lessons 1 to 4 on /doc/lessons and learned how to use the basics of mged and rt :) I'll read the other ASAP |
| 17:24.14 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2816 10/wiki/Shader_Enhancements: add documentation references |
| 17:26.21 | brlcad | the shaders are unfortunately some of our least documented portions of the code (because being a content modeling and rendering system are completely secondardy concerns) |
| 17:27.06 | brlcad | that said, we have support for quite a lot .. some of more hacked and research quality than other portions, but most all working for a specific purpose at some point in time |
| 17:29.01 | brlcad | OSL has the ability to replace our current shader string with a more formal and descriptive shader parameterization, with the description living as either as a new database object or keeping the string and passing through to a new liboptical shader |
| 17:30.41 | kunigami | hmm interesting |
| 17:31.36 | brlcad | shader objects are the way to go :) |
| 17:31.49 | brlcad | how to deal with them is the bigger question |
| 17:36.44 | *** part/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 17:45.33 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 17:46.07 | dli | do we still need openNURBS then? |
| 17:46.16 | brlcad | what? |
| 17:48.07 | dli | brlcad or you mean shader is only for displaying, ray-tracing. |
| 17:48.37 | brlcad | shaders only pertain to optics, displaying geometry via raytracing |
| 17:49.26 | dli | brlcad, I was thinking to save all internal geometry as shaders and leave some computation to GPU |
| 17:49.50 | dli | that sounds too ambitious anyway |
| 17:50.28 | brlcad | I'm not sure you're using the same terminology or there is a big misunderstanding of some concept |
| 17:50.38 | brlcad | "I don't think that means what you think it means" :) |
| 17:51.40 | dli | brlcad, don't worry, I don't understand the 'shader' part anyway |
| 17:51.47 | brlcad | even if you're thinking of a GPU shader, you still have to have a geometric representation that goes with it |
| 17:52.07 | brlcad | shading merely answers "how" to draw .. not what |
| 17:52.09 | dloman | dli: How many fingers do you have on your right hand? |
| 17:52.23 | brlcad | six! |
| 17:52.36 | dloman | egads. |
| 17:52.42 | dli | 101 |
| 17:53.43 | brlcad | dli: speaking of 101, http://en.wikipedia.org/wiki/Shader ;) |
| 17:54.24 | brlcad | or even better, http://en.wikipedia.org/wiki/Shading |
| 17:55.32 | dli | brlcad, I thought shader also includes manipulating objects |
| 17:55.48 | brlcad | you have to have objects to manipulate in the first place |
| 17:55.55 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2817 10/wiki/Shader_Enhancements: |
| 17:56.16 | CIA-105 | BRL-CAD: 03erikgreenwald * r44186 10/geomcore/trunk/src/interfaces/cl/ (gsclient.lisp gsnet.lisp gsserver.lisp): fix off by one weirdness in chunk request |
| 17:56.21 | brlcad | and it doesn't modify the object, it only modifies how it's displayed |
| 17:57.55 | dli | brlcad, thanks |
| 18:04.33 | CIA-105 | BRL-CAD: 03erikgreenwald * r44187 10/geomcore/trunk/src/interfaces/cl/gsserver.lisp: remove packet type display |
| 18:04.55 | CIA-105 | BRL-CAD: 03erikgreenwald * r44188 10/geomcore/trunk/src/interfaces/cl/ (gsclient.lisp gsnet.lisp): fix malformed expressions |
| 18:06.28 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 18:09.03 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 18:21.34 | bhinesley | brlcad: cool, I responded |
| 18:21.50 | brlcad | bhinesley: do you get e-mail notification? |
| 18:22.02 | bhinesley | brlcad: oops, not to you. page must have cached... |
| 18:22.15 | bhinesley | no, how do I enable that? I was looking everywhere... |
| 18:23.47 | brlcad | I just mean if we post a comment, do they notify you |
| 18:23.49 | brlcad | might not be a feature |
| 18:24.04 | brlcad | was in the past, but it's a new interface this year |
| 18:24.04 | bhinesley | unfortunately, they don't |
| 18:24.10 | brlcad | k |
| 18:25.34 | bhinesley | it seems like setting up a end-user editable plain text file with command aliases might not be a bad idea |
| 18:25.57 | bhinesley | not for the project, but in the future |
| 18:26.47 | brlcad | users can (and do) do that now with their .mgedrc file |
| 18:27.07 | bhinesley | oh alright, I had no idea (obviously) |
| 18:27.14 | brlcad | it would be nice to formalize that into specific packages, though |
| 18:27.28 | brlcad | it's basically akin to using the alias command and your .profile now |
| 18:28.09 | bhinesley | ah |
| 18:28.15 | brlcad | more useful would be command alias "packages" for things like "legacy mode commands", "dwayne's extensions", etc |
| 18:28.36 | starseeker | thinks that's the way to go if we "clean up" our existing commands - a "legacy.tcl" file or some such |
| 18:29.33 | brlcad | they should register as plugins, though, and then get enabled via the options gui |
| 18:30.13 | brlcad | so we can ship multiple configurations that you can just checkbox on/off, or they can toss in their own subdir into an install or homedir and get listed too |
| 18:30.25 | bhinesley | that sounds good |
| 18:30.32 | bhinesley | is it just the alias token, or is there a way to change the default command names? |
| 18:30.48 | brlcad | there's a way to change the default names |
| 18:31.02 | bhinesley | okay, that's what I was getting at |
| 18:31.08 | brlcad | so in theory these packages could override everthing |
| 18:31.27 | bhinesley | sounds like a good GSoC project ;) |
| 18:31.43 | brlcad | getting libged cleaned up is more important right now :) |
| 18:31.48 | bhinesley | sure |
| 18:32.18 | brlcad | that establishes the command baseline, one reusable across applications |
| 18:32.48 | bhinesley | yeah, I see that it makes sense to do that first |
| 18:33.53 | brlcad | that gets at the command registration I was referring to in my comment, so commands would register themselves with libged as an extension of the library, describe their capability, implement functionality -- then each command would get mapped to one or more names for scripting purposes, various GUI widgets, and into the help system |
| 18:35.48 | bhinesley | that would be ideal |
| 18:35.54 | bhinesley | highly modular |
| 18:36.12 | brlcad | that's the long-term goal |
| 18:36.27 | brlcad | so lots of cleanup, LOTS of refactoring to get there |
| 18:37.54 | bhinesley | so the idea is to keep things as contained as possible, for now |
| 18:38.05 | bhinesley | ? |
| 18:38.22 | brlcad | what do you mean? |
| 18:38.39 | brlcad | the idea is to move towards that completely modular goal :) |
| 18:39.20 | CIA-105 | BRL-CAD: 03starseeker * r44189 10/brlcad/branches/cmake/ (19 files in 6 dirs): MFC r44188 |
| 18:39.25 | brlcad | getting the command logic all in one place, making the two main apps (archer and mged) call through to libged to get at that command -- ideally without being aware of that command directly |
| 18:41.57 | *** join/#brlcad Ralith (~ralith@d142-058-173-143.wireless.sfu.ca) | |
| 18:42.03 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 18:42.07 | bhinesley | I thought that you were implying that these capabilities were not yet possible |
| 18:42.54 | bhinesley | nevermind... |
| 18:47.55 | CIA-105 | BRL-CAD: 03starseeker * r44190 10/brlcad/branches/cmake/src/libtclcad/CMakeLists.txt: Update libtclcad CMakeLists.txt file |
| 18:48.02 | brlcad | which is where your gsoc proposal comes in .. |
| 18:48.58 | brlcad | you can override commands and do things to them now, but there's no system in place for managing them and the commands are listed all over the place |
| 18:50.05 | CIA-105 | BRL-CAD: 03starseeker * r44191 10/brlcad/branches/cmake/src/libtclcad/CMakeLists.txt: Ah, right - add tclcad_obj.c |
| 18:50.44 | kunigami | brlcad: I commented on your question about my time during the summer. Could you see what do you think? thanks |
| 18:59.24 | bhinesley | brlcad: at this point, I would feel more comfortable starting with the command migration. Perhaps after the GSoC I could take on the goal of highly modular commands. |
| 19:01.45 | brlcad | kunigami: sure, it'll be a while though |
| 19:02.08 | brlcad | bhinesley: fair enough -- even working on command migration is moving towards modular commands |
| 19:09.57 | sachinjain | brlcad : how to upload a patch on sourceforge |
| 19:11.37 | brlcad | sachinjain: I suggest searching the web, there are LOTS of tutorials on how to create a patch using subversion, and how to upload to our patches tracker should be outright obvious (search for it) |
| 19:16.21 | CIA-105 | BRL-CAD: 03bob1961 * r44192 10/brlcad/trunk/ (include/ged.h include/tclcad.h src/libtclcad/tclcad_obj.c): Mods to get libtclcad compiling again. |
| 19:27.20 | bhinesley | brlcad: okay, comment posted now. I'm leaving for class. |
| 19:27.26 | CIA-105 | BRL-CAD: 03starseeker * r44193 10/brlcad/branches/cmake/ (include/ged.h include/tclcad.h src/libtclcad/tclcad_obj.c): MFC r44192 |
| 19:30.09 | CIA-105 | BRL-CAD: 03starseeker * r44194 10/geomcore/trunk/src/libgvm/gvm.h: Add a few more possible gvm header entries. |
| 19:30.13 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 19:34.09 | *** part/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 19:44.09 | CIA-105 | BRL-CAD: 03starseeker * r44195 10/geomcore/trunk/src/libgvm/gvm.h: will probably want to populate lists from repositories to have an easy format to send over the wire. |
| 19:49.52 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 20:08.33 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 20:25.25 | starseeker | wonders wy db_update_ident is used to update both title and units - why not just one function for title and another for units? or even just have _GLOBAL use normal bu_avs pairs? |
| 20:33.50 | starseeker | or does it... |
| 20:33.51 | starseeker | hmm |
| 20:36.55 | brlcad | _GLOBAL is just an attribute object |
| 20:38.10 | CIA-105 | BRL-CAD: 03erikgreenwald * r44196 10/geomcore/trunk/src/interfaces/cl/ (brlcad.asd brlcad.lisp): start up a cffi wrapper for librt |
| 20:38.27 | brlcad | db_update_ident() is historic behavior, combining title and units together was that way in all previous db versions iirc |
| 20:39.14 | brlcad | maybe even to reduce two i/o operations to one, but only speculative |
| 20:39.47 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 20:39.48 | brlcad | separating them would make sense now |
| 21:02.12 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 21:02.12 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 21:02.12 | *** join/#brlcad CIA-105 (~CIA@208.69.182.149) | |
| 21:02.12 | *** join/#brlcad kanzure__ (~kanzure@bioinformatics.org) | |
| 21:02.12 | *** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ) | |
| 21:06.01 | CIA-105 | BRL-CAD: 03erikgreenwald * r44197 10/geomcore/trunk/src/interfaces/cl/brlcad.lisp: Fix magic sizes (this may be a bug in librt?). Fix up the rt-open func. |
| 22:46.38 | CIA-105 | BRL-CAD: 03bob1961 * r44198 10/brlcad/trunk/src/libged/title.c: Should be using local2base instead of base2local here. |
| 23:45.37 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 00:30.13 | starseeker | Woot! |
| 00:30.20 | starseeker | now has 3 Neo1973 phones |
| 01:11.30 | *** join/#brlcad crazy_imp (~mj@a89-182-208-247.net-htp.de) | |
| 02:03.50 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 02:27.04 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 02:46.18 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601295.dsl.bell.ca) | |
| 03:22.50 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 03:58.55 | brlcad | starseeker: haha |
| 04:49.44 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 04:50.07 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 05:57.41 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 06:04.45 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 06:39.26 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 06:39.26 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:10.42 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 09:00.22 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:03.59 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 10:29.15 | dloman | Mernin all |
| 10:36.32 | kunigami | good morning |
| 10:38.54 | ``Erik | yargh |
| 10:49.23 | dloman | so hows the lisp thing going =D |
| 10:58.01 | ``Erik | awesome, files are moving back and forth, etc |
| 10:58.54 | ``Erik | the next trick is tesselating geometry to send out on the fly, which is the brlcad.lisp shtuff (which'll also do images, wireframes, parts of files, etc) |
| 10:59.25 | dloman | are there svn libs for lisp? |
| 10:59.57 | ``Erik | probably, but cffi is quick and easy to write, way nicer than jni |
| 11:00.55 | dloman | kewl |
| 11:02.15 | ``Erik | librt is very macro and struct heavy, so it's tricky to interface it :/ almost temped to write getter/setter type funcs for some of the librt stuff :D |
| 11:02.36 | dloman | ...write it in what language? |
| 11:02.56 | ``Erik | C, in raytrace.h |
| 11:03.12 | dloman | i'd say go for it :) |
| 11:03.28 | ``Erik | rt_set_ray(point_t origin, vect_t dir); etc |
| 11:03.40 | ``Erik | er, with an application sturct somewhere in there |
| 11:12.56 | CIA-105 | BRL-CAD: 03davidloman * r44199 10/geomcore/trunk/ (2 files in 2 dirs): Add in an optional replyMsg arg to the objToChunk converter |
| 11:22.39 | CIA-105 | BRL-CAD: 03davidloman * r44200 10/geomcore/trunk/src/GS/FileDataSource.cxx: Oops, forgot to commit FileDataSource::getObjs() ! It's implemented. |
| 11:23.31 | CIA-105 | BRL-CAD: 03davidloman * r44201 10/geomcore/trunk/src/GS/DataManager.cxx: Cleanup/fixup DataManager::handleGeometryReqMsg. Now uses the shiney, new, and improved FileDataSource. |
| 11:29.27 | CIA-105 | BRL-CAD: 03davidloman * r44202 10/geomcore/trunk/src/GS/GeometryService.cxx: Make GeometryService objects route GEOMETRYMANIFEST NetMsg's to the Datamanager |
| 11:41.25 | CIA-105 | BRL-CAD: 03davidloman * r44203 10/geomcore/trunk/ (3 files in 3 dirs): Stub in GetCmd (client cmd) for getting geometry from server. |
| 12:16.25 | dloman | ``Erik: whats with the GeometryBotReqMsg ? |
| 12:17.04 | dloman | look identicle to GeometryReqMsg |
| 12:17.18 | ``Erik | so far, eventually it should tesselate the geometry into an inmem db and send that |
| 12:17.41 | ``Erik | to feed ogl, isst, vsl, etc |
| 12:18.23 | dloman | why is a *Msg doing any work other than serialization and deserialization? tesselation is the job of the GE... isn't it? |
| 12:19.19 | ``Erik | I d'no how ya have things wired up, I was just mimicking what I saw :D I imagine the msg would have to ask ge for a facetized version, no? |
| 12:20.12 | dloman | perhaps, but that's not the way the gs is architected. |
| 12:21.11 | ``Erik | okie, it's hard to read through all that inheritance, d'no where exactly it should fit... I just figured I'd put SOMETHING there so you could fix it up later :D |
| 12:21.14 | dloman | some function being executed by some thread would 1) get the geometry from the DataManager, 2) use the GE to tesselate it and 3) make a GeometryManifest/Chunk to send the results to the requestor. |
| 12:21.22 | dloman | kk |
| 12:21.40 | dloman | there isn't that much inheritance :) Nothing compared to stuff like QT and Boost. heh. |
| 12:21.47 | dloman | those make me cry |
| 12:21.58 | ``Erik | at least they're documented :> |
| 12:22.16 | dloman | :P They're also stable and released |
| 12:23.41 | dloman | ..weren't created by one person, weren't created by someone doing their first soft dev project, etc, etc. |
| 12:23.46 | dloman | the list is long. |
| 12:24.05 | ``Erik | (and the only machine I have with doxygen can't configure geomcore :/ ) |
| 12:24.21 | dloman | cmake fails? |
| 12:24.36 | ``Erik | FindBRLCAD.cmake can't see the (system) tcl |
| 12:25.14 | dloman | bummer |
| 12:25.15 | starseeker | ``Erik: if that's using our custom FindTCL there should be a way to expand the search paths |
| 12:26.08 | ``Erik | is that pushed into rt^3, too? |
| 12:26.24 | starseeker | uh, dunno |
| 12:26.44 | starseeker | I was waiting until the ge/gs/gui reshuffle to go through all that |
| 12:29.56 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:10.36 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 13:34.36 | CIA-105 | BRL-CAD: 03erikgreenwald * r44204 10/geomcore/trunk/src/interfaces/cl/brlcad.lisp: bind libgcv. do RT_APPLICATION_INIT stuff. use &key to fill some of the struct. |
| 13:35.05 | CIA-105 | BRL-CAD: 03erikgreenwald * r44205 10/geomcore/trunk/src/interfaces/cl/ (gsnet.lisp gsserver.lisp): clean up conditional stuff |
| 13:57.34 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 14:18.29 | CIA-105 | BRL-CAD: 03davidloman * r44206 10/geomcore/trunk/src/libNet/netMsg/GenericMultiByteMsg.cxx: Removed some stray debugging lines. |
| 14:19.44 | brlcad | so my joking rant was apparently taken much more to heart than was intended |
| 14:20.16 | brlcad | if anyone in here had a part in conveying how 'upset' I was, I really wasn't |
| 14:21.34 | brlcad | the initial crap coding comment was totally meant to be tongue-in-cheek playful, the rest was simple matter-of-fact |
| 14:21.42 | CIA-105 | BRL-CAD: 03davidloman * r44207 10/geomcore/trunk/ (include/GetCmd.h src/GS/cmds/GetCmd.cxx): Implement GetCmd for the test client. |
| 14:22.13 | brlcad | particularly with release preparations under way |
| 14:23.11 | dloman | Well, if you want honesty, i was working remotely yesterday and only had IRC to go by, but you came across as genuinely upset. Just how I read it. |
| 14:23.32 | dloman | based on your above comments I assume others read it incorrectly also eh? |
| 14:23.38 | brlcad | apparently |
| 14:23.56 | brlcad | dislikes conflict, generally very happy-go-lucky |
| 14:24.47 | brlcad | I was annoyed by the timing, and that probably made some of my remarks more cynical than usual |
| 14:24.55 | CIA-105 | BRL-CAD: 03davidloman * r44208 10/geomcore/trunk/src/libNet/netMsg/GeometryChunkMsg.cxx: Typo fix. |
| 14:25.48 | dloman | eh, it happens. As adults we all (should) have thick enough skin to weather someone's irritation, be it misinterpreted or not. |
| 14:25.51 | brlcad | either way, the internet sucks at conveying emotion and intent -- I should (and do) know better and should have known better yesterday |
| 14:26.35 | brlcad | also don't know if this played any part |
| 14:26.44 | brlcad | but for the record |
| 14:26.46 | brlcad | reverts should have NO NEGATIVE CONNOTATION |
| 14:27.17 | brlcad | particularly for open source software projects, something I was taught long ago that is different from closed development |
| 14:27.37 | brlcad | When there is dispute or need, it's supposed to encourage communication without any negative connotation. |
| 14:27.46 | brlcad | You have just as much right to revert something I've done if a need arises. |
| 14:27.53 | brlcad | If you un-revert something I've reverted, then we both stop and discuss since that implies there are conflicting needs. |
| 14:28.05 | brlcad | just an FYI for everyone :) |
| 14:28.59 | dloman | did i miss a revert war? |
| 14:29.05 | brlcad | nope |
| 14:29.25 | brlcad | but I did revert something yesterday and don't know if that played any part in people "interpreting" my upsetness |
| 14:29.49 | dloman | kk. I've been trying to pay atention to the commit emails and thought I'd missed yet another important bit of info |
| 14:30.29 | dloman | "SO i heard brlcad was so mad that he punched three old ladies in the face." |
| 14:30.40 | brlcad | it was four dammit! |
| 14:30.43 | dloman | nice |
| 14:32.08 | CIA-105 | BRL-CAD: 03davidloman * r44209 10/geomcore/trunk/src/GS/GeometryService.cxx: Make sure the DataManager point is initialized to something other than 0x0 prior to attempting to use it. |
| 14:34.19 | CIA-105 | BRL-CAD: 03davidloman * r44210 10/geomcore/trunk/src/GS/DataManager.cxx: Add some error logging so that DataManager won't handle a GeometryReqMsg silently anymore. |
| 14:43.18 | CIA-105 | BRL-CAD: 03davidloman * r44211 10/geomcore/trunk/src/ (3 files in 2 dirs): Make test client handle geometry data sent by server. |
| 14:45.48 | dloman | woot, back to where i was before the qt rip out :) |
| 14:46.24 | ``Erik | starts looking for something else to break O:-) |
| 14:46.35 | dloman | lol |
| 14:46.45 | dloman | no need, i'm already too good at breaking things. |
| 14:47.01 | ``Erik | so ya found the segfault? |
| 14:47.08 | dloman | oh, and take that damned halo off your head. you're not fooling anyone :P |
| 14:47.10 | dloman | yeah |
| 14:47.31 | dloman | keith was right on with the pointer pointing at garbage |
| 14:59.52 | CIA-105 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2818 10/wiki/MGED_Commands: /* E */ |
| 15:11.55 | CIA-105 | BRL-CAD: 03davidloman * r44212 10/geomcore/trunk/src/libNet/NetMsgFactory.cxx: Make NetMsgFactory log an error when an unknown MsgType is encountered. (Rather than just returning NULL) |
| 15:16.00 | CIA-105 | BRL-CAD: 03davidloman * r44213 10/geomcore/trunk/src/GS/DataManager.cxx: Fix DataManager's error reporting to the client. Was sending back error codes as MsgTypes. Now sends MsgTypes as MsgTypes! |
| 15:20.04 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 15:20.36 | ``Erik | now there's a cab: http://www.youtube.com/watch?v=OiKFCzMxJik |
| 15:21.37 | dloman | nice |
| 15:23.50 | dloman | question: int bu_file_readable(const char *path) |
| 15:24.05 | dloman | the int that is returned.... is it 0 == readable ? |
| 15:39.30 | ``Erik | nonzero is readable, src/libbu/stat.c ... if(bu_file_readable(file)) { do stuff to it; } else { bu_log("u y no has read?"); } |
| 15:41.13 | dloman | kk, that's what I was thinkging, just got confused. |
| 15:41.14 | dloman | danke! |
| 15:53.49 | CIA-105 | BRL-CAD: 03davidloman * r44214 10/geomcore/trunk/include/FileDataSource.h: Add in a util function that determines if the supplied path exists and if it does, whether or not its a file or dir. |
| 15:54.18 | CIA-105 | BRL-CAD: 03davidloman * r44215 10/geomcore/trunk/src/GS/FileDataSource.cxx: Woops, forgot a file on the last commit. |
| 16:03.00 | CIA-105 | BRL-CAD: 03davidloman * r44216 10/geomcore/trunk/src/GS/FileDataSource.cxx: Make FileDataSource filter out all paths except paths ending in files. |
| 16:12.01 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 16:12.37 | CIA-105 | BRL-CAD: 03davidloman * r44217 10/geomcore/trunk/src/GS/cmds/GetCmd.cxx: Update the GetCmd::getHelp() method to display correct help |
| 16:22.33 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 16:30.54 | brlcad | dloman: there is no guarantee that <0 means files doesn't exist |
| 16:31.27 | brlcad | header documents 0 (i.e., false) if doesn't exist, and >0 for exists .. <0 is undefined |
| 16:31.43 | dloman | didn't see that in the header :/ |
| 16:31.52 | *** join/#brlcad hyarion_ (c05ben@peppar.cs.umu.se) | |
| 16:32.05 | dloman | just saw one sentence, so i read the code and asked to confirm. =D |
| 16:32.21 | brlcad | they're meant to be simple if (bu_file_exists(file)) then do something else don't |
| 16:32.23 | *** join/#brlcad bhinesley_ (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net) | |
| 16:32.51 | brlcad | complex return values usually indicate API weaknesses |
| 16:32.58 | brlcad | so it's just a simple boolean |
| 16:33.02 | dloman | kk |
| 16:34.07 | *** join/#brlcad roberthl_ (~robert@v1.rhl.me.uk) | |
| 16:35.49 | *** join/#brlcad roberthl (~robert@v1.rhl.me.uk) | |
| 16:35.49 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 16:37.15 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 16:37.58 | *** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ) | |
| 16:39.19 | brlcad | dloman: fwiw, things like FileDataSource::existsFileOrDir() really belong up in libbu (at least the implementation of it does) |
| 16:39.32 | brlcad | so we're portably consistent and we get reuse |
| 16:39.40 | dloman | right on. |
| 16:40.03 | dloman | i'm pushing getting functionally complete and debugged to stable. Then I plan on doing a ****ton of clean up =D |
| 16:40.15 | brlcad | if the API is lacking, then it's just as much work to make things fit cleanly into libbu as they do somewhere else |
| 16:41.47 | *** join/#brlcad roberthl (~robert@v1.rhl.me.uk) | |
| 16:41.47 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 16:43.14 | brlcad | yeah, with the current code, I think we just hadn't had a need yet to distinguish dirs beyond bu_file_exists() and bu_count_path() |
| 16:43.49 | brlcad | if that need is there, then it's trivial to extend another call like bu_dir_exists() or bu_is_directory() |
| 16:43.57 | dloman | well if the esistsFileOrDir(char*) is usefull then i can push it down there. |
| 16:44.14 | brlcad | there's a whole class of posix file node matches like that |
| 16:44.38 | brlcad | I wouldn't push it as it -- right now you only care if it's a file or a dir, but there are other types |
| 16:44.41 | brlcad | could be a link |
| 16:44.43 | brlcad | a pipe |
| 16:44.44 | brlcad | a socket |
| 16:45.04 | brlcad | existsFileOrDirOrSymbolicLinkOrPipeOr ... |
| 16:45.19 | brlcad | each having useful purpose |
| 16:46.47 | brlcad | that's why the current just followed the posix class ("man bash", jump down to CONDITIONAL EXPRESSIONS to see a list) |
| 16:47.11 | dloman | kk |
| 16:48.52 | brlcad | you could get a nearly identical result to your function with something like bu_file_type() that returns an enum type for regular file, dir, link, named pipe, etc |
| 16:49.39 | dloman | bu_file_type(), got it. |
| 16:49.51 | brlcad | that way you're still only implementing support for the types you need now but have the API in place that will extend to future node types |
| 16:49.54 | *** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 16:55.56 | CIA-105 | BRL-CAD: 03erikgreenwald * r44218 10/brlcad/trunk/src/conv/g-egg.c: eliminate as many globals as possible. pack the rest in the global struct. |
| 16:57.11 | brlcad | pretty awesome: http://www.youtube.com/watch?v=xFrMl_5T0Rc&feature=player_embedded |
| 16:59.04 | brlcad | open source cars |
| 17:01.39 | starseeker | is that anything like these guys? http://www.40fires.org/ |
| 17:02.09 | starseeker | or the commerical side: http://www.riversimple.com/ |
| 17:05.16 | starseeker | huh - http://www.onawi.org/ |
| 17:05.27 | starseeker | that could be kinda cool |
| 17:05.40 | dloman | am i reading g_transfer.c:server_geom() correctly? wdb_export_external() doesn't write to disk there? |
| 17:05.58 | dloman | brlcad: Nice video, that guys a good speaker :) |
| 17:13.23 | brlcad | dloman: wdb_export_external() writes to the "database instance", whatever that is |
| 17:13.34 | brlcad | in g_transfer's case, it's an in-memory-only database |
| 17:13.49 | dloman | yeah, figgered that out just now, heh. |
| 17:13.56 | brlcad | so it doesn't write to disk, but only because it's in-mem |
| 17:14.29 | dloman | if i instantiate a different type of db, then wdb_export_external to that, then that will get me writing to disk...... correct? |
| 17:14.56 | brlcad | depends what kind of dbip you make, but if it's a file-based dbip, then yes -- it'll write out to disk |
| 17:19.29 | dloman | db_open() with a RT_WDB_TYPE_DB_DISK flag? |
| 17:27.47 | brlcad | sounds about right |
| 17:27.56 | dloman | right on |
| 17:28.14 | CIA-105 | BRL-CAD: 03starseeker * r44219 10/geomcore/trunk/src/ (6 files in 2 dirs): Get some renaming done, get a couple files building. |
| 17:37.57 | CIA-105 | BRL-CAD: 03erikgreenwald * r44220 10/brlcad/trunk/ (configure.ac src/Makefile.am src/java/): no implementation, abandoned 8 years ago, unused, gone. |
| 17:39.00 | dloman | http://www.local-motors.com/checkup.php?c=6998 |
| 17:39.01 | dloman | awesome. |
| 17:41.53 | ``Erik | http://ecoroamer.com/drupal/CAD-files dwg for the thing |
| 17:42.13 | dloman | ....do i smell a new addition to the db library? |
| 17:42.44 | ``Erik | dwg is all engineering line drawings, no solid geometry, right? |
| 17:42.55 | starseeker | right |
| 17:43.10 | starseeker | good material for modeling, but not a solid model itself |
| 17:44.24 | starseeker | license statement is... less than clear |
| 17:44.39 | starseeker | someone should suggest one of the creative commons licenses to him |
| 17:44.53 | CIA-105 | BRL-CAD: 03erikgreenwald * r44221 10/brlcad/trunk/src/conv/g-egg.c: quell warning that showed up on fbsd but not mac |
| 17:46.34 | CIA-105 | BRL-CAD: 03starseeker * r44222 10/geomcore/trunk/src/libgvm/ (gvm_svn.h mem.c): Ah, right - we'll be using memory pools for the internals. |
| 17:48.00 | ``Erik | looks like it's just a stretched f650 with a camper O.o |
| 17:49.00 | starseeker | probably |
| 17:49.12 | dloman | yeah *JUST* a streched f650 |
| 17:50.10 | ``Erik | they started with a 2007 f650 with a c7 diesel engine, stretched it, slapped a custom built camper on, run the camper on solar cells and heat captured off the exhaust O.o |
| 17:52.34 | CIA-105 | BRL-CAD: 03starseeker * r44223 10/geomcore/trunk/src/libgvm/ (breakout.c gvm.h): move header entrys around, remove breakout.c (deal with that later) |
| 17:52.59 | ``Erik | any news on red testing for release? |
| 17:53.29 | CIA-105 | BRL-CAD: 03brlcad * r44224 10/brlcad/trunk/src/libged/wdb_obj.c: if ged_title() is wrong, then this one is probably wrong too since it's the daddy. make title not clobber units. |
| 18:00.13 | starseeker | we've also got a report rtwizard isn't working... let me check... |
| 18:00.46 | starseeker | crud |
| 18:03.14 | *** join/#brlcad Stattrav (~Stattrav@117.192.142.251) | |
| 18:03.14 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:05.06 | CIA-105 | BRL-CAD: 03brlcad * r44225 10/brlcad/trunk/NEWS: |
| 18:05.06 | CIA-105 | BRL-CAD: bob found/fixed a bug with the title command. presumably, this would convert |
| 18:05.06 | CIA-105 | BRL-CAD: the working units to mm if you tried to set the title via the units command. |
| 18:09.50 | CIA-105 | BRL-CAD: 03brlcad * r44226 10/brlcad/trunk/TODO: libged encapsulation issue reverted for release, schedule backlog task to restore with libdm/libfb decoupling addressed. similar decouple needed for screengrab command (though that command may just end up migrating?). |
| 18:11.42 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 18:19.40 | CIA-105 | BRL-CAD: 03davidloman * r44227 10/geomcore/trunk/include/FileDataSource.h: Add a //TODO about swapping out existsFileOrDir with bu_file_type() |
| 18:31.40 | CIA-105 | BRL-CAD: 03davidloman * r44228 10/geomcore/trunk/src/GS/DataManager.cxx: Add server side logging for geometry requests |
| 18:38.56 | CIA-105 | BRL-CAD: 03davidloman * r44229 10/geomcore/trunk/src/GS/FileDataSource.cxx: Make note about the Logger failing after the call to BRLCAD::MinimalDatabase cstr. |
| 18:42.00 | CIA-105 | BRL-CAD: 03davidloman * r44230 10/geomcore/trunk/src/GS/GSClient.cxx: Display the name of the GeometryChunk as it comes in from the server |
| 18:44.26 | CIA-105 | BRL-CAD: 03brlcad * r44231 10/brlcad/trunk/TODO: file node entity type support to libbu |
| 19:21.22 | CIA-105 | BRL-CAD: 03brlcad * r44232 10/brlcad/trunk/TODO: red matrix edit works! |
| 19:26.59 | CIA-105 | BRL-CAD: 03brlcad * r44233 10/brlcad/trunk/TODO: red is looking better, doesn't seem to list rgb/color attributes multiple times any more, but now seems to be wiping out the shader and region_id at least when set to plastic and -1 respectively. |
| 19:42.57 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 20:38.54 | *** join/#brlcad Wildstar (42bd9f25@gateway/web/freenode/ip.66.189.159.37) | |
| 20:39.05 | Wildstar | Hello |
| 20:39.35 | Wildstar | Is there a PDP-11 source code for BRL-CAD? |
| 20:41.13 | Wildstar | BBL |
| 20:44.13 | CIA-105 | BRL-CAD: 03starseeker * r44234 10/geomcore/trunk/src/libgvm/ (CMakeLists.txt mem.c objects.c): Add preliminary stab at repository_object conversion routine. |
| 20:45.44 | dli | PDP-11 is 16bit, amazing request for brl-cad :( |
| 20:50.48 | CIA-105 | BRL-CAD: 03erikgreenwald * r44235 10/geomcore/trunk/src/interfaces/cl/ (gsclient.lisp gsnet.lisp gsserver.lisp): macros! |
| 00:40.24 | *** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ) | |
| 01:11.07 | *** join/#brlcad crazy_imp (~mj@89.182.193.239) | |
| 01:27.24 | *** join/#brlcad crazy_im1 (~mj@a89-182-193-239.net-htp.de) | |
| 01:28.00 | *** join/#brlcad vtts_ (~vytautas@diz.ktu.lt) | |
| 01:28.24 | *** join/#brlcad dtidrow_ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) | |
| 01:30.39 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601295.dsl.bell.ca) | |
| 01:32.29 | *** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 01:51.55 | *** join/#brlcad hyarion (c05ben@peppar.cs.umu.se) | |
| 01:53.46 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 01:54.23 | *** join/#brlcad dtidrow_ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) | |
| 02:14.14 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 02:14.44 | sachinjain | dloman : I have uploaded a patch on sourceforge |
| 02:15.02 | sachinjain | what do I do next? |
| 02:24.47 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 04:15.35 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 04:17.49 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601295.dsl.bell.ca) | |
| 05:09.07 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 06:18.45 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:31.57 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 06:38.37 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 06:45.17 | bhinesley | are there any requests for commands to migrate to Archer? |
| 06:45.39 | bhinesley | hard for me to tell what is useful |
| 07:12.25 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 07:23.14 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 07:28.10 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 09:42.11 | bhinesley | dloman: I'm not sure if it alerts you; I have updated my proposal. |
| 12:17.34 | CIA-105 | BRL-CAD: 03davidloman * r44236 10/geomcore/trunk/include/ByteArray.h: Fix typo! |
| 12:20.56 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 12:34.10 | tofu | woo hoo, e-mail notifications are wroking |
| 12:34.25 | brlcad | bhinesley: it sends notifications now |
| 12:35.09 | brlcad | dli: not really an amazing request -- that's about when BRL-CAD was started, on 16-bit systems |
| 12:35.18 | brlcad | vax 11/780, pdp-11, etc |
| 12:38.40 | brlcad | bhinesley: an intersting list of 13 to start with .. some of those will be hard, some are dead easy, some will require a complete rewrite... :) |
| 12:39.20 | brlcad | I wouldn't put read_muves on that list myself |
| 12:39.48 | brlcad | reid and remat are very useful commands, but they're actually presently coded as simple tcl scripts |
| 12:42.23 | brlcad | the rcc-* commands really warrant being grouped into a single command with various sub-commands, but sorting out a useful naming convention hasn't happened |
| 12:42.54 | brlcad | prj-add is a hack simply because the projection shader is complicated (still a useful command, but stupid API-wise) |
| 12:43.08 | brlcad | either way, a very interesting list :) |
| 12:43.59 | brlcad | a simple way to narrow in on 10 to migrate is to look at the MGED quick reference sheet and simply go by any of those that aren't in LIBGED yet, those are core useful commands |
| 12:44.31 | brlcad | several of which you list: closedb, journal, man) |
| 12:44.44 | brlcad | nice work |
| 12:46.31 | ``Erik | vax11/780 was a 32b system |
| 12:50.01 | ``Erik | thought that by the time the first hints of raytracing code hit rcs in '85, the pdp was gone and it was done on vax |
| 13:13.57 | brlcad | it was done on the vax, but the pdp wasn't gone just yet iirc |
| 13:19.32 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 13:25.33 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 13:30.57 | dloman | https://www.ibm.com/developerworks/mydeveloperworks/blogs/InsideSystemStorage/entry/ibm_japan_mailbag_of_interesting_reactions7?lang=en |
| 13:54.22 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 14:38.02 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 15:02.51 | CIA-105 | BRL-CAD: 03bob1961 * r44237 10/brlcad/trunk/src/tclscripts/mged/openw.tcl: Added a wrapper for the call to dbupgrade from the Tools menu. This catches the call and prints the results to the command window. The catch prevents a possible error window popping up. |
| 15:15.46 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 15:27.00 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 15:34.27 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 15:43.59 | CIA-105 | BRL-CAD: 03brlcad * r44238 10/brlcad/branches/STABLE/ (81 files in 28 dirs): merge trunk to STABLE from r43921 to HEAD r44237 |
| 15:49.12 | *** part/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 16:34.57 | CIA-105 | BRL-CAD: 03indianlarry * r44239 10/brlcad/trunk/src/librt/primitives/bot/g_bot_include.c: |
| 16:34.57 | CIA-105 | BRL-CAD: Having issues with 'size_t' declaration of some variables within function |
| 16:34.57 | CIA-105 | BRL-CAD: rt_bot_makesegs_(). Variables need signed values so converted to 'ssize_t'. Only |
| 16:43.27 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 16:59.32 | bhinesley | brlcad: Should I avoid the rcc commands, then? |
| 16:59.32 | bhinesley | There are ~50 commands on the quick reference that aren't currently available in archer. I've found that several appear to be obsolete, and some are nearly migrated already (sometimes just missing aliases). |
| 16:59.32 | bhinesley | Besides those already listed, what remains is: dbfindtree, geometree, rtabort, ill, sill, matpick, facedef, mirface, permute, extrude, orot, rotobj, oed, orientation, accept, reject, qorot, eqn, eye_pt, mrot, vrot, and area. |
| 16:59.32 | bhinesley | I hate to ask, but are there any that you would recommend? |
| 16:59.33 | bhinesley | Failing that, I've identified another ~90 commands based on the source. There are probably more, that simply aren't in the usual places. |
| 17:01.53 | indianlarry | |
| 17:06.36 | brlcad | bhinesley: many of 50+ commands are available in archer, but under a different name |
| 17:06.53 | brlcad | there shouldn't be too many actually obsolete |
| 17:07.07 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 17:08.05 | bhinesley | I tried to remove them If I could find that the name was just changed |
| 17:08.41 | bhinesley | as for obsolete commands, I found <5 from the quick reference. |
| 17:09.57 | brlcad | okay, that sounds about right |
| 17:10.12 | brlcad | geometree would be one, archer has its own tree view |
| 17:10.36 | bhinesley | I did make that note :) |
| 17:10.47 | brlcad | accept/reject pertain to stateful editing, which archer attempts to move away from |
| 17:11.04 | bhinesley | so oed is probably obsolete too |
| 17:11.25 | brlcad | yes and no |
| 17:11.34 | brlcad | what it does definitely need to be in libged ... |
| 17:11.44 | brlcad | but the way it does it might not necessarily be an 'oed' command |
| 17:11.52 | bhinesley | nods |
| 17:12.14 | brlcad | oed would be one of my top-picks to sort out migrating |
| 17:12.38 | brlcad | a whole tutorial is dedicated to oed because it's the main way to perform matrix editing on the command line in mged |
| 17:13.44 | brlcad | archer presently doesn't have a mechanism defined for matrix editing on the command line iirc, which relates to all of the transformation and illumination commands you listed: ill, sill, matpick, orot, rotobj, qorot, mrot, vrot |
| 17:14.10 | bhinesley | that's what I thought :-/ |
| 17:14.12 | brlcad | which are rather ridiculous |
| 17:14.21 | brlcad | there should be one "rotate" command |
| 17:14.35 | bhinesley | has this been done? |
| 17:14.36 | brlcad | with various suboptions for the different ways you might want to rotate |
| 17:15.10 | brlcad | of course not, it's basically refactoring those command names listed into one command when they migrate to libged |
| 17:15.34 | brlcad | orot+rotobj+qorot+mrot+vrot+rot -> rotate [options] |
| 17:16.09 | brlcad | you're going to get pretty nut and bolty with the commands remaining :) |
| 17:16.33 | brlcad | all the easy ones are already done |
| 17:16.49 | bhinesley | so it seems |
| 17:17.09 | brlcad | fyi, there are approximately 700 commands in mged last time I counted |
| 17:17.37 | brlcad | the goal is to consolidate that down to less than 200 without loss of functionality |
| 17:17.51 | brlcad | obviously not part of a summer's work, but it's the bigger picture |
| 17:18.50 | brlcad | most of the quick ref sheet commands should migrate as-is just for a starting reference point (unless someone tackles the refactoring sooner) |
| 17:19.11 | brlcad | that's about 10% |
| 17:22.30 | brlcad | bhinesley: once you get into the swing of things, it'd probably be helpful to set up a spreadsheet of all the commands on the quick ref sheet with columns for the name in mged, status of libged refactoring, archer name, etc |
| 17:22.52 | brlcad | then just work down the list |
| 17:24.35 | brlcad | that way we can be more certain of what has been looked at and migrated, what was migrated but renamed, what hasn't been migrated at all yet because it's a script or crap or irrelevant, and what just hasn't even been looked at yet |
| 17:25.08 | bhinesley | sounds good |
| 17:29.41 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:07.18 | CIA-105 | BRL-CAD: 03starseeker * r44240 10/geomcore/trunk/src/libgvm/ (gvm.h objects.c): This function should be returning the bu_external - let the calling function decide how to package it or use it. |
| 18:13.16 | CIA-105 | BRL-CAD: 03erikgreenwald * r44241 10/brlcad/trunk/src/librt/opennurbs_ext.h: remove inline calls that cause gcc3.4.6 to fail (needs review) |
| 18:18.15 | brlcad | those inline statements were required to keep 4.3 or 4.4 happy, compilation fail with --enable-optimized iirc |
| 18:18.36 | brlcad | maybe a pragma similar to what's in bu.h |
| 18:21.07 | ``Erik | hm, an emergency install this morning on the darkside went all wonky for indianlarry (rhel4), we can't give up gcc3 support just yet... which in bu.h? not seeing anything in there about gcc versions or anything related about inlines |
| 18:36.25 | *** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ) | |
| 18:39.03 | *** join/#brlcad Stattrav (~Stattrav@117.192.134.162) | |
| 18:39.03 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:43.23 | *** join/#brlcad Ralith (~ralith@d142-058-174-190.wireless.sfu.ca) | |
| 19:05.05 | brlcad | ``Erik: __BU_ATTR_* |
| 19:05.21 | brlcad | they're not (yet) protected because we haven't had one that was version-dependent |
| 19:06.38 | brlcad | as for the dark side, that's a configuration snafu -- gcc4 is installed, it's just not default ... ./configure CC=gcc4 |
| 19:07.59 | brlcad | aha, common.h -- that's where the version-specific logic is at, so bu.h could stay simple |
| 19:59.03 | CIA-105 | BRL-CAD: 03starseeker * r44242 10/geomcore/trunk/src/libgvm/ (gvm.h objects.c): (untested) check to see if an object is present in the repository |
| 20:59.25 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 21:34.29 | CIA-105 | BRL-CAD: 03starseeker * r44243 10/geomcore/trunk/src/libgvm/ (gvm.h objects.c): Completely untested (the add and delete logic is untested even in svntest) but start working on the commit logic) |
| 21:49.14 | CIA-105 | BRL-CAD: 03starseeker * r44244 10/brlcad/branches/STABLE/src/librt/primitives/bot/g_bot_include.c: sync STABLE to trunk r44240 |
| 21:53.48 | starseeker | http://arstechnica.com/tech-policy/news/2011/04/the-next-napster-copyright-questions-as-3d-printing-comes-of-age.ars |
| 22:04.29 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 22:51.03 | *** join/#brlcad Ralith (~ralith@d142-058-174-190.wireless.sfu.ca) | |
| 00:04.10 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 00:09.05 | kunigami_ | hi, I've updated my proposal on "shaders enhancements". commentaries are most welcome! |
| 00:19.00 | brlcad | kunigami_: hehe |
| 00:19.02 | brlcad | "write a small tutorial on how to write a tutorial on how to implement shaders" |
| 00:20.08 | brlcad | but ... I what if I need a tutorial on writing small tutorial on how to write a tutorial on how shaders are implemented? |
| 00:25.44 | kunigami_ | brlcad: oops let me correct that :P |
| 00:26.23 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601295.dsl.bell.ca) | |
| 00:33.31 | brlcad | kunigami_: so a few other comments and clarifications |
| 00:34.37 | brlcad | it doesn't necessarily have to go into your proposal now (though it will be useful pre-coding work), but you'll have to tell me more about their concept of closures |
| 00:35.27 | brlcad | as well as whether OSL actually evaluates / calculates the optical properties of a shader or whether it just describes a shader |
| 00:36.27 | kunigami_ | brlad: hmm, ok! I think I'll spend some more time playing with OSL tomorrow! |
| 00:37.30 | brlcad | a shader can be a completely abstract concept, so it's hard for me to imagine they actually implemented a system that takes a C-style text description and turns it into an actual working implementation .. but maybe, imageworks has a lot of resources |
| 00:38.20 | brlcad | returning a parametric representation sounds more plausible, but then how that interacts with a raytrace sounds very interesting |
| 00:39.15 | brlcad | kunigami_: one thing you can look at, on the wiki is a tutorial on shooting a ray with brl-cad -- that has no shader/optics, just returns a hit point |
| 00:39.26 | brlcad | you could use that with OSL as a proof-of-concept |
| 00:39.33 | brlcad | that might be something work milestoning |
| 00:39.38 | brlcad | s/might/would/ |
| 00:39.45 | brlcad | since it would show how the two interact |
| 00:41.00 | kunigami_ | hmm good idea! |
| 01:01.58 | brlcad | starseeker: I hope you meant sync TRUNK to stable and not stable to trunk... ;) |
| 01:08.43 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 01:11.53 | *** join/#brlcad crazy_imp (~mj@a89-182-6-68.net-htp.de) | |
| 01:17.13 | CIA-105 | BRL-CAD: 03brlcad * r44245 10/brlcad/trunk/include/ (bu.h common.h): add __BU_ATTR_ALWAYS_INLINE with a protection for gcc 3.4 and earlier where the always_inline attribute wasn't yet fully implemented (reportedly still works for some optimization options) |
| 01:19.27 | CIA-105 | BRL-CAD: 03brlcad * r44246 10/brlcad/trunk/src/librt/opennurbs_ext.h: |
| 01:19.27 | CIA-105 | BRL-CAD: use the new __BU_ATTR_ALWAYS_INLINE define so that we get forced inline behavior |
| 01:19.27 | CIA-105 | BRL-CAD: for newer gcc or forced off if older. the 'inline' keyword may be superfluous |
| 01:24.04 | brlcad | tick tock gsoc applicants! |
| 01:24.11 | brlcad | two days remaining |
| 02:00.52 | *** join/#brlcad PrezWhiteCalf (MK@whitecalf.net) | |
| 02:03.48 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) | |
| 02:16.53 | starseeker | er, yeah |
| 03:11.57 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 03:16.17 | bhinesley | brlcad: Part of my new plan is to migrate oed (modified for stateless use), which then opens the door for ill, sill, and consolidation of all the rot commands. I wanted to try and get your opinion before updating the proposal. |
| 03:25.17 | bhinesley | Also, I was hoping to include the consolidation of the rcc-* commands, which you mentioned was desirable. Can a naming convention be hashed out during the coding phase, or is that something that the proposal should address? |
| 03:53.25 | brlcad | bhinesley: the proposal doesn't have to have everything addressed, just a clear plan (even if the plan includes numerous research, design, and coding work) |
| 03:54.54 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 04:05.45 | bhinesley | okay; I'm submitting again. |
| 04:05.48 | brlcad | bhinesley: the plan to migrate oed sounds great but that will be a somewhat tricky on -- give yourself a good bit of time (a week or two) for just that one command |
| 04:06.23 | bhinesley | that should be just fine, I rear-loaded the milestones to give me a chance to tackle the tougher issues |
| 04:07.00 | brlcad | setting up some means to track your progress can be a milestone in itself |
| 04:07.30 | brlcad | (e.g., the spreadsheet idea) |
| 06:13.41 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:57.56 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:00.54 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 09:43.50 | *** join/#brlcad sachinjain (~sachin@117.211.88.150) | |
| 11:19.57 | CIA-105 | BRL-CAD: 03davidloman * r44247 10/geomcore/trunk/tests/ (20 files in 19 dirs): Split out tests into Functional and Unit dirs in prep for some unit test addition. |
| 11:37.36 | *** join/#brlcad Stattrav (~Stattrav@122.172.43.72) | |
| 11:37.36 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:03.09 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 13:33.12 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:42.34 | sachinjain | brlcad : can you tell me what are the two approaches that you told me earlier for the project "vector output from raytracing" |
| 13:43.25 | sachinjain | and I have also uploaded a patch on sourceforge as you told to do so |
| 13:43.41 | sachinjain | told me* |
| 13:48.01 | CIA-105 | BRL-CAD: 03starseeker * r44248 10/geomcore/trunk/tests/func/svntest/main.c: Work from respository root for commit, rather than assuming a particular model |
| 13:51.31 | CIA-105 | BRL-CAD: 03starseeker * r44249 10/geomcore/trunk/tests/func/CMakeLists.txt: tweak build to get it working... |
| 13:53.43 | sachinjain | isn't there any developer online? |
| 13:53.57 | CIA-105 | BRL-CAD: 03starseeker * r44250 10/geomcore/trunk/src/libgvm/objects.c: Will need to specify 'root' here as well |
| 13:59.30 | CIA-105 | BRL-CAD: 03starseeker * r44251 10/geomcore/trunk/src/libgvm/objects.c: Memory is in pool, but go ahead and dequeue list... |
| 14:16.26 | d_rossberg | sachinjain: now, yes |
| 14:17.41 | d_rossberg | ups, he quit |
| 14:18.24 | starseeker | he doesn't really seem to grasp the nature of IRC |
| 14:27.59 | ``Erik | or mebbe he pays by time or data xfer |
| 14:28.32 | ``Erik | (or has to use a cybercafe or school lab for internet access) |
| 14:47.19 | starseeker | screen + remote server |
| 15:04.26 | ``Erik | gotta have shell access on a remote server to do that :D |
| 15:05.22 | brlcad | they're at a uni .. chances are super-high that they have or could get access |
| 15:07.22 | ``Erik | I d'no, where I went, they started killing screens at night and then removed unix servers for NT ones (12 rs6k aix boxes took over 300 nt4 machines to meet needs), and he may've moved back home for the summer *shrug* not everyone has our level of access, 'sall I'm sayin' |
| 15:08.05 | CIA-105 | BRL-CAD: 03starseeker * r44252 10/geomcore/trunk/src/libgvm/ (CMakeLists.txt models.c): Add logic for adding a new model |
| 15:08.21 | ``Erik | might be worth asking his connection details before stating that he doesn't "get it" |
| 15:08.47 | brlcad | given the previous discussions, I'd still bet on him just not getting it or not being patient |
| 15:09.21 | starseeker | whatever his connection details, IRC is what it is - if he can't communicate on those terms that's OK, but then he should be using email |
| 15:09.33 | brlcad | everything you describe happened where I was at, but there was still a dozen ways I could have run a screen session |
| 15:09.51 | brlcad | you only have to find ONE .. which really isn't that hard |
| 15:10.35 | brlcad | starseeker: great point, IRC isn't an excuse given we have a mailing list |
| 15:16.21 | *** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no) | |
| 15:32.19 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 15:43.19 | *** join/#brlcad Stattrav (~Stattrav@117.192.145.3) | |
| 15:43.19 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:47.11 | CIA-105 | BRL-CAD: 03starseeker * r44253 10/geomcore/trunk/src/libgvm/models.c: add gvm_get_model implementation |
| 15:50.54 | *** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net) | |
| 16:06.20 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.135.83) | |
| 16:22.38 | CIA-105 | BRL-CAD: 03brlcad * r44254 10/brlcad/trunk/src/libbu/: timetester binary |
| 16:23.25 | CIA-105 | BRL-CAD: 03brlcad * r44255 10/brlcad/trunk/src/libpc/: ignore pc_test binary |
| 16:24.15 | CIA-105 | BRL-CAD: 03brlcad * r44256 10/brlcad/trunk/src/libbn/: ignore bntester binary |
| 16:26.56 | CIA-105 | BRL-CAD: 03r_weiss * r44257 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message trimmed) |
| 16:26.56 | CIA-105 | BRL-CAD: Added preprocessor commands to optionally disable nmg triangulation functions |
| 16:26.56 | CIA-105 | BRL-CAD: within nmg_tri.c that are not needed when new 'prototype' nmg triangulation code |
| 16:47.39 | CIA-105 | BRL-CAD: 03starseeker * r44258 10/geomcore/trunk/src/libgvm/models.c: restructure gvm_get_model to be simpler - don't really need callback. Start working on gvm_get_objs - this will be tricky since it's essentially a keep without the full database |
| 16:54.54 | CIA-105 | BRL-CAD: 03brlcad * r44259 10/brlcad/trunk/src/other/incrTcl/itcl/generic/itclInt.h: is the common.h header necessary here? builds clean without |
| 16:59.38 | *** join/#brlcad Stattrav (~Stattrav@117.192.154.206) | |
| 16:59.38 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:04.16 | brlcad | ``Erik: this is the one: http://www.tirerack.com/tires/tires.jsp?tireMake=Continental&tireModel=ExtremeContact+DWS |
| 17:05.57 | brlcad | http://www.e90post.com/forums/showthread.php?t=302424 |
| 17:10.03 | *** join/#brlcad Stattrav (~Stattrav@117.192.139.40) | |
| 17:10.03 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:13.11 | *** join/#brlcad Elrohir (~kvirc@p5B14AD98.dip.t-dialin.net) | |
| 17:17.23 | *** join/#brlcad Stattrav (~Stattrav@117.192.135.92) | |
| 17:17.23 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:18.00 | ``Erik | brlcad: these were the kind I had http://www.sears.com/shc/s/p_10153_12605_09543528000P?sid=IDx20070921x00003a&ci_src=14110944&ci_sku=09543528000P |
| 17:20.33 | ``Erik | then I went to http://www.tirerack.com/tires/tires.jsp?tireMake=Michelin&tireModel=Pilot+Sport&partnum=54YR8SPORTG1&vehicleSearch=false&fromCompare1=yes which were awesome |
| 17:20.57 | ``Erik | last rears I got, they ordered the wrong ones and I got http://www.tirerack.com/tires/tires.jsp?tireMake=Michelin&tireModel=Pilot+Sport+A%2FS+Plus&partnum=54YR8PSAS&vehicleSearch=false&fromCompare1=yes |
| 17:22.52 | brlcad | yeah, this is the review I was mentioning: http://www.consumersearch.com/tires/continental-extremecontact-dws |
| 17:23.00 | brlcad | definitely not the same tire :) |
| 17:24.45 | ``Erik | yeh, all season instead of summer... won't stick as well, but will last longer and do better in rain |
| 17:25.26 | brlcad | yeah, the michelin was what I was going to go with, though one step up, the pilot super sport |
| 17:26.08 | brlcad | http://www.michelinman.com/tire-selector/category/ultra-high-performance-sport/pilot-super-sport/tire-details |
| 17:26.18 | brlcad | but too long a wait, it's a new tire |
| 17:26.35 | brlcad | wasn't going to be available until next week, wanted something now |
| 17:27.14 | ``Erik | hm, longer treadlife than the ones I used to have, interesting |
| 17:27.17 | brlcad | we'll see how it goes, so far I'm loving them .. super comfortable and quiet ride, and holding grip well enough to still make me smile |
| 17:28.08 | ``Erik | ponders the pilot sport cup |
| 17:33.37 | CIA-105 | BRL-CAD: 03r_weiss * r44260 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 17:33.37 | CIA-105 | BRL-CAD: Added a prototype version of the function 'nmg_triangulate_fu' (nmg triangulate |
| 17:33.37 | CIA-105 | BRL-CAD: faceuse) to the file 'nmg_tri.c'. Added preprocessor commands to, by default, |
| 18:14.36 | CIA-105 | BRL-CAD: 03r_weiss * r44261 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message trimmed) |
| 18:14.36 | CIA-105 | BRL-CAD: Added the functions 'nmg_plot_fu', 'nmg_triangulate_rm_holes', |
| 18:14.36 | CIA-105 | BRL-CAD: 'nmg_triangulate_rm_degen_loopuse', and 'nmg_dump_model' to the file |
| 18:42.17 | CIA-105 | BRL-CAD: 03r_weiss * r44262 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message trimmed) |
| 18:42.17 | CIA-105 | BRL-CAD: Added a new prototype version of the function 'cut_unimonotone' to the file |
| 18:42.17 | CIA-105 | BRL-CAD: 'nmg_tri.c'. This function supports the new prototype function |
| 18:42.25 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 18:46.58 | CIA-105 | BRL-CAD: 03Markhobley 07http://brlcad.org * r2819 10/wiki/MGED_Commands: /* E */ |
| 19:05.53 | *** join/#brlcad Stattrav (~Stattrav@117.192.128.64) | |
| 19:05.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:13.11 | CIA-105 | BRL-CAD: 03r_weiss * r44263 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message trimmed) |
| 19:13.11 | CIA-105 | BRL-CAD: Updated function 'pick_pt2d_for_cutjoin' within file 'nmg_tri.c'. This update |
| 19:13.11 | CIA-105 | BRL-CAD: supports the new prototype function 'nmg_triangulate_fu' (nmg triangulate |
| 19:39.19 | CIA-105 | BRL-CAD: 03r_weiss * r44264 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message trimmed) |
| 19:39.19 | CIA-105 | BRL-CAD: Updated function 'is_convex' within file 'nmg_tri.c'. This update supports the |
| 19:39.19 | CIA-105 | BRL-CAD: new prototype function 'nmg_triangulate_fu' (nmg triangulate faceuse) and is |
| 19:41.22 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 19:51.30 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:04.29 | ``Erik | neat. incr fails now :D |
| 20:05.19 | starseeker | oh, now that I think about it I recall something similar when I tried a vanilla build of incr |
| 20:13.54 | CIA-105 | BRL-CAD: 03r_weiss * r44265 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mod.c: (log message trimmed) |
| 20:13.54 | CIA-105 | BRL-CAD: Updated function 'nmg_cut_loop' within file 'nmg_mod.c'. This update supports |
| 20:13.54 | CIA-105 | BRL-CAD: the new prototype function 'nmg_triangulate_fu' (nmg triangulate faceuse) and is |
| 20:39.04 | CIA-105 | BRL-CAD: 03r_weiss * r44266 10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c: |
| 20:39.04 | CIA-105 | BRL-CAD: Updated function 'nmg_classify_lu_lu' within file 'nmg_class.c'. This update |
| 20:39.04 | CIA-105 | BRL-CAD: supports the new prototype function 'nmg_triangulate_fu' (nmg triangulate |
| 21:05.49 | CIA-105 | BRL-CAD: 03r_weiss * r44267 10/brlcad/trunk/src/librt/primitives/nmg/nmg_info.c: |
| 21:05.49 | CIA-105 | BRL-CAD: Updated function 'nmg_2edgeuse_g_coincident' within file 'nmg_info.c'. This |
| 21:05.49 | CIA-105 | BRL-CAD: update supports the new prototype function 'nmg_triangulate_fu' (nmg triangulate |
| 21:15.03 | ``Erik | src/brlcad/src/other/tcl/generic/tclInt.h:56: error: conflicting types for 'ptrdiff_t' |
| 21:15.07 | ``Erik | <PROTECTED> |
| 21:17.16 | ``Erik | http://paste.lisp.org/display/121260 is the full one, I imagine that common.h was important |
| 21:23.44 | CIA-105 | BRL-CAD: 03r_weiss * r44268 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mod.c: |
| 21:23.44 | CIA-105 | BRL-CAD: Updated function 'nmg_lu_reorient' within file 'nmg_mod.c'. This update supports |
| 21:23.44 | CIA-105 | BRL-CAD: the new prototype function 'nmg_triangulate_fu' (nmg triangulate faceuse) and is |
| 21:34.40 | CIA-105 | BRL-CAD: 03r_weiss * r44269 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: |
| 21:34.40 | CIA-105 | BRL-CAD: Updated function 'nmg_isect_eu_fu' within file 'nmg_inter.c'. This update |
| 21:34.40 | CIA-105 | BRL-CAD: supports the new prototype function 'nmg_triangulate_fu' (nmg triangulate |
| 21:37.19 | *** join/#brlcad dli (~dli@132.205.216.21) | |
| 21:51.16 | CIA-105 | BRL-CAD: 03starseeker * r44270 10/geomcore/trunk/src/libgvm/models.c: Untested, but add some logic to pull the comb's tree and add its members (if they're something not already seen) to the hash |
| 22:04.42 | starseeker | well, good news and bad news about kermit |
| 22:04.59 | starseeker | bad news is the project is shutting down, good news is they're planning to BSD license it |
| 22:07.12 | *** join/#brlcad Elrohir (~kvirc@p5B14AD98.dip.t-dialin.net) | |
| 22:33.42 | starseeker | wonders if their terminal emulation code could do what we need on Windows... |
| 22:45.17 | starseeker | prods himself again to give this a try... http://www.projectpluto.com/win32a.htm |
| 22:54.06 | CIA-105 | BRL-CAD: 03starseeker * r44271 10/geomcore/trunk/src/libgvm/models.c: Once we have the objects in question, stick 'em on the list. |
| 22:56.04 | CIA-105 | BRL-CAD: 03starseeker * r44272 10/geomcore/trunk/src/libgvm/models.c: Oh, right - we had to get the bu_external already earlier, so no need to get it again. |
| 23:51.39 | CIA-105 | BRL-CAD: 03starseeker * r44273 10/geomcore/trunk/src/libgvm/ (gvm.h models.c): Clear out comment, add gvm_export_list to header. |
| 23:53.27 | CIA-105 | BRL-CAD: 03starseeker * r44274 10/geomcore/trunk/src/libgvm/models.c: Go with NULL to avoid confusion here, assuming that's viable |
| 00:22.52 | CIA-105 | BRL-CAD: 03starseeker * r44275 10/geomcore/trunk/src/libgvm/ (CMakeLists.txt files.c): Start working on .g file handling routines |
| 00:37.05 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 00:51.48 | CIA-105 | BRL-CAD: 03starseeker * r44276 10/geomcore/trunk/src/libgvm/ (files.c models.c): Make a stab at file export |
| 01:11.28 | *** join/#brlcad crazy_imp (~mj@a89-182-212-231.net-htp.de) | |
| 01:15.04 | *** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net) | |
| 03:16.24 | starseeker | hmm - X11 license: http://www.mozart-oz.org/ |
| 03:26.57 | brlcad | ``Erik: hm, k -- that'd be the common.h then |
| 03:27.17 | brlcad | will revert |
| 03:38.03 | CIA-105 | BRL-CAD: 03brlcad * r44277 10/brlcad/trunk/src/other/incrTcl/itcl/generic/itclInt.h: revert r44259 |
| 04:08.05 | *** join/#brlcad siddharth (~siddharth@117.211.88.150) | |
| 04:08.12 | siddharth | anyone here? |
| 04:54.44 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 06:09.28 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 06:43.47 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 06:53.12 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:02.50 | *** join/#brlcad Stattrav (~Stattrav@122.167.168.206) | |
| 07:02.50 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:47.16 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:26.42 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:16.15 | *** join/#brlcad Elrohir (~kvirc@p5B14BE4A.dip.t-dialin.net) | |
| 12:59.18 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 14:14.31 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 14:55.58 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 15:00.59 | CIA-105 | BRL-CAD: 03r_weiss * r44278 10/brlcad/trunk/src/libbn/plane.c: (log message trimmed) |
| 15:00.59 | CIA-105 | BRL-CAD: Added new prototype versions of the functions 'bn_isect_lseg3_lseg3' and |
| 15:00.59 | CIA-105 | BRL-CAD: 'bn_isect_line3_line3' to the file 'plane.c'. The names of these new function |
| 15:07.05 | CIA-105 | BRL-CAD: 03r_weiss * r44279 10/brlcad/trunk/include/bn.h: (log message trimmed) |
| 15:07.05 | CIA-105 | BRL-CAD: Updated the header file for libbn (i.e. bn.h) to include the definition of new |
| 15:07.05 | CIA-105 | BRL-CAD: prototype versions of the functions 'bn_isect_lseg3_lseg3' and |
| 15:15.23 | CIA-105 | BRL-CAD: 03r_weiss * r44280 10/brlcad/trunk/include/raytrace.h: |
| 15:15.24 | CIA-105 | BRL-CAD: Updated the header file 'raytrace.h' to include the definition of a new |
| 15:15.24 | CIA-105 | BRL-CAD: prototype function 'nmg_dump_model'. This new function is located in file |
| 16:08.50 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 16:37.48 | CIA-105 | BRL-CAD: 03starseeker * r44281 10/brlcad/branches/cmake/ (CMakeLists.txt src/vfont/CMakeLists.txt): If we have rpmbuild around, add the RPM generator to the package build |
| 17:01.30 | CIA-105 | BRL-CAD: 03starseeker * r44282 10/brlcad/branches/cmake/CMakeLists.txt: Minimize hard-coding - use CMAKE_INSTALL_PREFIX for this, if we can get away with it |
| 18:30.56 | *** join/#brlcad Stattrav (~Stattrav@117.192.131.161) | |
| 18:30.56 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:41.44 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 19:09.40 | CIA-105 | BRL-CAD: 03erikgreenwald * r44283 10/brlcad/trunk/sh/conversion.sh: If no OBJECTS are set, pass an explicit "-print" to search. This may be a bug in the ged_search implementation ("search ." is no longer legitimate). |
| 19:23.09 | brlcad | it is a bug |
| 19:31.41 | CIA-105 | BRL-CAD: 03erikgreenwald * r44284 10/brlcad/trunk/sh/conversion.sh: force posix output from time(1) |
| 19:32.09 | ``Erik | yup, talked to starseeker about it. *shrug* when it's fixed, we can remove the workaround |
| 19:34.39 | CIA-105 | BRL-CAD: 03starseeker * r44285 10/geomcore/trunk/src/libgvm/files.c: rough out logic to use a .g file as the basis for a commit update set. |
| 19:35.20 | CIA-105 | BRL-CAD: 03erikgreenwald * r44286 10/brlcad/trunk/src/libged/search.c: some notes on the workaround for the "search ." bug |
| 19:35.49 | ``Erik | man, if I get a two week surprise vacation, I'm going to have trouble remembering C :D I'm already doing bu_log("~d" |
| 19:45.24 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:53.42 | brlcad | is running a coverity scan on brl-cad right now |
| 19:54.18 | starseeker | sweet! |
| 19:59.35 | CIA-105 | BRL-CAD: 03starseeker * r44287 10/geomcore/trunk/src/libgvm/mem.c: Oh yeah, don't forget svn_cmdline_init |
| 20:00.23 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 20:03.59 | CIA-105 | BRL-CAD: 03erikgreenwald * r44288 10/brlcad/trunk/db/bldg391.asc: remove references to nonexistent regions (midwall.r equip) |
| 20:33.41 | CIA-105 | BRL-CAD: 03starseeker * r44289 10/geomcore/trunk/ (6 files in 3 dirs): Add a basic gvmtest program - not much working yet, but get it in there to make shakedown possible. |
| 20:56.17 | brlcad | aaaand, the first pass through the system seems to have gotten stuck in libfft, restarting build |
| 21:00.11 | CIA-105 | BRL-CAD: 03starseeker * r44290 10/geomcore/trunk/src/libgvm/files.c: If 0, use latest revision (will need to do this in other functions too) |
| 21:12.03 | CIA-105 | BRL-CAD: 0399.183.222.230 07http://brlcad.org * r2820 10/wiki/Talk:MGED_to_Archer_Command_Migration: Project Proposal for G-coding extension |
| 21:13.02 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 21:51.20 | CIA-105 | BRL-CAD: 03starseeker * r44291 10/geomcore/trunk/src/libgvm/files.c: For reasons that are not immediately clear, the wdb_close (or db_close) bomb out when trying to export the .g file. It's reporting bad magic, but not clear how that bad magic is coming about. |
| 21:53.10 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Talk:MGED to Archer Command Migration]]": inappropriate place to ask questions about gcode, linking to and external website is not cool |
| 22:06.09 | brlcad | 2139 compilation units (100%) are ready for analysis |
| 22:06.09 | brlcad | The cov-build utility completed successfully. |
| 22:06.14 | brlcad | woot! |
| 22:09.13 | bhinesley | That's pretty interesting, I hadn't heard of coverity. |
| 22:15.24 | *** part/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net) | |
| 22:15.31 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net) | |
| 22:16.33 | starseeker | OK, it's not the way the repository is being build, because svntest can reassemble that repository |
| 22:25.19 | CIA-105 | BRL-CAD: 03starseeker * r44292 10/geomcore/trunk/src/libgvm/objects.c: Hmm - interesting. Looks like the database needs externs even in cases where the lookup isn't finding anything - this resolves the crash |
| 01:12.14 | *** join/#brlcad crazy_imp (~mj@a89-182-23-46.net-htp.de) | |
| 02:35.00 | brlcad | outstanding .. coverity report took 2.5 hours to process, found a little under 2k issues |
| 02:35.27 | brlcad | spot-checking just a couple and they're valid (and outstandingly descriptive!) |
| 02:35.48 | brlcad | so this should be some pretty awesome homework |
| 02:42.19 | brlcad | I'll check next week into getting other accounts created so multiple people can work on fixing the defects |
| 04:27.47 | bhinesley | that's amazing |
| 04:28.03 | bhinesley | I'd love to see what that output looks like |
| 07:22.54 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:50.13 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 09:05.12 | *** join/#brlcad Stattrav (~Stattrav@117.192.133.79) | |
| 09:05.12 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:21.17 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.139.114) | |
| 10:26.26 | *** join/#brlcad mafm (~mafm@236.Red-83-55-205.dynamicIP.rima-tde.net) | |
| 12:53.46 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 14:07.47 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 14:20.16 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 14:25.07 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:39.36 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 14:58.34 | *** join/#brlcad Stattrav (~Stattrav@117.192.136.165) | |
| 14:58.34 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:06.52 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 15:16.15 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 16:38.27 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 17:47.00 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 18:39.08 | *** join/#brlcad Stattrav (~Stattrav@117.192.136.165) | |
| 18:39.20 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:52.05 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 19:52.51 | *** join/#brlcad kunigami (~kunigami@187.21.173.136) | |
| 20:23.12 | *** join/#brlcad kunigami_ (~kunigami@187.21.173.136) | |
| 21:38.25 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 22:04.01 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 22:10.09 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 22:11.43 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) | |
| 22:49.21 | *** join/#brlcad kunigami (~kunigami@187.21.173.136) | |
| 22:51.11 | *** join/#brlcad kunigami_ (~kunigami@187.21.173.136) | |
| 23:13.00 | *** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 23:49.45 | *** join/#brlcad kunigami (~kunigami@187.21.173.136) | |
| 01:08.25 | *** join/#brlcad Yoshi47 (~jan@d72-39-60-53.home1.cgocable.net) | |
| 01:11.55 | *** join/#brlcad crazy_imp (~mj@a89-182-14-73.net-htp.de) | |
| 01:44.59 | *** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net) | |
| 03:10.14 | *** join/#brlcad kunigami_ (~kunigami@187.21.173.136) | |
| 05:31.40 | *** join/#brlcad Stattrav (~Stattrav@117.192.144.40) | |
| 05:31.40 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:38.06 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 07:57.45 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 08:06.12 | *** part/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 08:51.19 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 08:51.19 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 ETA 20110401 || Welcome GSoC 2011 Students! Speak up, ask questions, start here: http://brlcad.org/wiki/Google_Summer_of_Code/2011 | |
| 09:35.31 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 09:40.20 | *** join/#brlcad adityag1 (~ADITYA@182.237.144.88) | |
| 10:08.34 | *** join/#brlcad mafm (~mafm@49.Red-83-38-34.dynamicIP.rima-tde.net) | |
| 10:14.21 | *** join/#brlcad kunigami (~kunigami@187.21.173.136) | |
| 10:15.57 | *** join/#brlcad kunigami (~kunigami@187.21.173.136) | |
| 10:46.30 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:04.39 | *** join/#brlcad kunigami (~kunigami@187.21.173.136) | |
| 11:18.18 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 11:18.37 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 11:31.06 | *** join/#brlcad kunigami_ (~kunigami@187.21.173.136) | |
| 11:40.31 | *** join/#brlcad mafm (~mafm@49.Red-83-38-34.dynamicIP.rima-tde.net) | |
| 11:47.11 | *** join/#brlcad kunigami_ (~kunigami@187.21.173.136) | |
| 11:53.17 | *** join/#brlcad kunigami_ (~kunigami@187.21.173.136) | |
| 11:57.48 | *** join/#brlcad kunigami (~kunigami@187.21.173.136) | |
| 11:59.18 | *** join/#brlcad kunigami__ (~kunigami@187.21.173.136) | |
| 12:19.50 | *** join/#brlcad kunigami (~kunigami@187.21.173.136) | |
| 13:18.31 | *** join/#brlcad merzo (~merzo@13-137-133-95.pool.ukrtel.net) | |
| 13:30.56 | *** join/#brlcad merzo (~merzo@13-137-133-95.pool.ukrtel.net) | |
| 14:05.49 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 14:10.32 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 14:36.37 | *** join/#brlcad Stattrav (~Stattrav@117.192.129.27) | |
| 14:36.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:53.00 | *** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net) | |
| 16:01.33 | *** join/#brlcad mafm (~mafm@49.Red-83-38-34.dynamicIP.rima-tde.net) | |
| 16:10.54 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 16:10.54 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 16:10.54 | *** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 16:27.05 | *** join/#brlcad mafm (~mafm@49.Red-83-38-34.dynamicIP.rima-tde.net) | |
| 16:27.11 | *** join/#brlcad dtidrow (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) | |
| 16:48.33 | *** join/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 16:48.38 | *** part/#brlcad adityag (~ADITYA@182.237.144.88) | |
| 18:22.33 | *** join/#brlcad mafm (~mafm@83.38.34.49) | |
| 00:29.23 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net) | |
| 01:11.40 | *** join/#brlcad crazy_imp (~mj@a89-182-208-255.net-htp.de) | |
| 03:26.39 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 03:33.43 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177680483.dsl.bell.ca) | |
| 04:36.10 | *** join/#brlcad stevegt` (~stevegt@cislunar.TerraLuna.Org) | |
| 07:31.23 | *** join/#brlcad Stattrav (~Stattrav@122.172.5.31) | |
| 07:31.23 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:49.21 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 09:09.48 | *** join/#brlcad mafm (~mafm@132.Red-81-35-69.dynamicIP.rima-tde.net) | |
| 09:25.05 | CIA-105 | BRL-CAD: 03jordisayol * r44293 10/brlcad/trunk/sh/ (make_deb.sh make_rpm.sh): Properly handle errors during GNU/Linux packages building. |
| 13:09.49 | dloman | yawns |
| 13:10.03 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 13:22.32 | brlcad | resists the yawn |
| 13:23.00 | brlcad | totally bummed though |
| 13:23.03 | brlcad | no furlough |
| 13:23.33 | dloman | had two big brown eyes staring at me starting at 0100. Youngest wouldn't sleep! |
| 13:23.59 | dloman | heh, speak for your self. I still have a paying job because of 'no furlough' ;) |
| 13:37.38 | ``Erik | vacation woulda been nice O.o |
| 13:37.57 | dloman | still a chance for it :) |
| 13:37.59 | ``Erik | brlcad: migration? accounts? |
| 13:54.32 | dloman | brlcad: was looking at VLB over the weekend and saw that a bu_vlb_write() call could potentially trigger a bu_realloc(). In order to know this ahead of time, the caller would need to know both the vlb's 'nextByte' and 'capacity'. bu_vlb_buflen serves to get the 'nextByte' but there's nothing for capacity. I was thinking about adding a bu_vlb_capacity() and/or bu_vlb_remaining() functions. Comments/concerns/tips ? |
| 13:58.40 | ``Erik | the struct is public and the math is trivial O.o |
| 14:00.00 | ``Erik | iirc, vlb's default to 4k 'chunks', so that's a straight up page mapping, quick and cheap on linux (not on fbsd/mac) |
| 14:01.20 | brlcad | dloman: sounds good to me |
| 14:01.36 | brlcad | should make the function name mirror the vls api, though |
| 14:01.46 | dloman | nods |
| 14:04.51 | brlcad | very curious that you'd need to know the size, though -- the mechanism by which the bytes are stored is supposed t be a black box |
| 14:05.14 | brlcad | could be a bu_list of individual bytes, for example, or some c++ construct or a static buffer |
| 14:05.33 | dloman | was looking at vlb_write and saw that there is a possiblity of a realloc |
| 14:05.55 | dloman | and without knowing capacity a head of time, you'll never know if that realloc will happen or not. |
| 14:06.01 | brlcad | so? |
| 14:06.07 | brlcad | anything that adds bytes is going to be a potential realloc |
| 14:06.18 | brlcad | part of the black box |
| 14:06.36 | dloman | would exposing the capacity break the black box mindset? |
| 14:06.54 | brlcad | pretty much |
| 14:07.04 | dloman | okie |
| 14:07.15 | brlcad | still, what does the realloc matter? |
| 14:07.17 | ``Erik | I think it's more "why do you care?" O.o reallocs aren't terribly slow on occasion |
| 14:07.27 | ``Erik | premature optimization? O.o |
| 14:08.14 | dloman | just trying to think ahead ;) |
| 14:08.37 | brlcad | or "a little knowledge is dangerous" |
| 14:09.05 | brlcad | std::string foo = "hello"; foo += "world"; may or may not cause a realloc too |
| 14:09.16 | brlcad | you don't know, shouldn't care -- vlb is the same |
| 14:09.23 | dloman | okie |
| 14:10.28 | ``Erik | (no forward motion on the server? I'm out today, thought maybe I could start a system update and get some stuff installed) |
| 14:10.59 | dloman | is bug fixing and generally de-stupifying things. |
| 14:12.44 | brlcad | ``Erik: noted, i'll create your account |
| 14:13.01 | brlcad | context switch thrashing a bit at the moment |
| 14:19.49 | brlcad | ``Erik: gmail |
| 14:20.45 | brlcad | was leaving those default passwords until accounts got migrated |
| 14:22.27 | brlcad | so the coverity scan is really frelling awesome |
| 14:33.41 | CIA-105 | BRL-CAD: 03starseeker * r44294 10/geomcore/trunk/src/libgvm/ (files.c objects.c): Hrm. Something strange - simply calling gvm_obj_in_model was enough to cause a crash - reorganizing the initializations in gvm_object_in_model was enough to make things work. |
| 15:03.58 | brlcad | if anyone is interested in actually working on fixing coverity bugs, let me know with an e-mail address to provide so I can get an account created (let me know via e-mail or PM) |
| 15:05.00 | brlcad | please don't bother if you're just interested or want to peek at results, rather not waste david's time |
| 15:05.09 | brlcad | or mine for that matter |
| 15:05.33 | brlcad | here's what some of the results look like, though: |
| 15:06.17 | brlcad | http://brlcad.org/tmp/cov1.png <-- detected potential null dereference |
| 15:06.31 | brlcad | http://brlcad.org/tmp/cov2.png <-- security issues |
| 15:07.20 | brlcad | http://brlcad.org/tmp/cov3.png <-- more elaborate (and awesome) detection of potentially uninitialized data being used |
| 15:07.44 | dloman | neato. |
| 15:07.47 | dloman | that a pay service? |
| 15:07.54 | brlcad | just a sample of the 2k or so issues reported |
| 15:08.12 | brlcad | it's paid for, but not something we're paying for |
| 15:08.52 | brlcad | DHS funded an initiative a few years ago to evaluate (and improve) security of open source software |
| 15:09.03 | dloman | =D |
| 15:09.04 | dloman | nice |
| 15:09.40 | dloman | so its "free" =D |
| 15:10.47 | brlcad | I applied and we were one of the first to get added to the scan ladder (when there were only a couple dozen being scanned), but our scan (of an old version) got stuck on a build failure in src/other |
| 15:11.05 | brlcad | wasn't fully resolved until the past friday |
| 15:11.55 | dli | brlcad, I can have a look on the coverity bugs, not sure how hard it is to fix them, without collateral damage at least |
| 15:12.28 | dli | brlcad, do you have some examples for me to digest |
| 15:12.39 | brlcad | dli: just screenshotted three :) |
| 15:13.36 | dli | brlcad, too bad. :( no text report? |
| 15:14.04 | brlcad | dli: what do you mean? |
| 15:14.41 | brlcad | there's a full-blown website around the report generated, pretty sure there are export options too -- but the website lets you manage the issues so you know which ones are fixed and which are not |
| 15:15.10 | brlcad | dli: can you not view images at the moment or something? |
| 15:15.39 | dli | brlcad, of course, I can view images |
| 15:16.26 | brlcad | then what's the "too bad"? |
| 15:17.34 | dli | brlcad, I expected a list with file locations, line numbers, and explanation of findings, etc. |
| 15:20.17 | dli | http://scan.coverity.com/all-projects.html |
| 15:20.26 | dli | not found |
| 15:21.28 | brlcad | dli: it has that list of files, explanations and a lot more |
| 15:21.36 | brlcad | the screenshots show three specific bugs |
| 15:22.37 | brlcad | I can dump out the various reports (there are many, all configurable) as csv, but that's not really effective for fixing them collaboratively |
| 15:22.49 | dli | brlcad, found, 178,135 lines, that will take ages to fix :( |
| 15:23.10 | brlcad | dli: that's the stalled scan |
| 15:23.18 | brlcad | that webpage hasn't been updated in years |
| 15:23.39 | brlcad | it found 690,667 lines |
| 15:23.41 | dli | brlcad, so, I have to sign in to get updated |
| 15:24.00 | brlcad | that's lines of code analyzed, not # issues |
| 15:24.15 | brlcad | it found 1892 issues, 700 of which are like cov2.png |
| 15:24.24 | CIA-105 | BRL-CAD: 03starseeker * r44295 10/geomcore/trunk/ (4 files in 2 dirs): Ah, there we go - got changes committed to the repository. Approaching full parity with the old svnTest example. |
| 15:25.05 | dli | brlcad, a link for cov2.png? |
| 15:25.26 | brlcad | points up |
| 15:26.45 | brlcad | those where the screenshots I mentioned |
| 15:27.50 | dli | brlcad, to fix like sscanf(), we use atof(), etc., right? |
| 15:33.13 | brlcad | dli: it depends, strtol/strtod with manual string parsing or regexp parsing are generally more robust to sanitizing input |
| 15:33.55 | starseeker | brlcad: in that case, should we pre-package some regex logic for the common parsing cases? |
| 15:33.56 | brlcad | preferred over the ato*() family of functions because they don't report error |
| 15:35.41 | dli | brlcad, but the idea is to replace all sscanf(), rather than trying to keep sscanf() safe by limiting buffer size, etc |
| 15:35.44 | brlcad | starseeker: bu routines that get values from strings would be useful (however the underlying mechanism does it) |
| 15:36.41 | brlcad | dli: to best solve the problem, yes |
| 15:36.56 | brlcad | the quickest solution is to just add precision specifiers like the comment states |
| 15:37.33 | brlcad | depending on how many there are, that could be a first step or could be skipped in leu of an API solution |
| 15:39.47 | dli | brlcad, I think I can help fixing the issues here |
| 15:40.12 | brlcad | e-mail me a username and an e-mail to give the coverity guys |
| 15:41.18 | dli | brlcad, using the sean address in topic? |
| 15:43.15 | dli | brlcad, sent |
| 15:45.37 | brlcad | thx |
| 15:47.50 | dli | brlcad, I will ask about ideas before actually fixing anything, my biggest fear is still the collateral damages :) |
| 15:48.19 | brlcad | okay, no worries |
| 15:49.25 | brlcad | i'll mostly be concerned with people actually using the coverity website when bugs are fixed so we don't get people wasting time looking into issues that have already been solved |
| 15:49.35 | brlcad | so using the various status markers they provide |
| 15:49.41 | brlcad | inspected, uninspected, fixed, etc |
| 15:51.31 | dli | brlcad, right, with so many lines to check, need an way to assign/partition |
| 15:54.07 | CIA-105 | BRL-CAD: 03starseeker * r44296 10/geomcore/trunk/src/libgvm/gvm.h: Nevermind these functions - handled in a couple for loops. Add them later if needed. |
| 15:54.07 | brlcad | nods |
| 15:54.41 | brlcad | some are downright trivial to fix, some are downright tricky logic |
| 16:09.00 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 16:26.24 | CIA-105 | BRL-CAD: 03starseeker * r44297 10/geomcore/trunk/src/libgvm/ (files.c gvm.h objects.c): Clear out a few more functions of dubious utility, assing some names to the commit actions. |
| 16:37.35 | CIA-105 | BRL-CAD: 03starseeker * r44298 10/geomcore/trunk/tests/func/gvmtest/main.c: |
| 16:37.35 | CIA-105 | BRL-CAD: Add a test to create an empty repo. May need to add one additional parameter to |
| 16:37.35 | CIA-105 | BRL-CAD: all these functions - the ability to pass a local subpool (presumably as a void |
| 16:47.56 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2821 10/wiki/Main_Page: add a section on code cleanup |
| 16:55.19 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2822 10/wiki/Code_Cleanup: stub in initial page, link to HACKING |
| 17:01.01 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2823 10/wiki/Code_Cleanup: coverity section |
| 17:05.19 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:CoverityExample1.png]]": Example Coverity scan issue showing a potential (albeit unlikely) NULL dereference |
| 17:25.24 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:CoverityExample2.png]]": Coverity analysis showing secure coding practice suggestions |
| 17:27.48 | CIA-105 | BRL-CAD: 03starseeker * r44299 10/geomcore/trunk/src/libgvm/objects.c: Er, oops - need a textdelta if we're going to add content... |
| 17:27.49 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:CoverityExample3.png]]": Coverity analysis showing an elaborate detection of a variable being used that was potentially uninitialized |
| 17:28.47 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2827 10/wiki/Code_Cleanup: link in the images and site |
| 17:29.55 | CIA-105 | BRL-CAD: 03starseeker * r44300 10/geomcore/trunk/src/libgvm/objects.c: Use the gvm_info_clear_objects function |
| 17:31.18 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2828 10/wiki/Code_Cleanup: add a section on code reduction and using simian |
| 17:31.19 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2829 10/wiki/Code_Cleanup: swap the order so lays out better |
| 17:33.14 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2830 10/wiki/Code_Cleanup: add an example of the output |
| 17:35.46 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2831 10/wiki/Code_Cleanup: break the long line |
| 17:46.46 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2832 10/wiki/Code_Cleanup: add one more section on strict compilation, yay TOC |
| 17:50.47 | CIA-105 | BRL-CAD: 03davidloman * r44301 10/geomcore/trunk/CMake/FindCppUnit.cmake: Check in a quick n dirty cmake find module for finding CppUnit |
| 17:53.48 | CIA-105 | BRL-CAD: 03davidloman * r44302 10/geomcore/trunk/ (4 files in 4 dirs): Setup cmake to find CppUnit if the UnitTests are enabled. Split out subdirectory addition for Functional and Unit test dirs. Stub in unit test dir CMakeList.txt |
| 18:06.05 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177680483.dsl.bell.ca) | |
| 18:10.32 | *** join/#brlcad Stattrav (~Stattrav@117.192.144.22) | |
| 18:10.32 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:04.39 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177680483.dsl.bell.ca) | |
| 19:14.17 | *** join/#brlcad mafm (~mafm@132.Red-81-35-69.dynamicIP.rima-tde.net) | |
| 19:27.46 | starseeker | hah - Manassas, Virginia |
| 19:43.47 | CIA-105 | BRL-CAD: 03davidloman * r44303 10/geomcore/trunk/tests/unit/ (4 files in 2 dirs): Wire in CppUnit to cmake build. Added a sample cmake unit test that will eventually be ByteBuffer's Unit Test. |
| 19:47.33 | CIA-105 | BRL-CAD: 03davidloman * r44304 10/geomcore/trunk/ (3 files in 2 dirs): Implement ByteBuffer. Combines the functionality of ByteArray and DataStream, since those were mostly redundant. ByteBuffer is backed by a bu_vlb and, at this point, is completely untested. |
| 19:57.19 | CIA-105 | BRL-CAD: 03starseeker * r44305 10/geomcore/trunk/src/libgvm/TODO: Add a TODO for libgvm |
| 20:16.54 | ``Erik | hrm? |
| 20:26.21 | starseeker | ``Erik: Tcl/Tk conference this year is in Virginia |
| 20:30.30 | ``Erik | ah, roger |
| 20:40.14 | *** join/#brlcad Stattrav (~Stattrav@117.192.144.22) | |
| 20:40.14 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:41.17 | brlcad | perfect nearby location for a presentation or three |
| 20:44.34 | brlcad | ``Erik: login worked? |
| 21:03.31 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:05.53 | brlcad | starseeker: did you make red delete or keep the original if the user edits the object name? |
| 21:06.28 | starseeker | uh... I thoght I made it delete the original, but not sure |
| 21:06.48 | brlcad | okay |
| 21:07.18 | brlcad | i was thinking about the usability implications of both and intent |
| 21:09.01 | brlcad | given cases where both might be expected, I'm thinking it'll be safer to err on keeping the original |
| 21:09.32 | starseeker | make it a cp, instead of a mv? |
| 21:09.43 | brlcad | basically |
| 21:09.50 | starseeker | that kind of violates the paradigm of "changing this object" we're using with red |
| 21:10.03 | starseeker | the fact we use a temp copy is an implementation detail, after all |
| 21:11.00 | brlcad | the tradeoff is make those expecting copies having to cp first vs. those expecting rename having to rm after |
| 21:12.19 | brlcad | that's only if you expect red to "change this object" ... I can just as easily see someone pulling up the text editor, and expecting the name change to mean "give me a copy using that object's values" |
| 21:12.55 | brlcad | more than likely with some value(s) changed |
| 21:13.12 | starseeker | as opposed to every other parameter in the text editor changing the original object? dunno, seems a bit inconsistent (not to say someone wouldn't expect it...) |
| 21:13.16 | brlcad | basically boils down to cp+ed vs ed+rm |
| 21:14.05 | brlcad | i'm not sure someone wouldn't expect it frankly |
| 21:14.10 | brlcad | there are good use cases for both |
| 21:14.41 | brlcad | and every other param wouldn't change the original, it applies to that copy |
| 21:15.18 | brlcad | you wouldn't edit the original AND make a copy .. that'd just be wrong |
| 21:15.39 | CIA-105 | BRL-CAD: 03starseeker * r44306 10/geomcore/trunk/ (3 files in 2 dirs): Grrrrr. Can't get recursive assembly to function. Am I hitting some issue with pool memory size or something? |
| 21:15.55 | starseeker | oh, I agree - I just was thinking in the paradigm of "if you red an object, you're working on that one object. Period" |
| 21:16.06 | brlcad | it's the intent of changing the object name, did they mean rename or did they mean make me a new one based on the original |
| 21:17.22 | brlcad | the other consideration is that even if they are thinking that way, that it should rename the original .. the only surprise is that the original object is still there and they have to manually delete it |
| 21:18.13 | brlcad | if they're thinking the other way, that it should make a copy .. then much to their surprise, the original is deleted (along with the destruction of any original values they maybe still wanted) |
| 21:19.26 | starseeker | could make two commands - red and rcp |
| 21:19.27 | brlcad | that alone is pretty strong case for not deleting, maybe adding a flag to red to force one behavior |
| 21:20.09 | starseeker | yeah, I suppose until we have undo support not deleting is safer |
| 21:23.15 | brlcad | of course, copy or move behavior will have to check if that object name already exists, and similarly abort (unless there's a force flag) |
| 21:24.21 | brlcad | ah, and I see you already have code for that, excellent |
| 21:27.05 | brlcad | hm, what's a similar command that has cp/mv options |
| 21:36.25 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 21:42.42 | CIA-105 | BRL-CAD: 03starseeker * r44307 10/geomcore/trunk/src/libgvm/ (files.c models.c): OK, that worked. Wasn't cleaning up after myself. See if I can put the content assignment back. |
| 21:45.18 | CIA-105 | BRL-CAD: 03starseeker * r44308 10/geomcore/trunk/src/libgvm/ (files.c models.c): Yep, that was it - just needed to clear the list. |
| 22:24.29 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 22:40.06 | brlcad | hello KimK |
| 22:40.39 | KimK | Hi brlcad, how's it going? |
| 22:40.47 | brlcad | pretty great! |
| 22:41.00 | KimK | Ha, excellent |
| 22:44.21 | KimK | You might be interested to know that I have now managed to install BRL-CAD on several machines, one defeated me, I'll look into that one again on a return visit there. Unfortunately, I'm no smarter on operating BRL-CAD yet, but I have stumbled across some tutorials, I hope to have time to work on those. |
| 22:48.16 | brlcad | KimK: outstanding |
| 22:48.30 | brlcad | yeah, the tutorials on the main website (under Documentation) is really the place to begin |
| 22:48.49 | brlcad | several of the documents listed there are very helpful for learning the basics |
| 22:55.40 | KimK | I have been trying to get the Ubuntu menu to start BRL-CAD. The LibreOffice-dev group has a similar problem, they start scripts to start the locally-built development versions. A developer friend gave me a little bash trick to put in the Ubuntu menu command to start them, example: bash -c 'cd /home/username/libo/install/program; ./swriter' But I haven't been able to apply it in the expected ways to start mged, I don't know what's up with that |
| 22:55.40 | KimK | . |
| 22:56.00 | KimK | Bah, flooded by one, need a character counter, lol! |
| 22:57.56 | brlcad | KimK: hm.. in more recent versions jordi sayol has menu and icons working for fedora and debian |
| 22:58.23 | brlcad | might check out the .deb to see how he did it |
| 22:58.41 | brlcad | (it's not in apt, it's up on the website) |
| 23:00.15 | KimK | More recent as in your development version? OK, no problem, I only installed from the 7.18 tarball. Do you guys have a git repo yet? |
| 23:00.32 | brlcad | 7.18.2 |
| 23:00.43 | KimK | OK, 7.18.2 |
| 23:00.51 | brlcad | no plans to move from svn to git any time soon |
| 23:01.46 | KimK | Oh, you're on svn? Maybe I can use "git svn". (Git is really nice.) |
| 23:01.58 | brlcad | quite familiar with git |
| 23:03.01 | KimK | Excellent, maybe git will be an option someday and you can advocate for it? |
| 23:04.57 | brlcad | if a revision control system needs advocating, then it's not mature enough yet for our use |
| 23:06.01 | brlcad | didn't advocate for cvs when switched from rcs, didn't advocate for svn when switched from svn ... the benefits were clear and downsides non-existent |
| 23:06.22 | brlcad | git doesn't have that case yet, several downsides |
| 23:06.44 | brlcad | maybe someday, but then maybe svn will have those features by then too or maybe some other system will have stepped up |
| 23:08.00 | KimK | What do you see as the downsides of git? Is svn in the group of one-repo cvs's, is that the issue? |
| 23:08.31 | brlcad | don't understand the second question |
| 23:09.29 | KimK | well, some are bothered by the idea that there's no "official central repo" in git (except by agreement or convention). |
| 23:09.53 | KimK | Any repo is equal to any other repo. |
| 23:09.58 | brlcad | that could be seen as a downside (or a benefit), depending on the community |
| 23:11.57 | brlcad | there are social impacts that are pretty extensively discussed, potential for community fragmentation, potentially increase in antisocial behavior (comparitively, since collaboration isn't forced) |
| 23:12.14 | brlcad | practical downside is the windows support, but that's improving |
| 23:13.12 | brlcad | the fact that it's a relatively new version control system, not nearly as extensively tested due to age alone |
| 23:14.21 | KimK | The EMC2 group hasn't had fragmentation problems that I have observed. They do have an agreed central repo. I would put decentralization in the benefit category, especially when there are internet connectivity issues, as might be expected more frequently now. (Earthquakes, tsunamis, sunspots, disasters, emp, what-have-you.) |
| 23:14.40 | brlcad | size of repo clone compared to checkout requires increased disk (particularly for large histories) |
| 23:15.09 | brlcad | that's a bit ridiculous imho :) |
| 23:15.21 | KimK | Ease of anyone browsing full history might be helpful? |
| 23:15.24 | brlcad | "might be expected more frequently now" .. no more or less than before unless people are just ignorant of the planet :) |
| 23:16.16 | brlcad | I think I can count on one hand how many times I've been offline and needing to commit over the past five years |
| 23:16.40 | brlcad | that would be a benefit, but it's minor (and it's also something that svn is working to implement too) |
| 23:16.52 | brlcad | in the end, I think the systems will become so hybridized that it just won't matter |
| 23:17.47 | brlcad | in which case, a central repo that can be distributed would win over a distributed repo pretending to be central |
| 23:18.01 | brlcad | but that's many many years out, of course |
| 23:18.52 | KimK | Well, git does have an impressive array of projects, even if you discount the Linux kernel one. (Admittedly some bias there, lol.) |
| 23:19.05 | brlcad | the point about switching, though, was that up until now, it's been very clear and strong benefits with NO downsides ... that's simply not the case quite yet |
| 23:19.12 | brlcad | popularity means nothing |
| 23:19.56 | brlcad | git tends to be the most vocal but by far not the most popular yet, last estimate I saw had it at maybe 20% (across industry) |
| 23:20.16 | brlcad | course stats can be fudged to show just about anything :) |
| 23:20.49 | KimK | Well, not completely nothing, it means that some groups saw an advantage to switching (to whatever). |
| 23:21.12 | brlcad | the fact that the benefits and downsides have to be weighed means it's closer to a wash .. which would simply be busy work right now |
| 23:21.19 | brlcad | not solving any specific problem we're having |
| 23:21.36 | KimK | Yes, well, you guys do have your hands full. |
| 23:21.54 | KimK | Hope it's going well, generally? |
| 23:22.01 | brlcad | it solves a big problem when the dev team scales beyond a communication point |
| 23:22.05 | brlcad | git, that is |
| 23:22.40 | brlcad | that point is around 50-100 active developers, if I recall correctly |
| 23:23.41 | KimK | Due to its history, are most brlcad developers in the US? I think that makes a difference too. |
| 23:23.42 | brlcad | I did the math a couple years ago, but it's basically the point at which NxM communication points slow down development where having a distributed infrastructure lets you have islands of communication |
| 23:24.33 | KimK | Not in the US, but in the same time zone, makes chatting difficult, or at least delays email. |
| 23:24.34 | brlcad | i don't think that makes any difference -- same issue with other communities I work with that are predominantly non-US |
| 23:25.24 | brlcad | if you have active devs, then the method and time of communication plays only a minor part .. they're reading logs, mailing lists, whatever |
| 23:25.28 | brlcad | impact is minimal |
| 23:25.53 | brlcad | it's the point at which there is too much activity, too many devs to have centralized communication |
| 23:26.08 | brlcad | that's the 50-100 dev metric |
| 23:26.19 | brlcad | that's why it was dead-obvious for linux |
| 23:26.27 | brlcad | hundreds of active devs |
| 23:27.40 | KimK | OK. Well, hopefully brlcad will continue to grow and you'll have more developers too. |
| 23:27.55 | brlcad | yeah, that's a problem I'd LIKE to have ;) |
| 23:28.42 | KimK | Haha, you'll get there. |
| 23:37.55 | brlcad | starseeker: on further inspection, red will also *create* a new combination (from nothing) .. so that seems even more pertinent that the editing intent is "write an object I've named with these values" and the in-editor object name might simply be them changing their mind on that name |
| 00:28.21 | starseeker | brlcad: sounds good |
| 01:09.49 | brlcad | woo hoo, got a full-blown red regression test working |
| 01:12.22 | *** join/#brlcad crazy_imp (~mj@a89-182-220-92.net-htp.de) | |
| 02:04.40 | brlcad | the bad news is that it's failing the regression test pretty hard |
| 02:58.02 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 03:55.13 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 04:18.30 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 04:43.40 | ``Erik | *readreadread* git? bah, darcs ftw |
| 05:51.25 | CIA-105 | BRL-CAD: 03brlcad * r44309 10/brlcad/trunk/regress/red.sh: add an extensive test of the mged 'red' command due to repeat failures. regression unveils at least 11 other bugs, quality, and robustness issues still remaining. |
| 05:52.10 | CIA-105 | BRL-CAD: 03brlcad * r44310 10/brlcad/trunk/regress/Makefile.am: add a 'red' rule to run the new red regression test, but don't add it to the release regression due to all of the bugs |
| 05:57.47 | CIA-105 | BRL-CAD: 03brlcad * r44311 10/brlcad/trunk/src/libged/red.c: add a -f force flag to forcibly overwrite a pre-existing comb if the new name would result in an existing object getting overwritten. also fixed a memory free crash bug if final_name is NULL. |
| 06:09.46 | CIA-105 | BRL-CAD: 03brlcad * r44312 10/brlcad/trunk/src/libged/red.c: blather a strong warning since several data-destructive bugs are now confirmed, but not enough time to fix before release. hopefully better to warn than disable since some use cases are fine. |
| 06:10.54 | CIA-105 | BRL-CAD: 03brlcad * r44313 10/brlcad/trunk/TODO: red no longer show-stopper, but still needs to be fixed. |
| 06:11.51 | *** join/#brlcad Stattrav (~Stattrav@122.172.5.31) | |
| 06:11.52 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:14.11 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 06:17.45 | CIA-105 | BRL-CAD: 03brlcad * r44314 10/brlcad/trunk/src/libged/red.c: one sec is probably plenty |
| 07:20.34 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 08:31.32 | *** join/#brlcad mafm (~mafm@85.Red-83-50-132.dynamicIP.rima-tde.net) | |
| 09:36.07 | starseeker | brlcad: nice work on the red regression |
| 09:36.22 | starseeker | sigh - at this rate, I should get to NURBS around August |
| 10:54.47 | *** join/#brlcad mafm_ (~mafm@85.Red-83-50-132.dynamicIP.rima-tde.net) | |
| 13:51.51 | CIA-105 | BRL-CAD: 03starseeker * r44315 10/geomcore/trunk/src/libgvm/files.c: Yes. Handle the global attribute values. |
| 14:24.35 | *** join/#brlcad crazy_imp (~mj@a89-182-220-92.net-htp.de) | |
| 14:30.13 | CIA-105 | BRL-CAD: 03starseeker * r44316 10/geomcore/trunk/src/libgvm/TODO: |
| 14:30.13 | CIA-105 | BRL-CAD: Undoubtedly there's a lot of polishing, API refactoring, and error checking to |
| 14:30.13 | CIA-105 | BRL-CAD: do still - however, the core features of .g file breakup, committing, |
| 14:56.28 | starseeker | dloman: if you're around, could you take a look at the current state of libgvm? |
| 14:57.40 | starseeker | It needs robustness testing (with near-certain bug repairs), error handling, etc. but the key abilities are there now, so if it doesn't look too daunting I'd like to toss it over to you and tackle some helpdesk stuff (search, etc...) |
| 15:16.44 | CIA-105 | BRL-CAD: 03erikgreenwald * r44317 10/geomcore/trunk/src/interfaces/cl/ (gvm.asd gvm.lisp): libgvm cffi |
| 15:32.38 | brlcad | starseeker: did you run it? |
| 15:33.24 | brlcad | starseeker: as long as you get to (and finish) nurbs before october, we're good ;) |
| 15:40.46 | dloman | starseeker: Im kinda around today. I'll take it from here if you need/want to get moving back to NURBs. |
| 16:27.00 | CIA-105 | BRL-CAD: 03brlcad * r44318 10/brlcad/trunk/ (NEWS include/conf/PATCH): beginning final release steps for 7.18.4, bump patch |
| 16:31.22 | CIA-105 | BRL-CAD: 03brlcad * r44319 10/brlcad/trunk/ChangeLog: update changelog for 7.18.4 |
| 16:51.13 | starseeker | brlcad: run the regression? not yet |
| 16:51.41 | brlcad | ok, just wondering |
| 16:56.05 | starseeker | dloman: cool, thanks - let me know if you have any questions |
| 16:56.32 | starseeker | brlcad: I'll take a poke at it today - wanted to get those last two things working for dloman |
| 17:01.47 | starseeker | brlcad: did you want to revert the search changes for the release? I'm not using them in the gvm code anymore so we could probably get away with that |
| 17:05.38 | CIA-105 | BRL-CAD: 03brlcad * r44320 10/brlcad/trunk/NEWS: typo |
| 17:19.45 | CIA-105 | BRL-CAD: 03starseeker * r44321 10/brlcad/branches/cmake/ (31 files in 15 dirs): MFC r44320 |
| 17:28.12 | CIA-105 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2833 10/wiki/User:Kunigami: Initial load |
| 17:30.05 | CIA-105 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2834 10/wiki/User:Kunigami: |
| 17:30.55 | CIA-105 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2835 10/wiki/User:Kunigami: |
| 17:38.44 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 17:45.53 | brlcad | starseeker: I'm about to tag, so probably not :P |
| 17:46.10 | starseeker | ah, k :-) |
| 17:55.12 | brlcad | http://www.siam.org/meetings/gdspm11/ |
| 17:55.18 | brlcad | deadlines approaching for submission |
| 17:55.27 | CIA-105 | BRL-CAD: 03erikgreenwald * r44322 10/brlcad/trunk/src/other/libpng/Makefile.am: add an empty depends rule |
| 17:57.55 | CIA-105 | BRL-CAD: 03brlcad * r44323 10/brlcad/branches/STABLE/ (30 files in 15 dirs): merge trunk to STABLE from r to HEAD r |
| 17:59.26 | brlcad | that wasn't very informative |
| 18:00.15 | starseeker | has flashbacks |
| 18:04.58 | CIA-105 | BRL-CAD: 03brlcad * r44324 10/brlcad/trunk/HACKING: requesting a specific log revision, -rHEAD, results in empty output so don't use it |
| 18:15.30 | CIA-105 | BRL-CAD: 03brlcad * r44325 10/brlcad/branches/STABLE/ (7 files in 5 dirs): merge trunk to STABLE from r44240 to HEAD r44324 ... not really, but previous branch commit had bad log message. should be up-to-date wrt r44324 |
| 18:23.27 | CIA-105 | BRL-CAD: 03brlcad * r44326 10/brlcad/tags/rel-7-18-4/: tag release 7.18.4 |
| 18:26.28 | CIA-105 | BRL-CAD: 03brlcad * r44327 10/brlcad/trunk/HACKING: add diagnostic lines to echo the PREV and CURR values so we know if anything changes |
| 18:36.49 | CIA-105 | BRL-CAD: 03starseeker * r44328 10/brlcad/branches/cmake/ (HACKING src/CMakeLists.txt src/other/libpng/Makefile.am): MFC r44327 |
| 18:41.00 | CIA-105 | BRL-CAD: 03brlcad * r44329 10/brlcad/trunk/ (NEWS README include/conf/PATCH): final testing of source tarball under way, bump to 7.18.5 in anticipation of 7.18.6 next month. |
| 18:55.20 | starseeker | blinks... can it be that simple?? |
| 18:56.23 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 18:58.31 | CIA-105 | BRL-CAD: 03starseeker * r44330 10/brlcad/trunk/src/libged/search.c: This needs more testing, but search . and the conversion.sh script seem to run with this change... |
| 19:02.59 | starseeker | brlcad: looks like search . and search / are back |
| 19:04.40 | starseeker | when you say "relative searching" in the search TODO item, how is search ./havoc -type r different from search . havoc -type r ? |
| 19:08.29 | brlcad | well the latter is invalid syntax, for one ;) |
| 19:11.02 | brlcad | "search ./havoc -type r" is the same as "search havoc -type r" as they are both relative paths, but different from "search /havoc -type r" |
| 19:13.38 | brlcad | fortuantely, any string of ./ and ../ prefixes can probably be ignored since the top-level namespace scope has no parent |
| 19:14.35 | brlcad | the more imporant feature is being able to specify relative subpaths at all, "search havoc/weapons -type r" to get a list of regions under weapons |
| 19:15.05 | brlcad | operationally equivalent to "search weapons -type r" unless/until operators are added that are matrix-sensitives |
| 19:16.24 | brlcad | so it should be possible to just determine if it's absolute (starts with /) or not, if it's not, then walk the basename object |
| 19:19.47 | *** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412) | |
| 19:19.56 | brlcad | that was a painful release |
| 19:22.33 | starseeker | how is it invalid syntax? search uses . and / to select whether to report a list of objects or full paths |
| 19:22.41 | ``Erik | hm, should "search . havoc -blah" invalid? if we model on find, it'd be silly but valid... I could see wanting to specify several trees in one line.. "search leftwing rightwing -name *fuel*' |
| 19:23.00 | starseeker | the latter will work now |
| 19:23.04 | starseeker | but will return full paths |
| 19:24.08 | starseeker | oh, conceptual mismatch. The way I have it implemented now, the leading . and / have nothing to do with the paths |
| 19:24.32 | starseeker | they might as well be -l and -f (list and fullpath) |
| 19:26.11 | starseeker | um. I'm not sure how matrix sensitive operations would work with the current find logic |
| 19:27.29 | starseeker | brlcad: if I understand you, you're expecting search havoc -type r to return a list, not full paths? |
| 19:39.01 | brlcad | oh, my bad -- I actually didn't know/remember that search/find supported multiple paths .. nifty! |
| 19:40.08 | brlcad | and yes, I'd expect a relative path (including plain object names) to return a list, not paths .. prefix it with a / and you get paths |
| 19:40.12 | brlcad | consistent, simple |
| 19:40.16 | brlcad | no new options |
| 19:41.18 | starseeker | erm |
| 19:42.03 | starseeker | that introduces a new problem - if I mix them, e.g. seach /obj1 obj2 do I then get back a mixed full path/list result? |
| 19:42.38 | starseeker | the . and / have the merit of being unambiguous in that respect |
| 19:42.39 | brlcad | that'd be the impliciation -- if technically infeasible, could just detect and abort |
| 19:44.39 | brlcad | with 'find', having '.' and '/' return paths (relative and absolute respectively), everything works out fine because we're working with a hierarchy and paths are paths |
| 19:45.39 | brlcad | for search, it's a bit more complicated since we're searching over a graph -- there would be no useful difference between '.' and '/' like there is with find since a "relative" geometry path means nothing useful |
| 19:46.21 | brlcad | that's the motivation for "make it useful" since the most common operation is "i'm looking for a list of objects matching my criteria" |
| 19:46.38 | brlcad | not paths, lists -- so hijack the otherwise useless relative option on search |
| 19:48.15 | starseeker | ponders... |
| 19:48.17 | brlcad | I mean, you could make them both work identically, but post-process each path set afterwards (basename+uniq for relative path sets) |
| 19:48.43 | starseeker | the simplest way to mix results would be to run one search per path and accumulate the results, but that means n searchs for n arguments |
| 19:49.04 | brlcad | sounds reasonable |
| 19:49.26 | brlcad | lets you sort/filter each path set independently so you can return paths and non-pathed lists as one set |
| 19:49.59 | brlcad | if they ran "search . /" you'd basically get a list of all objects followed by a list of all paths |
| 19:52.36 | starseeker | do we have any kind of "canonicalization" routine for db paths? |
| 19:53.12 | starseeker | e.g. /havoc/. -> /havoc? |
| 20:08.19 | *** join/#brlcad crazy_imp (~mj@a89-182-220-92.net-htp.de) | |
| 20:10.13 | brlcad | the default posix / bsd one should work |
| 20:10.27 | brlcad | it just looks at the string, not the filesystem |
| 20:10.40 | brlcad | we call it in a couple places to reduce paths |
| 20:11.44 | brlcad | supports harder cases like /havoc/weapons/../fuel_system/lt_fuel/../../fuel_system/. -> /havoc/fuel_system |
| 20:12.11 | brlcad | release is now posted and notified |
| 21:17.50 | starseeker | excellent! |
| 21:18.15 | starseeker | pwd |
| 21:18.17 | starseeker | whoops |
| 21:20.53 | CIA-105 | BRL-CAD: 03starseeker * r44331 10/brlcad/trunk/src/libged/search.c: Take a stab at using . and / prefixes to denote lists or full paths. This is a significant change to the search syntax and functionality, needs testing. Doesn't yet use the canonical logic to simplify paths. |
| 21:27.28 | CIA-105 | BRL-CAD: 03erikgreenwald * r44332 10/geomcore/trunk/src/interfaces/cl/gvm.lisp: add test function |
| 21:28.08 | starseeker | brlcad: let me know if that does what you want |
| 21:29.49 | CIA-105 | BRL-CAD: 03erikgreenwald * r44333 10/geomcore/trunk/src/interfaces/cl/brlcad.lisp: add some callback stuff. Start a facetize function. |
| 21:33.00 | CIA-105 | BRL-CAD: 03starseeker * r44334 10/brlcad/trunk/src/libged/search.c: While I'm at it, fix the print order of the results - toplevel first, then children. |
| 21:43.20 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net) | |
| 22:39.17 | CIA-105 | BRL-CAD: 03starseeker * r44335 10/brlcad/branches/cmake/ (5 files in 4 dirs): MFC r44334 |
| 23:44.51 | CIA-105 | BRL-CAD: 03starseeker * r44336 10/brlcad/trunk/ (include/bu.h src/libbu/vls.c src/libged/search.c): Try some scrubbing on user supplied paths. Not sure this is correct yet, but it does handle some cases. |
| 23:48.29 | starseeker | brlcad: ok, I think the search command is ready for you to see what's still broken :-P |
| 00:47.47 | *** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 01:12.23 | *** join/#brlcad crazy_imp (~mj@a89-183-84-47.net-htp.de) | |
| 03:08.37 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601162.dsl.bell.ca) | |
| 03:32.26 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601162.dsl.bell.ca) | |
| 03:33.21 | *** join/#brlcad Stattrav (~Stattrav@117.192.154.227) | |
| 03:33.21 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 04:14.05 | *** join/#brlcad Stattrav (~Stattrav@117.192.154.227) | |
| 04:14.14 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 04:44.42 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 05:14.51 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:26.36 | brlcad | outstanding, already an rtwizard failure reported |
| 07:10.21 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:21.29 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 07:57.58 | *** part/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 08:09.33 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 08:18.57 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 10:04.11 | dloman | Mernin |
| 10:11.32 | *** join/#brlcad mafm_ (~mafm@233.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 12:01.12 | d_rossberg | er, src/libged/search.c tries to access a non-existent "local" member of struct db_full_path_list |
| 12:33.14 | CIA-105 | BRL-CAD: 03davidloman * r44337 10/geomcore/trunk/tests/unit/test_runner.cxx: Update test_runner.cxx with header and footer. Make console printing a tad prettier. |
| 12:37.26 | CIA-105 | BRL-CAD: 03davidloman * r44338 10/geomcore/trunk/CMakeLists.txt: Add in check to root CMakeLists.txt that tests if CppUnit has been found or not. If not, configuration of the unit tests will not occur and a message will be printed to the console instead of a cmake failure. |
| 12:38.07 | starseeker | d_rossberg: whoops - maybe I didn't check in the header change |
| 12:38.09 | starseeker | let me check |
| 12:40.02 | CIA-105 | BRL-CAD: 03starseeker * r44339 10/brlcad/trunk/include/raytrace.h: whoops - helps to check in the headers too |
| 12:42.47 | CIA-105 | BRL-CAD: 03starseeker * r44340 10/brlcad/branches/cmake/ (. include/bu.h src/libbu/vls.c src/libged/search.c): MFC r44339 |
| 12:43.12 | CIA-105 | BRL-CAD: 03davidloman * r44341 10/geomcore/trunk/include/ByteBuffer.h: getMark() should be public, not protected. |
| 13:08.53 | CIA-105 | BRL-CAD: 03starseeker * r44342 10/brlcad/trunk/src/libged/search.c: Hmm - that only worked on the Mac. Go the safe route and put basename into a tmp string. |
| 13:09.54 | CIA-105 | BRL-CAD: 03starseeker * r44343 10/brlcad/branches/cmake/src/libged/search.c: MFC r44342 |
| 13:25.41 | ``Erik | iirc, basename fills a chunk of static memory and is not necessarily thread safe |
| 13:27.15 | ``Erik | wait, no, it returns a pointer into the memory passed to it, n/m |
| 13:33.46 | dloman | fwiw it looks like gcj hasn't been touched in about 2 years :/ |
| 13:35.41 | ``Erik | huh, yeh, sept 22, 2009 |
| 13:36.12 | ``Erik | last commit was 113 minutes ago |
| 13:36.28 | ``Erik | http://gcc.gnu.org/viewcvs/trunk/ |
| 13:36.36 | dloman | to the gcc trunk yeah |
| 13:36.41 | dloman | but gcj is a subset |
| 13:36.52 | ``Erik | libjava is 28 hours |
| 13:37.03 | dloman | yeah, but someone touched the makefile junk |
| 13:37.06 | dloman | thats it. |
| 13:38.33 | ``Erik | hm, poking around, it looks like it's maintenance mode |
| 13:38.55 | ``Erik | handful of commits in the last year, some new test stuff, but otherwise "done" |
| 13:39.05 | dloman | yeah, i looked also. according th the 'status page' there are some big holes in functionality |
| 13:39.13 | dloman | like NIO isn't implemented :/ |
| 13:39.29 | ``Erik | nio, even? hm, last I looked, the gui stuff was the gaping hole :/ |
| 13:39.57 | dloman | for the most part, it is the gui |
| 13:39.58 | CIA-105 | BRL-CAD: 03brlcad * r44344 10/brlcad/trunk/TODO: already a request from a user to test out the BoT TIE integration, via rtg3 or covart, so add a LIBRT_BOT_MINTIE environment variable as a means to enable it pervasively. |
| 13:40.12 | dloman | but i saw that .nio.* was also just an interface, no implementation. |
| 13:40.14 | dloman | so that sucks. |
| 13:40.32 | ``Erik | brlcad: as a getenv(), not just the -c cmd? |
| 13:42.10 | brlcad | yeah |
| 13:42.48 | ``Erik | where did the request come from? I don't see it in email or trackers |
| 13:42.58 | brlcad | like LIBRT_V4FLIP, src/librt/librt.3 |
| 13:43.30 | brlcad | it was a direct e-mail |
| 13:44.46 | CIA-105 | BRL-CAD: 03davidloman * r44345 10/geomcore/trunk/ (include/ByteBuffer.h src/utility/ByteBuffer.cxx): Convert some size_t's to int32_t since size_t does not necessarily mean unsigned int. |
| 13:45.06 | brlcad | bu_basename() has a patch pending that will require the caller to bu_free() |
| 13:45.18 | brlcad | to match behavior with bu_dirname() |
| 13:45.38 | brlcad | (they don't match dirname()/basename() but it let them be thread-safe) |
| 13:45.48 | brlcad | at least re-entrant |
| 13:47.20 | CIA-105 | BRL-CAD: 03davidloman * r44346 10/geomcore/trunk/tests/unit/ (3 files in 2 dirs): Implement a few unit tests to get the feel for CPPUnit. |
| 13:47.50 | brlcad | dloman: heh, int32_t definitely doesn't mean unsigned int either :) |
| 13:47.58 | brlcad | uint32_t would though |
| 13:47.58 | dloman | righto |
| 13:48.21 | dloman | that's what i mean :) commit entry was poorly worded. |
| 13:49.32 | brlcad | size_t should be used when the value is meant to represent a "size" (i.e. unsigned 0->whatever) |
| 13:50.44 | CIA-105 | BRL-CAD: 03erikgreenwald * r44347 10/brlcad/trunk/src/librt/dir.c: if the LIBRT_BOT_MINTIE environment variable is set, try to update the corrosponding global (direct email request to brlcad@ |
| 13:50.46 | brlcad | why would a bytebuffer be specific about using 32-bit return values? smells wrong |
| 13:51.23 | dloman | need something that can return a -1 |
| 13:51.26 | brlcad | at a glance, getMark() sounds more like an off_t |
| 13:51.53 | brlcad | if it's still a size, ssize_t |
| 13:52.07 | brlcad | if it's a range offset, off_t |
| 13:52.21 | dloman | ssize_t == signed size_t ? |
| 13:52.28 | brlcad | yep |
| 13:52.40 | CIA-105 | BRL-CAD: 03erikgreenwald * r44348 10/brlcad/trunk/src/libged/search.c: hoise declarations before body, C90 does not allow mixing. |
| 13:52.54 | dloman | its a position.... so does that make it an range offset? |
| 13:53.48 | ``Erik | brlcad: in rt_dirbuild(), I'm assuming that is adequate for <third party>'s needs? |
| 13:54.08 | brlcad | having functions return values do double-duty with error values and values mixed fell out of stylistic favor a while ago, but is still fairly common -- ssize_t was added for that purpose to describe some of the legacy I/O calls (e.g., man 2 write) |
| 13:54.55 | brlcad | ``Erik: could just pull the getenv() during prep, avoid setting the global altogether |
| 13:55.42 | dloman | getMark() simply returns the 'marker' that the user set in the ByteBuffer. if its not set, getMark() returns -1 |
| 13:55.45 | brlcad | if (rt_bot_mintie > val || LIBRT_BOT_MINTIE > val || ...) tie prep |
| 13:56.17 | brlcad | dloman: would a marker of -32 work? |
| 13:56.54 | dloman | work as in 'is a marker of -32 valid' ? in that case, no |
| 13:57.29 | brlcad | then probably not an off_t |
| 13:57.39 | dloman | kk |
| 13:57.40 | brlcad | ssize_t |
| 13:57.49 | dloman | gets it now. duh, lol |
| 13:58.13 | ``Erik | wanted to avoid a slew of getenv() calls |
| 13:58.44 | brlcad | aren't they basically free? |
| 13:59.09 | ``Erik | um, any sane shell would save them in a trie, but it'll be a few syscalls |
| 13:59.15 | brlcad | already loaded into mem, just scans the array with string compares |
| 14:01.06 | brlcad | yeah, there's an environ[] global that is set up during binary init |
| 14:01.16 | brlcad | shouldnt' be syscalls |
| 14:01.54 | brlcad | http://pubs.opengroup.org/onlinepubs/009695399/functions/getenv.html says a few things about performance, nothing too insightful other than it "should" be fast |
| 14:03.12 | ``Erik | other than cognitive locality, is there any benefit to placing it in the primitive prep? |
| 14:03.37 | brlcad | also have the downside for long-running apps that might run some traces, stay running with the db still open, set the var, then run some more |
| 14:03.45 | ``Erik | it's already a global due to how rt -c works |
| 14:04.29 | brlcad | db_open() isn't a bad choice, it can probably work |
| 14:05.04 | brlcad | I'd just think you'd want it closer to the actual decision point (until it's observed / measured that performance is a problem) |
| 14:05.08 | brlcad | premature and all that :) |
| 14:05.42 | ``Erik | hm, I went with rt_dirbuild() because it seemed like the closest decision point... a converter will call db_open() without needing to prep *shrug* |
| 14:06.01 | brlcad | oop, I meant dirbuild |
| 14:07.34 | ``Erik | *shrug* if you want to make a todo to discuss it, that's cool. if we move it and it impacts my isst stuff, I'll bitch/moan/complain/etc :D |
| 14:08.37 | ``Erik | I'm not above saying "if you want it, change your rtg3/covart stuff" (this is the ohio office?) |
| 14:09.55 | ``Erik | if they test it, it'll break and I'll have to fix it :/ I'm running into cmake issues with gtk+2, so I can't give it the testing I'd like to just yet |
| 14:11.03 | brlcad | if it moved and impacted, it'd get moved back right away .. that'd be the "observed" problem :) |
| 14:11.42 | dloman | okay, most systems have htons and htonl, but is there any 'standard' support for 64 bit ints? |
| 14:11.46 | brlcad | the user's desire to test it isn't our concern until you give it the "thumbs up, seems to be working fine for me, I'm done" stamp of approval |
| 14:11.57 | brlcad | that's why the release notes said it was preliminary |
| 14:12.24 | brlcad | the flag is more "oh yeah, that'd be a great way to toggle it on/off for everyone, even after it's all done and working" |
| 14:12.56 | brlcad | dloman: in libbu there is |
| 14:13.07 | brlcad | otherwise no |
| 14:13.07 | dloman | kk, am checking there atm, thanks. |
| 14:13.49 | brlcad | dloman: nothing so fancy, #include "bu.h" and just call ntohll() or htonll() |
| 14:15.03 | dloman | brlcad: would you recommend using the fns for floats and doubles as well? |
| 14:15.29 | brlcad | what are you doing? |
| 14:15.44 | dloman | cleaning up the network serializer stuff |
| 14:15.53 | brlcad | libbu implements htonf() htond() ntohf() ntohd() |
| 14:19.06 | CIA-105 | BRL-CAD: 03starseeker * r44349 10/brlcad/branches/cmake/ (TODO src/libged/search.c src/librt/dir.c): MFC r44348 |
| 14:27.18 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 14:35.43 | *** join/#brlcad willdye (~willdye@198.183.6.23) | |
| 14:39.31 | CIA-105 | BRL-CAD: 03davidloman * r44350 10/geomcore/trunk/ (include/ByteBuffer.h src/utility/ByteBuffer.cxx): use of int32_t for ByteBuffer::mar was wrong. use ssize_t instead. Also, implemented put16Bit() and get16Bit() |
| 14:41.17 | CIA-105 | BRL-CAD: 03davidloman * r44351 10/geomcore/trunk/src/utility/ByteBuffer.cxx: No need to increment 'position' since bu_vlb_write already does this. |
| 14:44.30 | ``Erik | hm, 'ceylon' O.o |
| 14:46.58 | dloman | ? |
| 14:49.56 | ``Erik | http://blog.talawah.net/2011/04/gavin-king-unviels-red-hats-top-secret.html |
| 14:51.00 | dloman | that a play on Cylon? |
| 14:51.24 | CIA-105 | BRL-CAD: 03d_rossberg * r44352 10/rt^3/trunk/include/ (MinimalDatabase.h brlcad/ConstDatabase.h brlcad/Object.h): |
| 14:51.25 | CIA-105 | BRL-CAD: cleaned up to revision 44007 |
| 14:51.25 | CIA-105 | BRL-CAD: - removed unused includes from ConstDatabase.h (moved them to MinimalDatabase.h, maybe they are important there) |
| 14:51.56 | ``Erik | redhat has a plan. |
| 14:53.03 | starseeker | how do they plan to get all the existing java code over to Ceylon though? |
| 14:53.39 | starseeker | we can't even get IE6 to die - I doubt anything will prompt businesses to rewrite key Java code |
| 14:54.36 | ``Erik | it's "enterprisy" and on the jvm, groovy was too 'hippy' *shrug* |
| 14:54.57 | starseeker | is the jvm fully open source? |
| 14:55.23 | ``Erik | last I heard, the only turd left was in the sound code? |
| 14:55.34 | starseeker | hmm' |
| 14:56.19 | ``Erik | well, the only technical turd... the new ownership is a big steaming pile... O:-) |
| 14:57.03 | starseeker | interesting: http://vmkit.llvm.org/ |
| 14:57.37 | ``Erik | you saw that apple has thrown in with the llvm crowd after gcc went gplv3? |
| 14:57.56 | starseeker | yep |
| 14:58.38 | starseeker | could be a very good thing |
| 14:59.31 | starseeker | only problem I know of at the momemt is that clang isn't quite there performance wise compared to gcc |
| 14:59.42 | ``Erik | mebbe, hopefully apple still has some top tier talent, even though they just had another 'great exodus' |
| 14:59.51 | starseeker | did they? |
| 15:00.02 | starseeker | hadn't heard |
| 15:00.03 | ``Erik | well, mebbe 5ish years ago |
| 15:00.10 | starseeker | oh, the BSD guys? |
| 15:00.15 | ``Erik | hubbard, perlstein, etc |
| 15:00.16 | ``Erik | yeah |
| 15:01.19 | starseeker | well, so far it looks like they're doing a decent job |
| 15:01.52 | starseeker | a robust compiler toolkit with most of industry behind it and a BSD license strikes me as a Good Thing - everybody benefits |
| 15:02.42 | starseeker | seeing as there's not much of a commerical compiler market outside of specialized applications, it's in the interests of most companies to make a common substrate as good as possible |
| 15:03.14 | ``Erik | icc is proprietary, right? |
| 15:03.27 | starseeker | and Apple's gcc fork is going to stray further and further from gcc proper, so it'll just get more and more annoying |
| 15:03.30 | starseeker | I believe so |
| 15:04.02 | ``Erik | of anyone who would benefit, intel would be the obvious choice... they're starting to smell like 80's ibm :/ |
| 15:05.26 | starseeker | they must get enough licenses to make it worthwhile |
| 15:05.52 | starseeker | I suppose for companies shipping binaries, the cost is no big deal and they want the speedup |
| 15:06.52 | starseeker | dunno though - modern PCs seem fast enough that the difference would only be user visible in select cases |
| 15:33.46 | CIA-105 | BRL-CAD: 03starseeker * r44353 10/brlcad/trunk/src/libged/search.c: Unlike find, we won't insist on a path if we're given options - if we have options but no path, assume '.' |
| 15:34.48 | CIA-105 | BRL-CAD: 03starseeker * r44354 10/brlcad/branches/cmake/src/libged/search.c: MFC r44353 |
| 16:13.19 | CIA-105 | BRL-CAD: 03starseeker * r44355 10/brlcad/trunk/doc/docbook/system/mann/en/search.xml: Update search documentation |
| 16:13.58 | CIA-105 | BRL-CAD: 03starseeker * r44356 10/brlcad/branches/cmake/doc/docbook/system/mann/en/search.xml: MFC r44355 |
| 16:26.05 | starseeker | brlcad: hrm. I can't get the red tests to work - they're trying to fire off emacs for some reason |
| 16:33.38 | starseeker | oh, I have to set EDITOR to cat |
| 16:48.05 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:13.39 | ``Erik | hm, I saw that on fbsd, but mac worked ok |
| 17:14.38 | ``Erik | wonders if anything is still going on with googles 'go' O.o |
| 17:32.33 | dloman | http://i.imgur.com/y7Hm9.jpg |
| 17:55.37 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 18:07.10 | CIA-105 | BRL-CAD: 03r_weiss * r44357 10/brlcad/trunk/src/libbn/plane.c: (log message trimmed) |
| 18:07.11 | CIA-105 | BRL-CAD: Corrected a bug in function 'bn_isect_lseg3_lseg3_new' in file 'plane.c' within |
| 18:07.11 | CIA-105 | BRL-CAD: the libbn library. This is a prototype version of the function |
| 19:06.09 | starseeker | brlcad: aha - ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/devel/bmake/files/realpath.c |
| 19:08.48 | CIA-105 | BRL-CAD: 03starseeker * r44358 10/brlcad/branches/cmake/regress/CMakeLists.txt: Add CMake code to run the red regression, but don't add it to the general regress target for now since a) red doesn't pass and b) something funny is happening with the EDITOR being called |
| 19:13.09 | CIA-105 | BRL-CAD: 03starseeker * r44359 10/brlcad/trunk/ (include/bu.h src/libbu/vls.c src/libged/search.c): OK, no halfway measures. Going to need a full-on path resolution function. |
| 19:21.43 | CIA-105 | BRL-CAD: 03davidloman * r44360 10/geomcore/trunk/tests/unit/utility/ (ByteBufferUTest.cxx ByteBufferUTest.h): Complete implementation of the ByteBufferUTest class. |
| 19:23.23 | CIA-105 | BRL-CAD: 03davidloman * r44361 10/geomcore/trunk/ (include/ByteBuffer.h src/utility/ByteBuffer.cxx): Unit test immediately reveled some bugs with ByteBuffer's behavior. Fixt. |
| 19:33.45 | *** join/#brlcad Raz_Lobo (~razer@178.139.103.130) | |
| 19:38.35 | Raz_Lobo | hi all, I have a problem during deb package built of Brlcad-7.18.4 on PowerPC architecture. |
| 19:38.41 | Raz_Lobo | Copy from console: |
| 19:38.59 | Raz_Lobo | gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../src/other/tcl/generic -I../../src/oBS -I../../src/other/libz -pedantic -W -Wall -Wundef -Wfloat-equal -Wshadow -Winline -Wnc -W -Wall -Wundef -Wfloat-equal -Wshadow -Winline -Wno-long-long -c bntester.c |
| 19:38.59 | Raz_Lobo | cc1: warnings being treated as errors |
| 19:38.59 | Raz_Lobo | bntester.c: In function ‘main’: |
| 19:38.59 | Raz_Lobo | bntester.c:190:5: error: comparison is always true due to limited range of data type |
| 19:38.59 | Raz_Lobo | make[3]: *** [bntester.o] Error 1 |
| 19:39.06 | Raz_Lobo | Someone can help me? |
| 19:39.38 | starseeker | Raz_Lobo: Try adding --disable-strict to the configure flags |
| 19:40.27 | Raz_Lobo | ok, thanks so much, so fast. ^_^ |
| 19:40.28 | Raz_Lobo | I try. |
| 20:21.16 | brlcad | starseeker: hmm.. you shouldn't have needed to set editor to cat |
| 20:23.52 | starseeker | ``Erik was seeing issues with that too |
| 20:25.34 | brlcad | also, ftp://ftp.irisa.fr/pub/OpenBSD/src/lib/libc/stdlib/realpath.c |
| 20:26.01 | *** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net) | |
| 20:26.20 | brlcad | the more I think about it, the more I lean towards that deserving to be a librt function, not libbu |
| 20:27.07 | brlcad | since the minimal case right now isn't arbitrary path reduction, it's geometry path reduction |
| 20:27.29 | brlcad | also sets the stage for later if "symbolic link" objects get added |
| 20:27.52 | starseeker | arrgh :-P |
| 20:28.02 | starseeker | is 4/5 of the way to a bu_normalize |
| 20:28.14 | brlcad | hehe, you still need every bit of that for the rt func |
| 20:28.55 | starseeker | let me get this going first, then we can move it |
| 20:29.01 | brlcad | yeah keep on then, not a big deal |
| 20:31.11 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:39.25 | CIA-105 | BRL-CAD: 03starseeker * r44362 10/brlcad/trunk/ (include/bu.h src/libbu/brlcad_path.c src/libged/search.c): Try again, this time with a realpath based path normalization |
| 20:44.48 | CIA-105 | BRL-CAD: 03starseeker * r44363 10/brlcad/branches/cmake/ (5 files in 4 dirs): MFC r44362 |
| 20:56.57 | CIA-105 | BRL-CAD: 03starseeker * r44364 10/brlcad/trunk/ (4 files in 2 dirs): Move db_path.c to db_fullpath.c |
| 21:06.00 | CIA-105 | BRL-CAD: 03starseeker * r44365 10/brlcad/trunk/ (7 files in 4 dirs): Take a stab at making bu_normalize into db_normalize |
| 21:15.51 | CIA-105 | BRL-CAD: 03starseeker * r44366 10/brlcad/trunk/src/librt/db_path.c: Opps, headers are a good thing. |
| 21:18.19 | CIA-105 | BRL-CAD: 03starseeker * r44367 10/brlcad/branches/cmake/ (9 files in 4 dirs): MFC r44366 |
| 21:27.20 | CIA-105 | BRL-CAD: 03starseeker * r44368 10/brlcad/trunk/src/libged/search.c: remove debug line |
| 21:58.39 | *** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 22:45.31 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 01:12.10 | *** join/#brlcad crazy_imp (~mj@a89-182-198-172.net-htp.de) | |
| 01:19.31 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 04:02.12 | CIA-105 | BRL-CAD: 03brlcad * r44369 10/brlcad/trunk/src/libbn/bntester.c: bu_getopt() returns an int, not a char -- should resolve 'comparison is always true' failure (strict catches another bug). |
| 04:04.36 | CIA-105 | BRL-CAD: 03brlcad * r44370 10/brlcad/trunk/src/libbn/bntester.c: there is no reason for these variables to be declared static. main() is not reentrant or used recursively. |
| 04:05.59 | CIA-105 | BRL-CAD: 03brlcad * r44371 10/brlcad/trunk/src/libbn/bntester.c: ws indent consistency cleanup |
| 04:06.52 | CIA-105 | BRL-CAD: 03brlcad * r44372 10/brlcad/trunk/src/libbu/getopt.c: |
| 04:06.52 | CIA-105 | BRL-CAD: The getopt() function was once specified to return EOF instead of -1. This was |
| 04:06.52 | CIA-105 | BRL-CAD: changed by IEEE Std 1003.2-1992 (POSIX.2'') to decouple getopt() from <stdio.h>. |
| 04:13.01 | CIA-105 | BRL-CAD: 03brlcad * r44373 10/brlcad/trunk/include/bu.h: document the complex return values that may result from bu_getopt() (borrowed and adapted from the getopt() manual) |
| 04:36.29 | CIA-105 | BRL-CAD: 03brlcad * r44374 10/brlcad/trunk/ (249 files in 41 dirs): |
| 04:36.29 | CIA-105 | BRL-CAD: bu_getopt() function used to return EOF instead of -1. For getopt(), this was |
| 04:36.29 | CIA-105 | BRL-CAD: changed by IEEE Std 1003.2-1992 (POSIX.2'') to decouple getopt() from <stdio.h>. |
| 06:40.17 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601162.dsl.bell.ca) | |
| 06:42.10 | CIA-105 | BRL-CAD: 03d_rossberg * r44375 10/rt^3/tags/rel-7-18-4/: |
| 08:40.13 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 09:15.28 | *** join/#brlcad Stattrav (~Stattrav@117.192.140.159) | |
| 09:15.28 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:27.16 | *** join/#brlcad mafm_ (~mafm@193.153.199.229) | |
| 09:36.06 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 11:21.58 | CIA-105 | BRL-CAD: 03davidloman * r44376 10/geomcore/trunk/ (4 files in 3 dirs): Add getString and putString to ByteBuffer class. ByteBuffer class should now be a complete replacement for DataStream and ByteArray classes. Replacements to follow. |
| 11:36.13 | dloman | anyone: Are there help functions anywhere in the BRLCAD libs for getting/setting individual bits ? |
| 11:38.50 | dloman | (or do i need to roll my own) |
| 11:48.44 | *** join/#brlcad crazy_imp (~mj@a89-182-198-172.net-htp.de) | |
| 12:10.57 | CIA-105 | BRL-CAD: 03davidloman * r44377 10/geomcore/trunk/ (include/ByteBuffer.h src/utility/ByteBuffer.cxx): Add toHexString() to ByteBuffer. Aids in troubleshooting. |
| 12:23.04 | CIA-105 | BRL-CAD: 03davidloman * r44378 10/geomcore/trunk/ (include/ByteBuffer.h src/utility/ByteBuffer.cxx): Add ByteBuffer::defaultBufferSize and set it to 4k |
| 12:31.15 | brlcad | dloman: search include/bu.h for 'bit' :) |
| 12:31.32 | dloman | right on :) found it already, but thanks :) |
| 12:32.05 | dloman | is actually learning to look in bu first.... promise! |
| 12:32.27 | brlcad | will believe it when he sees it :) |
| 12:32.34 | dloman | pouts |
| 12:33.02 | brlcad | of course, the next time you'll look in libbu, and it'll be a math routine in libbn |
| 12:33.14 | dloman | wait... how can you see it if i never ask? ......SCAM! |
| 12:50.22 | brlcad | sees the commits |
| 12:50.33 | brlcad | commit with some libbu api that you never asked about :P |
| 13:04.36 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 13:20.10 | *** join/#brlcad mafm_ (~mafm@193.153.199.229) | |
| 13:20.32 | CIA-105 | BRL-CAD: 03davidloman * r44379 10/geomcore/trunk/ (55 files in 6 dirs): Removed DataStream and ByteArray classes. Replaced them with ByteBuffer. |
| 13:26.20 | *** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ) | |
| 13:34.35 | CIA-105 | BRL-CAD: 03starseeker * r44380 10/brlcad/branches/cmake/ (252 files in 43 dirs): MFC r44378 |
| 13:35.53 | CIA-105 | BRL-CAD: 03davidloman * r44381 10/geomcore/trunk/tests/unit/ (5 files in 3 dirs): Stub in unit test class for NetMsgs |
| 13:36.12 | CIA-105 | BRL-CAD: 03davidloman * r44382 10/geomcore/trunk/tests/func/libNet/CMakeLists.txt: remove cmake entry for func test of netmsgs |
| 13:48.01 | starseeker | crap |
| 13:48.34 | starseeker | we have a confirmed raytrace output change (overlap reporting with air volumes) between 7.16.8 and 7.18.3 |
| 13:52.37 | *** join/#brlcad Stattrav (~Stattrav@117.192.157.100) | |
| 13:52.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:58.54 | CIA-105 | BRL-CAD: 03bob1961 * r44383 10/brlcad/trunk/src/libdm/dm-wgl.c: RECT has no width/height members. |
| 15:38.47 | *** join/#brlcad Stattrav (~Stattrav@117.192.158.156) | |
| 15:38.47 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:47.07 | CIA-105 | BRL-CAD: 03davidloman * r44384 10/geomcore/trunk/src/libNet/netMsg/ (19 files): Formatting, ws. |
| 18:04.34 | CIA-105 | BRL-CAD: 03brlcad * r44385 10/brlcad/trunk/src/librt/cut.c: |
| 18:04.34 | CIA-105 | BRL-CAD: increment axis AFTER the end of the loop, not as the first statement, so that |
| 18:04.34 | CIA-105 | BRL-CAD: the iteration is XYZXYZXYZ instead of YZXYZXYZX. this unfortunately may impact |
| 18:17.28 | *** join/#brlcad Stattrav (~Stattrav@117.192.158.156) | |
| 18:17.28 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:19.27 | *** join/#brlcad jay_ (~jay@212.96.10.253) | |
| 18:19.59 | jay_ | hi |
| 18:20.15 | jay_ | anyone here using autocad 2010? |
| 18:20.33 | dloman | not I! |
| 18:21.46 | brlcad | jay_: we don't provide autocad support |
| 18:22.33 | jay_ | i know. i was just asking if someone here uses autocad |
| 18:22.54 | brlcad | so you can ask them your support questions in private? |
| 18:23.33 | brlcad | i've used autocad before |
| 18:23.34 | jay_ | brlcad, you really want me to ask each person here the same question in private? |
| 18:24.08 | brlcad | asking support for a commercial product from an open source community is generally a really shitty thing to do |
| 18:25.07 | brlcad | if you're willing to donate 10% of their license fee, I might consider your question(s); but I'd rather answer any and all open source related questions for free |
| 18:25.25 | jay_ | brlcad, are you serious? |
| 18:25.39 | brlcad | are you? |
| 18:25.50 | brlcad | you pay them for a reason, they have support channels |
| 18:26.08 | jay_ | brlcad, you just wasting my time. thanks for nothing |
| 18:26.12 | brlcad | likewise |
| 18:27.20 | *** mode/#brlcad [+o brlcad] by ChanServ | |
| 18:28.23 | *** part/#brlcad jay_ (~jay@212.96.10.253) | |
| 18:29.32 | starseeker | hah - blender finally released a stable version of 2.5 |
| 18:29.46 | starseeker | my, what an... odd versioning scheme |
| 18:30.03 | dli | brlcad, how is the coverity thing going? |
| 18:31.21 | brlcad | dli: waiting a couple days to see if there is other interest |
| 18:31.33 | brlcad | didn't want to send in account requests one at a time, just makes for more work on their end |
| 18:31.47 | brlcad | i'll send a batch request in on Monday |
| 18:32.02 | dli | brlcad, sure, just make sure I didn't miss something |
| 18:32.15 | brlcad | anyone who has expressed interest in working on the issues, I'll include them in that request |
| 18:32.51 | brlcad | I think it's up to just four accounts so far |
| 18:33.26 | dli | manpower not enough to fix 680 thousand lines :( |
| 18:33.47 | dli | or we develop some tool to auto fix findings |
| 18:33.49 | brlcad | dli: there's not 680k lines to fix :) |
| 18:33.56 | brlcad | there were 680k analyzed |
| 18:34.01 | brlcad | < 2k to fix |
| 18:34.18 | dli | brlcad, then, just doing it manually is fine |
| 18:34.41 | brlcad | if it was automatable, I would be writing scripts |
| 18:34.49 | brlcad | each issue has to be investigated for the proper fix |
| 18:35.03 | dli | brlcad, okay |
| 18:35.45 | brlcad | I bet more than 1800 will be very very easy, but then there will be 100 that will really take lots of time and effort to investigate and fix |
| 18:37.05 | brlcad | like the three I posted, two of them are trivial to "fix" .. one really begs for a function to be implemented (a week of work) and another (the long one) warrants a logic review to see how it got that far in the first place with uninit data |
| 18:52.55 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 18:55.51 | brlcad | ../../src/libged/.libs/libged.so: undefined reference to `db_normalize' |
| 18:55.59 | brlcad | starseeker: forget a file? |
| 18:56.16 | brlcad | or my sync might not be up to date .. checking now |
| 19:22.22 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 19:22.22 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412) | |
| 19:22.47 | starseeker | brlcad: hehe, no problem - lord knows I've done that enough... |
| 19:23.00 | starseeker | w |
| 19:23.05 | starseeker | bah |
| 20:11.04 | CIA-105 | BRL-CAD: 03brlcad * r44386 10/brlcad/branches/STABLE/ (272 files in 50 dirs): merge trunk to STABLE from r44325 to HEAD r44385 -- pulls in the spatial partitioning change to cut.c for XYZXYZXYZ split planes |
| 20:15.40 | CIA-105 | BRL-CAD: 03starseeker * r44387 10/brlcad/trunk/src/librt/db5_types.c: Make a stab at a more general solution to handling boolean strings for regions that expect them. |
| 20:30.59 | CIA-105 | BRL-CAD: 03starseeker * r44388 10/brlcad/trunk/src/librt/db5_types.c: Air isn't boolean, it's just a number |
| 20:46.09 | CIA-105 | BRL-CAD: 03starseeker * r44389 10/brlcad/branches/cmake/src/ (libdm/dm-wgl.c librt/cut.c librt/db5_types.c): MFC r44388 |
| 21:11.33 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:28.26 | CIA-105 | BRL-CAD: 03starseeker * r44390 10/brlcad/trunk/src/librt/db5_types.c: Might as well be general here - do what we did in color.c in libged |
| 21:47.44 | starseeker | yeah, red's shader stuff is totally busted |
| 21:58.19 | CIA-105 | BRL-CAD: 03r_weiss * r44391 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: |
| 21:58.39 | CIA-105 | BRL-CAD: Updated function 'nmg_bool' in file 'nmg_bool.c'. This update supports the new |
| 21:58.39 | CIA-105 | BRL-CAD: prototype function 'nmg_triangulate_fu' (nmg triangulate faceuse) and is |
| 21:58.39 | CIA-105 | BRL-CAD: disabled by default since it is untested in the production code. This update |
| 23:00.43 | *** join/#brlcad Ralith (~ralith@173-10-121-193-BusName-Washington.hfc.comcastbusiness.net) | |
| 23:20.44 | *** join/#brlcad Ralith (~ralith@1555hostw130.starwoodbroadband.com) | |
| 00:00.18 | *** join/#brlcad dli_ (~dli@67.55.46.44) | |
| 01:12.02 | *** join/#brlcad crazy_imp (~mj@a89-182-196-151.net-htp.de) | |
| 01:15.54 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net) | |
| 01:42.53 | *** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net) | |
| 03:03.16 | starseeker | O.o http://www.amazon.com/Virtual-LM-Pictorial-Engineering-Construction/dp/1894959140/ref=ntt_at_ep_dpt_2 |
| 03:14.19 | *** join/#brlcad bhinesley (~bhinesley@99.104.170.214) | |
| 03:35.35 | brlcad | hello bhinesley |
| 03:35.47 | bhinesley | hi |
| 03:36.36 | bhinesley | how's it going? |
| 03:38.24 | brlcad | had better days |
| 03:38.53 | brlcad | just got back from coaching novice rowers, it went terrible even though the weather was gorgeous |
| 03:39.04 | brlcad | frustrating :) |
| 03:39.08 | brlcad | otherwise, going great |
| 03:39.28 | bhinesley | I'm guessing that it's the "novice" part that was giving you trouble. |
| 03:40.13 | brlcad | not usually, but several things were off kilter tonight |
| 03:41.23 | bhinesley | bummer |
| 03:47.05 | bhinesley | do you work for the Army, Sean? |
| 03:47.22 | bhinesley | I mean, directly. |
| 04:16.40 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net) | |
| 04:16.52 | bhinesley | hm... mged keeps locking up my X session |
| 06:11.21 | *** join/#brlcad Ralith (~ralith@173-10-121-193-BusName-Washington.hfc.comcastbusiness.net) | |
| 06:29.49 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 06:58.47 | *** join/#brlcad Ralith (~ralith@173-10-121-193-BusName-Washington.hfc.comcastbusiness.net) | |
| 07:26.03 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net) | |
| 07:35.04 | *** join/#brlcad Ralith (~ralith@173-10-121-193-BusName-Washington.hfc.comcastbusiness.net) | |
| 07:44.22 | *** join/#brlcad Ralith (~ralith@173-10-121-193-BusName-Washington.hfc.comcastbusiness.net) | |
| 07:50.45 | *** join/#brlcad Ralith (~ralith@173-10-121-193-BusName-Washington.hfc.comcastbusiness.net) | |
| 08:02.03 | *** join/#brlcad Stattrav (~Stattrav@117.192.149.202) | |
| 08:02.03 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:04.30 | *** join/#brlcad mafm_ (~mafm@42.Red-83-45-72.dynamicIP.rima-tde.net) | |
| 09:11.11 | CIA-105 | BRL-CAD: 03d_rossberg * r44392 10/brlcad/trunk/src/librt/db_path.c: included raytrace.h because of the function's prototype and MAXPATHLEN via bu.h |
| 09:12.34 | CIA-105 | BRL-CAD: 03d_rossberg * r44393 10/brlcad/trunk/src/librt/CMakeLists.txt: synced with Makefile.am (db_fullpath.c) |
| 10:50.02 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 11:09.36 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 12:25.17 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 12:27.05 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.137.184) | |
| 13:38.45 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.197) | |
| 13:38.45 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:46.53 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.139.64) | |
| 14:00.28 | *** join/#brlcad Stattrav (~Stattrav@117.202.16.228) | |
| 14:00.28 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:18.43 | *** join/#brlcad Stattrav (~Stattrav@117.192.134.224) | |
| 14:18.43 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:40.03 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 16:07.54 | CIA-105 | BRL-CAD: 03starseeker * r44394 10/brlcad/trunk/src/ (libged/red.c librt/db5_types.c): Ah - rgb, not color. This is a 'quick fix' - need to avoid editing the original data and rework write_comb to have no internal knowledge of the details of standard attributes - use librt functions. |
| 16:09.47 | CIA-105 | BRL-CAD: 03starseeker * r44395 10/brlcad/branches/cmake/src/ (3 files in 3 dirs): MFC r44394 |
| 16:35.09 | *** join/#brlcad Stattrav (~Stattrav@117.192.135.83) | |
| 16:35.09 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:44.33 | *** join/#brlcad Ralith (~ralith@173.10.121.193) | |
| 16:49.44 | CIA-105 | BRL-CAD: 03starseeker * r44396 10/brlcad/trunk/src/libged/red.c: bye bye standard_attributes array, all hail db5_standard_attribute iteration |
| 16:51.19 | starseeker | you know, in some ways red should really be called ced - it will edit a combination whether or not the region flag is set |
| 16:53.49 | starseeker | even better, we could just have 'ed' which would call either combination editing or primitive editing with a text editor depending on the argument given |
| 16:56.29 | brlcad | yep |
| 16:56.35 | brlcad | ted |
| 16:56.46 | brlcad | merge it all into ted since it's just text editing an object |
| 16:56.53 | starseeker | nods |
| 16:57.16 | starseeker | is there any particular reason ted currently needs a primitive to be in edit state? |
| 16:57.22 | brlcad | not really |
| 16:57.28 | starseeker | (I mean, aside from the convenience of not typing the name...) |
| 16:57.33 | brlcad | that's the only reason |
| 16:57.44 | brlcad | old mged statefulness |
| 16:58.37 | starseeker | will check into it - ideally, mged would feed libged's ted either the active primitive (sed) OR the active comb (oed) |
| 16:59.07 | starseeker | dives deeper down the rabbit hole... |
| 16:59.59 | starseeker | brlcad: is there a good, easy way to make a local copy of a struct directory ? |
| 17:00.40 | brlcad | er |
| 17:00.43 | starseeker | was thinking bu_malloc and memcpy, but perhaps that has issues... |
| 17:00.45 | brlcad | you can copy the struck |
| 17:01.18 | brlcad | you can copy strucks directly -- it just depends on whether the copied pointer values will get edited or not |
| 17:01.26 | brlcad | heh, struct |
| 17:02.01 | starseeker | you mean struct directory dp_cpy = *dp ? |
| 17:02.12 | brlcad | that will do it |
| 17:02.16 | starseeker | in this case, editing is quite possible |
| 17:02.39 | brlcad | seems a bit odd that you'd need to mess with a dp |
| 17:02.39 | starseeker | guess I need a deep copy (avs, etc...) |
| 17:03.07 | starseeker | it's because the comb struct still keeps struct level variables for things like region, inherit, etc |
| 17:03.52 | starseeker | I need to 1) update those with any bu_avs values and then 2) update/create bu_avs values not present that ARE present in the struct |
| 17:04.33 | starseeker | if we could just nuke them out of the comb altogether that would be ideal... |
| 17:05.03 | brlcad | but which routine are you referring to? |
| 17:05.16 | starseeker | the ones you flagged |
| 17:05.29 | starseeker | db5_apply_std_attributes and db5_update_std_attributes |
| 17:06.07 | starseeker | I suppose I could write alternative versions of those that mimicked the internal comb variables |
| 17:06.22 | starseeker | maybe that's what I should do |
| 17:06.31 | starseeker | then just have a function to sync the attributes to a dp |
| 17:07.17 | brlcad | what's the difference between those two functions? |
| 17:07.37 | starseeker | a thought - can/should we mark the internal comb variables being replaced with attributes as deprecated, if we haven't already? |
| 17:08.14 | starseeker | db5_apply_std_attributes reads the bu_avs attributes and looks for av pairs corresponding to variables contained in the comb struct |
| 17:08.25 | starseeker | if it finds any, it applys them to the struct |
| 17:08.31 | brlcad | they already are marked deprecated in rt_comb_internal |
| 17:08.45 | starseeker | db5_update_std_attributes goes the other way |
| 17:09.39 | brlcad | so they're really something like: db_sync_attr_to_comb() and db_sync_comb_to_attr() |
| 17:11.07 | brlcad | if that's the case, I wouldn't think you'd need a dp -- you'd need just the comb and a const bu_avs or an avs and a const comb |
| 17:13.08 | brlcad | the caller code can call db5_get_attributes() to pull the avs, but that keeps the api more simple |
| 17:13.23 | brlcad | fewer degrees of freedom |
| 17:18.34 | starseeker | hmm... point |
| 17:21.35 | CIA-105 | BRL-CAD: 03erikgreenwald * r44397 10/brlcad/branches/cmake/src/librt/CMakeLists.txt: indentation |
| 17:47.51 | starseeker | brlcad: OH, that's why I had the dp mixed in - dp->d_flags &= ~RT_DIR_REGION; |
| 17:48.50 | starseeker | will that get taken care of automatically when the comb is updated? |
| 17:49.09 | brlcad | hmm |
| 18:11.48 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.135.183) | |
| 18:31.41 | CIA-105 | BRL-CAD: 03starseeker * r44398 10/brlcad/trunk/ (include/raytrace.h src/libged/red.c src/librt/db5_types.c): Rework the attribute sync logic - more to do for validation. Note that this isn't syncing the dp->d_flags anymore so if that's needed functions will have to do it manually. |
| 18:39.12 | CIA-105 | BRL-CAD: 03starseeker * r44399 10/brlcad/trunk/src/libged/red.c: Shouldn't need to call this out anymore |
| 18:44.56 | CIA-105 | BRL-CAD: 03starseeker * r44400 10/brlcad/trunk/src/libged/red.c: Not calling db_update_attributes anymore in the sync routines. |
| 18:47.30 | CIA-105 | BRL-CAD: 03starseeker * r44401 10/brlcad/branches/cmake/ (include/raytrace.h src/libged/red.c src/librt/db5_types.c): MFC r44400 |
| 19:21.20 | CIA-105 | BRL-CAD: 03erikgreenwald * r44402 10/brlcad/trunk/misc/win32-msvc8/librender/librender.vcproj: remove libtie, the functions are in librt now. |
| 19:23.48 | *** join/#brlcad Stattrav (~Stattrav@117.192.129.235) | |
| 19:23.48 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:37.34 | CIA-105 | BRL-CAD: 03starseeker * r44403 10/brlcad/trunk/src/ (libged/red.c librt/db5_types.c): reorder/rework the attribute syncing for build comb in light of the current function behavior. Give strtol a try. |
| 20:21.33 | CIA-105 | BRL-CAD: 03starseeker * r44404 10/brlcad/trunk/src/librt/db5_types.c: This should improve the robustness of the attr validation, including fixing an outright bug in air code handling. |
| 20:29.48 | *** join/#brlcad mafm (~mafm@42.Red-83-45-72.dynamicIP.rima-tde.net) | |
| 20:35.20 | CIA-105 | BRL-CAD: 03starseeker * r44405 10/brlcad/trunk/src/librt/db5_types.c: Remove more hardcoded attribute names. |
| 20:43.55 | CIA-105 | BRL-CAD: 03starseeker * r44406 10/brlcad/trunk/src/librt/db5_types.c: Start going with shader instead of oshader. Also, clear out old strings for shaders - clearing a shahder setting is a valid operation for attribute -> comb syncing. |
| 20:47.06 | *** join/#brlcad Cappie (~kvirc@bas2-sudbury98-1096601162.dsl.bell.ca) | |
| 20:54.24 | Cappie | ftp://files3.cyberlink.net login anon password anon <------ read Disclaimer.txt first :) |
| 20:56.39 | IriX64 | did redhat truly abandon el6 Workstation? |
| 22:08.17 | *** join/#brlcad dli (~dli@67.55.46.44) | |
| 22:56.56 | CIA-105 | BRL-CAD: 03starseeker * r44407 10/brlcad/trunk/src/ (5 files in 5 dirs): |
| 22:56.57 | CIA-105 | BRL-CAD: OK, starting to simply down a bit - add 'empty means set to zero' logic to other |
| 22:56.57 | CIA-105 | BRL-CAD: cases for attr->comb. only call what syncs are needed. more oshader->shader |
| 22:56.58 | CIA-105 | BRL-CAD: changes. Need to go with aircode as std for now, apparently - that one should |
| 22:56.58 | CIA-105 | BRL-CAD: be fine, just change standard report. |
| 23:15.09 | starseeker | brlcad: um. What behavior are you looking for with the unsafe region_id and material_id? Should I go ahead and assign the negative values, catch it, ...? |
| 23:17.40 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 23:30.16 | CIA-105 | BRL-CAD: 03starseeker * r44408 10/brlcad/branches/cmake/ (7 files in 6 dirs): MFC r44407 |
| 01:17.46 | *** join/#brlcad crazy_imp (~mj@a89-182-6-110.net-htp.de) | |
| 02:20.13 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net) | |
| 03:53.59 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601162.dsl.bell.ca) | |
| 05:19.16 | starseeker | makes a note of this page: http://www.blender.org/forum/viewtopic.php?t=18026 |
| 06:03.46 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:40.40 | *** join/#brlcad mafm (~mafm@242.Red-80-39-191.dynamicIP.rima-tde.net) | |
| 08:29.52 | *** join/#brlcad Ralith (~ralith@173-10-121-193-BusName-Washington.hfc.comcastbusiness.net) | |
| 10:00.33 | *** join/#brlcad merzo (~merzo@114-136-133-95.pool.ukrtel.net) | |
| 10:41.27 | *** join/#brlcad merzo (~merzo@40-234-95-178.pool.ukrtel.net) | |
| 12:37.37 | CIA-105 | BRL-CAD: 03jordisayol * r44409 10/brlcad/trunk/ (misc/debian/rules sh/make_deb.sh): |
| 12:37.38 | CIA-105 | BRL-CAD: Properly handle errors during GNU/Linux packages building |
| 12:37.38 | CIA-105 | BRL-CAD: Check if "configure" script exist. |
| 12:54.21 | CIA-105 | BRL-CAD: 03jordisayol * r44410 10/brlcad/trunk/misc/debian/changelog: Update debian/changelog to the next BRL-CAD release. |
| 13:02.12 | *** join/#brlcad mafm (~mafm@242.Red-80-39-191.dynamicIP.rima-tde.net) | |
| 15:02.57 | CIA-105 | BRL-CAD: 03starseeker * r44411 10/brlcad/trunk/src/librt/db5_types.c: Ah, was too aggressive about checking things on import. |
| 16:33.00 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601162.dsl.bell.ca) | |
| 16:38.35 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:41.28 | *** join/#brlcad cjdevlin1 (~devlin@75.118.176.70) | |
| 16:46.59 | *** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 17:18.13 | *** join/#brlcad Stattrav (~Stattrav@27.57.45.253) | |
| 17:18.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:27.02 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:37.16 | *** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 18:22.47 | *** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 18:24.08 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.219) | |
| 18:24.08 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:50.07 | *** join/#brlcad Ralith (~ralith@198.134.89.250) | |
| 20:38.31 | bhinesley | brlcad: on sourceforge, it still says Looking for the latest version? Download BRL-CAD_7.14.8.exe... |
| 22:23.51 | *** join/#brlcad Ralith (~ralith@204.239.250.1) | |
| 22:25.57 | dli | bhinesley, https://sourceforge.net/projects/brlcad/files/BRL-CAD%20for%20Windows/ , 7.18.0 is available |
| 22:57.56 | bhinesley | dli: oh, I was just pointing out that the message is outdated |
| 23:05.47 | CIA-105 | BRL-CAD: 03starseeker * r44412 10/brlcad/trunk/include/raytrace.h: Looks like we'll probably need this macro. |
| 23:23.29 | starseeker | brlcad: in your color-unsafe test, you're feeding it -123 and expecting it to change? |
| 23:23.49 | starseeker | the color input does validation - it should reject that and leave the file the same |
| 23:26.43 | CIA-105 | BRL-CAD: 03starseeker * r44413 10/brlcad/trunk/src/librt/db5_types.c: Don't add an attribute if color is 0/0/0. |
| 23:40.32 | starseeker | brlcad: I'm not sure I understand red.sh:442 - what are you trying to achieve there? |
| 00:19.05 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 00:28.15 | starseeker | O.o http://www.shipmodels.info/mws_forum/viewtopic.php?f=27&t=66949 |
| 00:36.25 | brlcad | color 0/0/0 is a perfectly valid color |
| 00:36.48 | brlcad | "-1" for color should delete the attribute if we follow previous mater convention |
| 00:37.10 | brlcad | -.* |
| 00:42.10 | *** join/#brlcad Stattrav (~Stattrav@27.57.189.11) | |
| 00:42.10 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 01:12.40 | *** join/#brlcad crazy_imp (~mj@a89-182-223-144.net-htp.de) | |
| 02:24.09 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601162.dsl.bell.ca) | |
| 06:44.58 | *** join/#brlcad ibot_ (~ibot@198.60.114.207) | |
| 06:44.58 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412) | |
| 06:59.08 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 07:43.17 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:32.07 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 21:32.07 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412) | |
| 21:58.19 | CIA-105 | BRL-CAD: 03starseeker * r44430 10/brlcad/trunk/src/libged/red.c: Fix up the rename behavior for red. |
| 22:00.07 | CIA-105 | BRL-CAD: 03starseeker * r44431 10/brlcad/trunk/src/libged/red.c: ws |
| 22:23.50 | *** join/#brlcad mafm (~mafm@156.Red-88-23-77.staticIP.rima-tde.net) | |
| 22:24.40 | CIA-105 | BRL-CAD: 03starseeker * r44432 10/brlcad/trunk/src/ (libged/red.c librt/db5_types.c): Try taking the requirement for the space out of the attribute regex, trunk the shader if it's been cleared out |
| 22:37.40 | CIA-105 | BRL-CAD: 03starseeker * r44433 10/brlcad/trunk/regress/red.sh: Urm. Shader is empty in test file, so this should be the same... |
| 22:53.41 | *** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net) | |
| 23:08.47 | CIA-105 | BRL-CAD: 03starseeker * r44434 10/brlcad/trunk/regress/red.sh: Clear out the bug report messages. |
| 23:13.58 | brlcad | starseeker: yeah, copy instead of move (or just ignore the original after reading its values) |
| 23:14.02 | CIA-105 | BRL-CAD: 03starseeker * r44435 10/brlcad/branches/cmake/ (4 files in 3 dirs): MFC r44434 |
| 23:17.54 | starseeker | I think I got all the regression tests dealt with |
| 23:24.42 | starseeker | brlcad: I'll work on merging red and ted tomorrow |
| 23:24.59 | starseeker | (at least, at the mged level) |
| 23:42.54 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-104-168-20.dsl.bkfd14.sbcglobal.net) | |
| 01:12.37 | *** join/#brlcad crazy_imp (~mj@a89-182-195-68.net-htp.de) | |
| 02:03.52 | *** join/#brlcad dloman_ (~claymore@BZ.BZFLAG.BZ) | |
| 02:29.42 | CIA-105 | BRL-CAD: 03brlcad * r44436 10/brlcad/trunk/src/libged/annotate.c: position placement, decoration |
| 02:33.36 | CIA-105 | BRL-CAD: 03brlcad * r44437 10/brlcad/trunk/src/libged/annotate.c: expand examples, notes on justification, placement, and initial thoughts on required struct members |
| 02:33.56 | brlcad | cool |
| 02:45.06 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177878567.dsl.bell.ca) | |
| 04:23.34 | *** join/#brlcad cjdevlin (~devlin@75.118.176.70) | |
| 05:42.32 | CIA-105 | BRL-CAD: 03brlcad * r44438 10/brlcad/trunk/src/libged/annotate.c: considerable thought put into formalizing the command design so that it's descriptive yet reads naturally. enough hours thinking and designing for now, time to start coding. |
| 05:48.57 | brlcad | pretty exhausting to design up front, but I think this will be worth it .. should be really easy to use |
| 05:53.35 | *** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net) | |
| 06:03.52 | CIA-105 | BRL-CAD: 03brlcad * r44439 10/brlcad/trunk/src/libged/annotate.c: lied, lil more thinking |
| 06:16.26 | *** join/#brlcad Stattrav (~Stattrav@27.57.101.209) | |
| 06:16.26 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:50.22 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 06:54.48 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177592886.dsl.bell.ca) | |
| 08:23.28 | *** join/#brlcad vtts (~vytautas@diz.ktu.lt) | |
| 08:41.48 | *** join/#brlcad mafm (~mafm@20.Red-81-34-125.dynamicIP.rima-tde.net) | |
| 09:11.30 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 09:56.51 | *** join/#brlcad Stattrav (~Stattrav@27.61.60.144) | |
| 09:56.51 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:12.18 | *** join/#brlcad Stattrav_ (~Stattrav@27.61.234.254) | |
| 11:34.03 | *** join/#brlcad mafm_ (~mafm@20.Red-81-34-125.dynamicIP.rima-tde.net) | |
| 11:50.25 | CIA-105 | BRL-CAD: 03erikgreenwald * r44440 10/brlcad/trunk/misc/win32-msvc8/librt/librt.vcproj: add db_fullpath.c |
| 11:55.38 | CIA-105 | BRL-CAD: 03erikgreenwald * r44441 10/brlcad/trunk/misc/win32-msvc8/libtclcad/libtclcad.vcproj: ged_obj.c is now tclcad_obj.c |
| 12:00.33 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-104-168-20.dsl.bkfd14.sbcglobal.net) | |
| 12:52.15 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 13:41.32 | *** part/#brlcad hyarion (c05ben@peppar.cs.umu.se) | |
| 13:53.18 | starseeker | is fighting the urge to begin a big reorganization of the primitive editing code... |
| 13:54.36 | starseeker | tedit is using globals, calls out a bit list of primitive types, doesn't do things like accept a name and primitive type on the command line to bring up an empty file... |
| 14:02.29 | brlcad | I tried eliminating one of the globals a few months back |
| 14:02.37 | brlcad | got something wrong, broke, reverted |
| 14:03.13 | brlcad | is prime for rewrite though |
| 14:09.07 | starseeker | I think it belongs in a functab interface |
| 14:10.11 | starseeker | would REALLY prefer to consolidate the import/export functabs into one, that keys off of an int parameter (1 = v4, 2 = v5, ... 100 = g2asc, 101 = txt edit, ...) |
| 14:10.52 | starseeker | then we don't have to muck with the functab for a new format |
| 14:11.25 | starseeker | don't have time for that now though - guess I'd better leave it, got to get on nurbs |
| 14:22.50 | dloman_ | haha: http://www.youtube.com/watch?v=ejEkZtgYNpQ&feature=related |
| 14:45.20 | CIA-105 | BRL-CAD: 03starseeker * r44442 10/brlcad/branches/cmake/src/librt/uvpoints.cpp: Make the tree depth to uvpoints a variable |
| 14:48.39 | CIA-105 | BRL-CAD: 03erikgreenwald * r44443 10/geomcore/trunk/include/NetMsg.h: include NetMsgTypes.h to propogate the defines to the implementation |
| 15:54.04 | CIA-105 | BRL-CAD: 03starseeker * r44444 10/brlcad/trunk/src/librt/uvpoints.cpp: Oops, that should have been in trunk. |
| 16:11.35 | starseeker | ``Erik: one of the things we need to do for merge is to figure out why package require Itcl/Itk isn't cutting it for some of the mged stuff |
| 16:11.55 | starseeker | IIRC, I'm depending on package require working in the CMake setup |
| 16:13.48 | starseeker | that'll be one of the main sources of conflict between the two trees - the change was reverted in trunk |
| 16:17.08 | starseeker | ah, phooy - 44444 should have been something more significant than a trunk sync |
| 16:18.10 | brlcad | starseeker: the func tab sort of already has an interface (in fact it has several) |
| 16:18.33 | CIA-105 | BRL-CAD: 03starseeker * r44445 10/brlcad/branches/cmake/ (3 files in 3 dirs): MFC r44444 |
| 16:19.49 | brlcad | at the functab level, it should be something pretty low level, like filling out a key/value pairing (another case for binary AVS) where each parameter and it's value is written in order |
| 16:20.51 | brlcad | then similar to nirt output, the values can be formatted accordingly consistently with just one function for all object types (avs to v4, avs to v5, avs to text, etc) |
| 16:21.22 | brlcad | heck, json is a prime candidate since it also includes recursive grouping support |
| 16:21.30 | brlcad | (as an implementation detail) |
| 16:21.39 | starseeker | nods |
| 16:21.42 | brlcad | at least, in-memory |
| 16:21.58 | starseeker | I'll have to shelve it for a while though - nurbs/step need attention |
| 16:22.13 | brlcad | nods |
| 16:26.00 | starseeker | ``Erik: take a look at bwish/cadAppInit.c for a note on the problem |
| 16:26.28 | brlcad | he working on merge review? |
| 16:26.43 | starseeker | he was asking about merging, dunno about review |
| 16:29.45 | starseeker | this is a handy little trick if you have trunk and cmake branches checkout out, run from within trunk: |
| 16:29.48 | starseeker | find . -type file ! -regex '.*svn.*' ! -regex '.*\.cmake' ! -name CMakeLists.txt -print -exec diff {} ../cmake/{} \; |
| 16:40.11 | brlcad | nods -- usually do something similar to that when I merge major branches |
| 17:11.32 | *** join/#brlcad crazy_imp (~mj@a89-182-195-68.net-htp.de) | |
| 18:03.41 | CIA-105 | BRL-CAD: 03bob1961 * r44446 10/brlcad/trunk/include/ged.h: Added GED_DM_VIEW_NULL. |
| 18:27.53 | *** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net) | |
| 20:20.19 | *** join/#brlcad merzo (~merzo@197-47-132-95.pool.ukrtel.net) | |
| 22:21.38 | *** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net) | |
| 00:58.52 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 00:58.52 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412) | |
| 01:12.37 | *** join/#brlcad crazy_imp (~mj@a89-182-207-113.net-htp.de) | |
| 01:38.54 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 02:11.15 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 02:56.22 | *** join/#brlcad Hyper-Core (~lol@71.31.117.174) | |
| 03:00.47 | *** part/#brlcad Hyper-Core (~lol@71.31.117.174) | |
| 04:04.27 | *** join/#brlcad vtts (~vytautas@diz.ktu.lt) | |
| 04:16.10 | *** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net) | |
| 04:37.59 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 05:06.31 | *** join/#brlcad Stattrav (~Stattrav@122.172.5.31) | |
| 05:06.31 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:14.39 | brlcad | starseeker: nice job keeping the branch in sync |
| 05:15.19 | brlcad | cursory review looks great .. just a few issues to resolve |
| 05:16.03 | brlcad | the known ones that you've already documented with bwish/mged init calls to Tcl_Eval("package require ...") instead of Itcl_Init() and friends |
| 05:16.39 | brlcad | one peculiar change in mged/cmd.c |
| 06:09.18 | CIA-105 | BRL-CAD: 03brlcad * r44447 10/brlcad/branches/cmake/include/ged.h: merge r44444:44446 from trunk |
| 06:37.11 | CIA-105 | BRL-CAD: 03brlcad * r44448 10/brlcad/trunk/src/other/libz/contrib/dotzlib/ (DotZLib/DotZLib.csproj DotZLib.build): merge from cmake branch to trunk, setting mime-type and eol-style on a few miles |
| 08:24.13 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 08:24.13 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412) | |
| 08:39.03 | *** join/#brlcad mafm_ (~mafm@127.Red-81-32-105.dynamicIP.rima-tde.net) | |
| 11:07.43 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 11:24.16 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 11:27.18 | CIA-105 | BRL-CAD: 03208.110.88.242 07http://brlcad.org * r2855 10/wiki/Main_Page: |
| 13:07.44 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2856 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/208.110.88.242|208.110.88.242]] ([[User talk:208.110.88.242|Talk]]); changed back to last version by [[User:Sean|Sean]] |
| 13:07.54 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:208.110.88.242]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 13:13.22 | CIA-105 | BRL-CAD: 03brlcad * r44449 10/brlcad/trunk/src/other/libz/contrib/masmx86/inffas32.asm: set props to match branch |
| 13:16.16 | CIA-105 | BRL-CAD: 03brlcad * r44450 10/brlcad/trunk/src/other/libz/contrib/masmx64/ (gvmat64.asm inffasx64.asm): more prop syncing |
| 13:16.41 | CIA-105 | BRL-CAD: 03brlcad * r44451 10/brlcad/branches/cmake/src/other/incrTcl/itk/win/rc/itk.rc: not native, windows-style in case it's shoved into a source tarball |
| 13:19.42 | CIA-105 | BRL-CAD: 03brlcad * r44452 10/brlcad/branches/cmake/src/other/incrTcl/itcl/win/rc/itcl.rc: sync eol-style to windows-style |
| 13:21.52 | CIA-105 | BRL-CAD: 03brlcad * r44453 10/brlcad/branches/cmake/src/librt/primitives/nmg/nmg_misc.c: somehow this change was missed from trunk a few months back. nmg is using a plane, so init properly with HSETALL. this snippet still needed/needs investigating. |
| 13:27.41 | CIA-105 | BRL-CAD: 03brlcad * r44454 10/brlcad/branches/cmake/src/ (bwish/cadAppInit.c bwish/main.c mged/setup.c): |
| 13:27.41 | CIA-105 | BRL-CAD: sync with trunk just so we have a matching merge at the point of sync. this |
| 13:27.42 | CIA-105 | BRL-CAD: restores the itcl/itk initialization to using their *_Init() functions instead |
| 13:36.44 | CIA-105 | BRL-CAD: 03brlcad * r44455 10/brlcad/branches/cmake/src/mged/cmd.c: another change that was somehow missed syncing from trunk. maybe off-by-one on the revisions a couple times. this change automatically redraws any objects that are edited. |
| 13:49.03 | CIA-105 | BRL-CAD: 03brlcad * r44456 10/brlcad/branches/cmake/include/config_win_cmake.h: another missed, probably due to name. everyone gets hypot and we have tk. |
| 13:54.34 | CIA-105 | BRL-CAD: 03brlcad * r44457 10/brlcad/branches/cmake/misc/win32-msvc/ (CMakeLists.txt Dll/CMakeLists.txt): sync with trunk |
| 14:45.16 | starseeker | brlcad: I'm not sure 44456 is the right way to sync - I have a vague recollection that the cmake branch changes were needed |
| 14:52.16 | brlcad | cmake branch had a compiler-version check -- that's usually not right |
| 14:52.49 | starseeker | I think that was added after some painful testing where we found it did matter for Visual Studio |
| 14:53.48 | starseeker | and the Tk variable(s) ought to be handled elsewhere - no reason for config_win to have that hardcoded |
| 14:55.47 | starseeker | IIRC, building with the HAVE_TK and hypot definion in Visual C++ 2010 won't work |
| 14:56.29 | starseeker | (HAVE_TK will be multiply defined regardless, if the build logic does its job) |
| 15:01.45 | CIA-105 | BRL-CAD: 03starseeker * r44458 10/brlcad/trunk/ (doc/docbook/system/mann/en/ls.xml src/libged/ls.c): Add a -q option to ls to do a quiet db_lookup instead of a noisy one (useful for scripting) |
| 15:03.23 | brlcad | it can matter for studio |
| 15:03.28 | brlcad | it just shouldn't be version-exempted |
| 15:03.49 | brlcad | it becomes a feature test if it's feature-variant |
| 15:04.49 | willdye | brlcad: this is only tangentially related to CAD, but FWIW the models and environments in Portal2 are (IMO) gorgeous. most of the animated movie's i've seen aren't as visually impressive as what P2 renders in real time. |
| 15:05.09 | brlcad | noticed HAVE_TK was suspect but had to pick left or right for the merge and trunk should win when there's doubt or suspect lines |
| 15:05.10 | willdye | if you're not a game player, at least check out some of the videos for the modeling work. |
| 15:05.31 | brlcad | willdye: okay, thanks |
| 15:05.45 | brlcad | usually a lot of impressive texture and lighting effects work :) |
| 15:06.03 | willdye | yes, that too. |
| 15:06.09 | ``Erik | shaders ftw |
| 15:07.34 | starseeker | brlcad: if you can figure out how to set up a feature test I'm cool with that - it does need to be handled in some fashion for VS 2010 |
| 15:08.15 | CIA-105 | BRL-CAD: 03brlcad * r44459 10/brlcad/trunk/ (INSTALL.cmake README.cmake TODO.cmake): sync the cmake top-level docs from the cmake branch |
| 15:08.19 | starseeker | ``Erik: do you remember that MSVC version specific thing we had to deal with? I recall asking you for help there |
| 15:08.24 | brlcad | er, a small snippet that runs hypot() and/or _hypot() |
| 15:09.03 | ``Erik | not especially, I didn't see a commit message on that file that helped, either :/ |
| 15:09.36 | ``Erik | I do recall looking up the variable on msdn, but not what the core issue was :/ |
| 15:10.14 | brlcad | #include <math.h>\nint main(int ac, char*av[]) { double f; f = _hypot(1.0, 1.0); return 0; } |
| 15:10.26 | brlcad | if it succeeds, #define hypot _hypot |
| 15:11.03 | starseeker | bbl, must perform helpdesk function |
| 15:57.41 | brlcad | syncs all the cmakelist files (with history!) |
| 16:04.36 | brlcad | woo hoo, no gsoc conflicts! |
| 16:04.51 | brlcad | not much longer now |
| 16:05.22 | ``Erik | heh, I was starting to do a clobber copy last night, decided to finish it today and you'd already started O.o w00t, history preserved |
| 16:06.09 | brlcad | the cmakelists files are going to take a while to sync with history :) |
| 16:07.14 | ``Erik | *nod* hopefully ya don't lose connection when committing :) I had one that wouldn't work in a single thing from the office, ended up using bz to do it |
| 16:07.33 | brlcad | commit from arlnet, why it's taking so fraking long |
| 16:07.36 | ``Erik | btw, new server has user accounts, a wad of ports, updated system, and /usr/home copied |
| 16:08.12 | brlcad | AWESOME! |
| 16:08.21 | ``Erik | that's a huge disk bump |
| 16:30.12 | brlcad | I bet |
| 16:30.34 | brlcad | heh, syncing the cmake files is going to take another hour .. stupid network |
| 16:36.19 | ``Erik | while that's chunking, think ya might update the crit cname? :D |
| 16:53.39 | CIA-105 | BRL-CAD: 03starseeker * r44460 10/brlcad/trunk/src/libged/ls.c: whoops, update usage too. |
| 18:17.26 | brlcad | woot, finished copying .. now the commit |
| 18:39.53 | CIA-105 | BRL-CAD: 03brlcad * r44461 10/brlcad/trunk/ (130 files in 130 dirs): sync all of the CMakeLists.txt files from the cmake branch to trunk, preserving history via svn cp for the new additions and copying for the rest. |
| 18:48.32 | brlcad | yes, it really took that long |
| 18:48.53 | *** join/#brlcad mafm_ (~mafm@34.Red-83-58-21.dynamicIP.rima-tde.net) | |
| 18:54.45 | starseeker | brlcad: so that just leaves the .cmake files? |
| 19:27.01 | starseeker | blinks: http://www.steptools.com/products/stepncwrite/ |
| 19:44.27 | CIA-105 | BRL-CAD: 03erikgreenwald * r44462 10/geomcore/trunk/src/libgvm/ (files.c gvm.h gvm_svn.h mem.c models.c objects.c repo.c): add header/footer, indent, kill trailing whitespace, etc. |
| 19:46.26 | ``Erik | still need merged in misc/CMake |
| 19:46.51 | ``Erik | grammar I master am of |
| 19:47.04 | starseeker | heh |
| 19:47.40 | ``Erik | (vim writing/editing style doesn't quite work in irssi) |
| 19:54.06 | brlcad | ``Erik: it's going, still merging |
| 19:54.32 | brlcad | doing the preserved copy apparently initiates a lot of net connections, which sucks |
| 19:54.48 | brlcad | at least on that net |
| 20:01.11 | CIA-105 | BRL-CAD: 03brlcad * r44463 10/brlcad/trunk/ (configure.cmake.sh misc/CMake/ misc/Doxyfile.in): add new files coming from the cmake branch: support infrastructure, templatized Doxyfile, and a fake configure wrapper |
| 20:08.46 | starseeker | ``Erik: yeah, it's in tests/func/gvmtest |
| 20:13.46 | ``Erik | #+darwin(sb-posix:chdir (let ((binname (sb-sys::os-get-runtime-executable-path t))) (subseq binname 0 (- (length binname) (length (concatenate 'string "Contents/MacOS/" +executable-name+)))))) |
| 20:14.06 | starseeker | awesome |
| 20:14.13 | ``Erik | ayup, I thought so |
| 20:14.45 | ``Erik | not awesome enough for 3 months in sbcl's guts, but... |
| 20:15.17 | CIA-105 | BRL-CAD: 03brlcad * r44464 10/brlcad/trunk/src/librt/db5_types.c: really 'del' means the same for any of the attributes. it's our old-style convention meant to remove/disable an value or option. |
| 20:20.18 | brlcad | nstill working on src/other |
| 20:26.15 | CIA-105 | BRL-CAD: 03brlcad * r44465 10/brlcad/trunk/src/other/ (8 files in 8 dirs): likewise with the src/other CMake dirs |
| 20:28.22 | brlcad | snack break, will be back to merging in a couple .. not yet complete |
| 20:28.45 | starseeker | mmm, snacks |
| 20:48.06 | *** join/#brlcad crazy_imp (~mj@a89-182-207-113.net-htp.de) | |
| 21:28.18 | *** join/#brlcad mafm (~mafm@34.Red-83-58-21.dynamicIP.rima-tde.net) | |
| 23:09.11 | *** join/#brlcad Yoshi47 (~jan@d72-39-60-53.home1.cgocable.net) | |
| 23:53.30 | *** join/#brlcad evander (~jack@adsl-76-202-242-120.dsl.emhril.sbcglobal.net) | |
| 23:55.40 | evander | hey |
| 02:28.10 | brlcad | hello evander |
| 02:30.43 | ``Erik | so the merge is complete? |
| 02:42.01 | evander | I'm having trouble getting brl-cad to compile, it's just one line causing trouble, anyone willing to help |
| 02:42.05 | evander | ? |
| 02:49.42 | brlcad | ``Erik: doing a final pass review now |
| 02:50.12 | brlcad | haven't done a compilation check yet, both old and new builds may be busted but the changes are reviewed and merged |
| 02:50.17 | brlcad | evander: what's the failure? |
| 02:51.39 | evander | make says that 'abi' and 'aci' 'may be uninitialized in this function' |
| 02:54.42 | evander | this is for the proc_box function in src/librt/patch/patch-g.c line 1936: 'vect_t ab, ac, ad, abi, aci, adi' |
| 02:55.37 | evander | sorry, src/conv/patch/patch-g.c |
| 03:10.12 | ``Erik | evander: there's a flag to disable strict flags when you run configure, try that? |
| 03:14.10 | evander | I'll try |
| 03:21.38 | CIA-105 | BRL-CAD: 03brlcad * r44466 10/brlcad/trunk/src/conv/patch/patch-g.c: quell strict compilation warning reported by evander via irc. compiler wasn't smart enough to figure out that use prior to init isn't possible (valid is false). |
| 03:33.41 | CIA-105 | BRL-CAD: 03brlcad * r44467 10/brlcad/trunk/misc/archlinux/brlcad.install: remove the rcs id var to minimize branch diff. add /bin/sh header for source scanners since it looks like proper syntax. |
| 03:37.54 | CIA-105 | BRL-CAD: 03brlcad * r44468 10/brlcad/trunk/src/other/togl/CMake/CheckFunctions.cmake: this just very well may be the last sync needed to merge cmake branch to trunk. |
| 03:40.20 | brlcad | verified, the diff looks clean |
| 03:40.33 | brlcad | now to check/fix the build :) |
| 03:41.09 | brlcad | fair game for anyone to hack on now |
| 03:51.57 | ``Erik | I'll do my usual spread tomorrow and either fix or report all the failures O.o I doubt there'll be many if the merge is solid, been fixing/reporting for the cmake branch for a while :) |
| 04:17.17 | brlcad | should be possible to have both working without too much effort at least while install testing proceeds -- that was just a pure source merge review so the branch can be closed out |
| 04:19.52 | CIA-105 | BRL-CAD: 03brlcad * r44469 10/brlcad/trunk/src/conv/patch/patch-g.c: oops, double semi |
| 04:31.31 | brlcad | hmm.. the lights regression is failing |
| 04:31.46 | brlcad | pretty sure it worked for release, but not 100% |
| 04:34.18 | CIA-105 | BRL-CAD: 03brlcad * r44470 10/brlcad/trunk/TODO: light regression is failing, need to investigate and fix. don't know when it broke. |
| 04:39.04 | CIA-105 | BRL-CAD: 03brlcad * r44471 10/brlcad/trunk/TODO: |
| 04:39.04 | CIA-105 | BRL-CAD: aha, found the cause. the lights test calls 'put' and sets attributes directly |
| 04:39.05 | CIA-105 | BRL-CAD: including several old attribute names such as rgb and .. oshader. this makes |
| 04:51.34 | CIA-105 | BRL-CAD: 03brlcad * r44472 10/brlcad/trunk/src/librt/CMakeLists.txt: deterministic behavior still applies, ignore individual 'extra_dist' files. |
| 05:55.06 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:02.29 | *** join/#brlcad crazy_imp (~mj@a89-182-193-94.net-htp.de) | |
| 08:07.31 | *** join/#brlcad crazy_im1 (~mj@a89-182-199-125.net-htp.de) | |
| 08:45.35 | *** join/#brlcad mafm (~mafm@213.Red-83-40-126.dynamicIP.rima-tde.net) | |
| 10:29.08 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 11:28.43 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 11:39.39 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 13:14.36 | brlcad | interesting.. old build passed distcheck :) |
| 13:26.00 | starseeker | blinks - but it shouldn't, should it? |
| 13:29.06 | ``Erik | should the old stuff get all the CMakeLists.txt and misc/CMake/ stuff added as EXTRA_DIST ? |
| 13:29.42 | brlcad | that's why it passing distcheck was interesting :) |
| 13:29.56 | brlcad | but otherwise, yeah |
| 13:30.18 | starseeker | winces - that's a lot of work unless we're going to maintain both for a while |
| 13:30.21 | ``Erik | distcheck won't complain if unknown "turds" don't get put in the tarball |
| 13:30.32 | brlcad | only minimal attention I'd think -- wont' live for long |
| 13:30.55 | brlcad | ``Erik: except I have logic in there that checks if anything is missing |
| 13:31.09 | brlcad | it compares the svn list with the dist |
| 13:31.34 | starseeker | took some doing to duplicate that behavior with CMake |
| 13:31.36 | brlcad | starseeker: o.O not really .. 10 min tops |
| 13:32.10 | starseeker | brlcad: updating all the Makefile.am extradists for all the directories where something was added? |
| 13:32.11 | brlcad | tedious, sure, but not a lot of actual time |
| 13:32.28 | starseeker | what do we gain? |
| 13:32.52 | brlcad | if we have to push a source release with it |
| 13:33.11 | brlcad | it's not your 10min, no worries :) |
| 13:33.18 | starseeker | true :-) |
| 13:33.41 | brlcad | I didn't plan on adding them unless distcheck failed |
| 13:33.53 | brlcad | and it didn't fail, so .. interesting :) |
| 13:34.03 | starseeker | cmake build is currently failing due to the Itcl_Init issue, bty |
| 13:42.49 | brlcad | hm, mine is actually failing in librt here |
| 13:42.55 | brlcad | strictness fail on bot.c |
| 13:43.02 | brlcad | signage warnings |
| 13:48.03 | starseeker | er, yeah - itcl is with strict off |
| 13:48.21 | starseeker | (lots of formatting blather too) |
| 13:56.13 | brlcad | so that's going to require a little digging -- Itcl_init definitely shouldn't be failing (nor should package require) |
| 13:56.18 | brlcad | i'll hop of the debugger later today |
| 13:56.23 | brlcad | s/of/on/ |
| 14:00.10 | ``Erik | the signed issues came from a commit indianlarry did, I'll ask him about it when he gets back in the office |
| 14:01.55 | brlcad | autotools strict is actually off in librt, was turned off during release preparations due to a problem in the nmg export code |
| 14:02.04 | brlcad | so even if bot succeeds, nmg is going to issue a warning |
| 14:02.41 | brlcad | we need to either exempt librt like autotools does, or fix the warnings (ideal) |
| 14:05.23 | ``Erik | yeah, I'd like to ask him sooner than later while it's still semi-fresh, mebbe leave a comment in the src if it bears holding off reverting |
| 14:06.08 | ``Erik | log says something about a bug report, d'no which one, so'z *shrug* |
| 14:36.42 | starseeker | brlcad: I know why Itcl_init isn't working - it's because I didn't include all the directories needed for the itcl.h/itk.h headers |
| 14:37.29 | starseeker | was trying to use package require to avoid that whole "using private headers" mess |
| 15:33.31 | *** join/#brlcad Stattrav (~Stattrav@117.202.20.210) | |
| 15:33.31 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:57.14 | ``Erik | mmmm, pröst *pats belleh* |
| 16:58.04 | ``Erik | brlcad: those g_bot_include signed issues are direct fallout from size_t, the 'index' and nhits stuff use -1 as a special value in some cases, a mixed of == and <0 |
| 16:59.58 | starseeker | brlcad: there are a couple of cases where I call out whole directories to ignore in the CMakeLists.txt files - in particular, the Tcl/Tk man pages are generated by scripts. I suppose would could actually list all those out and update that list every time Tcl/Tk changes something, but that's quite a pain as opposed to just snarfing the list of generated files after generating them |
| 17:06.19 | CIA-105 | BRL-CAD: 03starseeker * r44473 10/brlcad/trunk/doc/docbook/system/mann/en/CMakeLists.txt: Remove early experiment with file-checking code |
| 17:21.18 | CIA-105 | BRL-CAD: 03starseeker * r44474 10/brlcad/trunk/src/ (bwish/CMakeLists.txt mged/CMakeLists.txt): Until we get it sorted out, add in the logic needed for btclsh/bwish and mged to find the itcl.h and itk.h headers. |
| 17:21.46 | starseeker | ok, that gets me going with a non-strict build on Mac |
| 17:24.28 | starseeker | reflects that eventually we'll probably want to update the svn ignore properties in trunk |
| 17:24.37 | CIA-105 | BRL-CAD: 03erikgreenwald * r44475 10/brlcad/trunk/src/librt/primitives/bot/g_bot_include.c: use temporary signed variables to quell the signed/unsigned warning. Add a TODO: requesting review down the road. |
| 17:34.00 | CIA-105 | BRL-CAD: 03erikgreenwald * r44476 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: bu_glong -> ntohl (only tested on v5) |
| 17:35.35 | ``Erik | librt should be safe for strict again |
| 17:42.51 | CIA-105 | BRL-CAD: 03starseeker * r44477 10/brlcad/trunk/ (misc/CMake/BRLCAD_Util.cmake src/librt/CMakeLists.txt): Add the ability to specify a NOSTRICT compile when adding a library. |
| 18:11.53 | *** join/#brlcad merzo (~merzo@222-14-94-178.pool.ukrtel.net) | |
| 18:14.05 | brlcad | ``Erik: yeah, I remember that patch -- most of the -1 should have been properly cast through size_t, so if anything was missed, it might have been a <0 check that needed to be changed to == (size_t)-1 |
| 18:14.28 | brlcad | warrants getting the test case that provoked the bug |
| 18:16.11 | brlcad | starseeker: that sounds fine for src/other dirs -- I think the issue is more with our own directories |
| 18:16.41 | starseeker | brlcad: k. For ours it'll probably be a few cases like the xxx dir |
| 18:17.50 | brlcad | a minor referential integrity cost so we can say we're fully managed (with lists of all intentional files, whether source code or not) |
| 18:18.09 | brlcad | not a major issue in the least, just completeness |
| 18:18.22 | brlcad | really impressed how cleanly the merge went |
| 18:19.49 | brlcad | ``Erik: unless I typo'd .. the "obvious" conversion to ntohl() resulted in a hard crashing raytracing bug |
| 18:20.13 | starseeker | 'course, I doubt the windows build works right now |
| 18:20.32 | starseeker | but it shouldn't be far off |
| 18:20.39 | brlcad | sure, some wrinkles to iron out, but in all .. looking great |
| 18:20.44 | starseeker | is impressed you managed to save all the history |
| 18:20.46 | brlcad | old build works, new build works |
| 18:21.29 | starseeker | (all my early CMake suckage preserved for posterity...) |
| 18:21.30 | brlcad | now a confirmation that release tarballs produced are identical and same with binary installs, and the old can go bye bye soon |
| 18:21.47 | starseeker | not quite yet - install docs will need more work |
| 18:22.02 | brlcad | minor, that's an afternoon at best |
| 18:22.29 | starseeker | and possibly some expansion of the options in the fake configure script - also not a huge deal, unless we want to automate its generation |
| 18:22.54 | brlcad | it'll take more time to write up an article on the conversion overview and impact |
| 18:23.50 | starseeker | for the source files, it's make package_source - make package for the binaries, IIRC |
| 18:24.21 | brlcad | no worries, I'll assume it's all documented in INSTALL.cmake |
| 18:24.25 | brlcad | otherwise, I'll chase you down :) |
| 18:24.32 | starseeker | quickly checks... |
| 18:24.34 | starseeker | erm... |
| 18:24.53 | brlcad | er, perhaps HACKING.cmake |
| 18:25.23 | starseeker | which doesn't exist yet |
| 18:25.25 | starseeker | gets busy |
| 18:29.39 | starseeker | eventually we'll probably want to tie the new deb/rpm settings into the CPack stuff |
| 18:37.41 | *** join/#brlcad Stattrav (~Stattrav@117.202.20.210) | |
| 18:37.41 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:46.11 | ``Erik | brlcad: I raytraced a big nmg heavy model successfully (took 2 regex passes and hand reviewing the changes to verify, there was a cfl grade difference in some cases) |
| 18:46.38 | ``Erik | for bots, the test case was dark side |
| 18:47.36 | brlcad | ``Erik: okay cool |
| 18:47.50 | brlcad | i'm not above having entered a typo or fat-fingered some expression |
| 18:48.14 | brlcad | probably diff what I did with your patch to see where this lamb went astray |
| 18:59.07 | CIA-105 | BRL-CAD: 03starseeker * r44478 10/brlcad/trunk/src/other/CMakeLists.txt: Add a few dirs to the ignore list |
| 19:08.13 | kanzure | did jdoliner ever finish his implementation of boole? http://brlcad.org/wiki/User:Jdoliner |
| 19:10.27 | kanzure | ah.. brlcad/trunk/src/proc-db/surfaceintersect.cpp |
| 19:12.15 | kanzure | yeah i'm not sure if he committed all of his code or not |
| 19:13.07 | kanzure | hmm the latest was 2009-08-13 |
| 19:13.14 | kanzure | ok. that sounds about right |
| 19:14.25 | brlcad | kanzure: he didn't implement or integrate boole itself, but he was trying to implement what boole does in our system |
| 19:15.18 | brlcad | he started building up the individual pieces needed to get surface-surface intersection calculations going, and got something going, but it wasn't a complete effort |
| 19:15.48 | kanzure | looks like he did good work sticking with the opennurbs primitives |
| 19:15.54 | brlcad | src/proc-db/surfaceintersect.cpp is the latest state of the code |
| 19:15.58 | brlcad | yeah, pretty good |
| 19:16.46 | kanzure | on the wiki he mentions SurfaceSurfaceIntersect but all i see is BrepBrepIntersect; i figure it's the one? |
| 19:16.59 | kanzure | oh "SurfaceSurfaceIntersect has been renamed to FaceFaceIntersect same" ok |
| 19:17.21 | brlcad | a brep is one or more surfaces |
| 19:17.54 | kanzure | i forget how opennurbs handles multiple faces on an object |
| 19:18.13 | kanzure | i know that it's accessed as an array (like my_nurb.m_F[x] for the xth face) |
| 19:18.21 | kanzure | but usually there's some information about adjacency of faces .. er, somewhere |
| 19:18.42 | brlcad | see src/proc-db/brep*.cpp |
| 19:18.51 | kanzure | since you can call myobject.get_edges() where each edge separates two faces, etc. |
| 19:18.54 | kanzure | ok |
| 19:18.55 | brlcad | several examples |
| 19:19.42 | kanzure | it's the trimming curve that is the edge around a given face right? |
| 19:20.45 | brlcad | yes |
| 19:21.40 | kanzure | why do you say it wasn't a complete effort? |
| 19:21.51 | kanzure | oh duh, intersection isn't enough to actually perform the set operators |
| 19:22.14 | *** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net) | |
| 19:22.20 | brlcad | and I don't think his implementation will handle ALL cases of surface surface intersections |
| 19:22.29 | brlcad | lots of edge cases to consider |
| 19:24.00 | CIA-105 | BRL-CAD: 03starseeker * r44479 10/brlcad/trunk/doc/README.MacOSX: Document the issue CMake has with parallel builds and OSX open file limits |
| 19:25.00 | kanzure | yeah and then you have to merge the intersection curves |
| 19:25.07 | CIA-105 | BRL-CAD: 03starseeker * r44480 10/brlcad/trunk/HACKING.cmake: Add a cmake version of HACKING |
| 19:26.16 | kanzure | then use the merged brep to partition the original two solids, classify each partitioned component as either inside/outside and based on that classification add it to the object (depending on whether this is a union or difference) |
| 19:28.33 | brlcad | example, consider two simple triangles. they can intersect as a point (pt), a line (ln), or a face (fc), so you have pt-pt for two coinciding vertices, pt-ln for a vertex on edge, and pt-fc for a vertex in the face; ln-ln for coinciding edges (with three overlap sub-cases), ln-fa (similarly with three sub-cases), and fa-fa for non-tangential planar intersections (with at least three sub-cases) |
| 19:29.15 | brlcad | that's twelve cases, and I'd be surprised if he ended up with support for more than a few of them |
| 19:30.16 | brlcad | two random intersecting polygons is going to be a fc-fc intersect producing a ln result |
| 19:31.06 | kanzure | i don't know what to do in the case of a vertex on a face- presumably that vertex is infintismal anyway so.. |
| 19:31.29 | brlcad | right, so you decide whether to ignore or stitch |
| 19:31.48 | brlcad | one of them will be wrong :) |
| 19:32.03 | brlcad | but you don't know which |
| 19:33.24 | brlcad | you could attempt to say "okay, no points on faces" .. but even regular triangle that share an edge have this property (two pairs of coinciding vertices and a coinciding edge) |
| 19:33.59 | kanzure | btw the guys who wrote BOOLE released their code in the public domain |
| 19:34.36 | kanzure | (in c) |
| 19:34.49 | brlcad | basically, it's needing to preserve a concept of "inside", "outside", ... and "on" |
| 19:35.15 | brlcad | boole is not PD, unless they changed it recently |
| 19:35.25 | brlcad | it's NC |
| 19:36.04 | brlcad | http://gamma.cs.unc.edu/CSG/BOOLE-DOCS/copyright |
| 19:36.32 | kanzure | blah |
| 19:36.55 | kanzure | sorry for the false alarm |
| 19:37.13 | brlcad | I know the guys that worked on boole (and later esolid) |
| 19:37.25 | brlcad | that was collaborative research back in the day |
| 19:37.29 | kanzure | in one of their papers they claim it is public domain, but i see the license clearly claims differently |
| 19:37.41 | brlcad | they actually gave us permission to use their code many years ago via e-mail, but no longer have access to that e-mail without serious archive searching |
| 19:37.57 | kanzure | yeah the same paper references muuss which made me wonder if brlcad implemented this (which, the answer is no, but the 2009 gsoc student worked on it, neat) |
| 19:38.32 | brlcad | they were contracted by BRL to work on the problem back in the mid-90's, but unfortunately there was licensing disputes |
| 19:38.40 | kanzure | lamesauce |
| 19:38.56 | brlcad | maybe late 80's .. old history now |
| 19:39.27 | kanzure | i trust boole over, say, opencascade, for their intersection algorithm.. since at least this one is documented |
| 19:39.31 | brlcad | the goal was primarily nurbs raytracing and I think our current implementation easily beats it hands down |
| 19:39.48 | kanzure | i'm honestly surprised how there is no simple, well-written, well-documented, open source brep-brep intersection software |
| 19:40.06 | kanzure | this isn't *that* hard |
| 19:40.32 | brlcad | a lot of the surface surface intersection calculations were needed to get accurate ray-tracing, so you might be able to repurpose some of the ray-tracing code into a more general surface-surface intersection function |
| 19:40.55 | kanzure | i was thinking of implementing boole but i see there's a good start here |
| 19:40.58 | brlcad | it's hard to do robustly :) |
| 19:41.16 | kanzure | i think robustness can be sacrificed at first for a working system, and then robustness can be designed in for a 2.0 |
| 19:41.35 | kanzure | once we have someone, anyone, who is working on open source code that has successfully implemented any of this :) |
| 19:42.00 | brlcad | that's just it, it's not really working if it's not robust -- the best you can do is limit yourself to robustness across simple geometry |
| 19:42.08 | brlcad | like two spheres or two boxes |
| 19:42.22 | kanzure | do you mean practically robust or the academic version of "robust by proof"? ;) |
| 19:42.27 | kanzure | er, robust by theorem |
| 19:42.28 | brlcad | even robustly answering whether that pairing intersect or not .. tricky |
| 19:42.36 | brlcad | practically robust |
| 19:42.50 | brlcad | if you want provably, you need different numerics |
| 19:42.57 | brlcad | CGAL-style |
| 19:43.04 | brlcad | slow fixed arithmetic |
| 19:43.57 | brlcad | if you want to pick up the torch working in src/proc-db or elsewhere related to this, lemme know and I'll set you up |
| 19:44.14 | kanzure | what do you mean set me up? |
| 19:44.47 | brlcad | with commit access, so you can work on test code in src/proc-db for example |
| 19:45.51 | brlcad | if you want to do your own thing out of repo, that's cool too, but it is nice to see the commits to see rationale behind development directions |
| 19:45.54 | kanzure | i don't have anything to commit at the moment but i'll ping you |
| 19:46.02 | kanzure | that's true.. |
| 19:46.26 | brlcad | whatever works |
| 19:46.45 | kanzure | so you're ok with incomplete/dysfunctional code commits? |
| 19:47.00 | brlcad | in src/proc-db yes |
| 19:47.07 | brlcad | in src/lib* no |
| 19:47.20 | brlcad | unless it's #ifdef's out of course |
| 19:47.45 | brlcad | just shouldn't affect production use until it's reasonably well tested |
| 19:48.05 | brlcad | otherwise, visibility and communication ftw |
| 19:50.35 | kanzure | okay. |
| 19:50.48 | kanzure | sure, i'll take some svn commit access goodness |
| 19:52.05 | brlcad | done |
| 19:52.07 | brlcad | you've been around here long enough to know how we operate, not exactly a loose canon |
| 19:52.20 | brlcad | just don't break stuff :) |
| 19:52.28 | brlcad | read HACKING for the rest |
| 19:52.39 | brlcad | and/or ask |
| 20:03.15 | kanzure | okie dokie |
| 20:05.53 | *** join/#brlcad mafm (~mafm@48.Red-83-63-197.staticIP.rima-tde.net) | |
| 20:14.35 | kanzure | brlcad: did you add my sourceforge account? |
| 20:22.26 | brlcad | yep |
| 20:22.26 | CIA-105 | BRL-CAD: 03erikgreenwald * r44481 10/geomcore/trunk/src/interfaces/cl/gsserver.lisp: use defvar instead of defparameter (to avoid clobbering a live recompile conflict). Use global variable notation instead of constant. |
| 20:22.32 | brlcad | try a test commit |
| 20:25.06 | kanzure | i'd rather not muddy up commit history |
| 20:26.04 | brlcad | heh |
| 20:26.30 | brlcad | it's a huge history, not really going to be noticed :) |
| 20:26.53 | CIA-105 | BRL-CAD: 03erikgreenwald * r44482 10/geomcore/trunk/src/libgvm/repo.c: return 0 on success (instead of stack trash since there was no explicit return on success) |
| 20:27.09 | brlcad | https://sourceforge.net/mailarchive/forum.php?forum_name=brlcad-commits <-- per month commit stats |
| 20:28.21 | brlcad | wow, we hit a new record in january .. 914, nifty! |
| 20:42.02 | ``Erik | ah, svn_repos_open doesn't open the file, each operation opens and closes the file described by the repo struct... brutal |
| 20:49.05 | bhinesley | while (1) {touch . ; svn commit -M "testing"} |
| 20:49.13 | bhinesley | this month promises to be even better ;) |
| 20:49.43 | brlcad | heh, nice try |
| 20:50.12 | brlcad | that wouldn't commit a change, and you'll get invalid option on the -M ;) |
| 20:51.22 | ``Erik | can't think of a shell that'd eat that |
| 20:51.53 | brlcad | while `true` ; do echo "==$RANDOM==" >> file ; svn commit -m "+1" file ; cat file | sed 's/==.*==//g' > file ; done |
| 20:52.06 | *** join/#brlcad merzo (~merzo@7-32-94-178.pool.ukrtel.net) | |
| 20:52.17 | bhinesley | you guys are too much |
| 20:54.58 | *** join/#brlcad mafm (~mafm@48.Red-83-63-197.staticIP.rima-tde.net) | |
| 20:54.59 | starseeker | never give brlcad a shell script challenge |
| 21:00.36 | ``Erik | it's just another language *shrug* a repl based one, even |
| 21:01.30 | kanzure | brlcad: now that i look at it, BrepBrepIntersect doesn't actually use its (brep) "out" variable |
| 21:02.08 | kanzure | err, (ON_Brep) type |
| 21:02.55 | brlcad | kanzure: yep, I vaguely recall having to mark that as UNUSED during a strictness pass |
| 21:03.02 | kanzure | ah. |
| 21:03.04 | kanzure | fooey |
| 21:03.09 | brlcad | fix it ;) |
| 21:03.15 | brlcad | or rewrite |
| 21:03.26 | kanzure | if it wasn't using opennurbs, i'd immediately rewrite it on my own |
| 21:03.43 | kanzure | but.. since he did at least go to the trouble of making this slightly maintainable.. |
| 21:03.55 | brlcad | opennurbs is actually a pretty nice api to work with |
| 21:04.16 | kanzure | sure |
| 21:04.22 | brlcad | most of the annoying aspects have been things that were intentionally removed |
| 21:04.30 | kanzure | yes |
| 21:04.36 | kanzure | ON_GL... grr |
| 21:04.48 | ``Erik | nice, the acknowledgements section in the scsh manual... awesome |
| 21:05.19 | brlcad | do they thank the flying spagetti monster? |
| 21:05.49 | ``Erik | http://www.scsh.net/docu/html/man.html |
| 21:07.21 | brlcad | haha |
| 21:18.06 | brlcad | hm, sanity check: unsigned char cp; cp + 4 == &cp[4] ? |
| 21:22.11 | ``Erik | yup |
| 21:23.51 | brlcad | then the only diff between our conversions is you wrapped the cast in parens |
| 21:24.31 | brlcad | I'm thinking the bug was actually an unrelated change made to rt_nmg_reindex() in the same commit |
| 21:24.49 | brlcad | upgraded return type from int to long including two index vars |
| 21:26.40 | brlcad | the parens shouldn't matter because arrow has higher precedence than the cast, so it's already grouped |
| 21:27.01 | brlcad | otherwise we match line for line |
| 21:27.08 | brlcad | gotta be rt_nmg_reindex() .. hrm |
| 21:29.29 | brlcad | either way, nice fix ``Erik .. librt can be restrictified |
| 21:34.45 | *** join/#brlcad bhinesley (~bhinesley@99.104.168.20) | |
| 21:42.23 | CIA-105 | BRL-CAD: 03starseeker * r44483 10/brlcad/trunk/src/librt/CMakeLists.txt: Erik restored the strict building. |
| 22:05.34 | starseeker | ah, that's why - the default implementation of opennurbs_memory.c is a straight-up malloc/calloc/etc. wrapper |
| 22:11.49 | brlcad | starseeker: another approach for the itcl/package problem -- take it to the natural limit, shouldn't be calling either from C-land |
| 22:11.51 | CIA-105 | BRL-CAD: 03brlcad * r44484 10/brlcad/trunk/src/librt/Makefile.am: ditto for now |
| 22:12.08 | brlcad | make the scripts package require what they need |
| 22:12.15 | starseeker | true... |
| 22:25.19 | starseeker | er... this is not good. Probably the best way to set this up would be to use the apr memory pools, since we need variable sizes |
| 22:25.23 | starseeker | ick |
| 22:25.54 | starseeker | or custom roll our own |
| 22:32.38 | ``Erik | variable sizes? that doesn't tend to work well with pools, that's a full allocator |
| 22:34.22 | ``Erik | yeah, I've gotten in the habit of using parens whenever casting a referenced pieces just to verify it's all correct and obvious |
| 22:34.36 | ``Erik | piece |
| 22:34.54 | starseeker | ``Erik: it seems the technical term is "region based memory management" |
| 22:36.23 | starseeker | that's what the Apache Portable Runtime pools really are |
| 22:36.26 | ``Erik | if you have a finite set of sizes, you can do sets of pools... a 'buddy' allocator is pretty easy and quick, used to be the norm... system alloc usually uses slabs these days |
| 22:37.04 | ``Erik | 'region based' might mean slabs, just implemented outside of the kernel to avoid syscalls, maybe? *shrug* |
| 22:37.04 | starseeker | unfortunately, if we're going to put something behind the opennurbs on* functions (which we want to for improved performance) their API accepts arbitrary sizes |
| 22:37.48 | starseeker | the only thing that comes readily to mind is a hash table of pointers to pools, hashed by data type size |
| 22:39.09 | starseeker | basically, assume finite sizes in practice (if not in theory) and create whatever pools are needed - one per requested size |
| 22:39.12 | ``Erik | that'd be one wasteful way to do it... buddy system slicer on subpage chunks, mebbe with an occasional gc/compactor might be another |
| 22:39.36 | starseeker | looks up buddy allocator |
| 22:39.47 | ``Erik | (buddy system basically means a binary tree of memory, pick the best fit, dividing if needed) |
| 22:40.10 | ``Erik | and here we go, screaming to greenspuns tenth :D |
| 22:40.47 | starseeker | the quickest and most practical thing to do would be to stick APR behind opennurbs and see what kind of performance we get |
| 22:41.05 | starseeker | but that would tie our raytracing directly to the APR libraries as a dependency |
| 22:41.54 | ``Erik | isn't keen on that |
| 22:42.05 | starseeker | isn't either |
| 22:42.50 | ``Erik | do we know the typical size range that opennurbs wants? |
| 22:44.02 | starseeker | not really |
| 22:44.20 | ``Erik | as an experiment, we (and I mean you) could write a trivial allocator that does a big block alloc, sets a 'usual max' size and subdivides the memory into those sizes, so if it's 256 bytes, just return a 256 byte zone when 40 bytes is requested |
| 22:44.24 | ``Erik | wasteful, but easy |
| 22:44.28 | starseeker | my concern is if it's using onmalloc and friends to allocate storage for NURBS, the size range is going to be all over the map |
| 22:46.45 | ``Erik | could do a 'pass-through' allocator to instrument and record a history of allocs (or see if valgrind, efence, etc can be tortured into doing that) and compare with and without that for a test model? |
| 22:47.27 | starseeker | nods - or we might just do a data collection experiment - record all sizes requested and see how big the distribution really is |
| 22:47.38 | starseeker | I might be over-estimating the problem |
| 22:48.00 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177871947.dsl.bell.ca) | |
| 22:48.06 | ``Erik | yeh, I'd imagine you are :) profile before optimizing, right? |
| 22:49.54 | ``Erik | it'd be convenient if an automated tool could do that for you, instead of hand instrumenting the code |
| 22:50.41 | bhinesley | make well1.s rcc |
| 22:50.45 | bhinesley | oops sorry |
| 22:51.23 | brlcad | if you're messing with anything more complex than a simple bundling allocation pool (if even that), then you're probably doing something wrong |
| 22:51.59 | brlcad | who is doing the allocate? when? |
| 22:52.13 | starseeker | opennurbs - anytime onmalloc and friends are called |
| 22:52.19 | brlcad | which is when? |
| 22:52.30 | ``Erik | I think part of the evaluator for a shot hits one |
| 22:52.46 | starseeker | depends on whether you're overriding the C++ new or not - if you are, everytime anything is allocated in opennurbs |
| 22:52.52 | brlcad | evaluator that's called during prep, yes? |
| 22:53.35 | brlcad | find it hard to believe that malloc is being called during the trace .. performance would be very bad |
| 22:53.39 | starseeker | I believe so - I'd have to check if it's being called during the raytrace |
| 22:53.57 | brlcad | not just a little bad .. super bad, like almost nmg bad |
| 22:54.15 | brlcad | from I've seen interactive, that's just not possible |
| 22:54.17 | starseeker | brlcad: there is a new being called, I remember that from the Shark profiles, but it hit some geometries worse than others |
| 22:54.26 | brlcad | so if it's all prep, then you can pretty much control when you allocate |
| 22:54.33 | ``Erik | I was under the impression that shoot had one... and prep definitely needs sped up |
| 22:55.00 | brlcad | mm.. I'd focus on eliminating that single one during shot before even thinking about prep |
| 22:55.27 | ``Erik | if you're not freeing until the end, you can alloc a bit chunk and walk it linearly, if you request more than what's left, make a new one, ad the old one to a crap list and move on |
| 22:55.42 | ``Erik | big chunk |
| 22:55.47 | brlcad | nods |
| 22:56.19 | brlcad | that can even be done during prep |
| 22:56.29 | brlcad | at least for the initial chunk |
| 23:00.12 | *** part/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177871947.dsl.bell.ca) | |
| 23:00.48 | CIA-105 | BRL-CAD: 03starseeker * r44485 10/brlcad/trunk/src/librt/uvpoints.cpp: Add some timing and defaults. |
| 23:10.18 | starseeker | ah, looks like apr is using a more straightforward approach than I thought |
| 23:10.44 | starseeker | or wait... |
| 23:11.18 | starseeker | OK, well, either way something custom is needed - time to figure out how to set that up |
| 23:13.11 | ``Erik | the key is to limit the problem domain, if you try to be as generic as the libc stuff, you're trying to outsmart some incredibly smart guys O.o |
| 23:13.35 | starseeker | nods - I know, special allocation for special purposes |
| 23:17.53 | starseeker | huh, nifty: http://books.google.com/books?id=ukXrNh2g6fQC&pg=PA128&lpg=PA128&dq=APR+memory+pool+Boost&source=bl&ots=CF5TfwORRZ&sig=a6lt3dYZoPXYEaGRYIAb6mS3asU&hl=en&ei=J6uwTYvuBIeUtweqotDzCw&sa=X&oi=book_result&ct=result&resnum=3&ved=0CCYQ6AEwAg#v=onepage&q=APR%20memory%20pool%20Boost&f=false |
| 23:48.45 | brlcad | starseeker: do you have a profile? |
| 23:49.20 | starseeker | no, Shark is busted on my machine at the moment :-( |
| 23:49.21 | brlcad | I know we constantly say "allocations are bad" .. but they are totally trumped by algorithmic complexity analysis |
| 23:49.28 | starseeker | working off of memory from last year |
| 23:49.53 | starseeker | I suppose it's time to upgrade and get everything fixed |
| 23:50.34 | brlcad | e.g., it may be spending most of it's time calling malloc, but if it's because of some O(N^3) algorithm then it may be calling malloc 10-1000 times more than it actually needs to |
| 23:51.32 | starseeker | nods |
| 23:52.30 | brlcad | case in point was my nmg fix a few months bad .. nmg is relatively slow due to allocations, but was being really stupid reallocating over and over unnecessarily (by two orders of magnitude) .. cut a 5-day run down to half hour, all without changing the way allocations occur even though that's where most of the time was spent |
| 23:52.46 | brlcad | changed why it was allocating in the first place |
| 23:53.28 | brlcad | shark is awesome, but gprof can give insight too |
| 23:53.42 | brlcad | if you copied configure, it's the -pg profile option |
| 23:55.02 | starseeker | in cmake it's BRLCAD-ENABLE_PROFILING |
| 23:55.07 | starseeker | tests... |
| 23:58.58 | starseeker | I'm not actually messing with BRL-CAD's raytracing yet - I'm trying to get a feel for how my test uvpoints.cpp file is behaving |
| 00:01.27 | brlcad | gprof excels at function-level analysis |
| 00:01.42 | starseeker | growl... for whatever reason, that's not working on the mac either |
| 00:01.50 | starseeker | either in isolation or as part of the build |
| 00:01.58 | starseeker | to linux... |
| 00:02.35 | brlcad | TODO: fix profiling option :) |
| 00:03.05 | brlcad | (presuming you're using gprof right) |
| 00:03.28 | starseeker | yep, but I'm assuming it's my mac's fault until proven otherwise |
| 00:04.26 | brlcad | unlikely, it's not like shark |
| 00:04.55 | brlcad | it's not cpu metrics, it injects code around all your functions |
| 00:05.14 | brlcad | so if gcc works, it should work |
| 00:05.26 | starseeker | gprof works on inux |
| 00:05.29 | starseeker | linux even |
| 00:07.03 | brlcad | ok, whatever works |
| 00:09.25 | starseeker | must... fix... mac... |
| 00:10.47 | starseeker | yeah, ok - my uvpoints.cpp file is wasting most of its time with strings |
| 00:10.53 | starseeker | no wonder |
| 00:19.57 | brlcad | (fwiw, "using std namespace" is evil) |
| 00:20.10 | brlcad | er, using namespace std; |
| 00:20.22 | starseeker | I know - it's just a test program, not intended for production in its current form |
| 00:20.31 | brlcad | ah, interesting |
| 00:20.52 | starseeker | scratchpad for experimenting with uv coordinates, memory pools, etc. without the complexity of the SurfaceTree |
| 00:20.55 | brlcad | perhaps a less on references, pointers, and std:: data types :) |
| 00:21.06 | brlcad | damn, can't type tonight |
| 00:21.15 | brlcad | lesson |
| 00:21.18 | starseeker | winces - yeah, I'm quite sure I'm using it all wrong |
| 00:21.29 | brlcad | you're passing std::string in and out of functions |
| 00:21.41 | brlcad | that makes a copy of the string every function call |
| 00:21.47 | brlcad | and every return |
| 00:22.00 | brlcad | malloc-style |
| 00:22.29 | brlcad | you want to either pass around std::string*'s or std::string&'s depending on the use |
| 00:22.53 | brlcad | depends who creates the string and how it's used |
| 00:23.37 | brlcad | safest is to pass a pointer, but best is usually a ref .. but then you have to be more careful on how it's accessed and stored |
| 00:24.57 | starseeker | nods - any good tutorials? |
| 00:25.08 | brlcad | e.g. UVKey::UVKey() is fine taking a std::string newkey (so it'll make a copy on construction), but UVKey::getKey() should return a std::string& |
| 00:31.52 | CIA-105 | BRL-CAD: 03starseeker * r44486 10/brlcad/trunk/src/librt/uvpoints.cpp: Try returning a reference |
| 00:31.55 | starseeker | brlcad: like that? |
| 00:32.34 | brlcad | yeah, that's better |
| 00:33.17 | brlcad | one thing to remember, that change now changes the contract for UVKey -- it's no longer just a string, it's UVKey's string |
| 00:33.37 | starseeker | nods - that was the idea originally, actually |
| 00:33.43 | brlcad | so if you delete UVKey, any references to a std::string from getKey() would be dangling references (invalid) |
| 00:33.47 | starseeker | yow, string comparison is brutal |
| 00:35.26 | brlcad | yeah, that was my next question .. what's up with string keys?? |
| 00:35.33 | brlcad | numeric ftw |
| 00:35.41 | starseeker | they're UV coordinates |
| 00:36.40 | brlcad | so? |
| 00:36.50 | starseeker | I don't recall the original motivator - I think it was to make it easier to mash together two pairs into one unique descriptive string |
| 00:36.52 | brlcad | yeah, AppendKeys() .. nfg |
| 00:37.25 | brlcad | ints_to_key looks like some sort of string-based hash |
| 00:37.51 | brlcad | just store them into a u,v array, O(1) lookups |
| 00:38.01 | starseeker | ah, right - 0100 and 0001 don't convert to different integers |
| 00:38.34 | starseeker | and those strings are the keys for a minimal perfect hash |
| 00:39.01 | brlcad | perfectly inefficient maybe :) |
| 00:39.07 | starseeker | probably I should stash them as numbers and only build the strings when I need to |
| 00:39.57 | starseeker | the original effort there was to find unique identifiers for all the UV points that might get evaluated into 3-space during a subdivision of depth N |
| 00:40.15 | brlcad | either way, even as a perfect hash, shouldn't have a sprintf() call in there for generating a hash (heck, shouldn't need to manually hash yourself anyways) |
| 00:40.17 | starseeker | because there are a lot of shared points, I wanted a good way to avoid duplicate evaluations |
| 00:41.13 | brlcad | the std:: container hashing is pretty frickin good |
| 00:41.40 | starseeker | the simplest way to avoid duplicates was to have a way for any subdivision, at any depth up until the maximum depth, be able to look up a given UV coordinate to see if it had been evaluated |
| 00:42.32 | brlcad | you probably want a std::map |
| 00:43.09 | brlcad | heck, maybe even a simple std::map<u, std::map<v, value> > |
| 00:43.23 | starseeker | how fast are those lookups? |
| 00:43.33 | brlcad | guaranteed to be at least logN iirc |
| 00:43.57 | starseeker | in theory, if I understand correctly, a minimal perfect hash is O(1) |
| 00:44.50 | starseeker | and as a tree deepens, we can build up a LOT of points and do a LOT of lookups |
| 00:46.06 | starseeker | so a minimal perfect hash of a unique string descriptor of the UV coordinates, which is possible because we know the candidate sites that might be evaluated in advance, allows us to generate such a hash up front |
| 00:46.38 | brlcad | if it's O(1) lookup and O(insane) to generate the hash, you've kinda missed the boat |
| 00:46.56 | brlcad | that's still just the minimum guarantee |
| 00:47.02 | starseeker | except the hash only has to be generated at compile time |
| 00:47.13 | brlcad | you mean prep? |
| 00:47.18 | starseeker | no, compile |
| 00:47.22 | starseeker | source code compile |
| 00:47.38 | brlcad | er, there's no such thing going on in your code there now |
| 00:47.43 | starseeker | right |
| 00:47.56 | starseeker | because it was early days when I had to shift to other stuff |
| 00:48.14 | starseeker | but it DOES generate the keys.txt file, which contains the full list of unique keys |
| 00:48.31 | brlcad | if there is a limited set of hash sites, why not just direct index into a set then? |
| 00:49.25 | starseeker | all I know when I'm subdividing is the UV coordinates of the point I'm at - I have to map that to some index value |
| 00:49.37 | brlcad | i'd still try the std::map first -- dead simple implementation, easy to maintain, and really good performance behavior guarantees |
| 00:50.42 | brlcad | so the idea sounds fine, but it shouldn't be based on or involve strings |
| 00:51.47 | starseeker | uh... the string is key for hashing - apparently hashing numbers usually doesn't work out well |
| 00:52.11 | starseeker | my problem is I'm storing the info as a string, which is wrong |
| 00:52.12 | brlcad | http://www.sgi.com/tech/stl/hash_set.html |
| 00:52.42 | brlcad | again, configurable key type, even configurable hash function |
| 00:53.26 | brlcad | a hash set of hash maps perhaps for u,v to value mapping |
| 00:53.29 | brlcad | http://www.sgi.com/tech/stl/hash_map.html |
| 00:53.43 | brlcad | or hash_map of hash_maps |
| 00:59.07 | brlcad | the tradeoff with a std::map<> is that std::hash_map<> will be faster (O(1) on average O(N) worst case even with perfect hashing, have to account for collisions) but it's not in any particular order if you need to iterate or search |
| 00:59.48 | brlcad | so find *this* UV is fast.. finding your closest neighbor will be relatively expensive |
| 01:00.25 | starseeker | nods - so far there hasn't been a need for nearest UV neighbor (famous last words...) |
| 01:00.56 | starseeker | brlcad: let me see if I can take strings out of what I'm doing now, at least up until keys.txt is generated |
| 01:01.04 | starseeker | that works in the right direction regardless |
| 01:01.52 | starseeker | once I'm doing that right, we can tangle with the various hashing/mapping options |
| 01:08.04 | starseeker | the minimal perfect hash appeals to me because with this situation we don't NEED to have any collisions, but I suppose I could be full of... err... converted dog food too |
| 01:14.28 | *** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net) | |
| 02:31.04 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1128565712.dsl.bell.ca) | |
| 03:22.05 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 04:29.39 | starseeker | brlcad wins - will investigate stl map tomorrow, then look into hash_map if that's not enough |
| 04:29.55 | starseeker | braces for another C++ learning curve |
| 05:06.15 | brlcad | it's important enough to warrant a simple performance comparison |
| 06:14.42 | brlcad | starseeker: here's a code snippet I just whipped up for you to play with |
| 06:15.35 | brlcad | shows how to use map, hash map, and shows the comparative performance of each |
| 06:41.24 | brlcad | http://brlcad.org/tmp/hasher.cxx |
| 06:42.42 | brlcad | just for kicks, I stubbed in some code sort of showing worst case and best case perfect hashing .. though the devil is truly in the details for all of them since a simple datatype change or iteration change can completely skew the comparison |
| 06:44.12 | brlcad | only played two use-case scenarios, setting and reading .. not iterating over all, nearest neighbor, deletions, etc |
| 06:45.30 | brlcad | also using the non-bounds-checked [] operator instead of insert(), find(), and other functions |
| 06:46.55 | brlcad | I'd suggest looking at a real worst case trace, see how many insertions/lookups/deletions and what the tree looks like -- shallowest, average, deepest |
| 06:47.10 | brlcad | then mapping that into a test program simulating the same behavior |
| 06:50.51 | brlcad | should hopefully be a little more clear how/why I think map or unordered_map will probably be more than "good enough" given how much simpler they are to run with .. and if not, looking into exactly why |
| 07:33.21 | *** join/#brlcad Stattrav (~Stattrav@117.202.22.183) | |
| 07:33.21 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:10.31 | *** join/#brlcad crazy_imp (~mj@a89-182-215-216.net-htp.de) | |
| 08:28.56 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 08:30.38 | *** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no) | |
| 09:38.38 | *** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net) | |
| 11:35.09 | ``Erik | *readreadread* obsessing over a perfect hash may be self defeating... also; O() is just one of the bits to consider, there are 5 categories of asymptotic notation. qsort is a poor performer on O(), but awesome in real life (omega is tight, k is low, etc) |
| 11:40.48 | ``Erik | hm, no system hash funcs in your demo, brlcad? md5? sha1? :) |
| 12:45.34 | starseeker | brlcad: thanks for the demo - that will be a big help |
| 12:48.28 | starseeker | hmm... u+v won't work, isn't unique 0 + 1 = 1 + 0... probably need something like u * (some power of 10) + v |
| 12:48.52 | starseeker | that's a detail though |
| 12:49.20 | starseeker | rummages around for some energy and gets moving |
| 13:13.00 | ``Erik | collisions may be acceptable... ergo; quadratic (http://en.wikipedia.org/wiki/Quadratic_probing) or chained (each hash bin is a linked list) |
| 13:17.15 | *** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net) | |
| 13:33.11 | brlcad | starseeker: it'll "work" .. it's just a really really bad hash :) |
| 13:33.15 | brlcad | lots of collisions |
| 13:33.31 | brlcad | more showing the full range of impact it can have |
| 13:34.06 | brlcad | with the right hash, you approach the best case instant update time of an array but worst case can be an order worse than a simple map |
| 13:34.54 | brlcad | all the more motivation to just stick with the algo that makes most sense |
| 13:36.35 | brlcad | the data is a simple mapping of uv keys to a 3dpoint, so the immediate thought that comes to mind is std::map<std::pair<int, int>, vect_t> |
| 13:37.56 | brlcad | (do not use ON_3dpoint .. it's got lots of junk, you can set the vect_t direct on read: vect_t v = VINIT_ZERO; ON_3dpoint p = v; ON_3dpoint *pp = new ON_3dpoint(v); |
| 13:38.25 | brlcad | they added operator support for getting the value from a double* |
| 13:46.10 | brlcad | good exercise for the reader to attempt adding std::map<std::pair<int, int>, vect_t> and using proper std::map::iterator instead of using the [] operator .. you'll get a lot of insight |
| 13:57.11 | brlcad | then switch it to [] and compare :) |
| 14:31.14 | *** join/#brlcad dli (~dli@67.55.46.44) | |
| 14:46.25 | starseeker | brlcad: the map is good if we need things like nearest-neighbor? |
| 14:48.17 | starseeker | wonders if triangulation might just want that information, even if we don't need it for raytracing |
| 15:25.06 | ``Erik | r-tree is the shizzle for nearest neighbor |
| 15:25.12 | *** join/#brlcad Stattrav (~Stattrav@117.202.18.42) | |
| 15:25.12 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:25.41 | ``Erik | but data repacking should never take more than nlgn |
| 15:25.59 | ``Erik | poor cats, still reeling from the bathing this morning |
| 15:43.01 | starseeker | ``Erik: this should appeal to your bit-level side - can I take a floating point value and map it to an int simply? |
| 15:43.38 | starseeker | std::map is slow with floats, but for storage the important thing is to have an easy, unique identifer |
| 15:44.15 | starseeker | if the UV floating point coordinates can be mapped to integers... |
| 15:45.30 | starseeker | I hadn't properly considered what wanting to split first on the knot points implies - it pretty much trashes my subdivision gridding coordinate scheme |
| 15:46.34 | starseeker | might be able to get away with just being aware of which leaves contain knots, but more general solution of being able to pick any given UV point, subdivide using it, and using the std::map or something like it all the while sounds nice |
| 15:53.03 | *** part/#brlcad willdye (~willdye@198.183.6.23) | |
| 16:27.29 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 17:35.13 | *** join/#brlcad Stattrav (~Stattrav@117.202.18.42) | |
| 17:35.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:47.37 | starseeker | hmm... http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm |
| 18:45.43 | kanzure | did commercial CAD packages ever take more than a few seconds to do a boolean operation on two solids? |
| 19:08.49 | starseeker | kanzure: I doubt it... |
| 19:12.44 | kanzure | hrm. weird. i'm reading some papers from the 90s where these programmers are cheering because they can merge a few meshes "IN ALMOST EIGHT SECONDS!!" |
| 19:13.03 | kanzure | on some sort of sgi onyx machine (200 mhz.. etc.) |
| 19:17.49 | bhinesley | I'm off to the beach for the weekend. Have a good weekend, everyone. |
| 19:25.24 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 19:36.48 | kanzure | wow "CATIA uses polyhedral approximations for intersection and boundary computations" |
| 19:38.36 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 19:44.36 | kanzure | "We then use the trapezoidation of the trimming polygon (using Seidel's algorithm) to perform logarithmic time point location queries. |
| 19:44.39 | kanzure | "However, the accuracy of this result depends on the magnitude of errors introduced by approximating the high degree trimming curve through the boundary of the Gaudl invariants." |
| 19:44.43 | kanzure | ok i give up on this paper |
| 19:45.42 | starseeker | kanzure: which paper? |
| 19:45.53 | kanzure | one of krishnan's |
| 19:46.14 | kanzure | i'll use his other one where he uses matrix math for constructing the intersection curve |
| 20:39.27 | starseeker | brlcad: looks like the pair iteration is slightly slower, I'm assuming due to the make_pair overhead: http://brlcad.org/~starseeker/map_test.cxx |
| 20:43.37 | starseeker | I can't get the iterator to work thus far |
| 20:56.05 | starseeker | ah, there we go - I THINK that works... anyway, if I do full assignment instead of using drand48 the count returned seems to match up |
| 21:00.53 | starseeker | hmm, interesting - iterator is faster if I replace drand48 with i in the insertion loops |
| 21:01.03 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 22:26.36 | ``Erik | hm, you could always do floor() or ceiling()... could also grab a bit mask ( ((uint320t)f) >> 16) ) |
| 22:26.52 | ``Erik | s/0/_/ |
| 22:27.51 | starseeker | ``Erik: actually, even the worst case floating point performance may not be a showstopper - plus, it looks like to get performance benefit the data type in question needs to be small anyway |
| 22:29.22 | starseeker | suspects, based on conversations concerning STL libraries, that they probably are doing whatever the sanest thing is for floats under the hood |
| 22:30.25 | ``Erik | the guys who did stl are pretty good... don't try to outsmart them, the key is to not use their stuff wrong... |
| 22:31.06 | starseeker | nods |
| 22:31.24 | ``Erik | at the moment, we assume a full fpu... I'm sure BRL-CAD on my arm7 would suck arse |
| 22:31.40 | starseeker | heh |
| 22:32.02 | ``Erik | http://brlcad.org/~erik/20110422/ they are not happy :) |
| 22:32.31 | starseeker | hehe |
| 23:04.18 | brlcad | starseeker: excellent that you got the pair working along with iterators |
| 23:04.28 | brlcad | that was more the point than actual performance |
| 23:05.07 | brlcad | make_pair() is probably injecting a tiny overhead, you'd probably just call the pair<> constructor directly where you can set values by const reference instead of by value |
| 23:06.18 | brlcad | the other thing you should try is printing the pair values through the iterator |
| 23:06.43 | brlcad | instead of just incrementing counter, try to use the iterator |
| 23:22.45 | ``Erik | if I groked correctly, iterator classes are insanely efficient once invoked... a machine optimizable deref, iirc |
| 23:23.31 | ``Erik | same level of machine nerdiness as a ^= b ^= a ^= b |
| 00:55.10 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 02:24.03 | *** join/#brlcad crazy_im1 (~mj@a89-182-219-8.net-htp.de) | |
| 04:48.49 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 05:41.01 | *** join/#brlcad Stattrav (~Stattrav@117.192.140.160) | |
| 05:41.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:28.01 | *** join/#brlcad Stattrav (~Stattrav@117.192.141.32) | |
| 06:28.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:16.57 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:13.08 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:50.21 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 17:54.51 | *** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net) | |
| 00:52.43 | *** join/#brlcad Josko (~Josko@JSO5040.rhbd.psu.edu) | |
| 00:57.07 | Josko | How can I go about participating in the code cleanup effort following the FULL valid Coverity scan? |
| 01:28.46 | *** join/#brlcad Josko (~Josko@JSO5040.rhbd.psu.edu) | |
| 01:34.37 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 01:51.20 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) | |
| 02:29.04 | *** join/#brlcad crazy_imp (~mj@a89-182-28-75.net-htp.de) | |
| 04:39.28 | *** join/#brlcad nat_ (~nat@77.209.179.132) | |
| 04:58.03 | *** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net) | |
| 05:01.30 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 07:26.18 | *** join/#brlcad dli (~dli@67.55.46.44) | |
| 19:19.56 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 19:19.56 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412) | |
| 19:21.27 | CIA-105 | BRL-CAD: 03starseeker * r44490 10/brlcad/trunk/CMakeLists.txt: Ignore new hacking file |
| 20:02.29 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 20:34.53 | CIA-105 | BRL-CAD: 03erikgreenwald * r44491 10/geomcore/trunk/src/interfaces/cl/gvm.lisp: fix export names. Add a gvm-open convenience function. |
| 20:36.02 | CIA-105 | BRL-CAD: 03erikgreenwald * r44492 10/geomcore/trunk/src/interfaces/cl/ (gsserver.asd gsserver.lisp): use gvm to move files over (still entire .g file at a whack) |
| 21:02.56 | CIA-105 | BRL-CAD: 03starseeker * r44493 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_CPackOptions.cmake.in): Take a stab at using CPack options to get the directory structure we want. |
| 22:48.26 | kanzure | brlcad: after playing with BOOLE-1.1 a bit, i've found that their code fails on very simple tests |
| 22:48.41 | kanzure | for instance, taking the union of two cones works for the initial values that they provide in the example file, |
| 22:49.01 | kanzure | but if you move the center of the first cone by 0.1 in z, it claims the intersection curve isn't closed |
| 22:50.04 | kanzure | i'm hoping this is just a floating point arithmetic precision issue.. but so far i haven't been able to track this down |
| 22:50.16 | kanzure | if the algorithm fails for such basic operations then i don't see a point in using it |
| 00:16.01 | starseeker | kanzure: yeah, boole isn't the way for us to go these days |
| 00:31.15 | kanzure | esolid compiles and the visualizer works. yikes |
| 00:31.33 | kanzure | does anyone know about esolid's licensing? i can't find a license or copyright file anywhere |
| 01:04.26 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177871751.dsl.bell.ca) | |
| 02:29.50 | *** join/#brlcad crazy_imp (~mj@a89-182-207-95.net-htp.de) | |
| 03:21.24 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 06:41.04 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 06:46.22 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 07:35.56 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 08:17.25 | *** join/#brlcad mafm (~mafm@36.Red-81-35-69.dynamicIP.rima-tde.net) | |
| 10:00.13 | CIA-105 | BRL-CAD: 03davidloman * r44494 10/geomcore/trunk/include/ (GeometryManifestMsg.h NetMsg.h PingMsg.h PongMsg.h): Clean up some unused includes. |
| 10:02.02 | CIA-105 | BRL-CAD: 03davidloman * r44495 10/geomcore/trunk/src/libNet/netMsg/ (PingMsg.cxx RemoteNodenameSetMsg.cxx): Clean up a few more unused includes. |
| 10:29.29 | *** join/#brlcad csanyipal (~csanyipal@226-170-85-95.dynamic.stcable.net) | |
| 10:29.37 | csanyipal | Hi, |
| 10:32.44 | csanyipal | I'm reading SVN/brlcad/doc/legal/bdl.txt, bsd.txt, lgpl.txt and want to know, whether can I use the html documents in a Moodle course of BRL-CAD? |
| 11:07.19 | CIA-105 | BRL-CAD: 03davidloman * r44496 10/geomcore/trunk/tests/unit/utility/ (ByteBufferUTest.cxx ByteBufferUTest.h): Clean up extra newlines |
| 11:18.51 | *** join/#brlcad mafm_ (~mafm@36.Red-81-35-69.dynamicIP.rima-tde.net) | |
| 11:20.13 | CIA-105 | BRL-CAD: 03davidloman * r44497 10/geomcore/trunk/tests/unit/libnet/ (4 files): Drop the 's' from Msgs |
| 11:22.29 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 11:57.16 | brlcad | csanyipal: you sure can -- most of the docs are either bsd-licensed or public domain |
| 11:57.37 | csanyipal | brlcad: thanks! :) |
| 12:08.58 | brlcad | kunigami, bhinesley congratulations and thanks :) |
| 12:09.26 | brlcad | you guys were the clear choices |
| 12:10.24 | brlcad | as for mentors, keep in mind that you can and SHOULD utilize the mentoring resources of any brl-cad developer |
| 12:11.00 | brlcad | the one assigned is merely the one that will likely be tracking your progress and filling out your evals, but technical assistance is from all |
| 12:30.42 | starseeker | kanzure: I'd try the contact emails: http://research.cs.tamu.edu/keyser/geom/esolid/releases/version_0.3/README.htm see if they'd be OK with LGPL or BSD license |
| 12:31.43 | starseeker | kanzure: bear in mind esolid is sssslllooowww, if what I remember about it is accurate. It's not a method we'd want to rely on except perhaps as a last-ditch fallback |
| 13:09.46 | CIA-105 | BRL-CAD: 03davidloman * r44498 10/geomcore/trunk/ (4 files in 3 dirs): No reason for GSUUID to take a pointer to a string. |
| 13:14.49 | starseeker | asc2g isn't processing the attr command using ged_attr |
| 13:37.46 | CIA-105 | BRL-CAD: 03davidloman * r44499 10/geomcore/trunk/src/utility/ByteBuffer.cxx: Make ByteBuffer::toHexString() format the hex string properly. |
| 13:51.33 | CIA-105 | BRL-CAD: 03davidloman * r44500 10/geomcore/trunk/ (6 files in 5 dirs): Make GSUUID::toString return a string, not a pointer. All uses of this call were simply dereferencing the pointer anyway, and most weren't releasing the memory. Keeping it simpler this way. |
| 13:54.17 | CIA-105 | BRL-CAD: 03davidloman * r44501 10/geomcore/trunk/tests/func/ (3 files in 3 dirs): More GSUUID::toString() pointer dereferencing. |
| 13:56.52 | CIA-105 | BRL-CAD: 03starseeker * r44502 10/brlcad/trunk/src/libged/attr.c: Standardize the avs used by attr set - this still isn't fixing asc2g, which uses an older style API of some sort. |
| 14:05.18 | CIA-105 | BRL-CAD: 03davidloman * r44503 10/geomcore/trunk/tests/unit/ (5 files in 2 dirs): Rename NetMsgUTest to TypeOnlyMsgUTest for clarity. Finished implementing TypeOnlyMsgUTest. Will serve as the baseline test for all netmsg subclasses. |
| 14:05.35 | ``Erik | hm, if I understand correctly, passing a class by value creates a copy on the stack (with a constructor call) and destructor on return, that's why I was going pointer happy (defining pass by reference is a different way to invoke pointer shtuff, iirc... been a long time) |
| 14:07.20 | dloman_ | understood, however the more pointers there are, the much higher chance there is of a leak. So i simplified a bit. If its a perf hit, then someone can optimize later :) |
| 14:10.19 | ``Erik | *shrug* *pats the lithp version, with generational compacting garbage collection* |
| 14:10.53 | dloman_ | oh how i wish i could have used a language with memory management :) |
| 14:11.03 | ``Erik | java's gc is pretty good if you remember to set the turds to null when you're done with them... d'no about recently, but it USED to get confused and leave them |
| 14:11.49 | dloman_ | ya. it will still gs them, but it takes a significant amount of additional checks to figger out if the pointer isn't being used anymore |
| 14:11.50 | ``Erik | cyclic references with no top level heap walk, etc |
| 14:12.29 | ``Erik | hm, probably using ref counting for the first few generations, then a heap walker of some kind in the older generations, or 'on occasion' |
| 14:12.38 | dloman_ | exactly |
| 14:12.54 | dloman_ | which is why the young gneneration gc is wicked fast. |
| 14:13.51 | dloman_ | been looking at C# a lot recently. rather interesting langauge |
| 14:13.54 | CIA-105 | BRL-CAD: 03davidloman * r44504 10/geomcore/trunk/tests/unit/libnet/TypeOnlyMsgUTest.cxx: Ooops. Forgot to update the header include! |
| 14:14.01 | ``Erik | btw, why are ya shuffling a 128 bit number around as a hex string? (uuids) |
| 14:14.38 | dloman_ | cause i haven't gotten around to just writing the bytes to the ByteBuffer yet. keeps the debugging of the proto easier too. |
| 14:15.28 | ``Erik | kinda likes the notion fo starting out as a pure ascii format, then having a command to switch to a tight binary |
| 14:15.41 | ``Erik | so you can get the protocol sorted using telnet :) |
| 14:15.45 | CIA-105 | BRL-CAD: 03davidloman * r44505 10/geomcore/trunk/tests/unit/libnet/TypeOnlyMsgUTest.cxx: Again... wrong header. |
| 14:16.17 | dloman_ | well, i have a severe lack of experience with this, hence the severe lateness. :/ |
| 14:26.22 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) | |
| 14:27.40 | CIA-105 | BRL-CAD: 03davidloman * r44506 10/geomcore/trunk/tests/unit/ (4 files in 2 dirs): Compact test classes down to single files instead of class impl and header pairs. |
| 14:30.51 | CIA-105 | BRL-CAD: 03davidloman * r44507 10/geomcore/trunk/tests/unit/ (libnet/TypeOnlyMsgUTest.cxx utility/ByteBufferUTest.cxx): CPPUNIT_TEST_CUITE_REGISTRATION() calls are supposed to be *after* class declaration. |
| 14:42.38 | CIA-105 | BRL-CAD: 03davidloman * r44508 10/geomcore/trunk/ (3 files in 3 dirs): Pull two unused methods out. |
| 15:10.12 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 15:42.46 | CIA-105 | BRL-CAD: 03Erik 07http://brlcad.org * r2857 10/wiki/NetMsgTypes: Add ls message req/res. Add multistring msg. |
| 15:44.47 | CIA-105 | BRL-CAD: 03erikgreenwald * r44509 10/geomcore/trunk/include/NetMsgTypes.h: add bot request and list request/result. |
| 15:47.37 | dloman_ | ``Erik: whats the difference between GeometryBotReq and GeometryReq? |
| 15:48.22 | CIA-105 | BRL-CAD: 03Erik 07http://brlcad.org * r2858 10/wiki/GenericMultiStringMsg: multistring message |
| 15:48.42 | ``Erik | GeometryBoTReq returns BoT's, one per region (no CSG) for use in OGL, vsl, isst, etc |
| 15:49.15 | dloman_ | so its a request for geometry + request for conversion to bot ? |
| 15:49.46 | ``Erik | yeh, sorta... hopefully we can cache the BoT variants of the regions, and will have fast robust tesselation soon |
| 15:51.11 | dloman_ | ideally, a 'convert to BoT' would be a bit set on a normal geometry request msg. we can do that, now, if it would be easier for you? (it'd be better in the long run too) |
| 15:52.03 | ``Erik | it already is a bit :D GEOMETRYREQ | 0x1 |
| 15:52.53 | ``Erik | if you want to shuffle the interface a bit, doesn't bother me... it's just one of the things that'll be needed, "gimme something I can trivially shove in opengl" |
| 15:53.47 | dloman_ | no worries, just looking to keep things from getting jumbled up. |
| 15:53.59 | dloman_ | whats the ListReq and ListRes for? |
| 15:54.28 | ``Erik | looking around the server side geometry from a client, to find what you want to request |
| 15:54.56 | dloman_ | as in 'directory listing' type stuff? |
| 15:55.03 | ``Erik | yeah |
| 15:55.06 | dloman_ | kewl |
| 15:55.19 | ``Erik | "ls /" -> "havoc.g" "ktank.g" "m35.g" |
| 15:55.36 | ``Erik | "ls /havok/all.g/" -> "light" "component" "plane" |
| 15:55.59 | dloman_ | gotcha |
| 15:56.14 | ``Erik | er, well, you get what I mean... to make like a geometry viewer type thing work over the protocol |
| 15:57.16 | ``Erik | the 'list request' may eventually turn into some kind of query language, ah surpose |
| 16:00.06 | dloman_ | EQL |
| 16:08.16 | bhinesley | brlcad: 10-4, thank you |
| 16:08.57 | CIA-105 | BRL-CAD: 03Erik 07http://brlcad.org * r2859 10/wiki/NetMsgTypes: call the manifest a genericmultistring instead of a 'special' |
| 16:10.03 | CIA-105 | BRL-CAD: 03Erik 07http://brlcad.org * r2860 10/wiki/GenericMultiStringMsg: Update to mirror the manifest format |
| 16:12.05 | dloman_ | hey, i like things being special :P |
| 16:17.56 | CIA-105 | BRL-CAD: 03erikgreenwald * r44510 10/geomcore/trunk/src/interfaces/cl/ (gsclient.lisp gsnet.lisp gsserver.lisp): implement ls/lsr |
| 16:17.58 | ``Erik | the pattern repeated, that's when ya abstract it :) |
| 16:23.47 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 16:23.47 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412) | |
| 17:18.08 | CIA-105 | BRL-CAD: 03erikgreenwald * r44511 10/geomcore/trunk/src/interfaces/cl/gsnet.lisp: fix message types |
| 17:18.18 | CIA-105 | BRL-CAD: 03erikgreenwald * r44512 10/geomcore/trunk/src/interfaces/cl/ (gsserver.lisp gvm.lisp): throw an exception when gvm-open doesn't work |
| 17:19.08 | CIA-105 | BRL-CAD: 03erikgreenwald * r44513 10/geomcore/trunk/src/interfaces/cl/gsclient.lisp: handle a failmsg in response to a geometry request |
| 17:26.04 | CIA-105 | BRL-CAD: 03davidloman * r44514 10/geomcore/trunk/tests/unit/libnet/TypeOnlyMsgUTest.cxx: Formatting |
| 17:27.10 | CIA-105 | BRL-CAD: 03davidloman * r44515 10/geomcore/trunk/tests/unit/libnet/GeometryReqMsgUTest.cxx: Implement the GeometryReqMsg unit test |
| 18:04.42 | *** join/#brlcad crazy_im1 (~mj@a89-182-207-95.net-htp.de) | |
| 18:48.49 | kanzure | starseeker: how slow is too slow? |
| 18:49.05 | kanzure | i've been testing out esolid and the entire program itself runs in 700msec, but i don't think that's the algorithm's time itself |
| 18:49.10 | kanzure | that's also file reading/loading, allocation, etc. |
| 18:49.24 | kanzure | (700msec for various union/difference/intersection tests i've tried) |
| 18:50.24 | kanzure | i might just drive over to college station and show up at keyser's office and ask him about esolid.. he's relatively local to me (2h drive) |
| 18:54.24 | kanzure | there's some brlcad constants defined in esolid in a few places |
| 18:56.40 | *** part/#brlcad csanyipal (~csanyipal@226-170-85-95.dynamic.stcable.net) | |
| 19:27.45 | ``Erik | what kind of complexity is the 700ms case? (and yeah, that's probably mostly file i/o, parsing, etc) |
| 19:28.29 | CIA-105 | BRL-CAD: 03bob1961 * r44516 10/brlcad/trunk/ (5 files in 4 dirs): Modify asc2g to use libtclcad. |
| 19:33.07 | ``Erik | "esolid assumes that all solids are in general position" <-- could that be the 0.1 +z issue? |
| 22:17.16 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:212.92.142.160]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 23:58.19 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-104-168-20.dsl.bkfd14.sbcglobal.net) | |
| 01:33.45 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 02:21.20 | starseeker | hah, cool: http://ascendwiki.cheme.cmu.edu/ASCEND_overview |
| 02:24.29 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 02:28.20 | starseeker | huh: http://www.google-melange.com/gsoc/org/google/gsoc2011/cse_tuwien |
| 02:29.18 | *** join/#brlcad crazy_imp (~mj@a89-182-53-208.net-htp.de) | |
| 03:03.08 | starseeker | ooo - http://www.google-melange.com/gsoc/project/google/gsoc2011/carlosmn/13001 |
| 05:53.33 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:09.57 | *** join/#brlcad primary (debian-tor@gateway/tor-sasl/primary) | |
| 07:10.05 | primary | Hot damn. |
| 07:24.54 | *** join/#brlcad kanzure_ (~goonie@neuroblastoma.cs.pdx.edu) | |
| 07:25.31 | primary | Can anyone here recommend a high resolution TEMPEST resistant display monitor for use with BRL-CAD? |
| 07:37.18 | primary | what is he planning on doing |
| 08:19.11 | *** join/#brlcad mafm_ (~mafm@18.Red-88-23-77.staticIP.rima-tde.net) | |
| 10:40.27 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 10:40.27 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:08.08 | *** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 11:25.47 | CIA-105 | BRL-CAD: 03davidloman * r44517 10/geomcore/trunk/tests/unit/utility/ByteBufferUTest.cxx: Make ByteBuffer unit test check for proper Limit settings. |
| 11:27.29 | CIA-105 | BRL-CAD: 03davidloman * r44518 10/geomcore/trunk/src/utility/ByteBuffer.cxx: Fix limit setting bugs |
| 12:00.14 | *** join/#brlcad Stattrav (~Stattrav@122.172.42.236) | |
| 12:00.14 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:57.44 | CIA-105 | BRL-CAD: 03davidloman * r44519 10/geomcore/trunk/tests/unit/libnet/ (GeometryReqMsgUTest.cxx TypeOnlyMsgUTest.cxx): Collect common header tests into common function, only on a per class basis. |
| 13:29.45 | dloman_ | ``Erik: you around today? |
| 13:36.06 | ``Erik | ayup |
| 13:39.28 | CIA-105 | BRL-CAD: 03davidloman * r44520 10/geomcore/trunk/ (2 files in 2 dirs): Implement Unit test for GeometryManifestMsg. Fixed some bugs, should be working much smoother now. |
| 13:39.39 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 13:56.08 | CIA-105 | BRL-CAD: 03davidloman * r44521 10/geomcore/trunk/tests/unit/libnet/GeometryManifestMsgUTest.cxx: Remove some accidental copy/paste vomit. |
| 14:51.27 | CIA-105 | BRL-CAD: 03r_weiss * r44522 10/brlcad/trunk/src/librt/primitives/nmg/nmg_manif.c: |
| 14:51.27 | CIA-105 | BRL-CAD: Updated functions 'paint_face' and 'nmg_shell_manifolds' within file |
| 14:51.28 | CIA-105 | BRL-CAD: 'nmg_manif.c'. There was a datatype mismatch in the function parameters and some |
| 14:52.18 | CIA-105 | BRL-CAD: 03davidloman * r44523 10/geomcore/trunk/ (2 files in 2 dirs): Fix up some inheritance problems by making GeometryChunk a direct subclass of NetMsg rather than GenericMultiByteMsg. |
| 14:55.54 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:01.41 | ``Erik | nice http://gaming.operationreality.org/2011/04/26/crytek-for-free-cryengine-3-sdk-and-editor/ |
| 15:03.03 | dloman_ | wow, complete code access.... that's unusual! They're lawyers must be on standby :) |
| 15:03.42 | CIA-105 | BRL-CAD: 03r_weiss * r44524 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: |
| 15:03.43 | CIA-105 | BRL-CAD: Updated function 'nmg_bool' within file 'nmg_bool.c'. Moved this change from the |
| 15:03.43 | CIA-105 | BRL-CAD: triangulation prototype code to the main code. This change corrects a corruption |
| 15:03.44 | CIA-105 | BRL-CAD: problem with the class list array. This will improve the sucess of boolean |
| 15:03.44 | CIA-105 | BRL-CAD: operations on facetized cgs geometry. |
| 15:07.21 | *** join/#brlcad Stattrav (~Stattrav@117.192.157.232) | |
| 15:07.21 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:12.52 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:19.33 | dloman_ | Just when I thought patriotism was dead: http://www.ihatethemedia.com/a-simple-way-to-stop-westboro-baptist-church-funeral-protesters |
| 15:19.38 | dloman_ | love it. |
| 16:24.57 | *** join/#brlcad mafm (~mafm@18.Red-88-23-77.staticIP.rima-tde.net) | |
| 16:33.14 | *** join/#brlcad dli (~dli@67.55.46.44) | |
| 16:46.20 | CIA-105 | BRL-CAD: 03r_weiss * r44525 10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c: Updated functions 'nmg_class_pt_e', 'nmg_2lu_identical', 'class_shared_lu' and 'nmg_classify_lu_lu' within file 'nmg_class.c'. Changes were made to compare against SMALL_FASTF instead of '0.0'. |
| 16:46.37 | dloman_ | woooo, go Rich go! |
| 16:48.41 | *** join/#brlcad Stattrav (~Stattrav@117.192.131.229) | |
| 16:48.41 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:57.33 | dloman_ | kicks sf.net |
| 16:57.39 | dloman_ | come on... FASTER! |
| 17:00.13 | CIA-105 | BRL-CAD: 03davidloman * r44526 10/geomcore/trunk/src/libNet/NetMsgFactory.cxx: Two bug fixes. NetMsg parse was failing due to a >= being used instead of a <. Also make peeking at the MsgType remember start position instead of assuming a rewind to position:0 |
| 17:06.52 | *** join/#brlcad Stattrav (~Stattrav@117.192.131.229) | |
| 17:06.52 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:08.05 | *** join/#brlcad Stattrav (~Stattrav@117.192.131.229) | |
| 17:08.06 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:09.16 | *** join/#brlcad Stattrav (~Stattrav@117.192.131.229) | |
| 17:09.30 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:38.47 | CIA-105 | BRL-CAD: 03r_weiss * r44527 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message trimmed) |
| 17:38.47 | CIA-105 | BRL-CAD: Updated the prototype version of function 'nmg_triangulate_fu' doing some |
| 17:39.12 | CIA-105 | BRL-CAD: cleanup and re-factoring. The re-factoring created function 'nmg_isect_lseg3_eu' |
| 17:39.12 | CIA-105 | BRL-CAD: to test if a line segment intersects with any edgeuse within a faceuse. Updated |
| 17:39.12 | CIA-105 | BRL-CAD: the function 'nmg_triangulate_rm_degen_loopuse' adding code to verify each |
| 18:12.14 | *** join/#brlcad Stattrav (~Stattrav@117.192.131.229) | |
| 18:12.14 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:28.23 | dloman_ | okay, this is wierd. |
| 18:29.11 | dloman_ | using pkg, i have confirmed sending 350k on one end, but pkg is reporting recv-ing 25k on the other end. |
| 18:29.32 | dloman_ | digs into pkg. |
| 18:45.01 | *** join/#brlcad Stattrav (~Stattrav@117.192.131.229) | |
| 18:45.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:52.24 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:26.41 | kanzure | <PROTECTED> |
| 19:27.01 | kanzure | http://heybryan.org/shots/2011-04-27-1357-boolean-nurbs.png |
| 19:27.02 | kanzure | http://diyhpl.us/~bryan/irc/esolid_output.txt |
| 19:27.18 | kanzure | progress! now i have a "known good" and i can slowly start to chip away at it |
| 19:41.08 | ``Erik | neat |
| 19:41.37 | ``Erik | esolid is a python thang? does that mean porting it to C, as well? |
| 19:42.34 | ``Erik | do the surfaces that touch eachother share trimming curves? are the black speckles at the seams from tesselating for ogl? |
| 19:53.54 | kanzure | esolid is written in C++ and doesn't have a LICENSE file (i should ask the guy if he could public domain it, though) |
| 19:54.02 | kanzure | i've been writing my own version in python that is "similar" to esolid |
| 19:54.57 | kanzure | surfaces that touch each other do share trimming curves |
| 19:55.11 | kanzure | also, that screenshot sucks- a union doesn't demonstrate what's going on |
| 19:55.13 | kanzure | http://heybryan.org/shots/2011-04-27-1440-boolean-nurbs-difference.png |
| 19:55.36 | kanzure | the visualizer is some wacky shit, i don't think it's using the opengl nurbs routines and is just doing its own tessellation so it probably sucks a lot |
| 19:57.42 | ``Erik | okie, impressive |
| 20:01.34 | kanzure | i also have made a swig wrapper for the C++ version to interface with python |
| 20:01.54 | kanzure | in particular so that i can slowly replace the C++ versions with my own versions, which so far i've been trying to simplify.. |
| 20:02.02 | kanzure | the C++ code base for esolid has a lot of redundancies, it's ridiculous |
| 20:02.17 | kanzure | here's an if-then block for instance.. http://diyhpl.us/~bryan/irc/refactored0.txt |
| 20:02.21 | kanzure | bottom of the file is my refactored version |
| 20:04.51 | ``Erik | too bad esolid is 'school' related, otherwise it may be worth submitting some of it to http://thedailywtf.com/ |
| 20:05.16 | kanzure | by comparison boole-1.1 is significantly worse than esolid |
| 20:05.32 | kanzure | but it makes me wonder.. did some poor human actually write this code? |
| 20:05.42 | ``Erik | of course |
| 20:05.48 | kanzure | there's maybe 10 to 20,000 LOC here... what did they do? |
| 20:05.54 | kanzure | just write it all at once and pray it works the first time? |
| 20:05.56 | kanzure | there's no unit tests |
| 20:06.02 | ``Erik | probably a couple undergrads did it |
| 20:06.51 | kanzure | code quality is fairly consistent i think it was just john keyser entirely |
| 20:07.17 | kanzure | makes sense; he's over at TAMU now running their scholastic comp sci / programming competitive action force team |
| 20:07.48 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177680420.dsl.bell.ca) | |
| 20:08.10 | kanzure | next thing on my todo list is figuring out how to check my python versions against the swigged versions |
| 20:08.28 | kanzure | since swig won't accept my ArbitraryPatch against its _SWIGGED_K_PATCH object |
| 21:44.30 | kanzure | how do i make up unit tests when i don't know what the values should be? |
| 22:22.19 | ``Erik | hm, thennnnn ya don't understand the math you're trying to implement and should learn it? |
| 22:24.18 | primary | RUDE |
| 22:45.58 | kanzure | ``Erik: No, rather "nobody has ever tested any of this, so it could all be wrong anyway." |
| 22:49.39 | kanzure | and, even if you do understand the math, your code can still be wrong |
| 23:20.01 | ``Erik | 'this' being the esolid implementation? |
| 23:29.43 | ``Erik | kinda odd that the ogre guys would do "things and stuff" to their code to require xcode to build on a mac, instead of allowing a unix style build. :/ |
| 23:33.26 | ``Erik | for unit testing, is there a paper related that could help? deductive reasoning on the code comments/name/impl? I've seen "unit tests" created by simply feeding in inputs, recording the outputs, and calling those the "correct" values, not quite right... :) |
| 23:49.06 | primary | because mac |
| 23:49.07 | primary | Sorry, wrong channel. |
| 23:49.07 | primary | keyword highlighting |
| 00:14.41 | *** join/#brlcad kunigami1 (~kunigami@187.106.4.220) | |
| 01:59.17 | kanzure | ``Erik: there's lots of strategies for testing |
| 01:59.38 | kanzure | some people do unit tests, functional tests, integration tests, automated testing frameworks, non-automated testing frameworks, all sorts of stuff sold in books.. |
| 01:59.43 | kanzure | brlcad has a testing suite, right? |
| 02:04.44 | ``Erik | BRL-CAD has function tests and regression tests, no real unit tests |
| 02:05.45 | ``Erik | I advocated real unit testing for a "big" gov't project, wrote a couple papers outlining the full testing stack, pros, cons, etc... I'm quite aware of the different categories :) |
| 02:06.15 | kanzure | fun times. |
| 02:06.38 | ``Erik | I'd argue that to make a real unit test, you must completely understand what the functional unit you're testing is supposed to do, there can be no ambiguity in the contract |
| 02:06.54 | primary | ``Erik: Do you have links to those papers? |
| 02:07.44 | ``Erik | not sure they're public yet, I'll ask around tomorrow... I wrote them as internal documents and some drama with a small minded idjit stopped the regular release cycle |
| 02:26.21 | primary | what license do you publish them under ``Erik |
| 02:30.09 | *** join/#brlcad crazy_imp (~mj@a89-183-124-85.net-htp.de) | |
| 04:05.38 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 06:18.23 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 06:18.23 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:53.58 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:05.27 | *** join/#brlcad mafm (~mafm@5.Red-81-38-237.dynamicIP.rima-tde.net) | |
| 09:35.54 | *** join/#brlcad Stattrav (~Stattrav@122.172.12.161) | |
| 09:35.54 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:46.02 | *** join/#brlcad mafm_ (~mafm@5.Red-81-38-237.dynamicIP.rima-tde.net) | |
| 13:00.21 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 13:00.21 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:14.10 | starseeker | hmm: http://software.intel.com/en-us/blogs/2011/04/04/tbb-adoption-in-cad-technical-insights/ |
| 14:15.02 | ``Erik | starseeker, why'd you break everyone's computers? :D (you bailed before I could find ya) |
| 14:17.47 | ``Erik | starseeker: in your FindTCL.cmake, you have something where you set include paths to ${TCL_INCLUDE_PATH}/../generic ... why the ../ ? on fbsd, TCL_INCLUDE_PATH resolves to /usr/local/include/tcl8.5, adding /usr/local/include/tcl8.5/../generic doesn't quite work |
| 14:19.38 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 14:19.38 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:20.04 | starseeker | ``Erik: erm. I don't recall, unfortunately |
| 14:22.25 | CIA-105 | BRL-CAD: 03r_weiss * r44528 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: (log message trimmed) |
| 14:22.25 | CIA-105 | BRL-CAD: Updated functions 'nmg_do_radial_join', 'nmg_radial_build_list', |
| 14:22.26 | CIA-105 | BRL-CAD: 'nmg_two_face_fuse' and 'nmg_ck_fu_verts' within file 'nmg_fuse.c'. For function |
| 15:40.32 | *** join/#brlcad Stattrav (~Stattrav@117.192.134.244) | |
| 15:40.32 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:46.53 | *** join/#brlcad Stattrav (~Stattrav@117.202.27.145) | |
| 15:46.54 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:14.33 | *** join/#brlcad Stattrav (~Stattrav@117.202.17.251) | |
| 16:14.33 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:11.26 | *** join/#brlcad dli (~dli@67.55.46.44) | |
| 17:38.26 | CIA-105 | BRL-CAD: 03starseeker * r44529 10/geomcore/trunk/CMake/FindBRLCAD.cmake: Add tclcad to the list |
| 18:54.42 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177879058.dsl.bell.ca) | |
| 19:09.25 | CIA-105 | BRL-CAD: 03erikgreenwald * r44530 10/rt^3/trunk/cmake/FindBRLCAD.cmake: add bin to the library path for winderz |
| 20:06.08 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) | |
| 20:12.21 | *** join/#brlcad PrezWhiteCalf (MK@whitecalf.net) | |
| 20:17.46 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) | |
| 20:25.43 | *** join/#brlcad PrezWhiteCalf (MK@whitecalf.net) | |
| 20:31.00 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) | |
| 20:32.32 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 20:54.13 | *** join/#brlcad Computer (~Computer@unaffiliated/computer) | |
| 20:55.08 | Computer | what do you personally use brlcad for? |
| 22:09.33 | CIA-105 | BRL-CAD: 03Sapphire02 07http://brlcad.org * r2862 10/wiki/How_To_Know_About_A_Payday_Loan: New page: == Payday Loan - How To Know About A Payday Loan == There are some cases wherein you are not able to meet your expenses. Thus, people get to involve themselves on having loans. One... |
| 22:12.09 | CIA-105 | BRL-CAD: 03Sapphire02 07http://brlcad.org * r2863 10/wiki/How_To_Know_About_A_Payday_Loan: /* Payday Loan - How To Know About A Payday Loan */ |
| 22:19.23 | dli | what's going on with Sapphire02? |
| 22:33.16 | *** join/#brlcad kunigami1 (~kunigami@187.106.4.220) | |
| 22:37.43 | *** join/#brlcad mafm_ (~mafm@21.Red-83-35-148.dynamicIP.rima-tde.net) | |
| 02:16.05 | *** join/#brlcad Stattrav (~Stattrav@117.202.17.251) | |
| 02:16.05 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 02:29.53 | *** join/#brlcad crazy_imp (~mj@a89-182-29-122.net-htp.de) | |
| 03:13.17 | CIA-105 | BRL-CAD: 03Erik 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[How To Know About A Payday Loan]]": spam |
| 06:02.49 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 06:02.49 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:15.19 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 06:15.19 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:32.42 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 06:32.42 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:01.09 | *** join/#brlcad Stattrav (~Stattrav@14.96.220.57) | |
| 07:01.09 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:33.04 | *** join/#brlcad Stattrav (~Stattrav@14.96.220.57) | |
| 07:33.05 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:45.03 | *** join/#brlcad mafm_ (~mafm@188.Red-88-22-161.staticIP.rima-tde.net) | |
| 09:53.31 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:21.29 | *** join/#brlcad mafm (~mafm@188.Red-88-22-161.staticIP.rima-tde.net) | |
| 10:51.58 | CIA-105 | BRL-CAD: 03davidloman * r44531 10/geomcore/trunk/src/utility/ByteBuffer.cxx: Removed a stray malloc from ByteBuffer::compact() and added a zero length string check in ByteBuffer::toHexString() |
| 10:55.48 | CIA-105 | BRL-CAD: 03davidloman * r44532 10/geomcore/trunk/src/libNet/NetMsgFactory.cxx: |
| 10:55.48 | CIA-105 | BRL-CAD: Switched the minimum available data check from using ByteBuffer()::limit() to |
| 10:55.48 | CIA-105 | BRL-CAD: using ByteBuffer::remaining(). Using limit assumes that position is zero, which |
| 12:59.24 | dloman_ | hrm, really really strange. getting garbage in the data when sending large amounts (aka 350k) thru pkg. |
| 13:22.27 | dloman_ | also, if i try to use pkg_send() to send all 350k at once, pkg_send() reports that all data has been sent, however, only about 25k shows up on the other side :/ |
| 13:36.18 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 14:29.41 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 15:36.31 | CIA-105 | BRL-CAD: 03tbrowder2 * r44533 10/brlcad/trunk/doc/docbook/books/en/BRL-CAD_Tutorial_Series-VolumeIII.xml: delete spurious 'b' |
| 16:16.09 | *** join/#brlcad joevano (~joevano@bzflag/developer/JoeVano) | |
| 16:16.55 | joevano | brlcad: Happy Birthday! |
| 17:54.44 | CIA-105 | BRL-CAD: 03starseeker * r44534 10/brlcad/trunk/doc/docbook/system/mann/en/search.xml: Add brep to the search primitive types list. |
| 18:08.43 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 19:04.49 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.156) | |
| 19:04.51 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:00.10 | CIA-105 | BRL-CAD: 03starseeker * r44535 10/brlcad/trunk/doc/docbook/system/mann/en/search.xml: Whoops, how about valid xml. |
| 20:08.09 | CIA-105 | BRL-CAD: 03bob1961 * r44536 10/brlcad/trunk/src/Makefile.am: Promote libdm and libtclcad from kitchensink_dirs to bench_dirs. Reason - asc2g needs libtclcad. |
| 20:10.49 | CIA-105 | BRL-CAD: 03bob1961 * r44537 10/brlcad/trunk/include/raytrace.h: Added RT_APPLICATION_NULL macro. |
| 20:12.51 | CIA-105 | BRL-CAD: 03bob1961 * r44538 10/brlcad/trunk/include/ged.h: Add enclosing parens to a few NULL macros. |
| 20:27.23 | CIA-105 | BRL-CAD: 03starseeker * r44539 10/brlcad/trunk/src/libged/search.c: Make a stab at improving behavior of search when multiple paths are supplied. |
| 21:59.35 | CIA-105 | BRL-CAD: 03bob1961 * r44540 10/brlcad/trunk/ (include/tclcad.h src/libtclcad/tclcad_obj.c): Refactor a big chunk of to_rt_gettrees into to_rt_gettrees_application. |
| 22:24.32 | *** join/#brlcad kunigami1 (~kunigami@187.106.4.220) | |
| 22:28.01 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 02:29.38 | *** join/#brlcad crazy_imp (~mj@a89-182-9-99.net-htp.de) | |
| 06:09.23 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 06:09.25 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:22.40 | *** join/#brlcad mafm (~mafm@124.Red-83-45-72.dynamicIP.rima-tde.net) | |
| 10:18.04 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 10:18.04 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:49.14 | *** join/#brlcad merzo (~merzo@112-206-94-178.pool.ukrtel.net) | |
| 12:33.58 | *** join/#brlcad dli (~dli@67.55.46.44) | |
| 14:13.47 | *** join/#brlcad kunigami1 (~kunigami@187.106.4.220) | |
| 15:15.18 | *** join/#brlcad crazy_imp (~mj@a89-182-9-99.net-htp.de) | |
| 15:22.53 | *** part/#brlcad kunigami1 (~kunigami@187.106.4.220) | |
| 15:23.01 | *** join/#brlcad kunigami1 (~kunigami@187.106.4.220) | |
| 16:20.53 | *** join/#brlcad Stattrav (~Stattrav@117.192.148.252) | |
| 16:20.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:21.21 | *** join/#brlcad mafm (~mafm@124.Red-83-45-72.dynamicIP.rima-tde.net) | |
| 16:39.04 | *** join/#brlcad joevano (~joevano@c-71-193-108-171.hsd1.in.comcast.net) | |
| 16:39.04 | *** join/#brlcad joevano (~joevano@bzflag/developer/JoeVano) | |
| 17:54.05 | *** join/#brlcad crazy_imp (~mj@a89-182-9-99.net-htp.de) | |
| 17:57.21 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 18:41.26 | *** join/#brlcad Stattrav (~Stattrav@117.192.148.252) | |
| 18:41.27 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:37.48 | *** part/#brlcad joevano (~joevano@bzflag/developer/JoeVano) | |
| 21:23.54 | *** join/#brlcad Yoshi47 (~jan@d72-39-60-53.home1.cgocable.net) | |
| 22:46.31 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177680386.dsl.bell.ca) | |
| 22:58.55 | *** part/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177680386.dsl.bell.ca) | |
| 22:59.20 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177680386.dsl.bell.ca) | |
| 22:59.59 | *** part/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177680386.dsl.bell.ca) | |
| 01:26.25 | *** join/#brlcad merzo (~merzo@112-206-94-178.pool.ukrtel.net) | |
| 02:30.43 | *** join/#brlcad crazy_imp (~mj@a89-182-3-78.net-htp.de) | |
| 02:36.30 | *** join/#brlcad kunigami1 (~kunigami@187.106.4.220) | |
| 02:37.41 | kunigami1 | hi guys, let me ask a newbie question: in this github project (https://github.com/fohr/openshadinglanguage/tree/testrender), there's a link to download the source code, namely: https://github.com/fohr/openshadinglanguage.git |
| 02:38.25 | kunigami1 | but when I do: git clone https://github.com/fohr/openshadinglanguage.git, it downloads a different version from that available from the download button: https://github.com/fohr/openshadinglanguage/tarball/testrender |
| 02:39.19 | kunigami1 | does any one know how do I get this branch with git? thanks |
| 02:51.51 | dli | kunigami, the button gives you tagged version |
| 02:57.47 | kunigami1 | dli, I'm not used to git, but your answer helped me to find what I wanted. After cloning I just had to do 'git checkout testrender' to switch to the desired branch |
| 02:58.27 | dli | kunigami, different branches, try: git branch -a |
| 03:06.15 | kunigami1 | dli: this command lists the current branches and tells in which of them I am. thanks! |
| 08:52.13 | *** join/#brlcad csanyipal (~csanyipal@226-170-85-95.dynamic.stcable.net) | |
| 08:52.18 | csanyipal | Hi, |
| 08:57.35 | csanyipal | I have a working copy of brlcad SVN repository, the svnversion number is: 41797. |
| 08:59.20 | csanyipal | I find in the brlcad/doc/html/ directory the toc.html that has anchors to following directories: articles, books and lessons. |
| 08:59.55 | csanyipal | When one open this toc.html in a browser these anchors don't works. |
| 09:01.08 | csanyipal | After I made in brlcad/doc/html/ directory symlinks to those directories, I can use toc.html to browse these documents. |
| 09:01.54 | csanyipal | So why doesn't have this brlcad/doc/html/ directory already those symlinks? |
| 09:31.09 | *** join/#brlcad Stattrav (~Stattrav@117.192.136.214) | |
| 09:31.09 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:34.20 | csanyipal | Should those symlinks to be in the SVN repository? |
| 14:16.29 | *** join/#brlcad mafm (~mafm@240.Red-83-40-127.dynamicIP.rima-tde.net) | |
| 14:55.09 | *** join/#brlcad kunigami1 (~kunigami@187.106.4.220) | |
| 14:55.18 | *** part/#brlcad kunigami1 (~kunigami@187.106.4.220) | |
| 14:55.23 | *** join/#brlcad kunigami1 (~kunigami@187.106.4.220) | |
| 19:40.03 | *** join/#brlcad mafm_ (~mafm@240.Red-83-40-127.dynamicIP.rima-tde.net) | |
| 20:11.36 | csanyipal | I used BRL-CAD documentation for a Moodle course here: http://edu.csanyi-pal.info/moodle/ called 'BRL-CAD Articles, Books and Lessons'. |
| 20:37.24 | *** join/#brlcad Stattrav (~Stattrav@117.192.129.83) | |
| 20:37.24 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 00:02.41 | *** join/#brlcad mafm_ (~mafm@53.Red-83-37-177.dynamicIP.rima-tde.net) | |
| 01:39.30 | *** part/#brlcad kunigami1 (~kunigami@187.106.4.220) | |
| 02:30.30 | *** join/#brlcad crazy_imp (~mj@a89-183-71-182.net-htp.de) | |
| 03:09.49 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) | |
| 03:27.28 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 05:08.21 | *** join/#brlcad csanyipal (~csanyipal@226-170-85-95.dynamic.stcable.net) | |
| 05:08.33 | csanyipal | Hi, |
| 07:58.17 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 08:28.11 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 08:28.11 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:37.15 | *** join/#brlcad mafm_ (~mafm@132.Red-83-45-252.dynamicIP.rima-tde.net) | |
| 13:26.13 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 13:26.14 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:27.13 | CIA-105 | BRL-CAD: 03davidloman * r44541 10/geomcore/trunk/src/utility/ByteBuffer.cxx: Include string.h to make compile without grumbles on ubuntu. |
| 13:34.19 | CIA-105 | BRL-CAD: 03davidloman * r44542 10/geomcore/trunk/src/ (2 files in 2 dirs): printf was expecting a long long unsigned int but was getting passed a long unsigned in. Fixt. |
| 13:37.34 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 13:39.33 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 13:40.45 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) | |
| 13:41.42 | *** join/#brlcad PrezWhiteCalf (MK@whitecalf.net) | |
| 13:49.45 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 13:55.34 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 14:01.52 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) | |
| 14:14.38 | *** part/#brlcad csanyipal (~csanyipal@226-170-85-95.dynamic.stcable.net) | |
| 14:14.52 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 14:29.36 | *** join/#brlcad mafm (~mafm@132.Red-83-45-252.dynamicIP.rima-tde.net) | |
| 14:32.41 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 14:41.46 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 14:58.43 | CIA-105 | BRL-CAD: 03starseeker * r44543 10/brlcad/trunk/src/librt/search.c: Go with QUIET instead of NOISY for search db_lookup calls. |
| 15:02.04 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) | |
| 15:09.27 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 16:14.38 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177879414.dsl.bell.ca) | |
| 16:45.18 | *** part/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177879414.dsl.bell.ca) | |
| 16:45.26 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177879414.dsl.bell.ca) | |
| 16:45.36 | *** part/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177879414.dsl.bell.ca) | |
| 17:12.47 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 19:20.53 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.247) | |
| 19:20.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:24.02 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 19:41.11 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.247) | |
| 19:41.11 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:01.33 | *** join/#brlcad mafm (~mafm@132.Red-83-45-252.dynamicIP.rima-tde.net) | |
| 20:53.16 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.247) | |
| 20:53.16 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:01.19 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.247) | |
| 21:01.19 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:10.22 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:19.46 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.247) | |
| 21:19.46 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 22:46.51 | *** join/#brlcad csanyipal (~csanyipal@226-170-85-95.dynamic.stcable.net) | |
| 02:30.15 | *** join/#brlcad crazy_imp (~mj@a89-183-78-204.net-htp.de) | |
| 03:51.09 | kanzure | hrmm |
| 03:51.19 | kanzure | i'm currently the maintainer of an 'old' codebase from 2004-2009 called nanoengineer |
| 03:51.36 | kanzure | it's gplv2-licensed nanotech cad |
| 03:52.04 | kanzure | there's a lot of work that was put into it (about 5 to 10 developers over 4 years) |
| 03:52.10 | kanzure | but it's no longer being actively developed |
| 03:52.42 | kanzure | i know the license is poisonous to brlcad but maybe there's something i could that would make the code appealing to tack into brlcad? :/ |
| 04:07.58 | starseeker | kanzure: this one? http://nanoengineer-1.net |
| 04:08.59 | starseeker | GPL is (unfortunately) a non-starter - however, you can go the other way and use BRL-CAD libraries in nanoengineer |
| 04:10.01 | kanzure | meh |
| 04:10.05 | kanzure | yeah that's one of the sites |
| 04:10.09 | kanzure | http://nanorex.com/ too |
| 04:10.14 | kanzure | actual code: http://diyhpl.us/cgit/nanoengineer |
| 04:10.47 | starseeker | kanzure: believe me, the non-GPL restriction has been painful in the past |
| 04:11.02 | kanzure | well, i know everyone who wrote code in this project and copyright changes are possible |
| 04:11.17 | kanzure | basically a company was paying for the development of this code base, the company went belly up |
| 04:11.31 | kanzure | and while i love the software i don't have time to convert all of the old libraries and dependencies and upgrade its usage |
| 04:11.39 | kanzure | having said that, there's still some useful software in here somewhere |
| 04:11.42 | starseeker | LGPL-v2 or Modified BSD both work |
| 04:11.59 | kanzure | it's not directly related to solid modeling of course- it's atomically-precise CAD |
| 04:12.24 | kanzure | so the overall utility to brlcad might be minimal |
| 04:13.11 | starseeker | hard to say without a closer look |
| 05:54.36 | Ralith | kanzure: you could talk to the old devs and attempt a relicense; it'll be hard, but they'd probably rather their code be used at all than not. |
| 05:55.10 | Ralith | easier if the project had some foresight and had copyright assigned to one person. |
| 06:13.08 | kanzure | it is |
| 06:13.16 | kanzure | it's assigned to the company ;) |
| 06:13.23 | kanzure | which is owned by a single dude |
| 07:33.49 | *** join/#brlcad dli (~dli@67.55.46.44) | |
| 08:15.41 | *** join/#brlcad ScribbleJ (~scribble@99-35-164-204.lightspeed.dwgvil.sbcglobal.net) | |
| 08:15.47 | ScribbleJ | OMG an IRC channel |
| 08:15.50 | ScribbleJ | I already love it |
| 09:19.22 | *** join/#brlcad mafm (~mafm@87.Red-83-35-148.dynamicIP.rima-tde.net) | |
| 11:41.03 | dloman_ | Mernin |
| 12:49.32 | ``Erik | yargh |
| 13:37.09 | *** join/#brlcad culot (~culot@0xd0.org) | |
| 13:42.17 | culot | Hi, I am a FreeBSD committer and some days ago committed an update for the brlcad port (7.18.4) which was submitted by Erik Greenwald |
| 13:42.42 | culot | I tested the update on i386 and it worked well, however our automated build system reports that compilation fails on amd64 |
| 13:42.48 | culot | see: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.8.20110501074957/brlcad-7.18.4.log |
| 13:43.09 | culot | is it a known problem? |
| 14:34.19 | ``Erik | yeah, I saw the email, my amd64 fbsd8 box is having issues at the moment, so I can't test fixes :/ |
| 14:35.34 | ``Erik | (pav emailed me, too) |
| 14:36.45 | culot | ``Erik: ok thanks, I was not sure you received the mails so sorry for asking again here |
| 14:37.36 | ``Erik | a quick re-look makes it look like posix_memalign is defined in both /usr/include/mm_malloc.h and /usr/include/stdlib.h ... is this something that's changed on the amd64 branch? |
| 14:37.54 | ``Erik | > /usr/include/mm_malloc.h:37: error: declaration of 'int posix_memalign(void**, size_t, size_t) throw ()' throws different exceptions |
| 14:37.57 | ``Erik | > /usr/include/stdlib.h:160: error: from previous declaration 'int posix_memalign(void**, size_t, size_t)' |
| 14:40.53 | culot | I am not sure, I will have to check |
| 15:11.18 | *** join/#brlcad dli (~dli@67.55.46.44) | |
| 15:13.54 | CIA-105 | BRL-CAD: 03davidloman * r44544 10/geomcore/trunk/ (2 files in 2 dirs): Add new Job: MakeAndRouteMsgJob. Will shortly supersede RouteMsgJob |
| 16:08.01 | CIA-105 | BRL-CAD: 03starseeker * r44545 10/brlcad/trunk/src/tclscripts/mged/bindings.tcl: Don't do the mac keybinding fixes unless we're on Mac - they break zooming out on Linux. |
| 16:18.33 | culot | ``Erik: would you be interested if I set up a jail for you on an amd64 box so you can test your fixes? |
| 16:19.29 | culot | ``Erik: I would like to help you on this bug but I don't have much time now so I'm afraid giving you access to an amd64 box is the only help I could provide :'( |
| 16:20.27 | ``Erik | sure, a jail would be great, I'm trying to get qemu installed on a machine right now |
| 16:21.06 | culot | ``Erik: ok, I will give you access in a couple of minutes, just finishing the install |
| 16:22.20 | ``Erik | awesome! if you do a depends on cad/brlcad, I wouldn't need sudo |
| 16:22.58 | culot | I'll give you root access so you can do whatever you need to |
| 16:23.10 | ``Erik | aight |
| 16:32.28 | culot | ``Erik: did you get my private message? |
| 17:06.21 | ``Erik | yup, sorry, was talking to someone |
| 19:21.18 | *** join/#brlcad Stattrav (~Stattrav@117.192.136.213) | |
| 19:21.18 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:21.45 | CIA-105 | BRL-CAD: 03starseeker * r44546 10/brlcad/trunk/ (4 files in 4 dirs): Gah. More consequences of our using Itcl/Itk internal headers. Also fix FindTCL to not return any sort of generic dir (correct or otherwise.) |
| 19:40.36 | CIA-105 | BRL-CAD: 03starseeker * r44547 10/brlcad/trunk/src/ (3 files in 3 dirs): Need unix dir too... |
| 19:55.36 | CIA-105 | BRL-CAD: 03davidloman * r44548 10/geomcore/trunk/ (22 files in 8 dirs): |
| 19:55.37 | CIA-105 | BRL-CAD: Experimental build. There was something really screwy with the way pkg was |
| 19:55.37 | CIA-105 | BRL-CAD: handling chunks of data larger than 24k, so i unwired the send and recv portions |
| 19:55.38 | CIA-105 | BRL-CAD: of pkg and "rolled my own". Things are much more stable and much faster. There |
| 19:55.38 | CIA-105 | BRL-CAD: is still a bit of work todo, but geomcore compiles and runs at this point. |
| 20:46.47 | *** join/#brlcad mafm (~mafm@255.Red-88-11-184.dynamicIP.rima-tde.net) | |
| 22:48.52 | *** join/#brlcad merzo (~merzo@25-73-132-95.pool.ukrtel.net) | |
| 22:59.12 | *** join/#brlcad mafm (~mafm@255.Red-88-11-184.dynamicIP.rima-tde.net) | |
| 23:35.49 | *** part/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 02:30.06 | *** join/#brlcad crazy_imp (~mj@a89-182-3-232.net-htp.de) | |
| 02:49.30 | *** part/#brlcad ScribbleJ (~scribble@99-35-164-204.lightspeed.dwgvil.sbcglobal.net) | |
| 05:14.03 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 05:17.46 | kanzure | i sent an email to a prof about the licensing of his cad-related code, but he hasn't replied (it's been about a week) |
| 05:17.51 | kanzure | should i follow-up with a phone call? |
| 05:35.21 | CIA-105 | BRL-CAD: 03109.100.116.81 07http://brlcad.org * r2864 10/wiki/Main_Page: /* Third-party Projects */ |
| 07:32.06 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:58.47 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:23.37 | *** join/#brlcad mafm (~mafm@134.Red-81-35-69.dynamicIP.rima-tde.net) | |
| 10:50.27 | culot | ``Erik: FYI I committed your patch to correct the compilation issues on amd64, thanks |
| 10:51.54 | ``Erik | cool beans, thanks |
| 10:54.19 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 11:02.26 | *** part/#brlcad culot (~culot@0xd0.org) | |
| 11:27.40 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 11:56.40 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 11:58.28 | *** join/#brlcad pawleeq (~pavel@pc119.iabrno.cz) | |
| 11:58.33 | pawleeq | hello |
| 11:59.29 | pawleeq | I have compiled 7.18.4 on ubuntu and I experience a problem with zooming in mgeds graphics window |
| 11:59.35 | pawleeq | it only zooms in |
| 12:17.48 | *** join/#brlcad dli (~dli@67.55.46.44) | |
| 12:22.16 | pawleeq | to be exact it zooms in on left, right and middle click |
| 12:58.59 | starseeker | kanzure: probably couldn't hurt |
| 12:59.36 | starseeker | pawleeq: just fixed that yesterday - try building latest trunk svn checkout |
| 12:59.51 | pawleeq | starseeker: thank you |
| 13:46.34 | CIA-105 | BRL-CAD: 03starseeker * r44549 10/brlcad/trunk/src/librt/CMakeLists.txt: Try not to error out on the librt-static build when optimized - metaballs are triggering some subtle problem either with the code or possibly the older compiler used for the test. |
| 13:47.21 | starseeker | ``Erik: see if that fixes the build for you - I'd like to get a release put together, so any remining outstanding release-blocker issues I know about I'll try to squash today and tomorrow |
| 15:36.36 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 15:36.36 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:40.03 | CIA-105 | BRL-CAD: 03starseeker * r44550 10/brlcad/trunk/src/librt/CMakeLists.txt: Whoops - fix silly typos |
| 16:47.27 | CIA-105 | BRL-CAD: 03starseeker * r44551 10/brlcad/trunk/src/librt/CMakeLists.txt: Won't be a librt-static target unless static libs are being built. |
| 16:57.37 | CIA-105 | BRL-CAD: 03starseeker * r44552 10/brlcad/trunk/src/vdeck/vdeck.c: Strict warning in vdeck on BSD - I think this is the fix? |
| 17:06.15 | CIA-105 | BRL-CAD: 03starseeker * r44553 10/brlcad/trunk/src/libged/tables.c: More warnings on BSD - could also use a second opinion here. |
| 17:19.30 | CIA-105 | BRL-CAD: 03starseeker * r44554 10/brlcad/trunk/src/mged/animedit.c: Add a few initializations. |
| 17:20.20 | ``Erik | hrm |
| 17:38.37 | CIA-105 | BRL-CAD: 03starseeker * r44555 10/brlcad/trunk/src/libged/editit.c: make a copy of the edit string to avoid const issues |
| 17:48.34 | CIA-105 | BRL-CAD: 03starseeker * r44556 10/brlcad/trunk/src/libged/editit.c: er - how about using the copy while we're at it. |
| 18:13.55 | CIA-105 | BRL-CAD: 03starseeker * r44557 10/brlcad/trunk/src/mged/ (cmd.h utility1.c): f_tables doesn't appear to be used, and looks like it lives in libged now. |
| 18:20.25 | *** join/#brlcad mafm_ (~mafm@134.Red-81-35-69.dynamicIP.rima-tde.net) | |
| 20:07.21 | CIA-105 | BRL-CAD: 03Dloman 07http://brlcad.org * r2865 10/wiki/GeometryServiceNetworkProtocol: Updated header byte layout. |
| 20:07.23 | CIA-105 | BRL-CAD: 03Dloman 07http://brlcad.org * r2866 10/wiki/GeometryServiceNetworkProtocol: removed pkg |
| 20:12.06 | CIA-105 | BRL-CAD: 03Dloman 07http://brlcad.org * r2867 10/wiki/GeometryServiceNetworkProtocol: Drop depricated |
| 20:13.10 | CIA-105 | BRL-CAD: 03Dloman 07http://brlcad.org * r2868 10/wiki/GeometryServiceNetworkProtocol: Remove references to pkg |
| 20:26.56 | CIA-105 | BRL-CAD: 03erikgreenwald * r44558 10/geomcore/trunk/src/interfaces/cl/gsnet.lisp: reflect changes in GSNet protocol (elimination of magic, swapping of type and length) |
| 21:06.07 | CIA-105 | BRL-CAD: 03erikgreenwald * r44559 10/brlcad/trunk/src/libged/ (combmem.c red.c): quell warnings |
| 21:39.02 | *** join/#brlcad crazy_imp (~mj@a89-182-25-196.net-htp.de) | |
| 21:39.17 | *** join/#brlcad merzo (~merzo@162-173-94-178.pool.ukrtel.net) | |
| 22:40.23 | *** join/#brlcad Stattrav (~Stattrav@117.202.18.204) | |
| 22:40.23 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 22:52.26 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 00:08.33 | *** join/#brlcad docelic (~docelic@78.134.193.201) | |
| 00:20.00 | *** join/#brlcad docelic (~docelic@78.134.193.201) | |
| 03:04.41 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r2869 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/109.100.116.81|109.100.116.81]] ([[User talk:109.100.116.81|Talk]]); changed back to last version by [[User:Sean|Sean]] |
| 03:05.10 | CIA-105 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:109.100.116.81]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 07:33.01 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 08:38.30 | *** join/#brlcad mafm_ (~mafm@22.Red-83-55-205.dynamicIP.rima-tde.net) | |
| 10:21.34 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:09.52 | CIA-105 | BRL-CAD: 03starseeker * r44560 10/brlcad/trunk/include/CMakeLists.txt: Add a couple headers. |
| 12:34.18 | dloman_ | cd |
| 12:34.32 | dloman_ | oops, wrong terminal =D |
| 12:55.53 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 13:18.20 | ``Erik | huh, bangor and bremerton were merged to make kitsap |
| 13:18.43 | dloman_ | part of brac? |
| 13:19.12 | ``Erik | back in '04 |
| 13:19.28 | dloman_ | wow, i was still in bck then. |
| 13:19.34 | ``Erik | http://en.wikipedia.org/wiki/Naval_Base_Kitsap |
| 13:19.36 | dloman_ | must be really out od sync |
| 13:19.55 | ``Erik | I did mini-bootcamp in '91(90?) at bangor |
| 13:20.06 | dloman_ | heh.... Why? |
| 13:20.11 | ``Erik | njrotc |
| 13:20.39 | ``Erik | it was 3 days of kidgloves stuff, a 'field trip' with pt and marching |
| 13:20.54 | dloman_ | oh yeah, forgot you was in rotc :) |
| 13:21.33 | ``Erik | yes, post-rotc "f this s" involved growing the hair out, earrings, blue hair, etc :) |
| 13:23.10 | dloman_ | still backlashing? :) |
| 13:23.53 | ``Erik | (was talking to mike about things to do while sailing the area, he mentioned the fishing marker island with a picnic table and a waste deep volleyball court, which led to talk about hitting rocks or the poles, then the pic of the los angeles you pulled up yesterday, which got me reading about the incident, ... tangents on tangents) |
| 13:24.17 | ``Erik | waist deep, even |
| 13:24.28 | dloman_ | was going to say, lol |
| 13:24.36 | dloman_ | "You're playing v-ball in what?!?" |
| 13:24.36 | ``Erik | though with the silt and hillbilly garbage, waste deep might be correct... |
| 13:38.20 | *** join/#brlcad mafm_ (~mafm@22.Red-83-55-205.dynamicIP.rima-tde.net) | |
| 14:38.36 | starseeker | digs in to understand how to use quaternions... |
| 15:09.41 | CIA-105 | BRL-CAD: 03davidloman * r44561 10/geomcore/trunk/ (4 files in 4 dirs): Clean up some logger funkyness. Removed 'verbose' option. Didn't do anything anyways. |
| 16:41.31 | *** join/#brlcad docelic_ (~docelic@78.134.205.19) | |
| 16:46.30 | kanzure | my mom runs a small business (woodworking company) and she is purchasing some software :/ |
| 16:46.33 | kanzure | http://www.cabnetware.com/UserFiles/17/File/CWbrochure.pdf |
| 16:46.46 | kanzure | probably going to be horribly overpriced for what it does |
| 17:12.14 | ``Erik | starseeker: there was an old article (late 90's?) that gave a decent programmers overview of quaternions without delving into the math, I think it was an gamasutra? |
| 17:12.36 | ``Erik | ah, here we go: http://www.gamasutra.com/view/feature/3278/rotating_objects_using_quaternions.php |
| 17:26.26 | CIA-105 | BRL-CAD: 03davidloman * r44562 10/geomcore/trunk/src/utility/Logger.cxx: seems that bu_log is messing up the printing to stdout some how. Switch over to direct printing for now. |
| 17:38.49 | CIA-105 | BRL-CAD: 03davidloman * r44563 10/geomcore/trunk/ (8 files in 5 dirs): Clean up some nastly little memory leaks. |
| 17:42.06 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:42.48 | CIA-105 | BRL-CAD: 03starseeker * r44564 10/brlcad/trunk/src/other/ (5 files in 4 dirs): Try a setup to allow brlcad_config.h and togl_config.h to co-exist. |
| 17:57.15 | *** join/#brlcad Stattrav (~Stattrav@117.192.142.113) | |
| 17:57.15 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:03.38 | CIA-105 | BRL-CAD: 03starseeker * r44565 10/brlcad/trunk/src/adrt/ (CMakeLists.txt isst_tcltk.c): Tweak isst code for changes and strict build - not tested yet. |
| 18:25.48 | CIA-105 | BRL-CAD: 03starseeker * r44566 10/brlcad/trunk/src/adrt/ (CMakeLists.txt Makefile.am isst isst.tcl): Start setting up the actual Tcl/Tk application for isst. |
| 18:27.13 | CIA-105 | BRL-CAD: 03starseeker * r44567 10/brlcad/trunk/src/adrt/isst: Borrow archer's set-up for running wish. Got successful startup of isst. |
| 18:34.04 | CIA-105 | BRL-CAD: 03erikgreenwald * r44568 10/brlcad/trunk/src/adrt/CMakeLists.txt: add X11 include dir |
| 19:23.47 | CIA-105 | BRL-CAD: 03starseeker * r44569 10/brlcad/trunk/src/adrt/isst: Add rudimentry ability to specify model and object on isst command line. |
| 20:34.36 | CIA-105 | BRL-CAD: 03erikgreenwald * r44570 10/brlcad/trunk/CMakeLists.txt: look for GL/glext.h |
| 20:35.28 | CIA-105 | BRL-CAD: 03erikgreenwald * r44571 10/brlcad/trunk/src/other/CMakeLists.txt: allow togl on non-X11 platforms. Mark TOGL_LIBRARIES and TOGL_INCLUDE_DIRS as advanced. |
| 20:37.18 | CIA-105 | BRL-CAD: 03erikgreenwald * r44572 10/brlcad/trunk/src/other/togl/src/glext.h: add the SGI reference glext.h |
| 20:38.06 | CIA-105 | BRL-CAD: 03erikgreenwald * r44573 10/brlcad/trunk/src/other/togl/src/togl.c: use system glext if possible, local copy if not |
| 20:40.49 | *** join/#brlcad dli (~dli@66.49.170.199) | |
| 20:58.30 | CIA-105 | BRL-CAD: 03erikgreenwald * r44574 10/brlcad/trunk/src/other/togl/src/wglext.h: add local copy of wglext.h (msvc8 seems... lacking) |
| 20:58.53 | CIA-105 | BRL-CAD: 03erikgreenwald * r44575 10/brlcad/trunk/ (CMakeLists.txt src/other/togl/src/toglWGL.c): wire in wglext.h if possible |
| 21:20.43 | CIA-105 | BRL-CAD: 03erikgreenwald * r44576 10/brlcad/trunk/CMakeLists.txt: Define _FILE_OFFSET_BITS and _LARGEFILE64_SOURCE to 32b filesystem access to work around zlib's "little trick" that causes havoc with -Wundef. |
| 21:28.18 | CIA-105 | BRL-CAD: 03erikgreenwald * r44577 10/brlcad/trunk/src/adrt/CMakeLists.txt: add opengl include path |
| 21:40.48 | *** join/#brlcad crazy_imp (~mj@a89-183-74-132.net-htp.de) | |
| 03:19.46 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 04:14.02 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177593224.dsl.bell.ca) | |
| 04:33.11 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 06:44.09 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 06:46.35 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:59.06 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 06:59.30 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 06:59.30 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:59.41 | *** join/#brlcad mafm_ (~mafm@138.Red-88-23-77.staticIP.rima-tde.net) | |
| 10:56.12 | *** join/#brlcad mafm (~mafm@138.Red-88-23-77.staticIP.rima-tde.net) | |
| 11:28.32 | d_rossberg | what's the LIB_DIR in src/other/libregex/CMakeLists.txt? |
| 11:29.01 | d_rossberg | it looks like a left-over from the unrelated tcl |
| 11:40.51 | *** join/#brlcad Stattrav_ (~Stattrav@122.167.171.243) | |
| 12:35.19 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:56.18 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:16.05 | starseeker | d_rossberg: it should control where the library goes - it's being set by the parent CMakeLists.txt file |
| 13:16.13 | starseeker | are you seeing a problem? |
| 13:16.37 | starseeker | crosses his fingers and reboots after a major baselayout update... |
| 13:19.17 | *** join/#brlcad dli (~dli@66.49.170.199) | |
| 13:22.24 | ``Erik | starseeker: issues building togl on winderz. tkstubs.dll isn't being linked... manually added it, complained that some init func was defined in both tclStubs.dll and tcl.dll |
| 13:32.18 | starseeker | winces |
| 13:32.47 | starseeker | might check tkhtml's cmake logic... |
| 13:39.32 | ``Erik | looks at bwish's cmake O.o |
| 13:44.00 | starseeker | the tcl/tk related CMake logic is among the most gnarly bits, primarly because of how... personality filled Tcl/Tk's build process is to begin with |
| 13:46.23 | starseeker | If I thought there was any chance of success I'd start a github of the latest tcl/tk 8.6 dev srcs and try to make a cleaned-up and comprehensive CMake build to present at the Tcl/Tk conference |
| 13:48.19 | starseeker | contends that Tcl/Tk's public/private API separation is seriously busted - either they need to expose enough public API to allow extensions to be implemented without having to reference internal APIs, or they need to snarf all the license compatible extensions into the core |
| 14:02.40 | ``Erik | hm, isst exists as {builddir}/bin/isst, but does not get installed when I do "make install" |
| 14:06.17 | d_rossberg | starseeker: that's the problem: LIB_DIR isn't set in any parent CMakeLists.txt file, only in tcl's CMakeLists.txt |
| 14:08.15 | d_rossberg | i did a grap over the whole brlcad branch |
| 14:44.53 | *** join/#brlcad Stattrav (~Stattrav@117.192.130.88) | |
| 14:44.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:43.46 | *** join/#brlcad merzo (~merzo@178.94.161.13) | |
| 19:05.24 | *** join/#brlcad Stattrav (~Stattrav@117.192.130.88) | |
| 19:05.24 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:10.38 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 19:14.42 | *** join/#brlcad Stattrav (~Stattrav@117.192.130.88) | |
| 19:14.42 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:29.09 | *** join/#brlcad Stattrav (~Stattrav@117.192.130.88) | |
| 19:29.09 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:46.32 | *** join/#brlcad Stattrav (~Stattrav@117.192.130.88) | |
| 19:46.32 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:53.43 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 20:42.29 | CIA-105 | BRL-CAD: 03starseeker * r44578 10/brlcad/trunk/src/adrt/CMakeLists.txt: Add an install line for isst |
| 20:47.22 | starseeker | next time d_rossberg gets back - LIB_DIR is being set by the macro in the toplevel CMakeLists.txt file line 1545 |
| 20:52.11 | CIA-105 | BRL-CAD: 03starseeker * r44579 10/brlcad/trunk/src/other/togl/src/CMakeLists.txt: Use stubs on win32 |
| 20:55.20 | ``Erik | starseeker: when installed, cmake gives me http://paste.lisp.org/display/121826 ... rm -rf /usr/brlcad/trunk and cmake works fine |
| 21:00.00 | CIA-105 | BRL-CAD: 03erikgreenwald * r44580 10/brlcad/trunk/src/adrt/isst: add a shebang |
| 21:04.31 | CIA-105 | BRL-CAD: 03erikgreenwald * r44581 10/brlcad/trunk/src/adrt/CMakeLists.txt: put isst in bin/ instead of lib/ |
| 21:05.05 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 21:14.03 | CIA-105 | BRL-CAD: 03erikgreenwald * r44582 10/brlcad/trunk/src/adrt/CMakeLists.txt: install as an executable instead of plain file |
| 21:40.33 | *** join/#brlcad crazy_imp (~mj@a89-182-14-238.net-htp.de) | |
| 22:17.10 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 00:40.24 | *** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 04:06.41 | CIA-105 | BRL-CAD: 0372.234.127.28 07http://brlcad.org * r2870 10/wiki/Documentation: |
| 04:07.29 | CIA-105 | BRL-CAD: 0372.234.127.28 07http://brlcad.org * r2871 10/wiki/Documentation: fffff |
| 05:57.52 | *** join/#brlcad Stattrav (~Stattrav@117.192.130.88) | |
| 05:57.52 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:46.32 | *** join/#brlcad Stattrav (~Stattrav@122.167.87.95) | |
| 06:46.32 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:12.21 | *** join/#brlcad merzo (~merzo@94-26-132-95.pool.ukrtel.net) | |
| 14:35.53 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 18:26.38 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:50.52 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 19:52.02 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 19:55.45 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 21:40.19 | *** join/#brlcad crazy_imp (~mj@89.182.18.71) | |
| 03:52.57 | *** join/#brlcad dli (~dli@66.49.170.199) | |
| 07:49.41 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 07:49.41 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412) | |
| 09:21.39 | *** join/#brlcad Stattrav (~Stattrav@117.192.148.24) | |
| 09:21.39 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:15.39 | *** join/#brlcad Stattrav (~Stattrav@117.192.148.24) | |
| 18:15.39 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:27.59 | *** join/#brlcad Stattrav (~Stattrav@117.192.131.205) | |
| 18:27.59 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:13.00 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 19:49.11 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 20:00.01 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 20:32.44 | *** join/#brlcad Stattrav (~Stattrav@117.192.131.38) | |
| 20:32.44 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:41.05 | *** join/#brlcad crazy_imp (~mj@a89-183-10-209.net-htp.de) | |
| 06:43.39 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 06:55.16 | d_rossberg | starseeker: because of the LIB_DIR: i still didn't got it, line 1545 in my top level CMakeLists.txt file is MESSAGE("${CONFIG_TIME_MSG_LABEL}..: ${CONFIG_TIME_MSG}") |
| 07:45.04 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 07:45.04 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:02.23 | *** join/#brlcad Stattrav (~Stattrav@122.167.76.167) | |
| 08:02.23 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:50.52 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:57.10 | dloman_ | yawns |
| 11:52.49 | CIA-105 | BRL-CAD: 03davidloman * r44583 10/geomcore/trunk/include/Portal.h: Fix includes for proper compilation on Ubuntu |
| 13:07.57 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:42.25 | starseeker | LIB_DIR is being set by the macro in the toplevel CMakeLists.txt file line 1545 |
| 13:43.03 | starseeker | in trunk |
| 13:43.16 | starseeker | re-checks line number... |
| 13:44.21 | starseeker | oops |
| 13:44.53 | starseeker | 404 rather |
| 13:47.11 | starseeker | d_rossberg: yeah, sorry - line 404 |
| 13:59.42 | d_rossberg | starseeker: ok, now i got it, thanks |
| 14:39.32 | d_rossberg | btw, enigma can can be build with MSVC using mingwrep's libcrypt |
| 16:05.42 | *** join/#brlcad Stattrav (~Stattrav@117.202.26.95) | |
| 16:05.42 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:09.12 | CIA-105 | BRL-CAD: 03starseeker * r44584 10/brlcad/trunk/src/adrt/ (CMakeLists.txt isst.bat): Add .bat file for isst on Windows. |
| 19:12.41 | CIA-105 | BRL-CAD: 03erikgreenwald * r44585 10/brlcad/trunk/src/adrt/ (isst.h isst_tcltk.c): use bu_gettime() instead of gettimeofday |
| 19:46.03 | CIA-105 | BRL-CAD: 03starseeker * r44586 10/brlcad/trunk/misc/CMake/test_srcs/time.c.in: whoops - need the zero on the ninth too |
| 19:52.45 | CIA-105 | BRL-CAD: 03starseeker * r44587 10/brlcad/trunk/src/other/togl/ (6 files in 2 dirs): See if we can avoid putting headers in the src directory... |
| 19:53.30 | CIA-105 | BRL-CAD: 03starseeker * r44588 10/brlcad/trunk/src/adrt/CMakeLists.txt: Ignore the bat file too. |
| 19:55.35 | CIA-105 | BRL-CAD: 03erikgreenwald * r44589 10/brlcad/trunk/src/adrt/isst_tcltk.c: move variable declarations to beginning of block. Change trunc() to floor(). |
| 20:15.09 | CIA-105 | BRL-CAD: 03erikgreenwald * r44590 10/brlcad/trunk/src/adrt/isst_tcltk.c: Should be Issttcltk_Init, not Isst_Init. |
| 20:17.17 | CIA-105 | BRL-CAD: 03erikgreenwald * r44591 10/brlcad/trunk/src/adrt/CMakeLists.txt: fix path info for pkgIndex.tcl |
| 20:37.27 | *** join/#brlcad Stattrav (~Stattrav@117.202.26.95) | |
| 20:37.27 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:37.30 | CIA-105 | BRL-CAD: 03erikgreenwald * r44592 10/brlcad/trunk/TODO: add some items for next release |
| 20:47.48 | *** join/#brlcad Stattrav (~Stattrav@117.202.26.95) | |
| 20:47.48 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:50.57 | CIA-105 | BRL-CAD: 03erikgreenwald * r44593 10/brlcad/trunk/src/adrt/librender/ (render.h render_internal.h): define RENDER_EXPORT for dll export/import |
| 21:15.29 | *** join/#brlcad Stattrav (~Stattrav@117.202.26.95) | |
| 21:15.29 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:40.50 | *** join/#brlcad crazy_imp (~mj@a89-183-31-199.net-htp.de) | |
| 22:15.19 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 00:35.34 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 01:11.33 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177871643.dsl.bell.ca) | |
| 05:23.34 | *** join/#brlcad Stattrav (~Stattrav@122.167.76.167) | |
| 05:23.35 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:38.54 | CIA-105 | BRL-CAD: 03Maria geneva averia 07http://brlcad.org * r2872 10/wiki/How_Does_Car_Insurance_Works_In_The_Community: New page: == Car Insurance Quotes - How Does Car Insurance Works In The Community == There is something about today`s world that seems to give us restlessness? Is it because of the vast social or... |
| 05:48.06 | CIA-105 | BRL-CAD: 0368.234.216.134 07http://brlcad.org * r2873 10/wiki/How_Does_Car_Insurance_Works_In_The_Community: Blanking spam page. |
| 07:21.09 | *** join/#brlcad Stattrav (~Stattrav@122.167.76.167) | |
| 07:21.09 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:02.13 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 08:31.30 | *** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no) | |
| 11:03.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:14.24 | CIA-105 | BRL-CAD: 03Erik 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Maria geneva averia]] with an expiry time of infinite (account creation disabled): Spamming links to external sites |
| 11:14.38 | CIA-105 | BRL-CAD: 03Erik 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[How Does Car Insurance Works In The Community]]": Spam. |
| 12:52.26 | *** join/#brlcad Stattrav (~Stattrav@117.202.17.194) | |
| 12:52.26 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:08.36 | CIA-105 | BRL-CAD: 03starseeker * r44594 10/brlcad/trunk/src/ (3 files in 3 dirs): See if a togl stub library works for Windows. |
| 13:16.45 | CIA-105 | BRL-CAD: 03erikgreenwald * r44595 10/brlcad/trunk/NEWS: catch up on some news items |
| 13:26.53 | CIA-105 | BRL-CAD: 03erikgreenwald * r44596 10/brlcad/trunk/src/other/togl/src/CMakeLists.txt: TOGL_STUB_LIBRARIES should be marked "advanced" to avoid cmake-gui clutter |
| 13:30.15 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 13:52.48 | *** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ) | |
| 14:56.39 | CIA-105 | BRL-CAD: 03starseeker * r44597 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: Add some comments to the third party logic. |
| 14:59.29 | CIA-105 | BRL-CAD: 03starseeker * r44598 10/brlcad/trunk/CMakeLists.txt: Make the logic to prevent CMake from searching in CMAKE_INSTALL_PREFIX more robust. |
| 17:04.36 | *** join/#brlcad mafm (~mafm@236.Red-81-39-254.dynamicIP.rima-tde.net) | |
| 17:28.17 | CIA-105 | BRL-CAD: 03starseeker * r44599 10/brlcad/trunk/TODO: fixed detection issue |
| 18:11.56 | *** join/#brlcad merzo (~merzo@15-138-94-178.pool.ukrtel.net) | |
| 18:25.45 | CIA-105 | BRL-CAD: 03starseeker * r44600 10/brlcad/trunk/CMakeLists.txt: Er, oops - turn 64 bit off for 32bit compiler... |
| 19:11.43 | CIA-105 | BRL-CAD: 03starseeker * r44601 10/brlcad/trunk/src/adrt/CMakeLists.txt: Still need isst script on WIN32 |
| 19:17.15 | CIA-105 | BRL-CAD: 03erikgreenwald * r44602 10/brlcad/trunk/src/adrt/CMakeLists.txt: add opengl libraries |
| 19:27.35 | CIA-105 | BRL-CAD: 03starseeker * r44603 10/brlcad/trunk/src/adrt/CMakeLists.txt: Restore in-build-tree pkgIndex.tcl setup for isst. |
| 19:28.45 | CIA-105 | BRL-CAD: 03starseeker * r44604 10/brlcad/trunk/src/adrt/isst_tcltk.c: Linux needs Isst_Init |
| 19:29.49 | *** join/#brlcad Stattrav (~Stattrav@117.202.17.194) | |
| 19:29.49 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:01.32 | CIA-105 | BRL-CAD: 03bob1961 * r44605 10/brlcad/trunk/src/rt/ (do.c main.c opt.c): Fix rt commands use of "-c orientation" subcommand. |
| 20:33.30 | CIA-105 | BRL-CAD: 03r_weiss * r44606 10/brlcad/trunk/ (5 files in 2 dirs): Updated nmg boolean functions using the classlist array. Changed the classlist type from 'long' to 'size_t'. |
| 20:36.13 | CIA-105 | BRL-CAD: 03starseeker * r44607 10/brlcad/trunk/CMakeLists.txt: Make a stab at broader coverage for the 'searching in install paths' issue - don't know if this fully works as yet. |
| 20:55.29 | CIA-105 | BRL-CAD: 03starseeker * r44608 10/brlcad/trunk/CMakeLists.txt: |
| 20:55.30 | CIA-105 | BRL-CAD: Go for the SYSTEM paths - they aren't intended to be modified by the project |
| 20:55.30 | CIA-105 | BRL-CAD: according to CMake, but until we find another way to avoid searching |
| 20:55.32 | CIA-105 | BRL-CAD: CMAKE_INSTALL_PREFIX we seem to have little choice. Need to test this on |
| 20:55.33 | CIA-105 | BRL-CAD: Windows to see if it helps there. |
| 20:57.14 | CIA-105 | BRL-CAD: 03starseeker * r44609 10/brlcad/trunk/CMakeLists.txt: Fix comment's line number reference |
| 21:40.36 | *** join/#brlcad crazy_imp (~mj@a89-183-46-218.net-htp.de) | |
| 22:06.21 | CIA-105 | BRL-CAD: 03starseeker * r44610 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: ffast-math is causing tessellation failures on some platforms. |
| 00:17.19 | *** join/#brlcad dtidrow (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) | |
| 02:27.52 | *** join/#brlcad merzo (~merzo@116-46-94-178.pool.ukrtel.net) | |
| 02:33.07 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096600985.dsl.bell.ca) | |
| 03:13.48 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601166.dsl.bell.ca) | |
| 03:45.50 | CIA-105 | BRL-CAD: 03Paydayloan251 07http://brlcad.org * r2874 10/wiki/Payday_Loan_-_How_To_Get_The_Best_Payday_Loan: New page: Do net get too hard on yourself on how you can get the best solution to your problem now if you are running out from your expenses because of some emergency cases because the '''[http://ww... |
| 06:44.42 | CIA-105 | BRL-CAD: 03Rossberg 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Payday Loan - How To Get The Best Payday Loan]]": Spam |
| 06:48.19 | CIA-105 | BRL-CAD: 03Rossberg 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Paydayloan251]] with an expiry time of infinite (account creation disabled, autoblock disabled): Spamming links to external sites |
| 06:56.46 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:41.22 | *** join/#brlcad Stattrav (~Stattrav@122.167.76.167) | |
| 07:41.23 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:54.40 | *** join/#brlcad waprat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 10:08.17 | *** join/#brlcad mafm (~mafm@131.Red-83-37-177.dynamicIP.rima-tde.net) | |
| 10:21.11 | *** join/#brlcad mafm_ (~mafm@131.Red-83-37-177.dynamicIP.rima-tde.net) | |
| 11:26.30 | kunigami | I'm studying the osl language and I found a raytracer using it. The problem is that in rendering a glass sphere incorrectly: http://kuniga.files.wordpress.com/2021/04/corrected.png |
| 11:27.36 | ``Erik | those look like chrome balls, not glass |
| 11:29.23 | ``Erik | the scene specification actually lists them as glass, with a refraction coefficient and everything? |
| 11:30.11 | kunigami | Erik: yes, the dark sphere should be a glass one, like the original rendering http://kuniga.files.wordpress.com/2021/04/testrender_closures_fixed_refraction.jpg |
| 11:31.01 | ``Erik | hm, it seems to handle reflection ok, but refraction is all wrong |
| 11:31.37 | kunigami | ah ok, nice to know this. I'll look through the code to see if I can identify anything |
| 11:31.39 | ``Erik | still might be worth studying to see how they interfaced *shrug* :) |
| 11:32.10 | ``Erik | bbiab, heading to the office |
| 11:34.16 | kunigami | ok! |
| 11:58.49 | kunigami | the description of the glass shader is here: http://pastebin.com/6dMgch1A |
| 17:02.53 | *** join/#brlcad Stattrav (~Stattrav@117.192.131.185) | |
| 17:02.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:11.30 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:50.00 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 19:04.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:41.24 | *** join/#brlcad crazy_imp (~mj@a89-182-7-124.net-htp.de) | |
| 22:39.10 | starseeker | hah, cool! http://farside.ph.utexas.edu/euclid.html |
| 05:43.40 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 05:54.14 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 06:32.28 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 06:32.28 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:08.08 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:59.20 | *** join/#brlcad mafm_ (~mafm@251.Red-83-49-86.dynamicIP.rima-tde.net) | |
| 11:48.31 | dloman_ | yawns |
| 12:00.35 | ``Erik | yargh |
| 12:55.40 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 13:07.21 | ``Erik | awesome, the euclid book has greek and english side by side O.o |
| 15:24.02 | dloman_ | im confused.... does a 'directory struct' point to a single DB object or a set of DB objects? |
| 16:27.37 | d_rossberg | i would say mainly to a single object (d_namep), but there are also members of a concatenated list |
| 16:30.58 | *** join/#brlcad CIA-58 (cia@cia.atheme.org) | |
| 16:51.37 | *** join/#brlcad Stattrav (~Stattrav@117.192.144.223) | |
| 16:51.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:18.33 | *** join/#brlcad CIA-58 (cia@cia.atheme.org) | |
| 18:49.32 | *** join/#brlcad mafm (~mafm@251.Red-83-49-86.dynamicIP.rima-tde.net) | |
| 19:35.32 | *** join/#brlcad CIA-61 (cia@cia.atheme.org) | |
| 20:02.53 | starseeker | ``Erik: yeah - apparently the definitive version of Euclid's elements was done in the 1880's in Greek - "out of print" is putting it mildly |
| 20:03.24 | starseeker | I like that two column format - makes a nifty rosetta-stoneish setup for Greek/English |
| 20:04.00 | starseeker | too bad he didn't include a little more background on the research and sources that went into the original Greek compilation - from what little I know it was quite the project |
| 20:13.36 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 20:48.56 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 21:41.13 | *** join/#brlcad crazy_imp (~mj@a89-183-19-40.net-htp.de) | |
| 22:44.25 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 04:43.16 | *** join/#brlcad Stattrav (~Stattrav@122.167.76.167) | |
| 04:43.16 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:27.51 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 09:00.31 | *** join/#brlcad mafm (~mafm@144.Red-88-23-76.staticIP.rima-tde.net) | |
| 10:10.39 | dloman_ | yawns |
| 11:37.42 | dloman_ | http://www.youtube.com/watch?v=9BnLbv6QYcA&feature=related |
| 11:37.45 | dloman_ | i lol'd |
| 12:55.31 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:57.19 | dloman_ | starseeker: you're the primary author of search.c ...right? |
| 13:13.25 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) | |
| 13:28.27 | ``Erik | heh, my mom sent me an email with a classic... http://brlcad.org/~erik/shouldbe.html |
| 13:31.24 | dloman_ | nice :) |
| 13:31.53 | dloman_ | ``Erik: the argc and argv passed to db_walk_tree, are those the 'start' points for the walker? |
| 13:32.23 | *** join/#brlcad Stattrav (~Stattrav@117.202.23.71) | |
| 13:32.23 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:32.39 | ``Erik | yeah, the region/comb names |
| 13:34.11 | dloman_ | awesome danke |
| 13:48.37 | ``Erik | peers around |
| 13:52.21 | dloman_ | quiet today |
| 13:54.02 | ``Erik | brlcad is parked on his tofu name, so he's not 'here'. :/ have a couple things I need to ask him. Wait, sorry, baltimore, aks him. :D |
| 13:54.53 | dloman_ | *snicker* |
| 13:55.07 | dloman_ | i hate it when people axe me questions. |
| 15:23.39 | starseeker | dloman_: kinda - I built on top of some find code |
| 15:23.45 | dloman_ | kk |
| 15:23.56 | starseeker | is it having trouble? |
| 15:24.05 | dloman_ | not it, but me :) |
| 15:37.30 | starseeker | hmm: http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/ |
| 15:37.48 | starseeker | "Qt will require OpenGL (ES) 2.0 to work. QWidgets will be layered on top of the scene graph (not the scene graph on top of QWidgets as is currently done with Qt 4)." |
| 15:38.13 | starseeker | wonder if that means Qt-in-OpenGL is going to get simpler? |
| 15:41.12 | *** join/#brlcad mafm_ (~mafm@144.Red-88-23-76.staticIP.rima-tde.net) | |
| 17:46.30 | CIA-61 | BRL-CAD: 03davidloman * r44613 10/geomcore/trunk/tests/func/GE/ (CMakeLists.txt GeometryEngineTest.cxx): Work on a small test. |
| 18:23.36 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:54.19 | *** join/#brlcad Stattrav (~Stattrav@117.192.141.51) | |
| 18:54.19 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:05.27 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.133.142) | |
| 19:10.26 | *** join/#brlcad Stattrav (~Stattrav@117.192.129.225) | |
| 19:10.26 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:41.01 | *** join/#brlcad crazy_imp (~mj@a89-182-4-131.net-htp.de) | |
| 22:51.21 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177593434.dsl.bell.ca) | |
| 23:41.42 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177593434.dsl.bell.ca) | |
| 10:03.20 | *** join/#brlcad Stattrav (~Stattrav@117.192.134.167) | |
| 10:03.20 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 04:20.13 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 04:20.13 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412) | |
| 04:31.26 | *** join/#brlcad ebrown (~^echa^@110.138.166.185) | |
| 05:13.12 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 10:21.51 | *** join/#brlcad Stattrav (~Stattrav@117.192.158.93) | |
| 10:21.51 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:55.04 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 13:29.02 | *** join/#brlcad Stattrav (~Stattrav@117.192.158.93) | |
| 13:29.02 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:01.51 | *** join/#brlcad CIA-117 (cia@cia.atheme.org) | |
| 21:32.41 | *** join/#brlcad crazy_imp (~mj@a89-183-57-212.net-htp.de) | |
| 04:54.53 | *** join/#brlcad Stattrav (~Stattrav@117.192.128.2) | |
| 04:54.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:56.43 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.128.2) | |
| 06:58.41 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 10:18.17 | CIA-117 | BRL-CAD: 03Homeloanbroker 07http://brlcad.org * r2882 10/wiki/Home_Loan_Broker_-_How_to_Become_a_Loan_Modification_Broker: New page: If you want to become a '''[http://www.mortgagecomparison.com.au/ home loan broker]''', or specifically a loan modification broker, then you must undergo some training or rather get a real... |
| 11:24.44 | *** join/#brlcad finbrein (finbrein@CXXVII.voas.sl-laajakaista.fi) | |
| 11:26.19 | *** part/#brlcad finbrein (finbrein@CXXVII.voas.sl-laajakaista.fi) | |
| 11:35.05 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:43.48 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.143.203) | |
| 12:01.02 | dloman_ | yawns |
| 12:06.29 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:39.16 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 13:19.51 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 13:34.32 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 15:27.11 | *** join/#brlcad dli (~dli@66.49.170.199) | |
| 15:50.43 | CIA-117 | BRL-CAD: 03erikgreenwald * r44614 10/brlcad/trunk/TODO: lights-regress seems to work now. tesselation issue on optimized build was due to -ffast-math, so Cliff removed the flag. |
| 15:55.29 | *** join/#brlcad Stattrav (~Stattrav@117.192.143.203) | |
| 15:55.29 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:21.28 | CIA-117 | BRL-CAD: 03erikgreenwald * r44615 10/rt^3/trunk/cmake/FindBRLCAD.cmake: remove tie |
| 17:33.04 | CIA-117 | BRL-CAD: 03starseeker * r44616 10/brlcad/trunk/misc/CMake/FindOPENNURBS.cmake: See if this helps on Windows... |
| 17:41.41 | CIA-117 | BRL-CAD: 03erikgreenwald * r44617 10/geomcore/trunk/CMake/FindBRLCAD.cmake: remove tie |
| 18:06.27 | CIA-117 | BRL-CAD: 03erikgreenwald * r44618 10/brlcad/trunk/CMakeLists.txt: Don't try the math expression if we don't have a void pointer size (???) (starseeker) |
| 18:08.29 | CIA-117 | BRL-CAD: 03erikgreenwald * r44619 10/brlcad/trunk/misc/CMake/ (FindOPENNURBS.cmake FindUTAHRLE.cmake): |
| 18:08.29 | CIA-117 | BRL-CAD: Expand on the OpenNURBS and Utah find routines a big - not making much use of |
| 18:08.29 | CIA-117 | BRL-CAD: these yet, but the expanded tests happen to fail on Windows for the installed |
| 18:08.29 | CIA-117 | BRL-CAD: BRL-CAD, which avoids some configure problems. Still haven't found a good way |
| 18:08.29 | CIA-117 | BRL-CAD: yet to forcibly exclude the installed directory from the search on Windows. |
| 18:08.30 | CIA-117 | BRL-CAD: (starseeker) |
| 18:11.14 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 18:11.50 | CIA-117 | BRL-CAD: 03erikgreenwald * r44620 10/brlcad/trunk/misc/CMake/FindOPENNURBS.cmake: Clean up debug message |
| 20:54.31 | CIA-117 | BRL-CAD: 03Erik 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 20:54.31 | CIA-117 | BRL-CAD: deleted "[[Home Loan Broker - How to Become a Loan Modification Broker]]": |
| 20:54.31 | CIA-117 | BRL-CAD: content was: 'If you want to become a '''[http://www.mortgagecomparison.com.au/ |
| 20:54.31 | CIA-117 | BRL-CAD: home loan broker]''', or specifically a loan modification broker, then you must |
| 20:54.32 | CIA-117 | BRL-CAD: unde...' (and the only contributor was |
| 20:54.32 | CIA-117 | BRL-CAD: '[[Special:Contributions/Homeloanbroker|Homeloanbroker]]') |
| 20:54.54 | CIA-117 | BRL-CAD: 03Erik 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 20:54.54 | CIA-117 | BRL-CAD: deleted "[[Casino Online - How To Find Craps Rules Online]]": content was: '== |
| 20:54.54 | CIA-117 | BRL-CAD: Casino Online - How To Find Craps Rules Online ==Finding and searching the |
| 20:54.54 | CIA-117 | BRL-CAD: '''[http://www.casinobonus24.com/ casino online]''' that you are look...' (and |
| 20:54.54 | CIA-117 | BRL-CAD: the only contributor was |
| 20:54.54 | CIA-117 | BRL-CAD: '[[Special:Contributions/Mariagbuilder1|Mariagbuilder1]]') |
| 20:55.25 | CIA-117 | BRL-CAD: 03Erik 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Homeloanbroker]] with an expiry time of infinite (account creation disabled): Spamming links to external sites |
| 20:55.46 | CIA-117 | BRL-CAD: 03Erik 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Mariagbuilder1]] with an expiry time of infinite (account creation disabled): Spamming links to external sites |
| 21:20.31 | *** join/#brlcad crazy_imp (~mj@a89-183-12-108.net-htp.de) | |
| 21:24.17 | *** join/#brlcad dli (~dli@66.49.170.199) | |
| 22:13.41 | kunigami_ | I had to go through older versions of osl and oiio just to discover I was using the wrong glass shader >.< |
| 22:15.17 | ``Erik | well, at lesat ya found it :) |
| 22:17.04 | kunigami_ | :) yup |
| 22:17.08 | ``Erik | I think the far bigger task is isolation and integration, a first cut might use a fixed 'flat' shader (always return #ff0000), then try phong or normal |
| 22:17.44 | kunigami_ | hmm what do you mean by isolation? |
| 22:18.12 | ``Erik | figuring how much of what comes in the source tarball is actually required, removing things like demos and unused code, etc |
| 22:19.11 | ``Erik | I've no idea how much came with it, so'z I might not make sense *shrug* |
| 22:20.37 | kunigami_ | hmm ok. actually it seems the source is quite small. it is mainly the osl compiler, the shaders interpreter and the shaders tester |
| 22:21.48 | ``Erik | hm, cool |
| 22:22.01 | ``Erik | starseeker mentioned something about an insane dependancy list for it |
| 22:23.13 | kunigami_ | yes, there is also an important question: the idea is to create a dependence of osl or take a part of their code and start an independent development? |
| 22:23.48 | kunigami_ | as far as I remember, brlcad has few explicit dependencies. on the other hand installing osl is not trivial] |
| 22:23.48 | kunigami_ | |
| 22:24.47 | ``Erik | my guess is that the osl interface will exist in src/liboptical as a C style shader that interfaces OSL, OSL goes in src/other/osl/ (other deps might go in src/other) |
| 22:28.37 | kunigami_ | so, there will be a single C like shader that will call the while osl system right? |
| 22:29.15 | ``Erik | that'd be my guess |
| 23:06.18 | kunigami_ | a question regarding the wiki: is there any way to upload images in a personal directory? the last time I uploaded it went to a global scope. My main fear is that it overwrites some existing image... |
| 23:14.58 | ``Erik | no, it's not set up to allow that. You can always upload it somewhere like google images or flickr or something and link it in the wiki |
| 23:16.15 | kunigami_ | ok! thanks! |
| 00:57.20 | starseeker | ``Erik: my take would be to focus on getting a working shader - integration into the build logic can come later |
| 00:57.35 | starseeker | for the moment, we could even assume an installed osl |
| 00:58.27 | starseeker | I'd probably have to cmakeify at least one or two deps - to the best of my knowledge tbb doesn't currently use CMake, for example |
| 01:05.49 | starseeker | idly wonders if imageio could sub for freeimage in ogre... |
| 01:05.54 | starseeker | openimageio rather |
| 03:47.58 | ``Erik | starseeker: the src/liboptical/sh_osl.c thing is what I meant, integrate it into our raytracing package. Not spend a lot of time writing shaders for it before... src/other with checks for system are after some basic integration |
| 07:03.25 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:23.03 | *** join/#brlcad Stattrav_ (~Stattrav@111.93.134.142) | |
| 10:52.48 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 12:55.19 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 13:42.19 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 14:14.02 | dloman_ | bangs head against keyboard..... doesn't wanna write a custom treewalker :( |
| 14:16.04 | ``Erik | why would you need to? we have too many already? |
| 14:17.03 | ``Erik | cinematics are dandy and all, but after half a dozen times, zomfg, give me a button to skip it, seriously |
| 14:17.26 | dloman_ | trying to make a tree walker that does two things: 1) keeps track of full path and 2) creates the appropriate bu_ext |
| 14:17.32 | dloman_ | i get 1 easy |
| 14:17.40 | dloman_ | but 2 keeps eluding me. |
| 14:18.16 | dloman_ | every different tree walker i've tried fails on 'badmagic' cause somehow, the directory* gets 'misaligned' with the db_i* |
| 14:18.24 | ``Erik | ooh, all the tree walkers are thinking prepped geometry, not disk... you MIGHT be able to create a memory image and do a wdb export into it, then have a magic bu_external |
| 14:18.30 | ``Erik | I think that might be what, um |
| 14:18.55 | ``Erik | bad magic probably means you're trying to use a bu_external as a .g file, which is not valid |
| 14:19.30 | ``Erik | g_transfer.c dude |
| 14:19.36 | dloman_ | hrm, dunno how. just calling bu_get_external() and feeding it a dbip and directory |
| 14:19.38 | ``Erik | your answers are there :D |
| 14:19.49 | dloman_ | kk, i've been all over search.c, keep.c paths.c |
| 14:19.53 | dloman_ | thanks, i'll check it. |
| 14:20.17 | ``Erik | src/gtools/g_transfer.c, brlcad mentioned it a while ago |
| 14:20.42 | dloman_ | okay, that's half the info i already know. |
| 14:20.55 | dloman_ | i can make valid bu_externals by simply looping thru the file. |
| 14:21.07 | dloman_ | and i can get a good set of full paths by tree walking. |
| 14:21.32 | dloman_ | now, i need to combine the two so I can do both in one pass over the file. |
| 14:21.37 | dloman_ | ..... that even possible? |
| 14:21.42 | ``Erik | a bu_external maps immediately to a single line of a .asc file |
| 14:21.58 | dloman_ | righto. |
| 14:22.00 | ``Erik | maybe the g2asc program will help you more |
| 14:22.02 | dloman_ | well, here's a question |
| 14:22.07 | ``Erik | since it has to do that by definition |
| 14:22.26 | dloman_ | is there a way to take a db object name and get its full path? |
| 14:23.29 | ``Erik | I'm questioning myself on the notion of what full path means in the BRL-CAD filesystem... I'm kinda thinking that there is no such thing as a path, it's imaginary :D or, rather, reconstituted based on relationships |
| 14:23.48 | ``Erik | the whole "flat namespace" has always bugged me a bit |
| 14:24.26 | ``Erik | using notation to denote a tree when everything sits at the same level and stacks metadata to denote associations... *shudder* |
| 14:24.38 | dloman_ | hrm. time to ponder and test code more. |
| 14:24.42 | ``Erik | denote note note denote note stop. morse dork. :D |
| 14:25.01 | dloman_ | backs away slowly. |
| 14:25.15 | ``Erik | I'm off today, man, cut me some slack |
| 14:25.33 | dloman_ | =D |
| 14:25.38 | ``Erik | I'm just saying that viewing it as a real 'path' may be problematic, it might not actually exist that way |
| 14:26.00 | ``Erik | it's more like a strange ORM in reality |
| 14:26.02 | dloman_ | that's why i'd like to be able to 'walk' the tree and verify the path. |
| 14:26.33 | dloman_ | aka, a user specifies they want a list of all child objects of /some/path/to/an/obj.r |
| 14:26.54 | dloman_ | where the actual .g file is named 'to' |
| 14:26.57 | ``Erik | yeah, and that's why I'm bugged, it has to be hand assembled from the entire soup |
| 14:27.11 | ``Erik | mebbe we'll do real pathing in v6 |
| 14:27.53 | ``Erik | you'd have to stop at 'to' and pull everything in it to construct the tree, the tree does not explicitely exist in the .g |
| 14:28.02 | ``Erik | it's assembled from name relationships at load time |
| 14:28.03 | dloman_ | exactly |
| 14:29.39 | ``Erik | gonna go swap laundry, the things you should probably be looking at are g2asc, libged tops, maybe pulling a loaded 'internal' tree and doing exports on each bit |
| 14:30.21 | dloman_ | thinking about giving up and chalking it to 'premature optimization' |
| 14:30.27 | dloman_ | and just doing in two passes |
| 14:30.36 | dloman_ | slower, yeah, but hellova lot less frustrating |
| 14:30.43 | ``Erik | good luck O.o :D *think* butler might be able to help, brlcad might, but he's otherwise occupied... |
| 14:30.55 | dloman_ | doody duty |
| 14:30.57 | ``Erik | for the muves guys, performance is not a concern |
| 14:30.58 | dloman_ | *snicker* |
| 14:31.07 | dloman_ | don't really care about them |
| 14:31.10 | ``Erik | dropped off their package on saturday, btw |
| 14:31.26 | dloman_ | im thinking of mged 2 or 3 performance. |
| 14:31.36 | ``Erik | they're the ones driving funding and deadlines... yeah, we want better, but if under teh gun, just gotta shut them up, right? |
| 14:31.46 | dloman_ | yuppers. |
| 14:31.58 | ``Erik | soo mebbe you should KISS |
| 14:32.31 | ``Erik | who knows, maybe the simple slow approach is adequate |
| 14:32.43 | dloman_ | yeah, i was just thinking that same thing. |
| 14:32.44 | dloman_ | heh |
| 14:35.12 | ``Erik | (yeah, you kinda already said it, I was agreeing) |
| 14:35.34 | dloman_ | i was focusing on the 'stupid' part, lol |
| 14:35.42 | dloman_ | my head hurts cause of this stuff. |
| 14:35.46 | dloman_ | i sooooooo can't read C |
| 14:35.47 | ``Erik | "keep it stupid, simple?" |
| 14:36.15 | ``Erik | heh, different paradigm than you're used to |
| 14:36.27 | dloman_ | that's Yodas version? |
| 14:36.52 | ``Erik | I thought I was a really good programmer when I went back to college, bitched like crazy when I had to learn new languages and design paradigms... |
| 14:37.15 | ``Erik | I think every new language and definitely every new paradigm has made me a much better programmer in all the languages I can use |
| 14:37.58 | dloman_ | hehehe, just reading thru www.ihas1337code.com makes me realize just how much i missed by not going to college for CS. |
| 14:38.23 | ``Erik | it twists your mind and makes you look at things differently... and then enlightenment :) |
| 14:40.12 | ``Erik | the, uh, monthly 'scrum', one of the points ed wanted to talk about was the future of GS and having you rotate to other stuff, drag you out of isolation and expose you to other stuff |
| 14:40.30 | dloman_ | that'd be nice |
| 14:40.48 | ``Erik | are you in the office? I know ed is in, he answered his phone a bit confused |
| 14:41.01 | dloman_ | yeah, im here. |
| 14:41.36 | ``Erik | well, there ya go :D walk over and mention it, I'd be willing to go on speakerphone since I poked the tiger |
| 14:42.12 | dloman_ | well, there's the issue of me being pissed that i can't make this thing work the way i want it to, as easily as it should be to implement. |
| 14:42.29 | dloman_ | im stubborn like that, an i really want this to be done. |
| 14:43.37 | ``Erik | dude, it's a whole bucketload of very specialized knowledge, the smart thing is to say "hey, this is hard" and get help... |
| 14:43.51 | dloman_ | that's why i have you :P |
| 14:44.02 | ``Erik | I mean, what'd you say if a coner tried to restart a reactor and refused to stop and say they didn't know what was going on? |
| 14:44.23 | ``Erik | getwhutahmean,verne? |
| 14:44.36 | dloman_ | to be fair, things have gotten a whole lot better since i stopped trying to hammer rocks into swords :) |
| 14:45.00 | dloman_ | well, in that case, i'd laugh, then leave the boat. power to him :) |
| 14:45.04 | dloman_ | but i know what you mean. |
| 14:45.15 | ``Erik | notes that he is not on the boat at the moment O:-) *duck* |
| 14:46.16 | ``Erik | sorry, couldn't resist that one.. Cliff Ed and I talked a bit about the needs, state, possibilities, etc of GS and ed felt that you and brlcad needed some insight, but it was time to stop and see what was what |
| 14:46.36 | dloman_ | right on |
| 14:47.00 | dloman_ | i'd like to get it to a point where i can say: Here, its working. Barely, but its working to reqs. |
| 14:47.16 | ``Erik | I think cliff and i did a big info dump that he grokked, but a little more data was needed for a good decision |
| 14:47.38 | ``Erik | it might be that the lithp version is close enough to their requirements that we can say "good 'nuff till next fy" |
| 14:48.06 | dloman_ | that's my fallback, so thanks for that :) |
| 14:48.24 | ``Erik | is cliff in? be social, man, our downfall is lack of communication |
| 14:48.42 | dloman_ | oh, we've talked a lot the last few weeks :) |
| 14:48.59 | dloman_ | ive tripled my understanding of the brlcad libs in a short time. |
| 14:49.26 | dloman_ | add in the fact that i am finally confident enough to say "No, using that lib is stupid" |
| 14:49.27 | ``Erik | talking and communication are not necessarily parallel, and ed feels in the dark a lot of the time |
| 14:50.22 | ``Erik | he's a good guy to talk to, I'd strongly recommend heading over, sitting down and chattering a bit |
| 14:50.36 | dloman_ | will do |
| 14:50.59 | ``Erik | and like I said, I'm off today, but if you feel the need to call up and throw me on speakerphone *shrug* I'm here |
| 14:52.45 | dloman_ | will do, thanks. |
| 15:03.46 | kunigami_ | does the blue ball seem to be using a phong shader? http://imageshack.us/photo/my-images/101/phong3.png/ |
| 15:07.41 | kunigami_ | in this other image is used the microfacet-beckmann shader, http://imageshack.us/photo/my-images/40/imager03.png/ but the specular highlighting is blue instead of white |
| 15:08.02 | ``Erik | kunigami_: yes, phone, but not radiosity or photon mapping, which the rest of the scene seems to be using... the granulatiry makes it look like a combination, almost |
| 15:08.06 | ``Erik | phong, even |
| 15:09.41 | ``Erik | looks like the difference is a specular saturation issue, and the latter kinda looks wrong on reflection issues |
| 15:15.35 | kunigami_ | but shouldn't the phong shader ball look like a snooker ball? |
| 15:15.52 | ``Erik | on pure phong, it'll be very smooth with maybe banding |
| 15:16.32 | ``Erik | if it's a photon map or radiosity type thing before, then the normal will be randomly permutated and you'll get the grainyness |
| 15:17.46 | ``Erik | it could also be that a material property is effecting the normal |
| 15:23.46 | kunigami_ | hmm ok! thanks |
| 15:24.53 | ``Erik | either way, I'd imagine it's a minor issued compared to the src/liboptical/sh_osl.c work... *shrug* just my opinion, you may want to email Daniel Rossberg about it to see his thoughts :) |
| 15:25.08 | ``Erik | he's the one listed as your mentor, right? |
| 15:29.22 | kunigami_ | yup, it's him. ok, I'll send an email to him. |
| 15:30.01 | kunigami_ | I think I already completed what I was expected to do on the bounding time (according to my final proposal) |
| 15:30.35 | kunigami_ | thus, I was trying to do make more complex things before proceeding. |
| 15:31.14 | kunigami_ | anyway, my next task was to understand brlcad shading system |
| 15:37.24 | ``Erik | if it helps, sh_toon.c is something I just recently started, it's a very trivial example |
| 15:37.59 | kanzure | beep boop |
| 15:38.16 | kanzure | i'm still working on my rewrite of esolid |
| 15:38.23 | kanzure | it's a lot of code |
| 15:38.28 | kanzure | there are no unit tests |
| 15:38.46 | kanzure | and there's maybe another 5k lines to write before it might be working |
| 15:38.47 | kanzure | what should i do? |
| 15:43.54 | ``Erik | esolid? I'm not aware of that, can you quickly summarize? |
| 15:48.48 | ``Erik | sorry, gotta run, I'll be on later |
| 15:49.19 | kanzure | nurbs-based boolean operations |
| 15:49.35 | kanzure | (well, trimmed bezier patches) |
| 16:20.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:09.15 | CIA-117 | BRL-CAD: 03davidloman * r44621 10/geomcore/trunk/ (7 files in 2 dirs): Clean up the IDataSource interface a tad. |
| 17:17.48 | *** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ) | |
| 17:25.11 | *** join/#brlcad Stattrav (~Stattrav@117.192.132.43) | |
| 17:25.11 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:46.32 | CIA-117 | BRL-CAD: 03davidloman * r44622 10/geomcore/trunk/src/GS/FileDataSource.cxx: Start work on getListing() |
| 18:00.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:10.30 | starseeker | ah, bugger - http://dev.crypt.co.za/coffee/wiki?name=Project+Status |
| 18:10.35 | starseeker | how'd I miss THAT? |
| 18:21.00 | starseeker | kanzure: did you get a license OK from the original devs? |
| 18:34.59 | starseeker | hmm... apparently tcl/tk switched to fossil?? |
| 18:42.39 | starseeker | ah, right - after that CVS business on SF |
| 18:49.55 | kanzure | starseeker: no didn't get a response from him |
| 18:53.40 | kanzure | why would i be rewriting if i had a permissive license to use the original code? |
| 19:41.56 | CIA-117 | BRL-CAD: 03starseeker * r44623 10/brlcad/trunk/src/other/togl/ (CMakeLists.txt src/CMakeLists.txt): Use LIB_DIR variable for install, so Windows gets things where it expects them. |
| 19:42.10 | starseeker | kanzure: oh, you're re-writing from SCRATCH? |
| 19:42.17 | starseeker | thought you were re-factoring |
| 19:42.52 | kanzure | heh |
| 19:43.00 | kanzure | yeah... i'm doing something dumb |
| 19:43.07 | kanzure | it's taking me forever and i can't really judge my progress along the way |
| 19:43.27 | kanzure | i mean, i sort of am able to - like i have two boxes that are generated and i'm somewhere in the middle of the intersection code |
| 19:43.39 | kanzure | but i don't really know if all of my implementation works the same or not |
| 19:46.42 | starseeker | kanzure: if esolid had test cases, you should at least be able to feed those to your code to see if the results are the same |
| 19:46.54 | kanzure | it has no test cases |
| 19:46.59 | starseeker | winces |
| 19:47.10 | starseeker | are you building off of the opennurbs libraries? |
| 19:47.10 | kanzure | it's roughly 20,000 lines of code |
| 19:47.11 | kanzure | with no tests |
| 19:47.38 | kanzure | no i'm just doing a vanilla implementation/port first using esolid's code base |
| 19:47.45 | kanzure | and then i'll rip out all of the custom crap |
| 19:47.55 | kanzure | and replace it with opennurbs/opengl/scipy/numpy/clapack |
| 19:48.17 | starseeker | um... be careful about that - if you're building off of esolid's code base that might be seen as a "derivative work" |
| 19:48.33 | kanzure | yes i've examined the legal implications thoroughly |
| 19:48.38 | kanzure | don't worry |
| 19:48.45 | starseeker | nods. |
| 19:49.26 | starseeker | might be worth trying to call him if email didn't work - once in a while a phone call will get through where email won't |
| 19:49.43 | kanzure | sure |
| 19:49.52 | kanzure | but honestly, if it doesn't have unit tests, it's not worth that much |
| 19:49.57 | kanzure | someone will have to do what i'm doing eventually anyway |
| 19:50.05 | starseeker | true |
| 19:51.42 | starseeker | q |
| 19:51.45 | starseeker | whoops |
| 20:06.14 | kanzure | so now i don't know what to do |
| 20:06.25 | kanzure | http://diyhpl.us/cgit/lolcad/plain/esolid/esolid.py |
| 20:07.52 | kanzure | write unit tests for the original code base, then re-write them for my own? |
| 20:08.10 | kanzure | keep trucking and weep at the end as i slowly/painfully try to figure out why results are different? |
| 20:08.40 | starseeker | kanzure: how different would unit tests be between your code and the original? |
| 20:08.51 | kanzure | well it's just 2x the amount of code |
| 20:09.07 | kanzure | but other than that the initial upfront figuring out "wtf" is a one-time cost |
| 20:09.53 | starseeker | kanzure: might be worth verifying the original behavior |
| 20:11.19 | kanzure | true.. i should really do it |
| 20:11.28 | kanzure | HOW do these people write this code without testing? |
| 20:12.21 | starseeker | may have figured the tests were too messy to release |
| 20:15.40 | CIA-117 | BRL-CAD: 03starseeker * r44624 10/brlcad/trunk/src/other/togl/CMakeLists.txt: whoops, typo. |
| 21:20.47 | *** join/#brlcad crazy_imp (~mj@a89-183-22-49.net-htp.de) | |
| 21:43.33 | *** join/#brlcad Ralith (~ralith@d142-058-174-188.wireless.sfu.ca) | |
| 22:47.46 | *** join/#brlcad Ralith (~ralith@d142-058-174-188.wireless.sfu.ca) | |
| 01:47.26 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 02:01.25 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 06:29.04 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:07.37 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:27.21 | *** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 08:24.51 | CIA-117 | BRL-CAD: 03122.3.171.14 07http://brlcad.org * r2883 10/wiki/Forex_Trading-_How_To_Understand_FOREX_Market_Sentiment: New page: Did you know that currencies is the most widely trade all aver the world'? This is the reason why the '''[http://www.forexinsider.co.uk/ forex trading]''' market would open 24/7. However, ... |
| 08:55.01 | *** join/#brlcad Stattrav (~Stattrav@122.178.253.199) | |
| 08:55.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:20.04 | *** join/#brlcad Stattrav (~Stattrav@122.178.253.199) | |
| 09:20.04 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:36.41 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 11:41.50 | CIA-117 | BRL-CAD: 03indianlarry * r44625 10/brlcad/trunk/src/conv/step/PullbackCurve.cpp: Fixed array overrun in cubic interpolation routine |
| 14:22.50 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 14:35.46 | CIA-117 | BRL-CAD: 03starseeker * r44626 10/brlcad/trunk/src/other/togl/ (CMakeLists.txt include/CMakeLists.txt src/CMakeLists.txt): Install glew.h, break out header and src logic. |
| 14:37.43 | CIA-117 | BRL-CAD: 03starseeker * r44627 10/brlcad/trunk/TODO: *hopefully* we've now squashed all the red bugs. |
| 15:03.57 | *** join/#brlcad dli (~dli@66.49.170.199) | |
| 15:26.05 | CIA-117 | BRL-CAD: 03starseeker * r44628 10/brlcad/trunk/NEWS: Refine the NEWS file items. |
| 15:39.14 | *** join/#brlcad crazy_imp (~mj@a89-183-22-49.net-htp.de) | |
| 15:46.49 | *** join/#brlcad silvap (~silvap@static-96-255-52-7.washdc.fios.verizon.net) | |
| 15:47.56 | silvap | any of you have individually have >10000 commits to brlcad? |
| 15:48.03 | silvap | -have |
| 16:00.52 | ``Erik | 10364 mike |
| 16:00.53 | ``Erik | 9406 brlcad |
| 16:00.53 | ``Erik | 3241 jra |
| 16:37.02 | *** join/#brlcad Stattrav (~Stattrav@117.192.135.248) | |
| 16:37.03 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:58.49 | CIA-117 | BRL-CAD: 03indianlarry * r44629 10/brlcad/trunk/src/conv/step/ (EdgeCurve.cpp OpenNurbsInterfaces.cpp): |
| 16:58.50 | CIA-117 | BRL-CAD: Generalized curve generation for the ellipse and circle entity loadBrep code; |
| 16:58.50 | CIA-117 | BRL-CAD: also added curve reverse and start/stop point swap for entity 'edge_curve' based |
| 16:58.50 | CIA-117 | BRL-CAD: on 'same_sense' boolean variable. This basically fixed some issues with ellipse |
| 16:58.50 | CIA-117 | BRL-CAD: and circle conics. |
| 18:38.31 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.137.219) | |
| 19:23.58 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.219) | |
| 19:23.58 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:29.19 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.219) | |
| 19:29.19 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:37.16 | CIA-117 | BRL-CAD: 03bob1961 * r44630 10/brlcad/trunk/ (4 files in 3 dirs): Colors were not getting imported for combinations. Standardized attributes on import before calling object specific import func. Moved ATTR enum definitions from db5_types.c to raytrace.h |
| 20:01.32 | CIA-117 | BRL-CAD: 03starseeker * r44631 10/brlcad/trunk/NEWS: Tweak NEWS |
| 20:28.33 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.219) | |
| 20:28.33 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:33.55 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 21:05.23 | *** join/#brlcad Ralith (~ralith@d142-058-174-188.wireless.sfu.ca) | |
| 21:21.24 | *** join/#brlcad crazy_imp (~mj@a89-183-69-41.net-htp.de) | |
| 21:23.27 | alex_joni | hmm.. I can't recall to who I talked in here about http://juve.ro/blog-files/projects/01298803577/version4_x_final.PNG |
| 21:23.44 | alex_joni | anyways, here's an update: http://juve.ro/blog-files/projects/01298803577/version4_xxb_01.JPG |
| 21:23.53 | alex_joni | from: http://juve.ro/blog/projects/01298803577 |
| 21:31.26 | starseeker | alex_joni: awesome! |
| 21:32.40 | starseeker | really cool that you got it built |
| 21:50.17 | alex_joni | starseeker: thanks, hopefully it'll work too |
| 21:51.30 | starseeker | will you be trying it out soon? |
| 21:54.57 | alex_joni | yeah, hopefully these days |
| 21:55.23 | alex_joni | if not, surely over the weekend |
| 22:13.19 | CIA-117 | BRL-CAD: 03starseeker * r44632 10/brlcad/trunk/TODO: Sigh - solids regression is having a problem. Not sure when this started up. |
| 23:45.13 | dli | alex_joni, I initially thought the image were from brl-cad :( |
| 23:47.05 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 00:23.58 | *** join/#brlcad crazy_imp (~mj@a89-182-12-128.net-htp.de) | |
| 01:09.37 | starseeker | errr.... huh? regression passes on gentoo |
| 01:17.16 | CIA-117 | BRL-CAD: 0367.180.102.232 07http://brlcad.org * r2884 10/wiki/Documentation: |
| 04:13.48 | *** join/#brlcad ThePing (~phycho@174.127.64.107) | |
| 04:13.48 | *** part/#brlcad ThePing (~phycho@174.127.64.107) | |
| 06:33.29 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:05.11 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 10:05.07 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:44.15 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 11:51.12 | *** join/#brlcad kunigami1 (~kunigami@loco-gw.ic.unicamp.br) | |
| 12:25.16 | *** join/#brlcad crazy_imp (~mj@a89-182-12-128.net-htp.de) | |
| 12:54.11 | *** join/#brlcad crazy_imp (~mj@a89-182-12-128.net-htp.de) | |
| 15:45.42 | CIA-117 | BRL-CAD: 03r_weiss * r44633 10/brlcad/trunk/ (5 files in 2 dirs): Updated nmg boolean functions using the classlist array. Changed the classlist type from 'size_t' to 'short'. |
| 17:37.43 | CIA-117 | BRL-CAD: 03erikgreenwald * r44634 10/isst/trunk/ (14 files in 5 dirs): ISST repo is now in GIT. "git clone git://brlcad.git.sourceforge.net/gitroot/brlcad/isst.git" to get it. |
| 17:38.03 | dloman | ooooh git :) |
| 17:41.33 | *** join/#brlcad mafm (~mafm@127.Red-88-18-69.staticIP.rima-tde.net) | |
| 18:07.24 | *** join/#brlcad Stattrav (~Stattrav@117.192.151.218) | |
| 18:07.25 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:49.42 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 18:58.47 | ``Erik | surrounded by gits, might as well use git, right? ;> |
| 19:11.46 | CIA-117 | BRL-CAD: 03davidloman * r44635 10/geomcore/trunk/ (4 files in 3 dirs): Implement a path stepper that can step thru FS directories and .g files with the same path. Needs cleanup and generalizing, but it works. |
| 19:23.36 | CIA-117 | BRL-CAD: 03erikgreenwald * r44636 10/brlcad/trunk/src/adrt/isst_tcltk.c: export init functions for msvc |
| 19:48.20 | starseeker | is slightly confused by the "struct bu_mro" in struct region - is there any reason we don't just point to the bu_avs from the comb? |
| 19:48.30 | starseeker | (for attr_values) |
| 19:57.43 | *** join/#brlcad Stattrav (~Stattrav@117.192.151.218) | |
| 19:57.43 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:09.13 | *** join/#brlcad Stattrav (~Stattrav@117.192.151.218) | |
| 20:09.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:33.01 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 21:36.17 | *** join/#brlcad merzo (~merzo@57-12-94-178.pool.ukrtel.net) | |
| 22:07.26 | CIA-117 | BRL-CAD: 03r_weiss * r44637 10/brlcad/trunk/ (5 files in 2 dirs): Updated nmg boolean functions using the classlist array. Changed the classlist from 'short' to 'char'. |
| 22:18.35 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 22:18.35 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 22:19.32 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 22:19.32 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 22:19.57 | CIA-117 | BRL-CAD: 03starseeker * r44638 10/brlcad/trunk/CMakeLists.txt: Maybe someday this will work, or I'll figure out why I'm doing it wrong - CMAKE_SYSTEM_IGNORE_PATH should be ideal for excluding the install dir from Find results, but it doesn't seem to. |
| 22:50.46 | starseeker | ``Erik: looks like we can use bu_avs_merge to duplicate an avs - just init a new one and then merge the old one into the new |
| 23:53.16 | *** join/#brlcad mafm (~mafm@180.Red-88-18-69.staticIP.rima-tde.net) | |
| 00:15.29 | *** join/#brlcad merzo (~merzo@4-36-94-178.pool.ukrtel.net) | |
| 00:23.02 | *** join/#brlcad crazy_imp (~mj@a89-183-11-209.net-htp.de) | |
| 00:44.54 | CIA-117 | BRL-CAD: 03starseeker * r44639 10/brlcad/trunk/ (11 files in 6 dirs): Take a stab at switching from bu_mro (??) to bu_attribute_value_set - this will need a lot more testing (certainly of nirt and raytracing) to make sure nothing got busted. |
| 01:21.12 | *** join/#brlcad silvap_ (~silvap@static-96-255-52-7.washdc.fios.verizon.net) | |
| 01:36.49 | *** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 02:45.05 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 03:19.55 | ``Erik | damnit, starseeker, I had 99% of it done... and the bu_avs_merge is NOT a map for what that function does |
| 03:20.59 | ``Erik | nirt has a particularly tricky usage that is not a trivial conversion, that's what I left off for tomorrow morning |
| 03:21.47 | ``Erik | thinks avs may need to be altered to accomodate the nirt usage |
| 03:25.37 | ``Erik | (I'd originally recoded using merge, then realized it was wrong, that's what slowed me down and kept me from committing before I left) |
| 05:16.21 | *** join/#brlcad waprat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 05:27.09 | *** join/#brlcad silvap (~silvap@static-96-255-52-7.washdc.fios.verizon.net) | |
| 06:34.51 | *** join/#brlcad Stattrav (~Stattrav@122.167.103.118) | |
| 06:34.51 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:02.44 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:50.08 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:22.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:52.09 | *** join/#brlcad mafm (~mafm@190.Red-88-23-77.staticIP.rima-tde.net) | |
| 10:17.56 | *** join/#brlcad mafm_ (~mafm@190.Red-88-23-77.staticIP.rima-tde.net) | |
| 10:22.31 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:41.11 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 10:51.24 | CIA-117 | BRL-CAD: 03erikgreenwald * r44640 10/brlcad/trunk/src/libbu/Makefile.am: reflect mro.c removal |
| 10:59.38 | starseeker | ``Erik: ah, my bad |
| 10:59.47 | starseeker | feel free to revert mine |
| 11:01.00 | starseeker | had the mistaken impression you were going to go ahead and commit your intermediate state, so I thought perhaps you hadn't had time to fool with it... |
| 11:02.13 | ``Erik | hm, I'd a half broken nirt |
| 11:02.27 | ``Erik | rt_load_attrs() is not used by our code, so the difference in functionality may be irrelevant |
| 11:02.44 | ``Erik | it was added in '01 by jra, same time as the mro stuff |
| 11:02.56 | ``Erik | the changes, other than that, were almost identical to mine |
| 11:03.41 | ``Erik | grepping the fickle user code now |
| 11:03.42 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 11:03.42 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:04.08 | starseeker | <snort> - maybe the "user code" is where rt_load_attrs and similar specialized functions should be living |
| 11:04.42 | ``Erik | not used in that code |
| 11:05.02 | starseeker | uh... then what the *bleep* is it doing in there? |
| 11:07.02 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 11:07.53 | CIA-117 | BRL-CAD: 03erikgreenwald * r44641 10/brlcad/trunk/ (doc/deprecation.txt include/raytrace.h): mark rt_load_attrs deprecated |
| 11:10.13 | CIA-117 | BRL-CAD: 03erikgreenwald * r44642 10/brlcad/trunk/src/nirt/if.c: remove unused variable |
| 11:13.19 | ``Erik | runs bench and regress |
| 11:15.46 | ``Erik | optimized on x86_64 osX.6 fails in metaball.c using cmake, the 'const point_t *' issue |
| 11:31.44 | ``Erik | 32b fbsd's solids regress has 0 off |
| 11:32.04 | ``Erik | I think the mged-regress on my mac is due to the system tcl and ogl, running a build-all |
| 11:40.41 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 12:04.02 | CIA-117 | BRL-CAD: 03erikgreenwald * r44643 10/brlcad/trunk/src/tab/Makefile.am: disable strict flags, some lexers mix signed/unsigned. |
| 12:17.19 | ``Erik | erm? 32b fbsd in Release has 3 off by many in solids |
| 12:24.42 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 12:24.43 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:40.48 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 12:50.19 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:13.08 | CIA-117 | BRL-CAD: 03bob1961 * r44644 10/brlcad/trunk/src/libdm/dm-ogl.c: Minor mod. |
| 13:19.04 | CIA-117 | BRL-CAD: 03bob1961 * r44645 10/brlcad/trunk/src/libdm/dm-wgl.c: Copy points/vectors to an array of GLdouble before sending to OpenGL. This seems to have remedied a bit of strange behavior seen only on windows (i.e. data arrows were sometimes being drawn incorrectly). |
| 13:48.27 | ``Erik | 7.18.4 has the same solids regression failure |
| 13:57.28 | starseeker | hmm. Check 7.16.8? |
| 14:03.53 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 14:52.41 | *** join/#brlcad Stattrav (~Stattrav@117.192.130.145) | |
| 14:52.41 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:19.38 | CIA-117 | BRL-CAD: 03erikgreenwald * r44646 10/brlcad/trunk/TODO: solids regression fails on optimized builds and goes back quite a ways (further than 7.16.8). Bump it to unscheduled and add notes. |
| 16:28.47 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:31.21 | CIA-117 | BRL-CAD: 03starseeker * r44647 10/brlcad/trunk/src/libged/attr.c: attr get and show should work in read-only databases - it's only when we actually try to change something that we need to care about read-only. |
| 17:37.30 | CIA-117 | BRL-CAD: 03starseeker * r44648 10/brlcad/trunk/src/librt/tree.c: |
| 17:37.30 | CIA-117 | BRL-CAD: Hrm. Don't want to do a straight-up copy if the tree avs - that's got NULLs, |
| 17:37.30 | CIA-117 | BRL-CAD: not actual values. Probably need to pull in the attributes from elsewhere, but |
| 17:37.30 | CIA-117 | BRL-CAD: this isn't quite right - it's looking at primitives and the attributes in |
| 17:37.30 | CIA-117 | BRL-CAD: question appear to be higher in the path. |
| 17:38.00 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.138.105) | |
| 18:12.49 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.105) | |
| 18:12.49 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:21.11 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.105) | |
| 18:21.11 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:31.59 | CIA-117 | BRL-CAD: 03starseeker * r44649 10/brlcad/trunk/src/librt/tree.c: Well... grab the attributes from the first region in the path and use them... does this get us what we need? |
| 18:39.26 | *** part/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 18:52.12 | CIA-117 | BRL-CAD: 03starseeker * r44650 10/brlcad/trunk/src/librt/ (db_tree.c tree.c): Try to make sure the comb data structure reflects the attributes. |
| 18:58.30 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 19:30.05 | *** part/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 21:36.52 | ``Erik | starseeker: that model is borked, the region has an attribute "region=0". I changed it to 1 and everything magically worked |
| 22:25.16 | starseeker | ``Erik: O.o |
| 22:25.34 | starseeker | soo.... none of my changes are needed then? |
| 23:08.05 | *** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) | |
| 23:42.36 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 00:23.14 | *** join/#brlcad crazy_imp (~mj@a89-182-17-206.net-htp.de) | |
| 07:38.05 | *** join/#brlcad Stattrav (~Stattrav@122.178.234.245) | |
| 07:38.05 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:11.24 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:53.29 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:30.06 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:50.02 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.147.51) | |
| 16:13.19 | *** join/#brlcad pawleeq_ (~pawleeq@212-96-188-229.cust.selfnet.cz) | |
| 16:13.31 | pawleeq_ | hello |
| 20:05.10 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 20:10.34 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:02.57 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 00:23.21 | *** join/#brlcad crazy_imp (~mj@a89-183-40-23.net-htp.de) | |
| 01:41.55 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) | |
| 06:07.56 | *** join/#brlcad Stattrav (~Stattrav@117.202.23.83) | |
| 06:07.57 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:35.38 | *** join/#brlcad Stattrav (~Stattrav@117.192.151.65) | |
| 07:35.38 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:38.46 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 14:54.00 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:18.36 | CIA-117 | BRL-CAD: 03Casinopaysafecard 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:Casino Paysafecard - How To PlayStealing Bundles Casino24.pdf]]" |
| 21:53.37 | starseeker | hmm: http://wiki.cs.purdue.edu/cgvlab/doku.php?id=projects:spatial_geometric_constraints |
| 21:55.02 | starseeker | http://www.cs.purdue.edu/homes/cmh/electrobook/intro.html |
| 21:58.18 | starseeker | ah, nuts - GPL http://www.cise.ufl.edu/research/constraints/GNU/FRONTIER-gnu/ |
| 22:07.04 | starseeker | makes a note to grab papers from here: http://www.cise.ufl.edu/~sitharam/pub.html |
| 00:23.32 | *** join/#brlcad crazy_imp (~mj@a89-183-26-57.net-htp.de) | |
| 06:14.47 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 06:30.41 | *** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) | |
| 06:30.48 | *** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) | |
| 11:10.11 | dloman | yawns |
| 11:10.27 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 11:14.40 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:28.09 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 11:28.09 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:01.54 | kunigami | hi, does anyone know a good reference on different shaders? or should I go for papers? |
| 12:13.03 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 12:13.03 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:40.04 | ``Erik | what kind of shaders? |
| 12:57.13 | CIA-117 | BRL-CAD: 03davidloman * r44651 10/geomcore/trunk/ (2 files in 2 dirs): Cleaned up console/debug printing calls. |
| 13:15.49 | kunigami | brlcad suggested me to implement a polka dot shader, but I'm not sure on how to do it. I was wondering if is there any kind of 'handbook of shaders' :) |
| 13:21.48 | CIA-117 | BRL-CAD: 03davidloman * r44652 10/geomcore/trunk/ (120 files in 35 dirs): More cleanup. Removed double newlines and dangling tabs/spaces. |
| 13:51.29 | ``Erik | nah, not really a handbook... src/liboptical/ is where they sit, all those sh_*.c files |
| 13:51.48 | ``Erik | sh_xxx.c is an empty 'skeletal' shader with lots of docs |
| 13:58.54 | kunigami | ``Erik: I was actually looking for the algorithm for implementing these shaders. |
| 14:12.30 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 14:31.27 | *** join/#brlcad Stattrav (~Stattrav@122.167.226.157) | |
| 14:31.27 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:44.28 | *** join/#brlcad Stattrav (~Stattrav@117.192.159.208) | |
| 15:44.30 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:54.41 | *** join/#brlcad willdye (~willdye@198.183.6.23) | |
| 15:54.58 | *** part/#brlcad willdye (~willdye@198.183.6.23) | |
| 16:03.36 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 17:02.51 | *** join/#brlcad willdye (~willdye@198.183.6.23) | |
| 17:04.28 | *** part/#brlcad willdye (~willdye@198.183.6.23) | |
| 17:31.23 | *** join/#brlcad Stattrav (~Stattrav@117.192.159.208) | |
| 17:31.23 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:43.13 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 17:43.51 | *** part/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 19:52.46 | CIA-117 | BRL-CAD: 03starseeker * r44653 10/brlcad/trunk/src/librt/tree.c: OK, .g file with bad attributes was causing problems - revert silly hunt for region in path. |
| 21:02.55 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 21:37.18 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 23:58.20 | CIA-117 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2886 10/wiki/User:Kunigami/GSoc2011/Proposal: |
| 00:23.41 | *** join/#brlcad crazy_imp (~mj@a89-182-239-11.net-htp.de) | |
| 01:11.53 | CIA-117 | BRL-CAD: 03davidloman * r44654 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/connector/: Slight reorg. Will ultimately separate out the classes that comprise the Java GSConnector and the Java GS Test Client |
| 01:14.05 | CIA-117 | BRL-CAD: 03davidloman * r44655 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSJavaInterface.java: Change default returns to Exception throws for now. |
| 06:31.24 | *** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 06:33.40 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 06:37.22 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 07:32.54 | *** join/#brlcad Stattrav (~Stattrav@122.167.103.233) | |
| 07:32.54 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:15.15 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) | |
| 09:16.24 | *** join/#brlcad PrezWhiteCalf (MK@whitecalf.net) | |
| 10:01.21 | *** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no) | |
| 13:04.14 | dloman | question: If i want a listing of a regions 'children' in the form of a list of strings, whats the best way? |
| 13:25.13 | ``Erik | in c/c++? shell? tcl? |
| 13:26.56 | dloman | c |
| 13:28.06 | dloman | im currently reading db_comb.c and the db_tree_flatten_describe() func |
| 13:29.14 | ``Erik | src/libged/ls.c might be worth perusing, as well |
| 13:29.31 | dloman | yeah, thats where i started =D |
| 13:29.42 | dloman | that and libged/list.c |
| 13:32.06 | ``Erik | db_lookup() (librt/db_lookup.c) seems pertinent |
| 14:07.19 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 14:43.19 | CIA-117 | BRL-CAD: 03starseeker * r44656 10/brlcad/trunk/src/ (fb/CMakeLists.txt util/CMakeLists.txt): Add LINKER_LANGUAGE specifications for fbthreadtest and pldebug (from Guilherme Kunigami) |
| 15:43.58 | CIA-117 | BRL-CAD: 03r_weiss * r44657 10/brlcad/trunk/src/librt/primitives/nmg/nmg_pt_fu.c: |
| 15:43.58 | CIA-117 | BRL-CAD: Updated functions 'compute_loop_class' and 'make_near_list' within file |
| 15:43.58 | CIA-117 | BRL-CAD: 'nmg_pt_fu.c'. Passed bn_tol into function 'make_near_list' to be used in a |
| 15:43.58 | CIA-117 | BRL-CAD: compare. This change reduces the number of 'dangling face' errors during nmg |
| 15:43.58 | CIA-117 | BRL-CAD: boolean operations such as when running the mged 'facetize' command. |
| 16:04.57 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 16:31.20 | *** join/#brlcad dli (~dli@67.55.12.157) | |
| 16:58.13 | dloman | ``Erik: you ever implement the 'GEOMETRYLISTREQ' net msg? |
| 17:01.23 | CIA-117 | BRL-CAD: 03davidloman * r44658 10/geomcore/trunk/ (3 files in 2 dirs): Implement a getListing() function that obscures the transition from FS to G from the caller. |
| 17:02.05 | ``Erik | a1no |
| 17:02.11 | dloman | aight |
| 17:22.18 | CIA-117 | BRL-CAD: 03davidloman * r44659 10/geomcore/trunk/ (6 files in 3 dirs): Add directory listing request and response to the gsnet protocol. |
| 17:23.13 | CIA-117 | BRL-CAD: 03davidloman * r44660 10/geomcore/trunk/tests/func/GE/GeometryEngineTest.cxx: Check in changes to sandbox test file. Nothing to see here. |
| 17:37.02 | CIA-117 | BRL-CAD: 03davidloman * r44661 10/geomcore/trunk/include/DirListResMsg.h: Fix the header define. Changed a Q to an S. |
| 17:38.18 | CIA-117 | BRL-CAD: 03davidloman * r44662 10/geomcore/trunk/ (3 files in 2 dirs): Make GeometryService objects able to respond to directory requests. Ensure NetMsgRouter registration for DirListReq and DirListRes msgs. |
| 17:39.26 | CIA-117 | BRL-CAD: 03davidloman * r44663 10/geomcore/trunk/src/GS/GSClient.cxx: Formatting. Tabs/indent/newlines. |
| 17:55.14 | CIA-117 | BRL-CAD: 03davidloman * r44664 10/geomcore/trunk/ (3 files in 3 dirs): The directory list response needs to carry the requested path back to the caller. |
| 18:00.37 | CIA-117 | BRL-CAD: 03davidloman * r44665 10/geomcore/trunk/ (3 files in 3 dirs): Implement a ListCmd for the test client. |
| 18:05.21 | CIA-117 | BRL-CAD: 03davidloman * r44666 10/geomcore/trunk/src/libNet/NetMsgFactory.cxx: Make the NetMsgFactory aware of DirListReQ and DirListReS |
| 18:33.55 | CIA-117 | BRL-CAD: 03davidloman * r44667 10/geomcore/trunk/src/libNet/netMsg/DirListResMsg.cxx: Fix msg type in constructor. ooops. |
| 18:35.10 | CIA-117 | BRL-CAD: 03davidloman * r44668 10/geomcore/trunk/src/libNet/netMsg/DirListResMsg.cxx: Remove debug terminal printing. |
| 18:36.23 | CIA-117 | BRL-CAD: 03davidloman * r44669 10/geomcore/trunk/src/GS/FileDataSource.cxx: SHould be feeding getFsDirList() the filesystem path, not the entire path. |
| 19:04.11 | kunigami | hi, I'm trying to implement a 'polka dot' shader. I've based myself on a renderman shader. The results are kinda weird: for a sphere: http://yfrog.com/5mpolkafailp ; cilinder seen from top: http://yfrog.com/njcilinderp ; goblet: http://yfrog.com/mxgobletp |
| 19:07.08 | starseeker | kunigami: that's with OSL? |
| 19:07.37 | kunigami | starseeker: no, I've implemented with BL-CAD |
| 19:08.09 | starseeker | ah, very good |
| 19:08.43 | starseeker | offhand, it looks like the dot spacing is running over some "edge" |
| 19:09.21 | starseeker | I confess I don't know much about the shader system - ``Erik, how does the mapping work for something like that? |
| 19:10.28 | ``Erik | um, kinda depends for different primitives, I think it's [0,1] xy, but certain shapes sometimes do funny things.. try checkerboard on a sphere to see some weirdness |
| 19:10.54 | ``Erik | or a cylinder, for that matter |
| 19:17.56 | starseeker | kunigami: quirks or not, it looks like you've got the idea pretty well - that's a shaded BRL-CAD raytrace |
| 19:18.24 | starseeker | now the next question - how to shade BRL-CAD results using OSL |
| 19:21.22 | starseeker | kunigami: iirc, you got a simple test raytracer working with OSL shading? |
| 19:21.44 | starseeker | (not with BRL-CAD geometry, obviously...) |
| 19:22.03 | kunigami | starseeker: yes! Some guy did that working for spheres based on smallpt |
| 19:22.37 | ``Erik | so now it's time to link the two together? |
| 19:23.36 | kunigami | cool! Well, my idea is to make OSL system do all the calculation and then return a 3-d float array. Is it better to do it through a special BRL-CAD shader acting as an interface or a independent tool? |
| 19:24.01 | starseeker | kunigami: I'd say probably as a special BRL-CAD shader, for the moment |
| 19:24.20 | ``Erik | I'd think the shading interface, like src/liboptical/sh_osl.c having osl_render() which calls into OSL, then packs the pixel with the results |
| 19:25.41 | CIA-117 | BRL-CAD: 03davidloman * r44670 10/geomcore/trunk/src/GS/cmds/ListCmd.cxx: Add some string filtering loops to pull out extraneous ./ ../ and // sequences. |
| 19:26.42 | kunigami | hmm ok! |
| 19:26.57 | CIA-117 | BRL-CAD: 03davidloman * r44671 10/geomcore/trunk/src/GS/FileDataSource.cxx: Use 'top' flag when listing the 'top' of a .g file. Also use db_close and free where appropriate to release resources. |
| 19:29.46 | CIA-117 | BRL-CAD: 03davidloman * r44672 10/geomcore/trunk/src/GS/DataManager.cxx: Make DataManager respond to Directory Listing request. Also check for error return values and send FailureMsgs when appropriate. |
| 19:32.13 | CIA-117 | BRL-CAD: 03davidloman * r44673 10/geomcore/trunk/src/GS/ (GSClient.cxx GSCmdLineClient.cxx): Add in handling of DirectoryList request and response messages into the test client. |
| 19:36.12 | kunigami | osl source code would have to be added on /src/other, right? |
| 19:36.45 | starseeker | kunigami: eventually, but don't worry about that for now |
| 19:37.02 | starseeker | that's quite a job, and not of immediate interest |
| 19:37.12 | starseeker | just go ahead and use your install of osl |
| 19:39.10 | kunigami | ok, great! |
| 20:01.12 | CIA-117 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2887 10/wiki/User:Kunigami/GSoc2011/Proposal: /* Timeline */ Updated accomplished tasks and changed the next ones. |
| 20:24.14 | CIA-117 | BRL-CAD: 03starseeker * r44674 10/brlcad/trunk/src/adrt/isst_tcltk.c: Use TIE_EXPORT instead of manually calling out the _declspec statements in the .c file (VS2010 Express doesn't seem to like that...) |
| 20:25.32 | CIA-117 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2888 10/wiki/User:Kunigami/GSoc2011/Reports: |
| 20:29.18 | ``Erik | heh, doh, was gonna commit a fix to issttcltk... I missed up and put #__declspec insead of __declspec :D |
| 20:31.33 | starseeker | ``Erik: er, whatever :-) |
| 20:31.35 | starseeker | can do that too |
| 22:05.55 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177879469.dsl.bell.ca) | |
| 22:58.00 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) | |
| 00:23.54 | *** join/#brlcad crazy_imp (~mj@a89-182-193-229.net-htp.de) | |
| 01:18.10 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 02:22.24 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 04:58.47 | *** join/#brlcad dli (~dli@dsl-69-172-110-67.acanac.net) | |
| 05:02.21 | *** join/#brlcad Stattrav (~Stattrav@122.167.103.233) | |
| 05:02.21 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:45.29 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 06:47.35 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:12.36 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 10:44.01 | dloman | yawns |
| 11:05.13 | CIA-117 | BRL-CAD: 03davidloman * r44675 10/geomcore/trunk/ (5 files in 2 dirs): Drop antiquated DbObject and DbObjectManifest classes. No longer useful |
| 11:06.42 | CIA-117 | BRL-CAD: 03davidloman * r44676 10/geomcore/trunk/ (include/BrlcadDb.h src/GS/BrlcadDb.cxx src/GS/CMakeLists.txt): Rough in skeleton for BrlcadDb class. Will contain all fns necessary for loading, reading, writing and saving a .g file. |
| 11:07.11 | dloman | nice! sf.net is fast this morning! |
| 11:08.30 | CIA-117 | BRL-CAD: 03davidloman * r44677 10/geomcore/trunk/src/GS/BrlcadDb.cxx: Oops. Make constructor implementation match declaration =D |
| 11:09.16 | CIA-117 | BRL-CAD: 03davidloman * r44678 10/geomcore/trunk/src/GS/DataManager.cxx: Make DataManager handle DirListReqMsg objects appropriately. |
| 11:26.59 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 12:27.08 | CIA-117 | BRL-CAD: 03davidloman * r44679 10/geomcore/trunk/ (include/StringUtils.h src/utility/StringUtils.cxx): Pull out commonly used, or otherwise generically useful functions into new StringUtils class. |
| 12:27.38 | CIA-117 | BRL-CAD: 03davidloman * r44680 10/geomcore/trunk/src/utility/CMakeLists.txt: Wire StringUtils into cmake |
| 12:28.20 | CIA-117 | BRL-CAD: 03davidloman * r44681 10/geomcore/trunk/ (include/FileDataSource.h src/GS/FileDataSource.cxx): Allow FileDataSource to take advantage of StringUtils class. Remove any duplicate functionality. |
| 13:12.21 | CIA-117 | BRL-CAD: 03davidloman * r44682 10/geomcore/trunk/ (include/StringUtils.h src/utility/StringUtils.cxx): Add getLastStepOfPath() to StringUtils. |
| 13:18.37 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 14:04.15 | CIA-117 | BRL-CAD: 03davidloman * r44683 10/geomcore/trunk/tests/func/utility/ (CMakeLists.txt StringUtilsTest.cxx): Implement a stringUtils functional test. |
| 15:23.50 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:33.36 | CIA-117 | BRL-CAD: 03davidloman * r44684 10/geomcore/trunk/tests/unit/utility/StringUtilsUTest.cxx: Implement some unit tests for StringUtils class |
| 17:46.35 | CIA-117 | BRL-CAD: 03davidloman * r44685 10/geomcore/trunk/ (include/StringUtils.h src/utility/StringUtils.cxx): Break out common functionality in path parsers. Structure function calls more logically. |
| 17:48.27 | *** join/#brlcad mafm (~mafm@34.Red-83-49-87.dynamicIP.rima-tde.net) | |
| 17:53.36 | *** join/#brlcad mafm_ (~mafm@161.Red-83-50-132.dynamicIP.rima-tde.net) | |
| 18:15.30 | CIA-117 | BRL-CAD: 03davidloman * r44686 10/geomcore/trunk/ (2 files in 2 dirs): getLastStepOfPath was failing in certain cases. Created unit tests and fixed bugs. |
| 18:18.09 | CIA-117 | BRL-CAD: 03davidloman * r44687 10/geomcore/trunk/ (include/BrlcadDb.h src/GS/BrlcadDb.cxx): Flesh out BrlcadDB implementation a bit by adding isValidPath() and list() along with other support functions like open() close() etc... |
| 18:18.53 | CIA-117 | BRL-CAD: 03davidloman * r44688 10/geomcore/trunk/include/FileDataSource.h: Documentation and formatting.... |
| 18:20.18 | CIA-117 | BRL-CAD: 03davidloman * r44689 10/geomcore/trunk/src/GS/FileDataSource.cxx: Make FileDataSource use the BrlcadDb class. Remove duplicate code. |
| 18:39.00 | CIA-117 | BRL-CAD: 03davidloman * r44690 10/geomcore/trunk/src/GS/BrlcadDb.cxx: Check for solids. Solids don't have children! |
| 19:01.45 | *** join/#brlcad Stattrav (~Stattrav@117.192.155.188) | |
| 19:01.46 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:02.27 | CIA-117 | BRL-CAD: 03starseeker * r44691 10/brlcad/trunk/src/tclscripts/rtwizard/rtwizard.tcl: Make rtwizard's dirname line match archer's... |
| 19:13.37 | CIA-117 | BRL-CAD: 03davidloman * r44692 10/geomcore/trunk/ (3 files in 2 dirs): Implement a simple oop wrapper around the bu_external struct |
| 19:25.40 | kunigami_ | Hi, I have a newbie question: If I'm to include some library's headers and these header's depend on other headers, do I need to include both? |
| 19:27.42 | CIA-117 | BRL-CAD: 03davidloman * r44693 10/geomcore/trunk/src/GS/ExtObject.cxx: free bu_external* on ~ExtObject |
| 19:34.17 | CIA-117 | BRL-CAD: 03davidloman * r44694 10/geomcore/trunk/ (include/BrlcadDb.h src/GS/BrlcadDb.cxx): Implement contains() and getExtObj(). |
| 19:40.59 | kunigami_ | for example, I'm using a OSL header: oslexec.h. So I added OSL/include/ with include_directories(). but now, I get compile error from dependencies of oslexec.h such as openEXR |
| 19:54.04 | CIA-117 | BRL-CAD: 03davidloman * r44695 10/geomcore/trunk/ (include/BrlcadDb.h src/GS/BrlcadDb.cxx): Implement a bulk getter: getExtObjects(...). works on a list of names and provides a list of ExtObject objects. |
| 19:56.58 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601324.dsl.bell.ca) | |
| 20:32.49 | *** join/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 20:34.56 | *** part/#brlcad willdye (~willdye@fern.dsndata.com) | |
| 20:49.21 | *** join/#brlcad mafm (~mafm@161.Red-83-50-132.dynamicIP.rima-tde.net) | |
| 21:11.05 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 23:23.34 | starseeker | kunigami_: It depends on the headers, but if oslexec.h is pulling other .h files, you do need to include the directories that will let the compiler find them |
| 23:24.29 | starseeker | kunigami_: what's the error specifically? (I'd suggest using http://pastebin.mozilla.org/) |
| 23:29.46 | kunigami_ | I'm trying to compile the osl-raytracer out of the osl-system. But OSL depends on other libraries, so I was getting dependence errors. Now, I've included all these dependences on the cmake file, but I'm still getting some compile errors. I'll double-check my CMakeLists to see if I'm not doing anything silly :) BRB |
| 23:32.57 | ``Erik | I find that when I'm doing something silly, if often becomes obvious as I'm in the process of sharing to get help... I'm probably the meanest one around and I don't make fun of people or think less if they make mistakes (though I might rib on the ones who should know better, but it's in jest) |
| 23:33.15 | ``Erik | and with that, I'm out for the night, hasta la pasta, mi amiga2000's |
| 00:24.17 | *** join/#brlcad crazy_imp (~mj@a89-182-248-36.net-htp.de) | |
| 00:30.16 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601324.dsl.bell.ca) | |
| 00:31.22 | IriX64 | http://pastebin.com/u/IriX64 |
| 00:31.34 | IriX64 | trying to install 7.18.5 |
| 00:48.56 | kunigami_ | Well, I have no idea on how to resolve this error: http://pastebin.mozilla.org/1234805 |
| 00:49.19 | kunigami_ | It's difficult to tell what I'm trying to compile tough |
| 00:50.00 | kunigami_ | Here's the cmake file I'm using: http://pastebin.mozilla.org/1234806 |
| 00:52.22 | kunigami_ | A weird thing is that the raytracer depends on a file named oslexec_pvt.h, which is only available in the osl source, not in the generated lib (that is, on dist/include) |
| 00:53.39 | starseeker | kunigami_: have you tried sticking that file in the include dir? |
| 00:54.46 | kunigami_ | I added its directory with: include_directories(/Users/kunigami/dev/osl/src/liboslexec/) |
| 00:55.32 | starseeker | kunigami_: grep in your build directory for osl and see which binary files match RendererServices |
| 00:56.32 | starseeker | my first guess is that you need to link in some other OSL library |
| 00:59.40 | kunigami_ | grep says that simplerend.o and testrender.o matches |
| 01:00.42 | starseeker | nothing else? |
| 01:00.58 | starseeker | where is RendererServices defined? |
| 01:01.58 | kunigami_ | hmm this is the testrender build. In the osl build there are a bunch of files that maches. The only library is liboslexec |
| 01:02.11 | kunigami_ | ls |
| 01:02.14 | kunigami_ | oops |
| 01:02.48 | starseeker | try make VERBOSE=1 - does it definitely show the oslexec library being linked in? |
| 01:04.18 | starseeker | must head out - kunigami_, how did you build the original test program? I'd look at what you did there vs. what's going on here, if that succeeded... |
| 01:04.46 | kunigami_ | I think so. The last executed command is? /usr/bin/c++ -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/testrender.dir/testrender.o CMakeFiles/testrender.dir/simplerend.o CMakeFiles/testrender.dir/sphere.o -o testrender /Users/kunigami/dev/osl/dist/macosx/lib/liboslexec.dylib /Users/kunigami/dev/osl/dist/macosx/lib/liboslcomp.dylib /Users/kunigami/dev/oiio/dist/macosx/lib/libOpenImageIO.dylib /opt/local/lib/libboost_filesystem-mt |
| 01:04.47 | kunigami_ | /opt/local/lib/libboost_regex-mt.dylib /opt/local/lib/libboost_system-mt.dylib /opt/local/lib/libboost_thread-mt.dylib |
| 01:05.12 | kunigami_ | There's a /Users/member:kunigami/dev/osl/dist/macosx/lib/liboslexec.dylib there |
| 01:07.29 | kunigami_ | I built the original system with almost the same configuration of cmake. The difference was that testrender was under osl sources: /osl/src/testrender |
| 01:10.36 | kunigami_ | also, when linking libraries: oslexec, oslcomp and oslquery, CMakeLists does: TARGET_LINK_LIBRARIES ( testrender oslexec oslcomp oslquery) because these libraries are being generated too (I'm not sure if I was clear) |
| 01:25.28 | kunigami_ | Well, I'll take a break now. Tomorrow I'm back! |
| 02:28.10 | *** join/#brlcad CIA-56 (cia@cia.atheme.org) | |
| 04:45.04 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 06:09.15 | *** join/#brlcad CIA-61 (cia@cia.atheme.org) | |
| 06:15.14 | *** join/#brlcad Stattrav (~Stattrav@122.167.103.233) | |
| 06:15.14 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:21.22 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 06:21.23 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:27.51 | *** join/#brlcad crazy_imp (~mj@a89-182-248-36.net-htp.de) | |
| 06:34.11 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 06:35.34 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:22.08 | *** join/#brlcad mafm (~mafm@30.Red-83-45-252.dynamicIP.rima-tde.net) | |
| 11:29.38 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 11:39.40 | CIA-61 | BRL-CAD: 03erikgreenwald * r44696 10/brlcad/trunk/src/proc-db/ (CMakeLists.txt Makefile.am ringworld.c): Stub Niven's "ringworld" structure as a proc-db. It'd be an awesome stress test. |
| 11:43.37 | dloman | hahahahahaha awesome :) |
| 11:44.29 | ``Erik | :D a few details at http://en.wikipedia.org/wiki/Ringworld |
| 11:44.58 | ``Erik | 1.6m km wide, 1au radius |
| 11:45.33 | ``Erik | woops, oh, yeah, 1.6m km wide, 1.6k km tal |
| 11:46.08 | ``Erik | could whack it with rtweight and come up with a rough density, too |
| 11:46.15 | dloman | so, whats the Material Code for scrith ? =D |
| 11:46.40 | ``Erik | 42. :D |
| 11:48.36 | ``Erik | huh, took him 10 years to write the sequel (ringworld engineers) to address the complaints about gaps |
| 11:48.50 | ``Erik | http://en.wikipedia.org/wiki/The_Ringworld_Engineers |
| 11:49.08 | ``Erik | Secondly, many fans had identified numerous engineering problems in the Ringworld as described in the novel. |
| 11:49.36 | ``Erik | Niven says that one reason he wrote The Ringworld Engineers was to address these engineering problems. |
| 11:49.55 | ``Erik | aaanyways, fun set of books :) I haven't picked up the latest one yet (2004) |
| 11:51.14 | ``Erik | was thinking of coming up with the set of parms for the proc-db first, so'z it could do everything from a halo to a ringworld, with enough data to generate a newtonian model |
| 11:52.50 | ``Erik | then an anchored fractal to generate the 'tiles' |
| 11:55.07 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 12:06.01 | dloman | that would be a fun project :) |
| 12:08.05 | dloman | and, to be honest... the hardest part would be the terrain generation |
| 12:22.32 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 12:22.32 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:35.39 | *** join/#brlcad kunigami1 (~kunigami@loco-gw.ic.unicamp.br) | |
| 12:40.56 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:42.01 | ``Erik | terrain generation how? it's a pretty basic fractal exercise... done it before, will do it again |
| 12:42.50 | ``Erik | often, it's just taking a square, finding the center point, putting a random value there based on the neighbors, recurse... quadtree fractal pattern |
| 12:54.53 | dloman | right on. |
| 12:54.58 | dloman | i ment relative difficulty |
| 12:55.30 | dloman | the ring structure (aka a circular 'trench') is all of about 3 cyls :) |
| 12:56.01 | dloman | ring.r = u s1.s - s2.s - s3.s |
| 12:56.03 | dloman | done |
| 12:56.22 | dloman | so the fractal terrain gen is much more 'difficult' than that :) |
| 13:00.55 | ``Erik | for a really basic one, yes... but we might need to go with DSPs to get the surface |
| 14:33.57 | dloman | so it turns out that a sphere with a radius of 699500 km doesn't raytrace correctly :) (at least on my box) |
| 15:13.40 | CIA-61 | BRL-CAD: 03erikgreenwald * r44697 10/brlcad/trunk/src/proc-db/ringworld.c: remove 'count' check, since that doesn't exist. |
| 15:13.55 | dloman | lol, i just oened that file to fix that :) nice |
| 15:21.26 | *** join/#brlcad mafm (~mafm@30.Red-83-45-252.dynamicIP.rima-tde.net) | |
| 15:53.49 | *** join/#brlcad WhiteCalf (MK@whitecalf.net) | |
| 17:00.38 | *** join/#brlcad Stattrav (~Stattrav@117.192.153.125) | |
| 17:00.38 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:25.15 | *** join/#brlcad dtidrow (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) | |
| 18:04.44 | CIA-61 | BRL-CAD: 03erikgreenwald * r44698 10/brlcad/trunk/include/config_win_cmake.h: remove duplicate WITH_TK definition |
| 18:05.32 | CIA-61 | BRL-CAD: 03starseeker * r44699 10/brlcad/trunk/src/librt/CMakeLists.txt: Use the same trick for librt as librt-static - Wno-error due to Mac OSX warning |
| 18:07.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:12.01 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 19:31.41 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 19:33.31 | *** join/#brlcad crazy_imp (~mj@a89-182-248-36.net-htp.de) | |
| 19:40.44 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 19:41.20 | *** join/#brlcad Stattrav (~Stattrav@117.192.153.125) | |
| 19:41.20 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:15.18 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 20:38.12 | CIA-61 | BRL-CAD: 03bob1961 * r44700 10/brlcad/trunk/src/other/iwidgets/generic/ (4 files): Temporarily deleted a few troublesome options that currently break things like iwidgets::fileselectionbox and rtwizard. Need to find out what's really going on here. |
| 21:14.20 | *** join/#brlcad merzo (~merzo@165-62-94-178.pool.ukrtel.net) | |
| 00:23.56 | *** join/#brlcad crazy_imp (~mj@a89-182-143-78.net-htp.de) | |
| 02:34.35 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 03:35.57 | *** join/#brlcad merzo (~merzo@1-45-132-95.pool.ukrtel.net) | |
| 04:22.07 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 06:52.54 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:06.05 | *** join/#brlcad Stattrav (~Stattrav@122.167.103.233) | |
| 07:06.05 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:23.35 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 07:25.32 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 07:25.33 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:42.35 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1128565552.dsl.bell.ca) | |
| 08:53.14 | *** join/#brlcad mafm (~mafm@62.Red-81-34-125.dynamicIP.rima-tde.net) | |
| 09:37.01 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 11:04.20 | *** join/#brlcad mafm (~mafm@62.Red-81-34-125.dynamicIP.rima-tde.net) | |
| 11:16.16 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 11:50.50 | *** join/#brlcad Stattrav (~Stattrav@122.167.103.233) | |
| 11:50.51 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:53.03 | dloman | so ``Erik, i did some data szie calcs in my head yesterday..... might have a memory issue :) |
| 12:53.08 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:54.04 | dloman | 1.6x10^6 pix x 1.6x10^6 pix image is about 2.56 x 10^12 pixels... and at 1 byte per pixel... yeah, thats a bit large :) |
| 13:10.56 | ``Erik | 1552000000000000000000 square meters. |
| 13:12.35 | dloman | m or km ? |
| 13:12.48 | dloman | i though we were saying 1 pix == 1 km |
| 13:13.08 | ``Erik | meters |
| 13:13.16 | ``Erik | um, at 1km res, 1.5 petabytes |
| 13:14.08 | ``Erik | even when ya think you grok the scale of that puppy, it's still ungrokkable |
| 13:18.55 | ``Erik | hm, 606x^2 widths of area |
| 13:19.59 | ``Erik | 1284.5 km pixels will produce 1g of surface 8b elevetion data |
| 13:20.18 | ``Erik | or wait, no, my math is wrong |
| 13:20.51 | ``Erik | 1245.6 km edges will produce 1g |
| 13:22.20 | ``Erik | sooooo, the US would be ~6 pixels at that resolution |
| 13:22.44 | dloman | lol |
| 13:22.53 | dloman | question, since i know nothing of the process: |
| 13:23.27 | dloman | when brlcad 'preps' geometry... is that a good place to put in a LoD Proc Gen function(s) ? |
| 13:24.01 | ``Erik | no, LoD requires some understanding of the viewpoints location, and prep doesn't know anything about that |
| 13:24.17 | ``Erik | we cannot do LoD with the raytracing data as it stands |
| 13:24.33 | dloman | hrm, so does the geometry have *any* idea where the viewport is at anytime? |
| 13:24.59 | ``Erik | the geometry does not, the app is responsible for setting ray start points |
| 13:25.57 | ``Erik | hm |
| 13:26.12 | ``Erik | mebbe a fractal procedural displacement shader might work |
| 13:26.35 | starseeker | one of the things we need to do longer term is have the primitives provide the ability to take a view/geometry size and return an appropriate wireframe |
| 13:26.58 | dloman | so whats the order of operations then? |
| 13:27.23 | dloman | call 'rt', prep geometry, then start firing rays? |
| 13:27.30 | ``Erik | yup |
| 13:27.45 | ``Erik | all prep is completed before the first ray is shot |
| 13:27.56 | starseeker | has been tempted to start that level of re-org once or twice, but it's deeply invasive and probably a fair bit of work |
| 13:28.01 | dloman | aka, if the geometry is prepped *after* the call is made to rt, then the viewport data should be 'somewhere' that a function could get at. |
| 13:29.15 | ``Erik | starseeker: I'm setting up a git repo using the svn bridge on my desk fbsd box, um, /usr/tmp/brlcad.git I think? if you want to clone it for playground activities |
| 13:29.21 | dloman | course, this is 'logic' speaking and that may need not apply :) |
| 13:30.18 | ``Erik | sets is schedule to involve; finding pants. getting coffee. cleaning house on his day off here O.o wee. |
| 13:30.40 | dloman | oh you taking a 4 day then? |
| 13:30.46 | ``Erik | yup |
| 13:30.56 | ``Erik | CN today |
| 13:32.26 | dloman | starseeker: you taking a 4 day weekend also? |
| 13:39.06 | starseeker | no, i'll be in |
| 13:52.14 | dloman | Well that's a great way to kick off the weekend. my bank called. Accounts been comprimized :/ |
| 13:56.45 | ``Erik | ow, an actual compromise? not a false positive? |
| 13:57.29 | dloman | they shut down all my cards :) I have all my money. So whether it was a true compirmise or not, i really don't care :/ |
| 13:57.51 | dloman | However, now i have to jump thru a ton of hoops to get my accounts back up |
| 13:58.03 | dloman | kinda annoyed atm :) |
| 14:03.13 | ``Erik | better'n bein' empty handed, ah surpose |
| 14:03.21 | dloman | true that |
| 14:03.33 | ``Erik | cranks up poplamoose while cleaning O.o |
| 14:03.37 | dloman | pretty much why im not beating down the door of the base Bank of America |
| 14:03.40 | ``Erik | pomplamoose, even |
| 14:04.19 | ``Erik | (if'n ya don't know them, check them out on the youtubez, 'beat it' 'put a ring on it' 'nature boy'... awesome covers) |
| 14:05.49 | dloman | oh god, they did a christmas commercial this last year...... |
| 14:06.16 | dloman | they annoyed the hell out of me, lol |
| 14:07.06 | ``Erik | the hyundai one, yeah.. but they really don't suck, that was just a corporate obnoxiousness |
| 14:07.10 | dloman | seems it was the editing on the commercial, these arent that bad :) |
| 14:07.27 | ``Erik | their version of nature boy is effin' awesome |
| 14:07.32 | dloman | heh, is that a moog? |
| 14:37.21 | CIA-61 | BRL-CAD: 03davidloman * r44701 10/geomcore/trunk/ (include/BrlcadDb.h src/GS/BrlcadDb.cxx): Verbage change from 'path' to 'gPath' for clarity. |
| 14:45.58 | CIA-61 | BRL-CAD: 03davidloman * r44702 10/geomcore/trunk/src/GS/BrlcadDb.cxx: Was mistakenly using StringUtils::getLastStepOfPath() as a .g file path validation check. Fixt. Now correctly using BrlcadDb::_isValidPath() call. |
| 14:49.56 | CIA-61 | BRL-CAD: 03davidloman * r44703 10/geomcore/trunk/include/BrlcadDb.h: "//TODO Move these to a more common place?" added in reference to common return values dealing with errors for BrlcadDb function calls. |
| 15:47.12 | CIA-61 | BRL-CAD: 03davidloman * r44704 10/geomcore/trunk/include/BrlcadDb.h: Add some notes about ByteBuffer::wrap() failure handling. |
| 15:49.18 | CIA-61 | BRL-CAD: 03davidloman * r44705 10/geomcore/trunk/ (include/ExtObject.h src/GS/ExtObject.cxx): Add in a serialize method to ExtObject that creates a ByteBuffer and passed back a pointer to it. This allows the ByteBuffer to be exactly the size required. |
| 18:12.09 | *** join/#brlcad Stattrav (~Stattrav@117.202.25.117) | |
| 18:12.09 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:17.52 | *** join/#brlcad Stattrav (~Stattrav@117.202.25.117) | |
| 19:17.52 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:32.19 | CIA-61 | BRL-CAD: 03r_weiss * r44706 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: |
| 20:32.19 | CIA-61 | BRL-CAD: Corrected logic in functions 'nmg_booltree_evaluate' and 'nmg_boolean' within |
| 20:32.19 | CIA-61 | BRL-CAD: file 'nmg_bool.c'. This fix stops the error 'nmg_boolean() result of |
| 20:32.19 | CIA-61 | BRL-CAD: nmg_booltree_evaluate() isn't tp' which occurs occasionally when performing nmg |
| 20:32.19 | CIA-61 | BRL-CAD: boolean operations such as when using the mged 'facetize' command. This change |
| 20:32.19 | CIA-61 | BRL-CAD: also allows boolean operations to return a null result without failing. |
| 20:44.04 | *** join/#brlcad Stattrav (~Stattrav@117.202.25.117) | |
| 20:44.04 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:17.17 | *** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ) | |
| 21:18.06 | starseeker | dloman: ouch, sorry to hear that about your accounts! |
| 21:18.23 | starseeker | ``Erik: just curious, do you know anything about Lua (scripting language?) |
| 21:26.33 | ``Erik | unfortunately |
| 21:26.47 | ``Erik | it's an ugly language, but it's simple and very embedable |
| 21:27.38 | ``Erik | you can use luac to generate luab files, compiled things... um, I heard lua 5 was supposed to fix a lot of stuff, I mostly dealt with lua 4 a llllong time ago, doing a platformer video game |
| 21:34.05 | starseeker | hmm... how's it compare to Tcl? |
| 21:34.21 | starseeker | notes 5 has been out for quite a while... |
| 21:35.50 | ``Erik | my info is outdated, at the time... tcl was worse to integrate and slower, but tcl felt "lisper" |
| 21:36.09 | ``Erik | lua reminded me of basic |
| 21:36.15 | starseeker | winces |
| 21:36.41 | starseeker | darn... the "easier to integrate" bit really appeals... |
| 21:36.53 | ``Erik | it's a tiny language, easy to integrate... compile yourself up a version and experiment |
| 21:37.18 | starseeker | was looking over the Tcl build logic again and having bad things happen to his blood pressure... |
| 21:37.56 | starseeker | has evil thought... stick a Tcl parser on top of Lua :-P |
| 21:38.05 | ``Erik | tcl is stuck in the 80's, lua is designed for src/other/ type stuff... but the language panders to javascript/java/c++/perl programmers |
| 21:39.52 | starseeker | hmm... wonder if I can re-create the "mged command prompt" type environment |
| 21:39.54 | ``Erik | give it a shot, it's an easy one to learn... *shrug* all I can give is my opinion, and opinions are like a**holes :) |
| 21:40.11 | starseeker | wouldn't have Tcl under the hood though, so I suppose it's a guaranteed fail for acceptance |
| 21:41.02 | ``Erik | my vote is for removing tcl from teh core and providing a more abstracted interface so we can use python, ruby, cl, scheme, lua, ... perl... whatever anyone wants |
| 21:41.48 | ``Erik | C is lingua franca, so that should be our exposed interface |
| 21:42.30 | starseeker | would looove to find a way to get Tcl/Tk out of src/other altogether |
| 21:43.38 | ``Erik | that'd be interesting, I'm more concerned with doing "make librt" with no tcl having to be involved |
| 21:44.09 | starseeker | heh, CMake perspective talking for me I guess - making sure Tcl/Tk builds integrated and everywhere is like hauling around a 50 pound anchor |
| 21:44.56 | ``Erik | you're the one who decided to start not liking automake and push the cmake migration... you did it to yourself :D |
| 21:45.28 | ``Erik | so release today is not happening? |
| 21:46.19 | ``Erik | http://www.youtube.com/watch?v=LNpwBpZUrzk <-- all sorts of awesome |
| 21:46.49 | starseeker | ``Erik: well, having autotools and Windows builds separate is another and worse sort of boat anchor |
| 21:47.12 | ``Erik | yes, windows is a definite ... issue |
| 21:47.17 | starseeker | ``Erik: unfortunately, probably not today |
| 21:47.46 | starseeker | that little change of Bob's got rtwizard up, but means we need another round of testing |
| 21:47.52 | ``Erik | if you can get a build on thor, awesome... if not, well, it's a .0 and we expect pain in the transfer |
| 21:48.09 | starseeker | plus I suppose I should really figure out why rtedge isn't displaying in the rtwizard framebuffer... |
| 21:48.41 | starseeker | oh, and I didn't START not liking autotools - I NEVER liked it :-P |
| 21:48.47 | ``Erik | part of me wants to say "just throw it out" and take out lumps, and .2 will be a big cleanup release |
| 21:48.56 | ``Erik | s/out/our/ |
| 21:49.08 | starseeker | ``Erik: <shrug> we can do that |
| 21:49.28 | starseeker | ``Erik: you can do the release too you know - I don't have some "magic key" |
| 21:49.45 | ``Erik | I'm taking the day off, I'm not allowed to do work :D |
| 21:49.50 | starseeker | heh - cop-out |
| 21:50.17 | ``Erik | indeed. I'll go back to scrubbing toilets and floors now. :/ |
| 21:51.04 | ``Erik | (almost tagged yesterday, btw... seriously, fuggit, it'll suck and we'll get "it don't work", but ...) |
| 21:51.28 | starseeker | yeah, I know |
| 21:51.33 | starseeker | updates... |
| 21:53.27 | ``Erik | 7.20.2 will see the fixing of the osX ogl bug, the 32b tie bug, ... but 7.20.0 will not. |
| 21:53.54 | starseeker | ``Erik: if we're going to do it - anything we should toss in the deprecation list now? |
| 21:54.03 | starseeker | (i.e. we want to get rid of this ASAP?) |
| 21:54.04 | ``Erik | and the 7.20.0 winderz binary will be huge for the community, I think... 99% instead of 25% of the tools |
| 21:54.36 | ``Erik | um, mro and the libtie change is all I can think of |
| 21:55.12 | starseeker | heh - mro is kinda "whoops, it's gone now" instead of "deprecated, will go away eventually" |
| 21:55.12 | ``Erik | maybe a statement about the altered attribute handling? |
| 21:56.07 | ``Erik | "deprecated 7.20.0, deleted 7.20.0. Sucks to be you." |
| 21:56.37 | ``Erik | it's a minor bump, we're allowed to be a bit mean |
| 21:57.36 | starseeker | yeah, I guess we'll go with condition c |
| 21:57.46 | ``Erik | btw, I started a cmake migration of the project who would lament the mro removal... it's making me nervous |
| 21:58.55 | ``Erik | can trunk succeed at a distcheck? I tried to keep my modifications synced between cmake and automake, but ... |
| 21:59.33 | ``Erik | if automake can do a distcheck, benchmark and regress, I say tag and go |
| 21:59.39 | starseeker | nods |
| 21:59.47 | starseeker | I'm trying an automake distcheck now |
| 22:00.40 | ``Erik | seriously, crank http://www.youtube.com/watch?v=LNpwBpZUrzk up, get the sub going, tell bob it's for his own good |
| 22:00.57 | starseeker | heh |
| 22:01.04 | starseeker | he's not in, actually |
| 22:01.16 | ``Erik | PLAY IT |
| 22:02.28 | starseeker | is |
| 22:02.52 | ``Erik | since you're doing the gruntwork of releasing today, and it's a monster change, um, I will do a fbsd port cook on tuesday, and thinking this will be a very short run release |
| 22:03.10 | ``Erik | we might target 7.20.2 for, uh, 2 weeks from now? |
| 22:03.23 | starseeker | nods |
| 22:03.40 | starseeker | um... PomplamooseMusic |
| 22:03.43 | starseeker | ? |
| 22:03.45 | ``Erik | yes |
| 22:04.11 | ``Erik | pomplamoose is a duo band out of nyc, their cover of nat king coles nature boy is ... awesome |
| 22:04.33 | starseeker | they seem to bet getting a lot of attention |
| 22:04.36 | starseeker | do you know them? |
| 22:04.39 | ``Erik | I've been a fan of the for a few years, last winter they had a contract deal with hyundai on a commercial |
| 22:05.15 | starseeker | cool |
| 22:05.45 | ``Erik | I like to pretend that I find awesome bands before they become popular, I'm very "scene" like that |
| 22:06.02 | starseeker | nods - it does happen, once in a while |
| 22:06.35 | ``Erik | I think there're 4 that I've told people about that have gone on to commercials or some kinda recognition when I pointed to them as subs |
| 22:07.02 | ``Erik | goldfrapp, 2 weeks after I messaged every I knew about them, they showed up in a commercial |
| 22:07.10 | CIA-61 | BRL-CAD: 03starseeker * r44707 10/brlcad/trunk/doc/deprecation.txt: Abrupt, but close to minimal and what appears to be the least painful way forward - mro is going, all hail bu_attribute_value_set. |
| 22:07.20 | starseeker | awesome |
| 22:07.26 | ``Erik | (they probably shot the commercial before I heard them, but *shrug*) |
| 22:07.48 | starseeker | awaits the thunderbolt from brlcad... |
| 22:08.37 | ``Erik | the boy has a mini-me. the thunderbolt is 3 months out at the soonest |
| 22:09.12 | ``Erik | and this is explicitely permitted in the rules set down |
| 22:09.35 | starseeker | hehe |
| 22:09.57 | starseeker | well, for loose definitions of minimal |
| 22:10.01 | starseeker | close though |
| 22:10.08 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 22:10.16 | starseeker | and I still think it's the least painful approach |
| 22:10.37 | ``Erik | the, uh, favor you volunteered for, I started on it, it's gonna be rough... they have a very intertwined dep chain with lots of #include action |
| 22:12.02 | ``Erik | #include <Ap.h> instead of #include |
| 22:12.09 | ``Erik | #include "Ap/Ap.h" |
| 22:12.19 | starseeker | winces |
| 22:12.21 | ``Erik | so a lot of -I action |
| 22:12.36 | starseeker | I suppose untangling it isn't an option |
| 22:12.39 | ``Erik | or C changes... |
| 22:13.17 | ``Erik | if you can convince geoff... |
| 22:13.26 | starseeker | uh... yeah |
| 22:13.42 | starseeker | -I it is |
| 22:13.51 | starseeker | initially at least |
| 22:14.02 | ``Erik | frankly, I started my 'acst' branch to superseed both teams |
| 22:14.23 | ``Erik | unfortunately, we lack a dietz |
| 22:14.43 | ``Erik | "nothing succeeds like success", my gut feeling is that success will be punished |
| 22:15.17 | starseeker | well, all we can do is try |
| 22:17.00 | CIA-61 | BRL-CAD: 03starseeker * r44708 10/brlcad/trunk/ (README include/conf/MINOR include/conf/PATCH): Here we got - bump the version numbers. |
| 22:19.03 | CIA-61 | BRL-CAD: 03starseeker * r44709 10/brlcad/trunk/ChangeLog: Update ChangeLog |
| 22:21.02 | ``Erik | w00t |
| 22:29.35 | CIA-61 | BRL-CAD: 03starseeker * r44710 10/brlcad/branches/STABLE/ (427 files in 165 dirs): Merge trunk r44709 to STABLE |
| 22:30.11 | *** join/#brlcad Yoshi477 (~jan@d72-39-60-53.home1.cgocable.net) | |
| 22:34.11 | starseeker | notes he somehow missed that the byacc maintainer also maintains a version of flex |
| 22:35.23 | starseeker | hmm... |
| 22:59.31 | starseeker | hmm, cool http://tdb.samba.org/ |
| 23:00.34 | CIA-61 | BRL-CAD: 03starseeker * r44711 10/brlcad/tags/rel-7-20-0/: Tag 7.20.0 |
| 23:00.53 | starseeker | ``Erik: there ya go |
| 23:01.36 | starseeker | ahhh, crud - forgot to update the date of release |
| 23:02.16 | CIA-61 | BRL-CAD: 03starseeker * r44712 10/brlcad/trunk/NEWS: Ah, nuts - forgot to fix the date. |
| 23:05.06 | CIA-61 | BRL-CAD: 03starseeker * r44713 10/brlcad/trunk/ (NEWS README include/conf/PATCH): Bump numbers. |
| 23:05.24 | starseeker | needs to get outta here... |
| 00:22.53 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 00:29.34 | *** join/#brlcad crazy_imp (~mj@a89-182-152-210.net-htp.de) | |
| 07:46.39 | CIA-61 | BRL-CAD: 03Seo1 07http://brlcad.org * r2889 10/wiki/Seo_service_-_For_starters: New page: For starters, there are a lot of great '''[http://lease-a-seo.com SEO services]''' provided by capable Warriors for hire in the Warriorforum that offer honest services. However, there are ... |
| 11:06.32 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:54.05 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 12:02.01 | *** join/#brlcad dli (~dli@dsl-69-172-110-67.acanac.net) | |
| 13:09.12 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 13:26.48 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 13:36.14 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:49.20 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 13:58.35 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 14:11.07 | epileg | starseeker: I see that yesterday You updated the STABLE branch with v7.20.0 but there isn't a new source talball file for download |
| 14:12.13 | epileg | can I upload new deb/rpm packages based on STABLE branch? |
| 14:17.45 | ``Erik | probably, but the official tarball should be up very soon, tuesday at the latest. If you want source builds to match the md5/sha1, might be worth holding off an actual change in the package mgmt upstream. This one might take a little more work, though, we've switched to cmake... it might be a good idea to make a tar from stable and try to update the spec/deb files to accomodate that, then tweak a little once the 'official' source is upload |
| 14:19.15 | ``Erik | I suspect 7.20.2 will be fairly soon once we get feedback, this is a .0 release, so we kinda expect some turbulance :) give it a whack and let us know how bad it is ;) |
| 14:25.12 | epileg | I didn't switch to cmake the deb/rpm building process because there are some things that I'm not able to properly work |
| 14:25.56 | epileg | is there a way to specify the "man" dir with cmake? |
| 14:27.13 | epileg | is there a way to enable the pango rendering text with cmake? |
| 14:39.38 | epileg | also, is there a way to set the "share" folder? |
| 14:47.51 | starseeker | epileg: it's not thoroughly tested, but you can try -DBRLCAD_INSTALL_MAN_DIR=... -DMAN_DIR=... |
| 14:48.27 | starseeker | for share, it would be -DBRLCAD_INSTALL_DATA_DIR=... -DDDATA_DIR=... |
| 14:48.40 | starseeker | uh... dunno what pango is |
| 14:49.00 | starseeker | should clean up that project specific stuff at some point... |
| 14:49.02 | epileg | pango is a text rendering library |
| 14:49.09 | starseeker | do we use it? |
| 14:49.15 | epileg | yes |
| 14:49.18 | starseeker | where? |
| 14:49.44 | epileg | in mged, arch and rtwizard |
| 14:50.16 | starseeker | um. if it needs to be specifically linked in I probably missed it the first time around |
| 14:50.23 | epileg | if I compile brlcad without pango dev libs in my system, resulting execs do not properly render the text |
| 14:50.42 | starseeker | we don't seem to directly use it in our code |
| 14:50.51 | starseeker | only grep matches for pango are in misc and sh dirs |
| 14:51.37 | starseeker | I'm not sure that's us directly then |
| 14:51.54 | starseeker | are you using system Tcl/Tk? |
| 14:52.08 | epileg | I don't know, i just tell You what I get |
| 14:52.36 | starseeker | try ldd - does mged link to libpango? |
| 14:53.10 | starseeker | epileg: I would suggest trying a CMake build and see what happens |
| 14:53.23 | epileg | not, I build them with "./configure --enable-optimized --enable-almost-everything --with-ogl --disable-debug" |
| 14:53.49 | starseeker | hmm. Might be some subtlty with how X and Tk are doing text together |
| 14:53.51 | epileg | I already try cmake and I get a non rendering text on them |
| 14:54.01 | starseeker | even with libpango installed? |
| 14:55.06 | starseeker | ah, wait - that might be the freetype stuff with Tk - I think I might be assuming freetype for the Tk build on some platforms... |
| 14:55.23 | starseeker | epileg: which version of Debian is this? |
| 14:55.49 | epileg | ldd mged http://paste.debian.net/118256/ |
| 14:57.04 | starseeker | huh, weird |
| 14:57.21 | epileg | yes even with libpango installed. in the same system, using autotools, text rendering, with cmake, not text rendering |
| 14:57.43 | starseeker | probably something about the Tk build then |
| 14:58.06 | starseeker | is depressed but not surprised |
| 14:58.16 | epileg | hahaha |
| 14:59.19 | starseeker | Debian does some funny stuff |
| 14:59.53 | starseeker | one of the ultimate motivators for me trying Gentoo was Debian acting funny when it came to customization and settings |
| 15:00.11 | starseeker | God I'd love to ditch tcl/tk |
| 15:00.13 | epileg | well, I do this in Ubuntu 10.10 |
| 15:00.30 | starseeker | k - only way I can test that is if it works in VirtualBox |
| 15:01.25 | epileg | well, I always compile and create deb/rpm on virtualbox machines |
| 15:01.40 | epileg | without problems |
| 15:04.04 | starseeker | epileg: I don't suppose you could try the CMake build with a system Tcl/Tk? |
| 15:05.09 | epileg | I use exactly this: |
| 15:05.09 | epileg | cmake -DBRLCAD-ENABLE_OPTIMIZED_BUILD=ON -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON -DBRLCAD-ENABLE_STRICT=OFF |
| 15:05.35 | starseeker | epileg: OK - what happens with cmake -DBRLCAD-ENABLE_OPTIMIZED_BUILD=ON -DBRLCAD-ENABLE_STRICT=OFF |
| 15:05.49 | starseeker | and a system tcl/tk installed |
| 15:07.13 | epileg | give mi time to test this |
| 15:07.19 | starseeker | sure |
| 15:07.23 | starseeker | no hurry |
| 15:07.42 | starseeker | I'll only be online for a little while - just post the results when you have them |
| 15:07.47 | starseeker | we read scrollback |
| 15:08.13 | epileg | ok |
| 15:39.19 | epileg | starseeker: same result |
| 15:39.49 | epileg | two captures of the results |
| 15:39.51 | epileg | http://imageshack.us/photo/my-images/832/autotools.png/ |
| 15:40.12 | epileg | http://imageshack.us/photo/my-images/810/cmake.png/ |
| 15:45.07 | starseeker | huh - http://www.thermalanalytics.com/products/eclectic/ |
| 15:45.20 | starseeker | gpl and needs info to download though... |
| 15:46.27 | starseeker | looks like different fonts are being used |
| 15:47.58 | epileg | may be, but both compiled and installed in the same system, just different is autotools and cmake |
| 15:48.48 | starseeker | epileg: yeah, then my first suspicion is how Tk is being built/installed |
| 15:49.00 | starseeker | O.o - "Eclectic was developed by the U.S. Army TACOM" |
| 15:50.09 | starseeker | well well well |
| 15:55.33 | epileg | I've to go |
| 15:55.44 | starseeker | epileg: later - thanks for trying things out! |
| 15:56.03 | epileg | no problem :-) |
| 15:56.15 | starseeker | O.O - Eclectic can import our .asc files?? |
| 16:00.53 | *** part/#brlcad kunigami_ (~kunigami@187.106.4.220) | |
| 18:02.01 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 18:42.33 | *** join/#brlcad Stattrav (~Stattrav@117.192.129.172) | |
| 18:42.33 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:44.43 | *** part/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 21:53.49 | *** join/#brlcad merzo (~merzo@153-26-94-178.pool.ukrtel.net) | |
| 22:47.35 | *** join/#brlcad bhinesley (~bhinesley@99.144.90.118) | |
| 00:30.14 | *** join/#brlcad crazy_imp (~mj@a89-182-228-136.net-htp.de) | |
| 00:44.53 | ``Erik | *read* pango is part of the GTK suite, I can't think of any bit of our stuff that uses it directly.... it may be required by something in, say, pkgconfig or something |
| 03:34.49 | *** join/#brlcad merzo (~merzo@18-11-94-178.pool.ukrtel.net) | |
| 04:38.01 | *** join/#brlcad Stattrav (~Stattrav@117.192.129.172) | |
| 04:38.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 04:54.47 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 05:24.57 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.129.172) | |
| 06:10.41 | *** join/#brlcad Stattrav (~Stattrav@117.192.129.172) | |
| 06:10.41 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:31.18 | *** join/#brlcad dli (~dli@dsl-69-172-110-67.acanac.net) | |
| 07:57.19 | *** join/#brlcad mac- (mac@mac.banda.pl) | |
| 07:57.21 | mac- | hi |
| 08:45.08 | *** join/#brlcad dli (~dli@dsl-69-172-110-67.acanac.net) | |
| 10:01.38 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:59.52 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:43.50 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 12:52.30 | *** join/#brlcad kunigami (~kunigami@187.106.4.220) | |
| 14:16.12 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:44.48 | *** join/#brlcad Stattrav (~Stattrav@117.202.18.71) | |
| 14:44.48 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:17.49 | mac- | anyone live ? |
| 17:18.42 | mac- | can you tell me if it is possible to draw some mechanical parts and then simulate movement of them in BRL-CAD ? |
| 17:19.19 | mac- | i.e. with input data of placement from external source of data? |
| 17:36.35 | piksi | don't know actually |
| 17:36.43 | piksi | sounds like you want solidworks-like features |
| 17:37.14 | mac- | maybe more like Nastran |
| 17:37.28 | piksi | i'm not sure, if there are such features i've never used them |
| 17:37.56 | mac- | but I do not need to get result of mechanic calculations from BRL-CAD, because I wish to perform all calculations in Octave |
| 17:38.19 | mac- | then wish to visualize results by parts movement in i.e. BRL-CAD |
| 17:38.45 | mac- | I thought that I can do that in Salome but got difficulties - no one could help me |
| 17:42.27 | mac- | is there any official Forum for BRL-CAD ? |
| 18:05.38 | bhinesley | mac: http://sourceforge.net/projects/brlcad/forums |
| 18:24.02 | *** join/#brlcad Stattrav (~Stattrav@117.202.18.71) | |
| 18:24.02 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:28.14 | mac- | thanks |
| 20:38.36 | piksi | mac-: i don't think there is |
| 21:24.06 | bhinesley | piksi: see my last statement |
| 21:28.22 | piksi | oh, my eye didn't catch that one |
| 22:26.52 | bhinesley | Could someone review/approve a patch for me? |
| 22:26.59 | bhinesley | https://sourceforge.net/tracker/?func=detail&aid=3258381&group_id=105292&atid=640804 |
| 22:27.09 | bhinesley | I'm going to be making some similar changes in a bit. |
| 22:27.30 | bhinesley | just a 'lil tcl |
| 22:35.42 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 22:35.43 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412) | |
| 23:44.56 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 00:08.12 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 00:24.34 | *** join/#brlcad crazy_imp (~mj@a89-182-144-90.net-htp.de) | |
| 01:22.49 | bhinesley | here's a similar one that would be nice to have reviewed: https://sourceforge.net/tracker/?func=detail&aid=3309109&group_id=105292&atid=640804 |
| 01:26.26 | bhinesley | ... and for those on the go, here are three really easy ones: 3267991, 3247828, 3309107 :) |
| 01:26.31 | bhinesley | thanks in advance |
| 02:02.15 | CIA-61 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2891 10/wiki/User:Kunigami/GSoc2011/Reports: |
| 04:22.30 | *** join/#brlcad MinstrelGypsy (~kvirc@bas2-sudbury98-1177726421.dsl.bell.ca) | |
| 05:15.30 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:49.42 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 08:49.42 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:32.15 | *** join/#brlcad crazy_imp (~mj@a89-182-144-90.net-htp.de) | |
| 11:50.38 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:33.58 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:58.24 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:34.55 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 14:26.03 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 15:06.45 | *** join/#brlcad mafm (~mafm@193.153.53.166) | |
| 18:45.43 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1128565378.dsl.bell.ca) | |
| 18:46.35 | IriX64 | pardon, but in your CMake build, how do I disable -Werror, surely you can't expect me to fix all the warnings |
| 18:50.13 | IriX64 | tried passing -DCMAKE_DISABLE_STRICT=ON but no joy |
| 18:51.17 | IriX64 | ill continue to play, ciao |
| 19:36.50 | *** join/#brlcad Stattrav (~Stattrav@117.192.140.111) | |
| 19:36.50 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:24.09 | *** join/#brlcad dloman_ (~claymore@BZ.BZFLAG.BZ) | |
| 20:26.13 | *** join/#brlcad roberthl_ (~robert@v1.rhl.me.uk) | |
| 22:25.32 | *** join/#brlcad mafm (~mafm@193.153.53.166) | |
| 23:36.54 | CIA-61 | BRL-CAD: 03Documentshredding 07http://brlcad.org * r2892 10/wiki/Document_Shredding_-_How_To_Document_Destruction_Training: New page: If you speak of '''[http://www.shreddingservices4.com/document-shredding-nyc/ document shredding]''', their is a need for you to undergo a training so that you can do whatever you wanted t... |
| 00:25.40 | *** join/#brlcad crazy_imp (~mj@a89-182-235-192.net-htp.de) | |
| 00:55.01 | *** join/#brlcad bhinesley (~bhinesley@99.144.90.118) | |
| 01:25.31 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 02:36.24 | starseeker | bhinesley: I'll review the patch tomorrow |
| 02:36.37 | bhinesley | cool, thanks |
| 05:23.45 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) | |
| 06:43.58 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:44.26 | *** join/#brlcad roberthl (~robert@v1.rhl.me.uk) | |
| 06:44.33 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 09:05.48 | *** join/#brlcad Stattrav (~Stattrav@122.167.103.233) | |
| 09:05.48 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:00.51 | *** join/#brlcad mafm (~mafm@220.Red-88-22-160.staticIP.rima-tde.net) | |
| 10:31.26 | dloman | yawns |
| 10:37.13 | CIA-61 | BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Document Shredding - How To Document Destruction Training]]": This is spam. Please, someone with permissions, block User:Documentshredding |
| 10:38.03 | CIA-61 | BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Seo service - For starters]]": This is spam. Please, someone with permissions, block User:Seo1 |
| 10:38.41 | CIA-61 | BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Credit Cards Australia - How to Rate Credit Card Australia]]": This is spam. Please, someone with permissions, block User:Creditcardsaustralia |
| 10:39.52 | CIA-61 | BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Casinopaysafecard]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 10:40.04 | dloman | oooooh, i has block perms. Hehehehe, when did that happen? |
| 10:40.11 | dloman | "THE POWER!!!!!" |
| 10:40.42 | CIA-61 | BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Seo1]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 10:41.13 | CIA-61 | BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Creditcardsaustralia]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 10:41.55 | CIA-61 | BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Image:Casino Paysafecard - How To PlayStealing Bundles Casino24.pdf]]": This is spam. |
| 10:43.09 | CIA-61 | BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Documentshredding]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 10:45.55 | CIA-61 | BRL-CAD: 03Dloman 07http://brlcad.org * r2893 10/wiki/Documentation: Reverted edits by [[Special:Contributions/67.180.102.232|67.180.102.232]] ([[User talk:67.180.102.232|Talk]]); changed back to last version by [[User:72.234.127.28|72.234.127.28]] |
| 10:46.28 | CIA-61 | BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:67.180.102.232]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 10:50.03 | CIA-61 | BRL-CAD: 03Dloman 07http://brlcad.org * r2894 10/wiki/Documentation: Rolling back to last good version |
| 10:51.46 | CIA-61 | BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:72.234.127.28]] with an expiry time of infinite (anonymous users only, account creation disabled): Inserting nonsense/gibberish into pages |
| 10:52.28 | CIA-61 | BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:122.3.171.14]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 10:52.51 | CIA-61 | BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Forex Trading- How To Understand FOREX Market Sentiment]]": This is spam. |
| 11:02.08 | ``Erik | probably about when you created your wiki account and brlcad set you up |
| 11:24.53 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:43.37 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:08.18 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:19.28 | CIA-61 | BRL-CAD: 03brlcad * r44714 10/brlcad/trunk/include/bu.h: consider different encoding types for proper flexibility |
| 13:48.58 | starseeker | ``Erik: http://www.thermalanalytics.com/products/eclectic/ |
| 14:02.46 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 14:26.21 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 14:43.17 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:06.11 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 15:07.49 | starseeker | O.o http://scantailor.sourceforge.net/ |
| 15:16.08 | *** part/#brlcad PrezKennedy (DC@173.231.40.98) | |
| 15:18.17 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 15:35.03 | *** join/#brlcad dli (~dli@dsl-69-172-110-67.acanac.net) | |
| 15:54.34 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 15:55.21 | *** join/#brlcad Stattrav (~Stattrav@117.192.136.106) | |
| 15:55.22 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:08.19 | CIA-61 | BRL-CAD: 03starseeker * r44715 10/brlcad/trunk/src/tclscripts/mged/g2asc.tcl: Reviewed and applied patch from Brandon Hinesley (one of our 2011 GSoC students) that replaces MGED's g2asc saving dialog with the proper use of tk_getSaveFile. |
| 16:26.21 | CIA-61 | BRL-CAD: 03brlcad * r44716 10/brlcad/trunk/AUTHORS: note the code contribution from sf patch 3258381 (mged's export ASCII: Changed input box to a save file dialog) that cliff applied in r44715 |
| 16:41.04 | *** join/#brlcad kjander (~kristoffe@ip70-190-7-201.ph.ph.cox.net) | |
| 16:49.44 | kjander | have any private engineering firms adopted brl-cad? |
| 16:50.15 | kjander | i should say, does anyone have experience with a private engineering firm making that adoption? |
| 16:50.43 | ``Erik | commercial companies rarely advertise what products they use, I know that beoing has used it, but only because they've sent change requests or info requests |
| 16:51.05 | starseeker | kjander: depends also on what use |
| 16:51.30 | starseeker | if you mean as their primary in-house CAD tool, I have not heard of anyone doing that |
| 16:53.27 | kjander | right. i work with a small engineering startup and was curious if it would make a decent replacement for something like solidworks. i definitely see the pitfalls, the engineers aren't used to it, the commandline would seem primitive and the programmatic access it provides not much of an advantage. but also, as a startup, cad licensing costs can be brutal and i wanted to see if i could pitch brlcad as a viable alt |
| 16:54.20 | kjander | it's mostly for soft mockups of design, material interrogation is not a primary concern |
| 16:54.27 | ``Erik | BRL-CAD is mostly designed as an analysis package and may not be optimal for design work... we don't do, say, line drawing with scales |
| 16:56.24 | *** join/#brlcad dli (~dli@dyn-199-015.vpn.199.Concordia.CA) | |
| 16:57.10 | kjander | thanks ``Erik and starseeker. I think it that quick exchange you've already answered my question |
| 17:19.27 | *** part/#brlcad kjander (~kristoffe@ip70-190-7-201.ph.ph.cox.net) | |
| 17:26.18 | *** join/#brlcad dli (~dli@69.172.110.67) | |
| 17:27.33 | CIA-61 | BRL-CAD: 03bob1961 * r44717 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Removed bot2pipe from mArcherCoreCommands. |
| 17:55.49 | bhinesley | Is it a bad idea to submit two separate patches that affect the same file? |
| 18:46.55 | starseeker | bhinesley: no, that's fine |
| 18:47.22 | bhinesley | it doesn't make it any more difficult to approve? |
| 18:49.00 | starseeker | well, depends on the change |
| 18:49.09 | starseeker | feel free to submit it however you think best |
| 18:49.37 | bhinesley | okay |
| 18:49.52 | bhinesley | I was trying to avoid putting unrelated changes in the same patch |
| 18:50.26 | starseeker | how extensive are the changes? |
| 18:50.41 | bhinesley | not very... 10-20 lines each |
| 18:51.07 | starseeker | shrugs - either way, we'll sort it out ;-) |
| 18:51.32 | bhinesley | alright |
| 18:52.48 | bhinesley | just trying to not be a PITA |
| 18:54.59 | bhinesley | waits patiently for his book to arrive: http://www.amazon.com/Practical-Programming-Tcl-Tk-4th/dp/0130385603/ref=pd_ecc_rvi_cart_1 |
| 18:55.03 | starseeker | bhinesley: as long as you're improving things, your not a PITA :-) |
| 18:55.09 | bhinesley | haha |
| 18:55.10 | bhinesley | right on |
| 19:06.30 | *** join/#brlcad mafm (~mafm@230.Red-81-43-146.staticIP.rima-tde.net) | |
| 21:47.48 | *** join/#brlcad Stattrav (~Stattrav@117.192.156.95) | |
| 21:47.48 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:54.24 | CIA-61 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User:526 buy viagra]]": content was: '[http://viagra-soft-flavoured.abanteae.pl CLICK HERE TO BUY SOFT VIAGRA]' (and the only contributor was '[[Special:Contributions/83.24.64.144|83.24.64.144]]') |
| 21:54.34 | CIA-61 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:83.24.64.144]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 21:59.15 | *** join/#brlcad Stattrav (~Stattrav@117.192.156.95) | |
| 21:59.15 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 22:03.17 | CIA-61 | BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2895 10/wiki/User:Bhinesley: Started logging my progress onto the wiki |
| 00:18.44 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 00:20.59 | starseeker | is chagrined to discoverer he is having to read up on our basic ray/object intersection algorithms to make sense of them |
| 00:21.58 | bhinesley | well if it makes you feel any better, I had to look up chagrined to make sense of what you're saying |
| 00:24.00 | starseeker | heh |
| 00:24.22 | starseeker | Tim Daly of Axiom likes to say "there is no such thing as a simple job" |
| 00:24.59 | *** join/#brlcad crazy_imp (~mj@a89-182-228-164.net-htp.de) | |
| 03:50.11 | *** part/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 05:12.35 | *** join/#brlcad Stattrav (~Stattrav@122.167.103.233) | |
| 05:12.35 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:42.00 | starseeker | O.o http://advancingusability.wordpress.com/2010/11/09/cutexture-a-framework-for-qt-user-interfaces-in-ogre3d/ |
| 05:45.00 | starseeker | O.O https://qt.gitorious.org/qt-labs/qmlogre |
| 05:45.56 | starseeker | drools: http://www.youtube.com/watch?v=b_3xfFuwGOQ |
| 05:46.56 | starseeker | that might just be the Qt/Ogre integration solution |
| 08:34.11 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 08:34.47 | epileg | i got problems setting man dir in cmake |
| 08:36.59 | epileg | if I set: $ cmake [...] -DBRLCAD_INSTALL_MAN_DIR=share/man |
| 08:36.59 | epileg | I get: |
| 08:36.59 | epileg | [...] |
| 08:36.59 | epileg | Generating Tk man pages... |
| 08:36.59 | epileg | CMake Error at src/other/tkhtml/CMakeLists.txt:102 (install): |
| 08:36.59 | epileg | <PROTECTED> |
| 08:36.59 | epileg | [...] |
| 09:21.24 | *** join/#brlcad mafm (~mafm@193.153.198.34) | |
| 09:26.11 | *** join/#brlcad mafm (~mafm@193.153.198.34) | |
| 10:30.01 | epileg | if I use: -DBRLCAD_INSTALL_DATA_DIR=share |
| 10:30.01 | epileg | man pages are not installed too |
| 10:58.30 | dloman | yawns |
| 11:28.14 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 11:58.37 | *** join/#brlcad kunigami_ (~kunigami@loco-gw.ic.unicamp.br) | |
| 12:36.39 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:45.54 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.140) | |
| 12:45.54 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:47.41 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 13:03.41 | CIA-61 | BRL-CAD: 03bob1961 * r44718 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Needed to override ArcherCore::cmd because core commands added in Archer (including Core plugins) were not getting recognized. Added code to append core commands coming from plugins to mArcherCoreCommands. |
| 13:39.27 | ``Erik | http://news.slashdot.org/story/11/05/31/202238/Free-Software-Faces-a-Test-With-Qt |
| 13:44.35 | ``Erik | http://labs.qt.nokia.com/2011/05/31/qml-scene-graph-in-master/ |
| 14:25.06 | d_rossberg | is there a special reason why the build of static libs is switched off for MSVC in BRLCAD_Util.cmake? |
| 14:41.46 | *** join/#brlcad kunigami_ (~kunigami@loco-gw.ic.unicamp.br) | |
| 14:47.19 | starseeker | ``Erik: heh - the comments pretty thoroughly trashed that slashdot posting |
| 14:50.42 | starseeker | d_rossberg: uh... a vague memory was that they weren't adding much for the Windows build and were significantly increasing the build time... |
| 14:50.46 | starseeker | I'd have to check the logs |
| 14:51.21 | starseeker | d_rossberg: do you need them? |
| 14:51.35 | starseeker | the windows build is amazingly slow as it is... |
| 15:00.15 | *** join/#brlcad kunigami_ (~kunigami@loco-gw.ic.unicamp.br) | |
| 15:04.54 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 15:06.47 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 15:11.50 | d_rossberg | starseeker: i need them for the brlcad.dll |
| 15:12.20 | d_rossberg | they are build on request only anyway, or? |
| 15:12.45 | d_rossberg | "BUILD_STATIC_LIBS" |
| 15:13.30 | starseeker | d_rossberg: what's the difference on Windows between static and dynamic libs? |
| 15:15.21 | starseeker | d_rossberg: The way I had it set up - Debug builds don't build static unless you explicitly ask for them |
| 15:15.32 | starseeker | Release builds do build them, except with MSVC |
| 15:16.31 | starseeker | d_rossberg: the quick way to try it is to take out the "AND NOT MSVC" and see what happens |
| 15:17.21 | starseeker | really does need to do more scrubbing on the CMake build logic |
| 15:19.32 | d_rossberg | dynamic: you get a file (.dll) which has to be installed with the program; static: you get a file with object code which has to be linked with something executable |
| 15:20.10 | d_rossberg | i'll try a run with "NOT MSVC" removed |
| 16:21.00 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.140) | |
| 16:21.00 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:28.03 | CIA-61 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload: |
| 16:28.03 | CIA-61 | BRL-CAD: uploaded "[[Image:Moose Mascot.png]]": This image was drawn by Nicholas Reed in |
| 16:28.03 | CIA-61 | BRL-CAD: 2009 depicting BRL-CAD's magnificent moose mascot. BRL-CAD's was started in |
| 16:28.03 | CIA-61 | BRL-CAD: 1979 by Mike Muuss. You're clever enough to figure out the rest. |
| 16:29.49 | CIA-61 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Image:Moose Mascot.png]]": too big |
| 16:31.46 | CIA-61 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload: |
| 16:31.46 | CIA-61 | BRL-CAD: uploaded "[[Image:Moose Mascot.png]]": This image was drawn by Nicholas Reed in 2009 depicting BRL-CAD's magnificent moose mascot. BRL-CAD's was started in 1979 by Mike Muuss. You're clever enough to figure out the rest. |
| 16:31.46 | CIA-61 | BRL-CAD: This image was used in 2011 for the [http://brlcad.org/d/node/89 BRL-CAD Logo Competition]. |
| 18:01.58 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:10.52 | *** join/#brlcad dli (~dli@66.49.232.17) | |
| 18:45.18 | CIA-61 | BRL-CAD: 03bob1961 * r44719 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Clear out bindings on the <Enter> event for the geometry window in Ged::init_view_bindings. |
| 19:40.57 | kunigami_ | Hi, since I'm not able to link OSL libraries, I was thinking in building them together with BRLCAD. Do you think that this is feasible or I will have to change too much of the cmake configuration files? |
| 19:45.19 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.140) | |
| 19:45.19 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 22:38.56 | CIA-61 | BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2898 10/wiki/User:Bhinesley: /* Log */ |
| 00:25.25 | *** join/#brlcad crazy_imp (~mj@a89-182-221-38.net-htp.de) | |
| 00:31.43 | starseeker | kunigami: you haven't been able to determine the reason it's not working? |
| 00:31.49 | starseeker | kunigami: have you asked on the osl list? |
| 03:05.05 | bhinesley | if anyone has a minute, I'd really appreciate a review of this patch: https://sourceforge.net/tracker/?func=detail&aid=3309109&group_id=105292&atid=640804 |
| 03:06.31 | bhinesley | it changes mged's text box for inputting a new database name to a better dialog |
| 03:08.19 | bhinesley | help a young noob earn svn access ;-) |
| 03:08.28 | bhinesley | *commit |
| 03:09.10 | bhinesley | and eliminate channel spam |
| 03:38.10 | CIA-61 | BRL-CAD: 03starseeker * r44720 10/brlcad/trunk/src/tclscripts/mged/mged.tcl: Apply patch 3309109 from Brandon Hinesley - use tk dialog for File->New in mged. |
| 03:58.44 | CIA-61 | BRL-CAD: 03brlcad * r44721 10/brlcad/trunk/NEWS: cliff applied sf patch 3309109 (mged's new db input box changed to save file dialog) from brandon hinesley providing an improved file->new dialog for mged |
| 03:59.47 | bhinesley | thanks :) |
| 04:03.34 | CIA-61 | BRL-CAD: 03brlcad * r44722 10/geomcore/trunk/src/libNet/CMakeLists.txt: apparently libpkg is needed, link failure on 10.6 with pkg symbols |
| 07:17.06 | *** join/#brlcad Stattrav (~Stattrav@122.167.103.233) | |
| 07:17.06 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:25.47 | *** join/#brlcad mafm (~mafm@116.Red-83-49-86.dynamicIP.rima-tde.net) | |
| 13:48.22 | CIA-61 | BRL-CAD: 03davidloman * r44723 10/geomcore/trunk/src/libNet/netMsg/GeometryManifestMsg.cxx: Remove some debug printers |
| 14:02.56 | dloman | http://www.27bslash6.com/missy.html |
| 14:02.58 | dloman | lol |
| 14:06.08 | crazy_imp | heyho |
| 14:06.22 | crazy_imp | how can i translate & rotate a group in mged? |
| 14:06.48 | crazy_imp | (or convert the given group into a solid, which would be fine too :) |
| 14:07.30 | dloman | either use the 'matrix selection' menu or the |
| 14:07.43 | dloman | 'oed' command |
| 14:08.25 | dloman | either way, the concept is to prvide a path from the root of the db tree all the way down to a solid, splitting the path where you want to edit |
| 14:12.14 | crazy_imp | is it possible to show the commands issued by the matrix selection? |
| 14:12.45 | dloman | that i dunno |
| 14:12.49 | dloman | if your path is: |
| 14:13.07 | dloman | all/armor/upper/toparmor.r/toparmor01.s |
| 14:13.33 | dloman | then the oed command for editing 'upper' would look like this: |
| 14:13.56 | dloman | oed all/armor/ upper/toparmor.r/toparmor01.s |
| 14:14.02 | dloman | that would put you in matrix edit mode |
| 14:14.28 | dloman | you should, at that point, be able to manipulate 'upper' and everything in the tree below it. |
| 14:14.59 | dloman | for rotations, please note that the keypoint of toparmor01.s will be the 'rotate about' point |
| 14:16.17 | crazy_imp | ok, thanks :) |
| 14:16.25 | dloman | no prob! |
| 14:20.47 | crazy_imp | dloman: what kind of "object" is armor? |
| 14:22.05 | dloman | combination |
| 14:22.30 | dloman | object type path: comb/comb/comb/region/prim |
| 14:22.58 | crazy_imp | k |
| 14:32.51 | crazy_imp | with the oed command i only get one primitive :|. let's say i have foo.r made from a.s, b.s and c.s (as union) -> 'oed foo.r /b.s' edits only b.s |
| 14:33.11 | dloman | correct. |
| 14:33.35 | dloman | the first object on the right hand path will be the object in edit |
| 14:33.39 | dloman | so in your case |
| 14:33.50 | dloman | if you: 'B foo.r' |
| 14:34.03 | dloman | then 'oed / /foo.r/a.s' |
| 14:34.11 | dloman | you will be in matrix edit mode on foo.r |
| 14:34.45 | crazy_imp | \o/ |
| 14:52.06 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:53.40 | crazy_imp | dloman: is it possible to have a second region like foo.r, made from the same solids but at a different position (making the changes only to the region and not to the solids) - so if i change the solid, it'll be changed in both regions? |
| 14:54.01 | dloman | yes, that's basic instancing. |
| 14:54.10 | dloman | just do a copy |
| 14:54.22 | dloman | 'cp foo.r foo2.r' |
| 14:56.57 | crazy_imp | hm, oed / /foo2.r/b.s fails now |
| 14:57.13 | dloman | is foo2.r displayed? |
| 14:57.21 | dloman | via 'e foo2.r' ? |
| 14:58.00 | crazy_imp | ah, ok :) |
| 14:58.42 | crazy_imp | but i can't change the solid now, sed b.s says it's "multiply referenced" (which makes sense) |
| 14:58.44 | crazy_imp | brb |
| 14:59.19 | dloman | you can edit the solid individually with 'sed' command, just not via matrix edit |
| 15:10.51 | crazy_imp | it's a little bit confusing i can't edit the original b.s, but if i change foo2.r/b.s every b.s changes :D |
| 15:16.43 | dloman | yeah :/ a lot of times, instancing is more trouble that its worth. |
| 15:20.33 | crazy_imp | the other way round would be more intuitive imho |
| 15:27.51 | *** join/#brlcad mafm (~mafm@116.Red-83-49-86.dynamicIP.rima-tde.net) | |
| 16:05.46 | CIA-61 | BRL-CAD: 03davidloman * r44724 10/geomcore/trunk/ (2 files in 2 dirs): Change some verbage for clarity. |
| 16:07.28 | CIA-61 | BRL-CAD: 03davidloman * r44725 10/geomcore/trunk/ (5 files in 2 dirs): Modify iDataSource interface a bit. Added/fixed lots of functionality to FileDataSource. |
| 16:09.20 | CIA-61 | BRL-CAD: 03davidloman * r44726 10/geomcore/trunk/src/GS/GSClient.cxx: Fix handling of GeoChunk. Was returning false instead of true. Removed debug printing. |
| 16:11.16 | CIA-61 | BRL-CAD: 03davidloman * r44727 10/geomcore/trunk/ (include/ExtObject.h src/GS/ExtObject.cxx): Reworked cstr to take full path rather than just object name. Fixed deconstructor memory freeing. Added EXT_MAGIC to serialization/deserialization routines. Various other fixes. |
| 16:12.58 | CIA-61 | BRL-CAD: 03davidloman * r44728 10/geomcore/trunk/ (include/BrlcadDb.h src/GS/BrlcadDb.cxx): Add NULL_POINTER return value static. Add in recursive functions for pulling an entire tree of geometry rather than just the children of an object. |
| 16:14.30 | CIA-61 | BRL-CAD: 03davidloman * r44729 10/geomcore/trunk/src/GS/DataManager.cxx: Cascading changes from the mods to FileDataSource, BrlcadDb and ExtObject |
| 16:24.38 | CIA-61 | BRL-CAD: 03davidloman * r44730 10/geomcore/trunk/tests/func/GS/FileDataSourceTest.cxx: Using ExtObject now not MinimialObject |
| 16:25.16 | *** join/#brlcad merzo (~merzo@189-2-94-178.pool.ukrtel.net) | |
| 16:34.56 | *** join/#brlcad Stattrav (~Stattrav@117.192.134.147) | |
| 16:34.56 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:45.22 | *** join/#brlcad Stattrav (~Stattrav@117.192.134.147) | |
| 16:45.22 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:22.17 | *** join/#brlcad Stattrav (~Stattrav@117.192.134.147) | |
| 17:22.17 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:12.41 | *** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net) | |
| 18:12.48 | yukonbob | hello, #brl-cad : |
| 18:12.51 | yukonbob | :) |
| 18:49.58 | CIA-61 | BRL-CAD: 03davidloman * r44731 10/geomcore/trunk/ (5 files in 5 dirs): Remove dependancy for libge. Replaced by simpler BrlcadDb and ExtObject classes |
| 18:50.09 | *** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net) | |
| 19:00.44 | *** join/#brlcad merzo (~merzo@174-237-132-95.pool.ukrtel.net) | |
| 22:02.37 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 22:11.59 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 23:18.19 | CIA-61 | BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2899 10/wiki/User:Bhinesley: /* Log */ today |
| 23:23.23 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 00:12.43 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 00:25.48 | *** join/#brlcad crazy_imp (~mj@a89-182-173-66.net-htp.de) | |
| 00:32.54 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 01:07.01 | crazy_imp | is it possible to extrude a face along a curve? (like the pipe solid, but with another shape) |
| 02:23.53 | bhinesley | do you mean a revolve, like this: http://docs.autodesk.com/ACD/2010/ENU/AutoCAD%202010%20User%20Documentation/index.html?url=WS1a9193826455f5ffa23ce210c4a30acaf-540f.htm,topicNumber=d0e304250 ? |
| 02:24.00 | bhinesley | if so, I believe the answer is no |
| 02:28.13 | bhinesley | It looks like someone attempted it: http://brlcad.org/wiki/User:Pacman87 |
| 02:28.26 | bhinesley | I do not see any indication that it was finished though |
| 02:29.51 | bhinesley | and actually, what you asked for sounds more like a sweep than a revolve |
| 02:31.19 | bhinesley | like this: http://docs.autodesk.com/ACD/2010/ENU/AutoCAD%202010%20User%20Documentation/index.html?url=WS1a9193826455f5ffa23ce210c4a30acaf-5303.htm,topicNumber=d0e319229 |
| 04:41.46 | bhinesley | sighs peacefully |
| 04:41.47 | bhinesley | All that reading paid off, I'm finally getting somewhere with migrating/refactoring the man command |
| 04:49.58 | bhinesley | Should Archer continue to use the MGED man pages for the time being? |
| 05:03.51 | bhinesley | Also, what do you guys think about adding a filter for the list of man pages, or perhaps just having it jump to a given letter of the alphabet on keypress? There are many commands on there, making it kind of a pain to navigate. |
| 05:07.00 | CIA-61 | BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2900 10/wiki/User:Bhinesley: /* Log */ modified today's entries |
| 07:36.37 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 07:36.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:20.46 | crazy_imp | bhinesley: the sweep would allow more complex curves / paths, but the revolve would do the trick too with more (with some more segments) |
| 08:34.58 | *** join/#brlcad mafm (~mafm@142.Red-81-34-12.dynamicIP.rima-tde.net) | |
| 10:42.40 | kunigami | starseeker: I never get replies from OSL list :) But thanks to Sean's email I've figured out the error! I'll update the news soon! |
| 10:52.09 | *** join/#brlcad kunigami_ (~kunigami@loco-gw.ic.unicamp.br) | |
| 11:48.59 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 11:56.43 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 12:34.33 | starseeker | huh: http://www.askoh.com/stcad/index.html |
| 13:00.24 | *** join/#brlcad mafm (~mafm@220.Red-88-22-160.staticIP.rima-tde.net) | |
| 13:16.46 | *** join/#brlcad mafm_ (~mafm@220.Red-88-22-160.staticIP.rima-tde.net) | |
| 14:33.58 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:36.34 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 15:23.41 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 15:48.50 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.147.206) | |
| 17:05.21 | ``Erik | starseeker: 7.20.0 is missing a lot of it's cmake stuff :/ |
| 17:08.11 | *** join/#brlcad Stattrav (~Stattrav@117.192.147.206) | |
| 17:08.12 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:39.41 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 17:48.15 | *** join/#brlcad kunigami1 (~kunigami@loco-gw.ic.unicamp.br) | |
| 18:03.29 | kunigami | hi, does anyone know how to clear a flag on cmake? I did the following test: http://pastebin.mozilla.org/1241499 |
| 18:04.10 | kunigami | but when I run make VERBOSE=1, it seems that the -Werror flag is added even after I clean up CMAKE_CXX_FLAGS |
| 18:11.29 | bhinesley | try --disable-strict or -DBRLCAD-ENABLE_STRICT=OFF |
| 18:16.29 | bhinesley | kunigami: probably the prior |
| 18:29.41 | kunigami | bhinesley: Actually I'd like to turn off these flags only when compiling part of the code. So I was wondering if I could do this within cmake files |
| 18:33.36 | bhinesley | Oh, gottcha. |
| 18:45.03 | ``Erik | don't think it's set up like that, but if you dig into the CMakeFiles directory, you'll find a file flags.make you can edit (it'll be overwritten if you change the CMakeLists.txt) |
| 19:02.18 | kunigami | But can't I add this to CMakeLists so that whenever I run cmake the generated Makefile does not contain those flags? |
| 19:02.56 | kunigami | That's because OSL headers raises warnings that are treated as error by BRL-CAD build, so I'm getting compilation errors |
| 19:04.41 | kunigami | So I'd like to temporarily turn off some of the flags (I think only -Werror is enough) and after linking to OSL I turn them on again |
| 19:17.19 | ``Erik | I jabbed starseeker, he's the cmake guy |
| 19:18.23 | starseeker | kunigami: there is a way |
| 19:18.40 | starseeker | but why not just turn off the strict flags? |
| 19:19.22 | starseeker | if you want to get more systematic... |
| 19:19.24 | starseeker | looks it up |
| 19:20.34 | starseeker | ok. |
| 19:20.41 | starseeker | src/other/CMakeLists.txt is an example |
| 19:21.17 | starseeker | for the specific directory and sub-directories, you can do add_definitions(-Wno-error) or something like that |
| 19:21.26 | starseeker | if you want to do it just for a single library... |
| 19:22.32 | starseeker | <PROTECTED> |
| 19:22.40 | starseeker | that's probably what you're looking for |
| 19:26.16 | ``Erik | Nice. http://www.youtube.com/watch?v=sR2296df-bc (short ringworld animation) |
| 19:27.13 | *** join/#brlcad Stattrav (~Stattrav@117.192.147.206) | |
| 19:27.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:32.57 | CIA-61 | BRL-CAD: 03erikgreenwald * r44732 10/brlcad/trunk/src/proc-db/ringworld.c: add some size/mass notes |
| 19:37.51 | CIA-61 | BRL-CAD: 03erikgreenwald * r44733 10/brlcad/trunk/src/libgcv/ (CMakeLists.txt Makefile.am bottess.c): start of the j3dbool style tesselator |
| 19:42.47 | *** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 19:44.21 | CIA-61 | BRL-CAD: 03Trgjos 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:Cash-payday-advance.pdf]]" |
| 19:51.12 | CIA-61 | BRL-CAD: 03Trgjos 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:5128.pdf]]" |
| 20:28.01 | bhinesley | starseeker ``Erik: I'm moving the Manual Page Browser out of Archer/MGED and into a common script. Should this go in tclscripts/helpcomm.tcl, a new file tclscripts/man_browser.tcl, or somewhere else? |
| 20:46.11 | kunigami | starseeker: thank you |
| 20:47.32 | starseeker | bhinesley: I'd vote for tclscripts/man_browser.tcl |
| 21:07.42 | bhinesley | runs with it |
| 21:16.05 | kunigami | hmm I think that what is causing the compile error is the -pedantic flag. Adding -Wno-error is not resolving :( |
| 21:17.13 | starseeker | try -DBRLCAD-ENABLE_COMPILER_WARNINGS=OFF |
| 21:20.49 | kunigami | cool. it works well. thanks again |
| 22:34.03 | *** join/#brlcad kunigami (~kunigami@201.53.197.251) | |
| 00:26.00 | *** join/#brlcad crazy_imp (~mj@a89-182-194-68.net-htp.de) | |
| 01:09.54 | starseeker | wow - this old chicken scheme CMake file is quite impressive |
| 04:24.08 | ``Erik | cool, salvagable? educational? |
| 04:24.33 | starseeker | definitely educational - possibly partially salvagable |
| 04:24.41 | starseeker | looks like the build has changed quite a lot |
| 04:25.21 | starseeker | I stuck it on github as a hedge against the copy of the tarball someone posted vanishing - https://github.com/starseeker/chicken |
| 04:25.49 | starseeker | (chicken-2.6 branch has the original tarball contents. master is 4.7.0 - will try to adapt the CMake build logic to the new stuff there) |
| 04:27.37 | starseeker | ``Erik: overall chicken is still looking like the best combination of license, features and embeddability of the options I can scare up, plus the advantage of a head start on the CMake stuff |
| 04:28.21 | starseeker | rather impressively, the 2.6 version actually built successfully on my gentoo box - not bad given how old it is |
| 06:37.08 | *** join/#brlcad Stattrav (~Stattrav@117.192.128.135) | |
| 06:37.08 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:17.30 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 08:17.30 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:58.53 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 10:58.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:42.59 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 16:55.53 | *** join/#brlcad tupone (~tupone@gentoo/developer/tupone) | |
| 16:57.16 | *** part/#brlcad tupone (~tupone@gentoo/developer/tupone) | |
| 17:51.33 | CIA-61 | BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2903 10/wiki/User:Bhinesley: /* Log */ Logged yesterday, and my plan for today |
| 17:53.56 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:00.27 | CIA-61 | BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2904 10/wiki/User:Bhinesley: /* Log */ Reversing order, so that new entries are on top |
| 18:22.07 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:38.15 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:12.40 | *** join/#brlcad Stattrav (~Stattrav@117.192.132.10) | |
| 19:12.40 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:25.10 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:40.27 | *** join/#brlcad Yoshi47 (~jan@d72-39-60-53.home1.cgocable.net) | |
| 21:35.17 | CIA-61 | BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2905 10/wiki/User:Bhinesley: /* Experience */ removed redundant statement |
| 22:53.51 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177879044.dsl.bell.ca) | |
| 00:26.13 | *** join/#brlcad crazy_imp (~mj@a89-182-147-86.net-htp.de) | |
| 00:28.34 | *** join/#brlcad Stattrav (~Stattrav@117.192.132.10) | |
| 00:28.34 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 04:17.50 | *** join/#brlcad Stattrav (~Stattrav@223.177.104.197) | |
| 04:17.50 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:05.45 | *** join/#brlcad Stattrav (~Stattrav@203.196.190.162) | |
| 11:05.45 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:10.43 | *** join/#brlcad Stattrav (~Stattrav@203.196.190.162) | |
| 11:10.43 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:13.25 | *** join/#brlcad crazy_imp (~mj@a89-182-147-86.net-htp.de) | |
| 11:29.50 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:44.56 | *** join/#brlcad Stattrav (~Stattrav@27.57.139.96) | |
| 15:44.56 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:03.48 | *** join/#brlcad Stattrav (~Stattrav@27.57.139.96) | |
| 16:03.48 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:29.15 | CIA-61 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2906 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */ |
| 17:03.08 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 18:34.15 | *** join/#brlcad Stattrav (~Stattrav@203.196.190.162) | |
| 18:34.15 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:54.29 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 20:02.07 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:16.05 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 23:11.52 | *** join/#brlcad kunigami (~kunigami@201.53.197.251) | |
| 23:34.24 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 00:26.15 | *** join/#brlcad crazy_imp (~mj@a89-182-196-119.net-htp.de) | |
| 01:20.19 | *** part/#brlcad kunigami (~kunigami@201.53.197.251) | |
| 02:10.55 | *** join/#brlcad waprat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 02:48.35 | *** join/#brlcad DarkCalf (DC@2002:ade7:2862::ade7:2862) | |
| 03:39.54 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 03:58.31 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 04:38.27 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:06.13 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 08:17.52 | *** join/#brlcad Stattrav_ (~Stattrav@27.57.104.252) | |
| 09:32.02 | *** join/#brlcad Stattrav (~Stattrav@203.196.190.162) | |
| 09:32.02 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:27.19 | dloman | yawns |
| 11:34.03 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 12:23.27 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 12:24.27 | *** join/#brlcad juanman (~quassel@186.136.168.73) | |
| 12:24.33 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 14:08.42 | ``Erik | hm, cia's being a bit slow |
| 14:48.10 | *** join/#brlcad DarkCalff (DC@173.231.40.98) | |
| 14:55.42 | CIA-61 | BRL-CAD: 03tbrowder2 * r44734 10/brlcad/trunk/src/libfb/if_X24.c: correct spelling error |
| 15:00.03 | CIA-61 | BRL-CAD: 03erikgreenwald * r44735 10/brlcad/trunk/src/conv/g-egg.c: Add a -9 flag to trigger the new bottess stuff for testing. |
| 16:46.49 | CIA-61 | BRL-CAD: 03erikgreenwald * r44736 10/brlcad/trunk/src/conv/g-egg.c: add 9 to the getopt list and break after setting use_bottess |
| 17:17.42 | *** join/#brlcad kunigami_ (~kunigami@loco-gw.ic.unicamp.br) | |
| 17:25.18 | CIA-61 | BRL-CAD: 03brlcad * r44737 10/geomcore/trunk/tests/unit/test_runner.cxx: fix funky function spacing |
| 17:27.47 | *** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 17:30.51 | CIA-61 | BRL-CAD: 03erikgreenwald * r44738 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: Squash uninitialized variable warnings. |
| 17:45.10 | CIA-61 | BRL-CAD: 03starseeker * r44739 10/brlcad/trunk/CMakeLists.txt: Go with IGNORE_PATH for avoid install path - seems to be working in tests on Linux... |
| 18:41.00 | CIA-61 | BRL-CAD: 03erikgreenwald * r44740 10/brlcad/trunk/ (99 files in 99 dirs): Add CMakeLists.txt to EXTRA_DIST. |
| 18:46.10 | CIA-61 | BRL-CAD: 03erikgreenwald * r44741 10/brlcad/trunk/misc/Makefile.am: add CMake/ stuff to EXTRA_DIST |
| 18:59.51 | CIA-61 | BRL-CAD: 03starseeker * r44742 10/brlcad/trunk/CMakeLists.txt: Add an option to play nice as a subbuild of another project - turns off the distcheck support, timing code and cpack settings that would be the responsibility of a parent project. |
| 19:01.22 | ``Erik | starseeker: http://pastebin.ca/2075689 |
| 19:35.00 | CIA-61 | BRL-CAD: 03brlcad * r44743 10/brlcad/trunk/BUGS: seem to have found a bu_log bug |
| 19:35.04 | CIA-61 | BRL-CAD: 03erikgreenwald * r44744 10/brlcad/trunk/src/other/step/include/Makefile.am: add scl_cf_cmake.h.in to EXTRA_DIST |
| 19:36.23 | CIA-61 | BRL-CAD: 03erikgreenwald * r44745 10/brlcad/trunk/src/other/ (9 files in 9 dirs): add CMake/* stuff to EXTRA_DIST |
| 19:48.06 | CIA-61 | BRL-CAD: 03brlcad * r44746 10/brlcad/trunk/ (12 files in 7 dirs): (log message trimmed) |
| 19:48.07 | CIA-61 | BRL-CAD: accept kunigami's sf patch 3250116 (Corrected funcionality to bu_basename) that |
| 19:48.07 | CIA-61 | BRL-CAD: makes bu_basename() correspond more closely with basename() albeit with |
| 19:48.07 | CIA-61 | BRL-CAD: different memory management behavior, the latter being more consistent with |
| 19:48.07 | CIA-61 | BRL-CAD: bu_dirname(). this annoyingly requires that all bu_basename calls must now |
| 19:48.07 | CIA-61 | BRL-CAD: bu_free the memory returned but is the non-destructive thread-safe reentrant |
| 19:48.07 | CIA-61 | BRL-CAD: option for now. a compromise to consider may be to pass the fill-buffer in as a |
| 19:49.31 | CIA-61 | BRL-CAD: 03Tbrowder 07http://brlcad.org * r2907 10/wiki/Geometry_Service_Project_Main: /* Implementation Particulars */ |
| 19:51.19 | CIA-61 | BRL-CAD: 03brlcad * r44747 10/brlcad/trunk/doc/deprecation.txt: the gnu autotools-based build system was officially deprecated with the release of 7.20, so mark it as such so we can begin to migrate callers properly over the next few months. |
| 19:56.13 | CIA-61 | BRL-CAD: 03brlcad * r44748 10/brlcad/trunk/doc/deprecation.txt: if something is deprecated, presumably there's something better -- point them to it. should include the version it was deprecated on too for when it's marked obsolete. |
| 20:03.15 | CIA-61 | BRL-CAD: 03erikgreenwald * r44749 10/brlcad/trunk/src/fb/ioutil.c: fix missing argument to bu_log and bu_free |
| 20:09.43 | CIA-61 | BRL-CAD: 03brlcad * r44750 10/brlcad/trunk/src/libbu/basename.c: expand bu_basename() support to more closely mimic basename() while ensuring that NULL will not be returned. return '.' for NULL and empty paths like basename() does. |
| 20:10.26 | CIA-61 | BRL-CAD: 03erikgreenwald * r44751 10/brlcad/trunk/src/libbu/brlcad_path.c: free "tmp_basename" instead of stack allocated "buffer". |
| 20:23.25 | CIA-61 | BRL-CAD: 03brlcad * r44752 10/brlcad/trunk/src/libbu/basenametester.c: oop, ac > 1 .. don't prompt by default |
| 20:48.24 | CIA-61 | BRL-CAD: 03starseeker * r44753 10/brlcad/trunk/ (27 files in 26 dirs): Needs more testing, but simplify down the install dir variables. |
| 20:55.58 | CIA-61 | BRL-CAD: 03brlcad * r44754 10/brlcad/trunk/AUTHORS: credit code contribution from kunigami (sf patch 3250116) that improved/fixed bu_basename() to be consistent with basename(). both bhinesley and kunigami made their first contribution back in March. |
| 20:58.42 | CIA-61 | BRL-CAD: 03brlcad * r44755 10/brlcad/trunk/TODO: safer and better performance to avoid the memory allocation on every call, so should consider having the caller pass a buffer in instead of returning one for bu_basename/bu_dirname |
| 21:01.03 | tofu | waves |
| 21:04.43 | CIA-61 | BRL-CAD: 03starseeker * r44756 10/brlcad/trunk/CMakeLists.txt: Minor tweaks to CMakeLists.txt file. |
| 21:11.20 | CIA-61 | BRL-CAD: 03starseeker * r44757 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: Whoops, missed some variable changes. May be more to fix - needs testing. |
| 21:14.46 | CIA-61 | BRL-CAD: 03brlcad * r44758 10/geomcore/trunk/tests/func/GS/CMakeLists.txt: if the geometry engine libs are going to get disabled, then the build targets that use it shouldn't remain enabled |
| 21:19.23 | CIA-61 | BRL-CAD: 03brlcad * r44759 10/geomcore/trunk/tests/unit/CMakeLists.txt: testing a mod to the string interface, but bytebuffer is non-functional, so swap out and enable only the StringUtilsUTest. |
| 21:20.19 | CIA-61 | BRL-CAD: 03brlcad * r44760 10/geomcore/trunk/include/ (FileDataSource.h GeometryChunkMsg.h SvnDataSource.h): remove unused headers from the geometry engine |
| 21:20.24 | bhinesley | brlcad: welcome back |
| 21:20.33 | brlcad | thanks bhinesley |
| 21:20.48 | brlcad | and congrats |
| 21:21.03 | bhinesley | thanks |
| 21:21.26 | CIA-61 | BRL-CAD: 03starseeker * r44761 10/brlcad/trunk/ (3 files in 2 dirs): Go with KDE style lookup for Carbon and Cocoa - much simpler. |
| 21:23.57 | brlcad | (on commit access) |
| 21:23.59 | CIA-61 | BRL-CAD: 03brlcad * r44762 10/geomcore/trunk/ (5 files in 4 dirs): fortunately, there's already a very common name for this type of operation. instead of getLastStepOfPath(), rename to simply basename(). |
| 21:24.10 | brlcad | you and kunigami are good to go, the patches have been fantastic |
| 21:24.47 | brlcad | should no longer be working in isolated silence... daily frequent commits expected ;) |
| 21:26.43 | kunigami_ | cool! For now, I'm still doing experiments that are not ready for commit. Or should I add them as long as they do not break the existing code? |
| 21:26.53 | brlcad | kunigami_: the latter |
| 21:27.24 | bhinesley | oh awesome, thanks! |
| 21:27.32 | brlcad | as long as you don't break the build, you should almost always commit |
| 21:27.49 | brlcad | you cannot commit too frequently |
| 21:29.25 | brlcad | plus it helps give the other devs insight into what you're doing, what you've tried, why you ended up going down a particular dev path, etc |
| 21:30.38 | bhinesley | By "break the build" I'm assuming you mean resulting in it not compiling. Should we still commit if, say, a command is broken? |
| 21:39.44 | CIA-61 | BRL-CAD: 03starseeker * r44763 10/brlcad/trunk/CMakeLists.txt: More minor CMakeLists.txt changes. |
| 21:41.21 | CIA-61 | BRL-CAD: 03brlcad * r44764 10/geomcore/trunk/tests/unit/utility/StringUtilsUTest.cxx: twas different code, don't convert to c string only to convert back to std::string |
| 21:43.16 | starseeker | bhinesley: sure |
| 21:44.19 | CIA-61 | BRL-CAD: 03brlcad * r44765 10/geomcore/trunk/src/utility/StringUtils.cxx: |
| 21:44.19 | CIA-61 | BRL-CAD: de-invent the wheel, refactor to common functionality in libbu. we could call |
| 21:44.19 | CIA-61 | BRL-CAD: basename() directly, but bu_basename() is better reuse and has more safeguards. |
| 21:44.19 | CIA-61 | BRL-CAD: keep the wrapper so callers can keep their pretty std::strings. |
| 21:45.08 | starseeker | brlcad: welcome back! |
| 21:45.18 | starseeker | heh - caught up on sleep did ya? :-P |
| 21:48.41 | brlcad | never really had sleep deprivation (at least no more than usual), in fact I think I've been getting used to MORE sleep than usual |
| 21:49.00 | starseeker | O.o |
| 21:49.11 | starseeker | wow, that's lucky |
| 21:49.12 | brlcad | more just lots going on, traveling, working on the house, taking care of things |
| 21:49.19 | starseeker | nods |
| 21:58.53 | CIA-61 | BRL-CAD: 03starseeker * r44766 10/brlcad/trunk/TODO: Note Archer uses of search need to be updated. |
| 22:19.22 | CIA-61 | BRL-CAD: 03starseeker * r44767 10/brlcad/trunk/CMakeLists.txt: Reorganize distcheck global logic a bit. |
| 22:21.07 | bhinesley | is very glad he has rsnapshot run every 4 hours, because several files were just overwritten |
| 22:52.42 | CIA-61 | BRL-CAD: 03starseeker * r44768 10/brlcad/trunk/CMakeLists.txt: Note that distcheck, as well as target ordering, are related to the command override logic. |
| 23:24.06 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 23:50.38 | brlcad | bhinesley: also why it's important to commit frequently :) |
| 23:51.46 | brlcad | if you're writing code and an hour goes by without a commit, you're probably doing something wrong |
| 23:51.52 | brlcad | not working in smaller incremental steps is the usual fail |
| 23:52.39 | brlcad | if you work incrementally, you can almost commit as frequently as you save a file |
| 23:54.12 | bhinesley | good to knwo |
| 00:01.09 | brlcad | yeah, once you start making a little progress, your commits (and your commit messages) will be just as important if not more important than progress updates .. good stuff |
| 00:01.58 | bhinesley | nods |
| 00:02.03 | bhinesley | there will be a lot going through today |
| 00:10.31 | *** join/#brlcad Stattrav (~Stattrav@117.192.142.216) | |
| 00:10.31 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 00:26.32 | *** join/#brlcad crazy_imp (~mj@a89-182-166-16.net-htp.de) | |
| 01:09.43 | *** join/#brlcad Stattrav (~Stattrav@117.192.142.216) | |
| 01:09.43 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 01:24.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 01:41.07 | CIA-61 | BRL-CAD: 03bhinesley * r44769 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): (log message trimmed) |
| 01:41.07 | CIA-61 | BRL-CAD: This was an incremental step towards: 1) adding the man command to archer 2) |
| 01:41.07 | CIA-61 | BRL-CAD: creating a megawidget for the manual page browser, to eliminate code duplication |
| 01:41.07 | CIA-61 | BRL-CAD: among Archer and MGED. Progress already made on the actual megawidget will be |
| 01:41.07 | CIA-61 | BRL-CAD: added in a bit. |
| 01:41.07 | CIA-61 | BRL-CAD: -Man command now works in Archer |
| 01:41.08 | CIA-61 | BRL-CAD: -Changed the method of adding commands to the Manual Page Browser ToC from "insert end" to using -listvariable as recommended here: http://www.tkdocs.com/tutorial/morewidgets.html |
| 02:44.55 | CIA-61 | BRL-CAD: 03bhinesley * r44770 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Removed doarcherMan, and set Help->Man Pages to call the man command directly |
| 03:22.01 | brlcad | woot |
| 03:31.18 | bhinesley | :-P |
| 03:31.36 | CIA-61 | BRL-CAD: 03brlcad * r44771 10/brlcad/trunk/NEWS: brandon added the 'man' command to archer. |
| 03:33.03 | bhinesley | ah |
| 03:33.19 | bhinesley | shall I make an effort to keep that updated? |
| 03:33.28 | starseeker | it's usually easier |
| 03:33.39 | starseeker | add user-visible stuff |
| 03:34.00 | bhinesley | ok |
| 03:34.52 | starseeker | brlcad: what plans did you have for the architecture of libgcv? I've been reading up on the issue indianla1ry ran into with trying to turn the step-g factory mechanism into a library - the whole "compiler removing static" thing |
| 03:35.12 | starseeker | there appears to be No Good Solution if you stick to straight C++ |
| 03:35.44 | starseeker | not compiler, linker stripping out static rather |
| 03:35.46 | CIA-61 | BRL-CAD: 03brlcad * r44772 10/brlcad/trunk/NEWS: |
| 03:35.47 | CIA-61 | BRL-CAD: brandon also improved the manual page browser gui behavior with improved |
| 03:35.47 | CIA-61 | BRL-CAD: performance (using listbox variable binding instead of adding items manually) |
| 03:35.47 | CIA-61 | BRL-CAD: and adding a ListboxSelect event binding so keys, clicking, and dragging work. |
| 03:36.15 | brlcad | bhinesley: yeah, any time you make a change that is *user* visible, it warrants a one-line entry in the NEWS file |
| 03:37.10 | brlcad | the file has a specific format (described at the bottom) and the commit message per line is important |
| 03:38.01 | starseeker | is getting desperate enough to consider embedding scheme or lisp to escape the limits of C++/C... |
| 03:38.02 | brlcad | the svn log is automatically parsed with a script that pulls each commit message for each feature line which we use to review features, so try to only commit one line at a time and make your commit message as descriptive as needed |
| 03:38.39 | brlcad | starseeker: not sure what you're referring to |
| 03:39.01 | brlcad | step-g's factory mechanism isn't a very good way to do things.. |
| 03:39.18 | starseeker | erm. what's the better way? |
| 03:39.45 | brlcad | first, what's the goal? :) |
| 03:39.45 | starseeker | was under the impression the factory design was the recommend approach to that sort of problem... |
| 03:39.50 | brlcad | factory sure |
| 03:39.57 | brlcad | there's lots of ways to make factory |
| 03:40.06 | bhinesley | brlcad: I'm not sure I follow... you're saying keep commit messages brief? |
| 03:40.32 | starseeker | architect the library in such a way that you can write one file per format, add it to the library without changing anything else, and have the conversion routines be able to find it when some program using the library asks for it |
| 03:40.50 | brlcad | bhinesley: no no, the messages can/should be any details not encoded in the 70-char news line, like why or bug report numbers or who reported a bug or who requested the feature, ets |
| 03:41.09 | bhinesley | oh okay |
| 03:41.13 | brlcad | starseeker: one file per format is probably not feasible |
| 03:41.15 | bhinesley | that's what I figured |
| 03:41.25 | starseeker | growl |
| 03:41.39 | brlcad | i mean, there'd be just one set of function hooks per format |
| 03:41.49 | brlcad | ala src/librt/primitives |
| 03:41.55 | brlcad | but it's a set of funcs that you'd need |
| 03:42.08 | brlcad | probably not just read and write |
| 03:42.26 | brlcad | but even those two, rather different requirements |
| 03:44.30 | brlcad | starseeker: as for the rest (add it to the library without changing anything else, and have the conversion routines be able to find) .. that's pretty easy |
| 03:44.48 | brlcad | even a simple freshman textbook factory implementation will do that |
| 03:45.02 | brlcad | or dynamic loaded library snippets |
| 03:45.42 | starseeker | what's the problem with step-g's implementation then? |
| 03:45.55 | starseeker | I was under the impression indianla1ry designed it fairly carefully |
| 03:46.58 | brlcad | it's using the sdai (app interface) from the step class libraries |
| 03:47.28 | starseeker | I'm not sure that's the reason it wouldn't work as a lib though... |
| 03:47.29 | brlcad | it static-initializes variables, then searches at runtime for those classes |
| 03:47.48 | starseeker | right - most of the C++ Factory discussions I can find do something like that |
| 03:47.55 | brlcad | the problem was there was some compiler (erroneously) optimizing away those static classes so they didn't exist iirc |
| 03:48.08 | brlcad | not the way sdai did it |
| 03:48.14 | brlcad | it was a nit pick detail |
| 03:48.15 | starseeker | shakes his head - that's not a compiler error, according to everything that I can find |
| 03:48.25 | brlcad | the overall approach they intended was 'okay' |
| 03:49.12 | brlcad | it relied on static variable initialization ordering, which isn't guaranteed |
| 03:49.33 | starseeker | http://programmerjoe.com/2007/03/18/the-abstract-factory-pattern-in-c/ |
| 03:49.51 | starseeker | that article mentions the linker stripping out "unreferenced" static variables |
| 03:50.01 | brlcad | they needed to require an init point other than main() (like loading a library or an explicit init() method) |
| 03:51.01 | brlcad | right off the bad, that write-up isn't entirely accurate |
| 03:51.22 | brlcad | lack of an ability to instantiate an object at runtime given the name of a class .. you can, it's just complicated |
| 03:52.29 | starseeker | it must be, I can't find anything so far telling me how to do it |
| 03:52.57 | brlcad | he states the problem: "you won't be referencing these classes and objects directly, so you have to force the linker to include them by adding references" |
| 03:53.32 | brlcad | it's all in how you build up the factory, and there are lots of ways to go about it |
| 03:53.47 | brlcad | sdai's method was a little sucky, but a simple reference fixes the optimization problem |
| 03:54.02 | brlcad | actual code example I wrote a few years ago: https://bzflag.svn.sourceforge.net/svnroot/bzflag/branches/experimental/v2_99continuing/bzflag/src/include/Factory.h |
| 03:55.02 | brlcad | that's the abstract factory, here showing a real factory: https://bzflag.svn.sourceforge.net/svnroot/bzflag/branches/experimental/v2_99continuing/bzflag/src/bzfs/SpawnPolicyFactory.h |
| 03:55.34 | brlcad | and then the 'simple fix' that lets the linker know that you don't want it to optimize away: https://bzflag.svn.sourceforge.net/svnroot/bzflag/branches/experimental/v2_99continuing/bzflag/src/bzfs/SpawnPolicyFactory.cpp |
| 03:55.45 | brlcad | (see the _init() function) |
| 03:56.32 | starseeker | yes |
| 03:56.41 | brlcad | if I wanted to avoid the explicit list of types (which isn't all that bad really, factory lists don't really tend to change that frequently) |
| 03:57.01 | brlcad | I'd just have made loadable library modules, and load / register them all in _init() |
| 03:57.32 | brlcad | think dlopen() style |
| 03:58.02 | starseeker | um... wouldn't that get rather messy if you started to have hundereds of types floating around? |
| 03:58.39 | brlcad | not really, it's still just an entity list |
| 03:58.43 | starseeker | also, is that portable? (loadable library modules) |
| 03:58.56 | brlcad | pretty much, but I'd start with an explicit list |
| 03:59.51 | starseeker | so is that _init call in a library or an executable? |
| 04:00.04 | ``Erik | might be worth seeing how OS's deal with, say, network cards... I think that might be somewhat analogous. FBSD has a set of common functions and some macro fu to 'register' |
| 04:00.18 | brlcad | starseeker: an exectuable in that case, but it could go into a lib too |
| 04:01.53 | brlcad | the libgcv api should get written down first before getting mired in implementation detail like this, issues that might screw up the api if done poorly |
| 04:02.00 | ``Erik | my concern is that different formats hold different kinds of data, so your intermediate format is either a massive superset or a minimal subset :/ |
| 04:02.47 | brlcad | .g or .step are both fairly massive supersets |
| 04:02.55 | brlcad | or at least have arbitrary storage capability |
| 04:03.23 | starseeker | massive superset doesn't worry me - a pivot format in a conversion library of this nature will be conceptually broad of necessity |
| 04:03.33 | brlcad | in-mem .g ftw imnsho ;) |
| 04:03.47 | starseeker | we we need is a technically sound way to manage that complexity and extend it cleanly |
| 04:03.51 | brlcad | that's how most of the code is already written anyways, least effort |
| 04:04.19 | brlcad | best performing too, of known options |
| 04:04.55 | starseeker | if we focus on just what .g supports, yeah that's the simple route. But it means the conversion library will remain special purpose, because there are a LOT of things we don't support now in the .g format |
| 04:04.58 | brlcad | but the api shouldn't care -- it's more "import from X" .. then "export as Y" |
| 04:05.14 | brlcad | using in-mem .g or whatever else is just the in-between implementation detail |
| 04:05.25 | starseeker | sure, but the devil's in the details |
| 04:05.54 | brlcad | nothing says we have to only focus on what .g supports |
| 04:06.11 | brlcad | just need a mechanism for storing and recovering |
| 04:06.16 | starseeker | uh... if we're using .g as the in-mem pivot format... |
| 04:06.17 | brlcad | which .g has |
| 04:06.27 | brlcad | example |
| 04:06.57 | ``Erik | bones, keyframes, animation stuff, programmable definition (povray), ... |
| 04:07.17 | ``Erik | v5 has deficiencies |
| 04:07.30 | brlcad | I can store opengl-style pixel shader information into a .g file along with textures and texture mapping data ... even though brl-cad can't use it |
| 04:08.05 | brlcad | just need to know that's what was stored so when an exporter wants the data, it can pull it |
| 04:08.41 | starseeker | but if you need to convert that to format FOO pixel shader information for three other export formats, where does that logic live? |
| 04:09.02 | ``Erik | you can shove lightwave objects and scenes in an attribute, but without knowledge of the magic black box, conversion is impossible |
| 04:09.05 | starseeker | I doubt we want each exporter to implement all of its own conversion logic for that sort of thing |
| 04:09.12 | starseeker | there will be lots of overlap |
| 04:09.50 | brlcad | starseeker: how's that different than asking "if you need to convert that sphere to format FOO, where does that logic live?" |
| 04:10.01 | brlcad | it lives in format FOO's converter |
| 04:11.22 | brlcad | the only thing an underlying format is going to give you is structure, not necessarily easier access or reduction of export logic |
| 04:11.36 | brlcad | *memory* structure |
| 04:12.25 | brlcad | so .g doesn't have a memory structure for pixel shaders, boo hoo .. don't care really .. libgcv defines a structure and shoves it in, knows the structure, so it can pull it out |
| 04:13.11 | brlcad | this isn't unique to .g in the least .. there's not a single format that doesn't have this issue and would need a similar 'fix' |
| 04:14.22 | brlcad | step would be the closest to being a format that has in-memory structure for almost everything, but it's still NOT everything and you pay for the complexity |
| 04:14.47 | brlcad | can see either working, though, easily enough (step or .g) |
| 04:14.54 | starseeker | 's instinct is that the complexity might be worth paying for... |
| 04:15.36 | brlcad | write a complet g-step and say that again :) |
| 04:16.23 | starseeker | fair enough - but that gets back to trying to understand how to Do It Right - and explicit lists get long fast when we're talking about STEP |
| 04:16.34 | ``Erik | d'no, starseeker... it's not our job to be a zomfg utility conversion toolkit... we do better than most already, but that's a hell of a calling |
| 04:16.48 | brlcad | it's not? :) |
| 04:16.53 | starseeker | ``Erik: I'm not saying we need to be that overnight, but I'd like to architect so that we can grow into that |
| 04:17.04 | brlcad | we do better than everyone at this point (open source) |
| 04:17.37 | starseeker | thinks the best way to get other interests on board is to position ourselves to do it better than ANYONE, closed or open |
| 04:17.50 | brlcad | my thoughts were to leverage existing code as much as possible, because it really is a huge task once you involve more than a couple formats |
| 04:18.38 | ``Erik | some commercial packages do a very impressive job of importing and exporting, but they have tons of resources to throw at satisfying their customers |
| 04:19.06 | brlcad | take the converters main() as they stand now, rewrite them so that stl-g's main is something like stl2g() but the g is opened as an in-mem db and a context is preserved |
| 04:19.12 | starseeker | sure. That's why it's so important we be able to grow incrementally, being clean from the start and gradually expanding our abilities |
| 04:19.36 | brlcad | repeat for all formats, and you have a slew of conversion funcs from files to in-mem .g with very very minimal code change |
| 04:19.40 | CIA-61 | BRL-CAD: 03bhinesley * r44773 10/brlcad/trunk/src/tclscripts/ (archer/Archer.tcl man_browser.tcl pkgIndex.tcl): Added the ManBrowser mega-widget (nonfunctional). This will eliminate code duplication of the Manual Page Browsers among Archer and MGED. |
| 04:20.07 | ``Erik | many conv/ files can be simplified by migrating them to the existing libgcv tesselation functions |
| 04:20.08 | brlcad | register all of those funtions into a table in libgcv and bingo, universal converter |
| 04:20.13 | starseeker | brlcad: My understanding was that we were going to have a lot of code changes anyway as we reduced the duplication of logic during the libgcv conversion |
| 04:20.19 | ``Erik | triangles are a good lcd |
| 04:20.21 | brlcad | ``Erik: yeah they can.... |
| 04:20.26 | brlcad | but it's a royal pita |
| 04:20.32 | brlcad | i've tried a couple times |
| 04:20.52 | ``Erik | I've made an attempt, as well :) |
| 04:20.53 | brlcad | almost all of them have slight tweaks, write out different data at random points in the output, etc |
| 04:21.48 | ``Erik | I threw in a generalized tesselation function into the new stuff I'm doing that'll return a full tree of BoTs, it might be the change we need to migrate |
| 04:22.24 | brlcad | starseeker: ideally, but not necessarily .. reducing the code duplication there is not nearly as trivial as what I described |
| 04:22.58 | brlcad | ``Erik: I saw .. by trying to tessellate from scratch with a different algo... good luck with that ;) |
| 04:23.22 | brlcad | even if it works reliably, that's still 100k lines of code to refactor |
| 04:23.31 | ``Erik | have a working java example, surprisingly small |
| 04:23.32 | brlcad | even if it reduces 10-fold, that's weeks of work |
| 04:23.38 | ``Erik | nmg is just plain horrible |
| 04:23.57 | brlcad | because it guarantees topology |
| 04:24.13 | brlcad | what's the approach you're using do for that? |
| 04:24.27 | ``Erik | there's a trick in the latest approach that kinda surprises me, slicing all intersecting triangles before catagorizing |
| 04:25.16 | ``Erik | the original '86 paper has a whole chain of refinements, UnNBoolean seems to be the latest real example. I think the NMG stuff was originally based on that old '86 paper, then prematurely abstracted and implemented... poorly. |
| 04:25.31 | brlcad | there's only three or four methods I'm aware of that preserve topology |
| 04:26.10 | ``Erik | at the heart, this is still the same approach that nmg was supposed to be |
| 04:26.54 | ``Erik | lee admitted that he didn't know what he was doing and screwed it up, daytona noted that too much information was thrown away at the beginning of the pass, ... *shrug* we'll see |
| 04:27.00 | ``Erik | and I think my cat just farted at me |
| 04:27.28 | brlcad | nmg is the radial-edge method, there's winged-edge, half-edge, quad-edge, doubly linked faces, .. |
| 04:28.37 | ``Erik | most of those assume arbitrary polygons, i'm sticking to pure triangles |
| 04:29.06 | brlcad | I'm not defending nmg as much as saying it's hard to do it while still guaranteeing topology, preserving the manifold property |
| 04:29.36 | ``Erik | http://unbboolean.sourceforge.net/ |
| 04:30.07 | ``Erik | s/N/B/ |
| 04:31.08 | louipc | huh replace N with B? |
| 04:31.33 | ``Erik | yeh, louis, I said unnboolean, shoulda been unbboolean :) |
| 04:31.38 | brlcad | ``Erik: fwiw, the polyhedral paper they reference came *before* radial-edge |
| 04:31.56 | ``Erik | erm, the portugeuse 2008 paper? |
| 04:32.06 | louipc | ah cool |
| 04:32.34 | louipc | new competitions? |
| 04:32.46 | brlcad | by a couple years |
| 04:32.54 | brlcad | he states it: Constructive Solid Geometry for Polyhedral Objects, by D. H. Laidlaw, W. B. Trumbore, and J. F. Hughes |
| 04:33.19 | ``Erik | there's a chain of papers that go from 86 to 08 |
| 04:33.35 | brlcad | the portuguese paper he wrote :) |
| 04:33.38 | CIA-61 | BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2908 10/wiki/User:Bhinesley: /* Log */ Yesterday, today, and plan for tomorrow. |
| 04:34.21 | brlcad | I have trumbore's paper around here somewhere |
| 04:34.35 | brlcad | it's decent, simple |
| 04:35.08 | ``Erik | *grouse* pine frequently crashes on brlcad.org, and mutt won't even run. need to migrate |
| 04:35.12 | brlcad | definitely wouldn't declare the approach better (or worse) |
| 04:35.59 | louipc | what os? |
| 04:36.00 | brlcad | iirc, the method also attempts to preserve manifold, but fails for some n-manifold cases that radial solved |
| 04:36.41 | brlcad | radial solved the problem, but with complexity .. the failure in nmg isn't the method but the implementation |
| 04:38.54 | ``Erik | there seems to be a lot of success with the KISS deviation from what nmg tried, shouldn't take too long to implement and would bump up a couple 9's on success rate for real geometry |
| 04:40.01 | ``Erik | I'll read up on radial edge, but the task as stated is pretty low investment |
| 04:40.48 | brlcad | done again from scratch, I'd probably be looking at winged edge or radial |
| 04:40.58 | brlcad | the bigger issue for CAD is the manifold property |
| 04:41.48 | brlcad | if something has three holes, it should preserve those three holes through conversion, not some other number .. or catastrophic for analysis, turn into a non-manifold |
| 04:42.19 | brlcad | the latter is the biggest problem and the hardest to guarantee without structure |
| 04:44.41 | ``Erik | I'd love to just use nurbs as the intermediary and focus effort now, but several people want visual tesselations to shove in ogl, that's what I'm working towards... not serious interrogation, just quick visualization |
| 04:45.24 | brlcad | except the very next thing they'll want is to dump that to something other than opengl and shoot rays at it, pretending it means something |
| 04:45.29 | brlcad | you know it as well as I |
| 04:47.32 | ``Erik | unfortunately, they'll try... so we call BoT's an approximation and push 'em towards nurbs |
| 04:48.08 | ``Erik | time for sleep, catch ya'll later :) |
| 04:48.16 | brlcad | hey, it's your seconds ticking by |
| 04:48.21 | brlcad | I just think it's a waste of time |
| 04:49.34 | brlcad | and I'll annongly keep saying it .. we should be focusing on robust solid modeling and geometry managemenet |
| 04:50.06 | brlcad | anything else is outside our domain, a distraction, wasted divergent resources and wasted effort |
| 04:50.59 | ``Erik | dude, I agree... I tried to pitch putting my funded time to nurbs... but was told I had to have improved tesselation by the end of the fy, it's on my objectives, need something for accomplishments in late sept... :/ process is screwing product yet again |
| 04:51.51 | louipc | I'd say UI is the most important at this point :P |
| 04:51.55 | brlcad | so give them g-egg ;) |
| 04:52.07 | brlcad | louipc: it is to the community at large |
| 04:52.31 | ``Erik | they were trying to put me on tweaking marching cubes, which is simply wrong for our kind of geometry, so I think I managed a small victory in changing that direction |
| 04:52.37 | brlcad | but not to the elephant contributor that pays to get what they think is most important :) |
| 04:52.53 | louipc | hehe |
| 04:53.07 | louipc | name the price ;) |
| 04:53.54 | ``Erik | after all the overhead (equipment, facilities, mgmt, support staff), I think it's in the neighborhood of 240000usd/year |
| 04:54.01 | brlcad | louipc: nominally, http://www.ohloh.net/p/brlcad/estimated_cost |
| 04:54.58 | brlcad | heh, that's probably missing a digit |
| 04:55.22 | louipc | waow |
| 04:55.59 | brlcad | or did you mean per year per person |
| 04:56.13 | ``Erik | disturbingly, I'm pretty sure that the failbomb upstairs has already cost more than all of BRL-CAD |
| 04:56.17 | ``Erik | I meant per person per year |
| 04:57.28 | ``Erik | so yeh, sleep. hasta la pasta |
| 04:57.43 | louipc | nite |
| 04:57.50 | brlcad | still thinks the easiest path forward is unit testing libbn then libnmg, evaluating robust up the call hierarchy |
| 04:57.56 | brlcad | cheers |
| 05:02.36 | CIA-61 | BRL-CAD: 03brlcad * r44774 10/brlcad/trunk/NEWS: cliff and erik developed a tcl/tk version of isst made available through the cmake build for 64-bit platforms. recommit for docs. |
| 05:02.59 | brlcad | starseeker: did you see the bug report about the bindings? |
| 05:03.25 | brlcad | said both mouse buttons now zoom out, probably related to "zoom out keybinding fixed on Linux/*BSD" made prior to release |
| 05:05.26 | CIA-61 | BRL-CAD: 03brlcad * r44775 10/brlcad/trunk/NEWS: |
| 05:05.26 | CIA-61 | BRL-CAD: cliff fixed the zoom-out mouse binding on linux/bsd that probably stopped |
| 05:05.26 | CIA-61 | BRL-CAD: working after I made a fix for Mac bindings. problem may need revisiting, |
| 05:05.26 | CIA-61 | BRL-CAD: though, becuase there's already a report that both left/right mouse now zoom out |
| 05:05.26 | CIA-61 | BRL-CAD: for some platform. |
| 05:08.45 | CIA-61 | BRL-CAD: 03brlcad * r44776 10/brlcad/trunk/BUGS: both mouse buttons zoom in now on some common platform |
| 05:10.25 | CIA-61 | BRL-CAD: 03brlcad * r44777 10/brlcad/trunk/NEWS: cliff improved the mged 'search' command so you can specify multiple paths now and it will report them appropriately. recommit for docs. |
| 05:13.46 | CIA-61 | BRL-CAD: 03brlcad * r44778 10/brlcad/trunk/NEWS: richard reportedly fixed a segment splitting bug that would affect all tessellation and polygonal conversions. recommit for docs. |
| 05:15.14 | CIA-61 | BRL-CAD: 03brlcad * r44779 10/brlcad/trunk/NEWS: richard fixed a crash that was occuring during facetization/conversion of large models. bad book keeping? recommit for docs. |
| 05:18.03 | CIA-61 | BRL-CAD: 03brlcad * r44780 10/brlcad/trunk/NEWS: bob fixed a bug introduced in asc2g where the new standard attribute logic was causing the color tables and other attribute data to not get converted properly. recommit for docs. |
| 05:20.41 | brlcad | starseeker: "improve path resolution logic for search paths" means what? |
| 05:22.01 | CIA-61 | BRL-CAD: 03brlcad * r44781 10/brlcad/trunk/NEWS: remove items that weren't user-visible. annotate is not yet 'published', attribute standardization is all under the hood, libtie was already announced in 7.18.4 |
| 05:23.18 | CIA-61 | BRL-CAD: 03brlcad * r44782 10/brlcad/trunk/NEWS: cliff added a -q quiet lookup option tot he ls command so that the lookup failure message can be suppressed (particularly important for scripting) |
| 05:28.00 | CIA-61 | BRL-CAD: 03brlcad * r44783 10/brlcad/trunk/NEWS: multiple names separated by commas for parsing, using past tense |
| 05:33.05 | CIA-61 | BRL-CAD: 03brlcad * r44784 10/brlcad/trunk/NEWS: |
| 05:33.05 | CIA-61 | BRL-CAD: cliff and I addressed numerous stability and robustness issues in the red |
| 05:33.05 | CIA-61 | BRL-CAD: command. now should handle standard attributes more consistently, be robust to |
| 05:33.05 | CIA-61 | BRL-CAD: bogus user input, be robust to empty/null input, and correctly preserve values |
| 05:33.06 | CIA-61 | BRL-CAD: creating a copy if the name is changed. |
| 05:40.01 | CIA-61 | BRL-CAD: 03brlcad * r44785 10/brlcad/trunk/NEWS: (log message trimmed) |
| 05:40.02 | CIA-61 | BRL-CAD: previously undocumented keith's modification because the change wasn't expected |
| 05:40.02 | CIA-61 | BRL-CAD: to be user-visible, but it turns out it was (for pixel accurate grazing |
| 05:40.02 | CIA-61 | BRL-CAD: selection), so credit us both for changing the spatial partition traversal |
| 05:40.02 | CIA-61 | BRL-CAD: ordering. keith originally fixed a traversal 'bug' where it was walking cut |
| 05:40.02 | CIA-61 | BRL-CAD: planes something like XYXYXYXYX (missing Z). he changed it to traverse |
| 05:40.03 | CIA-61 | BRL-CAD: YZXYZXYZX, but that caused a different cell to get selected first and |
| 05:44.07 | CIA-61 | BRL-CAD: 03brlcad * r44786 10/brlcad/trunk/NEWS: |
| 05:44.07 | CIA-61 | BRL-CAD: I added a LIBRT_BOT_MINTIE environment variable override that lets the user |
| 05:44.07 | CIA-61 | BRL-CAD: specify at what level libtie is used to evaluate a bot. lets you override |
| 05:44.07 | CIA-61 | BRL-CAD: during database loads affecting subsequent raytrace calls (better suited to |
| 05:44.07 | CIA-61 | BRL-CAD: repeat single-ray shots ala muves). |
| 05:46.00 | CIA-61 | BRL-CAD: 03brlcad * r44787 10/brlcad/trunk/NEWS: cliff changed the search output order to list shallow items prior to deeply nested items. |
| 05:48.20 | CIA-61 | BRL-CAD: 03brlcad * r44788 10/brlcad/trunk/NEWS: cliff extended search's power by adding support for '.' relative path search results where object lists are returned instead of full paths |
| 05:52.34 | CIA-61 | BRL-CAD: 03brlcad * r44789 10/brlcad/trunk/NEWS: |
| 05:52.35 | CIA-61 | BRL-CAD: I added a -f flag to the red command to force overwriting any existing |
| 05:52.35 | CIA-61 | BRL-CAD: combinations. if you run red, change the object name while editing, yet that |
| 05:52.35 | CIA-61 | BRL-CAD: new name already exists, it will abort. with the -f flag, it will overwrite. |
| 05:56.21 | CIA-61 | BRL-CAD: 03brlcad * r44790 10/brlcad/trunk/NEWS: technically, many of our items are verbless clauses as the action verb is implied (usually 'added'). |
| 05:58.43 | CIA-61 | BRL-CAD: 03brlcad * r44791 10/brlcad/trunk/src/tclscripts/ (CMakeLists.txt Makefile.am): add the new man_browser.tcl file to the dist |
| 06:15.46 | CIA-61 | BRL-CAD: 03brlcad * r44792 10/brlcad/trunk/NEWS: reword the intro description with details about the new cmake build and additional reasoning for the migration. |
| 07:30.11 | *** join/#brlcad Stattrav (~Stattrav@117.202.24.91) | |
| 07:30.11 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:08.49 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 08:08.49 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412) | |
| 08:22.01 | *** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 09:17.57 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 09:17.57 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:37.38 | starseeker | brlcad: the search path thing is the whole "make sense out of .././.././" type paths |
| 11:38.13 | starseeker | there's another new zoom bug? I thought the only zoom bug was the one introduced by the mac keybinding change |
| 11:54.07 | starseeker | that report was 7.18.4 - I think thats the mac thing |
| 11:54.28 | starseeker | will check later |
| 12:03.50 | CIA-61 | BRL-CAD: 03davidloman * r44793 10/geomcore/trunk/: Add /Debug to svn:ignore (Build byproduct) |
| 12:06.30 | CIA-61 | BRL-CAD: 03davidloman * r44794 10/geomcore/trunk/src/interfaces/java/: Add /bin to svn:ignore (Build byproduct) |
| 12:45.19 | kunigami_ | hi, do I already have an SVN account for commit? If so, which is my password? |
| 12:49.49 | ``Erik | it's your sourceforge account |
| 12:50.15 | ``Erik | you should have uploaded ssh keys |
| 12:51.28 | kunigami_ | hmm how do I do that? |
| 12:53.36 | ``Erik | log into the web page at sourceforge, click account at the top right, click services, click edit ssh keys |
| 12:54.29 | ``Erik | https://sourceforge.net/apps/trac/sourceforge/wiki/Subversion is the help page for all of that |
| 12:55.02 | ``Erik | (might be able to do https with your sf password, but I think ssh is the recommended route) |
| 12:59.28 | kunigami_ | thank you! I seems that there may be a delay when updating the ssh-keys. I still don't have acess, so I'll wait a bit |
| 13:03.39 | brlcad | starseeker: I must have missed that the report was for 7.18.4 |
| 13:03.55 | brlcad | that would be more promising, I'll follow up |
| 13:04.23 | brlcad | kunigami_: your sf.net username/password should work just fine too |
| 13:05.17 | kunigami_ | I'm getting the following error: |
| 13:05.20 | kunigami_ | svn: Commit blocked by pre-commit hook (exit code 1) with output: |
| 13:06.01 | kunigami_ | <PROTECTED> |
| 13:06.32 | kunigami_ | brlcad/trunk/include/osl-renderer.h : svn:mime-type is not set |
| 13:07.09 | ``Erik | you have to do a propset, it should tell you exactly what to do in the error msg |
| 13:07.39 | kunigami_ | oops. you're right. sorry for that |
| 13:08.57 | ``Erik | http://brlcad.org/wiki/Cvs2svn has an example autoprop file to avoid that in the future |
| 13:13.26 | CIA-61 | BRL-CAD: 03Paydayway 07http://brlcad.org * r2909 10/wiki/Forex_Trading-_How_To_Understand_FOREX_Market_Sentiment: New page: Investors can trade almost any currency in the world. Investors, as individuals, countries, and corporations, may trade in the forex if they have enough financial capital to get started an... |
| 13:13.55 | CIA-61 | BRL-CAD: 03kunigami * r44795 10/brlcad/trunk/ (6 files in 2 dirs): This is my first commit. It adds a ols shader as well as a osl-renderer which by now just sets a color |
| 13:14.12 | ``Erik | w00t, grats |
| 13:14.27 | kunigami_ | yay! cool! |
| 13:25.39 | brlcad | woohoo |
| 13:27.10 | CIA-61 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/protect: protected "[[Forex Trading- How To Understand FOREX Market Sentiment]]": [edit=sysop:move=sysop] |
| 13:27.22 | CIA-61 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 13:27.22 | CIA-61 | BRL-CAD: deleted "[[Forex Trading- How To Understand FOREX Market Sentiment]]": content |
| 13:27.22 | CIA-61 | BRL-CAD: was: 'Investors can trade almost any currency in the world. Investors, as |
| 13:27.22 | CIA-61 | BRL-CAD: individuals, countries, and corporations, may trade in the forex if they have |
| 13:27.22 | CIA-61 | BRL-CAD: enou...' (and the only contributor was |
| 13:27.22 | CIA-61 | BRL-CAD: '[[Special:Contributions/Paydayway|Paydayway]]') |
| 13:27.45 | CIA-61 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Paydayway]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 13:47.39 | ``Erik | brlcad: is sf backend 1.5 now? |
| 13:48.04 | brlcad | kunigami_: http://brlcad.org/wiki/Mime-types |
| 13:48.27 | brlcad | ``Erik: I haven't migrated it, so unless they did for us, probably not |
| 13:48.39 | brlcad | could be something to work on today |
| 13:49.03 | CIA-61 | BRL-CAD: 03kunigami * r44796 10/brlcad/trunk/ (4 files in 2 dirs): Changed .c to .cpp and now I'm exporting the osl-renderer functions so that C code can call them |
| 13:54.25 | CIA-61 | BRL-CAD: 03erikgreenwald * r44797 10/brlcad/trunk/TODO: Remove the LIBRT_BOT_MINTIE task. Bump bottie crash and repo backend to next release. |
| 14:21.43 | brlcad | woot, another logo submission |
| 14:35.45 | CIA-61 | BRL-CAD: 03brlcad * r44798 10/brlcad/trunk/NEWS: |
| 14:35.45 | CIA-61 | BRL-CAD: in retrospect, my addition of the LIBRT_BOT_MINTIE variable was during prep, |
| 14:35.45 | CIA-61 | BRL-CAD: which erik replaced with override during database load, so credit him on the |
| 14:35.45 | CIA-61 | BRL-CAD: change that toggles tie BoT raytrace optimization on/off as an environment |
| 14:35.45 | CIA-61 | BRL-CAD: variable override. |
| 16:03.55 | CIA-61 | BRL-CAD: 03tbrowder2 * r44799 10/brlcad/trunk/NEWS: correct spelling |
| 17:02.52 | *** join/#brlcad Stattrav (~Stattrav@117.192.154.39) | |
| 17:02.52 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:21.43 | kunigami_ | a question regarding the macro BRLCAD_ADDLIB(libname srcs libs) |
| 17:22.25 | kunigami_ | when I pass libs as "abc.dylib;def.dylib" is does not call target_link_libraries |
| 17:23.07 | kunigami_ | but when I pass libs as "abc.dylib def.dylib", that is, replacing ";" for " " , it does call target_link_libraries |
| 17:23.55 | kunigami_ | that's strange because there's a replacement: STRING(REGEX REPLACE " " ";" libslist1 "${libs}") right on the beginning of the macro |
| 17:33.02 | CIA-61 | BRL-CAD: 03tbrowder2 * r44800 10/brlcad/trunk/doc/README.Linux: correct relative path typo for 32-bit configuration |
| 18:33.38 | brlcad | that wasn't a question :) |
| 18:36.27 | kunigami_ | hehe, let me complete :) Is that true or am I missing something? |
| 18:39.48 | brlcad | 'yes' |
| 18:40.08 | brlcad | those aren't mutually exclusive options ;) |
| 18:40.17 | brlcad | that said, sounds like a starseeker question |
| 18:52.00 | CIA-61 | BRL-CAD: 03kunigami * r44801 10/brlcad/trunk/ (5 files in 2 dirs): Moved osl-renderer.h from /include to /src/liboptical. there's no need to such headers to be public |
| 18:55.11 | brlcad | ~kunigami++ |
| 18:55.20 | brlcad | was going to comment on that yesterday |
| 18:56.11 | brlcad | you should also change the #include to be a relative path reference so it's "private" status is clear (e.g., #include "./osl-renderer.h") |
| 18:56.33 | kunigami_ | ok! |
| 18:56.57 | brlcad | kunigami_: have you been able to make a (brl-cad) shader do anything yet? |
| 18:58.15 | kunigami_ | I made the polka dot shader: http://kuniga.files.wordpress.com/2021/05/goblet1.png it's very ugly, but I think I got the idea |
| 19:30.12 | starseeker | ``Erik: were you refering to the kernel module loading process? (kldload and friends?) |
| 20:10.56 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 20:10.56 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412) | |
| 20:11.32 | ``Erik | gets some popcorn |
| 20:13.04 | starseeker | brlcad: I guess it comes down to what we consider immediate needs to be |
| 20:13.15 | brlcad | if dynamic loading becomes desirable, that can be added *very easily* using any number of methods |
| 20:13.47 | brlcad | so what is the immediate need? what is dynamic loading fixing? |
| 20:13.54 | brlcad | (again, forget step-g for a minute) |
| 20:14.40 | starseeker | for me the immediate question is "can we design an API/library that can expand to handle arbitrary geometry files" |
| 20:15.47 | starseeker | step-g aside, it's quite clear there are an awesome number of object times we *potentially* will want/need to convert |
| 20:15.50 | brlcad | case in point .. you can design an *API* to handle arbitrary geometry files with or without dynamic |
| 20:16.07 | starseeker | s/times/types |
| 20:16.46 | starseeker | if the api design can be considered fully independent of the implementation, we can start with the api - I wasn't sure that was a practical reality |
| 20:16.48 | brlcad | right, and if it's going to be "arbitrary", you don't even really know what all the types are |
| 20:17.24 | starseeker | right. which is why flexible and general mechanisms for expanding what types the library can handle are so important |
| 20:17.38 | brlcad | right |
| 20:17.40 | brlcad | but mind you, the API is agnostic to the implementation |
| 20:18.10 | brlcad | the library *architecture* is not necessarily agnostic, as that's basically the implementation detail nuts and bolts |
| 20:18.34 | brlcad | but if you don't have the API nailed down yet, you don't really have a grasp on requirements to be designing architecture anyways |
| 20:18.51 | brlcad | whereas you can easily come up with an architecture that might mess up your API |
| 20:19.08 | brlcad | horse -> cart ;) |
| 20:20.09 | starseeker | was worried that the issue with Factory classes and C++ (which is by no means unique to step-g) meant that a good mechanism for generality might be problematic |
| 20:20.43 | starseeker | hence my interest in learning enough about the approaches to implementing that generality to be sure it wasn't a complete and total blind alley |
| 20:21.13 | brlcad | sure, but that's where a lil knowledge is leading to fear .. there are hundreds of other proof-positive implementations of factories and c++ that do this just fine |
| 20:21.33 | brlcad | and of dynamic loading and of scripted loading and of network loading .... etc |
| 20:23.00 | starseeker | brlcad: the existence of the Apache mod system I guess I can accept as proof that it can be done |
| 20:23.12 | brlcad | if you really want to make it type AWARE and type extensible, that will definitely affect the API |
| 20:23.31 | brlcad | just about every single commercial game loads data modularly ;) |
| 20:23.43 | starseeker | uh... don't we want it to be type aware? |
| 20:23.44 | brlcad | heck, even liboptical does it .. we just don't have any |
| 20:24.15 | brlcad | I haven't thought about an API too much yet (which is really what's needed first), but my inclination would be no |
| 20:24.26 | starseeker | O.o |
| 20:24.31 | brlcad | there are too many entity types, and there will always be some entity type you don't recognize |
| 20:24.44 | brlcad | basically akin to keeping it as a typeless system |
| 20:24.57 | starseeker | so we handle the ones we do recognize, and gracefully fail on the ones we don't |
| 20:25.02 | brlcad | interactors know what they can interact with (and they are types in themselves) |
| 20:25.29 | brlcad | each geometry format module can handle the ones they recognize |
| 20:25.50 | brlcad | we have some abstract way for registering annotated "data" |
| 20:27.00 | starseeker | I guess what I need to do is lay out my notion of an API |
| 20:27.06 | starseeker | maybe that'll clarify it for me |
| 20:27.08 | brlcad | yeah |
| 20:27.54 | brlcad | try to write the public header, or a main() that shows how the API might be used in simple terms |
| 20:28.18 | starseeker | at this point I don't agree that it should be typeless, so I guess I need to run head-first into why it should be |
| 20:28.26 | brlcad | there you answer questions like, do you allow iterating over individual objects |
| 20:28.28 | starseeker | nods - will do |
| 20:28.40 | brlcad | how to deal with hierarchy information |
| 20:28.45 | brlcad | what to do with metadata, etc |
| 20:29.00 | brlcad | "typeless" is being used very loosely here |
| 20:29.45 | brlcad | typeless in the language sense .. if it were C, there wouldn't be a sphere struct; if c++, there would not be a sphere class .. that's what I mean by typeless |
| 20:30.17 | starseeker | yeah... I'm not seeing that, but let me play with the API thing for a day or two and I'll see |
| 20:30.18 | brlcad | there'd be some bundle data saying "I'm a sphere and I have these parameters and these values" |
| 20:31.36 | brlcad | it's the difference between librt reading objects off disk and knowing "this is a sphere entity with some data" and having an actual rt_ell_internal object with sphere data in it |
| 20:32.05 | brlcad | the latter is going to be a veritable hell for a conversion library, and I'd argue probably unnecessary |
| 20:32.42 | starseeker | well, let me crunch on it |
| 20:32.48 | brlcad | it'd just make the library way more complex when you can perform the same work, turn that sph into a set of polygons and write out stl *without* an rt_ell_internal in memory |
| 20:33.00 | starseeker | how? |
| 20:33.26 | brlcad | just like how librt does it now |
| 20:34.04 | starseeker | uh... don't the tessellation routines need to know the details of the sphere? |
| 20:34.51 | brlcad | yep |
| 20:35.01 | brlcad | they don't necessarily need an rt_ell_internal though |
| 20:36.11 | brlcad | data-driven object-oriented design |
| 20:36.31 | brlcad | I think one of my game programming gems has a relevant article, I'll see if I can dig it up |
| 20:37.33 | starseeker | nods - that might be helpful |
| 20:37.47 | starseeker | I'll try and cook up an API |
| 20:40.35 | CIA-61 | BRL-CAD: 03erikgreenwald * r44805 10/brlcad/trunk/ (6 files in 4 dirs): add/use dlfcn wrapper |
| 20:43.57 | CIA-61 | BRL-CAD: 03erikgreenwald * r44806 10/brlcad/trunk/src/liboptical/material.c: remove the HAVE_DLOPEN stuff, since that's handle in bu now |
| 20:45.36 | CIA-61 | BRL-CAD: 03erikgreenwald * r44807 10/brlcad/trunk/src/liboptical/sh_stack.c: more HAVE_DLOPEN removal |
| 20:48.10 | brlcad | starseeker: if you haven't yet, I'd suggest looking briefly into both liboptical and librt, how they deal with extensible types |
| 20:49.02 | brlcad | not what I'd suggest going with for gcv, but they are about as simple as it gets, scalable to hundreds of entities, and should be understood (how their types relate to the *API*) |
| 20:59.36 | CIA-61 | BRL-CAD: 03erikgreenwald * r44808 10/brlcad/trunk/src/libbu/dlfcn.c: take a whack at porting these functions to windows |
| 21:07.32 | CIA-61 | BRL-CAD: 03erikgreenwald * r44809 10/brlcad/trunk/include/bu.h: add dlfcn.h for RTLD_* |
| 21:26.21 | starseeker | hah, cool: http://deviceguru.com/worlds-first-open-source-flashlight/ |
| 21:27.40 | kunigami_ | I'm getting compilation error for material.c -- ‘RTLD_NOW’ undeclared. |
| 21:28.08 | kunigami_ | I'll check later, but that could have been introduced by r44806 |
| 21:28.18 | kunigami_ | I'm off by today |
| 21:28.23 | ``Erik | which os? |
| 21:28.28 | kunigami_ | mac os |
| 21:28.53 | ``Erik | that'd be the one fixed in 44809 :) |
| 21:29.54 | kunigami_ | oops sorry. I did update from src/ dir |
| 21:31.19 | *** join/#brlcad kunigami_ (~kunigami@loco-gw.ic.unicamp.br) | |
| 21:52.11 | *** join/#brlcad crazy_imp (~mj@a89-182-166-16.net-htp.de) | |
| 21:52.46 | CIA-61 | BRL-CAD: 03erikgreenwald * r44810 10/brlcad/trunk/src/ (10 files in 5 dirs): Apple includes stdbool.h in dlfcn.h, so change our various typedefs of bool to their actual type. |
| 22:47.11 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 23:01.17 | ``Erik | aw man, I can't compete in the logo contest? shucks |
| 23:12.13 | CIA-61 | BRL-CAD: 03erikgreenwald * r44811 10/brlcad/trunk/AUTHORS: Keith and Richard probably qualify as developers instead of contributors at this point. |
| 23:30.52 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 00:26.19 | *** join/#brlcad crazy_imp (~mj@a89-182-241-223.net-htp.de) | |
| 00:48.16 | louipc | do I count as a dev? could I compete in the contest? hehe |
| 01:06.32 | CIA-61 | BRL-CAD: 03bhinesley * r44812 10/brlcad/trunk/src/tclscripts/man_browser.tcl: |
| 01:06.32 | CIA-61 | BRL-CAD: Changed ManBrowser mega-widget to inherit from iwidgits::dialog. It now creates |
| 01:06.32 | CIA-61 | BRL-CAD: the window properly, activates, loads the table of contents and |
| 01:06.32 | CIA-61 | BRL-CAD: Introduction.html. Selection binding of the ToC is not working yet. Still some |
| 01:06.33 | CIA-61 | BRL-CAD: cleanup to do. |
| 02:11.29 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 02:11.39 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 02:35.49 | brlcad | ``Erik: no complaints for those two as they're "close enough" but they were still under the measure I've used for others in the list, fwiw |
| 02:39.26 | brlcad | not a hard steadfast rule of course since it's easily fudged, but a couple hundred "significant" commits on the core code for several months sustained is the general rule of thumb |
| 02:40.31 | brlcad | course, with those two in particular, if they were committing properly, they probably would have hit that metric by now |
| 03:55.25 | ``Erik | both are lean on frequency, but indianlarry has provided significant value, and the other needs help to grow beyond old waterfall |
| 03:55.50 | brlcad | certainly |
| 03:56.27 | ``Erik | if you wanna tweak, go for it, I just felt like those two deemed shift |
| 03:56.40 | brlcad | nah, like I said.. they're close enough to the metric I was using |
| 03:57.27 | brlcad | value isn't the metric, though .. a big honkin' awesome 100k patch that makes mged totally awesome would not make one a dev ;) |
| 03:57.36 | ``Erik | aight, then shove your passive aggresiveness :D |
| 03:57.39 | brlcad | more sustained value .. which he has cetainly demonstrated |
| 03:57.53 | brlcad | isn't being passive aggressive |
| 03:58.35 | ``Erik | both need to be more frequent in commits, and I will continue to harangue them |
| 03:58.45 | brlcad | more cautious that we start adding borderline folks, shifting the gray area lower and lower instead of waiting until it's a "well duh they're a dev" |
| 03:58.53 | brlcad | yay |
| 03:59.26 | ``Erik | so how's tesa? missing the idea of sleep yet? ;) |
| 03:59.27 | brlcad | hey even the latter did pretty well with that I noticed.. have a dozen or so major commits to review in my queue |
| 04:00.02 | brlcad | I haven't gotten this much sleep since .. high school |
| 04:00.47 | ``Erik | might wanna reconsider that answer, cuz I'll loan jill a kuhknifh to stab you with ;> *duck* |
| 04:02.01 | brlcad | definitely more interruptions, but nothing so drastic .. lots of drama queens and kings making a big deal out of nothing :) |
| 04:02.25 | ``Erik | aaaanyhow, as youv'e stated, a commit is a statement that can be argued |
| 04:02.50 | brlcad | yeah, it's all good |
| 04:02.56 | ``Erik | half surprised you haven't chimed in on my dlfcn.c tweak |
| 04:03.12 | brlcad | bigger issue is there are a few names on there now that probably don't belong but got grandfathered in |
| 04:03.26 | brlcad | at least with that same metric, but then different times too |
| 04:03.38 | brlcad | dlfcn looked cool, what of it? |
| 04:05.14 | ``Erik | given your discussion with starseeker about dynamically loaded stuff at the time, I imagined... constertation. It's viable given the liboptical and librender dependancies, ... just imagined a bit of fireworks :) |
| 04:05.15 | brlcad | kinda lame failure case (i.e., print "boo hoo") but simple enough to be portable and useful |
| 04:05.45 | brlcad | I don't rant on everything you know :) |
| 04:05.48 | brlcad | sometimes it's all good |
| 04:06.15 | brlcad | so you can't unload a lib on windows? |
| 04:06.35 | brlcad | early osx 10.0 had that same fail |
| 04:06.37 | ``Erik | usually... figured this might stir ya up... no, could not find an unload on winderz |
| 04:07.20 | brlcad | it was a perfect refactor case to boot |
| 04:07.23 | ``Erik | msdn's "see also" had no unload stuff |
| 04:07.33 | brlcad | non-portable code in two places, refactored to one and made portable |
| 04:07.51 | ``Erik | more than 2 |
| 04:07.59 | brlcad | three? |
| 04:08.05 | brlcad | liboptical, render, and ? |
| 04:08.07 | ``Erik | 4, I think |
| 04:08.14 | ``Erik | optical, render, fb, fbed |
| 04:08.31 | brlcad | ah, wasn't aware of the latter to (and didn't notice in the commit) |
| 04:08.36 | brlcad | *two* |
| 04:08.46 | brlcad | that's really stupid for fbed |
| 04:09.09 | brlcad | wtf is fbed dynamically loading? |
| 04:09.21 | ``Erik | grep it. |
| 04:10.24 | ``Erik | or svn diff... you know what to do. |
| 04:11.00 | brlcad | I don't care that much |
| 04:11.40 | brlcad | I had a mail queue over 1000 to work through, if I spent that much time per issue, it'd take months |
| 04:13.19 | brlcad | so curiousity got me, see that it's linking -ldl, but no dl*() function being called .. just bool issue in your commit |
| 04:14.14 | brlcad | er, I take it back, not linking -ldl |
| 04:19.50 | brlcad | meh, doesn't look like it's dynamically loading to me, but no matter |
| 04:40.34 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 04:40.35 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412) | |
| 05:33.38 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 05:33.39 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412) | |
| 07:05.43 | *** join/#brlcad Stattrav (~Stattrav@122.167.241.15) | |
| 07:05.43 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:23.26 | *** join/#brlcad Stattrav (~Stattrav@122.167.241.15) | |
| 07:23.26 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:49.11 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 09:50.08 | *** join/#brlcad Stattrav (~Stattrav@122.167.241.15) | |
| 09:50.08 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:12.02 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:32.10 | ``Erik | brlcad: liboptical and adrt/librender do dynamic loading, but the inclusion of dlfcn.h pulled in stdbool on osX, which caused fbed, fb, and a few others to flip out where we had our own bool defined, so the change cascaded. I'm half thinking of removing dlfcn.h from bu.h, defining our own RTLD_* variables and making a translation table in bu_dlopen(). :/ |
| 11:40.40 | ``Erik | vmath.h is a link dep? I thought it was purely macro and typedef O.o |
| 11:44.54 | ``Erik | yeh, I see no function or global in vmath, it shouldn't be a lib dep |
| 11:46.24 | ``Erik | ah, bunk commit message, it's just more digits on the arse end of M_PI |
| 11:58.07 | dloman | woot!!! Powers back on :) |
| 12:58.01 | CIA-61 | BRL-CAD: 03brlcad * r44817 10/brlcad/trunk/src/libged/combmem.c: HINIT_ZERO instead of VSETALLN() for simplicity |
| 13:03.11 | CIA-61 | BRL-CAD: 03brlcad * r44818 10/brlcad/trunk/doc/deprecation.txt: annotate the recently obsolete items with their entity. time to consider the vmath length constants obsolete too. |
| 13:04.22 | CIA-61 | BRL-CAD: 03brlcad * r44819 10/brlcad/trunk/include/vmath.h: remove ELEMENTS_PER_PT, HVECT_LEN, and HPT_LEN in favor of their more consistent replacements that were added deprecating these in 7.12 |
| 13:05.32 | CIA-61 | BRL-CAD: 03brlcad * r44820 10/brlcad/trunk/Makefile.am: one of the last times the trailing slash issue will make an appearance.. |
| 13:39.02 | CIA-61 | BRL-CAD: 03erikgreenwald * r44821 10/brlcad/trunk/TODO: multiple configuration cmake builds seem to be ok, so strike it. Add the OSX GL/X segfault to things to fix. |
| 13:40.20 | CIA-61 | BRL-CAD: 03brlcad * r44822 10/brlcad/trunk/ (14 files in 6 dirs): remove template comments and unused doxygen file blocks |
| 13:40.24 | CIA-61 | BRL-CAD: 03erikgreenwald * r44823 10/brlcad/trunk/NEWS: note that cmake files will now be included in dist. |
| 13:41.06 | brlcad | ``Erik: yeah, i knew about the bools in fbed and elsewhere |
| 13:41.29 | brlcad | they were on my hit list to eliminate next time stomping through those files |
| 13:42.35 | brlcad | when I said non-portable code in two places, I meant non-portable dynamic loading in two places, refactored to one |
| 13:42.42 | brlcad | that was the awesome goodness |
| 13:49.53 | ``Erik | aight, I don't have a test case to see if my bu_dl* winderz stuff works, do you? |
| 17:08.34 | dloman | Community 'paintball episode' : http://www.youtube.com/watch?v=ivLmfGK6pj4 |
| 17:08.54 | dloman | Community 'D&D Episode' : http://www.youtube.com/watch?v=cVanRXdlfLA |
| 17:25.30 | ``Erik | ringworld anim: http://www.youtube.com/watch?v=sR2296df-bc |
| 17:48.22 | *** join/#brlcad Stattrav (~Stattrav@122.167.241.15) | |
| 17:48.22 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:45.17 | CIA-61 | BRL-CAD: 03bhinesley * r44824 10/brlcad/trunk/src/tclscripts/man_browser.tcl: Fixed ManBrowser mouse binding. The dialog itself is back to business as usual. Now, to fix internal ToC selection (ex: set archerMan [ManBrowser .archerMan]; archerMan configure -selection )... |
| 18:46.01 | bhinesley | bah... didn't escape \$cmdName |
| 18:51.40 | CIA-61 | BRL-CAD: 03kunigami * r44825 10/brlcad/trunk/src/liboptical/ (osl-renderer.cpp osl-renderer.h sh_osl.c): Added support for OSL closure color query. It's crashing though. Maybe due to a memory leak |
| 19:10.47 | CIA-61 | BRL-CAD: 03bhinesley * r44826 10/brlcad/trunk/src/tclscripts/man_browser.tcl: ManBrowser internal ToC selection is working, although a bit differently than originally planned: [ select ls]. |
| 19:11.03 | bhinesley | smacks head |
| 19:11.51 | bhinesley | forgot to escape again |
| 19:20.26 | brlcad | ``Erik: I do, but don't have a windows box to test it on ;) |
| 20:21.02 | *** join/#brlcad mafm (~mafm@19.Red-83-40-127.dynamicIP.rima-tde.net) | |
| 20:51.39 | CIA-61 | BRL-CAD: 03kunigami * r44827 10/brlcad/trunk/misc/CMake/FindOSL.cmake: Just realized that I did not added OSL finder for cmake |
| 21:03.11 | CIA-61 | BRL-CAD: 03erikgreenwald * r44828 10/brlcad/trunk/misc/Makefile.am: add FindOSL.cmake to the dist list |
| 21:21.38 | brlcad | kunigami_: vmath macros ftw |
| 21:21.59 | brlcad | you used them in at least one place, but there looked like other places you can put them to use to reduce code |
| 21:23.37 | kunigami_ | brlcad: ok. I was thinking to refactor the code after making it work |
| 21:26.01 | CIA-61 | BRL-CAD: 03kunigami * r44829 10/brlcad/trunk/misc/CMake/ (FindOIIO.cmake FindOSL.cmake FindOpenEXR.cmake FindTBB.cmake): added three more cmake finders. Also edited Makefile.am this time |
| 21:26.39 | CIA-61 | BRL-CAD: 03kunigami * r44830 10/brlcad/trunk/misc/Makefile.am: ... Also edited Makefile.am this time |
| 21:28.42 | CIA-61 | BRL-CAD: 03kunigami * r44831 10/brlcad/trunk/misc/CMake/util_macros.cmake: This was borrowed from OSL build system. TODO: merge it with BRLCAD util |
| 21:33.38 | brlcad | nods |
| 21:40.18 | CIA-61 | BRL-CAD: 03brlcad * r44832 10/brlcad/trunk/src/liboptical/ (osl-renderer.cpp osl-renderer.h): untested (don't have osl/oiio/boost installed), but should work just fine to use VMOVE for Vec3's too if [] is defined. |
| 21:41.06 | brlcad | that should work, lemme know if it barks |
| 21:42.31 | brlcad | few other code completeness issues, file formatting should match existing style and structure |
| 21:43.35 | brlcad | if you run sh/template.sh on all new files, it'll add the proper header and footer to those files |
| 21:44.08 | brlcad | afterwards, you should similarly be able to run sh/indent.sh and sh/ws.sh to clean up the style |
| 21:45.45 | brlcad | you'll find me harping a lot about maintaining consistent style all the time ... codebases this size require it ;) |
| 21:48.15 | brlcad | also, looks like render_svc file(s) are missing |
| 21:49.55 | CIA-61 | BRL-CAD: 03brlcad * r44833 10/brlcad/trunk/src/liboptical/Makefile.am: |
| 21:49.56 | CIA-61 | BRL-CAD: any new files have to get added to both CMakeLists.txt and Makefile.am for the |
| 21:49.56 | CIA-61 | BRL-CAD: time being while the build system is in transition. at a minimum, list files in |
| 21:49.56 | CIA-61 | BRL-CAD: EXTRA_DIST in the Makefile.am and proper logic in the cmake build. |
| 21:51.21 | CIA-61 | BRL-CAD: 03brlcad * r44834 10/brlcad/trunk/src/liboptical/CMakeLists.txt: render_svc.cpp apparently wasn't added, remove from compile rules |
| 21:51.55 | brlcad | bhinesley: question from one of the archer devs about closedb -- what happens after the db is closed? is another temp db created? |
| 21:52.34 | brlcad | it's of his opinion that it should put archer back into a state like when it was first started with an empty unsaved db |
| 21:52.48 | bhinesley | that's what happens |
| 21:52.53 | bhinesley | I haven't commited that patch yet, though |
| 21:52.56 | brlcad | cool |
| 21:53.06 | brlcad | he was just asking about it today |
| 21:53.21 | brlcad | hadn't looked at the patch yet |
| 21:54.14 | bhinesley | I'm planning on re-reviewing them all and committing sometime this week, if that's alright |
| 21:57.28 | brlcad | sounds perfect |
| 22:01.15 | brlcad | kunigami: is there some technical reason that -Wno-error -no-pedantic were set on the the osl render files? |
| 22:27.30 | *** join/#brlcad Stattrav (~Stattrav@117.192.155.178) | |
| 22:27.30 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 22:29.15 | CIA-61 | BRL-CAD: 03bhinesley * r44835 10/brlcad/trunk/src/tclscripts/ (archer/Archer.tcl man_browser.tcl): (log message trimmed) |
| 22:29.15 | CIA-61 | BRL-CAD: ManBrowser is now ready to be used by Archer and MGED |
| 22:29.15 | CIA-61 | BRL-CAD: Added -disabledPages and -enabledPages to give more control over which commands are displayed. |
| 22:29.15 | CIA-61 | BRL-CAD: Configured constructor to call configbody's with blank args if user didn't configure public variables, in order to trigger defaults. |
| 22:29.16 | CIA-61 | BRL-CAD: Removed \"get\" method, as it doesn't appear to be necessary the way things are done now. |
| 22:29.16 | CIA-61 | BRL-CAD: Renamed cmd/commands etc. variable name components to page/pages, since they're not necessarily commands (ex: Introduction.html). |
| 22:29.17 | CIA-61 | BRL-CAD: Changed regex uses to \[file\] commands. |
| 22:32.37 | bhinesley | There is an -enabledPages option for ManBrowser, which I'd like to populate with a list of commands that are actually available in Archer. Is there a preferred method of getting such a list? |
| 22:33.05 | bhinesley | actually, while we're at it, I'd like to do the same thing for MGED |
| 22:38.19 | brlcad | the best way to do that consistently / maintainably is via libged |
| 22:39.07 | brlcad | there are ways to get the lists via tcl for both, but it's two different ways and would rather suck from an architecture standpoint |
| 22:39.33 | brlcad | libged needs a way to keep a registry of all commands available |
| 22:40.31 | brlcad | have each command register themselves, so when you query, you get the list |
| 22:40.49 | brlcad | would also let you build up built-in commands like 'help' that need access to all commands |
| 22:41.43 | bhinesley | hmm |
| 22:43.13 | bhinesley | I'll look into this |
| 22:44.01 | bhinesley | I was kinda hoping you were going to say "Yes! Here's a variable with the exact list you need!" |
| 22:44.08 | bhinesley | :-P |
| 22:46.18 | brlcad | haha |
| 22:47.14 | brlcad | it's one of the design goals for libged anyways, so might as well work on it now where it's needed |
| 22:47.52 | brlcad | it's also critical for one of the most powerful features on our to-do list, search -exec |
| 22:48.02 | brlcad | major win |
| 22:48.44 | bhinesley | Sounds great. I'm basically set for my first milestone, so I definitely have the time. |
| 22:50.04 | brlcad | if you're making progress on core dev issues like that one, then you're golden :) |
| 22:50.53 | brlcad | even if you spent all summer "getting it perfect" and the milestones went out the window ;) |
| 22:51.19 | bhinesley | good to know |
| 22:51.36 | brlcad | more important that you're having fun and maintainable progress is being made |
| 22:52.44 | brlcad | I can work on stubbing out a basic plugin framework this week if that's next on your plate unless you have some ideas on an approach as well |
| 22:54.26 | bhinesley | it is, and I don't |
| 22:56.16 | brlcad | the design constraints are pretty simple, want to move towards libged being an event-driven modular plugin system, so you'd define a command (e.g., kill) that performs some action (e.g., validates and records delete events); that command is registered with the library (e.g., adds a callback struct to a command array) |
| 22:59.10 | brlcad | the library can then call into any registered command, or iterate over all registered commands and get information (e.g., call a ged_short_help() callback for the 'help' command) and so on |
| 23:00.58 | bhinesley | much easier to keep track of |
| 23:03.43 | bhinesley | "search -exec", like unix "find -exec" I take it |
| 23:03.55 | bhinesley | to run operations on the results |
| 23:05.53 | CIA-61 | BRL-CAD: 03brlcad * r44836 10/brlcad/trunk/include/nmg.h: fill in the remaining available debug bits |
| 23:05.54 | brlcad | exactly |
| 23:06.53 | CIA-61 | BRL-CAD: 03Quattvendypol 07http://compilefarm.org * r2911 10/wiki/Main_Page: |
| 23:06.54 | brlcad | that will likely be one of the single most powerful geometry processing options to get added |
| 23:07.44 | CIA-61 | BRL-CAD: 03Sean 07http://brlcad.org * r2912 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/Quattvendypol|Quattvendypol]] ([[User talk:Quattvendypol|Talk]]); changed back to last version by [[User:Erik|Erik]] |
| 23:07.51 | CIA-61 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Quattvendypol]] with an expiry time of infinite (account creation disabled): Inserting nonsense/gibberish into pages |
| 23:08.30 | CIA-61 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/protect: protected "[[Main Page]]": [edit=sysop:move=sysop] |
| 23:08.53 | CIA-61 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/protect: changed protection level for "[[Main Page]]": [edit=autoconfirmed:move=autoconfirmed] |
| 23:09.22 | CIA-61 | BRL-CAD: 03Sean 07http://brlcad.org * r2915 10/wiki/Main_Page: |
| 23:13.30 | CIA-61 | BRL-CAD: 03brlcad * r44837 10/brlcad/trunk/include/nmg.h: NMG_DANGLING isn't used, but doesn't need to be commented out |
| 23:15.08 | *** join/#brlcad mafm_ (~mafm@19.Red-83-40-127.dynamicIP.rima-tde.net) | |
| 23:15.23 | CIA-61 | BRL-CAD: 03bhinesley * r44838 10/brlcad/trunk/src/tclscripts/man_browser.tcl: Added getBrowser proc to make ManBrowser do the footwork |
| 23:16.50 | CIA-61 | BRL-CAD: 03brlcad * r44839 10/brlcad/trunk/src/burst/plot.c: would be nice to be able to toggle the plotting |
| 23:18.11 | CIA-61 | BRL-CAD: 03bhinesley * r44840 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Removed buildarcherMan function and replaced it with the instantiation of a ManBrowser mega-widget. Removed ::man command logic that is now performed by ManBrowser. |
| 23:21.54 | CIA-61 | BRL-CAD: 03brlcad * r44841 10/brlcad/trunk/include/nmg.h: er, conflicts with raytrace.h -- prefix with NMG_ which they should probably all do anyways |
| 23:22.55 | CIA-61 | BRL-CAD: 03brlcad * r44842 10/brlcad/trunk/src/conv/asc/asc2g.c: dead code elimination. not likely support for these (old bspline geometry) will be implemented any time soon, so remove the unused code instead of exiting. |
| 23:34.43 | CIA-61 | BRL-CAD: 03brlcad * r44843 10/brlcad/trunk/ (5 files in 2 dirs): remove cat-fb because it incurred a maintenance cost. phototypesetting went out of style 20 years ago, obsolete hardware. |
| 23:36.34 | CIA-61 | BRL-CAD: 03brlcad * r44844 10/brlcad/trunk/misc/win32-msvc8/ (Makefile.am cat2fb/): remove the msvc8 build files too |
| 23:36.49 | brlcad | would anyone object if I remove the msvc build files? |
| 23:40.40 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 23:52.08 | starseeker | wouldn't :-P |
| 00:04.42 | CIA-61 | BRL-CAD: 03bhinesley * r44845 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Don't need to keep the window name around, since ManBrowser has getBrowser |
| 00:14.22 | *** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 00:22.30 | CIA-61 | BRL-CAD: 03bhinesley * r44846 10/brlcad/trunk/src/tclscripts/mged/man.tcl: Removed existing MGED man dialog code, inswitching to the ManBrowser mega-widget. Now MGED/Archer Manual page dialogs are identical, but ToC may vary depending on configuration. |
| 00:24.50 | CIA-61 | BRL-CAD: 03bhinesley * r44847 10/brlcad/trunk/NEWS: The manual page browser behavior improvements applied to Archer are now found in MGED as well, since they both use the same ManBrowser mega-widget. |
| 00:26.33 | *** join/#brlcad crazy_imp (~mj@a89-182-190-201.net-htp.de) | |
| 00:32.50 | CIA-61 | BRL-CAD: 03bhinesley * r44848 10/brlcad/trunk/NEWS: removed period from sentence fragment |
| 00:56.33 | CIA-61 | BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2916 10/wiki/User:Bhinesley: /* Log */ Yesterday, today |
| 01:22.10 | starseeker | bhinesley: I can't run archer from build dir: |
| 01:22.21 | starseeker | <PROTECTED> |
| 01:22.21 | starseeker | can't find package ManBrowser 1.0 |
| 01:22.21 | starseeker | ERROR: Unable to load Archer |
| 02:27.30 | *** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 03:00.51 | bhinesley | starseeker:works for me |
| 03:01.00 | bhinesley | anyone else confirm this? |
| 03:01.22 | starseeker | bhinesley: are you doing an out of source directory build? |
| 03:01.28 | bhinesley | yeah |
| 03:02.10 | bhinesley | you mean running archer from the bin directory under the svn trunk? |
| 03:02.44 | starseeker | yeah, uninstalled |
| 03:03.14 | starseeker | not from source dir, but from the build bin dir without anything in the final install location |
| 03:03.18 | bhinesley | I've noticed that it will use the tclscripts that are in your install directory, rather than those in your source directory |
| 03:03.45 | bhinesley | but that was true far before I made any changes |
| 03:03.52 | starseeker | yeah, that's not really avoidable |
| 03:04.16 | starseeker | let me try flushing out my install dir... |
| 03:04.20 | starseeker | rebuilds |
| 03:12.16 | bhinesley | I'm a bit confused though... how would it work uninstalled, since the tclscripts wouldn't be in the install location |
| 03:15.39 | CIA-61 | BRL-CAD: 03starseeker * r44849 10/brlcad/trunk/src/tclscripts/CMakeLists.txt: Add man_browser.tcl to CMakeLists.txt |
| 03:16.08 | starseeker | bhinesley: the CMake build logic goes to some trouble to re-create (functionally, at least) the installed layout in the build dir |
| 03:16.42 | starseeker | including build and install versions of configuration files, if need be |
| 03:17.57 | starseeker | that's what all the extra foo in the BRLCAD_ADDDATA macro is about |
| 03:18.56 | bhinesley | okay... but you just removed man_browser.tcl from the list of tclscripts and added a second menu_override.tcl |
| 03:19.05 | bhinesley | starseeker: what does that achieve? |
| 03:19.21 | starseeker | no - I added man_browser.tcl and re-aligned menu_override.tcl |
| 03:19.36 | starseeker | man_browser.tcl wasn't in that list previously |
| 03:19.47 | bhinesley | oops, forgot to update |
| 03:20.05 | bhinesley | well menu_override is in there twice |
| 03:20.34 | starseeker | ah, whoops |
| 03:21.00 | CIA-61 | BRL-CAD: 03starseeker * r44850 10/brlcad/trunk/src/tclscripts/CMakeLists.txt: only need menu_override.tcl once |
| 03:21.14 | starseeker | there we go |
| 03:21.33 | bhinesley | does it work as expected now? |
| 03:21.36 | starseeker | yep |
| 03:21.40 | starseeker | nice :-) |
| 03:21.47 | bhinesley | cool |
| 03:21.53 | bhinesley | you live you learn |
| 03:22.25 | starseeker | no problem - that's something of a custom feature of our build system, not a "normal" CMake setup |
| 03:22.31 | starseeker | easy fix |
| 03:23.08 | starseeker | really needs to properly document this thing in a writeup... |
| 03:23.24 | starseeker | right after all my other problems go away (sigh) |
| 03:23.28 | bhinesley | haha |
| 03:23.54 | bhinesley | so if I add a file, as far as building goes, is that the only place I need to add it? |
| 03:24.06 | starseeker | for a tclscript? yeah. |
| 03:24.19 | bhinesley | yes, that's all I meant |
| 03:24.22 | starseeker | or in the CMakeLists.txt file in the appropriate subdirectory |
| 03:24.36 | bhinesley | nods |
| 03:25.05 | bhinesley | what time is it for you? |
| 03:25.07 | starseeker | technically we should probably add 'em to the Makefile.am lists, at least until we finally remove the old logic |
| 03:25.15 | starseeker | closing in on 11pm |
| 03:25.55 | starseeker | I lied - closing in on 11:30pm |
| 03:26.01 | bhinesley | ah okay... I wasn't sure if you were a night owl or an early riser :) |
| 03:26.21 | starseeker | night owl by inclination - occasional early riser by necessity |
| 03:26.45 | bhinesley | yeah, me too |
| 03:27.48 | bhinesley | but not tonight ;-) see you later |
| 03:29.05 | starseeker | later |
| 03:38.51 | CIA-61 | BRL-CAD: 03brlcad * r44851 10/brlcad/trunk/src/mged/points/main.c: let both of them work together, wrap in COMPILE_STANDALONE instead of ambiguous if 0 |
| 03:39.46 | CIA-61 | BRL-CAD: 03brlcad * r44852 10/brlcad/trunk/src/mged/points/process.c: key off PRINT_DEBUG instead of 0 |
| 03:52.20 | brlcad | bhinesley: er, and (for the time being) also add new files into the Makefile.am .. parallel build systems until deprecation process is completed |
| 03:53.33 | brlcad | (which you did, I believe) |
| 03:56.44 | CIA-61 | BRL-CAD: 03brlcad * r44853 10/brlcad/trunk/src/mged/points/process.c: quell warning, PRINT_ARRAY, not PRINT_DEBUG |
| 04:03.11 | CIA-61 | BRL-CAD: 03brlcad * r44854 10/brlcad/trunk/NEWS: |
| 04:03.11 | CIA-61 | BRL-CAD: the commit message must be reiterated when lines are edited so that our |
| 04:03.11 | CIA-61 | BRL-CAD: auto-processing of this file will pick up the right (last) comment in reports. |
| 04:03.11 | CIA-61 | BRL-CAD: erik and I added a handful of new cmake build files that were missing from the |
| 04:03.12 | CIA-61 | BRL-CAD: source dist. |
| 04:07.56 | brlcad | bhinesley: NICE |
| 04:08.03 | brlcad | the browser looks fantastic |
| 04:08.24 | brlcad | like the bindings |
| 04:17.16 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 04:19.36 | brlcad | starseeker: am I correct recalling that the cmake build does not produce a unified brlcad lib (brlcad.dll, libbrlcad.so, etc) |
| 04:19.59 | brlcad | because everything would need to compile multiple times |
| 04:49.23 | CIA-61 | BRL-CAD: 03brlcad * r44855 10/brlcad/trunk/ (91 files in 34 dirs): |
| 04:49.24 | CIA-61 | BRL-CAD: A Big Code Deadness Elimination Fest, G. Huzzah... Remove code that is #if 0'd |
| 04:49.24 | CIA-61 | BRL-CAD: out unless there's a comment or some other strong evidence that the code really |
| 04:49.24 | CIA-61 | BRL-CAD: needs to hang around because it's useful, is part of a recent work in progress |
| 04:49.24 | CIA-61 | BRL-CAD: (still should document why it's if 0'd), or is code that is clearly |
| 04:49.24 | CIA-61 | BRL-CAD: demonstrating some useful purpose (beyond "this 'might' be useful some day"). |
| 04:49.25 | CIA-61 | BRL-CAD: Reduction of 2680 lines. |
| 05:05.40 | CIA-61 | BRL-CAD: 03brlcad * r44856 10/brlcad/trunk/doc/deprecation.txt: changes to the spm interface in libbn (to include bn prefix) are minimally impacting changes) |
| 05:08.44 | CIA-61 | BRL-CAD: 03brlcad * r44857 10/brlcad/trunk/doc/deprecation.txt: two more spm macro types getting updated |
| 05:36.03 | CIA-61 | BRL-CAD: 03brlcad * r44858 10/brlcad/trunk/ (8 files in 6 dirs): |
| 05:36.03 | CIA-61 | BRL-CAD: spm functions, types, and macro symbols get the bn prefix added. this makes the |
| 05:36.03 | CIA-61 | BRL-CAD: bn api more self-consistent and easier to identify origination. fortunately, |
| 05:36.03 | CIA-61 | BRL-CAD: minimally impacting too, so just update symbol names accordingly. |
| 06:21.57 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 06:45.50 | *** join/#brlcad Stattrav (~Stattrav@122.167.241.15) | |
| 06:45.50 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:30.33 | *** join/#brlcad Stattrav (~Stattrav@122.167.241.15) | |
| 07:30.33 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:26.51 | *** join/#brlcad mafm_ (~mafm@155.Red-83-40-127.dynamicIP.rima-tde.net) | |
| 08:54.51 | CIA-61 | BRL-CAD: 03d_rossberg * r44859 10/brlcad/trunk/src/libbu/dlfcn.c: made it compile with MSVC |
| 10:05.23 | starseeker | brlcad: correct |
| 10:44.35 | kunigami | brlcad: they were there because I wanted to remove warning flags that were causing compilation errors due to osl headers. I'm now turning them off through cmake parameters. I'll remove them. |
| 11:09.23 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 11:09.36 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:30.13 | CIA-61 | BRL-CAD: 03kunigami * r44860 10/brlcad/trunk/misc/CMake/FindOSL.cmake: Changed FindOSL so that it searches osl libraries from the OSLHOME environment variable (the path was hard-coded before) |
| 11:33.44 | CIA-61 | BRL-CAD: 03kunigami * r44861 10/brlcad/trunk/src/liboptical/ (CMakeLists.txt osl-renderer.cpp): removed unused cpp flags |
| 11:34.35 | CIA-61 | BRL-CAD: 03davidloman * r44862 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: Added some documentation and a try/catch to catch the thrown exceptions. |
| 11:47.26 | brlcad | kunigami: so warnings are disabled or enabled? we should default to fully enabled and accommodate quelling the warnings if at all possible |
| 11:47.47 | brlcad | strict compilation is the golden standard |
| 11:48.49 | brlcad | with a couple auto-generated code (lex/yacc) exceptions where we can't fix them, the entire source code has been made compliant for improved portability, maintainability, security, consistency, etc |
| 11:49.40 | brlcad | also, doesn't that memset() defeat the VMOVE's that immediately preceede it? |
| 12:03.48 | CIA-61 | BRL-CAD: 03davidloman * r44863 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/NetMsgChangeTracker.java: Implement a simple change tracker class with pooling. |
| 12:05.07 | CIA-61 | BRL-CAD: 03davidloman * r44864 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ByteBufferUtils.java: Move ByteBuffer resize functions into ByteBufferUtils |
| 12:08.28 | CIA-61 | BRL-CAD: 03davidloman * r44865 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/utils/: Add a utils package |
| 12:13.11 | CIA-61 | BRL-CAD: 03kunigami * r44866 10/brlcad/trunk/src/liboptical/ (render_svc.cpp render_svc.h): missing files for osl-renderer to compile |
| 12:30.28 | kunigami | brlcad: I can't compile OSL code if I do not use -DBRLCAD-ENABLE_COMPILER_WARNINGS=OFF and -DBRLCAD-ENABLE_STRICT=OFF |
| 12:30.41 | kunigami | I mean link |
| 12:31.52 | CIA-61 | BRL-CAD: 03brlcad * r44867 10/brlcad/trunk/src/librt/ (librt_private.h primitives/ell/ell.c primitives/epa/epa.c): consolidate and move rt_ell_ang() from epa.c to ell.c since it's used by ehy, epa, and hyp. Add to librt_private.h since it's private reuse API. |
| 12:31.56 | CIA-61 | BRL-CAD: 03kunigami * r44868 10/brlcad/trunk/misc/CMake/FindOSL.cmake: Modified FindOSL so that it can find the libraries on linux too |
| 12:34.23 | CIA-61 | BRL-CAD: 03brlcad * r44869 10/brlcad/trunk/src/librt/primitives/ (ehy/ehy.c hyp/hyp.c): no longer need the forward decls for rt_ell_ang() since it's in librt_private.h |
| 12:34.43 | kunigami | brlcad: thanks for spotting that! I'll fix it |
| 12:35.07 | brlcad | kunigami: sure, but what are the warnings |
| 12:35.16 | brlcad | it *should* stop the build |
| 12:35.34 | brlcad | until the source code issues get fixed or accommodated |
| 12:35.43 | brlcad | that's part of the strictness |
| 12:36.09 | brlcad | so the question isn't whether it works or not, it's what's the warning? |
| 12:36.50 | kunigami | ok. I'll run it again to get these warnings |
| 12:36.57 | brlcad | if that can be dealt with (in any fashion) without disabling warnings, then we should if only so that we can compile OUR code with strict reporting |
| 12:37.32 | brlcad | i.e., the code in if_osl.c and osl_renderer.cpp should be strict compliant |
| 12:37.57 | brlcad | it's possible that the warnings can't be squashed, but we should try |
| 12:39.56 | brlcad | also, if you're going to readd new files, make sure you update Makefile.am and CMakeLists.txt so the build isn't broken in the interim :) |
| 12:40.25 | brlcad | trying not to call out too much at once, hopefully not overwhelming -- one bit at a time... :) |
| 12:42.33 | kunigami | I always forget to update Makefile.am! On cmake files I'm trying to maintain them inside ENABLE_OSL code, so that normal builds will keep compiling |
| 12:43.08 | CIA-61 | BRL-CAD: 03brlcad * r44870 10/brlcad/trunk/src/librt/ (5 files in 5 dirs): rename rt_ell_ang() to ell_angle(). it's not public librt API, so it shouldn't have the rt_ prefix. ell_ prefix is appropriate living in ell.c and given what it does. |
| 12:43.58 | brlcad | yeah, I saw that |
| 12:44.14 | brlcad | for Makefile.am, you can keep it simple |
| 12:44.50 | brlcad | since they have all those extra deps and build logic needed, your stuff can just get added to EXTRA_DIST so it's at least in the source tarball |
| 12:45.18 | kunigami | ok! |
| 12:45.22 | brlcad | would be a waste of time to add duplicate build logic to both now that the autotools one is deprecated |
| 12:46.24 | kunigami | wouldn't be better to add those files to Makefile.am only after they are functional? |
| 12:49.07 | brlcad | nope |
| 12:49.35 | brlcad | it will actually halt our ability to make a release |
| 12:50.28 | brlcad | there's a validation check to make sure any file available on checkout is in a source tarball |
| 12:50.52 | kunigami | ok |
| 12:50.53 | brlcad | so all files have to get listed at least as EXTRA_DIST |
| 12:51.08 | brlcad | it won't attempt to compile them as EXTRA_DIST, just adds them to the source tarball |
| 12:51.38 | brlcad | that was a source tarball can still be prepared with autotools, but you'd have to compile with cmake to get the osl shader |
| 12:51.54 | brlcad | which is all good, cmake will be prime within 3 months |
| 12:52.12 | kunigami | perfect |
| 12:55.29 | CIA-61 | BRL-CAD: 03kunigami * r44871 10/brlcad/trunk/src/liboptical/ (Makefile.am osl-renderer.cpp): including added files on EXTRA-DIST |
| 12:55.30 | ``Erik | *readreadread* yeh, I was thinking EXTRA_DIST |
| 12:55.41 | ``Erik | hopefully, cmake will be primary in 3 weeks. |
| 12:58.14 | kunigami | the file in src/other/iwidgets/pkgIndex.tcl seems to be written on building and is versioned |
| 12:59.52 | kunigami | oh I'm confused. I'm able to compile even with strict flags on >.< I'll check if it was not a cache issue |
| 13:01.31 | ``Erik | brlcad: the compile fails he was getting were with the fruity osl headers, it's legit |
| 13:02.05 | ``Erik | (or, the ones he reported a few days back were osl headers, ... I'll shut up and let it unfold here :) ) |
| 13:02.19 | kunigami | haha :) |
| 13:04.08 | ``Erik | starseeker: I'm getting bad memory assertions on winderz from btclsh... I'm not in today, but if you want to borrow my winderz pooter to look into it, be my guest. it's stopping the ampi stuff from doing it's thing. (and I have the spare key, had it on the dash of my truck when I turned around and went home this morning. if I don't see you tomorrow, I'll either leave it on my desk or stop by your place over the weekend) |
| 13:04.35 | starseeker | cool, thanks |
| 13:05.33 | starseeker | growl... Windows Strikes Again... |
| 13:05.39 | ``Erik | (and one of these days, I'll take ya guys to dinner as a danke) |
| 13:05.58 | starseeker | ``Erik: no worries - I owe Bob at least a steak... |
| 13:06.37 | starseeker | kunigami: you might try mentioning OSL header issues to the OSL devs |
| 13:07.03 | ``Erik | yeah, I should probably give bob a bottle of 1800 or something for the tree |
| 13:07.23 | ``Erik | get him spoiled on 'good' stuff :> |
| 13:07.32 | starseeker | heh |
| 13:07.46 | kunigami | starseeker: ok |
| 13:07.50 | ``Erik | mebbe cabo wabo |
| 13:08.28 | brlcad | I don't doubt they were legit, it's whether they can be squashed on our end or not, like we do for other headers that have issues |
| 13:09.43 | kunigami | ouch I just ran cmake inside brlcad source directory and made a mess. Any easier way to cleanup that instead of a clean checking out? |
| 13:09.46 | ``Erik | I still need to look up details on the tnt/jama ... thing. external headers can be a bear :) |
| 13:10.15 | ``Erik | rm -rf CMakeCache.txt CMakeFiles ; find . -name Makefile -or -name CMakeFiles | xargs rm -rf |
| 13:10.23 | brlcad | kunigami: if you ever want to verify the autotools build in addition to the cmake build, this should do it: sh autogen.sh && ./configure --enable-all --enable-warnings --without-ogl && make distcheck |
| 13:10.26 | ``Erik | I think that'll clobber it well |
| 13:10.55 | brlcad | tnt/jama we can fix :) |
| 13:11.28 | brlcad | they're warnings were trivial, but easy edits |
| 13:11.41 | ``Erik | "best practice" is to build out of srcdir... mkdir -p build/auto build/cmake ; (cd build/cmake && cmake ../.. && make) ; sh autogen.sh && (cd build/auto && ../../configure && make) |
| 13:12.12 | brlcad | though in-dir should work too .. just gets messy |
| 13:13.15 | ``Erik | if ya make a mess using out of dir, rm -rf is an easy cleanup :) indir is the trivial case, so of course it should work |
| 13:13.46 | kunigami | I always use a build directory with cmake ../brlcad but if I'm on blcar directory, ../brlcad goes to the source directory. Maybe I should change brlcad-build level :) |
| 13:17.00 | ``Erik | brlcad: what do you think of a toplevel "models" repo? is MoRe a flop? I think I've been volunteered for a small construction project and want to crank a model for verification and materials list... (toddler sandbox) |
| 13:31.19 | *** join/#brlcad kunigami_ (~kunigami@loco-gw.ic.unicamp.br) | |
| 13:31.56 | kunigami_ | Here's the error when compiling with strict: http://pastebin.mozilla.org/1246222 |
| 13:32.37 | kunigami_ | note that most of the errors come from two files I copied from OSL. There's one at oslclosure that is from the library itself |
| 14:19.17 | brlcad | likes to use .build dirs, old gen.sh legacy |
| 14:19.58 | brlcad | more consistent for NFS mounted filesystems too where you have multiple binary builds simultaneously |
| 14:22.58 | brlcad | kunigami: all except the one in oslclosure.h are fixable since they're in our source tree |
| 14:23.09 | brlcad | and since it's just an extraneous ';', it's worth an edit on oslclosure.h too so strict can remain enabled |
| 14:24.37 | brlcad | worth a patch to the osl dev, since it's probably just something overlooked |
| 14:37.20 | CIA-61 | BRL-CAD: 03d_rossberg * r44872 10/brlcad/trunk/src/ (libbn/CMakeLists.txt libbu/CMakeLists.txt): removed a flag that is set in the BRLCAD_ADDLIB macro anyway |
| 14:41.55 | CIA-61 | BRL-CAD: 03d_rossberg * r44873 10/brlcad/trunk/src/other/libz/CMakeLists.txt: now there will be build a static zlib library too if the BUILD_STATIC_LIBS flag is set |
| 14:45.40 | kunigami | brlcad: ok! |
| 14:50.00 | ``Erik | huh, jra called |
| 15:46.08 | *** join/#brlcad Stattrav (~Stattrav@117.192.136.249) | |
| 15:46.08 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:53.50 | dloman | jra? Where is he now... Florida? |
| 16:15.57 | *** join/#brlcad Stattrav (~Stattrav@117.192.143.183) | |
| 16:15.57 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:23.48 | CIA-61 | BRL-CAD: 03kunigami * r44874 10/brlcad/trunk/src/liboptical/CMakeLists.txt: Modified CMakeLists. Libraries paths are not hard-coded anymore |
| 17:18.34 | ``Erik | he's still local, he has grandkids in the area |
| 17:18.52 | ``Erik | he noted your abdication, dlo |
| 18:24.21 | *** join/#brlcad mafm_ (~mafm@155.Red-83-40-127.dynamicIP.rima-tde.net) | |
| 18:34.00 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 21:43.25 | dloman | brlcad: was in your neighborhood today and saw this: http://i56.tinypic.com/2e0iog0.png and figured I'd let you know that a cop might stop you since the car seat isn't facing backwards. Just a heads up. |
| 21:44.41 | dloman | =D |
| 21:57.35 | CIA-61 | BRL-CAD: 03bhinesley * r44875 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: ManBrowser window naming collision is no longer a factor; renamed window. |
| 23:26.14 | *** join/#brlcad mafm (~mafm@155.Red-83-40-127.dynamicIP.rima-tde.net) | |
| 00:26.47 | *** join/#brlcad crazy_imp (~mj@a89-182-155-87.net-htp.de) | |
| 01:27.36 | bhinesley | I'm getting a compile error with cmake: http://pastebin.mozilla.org/1246735 |
| 01:27.46 | bhinesley | glu.h doesn't exist |
| 01:40.13 | bhinesley | I disabled GL, and was able to compile. |
| 02:08.05 | bhinesley | disregard... I cleaned the build directory and it's working with GL enabled now, too. |
| 02:17.02 | CIA-61 | BRL-CAD: 03bhinesley * r44876 10/brlcad/trunk/src/proc-db/sketch.c: Applied patch 3247828, submitted by myself. Fixed sketch usage statment so that it isn't always printed, and clarified the output when an argument is mistakenly provided |
| 02:40.11 | brlcad | dloman: hehe |
| 02:40.16 | brlcad | where'd that pic come from? |
| 02:43.49 | CIA-61 | BRL-CAD: 03bhinesley * r44877 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: |
| 02:43.49 | CIA-61 | BRL-CAD: Applied patch 3309910, submitted by myself. It makes Archer's opendb command |
| 02:43.49 | CIA-61 | BRL-CAD: behave like more mged when no arguments are supplied. It prints the database |
| 02:43.49 | CIA-61 | BRL-CAD: name if it is in memory only, or it prints the path to and name of the database |
| 02:43.49 | CIA-61 | BRL-CAD: if it is saved on disk. |
| 02:50.03 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 02:50.09 | CIA-61 | BRL-CAD: 03bhinesley * r44878 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Applied patch 3309107, submitted by myself. It adds a closedb command to Archer, which simply loads an empty database in memory, like when Archer is first started. |
| 02:57.57 | CIA-61 | BRL-CAD: 03bhinesley * r44879 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Applied patch 3267991, submitted by myself. The commands 'q' and 'exit' are already available in Archer; this adds the 'quit' synonym. |
| 02:59.20 | CIA-61 | BRL-CAD: 03brlcad * r44880 10/brlcad/trunk/NEWS: bhinesley made Archer's opendb command behave like mged when no arguments are supplied. It prints the name if the database is in memory only, or it prints the absolute path if the database is saved on disk. |
| 03:00.28 | CIA-61 | BRL-CAD: 03brlcad * r44881 10/brlcad/trunk/BUGS: opening a database with the same name as a command (in archer) reportedly (by bhinesley) doesn't work |
| 03:01.33 | CIA-61 | BRL-CAD: 03brlcad * r44882 10/brlcad/trunk/NEWS: bhinesley added the missing closedb command to archer as well, calls Load '' which closes the current database and opens an empty one like when archer first starts up. |
| 03:17.46 | CIA-61 | BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2917 10/wiki/User:Bhinesley: /* Log */ today, and plan tomorrow |
| 03:33.51 | *** part/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 06:52.01 | *** join/#brlcad Stattrav (~Stattrav@122.167.241.15) | |
| 06:52.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:17.03 | *** join/#brlcad mafm (~mafm@183.Red-81-32-97.dynamicIP.rima-tde.net) | |
| 09:29.44 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 09:29.44 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:00.55 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 15:00.55 | *** join/#brlcad mafm (~mafm@183.Red-81-32-97.dynamicIP.rima-tde.net) | |
| 15:25.00 | *** join/#brlcad Stattrav (~Stattrav@122.172.247.68) | |
| 15:25.00 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:09.35 | brlcad | mm, some nice features coming in the subversion 1.7 update |
| 16:23.32 | CIA-61 | BRL-CAD: 03brlcad * r44883 10/brlcad/trunk/ (42 files in 25 dirs): convert about 180 calls to NEAR_ZERO() to NEAR_EQUAL() where the intent seems (via the a - b = 0 trick) to be comparing for equality. improves readability. |
| 16:24.07 | starseeker | brlcad: are they close to releasing 1.7? |
| 16:28.02 | CIA-61 | BRL-CAD: 03brlcad * r44884 10/brlcad/trunk/doc/deprecation.txt: BU_EXTERN and BU_ARGS are pre-c89 accommodations, no longer needed and minimally impacting to remove them |
| 16:42.18 | CIA-61 | BRL-CAD: 03brlcad * r44885 10/brlcad/trunk/doc/deprecation.txt: BU_EXTERN() is a macro and a bit more tricky to isolate properly, but still minimally impacting. |
| 16:48.39 | CIA-61 | BRL-CAD: 03starseeker * r44886 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Archer's use of the search command needed updating after the syntax change - fixed highlighting of related items in Archer. |
| 16:51.35 | CIA-61 | BRL-CAD: 03starseeker * r44887 10/brlcad/trunk/NEWS: |
| 16:51.36 | CIA-61 | BRL-CAD: Archer's tree widget can optionally highlight combinations that would be |
| 16:51.36 | CIA-61 | BRL-CAD: impacted by the editing of the currently selected component - that feature |
| 16:51.36 | CIA-61 | BRL-CAD: relied on search, and the syntax change threw it off. Fixed syntax, behavior |
| 16:51.36 | CIA-61 | BRL-CAD: restored. |
| 17:09.15 | CIA-61 | BRL-CAD: 03brlcad * r44888 10/brlcad/trunk/doc/deprecation.txt: have been using emacs syntax to date, but change over to perl syntax so we can easily show users how to apply a minimally impacting regex to their file(s) |
| 17:15.27 | CIA-61 | BRL-CAD: 03brlcad * r44889 10/brlcad/trunk/doc/deprecation.txt: untested, but this should swap them from emacs regexp quoting to perl quoting |
| 17:17.17 | CIA-61 | BRL-CAD: 03brlcad * r44890 10/brlcad/trunk/doc/deprecation.txt: meant slurp mode, not code 7 |
| 17:34.49 | *** join/#brlcad mafm (~mafm@193.153.199.74) | |
| 17:44.24 | bhinesley | starseeker: You said that it's possible to run Archer from the build directory uninstalled... but it's still using the installed tcl scripts for me. What's the trick? |
| 17:45.04 | bhinesley | I did a cmake build out of the source directory |
| 17:46.26 | bhinesley | *outside of |
| 17:50.36 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 17:50.36 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:15.58 | starseeker | bhinesley: if you have an installed BRL-CAD in the same directory as your CMAKE_INSTALL_PREFIX, BRL-CAD will look there first for dat |
| 18:16.01 | starseeker | data even |
| 18:16.16 | bhinesley | oh, alright :) |
| 18:16.37 | starseeker | you can either a) re-build BRL-CAD with CMAKE_INSTALL_PREFIX set to a directory where there is no BRL-CAD or b) remove the installed version |
| 18:16.46 | starseeker | I get bit by that once in a while too |
| 18:17.18 | ``Erik | starseeker: "Consider a Spherical Cow: A Course in Environmental Problem Solving" by John Harte ( http://en.wikipedia.org/wiki/Spherical_cow ) |
| 18:17.19 | bhinesley | anything to save time testing |
| 18:17.20 | starseeker | usually what I'll do is pass -DCMAKE_BUILD_TYPE=Debug - that sets the install directory to ../brlcad-install relative to the build directory (IIRC) |
| 18:17.31 | starseeker | ``Erik: heh, yep :-) |
| 18:18.00 | starseeker | bhinesley: then, as long as you don't have the brlcad-install actually installed, you can run successfully from the build directory |
| 18:18.13 | starseeker | or brlcad-install actually populated rather |
| 18:18.39 | bhinesley | alright, I'll give that a go |
| 18:18.40 | ``Erik | "wanted dead or alive: schrödinger's cat" |
| 18:19.00 | starseeker | <snort> I think that's wanted dead AND alive :-O |
| 18:19.12 | starseeker | :-P |
| 18:19.37 | ``Erik | "a seminar on time travel will be held two weeks ago" |
| 18:19.45 | ``Erik | there's pretty corny :D |
| 18:20.04 | starseeker | sooo... you found the bottom of the internet? :-P |
| 18:20.20 | ``Erik | it's not as bad as /b/ |
| 18:23.11 | *** join/#brlcad athena0 (~ed@ppp-70-226-169-88.dsl.mdsnwi.ameritech.net) | |
| 18:26.48 | starseeker | hmm - an auction company in Dallas, TX called Heritage Auctions is selling dinosaur skeletons |
| 18:27.00 | starseeker | just the thing to put up in the living room :-P |
| 18:27.29 | starseeker | (talk about an efficient way to scare little kids...) |
| 18:29.36 | bhinesley | psh... not my kids. They'd be all over it. |
| 18:36.29 | athena0 | I'm having a brain-fart... brlcad is complaining about a missing library before compile, and I can't seem to resolve it. |
| 18:36.46 | athena0 | $ grep "Xi library" config.log |
| 18:36.53 | athena0 | configure:28705: WARNING: X11 support is enabled but the Xi library was not found. |
| 18:37.00 | bhinesley | mesagl, I believe |
| 18:37.09 | bhinesley | hold on |
| 18:37.16 | athena0 | $ sudo aptitude search libxi | grep "X11 Input" |
| 18:37.21 | athena0 | i libxi-dev - X11 Input extension library (development h |
| 18:37.30 | athena0 | i libxi6 - X11 Input extension library |
| 18:37.38 | athena0 | p libxi6-dbg - X11 Input extension library (debug package |
| 18:38.11 | athena0 | Have I forgotten something obvious here? |
| 18:42.47 | *** join/#brlcad EricZZZ (~EricZZZ@ppp-70-226-169-88.dsl.mdsnwi.ameritech.net) | |
| 18:44.17 | bhinesley | athena0: I'm pretty sure there is a mesa library missing, but I'm having trouble proving that. |
| 18:44.29 | bhinesley | I've had that warning before |
| 18:46.22 | athena0 | I don't suppose there'd be any harm in just installing xlibmesa-gl and xlibmesa-gl-dev and giving it another shot |
| 18:46.36 | bhinesley | nods |
| 18:46.39 | bhinesley | sorry I can't say for sure |
| 18:52.45 | *** part/#brlcad bhinesley (~bhinesley@99.144.90.118) | |
| 18:52.51 | *** join/#brlcad bhinesley (~bhinesley@99.144.90.118) | |
| 18:53.55 | athena0 | Arg. No dice. Still complaining about Xi library not found |
| 18:54.12 | bhinesley | athena0: Yeah, I see it now. The message is coming from configure.ac:1220 |
| 18:54.18 | bhinesley | libxi, allegedly |
| 18:55.00 | bhinesley | so maybe you need to do a "make clean" or something |
| 18:56.10 | athena0 | Worth a shot. ... |
| 18:57.23 | athena0 | No, still complaining during ./configure after a make clean |
| 18:57.37 | bhinesley | :-/ |
| 18:58.33 | athena0 | My system seems pretty convinced it's got the libxi packages. Any chance it's just hid them away in some strange directory structure? Maybe this could be solved with a well-placed "ln -s" |
| 19:01.36 | bhinesley | do a `sudo updatdb && locate libXi.so` |
| 19:01.45 | bhinesley | mine are in /usr/lib and /usr/lib64 |
| 19:03.39 | CIA-61 | BRL-CAD: 03kunigami * r44891 10/brlcad/trunk/src/liboptical/ (5 files): Discovered that OSLRender only leaks memory if called by sh_osl. I've copied the osl raytracer into osl_rt in such a way that it calls OSLRender class. Valgrind did not identified the memory leaks present in the rt run |
| 19:03.54 | athena0 | $ sudo updatedb && locate libXi.so |
| 19:04.16 | athena0 | <PROTECTED> |
| 19:04.21 | athena0 | <PROTECTED> |
| 19:04.27 | athena0 | <PROTECTED> |
| 19:13.14 | bhinesley | athena0: do you have libx11-dev installed? |
| 19:16.07 | athena0 | Yep. |
| 19:16.08 | athena0 | $ sudo updatedb && locate libx11-dev |
| 19:16.12 | athena0 | <PROTECTED> |
| 19:16.49 | athena0 | (output truncated ...) |
| 19:17.03 | bhinesley | yeah, I believe ya |
| 19:19.41 | athena0 | Would it be possible for the .deb file available for download to work on my machine when the source doesn't look like it's going to compile? |
| 19:20.08 | bhinesley | yeah |
| 19:20.24 | athena0 | ah. Then I'm gonna give that a shot. |
| 19:21.01 | bhinesley | good idea :) |
| 19:44.22 | CIA-61 | BRL-CAD: 03bhinesley * r44892 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl CombEditFrame.tcl): |
| 19:44.22 | CIA-61 | BRL-CAD: Adding '-sorted' to lsearch's in few places where it's clear that the given list |
| 19:44.22 | CIA-61 | BRL-CAD: was A) sorted '-increasing' B) sorted as ASCII text C) was not modified before |
| 19:44.22 | CIA-61 | BRL-CAD: the search D) not sorted with any of '-all'/'-not'/'-glob'/'-regexp'. This |
| 19:44.22 | CIA-61 | BRL-CAD: option results in increased performance, since it forces lsearch to do a binary |
| 19:44.22 | CIA-61 | BRL-CAD: search, rather than the default linear search. |
| 19:44.23 | CIA-61 | BRL-CAD: Of all 58 instances of lsort in BRL-CAD tcl scripts that were inspected, only 3 obvious cases of missing 'lsearch -sorted' options were found following them. |
| 20:00.57 | *** join/#brlcad roberthl (~robert@v1.rhl.me.uk) | |
| 20:00.57 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 20:04.24 | athena0 | Seems to work! |
| 20:04.45 | athena0 | bhinesley: Thanks very much for your help. |
| 20:05.14 | bhinesley | athena0: no problem, I wish could have helped more |
| 20:10.40 | *** join/#brlcad Stattrav (~Stattrav@117.192.142.11) | |
| 20:10.40 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:21.58 | CIA-61 | BRL-CAD: 03bhinesley * r44893 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Realigned the definition of mArcherCoreCommands, which was getting a little out of hand |
| 20:47.31 | CIA-61 | BRL-CAD: 03bhinesley * r44894 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Indented a multi-line string. |
| 21:03.21 | CIA-61 | BRL-CAD: 03starseeker * r44895 10/brlcad/trunk/TODO: Archer search usage fixed, note problems being seen with rtwizard. |
| 21:05.58 | starseeker | I think with that can't find Xi libs thing you might to call out the x11 location using --with-x11 or some such... I ran into something similar once. |
| 21:06.07 | starseeker | wonder if CMake build would have worked |
| 21:07.35 | starseeker | really needs to have another go at getting RamDebugger running and see if it would help the Tcl/Tk development process... |
| 21:10.51 | bhinesley | starseeker: I had the problem once before too, but I can't remember what I did. I thought it was due it some package I installed, because once it was fixed it never came back. |
| 21:12.50 | bhinesley | RamDebugger looks neat |
| 21:17.51 | starseeker | bhinesley: heh - don't be tempted to waste too much time on it though - I have a feeling getting it working with BRL-CAD could be a bit of a trick |
| 21:18.30 | bhinesley | I'm sure |
| 21:19.44 | starseeker | I'd have to start by hooking it all into our CMake tclscripts logic, and then fixing whatever needs fixing |
| 21:19.56 | starseeker | and figure out which pieces (e.g. tkcvs) we could ditch |
| 21:20.27 | bhinesley | Speaking of which, is there any chance of distcc working? I've tried, but it complained that it wasn't a valid compiler. |
| 21:20.57 | bhinesley | it worked alright with automake |
| 21:21.13 | starseeker | urm |
| 21:22.20 | bhinesley | not that it's a big deal :) |
| 21:22.32 | starseeker | looking over CMake list archives... |
| 21:22.57 | starseeker | CC=distcc gcc" cmake ../brlcad ? |
| 21:23.13 | bhinesley | yeah, it dies |
| 21:23.25 | starseeker | dies how? |
| 21:23.54 | bhinesley | something about distcc not passing compiler checks... I'll try it again in a bit and let you know. I'm doing another build right now. |
| 21:24.06 | starseeker | huh. k |
| 21:24.50 | starseeker | looks like distcc has come up before: http://www.cmake.org/pipermail/cmake/2008-January/019292.html |
| 21:35.03 | bhinesley | starseeker: http://pastebin.mozilla.org/1247430 |
| 21:35.33 | starseeker | erm. distcc works in isolation? |
| 21:36.01 | bhinesley | it uses gcc/g++ |
| 21:36.19 | starseeker | I mean if you run the line # |
| 21:36.20 | starseeker | I mean if you run the line /usr/bin/distcc gcc -o CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o -c |
| 21:36.23 | starseeker | # /home/bhinesley/brlcad-trunk/build/cmake-withogl-distcc/CMakeFiles/CMakeTmp/testCCompiler.c |
| 21:36.47 | starseeker | and then linke it: # |
| 21:36.47 | starseeker | and then linke it: /usr/bin/distcc gcc CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o -o |
| 21:36.50 | starseeker | # cmTryCompileExec -rdynamic |
| 21:36.54 | starseeker | er link it even |
| 21:38.00 | bhinesley | I'm not sure if the "gcc" is supposed to be there or not |
| 21:38.49 | starseeker | bhinesley: maybe not - I'd experiment with it "in isolation" to make sure you can get it to work, first |
| 21:42.22 | bhinesley | oh, I see what you mean |
| 21:44.41 | starseeker | hrm... looks like tktreectrl would need a CMake build file... |
| 21:44.47 | starseeker | fights the temptation... |
| 22:03.33 | bhinesley | what does the debug flag do besides change the install directory? |
| 22:50.27 | *** join/#brlcad Yoshi47 (~jan@d72-39-60-53.home1.cgocable.net) | |
| 23:07.27 | starseeker | bhinesley: adds -g flag, few other compiler flags |
| 23:19.11 | *** join/#brlcad mafm (~mafm@95.Red-88-22-160.staticIP.rima-tde.net) | |
| 23:32.58 | CIA-61 | BRL-CAD: 03brlcad * r44896 10/brlcad/trunk/ (10 files in 6 dirs): stop using BU_ARGS, just list the arguments. c89/posix lets us move forward. |
| 23:50.15 | *** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 00:27.03 | *** join/#brlcad crazy_imp (~mj@a89-182-246-204.net-htp.de) | |
| 01:06.45 | CIA-61 | BRL-CAD: 03brlcad * r44897 10/brlcad/trunk/doc/deprecation.txt: space is optional |
| 01:23.31 | CIA-61 | BRL-CAD: 03brlcad * r44898 10/brlcad/trunk/ (12 files in 4 dirs): remaining removal of BU_ARGS. poof. |
| 01:33.37 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177726205.dsl.bell.ca) | |
| 03:54.16 | CIA-61 | BRL-CAD: 03brlcad * r44899 10/brlcad/trunk/include/bu.h: ws cleanup |
| 04:40.00 | CIA-61 | BRL-CAD: 03brlcad * r44900 10/brlcad/trunk/ (18 files in 5 dirs): ws consistency cleanup of affected files |
| 04:52.39 | CIA-61 | BRL-CAD: 03brlcad * r44901 10/brlcad/trunk/src/librt/db_open.c: revert back to r43023 .. unintentionally caught up in ws commit. |
| 04:54.12 | CIA-61 | BRL-CAD: 03brlcad * r44902 10/brlcad/trunk/src/librt/db_open.c: ws cleanup |
| 04:57.33 | CIA-61 | BRL-CAD: 03brlcad * r44903 10/brlcad/trunk/src/librt/db_open.c: document why dynamic memory is being allocated here. also, search the database dir before the current dir when looking for resources. less likely to pick up random unintentional files. |
| 05:39.40 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:27.48 | *** join/#brlcad Stattrav (~Stattrav@117.192.140.12) | |
| 07:27.48 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:20.08 | *** join/#brlcad mafm (~mafm@26.Red-88-11-185.dynamicIP.rima-tde.net) | |
| 09:31.47 | *** join/#brlcad Stattrav (~Stattrav@117.192.140.12) | |
| 09:31.49 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:42.39 | *** join/#brlcad mafm_ (~mafm@26.Red-88-11-185.dynamicIP.rima-tde.net) | |
| 14:35.16 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:07.22 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:44.13 | *** join/#brlcad Stattrav (~Stattrav@117.192.157.26) | |
| 18:44.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:50.33 | *** join/#brlcad Stattrav (~Stattrav@117.192.157.26) | |
| 18:50.34 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:58.53 | *** join/#brlcad Stattrav (~Stattrav@117.192.157.26) | |
| 18:58.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:07.12 | *** join/#brlcad Stattrav (~Stattrav@117.192.157.26) | |
| 19:07.14 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:15.43 | *** join/#brlcad Stattrav (~Stattrav@117.192.157.26) | |
| 19:15.45 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:23.39 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:33.47 | *** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 21:08.03 | *** join/#brlcad Stattrav (~Stattrav@117.192.157.26) | |
| 21:08.03 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 00:27.15 | *** join/#brlcad crazy_imp (~mj@a89-182-141-188.net-htp.de) | |
| 07:05.29 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.146) | |
| 07:05.29 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:29.38 | *** join/#brlcad poolio_ (~poolio@BZ.BZFLAG.BZ) | |
| 07:33.42 | *** join/#brlcad roberthl_ (~robert@v1.rhl.me.uk) | |
| 07:43.01 | *** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no) | |
| 07:43.22 | *** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 07:43.32 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 07:43.51 | *** join/#brlcad crazy_imp (~mj@a89-182-141-188.net-htp.de) | |
| 07:43.51 | *** join/#brlcad vtts_ (~vytautas@diz.ktu.lt) | |
| 07:43.51 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:43.51 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 07:43.51 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 07:44.15 | *** join/#brlcad mafm_ (~mafm@26.Red-88-11-185.dynamicIP.rima-tde.net) | |
| 07:44.15 | *** join/#brlcad bhinesley (~bhinesley@99.144.90.118) | |
| 07:44.15 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 07:44.15 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 07:44.30 | *** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 07:44.30 | *** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ) | |
| 07:44.30 | *** join/#brlcad dtidrow (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) | |
| 07:49.42 | *** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 07:49.54 | *** join/#brlcad crazy_imp (~mj@a89-182-141-188.net-htp.de) | |
| 07:57.30 | *** join/#brlcad roberthl (~robert@v1.rhl.me.uk) | |
| 07:57.30 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 08:04.20 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 08:07.46 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 14:22.55 | *** join/#brlcad Stattrav (~Stattrav@117.192.150.161) | |
| 14:22.55 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:04.12 | *** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 17:43.40 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 18:16.01 | *** join/#brlcad Stattrav (~Stattrav@117.192.150.161) | |
| 18:16.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:43.48 | CIA-61 | BRL-CAD: 03bhinesley * r44904 10/brlcad/trunk/src/tclscripts/man_browser.tcl: There was a common variable for a listbox -listvariable; changed it to an array so that multiple instances could use it. |
| 20:44.53 | CIA-61 | BRL-CAD: 03bhinesley * r44905 10/brlcad/trunk/src/tclscripts/ (archer/ArcherCore.tcl mged/man.tcl): Man commands for both MGED/Archer weren't correctly handling invalid command names. |
| 21:30.00 | dloman | loving this and the sequel: http://www.youtube.com/watch?v=EwCOG-2ORrc&feature=related |
| 22:01.47 | CIA-61 | BRL-CAD: 03bhinesley * r44906 10/brlcad/trunk/src/tclscripts/man_browser.tcl: |
| 22:01.48 | CIA-61 | BRL-CAD: Fully documented the ManBrowser class. Made the order of method definitions |
| 22:01.49 | CIA-61 | BRL-CAD: consistent with the order they were declared in the interface. Removed |
| 22:01.49 | CIA-61 | BRL-CAD: getBrowser method and let the only caller (listbox selection binding) handle |
| 22:01.49 | CIA-61 | BRL-CAD: that itself. Added a couple items to the to-do/ideas list. Removed all code that |
| 22:01.50 | CIA-61 | BRL-CAD: was commented out. |
| 00:16.09 | CIA-61 | BRL-CAD: 03bhinesley * r44907 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Some tests I was running regarding a bug in the ls command were accidently included in the last commit. Reverting |
| 00:27.28 | *** join/#brlcad crazy_imp (~mj@89.182.141.229) | |
| 04:06.21 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 07:11.34 | *** join/#brlcad Stattrav (~Stattrav@122.172.247.68) | |
| 07:11.34 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:20.41 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 09:03.02 | *** join/#brlcad CIA-12 (~CIA@cia.atheme.org) | |
| 09:37.53 | *** join/#brlcad CIA-49 (~CIA@cia.atheme.org) | |
| 10:55.26 | CIA-49 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2918 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */ |
| 11:46.58 | CIA-49 | BRL-CAD: 03brlcad * r44908 10/brlcad/trunk/doc/deprecation.txt: little more aggressive multiline matching even though it still will skip function pointer arguments |
| 12:18.04 | CIA-49 | BRL-CAD: 03brlcad * r44909 10/brlcad/trunk/ (65 files in 27 dirs): the days of supporting pre-ansi C compilers are long past. remove the BU_EXTERN() wrapper macro as a minimally impacting change. functions should be fully descriptive per ansi with type qualified parameter lists. |
| 12:25.14 | brlcad | has wanted to do that for more than 10 years! |
| 12:34.27 | CIA-49 | BRL-CAD: 03kunigami * r44910 10/brlcad/trunk/src/liboptical/ (CMakeLists.txt osl_rt2.c): Added a simple c osl raytracer to call functions from osl_render. it does not leak memory |
| 12:36.19 | CIA-49 | BRL-CAD: 03kunigami * r44911 10/brlcad/trunk/src/liboptical/osl_rt.cpp: Changed osl_rt (cpp version) to use the wrapper functions instead of the class methods directly. it does not leak memory |
| 12:37.40 | CIA-49 | BRL-CAD: 03kunigami * r44912 10/brlcad/trunk/src/liboptical/sh_osl.c: Changed sh_osl so that the reference to OSLRenderer is stored in shader_specifics. It does leak memory :( |
| 12:51.18 | CIA-49 | BRL-CAD: 03brlcad * r44913 10/brlcad/trunk/misc/batch-indent-region.el: don't mess with the backslashes |
| 13:24.03 | CIA-49 | BRL-CAD: 03brlcad * r44914 10/brlcad/trunk/include/ (15 files): ws indent cleanup after BU_EXTERN removal |
| 13:24.22 | CIA-49 | BRL-CAD: 03brlcad * r44915 10/brlcad/trunk/regress/testlib.c: ws indent cleanup |
| 13:35.33 | kunigami | actually osl_rt2.c leaks memory too |
| 13:53.34 | brlcad | do you know why? :) |
| 13:55.51 | CIA-49 | BRL-CAD: 03brlcad * r44916 10/brlcad/trunk/include/tclcad.h: gah, remove the commas |
| 14:57.01 | kunigami | I know "where" :) it's on an open image io function called "OpenImageIO::v0::ustring::make_unique". It's probably that the raytracer is not freeing it. Unfortunately it has a lot of calling in between, including some LLVM code |
| 14:57.21 | kunigami | I'll have to dig further |
| 15:06.06 | kunigami | ouch, this leaking occurs also in osl code, namely the testshade application. |
| 15:17.02 | starseeker | kunigami: has the osl list been of any help with stuff like this? |
| 15:41.38 | *** join/#brlcad Stattrav (~Stattrav@122.172.247.68) | |
| 15:41.38 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:43.21 | kunigami | hmm, I've once asked by the usage and they did not answered me. But I didn't ask about the code. I'll check if is not a silly mistake and then send an email them. |
| 15:47.03 | *** join/#brlcad dli (~dli@dsl-67-55-7-45.acanac.net) | |
| 16:09.53 | kunigami | When I run with valgrind, rt finishes without crashing. This image: http://dl.dropbox.com/u/1399996/GSoC/WeirdRendering.png is a render of a scene where the floor has an osl yellow shader. Note the weird black strips on it |
| 16:15.53 | starseeker | kunigami: so does that image consitute the first ever BRL-CAD + OSL raytrace image? |
| 16:16.02 | kunigami | yes :) |
| 16:16.31 | starseeker | those black lines might be scan lines that never completed (if there were memory issues or something... you say it crashes without valgrind?) |
| 16:17.34 | kunigami | starseeker: yup |
| 16:18.04 | starseeker | I'd work on the crash first |
| 16:19.13 | kunigami | here is the gdb backtrace: http://pastebin.mozilla.org/1248665 |
| 16:28.03 | kunigami | Could that be an issue with multiple threads? |
| 16:50.38 | *** join/#brlcad merzo (~merzo@50-140-132-95.pool.ukrtel.net) | |
| 16:54.37 | *** join/#brlcad Stattrav (~Stattrav@122.172.247.68) | |
| 16:54.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:59.14 | *** join/#brlcad merzo (~merzo@50-140-132-95.pool.ukrtel.net) | |
| 17:23.57 | brlcad | woot, another logo submission |
| 17:25.24 | brlcad | kunigami: fwiw, OSL is pretty much a one-man show |
| 17:25.50 | brlcad | unfortunately he's not particularly interested in providing support (help) unless you find a bug or write patches, but it's good that you've been talking on the list anyways |
| 17:26.17 | kunigami | I had that impression too. Larry Gritz seems to be ahead of both OSL and OIIO |
| 17:26.29 | brlcad | nods |
| 17:26.43 | brlcad | nice guy, but not a lot of time |
| 17:27.13 | brlcad | kunigami: run rt -P1 and you won't get thread contention |
| 17:27.23 | brlcad | that image is fantastic progress, though :) |
| 17:27.32 | brlcad | worth posting to your log |
| 17:34.25 | bhinesley | what does the debug flag do besides change the install directory? |
| 17:34.28 | bhinesley | oops |
| 17:34.41 | bhinesley | ignore that... accidentally sent history |
| 17:39.40 | bhinesley | brlcad: We talked about a libged command registry a few days ago. Did you have any particulars in mind with regard to how you'd like the registry to work? |
| 17:45.30 | brlcad | definitely, started working on the interface over the weekend |
| 17:45.54 | bhinesley | oh, did you commit anything? |
| 17:52.24 | kunigami | running with rt -P1 stops the crashing! (actually I had tried with -P1 before, but I did "./rt example.g scene.c -P1" and just discovered that the order matters >.<) |
| 17:52.34 | kunigami | the strips are still there though |
| 18:31.16 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 18:50.22 | brlcad | kunigami: so two separate issues -- the strips are probably not threading related then and the crashing may be |
| 18:50.34 | brlcad | P1 just means use one processor |
| 18:51.42 | kunigami | yup. I'll check if it's not the case that the OSLRenderer is returning black pixels (I don't believe so) |
| 18:51.49 | CIA-49 | BRL-CAD: 03brlcad * r44917 10/brlcad/trunk/include/fb.h: common comes before all system headers |
| 18:51.59 | CIA-49 | BRL-CAD: 03brlcad * r44918 10/brlcad/trunk/include/ged.h: common comes before all system headers |
| 18:56.27 | CIA-49 | BRL-CAD: 03brlcad * r44919 10/brlcad/trunk/src/rt/viewg3.c: comment ws indent style cleanup |
| 18:59.00 | brlcad | yeah, not likely |
| 18:59.31 | brlcad | osl wouldn't know about a scanline |
| 18:59.45 | brlcad | undoubtedly something in sh_osl.c |
| 19:16.37 | kunigami | It was actually OSLRenderer that was returning the black points :) The random erand48 depends on the y-coordinate :P |
| 19:19.09 | kunigami | I'm not sure how we'll deal with the recursion. |
| 19:19.57 | kunigami | OSLRenderer finds a multiplier, generates a new ray and recurse |
| 19:20.12 | kunigami | the problems is that not all objects are using osl_shaders |
| 19:21.02 | kunigami | OSLRender would have to return this multiplier back to brlcad system |
| 19:27.15 | kunigami | but how to deal with reflection and refraction? |
| 19:53.38 | kunigami | - |
| 19:54.15 | kunigami | should I use "struct bu_vls" instead of "char *"? |
| 19:54.49 | brlcad | that's pretty interesting |
| 19:56.54 | CIA-49 | BRL-CAD: 03r_weiss * r44920 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: |
| 19:56.54 | CIA-49 | BRL-CAD: Made additional corrections to logic in functions 'nmg_booltree_evaluate' and |
| 19:56.54 | CIA-49 | BRL-CAD: 'nmg_boolean' within file 'nmg_bool.c'. This fix stops the error 'nmg_boolean() |
| 19:56.54 | CIA-49 | BRL-CAD: result of nmg_booltree_evaluate() isn't tp' which occurs occasionally when |
| 19:56.55 | CIA-49 | BRL-CAD: performing nmg boolean operations such as when using the mged 'facetize' |
| 19:56.55 | CIA-49 | BRL-CAD: command. This change also allows boolean operations to return a null result |
| 19:56.56 | CIA-49 | BRL-CAD: without failing. |
| 19:57.06 | brlcad | those are (sometimes) shader properties, so it'd be the shader shooting any new rays needed (via librt) .. user might write some interesting osl shader that requires thousands of new rays to get generated for each pixel |
| 19:57.57 | brlcad | kunigami: vls vs char* => "it depends" |
| 19:58.20 | brlcad | if you need a dynamic string in C, vls is the way to go |
| 19:58.26 | brlcad | if you're in c++, just use a std::string |
| 19:59.16 | brlcad | if you're just storing a name or label and there's no need for the string to be variable in size, then a char[] might be appropriate |
| 19:59.43 | brlcad | when in doubt, vls |
| 20:00.06 | kunigami | I'd like to add a parameter to sh_osl so that the user can specify which osl shader to use |
| 20:00.16 | kunigami | I think vls is better then |
| 20:04.14 | brlcad | what about embedding an actual osl shader? |
| 20:15.34 | kunigami | do you mean independent from rt? |
| 20:26.27 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 20:26.27 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412) | |
| 20:36.09 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 21:04.49 | brlcad | kunigami: I mean embedding new shader descriptions, like this: https://github.com/fohr/openshadinglanguage/blob/testrender/src/shaders/matte.osl |
| 21:05.42 | brlcad | so you could define new shaders and new shader behavior at runtime or at least without recompiling brl-cad |
| 21:05.52 | brlcad | (or osl) |
| 21:21.59 | CIA-49 | BRL-CAD: 03starseeker * r44921 10/brlcad/trunk/src/rt/viewg3.c: fix C comment formatting |
| 21:24.32 | starseeker | bhinesley: I'm getting a problem with Archer |
| 21:24.46 | bhinesley | what's that? |
| 21:24.59 | starseeker | bhinesley: when I launch archer and open a .g file with the File->Open menu option, I can't raytrace the result |
| 21:25.29 | starseeker | when I launch archer and supply the .g file name from the command line (e.g. ./bin/archer m35.g) I can raytrace it |
| 21:25.46 | bhinesley | I'll take a look |
| 21:25.57 | starseeker | thanks |
| 21:30.52 | starseeker | I think it has to do with the path that is being passed to rt |
| 21:31.56 | starseeker | I'm seeing : |
| 21:32.00 | starseeker | opendb /home/user/brlcad/brlcad-build//home/user/brlcad/brlcad-build/share/brlcad/7.20.1/db/m35.g~ |
| 21:33.10 | starseeker | when I specify from the command line I get: |
| 21:33.13 | starseeker | opendb /home/user/brlcad/brlcad-build/share/brlcad/7.20.1/db/m35.g~ |
| 21:41.54 | bhinesley | hm, I'm getting the same (wrong) result no matter how I open the .g file |
| 21:43.48 | starseeker | bhinesley: could that be a consequence of your recent changes? |
| 21:44.03 | bhinesley | I'm not seeing how... they're minor/straightforward |
| 21:49.18 | bhinesley | yeah, it's definitely not that |
| 21:49.49 | starseeker | hrm |
| 21:54.45 | bhinesley | Okay, it runs for me when I am in the directory of the .g file. If I give it a full path it fails even from the command line. |
| 22:12.24 | starseeker | bhinesley: weird... this must be some kind of recent change, it worked just a little while ago... |
| 22:13.12 | bhinesley | starseeker: yeah, I've looked through recent svn logs on related files but haven't found anything interesting yet |
| 22:42.42 | starseeker | bhinesley: yeah, me either |
| 22:53.34 | bhinesley | starseeker: well, you're right about it being a recent change. I updated to r44873, which was 4 days ago, and it works fine. |
| 00:09.03 | *** join/#brlcad vtts (~vytautas@diz.ktu.lt) | |
| 00:11.28 | CIA-49 | BRL-CAD: 03bhinesley * r44922 10/brlcad/trunk/src/librt/db_open.c: Reverted code changes introduced by r44903. It introduced a bug, where raytracing .g files outside of the CWD would fail due to an invalid path. |
| 00:11.44 | bhinesley | starseeker: ^^^ |
| 00:27.46 | *** join/#brlcad crazy_imp (~mj@a89-182-248-44.net-htp.de) | |
| 00:28.12 | starseeker | bhinesley++ |
| 00:28.13 | starseeker | nice find |
| 00:28.59 | bhinesley | shoulda found it earlier, but I didn't realize that the sf commit archives show OLDEST commits on top |
| 00:29.20 | bhinesley | db_open, duh |
| 00:30.35 | starseeker | good job - I shoulda checked that first, but since it was archer-only behavior on my machine the first thing that lept to mind was tcl/tk changes |
| 00:31.01 | starseeker | obviously not :-O |
| 01:03.34 | brlcad | hm, that implies some other bug because those are supposed to be search paths |
| 01:22.25 | bhinesley | Ah okay. I'll take another look tomorrow. |
| 04:06.32 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 04:23.47 | CIA-49 | BRL-CAD: 03brlcad * r44923 10/brlcad/trunk/TODO: eliminate dbi_filepath. shouldn't need to search for resources. the user specified where the database is at, paths are merely relative to our pwd at the time the db was opened or absolute. |
| 04:30.21 | CIA-49 | BRL-CAD: 03brlcad * r44924 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: |
| 04:30.22 | CIA-49 | BRL-CAD: rename RT_CK_DISKMAGIC to NMG_CK_DISKMAGIC since it's not librt api and is |
| 04:30.22 | CIA-49 | BRL-CAD: internal to just nmg.c; probably doesn't even warrant NMG_ prefix, but might |
| 04:30.22 | CIA-49 | BRL-CAD: need to get moved to nmg.h when separated out in a diff lib so leave it be for |
| 04:30.22 | CIA-49 | BRL-CAD: now. |
| 04:40.27 | CIA-49 | BRL-CAD: 03brlcad * r44925 10/brlcad/trunk/src/librt/ (8 files in 7 dirs): some ws indent changes in here got skipped. commit. |
| 04:42.06 | CIA-49 | BRL-CAD: 03brlcad * r44926 10/brlcad/trunk/src/librt/db_open.c: premature, dbip ftw |
| 04:43.38 | CIA-49 | BRL-CAD: 03brlcad * r44927 10/brlcad/trunk/include/raytrace.h: dbi_filename paths are not const if we have to free them! |
| 05:00.14 | CIA-49 | BRL-CAD: 03brlcad * r44928 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: rename rt_nmg_reindex() to just reindex() since it's not librt public api. looks like it's even private nmg api so we can drop the nmg_ prefix. |
| 05:03.23 | CIA-49 | BRL-CAD: 03brlcad * r44929 10/brlcad/trunk/src/ (15 files in 12 dirs): ws indent cleanup after BU_EXTERN removal |
| 05:13.09 | CIA-49 | BRL-CAD: 03brlcad * r44930 10/brlcad/trunk/src/librt/librt.3: document the LIBRT_BOT_MINTIE option in the librt manual page, just so it's written down somewhere user-visible. |
| 06:37.15 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 09:31.13 | *** join/#brlcad Stattrav (~Stattrav@122.172.247.68) | |
| 09:31.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:16.36 | *** join/#brlcad dtidrow (~dtidrow@c-68-60-53-123.hsd1.mi.comcast.net) | |
| 10:46.02 | kunigami | brlcad: the way I was thinking (string identifying shader), you could define a new shader "foo.osl", compile it to "foo.oso" and them load it passing as parameter to sh_osl "foo" |
| 10:46.56 | kunigami | today, what we have is that I have a hard-coded osl shader name "yellow", but "yellow.oso" was compiled independently of brlcad or osl |
| 10:48.16 | kunigami | "what we have is that I have" ... lol |
| 10:55.00 | dloman | yawns |
| 10:55.51 | dloman | mernin all! |
| 11:00.29 | kunigami | morning :) |
| 11:02.49 | dloman | hows gsoc goin for ya? |
| 11:27.23 | *** join/#brlcad crazy_imp (~mj@a89-182-248-44.net-htp.de) | |
| 12:15.58 | CIA-49 | BRL-CAD: 03brlcad * r44931 10/brlcad/trunk/ (9 files in 8 dirs): |
| 12:15.58 | CIA-49 | BRL-CAD: make bu_vls use size_t/off_t internally for tracking the buffer size. |
| 12:15.58 | CIA-49 | BRL-CAD: accordingly, make bu_vls_setlen() and bu_vls_strlen() take a size_t parameter |
| 12:15.58 | CIA-49 | BRL-CAD: and propagate changes down to callers as well so we don't have signed/unsigned |
| 12:15.59 | CIA-49 | BRL-CAD: mismatching. |
| 12:19.54 | CIA-49 | BRL-CAD: 03davidloman * r44932 10/geomcore/trunk/src/GS/FileDataSource.cxx: Comments fix. No longer use BRLCAD::MinimalObject. Uses ExtObjects instead. |
| 12:21.46 | CIA-49 | BRL-CAD: 03davidloman * r44933 10/geomcore/trunk/src/clients/ (. java/): Add a dir for client work. Need to reduce confusion by separating the 'interface' work from the 'clients' that use said interface. |
| 12:25.53 | CIA-49 | BRL-CAD: 03davidloman * r44934 10/geomcore/trunk/src/clients/java/ (src/ test/): Add /src and /test to client dirs for GS Java Client project setup. |
| 12:29.26 | CIA-49 | BRL-CAD: 03davidloman * r44935 10/geomcore/trunk/src/clients/java/: More Project setup. Ignore .* files from eclipse. |
| 12:32.18 | CIA-49 | BRL-CAD: 03davidloman * r44936 10/geomcore/trunk/src/clients/java/src/org/ (4 files in 4 dirs): Add initial source package tree to client /src for GS Java Client project setup. |
| 12:34.09 | CIA-49 | BRL-CAD: 03davidloman * r44937 10/geomcore/trunk/src/ (19 files in 4 dirs): Move client files from interface project to client project |
| 12:35.00 | CIA-49 | BRL-CAD: 03davidloman * r44938 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/: Drop client dirs from interface project |
| 12:53.51 | CIA-49 | BRL-CAD: 03brlcad * r44939 10/brlcad/trunk/ (include/bu.h src/libbu/vls.c): vls_offset isn't supposed to go negative since it's a positive index from the front, so make it a size_t too. remove unnecessary casts now that internal bu_vls members are size_t. |
| 13:15.19 | CIA-49 | BRL-CAD: 03brlcad * r44940 10/brlcad/trunk/src/mged/animedit.c: linux size_t quellage |
| 13:24.56 | CIA-49 | BRL-CAD: 03brlcad * r44941 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: got some unreliable asc2g crashes with the new tclcad handling. thrown in some asserts where unexpected NULLs were showing up in gdb. |
| 13:37.10 | CIA-49 | BRL-CAD: 03brlcad * r44942 10/brlcad/trunk/src/conv/iges/ (convtree.c iges_struct.h): MEMCHECK is only used in convtree.c so move from iges_struct.h; also simplify conditional so we can require a semicolon on use so formatting stays sane. cleanup. |
| 14:01.35 | CIA-49 | BRL-CAD: 03Waters 07http://brlcad.org * r2919 10/wiki/User:Waters: New page: [http://www.speedmycomputer.net/ how can i speed up my computer] |
| 14:23.50 | CIA-49 | BRL-CAD: 03brlcad * r44943 10/brlcad/trunk/include/raytrace.h: |
| 14:23.50 | CIA-49 | BRL-CAD: add a new RT_INIT_COMB_INTERNAL initialization macro for initializing |
| 14:23.50 | CIA-49 | BRL-CAD: rt_comb_internal structs. add a corresponding RT_FREE_COMB_INTERNAL() macro |
| 14:23.50 | CIA-49 | BRL-CAD: since we do initialize the vls strings potentially allocating memory (might want |
| 14:23.50 | CIA-49 | BRL-CAD: a bu_vls_init_empty() or vls INIT macro). |
| 14:24.37 | CIA-49 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Waters]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 14:24.57 | CIA-49 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User:Waters]]": content was: '[http://www.....net/ how can i speed up my computer]' (and the only contributor was '[[Special:Contributions/Waters|Waters]]') |
| 14:27.57 | CIA-49 | BRL-CAD: 03brlcad * r44944 10/brlcad/trunk/src/ (12 files in 4 dirs): use the new RT_INIT_COMB_INTERNAL macro allowing us to make comb initialization consistent and consolidated into one place. |
| 14:30.33 | brlcad | bhinesley: any luck with the dbi_filepath issue? I'm actually not seeing how that even comes into play during database open (supposed to be used to find resources like height field files, bitmaps, shader files, etc) |
| 14:37.54 | CIA-49 | BRL-CAD: 03brlcad * r44945 10/brlcad/trunk/misc/Makefile.am: sort & sync. remove FindCocoa.cmake and FindCorbon.cmake, add util_macros.cmake. |
| 14:59.32 | CIA-49 | BRL-CAD: 03davidloman * r44946 10/geomcore/trunk/src/clients/java/src/org/brlcad/geometryservice/minimalclient/ (CmdConsolePanel.java JTextFieldWithHistory.java): Break out JTextField into custom subclass. Add cmd history. |
| 15:10.34 | CIA-49 | BRL-CAD: 03starseeker * r44947 10/brlcad/trunk/src/other/iwidgets/generic/ (panedwindow.itk tclIndex): Stick in iwidgets panedwindow method and option that seem to be needed for RamDebugger... |
| 15:11.24 | CIA-49 | BRL-CAD: 03davidloman * r44948 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ (GSConnection.java msg/AbstractNetMsg.java): Make the java implementation AbstractNetMsg.java match NetMsg.cxx |
| 15:11.47 | *** join/#brlcad Stattrav (~Stattrav@122.167.214.98) | |
| 15:11.47 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:15.08 | CIA-49 | BRL-CAD: 03davidloman * r44949 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/NetMsgTypes.java: Update NetMsgTypes from C++ code. |
| 15:42.02 | CIA-49 | BRL-CAD: 03davidloman * r44950 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/RemoteNodeNameSetMsg.java: Comment cleanup |
| 15:42.38 | CIA-49 | BRL-CAD: 03davidloman * r44951 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/ (5 files): Implement a few more NetMsg types in java. More on the way. |
| 15:47.09 | CIA-49 | BRL-CAD: 03starseeker * r44952 10/brlcad/trunk/src/other/tktreectrl/ (246 files in 21 dirs): |
| 15:47.10 | CIA-49 | BRL-CAD: Early cut at a CMakeified tktreectrl widget. This and the next few commits are |
| 15:47.11 | CIA-49 | BRL-CAD: only for the purposes of 'checkpointing' what I have managed to get working as |
| 15:47.12 | CIA-49 | BRL-CAD: far as RamDebugger goes - not really functional as yet (the basic RamDebugger |
| 15:47.17 | CIA-49 | BRL-CAD: window comes up, but that's about it), so I'll promptly remove it again - the |
| 15:47.17 | CIA-49 | BRL-CAD: goal is to have what I did get in svn history if I can devote more resources to |
| 15:47.17 | CIA-49 | BRL-CAD: it later. |
| 15:53.12 | kunigami | dloman: going well. By now I'm studying how to deal with recursive rays (reflection and refraction/transmission). will make some experiments here |
| 16:02.33 | CIA-49 | BRL-CAD: 03starseeker * r44953 10/brlcad/trunk/src/other/ (672 files in 38 dirs): |
| 16:02.33 | CIA-49 | BRL-CAD: Tweaked version of RamDebugger - diff with vanilla version 7.8 to see |
| 16:02.33 | CIA-49 | BRL-CAD: differences. Removed a few extensions and there is more to remove, if this were |
| 16:02.33 | CIA-49 | BRL-CAD: ever to be properly set up for what BRL-CAD needs - many features like cvs |
| 16:02.33 | CIA-49 | BRL-CAD: aren't particularly important to us, for example... Changes here were done |
| 16:02.34 | CIA-49 | BRL-CAD: using the enable-all-local-libs build options. |
| 16:04.19 | kunigami | by the way, is there any variable that stores how many times a given ray hit an object (or its depth)? |
| 16:04.31 | CIA-49 | BRL-CAD: 03starseeker * r44954 10/brlcad/trunk/src/other/ (CMakeLists.txt RamDebugger/ tktreectrl/): Checkpoint complete, restore previous src/other CMakeLists.txt logic and remove RamDebugger related directories. |
| 16:05.36 | brlcad | kunigami: you set up callbacks when you fire a ray for hit/miss that can perform that book-keeping, or you can make sure a_onehit is unset and you'll get back a partition list of all objects along that ray |
| 16:08.45 | brlcad | kunigami: http://brlcad.org/wiki/Example_Application shows the latter where it iterates over the partition list |
| 16:12.51 | CIA-49 | BRL-CAD: 03davidloman * r44955 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/ (GeometryChunkMsg.java GeometryManifestMsg.java): Add GeometryManifest and GeometryChunk msgs to java |
| 16:13.13 | CIA-49 | BRL-CAD: 03davidloman * r44956 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/ (PingMsg.java PongMsg.java): Add Ping and Pong to java |
| 16:16.11 | CIA-49 | BRL-CAD: 03davidloman * r44957 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/ (DirListReqMsg.java DirListResMsg.java): Add DirectoryList request and response NetMsgs to java. |
| 16:16.49 | CIA-49 | BRL-CAD: 03davidloman * r44958 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/NetMsgFactory.java: Update NetMsgfactory with all the recently implemented NetMsg subclasses. |
| 16:17.11 | *** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net) | |
| 16:18.11 | kunigami | brlcad: thanks! this example also shows how to setup the callback |
| 16:20.03 | CIA-49 | BRL-CAD: 03bob1961 * r44959 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Added the ability to create instances of ArcherCore with/without the treeview or the toolbar. |
| 16:20.50 | CIA-49 | BRL-CAD: 03davidloman * r44960 10/geomcore/trunk/src/libNet/netMsg/NewNodeOnNetMsg.cxx: Update NetMsg type to correct one for this class. |
| 16:21.47 | kunigami | if I understood it right, whenever it hits an object that function will be called. If, for example, a ray first hits an object A, the callback will be called with only object A. If this ray further hits an object B, them both A and B will be in that partition list? |
| 16:21.51 | CIA-49 | BRL-CAD: 03davidloman * r44961 10/geomcore/trunk/src/utility/StringUtils.cxx: Fix incorrect type and cast. |
| 16:26.03 | brlcad | kunigami: it depends if onehit is set, but if unset then yes |
| 16:26.32 | yukonbob | hello, #brlcad |
| 16:26.41 | brlcad | howdy yukonbob |
| 16:26.53 | yukonbob | how're things? |
| 16:28.46 | CIA-49 | BRL-CAD: 03bob1961 * r44962 10/brlcad/trunk/src/tclscripts/rtwizard/ (RaytraceWizard.tcl lib/MGEDpage.itk): Updates to use ArcherCore instead of Mged which has been deprecated. |
| 16:29.20 | brlcad | busy |
| 16:29.34 | brlcad | dloman: how was the type incorrect? |
| 16:29.36 | yukonbob | excellent! |
| 16:29.57 | yukonbob | hits website to see if there're published stories about recent(ish) goings-on... |
| 16:30.39 | brlcad | maybe a complaint that bu_free() wasn't being passed a genptr_t (i.e., a void*), but making it const isn't technically correct |
| 16:32.32 | brlcad | starseeker: hmmm |
| 16:32.46 | brlcad | adding RamDebugger is akin to adding gdb ... kinda odd |
| 16:33.11 | brlcad | maybe a separate branch for 3rd party tools? |
| 16:36.37 | yukonbob | what's the RamDebugger for ? |
| 16:41.00 | brlcad | presumably debugging tcl code |
| 16:41.10 | brlcad | it's a gui ide for tcl debugging |
| 16:43.14 | starseeker | brlcad: I removed it - just wanted to stash it in history somewhere |
| 16:43.47 | brlcad | heh, okay |
| 16:44.33 | starseeker | brlcad: ultimately it might be interesting to be able to debug tcl scripts "in MGED" or some such, but for the moment I can't even get the darn thing to debug ANYTHING |
| 16:46.04 | starseeker | I'm sure it'll do something once I finish widing through the "oh, this doesn't work either with this version" fun but even then I'm not sure how well it would do with incrTcl/iwidgets |
| 16:46.46 | starseeker | my annoyance threshold with debugging Tcl/Tk just hit a momentary peak - it'll fade back to normal background annoyance levels soon :-P |
| 16:46.55 | yukonbob | notes theres also -DTCL_MEM_DEBUG, and the [mem] commands it presents... |
| 16:47.57 | yukonbob | starseeker: Tcl loves you :) |
| 16:48.34 | starseeker | yukonbob: what I miss most is the ability to step through a tcl file line by line in an editor DDD style, examining variables and such and easily seeing which Tcl line ultimately triggered the latest framebuffer/display manager problem |
| 16:49.25 | starseeker | feeding bwish into gdb does OK if the problem is in our C libraries, but if it's actually in the Tcl code... |
| 16:49.31 | dloman | brlcad: was supposed to be const char* instead of just char* |
| 16:49.32 | yukonbob | nods... a bit more involved than just memory consumption, ckalloc() guarding... |
| 16:49.41 | dloman | brlcad: and i missed a cast to void* |
| 16:49.54 | yukonbob | TclPro has what you're looking for, I think, but I haven't played w/ that part of Tcl dev... |
| 16:50.02 | yukonbob | is sure starseeker is on the case, though. |
| 16:50.30 | starseeker | <snort> the problem is Tcl/Tk problems of that nature are just rare enough that we can usually ignore them or have bob1961 track 'em down |
| 16:51.04 | starseeker | TclPro... isn't that the commerical one? Or wasn't there some free version that hasn't been updated in a long long time? |
| 16:54.55 | brlcad | dloman: it's not supposed to be const char |
| 16:55.08 | brlcad | at least not if you're going to bu_free it (which the signature requires) |
| 16:55.33 | dloman | okie |
| 16:56.02 | brlcad | the cast to void* (i.e., genptr_t) is the only thing that might have provoked a warning, but the types should have been golden |
| 16:57.03 | brlcad | the constness is broken by casting to void* anyways |
| 16:57.49 | starseeker | hah, cool: http://labs.qt.nokia.com/2011/06/03/threaded-opengl-in-4-8/ |
| 16:58.27 | bhinesley | brlcad: not yet, I'm just starting for today. To answer your question: I don't think that it has anything to do with opening the database. It has to do with the CWD, which is apparently being used somewhere. |
| 16:58.27 | bhinesley | When attempting to raytrace, we see the path "/CWD//full_path_to_.g/" being used (two absolute paths concatenated). |
| 17:00.17 | brlcad | yeah, i get the end-effect, and that the full-path cwd is presumably coming from dbi_fullpath .. but not how the order of search dirs [0] vs [1] would result in that |
| 17:00.40 | bhinesley | that, I will have to figure out |
| 17:01.01 | bhinesley | gets to work |
| 17:01.05 | brlcad | I did a full search for dbi_fullpath and ... if it's the cause, I haven't quite seen how yet :) |
| 17:01.29 | CIA-49 | BRL-CAD: 03davidloman * r44963 10/geomcore/trunk/src/utility/StringUtils.cxx: Cast the data from bu_basename to (char*) rather than passing around a (const char*) |
| 17:02.25 | brlcad | hmmm |
| 17:02.41 | brlcad | I think your header files are out of date, don't need a cast either :) |
| 17:02.46 | brlcad | (dloman) |
| 17:03.15 | brlcad | that's probably the original problem |
| 17:03.26 | dloman | kk |
| 17:04.07 | dloman | updates |
| 17:11.00 | starseeker | O.o another one: https://github.com/advancingu/Cutexture |
| 17:12.55 | brlcad | http://www.youtube.com/watch?v=b_3xfFuwGOQ |
| 17:14.45 | starseeker | brlcad: yeah, saw that - quite promising |
| 17:14.57 | starseeker | that's the experimental Qt5 apparently |
| 17:15.12 | brlcad | same problem from a couple years ago though |
| 17:15.17 | brlcad | still seems "backwards" |
| 17:15.57 | starseeker | you mean ogre-in-Qt not Qt-in-Ogre? |
| 17:16.05 | brlcad | yeah |
| 17:16.20 | brlcad | or both really since you still want qt widgets in the ogre context too |
| 17:16.38 | brlcad | but that your main window is a qt window, not something ogre establishes |
| 17:16.58 | starseeker | maybe cutexture is set up more along those lines - I'll have to check |
| 17:17.17 | starseeker | usually the problem I have testing these suckers is getting Ogre working on my home box... |
| 17:34.07 | yukonbob | Trolltech ogre? Isn't there a rule against cross-fairytale creature misappropriation? |
| 17:38.22 | bhinesley | brlcad: which argument is used for what seems to be explicit: if (argv[1][0] != '/') |
| 17:39.19 | bhinesley | it tests to see if the second argument is an absolute path, but not the first |
| 17:39.39 | bhinesley | sorry, this is in db_open.c |
| 17:53.32 | CIA-49 | BRL-CAD: 03starseeker * r44964 10/brlcad/trunk/ (5 files in 4 dirs): Downcase the openNURBS directory to just opennurbs - 'cause macros are easier when you don't have mixed case in the way. |
| 17:55.39 | brlcad | ah, heh .. I was hunting down dbi_fullpath in other files and it hadn't even gotten out of db_open()! I see now, it's trying to expand the full path for dbi_filename() |
| 17:55.51 | brlcad | will rewrite that function, no worries -- thanks! |
| 17:56.07 | bhinesley | oh alright! no problem. |
| 17:56.40 | brlcad | it was actually next in my queue to add a cwd routine to libbu anyways |
| 18:02.40 | bhinesley | brlcad: should I keep working on migrating commands and fixing bugs for now, or should I start on the libged command registry? I'm not really sure where to start on the registry, so we might need to talk about it for a bit before I do. |
| 18:03.13 | bhinesley | either is fine for me |
| 18:11.16 | *** join/#brlcad bhinesley_ (~bhinesley@99.144.90.118) | |
| 18:11.43 | bhinesley_ | brlcad: my machine locked up, so if you said anything i missed it |
| 18:17.26 | starseeker | bhinesley: he didn't yet |
| 18:17.39 | bhinesley | thanks :) |
| 18:24.07 | brlcad | bhinesley: I'd keep with the original plan for now, command migration, refactoring, and fixing |
| 18:24.25 | bhinesley | ok |
| 18:25.30 | brlcad | I've got something started for the registry, but am just a bit overtasked at the moment to dive down that path just yet |
| 18:26.11 | brlcad | nothing fancy to say the least, but the command work will be more immediately useful anyways |
| 18:26.23 | bhinesley | Oh, don't worry about it, I know you have a lot on your plate. |
| 18:31.31 | CIA-49 | BRL-CAD: 03davidloman * r44965 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSJavaInterface.java: Comment clean up. Also added two methods that will need to be rolled into jBRLCAD's GemetryService Interface |
| 18:32.48 | CIA-49 | BRL-CAD: 03davidloman * r44966 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSStatics.java: Remove libPKG remnants |
| 18:33.43 | CIA-49 | BRL-CAD: 03brlcad * r44967 10/brlcad/trunk/ (TODO src/libged/typein.c): we allocate the idb_ptr so we know the vls is not initialized. call bu_vls_init() instead of bu_vls_init_if_uninit(). still warrants a quick test before the next release, though. |
| 18:34.15 | CIA-49 | BRL-CAD: 03davidloman * r44968 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/AbstractNetMsg.java: Was incorrectly serializing using the old GSNetProto header. Removed the two MAGIC values and fixed the msgLen calculation. |
| 18:35.36 | CIA-49 | BRL-CAD: 03brlcad * r44969 10/brlcad/trunk/src/ (conv/dxf/dxf-g.c mged/vrlink.c): make the vls a pointer so it can sometimes be NULL and we can test that for determining whether to initialize or not. call bu_vls_init() instead of the unreliable bu_vls_init_if_uninit(). |
| 18:36.21 | CIA-49 | BRL-CAD: 03brlcad * r44970 10/brlcad/trunk/src/mged/utility1.c: the tmp_vls isn't used outside the nested scope so pull it down to where it's used. there we know it's not initialized, so we can just call bu_vls_init(). |
| 18:37.15 | CIA-49 | BRL-CAD: 03brlcad * r44971 10/brlcad/trunk/src/ (libbu/parse.c librt/parse.c): if they're not initialized, it's an error in the caller's code. don't try to accommodate the error by initializing. |
| 18:41.51 | CIA-49 | BRL-CAD: 03brlcad * r44972 10/brlcad/trunk/ (doc/deprecation.txt include/bu.h src/libbu/vls.c): |
| 18:41.52 | CIA-49 | BRL-CAD: and with that, mark the silly inconsistent error-prone unreliable |
| 18:41.52 | CIA-49 | BRL-CAD: bu_vls_init_if_uninit() function as deprecated. there needs to be an INIT macro |
| 18:41.52 | CIA-49 | BRL-CAD: for bu_vls structs but bu_vls_init() is the better way to go. the problem stems |
| 18:41.52 | CIA-49 | BRL-CAD: from memory not getting consistently initialized and/or reset to zero so that |
| 18:41.52 | CIA-49 | BRL-CAD: the magic check would actually work. using a NULL pointer or caller-based init |
| 18:41.53 | CIA-49 | BRL-CAD: flag are safer methods. |
| 18:42.04 | CIA-49 | BRL-CAD: 03davidloman * r44973 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: |
| 18:42.04 | CIA-49 | BRL-CAD: Added a thread sleep in the GSConnection run loop to keep from hogging a CPU. |
| 18:42.04 | CIA-49 | BRL-CAD: Fixed buffer size checking in tryMakeNetMsg(), it was incorrectly thinking there |
| 18:42.04 | CIA-49 | BRL-CAD: was insufficient data to deserialize and bailing out. Also fixed waitForMsg() |
| 18:42.05 | CIA-49 | BRL-CAD: as the totalRead parameter was not being reset after the loop was finished. |
| 18:46.10 | CIA-49 | BRL-CAD: 03davidloman * r44974 10/geomcore/trunk/src/clients/java/src/org/brlcad/geometryservice/minimalclient/CmdConsolePanel.java: Removed unused var from doCmd(). Was leftover from debugging. |
| 18:47.00 | CIA-49 | BRL-CAD: 03davidloman * r44975 10/geomcore/trunk/src/clients/java/src/org/brlcad/geometryservice/minimalclient/cmd/LoginCmd.java: Print the remote nodename to the GUI console upon successful connection. |
| 18:51.05 | CIA-49 | BRL-CAD: 03davidloman * r44976 10/geomcore/trunk/ (include/PortalManager.h src/libNet/PortalManager.cxx): Make a difference between 'LocalNodeName' and the PortalManager object's name. LocalNodeName is the name of this PortalManager on the network while the other is simply the object's name used in Logging. |
| 18:54.19 | CIA-49 | BRL-CAD: 03davidloman * r44977 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: Eliminate duplicate fn. |
| 19:04.07 | CIA-49 | BRL-CAD: 03starseeker * r44978 10/brlcad/trunk/src/other/opennurbs/CMakeLists.txt: bye bye mixed case |
| 19:07.12 | CIA-49 | BRL-CAD: 03davidloman * r44979 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSNetMsgFutureResponse.java: Add a response handler for NetMsg that should envoke a response from server. |
| 19:08.53 | brlcad | starseeker: if I recall correctly, mixed case on the product is what was in their original build files, so there is some value in preserving that trait |
| 19:10.35 | brlcad | further deviation from their source (with any benefit?) making it more complicated to swap in a system opennurbs down the road |
| 19:12.34 | brlcad | the dir name is irrelevant, but the product name does have meaning (e.g., mixed case is highly indicative of C++ libs vs C libs .. a quick scan of any lib dir and the C++ ones are generally (conventionally) the ones with upper-case) |
| 19:19.04 | CIA-49 | BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2920 10/wiki/User:Bhinesley: /* Log */ Friday - Monday, plan today |
| 19:24.36 | CIA-49 | BRL-CAD: 03brlcad * r44980 10/brlcad/trunk/include/bu.h: |
| 19:24.36 | CIA-49 | BRL-CAD: implement BU_INIT_VLS() and BU_INIT_VLB() macros to initialize a vls/vlb struct |
| 19:24.36 | CIA-49 | BRL-CAD: without allocating any memory. also, similar to the convention in vmath, |
| 19:24.36 | CIA-49 | BRL-CAD: provide BU_VLS_INIT_ZERO/BU_VLB_INIT_ZERO macros suitable for declaration |
| 19:24.36 | CIA-49 | BRL-CAD: statement initialization. |
| 19:25.45 | brlcad | bhinesley: tell me about ls |
| 19:41.21 | *** join/#brlcad yiyus (2383vince@je.je.je) | |
| 19:55.11 | CIA-49 | BRL-CAD: 03davidloman * r44981 10/geomcore/trunk/src/libNet/ (Portal.cxx PortalManager.cxx): Make Portal/PortalManager respond to a RemNodeNameSet message rather than automatically sending its localNodeName. |
| 19:55.28 | CIA-49 | BRL-CAD: 03brlcad * r44982 10/brlcad/trunk/include/bu.h: add BU_LIST_INIT_ZERO, BU_BITV_INIT_ZERO, and BU_INIT_BITV macros for api consistency (lots more to go) |
| 19:55.51 | bhinesley | brlcad: I noticed that when you enter "ls not-an-obj" it would print "not-an-obj", which is misleading. I checked ArcherCore.tcl, and saw that it simply does "return \$expandedArgs" if you don't pass any options. |
| 19:55.51 | bhinesley | I was trying to get the behavior that MGED has: if you do an 'ls is-an-obj not-an-obj', it returns something like "is-an-obj (\n ...) not-an-obj doesn't exist". This doesn't seem possible the way it works now, since we're not letting libged's ls command print it's error directly to the command line. If we want ::ls to print the error, it has to be all or nothing (failure or success), since a partial match in libged's ls simply returns GED_OK. |
| 19:56.23 | CIA-49 | BRL-CAD: 03brlcad * r44983 10/brlcad/trunk/src/libbu/ (list.c malloc.c mappedfile.c temp.c): no longer need to manually init the bu_list or ignore init, call BU_LIST_INIT_ZERO instead. |
| 19:57.11 | bhinesley | hopefully that made sense |
| 20:08.43 | CIA-49 | BRL-CAD: 03brlcad * r44984 10/brlcad/trunk/include/bu.h: fix BU_INIT_BITV(). we need pointers to pass to BU_INIT_LIST(). group the bu_list init macros together better and add BU_INIT_LIST (which calls the existing BU__LIST_INIT that will soon go away). |
| 20:09.00 | CIA-49 | BRL-CAD: 03brlcad * r44985 10/brlcad/trunk/src/libbu/bitv.c: initialize the BU_BITV properly instead of setting the magic manually. |
| 20:41.42 | brlcad | bhinesley: yes, that does make sense |
| 20:42.18 | brlcad | that actually sounds like a prime example for consolidation so that they are identical |
| 20:43.09 | brlcad | so there's no expansion in mged or archer, that ged_ls() does all the work with the necessary information returned in the struct ged in some form that both can display suitably |
| 20:44.06 | brlcad | and of course sorting out what it means to have a partial failure from an api perspective |
| 20:44.48 | brlcad | I'd think partial failure is still a failure, not GED_OK for starters |
| 20:44.53 | bhinesley | agreed |
| 20:47.05 | brlcad | the issue then just becomes how to have ged_ls() add listings and failures to the results |
| 20:47.33 | brlcad | could be time to sort out a proper result set instead of the dumb ged_result_str |
| 20:48.21 | kunigami | can I set the hit callback on the shader setup? |
| 20:50.07 | brlcad | e.g., an array of types and values so that "ls valid invalid valid2" might return the set { {GED_OBJECT, "valid"}, {GED_ERROR, "ls: invalid: No such object"}, {GED_OBJECT, "valid2"} } |
| 20:50.35 | brlcad | kunigami: you can set the hit callback any time before rt_shootray() is called |
| 20:51.56 | brlcad | if you're in the shader, though, then that probably implies that a ray was already fired, hit callback was made, determined ther shader, and shader callback was made .. so you'd be firing another ray you set up |
| 20:54.58 | kunigami | true |
| 20:55.24 | bhinesley | brlcad: does ::ls even need to know that much? Couldn't just the results be passed back from ged_ls? |
| 20:55.47 | kunigami | it seems that the variable 'a_level' from application struct counts the depth of recursion. let me give it a try |
| 20:57.43 | bhinesley | and by that, I mean one long string that is printed |
| 20:58.25 | bhinesley | n/m... then we'd lose the ability to identify which part of it is an error |
| 20:58.35 | bhinesley | for logging and whatnot |
| 20:58.36 | brlcad | bhinesley: bingo |
| 20:58.44 | brlcad | I mean for now, that'd be an improvement |
| 20:59.16 | brlcad | but the goal is to make the return from the ged_*() functions be programmatic |
| 21:00.12 | brlcad | so I could write a program that uses ged_ls() to lookup objects, iterate over them and call other functions etc |
| 21:00.57 | brlcad | or in the case of mged/arhcer, maybe I want to return the list of objects as a proper list and print the error (interleaved and color-coded) to stderr |
| 21:02.42 | bhinesley | I understand; I was thinking about it from the perspective of tcl code duplication. It'd be nice if there was a mechanism for using the same call to ged_ls for both programs... like how I kinda forced that with ManBrowser. |
| 21:02.54 | bhinesley | that would prevent problems like this from occurring in the first place |
| 21:04.25 | CIA-49 | BRL-CAD: 03brlcad * r44986 10/brlcad/trunk/ (21 files in 12 dirs): |
| 21:04.25 | CIA-49 | BRL-CAD: replace BU_LIST_UNINITIALIZED() with !BU_LIST_IS_INITIALIZED() as a minimally |
| 21:04.25 | CIA-49 | BRL-CAD: impacting API change. BU_LIST_UNINITIALIZED() is unnecessary with the other and |
| 21:04.26 | CIA-49 | BRL-CAD: inconsistent with the API (the only *_uninitialized macro of its kind). reduce, |
| 21:04.26 | CIA-49 | BRL-CAD: reuse. |
| 21:05.07 | bhinesley | shrugs |
| 21:21.06 | starseeker | brlcad: uh... we're writing our own build logic for opennurbs anyway... |
| 21:22.33 | starseeker | brlcad: at this point I'm very doubtful we'll ever be able to use a system opennurbs |
| 21:23.01 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177593767.dsl.bell.ca) | |
| 21:23.19 | starseeker | I'll revert it if you want and try to find another way to do what I had in mind... |
| 21:27.08 | CIA-49 | BRL-CAD: 03bhinesley * r44987 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Temporary fix for ::ls to stop echoing nonexistant objects. |
| 21:29.23 | brlcad | starseeker: it should probably still be our goal, not intentionally move away with a fork |
| 21:29.32 | brlcad | if only to minimize differences the next time we sync |
| 21:29.56 | brlcad | that one in particular, though, gets at the convention issue and the "name" of the library |
| 21:31.28 | starseeker | brlcad: I'm not sure I agree about forking, but I'll revert the name downcasing (working on it now) |
| 21:33.50 | *** part/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177593767.dsl.bell.ca) | |
| 21:35.16 | *** join/#brlcad bhinesley_ (~bhinesley@99.144.90.118) | |
| 21:35.43 | *** join/#brlcad bhinesley_ (~bhinesley@99.144.90.118) | |
| 21:36.31 | CIA-49 | BRL-CAD: 03starseeker * r44988 10/brlcad/trunk/ (501 files in 11 dirs): Revert r44964 |
| 21:46.50 | brlcad | starseeker: I still think it's entirely possible to get a pristine openNURBS working, to move back towards the original goal of having a proper layer on *top* of opennurbs for our added functionality |
| 21:47.09 | brlcad | maybe that overlay is your libnurbs project |
| 21:47.44 | brlcad | anything else is going to have an ongoing maintenance cost that, well, will suck more and more over time |
| 21:48.47 | brlcad | curious though -- what prompted that onto your radar to change it? |
| 21:49.16 | starseeker | I'm playing games with CMake macros to get the distcheck filelists out of src/other/CMakeLists.txt |
| 21:49.51 | starseeker | I was using some toupper and tolower logic in macros - it may not be strictly necessary though, so I'm going to revisit those macros |
| 00:27.56 | *** join/#brlcad crazy_imp (~mj@a89-182-252-199.net-htp.de) | |
| 02:24.16 | CIA-49 | BRL-CAD: 03brlcad * r44989 10/brlcad/trunk/src/libbu/vls.c: make sure the string actually has allocated memory befor trying to set a sanity char |
| 02:40.45 | CIA-49 | BRL-CAD: 03brlcad * r44990 10/brlcad/trunk/include/bu.h: the func is bu_vls_init(), the macro is BU_INIT_VLS() |
| 02:43.21 | CIA-49 | BRL-CAD: 03brlcad * r44991 10/brlcad/trunk/include/raytrace.h: call BU_INIT_VLS() instead of bu_vls_init() here so we can avoid memory allocation |
| 03:51.34 | CIA-49 | BRL-CAD: 03brlcad * r44992 10/brlcad/trunk/include/raytrace.h: better comment wording. the struct itself isn't freed so don't say memory is released. callers still need to call bu_free(). |
| 03:54.25 | *** join/#brlcad CIA-49 (~CIA@cia.atheme.org) | |
| 04:11.53 | *** join/#brlcad CIA-68 (~CIA@cia.atheme.org) | |
| 04:14.27 | CIA-68 | BRL-CAD: 03brlcad * r44995 10/brlcad/trunk/include/bu.h: not necessarily deprecated just yet. we may want to use RT_type_INIT() instead of RT_INIT_type |
| 04:14.27 | CIA-68 | BRL-CAD: 03brlcad * r44994 10/brlcad/trunk/src/mged/utility1.c: vls overkill, just interpret the help command directly |
| 04:14.27 | CIA-68 | BRL-CAD: 03brlcad * r44993 10/brlcad/trunk/src/librt/comb/db_comb.c: simplify. call RT_FREE_COMB_INTERNAL() instead of manually managing the struct members. |
| 07:01.47 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 11:33.57 | CIA-68 | BRL-CAD: 03davidloman * r44996 10/geomcore/trunk/ (include/Session.h src/GS/Session.cxx): Make Session::generateSessionInfoMsg() take an optional 'reply' message as an arg. This allows for proper RegardingUUID setting in generated msg. |
| 11:34.57 | CIA-68 | BRL-CAD: 03davidloman * r44997 10/geomcore/trunk/src/GS/SessionManager.cxx: Pass the NewSessionRequestMsg as an arg to the SessionInfoMsg construction in Session::generateSessionInfoMsg() |
| 12:27.11 | CIA-68 | BRL-CAD: 03brlcad * r44998 10/brlcad/trunk/ (include/bu.h src/libbu/bitv.c): |
| 12:27.11 | CIA-68 | BRL-CAD: continue moving towards API consistency and completeness. start making sure all |
| 12:27.11 | CIA-68 | BRL-CAD: structs have a common set of macros: BU_[type]_INIT(), BU_[type]_INIT_ZERO, |
| 12:27.11 | CIA-68 | BRL-CAD: BU_[type]_NULL, along with a few others. ensure there's a NULL and typedef as |
| 12:27.11 | CIA-68 | BRL-CAD: well (even though those may be eliminated down the road). expand doxygen docs |
| 12:27.12 | CIA-68 | BRL-CAD: while we're at it finishing up bu_list, bu_bitv, and bu_hist for starters. |
| 12:36.00 | CIA-68 | BRL-CAD: 03brlcad * r44999 10/brlcad/trunk/include/bu.h: fill out bu_ptbl macros and typedef |
| 12:42.39 | CIA-68 | BRL-CAD: 03brlcad * r45000 10/brlcad/trunk/include/bu.h: fill out bu_mapped_file macros and typedef, fix ptbl typedef typo |
| 12:48.08 | CIA-68 | BRL-CAD: 03davidloman * r45001 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/ (GSJavaInterface.java net/GSConnection.java): Rework error handling on connectToHost() fns. Had to create a custom class to handle all the possible return values. (This is where callbacks or pointers would have been nice to have!) |
| 12:50.28 | CIA-68 | BRL-CAD: 03davidloman * r45002 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ (4 files in 2 dirs): Clean up Exception printing. Helps in tracking down bugs. Lots of future clean up here! |
| 12:50.47 | CIA-68 | BRL-CAD: 03brlcad * r45003 10/brlcad/trunk/src/libbu/ (globals.c hook.c): just use NULL instead of BU_HOOK_NULL |
| 12:51.02 | CIA-68 | BRL-CAD: 03brlcad * r45004 10/brlcad/trunk/include/bu.h: expand bu_hook_list macros, remove BU_HOOK_NULL |
| 12:51.51 | CIA-68 | BRL-CAD: 03davidloman * r45005 10/geomcore/trunk/src/clients/java/src/org/brlcad/geometryservice/minimalclient/cmd/LoginCmd.java: Cascading changes from connectToHost(). It no longer returns a simple boolean. Instead it returns an int with informational error/return codes. |
| 12:53.46 | CIA-68 | BRL-CAD: 03davidloman * r45006 10/geomcore/trunk/src/clients/java/src/org/brlcad/geometryservice/minimalclient/cmd/ (CmdManager.java ListCmd.java LogoutCmd.java): Implement ListCmd and LogoutCmd |
| 12:56.00 | CIA-68 | BRL-CAD: 03davidloman * r45007 10/geomcore/trunk/src/clients/java/src/org/brlcad/geometryservice/minimalclient/CmdConsolePanel.java: More exception cleanup. |
| 12:56.59 | CIA-68 | BRL-CAD: 03davidloman * r45008 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: Forgot to remove a debugging statement |
| 12:57.20 | CIA-68 | BRL-CAD: 03davidloman * r45009 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSJavaInterface.java: Import cleanup |
| 13:03.51 | CIA-68 | BRL-CAD: 03brlcad * r45010 10/brlcad/trunk/include/bu.h: include some clarity that all of the structs that include list elements are still expected to have a list head node, which should have a magic type of BU_LIST_HEAD_MAGIC. |
| 13:11.25 | CIA-68 | BRL-CAD: 03brlcad * r45011 10/brlcad/trunk/include/bu.h: add avs macros and typedef |
| 13:16.04 | CIA-68 | BRL-CAD: 03brlcad * r45012 10/brlcad/trunk/include/bu.h: api is starting to stabilize, convention is now BU_[type]_INIT() so change BU_INIT_VLS() to BU_VLS_INIT(). |
| 13:18.40 | CIA-68 | BRL-CAD: 03brlcad * r45013 10/brlcad/trunk/include/raytrace.h: update the one place where BU_INIT_VLS() was being called too. |
| 13:18.50 | CIA-68 | BRL-CAD: 03brlcad * r45014 10/brlcad/trunk/include/bu.h: update vlb the same |
| 13:31.09 | kunigami | I'll take the rest of the week studying the feasibility of using a brl-cad shader as an interface to osl system. The example @brlcad showed me made me think that implementing a stand-alone application for osl would be feasible. |
| 13:33.32 | CIA-68 | BRL-CAD: 03brlcad * r45015 10/brlcad/trunk/include/bu.h: |
| 13:33.33 | CIA-68 | BRL-CAD: expand bu_structparse macros and typedef. since this struct has no magic, |
| 13:33.33 | CIA-68 | BRL-CAD: BU_STRUCTPARSE_IS_INITIALIZED() can only check whether the pointer is non-null. |
| 13:33.33 | CIA-68 | BRL-CAD: that's a reminder to make sure all the others are non-null before we dereference |
| 13:33.33 | CIA-68 | BRL-CAD: too. |
| 13:45.25 | CIA-68 | BRL-CAD: 03brlcad * r45016 10/brlcad/trunk/include/bu.h: can't just check the pointer for truthfulness since static variables will always return true. fake out the compiler via a pointer cast and comparison to NULL. |
| 14:00.44 | brlcad | aaand we pause there since bu_external is a bit of a doosie |
| 15:09.48 | dloman | ``Erik: you around? |
| 15:10.29 | dloman | ``Erik: Well, whenever you are, check this out. kinda neat: http://www.dennisantinori.com/Resources/Ringworld/ |
| 15:44.16 | dloman | wow, there's a Lego CAD app: http://www.ldraw.org |
| 15:44.18 | dloman | awesome |
| 16:19.27 | CIA-68 | BRL-CAD: 03brlcad * r45017 10/brlcad/trunk/src/libbu/CMakeLists.txt: sync. add basenametester compilation. |
| 16:32.05 | CIA-68 | BRL-CAD: 03starseeker * r45018 10/brlcad/trunk/ (6 files in 4 dirs): This is an intermediate phase and I doubt it's working, but I need to checkpoint - reworking distcheck logic to be cleaner, more robust, etc. |
| 16:40.17 | *** join/#brlcad bhinesley (~bhinesley@99.144.90.118) | |
| 16:48.54 | brlcad | starseeker: what's the equivalent of noinst_BINARIES ? |
| 16:51.38 | CIA-68 | BRL-CAD: 03brlcad * r45019 10/brlcad/trunk/NEWS: past tense rewrite. cliff fixed a bug in archer's tree view widget to highlight related objects. |
| 16:59.59 | *** join/#brlcad bhinesley (~bhinesley@99.144.90.118) | |
| 17:01.21 | CIA-68 | BRL-CAD: 03brlcad * r45020 10/brlcad/trunk/NEWS: brandon improved the ls command error reporting in archer where before it wouldn't report an error for partial failures if you 'ls valid invalid'. now it at least displays the lookup failure. |
| 17:06.07 | bhinesley | brlcad: actually, it doesn't display an error in Archer, it just doesn't echo invalid names anymore. The problem with returning the error in the struct ged's return string, is that mged would display the error, too... so it would break any scripted uses of ls. |
| 17:07.18 | bhinesley | plus, I'd have to to a quiet db_lookup, so that mged didn't show two error messages. |
| 17:07.29 | bhinesley | *to do |
| 17:10.53 | *** join/#brlcad Stattrav (~Stattrav@122.167.214.98) | |
| 17:10.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:19.43 | CIA-68 | BRL-CAD: 03davidloman * r45021 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ByteBufferReader.java: Make the ByteBuffer copy in the ByteBufferReader cstr optional. Reduces the amount of mallocs significantly. |
| 17:21.05 | brlcad | bhinesley: ah, okay -- misunderstood your commit message |
| 17:21.43 | brlcad | fortunately the news line itself is vague enough that it still applies |
| 17:21.48 | bhinesley | nods |
| 17:21.55 | brlcad | it's improved, just not the way the comment says ;) |
| 17:32.47 | CIA-68 | BRL-CAD: 03brlcad * r45022 10/brlcad/trunk/doc/deprecation.txt: |
| 17:32.47 | CIA-68 | BRL-CAD: unlike the other lists, finding the latest minimally impacting change needs to |
| 17:32.47 | CIA-68 | BRL-CAD: be deterministic. so list them in chronological order so the most recent are at |
| 17:32.47 | CIA-68 | BRL-CAD: the end of the file. the same doesn't hold true for the incompatible changes so |
| 17:32.47 | CIA-68 | BRL-CAD: leave them in reverse chrono order. |
| 17:38.05 | CIA-68 | BRL-CAD: 03brlcad * r45023 10/brlcad/trunk/doc/deprecation.txt: with the list now in chrono order, go ahead and add the massive 6.0 release API overhaul (sed script lines) |
| 17:39.14 | CIA-68 | BRL-CAD: 03brlcad * r45024 10/brlcad/trunk/include/ (Makefile.am sed4): the old sed4 script is no more. see doc/deprecation for the goods and additional API changes. |
| 17:53.55 | CIA-68 | BRL-CAD: 03brlcad * r45025 10/brlcad/trunk/doc/deprecation.txt: |
| 17:53.55 | CIA-68 | BRL-CAD: BU_INIT_EXTERNAL() to be renamed to BU_EXTERNAL_INIT() so the API is consistent. |
| 17:53.55 | CIA-68 | BRL-CAD: same for RT_INIT_DB_INTERNAL. both have been around for a long while, so some |
| 17:53.55 | CIA-68 | BRL-CAD: external code updates shold be expected. alas, they are still minimally |
| 17:53.55 | CIA-68 | BRL-CAD: impacting API changes. |
| 17:56.50 | CIA-68 | BRL-CAD: 03davidloman * r45026 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/NetMsgFactory.java: Remove try/catch block from NetMsgFactory.makeMsg() We want any exceptions to be thrown to the caller of NetMsgFactory.makeMsg() so they can deal with it appropriately. |
| 17:59.44 | CIA-68 | BRL-CAD: 03Sean 07http://brlcad.org * r2921 10/wiki/Community_Publication_Portal: as more API changes are made, we'll need to talk about the deprecation process |
| 18:00.53 | CIA-68 | BRL-CAD: 03brlcad * r45027 10/brlcad/trunk/ (25 files in 13 dirs): |
| 18:00.53 | CIA-68 | BRL-CAD: rename BU_INIT_EXTERNAL() to BU_EXTERNAL_INIT() so that the API is consistent. |
| 18:00.53 | CIA-68 | BRL-CAD: as this symbol is so frequently used, it's likely to affect external codes but |
| 18:00.53 | CIA-68 | BRL-CAD: the change is still minimally impacting and trivial to accommodate. |
| 18:09.20 | CIA-68 | BRL-CAD: 03starseeker * r45028 10/brlcad/trunk/src/other/dlists/ (19 files): Whoops - helps to commit everything. |
| 18:09.42 | starseeker | brlcad: erm. what did noinst_BINARIES do? |
| 18:10.47 | starseeker | if you want to build a binary that you're not wanting to install, just do add_executable followed by target_link_libraries |
| 18:11.33 | starseeker | take a look at htester and timetester in libbu |
| 18:14.07 | CIA-68 | BRL-CAD: 03brlcad * r45029 10/brlcad/trunk/ (5 files in 4 dirs): rename RT_CK_DBTR and RT_DBTR_MAGIC to RT_CK_DB_TRAVERSE and RT_DB_TRAVERSE_INIT for api consistency. |
| 18:19.32 | CIA-68 | BRL-CAD: 03brlcad * r45030 10/brlcad/trunk/doc/deprecation.txt: last jump, renaming all of the RT_INIT_[type] macros to RT_[type]_INIT for API consistency. this unfortunately affects a LOT of code (including 3rd party) but it's minimally impacting and improves the API. |
| 18:21.25 | *** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ) | |
| 18:24.10 | CIA-68 | BRL-CAD: 03brlcad * r45031 10/brlcad/trunk/doc/deprecation.txt: RT_INIT_DB_INTERNAL is included in the more general case so remove it |
| 18:27.41 | CIA-68 | BRL-CAD: 03brlcad * r45032 10/brlcad/trunk/ (93 files in 32 dirs): API consistency overhaul. all struct INIT routines are now all RT_[type]_INIT() instead of being a mix of INIT before and after the type. 's/RT_INIT_([A-Z_]*)/RT_\1_INIT/g' |
| 18:28.20 | CIA-68 | BRL-CAD: 03brlcad * r45033 10/geomcore/trunk/ (5 files in 3 dirs): update to the API changes on trunk for libbu and libbn. INIT now trails the type. you'll have to update your installed brlcad headers for this one. |
| 18:30.56 | CIA-68 | BRL-CAD: 03davidloman * r45034 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/NetMsgChangeTracker.java: Loosen restrictions on NetMsgChangeTracker. Make it a simple data container. Shift from using byte to int for change value. No need to optimize memory useage quite yet. |
| 18:31.03 | CIA-68 | BRL-CAD: 03brlcad * r45035 10/brlcad/trunk/misc/Doxyfile: BU_EXTERN is no more |
| 18:31.40 | CIA-68 | BRL-CAD: 03brlcad * r45036 10/geomcore/trunk/doc/doxygen/Doxyfile.in: BU_EXTERN is no more |
| 18:32.57 | brlcad | starseeker: it does exactly what you described, builds but doesn't install -- so then what do I add to install it in addition to add_exec and target_link_.. ? |
| 18:35.15 | brlcad | mmmmee no likie the .dist files .. that's even more error prone than how we do it for autotools... |
| 18:36.21 | brlcad | should at least be localized to each dir's CMakeLists.txt file akin to EXTRA_DIST, not in some remote dir (out of sight, out of mind) |
| 18:36.50 | brlcad | better would be to pull the svn manifest |
| 18:37.09 | starseeker | I'm trying to set this up so we don't have to put anything extra in the src/other directory in cases where the src/other directory has its own CMakeLists.txt file |
| 18:38.06 | starseeker | previously everything was in src/other/CMakeLists.txt, which was really messing with the readibility of that file |
| 18:38.15 | brlcad | is the problem because there's just one CMakeLists.txt file for all of the src/other targets? |
| 18:38.46 | starseeker | no - the problem is we can't count on src/other CMake logic to give us what we need for distcheck |
| 18:39.58 | starseeker | I have been working very hard with the src/other design to get as close as I possibly can to being able to just "drop in" a CMakeified src/other library and have it "just work" |
| 18:40.17 | brlcad | the problem is the separation of the file list from the actual files .. instantly out of sync and the dev can't really be faulted for missing it |
| 18:40.46 | starseeker | make distcheck will show it instantly (first thing checked, in fact) |
| 18:41.07 | brlcad | what about at least making the files more visible? |
| 18:41.20 | starseeker | how-so? store them toplevel in src/other? |
| 18:41.22 | brlcad | mv dlists/*.dist . |
| 18:41.28 | starseeker | I did that initially, but it seemed messy |
| 18:41.28 | brlcad | make the file name match the dir name |
| 18:41.46 | brlcad | it is messy, but less error prone |
| 18:41.53 | starseeker | shrugs - sure, not a problem |
| 18:42.02 | brlcad | hopefully reminded every time you cd into a dir to add/update a file that there is a dist list that probably needs updating |
| 18:42.14 | starseeker | nods |
| 18:44.12 | brlcad | does distcheck look at the svn manifest to compare then? |
| 18:44.56 | starseeker | not in that stage |
| 18:45.06 | starseeker | it's using the CMake build logic itself |
| 18:45.14 | brlcad | how does it know when something is missing? |
| 18:46.20 | starseeker | there's an error routine that reports when you try to ignore something that isn't present, and CMake itself wipes out if you try to call out a file in the build logic that isn't there |
| 18:46.45 | brlcad | unrelated, was the 7.20.0 windows release made with cmake or the msvc files? someone asking if step-g is included |
| 18:46.49 | starseeker | I was assuming we wanted it to function without svn... |
| 18:47.23 | starseeker | CMake, but step-g doesn't build on Windows right now |
| 18:47.30 | starseeker | (that depends on the flex/byacc stuff) |
| 18:47.56 | starseeker | That's high on my todo list, once I get my current mess cleaned up |
| 18:48.57 | starseeker | brlcad: I'm in-process on reworking the distcheck logic - I didn't really want to commit yet, but it was getting too complex to keep going without some sort of checkpoint - I'll give a shout-out when it looks ready for testing |
| 18:50.24 | brlcad | definitely should work if SVN isn't available, but doesn't mean it can't leverage when it clearly is available too |
| 18:51.10 | brlcad | that's what autotools distcheck does now (see dist-hook: in top-level Makefile.am, first line) |
| 18:51.46 | CIA-68 | BRL-CAD: 03starseeker * r45037 10/brlcad/trunk/ (40 files in 4 dirs): move the dist lists to src/other toplevel. |
| 18:51.57 | brlcad | basically, for any entries files it finds (i.e., manifest files), make sure the files listed are in the dist |
| 18:51.59 | starseeker | brlcad: I've got two separate checks - one to see if the build logic covers the files, and then (if svn is available) to see if svn status reports anything |
| 18:52.22 | brlcad | svn status? |
| 18:52.32 | starseeker | checks for un-committed changes |
| 18:52.37 | brlcad | hm, ok |
| 18:52.39 | starseeker | or files svn doesn't know about |
| 18:52.54 | brlcad | I always have dozens or hundreds of those, works in progress |
| 18:53.28 | starseeker | the assumption is that for a tarball build a clean checkout will be used - CPack grabs everything not on it's exclude list |
| 18:53.59 | brlcad | that'll take some getting used to |
| 18:54.53 | starseeker | 's take on it was that it's way simpler to do a clean checkout and use that than to try and maintain all the logic to sort out what should and shouldn't be included from a working tree |
| 18:55.26 | brlcad | simpler, sure .. but much more time consuming :) |
| 18:55.45 | starseeker | really? for me a clean tree checkout is a drob in the bucket compared to the rest of the checklist |
| 18:56.19 | starseeker | I usually do it anyway just to try and make sure I haven't messed up getting something in to svn |
| 18:57.12 | brlcad | well that's why it's also important to make the dist, then do distchecks on the dist tarball since that's what's actually uploaded |
| 18:57.25 | brlcad | that's my "clean checkout" there |
| 18:57.52 | brlcad | no extra download, I should test the final build regardless |
| 19:00.32 | brlcad | no matter, the bigger issue is that we make sure all files that are in a checkout are in the dist (including simple doc/text files that aren't listed in build rules) -- however that happens |
| 19:01.00 | starseeker | nods - let me finish ironing out the bugs of this rework and I'll volunteer it for a stress test |
| 19:02.09 | brlcad | pulling the manifest is the easiest (only?) way to ensure files get included |
| 19:02.14 | brlcad | nods |
| 19:09.43 | CIA-68 | BRL-CAD: 03starseeker * r45038 10/brlcad/trunk/src/other/dlists/: remove dlists dir |
| 19:10.55 | brlcad | starseeker: new files missing from src/other/Makefile.am :) ... have to maintain both just a while longer |
| 19:12.09 | CIA-68 | BRL-CAD: 03starseeker * r45039 10/brlcad/trunk/src/other/togl/demo/CMakeLists.txt: rather than turning this off completely, disable it on WIN32 for now. Should eventually fix this |
| 19:13.24 | starseeker | brlcad: yeah, I know - figured I'd update those when the dust settles |
| 19:16.24 | brlcad | only mentioning it because it'll halt my build testing in the meantime -- I have a continuous distcheck build loop going for all of the API changes I've been making |
| 19:16.40 | brlcad | lots more to go, so it helps make sure I don't accidentally break the build for more than a few minutes |
| 19:18.26 | starseeker | winces - sorry |
| 19:20.55 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 19:25.12 | dloman | oh dayum: http://www.youtube.com/watch?v=PNFAsKwCCHw&feature=feedrec_grec_index |
| 19:40.48 | brlcad | bhinesley: if you're looking for a refactoring, merging erase and erase_all into one command would be a good one |
| 19:41.28 | brlcad | the latter as an option to the prior, unify syntax |
| 19:42.08 | bhinesley | alright, that sounds good. I'm trying to see what migrating oed is going to take right now. |
| 19:42.39 | starseeker | bhinesley: heh - watch out for that one |
| 19:42.48 | bhinesley | er rather, oed-related translations, since we want it stateless |
| 19:43.41 | bhinesley | starseeker: yeah, I'm starting to wonder what I got myself into :) |
| 19:43.56 | starseeker | brlcad: hrm. how did you want to see oed translated into Archer, now that I think about it? |
| 19:44.28 | brlcad | kunigami: how's it going? progress on the crashes? |
| 19:45.25 | brlcad | fwiw, memory leaks don't generally lead to crashes -- overrunning bounds and resource contention do, though |
| 19:46.21 | brlcad | starseeker: oed becomes a standard set of options for the translate, rotate, and scale commands |
| 19:46.34 | brlcad | so oed itself doesn't migrate, but what it does .. does |
| 19:46.44 | brlcad | i.e., sets up a selection and a keypoint |
| 19:47.32 | CIA-68 | BRL-CAD: 03starseeker * r45040 10/brlcad/trunk/ (8 files in 8 dirs): Hmm. OK, that's promising - distcheck called out some files that, upon examination, make sense. This might do it, but needs a LOT more checking/hammering. |
| 19:48.00 | brlcad | oed itself might just turn into a simple keypoint option |
| 19:51.43 | kunigami | brlcad: I kinda ignored the crashes by now, since it seems to be a multi-thread issue. I've been using P=1 and no problems happened until now |
| 19:57.42 | CIA-68 | BRL-CAD: 03starseeker * r45041 10/brlcad/trunk/src/other/ (URToolkit.dist step.dist): couple dist additions that got swatted in the move. |
| 19:57.44 | brlcad | ignoring syntax and whatever the current code does, you basically have: {translate|rotate|scale} [--keypoint {bb_corner|bb_center}:{object_name} | {3d position}] [--relative xdist [ydist [zdist]] | --absolute xpos [ypos [zpos]]] [object(s)] |
| 19:58.45 | brlcad | not exact, of course, since rotate is relative or absolute angles or ypr or aet and scale is relative or aboslute scale factors |
| 19:59.19 | brlcad | but oed is basically that --keypoint option |
| 20:00.12 | brlcad | specifically one subset where it's bb_default which is usually the bottom left corner of the object |
| 20:00.49 | brlcad | or some other "natural" origin |
| 20:01.42 | brlcad | kunigami: ah, okay .. so then if you got a disk shaded using your yellow osl shader, what happens if you set it to one of the other default osl shaders? |
| 20:02.22 | kunigami | I tried using the mirror shader, but I renders to black, but I'm not doing recursion right |
| 20:02.45 | brlcad | ouch |
| 20:02.48 | brlcad | wouldn't start with mirror :) |
| 20:02.51 | brlcad | try something diffuse :) |
| 20:03.26 | brlcad | they have a phong or gouraud shader? |
| 20:04.00 | kunigami | the yellow shader was a (perfect) diffuse one |
| 20:04.32 | kunigami | now, I don't have such shader, but I can research about |
| 20:05.22 | brlcad | basically implemented a flat shader, not really diffuse |
| 20:05.45 | brlcad | if it were a curved surface, you should get highlight and shadow with diffuse |
| 20:06.19 | brlcad | I wouldn't spend time implementing shaders .. iirc, they had five or six example shaders |
| 20:07.17 | kunigami | the yellow shader is the same from the sphere of this image: http://kuniga.files.wordpress.com/2021/05/image.png |
| 20:07.39 | kunigami | maybe I'm not setting up the global parameters (normal, incident ray) correctly |
| 20:07.51 | kunigami | I'll try assigning it to a sphere |
| 20:09.17 | CIA-68 | BRL-CAD: 03brlcad * r45042 10/brlcad/trunk/include/raytrace.h: DBTR got expanded to DB_INTERNAL, no good. expand to DB_TRAVERSE. |
| 20:11.47 | brlcad | looks like some sort of path trace |
| 20:12.26 | brlcad | we have a cornell box in the db directory iirc, so you can play with similar scenes |
| 20:12.42 | brlcad | if not, it's trivial to set one up |
| 20:13.07 | CIA-68 | BRL-CAD: 03starseeker * r45043 10/brlcad/trunk/misc/CMake/distcheck_buildsys.cmake.in: Remove debug messages |
| 20:15.30 | kunigami | yeah, I added a sphere to the scene, but it was rendered as a yellow circle >.< |
| 20:16.19 | kunigami | gotta take a look at the parameters. just for clarification: u and v and their dP/du and dP/dv are only useful if we're going to do some kind of mapping, right? |
| 20:16.53 | brlcad | yes for u/v .. what's the dP/du you're referring to? |
| 20:17.37 | brlcad | the normal isn't necessarily calculated by default -- you'll probably need that to calculate a diffuse falloff |
| 20:17.38 | kunigami | as far as I understood P is the hit point and dP/du are the derivatives regarding u and v directions |
| 20:18.05 | kunigami | hmm, I was setting the normal from swp->sw_hit.hit_normal |
| 20:19.00 | brlcad | I'd make sure that value has been calculated, you may need to call RT_HIT_NORMAL() |
| 20:20.06 | kunigami | I added MFI_NORMAL on mfuncs, but I'll double check |
| 20:20.32 | brlcad | ah, and for the other, yes -- those are all curvature related values, for texture/image mapping |
| 20:20.41 | brlcad | ah, okay |
| 20:24.26 | starseeker | brlcad: ERROR: bad pointer 0xd7fc488: s/b bu_vls(x89333bbb), was Zero_Magic_Number(x0), file src/libbu/vls.c, line 301 |
| 20:24.41 | starseeker | shaders regression test |
| 20:26.55 | brlcad | backtrace? there was a couple places in the code that were calling BU_VLS_INIT_IF_UNINIT() unreliably, may need an explicit BU_VLS_INIT() now |
| 20:27.13 | starseeker | let me see if I can generate one, hang on... |
| 20:27.21 | brlcad | it should have auto-dumped one |
| 20:27.25 | brlcad | bomb.log |
| 20:29.41 | starseeker | hmm - don't see it |
| 20:29.44 | starseeker | one sec... |
| 20:30.31 | CIA-68 | BRL-CAD: 03brlcad * r45044 10/brlcad/trunk/TODO: merge erase/erase_all and notes on oed migration |
| 20:30.35 | brlcad | *-bomb.log |
| 20:31.40 | brlcad | kunigami: you may also need an osl light source for proper calcs, don't know |
| 20:31.48 | brlcad | I do recall an emitter shader for lights |
| 20:38.25 | starseeker | doesn't seem to be dropping a bomb log |
| 20:38.29 | brlcad | k |
| 20:46.07 | *** join/#brlcad CIA-62 (~CIA@cia.atheme.org) | |
| 20:49.33 | starseeker | feeding anything at all after the <<EOF seems to trigger the crash - not specific to any one command |
| 20:49.50 | starseeker | (in shaders.rt) |
| 20:50.00 | *** join/#brlcad dli (~dli@dsl-67-55-7-45.acanac.net) | |
| 20:51.58 | starseeker | ah hah |
| 20:51.58 | CIA-62 | BRL-CAD: 03brlcad * r45045 10/brlcad/trunk/src/libdm/dm-ogl.c: GL/gl.h needs the same protection as glx.h did. encountered y1 shadow warnings on mac 10.5, gcc4.0.1 |
| 20:52.42 | CIA-62 | BRL-CAD: 03brlcad * r45046 10/brlcad/trunk/src/mged/dm-ogl.c: GL headers need the same protections used in libdm's dm-ogl.c file so we don't get shadow warnings and compilation failure. |
| 20:55.10 | starseeker | brlcad: here we go: http://pastebin.mozilla.org/1250287 |
| 20:56.00 | CIA-62 | BRL-CAD: 03brlcad * r45047 10/brlcad/trunk/src/libdm/focus.c: |
| 20:56.00 | CIA-62 | BRL-CAD: may need revisiting, but unsetting and resetting __GNUC_MINOR__ (gcc 4.0.1, mac |
| 20:56.00 | CIA-62 | BRL-CAD: 10.5) leaves the compiler in some odd state where subsequent header inclusion |
| 20:56.00 | CIA-62 | BRL-CAD: still think it is undefined (even though #ifdef before their inclusion shows it |
| 20:56.00 | CIA-62 | BRL-CAD: is!). removing the protections makes things work again so will have to |
| 20:56.00 | CIA-62 | BRL-CAD: rediscover a different fix for whatever environment was failing if it still |
| 20:56.01 | CIA-62 | BRL-CAD: fails. |
| 21:28.11 | *** join/#brlcad merzo (~merzo@48-55-133-95.pool.ukrtel.net) | |
| 21:29.51 | kunigami | brlcad: the parameters seems right. the problem, I think, comes from the fact that I'm not considering recursion. The osl-system returns only the color of the sphere, but I think the attenuation will depend on the ray going out towards the light and the sphere normal |
| 21:54.42 | *** join/#brlcad crazy_imp (~mj@a89-182-252-199.net-htp.de) | |
| 22:33.51 | CIA-62 | BRL-CAD: 03brlcad * r45048 10/brlcad/trunk/src/libbu/brlcad_path.c: can't bu_free() a static buffer. supposed to be tmp_basename from bu_basename(). |
| 22:59.32 | *** join/#brlcad DarkCalf (DC@2002:ade7:2862::ade7:2862) | |
| 23:01.25 | CIA-62 | BRL-CAD: 03brlcad * r45049 10/brlcad/trunk/src/libbu/basenametester.c: quell warning, call bu_fgets() instead of calling fgets() directly. |
| 23:08.38 | CIA-62 | BRL-CAD: 03bhinesley * r45050 10/brlcad/trunk/ (13 files in 8 dirs): |
| 23:08.39 | CIA-62 | BRL-CAD: Removed all occurences of erase_all command and the dall alias. The same |
| 23:08.39 | CIA-62 | BRL-CAD: operation is now performed by "erase -r". Usage statement corrected to no longer |
| 23:08.39 | CIA-62 | BRL-CAD: print first arg instead of cmd name. Fixed ArcherCore::erase that was using |
| 23:08.39 | CIA-62 | BRL-CAD: lappend without initialization. Updated NEWS. |
| 23:09.35 | bhinesley | hm. it says that the commit failed |
| 23:23.53 | bhinesley | good god sf, it's one line, commit already |
| 23:26.47 | CIA-62 | BRL-CAD: 03bhinesley * r45051 10/brlcad/trunk/src/libged/erase.c: Revised usage statement to make it clear that if -r is specified, all other options are ignored. |
| 23:27.50 | bhinesley | puts away the plunger |
| 23:42.14 | *** join/#brlcad piksi_ (piksi@pi-xi.net) | |
| 23:42.18 | *** join/#brlcad dloman_ (~claymore@BZ.BZFLAG.BZ) | |
| 23:43.08 | CIA-62 | BRL-CAD: 03brlcad * r45052 10/brlcad/trunk/regress/shaders.sh: document in detail why shaders must run single-threaded (it's because of the random transparency shader). also pass extra parameters normally -- no need for them to be in the rt script file. |
| 23:44.51 | CIA-62 | BRL-CAD: 03brlcad * r45053 10/brlcad/trunk/src/liboptical/sh_prj.c: |
| 23:44.52 | CIA-62 | BRL-CAD: fix the uninitialized vls bug reported by starseeker. indeed, the source name |
| 23:44.52 | CIA-62 | BRL-CAD: of the shader was not being initialized properly before bu_structparse expands a |
| 23:44.52 | CIA-62 | BRL-CAD: %V table entry and calls bu_vls_strcpy(). instead of just initializing the vls, |
| 23:44.52 | CIA-62 | BRL-CAD: though, go ahead and initialize the entire img_specific struct just because it's |
| 23:44.53 | CIA-62 | BRL-CAD: the awesome thing to do. profile showed performance unaffected by the setup |
| 23:44.54 | CIA-62 | BRL-CAD: memcpy(). |
| 23:52.13 | *** part/#brlcad bhinesley (~bhinesley@99.144.90.118) | |
| 23:52.20 | *** join/#brlcad bhinesley (~bhinesley@99.144.90.118) | |
| 23:59.59 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 23:59.59 | *** join/#brlcad dtidrow (~dtidrow@c-68-60-53-123.hsd1.mi.comcast.net) | |
| 00:24.28 | *** join/#brlcad Stattrav (~Stattrav@117.192.129.172) | |
| 00:24.32 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 00:28.53 | *** join/#brlcad crazy_imp (~mj@89.182.175.97) | |
| 00:49.32 | *** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 03:45.01 | CIA-62 | BRL-CAD: 03brlcad * r45054 10/brlcad/trunk/src/libbu/ (CMakeLists.txt Makefile.am brlcad_path.c progname.c): |
| 03:45.01 | CIA-62 | BRL-CAD: move bu_argv0_full_path(), bu_argv0(), bu_getprogname(), bu_setprogname() and |
| 03:45.01 | CIA-62 | BRL-CAD: their helper functions (_bu_ipwd() and _bu_argv0()) from brlcad_path.c to |
| 03:45.01 | CIA-62 | BRL-CAD: progname.c since they have nothing to do with our intrinsic search data/root |
| 03:45.01 | CIA-62 | BRL-CAD: search logic. |
| 03:51.18 | CIA-62 | BRL-CAD: 03brlcad * r45055 10/brlcad/trunk/src/libbu/ (brlcad_path.c progname.c): sys/param.h provides MAXPATHLEN, document it for posterity |
| 05:30.43 | CIA-62 | BRL-CAD: 03brlcad * r45056 10/brlcad/trunk/src/libged/erase.c: quell warning due to bad pointer dereference juju. argv[0] was the intended target. |
| 05:58.29 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 06:35.46 | CIA-62 | BRL-CAD: 03brlcad * r45057 10/brlcad/trunk/src/libbu/progname.c: no need for buffer to be static. just makes for multithreading nasty. |
| 06:40.09 | CIA-62 | BRL-CAD: 03brlcad * r45058 10/brlcad/trunk/src/libbu/ (CMakeLists.txt Makefile.am getcwd.c): |
| 06:40.09 | CIA-62 | BRL-CAD: stub in an initial bu_getcwd() implementation that uses getcwd() and getenv(PWD) |
| 06:40.09 | CIA-62 | BRL-CAD: for determining the current working directory. untested on win32 (try _getcwd() |
| 06:40.09 | CIA-62 | BRL-CAD: and _fullpath()) too, but it's the start of a replacement for _bu_ipwd(). |
| 06:40.42 | CIA-62 | BRL-CAD: 03brlcad * r45059 10/brlcad/trunk/ (CMakeLists.txt configure.ac): need to test for getcwd for libbu's bu_getcwd() function. |
| 06:44.50 | CIA-62 | BRL-CAD: 03brlcad * r45060 10/brlcad/trunk/include/bu.h: finish up the bu_external init macros and typedef |
| 06:45.54 | brlcad | pauses |
| 06:59.02 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 08:18.28 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 08:31.17 | *** join/#brlcad dli (~dli@dsl-67-55-7-45.acanac.net) | |
| 10:15.33 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:38.30 | dloman_ | sheesh! 0245! Littlefoot helping you stay up and code? :) |
| 11:45.09 | dloman_ | oh wow, lol: http://www.youtube.com/watch?v=CFuyE_VBeO8&feature=player_embedded#at=338 |
| 12:53.22 | brlcad | hehehe |
| 12:53.29 | brlcad | that's pretty good |
| 12:57.39 | CIA-62 | BRL-CAD: 03brlcad * r45061 10/brlcad/trunk/src/libbu/basenametester.c: add header |
| 13:01.54 | dloman_ | had trouble not envisioning snakes on a plane :) |
| 13:03.38 | CIA-62 | BRL-CAD: 03brlcad * r45062 10/brlcad/trunk/src/libbu/basenametester.c: protect the header inclusion, sys headers before brl-cad headers |
| 13:17.46 | CIA-62 | BRL-CAD: 03brlcad * r45063 10/brlcad/trunk/src/libbu/basenametester.c: fingers have a mind of thier own. libgen not libged |
| 13:27.10 | CIA-62 | BRL-CAD: 03brlcad * r45064 10/brlcad/trunk/src/libbu/progname.c: prevent a crash inside setprogname if we're passed a NULL argv0. |
| 13:46.28 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:04.43 | CIA-62 | BRL-CAD: 03brlcad * r45065 10/brlcad/trunk/src/libbu/progname.c: the _bu_ipwd() calls are temporary, denote that |
| 14:09.42 | CIA-62 | BRL-CAD: 03brlcad * r45066 10/brlcad/trunk/include/bu.h: bu_argv0_full_path() wasn't a very good idea either. declare bu_getcwd() as the new coke. |
| 14:21.02 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 14:24.23 | CIA-62 | BRL-CAD: 03d_rossberg * r45067 10/brlcad/trunk/include/raytrace.h: quell warnings (and probable misinterpretation) in MSVC |
| 14:34.36 | CIA-62 | BRL-CAD: 03brlcad * r45068 10/brlcad/trunk/src/libbu/progname.c: |
| 14:34.36 | CIA-62 | BRL-CAD: simplify bu_getprogname(). forget about trying to cash the progname result and |
| 14:34.36 | CIA-62 | BRL-CAD: just re-evaluate the name again. this is necessary anyways in case the caller |
| 14:34.36 | CIA-62 | BRL-CAD: repeatedly calls bu_setprogname() with different values. also add protection |
| 14:34.36 | CIA-62 | BRL-CAD: from bu_basename() which will return '.' or '/' for some strings and that's not |
| 14:34.37 | CIA-62 | BRL-CAD: very useful. |
| 14:36.32 | CIA-62 | BRL-CAD: 03d_rossberg * r45069 10/brlcad/trunk/ (7 files in 7 dirs): |
| 14:36.32 | CIA-62 | BRL-CAD: enabled the build of static libs for MSVC |
| 14:36.32 | CIA-62 | BRL-CAD: Static libs shouldn't export symbols like the DLLs because they are linked |
| 14:36.32 | CIA-62 | BRL-CAD: directly. Thats why the BRLCAD_DLL flag will be set for DLLs only. The |
| 14:36.32 | CIA-62 | BRL-CAD: BRLCAD_ADDLIB and BRLCAD_ADDEXEC macros are setting this flag automatically. If |
| 14:36.33 | CIA-62 | BRL-CAD: they are not used the BRLCAD_DLL flag has to be set manually if needed. |
| 14:39.33 | CIA-62 | BRL-CAD: 03d_rossberg * r45070 10/brlcad/trunk/src/librt/CMakeLists.txt: enabled export of TIE (Triangle Index Table) symbols for MSVC |
| 14:45.46 | CIA-62 | BRL-CAD: 03brlcad * r45071 10/brlcad/trunk/src/libbu/ (CMakeLists.txt Makefile.am prognametester.c): add a new unit test for bu_getprogname/bu_setprogname. already helped uncover and fix three bugs. |
| 14:51.38 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2922 10/wiki/Community_Publications_Portal: redirect plural |
| 15:05.42 | *** join/#brlcad piksi_ (piksi@pi-xi.net) | |
| 15:09.18 | starseeker | hmm: http://code.google.com/p/thrust/ |
| 15:12.44 | dloman_ | neato! |
| 16:24.56 | kunigami | does the ray direction ever changes in rt? I'm printing application->a_ray.r_dir and it is always the same |
| 17:22.27 | bhinesley | brlcad: Did you want to migrate MGED to the new oed translations, or just Archer? |
| 17:54.59 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-125-86-110.dsl.bkfd14.sbcglobal.net) | |
| 18:16.21 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:46.57 | brlcad | kunigami: shaders can change the ray direction, refraction on phong for example |
| 18:47.40 | brlcad | bhinesley: for oed, both and neither |
| 18:48.24 | brlcad | libged really, so mged will get access to the newer stateless version, but oed doesn't have to go away from mged nor get ported to archer (as a new command) .. it's functionality is just added to libged and accessible to both |
| 18:48.58 | brlcad | no command logic should really be going into archer or mged at this point -- it should be a trivial wrapper on both sides that just calls through to libged |
| 18:51.27 | bhinesley | so the current oed translations are going away in favor of the one migrated into libged |
| 18:51.56 | bhinesley | I just wasn't sure if we wanted to change the way mged oed currently works |
| 18:54.46 | bhinesley | okay, what I said may be misinterpreted... so I'll just say that I realize that the new command belongs in libged :) |
| 18:55.37 | CIA-62 | BRL-CAD: 03starseeker * r45072 10/brlcad/trunk/CMakeLists.txt: Flag CMAKE_SYSTEM_IGNORE_PATH as advanced |
| 18:56.14 | CIA-62 | BRL-CAD: 03brlcad * r45073 10/brlcad/trunk/include/bu.h: add missing macros and typedef for bu_color struct. |
| 18:57.44 | CIA-62 | BRL-CAD: 03starseeker * r45074 10/brlcad/trunk/src/other/CMakeLists.txt: Get another stray variable marked as advanced. |
| 19:07.16 | kunigami | <PROTECTED> |
| 19:39.35 | CIA-62 | BRL-CAD: 03brlcad * r45075 10/brlcad/trunk/ (17 files in 5 dirs): consistency, rename the bu_rb_tree struct typedef to bu_rb_tree_t and make bu_rb_tree be the name of the struct like the other bu structs. |
| 20:07.04 | brlcad | bhinesley: yeah, the current system in mged is very modal |
| 20:07.14 | brlcad | you enter an edit mode, then perform edit operations |
| 20:07.33 | brlcad | the goal is towards being completely modeless, so you just perform operations |
| 20:07.52 | brlcad | oed's entire purpose is to enter a mode, set up a selection, and set up a keypoint |
| 20:07.55 | brlcad | the mode isn't necessary |
| 20:08.24 | brlcad | the selection is simple object names on other commands (translate/rotate/scale) |
| 20:08.44 | brlcad | the keypoint becomes the main feature that needs to migrate as an option with reasonable defaults |
| 20:09.27 | brlcad | kunigami: that would be perspective mode (-p##) |
| 20:09.40 | brlcad | default rendering is orthogonal rays |
| 20:10.22 | brlcad | rt supports both, naturally |
| 20:12.37 | CIA-62 | BRL-CAD: 03starseeker * r45076 10/brlcad/trunk/CMakeLists.txt: We require cmake 2.8, and 2.6 and later treat CPACK_STRIP_FILES as a boolean variable - no reason for this logic anymore (which may not have been correct to start with) |
| 20:16.48 | kunigami | hmm I think I was not clear. In this image: http://www.devmaster.net/articles/raytracing_series/part1.2.jpg there are several rays going out from the camera, each of them have a particular direction |
| 20:17.33 | kunigami | I made a test and printed the direction of all rays sent to shootray, but all of them were the same |
| 20:17.43 | kunigami | (sent by rt application) |
| 20:21.19 | kunigami | the point is: how come can rays hit different objects if they seem to have the same direction? I'm studying how the hit detector works, but it probably uses another information that I'm missing... |
| 20:25.12 | CIA-62 | BRL-CAD: 03bob1961 * r45077 10/brlcad/trunk/src/libbu/basenametester.c: Call basename if HAVE_BASENAME. |
| 20:27.06 | CIA-62 | BRL-CAD: 03starseeker * r45078 10/brlcad/trunk/include/gcv.h: add a couple of gcv functions to gcv.h (need at lest gcv_bottess_region_end for windows...) |
| 21:01.53 | CIA-62 | BRL-CAD: 03bob1961 * r45079 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Make it so that a canvas located toolbar or menu is allowed only if mViewOnly is true. |
| 21:41.00 | CIA-62 | BRL-CAD: 03bhinesley * r45080 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: ls can just use gedWrapper |
| 23:04.35 | CIA-62 | BRL-CAD: 03bhinesley * r45081 10/brlcad/trunk/ (10 files in 6 dirs): In the process of adding the translate command to libged. In MGED, it is under translate2 for now. Archer throws a segmentation fault when I try to run it. |
| 23:05.46 | bhinesley | could someone take a look at this ^ for me? "Archer> translate" causes archer to throw a segfault. |
| 23:05.59 | bhinesley | not sure what I'm missing |
| 23:08.53 | ``Erik | gdb bin/bwish |
| 23:08.57 | ``Erik | run bin/archer |
| 23:09.03 | ``Erik | then, when it crashes, do a backtrace? |
| 23:11.17 | bhinesley | hey, thanks, that's a start |
| 23:11.36 | ``Erik | np, good luck tracking it |
| 23:11.56 | ``Erik | plenty of crash tutorials on using gdb can be found on the web :) |
| 23:37.13 | *** join/#brlcad Stattrav (~Stattrav@122.167.214.98) | |
| 23:37.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 23:54.05 | CIA-62 | BRL-CAD: 03bhinesley * r45082 10/brlcad/trunk/src/ (libtclcad/tclcad_obj.c tclscripts/archer/ArcherCore.tcl): Fixed Archer translate command segfault from r45081. Function callback was GED_FUNC_PTR_NULL rather than ged_translate. |
| 23:56.11 | bhinesley | ``Erik: that helped quite a bit, thanks again |
| 00:20.05 | dloman_ | hey ``Erik 's alive! |
| 00:28.14 | *** join/#brlcad crazy_imp (~mj@a89-182-140-122.net-htp.de) | |
| 00:47.39 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r2923 10/wiki/User:Bhinesley: /* Log */ Tuesday, yesterday, today, plan tomorrow |
| 02:04.07 | CIA-62 | BRL-CAD: 03starseeker * r45083 10/brlcad/trunk/src/other/ (140 files in 10 dirs): Put m4 and byacc back in. Hold off on flex until it's closer to actually building. |
| 03:07.15 | CIA-62 | BRL-CAD: 03bhinesley * r45084 10/brlcad/trunk/src/libged/translate.c: Started argument handling on translate cmd (nonfunctioning) |
| 03:23.26 | CIA-62 | BRL-CAD: 03bhinesley * r45085 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Disable translate's gedWrapper flags for now |
| 06:42.04 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 06:47.52 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 06:58.10 | CIA-62 | BRL-CAD: 03d_rossberg * r45086 10/brlcad/trunk/ (4 files in 4 dirs): |
| 06:58.10 | CIA-62 | BRL-CAD: included the brlcad.dll build into the overall CMake build |
| 06:58.10 | CIA-62 | BRL-CAD: it is switched off by default and can be enabled by setting the (advanced) option BRLCAD-ENABLE_BRLCAD_LIBRARY |
| 07:00.34 | *** part/#brlcad vtts (~vytautas@diz.ktu.lt) | |
| 07:02.28 | CIA-62 | BRL-CAD: 03d_rossberg * r45087 10/brlcad/trunk/src/other/openNURBS/CMakeLists.txt: under some conditions - most important one is BRLCAD-ENABLE_BRLCAD_LIBRARY - link with the static version of zlib |
| 07:57.06 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 08:25.59 | *** join/#brlcad dli (~dli@dsl-67-55-7-45.acanac.net) | |
| 08:25.59 | *** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 08:25.59 | *** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no) | |
| 08:34.48 | *** join/#brlcad dli (~dli@dsl-67-55-7-45.acanac.net) | |
| 08:34.48 | *** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 08:34.48 | *** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no) | |
| 10:08.46 | *** join/#brlcad Stattrav (~Stattrav@122.167.214.98) | |
| 10:08.46 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:38.27 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:48.22 | dloman_ | yawns |
| 11:51.31 | brlcad | yawns |
| 11:54.58 | brlcad | bhinesley: learning the basics of using gdb (or any debugger really) is one of the best tools you can learn |
| 11:55.21 | brlcad | graduating from printing statements to being able to step through code with a debugger is pretty big :) |
| 11:56.15 | brlcad | setting breakpoints, inspecting memory, walking up and down the stack, stepping through functions, ... |
| 11:56.18 | brlcad | good stuff :) |
| 11:57.16 | brlcad | kunigami: so that picture is exactly a diagram of perspective rays -- looks like approximately -p45 |
| 11:59.45 | brlcad | instead of divergent rays, the default raytrace uses *parallel* rays, so they're all in the same direction but with different start points |
| 12:00.12 | kunigami | brlcad: ahh I imagined that! thanks for the clarification |
| 12:10.18 | brlcad | if you take a perspective camera and move it backwards while simultaneously zooming the lens |
| 12:10.28 | brlcad | the rays will diverge less and less |
| 12:11.04 | brlcad | take that to the limit, with the camera at an infinite distance away and infinitely zoomed in on the view plane, and the rays become parallel |
| 12:11.37 | brlcad | it's called an orthogonal camera |
| 12:12.39 | brlcad | pretty much the default in all CAD systems and is the style of view that gives you perfect top-down views, side views, etc that you might see on a blueprint diagram |
| 12:32.53 | CIA-62 | BRL-CAD: 03brlcad * r45088 10/brlcad/trunk/include/bu.h: add macros for bu_rb_tree. bit more complicated struct to initialize and these macros aren't yet tested, so might need some tweaking. |
| 12:37.22 | kunigami | hmm interesting. and for zooming, instead of moving the camera nearer/farther from the projection plane you instead select a larger/smaller rectangle in this plane? |
| 12:48.50 | CIA-62 | BRL-CAD: 03brlcad * r45089 10/brlcad/trunk/include/bu.h: fix BU_VLB_INIT() and add macros/typedef for bu_observer. it's apparently not using the magic number, so pretend the magic is zero for now. |
| 12:49.23 | CIA-62 | BRL-CAD: 03davidloman * r45090 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ (GSConnection.java NetMsgFactory.java): Move all the ByteBuffer parsing fns over to NetMsgFactory where the rightly belong. Change functions to take pre-init-ed lists as args to minimize on the mallocs/frees. |
| 13:06.52 | CIA-62 | BRL-CAD: 03brlcad * r45091 10/brlcad/trunk/include/bu.h: add all of the macros and typedefs for the three bu hash structs: bu_hash_entry, bu_hash_tbl, bu_hash_record. untested macros. mm. bu_hash should probably get used a lot more throughout the code... |
| 13:12.46 | CIA-62 | BRL-CAD: 03brlcad * r45092 10/brlcad/trunk/include/bu.h: add macros and typedef for bu_image_file |
| 13:49.39 | brlcad | kunigami: not really, you basically just treat it like a completely different camera with parallel rays originating from the image plane in a grid |
| 13:49.47 | brlcad | it actually simplifies things |
| 13:50.27 | brlcad | rays still behave the same as they do in perspective mode, they're just originating from different points all going in the same direction |
| 13:50.47 | brlcad | woo hoo, that's all of the libbu structs! |
| 13:53.20 | dloman_ | yay |
| 13:53.22 | dloman_ | ! |
| 13:57.08 | ``Erik | dloman_: yup, alive, just got back from ocean city... ya doing a going away lunch or get-together? |
| 13:57.18 | dloman_ | did yesterday :( |
| 13:57.32 | ``Erik | doh! |
| 13:57.38 | dloman_ | but i have to come back in on the 23rd for a appt at Kirk Med Center, so we can do lunch then. |
| 14:00.48 | ``Erik | okie, cool beans |
| 14:01.00 | ``Erik | next thursday |
| 14:06.29 | CIA-62 | BRL-CAD: 03davidloman * r45093 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: Add back in the NULL test. Accidentally got deleted! |
| 14:07.01 | CIA-62 | BRL-CAD: 03davidloman * r45094 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSJavaInterface.java: Implement getList() |
| 14:08.22 | CIA-62 | BRL-CAD: 03davidloman * r45095 10/geomcore/trunk/src/clients/java/src/org/brlcad/geometryservice/minimalclient/cmd/ListCmd.java: Implement ListCmd |
| 15:03.54 | *** join/#brlcad Stattrav (~Stattrav@117.202.22.140) | |
| 15:03.54 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:18.15 | CIA-62 | BRL-CAD: 03brlcad * r45096 10/brlcad/trunk/ (configure.ac misc/Makefile.am misc/win32-msvc8/): the old msvc8 build system is no longer relevant. cmake is the new cake. |
| 16:24.20 | *** join/#brlcad Stattrav (~Stattrav@117.202.22.140) | |
| 16:24.20 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:08.19 | *** join/#brlcad dli (~dli@dsl-67-55-7-45.acanac.net) | |
| 17:08.19 | *** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 17:08.19 | *** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no) | |
| 17:16.08 | *** join/#brlcad dli (~dli@dsl-67-55-7-45.acanac.net) | |
| 17:16.08 | *** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 17:16.08 | *** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no) | |
| 17:22.25 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 17:48.10 | ``Erik | neat, my home box hit 400 days uptime |
| 17:48.29 | ``Erik | <PROTECTED> |
| 17:50.49 | ``Erik | neat, bz is at 501 days |
| 17:57.18 | CIA-62 | BRL-CAD: 03bob1961 * r45097 10/brlcad/trunk/src/ (libtclcad/tclcad_obj.c tclscripts/lib/Ged.tcl): A few more modes to accommodate windows. |
| 18:06.52 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-125-86-110.dsl.bkfd14.sbcglobal.net) | |
| 18:58.56 | *** join/#brlcad merzo (~merzo@177-195-133-95.pool.ukrtel.net) | |
| 19:28.34 | CIA-62 | BRL-CAD: 03bhinesley * r45098 10/brlcad/trunk/src/libged/translate.c: Basic short argument handling implemented for ged_translate |
| 19:56.45 | CIA-62 | BRL-CAD: 03starseeker * r45099 10/brlcad/trunk/src/other/ (51 files in 2 dirs): Add subset of flex and what build logic exists thus far - still have quite a few tests to add, but it does build and process the '%%' minimal file. Doubtful it really works as yet. |
| 20:05.34 | CIA-62 | BRL-CAD: 03bhinesley * r45100 10/brlcad/trunk/src/libged/translate.c: fix usage formatting |
| 20:28.00 | CIA-62 | BRL-CAD: 03starseeker * r45101 10/brlcad/trunk/ (CMakeLists.txt src/other/CMakeLists.txt): Remove the obsolete DISTCHECK_DIRS global property, more comments on flex. |
| 20:38.34 | *** join/#brlcad mac- (mac@mac.banda.pl) | |
| 20:38.37 | mac- | hi |
| 20:55.16 | brlcad | hello |
| 20:55.38 | brlcad | ``Erik: sounds like time to take it down then! |
| 20:55.47 | brlcad | that's what I was waiting for .... |
| 21:02.00 | *** join/#brlcad merzo (~merzo@177-195-133-95.pool.ukrtel.net) | |
| 21:47.02 | dloman_ | ``Erik: change of plans man. I found someone at Kirk to get me thru today, rather than thursday. Looks like I won't be in MD next week! :/ |
| 22:07.07 | CIA-62 | BRL-CAD: 03bhinesley * r45102 10/brlcad/trunk/src/libged/translate.c: More complete 'translate' argument handling |
| 00:28.29 | *** join/#brlcad crazy_imp (~mj@a89-182-172-216.net-htp.de) | |
| 06:42.54 | *** join/#brlcad Stattrav (~Stattrav@122.167.214.98) | |
| 06:42.54 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:19.24 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 10:07.41 | *** join/#brlcad mafm (~mafm@237.Red-83-45-72.dynamicIP.rima-tde.net) | |
| 13:11.19 | CIA-62 | BRL-CAD: 03kunigami * r45103 10/brlcad/trunk/src/liboptical/ (5 files): (log message trimmed) |
| 13:11.20 | CIA-62 | BRL-CAD: the osl-renderer now works with multiple osl shaders. Made several design |
| 13:11.20 | CIA-62 | BRL-CAD: changes to allow recursive rays... it now returns in the renderinfo struct |
| 13:11.20 | CIA-62 | BRL-CAD: information about the new ray that must be cast. the caller of the system must |
| 13:11.20 | CIA-62 | BRL-CAD: shoot the new ray. this is good because I imagine brl-cad shaders and osl |
| 13:11.20 | CIA-62 | BRL-CAD: shaders could be mixed. I've not tested this system with sh_osl, but rather |
| 13:11.20 | CIA-62 | BRL-CAD: osl_rt. on the other hand, I imagine the calling interface is essentially the |
| 15:31.28 | CIA-62 | BRL-CAD: 03brlcad * r45104 10/brlcad/trunk/src/proc-db/surfaceintersect.cpp: @Compare and @check are not valid doxygen. change to @brief ... |
| 15:39.32 | CIA-62 | BRL-CAD: 03brlcad * r45105 10/brlcad/trunk/include/raytrace.h: quell doxygen warning, 'command inside argument documentation' |
| 15:44.03 | CIA-62 | BRL-CAD: 03brlcad * r45106 10/brlcad/trunk/include/bu.h: clarify which file since there are multiple files named the same being processed by doxygen. |
| 15:45.37 | CIA-62 | BRL-CAD: 03brlcad * r45107 10/brlcad/trunk/src/adrt/isst_tcltk.c: file is not main.c |
| 15:45.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:05.45 | *** join/#brlcad Stattrav_ (~Stattrav@117.202.21.118) | |
| 17:33.58 | *** join/#brlcad crazy_imp (~mj@a89-182-196-105.net-htp.de) | |
| 18:01.37 | *** join/#brlcad Stattrav (~Stattrav@117.192.143.94) | |
| 18:01.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:41.31 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.136.225) | |
| 18:43.07 | *** join/#brlcad Stattrav1 (~Stattrav@117.192.136.225) | |
| 18:48.37 | *** join/#brlcad Stattrav (~Stattrav@117.192.136.225) | |
| 18:48.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:36.06 | *** join/#brlcad Stattrav (~Stattrav@117.192.136.225) | |
| 19:36.06 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 22:39.34 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 23:27.15 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 06:08.59 | *** join/#brlcad Stattrav (~Stattrav@117.202.16.74) | |
| 06:08.59 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:42.47 | *** join/#brlcad Stattrav (~Stattrav@117.192.143.117) | |
| 06:42.48 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:51.50 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:59.30 | *** join/#brlcad juan_man (~quassel@201.255.49.161) | |
| 06:59.38 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) | |
| 07:19.20 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 10:09.52 | *** join/#brlcad crazy_imp (~mj@a89-182-196-105.net-htp.de) | |
| 10:37.43 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:10.27 | *** join/#brlcad Stattrav (~Stattrav@117.202.24.155) | |
| 11:10.27 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:18.11 | *** join/#brlcad Stattrav (~Stattrav@117.202.24.155) | |
| 11:18.11 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:24.29 | *** join/#brlcad Stattrav (~Stattrav@117.202.24.155) | |
| 11:24.35 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:14.41 | CIA-62 | BRL-CAD: 03brlcad * r45108 10/brlcad/trunk/src/libbu/ (getcwd.c globals.c): be specific about which file's we're referring to for doxygen |
| 17:30.52 | *** join/#brlcad crazy_im1 (~mj@a89-182-181-206.net-htp.de) | |
| 17:57.44 | *** join/#brlcad kunigami_ (~kunigami@201.53.197.251) | |
| 19:17.31 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 23:00.10 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 23:05.57 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 01:20.46 | CIA-62 | BRL-CAD: 03brlcad * r45109 10/brlcad/trunk/include/bu.h: prefix all doxygen file markers with the library they belong to in order to avoid conflicts with same-named files in other directories being processed simultaneously. |
| 02:10.22 | CIA-62 | BRL-CAD: 03brlcad * r45110 10/brlcad/trunk/include/bu.h: this file isn't in the libbu dir |
| 02:11.22 | CIA-62 | BRL-CAD: 03brlcad * r45111 10/brlcad/trunk/src/libbn/ (22 files): prefix all of the doxygen file commands with libbn so we don't conflict with same-named files in other directories |
| 02:22.22 | CIA-62 | BRL-CAD: 03brlcad * r45112 10/brlcad/trunk/src/ (425 files in 15 dirs): prefix all of the library @file doxygen commands with the library dir/name in order to avoid conflicts with same-named files in other directories. was causing processing woes. |
| 02:26.07 | CIA-62 | BRL-CAD: 03brlcad * r45113 10/brlcad/trunk/src/ (168 files in 5 dirs): more @file prefixing in order to deconfuse doxygen bulk processing where file names are non-unique. |
| 02:40.31 | CIA-62 | BRL-CAD: 03brlcad * r45114 10/brlcad/trunk/src/ (469 files in 10 dirs): more @file directive clarification for doxygen to avoid naming conflicts with other same-named files in other directories. |
| 02:43.38 | CIA-62 | BRL-CAD: 03brlcad * r45115 10/brlcad/trunk/src/ (59 files in 3 dirs): few more @file doxygen conflict cases |
| 02:44.14 | CIA-62 | BRL-CAD: 03brlcad * r45116 10/brlcad/trunk/src/proc-db/brep_cube.cpp: proper header |
| 03:13.07 | CIA-62 | BRL-CAD: 03brlcad * r45117 10/brlcad/trunk/src/proc-db/ (brep_cube.cpp brep_simple.cpp csgbrep.cpp): header cleanup, refer to the proper filename |
| 03:17.22 | CIA-62 | BRL-CAD: 03brlcad * r45118 10/brlcad/trunk/src/vfont/vfont.h: filename is vfont |
| 03:21.09 | CIA-62 | BRL-CAD: 03brlcad * r45119 10/brlcad/trunk/include/vector_fpu.h: add missing common.h include for UNUSED() definition. |
| 03:25.55 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 07:02.21 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 08:16.14 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 09:05.10 | *** join/#brlcad Stattrav (~Stattrav@122.167.214.98) | |
| 09:05.10 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:56.20 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2924 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */ |
| 10:57.57 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2925 10/wiki/User:Kunigami/GSoc2011/Proposal: /* Timeline */ updated timeline |
| 14:28.53 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 14:37.35 | *** join/#brlcad Stattrav (~Stattrav@117.192.151.196) | |
| 14:37.35 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:50.11 | CIA-62 | BRL-CAD: 03erikgreenwald * r45120 10/brlcad/trunk/include/raytrace.h: Some parsers freak out when they see */*stp*/, thinking it's an end of comment. Adding a space seems to make them happy. |
| 15:11.48 | brlcad | wb |
| 15:12.31 | ``Erik | yargh |
| 15:12.43 | ``Erik | vacations never last long enough. :/ |
| 15:22.20 | CIA-62 | BRL-CAD: 03brlcad * r45121 10/brlcad/trunk/src/ (52 files in 7 dirs): (log message trimmed) |
| 15:22.20 | CIA-62 | BRL-CAD: remove the SCLLOG/SCLBOOL wrappers on the SCL Boolean and Logical enums. they |
| 15:22.20 | CIA-62 | BRL-CAD: were being conditionally put into a namespace in order to be protected in case |
| 15:22.20 | CIA-62 | BRL-CAD: they're used within a 3rd party context (like CORBA) that might also define |
| 15:22.20 | CIA-62 | BRL-CAD: same-named enums, but the macrofied protection just adds complexity. iff a |
| 15:22.21 | CIA-62 | BRL-CAD: conflict is encountered, the types can be put into an SCL or P23 or SDAI |
| 15:22.22 | CIA-62 | BRL-CAD: namespace. 'Boolean' would be prime for outright removal/replacement with |
| 15:22.36 | brlcad | kunigami: make sure all files you add have a proper header and footer, e.g.: sh/header.sh lgpl src/liboptical/osl-renderer.cpp |
| 15:23.30 | brlcad | sh/header.sh, sh/footer.sh, or sh/template.sh (to apply both header and footer) |
| 15:23.58 | brlcad | sh/ws.sh and sh/indent.sh will clean up the formatting so it's consistent with the rest of the source code |
| 15:24.50 | brlcad | just make sure any cleanup commits aren't mixed with actual code/logic changes |
| 15:40.15 | CIA-62 | BRL-CAD: 03kunigami * r45122 10/brlcad/trunk/src/liboptical/osl-renderer.cpp: Cleaning up formatting of osl-renderer.cpp |
| 15:50.21 | CIA-62 | BRL-CAD: 03erikgreenwald * r45123 10/brlcad/trunk/src/other/m4/lib/ohash.h: include sys/types.h for u_int32_t |
| 16:28.43 | CIA-62 | BRL-CAD: 03starseeker * r45124 10/brlcad/trunk/src/other/m4/ (eval.c gnum4.c main.c misc.c): Try the BRL-CAD wrapper for unistd.h here... |
| 16:31.10 | kunigami | when I run indent with osl-renderer.h it changes spacing to 2 while in osl-renderer.cpp it keeps 4. it that the default? |
| 16:34.11 | kunigami | hmm, actually I'd rather ask why footer.sh does not add "c-basic-offset: 4" line? |
| 16:48.32 | CIA-62 | BRL-CAD: 03starseeker * r45125 10/brlcad/trunk/src/other/m4/lib/libyywrap.c: Hmm - MSVC doesn't like __P for some reason. |
| 16:49.32 | CIA-62 | BRL-CAD: 03kunigami * r45126 10/brlcad/trunk/src/liboptical/ (osl-renderer.cpp osl-renderer.h osl_rt.cpp osl_rt2.c): formatting changes for several files |
| 16:50.21 | CIA-62 | BRL-CAD: 03starseeker * r45127 10/brlcad/trunk/src/other/m4/generated/tokenizer.c: one more unistd.h case |
| 16:52.44 | CIA-62 | BRL-CAD: 03kunigami * r45128 10/brlcad/trunk/src/liboptical/osl-renderer.cpp: typo on osl-renderer.cpp local variables |
| 16:53.23 | brlcad | starseeker: egads man |
| 16:53.56 | brlcad | if you had to paste it just twice .. should've been a hint to refactor :) |
| 16:54.21 | brlcad | put that mess into a header and just #include it... |
| 16:57.27 | brlcad | I know you're just trying to "get it to work" .. but egads .. that's passing the buck and really making more work for later |
| 16:59.35 | CIA-62 | BRL-CAD: 03starseeker * r45129 10/brlcad/trunk/src/other/m4/ (eval.c extern.h gnum4.c main.c mdef.h): Remove the doesyscmd option from the m4 logic. May have to revisit this if it turns out later we need it, but this will be problematic on Win32. |
| 17:00.45 | brlcad | also, fwiw, __P is undoubtedly defined like BU_ARGS() used to be .. it makes the parameter list conditional |
| 17:01.17 | brlcad | the __P protection belongs where it's defined, not where it was used in libyywrap.c |
| 17:04.43 | CIA-62 | BRL-CAD: 03starseeker * r45130 10/brlcad/trunk/src/other/m4/ (14 files in 2 dirs): |
| 17:04.43 | CIA-62 | BRL-CAD: Hack, slash and burn approach to MSVC building - this has lots of unresolved |
| 17:04.43 | CIA-62 | BRL-CAD: external symbols and may not function at all anywhere, but it should indicate |
| 17:04.43 | CIA-62 | BRL-CAD: what further changes are needed. Will also need regex linked in, need to take |
| 17:04.43 | CIA-62 | BRL-CAD: care of that. |
| 17:05.02 | brlcad | kunigami: c-file-style: "Stroustrup" sets 4-char indents |
| 17:06.27 | starseeker | brlcad: oh, I know - I've got a lot of refactoring to do - I'm just trying to get a feel for the scope of what's needed |
| 17:06.37 | kunigami | that's strange. even with that line indent.sh used 2 spaces. When I added c-basic-offset:4 it correclty used 4 |
| 17:07.00 | starseeker | brlcad: it wasn't immediately clear how deep into "unixy" coding this m4 was |
| 17:10.02 | CIA-62 | BRL-CAD: 03brlcad * r45131 10/brlcad/trunk/src/liboptical/osl-renderer.h: restructure around a WITH_OSL keyword instead of __cplusplus since it should always be possible to compile the sh_osl C interface. |
| 17:11.07 | brlcad | starseeker: http://gnuwin32.sourceforge.net/packages/m4.htm |
| 17:11.50 | brlcad | enough to warrant someone making a fork instead of trying to make it portable |
| 17:11.57 | brlcad | but then that could have just been laziness or simplicity |
| 17:12.14 | starseeker | nods - yeah, saw that - but this isn't GNU m4 |
| 17:12.25 | starseeker | it's the netbsd port of the openbsd m4 |
| 17:12.41 | starseeker | was going for the smallest m4 that looked like it might have a hope of working with flex |
| 17:12.55 | starseeker | both for build simplicity/porting simplicity and to keep the size of src/other smaller :-P |
| 17:13.25 | starseeker | so far this feels a lot like working with the find code for the search command |
| 17:13.54 | kunigami | brlcad: I didn't understand your changes to osl-renderer.h. It was already possible to compile with sh_osl C interface. |
| 17:14.34 | brlcad | if we really wanted simplicity and a small src/other, we'd just generate the files, add them to svn, and compile those on windows :) |
| 17:14.39 | CIA-62 | BRL-CAD: 03starseeker * r45132 10/brlcad/trunk/src/other/m4/lib/libyywrap.c: Ah, that's why cdefs was included here. Win32 doesn't have cdefs, so be more direct... |
| 17:15.02 | brlcad | way more simple than these 3-4 new dependencies, build system mods, maintenance woes |
| 17:15.20 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 17:15.21 | kunigami | the reason for __cplusplus was that C++ code would see a different interface than C code |
| 17:16.31 | brlcad | kunigami: which C++ code? |
| 17:16.56 | kunigami | brlcad: osl-renderer.cpp which is an interface to osl system |
| 17:17.25 | kunigami | both osl-renderer.cpp and sh_osl.c share the interface osl-renderer.h |
| 17:18.05 | brlcad | iirc, technically doesn' sh_osl.c only "share" the inteface via the C callbacks declared at the bottom of osl-renderer.h? |
| 17:18.26 | *** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net) | |
| 17:18.26 | brlcad | it's "declare class" or "declare typedefs and C funcs" |
| 17:18.31 | yukonbob | hello, #brlcad |
| 17:18.41 | brlcad | rather, it was |
| 17:18.46 | brlcad | hello yukonbob |
| 17:19.26 | brlcad | kunigami: something to consider, sh_osl doesn't have to be C -- it can be a C++ file |
| 17:19.55 | brlcad | so you can call right into osl-renderer.h classes |
| 17:20.17 | brlcad | the only protection really necessary is whether we have OSL or not |
| 17:21.18 | brlcad | that was the motivation, move towards blocking based on the build feature, since the compilation of the interface file is already built-in |
| 17:22.35 | kunigami | I'm not sure if I understood what you meant, but when OSL is not enabled, osl-renderer.h is not even compiled. |
| 17:23.42 | brlcad | right, it's either on and OSL is available or it's off |
| 17:23.51 | brlcad | sh_osl.c doesn't get compiled if it's off, right? |
| 17:23.56 | kunigami | yup |
| 17:24.10 | kunigami | I added a conditional on CMakeLists.txt |
| 17:24.28 | brlcad | so then if it's only on when osl is compiled, and osl is c++, then sh_osl can be c++ |
| 17:24.41 | brlcad | and the c wrapping isn't needed |
| 17:25.07 | brlcad | just adds complexity and code that won't ever get executed/used |
| 17:25.22 | brlcad | make sense? |
| 17:25.32 | kunigami | brlcad: right. I didn't know that sh_osl could be c++. |
| 17:26.01 | brlcad | yep, you could svn mv sh_osl.c sh_osl.cpp if you really wanted |
| 17:26.18 | brlcad | the only important part is that C++ types aren't publicly exposed by liboptical |
| 17:26.56 | brlcad | so if you find yourself needing to add a C++ class / typedef into a header file in the top-level include/ directory, then it might be an issue and require some rethought |
| 17:27.24 | kunigami | but if sh_osl is C++ then I'll have to export functions using "extern C" anyway, because AFAIK C++ exports mangled functions names |
| 17:27.52 | brlcad | sure, if you call C functions |
| 17:28.11 | brlcad | and call them outside that compilation unit |
| 17:28.43 | brlcad | the c functions you had looked like logic that wouldn't need to live in osl-renderer, they'd just be part of the logic in sh_osl.c |
| 17:28.47 | brlcad | er sh_osl.cpp |
| 17:29.24 | brlcad | i.e., you don't need wrappers, you'd just create OSL_Renderer objects and use them |
| 17:29.44 | kunigami | perfect |
| 17:29.50 | kunigami | I'll give it a try |
| 17:30.32 | brlcad | at most, you'd maybe have to stash an OSL_Renderer* object into a struct so you could pass it around as a void* through the various liboptical callback functions |
| 17:30.42 | brlcad | (the 'dpp' parameter) |
| 17:30.56 | brlcad | that's a user data pointer |
| 17:31.22 | brlcad | and that's only because c++ forbids casting objects through void*, have to stash in struct and cast the struct through void* |
| 17:32.00 | brlcad | make sure you quell all warnings ;) |
| 17:32.44 | kunigami | right |
| 17:34.35 | brlcad | starseeker: those big repeated code blocks are more a mentality issue, not letting yourself create extra work in the first place |
| 17:35.14 | *** join/#brlcad crazy_imp (~mj@a89-182-170-199.net-htp.de) | |
| 17:35.56 | brlcad | plus, i've heard you say something to the effect of "I've got a lot of refactoring to do" |
| 17:35.59 | brlcad | with plans to clean some bit of code up "later" on at least three other occasions now :D |
| 17:36.24 | brlcad | and that "later" never manifested itself |
| 17:36.54 | brlcad | code complete, deep not wide |
| 17:45.04 | brlcad | kunigami: not sure about the 2 vs 4 indents -- maybe something in your .emacs file? if I move mine out of the way, I get 4char indents |
| 17:45.10 | CIA-62 | BRL-CAD: 03starseeker * r45133 10/brlcad/trunk/src/other/m4/ (common.h eval.c gnum4.c main.c misc.c pstdint.h): move unistd.h wrapper to common file, add portability guarantee with pstdint.h |
| 17:52.33 | CIA-62 | BRL-CAD: 03starseeker * r45134 10/brlcad/trunk/src/other/m4/ (expr.c look.c trace.c): Replace a few direct calls to stdint.h |
| 17:53.40 | CIA-62 | BRL-CAD: 03brlcad * r45135 10/brlcad/trunk/src/other/m4/lib/libyywrap.c: even simpler, it's a preansiism |
| 17:59.14 | CIA-62 | BRL-CAD: 03starseeker * r45136 10/brlcad/trunk/src/other/m4/ (generated/tokenizer.c parser.y tokenizer.l): Ah, hiding in the tokenizer. Should get us down to the regex header. |
| 18:00.44 | CIA-62 | BRL-CAD: 03starseeker * r45137 10/brlcad/trunk/src/other/m4/lib/ohash_int.h: Nope, one more - ohash |
| 18:05.46 | CIA-62 | BRL-CAD: 03erikgreenwald * r45138 10/brlcad/trunk/src/other/m4/generated/parser.c: remove stdint.h in favor of common.h/pstdint.h |
| 18:06.49 | *** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net) | |
| 18:09.59 | CIA-62 | BRL-CAD: 03starseeker * r45139 10/brlcad/trunk/src/other/m4/ (CMake/ CMake/FindREGEX.cmake CMakeLists.txt): Add logic to locate and link in regex library. |
| 18:14.20 | brlcad | starseeker: so how's the prognosis looking ... have a thought that might make the effort somewhat moot |
| 18:14.32 | starseeker | brlcad: not bad, actually |
| 18:14.36 | starseeker | at least, not so far |
| 18:14.41 | starseeker | what's the though? |
| 18:15.10 | brlcad | ditch lex/yacc for antlr |
| 18:15.10 | CIA-62 | BRL-CAD: 03starseeker * r45140 10/brlcad/trunk/src/other/m4/CMakeLists.txt: Dur - try linking the library, not compiling it. |
| 18:15.26 | brlcad | it's half the code side and supports windows |
| 18:15.42 | starseeker | huh, never heard of it before |
| 18:15.43 | brlcad | but would require rewriting our few existing lex/yacc files in their syntax (which is nearly identical) |
| 18:15.50 | starseeker | reads... |
| 18:17.03 | starseeker | brlcad: it's java based? |
| 18:18.24 | starseeker | or are you looking at the C runtime distributions? |
| 18:19.01 | brlcad | http://www.antlr.org/wiki/display/ANTLR3/Five+minute+introduction+to+ANTLR+3 |
| 18:23.03 | brlcad | another tutorial: http://supportweb.cs.bham.ac.uk/docs/tutorials/docsystem/build/tutorials/antlr/antlr.html |
| 18:23.53 | starseeker | don't we need java to run antlr and generate the code though? |
| 18:26.13 | brlcad | either hook in the java binary (which we could probably bundle precompiled if it's small enough), or compile them via the C runtime (which is about 25k lines of code, about the size of flex) |
| 18:27.03 | brlcad | if I'm understanding their setup correctly, that would even be more ideal than the lex/yacc approach for things like libgcv where we just want the parsing functions, not a main() |
| 18:28.06 | brlcad | of course, the java app may still be required to compile the functions and then the C runtime to use them, not 100% sure on that detail |
| 18:28.13 | starseeker | I'm trying to figure out if the runtime can eat the grammer and execute code, or if you still need the java tools to generate the code |
| 18:28.17 | starseeker | er, yeah :-) |
| 18:29.51 | starseeker | I'm thinking you need java to compile the grammar - I just built libantlr3c and there's no tool I can see to generate C code... |
| 18:30.34 | starseeker | I did a survey a while back looking for lex/yacc alternatives that were in C and I remember coming up rather short... |
| 18:33.12 | starseeker | hmm... |
| 18:33.26 | starseeker | brlcad: maybe http://www.hwaci.com/sw/lemon/ ? |
| 18:35.06 | starseeker | if we're willing to rewrite our definitions, that might be a way to go |
| 18:35.54 | *** join/#brlcad crazy_imp (~mj@a89-182-141-171.net-htp.de) | |
| 18:36.25 | kunigami | I didn't know in C it's allowed to set a function like "void foo(int x)" to a function pointer "void (*fp)()". In C++ it seems it is not allowed. Any suggestions? |
| 18:36.55 | brlcad | starseeker: it'd be worth giving it a try, maybe start with the simple parser in src/mged/points |
| 18:37.42 | brlcad | that's a prime simple test case for conversion, if it works, that'd probably be good enough proof of concept to run forward with it |
| 18:39.09 | brlcad | not nearly as complicated as the others |
| 18:39.23 | starseeker | nods - sounds good |
| 18:39.24 | brlcad | kunigami: I'm working on fixing that right now |
| 18:39.39 | brlcad | kunigami: that's an old carry-over from k&r days of C |
| 18:39.57 | kunigami | brlcad: ok, thanks! |
| 18:42.11 | brlcad | c++ has the same behavior as the concept of "calling a function" in either is as simple as jumping to a pointer address |
| 18:42.39 | brlcad | it just adds type safety during compilation so it can enforce only jumping to a "compatible" address |
| 18:44.07 | yukonbob | starseeker: what are you looking for lex/yacc alternatives for? |
| 18:44.34 | brlcad | C will happily jump to whatever you ask, compiler won't even warn by default unless you ask it to |
| 18:44.47 | kunigami | hmm interesting |
| 18:45.08 | starseeker | yukonbob: we need to be able to handle a (potentially large) number of grammar definitions for geometry format conversion (and other uses, like MGED's point abilities) |
| 18:45.35 | starseeker | we also need to be portable, and (right now) recent flex versions aren't working on Windows |
| 18:45.46 | yukonbob | starseeker: and lex/yacc are unsuitable for some reason? |
| 18:45.48 | starseeker | we also need something that's LGPL-or-freer |
| 18:45.51 | yukonbob | ah |
| 18:46.07 | yukonbob | checks. |
| 18:46.14 | starseeker | The best combination I had come up with so far was the netbsd m4 + byacc + flex |
| 18:46.21 | brlcad | license compatible and portable to windows .. good luck ;) |
| 18:46.21 | starseeker | but that'll have to be ported to Windows |
| 18:46.47 | yukonbob | heh -- that's what I was just looking up. |
| 18:47.04 | yukonbob | NetBSD runs everything, even if it's not. |
| 18:47.13 | yukonbob | ;) |
| 18:47.29 | starseeker | the commits you saw earlier were me and ``Erik getting NetBSD's m4 compiling on MSVC |
| 18:47.59 | starseeker | as long as we don't have to run system commands, it doesn't look too bad - mostly just need to swat all the uses of err, warnx, etc. |
| 18:48.45 | starseeker | flex will be a bit trickier, since it wants to run m4 from within it's own source code (ick) |
| 18:49.09 | yukonbob | starseeker: like exec("m4"...");? |
| 18:49.10 | starseeker | fortunately we just need to run 'em during build, and don't have to install them |
| 18:49.23 | starseeker | pretty much |
| 18:49.27 | yukonbob | sweet. |
| 18:50.38 | starseeker | byacc I'm more hopeful about - the dev was very helpful and added a couple Bison features to get our libobj examples working |
| 18:50.55 | starseeker | but of course that too is untried on Windows |
| 18:51.16 | starseeker | yukonbob: if you know of something less gnarly we'd LOVE to hear about it :-P |
| 18:51.16 | yukonbob | starseeker: I haven't worked w/ flex/yacc in ages, but aren't their artifacts just .c and .h? Considered just generating those on a *nix and shipping those artifacts as part of the repo? |
| 18:51.47 | starseeker | yukonbob: the problem with that is the grammar definitions are what you edit during the development process |
| 18:52.17 | starseeker | we want potential developers to edit the source, type "make" (or do the MSVC thing on Windows) and have it Just Work |
| 18:52.50 | yukonbob | ya -- my suggestion is certainly non-elegant in that regard. |
| 18:52.51 | starseeker | the temptation when you have generated source files is to tweak those files and not the original grammar definitions, which very quickly divorces the code (and fixes) from what should be the canonical source code |
| 18:53.28 | yukonbob | inlucde a comment "Edit this code under threat of death as punishment"... |
| 18:53.34 | starseeker | a geometry conversion library may potentially grow to have dozens of grammars that need to be handled, and that will be quite a job even if we AREN'T having to worry about syncing back and forth |
| 18:53.46 | starseeker | heh |
| 18:54.10 | starseeker | that's a great way to encourage contributions :-P |
| 18:54.35 | yukonbob | starseeker: anybody who's able to contribute to a lexer/parser will know what it means. |
| 18:55.12 | yukonbob | but meh... best case is a truly portable lex/yacc |
| 18:55.25 | starseeker | yukonbob: if we're building just the sources though, new devs may head straight for the sources to fix a problem |
| 18:55.37 | starseeker | would probably do that, without knowing better |
| 18:55.56 | starseeker | and would probably run screaming :-P |
| 18:57.45 | yukonbob | starseeker: is your list of candidates posted anywhere?| |
| 18:57.49 | starseeker | because the lex/yacc or whatever files are the "user editable" form of the logic, we also want to make sure they continue to work and don't "bit rot" - if the C files work, but no one has done the generation in a few years, who knows what may have gone wrong next time we NEED to do the generation? |
| 18:57.59 | starseeker | yukonbob: uh - src/other? :-P |
| 18:58.12 | starseeker | will make a wiki page quick... |
| 19:05.59 | yukonbob | starseeker: re: bit rot -- build is automated for producing various binaries, no? |
| 19:07.22 | starseeker | er, huh? |
| 19:07.56 | yukonbob | on major releases, you have a system that generates binaries, no? |
| 19:08.15 | starseeker | Oh, you mean binary releases? yeah |
| 19:09.21 | yukonbob | so for case of ppl tweaking lex/yacc artifacts and not being able to actually produce them canonically, that'd be tested periodically w/ testing for formal releases... |
| 19:09.58 | yukonbob | should stop worrying about project-wide builds and see if his NetBSD build still stands up to latests sources... |
| 19:10.01 | starseeker | yukonbob: but if it's not integrated into our build, it becomes an extra overhead/step that consumes developer time (a lot of it, over the long pull) |
| 19:18.34 | yukonbob | ! -- this has bumped 2 minor versions since I last checked... |
| 19:21.07 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2926 10/wiki/Lexer_Parser: Stub in a page for discussing lexers/parsers |
| 19:21.48 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2927 10/wiki/Lexer_Parser: |
| 19:26.08 | starseeker | hmm - re2c actually might be interesting |
| 19:28.20 | starseeker | http://lekernel.net/blog/2009/02/re2c-and-lemon-an-elegant-alternative-to-flex-and-bison/ |
| 19:31.20 | starseeker | O.o apparently someone is building re2c on MSVC? |
| 19:31.52 | yukonbob | familiar w/ lemon, but not re2c |
| 19:32.11 | starseeker | yukonbob: what do you think of lemon? |
| 19:35.16 | yukonbob | likes things that come from drh |
| 19:35.24 | starseeker | yukonbob: know anything about styx? http://speculate.de/ |
| 19:35.58 | yukonbob | like I said, I haven't played in that domain for a while, but conceptually, lemon is nice, and is thoroughly tested via sqlite |
| 19:36.20 | starseeker | huh - styx has Express (from STEP) as an example grammar |
| 19:36.26 | yukonbob | likes this "non statement" in the re2c: |
| 19:36.33 | yukonbob | "...equal to hand-written code in terms of size, speed and quality." |
| 19:36.43 | yukonbob | *re2c site.. |
| 19:37.25 | yukonbob | my understanding w/ parser code is that rolling your own is often error-prone, difficult, often inefficient, etc., etc. |
| 19:38.09 | starseeker | heh - if I read that right, it dates back to when people were hand-tuning code due to machine speed constraints |
| 19:38.35 | yukonbob | ya -- /me just getting into site, so may be pulling out of context, but still made me chuckle. |
| 19:39.24 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2928 10/wiki/Lexer_Parser: Add a few more notes |
| 19:39.37 | yukonbob | heh -- oh, and holding up PHP as a flagship project... |
| 19:42.50 | starseeker | still - if it doesn't need m4 and already builds on Windows... |
| 19:46.07 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 19:46.44 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2929 10/wiki/Lexer_Parser: not links |
| 19:53.59 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2930 10/wiki/Lexer_Parser: Few more comments on re2c, link to example using lemon |
| 20:30.13 | CIA-62 | BRL-CAD: 03erikgreenwald * r45141 10/brlcad/trunk/src/other/m4/ (14 files in 3 dirs): rename common.h to commonm4.h, as our regex.h requires include/common.h |
| 20:30.30 | starseeker | nods - good catch |
| 20:38.08 | CIA-62 | BRL-CAD: 03erikgreenwald * r45142 10/brlcad/trunk/src/other/m4/ (gnum4.c main.c misc.c): errx->m4errx |
| 20:40.06 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r2931 10/wiki/Lexer_Parser: Add notes on Antlr |
| 20:48.17 | CIA-62 | BRL-CAD: 03erikgreenwald * r45143 10/brlcad/trunk/src/other/m4/misc.c: add some windows portability functions. Includes getopt from libbu, LGPL pollution. |
| 20:51.09 | CIA-62 | BRL-CAD: 03starseeker * r45144 10/brlcad/trunk/src/other/byacc/main.c: Looks like this is the only use byacc makes of unistd, so just wrap it here. |
| 20:51.32 | kunigami | When I finish porting sh_osl.c to sh_osl.cpp, OSLRenderer object will need to be declared at a global scope. In which place do you think it's better to keep it? I though of putting it on "struct application", but this struct is not passed as parameter to osl_setup. |
| 20:59.49 | kunigami | hmm the problem of letting OSLRenderer global is that we will need a opaque pointer because it will be visible for C code. |
| 21:01.22 | kunigami | Is it possible to declare it in such a way that it is visible to all sh_osl instances as a global object, while not exposing it to C code? |
| 21:02.54 | brlcad | you mean like static? :) |
| 21:06.52 | kunigami | probably is that what I want |
| 21:08.31 | brlcad | definitely don't want something globally visible |
| 21:09.09 | brlcad | a static global will limit scope to that file, a static variable inside a callback will limit scope even further to callers of an accessor function |
| 21:09.32 | CIA-62 | BRL-CAD: 03starseeker * r45145 10/brlcad/trunk/src/other/flex/ (CMake/ CMake/FindREGEX.cmake CMakeLists.txt): flex will need the regex lib too (and a good deal more, but start with this.) |
| 21:09.49 | brlcad | what else does flex need? |
| 21:10.03 | starseeker | er, sorry - phrased that wrong |
| 21:10.16 | starseeker | needs tests (limit.h, sys/wait.h, etc.) |
| 21:10.24 | brlcad | ah |
| 21:16.48 | kunigami | I was thinking about a possible problem: I only managed to make OSLRenderer work when I grouped all osl shaders in a single class (I've tried using a OSLRenderer for each osl shader, but it didn't work). It's probably the case that some information must be stored in a global context and shared among the shaders. If this is true, it won't be possible to mix brl-cad and osl shaders :( I've to investigate it further... |
| 21:26.51 | CIA-62 | BRL-CAD: 03starseeker * r45146 10/brlcad/trunk/src/other/flex/CMakeLists.txt: No doubt a fair number of these tests need to be more sophisticated, but this gives us a first cut at supporting most of conf.in's variables. |
| 21:57.29 | CIA-62 | BRL-CAD: 03starseeker * r45147 10/brlcad/trunk/src/other/flex/CMakeLists.txt: Whoops - add in the REGEX include dir too. |
| 21:58.57 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 22:01.02 | CIA-62 | BRL-CAD: 03brlcad * r45148 10/brlcad/trunk/include/optical.h: document optical_shader_init() |
| 22:04.54 | CIA-62 | BRL-CAD: 03starseeker * r45149 10/brlcad/trunk/src/other/flex/scan.c: wrap unistd.h in scan.c - will need to fix the generation in some fashion for this, probably add the wrapper to the skeleton... |
| 22:07.35 | CIA-62 | BRL-CAD: 03starseeker * r45150 10/brlcad/trunk/src/other/flex/scan.c: Hmm... need something a bit different here, apparently... - try going minimal... |
| 22:07.37 | *** join/#brlcad dtidrow (~dtidrow@c-68-60-53-123.hsd1.mi.comcast.net) | |
| 22:10.12 | CIA-62 | BRL-CAD: 03starseeker * r45151 10/brlcad/trunk/src/other/flex/parse.c: Hmm. Possibly a stray semicolon, could also be an error in the if/else logic... |
| 23:06.52 | brlcad | kunigami: if it's hooked through our shader system, there really is no limitation on mixing shader types because the mixing is per-pixel and happening on our end |
| 23:07.19 | brlcad | you might not be able to get neat blending effects, like a caustic on a non-osl shader, but that's okay |
| 23:07.58 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 23:08.39 | brlcad | it's really a question of whether osl can shade a single pixel without shooting the ray itself -- if it can, then it should be entirely possible |
| 23:09.06 | brlcad | finally finishes an exhaustive day refactoring liboptical .. now to make sure it still works! |
| 23:09.15 | *** part/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) | |
| 23:35.52 | CIA-62 | BRL-CAD: 03bhinesley * r45152 10/brlcad/trunk/src/libged/translate.c: adding 'f_tr_obj' functionality to 'translate' |
| 00:31.27 | brlcad | bhinesley: rough going? :) |
| 00:37.13 | bhinesley | brlcad: yeah... |
| 00:37.30 | bhinesley | reading through code and trying to figure things out |
| 02:39.23 | brlcad | bhinesley: have you read through the oed tutorial? if not, I would recommend it as it explains a lot of 'why' oed behaves the way it does, which mostly relates to implementation detail |
| 02:40.05 | brlcad | like how a keypoint is specified (it's the right-hand side, first natural coordinate) |
| 03:21.34 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) | |
| 03:36.43 | CIA-62 | BRL-CAD: 03brlcad * r45153 10/brlcad/trunk/bench/run.sh: |
| 03:36.43 | CIA-62 | BRL-CAD: fix off-by-one bug where TIMEFRAME=0 was causing all testing to get skipped. it |
| 03:36.43 | CIA-62 | BRL-CAD: should at least run all tests once. also fixed a bug where it was reporting |
| 03:36.43 | CIA-62 | BRL-CAD: success if previous pix files were still in the run directory, even if rt |
| 03:36.43 | CIA-62 | BRL-CAD: failed. now handles negative time values too (by clamping to min). |
| 03:45.01 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) | |
| 03:53.01 | CIA-62 | BRL-CAD: 03brlcad * r45154 10/brlcad/trunk/ (38 files in 3 dirs): (log message trimmed) |
| 03:53.01 | CIA-62 | BRL-CAD: major refactoring of the liboptical callback api to expand the function |
| 03:53.01 | CIA-62 | BRL-CAD: callbacks with their respective parameters. in doing so, the headp mfuncs list |
| 03:53.01 | CIA-62 | BRL-CAD: parameter was removed (only used by stack and text shaders) in favor of just |
| 03:53.01 | CIA-62 | BRL-CAD: generating a new headp via optical_shader_init(). also ended up propagating a |
| 03:53.02 | CIA-62 | BRL-CAD: slew of genptr_t's instead of char* and some basic constness. the stronger ansi |
| 03:53.03 | CIA-62 | BRL-CAD: type checking revealed several inconsistencies that got caught up in the cleanup |
| 04:12.56 | CIA-62 | BRL-CAD: 03brlcad * r45155 10/brlcad/trunk/src/ (16 files in 8 dirs): remove the antiquated msvc build files from long ago. no longer relevant with the new cmake build. |
| 04:22.44 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1128565141.dsl.bell.ca) | |
| 04:30.32 | CIA-62 | BRL-CAD: 03brlcad * r45156 10/brlcad/trunk/src/liboptical/ (material.c sh_stack.c shade.c): add some sanity checks. make sure the callbacks aren't null before we call them. make sure other related struct dereferences aren't null as well otherwise do something else to avoid crashing. |
| 04:30.54 | *** part/#brlcad IriX64 (~kvirc@bas2-sudbury98-1128565141.dsl.bell.ca) | |
| 04:36.26 | CIA-62 | BRL-CAD: 03brlcad * r45157 10/brlcad/trunk/src/liboptical/sh_wood.c: remove the unnecessary wood_init() routine and respective eRT dead code sections. can init to null on decl and avoid the book-keeping and function call altogether. |
| 04:41.13 | bhinesley | brlcad: yes, I've read the oed tutorial. |
| 04:43.11 | bhinesley | I haven't really done anything that involves directly manipulating graphics objects, until now. It's taking a lot to understand how that works. |
| 04:44.39 | bhinesley | (for me) :) |
| 04:45.47 | CIA-62 | BRL-CAD: 03brlcad * r45158 10/brlcad/trunk/src/burst/Hm.h: comment cleanup and s/<control>/CONTROL/ |
| 04:48.09 | CIA-62 | BRL-CAD: 03bhinesley * r45159 10/brlcad/trunk/src/libged/translate.c: use struct db_full_path, not char[] |
| 04:55.09 | CIA-62 | BRL-CAD: 03brlcad * r45160 10/brlcad/trunk/src/conv/ (g-xxx.c walk_example.c): don't declare UNUSED params to doxygen, just bitches about them. if you list some params, though, you should list all of them (except UNUSED ones). |
| 04:56.07 | CIA-62 | BRL-CAD: 03brlcad * r45161 10/brlcad/trunk/src/libbn/axis.c: add param docs missing from a couple funcs |
| 04:59.08 | CIA-62 | BRL-CAD: 03bhinesley * r45162 10/brlcad/trunk/src/libged/translate.c: fix whitespace (ws.sh) |
| 05:52.11 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 06:43.22 | *** join/#brlcad Stattrav (~Stattrav@122.167.214.98) | |
| 06:43.22 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:20.02 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 07:32.29 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 07:32.29 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:23.39 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 08:57.51 | *** join/#brlcad Stattrav (~Stattrav@122.167.214.98) | |
| 08:57.51 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:17.30 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 09:17.30 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:03.41 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 10:32.18 | CIA-62 | BRL-CAD: 03brlcad * r45163 10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: wrap diagrams in @code/@endcode |
| 10:38.43 | CIA-62 | BRL-CAD: 03brlcad * r45164 10/brlcad/trunk/src/rt/do.c: remove appearance of tags for parsing |
| 10:41.58 | CIA-62 | BRL-CAD: 03brlcad * r45165 10/brlcad/trunk/src/shapes/fence.h: doxygenify comments |
| 10:45.37 | CIA-62 | BRL-CAD: 03brlcad * r45166 10/brlcad/trunk/src/util/pixfade.c: remove tag appearance |
| 10:45.54 | CIA-62 | BRL-CAD: 03brlcad * r45167 10/brlcad/trunk/src/vdeck/vdeck.c: wrap table in @code/@endcode |
| 10:59.02 | CIA-62 | BRL-CAD: 03kunigami * r45168 10/brlcad/trunk/src/liboptical/ (6 files): moving sh_osl.c to sh_osl.cpp |
| 11:00.16 | CIA-62 | BRL-CAD: 03brlcad * r45169 10/brlcad/trunk/include/bu.h: match @param variable names with the function so it knows which is which. clean up formatting on the @code/@endcode sections |
| 11:00.38 | CIA-62 | BRL-CAD: 03brlcad * r45170 10/brlcad/trunk/include/wdb.h: if you're going to annotate one of the parameters, they all have to be annotated. |
| 11:01.05 | CIA-62 | BRL-CAD: 03brlcad * r45171 10/brlcad/trunk/src/librt/vlist.c: document the other param |
| 11:03.04 | CIA-62 | BRL-CAD: 03brlcad * r45172 10/brlcad/trunk/src/libwdb/reg.c: if you document one of them, document all of them |
| 11:07.46 | CIA-62 | BRL-CAD: 03brlcad * r45173 10/brlcad/trunk/src/proc-db/surfaceintersect.cpp: function sig consistency |
| 11:14.21 | CIA-62 | BRL-CAD: 03brlcad * r45174 10/brlcad/trunk/include/rtgeom.h: comment cleanup. put latex equation into a code block. |
| 12:25.22 | CIA-62 | BRL-CAD: 03kunigami * r45175 10/brlcad/trunk/src/liboptical/ (CMakeLists.txt init.c osl_rt.cpp): implemented a simple mirror shader on osl_rt to make sure we can combine osl shaders with other shaders. it worked\! |
| 12:26.59 | kunigami | brlcad: any news on the "struct mfuncs" support to C++? |
| 12:30.42 | CIA-62 | BRL-CAD: 03starseeker * r45176 10/brlcad/trunk/src/other/CMakeLists.txt: Reorder things a bit. |
| 12:31.09 | CIA-62 | BRL-CAD: 03starseeker * r45177 10/brlcad/trunk/src/ (8 files in 8 dirs): dsp files are no more, so we don't need to ignore them. |
| 14:41.43 | *** join/#brlcad crazy_imp (~mj@a89-182-132-98.net-htp.de) | |
| 14:42.18 | brlcad | kunigami: I just checked in all of the changes this morning |
| 14:42.52 | brlcad | er, last night even .. r45154 |
| 14:43.50 | brlcad | so now they're properly expanded global function callbacks |
| 14:44.54 | brlcad | you'll still want extern "C" linkage, but should be able to hook in your callbacks from the C++ side warning-free |
| 15:01.30 | *** join/#brlcad _psilva (~silvap@static-96-255-52-7.washdc.fios.verizon.net) | |
| 15:46.34 | brlcad | kunigami: you may have noticed, but larry just added a slew of comments to the testshader example, explaining everything in more detail |
| 15:46.38 | brlcad | https://github.com/lgritz/OpenShadingLanguage/blob/e7673afe1c1c9467eba48e7a836904999f80a1cf/src/testshade/testshade.cpp |
| 15:46.46 | kunigami | besides declaring each _setup, _render, _print and _free surrounded with extern "C", should I take any other care? The compiling goes fine, but when I try to run ./rt, it gives me undefined symbol for osl_setup |
| 15:47.24 | brlcad | you declare the bu_structparse table, then add that table to init.c |
| 15:47.43 | brlcad | I think I saw a recent previous commit where you removed it from init |
| 15:48.08 | kunigami | I added it back already |
| 15:48.54 | brlcad | there's nothing more to it other than those two steps that come to mind |
| 15:48.58 | brlcad | what's the actual error? |
| 15:49.20 | kunigami | ./rt: symbol lookup error: /home/kunigami/workspace/dev/bin/brlcad-bin/lib/liboptical.so.19: undefined symbol: osl_setup |
| 15:49.41 | kunigami | I'll try a clean compiling here (I've been updating only from src/liboptical) |
| 15:50.16 | brlcad | the function is implemented in an extern "C" block too? |
| 15:50.40 | kunigami | no, but it's hidden from the C code |
| 15:52.42 | kunigami | about the testrender update: great! I'll read it later! Maybe it helps me improving the current system I've been using almost like copy & paste |
| 15:52.53 | brlcad | what do you mean hidden? |
| 15:53.02 | brlcad | the callback functions aren't "hidden" |
| 15:53.32 | brlcad | they can be HIDDEN (i.e., static), but have to be globally addressable otherwise you'll get ... a runtime error ;) |
| 15:53.59 | brlcad | I'm betting it's extern "C" linkage |
| 15:54.05 | brlcad | add that to the function decl |
| 15:54.17 | brlcad | extern "C" int osl_setup(...) { ... |
| 16:00.10 | kunigami | hmm ok! I don't know why I though that each shader was compiled as a separated unit and then dynamically linked to liboptical :P Fixing that |
| 16:10.16 | kunigami | worked. thanks! |
| 16:10.17 | brlcad | there is code in there that will dynamically load new shaders |
| 16:10.38 | brlcad | but they'd still need to be extern "C" so the symbol names are mangled |
| 16:16.54 | CIA-62 | BRL-CAD: 03178.73.220.94 07http://brlcad.org * r2932 10/wiki/MGED_CMD_saveview: |
| 16:19.02 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2933 10/wiki/MGED_CMD_saveview: Reverted edits by [[Special:Contributions/178.73.220.94|178.73.220.94]] ([[User talk:178.73.220.94|Talk]]); changed back to last version by [[User:Sean|Sean]] |
| 16:19.14 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:178.73.220.94]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 16:39.25 | CIA-62 | BRL-CAD: 03brlcad * r45178 10/brlcad/trunk/TODO: notes on benchmark suite |
| 16:39.49 | CIA-62 | BRL-CAD: 03brlcad * r45179 10/brlcad/trunk/TODO: erase/erase_all merged |
| 16:44.12 | CIA-62 | BRL-CAD: 03brlcad * r45180 10/brlcad/trunk/TODO: the rename will ideally have to wait until the next minor update now |
| 16:50.53 | *** join/#brlcad Stattrav (~Stattrav@117.202.27.251) | |
| 16:50.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:17.25 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 17:17.33 | *** join/#brlcad Stattrav (~Stattrav@117.202.27.251) | |
| 17:17.33 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:19.51 | *** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net) | |
| 17:31.20 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:41.09 | kunigami | hmm I think I'm doing something wrong :P the sphere was supposed to be the osl shader http://imageshack.us/photo/my-images/16/weirdje.png/ |
| 17:47.13 | kunigami | I'll try adding supersampling |
| 18:04.50 | CIA-62 | BRL-CAD: 03kunigami * r45181 10/brlcad/trunk/src/liboptical/ (CMakeLists.txt init.c osl-renderer.cpp sh_osl.cpp): finished porting sh_osl.c to sh_osl.cpp and added some code to integrate osl (but is not working properly) |
| 18:49.49 | brlcad | kunigami: your #ifdef __cplusplus sections in sh_osl.cpp ... |
| 18:49.57 | brlcad | when will they ever be false? :) |
| 18:52.12 | kunigami | hmm probably not :) |
| 18:53.49 | CIA-62 | BRL-CAD: 03kunigami * r45182 10/brlcad/trunk/src/liboptical/sh_osl.cpp: removed useless cplusplus macros |
| 18:53.53 | brlcad | the only conditional you might consider would be a toggle on whether OSL is available or not, OSL_ENABLED or WITH_OSL or somesuch |
| 18:54.10 | brlcad | but that'd only be so you could print "oops, osl not available" |
| 18:55.32 | brlcad | so educate me a little bit -- how does osl shade a pixel given a hit point and normal? |
| 18:55.44 | brlcad | what do you provide to osl? |
| 18:59.42 | kunigami | From the testrender example, I think for each pixel we need to provide osl with object normal, incident ray and hit point -- for the most basic case |
| 19:02.45 | brlcad | so then how does it shade given that info? |
| 19:03.46 | kunigami | actually we also need to provide a shaderstate, which seems to contain information about which osl shader is being used |
| 19:04.01 | brlcad | how might I take light source visibility into an account, for example, if I'm trying to write an osl shader |
| 19:05.01 | kunigami | I think that it's done through recursion. When a ray hit a non-emitter surface, it is propagated |
| 19:05.28 | kunigami | when it finally hits a emitter, it just return its color |
| 19:05.33 | brlcad | how does that happen? osl didn't shoot the primary ray |
| 19:06.59 | kunigami | it calculates the output direction from the incident ray and the normal, I think |
| 19:07.33 | brlcad | that would imply to me that there has to be some way either to register with osl how rays are fired (e.g. register a callbackup that ends up calling rt_shootray()), or call into osl for info to know when a new ray needs to be fired to compute some shader info |
| 19:07.57 | brlcad | sure, it'll know the direction, but it doesn't exactly have any logic to shoot a ray |
| 19:09.00 | brlcad | otherwise, osl would also require the geometry in some format and it wouldn't be a shading library, it'd be a raytracer :) |
| 19:09.15 | kunigami | In testrender this logic was implemented along the radiance function. In sh_osl I'm explict calling rt_shootray |
| 19:10.29 | CIA-62 | BRL-CAD: 03brlcad * r45183 10/brlcad/trunk/src/libged/translate.c: c99-style // comments can't be used in C files, must be c89 compliant |
| 19:11.28 | brlcad | i'm not familiar with testrender .. is the radiance function something written in C/C++ and provided to OSL? |
| 19:12.28 | kunigami | no, radiance was a function written by the author of testrender. It's a simple intersection system to find which of the spheres of the scene was hit by the given ray |
| 19:13.37 | brlcad | so in your weirdje image, which shader is on that sphere? |
| 19:14.25 | brlcad | the reason I'm asking, trying to understand how we'll put this integration to use down the road |
| 19:14.44 | kunigami | that's an osl shader, which should be a perfect diffuse yellow |
| 19:15.06 | brlcad | I know from a high-high level what OSL is capable of, it's how it gets integrated that seems still to be a mystery |
| 19:16.04 | brlcad | so perfect diffuse, it should be a shader that just needs the ray, object hit point, and surface normal |
| 19:16.14 | kunigami | yes |
| 19:16.19 | brlcad | so it shades based on the cosine angle, basically light coming from the camera |
| 19:16.42 | brlcad | so why is the bottom of the sphere bright and the top dark then? :) |
| 19:17.40 | brlcad | that also implies an another open question: how might one implement a phong shader with OSL |
| 19:18.15 | kunigami | It seems it's acting like a mirror (the top of the scene is dark and the floor is bright) |
| 19:18.43 | brlcad | hm, true |
| 19:19.33 | brlcad | ah, your firing a ray for each hit point, aren't you -- a ray down the normal or something |
| 19:19.53 | brlcad | the color it gets will be a mirror-like color |
| 19:21.29 | kunigami | yes, but it's exactly the same thing I do on osl_rt and there the color is as expected |
| 19:21.55 | brlcad | apparently not "exactly" the same :) |
| 19:25.05 | kunigami | the difference is that in osl_rt all shaders (except the mirror) are osl ones. Probably some information is being stored in the system when a ray jumps from an object to another. |
| 19:25.15 | brlcad | once you get diffuse working, I'd suggest trying to get a simplistic phong shader implemented, since that really begs questions on how the OSL API is supposed to handle secondary queries |
| 19:28.58 | brlcad | you could use the cornell box example and make all objects have an osl shader |
| 19:29.06 | brlcad | no sense making it more complicated than it needs to be |
| 19:44.37 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 19:50.52 | CIA-62 | BRL-CAD: 03r_weiss * r45184 10/brlcad/trunk/src/libbu/list.c: Fixed a bug in function 'bu_list_reverse' within file 'list.c' of the 'libbu' library. A 'struct bu_list' was not initialized correctly causing a segmentation fault. |
| 19:58.07 | CIA-62 | BRL-CAD: 03r_weiss * r45185 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: |
| 19:58.07 | CIA-62 | BRL-CAD: Updated function 'nmg_booltree_evaluate' within file 'nmg_bool.c'. Removed the |
| 19:58.07 | CIA-62 | BRL-CAD: call to 'nmg_model_fuse' since it is not necessary here. This is called later |
| 19:58.08 | CIA-62 | BRL-CAD: within function 'nmg_bool'. This change will increase the speed in which nmg |
| 19:58.08 | CIA-62 | BRL-CAD: boolean operations are performed. For example, the mged command 'facetize' will |
| 19:58.08 | CIA-62 | BRL-CAD: run faster. |
| 20:13.48 | CIA-62 | BRL-CAD: 03r_weiss * r45186 10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c: |
| 20:13.48 | CIA-62 | BRL-CAD: Updated functions 'nmg_class_pt_s', 'class_eu_vs_s' and 'class_fu_vs_s' within |
| 20:13.48 | CIA-62 | BRL-CAD: file 'nmg_class.c'. The changes will increase the speed in which nmg boolean |
| 20:13.48 | CIA-62 | BRL-CAD: operations are performed. For example, the mged command 'facetize' will run |
| 20:13.48 | CIA-62 | BRL-CAD: faster. The change adds a compare to the shell bounding box to exclude nmg |
| 20:13.49 | CIA-62 | BRL-CAD: objects (shell,face,loop,edge,vertex) as early as possible in the classification |
| 20:13.50 | CIA-62 | BRL-CAD: to prevent extra processing. |
| 20:17.12 | CIA-62 | BRL-CAD: 03brlcad * r45187 10/brlcad/trunk/db/ (CMakeLists.txt Makefile.am cornell.rt): add a view script for the cornell box that can be used to restore a prototypical view inside the box. |
| 20:18.29 | brlcad | kunigami: that view script may be of interest -- if you run it (sh cornell.rt), it should render a typical view of the existing cornell.g model |
| 20:18.47 | CIA-62 | BRL-CAD: 03r_weiss * r45188 10/brlcad/trunk/include/vmath.h: |
| 20:18.47 | CIA-62 | BRL-CAD: Added macro 'V3PT_OUT_RPP_TOL' to file 'vmath.h' which tests if a vertex is |
| 20:18.47 | CIA-62 | BRL-CAD: outside a bounding box by at least the distance tolerance. This macro supports |
| 20:18.47 | CIA-62 | BRL-CAD: changes to functions 'nmg_class_pt_s' and 'class_eu_vs_s' within file |
| 20:18.47 | CIA-62 | BRL-CAD: 'nmg_class.c'. |
| 20:18.48 | brlcad | may be useful for tweaking the cornell.g model to be all osl shaders |
| 20:18.55 | brlcad | for testing |
| 20:25.17 | CIA-62 | BRL-CAD: 03r_weiss * r45189 10/brlcad/trunk/src/librt/primitives/nmg/nmg_pt_fu.c: |
| 20:25.17 | CIA-62 | BRL-CAD: Updated function 'nmg_class_pt_lu_except' within file 'nmg_pt_fu.c'. Improved |
| 20:25.17 | CIA-62 | BRL-CAD: the test against the loop bounding box by added the distance tolerance and |
| 20:25.17 | CIA-62 | BRL-CAD: changed the macro so that the point must be at least the distance tolerance |
| 20:25.17 | CIA-62 | BRL-CAD: outside the loop bounding box to be excluded. |
| 20:31.03 | CIA-62 | BRL-CAD: 03brlcad * r45190 10/brlcad/trunk/include/bu.h: don't let BU_LIST_INIT_ZERO set the magic number to BU_LIST_HEAD_MAGIC since the pointers are still NULL. the macro is only useful as a zero-initializer. |
| 20:31.37 | kunigami | brlcad: thanks! I was trying to setup that scene here without much sucess |
| 20:33.23 | CIA-62 | BRL-CAD: 03brlcad * r45191 10/brlcad/trunk/NEWS: |
| 20:33.24 | CIA-62 | BRL-CAD: through a variety of enhancements, richard has been making headway on improving |
| 20:33.24 | CIA-62 | BRL-CAD: the performance and reliability of the nmg/bot processing code. in particular, |
| 20:33.24 | CIA-62 | BRL-CAD: he has eliminated duplicative model fusing and improve topology connectivity |
| 20:33.24 | CIA-62 | BRL-CAD: evaluations so objects that previously wouldn't convert can. |
| 20:33.53 | brlcad | kunigami: it's a little screwy because that model uses the original cornell specification |
| 20:34.06 | brlcad | with exact positioning and orientation, which doesn't match our coordinate system |
| 20:34.39 | brlcad | plus you want perspective for that model since you're in such a small confined space, which isn't the default |
| 20:36.15 | brlcad | someone needs to remodel the box to fix our render expectations a little bit better, and if only to toss in a sphere :) |
| 20:39.50 | ``Erik | ferrofluid http://www.youtube.com/watch?v=OsW8zctD7CM |
| 20:44.21 | CIA-62 | BRL-CAD: 03r_weiss * r45192 10/brlcad/trunk/src/librt/primitives/ars/ars.c: |
| 20:44.21 | CIA-62 | BRL-CAD: Updated the 'rt_ars_tess' function within file 'ars.c'. This change simplifies |
| 20:44.21 | CIA-62 | BRL-CAD: the 'ars' primitive geometry to improve the success of performing nmg boolean |
| 20:44.21 | CIA-62 | BRL-CAD: operations with 'ars' primitives. Commands such as mged 'facetize' will have |
| 20:44.22 | CIA-62 | BRL-CAD: greater success when the geometry to facetize contains 'ars' primitives. |
| 21:05.33 | CIA-62 | BRL-CAD: 03128.63.32.62 07http://brlcad.org * r2934 10/wiki/Lexer_Parser: /* Parsers */ - add note pointing to lemon example |
| 21:40.57 | CIA-62 | BRL-CAD: 03r_weiss * r45193 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message trimmed) |
| 21:40.57 | CIA-62 | BRL-CAD: Fixed a bug in function 'nmg_triangulate_rm_degen_loopuse' which caused an |
| 21:40.57 | CIA-62 | BRL-CAD: infinite loop when a loopuse contains a single vertexuse instead of a list of |
| 21:40.57 | CIA-62 | BRL-CAD: edgeuse. The function now also kills all loopuse which contain only a single |
| 21:40.57 | CIA-62 | BRL-CAD: vertexuse. The associated single vertexuse is also killed. This function |
| 21:40.57 | CIA-62 | BRL-CAD: supports the new prototype function 'nmg_triangulate_fu' (nmg triangulate |
| 21:40.58 | CIA-62 | BRL-CAD: faceuse). Preprocessor commands are added so these updates/additions are |
| 21:57.34 | *** join/#brlcad crazy_imp (~mj@a89-182-130-99.net-htp.de) | |
| 22:00.00 | *** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ) | |
| 22:00.01 | *** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ) | |
| 22:00.35 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 00:08.26 | *** join/#brlcad crazy_imp (~mj@a89-182-222-99.net-htp.de) | |
| 00:33.06 | CIA-62 | BRL-CAD: 03brlcad * r45194 10/brlcad/trunk/NEWS: |
| 00:33.06 | CIA-62 | BRL-CAD: in addition to the general enhancements to nmg processing, there was a specific |
| 00:33.06 | CIA-62 | BRL-CAD: simplification/improvement to ARS->NMG conversion so that facetize and exports |
| 00:33.06 | CIA-62 | BRL-CAD: will have greater success. merges coplaner faces and simplifies the shells. |
| 00:42.46 | *** join/#brlcad crazy_imp (~mj@a89-182-162-253.net-htp.de) | |
| 03:17.00 | CIA-62 | BRL-CAD: 03brlcad * r45195 10/brlcad/trunk/include/brep.h: file name is brep.h, not on_nurb.h |
| 03:25.42 | CIA-62 | BRL-CAD: 03brlcad * r45196 10/brlcad/trunk/src/conv/ (26 files): denote as being conv files in order to avoid conflicting with same-named files in other dirs |
| 06:19.26 | *** join/#brlcad Stattrav (~Stattrav@122.167.214.98) | |
| 06:19.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:01.27 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 09:11.31 | *** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz) | |
| 09:11.45 | pawleeq | hello |
| 12:14.28 | CIA-62 | BRL-CAD: 03erikgreenwald * r45197 10/brlcad/trunk/src/other/m4/ (gnum4.c lib/setprogname.c misc.c): hacks to get something compiling on winderz (not tested). |
| 12:23.34 | brlcad | kunigami: is include/osl-renderer.h being used? |
| 13:05.00 | CIA-62 | BRL-CAD: 03brlcad * r45198 10/brlcad/trunk/src/librt/primitives/ (113 files in 36 dirs): include paths to remove ambiguity with same-named files in other directories |
| 13:17.16 | CIA-62 | BRL-CAD: 03brlcad * r45199 10/brlcad/trunk/src/ (132 files in 10 dirs): make the @file name match the file name, disambiguate util files |
| 14:01.17 | CIA-62 | BRL-CAD: 03brlcad * r45200 10/brlcad/trunk/src/libpc/pcParameter.h: ws |
| 14:02.21 | CIA-62 | BRL-CAD: 03brlcad * r45201 10/brlcad/trunk/src/libpc/pcParameter.h: declare the makeIterator() functions |
| 14:09.51 | CIA-62 | BRL-CAD: 03brlcad * r45202 10/brlcad/trunk/src/other/openNURBS/ (CMakeLists.txt Makefile.am): opennurbs_x has nothing to do with X11, it deals with surface/curve intersection events. enable it for compilation. |
| 14:10.13 | CIA-62 | BRL-CAD: 03brlcad * r45203 10/brlcad/trunk/src/proc-db/surfaceintersect.cpp: don't pretend to be openNURBS |
| 14:11.44 | CIA-62 | BRL-CAD: 03brlcad * r45204 10/brlcad/trunk/src/proc-db/surfaceintersect.cpp: @check is no-good, @brief |
| 14:16.13 | CIA-62 | BRL-CAD: 03brlcad * r45205 10/brlcad/trunk/src/libdm/dm-plot.c: not an e-mail, change to name. doxygenify, use INIT_ZERO. |
| 14:19.57 | CIA-62 | BRL-CAD: 03brlcad * r45206 10/brlcad/trunk/include/dvec.h: describe the typedefs |
| 14:20.23 | CIA-62 | BRL-CAD: 03brlcad * r45207 10/brlcad/trunk/ (include/wdb.h src/libwdb/reg.c): comments belong in header, only say it once. |
| 14:33.40 | *** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz) | |
| 14:37.54 | *** join/#brlcad d_rossbe1g (~rossberg@BZ.BZFLAG.BZ) | |
| 14:47.43 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 15:03.35 | *** join/#brlcad mafm (~mafm@243.Red-88-26-141.staticIP.rima-tde.net) | |
| 15:16.31 | *** join/#brlcad Stattrav (~Stattrav@117.202.19.109) | |
| 15:16.31 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:00.25 | *** join/#brlcad Elrohir (~kvirc@p5B14AEB2.dip.t-dialin.net) | |
| 16:32.15 | *** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz) | |
| 16:50.47 | CIA-62 | BRL-CAD: 03brlcad * r45208 10/brlcad/trunk/include/bu.h: move around the grouping so that all of the libbu groups are within the libbu group. needs lots more work. |
| 16:53.35 | brlcad | hello pawleeq |
| 17:30.25 | CIA-62 | BRL-CAD: 03brlcad * r45209 10/brlcad/trunk/include/bu.h: |
| 17:30.25 | CIA-62 | BRL-CAD: remove all of the B U _ expanded function names. it helped find API functions |
| 17:30.25 | CIA-62 | BRL-CAD: in the source files where they were mixed with implementation code, but in the |
| 17:30.25 | CIA-62 | BRL-CAD: header, it's all API. moreover, it makes our documenting job harder since it |
| 17:30.25 | CIA-62 | BRL-CAD: prevents auto-brief (recognition of the first line/sentance as a brief |
| 17:30.25 | CIA-62 | BRL-CAD: description). with the title removed, we can remove all of the @brief markers |
| 17:30.26 | CIA-62 | BRL-CAD: too. |
| 17:33.04 | CIA-62 | BRL-CAD: 03brlcad * r45210 10/brlcad/trunk/include/bu.h: deprecated is not a doxygen command, just make it the first line instead. make bu_cv_w_cookie() params match declared param names. |
| 17:34.36 | CIA-62 | BRL-CAD: 03brlcad * r45211 10/brlcad/trunk/src/libbu/ (22 files): remove all group inclusions from the source files. cleans up output since the groups were disjoint from those described in the header file and makes it easier to rearrange public API in one place. |
| 18:00.05 | kunigami | brlcad: yes, osl-renderer.h is used by sh_osl |
| 18:26.35 | *** join/#brlcad Stattrav (~Stattrav@117.202.19.109) | |
| 18:26.35 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:38.03 | *** join/#brlcad Stattrav (~Stattrav@117.202.19.109) | |
| 18:38.03 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:46.02 | *** join/#brlcad Stattrav (~Stattrav@117.202.19.109) | |
| 18:46.02 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:48.02 | brlcad | kunigami: there are two |
| 18:49.24 | CIA-62 | BRL-CAD: 03kunigami * r45212 10/brlcad/trunk/include/osl-renderer.h: old version of osl-renderer.h that I forgot to delete. It was moved to liboptical |
| 18:49.46 | brlcad | made sure it's not in the CMakeLists or Makefile.am? |
| 18:50.53 | kunigami | brlcad: thanks |
| 18:51.00 | CIA-62 | BRL-CAD: 03kunigami * r45213 10/brlcad/trunk/include/CMakeLists.txt: removing osl-renderer.h from CMakeLists.txt |
| 18:59.57 | *** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz) | |
| 19:01.30 | *** join/#brlcad Stattrav (~Stattrav@117.202.19.109) | |
| 19:01.30 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:14.18 | *** join/#brlcad Stattrav (~Stattrav@117.202.19.109) | |
| 19:14.18 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:03.17 | CIA-62 | BRL-CAD: 03bhinesley * r45214 10/brlcad/trunk/src/libged/translate.c: adding 'combination' argument, more robust argument handling |
| 20:06.28 | CIA-62 | BRL-CAD: 03bhinesley * r45215 10/brlcad/trunk/src/libged/translate.c: oops, poorly formatted error |
| 20:08.01 | CIA-62 | BRL-CAD: 03bhinesley * r45216 10/brlcad/trunk/src/libged/translate.c: heh, still wrong |
| 20:23.15 | *** join/#brlcad Stattrav (~Stattrav@117.202.19.109) | |
| 20:23.15 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:39.40 | CIA-62 | BRL-CAD: 03brlcad * r45217 10/brlcad/trunk/include/ (bu.h cmd.h magic.h vfont-if.h): naturally still needs a lot more work, but sort out more high-level organization of the API sections. top-level groups aren't set yet, but lower-level ones now have fuller names |
| 20:51.03 | bhinesley | how can I check that the path to a combination/object is valid? For instance, primitive.s/region.r is a bad path. |
| 20:51.23 | bhinesley | I mean, is there a function that handles this |
| 20:52.10 | bhinesley | doh, I guess that would be db_lookup |
| 21:21.35 | CIA-62 | BRL-CAD: 03bhinesley * r45218 10/brlcad/trunk/src/libged/translate.c: added checks for existence of paths that are passed in |
| 21:23.33 | CIA-62 | BRL-CAD: 03kunigami * r45219 10/brlcad/trunk/src/liboptical/sh_osl.cpp: added a parameter to osl_specifics to hold the shadername |
| 21:49.57 | CIA-62 | BRL-CAD: 03bhinesley * r45220 10/brlcad/trunk/src/libged/translate.c: Cleanup, store strings so that conversions aren't needed later, use LOOKUP_NOISY. There remains a problem doing a db_lookup on s_full_path. |
| 23:34.49 | *** join/#brlcad kunigami_ (~kunigami@201.53.197.251) | |
| 00:45.08 | *** join/#brlcad crazy_imp (~mj@a89-182-188-243.net-htp.de) | |
| 00:58.04 | *** join/#brlcad kunigami_ (~kunigami@201.53.197.251) | |
| 01:16.32 | CIA-62 | BRL-CAD: 03kunigami * r45221 10/brlcad/trunk/src/liboptical/ (CMakeLists.txt osl_rt2.c): the C osl raytracer example is no longer necessary |
| 01:59.42 | kunigami_ | when shooting a new ray from a shader, is it better to define a new struct application or to use the same we receive as parameter? |
| 02:09.08 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 02:09.08 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412) | |
| 02:13.09 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) | |
| 06:33.55 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 06:37.07 | *** join/#brlcad Stattrav (~Stattrav@122.167.214.98) | |
| 06:37.07 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:42.11 | *** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 09:39.38 | *** join/#brlcad Elrohir (~kvirc@p5B14A86A.dip.t-dialin.net) | |
| 09:52.27 | *** join/#brlcad mafm (~mafm@102.Red-81-32-97.dynamicIP.rima-tde.net) | |
| 09:55.29 | *** join/#brlcad mafm_ (~mafm@102.Red-81-32-97.dynamicIP.rima-tde.net) | |
| 10:04.45 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 10:04.45 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:18.14 | *** join/#brlcad Stattrav_ (~Stattrav@122.167.214.98) | |
| 10:45.54 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 11:16.55 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 12:18.37 | *** join/#brlcad kunigami (~kunigami@201.53.197.251) | |
| 12:27.46 | *** join/#brlcad kunigami1 (~kunigami@loco-gw.ic.unicamp.br) | |
| 13:32.06 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 14:00.51 | starseeker | ``Erik: http://www.amazon.com/Parsing-Techniques-Practical-Monographs-Computer/dp/1441919015 |
| 14:01.01 | starseeker | that looks interesting (if a bit expensive) |
| 16:31.20 | *** join/#brlcad Elrohir (~kvirc@p5B14A86A.dip.t-dialin.net) | |
| 16:35.13 | kunigami | is "quaturnion" a typo of "quaternion" or it is actually a valid word? |
| 16:37.58 | *** join/#brlcad Stattrav (~Stattrav@117.192.130.174) | |
| 16:37.58 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:04.45 | ``Erik | I'd assume it's a misspelling |
| 19:05.14 | CIA-62 | BRL-CAD: 03bob1961 * r45222 10/brlcad/trunk/src/tclscripts/mged/text.tcl: Modified the "gets" proc to use the last line in getsVal. |
| 20:57.13 | CIA-62 | BRL-CAD: 03starseeker * r45223 10/brlcad/trunk/src/libpc/CMakeLists.txt: Add libz to the libpc include dirs |
| 21:43.32 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 21:49.42 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 22:04.00 | kunigami | In the script db/cornell.rt, the parameter "orientation" is 4-dimensional. If I understood right, it is representing a quaternion. I just learned what a quaternion is and how it can represent a rotation around a given axis. Can I extract the viewing direction from this quaternion? |
| 23:50.21 | starseeker | sweet: http://www.ibm.com/developerworks/library/l-lexyac/index.html |
| 00:06.32 | CIA-62 | BRL-CAD: 03bhinesley * r45224 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: set outdated argument list to void |
| 00:08.10 | CIA-62 | BRL-CAD: 03bhinesley * r45225 10/brlcad/trunk/include/raytrace.h: we have a DB_FULL_PATH_CUR_DIR, so why not add a DB_FULL_PATH_DOOR_DIR, too. |
| 00:10.23 | CIA-62 | BRL-CAD: 03bhinesley * r45226 10/brlcad/trunk/src/libged/translate.c: Adding ged_ispath to determine if supplied paths exist. Previous translate cmd tests were all wrong, and were removed. I'll find a better home for ispath once it's working. Not sure if it needs to be an actual command. |
| 00:11.42 | bhinesley | things are starting to make sense (finally) |
| 00:12.32 | bhinesley | understanding the database format has been a struggle... new to me |
| 00:14.43 | bhinesley | haha, that's DB_FULL_PATH_ROOT_DIR, not DOOR_DIR |
| 00:15.22 | bhinesley | 's brain is fried |
| 00:31.53 | CIA-62 | BRL-CAD: 03bhinesley * r45227 10/brlcad/trunk/include/raytrace.h: r45225 added DB_FULL_PATH_ROOT_DIR, not DB_FULL_PATH_DOOR_DIR |
| 00:45.31 | *** join/#brlcad crazy_imp (~mj@a89-182-163-109.net-htp.de) | |
| 01:50.54 | CIA-62 | BRL-CAD: 03kunigami * r45228 10/brlcad/trunk/src/liboptical/ (CMakeLists.txt osl_rt.cpp): |
| 01:50.54 | CIA-62 | BRL-CAD: modifying osl_rt so that it renders brl-cad scenes. It shoots its own rays and |
| 01:50.54 | CIA-62 | BRL-CAD: calls rt_shootray. I'm using the cornel.g db, with the parameters in |
| 01:50.54 | CIA-62 | BRL-CAD: db/cornell.rt script. By now, it justs prints a message when a object is hit. |
| 01:50.54 | CIA-62 | BRL-CAD: Next step is to identify the name of the osl-shader the object belongs to |
| 02:02.23 | CIA-62 | BRL-CAD: 03bhinesley * r45229 10/brlcad/trunk/src/libged/translate.c: ged_ispath should use standard GED function return codes |
| 02:05.45 | CIA-62 | BRL-CAD: 03kunigami * r45230 10/brlcad/trunk/src/ (5 files in 4 dirs): changed occurrences of quaturnion by quaternion |
| 02:32.36 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 02:32.36 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412) | |
| 02:37.02 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 02:37.02 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412) | |
| 04:01.32 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 04:08.45 | CIA-62 | BRL-CAD: 03bhinesley * r45231 10/brlcad/trunk/src/libged/translate.c: ged_is_path is now functioning (privately) :) It would be useful for several functions, so they can check paths and not die a meaningless death like 'ls shell.c/nut.c'. Now to find it a home. |
| 04:13.48 | bhinesley | brlcad: really hoping I didn't duplicate any functionality with that one ^ |
| 04:13.48 | bhinesley | I looked around but couldn't find anything that did the trick. Assuming that I haven't, any suggestions on where it should live and/or what it should be named? |
| 04:35.43 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r2935 10/wiki/User:Bhinesley: /* Log */ last few days, today, plan tomorrow+ |
| 04:39.23 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r2936 10/wiki/User:Bhinesley: /* Log */ clarified dates an item was worked on |
| 06:59.46 | *** join/#brlcad Stattrav (~Stattrav@117.192.148.225) | |
| 06:59.46 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:17.54 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:58.22 | *** join/#brlcad Stattrav (~Stattrav@117.202.16.22) | |
| 07:58.22 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:03.23 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:15.42 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:20.43 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.154.61) | |
| 09:15.31 | *** join/#brlcad mafm_ (~mafm@162.Red-83-38-35.dynamicIP.rima-tde.net) | |
| 11:20.19 | brlcad | kunigami: it's usually better to define a new struct application for each new ray segment being fired |
| 11:23.02 | brlcad | kunigami: orientation is a quaternion (and that was a set of typos) and yes, you can extract the viewing direction (which is what the mged "loadview" command partially does |
| 11:26.20 | brlcad | bhinesley: hope you didn't too as low-level functionality like that is easy to replicate (because it can be hard to find unless you wrote it) |
| 11:27.41 | brlcad | I wouldn't be surprised if that logic existed somewhere but the important part is that it's not readily documented, so if your implementat does anything new, it should be that ;) |
| 11:28.46 | brlcad | for now, I'd treat is as private (documented) libged API (src/libged/ged_private.h) |
| 11:31.05 | brlcad | libged is supposed to consist of a private API for reuse across ged functions and the public API for external reuse and transactional access into the struct ged |
| 11:33.54 | brlcad | starseeker: best way to learn lex/yacc, highly recommended -- use that tutorial and write a simple parser for something real but not too complicated (maybe a povray parser or a csv parser) |
| 12:12.45 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:29.51 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 12:35.27 | kunigami | I've a strange linker error: http://pastebin.mozilla.org/1256847 |
| 12:36.35 | kunigami | it does not find mlib_setup, even tough I'm linking to liboptical and this function is in the liboptical table |
| 12:37.15 | kunigami | there's a strange warning too: warning: can't find atom for N_GSYM stabs ep:G(0,423) in CMakeFiles/osl_rt.dir/osl_rt.cpp.o |
| 12:48.25 | kunigami | this error happens both on mac and linux :( |
| 13:00.01 | starseeker | makes a note to study this more carefully, even though src/other may make it impractical: http://www.vtk.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file |
| 14:56.01 | CIA-62 | BRL-CAD: 03bhinesley * r45232 10/brlcad/trunk/src/libged/translate.c: check for empty tree is unnecessary, as db_find_named_leaf will return correctly either way |
| 15:25.28 | CIA-62 | BRL-CAD: 03bhinesley * r45233 10/brlcad/trunk/src/libged/ (CMakeLists.txt Makefile.am ged_private.h path.c translate.c): Renamed ged_is_path to _ged_path_validate, and moved it into a seperate file. Exposed it via ged_private. |
| 15:39.32 | CIA-62 | BRL-CAD: 03bhinesley * r45234 10/brlcad/trunk/src/libged/path.c: Document _ged_path_validate interface |
| 16:09.54 | CIA-62 | BRL-CAD: 03erikgreenwald * r45235 10/brlcad/trunk/src/libged/translate.c: change strtof to strtod. fastf_t is double and windows doesn't have strtof. |
| 16:16.10 | kunigami | I'm trying to extract the view direction from the quaternion with the following code: http://pastebin.mozilla.org/1256899 Though the scene that is rendered is not the same as when I run it with cornell.rt script. |
| 16:26.13 | CIA-62 | BRL-CAD: 03erikgreenwald * r45236 10/brlcad/trunk/ (include/ged.h src/libged/path.c src/libged/translate.c): Remove _ prefix from _ged_path_validate and add prototype to ged.h. |
| 16:37.14 | *** join/#brlcad yiyus (1242712427@server1.bouncer4you.de) | |
| 16:54.07 | *** join/#brlcad mafm (~mafm@162.Red-83-38-35.dynamicIP.rima-tde.net) | |
| 17:10.36 | CIA-62 | BRL-CAD: 03bhinesley * r45237 10/brlcad/trunk/src/libged/ged_private.h: r45236 put ged_path_validate in ged.h, so remove it from ged_private.h |
| 17:30.12 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.154.61) | |
| 17:46.56 | *** join/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 18:49.08 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:06.58 | *** join/#brlcad Stattrav (~Stattrav@117.192.154.61) | |
| 19:06.58 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:29.36 | *** join/#brlcad Stattrav (~Stattrav@117.192.154.61) | |
| 19:29.40 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:41.43 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.154.61) | |
| 20:17.43 | CIA-62 | BRL-CAD: 03bhinesley * r45238 10/brlcad/trunk/src/ (66 files in 32 dirs): Quieted all 511 warnings about using number formatting other than %zu for a size_t argument. |
| 21:24.21 | *** join/#brlcad kunigami (~kunigami@201.53.197.251) | |
| 22:13.24 | *** join/#brlcad Stattrav (~Stattrav@117.192.154.61) | |
| 22:13.24 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 22:21.46 | *** join/#brlcad Stattrav (~Stattrav@117.192.154.61) | |
| 22:21.46 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 22:29.44 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 22:47.28 | *** join/#brlcad Stattrav (~Stattrav@117.192.154.61) | |
| 22:47.28 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 22:53.48 | *** join/#brlcad Stattrav (~Stattrav@117.192.154.61) | |
| 22:53.48 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 23:02.13 | *** join/#brlcad Stattrav (~Stattrav@117.192.154.61) | |
| 23:02.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 23:13.01 | bhinesley | for a windows cmake build, do we use mingw32-make.exe? I can't seem to get it to work: http://pastebin.mozilla.org/1257485 |
| 23:35.28 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 23:45.04 | *** join/#brlcad Stattrav (~Stattrav@117.192.154.61) | |
| 23:45.04 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 00:45.50 | *** join/#brlcad crazy_imp (~mj@a89-182-180-139.net-htp.de) | |
| 01:29.25 | CIA-62 | BRL-CAD: 03kunigami * r45239 10/brlcad/trunk/src/liboptical/ (osl-renderer.cpp osl_rt.cpp): |
| 01:29.25 | CIA-62 | BRL-CAD: updated version of osl_rt. It now renders brlcad scenes using osl shaders. the |
| 01:29.25 | CIA-62 | BRL-CAD: results are still strange, but are getting better. I managed to find a suitable |
| 01:29.25 | CIA-62 | BRL-CAD: direction for the viewpoint for the scene cornell.g on db/. I did it |
| 01:29.25 | CIA-62 | BRL-CAD: empirically, since I couldnt extract this information from the orientation |
| 01:29.26 | CIA-62 | BRL-CAD: quaternion. |
| 01:33.29 | kunigami | http://dl.dropbox.com/u/1399996/GSoC/OSL_RT-2011-06-24.png -- is the result from the latest osl ray tracer. the scene is the cornell.g. walls are of diffuse blue, floor is diffuse red. Tall box diffuse yellow and short box is mirror. The light in the ceiling is an emitter shader. (the scene is kinda dark. in the next render I'll try a stronger emission value) |
| 07:04.43 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:51.13 | *** join/#brlcad Stattrav (~Stattrav@117.192.154.61) | |
| 07:51.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:52.32 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.154.61) | |
| 08:24.40 | *** join/#brlcad Stattrav (~Stattrav@117.192.133.205) | |
| 08:24.40 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:34.13 | ``Erik | is the shader you're using a path tracer? photon mapper? |
| 12:35.30 | ``Erik | have you tried a simple phong shader and compared to non-osl raytraces to try to get the input mapping for osl? |
| 12:35.54 | ``Erik | (pretty cool, btw) |
| 13:28.43 | kunigami1 | To tell the truth, I actually don't know the difference between path tracer and photon mapper :P I've just adapted a previous renderer that some guy implemented for osl |
| 13:29.13 | kunigami1 | I still have to make tests with phong shaders and glass too (thanks) |
| 15:55.02 | starseeker | O.o http://www.bloodhoundssc.com/car/facts_and_figures/cad_drawings.cfm |
| 16:13.03 | starseeker | need to translate 'em to STEP... |
| 17:46.04 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:00.32 | *** join/#brlcad michael (~michael@cpe-24-210-25-11.columbus.res.rr.com) | |
| 18:02.44 | *** join/#brlcad Otto__ (~Otto@cpe-24-210-25-11.columbus.res.rr.com) | |
| 18:03.13 | *** join/#brlcad Otto__ (~Otto@cpe-24-210-25-11.columbus.res.rr.com) | |
| 18:40.04 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 23:12.56 | louipc | Should the channel topic be updated for the new version? |
| 23:14.37 | *** join/#brlcad Otto__ (~Otto@cpe-24-210-25-11.columbus.res.rr.com) | |
| 00:46.11 | *** join/#brlcad crazy_imp (~mj@a89-182-228-189.net-htp.de) | |
| 01:29.25 | *** join/#brlcad kunigami (~kunigami@201.53.197.251) | |
| 03:29.08 | *** join/#brlcad Soze49 (~Soze@186.136.208.223) | |
| 03:34.24 | Soze49 | Hi, sorry if I'm out of topic but, could you please point me to some information source about making cross sections of 3d models ? I'm working with STL files, and I need yo make cross sections from the models so any advice on existent algorithms, methods, etc is what i need. |
| 03:54.12 | Otto__ | the fastest way that I found was to make an arb8 that cut out the part you didn't want. you could also use an arb8 that would only include the area you wanted to keep. |
| 04:03.02 | Soze49 | but I have a 3d model made of triangle facets so the idea is to construct a bitmap of the intersection of a plane with the model |
| 04:17.05 | Otto__ | Honestly not to be of any help, but I'm of no help. I'm not too sure of how to go about that. May google search prove fruitful |
| 07:42.17 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:48.14 | *** join/#brlcad Stattrav (~Stattrav@117.192.149.147) | |
| 08:48.14 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:55.42 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:59.07 | *** join/#brlcad Stattrav (~Stattrav@117.192.149.147) | |
| 14:59.07 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:56.08 | *** part/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 17:07.24 | *** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 18:27.42 | *** join/#brlcad Otto_ (~Otto@cpe-24-210-25-11.columbus.res.rr.com) | |
| 19:06.08 | *** join/#brlcad Stattrav (~Stattrav@117.192.133.14) | |
| 19:06.08 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 22:31.45 | *** join/#brlcad Stattrav (~Stattrav@117.192.133.14) | |
| 22:31.45 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 00:45.33 | *** join/#brlcad crazy_imp (~mj@a89-182-161-248.net-htp.de) | |
| 01:37.22 | *** part/#brlcad kunigami (~kunigami@201.53.197.251) | |
| 01:40.37 | CIA-62 | BRL-CAD: 03kunigami * r45240 10/brlcad/trunk/src/liboptical/sh_osl.cpp: instead of using the same struct application, create another one when shooting a new ray |
| 04:09.02 | *** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 04:16.24 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) | |
| 07:24.11 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:10.08 | CIA-62 | BRL-CAD: 03d_rossberg * r45241 10/brlcad/trunk/src/libgcv/bottess.c: fixed MSVC build: rt_bot_describe() is not DLL-exported (and it should not), used the pointer from the function table instead |
| 11:18.35 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 11:26.30 | ``Erik | herr Roßberg, apologies for leaving that garbage in, it will be gone this week :) |
| 11:33.29 | d_rossberg | apologies accepted, sir :) |
| 11:49.01 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 11:49.12 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 12:29.10 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 16:19.30 | *** join/#brlcad Stattrav (~Stattrav@117.202.29.208) | |
| 16:19.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:38.37 | CIA-62 | BRL-CAD: 03r_weiss * r45242 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: Update to quiet compiler warnings. Change was to file 'nmg_bool.c' function 'nmg_booltree_evaluate'. |
| 17:13.47 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2937 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */ Week 5 |
| 17:51.39 | CIA-62 | BRL-CAD: 03r_weiss * r45243 10/brlcad/trunk/src/librt/primitives/nmg/nmg_pt_fu.c: Updated functions 'nmg_class_pt_lu' and 'nmg_class_pt_fu_except' located within file 'nmg_pt_fu.c'. Improved the compare against nmg object bounding boxes by including the distance tolerance in the compare. |
| 17:51.51 | *** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net) | |
| 17:51.53 | yukonbob | hello, #brlcad |
| 17:55.14 | bhinesley | hi, yukonbob |
| 18:03.00 | CIA-62 | BRL-CAD: 03starseeker * r45244 10/brlcad/trunk/src/other/CMakeLists.txt: Mark this option as adavnced - eventually it will go away altogether, once we get it straightened out what tool chain we'll be using and add ThirdParty/Find* tests for what we need. |
| 18:14.41 | CIA-62 | BRL-CAD: 03starseeker * r45245 10/brlcad/trunk/ (misc/CMakeLists.txt src/other/CMakeLists.txt): Couple quick distcheck entries. |
| 18:20.26 | bhinesley | starseeker: for a windows cmake build, do we use mingw32-make.exe? I can't seem to get it to work: http://pastebin.mozilla.org/1257485 |
| 18:21.14 | starseeker | bhinesley: Normally we use Microsoft Visual C++ |
| 18:21.38 | bhinesley | ok |
| 18:21.40 | bhinesley | thanks |
| 18:22.14 | starseeker | in principle other Windows build approaches should work, but it's quite a lot of time/effort to set up to try them and we just haven't lately |
| 18:22.39 | bhinesley | nods |
| 18:28.21 | CIA-62 | BRL-CAD: 03starseeker * r45246 10/brlcad/trunk/src/other/Makefile.am: Ignore files in Makefile.am too. |
| 18:31.14 | CIA-62 | BRL-CAD: 03starseeker * r45247 10/brlcad/trunk/src/other/Makefile.am: files too, not just dirs. |
| 18:51.35 | *** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net) | |
| 19:05.23 | *** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 19:09.22 | *** join/#brlcad __monty__ (~toon@242.93-242-81.adsl-dyn.isp.belgacom.be) | |
| 19:10.05 | __monty__ | Hi, just looking for the latest version of brl cad that works on a ppc mac. 7.6.6? |
| 19:19.02 | __monty__ | Oh, found it 7.10.4, excuse my laziness. |
| 19:35.39 | CIA-62 | BRL-CAD: 03bhinesley * r45248 10/brlcad/trunk/src/libged/combmem.c: Using the first element of argv to refer to the command name doesn't work so well after you've incremented it. |
| 22:22.12 | CIA-62 | BRL-CAD: 03bhinesley * r45249 10/brlcad/trunk/src/libged/translate.c: Don't allow -r and -k options simultaneously. Distinguish between solids and combinations. |
| 22:28.58 | *** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no) | |
| 22:31.09 | *** join/#brlcad merzo (~merzo@235-121-133-95.pool.ukrtel.net) | |
| 22:32.14 | CIA-62 | BRL-CAD: 03starseeker * r45250 10/brlcad/trunk/src/other/ (7 files in 7 dirs): Remove some package stuff in src/other that we don't need and is interfering with rpmbuild - byacc in particular we won't need this for since byacc is intended here only as a build aid. |
| 22:57.35 | CIA-62 | BRL-CAD: 03starseeker * r45251 10/brlcad/trunk/src/other/ (tcl.dist tk.dist): dist files worked - complained that these files weren't there. |
| 23:56.59 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 00:13.33 | *** join/#brlcad merzo (~merzo@235-121-133-95.pool.ukrtel.net) | |
| 00:13.33 | *** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 00:46.05 | *** join/#brlcad crazy_imp (~mj@a89-182-244-94.net-htp.de) | |
| 02:10.46 | CIA-62 | BRL-CAD: 03bhinesley * r45252 10/brlcad/trunk/ (include/ged.h src/libged/path.c src/libged/translate.c): |
| 02:10.46 | CIA-62 | BRL-CAD: Isolating core translate functionality into a seperate function, so that it |
| 02:10.46 | CIA-62 | BRL-CAD: could be more readily called internally. Laid out comments on how it will be |
| 02:10.46 | CIA-62 | BRL-CAD: finished (hopefully tomorrow). Also, ged_path_validate had a parameter byval |
| 02:10.46 | CIA-62 | BRL-CAD: when it should have been a const \* |
| 05:08.46 | brlcad | starseeker: what's the equivalent of --disable-strict with cmake? |
| 05:16.11 | *** join/#brlcad Stattrav (~Stattrav@122.167.214.98) | |
| 05:16.11 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:50.42 | CIA-62 | BRL-CAD: 03brlcad * r45253 10/brlcad/trunk/misc/brlcad.spec.in: still woefully incomplete, but this should at least make the spec file behave better for autotool builds |
| 05:52.36 | brlcad | kunigami1: you can load that .rt viewscript into mged, set the view center (I list it in the file itself), then query the view direction (see 'view' command) |
| 05:54.26 | brlcad | the other piece of the puzzle is that the cornell.rt script sets up a 60 degree perspective view, not orthogonal rays -- if you remove the -p60 from the .rt file, you might have better luck getting a matching fivew |
| 05:56.18 | brlcad | kunigami1: http://dl.dropbox.com/u/1399996/GSoC/OSL_RT-2011-06-24.png is looking pretty swank... nifty |
| 06:00.54 | *** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.0 is posted, 7.20.2 undering build release testing now (20110628) | |
| 06:02.07 | brlcad | louipc: thx for the reminder |
| 06:02.10 | brlcad | though we're not topic-locked, you (or anyone) can update it as needed .. |
| 06:10.00 | bhinesley | brlcad: -DBRLCAD-ENABLE_STRICT=OFF |
| 06:16.07 | brlcad | bhinesley: thx |
| 08:33.56 | *** join/#brlcad merzo (~merzo@235-121-133-95.pool.ukrtel.net) | |
| 10:32.46 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 12:48.48 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:28.00 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 14:02.50 | *** join/#brlcad merzo (~merzo@157-86-133-95.pool.ukrtel.net) | |
| 14:21.49 | starseeker | brlcad: -DBRLCAD-ENABLE_STRICT=OFF |
| 14:22.30 | starseeker | brlcad: did you have a chance to reproduce that distcheck failure? |
| 14:28.29 | brlcad | not yet, but looking at it now |
| 14:28.36 | brlcad | starseeker: can't find the pdf |
| 14:48.33 | CIA-62 | BRL-CAD: 03brlcad * r45254 10/brlcad/trunk/bench/run.sh: |
| 14:48.33 | CIA-62 | BRL-CAD: so comparing by -lt makes the timing comparison suck for normal iterations |
| 14:48.33 | CIA-62 | BRL-CAD: because it causes the comparison to effectively be the floor() of the elapsed |
| 14:48.33 | CIA-62 | BRL-CAD: time, which makes causes TIMEFRAME to get exceeded (e.g., elp=1.99 will iterate |
| 14:48.33 | CIA-62 | BRL-CAD: again even if TIMEFRAME=1). revert back to less-than since what we really need |
| 14:48.34 | CIA-62 | BRL-CAD: is a do-while loop. achieve the same by initializing our elapsed counters to |
| 14:48.34 | CIA-62 | BRL-CAD: negative, so we still get sane behavior at TIMEFRAME=0. |
| 14:52.22 | CIA-62 | BRL-CAD: 03brlcad * r45255 10/brlcad/trunk/bench/run.sh: allow the benchmark to accelerate by two orders of magnitude at a time if we're on crazy fast hardware. allows faster convergence with fewer iterations. |
| 14:56.00 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 15:33.14 | CIA-62 | BRL-CAD: 03brlcad * r45256 10/brlcad/trunk/bench/Makefile.am: go ahead and add a distclean rule so proper cleaning is performed during distcheck |
| 15:58.43 | CIA-62 | BRL-CAD: 03brlcad * r45257 10/brlcad/trunk/bench/run.sh: |
| 15:58.43 | CIA-62 | BRL-CAD: change the name of our iteration log/pix files to be more consistent with the |
| 15:58.43 | CIA-62 | BRL-CAD: benchmark.log files using -PID prior to the file extension. also be more |
| 15:58.43 | CIA-62 | BRL-CAD: careful to only keep a backup once so that a given -PID test iteration backup |
| 15:58.43 | CIA-62 | BRL-CAD: file should correspond to the previous *benchmark* run, not just the previous |
| 15:58.44 | CIA-62 | BRL-CAD: *iteration*. refactor into function since we do the cleanup twice. |
| 16:00.00 | CIA-62 | BRL-CAD: 03brlcad * r45258 10/brlcad/trunk/src/libged/translate.c: c++-style // comments are not allowed for portability |
| 16:18.35 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2938 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */ libpng conflict solved |
| 16:50.45 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 17:56.38 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.220) | |
| 17:56.38 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:47.00 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.220) | |
| 18:47.00 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:11.37 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.220) | |
| 19:11.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:27.26 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.220) | |
| 19:27.26 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:34.05 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.220) | |
| 19:34.05 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:42.48 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.220) | |
| 19:42.48 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:36.53 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.220) | |
| 20:36.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:43.01 | CIA-62 | BRL-CAD: 03bhinesley * r45259 10/brlcad/trunk/src/libged/translate.c: |
| 20:43.01 | CIA-62 | BRL-CAD: Retrieves correct tree to be edited: |
| 20:43.01 | CIA-62 | BRL-CAD: A)If path's CWD isn't '/', the object's parent is retrieved so that the object's entry can be modified. |
| 20:43.01 | CIA-62 | BRL-CAD: B)If the path is '/', the object (combination) itself is returned so that all instances of object are changed, by modifying it's entire tree. |
| 20:43.01 | CIA-62 | BRL-CAD: All existing logic relating to this was moved to translate(). |
| 20:46.07 | CIA-62 | BRL-CAD: 03bhinesley * r45260 10/brlcad/trunk/src/libged/translate.c: that's CWD/obj, not "object's parent", whatever that was supposed to mean |
| 21:18.17 | CIA-62 | BRL-CAD: 03brlcad * r45261 10/brlcad/trunk/ (include/ged.h src/libged/ged.c): ged_drawable_close() is an implementation detail, probably doesn't need to be public API, so migrate functionality into ged_close() and remove it. |
| 21:24.39 | CIA-62 | BRL-CAD: 03brlcad * r45262 10/brlcad/trunk/src/libged/ged.c: same thing with ged_drawable_init() .. remove it from public api, absorbed into ged_init() |
| 21:25.25 | CIA-62 | BRL-CAD: 03kunigami * r45263 10/brlcad/trunk/src/liboptical/osl_rt.cpp: performing tests with refraction (glass shader). it is not working correclty. internal ray probably is not being delt right. |
| 21:27.16 | *** part/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 21:49.11 | CIA-62 | BRL-CAD: 03brlcad * r45264 10/brlcad/trunk/src/mged/mged.c: remove calls to ged_drawable_close(). simplifies cleanup to just ged_close(). |
| 21:49.43 | CIA-62 | BRL-CAD: 03brlcad * r45265 10/brlcad/trunk/include/ged.h: qray stuff shouldn't be public api |
| 21:51.18 | CIA-62 | BRL-CAD: 03brlcad * r45266 10/brlcad/trunk/src/libged/ (ged.c ged_private.h nirt.c qray.c qray.h): rename ged_qray_*() functions so they don't appear to be public api. prefix them with just qray_*() and declare the ones used elsewhere in the qray.h private header. |
| 22:01.43 | CIA-62 | BRL-CAD: 03brlcad * r45267 10/brlcad/trunk/src/libged/ (10 files): ws indent style cleanup |
| 22:08.07 | CIA-62 | BRL-CAD: 03brlcad * r45268 10/brlcad/trunk/src/libged/ (17 files): ws indent style cleanup |
| 22:26.21 | CIA-62 | BRL-CAD: 03starseeker * r45269 10/brlcad/trunk/src/other/tktable/unix/: delete empty unix directory. |
| 22:27.59 | CIA-62 | BRL-CAD: 03starseeker * r45270 10/brlcad/trunk/src/other/tktable.dist: update tk dist file |
| 22:29.52 | CIA-62 | BRL-CAD: 03brlcad * r45271 10/brlcad/trunk/src/libged/ (20 files): ws indent style cleanup |
| 22:32.42 | CIA-62 | BRL-CAD: 03bhinesley * r45272 10/brlcad/trunk/src/libged/translate.c: remove superfluous parentheses |
| 22:43.28 | CIA-62 | BRL-CAD: 03bhinesley * r45273 10/brlcad/trunk/src/libged/translate.c: break/shorten comments past 70th column |
| 22:46.55 | starseeker | blinks - woah, all of a sudden we're getting ERROR: bad pointer 0x1dc43300: s/b rt_wdb(x5f576462), was Unknown_Magic(x3a24d53e48), file src/librt/wdb.c, line 419 |
| 22:47.39 | CIA-62 | BRL-CAD: 03brlcad * r45274 10/brlcad/trunk/src/libged/ (22 files): ws indent style cleanup |
| 22:51.47 | brlcad | starseeker: with what? |
| 22:52.58 | *** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net) | |
| 22:53.13 | brlcad | there should be a stack report for that one too, should be obvious where it's coming from |
| 22:53.45 | brlcad | maybe related to r45261 or r45264 or similar change |
| 22:54.05 | brlcad | in which case something just not being initialized or free'd correctly |
| 22:57.39 | CIA-62 | BRL-CAD: 03brlcad * r45275 10/brlcad/trunk/src/libged/ (44 files): ws (mostly trailing ws elimination) |
| 22:59.57 | starseeker | brlcad: make regress - wdb_close is getting bad magic |
| 23:00.51 | starseeker | wdb_close being called by ged_close |
| 23:01.35 | brlcad | k, that has to be related then -- I'll look into it |
| 23:02.13 | brlcad | must be closing something that was never opened or previously closed but not set to NULL afterwards, or similar |
| 23:10.12 | CIA-62 | BRL-CAD: 03brlcad * r45276 10/brlcad/trunk/src/libged/ (58 files): batch indent cleanup |
| 23:22.48 | brlcad | bhinesley: I trust you have read the sources to the other translate command? (otranslate.c) just checking to make sure you're not spinning on actually implementing translate |
| 23:25.36 | bhinesley | I've seen it, yes. I think I know what to do now. |
| 23:25.52 | bhinesley | for objects, should I just call ged_otranslate? |
| 23:26.30 | bhinesley | I guess not, it doesn't do relative/absolute/keypoint positioning |
| 23:26.52 | brlcad | right, I'd go the other way around |
| 23:27.10 | brlcad | once you get yours working, make ged_otranslate call your translate func |
| 23:27.17 | bhinesley | alright |
| 23:27.19 | brlcad | ptranslate is siilar |
| 23:27.23 | brlcad | *similar |
| 23:27.27 | bhinesley | what is "p" |
| 23:28.55 | brlcad | o => object |
| 23:28.57 | brlcad | p => primitive |
| 23:29.30 | brlcad | in general, "object" (incorrectly and confusingly) refers to non-primitive combination objects |
| 23:30.14 | bhinesley | ok |
| 23:30.34 | brlcad | you'll see a lot of places where there is a distinction (either at the command or API level) between combs and prims because of how they're implemented, but that's mostly places where librt needs refactoring |
| 23:31.16 | bhinesley | I wanted to ask about flattening the trees: is it best to just build a recursive function or to flatten the tree? I wouldn't have even though about flattening if I hadn't seen db_flatten_tree. |
| 23:31.39 | brlcad | depends what you're doing |
| 23:32.22 | bhinesley | either doing a translation on one node or all of them |
| 23:32.51 | bhinesley | I just assumed that the step of flattening was a waste |
| 23:33.09 | bhinesley | (although that's what translate. is doing right now) |
| 23:33.11 | bhinesley | *.c |
| 23:33.57 | brlcad | in general yes |
| 23:34.21 | brlcad | you shouldn't really (ever) need to flatten a tree unless it's for printing or ease of searching nodes |
| 23:34.33 | brlcad | poor-mans serialization |
| 23:36.25 | bhinesley | alright |
| 23:36.56 | bhinesley | I saw db_flatten_tree being used in a couple places where it probably didn't need to be, then |
| 00:09.47 | brlcad | not surprising |
| 00:09.54 | CIA-62 | BRL-CAD: 03brlcad * r45277 10/brlcad/trunk/src/libged/ (100 files): remainder of ws indent consistency cleanup. reorder to eliminate some forward decls too. |
| 00:11.05 | brlcad | improving code quality is always fair game |
| 00:12.05 | brlcad | whether it's some bit of logic that could be cleaned up or a usage pattern that begs refactoring or outright crap code that needs to be taken out back and shot |
| 00:14.13 | CIA-62 | BRL-CAD: 03brlcad * r45278 10/brlcad/trunk/src/libged/ (CMakeLists.txt Makefile.am subtype.c): subtyping is something that should be defined within the objects themselves down in librt, not at this high level. no matter, the code is a ways off from compiling anyways, so removed from dist. |
| 00:15.00 | *** join/#brlcad merzo (~merzo@157-86-133-95.pool.ukrtel.net) | |
| 00:15.41 | CIA-62 | BRL-CAD: 03brlcad * r45279 10/brlcad/trunk/src/libged/ (vdraw.c wdb_vdraw.c): vmath provides M_SQRT2 |
| 00:23.33 | CIA-62 | BRL-CAD: 03brlcad * r45280 10/brlcad/trunk/src/libged/adc.c: remove ged_ prefix on non-public functions, reorder to eliminate forward decls |
| 00:30.31 | CIA-62 | BRL-CAD: 03brlcad * r45281 10/brlcad/trunk/src/libged/ged.c: don't blindly close the wdbp |
| 00:38.49 | CIA-62 | BRL-CAD: 03brlcad * r45282 10/brlcad/trunk/src/libged/ged.c: initialize the other struct ged members during ged_init() so they can be properly memory-managed. |
| 00:39.34 | CIA-62 | BRL-CAD: 03brlcad * r45283 10/brlcad/trunk/src/libged/ged.c: bah, fix typos |
| 00:46.34 | *** join/#brlcad crazy_imp (~mj@a89-182-231-95.net-htp.de) | |
| 00:50.03 | bhinesley | brlcad: yeah, I should have taken a closer look at otranslate/ptranslate. That helps a lot. |
| 01:14.24 | CIA-62 | BRL-CAD: 03bhinesley * r45284 10/brlcad/trunk/src/libged/ (path.c translate.c): ensure path is initialized and isn't / before trying to access it's directories |
| 01:24.06 | CIA-62 | BRL-CAD: 03bhinesley * r45285 10/brlcad/trunk/src/libged/translate.c: translate.c accidentally included in last commit... inverse merge 45284 |
| 02:44.30 | CIA-62 | BRL-CAD: 03bhinesley * r45286 10/brlcad/trunk/src/librt/db_fullpath.c: it is already assumed that an empty string corresponds to '/', so handle a NULL string the same way (rather than bombing) |
| 02:48.49 | CIA-62 | BRL-CAD: 03brlcad * r45287 10/brlcad/trunk/src/librt/wdb.c: if we're closing a wdbp, make sure all memory is released. set the magic to 0 for sanity too in case someone looks at that memory again later. |
| 04:08.47 | *** join/#brlcad DarkCalf (DC@2002:ade7:2862::ade7:2862) | |
| 04:24.56 | brlcad | starseeker: definitely related, though how to fix this correctly is going to be very tricky .. spagetti code intermingled on the tcl and c sides, both trying to manage that wdbp |
| 04:53.01 | CIA-62 | BRL-CAD: 03bhinesley * r45288 10/brlcad/trunk/src/ (libged/translate.c tclscripts/archer/ArcherCore.tcl): tranlation of all objects in a single combination's tree is now working: 'translate -r 5 5 5 / obj1.c', or equivalently 'translate 5 5 5 obj1.c' |
| 05:04.23 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 05:21.14 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 05:45.00 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r2939 10/wiki/User:Bhinesley: /* Log */ Friday, yesterday, today, plan for the week |
| 05:54.12 | bhinesley | brlcad: I'm getting a segfault when I run 'make'. I see that you might still be working on it, so I'll just say that after an inverse merge of r45287 it goes away. http://pastebin.mozilla.org/1260422 |
| 06:20.30 | CIA-62 | BRL-CAD: 03brlcad * r45289 10/brlcad/trunk/src/librt/wdb.c: better wdb init. don't just set the magic, the forw/back list pointers need initializing. init both vls, not just one of them. |
| 06:24.31 | CIA-62 | BRL-CAD: 03brlcad * r45290 10/brlcad/trunk/src/librt/wdb.c: set the magic properly useing BU_LIST_MAGIC_SET() |
| 06:25.50 | CIA-62 | BRL-CAD: 03brlcad * r45291 10/brlcad/trunk/src/libged/wdb_obj.c: don't wdb_close does the dequeue and vls frees for us |
| 06:26.56 | CIA-62 | BRL-CAD: 03brlcad * r45292 10/brlcad/trunk/src/libged/ged.c: be careful the gdp is not already allocated (should get set to null when deallocated) |
| 06:35.24 | *** join/#brlcad Stattrav (~Stattrav@122.167.214.98) | |
| 06:35.24 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:42.27 | CIA-62 | BRL-CAD: 03brlcad * r45293 10/brlcad/trunk/src/mged/setup.c: protect this file from auto-formatting by making the expansion of ',' into a compile-time error. the 35,25 and 45,45 commands along with the mged_display tcl variable relies on there being no spaces around the comma. |
| 06:48.05 | CIA-62 | BRL-CAD: 03brlcad * r45294 10/brlcad/trunk/src/mged/mged.c: (log message trimmed) |
| 06:48.05 | CIA-62 | BRL-CAD: the wdb tcl objects and ged structures both assume they get to own the wdbp they |
| 06:48.05 | CIA-62 | BRL-CAD: were passed. can't just remove the wdb_close() from wdb_deleteProc() as there |
| 06:48.05 | CIA-62 | BRL-CAD: doesn't seem to be any place in mged where the .inmem wdb is actually recorded |
| 06:48.05 | CIA-62 | BRL-CAD: (it's stored inside a tcl callback). so let the tcl objects do their thing, but |
| 06:48.05 | CIA-62 | BRL-CAD: then that means the ged needs to acquire a full-fledged copy of the wdb and gets |
| 06:48.06 | CIA-62 | BRL-CAD: treated as another dbi observer. this requires more extensive testing for |
| 06:49.26 | brlcad | starseeker: that should fix it, but it definitely needs more testing (particularly memory testing) ... the open/close code is a royal mess, so it really warrants a valgrinding |
| 06:59.22 | CIA-62 | BRL-CAD: 03brlcad * r45295 10/brlcad/trunk/src/libged/analyze.c: reorder in order to eliminate forward references and disambiguate private functions from public API by not using ged_ prefix. |
| 07:06.50 | CIA-62 | BRL-CAD: 03brlcad * r45296 10/brlcad/trunk/src/libged/ (dg_obj.c vdraw.c wdb_vdraw.c): reorder and rename in order to remove the ged_ prefix on non-API functions. disambiguate with the tcl-based vdraw_cmd(), renaming to vdraw_cmd_tcl(). |
| 07:21.13 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 10:52.19 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 11:32.53 | starseeker | brlcad: so should we hold off on the release for now? |
| 11:33.08 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 11:36.10 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 12:08.53 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:28.10 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 13:02.30 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:28.35 | kunigami | <PROTECTED> |
| 13:30.31 | kunigami | I've been reading refract.c but |
| 13:31.04 | kunigami | I couldn't notice any difference, except that it changes the hit callback. |
| 13:34.50 | kunigami | In osl_rt, first I detect the ray is a refraction one (which occurs when the next ray to be shot and the normal vector -- which I assume is pointing outwards -- have dot product less than zero). After shooting this new ray, I invert the normal given by the application. |
| 13:35.55 | brlcad | starseeker: I wouldn't think so, if we pass all release testing -- just have to make sure everything really works with actual hands-on modeling |
| 13:37.06 | brlcad | kunigami: if you're inside an object, you won't get a hit until you encounter another object exterior |
| 13:37.19 | brlcad | i believe you'll want to back the ray out of anything that you're in |
| 13:37.55 | brlcad | at least for onehit |
| 13:38.19 | starseeker | /src/libged/draw.c |
| 13:38.20 | starseeker | {standard input}:13976:non-relocatable subtraction expression, "_dgo_open_tcl" minus "L00000000002$pb" |
| 13:39.38 | brlcad | unclean build? that was just a function that was renamed from dgo_open to dgo_open_tcl |
| 13:40.28 | brlcad | not used in draw.c, so a lil mystery there |
| 13:41.41 | kunigami | brlcad: I'm not sure if I understand what you said. When a ray hits a glass object, I need to shoot a refraction ray. This ray will hit this same glass object from inside. I think I need to pass this "internal" ray to OSL system. |
| 13:42.12 | starseeker | ah, OK |
| 13:42.19 | starseeker | mutters under his breath about autotools... |
| 13:44.21 | CIA-62 | BRL-CAD: 03brlcad * r45297 10/brlcad/trunk/src/libged/draw.c: remove the dgo references in here since this file no longer has anything to do with the dgo interface. |
| 13:45.59 | brlcad | kunigami: so in that case, your incoming ray hits glass, you determine that you need to refract, so you don't need to "rehit" that glass surface (so you don't need to back the ray out) -- you just fire from the interior |
| 13:46.23 | brlcad | you may need to move the ray forward just an epsilon so that it doesn't accidentically rehit the surface due to floating point fuzz |
| 13:49.33 | CIA-62 | BRL-CAD: 03brlcad * r45298 10/brlcad/trunk/src/libged/bev.c: replace the ged_ prefix on non-public API |
| 13:52.35 | kunigami | brlcad: I didn't considered that! Let me try moving the starting point a little bit in the ray direction. |
| 13:53.35 | CIA-62 | BRL-CAD: 03starseeker * r45299 10/brlcad/trunk/src/other/libpng/CMakeLists.txt: This symlink probably shouldn't be pointing to the build directory - point it to the final installed location and see if that works... |
| 13:53.53 | CIA-62 | BRL-CAD: 03brlcad * r45300 10/brlcad/trunk/src/libged/bot_dump.c: more ged_ prefix removal on non-public API |
| 14:08.59 | *** join/#brlcad _psilva (~silvap@static-96-255-52-7.washdc.fios.verizon.net) | |
| 14:09.10 | _psilva | mornin |
| 14:09.13 | brlcad | howdy |
| 14:09.33 | _psilva | i'll try svn tonight |
| 14:11.28 | CIA-62 | BRL-CAD: 03starseeker * r45301 10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Spoke too soon - might be a problem with how BRL-CAD is setting CMAKE_LIBRARY_OUTPUT_DIRECTORY |
| 14:12.20 | CIA-62 | BRL-CAD: 03starseeker * r45302 10/brlcad/trunk/CMakeLists.txt: See whether we actually needed to specify the BRLCAD_BINARY_DIR - if we don't, this may avoid libpng's problem. |
| 14:20.00 | CIA-62 | BRL-CAD: 03starseeker * r45303 10/brlcad/trunk/CMakeLists.txt: Ah, that's right - that's what gives us the ability to duplicate the installed layout. Will need to do something else with libpng. |
| 14:25.45 | starseeker | dg_obj.c:339: warning: implicit declaration on vdraw_cmd_t |
| 14:29.12 | _psilva | i found g_var still in the distro |
| 14:29.22 | _psilva | doubt it's used by anyone |
| 14:35.33 | CIA-62 | BRL-CAD: 03brlcad * r45304 10/brlcad/trunk/src/libged/ (clip.c color.c ged_private.h): more ged_ (and _ged_) prefix removal. great example where reordering eliminates the need for forward decls and the unnecessary inclusion of the color funcs in ged_private (implying internal reuse API). |
| 14:36.04 | starseeker | brlcad: are you able to get a build of BRL-CAD right now? I can't even in non-strict mode... |
| 14:36.18 | starseeker | src/libged/vdraw.c:740: error: conflicting types for ‘vdraw_cmd’ |
| 14:36.30 | starseeker | include/dg.h:264: error: previous declaration of ‘vdraw_cmd’ was here |
| 14:39.38 | CIA-62 | BRL-CAD: 03brlcad * r45305 10/brlcad/trunk/src/libged/comb_std.c: ged_/GED_ prefix removal on non-public API |
| 14:40.07 | brlcad | starseeker: I do get a clean build, lemme see if I have uncommitted files |
| 14:41.24 | CIA-62 | BRL-CAD: 03brlcad * r45306 10/brlcad/trunk/include/dg.h: sure enough, uncommitted file. vdraw_cmd() was renamed to vdraw_cmd_tcl(). |
| 14:42.24 | brlcad | _psilva: it's not been a maintenance burden, so it's been left alone |
| 14:43.02 | brlcad | dead code tends to get left alone unless/until it incurs a maintenance cost |
| 14:44.16 | starseeker | brlcad: ah, phew - thanks |
| 14:44.26 | starseeker | (kinda makes release testing harder :-P) |
| 14:45.29 | _psilva | just saying practically it really has no use |
| 14:45.40 | _psilva | i suppose maybe as a reference for another convertor |
| 14:45.44 | _psilva | it has some value |
| 15:21.19 | brlcad | _psilva: you have the ability to make it useful ;) |
| 15:25.40 | _psilva | heh, just saying |
| 16:48.59 | *** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net) | |
| 17:25.48 | CIA-62 | BRL-CAD: 03kunigami * r45307 10/brlcad/trunk/src/liboptical/osl_rt.cpp: osl-rt can read number of samples from input |
| 17:52.03 | CIA-62 | BRL-CAD: 03starseeker * r45308 10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Try an alternative approach to the symlink issue. |
| 17:55.31 | brlcad | _psilva: just saying you're going to do it? |
| 17:58.41 | brlcad | actually, I recall looking at that converter a few months back and decided to keep it around because it might be useful as a plugin to our geometry conversion library |
| 17:58.41 | CIA-62 | BRL-CAD: 03starseeker * r45309 10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Fix up indenting. |
| 18:21.20 | CIA-62 | BRL-CAD: 03starseeker * r45310 10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Need to use the location property for the active configuration. Probably other places in BRL-CAD where I need to make this change. |
| 18:35.33 | CIA-62 | BRL-CAD: 03starseeker * r45311 10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Make sure we flush any old symlinks when re-running cmake. |
| 18:36.50 | CIA-62 | BRL-CAD: 03bhinesley * r45312 10/brlcad/trunk/src/libged/ptranslate.c: after pointer arithmetic, argv[0] doesn't point to command name |
| 18:48.27 | CIA-62 | BRL-CAD: 03starseeker * r45313 10/brlcad/trunk/src/other/libpng/CMakeLists.txt: |
| 18:48.27 | CIA-62 | BRL-CAD: Since Windows doesn't symlink, we need to do something else. Rather than run |
| 18:48.28 | CIA-62 | BRL-CAD: code on installation, just add a target to do the copy that depends on the |
| 18:48.28 | CIA-62 | BRL-CAD: library target. Can do this for the symlink if need but, but so far it doesn't |
| 18:48.28 | CIA-62 | BRL-CAD: look like we need to. Untested on Windows. |
| 18:52.07 | *** join/#brlcad merzo (~merzo@226-207-132-95.pool.ukrtel.net) | |
| 18:55.26 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r2940 10/wiki/User:Bhinesley: /* Log */ real oed command requires a keypoint |
| 19:00.50 | CIA-62 | BRL-CAD: 03starseeker * r45314 10/brlcad/trunk/CMakeLists.txt: LOCATION -> LOCATION_ |
| 19:15.05 | CIA-62 | BRL-CAD: 03starseeker * r45315 10/brlcad/trunk/CMakeLists.txt: |
| 19:15.05 | CIA-62 | BRL-CAD: Most of the time if you're compiling you want Debug build, and when you don't |
| 19:15.05 | CIA-62 | BRL-CAD: want that you're specifying Release build - it's extremely rare to really WANT |
| 19:15.05 | CIA-62 | BRL-CAD: to not have the build type set. Make the default behavior the common case. |
| 19:27.47 | ``Erik | http://www.youtube.com/watch?v=X9eriClHWLw adam savage singing "I will survive" as gollum |
| 19:34.58 | CIA-62 | BRL-CAD: 03bhinesley * r45316 10/brlcad/trunk/src/libged/translate.c: Enable support for translating all instances of a primitive. Negative coordinates no longer mistaken for arguments. |
| 19:45.22 | starseeker | bites back cuss words - CMake has it's own notion of permissions, independent of umask |
| 20:44.15 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-125-86-110.dsl.bkfd14.sbcglobal.net) | |
| 20:48.32 | starseeker | bhinesley: I'm seeing the following: |
| 20:48.34 | starseeker | ../../../src/libged/translate.c: In function 'ged_translate': |
| 20:48.34 | starseeker | ../../../src/libged/translate.c:237: error: expected ')' before 'restrict' |
| 20:48.49 | bhinesley | huh, ok |
| 20:50.45 | *** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net) | |
| 20:53.38 | CIA-62 | BRL-CAD: 03bhinesley * r45317 10/brlcad/trunk/src/libged/translate.c: restrict qualifier causing build errors |
| 20:54.06 | bhinesley | I'm rebuilding from scratch right now, so I haven't tested that, but it should get you by (possibly with a warning) |
| 21:18.57 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2941 10/wiki/ESA_Summer_of_Code_in_Space: initial description of SOCIS announcing intent to apply |
| 21:22.26 | CIA-62 | BRL-CAD: 03kunigami * r45318 10/brlcad/trunk/src/liboptical/ (7 files): changed osl-renderer to liboslrend |
| 21:30.15 | kunigami | I can't get refraction to work. In the following render, the tall box is from glass : http://dl.dropbox.com/u/1399996/GSoC/OSL_RT-2011-06-29.png |
| 21:40.09 | CIA-62 | BRL-CAD: 03r_weiss * r45319 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: |
| 21:40.09 | CIA-62 | BRL-CAD: Improved function 'nmg_bool' within file 'nmg_bool.c'. These changes will, under |
| 21:40.09 | CIA-62 | BRL-CAD: certain conditions, increase the speed in which boolean operations are performed |
| 21:40.09 | CIA-62 | BRL-CAD: on nmg structures. This will increase the speed of operations such as when using |
| 21:40.09 | CIA-62 | BRL-CAD: the mged 'facetize' or 'ev' command. |
| 21:49.56 | brlcad | kunigami1: would be a good question to pose to the mailing list, maybe see if Rossberg has some suggestions |
| 21:50.36 | brlcad | you're definitely getting some interesting effects, but reflectivity is clearly dominant |
| 22:13.16 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2942 10/wiki/ESA_Summer_of_Code_in_Space: simplify |
| 22:18.00 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2943 10/wiki/ESA_Summer_of_Code_in_Space: link proj ideas, needs customization to socis |
| 22:19.24 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Google Summer of Code/Checklist]] moved to [[Summer of Code/Checklist]]: want to reuse the checklist since ESA is running their own SoC |
| 22:24.26 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2946 10/wiki/Summer_of_Code/Checklist: generalize and specify |
| 22:25.37 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Google Summer of Code/Application Guidelines]] moved to [[Summer of Code/Application Guidelines]]: Now supports two SoC programs |
| 22:26.30 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2949 10/wiki/Summer_of_Code/Application_Guidelines: socify |
| 22:27.01 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2950 10/wiki/Summer_of_Code/Checklist: simplify category |
| 22:27.46 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Google Summer of Code/Acceptance]] moved to [[Summer of Code/Acceptance]]: now supporting two soc programs |
| 22:32.05 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2953 10/wiki/Summer_of_Code/Acceptance: generalize |
| 22:32.56 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Google Summer of Code/Expectations]] moved to [[Summer of Code/Expectations]]: now supporting two SoC programs |
| 22:37.12 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2956 10/wiki/Summer_of_Code/Expectations: generalize |
| 22:37.51 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2957 10/wiki/Summer_of_Code/Checklist: be abnoxious |
| 22:38.53 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2958 10/wiki/Summer_of_Code/Checklist: or not |
| 22:40.26 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2959 10/wiki/Google_Summer_of_Code: |
| 22:41.38 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2960 10/wiki/Google_Summer_of_Code/2011: |
| 22:59.55 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2961 10/wiki/ESA_Summer_of_Code_in_Space: generalize |
| 23:01.59 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Category:Google Summer of Code]]": content was: '[[category:Projects]]' (and the only contributor was '[[Special:Contributions/Ssd|Ssd]]') |
| 23:02.53 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2962 10/wiki/Google_Summer_of_Code/2008: |
| 23:03.26 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Google Summer of Code/Proposal Evaluation]] moved to [[Summer of Code/Proposal Evaluation]]: generalize |
| 23:05.04 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2965 10/wiki/Summer_of_Code/Proposal_Evaluation: generalify |
| 23:05.50 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2966 10/wiki/User:EBautu: cat |
| 23:06.33 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2967 10/wiki/More_Changelog: cat |
| 23:07.00 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2968 10/wiki/Google_Summer_of_Code/Flyers: |
| 23:07.27 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2969 10/wiki/Google_Summer_of_Code/2009/Project_Ideas: cat |
| 23:07.50 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2970 10/wiki/Google_Summer_of_Code/2008/Project_Ideas: cat |
| 23:08.01 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2971 10/wiki/Google_Summer_of_Code/2009: cat |
| 23:08.27 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2972 10/wiki/Google_Summer_of_Code/2009/Project_Ideas: stray . |
| 23:11.08 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2973 10/wiki/Google_Summer_of_Code/Project_Ideas: generalize |
| 23:14.19 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2974 10/wiki/ESA_Summer_of_Code_in_Space/Project_Ideas: initial stab at ideas for SOCIS, starting with the GSoC list |
| 23:59.32 | ``Erik | *grouse* I might have to play a game with highlighters and a trip to someone with a free tube tester O.o |
| 00:47.07 | *** join/#brlcad crazy_imp (~mj@a89-182-123-98.net-htp.de) | |
| 01:26.50 | *** part/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 04:15.18 | CIA-62 | BRL-CAD: 03brlcad * r45320 10/brlcad/trunk/src/libged/concat.c: reorder to remove forward decls, remove misleading ged_ prefix from static functions |
| 04:27.16 | CIA-62 | BRL-CAD: 03brlcad * r45321 10/brlcad/trunk/src/libged/draw.c: reorder to remove forward decls, remove misleading ged_ prefix from static functions |
| 04:38.02 | CIA-62 | BRL-CAD: 03brlcad * r45322 10/brlcad/trunk/src/libged/ (9 files): even more reordering to remove forward decls, remove misleading ged_ prefix from static functions |
| 05:02.36 | CIA-62 | BRL-CAD: 03bhinesley * r45323 10/brlcad/trunk/src/libged/translate.c: added support for translating 'only a particular instance' of an object (like 'oed obj1.c obj2.c/kp.s') |
| 05:05.37 | bhinesley | really feeling like I understand what needs to happen now. The rest should be muuuch faster :) |
| 05:06.10 | bhinesley | took every neuron in my central nervous system to figure it out, though |
| 05:08.19 | bhinesley | yawns |
| 05:24.32 | CIA-62 | BRL-CAD: 03bhinesley * r45324 10/brlcad/trunk/src/libged/translate.c: Enable support for 'instance only' and 'all instances' translation of primitives. The main things left to do, are: enabling support for absolute/keypoint positioning and accepting multiple object arguments. |
| 05:28.38 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r2975 10/wiki/User:Bhinesley: /* Log */ today |
| 05:29.54 | CIA-62 | BRL-CAD: 03brlcad * r45325 10/brlcad/trunk/src/libged/ (20 files): remainder of reordering to remove forward decls and removal of misleading ged_ prefix from static non-public api functions |
| 05:31.17 | brlcad | bhinesley: haha, outstanding :) |
| 05:33.17 | brlcad | you got/get how the current way oed behaves is to use the natural (aka arbitrary coded keypoint) coordinate system origin of a specified primitive as the origin to use for a keypoint? |
| 05:34.49 | bhinesley | I get what you're saying |
| 05:37.03 | bhinesley | should the 'new' way allow the user to specify any coordinate as well as any object's origin? |
| 05:37.28 | brlcad | ideally, yeah |
| 05:37.46 | bhinesley | anything else? |
| 05:40.57 | brlcad | three use cases that come to mind are an arbitrary xyz, a 'natural' origin keypoint akin to what oed does now, and a 'default' origin on an object's minimum bounding box center |
| 05:41.51 | brlcad | there isn't presently a routine to get the third one at the moment, but that's probably the ideal default |
| 05:42.28 | brlcad | for now it can just be the AABB center or stubbed into the command-line api but unimplemented |
| 05:43.00 | bhinesley | ok |
| 05:43.01 | brlcad | need some syntax to differentiate an object name refering to the natural vs centered keybpoint |
| 05:43.56 | bhinesley | could just use different switches (-n -c) |
| 05:44.06 | brlcad | sure |
| 06:44.04 | *** join/#brlcad Stattrav (~Stattrav@122.178.252.52) | |
| 06:44.04 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:28.21 | *** join/#brlcad Stattrav (~Stattrav@122.178.211.204) | |
| 07:28.21 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:46.23 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 10:54.45 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 11:09.01 | CIA-62 | BRL-CAD: 03brlcad * r45326 10/brlcad/trunk/src/libged/ged.c: yet another tweak that 'should be safe' but might not be. release the ged_gdp that we allocated during init. assume that init isn't being called on something already initialized too. |
| 11:52.08 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 12:24.23 | CIA-62 | BRL-CAD: 03brlcad * r45327 10/brlcad/trunk/ (259 files in 7 dirs): |
| 12:24.23 | CIA-62 | BRL-CAD: change ged_log an ged_result_str from being directly embedded bu_vls structs to |
| 12:24.23 | CIA-62 | BRL-CAD: being pointers. this makes the struct smaller but more importantly lets us |
| 12:24.23 | CIA-62 | BRL-CAD: manage memory and initialization more easily. sure, the pointer might now be |
| 12:24.23 | CIA-62 | BRL-CAD: null, but that'll be wrapped soon anyways (and can be validated). happens to |
| 12:24.24 | CIA-62 | BRL-CAD: save a lot of '&' typing too. ;) |
| 12:32.44 | brlcad | starseeker: do you happen to have a set of already-rendered nifty NURBS images handy? |
| 12:33.12 | brlcad | ideally showcasing relatively simple objects that would be rather complicated to implement as CSG |
| 12:33.47 | brlcad | I know there's the phone images, any others? |
| 12:35.40 | brlcad | ideally something that doesn't require release approval, looking to publish an overview of step on the wiki and mailing list really soon |
| 12:36.27 | CIA-62 | BRL-CAD: 03brlcad * r45328 10/brlcad/trunk/src/bwish/ (cadAppInit.c main.c): not calling ged_init() |
| 12:37.07 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 12:38.47 | CIA-62 | BRL-CAD: 03brlcad * r45329 10/brlcad/trunk/src/libged/ged.c: have to bu_free() the gedp itself now since ged_free() releases the internal memory (so it can still release memory for ged structs on the stack) |
| 12:58.29 | CIA-62 | BRL-CAD: 03brlcad * r45330 10/brlcad/trunk/src/libged/ged.c: |
| 12:58.29 | CIA-62 | BRL-CAD: fix compile, missed commit. don't free the gedp itself during ged_free() so we |
| 12:58.29 | CIA-62 | BRL-CAD: can still pass static struct ged entities and have their memory allocations |
| 12:58.29 | CIA-62 | BRL-CAD: released. this matches with other bu structs and their respective free |
| 12:58.29 | CIA-62 | BRL-CAD: functions (e.g. bu_vls_free()). |
| 13:00.24 | epileg | I'm using -DBRLCAD_INSTALL_DATA_DIR= and -DDDATA_DIR= to set share folder, but without success. How can I properly set it? |
| 13:00.49 | CIA-62 | BRL-CAD: 03brlcad * r45331 10/brlcad/trunk/src/shapes/ (human.c tire.c): we can now call ged_free() so we're not leaking memory (albeit during exit) |
| 13:08.49 | brlcad | is DDDATA_DIR a typo? |
| 13:09.42 | CIA-62 | BRL-CAD: 03brlcad * r45332 10/brlcad/trunk/src/ (libged/wdb_obj.c mged/mged.c mged/setup.c): plug various ged memory leakages. if we fail, reset back to null. |
| 13:10.21 | epileg | brlcad: is as starseeker typed |
| 13:11.06 | brlcad | looks like one too many D's to me |
| 13:11.52 | epileg | ok, i'll try removing a D |
| 13:15.53 | brlcad | starseeker: cmake --help-variable-list and all the other various --help-* commands seem to be somewhat useless ... can all the various BRL-CAD vars get added to a BRLCAD module? |
| 13:17.03 | brlcad | epileg: I do see that CMAKE_INSTALL_PREFIX is the equivalent of ./configure --prefix= |
| 13:18.05 | epileg | yes, i know. what 's BRLCAD_PREFIX? |
| 13:19.00 | brlcad | presumably the same thing, where do you see that? |
| 13:19.58 | epileg | I' see it with "cmake-gui" |
| 13:20.05 | brlcad | starseeker: also, INSTALL.cmake looks like it's incomplete? still has all the configure options, no itemized cmake build options |
| 13:21.52 | brlcad | epileg: ah, yeah -- the CMakeLists file says it's also the install prefix, an advanced option of some sort |
| 13:22.26 | brlcad | it's set to CMAKE_INSTALL_PREFIX, so perhaps just an internal variable |
| 13:23.15 | epileg | brlcad: ok, thanks. removing a D for share folder properly worked! |
| 13:24.00 | brlcad | form is -D VAR=VAL |
| 13:24.13 | brlcad | so it was suspicious that there'd be a DDATA_DIR var |
| 13:24.20 | epileg | aha |
| 13:25.21 | brlcad | from my reading of the usage, the space is even optional so it'd probably be more clear to put the space in our docs |
| 13:25.25 | ``Erik | BRLCAD_PREFIX is something starseeker added to prevent using old installed BRL-CAD libs to link during build, should be marked as advanced |
| 13:26.06 | ``Erik | CMAKE_INSTALL_PREFIX is the one you want to use |
| 13:27.28 | epileg | Thanks brlcad ``Erik |
| 13:27.30 | CIA-62 | BRL-CAD: 03starseeker * r45333 10/brlcad/trunk/CMakeLists.txt: Readibility improvement. |
| 13:27.46 | epileg | now I only need text to properly rendering. Is there a way to do that in cmake? |
| 13:30.56 | kunigami | I made a scene consisting of a sphere with center (0,0,0) and radius 1 and shot a ray from (-10, 0, 0) with direction (1, 0, 0) |
| 13:31.51 | kunigami | when I call the first rt_shootray it returns (-1, 0, 0) as the hit point (OK). OSL code returns the direction (1, 0, 0) (OK) |
| 13:32.45 | kunigami | then I forward the hit point a little bit to (-0.9999, 0, 0) and shoot a new ray from there with direction (1, 0, 0). rt_shootray returns (-0.9999, 0, 0) as the hit point |
| 13:34.01 | kunigami | I'll send this information to the mail list as suggested. I'm probably not setting something right before calling rt_shootray the second time |
| 13:56.45 | d_rossberg | kunigami: (-0.9999, 0, 0) is OK but you are probable interested in the pt_outhit |
| 14:35.38 | starseeker | brlcad: seeing a crash: http://pastebin.mozilla.org/1261320 |
| 14:35.55 | starseeker | brlcad: urm. NURBS images... probably just the phone image handy |
| 14:36.30 | starseeker | http://bzflag.bz/~starseeker/phone_large.png |
| 14:40.59 | starseeker | let me see if I can get an openbook image rendered |
| 14:44.49 | starseeker | http://bzflag.bz/~starseeker/openbook_d2.png |
| 14:53.45 | starseeker | brlcad: um... the cmake help commands are help for cmake developers, not about a particular project |
| 14:55.16 | starseeker | INSTALL.cmake was/is a work in progress. I haven't pushed to finish it up yet |
| 14:55.58 | starseeker | I didn't figure we would be pushing the CMake build as primary until after this release, so I wasn't worried about it yet. |
| 14:59.40 | *** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) | |
| 15:00.44 | *** part/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net) | |
| 15:05.07 | brlcad | kunigami: ah, probably because you're inside an object, so it's instantly a hit. since you know you're a refraction ray, you may want to set onehit to false and skip the first partition |
| 15:05.47 | brlcad | otherwise, you have no idea how far forward you'll need to nudge forward to get past that object |
| 15:06.21 | brlcad | ah, or what d_rossberg said :) |
| 15:07.02 | kunigami | :) I'm implementing that. For a render with few samples it seems to have worked. Checking with more samples now |
| 15:07.41 | brlcad | starseeker: yeah, looking for something better than those |
| 15:07.57 | brlcad | phone_large is interesting, but isn't "nurbs-compelling" |
| 15:08.14 | brlcad | openbook_d2 is "nurbs-compelling", but just not very interesting |
| 15:08.49 | starseeker | brlcad: yeah, then I don't have anything handy |
| 15:09.17 | brlcad | evan a simple closed surface deformed to all hell wibbly wobbly would probably work, but a real object would be better |
| 15:09.19 | starseeker | sorry :-/ |
| 15:10.03 | starseeker | are you seeing that bomb issue with ged_init? |
| 15:10.28 | brlcad | looking at that now |
| 15:10.46 | brlcad | everyone should see it given that report |
| 15:11.04 | brlcad | didn't you read it? :) |
| 15:11.28 | starseeker | I did - but figured you'd probably tested the recent commits, so I thought perhaps there was another uncommitted file or some such |
| 15:13.06 | brlcad | tested, but apparently not code that exercised ged_init() |
| 15:13.52 | CIA-62 | BRL-CAD: 03brlcad * r45334 10/brlcad/trunk/src/libged/ged.c: have to allocate memory now before init can occur since they're just pointers |
| 15:19.22 | starseeker | yep, that's got it - thanks |
| 15:33.03 | *** join/#brlcad Stattrav (~Stattrav@117.192.146.37) | |
| 15:33.03 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:15.46 | starseeker | kunigami: might want to update the Makefile.am in liboptical |
| 16:16.01 | kunigami | ouch, I always forget |
| 16:17.23 | starseeker | brlcad: I doubt it's "nurbsy" enough, but here's a rendering of the bugbase model: http://bzflag.bz/~starseeker/bugbase.png |
| 16:19.42 | CIA-62 | BRL-CAD: 03kunigami * r45335 10/brlcad/trunk/src/liboptical/Makefile.am: changed osl-renderer to liboslrend in Makefile.am |
| 16:20.20 | brlcad | better, but similarly kind of bland |
| 16:21.01 | starseeker | kunigami: thanks |
| 16:30.07 | kunigami | http://dl.dropbox.com/u/1399996/GSoC/OSL_RT-2011-06-30.png |
| 16:30.31 | kunigami | The light is a bit too strong, but I think the glass is being rendered right now. |
| 16:32.23 | starseeker | kunigami: nice! |
| 16:50.14 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 16:52.21 | starseeker | brlcad: hmm - still getting complaints about leftover files from distcheck in the bench directory: http://pastebin.mozilla.org/1261343 |
| 16:53.40 | brlcad | kunigami: awesome .. curious interaction on the ground but not yet clear whether it's "right" or not |
| 16:53.44 | brlcad | definitely better though |
| 16:54.49 | brlcad | one thing I remembered to ask you about... are you running through rt or is this through that osl front-end tracer set up to shoot librt rays? |
| 16:55.42 | brlcad | reason I ask, the image looks flipped |
| 16:56.06 | kunigami | I'm running from the second one. My next step is to port is to rt so that I can try to integrate with BRL-CAD shaders |
| 17:01.38 | CIA-62 | BRL-CAD: 03brlcad * r45336 10/brlcad/trunk/bench/Makefile.am: try making these 'local' overrides since something is apparently stopping regular generated files from getting cleaned up during distcheck. |
| 17:01.40 | brlcad | yeah, getting that same output, even without any other brl-cad shaders, via rt would be good |
| 17:02.41 | brlcad | and gets closer towards answering those outstanding questions I had regarding how secondary rays are going to play with arbirary osl shaders |
| 17:06.13 | CIA-62 | BRL-CAD: 03brlcad * r45337 10/brlcad/trunk/TODO: mater command bustage?? |
| 17:28.11 | CIA-62 | BRL-CAD: 03kunigami * r45338 10/brlcad/trunk/src/liboptical/ (CMakeLists.txt Makefile.am osl_rt.cpp): added suport for refraction to osl_rt. Also added it no Makefile.am |
| 17:28.24 | kunigami | *to |
| 17:36.00 | CIA-62 | BRL-CAD: 03brlcad * r45339 10/brlcad/trunk/include/bu.h: add some assertions and protections to the bu_list insertion/dequeue macros. make them not dereference null or at least assert gracefully so we don't crash. |
| 17:39.10 | CIA-62 | BRL-CAD: 03brlcad * r45340 10/brlcad/trunk/ (NEWS src/liboptical/sh_light.c): |
| 17:39.10 | CIA-62 | BRL-CAD: encountered a crash during raytrace rendering a scene that had just one light |
| 17:39.10 | CIA-62 | BRL-CAD: with an invalid parameter specification. structparse failed causing |
| 17:39.10 | CIA-62 | BRL-CAD: light_free() to be called, which crashed on the light list (that had none added |
| 17:39.10 | CIA-62 | BRL-CAD: yet). fixed the bug on both ends, making the list dequeue safe and initializing |
| 17:39.11 | CIA-62 | BRL-CAD: the list properly. |
| 17:46.06 | *** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net) | |
| 18:14.52 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:47.49 | CIA-62 | BRL-CAD: 03kunigami * r45341 10/brlcad/trunk/src/liboptical/ (osl_rt.cpp sh_osl.cpp): rt now correctly renders reflection |
| 18:48.41 | kunigami | For refraction, I'll probably have to create a new callback in the fashion of rr_render |
| 19:04.06 | *** join/#brlcad Stattrav (~Stattrav@117.192.146.37) | |
| 19:04.06 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:41.19 | CIA-62 | BRL-CAD: 03starseeker * r45342 10/brlcad/trunk/ (NEWS TODO src/libged/mater.c): |
| 19:41.19 | CIA-62 | BRL-CAD: Fix a bug in the mater command - wasn't respecting the attribute syncing needed |
| 19:41.19 | CIA-62 | BRL-CAD: for the new system. Ultimately this should be rewritten to just act on |
| 19:41.19 | CIA-62 | BRL-CAD: attributes and not the comb structure, but that's a bit more extensive. |
| 19:44.32 | CIA-62 | BRL-CAD: 03starseeker * r45343 10/brlcad/trunk/ (NEWS TODO): Bob fixed a number of issues with rtwizard by porting it to use the new ArcherCore framework (handling unknown units, freezing on some .g files.) |
| 19:45.41 | starseeker | ``Erik: I'm assuming that osX link line TODO is the one for CMake? |
| 19:47.44 | CIA-62 | BRL-CAD: 03starseeker * r45344 10/brlcad/trunk/TODO: Move a few tasks that aren't going to be handled this go-around. |
| 19:49.51 | starseeker | brlcad: um. is "revolve typein" the MGED command line input for our revolve primitive? |
| 19:51.29 | starseeker | fires off distcheck again |
| 19:56.21 | brlcad | starseeker: i'm not sure the mater color problem was occuring before 7.20.0, only noticed it afterwards |
| 19:56.53 | brlcad | and yes, "in rev revolve ..." |
| 19:57.12 | brlcad | that avs code seems incredibly complicated for what it's doing |
| 19:59.34 | kunigami | http://dl.dropbox.com/u/1399996/GSoC/OSL_RT-Refraction-Corrected-2011-06-30.png |
| 20:00.43 | kunigami | I was using a wrong index of refraction inside BRL-CAD, so it could be calculating hitting points wrongly |
| 20:33.58 | starseeker | woot - distcheck passed on linux |
| 20:37.36 | CIA-62 | BRL-CAD: 03starseeker * r45345 10/brlcad/trunk/misc/Makefile.am: Need the Doxygen.in file in extradist |
| 20:58.11 | CIA-62 | BRL-CAD: 03bhinesley * r45346 10/brlcad/trunk/src/libged/translate.c: Clean up some logic, clarify comments |
| 21:05.11 | starseeker | ``Erik: With the inclusion of Doxygen.in, I think the CMake build is now functioning from the autotools tarball |
| 21:12.03 | brlcad | kunigami: yeah, *that* is looking much better :) |
| 21:12.20 | brlcad | did you make the light bigger? |
| 21:13.28 | kunigami | yup :P but I did not the right way. Now when I render I get way more overlap messages (just scaled both the ceiling hole and the rectangle by hand) |
| 21:15.54 | starseeker | brlcad: in rev.s revolve 0 0 0 0 0 1 0 1 0 190 test_sketch works for me |
| 21:16.14 | starseeker | was there something specific that was a concern? |
| 21:17.39 | CIA-62 | BRL-CAD: 03brlcad * r45347 10/brlcad/trunk/src/libged/mater.c: improve handling of the color arguments by properly trimming whitespace before making comparisons or parsing values. |
| 21:18.24 | CIA-62 | BRL-CAD: 03kunigami * r45348 10/brlcad/trunk/src/liboptical/sh_osl.cpp: added a callback to be called whenever a refraction ray is shoot. I'm getting some runtime errors like mis-aligned struct hit pointer. |
| 21:20.13 | CIA-62 | BRL-CAD: 03brlcad * r45349 10/brlcad/trunk/src/libged/mater.c: free the right vls |
| 21:21.40 | kunigami | Current render by rt for a mirror shader (tall box): http://dl.dropbox.com/u/1399996/GSoC/OSL_Shader_Mirror_Test_2011-06-30.png |
| 21:22.08 | kunigami | ... and for glass shader (tall box): http://dl.dropbox.com/u/1399996/GSoC/OSL_Shader_Glass_Test_2011-06-30.png |
| 21:22.50 | kunigami | wrong, by the way |
| 21:22.51 | brlcad | kunigami: avoid forward decls unless you have a cyclic loop |
| 21:23.11 | kunigami | brlcad: ok! I'll fix that |
| 21:25.47 | CIA-62 | BRL-CAD: 03starseeker * r45350 10/brlcad/trunk/TODO: revolve in seems to function. |
| 21:25.50 | CIA-62 | BRL-CAD: 03kunigami * r45351 10/brlcad/trunk/src/liboptical/sh_osl.cpp: avoiding forward decls |
| 21:26.39 | starseeker | brlcad: I'm guessing that mater bug probably does appear in 7.20.0 - it's almost certainly a consequence of the attribute/red work |
| 21:27.08 | brlcad | starseeker: nope, just a quick sanity check since the typein interface for it was changed -- maybe try that same in command interactively if it wasn't so it builds up the args |
| 21:27.28 | starseeker | brlcad: that's how I generated that command - interactively :-P |
| 21:27.33 | starseeker | didn't know the parameters |
| 21:27.38 | brlcad | k, cool |
| 21:27.45 | brlcad | good enough! |
| 21:28.23 | starseeker | I think that OSX thing is the CMake logic not sorting out multiple X11 installs on a Mac - probably don't need to swat that right now, that'll involve some fairly heavy duty mucking with FindX11.cmake |
| 21:34.46 | CIA-62 | BRL-CAD: 03starseeker * r45352 10/brlcad/trunk/TODO: Move the OSX X11 search issue, add some more notes about what will need to be done. |
| 21:37.50 | CIA-62 | BRL-CAD: 03brlcad * r45353 10/brlcad/trunk/src/libged/mater.c: remove the debug avs printing |
| 21:39.29 | brlcad | does the build automatically look in the ports dir or did the user specify an additional dyld_library_path? |
| 21:39.40 | brlcad | it shouldn't be looking in the ports dir automatically in the first place |
| 21:39.57 | brlcad | unless someone points there with flags |
| 21:41.15 | brlcad | if it's a user setting, then we can try to detect that and/or tell people to unset their paths |
| 21:41.48 | starseeker | dunno - have to look at FindX11 and what the find paths are by default on OSX |
| 21:43.50 | starseeker | it can probably be handled cleanly, but I don't have time to tackle it for this release |
| 21:44.06 | brlcad | I don't see /opt in the list (except a stray include dir) |
| 21:44.20 | starseeker | would want to include ``Erik in that discussion, since he spotted the issue first |
| 21:44.33 | brlcad | also don't see the default mac install location either, though |
| 21:44.54 | starseeker | nods - that's why I want to check ``Erik's setup in more detail |
| 21:49.50 | CIA-62 | BRL-CAD: 03brlcad * r45354 10/brlcad/trunk/misc/CMake/FindX11.cmake: look in /usr/X11/lib followed by the older convention, X11 subdirs in the system lib. |
| 21:56.24 | CIA-62 | BRL-CAD: 03brlcad * r45355 10/brlcad/trunk/src/libged/mater.c: if the avs isn't initialized before it's needed, then we don't need to free it on all the error conditions. also emphasizes the curious double-standardize... intentional? |
| 21:56.25 | CIA-62 | BRL-CAD: 03starseeker * r45356 10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Tweak the png linking mechanism a bit - test this on a few more platforms. |
| 21:57.29 | starseeker | brlcad: urm. IIRC, I think I standardized on import to make sure any changes to the color attribute would override any pre-existing color attributes... |
| 21:58.33 | starseeker | not sure if both are still needed |
| 21:58.58 | starseeker | that whole thing needs to be rewritten - it shouldn't be acting on the comb structure directly at all, except for the avs |
| 21:59.21 | starseeker | i gotta run, bbl |
| 22:13.45 | brlcad | nods |
| 22:14.53 | brlcad | curious that the old way has stopped working through -- that's not bidirectional, I'd expect the write of a db_comb_internal to sync comb to attr, then attr to comb, then write out |
| 22:16.10 | brlcad | since the comb fields are "fixed" and have flags when fields are invalid, they can be used to detect deletions and such that you don't get otherwise |
| 22:23.46 | CIA-62 | BRL-CAD: 0376.252.190.26 07http://brlcad.org * r2976 10/wiki/STEP: update/reword scl, esa/nasa sections |
| 22:35.46 | CIA-62 | BRL-CAD: 0383.85.24.171 07http://brlcad.org * r2977 10/wiki/ESA_Summer_of_Code_in_Space: |
| 22:38.04 | bhinesley | is there a standard character we should use for commands skipping coordinate arguments? |
| 22:38.05 | bhinesley | Ex: translate - - 5 sph.s ;# move sph.s up z-axis 5 units |
| 22:39.39 | bhinesley | In that case, zero would work, but there are cases zero would not suffice |
| 22:40.28 | bhinesley | Ex: translate -c - - 5 sph.s ;# move center of sph.s 5 units up z-axis |
| 22:41.07 | bhinesley | er to z=5, rather |
| 23:42.22 | CIA-62 | BRL-CAD: 03r_weiss * r45357 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: |
| 23:42.22 | CIA-62 | BRL-CAD: Updated functions 'nmg_two_face_fuse' and 'nmg_model_face_fuse' within file |
| 23:42.22 | CIA-62 | BRL-CAD: 'nmg_fuse.c'. These changes improve the fusing of coplanar faces during boolean |
| 23:42.22 | CIA-62 | BRL-CAD: operations of nmg objects. The changes can be seen on curved objects such as |
| 23:42.22 | CIA-62 | BRL-CAD: spheres which are not distorted due to improper face fusing. The changes effect |
| 23:42.23 | CIA-62 | BRL-CAD: functions such the mged 'facetize' and 'ev' commands. |
| 00:17.15 | CIA-62 | BRL-CAD: 03r_weiss * r45358 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mod.c: |
| 00:17.15 | CIA-62 | BRL-CAD: Updated function 'nmg_shell_coplanar_face_merge' within file 'nmg_mod.c'. This |
| 00:17.15 | CIA-62 | BRL-CAD: update improves the success of boolean operations on nmg objects which contain |
| 00:17.15 | CIA-62 | BRL-CAD: coplanar faces. This change effects functions such as the mged 'facetize' and |
| 00:17.15 | CIA-62 | BRL-CAD: 'ev' commands. |
| 00:27.57 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 00:46.26 | *** join/#brlcad crazy_imp (~mj@a89-182-114-102.net-htp.de) | |
| 01:01.59 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 01:57.08 | *** join/#brlcad _psilva1 (~Adium@pool-74-96-114-18.washdc.fios.verizon.net) | |
| 01:57.30 | _psilva1 | eh |
| 01:59.47 | _psilva1 | test |
| 01:59.52 | *** part/#brlcad _psilva1 (~Adium@pool-74-96-114-18.washdc.fios.verizon.net) | |
| 02:00.06 | *** join/#brlcad _psilva1 (~Adium@pool-74-96-114-18.washdc.fios.verizon.net) | |
| 02:00.17 | _psilva1 | test 2 |
| 02:01.42 | _psilva1 | anyone compile pkg-config lately? |
| 02:03.11 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 02:49.54 | ``Erik | we were doing a hard push on a release until someone did a metric fuckton of libged commits.. with any luck, we'll finish the release cycle this week with a build that is auto*, cmake and pkg friendly :/ |
| 02:55.00 | ``Erik | starseeker: you have access to the box that's causing issue, I'd not qualify it as a show stopper for the release, just a "needs to be looked into soon" issue |
| 03:31.31 | brlcad | bhinesley: probably opt for your previous suggestion, making different options -c # # # == -x # -y # -z # |
| 03:32.21 | bhinesley | alright |
| 03:33.08 | bhinesley | I have an idea to make the oed-ish commands more versatile |
| 03:33.25 | bhinesley | I'll show you later |
| 03:33.40 | brlcad | xyz or ijk |
| 03:33.41 | brlcad | ok |
| 03:34.18 | brlcad | could use xyz for points and ijk for angles or somesuch |
| 03:34.42 | brlcad | or gang them together, just a lil messier to validate |
| 03:36.20 | bhinesley | hmm so you don't like "translate 5 # 7 object2.c"? |
| 03:36.49 | bhinesley | I'm not quite following |
| 04:08.57 | brlcad | not particularly |
| 04:09.13 | brlcad | that would be introducing a new 'convention' of sorts |
| 04:09.28 | brlcad | and not one particularly obvious |
| 04:09.36 | bhinesley | yeah, I was hoping there was one |
| 04:15.10 | bhinesley | what about using the -x -y -z's as placeholders: "translate -k -x -y 5 -x -y 6 obj.c" would move obj.c from 5 to 6 on the z-axis |
| 04:16.11 | bhinesley | well not exactly... it would be equivalent to 'translate -x -y 1 obj.c' |
| 04:16.30 | brlcad | that doesn't make a whole lot of immediate sense to me either |
| 04:17.16 | bhinesley | the trouble with the way you mentioned, is that you can't tell the difference between a -x for a keypoint and a -x for a delta |
| 04:17.59 | bhinesley | there's something similar to this in AutoCAD called point filters... extremely useful and underused |
| 04:19.09 | brlcad | oh but there is, missing opts |
| 04:20.28 | brlcad | translate -a -c 1 2 3 foo ; translate -r -x 2 -y 1 foo ; foo is at 3 3 3 |
| 04:20.45 | brlcad | absolute and relative options |
| 04:21.46 | brlcad | or one could be the default so you only need the option to specify the other |
| 04:22.01 | brlcad | e.g., relative as default, then -a for absolute |
| 04:24.34 | brlcad | since all three commands need to work together and writing argv/argc parsing sucks, write out the synopsis first |
| 04:24.42 | brlcad | for tra, sca, rot |
| 04:25.10 | bhinesley | I did for my idea... I should show you now. |
| 04:25.28 | brlcad | so we don't end up with -c coordinate, -p point, -k keypoint, all meaning the same thing |
| 04:26.08 | bhinesley | Alright, keep in mind that I was thinking that using a placeholder like '-' would be okay when I wrote this: http://pastebin.mozilla.org/1261895 |
| 04:27.21 | bhinesley | formatting got a little screwed up |
| 04:29.50 | brlcad | halfway through |
| 04:30.05 | brlcad | that's actually looking pretty good |
| 04:31.50 | brlcad | still think the - is a bit screwy -- we do have a convention of using '.' with another command so that'd be the only relevant convention, but I think that explicit axis opts would provide more clarity and the '.'s would just be a shorthand for experts |
| 04:33.15 | bhinesley | that sounds good; there's one case that it may be problematic to use the -x/-y/-z with: 'translate -k -x 1 -y 2 -z 3 object' is ambiguous... but it may not be a valid command anyways |
| 04:33.28 | brlcad | another convention used is a field separator, e.g., "5/2/3" or "3,1,3" .. where you allow empty fields "/2/3" and ",,3" |
| 04:36.21 | brlcad | not a huge fan, though |
| 04:36.44 | bhinesley | I think the -x/-y/-z and '.' thing works |
| 04:36.50 | bhinesley | any ideas for alternatives to the '-' arguments for the -c/-o options? |
| 04:42.59 | bhinesley | I suppose I could allow use of '.' intended for experts as with -x/-y/-z, and everyone else just types out the path/obj again |
| 04:46.02 | bhinesley | or sets it to a TCL variable |
| 04:49.23 | epileg | starseeker: mged compiled with cmake has these more dependencies http://paste.debian.net/121565/ than the mged compiled with autotools |
| 04:50.27 | brlcad | bhinesley: avoid any interaction with tcl on the libged side of things |
| 04:50.38 | bhinesley | I meant that the user could |
| 04:50.46 | brlcad | k |
| 04:50.57 | brlcad | the goal is to make the core libs completely devoid of tcl, long term project |
| 04:51.16 | brlcad | basically undoing integration from the past 15 years :) |
| 04:51.23 | bhinesley | hehe |
| 04:53.34 | brlcad | bhinesley: I like the write up |
| 04:53.42 | brlcad | clearly put a good bit of thought into this |
| 04:53.51 | bhinesley | cool, thanks |
| 04:54.46 | bhinesley | ...thanks for taking it seriously |
| 04:54.58 | bhinesley | would have been easy to say "meh. do it my way." |
| 04:55.35 | brlcad | meh, it's not that bad ;) |
| 04:55.43 | bhinesley | hehe |
| 04:55.57 | brlcad | I think -x/-y/-z and '.' will help be more consistent |
| 04:56.55 | brlcad | except in this context... 0.0 vs 0. vs .0 vs . are all pretty similar :) |
| 04:58.26 | brlcad | something about this is bothersome: translate -k -23 4 17 9 2 1 bowl.c |
| 04:58.50 | brlcad | I think it's the slew of labeled and unlabeled numbers |
| 05:00.01 | bhinesley | could make a -d (delta) switch, that is optional/only required when -k is used |
| 05:00.25 | bhinesley | "translate -k -23 4 17 -d 9 2 1 bowl.c" |
| 05:00.49 | bhinesley | honestly, that is nothing more than a relative translation that does some math for you |
| 05:03.41 | brlcad | nods |
| 05:03.46 | brlcad | it's more important for rotate |
| 05:04.46 | brlcad | I think it gets back to an optional [-a|-r] for the TO |
| 05:05.12 | brlcad | translate -k -23 3 17 -r 9 2 1 bowl.c |
| 05:05.26 | brlcad | which is same as translate -k -23 4 17 9 2 1 bowl.c |
| 05:05.33 | bhinesley | good idea |
| 05:05.34 | brlcad | i.e., -r is optional and default |
| 05:05.42 | brlcad | but makes documenting instructions more clear |
| 05:06.17 | brlcad | and in that context -k with -a would be pointless since -a wins, but no harm to specify it |
| 05:07.35 | bhinesley | shouldn't it be "translate -k -23 3 17 -a 9 2 1 bowl.c" though, since the 9,2,1 are absolute coordinates |
| 05:07.57 | bhinesley | and then "translate -r 5 5 5 obj" == "translate 5 5 5 obj" |
| 05:09.05 | bhinesley | n/m I read your last sentence |
| 05:09.33 | *** join/#brlcad _psilvah (~prasad@pool-74-96-114-18.washdc.fios.verizon.net) | |
| 05:09.39 | _psilvah | brlcad: w00t! :D |
| 05:10.06 | brlcad | heh |
| 05:10.08 | _psilvah | finally progress |
| 05:10.25 | _psilvah | thanks btw |
| 05:12.39 | brlcad | hey, it's for a good cause if it gets you back into useful coding ;) |
| 05:12.54 | _psilvah | 3 |
| 05:13.24 | _psilvah | bench is next |
| 05:13.39 | _psilvah | tho i need to brush up on svn commands |
| 05:13.55 | _psilvah | now how do i switch to window 3.. |
| 05:13.58 | _psilvah | :( |
| 05:14.12 | brlcad | bhinesley: my understanding is => translate -k 10 10 10 -a -10 0 10 bowl.c => -10,0,10 and... |
| 05:15.16 | brlcad | translate -k 10 10 10 -r -10 0 10 bowl.c => translate -k 10 10 10 -10 0 10 bowl.c => translate -k 10 10 10 -10 . 10 bowl.c => 0,10,20 |
| 05:18.16 | bhinesley | that's the exact opposite of what I was thinking :) |
| 05:18.39 | brlcad | hah, outstanding then |
| 05:19.46 | brlcad | how does a relative translate get you to absolute coordinates from a keypoint? |
| 05:21.58 | brlcad | would be nice to combine the -c -o -k options, to simplify usage |
| 05:22.08 | brlcad | -k object makes perfect sense to me |
| 05:23.41 | brlcad | just need to know which point in object |
| 05:25.21 | bhinesley | I think I just misunderstood what you were saying... translate -k 10 10 10 -a -10 0 10 bowl.c would move you a relative -20,-10,0, right? |
| 05:25.50 | bhinesley | when I'm thinking of "-a", I'm thinking, these coordinates are absolute |
| 05:26.25 | bhinesley | may be too tired to think straight |
| 05:26.33 | brlcad | you didn't misunderstand, that's not what I wrote -- but that would make sense |
| 05:26.41 | brlcad | I was thinking -k was completely meaningless with -a |
| 05:27.21 | brlcad | with the reasoning that if you translate to an absolute position (from ANY keypoint), you end up at that position |
| 05:27.56 | bhinesley | I see |
| 05:28.16 | brlcad | I get your idea too, rather different |
| 05:29.01 | brlcad | and from a utilitarian perspective, yours probably makes more sense since mine is achieved by simply dropping the -k |
| 05:30.21 | brlcad | whereas yours you can use to calculate |
| 05:31.50 | brlcad | basically "a - k = point" giving -20,-10,0 |
| 05:31.59 | bhinesley | right |
| 05:32.26 | brlcad | and "k + r = point" for relative |
| 05:33.35 | brlcad | ? |
| 05:33.39 | bhinesley | not exactly |
| 05:34.10 | bhinesley | r does movements relative to the current position |
| 05:34.21 | bhinesley | so a -r from any keypoint is the same |
| 05:37.24 | brlcad | if bowl.c is at 100,100,100, then I believe you're saying "translate -k 10 10 10 -a -10 0 10 bowl.c" puts it at 80,90,100 (calculated a -20,-10,0 vector) |
| 05:38.23 | bhinesley | correct |
| 05:38.34 | brlcad | if bowl.c is at 100,100,100, then "translate -k 10 10 10 -r -10 0 10 bowl.c" puts it at ... |
| 05:39.21 | bhinesley | -k is ignored; it's the same as "translate -r 10 0 10 bowl.c", so bowl.c is at 110,100,110 |
| 05:40.36 | brlcad | presuming you meant 90,100,110 ;) |
| 05:40.47 | bhinesley | yes |
| 05:40.56 | bhinesley | I have these fonts really small |
| 05:41.09 | bhinesley | missed the '-' |
| 05:41.20 | brlcad | that seems to defeat the meaning of a keypoint to me |
| 05:42.03 | bhinesley | I agree, that was just my understanding |
| 05:42.10 | bhinesley | I like what you said before |
| 05:42.21 | bhinesley | it's just a bit hard to understand |
| 05:42.44 | brlcad | translate -k bowl.c -r -10 0 10 bowl.c == translate -r -10 0 10 bowl.c |
| 05:42.54 | bhinesley | -r moves us to an absolute point, which is a relative distance away from the keypoint |
| 05:44.23 | brlcad | from that approach: translate -k bowl.c == translate -k 100 100 100, so tranlsate -k 100 100 100 -r -10 0 10 bowl.c => 90,100,110 make perfect sense |
| 05:44.48 | brlcad | but then it carries that translate -k 10 10 10 -r -10 0 10 bowl.c should not be the same |
| 05:46.17 | brlcad | k + r is consistent with both |
| 05:46.55 | bhinesley | ok |
| 05:47.02 | bhinesley | sounds good |
| 05:47.02 | brlcad | with the understanding that k is implicitly the object's position unless overridden |
| 05:48.22 | brlcad | keeps in line with your nice FROM TO setup |
| 05:48.37 | brlcad | the TO is wrt the FROM, not the object |
| 05:48.52 | brlcad | unless FROM isn't specified, then it's implicitly the object |
| 05:49.20 | brlcad | lesse, does that still hold for absolute too... |
| 05:49.21 | bhinesley | nice |
| 05:55.20 | brlcad | yeah, a bit to wrap the head around at this hour |
| 05:55.27 | brlcad | newpos = oldpos + rel = keypoint + rel .. pretty clear cut |
| 05:55.31 | bhinesley | haha, exactly |
| 05:56.03 | brlcad | my original was newpos = abs .. which is simple, but not too useful |
| 05:56.23 | brlcad | you made it derive a vector, to be applied to oldpos |
| 05:58.34 | brlcad | newpos = abs - keypoint = abs - oldpos = -10,0,10 - 100,100,100 = -110,100,110 .. that doesn't seem right |
| 05:59.47 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) | |
| 05:59.47 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:59.49 | brlcad | translate -a -10 0 10 bowl.c => -10,0,10 .. basically newpos = abs |
| 06:02.24 | brlcad | translate -k 10 10 10 -a -10 0 10 bowl.c => 100,100,100 + -20,-10,0 = 80,90,100 |
| 06:03.13 | bhinesley | correct |
| 06:03.50 | brlcad | the problem is consistency: translate -k 100 100 100 -a -10 0 10 bowl.c => ??? |
| 06:04.23 | brlcad | or maybe just not seeing the formulation correctly |
| 06:05.01 | brlcad | aha! |
| 06:05.23 | brlcad | 100,100,100 + -110,-100,-90 = -10,0,10 |
| 06:06.34 | brlcad | abs is not just "abs" .. it's abs' = abs - oldpos |
| 06:07.04 | brlcad | okay, cool .. that works |
| 06:07.49 | brlcad | the only other detail in the synopsis is the whole -c -o hullabaloo |
| 06:08.43 | bhinesley | well -o can go away, as you've shown |
| 06:08.55 | bhinesley | -k obj || -k -10 0 10 |
| 06:09.02 | brlcad | nods |
| 06:11.09 | brlcad | actually it's -c that disappeared |
| 06:11.38 | brlcad | or that could |
| 06:11.51 | bhinesley | the center of a primitive is 0,0,0? |
| 06:12.02 | brlcad | at least for arbitrary non-primitive obj, their "V" position is their bounding box center |
| 06:12.11 | bhinesley | oh. |
| 06:12.12 | brlcad | I wish |
| 06:12.32 | brlcad | each primitive defines their own "natural" origin |
| 06:12.44 | brlcad | for a box, it's one of the corners |
| 06:12.56 | brlcad | for a cylinder, it's the center of the bottom disc |
| 06:13.05 | brlcad | for a torus, it's the center |
| 06:13.10 | brlcad | etc |
| 06:13.30 | brlcad | it's undefined for combinations |
| 06:13.41 | brlcad | that's why OED makes you specify a path/to/primitive |
| 06:13.48 | bhinesley | right |
| 06:14.52 | brlcad | so we can define it to be the bb center for all combination objects |
| 06:15.08 | brlcad | that makes -k obj work for any object |
| 06:15.20 | brlcad | it's just whether to use that same center even for primitives or whether to use their V |
| 06:15.36 | brlcad | as a default at least |
| 06:15.45 | brlcad | and then an option to specify the other |
| 06:16.18 | brlcad | my inclination is default to center for everything |
| 06:17.51 | brlcad | translate [-n] [-k] [object | 3dpos] [-a | -r] 3dpos object(s) |
| 06:18.50 | brlcad | where 3dpos := [-x] {#|.} [-y] {#|.} [-z] {#|.} |
| 06:18.56 | bhinesley | yeah, I'd say that defaulting to center is more useful |
| 06:19.43 | brlcad | more precisely... |
| 06:22.06 | brlcad | translate [[-n] [-k {object | [-x] {#|.} [-y] {#|.} [-z] {#|.}}]] [-a|-r] [-x] {#|.} [-y] {#|.} [-z] {#|.} object(s) |
| 06:22.09 | brlcad | :) |
| 06:22.39 | bhinesley | don't we need another object in there somewhere |
| 06:23.14 | brlcad | oh that's right, you allowed the TO to be objects as well |
| 06:23.17 | brlcad | that's new to me ;) |
| 06:23.42 | bhinesley | very nice once you get the hang of it |
| 06:24.18 | bhinesley | say you have 3 wheels on a vehicle; you can copy one in place, and easily move it into position |
| 06:24.31 | bhinesley | ignoring z-axis |
| 06:24.41 | brlcad | translate [-n] [[-k] [object|3dpos]] [[-a|-r] [object|3dpos]] object(s) |
| 06:25.12 | bhinesley | great, that actually works ok for parsing too |
| 06:26.03 | bhinesley | I was worried about "translate -k obj -a obj2 obj3 obj4 obj5 at first |
| 06:26.04 | brlcad | probably actually end up needing [-n|-c] |
| 06:26.36 | bhinesley | how so |
| 06:26.36 | brlcad | and allowing it independently on the TO and the FROM |
| 06:26.49 | bhinesley | right |
| 06:27.17 | bhinesley | translate -c -k obj -n -a obj2 obj3 obj4 obj5 |
| 06:27.28 | brlcad | or at least need to respecify -n twice |
| 06:27.40 | bhinesley | even better |
| 06:28.07 | brlcad | so that it binds to the k|a|r options |
| 06:30.20 | brlcad | translate [[-n] [-k {object|3dpos}]] [[-n] -a|-r {object|3dpos}] object(s) |
| 06:30.41 | brlcad | not exact or useful synopsis syntax in that form... |
| 06:31.50 | brlcad | either way, really nice work there .. good brainstorming |
| 06:32.19 | bhinesley | thanks; it was a pleasure working with you |
| 06:33.18 | bhinesley | I should probably ask you: is it alright if I focus on just this oed stuff for my second milestone? |
| 06:33.30 | bhinesley | I have a feeling it will not all be done + another command |
| 06:33.50 | brlcad | absolutely |
| 06:33.58 | bhinesley | right on |
| 06:34.13 | brlcad | the milestones are completely insignificant if progress like this is being made ;) |
| 06:34.23 | bhinesley | excellent |
| 06:34.52 | bhinesley | sorry it's taken me like 3 weeks to do anything significant with this. I ran out of talent. |
| 06:35.10 | brlcad | was to be expected |
| 06:35.25 | brlcad | not a simple problem or we would have done it already |
| 06:37.07 | brlcad | easier to create yet another command that does some specific subset syntax and relies on a stupid oed selection state that is based around implementation detail keypoints insignificant to the modeler |
| 06:37.31 | brlcad | that's why this consolidates about a dozen commands into just three |
| 06:38.39 | brlcad | if you can recharacterize your writeup (which should be committed, btw, even as you work on it) after our talking, I'd jump over to scale and rotate to make sure the same syntax structure will work for them and make sense |
| 06:38.57 | brlcad | with angles and distances, rotate might be especially interesting |
| 06:39.22 | brlcad | degrees, radians |
| 06:39.30 | bhinesley | nods |
| 06:39.41 | bhinesley | I have it in translate.c right now, is that alright? |
| 06:39.51 | brlcad | oh sure, I missed it there |
| 06:40.00 | bhinesley | no, not commited |
| 06:40.10 | bhinesley | (yet) |
| 06:40.14 | brlcad | ah, okay |
| 06:40.24 | brlcad | was gonna say, it's not in my copy :) |
| 06:40.43 | bhinesley | hehe you need to do a 'svn up -r brandon's' |
| 06:41.55 | brlcad | if you get the urge to convert to actual docs, they live in doc/docbook/system/mann/en/ |
| 06:42.23 | brlcad | translate.xml would get added for the manpage, docbook xml format, lots of examples to follow |
| 06:42.48 | brlcad | goes walkabout |
| 06:43.02 | bhinesley | great, I was wondering how those were generated |
| 06:52.31 | CIA-62 | BRL-CAD: 03bhinesley * r45359 10/brlcad/trunk/src/libged/translate.c: Laid out a brand spankin new syntax for translate. It is already obsolete, per irc conversation with Sean. Many ged_translate/translate things are broken, but I'm too tired to go on, so it's commented out for now. |
| 07:15.43 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) | |
| 07:15.43 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:00.54 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 08:25.20 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) | |
| 08:25.20 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:34.49 | *** part/#brlcad kunigami1 (~kunigami@loco-gw.ic.unicamp.br) | |
| 10:36.45 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 11:07.15 | CIA-62 | BRL-CAD: 03kunigami * r45360 10/brlcad/trunk/src/liboptical/ (liboslrend.h osl_rt.cpp): removing unused variables |
| 11:21.32 | kunigami | May I add an option to rt that reads the number of samples that will be made for each pixel? |
| 11:22.23 | kunigami | If yes, it's better to do it through rt script language, right? |
| 11:26.14 | kunigami | It would also be great if I could implement that kind of framebuffer that begins noisy and gains shape as more and more samples are done (but this would require to change the way rays are shot by rt) |
| 11:44.06 | starseeker | epileg: is that produced with the make package command? |
| 11:44.32 | epileg | yes, both |
| 11:45.19 | epileg | starseeker: mmmm, do You mean the binary or the shared libs list? |
| 11:50.58 | starseeker | epileg: well, basically that list looks like it's from untarring one of the tarballs (binary) built by make package |
| 11:51.23 | starseeker | which would be really annoying - I thought I had all that path stuff straightened out |
| 11:52.46 | epileg | starseeker: yes, htey are |
| 11:53.08 | starseeker | there will be a few things present in a CMake build that aren't in an autotools build, since the CMake build has some new stuff |
| 11:53.27 | starseeker | more disturbing is the /home/jordi/svn/brlcad_7.20.1-0_amd64-2/usr/brlcad/bin path |
| 11:54.15 | starseeker | I'm trying a make package here |
| 11:54.15 | epileg | starseeker: no no, forget this. I just created two deb packages and uncompress them |
| 11:54.23 | starseeker | Oh! |
| 11:54.37 | starseeker | the CMake package build for debs is completely untested |
| 11:54.42 | epileg | one with autotools and another with cmake |
| 11:55.13 | starseeker | well, for one thing the CMake build turns on OpenGL by default, while the autotools still has it off by default |
| 11:55.22 | epileg | well, I have done the autotools deb packages script |
| 11:55.25 | starseeker | that's probably where the libGLU is coming from |
| 11:55.56 | epileg | aha |
| 11:56.08 | starseeker | epileg: I need to look over the logic you've done for that and make sure the CMake build incorporates what is needed to reproduce it |
| 11:56.22 | epileg | ok |
| 11:56.27 | starseeker | I can't test deb except on a virtual machine though, so I'm not set up for it yet |
| 11:56.37 | epileg | I'll give You exactly what I've done |
| 11:57.02 | starseeker | for the tcl/tk stuff... at a glance it looks like the CMake build had enabled all local libs and the autotools build didn't |
| 11:57.41 | starseeker | libpoints is just how CMake is building the MGED points logic, so that's not surprising |
| 11:57.43 | epileg | but there are more libs in autotools packages than in cmake one |
| 11:58.09 | starseeker | wait - is the list I'm looking at autotools things that hte CMake build Doesn't have? |
| 11:58.40 | epileg | ok |
| 11:59.13 | epileg | about testing, don't worry, I've ready many virtual machines to test them |
| 12:00.20 | starseeker | bhinesley: getting this error: src/libged/translate.c:49: error: ‘translate’ defined but not used |
| 12:01.28 | starseeker | no worries, but may want to #if it out in the repository until you progress to the point where it's used by something |
| 12:02.00 | epileg | starseeker: in the autotools package, there are 747 elements, 69,9 MB, and in cmake package 671 elements, 46,3 MB |
| 12:02.13 | starseeker | erm. |
| 12:02.14 | epileg | in lib folder |
| 12:03.26 | epileg | in came i used: |
| 12:03.26 | epileg | cmake -DBRLCAD-ENABLE_OPTIMIZED_BUILD=ON \ |
| 12:03.26 | epileg | -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON \ |
| 12:03.26 | epileg | -DBRLCAD-ENABLE_STRICT=OFF \ |
| 12:03.26 | epileg | -DCMAKE_BUILD_TYPE=Release \ |
| 12:03.27 | epileg | -DCMAKE_INSTALL_PREFIX=/usr/brlcad \ |
| 12:03.27 | epileg | -DDATA_DIR=share \ |
| 12:03.28 | epileg | -DMAN_DIR=share/man |
| 12:04.04 | epileg | cmake* |
| 12:05.15 | starseeker | ok |
| 12:05.49 | starseeker | epileg: for each of the two package directories (autotools and cmake) can you do the following? |
| 12:06.12 | epileg | and in autotools: |
| 12:06.12 | epileg | ./configure --enable-optimized --enable-almost-everything --with-ogl --disable-debug -disable-strict -prefix=/usr/brlcad |
| 12:06.25 | epileg | yes, tell me |
| 12:06.28 | starseeker | find . -type f |grep -v .svn|xargs stat --format='%n' > autotools.list |
| 12:06.34 | starseeker | find . -type f |grep -v .svn|xargs stat --format='%n%s' > autotools_size.list |
| 12:06.40 | starseeker | and the same for cmake |
| 12:06.46 | epileg | ok |
| 12:06.59 | starseeker | those four files will provide a way to compare what is ending up in the two package dirs |
| 12:07.11 | epileg | in the root package folder, right? |
| 12:07.15 | starseeker | yes |
| 12:07.21 | epileg | just a secont |
| 12:11.21 | epileg | starseeker: some email to send or paste on a web page? |
| 12:13.24 | starseeker | http://paste.debian.net should work |
| 12:13.29 | epileg | ok |
| 12:14.24 | epileg | ...Length of code is not allowed to exceed 90kb... |
| 12:14.30 | starseeker | phooey |
| 12:14.45 | starseeker | i'll pm you an email addy |
| 12:17.51 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 12:35.35 | epileg | starseeker: did You receive it? |
| 12:37.44 | epileg | starseeker: just one thing. as You can see, at the end of cmake.list and cmake_size.list, there is ./autotools_size.list and ./autotools.list instead of the cmake... filenames |
| 12:38.15 | epileg | this is because i've changed the filenames after run the command, sorry |
| 12:52.51 | starseeker | epileg: I'll check in a bit - dealing with multiple things at the moment |
| 12:52.59 | starseeker | (shredder broke, vacuum broke...) |
| 12:53.05 | epileg | ok, no problem |
| 12:53.31 | starseeker | np - I can spot the autotools.list filesw |
| 12:58.58 | CIA-62 | BRL-CAD: 03kunigami * r45361 10/brlcad/trunk/src/liboptical/ (osl_rt.cpp sh_osl.cpp): Still having problems rendering glass material. I've tried even calling OSL QueryColor directly (without mfuncs), but still no success |
| 14:10.52 | brlcad | kunigami: rt has a -H hypersample option already |
| 14:41.09 | brlcad | that used in conjunction with -s oversizing then downsampling are a common best-practice for producing smoothly anti-aliased images |
| 14:42.01 | brlcad | on that same note, there is a -j jitter flag that will modify the starting ray hit point in various ways depending on the jitter value |
| 15:05.39 | CIA-62 | BRL-CAD: 03starseeker * r45362 10/brlcad/trunk/doc/html/CMakeLists.txt: fix target directory for animmate |
| 15:09.14 | CIA-62 | BRL-CAD: 03starseeker * r45363 10/brlcad/trunk/src/util/CMakeLists.txt: pc_test isn't supposed to be installed. |
| 15:12.19 | starseeker | epileg: the CMake zlib build isn't installing the private zlib headers, while the autotools build is - unless we need to install them, I'm inclined to go with the CMake behavior |
| 15:13.14 | starseeker | epileg: the CMake build won't have the .la files that the autotools build has - that's expected |
| 15:13.41 | starseeker | some differences with library naming for itcl/itk, looks like... that shouldn't matter |
| 15:15.01 | epileg | starseeker: I'll be agree with any decision You take |
| 15:15.27 | starseeker | tcl/tkConfig.sh scripts aren't there yet for the CMake build of Tcl/Tk |
| 15:15.41 | starseeker | epileg: do the packages generated actually work when installed? |
| 15:15.55 | epileg | yes |
| 15:16.40 | epileg | just the rtwizard do not properly render, both cmake and autotools builds |
| 15:17.29 | starseeker | what's the issue with rtwizard? |
| 15:17.50 | starseeker | epileg: hmm, looks like I haven't gotten around to doing the man pages for iwidgets yet... |
| 15:19.07 | epileg | starseeker: do You remember the difference between cmake and autotools about text rendering? it's still there |
| 15:20.36 | epileg | error message from rtwizard |
| 15:20.39 | epileg | http://paste.debian.net/121606/ |
| 15:22.06 | starseeker | oh, I see - autotools build prefixed all of hte man pages before installing them |
| 15:22.35 | starseeker | epileg: is rt in your path? |
| 15:23.03 | epileg | nop |
| 15:23.33 | epileg | but rt is not provided by brlcad? |
| 15:26.31 | epileg | sorry, something wrong in my system |
| 15:32.33 | CIA-62 | BRL-CAD: 03starseeker * r45364 10/brlcad/trunk/src/other/iwidgets/ (CMakeLists.txt doc/CMakeLists.txt): Take care of iwidgets man pages. |
| 15:33.02 | starseeker | other major difference I see is CMake is installing Tcl/Tk man pages, where it looks like autotools isn't |
| 15:33.15 | epileg | aha |
| 15:34.34 | starseeker | somewhat surprisingly, autotools didn't build step-g? |
| 15:43.41 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 15:44.21 | epileg | starseeker: so sorry, rtwizard properly works. It was a problem on my environment variables |
| 15:45.13 | starseeker | np |
| 15:45.29 | starseeker | just glad it wasn't busted yet again :-P |
| 15:46.06 | epileg | :-) |
| 16:42.38 | *** join/#brlcad Elrohir (~kvirc@pD95EDF28.dip.t-dialin.net) | |
| 17:00.40 | CIA-62 | BRL-CAD: 03bhinesley * r45365 10/brlcad/trunk/src/libged/translate.c: don't leave private translate function definition enabled if it's not used |
| 17:00.42 | bhinesley | starseeker: hah, yeah, I was lying in bed last night thinking "really should have just commented out that whole private function" |
| 17:17.28 | bhinesley | heh *laying |
| 18:37.22 | brlcad | prefixed the man pages? |
| 18:38.53 | *** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 being tagged today (20110701) || BRL-CAD has applied to participate in the ESA Summer of Code in Space! | |
| 18:42.36 | CIA-62 | BRL-CAD: 03brlcad * r45366 10/brlcad/trunk/bench/Makefile.am: try without defining DISTCLEANFILES |
| 18:42.54 | brlcad | I see why the distcheck was still failing, missed committing a file a few days ago |
| 18:44.57 | CIA-62 | BRL-CAD: 03starseeker * r45367 10/brlcad/trunk/src/other/iwidgets/doc/Makefile.am: Add CMakeLists.txt file. |
| 18:59.50 | CIA-62 | BRL-CAD: 03kunigami * r45368 10/brlcad/trunk/src/liboptical/sh_osl.cpp: |
| 18:59.50 | CIA-62 | BRL-CAD: solved the glass shader. the problem was that the next application was set by |
| 18:59.50 | CIA-62 | BRL-CAD: next.a_hit = prev.a_hit, but if prev.a_hit was the refraction callback, |
| 18:59.50 | CIA-62 | BRL-CAD: next.a_hit would be also refraction. the expected behavior is to set mext.a_hit |
| 18:59.50 | CIA-62 | BRL-CAD: as the first callback (the one that was used by the first ray |
| 19:05.17 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2978 10/wiki/User:Kunigami/GSoc2011/Reports: /* Week 6 */ Reports updated |
| 19:10.23 | CIA-62 | BRL-CAD: 03starseeker * r45369 10/brlcad/trunk/NEWS: Richard improved facetization by updating routines to merge coplanar faces. |
| 19:11.58 | CIA-62 | BRL-CAD: 03starseeker * r45370 10/brlcad/trunk/include/conf/PATCH: Bump patch version number. |
| 19:14.53 | CIA-62 | BRL-CAD: 03starseeker * r45371 10/brlcad/trunk/ChangeLog: Update ChangeLog |
| 19:23.52 | *** join/#brlcad merzo (~merzo@94-20-133-95.pool.ukrtel.net) | |
| 19:34.06 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2979 10/wiki/User:Kunigami/GSoc2011/Reports: /* Week 6 */ |
| 19:49.53 | CIA-62 | BRL-CAD: 03kunigami * r45372 10/brlcad/trunk/src/liboptical/sh_osl.cpp: instead of calling OSLQueryColor directly (with the hardcoded name glass), call mf_render. this is better because the refracted ray may not be inside a shader named glass |
| 19:52.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:04.12 | brlcad | kunigami: so lets see it! |
| 20:05.34 | brlcad | aha, http://dl.dropbox.com/u/1399996/GSoC/OSL_RT-Refraction-Corrected-2011-06-30.png |
| 20:06.34 | brlcad | kunigami: what glass parameters are you using? refraction index, specular and diffuse params, etc |
| 20:06.55 | CIA-62 | BRL-CAD: 03starseeker * r45373 10/brlcad/branches/STABLE/ (2197 files in 194 dirs): Sync STABLE to trunk r45358 |
| 20:08.49 | starseeker | woot |
| 20:10.57 | CIA-62 | BRL-CAD: 03starseeker * r45374 10/brlcad/branches/STABLE/ (17 files in 12 dirs): Sync STABLE to trunk r45373 |
| 20:11.28 | brlcad | thinks you meant trunk TO stable |
| 20:11.57 | brlcad | :) |
| 20:14.32 | starseeker | er, yeah |
| 20:14.44 | bhinesley | either way is good ;-) |
| 20:14.58 | starseeker | prepares to tag... drumroll please... |
| 20:15.34 | starseeker | double checks the release numbers this time... |
| 20:15.57 | brlcad | and mged acutally runs along with archer :) |
| 20:30.29 | starseeker | yep, they run |
| 20:30.40 | starseeker | here we go |
| 20:31.18 | CIA-62 | BRL-CAD: 03starseeker * r45375 10/brlcad/tags/rel-7-20-2/: Tag release 7.20.2 |
| 20:37.08 | kunigami | brlcad: reading the osl glass shader, it seems that the index of refraction is 1.5 |
| 20:39.14 | kunigami | I don't know the specular and diffuse parameters. would have to take a look at implementation |
| 20:40.08 | kunigami | The shader description: http://pastebin.mozilla.org/1262389 |
| 20:43.54 | kunigami | Scene with a BRLCAD shader (checkers) and a OSL shader (mirror). The way it is implemented, BRLCAD shaders will act as lights. |
| 20:43.57 | kunigami | http://dl.dropbox.com/u/1399996/GSoC/OSL-BRLCAD-Shader-Integration.png |
| 20:52.04 | brlcad | awesome starseeker |
| 20:57.14 | starseeker | tarballs up |
| 20:58.57 | CIA-62 | BRL-CAD: 03starseeker * r45376 10/brlcad/trunk/ (NEWS README include/conf/PATCH): Bump revision numbers. |
| 21:14.46 | brlcad | hm, rt inside mged is blocking |
| 21:23.58 | brlcad | here's what that scene looks like with rt: http://tinypic.com/view.php?pic=9kufk1&s=7 |
| 21:24.31 | brlcad | and as checker: http://tinypic.com/view.php?pic=i3hzjk&s=7 |
| 21:36.17 | CIA-62 | BRL-CAD: 03brlcad * r45377 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: gah, post-ta build failure! code is used unitialized. remove it... |
| 21:51.15 | CIA-62 | BRL-CAD: 03brlcad * r45378 10/brlcad/branches/STABLE/src/librt/primitives/nmg/nmg_fuse.c: merge r45377 from trunk to stable |
| 22:15.23 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2980 10/wiki/Main_Page: link to socis |
| 22:33.35 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 22:57.43 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2981 10/wiki/ESA_Summer_of_Code_in_Space/Project_Ideas: eliminate some ideas only loosely relevant to space work |
| 22:59.00 | CIA-62 | BRL-CAD: 03brlcad * r45379 10/brlcad/tags/rel-7-20-2/src/librt/primitives/nmg/nmg_fuse.c: source tarballs were posted but not announced, so merge r45377 from trunk to stable so we can regenerate them |
| 23:18.26 | starseeker | brlcad: O.o Sorry - what happened? |
| 23:20.23 | starseeker | bites back cuss words - how in the *bleep* did I get all those successful builds and then have a build failure?? |
| 23:21.16 | starseeker | the tarballs came out of a tagged distcheck build |
| 23:23.39 | starseeker | deletes source tarballs, regens |
| 23:44.14 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2982 10/wiki/ESA_Summer_of_Code_in_Space/Project_Ideas: |
| 23:46.17 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2983 10/wiki/ESA_Summer_of_Code_in_Space/Project_Ideas: reorder |
| 23:54.05 | brlcad | starseeker: did you compile optimized? |
| 23:54.14 | brlcad | optimized often enables even more warnings |
| 23:55.37 | brlcad | that's part of my compile script -- all+warn, all+opt+warn, all+32bit+warn, default+warn, default+opt+warn, .... etc etc :) |
| 23:55.55 | starseeker | hrm. No, I think I used the line in HACKING |
| 23:56.34 | brlcad | yeah, you did it right .. just slipped through |
| 23:57.11 | brlcad | release binaries aren't supposed to be optimized anyways (so they can be debugged) |
| 23:57.58 | brlcad | and some platforms don't behave well with optimized, so several reasons why it isn't in HACKING |
| 23:58.53 | brlcad | looks like my build script tests 13 build configurations testing make, make distcheck, and make test for all 13 ... :) |
| 23:59.36 | CIA-62 | BRL-CAD: 03bhinesley * r45380 10/brlcad/trunk/ (6 files in 4 dirs): |
| 23:59.36 | CIA-62 | BRL-CAD: Started rearranging things, to put translate/rotate/scale syntax handling in one |
| 23:59.36 | CIA-62 | BRL-CAD: place. Re-wrote proposed 'translate' manual per conversation with Sean. There |
| 23:59.36 | CIA-62 | BRL-CAD: were a couple more issues resolved and ideas added along the way. Next step is |
| 23:59.36 | CIA-62 | BRL-CAD: to ensure that rotate/scale will work alright with the same syntax. |
| 00:01.17 | brlcad | that's 39 compiles, 26 installs, and 26 tests |
| 00:01.44 | starseeker | Hum. Will have to tweak the CMake logic for release - I think I might be turning on optimized by default for a Release build |
| 00:01.54 | brlcad | i'm still amazed when the build fails on some 30-somethingth test .. happens rarely, but has happened a couple times |
| 00:02.18 | starseeker | Ding! the new source tarballs are done |
| 00:02.25 | brlcad | outstanding! |
| 00:02.34 | starseeker | one more time... |
| 00:02.48 | brlcad | i'll try to send out the release announcements this weekend |
| 00:02.59 | bhinesley | how do I rename a file? Doing 'svn mv 1 2' and then commiting is giving me an error |
| 00:03.05 | brlcad | what's the err? |
| 00:03.28 | bhinesley | http://pastebin.mozilla.org/1262525 |
| 00:03.28 | brlcad | and did you do more than that one command .. like mv it then edit it |
| 00:04.08 | brlcad | hm, that looks like some network hiccup |
| 00:04.12 | bhinesley | I did that at first.. but I undid the move, commited the old file, and now I'm just trying to do the move |
| 00:04.13 | brlcad | did you just try again? |
| 00:04.28 | bhinesley | I've tried several times, not just this second though |
| 00:05.21 | brlcad | are you behind a proxy or something? |
| 00:05.31 | bhinesley | nope |
| 00:05.34 | brlcad | sounds like a protocol mismatch |
| 00:06.01 | brlcad | maybe your isp put you behind a proxy without your knowledge |
| 00:06.08 | starseeker | hmm - internet too swamped locally |
| 00:06.10 | bhinesley | :-O |
| 00:06.18 | bhinesley | lets hope not |
| 00:06.45 | brlcad | is your checkout http or https? |
| 00:07.23 | bhinesley | http, it appears |
| 00:07.32 | brlcad | grep http .svn/entries |
| 00:08.03 | bhinesley | http |
| 00:08.22 | brlcad | mm.. hm |
| 00:08.57 | brlcad | well that's about all I got -- it's either something temporary that sf folks are working on and you'll just have to wait |
| 00:09.03 | brlcad | or you can try switching to https |
| 00:09.21 | bhinesley | alright |
| 00:09.31 | brlcad | find . -name entries -exec perl -pi -e 's/http:/https:/g' {} \; |
| 00:09.34 | brlcad | should do the trick |
| 00:09.46 | bhinesley | could you move libged/translate.c to libged/alter.c for me... the build is broken as is |
| 00:09.52 | brlcad | sure |
| 00:09.55 | bhinesley | thx |
| 00:10.01 | brlcad | at least .. I'll try ;) |
| 00:10.05 | bhinesley | hehe |
| 00:11.43 | CIA-62 | BRL-CAD: 03brlcad * r45381 10/brlcad/trunk/src/libged/ (alter.c translate.c): move translate.c to alter.c in order to reflect a mild restructuring. |
| 00:12.56 | brlcad | I'm always on https, so still could have been some proxy badness on isp or sf.net end or just a fluke that's already fixed |
| 00:15.37 | bhinesley | I seem to have connection problems with them from time to time |
| 00:16.07 | bhinesley | recently it's been alright... but sometimes I have to 'svn up' several times to get everything |
| 00:17.07 | bhinesley | I ran the command you gave me, so hopefully that will help |
| 00:36.53 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 00:46.49 | *** join/#brlcad crazy_imp (~mj@a89-182-108-165.net-htp.de) | |
| 02:05.37 | starseeker | ah, there we go |
| 02:05.40 | starseeker | scp to the rescue |
| 04:38.01 | starseeker | hah - http://code.google.com/p/re2 |
| 06:17.10 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) | |
| 06:17.10 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:19.10 | *** join/#brlcad yiyus (~124271242@je.je.je) | |
| 06:53.55 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 06:53.58 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:04.47 | *** join/#brlcad merzo (~merzo@94-20-133-95.pool.ukrtel.net) | |
| 07:06.10 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) | |
| 07:06.10 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:02.51 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 11:02.51 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:34.44 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) | |
| 11:34.44 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:43.21 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 12:02.50 | *** join/#brlcad kunigami_ (~kunigami@loco-gw.ic.unicamp.br) | |
| 12:11.46 | *** join/#brlcad kunigami_ (~kunigami@loco-gw.ic.unicamp.br) | |
| 12:12.49 | kunigami | Testing |
| 12:13.18 | kunigami_ | Cool :) |
| 12:40.10 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 13:02.52 | *** join/#brlcad djjara (~djjara@22.Red-79-157-206.dynamicIP.rima-tde.net) | |
| 15:51.58 | brlcad | kunigami: here's what that scene looks like with rt |
| 15:52.08 | brlcad | http://tinypic.com/view.php?pic=9kufk1&s=7 |
| 15:52.47 | brlcad | so not too shabby on the glass :) |
| 15:53.48 | brlcad | yours looks like it's also giving a reflection on the back face of the tall box, which I'm not sure is right but I think I did see that in the osl shader code you posted |
| 15:54.37 | kunigami | yeah, I had that impression too |
| 15:55.00 | brlcad | here's another -- similar to your recent image: http://tinypic.com/view.php?pic=i3hzjk&s=7 |
| 15:55.42 | brlcad | checker by itself is not very interesting, you have to use the stack shader and combine checker with phong to get curvature |
| 15:56.32 | kunigami | what do you mean by curvature? |
| 15:56.40 | brlcad | if you want to see that example, the db is at http://brlcad.org/tmp/cornell.g |
| 15:58.16 | brlcad | notice how the checker box you rendered was "flat"? |
| 15:58.48 | brlcad | this one: http://dl.dropbox.com/u/1399996/GSoC/OSL-BRLCAD-Shader-Integration.png |
| 15:59.33 | brlcad | no delineation between the top and the sides |
| 16:00.15 | brlcad | now compare that to my render, still checker but now you can "see the box" -- that's the "stack" shader |
| 16:00.16 | kunigami | hmm, understood. perfect. I'll take a look at the example |
| 16:00.52 | brlcad | stacking together checker and phong (plastic) |
| 18:36.27 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:17.22 | *** join/#brlcad Stattrav (~Stattrav@117.192.148.229) | |
| 19:17.22 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:37.36 | *** join/#brlcad Stattrav (~Stattrav@117.192.148.229) | |
| 19:37.36 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:00.54 | *** join/#brlcad Stattrav (~Stattrav@117.192.148.229) | |
| 20:00.54 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:06.43 | *** join/#brlcad genba (~genba@74.Red-81-37-61.dynamicIP.rima-tde.net) | |
| 20:07.22 | *** join/#brlcad genba (~genba@74.Red-81-37-61.dynamicIP.rima-tde.net) | |
| 20:07.54 | *** join/#brlcad genba_ (~genba@74.Red-81-37-61.dynamicIP.rima-tde.net) | |
| 20:10.25 | *** join/#brlcad genba_ (~genba@74.Red-81-37-61.dynamicIP.rima-tde.net) | |
| 20:15.34 | *** join/#brlcad genba_ (~genba@74.Red-81-37-61.dynamicIP.rima-tde.net) | |
| 20:17.46 | *** join/#brlcad Stattrav (~Stattrav@117.192.148.229) | |
| 20:17.46 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:23.51 | *** join/#brlcad genba_ (~genba@74.Red-81-37-61.dynamicIP.rima-tde.net) | |
| 20:29.38 | *** join/#brlcad genba_ (~genba@74.Red-81-37-61.dynamicIP.rima-tde.net) | |
| 20:43.15 | *** join/#brlcad genba_ (~genba@74.Red-81-37-61.dynamicIP.rima-tde.net) | |
| 20:49.42 | *** join/#brlcad genba_ (~genba@74.Red-81-37-61.dynamicIP.rima-tde.net) | |
| 20:50.34 | *** join/#brlcad Stattrav (~Stattrav@117.192.148.229) | |
| 20:50.34 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:00.39 | *** join/#brlcad Stattrav (~Stattrav@117.192.148.229) | |
| 21:00.39 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:10.02 | *** join/#brlcad Stattrav (~Stattrav@117.192.148.229) | |
| 21:10.02 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:32.10 | *** join/#brlcad Elrohir (~kvirc@p5B14BDA4.dip.t-dialin.net) | |
| 00:27.41 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 00:29.23 | kunigami | http://dl.dropbox.com/u/1399996/GSoC/OSL-BRLCAD-Shader-Integration-2.png |
| 00:30.06 | kunigami | Test with checker shader + phong (thanks to brlcad) |
| 00:47.20 | *** join/#brlcad crazy_imp (~mj@a89-182-54-210.net-htp.de) | |
| 01:18.55 | *** join/#brlcad ododo (~ododo@mna75-7-82-230-225-108.fbx.proxad.net) | |
| 01:28.44 | *** part/#brlcad ododo (~ododo@mna75-7-82-230-225-108.fbx.proxad.net) | |
| 07:42.04 | *** join/#brlcad FredGan (~Adium@broadband-109-173-13-224.nationalcablenetworks.ru) | |
| 07:42.14 | *** part/#brlcad FredGan (~Adium@broadband-109-173-13-224.nationalcablenetworks.ru) | |
| 13:39.38 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 15:07.15 | *** join/#brlcad Stattrav (~Stattrav@117.192.136.92) | |
| 15:07.15 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:31.48 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 19:55.13 | *** join/#brlcad Stattrav (~Stattrav@117.192.136.92) | |
| 19:55.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:46.18 | *** join/#brlcad Stattrav (~Stattrav@117.192.136.92) | |
| 20:46.18 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:54.34 | *** join/#brlcad Stattrav (~Stattrav@117.192.136.92) | |
| 20:54.38 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:03.46 | *** join/#brlcad Stattrav (~Stattrav@117.192.136.92) | |
| 21:03.47 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:46.46 | *** join/#brlcad Stattrav (~Stattrav@117.192.136.92) | |
| 21:46.46 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 22:02.12 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.136.92) | |
| 01:23.06 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 04:08.33 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 05:43.12 | *** join/#brlcad Stattrav (~Stattrav@117.192.148.193) | |
| 05:43.12 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:09.16 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) | |
| 07:09.16 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:26.04 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 08:23.02 | CIA-62 | BRL-CAD: 03d_rossberg * r45382 10/rt^3/tags/rel-7-20-2/: tag the C++ core interface with the corresponding BRL-CAD version (i.e. 7.20.2) |
| 08:50.48 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 09:38.27 | *** join/#brlcad merzo (~merzo@86.57.159.195) | |
| 10:36.08 | *** join/#brlcad kunigami1 (~kunigami@loco-gw.ic.unicamp.br) | |
| 11:22.27 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 11:33.31 | *** join/#brlcad kunigami_ (~kunigami@loco-gw.ic.unicamp.br) | |
| 14:29.24 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 15:11.00 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 15:35.54 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 16:14.10 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2984 10/wiki/User:Kunigami/GSoc2011/Proposal: /* Timeline */ update timeline |
| 16:14.51 | kunigami1 | Is there any other suggestion that you think I should give priority? |
| 17:32.50 | *** join/#brlcad kunigami_ (~kunigami@loco-gw.ic.unicamp.br) | |
| 19:00.59 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.173) | |
| 19:01.00 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:13.49 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.128.214) | |
| 19:19.16 | *** join/#brlcad Stattrav (~Stattrav@117.192.130.127) | |
| 19:19.16 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:02.25 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 20:05.52 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 20:19.31 | kunigami_ | sorry for asking again, but I think I've lost the conversation log for some reason. may I add an option to rt to read how many samples it will use to render osl shaders? |
| 22:13.35 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 22:26.36 | *** join/#brlcad _psilva (~silvap@static-96-255-52-7.washdc.fios.verizon.net) | |
| 22:34.43 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 23:11.59 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 02:53.18 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 04:52.54 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 04:57.43 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) | |
| 06:57.22 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:53.03 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 09:41.21 | *** join/#brlcad merzo (~merzo@86.57.159.195) | |
| 09:58.02 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 11:16.38 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 11:16.38 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 being tagged today (20110701) || BRL-CAD has applied to participate in the ESA Summer of Code in Space! | |
| 11:57.43 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:48.41 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:40.17 | *** join/#brlcad merzo (~merzo@86.57.159.195) | |
| 15:46.14 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 16:48.15 | *** join/#brlcad Stattrav (~Stattrav@117.202.24.255) | |
| 16:48.15 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:59.40 | *** join/#brlcad merzo (~merzo@86.57.159.195) | |
| 17:02.52 | *** join/#brlcad Stattrav_ (~Stattrav@117.202.19.69) | |
| 17:07.53 | *** join/#brlcad Stattrav (~Stattrav@117.192.147.232) | |
| 17:07.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:32.17 | *** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no) | |
| 18:17.27 | *** join/#brlcad Stattrav (~Stattrav@117.192.133.102) | |
| 18:17.27 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:27.44 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:28.27 | CIA-62 | BRL-CAD: 03bhinesley * r45383 10/brlcad/trunk/src/tclscripts/mged/ (man.tcl openw.tcl): Make the paramater for mged's man command optional. Fix the menu item: don't try to open "Introduction". With the new ManBrowser, it is no longer recognized as a valid argument, but is instead loaded by default. |
| 20:29.47 | bhinesley | not sure how I didn't catch that ^^ |
| 20:30.20 | bhinesley | the manual page browser works alright, but the menu item was broken |
| 20:30.46 | bhinesley | should there be a patch or anything for the release? |
| 20:31.05 | bhinesley | command line worked okay |
| 20:38.09 | *** join/#brlcad Stattrav (~Stattrav@117.192.128.251) | |
| 20:38.09 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:00.31 | *** join/#brlcad Stattrav (~Stattrav@117.192.128.251) | |
| 21:00.31 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:10.51 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:23.15 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:29.36 | CIA-62 | BRL-CAD: 03bob1961 * r45384 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Fixed the "Affected Tree/List Nodes" behavior. |
| 21:34.46 | brlcad | kunigami: response to that from earlier... |
| 21:34.46 | brlcad | kunigami: rt has a -H hypersample option already |
| 21:34.46 | brlcad | that used in conjunction with -s oversizing then downsampling are a common best-practice for producing smoothly anti-aliased images |
| 21:34.49 | brlcad | on that same note, there is a -j jitter flag that will modify the starting ray hit point in various ways depending on the jitter value |
| 21:35.18 | kunigami | great! thank you |
| 21:35.30 | brlcad | man rt has more details |
| 21:35.46 | brlcad | bhinesley: releases are past history, so generally too late to make it there |
| 21:36.48 | brlcad | the release announcement hadn't been posted yet so technically source tarballs could be reposed and the release retagged, but that's a lot of work (and starseeker's on vacation, so he won't do it) especially for a help menu option with a workaround |
| 21:37.06 | brlcad | just leave it be, note the menu fix as a NEWS line |
| 21:39.27 | brlcad | kunigami: you may also be interested in -i incremental mode, akin to jpeg incremental mode |
| 21:39.34 | bhinesley | alright |
| 21:39.50 | brlcad | as well as non-buffered output mode |
| 21:48.31 | CIA-62 | BRL-CAD: 03bhinesley * r45385 10/brlcad/trunk/src/libged/alter.c: note fix of Manual page item in help menu |
| 21:48.39 | bhinesley | dang it |
| 21:48.52 | *** join/#brlcad Stattrav (~Stattrav@117.192.128.251) | |
| 21:48.52 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:55.28 | CIA-62 | BRL-CAD: 03bhinesley * r45386 10/brlcad/trunk/src/libged/alter.c: reversing last commit (wrong file) |
| 21:56.01 | CIA-62 | BRL-CAD: 03bhinesley * r45387 10/brlcad/trunk/NEWS: note fix of Manual page item in help menu |
| 22:57.21 | *** join/#brlcad _psilva_ (~silvap@static-96-255-52-7.washdc.fios.verizon.net) | |
| 01:11.05 | CIA-62 | BRL-CAD: 03kunigami * r45388 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h sh_osl.cpp): added support to osl parameters through the sh_osl shader description. I had to implement another parser for the arguments and the syntax is poor. I'll ask in the devs lists for suggestions |
| 01:16.36 | CIA-62 | BRL-CAD: 03kunigami * r45389 10/brlcad/trunk/src/other/osl/ (9 files in 2 dirs): added a directory with osl shaders |
| 01:17.59 | CIA-62 | BRL-CAD: 03kunigami * r45390 10/brlcad/trunk/src/liboptical/liboslrend.cpp: removing unnecessary code from liboslrend |
| 01:44.32 | CIA-62 | BRL-CAD: 03kunigami * r45391 10/brlcad/trunk/src/liboptical/sh_osl.cpp: removed hypersampling from pixels of osl shaders, since rt already has an option for this (I should RTFM) |
| 03:49.07 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 04:20.09 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 05:04.33 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 08:20.00 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:05.06 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:52.10 | CIA-62 | BRL-CAD: 03bhinesley * r45392 10/brlcad/trunk/src/libged/alter.c: |
| 09:52.11 | CIA-62 | BRL-CAD: Laid out a rough draft of rotate command Manual page. It's proving to be a bit |
| 09:52.11 | CIA-62 | BRL-CAD: more complex, and require more options than translate; there are still several |
| 09:52.11 | CIA-62 | BRL-CAD: issues/inconsistencies to work out. Added optional [OFFSET_POS] argument to |
| 09:52.11 | CIA-62 | BRL-CAD: every object argument in both commands, in order to add flexibility. Removed '.' |
| 09:52.11 | CIA-62 | BRL-CAD: options to ignore specific coordinates, as it would have conflicted with |
| 09:52.12 | CIA-62 | BRL-CAD: [OFFSET_POS], and -x/-y/-z options are clearer anyways. |
| 10:46.53 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 11:05.28 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.146.209) | |
| 11:16.54 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:32.56 | *** join/#brlcad merzo (~merzo@86.57.159.195) | |
| 12:58.07 | *** join/#brlcad Stattrav_ (~Stattrav@117.202.16.93) | |
| 13:08.11 | *** join/#brlcad Stattrav (~Stattrav@117.192.129.75) | |
| 13:08.11 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:11.56 | CIA-62 | BRL-CAD: 03kunigami * r45393 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h osl_rt.cpp sh_osl.cpp): |
| 13:11.56 | CIA-62 | BRL-CAD: Instead of keeping shadername as the identifier or the shader, I now use the |
| 13:11.56 | CIA-62 | BRL-CAD: shaderstate which is the only thing required by OSLRender. This is better |
| 13:11.56 | CIA-62 | BRL-CAD: because for shader groups (shaders networks), there is not necessarily a name |
| 13:11.56 | CIA-62 | BRL-CAD: associated |
| 13:30.35 | *** join/#brlcad kunigami2 (~kunigami@loco-gw.ic.unicamp.br) | |
| 14:35.55 | *** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 14:38.02 | nsd_ | Quick question: Is BRL-CAD 7.20.2 a stable release...? It's available for download on sf.net, but it's not listed on the news page. Should I just stick with 7.18.4? |
| 14:42.25 | ``Erik | it should be stable, it's just in the process of a formal release, so the news page, announce, freshmeat update, etc. haven't been finished yet |
| 14:44.28 | nsd_ | Oh alrighty then, thanks |
| 16:16.35 | *** join/#brlcad Stattrav (~Stattrav@117.192.148.124) | |
| 16:16.35 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:27.50 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.156.87) | |
| 16:39.37 | *** join/#brlcad Stattrav (~Stattrav@117.192.133.57) | |
| 16:39.41 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:04.18 | *** join/#brlcad Stattrav (~Stattrav@117.192.133.57) | |
| 17:04.18 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:11.00 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.131.36) | |
| 18:15.08 | *** part/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 19:46.49 | CIA-62 | BRL-CAD: 03bhinesley * r45394 10/brlcad/trunk/src/libged/alter.c: Resolved all issues that I could find with "rotate". Still lacking in examples. |
| 20:30.59 | CIA-62 | BRL-CAD: 03erikgreenwald * r45395 10/brlcad/trunk/src/libgcv/bottess.c: switch to internal representation. implement some shtuff. add lots of checking. |
| 21:33.49 | CIA-62 | BRL-CAD: 03bhinesley * r45396 10/brlcad/trunk/src/libged/alter.c: Added examples of using OFFSET_DIST and X_OBJ/Y_OBJ/Z_OBJ to translate manual. Made several corrections, including in SYNOPSIS for both translate/rotate |
| 22:50.01 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 23:00.28 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r2985 10/wiki/User:Bhinesley: /* Log */ Past week, today, plan |
| 23:40.40 | CIA-62 | BRL-CAD: 03bhinesley * r45397 10/brlcad/trunk/src/libged/alter.c: several corrections, add more examples, add skeleton of scale manual page |
| 01:31.54 | CIA-62 | BRL-CAD: 03kunigami * r45398 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h sh_osl.cpp): added support to setting Color parameters |
| 01:53.03 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 02:37.02 | CIA-62 | BRL-CAD: 03kunigami * r45399 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h sh_osl.cpp): added suport to osl shaders network |
| 05:53.05 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 06:36.31 | *** join/#brlcad merzo (~merzo@86.57.159.195) | |
| 06:55.19 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) | |
| 06:55.20 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:23.50 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 11:29.49 | *** join/#brlcad merzo (~merzo@86.57.159.195) | |
| 12:19.02 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 12:30.15 | kunigami | http://dl.dropbox.com/u/1399996/GSoC/RT_OSL_checker.png |
| 12:31.51 | kunigami | I've implemented a checker shader for OSL. It can receive two other shaders as inputs for black color and white color. In the example there's a green shader and pink shader for input |
| 13:22.24 | CIA-62 | BRL-CAD: 03indianlarry * r45400 10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Fixed win32 and not cygwin side of CREATE_SYMLINK macro pointing to correct file location. |
| 13:26.38 | CIA-62 | BRL-CAD: 03indianlarry * r45401 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: Added dbl quotes around "files to copy" and destination "path name" to allow for names with spaces. |
| 13:36.44 | ``Erik | nice, kunigami! what GI algo are you using, again? |
| 13:38.10 | kunigami | this was run with rt using 500 hypersamples using OSL shaders. I *think* that OSL system implements path tracer |
| 13:38.37 | ``Erik | cool, so rt -H500 -j3 ? |
| 13:39.52 | kunigami | hmm actually I didn't set jitter, so it probably is using the default -J1. |
| 13:40.03 | kunigami | is J3 different from J1 for static images? |
| 13:40.10 | ``Erik | yes |
| 13:40.39 | kunigami | hmm, ok! let me see the result with -J3 |
| 13:40.46 | ``Erik | it's a bit flat, 1 changes the origin, 2 changes the direction, 3 does both |
| 13:45.02 | ``Erik | have any docs on how to run it with the osl stuff? I have some relatively heavy hw I can throw at it if you want |
| 13:45.43 | ``Erik | (though I'd probably just use a 16 core xeon box :) |
| 13:56.50 | kunigami | not yet :( is it better to move osl code to brlcad repository or should I just make the doc explaining how to setup osl and then link to brlcad? |
| 14:04.26 | ``Erik | the OSL stuff is basically a script to set up the osl pipeline? what's the license situation on it? |
| 14:05.10 | ``Erik | I see some in src/other/osl/ , is that the same stuff? |
| 14:18.27 | kunigami | my idea was to move osl source code to src/other/osl sometime. By now, I'm just putting there the osl shaders I've been developing |
| 14:20.45 | d_rossberg | ``Erik: is rt_bot_ifree2() only temporarily in bottess.c or should this function be declared in raytrace.h for DLL-export? |
| 14:23.19 | starseeker | did his best to answer the SCL email, but perhaps someone more plugged in this week should answer? |
| 14:25.05 | starseeker | kunigami: if you're referring to the osl library itself, I'd still say not to worry yet about including it in BRL-CAD - the full dependency chain (llvm, etc.) is nothing to sneeze at |
| 14:26.40 | kunigami | starseeker: ok. I'll try to write a small tutorial so that one can build OSL himself and link it to BRL-CAD |
| 14:30.36 | ``Erik | d_rossberg: probably temporary, let me check something really quick on my winderz box |
| 14:30.56 | ``Erik | smacks starseeker around for being on the computer when he's supposed to be visiting family O.o |
| 14:35.42 | CIA-62 | BRL-CAD: 03erikgreenwald * r45402 10/brlcad/trunk/src/libgcv/bottess.c: disable rt_bot_ifree2 on windows due to symbol export/import issues. |
| 14:38.24 | ``Erik | d_rossberg: óssok, I get a full build on msvc2005/vista32 now |
| 14:38.53 | ``Erik | s/óss// |
| 14:46.36 | d_rossberg | ``Erik: works for me too (msvc2008/xp32) :) |
| 14:58.20 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 15:31.46 | kunigami | http://dl.dropbox.com/u/1399996/GSoC/RT_OSL_checker_glass.png |
| 15:32.13 | kunigami | Just another example, using a mirror shader and a green shader to compose the checker shader |
| 15:32.29 | kunigami | I'm still rendering with the option -J3 |
| 16:26.33 | CIA-62 | BRL-CAD: 03kunigami * r45403 10/brlcad/trunk/src/other/osl/shaders/ (checker.osl gen_color.osl): updated checker shader and added a generic diffuse color shader |
| 17:01.47 | CIA-62 | BRL-CAD: 03erikgreenwald * r45404 10/brlcad/trunk/src/libgcv/bottess.c: add/rm face funcs. added some iterators. cleanup/checking. |
| 17:30.52 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2986 10/wiki/User:Kunigami/GSoc2011/OSL_Tutorial: Small tutorial do get OSL working with BRL-CAD |
| 17:31.41 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2987 10/wiki/User:Kunigami/GSoc2011/OSL_Tutorial: /* Compiling some shaders */ |
| 17:35.02 | CIA-62 | BRL-CAD: 03kunigami * r45405 10/brlcad/trunk/src/other/osl/shaders/ (blue.osl converter.osl red.osl): adding required shaders to run cornell-kunigami.g |
| 17:37.25 | CIA-62 | BRL-CAD: 03kunigami * r45406 10/brlcad/trunk/db/cornell-kunigami.g: added the scene I've been using for tests |
| 18:56.29 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2988 10/wiki/User:Kunigami: /* Links */ added link to osl tutorial |
| 19:59.30 | CIA-62 | BRL-CAD: 03bhinesley * r45407 10/brlcad/trunk/src/libged/alter.c: |
| 19:59.30 | CIA-62 | BRL-CAD: Added -d option to distinguish among the intepretations of ANGLE_TO as an |
| 19:59.30 | CIA-62 | BRL-CAD: absolute position (-a), relative distance (-r), or relative degree or radian |
| 19:59.30 | CIA-62 | BRL-CAD: offset from ANGLE_FROM (-d). Apparently this was only happening in my brain, |
| 19:59.30 | CIA-62 | BRL-CAD: before. |
| 20:53.12 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2989 10/wiki/User:Kunigami/GSoc2011/Proposal: /* Timeline */ |
| 20:59.03 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2990 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */ week 7 reports |
| 21:31.32 | CIA-62 | BRL-CAD: 03erikgreenwald * r45408 10/brlcad/trunk/src/libgcv/bottess.c: Add inverted flag to face foo. remove normal from face (superfluous, it's in the plane eq). Expand the bounding volume slightly for fp fuzz. |
| 21:39.18 | CIA-62 | BRL-CAD: 03r_weiss * r45409 10/brlcad/trunk/src/libged/erase.c: |
| 21:39.18 | CIA-62 | BRL-CAD: Fixed a bug in the mged 'rm' command. This command 'deletes all occurrences of |
| 21:39.18 | CIA-62 | BRL-CAD: the listed members from the specified combination'. A segmentation fault would |
| 21:39.18 | CIA-62 | BRL-CAD: occur when a region is displayed in 'mged' and the 'rm' command is used to |
| 21:39.18 | CIA-62 | BRL-CAD: remove a member of the displayed region and the member occurs in the region more |
| 21:39.19 | CIA-62 | BRL-CAD: than once. The changed function is 'ged_splitGDL' within the 'libged' library |
| 21:39.20 | CIA-62 | BRL-CAD: within file 'erase.c'. |
| 21:52.17 | CIA-62 | BRL-CAD: 03erikgreenwald * r45410 10/brlcad/trunk/src/libgcv/bottess.c: carry tolerance through. Start on the 2 face split. |
| 21:55.30 | CIA-62 | BRL-CAD: 03bhinesley * r45411 10/brlcad/trunk/src/libged/alter.c: |
| 21:55.30 | CIA-62 | BRL-CAD: The description of how the default ANGLE_FROM is calculated needed to be much |
| 21:55.30 | CIA-62 | BRL-CAD: more precise. It defines the y-axis of the rotation. These defaults came |
| 21:55.30 | CIA-62 | BRL-CAD: together really well (so it seems). I'll have to recheck the examples. |
| 00:04.45 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 00:30.46 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 01:11.21 | CIA-62 | BRL-CAD: 03kunigami * r45412 10/brlcad/trunk/src/other/osl/shaders/cloud.osl: adding the cloud shader |
| 01:11.46 | kunigami | http://dl.dropbox.com/u/1399996/GSoC/RT_OSL_cloud.png sample image |
| 01:55.34 | CIA-62 | BRL-CAD: 03bhinesley * r45413 10/brlcad/trunk/src/libged/alter.c: |
| 01:55.34 | CIA-62 | BRL-CAD: Added some more practical rotate examples. Added optional ANGLE_ORIGIN argument, |
| 01:55.34 | CIA-62 | BRL-CAD: to divorce rotation ANGLE from CENTER of rotation. This will allow for the use |
| 01:55.34 | CIA-62 | BRL-CAD: of any reference AXIS/ANGLE in the drawing. Several corrections. |
| 02:01.53 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r2991 10/wiki/User:Bhinesley: /* Log */ today |
| 04:12.46 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 07:06.24 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) | |
| 07:06.24 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:46.57 | CIA-62 | BRL-CAD: 03bhinesley * r45414 10/brlcad/trunk/src/libged/alter.c: fixed several errors and removed poor examples |
| 09:44.05 | *** join/#brlcad merzo (~merzo@160-35-132-95.pool.ukrtel.net) | |
| 10:10.33 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2992 10/wiki/User:Kunigami/GSoc2011/Reports: /* Week 7 */ added screenshot for cloud shader |
| 12:35.20 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 14:15.12 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 16:38.06 | CIA-62 | BRL-CAD: 03r_weiss * r45415 10/brlcad/trunk/src/libged/mater.c: Fixed bug in the mged 'mater' command where the inheritance could not be changed unless the color is changed at the same time. This change was in function 'ged_mater' within file 'mater.c' within the 'libged' library. |
| 17:12.48 | *** join/#brlcad Elrohir (~kvirc@p5B14AA52.dip.t-dialin.net) | |
| 18:29.31 | *** join/#brlcad mafm (~mafm@205.Red-88-15-70.dynamicIP.rima-tde.net) | |
| 18:46.41 | *** join/#brlcad merzo (~merzo@160-35-132-95.pool.ukrtel.net) | |
| 19:27.34 | *** join/#brlcad Stattrav (~Stattrav@14.96.30.86) | |
| 19:27.35 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 22:14.59 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 22:35.46 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 23:32.16 | *** join/#brlcad tharis20 (~tharis@bl21-47-193.dsl.telepac.pt) | |
| 01:17.22 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 02:22.53 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 02:25.52 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 03:22.43 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 04:22.58 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 04:49.15 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:30.17 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 08:56.10 | *** join/#brlcad mafm (~mafm@235.Red-193-153-198.dynamicIP.rima-tde.net) | |
| 09:16.16 | *** join/#brlcad mafm_ (~mafm@235.Red-193-153-198.dynamicIP.rima-tde.net) | |
| 09:47.42 | *** join/#brlcad merzo (~merzo@17-183-94-178.pool.ukrtel.net) | |
| 15:41.44 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 17:39.43 | *** join/#brlcad Stattrav (~Stattrav@117.192.140.74) | |
| 17:39.43 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:50.05 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:00.29 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:09.46 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:20.10 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:34.36 | *** join/#brlcad Stattrav (~Stattrav@117.192.140.74) | |
| 19:34.38 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 03:19.32 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 04:51.07 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-125-86-110.dsl.bkfd14.sbcglobal.net) | |
| 05:07.25 | *** join/#brlcad bhinesley (~bhinesley@99.125.86.110) | |
| 07:10.05 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) | |
| 07:10.05 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:05.17 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 13:55.04 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 13:57.36 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 14:02.13 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 14:04.00 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 14:08.37 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 14:13.13 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 14:18.04 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 14:22.43 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 14:27.29 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 14:32.07 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 14:34.14 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 14:38.59 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 14:43.38 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 14:45.07 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 14:49.44 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 14:54.20 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 14:59.22 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 15:03.58 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 15:08.34 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 15:10.43 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 15:15.34 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 15:20.11 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 15:24.52 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 15:29.38 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 15:34.22 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 15:37.42 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 15:42.19 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 15:46.55 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 15:51.34 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 18:50.16 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-125-86-110.dsl.bkfd14.sbcglobal.net) | |
| 18:56.20 | *** join/#brlcad Stattrav (~Stattrav@14.96.213.27) | |
| 18:56.20 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:16.08 | CIA-62 | BRL-CAD: 03brlcad * r45416 10/brlcad/trunk/src/other/step/src/express/expscan.l: |
| 19:16.09 | CIA-62 | BRL-CAD: from mpictor's commit fixing a crash from newer versions of flex, |
| 19:16.09 | CIA-62 | BRL-CAD: https://github.com/mpictor/StepClassLibrary/commit/37ac5dc82f6da91a62a39596ad0582649fce91a6; |
| 19:16.09 | CIA-62 | BRL-CAD: which is from a gentoo spim patch, which seems to have originated from a fedora |
| 19:16.09 | CIA-62 | BRL-CAD: patch. apparently yy_init was changed from meaning 'needs to be initialized' to |
| 19:16.09 | CIA-62 | BRL-CAD: 'was initialized', effectively flipping the boolean meaning. |
| 20:23.44 | *** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 21:10.05 | *** join/#brlcad mafm (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 22:53.55 | CIA-62 | BRL-CAD: 03bhinesley * r45417 10/brlcad/trunk/src/libged/alter.c: Made several corrections to existing manuals, and wrote mock manual for "scale" command. It turns out that it is closer to "rotate" than "translate"\; still much simpler, though. Needs examples to work out any issues. |
| 22:57.10 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2993 10/wiki/Astronomical_units: initial page on astronomical units |
| 23:09.06 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2994 10/wiki/Bending_light: initial writeup for bending light |
| 23:20.04 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2995 10/wiki/Celestial_mechanics_particle_system: initial celestial mechanics idea |
| 23:23.30 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2996 10/wiki/Celestial_mechanics_particle_system: refer to pnts and ell primitives |
| 23:36.31 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2997 10/wiki/Non-vacuum_gravity_simulator: initial physics engine integration idea |
| 23:56.09 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2998 10/wiki/Polarization: initial polarization article |
| 00:37.19 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r2999 10/wiki/Density_functions: initial page on material (density) objects |
| 00:37.29 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3000 10/wiki/ESA_Summer_of_Code_in_Space/Project_Ideas: link to all of the new articles |
| 00:41.24 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 00:46.03 | *** join/#brlcad bhinesley (~bhinesley@99.125.86.110) | |
| 00:55.46 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 00:55.46 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 being tagged today (20110701) || BRL-CAD has applied to participate in the ESA Summer of Code in Space! | |
| 02:09.13 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3001 10/wiki/Community_Publication_Portal: initial stub of 7.20.2 release announcement |
| 02:46.34 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3002 10/wiki/Community_Publication_Portal: /* Release 7.20.2 */ restructure |
| 03:47.28 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3003 10/wiki/Community_Publication_Portal: /* Release 7.20.2 */ expand writeup, consolidate contributors |
| 03:52.36 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3004 10/wiki/Community_Publication_Portal: /* Release 7.20.2 */ |
| 03:57.38 | CIA-62 | BRL-CAD: 03brlcad * r45418 10/brlcad/trunk/NEWS: reword the writeup for brevity/clarity |
| 04:15.18 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3005 10/wiki/Community_Publication_Portal: /* Final Editorial Review */ release 7.20.2 posted |
| 04:42.53 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 06:50.32 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 08:05.10 | CIA-62 | BRL-CAD: 03d_rossberg * r45419 10/brlcad/trunk/CMakeLists.txt: corrected comment on brlcad.dll flag |
| 08:18.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:32.40 | *** join/#brlcad poolio_ (~poolio@BZ.BZFLAG.BZ) | |
| 09:47.43 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 09:50.30 | *** join/#brlcad mafm (~mafm@12.Red-193-153-199.dynamicIP.rima-tde.net) | |
| 10:01.09 | *** join/#brlcad piksi_ (piksi@pi-xi.net) | |
| 11:31.48 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 12:46.26 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 13:57.35 | CIA-62 | BRL-CAD: 03brlcad * r45420 10/brlcad/trunk/src/liboptical/material.c: two found: labels in the same file, bad ju ju |
| 14:20.50 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 14:27.34 | d_rossberg | kunigami: could you solve the refraction issue? |
| 14:29.39 | kunigami | d_rossberg: nope. I think I'll redo the tests and attach the images in the email. Maybe they give a better idea on what's going on |
| 14:32.13 | d_rossberg | do you know now whats the difference between pt_inhit and pt_outhit? |
| 14:32.23 | CIA-62 | BRL-CAD: 03erikgreenwald * r45421 10/brlcad/trunk/src/libgcv/bottess.c: add precomputed face add to avoid fp fuzz on the plane equation |
| 14:45.10 | *** join/#brlcad silvap (~silvap@static-96-255-52-7.washdc.fios.verizon.net) | |
| 14:53.39 | kunigami | I'm not sure if I understand them correctly. As far as I understand, the outhit is the intersection of the ray as if I were refracted |
| 15:14.36 | d_rossberg | the ray-trace gives you a series of hits with solids (regions or primitives) |
| 15:15.36 | d_rossberg | a hit with a solid is the part of the ray which lies inside the solid |
| 15:16.25 | d_rossberg | and it is determi |
| 15:16.55 | d_rossberg | ... sorry, defined by the entry and exit point |
| 15:18.40 | d_rossberg | i.e. pt_inhit descibes the point where your ray enters a solid (point, distance from the rays origin normal of the solin in this point, ...) |
| 15:19.23 | d_rossberg | and pt_outhit does the same for the point where the ray leaves the solid |
| 15:20.38 | d_rossberg | normaly the light goes outside the solids, but in case of refraction you are interested in the lights way inside a solid |
| 16:34.09 | brlcad | kunigami: make sense? |
| 16:36.02 | brlcad | if you shot a ray towards a sphere, you'll get an inhit at the point where it hits, then an outhit on the other side of the sphere where it would exit |
| 16:36.34 | brlcad | remember you're dealing with solid geometry, not just surfaces, so a sphere isn't just the outer surface -- it's solid all the way through |
| 16:42.34 | brlcad | so the ray tracer gives you sets of inhit/outhit (i.e., partitions) |
| 16:43.34 | brlcad | you might want to see how our existing phong shader -- src/liboptical/sh_plastic.c -- deals with refraction and transmission, calls rr_render() from refract.c |
| 16:56.37 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 17:02.16 | kunigami | brlcad: but this outhit takes into account the index of refraction, right? |
| 17:02.50 | kunigami | I read the code in refract.c. I borrowed part of that code to implement the refraction callback of sh_osl |
| 17:04.14 | brlcad | it depends what you mean by taking it into account |
| 17:05.04 | brlcad | if you rt_shootray an application struct with index of refraction set, then NO .. it won't take it into account for *that* ray being fired |
| 17:05.31 | brlcad | inhit/outhit will always be along the ray pnt->dir being fired |
| 17:05.46 | brlcad | the index of refraction controls the next ray being fired |
| 17:10.22 | kunigami | hmm, interesting. I had the impression that changing the index of refraction did changed the way the glass looked. maybe I had changed something else |
| 17:10.28 | kunigami | I'll check again |
| 19:29.54 | *** join/#brlcad mafm_ (~mafm@12.Red-193-153-199.dynamicIP.rima-tde.net) | |
| 19:45.21 | CIA-62 | BRL-CAD: 03bhinesley * r45422 10/brlcad/trunk/src/libged/alter.c: Added a few examples to the scale manual to help work out issues. It is straightforward compared to the rotate command. These examples are probably sufficient. |
| 19:56.48 | bhinesley | brlcad: I'm starting to work on the argument handler (alter) for translate/rotate/scale. |
| 19:56.48 | bhinesley | While all 3 commands accept different arguments, the methods of grouping them are all based on the same concepts. I'm building a sort of argument handling system for alter, so that adding another command, or altering an existing one will be easy enough. What I'm implying is that you can check out the mock manuals at your leisure, and just let me know what changes you'd like. |
| 20:32.29 | *** part/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 21:49.33 | brlcad | bhinesley: okay |
| 21:49.50 | brlcad | haven't had a chance to read up in detail since you started on rotate, but will this week |
| 21:50.33 | brlcad | at a glance, would really like scale to accept simple uniform scaling via single arg |
| 21:50.39 | brlcad | like scale 2.0 foo |
| 21:51.08 | brlcad | since that's the most common use case, it should be the most brief |
| 21:51.15 | bhinesley | nods |
| 21:53.58 | bhinesley | I could make 'scale 2.0' == 'scale 2.0 2.0 2.0' while 'scale -x 2.0' performs a stretch |
| 21:56.28 | bhinesley | but then, should 'scale 2.0 3.0' == 'scale -x 2.0 -y 3.0'? This would seem weird: 'scale 2.0 3.0' == 'scale 2.0 3.0 3.0' |
| 21:58.11 | bhinesley | looks like 'sca' would do the prior |
| 22:06.45 | CIA-62 | BRL-CAD: 03bhinesley * r45423 10/brlcad/trunk/src/libged/alter.c: All 3 FACTOR_TO_POS arguments areset to its first argument, if it is the only one given. |
| 22:07.55 | CIA-62 | BRL-CAD: 03bhinesley * r45424 10/brlcad/trunk/src/libged/alter.c: accidentally removed a brace in the last commit |
| 23:31.03 | ``Erik | mebbe scale 2/2/2 ? so'z you can do 2// or whatever? |
| 23:35.56 | ``Erik | (defmethod scale-x (obj val) (* (x-of obj) val)) (defmethod scale (obj val) (scale-x obj val) (scale-y obj val) (scale-z obj val)) ... :D |
| 23:41.59 | bhinesley | ``Erik see libged/alter.c for the manuals I've cooked up so far |
| 23:43.12 | bhinesley | notably: {xyz_factor | {x y [z]}} | {[-x {x | X_OBJ}] [-y {y | Y_OBJ}] [-z {z | Z_OBJ}]} |
| 23:45.18 | bhinesley | 2// would be a stretch in the x-axis |
| 23:45.29 | bhinesley | while 2/2/2 would be a uniform scale |
| 23:47.06 | bhinesley | the slashes would actually work pretty well though, as far as trimming the size of the commands |
| 23:50.37 | bhinesley | it means we could do things like './sphere.s 1 4 5/7' rather than '-x . -y sphere.s 1 4 5 -z 7' |
| 23:51.48 | bhinesley | (which means: use the x-coordinate of each argument we're scaling, the y-coordinate of the center of sphere.s offset (1,4,5), and the z-coordinate of 7) |
| 23:53.38 | bhinesley | not that the '.' makes much sense for that particular usage of 'scale', but it is very useful for translate/rotate, which use a similar syntax |
| 23:59.08 | CIA-62 | BRL-CAD: 03bhinesley * r45425 10/brlcad/trunk/src/libged/alter.c: expand upon the definition of OFFSET_DIST, to clarify its dissimilarities from *POS arguments |
| 00:33.27 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 00:42.09 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 03:34.32 | ``Erik | the / is a relatively safe token for splitting and we use it elsewhere to denote tokens, the comma is used in some locales as a decimal point... if we ever go gettext, could cause issue |
| 03:36.59 | bhinesley | what comma are you referring to? |
| 03:37.17 | ``Erik | (but I'm no usability expert and make it a point to avoid gui work, so'z *shrug*) |
| 03:37.28 | ``Erik | (1,4,5) as a listing of coordinate |
| 03:38.04 | bhinesley | oh, I was just interpreting the syntax in human readable form |
| 03:38.09 | bhinesley | there are no commas :) |
| 03:38.26 | ``Erik | just noting that the glyph is risky :) people who haven't done internationalization can easily miss that gotcha :) |
| 03:38.37 | bhinesley | nods |
| 03:38.40 | bhinesley | thanks |
| 03:41.24 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 03:47.15 | ``Erik | (and vi, not vim?) |
| 03:52.36 | ``Erik | brlcad: dlo found issues in the solar system scale stuff when mocking up a ringworld as a pre-procdb issue, prolly fp fuzz around 1.5e14mm, so'z the claims in the au page may be a bit... optimistic :) |
| 03:54.07 | ``Erik | for the physics shtuff, my vote is for bullet, my research indicates that it started whupping ode a few years back |
| 04:01.18 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3006 10/wiki/User:Bhinesley: /* Who I am */ vim, not vi :) |
| 04:01.32 | bhinesley | ``Erik: ^ |
| 04:01.36 | bhinesley | :) |
| 04:02.27 | ``Erik | :D I'm a fbsd weenie and the 'default' editor is nvi, very different from vim |
| 04:03.07 | ``Erik | (default editor is a bsh, not bash, also confusing to linux folk) |
| 04:03.41 | bhinesley | I was a fbsd admin for a couple years, but that was a long time ago |
| 04:03.52 | bhinesley | (small company) |
| 04:04.47 | ``Erik | cool beans |
| 04:05.17 | ``Erik | which major? |
| 04:05.23 | bhinesley | computer science |
| 04:05.25 | bhinesley | BS |
| 04:05.36 | ``Erik | I meant fbsd major release number :) |
| 04:05.44 | bhinesley | oh jeez |
| 04:05.55 | ``Erik | I went fbsd with a 3, really embraced it at 4 |
| 04:06.21 | ``Erik | late 90's, yo |
| 04:07.04 | bhinesley | based on the release dates on wikipedia it must have been 5 for me |
| 04:07.38 | bhinesley | I was running 'stable' about 2004 or 2005 |
| 04:07.47 | ``Erik | brlcad.org is still running one of the 5 series |
| 04:08.36 | ``Erik | it's a good os, can be a bit tricky to maintain if you're not used to the *nix world |
| 04:09.34 | bhinesley | nods |
| 04:09.35 | bhinesley | I learned on it |
| 04:09.52 | ``Erik | <-- is a port maintainer for a couple dozen, has a few hundred pr's, friends with several core folk, good stuff :) |
| 04:10.11 | bhinesley | awesome |
| 04:10.29 | ``Erik | openbsd is nice, too, theo can be a dick, though |
| 04:10.36 | bhinesley | haha |
| 04:10.51 | bhinesley | never used it, myself |
| 04:11.25 | ``Erik | I've only used open in a vm, the X upgrade was a royal pain |
| 04:11.50 | ``Erik | dragonfly has some interesting ideas, that was a weird period |
| 04:12.40 | ``Erik | was around '02 I think, major philosophical differences on concurrency and smp |
| 04:13.10 | ``Erik | smelled like both sides weren't listening, just saying that the other side was wrong... was almost like congress *cough* O:-) |
| 04:13.32 | brlcad | ``Erik: how is "untested support for astronomical units and lots of room for there to be computational issues" being optimistic? |
| 04:13.35 | bhinesley | "they need to compromise!" |
| 04:14.54 | brlcad | bhinesley: not too worried about supporting FACTOR || X Y || X Y Z .. FACTOR || X Y Z are the two main use cases |
| 04:15.18 | ``Erik | brlcad: the statement that we can do it at a full sol system level, we have known issues at 2% of that |
| 04:15.31 | brlcad | or even FACTOR | [-x X] [-y Y] [-z Z] |
| 04:16.15 | brlcad | ``Erik: er, where do you see that statement? |
| 04:17.04 | bhinesley | alright. I won't worry about it, unless it's simpler to just include it. |
| 04:17.14 | brlcad | the only claim it makes is that objects at that scale can be created .. and then it caveats saying it's all untested and probably has issues |
| 04:17.34 | ``Erik | um, the celestial mechanics page says, srry |
| 04:18.41 | brlcad | even there, it just says you can accurately model the solar system to scale .. which is true, you just can't render that model |
| 04:19.15 | brlcad | and even then -- I don't know if simple ellipsoids at that scale would have an issue |
| 04:19.20 | ``Erik | dlo's experiment was a 30m thick strip at 1au and had display issues similar to ogl zbuffer fighting, *shrug* |
| 04:19.59 | brlcad | that's already changing the numbers involved substantially |
| 04:20.07 | brlcad | small detail at a massive scale, I'd expect a problem |
| 04:20.26 | brlcad | modeling the solar system is effectively no detail at a massive scale |
| 04:20.38 | ``Erik | yeah, he was trying to hand-build a niven ringworld, to preview the proc-db I started |
| 04:21.05 | brlcad | I don't see why a super massive sph wouldn't render just fine as an AU scale |
| 04:21.11 | brlcad | s/as/at/ |
| 04:21.39 | ``Erik | an ell should, I'd think |
| 04:21.45 | brlcad | the only issue might be the transformation it attempts to perform during raytracing so that the primitive is in a normal unitized position during eval |
| 04:21.55 | brlcad | that might bork the floating |
| 04:22.23 | brlcad | I've created a planet-sized ell before, no problems |
| 04:22.34 | brlcad | but only at the origina |
| 04:22.40 | ``Erik | it might be an op ordering issue that he was seeing, too *shrug* |
| 04:22.53 | ``Erik | planet sizes run quite a wide gambit |
| 04:23.08 | ``Erik | we have the earth sized planet with the star trek stuff in orbit, that works well |
| 04:23.24 | ``Erik | but a planet and local orbit is tiny compared to a solar system |
| 04:24.04 | brlcad | bhinesley: note that some objects can only be scaled uniformly, so there will have to be error checking if attempting to only scale 1 or 2 axes |
| 04:24.40 | bhinesley | I figured as much; such as a sphere |
| 04:26.03 | ``Erik | measuring in meters, I think a 64b ieee854 is around ~10 meter accuract at a pluto orbit (~50au), so mm would be 10km accuracy |
| 04:26.07 | brlcad | sphere is fine, they become ellipsoids |
| 04:26.20 | bhinesley | oh, hah |
| 04:26.24 | ``Erik | and that's straight measure, no math to increase inacuracy |
| 04:26.25 | brlcad | torus is the typical error case |
| 04:27.00 | ``Erik | tgc's can also be touchy, iirc |
| 04:27.22 | brlcad | ``Erik: which implies simulating our solar system to scale would be just fine .. 10km would be sub-sub-pixel |
| 04:28.37 | ``Erik | means I can't put a toy jeep on neptune, though :D |
| 04:29.28 | brlcad | heh |
| 04:30.22 | ``Erik | now my frame of reference... back in the late 90's, I was trying to make an xwing type game and was looking for ways to have a small craft be accurate anywhere in a solar system |
| 04:30.24 | brlcad | yeah, that'd be about *45M* km per pixel for a basic "overhead" render |
| 04:31.24 | brlcad | means earth is sub-pixel to scale too |
| 04:31.53 | brlcad | so you'd have to scale the bodies up several orders of magnitude, which might be neat in itself |
| 04:31.54 | ``Erik | for most displays, the only thing that MIGHT get a pixel for a solar system scale render ist he sun... |
| 04:32.41 | brlcad | yeah, sun is sub-pixel 1.39M km diameter |
| 04:33.12 | brlcad | three orders of magnitude would make them visible |
| 04:33.15 | ``Erik | but a 10,000 km 'tile' eliminates any surface detail in the outer bits |
| 04:35.36 | ``Erik | *shrug* at solar scales, we lose a lot of accuracy, 'sall :) |
| 04:36.18 | ``Erik | nerds who want to make ringworlds, dyson spheres, etc might be a bit upset when it doesn't quite work right |
| 04:37.29 | ``Erik | imma catch some z's, hasta manana :) |
| 04:38.52 | brlcad | nods |
| 04:38.55 | bhinesley | see ya |
| 04:39.10 | brlcad | the first units project aims to help fix the units issue better |
| 04:39.59 | brlcad | making sure the math is stable for existing prims, then maybe working on scaling zones |
| 04:41.21 | brlcad | bhinesley: curious choice of 'alter' for the command name |
| 04:41.35 | brlcad | any reason that over 'edit'? |
| 04:41.55 | bhinesley | nope, edit would be fine |
| 04:42.14 | bhinesley | alter just came to mind, and it's easy enough to change, so I went with it |
| 04:43.01 | brlcad | it's fine, just wondering if there was some underlying motivation |
| 04:43.15 | brlcad | both edit and alter are a little vague |
| 04:43.56 | brlcad | ambiguous even, since I can't edit/alter some object parameters |
| 04:45.31 | brlcad | those three subcommands are all transformations, so 'xform' would be pretty fitting too |
| 04:46.47 | bhinesley | whatever name it is, it will be "extern thename" in ged_private.h |
| 04:47.03 | bhinesley | and also, "extern thename_translate", etc |
| 04:47.30 | bhinesley | the idea is, thename_translate will be as primitive of a translate as possible |
| 04:48.01 | brlcad | you mean only as private api, not a new parent command? |
| 04:48.26 | bhinesley | if I understand you correctly: there will be both |
| 04:48.43 | brlcad | then what do you mean by "extern thename" in ged_private.h ? |
| 04:49.01 | brlcad | ged_private is for declaring non-public API (functions) |
| 04:49.28 | bhinesley | ged_thename will be public |
| 04:49.47 | brlcad | so then it goes in ged.h :) |
| 04:49.56 | bhinesley | correct |
| 04:50.21 | brlcad | okay, just confused by your prior statement |
| 04:50.21 | brlcad | 00:46 < bhinesley> whatever name it is, it will be "extern thename" in ged_private.h |
| 04:50.26 | bhinesley | there is a separate function, "thename", which is for calling internally without using argv |
| 04:50.52 | brlcad | ah, I think I might get what you're saying |
| 04:50.57 | bhinesley | ged_thename simply parses command line arguments and passes it to thename |
| 04:51.01 | brlcad | nods |
| 04:51.03 | brlcad | got it |
| 04:51.16 | bhinesley | yeah, excuse me... I'm not very good at expressing these things |
| 04:51.23 | bhinesley | (yet) |
| 04:52.14 | brlcad | funcs still only need to be declared extern in ged_private.h if they're going to be used by more than one file |
| 04:52.29 | brlcad | so if it all lives in alter.c, you're fine with simple function ordering |
| 04:53.37 | bhinesley | A command that needs to do a simple translate could call thename_translate. If it needed to do a batch translate using '.', or if it needed to use objects/distances to calculate coordinates, then it could call thename. |
| 04:53.52 | brlcad | it'd only be if you broke it out into alter.c, translate.c, rotate.c, scale.c with the latter three ged_[cmd]() funcs calling ged_alter() |
| 04:55.05 | bhinesley | okay, I'm a little confused. |
| 04:55.20 | brlcad | no worries, carry on :) |
| 04:55.44 | bhinesley | ged.h is for sharing with commands outside of libged, while ged_private.h is for sharing internally to libged only? |
| 04:56.01 | brlcad | almost |
| 04:56.37 | brlcad | ged.h is public declaration for use anywhere (inside/outside) |
| 04:57.06 | brlcad | ged_private.h is private declaration where there is internal reuse |
| 04:57.47 | brlcad | so funcs are added to ged.h when they're "published" but should only ged added to ged_private.h when they're actually used in more than one file |
| 04:57.55 | brlcad | even if they're ripe for reuse |
| 04:58.35 | bhinesley | okay |
| 04:58.50 | brlcad | not a big issue if they're declared in ged_private.h and not used in multiple places, but the decls might get removed/cleaned up down the road to keep files simple |
| 04:59.41 | bhinesley | sounds like ged_thename goes in ged.h for now, and eventually thename/thename_translate/etc may go in ged_private.h |
| 04:59.48 | brlcad | there are 400+ commands which means there could easily be 3x that many "private yet potentially reusable" internal funcs .. which wouldn't be too useful to browse through |
| 05:00.11 | brlcad | right, that's the intention at least |
| 05:00.58 | brlcad | my guy feeling is that any function prime for libged reuse probably doesn't even belong in libged |
| 05:01.07 | brlcad | begs refactoring down into librt |
| 05:01.33 | bhinesley | why does so much end up in librt? I thought it was just raytracing? |
| 05:01.37 | brlcad | aside from commands calling other commands at the libged API level |
| 05:01.47 | brlcad | librt isn't just raytracing |
| 05:02.00 | brlcad | it's the underlying geometry management |
| 05:02.09 | bhinesley | I mean, I have seen that... I just didn't understand the reasoning |
| 05:02.49 | brlcad | geometry representation, disk I/O, serialization, and ray tracing |
| 05:03.24 | brlcad | it would probably be more appropriately named "libg", except that the main reason for its existence is to shoot rays |
| 05:03.56 | bhinesley | alright, that makes sense |
| 05:04.15 | brlcad | and there is a very close relationship between the on-disk representation and the in-memory format used for ray-tracing |
| 05:04.44 | brlcad | the two are tightly coupled for performance reasons, why we can raytrace massive multi GB scenes in mere seconds |
| 05:04.53 | bhinesley | ahh |
| 05:05.42 | brlcad | we've talked about separating the two into different libraries, but it would be tricky to do cleanly API-wise |
| 05:05.53 | bhinesley | so, as you were saying: should uhh... 'thename' live in librt? |
| 05:06.28 | brlcad | if it's argc/argv style, then it still belongs in libged |
| 05:07.06 | bhinesley | well, only ged_thename is argc/argv style |
| 05:12.21 | brlcad | it depends what the command ends up looking like parameter-wise |
| 05:12.39 | brlcad | keep an eye on rt_matrix_transform() since that is the current closest-fit API call already in librt that comes to mind |
| 05:12.50 | brlcad | it's how mged applies most matrix edits now |
| 05:13.00 | brlcad | s/matrix/primitive/ |
| 05:13.37 | brlcad | through transformation matrices (with scaling, translation, and rotation components) |
| 05:18.20 | bhinesley | interesting |
| 08:10.00 | *** join/#brlcad mafm (~mafm@83.Red-83-54-79.dynamicIP.rima-tde.net) | |
| 08:36.36 | brlcad | calls it done for now |
| 08:38.56 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) | |
| 08:38.56 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:34.51 | CIA-62 | BRL-CAD: 03bhinesley * r45426 10/brlcad/trunk/src/libged/alter.c: Set up the struct and flags for ged_alter and alter command argument handling. Other small cleanup/setup stuff. |
| 11:18.17 | CIA-62 | BRL-CAD: 03indianlarry * r45427 10/brlcad/trunk/include/dm.h: externalize display manager interfaces |
| 13:42.28 | *** join/#brlcad mafm (~mafm@83.Red-83-54-79.dynamicIP.rima-tde.net) | |
| 13:56.33 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 16:30.28 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 17:30.54 | CIA-62 | BRL-CAD: 03starseeker * r45428 10/brlcad/trunk/CMakeLists.txt: If we don't have a defined CMAKE_SIZEOF_VOID_P, assume 32 bit to be safe. |
| 17:59.24 | CIA-62 | BRL-CAD: 03erikgreenwald * r45429 10/brlcad/trunk/CMakeLists.txt: match the endif to the if |
| 18:13.20 | CIA-62 | BRL-CAD: 03r_weiss * r45430 10/brlcad/trunk/ (6 files in 3 dirs): (log message trimmed) |
| 18:13.20 | CIA-62 | BRL-CAD: Changed function nmg_model_edge_g_fuse by renaming it to nmg_edge_g_fuse and |
| 18:13.20 | CIA-62 | BRL-CAD: allowing the magic of a nmg object to be passed in instead of a pointer to a nmg |
| 18:13.20 | CIA-62 | BRL-CAD: model structure. This change allows the function to fuse edge geometry in other |
| 18:13.20 | CIA-62 | BRL-CAD: smaller nmg objects such as an nmg shell or nmg faceuse. The following files |
| 18:13.20 | CIA-62 | BRL-CAD: were changed raytrace.h nmg_simplify.c wdb_obj.c nmg_tri.c nmg_fuse.c |
| 18:13.21 | CIA-62 | BRL-CAD: nmg_bool.c. The purpose of this change is to improve performance of nmg boolean |
| 18:38.16 | *** join/#brlcad nsd (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 18:43.31 | *** join/#brlcad nsd (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 18:44.53 | *** join/#brlcad nsd (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 19:23.54 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 19:51.40 | CIA-62 | BRL-CAD: 03r_weiss * r45431 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: |
| 19:51.40 | CIA-62 | BRL-CAD: Updated function nmg_bool within file nmg_bool.c. This change removes |
| 19:51.40 | CIA-62 | BRL-CAD: unnecessary operations to improve the speed of nmg boolean operations. This |
| 19:51.40 | CIA-62 | BRL-CAD: change will increase the speed of functions such as the mged 'ev' and 'facetize' |
| 19:51.40 | CIA-62 | BRL-CAD: commands. |
| 20:29.39 | CIA-62 | BRL-CAD: 03r_weiss * r45432 10/brlcad/trunk/ (include/raytrace.h src/librt/primitives/nmg/nmg_ck.c): |
| 20:29.39 | CIA-62 | BRL-CAD: Added a new function nmg_vsshell which validates the pointer structures within a |
| 20:29.39 | CIA-62 | BRL-CAD: single nmg shell structure and all structures within. The function nmg_vshell |
| 20:29.39 | CIA-62 | BRL-CAD: was changed to call the nmg_vsshell function. The function nmg_vshell is passed |
| 20:29.39 | CIA-62 | BRL-CAD: a list of shells to validate instead of a single shell. The purpose of this |
| 20:29.39 | CIA-62 | BRL-CAD: change is to allow a single nmg shell to be validated instead of all shells |
| 20:29.40 | CIA-62 | BRL-CAD: within an nmg model. The files raytrace.h and nmg_ck.c were changed. |
| 20:36.28 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:16.57 | CIA-62 | BRL-CAD: 03r_weiss * r45433 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 21:16.58 | CIA-62 | BRL-CAD: Updated functions nmg_triangulate_model and nmg_triangulate_shell within file |
| 21:16.58 | CIA-62 | BRL-CAD: nmg_tri.c. These changes make the operations of these functions consistent so |
| 21:16.58 | CIA-62 | BRL-CAD: that the difference is only one triangulates an nmg shell and the other |
| 21:16.58 | CIA-62 | BRL-CAD: triangulates all the nmg shells within an nmg model. |
| 21:18.31 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 21:20.56 | CIA-62 | BRL-CAD: 03bhinesley * r45434 10/brlcad/trunk/src/libged/alter.c: Added a union to store distinct command argument groupings for each command. This obsoleted some of the command-specific #define flags; I'll fix that later. Started on helper functions for building args. |
| 21:31.30 | CIA-62 | BRL-CAD: 03r_weiss * r45435 10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c: |
| 21:31.30 | CIA-62 | BRL-CAD: Fixed a bug in function class_eu_vs_s within file nmg_class.c. The mid point of |
| 21:31.30 | CIA-62 | BRL-CAD: the edge was not computed correctly. I also used points near the vertices but |
| 21:31.30 | CIA-62 | BRL-CAD: still on the edge for the fallback if the mid point can not be classified. This |
| 21:31.30 | CIA-62 | BRL-CAD: change improves the success of nmg boolean operations and can be seen when |
| 21:31.30 | CIA-62 | BRL-CAD: running, for example, the mged 'facetize' and 'ev' commands. |
| 22:14.50 | CIA-62 | BRL-CAD: 03r_weiss * r45436 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 22:14.50 | CIA-62 | BRL-CAD: Updated the prototype version of the function cut_unimonotone within file |
| 22:14.50 | CIA-62 | BRL-CAD: nmg_tri.c. This is a work in progress and this change is disabled by default. |
| 22:14.50 | CIA-62 | BRL-CAD: Some code cleanup was done and the ability to reverse the direction of loopuse |
| 22:14.50 | CIA-62 | BRL-CAD: was added to correct situations after a loop cut that the direction reverses |
| 22:14.51 | CIA-62 | BRL-CAD: i.e. is cw and should be ccw. This change supports the prototype version of the |
| 22:14.52 | CIA-62 | BRL-CAD: function nmg_triangulate_fu. |
| 22:30.37 | CIA-62 | BRL-CAD: 03brlcad * r45437 10/brlcad/trunk/src/libged/ (CMakeLists.txt Makefile.am zoom/ zoom/zoom.c zoom.c): zoom becomes the guinea piggie. move it into a subdir in preparation for sorting out fully self-contained modular commands. |
| 22:31.19 | CIA-62 | BRL-CAD: 03brlcad * r45438 10/brlcad/trunk/src/libged/zoom/zoom.c: remove unnecessary headers and useless doxy file comment |
| 22:32.36 | CIA-62 | BRL-CAD: 03brlcad * r45439 10/brlcad/trunk/src/libged/zoom/zoom.c: technically, ged_private.h is no longer in this dir |
| 22:40.28 | CIA-62 | BRL-CAD: 03brlcad * r45440 10/brlcad/trunk/src/libged/ (ged_private.h vutil.c zoom/zoom.c): move _ged_do_zoom() out of vutil into zoom.c since that's the only place it's used, no longer needing private decl. rename to zoom(). |
| 22:44.03 | CIA-62 | BRL-CAD: 03brlcad * r45441 10/brlcad/trunk/src/libged/zoom/zoom.c: reduce and simplify |
| 22:44.51 | CIA-62 | BRL-CAD: 03brlcad * r45442 10/brlcad/trunk/src/libged/zoom/zoom.c: don't need a db to scale the view |
| 22:58.13 | CIA-62 | BRL-CAD: 03brlcad * r45443 10/brlcad/trunk/src/libged/zoom/zoom.c: make sure we set sf before testing its value, simplify validity to the two boundaries while treating the edge case as inside. |
| 22:59.44 | CIA-62 | BRL-CAD: 03brlcad * r45444 10/brlcad/trunk/include/vmath.h: ws |
| 23:51.16 | *** join/#brlcad mafm (~mafm@83.Red-83-54-79.dynamicIP.rima-tde.net) | |
| 00:28.57 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 00:50.42 | CIA-62 | BRL-CAD: 03kunigami * r45445 10/brlcad/trunk/src/liboptical/ (liboslrend.h sh_osl.cpp): |
| 00:50.42 | CIA-62 | BRL-CAD: trying to allow multi-threading. I surrounded OSLRender access with semaphores |
| 00:50.42 | CIA-62 | BRL-CAD: lock, but with 2 processors it is still crashing. I first tried using |
| 00:50.42 | CIA-62 | BRL-CAD: RT_SEM_LAST, but I get a run-time error because the number of semaphores |
| 00:50.42 | CIA-62 | BRL-CAD: exceeded 12, so I added a random identifier 8 |
| 01:59.46 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 01:59.46 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 being tagged today (20110701) || BRL-CAD has applied to participate in the ESA Summer of Code in Space! | |
| 03:06.12 | starseeker | ``Erik: do you know a good desktop PC maker these days? |
| 03:06.43 | starseeker | may have to look into a new system, and isn't sure he can afford the time to collect components and do it "right" |
| 03:09.28 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 03:28.56 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 03:42.53 | CIA-62 | BRL-CAD: 03bhinesley * r45446 10/brlcad/trunk/src/libged/alter.c: update argument flags, add several argument node helper functions |
| 05:39.30 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 07:30.00 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 07:34.45 | *** join/#brlcad Stattrav (~Stattrav@117.202.18.108) | |
| 07:34.45 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:25.14 | *** join/#brlcad mafm (~mafm@90.Red-83-42-153.dynamicIP.rima-tde.net) | |
| 09:14.56 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) | |
| 09:14.56 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:54.15 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 12:08.38 | ``Erik | starseeker: been starting to research that myself, think I'm about due for 2 new machines |
| 13:21.29 | kunigami_ | Which tool do you use to debug multi-thread applications? |
| 13:30.31 | brlcad | kunigami_: gdb can be used to debug multithreaded apps, you can switch threads and processes while debugging, set separate breakpoints, etc |
| 13:30.45 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) | |
| 13:30.45 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:37.02 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3007 10/wiki/Celestial_mechanics_particle_system: |
| 13:39.05 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 13:42.15 | *** join/#brlcad mafm (~mafm@90.Red-83-42-153.dynamicIP.rima-tde.net) | |
| 13:47.34 | brlcad | yawns |
| 14:42.00 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 17:25.06 | *** join/#brlcad merzo (~merzo@252-7-132-95.pool.ukrtel.net) | |
| 18:20.44 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:24.36 | *** join/#brlcad dli (~dli@66.49.188.111) | |
| 18:49.40 | CIA-62 | BRL-CAD: 03erikgreenwald * r45447 10/brlcad/trunk/src/proc-db/ringworld.c: add some body to make this do something (shows render issues at large scale) |
| 18:52.34 | CIA-62 | BRL-CAD: 03erikgreenwald * r45448 10/brlcad/trunk/NEWS: list ringworld proc-db |
| 18:53.48 | CIA-62 | BRL-CAD: 03brlcad * r45449 10/brlcad/trunk/include/bu.h: add a BU_LIST_INIT_MAGIC() macro so we can init and set a magic as a one-liner |
| 18:59.13 | CIA-62 | BRL-CAD: 03brlcad * r45450 10/brlcad/trunk/include/bu.h: use the new BU_LIST_INIT_MAGIC() macro, reduce |
| 19:01.02 | CIA-62 | BRL-CAD: 03brlcad * r45451 10/brlcad/trunk/include/ged.h: initial stubs for supporting a ged command container within the ged struct. a ged_cmd object describes a single named command providing the name, a brief description, the name of its manual page, and callback hooks. |
| 19:01.37 | CIA-62 | BRL-CAD: 03brlcad * r45452 10/brlcad/trunk/include/magic.h: define a magic number for ged_cmd objects. using 'exec' since that's the heart of a ged command. |
| 19:08.34 | CIA-62 | BRL-CAD: 03brlcad * r45453 10/brlcad/trunk/include/ (bu.h magic.h): |
| 19:08.34 | CIA-62 | BRL-CAD: fix a FIXME, define a magic number for bu_observer objects. if there was bad |
| 19:08.34 | CIA-62 | BRL-CAD: code that relied on zero-initialization (e.g., via calloc), that will no longer |
| 19:08.34 | CIA-62 | BRL-CAD: result in proper initialization and will fail until fixed with a |
| 19:08.34 | CIA-62 | BRL-CAD: BU_OBSERVER_INIT OR BU_OBSERVER_INIT_ZERO call. |
| 19:16.53 | CIA-62 | BRL-CAD: 03brlcad * r45454 10/brlcad/trunk/src/liboptical/sh_prj.c: set the magic as soon as we begin as part of initialization. |
| 19:18.13 | CIA-62 | BRL-CAD: 03brlcad * r45455 10/brlcad/trunk/src/ (5 files in 3 dirs): use the new BU_LIST_INIT_MAGIC() macro, reducing a few lines |
| 19:25.40 | CIA-62 | BRL-CAD: 03brlcad * r45456 10/brlcad/trunk/src/libged/zoom/zoom.c: work in progress. define the zoom command including load/unload functions that add/remove it from a gedp. |
| 19:29.17 | bhinesley | grabs popcorn |
| 19:32.01 | kunigami_ | Even adding semaphores around OSLRender sh_osl crashes for two processors. I tried increasing the size of the stack at bu_parallel. without sucess |
| 19:33.18 | kunigami_ | The problem only occurs when I do recursive calls (through rt_shootray) |
| 19:34.07 | kunigami_ | I took a look at the implementation of rr_render and it does not seem to take any extra care before calling rt_shootray |
| 19:57.30 | CIA-62 | BRL-CAD: 03brlcad * r45457 10/brlcad/trunk/include/magic.h: expand all of the magic numbers with what they represent in ascii, using '?' for non-printable characters. |
| 20:13.37 | CIA-62 | BRL-CAD: 03starseeker * r45458 10/brlcad/trunk/CMakeLists.txt: |
| 20:13.37 | CIA-62 | BRL-CAD: Start trying to get the point where we can do 64 bit builds on 32 bit systems |
| 20:13.37 | CIA-62 | BRL-CAD: and vice versa with the flick of an option. Start with a more verbose warning |
| 20:13.37 | CIA-62 | BRL-CAD: and option correction for MSVC, where one must pick one generator or the other |
| 20:13.37 | CIA-62 | BRL-CAD: at CMake configure time. |
| 21:25.10 | CIA-62 | BRL-CAD: 03starseeker * r45459 10/brlcad/trunk/src/libfft/CMakeLists.txt: Whoops - adding --no-undefined to linker flags caught libfft needing M_LIBRARY |
| 21:26.08 | CIA-62 | BRL-CAD: 03starseeker * r45460 10/brlcad/trunk/CMakeLists.txt: Add --no-undefined to linker, fix printing of linker settings. |
| 21:27.10 | CIA-62 | BRL-CAD: 03starseeker * r45461 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Untested, but add in some flags intended to help handle the 'build 32 on 64bit' situation. |
| 21:31.13 | CIA-62 | BRL-CAD: 03starseeker * r45462 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Add linker settings for 32 as well. Ideally these should be tests to see if the linker can handle the flags, but not sure how to set that up yet. |
| 21:31.37 | CIA-62 | BRL-CAD: 03brlcad * r45463 10/brlcad/trunk/include/nurb.h: don't conditionally include the headers we need. they already have built-in inclusion protection. |
| 21:34.51 | CIA-62 | BRL-CAD: 03brlcad * r45464 10/brlcad/trunk/ (3 files in 3 dirs): replace RT_CNURB_MAGIC and RT_SNURB_MAGIC with the corresponding NMG magic defines that were identical values. |
| 22:40.14 | CIA-62 | BRL-CAD: 03bhinesley * r45465 10/brlcad/trunk/src/libged/alter.c: rename several silly struct/union/members, more helper function work |
| 22:46.33 | kunigami_ | Running with GDB, I always get one of these two errors: http://paste.ubuntu.com/643588/ (the cause seems to be invalid memory access) |
| 22:52.43 | CIA-62 | BRL-CAD: 03bhinesley * r45466 10/brlcad/trunk/src/libged/ (alter.c edit.c): renaming alter to edit... let's see if I can rename the file first |
| 23:01.07 | CIA-62 | BRL-CAD: 03bhinesley * r45467 10/brlcad/trunk/ (6 files in 4 dirs): other instances of alter that needed to be renamed to edit, and add edit command to archer |
| 23:16.44 | *** join/#brlcad mafm (~mafm@90.Red-83-42-153.dynamicIP.rima-tde.net) | |
| 23:28.38 | CIA-62 | BRL-CAD: 03bhinesley * r45468 10/brlcad/trunk/src/mged/setup.c: rename alter -> edit for mged |
| 23:29.42 | CIA-62 | BRL-CAD: 03bhinesley * r45469 10/brlcad/trunk/src/libged/edit.c: make most functions HIDDEN, at least for now |
| 00:36.49 | *** join/#brlcad crux000 (~dan@66.110.178.234) | |
| 00:37.50 | *** part/#brlcad crux000 (~dan@66.110.178.234) | |
| 00:45.53 | CIA-62 | BRL-CAD: 03kunigami * r45470 10/brlcad/trunk/src/liboptical/sh_osl.cpp: |
| 00:45.53 | CIA-62 | BRL-CAD: Instead of copying only a_rtip, a_hit and a_miss from the previous application, |
| 00:45.53 | CIA-62 | BRL-CAD: I'm now copying the whole structure before calling rt_shootray at osl_render. I |
| 00:45.53 | CIA-62 | BRL-CAD: have no idea why it worked for single threads but not for multiple threads. |
| 00:47.29 | CIA-62 | BRL-CAD: 03brlcad * r45471 10/brlcad/trunk/ (7 files in 5 dirs): replace BU_LIST_MAGIC_OK() and BU_LIST_MAGIC_WRONG() with BU_LIST_MAGIC_EQUAL() in order for the API to be more consistent with convention already established in libbn. |
| 00:48.00 | brlcad | kunigami_: aha, so that fixed it? |
| 00:49.23 | brlcad | didn't realize you were doing a partial copy there .. there are cpu-specific resource structures in an application struct, so when you weren't copying them it would have been in some peculiar uninitialized state (not suitable for threaded use) |
| 00:51.37 | CIA-62 | BRL-CAD: 03brlcad * r45472 10/brlcad/trunk/include/bu.h: remove BU_LIST_CLOSE() since it appears to not be in use any where and it's use is rather limited with the embedded return; there's also no corresponding 'open' so it was just bad API to begin with |
| 00:55.33 | CIA-62 | BRL-CAD: 03bhinesley * r45473 10/brlcad/trunk/src/ (3 files in 3 dirs): |
| 00:55.33 | CIA-62 | BRL-CAD: Add edit and translate/rotate/scale to Archer. Edit command aliases are |
| 00:55.33 | CIA-62 | BRL-CAD: intentionally only available to Archer, to keep existing mged commands intact |
| 00:55.33 | CIA-62 | BRL-CAD: for the time being. Once everything is working, translate/rotate/scale will be |
| 00:55.33 | CIA-62 | BRL-CAD: mapped directly to ged_edit. |
| 00:56.18 | brlcad | basically, your new application struct wasn't being initialized properly |
| 00:57.07 | brlcad | anytime you do a full struct copy, you should denote it with a /* struct copy */ comment or similar |
| 01:02.42 | brlcad | starseeker: is nirt building on windows? |
| 01:03.56 | brlcad | ah, I see you just disabled those files .. never mind |
| 01:04.28 | CIA-62 | BRL-CAD: 03brlcad * r45474 10/brlcad/trunk/src/nirt/dist_def.c: use FMAX() instead of fmax() since the latter is C99 |
| 01:32.51 | kunigami_ | brlcad: it seems to have been solved :) I'll add that comment |
| 02:13.29 | *** join/#brlcad merzo (~merzo@252-7-132-95.pool.ukrtel.net) | |
| 02:29.32 | *** join/#brlcad mafm (~mafm@90.Red-83-42-153.dynamicIP.rima-tde.net) | |
| 02:49.41 | *** join/#brlcad IriX64 (~root@bas2-sudbury98-1177871903.dsl.bell.ca) | |
| 02:55.50 | *** join/#brlcad IriX64_ (~root@bas2-sudbury98-1177872273.dsl.bell.ca) | |
| 03:00.56 | *** join/#brlcad IriX64 (~root@bas2-sudbury98-1096601331.dsl.bell.ca) | |
| 03:05.59 | *** join/#brlcad IriX64_ (~root@bas2-sudbury98-1128564768.dsl.bell.ca) | |
| 03:35.14 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 04:18.25 | CIA-62 | BRL-CAD: 03brlcad * r45475 10/brlcad/trunk/src/nirt/ (CMakeLists.txt Makefile.am dist_def.c): |
| 04:18.25 | CIA-62 | BRL-CAD: remove dist_def.c which was disabled from compilation, but appears to have been |
| 04:18.25 | CIA-62 | BRL-CAD: related to an earlier implementation of nirt's backout command. since that code |
| 04:18.25 | CIA-62 | BRL-CAD: has since changed and been improved, just kill this old bit. |
| 04:21.53 | CIA-62 | BRL-CAD: 03brlcad * r45476 10/brlcad/trunk/ (3 files in 3 dirs): remove nurb's MIN/MAX macros since we already rely on FMIN/FMAX elsewhere. |
| 04:28.06 | CIA-62 | BRL-CAD: 03brlcad * r45477 10/brlcad/trunk/src/burst/grid.c: remove the min()/max() functions since there don't seem to be any uses that will have side-effects, use FMIN()/FMAX() instead like already being used. |
| 04:28.52 | CIA-62 | BRL-CAD: 03brlcad * r45478 10/brlcad/trunk/src/proc-db/masonry.c: get rid of the min/max macros in favor of the FMIN/FMAX decls from common.h |
| 04:30.58 | CIA-62 | BRL-CAD: 03brlcad * r45479 10/brlcad/trunk/src/fb/pl-fb.c: remove unused min() macro |
| 04:36.12 | CIA-62 | BRL-CAD: 03brlcad * r45480 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: call NEAR_EQUAL() instead of BN_APPROXEQUAL() since they do the same thing and the latter is unnecessary api. |
| 04:41.03 | CIA-62 | BRL-CAD: 03brlcad * r45481 10/brlcad/trunk/include/bn.h: remove BN_APPROXEQUAL since NEAR_EQUAL is practically equivalent just without requiring a bn_tol. looks like the only use was isolated to brep.cpp, so yank it. |
| 04:48.35 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 04:58.48 | CIA-62 | BRL-CAD: 03brlcad * r45482 10/brlcad/trunk/src/irprep/ (CMakeLists.txt Makefile.am ir-sgi.1 ir-sgi.c): remove the antiquated ir-sgi tool since IRIX is no longer a supported platform |
| 05:03.04 | CIA-62 | BRL-CAD: 03brlcad * r45483 10/brlcad/trunk/src/irprep/ (CMakeLists.txt Makefile.am irdisp.c pictsgi.1 pictsgi.c): same for pictsgi and irdisp tools, which called ir-sgi. remove pictsgi since it's no longer functional without ir-sgi. |
| 05:10.11 | CIA-62 | BRL-CAD: 03brlcad * r45484 10/brlcad/trunk/include/ (bu.h raytrace.h): remove sgi/mips references, platform no longer relevant |
| 05:16.58 | CIA-62 | BRL-CAD: 03brlcad * r45485 10/brlcad/trunk/src/lgt/ (6 files): remove all references to sgi since the platform is no longer maintainable |
| 05:37.28 | CIA-62 | BRL-CAD: 03brlcad * r45486 10/brlcad/trunk/src/canon/ (Makefile.am canonlib.c): more sgi/irix/mips removal. no longer need libds too. |
| 05:45.48 | CIA-62 | BRL-CAD: 03brlcad * r45487 10/brlcad/trunk/src/libfb/if_X.c: we still need this with Xorg, not SGI-specific |
| 05:46.02 | CIA-62 | BRL-CAD: 03brlcad * r45488 10/brlcad/trunk/src/libfb/ (fbserv_obj.c if_ogl.c): remove sgi from comments |
| 05:50.50 | CIA-62 | BRL-CAD: 03brlcad * r45489 10/brlcad/trunk/src/libfb/if_X.c: actually, it looks like peeking at the fd is the only internal we look for so call ConnectionNumber() to get it so we can unset XLIB_ILLEGAL_ACCESS. |
| 05:52.53 | CIA-62 | BRL-CAD: 03brlcad * r45490 10/brlcad/trunk/src/ (bwish/Makefile.am conv/Makefile.am): LINK_STATIC_REQUIRED was needed for irix, simplify |
| 05:58.36 | CIA-62 | BRL-CAD: 03brlcad * r45491 10/brlcad/trunk/ (16 files in 9 dirs): the sgi/irix/mips platform is no more and has been that way for many years now. reduce maintenance cost, remove and refactor accordingly. |
| 06:17.26 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) | |
| 06:17.26 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:12.43 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 08:05.59 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 09:34.51 | *** join/#brlcad mafm (~mafm@247.Red-83-38-35.dynamicIP.rima-tde.net) | |
| 11:49.25 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-187-000.wlan.tudelft.nl) | |
| 12:01.57 | CIA-62 | BRL-CAD: 03starseeker * r45492 10/brlcad/trunk/CMakeLists.txt: |
| 12:01.57 | CIA-62 | BRL-CAD: Ah hah. Per http://www.cmake.org/Wiki/CMake_Version_Compatibility_Matrix, the |
| 12:01.57 | CIA-62 | BRL-CAD: *IGNORE_PATH variables weren't around until 2.8.3 - that's probably why the new |
| 12:01.57 | CIA-62 | BRL-CAD: mechanism for ignoring install paths wasn't working in some tests. Bump our |
| 12:01.57 | CIA-62 | BRL-CAD: required version, as we need to avoid finding old installed BRL-CAD libraries. |
| 12:22.20 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 12:33.34 | brlcad | moin |
| 13:18.35 | CIA-62 | BRL-CAD: 03brlcad * r45493 10/brlcad/trunk/src/ (5 files in 4 dirs): more irix reference removals. |
| 13:29.51 | ``Erik | yargh |
| 13:30.34 | ``Erik | hm, broken stuff, but vaccuum lady is here :/ |
| 13:43.37 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) | |
| 13:43.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:07.56 | *** join/#brlcad kunigami__ (~kunigami@201.53.206.27) | |
| 14:18.16 | *** join/#brlcad dli (~dli@dsl-67-204-13-217.acanac.net) | |
| 14:40.48 | *** join/#brlcad dli (~dli@66.49.171.226) | |
| 16:34.50 | CIA-62 | BRL-CAD: 03r_weiss * r45494 10/brlcad/trunk/src/librt/primitives/ars/ars.c: (log message trimmed) |
| 16:34.51 | CIA-62 | BRL-CAD: Updated the rt_ars_tess function within file ars.c. I disabled the functions |
| 16:34.51 | CIA-62 | BRL-CAD: nmg_shell_coplanar_face_merge and nmg_simplify_shell unless the prototype |
| 16:34.51 | CIA-62 | BRL-CAD: triangulation is enabled. The problem is these functions simplify the ars which |
| 16:34.51 | CIA-62 | BRL-CAD: causes more work for later triangulating the ars. The original triangulation |
| 16:34.51 | CIA-62 | BRL-CAD: code is unable to triangulate the resulting ars after being simplifed. In order |
| 16:34.52 | CIA-62 | BRL-CAD: to raytrace an ars, it is first converted to a bot primitive which requires |
| 16:36.08 | *** join/#brlcad dli (~dli@173.248.249.148) | |
| 16:56.49 | *** join/#brlcad dli (~dli@66.49.131.81) | |
| 17:03.28 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 17:04.31 | starseeker | whoops |
| 17:04.52 | starseeker | make makes a note that quit != part in issi |
| 17:04.55 | starseeker | irssi even |
| 17:19.20 | ``Erik | heh, nope, not equal :) |
| 17:30.03 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 17:42.42 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 18:04.02 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:18.20 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) | |
| 19:18.20 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:38.17 | CIA-62 | BRL-CAD: 03bhinesley * r45495 10/brlcad/trunk/src/libged/edit.c: remove trailing ws |
| 19:54.56 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601243.dsl.bell.ca) | |
| 19:55.44 | IriX64 | brlcad/regress is missing CMakeLists.txt |
| 19:57.49 | IriX64 | btw i run el6Workstation now, cygwin is retired :) ill ask my self to leave now. |
| 20:02.11 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096600661.dsl.bell.ca) | |
| 20:02.50 | IriX64 | shouldn't do this so soon but cmake generates man/html, configure generates man/html/pdf if anybody cares |
| 20:03.19 | IriX64 | i hear me asking myself to leave again, wont be back today |
| 20:25.33 | kunigami_ | 13min to render a scene with one processor. 14min to run with 2 :) The problem is that I'm blocking the OSLRender every time I query a color, which is probably where most all the time is spent. I'm currently looking for multi-threaded examples using OSL system to block less parts of code. |
| 20:56.14 | dli | cmake trouble: [ 17%] make[2]: *** No rule to make target `usr/brlcad/share/tclscripts/archer/tclIndex', needed by `src/tclscripts/archer/CMakeFiles/archer_tclIndex' |
| 20:58.54 | bhinesley | hmm.. . it's working for me |
| 21:03.14 | bhinesley | dli: are you working on a recent svn checkout, a tarball, or what? |
| 21:03.25 | dli | bhinesley, 7.20.2 |
| 21:03.36 | bhinesley | windows? |
| 21:03.43 | dli | bhinesley, linux |
| 21:05.11 | bhinesley | unless someone else has an idea, I will take a look but it will take me a bit to download/compile |
| 21:05.49 | dli | bhinesley, this is my cmake line: http://pastebin.com/hrXWMCZn |
| 21:08.52 | bhinesley | hmm... starseeker may have to take a look at that one |
| 21:09.24 | bhinesley | is just a student |
| 21:09.30 | dli | bhinesley, I know he started the cmake branch |
| 21:09.55 | bhinesley | yep, he's your man |
| 21:10.54 | dli | bhinesley, also, I have to tweak CMakefile.txt a little bit: http://paste.pocoo.org/show/438902/ |
| 21:11.47 | bhinesley | odd |
| 21:13.33 | bhinesley | what is there currently: http://pastebin.mozilla.org/1272356 |
| 21:13.48 | *** join/#brlcad mafm (~mafm@247.Red-83-38-35.dynamicIP.rima-tde.net) | |
| 21:14.12 | dli | bhinesley, current some ${${path_label}_LABEL} contain space within |
| 21:15.11 | dli | bhinesley, therefore, sending more than two arguments to LENGTH, and break cmake |
| 21:15.57 | bhinesley | yeah, I misread, your original is identical to the current revision |
| 21:17.35 | bhinesley | I won't waste your time: I wouldn't know how to fix it. |
| 21:18.03 | dli | bhinesley, don't worry :) |
| 21:34.56 | dli | bhinesley, seems to be something wrong with make configure line, it builds now |
| 21:39.11 | bhinesley | can you show me what you changed it to? |
| 21:42.32 | dli | bhinesley, sure |
| 21:44.52 | dli | bhinesley, http://paste.pocoo.org/show/438926/ |
| 21:45.10 | dli | bhinesley, I guess the incorrect PREFIX broke it |
| 21:53.20 | bhinesley | dli: yeah I see that there there is no DCMAKE_PREFIX in your correct version, but there are two DCMAKE_INSTALL_PREFIX's |
| 21:53.28 | bhinesley | er, working version |
| 21:53.46 | bhinesley | er DBRLCAD_PREFIX I mean |
| 21:55.27 | dli | bhinesley, it's okay, one instance is always added by the gentoo script, the second one overrides it |
| 21:56.55 | bhinesley | nods |
| 21:59.28 | dli | ^[[0m[ 98%] Built target step-g |
| 21:59.28 | dli | make: *** [all] Error 2 |
| 21:59.32 | dli | no luck :( |
| 21:59.45 | bhinesley | :-/ |
| 22:00.04 | dli | bhinesley, can I disable step-g ? |
| 22:00.33 | dli | bhinesley, it says 'built', so it's not step-g |
| 22:11.40 | brlcad | make VERBOSE=1 |
| 22:11.55 | dli | brlcad, doing that now |
| 22:16.07 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 23:30.57 | ``Erik | notes that --no-undefined is not a recognized option on some of his compilers O.o (like the mac) |
| 23:54.34 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 23:56.29 | *** join/#brlcad kunigami__ (~kunigami@201.53.206.27) | |
| 23:57.00 | starseeker | ``Erik: yeah, need to test for that somehow or other |
| 23:59.36 | starseeker | dli: "usr" is still a really bad value for CMAKE_INSTALL_PREFIX |
| 23:59.53 | starseeker | also, you don't need to set BRLCAD_PREFIX any more - it's just an interal thing now |
| 00:00.14 | dli | starseeker, yes, I figured it out by trying brutal force :( |
| 00:00.33 | starseeker | sorry - been busy |
| 00:00.48 | dli | starseeker, how do I add LDFLAGS for itcl and itk? still broken after 98% built |
| 00:01.24 | starseeker | growl. pastebin? |
| 00:02.03 | dli | usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -litcl |
| 00:02.35 | starseeker | um - are you using system itcl or the local one? |
| 00:02.46 | dli | starseeker, and itcl is at: /usr/lib64/itcl3.4/libitcl3.4.so , using system one |
| 00:03.54 | starseeker | what does your CMakeCache.txt say for ITCL_LIBRARY? |
| 00:03.57 | dli | starseeker, do I need CMAKE_LINK_FLAGS or could it auto detect system itcl/itk |
| 00:04.16 | starseeker | I thought I had set up detection for Itcl/Itk |
| 00:04.43 | dli | starseeker, grep ITCL_LIBRARY CMakeCache.txt found nothing |
| 00:04.47 | starseeker | I seldom build with system libs, so it's possible the Find* logic for Itcl/Itk isn't functioning quite right |
| 00:05.09 | starseeker | hmm - you do have a CMakeCache.txt file? |
| 00:05.18 | dli | starseeker, grep ITCL found something: http://paste.pocoo.org/show/439032/ |
| 00:06.17 | starseeker | hmm - so the question is what the find routines are doing |
| 00:08.05 | dli | starseeker, for the time being, I will try CMAKE_LINK_FLAGS |
| 00:09.19 | starseeker | If the find routines were working, you wouldn't be getting itcl |
| 00:10.04 | dli | starseeker, do you mean be getting itcl/itk trouble? |
| 00:10.17 | CIA-62 | BRL-CAD: 03starseeker * r45496 10/brlcad/trunk/CMakeLists.txt: Quote some path strings for robustness - need more testing of the logic with spaces and other unfriendly characters paths |
| 00:10.31 | starseeker | dli: I'm assuming your using system Tcl/Tk? |
| 00:10.40 | dli | starseeker, yes |
| 00:11.04 | starseeker | dli: what happens if you just run cmake without forcing off libraries? |
| 00:11.18 | starseeker | (i.e what does the summary report at the end?) |
| 00:11.28 | starseeker | it will try to use system libraries if it can find them by default |
| 00:11.53 | dli | starseeker, I will try that later, it's building with CMAKE_LINK_FLAGS now :( slow core2duo |
| 00:12.12 | starseeker | k - if it's not using system Tcl/Tk, there's probably a reason |
| 00:12.34 | starseeker | forcing system lib usage when the cmake logic doesn't select them by default is problematic |
| 00:12.49 | starseeker | if the cmake logic is doing its job, it is rejecting them for a reason |
| 00:13.31 | dli | starseeker, summary of report: http://pastebin.com/AkxGVSdZ |
| 00:14.07 | starseeker | and your CMakeCache.txt file still doesn't have ITCL_LIBRARY? |
| 00:15.10 | dli | starseeker, no, still no ITCL_LIBRARY |
| 00:17.04 | starseeker | OH. I know what's going on |
| 00:17.14 | starseeker | this is a consequence of switching back to using the Itcl/Itk C API |
| 00:17.45 | dli | starseeker, so, I probably need a patch for 7.20.2 |
| 00:17.59 | starseeker | I had changed things so that we were simply doing package require Itcl where needed - brlcad got a report of some breakage somewhere |
| 00:18.07 | starseeker | I never could reproduce it |
| 00:18.24 | starseeker | dli: you might try the autotools build - that should still work |
| 00:18.40 | dli | starseeker, already tested, it works |
| 00:19.13 | dli | starseeker, I'm trying to make a gentoo ebuild for cmake building |
| 00:19.14 | starseeker | brlcad: do you recall what the problem was with using package require and what the conditions were to reproduce the bug? If it's a choice between fixing that bug and reworking the Itcl/Itk detection logic to find the C API I'd vote for fixing the bug |
| 00:20.53 | starseeker | dli: this isn't all that simple - the Itcl/Itk C headers require internal headers we can't count on from an installed system version |
| 00:21.27 | dli | starseeker, but autotools still build it properly |
| 00:21.43 | starseeker | dli: yes, because all the necessary scary logic is already in there |
| 00:22.09 | starseeker | we shouldn't actually need the Itcl/Itk C api at all - I yanked it out once, but there was a report of a bug |
| 00:22.23 | starseeker | something about loading iwidgets twice IIRC, but I couldn't duplicate it |
| 00:22.47 | dli | starseeker, I would love to see itcl/itk removed. :( |
| 00:22.58 | starseeker | dli: we can't remove it - it's used extensively |
| 00:23.13 | starseeker | once we can just do "package require Itcl" it gets a lot easier |
| 00:23.52 | starseeker | The Tcl/Tk headers are horrible about API separation - lots of extensions need access to "internal" headers just to build |
| 00:24.06 | dli | starseeker, for the time being I can force local building of itcl/itk, seems to be a workaround |
| 00:24.14 | starseeker | dli: yeah, that should work |
| 00:24.29 | starseeker | although if you're doing a gentoo ebuild they'll never go for it |
| 00:25.12 | dli | starseeker, let me try ;( |
| 00:28.26 | dli | starseeker, I have to enable tcl/tk local building, not simply itcl/itk, right? |
| 00:28.40 | starseeker | um. You can try just itcl/itk |
| 00:28.58 | starseeker | not sure if that'll fly without the tcl/tk internal headers, but you can give it a shot |
| 00:29.28 | dli | starseeker, no such flag ITCL/ITK in CMakeLists.txt |
| 00:29.44 | starseeker | -DBRLCAD_BUILD_LOCAL_ITCL=ON |
| 00:29.55 | starseeker | -DBRLCAD_BUILD_LOCAL_ITK=ON |
| 00:29.57 | starseeker | try those |
| 00:32.24 | kunigami__ | Is there any way I can get the identifier of a thread in a sh_xyz code? |
| 00:33.14 | dli | starseeker, no, no effect, cmake still found system itcl/itk |
| 00:33.25 | starseeker | one sec... |
| 00:34.12 | starseeker | crud - yeah, you may need to enable tcl/tk then |
| 00:34.37 | starseeker | I was probably thinking a "sane" Itcl/Itk build couldn't depend on a system tcl/tk install having what it needed anyway |
| 00:37.07 | kunigami__ | This identifier should be passed along application and probably set at do_pixel |
| 00:37.28 | starseeker | kunigami__: sorry, that's a little outside my expertice |
| 00:40.09 | starseeker | dli: the only reason we can even "mix" system Tcl/Tk and local package builds in the old autotools setup is due to our logic supplying our own local include directories in src/other to the builds of those extensions that need them |
| 00:40.11 | dli | starseeker, still no luck, cmake still found system tcl/tk/itcl/itk |
| 00:40.36 | kunigami__ | starseeker: no problem :) I'm just thinking aloud to see if I can get some feedback |
| 00:40.36 | kunigami__ | ] |
| 00:40.48 | starseeker | -DBRLCAD_BUILD_LOCAL_TCL_FORCE=ON |
| 00:41.11 | starseeker | or rather -DBRLCAD_BUILD_LOCAL_TCL_FORCE_ON=ON |
| 00:44.02 | dli | starseeker, yes, FORCE_ON does the trick |
| 00:54.41 | kunigami__ | <PROTECTED> |
| 00:59.19 | CIA-62 | BRL-CAD: 03starseeker * r45497 10/brlcad/trunk/CMakeLists.txt: Comment out the --no-undefined linker option until I figure out how to test it. |
| 01:17.15 | kunigami__ | thanks :) |
| 01:18.09 | dli | starseeker, yes, with FORCE_ON, it builds properly. Thanks |
| 01:19.28 | starseeker | dli: no problem |
| 01:23.44 | CIA-62 | BRL-CAD: 03kunigami * r45498 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h sh_osl.cpp): changing OSLRender methods to static. I think this will be necessary to increase parallelism |
| 02:28.22 | bhinesley | When I have argc > 1 and my command returns GED_HELP, Archer prints the error "No ledger entry found for help." What am I missing? |
| 02:28.48 | bhinesley | in that case, argv[2] was help |
| 02:29.41 | bhinesley | excuse me, argv[1] was help |
| 02:37.16 | CIA-62 | BRL-CAD: 03bhinesley * r45499 10/brlcad/trunk/include/ged.h: moved ged_edit to more appropriate place |
| 02:43.55 | CIA-62 | BRL-CAD: 03bhinesley * r45500 10/brlcad/trunk/src/ (8 files in 3 dirs): Validate subcommand names, add ged_edit stuff to a few places I missed before, cleanup. |
| 02:45.58 | CIA-62 | BRL-CAD: 03bhinesley * r45501 10/brlcad/trunk/src/libged/edit.c: quiet compiler warning about unused variable |
| 02:52.13 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 03:12.36 | brlcad | kunigami__: libbu's parallelism passes the cpu/thread id to the worker callback |
| 03:12.54 | brlcad | for rt, that's the worker() function in src/rt/worker.c, which in turn calls do_pixel() with the cpu |
| 03:13.44 | brlcad | the application struct's a_resource is then set to a cpu-specific resource structure safe for that thread to use without blocking |
| 03:14.18 | brlcad | why you'd need to know that is a bit of a mystery, though ... :) |
| 03:15.28 | brlcad | bhinesley: I'm not sure what archer was set up to use, but it may be pulling help from src/tclscripts/helplib.tcl and/or src/tclscripts/help.tcl ... old help interface |
| 03:15.59 | brlcad | the modular command refactoring that I started is the beginnings of making those obsolete |
| 03:16.57 | bhinesley | brlcad: that was sort of a bad example. It prints "No ledger entry found for <whatever argv[1] is>" |
| 03:17.42 | bhinesley | assuming that I return GED_HELP |
| 03:18.09 | brlcad | both mged and archer tell you that or just archer? |
| 03:18.13 | bhinesley | just archer |
| 03:19.36 | bhinesley | you weren't kidding... there really are a lot of places to make changes when you add a command |
| 03:19.52 | *** join/#brlcad dli (~dli@dsl-69-172-83-119.acanac.net) | |
| 03:21.46 | brlcad | yeah, it's really terrible |
| 03:22.23 | brlcad | 15 years of a very active dev not doing hardly any proper refactoring, at least not for the DRY principle |
| 03:24.17 | brlcad | part of the problem is that even with a clean refactoring towards libged, a silly route was taken to make it fit the existing archer interface .. once again needing to repeat all commands |
| 03:24.43 | brlcad | all of the *_obj.c files should be killed, but that's a refactoring task in itself -- feel free to tackle any and all of them |
| 03:25.46 | bhinesley | nods |
| 03:25.55 | bhinesley | definitely no lack of things to do |
| 03:31.53 | brlcad | he's also like the 3rd or 4th most experienced tcl dev on the planet (at least as measured by ohloh), so (for him) he's very adept wandering around the bowels of mged and archer |
| 03:32.14 | brlcad | sort of has his own perspective on maintainability |
| 03:34.02 | bhinesley | is he ever in here? |
| 03:34.12 | bhinesley | or lists only? |
| 03:37.52 | brlcad | mostly mailing list |
| 03:38.08 | brlcad | so that ledger issue, more replication crap |
| 03:38.36 | brlcad | and it's not code I really understand, so can't be of much help -- might make a good mailing list question if you have any |
| 03:38.42 | bhinesley | alright, well, it's not inhibiting the functionality of the command, so I won't worry about it right now |
| 03:39.00 | brlcad | tclscripts/archer/Archer.tcl AND tclscripts/archer/ArcherCore.tcl .. both list commands for some reason |
| 03:39.19 | brlcad | I presume if you don't list the command that it's calling some generic wrapper, and pulling the wrong argv for your command or something |
| 03:39.54 | bhinesley | looks into this |
| 03:40.07 | bhinesley | hey, ohloh is pretty neat |
| 03:40.10 | bhinesley | just now checking it out |
| 03:40.17 | brlcad | really? :) |
| 03:40.33 | brlcad | http://www.ohloh.net/p/brlcad |
| 03:41.37 | bhinesley | first thing I did was search for brlcad ;-) |
| 03:51.20 | bhinesley | 96 commits... hm... I'd better step it up a notch |
| 03:59.40 | brlcad | add two orders of magnitude and you'll be in the #3 spot ;) |
| 03:59.59 | brlcad | that's like two years |
| 04:11.19 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3008 10/wiki/Non-vacuum_gravity_simulator: missing paren |
| 04:20.37 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3009 10/wiki/Celestial_mechanics_particle_system: link to some 3rd party libs |
| 04:21.08 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3010 10/wiki/Non-vacuum_gravity_simulator: |
| 04:41.35 | *** join/#brlcad dli (~dli@67.55.33.66) | |
| 07:09.17 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 07:10.29 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:12.14 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 07:12.56 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 07:16.23 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 08:02.47 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 09:10.01 | *** join/#brlcad mafm (~mafm@120.Red-83-42-153.dynamicIP.rima-tde.net) | |
| 09:18.18 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:56.23 | kunigami__ | brlcad: it seems I need to set different vars for each thread when first calling OSLRender and I dont know how to do that without an identifier for each thread. |
| 10:08.14 | kunigami__ | unless I initialize OSLRender right in do_pixel |
| 11:02.51 | *** join/#brlcad dli (~dli@67.55.33.66) | |
| 11:20.07 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 11:39.20 | *** join/#brlcad __name__ (~name@sburn/devel/name) | |
| 11:47.31 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 12:13.20 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 14:05.29 | *** join/#brlcad dli (~dli@66.49.183.65) | |
| 14:50.42 | brlcad | kunigami__: you could use the address of the struct resource in the application struct -- that is unique per process/thread |
| 15:12.05 | *** join/#brlcad mafm_ (~mafm@120.Red-83-42-153.dynamicIP.rima-tde.net) | |
| 16:47.47 | *** join/#brlcad __name__ (~name@chello080108038152.1.11.vie.surfer.at) | |
| 16:47.47 | *** join/#brlcad __name__ (~name@sburn/devel/name) | |
| 17:11.42 | __name__ | Hello! I've been reading your SOCIS projects and would be interested whether there are any tools of preference for the web applications (language, DB, whether it's supposed the be ajaxy, etc.) |
| 17:21.48 | CIA-62 | BRL-CAD: 03r_weiss * r45502 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 17:21.48 | CIA-62 | BRL-CAD: Updated the prototype version of function cut_unimonotone within file nmg_tri.c. |
| 17:21.48 | CIA-62 | BRL-CAD: This function supports the prototype version of function nmg_triangulate_fu. |
| 17:21.48 | CIA-62 | BRL-CAD: These prototype functions are disabled by default. This is a work is progress. |
| 17:21.48 | CIA-62 | BRL-CAD: Changed the test for an infinite loop and added more error checking. Also did |
| 17:21.49 | CIA-62 | BRL-CAD: code cleanup. |
| 18:11.18 | *** join/#brlcad name (~name@sburn/devel/name) | |
| 18:34.55 | brlcad | hello __name__ |
| 18:35.45 | brlcad | __name__: there isn't a strong preference, but something that works for most users, is easy to install and maintain, and does the job best |
| 18:36.16 | brlcad | current website is a drupal+mediawiki combo |
| 18:46.45 | *** join/#brlcad DarkCalff (DC@173.231.40.98) | |
| 18:48.44 | CIA-62 | BRL-CAD: 03erikgreenwald * r45503 10/brlcad/trunk/src/libged/edit.c: Clean up C90 warning on some compilers. |
| 19:12.08 | CIA-62 | BRL-CAD: 03r_weiss * r45504 10/brlcad/trunk/src/irprep/ (Compile.sgi Makefile.am): sgi files are gone in irprep - let the Makefile.am know about it. |
| 19:34.37 | *** join/#brlcad epileg (~epileg@188.119.210.222.dynamic.eurona.net) | |
| 19:34.41 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 19:40.22 | *** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ) | |
| 19:50.42 | brlcad | wootness |
| 20:35.14 | starseeker | brlcad: hmm? |
| 20:35.30 | __name__ | brlcad: Well you cannot really base a benchmark web-UI on either of those. |
| 21:08.37 | CIA-62 | BRL-CAD: 03r_weiss * r45505 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 21:08.37 | CIA-62 | BRL-CAD: Updated the prototype version of the function nmg_triangulate_fu within file |
| 21:08.37 | CIA-62 | BRL-CAD: nmg_tri.c. This function is disabled by default. This is a work is process. The |
| 21:08.37 | CIA-62 | BRL-CAD: majority of the changes were code cleanup. Added logic to prevent unnecessary |
| 21:08.37 | CIA-62 | BRL-CAD: processing of already triangulated faceuse. |
| 21:09.19 | CIA-62 | BRL-CAD: 03starseeker * r45506 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Clang likes to complain about unused command line arguments, and we don't really care. |
| 21:19.19 | starseeker | first crack at building BRL-CAD with clang/clang++ in XCode 4: http://pastebin.mozilla.org/1272704 |
| 21:19.45 | brlcad | __name__: sure you could -- I could make plain html work too |
| 21:19.50 | brlcad | all in the design |
| 21:20.02 | brlcad | doesn't mean you're constrained to those, just saying what's already handy |
| 21:20.08 | starseeker | doesn't know enough about why those externs are there to know if they are still needed... |
| 21:20.09 | __name__ | brlcad: Doesn't sound like a good idea though. |
| 21:20.21 | brlcad | that's a different statement ;) |
| 21:20.31 | __name__ | (Generating pure HTML.) |
| 21:21.05 | brlcad | big difference between "cannot" and "not a good idea" ;) |
| 21:21.15 | __name__ | brlcad: Fair point. |
| 21:21.20 | brlcad | you have a windows build handy? |
| 21:21.29 | brlcad | sry, starseeker: http://pastebin.mozilla.org/1272704 |
| 21:21.38 | brlcad | bah .. starseeker: you have a windows build handy? |
| 21:23.13 | __name__ | brlcad: Anyway. I'd be happy to do the web-application (or any other not-too-physics-heavy task). |
| 21:24.12 | starseeker | brlcad: not at the moment - problem? |
| 21:24.13 | brlcad | starseeker: huh, interesting warnings .. apparently llvm thinks that declarations can shadow declarations |
| 21:24.34 | starseeker | liboptical isn't happy either: http://pastebin.mozilla.org/1272706 |
| 21:25.16 | brlcad | starseeker: the good news is that those are just duplicate decls and llvm can help weed them out |
| 21:25.49 | brlcad | just remove the redundant duplicate |
| 21:26.32 | brlcad | starseeker: and no, not a problem -- I just have an implementation of fchmod() for Windows that will likely break the Windows build, need someone to test |
| 21:26.51 | starseeker | ah |
| 21:27.25 | starseeker | yeah, probably would take me at least an hour or so to kick my Windows build back into gear |
| 21:28.47 | CIA-62 | BRL-CAD: 03starseeker * r45507 10/brlcad/trunk/src/ (libfb/fb_generic.c librt/tcl.c): remove duplicate decls (XCode 4 clang no likie) |
| 21:28.54 | starseeker | bounces over to the Windows box... |
| 21:29.09 | starseeker | brlcad: whats the MFUNCS thing all about? |
| 21:29.31 | brlcad | hold a sec, looking |
| 21:31.26 | CIA-62 | BRL-CAD: 03brlcad * r45508 10/brlcad/trunk/src/libbu/fchmod.c: |
| 21:31.26 | CIA-62 | BRL-CAD: implement fchmod() for Windows. this will likely break the Windows build, but |
| 21:31.26 | CIA-62 | BRL-CAD: committing it since the only issue should be minor header and preprocessor |
| 21:31.26 | CIA-62 | BRL-CAD: symbolage. in order to implement fchmod on Windows, we rely on chmod() instead |
| 21:31.26 | CIA-62 | BRL-CAD: which is available but requires a filename. this is normally not knowable, but |
| 21:31.27 | CIA-62 | BRL-CAD: windows provides a roundabout way to get it, so run with it. |
| 21:42.57 | CIA-62 | BRL-CAD: 03starseeker * r45509 10/brlcad/trunk/src/liboptical/sh_wood.c: duplicate declarations in sh_wood.c |
| 21:47.28 | CIA-62 | BRL-CAD: 03r_weiss * r45510 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 21:47.28 | CIA-62 | BRL-CAD: Updated the prototype function nmg_plot_fu within file nmg_tri.c. This function |
| 21:47.28 | CIA-62 | BRL-CAD: supports the prototype function nmg_triangulate_fu. These functions are disabled |
| 21:47.28 | CIA-62 | BRL-CAD: by default. This is a work in process. The changes were code cleanup. |
| 21:55.05 | CIA-62 | BRL-CAD: 03starseeker * r45511 10/brlcad/trunk/src/ (14 files in 10 dirs): Remove all non-liboptical shadowing warnings. |
| 22:00.01 | starseeker | ah right, the optical/multispectral thing |
| 22:02.06 | CIA-62 | BRL-CAD: 03starseeker * r45512 10/brlcad/trunk/src/liboptical/init.c: |
| 22:02.06 | CIA-62 | BRL-CAD: Some of these MFUNCS are declared in the header for libmultispectral - for |
| 22:02.06 | CIA-62 | BRL-CAD: those, don't do the extern struct part of the original MFUNCS macro. Add a |
| 22:02.06 | CIA-62 | BRL-CAD: DMFUNCS macro for both the extern and the mlib_add shader call, and make MFUNCS |
| 22:02.06 | CIA-62 | BRL-CAD: just do the mlib_add_shader bit. |
| 22:04.04 | CIA-62 | BRL-CAD: 03starseeker * r45513 10/brlcad/trunk/src/fbed/fbed.c: f_Stop doesn't take any arguments |
| 22:07.46 | CIA-62 | BRL-CAD: 03starseeker * r45514 10/brlcad/trunk/src/libmultispectral/init.c: Same trick for libmultispectral as for liboptical. |
| 22:09.08 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 22:10.57 | CIA-62 | BRL-CAD: 03starseeker * r45515 10/brlcad/trunk/src/gtools/beset/population.c: resp was unused here? Not really sure what the intent of that statement was. |
| 22:11.47 | CIA-62 | BRL-CAD: 03starseeker * r45516 10/brlcad/trunk/src/rt/ (viewarea.c viewfrac.c viewpp.c): Some more duplicate declarations. |
| 22:13.38 | brlcad | starseeker: MFUNCS is how each shader is registered with liboptical |
| 22:13.53 | CIA-62 | BRL-CAD: 03starseeker * r45517 10/brlcad/trunk/src/lgt/do_options.c: More functions that don't take any arguments. |
| 22:14.26 | brlcad | the problem is that a few shaders might have to be declared for libmultispectral, so some are declared in optical.h |
| 22:14.56 | starseeker | brlcad: right - I had forgotten about that, something I think from the Windows build |
| 22:14.59 | starseeker | I got is straight |
| 22:15.17 | brlcad | they shouldn't need to be declared in optical.h |
| 22:15.21 | starseeker | Woot! clang build with XCode 4 finished |
| 22:15.30 | brlcad | sort of breaks the whole modularity DRY principle |
| 22:17.42 | brlcad | pretty cool, yay for portability |
| 22:18.08 | starseeker | brlcad: what was the intent of that bset/population.c line I wonder? |
| 22:29.50 | brlcad | I don't see a beset line |
| 22:34.05 | starseeker | r45515 |
| 22:34.32 | starseeker | svn diff -r45514:45515 |
| 22:40.52 | starseeker | Ouch |
| 22:40.59 | starseeker | benchmark results: |
| 22:41.07 | starseeker | clang vgr: 13540 |
| 22:41.21 | starseeker | gcc vgr: 14944 |
| 22:41.30 | starseeker | (debug builds in both cases) |
| 22:47.05 | ``Erik | optimized? |
| 22:47.12 | starseeker | ``Erik: working on it now |
| 22:49.14 | starseeker | brlcad: fchmod.c Windows build failures: http://pastebin.mozilla.org/1272750 |
| 23:03.53 | CIA-62 | BRL-CAD: 03starseeker * r45518 10/brlcad/trunk/src/mged/utility1.c: clang is reporting these as unused. Looks like this is part of the stuff that has moved to libged - nuke. |
| 23:16.46 | starseeker | gcc vgr (optimized): 33425 |
| 23:18.01 | starseeker | can already tell the clang results will be slower |
| 23:20.45 | *** join/#brlcad webmaster (~webmaster@93-152-34-168.xln.managedbroadband.co.uk) | |
| 23:30.26 | starseeker | clang vgr (optimized): 30409 |
| 23:30.56 | starseeker | sigh. Oh, well - at least it's a useful tool for debugging - I like the error messages |
| 02:00.11 | CIA-62 | BRL-CAD: 03bhinesley * r45519 10/brlcad/trunk/src/libged/edit.c: (log message trimmed) |
| 02:00.11 | CIA-62 | BRL-CAD: Changed the way that commands are added/stored, to use an array of structs |
| 02:00.11 | CIA-62 | BRL-CAD: similar to other command lists in BRL-CAD; much better. Set up ged_edit so that |
| 02:00.11 | CIA-62 | BRL-CAD: it behaves like a wrapper when the command name is not a ged_edit subcommand. |
| 02:00.11 | CIA-62 | BRL-CAD: Otherwise, when the command name is a ged_edit subcommand, it behaves as if it |
| 02:00.11 | CIA-62 | BRL-CAD: were the only command available. The syntax for some of the subcommands is |
| 02:00.11 | CIA-62 | BRL-CAD: pretty intense, so I also implemented a help system that displays the expanded |
| 03:59.48 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 03:59.48 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 being tagged today (20110701) || BRL-CAD has applied to participate in the ESA Summer of Code in Space! | |
| 04:00.56 | CIA-62 | BRL-CAD: 03brlcad * r45520 10/brlcad/trunk/src/libbu/fchmod.c: fix a variety of minor build issues that came up during compilation testing. thanks starseeker! |
| 04:02.48 | brlcad | starseeker: ah, that resp just looks like a typo. probably never noticed because it's doesn't affect anything. |
| 04:03.22 | brlcad | resp is a resource pointer, so probably was being typed to get passed to some function |
| 04:58.26 | *** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ) | |
| 06:15.10 | *** join/#brlcad Stattrav (~Stattrav@117.192.148.223) | |
| 06:15.10 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:20.19 | starseeker | brlcad: do you recall what the issue was with using "package require Itcl" instead of the C api? |
| 06:21.02 | starseeker | I'd really like to get that straight so I don't have to muck up the src/other build logic for the system tcl/tk local itcl/itk case... |
| 06:40.47 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.139.74) | |
| 06:45.48 | *** join/#brlcad Stattrav (~Stattrav@117.202.31.116) | |
| 06:45.48 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:11.38 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.154.180) | |
| 08:23.48 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 10:08.01 | *** join/#brlcad dli (~dli@66.49.183.65) | |
| 10:31.16 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 10:42.16 | CIA-62 | BRL-CAD: 03brlcad * r45521 10/brlcad/trunk/ (5 files in 2 dirs): renamed stat.c to file.c in order to reflect the API supporting more than determining whether a file exists and stat-style permissions info. |
| 10:44.20 | CIA-62 | BRL-CAD: 03brlcad * r45522 10/brlcad/trunk/src/libbu/file.c: don't need _bu_ prefix on HIDDEN funcs, use file prefix. |
| 10:47.22 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) | |
| 10:47.22 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:48.29 | brlcad | starseeker: I do not recall other than it being related to packages being rather mucked up with double inclusions and runtime failures |
| 10:50.07 | brlcad | I don't think the problem is understood well enough at this point given it seems to only either work with autotools or cmake build but not both as a package require .. something isn't right |
| 10:51.33 | brlcad | given a choice between always failing autotools and sometimes failing cmake with the right build options, we'll still need to keep both working until the deprecation timeframe is over |
| 10:53.05 | brlcad | the underlying issue needs to be understood, should be working for both build systems (*especially* the package require approach, that's why it has fewer warm fuzzies that it's right) |
| 11:06.12 | ``Erik | hm, xcode4 still requires a an ios/mac paid dev acct :/ |
| 12:19.17 | *** join/#brlcad KimK_afk (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 12:27.07 | *** join/#brlcad name (~name@chello080108038152.1.11.vie.surfer.at) | |
| 12:27.07 | *** join/#brlcad name (~name@sburn/devel/name) | |
| 13:18.25 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) | |
| 13:18.25 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:23.41 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 15:11.57 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 15:33.41 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 17:00.49 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 19:59.38 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 20:16.37 | *** join/#brlcad Stattrav (~Stattrav@117.192.133.54) | |
| 20:16.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:39.44 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.136.248) | |
| 20:55.43 | *** join/#brlcad Stattrav (~Stattrav@117.192.136.210) | |
| 20:55.43 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 23:48.14 | *** part/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 01:53.12 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 02:36.30 | *** join/#brlcad __name__ (~name@bitsrc.org) | |
| 04:42.03 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 10:07.22 | *** join/#brlcad merzo (~merzo@165-40-132-95.pool.ukrtel.net) | |
| 10:09.50 | *** join/#brlcad merzo (~merzo@165-40-132-95.pool.ukrtel.net) | |
| 10:18.59 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 10:42.14 | merzo | I'm trying to get sources via svn but get an error: |
| 10:42.17 | merzo | Checksum mismatch: src/other/tkimg/Makefile.am |
| 10:42.17 | merzo | expected: daed4d060f148304dad5b5f7bba69966 |
| 10:42.17 | merzo | <PROTECTED> |
| 10:42.25 | merzo | on revision 30755 |
| 10:45.36 | merzo | guys how to solve it? |
| 10:51.15 | merzo | probably I can ignore this broken revision? |
| 11:07.48 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) | |
| 11:07.48 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:15.12 | *** join/#brlcad __name__ (~name@sburn/devel/name) | |
| 12:17.02 | *** join/#brlcad __name__ (~name@sburn/devel/name) | |
| 12:57.49 | brlcad | merzo: what is your checkout line? |
| 12:58.02 | brlcad | suggest just "try again", maybe some network hiccup |
| 13:02.22 | brlcad | http://stackoverflow.com/questions/6130/repair-svn-checksum |
| 13:02.36 | brlcad | basically you can rm -rf src/other/tkimg then svn update again, should work |
| 13:26.39 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 13:54.07 | ``Erik | huh, this X install has variatic macros in the X headers, causing libdm to fail due to iso strictness |
| 14:35.07 | *** join/#brlcad merzo (~merzo@37-236-132-95.pool.ukrtel.net) | |
| 17:53.10 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 17:58.56 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 23:33.44 | CIA-62 | BRL-CAD: 03brlcad * r45523 10/brlcad/trunk/include/optical.h: |
| 23:33.44 | CIA-62 | BRL-CAD: FIXME, should not need to declare all liboptical shaders used by |
| 23:33.44 | CIA-62 | BRL-CAD: libmultispectral. in theory, multispectral can use all of them and having to |
| 23:33.44 | CIA-62 | BRL-CAD: list shaders in three places really sucks. could give multispectral a prefix or |
| 23:33.44 | CIA-62 | BRL-CAD: suffix so it's a different var, but they shouldn't even be globals. |
| 00:49.38 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 01:23.33 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 03:06.57 | brlcad | FYI, we're now within a sagonet maintenance window for the next 6 hours |
| 03:07.25 | brlcad | sry, next 7 hours (till 6am edt) |
| 03:07.35 | brlcad | downtime shouldn't exceed 20min, but will be any time in that window |
| 03:08.00 | brlcad | rack in datacenter is being moved |
| 03:47.22 | brlcad | starseeker: where are the functions listed in configure.ac, section 7, getting checked in the CMake build logic? can't find them |
| 04:04.51 | brlcad | hope the answer isn't what it's looking like ... that'd be a lot of useful functionality falling back to dumb defaults |
| 05:03.05 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 05:58.34 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) | |
| 05:58.34 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:14.17 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 07:20.06 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:24.46 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 11:05.18 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 11:25.40 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 14:45.13 | CIA-62 | BRL-CAD: 03brlcad * r45524 10/brlcad/trunk/BUGS: |
| 14:45.13 | CIA-62 | BRL-CAD: rt run from within mged (and probably also within archer, but untested) doesn't |
| 14:45.13 | CIA-62 | BRL-CAD: output anything other than the final success/failure message from libged. |
| 14:45.13 | CIA-62 | BRL-CAD: something is suppressing all output, which doesn't seem to have been intentional |
| 14:45.13 | CIA-62 | BRL-CAD: (undocumented). |
| 14:58.33 | brlcad | heh, new server was rebooted, but apparently the firewall was turned on (without any rules, defaulting to block everything) |
| 15:02.02 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 15:03.58 | ``Erik | I was able to log into it about 20 minutes ago O.o |
| 15:04.26 | ``Erik | sure ya got the right IP? a lot of stuff pointing to the 'new' server is pointing to the 'old' 'new' server, like the crit domain name |
| 15:06.11 | ``Erik | (or was that fixed before I logged in at 10:41?) |
| 15:09.44 | brlcad | I got it fixed a couple hours ago |
| 15:09.54 | brlcad | ipfw is turned off at the moment |
| 15:12.04 | ``Erik | I think I tried to set up the auto-deny script you had, I may've munged it up |
| 15:12.10 | ``Erik | was a while back *shrug* |
| 15:12.14 | brlcad | np |
| 15:13.10 | ``Erik | with the reboots, might be prime time to expediate the migration |
| 15:13.37 | brlcad | i've been actively trying for some time now |
| 15:15.31 | brlcad | thinks brep plot just might be stuck in an infinite loop... been trying to plot an 800-object model for over an hour now |
| 15:16.01 | ``Erik | I think I've installed all the right ports, it's the config that might need work *shrug* you have some businesses using it and I don't want to risk their revenue *shrug* :) |
| 15:16.23 | ``Erik | shrugs himself to the kitchen to do some dishes |
| 15:16.29 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 15:29.59 | ``Erik | HAH, apple releases an ios update to prevent jailbreaking and it's broken almost immediately, only a 12hr gap in the slapsnot stories, nice |
| 15:42.15 | louipc | jajajaja |
| 15:45.18 | ``Erik | nice spin, the update notes say "Fixes security vulnerability associated with viewing malicious PDF files." |
| 15:45.42 | ``Erik | (the jailbreak uses a flaw in the pdf render stack) |
| 15:45.49 | starseeker | brlcad: Um - do you mean the AC_CHECK_FUNCS list on line 4506 of configure.ac? |
| 15:46.29 | starseeker | correction, line 2262 |
| 15:46.54 | starseeker | similar tests are in CMakeLists.txt starting at line 1096 |
| 15:49.21 | ``Erik | hm, liboptical throws a slew of warnings, %d fed an int instead of a long int |
| 16:26.54 | brlcad | starseeker: aha! thanks ... I'd grepped down the source tree and into misc/ but apparently not the top-level CMakeLists.txt file |
| 16:27.38 | brlcad | do think this brep plot is in an inf loop .. damn |
| 16:34.14 | starseeker | crud - it is a debug build? |
| 16:35.04 | brlcad | should be |
| 16:35.54 | brlcad | could also just be insancely slow, but it's been 2-3 hours |
| 16:36.37 | brlcad | http://pastebin.mozilla.org/1274946 |
| 16:42.45 | brlcad | lets it keep churning for now |
| 16:43.29 | brlcad | stack does keep changing, at least up to plot_BBNode, so if it's an inf loop, it's fairly complex or at the plot_BBNode level |
| 16:49.39 | starseeker | yipe |
| 16:55.44 | CIA-62 | BRL-CAD: 03starseeker * r45525 10/geomcore/trunk/CMake/FindCppUnit.cmake: Don't use FATAL_ERROR when checking for CppUnit - it's not essential. |
| 17:12.14 | ``Erik | mac? fbsd? attach pid to process to see what it's doing? |
| 17:12.30 | ``Erik | shark, truss, uh, I think linux strace or ktrace may do something |
| 17:12.39 | brlcad | nifty, rt crash on nurbs raytrace |
| 17:13.04 | ``Erik | or winderz, attach msvc debugger to process, pheer |
| 17:13.12 | brlcad | that is attached, did watch .. hence my comments about the "stack does keep changing" |
| 17:13.35 | ``Erik | aight, then it's doing something, but could be an infinite loop *shrug* |
| 17:14.00 | ``Erik | stop occasionally and record the stack dump? |
| 17:14.12 | brlcad | of course |
| 17:14.12 | ``Erik | if they don't change, it might be infinite |
| 17:14.27 | brlcad | blinks |
| 17:14.33 | brlcad | I feel like a broken record |
| 17:14.41 | ``Erik | srry, just got back from exercising and showering, brain isn't quite right |
| 17:14.57 | ``Erik | <-- playing the captain obvious role, it usually helps *shrug* :) |
| 17:14.57 | brlcad | exerwhaat? you okay? |
| 17:15.16 | brlcad | hit you head and stumble into the gym by accident? |
| 17:15.27 | ``Erik | nah, walking/jogging a trail in the heat |
| 17:15.48 | ``Erik | ya sure it's plugged into the wall? is the power on? :> |
| 17:16.42 | ``Erik | an infinite loop in the opennurbs stuff would be an interesting find, indianlarry is pretty good at what he does and I doubt the originators would not have noticed such a thing |
| 17:17.09 | ``Erik | slow, yes, infinite... not highly probable |
| 17:19.22 | ``Erik | brlcad: is MoRe the right place to dump works in progress for critique? |
| 17:20.43 | ``Erik | hah, guess they're moving that rack now |
| 17:21.11 | CIA-62 | BRL-CAD: 03starseeker * r45526 10/geomcore/trunk/tests/func/GE/CMakeLists.txt: Hmm - don't think we need CPPUNIT_INCLUDE_DIR here? Not in unit directory in any case... |
| 17:27.33 | CIA-62 | BRL-CAD: 03starseeker * r45527 10/geomcore/trunk/tests/func/svntest/main.c: Sync up with macro API cleanup in r45032 |
| 17:37.45 | *** join/#brlcad Stattrav (~Stattrav@117.202.20.234) | |
| 17:37.45 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:42.41 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 18:32.35 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 18:32.48 | brlcad | looks like sagonet borked a router |
| 18:33.32 | brlcad | maybe someone kicked the power cord right as you were mentioning it, otherwise, last msg received was 13:17 local |
| 18:34.07 | brlcad | I've narrowed it down to a single brep primitive .. looking very likely that it's infinite |
| 18:44.53 | *** join/#brlcad Stattrav_ (~Stattrav@117.202.20.234) | |
| 18:49.04 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:11.17 | *** join/#brlcad Stattrav (~Stattrav@117.202.20.234) | |
| 19:11.17 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:18.59 | *** join/#brlcad Stattrav (~Stattrav@117.202.20.234) | |
| 19:19.00 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:26.23 | *** join/#brlcad Stattrav (~Stattrav@117.202.20.234) | |
| 19:26.23 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:32.59 | *** join/#brlcad Stattrav (~Stattrav@117.202.20.234) | |
| 19:32.59 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:49.07 | *** join/#brlcad Stattrav (~Stattrav@117.202.20.234) | |
| 19:49.07 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:00.18 | *** join/#brlcad yaadam (~chatzilla@188.147.8.128.nat.umts.dynamic.t-mobile.pl) | |
| 20:02.26 | *** join/#brlcad yaadam (~chatzilla@188.147.8.128.nat.umts.dynamic.t-mobile.pl) | |
| 20:03.18 | yaadam | What, about list of accept Logo BrlCAD ? |
| 20:06.11 | yaadam | I want to :-D see a gallery work of logo - I send a one. |
| 20:09.19 | yaadam | Or just you wait to deadline of logo Competition? |
| 20:09.35 | yaadam | And then show all send work? |
| 20:09.42 | yaadam | right :-) ? |
| 20:13.22 | CIA-62 | BRL-CAD: 03kunigami * r45528 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h sh_osl.cpp): added support to multi-thread using the OSL cocept of thread_info (hope I get it right :P) preliminary tests show a decrease in the time needed to render an example image when going from 1 to 2 processors |
| 20:23.39 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r3011 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */ added report for last week |
| 20:23.59 | CIA-62 | BRL-CAD: 03bhinesley * r45529 10/brlcad/trunk/src/libged/edit.c: comment detailing how ged_edit will handle standardized and unique (unrecognized) subcommand options/args in a generic way, without requiring changes when a new command is added. Spellchecked file. |
| 20:55.35 | CIA-62 | BRL-CAD: 03bhinesley * r45530 10/brlcad/trunk/include/bu.h: typo |
| 21:20.01 | brlcad | patience yaadam |
| 21:21.54 | kunigami_ | seems he didn't have patience even to wait for a response :) |
| 21:23.10 | *** join/#brlcad yaadam (~chatzilla@188.147.8.128.nat.umts.dynamic.t-mobile.pl) | |
| 21:23.29 | CIA-62 | BRL-CAD: 03r_weiss * r45531 10/brlcad/trunk/src/libbn/plane.c: |
| 21:23.29 | CIA-62 | BRL-CAD: Created a new prototype version of function bn_isect_line_lseg in the libbn |
| 21:23.29 | CIA-62 | BRL-CAD: library within file plane.c. This new version is disabled by default and exists |
| 21:23.29 | CIA-62 | BRL-CAD: to support the prototype version of nmg_triangulate_fu. The changes to this |
| 21:23.29 | CIA-62 | BRL-CAD: function were necessary to process the output from the prototype function |
| 21:23.30 | CIA-62 | BRL-CAD: bn_isect_line3_line3_new. This is a work in progress. |
| 21:37.10 | CIA-62 | BRL-CAD: 03brlcad * r45532 10/brlcad/trunk/ (NEWS src/librt/opennurbs_ext.h): |
| 21:37.10 | CIA-62 | BRL-CAD: fixed a bug in NURBS plot where it was getting stuck in an infinite loop due to |
| 21:37.10 | CIA-62 | BRL-CAD: hitting an edge case where our v estimate for a given u was _exactly_ hitting |
| 21:37.10 | CIA-62 | BRL-CAD: the test point causing subsequent tests to repeatedly test the same point over |
| 21:37.10 | CIA-62 | BRL-CAD: and over. this edge case is actually a happy done-with-function case so we can |
| 21:37.10 | CIA-62 | BRL-CAD: just return the precise v value. |
| 21:40.27 | CIA-62 | BRL-CAD: 03brlcad * r45533 10/brlcad/trunk/src/librt/opennurbs_ext.h: add another subtle change in case the == case ever gets removed, swap the logic so that the <= case will cause the comparison to clamp correctly to the singular point (and further prevent the inf loop). |
| 22:00.47 | *** join/#brlcad yAdam (~chatzilla@178.180.65.32.nat.umts.dynamic.t-mobile.pl) | |
| 22:12.26 | CIA-62 | BRL-CAD: 03kunigami * r45534 10/brlcad/trunk/src/liboptical/init.c: osl_mfuncs should be included on DMFUNCS too |
| 22:27.18 | *** join/#brlcad yAdam (~chatzilla@178.180.65.32.nat.umts.dynamic.t-mobile.pl) | |
| 22:56.18 | *** part/#brlcad yAdam (~chatzilla@178.180.65.32.nat.umts.dynamic.t-mobile.pl) | |
| 01:44.54 | CIA-62 | BRL-CAD: 03kunigami * r45535 10/brlcad/trunk/src/other/ (4 files in 3 dirs): Added cmakefile to compile the .osl shaders into .oso ones. This is done only if the OSL flag is enabled |
| 02:03.23 | CIA-62 | BRL-CAD: 03kunigami * r45536 10/brlcad/trunk/src/liboptical/sh_osl.cpp: changed sh_osl to read shaders from ../shaders instead of ./ |
| 02:17.17 | CIA-62 | BRL-CAD: 03bhinesley * r45537 10/brlcad/trunk/src/libged/edit.c: adding generic subargument handling to ged_edit; it's a work in progress. incomplete sections are disabled |
| 02:30.37 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3012 10/wiki/User:Bhinesley: /* Log */ wrong month on a few dates |
| 02:33.00 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3013 10/wiki/User:Bhinesley: /* Log */ overwrote a couple dates last change |
| 02:53.22 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3014 10/wiki/User:Bhinesley: /* Log */ catching up |
| 03:04.46 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3015 10/wiki/User:Bhinesley: /* Log */ cross out completed items |
| 03:57.06 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 04:38.51 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 05:53.12 | *** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ) | |
| 07:14.06 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:57.17 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:34.05 | *** join/#brlcad yAdam (~chatzilla@188.147.179.132.nat.umts.dynamic.t-mobile.pl) | |
| 10:09.28 | *** join/#brlcad yAdam (~chatzilla@188.147.201.90.nat.umts.dynamic.t-mobile.pl) | |
| 10:15.46 | *** join/#brlcad yAdam (~chatzilla@188.147.201.90.nat.umts.dynamic.t-mobile.pl) | |
| 12:52.35 | *** join/#brlcad yAdam (~chatzilla@188.146.24.10.nat.umts.dynamic.t-mobile.pl) | |
| 13:03.29 | *** part/#brlcad yAdam (~chatzilla@188.146.24.10.nat.umts.dynamic.t-mobile.pl) | |
| 13:20.35 | CIA-62 | BRL-CAD: 03erikgreenwald * r45538 10/brlcad/trunk/src/libged/edit.c: #if0 some unused funcs marked HIDDEN, causes compile failure when debugging is disabled |
| 13:41.09 | CIA-62 | BRL-CAD: 03brlcad * r45539 10/brlcad/trunk/ (include/bu.h src/libbu/file.c): |
| 13:41.09 | CIA-62 | BRL-CAD: initial implementation of bu_file_delete() for removing files. performs a |
| 13:41.09 | CIA-62 | BRL-CAD: simple remove() but then will try harder by relaxing the file permissions on a |
| 13:41.09 | CIA-62 | BRL-CAD: second pass attempt if the first fails. untested on windows but remove() is c90 |
| 13:41.09 | CIA-62 | BRL-CAD: so we should be able to rely on it. callers will just have to make sure the |
| 13:41.10 | CIA-62 | BRL-CAD: file isn't opened. |
| 13:49.45 | *** join/#brlcad yAdam (~chatzilla@188.146.24.10.nat.umts.dynamic.t-mobile.pl) | |
| 13:49.58 | *** part/#brlcad yAdam (~chatzilla@188.146.24.10.nat.umts.dynamic.t-mobile.pl) | |
| 14:16.51 | *** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || | |
| 14:16.58 | brlcad | bah |
| 14:17.34 | *** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 14:17.58 | brlcad | all orgs get just one slot |
| 14:18.48 | __name__ | shouldn't this have been announced yesterday? |
| 14:19.56 | brlcad | they were a little late due to more submissions than they anticipated |
| 14:20.17 | brlcad | it was just announced a little bit ago |
| 14:22.09 | __name__ | Their FAQ still are not complete either. |
| 14:24.37 | brlcad | is a faq ever complete? |
| 14:24.52 | __name__ | They have questions without answers isted. |
| 14:24.55 | brlcad | unless you define the frequency, there will always be someone with a question |
| 14:24.55 | __name__ | *listed even |
| 14:25.01 | brlcad | ah, meh |
| 14:25.03 | brlcad | not really concerning -- they're pretty closely mirrored after gsoc |
| 14:25.21 | brlcad | limited time and resources, building it up as they go .. it is a pilot program after all |
| 14:25.40 | brlcad | any info is a plus, the whole thing could be done over private e-mail exchanges |
| 14:25.41 | __name__ | Yeah. |
| 14:25.54 | brlcad | or (shudder) phone calls |
| 14:26.34 | brlcad | I'm impressed they got 20 slots funded by their management |
| 14:27.02 | brlcad | roughly 100-200k pilot |
| 14:28.00 | ``Erik | heh, a faq with no answers would be awesome "look, it's a faq, not an atfaq! just the questions!" :D |
| 14:29.16 | __name__ | Hah |
| 14:33.33 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 15:10.02 | bhinesley | ``Erik: I wonder why it doesn't fail for me when there are unused functions... I have debugging enabled |
| 15:10.37 | bhinesley | I don't even get a warning |
| 15:11.41 | bhinesley | smacks self awake |
| 15:12.22 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:05.21 | brlcad | bhinesley: different versions of the same compiler will report different warnings, plus other compilation settings (such as optimized) can affect warnings |
| 16:07.46 | bhinesley | do you always build with strict on? It never works for me |
| 16:07.58 | ``Erik | with debugging OFF, the NDEBUG flag gets set, which turns HIDDEN into "static", otherwise it's defined as /* */ |
| 16:08.24 | ``Erik | that's where that issue came from |
| 16:08.52 | bhinesley | hmm |
| 16:11.09 | bhinesley | the question I really mean to ask is: what should I be doing differently, so that you guys don't have to follow me around to clean up my mess? :) |
| 16:11.27 | ``Erik | stop making a mess? :D |
| 16:11.51 | bhinesley | I have to figure out how to identify a mess first |
| 16:11.54 | ``Erik | I like to have a 'build' directory with several subdirs for different configurations to spot those |
| 16:12.47 | bhinesley | okay, so you build with various options as a matter of course |
| 16:13.37 | ``Erik | yeah, and a variety of os/arch's, to boot |
| 16:14.35 | bhinesley | ok |
| 16:21.27 | brlcad | bhinesley: strict should always work -- if it doesn't, that's something that needs to be addressed |
| 16:21.48 | brlcad | should be building with strict enabled |
| 16:22.20 | brlcad | debug enabled and strict enabled -- optimized can be on or off |
| 16:23.22 | bhinesley | there are thousands upon thousands of warnings... I'm guessing that only certain types are treated as errors |
| 16:23.26 | bhinesley | ? |
| 16:24.13 | bhinesley | I will take a look at what is stopping me from building strict |
| 16:35.24 | brlcad | what are the first few? |
| 16:35.48 | brlcad | i'm guessing that it's something like printf specifier conversions |
| 16:38.04 | *** join/#brlcad Stattrav (~Stattrav@117.192.157.143) | |
| 16:38.04 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:54.02 | *** join/#brlcad alex_jon1 (~alex_joni@81.196.65.201) | |
| 16:59.28 | bhinesley | brlcad: lots of printf specifier conversions, yes. Also, a lot of variables not set or not used (these are stopping me from building strict). |
| 16:59.43 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 17:01.57 | brlcad | bhinesley: what os and version of gcc? |
| 17:02.03 | brlcad | and cmake or autotools build? |
| 17:02.35 | brlcad | if you can produce a full build log, I can look into whether there is a categoric fix |
| 17:03.03 | bhinesley | Fedora 15, gcc 4.6.0 20110530, cmake |
| 17:03.08 | brlcad | I suspect you're just using a version of gcc newer than everyone else or on a curious platform with odd 32-bit/64-bit size mixtures |
| 17:03.17 | bhinesley | 64-bit |
| 17:03.23 | brlcad | definitely a pretty new gcc |
| 17:04.21 | brlcad | make -k 2>&1 | tee build.log |
| 17:05.01 | ``Erik | installs gcc47 on crit O.o |
| 17:05.19 | bhinesley | Okay, I'm running that. It seems that the unused variables are primarily what is preventing build, so I'll see how far the rabbit hole goes in the meantime. |
| 17:06.59 | bhinesley | a lot of "{int ret; ret = somefunction();}" -> "{(void)somefunction();}" |
| 17:13.33 | bhinesley | http://db.tt/rITDTCH |
| 17:13.54 | bhinesley | brlcad ^ build log |
| 17:18.31 | CIA-62 | BRL-CAD: 03bhinesley * r45540 10/brlcad/trunk/src/libbu/ (bomb.c crashreport.c): removed unused variables and quiet compiler |
| 17:20.23 | bhinesley | more complex to fix: http://pastebin.mozilla.org/1276121 |
| 17:21.11 | bhinesley | I'm assuming we want to keep BU_LIST_APPEND's BU_ASSERT's |
| 17:27.52 | CIA-62 | BRL-CAD: 03bhinesley * r45541 10/brlcad/trunk/src/libbu/vlb.c: remove unused variable missed last commit |
| 17:32.20 | bhinesley | very quietly disables strict and goes back to work for now |
| 17:50.20 | brlcad | bhinesley: don't go too far down that route |
| 17:50.56 | brlcad | functions like read()/write() will thrown warnings with different versions of the compiler if you cast the return to (void) |
| 17:51.10 | bhinesley | ah |
| 17:51.35 | brlcad | the fact that the return value is being stashed in a var was to quiet earlier warnings |
| 17:51.46 | bhinesley | alright, I'll revert |
| 17:52.30 | brlcad | note that r45540 unveils two issues |
| 17:53.07 | brlcad | fwrite doesn't return an int, it returns a size_t |
| 17:54.43 | bhinesley | okay, so I'll fix it |
| 17:54.45 | brlcad | write and fwrite return values are compared against the number of values written, write is an int, fwrite a size_t, both if (ret != nvals) perror("fwrite/write failed"); |
| 17:55.14 | brlcad | just calling perror() preserves current behavior, just printing the issue |
| 17:55.51 | brlcad | (as a two-liner, not one-liner) |
| 17:57.15 | *** join/#brlcad merzo (~merzo@48-81-132-95.pool.ukrtel.net) | |
| 18:06.42 | *** join/#brlcad Stattrav (~Stattrav@117.192.157.143) | |
| 18:06.42 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:33.35 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 19:23.15 | CIA-62 | BRL-CAD: 03bhinesley * r45542 10/brlcad/trunk/src/libbu/ (bomb.c crashreport.c vlb.c): resolved issues regarding fwrite/write return value validation, unveiled by r45540/r45541 per conversation with Sean |
| 19:42.26 | *** join/#brlcad KimK_afk (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 19:46.08 | brlcad | bhinesley: thought you said there were thousands? |
| 19:46.29 | brlcad | only see a dozen or so files in your log |
| 19:56.57 | bhinesley | I must have different options set. I did a `wc` of lines containing "error" a couple weeks ago, and there were thousands. |
| 19:57.07 | bhinesley | er "warning" |
| 19:59.31 | bhinesley | that's how I found the 511 warnings that I fixed with r45238 |
| 20:00.02 | bhinesley | (all regarding printf specifiers) |
| 20:03.15 | bhinesley | anyways, it seems that I misunderstood the meaning of strict; I thought that *all* warnings were treated as errors. When I saw so many warnings, I assumed that compiling w/ strict was a goal, not a reality. Then I noticed that people were finding problems with my code a little too fast >.< |
| 20:06.22 | brlcad | yeah, nope .. you're just ahead of us with your fancy new compilerness ;) |
| 20:06.33 | bhinesley | hah |
| 20:06.45 | brlcad | suprised starseeker hadn't hit the issues on gentoo |
| 20:09.06 | CIA-62 | BRL-CAD: 03brlcad * r45543 10/brlcad/trunk/src/libbu/crashreport.c: quell warning on || && logic, wrap latter in parens |
| 20:15.08 | CIA-62 | BRL-CAD: 03128.63.32.74 07http://brlcad.org * r3016 10/wiki/Community_Publication_Portal: stub in ESA SOCIS announcement |
| 20:19.56 | CIA-62 | BRL-CAD: 03brlcad * r45544 10/brlcad/trunk/ (NEWS src/mged/mged.c src/mged/setup.c): now that the ged struct is fully initialized during ged_init(), it exposed a bug where code wasn't initializing the output handler properly after opening a database. this restores rt command output. |
| 20:47.30 | brlcad | starseeker: the csgbrep bomb is valid -- the arbn block creates an nmgmodel and tries to pass it forward as an rt_arbn_internal, so it bombs |
| 20:47.54 | brlcad | the magic check was probably what changed, no idea how it ever would have worked as it is now |
| 20:48.28 | brlcad | csgbrep.cpp:261 is where it goes wrong |
| 20:52.41 | CIA-62 | BRL-CAD: 03brlcad * r45545 10/brlcad/trunk/src/proc-db/csgbrep.cpp: |
| 20:52.41 | CIA-62 | BRL-CAD: looks like this is calling the wrong function table entry. it's setting an NMG |
| 20:52.41 | CIA-62 | BRL-CAD: as the object pointer, but was trying to call the ARBN functab. tripped a bomb |
| 20:52.41 | CIA-62 | BRL-CAD: magic detection. calling the NMG converter seems to work in a better non-crashy |
| 20:52.41 | CIA-62 | BRL-CAD: way. |
| 21:08.42 | starseeker | brlcad: ah, cool - thanks |
| 21:31.14 | *** join/#brlcad merzo (~merzo@48-81-132-95.pool.ukrtel.net) | |
| 21:31.56 | CIA-62 | BRL-CAD: 03kunigami * r45546 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h sh_osl.cpp): Added support for setting string parameters to OSL shaders |
| 21:41.03 | CIA-62 | BRL-CAD: 03Intmiti 07http://brlcad.org * r3017 10/wiki/Videopoker_is_definately_the_best_casino_games: New page: look for for online casinos on [http://www.google.com Google] |
| 21:41.55 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 22:03.48 | CIA-62 | BRL-CAD: 03bhinesley * r45547 10/brlcad/trunk/src/libged/edit.c: change a labeled block to a private function |
| 22:27.16 | *** join/#brlcad merzo (~merzo@48-81-132-95.pool.ukrtel.net) | |
| 22:48.17 | CIA-62 | BRL-CAD: 03Antlipi 07http://www.solidgeometry.org * r3018 10/wiki/Blackjack_is_without_any_doubts_the_best_casino_games: New page: look for for ambling on [http://www.google.com Google] |
| 23:14.21 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Antlipi]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 23:14.24 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Blackjack is without any doubts the best casino games]]": content was: 'look for for ambling on [http://www.google.com Google]' (and the only contributor was '[[Special:Contributions/Antlipi|Antlipi]]') |
| 23:14.28 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Intmiti]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 23:14.33 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Videopoker is definately the best casino games]]": content was: 'look for for online casinos on [http://www.google.com Google]' (and the only contributor was '[[Special:Contributions/Intmiti|Intmiti]]') |
| 23:24.26 | CIA-62 | BRL-CAD: 03kunigami * r45548 10/brlcad/trunk/src/other/osl/shaders/ (converter.osl sh_texture.osl): texture shader. this one was pretty straightforward since there's already an implemented internal function |
| 23:25.09 | kunigami_ | Testing the texture shader: http://dl.dropbox.com/u/1399996/GSoC/osl_texture.png |
| 23:39.04 | brlcad | heh, nifty |
| 23:39.22 | brlcad | what happened to the light source, though? |
| 23:40.26 | brlcad | illuminating the left corner but not the right just from the reflective box? if so, seems like there's some energy loss (I'd expect it to be brighter given previous images) |
| 23:51.14 | kunigami_ | brlcad: in previous images I was multiplying the colors by a factor of 2 or 3 because the scene was too dark. Now I'm just using a very very bright light. I'm not sure if that's the cause of difference |
| 23:51.30 | brlcad | kunigami_: so you mentioned earlier that you have to hypersample 1000 times .. that just sounds wrong for many reasons.. how is hypersampling being used? |
| 23:53.01 | kunigami_ | the image above was hypersamples 1000 times too. I'm just using -H 1000 -J3 |
| 23:53.13 | brlcad | should work without any hypersampling, just perhaps not as well converged global light (e.g., corners not quite as dark as they should be) |
| 23:53.25 | brlcad | right, but .. why? :) |
| 23:53.38 | brlcad | what does non -H1000 look like? |
| 23:55.22 | kunigami_ | brlcad: http://dl.dropbox.com/u/1399996/GSoC/no-hypersampling.png |
| 23:55.55 | brlcad | so can you explain that? |
| 23:56.43 | brlcad | every pixel has a ray being fired, so why wouldn't they all return a color for a primary hit? |
| 23:57.07 | kunigami_ | the osl system returns a random reflection direction everytime I make a query (biased depending on the shader), so it's necessary |
| 23:57.19 | ``Erik | -H only effects the primary ray, didn't the path tracer and photon mapper twingy did get a HUGE benefit by multiplying secondaries instead of primaries? |
| 23:57.24 | kunigami_ | a large number of samples so the color converges |
| 23:58.58 | brlcad | kunigami_: returning a random reflection direction sounds like a controllable parameter though, no? |
| 23:59.41 | brlcad | it's the shader's job to determine whether there is reflection in the first place |
| 23:59.50 | kunigami_ | hm not sure. I'd have to find out |
| 00:00.23 | brlcad | unless you just happen to be using an osl shader that returns random reflections |
| 00:00.50 | brlcad | otherwise, it sounds like something they's just default to .. but isn't actually necessary -- should be able to converge much faster |
| 00:01.16 | brlcad | otherwise it sounds like it basically acting like a generalized path tracer |
| 00:01.28 | brlcad | otherwise ;) |
| 00:01.42 | kunigami_ | I think it's a path tracer |
| 00:01.53 | brlcad | it is and it isn't ;) |
| 00:02.02 | brlcad | isn't supposed to be a generalized shader system |
| 00:02.22 | brlcad | meaning you could use it as a path tracer or not |
| 00:02.42 | kunigami_ | hmm makes sense |
| 00:02.42 | brlcad | perhaps it just defaults to path tracing |
| 00:02.55 | ``Erik | accidental negative? it IS supposed to be generalized, no? so'z it can be path trace, radiosity, phong, etc |
| 00:03.26 | brlcad | "isn't it supposed to be" |
| 00:04.06 | brlcad | or s/isn't/it's/ :) |
| 00:04.06 | ``Erik | ah, s/t/ t it/;s/$/?/ |
| 00:04.34 | kunigami_ | the thing is that I based my code in a example and maybe there it was implementing a path tracer |
| 00:05.00 | kunigami_ | I wasn't aware that this could be just a "mode" |
| 00:05.07 | ``Erik | kunigami: sounds so, is there a basic phong OSL script you can slap in there? that'd be a lot quicker on the tests and be a pretty close relative to the current 'default' of rt |
| 00:05.13 | brlcad | so then we (you) have some homework to figure out ;) |
| 00:06.04 | ``Erik | would think pixdiffs of the current C phong/plastic vs the OSL phong would be interesting |
| 00:06.23 | brlcad | for starters, making sure you're working with rt from here forward, not a standalone so we make sure the integration migrations towards something production usable, even if it's the path tracer |
| 00:06.40 | brlcad | I don't think OSL ships phong by default |
| 00:07.22 | ``Erik | any guess on how difficult it'd be to write? I'd hope trivial... |
| 00:08.01 | brlcad | hm, mildly related discussion: http://groups.google.com/group/osl-dev/browse_thread/thread/3350532577b3f8b7/657b1956e545b5ba?lnk=raot |
| 00:08.30 | kunigami_ | I think there's a implementation of a phong shader, but if I remember well, it wasn't much different from the diffuse |
| 00:08.39 | kunigami_ | let me try here |
| 00:09.52 | brlcad | hates it when he searches for some topic like this and the top hits are our own irc log discussions |
| 00:10.35 | brlcad | so phong() is an OSL function |
| 00:10.45 | brlcad | along with cooktorrance() |
| 00:10.52 | brlcad | and a few others |
| 00:11.23 | ``Erik | ok, so we do have the theoretical opportunity for a 1:1 comparison of our own shader system vs osl |
| 00:11.57 | brlcad | still unclear how you drive the phong reflectance/specular rays |
| 00:13.10 | ``Erik | if push comes to shove, we SHOULD be able to re-implement our interpretation in osl, I'd hope? |
| 00:13.30 | brlcad | it's not that |
| 00:13.39 | brlcad | librt is still the one shooting rays and managing geometry |
| 00:13.55 | brlcad | so librt fires, hits an osl surface, calls into osl to figure out what to do |
| 00:14.01 | ``Erik | *shrug* either way, hasta luego, see ya'll tomorrie :) |
| 00:14.15 | brlcad | then it needs to fire more rays .. how it does that isn't clear to me |
| 00:15.41 | brlcad | this should be like a "chapter 1" or intro-to-osl detail spelled out somewhere |
| 00:18.28 | brlcad | aha, language spec talks about it somem |
| 00:19.04 | brlcad | "Effects that would ordinarily require explicit ray tracing, such as reflection and refraction, are simply part of the radiance closure and look like any other BSDF |
| 00:21.07 | brlcad | mm, getting the gist |
| 00:21.11 | brlcad | kunigami_: so I'll have to read through this some more tonight, but I think the first step is to not gang off the -H option since that fires multiple primary rays ... |
| 00:23.21 | brlcad | very expensive |
| 00:23.28 | brlcad | do something trivial like getenv(LIBRT_OSL_SAMPLES) instead of a command line option and use that parameter to toggle how many internal osl samples it needs to acquire per ray |
| 00:24.27 | brlcad | should shave massive amounts of time since it doesn't need to rewalk the spatial partitioning, and still give the same resulting picture |
| 00:25.17 | kunigami_ | ah I was just asking that. ok, so going back to my first implemented hypersampling |
| 00:25.34 | brlcad | we can tie it to command-line options later if it all gets working cleanly |
| 00:25.52 | brlcad | it *shouldn't* need to re-call rt_shootray() |
| 00:26.08 | brlcad | the ray hit is the same for 1 sample as it was for 1 million |
| 00:56.40 | CIA-62 | BRL-CAD: 03kunigami * r45549 10/brlcad/trunk/src/liboptical/sh_osl.cpp: |
| 00:56.40 | CIA-62 | BRL-CAD: added back hypersampling right on sh_osl instead of using the -H parameter. It's |
| 00:56.40 | CIA-62 | BRL-CAD: much less expensive since we dont need to re-calculate the hit point which, in |
| 00:56.40 | CIA-62 | BRL-CAD: the end, will be the same for all samples. It reads the number of samples from |
| 00:56.40 | CIA-62 | BRL-CAD: an environment variable, which is better than having a hardcoded value |
| 01:31.05 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.132.140) | |
| 01:37.19 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 01:42.45 | brlcad | kunigami_: there are several items in your nsamples loop there that do not change across loop iterations -- should pull them out so they're only computed once |
| 02:01.29 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.152.125) | |
| 02:06.32 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 02:11.35 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.148.37) | |
| 03:03.39 | *** join/#brlcad Stattrav (~Stattrav@117.192.149.58) | |
| 03:03.39 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 03:07.41 | CIA-62 | BRL-CAD: 03bhinesley * r45550 10/brlcad/trunk/src/libged/edit.c: |
| 03:07.41 | CIA-62 | BRL-CAD: Cut down on a lot of duplication. Fixed a few issues with subcmd arg helper |
| 03:07.41 | CIA-62 | BRL-CAD: functions (and most are enabled/used now). ged_edit() generic subcommand |
| 03:07.41 | CIA-62 | BRL-CAD: argument parsing is nearly done. Still a WIP. Some option combinations are |
| 03:07.41 | CIA-62 | BRL-CAD: accepted that shouldn't be. It is crashing right now, too. That is to be |
| 03:07.42 | CIA-62 | BRL-CAD: expected, as it needs edit_str_to_arg() to work properly, and that is |
| 03:07.43 | CIA-62 | BRL-CAD: incomplete/needs some modifications. |
| 03:18.01 | *** join/#brlcad Stattrav (~Stattrav@117.192.132.193) | |
| 03:18.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 03:34.20 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.157.12) | |
| 03:55.43 | *** join/#brlcad Stattrav (~Stattrav@117.202.18.126) | |
| 03:55.43 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 04:00.42 | *** join/#brlcad Stattrav_ (~Stattrav@117.202.16.214) | |
| 04:05.44 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 04:25.44 | *** join/#brlcad Stattrav_ (~Stattrav@117.202.23.44) | |
| 04:37.55 | *** join/#brlcad Stattrav (~Stattrav@117.202.24.28) | |
| 04:37.55 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 04:55.29 | *** join/#brlcad Stattrav (~Stattrav@117.192.156.5) | |
| 04:55.29 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:00.28 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.146.128) | |
| 05:05.26 | *** join/#brlcad Stattrav (~Stattrav@117.202.28.81) | |
| 05:05.27 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:16.45 | *** join/#brlcad Stattrav_ (~Stattrav@117.202.22.242) | |
| 05:24.24 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded a new version of "[[Image:Industry Diagram.pdf]]": Fifth revision of the BRL-CAD Industry Diagram. |
| 05:27.32 | *** join/#brlcad Stattrav (~Stattrav@117.192.159.51) | |
| 05:27.33 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:29.15 | brlcad | starseeker: care to try another attempt at converting the diagram to an open format? :) |
| 05:30.05 | brlcad | been a few years, better fonts, hopefully better rendering |
| 05:31.10 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) | |
| 05:31.18 | yukonbob | hello, #brlcad :) |
| 05:33.12 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.154.48) | |
| 05:43.41 | brlcad | howdy |
| 05:52.57 | yukonbob | hai |
| 05:53.22 | yukonbob | how're things? |
| 06:47.55 | *** join/#brlcad Stattrav (~Stattrav@117.192.128.91) | |
| 06:47.55 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:00.39 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:28.52 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:11.31 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 10:23.10 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 10:51.49 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) | |
| 10:51.49 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:33.04 | *** join/#brlcad SCD101 (~sam@109.77.120.154) | |
| 12:33.19 | SCD101 | Hey there :) |
| 12:37.35 | SCD101 | Many people enquired about the ESA SoC? |
| 12:48.06 | CIA-62 | BRL-CAD: 03kunigami * r45551 10/brlcad/trunk/src/liboptical/sh_osl.cpp: moving constant parts out of the loop |
| 12:56.40 | brlcad | SCD101: I think we're up to approximately 482 |
| 12:57.06 | SCD101 | 482 for just your projects? Wow |
| 12:58.04 | brlcad | SCD101: heh, if you believe that, I have a bridge to sell you |
| 12:58.36 | SCD101 | Well considering there are 20 places in total over all of the organisations :P |
| 12:58.47 | SCD101 | How many really? :L |
| 12:59.10 | SCD101 | Also, how big is the bridge? |
| 12:59.15 | SCD101 | :P |
| 12:59.16 | brlcad | it's a wonderful bridge, connecting reality with Mr. Roger's Neighborhood |
| 12:59.32 | brlcad | just a couple |
| 13:00.24 | brlcad | 20 orgs, but the program isn't exceptionally well known, only affects EU students, and is for students with an interest in a niche domain (space) |
| 13:00.30 | SCD101 | Ah cool. I only know C and am doing GSoC atm. Would I need experience with BRL-CAD or is it only needed for some of the projects? |
| 13:18.02 | brlcad | shouldn't matter for most projects, you's learn what you need as you go |
| 13:18.50 | brlcad | you don't need experience with BRL-CAD, but you should be able to read and comprehend existing source code quickly so anything you work on is properly integrated |
| 13:19.26 | brlcad | none of the projects are stand alone, work-off-in-a-corner tasks |
| 13:19.54 | brlcad | they're all intended to be fully integrated so that when you're done, you've improved BRL-CAD in some fashion |
| 13:33.21 | SCD101 | brlcad, I'm currently working on dpkg for Debian. So I've gotten some good experience with large codebases. However I do hope our codebase has more comments than dpkg :P |
| 13:36.12 | brlcad | at more than 1M lines, you'll find some parts are extensively commented, beautiful lush examples, along with entire continents of code without comments |
| 13:36.34 | brlcad | so it depends where you're working, but there are plenty of devs to help you along |
| 13:36.58 | SCD101 | Ok that's good :) |
| 13:37.21 | SCD101 | And all of the projects are open for submission? I only ask because there can only be one can't there? :P |
| 13:38.46 | brlcad | not sure what you mean |
| 13:39.02 | brlcad | you propose the project |
| 13:39.05 | brlcad | we just suggest ideas |
| 13:39.37 | SCD101 | Nvm got confused :L |
| 13:41.04 | SCD101 | I'm liking the look of this bending light idea :P |
| 13:41.39 | SCD101 | AH you use svn |
| 13:47.51 | SCD101 | Ok I really like the code layout. Looks nice to work with |
| 15:55.38 | *** join/#brlcad SCD101 (~sam@109.77.120.154) | |
| 16:04.49 | brlcad | if you have any questions, this is usually the place (or the mailing list) |
| 17:00.04 | kunigami_ | it seems osl shaders have functions named eval_reflect and eval_transmit which must be fed with the view direction and the lighting direction and they return the color |
| 17:05.50 | kunigami_ | hmm so we need to consider the contribution of each light source and get a color? |
| 17:07.21 | kunigami_ | then, if there's reflection/refraction to be done, we compute the directions? |
| 17:45.11 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 18:15.10 | *** join/#brlcad merzo (~merzo@142-55-132-95.pool.ukrtel.net) | |
| 18:30.17 | CIA-62 | BRL-CAD: 03bhinesley * r45552 10/brlcad/trunk/src/libged/edit.c: oops; db_free_full_path() doesn't free bu_malloc'd space for the db_full_path struct itself, so it must be done manually. |
| 18:39.26 | CIA-62 | BRL-CAD: 03bob1961 * r45553 10/brlcad/trunk/src/tclscripts/mged/openw.tcl: This fixes the failed browser launch on windows. |
| 18:56.40 | CIA-62 | BRL-CAD: 03brlcad * r45554 10/brlcad/trunk/NEWS: bob fixed a bug in mged where the browser wasn't getting set properly so the browser wouldn't launch. needed to set mged_browser var but was only setting (web_browser) |
| 19:05.57 | brlcad | kunigami_: so my reading through the osl intro last night, it does change a few notions I had of their system |
| 19:06.40 | brlcad | they are geared towards solving global illumination, which doesn't necessarily mean path tracing, but it does mean that they're not set up for traditional phong-style ray tracing |
| 19:07.33 | kunigami_ | does global illumination imples multiple samples? |
| 19:07.37 | brlcad | actually, their docs seemed a little self-contradicting saying they didn't implement phong-style semantics for a shader but then continue to list a phong function as a possible shader evaluation routine |
| 19:07.37 | kunigami_ | implies* |
| 19:07.51 | brlcad | yes and no |
| 19:08.06 | brlcad | osl evaluates closures |
| 19:08.27 | brlcad | so you can think of every pixel as representing a complex polynomial equation |
| 19:08.57 | brlcad | if solves the equation as far as it can parametrically, then uses the starting view/ray information to solve the remainder |
| 19:09.08 | brlcad | so in theory, they precompute a lot more than you would otherwise |
| 19:10.28 | brlcad | e.g., if you had a lot of reflective shiny surfaces, bright lights but then had a "black-hole sphere" in that scene, then the closure for the pixels of the sphere reduce to .. nothing, black, and there is no need to sample, reshoot, etc |
| 19:10.51 | brlcad | it's not just "absorbed", it figured out that the equation reduced |
| 19:13.16 | kunigami_ | I made two renders using their phong function. one using exponent = 0 and the other exponent = 1. |
| 19:13.18 | brlcad | so not calling -Hbig_number and having any OSL-samples happen internally was a better direction |
| 19:15.13 | kunigami_ | exp = 0 http://dl.dropbox.com/u/1399996/GSoC/green-phong-e0.png |
| 19:15.24 | kunigami_ | exp = 1 http://dl.dropbox.com/u/1399996/GSoC/green-phong-e1.png |
| 19:17.27 | brlcad | mm, too noisy to tell what is going on there |
| 19:20.23 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 19:20.30 | *** part/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 19:20.34 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 19:26.14 | brlcad | kunigami_: did you see a performance difference between shooting with -H and since you refactored out the common code from the loop you readded? |
| 19:27.03 | kunigami_ | didn't measured. Let me do some tests |
| 19:27.27 | brlcad | would have expected it to be noticeable |
| 19:32.47 | kunigami_ | I was wondering if it's desirable to have another incremental mode view for such shaders. At each sample the framebuffer is updated so the image begins noisy and converges to a noise-free one |
| 20:20.08 | CIA-62 | BRL-CAD: 03erikgreenwald * r45555 10/brlcad/trunk/ (include/bu.h src/libbu/simd.c): add support for SSE3, SSE4_1 and SSE4_2. Add a bu_simd_supported function. Minor cleanup and clobberage fixes |
| 20:25.19 | CIA-62 | BRL-CAD: 03r_weiss * r45556 10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c: (log message trimmed) |
| 20:25.19 | CIA-62 | BRL-CAD: Updated function nmg_class_pt_s within file nmg_class.c. This change supports |
| 20:25.19 | CIA-62 | BRL-CAD: the prototype version of the nmg_triangulate_fu function. Within function |
| 20:25.19 | CIA-62 | BRL-CAD: nmg_class_pt_s it uses the raytracer to classify if a point is in, out or on a |
| 20:25.19 | CIA-62 | BRL-CAD: shell. During the computations of determining this, line intersection functions |
| 20:25.20 | CIA-62 | BRL-CAD: are used where some require finite line segments. To help resolve some of the |
| 20:25.21 | CIA-62 | BRL-CAD: computation problems I added a magnitude to the ray direction vector instead of |
| 20:52.34 | *** join/#brlcad tharis20 (~tharis@bl21-44-216.dsl.telepac.pt) | |
| 21:21.23 | tharis20 | hi, I'm Francisco from Portugal and I'm applying to SOCIS |
| 21:21.56 | tharis20 | I don't know what else I should mention, for now I'm just reading and following the checklist |
| 21:23.32 | kunigami_ | brlcad: running with -H 100 and 1 sample per pixel, took 910s. with -H 1 and 100 samples per pixel, took 713s. |
| 21:29.51 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r3020 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */ added reports for week 9 |
| 21:31.33 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r3021 10/wiki/User:Kunigami/GSoc2011/Reports: /* Week 9 (July 18th to July 25) */ added more info to week 9 |
| 21:50.20 | brlcad | tharis20: welcome and thanks! |
| 21:50.26 | brlcad | kunigami_: iiiinteresting |
| 21:50.49 | brlcad | I would have expected more of an increase frankly, but maybe osl is just dominating more than I thought |
| 21:51.32 | tharis20 | brlcad: to run archer do I need to compile brlcad with opengl? |
| 21:52.18 | brlcad | kunigami_: so now is oslr->QueryColor() deterministic? does it return the same color every time for a given info? |
| 21:52.25 | brlcad | tharis20: yep |
| 21:52.36 | brlcad | otherwise, you can use 'mged' |
| 21:52.54 | tharis20 | I know, but I wanted to run archer to see the differences |
| 21:53.11 | kunigami_ | brlcad: no, I still don't know how to use eval_reflect / transmit correcly. |
| 21:53.43 | tharis20 | OpenGL is supposed to be shipped with OSX, but I'm getting an error compiling brlcad with it... I'll see if I can fix it, otherwise, I'll ask someone for help |
| 21:54.16 | brlcad | tharis20: it is shipped with osx -- how are you compiling? |
| 21:54.30 | brlcad | tharis20: give the cmake build a try, you'll need to install cmake |
| 21:55.19 | tharis20 | I have cmake installed, but I was using autotools |
| 21:55.27 | tharis20 | I'll give it a shot then |
| 21:56.27 | brlcad | otherwise, you can paste an error snippet and usually someone will respond within a while |
| 21:56.40 | tharis20 | sure ;) thank you |
| 22:13.26 | *** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 22:14.06 | *** join/#brlcad SCD101 (~sam@109.77.120.154) | |
| 22:14.07 | tharis20 | ... |
| 22:52.22 | tharis20 | woot 37 minutes, 8 seconds |
| 22:57.59 | ``Erik | for the compile? single core slower machine? o.O nfs over 14.4k modem? :D |
| 22:59.27 | bhinesley | waits about that long for a clean build on a Core 2 6600 @ 2.4Ghz |
| 23:00.34 | *** join/#brlcad SCD101 (~sam@109.77.120.154) | |
| 23:13.13 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 23:13.20 | abhi2011 | hi |
| 23:15.09 | abhi2011 | I am trying to write a basic plugin for BRLCAD |
| 23:15.30 | abhi2011 | Is there any tutorial similar to http://brlcad.org/wiki/Developing_applications for plugins ? |
| 23:17.10 | tharis20 | ``Erik: yes, for the compile |
| 23:30.08 | CIA-62 | BRL-CAD: 03r_weiss * r45557 10/brlcad/trunk/src/librt/primitives/nmg/nmg_rt_isect.c: (log message trimmed) |
| 23:30.08 | CIA-62 | BRL-CAD: Updated functions vertex_neighborhood, get_pole_dist_to_face, |
| 23:30.08 | CIA-62 | BRL-CAD: guess_class_from_hitlist_min, guess_class_from_hitlist_max, |
| 23:30.08 | CIA-62 | BRL-CAD: isect_ray_snurb_face, record_face_hit, edge_hit_ray_state, ray_hit_vertex, |
| 23:30.08 | CIA-62 | BRL-CAD: nmg_class_ray_vs_shell within file nmg_rt_isect.c. Many changes are to support |
| 23:30.09 | CIA-62 | BRL-CAD: the prototype version of nmg_triangulate_fu. The changes associated with this |
| 23:30.10 | CIA-62 | BRL-CAD: prototype are disabled by default. The prototype related changes create a |
| 23:37.15 | kunigami_ | To evaluate the contribution of light sources, I'll have to find the light directions for every query point and also if this light is visible or not. For now, I'll just use BRL-CAD lights because this information is already computed |
| 23:58.28 | kunigami_ | Seems there's a bug on sh_toon shader. Currently it is : cosi = VDOT(swp->sw_hit.hit_normal, swp->sw_tolight); |
| 23:58.30 | CIA-62 | BRL-CAD: 03r_weiss * r45558 10/brlcad/trunk/src/libbn/plane.c: |
| 23:58.30 | CIA-62 | BRL-CAD: Updated the protoype function bn_isect_line3_line3_new within file plane.c which |
| 23:58.30 | CIA-62 | BRL-CAD: supports the prototype function nmg_triangulate_fu. These changed are disabled |
| 23:58.30 | CIA-62 | BRL-CAD: by default. Performed code cleanup and improved some of the logic. More cleanup |
| 23:58.30 | CIA-62 | BRL-CAD: is needed. This is a work in progress. |
| 23:59.41 | kunigami_ | but since we're iterating on lights, I think it should be: cosi = VDOT(swp->sw_hit.hit_normal, &sh_swp->sw_tolight + 3*i); |
| 00:01.09 | kunigami_ | If anyone confirm that I'll change it |
| 00:03.16 | kunigami_ | oops ignore the operator & there |
| 00:22.42 | brlcad | abhi2011: wanting to "write a basic plugin" can mean many many things to a package as large as brl-cad |
| 00:23.06 | abhi2011 | ok |
| 00:23.29 | brlcad | could be new object type, new shaders, new commands, new tools, ... |
| 00:23.31 | abhi2011 | so I am trying to learn how to compile plugins |
| 00:23.41 | abhi2011 | i just want to print something |
| 00:23.48 | abhi2011 | on the console and exit |
| 00:23.55 | brlcad | from what? |
| 00:24.13 | abhi2011 | from inside the plugin |
| 00:24.19 | abhi2011 | this is for the physics engine |
| 00:24.22 | brlcad | still, a plugin to *what* :) |
| 00:24.33 | abhi2011 | we were discussing in the mailing list |
| 00:24.35 | brlcad | brl-cad is a suite of applications |
| 00:24.49 | brlcad | okay, so probably a new command |
| 00:24.54 | abhi2011 | yes |
| 00:24.58 | brlcad | commands go into libged |
| 00:25.06 | abhi2011 | so something like ged_physics() |
| 00:25.46 | bhinesley | src/libged/zap.c is a small example |
| 00:26.57 | abhi2011 | 1 sec i ll ok |
| 00:27.05 | bhinesley | or version.c |
| 00:27.10 | abhi2011 | ok |
| 00:27.14 | brlcad | yeah, there are about 400 examples in there |
| 00:27.30 | abhi2011 | ok....is there any doc which discusses how to compile the plugin |
| 00:27.39 | abhi2011 | that is after i have setup the tcl code and c code |
| 00:27.48 | brlcad | add them to src/mged/setup.c and you'll have it available in mged |
| 00:27.59 | abhi2011 | ah ok |
| 00:28.08 | abhi2011 | well i actually wanted to make a plugin for archer |
| 00:28.47 | abhi2011 | the plugin will allow simple physics ultmately |
| 00:28.48 | brlcad | adding to archer is a bit more involved, save that for later |
| 00:28.57 | abhi2011 | ok |
| 00:29.11 | brlcad | it's easy, but that's code that's in flux, so no need to waste time |
| 00:29.37 | abhi2011 | so to compile the code I guess something like : cc -I/usr/brlcad/include/brlcad -L/usr/brlcad/lib -o rtexample rtexample.c -lbu -lrt -lm |
| 00:29.42 | brlcad | if a new physics command does what you're proposing it will do, then can look into archer hooks |
| 00:29.43 | abhi2011 | should do ? |
| 00:30.06 | brlcad | you could do that, assumes a brl-cad install but better would be to add it to the build logic |
| 00:30.23 | abhi2011 | ok |
| 00:30.34 | brlcad | if you're doing an autotools compile, you edit the Makefile.am; or if you're doing a cmake compile, it's the CMakeLists.txt file |
| 00:30.37 | brlcad | then just make |
| 00:30.48 | abhi2011 | ok |
| 00:30.59 | brlcad | (after running autogen.sh or cmake or configure, depends on which build system you use and your platform) |
| 00:31.08 | brlcad | INSTALL and INSTALL.cmake have details |
| 00:31.16 | abhi2011 | ok |
| 00:31.54 | abhi2011 | by the way I was trying out the example from http://brlcad.org/w/images/3/3d/Application_Development.pdf |
| 00:32.04 | abhi2011 | the rtexample.c file |
| 00:32.06 | brlcad | kunigami_: good find if it is the bug, but I'm not familiar with that shader -- ``Erik wrote it |
| 00:32.15 | abhi2011 | if i compile using cc -I/usr/brlcad/include/brlcad -L/usr/brlcad/lib -o rtexample rtexample.c -lbu -lrt -lm |
| 00:32.16 | brlcad | abhi2011: yes? |
| 00:32.20 | abhi2011 | then i get |
| 00:32.37 | abhi2011 | no bio.h file |
| 00:32.57 | brlcad | need to also include /usr/brlcad/include |
| 00:33.00 | abhi2011 | and this header is indeed not present in /usr/include/brlcad |
| 00:33.33 | abhi2011 | ah ok |
| 00:33.43 | brlcad | actually, you're right |
| 00:33.50 | brlcad | bio.h is considered a private header |
| 00:34.06 | abhi2011 | yah |
| 00:34.11 | abhi2011 | i dont c it there either |
| 00:34.26 | abhi2011 | in /usr/brlcad/include i mean |
| 00:34.46 | abhi2011 | there is a file called fbio.h |
| 00:35.01 | abhi2011 | in /usr/brlcad/include/brlcad |
| 00:35.19 | abhi2011 | i popped that in instead :P |
| 00:35.51 | CIA-62 | BRL-CAD: 03brlcad * r45559 10/brlcad/trunk/src/rt/rtexample.c: doesn't seem to be a real need for bio.h here. remove it since this is an example application meant to compile outside brl-cad's build system. thx abhi2011 for the catch. |
| 00:36.15 | abhi2011 | ok |
| 00:36.18 | abhi2011 | np |
| 00:36.40 | brlcad | technically, http://brlcad.org/w/images/3/3d/Application_Development.pdf doesn't reference bio.h ;) |
| 00:36.57 | abhi2011 | ah ok |
| 00:37.09 | abhi2011 | well no tcl.h now |
| 00:37.21 | abhi2011 | [abhi@abhi rt]$ cc -I/usr/brlcad/include/brlcad -L/usr/brlcad/lib -o rtexample rtexample.c -lbu -lrt -lm |
| 00:37.22 | abhi2011 | In file included from /usr/brlcad/include/brlcad/vmath.h:85:0, |
| 00:37.24 | abhi2011 | <PROTECTED> |
| 00:37.25 | abhi2011 | /usr/brlcad/include/brlcad/bu.h:216:58: fatal error: tcl.h: No such file or directory |
| 00:37.27 | abhi2011 | compilation terminated. |
| 00:37.51 | brlcad | that's system dependent |
| 00:37.58 | abhi2011 | ah ok got it |
| 00:38.00 | brlcad | either in /usr/brlcad/include or somewhere else on your system |
| 00:38.06 | abhi2011 | yes right |
| 00:38.09 | abhi2011 | will put it in |
| 00:38.11 | brlcad | that compile line is just supposed to be notional, no way to make it work for everyone |
| 00:38.20 | abhi2011 | right |
| 00:49.20 | abhi2011 | ok got rtexample.c compiled with cc -I/usr/brlcad/include/brlcad -I/usr/brlcad/include-L/usr/brlcad/lib -o rtexample rtexample.c -lbu -lrt -lm |
| 00:49.58 | abhi2011 | now there is a shared library error with brlcad utility library |
| 00:50.01 | abhi2011 | [abhi@abhi rt]$ ./rtexample sphere.g sph1.s |
| 00:50.03 | abhi2011 | ./rtexample: error while loading shared libraries: libbu.so.19: cannot open shared object file: No such file or directory |
| 00:51.03 | abhi2011 | perhaps its not looking in /usr/brlcad/lib |
| 00:51.17 | abhi2011 | where i can see the library is present |
| 00:52.29 | abhi2011 | hmm....I have given the lib path correctly during compiling though |
| 00:59.35 | abhi2011 | probably load library path |
| 00:59.51 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.87) | |
| 00:59.51 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 01:03.02 | kunigami_ | abhi2011: which OS? |
| 01:03.11 | abhi2011 | right finally got rtexample working |
| 01:03.16 | brlcad | your example line has a typo, before the -L |
| 01:03.18 | abhi2011 | fedora 15 |
| 01:03.26 | brlcad | (no space) |
| 01:03.48 | abhi2011 | yes i corrected that |
| 01:04.25 | abhi2011 | the $LD_LIBRARY_PATH was not pointing to /usr/brlcad/lib |
| 01:04.36 | abhi2011 | i put that in , now it runs |
| 01:04.53 | brlcad | not particularly relevant for implementing a physics engine command, but here's a similar example that shows one of the interfaces for creating procedural geometry: http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/proc-db/wdb_example.c?revision=45559&view=markup |
| 01:05.07 | brlcad | LD_LIBRARY_PATH shouldn't need to point to /usr/brlcad/lib |
| 01:05.13 | brlcad | unless you already had is set |
| 01:05.49 | brlcad | LD_LIBRARY_PATH overrides whatever the binary was compiled to look in, if it was set then the solution was probably to just unset it |
| 01:06.03 | brlcad | unless you have it set due to other apps or something like that |
| 01:06.07 | abhi2011 | well ok i ll try unsetting it |
| 01:06.13 | abhi2011 | it was blank before |
| 01:06.23 | brlcad | set or blank? |
| 01:06.31 | brlcad | er, unset or blank? |
| 01:06.41 | brlcad | empty is not the same as unset |
| 01:06.49 | abhi2011 | it was blank...but the program was complaining when it was blank |
| 01:07.12 | abhi2011 | hmm....it was printing a blank line when i echoed it |
| 01:07.45 | brlcad | so what are you studying? |
| 01:08.06 | abhi2011 | i am doing computer engineering |
| 01:08.17 | brlcad | undergrad or grad? |
| 01:08.22 | abhi2011 | grad |
| 01:08.39 | abhi2011 | you are studying as well ? |
| 01:08.52 | brlcad | always ;) |
| 01:08.58 | abhi2011 | hehe |
| 01:09.00 | brlcad | but not in a university setting any more |
| 01:09.07 | abhi2011 | ok |
| 01:09.17 | abhi2011 | hmm..same error again |
| 01:09.29 | abhi2011 | ./rtexample: error while loading shared libraries: libbu.so.19: cannot open shared object file: No such file or directory |
| 01:10.00 | abhi2011 | but i think the gcc linker will link it in as a static library |
| 01:10.16 | brlcad | ldd rtexample |
| 01:10.26 | abhi2011 | yep abt to do tht |
| 01:10.47 | abhi2011 | hmm |
| 01:10.52 | abhi2011 | [abhi@abhi rt]$ ldd rtexample |
| 01:10.52 | brlcad | there's no reason it shouldn't work non-static and without LD_LIBRARY_PATH set |
| 01:10.53 | abhi2011 | linux-gate.so.1 => (0x00339000) |
| 01:10.56 | abhi2011 | libbu.so.19 => not found |
| 01:10.57 | abhi2011 | librt.so.19 => not found |
| 01:10.58 | abhi2011 | libm.so.6 => /lib/libm.so.6 (0x4d18c000) |
| 01:11.00 | abhi2011 | libc.so.6 => /lib/libc.so.6 (0x4cfd1000) |
| 01:11.02 | abhi2011 | /lib/ld-linux.so.2 (0x4cfb0000) |
| 01:11.54 | brlcad | what does it report if you just run this: cc -I/usr/brlcad/include/brlcad -I/usr/brlcad/include -L/usr/brlcad/lib -o rtexample rtexample.c |
| 01:12.51 | abhi2011 | lots of undefined references |
| 01:13.08 | abhi2011 | [abhi@abhi rt]$ cc -I/usr/brlcad/include/brlcad -I/usr/brlcad/include -L/usr/brlcad/lib -o rtexample rtexample.c |
| 01:13.10 | abhi2011 | /tmp/cchQUtho.o: In function `hit': |
| 01:13.12 | abhi2011 | rtexample.c:(.text+0x58): undefined reference to `bu_log' |
| 01:13.13 | abhi2011 | rtexample.c:(.text+0x133): undefined reference to `bu_badmagic' |
| 01:13.15 | abhi2011 | rtexample.c:(.text+0x1a8): undefined reference to `bu_badmagic' |
| 01:13.17 | abhi2011 | rtexample.c:(.text+0x226): undefined reference to `bu_badmagic' |
| 01:13.18 | abhi2011 | ..... |
| 01:14.04 | abhi2011 | hmm the -L flag should be enough to specify the library path |
| 01:14.06 | brlcad | so then: cc -I/usr/brlcad/include/brlcad -I/usr/brlcad/include -L/usr/brlcad/lib -o rtexample rtexample.c -lrt -lbu -lm |
| 01:15.04 | abhi2011 | that command compiles successfully |
| 01:15.22 | brlcad | but then ldd still says not found? |
| 01:15.31 | abhi2011 | yep |
| 01:15.33 | abhi2011 | [abhi@abhi rt]$ cc -I/usr/brlcad/include/brlcad -I/usr/brlcad/include -L/usr/brlcad/lib -o rtexample rtexample.c -lrt -lbu -lm |
| 01:15.35 | abhi2011 | [abhi@abhi rt]$ ldd rtexample |
| 01:15.37 | abhi2011 | linux-gate.so.1 => (0x00b43000) |
| 01:15.38 | abhi2011 | librt.so.19 => not found |
| 01:15.40 | abhi2011 | libbu.so.19 => not found |
| 01:15.41 | abhi2011 | libm.so.6 => /lib/libm.so.6 (0x4d18c000) |
| 01:15.43 | abhi2011 | libc.so.6 => /lib/libc.so.6 (0x4cfd1000) |
| 01:15.44 | abhi2011 | /lib/ld-linux.so.2 (0x4cfb0000) |
| 01:15.46 | abhi2011 | [abhi@abhi rt]$ |
| 01:15.52 | brlcad | then something with your ld setup doesn't seem standard |
| 01:16.19 | abhi2011 | hmm..its a fresh fedora install |
| 01:16.44 | brlcad | set > file |
| 01:16.50 | brlcad | pastebin the file |
| 01:16.56 | abhi2011 | ok |
| 01:17.15 | brlcad | cc --version |
| 01:17.43 | brlcad | fwiw, it doesn't really matter (at least in terms of getting work done) |
| 01:18.06 | brlcad | it's something particular to either your setup and system or fedora in general |
| 01:18.16 | brlcad | usual integration is to mod the build system |
| 01:18.26 | abhi2011 | ok |
| 01:18.39 | abhi2011 | by the way...what do you mean by paste binning the file |
| 01:18.45 | abhi2011 | i ll just paste it here ? |
| 01:18.48 | brlcad | ~pastebin |
| 01:18.48 | ibot | [~pastebin] A "pastebin" is a web-based service where you should paste anything over 3 lines so you don't flood the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://bin.cakephp.org/ , http://asterisk.pastey.net/ , or install pastebinit with yum or aptitude. |
| 01:18.57 | brlcad | don't use the first one |
| 01:19.36 | abhi2011 | ok |
| 01:20.33 | abhi2011 | http://bin.cakephp.org/view/1242653996 |
| 01:23.12 | abhi2011 | [abhi@abhi rt]$ cc --version |
| 01:23.14 | abhi2011 | cc (GCC) 4.6.0 20110530 (Red Hat 4.6.0-9) |
| 01:23.16 | abhi2011 | Copyright (C) 2011 Free Software Foundation, Inc. |
| 01:25.27 | abhi2011 | dont try to hack my system :P |
| 01:32.49 | brlcad | why would I bother with that? :P |
| 01:33.07 | brlcad | so you DO have LD_LIBRARY_PATH set to empty |
| 01:33.14 | brlcad | try: unset LD_LIBRARY_PATH |
| 01:33.19 | brlcad | then ./rtexample |
| 01:36.14 | abhi2011 | haha just kidding :) |
| 01:36.27 | abhi2011 | ok yah i ll try that |
| 01:38.45 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 01:42.06 | abhi2011 | [abhi@abhi rt]$ unset LD_LIBRARY_PATH |
| 01:42.08 | abhi2011 | [abhi@abhi rt]$ ./rtexample |
| 01:42.10 | abhi2011 | ./rtexample: error while loading shared libraries: librt.so.19: cannot open shared object file: No such file or directory |
| 01:42.12 | abhi2011 | [abhi@abhi rt]$ echo $LD_LIBRARY_PATH |
| 01:42.52 | abhi2011 | seems that its unable to find the library without the library path being set |
| 01:47.46 | kunigami_ | Did you try: export LD_LIBRARY_PATH=/usr/brlcad/lib ? |
| 01:50.31 | abhi2011 | yes that does work of course |
| 01:50.57 | abhi2011 | ok so I am trying to add a command to Mged |
| 01:51.28 | abhi2011 | i copied src/libged/zap.c to test.c |
| 01:51.37 | abhi2011 | and i have modified it to : |
| 01:52.06 | abhi2011 | http://bin.cakephp.org/view/118439282 |
| 01:52.36 | abhi2011 | then in setup.c i added a cmd below the zap command |
| 01:52.47 | abhi2011 | <PROTECTED> |
| 01:52.49 | abhi2011 | <PROTECTED> |
| 01:52.50 | abhi2011 | {"T", cmd_test, GED_FUNC_PTR_NULL}, |
| 01:52.52 | abhi2011 | <PROTECTED> |
| 01:52.55 | abhi2011 | the T command for testing |
| 01:53.17 | abhi2011 | now I guess i need to compile these 2 files |
| 01:53.33 | abhi2011 | so do I compile like I did for rtexample.c ? |
| 01:54.00 | CIA-62 | BRL-CAD: 03bhinesley * r45560 10/brlcad/trunk/src/librt/db_fullpath.c: |
| 01:54.00 | CIA-62 | BRL-CAD: db_string_to_path() will trim all leading slashes, but only one trailing slash; |
| 01:54.00 | CIA-62 | BRL-CAD: then it fails when more than one trailing slash is given. I can think of no |
| 01:54.00 | CIA-62 | BRL-CAD: reason why it shouldn't remove all trailing slashes, so now it does. |
| 01:55.11 | abhi2011 | i think the cmd_test still needs to be defined though |
| 01:59.25 | bhinesley | abhi2011: actually, mged isn't using libged for that one... |
| 02:00.18 | bhinesley | you need a better example :) |
| 02:01.36 | bhinesley | archer is using ged_zap, while mged is using cmd_zap |
| 02:04.24 | bhinesley | ged_cat in cat.c is another short one |
| 02:05.14 | bhinesley | what you'll need is something like {"T", cmd_ged_plain_wrapper, ged_test} |
| 02:13.55 | brlcad | abhi2011: the thing is, the library path is supposed to be set in the binary (unless ld or gcc are configured otherwise) |
| 02:14.35 | brlcad | like I said, might be a fedora-specific setting or something different with gcc 4.6 |
| 02:15.03 | brlcad | either way, really doesn't matter -- that's not the usual compile method -- we use a build system |
| 02:15.27 | brlcad | so first step is to compile and install all of brl-cad -- there is a checklist on the wiki of things to do |
| 02:15.47 | brlcad | as for the command, everything bhinesley is saying is spot on :) |
| 02:55.58 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 04:26.07 | *** join/#brlcad Stattrav (~Stattrav@117.202.21.215) | |
| 04:26.07 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 04:31.06 | *** join/#brlcad Stattrav (~Stattrav@117.202.23.74) | |
| 04:31.06 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 04:58.47 | *** join/#brlcad Stattrav (~Stattrav@117.202.23.74) | |
| 04:58.47 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:39.46 | CIA-62 | BRL-CAD: 03bhinesley * r45561 10/brlcad/trunk/src/libged/edit.c: Fixed a bunch of logic bugs. Implemented 'quiet' flagging for edit_str_to_arg, and allowed for conversions to be silently attempted whenever a string *might* contain an arg. |
| 06:54.21 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:08.41 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:17.12 | CIA-62 | BRL-CAD: 03bhinesley * r45562 10/brlcad/trunk/src/libbu/bomb.c: "not validating 'write' return value; missed this in r45542" |
| 07:24.37 | *** join/#brlcad Stattrav (~Stattrav@117.213.184.187) | |
| 07:24.40 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:39.31 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 10:25.26 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 10:28.32 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 10:55.19 | tharis20 | brlcad: does fixing a broken link on your wiki count as a useful patch? :p |
| 11:07.40 | abhi2011 | brlcad: well i have installed all of brlcad |
| 11:08.44 | abhi2011 | and I have setup a new file in src\libged |
| 11:08.54 | abhi2011 | src\libged\test.c |
| 11:09.57 | abhi2011 | so I want it to be a new command to mged |
| 11:10.29 | abhi2011 | i inserted a new command into setup.c |
| 11:10.59 | abhi2011 | {"T", cmd_ged_plain_wrapper, ged_test}, |
| 11:12.01 | abhi2011 | my question is how do I now compile both the files : setup.c and test.c, so that they become available in mged |
| 11:18.59 | kunigami_ | add test.c to LIBGED_SOURCES at libged/CMakeLists.txt |
| 11:19.37 | CIA-62 | BRL-CAD: 03brlcad * r45563 10/brlcad/trunk/src/libbu/bomb.c: write() returns an ssize_t, simplify test |
| 11:22.55 | brlcad | tharis20: can I apply the fix with the patch command? |
| 11:23.27 | brlcad | abhi2011: did you compile/install using cmake? |
| 11:24.02 | brlcad | if so, then what kunigami_ said, recompile, and test.c should get built |
| 11:24.14 | brlcad | if you used autotool, edit src/libged/Makefile.am, then recompile |
| 11:32.16 | abhi2011 | umm no i nstalled brlcad from the rpm |
| 11:32.32 | abhi2011 | so should i build brlcad from source ? |
| 11:32.51 | abhi2011 | is there no way to compile plugins without compiling all of brlcad ? |
| 11:39.30 | tharis20 | in the features request tracker there are some marked open which are already solved |
| 11:41.41 | brlcad | abhi2011: have you ever worked with open source (development) before? |
| 11:42.00 | brlcad | tharis20: yeah, they've not been reviewed in a little while, couple months out of sync |
| 11:42.33 | brlcad | better are the BUGS and TODO files in the source code, or run the tools until you encounter an issue |
| 11:44.00 | tharis20 | I was reading them so that I could choose one to try to implement and I was always "Ok, I don't understand this... isn't this already implemented? No, otherwise it would be closed. It's probably me not understading..." |
| 11:44.01 | brlcad | abhi2011: you can compile plugins without compiling all of brlcad but if it's not obvious how to do that, then you should build the package from source |
| 11:44.12 | abhi2011 | well i have installed open source software before and I know how to compile softwares from source |
| 11:44.27 | abhi2011 | but no i havent actually worked on an open source project |
| 11:45.27 | brlcad | we make compiling brl-cad about as simple as it gets, especially for a package this big, including adding additions -- but yes, you could set up your own build module outside our build system if you wanted using whatever tools you like |
| 11:45.55 | brlcad | it's just a lot easier to explain the integrated approach and socis will be entirely focused on an integrated approach anyways |
| 11:46.16 | abhi2011 | ok yes, I am fine with that |
| 11:46.32 | abhi2011 | so by the integrated approach you mean using cmake right ? |
| 11:46.40 | brlcad | fwiw, stand-alone development is highly frowned upon around here, we all work together so there should be no hesitation to add to the core |
| 11:46.41 | abhi2011 | using cmake to build brlcad from source ? |
| 11:46.51 | brlcad | cmake or autotools |
| 11:46.55 | brlcad | we have two major build systems |
| 11:47.10 | brlcad | autotools is the older more established, but we're in the process (right now) replacing it with a cmake build |
| 11:47.45 | abhi2011 | yes of course..I do not want to do stand-alone development, i want to do this with the community :) |
| 11:47.47 | brlcad | every major feature we remove, though, goes through a proper deprecation removal process so it's not just yanked out from under our users |
| 11:48.09 | brlcad | so autotools is now considered deprecated, and in a few months there will be only cmake |
| 11:48.16 | abhi2011 | ok |
| 11:48.30 | abhi2011 | all I want to do is learn how to make plugins in brlcad |
| 11:48.41 | brlcad | but in the time being, either/both work (and if you make it into socis, you'd be expected to update both) |
| 11:48.42 | abhi2011 | so I can move on to real development of the physics |
| 11:48.58 | abhi2011 | ok yes i understand |
| 11:49.53 | brlcad | like I said yesterday, we have at least a dozen different concepts of a plugin and they all get hooked in differently -- for libged commands, it's (not necessary, but) easiest to just add to the existing build |
| 11:50.07 | brlcad | tharis20: which feature? |
| 11:50.38 | brlcad | abhi2011: have you looked over http://brlcad.org/wiki/Summer_of_Code/Checklist ? |
| 11:50.49 | tharis20 | brlcad: fbclear, for example |
| 11:51.11 | brlcad | link? |
| 11:51.38 | abhi2011 | ah no not yet. right I ll have a look |
| 11:52.09 | tharis20 | http://sourceforge.net/tracker/?func=detail&aid=3238193&group_id=105292&atid=640805 |
| 11:52.27 | tharis20 | this one also http://sourceforge.net/tracker/?func=detail&aid=3279756&group_id=105292&atid=640805 |
| 11:52.41 | brlcad | tharis20: as far as I know, mged doesn't sport an fbclear command still |
| 11:53.27 | brlcad | the latter for the mater command was a bug and is fixed |
| 11:53.49 | tharis20 | I thought it did, in the Introduction to MGED, it mentions this command |
| 11:53.53 | tharis20 | let me check again |
| 11:54.27 | brlcad | theres a gui fbclear button |
| 11:54.29 | brlcad | but no command |
| 11:56.07 | tharis20 | is the function of the wanted command the same of the button? |
| 11:57.14 | abhi2011 | ok I have a question about the Application requirements for SOCIS |
| 11:57.39 | abhi2011 | so is submitting a patch required for being accepted |
| 12:05.00 | abhi2011 | right I have read through the requirements |
| 12:07.33 | abhi2011 | To write a successful propsal, I am trying to compile brlcad from source and write a basic plugin |
| 12:09.54 | abhi2011 | given the tight timeline for SOCIS, how strictly will the acceptance requirements be followed ? |
| 12:10.24 | abhi2011 | especially submitting a patch within the short timeframe would be really tight |
| 12:11.25 | ``Erik | the patch is just to prove that you can compile the code, follow the coding guidelines in the HACKING file and interface with subversion, it doesn't have to be a major change |
| 12:18.29 | abhi2011 | ok I understand...right I ll get on it |
| 12:29.33 | tharis20 | if there's an app doing something and I just want to make a command that uses that app, what's the best approach? |
| 12:30.46 | tharis20 | system call to that app (I don't think that's a good idea), although the GUI uses it or copying and pasting that part that matters of the code of the original app, or ? |
| 12:37.52 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-187-000.wlan.tudelft.nl) | |
| 13:12.56 | tharis20 | besides adding a line in setup.c, editing src/libged/Makefile.am, what else do I need to do to compile with a new command? is there anything else I need to update? |
| 13:16.33 | kunigami_ | tharis20: I think it's enough. Have you tried compiling with these changes? |
| 13:17.03 | tharis20 | yes, and I always get that the function is undeclared |
| 13:19.55 | kunigami_ | paste the error in a patebin, http://paste.ubuntu.com/, for example |
| 13:22.15 | tharis20 | http://pastebin.com/7pBuvvhJ |
| 13:23.28 | tharis20 | I've also noticed that in libged there's no fbclear.o or fbclear.lo |
| 13:53.01 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 13:56.08 | CIA-62 | BRL-CAD: 03erikgreenwald * r45564 10/brlcad/trunk/src/libbu/bomb.c: fix signed/unsigned warning |
| 14:06.33 | *** join/#brlcad tharis20_ (~tharis@bl21-60-39.dsl.telepac.pt) | |
| 14:06.57 | tharis20_ | brlcad: can you help me? ^ |
| 14:48.43 | brlcad | tharis20: if it were, there wouldn't be the need for an fbclear command ;) |
| 14:48.56 | brlcad | it calls through some private api to clear the framebuffer |
| 14:49.46 | brlcad | abhi2011: the patch doesn't have to be related to your project proposal, it can be anything -- the point as ``Erik mentioned is to show competency |
| 14:50.36 | abhi2011 | ok yes. I am compiling the brlcad source now from the instructions in INSTALL.cmake file |
| 14:51.18 | brlcad | so the better your patch, the better your proposal, but even a one-line patch that fixes a hard bug can be as amazing or more than a 1000 line patch that implements some new feature |
| 14:51.28 | tharis20 | brlcad: so, the button fbclear doesn't do the same as the command of the feature request |
| 14:51.46 | brlcad | tharis20: it does the desired operation |
| 14:52.00 | brlcad | but you can't use the api that the button uses for the command |
| 14:52.14 | brlcad | they're in different sections of code |
| 14:52.23 | tharis20 | but the command calls the application fbclear through a system call |
| 14:52.38 | brlcad | yes, it eventually gets to that |
| 14:52.39 | tharis20 | *the button |
| 14:52.54 | brlcad | that's kinda lame for a command |
| 14:53.05 | abhi2011 | right i understand, thanks brlcad |
| 14:53.37 | brlcad | it's just as much logic to set up a connection to fork/exec the fbclear binary as it is to open a connection to the framebuffer and issue a clear command |
| 14:53.53 | tharis20 | exactly, that's why I asked what's the best way, trying to avoid the system call |
| 14:53.53 | brlcad | probably < 20 lines of code |
| 14:54.13 | brlcad | basically, the guts to the fbclear command, with some simplification |
| 14:54.21 | brlcad | s/command/tool/ |
| 14:54.54 | tharis20 | ok, I created a fbclear.c in src/libged |
| 14:55.06 | tharis20 | and added it to Makefile.am |
| 14:55.29 | brlcad | the issue in terms of encapsulation is that there "shouldn't" be a direct call into libfb from libged |
| 14:55.44 | tharis20 | what else do I need to do so that when I compile, mged will recognize the command? |
| 14:55.49 | brlcad | so you shouldn't just call fb_clear() .. it should get passed in through the struct ged |
| 14:56.10 | brlcad | you'll need to add a binding for the function in src/mged/setup.c |
| 14:56.22 | tharis20 | yes, I also did that |
| 14:58.32 | brlcad | fwiw, calling the binary would be better than calling the libfb api directly if you can't figure out how to get to the framebuffer through the struct ged |
| 14:59.17 | brlcad | (ged_fbsp) |
| 15:00.02 | brlcad | tharis20: pastebin.com is the worst pastebin service out there and inaccessible to many of us (network blocked) |
| 15:00.06 | tharis20 | I'm calling the binary src/fb/fbclear |
| 15:00.20 | brlcad | if you have a declaration problem, that means what? |
| 15:00.41 | tharis20 | http://pastebin.ubuntu.com/649203/ |
| 15:01.10 | tharis20 | that means I'm not including something, I guess |
| 15:01.12 | brlcad | so what does that error mean? |
| 15:01.21 | brlcad | not exactly |
| 15:01.28 | brlcad | it means something isn't declared |
| 15:01.47 | brlcad | and it tells you exactly what's not declared |
| 15:01.56 | brlcad | so you just need to find where declarations go |
| 15:05.46 | tharis20 | ok, so now it's the linker giving an error |
| 15:05.56 | tharis20 | since fbclear.c was not compiled |
| 15:06.58 | CIA-62 | BRL-CAD: 03brlcad * r45565 10/brlcad/trunk/src/libbu/bomb.c: strlen() returns and write() takes a size_t, so keep the higher precision as far as we can even through write() requires the stupid return type |
| 16:32.15 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 17:16.52 | brlcad | ``Erik: |
| 17:16.53 | brlcad | simd.c:29: error: can't find a register in class 'BREG' while reloading 'asm' |
| 17:47.34 | *** join/#brlcad Stattrav (~Stattrav@117.192.147.252) | |
| 17:47.34 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:31.32 | kunigami_ | question on calculating the visibility of the light: if the normal of the surface points in the same "direction" of the light, then that light is not visible. In this case the function light_obs returns early without setting sw_visible to NULL |
| 18:32.18 | kunigami_ | I made a test. In the following image, whenever there's a visible light in the given point, I shade it white. look the result |
| 18:32.53 | kunigami_ | http://dl.dropbox.com/u/1399996/GSoC/light_obs.png |
| 18:35.21 | kunigami_ | this also seem to be the cause of the strange behavior of the toon shader: http://dl.dropbox.com/u/1399996/GSoC/toon_result.png |
| 18:36.00 | kunigami_ | look how the blue light seems to be casting a shadow in the portion that should be illuminated by the yellow one |
| 18:36.51 | kunigami_ | without the blue light: http://dl.dropbox.com/u/1399996/GSoC/toon_result_2.png |
| 18:42.50 | *** join/#brlcad Stattrav (~Stattrav@117.192.147.252) | |
| 18:42.50 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:52.40 | *** join/#brlcad Stattrav (~Stattrav@117.192.147.252) | |
| 18:52.40 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:08.44 | *** join/#brlcad Stattrav (~Stattrav@117.192.147.252) | |
| 19:08.44 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:12.29 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 20:09.28 | kunigami_ | strange... the result is still this image http://dl.dropbox.com/u/1399996/GSoC/toon_result.png even when I initialize sw_visible to NULL (before calling light_obs). |
| 20:10.03 | kunigami_ | the problem is only solved when I replace sw_tolight by sw_tolight + 3*i (as mentioned yesterday) |
| 20:10.59 | kunigami_ | http://dl.dropbox.com/u/1399996/GSoC/toon_result_3.png |
| 20:12.13 | kunigami_ | I'm not really sure if my changes are the right ones to do. I'll send an email to dev-list asking for a review |
| 20:32.24 | *** join/#brlcad Stattrav (~Stattrav@117.192.147.252) | |
| 20:32.25 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:39.51 | *** join/#brlcad Stattrav (~Stattrav@117.192.147.252) | |
| 20:39.51 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:01.03 | CIA-62 | BRL-CAD: 03bhinesley * r45566 10/brlcad/trunk/src/libged/edit.c: |
| 21:01.04 | CIA-62 | BRL-CAD: added detection of objects without slashes, nullified dangling |
| 21:01.04 | CIA-62 | BRL-CAD: pointers, misc cleanup |
| 21:07.03 | brlcad | kunigami_: the toon shader is very new, might just have some bugs |
| 21:08.21 | brlcad | ``Erik wrote it, best to ask him |
| 21:08.53 | brlcad | from your images, looks like it is a bug, but not familiar with that shader myself |
| 21:12.03 | ``Erik | should probably eventually finish that shader |
| 21:20.04 | CIA-62 | BRL-CAD: 03erikgreenwald * r45567 10/brlcad/trunk/src/libbu/simd.c: ia32 seems to be unhappy about trying to address ebx at all in PIC mode, so simplify by completely duplicating the asm section to contain all the specialisms |
| 21:22.13 | brlcad | build succeeded here |
| 21:22.41 | ``Erik | yeah, i386 PIC asm code confuses gcc |
| 21:24.58 | CIA-62 | BRL-CAD: 03brlcad * r45568 10/brlcad/trunk/TODO: reports of crashes. red with multiple blank lines and illuminate+Z. |
| 21:36.55 | *** join/#brlcad Elrohir (~kvirc@p5B14A10B.dip.t-dialin.net) | |
| 23:10.44 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.135.247) | |
| 23:15.46 | *** join/#brlcad Stattrav (~Stattrav@117.192.134.79) | |
| 23:15.46 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 23:31.08 | CIA-62 | BRL-CAD: 03r_weiss * r45569 10/brlcad/trunk/src/libbn/plane.c: |
| 23:31.09 | CIA-62 | BRL-CAD: Updated the prototype version of function bn_isect_line_lseg and |
| 23:31.09 | CIA-62 | BRL-CAD: bn_isect_line3_line3_new within the libbn library within file plane.c. These |
| 23:31.09 | CIA-62 | BRL-CAD: changes are disabled by default. These functions support the prototype function |
| 23:31.09 | CIA-62 | BRL-CAD: nmg_triangulate_fu. Made changes to code logic and performed code cleanup. This |
| 23:31.09 | CIA-62 | BRL-CAD: is a work in progress. |
| 23:56.23 | CIA-62 | BRL-CAD: 03r_weiss * r45570 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: |
| 23:56.23 | CIA-62 | BRL-CAD: Updated function nmg_radial_build_list within file nmg_fuse.c. These changes |
| 23:56.23 | CIA-62 | BRL-CAD: support the prototype version of nmg_triangulate_fu. This change corrects a |
| 23:56.23 | CIA-62 | BRL-CAD: problem when the edge radial pointers are not already sorted. These changes are |
| 23:56.23 | CIA-62 | BRL-CAD: disabled by default. This is a work in progress. |
| 00:04.40 | CIA-62 | BRL-CAD: 03r_weiss * r45571 10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c: |
| 00:04.40 | CIA-62 | BRL-CAD: Updated function class_eu_vs_s within file nmg_class.c. This change supports the |
| 00:04.40 | CIA-62 | BRL-CAD: prototype version of nmg_triangulate_fu. Made a logic change which stops the |
| 00:04.40 | CIA-62 | BRL-CAD: error message "class_eu_vs_s: classifier found edge midpoint ON, edge topology |
| 00:04.40 | CIA-62 | BRL-CAD: should have been shared" when performing nmg boolean operations such as when |
| 00:04.40 | CIA-62 | BRL-CAD: running the mged 'facetize' or 'ev' commands. This change is disabled by |
| 00:04.40 | CIA-62 | BRL-CAD: default. This is a work in progress. |
| 00:56.45 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 01:26.12 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 01:31.58 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 02:07.24 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 02:08.49 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.152.228) | |
| 05:06.09 | brlcad | starseeker: thanks for the pointer to look at search |
| 05:06.26 | brlcad | it actually doesn't perform group globbing, but it calls a function I'd forgotten about |
| 05:06.48 | brlcad | calls bu_fnmatch, which is a poorly named function that performs globbing on a single string item |
| 05:07.00 | brlcad | so I can use it while iterating over all items |
| 05:25.10 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 06:42.11 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:58.18 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.137.7) | |
| 07:46.22 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 07:59.24 | CIA-62 | BRL-CAD: 03bhinesley * r45572 10/brlcad/trunk/src/libged/edit.c: (log message trimmed) |
| 07:59.24 | CIA-62 | BRL-CAD: Implemented mechanism for reading multiple subarguments per option and lists of |
| 07:59.24 | CIA-62 | BRL-CAD: arguments for edit subcommands. Objects are currently the only type of argument |
| 07:59.24 | CIA-62 | BRL-CAD: supported, but the logic to add additional parsing capabilities is in place. |
| 07:59.24 | CIA-62 | BRL-CAD: Generic option handling works fairly well now, and provides good feedback to the |
| 07:59.25 | CIA-62 | BRL-CAD: user about bad option/argument combinations as well as possible without knowing |
| 07:59.26 | CIA-62 | BRL-CAD: the syntax of a given command. The syntax of -k/-a/-r options and -x/-y/-z |
| 08:57.16 | *** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz) | |
| 08:57.49 | pawleeq | hello |
| 09:02.18 | pawleeq | I am trying to compile svn version on Ubuntu 11.04 and I fail with this message: http://pastebin.com/kf4GtZ3T |
| 09:11.54 | d_rossberg | zoom.c was moved recently, maybe you should update your makefiles (configure) or use the cmake build |
| 09:14.49 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:17.33 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 09:17.33 | pawleeq | d_rossberg: I was configuring the build as it is written in instructions (autogen, configure) |
| 09:18.57 | d_rossberg | pawleeq: but when? before or after your last svn update |
| 09:25.18 | *** join/#brlcad Stattrav (~Stattrav@117.192.132.143) | |
| 09:25.18 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:28.52 | pawleeq | d_rossberg: no, after |
| 09:31.40 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:37.00 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:45.21 | *** join/#brlcad Stattrav (~Stattrav@117.202.17.197) | |
| 09:45.21 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:55.40 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:08.58 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 10:16.38 | brlcad | pawleeq: but you had a pre-existing checkout, yes? |
| 10:17.30 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:17.40 | brlcad | that looks like a message from the automake dependency tracking code, which doesn't get regenerated through autogen/configure |
| 10:18.01 | pawleeq | brlcad: yeah i had |
| 10:18.02 | brlcad | rm -rf src/libged && svn up src/libged |
| 10:18.14 | brlcad | then rebuild |
| 10:19.03 | pawleeq | thx, I will let you know |
| 10:21.12 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 10:22.31 | *** join/#brlcad Stattrav (~Stattrav@117.192.143.98) | |
| 10:22.31 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:27.35 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.144.16) | |
| 10:32.41 | *** join/#brlcad Stattrav (~Stattrav@117.213.185.180) | |
| 10:32.41 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:38.15 | starseeker | brlcad: I believe the fnmatch name came from http://pubs.opengroup.org/onlinepubs/009695399/functions/fnmatch.html, which is probably what the original find code was calling - it probably is a bad name now that we aren't matching filenames specifically with it anymore |
| 10:38.38 | starseeker | I suspect it was "find code needs this, not on windows, make a libbu version" or some such |
| 10:48.50 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:16.56 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.136.236) | |
| 11:28.32 | *** join/#brlcad Stattrav (~Stattrav@117.192.144.178) | |
| 11:28.32 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:13.01 | ``Erik | "test whether a filename or pathname matches a shell-style pattern" sounds awfully korn/posix2 related to me |
| 12:28.36 | CIA-62 | BRL-CAD: 03d_rossberg * r45573 10/brlcad/trunk/include/ (config_win.h config_win_cmake.h): S_IRWXU for Windows (MS Visual Studio) |
| 12:51.35 | *** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz) | |
| 13:10.05 | pawleeq | brlcad: sorry for such a late reply, but it worked all right, thank you again :) |
| 13:30.34 | *** join/#brlcad abhi2011_ (~chatzilla@wlan-145-94-187-000.wlan.tudelft.nl) | |
| 13:32.42 | *** join/#brlcad abhi2011_ (~chatzilla@wlan-145-94-187-000.wlan.tudelft.nl) | |
| 13:41.19 | CIA-62 | BRL-CAD: 03erikgreenwald * r45574 10/brlcad/trunk/src/libged/edit.c: GCC 4.1 has a bug where a variable set in every condition of a switch still registers as possibly uninitialized, so set it to 0 on definition (seen on rhel5). |
| 14:01.24 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 16:04.07 | brlcad | starseeker: I know bu_fnmatch() comes from fnmatch() ... it's an old bsd function, and defined by posix |
| 16:04.26 | brlcad | it's just a bad function name, because it's not actually specific to file names |
| 16:04.47 | brlcad | pawleeq: no problem |
| 16:15.30 | *** join/#brlcad Stattrav (~Stattrav@122.178.240.221) | |
| 16:15.30 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:40.59 | CIA-62 | BRL-CAD: 03bhinesley * r45575 10/brlcad/trunk/src/libged/edit.c: initialize variable to default before switch, rather than setting in every case |
| 17:43.17 | CIA-62 | BRL-CAD: 03bhinesley * r45576 10/brlcad/trunk/src/libged/edit.c: var probably still needs to be initialized when defined to prevent compiler warnings |
| 18:33.37 | *** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz) | |
| 18:41.35 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3022 10/wiki/ESA_Summer_of_Code_in_Space: |
| 18:55.13 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3023 10/wiki/Community_Publication_Portal: /* Sean Morrison: ESA Summer of Code in Space */ fill out detail |
| 18:57.19 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3024 10/wiki/Community_Publication_Portal: final review |
| 18:58.20 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3025 10/wiki/Community_Publication_Portal: put in right section, done |
| 19:23.22 | *** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz) | |
| 19:27.02 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3026 10/wiki/Community_Publication_Portal: not really frozen, apparently -- found bugs during post |
| 19:56.40 | *** join/#brlcad tharis20 (~tharis@bl12-21-147.dsl.telepac.pt) | |
| 19:57.25 | tharis20 | hello |
| 20:31.02 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 22:30.32 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 00:32.04 | abhi2011 | hi |
| 00:32.12 | abhi2011 | I am trying to compile brlcad |
| 00:32.23 | abhi2011 | apparently I do not have many libraries installed |
| 00:32.37 | abhi2011 | here is the output after compile |
| 00:33.45 | abhi2011 | http://bin.cakephp.org/view/1775318086 |
| 00:34.35 | abhi2011 | i am trying to install the optimized version , the command is as given in INSTALL.cmake |
| 00:34.53 | abhi2011 | cmake ../brlcad-X.Y.Z -DBRLCAD-ENABLE_OPTIMIZED=ON |
| 00:38.40 | abhi2011 | i am installing the packages one by one now |
| 01:04.34 | kunigami_ | if you're building from source. probably the dependencies are already there. try using -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON parameter too |
| 01:19.18 | abhi2011 | ok |
| 01:20.06 | abhi2011 | well i installed and updated quite a few libraries before i saw this :P |
| 01:20.17 | abhi2011 | now its finaly succeeded |
| 01:20.25 | abhi2011 | will try to make now |
| 01:23.53 | abhi2011 | hmm ran into an error while building |
| 01:23.58 | abhi2011 | [ 3%] Building C object src/libbu/CMakeFiles/libbu.dir/malloc.c.o |
| 01:23.59 | abhi2011 | [ 3%] Building C object src/libbu/CMakeFiles/libbu.dir/mappedfile.c.o |
| 01:24.00 | abhi2011 | /home/abhi/brlcad/src/libbu/mappedfile.c: In function ‘bu_open_mapped_file’: |
| 01:24.02 | abhi2011 | /home/abhi/brlcad/src/libbu/mappedfile.c:237:5: error: the comparison will always evaluate as ‘true’ for the address of ‘bu_mapped_file_list’ will never be NULL [-Werror=address] |
| 01:24.04 | abhi2011 | cc1: all warnings being treated as errors |
| 01:24.06 | abhi2011 | make[2]: *** [src/libbu/CMakeFiles/libbu.dir/mappedfile.c.o] Error 1 |
| 01:24.07 | abhi2011 | make[1]: *** [src/libbu/CMakeFiles/libbu.dir/all] Error 2 |
| 01:24.08 | abhi2011 | make: *** [all] Error 2 |
| 01:24.16 | abhi2011 | this is from code checked out from trunk |
| 01:25.01 | abhi2011 | probably have to turn warnings as errors off ? |
| 01:31.52 | abhi2011 | here is the build log |
| 01:31.54 | abhi2011 | http://bin.cakephp.org/view/1072403513 |
| 02:24.18 | brlcad | starseeker: is the automatic detection not set up in cmake? e.g., in his build log it fails on termlib (but that's obviously something we provide) |
| 02:26.11 | brlcad | abhi2011: that strictness failure is due to a recent code change. you can/should turn Werror off (or fix the warning) |
| 02:29.40 | abhi2011 | ok |
| 02:31.44 | brlcad | see if this fixes it |
| 02:32.53 | CIA-62 | BRL-CAD: 03brlcad * r45577 10/brlcad/trunk/include/bu.h: cast the BU_ASSERT pointers through void* in order to hopefully get past the compiler (correctly) warning that the comparison will always evaluate as true. |
| 02:40.31 | *** join/#brlcad tharis20 (~tharis@bl21-50-118.dsl.telepac.pt) | |
| 02:46.56 | abhi2011 | ok..so I should turn compiler warning off, or should I try to cast the BU_ASSERT pointers through void* |
| 03:00.34 | abhi2011 | ok is there a particular cmake file which has the compiler flags ? |
| 03:00.46 | abhi2011 | I have been searching in the files but havent found one yet |
| 03:00.49 | abhi2011 | i ll try find |
| 03:08.13 | abhi2011 | hmm i found it in brlcad/misc/CMake/CompilerFlags.cmake |
| 03:08.45 | abhi2011 | seems like I should turn off the BRLCAD-ENABLE_STRICT flag |
| 03:14.30 | abhi2011 | ok I set brlcad/CMakeLists.txt , line 708 to OFF |
| 03:14.46 | abhi2011 | # Enable/disable strict compiler settings - these are limited to libraries that |
| 03:14.48 | abhi2011 | # specifically inform the BRLCAD_ADDLIB macro they can be built with STRICT flags. |
| 03:14.49 | abhi2011 | OPTION(BRLCAD-ENABLE_STRICT "Use strict compiler settings on libraries that support them" OFF) |
| 03:15.30 | abhi2011 | this should turn off the warnings as errors |
| 03:16.34 | abhi2011 | hmmm...thats didnt work |
| 04:32.40 | bhinesley | abhi2011: he tried to patch it, the channel just echoed his commit; you should run `svn update` and see if your warning is gone. |
| 04:33.11 | bhinesley | otherwise, just try something like `cmake -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON -DBRLCAD-ENABLE_STRICT=OFF` |
| 04:33.15 | bhinesley | ` |
| 04:34.22 | bhinesley | (er rather, the bot CIA-62 echoed his commit) |
| 06:42.45 | *** join/#brlcad colin_ (~colin@114-37-169-197.dynamic.hinet.net) | |
| 07:23.29 | *** part/#brlcad colin_ (~colin@114-37-169-197.dynamic.hinet.net) | |
| 11:18.05 | ``Erik | hm, fbsd is conservative with setting __SSE__, it wants an -msse3 flag passed... is there cmake fu to make that happen? |
| 11:28.42 | abhi2011 | Scanning dependencies of target htester |
| 11:28.44 | abhi2011 | [ 4%] Building C object src/libbu/CMakeFiles/htester.dir/htester.c.o |
| 11:28.45 | abhi2011 | /home/abhi/brlcad/src/libbu/htester.c: In function ‘main’: |
| 11:28.47 | abhi2011 | /home/abhi/brlcad/src/libbu/htester.c:68:9: error: variable ‘ret’ set but not used [-Werror=unused-but-set-variable] |
| 11:28.49 | abhi2011 | cc1: all warnings being treated as errors |
| 11:28.50 | abhi2011 | make[2]: *** [src/libbu/CMakeFiles/htester.dir/htester.c.o] Error 1 |
| 11:28.52 | abhi2011 | make[1]: *** [src/libbu/CMakeFiles/htester.dir/all] Error 2 |
| 11:28.53 | abhi2011 | make: *** [all] Error 2 |
| 11:28.55 | abhi2011 | i ll try the -DBRLCAD-ENABLE_STRICT=OFF` |
| 11:29.15 | *** part/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 11:58.22 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 12:03.15 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 12:03.29 | *** join/#brlcad Stattrav (~Stattrav@117.192.150.58) | |
| 12:03.29 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:05.35 | CIA-62 | BRL-CAD: 03brlcad * r45578 10/brlcad/trunk/src/libbu/htester.c: newer gcc 4.6 is smarter, have to actually use the return value. |
| 14:05.39 | brlcad | abhi2011: that commit should fix htester.c |
| 14:07.07 | brlcad | newer compiler just came out less than a month ago that is better and producing/detecting more warning issues, so they're new issues that haven't been fixed yet |
| 14:08.00 | brlcad | we default to not only treating all warnings as errors but having the compiler report almost every error that it's capable of reporting, way more than the default used by others |
| 14:09.19 | brlcad | so you can keep reporting them and someone will fix them or just turn the strictness off with -DBRLCAD-ENABLE_STRICT=OFF |
| 14:10.12 | brlcad | starseeker: those define sames are like nails on chaulkboard -- can they be all underscores or all dashes? the mix is just asking for usability woe |
| 14:10.26 | brlcad | s/sames/names/ |
| 14:22.23 | abhi2011 | right ok |
| 14:23.07 | abhi2011 | hmm got one more :) !! |
| 14:23.11 | abhi2011 | Linking C executable ../../bin/g-var |
| 14:23.13 | abhi2011 | /usr/bin/ld: CMakeFiles/g-var.dir/g-var.c.o: undefined reference to symbol 'sin@@GLIBC_2.0' |
| 14:23.15 | abhi2011 | /usr/bin/ld: note: 'sin@@GLIBC_2.0' is defined in DSO /lib/libm.so.6 so try adding it to the linker command line |
| 14:23.16 | abhi2011 | /lib/libm.so.6: could not read symbols: Invalid operation |
| 14:23.18 | abhi2011 | collect2: ld returned 1 exit status |
| 14:23.20 | abhi2011 | make[2]: *** [bin/g-var] Error 1 |
| 14:23.22 | abhi2011 | make[1]: *** [src/conv/CMakeFiles/g-var.dir/all] Error 2 |
| 14:23.23 | abhi2011 | make: *** [all] Error 2 |
| 14:24.12 | abhi2011 | math library flag |
| 14:24.32 | abhi2011 | or something related i think |
| 14:28.38 | abhi2011 | about 41% of the build is done |
| 15:37.06 | CIA-62 | BRL-CAD: 03brlcad * r45579 10/brlcad/trunk/src/conv/CMakeLists.txt: add to all of the executables that make direct calls to sin()/cos(). report of build failure from abhi2011 via irc on linux, gcc 4.6, where the implicit attempt to add it automatically results in an ld failure. |
| 15:37.28 | abhi2011 | cool! |
| 15:37.34 | abhi2011 | will try now |
| 15:38.29 | abhi2011 | So what exactly got added |
| 15:39.50 | brlcad | well, exactly http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/conv/CMakeLists.txt?r1=45069&r2=45579 |
| 15:39.56 | brlcad | there's now an explicit link for -lm for those binaries |
| 15:40.34 | brlcad | should not be needed as it's already prescribed elsewhere, but something appears to be wrong on your system with ld or /lib/libm.so.6 |
| 15:41.19 | abhi2011 | ok |
| 15:41.28 | brlcad | adding it explicit may just get past whatever that issue is and is harmless in the build file otherwise for others |
| 15:41.38 | abhi2011 | right ok |
| 15:49.54 | abhi2011 | Scanning dependencies of target enf-g |
| 15:49.56 | abhi2011 | [ 41%] Building C object src/conv/CMakeFiles/enf-g.dir/enf-g.c.o |
| 15:49.57 | abhi2011 | Linking C executable ../../bin/enf-g |
| 15:49.59 | abhi2011 | /usr/bin/ld: CMakeFiles/enf-g.dir/enf-g.c.o: undefined reference to symbol 'sqrt@@GLIBC_2.0' |
| 15:50.00 | abhi2011 | /usr/bin/ld: note: 'sqrt@@GLIBC_2.0' is defined in DSO /lib/libm.so.6 so try adding it to the linker command line |
| 15:50.02 | abhi2011 | /lib/libm.so.6: could not read symbols: Invalid operation |
| 15:50.04 | abhi2011 | collect2: ld returned 1 exit status |
| 15:50.05 | abhi2011 | make[2]: *** [bin/enf-g] Error 1 |
| 15:50.07 | abhi2011 | make[1]: *** [src/conv/CMakeFiles/enf-g.dir/all] Error 2 |
| 15:50.08 | abhi2011 | make: *** [all] Error 2 |
| 15:50.10 | abhi2011 | same issue, different place |
| 16:13.18 | CIA-62 | BRL-CAD: 03brlcad * r45580 10/brlcad/trunk/src/conv/CMakeLists.txt: more needed for sqrt() |
| 16:36.39 | abhi2011 | [ 17%] Building C object src/rt/CMakeFiles/rtray.dir/viewray.c.o |
| 16:36.41 | abhi2011 | Linking C executable ../../bin/rtray |
| 16:36.42 | abhi2011 | /usr/bin/ld: CMakeFiles/rtray.dir/worker.c.o: undefined reference to symbol 'sin@@GLIBC_2.0' |
| 16:36.44 | abhi2011 | /usr/bin/ld: note: 'sin@@GLIBC_2.0' is defined in DSO /lib/libm.so.6 so try adding it to the linker command line |
| 16:36.45 | abhi2011 | /lib/libm.so.6: could not read symbols: Invalid operation |
| 16:36.47 | abhi2011 | collect2: ld returned 1 exit status |
| 16:36.48 | abhi2011 | make[2]: *** [bin/rtray] Error 1 |
| 16:36.50 | abhi2011 | make[1]: *** [src/rt/CMakeFiles/rtray.dir/all] Error 2 |
| 16:36.52 | abhi2011 | make: *** [all] Error 2 |
| 17:13.44 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-125-86-110.dsl.bkfd14.sbcglobal.net) | |
| 17:39.28 | abhi2011 | Linking C executable ../../bin/rtray |
| 17:39.29 | abhi2011 | /usr/bin/ld: CMakeFiles/rtray.dir/worker.c.o: undefined reference to symbol 'sin@@GLIBC_2.0' |
| 17:39.31 | abhi2011 | /usr/bin/ld: note: 'sin@@GLIBC_2.0' is defined in DSO /lib/libm.so.6 so try adding it to the linker command line |
| 17:39.33 | abhi2011 | /lib/libm.so.6: could not read symbols: Invalid operation |
| 17:39.35 | abhi2011 | collect2: ld returned 1 exit status |
| 17:39.37 | abhi2011 | make[2]: *** [bin/rtray] Error 1 |
| 17:39.38 | abhi2011 | make[1]: *** [src/rt/CMakeFiles/rtray.dir/all] Error 2 |
| 17:39.40 | abhi2011 | make: *** [all] Error 2 |
| 18:00.11 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 19:35.11 | CIA-62 | BRL-CAD: 03brlcad * r45581 10/brlcad/trunk/src/rt/CMakeLists.txt: more ${M_LIBRARY} additions to accommodate some front-end calls to sin()/cos() |
| 19:45.23 | abhi2011 | cool! |
| 19:45.42 | brlcad | there are undoubtedly a lot more places that will need to be propagated |
| 19:48.41 | abhi2011 | ok |
| 19:49.12 | abhi2011 | cant this be automated |
| 19:49.39 | abhi2011 | like for all binaries like the rtray |
| 19:50.10 | abhi2011 | ok 42% now |
| 19:50.13 | abhi2011 | Linking C shared library ../../lib/libtclcad.so |
| 19:50.15 | abhi2011 | [ 42%] Built target libtclcad |
| 19:50.16 | abhi2011 | Linking C executable ../../bin/asc2g |
| 19:50.18 | abhi2011 | /usr/bin/ld: CMakeFiles/asc2g.dir/asc/asc2g.c.o: undefined reference to symbol 'sqrt@@GLIBC_2.0' |
| 19:50.20 | abhi2011 | /usr/bin/ld: note: 'sqrt@@GLIBC_2.0' is defined in DSO /lib/libm.so.6 so try adding it to the linker command line |
| 19:50.21 | abhi2011 | /lib/libm.so.6: could not read symbols: Invalid operation |
| 19:50.23 | abhi2011 | collect2: ld returned 1 exit status |
| 19:50.25 | abhi2011 | make[2]: *** [bin/asc2g] Error 1 |
| 19:50.26 | abhi2011 | make[1]: *** [src/conv/CMakeFiles/asc2g.dir/all] Error 2 |
| 19:50.27 | abhi2011 | make: *** [all] Error 2 |
| 19:50.36 | brlcad | only thing I can think of is you're using some older version of cmake or there is something wrong with your ld setup |
| 19:51.08 | abhi2011 | hmm ok |
| 19:51.09 | brlcad | otherwise, there's no way to automate the fix for sure |
| 19:51.28 | abhi2011 | its a straight fedora 15 install |
| 19:51.43 | abhi2011 | no changes to ld etc |
| 19:51.59 | brlcad | right, but it gets back to the earlier ld fishyness too |
| 19:52.09 | abhi2011 | yeah |
| 19:52.14 | brlcad | something is still different, whether intentional or not |
| 19:53.12 | brlcad | there are 400 binaries in brl-cad, so at least that many opportunities to hit this issue |
| 19:53.41 | brlcad | one thing you could do would be to compile with "make -k 2>&1 | tee build.log" |
| 19:54.09 | brlcad | then you can post that build log up some place, it should get further than one at a time |
| 19:54.58 | abhi2011 | ok right I ll do that |
| 19:57.40 | CIA-62 | BRL-CAD: 03brlcad * r45582 10/brlcad/trunk/src/conv/ (CMakeLists.txt iges/CMakeLists.txt): more -lm propagation |
| 20:08.36 | *** join/#brlcad tharis20_ (~tharis@2.82.61.33) | |
| 20:43.11 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.215) | |
| 20:43.11 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:48.11 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.138.138) | |
| 20:51.12 | abhi2011 | right the build is done |
| 20:53.20 | abhi2011 | i ll post the build log in the mailing list |
| 20:53.57 | brlcad | Nuuuo |
| 20:54.09 | brlcad | just post it to some file sharing service |
| 20:54.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:54.25 | brlcad | how long is it? |
| 21:01.44 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.89) | |
| 21:01.44 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:01.48 | abhi2011 | 10.6 mb |
| 21:02.00 | abhi2011 | when compressed just 400 kb |
| 21:02.54 | abhi2011 | sent on the mailing list |
| 21:03.07 | abhi2011 | may I know what is the preferred platform for building brlcad |
| 21:03.46 | abhi2011 | i would like to finish building brlcad soon and move on development as the ESA SOCIS deadline is coming up fast :) |
| 21:08.06 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:14.30 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.89) | |
| 21:14.41 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:24.02 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.89) | |
| 21:24.03 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:31.21 | brlcad | abhi2011: there isn't really a preferred platform, we continuously build on a variety of platforms including linux (rh, gentoo, ubuntu, ...), freebsd, mac os x, windows, and occasionally even on haiku, solaris, openbsd, ... |
| 21:31.37 | brlcad | the issues you're running into are not common, to say the least |
| 21:32.04 | brlcad | the only other suggestion I could make would be to try the autotools build instead of the cmake build (from a fresh checkout) to see if it works better for you |
| 21:32.23 | brlcad | ./autogen.sh && ./configure --enable-all && make |
| 21:33.10 | abhi2011 | right ok |
| 21:37.02 | brlcad | mm, 95% of that build log is just src/conv/step blathering warnings for autogenerated code (which we don't care about, won't fix) |
| 21:37.55 | brlcad | that's more reasonable, 1mb |
| 21:39.33 | brlcad | er, not even .. 300k, just 5k lines |
| 21:40.07 | abhi2011 | <PROTECTED> |
| 21:40.17 | abhi2011 | 79372 lines |
| 21:41.03 | brlcad | of which about 74300 are completely irrelevant |
| 21:41.42 | abhi2011 | ok I ll try the autotools build, see if that resolves the issue |
| 21:41.58 | brlcad | if that log needs to get generated again (say after someone goes through and addresses the warnings), use: cat build.log | grep -v src/conv/step |grep -v src/other/step > build2.log |
| 21:42.51 | brlcad | autotools isn't going to fix the strictness warnings, so need to disable strict there too |
| 21:42.59 | brlcad | ./autogen.sh && ./configure --enable-all --disable-strict && make |
| 21:43.37 | brlcad | it detects and links libraries in a very different way, though, so might get past the math library issues |
| 21:44.27 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.131.139) | |
| 21:54.34 | abhi2011 | right ok |
| 21:55.31 | abhi2011 | and as backup...does brlcad have a smooth build on fedora 10 ? |
| 21:55.57 | abhi2011 | like I am looking for any other platform in which brlcad is known to have a smooth build |
| 21:57.03 | brlcad | what are your options? |
| 21:57.14 | abhi2011 | i can try opensuse various versions |
| 21:57.19 | abhi2011 | or fedora 10 to 14 |
| 21:57.40 | abhi2011 | well any free distro really :) |
| 21:58.10 | brlcad | well we've certainly built on fedora and opensuse before |
| 21:58.33 | brlcad | the compilation warnings are a non-issue, because they can be disabled -- and are specific to gcc 4.6 |
| 21:58.45 | abhi2011 | ok |
| 21:58.57 | abhi2011 | yes i am trying with autotools now |
| 21:59.41 | brlcad | the linker problem is the first I've seen of that so hopefully the autotools build will get past it |
| 22:01.05 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 22:11.29 | *** join/#brlcad Stattrav (~Stattrav@117.192.131.139) | |
| 22:11.30 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 22:21.32 | *** join/#brlcad Stattrav (~Stattrav@117.192.131.139) | |
| 22:21.33 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 22:45.41 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 22:56.45 | *** join/#brlcad Stattrav (~Stattrav@117.192.143.63) | |
| 22:56.45 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 23:01.43 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.138.30) | |
| 23:10.17 | abhi2011 | well the autotools build is still running, i hope there is a way to just build plugins for mged separately rather than have to build all of brlcad to test them |
| 00:37.16 | abhi2011 | autotools build succeded - took 1 hour |
| 00:47.52 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 01:41.38 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 01:57.30 | brlcad | abhi2011: glad to hear it, so the latter linkage issue is more likely build system related -- cmake is new |
| 01:57.57 | brlcad | abhi2011: and you don't have to rebuild all of brl-cad to test, you can cd to subdirs and it'll only build/rebuild what you add/change |
| 02:07.17 | *** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net) | |
| 06:46.07 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 08:25.42 | *** join/#brlcad Calin (~Calin@109.99.20.242) | |
| 09:57.01 | *** join/#brlcad Stattrav (~Stattrav@117.192.132.247) | |
| 09:57.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:03.25 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.130.62) | |
| 10:20.31 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:48.45 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:56.08 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:05.26 | *** join/#brlcad Stattrav (~Stattrav@117.202.23.115) | |
| 11:05.26 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:20.10 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.129.21) | |
| 11:25.07 | *** join/#brlcad Stattrav (~Stattrav@117.192.148.196) | |
| 11:25.07 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:30.07 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.133.68) | |
| 11:35.10 | *** join/#brlcad Stattrav (~Stattrav@117.192.143.229) | |
| 11:35.10 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:36.58 | *** join/#brlcad CalinPaul (~Calin@109.99.20.242) | |
| 11:49.20 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.156.102) | |
| 12:34.54 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 12:37.57 | *** join/#brlcad abhi2011__ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 12:41.40 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:55.44 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 13:24.19 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.151.88) | |
| 13:44.51 | CIA-62 | BRL-CAD: 03brlcad * r45583 10/brlcad/trunk/src/conv/iges/iges.c: gcc 4.6 quellage. format specifiers and set but unused vars. |
| 13:49.24 | CIA-62 | BRL-CAD: 03brlcad * r45584 10/brlcad/trunk/CMakeLists.txt: |
| 13:49.25 | CIA-62 | BRL-CAD: blindly forcing the FS access down to 32-bit is causing build problems for |
| 13:49.25 | CIA-62 | BRL-CAD: environments that prescribe a different setting. getting redefinition warnings |
| 13:49.25 | CIA-62 | BRL-CAD: aside from it feeling like a non-portable hack to start with. needs a better |
| 13:49.25 | CIA-62 | BRL-CAD: test if zlib needs something. |
| 13:52.40 | ``Erik | um, when I build on a certain 64b rhel machine with a cat name, it says it's dropping to 32b mode, but actually builds 64b. Between that and the fat binary issue, some serious luvin' is needed for word width |
| 14:10.54 | CIA-62 | BRL-CAD: 03erikgreenwald * r45585 10/brlcad/trunk/TODO: add a couple config issues |
| 14:24.34 | brlcad | nods |
| 14:37.05 | CIA-62 | BRL-CAD: 03brlcad * r45586 10/brlcad/trunk/src/ (17 files in 17 dirs): |
| 14:37.05 | CIA-62 | BRL-CAD: remainder(?) of -lm propagation. used fedora build log failure report to fix |
| 14:37.05 | CIA-62 | BRL-CAD: all instances except for libremrt. it's marked as a static lib, so unclear how |
| 14:37.05 | CIA-62 | BRL-CAD: to specify the dependency like is done in BRLCAD_ADDLIB (and why can we not just |
| 14:37.05 | CIA-62 | BRL-CAD: call that instead?). needs fedora retesting. |
| 14:43.07 | brlcad | starseeker: these normal? or better question, how to suppress them by default: |
| 14:43.10 | brlcad | -- Could NOT find UTAHRLE (missing: UTAHRLE_LIBRARY UTAHRLE_INCLUDE_DIR) |
| 14:43.10 | brlcad | -- Could NOT find TCL (missing: TCL_LIBRARY TCL_TCLSH_EXECUTABLE TCL_TCLSH TCL_LIBRARY TCL_INCLUDE_PATH TCL_STUB_LIBRARY TK_INCLUDE_PATH TCL_TK_LIBRARY TCL_WISH_EXECUTABLE TK_LIBRARY TCL_TK_STUB_LIBRARY TK_STUB_LIBRARY) |
| 14:43.14 | brlcad | -- Could NOT find TK (missing: TCL_TK_LIBRARY TCL_TCLSH_EXECUTABLE TCL_TCLSH TCL_LIBRARY TCL_INCLUDE_PATH TCL_STUB_LIBRARY TK_INCLUDE_PATH TCL_TK_LIBRARY TCL_WISH_EXECUTABLE TK_LIBRARY TCL_TK_STUB_LIBRARY TK_STUB_LIBRARY TCL_LIBRARY) |
| 14:43.18 | brlcad | -- Could NOT find OPENNURBS (missing: OPENNURBS_LIBRARY OPENNURBS_INCLUDE_DIR) |
| 14:43.21 | brlcad | -- Could NOT find SCL (missing: SCL_CORE_LIB SCL_DAI_LIB SCL_UTILS_LIB SCL_EXPRESS_EXECUTABLE) |
| 14:54.29 | CIA-62 | BRL-CAD: 03brlcad * r45587 10/brlcad/trunk/src/conv/iges/iges.c: unused i |
| 15:46.51 | abhi2011 | yep i got those too |
| 16:22.53 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 17:08.24 | *** join/#brlcad name (~name@sburn/devel/name) | |
| 17:20.43 | *** join/#brlcad Calin (~Calin@109.99.20.242) | |
| 20:32.04 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3027 10/wiki/User:Abhijit: ESA Summer of Code Project Proposal for Abhijit Nandy |
| 20:32.13 | abhi2011 | hi |
| 20:32.33 | abhi2011 | I am preparing my project proposal for SOCIS |
| 20:32.50 | abhi2011 | Will I insert it in my wiki page as given in the guidelines ? |
| 20:46.12 | brlcad | sure, that works great |
| 20:48.11 | abhi2011 | cool |
| 21:09.59 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3028 10/wiki/User:Abhijit: SOCIS proposal of Abhijit |
| 21:10.10 | abhi2011 | uploaded it for initial review |
| 21:12.16 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3029 10/wiki/User:Abhijit: /* Brief project summary */ |
| 21:23.28 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3030 10/wiki/User:Abhijit: /* Detailed project description */ |
| 22:00.26 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3031 10/wiki/User:Abhijit: Added background work so far. |
| 22:01.23 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3032 10/wiki/User:Abhijit: /* Background work done and why I will be a good choice for the project :) */ |
| 22:15.58 | LainIwakuraX | Hello all, I've become interested in development on brlcad...so I picked up one of the tasks here: http://brlcad.org/wiki/Contributor_Quickies and completed it. Who do I talk to about next steps, etc.? This is my first time doing open source stuff, I have no idea how things work. |
| 22:27.52 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3033 10/wiki/User:Abhijit: /* Background work done and why I will be a good choice for the project :) */ |
| 23:04.00 | starseeker | brlcad: yeah, those are normal |
| 23:04.32 | starseeker | not sure if I put a mechanism in to suppress them |
| 23:16.35 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 23:27.05 | abhi2011 | Hi I am working on moving LIBBN comments from source to header files as given here http://brlcad.org/wiki/Contributor_Quickies#VERY_EASY:_Translate_.22BRL-CAD_Overview.22_document |
| 23:27.46 | abhi2011 | So if I understand correctly, a new header file needs to be created for every C file and the functions need to be declared there |
| 23:34.24 | LainIwakuraX | The way I understood it, the functions in src/libbn/*.c have comments, but those comments should be on the function prototypes |
| 23:34.28 | LainIwakuraX | which are in bn.h |
| 23:34.52 | LainIwakuraX | so you shouldn't need to create a new header |
| 23:35.26 | abhi2011 | ah ok thanks LainIwakuraX |
| 23:35.40 | abhi2011 | so was this the one you completed :) |
| 23:35.47 | LainIwakuraX | no lol |
| 23:36.04 | LainIwakuraX | I did this: http://brlcad.org/wiki/Contributor_Quickies#MEDIUM:_Replace_SCLstring_with_std::string |
| 23:36.08 | LainIwakuraX | so just don't do that one ;) |
| 23:36.34 | abhi2011 | ah ok |
| 23:42.08 | LainIwakuraX | I'm out for dinner, if any developer wants to talk w/ me about code review / changes I made just type something here I'll see it soon |
| 00:16.40 | tharis20 | brlcad: can a person apply for two projects in brlcad? |
| 00:17.10 | tharis20 | obviously, one would be working only on one of them, if he got accepted |
| 00:38.24 | brlcad | starseeker: so the better question was how to suppress them by default? they don't really convey useful information, misleading even |
| 00:39.48 | brlcad | LainIwakuraX: if you've completed one of them, awesome -- the first steps are generally to post a patch to the brl-cad patches tracker on sourceforge and talk to devs to get it reviewed/applied |
| 00:40.25 | brlcad | LainIwakuraX: the basic high-level project operations are written up in the HACKING file, linked to on the quickies page |
| 00:41.04 | brlcad | LainIwakuraX: and that's pretty impressive if you've replaced all of the SCLstring instances.. nice! |
| 00:41.40 | abhi2011 | Hi brlcad, since BRL-CAD uses doxygen for documentation, is there a doxyfile in the source code already or is one generated when needed |
| 00:41.48 | brlcad | there's one in misc/ |
| 00:41.53 | abhi2011 | ok |
| 00:42.11 | brlcad | but it's easy enough to recreate one as needed too |
| 00:42.20 | abhi2011 | right ok |
| 00:42.49 | brlcad | I've been working on a doxyfile specific for libbu that's a little different from what's in nmisc/ |
| 00:43.02 | brlcad | as a template for the rest, but it's still a wip |
| 00:43.16 | abhi2011 | ok |
| 00:43.51 | abhi2011 | regarding moving LIBBN comments from source to header files, I guess the comments on the *.c file need to be moved atop the function declarations in bu.h ? |
| 00:44.46 | brlcad | nope, but close |
| 00:44.49 | abhi2011 | i.e. the files in /src/libbn/*.c |
| 00:44.56 | brlcad | atop the decls in bN.h ;) |
| 00:45.05 | abhi2011 | oops yes right |
| 00:45.29 | brlcad | have you ever made a patch before? |
| 00:45.34 | abhi2011 | no |
| 00:45.44 | brlcad | that's fine |
| 00:46.01 | abhi2011 | but i understand that making the changes and testing with doxygen should not be done in the checked out svn repository |
| 00:46.13 | abhi2011 | otherwise a diff will add the new files as weel |
| 00:46.14 | brlcad | but then I suggest not attempting all files, migrate just one libbn file to the header and work on submitting it as a patch |
| 00:46.30 | brlcad | there shouldn't be any new files |
| 00:46.33 | abhi2011 | right ok |
| 00:46.54 | brlcad | svn will make a patch file for you, which is basically just a special format text file |
| 00:47.22 | abhi2011 | yes true, the thing is if I test with doxygen in the svn checked out source, then it will produce new files |
| 00:47.34 | brlcad | try moving one comment from src/libbn to include/bn.h then run svn diff at the top-level -- that will output a diff of any changes you made |
| 00:47.48 | abhi2011 | right ok |
| 00:47.57 | brlcad | you can point doxygen output anywhere |
| 00:48.11 | abhi2011 | yes ok |
| 00:48.14 | brlcad | those files will get ignored by svn unless you specifically add them |
| 00:48.28 | abhi2011 | ok cool |
| 00:48.33 | brlcad | there are lots of tutorials around the net too on creating a patch file with svn |
| 00:49.13 | abhi2011 | right. I ll try with 1 file first |
| 00:49.20 | brlcad | basically, though, it's just "svn diff > my_changes.patch" .. then manually inspect the my_changes.patch file with a text editor to make sure it only includes things you intended to change |
| 00:49.35 | abhi2011 | ok |
| 00:49.50 | brlcad | if it includes more, you have to svn revert the files unintentionally edited or undo the edits by hand |
| 00:50.08 | abhi2011 | right |
| 00:50.12 | brlcad | that patch file gets posted to the patches tracker, and then you get a dev to review it (in here and/or on the mailing list) |
| 00:50.51 | abhi2011 | ok...the submission is through the web interface i guess |
| 00:51.01 | abhi2011 | *the posting |
| 00:51.23 | brlcad | abhi2011: for socis, that will satisfy the "requirement" more than enough but keep in mind that shows only basic competency .. doesn't take any skill to move a comment ;) |
| 00:52.00 | abhi2011 | yes true :) |
| 00:53.43 | abhi2011 | well have to start somewhere :P |
| 00:55.06 | LainIwakuraX | brlcad: How do I make a patch? Like I mentioned this is my first time doing open source stuff =x |
| 00:57.01 | LainIwakuraX | brlcad: Nevermind, it looks like svn diff > stuff.patch =) |
| 01:12.06 | starseeker | brlcad: um. they are conveying information in the sense that tests are actually being run to see if system versions of those libraries are available... |
| 01:12.56 | starseeker | not sure how they're misleading... I could add a note saying local version is being enabled for compilation... |
| 01:19.44 | brlcad | starseeker: those messages were printed during make, not during cmake (this was a simple "cmake . ; make") and they're the first thing output during make |
| 01:20.24 | brlcad | basically looks like a bunch of failure messages, which during make implies build failures |
| 01:23.31 | LainIwakuraX | Patch submitted, now I wait =P |
| 01:23.36 | brlcad | the clarity of the message itself would also help .. "Could NOT find UTAHRLE" isn't true and has overemphasis, maybe "Could not find a usable system Utah Raster Toolkit, building the included one" |
| 01:24.05 | brlcad | LainIwakuraX: outstanding |
| 01:58.22 | tharis20 | is there a way not to compile all brlcad stuff when modifying only 1 file? |
| 01:59.15 | brlcad | yes several ways, the easiest is to just cd to the dir where the change was made and make |
| 02:01.43 | abhi2011 | submitted my basic patch :P |
| 02:07.39 | abhi2011 | regarding the Convert BU_SETJUMP/BU_UNSETJUMP blocks into try/catch layout |
| 02:07.54 | starseeker | brlcad: are you sure cmake wasn't being run first? |
| 02:08.09 | starseeker | rerun rather... |
| 02:08.51 | abhi2011 | i guess a simple grep for BU_SETJUMP in src/**/*.c should reveal all places where the blocks should be replaced with try/catch layout ? |
| 02:09.26 | LainIwakuraX | abhi2011: "grep -H -r "BU_SETJUMP" . | grep -v svn | less" |
| 02:09.42 | LainIwakuraX | in an appropriately high level directory |
| 02:09.56 | abhi2011 | nice...thanks |
| 02:10.01 | abhi2011 | i ll grep in src |
| 02:10.11 | LainIwakuraX | That's how I found SCLstring ;) lol |
| 02:10.21 | abhi2011 | :) |
| 02:11.31 | abhi2011 | i think better to add *.c |
| 02:12.35 | LainIwakuraX | Yeah, in my case I had to look in header files too, but whatever works |
| 02:13.37 | abhi2011 | right...and do you do the build in the source tree using autotools ? |
| 02:13.48 | abhi2011 | or out of tree |
| 02:14.16 | LainIwakuraX | hm, last night I was just using cmake / make in the highest level |
| 02:15.48 | abhi2011 | ok, I guess then the object files get produced in the source tree |
| 02:16.14 | LainIwakuraX | yeah, svn will ignore those though unless you svn add them |
| 02:16.20 | abhi2011 | ok |
| 02:47.06 | abhi2011 | so the code is something like this : |
| 02:47.11 | abhi2011 | double result; |
| 02:47.13 | abhi2011 | if (!BU_SETJUMP) { |
| 02:47.14 | abhi2011 | <PROTECTED> |
| 02:47.16 | abhi2011 | <PROTECTED> |
| 02:47.18 | abhi2011 | <PROTECTED> |
| 02:47.20 | abhi2011 | ret = 1; |
| 02:47.21 | abhi2011 | failed_cnt++; |
| 02:47.23 | abhi2011 | (void)fprintf(stream, "Failed function %lu test case on line %lu expected = %.15f result = %.15f\n", |
| 02:47.25 | abhi2011 | <PROTECTED> |
| 02:47.26 | abhi2011 | <PROTECTED> |
| 02:47.28 | abhi2011 | success_cnt++; |
| 02:47.30 | abhi2011 | <PROTECTED> |
| 02:47.32 | abhi2011 | } else { |
| 02:47.34 | abhi2011 | <PROTECTED> |
| 02:47.36 | abhi2011 | <PROTECTED> |
| 02:47.37 | abhi2011 | <PROTECTED> |
| 02:47.39 | abhi2011 | <PROTECTED> |
| 02:47.41 | abhi2011 | <PROTECTED> |
| 02:47.42 | abhi2011 | } BU_UNSETJUMP; |
| 02:47.44 | abhi2011 | this may be replaced by code similar to: |
| 02:47.45 | abhi2011 | double result; |
| 02:47.47 | abhi2011 | try{ |
| 02:47.48 | abhi2011 | <PROTECTED> |
| 02:47.50 | abhi2011 | <PROTECTED> |
| 02:47.51 | abhi2011 | <PROTECTED> |
| 02:47.53 | abhi2011 | <PROTECTED> |
| 02:47.54 | abhi2011 | <PROTECTED> |
| 02:47.56 | abhi2011 | <PROTECTED> |
| 02:47.57 | abhi2011 | <PROTECTED> |
| 02:47.59 | abhi2011 | ret = 1; |
| 02:48.01 | abhi2011 | failed_cnt++; |
| 02:48.03 | abhi2011 | (void)fprintf(stream, "Failed function %lu test case on line %lu expected = %.15f result = %.15f\n", |
| 02:48.05 | abhi2011 | <PROTECTED> |
| 02:48.07 | abhi2011 | <PROTECTED> |
| 02:48.08 | abhi2011 | success_cnt++; |
| 02:48.10 | abhi2011 | <PROTECTED> |
| 02:48.12 | abhi2011 | } catch( char *str ) { |
| 02:48.13 | abhi2011 | <PROTECTED> |
| 02:48.15 | abhi2011 | <PROTECTED> |
| 02:48.17 | abhi2011 | <PROTECTED> |
| 02:48.19 | abhi2011 | <PROTECTED> |
| 02:48.20 | abhi2011 | } |
| 02:48.22 | abhi2011 | bu_setjmp_valid=0; |
| 02:52.03 | LainIwakuraX | codepad.org |
| 02:57.23 | abhi2011 | :P.....ok |
| 03:21.57 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 03:28.23 | brlcad | starseeker: it probably was, but then that is curious in itself in that the exact previous command was "cmake ." |
| 03:28.37 | brlcad | abhi2011: omg, dude pastebin next time |
| 03:28.40 | brlcad | ~pastebin |
| 03:28.40 | ibot | [~pastebin] A "pastebin" is a web-based service where you should paste anything over 3 lines so you don't flood the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://bin.cakephp.org/ , http://asterisk.pastey.net/ , or install pastebinit with yum or aptitude. |
| 03:30.41 | brlcad | 3 lines is a bit crazy, but more than 5 or so, definitely |
| 03:31.26 | brlcad | that many lines pretty much halts the channel while it's pasting to everyone (you may see it instantly, but in reality, it ticks off about 1 line a second) |
| 03:32.13 | brlcad | the task it to structure the jumps into try/catch *style*, not actual try/catch syntax .. lots of examples in the code that are converted already |
| 03:47.12 | brlcad | abhi2011: unless you're already familiar with C jumps (longjmp() and friends), a better use of your time would something that gets you working in libged |
| 03:47.24 | brlcad | like fixing the 'analyze' command output formatting |
| 03:49.02 | brlcad | or related, https://sourceforge.net/tracker/?func=detail&aid=2954409&group_id=105292&atid=640805 albeit a little bit harder than fixing the output formatting |
| 03:51.41 | brlcad | or letting the cp command take multiple arguments for simultaneously creating named copies, relatively simple logic mod to a libged command |
| 03:51.58 | brlcad | TODO and BUGS files list dozens of potential things more apropos than the dev quickies |
| 05:16.02 | *** join/#brlcad Calin (~Calin@109.99.20.242) | |
| 06:10.40 | *** join/#brlcad Stattrav (~Stattrav@122.167.229.132) | |
| 06:10.40 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:42.28 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:45.35 | ``Erik | I don't see those cmake tests run on builds, could it be that you had an ntpdate pump that shifted the time back enough to rerun cmake? |
| 08:08.38 | *** join/#brlcad tharis20_ (~tharis@bl21-62-152.dsl.telepac.pt) | |
| 08:44.55 | abhi2011 | right , will take care to pastebin next time |
| 10:09.17 | abhi2011 | by the way, I was wondering if my basic patch (id: 3376910) has a usable .diff file |
| 10:29.22 | CIA-62 | BRL-CAD: 03Martinpaul 07http://brlcad.org * r3034 10/wiki/Main_Page: |
| 11:04.39 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 12:33.41 | brlcad | not very likely, and I've seen it before |
| 12:34.09 | brlcad | abhi2011: hadn't looked yet but that's part of that process, to make sure everything is right |
| 12:36.44 | starseeker | cmake will automatically re-run if the CMakeLists.txt files or .cmake files have been changed at all |
| 12:37.38 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3035 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/Martinpaul|Martinpaul]] ([[User talk:Martinpaul|Talk]]); changed back to last version by [[User:Sean|Sean]] |
| 12:37.48 | abhi2011 | ok thanks brlcad |
| 12:37.53 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Martinpaul]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 12:38.04 | abhi2011 | by the way does opengl support need to be turned on specifically for the autotools build |
| 12:38.38 | abhi2011 | after ./configure, I always get the Build with OpenGL support as ...no |
| 12:38.57 | abhi2011 | consequently after the compile mged does startup |
| 12:39.03 | abhi2011 | but archer does not |
| 12:39.47 | brlcad | archer requires opengl, mged does not |
| 12:40.00 | starseeker | in autotools opengl is off by default |
| 12:40.14 | brlcad | not it's not, it's autodetect by default :) |
| 12:40.35 | brlcad | ah, my bad |
| 12:40.40 | starseeker | eh? |
| 12:40.44 | brlcad | it *was* autodetect at some point |
| 12:40.56 | starseeker | ah :-) |
| 12:41.08 | brlcad | to many turn on, try, turn off doesn't work everywhere attempts |
| 12:47.49 | CIA-62 | BRL-CAD: 03brlcad * r45588 10/brlcad/trunk/include/fb.h: log the exact same thing we tested, print what should be the magic, not a pointer |
| 12:48.35 | CIA-62 | BRL-CAD: 03brlcad * r45589 10/brlcad/trunk/src/conv/ (bot_shell-vtk.c iges/add_loop.c): gcc 4.6 warning quellage |
| 12:55.09 | CIA-62 | BRL-CAD: 03brlcad * r45590 10/brlcad/trunk/src/other/iwidgets/pkgIndex.tcl: should no longer be keeping pkgIndex.tcl files (and other generated files) in the repo now that the msvc files are gone |
| 13:03.53 | CIA-62 | BRL-CAD: 03brlcad * r45591 10/brlcad/trunk/src/ (conv/bot_shell-vtk.c libbu/ptbl.c): call %zu instead of %z to be more consistent with the calls elsewhere |
| 13:19.48 | CIA-62 | BRL-CAD: 03brlcad * r45592 10/brlcad/trunk/src/conv/ (6 files in 3 dirs): more warning quellage. use %p instead of x%x, remove unused vars, cast accordingly |
| 13:22.27 | abhi2011 | right brlcad, so how do i turn it on in autotools |
| 13:36.26 | starseeker | --with-ogl |
| 13:37.59 | abhi2011 | thanks starseeker |
| 13:50.00 | CIA-62 | BRL-CAD: 03brlcad * r45593 10/brlcad/trunk/src/conv/dxf/dxf-g.c: remove unused variables, lots of unimplemented functionality apparently stubbed |
| 13:55.16 | CIA-62 | BRL-CAD: 03brlcad * r45594 10/brlcad/trunk/src/conv/g-egg.c: pass ncpu down through to db_walk_tree since it's only != 1 if user specifies it. remove unused vars. |
| 13:55.32 | CIA-62 | BRL-CAD: 03starseeker * r45595 10/brlcad/trunk/ (3 files in 2 dirs): |
| 13:55.32 | CIA-62 | BRL-CAD: CMake will check for third party libraries every time it is run (or rather, the |
| 13:55.32 | CIA-62 | BRL-CAD: ThirdParty.cmake macro logic will) but default to being quiet about it on |
| 13:55.32 | CIA-62 | BRL-CAD: subsequent runs unless there's actually something to report. By the same token, |
| 13:55.33 | CIA-62 | BRL-CAD: don't keep hammering on the build type. |
| 13:55.54 | starseeker | brlcad: I think that'll take care of the messages you were seeing |
| 14:09.39 | CIA-62 | BRL-CAD: 03brlcad * r45596 10/brlcad/trunk/src/ (17 files in 8 dirs): more gcc 4.6 quellage, eliminate set but unused variables, use void* for %p, and use %zu for size_t. |
| 14:11.57 | abhi2011 | hmm....some other library seems missing |
| 14:11.59 | abhi2011 | http://bin.cakephp.org/view/675147344 |
| 14:12.18 | abhi2011 | i have installed mesaGL, mesaGLU, freeglut |
| 14:15.20 | CIA-62 | BRL-CAD: 03brlcad * r45597 10/brlcad/trunk/src/rt/ (CMakeLists.txt Makefile.am scanline.c scanline.h viewmlt.c): |
| 14:15.20 | CIA-62 | BRL-CAD: remove rtmlt. it was never a completed nor working implementation of metropolis |
| 14:15.20 | CIA-62 | BRL-CAD: light transport. since it's become a maintenance burden (quellage) and isn't |
| 14:15.20 | CIA-62 | BRL-CAD: being worked on by anyone, time for removal. kunigami's progress on the osl |
| 14:15.20 | CIA-62 | BRL-CAD: integration is already further along, so renewed interest can be concentrated |
| 14:15.20 | CIA-62 | BRL-CAD: there. |
| 14:18.00 | brlcad | abhi2011: if you install new packages, you'll need to delete several cache files before rerunning configure, rm -rf *cache* |
| 14:18.21 | brlcad | then rerun configure, make sure it says opengl is enabled at the end |
| 14:19.33 | brlcad | if it still fails, pastebin the build failure from the compile line to the end (i.e., including the gcc line), not just the last few lines |
| 14:20.57 | abhi2011 | ok |
| 14:21.48 | brlcad | halfway through your warning log, so should have that retestable in a day or two |
| 14:23.12 | abhi2011 | ah ok thanks brlcad :) |
| 15:11.09 | CIA-62 | BRL-CAD: 03brlcad * r45598 10/brlcad/trunk/src/rt/CMakeLists.txt: remove trailing ws |
| 15:12.09 | CIA-62 | BRL-CAD: 03brlcad * r45599 10/brlcad/trunk/src/rt/ (scanline.c scanline.h): these files are not specific to rtmlt, partially revert r45597 to restore them |
| 15:15.24 | brlcad | starseeker: have I said how much I really like the subdir rebuilding with cmake, how it rebuilds all deps for a given subdir |
| 15:18.18 | CIA-62 | BRL-CAD: 03brlcad * r45600 10/brlcad/trunk/src/rt/viewarea.c: upgrade rtarea to size_t throughout. should help it handle 'massive' 64-bit geometries better than the previous long/int tracking it was using. |
| 15:21.08 | CIA-62 | BRL-CAD: 03brlcad * r45601 10/brlcad/trunk/src/rt/viewarea.c: reorder functions to avoid forward decls. |
| 15:28.08 | CIA-62 | BRL-CAD: 03brlcad * r45602 10/brlcad/trunk/src/rt/viewcheck.c: do the same for rtcheck, upgrade to counters to size_t |
| 15:33.35 | CIA-62 | BRL-CAD: 03brlcad * r45603 10/brlcad/trunk/src/rt/ (viewarea.c viewcheck.c): ws consistency cleanup |
| 15:46.11 | CIA-62 | BRL-CAD: 03brlcad * r45604 10/brlcad/trunk/src/rt/ (viewweight.c viewxray.c): use argv0 |
| 15:59.27 | CIA-62 | BRL-CAD: 03brlcad * r45605 10/brlcad/trunk/src/libicv/rot.c: use argv[0] instead of bu_getprogname() since the command name should still be there. make sure bu_optind is really 1, though. |
| 16:05.04 | CIA-62 | BRL-CAD: 03brlcad * r45606 10/brlcad/trunk/src/ (4 files in 2 dirs): quellage, set but unused variables, missing variables for print specifiers (crashy crashy) |
| 16:10.08 | CIA-62 | BRL-CAD: 03brlcad * r45607 10/brlcad/trunk/src/bwish/input.c: %S was deprecated a long while back, should be %V for vls |
| 16:27.56 | CIA-62 | BRL-CAD: 03brlcad * r45608 10/brlcad/trunk/src/mged/cmd.c: and this ever worked? hard to imagine a lot of people are using the 'lm' command since it seems to have been passing the wrong argv to ls.. there shouldn't be muves-specific commands in brl-cad anyways. |
| 16:37.25 | CIA-62 | BRL-CAD: 03brlcad * r45609 10/brlcad/trunk/src/proc-db/breplicator.cpp: heh, %0 |
| 16:42.26 | CIA-62 | BRL-CAD: 03brlcad * r45610 10/brlcad/trunk/src/shapes/coil.c: someone's editor leaves trailing whitespace turds all over the place |
| 16:53.46 | CIA-62 | BRL-CAD: 03brlcad * r45611 10/brlcad/trunk/include/fb.h: they're both uint32_t values, not a pointer |
| 17:12.19 | starseeker | brlcad: cool, thanks! glad you're finding something to like with the CMake build, was kinda afraid I was going to make your life miserable for the sake of cross platform building ;-) |
| 17:23.51 | CIA-62 | BRL-CAD: 03brlcad * r45612 10/brlcad/trunk/src/other/libz/ (zconf.h zconf.h.in): what if we just yank the whole _LARGEFILE64_SOURCE hack section. shouldn't need to muck with it. |
| 17:24.39 | brlcad | starseeker: oh, I like it, there's just a lot of polish needed |
| 17:26.04 | brlcad | the autotools build had many years to carefully tweak messages so that things are nearly as clear as possible (given the build infrastructure) making things as easy as possible for compiling-users, even if it meant more work on our end |
| 17:26.29 | brlcad | some of that has regressed a little bit, but nothing that can't be fixed and overall a step forward still |
| 17:29.23 | brlcad | others are just subtle changes here and there |
| 17:29.55 | CIA-62 | BRL-CAD: 03starseeker * r45613 10/brlcad/trunk/src/rt/CMakeLists.txt: |
| 17:29.55 | CIA-62 | BRL-CAD: Add M_LIBRARY to libremrt. BRLCAD_ADDLIB isn't used here because this library |
| 17:29.55 | CIA-62 | BRL-CAD: isn't installed and is only built as a static library - in the (relatively rare) |
| 17:29.55 | CIA-62 | BRL-CAD: cases in BRL-CAD where this is true we just use the raw cmake commands for |
| 17:29.55 | CIA-62 | BRL-CAD: library building rather than obfuscate the logic with more macros. |
| 17:30.55 | starseeker | brlcad: um. if we're going to yank that stuff out of zlib, should we submit a patch back? |
| 17:31.45 | brlcad | sure |
| 17:31.55 | starseeker | admittedly I've got non-vanilla changes in both libpng and zlib right now, but I've been planning to submit them all back to see if I can get 'em included (I'll probably have to upgrade our libpng version to get that to work so I haven't done it yet, but I need to.) |
| 17:32.15 | brlcad | are we up-to-date with zlib"? |
| 17:32.25 | brlcad | thought they had a new rev |
| 17:32.25 | starseeker | unless they've released a new version, yeah |
| 17:32.28 | starseeker | checks |
| 17:32.47 | starseeker | yeah - 1.2.5 |
| 17:33.00 | starseeker | upgraded a long while back to get the cmake file they included in that version |
| 17:33.15 | brlcad | still, that snippet seems a little strange, trying to detect if its set so they can unset it... they shouldn't care |
| 17:33.53 | starseeker | they did a couple odd things in that release - I've seen cases where mixing our zlib with system stuff using a system zlib has caused problems |
| 17:34.12 | brlcad | I'd put a patch into zconf.h to work around a compiler warning, but not into the zconf.h.in file cmake was using |
| 17:34.20 | brlcad | undoubtedly related to erik's later hack |
| 17:35.02 | starseeker | I haven't bugged 'em yet because the zlib CMakeLists.txt change is relatively minor (IIRC) but if we can fix that nonsense and really improve things it becomes worthwhile |
| 17:35.59 | CIA-62 | BRL-CAD: 03brlcad * r45614 10/brlcad/trunk/src/ (24 files in 9 dirs): quell majority remainder of gcc 4.6 warnings from user log. mostly pointer casts, print specifier, and set but unused variable warnings. still need to sort out the %V warnings. |
| 17:38.08 | brlcad | hm, so somewhere in the debug/not-debug settings, it's issuing %V warnings with the cmake build ... gets back to an earlier discussion on how that warning was being suppressed |
| 17:39.19 | brlcad | looks like STRICT_FLAGS isn't being set |
| 17:39.28 | starseeker | um. |
| 17:41.48 | brlcad | I see a snippet in the CMakeLists.txt file, looks like it should be getting set |
| 17:42.16 | starseeker | I may have messed up somewhat with all that... was trying to be clever about having Debug and Release build types "do the right thing" to make life easy |
| 17:42.19 | brlcad | oh, maybe he turned off strict so they got reported... |
| 17:42.44 | brlcad | shakes fist at cmake log for now showing the gcc lines |
| 17:42.49 | brlcad | s/now/not!/ |
| 17:42.59 | brlcad | I love it and hate it |
| 17:43.25 | starseeker | make VERBOSE=1 ? |
| 17:43.26 | brlcad | they gotta fix that |
| 17:43.39 | brlcad | that's not really what I want, though |
| 17:43.43 | brlcad | that's all or nothing |
| 17:43.51 | brlcad | I want to just see the gcc lines for the compiles that fail |
| 17:45.24 | brlcad | kind of like what autogen.sh does, you run the command, capture the output, check the return value; if succeeded, keep quiet, but if failed, show the actual command and error it produced |
| 17:45.50 | brlcad | should be pretty trivial |
| 17:46.04 | brlcad | for some definition of trivial to the cmake devs :) |
| 17:47.01 | brlcad | starseeker: so refresher understanding just to make sure, turning on warnings just turns on all the -Wwhatever warning flags, yes? and turning on strict basically adds -Werror so they halt |
| 17:47.11 | starseeker | right |
| 17:47.28 | brlcad | okay, so then that might be a done deal then |
| 17:47.42 | starseeker | except that when we add Werror I think we turn off that printf one since we can't comply with it |
| 17:47.42 | brlcad | we might be gcc 4.6 clean now, or at least very very close to it |
| 17:47.47 | brlcad | right |
| 17:47.54 | brlcad | that's header logic, though, not build logic |
| 17:48.32 | starseeker | hmm. I might have gilded the lily there - would need to check |
| 17:48.33 | brlcad | keys off of the STRICT_FLAGS setting, that's what had me wondering |
| 17:49.14 | brlcad | wonders where bhinesley is |
| 17:50.45 | brlcad | downloads gcc 4.6 |
| 17:51.03 | starseeker | dunno, haven't heard from him today |
| 17:52.39 | brlcad | wow, make clean doesn't give any output? |
| 17:52.52 | starseeker | nope - just cleans |
| 17:52.55 | brlcad | ouch :) |
| 17:53.14 | starseeker | make clean VERBOSE=1 :-P |
| 17:53.54 | brlcad | some feedback would be useful for a command that takes several minutes to run, locks up I/O, looks like something stuck in an inf loop |
| 17:54.23 | starseeker | brlcad: are you subscribed to the CMake email list? It's usually quite responsive |
| 17:54.33 | brlcad | not at the moment |
| 17:55.03 | starseeker | most of these sorts of questions I end up going to there to try and answer anyway, so you might as well cut out the middleman :-P |
| 17:55.11 | brlcad | wow, make clean is brining this system to its knees, can't even keep up with typing |
| 17:55.21 | starseeker | that's... quite odd |
| 17:56.28 | brlcad | hm, not make |
| 17:56.59 | brlcad | looks like safari went nuts too, maybe the i/o slowness hit some bug |
| 18:09.14 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.90) | |
| 18:09.14 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:14.15 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.145.200) | |
| 18:28.43 | *** join/#brlcad Stattrav (~Stattrav@117.192.143.204) | |
| 18:28.43 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:31.51 | abhi2011 | does brlcad depend on libdm ? |
| 18:32.12 | abhi2011 | because the build fails on a file which uses libdm |
| 18:32.28 | abhi2011 | dm-ogl.c |
| 18:32.33 | starseeker | libdm is one of BRL-CAD's libraries |
| 18:32.36 | starseeker | what's the error? |
| 18:33.42 | abhi2011 | http://bin.cakephp.org/view/1720792653 |
| 18:34.15 | abhi2011 | i did configure before with ogl |
| 18:34.33 | starseeker | um. You're building with autotools I take it? |
| 18:34.40 | abhi2011 | yes |
| 18:34.45 | abhi2011 | i ll try make clean |
| 18:34.50 | abhi2011 | and configure again |
| 18:34.53 | starseeker | libdm built with opengl enabled? |
| 18:35.16 | starseeker | what that looks like offhand is that mged is being built with opengl on but libdm was built with it off - odd |
| 18:35.22 | abhi2011 | well i havent checked the complete logs yet |
| 18:35.33 | abhi2011 | hmmm |
| 18:36.07 | abhi2011 | maybe the cache was not clean from the previous builds |
| 18:36.17 | starseeker | I'd try that first - clean build |
| 18:36.28 | abhi2011 | yep |
| 18:42.05 | brlcad | abhi2011: you have to clean the cache and, of course, also delete your previous builds.... |
| 18:42.25 | abhi2011 | right |
| 18:42.36 | brlcad | so not just rm -rf *cache* |
| 18:42.41 | brlcad | but also make clean |
| 18:43.05 | brlcad | might be easier for you to just start fresh since the build system seems to be a bit foreign |
| 18:43.19 | brlcad | with a new checkout |
| 18:48.04 | CIA-62 | BRL-CAD: 03starseeker * r45615 10/brlcad/trunk/src/other/iwidgets.dist: Ain't there so don't ignore it anymore. |
| 18:48.07 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-125-86-110.dsl.bkfd14.sbcglobal.net) | |
| 18:48.15 | starseeker | bhinesley: howdy :-) |
| 18:48.33 | bhinesley | starseeker: hello :) |
| 18:48.37 | abhi2011 | right, i ll checkout fresh |
| 18:48.51 | starseeker | bhinesley: how goes the edit.c work? |
| 18:49.18 | *** join/#brlcad Stattrav (~Stattrav@117.192.143.204) | |
| 18:49.18 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:49.33 | bhinesley | it's going good |
| 18:49.43 | bhinesley | taking a lot longer than I thought |
| 18:49.50 | bhinesley | but good |
| 18:50.07 | starseeker | you're working on option parsing still, or is that wrapping up? |
| 18:50.21 | bhinesley | that's done, more or less |
| 18:50.48 | starseeker | cool - so what's your next step? |
| 18:52.04 | bhinesley | ged_edit passes off to edit(), which will build the (point_t) arguments for the subcommands |
| 18:52.42 | bhinesley | so the next step is edit(); do command specific argument validation, convert objects + offsets to points, and pass off to the subcommands to do the work |
| 18:53.01 | bhinesley | oh, and edit() handles the batch operations |
| 18:53.23 | *** join/#brlcad CalinPaulAlexand (~Calin@109.99.20.242) | |
| 18:53.36 | bhinesley | so if "." is specified as an object, it will convert that to multiple calls to the subcommand, replacing "." with the next object being operated on |
| 18:53.47 | starseeker | brlcad: ah-ha http://mail.madler.net/pipermail/zlib-devel_madler.net/2011-June/002581.html |
| 18:54.54 | bhinesley | misses colored nicks in irssi |
| 18:56.11 | starseeker | bhinesley: cool :-) |
| 18:56.45 | brlcad | bhinesley: were your ears burning? |
| 18:57.09 | bhinesley | brlcad: my ears? |
| 18:57.22 | brlcad | was just talking about you a little while ago |
| 18:57.28 | bhinesley | oh :) |
| 18:58.16 | bhinesley | good things I hope ;-) |
| 18:58.18 | starseeker | gah - zlib doesn't seem to have a public dev repository! |
| 18:58.54 | brlcad | starseeker: you mean, https://gforge.sci.utah.edu/gf/project/zlib/scmsvn/ ? |
| 18:59.36 | starseeker | mutter - how'd I miss that? |
| 18:59.50 | brlcad | starseeker: doesn't look like cmake even provides what I'd want for make clean |
| 19:00.25 | brlcad | make clean VERBOSE=1 doesn't really show anything useful, just a bunch of cd calls and sub-make reinvocations (and VERBOSE isn't preserved) |
| 19:00.59 | starseeker | brlcad: true, but it does at least give you feedback that something is happening |
| 19:01.12 | brlcad | I'd want to see either what files are being deleted, what directories/targets are being processed, or both |
| 19:01.16 | brlcad | actual files |
| 19:01.26 | starseeker | nods - yeah, I don't know of any way to get it to do that |
| 19:01.36 | starseeker | never really cared, personally... |
| 19:01.56 | brlcad | usability nitpick |
| 19:02.05 | brlcad | if it was instant, wouldn't care .. but it takes several minutes |
| 19:03.06 | starseeker | growl. Looks like vanilla zlib won't be workable at least until they stick 1.2.6 up somewhere |
| 19:03.13 | brlcad | I can't glance at it and tell if it's got 2 seconds or 200 seconds remaining, or if it's just stuck |
| 19:03.58 | starseeker | you're on a Mac? |
| 19:04.10 | brlcad | sometimes |
| 19:04.23 | bhinesley | 's panic subsides; ahh, colored nicks |
| 19:04.24 | starseeker | I mean, the make clean is taking several minutes on a mac? |
| 19:04.49 | brlcad | my previous build was, yes |
| 19:04.59 | brlcad | could have been related to safari going nuts |
| 19:04.59 | starseeker | tries it on Linux quick... |
| 19:05.06 | brlcad | but that's the point, there's zero feedback |
| 19:05.39 | starseeker | took < 10 seconds here |
| 19:05.42 | brlcad | if your linux box is thrashing or if you were on an nfs filesystem, the same would affect you there |
| 19:06.36 | brlcad | a second pass make clean only takes a few seconds here too, several factors |
| 19:07.31 | brlcad | otherwise by that same logic, I wouldn't need 'top' because well, most of the time everything runs fine |
| 19:08.03 | starseeker | nods - oh, I see the logic but that's probably why it wasn't a high priority for them |
| 19:12.02 | brlcad | yeah, even an already cleaned build takes about 20 seconds |
| 19:12.11 | brlcad | proably all of the reinvocations of make for every target |
| 19:12.30 | brlcad | that and this laptop isn't the quickest |
| 19:14.02 | starseeker | tosses together an email to the zlib devs... |
| 19:15.23 | brlcad | starseeker: how about a simple echo/output line on the clean rule that just says "Deleting build files, please wait..." |
| 19:15.31 | brlcad | where would that go? |
| 19:16.18 | starseeker | brlcad: unfortunately, the clean rule isn't something that can be user-modified yet - IIRC that's one of the issues they most commonly get requested to fix |
| 19:16.25 | starseeker | checks archives... |
| 19:17.01 | brlcad | ah, k |
| 19:17.03 | starseeker | http://www.cmake.org/pipermail/cmake/2006-October/011477.html |
| 19:17.26 | starseeker | old email though - don't know what current status is |
| 19:17.33 | brlcad | yeah, quite |
| 19:18.31 | starseeker | yeah, still an issue in 09: http://www.cmake.org/pipermail/cmake/2009-January/026727.html |
| 19:20.01 | starseeker | somewhat related: http://www.cmake.org/Bug/view.php?id=10424 |
| 19:21.02 | starseeker | ah, I think this was the actual issue: http://www.cmake.org/Bug/view.php?id=6183 |
| 19:22.51 | brlcad | it's not clear if that last one is saying that it's not possible or that it is possible given that additional info statemetn |
| 19:23.23 | starseeker | as far as I know it's not possible, but then I haven't really pushed hard to try it |
| 19:23.23 | brlcad | or are they just saying "it wouldn't be hard to support adding custom commands" |
| 19:23.37 | starseeker | I think so - I think the guy making the report was making the case that it's a simple change |
| 19:23.58 | starseeker | I've seen other comments on the issue (that I can't scare up right now) that indicated it wasn't quite so simple though |
| 19:24.07 | brlcad | k |
| 19:24.14 | brlcad | I'll suck it up for now |
| 19:24.27 | starseeker | (I suppose patches welcome :-P) |
| 19:43.54 | bhinesley | is it okay to use SMALL_FASTF/MAX_FASTF as sentinal values? |
| 19:44.16 | starseeker | what do you mean by sentinal values? |
| 19:44.38 | bhinesley | I could use a way to indicate that a particular coordinate of a vector has not been set |
| 19:45.10 | bhinesley | so could I set, say coord[1] = MAX_FASTF, since it will never be used in practice |
| 19:45.22 | starseeker | oh - I believe that's workable |
| 19:45.25 | starseeker | brlcad? |
| 19:59.25 | *** join/#brlcad CalinPaulAlexand (~Calin@109.99.20.242) | |
| 20:10.37 | CIA-62 | BRL-CAD: 03starseeker * r45616 10/brlcad/trunk/src/other/libpng/ (175 files in 21 dirs): |
| 20:10.37 | CIA-62 | BRL-CAD: libpng-1.5.x is the current stable libpng series now. Update to libpng 1.5.4, |
| 20:10.37 | CIA-62 | BRL-CAD: 'cause that's what all the cool kids are doing. (API cleanup is a good thing, |
| 20:10.37 | CIA-62 | BRL-CAD: too...) Starting with a vanilla check-in, will probably need to re-apply |
| 20:10.37 | CIA-62 | BRL-CAD: Makefile.am changes and will definitely need to port CMakeLists.txt changes |
| 20:10.38 | CIA-62 | BRL-CAD: forward. Will be submitting the CMakeLists.txt changes back to see if we can |
| 20:10.39 | CIA-62 | BRL-CAD: get them included in the next version of libpng. |
| 20:12.13 | CIA-62 | BRL-CAD: 03starseeker * r45617 10/brlcad/trunk/src/ (fb/fb-png.c libged/png.c other/libpng.dist util/pix-png.c): fix header includes for 1.5 libpng - need explicit zlib.h in a couple places. |
| 20:16.24 | *** join/#brlcad CalinPaulAlexand (~Calin@109.99.20.242) | |
| 20:21.57 | *** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net) | |
| 20:22.22 | brlcad | bhinesley: those are terrible sentinal values because they're frequently valid and will match a simple == 0 comparison |
| 20:22.45 | brlcad | usual practice is either a separate set/unset variable flag |
| 20:22.58 | brlcad | or use -INFINITY/INFINITY |
| 20:23.22 | brlcad | which still isn't full-proof safe, but "good enough" in practice |
| 20:23.34 | starseeker | brlcad: hmm. do similar concerns apply to the use of (say) MAX_INT? |
| 20:24.33 | brlcad | presuming you mean INT_MAX, that's effectively == INFINITY for the int type |
| 20:24.40 | bhinesley | alright, the flags will work fine; I already have a mechanism for that |
| 20:24.44 | starseeker | ah, k |
| 20:25.04 | brlcad | it's harder for integer types, though, since you can interate to infinity pretty easily |
| 20:25.23 | brlcad | so the code has to work harder to make sure you're always < INT_MAX, not <= |
| 20:25.32 | brlcad | better is flags ;) |
| 20:29.05 | LainIwakuraX | brlcad: I'm here for about...2 hours and here again later tonight if you were going to test the patch I made (and want me here for the testing) |
| 20:30.56 | starseeker | LainIwakuraX: are you applying to the ESA Summer of Code? |
| 20:32.12 | LainIwakuraX | starseeker: No, although I am qualified. |
| 20:32.51 | starseeker | LainIwakuraX: awesome work wading through that SCLString code :-) |
| 20:33.10 | LainIwakuraX | It wasn't that bad =P |
| 20:33.46 | LainIwakuraX | Should I apply for ESA Summer of Code? The thing stopping me was the proposal...it seems hard =/ |
| 20:33.58 | brlcad | LainIwakuraX: maybe not that hard, but editing about 900 lines that have to be manually adapted is still a lot of appreciated effort |
| 20:34.10 | LainIwakuraX | Ah |
| 20:34.22 | LainIwakuraX | When I got tired |
| 20:34.24 | LainIwakuraX | in vim |
| 20:34.31 | LainIwakuraX | :%s/SCLstring/std::string/g |
| 20:34.34 | LainIwakuraX | >_> |
| 20:34.51 | brlcad | :) |
| 20:35.06 | brlcad | that's the easy part, then you had to adapt all of the callers |
| 20:35.10 | starseeker | LainIwakuraX: what seemed hard about the proposal? |
| 20:35.19 | brlcad | of course, still have to see if it actually works ;) |
| 20:36.00 | LainIwakuraX | starseeker: A lot of the projects being proposed are a bit advanced, I'm only going into my second year of comp sci. at University |
| 20:36.35 | bhinesley | LainIwakuraX: me too, but I was accepted into GSoC |
| 20:36.36 | bhinesley | :) |
| 20:36.40 | starseeker | LainIwakuraX: http://brlcad.org/wiki/STEP_Libraries |
| 20:36.42 | starseeker | :-P |
| 20:37.06 | starseeker | http://brlcad.org/wiki/ESA_Summer_of_Code_in_Space/Project_Ideas, under Geometry Conversion Projects |
| 20:37.17 | LainIwakuraX | uhh |
| 20:37.19 | LainIwakuraX | I see |
| 20:37.27 | LainIwakuraX | I guess I will apply lol |
| 20:37.47 | bhinesley | well, third actually... but I'm only just now transferring to the university after taking a grand total of 3 programming classes |
| 20:37.53 | LainIwakuraX | ah |
| 20:38.31 | LainIwakuraX | I've only taken 1 C++ course..but I had a good teacher =P |
| 20:38.41 | bhinesley | I thought the same thing that you did though. I saw a bunch of PhD/Masters students and thought that I was out of my leauge, but here I am. |
| 20:38.46 | brlcad | yay, got step-g to crash |
| 20:38.53 | LainIwakuraX | uh oh |
| 20:39.05 | bhinesley | LainIwakuraX: same here. I've taken Java, C, and C++, but that's it. |
| 20:39.26 | LainIwakuraX | brlcad: are you treating warnings as errors? |
| 20:39.26 | brlcad | LainIwakuraX: not your patch |
| 20:39.29 | LainIwakuraX | oh |
| 20:39.35 | LainIwakuraX | don't scare me lol |
| 20:40.18 | brlcad | test file I fed it was a bit insane |
| 20:41.08 | starseeker | LainIwakuraX: when I saw your patch I actually thought it was your patch submission for the ESA SoC application :-P |
| 20:41.53 | LainIwakuraX | No, I just wanted to get involved ._. |
| 20:42.01 | starseeker | awesome :-) |
| 20:42.09 | LainIwakuraX | I guess I'll reference the patch on my application though |
| 20:43.09 | LainIwakuraX | Where do I go to apply? I lost the link |
| 20:43.45 | starseeker | http://sophia.estec.esa.int/socis2011/ |
| 20:43.55 | starseeker | http://brlcad.org/wiki/ESA_Summer_of_Code_in_Space |
| 20:45.17 | LainIwakuraX | How many hours does this usually take up? I did that SCLstring thing in about 5 hours, but I do have a part-time job in web development |
| 20:48.29 | LainIwakuraX | Hm..I guess it'd depend a lot on what you were doing |
| 20:49.14 | brlcad | LainIwakuraX: it's generally expected that the SoC programs constitute full-time 40+ hours effort |
| 20:49.36 | brlcad | if you have another job, might just want to keep it to a hobby .. less pressure, much more fun ;) |
| 20:49.42 | brlcad | scratch your own itches |
| 20:49.53 | starseeker | LainIwakuraX: yeah, definitely the low-pressure way to go |
| 20:50.03 | LainIwakuraX | brlcad: My other job is pretty...flexible |
| 20:50.12 | LainIwakuraX | I'm applying =P |
| 20:51.28 | brlcad | :) |
| 20:52.31 | brlcad | another thing to keep in mind, given a space agency is sponsoring this, given two roughly equivalent applicants .. priority will go towards development that is directly space-related |
| 20:52.47 | LainIwakuraX | Mhm |
| 20:52.56 | brlcad | having two "roughly equivalent" applicants is unlikely, but worth saying nonetheless ;) |
| 20:53.12 | brlcad | well, no compilation failures with the step patch |
| 20:54.42 | LainIwakuraX | =P I wasn't lying |
| 21:03.00 | CIA-62 | BRL-CAD: 03brlcad * r45618 10/brlcad/trunk/src/ (44 files in 10 dirs): |
| 21:03.00 | CIA-62 | BRL-CAD: apply sf patch 3376896 (All instances of SCLstring changed to std::string) from |
| 21:03.00 | CIA-62 | BRL-CAD: lainiwakurax. patch converts scl converts almost all instances of SCLstring in |
| 21:03.00 | CIA-62 | BRL-CAD: SCL to standard STL strings. tested minimally with a few ap203 conversions that |
| 21:03.00 | CIA-62 | BRL-CAD: all seemed to parse and convert equivalently. outstanding. |
| 21:03.51 | LainIwakuraX | It worked? |
| 21:05.18 | CIA-62 | BRL-CAD: 03brlcad * r45619 10/brlcad/trunk/AUTHORS: credit Zach Easterbrook (lainiwakurax) as a code contributor with his code patch that converted SCLstring to std::string in src/conv/step and src/other/step. thanks, Zach! |
| 21:05.34 | brlcad | looks like it |
| 21:05.39 | LainIwakuraX | =D Awesome |
| 21:07.30 | brlcad | yeah, quite |
| 21:08.19 | LainIwakuraX | I'm not surprised there wasn't much of a time difference, their functions were very similar to the ones in std::string |
| 21:08.20 | CIA-62 | BRL-CAD: 03brlcad * r45620 10/brlcad/trunk/TODO: lainiwakurax replaced SCLstring with std::string (via sf patch 3376896) |
| 21:08.34 | brlcad | the implementation of those functions are quite different |
| 21:08.48 | LainIwakuraX | Ah |
| 21:09.24 | brlcad | I noticed a few dozen instances of SCLstring still remain, were they problematic? |
| 21:09.33 | brlcad | or did you only fix the ones that affected compilation? |
| 21:09.52 | LainIwakuraX | I'd say I fixed 99% of them...there were some in blocks like this: |
| 21:09.58 | LainIwakuraX | #ifdef __OSTORE__ |
| 21:10.06 | LainIwakuraX | and they used a function (get_os_typespec) |
| 21:10.11 | LainIwakuraX | and I didn't know what it did |
| 21:10.47 | LainIwakuraX | soo I focused on the ones where I knew what was going on |
| 21:14.20 | LainIwakuraX | one sec I'm finding the spot where that is |
| 21:14.21 | brlcad | yeah, OSTORE is a bit of a mystery, but looks like a partial interface for automatic serialization for an object store |
| 21:14.52 | brlcad | don't see anything that turns OSTORE on/off, though |
| 21:15.22 | LainIwakuraX | if you go to errordesc.cc in clutils |
| 21:15.33 | LainIwakuraX | around line 189 you'll see some spots where it's still SCLstring |
| 21:15.40 | LainIwakuraX | they're in those blocks |
| 21:15.59 | brlcad | nods |
| 21:16.09 | brlcad | those OSTORE blocks can probably just be deleted |
| 21:16.22 | LainIwakuraX | wait, there is stuff in else blocks |
| 21:16.35 | LainIwakuraX | that I didn't catch =/ would those matter? |
| 21:17.18 | LainIwakuraX | http://codepad.org/lsTE2mHV |
| 21:17.22 | brlcad | probably, but apparently they're self-contained |
| 21:17.33 | brlcad | probably got lucky since they're just used for error reporting |
| 21:18.06 | brlcad | fg |
| 21:18.54 | LainIwakuraX | I'll fix those instances in the else's in a few minutes, to be safe |
| 21:19.10 | brlcad | the final test will be the removal of the sclstring class |
| 21:19.24 | LainIwakuraX | mhm |
| 21:19.36 | CIA-62 | BRL-CAD: 03starseeker * r45621 10/brlcad/trunk/src/other/step/src/clutils/ (CMakeLists.txt scl_string.cc scl_string.h): Doesn't look like scl_string.cc/h are being used - yank |
| 21:20.27 | brlcad | heh |
| 21:20.34 | brlcad | starseeker: it's still used in a few places |
| 21:20.44 | starseeker | builds |
| 21:20.51 | brlcad | maybe not in a portion enabled in our build |
| 21:24.40 | starseeker | man - no indication in the docs as to what OSTORE is for that I can see |
| 21:25.21 | LainIwakuraX | should I bother fixing the SCLstring instances in those OSTORE blocks? |
| 21:25.49 | starseeker | brlcad: what do you think? |
| 21:26.51 | starseeker | LainIwakuraX: I think you can try switching it in errordecs.h to start and see what follows... |
| 21:27.37 | LainIwakuraX | k |
| 21:28.12 | CIA-62 | BRL-CAD: 03brlcad * r45622 10/brlcad/trunk/src/other/libpng/ (8 files): remove autogenerated build files. have to play nicely with autotools build until it's obsolete. |
| 21:30.03 | LainIwakuraX | since you removed those files...I'm getting a cmake error |
| 21:30.14 | LainIwakuraX | CMake Error at misc/CMake/BRLCAD_Util.cmake:214 (MESSAGE): Attempting to ignore non-existent file /home/yuki/bin/brlcad/src/other/step/src/clutils/scl_string.h |
| 21:30.24 | starseeker | LainIwakuraX: er, sorry |
| 21:30.30 | starseeker | got a bit too eager |
| 21:30.34 | LainIwakuraX | =P |
| 21:31.04 | brlcad | ignore the OSTORE blocks |
| 21:31.20 | LainIwakuraX | kk |
| 21:31.23 | brlcad | or separate patch to remove them |
| 21:32.05 | CIA-62 | BRL-CAD: 03starseeker * r45623 10/brlcad/trunk/src/other/step/src/clutils/ (scl_string.cc scl_string.h): Wait until we're sure they're gone. |
| 21:33.00 | CIA-62 | BRL-CAD: 03starseeker * r45624 10/brlcad/trunk/src/other/step/src/clutils/CMakeLists.txt: CMakeLists.txt too |
| 21:33.46 | LainIwakuraX | I'm thinking of proposing this: http://brlcad.org/wiki/Density_functions |
| 21:34.07 | LainIwakuraX | thoughts? It seems interesting |
| 21:34.23 | LainIwakuraX | and I like functions..for describing things =P |
| 21:36.37 | brlcad | thoughts as in? |
| 21:36.49 | starseeker | heh - had enough of the SCL code? :-P Main thing is to pick something you think would interest you and you'd enjoy working on |
| 21:36.56 | brlcad | it's an interesting priority topic, very very closely related to another non-priority topic too: http://brlcad.org/wiki/Material_and_Shader_Objects |
| 21:37.39 | LainIwakuraX | Hm, well it's listed as "difficult" but the SCLstring thing was "medium" and I did it in 5 hours |
| 21:38.44 | LainIwakuraX | So you guys know more about this system =/ do you think it'd be fun and challenging? |
| 21:40.05 | LainIwakuraX | But still reasonable enough for someone who hasn't worked on BRL-CAD |
| 21:40.07 | LainIwakuraX | I suppose |
| 21:42.50 | brlcad | heh, "medium" in terms of being a quickie |
| 21:43.02 | starseeker | LainIwakuraX: we can't guide you too much - you're the one who will know what is interesting. I will say that when we say it's "HARD" we generally aren't kidding |
| 21:43.04 | brlcad | that's on a rough "doable within a couple days" scale |
| 21:43.27 | brlcad | the summer of code projects are on a doable within a couple months scale" |
| 21:44.11 | LainIwakuraX | Ah |
| 21:44.49 | LainIwakuraX | Well, I'll research this a bit and have the submission sometime tonight |
| 21:45.05 | starseeker | the SCLstring thing basically was a warm up for the Step Library cleanup task |
| 21:45.10 | starseeker | there's a lot more waiting |
| 21:45.18 | LainIwakuraX | ah |
| 21:45.38 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3036 10/wiki/Contributor_Quickies: LainIwakuraX converted scl to stl, sclstring to std::string |
| 21:46.20 | starseeker | LainIwakuraX: notice too that although all of the functional instances of SCLstring were changed, it's still not quite fully purged |
| 21:47.54 | starseeker | brlcad: I didn't see the ESA task criteria (if any) - did they lay out particular areas they wanted to see worked? |
| 21:49.03 | brlcad | not in specific detail, similar to gsoc they're mostly hands off but their interest (and the business case to their management) is pretty clear |
| 21:49.19 | starseeker | yeah, looks like the OSTORE stuff involves something called ostore.h, which isn't in the NIST repostory |
| 21:49.32 | brlcad | starseeker: I wouldn't worry about OSTORE, it's dead code |
| 21:49.37 | brlcad | no way to turn it on means it's dead |
| 21:49.38 | starseeker | nods |
| 21:49.51 | brlcad | sounds like something that would be added for CORBA |
| 21:49.56 | starseeker | winces |
| 21:50.20 | brlcad | so just yank it |
| 21:50.26 | starseeker | nods |
| 21:50.46 | brlcad | goes to coach for a bit |
| 21:52.13 | LainIwakuraX | Question about the density functions, it says: "Material objects should be BRL-CAD database objects that can be referenced (by name) by other db objects" |
| 21:52.19 | LainIwakuraX | Are these objects like, structs? |
| 21:52.42 | starseeker | no, that's referring to an object in a BRL-CAD .g database |
| 21:52.51 | LainIwakuraX | Ah |
| 21:53.24 | LainIwakuraX | Is there a brief way to describe how these objects are formed? |
| 21:57.45 | CIA-62 | BRL-CAD: 03starseeker * r45625 10/brlcad/trunk/src/other/step/src/ (clstepcore/ExpDict.cc clstepcore/sdaiSelect.cc clutils/Str.h): Remove some commented out code containing SCLstring |
| 21:58.23 | starseeker | LainIwakuraX: not really a "brief" way - you can look at the primitives in src/librt/primitives for some examples... |
| 21:59.42 | LainIwakuraX | kk |
| 22:10.18 | LainIwakuraX | I can submitted a link to a google doc document for the proposal, correct? |
| 22:10.30 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 22:10.49 | starseeker | LainIwakuraX: dunno, question for brlcad |
| 22:11.17 | LainIwakuraX | ah |
| 22:20.14 | CIA-62 | BRL-CAD: 03starseeker * r45626 10/brlcad/trunk/src/other/step/src/ (5 files in 2 dirs): remove remainder of SCLstring uses |
| 22:27.59 | LainIwakuraX | I'm out for a while, see you guys in ~2 hrs |
| 22:43.02 | abhi2011 | got archer runnning finally |
| 22:43.26 | abhi2011 | got a funny opengl warning as well : OpenGL Warning: No pincher, please call crStateSetCurrentPointers() in your SPU |
| 22:45.49 | abhi2011 | wow!!..rt just rox! |
| 22:45.58 | abhi2011 | rendered a sphere :P |
| 22:59.59 | CIA-62 | BRL-CAD: 03starseeker * r45627 10/brlcad/trunk/src/other/step/src/ (17 files in 3 dirs): Take a stab at removing scl_string altogether. |
| 23:04.46 | *** join/#brlcad starseek1r (~starseeke@BZ.BZFLAG.BZ) | |
| 23:05.00 | starseek1r | ah, fudge - step-g isn't working for me |
| 23:11.13 | starseeker | happened after the initial application of the patch (on Linux) |
| 23:11.31 | starseeker | LainIwakuraX: can you build BRL-CAD as a whole? |
| 23:11.47 | starseeker | I'm getting the following error: |
| 23:11.48 | starseeker | terminate called after throwing an instance of 'std::logic_error' what(): basic_string::_S_construct NULL not valid |
| 23:11.51 | starseeker | Aborted |
| 23:14.44 | starseeker | running the command ./bin/step-g -o test.g ../brlcad/src/other/step/data/ap203/cube1.p21 |
| 00:46.55 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 01:39.59 | LainIwakuraX | starseeker: I can build BRL-CAD as a whole, if you check my patch it's the environment |
| 01:40.28 | starseeker | LainIwakuraX: what behavior do you see if you try the above? |
| 01:40.43 | LainIwakuraX | 1 sec |
| 01:41.00 | LainIwakuraX | yeah I get that too |
| 01:41.19 | starseeker | hrm |
| 01:42.12 | LainIwakuraX | how do I track down that sort of thing? =/ |
| 01:42.26 | starseeker | LainIwakuraX: gdb to start with |
| 01:42.52 | starseeker | figure out which call is producing the error, examine the data being fed in and why it's wiping out |
| 01:43.41 | LainIwakuraX | ah okay..first time working with gdb, I'll try to get this sorted |
| 01:43.56 | starseeker | it's a good skill to have :-) |
| 01:44.05 | starseeker | bt (backtrace) is quite useful |
| 01:44.44 | LainIwakuraX | ah I think I know what may be causing this bug, I can go fix it in source |
| 01:59.29 | LainIwakuraX | It looks like somewhere a std::string is being assigned to NULL when it probably should be "" |
| 01:59.43 | LainIwakuraX | this might take a few minutes to hunt down |
| 02:00.00 | starseeker | yeah, I thought it might be something like this: http://stackoverflow.com/questions/2407711/avoiding-improper-stdstring-initialization-with-null-const-char-using-g |
| 02:00.15 | starseeker | possibly SCLstring tolerated NULL as an initialization input... |
| 02:01.13 | LainIwakuraX | mhm. I found a few spots where I said "new std::string" and I changed those to initialize with "" for sure...but that didn't fix it |
| 02:01.29 | LainIwakuraX | I'll look around |
| 02:01.33 | starseeker | LainIwakuraX: I probably added a few of those myself... |
| 02:01.45 | LainIwakuraX | =x |
| 02:06.12 | CIA-62 | BRL-CAD: 03bhinesley * r45628 10/brlcad/trunk/src/libged/edit.c: |
| 02:06.12 | CIA-62 | BRL-CAD: Tracked down an issue where the last object wasn't being added, and the last |
| 02:06.12 | CIA-62 | BRL-CAD: node in the linked list was empty. Added support for numeric args (as abs coord, |
| 02:06.12 | CIA-62 | BRL-CAD: rel pos, or obj offset). Added/renamed constants for specifying coordinates, so |
| 02:06.12 | CIA-62 | BRL-CAD: that significance goes from left to right: |
| 02:06.13 | CIA-62 | BRL-CAD: '%s/EDIT\([[:upper:]]\)_COORD/EDIT_COORD_\1/g'. Several smaller, |
| 02:06.14 | CIA-62 | BRL-CAD: formatting/comment corrections. |
| 02:20.07 | LainIwakuraX | starseeker: If you find the spot where it's being initialized to null let me know, I haven't found it yet =( |
| 02:21.08 | starseeker | LainIwakuraX: it might even be a function of what it's parsing... my C++ foo is a bit weak, unfortunately |
| 02:21.38 | starseeker | probably very simple once we figure it out |
| 02:22.43 | LainIwakuraX | yeah, I know that when I see it I'll know it lol it's just finding it |
| 02:23.04 | LainIwakuraX | gdb gives me some info.. |
| 02:23.14 | LainIwakuraX | STEPWrapper::load(std::basic_string<char, std::char_traits<char>, std::allocator<char> >&) () |
| 02:23.28 | LainIwakuraX | I can't find STEPWrapper::load anywhere though |
| 02:24.42 | starseeker | wonders if ddd might be helpful... |
| 02:25.51 | bhinesley | spent about a hour wrestling ddd crashes today |
| 02:26.57 | bhinesley | LainIwakuraX: when in doubt: `find . -name "*.cpp" -exec grep "STEPWrapper::load" --with-filename {} \;` |
| 02:28.26 | bhinesley | or use ctags (even better) |
| 02:31.00 | LainIwakuraX | doesn't bring up anything =( |
| 02:31.22 | LainIwakuraX | I usually use: grep -H -r "<thing to search for>" . | grep -v svn | less |
| 02:32.42 | LainIwakuraX | oho...may have found it |
| 02:33.17 | LainIwakuraX | ugh it was in a different directory! I forgot two were involved in my editing process...this should be easier now |
| 02:43.36 | LainIwakuraX | starseeker: I've found the offending code I'm in the process of debugging it |
| 02:45.27 | starseeker | Registry::AddType, clstepcore/Registry.inline.cc:221 ? |
| 02:45.33 | LainIwakuraX | No |
| 02:45.44 | starseeker | nmm |
| 02:45.53 | LainIwakuraX | conv/step/STEPWrapper.cpp |
| 02:45.56 | LainIwakuraX | the load function |
| 02:45.57 | starseeker | ah |
| 03:15.06 | LainIwakuraX | okay the "offending" code was sort of offending, after travelling to 4 different functions I found the real offending code =P working on it.. |
| 03:36.04 | LainIwakuraX | starseeker: I fixed that bug, but now we get a segfault |
| 03:36.13 | LainIwakuraX | Reading Data from ../brlcad/src/other/step/data/ap203/cube1.p21... |
| 03:36.16 | LainIwakuraX | segfault |
| 03:38.20 | brlcad | starseeker, probably a little premature on the cross-post, no? :) |
| 03:39.00 | brlcad | best when collaborating to announce after we've fully vetted/tested ourselves |
| 03:41.04 | brlcad | interesting that I didn't run into a failure on my test |
| 03:41.27 | brlcad | tests that particular p21 file |
| 03:41.31 | LainIwakuraX | yes, it is curious but the bug I found would have indeed failed on something eventually =P |
| 03:41.35 | LainIwakuraX | the line said |
| 03:41.43 | LainIwakuraX | std::string schmn = NULL |
| 03:41.53 | LainIwakuraX | that won't work |
| 03:44.16 | brlcad | nods |
| 03:44.22 | brlcad | hm, BAD cmake rebuild |
| 03:48.55 | LainIwakuraX | Uhh |
| 03:49.05 | LainIwakuraX | I got it to work without a segfault |
| 03:49.20 | LainIwakuraX | it says Reading Data from ../brlcad/src/other/step/data/ap203/cube1.p21... |
| 03:49.33 | LainIwakuraX | Then it says basic_string::_S_construct null not valid |
| 03:49.38 | LainIwakuraX | then the program exits normally... |
| 03:49.45 | LainIwakuraX | (according to gdb) |
| 03:53.34 | bhinesley | brlcad: what gcc do most devs use? |
| 03:53.51 | brlcad | yeah, my test of the patch was quite flawed, two build systems got in the way of each other |
| 03:53.54 | bhinesley | I figured I'd install a lower version so I can use strict |
| 03:54.12 | brlcad | bhinesley: a pretty wide variety, actually |
| 03:54.20 | brlcad | just nobody on gcc 4.6 yet (except you ;) |
| 03:54.26 | bhinesley | heh |
| 03:54.35 | ``Erik | uses 4.2 (fbsd standard) and 4.1 (apple standard) mostly |
| 03:54.36 | brlcad | it's been out for about a month |
| 03:54.54 | brlcad | bhinesley: have you rebuilt lately? |
| 03:55.15 | bhinesley | doing so now, but strict is off |
| 03:55.20 | brlcad | I fixed a slew of the ones abhit reported over the weekend, about a thousand issues |
| 03:55.27 | bhinesley | nice |
| 03:55.28 | brlcad | save a full build log |
| 03:55.46 | brlcad | make 2>&1 | tee build.log |
| 03:56.02 | bhinesley | okay, in just a bit |
| 03:56.29 | bhinesley | I just did a svn update... you guys were busy over the weekend :) |
| 03:56.38 | brlcad | I'm sure I didn't get everything since I don't have the compiler warning if I missed anything, but it should be far better |
| 03:56.51 | bhinesley | nods |
| 03:56.57 | ``Erik | brlcad: I put gcc4.7 on crit if you get the urge to play |
| 03:56.59 | bhinesley | I saw the logs |
| 03:57.09 | brlcad | most oft he things it's warning about are really trivial to fix |
| 03:57.26 | brlcad | vars not being used, print specifier consistency |
| 03:57.37 | brlcad | ``Erik: good to know, thanks |
| 03:57.51 | brlcad | reproduces the step-g failure |
| 03:58.23 | LainIwakuraX | brlcad: I have that fixed to not crash, cleaning up some things and submitting a patch |
| 04:01.44 | brlcad | LainIwakuraX: okay, great .. so I shouldn't go debugging |
| 04:08.36 | LainIwakuraX | brlcad: Patch is submitted...like I said in the notes though even though there isn't a crash I still don't know if it "works" |
| 04:08.54 | LainIwakuraX | If you could test that it'd be great =) I haven't used this program before, I don't know what to expect from it |
| 04:11.32 | brlcad | LainIwakuraX: what was the issue with STEPWrapper::load() ? |
| 04:12.06 | brlcad | changing from a std::string& to a std::string merely makes it make a copy (alloc) |
| 04:12.27 | brlcad | if that fixes a crash, some further investigating is probably warranted |
| 04:12.35 | LainIwakuraX | brlcad: Uh, that shouldn't have been changed- that was a test |
| 04:12.46 | brlcad | starseeker: debugging is not enabled by default? |
| 04:13.30 | brlcad | patch files are text, you should review them before posting .. just like you should review the diff before a commit too |
| 04:13.42 | brlcad | svn revert will restore a file to an unedited state |
| 04:14.09 | brlcad | "svn diff | less" and you can manually inspect what changes are getting included |
| 04:14.41 | LainIwakuraX | brlcad: if you give me two seconds I'll upload a better patch file |
| 04:14.45 | brlcad | k |
| 04:15.20 | brlcad | also make sure you're up-to-date (svn up) so the line offsets are correct |
| 04:17.20 | LainIwakuraX | hm |
| 04:17.36 | LainIwakuraX | I put my &'s on string, not the variable name.. |
| 04:18.05 | LainIwakuraX | it was string &step_file but now it's string& step_file..that's fine though |
| 04:18.20 | brlcad | they are equivalent |
| 04:18.24 | LainIwakuraX | I know |
| 04:18.31 | LainIwakuraX | that's why I said it's fine =P |
| 04:18.36 | brlcad | heh |
| 04:19.22 | brlcad | convention is usually to bind the type together with c++ but separate them for c |
| 04:19.34 | brlcad | so string& is peachy for scl |
| 04:19.39 | LainIwakuraX | ah |
| 04:19.48 | LainIwakuraX | k the better patch is up there |
| 04:20.06 | brlcad | gets |
| 04:21.54 | LainIwakuraX | I'll brb in ~10 mins, let me know how it goes |
| 04:22.25 | brlcad | testing now |
| 04:23.18 | brlcad | so it no longer hard-crashes, but it still exits due to a NULL string |
| 04:24.06 | brlcad | looks like it's maybe on a static |
| 04:25.46 | brlcad | will have to debug more tomorrow.. because *somebody* thought defaulting to no debug symbol compilation was a good idea *ahem* :) |
| 04:26.41 | brlcad | basically, every place a std::string is instantiated, it needs to be initialized to be compatible with what it was assuming |
| 04:32.02 | CIA-62 | BRL-CAD: 03brlcad * r45629 10/brlcad/trunk/src/other/step/src/ (5 files in 2 dirs): |
| 04:32.02 | CIA-62 | BRL-CAD: apply sf patch 3377904 (fixed a bug with step-g and null strings) from Zach |
| 04:32.02 | CIA-62 | BRL-CAD: Easterbrook ( lainiwakurax ) which indeed fixes the step-g crash, but still |
| 04:32.02 | CIA-62 | BRL-CAD: doesn't restore it to a functional status. aborts with a message about a NULL |
| 04:32.02 | CIA-62 | BRL-CAD: std::string. |
| 04:32.23 | LainIwakuraX | I'm back |
| 04:32.59 | LainIwakuraX | brlcad: How can we test this if it's failing without...uh, any issues? |
| 04:33.09 | LainIwakuraX | I can't do a backtrace in gdb |
| 04:33.51 | brlcad | for one, step-g produces a ton of output when it's working correctly ;) |
| 04:34.31 | brlcad | you can put a breakpoint on main (b main) and step forward ('n' command for "next instruction") |
| 04:34.51 | brlcad | or "b whatever" to break on any arbitrary function |
| 04:35.08 | brlcad | it'll take me a while to get a rebuild with debugging enabled myself |
| 04:36.43 | LainIwakuraX | brlcad: Is it cool if we tackle this tomorrow then? It's 12:30a.m here and I have a few more things to do before bed =x |
| 04:37.55 | brlcad | we're apparently on the same coast, sounds good to me |
| 04:38.50 | LainIwakuraX | k, see you then. I'm usually awake in the afternoon lol |
| 04:42.03 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 04:55.02 | bhinesley | brlcad: build.log http://paste.pocoo.org/show/446487/ |
| 04:56.03 | bhinesley | er, you probably wanted me to use 'make -k' |
| 05:00.42 | bhinesley | 'make -k' build log: http://paste.pocoo.org/show/446495/ |
| 05:34.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:26.18 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 07:10.26 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 08:47.51 | CIA-62 | BRL-CAD: 03Abby Moss 07http://brlcad.org * r3037 10/wiki/Main_Page: |
| 08:47.59 | CIA-62 | BRL-CAD: 03d_rossberg * r45630 10/brlcad/trunk/src/libbu/CMakeLists.txt: Windows MSVC: because of GetMappedFileName() in fchmod.c link with psapi.lib |
| 08:50.13 | *** join/#brlcad Stattrav (~Stattrav@122.167.229.132) | |
| 08:50.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:33.19 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 11:42.12 | starseeker | brlcad: yeah, premature. Was going on your initial report that it worked |
| 11:47.55 | starseeker | starseeker: I'll hold off until we have it working next time |
| 11:47.59 | starseeker | er brlcad rather |
| 11:48.05 | starseeker | is talking to himself |
| 11:58.57 | brlcad | mm, you sent the message before I'd even started testing :) |
| 12:01.07 | brlcad | 2pm, didn't test and commit till 5pm .. but even if if it was golden, I'd suggest we send them revision numbers at stepping points |
| 12:01.17 | brlcad | bhinesley: thanks |
| 12:20.58 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3038 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/Abby Moss|Abby Moss]] ([[User talk:Abby Moss|Talk]]); changed back to last version by [[User:Sean|Sean]] |
| 12:21.20 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Abby Moss]] with an expiry time of infinite (account creation disabled, e-mail blocked) |
| 12:27.48 | CIA-62 | BRL-CAD: 03brlcad * r45631 10/brlcad/trunk/src/ (CMakeLists.txt libbu/CMakeLists.txt): set PSAPI_LIB variable so we can consolidate into the same since MSVC block |
| 12:30.28 | d_rossberg | brlcad: setting of the MSVC libraries isn't very consistent in the cmake files, see e.g. librt |
| 12:34.54 | brlcad | nods |
| 12:35.57 | CIA-62 | BRL-CAD: 03brlcad * r45632 10/brlcad/trunk/src/other/step/src/ (62 files in 7 dirs): |
| 12:35.57 | CIA-62 | BRL-CAD: eliminate all of the __OSTORE__ sections. considered dead code because there |
| 12:35.57 | CIA-62 | BRL-CAD: was no managed way to enable those code sections. appears to be a binding to a |
| 12:35.57 | CIA-62 | BRL-CAD: commercial API (Progress Software Corp's ObjectStore product), so remove in |
| 12:35.57 | CIA-62 | BRL-CAD: favor of simplified code maintenance and reduced complexity. removes almost 3k |
| 12:35.58 | CIA-62 | BRL-CAD: lines of code. |
| 12:36.08 | brlcad | d_rossberg: I know, the evils of letting a "platform" identifier in for a few things makes it really easy to abuse/reuse in more places than it should |
| 12:36.51 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 12:41.00 | CIA-62 | BRL-CAD: 03brlcad * r45633 10/brlcad/trunk/src/ (CMakeLists.txt librt/CMakeLists.txt): similar to libbu, consolidate the msvc library settings into the same place where winsock gets set, consistently just use library names in ADDLIB |
| 12:49.09 | brlcad | I'm sure the intention was to go back one day, some day, and fix them proper when they were first written... ;) |
| 12:53.18 | CIA-62 | BRL-CAD: 03brlcad * r45634 10/brlcad/trunk/CMakeLists.txt: typo? |
| 12:54.10 | d_rossberg | OK |
| 13:00.31 | CIA-62 | BRL-CAD: 03brlcad * r45635 10/brlcad/trunk/CMakeLists.txt: |
| 13:00.31 | CIA-62 | BRL-CAD: consistently default all builds (particularly fresh svn checkouts) to a system |
| 13:00.32 | CIA-62 | BRL-CAD: install into /usr/brlcad using rel- for releases and dev- for developer builds. |
| 13:00.32 | CIA-62 | BRL-CAD: could probably even just key off of the patch number but leave as-is for now. |
| 13:00.32 | CIA-62 | BRL-CAD: this will probably require windows to set the install prefix given there usually |
| 13:00.32 | CIA-62 | BRL-CAD: is no /usr path but that is needed for windows anyways for release builds. |
| 13:01.29 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 13:01.46 | CIA-62 | BRL-CAD: 03brlcad * r45636 10/brlcad/trunk/TODO: remove all of the MSVC platform sections in the CMakeLists.txt files |
| 13:01.49 | brlcad | abhi2011: application received! |
| 13:08.44 | CIA-62 | BRL-CAD: 03brlcad * r45637 10/brlcad/trunk/TODO: demote a lot of tasks that won't likely be completed by next month. leave most of the build-related tasks since we're moving towards eventual autotools removal. |
| 13:09.37 | CIA-62 | BRL-CAD: 03brlcad * r45638 10/brlcad/trunk/TODO: cp command now redraws once again, along with a slew of other ged commands. if one of the argv parameters is displayed, it gets redrawn. |
| 13:14.57 | CIA-62 | BRL-CAD: 03brlcad * r45639 10/brlcad/trunk/BUGS: rt displays output once again, button bindings should be fixed, and rt after cd in mged on windows should work once again |
| 13:34.45 | CIA-62 | BRL-CAD: 03brlcad * r45640 10/brlcad/trunk/src/conv/step/step-g.cpp: ws style |
| 13:39.02 | CIA-62 | BRL-CAD: 03brlcad * r45641 10/brlcad/trunk/src/conv/step/ (6 files): |
| 13:39.02 | CIA-62 | BRL-CAD: got step-g to crash with a couple input test files, one crashing on Surface.h:48 |
| 13:39.02 | CIA-62 | BRL-CAD: implying some stack corruption or memory issue. so add protections all the way |
| 13:39.02 | CIA-62 | BRL-CAD: up the stack to make sure we didn't run out of memory or dereference a null |
| 13:39.02 | CIA-62 | BRL-CAD: pointer at some point. probably doesn't get to the heart of the crash, but |
| 13:39.02 | CIA-62 | BRL-CAD: should help isolate it and help halt sooner (and hopefully more gracefully than |
| 13:39.03 | CIA-62 | BRL-CAD: a crash). |
| 13:40.34 | CIA-62 | BRL-CAD: 03brlcad * r45642 10/brlcad/trunk/src/other/libpng/depcomp: depcomp is generated, remove from checkin |
| 13:42.35 | CIA-62 | BRL-CAD: 03brlcad * r45643 10/brlcad/trunk/src/other/libpng/config.h.in: autoheader made config.h.in, also remove |
| 13:42.44 | abhi2011 | thanks brlcad :) |
| 13:50.51 | CIA-62 | BRL-CAD: 03brlcad * r45644 10/brlcad/trunk/TODO: libpng needs backported fixes for autotools |
| 14:30.38 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:35.28 | starseeker | brlcad: ah, right - I thought they might want to play with the patch at that point. Was hoping they might do some of the work for us :-P |
| 14:36.48 | starseeker | brlcad: you really want to go into /usr/brlcad for dev builds by default? |
| 14:36.57 | starseeker | was very intentionally staying out of system dirs |
| 14:47.00 | CIA-62 | BRL-CAD: 03starseeker * r45645 10/brlcad/trunk/CMakeLists.txt: Wasn't a typo - to do what that previous edit looked like it wanted to do, ELSEIF (I think) is what is needed. Instead of that, just turn on DEBUG_BUILD for everything except Release |
| 14:47.26 | starseeker | isn't even sure how to test for Microsoft system libraries... |
| 14:49.16 | CIA-62 | BRL-CAD: 03starseeker * r45646 10/brlcad/trunk/misc/enigma/enigma.c: clang didn't like argc not having a type |
| 14:52.13 | starseeker | isn't sure he agrees with making the MSVC specific stuff into tests - that'll just lengthen the configure process even further, and the probability is very high that those options will be useless everywhere else (or even worse, might mean something altogether different, given how foreign MSVC is to other environments) |
| 14:58.22 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 15:04.02 | CIA-62 | BRL-CAD: 03starseeker * r45647 10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Add the new, improved libpng CMakeLists.txt macros from our 1.4.x build - this is what should go back to libpng as a proposed patch. |
| 15:21.22 | CIA-62 | BRL-CAD: 03starseeker * r45648 10/brlcad/trunk/src/other/ (3 files in 2 dirs): OK, I think we've gotten rid of 'em now - try again to remove scl_string |
| 15:33.24 | brlcad | starseeker: having a default checkout that doesn't perform a system install breaks convention in itself, /usr/local is usually the default which is where our /usr/brlcad becomes preferred so we're protected |
| 15:35.50 | brlcad | there's also a portability issue for some platforms (like aix, hpux, some linux, and few others) where binaries are not relocatable by default, so if you installed into your home directory, you can't just copy that (e.g., into /usr/brlcad) and have it work, have to set library paths and our brlcad root/data paths in the environment |
| 15:36.57 | starseeker | right, but I had figured when doing a debug (e.g. development) build installing in /usr/brlcad was less likely to be important (I personally never install there while doing development) |
| 15:36.59 | brlcad | plus it matches our project history, we consistently install into /usr/brlcad by default -- others can set a prefix |
| 15:37.40 | brlcad | to a user checking out from svn, there is a surprise that I just did a checkout, compile, install ... and it's not installed |
| 15:37.57 | brlcad | at least not where I'd expect it, not in a system location |
| 15:38.26 | starseeker | well... I suppose I could go back to defaulting to /usr/brlcad if CMAKE_BUILD_TYPE is not set... |
| 15:38.38 | brlcad | and you should be installing into /usr/brlcad ... else we end up with mysterious path problems when mged is attempting to load :) |
| 15:39.11 | starseeker | <snort> I would have thought installing somewhere other than /usr/brlcad would be MORE likely to highlight path problems, not less |
| 15:39.31 | brlcad | release going to /usr/brlcad/rel-VERSION and non-release going to /usr/brlcad/dev-VERSION is actually a nice consistency |
| 15:40.10 | brlcad | it did highlight problems.. the /usr/brlcad one didn't work :) |
| 15:40.16 | starseeker | nods - I can live with it, I just liked the idea of doing a checkout/build/install for development purposes without having to worry about system permissions |
| 15:41.39 | brlcad | end-user convenience should always take priority over developer convenience |
| 15:41.48 | brlcad | i'm a stout believer in that stance |
| 15:42.03 | starseeker | end users use RPMs or package managers :-P |
| 15:42.05 | brlcad | users get the shaft WAY too often in open source |
| 15:42.14 | brlcad | end users include anyone that's not a developer |
| 15:43.57 | brlcad | which includes users that checkout from the repository, or that would pick up a nightly source tarball... |
| 15:44.47 | brlcad | still, it's more just about not *intentionally* making things more difficult or compilicated when it's just a matter of convention or a few keystrokes more or a few more lines in build files to help make it easier |
| 15:48.34 | starseeker | shrugs. OK, I can live with dev-VERSION. |
| 15:49.29 | brlcad | so next topic? :) |
| 15:49.41 | brlcad | I'd expect microsoft system libs are tested for like any other library, no? |
| 15:49.49 | starseeker | hmm... idea. If I look for a BRL-CAD_build_settings.cmake file early in the CMakeLists.txt and load it if found, that would provide a way for a developer to customize things without disturbing end-users - would that be OK? |
| 15:50.35 | starseeker | brlcad: I suppose there might be a way to test for Microsoft librarys - I have no idea if the standard CMake mechanisms will do it though. |
| 15:51.12 | starseeker | Maybe we can wrap that set of tests in in MSVC conditional in the toplevel so we don't waste time with them on Mac/Linux at least? |
| 15:51.28 | brlcad | the issue is really what happens to a default user -- if someone actively sets up their config, that's akin to setting -Dvar=val or --prefix options and it's peachy keen |
| 15:51.54 | starseeker | awesome - I mainly want a way to minimize the number of config options/flags I have to pass over and over |
| 15:52.01 | brlcad | nods |
| 15:52.06 | brlcad | perfectly reasonable |
| 15:52.18 | brlcad | when was the last time you built the linux kernel (by hand)? |
| 15:52.24 | starseeker | the configure wrapper helps some there, but not really enough |
| 15:52.46 | brlcad | they had a pretty neat setup |
| 15:52.46 | starseeker | brlcad: define by hand - using their grapical config tool, or item-by-item? |
| 15:52.55 | brlcad | either really |
| 15:53.00 | brlcad | so you config the kernel, right? |
| 15:53.07 | brlcad | it ends up with a config file with all your settings |
| 15:53.16 | starseeker | yeah - usually whenever I get a new machine, so the gentoo kernel has the right modules |
| 15:53.20 | starseeker | right |
| 15:53.23 | brlcad | so even after config is done, you can go in, edit it, and run with those new settings |
| 15:53.37 | brlcad | something like that would be awesome |
| 15:53.58 | starseeker | nods - CMakeCache.txt does some of that, but not "up front" before a configure is run |
| 15:54.13 | brlcad | "cmake path" resulting in a .GLOBAL would be fun :) |
| 15:54.43 | starseeker | brlcad: in case I haven't mentioned it - you can hand edit the CMakeCache.txt file in the toplevel build to change options |
| 15:54.44 | brlcad | I think linux uses .CONFIG? |
| 15:55.20 | brlcad | it's configurable iirc, but defaults to something like that |
| 15:55.23 | starseeker | for post configure settings caching, CMakeCache.txt should have everything you could want |
| 15:56.03 | brlcad | so common use case that comes to mind .. we have all these tests for opengl |
| 15:56.12 | brlcad | user runs cmake, it fails the test |
| 15:56.16 | brlcad | but they know they have it |
| 15:56.58 | brlcad | sure enough, "make" just skips our ogl code; so they go in and edit the build config file, turn ogl on, re-run make .. and it builds |
| 15:57.04 | brlcad | something like that doable? |
| 15:57.21 | starseeker | yeah - that's what I usually do if I forget to turn something on |
| 15:57.44 | brlcad | so maybe just a better name than CMakeCache.txt :) |
| 15:58.01 | brlcad | or is that literally every function/header/feature test? |
| 15:58.37 | starseeker | brlcad: heh - hardwired, I think. But my point wasn't that I want that ability AFTER running cmake - I want to always pass (say) BRLCAD-ENABLE_ALL_LOCAL_LIBS=ON without having to type it every time, and without having to edit the cache file |
| 15:59.01 | brlcad | blocking the MSVC-only tests would be fine -- that's what I was thinking -- it's more that they should still be tested for like any other feature since they're just as ephemeral as any of the other libs |
| 15:59.25 | brlcad | winsock2, for example, is one of several incarnations of the windows networking interface |
| 16:00.41 | brlcad | starseeker: right, I got that -- but I figured that should just be a matter of (re-)loading it during cmake for defaults as well as during make to drive compilation |
| 16:01.08 | brlcad | so if CMakeCache.txt is hardwired, maybe we could output just the high-level options we care about to a different config file |
| 16:01.15 | starseeker | nods |
| 16:01.16 | brlcad | basically, the summary items |
| 16:01.21 | starseeker | let me experiment a bit |
| 16:01.59 | brlcad | likes the .GLOBAL/_GLOBAL inside "joke" |
| 16:02.02 | starseeker | this is over and above anything autotools ever provided (unless you count storing a configure line in a .sh file) so it's probably not a high priority - I'm just lazy about typing options :-P |
| 16:02.18 | brlcad | it is above it |
| 16:02.27 | brlcad | something I thought about adding a few times, though |
| 16:02.29 | starseeker | winces a little - maybe BRL-CAD_CONFIG.GLOBAL |
| 16:03.15 | brlcad | users already know they're in a brl-cad checkout, no need to remind them in all the file names :) |
| 16:03.38 | brlcad | even just CONFIG would probably be fine |
| 16:03.59 | starseeker | hadn't envisioned putting it in the checkout or even the build dir - this would be something that could be stored (optionally) in the parent directory |
| 16:04.28 | brlcad | I didn't mean put it in checkout |
| 16:04.40 | brlcad | file generated by cmake, reused by cmake and make |
| 16:05.00 | starseeker | shakes his head - I want to be able to use this to set options before I ever run CMake at all |
| 16:05.36 | brlcad | nothing I've said precludes that ??? |
| 16:06.00 | starseeker | cmake can't generate a file in the parent directory - oh, wait |
| 16:06.08 | starseeker | hmm. |
| 16:06.30 | brlcad | I presume by parent you mean user's home dir or something? |
| 16:06.35 | starseeker | basically |
| 16:06.49 | starseeker | one config file to rule them all :-P |
| 16:07.14 | starseeker | I guess we can check for and read that in, then generate something in the build directory for subsequent use in that run |
| 16:07.23 | brlcad | hm, that's a little odd |
| 16:07.45 | starseeker | brlcad: might be odd, but it would be completely harmless unless someone specifically sought it out and set it up |
| 16:08.08 | brlcad | sure, but it can be turned into a proper feature and achieve the same result |
| 16:08.48 | starseeker | uh... I guess I'm not following |
| 16:09.13 | brlcad | still thinking to the linux kernel as a model to follow |
| 16:09.44 | brlcad | I can craft up my own CONFIG file and specify it to the build (from wherever really) |
| 16:10.01 | brlcad | or I can run the interactive build (cmake .) and it'll dump out a CONFIG file for me |
| 16:10.15 | brlcad | which I can subsequently reuse if I wanted (from anywhere) |
| 16:10.21 | brlcad | edit to heart's content |
| 16:10.32 | brlcad | or ignore and the build just uses it for settings |
| 16:11.12 | brlcad | familiar, time tested, pretty simple |
| 16:16.42 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:26.45 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:34.55 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.146.20) | |
| 17:09.59 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 17:34.55 | CIA-62 | BRL-CAD: 03starseeker * r45649 10/brlcad/trunk/CMakeLists.txt: |
| 17:34.55 | CIA-62 | BRL-CAD: Add a dirt-simple way to allow developers to inject their own default settings |
| 17:34.55 | CIA-62 | BRL-CAD: into the CMake process - eventually we may want to do something more |
| 17:34.55 | CIA-62 | BRL-CAD: sophisticated, but this is a simple way to do things like enable all local |
| 17:34.55 | CIA-62 | BRL-CAD: libraries by default. |
| 18:34.40 | brlcad | starseeker: what does it mean to be a release build? |
| 18:35.03 | brlcad | is that merely synonymous with non-debug? .. or what if I wanted a debuggable release build? |
| 19:30.47 | brlcad | starseeker: so unexpected behavior .. cd brlcad ; mkdir .cmake ; cd .cmake ; cmake .. ; echo "why aren't there any build files output here?" |
| 19:56.43 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 20:08.40 | *** join/#brlcad tharis20_ (~tharis@2.83.244.20) | |
| 21:10.19 | starseeker | starseeker: right now it's mostly /usr/brlcad/rel* paths and turning on optimization by default |
| 21:11.20 | starseeker | formally acknowledges not outputing build files in expected directory if there is a CMakeCache.txt file in the source dir is Not Good |
| 21:11.33 | starseeker | brlcad: right now it's mostly /usr/brlcad/rel* paths and turning on optimization by default |
| 21:11.38 | starseeker | is talking to himself again |
| 23:29.45 | *** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net) | |
| 23:32.42 | LainIwakuraX | brlcad: I see a lot of updates to step stuff in the latest rev. sorry I wasn't here in the afternoon to help =( |
| 23:46.28 | tharis20 | brlcad: in the expectations it is said that it is expected students to work 40 hours a week, the same as a full-time job |
| 23:46.50 | tharis20 | but SOCIS extends until the end of October and classes begin in mid-September |
| 00:04.25 | LainIwakuraX | starseeker, brlcad, whenever you guys see this- I checked the SOCIS project timeline and about 2 months of it overlaps with University, I can't comfortably commit to school, the project, and my part-time work. I'm staying here as a regular contributor though =) |
| 00:20.34 | ``Erik | looks like most of europe starts school in early-mid september, I wonder if they're aware of that O.o unfortunate that there's such a huge overlap |
| 00:21.37 | LainIwakuraX | Yeah Canada too, I wish I could apply but it's not feasible or fair =( |
| 00:21.51 | LainIwakuraX | (to the project + me) |
| 00:22.27 | ``Erik | brlcad: since you're the point of contact with them, are you going to contact them to see what's up? http://en.wikipedia.org/wiki/Summer_vacation lists the 'common' dates for most countries |
| 00:22.58 | ``Erik | assumed that EU nations had a longer or later break, but it doesn't seem so |
| 00:23.45 | ``Erik | and a 40hr job plus school can be pretty brutal, did it to pay my tuition 'n books O.o |
| 00:25.37 | LainIwakuraX | heh, I'd like to be superman =P but 40hr SOCIS, 5 Full time courses in school, and a part-time job |
| 00:25.39 | ``Erik | heh, of course esa is part of the cern blocks, so only students from cern nations can participate :/ |
| 00:25.42 | LainIwakuraX | Too crazy lol |
| 00:26.56 | tharis20 | exactly, with school, available time reduces significantly |
| 00:28.04 | tharis20 | and although, in the beginning, there's not much work to do, in Portugal (where I live) there's a tradition for sophomores to participate in activities with freshmen, a thing called "Praxe" |
| 00:28.28 | tharis20 | http://en.wikipedia.org/wiki/Praxe |
| 00:29.22 | LainIwakuraX | In Canada we get homework =( |
| 00:30.30 | tharis20 | LOL In Portugal it depends on the Univ. there are some that send mandatory homework. Mine sends homework for those who want to do homework. :x |
| 00:30.55 | ``Erik | I have to scoot, awesome if you're willing to continue contributing regardless... hopefully something will get sorted out :) later |
| 00:31.32 | LainIwakuraX | Yeah this project has piqued my interest =P definitely sticking around |
| 00:31.51 | tharis20 | I'd like to know if even with school one is expected to work as a full-time job |
| 00:32.21 | tharis20 | but regardless of SOCIS, I think I will contribute to this project |
| 00:32.52 | tharis20 | been looking for an open-source project to work that he really likes |
| 00:33.07 | LainIwakuraX | ^ |
| 00:37.22 | tharis20 | oh man, I don't know how I'm going to wake up early tomorrow... |
| 03:36.56 | brlcad | LainIwakuraX: it's alright, happens ... and more importantly great to hear you're still interested in dev ;) |
| 03:37.39 | brlcad | ``Erik: yeah, they wanted to start earlier (part of why the schedule is so tight already) .. but didn't get management approval till late |
| 03:38.45 | brlcad | from the mailing list discussions, their familiarity and decision processes sound almost exactly like how I imagined arl dealing with running a gsoc-style program |
| 03:56.08 | LainIwakuraX | brlcad: I did an svn update and a lot of STEP stuff changed but I still get the same error that silently crashes step-g |
| 03:56.24 | brlcad | LainIwakuraX: yeah, the crash hasn't been fixed yet |
| 03:57.44 | LainIwakuraX | kk, I won't be able to get to it tonight but tomorrow / thursday I can probably spend a good while on it |
| 03:57.53 | LainIwakuraX | I don't really know what's still causing it though =/ |
| 04:17.27 | CIA-62 | BRL-CAD: 03brlcad * r45650 10/brlcad/trunk/src/other/step/src/ (8 files in 2 dirs): std::string are declared in <string>, not <string.h>; fix r45627. |
| 04:24.24 | LainIwakuraX | I'm out for the night |
| 05:32.40 | starseeker | brlcad: er, oops - sorry about that |
| 07:07.15 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 08:27.09 | *** join/#brlcad CalinPaulAlexand (524f464d@gateway/web/freenode/ip.82.79.70.77) | |
| 08:29.01 | *** join/#brlcad Stattrav (~Stattrav@122.178.209.201) | |
| 08:29.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:00.40 | *** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 09:55.09 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 10:25.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:42.23 | CIA-62 | BRL-CAD: 03indianlarry * r45651 10/brlcad/trunk/src/other/step/src/clstepcore/ (ExpDict.h ExpDict.inline.cc sdaiApplication_instance.cc): Changed parameter 'schnm' back to 'const char *' for functions SchRename::rename() and TypeDescriptor::Name(). |
| 14:38.30 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 15:30.37 | brlcad | starseeker: revisiting yesterday's discussion .. turns out the cache behavior is actually not a bug, just bad design |
| 15:31.02 | brlcad | the path parameter specifies EITHER a source dir or a build dir |
| 15:32.02 | brlcad | that actually seems a bit asinine to me since all it avoids is a 'cd' but introduces the unexpected behavior since they flip the meaning of the path argument |
| 16:17.34 | brlcad | looks like r45651 fixed step-g for me |
| 17:22.28 | brlcad | aha fixed! |
| 17:22.37 | brlcad | (a different subtle bug) |
| 17:30.55 | CIA-62 | BRL-CAD: 03brlcad * r45652 10/brlcad/trunk/src/other/step/src/clstepcore/read_func.cc: ws consistency |
| 17:37.30 | CIA-62 | BRL-CAD: 03brlcad * r45653 10/brlcad/trunk/src/other/step/src/clstepcore/ (README sdaiString.cc): update the README to reflect the current directory contents. was referring to files and classes that were renamed/refactored and/or no longer exist. |
| 17:41.02 | CIA-62 | BRL-CAD: 03brlcad * r45654 10/brlcad/trunk/src/other/step/src/clstepcore/ (README sdaiString.cc): revert r45653, unintentional inclusion of a bug fix that begs documenting |
| 17:42.06 | CIA-62 | BRL-CAD: 03brlcad * r45655 10/brlcad/trunk/src/other/step/src/clstepcore/README: update the README to reflect the current directory contents. was referring to files and classes that were renamed/refactored and/or no longer exist. |
| 17:50.40 | CIA-62 | BRL-CAD: 03brlcad * r45656 10/brlcad/trunk/src/other/step/src/clstepcore/sdaiString.cc: (log message trimmed) |
| 17:50.40 | CIA-62 | BRL-CAD: fix a bug introduced with the conversion of SCL's string management to using |
| 17:50.40 | CIA-62 | BRL-CAD: STL's std::string. null values were getting injected into the parsing output |
| 17:50.40 | CIA-62 | BRL-CAD: since std::string will happily record a zero-character and keep track of how |
| 17:50.40 | CIA-62 | BRL-CAD: long the c-string buffer is independent of null-termination. the streams |
| 17:50.40 | CIA-62 | BRL-CAD: happily print the entire buffer (i.e., not relying on null termination) causing |
| 17:50.41 | CIA-62 | BRL-CAD: literal '\0' values to get output. fix was simple, don't append '\0' values. |
| 17:50.46 | brlcad | that took a while to find/fix! |
| 17:57.44 | starseeker | brlcad: nicely done! |
| 18:15.16 | brlcad | now to profile |
| 18:17.16 | brlcad | initial test showed a speedup |
| 20:14.00 | CIA-62 | BRL-CAD: 03brlcad * r45657 10/brlcad/trunk/src/conv/step/step-g.cpp: make sure we can read the input step file before stubbing in an empty .g file that gets in the way on follow-up invocations. stub in support for stdin piped input too. |
| 20:14.41 | CIA-62 | BRL-CAD: 03brlcad * r45658 10/brlcad/trunk/src/conv/step/STEPWrapper.h: use std:: prefix on stl types |
| 20:15.00 | CIA-62 | BRL-CAD: 03brlcad * r45659 10/brlcad/trunk/src/conv/step/STEPWrapper.cpp: ws indent consistency cleanup |
| 20:27.35 | *** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net) | |
| 20:35.05 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:35.24 | CIA-62 | BRL-CAD: 03erikgreenwald * r45660 10/brlcad/trunk/src/libgcv/bottess.c: do vertex/plane throwaway on triangle intersection test |
| 20:37.47 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.134.140) | |
| 20:46.08 | *** join/#brlcad Stattrav (~Stattrav@117.192.140.17) | |
| 20:46.08 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:48.49 | CIA-62 | BRL-CAD: 03brlcad * r45661 10/brlcad/trunk/src/conv/step/step-g.cpp: print status when writing the output file |
| 21:08.24 | CIA-62 | BRL-CAD: 03brlcad * r45662 10/brlcad/trunk/src/conv/step/STEPWrapper.cpp: trim a little so the summary will usually fit within 80 columns, let user know if input came from stdin |
| 21:11.56 | CIA-62 | BRL-CAD: 03brlcad * r45663 10/brlcad/trunk/src/other/step/src/cleditor/ (STEPfile.cc STEPfile.inline.cc): add support for reading exchange/express/step input from standard input. if the filename provided is a '-', it will be treated special to imply standard input. |
| 21:25.22 | LainIwakuraX | brlcad: It looks like that step-g crash has been fixed! awesome =) |
| 21:27.34 | brlcad | LainIwakuraX: yeah, mostly due to indianlarry -- looks like you were passing std::string as a char* in a few places |
| 21:28.38 | brlcad | on a positive note, I'm seeing a rough 20% performance increase on (smallish) step models |
| 21:28.56 | brlcad | unfortunately, diminishes towards 0% increase as the models get bigger and more realistic |
| 21:29.07 | brlcad | dominated by other processing time |
| 21:33.05 | LainIwakuraX | ahh I thought I had those spots worked out |
| 21:33.27 | LainIwakuraX | it was tricky because SCLstring appears to behave similar to regular C strings =/ |
| 21:33.49 | LainIwakuraX | Well at least it's all good now |
| 21:53.49 | CIA-62 | BRL-CAD: 03erikgreenwald * r45664 10/brlcad/trunk/src/libgcv/bottess.c: Fast test for coplanar triangles. Find direction vector of intersecting line and projection direction. Make noise-code compile time switchable. |
| 22:10.23 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 22:12.06 | brlcad | LainIwakuraX: it's *hopefully* all good for now -- our importer only exercises a small portion of scl :/ |
| 22:12.36 | brlcad | the other bug was in Sdai_String where you inherited from std::string |
| 22:12.53 | brlcad | it was manually appending '\0' values, which caused a bit of a mess in the output |
| 22:13.20 | brlcad | because std::string will happily append and print null values, where c-strings halt on null-termination |
| 23:55.23 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 23:55.23 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 23:57.52 | CIA-62 | BRL-CAD: 03bhinesley * r45667 10/brlcad/trunk/src/libged/edit.c: |
| 23:57.53 | CIA-62 | BRL-CAD: Laid out additional subcommand functions, and added pointers to them into the |
| 23:57.53 | CIA-62 | BRL-CAD: array of edit_cmd structs. This will help keep subcommands separate from the |
| 23:57.53 | CIA-62 | BRL-CAD: edit routines, so adding/modifying commands will be more isolated/simpler than I |
| 23:57.53 | CIA-62 | BRL-CAD: had originally planned. Started on edit(). None of this is not tested very well |
| 23:57.53 | CIA-62 | BRL-CAD: yet. WIP |
| 23:58.58 | bhinesley | hm, r45678 coming up |
| 23:59.01 | bhinesley | puts on party hat |
| 23:59.16 | brlcad | hehe |
| 23:59.26 | brlcad | goes to get sparklers |
| 00:00.00 | LainIwakuraX | lol |
| 00:11.21 | CIA-62 | BRL-CAD: 03brlcad * r45668 10/brlcad/trunk/src/conv/step/step-g.cpp: always tear down the factory |
| 00:13.42 | CIA-62 | BRL-CAD: 03brlcad * r45669 10/brlcad/trunk/src/conv/step/STEPWrapper.cpp: dotg != dot_g |
| 00:49.48 | *** join/#brlcad tharis20 (~tharis@dyn896-219.eduroam.ic.ac.uk) | |
| 00:50.57 | LainIwakuraX | Out for the night |
| 00:57.55 | *** join/#brlcad tharis20 (~tharis@dyn896-219.eduroam.ic.ac.uk) | |
| 01:54.26 | CIA-62 | BRL-CAD: 03kunigami * r45670 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h sh_osl.cpp): added support for vector/normal/point and matrix shader parameters |
| 03:07.52 | CIA-62 | BRL-CAD: 03brlcad * r45671 10/brlcad/trunk/src/conv/step/STEPWrapper.cpp: sanity, abort if we encounter a null |
| 03:08.07 | CIA-62 | BRL-CAD: 03brlcad * r45672 10/brlcad/trunk/src/conv/step/ (5 files): ws |
| 04:22.17 | CIA-62 | BRL-CAD: 03brlcad * r45673 10/brlcad/trunk/configure.ac: PNG libtool library is now libpng15.la |
| 04:27.20 | CIA-62 | BRL-CAD: 03brlcad * r45674 10/brlcad/trunk/src/libbn/plane.c: parallel is set but unused, kill it |
| 04:34.05 | CIA-62 | BRL-CAD: 03brlcad * r45675 10/brlcad/trunk/src/libbn/plot3.c: more variable set-but-unused warnings from gcc 4.7 (prerelease), but these are actually needed. check the ret value and perror if we didn't write all that was expected. |
| 04:38.20 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 04:40.45 | CIA-62 | BRL-CAD: 03brlcad * r45676 10/brlcad/trunk/src/librt/bundle.c: status is unused, remove |
| 04:52.42 | CIA-62 | BRL-CAD: 03brlcad * r45677 10/brlcad/trunk/src/conv/step/ (STEPWrapper.cpp STEPWrapper.h): convert InstMgr from an embedded class to a pointer with allocation on the heap |
| 05:15.31 | CIA-62 | BRL-CAD: 03brlcad * r45678 10/brlcad/trunk/src/librt/prep.c: yet another example why strict compilation is a "good thing" (tm). quell warning about old_max being set but unused. turns out this was a bug introduced several years ago in r36723 after a simple refactoring. |
| 05:17.46 | CIA-62 | BRL-CAD: 03brlcad * r45679 10/brlcad/trunk/src/other/step/src/cleditor/instmgr.cc: plug a memory leak accounting for almost a half MB. delete the InstMgr master and sorted master manager node arrays. |
| 05:34.37 | CIA-62 | BRL-CAD: 03brlcad * r45680 10/brlcad/trunk/src/librt/primitives/ (bot/btgf.c dsp/dsp.c): remove unused var |
| 05:36.15 | CIA-62 | BRL-CAD: 03brlcad * r45681 10/brlcad/trunk/src/librt/primitives/bspline/bspline.cpp: and again, strictness catches a bug -- this one affects being able to dbupgrade/dbopen incompatible v4 files. it basically was reading in old bpline objects without applying a properly byte-flipped matrix. |
| 05:38.13 | CIA-62 | BRL-CAD: 03brlcad * r45682 10/brlcad/trunk/src/other/step/src/cleditor/STEPfile.inline.cc: delete the instances before deleting the container, don't just clear them. plugs memory leak (though there is still lots to go for scl) |
| 05:41.30 | CIA-62 | BRL-CAD: 03brlcad * r45683 10/brlcad/trunk/src/other/step/TODO: leaking something nasty |
| 06:50.59 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:00.34 | CIA-62 | BRL-CAD: 03brlcad * r45684 10/brlcad/trunk/src/librt/ (13 files in 9 dirs): quell a slew of gcc 4.7 detections of variables being set but weren't being used. one of the nmg routines, nmg_eval_linear_trim_to_tol(), is a little suspect but the rest were mostly benign. |
| 09:59.59 | CIA-62 | BRL-CAD: 03bhinesley * r45685 10/brlcad/trunk/src/libged/edit.c: (log message trimmed) |
| 09:59.59 | CIA-62 | BRL-CAD: Renamed stupid "*_concise" functions to "*_wrapper". Added functions to get the |
| 09:59.59 | CIA-62 | BRL-CAD: next argument "head" in the union edit_cmd. Not too happy about adding yet |
| 09:59.59 | CIA-62 | BRL-CAD: another command-specific function; but it seems necessary to keep separation, |
| 09:59.59 | CIA-62 | BRL-CAD: while still having an intuitive way to build arguments (id est union edit_cmd). |
| 10:00.00 | CIA-62 | BRL-CAD: With these functions, we'll be able to pass over all of a command's arguments, |
| 10:00.01 | CIA-62 | BRL-CAD: without being aware of the union edit_cmd layout. The new plan is to keep edit() |
| 11:00.10 | *** join/#brlcad Stattrav (~Stattrav@122.178.209.201) | |
| 11:00.10 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:04.06 | *** join/#brlcad Stattrav_ (~Stattrav@111.93.134.142) | |
| 11:12.08 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 11:12.08 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:10.46 | *** join/#brlcad Stattrav (~Stattrav@111.93.134.142) | |
| 12:10.46 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:08.16 | CIA-62 | BRL-CAD: 03brlcad * r45686 10/brlcad/trunk/src/libfb/ (if_X.c if_X24.c): quell set-but-unused warnings |
| 13:11.30 | CIA-62 | BRL-CAD: 03brlcad * r45687 10/brlcad/trunk/src/libgcv/bottess.c: dir unused |
| 13:14.02 | CIA-62 | BRL-CAD: 03brlcad * r45688 10/brlcad/trunk/src/libgcv/bottess.c: actually, build just wasn't up to date -- dir is used now, but i is not. quellage. |
| 13:17.41 | CIA-62 | BRL-CAD: 03brlcad * r45689 10/brlcad/trunk/src/libged/ (bo.c bot_dump.c): remove slew of set-yet-unused vars |
| 13:22.29 | CIA-62 | BRL-CAD: 03brlcad * r45690 10/brlcad/trunk/src/libged/edit.c: gcc 4.7 no longer considers these constant/computable at compile-time. so, meh, set them at runtime. |
| 13:26.55 | CIA-62 | BRL-CAD: 03brlcad * r45691 10/brlcad/trunk/src/libged/ (glob.c human.c): more set-and-unused var elimination |
| 13:30.22 | CIA-62 | BRL-CAD: 03brlcad * r45692 10/brlcad/trunk/src/libpc/pcVariable.h: j unused |
| 13:31.59 | CIA-62 | BRL-CAD: 03brlcad * r45693 10/brlcad/trunk/src/librt/opennurbs_ext.cpp: points a and b are unused, remove |
| 13:32.46 | brlcad | i'm liking this new version of the compiler .. the warnings have actually caught a slew of bugs, some minor, some not-so-minor |
| 13:40.31 | CIA-62 | BRL-CAD: 03brlcad * r45694 10/brlcad/trunk/include/bu.h: the pointer!=NULL comparison is always true for variables on the stack. cast through void so the compiler will shut it. |
| 13:42.25 | CIA-62 | BRL-CAD: 03brlcad * r45695 10/brlcad/trunk/src/libged/ (png.c ps.c red.c screengrab.c tire.c): remainder of libged set-and-unused warnings |
| 13:51.54 | CIA-62 | BRL-CAD: 03brlcad * r45696 10/brlcad/trunk/src/liboptical/photonmap.c: unused due to commented code |
| 13:52.56 | CIA-62 | BRL-CAD: 03brlcad * r45697 10/brlcad/trunk/src/libdm/labels.c: we dont' do anything with id, so don't bother saving it from rt_db_get_internal() |
| 13:54.42 | CIA-62 | BRL-CAD: 03brlcad * r45698 10/brlcad/trunk/src/conv/ (3dm/3dm-g.cpp dxf/dxf-g.c step/OpenNurbsInterfaces.cpp): set-and-unused quellage |
| 13:56.17 | CIA-62 | BRL-CAD: 03brlcad * r45699 10/brlcad/trunk/src/librtserver/rtserver.c: idx and los are unused, so get rid of them |
| 13:58.53 | CIA-62 | BRL-CAD: 03brlcad * r45700 10/brlcad/trunk/NEWS: |
| 13:58.53 | CIA-62 | BRL-CAD: preliminary testing of the conversion from SCLstring to std::string is showing a |
| 13:58.53 | CIA-62 | BRL-CAD: consistent speed improvement in step-g for relatively small models. Models |
| 13:58.53 | CIA-62 | BRL-CAD: taking less than a few minutes to convert are now taking approximately 10-30% |
| 13:58.53 | CIA-62 | BRL-CAD: less time. Unfortunately, models that take more than 10-20 minutes still take |
| 13:58.53 | CIA-62 | BRL-CAD: 10-20 minutes implying that some other processing dominates as the files get |
| 13:58.53 | CIA-62 | BRL-CAD: bigger. |
| 14:10.19 | CIA-62 | BRL-CAD: 03brlcad * r45701 10/brlcad/trunk/src/lgt/ (do_options.c screen.h): |
| 14:10.19 | CIA-62 | BRL-CAD: let TEMPLATE_COLS represent the number of chars not including null, so we're |
| 14:10.19 | CIA-62 | BRL-CAD: protected on both ends of printing. more tricky, gcc detected that the |
| 14:10.19 | CIA-62 | BRL-CAD: snprintf() range provided was too much since IR_AUTO_MAP_PTR already indexes far |
| 14:10.19 | CIA-62 | BRL-CAD: into template. |
| 14:12.47 | brlcad | and with that, we have our first clean strict pass on 4.7 |
| 14:13.43 | brlcad | still have to test optimized and 32-bit |
| 14:14.05 | brlcad | hits the road |
| 14:15.31 | CIA-62 | BRL-CAD: 03erikgreenwald * r45702 10/brlcad/trunk/src/libgcv/bottess.c: put the i's back, they're necessary for the next step |
| 14:23.05 | brlcad | ``Erik: I figured that was a work-in-progress .. but the newer compiler builds now halt on incomplete code that's enabled |
| 14:24.18 | brlcad | we'll have to #if-wrap works in progress that get committed (that i var is actually the only one that was active code, surprisingly) |
| 14:24.54 | brlcad | rather like it actually, encourages coding complete (and committing complete) instead of stubbed functionality |
| 14:38.42 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:39.00 | ``Erik | <PROTECTED> |
| 14:39.34 | ``Erik | would rather not do a 2000 line commit O.o |
| 14:45.21 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 15:28.23 | brlcad | ``Erik: I think it's smart enough to recognize that's a no-op and the var is still unused now |
| 15:32.38 | brlcad | starseeker: so there are just two or three files that keep getting edited in the source directory |
| 15:32.42 | brlcad | cmake is building built in a separate build dir |
| 15:32.50 | CIA-62 | BRL-CAD: 03r_weiss * r45703 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 15:32.51 | CIA-62 | BRL-CAD: Added two new functions to support the prototype version of nmg_triangulate_fu. |
| 15:32.51 | CIA-62 | BRL-CAD: These functions are 'nmg_tri_kill_accordions' and 'validate_tbl2d'. The first |
| 15:32.51 | CIA-62 | BRL-CAD: function is a specialized version of the 'nmg_kill_accordions' function which |
| 15:32.51 | CIA-62 | BRL-CAD: allows killed vertexuse to be removed (nulled out) from the tbl2d table. The |
| 15:32.51 | CIA-62 | BRL-CAD: second function verifies that all vertexuse within a faceuse is stored in the |
| 15:32.52 | CIA-62 | BRL-CAD: tbl2d table. These functions are a work in progress and are disabled by default. |
| 15:32.52 | brlcad | zconf.h |
| 15:33.41 | brlcad | cssprop.tcl, tokenlist.txt |
| 15:34.00 | ``Erik | commits and runs O.O |
| 15:34.00 | CIA-62 | BRL-CAD: 03erikgreenwald * r45704 10/brlcad/trunk/src/libgcv/bottess.c: gut stuff and use straight moller97, modified for BRL-CAD types |
| 15:48.13 | CIA-62 | BRL-CAD: 03r_weiss * r45705 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mod.c: Rewrote the 'nmg_kill_accordions' function within file 'nmg_mod.c'. The new version has cleaner logic and will continue to remove all accordions from a loopuse. |
| 15:54.33 | *** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no) | |
| 15:59.31 | CIA-62 | BRL-CAD: 03r_weiss * r45706 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 15:59.31 | CIA-62 | BRL-CAD: Updated function 'find_pt2d' within file 'nmg_tri.c'. This change allows this |
| 15:59.31 | CIA-62 | BRL-CAD: function to receive a null vertexuse pointer without crashing. In addition, when |
| 15:59.31 | CIA-62 | BRL-CAD: passed a null vertexuse pointer, this function will return the first entry in |
| 15:59.31 | CIA-62 | BRL-CAD: the table which contains a null vertexuse pointer. This is useful for finding |
| 15:59.32 | CIA-62 | BRL-CAD: entries in the table which can be reused instead of allocating a new table |
| 15:59.33 | CIA-62 | BRL-CAD: entry. |
| 16:16.07 | brlcad | bhinesley: looks like a strict 4.6 build should work just fine now |
| 16:46.28 | CIA-62 | BRL-CAD: 03r_weiss * r45707 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 16:46.29 | CIA-62 | BRL-CAD: Updated function 'join_mapped_loops' within file 'nmg_tri.c'. Added more error |
| 16:46.29 | CIA-62 | BRL-CAD: checking and did some code cleanup and improved the existing error messages. |
| 16:46.29 | CIA-62 | BRL-CAD: Changed some of the logic to support the prototype version of the |
| 16:46.29 | CIA-62 | BRL-CAD: 'nmg_triangulate_fu' function. Under certain conditions a new vertexuse can be |
| 16:46.29 | CIA-62 | BRL-CAD: created and it was not adding this to the tbl2d table. The logic changes are a |
| 16:46.30 | CIA-62 | BRL-CAD: work in progress and are disabled by default. |
| 17:41.31 | CIA-62 | BRL-CAD: 03brlcad * r45708 10/brlcad/trunk/src/conv/step/BRLCADWrapper.cpp: close the database on destruction, null out the pointer just in case |
| 17:43.52 | bhinesley | brlcad, sorry, there are still some issues: http://paste.pocoo.org/show/448279/ |
| 17:44.23 | CIA-62 | BRL-CAD: 03brlcad * r45709 10/brlcad/trunk/src/conv/step/step-g.cpp: so there is definitely some funky stack corruption going on. deleting the step wrapper crashes, investigating. |
| 17:44.55 | bhinesley | I cut out the middle of the file around 337, because it was too big to upload. The lines I cut out were similar to the ones directly before it. |
| 17:45.26 | brlcad | bhinesley: no need to be sorry, that's good |
| 17:45.54 | brlcad | strictness almost always requires multi-platform compilation to get all the issues ironed out |
| 17:49.59 | CIA-62 | BRL-CAD: 03brlcad * r45710 10/brlcad/trunk/src/conv/step/STEPWrapper.cpp: my bad, STEPWrapper doesn't get to own the dotg instance, they're stashing it for future use. was causing double-delete badness. |
| 17:50.50 | CIA-62 | BRL-CAD: 03brlcad * r45711 10/brlcad/trunk/src/conv/step/step-g.cpp: safe to delete stepwrapper again |
| 17:54.08 | bhinesley | brlcad: that trimmed it down enough so that I can upload the whole file now: http://paste.pocoo.org/show/448285/ |
| 17:54.18 | brlcad | cool, thx |
| 17:54.28 | bhinesley | np |
| 17:54.43 | bhinesley | oops, wait... that was the old one |
| 17:54.58 | brlcad | so in actuality, only a dozen or so issues remaining |
| 17:55.17 | brlcad | all the SdaiCONFIG_CONTROL_DESIGN ones aren't fatal (that's auto-generated code) |
| 17:56.33 | bhinesley | nods |
| 17:57.01 | bhinesley | wgetpaste is playing tricks on me... uploading the old version of a file that has been overwritten (!) |
| 17:59.40 | bhinesley | ahh, n/m, it's a problem with my primary selection/clipboard. The link in here is good, the link getting pasted into my browser is old. |
| 18:03.32 | bhinesley | counts about 50 errors, probably only a dozen or so unique as brlcad mentioned |
| 18:45.51 | CIA-62 | BRL-CAD: 03r_weiss * r45712 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 18:45.51 | CIA-62 | BRL-CAD: Changed the function 'join_mapped_loops' within file 'nmg_tri.c'. I disabled one |
| 18:45.51 | CIA-62 | BRL-CAD: of the error checks which was causing some problems. The error check is now only |
| 18:45.51 | CIA-62 | BRL-CAD: enabled when the prototype version of function 'nmg_triangulate_fu' is enabled. |
| 18:46.30 | CIA-62 | BRL-CAD: 03brlcad * r45713 10/brlcad/trunk/src/conv/step/SdaiCONFIG_CONTROL_DESIGN.cc: delete debug code |
| 18:47.29 | abhi2011 | hi |
| 18:47.43 | abhi2011 | I am trying to add a command to mged |
| 18:48.03 | abhi2011 | its to learn how to add commands basically |
| 18:48.21 | abhi2011 | so I have copied out the tire.c file to a new file physics.c |
| 18:48.28 | abhi2011 | and made some changes |
| 18:49.04 | abhi2011 | the command will be simply called runphysics and has no parameters |
| 18:49.19 | abhi2011 | so apart from making a new source file, are there any other changes needed |
| 18:49.33 | abhi2011 | to compile it as part of libged |
| 18:53.25 | brlcad | of course :) |
| 18:53.46 | abhi2011 | in the CMakeLists.txt i guess |
| 18:53.47 | brlcad | otherwise how would libged know your new file from thesis.doc |
| 18:54.09 | abhi2011 | haha |
| 18:54.12 | abhi2011 | :) |
| 18:54.12 | brlcad | CMakeLists.txt and Makefile.am |
| 18:54.17 | abhi2011 | ok |
| 18:54.26 | brlcad | we have two build systems being maintained at the moment |
| 18:54.29 | brlcad | so two files |
| 18:54.45 | abhi2011 | ok, and the specific CMakeLists.txt to be edited is the top level one in the brlcad directory i guess |
| 18:54.49 | brlcad | once added, that will compile the file |
| 18:55.13 | brlcad | then you'll either want to add a command binding to mged or create a stand-alone application wrapper |
| 18:55.30 | abhi2011 | ah yes the command binding |
| 18:55.34 | brlcad | mged bindings are in src/mged/setup.c |
| 18:55.37 | abhi2011 | there wqa a specific c file for that |
| 18:55.38 | abhi2011 | right |
| 18:55.53 | brlcad | stand-alone wrapper would be writing a small binary like src/shapes/tire.c |
| 18:56.05 | abhi2011 | ok |
| 18:56.18 | abhi2011 | yah i ll try with the command binding first |
| 18:56.24 | abhi2011 | though it makes more sense |
| 18:56.31 | abhi2011 | to have it as a binary wrapper |
| 18:56.53 | abhi2011 | I have an interesting question though |
| 18:56.55 | brlcad | makes more sense as an mged command, but a binary wrapper will be easier for initial testing |
| 18:57.03 | abhi2011 | yes exactly |
| 18:57.21 | abhi2011 | and most physics engines |
| 18:57.28 | abhi2011 | can launch an opengl render window |
| 18:57.38 | abhi2011 | and show whats happening in the physics world |
| 18:57.55 | abhi2011 | which can help at times |
| 18:58.11 | brlcad | well, that would be mged |
| 18:58.34 | abhi2011 | yes right, mged already shows an opengl windows |
| 18:58.37 | brlcad | writing opengl or windowing code for a standalone binary would be undesirable, waste of time frankly |
| 18:58.39 | abhi2011 | *window |
| 18:58.47 | abhi2011 | yes right |
| 18:59.11 | brlcad | standalone binary would be just to run the simulation, console debug printing, simplified testing |
| 18:59.46 | abhi2011 | yes |
| 19:00.31 | abhi2011 | I understand your point of course. Bullet already comes with accurate rendering code though :) so there is no need to write it :) |
| 19:01.01 | brlcad | BRL-CAD already comes with rendering code too, so there's no need to bind to a new 3rd party interface |
| 19:01.11 | abhi2011 | hehe :) yes true |
| 19:03.40 | CIA-62 | BRL-CAD: 03brlcad * r45714 10/brlcad/trunk/src/libdm/dm-ogl.c: quellage, remove set-but-not-used variables |
| 19:06.45 | brlcad | bhinesley: grep -E '(CURSES|TERM|TINFO)' include/brlcad_config.h |
| 19:06.49 | brlcad | (in your build dir) |
| 19:07.00 | brlcad | /home/bhinesley/brlcad-trunk/src/libcursor/cursor.c looks like a cmake detection failure |
| 19:07.17 | brlcad | not testing for termcap or curses correctly |
| 19:07.42 | brlcad | same thing with the burst too (Sc.c) |
| 19:08.43 | brlcad | so those look like the only three problems, dm-ogl.c which I just fixed and those two files (cursor.c and Sc.c) which have the same termcap detection problem |
| 19:10.51 | abhi2011 | so I have added a new command just after rtweight |
| 19:10.58 | abhi2011 | {"rtweight", cmd_rt, GED_FUNC_PTR_NULL}, |
| 19:10.59 | CIA-62 | BRL-CAD: 03brlcad * r45715 10/brlcad/trunk/src/conv/step/OpenNurbsInterfaces.cpp: debug code tracing down stack corruption accidentally got committed. re-enable advanced brep entity loading. |
| 19:10.59 | abhi2011 | {"runphysics", cmd_rt, GED_FUNC_PTR_NULL}, |
| 19:12.39 | brlcad | doesn't look right |
| 19:12.54 | brlcad | you were following the tire command, that's your example -- not rtweight |
| 19:13.11 | brlcad | at least in terms of what that line should look like, doesn't matter where it's at |
| 19:17.29 | abhi2011 | ok yah the tire command is a wrapper ...right i ll change it |
| 19:18.51 | abhi2011 | right this should be ok |
| 19:18.54 | abhi2011 | <PROTECTED> |
| 19:18.56 | abhi2011 | <PROTECTED> |
| 19:18.57 | abhi2011 | <PROTECTED> |
| 19:19.16 | abhi2011 | i changed the c function name of course in the .c file |
| 19:24.10 | brlcad | kunigami_: just to be sure, you have seen http://code.google.com/p/openshadinglanguage/w/list y es? |
| 19:24.54 | bhinesley | brlcad: #define HAVE_TERMIO_H 1\n#define HAVE_TERMIOS_H 1 |
| 19:26.52 | kunigami | brlcad: yup. I didn't read the light path expression because I thought that was not a feature that would be useful for brlcad, or am I wrong? |
| 19:29.28 | abhi2011 | brlcad: hmm I went through the CMakeLists.txt file in the brlcad top level directory, there does not appear to be a place to add a mged command there |
| 19:29.38 | abhi2011 | for example I dont see tire anywhere |
| 19:29.58 | abhi2011 | *mged application wrapper i mean, not a command |
| 19:36.29 | brlcad | abhi2011: not following |
| 19:36.35 | brlcad | you add it to libged's file |
| 19:36.35 | CIA-62 | BRL-CAD: 03brlcad * r45716 10/brlcad/trunk/src/other/ (CMakeLists.txt libz/CMakeLists.txt): test to see what breaks. leave the zconf.h file alone, don't abort if it exists. |
| 19:37.43 | bhinesley | abhi2011: I think you're looking for libged/CMakeList.txt |
| 19:38.46 | abhi2011 | ah yes, |
| 19:38.57 | brlcad | starseeker: I'll give that a go with some testing, but that should be a pretty safe/easy change |
| 19:39.07 | abhi2011 | I have added it to setup.c in src/mged/ |
| 19:39.17 | abhi2011 | and now I want to add it to the build logic |
| 19:39.27 | brlcad | because zconf.h isn't "actually" autogenerated .. at least zconf.h.in doesn't have any substitution patterns, so it's just a copy |
| 19:39.49 | brlcad | which means there could be a million copies in a million include dirs and it won't affect build in the least |
| 19:40.01 | brlcad | testing now though |
| 19:40.31 | abhi2011 | so I guess the right place to add the the new c file that implements runphysics (i.e. src/libged/runphysics.c), to the build logic is libged/CMakeList.txt |
| 19:42.06 | CIA-62 | BRL-CAD: 03brlcad * r45717 10/brlcad/trunk/src/other/libz/zconf.h.cmakein: remove the _LARGEFILE64_SOURCE hack from the cmake template too. causes build problems with system headers that also define it. |
| 19:46.30 | abhi2011 | ok thats done, now the autotools build has to know about the new c file as well |
| 19:46.50 | abhi2011 | So I guess the new filename should go into Makefile.am |
| 19:46.58 | abhi2011 | in the top level directory |
| 19:47.11 | bhinesley | nope, in libged/Makefile.am |
| 19:47.30 | abhi2011 | ah yes there is one there too...right of course |
| 19:47.37 | bhinesley | haha |
| 19:47.44 | abhi2011 | :P |
| 19:48.20 | abhi2011 | these make files and cmake files are all over the place ! |
| 19:49.13 | ``Erik | hm, cmake seems to do everything in it's power to prevent a profiling build |
| 20:00.09 | starseeker | brlcad: yeah, I actually have added the two define options in the cmakein file in the CMakeLists.txt file as definitons, which means we don't need that file at all. |
| 20:00.56 | CIA-62 | BRL-CAD: 03starseeker * r45718 10/brlcad/trunk/src/other/ (libz/CMakeLists.txt libz/zconf.h.cmakein libz.dist): Eliminate the need for a separate zconf.h.cmakein file by simply adding the definitions at the CMakeLists.txt level if they are needed. |
| 20:03.53 | starseeker | looks at cssprop.tcl, tokenlist.txt to see if he can get them to change |
| 20:11.12 | CIA-62 | BRL-CAD: 03r_weiss * r45719 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 20:11.12 | CIA-62 | BRL-CAD: Updated the prototype version of function 'cut_unimonotone' within file |
| 20:11.12 | CIA-62 | BRL-CAD: 'nmg_tri.c'. This function supports the prototype version of function |
| 20:11.12 | CIA-62 | BRL-CAD: 'nmg_triangulate_fu'. Improved the error checking and the logic to cleanup |
| 20:11.12 | CIA-62 | BRL-CAD: problem loopuse. Also did some code cleanup. This change is disabled by default. |
| 20:11.12 | CIA-62 | BRL-CAD: This is a work in progress. |
| 20:19.07 | starseeker | ``Erik: here's a good quote for you: |
| 20:19.11 | starseeker | "You don't make a good language by smashing a bunch of "projects" together. If you do that, you end up with C++." |
| 20:21.36 | CIA-62 | BRL-CAD: 03bhinesley * r45720 10/brlcad/trunk/src/libged/edit.c: Changed all union edit_cmd args to pointers. Kinda liked the idea of them being automatic, as it would simplify building commands, but we need to be able to shuffle them around easily for the *_add_arg functions. |
| 20:22.57 | CIA-62 | BRL-CAD: 03bhinesley * r45721 10/brlcad/trunk/src/ (libdm/dm-ogl.c libtclcad/tclcad_obj.c): Quiet some compiler warnings about unused variables. |
| 21:04.42 | CIA-62 | BRL-CAD: 03starseeker * r45722 10/brlcad/trunk/src/other/libpng/configure.ac: autogen failed - add back in what seem to be the related differences from the previous libpng configure.ac |
| 21:06.33 | starseeker | in case anyone else wants profiling w/cmake, it's BRLCAD-ENABLE_PROFILING |
| 21:09.00 | ``Erik | yeh, srry, found that var earlier, only mentioned it to starseeker in person |
| 21:17.32 | CIA-62 | BRL-CAD: 03starseeker * r45723 10/brlcad/trunk/src/other/libpng/configure.ac: whoops, typo |
| 21:21.41 | starseeker | cool - with that zconf.h change, in principle the CMake build should now leave behind a pristine source tree |
| 21:33.23 | CIA-62 | BRL-CAD: 03starseeker * r45724 10/brlcad/trunk/configure.ac: need both source and build dirs as includes now for libpng |
| 21:35.44 | CIA-62 | BRL-CAD: 03starseeker * r45725 10/brlcad/trunk/NEWS: Upgraded libpng to 1.5.4 |
| 21:36.53 | starseeker | brlcad: yeah, I'm not seeing any changes to the tkhtml files here doing both an autotools and cmake out of dir build... |
| 21:37.14 | starseeker | guess the next thing to try is in dir... |
| 21:50.59 | ``Erik | starseeker: the slashdot comments on java7 release? |
| 21:53.08 | starseeker | heh - yeah |
| 21:54.50 | CIA-62 | BRL-CAD: 03erikgreenwald * r45726 10/brlcad/trunk/src/libgcv/bottess.c: cleanup, more style normalization, removal of some dead code |
| 21:55.38 | starseeker | that should take care of libpng, unless another platform exposes some issue - working on Linux now |
| 22:01.44 | CIA-62 | BRL-CAD: 03starseeker * r45727 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Don't add omit-frame-pointer if we're profiling - things are Not Happy. |
| 22:53.28 | CIA-62 | BRL-CAD: 03r_weiss * r45728 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: Updated the prototype version of function 'nmg_triangulate_fu' within file 'nmg_tri.c'. The logic was simplified and code cleanup was done. This change is disabled by default. This is a work in progress. |
| 23:41.10 | *** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net) | |
| 00:25.36 | CIA-62 | BRL-CAD: 03bhinesley * r45729 10/brlcad/trunk/src/libged/edit.c: (log message trimmed) |
| 00:25.36 | CIA-62 | BRL-CAD: Started on command-specific argument handling for translate, fixed some minor |
| 00:25.36 | CIA-62 | BRL-CAD: problems, and simplified some things. Need to have edit() add appropriate flags |
| 00:25.36 | CIA-62 | BRL-CAD: to command line args and remove command line character options from each arg's |
| 00:25.36 | CIA-62 | BRL-CAD: cl_options[] before I can continue. Tried to add this functionality in |
| 00:25.36 | CIA-62 | BRL-CAD: ged_edit() as it is originally adding the args, but it really needs to be done |
| 00:25.37 | CIA-62 | BRL-CAD: on a second loop, since the arguments before and after the current arg make a |
| 01:08.49 | CIA-62 | BRL-CAD: 03kunigami * r45730 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h sh_osl.cpp): started coding the (supposely) raytracer using OSL. the results are not correct |
| 01:09.12 | kunigami_ | http://dl.dropbox.com/u/1399996/GSoC/Refraction-Weight.png |
| 01:09.43 | kunigami_ | I still didn't find out how to get the colors from the shaders :( |
| 01:11.25 | kunigami_ | What I'm currently doing is to traverse each light and call eval_reflect (I didn't understand why there exists eval_transmit) and get the average weight |
| 03:04.46 | brlcad | someone needs to tell r_weiss that he doesn't really need to mention the file name in his commit messages... kinda blatently redundant |
| 03:05.40 | brlcad | kunigami_: so what is that picture? |
| 05:52.41 | *** join/#brlcad Stattrav (~Stattrav@122.178.209.201) | |
| 05:52.41 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:08.34 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 08:54.43 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 08:54.51 | abhi2011 | hi |
| 08:55.09 | abhi2011 | So I was trying to add a new command yesterday to mged |
| 08:55.18 | abhi2011 | I get this error during the build |
| 08:56.03 | abhi2011 | http://bin.cakephp.org/view/276195617 |
| 08:56.29 | abhi2011 | seems after adding the implementing c function to setup.c, it has to be also declared somewhere |
| 08:59.07 | bhinesley | abhi2011: lets see your setup.c line again |
| 08:59.32 | abhi2011 | {"tire", cmd_ged_plain_wrapper, ged_tire}, |
| 08:59.34 | abhi2011 | <PROTECTED> |
| 08:59.36 | abhi2011 | <PROTECTED> |
| 08:59.53 | abhi2011 | the 2nd lie was added by me |
| 09:00.39 | abhi2011 | i think ged_runphysics has to be declared in libged somewhere |
| 09:01.14 | abhi2011 | maybe after i changed the implementation name in the c file |
| 09:01.27 | abhi2011 | I have to declare it in a related header |
| 09:02.28 | bhinesley | there are a ton of places for new commands to be "declared", for various uses. It's kind of a dark art. Try adding a line to the cmd_tab in src/libtclcad/tclcad_obj.c |
| 09:03.31 | bhinesley | not sure if that will do you any good since you're trying to add it to mged only |
| 09:03.47 | abhi2011 | ok i will try that |
| 09:04.49 | abhi2011 | but are you sure there is no header file like src/libged/runphysics.h required for the newly added src/libged/runphysics.c |
| 09:05.17 | bhinesley | yes, actually, I just recalled what it is you probably need: include/ged.h |
| 09:05.31 | abhi2011 | i do have it included |
| 09:05.38 | abhi2011 | let me paste the code 1 sec |
| 09:06.21 | abhi2011 | http://bin.cakephp.org/view/1016518663 |
| 09:08.03 | bhinesley | Oh, right... I meant that you probably need to add a ged_runphysics declaration to the file include/ged.h |
| 09:08.04 | abhi2011 | but ged.h does not have a declaration of the new function in runphysics.c , |
| 09:08.05 | abhi2011 | int |
| 09:08.06 | abhi2011 | ged_runphysics(struct ged *gedp, int argc, const char *argv[]) |
| 09:08.11 | bhinesley | nods |
| 09:08.13 | abhi2011 | ok |
| 09:11.09 | abhi2011 | by the way, what does wdb routine mean |
| 09:11.14 | abhi2011 | came across them in ged.h |
| 09:12.21 | bhinesley | search HACKING for libwdb |
| 09:12.35 | abhi2011 | right :) |
| 09:13.57 | abhi2011 | cool the build resumed again |
| 09:14.14 | bhinesley | cool |
| 09:33.20 | CIA-62 | BRL-CAD: 03bhinesley * r45731 10/brlcad/trunk/src/libged/edit.c: |
| 09:33.20 | CIA-62 | BRL-CAD: Updated several helper functions to work with a recent change from automatic |
| 09:33.20 | CIA-62 | BRL-CAD: arguments in union edit_cmd to pointers. Added command-specific functions to |
| 09:33.20 | CIA-62 | BRL-CAD: initialize the needed argument pointers. Fixed a problem with the help |
| 09:33.20 | CIA-62 | BRL-CAD: subsystem, and eliminated a bit of redundancy. More edit() testing, but not a |
| 09:33.20 | CIA-62 | BRL-CAD: whole heck of lot of foreward progress yet. |
| 09:50.45 | kunigami_ | brlcad: it's the average weight returned by eval_reflect |
| 11:46.25 | *** join/#brlcad Stattrav (~Stattrav@122.178.209.201) | |
| 11:46.25 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 12:18.36 | abhi2011 | success!! |
| 12:18.41 | abhi2011 | new command added :P |
| 12:22.10 | abhi2011 | I was wondering, regarding mged application wrappers |
| 12:22.32 | abhi2011 | so suppose i have written a simple application that say just prints hello world |
| 12:22.45 | abhi2011 | now I want to integrate it into mged |
| 12:23.48 | abhi2011 | so I would insert code in libged like |
| 12:23.50 | abhi2011 | int |
| 12:23.51 | abhi2011 | ged_runphysics(struct ged *gedp, int argc, const char *argv[]) |
| 12:24.51 | abhi2011 | so i guess i would need to migrate the c code to the wrapper c file inside libged |
| 12:25.29 | abhi2011 | it would not be possible for mged to call my precompiled program and direct its output to its own output in the mged window ? |
| 12:26.51 | abhi2011 | and also provide it input through the argc, argv[] arguments that is generally used to receive command line parameters by c programs ? |
| 12:29.30 | abhi2011 | hmm I guess not, such a thing would need to be done by the wrapper function if at all required |
| 13:21.05 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 13:53.47 | brlcad | kunigami_: ah, that makes a lot more sense! |
| 13:55.27 | brlcad | looks like there's a curious bias, though -- I'd expect surface reflectivity to be fairly constant for the flat surfaces |
| 13:56.10 | brlcad | looks more like it's showing the relative amount of energy reflected |
| 13:57.58 | brlcad | abhi2011: you could call a preompiled program and direct output to the mged window (several mged commands do exactly that) ... it's just bad design |
| 13:58.20 | brlcad | and for a physics engine integration, you really don't want unnecessary overhead |
| 13:58.53 | brlcad | needs to be tight and fast so you could call it 20 times a second without delay |
| 14:52.44 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 14:52.44 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 15:14.06 | abhi2011 | right i ll insert it as a command in mged |
| 15:14.51 | abhi2011 | right now I am checking with a checked out copy of brlcad, whether i can compile and install bullet with it and start the physics through a command |
| 15:15.11 | abhi2011 | so bullet has it own sources of course |
| 15:15.31 | abhi2011 | where would you generally place the sources for an external library, in the src tree i mean |
| 17:35.02 | ``Erik | src/other/ usually... but until it's end user ready, it might be better to say "hey, developers, you need bullet installed to use it" |
| 18:37.01 | abhi2011 | right ok |
| 18:37.10 | abhi2011 | so i have got bullet installed and running now |
| 18:37.39 | abhi2011 | will proceed to write add it to the runphysics command |
| 18:37.42 | abhi2011 | but before that |
| 18:38.11 | abhi2011 | is there any command or app wrapper that access the list of objects in mged |
| 18:38.17 | abhi2011 | i want to se how its done |
| 18:38.50 | abhi2011 | because say the user has drawn a sphere, then I would need its dimensions to insert it in the physics world and run a simulation |
| 18:49.52 | abhi2011 | hmm...I am using the autotools build, I have included a new Bullet header now to the new command I had added to mged earlier (by modifying tire.c in src/libged) |
| 18:50.52 | abhi2011 | the new header is #include <btBulletDynamicsCommon.h> , and its already been placed in /usr/local/include/bullet during Bullet installation |
| 18:51.05 | abhi2011 | but apparently bullet does not look here for headers |
| 18:51.19 | abhi2011 | have to modify the build logic to make sure it does |
| 18:55.33 | abhi2011 | any idea where exactly can add this so it appears as a -I/usr/local/include/bullet compiler option during the build |
| 19:03.20 | CIA-62 | BRL-CAD: 03starseeker * r45732 10/brlcad/trunk/CMakeLists.txt: Provide an option to allow RPMS to have a version-specific unique name, to make it simpler to allow for installing multiple versions of BRL-CAD on one system. |
| 20:11.58 | *** join/#brlcad CalinPaulAlexand (~Calin@109.99.20.242) | |
| 21:46.12 | *** join/#brlcad DarkCalff (DC@173.231.40.98) | |
| 22:17.43 | bhinesley | yay, clean build time went from 37min -> 16min when I switched out my 7200RPM drive for an SSD |
| 22:49.44 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 22:51.24 | abhi2011 | hi |
| 22:51.35 | abhi2011 | I have a question regarding adding new headers |
| 00:09.02 | CIA-62 | BRL-CAD: 03bhinesley * r45733 10/brlcad/trunk/src/libged/edit.c: Fixed crash due to use of uninitialized pointers; command union wasn't being initialized early enough. |
| 01:57.36 | starseeker | makes a note to investigate CMake's FeatureSummary.cmake |
| 01:58.13 | starseeker | rather an interesting survey here - someone went through KDE's cmake logic, covers a lot of interesting points: http://community.kde.org/index.php?title=KDE_Core/Platform_11/Buildsystem/FindFilesSurvey |
| 02:16.07 | *** join/#brlcad kunigami1 (~kunigami@loco-gw.ic.unicamp.br) | |
| 02:17.06 | *** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 02:17.06 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 03:04.34 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 06:38.02 | CIA-62 | BRL-CAD: 03bhinesley * r45734 10/brlcad/trunk/src/libged/edit.c: |
| 06:38.03 | CIA-62 | BRL-CAD: Finished the edit_translate_add_cl_args() function (previously *_add_args()), so |
| 06:38.03 | CIA-62 | BRL-CAD: the logic of unique cmd-line args for that cmd are validated (needed 1 done to |
| 06:38.03 | CIA-62 | BRL-CAD: proceed with edit()). Added flagging of common options to ged_edt(); now, only |
| 06:38.03 | CIA-62 | BRL-CAD: cmd-specific options are recorded as chars. Since bug fix in r45733, I was able |
| 06:38.03 | CIA-62 | BRL-CAD: to start enabling/testing '.' batch operator(WIP). Also, made an alias of '--'. |
| 06:38.04 | CIA-62 | BRL-CAD: Trimmed long lines/comments. Removed dead code. |
| 07:07.25 | *** join/#brlcad Stattrav (~Stattrav@117.213.188.221) | |
| 07:07.25 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:14.05 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:37.34 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.139.9) | |
| 08:59.23 | CIA-62 | BRL-CAD: 03bhinesley * r45735 10/brlcad/trunk/src/libged/edit.c: (log message trimmed) |
| 08:59.24 | CIA-62 | BRL-CAD: Due to some previous changes, an edit_arg was set to point at to something |
| 08:59.24 | CIA-62 | BRL-CAD: before being 'initialized' to NULL, which was causing crashes later on. Also, |
| 08:59.24 | CIA-62 | BRL-CAD: the natural origin option was still being saved as a character, and the target |
| 08:59.24 | CIA-62 | BRL-CAD: object flag was not being set. Enabled support for multiple target object |
| 08:59.24 | CIA-62 | BRL-CAD: arguments. Added helper function to free last arg in a list, broke common |
| 08:59.25 | CIA-62 | BRL-CAD: functionality out to reduce redundancy. edit_translate_add_cl_args() is |
| 09:40.37 | *** join/#brlcad CalinPaulAlexand (~Calin@109.99.20.242) | |
| 10:17.57 | abhi2011 | hi |
| 10:19.31 | abhi2011 | I am trying to add a new header, for an external library |
| 10:20.59 | abhi2011 | the header is located in /usr/local/include/bullet and I need to add this to the brlcad include paths. But I am not very sure where exactly I need to add it (I am using autotools build) |
| 10:21.58 | abhi2011 | i think it should be the pkgincludedir = $(includedir)/brlcad variable |
| 17:02.06 | *** join/#brlcad CalinPaulAlexand (~Calin@109.99.20.242) | |
| 17:54.55 | *** join/#brlcad CalinPaulAlexand (~Calin@109.99.20.242) | |
| 18:05.43 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 18:15.48 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 23:42.19 | *** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net) | |
| 06:01.21 | ``Erik | hm |
| 09:55.10 | abhi2011 | ok figured out the build system, seems like i have to add all include directories to the configure script with checks |
| 10:54.11 | abhi2011 | hi |
| 10:54.46 | abhi2011 | I have inserted some headers from the bullet library into brlcad and I have modified the build logic to look in the include library |
| 10:55.19 | abhi2011 | however the compile stops when it sees the 'class' c++ keyword in one of the bullet headers |
| 10:55.53 | abhi2011 | i think perhaps libged is not being compiled with some c++ compiler flag being appropriately set |
| 11:08.05 | abhi2011 | http://bin.cakephp.org/view/1255993858 |
| 13:05.08 | abhi2011 | Generally successful compiles with Bullet go as follows : g++ -I/usr/local/include/bullet main.cpp -L/usr/local/lib -lBulletDynamics -lBulletCollision -lLinearMath |
| 13:20.26 | brlcad | abhi2011: you can't include a c++ header into a .c file |
| 13:20.58 | brlcad | you'll have to layer the interface so that the c++ is encapsulated |
| 13:21.48 | brlcad | one way would be to have the src/libged/yourfile.c call functions from a src/libged/implfile.cpp (which includes the bullet header) |
| 13:28.04 | abhi2011 | right |
| 13:28.30 | abhi2011 | and the libraries need to be added to the configure script as well ? |
| 14:01.51 | ``Erik | when the symbols are needed, they will need to be linked against the library or binary, yes... (might be better to use cmake instead of automake at this point) |
| 14:12.39 | CIA-62 | BRL-CAD: 03kunigami * r45736 10/brlcad/trunk/src/liboptical/liboslrend.cpp: discovered how to get the object color from the closures. the next step is how to make the closure tell me to perform reflection |
| 14:37.59 | CIA-62 | BRL-CAD: 03brlcad * r45737 10/brlcad/trunk/CMakeLists.txt: CAD_VERSION was only needed to bridge an m4 variable to a shell variable, cmake can just set BRLCAD_VERSION. on that note, use it where triplets are called for and keeping with our naming guidelines. |
| 15:21.55 | abhi2011 | right, thanks brlcad and Erik |
| 15:22.28 | abhi2011 | yah I would use cmake as soon as the issues with gcc 4.6.0 are resolved |
| 16:56.48 | brlcad | abhi2011: most if not all of the issues should be resolved now |
| 16:56.56 | brlcad | as of a couple days ago |
| 16:58.03 | abhi2011 | cool, i will give it a try :) |
| 17:33.01 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.213) | |
| 17:33.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:38.29 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.139.18) | |
| 17:40.09 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:32.53 | brlcad | starseeker: ``Erik: ping |
| 22:04.58 | brlcad | ~seen tharis20 |
| 22:05.08 | ibot | tharis20 <~tharis@2.83.244.20> was last seen on IRC in channel #brlcad, 4d 21h 27m 46s ago, saying: 'oh man, I don't know how I'm going to wake up early tomorrow...'. |
| 22:17.11 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 22:29.39 | CIA-62 | BRL-CAD: 03brlcad * r45738 10/brlcad/trunk/TODO: document initial thoughts on a 'simulate' command syntax |
| 22:55.25 | CIA-62 | BRL-CAD: 03brlcad * r45739 10/brlcad/trunk/TODO: options for applying or not applying standard gravity in a simplified form (-g being default) |
| 00:38.03 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) | |
| 01:48.10 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 02:02.49 | *** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net) | |
| 02:23.20 | CIA-62 | BRL-CAD: 03kunigami * r45740 10/brlcad/trunk/src/rt/do.c: added a experimental mode to call do_run several times. by now each run is independent, but my next step is to sum the colors in scanline array instead of just setting them. |
| 07:12.08 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 09:42.34 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 10:06.41 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 10:29.27 | *** join/#brlcad Stattrav (~Stattrav@117.192.147.9) | |
| 10:29.27 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:49.30 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 11:41.36 | *** join/#brlcad Stattrav (~Stattrav@117.202.26.38) | |
| 11:41.36 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:50.04 | *** join/#brlcad Elrohir (~kvirc@p5B14B46A.dip.t-dialin.net) | |
| 11:58.20 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:35.09 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.159.229) | |
| 12:52.02 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:53.42 | *** join/#brlcad Stattrav (~Stattrav@117.202.31.56) | |
| 12:53.42 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:03.53 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.145.237) | |
| 13:19.26 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:25.52 | CIA-62 | BRL-CAD: 03r_weiss * r45741 10/brlcad/trunk/src/libged/edit.c: Updated file 'edit.c' within the libged library. Fixed some compile warnings/errors. |
| 14:26.30 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 14:27.26 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 14:48.30 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 14:49.30 | brlcad | yawns |
| 15:11.00 | d_rossberg | last change in libged/edit.c (r45741): shouldn't there be a bu_free()? or #define the array sizes? |
| 16:49.33 | brlcad | bhinesley: d_rossberg's question is directed towards you ;) |
| 16:51.46 | bhinesley | brlcad: oh okay. I was just looking at it and trying to figure out why those changes were made |
| 16:52.15 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 16:52.25 | bhinesley | but yes, d_rossberg, it needs to be freed at the least |
| 16:55.37 | bhinesley | I don't understand why "struct edit_arg *arg_heads[len];" was changed to "struct edit_arg **arg_heads;" |
| 16:56.06 | bhinesley | I mean, why coudn't it be automatic |
| 17:05.23 | brlcad | he's not here right now |
| 17:06.01 | bhinesley | ah |
| 17:06.06 | brlcad | bhinesley: c90 prohibits dynamic array sizes based on runtime variable values |
| 17:06.22 | brlcad | c++ allows it |
| 17:07.07 | brlcad | c99 might even allow it, but it's more portable to allocate your size as needed if the size can't be known at compile-time |
| 17:07.37 | bhinesley | oh okay, so I can probably just use a #define, since I do know the size at compile-time |
| 17:08.16 | brlcad | nods |
| 17:08.30 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 17:19.23 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 17:37.39 | CIA-62 | BRL-CAD: 03bhinesley * r45742 10/brlcad/trunk/src/libged/edit.c: |
| 17:37.39 | CIA-62 | BRL-CAD: Compiler warnings because of dynamically sized arrays based on runtime variable |
| 17:37.39 | CIA-62 | BRL-CAD: were resolved by allocating memory in r45741 (which was not subsequently being |
| 17:37.39 | CIA-62 | BRL-CAD: freed). Since these sizes are known at compile time, we can instead size the |
| 17:37.39 | CIA-62 | BRL-CAD: arrays using preprocessor macros. Also resolved, were 3 warnings about printf |
| 17:37.40 | CIA-62 | BRL-CAD: format specifiers; the pointers needed to be dereferenced. |
| 17:40.10 | *** join/#brlcad Stattrav (~Stattrav@117.192.134.200) | |
| 17:40.10 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:51.05 | *** join/#brlcad Stattrav (~Stattrav@117.192.134.200) | |
| 17:51.05 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:55.49 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 18:00.32 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 18:10.14 | brlcad | congratulations abhi2011 |
| 18:10.31 | abhi2011 | Thanks brlcad |
| 18:10.46 | abhi2011 | didnt expect it :P |
| 18:11.00 | brlcad | so this will be pretty exciting, can't wait to see some objects responding to gravity :) |
| 18:11.29 | abhi2011 | hehe yes :) |
| 18:11.38 | brlcad | it's going to be a lot of work, but I think you'll manage if you work hard at it and put a lot of time into figuring things out |
| 18:11.41 | abhi2011 | by the way about yesterday's code |
| 18:12.00 | abhi2011 | so the gedp structure was something I could not get rid of |
| 18:12.06 | brlcad | so that's pretty exemplary, yesterday's code exercise |
| 18:12.25 | abhi2011 | ok |
| 18:12.27 | brlcad | shouldn't really take more than an hour, and you got stuck :) |
| 18:12.40 | abhi2011 | ya i wasted 45 mins on the linking issue :P |
| 18:12.47 | abhi2011 | coding took much less time |
| 18:12.56 | brlcad | yet coding is incomplete too :) |
| 18:13.03 | abhi2011 | hehe :P |
| 18:13.19 | brlcad | so you really do need to figure out how to get that to work |
| 18:13.21 | abhi2011 | yah the gedp structure was something i COULD NOT GET RID OF |
| 18:13.25 | abhi2011 | oops no caps |
| 18:13.27 | brlcad | it's actually directly related to your task |
| 18:13.29 | abhi2011 | sorry |
| 18:13.43 | abhi2011 | yes |
| 18:14.10 | abhi2011 | so a question |
| 18:14.17 | brlcad | you'll need to read that code over and over until you understand what it's doing and figure out how the bounding box is actually calculated |
| 18:14.25 | brlcad | without libged, naturally :) |
| 18:14.49 | abhi2011 | ah ok, I was thinking there is a function in libged that directly takes an object extracted from the .g file |
| 18:14.50 | brlcad | or with it -- frankly doesn't matter, it's just not necessary |
| 18:15.04 | abhi2011 | yes exactly, no point rebuilding the wheel |
| 18:15.27 | brlcad | there is a function in libged that directly takes an object extracted from the .g file |
| 18:15.32 | abhi2011 | right |
| 18:15.37 | abhi2011 | was looking for that :) |
| 18:15.50 | brlcad | you need to read the code |
| 18:16.02 | brlcad | because you already sort of found it, or at least found the direct pointers to it |
| 18:16.27 | brlcad | if it's not obvious, you should review that code line by line until you understand it ;) |
| 18:16.33 | abhi2011 | yes i will look through the functions defined in libged and make that program work |
| 18:17.27 | abhi2011 | ok be right back in few mins |
| 18:46.12 | CIA-62 | BRL-CAD: 03bhinesley * r45743 10/brlcad/trunk/src/libged/edit.c: fixed off by one error in a function that frees linked list of args; was causing crashes in some cases |
| 18:58.56 | *** join/#brlcad Stattrav (~Stattrav@117.192.134.200) | |
| 18:58.56 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:10.37 | abhi2011 | back |
| 20:02.53 | *** join/#brlcad Stattrav (~Stattrav@117.192.134.200) | |
| 20:02.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:09.34 | CIA-62 | BRL-CAD: 03bhinesley * r45744 10/brlcad/trunk/src/libged/edit.c: (log message trimmed) |
| 20:09.34 | CIA-62 | BRL-CAD: One of the translate cmd's functions was not detecting missing "TO" args, which |
| 20:09.34 | CIA-62 | BRL-CAD: ged_edit() intentionally doesn't detect if the -k option isn't given. A function |
| 20:09.34 | CIA-62 | BRL-CAD: to free edit_cmd obj's was only partially working since args were changed from |
| 20:09.34 | CIA-62 | BRL-CAD: being automatic to malloc'd. Fixed several related/unrelated problems with |
| 20:09.35 | CIA-62 | BRL-CAD: regard to freeing and allocating memory. Added a helper function to only free |
| 20:09.36 | CIA-62 | BRL-CAD: args if they are unused, which saved some checks/vars later on. There were some |
| 20:19.24 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 20:22.35 | CIA-62 | BRL-CAD: 03r_weiss * r45745 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 20:22.35 | CIA-62 | BRL-CAD: Updated the prototype version of function 'cut_unimonotone' within file |
| 20:22.35 | CIA-62 | BRL-CAD: 'nmg_tri.c'. This change adds a check for null edgeuse. This prototype function |
| 20:22.35 | CIA-62 | BRL-CAD: supports the prototype version of 'nmg_triangulate_fu'. These changes are |
| 20:22.35 | CIA-62 | BRL-CAD: disabled by default. These changes are a work in progress. |
| 20:29.18 | CIA-62 | BRL-CAD: 03r_weiss * r45746 10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c: |
| 20:29.18 | CIA-62 | BRL-CAD: Updated functions 'nmg_class_pt_e', 'nmg_class_pt_l', 'class_vu_vs_s', |
| 20:29.18 | CIA-62 | BRL-CAD: 'nmg_class_pt_s', 'class_eu_vs_s' and 'class_lu_vs_s' within file 'nmg_class.c'. |
| 20:29.18 | CIA-62 | BRL-CAD: Most of the updates were changes to support the prototype version of function |
| 20:29.18 | CIA-62 | BRL-CAD: 'nmg_triangulate_fu'. The remainer of the changes were code cleanup. The logic |
| 20:29.18 | CIA-62 | BRL-CAD: changes are disabled by default and are a work in progress. These changes are |
| 20:29.19 | CIA-62 | BRL-CAD: related to classification of nmg objects during boolean operations. |
| 20:29.28 | CIA-62 | BRL-CAD: 03starseeker * r45747 10/brlcad/branches/STABLE/src/ (libged/erase.c libged/mater.c librt/primitives/ars/ars.c): Add a few bugfix patches to STABLE. |
| 20:38.03 | CIA-62 | BRL-CAD: 03r_weiss * r45748 10/brlcad/trunk/src/librt/primitives/nmg/nmg_rt_isect.c: (log message trimmed) |
| 20:38.04 | CIA-62 | BRL-CAD: Updated functions 'vertex_neighborhood', 'ray_hit_vertex', 'isect_ray_faceuse', |
| 20:38.04 | CIA-62 | BRL-CAD: 'guess_class_from_hitlist_max', 'guess_class_from_hitlist_min' and |
| 20:38.04 | CIA-62 | BRL-CAD: 'nmg_class_ray_vs_shell' within file 'nmg_rt_isect.c'. Most of the changes |
| 20:38.04 | CIA-62 | BRL-CAD: support the prototype version of the function 'nmg_triangulate_fu'. The |
| 20:38.04 | CIA-62 | BRL-CAD: remaining changes are code cleanup. The logic changes are disabled by default |
| 20:38.05 | CIA-62 | BRL-CAD: and are a work in progress. These changes are related to classification of nmg |
| 20:45.26 | CIA-62 | BRL-CAD: 03r_weiss * r45749 10/brlcad/trunk/src/librt/primitives/nmg/nmg_pt_fu.c: Updated function 'nmg_class_pt_eu' within file 'nmg_pt_fu.c'. Changed a floating point compare to 0.0 to using SMALL_FASTF. |
| 22:13.06 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r3039 10/wiki/User:Kunigami/GSoc2011/Reports: added log for past week |
| 22:13.50 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r3040 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */ corrected formatting error |
| 22:14.09 | CIA-62 | BRL-CAD: 03bhinesley * r45750 10/brlcad/trunk/src/libged/edit.c: Improved detection/alerts of translate command syntax-error. |
| 22:15.19 | bhinesley | kunigami: bah, you just reminded me that I've been forgetting that again :-/ |
| 22:15.31 | kunigami | bhinesley: :) |
| 22:24.50 | abhi2011 | brlcad I found the reason for the linking errors yesterday |
| 22:25.38 | abhi2011 | I was using fedora from virtual box and I had placed the main.c file in a mounted partition |
| 22:25.48 | abhi2011 | the partition is a windows partition |
| 22:26.32 | abhi2011 | once I copied the file into the /home its having no problem finding librt |
| 22:32.11 | abhi2011 | hmm no thats not the reason |
| 22:32.34 | abhi2011 | well anyway am using a native installation now so it should be fine |
| 22:45.54 | brlcad | bhinesley: kunigami: you guys have been fantastic at updating your reports (completely unprompted) .. seriously I think you're both a couple of the best I've seen at announcing your activities |
| 22:45.58 | brlcad | kudos |
| 22:46.49 | kunigami | brlcad: thanks! |
| 22:47.07 | bhinesley | cool... I worry about these things ;-) |
| 23:15.25 | ``Erik | (btw, great job on passing the midpoint, too) |
| 23:15.52 | bhinesley | thank you |
| 23:17.58 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 23:18.03 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3041 10/wiki/User:Abhijit: /* Development timeline */ |
| 23:52.30 | *** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net) | |
| 01:50.14 | CIA-62 | BRL-CAD: 03kunigami * r45751 10/brlcad/trunk/src/rt/ (do.c ext.h opt.c view.c): |
| 01:50.14 | CIA-62 | BRL-CAD: added simple support for the multi-sample framebuffer. I'm currently using the |
| 01:50.14 | CIA-62 | BRL-CAD: scanline array to hold the partial averages, but this is not good since it is a |
| 01:50.14 | CIA-62 | BRL-CAD: char array and many values will be truncated when I compute the next average. I |
| 01:50.14 | CIA-62 | BRL-CAD: think we must use a dedicated buffer to hold these averages. To test this mode, |
| 01:50.15 | CIA-62 | BRL-CAD: compile with -DEXPERIMENTAL_MODE |
| 01:51.13 | CIA-62 | BRL-CAD: 03kunigami * r45752 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp sh_osl.cpp): the experimental mode should be used with path-tracing, turning off ray-tracing on sh_osl... |
| 03:43.59 | brlcad | kunigami: what do you mean by "turning off ray-tracing on sh_osl"? |
| 03:44.48 | brlcad | ah, you mean your single-ray test? |
| 03:46.28 | brlcad | mm, looks like it |
| 03:47.29 | brlcad | so question about that for loop at the end of sh_osl.cpp .. it looks like it's basically calling rt_shootray() over and over again unless it's a refraction ray |
| 03:52.12 | brlcad | ah, but only if reflection is being performed, hmm |
| 03:57.49 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 04:37.24 | CIA-62 | BRL-CAD: 03bhinesley * r45753 10/brlcad/trunk/src/libged/edit.c: |
| 04:37.24 | CIA-62 | BRL-CAD: edit() will now "expand" batch operation args, by performing a deep copy of |
| 04:37.24 | CIA-62 | BRL-CAD: every target obj's edit_arg struct, consolidating option flags between the two |
| 04:37.24 | CIA-62 | BRL-CAD: as necessary. Added detection of keypoints missing their matching 'TO' arg, |
| 04:37.24 | CIA-62 | BRL-CAD: since every cmd should have that behavior. Replaced edit_arg_free_if_empty() |
| 04:37.25 | CIA-62 | BRL-CAD: with edit_arg_is_empty; a bit more versatile that way. |
| 05:07.03 | Stattrav | can i compile the source on my computer by suppressing the "treating warnings as errors" notification ? |
| 05:07.15 | Stattrav | for a dev machine for brlcad ? |
| 06:35.16 | *** join/#brlcad Stattrav (~Stattrav@117.213.184.103) | |
| 06:35.16 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:40.15 | *** join/#brlcad Stattrav_ (~Stattrav@117.202.27.11) | |
| 06:52.32 | *** join/#brlcad Stattrav (~Stattrav@117.192.131.187) | |
| 06:52.33 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 07:09.33 | bhinesley | Stattrav, if you're using autotools, use "--disable-strict". If you're using cmake, you can use -DBRLCAD-ENABLE_STRICT=OFF |
| 07:10.41 | Stattrav | bhinesley: aah compiled by removing -Werror :) thanks. i shall make a note of it for the next time |
| 07:11.17 | bhinesley | no problem |
| 11:27.57 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 11:27.57 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 11:38.30 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 11:38.43 | *** join/#brlcad Stattrav (~Stattrav@117.192.129.74) | |
| 11:38.43 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 11:57.13 | CIA-62 | BRL-CAD: 03starseeker * r45754 10/brlcad/branches/STABLE/src/libfft/CMakeLists.txt: Add the libfft CMakeLists.txt tweak to STABLE. |
| 12:18.58 | brlcad | there were probably a hundred places that needed M_LIBRARY |
| 12:46.25 | starseeker | brlcad: that one specifically fell out of a particular compile |
| 12:48.42 | starseeker | it was when I tossed in the -Wl,--no-undefined line to CMAKE_SHARED_LINKER_FLAGS - that one, and only that one, failed (IIRC) |
| 13:28.02 | CIA-62 | BRL-CAD: 03starseeker * r45755 10/brlcad/trunk/CMakeLists.txt: CMake doesn't currently work with umask settings, so there's no point in setting it ahead of time. |
| 14:06.34 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 14:34.31 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 14:46.10 | abhi2011 | Hi, while using the cmake build is there a flag to stop treating warnings as errors |
| 14:46.36 | abhi2011 | just as with the autotools build there is ./configure --enable-all --disable-strict --with-ogl |
| 14:55.18 | abhi2011 | ah its just a simple flag :P : cmake ../brlcad -DBRLCAD-ENABLE_OPTIMIZED=ON -DBRLCAD-ENABLE_STRICT=OFF |
| 15:01.22 | brlcad | starseeker: ah, the issue is that for some platforms, no-undefined is the system default for ld |
| 15:01.35 | brlcad | there were two users in here that run into that problem (with fedora, I believe) |
| 15:23.42 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 15:32.19 | CIA-62 | BRL-CAD: 03brlcad * r45756 10/brlcad/trunk/src/rt/view.c: quell variable type warnings, stub in code for displaying progress during raytrace ... which unfortunately kills render performance. |
| 15:33.33 | CIA-62 | BRL-CAD: 03brlcad * r45757 10/brlcad/trunk/src/rt/do.c: more type quellage (someone needs to compile strict) .. use bu_log() instead of fprintf(). only bu_log() supports %z for size_t types (with c90). |
| 17:04.47 | *** join/#brlcad Stattrav (~Stattrav@117.192.146.245) | |
| 17:04.47 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:38.07 | abhi2011 | brlcad compiled and ran successfully with cmake under opensuse 11.4, though the gcc is old (gcc 4.5.1) |
| 17:38.32 | brlcad | that's not really an old gcc |
| 17:38.44 | brlcad | 4.0 is old, 4.2 is a little old |
| 17:41.16 | brlcad | dang .. something still doesn't seem right with cmake debug builds .. no debugging symbols in the binary |
| 17:41.28 | brlcad | CMAKE_MODULE_LINKER_FLAGS_DEBUG:STRING= |
| 17:41.45 | brlcad | that doesn't look right, need -g during compilation and linking |
| 17:41.55 | brlcad | CMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING= |
| 17:41.57 | brlcad | too |
| 17:48.26 | ``Erik | heh, rhel5 ships with 4.1.2, fbsd8 is 4.2.2, osX xcode3 is 4.2.1 O.o 4.5 sounds pretty new to me :D |
| 17:49.12 | abhi2011 | yes true, i meant since 4.6.0 is out now :P |
| 17:49.27 | abhi2011 | the CMAKE_MODULE_LINKER_FLAGS_DEBUG is not one of the cmake flags is it ? |
| 17:49.44 | abhi2011 | i dont see it in CMakeLists.txt |
| 17:58.02 | brlcad | no worries, that was more a directed inquiry towards starseeker |
| 17:59.31 | starseeker | brlcad: I haven't been doing much in the way of setting linker flags thus far |
| 18:00.07 | starseeker | so yeah, there are probably some we'll need to add |
| 18:00.09 | brlcad | so you've not been working in gdb very much I take it then? :) |
| 18:00.28 | starseeker | not too much lately, but I have done so before... |
| 18:01.09 | starseeker | never noticed anything amiss, which probably means I wasn't doing something right... |
| 18:01.31 | brlcad | I think that's the crux of the issue, debug/cflags used for compile aren't being used during linking |
| 18:02.06 | starseeker | um... which issue? |
| 18:02.46 | starseeker | now remembers why he loathed the tcl build system so much... gah |
| 18:02.52 | brlcad | I have binaries getting linked without debug symbols |
| 18:03.09 | brlcad | and sure enough, if I make VERBOSE=1, there is no -g on the linker line |
| 18:04.24 | brlcad | /vld/other/morrison/Applications/bin/gcc -pipe -fno-strict-aliasing -fno-common -fexceptions -std=gnu99 -m64 -pedantic -Wall -Wextra -Wundef -Wfloat-equal -Wshadow -Winline -Wno-long-long -Werror -m64 CMakeFiles/myapp.dir/myapp.c.o -o ../../bin/myapp -rdynamic ../../lib/libwdb.so.19.0.1 -lm ../../lib/librt.so.19.0.1 ../../lib/libbn.so.19.0.1 ../../lib/libbu.so.19.0.1 -lpthread -lpng ../../lib/libsysv.so.19.0.1 ../../lib/libtcl.so.8.5.9 -lm -ldl ../../lib/ |
| 18:04.50 | ``Erik | huh, mysql went cmake |
| 18:04.52 | brlcad | so it's passing a whole variety of flags, but not -g |
| 18:05.19 | starseeker | k - that's probably a missing line in CMake/CompilerFlags.cmake |
| 18:08.17 | CIA-62 | BRL-CAD: 03starseeker * r45758 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Add the debug flag to the shared library linker line - may need to fix more than this, but it's a start |
| 18:10.03 | brlcad | what is CMAKE_SHARED_LINKER_FLAGS_${CFG_TYPE} ? |
| 18:10.10 | brlcad | other flags don't set that... |
| 18:10.51 | CIA-62 | BRL-CAD: 03starseeker * r45759 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: key off of the debug option, not build type, since we might be turning on debug flags even in a release build. |
| 18:11.13 | CIA-62 | BRL-CAD: 03brlcad * r45760 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: setting cflags/cxxflags is insufficient (or cmake is wrong to not apply cflags during linking), the linker needs to have debug flags for executables too |
| 18:11.28 | starseeker | brlcad: that's CMAKE_SHARED_LINKER_FLAGS_DEBUG for a debug build, CMAKE_SHARED_LINKER_FLAGS_RELEASE build |
| 18:12.09 | brlcad | but then what purpose does CMAKE_SHARED_LINKER_FLAGS serve? |
| 18:12.28 | starseeker | if you have no build type at all set, it falls back on that one (if I understand correctly) |
| 18:13.03 | starseeker | I'm currently making people work to NOT have a build type set, but that's relatively recent |
| 18:13.04 | brlcad | err, I thought I saw a message during cmake saying "build profile not set, using Debug" ? |
| 18:13.47 | starseeker | yeah - that's me turning it on if it's not set - you can force it to stay off by specifying NONE (I think) but the assumption is you want the build type set |
| 18:15.15 | brlcad | cmake doesn't use LD_FLAGS? |
| 18:15.41 | starseeker | um - you mean if you specify it on the command line? not sure |
| 18:15.49 | brlcad | no, I mean internally |
| 18:16.04 | brlcad | C_FLAGS and CXX_FLAGS variables get set |
| 18:16.07 | starseeker | oh - no, I think it uses the SHARED_LINKER_FLAGS stuff |
| 18:16.20 | brlcad | but curiously no LD_FLAGS, which would be the pairing |
| 18:16.37 | brlcad | is C_FLAGS a var you came up with or cmake? |
| 18:17.07 | starseeker | I believe that one is CMake |
| 18:17.25 | starseeker | http://cmake.org/Wiki/CMake_Useful_Variables |
| 18:18.20 | brlcad | CFLAGS/CXXFLAGS/CPPFLAGS/LDFLAGS are the historic var names |
| 18:18.51 | brlcad | er, they list CMAKE_C_FLAGS .. that's not the same as C_FLAGS |
| 18:19.06 | starseeker | oh, yeah - sorry |
| 18:19.31 | starseeker | I've found that list to be very useful, seems to be fairly accurate |
| 18:20.55 | brlcad | so you set C_FLAGS, and presumably down the line, CMAKE_C_FLAGS is set to your C_FLAGS |
| 18:22.10 | starseeker | right |
| 18:25.24 | starseeker | hmm... actually, I can probably clean up that logic some |
| 18:26.52 | CIA-62 | BRL-CAD: 03brlcad * r45761 10/brlcad/trunk/src/libbu/getopt.c: style cleanup |
| 18:27.56 | CIA-62 | BRL-CAD: 03brlcad * r45762 10/brlcad/trunk/src/libbu/getopt.c: no place for you |
| 18:28.11 | starseeker | I was using a lot of my own variables in the earlier days, before I got a handle on what variables were used for what |
| 18:36.50 | starseeker | brlcad: ah, right - I remember now. C_FLAGS is actually a variable holding the name of the correct CMAKE_C_FLAGS_* variable for the build type |
| 18:45.38 | brlcad | hm, neat trick, but sounds potentially problematic |
| 18:46.11 | brlcad | since for some of the output targets, cmake generates all build profiles into the output (e.g., studio or xcode) |
| 18:50.51 | starseeker | does it? I was under the impression you had to specify Debug or Release at CMake time, but I could be wrong |
| 18:51.26 | brlcad | possibly, but those build systems do support multiple configurations |
| 18:52.10 | brlcad | MSVC pretty much came up with the concept of separate Debug and Release build configurations (named as such) |
| 18:53.22 | starseeker | nods - the question though is whether CMake actually generates both configurations in valid form from a single CMake run |
| 18:53.27 | brlcad | yep |
| 18:58.19 | brlcad | this makes it sound like it does: http://www.cmake.org/pipermail/cmake/2010-January/034365.html |
| 19:05.53 | starseeker | hmm... mutter... |
| 19:13.06 | *** join/#brlcad Stattrav (~Stattrav@117.192.146.245) | |
| 19:13.06 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:15.07 | CIA-62 | BRL-CAD: 03starseeker * r45763 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/CompilerFlags.cmake): More refinement of the compiler flags logic. May have to go one step further for MSVC project files... |
| 19:22.34 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:51.16 | CIA-62 | BRL-CAD: 03starseeker * r45764 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Have a go at setting compiler flags for all configurations. |
| 19:51.28 | starseeker | brlcad: that might do it |
| 19:52.39 | CIA-62 | BRL-CAD: 03starseeker * r45765 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: whoops, typo |
| 20:05.16 | CIA-62 | BRL-CAD: 03starseeker * r45766 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Some cleanup and typo fixes, make the ADD_NEW_FLAG macro a bit more flexible |
| 20:07.25 | starseeker | huh, cool: http://chiselapp.com/user/andreas_kupries/repository/crimp/home |
| 21:28.07 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 06:18.08 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 06:18.08 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 06:58.40 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 07:03.34 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 09:35.41 | d_rossberg | starseeker: the STRICT_FLAGS is a little bit disturbing to MSVC |
| 09:54.36 | *** join/#brlcad Stattrav (~Stattrav@122.178.209.201) | |
| 09:54.42 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:12.24 | abhi2011 | ok thanks bhinesly and brlcad |
| 10:41.07 | abhi2011 | bhinesley: db_lookup(dbip, argv[2], 1) is correct then as db_lookup works on objects inside the database, and sph1.s is an object inside the sphere.g database |
| 10:41.54 | abhi2011 | however it seems that ged_bb() treats the command line differently from what I expect |
| 10:42.32 | abhi2011 | so I give the db name first and the object name 2nd which is argv[1] and argv[2] respectively |
| 10:43.35 | abhi2011 | but it treats argv[1] also as an object name in the currently open db, so I modified the code to pass argv+1 instead and argc =1, so that only 1 object name (sph1.s) gets passed |
| 10:44.13 | abhi2011 | like this : if ( ged_bb(gedp, 1, argv+1) == GED_OK){.... |
| 10:45.26 | abhi2011 | ged_bb() still doesnt return GED_OK though, so I am checking if something else is going wrong |
| 11:08.43 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:19.11 | abhi2011 | ok I got the bb now ! |
| 12:19.27 | abhi2011 | but it seems I cant print the bound by just printing the gedp result string |
| 12:19.53 | abhi2011 | so if i try printf("%s\n", gedp->ged_result_str); |
| 12:20.09 | abhi2011 | then i get �;3� !! |
| 12:20.44 | abhi2011 | I ll check if its actually a char* |
| 12:37.46 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 12:49.35 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:08.57 | abhi2011 | ah ok its a variable length string to save memory |
| 13:13.12 | abhi2011 | YES!!!...finally got the bb printed :P |
| 13:13.20 | abhi2011 | printf("%s\n", ( ((gedp->ged_result_str)->vls_str) + ((gedp->ged_result_str)->vls_offset) ) ); |
| 13:13.38 | abhi2011 | output is same as in archer for a unit sphere centred at the origin |
| 13:15.39 | abhi2011 | perhaps not the most efficient but works : http://bin.cakephp.org/view/1085618267 |
| 13:46.31 | starseeker | d_rossberg: "disturbing?" |
| 13:52.21 | d_rossberg | MSVC does not know how to handle a "STRICT_FLAGS" compiler switch, so it tries to open a file with this name |
| 13:53.24 | d_rossberg | probable a problem in cmake: not STRICT_FLAGS is meant but its value |
| 13:55.44 | *** join/#brlcad DarkCalff (DC@173.231.40.98) | |
| 14:56.59 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 15:12.18 | brlcad | abhi2011: so this is going to be a learning experience, but good work figuring out how to print the bb |
| 15:13.21 | brlcad | your end result uses the libged API, which is a very high-level interface |
| 15:13.32 | brlcad | a few "mistakes", one being what you did with ged_result_str |
| 15:13.57 | brlcad | it's a struct bu_vls ... and accessing the internal vls_str and vls_offset is a no-no |
| 15:14.16 | brlcad | there are printing routines for that |
| 15:14.32 | brlcad | you'd either use bu_log() instead of printf() where you can use %V to print them |
| 15:15.11 | brlcad | or you'd call printf() with bu_vls_addr(dedp->ged_result_str) to get the underlying char * |
| 15:16.22 | brlcad | abhi2011: so then the next useful step is to compute the bounding box without calling ged_open() or ged_bb(), using the lower level librt API that libged is using |
| 15:24.05 | CIA-62 | BRL-CAD: 03kunigami * r45767 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h sh_osl.cpp): changed the field reflection by ray_type so that it can also represent transmission rays. I hope this way the logic gets clearer |
| 15:40.28 | abhi2011 | brlcad : right will try that |
| 15:43.44 | brlcad | so, db_open(), and other db_*() and rt_*() api calls, no ged_*() functions |
| 15:44.03 | brlcad | that will be what your physics command will need to do |
| 15:44.10 | abhi2011 | yes, that was my other option if libged were not to work, but chose the easy way out first :P |
| 15:44.23 | abhi2011 | yes right |
| 15:44.47 | brlcad | nothing wrong with that approach |
| 15:45.08 | brlcad | and in most other contexts, calling libged would be fine too |
| 15:45.26 | abhi2011 | umm so why not in this case too |
| 15:45.33 | brlcad | if anything, you can read the source for ged_bb() and follow the functions to see how it computes the bb |
| 15:45.42 | abhi2011 | yes i did that |
| 15:45.52 | abhi2011 | i know how to use the librt functions now |
| 15:46.01 | brlcad | so then it should be very clear and trivial to convert ;) |
| 15:46.09 | abhi2011 | yep :) |
| 15:46.25 | brlcad | this case is different because you're also implementing a libged function |
| 15:46.49 | abhi2011 | so we cannot use other libged functions ? |
| 15:47.04 | abhi2011 | that are exported...just curious |
| 15:47.04 | brlcad | ged functions shouldn't be built on other ged functions when the common functionality has already been refactored into librt |
| 15:47.10 | brlcad | it just adds layered complexity |
| 15:47.11 | abhi2011 | ah ok |
| 15:47.22 | abhi2011 | and will introduce delays |
| 15:47.23 | brlcad | as well as slows things down |
| 15:47.25 | brlcad | nods |
| 15:47.27 | abhi2011 | yep |
| 15:47.55 | brlcad | the slow down in negligible for interactive use, but is significant for programmatic use |
| 15:48.14 | abhi2011 | yah...we want real time motion..yay ! |
| 15:48.18 | abhi2011 | :) |
| 15:49.16 | abhi2011 | by the way I was wondering, brl cad was used before my usmil right |
| 15:49.35 | abhi2011 | so they moved on to other software and open sourced this ? |
| 15:50.40 | abhi2011 | I was looking for some of the full forms of the primitives like tgc in google and I came across this : http://www.digitaldogma.org/archive/MikeMuuss/papers/brlcad5.0/html/mged/tableofcontents2_1.html |
| 16:16.49 | *** join/#brlcad survery (~thomas@dslb-178-007-120-202.pools.arcor-ip.net) | |
| 16:17.05 | *** part/#brlcad survery (~thomas@dslb-178-007-120-202.pools.arcor-ip.net) | |
| 16:21.16 | bhinesley | abhi2011: that makes sense. I was looking for calls directly to db_lookup in your pastbin; I didn't catch that. Glad you got it working. |
| 16:24.39 | abhi2011 | bhinesley: yep, converting to use only rt now |
| 17:22.49 | CIA-62 | BRL-CAD: 03starseeker * r45768 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Was getting too clever for my own good. If ADD_NEW_FLAG comes in empty, don't do anything - should avoid the error on Windows |
| 17:28.03 | CIA-62 | BRL-CAD: 03r_weiss * r45769 10/brlcad/trunk/include/raytrace.h: |
| 17:28.03 | CIA-62 | BRL-CAD: Added an entry into the 'raytrace.h' header for a new function 'nmg_keu_zl' |
| 17:28.03 | CIA-62 | BRL-CAD: which removes all zero length edgeuse from an nmg shell. This function is |
| 17:28.03 | CIA-62 | BRL-CAD: disabled by default and is a work in progress. This function supports the |
| 17:28.03 | CIA-62 | BRL-CAD: prototype version of 'nmg_triangulate_fu'. |
| 17:31.08 | CIA-62 | BRL-CAD: 03r_weiss * r45770 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mk.c: |
| 17:31.08 | CIA-62 | BRL-CAD: Added a new function 'nmg_keu_zl' which removes all zero length edgeuse from an |
| 17:31.08 | CIA-62 | BRL-CAD: nmg shell. This was added into file 'nmg_mk.c'. This function is disabled by |
| 17:31.08 | CIA-62 | BRL-CAD: default and supports the prototype version of 'nmg_triangulate_fu'. This is a |
| 17:31.08 | CIA-62 | BRL-CAD: work in progress. |
| 17:42.59 | CIA-62 | BRL-CAD: 03r_weiss * r45771 10/brlcad/trunk/src/librt/primitives/tor/tor.c: (log message trimmed) |
| 17:42.59 | CIA-62 | BRL-CAD: Updated function 'rt_tor_tess' within file 'src/librt/primitives/tor/tor.c' by |
| 17:42.59 | CIA-62 | BRL-CAD: adding a call to function 'nmg_keu_zl' which removes all zero length edgeuse. |
| 17:42.59 | CIA-62 | BRL-CAD: Under certain conditions the function 'rt_tor_tess' will create a tessellated |
| 17:42.59 | CIA-62 | BRL-CAD: torus which contains zero length edgeuse which is invalid and causes a crash in |
| 17:43.00 | CIA-62 | BRL-CAD: later functions. An example of a torus which causes a crash during 'facetize' is |
| 17:43.00 | CIA-62 | BRL-CAD: object 'old.s82' within the 'm35.g' sample model. This change is disabled by |
| 18:18.57 | CIA-62 | BRL-CAD: 03kunigami * r45772 10/brlcad/trunk/src/rt/view.c: added a dedicated buffer to keep partial sums on multi-sample modes |
| 18:24.54 | CIA-62 | BRL-CAD: 03kunigami * r45773 10/brlcad/trunk/src/rt/view.c: had left behind a debug message |
| 18:27.20 | ``Erik | mysql removed from osX.7, nice |
| 19:04.33 | CIA-62 | BRL-CAD: 03brlcad * r45774 10/brlcad/trunk/include/vmath.h: add missing zero macros, HNEAR_ZERO(), VZERO(), V2ZERO(), & HZERO() |
| 19:04.43 | CIA-62 | BRL-CAD: 03r_weiss * r45775 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message trimmed) |
| 19:04.43 | CIA-62 | BRL-CAD: Added new functions 'print_loopuse_tree', 'nmg_classify_pt_loop_new', |
| 19:04.43 | CIA-62 | BRL-CAD: 'nmg_classify_lu_lu_new', 'insert_above', 'insert_node' and |
| 19:04.43 | CIA-62 | BRL-CAD: 'nmg_build_loopuse_tree' to file 'nmg_tri.c'. These function are prototype |
| 19:04.44 | CIA-62 | BRL-CAD: functions which support the prototype version of 'nmg_triangulate_fu'. Some of |
| 19:04.44 | CIA-62 | BRL-CAD: these functions may have their names changed or moved to a more appropriate |
| 19:04.45 | CIA-62 | BRL-CAD: location within the code. These functions are the beginning of code which |
| 19:05.34 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 19:20.56 | brlcad | kunigami: it might be beneficial in the long run to use a long or floating point accumulation buffer |
| 19:21.31 | kunigami | yup I'm using long |
| 19:21.47 | brlcad | awesome, missed that ;) |
| 19:24.41 | brlcad | that means we'll be able to accumulate about 16M passes before the buffer is "full" (at 32-bit) .. that's a lot of hypersampling ;) |
| 19:25.59 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 19:27.04 | kunigami | when adding inside sh_osl, I could have values greater than 1.0, but with averages bellow 1.0. Thus, it was not "clamped". now, if I have any component greater than 1.0, it will be clamped and the average will be near 0 if the other components are 0. I have a test Scenesthat relies on strong brightnes. It was rendered nicely before, but now it is too dark. Would be wrong if I avoid clamping the components of the sum, but only the sum itself? |
| 19:38.58 | brlcad | kunigami: if I understand you correctly (and I'm not 100% sure that I do), then yes.. you can use the buffer as an accumulation buffer and clamp/average/downsample at some later processing stage |
| 19:42.24 | brlcad | for hypersampling, for example, instead of accumulating "value/#rays" for each hypersample ray (i.e. val/#rays * #rays => final_value), it would accumulate "value" as-is (resulting in "value * #rays" in the buffer), then divide by the #rays at the end or scale to 255 or whatever |
| 19:45.46 | CIA-62 | BRL-CAD: 03brlcad * r45776 10/brlcad/trunk/BUGS: a torus with a zero sized inner diameter results in zero-length edges during tessellation. nmg_keu_zl() could remove them, but it implies there is a flaw in the rt_tor_tess() logic not accounting for the edge case. |
| 19:46.43 | brlcad | kunigami: did my response make sense about the two different options? |
| 19:50.42 | kunigami | brlcad: yes, that makes sense. I'll do the same way as hypersampling, thanks |
| 20:40.49 | *** join/#brlcad merzo (~merzo@59-47-132-95.pool.ukrtel.net) | |
| 21:26.36 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 21:46.33 | CIA-62 | BRL-CAD: 03kunigami * r45777 10/brlcad/trunk/src/rt/ (do.c view.c): changed the accumulator buffer to float so that it saves the raw components of ap.a_color before theyre clamped. We only expand and clamp it when moving the partial sums to scanline |
| 22:01.47 | *** join/#brlcad Yoshi477 (~jan@d72-39-60-53.home1.cgocable.net) | |
| 22:14.43 | abhi2011 | so I am trying to get the bb now using librt only |
| 22:14.52 | abhi2011 | here is the code so far : http://bin.cakephp.org/view/570066725 |
| 22:15.12 | abhi2011 | I run it as ./a.out dome.g sph2.s rcc2.s |
| 22:15.34 | abhi2011 | the objects are present in the dome.g database file as I can see them in archer |
| 22:15.58 | abhi2011 | yet : db_lookup(sph2.s) failed: sph2.s does not exist |
| 22:16.07 | abhi2011 | so I am debugging with gdb now |
| 22:16.53 | abhi2011 | and I saw that inside db_lookup there is a line that tries to hash the name 'sph2.s' (when its being looked up) |
| 22:17.56 | abhi2011 | line 230 : dp = dbip->dbi_Head[db_dirhash(name)]; |
| 22:18.38 | abhi2011 | the hash for 'sph2.s' is 747 which is why dbip->dbi_Head[db_dirhash(name)]; returns null and consequently the lookup fails |
| 22:23.15 | abhi2011 | probably the hash value can be anything, but perhaps its out of range in this case of the array dbi_Head[] |
| 22:31.29 | abhi2011 | perhaps its because the objects sph2.s and rcc2.s are leaves, that is they are not children of higher levels groups |
| 23:01.48 | abhi2011 | probaly the directory is not built up already as in the rtexample.c |
| 23:13.24 | abhi2011 | ok easier to use rtip = rt_dirbuild(argv[1], title, sizeof(title)); |
| 23:13.47 | abhi2011 | and rt_gettree(rtip, argv[2]) with bb calculated using rt_prep_parallel(rtip, 1); |
| 23:24.19 | ``Erik | *reads he pastebin* yeah, you do need an rt_prep somewhere in there, that's where the bb gets set |
| 23:25.28 | abhi2011 | well yes, but I did not reach that far in that code, the db_lookup() called from db_string_to_path() in line 50, barfed well before that ! |
| 23:25.40 | abhi2011 | I guess cause there was no directory built up |
| 23:26.14 | abhi2011 | this command would normally get called from inside mged when rtip would have a valid directory setup containing the structure of the model |
| 23:26.44 | abhi2011 | but for the command line program its probably not so, so I have to start by calling rt_dirbuild() |
| 23:27.36 | ``Erik | hm, yeah (not too familiar with the very early stages of opening/parsing a .g, myself), I think you're right |
| 23:28.23 | ``Erik | some of the src/conv/ programs use prepared geometry and are quite a bit simpler than the src/rt stuff... might be worth poking around in there for examples |
| 23:28.49 | CIA-62 | BRL-CAD: 03bhinesley * r45778 10/brlcad/trunk/src/libged/edit.c: |
| 23:28.49 | CIA-62 | BRL-CAD: Started on functions that convert db_full_path objects to points (natural |
| 23:28.49 | CIA-62 | BRL-CAD: origin/bounding box center); WIP. edit() was getting a bit difficult to read, |
| 23:28.49 | CIA-62 | BRL-CAD: which has led to several bugs, so I broke out batch expansion code into |
| 23:28.49 | CIA-62 | BRL-CAD: edit_arg_expand(). There are still some problems preventing this from working, |
| 23:28.50 | CIA-62 | BRL-CAD: but I haven't commited in a while and need to. Several changes to struct |
| 23:28.51 | CIA-62 | BRL-CAD: edit_arg helper functions; needed more versatility |
| 23:29.07 | abhi2011 | ah ok, umm why the 'conv' are they converted from some other library or something ? |
| 23:30.05 | ``Erik | converting between formats |
| 23:30.38 | bhinesley | abhi2011, the HACKING file tells you what the major directories are for |
| 23:31.05 | ``Erik | g-shell-rect.c fires rays to solve new geometry |
| 23:31.35 | ``Erik | um, also; the rtcmp toplevel project has an rt directory with a VERY minimal and simple example of how to get rt firing rays at geometry |
| 23:33.09 | abhi2011 | ah yes right thanks Erik and bhinesley |
| 23:33.13 | ``Erik | which is rt_dirbuild(); rt_gettree(); rt_prep_parallel(); |
| 23:34.45 | abhi2011 | the rtcmp sounds interesting, will have a look |
| 23:36.01 | ``Erik | it's minimal and hackish, was to compare performance/correctness between 3 raytracing engines |
| 23:36.14 | ``Erik | not "production" code :) |
| 23:36.57 | abhi2011 | ok, yah I just need a quick intro to raytracing using brlcad |
| 23:40.13 | ``Erik | http://brlcad.svn.sourceforge.net/viewvc/brlcad/rtcmp/trunk/rt/rt.c?revision=34030&view=markup |
| 23:40.52 | ``Erik | that's about as simple as it gets... the hit() function is a bit more than you might need, but the rest... :) |
| 23:47.00 | abhi2011 | hmm I understand most of it except the hit function |
| 23:47.22 | abhi2011 | seems its partitioning the 3d space around the point where the ray hit some geometry |
| 23:47.46 | abhi2011 | and calculating the outward pointing normal at that point on its surface....wild guess |
| 23:48.45 | ``Erik | yeah, rt_shootray() needs hit and miss callbacks set in the application structure and calls one of them depending on what happened |
| 23:49.00 | ``Erik | the hit function gets fed a boolean evaluated "partition list" |
| 23:49.28 | ``Erik | my hit() function there is solving normals and repacking the results into a different partition list format (for comparison) |
| 23:50.00 | ``Erik | if a_onehit is set, it'll only fill the first partition, useful for visual raytracing |
| 23:50.36 | abhi2011 | ok so these partitions represent cubiodal regions in 3d space ? |
| 23:51.29 | abhi2011 | i am thinking in terms of partitioning of the 3d space into 8 different regions around a point |
| 23:51.47 | abhi2011 | around the 3 axes |
| 23:52.06 | ``Erik | no, they're segments along the ray where it intersects geometry |
| 23:52.26 | abhi2011 | ah ok |
| 23:52.41 | abhi2011 | so some segments will be inside the geomtry and some outside |
| 23:53.06 | abhi2011 | which can be decided using the equation of a sphere for example if a sphere is the geometry |
| 23:53.28 | ``Erik | it does boolean evaluation before generating the partition list (using the boolweave() function in rt), so that's actual solid geometry in those partitions |
| 23:54.02 | abhi2011 | ok |
| 23:54.36 | ``Erik | if you have a 1 radius sphere at the origin and subtract an arb8 that's across an origin plane and shoot perpendicular to that plane, you'll see a partition that says "I hit a sphere from 1,0,0 to 0,0,0" |
| 23:54.47 | ``Erik | is that confusing enough? :D |
| 23:56.02 | abhi2011 | no I am getting it slowly :P, but I am familiar with all the short forms of the primitves yet, so arb8 is a rectangle or a plane ? |
| 23:56.19 | abhi2011 | *not familiar |
| 23:56.19 | ``Erik | arb8 is a box |
| 23:56.22 | abhi2011 | ok |
| 23:57.04 | abhi2011 | right i get it |
| 23:57.32 | abhi2011 | but wait we have subtracted an arb8 |
| 23:57.36 | ``Erik | http://brlcad.org/gallery/d/170-2/primitives.png |
| 23:57.48 | abhi2011 | so there is a hollow region inside the sphere |
| 23:57.56 | ``Erik | well, a sphere cut in half |
| 23:58.04 | abhi2011 | ah yes right |
| 23:58.42 | abhi2011 | ah cool thats handy |
| 00:00.03 | ``Erik | there's a program called "nirt", it's a console interface to individually fire rays at geometry with text output... maybe that'll be helpful playing with to understand what's in the C structures? |
| 00:00.21 | abhi2011 | ah thats for nirt is for |
| 00:00.32 | abhi2011 | right i ll do that |
| 00:00.49 | ``Erik | "natelies interactive ray tracer" |
| 00:01.10 | ``Erik | starseeker did a lot of work overhauling the documentation for it |
| 00:01.15 | abhi2011 | yes I remember reading that somewhere among the heap of docs :P |
| 00:01.26 | abhi2011 | cool |
| 00:09.32 | ``Erik | okie, I'm heading out, if you have questions, throw 'em out... if no one else answers them, I'll be back on tomorrow morning and try to respond to them all :) |
| 00:16.23 | *** join/#brlcad merzo (~merzo@118-62-132-95.pool.ukrtel.net) | |
| 00:21.44 | abhi2011 | right thanks Erik |
| 00:22.24 | abhi2011 | here is the program for getting the BB for geometry in a .g file using only librt : http://bin.cakephp.org/view/570066725 |
| 00:33.23 | *** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net) | |
| 01:15.46 | CIA-62 | BRL-CAD: 03kunigami * r45779 10/brlcad/trunk/src/rt/ (do.c ext.h opt.c view.c worker.c): added the random, unbuffered mode. it have a strange behaviour: the frame buffer is only painting pixels with x=0, even though I'm passing random values of x ranging from 0 to 511 |
| 01:56.47 | kunigami | In the lines of my commit's comment, I've made some tests with different values of w and h when calling RT. |
| 01:57.05 | kunigami | 512x512: http://dl.dropbox.com/u/1399996/GSoC/RT512x512.png |
| 01:57.22 | kunigami | 128x128: http://dl.dropbox.com/u/1399996/GSoC/RT128x128.png |
| 01:57.37 | kunigami | 300x300: http://dl.dropbox.com/u/1399996/GSoC/RT300x300.png |
| 01:57.49 | kunigami | 64x64: http://dl.dropbox.com/u/1399996/GSoC/RT64x64.png |
| 01:58.58 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177593653.dsl.bell.ca) | |
| 01:59.21 | kunigami | One note: the last rendering (64x64) was done in unbuffered mode(because the width is less than 96) |
| 02:01.42 | kunigami | Is this a bug or one is not supposed to use w,h less than 512 in fb mode? |
| 02:04.21 | kunigami | also, when I force rt to use unbuffered mode, it renders a black scene. (512x512) |
| 02:14.31 | CIA-62 | BRL-CAD: 03kunigami * r45780 10/brlcad/trunk/src/liboptical/sh_osl.cpp: removed (again) the loop in sh_osl since we are doing multi-samples before calling this shader |
| 06:28.14 | brlcad | kunigami: you're looking at several bugs there |
| 06:28.36 | brlcad | at least two of them related to x11 changes in the past 10 years |
| 06:29.04 | brlcad | first, I don't believe the black one is actually black, it's just not updating |
| 06:29.20 | brlcad | you might see an image if you minimize/restore .. something to cause a redraw |
| 06:30.03 | brlcad | the 128 version is supposed to be "zoomed" where pixels are auto-scaled 4x4 |
| 06:30.33 | brlcad | that used to work, but something has changed, causing it to only draw some subset of duplicated lines |
| 06:31.26 | brlcad | kunigami: one tool you might find useful since you're working in framebuffer land is 'fbserv' .. you can run a persistent framebuffer and send render results to it |
| 06:31.43 | brlcad | fbserv -S1024 0 /dev/ogl & |
| 06:31.50 | brlcad | rt -F0 file.g object |
| 06:33.00 | brlcad | especially for debugging, it helps sort out whether problems are on the sender/drawing side or on the receiving/framebuffer side |
| 06:33.24 | brlcad | abhi2011: nice work! |
| 06:33.43 | brlcad | keep that code around, you'll need it for your project |
| 08:01.20 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 13:30.36 | brlcad | yawns |
| 13:35.42 | abhi2011 | brlcad: is there any example which shows how to actually move geometry in mged |
| 13:37.15 | brlcad | undoubtedly |
| 13:37.31 | brlcad | the general idea is that you apply a transformation matrix |
| 13:37.31 | abhi2011 | :) |
| 13:37.36 | abhi2011 | yes right |
| 13:37.48 | abhi2011 | so some of the functions fromvmath.h |
| 13:41.26 | brlcad | those are general math macros |
| 13:41.38 | brlcad | maybe helpful, but they don't know about geometry |
| 13:49.01 | brlcad | there is a function table that responds to all entity types and performs operations on them |
| 13:49.18 | brlcad | applying a transformation matrix is the ft_xform() callback |
| 13:49.46 | brlcad | rt_matrix_transform() wraps that into a relatively simple API call |
| 13:50.10 | brlcad | see src/librt/transform.c |
| 13:52.50 | abhi2011 | right thanks, by the ft_xform() callback is called automatically in every rendering cycle like in glut ? |
| 13:58.10 | abhi2011 | ah ok there is a ft_xform for each type of primitive and the proper one is picked from the function pointers table and called using rt_functab[input->idb_type].ft_xform() |
| 14:01.36 | abhi2011 | reminds me of virtual functions in c++ |
| 14:03.19 | brlcad | that's almost exactly what it is, polymorphic behavior in c |
| 14:04.41 | brlcad | you might get a little lost in the logic, but you can see a transformation applied (eventually) in the inside command, src/mged/cmd.c in the cmd_ged_inside() function |
| 14:05.34 | brlcad | calls transform_editing_solid() which calls rt_matrix_transform() |
| 14:06.03 | brlcad | of course, those are all mged logic -- not useful to you other than as reference |
| 14:07.13 | brlcad | it is a good next step, though -- our moss.g sample geometry has a light source in it, try to move that lightsource down to the ground plate |
| 14:14.14 | abhi2011 | right |
| 14:21.02 | CIA-62 | BRL-CAD: 03erikgreenwald * r45781 10/brlcad/trunk/src/rt/do.c: remove unused variable |
| 14:21.32 | CIA-62 | BRL-CAD: 03erikgreenwald * r45782 10/brlcad/trunk/src/rt/view.c: remove unused variable. fix signed/unsigned issue |
| 16:53.33 | *** join/#brlcad Stattrav (~Stattrav@122.164.241.143) | |
| 16:53.33 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:55.30 | CIA-62 | BRL-CAD: 03starseeker * r45783 10/brlcad/trunk/src/other/tcl/ (4 files in 2 dirs): |
| 16:55.30 | CIA-62 | BRL-CAD: Start a clean-up of the Tcl cmake logic, backported from experiments in progress |
| 16:55.30 | CIA-62 | BRL-CAD: with building 8.6. This version of the logic allows XCode 4 to successfully |
| 16:55.30 | CIA-62 | BRL-CAD: build Tcl (not sure about older XCode versions). More work is needed to try a |
| 16:55.30 | CIA-62 | BRL-CAD: broader XCode build of BRL-CAD. |
| 17:17.21 | CIA-62 | BRL-CAD: 03bhinesley * r45784 10/brlcad/trunk/src/libged/edit.c: An argument duplication function was checking the (always empty) destination argument for an object before copying, when it should have been checking the source argument |
| 18:03.51 | bhinesley | is there a way to get the apparant coordinates of an object, as offset by matrices, without stepping through the tree and adding all of them up? |
| 18:07.16 | bhinesley | ex: if a shape is at 0,0,0, but it's inside a combination that is at 1,1,1, which is inside another combination drawn at 2,2,2; what's the best way to get "3,3,3" if I have a db_full_path "comb1/comb2/object" |
| 18:16.58 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 18:44.00 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 19:05.25 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177593653.dsl.bell.ca) | |
| 19:38.10 | *** join/#brlcad merzo (~merzo@9-227-132-95.pool.ukrtel.net) | |
| 19:49.43 | CIA-62 | BRL-CAD: 03starseeker * r45785 10/brlcad/trunk/src/other/tcl/CMakeLists.txt: Add M_LIBRARY to tcl, not just tclstub |
| 20:14.13 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177593653.dsl.bell.ca) | |
| 21:28.56 | CIA-62 | BRL-CAD: 03bhinesley * r45786 10/brlcad/trunk/src/libged/edit.c: |
| 21:28.56 | CIA-62 | BRL-CAD: Wrote body of edit_translate command (basically a stripped down version of the |
| 21:28.57 | CIA-62 | BRL-CAD: very first translate command I wrote). Removed all dead/obsolete code. A bit |
| 21:28.57 | CIA-62 | BRL-CAD: more work on path/object to coordinate conversion functions, but it's not usable |
| 21:28.57 | CIA-62 | BRL-CAD: yet, and still a WIP. |
| 22:16.55 | CIA-62 | BRL-CAD: 03starseeker * r45787 10/brlcad/trunk/src/other/tcl/CMakeLists.txt: Add M_LIBRARY for tclsh too |
| 22:35.04 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 22:36.43 | kunigami | brlcad: I think I didn't get how to use this framebuffer server. I have no /dev/ogl (maybe because I did not enabled it when installing brlcad?) and running without setting the framebuffer doesn't work |
| 22:56.07 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3042 10/wiki/User:Bhinesley: /* Log */ Logging last couple weeks |
| 23:15.33 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3043 10/wiki/User:Bhinesley: /* General plan */ was outdated |
| 23:16.27 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3044 10/wiki/User:Bhinesley: /* Development timeline (from proposal) */ rename |
| 23:18.53 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3045 10/wiki/User:Bhinesley: /* Who I am */ |
| 23:21.00 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3046 10/wiki/User:Bhinesley: /* Experience */ Not too shabby at Tcl/Tk/Itcl/Itk |
| 23:25.44 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3047 10/wiki/User:Bhinesley: /* GSoC 2011 Project */ |
| 23:26.29 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3048 10/wiki/User:Bhinesley: /* GSoC 2011 Project */ |
| 23:27.53 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 23:29.00 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3049 10/wiki/User:Bhinesley: /* Log */ grammar: A'int liking "got" none |
| 23:46.19 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 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) | |
| 00:25.57 | CIA-62 | BRL-CAD: 03brlcad * r45799 10/brlcad/trunk/src/librt/primitives/brep/ (brep_debug.cpp brep_debug.h): RED/GRN/BLU are defined by libbu, pick a different name for RED |
| 00:31.59 | CIA-62 | BRL-CAD: 03brlcad * r45800 10/brlcad/trunk/src/libwdb/skt.c: |
| 00:31.59 | CIA-62 | BRL-CAD: still need to do more, but make a copy of the caller's sketch (in case it's on |
| 00:31.59 | CIA-62 | BRL-CAD: the stack where the eventual call to bu_free() down in wdb_export() would be |
| 00:31.59 | CIA-62 | BRL-CAD: bad). this is incomplete since we still should perform a deep copy of the |
| 00:31.59 | CIA-62 | BRL-CAD: caller's struct (including all of the segments). |
| 00:32.55 | CIA-62 | BRL-CAD: 03brlcad * r45801 10/brlcad/trunk/TODO: autotools unbusted, just needed a version bump |
| 00:33.41 | CIA-62 | BRL-CAD: 03brlcad * r45802 10/brlcad/trunk/TODO: note to self, deep sketch copying still needed |
| 00:36.51 | CIA-62 | BRL-CAD: 03brlcad * r45803 10/brlcad/trunk/src/proc-db/csgbrep.cpp: even further reduction of about 70 lines. code went a wee bit nuts with dynamic memory allocation. simplify, put objects on the stack. |
| 00:43.27 | abhi2011 | brlcad : for testing object movement its best to write a mged plugin I guess. A stand alone program like the ones I wrote before do not have an opengl window anway |
| 00:46.45 | CIA-62 | BRL-CAD: 03bhinesley * r45804 10/brlcad/trunk/src/libged/list.c: return from function bypasses rt_db_free_internal() call |
| 01:51.44 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 02:22.01 | brlcad | abhi2011: yes, that's the idea .. a libged command similar to 'clone' (src/libged/clone.c), search for 'clone' in src/mged and src/libged |
| 02:22.08 | CIA-62 | BRL-CAD: 03bhinesley * r45805 10/brlcad/trunk/src/libged/edit.c: Functions for converting paths+objects+offsets to coordinates are written; need to be tested/debugged. Pretty close to being done with the command agnostic edit() stuff. |
| 02:51.48 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 02:57.29 | CIA-62 | BRL-CAD: 03bhinesley * r45806 10/brlcad/trunk/src/libged/edit.c: (log message trimmed) |
| 02:57.30 | CIA-62 | BRL-CAD: Reflowed all comments. Enable execution of subcommand functions in edit(), |
| 02:57.30 | CIA-62 | BRL-CAD: "subcmd->cmd->exec()". The translate command should be operational through |
| 02:57.30 | CIA-62 | BRL-CAD: ged_edit() once I resolve several issues with edit() and friends. The only |
| 02:57.30 | CIA-62 | BRL-CAD: exception that I can think of, is the use of the bounding box centers of |
| 02:57.30 | CIA-62 | BRL-CAD: objects; although everything in edit.c was designed with this in mind, the |
| 02:57.30 | CIA-62 | BRL-CAD: argument-to-coordinate functions currectly will only use natural origins. It's |
| 03:00.27 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3050 10/wiki/User:Bhinesley: /* Log */ today, and what's next |
| 08:09.15 | *** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 09:32.11 | *** join/#brlcad emagdalena (~splineman@129.Red-88-4-185.dynamicIP.rima-tde.net) | |
| 09:32.20 | *** join/#brlcad splineman (~splineman@129.Red-88-4-185.dynamicIP.rima-tde.net) | |
| 13:26.42 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 14:07.47 | *** join/#brlcad Elrohir (~kvirc@p5B14BCFE.dip.t-dialin.net) | |
| 14:43.34 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 16:33.49 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 17:45.41 | abhi2011 | here is the code so far for the new runphysics command which will move objects according to newtonian physics :P |
| 17:45.45 | abhi2011 | http://bin.cakephp.org/view/558121873 |
| 17:46.39 | abhi2011 | I have got it inside mged as a command, as of now I am trying to apply a simple translation to a passed object to see if I can move them around |
| 17:47.15 | abhi2011 | I am using transform_editing_solid() |
| 17:48.00 | abhi2011 | though the solid passed will not be the current solid being edited , but instead the struct rt_db_internal for the passed object |
| 18:24.46 | abhi2011 | ok I ll directly use rt_matrix_transform from librt |
| 19:20.36 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 20:56.12 | brlcad | mm, that looks not too shabby from abhijit |
| 20:57.45 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 22:36.03 | abhi2011 | ok so I am trying to translate an object using an mged command in preparation to do more physics based transformations |
| 22:36.08 | abhi2011 | here is the code : http://bin.cakephp.org/view/558121873 |
| 22:36.29 | abhi2011 | so I am trying to apply a simple translation to the passed object using rt_matrix_transform |
| 22:36.48 | abhi2011 | and the command runs without errors and prints a message afterwards |
| 22:37.00 | abhi2011 | so I am guessing the transformation matrix was applied |
| 22:37.52 | abhi2011 | but the thing is, the rt_matrix_transform() commands takes an input solid (struct rt_db_internal) and returns an output solid (again another rt_db_internal) |
| 22:38.05 | abhi2011 | this new solid should be at the new translated position |
| 22:38.21 | abhi2011 | but I am not able to figure out how to verify this |
| 22:39.00 | abhi2011 | this new solid is apparently not inserted automatically into the model tree as I cant see it using the list command in mged |
| 22:39.22 | abhi2011 | I tried rt_db_put_internal(ndp, gedp->ged_wdbp->dbip, &os, 0); but it runs into pointer erros |
| 22:44.00 | abhi2011 | so basically I need to insert the output solid returned by rt_matrix_transform() into the model tree or at the least print its position so I can see if its at the translated position |
| 22:46.26 | ``Erik | combinations hold matrices, primitives do not... the 'xpush' command walks down the tree propogating the matrix and finally modifying the primitive, so all matrices in the path should be identity... is that what you're looking for? |
| 22:46.33 | abhi2011 | I cant do if ((ndp = db_lookup(gedp->ged_wdbp->dbip, os, LOOKUP_NOISY)) == RT_DIR_NULL){ either as I need the name of the output solid |
| 22:47.33 | abhi2011 | Erik : ah ok so I can try to apply the transform on a combination |
| 22:47.58 | abhi2011 | but if I use rt_matrix_transform() for that |
| 22:48.26 | abhi2011 | then the paramters of rt_matrix_transform() show that there is an input and an output struct rt_db_internal |
| 22:48.40 | abhi2011 | struct rt_db_internal is what will hold information about the combination I guess |
| 22:49.08 | ``Erik | hm, looking at the source, rt_matrix_transform is just the last step to actually try to mutate the primitive :/ |
| 22:49.10 | abhi2011 | so rt_matrix_transform() does not transform the input directly |
| 22:49.19 | abhi2011 | ah ok |
| 22:49.32 | abhi2011 | all I need is to move a primitive or a combination |
| 22:49.53 | abhi2011 | using a translation matrix as of now |
| 22:50.04 | ``Erik | src/mged/edsol.c is where that function is called |
| 22:50.12 | abhi2011 | yes |
| 22:51.19 | ``Erik | has a party to head off to, perhaps brlcad will peruse the backlog later and provide more insight |
| 22:53.05 | abhi2011 | have a great time :) |
| 23:18.38 | kunigami | anyone able to compile the latest revision? I'm getting linking errors from libtk |
| 23:26.33 | starseeker | kunigami: what errors? |
| 23:27.42 | starseeker | trunk builds for me on gentoo... |
| 23:30.36 | kunigami | starseeker: http://paste.ubuntu.com/660137/ |
| 23:32.00 | kunigami | weird. I tried a clean install and the problem persists |
| 23:45.22 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3051 10/wiki/User:Abhijit: /* Development timeline */ |
| 00:17.33 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 02:48.53 | starseeker | kunigami: is it building tcl? |
| 02:49.17 | starseeker | if that's a CMake build, can you post again with make VERBOSE=1 ? |
| 02:50.20 | kunigami | starseeker: right, I'll do that in a minute. I went back to r45780 and it seems fine (r5797 gives a compile error too) |
| 02:50.45 | starseeker | kunigami: it's very probably the tweaks I made to the tcl/tk build system |
| 02:51.07 | starseeker | kunigami: you're on a mac? which version of OSX? |
| 02:51.39 | kunigami | I'm on on mac 10.6 |
| 02:51.44 | starseeker | huh |
| 02:52.00 | starseeker | what's your cmake configure line? |
| 02:52.18 | kunigami | starseeker: cmake ../brlcad -DBRLCAD-ENABLE_OPENGL=OFF -DBRLCAD-ENABLE_COMPILER_WARNINGS=OFF -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON -DBRLCAD-ENABLE_OSL=ON -DCMAKE_INSTALL_PREFIX=/Users/kunigami/dev/brlcad-bin/ -DBRLCAD-ENABLE_STRICT=OFF |
| 02:53.42 | starseeker | huh. yeah, if you can post the whole thing (that plus make VERBOSE=1 ) that should help |
| 02:54.47 | kunigami | here it is: http://paste.ubuntu.com/660214/ |
| 02:59.24 | starseeker | kunigami: um. can you try it again from a clean build directory? |
| 02:59.50 | starseeker | eg cmake <options> && make VERBOSE=1 |
| 03:00.02 | kunigami | oh, sure! |
| 03:04.49 | starseeker | gah, wait a sec... |
| 03:05.58 | CIA-62 | BRL-CAD: 03starseeker * r45807 10/brlcad/trunk/src/other/tk/CMakeLists.txt: Whoops. Helps to spell things correctly. |
| 03:06.21 | starseeker | kunigami: see if that fixes things |
| 03:14.40 | kunigami | starseeker: seems it did! thank you! |
| 04:03.30 | starseeker | O.o http://nova-docdb.fnal.gov/cgi-bin/ShowDocument?docid=6090 |
| 04:09.54 | starseeker | hmm - can at least partially import this but it raytraces funny http://acquisition.jpl.nasa.gov/rfp/JC-2663-595218/GantryCADfile(STPformat).stp |
| 04:58.12 | *** join/#brlcad kunigami1 (~kunigami@loco-gw.ic.unicamp.br) | |
| 08:50.49 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3052 10/wiki/User:Abhijit: /* Logs */ |
| 08:56.05 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3053 10/wiki/User:Abhijit: /* Log */ |
| 12:15.45 | abhi2011 | brlcad : I have written the runphysics command to translate an input object using the rt_matrix_transform() function : http://bin.cakephp.org/view/1932154726 |
| 12:17.31 | abhi2011 | A new combination which is a copy of the input, is created at the translated position (later I will make it work on the input combination itself) |
| 12:19.13 | abhi2011 | I added the new translated combination to the db tree, but it seems to not respond to draw commands, this is the error I get in Mged : http://bin.cakephp.org/view/1614988156 |
| 13:15.10 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 13:48.44 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:15.05 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 14:46.43 | brlcad | abhi2011: looking good ... does it work? |
| 14:49.12 | brlcad | one change I'd like to request .. "runphysics" sounds too quirky, too ambiguous |
| 14:49.12 | abhi2011 | umm no brlcad :( |
| 14:49.19 | brlcad | almost like "do science" |
| 14:49.24 | abhi2011 | haha :) |
| 14:49.38 | abhi2011 | "simulate" |
| 14:49.42 | ``Erik | "teh winz: |
| 14:50.01 | brlcad | that's exactly what I was going to suggest, "simulate" is better and extends to other operations in the future |
| 14:50.11 | abhi2011 | right |
| 14:50.18 | abhi2011 | so regarding the code |
| 14:50.43 | abhi2011 | its seems that rt_matrix_transform() takes an input combination and returns an output combination |
| 14:50.59 | brlcad | okay |
| 14:51.00 | abhi2011 | but what would be better is to directly act on the input |
| 14:51.03 | ``Erik | sips his irish coffee in celebration of a successful oil change and tire rotation (next time, imma just pay someone to do it) |
| 14:51.16 | abhi2011 | change its attributes so it gets drawn in the new position |
| 14:51.49 | brlcad | abhi2011: are you saying that the output combination is not the same as the input combination? |
| 14:51.58 | ``Erik | thought rt_matrix_transform() just called the f_xform() field for the primitive, it did NOT operate at the comb level... but I may misrecall |
| 14:52.17 | abhi2011 | brlcad : well I think so |
| 14:52.39 | abhi2011 | because when I add it to the db then it shows an error |
| 14:52.59 | abhi2011 | http://bin.cakephp.org/view/1614988156 |
| 14:53.24 | brlcad | ``Erik: it calls into the object functab |
| 14:53.29 | abhi2011 | I call the output combination as translated_solid |
| 14:53.32 | brlcad | (combs are registered as objects) |
| 14:53.39 | ``Erik | ah, did not know that |
| 14:53.49 | ``Erik | do combs recursively pass the xform? |
| 14:54.10 | ``Erik | xpush style? |
| 14:54.35 | brlcad | I don't recall, but I don't think so |
| 14:54.54 | brlcad | just calls the generic transform |
| 14:55.10 | ``Erik | sets the comb matrix and returns, ok |
| 14:55.19 | ``Erik | might be a pertinent detail to abhi's stuff |
| 14:55.25 | brlcad | which does an import with a matrix applied |
| 14:55.59 | brlcad | abhi2011: what is translated_solid? |
| 14:56.03 | brlcad | "l translated solid" |
| 14:56.11 | brlcad | er, "l translated_solid" |
| 14:56.23 | abhi2011 | its the output of rt_matrix_transform() |
| 14:56.36 | brlcad | no |
| 14:56.38 | abhi2011 | i add the output of rt_matrix_transform() to the database |
| 14:56.40 | brlcad | run that command in mged |
| 14:57.15 | abhi2011 | yes the command adds it to the database |
| 14:57.24 | brlcad | *sigh* |
| 14:57.25 | brlcad | no |
| 14:57.33 | brlcad | run ... "l translated_solid" ... in mged |
| 14:57.39 | abhi2011 | oh ok |
| 14:58.04 | ``Erik | most mged commands are simple wrappers to the C library |
| 14:58.35 | ``Erik | so "what does this mean" can be easily experimented with by doing mged cmds |
| 15:00.19 | brlcad | from that pastebin listing, it looks like translated_solid is wrong -- it's not recognized as a comb yet giving a subtree failure |
| 15:00.57 | abhi2011 | ya seems that way |
| 15:00.59 | abhi2011 | http://bin.cakephp.org/view/1112923952 |
| 15:01.02 | brlcad | I wouldn't worry about making a copy just yet -- try updating the original object |
| 15:01.36 | brlcad | interesting |
| 15:01.37 | abhi2011 | ok , then rt_matrix_transform() output should be copied into the original object |
| 15:01.55 | brlcad | rt_matrix_transform applied the change to the original object |
| 15:01.59 | brlcad | you just have to write it out to disk |
| 15:02.16 | brlcad | look at the other places where rt_matrix_transform() is called, see what else they're doing |
| 15:02.39 | abhi2011 | yes |
| 15:03.02 | abhi2011 | the translate and rotate commands apply vector math to do their thing |
| 15:03.40 | abhi2011 | I was looking at chgmodel.c for how these commands work |
| 15:04.22 | brlcad | I believe you just feed rt_matrix_transform() the same rt_db_internal pointer for both input and output |
| 15:05.11 | brlcad | then it'll either be written to disk, or you'll call an export function (e.g., rt_db_put_internal()) to write it |
| 15:05.26 | abhi2011 | oh its that simple....:P |
| 15:05.46 | brlcad | it's something close to that simple |
| 15:07.15 | abhi2011 | yes after getting the output from rt_matrix_transform() , I call db_diradd() to get the directory pointer and then rt_db_put_internal() to put the internal format of the combination to the disk |
| 15:08.33 | ``Erik | brlcad: I think I have the new machine cleaned up and about ready to look at migration again, the hiccup with the weird dep thrashing everything is fixed |
| 15:09.44 | ``Erik | (if not zomfg migration, I'd appreciate the crit. name being moved so'z I don't have to remember #'s :D ) |
| 15:14.04 | brlcad | nods |
| 15:19.34 | abhi2011 | YES!!!! :) |
| 15:19.40 | abhi2011 | just moved it |
| 15:19.52 | abhi2011 | brlcad: thanks ! |
| 15:21.13 | abhi2011 | here is the modified code , have to clean up though : http://bin.cakephp.org/view/1932154726 |
| 15:36.50 | *** join/#brlcad splineman (~splineman@155.Red-88-21-190.staticIP.rima-tde.net) | |
| 15:36.56 | *** join/#brlcad emagdalenag (~splineman@155.Red-88-21-190.staticIP.rima-tde.net) | |
| 15:38.35 | *** join/#brlcad splineman (~splineman@155.Red-88-21-190.staticIP.rima-tde.net) | |
| 15:38.57 | *** join/#brlcad emagdalena (~emagdalen@155.Red-88-21-190.staticIP.rima-tde.net) | |
| 15:53.26 | abhi2011 | I am trying to do arbitrary rotations now for the simulate command |
| 16:08.26 | *** join/#brlcad emagdalenag (~emagdalen@3.Red-83-56-124.dynamicIP.rima-tde.net) | |
| 17:13.41 | brlcad | excellent |
| 18:24.04 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 18:32.00 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3054 10/wiki/User:Abhijit: /* Log */ |
| 18:54.23 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3055 10/wiki/User:Abhijit: /* Log */ |
| 20:46.54 | abhi2011 | ok I get a strange behavior when I link the simulate command with a command wrapper |
| 20:47.28 | abhi2011 | so I have modified cmd.c to include a new command wrapper for the new mged command "simulate" |
| 20:48.05 | abhi2011 | cmd.c now has the implementation for cmd_ged_simulate_wrapper(ClientData clientData, Tcl_Interp *interpreter, int argc, const char *argv[]) |
| 20:48.18 | abhi2011 | its very similar to the cmd_ged_edit_wrapper() |
| 20:49.11 | abhi2011 | http://bin.cakephp.org/view/1859715979 |
| 20:49.48 | abhi2011 | in the command wrapper I call the libged function which actually implements the simulate function : ged_simulate(struct ged *gedp, int argc, const char *argv[]) |
| 20:50.24 | abhi2011 | i call ged_simulate() 100 times from the command wrapper with an artificial delay inserted of 1/10th of a second |
| 20:51.51 | abhi2011 | ged_simulate() is called inside a for loop and I draw the object at the new position as well at the end of each iteration, so it should appear to move every 1/10th of a second in mged |
| 20:52.36 | abhi2011 | but the object is moved only at the end of all the iterations when the command wrapper returns |
| 20:53.10 | abhi2011 | I would have expected mged to draw the object immediately after the cmd_draw() is called to draw the object |
| 20:58.41 | abhi2011 | so the way the simulate command should work is , the user gives the number of steps to simulate as : simulate 10 |
| 20:59.17 | abhi2011 | and then the physics takes over and simulates with the command wrapper for simulate called the libged simulate implementation 10 times |
| 21:00.14 | abhi2011 | but after each call to the libged simulate function ged_simulate(), the position of the dynamic object should be redrawn in mged and not after all the iterations are complete |
| 21:00.14 | ``Erik | command sounds about right, I believe there is a "flush" type command that has to be passed to force display |
| 21:00.25 | abhi2011 | aoh |
| 21:00.35 | abhi2011 | right i ll check it |
| 21:31.23 | abhi2011 | there is a update_views = 1; probably that one |
| 21:54.48 | ``Erik | I tend to avoid gui code, but that sounds familiar. I think there was maybe discussion about an explicit "block until" flush cmd? I'm not sure :/ |
| 21:55.17 | ``Erik | (the discussion being about if we should implement one, or if the variable is adequate) |
| 22:09.59 | abhi2011 | any way to grep the irc logs :P |
| 22:16.34 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 22:18.02 | louipc | abhi2011: the one's stored on your computer? |
| 22:21.59 | abhi2011 | no the logs for the last few months |
| 22:22.46 | abhi2011 | louipc: maybe I can find the discussion regarding the 'block until' flush command that Erik was speaking about |
| 22:28.36 | abhi2011 | basically if a command is taking too long to process, there must be a way to send updates to the user as it progresses |
| 22:58.53 | louipc | abhi2011: you can try using google to search maybe |
| 22:59.44 | louipc | abhi2011: search "site:http://ibot.rikers.org/%23brlcad/ abhi2011" for example |
| 23:20.18 | abhi2011 | louipc: ah yes that works quite well |
| 23:20.34 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 23:37.04 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 00:49.06 | abhi2011 | ok so I am trying to add a new .cpp file to src/libged where all the c++ code to access bullet physics will go |
| 00:49.40 | abhi2011 | the cpp file has a header which I include in the mged command implementation file |
| 00:50.43 | abhi2011 | So my c++ test file is simphysics.cpp with some test code |
| 00:51.45 | abhi2011 | http://bin.cakephp.org/view/1739302378 |
| 00:53.23 | abhi2011 | I have a header for it and this is included in simulate.c which has the libged implementation of the simulate command : http://bin.cakephp.org/view/1706385166 |
| 00:54.24 | abhi2011 | the cpp file has the definition of a single function single_step_sim() which uses the cout object to print out some test message |
| 00:55.19 | abhi2011 | I get a linking error when I compile which says single_step_sim() is an undefined reference |
| 00:56.39 | abhi2011 | However since I have included the header (which declares single_step_sim() ) in simulate.c the compiler should be able to see the declaration |
| 00:57.14 | abhi2011 | Perhaps it has to be exported using GED_EXPORT, but its not called from outside the library so it shouldnt be required to export it |
| 01:06.51 | abhi2011 | this is the linking error : http://bin.cakephp.org/view/1997617995 |
| 05:15.44 | *** join/#brlcad Stattrav (~Stattrav@203.196.190.162) | |
| 05:15.44 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 06:04.43 | *** join/#brlcad emagdalenag (~emagdalen@109.Red-88-4-184.dynamicIP.rima-tde.net) | |
| 10:23.01 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 11:32.54 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r3056 10/wiki/User:Kunigami/GSoc2011/Reports: /* Week 11 (August 1st to August 8th) */ log for past week |
| 12:30.41 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 12:36.39 | abhi2011 | has anyone tried to add c++ files to existing code, that is mixing c with c++ |
| 12:38.07 | brlcad | abhi2011: adding c++ to c files would make them c++ files |
| 12:40.40 | brlcad | you'll want to write a bridge, i.e., one or more C functions that wrap all of your C++ logic |
| 12:40.42 | abhi2011 | ok I am trying to integrate bullet c++ code into brlcad |
| 12:40.48 | brlcad | I know |
| 12:40.49 | abhi2011 | right |
| 12:41.08 | brlcad | those bridging functions will need to be marked extern "C" since they're in c++ files |
| 12:41.16 | brlcad | so that they're not name-mangled |
| 12:42.52 | abhi2011 | yes I have written a separate function in a cpp file simphysics.cpp that has all the c++ code, I have declared this function in a header simphysics.h |
| 12:42.54 | *** join/#brlcad emagdalenag (~emagdalen@179.Red-88-4-185.dynamicIP.rima-tde.net) | |
| 12:43.10 | abhi2011 | i include this header in simulate.c which is the libged simulate command implementation |
| 12:43.41 | abhi2011 | in the header where i declare the c++ function, I can declare it as extern |
| 12:43.55 | brlcad | it's not just extern |
| 12:43.58 | brlcad | it's extern "C" |
| 12:44.05 | abhi2011 | ah ok |
| 12:44.20 | brlcad | search for that in existing include/*.h headers |
| 12:44.21 | abhi2011 | i get it |
| 12:44.27 | abhi2011 | right |
| 12:44.39 | brlcad | stop saying right :) |
| 12:45.05 | abhi2011 | :P, yes |
| 12:51.46 | brlcad | heh, http://www.sbir.gov/sbirsearch/detail/93829 |
| 12:52.06 | brlcad | apparently ARA got half a million back in the mid-90's to develop that .. interesting, never saw it |
| 12:52.35 | brlcad | (assuming they got phase 2 funding, maybe only phase 1) |
| 13:40.55 | abhi2011 | interestng |
| 14:19.10 | *** join/#brlcad emagdalenag (~emagdalen@41.Red-88-21-190.staticIP.rima-tde.net) | |
| 14:52.47 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-187-155.wlan.tudelft.nl) | |
| 15:25.29 | CIA-62 | BRL-CAD: 03brlcad * r45808 10/brlcad/trunk/src/libwdb/skt.c: there already exists a copy function for deep copying, so use it. |
| 15:27.33 | CIA-62 | BRL-CAD: 03brlcad * r45809 10/brlcad/trunk/src/libwdb/ (CMakeLists.txt Makefile.am sketch.c skt.c): rename from skt.c to sketch.c because it's easier to find the file if the filename matches the primitive's canonical short name. |
| 15:35.56 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 15:49.05 | *** join/#brlcad fosburg (~steve@or-67-238-17-118.dhcp.embarqhsd.net) | |
| 15:49.59 | fosburg | anyone here |
| 16:04.54 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 16:07.57 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 16:11.46 | *** join/#brlcad fosburg (~steve@or-67-238-17-118.dhcp.embarqhsd.net) | |
| 16:16.06 | kunigami | rt is running out of single letter options :) shouldn't we allow more for more mnemonic options? |
| 16:16.46 | kunigami | I'd like to add a framebuffer mode. Bothb,B, f and F are already taken, but -fb would be better anyway |
| 16:23.47 | brlcad | kunigami: we don't (yet) have proper infrastructure in place for --long-options |
| 16:25.02 | brlcad | with getopt, -fb is equivalent to "-f -b", so at best you'd need something like --fb |
| 16:25.12 | brlcad | that said, what do you mean by framebuffer mode? |
| 16:27.20 | CIA-62 | BRL-CAD: 03brlcad * r45810 10/brlcad/trunk/include/wdb.h: meant to commit this with r45808, made the passed parameter const now that it's properly copied before export. |
| 16:28.36 | CIA-62 | BRL-CAD: 03brlcad * r45811 10/brlcad/trunk/include/raytrace.h: add a new type, rt_curve, for use by sketch and extrude definitions. |
| 16:38.40 | abhi2011 | does anyone else get warnings about the version infomation being missing from libz : /usr/bin/cmake: /usr/brlcad/dev-7.20.3/lib/libz.so.1: no version information available (required by /usr/bin/cmake) |
| 16:38.58 | abhi2011 | I get this during cmake and during make install as well |
| 16:39.38 | abhi2011 | maybe the libz version info needs to be patched |
| 17:03.11 | *** join/#brlcad fosburg (~steve@or-67-238-17-118.dhcp.embarqhsd.net) | |
| 17:05.32 | kunigami | brlcad: something like we discussed on email: the frequency on which the framebuffer is updated and how rays are shot. this would form two options. I want to add an option for the "how rays are shot". fb was just an example for a long letter example. Which name would better describe this parameter? tr? |
| 17:08.05 | brlcad | that rabbit hole runs a little deep :) |
| 17:09.25 | brlcad | my point wasn't specific to -fb, -abc == -a -b -c to getopt (which is highly desireable in some contexts) |
| 17:09.42 | brlcad | the feature missing is long-opts support, which would let you specify longer name options in addition to one-letter optiosn |
| 17:10.15 | brlcad | half of rt's short options would be better as long-only options for some form of advanced control |
| 17:11.38 | brlcad | but like I said, the infrastructure for long options isn't implemented, so better to just pick one of the few remaining one-letter options for now unless you want to tackle implementing long options properly (new libbu api) |
| 17:12.12 | kunigami | hehe ok. Will choose one of the remaining :) |
| 17:12.19 | brlcad | :) |
| 17:13.01 | brlcad | looks like -m -y -z -L -Y -Z plus some punctuation are all that remain |
| 17:15.39 | brlcad | given -l is lighting model, -L for firing pattern might work well |
| 17:18.36 | brlcad | another option might be to overload the -Q option or -B option |
| 17:18.51 | brlcad | looks like -b might be fair game too.. |
| 17:22.08 | brlcad | definitely fair game, it's the same as -j |
| 17:22.54 | brlcad | so I suggest -L, -Q, or -b |
| 17:23.40 | brlcad | the latter two require a little refactoring, but seem most appropriate |
| 17:25.43 | brlcad | kunigami: suggest writing up the proposed usage change like what bhinesley did for edit, either as a comment or wiki dev page would be sufficient |
| 17:26.05 | brlcad | to make sure the usage is clean and impact minimal before you run down a path |
| 17:27.14 | brlcad | rt is a critical path, so should make sure there's extra thought put into how the new options will get used |
| 17:33.31 | CIA-62 | BRL-CAD: 03brlcad * r45812 10/brlcad/trunk/src/libwdb/ (CMakeLists.txt Makefile.am extr.c extrude.c): rename extr.c to extrude.c so that the filename matches the primitiv'es canonical short name. makes it easier to identify what this file contains. |
| 17:35.33 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 17:44.47 | kunigami | brlcad: comment right on the code? like rt/main.c or rt/opt.c? |
| 17:45.40 | brlcad | anywhere, just some place we can collectively see it |
| 17:45.52 | kunigami | ok! |
| 17:58.49 | *** join/#brlcad fosburg (~steve@or-67-238-17-118.dhcp.embarqhsd.net) | |
| 18:12.14 | brlcad | excellent |
| 18:12.35 | brlcad | couple usage examples would be helpful too in addition to more formalized usage syntax |
| 18:23.00 | CIA-62 | BRL-CAD: 03brlcad * r45813 10/brlcad/trunk/src/tclscripts/menu_override.tcl: |
| 18:23.00 | CIA-62 | BRL-CAD: example of why it's useful to see the tclsh warnings.. remove a handful of |
| 18:23.00 | CIA-62 | BRL-CAD: ::tk:: functions that curiously are living in our sources, yet they don't appear |
| 18:23.00 | CIA-62 | BRL-CAD: to have any overridden behavior. menus in mged tested fine without, so let the |
| 18:23.01 | CIA-62 | BRL-CAD: tk guys manage their own code. remove our fork. |
| 18:25.58 | ``Erik | starseeker: tclUnixInit.c:367 or so, #include <sys/utsname.h> for uname(3) on line 471 or so |
| 18:26.22 | CIA-62 | BRL-CAD: 03brlcad * r45814 10/brlcad/trunk/misc/Doxyfile: output to 'doxygen_output' in whatever our current directory is, no point putting it into misc |
| 18:28.06 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r3057 10/wiki/User:Kunigami/GSoc2011/RT_Parameters_Proposal: draft to present the new options to be added RT application. Waiting for review before implementing |
| 18:28.28 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r3058 10/wiki/User:Kunigami/GSoc2011/RT_Parameters_Proposal: /* Examples */ correct formatting |
| 18:29.28 | *** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ) | |
| 18:29.38 | kunigami | may I already add osl and oiio code to the svn? |
| 18:30.03 | tofu | how big are they? |
| 18:30.48 | *** mode/#brlcad [+o brlcad] by ChanServ | |
| 18:31.01 | kunigami | osl is 5MB |
| 18:31.24 | kunigami | oiio is 9.4MB |
| 18:31.50 | kunigami | or we'll let them be optional external code? |
| 18:31.56 | brlcad | do they have any dependencies of their own? |
| 18:32.09 | brlcad | it depends just how complex they are |
| 18:32.20 | kunigami | yes, a quite long one by the way |
| 18:33.35 | brlcad | do you have the build documented somewhere? |
| 18:33.48 | kunigami | http://brlcad.org/wiki/User:Kunigami/GSoc2011/OSL_Tutorial |
| 18:33.59 | brlcad | excellent, thought you had |
| 18:34.58 | starseeker | as i recall, OSL has quite the nasty dependency list |
| 18:35.02 | kunigami | but I didn't mentioned all the dependencies. Most of them are aviable like in mac ports or ubuntu synaptic |
| 18:35.08 | starseeker | llvm |
| 18:35.10 | kunigami | starseeker: yup |
| 18:36.24 | brlcad | ah, right, llvm .. that's certainly a pickle |
| 18:37.14 | brlcad | pretty much guarantees it'll be disabled on release configurations unless we do some heavy lifting to make it easier |
| 18:37.16 | starseeker | boost, imath, openimageio |
| 18:38.25 | starseeker | (imath looks like it may be part of openexr) |
| 18:38.45 | kunigami | yes, I had to install openexr |
| 18:38.53 | brlcad | kunigami: how about checking all of the deps into a separate module |
| 18:39.24 | starseeker | not surpring, openexr really has taken off in the movie industry and that's sony's target use case for this... |
| 18:39.31 | brlcad | we can hook those in later as an svn external if we want, or extra download step |
| 18:39.41 | starseeker | votes for that appraoch |
| 18:39.41 | brlcad | but that way, the N deps are all in one place |
| 18:39.43 | starseeker | approach even |
| 18:40.51 | brlcad | then their compilation can be wrapped up with even a simple Makefile that will compile/install all in the proper order |
| 18:41.01 | brlcad | <PROTECTED> |
| 18:41.17 | brlcad | kunigami: do you know how to create a new module? |
| 18:41.18 | starseeker | osl itself uses cmake |
| 18:41.29 | kunigami | kunigami: nope |
| 18:41.34 | kunigami | ops |
| 18:41.37 | kunigami | brlcad: nope |
| 18:41.38 | brlcad | sure, but it's just one of about a half-dozen or so |
| 18:42.08 | starseeker | openimagio has one, it looks like |
| 18:42.13 | starseeker | pretty sure llvm does |
| 18:42.39 | kunigami | you mean cmake module? like FindXYZ.cmake? |
| 18:43.00 | starseeker | no, CMakeLists.txt file |
| 18:43.08 | brlcad | kunigami: basically, you'll checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad (perhaps with max-depth set to 0 so it doesn't check out the whole repo) and add an 'osl' dir with three subdirs, 'trunk', 'branches', 'tags' |
| 18:43.56 | brlcad | then add the various OSL packages as subdirs under /svnroot/brlcad/osl/trunk/. |
| 18:44.30 | brlcad | one dir for each dep, openexr, llmbase, boost, etc |
| 18:44.52 | brlcad | can skip any external deps that are in /svnroot/brlcad/brlcad/trunk/src/other (like libpng, libz, etc) |
| 18:45.43 | starseeker | hmm... openexr doesn't have one |
| 18:45.52 | starseeker | wonder if they'd accept one |
| 18:46.16 | brlcad | unless we plan on fully managing them, wouldn't bother |
| 18:46.55 | brlcad | only reason to add them is to have them in revision control so they can be conveniently downloaded if we want to push out binaries with osl enabled |
| 18:47.57 | brlcad | exr-pix would be cool, that'd be a reason :) |
| 18:49.10 | starseeker | isn't quite sure how exr would integrate with our tools - we might have to make rt and friends output straight to exr if we wanted to take full advantage of it... |
| 19:03.39 | CIA-62 | BRL-CAD: 03kunigami * r45815 10/osl/ (. branches/ tags/ trunk/): setting up initial structure for osl code and dependences |
| 19:06.27 | *** join/#brlcad fosburg (~steve@or-67-238-17-118.dhcp.embarqhsd.net) | |
| 19:12.31 | CIA-62 | BRL-CAD: 03starseeker * r45816 10/brlcad/trunk/src/other/tcl/CMakeLists.txt: Add one missing file to Windows source list - this new setup, for the first time, allows for a successful run of wish.exe |
| 19:22.44 | *** join/#brlcad emagdalena (~emagdalen@216.Red-88-4-184.dynamicIP.rima-tde.net) | |
| 19:38.33 | CIA-62 | BRL-CAD: 03brlcad * r45817 10/brlcad/trunk/misc/ (CMakeLists.txt Makefile.am): the Doxygen paths are already relative, so no need to auto-generate the file with full-paths shoved in. write out to the doc dir. |
| 19:56.07 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r3059 10/wiki/User:Kunigami: /* Links */ added link to my RT parameters proposal |
| 20:01.04 | *** join/#brlcad dli (~dli@dsl-67-204-17-156.acanac.net) | |
| 20:03.49 | CIA-62 | BRL-CAD: 03brlcad * r45818 10/brlcad/trunk/ (16 files in 10 dirs): |
| 20:03.50 | CIA-62 | BRL-CAD: fix a FIXME, rename the struct curve definition that was embedded into |
| 20:03.50 | CIA-62 | BRL-CAD: rt_sketch_internal. this creates a new rt_curve structure and moves the |
| 20:03.50 | CIA-62 | BRL-CAD: associated segment structures into rtgeom. unfortunately requires nmg.h for the |
| 20:03.50 | CIA-62 | BRL-CAD: knot_vector and cascades a set of name changes, but improvement all around. |
| 20:17.54 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 20:32.24 | CIA-62 | BRL-CAD: 03kunigami * r45819 10/osl/trunk/osl/: add just the empty dir for mime-type testing |
| 20:35.00 | CIA-62 | BRL-CAD: 03kunigami * r45820 10/osl/trunk/osl/CHANGES: add just the empty dir for mime-type testing |
| 21:54.45 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 21:54.46 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 22:05.20 | CIA-62 | BRL-CAD: 03brlcad * r45827 10/brlcad/trunk/ (include/raytrace.h src/librt/primitives/sketch/sketch.c): segment magic numbers are presently unsigned long, update pointers accordingly |
| 22:15.48 | CIA-62 | BRL-CAD: 03brlcad * r45828 10/brlcad/trunk/src/proc-db/sketch.c: now that mk_sketch() releases memory, we can simplify by creating the sketch and all segments on the stack. |
| 22:19.13 | CIA-62 | BRL-CAD: 03kunigami * r45829 10/osl/trunk/oiio/ (399 files in 82 dirs): adding missing files to oiio |
| 22:21.18 | CIA-62 | BRL-CAD: 03brlcad * r45830 10/brlcad/trunk/src/proc-db/sketch.c: come to think of it, we don't need ANY stinking dynamic memory allocation. huzzah. |
| 22:25.58 | CIA-62 | BRL-CAD: 03brlcad * r45831 10/brlcad/trunk/src/proc-db/sketch.c: reduce some more and document the vars |
| 23:38.46 | CIA-62 | BRL-CAD: 03kunigami * r45832 10/osl/trunk/ilmbase/ (245 files in 69 dirs): adding latest stable version of ilmbase, 1.0.1 |
| 23:46.50 | CIA-62 | BRL-CAD: 03kunigami * r45833 10/osl/trunk/ilmbase/config/Makefile.in: added missing file to ilmbase |
| 23:51.29 | CIA-62 | BRL-CAD: 03kunigami * r45834 10/osl/trunk/ilmbase/ (7 files in 7 dirs): added missing file to ilmbase (cant understand why some files are not being added) |
| 00:04.54 | brlcad | kunigami: it's because some files are listed in your ~/.subversion/config global-ignores directive, files that are "usually" auto-generated |
| 00:05.25 | brlcad | Makefile.in files being a byproduct of automake, though some projects choose to be autoconf-only and use Makefile.in |
| 00:05.53 | brlcad | remove the directive and should resolve itself |
| 00:06.34 | kunigami | that's strange, my global-ignores only includes .o, .lo and .la |
| 00:27.45 | starseeker | brlcad: we've got something odd going on with bu_ipwd |
| 00:27.58 | starseeker | I'm trying to run archer from build directory, and it's not finding the plugins |
| 00:28.31 | starseeker | the problem traces to how plugins are loaded - the current working directory is changed to being fairly deep in the share structure |
| 00:28.43 | starseeker | when there, bu_brlcad_data no longer gives useful results |
| 00:29.38 | starseeker | brlcad: try running bwish from share/brlcad/7.20.3/plugins/archer/Utility |
| 00:30.05 | starseeker | e.g ../../../../../../bin/bwish |
| 00:30.11 | starseeker | then try bu_brlcad_data "" |
| 00:32.30 | dli | starseeker, is there any known issue with building brlcad against libpng-1.5? |
| 00:36.19 | starseeker | dli: trunk can (we actually just upgraded to 1.5) |
| 00:36.44 | dli | starseeker, thanks a lot! just got a bug report from gentoo |
| 00:41.29 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 00:49.44 | CIA-62 | BRL-CAD: 03kunigami * r45835 10/osl/trunk/openexr/ (396 files in 67 dirs): adding latest version of openexr (v1.6.1) |
| 01:38.53 | kunigami | openexr requires zlib, which is packed with brlcad. but openexr uses autotools to build. should I modify it to automatically find the brlcad version or may I assume that the user will take care of this dependence? |
| 01:48.05 | brlcad | kunigami: that is pretty odd then .. it's in my config (but then I added it) |
| 01:49.18 | brlcad | as for zlib, is there already a configure option for --with-zlib=/path/to/zlib or somesuch? otherwise the top-level build file can take care of passing it in the build flags |
| 01:49.42 | kunigami | brlcad: hmm, let me check |
| 01:52.54 | kunigami | there's no such option. so the idea is that one top-level file builds all osl dependencies? |
| 01:58.16 | brlcad | yeah, something very simple to assist builds on linux/bsd/mac |
| 01:59.12 | kunigami | hm, ok |
| 01:59.16 | brlcad | either a makefile or a script, whatever is easiest |
| 02:00.54 | kunigami | I'd go for script. I'm not that fluent with makefiles |
| 02:01.49 | brlcad | starseeker: data path loading requires either a) that one of the libbu path functions is called prior to a directory change or b) that the resources are in their install location |
| 02:03.03 | brlcad | if both those are false, then there's no way for libbu to know what the initial working directory path was (other than a hard override) |
| 02:11.14 | CIA-62 | BRL-CAD: 03bhinesley * r45836 10/brlcad/trunk/src/libged/edit.c: |
| 02:11.15 | CIA-62 | BRL-CAD: Batch arguments were expanding, but only the first set was being executed. |
| 02:11.15 | CIA-62 | BRL-CAD: Fixing this meant writing a function to duplicate command argument groupings, |
| 02:11.15 | CIA-62 | BRL-CAD: which in turn required changing the subcommand functions for looping through |
| 02:11.15 | CIA-62 | BRL-CAD: args. The counters needed to be exposed as paramaters, and made non-static... |
| 02:11.15 | CIA-62 | BRL-CAD: which should have been done in the first place. Updated the half-dozen or so |
| 02:11.15 | CIA-62 | BRL-CAD: places that depended on the old logic. |
| 02:20.19 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 03:04.18 | CIA-62 | BRL-CAD: 03bhinesley * r45837 10/brlcad/trunk/src/libged/edit.c: off by one errors introduced r45836 |
| 03:09.53 | starseeker | brlcad: it can't key off the location of the bwish binary? |
| 04:00.49 | starseeker | hmm... may want to re-examine the mechanism being used for plugin loading |
| 04:02.14 | CIA-62 | BRL-CAD: 03bhinesley * r45838 10/brlcad/trunk/src/libged/edit.c: |
| 04:02.15 | CIA-62 | BRL-CAD: Simplified/removed some things in edit(), and resolved several unrelated issues, |
| 04:02.15 | CIA-62 | BRL-CAD: many of which were recently introduced. Translate isn't quite working yet. There |
| 04:02.15 | CIA-62 | BRL-CAD: seems to be a problem getting the apparent coordinates of objects, which I think |
| 04:02.15 | CIA-62 | BRL-CAD: might all be evaluating to (0,0,0). Also, there are several untested option/arg |
| 04:02.15 | CIA-62 | BRL-CAD: combinations. |
| 04:04.31 | starseeker | brlcad: if the "change to current working directory before doing things" approach is what's causing the break, I wonder if it might be workable to scrap that altogether |
| 04:07.30 | starseeker | or "change the current working directory" rather |
| 04:07.44 | starseeker | doesn't quite see why that's essential |
| 04:22.16 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3060 10/wiki/User:Bhinesley: /* Log */ today, plan |
| 04:22.46 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3061 10/wiki/User:Bhinesley: /* Log */ typo |
| 04:32.21 | brlcad | starseeker: why what is/isn't essential? |
| 04:32.42 | brlcad | archer needing to change the cwd sounds bad |
| 04:33.49 | brlcad | and even if it "needs to" for some odd reason, it should be getting the current dir (via libbu) first so the path can be restored |
| 04:41.28 | starseeker | Archer::pluginLoadCWDFiles |
| 04:42.09 | starseeker | will try to sort it out tomorrow |
| 05:06.05 | brlcad | yeah, without getting into the nitty gritty, there doesn't sound like there's any reason it needs to load files from "cwd" .. it needs to load files from a plugin dir, determined from bu_brlcad_data "path/to/plugin/dir" |
| 05:46.30 | *** join/#brlcad blindbox (~UPPnub@60.51.60.209) | |
| 06:32.52 | *** part/#brlcad blindbox (~UPPnub@60.51.60.209) | |
| 08:33.16 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 08:58.26 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 09:56.50 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 13:32.33 | abhi2011 | brlcad: I am working on a new function to be added to librt which will reside in librt/bbox.c |
| 13:32.57 | abhi2011 | the function looks like this : rt_bound_dbfullpath(const struct db_full_path *pp, struct rt_i *rtip, fastf_t *tree_min, fastf_t *tree_max) |
| 13:33.31 | abhi2011 | so it will take a db_full_path and return the bb for the combination or region in that path, otherwise return an error |
| 13:38.08 | abhi2011 | however for finding the bb a db_full_path is not needed, generall the databse would be opened using rt_dirbuild() which returns a struct rt_i and not struct db_i |
| 13:38.29 | abhi2011 | from that point onwards only rt_* functions would be involved |
| 13:39.59 | abhi2011 | so I am currently using db_path_to_string() to convert the struct db_full_path passed to rt_bound_dbfullpath(), to a string representation of the path |
| 13:42.04 | abhi2011 | I can use this string representation of a region/group to search the list of regions available in the struct rt_i * trip |
| 13:42.27 | abhi2011 | once the region is found then I can use rt_bound_tree() to get the bb |
| 13:43.11 | abhi2011 | so my point is that db_path_to_string() seems to be the only way to jump from using db_* functions to rt_* functions |
| 15:33.55 | brlcad | abhi2011: the function shouldn't take an rtip |
| 15:34.19 | brlcad | that's an implementation detail .. needs to be a simple form of "here's an object, get the bounding box" |
| 15:35.14 | brlcad | either using db_full_patths or rt_db_internal objects, not immediately clear to me which is better |
| 15:36.42 | brlcad | also, in general, the database won't necessarily be opened with rt_dirbuild() .. that's only for raytracing applications. they may simply call db_open() or db_open_inmem() or wdb_dbopen() or ... |
| 15:37.19 | brlcad | that's one of the points of creating this function, hiding the fact that we create a raytrace context so we can call prep so we can get the bounding boxes |
| 16:12.05 | CIA-62 | BRL-CAD: 03brlcad * r45839 10/brlcad/trunk/src/proc-db/csgbrep.cpp: eliminate the remainder of dynamic memory allocation now that it is no longer needed. greatly simplifies creating sketch objects procedurally. |
| 16:31.58 | CIA-62 | BRL-CAD: 03brlcad * r45840 10/brlcad/trunk/src/librt/primitives/dsp/dsp_brep.cpp: help prevent crashing if the data file cannot be found, validate before trying to use the mapped file. this should be using dsp_get_data() instead of replicating logic. |
| 16:53.07 | CIA-62 | BRL-CAD: 03brlcad * r45841 10/brlcad/trunk/TODO: sketch objects get copied deeply now |
| 16:55.38 | CIA-62 | BRL-CAD: 03brlcad * r45842 10/brlcad/trunk/TODO: most of the wdb routines now properly make a copy so wdb_export can free it. possibly a few stragglers remaining, but not nmg and sketch previously mentioned. |
| 16:57.12 | CIA-62 | BRL-CAD: 03brlcad * r45843 10/brlcad/trunk/src/proc-db/sketch.c: no more dynamic mem |
| 16:57.43 | abhi2011 | brlcad: ok I get it. |
| 16:57.52 | CIA-62 | BRL-CAD: 03brlcad * r45844 10/brlcad/trunk/src/proc-db/csgbrep.cpp: we already created a db_internal, don't call mk_sketch() directly. |
| 16:59.25 | abhi2011 | all the prep functions take an rtip as input however i.e. rt_prep(struct rt_i *rtip) & rt_prep_parallel() |
| 16:59.43 | brlcad | knows that :) |
| 16:59.51 | abhi2011 | I am guessing these are the only 2 ways to get the bb |
| 17:00.00 | brlcad | you need an rtip |
| 17:00.06 | brlcad | the function, however, does not |
| 17:00.06 | abhi2011 | hmm so I would need to convert the input to an rtip |
| 17:00.14 | brlcad | right |
| 17:01.19 | abhi2011 | rt_dirbuild() would open up the database and return a rtip, but we dont want the caller to pass the database name as well |
| 17:01.27 | abhi2011 | just an object |
| 17:01.30 | brlcad | right |
| 17:01.50 | brlcad | and they might not be a raytracing app, so all they have is a filename and/or a dbip |
| 17:02.20 | brlcad | you might get away with passing a (struct db_i *, struct rt_db_internal *, min, max) |
| 17:02.46 | brlcad | or db_i, name, min, max |
| 17:02.49 | abhi2011 | yes i am looking at rt_new_rti() which has db_i |
| 17:02.57 | abhi2011 | as input |
| 17:03.25 | abhi2011 | yah I am guessing the user will have at a minimum the db_i |
| 17:03.33 | abhi2011 | else they wont have a file open :P |
| 17:04.21 | brlcad | they won't necessarily have a file open |
| 17:04.33 | brlcad | you can create memory-only database instances |
| 17:04.39 | abhi2011 | ah yes right |
| 17:04.48 | brlcad | but that's still encapsulated in a dsip |
| 17:04.52 | brlcad | *dbip |
| 17:04.55 | abhi2011 | both ways, the db_i would exist |
| 17:06.02 | abhi2011 | ok I ll proceed assuming that a db_i can be passed by the caller , as of now |
| 17:06.29 | CIA-62 | BRL-CAD: 03brlcad * r45845 10/brlcad/trunk/src/external/Unigraphics/ug-g.c: call rt_curve_free() for consistent cleanup |
| 17:17.34 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 17:17.34 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 17:19.00 | abhi2011 | ok, what is an in-mem, you mean an in memory representation of the comb, which can be prepped ? |
| 17:19.30 | brlcad | db_open_inmem() |
| 17:19.39 | brlcad | it's a dbip that only lives in memory |
| 17:20.52 | brlcad | you can create an in-mem dbip, add the struct rt_db_internal * to it, call rt_new_rti() to get an rtip, and finally call rt_gettree() to evaluate the bounding boxes |
| 17:23.26 | abhi2011 | ok |
| 17:26.35 | CIA-62 | BRL-CAD: 03brlcad * r45846 10/brlcad/trunk/src/conv/dxf/dxf-g.c: free the sketch now that mk_sketch() doesn't |
| 17:27.48 | abhi2011 | I see a duplication in 1 thing though |
| 17:28.12 | abhi2011 | since db_* functions already provide database manipulation capabilities on disk and in-mem |
| 17:28.38 | abhi2011 | is there any need to duplicate it in functions like rt_dir_build() |
| 17:28.40 | CIA-62 | BRL-CAD: 03brlcad * r45847 10/brlcad/trunk/src/conv/dxf/dxf-g.c: struct is embedded, can't be null, and rt_curve_free() wants a pointer. |
| 17:29.02 | abhi2011 | eg. rt_dir_build() and db_open() both open a database |
| 17:30.07 | abhi2011 | but perhaps its because rt_dir_build() opens a on disk database and very conveniently returns a rt_i which can be used further down the raytracing system |
| 17:30.13 | brlcad | rt_dirbuild() calls db_open() |
| 17:30.26 | abhi2011 | oh ok |
| 17:31.09 | brlcad | the goal of dirbuild is to give a raytrace instance, the point of open is to get a database instance .. different (albeit related) purposes |
| 17:31.37 | abhi2011 | yes I get understand |
| 17:33.03 | CIA-62 | BRL-CAD: 03brlcad * r45848 10/brlcad/trunk/src/conv/shp/shp-g.c: no longer need to allocate dynamic memory for the sketch, keep it on the stack and just free the minimal set of dynamic memory that was needed for the sketch's curve segments. |
| 17:36.49 | CIA-62 | BRL-CAD: 03brlcad * r45849 10/brlcad/trunk/src/libged/tire.c: another rt_sketch_internal that no longer needs to be dynamic. release the dynamic data associated with it though, now that mk_sketch() won't |
| 17:42.15 | abhi2011 | i was looking at d b _ c r e a t e _ i n m e m() as well and I see that it add a default _GLOBAL object as well, but what would be the point of adding such an object |
| 17:42.54 | brlcad | doesn't matter |
| 17:43.18 | brlcad | _GLOBAL holds the working units for the geometry in question |
| 17:43.30 | abhi2011 | ok |
| 17:45.47 | CIA-62 | BRL-CAD: 03brlcad * r45850 10/brlcad/trunk/src/libged/make.c: enable creation of the old/original sketch object if a LIBGED_MAKE_SKETCH environment variable is set to 1. useful for debugging purposes and makes the code get compiled so it doesn't fall out of sync with the api. |
| 17:52.24 | abhi2011 | I was reading about sketches at http://brlcad.org/wiki/Sketch , since I see a lot of code changes going on related to them, I guess they are simply a line and curve based drawing of a model's shape ? |
| 18:02.10 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 18:04.07 | brlcad | abhi2011: they're autocad-style 2d "drawings" |
| 18:05.17 | abhi2011 | ok |
| 18:21.52 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload: |
| 18:21.52 | CIA-62 | BRL-CAD: uploaded "[[Image:Example sketch.png]]": This is an example sketch that can be |
| 18:21.52 | CIA-62 | BRL-CAD: created with the ''make'' command if the LIBGED_MAKE_SKETCH environment variable |
| 18:21.52 | CIA-62 | BRL-CAD: is set to 1. This example sketch is primarily used for demonstration and |
| 18:21.52 | CIA-62 | BRL-CAD: debugging purposes. |
| 18:28.51 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3063 10/wiki/Sketch: link to the example sketch object image |
| 18:33.11 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3064 10/wiki/SGI_Cube: clean up alignment with |
| 18:35.04 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3065 10/wiki/SGI_Cube: swap images? |
| 18:47.55 | CIA-62 | BRL-CAD: 03brlcad * r45851 10/brlcad/trunk/ (include/raytrace.h src/librt/htbl.c): use size_t for hit table indexing |
| 19:03.43 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 19:03.43 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 19:05.21 | abhi2011 | Trying to convert the struct rt_db_internal to bu_external now as wdb_export_external() accepts only bu_external |
| 19:06.32 | abhi2011 | some of the primitives of librt do it |
| 19:06.57 | abhi2011 | like rt_ell_export5() in librt/primitives/ell/ell.c |
| 19:12.03 | abhi2011 | specifically the htond() and ntohd() seem to do conversions from an external db format bu_external to an internal rt_db_internal |
| 19:21.19 | brlcad | abhi2011: sounds too low-level |
| 19:22.46 | brlcad | wdb_put_internal() and rt_db_put_internal() both work at a higher level |
| 19:22.55 | abhi2011 | well I wish there was a wdb_export_external |
| 19:23.02 | abhi2011 | *wdb_export_internal |
| 19:23.04 | abhi2011 | ah ok |
| 19:23.36 | brlcad | get/put read/write to disk |
| 19:23.54 | abhi2011 | yes I need to look through the libwdb functions more carefully :P |
| 19:23.55 | brlcad | import/export convert from/to serialized (i.e., disk) format |
| 19:24.25 | brlcad | it's understandably complex to fresh eyes :) |
| 19:24.58 | abhi2011 | yah the thing is all the functions are there to make life easy, just need to run doxygen once |
| 19:25.39 | brlcad | even with doxygen, there are a LOT of functions .. so it takes a while |
| 19:25.52 | abhi2011 | ok |
| 19:56.59 | CIA-62 | BRL-CAD: 03kunigami * r45852 10/osl/trunk/compile.sh: Added a script to build ilmbase and openexr |
| 20:04.42 | brlcad | kunigami: ready for testing? |
| 20:07.06 | kunigami | no |
| 20:07.51 | kunigami | I'm currently trying to force openexr to use the local version of libz. It's getting from system] |
| 20:10.06 | brlcad | unless that causes a problem, wouldn't worry too much about it |
| 20:11.38 | kunigami | actually I don't know how to tell openexr where to look if it's not installed on the system :P |
| 20:12.04 | brlcad | main options are 1) install brlcad, then osl, then reinstall brlcad; or 2) link libz as svn external, then osl, then brlcad; or 3) copy libz, then osl, then brlcad |
| 20:12.44 | brlcad | autoconf supports setting CFLAGS/CXXFLAGS/CPPFLAGS/LDFLAGS during configure, that'd be how |
| 20:13.20 | brlcad | ./configure CPPFLAGS=-I/path/to/libz/include LDFLAGS=-L/path/to/libz/libdir |
| 20:14.20 | kunigami | oh ok, great then. (by the way, I didn't understand what you meant in those three options) |
| 20:17.12 | brlcad | in terms of dealing with libz |
| 20:17.18 | brlcad | basically three options |
| 20:17.45 | brlcad | if you assume brlcad is already compiled/installed (so you can use the libz it compiled), then you'll have to build brl-cad twice |
| 20:18.31 | kunigami | true |
| 20:19.06 | brlcad | alternatives are to link in libz sources (svn:external) or svn cp (i.e., fork them in) |
| 20:34.12 | CIA-62 | BRL-CAD: 03starseeker * r45853 10/brlcad/trunk/src/ (6 files in 3 dirs): Simplify loading of Archer plugins - use bu_brlcad_data and avoid all the CWD logic. Good cleanup, and plugin loading now works in the build directory. |
| 20:34.40 | brlcad | awesome |
| 20:48.34 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 21:08.04 | CIA-62 | BRL-CAD: 03starseeker * r45854 10/brlcad/trunk/src/libbu/basename.c: Generalize bu_basename with the BU_DIR_SEPARATOR variable |
| 21:09.52 | CIA-62 | BRL-CAD: 03starseeker * r45855 10/brlcad/trunk/src/libbu/basename.c: Fix comments |
| 21:12.32 | brlcad | starseeker: i imagine the bu_basename() change is user-visible in some fashion |
| 21:12.41 | brlcad | possibly the plugins one too |
| 21:13.11 | starseeker | possibly... plugins is visible only when running from the build directory (probably why it never got addressed sooner...) |
| 21:13.21 | starseeker | adds NEWS item for basename |
| 21:13.33 | brlcad | yeah, plugins wouldn't be then |
| 21:16.35 | CIA-62 | BRL-CAD: 03starseeker * r45856 10/brlcad/trunk/NEWS: Generalized the bu_basename function to work with Windows paths - allows libraries and programs to capture their executable name without path information. |
| 21:18.40 | brlcad | which means what to the user? |
| 21:19.03 | starseeker | brlcad: not entirely sure. |
| 21:19.09 | brlcad | heh |
| 21:19.25 | brlcad | what wasn't working that now is working? |
| 21:19.28 | starseeker | brlcad: things *might* not work because of that, but we apparently hadn't run into anything |
| 21:23.35 | *** join/#brlcad saltan (~lieven@d51530284.static.telenet.be) | |
| 21:25.37 | CIA-62 | BRL-CAD: 03brlcad * r45857 10/brlcad/trunk/NEWS: |
| 21:25.37 | CIA-62 | BRL-CAD: how about this. cliff and bob improved mged/archer/bwish run-time behavior on |
| 21:25.37 | CIA-62 | BRL-CAD: windows by fixing bu_basename() to work with the windows path separator. this |
| 21:25.37 | CIA-62 | BRL-CAD: low-level interface is used for capturing the path to the running executable, |
| 21:25.37 | CIA-62 | BRL-CAD: data resources, and more; so fixing the routine should generally make things |
| 21:25.37 | CIA-62 | BRL-CAD: better, making apps more consistent for windows users. |
| 21:30.14 | brlcad | prepares a large whoosh commit |
| 21:30.16 | starseeker | that'll work :-) |
| 21:30.22 | starseeker | ducks and hides |
| 21:51.12 | CIA-62 | BRL-CAD: 03brlcad * r45858 10/brlcad/trunk/ (88 files in 23 dirs): (log message trimmed) |
| 21:51.12 | CIA-62 | BRL-CAD: Convert all BRL-CAD magic numbers to uint32_t. This change affects more than a |
| 21:51.12 | CIA-62 | BRL-CAD: dozen structs and more than 500 usages throughout the code including many |
| 21:51.12 | CIA-62 | BRL-CAD: function signatures, but is still considered minimally impacting. This |
| 21:51.12 | CIA-62 | BRL-CAD: consolidates the slew of int, long, unsigned int, unsigned long, etc definitions |
| 21:51.12 | CIA-62 | BRL-CAD: of magic numbers that were assuming to be 4 bytes for magic number validation. |
| 21:51.13 | CIA-62 | BRL-CAD: It also exposed a curious book-keeping practice in NMG where pointers to the |
| 21:51.42 | starseeker | tests the woosh |
| 21:57.56 | starseeker | yep, seems to work |
| 22:03.13 | brlcad | argh |
| 22:21.49 | CIA-62 | BRL-CAD: 03bob1961 * r45859 10/brlcad/trunk/src/libtclcad/tclcadAutoPath.c: |
| 22:21.49 | CIA-62 | BRL-CAD: Need to copy result of call to bu_brlcad_root() into local storage before |
| 22:21.49 | CIA-62 | BRL-CAD: calling bu_brlcad_data() because bu_brlcad_root() uses static char array and |
| 22:21.49 | CIA-62 | BRL-CAD: bu_brlcad_data() calls bu_brlcad_root() overwriting what was previously in the |
| 22:21.49 | CIA-62 | BRL-CAD: static array. |
| 22:24.28 | abhi2011 | rt_uniresource is often(always) specified with rt_db_put_internal() |
| 22:24.43 | brlcad | it's a global |
| 22:24.47 | abhi2011 | I understand that it contains settings for uni processor machines |
| 22:24.56 | abhi2011 | yes |
| 22:24.57 | brlcad | sort of |
| 22:25.09 | abhi2011 | so what happens for multi cpu machines |
| 22:25.26 | CIA-62 | BRL-CAD: 03brlcad * r45860 10/brlcad/trunk/src/librt/ (4 files in 2 dirs): |
| 22:25.26 | CIA-62 | BRL-CAD: add a new private header for dsp-implementation use, moving the DSP() macro from |
| 22:25.26 | CIA-62 | BRL-CAD: dsp.c to this new dsp.h header so that the brep routine can use the same macro. |
| 22:25.26 | CIA-62 | BRL-CAD: remove the dsp_val() debugging wrapper function while we're at it. |
| 22:25.52 | brlcad | it's a "cpu resource" structure used for book-keeping |
| 22:26.11 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 22:26.15 | abhi2011 | ok |
| 22:26.29 | brlcad | the rt_uniresource can only be used by one cpu at a time, so it effectively makes that function single-threaded |
| 22:26.51 | abhi2011 | oh ok, some semaphore is present to enable that |
| 22:26.59 | brlcad | many functions pass resources around, but don't actually do anything with them |
| 22:27.13 | brlcad | others use the resource structure if they're SMP-aware |
| 22:27.17 | brlcad | like the ray tracer |
| 22:27.22 | abhi2011 | ok |
| 22:27.29 | brlcad | basically, don't worry about it |
| 22:27.35 | abhi2011 | ok :) |
| 22:27.43 | brlcad | if you were passed a resource, then pass it forward |
| 22:27.57 | brlcad | otherwise if you need to call something and don't have a resource, use the rt_uniresource |
| 22:28.17 | abhi2011 | ok |
| 22:31.35 | CIA-62 | BRL-CAD: 03brlcad * r45861 10/brlcad/trunk/src/librt/primitives/dsp/dsp_brep.cpp: |
| 22:31.35 | CIA-62 | BRL-CAD: make the dsp brep implementation use the new private dsp.h header for the DSP() |
| 22:31.35 | CIA-62 | BRL-CAD: macro instead of duplicating the code (bad, no donut for you). similarly, there |
| 22:31.35 | CIA-62 | BRL-CAD: shouldn't need to be any need to validate the dsp_ip or load it because that |
| 22:31.35 | CIA-62 | BRL-CAD: would have already happened during import. redoing that here will just leak |
| 22:31.36 | CIA-62 | BRL-CAD: memory and be not as good as what is done during import. |
| 22:36.08 | CIA-62 | BRL-CAD: 03starseeker * r45862 10/brlcad/trunk/src/other/tk/CMakeLists.txt: Make sure FREETYPE_LIBRARIES is empty if FREETYPE_FOUND is a no-go. |
| 22:38.40 | dli | /var/tmp/portage/media-gfx/brlcad-7.20.2-r1/work/brlcad-7.20.2/src/libged/png.c:363:38: error: 'Z_BEST_COMPRESSION' undeclared (first use in this function) |
| 22:39.10 | dli | starseeker, so, 7.20.2 is not compatible with libpng-1.5 |
| 22:40.14 | dli | starseeker, is there a patch to make 7.20.2 build with libpng-1.5? |
| 22:41.15 | ``Erik | that's actually a zlib symbol, one that's been there for a long time :/ |
| 22:43.15 | brlcad | dli: suspect that's not the actual first error |
| 22:43.38 | brlcad | probably preceeded with some failure to find/include zlib.h |
| 22:43.47 | dli | brlcad, seems to be, I do "make" again, that's the only error |
| 22:44.11 | brlcad | show the entire output from the compile line on |
| 22:44.33 | brlcad | make VERBOSE=1 if you're using cmake |
| 22:44.54 | dli | brlcad, http://pastebin.com/xH38anuF |
| 22:45.05 | brlcad | can't get to pastebin.com |
| 22:45.26 | brlcad | try http://paste.ubuntu.com/ |
| 22:46.20 | ``Erik | gnarly, that really is the first error |
| 22:46.44 | dli | brlcad, http://paste.ubuntu.com/662232/ |
| 22:48.06 | brlcad | so then it's finding some zlib.h that doesn't declare Z_BEST_COMPRESSION |
| 22:50.25 | dli | brlcad, let me try to build zlib |
| 22:50.27 | starseeker | dli: um. I suppose I could make a patch... |
| 22:50.36 | brlcad | dli: what does your system zlib.h look like? |
| 22:50.51 | dli | starseeker, if it's not too much work :( |
| 22:51.39 | brlcad | so far this has little if anything to do with libpng-1.5 |
| 22:52.03 | dli | brlcad, http://paste.pocoo.org/show/455636/ |
| 22:52.09 | ``Erik | you fools have 8 minutes until http://www.humblebundle.com is over, if'n ya wanna show your support for linux or osX :) |
| 22:54.53 | brlcad | dli: yeah, that zlib.h definitely defines Z_BEST_COMPRESSION |
| 22:55.08 | brlcad | edit that file and put a #error on the line before Z_BEST_COMPRESSION |
| 22:55.13 | brlcad | see if it's actually included |
| 22:55.19 | dli | brlcad, so, it's the building scripts or configure |
| 22:55.37 | brlcad | either neither? |
| 22:56.12 | starseeker | dli: this is most of it: http://bzflag.bz/~starseeker/png_patch.diff |
| 22:56.30 | starseeker | given it's gentoo, I'm assuming you're not using our src/other copies of zlib or libpng? |
| 22:56.42 | dli | starseeker, thanks |
| 22:57.09 | brlcad | the error says it's not declared, the source includes zlib.h, zlib.h lists it declared |
| 22:57.15 | brlcad | ergo, there is no problem |
| 22:57.23 | dli | starseeker, no other people, I'm the only one maintaining brlcad in gentoo |
| 22:57.32 | ``Erik | 2.5 minutes on humblebundle.com O.o |
| 22:58.08 | brlcad | nothing in libpng-1.5 changes Z_BEST_COMPRESSION |
| 22:58.30 | brlcad | so it's still an unknown problem, and libpng update is possibly a big red herring |
| 22:58.33 | starseeker | knows - was just giving him changes he will likely need later. |
| 22:58.58 | brlcad | OH |
| 22:59.13 | brlcad | I'm looking at head .. did 7.20.2 not include zlib.h ? |
| 22:59.19 | dli | starseeker, why do I still need this patch? http://paste.pocoo.org/show/455638/ |
| 22:59.21 | brlcad | (in src/libged/png.c |
| 22:59.47 | brlcad | that would explain it, lucy |
| 22:59.59 | dli | brlcad, the svn trunk builds without issue |
| 23:00.04 | starseeker | dli: um... may have something to do with spaces in paths... |
| 23:00.40 | starseeker | or just spaces in general |
| 23:00.42 | brlcad | dli: yeah, that explains it all -- the problem is a simple one-liner header #include missing |
| 23:01.14 | dli | brlcad, add the header to the c file itself? |
| 23:01.21 | brlcad | hm? |
| 23:01.29 | starseeker | dli: does the patch I posted fix it? |
| 23:01.31 | brlcad | #include "zlib.h" was missing from that file |
| 23:01.45 | dli | starseeker, let me try |
| 23:01.54 | brlcad | starseeker's patch, http://bzflag.bz/~starseeker/png_patch.diff fixes it for the previous release |
| 23:02.13 | brlcad | png.h must no longer auto-include zlib.h for you |
| 23:04.17 | CIA-62 | BRL-CAD: 03brlcad * r45863 10/brlcad/trunk/src/librt/primitives/dsp/dsp.h: prevent crashing if the dsp buffer isn't set yet |
| 23:04.46 | CIA-62 | BRL-CAD: 03brlcad * r45864 10/brlcad/trunk/src/proc-db/csgbrep.cpp: initialize all of the dsp fields so we don't crash on export |
| 23:08.01 | ``Erik | yup, 1.4 has #include <zlib.h>, 1.5 does not |
| 23:10.22 | ``Erik | png.h indicates that you should pass an actual number and that they may not correlate to the zlib values in the future |
| 23:11.08 | ``Erik | line 1646 |
| 23:11.45 | brlcad | funny, their manpage gives an example using Z_BEST_COMPRESSION :) |
| 23:13.06 | ``Erik | (does his best wallace shawn voice) docs that're out of date? inconceivable! |
| 23:14.49 | CIA-62 | BRL-CAD: 03kunigami * r45865 10/osl/trunk/compile.sh: added oiio compilation. there's an issue with cmake mixing TBB versions (like it does with opengl in brlcad), so by now I just set TBB_USE=0 |
| 23:16.43 | CIA-62 | BRL-CAD: 03bhinesley * r45866 10/brlcad/trunk/src/libged/edit.c: |
| 23:16.43 | CIA-62 | BRL-CAD: Enabled use of bounding box centers of objects as points. Basic object |
| 23:16.43 | CIA-62 | BRL-CAD: translations are working "translate -k obj1 -a obj2 obj3", "translate -a obj2 |
| 23:16.43 | CIA-62 | BRL-CAD: obj1", etc. (redrawing is broken, the objects have to be blasted). It turns out |
| 23:16.43 | CIA-62 | BRL-CAD: that getting the natural origin is what is causing the 0,0,0 coordinates; |
| 23:16.44 | CIA-62 | BRL-CAD: haven't been able to figure out why. Many things aren't working yet. At least |
| 23:16.44 | CIA-62 | BRL-CAD: some translations using reference vectors are working. |
| 23:18.21 | CIA-62 | BRL-CAD: 03brlcad * r45867 10/brlcad/trunk/src/librt/primitives/ (20 files in 20 dirs): |
| 23:18.21 | CIA-62 | BRL-CAD: make the caller allocate an ON_Brep object, maybe they want to avoid dynamic |
| 23:18.21 | CIA-62 | BRL-CAD: memory allocation altogether. this plugs a leak in the csgbrep proc-db and begs |
| 23:18.21 | CIA-62 | BRL-CAD: changing the *_brep() param to a simple ON_Brep * instead of a double pointer. |
| 23:19.42 | brlcad | cheers on bhinesley |
| 23:19.55 | brlcad | progress, :) |
| 23:20.04 | bhinesley | yes, finally :) |
| 23:21.49 | bhinesley | still a lot to fix/test |
| 23:22.18 | bhinesley | for instance "translate 5 obj1.c" is broken |
| 23:22.20 | bhinesley | rolls eyes |
| 23:22.31 | starseeker | heh - hang in there |
| 23:22.46 | starseeker | that "it's all coming together" feeling is a lot of fun |
| 23:25.59 | bhinesley | starseeker: agreed |
| 23:30.04 | bhinesley | if I could do one thing differently, I would have used simple linked lists of arguments with flags, instead of a union of subcommand structs of args. That made so much more work and caused so many problems, that it couldn't possibly have been worth it |
| 23:32.56 | bhinesley | the only 'pro' is that it should make it easier to build subcommand arguments programatically. Create a union, attach a command name, stuff the arguments in the correct elements and go. |
| 23:33.09 | bhinesley | s/Create/declare |
| 23:33.25 | starseeker | nods - hindsight is often like that |
| 23:49.32 | starseeker | makes a note to check this out later: http://dgnlib.maptools.org/ |
| 00:13.34 | starseeker | bhinesley: one question - with the benefit of hindsight, would it be better going forward to switch to a linked list approach (not right now obviously, with gsoc winding up RSN, but in the future) |
| 00:14.43 | bhinesley | it probably depends on how often we're building commands programatically |
| 00:15.22 | starseeker | linked lists can also be built programatically though, can't they? |
| 00:16.13 | starseeker | figures for the editing commands programmatic calling will probably be fairly common... |
| 00:26.36 | dli | starseeker, brlcad with starseeker's patch, brlcad-7.20.2 builds with libpng-1.5, thanks |
| 00:27.52 | starseeker | dli: np - good to know it fixes it for external libpng as well as our local copy |
| 00:47.57 | *** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net) | |
| 00:49.17 | bhinesley | starseeker: yes; but it *may* be easier, and/or less error prone for edit() callers to use the structs. (btw, callers can actually still use a linked list if need be, and just run it through edit_<subcmd-name>_add_cl_args() before calling edit()). I decided on the edit_cmd union because it seemed like building args would be more legible, and therefore easier to build: "cmd.translate.ref_vector.from = arg;" rather than "args |
| 00:52.12 | bhinesley | structs seems more "rigid", as you have a finite number of elements (arguments) that you can add |
| 00:54.21 | bhinesley | as far as creating new edit subcommands goes, I don't think it makes much of a difference; it requires a couple subcommand-specific functions that would not be required if linked lists were used, but they're ~20 lines and dead simple. |
| 00:58.06 | bhinesley | it feels like hacking in linked-list behavior, though |
| 01:24.14 | bhinesley | I can't think of a compelling reason switch to linked lists. I'm open to criticism, though. |
| 03:05.03 | *** join/#brlcad dli_ (~dli@dsl-173-248-211-69.acanac.net) | |
| 03:15.04 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) | |
| 03:15.05 | yukonbob | oh hai |
| 03:27.51 | CIA-62 | BRL-CAD: 03brlcad * r45868 10/brlcad/trunk/src/librt/ (db_io.c dir.c): the rt_fwrite_internal/db_fwrite_internal functions are only intended to work with v4 geometry. |
| 03:31.23 | *** join/#brlcad dli_ (~dli@dsl-69-171-146-13.acanac.net) | |
| 03:39.11 | CIA-62 | BRL-CAD: 03brlcad * r45869 10/brlcad/trunk/src/proc-db/csgbrep.cpp: relearning how to write an object from nothing |
| 03:39.38 | CIA-62 | BRL-CAD: 03brlcad * r45870 10/brlcad/trunk/src/proc-db/csgbrep.cpp: ws |
| 03:40.06 | CIA-62 | BRL-CAD: 03brlcad * r45871 10/brlcad/trunk/src/proc-db/csgbrep.cpp: indent |
| 03:43.30 | CIA-62 | BRL-CAD: 03brlcad * r45872 10/brlcad/trunk/src/proc-db/ (19 files): ws and indent cleanup |
| 03:52.08 | yukonbob | before I dig in: I'm getting a build failure on 7.20.2 (NetBSD, providing some own utilities (ie: tcl/tk/itcl) |
| 03:53.08 | yukonbob | is a warning (treated as error): bitv.c: in function 'bu_hex_to_bitv': |
| 03:53.45 | yukonbob | bitv.c:250: warning: array subscript has type char |
| 03:53.48 | yukonbob | , same for line 255 |
| 03:54.05 | yukonbob | had same error w/ 7.20.0 |
| 03:54.20 | yukonbob | known issue? |
| 03:55.16 | yukonbob | hrmm... macro issue? |
| 03:55.35 | brlcad | yukonbob: not a known issue, just our strict compilation behavior treating a warning as an error |
| 03:55.53 | yukonbob | hey brlcad :) |
| 03:55.54 | brlcad | you can disable strict compilation and it'll succeed |
| 03:56.09 | yukonbob | nods. alright :) Onward! |
| 03:57.05 | brlcad | if you try to compile with trunk, a full build log would be useful |
| 03:57.11 | brlcad | so someone can fix the warnings |
| 03:57.43 | yukonbob | will work incrementally. |
| 03:58.19 | yukonbob | 7.20.2 for now... I've got some tcl/tk/itcl integration I'd like to work with somebody on; then bigger fish |
| 03:59.12 | yukonbob | just svn updated, but has to review tree, got merge conflicts, which is weird, considering I don't edit my local copy. |
| 03:59.51 | yukonbob | re-./configure'd, make'ing. |
| 04:00.36 | yukonbob | brlcad: autoconf et al still to be first class citizens for foreseeable future? |
| 04:01.51 | brlcad | yukonbob: not really |
| 04:02.01 | brlcad | the build system is being replaced with the new cmake build system |
| 04:02.05 | yukonbob | ok... so cmake transition went well? |
| 04:02.11 | brlcad | for the most part |
| 04:02.14 | yukonbob | nice. |
| 04:02.22 | brlcad | autotools is going through our deprecation process now |
| 04:02.27 | yukonbob | I like cmake, despite it's problems. |
| 04:02.47 | yukonbob | my biggest peave is that they didn't use Tcl as the control language, but half-baked their own, but... ;) |
| 04:02.54 | brlcad | http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/doc/deprecation.txt?revision=HEAD |
| 04:03.09 | brlcad | basically a 3-month minimum to give people a head's up |
| 04:03.29 | yukonbob | nods. |
| 04:03.41 | yukonbob | well, congratulations on the shift; not a small feat! |
| 04:03.50 | brlcad | starseeker did all the hard work |
| 04:03.57 | yukonbob | was just going to ask... |
| 04:04.09 | yukonbob | I know cliff was heads-down in it for a while. |
| 04:04.34 | yukonbob | [incr starseeker] |
| 04:06.21 | yukonbob | dammit |
| 04:06.24 | CIA-62 | BRL-CAD: 03brlcad * r45873 10/brlcad/trunk/src/libged/ (dbip.c grid.c nmg_collapse.c): quell the non-%V warnings listed in dli's build log |
| 04:06.28 | yukonbob | now real macro issues. |
| 04:07.01 | yukonbob | iso C does not permit named variadic macros... |
| 04:07.43 | yukonbob | hrmm. Looks to be from own X11 headers. |
| 04:08.26 | yukonbob | oh. nm. /me reads on, sees, is itk. |
| 04:15.40 | CIA-62 | BRL-CAD: 03brlcad * r45874 10/brlcad/trunk/src/other/tcl/CMakeLists.txt: looks like this file is not in sync with the sources.. build failure with missing symbol and sure enough the source file isn't being compiled. |
| 04:24.18 | brlcad | bhinesley: ../../../src/libged/edit.c:1226: warning: passing argument 2 of 'ged_path_validate' discards qualifiers from pointer target type |
| 04:25.33 | brlcad | if you can capture another "make -k 2>&1 | tee build.log" .. I can take another pass at squashing any warnings that remain so you can keep strict enabled |
| 04:26.40 | bhinesley | brlcad: will do |
| 04:27.32 | brlcad | also, |
| 04:27.33 | brlcad | ../../../src/libged/path.c:83: error: conflicting types for 'ged_path_validate' |
| 04:27.33 | brlcad | ../../../include/ged.h:1885: error: previous declaration of 'ged_path_validate' was here |
| 04:27.42 | brlcad | perhaps header not checked in |
| 04:27.56 | bhinesley | that's odd |
| 04:28.13 | brlcad | or... maybe I'm not up to date..... |
| 04:28.19 | brlcad | lemme check |
| 04:28.41 | bhinesley | I did change them in 2 seperate commits |
| 04:30.03 | brlcad | low and behold, that was the problem for both issues, it's all good |
| 04:30.09 | brlcad | sorry for the bother! |
| 04:30.18 | bhinesley | oh np |
| 04:39.27 | CIA-62 | BRL-CAD: 03brlcad * r45875 10/brlcad/trunk/src/proc-db/csgbrep.cpp: things are way simpler than I was attempting, just call wdb_put_internal() |
| 04:40.29 | CIA-62 | BRL-CAD: 03brlcad * r45876 10/brlcad/trunk/src/proc-db/csgbrep.cpp: unused var |
| 04:43.08 | bhinesley | brlcad: build log: http://paste.pocoo.org/show/455744/ |
| 04:48.11 | CIA-62 | BRL-CAD: 03brlcad * r45877 10/brlcad/trunk/src/proc-db/csgbrep.cpp: |
| 04:48.11 | CIA-62 | BRL-CAD: turns out, wdb_put_internal() has similar delusional notions to the mk_*() |
| 04:48.11 | CIA-62 | BRL-CAD: functions assuming memory is dynamic and ready to be released. since we have |
| 04:48.11 | CIA-62 | BRL-CAD: stack objects, that's bad. fortunately, it skips the free if idb_meth isn't |
| 04:48.11 | CIA-62 | BRL-CAD: set, so try to pull a fast one. |
| 05:00.24 | CIA-62 | BRL-CAD: 03brlcad * r45878 10/brlcad/trunk/src/librt/ (db5_io.c wdb.c): prevent crashing if idb_meth isn't set |
| 05:21.38 | CIA-62 | BRL-CAD: 03brlcad * r45879 10/brlcad/trunk/src/librt/primitives/ (5 files in 5 dirs): remove debugging print statements, noisy |
| 05:28.04 | CIA-62 | BRL-CAD: 03brlcad * r45880 10/brlcad/trunk/src/librt/primitives/pipe/pipe_brep.cpp: shush |
| 05:28.25 | CIA-62 | BRL-CAD: 03brlcad * r45881 10/brlcad/trunk/src/librt/primitives/sketch/sketch.c: print 5 in v5 routines, not 4 |
| 05:35.41 | CIA-62 | BRL-CAD: 03brlcad * r45882 10/brlcad/trunk/src/librt/primitives/ehy/ehy_brep.cpp: unused vars, perhaps wip |
| 05:36.27 | CIA-62 | BRL-CAD: 03brlcad * r45883 10/brlcad/trunk/ (include/raytrace.h src/librt/primitives/sketch/sketch.c): more uint32_t magic number fallout |
| 05:50.36 | CIA-62 | BRL-CAD: 03brlcad * r45884 10/brlcad/trunk/src/librt/primitives/ (extrude/extrude.c revolve/revolve.c sketch/sketch_brep.cpp): even more magic fallout. highlights the importance of consistently testing magic numbers, particularly where pointers to them are shoved into bu pointer tables and end up with signage issues. |
| 06:02.50 | CIA-62 | BRL-CAD: 03brlcad * r45885 10/brlcad/trunk/src/librt/primitives/revolve/revolve_brep.cpp: yep, more |
| 06:07.23 | yukonbob | yay me! successfully built, installing; issues that I recognize from previous installs; conflicts w/ libpng between in-tree and other-installations, need to #include <zlib.h> (will find file), tweak itcl/itk... |
| 06:11.29 | CIA-62 | BRL-CAD: 03brlcad * r45886 10/brlcad/trunk/src/librt/primitives/revolve/revolve_brep.cpp: more shushing |
| 06:12.36 | CIA-62 | BRL-CAD: 03brlcad * r45887 10/brlcad/trunk/src/proc-db/csgbrep.cpp: and with this, we should now have all primitives getting written out identically in brep and implicit form (export needed the idb_type to be set). dsp is hozered, so disable. |
| 06:13.09 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 06:29.32 | brlcad | bhinesley: THX! |
| 06:30.22 | bhinesley | np |
| 06:30.46 | *** part/#brlcad saltan (~lieven@d51530284.static.telenet.be) | |
| 06:46.06 | CIA-62 | BRL-CAD: 03bhinesley * r45888 10/brlcad/trunk/src/libged/edit.c: (log message trimmed) |
| 06:46.06 | CIA-62 | BRL-CAD: Wrote a function to expand arguments with partial coordinates set, via -x/-y/-z |
| 06:46.06 | CIA-62 | BRL-CAD: options (support for this was missing in edit()). Required changes to functions |
| 06:46.06 | CIA-62 | BRL-CAD: for getting object coordinates; they now write to any vector they are passed, so |
| 06:46.06 | CIA-62 | BRL-CAD: that coordinates may be obtained without modifying the edit_cmd object. Resolved |
| 06:46.06 | CIA-62 | BRL-CAD: issue in an argument string parsing function, which was incorrectly pairing |
| 06:46.07 | CIA-62 | BRL-CAD: objects with the coordinates that they followed. Had to remove ability to |
| 07:06.27 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3066 10/wiki/User:Bhinesley: /* Log */ today |
| 07:23.16 | *** join/#brlcad dli (~dli@dsl-69-171-146-13.acanac.net) | |
| 09:45.54 | *** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ) | |
| 09:46.33 | *** join/#brlcad d_rossbe1g (~rossberg@BZ.BZFLAG.BZ) | |
| 09:47.20 | abhi2011 | brlcad: I have been trying to insert a struct rt_db_internal into a directory |
| 09:48.10 | abhi2011 | it goes like this : http://bin.cakephp.org/view/73267920 |
| 09:48.30 | abhi2011 | so I create a in-mem dbip |
| 09:48.58 | abhi2011 | and then I create a struct directory by using dp = db_lookup(dbip, ip->idb_meth->ft_name, LOOKUP_NOISY) |
| 09:49.19 | abhi2011 | the struct directory is required when using rt_db_put_internal(dp, dbip, ip, &rt_uniresource) |
| 09:49.59 | abhi2011 | the db_lookup() is bound to fail however because the dbip it uses has just been created, so its empty |
| 09:50.39 | abhi2011 | so is there any other way to create a struct directory * that can be passed to rt_db_put_internal() |
| 09:54.47 | abhi2011 | probably db_diradd() may work |
| 10:34.47 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 11:17.49 | d_rossberg | abhi2011: you have just created the in-memory database, therefore it's empty |
| 11:18.35 | d_rossberg | you probably need a rt_i* as a parameter |
| 11:19.55 | abhi2011 | d_rossberg: Yes true, however I need top insert a struct rt_db_internal into the dbip before I can make a rt_i* out of it |
| 11:20.05 | abhi2011 | <PROTECTED> |
| 11:20.45 | abhi2011 | however before I can call rt_new_rti , i need to insert an object (represented by rt_db_internal) into the dbip |
| 11:22.12 | abhi2011 | to insert a rt_db_internal into the dbip, I call rt_db_put_internal(dp, dbip, ip, &rt_uniresource) |
| 11:22.29 | abhi2011 | which requires a struct directory * dp |
| 11:22.47 | abhi2011 | its while getting the dp that I run into an issue |
| 11:23.22 | abhi2011 | I obviously cannot use db_loopup() because dbip is empty |
| 11:23.32 | abhi2011 | yet I need dp :P |
| 11:23.56 | abhi2011 | *db_lookup() |
| 11:24.06 | d_rossberg | i'm afraid it's impossible to get the rtip back from a rt_db_internal structure |
| 11:24.49 | d_rossberg | rt_db_internal points to the internal representation of an object |
| 11:24.56 | abhi2011 | hmm, my final aim is to calculate the bounding box for the passed rt_db_internal |
| 11:25.07 | d_rossberg | it needs to be castet to the real object type |
| 11:25.13 | abhi2011 | oh ok |
| 11:25.31 | abhi2011 | so a switch case to detect the object type |
| 11:25.31 | abhi2011 | and convert |
| 11:25.31 | d_rossberg | look at rtgeom.h for these types |
| 12:53.39 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 12:53.39 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 12:55.22 | CIA-62 | BRL-CAD: 03brlcad * r45889 10/brlcad/trunk/src/proc-db/csgbrep.cpp: this is v5 geometry, need to set the major_type as well as the minor. |
| 13:00.47 | abhi2011 | So I am calling wdb_put_external() using : |
| 13:00.49 | abhi2011 | if (wdb_put_internal(dbip->dbi_wdbp, ip->idb_meth->ft_name, &ip, 1.0) < 0) |
| 13:01.05 | abhi2011 | I want it to insert an object named sph2.s |
| 13:01.28 | abhi2011 | however ip->idb_meth->ft_name point to the ID of the sphere geometry ID_ELL |
| 13:01.46 | abhi2011 | I would need the object name here |
| 13:02.08 | abhi2011 | There should be some way to extract the object name from the struct rt_db_internal |
| 13:02.21 | abhi2011 | I am looking at the fields of idb_meth now |
| 13:03.39 | abhi2011 | so instead of wdb_put_internal (wdbp=0x634420, name=0x7fffe98ccdb0 "ID_ELL", ip=0x7fffffffd988, local2mm=1) |
| 13:03.52 | abhi2011 | I want to call the function as wdb_put_internal (wdbp=0x634420, name=0x7fffe98ccdb0 "sph2.s", ip=0x7fffffffd988, local2mm=1) |
| 13:06.23 | CIA-62 | BRL-CAD: 03brlcad * r45890 10/brlcad/trunk/src/proc-db/csgbrep.cpp: extrude and revolve don't actually need their own sketch objects, reduce |
| 13:09.02 | tofu | abhi2011: look at that file (csgbrep.cpp) .. in there is a little function that shows an rt_db_internal getting added to a database |
| 13:09.47 | tofu | at the rt_db_internal layer, you don't know the name any more, but you don't need to -- so you can just give it any dummy name |
| 13:10.25 | tofu | the whole point of adding it to a dbip in the first place is just so you can get a proper rtip so you can call dirbuild and/or prep to get the bounding box calculated automatically |
| 13:10.49 | tofu | see the write_out() function |
| 13:12.03 | abhi2011 | tofu: thanks! i suspected the name wouldnt be there anymore and yes i dont need it too |
| 13:12.04 | tofu | there's also wdb_put_internal() that is even simpler and might work for you (just write_out() couldn't use it) |
| 13:12.22 | abhi2011 | ok |
| 13:13.25 | abhi2011 | tofu: yes i am using wdb_put_internal (wdbp=0x634420, name=0x7fffe98ccdb0 "ID_ELL", ip=0x7fffffffd988, local2mm=1) now |
| 13:13.38 | abhi2011 | which needs a name to be pased as well |
| 13:13.53 | abhi2011 | i could try a dummy of course |
| 13:18.10 | tofu | bhinesley: you actually have no more compilation warnings listed in that log, just one bonefide build failure in cursor.c |
| 13:19.41 | tofu | bhinesley: something is awry with the termcap.h/term.h/curses.h header detection, so it's not getting a header included that it needs -- if you would, work with starseeker to see what cmake isn't detecting properly as it's not a source code issue but a build system issue |
| 13:30.03 | CIA-62 | BRL-CAD: 03brlcad * r45891 10/brlcad/trunk/src/tclscripts/mged/openw.tcl: only attempt to override tk behavior if tk is loaded |
| 13:33.13 | starseeker | tofu: I'll take a look at that today - Bob's machine is having a similar issue |
| 13:33.57 | starseeker | mildly frustrating - I thought I finally had that sorted - but I'll squash it sooner or later |
| 13:34.35 | CIA-62 | BRL-CAD: 03brlcad * r45892 10/brlcad/trunk/src/tclscripts/mged/helpdevel.tcl: supposed to read helplib.tcl, but it doesn't, so simpilfy |
| 13:37.12 | CIA-62 | BRL-CAD: 03brlcad * r45893 10/brlcad/trunk/src/tclscripts/mged/help.tcl: try a different way to read in the helplib.tcl file, source it |
| 13:46.05 | CIA-62 | BRL-CAD: 03brlcad * r45894 10/brlcad/trunk/src/tclscripts/mged/mged.tcl: |
| 13:46.05 | CIA-62 | BRL-CAD: another case where a tk function is curiously being overridden for no apparent |
| 13:46.05 | CIA-62 | BRL-CAD: reason. TextInsert was added by gdurf back in 1995 with an empty log message, |
| 13:46.05 | CIA-62 | BRL-CAD: so yank it. the current tk version looks similar enough but better. |
| 13:48.44 | CIA-62 | BRL-CAD: 03brlcad * r45895 10/brlcad/trunk/src/tclscripts/mged/skt_ed.tcl: don't shadow the dot proc with a value |
| 13:51.16 | CIA-62 | BRL-CAD: 03brlcad * r45896 10/brlcad/trunk/src/tclscripts/mged/skt_ed.tcl: remove the Sketch_editor namespace lookalike prefix from a handful of funcs that aren't listed as itcl class methods but are pretending to be them. make them regular procs. |
| 13:53.34 | CIA-62 | BRL-CAD: 03brlcad * r45897 10/brlcad/trunk/src/tclscripts/rtwizard/RaytraceWizard.tcl: script isn't always being run as a main application, make sure argv exists |
| 13:55.31 | CIA-62 | BRL-CAD: 03brlcad * r45898 10/brlcad/trunk/src/tclscripts/ (cad_dialog.tcl hoc.tcl): make sure the tk namespace exists before trying to set variables in it |
| 14:04.00 | tofu | that should actually take care of most if not all of the tclscript blather |
| 14:04.12 | CIA-62 | BRL-CAD: 03brlcad * r45899 10/brlcad/trunk/src/tclscripts/mged/ (8 files): |
| 14:04.12 | CIA-62 | BRL-CAD: this could use some rethinking, but instead of testing to make sure the commands |
| 14:04.12 | CIA-62 | BRL-CAD: we need actually exist at 'source' time, see if they exist at run-time. this |
| 14:04.12 | CIA-62 | BRL-CAD: should avoid pkgindex blather and be more likely that the command is actually |
| 14:04.12 | CIA-62 | BRL-CAD: already loaded. |
| 14:07.37 | abhi2011 | csgbrep.cpp seems to be making a model by inserting arbs, ellipses etc using mk_brep() |
| 14:08.55 | tofu | it would seem that way because it is |
| 14:09.15 | tofu | it makes each primitive in implicit and brep/nurbs form |
| 14:09.23 | tofu | irrelevant for what you're doing |
| 14:09.45 | abhi2011 | ok but I can use mkprep() to insert rt_db_internal |
| 14:09.47 | tofu | the point is how it's writing out primitives using an existing rt_db_internal* is very similar to what you're trying to do |
| 14:09.51 | abhi2011 | to a wdb |
| 14:09.55 | tofu | no |
| 14:10.04 | tofu | ignore mk_* |
| 14:10.10 | abhi2011 | ok |
| 14:10.53 | tofu | you were trying to write an rt_db_internal to an inmem dbip, so you can get an rtip from it |
| 14:10.59 | abhi2011 | yes right |
| 14:11.06 | abhi2011 | mk_brep writes a boundary repr |
| 14:11.18 | tofu | IGNORE mk_* |
| 14:11.37 | abhi2011 | yes ignored :) |
| 14:11.40 | tofu | you care about the rt_db_internal |
| 14:11.46 | abhi2011 | yes |
| 14:11.53 | tofu | read write_out() |
| 14:12.16 | tofu | it's yet another example of writing an rt_db_internal, you might be able to use a similar method |
| 14:12.30 | tofu | you may also be able to just use wdb_put_internal() |
| 14:13.52 | abhi2011 | tofu: yes I have tried wdb_put_internal(), however it requires a valid name t be passed, a dummy name does not work |
| 14:14.05 | tofu | eh? |
| 14:14.29 | abhi2011 | well I have tried it like this : wdb_put_internal(dbip->dbi_wdbp, "dummy.s", &ip, 1.0) |
| 14:15.19 | tofu | it doesn't know what is valid/invalid, so if that failed, it's something else |
| 14:15.55 | tofu | in fact, the name you provided isn't dummy at that point -- you're saying "write this ip as dummy.s" |
| 14:16.18 | tofu | which is correct -- so if it fails, something is probably either wrong with the wdbp or ip |
| 14:16.21 | abhi2011 | yes right |
| 14:17.07 | abhi2011 | hmm, I do a valid lookup of the ip using if ( !rt_db_lookup_internal(dbip, argv[2], &dp, &intern, LOOKUP_NOISY, &rt_uniresource)){ |
| 14:18.09 | tofu | so then when you say it "does not work", what do you mean exactly |
| 14:19.18 | abhi2011 | well I get a bad pointer error : ERROR: bad pointer 0x7ffff73da148: s/b rt_db_internal(xdbbd867), was Unknown_Magic(x7ffff73da5e0), file /home/abhi/socis/brlcad/src/librt/wdb.c, line 289 |
| 14:19.42 | abhi2011 | so here is the main program I have got so far to test : http://bin.cakephp.org/view/73267920 |
| 14:19.56 | abhi2011 | the program tests the new function in librt |
| 14:20.36 | abhi2011 | this is the function : http://bin.cakephp.org/view/267477296 |
| 14:23.49 | abhi2011 | trying to find out if the ip i am passing is somehow in incorrect form : wdb_put_internal (wdbp=0x634420, name=0x7fffe964745f "dummy.s", ip=0x7fffffffd988, local2mm=1) |
| 14:25.16 | abhi2011 | hmm the magick number is wrong |
| 14:26.56 | abhi2011 | the struct rt_db_internal probably needs to be properly initialized, just passing a pointer wont do |
| 14:27.35 | abhi2011 | i ll try with RT_DB_INTERNAL_INIT(tmp_internal); |
| 14:30.20 | abhi2011 | hmm no , thats not the case, because i pass a valid ip using rt_db_lookup_internal() in the program |
| 14:32.46 | abhi2011 | wdb_put_internal() causes bu_badmagic (ptr=0x7fffffffd988, magic=230414439, str=0x7fffe96a4577 "rt_db_internal", file=0x7fffe96a4350 "/home/abhi/socis/brlcad/src/librt/wdb.c", line=289) to be called |
| 14:34.39 | tofu | abhi2011: are you up-to-date with your checkout? |
| 14:35.04 | abhi2011 | no I am not , will check out now |
| 14:35.16 | tofu | there were a lot of magic number changes just yesterday and last night affecting magic numbers, that error looks related |
| 14:35.23 | abhi2011 | oh ok |
| 14:35.42 | abhi2011 | are magick numbers in a definite range ? |
| 14:35.49 | tofu | should always stay as up-to-date as possible, svn updating throughout the day unless you're at a critical point yourself |
| 14:35.53 | tofu | yes |
| 14:35.58 | tofu | they're a specific value that is expected |
| 14:35.59 | abhi2011 | so I can just look at a number and say this looks wrong |
| 14:36.03 | abhi2011 | ok |
| 14:36.29 | tofu | s/b means "should be" |
| 14:36.45 | tofu | so it should have had a value of xdbbd867 ... but instead it encountered x7ffff73da5e0 |
| 14:37.15 | tofu | which just looks like the aforementioned type cast problem that has already been fixed |
| 14:37.34 | abhi2011 | oh ok, yah the 7fffff.. thing looks like a virtual memory pointer |
| 14:47.44 | tofu | make sure you're actually passing correct data too, of course, that it really is a valid rt_db_internal |
| 14:50.05 | abhi2011 | tofu: yes, I get the rt_db_internal using rt_db_lookup_internal(), which does not return an error |
| 14:50.51 | CIA-62 | BRL-CAD: 03n_reed * r45900 10/brlcad/trunk/src/libgcv/wfobj/ (7 files): Removing unused C versions of obj parser sources. They will be out-of-sync with the refactored C++ parser sources. |
| 14:51.44 | CIA-62 | BRL-CAD: 03Lighkatwheajec 07http://compilefarm.net * r3067 10/wiki/Main_Page: |
| 15:24.59 | abhi2011 | thats strange, I get a seg fault after the latest checkout , during make install |
| 15:25.04 | abhi2011 | while Generating ../share/brlcad/7.20.3/db/terra.g |
| 15:26.01 | abhi2011 | http://bin.cakephp.org/view/1252572721 |
| 15:26.48 | abhi2011 | ok I ll probably need to run cmake again as well |
| 15:30.30 | CIA-62 | BRL-CAD: 03n_reed * r45901 10/brlcad/trunk/src/libgcv/wfobj/ (obj_parser.h obj_parser.h): Reverted obj_parser.h to last working verion. |
| 15:52.08 | abhi2011 | thats wierd I got the same error again |
| 15:52.55 | abhi2011 | anyone else getting this error while building the latest version ? |
| 15:53.32 | abhi2011 | appears to be related to rt_uniresource : ../bin/asc2g: Symbol `rt_uniresource' has different size in shared object, consider re-linking |
| 16:11.52 | tofu | abhi2011: you need to fully rebuild |
| 16:15.10 | brlcad | whatever dependency checking that cmake is doing apparently isn't full proof, make clean and rebuild |
| 16:33.08 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 16:41.24 | bhinesley | starseeker: at your service; let me know if you need me to do anything for the termcap/term/curses detection issue |
| 17:01.47 | CIA-62 | BRL-CAD: 03n_reed * r45902 10/brlcad/trunk/src/libgcv/wfobj/ (7 files): Changing .cc to .cpp. Whitespace and style. |
| 17:04.37 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 17:48.10 | abhi2011 | thats strange a did a fresh checkout and a clean rebuild |
| 17:48.23 | abhi2011 | brlcad compiled successfully |
| 17:48.45 | abhi2011 | and I inserted my function into librt for finding the bounding box |
| 17:49.01 | abhi2011 | but I still get an error related to magick numbers |
| 17:49.13 | abhi2011 | ERROR: bad pointer 0x7fff838b3c18: s/b rt_db_internal(xdbbd867), was Unknown_Magic(x838b40b0), file /home/abhi/socis/brlcad/src/librt/wdb.c, line 289 |
| 17:49.50 | abhi2011 | i dont think this is a svn related problem, as I did a fresh build after clearing everything |
| 17:51.09 | brlcad | what does your function look like |
| 17:52.40 | abhi2011 | brlcad: here it is http://bin.cakephp.org/view/84589638 |
| 17:53.37 | abhi2011 | this is the test program : http://bin.cakephp.org/view/453281250 |
| 17:53.40 | brlcad | I have trouble believing that compiles without warning |
| 17:54.38 | brlcad | listen to your compiler :) |
| 17:55.17 | brlcad | the bad point failure is correct from what I see |
| 17:55.23 | brlcad | *pointer |
| 18:03.41 | abhi2011 | brlcad: I ll have a look at the warnings again :) |
| 18:09.21 | abhi2011 | ah shoot!!, missed that one among the thousand other warnings |
| 18:15.28 | brlcad | you shouldn't have any warnings in your code.... |
| 18:23.07 | abhi2011 | by the way, while building brlcad, do you generally enable strict off : cmake ../brlcad -DBRLCAD-ENABLE_STRICT=OFF -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/home/abhi/brlcad |
| 18:23.41 | ``Erik | leaves it at default strictness |
| 18:24.31 | abhi2011 | ok :) |
| 18:25.46 | bhinesley | abhi2011: We're supposed to leave it on. I'm running gcc 4.6, so it's been necessary for me to disable it while the compiler warnings were being dealt with; but all code should be strict compliant. |
| 18:25.57 | brlcad | strict would be very useful if we turned it off, the point is to fix the issues reported |
| 18:27.15 | abhi2011 | ok, yes I remember turning it off last month when I running on gcc 4.6.0 :P |
| 18:27.55 | bhinesley | abhi2011: should be close to working now, if not working already |
| 18:28.05 | abhi2011 | nice ! |
| 18:28.18 | bhinesley | brlcad has been working 25 hours a day on that |
| 18:28.30 | bhinesley | cracks whip |
| 18:28.36 | abhi2011 | yeah I have seen him committing all day ! |
| 18:28.42 | brlcad | jumps |
| 18:28.46 | abhi2011 | :P |
| 18:29.13 | abhi2011 | well lots of commits |
| 18:30.36 | brlcad | abhi2011: if you read the announcements from CIA-62 or join the brlcad-commits mailing list, it's easier to follow developments as they occur so you are aware what's going on and how changes might affect you |
| 18:31.17 | brlcad | the commits mailing list can be particularly educational if you read through the patches and comments, get more familiar reading code |
| 18:31.50 | brlcad | (and that's true for pretty much any dev and any project that has a commit tracker) |
| 18:31.58 | abhi2011 | yes I have been following the CIA-62 announcements, will join the brlcad-commits mailing list |
| 18:32.43 | brlcad | not just to see "oh, john has been very busy and codes day and night" .. but actually have a pretty good idea of what john is doing and why |
| 18:38.33 | ``Erik | one would hope the commit message does that, but the diff is what's really happening |
| 18:44.13 | CIA-62 | BRL-CAD: 03Sean 07http://compilefarm.net * r3068 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/Lighkatwheajec|Lighkatwheajec]] ([[User talk:Lighkatwheajec|Talk]]); changed back to last version by [[User:Sean|Sean]] |
| 18:44.17 | CIA-62 | BRL-CAD: 03Sean 07http://compilefarm.net * r0 10/wiki/Special:Log/block: blocked [[User:Lighkatwheajec]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 18:47.27 | abhi2011 | yes, hoping to get commit access soon too :) |
| 19:05.14 | abhi2011 | ok I am finally past wdb_put_internal(), so rt_gettree() must always be called before rt_prep_parallel() , to load the geometry into rtip ? |
| 19:05.46 | brlcad | actually rt_gettree() should be sufficient, iirc |
| 19:05.55 | abhi2011 | ok |
| 19:06.07 | brlcad | you may have the bounding boxes computed by then |
| 19:06.49 | abhi2011 | ok, so rt_gettree() gets the tree structure for the passed object name, and attaches it to the rtip list of regions ? |
| 19:07.12 | abhi2011 | or probably marks them in rtip , that this and this will be raytraced in the future |
| 19:08.16 | ``Erik | hm, bounding volume info is generated during ft_prep() |
| 19:09.02 | abhi2011 | ok, and ft_prep() is probably called only by rt_prep() |
| 19:09.16 | ``Erik | yeh (or rt_prep_parallel() ) |
| 19:09.20 | brlcad | you'd think that |
| 19:09.23 | abhi2011 | yes |
| 19:09.26 | brlcad | but iirc, it's not |
| 19:09.43 | brlcad | don't guess, read the code |
| 19:10.03 | ``Erik | the 3 prims I looked at set st_center and friends in their _prep() funcs, rt_gettrees_muves() doesn't try to call prep on the primitives |
| 19:10.04 | brlcad | I believe you have everything you need after calling gettrees |
| 19:13.08 | brlcad | prior statement true, latter statement not so true |
| 19:16.12 | brlcad | basically, a slight nomenclature mismatch, always been the case afaicr |
| 19:16.22 | brlcad | rt_prep() and rt_prep_parallel() set up the spatial partitioning and other "preparation" activities |
| 19:16.42 | brlcad | the actual prep callbacks, however, are called before that during tree loading |
| 19:17.10 | brlcad | we consider all of that "prep time" when talking about rt, but code-wise, it's a separate step |
| 19:17.40 | ``Erik | huh, yeah, _rt_gettree_leaf() does the ft_prep |
| 19:18.19 | ``Erik | guess ya do have the primitive aabb's after rt_gettree(), just not the bvh |
| 19:18.24 | brlcad | thinks he brought a server to its knees |
| 19:18.38 | ``Erik | while(1)fork(); ? |
| 19:18.48 | brlcad | a little more insideous |
| 19:18.53 | brlcad | and unintentional |
| 19:18.55 | brlcad | actual work |
| 19:19.35 | ``Erik | g-nmg -a .00001 ? :D I oom'd a 64g box with something similar |
| 19:19.48 | brlcad | not even that far |
| 19:20.01 | brlcad | three or four big facetizations and a level 7 sphereflake output |
| 19:20.35 | ``Erik | ah, our sphflake example is level 3, right? |
| 19:20.41 | brlcad | a 0.1, two 0.01, and a default, along with sphflake |
| 19:20.50 | brlcad | something around there |
| 19:20.57 | brlcad | I've done a 7 and 8 before |
| 19:21.31 | brlcad | something like 100MB for 7, 1GB or so for 8 iirc |
| 19:22.44 | brlcad | course, could have been completely coincidental too |
| 19:22.59 | brlcad | but it's acting like a thrashed pig, a dead one at that |
| 19:25.51 | ``Erik | hm, c++ link issues with gcc 4.7, std::list stuff O.o |
| 19:32.10 | abhi2011 | ok I am trying to understand the code in tree.c, one thing I can immediately get : there is just one tree for the whole model right ? |
| 19:32.34 | abhi2011 | so rt_gettrees() can get nodes from this main tree |
| 19:32.51 | abhi2011 | which are the roots from smaller trees |
| 19:33.29 | abhi2011 | *for smaller trees I mean |
| 19:33.31 | brlcad | ``Erik: I linked with 4.7 just last week |
| 19:34.08 | brlcad | ooh, server sprung back to life! |
| 19:34.19 | ``Erik | I'm rebuilding with all local libs now, may've been a dep linked against 4.2 (this is on fbsd) |
| 19:34.32 | brlcad | hehe, load in the 50's |
| 19:35.10 | ``Erik | sphflake and the tesselations should all be single threaded... did someone do something silly and try to start a java program on it or something? O.o :D |
| 19:35.36 | CIA-62 | BRL-CAD: 03bhinesley * r45903 10/brlcad/trunk/src/libged/edit.c: flags for all 3 coordinates supplied in the "[x [y [z]]]" format were being set regardless of whether or not some of the optional coordinates were omitted |
| 19:36.32 | brlcad | probably memory, all four jobs I had running probably all wanted as much memory as they could get |
| 19:36.58 | brlcad | hm, though top seems to think there's plenty of memory, no swap in use |
| 19:37.09 | brlcad | *shrug* |
| 19:37.37 | ``Erik | http://paste.lisp.org/display/123942 |
| 19:37.49 | brlcad | aha... |
| 19:37.50 | brlcad | Program terminated with signal SIGKILL, Killed. |
| 19:38.13 | brlcad | someone intervened to bring it back to life |
| 19:38.50 | brlcad | apparently facetizing an ehy was sinking the ship |
| 19:39.51 | brlcad | ``Erik: at a glance, the GLIBCXX_3.4.15 is suspicious |
| 19:40.19 | ``Erik | yeh, considering librt links against /lib/libc.so |
| 19:40.23 | brlcad | gcc 4.7 should have come with a libc update |
| 19:41.13 | ``Erik | that librt links but things using librt don't is also surprising |
| 19:42.09 | ``Erik | hasn't really done c++ on gcc, or lately.. was almost all back on msvc1.0 and borland 4.5/5.02 |
| 19:44.21 | kunigami | does anyone know how to force cmake to find an include path? http://paste.ubuntu.com/662921/ |
| 19:47.03 | ``Erik | hm, interesting... it links against /usr/local/lib/gcc47/libstdc++.so, then runtime loads /usr/lib/libstdc++.so... might need explicit rpath info |
| 19:47.56 | brlcad | or ld_lib path set |
| 19:48.11 | brlcad | or /usr/local/lib config'd as a system lib dir before /usr/lib |
| 19:48.17 | ``Erik | yeah, my little test program worked when I gave it LD_LIBRARY_PATH |
| 19:48.31 | ``Erik | you mean /usr/local/lib/gcc47? I think /usr/local/lib is already there |
| 19:48.52 | brlcad | right |
| 19:49.52 | ``Erik | that's letting the build continue *shrug* interesting that the rpath info isn't being forced to the 'odd' library |
| 20:00.21 | CIA-62 | BRL-CAD: 03brlcad * r45904 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: revolve doesn't yet implement tessellation, but doesn't mean we should bomb. the NMG_CK checks aren't right since it's this function's job to fill them in. |
| 20:10.16 | CIA-62 | BRL-CAD: 03brlcad * r45905 10/brlcad/trunk/ (5 files in 3 dirs): revolve using sk instead of skt like extrude is just asking for trouble. make the two consistent, the same. |
| 20:13.19 | CIA-62 | BRL-CAD: 03starseeker * r45906 10/brlcad/trunk/src/other/CMakeLists.txt: |
| 20:13.20 | CIA-62 | BRL-CAD: Ah - when doing the local termlib, we have to specify that we are using the |
| 20:13.20 | CIA-62 | BRL-CAD: termcap.h header as well. Probably didn't spot this sooner because most systems |
| 20:13.20 | CIA-62 | BRL-CAD: had a system termcap.h and the BRLCAD_INCLUDE_FILE test just happened to work as |
| 20:13.20 | CIA-62 | BRL-CAD: well. |
| 20:19.47 | CIA-62 | BRL-CAD: 03brlcad * r45907 10/brlcad/trunk/src/librt/primitives/sketch/sketch.c: similarly wrong to check them for validity when we're supposed to fill them in |
| 20:20.35 | CIA-62 | BRL-CAD: 03brlcad * r45908 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: prevent tessellation from crashing on primitives that don't have a callback set (like sketch) |
| 20:27.29 | CIA-62 | BRL-CAD: 03erikgreenwald * r45909 10/brlcad/trunk/src/libged/typein.c: rt_revolve_internals sk is now skt. |
| 20:31.35 | CIA-62 | BRL-CAD: 03erikgreenwald * r45910 10/brlcad/trunk/src/libgcv/bottess.c: minor cleanup and reorg |
| 21:15.23 | abhi2011 | ok finally got the function working, testing it on regions/combinations and groups now before submitting a patch |
| 21:16.04 | kunigami | my problem was that cmake searches first on default paths. Adding NO_DEFAULT_PATH solved the problem |
| 21:21.54 | CIA-62 | BRL-CAD: 03kunigami * r45911 10/osl/trunk/osl/src/cmake/externalpackages.cmake: modified the way osl searches for external packages. we want it to seach for local libraries (that will be packed and compiled with osl) |
| 21:34.46 | starseeker | bhinesley: does that lastest commit to src/other/CMakelists.txt fix your compile issue? |
| 22:06.52 | bhinesley | applauds starseeker |
| 22:07.01 | bhinesley | works like a charm |
| 22:08.29 | bhinesley | This will be nice. No more grepping through build logs for my warnings. |
| 22:49.43 | brlcad | starseeker: vtk is the other project that came to mind that had implemented it a long while back |
| 22:50.49 | brlcad | looking at their docs, it looks like I was confusing their normal scene node sorting |
| 22:51.52 | brlcad | which, for what it's worth, is all we'd probably every want anytime soon anyways since depth peeling is relatively-speaking very expensive |
| 22:52.54 | brlcad | basically cuts performance by about an order .. which may be fine and dandy when your fps would have been 100+ .. but not when it's <1 fps |
| 22:53.08 | brlcad | http://www.vtk.org/Wiki/VTK/Depth_Peeling |
| 22:54.57 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 22:55.33 | brlcad | looks like there was/is a related ogre gsoc project this year |
| 22:56.49 | ``Erik | wishes ogre had a decent C interface for FFI O.o |
| 23:00.31 | abhi2011 | I am getting a strange error when I try to start Mged, after I shifted BRL-CAD from the default installation location at /usr/brlcad |
| 23:00.49 | abhi2011 | its now in /home/abhi/brlcad and is a debug build |
| 23:01.10 | abhi2011 | however when mged starts up its not able to find helplib.tcl and so cant start the gui |
| 23:02.44 | abhi2011 | I wonder how it knew previously to look in /usr/brlcad/share/brlcad/7.20.3/tclscripts |
| 23:03.25 | abhi2011 | there should be a configuration for mged which I am missing i think |
| 23:09.50 | bhinesley | abhi2011: with a debug build, you can run mged right from the build directory, without installing |
| 23:12.25 | bhinesley | much faster compile/dbug cycle that way anyways |
| 23:12.34 | bhinesley | *debug |
| 23:14.14 | abhi2011 | bhinesley: I tried that too just now, so I am in brlcad-build, I cd into bin and mged |
| 23:14.20 | abhi2011 | but the same error persists |
| 23:14.47 | bhinesley | what options are you building with |
| 23:15.18 | abhi2011 | cmake ../brlcad -DBRLCAD-ENABLE_STRICT=OFF -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/home/abhi/brlcad |
| 23:15.37 | bhinesley | actually, I'm getting the same error |
| 23:16.01 | abhi2011 | is it after a recent checkout ? |
| 23:16.38 | abhi2011 | the error is from mged.c |
| 23:16.43 | bhinesley | yes, recent checkout |
| 23:18.44 | bhinesley | yeah, it's looking in the wrong directory. changing to /home/bhinesley/brlcad-trunk/build/cmake/share/brlcad/7.20.3/tclscripts/geometree and then running ../../../../../bin/mged works |
| 23:19.44 | bhinesley | since ../helplib.tcl is correct if the CWD is geomtree |
| 23:20.10 | abhi2011 | the cmake changes wouldnt have a effect would it |
| 23:20.30 | bhinesley | I'm not sure, but it does sound like a job for starseeker |
| 23:20.43 | bhinesley | puts hand above brow and looks to the clouds |
| 23:20.53 | abhi2011 | :) |
| 23:22.41 | bhinesley | starseeker: archer isn't launching from build dir either: no files matched glob pattern "*.html" |
| 23:23.46 | abhi2011 | yes ../../../../../bin/mged works for me too |
| 23:58.13 | abhi2011 | brlcad: can we expect the librt bb function rt_bound_dbfullpath(struct rt_db_internal *ip, point_t *rpp_min, point_t *rpp_max) , to work only on primitives |
| 23:59.10 | abhi2011 | or should I expect the user to pass in regions or groups as well, in which I can iterate through the region's or group's constituent primitives |
| 00:00.21 | abhi2011 | though in my original program, I was detecting a region by passing over the region list in the rtip and checking for name matches |
| 00:03.43 | abhi2011 | so to detect the fact that the user has passed a region in a struct rt_db_internal , there should be a field in the struct rt_db_internal that identifies the contents as a region |
| 00:04.47 | abhi2011 | or the user would need to pass the model's directory so I can try name matches to detect |
| 00:20.10 | CIA-62 | BRL-CAD: 03kunigami * r45912 10/osl/trunk/osl/src/cmake/externalpackages.cmake: force cmake to ilmbase, openexr and llvm in the path os osl/trunk |
| 00:21.32 | CIA-62 | BRL-CAD: 03kunigami * r45913 10/osl/trunk/osl/src/testshade/CMakeLists.txt: disable testshade_dso app because it uses an oiio version that is not stable (its not used by brlcad) |
| 00:52.05 | CIA-62 | BRL-CAD: 03bhinesley * r45914 10/brlcad/trunk/src/libged/edit.c: |
| 00:52.05 | CIA-62 | BRL-CAD: With the improved edit_*_get_arg_head()'s, individual subcommand init functions |
| 00:52.05 | CIA-62 | BRL-CAD: are no longer necessary; a generic edit_cmd_init() can handle it all. Reduces |
| 00:52.05 | CIA-62 | BRL-CAD: the number of functions needed for each subcommand to 4; nice. Also in this |
| 00:52.05 | CIA-62 | BRL-CAD: commit: noticed a variable for a return value being initialized to a literal |
| 00:52.06 | CIA-62 | BRL-CAD: value, rather than GED_OK. |
| 01:53.16 | CIA-62 | BRL-CAD: 03bhinesley * r45915 10/brlcad/trunk/src/libged/edit.c: regrouping/sorting functions a bit |
| 02:05.14 | starseeker | bhinesley: um. that's probably the html viewer not finding its stuff |
| 02:05.25 | starseeker | looks at what mged is up too... |
| 02:06.11 | bhinesley | starseeker: yeah, it's the one that I wrote :-P |
| 02:06.31 | starseeker | can you see where it's failing? |
| 02:06.37 | bhinesley | yeah |
| 02:07.05 | bhinesley | man_browser.tcl:124 |
| 02:07.48 | starseeker | what's in $path? |
| 02:07.56 | bhinesley | I'm checking |
| 02:08.01 | starseeker | will see if he can duplicate the failure, one sec... |
| 02:08.44 | starseeker | regardless, we probably want to add -nocomplain to that glob - that's not a reason for archer to fail to start |
| 02:08.55 | bhinesley | ah there it is; its using the default for the class itself on :68 |
| 02:09.17 | bhinesley | starseeker: true |
| 02:11.26 | bhinesley | seems the other help browser needs it as well |
| 02:14.33 | bhinesley | hm, or not. |
| 02:14.47 | bhinesley | I'm still getting an error, even with -nocomplain |
| 02:17.00 | CIA-62 | BRL-CAD: 03starseeker * r45916 10/brlcad/trunk/src/tclscripts/mged/help.tcl: I think we want to get helplib.tcl from the tclscripts dir? |
| 02:18.15 | starseeker | bhinesley: I'm guessing share/brlcad/7.20.3/html doesn't have anything in it? |
| 02:18.59 | bhinesley | there are folders and files |
| 02:19.05 | starseeker | O.o |
| 02:19.06 | starseeker | weird |
| 02:19.22 | starseeker | what does puts $path print out? |
| 02:21.55 | bhinesley | well it's looking for ./share/brlcad/7.20.3/html/mann/en/ |
| 02:22.09 | starseeker | which does exist? |
| 02:22.20 | bhinesley | mann doesn't |
| 02:22.34 | starseeker | urm. that's the problem then |
| 02:32.04 | CIA-62 | BRL-CAD: 03starseeker * r45917 10/brlcad/trunk/src/tclscripts/man_browser.tcl: Don't refuse to start archer just because the html docs aren't around. |
| 02:32.22 | bhinesley | was just about to do that ;) |
| 02:33.28 | starseeker | one remaining wrinkle - when I nuked all of html and then re-ran make, the docs rebuilt but toc.html wasn't present - it's copied during the configure process, not the make process |
| 02:33.49 | bhinesley | meh... your way looks better anyways |
| 02:33.56 | starseeker | probably should have the archer help viewer check for that file as well as one of the generated files |
| 02:35.51 | starseeker | wonders reworking the "copy during configure" cases into build rules... wonder if that's practical/worth it... |
| 02:40.52 | CIA-62 | BRL-CAD: 03starseeker * r45918 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: |
| 02:40.52 | CIA-62 | BRL-CAD: Check for toc.html as well, since it comes from the configure process and not |
| 02:40.52 | CIA-62 | BRL-CAD: the make process in the build directory. May want to consider adding a copy |
| 02:40.52 | CIA-62 | BRL-CAD: build rule for things like this so make puts everything back where it belongs, |
| 02:40.52 | CIA-62 | BRL-CAD: but not a huge deal since re-running cmake takes care of it. |
| 02:44.15 | CIA-62 | BRL-CAD: 03starseeker * r45919 10/brlcad/trunk/NEWS: A bug in Archer's help browser code resulted in Archer failing to start if it was unable to find the html files used for the help system - it now starts even if those files are not present. |
| 02:44.28 | starseeker | ok, we should be good to go again |
| 02:44.40 | starseeker | abhi2011: does that fix it for you? |
| 02:45.15 | starseeker | bhinesley: still begs the question of why your mann directory wasn't present |
| 02:45.57 | bhinesley | I reconfigured and I'm rebuilding... perhaps it is now. Do you periodically reconfigure? I tend to just 'svn update' and make |
| 02:47.15 | bhinesley | it should trigger a reconfigure if it needs one, right? |
| 02:54.06 | bhinesley | starseeker: no dice |
| 02:59.11 | bhinesley | ok iiii'm an idiot. BRLCAD-BUILD_EXTRADOCS=OFF |
| 03:01.10 | bhinesley | that's what I get for using ccmake |
| 03:15.46 | starseeker | bhinesley: yeah, normally cmake is pretty good about reconfiguring/rebuilding when it needs to |
| 03:16.08 | starseeker | earlier case where brlcad had to recommend a clean rebuild was a bit surprising |
| 03:16.56 | starseeker | heh - yeah, if you tell it not to build the html docs it shouldn't :-P |
| 03:17.10 | bhinesley | imaging that! :) |
| 03:17.14 | bhinesley | *imagine |
| 03:17.31 | starseeker | did that fix everything? |
| 03:17.37 | bhinesley | yes |
| 03:17.50 | bhinesley | thank you |
| 03:18.18 | starseeker | np |
| 03:18.30 | bhinesley | looks like there was no cmake issue? |
| 03:19.13 | starseeker | I didn't see one - looked like just a few tcl file tweaks |
| 03:20.52 | bhinesley | oh I see it now, help.tcl |
| 03:22.14 | bhinesley | well, at least it exposed some problems |
| 03:22.52 | starseeker | sure - good stuff :-) |
| 03:23.33 | CIA-62 | BRL-CAD: 03bhinesley * r45920 10/brlcad/trunk/src/tclscripts/man_browser.tcl: set -nocomplain on glob, just in case; we don't want to fail to start due to some missing files |
| 04:35.47 | brlcad | starseeker: the earlier clean rebuild case wasn't cmake's fault -- just coincidentally hitting a magic number failure after the magic numbers were converter to uint32_t, but he was passing a bad pointer (so the magic failure was the right thing to do) |
| 04:37.54 | brlcad | abhi2011: they can pass in any object, maybe even non-geometry |
| 04:38.13 | brlcad | note that the name, rt_bound_dbfullpath(), is no longer right |
| 04:43.55 | brlcad | finishes organizing the logo submissions |
| 06:43.01 | CIA-62 | BRL-CAD: 03bhinesley * r45921 10/brlcad/trunk/src/libged/edit.c: |
| 06:43.01 | CIA-62 | BRL-CAD: Now that there are functions to convert path+objects+offsets to coords, |
| 06:43.01 | CIA-62 | BRL-CAD: arguments that had to be split into multiple structs (due to -x/-y/-z options) |
| 06:43.01 | CIA-62 | BRL-CAD: can be consolidated. It would be slightly more efficient to do this as the |
| 06:43.01 | CIA-62 | BRL-CAD: arguments are parsed, but IMO not worth muddying up ged_edit() over. |
| 06:58.41 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3069 10/wiki/User:Bhinesley: /* Log */ today |
| 07:22.18 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 09:14.25 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3070 10/wiki/User:Abhijit: /* Log */ |
| 09:42.04 | abhi2011 | brlcad: so I would need to find the list of primitives in the region represented by the rt_db_internal |
| 11:02.42 | abhi2011 | bhinesley: did the mged and archer launching errors get resolved after the latest checkout |
| 11:13.16 | CIA-62 | BRL-CAD: 03kunigami * r45922 10/osl/trunk/boost_1_46_1/: adding latest compatible boost version with osl. doing it by parts |
| 11:14.45 | CIA-62 | BRL-CAD: 03kunigami * r45923 10/osl/trunk/boost_1_46_1/boost/: adding latest compatible boost version with osl. part 2 |
| 11:38.34 | abhi2011 | ok, db_walk_tree() allows a nice set of functions to be provided for accepting and rejecting regions while building a boolean tree of the regions, I will try and use it for adding the primitives of the passed regions to the wdb |
| 11:52.11 | kunigami | hmm just saw that boost has ~ 500MB. should upload it to svn anyway? |
| 11:53.03 | kunigami | I didn't have to change anything on it from the original version. maybe add a line on the script to download it directly? |
| 12:12.37 | kunigami | llvm is pretty big too ~ 250MB |
| 12:36.21 | abhi2011 | kunigami: doesnt boost source already ship with brlcad in src/other/boost |
| 12:42.44 | abhi2011 | ok passing a leaf function to db_walk_tree() wont work because its never called even after a missing primitive is detected, was hoping to use the function to add the primitive |
| 13:31.06 | starseeker | abhi2011: mged and archer should launch now |
| 13:52.25 | abhi2011 | starseeker: yes its fine now, thanks! |
| 14:01.18 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 14:05.50 | brlcad | kunigami: that's a bit large to add, maybe see if you can identify the portion used? boost has a tool to identify the headers/deps needed so you don't have to download the kitchen sink |
| 14:06.05 | brlcad | llvm can be expected as a system install |
| 14:19.41 | CIA-62 | BRL-CAD: 03n_reed * r45924 10/brlcad/trunk/src/libgcv/wfobj/ (5 files): Using more readable names. Removed unused typedefs and some cryptic size checks of questionable utility. |
| 14:36.21 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-184-068.wlan.tudelft.nl) | |
| 15:12.02 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 16:27.57 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-184-068.wlan.tudelft.nl) | |
| 17:20.55 | *** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 17:58.58 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-184-068.wlan.tudelft.nl) | |
| 18:05.35 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 18:36.53 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 18:47.58 | kunigami1 | brlcad: ok |
| 18:51.24 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 19:12.44 | abhi2011 | brlcad: currently the librt function for finding the bb works on shapes, but if I pass regions then the db_walk_tree() detects that the shapes of the regions are absent and causes the bounding box to not be calculated |
| 19:13.44 | abhi2011 | so I am going to use the code in db_walk_tree() to add primitive leaf nodes when they are detected to be absent, which will involve significant amounts of duplicate code |
| 19:14.56 | abhi2011 | so I was wondering if there is an easier way to find and add the primitives to the rt_db_internal representation of a region |
| 19:17.02 | abhi2011 | db_walk_tree() allows call backs when a region is started and ended and for leaf nodes, but the leaf node callback is never called if a leaf (primitive) is found to be missing from the model tree |
| 19:40.03 | CIA-62 | BRL-CAD: 03starseeker * r45925 10/brlcad/trunk/src/other/incrTcl/itcl/ (4 files in 2 dirs): Take a stab at moving the itcl compilation logic over to the cleaned up logic being used for tcl itself |
| 19:43.56 | CIA-62 | BRL-CAD: 03bob1961 * r45926 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: |
| 19:43.56 | CIA-62 | BRL-CAD: Need to destroy the ray object whenever the ged object is destroyed or when |
| 19:43.56 | CIA-62 | BRL-CAD: opening a different database. This fix was prompted by database turds being left |
| 19:43.56 | CIA-62 | BRL-CAD: on Windows platforms whenever the ray object was used. That is, the ray object |
| 19:43.56 | CIA-62 | BRL-CAD: also has the database copy (i.e. the turd) open and so the code that removes the |
| 19:43.57 | CIA-62 | BRL-CAD: database copy fails. |
| 19:49.30 | brlcad | abhi2011: I don't think you can call db_walk_tree .. you don't know the name of the rt_db_internal that you're trying to calculate a bounding box for |
| 20:07.48 | brlcad | at least, you can't call it for that dbi -- you could call it for all of the comb's members to recursively get their bbs |
| 20:08.48 | brlcad | it might be easier to just implement ft_prep for combs |
| 20:10.22 | CIA-62 | BRL-CAD: 03starseeker * r45927 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Do as MGED does and default to Navy |
| 20:12.33 | brlcad | abhi2011: aha, I think I have a solution, but it depends on what your code looks like now |
| 20:12.59 | brlcad | since you DO have it working for primitive, just work on cleaning up the code and make your patch |
| 20:13.47 | brlcad | make it gracefully fail on combs for now, then once your patch is integrated, can work on bb of comb |
| 20:14.31 | abhi2011 | brlcad: hint to the solution :P |
| 20:15.06 | brlcad | if you have an rt_db_internal that is a comb, then you have a union tree pointer |
| 20:15.17 | abhi2011 | yes |
| 20:15.22 | brlcad | if you have a union tree pointer, then you can call the other/existing bbox routine, rt_bound_tree() |
| 20:15.53 | abhi2011 | ah yes thats the other function i used in my program before too |
| 20:17.05 | brlcad | you may still need to call rt_gettree/rt_gettrees to load/evaluate the tree, but that's easy |
| 20:17.05 | abhi2011 | rt_bound_tree(regp->reg_treetop, reg_min, reg_max) |
| 20:17.31 | brlcad | that'd only be for regions |
| 20:17.34 | brlcad | you have combs |
| 20:17.40 | brlcad | combp->tree |
| 20:17.40 | abhi2011 | ah yes |
| 20:17.52 | brlcad | see rt_comb_internal in raytrace.h |
| 20:18.15 | abhi2011 | ok |
| 20:18.26 | brlcad | basically, implementing much of what _ged_get_obj_bounds() does |
| 20:18.43 | brlcad | just instead of using db_full_path objects you're using rt_db_internal objects |
| 20:23.30 | abhi2011 | ok |
| 20:31.27 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 20:55.31 | CIA-62 | BRL-CAD: 03bob1961 * r45928 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: The backgroundColor routine should be calling ::cadwidgets::Ged::get_rgb_color instead of getRgbColor for consistency. |
| 20:57.16 | CIA-62 | BRL-CAD: 03bhinesley * r45929 10/brlcad/trunk/src/libged/edit.c: oops... edit_cmd initialization routine introduced r45921 tried to set pointer that was pointed to by uninitialized pointer to NULL |
| 21:18.00 | CIA-62 | BRL-CAD: 03starseeker * r45930 10/brlcad/trunk/src/other/ (7 files in 4 dirs): |
| 21:18.00 | CIA-62 | BRL-CAD: Make a stab at itk, probably the trickiest of these extensions. Need to do some |
| 21:18.00 | CIA-62 | BRL-CAD: more logic consolidation into tcl.cmake and the src/other CMakeLists.txt |
| 21:18.00 | CIA-62 | BRL-CAD: settings probably need some more study (there are a lot of possible cases) but |
| 21:18.00 | CIA-62 | BRL-CAD: getting there. Need to study STUBS usage in the standard Tcl/Tk build more and |
| 21:18.01 | CIA-62 | BRL-CAD: see if I need some conditionalization logic for those flags... |
| 22:10.31 | CIA-62 | BRL-CAD: 03starseeker * r45931 10/brlcad/trunk/src/libbu/progname.c: We need a static buffer here, otherwise our path disappears on us. |
| 22:11.33 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 22:45.45 | CIA-62 | BRL-CAD: 03starseeker * r45932 10/brlcad/trunk/src/libbu/progname.c: avoid overwriting the full argv0 path - bu_getprogname was storing its basename in the save variable as argv0's full path information. |
| 00:33.03 | ``Erik | progname, eh? O.o I feel like bu_basename is ... wrong... assumes '/' is the path delimiter, which isn't guaranteed |
| 00:34.01 | ``Erik | but I'm recouping from exercise, so'z what do I know |
| 00:34.31 | ``Erik | (also assumes that "." means "here") |
| 00:36.32 | CIA-62 | BRL-CAD: 03bhinesley * r45933 10/brlcad/trunk/src/libged/edit.c: |
| 00:36.32 | CIA-62 | BRL-CAD: Translations to absolute coordinates are mostly working now, id est "translate |
| 00:36.32 | CIA-62 | BRL-CAD: 10 20 30 sphere.s". Ommitted coordinates are set to 0 for the time being; will |
| 00:36.32 | CIA-62 | BRL-CAD: be enabled once relative positioning is working. Fixed lots of small stuff that |
| 00:36.32 | CIA-62 | BRL-CAD: was causing big problems: return variables not being checked properly, vectors |
| 00:36.32 | CIA-62 | BRL-CAD: not being initialized, using a ptr where a ptr-to-ptr was needed, etc. |
| 00:36.43 | ``Erik | (here are some delimiters, delimited with spaces: / \ : . > ) |
| 00:37.45 | ``Erik | (here are some parent directory delimiters, for s&g: .. [-] :: / ^ < ) |
| 00:38.21 | ``Erik | s/delimiters/specifiers/ |
| 00:39.13 | ``Erik | finishes drying off and heads out, have a good weekend all :) |
| 00:52.41 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 02:14.37 | CIA-62 | BRL-CAD: 03starseeker * r45934 10/brlcad/trunk/CMakeLists.txt: Stay with the release wording. |
| 02:16.26 | abhi2011 | patch submitted for new bounding box function in librt using struct rt_db_internal |
| 03:12.04 | CIA-62 | BRL-CAD: 03bhinesley * r45935 10/brlcad/trunk/src/libged/edit.c: (log message trimmed) |
| 03:12.04 | CIA-62 | BRL-CAD: Relative and absolute translations of single objects is now working, as is using |
| 03:12.04 | CIA-62 | BRL-CAD: a default of the bounding box center of objects or option -k to set keypoints. |
| 03:12.04 | CIA-62 | BRL-CAD: Objects and numbers are now working for all arguments, as well. Using the |
| 03:12.04 | CIA-62 | BRL-CAD: apparent coordinates of objects (i.e. translate -k |
| 03:12.05 | CIA-62 | BRL-CAD: a/very/specific/instance/of/shp.s -a 0 17 2.3 shp2.s) is working somewhat, but |
| 03:12.05 | CIA-62 | BRL-CAD: is off a bit in many cases. Specifiying coordinates/objects with -x/-y/-z is not |
| 03:15.19 | bhinesley | ^--regarding that... I failed to mention that using "obj/shp" vs. "shp" on the objects to translate does work as expected (ala oed) |
| 04:03.23 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 04:28.23 | CIA-62 | BRL-CAD: 03brlcad * r45936 10/brlcad/trunk/NEWS: reword to put verb foot forward first, and to remove trailing dash |
| 04:29.08 | CIA-62 | BRL-CAD: 03brlcad * r45937 10/brlcad/trunk/NEWS: |
| 04:29.08 | CIA-62 | BRL-CAD: reword to put verb foot forward first, and to remove trailing dash; A bug in |
| 04:29.08 | CIA-62 | BRL-CAD: Archer's help browser code resulted in Archer failing to start if it was unable |
| 04:29.08 | CIA-62 | BRL-CAD: to find the html files used for the help system - it now starts even if those |
| 04:29.08 | CIA-62 | BRL-CAD: files are not present. |
| 04:37.20 | CIA-62 | BRL-CAD: 03brlcad * r45938 10/brlcad/trunk/ (NEWS src/libged/keep.c): the keep command now saves the sketch associated with a revolve, not just the revolve itself. |
| 04:46.31 | CIA-62 | BRL-CAD: 03brlcad * r45939 10/brlcad/trunk/BUGS: revolve is busted? |
| 04:53.25 | CIA-62 | BRL-CAD: 03brlcad * r45940 10/brlcad/trunk/ (BUGS TODO): document a few more issues being uncovered by the nurbs testing. tessellation failures (crash and graceful aborts) on rhc and epa hypersensitivity to absolute tolerance. |
| 05:07.36 | CIA-62 | BRL-CAD: 03bhinesley * r45941 10/brlcad/trunk/src/libged/edit.c: Tweak behavior of -k/-a/-r translations, per IRC conversation with Sean on June 30, 2011, around 05:45:00 to UTC. Seems to be fully in compliance. |
| 05:26.33 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3071 10/wiki/User:Bhinesley: /* Log */ today |
| 06:46.21 | brlcad | ``Erik: er, bu_basename() uses BU_DIR_SEPARATOR now (change made earlier this week while you were sleeping) |
| 08:14.46 | brlcad | *finally* gets the script working (so he thinks) with all the calcs he originally intended: rt perf, rt pixdiff, rtedge pixdiff, rtxray pixdiff, projected area, and volume |
| 10:40.54 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 11:32.00 | ``Erik | huh, did I not svn up? O.o |
| 11:32.29 | ``Erik | I looked on my home box to see what kinda stuff starseeker was mucking with, it tends to be horribly out of date :) |
| 11:55.58 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r3072 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */ updated week 12, corrected formatting of week 11 |
| 12:32.06 | ``Erik | that's a lot of updated files O.o |
| 12:32.53 | ``Erik | if ya'll are calling this a churchville la tolteca day, I'm willing to come visit... otherwise, dayy off, beaches! |
| 12:33.18 | ``Erik | grabs a hedge trimmer and enjoys "vacation" O.o workworkowrk. zubzub. |
| 13:00.35 | abhi2011 | Hi, I have seen boolean trees uses many places in the code , like for example one of the parameters of rt_bound_tree() in librt |
| 13:01.05 | abhi2011 | I know what a boolean tree is , but I fail to understand how it can be used to represent a region |
| 13:02.11 | abhi2011 | I would think a region would be represented by a non-binary tree for example |
| 13:02.42 | abhi2011 | with the child nodes being the' unioned' regions or primitives |
| 13:04.24 | abhi2011 | a boolean tree would be more useful to represent decision trees for example, but I am probably missing some essential point about the data structure used to represent the model |
| 13:05.51 | abhi2011 | I can see that the operation on the constituents nodes like UNION/XOR are kept at the tree root, maybe thats the reason why boolean trees are used |
| 14:43.04 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3073 10/wiki/User:Abhijit: /* Log */ |
| 17:00.21 | *** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 17:32.48 | *** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 17:44.57 | CIA-62 | BRL-CAD: 03bhinesley * r45942 10/brlcad/trunk/src/libged/edit.c: Check for existence of matp_t before getting vector or applying deltas. |
| 17:47.11 | *** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 18:16.53 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 19:18.52 | *** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 19:39.07 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.128.100) | |
| 20:02.40 | *** join/#brlcad dli (~dli@dsl-173-248-243-175.acanac.net) | |
| 20:02.50 | CIA-62 | BRL-CAD: 03starseeker * r45943 10/brlcad/trunk/misc/CMake/FindTCL.cmake: Do as Tcl does - if Tcl is quiet, so too should Tk be quiet. |
| 20:36.56 | CIA-62 | BRL-CAD: 03bhinesley * r45944 10/brlcad/trunk/src/libged/edit.c: Disable error on the use of paths with len > 2. It was checking arguments it shouldn't have been. It may be better off dead anyways; see note in file. |
| 20:38.26 | brlcad | iiiinteresting votes on the logo images |
| 20:38.39 | CIA-62 | BRL-CAD: 03bhinesley * r45945 10/brlcad/trunk/src/libged/path.c: reincrement pointer/length when done; otherwise, freeing the path only works intermittently |
| 20:48.34 | louipc | hows that going? |
| 20:49.27 | brlcad | it's pretty much done :) |
| 20:49.43 | brlcad | nine judges have voted, four candidates shot to the top of the list |
| 20:57.50 | brlcad | ah *whew* |
| 20:58.15 | brlcad | actually thought we had a tie for first .. |
| 20:58.22 | brlcad | but was error in the maths |
| 20:59.17 | CIA-62 | BRL-CAD: 03starseeker * r45946 10/brlcad/trunk/ (6 files in 4 dirs): |
| 20:59.17 | CIA-62 | BRL-CAD: Begin a major re-work of the third-party-option-handling logic in CMake, taking |
| 20:59.18 | CIA-62 | BRL-CAD: advantage of CMake's ability to constrain variables to particular string values. |
| 20:59.18 | CIA-62 | BRL-CAD: This should actually simplify the build logic somewhat in the end, but right now |
| 20:59.18 | CIA-62 | BRL-CAD: it's definitely alpha and untested in most configurations. |
| 21:00.00 | brlcad | shaweet, very clear 1st, 2nd, 3rd |
| 21:04.46 | starseeker | oof |
| 21:04.46 | CIA-62 | BRL-CAD: 03starseeker * r45947 10/brlcad/trunk/CMakeLists.txt: Cleanup, delete leftover code. |
| 21:06.58 | CIA-62 | BRL-CAD: 03starseeker * r45948 10/brlcad/trunk/CMakeLists.txt: Beware cut and paste. |
| 21:08.04 | CIA-62 | BRL-CAD: 03starseeker * r45949 10/brlcad/trunk/CMakeLists.txt: ordering consistency |
| 21:09.43 | CIA-62 | BRL-CAD: 03starseeker * r45950 10/brlcad/trunk/CMakeLists.txt: mark RPMBUILD_EXEC as advanced |
| 21:11.22 | CIA-62 | BRL-CAD: 03bhinesley * r45951 10/brlcad/trunk/src/libged/edit.c: suboptions (-x/-y/-z) were erroneously detected as primary options, triggering a syntax error |
| 21:11.57 | CIA-62 | BRL-CAD: 03starseeker * r45952 10/brlcad/trunk/CMakeLists.txt: Stray newline |
| 21:19.58 | CIA-62 | BRL-CAD: 03starseeker * r45953 10/brlcad/trunk/configure.cmake.sh: Update configure.cmake.sh to reflect new variables |
| 21:22.02 | CIA-62 | BRL-CAD: 03starseeker * r45954 10/brlcad/trunk/ (3 files in 2 dirs): Rename FindTclPackage to more accurately reflect what it's doing these days |
| 21:23.09 | CIA-62 | BRL-CAD: 03starseeker * r45955 10/brlcad/trunk/CMakeLists.txt: Fix comment |
| 22:29.40 | CIA-62 | BRL-CAD: 03bhinesley * r45956 10/brlcad/trunk/src/libged/edit.c: |
| 22:29.40 | CIA-62 | BRL-CAD: Coordinate specification flags are all enabled by default, so a bitwise and is |
| 22:29.40 | CIA-62 | BRL-CAD: needed to enable just one. Once that was fixed, they were not being detected as |
| 22:29.40 | CIA-62 | BRL-CAD: suboptions; a separate flag was needed for that. ged_edit() is doing the right |
| 22:29.40 | CIA-62 | BRL-CAD: thing now, but now it's being picked up as bad syntax somewhere else. |
| 22:34.55 | CIA-62 | BRL-CAD: 03starseeker * r45957 10/brlcad/trunk/ (15 files in 14 dirs): Improve handling of extra documentation options - use conditional options keying off of program detection and other options, shorten variable names. |
| 22:36.29 | CIA-62 | BRL-CAD: 03starseeker * r45958 10/brlcad/trunk/configure.cmake.sh: Correct configure.cmake.sh |
| 22:37.27 | starseeker | figures that's enough damage for one day... |
| 23:30.43 | *** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 00:15.37 | abhi2011 | brlcad: I have modifying the bb function to work on groups and regions : http://bin.cakephp.org/view/1394071764 |
| 00:16.32 | abhi2011 | I am calling rt_gettree() before rt_bound_tree() to evaluate the tree first |
| 00:17.59 | abhi2011 | I am testing with a region made as follows in mged r part1.r u rcc2.s - sph2.s |
| 00:19.18 | abhi2011 | so when traversing the tree in the rt_bound_tree() call , the first call sees the subtraction operator in tp->tr_op and proceeds smoothly down to the left child |
| 00:20.34 | abhi2011 | however in the left tree where it should find the primitive rcc2.s, it encounters an unknown op 12, I think it should have encountered a tr_op = OP_SOLID for the rcc.s primitive |
| 00:22.05 | abhi2011 | this is probably related to the fact that the rt_gettree() calls reports missing primitives for the region : db_lookup(rcc2.s) failed in /dummy, db_lookup(sph2.s) failed in /dummy, |
| 00:22.07 | abhi2011 | rt_gettrees(dummy) warning: no primitives found |
| 00:24.31 | abhi2011 | so probably the missing primitives need to be added to the dbi , before the rt_gettree() call, so that the tree is evaluated properly |
| 00:53.16 | abhi2011 | ok, 12 is a OP_DB_LEAF as defined in raytrace.h: line 1177, wonder why rt_bound_tree() cant interpret it |
| 01:23.29 | starseeker | hah, cool: http://www.pointclouds.org/ |
| 01:27.00 | starseeker | wonders if we can feed raytrace points into that and get NURBS back... |
| 01:43.08 | starseeker | bhinesley: curious - how close is your command to being fully functional? |
| 02:09.12 | CIA-62 | BRL-CAD: 03starseeker * r45959 10/brlcad/trunk/CMakeLists.txt: Make sure BRLCAD_BUNDLED_LIBS is in the cache |
| 02:31.17 | CIA-62 | BRL-CAD: 03starseeker * r45960 10/brlcad/trunk/ (misc/CMake/ThirdParty_TCL.cmake src/other/CMakeLists.txt): Tweaks to get Tcl/Tk package testing going again. |
| 02:34.29 | bhinesley | starseeker: translate? Quite; I'd say that the "generic" subcommand processing plus the translate command is at 90% at worst. I'd planed on putting in some time this weekend, in the hopes that I will have translate completed, which would imply that generic subcommand processing is done as well. I'm aiming to have 'rotate' done by the end of GSoC; I'm not sure if I can, but that's what I'm shooting for. I highly doubt that I |
| 02:37.13 | CIA-62 | BRL-CAD: 03starseeker * r45961 10/brlcad/trunk/CMakeLists.txt: Constrain the CMake dropdown menu options for CMAKE_BUILD_TYPE to Debug and Release |
| 02:48.15 | bhinesley | recalculates: more like 95% at worst |
| 02:52.44 | starseeker | bhinesley: cool. the "recommended" pencil's down date for coding is the 15th, with a week to document what has been done - I was thinking, given the complexity of the command(s) your working on, it might not be a bad idea to start a docbook man page for this sucker - brlcad, what do you think? should bhinesley keep chugging on the code? |
| 02:53.12 | starseeker | can see arguments both ways, but I really hate to interrupt your momentum on the code |
| 02:53.30 | starseeker | particularly when it's something like this where having it all "loaded" in your head is important |
| 02:53.37 | bhinesley | ou know, I was actually thinking the same thing earlier today. I would be fine with documenting translate/edit before moving on. |
| 02:53.55 | starseeker | bhinesley: do you have any experience with docbook? |
| 02:53.59 | bhinesley | none |
| 02:54.02 | starseeker | winces |
| 02:54.07 | starseeker | urm |
| 02:54.24 | bhinesley | can't be that bad... |
| 02:54.57 | starseeker | posts that one on the "famous last words" hall of fame... |
| 02:55.11 | starseeker | the toplevel MGED command is "edit", correct? |
| 02:56.04 | bhinesley | yes; but ged_edit recognizes the command name being used, and if it is a subcommand, uses it transparently |
| 02:56.14 | starseeker | O.o hmm |
| 02:56.43 | starseeker | bhinesley: keep coding for now - I need to think about how to organize that doc wise |
| 02:57.27 | bhinesley | I don't know if the edit command itself all that necessary |
| 02:58.10 | bhinesley | we could hide it behind subcommands, or not hide it... I don't see that it makes any difference |
| 02:58.28 | bhinesley | unlikely that anyone is going to use "edit translate" when "translate" is available |
| 02:58.36 | starseeker | would have taken the approach of having a powerful "edit" command, and then have tcl level "wrappers" that translate "rotate" to "edit rotate" |
| 02:58.50 | starseeker | nods |
| 03:00.32 | bhinesley | we could still do that. Right now, there are edit/translate/rotate/scale commands all tied to ged_edit(). We could get rid of translate/rotate/scale, and do it at a TCL level. |
| 03:01.01 | starseeker | would like to have brlcad's opinion on that one |
| 03:02.07 | starseeker | not a big deal, I'm thinking - and I think you're right that the "man page" level is probably rotate/translate/scale - with perhaps a simpler one for edit showing the full syntax and referencing the individual man pages for each "subcommand" for more details |
| 03:02.26 | starseeker | otherwise edit would be a true monster of a man page |
| 03:02.37 | bhinesley | that's basically the format I had for the "mock" manual pages in edit.c |
| 03:02.59 | starseeker | was looking at those - nice work, and I think that will translate fairly cleanly to the docbook system |
| 03:03.47 | starseeker | bhinesley: I guess the thing to do is first make sure translate is solid, and see what brlcad thinks |
| 03:05.37 | bhinesley | alright. For the record, I tend to agree that translate should be documented before moving on. |
| 03:50.10 | CIA-62 | BRL-CAD: 03starseeker * r45962 10/brlcad/trunk/src/other/CMakeLists.txt: Need to flag ITCL_LIBRARY as advanced here too. |
| 04:19.48 | CIA-62 | BRL-CAD: 03starseeker * r45963 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/CompilerFlags.cmake): (log message trimmed) |
| 04:19.48 | CIA-62 | BRL-CAD: Use a variation on the three way option trick to get more sophisticated about |
| 04:19.48 | CIA-62 | BRL-CAD: turning on/off the optimization flags as a function of CMAKE_BUILD_TYPE - if |
| 04:19.48 | CIA-62 | BRL-CAD: Auto, optimization flags are on for Release and off for Debug, but 'hard' |
| 04:19.48 | CIA-62 | BRL-CAD: setting BRLCAD_FLAGS_OPTIMIZATION to ON or OFF will override the build-type |
| 04:19.48 | CIA-62 | BRL-CAD: based decision. Also, clear the compile flags before we do our thing to |
| 04:19.49 | CIA-62 | BRL-CAD: eliminate any flags CMake automatically adds for a given build type - that's why |
| 04:24.36 | CIA-62 | BRL-CAD: 03starseeker * r45964 10/brlcad/trunk/CMakeLists.txt: |
| 04:24.36 | CIA-62 | BRL-CAD: Go with the most expected/convenient behavior - can't think of a valid case to |
| 04:24.36 | CIA-62 | BRL-CAD: install a rel into a dev dir or vice versa, complete and deceptive violation of |
| 04:24.36 | CIA-62 | BRL-CAD: convention and more convenient/useful to have the install dir swapped as a |
| 04:24.36 | CIA-62 | BRL-CAD: function of build type. |
| 06:14.31 | CIA-62 | BRL-CAD: 03starseeker * r45965 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/CompilerFlags.cmake): Just like the optimization flag, except with the opposite defaults, enable smart autosetting of the debug flags. |
| 06:29.49 | CIA-62 | BRL-CAD: 03starseeker * r45966 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_Util.cmake): A pattern emerges, time for a macro. CMAKE_BUILD_TYPE aware options. |
| 06:33.26 | CIA-62 | BRL-CAD: 03starseeker * r45967 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_Util.cmake): Don't really need the project name and it's limiting flexibility. |
| 06:54.43 | CIA-62 | BRL-CAD: 03starseeker * r45968 10/brlcad/trunk/ (7 files in 7 dirs): |
| 06:54.43 | CIA-62 | BRL-CAD: Key the static lib building on the build type. Exposed a problem with making |
| 06:54.43 | CIA-62 | BRL-CAD: the trigger variable an OPTION in sub-builds - doing so forces the setting into |
| 06:54.43 | CIA-62 | BRL-CAD: the cache and makes it impractical for the AUTO_OPTION macro to do its thing. |
| 06:54.43 | CIA-62 | BRL-CAD: Fortunately, the only files doing that were the ones we wrote - corrected them, |
| 06:54.43 | CIA-62 | BRL-CAD: and we're good to go. |
| 06:57.26 | CIA-62 | BRL-CAD: 03starseeker * r45969 10/brlcad/trunk/CMakeLists.txt: Mark rtgl as advanced. Starting to look fairly clean now, at least on Linux. |
| 07:01.40 | starseeker | brlcad: hopefully that looks better, need to sleep now |
| 17:46.06 | CIA-62 | BRL-CAD: 03starseeker * r45970 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: do some validation on auto_options - probably should at least make these case insensitive, figure out best way to do that later. |
| 17:54.47 | CIA-62 | BRL-CAD: 03starseeker * r45971 10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake: Silly me - use tcl to ensure returning just the highest available package number, no need for bizarre regex foo in CMake. |
| 19:16.34 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 22:35.47 | kunigami | I used boost bcp to select the necessary headers to compile both osl and oiio. it copied a subset of the library into a separated directory. when building though, it does not generate lib's for libraries such as threads. does anyone have experience on doing this? |
| 04:06.36 | CIA-62 | BRL-CAD: 03bhinesley * r45972 10/brlcad/trunk/src/libged/edit.c: |
| 04:06.36 | CIA-62 | BRL-CAD: Using a single coordinate specifier per argument is now working, i.e. "translate |
| 04:06.36 | CIA-62 | BRL-CAD: -k -x ab/abc/sphere.s -a -x ab/def/sphere.s cube.s". Crashes if more than one is |
| 04:06.36 | CIA-62 | BRL-CAD: used per -k/-a/-r option. A routine consolidating multiple -x/-y/-z arguments |
| 04:06.36 | CIA-62 | BRL-CAD: into an edit_arg is the likely culprint. It was modified to accept a flag |
| 04:06.36 | CIA-62 | BRL-CAD: controlling whether to skip consolidation of union edit_cmd common.objects or |
| 04:06.37 | CIA-62 | BRL-CAD: not. Several unrelated corrections/comment updates. |
| 04:13.55 | CIA-62 | BRL-CAD: 03bhinesley * r45973 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: delete FIXME comments; Cliff said that this is how he'd do it anyways, so I worry about changing it. |
| 04:46.42 | bhinesley | ^-- heh, s/I worry/I won't worry/ |
| 07:18.58 | CIA-62 | BRL-CAD: 03bhinesley * r45974 10/brlcad/trunk/src/libged/edit.c: (log message trimmed) |
| 07:18.58 | CIA-62 | BRL-CAD: Initializing cur_arg pointer to wrong value after freeing, resulted in stepping |
| 07:18.58 | CIA-62 | BRL-CAD: over two nodes in linked list rather than one. Missing braces for if statements |
| 07:18.58 | CIA-62 | BRL-CAD: causing havoc. Attempt to free a shallow copy of a union edit_cmd (wasn't |
| 07:18.58 | CIA-62 | BRL-CAD: causing any problems though, since its contents were first replaced with NULL |
| 07:18.59 | CIA-62 | BRL-CAD: pointers, which was detected by the freeing function and therefore nothing was |
| 07:19.00 | CIA-62 | BRL-CAD: freed). Simplified and clarified a few other small things. Still some problems |
| 07:32.48 | CIA-62 | BRL-CAD: 03bhinesley * r45975 10/brlcad/trunk/src/libged/edit.c: |
| 07:32.48 | CIA-62 | BRL-CAD: Since target object paths are not checked for fp_len>2 anymore, translate needs |
| 07:32.48 | CIA-62 | BRL-CAD: to use the last two directories in path. Remove commented out code that might |
| 07:32.48 | CIA-62 | BRL-CAD: have been repurposed to detect argv strings containing >2 directories. It would |
| 07:32.48 | CIA-62 | BRL-CAD: be a shame to reduce functionality just to make things marginally more |
| 07:32.49 | CIA-62 | BRL-CAD: intuitive. |
| 07:50.48 | CIA-62 | BRL-CAD: 03bhinesley * r45976 10/brlcad/trunk/src/libged/edit.c: |
| 07:50.48 | CIA-62 | BRL-CAD: Comparing the contents of argument heads with that of common->objects is an |
| 07:50.48 | CIA-62 | BRL-CAD: unsure way to end loops involving get_arg_head(). Instead, compare the address |
| 07:50.48 | CIA-62 | BRL-CAD: of common->objects with that of the argument heads. This is of greatest |
| 07:50.48 | CIA-62 | BRL-CAD: practical significant in batch operations, where it is possible for |
| 07:50.49 | CIA-62 | BRL-CAD: common->objects to be NULL, and therefore match the first NULL argument, which |
| 07:50.50 | CIA-62 | BRL-CAD: is not necessarily common->objects. |
| 09:10.46 | CIA-62 | BRL-CAD: 03bhinesley * r45977 10/brlcad/trunk/src/libged/edit.c: |
| 09:10.47 | CIA-62 | BRL-CAD: Specifiying one or more coordinates using the -x/-y/-z options is working. There |
| 09:10.47 | CIA-62 | BRL-CAD: were missing parenthesis in several places, a couple conditionals that were |
| 09:10.47 | CIA-62 | BRL-CAD: !'ing when they obviously shouldn't, and space for a vector allocated |
| 09:10.47 | CIA-62 | BRL-CAD: conditionally when it should have been unconditional. I'll perform more thorough |
| 09:10.47 | CIA-62 | BRL-CAD: testing once batch operations are working. |
| 09:18.56 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3074 10/wiki/User:Bhinesley: /* Log */ friday, saturday |
| 09:20.24 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3075 10/wiki/User:Bhinesley: /* Log */ strike off completed item |
| 09:23.55 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3076 10/wiki/User:Bhinesley: /* General plan */ update progress |
| 11:13.18 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 12:02.24 | abhi2011 | I noticed a strange thing in mged, if a shapes is killed while in edit mode and then changes are accepted from the edit menu, then the accept |
| 12:02.25 | abhi2011 | tries to apply the changes to a non-existent shape and this crashes mged. |
| 13:26.20 | *** join/#brlcad plaes (~plaes@gn237.zone.eu) | |
| 13:26.52 | plaes | are there any plans to move brlcad repository to git? |
| 13:28.44 | louipc | Heheheh. Haven't heard anything. |
| 13:29.13 | louipc | brl-cad is huge though. so it might just be better to use svn in this case |
| 13:29.55 | plaes | well, yeah |
| 13:30.08 | plaes | is using git-svn anyway :) |
| 13:30.19 | louipc | cool |
| 13:30.31 | louipc | do you host your repo? |
| 13:30.45 | plaes | only on my machine |
| 13:31.22 | louipc | what's the point then? |
| 13:32.26 | plaes | just asking and sort of volunteering... ;) |
| 13:33.31 | louipc | hehe better host it and display the wonders of git |
| 13:33.47 | plaes | github ^^ :) |
| 13:34.15 | louipc | I really like git too, but it's not for everything |
| 14:35.43 | brlcad | plaes: no such plans |
| 14:37.42 | brlcad | when you want to require active instead of passive coordination and centralized development, dvcs just add extra steps with minimal benefits |
| 14:38.16 | brlcad | git-svn works just fine for those that want to use it |
| 14:43.08 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 16:26.25 | plaes | hum.. cmake doesn't seem to be checking whether system TNT and JAMA support exists |
| 17:35.10 | plaes | when trying to build with system Tcl/Tk, there's a failure during linking |
| 17:35.13 | plaes | cmake ^^ |
| 17:35.24 | plaes | is this known issue? |
| 18:01.49 | brlcad | plaes: not a known issue |
| 18:02.10 | brlcad | maybe you can post details (pastebin or sf tracker) with details? |
| 18:02.16 | brlcad | er yeah |
| 18:19.01 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 18:23.48 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 18:27.15 | plaes | hm, ok |
| 18:55.37 | plaes | http://paste.pocoo.org/show/458325/ |
| 18:56.25 | plaes | when linking against itcl, one has to provide the path to that library |
| 18:56.48 | plaes | I assume there are issues like that with other tcl/tk libs as well |
| 18:57.14 | plaes | unfortunately tcl/tk packaging is a mess.. :S |
| 20:03.14 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3077 10/wiki/User:Bhinesley: /* Log */ rephrase |
| 20:48.41 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 21:04.54 | brlcad | plaes: it looks like incrtcl is configured to use a system itcl -- do you have a system libitcl installed? |
| 21:08.03 | abhi2011 | brlcad: was wondering if you had a chance to look over the patch I submitted |
| 21:08.34 | plaes | ~> |
| 21:08.34 | ibot | somebody said > was redirection of stdout to a file. |
| 21:09.14 | brlcad | abhi2011: not yet, very busy weekend |
| 21:09.37 | plaes | brlcad: yes, I have it installed |
| 21:09.41 | brlcad | abhi2011: moreover, once someone does look at it, they generally update the tracker so you know it was reviewed |
| 21:10.05 | abhi2011 | :) yes I understand, I am proceeding with the simulate command coding etc |
| 21:10.37 | brlcad | that's fine, assuming the patch works perfectly :) |
| 21:11.12 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 21:11.12 | brlcad | if you run into a bug (you mentioned running into something the other day with mged) and find a fix, that'd be another perfect patch case |
| 21:11.36 | abhi2011 | cool will look in it |
| 21:11.48 | abhi2011 | yeah regarding the bb, having a bit of an issue with regions, but the patch I submitted will detect regions and combinations and gracefully exit |
| 22:28.59 | CIA-62 | BRL-CAD: 03bhinesley * r45978 10/brlcad/trunk/src/libged/edit.c: Accepting multiple target objects, and performing batch operations is working. Reflowed and revised some comments, and ran a spellcheck. The only remaining known issue is fixing/enabling option -n. |
| 22:53.53 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 23:00.03 | abhi2011 | anyone else getting a cannot find -litcl, cannot find -litk error ? |
| 23:00.08 | abhi2011 | when building |
| 23:15.36 | bhinesley | abhi2011: I just updated; no build errors for me |
| 23:17.25 | abhi2011 | ok thats strange, seems its asking looking for system which I have specified during cmake -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON |
| 23:17.33 | abhi2011 | *system libs |
| 23:18.26 | bhinesley | I have that enabled too |
| 23:18.57 | bhinesley | are you up to date? starseeker recently made some changes relating to Tcl |
| 23:20.02 | abhi2011 | yes I just updated , thats when I began getting this error |
| 23:20.40 | bhinesley | that's odd... you updated from the trunk dir, right? |
| 23:21.02 | abhi2011 | yep, as always |
| 23:21.06 | abhi2011 | its always worked before |
| 23:21.09 | bhinesley | hm |
| 23:21.29 | abhi2011 | i dont think i need itk-devel or itcl-devel |
| 23:21.52 | abhi2011 | the binary libs have been enough to link before this |
| 23:21.56 | bhinesley | I don't think so either |
| 23:22.20 | bhinesley | did you say you're running Fedora? |
| 23:22.29 | abhi2011 | opensuse 11.4 |
| 23:22.35 | bhinesley | ah, someone else then |
| 23:22.51 | abhi2011 | yeah it was me, ditched fedora :P |
| 23:23.08 | bhinesley | oh, hah |
| 23:23.25 | bhinesley | yeah I haven't been on good terms with it either |
| 23:27.51 | abhi2011 | compiler issues ? |
| 23:29.55 | bhinesley | no |
| 23:30.42 | bhinesley | I've had to boot to a rescue console at least twice. I run "yum update" and it boots fine again. |
| 23:30.57 | bhinesley | had to remove kmod-nvidia |
| 23:31.26 | bhinesley | there seems to be a lot of not-very-well-tested software that makes it into Fedora stable |
| 23:32.37 | bhinesley | I'll be back to Debian before long, I'm sure |
| 23:37.04 | bhinesley | s/a rescue console/single user mode |
| 23:39.54 | abhi2011 | yeah ubuntu seems pretty stable |
| 23:40.36 | abhi2011 | so most of the mged commands work in archer now ? |
| 23:40.56 | starseeker | the options for enabling everything have changed |
| 23:41.14 | starseeker | now it's -DBRLCAD_BUNDLED_LIBS=Bundled |
| 23:42.22 | starseeker | I'm not sure I can build against a system itcl/itk right at the moment - the 3rd party build logic got the guts ripped out of it and redone, so there's still some shakeout to do |
| 23:42.39 | bhinesley | abhi2011: most of them were working before I started |
| 23:42.56 | starseeker | we really really really need to quit using the Itcl/Itk C apis... |
| 23:43.48 | bhinesley | starseeker: why is that? |
| 23:44.38 | starseeker | it's what complicates building with system tcl/tk vs. bundled tcl/tk so much - I can detect if a system Tcl/Tk has Itcl/Itk installed as a package, but when we're using the C api that's not enough |
| 23:45.23 | bhinesley | ah |
| 23:45.31 | starseeker | I ripped that stuff out once already, but we got some reports that iwidgets wasn't working (I think brlcad got 'em) and it was a problem I have been unable to reproduce |
| 23:45.58 | starseeker | which means I can't debug it, and I can change it back until I can - Catch 22 |
| 23:47.28 | starseeker | bhinesley, abhi2011: after this latest round of updates, I'd be sure to clear my build dir and start fresh - lots and lots of changes |
| 23:47.54 | starseeker | cmake-gui will show you the current layout, if you happen to have the gui version available |
| 23:50.34 | abhi2011 | starseeker: ok so would i need to have the sources of itcl/itk installed ? |
| 23:51.03 | abhi2011 | or will enabling everything through -DBRLCAD_BUNDLED_LIBS=Bundled be enough to build |
| 23:51.39 | abhi2011 | hmm, i think it should look at the bundles libs, so the latter should be ok |
| 23:52.05 | abhi2011 | yeah, I am doing a fresh build now |
| 23:52.19 | bhinesley | starseeker: k, thanks |
| 00:02.30 | bhinesley | starseeker: cursor.c errors are back http://paste.pocoo.org/show/458445/ |
| 00:24.03 | bhinesley | starseeker: scratch that, appears to be my fault |
| 00:28.44 | abhi2011 | ok I get an error in analyze.c : /home/abhi/socis/brlcad/src/libged/analyze.c:312:5: error: call to function ‘rt_arb_centroid’ without a real prototype |
| 00:29.00 | bhinesley | starseeker: double scratch that... not my fault |
| 00:29.44 | abhi2011 | some more : /home/abhi/socis/brlcad/include/raytrace.h:3354:23: note: ‘rt_arb_centroid’ was declared here |
| 00:30.17 | abhi2011 | seems the declaration is not being taken correctly |
| 00:31.02 | abhi2011 | bhinseley: your error seems also related to implicit declarations |
| 00:31.57 | bhinesley | nods |
| 00:32.52 | abhi2011 | hmm even in track.c its the same thing: error: call to function ‘track_mk_comb’ without a real prototype |
| 01:25.35 | CIA-62 | BRL-CAD: 03bhinesley * r45979 10/brlcad/trunk/src/libged/edit.c: |
| 01:25.37 | CIA-62 | BRL-CAD: During certain batch translations, objects after the first target object simply |
| 01:25.37 | CIA-62 | BRL-CAD: moved to the same location as the first target object. This was due to certain |
| 01:25.37 | CIA-62 | BRL-CAD: translation vectors not being recalculated after executing the first |
| 01:25.37 | CIA-62 | BRL-CAD: translation. Since information about an argument is lost after the first vector |
| 01:25.37 | CIA-62 | BRL-CAD: is calculated, there needs to be a new vector (and therefore struct edit_arg) |
| 01:25.38 | CIA-62 | BRL-CAD: for each translation. |
| 01:53.12 | starseeker | bhinesley: can you give me a make VERBOSE=1 with the cursor error? |
| 01:53.55 | starseeker | also, can you tell me if brlcad_config.h has #define HAVE_TERMCAP_H 1 ? |
| 01:57.13 | bhinesley | there is no #define HAVE_TERMCAP_H |
| 01:57.19 | starseeker | growl |
| 01:57.19 | bhinesley | I'm running make right now |
| 01:57.33 | starseeker | one sec... let me see if I accidentally undid my fix |
| 01:57.48 | bhinesley | I saw it there |
| 02:01.13 | CIA-62 | BRL-CAD: 03starseeker * r45980 10/brlcad/trunk/src/other/CMakeLists.txt: Oops - variables changed, so update conditionals that use them... |
| 02:01.18 | starseeker | bhinesley: give that a shot |
| 02:01.39 | starseeker | sigh... the hazards of radical rework |
| 02:04.05 | bhinesley | rebuilding |
| 02:07.10 | dli | starseeker, does cmake scripts support system tcl/tk now? |
| 02:07.28 | dli | starseeker, instead of brlcad local building |
| 02:09.02 | starseeker | dli: it should - testing that now |
| 02:09.28 | CIA-62 | BRL-CAD: 03starseeker * r45981 10/brlcad/trunk/src/other/CMakeLists.txt: Be slightly more aggressive with the find_library command for itcl |
| 02:09.56 | dli | starseeker, great, because gentoo people still don't accept my packages, due to mandatory tcl/tk local building |
| 02:10.09 | starseeker | winces - yeah, not surprised |
| 02:13.54 | starseeker | dli: still working on local itcl/itk - one second |
| 02:21.23 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 02:34.08 | CIA-62 | BRL-CAD: 03starseeker * r45982 10/brlcad/trunk/src/ (3 files in 3 dirs): |
| 02:34.09 | CIA-62 | BRL-CAD: Ah, right. Original CMake logic written assuming package require based Itcl/Itk |
| 02:34.09 | CIA-62 | BRL-CAD: usage - when C libs were again necessary, just hacked in quickly. Can't get away |
| 02:34.09 | CIA-62 | BRL-CAD: with that anymore, so use variables where appropriate and look for itk C library |
| 02:34.15 | starseeker | dli: give that a shot |
| 02:36.02 | dli | starseeker, revision 45982 |
| 02:36.16 | dli | starseeker, testing now |
| 02:36.23 | starseeker | that works for me here with system tcl/tk and itcl/itk - I don't have a system iwidgets, tkhtml, tkpng or tktable |
| 02:36.53 | starseeker | the raster toolkit, opennurbs and STEP Class Libraries will stay on because we're currently maintaining our own versions of those |
| 02:38.02 | starseeker | dli: also, remember the cmake options have changed a lot - still probably in flux, actually |
| 02:40.35 | dli | starseeker, this is reported configure options: |
| 02:40.38 | dli | starseeker, http://pastebin.com/g7dD2VMP |
| 02:41.21 | starseeker | hmm - surprized the optimized release summary option isn't printing |
| 02:41.36 | starseeker | is that a clean configure from a fully updated trunk? |
| 02:41.53 | starseeker | what configure options are you passing in? |
| 02:42.37 | bhinesley | starseeker: builds fine, thanks |
| 02:43.40 | dli | starseeker, options passed to cmake: http://pastebin.com/h3ELaNfD |
| 02:44.16 | starseeker | dli: ah, let me translate those |
| 02:44.58 | starseeker | dli: will gentoo accept a BRL-CAD build of tkhtml? |
| 02:46.08 | dli | starseeker, should be fine, since there's no tkhtml package in gentoo yet |
| 02:46.50 | starseeker | they don't want static libs? |
| 02:48.36 | dli | starseeker, I think it's ok, but they want to be sure about how libs are used/linked, so, package manager can avoid broken libraries better, package deps better |
| 02:50.34 | starseeker | dli: um - surprised you turned off the example geometry - is that a policy? |
| 02:51.04 | starseeker | with EXTRADOCS off, the html documentation won't be available |
| 02:51.56 | dli | starseeker, it's controlled by USE flag: examples |
| 02:52.43 | dli | starseeker, http://pastebin.com/7ndb9WDQ |
| 02:53.16 | dli | starseeker, so, USE="doc" will enable extradocs, extradocs_pdf, extradocs_man |
| 02:54.20 | dli | starseeker, aqua, does brlcad support aqua? |
| 02:54.35 | starseeker | no |
| 02:55.41 | dli | starseeker, then, it's a mistake |
| 02:58.02 | starseeker | what are you specifically setting up with the Gentoo build type? |
| 02:58.22 | starseeker | we generally have Debug and Release - I haven't tried feeding in something else |
| 02:59.30 | dli | starseeker, only debug and release, if USE="debug" it's Debug, otherwise Release |
| 02:59.49 | starseeker | you're passing in CMAKE_BUILD_TYPE=Gentoo though |
| 03:00.25 | dli | starseeker, it must be from the gentoo default :( need to disable that then |
| 03:00.42 | starseeker | dli: well, it might work - just completely untested |
| 03:01.21 | starseeker | dli: this is closer, given our current state: http://pastebin.mozilla.org/1300959 |
| 03:01.31 | starseeker | you can see what happens with that |
| 03:02.07 | starseeker | I will test with a "nonsense" build type setting and see what happens once... |
| 03:03.29 | starseeker | ah, that's why the optimize and debug flags were not set |
| 03:04.15 | dli | starseeker, I can try to set default build type to Release, then, if USE=Debug, set it to Debug |
| 03:04.44 | starseeker | dli: I wouldn't worry too much about the pdf doc building just yet - if you still want to enable it, the options are BRLCAD_EXTRADOCS_PDF and BRLCAD_EXTRADOCS_PDF_MAN |
| 03:04.54 | starseeker | remember Apache FOP is needed for that |
| 03:05.24 | starseeker | dli: well, a non-standard build type should still do SOMETHING sane |
| 03:05.43 | starseeker | I'm not sure how successful we'd be fighting with the gentoo guys about that |
| 03:06.09 | dli | starseeker, BRLCAD_EXTRADOCS_PDF and BRLCAD_EXTRADOCS_PDF_MAN were already in the package script |
| 03:06.40 | starseeker | ah, k |
| 03:07.10 | dli | starseeker, the complete gentoo package (ebuild) for the svn live version: http://paste.pocoo.org/show/458500/ |
| 03:10.34 | CIA-62 | BRL-CAD: 03starseeker * r45983 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: Er, oops - fix default fallback settings for auto_option macro |
| 03:10.55 | starseeker | dli: that should help |
| 03:11.11 | starseeker | or at least, the settings are saner - trying the build now |
| 03:11.58 | starseeker | yeah, this should fall back to the /usr/brlcad path, no optimization and no debug flags by default |
| 03:13.49 | starseeker | note that tcl/tk need to be 8.5 - 8.4 will no longer be enough, IIRC (ttk widgets, among other issues) |
| 03:14.35 | starseeker | tnt and jama are headers, and if I'm remembering right we need our local copies |
| 03:14.46 | starseeker | shouldn't be a build issue at all |
| 03:15.09 | starseeker | (as far as conflicting with a system install anyway, unless we're copying those into our install tree - I'd need to check.) |
| 03:18.39 | dli | starseeker, building, let's see how it works out |
| 04:02.55 | starseeker | dli: any luck? |
| 18:08.28 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 18:08.28 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 18:10.43 | CIA-62 | BRL-CAD: 03starseeker * r45990 10/brlcad/trunk/src/archer/archer: |
| 18:10.43 | CIA-62 | BRL-CAD: Warn if we appear to be running archer from a non-install directory with an |
| 18:10.43 | CIA-62 | BRL-CAD: install already in place - this is the situation where .tcl files will get |
| 18:10.43 | CIA-62 | BRL-CAD: pulled from /usr/brlcad/* instead of local copies, which if unnoticed by the |
| 18:10.43 | CIA-62 | BRL-CAD: developer makes for some very frustrating troubleshooting (particularly for |
| 18:10.44 | CIA-62 | BRL-CAD: those not familiar with bu_brlcad_root's behavior). We have enough information |
| 18:10.45 | CIA-62 | BRL-CAD: to spot this situation at runtime, so do it. |
| 18:12.54 | bhinesley | starseeker: alright. Their verbage was a bit strong/misleading. |
| 18:18.49 | starseeker | bhinesley: they have to write that for borderline cases where a student might be trying to sprint right at the end and shoves so much code at a mentor right before the eval that they *can't* properly evaluate it |
| 18:19.43 | bhinesley | ah |
| 19:06.42 | kunigami1 | just wondering: is it feasible to pack boost compressed in the osl code? the 7ziped version has ~40MB |
| 19:07.14 | starseeker | kunigami1: um. you couldn't extract the parts you need? |
| 19:07.47 | kunigami1 | I still can't. I tried with 1.46.1. I'm currently trying with 1.47.0 |
| 19:08.24 | kunigami1 | I asked in boost dev list, but the guy suggested to me exactly what I did |
| 19:09.32 | CIA-62 | BRL-CAD: 03tbrowder2 * r45991 10/brlcad/trunk/sh/conversion.sh: add a SAVE option to keep converted tgm from being deleted |
| 19:12.38 | CIA-62 | BRL-CAD: 03tbrowder2 * r45992 10/brlcad/trunk/NEWS: documented change for users |
| 20:22.43 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 20:30.48 | *** join/#brlcad merzo (~merzo@137-79-132-95.pool.ukrtel.net) | |
| 21:05.07 | kunigami1 | good, seems that was a bug with boost 1.46. let me see if oiio and osl compile with this smaller version |
| 21:15.56 | plaes | gotta love git-send-email \o/ |
| 21:25.58 | *** join/#brlcad KimK_ibmlaptop (~kkirwan@209.248.147.2.nw.nuvox.net) | |
| 22:08.59 | CIA-62 | BRL-CAD: 03starseeker * r45993 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Don't try adding the debug flag manually if it's Xcode - let Xcode itself handle things. Trying it manually caused an options conflict. |
| 22:55.28 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 23:03.09 | CIA-62 | BRL-CAD: 03starseeker * r45994 10/brlcad/trunk/src/tclscripts/rtwizard/lib/PictureTypeBase.itcl: rt isn't always in the path. Use the bu_brlcad_root, rtwizard. |
| 23:07.40 | CIA-62 | BRL-CAD: 03starseeker * r45995 10/brlcad/trunk/NEWS: |
| 23:07.40 | CIA-62 | BRL-CAD: rtwizard was relying on rt being present in the system path in order to run it |
| 23:07.40 | CIA-62 | BRL-CAD: and generate a picture - instead, have it find and use the rt command specific |
| 23:07.40 | CIA-62 | BRL-CAD: to its own BRL-CAD release without needing rt to be in the path. |
| 23:15.24 | *** join/#brlcad merzo (~merzo@250-21-132-95.pool.ukrtel.net) | |
| 23:17.12 | bhinesley | how do I get the natural origins of primitives? |
| 23:17.20 | bhinesley | cries uncle |
| 23:22.40 | CIA-62 | BRL-CAD: 03starseeker * r45996 10/brlcad/trunk/src/tclscripts/rtwizard/lib/PictureTypeBase.itcl: |
| 23:22.41 | CIA-62 | BRL-CAD: Wow. Apparently the only reason rtwizard wouldn't output png ouput if you |
| 23:22.41 | CIA-62 | BRL-CAD: specified a .png extension was due to its regarding the filename as a |
| 23:22.41 | CIA-62 | BRL-CAD: framebuffer (-F) target instead of an output file (-o). Literally a one |
| 23:22.41 | CIA-62 | BRL-CAD: character fix, and rtwizard will now output png files if given a .png filename. |
| 23:22.57 | starseeker | bhinesley: "natural origins?" |
| 23:23.14 | bhinesley | yes, that's what brlcad called it |
| 23:23.37 | bhinesley | as opposed to the bounding box center... he said that there is a natural starting point of primitives |
| 23:23.39 | starseeker | uh. is that the point that (say) the sed command grabs from a primitive? |
| 23:23.42 | starseeker | oh |
| 23:24.22 | bhinesley | I'm not sure, I'll have to look at sed |
| 23:24.35 | starseeker | would suggest checking what sed does |
| 23:24.46 | starseeker | that'd be my fist step anyway |
| 23:24.50 | starseeker | first step even |
| 23:25.08 | starseeker | (probably be shaking a fist at it too, come to think of it...) |
| 23:25.23 | bhinesley | heh |
| 23:26.10 | starseeker | look for f_sed in chgview.c in mged |
| 23:26.20 | bhinesley | ok |
| 23:27.23 | starseeker | hmm... that doesn't help much... |
| 23:28.45 | bhinesley | I guess that's the problem, starseeker; I don't really know what I'm looking for |
| 23:29.06 | starseeker | bhinesley: that's a little outside my expertice also - let me dig a minute |
| 23:29.20 | bhinesley | alright, thank you |
| 23:33.29 | starseeker | you might try looking at curr_e_axes_pos being set in edsol.c |
| 23:35.14 | starseeker | ah hah! |
| 23:35.23 | starseeker | get_solid_keypoint, edsol.c 9222 |
| 23:36.38 | bhinesley | looking |
| 23:37.09 | bhinesley | looks promising; I was thinking that it would have to be different for each primitive type |
| 23:37.24 | bhinesley | retrieving it, I mean |
| 23:38.19 | starseeker | winces - OK, if that's actually it, the options are 1) make a libged version of that 2) refactor it into per-primitive calls via the functable (a better way but more time-consuming) 3) ask brlcad what to do (the best way but probably the most work :-P) |
| 23:38.44 | bhinesley | hahaha @3 |
| 23:39.30 | starseeker | I'd say start with 1) for now (lord knows we've got lots of logic like that in there that needs cleanup) and see if you can get it to actually work |
| 23:39.57 | starseeker | if that's what we need, then it'll be already isolated from mged and easier to use for the "right thing" refactoring step |
| 23:42.21 | bhinesley | ok, it doesn't sound so bad |
| 23:50.57 | brlcad | starseeker: regarding r45996, does rtwizard's preview option still work? |
| 23:51.51 | starseeker | I believe so... |
| 23:52.33 | starseeker | tests |
| 23:52.50 | starseeker | oh, wait - point |
| 23:52.54 | starseeker | it might not... |
| 23:54.12 | starseeker | crud, yeah no dice |
| 00:01.57 | brlcad | basically it's a double-use variable so you'll have to conditionalize somewhere, even if you split it into two variables |
| 00:02.37 | brlcad | unless you change the logic to always go to a -o output file then pix-fb that file |
| 00:02.54 | brlcad | but then you'll need rm logic if it's a preview too |
| 00:03.12 | brlcad | nothing at all tricky, but not a one-character fix ;) |
| 00:03.33 | brlcad | OSL solids up from siggraph: http://s2011compilers.org |
| 00:04.13 | brlcad | unfortunately, he pulled the cool images from alice in wonderland and the amazing spider man that showed OSL in production use |
| 00:07.55 | brlcad | bhinesley: heh, either of those options sound fine -- you only need to push the logic up into libged, but if you want to push it further (up into librt or into librt's individual primitives), even better |
| 00:08.55 | brlcad | anytime there is a switch or if table that itemizes primitives, that is a clear indicator of functionality that need to be refactored up into librt |
| 00:09.25 | brlcad | so that is the long-term goal, libged gets that code one step closer so it's still an improvement if that's as far as you take it |
| 00:11.09 | bhinesley | brlcad: alright. If moving it to libged is supposedly easier, then I should probably do that for now. I don't want to get sidetracked from edit/translate just yet. |
| 00:11.16 | brlcad | plaes: thanks for the patches, will review |
| 00:14.37 | brlcad | kunigami: if it works compressed, just commit it uncompressed then .. the size isn't critical, it just doesn't seem "right" if it's huge huge |
| 00:16.29 | brlcad | bhinesley: as for the "required to stop", you have it spot on -- that's just for the official code tarball that has to be uploaded to google, you dont' have to stop coding in the least |
| 00:17.34 | brlcad | technically, you're being paid to "test google upload infrastructure" .. that's how they legally pay students for work that they don't directly evaluate |
| 00:18.04 | bhinesley | brlcad: interesting |
| 00:18.45 | brlcad | yeah, it's pretty funny |
| 00:19.49 | brlcad | bhinesley: oh and libged is going to be easier because it's almost as simple as move block of code from mged to libged .. whereas to put it into librt properly would require adding a function to each individual primitive |
| 00:20.07 | brlcad | maybe two hours difference, but more work nonetheless |
| 00:20.18 | bhinesley | ah, I see. the "OOP interface" |
| 00:20.41 | brlcad | nods |
| 00:20.52 | CIA-62 | BRL-CAD: 03starseeker * r45997 10/brlcad/trunk/src/tclscripts/rtwizard/lib/ (FbPage.itk PictureTypeBase.itcl): Ah, not quite so simple - the same command feeds both the preview and the file-out operations, so we need to accomidate both. |
| 00:21.30 | starseeker | brlcad: there we go - both preview and png output |
| 00:22.02 | brlcad | you left a debug puts ;) |
| 00:23.20 | starseeker | picky picky... :-P |
| 00:23.40 | CIA-62 | BRL-CAD: 03starseeker * r45998 10/brlcad/trunk/src/tclscripts/rtwizard/lib/PictureTypeBase.itcl: remove stray debug output |
| 00:26.47 | starseeker | brlcad: does rtwizard work on Windows? |
| 00:27.24 | starseeker | probably shouldn't ask that... |
| 00:28.43 | starseeker | brlcad: something up with those BU_ASSERT changes you made, by the way... |
| 00:31.27 | CIA-62 | BRL-CAD: 03starseeker * r45999 10/brlcad/trunk/NEWS: |
| 00:31.27 | CIA-62 | BRL-CAD: rtwizard can output png files now, handing it the same way rt itself does (use |
| 00:31.27 | CIA-62 | BRL-CAD: .png as the file name suffix). Was primarly a matter of distinguishing between |
| 00:31.27 | CIA-62 | BRL-CAD: framebuffer and file targets - previously the 'file output' was just a |
| 00:31.27 | CIA-62 | BRL-CAD: framebuffer dump to a file. |
| 00:32.02 | CIA-62 | BRL-CAD: 03bhinesley * r46000 10/brlcad/trunk/src/libged/edit.c: Changing memory allocations for structs to use BU_GETSTRUCT. Simplified/reduced some things. Added some error checking. Nothing major. |
| 00:32.17 | CIA-62 | BRL-CAD: 03starseeker * r46001 10/brlcad/trunk/TODO: png in rtwizard, check. |
| 00:32.46 | brlcad | starseeker: understood -- investigating, they should have been good to go as I was pretty careful but "-1" is a special case |
| 00:33.01 | starseeker | brlcad: thanks |
| 00:33.03 | brlcad | that might be what is causing the current problem even, just in a different way |
| 00:33.33 | brlcad | it writes out a -1 to mean "this is an identity matrix, don't write it out" |
| 00:34.35 | CIA-62 | BRL-CAD: 03bhinesley * r46002 10/brlcad/trunk/src/libged/ (CMakeLists.txt Makefile.am get_solid_kp.c): Migrating edit/edsol.c:get_solid_keypoint() to libged. It compiles cleanly, but is otherwise untested. |
| 00:36.56 | starseeker | brlcad: how were you figuring to do the temp color thing for rtwizard? |
| 00:39.06 | brlcad | plaes: would like to talk about your libfft patches when you got a sec, questions 1) what's the impact (performance, correctness) using fftw3.. our used to be much faster; 2) configure.ac can't call PKG_* macros and that build system is deprecated anyways, cmake build is where the action is at (which I see you had a separate patch for); 3) again performance check, the fixed size convolutions are highly optimizable .. what's the impact? |
| 00:39.13 | brlcad | starseeker: options to rt |
| 00:39.42 | brlcad | probably set variables |
| 00:39.50 | starseeker | erm. don't know that trick |
| 00:40.43 | brlcad | basically, get it to work with rt first, rtwizard just calls rt |
| 00:40.59 | starseeker | nods |
| 00:41.06 | brlcad | rtwizard needs some gui interface to set/unset the colors |
| 00:41.15 | brlcad | but then those just turn into command line opts |
| 00:41.32 | starseeker | are the rt options already in place to override colors? |
| 00:41.35 | brlcad | do you know how rtedge options work? same basic idea |
| 00:42.02 | brlcad | no, they're not -- that's pretty much 90% of the task |
| 00:42.15 | brlcad | the rtwizard gui part is nothing |
| 00:42.44 | starseeker | right |
| 00:44.08 | brlcad | bhinesley: oof! .. so "moving code" probably wasn't the best term to use |
| 00:44.18 | brlcad | those globals gotta go |
| 00:44.59 | brlcad | the statics will need to be non-static since libged is supposed to be stateless |
| 00:45.09 | brlcad | that may or may not break it |
| 00:45.38 | brlcad | params should be const that can be const |
| 00:46.15 | brlcad | mged gets away with a lot of shit that isn't tolerated for libged (as that is the entire point of the library, clean refactoring) |
| 00:47.10 | brlcad | finally, function should be added to ged_private.h (and renamed) so it doesn't accidentally become public libged api |
| 00:48.49 | bhinesley | brlcad: alright |
| 00:48.56 | bhinesley | still, I'll see if I can get it working first |
| 00:53.30 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 00:53.35 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 01:19.46 | CIA-62 | BRL-CAD: 03starseeker * r46003 10/brlcad/trunk/ (3 files in 3 dirs): Need to make the FindGL logic match up with the FindX11 logic to make sure the two are in sync. Needs more testing. |
| 01:27.45 | CIA-62 | BRL-CAD: 03starseeker * r46004 10/brlcad/trunk/misc/CMake/ (BRLCAD_Util.cmake ThirdParty_TCL.cmake): more case correction logic is needed - try this. |
| 02:04.13 | CIA-62 | BRL-CAD: 03bhinesley * r46005 10/brlcad/trunk/src/libged/ (ged_private.h get_solid_kp.c): Make compliant with libged standards (rm global/static vars). Declare in ged_private. Temporarily disable support for ARS/BSPLINE, which will require a little more work. |
| 02:05.09 | CIA-62 | BRL-CAD: 03bhinesley * r46006 10/brlcad/trunk/src/libged/get_solid_kp.c: remove (temporary) cast to void |
| 02:11.47 | CIA-62 | BRL-CAD: 03bhinesley * r46007 10/brlcad/trunk/src/libged/edit.c: Enabled support for using the natural origins of primitives as a reference point. |
| 02:13.18 | bhinesley | starseeker: Thank you, again, for helping me with that. I doubt that I would have been able to figure that out any time soon. |
| 02:29.07 | starseeker | bhinesley: np - that's what mentors are for :-) |
| 02:29.32 | starseeker | bhinesley: you've got the fun part - turn it into a viable libged function |
| 02:33.20 | bhinesley | starseeker: well it seems to work just fine. Just need to make ARS/BSPLINE work; they used a couple globals that were set elsewhere. Making mged call the libged version is another matter. |
| 02:35.22 | brlcad | bhinesley: looks much better, nice work :) |
| 02:36.18 | bhinesley | brlcad: great, thanks! |
| 02:36.51 | CIA-62 | BRL-CAD: 03bhinesley * r46008 10/brlcad/trunk/src/libged/edit.c: Yikes; dynamically allocate a character buffer since _ged_get_solid_kp() writes to it. |
| 02:37.24 | brlcad | where's that string freed? :) |
| 02:37.38 | bhinesley | ... in the code I'm about to write because you said that |
| 02:37.45 | brlcad | heh |
| 02:38.23 | brlcad | also very minor point, but recommend bu_calloc unless you're in some performance-critical loop |
| 02:38.40 | bhinesley | okay; why is that? |
| 02:38.49 | *** part/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 02:38.51 | brlcad | zero-initialized memory |
| 02:39.02 | bhinesley | right, but why? |
| 02:39.52 | brlcad | in general, zero-initialized memory is much faster at exposing initialization/deinitialization bugs in code |
| 02:40.10 | bhinesley | ah |
| 02:40.26 | brlcad | some compilers will even make malloc() zero-initialize by default unless you turn on -O# optimization level |
| 02:40.36 | brlcad | for that same reason |
| 02:41.40 | brlcad | but the standard doesn't require it, so it's better practice to do it intentionally yourself, then you also have the added benefit that you can test for nullity or 0-values |
| 02:41.53 | CIA-62 | BRL-CAD: 03bhinesley * r46009 10/brlcad/trunk/src/libged/edit.c: Forgot to free string. |
| 02:42.03 | brlcad | r46008 leaks memory, btw ;) |
| 02:42.22 | brlcad | and r46009 should make it crash ;) |
| 02:48.26 | starseeker | make a note of these slides - http://www.slideshare.net/ckleclerc/2011-nasa-open-source-summit-david-wheeler |
| 02:49.02 | CIA-62 | BRL-CAD: 03bhinesley * r46010 10/brlcad/trunk/src/libged/edit.c: Use *calloc* and *sizeof* like the grown-ups. |
| 02:49.50 | bhinesley | alright, wth |
| 03:00.11 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 03:00.21 | starseeker | bhinesley: problem? |
| 03:01.11 | bhinesley | NO. heh. Dumb mistake that I am not able to fix instantly for some reason. |
| 03:02.01 | brlcad | bhinesley: need a hint? |
| 03:02.25 | bhinesley | nah, then I will feel even stupider |
| 03:02.52 | starseeker | bhinesley: you might as well - it saves time, and I need those hints all the time :-P |
| 03:03.02 | bhinesley | sighs |
| 03:03.21 | bhinesley | Alright. brlcad, is it because I need to use bu_strlcpy? |
| 03:03.25 | brlcad | how would I know that r42009 will crash? |
| 03:04.35 | brlcad | that should take you down the rabbit hole |
| 03:05.42 | brlcad | damn server shut down during my latest nurbs performance testing after about 80% completion .. arf |
| 03:05.53 | starseeker | winces |
| 03:16.33 | starseeker | bhinesley: try stepping through with a debugger (I'd start with the char *str; line) |
| 03:24.06 | CIA-62 | BRL-CAD: 03starseeker * r46011 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: Er, oops - normalize, THEN check. |
| 03:24.58 | brlcad | nifty, some oklahoma country music show wants to use our logo contest rules |
| 03:25.21 | starseeker | hah, awesome |
| 03:28.53 | starseeker | bhinesley: focus on why brlcad said 46008 leaks memory |
| 03:31.05 | starseeker | brlcad: should we revert that BU_ASSERT size_t change for now? it crashes on my gentoo box too |
| 03:33.06 | starseeker | dli: hah - saw the brlcad-9999 ebuild appear in one of the overlay updates :-) |
| 03:34.35 | dli | starseeker, still, 7.20.2 cmake version doesn't work |
| 03:34.46 | dli | starseeker, I mean to build with system tcl/tk |
| 03:35.05 | starseeker | dli: even with the patches to cmake? |
| 03:35.22 | starseeker | well, presumably 7.20.4 will |
| 03:36.00 | dli | starseeker, I can remove the 7.20.2 cmake ebuild for the time being |
| 03:36.33 | brlcad | starseeker: working on the BU_ASSERT now, it should be something obvious |
| 03:36.42 | brlcad | s/now/for a lil bit now/ |
| 03:37.05 | starseeker | dli: probably simpler |
| 03:37.45 | starseeker | a cmake patch would be rather... large at this point :-) |
| 03:38.06 | louipc | :o |
| 03:38.30 | louipc | who wins the contest by the way? |
| 03:39.18 | louipc | is looking forward to seeing the logos. |
| 03:42.46 | starseeker | sweet - bzflag ebuild now updated to 2.4 :-) |
| 03:42.54 | dli | starseeker, I will ask someone to review the package and update the gentoo main tree |
| 03:47.22 | CIA-62 | BRL-CAD: 03bhinesley * r46012 10/brlcad/trunk/src/libged/edit.c: Ptr to string, not pointer to char. |
| 03:48.09 | CIA-62 | BRL-CAD: 03bhinesley * r46013 10/brlcad/trunk/src/libged/get_solid_kp.c: Enable BSPLINE support. |
| 04:01.48 | brlcad | bhinesley: that's nfg |
| 04:03.04 | brlcad | str only needs to be a char* |
| 04:06.07 | brlcad | r46012 technically avoids the crash on free, but doesn't fix the problem -- you were closer with bu_strlcpy() thinking |
| 05:02.40 | CIA-62 | BRL-CAD: 03bhinesley * r46014 10/brlcad/trunk/src/libged/edit.c: Don't dynamically allocate string. |
| 05:08.22 | starseeker | bhinesley: doesn't get_solid_keypoint still need to write to str? |
| 05:09.55 | bhinesley | apparently I don't know what the fuck I'm doing. |
| 05:10.33 | starseeker | bhinesley: stay calm :-) |
| 05:10.54 | starseeker | we've all made our share of this kind of mistake |
| 05:11.50 | starseeker | don't give up - think about what brlcad said about 46008 and 46009 |
| 05:15.21 | starseeker | bhinesley: sometimes in situations like this it's helpful to make your own isolated C file and just try to get it to do the one thing you're working on |
| 05:22.08 | plaes | brlcad: awake now |
| 05:22.17 | plaes | lives in UTC+2 |
| 05:24.48 | CIA-62 | BRL-CAD: 03bhinesley * r46015 10/brlcad/trunk/src/libged/edit.c: keep a copy of original ptr to free |
| 05:39.48 | plaes | brlcad: fftw - 1) tried benchmarking it, didn't notice much difference (maybe I need some bigger models to test with) |
| 05:41.22 | plaes | fftw - 2) Why cannot it call the PKG_* macros? autoconf works for me.. for cmake the paths to detect fftw and add it to libraries is missing |
| 05:45.04 | plaes | and 3) fftw chooses different algorithms baased on the size, we had currently only "faster variant for length 256 |
| 05:46.10 | plaes | IIRC, it uses faster algorithms for all powerof two sizes |
| 06:41.03 | CIA-62 | BRL-CAD: 03bhinesley * r46016 10/brlcad/trunk/src/libged/get_solid_kp.c: Disable BSPLINE again... it's not working |
| 06:46.55 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3078 10/wiki/User:Bhinesley: /* Log */ today |
| 06:51.58 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 07:22.42 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 09:05.16 | *** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 09:18.31 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 12:33.50 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 13:07.38 | kunigami | brlcad: the first time I tried uploading the full boost, the commit was interrupted. (I'm almost sure that was not my connection that failed) does sourceforge has some kind of cap? |
| 13:08.58 | plaes | you want to bundle whole boost library? |
| 13:09.41 | kunigami | that was not the first idea, but I'm having troubles in selecting only the required subset |
| 13:09.57 | plaes | :S |
| 13:11.58 | starseeker | bhinesley: closer, but you're still passing in str to get_solid_keypoint - you want to pass in the buffer (that's the whole point of mallocing it in the first place) |
| 13:12.15 | kunigami | I had advances and managed to copy but now I'm stuck with a build error. probably the build scripts were not copied properly. I'll report to boost dev's list |
| 13:13.18 | starseeker | bhinesley: look at other parts of the code that are working with buffers and string assignment |
| 13:13.24 | CIA-62 | BRL-CAD: 03kunigami * r46017 10/osl/trunk/boost_1_46_1/: deleting initial boost commits |
| 13:13.31 | plaes | most of the times bundled libraries cause more damage than they fix.. (security issues, etc..) |
| 13:14.01 | starseeker | plaes: we will use system libs by default in our configuration if they are available |
| 13:14.28 | starseeker | but if not, we have to be able to fall back on our local versions rather than fail to build |
| 13:14.59 | plaes | well, boost is quite popular library |
| 13:15.09 | plaes | most of the distros have it |
| 13:16.05 | starseeker | windows is often where we end up needing local copies of things |
| 13:16.38 | plaes | yeah, package management in windows sucks :( |
| 13:17.04 | starseeker | there are other issues too (Tcl/Tk on OSX is not built for X11, which we currently need) |
| 13:18.30 | starseeker | the linux distros always hate bundling (and generally I agree with them) but in the case of something like BRL-CAD we can't always wait for the system to catch up |
| 13:19.04 | starseeker | (for example, a lot of linux distros will still put tcl/tk 8.4 on by default, which is too old for us now) |
| 13:19.48 | kunigami | interesting |
| 13:23.45 | starseeker | or there's the package dli is working on for gentoo - they don't have a tkhtml ebuild, but we're using that now for our doc viewing system |
| 13:24.40 | plaes | yeah, I'm using Gentoo too, though I'm compiling my own |
| 13:25.10 | plaes | ah, dli is the one who maintains it |
| 13:25.16 | starseeker | is also a gentoo user |
| 13:26.11 | plaes | dlbtw, I fixed dev-tcl/itk to install itkConfig.sh file ;) |
| 13:27.01 | dli | plaes, but 7.20.2 is still not in main tree, I don't have access to main tree, only the sci-overlay |
| 13:27.29 | plaes | dli: why does it depend explicitly on java? |
| 13:28.30 | plaes | also, Calculating dependencies - * A file is not listed in the Manifest: '/var/lib/layman/science/media-gfx/brlcad/brlcad-7.20.2-r1.ebuild' |
| 13:29.16 | dli | plaes, the dependency on java is removed already for cmake version :( |
| 13:29.56 | dli | plaes, weird |
| 13:29.57 | ``Erik | BRL-CAD does have a JNI interface in src/librtserver that requires the java headers and libraries, and I believe the pdf docs require apache fop which is a java program |
| 13:30.23 | dli | plaes, sorry, my fault, forgot to check git ls-files |
| 13:31.02 | starseeker | wants to build a desktop with one of those new AMD 12 core processors :-) |
| 13:31.43 | dli | plaes, fixed in overlay |
| 13:32.11 | plaes | it works nice, now if you could add java USE flag too ;) |
| 13:32.12 | dli | starseeker, in 5 years, netbooks will have that many cores :) |
| 13:34.19 | dli | plaes, I will do that, need some time to test it though |
| 13:34.29 | starseeker | is still stuck on two at the moment - house keeps breaking, so minor things like CPU core count take a backseat |
| 13:36.20 | ``Erik | pats his 650mhz p3 O.o |
| 13:37.04 | dli | ``Erik, I run an amd (athlon-4 k7) 500MHz |
| 13:39.52 | starseeker | if I can't emerge world from scratch in less than a minute the machine isn't powerful enough :-P |
| 13:41.18 | dli | starseeker, I use ebuild qmerge to testing, so, easier than atomic emerge |
| 13:45.17 | starseeker | dli: cool. nice work, bty - thanks for the time you're putting in |
| 13:45.34 | starseeker | has some experience with gentoo integration and knows it ain't so simple |
| 13:46.24 | starseeker | saddles up and heads out |
| 13:54.59 | plaes | wow, you guys can then test my fftw patchset ;) |
| 14:14.10 | CIA-62 | BRL-CAD: 03erikgreenwald * r46018 10/brlcad/trunk/include/bu.h: add BU_ASSERT_SSIZE_T |
| 14:14.47 | CIA-62 | BRL-CAD: 03erikgreenwald * r46019 10/brlcad/trunk/src/librt/comb/comb.c: Change mi to ssize_t since we store -1 as a magic value and do a < in the assertion. |
| 14:28.42 | dli | starseeker, JavaVM/jni.h - not found, the icedtea6 jni.h is /opt/icedtea6-bin-1.10.3/include/jni.h |
| 14:56.13 | kunigami | is there anyway to be warned by subversion when I'm adding a file which does match any pattern on config file? |
| 14:57.04 | kunigami | Currently, it causes error when I'm already commiting and this way I have to reverse |
| 14:57.16 | kunigami | *revert |
| 14:58.09 | kunigami | (I'm referring to those mime types) |
| 15:00.38 | ``Erik | typically, it'll complain that you need to set the svn:mime-type and svn:eol-style |
| 15:01.22 | kunigami | yup, but I'd like it to complain when I'm adding the files, not when committing. |
| 15:25.16 | bhinesley | starseeker: _ged_get_solid_keypoint takes a char**. It changes what *str points to. That's one of the reasons why it was crashing when I attempted to free. There really is not point in allocating space; it never writes to it. |
| 15:27.30 | bhinesley | _get_get_solid_keypoint does things like *str = "V";, which was throwing me off. (*str = "V") != ((*str)[0] = 'V') |
| 15:29.13 | bhinesley | so, silly enough, my first commit with "char *str = "V";" actually worked just fine |
| 15:35.29 | brlcad | right, as long as you don't try to free(str) or write to str, but you could pass &str to a char ** argument and repoint str to something else |
| 15:36.32 | bhinesley | that's what I ended up doing when I realized that the pointer had changed |
| 15:36.36 | brlcad | plaes: computing a fft is a pretty quick operation these days so you'd probably want to perform a 256x256 convolution a few million times in a loop, compare before/after |
| 15:37.33 | brlcad | plaes: PKG macros are only available if pkg_config is installed, which isn't for many platforms our autotools build supports, but then like I said -- that build system is going away completely in a few months in favor of cmake |
| 15:39.09 | abhi2011 | I have a question about setting up commands in mged, so if a command is to be run through a tcl procedure, then I guess it should not have a entry in the table in mged/setup.c |
| 15:40.07 | abhi2011 | setting up a tcl script in tclscripts/mged should be sufficient, and this should avoid any conflicts with the setup.c mechanism of running commands ? |
| 15:41.40 | bhinesley | abhi2011: meaning a purely Tcl command? |
| 15:41.41 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 15:41.57 | brlcad | kunigami: not sure about getting svn to warn when it *doesn't* match a pattern.. though it's not clear what error you'd run into that begs a revert -- if it aborts saying mime types aren't set, you can just set the mimetypes and try again until they're all set |
| 15:42.26 | abhi2011 | bhinseley: no the logic for the command is in a c file and I have been running it so far using an entry in setup.c |
| 15:42.39 | abhi2011 | so its not a pure tcl command |
| 15:43.03 | abhi2011 | what I want is to call the command multiple times from a tclscript |
| 15:43.07 | brlcad | plaes: java is not required, it just builds a jni binding library if it's detected .. if an ebuild specified it as required, that could be simplified/removed |
| 15:44.15 | kunigami | brlcad: I need to add an entry to .subversion/conf when it gives an error. But this will only make effect if I revert and add the file again. The reason I'm complaining is that if I'm adding to much code, it takes a lot of time before raising an error. I'm writing a simple script by now |
| 15:44.20 | brlcad | bhinesley: what about just removing the parameter altogether? |
| 15:44.38 | brlcad | if you don't use it, it's just overhead logic that will fall out of sync |
| 15:45.15 | brlcad | abhi2011: you shouldn't need to do anything in tclscripts/mged |
| 15:45.42 | brlcad | you can call it multiple times from a tclscript already |
| 15:46.20 | brlcad | if you just want to avoid typing a test proc many times over, put your logic into a .tcl file and "source file.tcl" to run that proc |
| 15:46.39 | brlcad | calling the command in a loop in order to get interactive updating is not the final form of the command |
| 15:46.48 | brlcad | it's just a short-term workaround |
| 15:47.06 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 15:47.33 | bhinesley | brlcad: I could; it would remove a lot of functionality, since we'd only be able to get one type of point. I'm not sure how it would affect getting the coordinates of a BSPLINE/ARS; I haven't been able to get them to work yet in the first place |
| 15:47.53 | bhinesley | so if I am personally not using it, it should be removed? |
| 15:48.19 | brlcad | bspline is going to be deprecated/removed so a non-issue there |
| 15:48.38 | bhinesley | ok, I'll remove that |
| 15:48.40 | abhi2011 | oh ok, I thought the user would invoke a single command from mged , and then a tclscript corresponding to the command would run to update the position at each step (with the libged command running 1 step each time) |
| 15:48.52 | brlcad | ars just needs to define a point, perhaps the first point .. which it would have had to do anyways for sed |
| 15:49.29 | brlcad | abhi2011: no, soonish, the libged command will run all N time steps.. the tcl script is just so you can see updates in the meantime |
| 15:49.45 | brlcad | getting interactive updating *while* a command is running is going to require a minor modification |
| 15:49.53 | bhinesley | brlcad: it relied on 3 globals (es_ars_crv, es_ars_col, es_pt), which I do not know how to set |
| 15:49.59 | abhi2011 | brlcad: ok I understand |
| 15:50.37 | starseeker | hmm... get solid keypoint apparently allows to select vertex or height. |
| 15:51.16 | starseeker | or the A/B/C points for sph/ell |
| 15:52.08 | starseeker | do we actually use that ability? |
| 15:53.05 | brlcad | bhinesley: quick glance through the code, those are set depending on the editing mode |
| 15:53.22 | brlcad | lemme see if it's obvious how the default is set |
| 15:53.25 | bhinesley | starseeker: addressing me? well, it would be neat to incorporate the use of those points into edit.c, but would make for some even more daunting syntax. As it is, no, I do not use. |
| 15:54.06 | starseeker | bhinesley: more thinking out loud - the ability is in the code, but if we make no use of it it can be removed |
| 15:54.17 | starseeker | default looks like it might be edsol.c:2565 |
| 15:55.32 | bhinesley | starseeker: case ID_ARS doesn't use the string to select which point |
| 15:56.01 | bhinesley | it uses es_ars_crv and es_ars_col, which are both set to -1 in edsol.c (?) |
| 15:56.59 | brlcad | bhinesley: keep in mind that the logic will forever exist in svn (and in mged until it's removed/refactored), so unless you're aiming for the long term proper refactoring (i.e. librt prims) .. you should simplify to just what you need |
| 15:57.45 | bhinesley | brlcad: no problem |
| 15:58.08 | brlcad | starseeker: if you're right, then it looks like you can't push an ARS |
| 15:58.31 | brlcad | so using the first point or average of all ars points would be perfectly adequate |
| 15:58.50 | bhinesley | I've got to step out for a bit, bbl |
| 15:58.55 | brlcad | cya |
| 15:59.00 | brlcad | hits road |
| 16:00.48 | brlcad | hm, cmake build not catching warnings being spit out by atools build |
| 16:01.05 | starseeker | am I missing some flags? |
| 16:01.28 | brlcad | bhinesley: mixing decls and code in edit.c, have to put all decls at the top of a scope for c90 compliance |
| 17:12.22 | bhinesley | brlcad: ah yes, assuming you're referring to the calloc, I was testing and forgot to move that back |
| 17:23.58 | CIA-62 | BRL-CAD: 03bhinesley * r46020 10/brlcad/trunk/src/libged/edit.c: Don't mix decls and code. |
| 17:25.20 | bhinesley | brlcad: saw what you meant. |
| 17:25.29 | plaes | brlcad: did you see my answer to your fftw3 questions? |
| 17:32.57 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 17:34.32 | brlcad | plaes: yes, and I responded back :) |
| 17:35.37 | plaes | ah, didn't scroll up too much |
| 17:36.05 | plaes | s/too/that |
| 17:36.07 | brlcad | <PROTECTED> |
| 17:36.46 | plaes | whoa, cool |
| 17:36.48 | bhinesley | brlcad: neat |
| 17:37.18 | brlcad | you can add your own custom keywords to hilight too, but your nick is a default |
| 17:37.35 | starseeker | <PROTECTED> |
| 17:37.44 | starseeker | is that irssi specific |
| 17:37.53 | brlcad | helps to leave off the leading space there starseeker ... :) |
| 17:37.59 | starseeker | nods |
| 17:38.14 | brlcad | that is a client command, but lots of irc clients support it |
| 17:38.28 | starseeker | sweet |
| 17:38.29 | bhinesley | saw a student in #gsoc send his /nickserv ident command |
| 17:38.38 | bhinesley | ...with hundreds in the room |
| 17:38.39 | starseeker | heh - oops |
| 17:38.44 | brlcad | yeah, happens, then hilarity ensues |
| 17:38.49 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 17:51.32 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 18:05.47 | louipc | like password changing :P |
| 18:15.31 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 18:22.05 | CIA-62 | BRL-CAD: 03brlcad * r46021 10/brlcad/trunk/src/proc-db/: ignore ringworld |
| 18:25.39 | CIA-62 | BRL-CAD: 03bhinesley * r46022 10/brlcad/trunk/src/libged/ (edit.c ged_private.h get_solid_kp.c): Removed **strp parameter of _ged_get_solid_keypoint(), and updated arguments in edit.c. Temporarily disable certain primitive types that we're not yet calculating the keypoint of. |
| 18:31.58 | starseeker | blinks - apparently all ars does is tessellate itself and then call bot routines |
| 18:34.16 | brlcad | yeah, it was the quick and dirty way back in the day when it was being implemented |
| 18:34.20 | brlcad | someone completely intending to go back and improve on it some day |
| 18:35.05 | brlcad | prime example why you shouldn't half-ass anything, that crap lives on much longer that the dev that contributed it |
| 18:35.28 | CIA-62 | BRL-CAD: 03starseeker * r46023 10/brlcad/trunk/src/librt/primitives/ars/ars.c: Been commented out for a long time, svn's got our back if we need it - outta here. |
| 18:35.40 | brlcad | if it's worth doing, do it while it's in context and we'll all waste a little less time |
| 18:36.07 | brlcad | ars is really just a useful input type, describes geometry using waterlines |
| 18:37.39 | brlcad | should be a nice smooth surface, or at least an option like dsp for faceted linear interpolation in addition to smooth |
| 19:10.41 | CIA-62 | BRL-CAD: 03bhinesley * r46024 10/brlcad/trunk/src/libged/get_solid_kp.c: Enable retrieval of natural origin of PIPE and ARBN. Hard coded in a tolerance in ARBN for acceptable distance from point to plane, used in calculating origin. |
| 19:11.21 | bhinesley | I am assuming it is unacceptible to hard code in a tolerance (as in r46024). Where should I get it from? |
| 19:11.21 | CIA-62 | BRL-CAD: 03brlcad * r46025 10/brlcad/trunk/src/other/libpng/Makefile.am: add depends rule, support for 1.7, source our m4 dir |
| 19:14.20 | bhinesley | I should mention that in the original file, it was set via mged_tol.dist |
| 19:16.51 | brlcad | bhinesley: the gedp has a ged_wdbp member that holds tolerance settings for the current database |
| 19:17.09 | bhinesley | oh, cool |
| 19:18.09 | brlcad | see rt_wdb in raytrace.h (and the respective tolerance structs in libbn) |
| 19:21.21 | CIA-62 | BRL-CAD: 03bhinesley * r46026 10/brlcad/trunk/src/libged/get_solid_kp.c: get tolerance from db |
| 19:23.45 | abhi2011 | brlcad: I have modifying the bb function to work on groups and regions : http://bin.cakephp.org/view/1394071764 |
| 19:24.01 | abhi2011 | I am calling rt_gettree() before rt_bound_tree() to evaluate the tree first |
| 19:26.17 | brlcad | abhi2011: excellent! |
| 19:26.19 | brlcad | that's looking better |
| 19:26.47 | brlcad | probably don't need the if (combp->region_flag) conditional if you're going to do the same to both if/else cases |
| 19:27.23 | abhi2011 | ah yes, but I am not sure if both regions and groups will require the same treatment |
| 19:27.29 | abhi2011 | I am testing with a region made as follows in mged r part1.r u rcc2.s - sph2.s |
| 19:27.31 | brlcad | they will :) |
| 19:27.36 | brlcad | regions are combs |
| 19:27.41 | abhi2011 | yes right |
| 19:27.49 | abhi2011 | yes ok |
| 19:27.54 | brlcad | :) |
| 19:28.00 | abhi2011 | well , the thing is when traversing the tree in the rt_bound_tree() call , the first call sees the subtraction operator in tp->tr_op and proceeds smoothly down to the left child |
| 19:28.14 | abhi2011 | however in the left tree where it should find the primitive rcc2.s, it encounters an unknown op 12, I think it should have encountered a tr_op = OP_SOLID for the rcc.s primitive |
| 19:28.28 | abhi2011 | this is probably related to the fact that the rt_gettree() calls reports missing primitives for the region : db_lookup(rcc2.s) failed in /dummy, db_lookup(sph2.s) failed in /dummy, |
| 19:28.59 | brlcad | yeah, that's exactly why |
| 19:29.08 | brlcad | you need more than just the comb put into the inmem |
| 19:29.26 | abhi2011 | ok |
| 19:29.30 | brlcad | you have to put the whole hierarchy |
| 19:30.11 | brlcad | db_functree() is good for that |
| 19:30.15 | abhi2011 | ok, umm so I should use dbi_walk_tree() and register callbacks |
| 19:30.17 | abhi2011 | oh ok |
| 19:30.17 | brlcad | see src/libged/keep.c |
| 19:30.49 | brlcad | the 'heep' command does the same thing you need to do except it writes to a file and you need to write to the inmem |
| 19:31.06 | brlcad | er, "keep" command |
| 19:31.29 | abhi2011 | ah , ok |
| 19:32.20 | *** join/#brlcad dli (~dli@66.49.191.45) | |
| 19:32.39 | brlcad | hm, abhi2011 but wasn't the point of the inmem so you could call rt_gettrees on it? |
| 19:32.50 | brlcad | which only applied to primitives |
| 19:33.19 | brlcad | why not just call rt_bound_tree() directly with the same (non-inmem) dbip? |
| 19:33.42 | abhi2011 | well yes, for primitives I do call rt_bound_tree() directly |
| 19:33.54 | abhi2011 | or rather |
| 19:34.01 | abhi2011 | no I dont |
| 19:34.16 | abhi2011 | its rt_gettree() which is sufficient |
| 19:34.23 | brlcad | right |
| 19:34.37 | abhi2011 | however for combs, the rt_gettree() is not sufficient |
| 19:34.45 | abhi2011 | but i havent tried rt_gettrees() |
| 19:34.56 | abhi2011 | maybe that will work |
| 19:35.08 | brlcad | er, that's not my point |
| 19:35.53 | brlcad | okay, so the problem is a bit convoluted because you lost the caller's rt_db_internal pointer |
| 19:36.05 | brlcad | first step, make that first parameter const |
| 19:36.07 | abhi2011 | yes :) |
| 19:36.14 | abhi2011 | nope that doesnt work |
| 19:36.18 | brlcad | it can |
| 19:36.26 | abhi2011 | oh ok |
| 19:36.35 | abhi2011 | wdb_put_internal() will be unable to free it then |
| 19:36.39 | brlcad | yep |
| 19:36.45 | brlcad | so you have to do something about that |
| 19:37.18 | abhi2011 | well I have tried with const before but I ll try once more, perhaps I missed something |
| 19:37.22 | brlcad | if you make a copy, then that same ip should be just fine for rt_bound_tree() |
| 19:37.28 | abhi2011 | ok |
| 19:38.11 | brlcad | it might even be easier to deal with primitives differently |
| 19:38.57 | brlcad | instead of using an inmem and calling gettrees(), it might be a lot simpler to fill in an rt_comb_internal yourself with just that one primitive as a leaf node |
| 19:39.22 | brlcad | then you could call rt_bound_tree() the same for any rt_db_internal regardless of it being a primitive or a combination |
| 19:40.08 | abhi2011 | ok yes |
| 19:51.37 | CIA-62 | BRL-CAD: 03brlcad * r46027 10/brlcad/branches/cmake/: remove the cmake branch as it was reviewed and merged back in April/May 2011. trunk is where the action is now. |
| 19:54.00 | *** join/#brlcad dli (~dli@67.55.32.136) | |
| 19:57.43 | brlcad | starseeker: can the goblin branch be killed? |
| 19:57.59 | brlcad | hasn't had activity since early 2010 |
| 20:17.37 | CIA-62 | BRL-CAD: 03brlcad * r46028 10/brlcad/trunk/ (include/raytrace.h src/librt/bbox.c): accept sf patch 3390331 (Addition of a new librt function to return the bounding box) from Abhijit ( abhi2011 ). applies cleanly even if it's still a work in progress. |
| 20:18.39 | abhi2011 | yipee :P |
| 20:18.59 | bhinesley | abhi2011: looking good, I will probably use that to calculate my bb centers :) |
| 20:19.08 | abhi2011 | nice :) |
| 20:22.09 | CIA-62 | BRL-CAD: 03brlcad * r46029 10/brlcad/trunk/AUTHORS: credit abhijit nandy with his code contributions to date, namely efforts to implement a librt routine that calculates bounding boxes for given geometry. (see sf patch 3390331 and 3376910) |
| 20:22.38 | brlcad | abhi2011: so with that, you are now vetted with commit access -- don't break anything ;) |
| 20:23.23 | brlcad | that also means, however, that you should commit the updates you have right away, though, and then continually commit to svn throughout the day while you work and make progress |
| 20:23.50 | brlcad | that makes it a lot easier for other devs to track not only what you are doing, but how and why you arrive at various implementation decisions |
| 20:24.11 | abhi2011 | brlcad: thanks, yes I will be careful :) |
| 20:24.26 | brlcad | just do a good faith effort to make sure you don't break the build, follow the HACKING guidelines, and work with other devs if an issue comes up |
| 20:24.40 | brlcad | abhi2011: and congrats ;) |
| 20:24.57 | abhi2011 | :) haha |
| 20:25.22 | abhi2011 | yah I ll finish the bb functions and test it before my next commit |
| 20:25.44 | abhi2011 | i mean first commit |
| 20:26.31 | brlcad | you're the only one working on that function right now, so if what you have *now* already compiles, you can go ahead and commit it |
| 20:26.39 | brlcad | then test/fix, then recommit, etc |
| 20:26.46 | brlcad | you cannot commit too frequently |
| 20:26.51 | abhi2011 | ok |
| 20:26.59 | brlcad | you can very easily commit too infrequently (and many do) |
| 20:27.23 | brlcad | ftw: svn commit -m "blah blah" my_file.c & |
| 20:27.33 | brlcad | backgrounds the commit with the log message so you can keep coding ;) |
| 20:27.42 | abhi2011 | yes ok |
| 20:27.50 | abhi2011 | been using tortoise svn :P |
| 20:28.04 | brlcad | ah, okay |
| 20:28.24 | abhi2011 | i mean before for other projects , while in windows |
| 20:28.27 | brlcad | that's your perrogative, just don't let the tool slow down your interaction and commits :) |
| 20:28.40 | abhi2011 | yep |
| 20:28.58 | abhi2011 | i have a question regarding the primary data structures |
| 20:29.06 | abhi2011 | used in brl-cad |
| 20:29.39 | abhi2011 | so the tree that the rt_* functions manipulate, thats the main boolean tree used to represent the model |
| 20:29.56 | brlcad | sure, you can look at it that way |
| 20:29.56 | abhi2011 | I mean the union tree* structure |
| 20:30.02 | brlcad | nods |
| 20:30.52 | brlcad | note that those represent the tree for a combination (i.e., a combination represents a boolean recipe) |
| 20:31.16 | brlcad | so primitives don't inherintly have a tree because they don't inherintly have a boolean recipe, they are leaf nodes |
| 20:31.39 | abhi2011 | yes, so the root has the boolean operations being performed on the leaves, for each node , ok but if everthing is present in the tree leaves(which I understand can only be the primitives) then why is there a need to a slid table soltab |
| 20:32.22 | brlcad | a need to what? |
| 20:33.08 | abhi2011 | oops... i meant why is there a need for a solid table called struct soltab |
| 20:33.34 | abhi2011 | it seems to hold extra information about solids in the model |
| 20:33.56 | abhi2011 | but this could have been packed into the union tree nodes |
| 20:34.24 | starseeker | brlcad: sure |
| 20:35.16 | CIA-62 | BRL-CAD: 03bhinesley * r46030 10/brlcad/trunk/src/libged/get_solid_kp.c: Enable retrieval of reasonable default keypoints for the remaining primitive types (METABALL, BOT, ARS, NMG). Remove all FIXME's/unnecessary comments, and trim all line lengths. |
| 20:37.32 | brlcad | abhi2011: struct soltab are basically unpacked rt_db_internal objects of primitives only |
| 20:38.04 | abhi2011 | ok |
| 20:38.07 | brlcad | part legacy part optimized expressiveness |
| 20:38.26 | brlcad | soltab is basically a prep'd rt_db_internal |
| 20:38.42 | brlcad | primitive |
| 20:39.04 | brlcad | starseeker: sure it can go or sure it has value and needs to stay? :) |
| 20:39.16 | abhi2011 | ok, and I read in some of the docs that an octree based space partitioning is done before rays are shot by rt |
| 20:39.26 | brlcad | don't want to remove it if there's some residual value there .. but if it's dead in the water, might as well clean up |
| 20:39.54 | brlcad | abhi2011: spatial partitioning is performed before rays are shot |
| 20:40.05 | abhi2011 | ok |
| 20:40.07 | brlcad | so that you only evaluate against primitives that are "near" |
| 20:40.13 | abhi2011 | yes |
| 20:40.34 | brlcad | yay, all logo finalists have responded .. time for the announcement |
| 20:40.37 | brlcad | waddles |
| 21:03.19 | DarkCalf | brlcad, have you seen Minecraft? |
| 21:15.43 | kunigami | >.< svn: Commit failed (details follow): |
| 21:15.43 | kunigami | svn: MERGE of '/svnroot/brlcad/osl/trunk': timed out waiting for server (https://brlcad.svn.sourceforge.net) |
| 21:16.11 | kunigami | do you mind if I perform several small commits on boost parts? |
| 21:19.14 | CIA-62 | BRL-CAD: 03kunigami * r46031 10/osl/trunk/boost/: adding boost by parts |
| 21:20.27 | CIA-62 | BRL-CAD: 03kunigami * r46032 10/osl/trunk/boost/boost/: adding boost by parts |
| 21:23.03 | CIA-62 | BRL-CAD: 03starseeker * r46033 10/brlcad/trunk/ (8 files in 8 dirs): |
| 21:23.03 | CIA-62 | BRL-CAD: Start organizing a functab function specifically for bounding box calculation. |
| 21:23.03 | CIA-62 | BRL-CAD: So far, have functions for ell, tor, tgc and rec pulled out from prep - arb8 is |
| 21:23.03 | CIA-62 | BRL-CAD: implemented but the way arb prep works means we can't use it there. sph just |
| 21:23.03 | CIA-62 | BRL-CAD: calls the ell routine. |
| 21:24.13 | starseeker | brlcad: it can go |
| 21:25.06 | starseeker | kunigami: sure - that has to be done sometimes |
| 21:25.07 | CIA-62 | BRL-CAD: 03kunigami * r46034 10/osl/trunk/boost/boost/aligned_storage.hpp: adding boost by parts |
| 21:25.17 | CIA-62 | BRL-CAD: 03kunigami * r46035 10/osl/trunk/boost/boost/array.hpp: adding boost by parts |
| 21:25.28 | CIA-62 | BRL-CAD: 03kunigami * r46036 10/osl/trunk/boost/boost/asio.hpp: adding boost by parts |
| 21:25.38 | CIA-62 | BRL-CAD: 03kunigami * r46037 10/osl/trunk/boost/boost/assert.hpp: adding boost by parts |
| 21:25.50 | kunigami | ouch, |
| 21:25.57 | CIA-62 | BRL-CAD: 03kunigami * r46038 10/osl/trunk/boost/boost/bind.hpp: adding boost by parts |
| 21:25.57 | CIA-62 | BRL-CAD: 03kunigami * r46039 10/osl/trunk/boost/boost/call_traits.hpp: adding boost by parts |
| 21:27.33 | CIA-62 | BRL-CAD: 03kunigami * r46040 10/osl/trunk/boost/boost/algorithm/ (43 files in 4 dirs): adding boost by parts |
| 21:29.58 | CIA-62 | BRL-CAD: 03kunigami * r46041 10/osl/trunk/boost/boost/archive/ (97 files in 4 dirs): adding boost by parts |
| 21:36.13 | brlcad | starseeker: awesome, adding the new functab! |
| 21:36.38 | brlcad | fwiw, that makes librt binary incompatible unless you make the new functab entry be last |
| 21:36.50 | starseeker | brlcad: starting it anyway - some of these aren't so simple (trying the figure out how the frack to get a list of all vertices in an nmg) |
| 21:36.59 | starseeker | brlcad: ah, crap |
| 21:37.20 | brlcad | not .g incompatible, librt.so incompat |
| 21:37.24 | starseeker | I should move it then? |
| 21:37.43 | CIA-62 | BRL-CAD: 03kunigami * r46042 10/osl/trunk/boost/boost/asio/ (310 files in 13 dirs): adding boost by parts |
| 21:37.43 | brlcad | doesn't matter -- but if it stays as-is, minor should be bumped |
| 21:38.01 | starseeker | grins evilly - oh good, then we'll do the deprications too |
| 21:38.16 | CIA-62 | BRL-CAD: 03kunigami * r46043 10/osl/trunk/boost/boost/bind/ (14 files): adding boost by parts |
| 21:38.28 | CIA-62 | BRL-CAD: 03kunigami * r46044 10/osl/trunk/boost/boost/cast.hpp: adding boost by parts |
| 21:38.35 | starseeker | there has got to be some way to iterate over all vertices in a model for nmg... |
| 21:38.38 | CIA-62 | BRL-CAD: 03kunigami * r46045 10/osl/trunk/boost/boost/cerrno.hpp: adding boost by parts |
| 21:38.48 | CIA-62 | BRL-CAD: 03kunigami * r46046 10/osl/trunk/boost/boost/checked_delete.hpp: adding boost by parts |
| 21:38.59 | CIA-62 | BRL-CAD: 03kunigami * r46047 10/osl/trunk/boost/boost/compressed_pair.hpp: adding boost by parts |
| 21:39.22 | CIA-62 | BRL-CAD: 03kunigami * r46048 10/osl/trunk/boost/boost/concept/ (11 files in 2 dirs): adding boost by parts |
| 21:39.33 | CIA-62 | BRL-CAD: 03kunigami * r46049 10/osl/trunk/boost/boost/concept_archetype.hpp: adding boost by parts |
| 21:39.44 | CIA-62 | BRL-CAD: 03kunigami * r46050 10/osl/trunk/boost/boost/concept_check.hpp: adding boost by parts |
| 21:41.37 | CIA-62 | BRL-CAD: 03kunigami * r46051 10/osl/trunk/boost/boost/config/ (73 files in 6 dirs): adding boost by parts |
| 21:41.49 | CIA-62 | BRL-CAD: 03kunigami * r46052 10/osl/trunk/boost/boost/config.hpp: adding boost by parts |
| 21:41.59 | CIA-62 | BRL-CAD: 03kunigami * r46053 10/osl/trunk/boost/boost/cregex.hpp: adding boost by parts |
| 21:42.08 | CIA-62 | BRL-CAD: 03kunigami * r46054 10/osl/trunk/boost/boost/cstdint.hpp: adding boost by parts |
| 21:42.18 | CIA-62 | BRL-CAD: 03kunigami * r46055 10/osl/trunk/boost/boost/cstdlib.hpp: adding boost by parts |
| 21:42.27 | CIA-62 | BRL-CAD: 03kunigami * r46056 10/osl/trunk/boost/boost/current_function.hpp: adding boost by parts |
| 21:44.03 | CIA-62 | BRL-CAD: 03kunigami * r46057 10/osl/trunk/boost/boost/date_time/ (65 files in 3 dirs): adding boost by parts |
| 21:45.07 | CIA-62 | BRL-CAD: 03kunigami * r46058 10/osl/trunk/boost/boost/detail/ (33 files): adding boost by parts |
| 21:45.26 | CIA-62 | BRL-CAD: 03kunigami * r46059 10/osl/trunk/boost/boost/dynamic_bitset/ (. config.hpp dynamic_bitset.hpp): adding boost by parts |
| 21:45.39 | CIA-62 | BRL-CAD: 03kunigami * r46060 10/osl/trunk/boost/boost/dynamic_bitset.hpp: adding boost by parts |
| 21:45.47 | CIA-62 | BRL-CAD: 03kunigami * r46061 10/osl/trunk/boost/boost/dynamic_bitset_fwd.hpp: adding boost by parts |
| 21:45.57 | CIA-62 | BRL-CAD: 03kunigami * r46062 10/osl/trunk/boost/boost/enable_shared_from_this.hpp: adding boost by parts |
| 21:46.13 | abhi2011 | I have a question regarding commits, so suppose I have commited 2 or more files but I want to commit only a particular file as of now, can I do that |
| 21:46.25 | CIA-62 | BRL-CAD: 03kunigami * r46063 10/osl/trunk/boost/boost/exception/ (16 files in 2 dirs): adding boost by parts |
| 21:46.29 | abhi2011 | *i mean suppose I have modified |
| 21:46.38 | CIA-62 | BRL-CAD: 03kunigami * r46064 10/osl/trunk/boost/boost/exception_ptr.hpp: adding boost by parts |
| 21:46.41 | kunigami | you can do: svn commit -m "message" name-of-the-file |
| 21:46.51 | starseeker | sure - svn commit path/to/specific/file -m "message" |
| 21:46.53 | abhi2011 | kunigami: thanks :) |
| 21:46.54 | starseeker | er, yeah |
| 21:47.00 | abhi2011 | yes |
| 21:47.21 | CIA-62 | BRL-CAD: 03kunigami * r46065 10/osl/trunk/boost/boost/filesystem/ (24 files in 4 dirs): adding boost by parts |
| 21:47.30 | CIA-62 | BRL-CAD: 03kunigami * r46066 10/osl/trunk/boost/boost/filesystem.hpp: adding boost by parts |
| 21:47.37 | plaes | brlcad doesn't support STEP ? |
| 21:47.42 | CIA-62 | BRL-CAD: 03kunigami * r46067 10/osl/trunk/boost/boost/foreach.hpp: adding boost by parts |
| 21:47.51 | CIA-62 | BRL-CAD: 03kunigami * r46068 10/osl/trunk/boost/boost/foreach_fwd.hpp: adding boost by parts |
| 21:48.24 | CIA-62 | BRL-CAD: 03kunigami * r46069 10/osl/trunk/boost/boost/format/ (20 files in 2 dirs): adding boost by parts |
| 21:48.35 | CIA-62 | BRL-CAD: 03kunigami * r46070 10/osl/trunk/boost/boost/format.hpp: adding boost by parts |
| 21:49.13 | CIA-62 | BRL-CAD: 03kunigami * r46071 10/osl/trunk/boost/boost/function/ (20 files in 2 dirs): adding boost by parts |
| 21:49.23 | CIA-62 | BRL-CAD: 03kunigami * r46072 10/osl/trunk/boost/boost/function.hpp: adding boost by parts |
| 21:49.34 | starseeker | plaes: we're working on it - step-g |
| 21:49.36 | CIA-62 | BRL-CAD: 03kunigami * r46073 10/osl/trunk/boost/boost/function_equal.hpp: adding boost by parts |
| 21:49.49 | plaes | aha |
| 21:50.01 | starseeker | kunigami: uh, you might want to try committing per dir, not per file... |
| 21:50.03 | CIA-62 | BRL-CAD: 03kunigami * r46074 10/osl/trunk/boost/boost/functional/ (13 files in 3 dirs): adding boost by parts |
| 21:50.17 | starseeker | oh, nevermind I see |
| 21:52.16 | kunigami | starseeker: I could have done a better job committing each dir's first and then all the single files in a single bundle :( sorry |
| 21:52.29 | CIA-62 | BRL-CAD: 03kunigami * r46075 10/osl/trunk/boost/boost/fusion/ (111 files in 21 dirs): adding boost by parts |
| 21:52.43 | CIA-62 | BRL-CAD: 03kunigami * r46076 10/osl/trunk/boost/boost/get_pointer.hpp: adding boost by parts |
| 21:53.31 | brlcad | starseeker: there's nmg_visit() |
| 21:53.54 | CIA-62 | BRL-CAD: 03kunigami * r46077 10/osl/trunk/boost/boost/graph/ (45 files in 7 dirs): adding boost by parts |
| 21:53.58 | brlcad | otherwise, I believe it's always treated as a recursive structure so integrity is better preserved |
| 21:54.13 | starseeker | nods - OK, let me try a trick... |
| 21:54.16 | CIA-62 | BRL-CAD: 03kunigami * r46078 10/osl/trunk/boost/boost/implicit_cast.hpp: adding boost by parts |
| 21:54.16 | CIA-62 | BRL-CAD: 03kunigami * r46079 10/osl/trunk/boost/boost/integer/ (. integer_mask.hpp static_log2.hpp): adding boost by parts |
| 21:54.17 | brlcad | for all regions, for all shells, for all loops, for all edges, for all vertices, etc |
| 21:54.26 | CIA-62 | BRL-CAD: 03kunigami * r46080 10/osl/trunk/boost/boost/integer.hpp: adding boost by parts |
| 21:54.33 | brlcad | nmg_visit() has a vertex callback though, so that might be easiest |
| 21:54.36 | CIA-62 | BRL-CAD: 03kunigami * r46081 10/osl/trunk/boost/boost/integer_fwd.hpp: adding boost by parts |
| 21:54.37 | starseeker | (by the way - is there a way to clear a bu_ptbl without having to free memory?) |
| 21:54.47 | CIA-62 | BRL-CAD: 03kunigami * r46082 10/osl/trunk/boost/boost/integer_traits.hpp: adding boost by parts |
| 21:54.57 | CIA-62 | BRL-CAD: 03kunigami * r46083 10/osl/trunk/boost/boost/intrusive_ptr.hpp: adding boost by parts |
| 21:55.12 | CIA-62 | BRL-CAD: 03kunigami * r46084 10/osl/trunk/boost/boost/io/ (. detail/ detail/quoted_manip.hpp ios_state.hpp): adding boost by parts |
| 21:55.23 | CIA-62 | BRL-CAD: 03kunigami * r46085 10/osl/trunk/boost/boost/io_fwd.hpp: adding boost by parts |
| 21:55.28 | brlcad | starseeker: I believe so |
| 21:55.33 | brlcad | bu.h ftw ;) |
| 21:55.39 | starseeker | is looking |
| 21:56.29 | starseeker | ah - bu_ptbl_zero perhaps... |
| 21:56.39 | starseeker | nope there it is |
| 21:56.41 | starseeker | bu_ptbl_reset |
| 21:56.42 | starseeker | :-) |
| 22:01.09 | CIA-62 | BRL-CAD: 03kunigami * r46086 10/osl/trunk/boost/boost/is_placeholder.hpp: adding boost by parts |
| 22:01.51 | CIA-62 | BRL-CAD: 03kunigami * r46087 10/osl/trunk/boost/boost/iterator/ (17 files in 2 dirs): adding boost by parts |
| 22:02.08 | CIA-62 | BRL-CAD: 03kunigami * r46088 10/osl/trunk/boost/boost/iterator.hpp: adding boost by parts |
| 22:02.26 | CIA-62 | BRL-CAD: 03kunigami * r46089 10/osl/trunk/boost/boost/iterator_adaptors.hpp: adding boost by parts |
| 22:02.38 | CIA-62 | BRL-CAD: 03kunigami * r46090 10/osl/trunk/boost/boost/lexical_cast.hpp: adding boost by parts |
| 22:02.48 | CIA-62 | BRL-CAD: 03kunigami * r46091 10/osl/trunk/boost/boost/limits.hpp: adding boost by parts |
| 22:02.59 | CIA-62 | BRL-CAD: 03kunigami * r46092 10/osl/trunk/boost/boost/make_shared.hpp: adding boost by parts |
| 22:08.36 | CIA-62 | BRL-CAD: 03kunigami * r46093 10/osl/trunk/boost/boost/math/ (206 files in 7 dirs): adding boost by parts |
| 22:08.50 | CIA-62 | BRL-CAD: 03kunigami * r46094 10/osl/trunk/boost/boost/mem_fn.hpp: adding boost by parts |
| 22:08.59 | CIA-62 | BRL-CAD: 03kunigami * r46095 10/osl/trunk/boost/boost/memory_order.hpp: adding boost by parts |
| 22:10.26 | CIA-62 | BRL-CAD: 03kunigami * r46096 10/osl/trunk/boost/boost/mpi/ (55 files in 4 dirs): adding boost by parts |
| 22:10.39 | CIA-62 | BRL-CAD: 03kunigami * r46097 10/osl/trunk/boost/boost/mpi.hpp: adding boost by parts |
| 22:13.58 | CIA-62 | BRL-CAD: 03starseeker * r46098 10/brlcad/trunk/src/librt/primitives/ (nmg/nmg.c table.c): |
| 22:13.58 | CIA-62 | BRL-CAD: This appears to be a working bbox routine for nmg, but I need someone to review |
| 22:13.58 | CIA-62 | BRL-CAD: it and make sure I haven't accidently swatted some other prep function during |
| 22:13.58 | CIA-62 | BRL-CAD: this re-org. I can get a bbox and raytrace a facetized sphere. |
| 22:31.17 | CIA-62 | BRL-CAD: 03kunigami * r46099 10/osl/trunk/boost/boost/mpl/ (902 files in 29 dirs): adding boost by parts |
| 22:33.13 | CIA-62 | BRL-CAD: 03kunigami * r46100 10/osl/trunk/boost/boost/multi_index/ (54 files in 2 dirs): adding boost by parts |
| 22:33.24 | CIA-62 | BRL-CAD: 03kunigami * r46101 10/osl/trunk/boost/boost/multi_index_container.hpp: adding boost by parts |
| 22:33.36 | CIA-62 | BRL-CAD: 03kunigami * r46102 10/osl/trunk/boost/boost/multi_index_container_fwd.hpp: adding boost by parts |
| 22:33.46 | CIA-62 | BRL-CAD: 03kunigami * r46103 10/osl/trunk/boost/boost/next_prior.hpp: adding boost by parts |
| 22:33.56 | CIA-62 | BRL-CAD: 03kunigami * r46104 10/osl/trunk/boost/boost/non_type.hpp: adding boost by parts |
| 22:34.07 | CIA-62 | BRL-CAD: 03kunigami * r46105 10/osl/trunk/boost/boost/noncopyable.hpp: adding boost by parts |
| 22:34.22 | CIA-62 | BRL-CAD: 03kunigami * r46106 10/osl/trunk/boost/boost/none.hpp: adding boost by parts |
| 22:34.30 | CIA-62 | BRL-CAD: 03kunigami * r46107 10/osl/trunk/boost/boost/none_t.hpp: adding boost by parts |
| 22:35.21 | CIA-62 | BRL-CAD: 03kunigami * r46108 10/osl/trunk/boost/boost/numeric/ (20 files in 3 dirs): adding boost by parts |
| 22:35.33 | CIA-62 | BRL-CAD: 03kunigami * r46109 10/osl/trunk/boost/boost/operators.hpp: adding boost by parts |
| 22:35.45 | CIA-62 | BRL-CAD: 03kunigami * r46110 10/osl/trunk/boost/boost/optional/ (. optional.hpp optional_fwd.hpp): adding boost by parts |
| 22:35.56 | CIA-62 | BRL-CAD: 03kunigami * r46111 10/osl/trunk/boost/boost/optional.hpp: adding boost by parts |
| 22:36.27 | CIA-62 | BRL-CAD: 03kunigami * r46112 10/osl/trunk/boost/boost/parameter/ (17 files in 2 dirs): adding boost by parts |
| 22:36.49 | CIA-62 | BRL-CAD: 03kunigami * r46113 10/osl/trunk/boost/boost/pending/ (9 files in 2 dirs): adding boost by parts |
| 22:36.59 | CIA-62 | BRL-CAD: 03kunigami * r46114 10/osl/trunk/boost/boost/pointee.hpp: adding boost by parts |
| 22:37.22 | CIA-62 | BRL-CAD: 03kunigami * r46115 10/osl/trunk/boost/boost/pool/ (12 files in 2 dirs): adding boost by parts |
| 22:41.21 | CIA-62 | BRL-CAD: 03kunigami * r46116 10/osl/trunk/boost/boost/preprocessor/ (183 files in 35 dirs): adding boost by parts |
| 22:41.39 | CIA-62 | BRL-CAD: 03kunigami * r46117 10/osl/trunk/boost/boost/progress.hpp: adding boost by parts |
| 22:41.58 | CIA-62 | BRL-CAD: 03kunigami * r46118 10/osl/trunk/boost/boost/property_map/ (9 files in 3 dirs): adding boost by parts |
| 22:46.44 | CIA-62 | BRL-CAD: 03kunigami * r46119 10/osl/trunk/boost/boost/python/ (208 files in 7 dirs): adding boost by parts |
| 22:46.59 | CIA-62 | BRL-CAD: 03kunigami * r46120 10/osl/trunk/boost/boost/python.hpp: adding boost by parts |
| 22:48.36 | CIA-62 | BRL-CAD: 03kunigami * r46121 10/osl/trunk/boost/boost/random/ (61 files in 2 dirs): adding boost by parts |
| 22:48.51 | CIA-62 | BRL-CAD: 03kunigami * r46122 10/osl/trunk/boost/boost/random.hpp: adding boost by parts |
| 22:49.57 | CIA-62 | BRL-CAD: 03kunigami * r46123 10/osl/trunk/boost/boost/range/ (45 files in 4 dirs): adding boost by parts |
| 22:50.09 | CIA-62 | BRL-CAD: 03kunigami * r46124 10/osl/trunk/boost/boost/ref.hpp: adding boost by parts |
| 22:51.47 | CIA-62 | BRL-CAD: 03kunigami * r46125 10/osl/trunk/boost/boost/regex/ (57 files in 4 dirs): adding boost by parts |
| 22:52.02 | CIA-62 | BRL-CAD: 03kunigami * r46126 10/osl/trunk/boost/boost/regex.hpp: adding boost by parts |
| 22:52.12 | CIA-62 | BRL-CAD: 03kunigami * r46128 10/osl/trunk/boost/boost/regex_fwd.hpp: adding boost by parts |
| 22:52.21 | CIA-62 | BRL-CAD: 03starseeker * r46127 10/brlcad/trunk/src/librt/primitives/ (bot/bot.c bot/g_bot_include.c table.c): Add bbox routine for bots. |
| 22:52.21 | CIA-62 | BRL-CAD: 03kunigami * r46129 10/osl/trunk/boost/boost/scoped_array.hpp: adding boost by parts |
| 22:52.32 | CIA-62 | BRL-CAD: 03kunigami * r46130 10/osl/trunk/boost/boost/scoped_ptr.hpp: adding boost by parts |
| 22:53.52 | CIA-62 | BRL-CAD: 03kunigami * r46131 10/osl/trunk/boost/boost/serialization/ (51 files in 2 dirs): adding boost by parts |
| 22:54.06 | CIA-62 | BRL-CAD: 03kunigami * r46132 10/osl/trunk/boost/boost/shared_array.hpp: adding boost by parts |
| 22:54.17 | CIA-62 | BRL-CAD: 03kunigami * r46133 10/osl/trunk/boost/boost/shared_ptr.hpp: adding boost by parts |
| 22:55.53 | CIA-62 | BRL-CAD: 03kunigami * r46134 10/osl/trunk/boost/boost/smart_ptr/ (50 files in 2 dirs): adding boost by parts |
| 22:56.08 | CIA-62 | BRL-CAD: 03kunigami * r46135 10/osl/trunk/boost/boost/smart_ptr.hpp: adding boost by parts |
| 23:00.50 | CIA-62 | BRL-CAD: 03kunigami * r46136 10/osl/trunk/boost/boost/spirit/ (209 files in 36 dirs): adding boost by parts |
| 23:01.10 | CIA-62 | BRL-CAD: 03kunigami * r46137 10/osl/trunk/boost/boost/static_assert.hpp: adding boost by parts |
| 23:01.24 | CIA-62 | BRL-CAD: 03kunigami * r46138 10/osl/trunk/boost/boost/swap.hpp: adding boost by parts |
| 23:01.45 | CIA-62 | BRL-CAD: 03kunigami * r46139 10/osl/trunk/boost/boost/system/ (. api_config.hpp config.hpp error_code.hpp system_error.hpp): adding boost by parts |
| 23:04.48 | CIA-62 | BRL-CAD: 03kunigami * r46140 10/osl/trunk/boost/boost/test/ (126 files in 13 dirs): adding boost by parts |
| 23:06.06 | CIA-62 | BRL-CAD: 03kunigami * r46141 10/osl/trunk/boost/boost/thread/ (47 files in 4 dirs): adding boost by parts |
| 23:06.17 | CIA-62 | BRL-CAD: 03kunigami * r46142 10/osl/trunk/boost/boost/thread.hpp: adding boost by parts |
| 23:06.30 | CIA-62 | BRL-CAD: 03kunigami * r46143 10/osl/trunk/boost/boost/throw_exception.hpp: adding boost by parts |
| 23:06.43 | CIA-62 | BRL-CAD: 03kunigami * r46144 10/osl/trunk/boost/boost/timer.hpp: adding boost by parts |
| 23:06.54 | CIA-62 | BRL-CAD: 03kunigami * r46145 10/osl/trunk/boost/boost/token_functions.hpp: adding boost by parts |
| 23:07.05 | CIA-62 | BRL-CAD: 03kunigami * r46146 10/osl/trunk/boost/boost/token_iterator.hpp: adding boost by parts |
| 23:07.15 | CIA-62 | BRL-CAD: 03kunigami * r46147 10/osl/trunk/boost/boost/tokenizer.hpp: adding boost by parts |
| 23:07.30 | CIA-62 | BRL-CAD: 03kunigami * r46148 10/osl/trunk/boost/boost/tr1/ (. detail/ detail/config.hpp detail/config_all.hpp memory.hpp): adding boost by parts |
| 23:07.46 | CIA-62 | BRL-CAD: 03kunigami * r46149 10/osl/trunk/boost/boost/tuple/ (6 files in 2 dirs): adding boost by parts |
| 23:07.56 | CIA-62 | BRL-CAD: 03kunigami * r46150 10/osl/trunk/boost/boost/type.hpp: adding boost by parts |
| 23:10.43 | CIA-62 | BRL-CAD: 03kunigami * r46151 10/osl/trunk/boost/boost/type_traits/ (121 files in 3 dirs): adding boost by parts |
| 23:11.00 | CIA-62 | BRL-CAD: 03kunigami * r46152 10/osl/trunk/boost/boost/type_traits.hpp: adding boost by parts |
| 23:11.57 | CIA-62 | BRL-CAD: 03kunigami * r46153 10/osl/trunk/boost/boost/typeof/ (29 files in 3 dirs): adding boost by parts |
| 23:12.13 | CIA-62 | BRL-CAD: 03kunigami * r46154 10/osl/trunk/boost/boost/units/ (. detail/ detail/utility.hpp): adding boost by parts |
| 23:12.43 | CIA-62 | BRL-CAD: 03kunigami * r46155 10/osl/trunk/boost/boost/unordered/ (16 files in 2 dirs): adding boost by parts |
| 23:12.52 | CIA-62 | BRL-CAD: 03kunigami * r46156 10/osl/trunk/boost/boost/unordered_map.hpp: adding boost by parts |
| 23:13.03 | CIA-62 | BRL-CAD: 03kunigami * r46157 10/osl/trunk/boost/boost/unordered_set.hpp: adding boost by parts |
| 23:13.34 | CIA-62 | BRL-CAD: 03kunigami * r46158 10/osl/trunk/boost/boost/utility/ (15 files in 2 dirs): adding boost by parts |
| 23:13.45 | CIA-62 | BRL-CAD: 03kunigami * r46159 10/osl/trunk/boost/boost/utility.hpp: adding boost by parts |
| 23:13.57 | CIA-62 | BRL-CAD: 03kunigami * r46160 10/osl/trunk/boost/boost/version.hpp: adding boost by parts |
| 23:14.05 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 23:14.07 | CIA-62 | BRL-CAD: 03kunigami * r46161 10/osl/trunk/boost/boost/visit_each.hpp: adding boost by parts |
| 23:16.11 | CIA-62 | BRL-CAD: 03kunigami * r46162 10/osl/trunk/boost/boost/wave/ (62 files in 5 dirs): adding boost by parts |
| 23:16.21 | CIA-62 | BRL-CAD: 03kunigami * r46163 10/osl/trunk/boost/boost/wave.hpp: adding boost by parts |
| 23:16.32 | CIA-62 | BRL-CAD: 03kunigami * r46164 10/osl/trunk/boost/boost/weak_ptr.hpp: adding boost by parts |
| 23:24.12 | CIA-62 | BRL-CAD: 03kunigami * r46165 10/osl/trunk/boost/doc/ (. src/ src/minimal.css): adding boost by parts |
| 23:32.14 | brlcad | starseeker: have you been hooking the new bbox funcs into prep? |
| 23:32.21 | starseeker | brlcad: yeah |
| 23:32.24 | brlcad | cool |
| 23:32.25 | starseeker | where I can |
| 23:51.21 | CIA-62 | BRL-CAD: 03kunigami * r46166 10/osl/trunk/boost/libs/ (481 files in 118 dirs): adding boost by parts |
| 23:52.56 | CIA-62 | BRL-CAD: 03kunigami * r46167 10/osl/trunk/boost/tools/: adding boost by parts |
| 23:53.42 | CIA-62 | BRL-CAD: 03kunigami * r46168 10/osl/trunk/boost/tools/build/ (. boost.css index.html v2/): adding boost by parts |
| 23:55.16 | CIA-62 | BRL-CAD: 03kunigami * r46169 10/osl/trunk/boost/tools/build/v2/ (21 files): adding boost by parts |
| 23:58.51 | ``Erik | O.o svn has a builtin variant of .cvsignore? (the ringworld commit caught my eye) |
| 00:00.25 | CIA-62 | BRL-CAD: 03kunigami * r46170 10/osl/trunk/boost/tools/build/v2/ (53 files in 6 dirs): adding boost by parts |
| 00:01.22 | ``Erik | (a couple people (slow committers) have asked why we aren't on git, any valid argument?) |
| 00:02.40 | CIA-62 | BRL-CAD: 03starseeker * r46171 10/brlcad/trunk/src/librt/primitives/bot/ (bot.c g_bot_include.c): Whoops - shouldn't be resetting stp here. |
| 00:04.36 | CIA-62 | BRL-CAD: 03starseeker * r46172 10/brlcad/trunk/src/librt/primitives/ (ars/ars.c table.c): It's not strictly necessary for prep as long as we're using BoT internally for ars, but go ahead and add a bbox routine for ars. |
| 00:05.22 | starseeker | ``Erik: we aim to have everybody committing to a common branch to avoid "working in isolation" too much, as I understand it |
| 00:05.33 | starseeker | git makes it much easier to wander off in a corner and work in isolation |
| 00:06.10 | ``Erik | that was my thought, but I'd probably present it as "suck it up, stub it so it compiles and commit a lot, stop whining" |
| 00:06.52 | ``Erik | my two office mates are reluctant to commit until they feel things are "done", which throws away the continual peer review aspect |
| 00:07.39 | starseeker | nods - we've tried to discuss that with 'em before, but to no avail |
| 00:08.14 | starseeker | wonders if he should bother with a bbox routine for poly - I'm not even sure how I'd test it |
| 00:08.38 | CIA-62 | BRL-CAD: 03kunigami * r46173 10/osl/trunk/boost/tools/build/v2/ (283 files in 38 dirs): adding boost by parts |
| 00:10.22 | ``Erik | 'poly'? |
| 00:10.47 | ``Erik | open nmg, basically? |
| 00:11.38 | ``Erik | be easy to write such a func, set max to -infinity, min to infinity, then for each vertex, see if max{x,y,z} is bigger and min{x,y,z} is smaller, update them as you go |
| 00:16.20 | ``Erik | wanders off, hasta la pasta |
| 00:17.28 | CIA-62 | BRL-CAD: 03kunigami * r46174 10/osl/trunk/boost/tools/build/v2/test/ (365 files in 50 dirs): adding boost by parts |
| 00:22.13 | CIA-62 | BRL-CAD: 03kunigami * r46175 10/osl/trunk/boost/tools/build/v2/engine/ (99 files): adding boost by parts |
| 00:24.14 | abhi2011 | is anyone able to compile with strict warnings on : cmake ../brlcad -DBRLCAD_BUNDLED_LIBS=Bundled -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/home/abhi/brlcad |
| 00:24.16 | CIA-62 | BRL-CAD: 03kunigami * r46176 10/osl/trunk/boost/tools/build/v2/engine/ (14 files in 2 dirs): adding boost by parts |
| 00:24.57 | abhi2011 | i am still getting the function prototype errors I was getting yesterday from a fresh checkout : /home/abhi/socis/brlcad/src/libged/inside.c:935:2: error: call to function ‘rt_arb_get_cgtype’ without a real prototype |
| 00:41.40 | CIA-62 | BRL-CAD: 03kunigami * r46177 10/osl/trunk/boost/tools/build/v2/engine/boehm_gc/ (92 files): adding boost by parts |
| 00:44.53 | CIA-62 | BRL-CAD: 03kunigami * r46178 10/osl/trunk/boost/tools/build/v2/engine/boehm_gc/ (59 files in 5 dirs): adding boost by parts |
| 00:46.36 | CIA-62 | BRL-CAD: 03kunigami * r46179 10/osl/trunk/boost/tools/build/v2/engine/boehm_gc/doc/ (37 files): adding boost by parts |
| 00:47.39 | CIA-62 | BRL-CAD: 03kunigami * r46180 10/osl/trunk/boost/ (Jamroot boost-build.jam boost.png bootstrap.sh): woot the last boost files |
| 00:50.52 | CIA-62 | BRL-CAD: 03kunigami * r46181 10/osl/trunk/compile.sh: added rule for boost and osl - it remains fixing the destination dir of oiio and osl and testing on another machine |
| 01:21.57 | starseeker | ``Erik: oh, I know it's easy to write but the primitive is an old one |
| 01:22.24 | starseeker | make and in don't support it, so creating one would require a bit of nonsense |
| 01:24.18 | starseeker | I can on gentoo - what gcc/os are you using? |
| 01:25.15 | CIA-62 | BRL-CAD: 03bhinesley * r46182 10/brlcad/trunk/src/libged/edit.c: (log message trimmed) |
| 01:25.15 | CIA-62 | BRL-CAD: Started logging tests of translate options/args. Ex. of a more complex set of |
| 01:25.15 | CIA-62 | BRL-CAD: args that is working: "translate -a -x comb/combA 3 -z combB/combC 0 0 11 -y |
| 01:25.15 | CIA-62 | BRL-CAD: combD/combE 0 7 combF/combG", which moves the instance of combG in combF from |
| 01:25.15 | CIA-62 | BRL-CAD: it's bounding box center to (x= apparent bb ctr of comb/combA offset 3 units), |
| 01:25.16 | CIA-62 | BRL-CAD: (y= apparent bb ctr of combF/combG offset 7 units), (z= apparent bb ctr of |
| 01:25.17 | CIA-62 | BRL-CAD: combB/combC offset 11 units). Disable use of batch operator as an argument to |
| 01:30.11 | brlcad | abhi2011: so fix it :) |
| 01:30.38 | brlcad | for whatever reason, nobody else is hitting that warning, making you the perfect person to fix it |
| 01:32.15 | brlcad | starseeker: poly was the precursor to BoT |
| 01:34.27 | CIA-62 | BRL-CAD: 03brlcad * r46183 10/brlcad/trunk/TODO: the hf and polysolid primitives are both supplanted by newer more complete primitives (half and BoT respectively), so mark them for removal in rel8 |
| 01:35.02 | abhi2011 | yep I turned of strict warnings :P |
| 01:35.35 | brlcad | abhi2011: that's no fix :P |
| 01:35.46 | brlcad | you do understand what that message means, yes? |
| 01:36.24 | abhi2011 | hehe yeah, will look into it, though its strange that I am getting it for almost every c function |
| 01:37.08 | brlcad | shouldn't have to look into it .. should be obvious -- if it's not, then you definitely should "fix" that warning |
| 01:37.29 | brlcad | prototype is empty |
| 01:37.44 | brlcad | it wants a real decl with the args listed |
| 01:37.58 | brlcad | decl is in include/raytrace.h |
| 01:38.56 | abhi2011 | yes and I am sure its included in the appropriate c file |
| 01:39.43 | brlcad | sure, but the prototype is *empty* |
| 01:39.53 | brlcad | that's what the compiler is warning you about |
| 01:40.10 | brlcad | make it be not empty |
| 01:40.33 | bhinesley | abhi2011: curious which gcc you're running |
| 01:40.48 | abhi2011 | yes, I can do that, I am just wondering if its code being modified by someone else |
| 01:41.19 | abhi2011 | brlcad: 4.5.1 20101208 |
| 01:41.53 | CIA-62 | BRL-CAD: 03brlcad * r46184 10/brlcad/trunk/TODO: need to include deprecation output on the old build system as well as when creating (or perhaps exporting) bspline/poly/hf primitives. |
| 01:42.30 | brlcad | abhi2011: no entiendo.. "code being modified by someone else"? |
| 01:43.23 | brlcad | no code is sacred, if code is found deficient, it gets fixed/improved/refactored |
| 01:43.37 | brlcad | revision control is our safety net |
| 01:44.48 | abhi2011 | brlcad: ok :) , though I was wondering whats the compiler version you are using |
| 01:45.11 | abhi2011 | because it seems more like a compiler flag issue |
| 01:45.15 | bhinesley | abhi2011: we're all over the place. I'm using 4.6 |
| 01:45.19 | abhi2011 | ok |
| 01:45.51 | CIA-62 | BRL-CAD: 03brlcad * r46185 10/brlcad/trunk/doc/deprecation.txt: |
| 01:45.51 | CIA-62 | BRL-CAD: they were never officially documented as such, so do so now. mark the bspline, |
| 01:45.51 | CIA-62 | BRL-CAD: poly, and hf primitives as deprecated. as removing them is a rather major |
| 01:45.51 | CIA-62 | BRL-CAD: backwards-incompatible change, they're better suited to rel8 than they are the |
| 01:45.51 | CIA-62 | BRL-CAD: usual 3-minor release timeframe. they should be documented somewhere |
| 01:45.52 | CIA-62 | BRL-CAD: regardless. |
| 01:46.34 | brlcad | abhi2011: we intentionally consider all warnings as errors for this exact reason, so that the issues get fixed |
| 01:48.41 | brlcad | the compiler usually issues warnings for pretty good reasons, so it's our project stance to halt regardless of version or environment (unless the issue is fundamentally unavoidable or a bug outside our control that cannot be compensated for easily) |
| 01:49.47 | starseeker | brlcad: do we have a tool to convert bspline/poly/hf primitives to their newer versions? |
| 01:49.59 | starseeker | wonders if cline can also get chopped... |
| 01:50.19 | brlcad | starseeker: nope |
| 01:50.22 | abhi2011 | brlcad: yes, I understand that, the errors came for a huge number of functions across multiple files, so I ll see if fixing one of them makes a difference |
| 01:50.40 | brlcad | starseeker: actually "yes" .. it just doesn't |
| 01:50.42 | brlcad | dbupgrade |
| 01:51.13 | starseeker | nods |
| 01:51.37 | starseeker | so that would be added for a 5->6 upgrade? |
| 01:51.51 | brlcad | I added code to run bspline through brep, worked well |
| 01:51.59 | brlcad | but the other two are relics |
| 01:52.45 | starseeker | nods - but I'm guessing we still don't get to ignore 'em in the upgrade path? |
| 01:52.59 | brlcad | shouldn't |
| 01:55.33 | starseeker | do we teach dbupgrade to convert 'em now when run on a v5 file? |
| 01:57.29 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 02:03.50 | CIA-62 | BRL-CAD: 03bhinesley * r46186 10/brlcad/trunk/src/libged/edit.c: Simplify iterating through arguments for execution of batch commands. |
| 02:11.42 | brlcad | starseeker: that would probably be okay |
| 02:12.52 | brlcad | presently does nothing with v5 files, of course |
| 02:35.52 | CIA-62 | BRL-CAD: 03brlcad * r46187 10/brlcad/trunk/src/librt/primitives/table.c: |
| 02:35.52 | CIA-62 | BRL-CAD: there's no need to intentionally make matters any harder for ourselves than they |
| 02:35.52 | CIA-62 | BRL-CAD: need to be, move the bbox routine to the end so we can reduce the risk of |
| 02:35.52 | CIA-62 | BRL-CAD: calling the wrong callback and crashing (or worse) if an older library somehow |
| 02:35.52 | CIA-62 | BRL-CAD: got linked. also didn't seem to be any particular grouping reason to have it |
| 02:35.52 | CIA-62 | BRL-CAD: between ifree/describe .. more closely related to prep and params, which the |
| 02:35.53 | CIA-62 | BRL-CAD: latter is conveniently at the end. |
| 02:36.35 | CIA-62 | BRL-CAD: 03brlcad * r46188 10/brlcad/trunk/include/raytrace.h: oops, this file goes with r46187. move bbox to the end. |
| 02:37.00 | brlcad | starseeker: you see tom's note? |
| 02:37.05 | brlcad | revenge of the red |
| 02:40.42 | CIA-62 | BRL-CAD: 03brlcad * r46189 10/brlcad/trunk/src/libged/red.c: remove the WARNING blather. all of the known red issues were fixed and are now integrated into our release regression testing with a rather extensive set of tests. |
| 03:04.47 | abhi2011 | ok I was looking into the error: call to function ‘blahblah’ without a real prototype , that I have been getting : it seems many(about 40+ functions, probably more) have been declared as follows Function(), and overhauling all of them would involve updating a huge number of files |
| 03:08.05 | abhi2011 | Not sure if it would be a good idea to do that |
| 03:08.21 | bhinesley | $5 says that it would be :) |
| 03:09.12 | abhi2011 | hehe :), well I ll get started then |
| 03:09.38 | bhinesley | i'm really curious as to why you're being alerted to these issues and not me (and others?). As brlcad pointed out, at least with the first warning, there is an actual problem that we can all observe; not the result of some configuration issue on your end. |
| 03:10.32 | bhinesley | slight differences in the compiler, I must assume |
| 03:10.42 | abhi2011 | well I am using a standard cmake configuration : cmake ../brlcad -DBRLCAD-ENABLE_STRICT=ON -DBRLCAD_BUNDLED_LIBS=Bundled -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/home/abhi/brlcad |
| 03:10.51 | abhi2011 | yes, the funny thing is, it wasnt there last week |
| 03:11.01 | abhi2011 | exactly same compiler |
| 03:11.25 | bhinesley | shrugs |
| 03:22.09 | brlcad | yeah, that's the odd part |
| 03:22.51 | brlcad | I pulled latest gcc svn (gcc 4.7) and don't get that warning, even though it's clearly a valid warning with the dumb k&r declarations being used |
| 03:24.19 | brlcad | abhi2011: so yeah, it would be a great idea to fix them since you're the one getting the reports .. but it's impossible that it's a "huge" number of files :) |
| 03:24.48 | brlcad | 40+ functions would, at worst, be 40+ files .. that's quick n' easy, maybe 20 min on a bad day :) |
| 03:25.18 | brlcad | more than likely, it's 90% in raytrace.h |
| 03:27.08 | CIA-62 | BRL-CAD: 03brlcad * r46190 10/brlcad/trunk/TODO: report that rtcheck doesn't work in previous release. probably the rt output bug, but warrants a quick test before the next release. |
| 03:31.21 | CIA-62 | BRL-CAD: 03bhinesley * r46191 10/brlcad/trunk/src/libged/edit.c: (log message trimmed) |
| 03:31.21 | CIA-62 | BRL-CAD: Argument type flags were being cleared by mistake. This led to an assert failure |
| 03:31.21 | CIA-62 | BRL-CAD: when trying to calculate vectors, as there was no argument flagged EDIT_FROM; |
| 03:31.22 | CIA-62 | BRL-CAD: which should at least defaulted to something. The batch operator is now working, |
| 03:31.22 | CIA-62 | BRL-CAD: at least in the simple cases that I tried. Also, a variable tracking the number |
| 03:31.22 | CIA-62 | BRL-CAD: of arguments in a linked list was only incremented by 1 for each batch operator, |
| 03:31.23 | CIA-62 | BRL-CAD: rather than adding the number of target objects to the total. I didn't observe |
| 03:31.44 | bhinesley | ^-- amazing the trouble a missing bit can cause |
| 03:41.04 | CIA-62 | BRL-CAD: 03bhinesley * r46192 10/brlcad/trunk/src/libged/edit.c: Error about not yet supporting use of the batch operator to specify individual coordinates was a bit overzealus. |
| 03:41.42 | bhinesley | yay, all kinds of neat stuff works now |
| 03:53.06 | brlcad | heh |
| 03:53.10 | brlcad | awesome! |
| 03:53.39 | brlcad | bhinesley: so you're soon to be on my radar to obtain deeper understanding of all the changes you've made of lagte |
| 03:53.55 | brlcad | the code is getting a bit complex for the task at hand |
| 03:54.52 | brlcad | but a bit premature to comment other than "that's a lot of code!" :) |
| 03:55.07 | brlcad | nice work on tackling such a complex task |
| 04:00.17 | bhinesley | great, I look forward to your comments/ideas |
| 04:04.47 | bhinesley | if I remove incomplete scale/rotate stuff, there are 1176 LOC according to cloc; and about as many lines in comments |
| 04:05.33 | brlcad | starseeker: nmg bbox looks good to me on the surface, save for one issue -- an empty nmg will likely crash, need to init vert_table |
| 04:06.41 | brlcad | bhinesley: like I said, that's a lot of code (for something as basically amounts to a xform call) :) |
| 04:07.06 | brlcad | the arg processing probably begs refactoring |
| 04:07.11 | bhinesley | the translate command is 158 LOC |
| 04:07.29 | brlcad | yeah, that's more what I'd expect |
| 04:07.50 | brlcad | so there's a ton of infrastructure around the meat of the matter |
| 04:07.57 | brlcad | not saying that's good or bad, it is what it is |
| 04:08.09 | bhinesley | same here |
| 04:08.43 | brlcad | it is, however, a pretty strong cue that something probably needs to be refactored |
| 04:09.37 | bhinesley | that's not suprising. I've learned a lot (about brlcad and coding), and there were a lot of suprises along the way. |
| 04:11.29 | bhinesley | I certainly didn't expect it to take me this long |
| 04:11.37 | bhinesley | but there it is |
| 04:17.21 | brlcad | yep |
| 04:18.14 | brlcad | hopefully you stick to it too, there's a lot of interesting projects you could cut your teeth on now that you've become a little familiar with the code |
| 04:18.33 | brlcad | some a lot more exciting that argument parsing ;) |
| 04:18.37 | bhinesley | hehe |
| 04:29.16 | CIA-62 | BRL-CAD: 03bhinesley * r46193 10/brlcad/trunk/src/libged/edit.c: These arguments to translate work, since r46191/92. |
| 05:37.50 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3079 10/wiki/User:Bhinesley: /* Log */ crossed out tasks, logged today |
| 06:38.09 | brlcad | publishes the logo contest finalists |
| 06:38.15 | brlcad | waddles off into the night |
| 07:34.57 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 11:18.46 | abhi2011 | brlcad: yes, I have begun modifying the k&r styles |
| 14:00.34 | CIA-62 | BRL-CAD: 03kunigami * r46194 10/osl/trunk/oiio/Makefile: modified the build script a bit so that oiio exports to a default destination install |
| 14:02.10 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 14:09.59 | CIA-62 | BRL-CAD: 03kunigami * r46195 10/osl/trunk/osl/ (Makefile src/CMakeLists.txt): added missing make from osl root and also turned off -werror |
| 14:11.35 | CIA-62 | BRL-CAD: 03kunigami * r46196 10/osl/trunk/compile.sh: now both osl and oiio should be build on default dirs |
| 14:17.25 | CIA-62 | BRL-CAD: 03kunigami * r46197 10/osl/trunk/boost/boostcpp.jam: missing file to build boost |
| 14:17.48 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 14:19.52 | CIA-62 | BRL-CAD: 03kunigami * r46198 10/osl/trunk/compile.sh: boost should be built before oiio/osl |
| 14:51.32 | CIA-62 | BRL-CAD: 03starseeker * r46199 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: initialize bu_ptbl for nmg vert list in bbox routine. |
| 14:55.00 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 15:05.07 | kunigami | is there any environment variable I can set so that cmake find_library will look there too? |
| 15:10.48 | ``Erik | mebbe LD_LIBRARY_PATH ? |
| 15:13.13 | kunigami | hmm I tried that, but didn't work. INut 'll check again |
| 15:19.04 | kunigami | nope. by the way, I'm trying to call FindPNG module, but it's not setting anything. I've build brlcad and so libpng was build on <brlcad dest>/lib/, which is the path that I added to LD_LIBRARY_PATH |
| 15:29.22 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 15:30.28 | kunigami | anyone having problems with ITK_LBRARY not being found? |
| 15:34.43 | brlcad | abhi2011: so version control 101 -- if you've been modifying them, then you should be committing already |
| 15:35.20 | brlcad | fix one, commit, fix another, commit -- at least per file |
| 15:35.52 | brlcad | waiting to commit them all as one mega change is much harder to review |
| 15:39.48 | starseeker | kunigami: you're using a system itk? |
| 15:40.36 | starseeker | kunigami: I believe the environment variable is CMAKE_LIBRARY_PATH |
| 15:58.13 | CIA-62 | BRL-CAD: 03r_weiss * r46200 10/brlcad/trunk/src/ (4 files in 4 dirs): Updated files 'get_solid_kp.c', 'rec.c', 'tgc.c' and 'nmg.c' to remove the compiler error/warning message 'ISO C90 forbids mixed declarations and code'. |
| 16:00.02 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 16:02.48 | kunigami | starseeker: I'm using -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON, so I believe it's using from the source |
| 16:06.59 | starseeker | kunigami: that option has changed - try -DBRLCAD_BUNDLED_LIBS=Bundled |
| 16:07.05 | kunigami | starseeker: thanks, that name led me to the CMAKE_PREFIX_PATH |
| 16:07.19 | kunigami | starseeker: oh, |
| 16:10.43 | kunigami | hmm, no, the error remains |
| 16:10.56 | CIA-62 | BRL-CAD: 03abhi2011 * r46201 10/brlcad/trunk/src/librt/bbox.c: Updated librt function for finding bb from rt_db_internal |
| 16:20.29 | CIA-62 | BRL-CAD: 03abhi2011 * r46202 10/brlcad/trunk/include/raytrace.h: Updated declaration for the bb function as well |
| 16:28.52 | CIA-62 | BRL-CAD: 03abhi2011 * r46203 10/brlcad/trunk/src/fb/fb-orle.c: Filled in empty K&R style prototypes with the parameter datatypes |
| 16:29.41 | CIA-62 | BRL-CAD: 03abhi2011 * r46204 10/brlcad/trunk/include/orle.h: Filled in empty K&R style prototypes with the parameter datatypes |
| 16:31.37 | kunigami | damn |
| 16:32.17 | abhi2011 | there appears to be 2 structures in use in libfb with exactly the same definition : struct ColorMap and struct RLEColorMap |
| 16:33.19 | abhi2011 | kunigami: I was getting the itk error 2 days ago, but a clean checkout and the bundled options helped compile it successfully |
| 16:33.55 | kunigami | I had mistyped the command to DBRLCAD-BUNDLED_LIBS=Bundled sorry :( |
| 16:34.09 | abhi2011 | :) |
| 16:36.13 | abhi2011 | and strangely some of the functions in libfb are defined with struct RLEColorMap * but are passed struct ColorMap * , leading to a lot of warnings |
| 16:37.10 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 16:40.07 | starseeker | abhi2011, kunigami: if you guys can use cmake-gui, it will show you the most common "user" options |
| 16:50.53 | CIA-62 | BRL-CAD: 03starseeker * r46205 10/brlcad/trunk/src/librt/primitives/ (poly/poly.c table.c): add a bbox routine for poly - pretty minimal shifting of the logic, as this is on its way out anyway. |
| 16:54.11 | kunigami | starseeker: do you know if it is available for mac? |
| 16:55.55 | brlcad | abhi2011: why did you add fb.h to orle.h ? |
| 16:56.14 | brlcad | orle shouldn't need fb.h iirc |
| 16:57.08 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 16:58.39 | CIA-62 | BRL-CAD: 03brlcad * r46206 10/brlcad/trunk/src/fb/ (cmap-crunch.c fb-cmap.c fb-orle.c fbpoint.c): remove authors, revision control tracks actual authorship |
| 17:00.31 | bhinesley | kunigami: not sure about your question, but fyi the curses version, ccmake, will achieved the same end |
| 17:03.49 | kunigami | bhinesley: I'll take a look on that. thanks! |
| 17:07.23 | abhi2011 | brlcad: that was to allow the declaration of struct ColorMap to be available, I had modified the declaration of rle_wmap() to be rle_wmap(FILE *, ColorMap *); as a ColorMap* was being passed to it in fb-orle.c |
| 17:07.46 | abhi2011 | But i later changed it to rle_wmap(FILE *, RLEColorMap *); |
| 17:08.06 | abhi2011 | when I checked the definition of rle_wmap() |
| 17:08.32 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 17:09.00 | CIA-62 | BRL-CAD: 03brlcad * r46207 10/brlcad/trunk/src/fb/fb-orle.c: the structures are just coincidentally the same, so we need to copy the color map values before passing to rle_wmap. if fbio's structure ever changed, the hard cast would have been a potentially nasty bug to diagnose. |
| 17:09.22 | abhi2011 | So my question is I do get a lot of warnings (which of course are treated as errors), wherever a struct RLEColorMap * should be passed instead of struct ColorMap* |
| 17:09.26 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 17:10.45 | abhi2011 | brlcad: ok so I can copy the struct ColorMap values to a struct RLEColorMap instead and pass a struct RLEColorMap* as expected |
| 17:13.09 | CIA-62 | BRL-CAD: 03brlcad * r46208 10/brlcad/trunk/src/fb/ (cmap-crunch.c fb-cmap.c fb-orle.c fb-rle.c): ws indent style cleanup |
| 17:13.31 | brlcad | abhi2011: yeah, that's probably better |
| 17:13.37 | abhi2011 | ok |
| 17:13.52 | brlcad | I'm actually not 100% positive that they're actually compatible too, but that's how the code is presently written |
| 17:14.02 | brlcad | the new rle color maps have a different ordering iirc |
| 17:14.59 | CIA-62 | BRL-CAD: 03brlcad * r46209 10/brlcad/trunk/include/orle.h: shouldn't need fb.h here |
| 17:16.24 | brlcad | abhi2011: coincidentally, that's why the compiler warnings are a good thing -- we wouldn't have known that a struct was being implicitly converted until the arg list was added to the function prototype |
| 17:17.31 | CIA-62 | BRL-CAD: 03kunigami * r46210 10/osl/trunk/jpeg-8c/ (180 files): oiio also depends on jpge |
| 17:17.45 | starseeker | kunigami: cmake? sure |
| 17:17.46 | abhi2011 | brlcad: ok I ll explicitly specify the struct members while copying instead of a plain A = B |
| 17:19.19 | starseeker | kunigami: http://www.cmake.org/files/v2.8/cmake-2.8.5-Darwin-universal.dmg |
| 17:23.41 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 17:29.04 | brlcad | kunigami: heh, the list just keeps growing :) |
| 17:29.29 | kunigami | brlcad: libtiff is coming too! |
| 17:29.33 | brlcad | :) |
| 17:30.38 | brlcad | kunigami: it's a good thing OSL is actually worth it ... can't wait to see a full detail rendering run over a weekend |
| 17:31.06 | kunigami | brlcad: :) |
| 17:31.08 | starseeker | isn't sure if brlcad is making an assertion or a challenge :-P |
| 17:31.18 | kunigami | hehe |
| 17:32.46 | CIA-62 | BRL-CAD: 03starseeker * r46211 10/brlcad/trunk/src/librt/primitives/ (bspline/bspline.cpp table.c): Take a stab at a bbox routine for brep. Like poly, not going to put much effort into this one - in this can't won't even hook it into prep. |
| 17:33.10 | starseeker | hmm s/can't/case |
| 17:33.42 | brlcad | and s/brep/bspline/ |
| 17:34.03 | starseeker | er, yeah |
| 17:34.37 | brlcad | is excited, actually getting 3D geometry for the logo |
| 17:34.49 | brlcad | though that will be fun to model in BRL-CAD |
| 17:37.34 | kunigami | by far, the thing that is taking more time is to add entries on subversion/config of files without extension :( |
| 17:37.57 | starseeker | kunigami: yep, always a problem when adding an external repo |
| 17:38.48 | brlcad | kunigami: write a script? |
| 17:39.00 | brlcad | they're all header files, no? |
| 17:39.06 | starseeker | notes that the moose is out, abstract art is in ;-) |
| 17:39.38 | kunigami | brlcad: I wrote a script to tell which files are not covered by config before adding them https://gist.github.com/1150253 |
| 17:39.42 | brlcad | the moose isn't necessarily out, but the other won had considerably more votes |
| 17:39.51 | brlcad | s/won/one/ jessh |
| 17:40.19 | kunigami | maybe I can assume a default (svn:eol-style=native;svn:mime-type=text/plain) in those cases |
| 17:41.08 | brlcad | maybe I'm missing something, but you should be able to add most all of boost with a 'find' command one-liner |
| 17:42.28 | brlcad | starseeker: I think what'll amount to is a mix -- the moose is still the mascot, just the logo doesn't necessarily refer to it |
| 17:42.38 | starseeker | nods |
| 17:42.41 | brlcad | like how redhat's is a hat, even though the mascot is a penguin |
| 17:43.00 | brlcad | or ubuntu with the three holding hands |
| 17:43.51 | bhinesley | what could cause the compiler to warn about variables as being "set but not used", when they are in fact set and used (in rec.c vars:magsq_c/magsq_d)? |
| 17:44.11 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 17:44.52 | bhinesley | oh gosh, n/m I was in the wrong function with the same vars |
| 17:45.12 | starseeker | bhinesley: that's a consequence of the bbox function logic moving |
| 17:45.13 | brlcad | kunigami: cp boost /path/to/svn/boost ; cd /path/to/svn ; find boost -type d -exec svn add {} \; -type f -exec svn add {} \; -exec svn ps svn:eol-style native {} \; -exec svn ps svn:mime-type text/plain {} \; |
| 17:45.23 | brlcad | something like that at least, should do the trick |
| 17:45.26 | starseeker | magsq_c and magsq_d are apparently not used in prep now |
| 17:45.33 | kunigami | brlcad: now I'm not sure we're talking about the same things. Here are the files of libtiff that svn won't know how to set mime-type/eol-style: http://paste.ubuntu.com/668472/ |
| 17:46.31 | brlcad | yeah, so I'd just take that list as-is, set them as text/plain and move on :) |
| 17:47.17 | brlcad | cat log | awk '{print $4}' | xargs svn ps svn:eol-style native |
| 17:47.18 | brlcad | <PROTECTED> |
| 17:47.21 | CIA-62 | BRL-CAD: 03starseeker * r46212 10/brlcad/trunk/src/librt/primitives/rec/rec.c: compilers should be happy. |
| 17:48.06 | kunigami | hmmm I didn't know that it was a command to set it. I was editing the config file manually >.< |
| 17:49.24 | bhinesley | starseeker: yeah sorry, I would have removed them but went to the wrong function and it looked fine :-| |
| 17:49.37 | starseeker | np - my fault, it was my change |
| 17:49.51 | bhinesley | ah |
| 17:50.17 | starseeker | is extracting bounding box logic from prep routines - occasionally messy |
| 17:52.36 | brlcad | kunigami: oh dear!... |
| 17:53.18 | brlcad | kunigami: http://brlcad.org/wiki/Mime-types |
| 17:53.38 | brlcad | specifically, the part near the end |
| 17:54.06 | kunigami | I should have read past the 5th line too :( |
| 18:03.22 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 18:07.17 | CIA-62 | BRL-CAD: 03starseeker * r46213 10/brlcad/trunk/src/librt/primitives/ (ebm/ebm.c table.c): ebm bbox routine. |
| 18:14.46 | CIA-62 | BRL-CAD: 03starseeker * r46214 10/brlcad/trunk/src/librt/primitives/ (table.c vol/vol.c): vol is basically a variation on ebm as far as bbox goes. |
| 18:16.37 | CIA-62 | BRL-CAD: 03bhinesley * r46215 10/brlcad/trunk/src/libged/edit.c: |
| 18:16.37 | CIA-62 | BRL-CAD: Testing "translate -k -x 3 -a -y 5 shp" revealed that the default "to" points |
| 18:16.37 | CIA-62 | BRL-CAD: (ex: x/z of -a) were being set to shp's bb-ctr, rather than the kp specified |
| 18:16.37 | CIA-62 | BRL-CAD: with -k (which in turn defaults points to the bb-ctr of shp). That cmd should |
| 18:16.37 | CIA-62 | BRL-CAD: move the bb-ctr of shp to y=5 and not change its x/z pos (the -k part is |
| 18:16.38 | CIA-62 | BRL-CAD: superflous). It was moving the y-axis, but was also moving on the x-axis an |
| 18:16.39 | CIA-62 | BRL-CAD: amount equal to the difference between the bb ctr of shp and x=3. |
| 18:17.03 | brlcad | starseeker: the good news is that all counts towards GS/GE work |
| 18:17.34 | *** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 18:21.38 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 18:32.03 | starseeker | brlcad: question - looking at bn_tol in bn.h, the comments say double perp; /**< @brief nearly 0 */ but BN_VECT_ARE_PARALLEL is doing NEAR_EQUAL comparisions between _tol->perp and -1.0/1.0. Won't those always be false? |
| 18:44.58 | CIA-62 | BRL-CAD: 03kunigami * r46216 10/osl/trunk/tiff-3.9.5/ (447 files in 26 dirs): oiio also depends on tiff |
| 18:51.02 | brlcad | starseeker: I believe the comment is misleading |
| 18:52.32 | bhinesley | starts cracking on docbook |
| 18:53.08 | brlcad | starseeker: oh, my bad -- it's right |
| 18:53.19 | CIA-62 | BRL-CAD: 03kunigami * r46217 10/osl/trunk/compile.sh: added rules for jpeg and tiff |
| 18:54.07 | brlcad | perp is close to zero, the comparison isn't between tol->perp and -1.0/1.0 .. it's between the dot product value and -1/1 .. within a tol->perp near-zero tolerance |
| 18:55.19 | brlcad | since the dot product is already range clamped, the tight distance tolerance becomes too tight.. you want a different tolerance close to zero but bigger than SMALL_FASTF, probably even bigger than 0.0005 |
| 18:56.18 | brlcad | interestingly enough, looks like it's 1e-6 in most places I can find |
| 18:56.53 | starseeker | there's an RT_DOT_TOL in the header, but I'm not sure it's used |
| 18:57.09 | brlcad | hm, 0 in some places 0.001 (which feels right) in others, and 1e-6 in most places (feels too tight) |
| 18:57.51 | brlcad | heh, nice relevant comment in libbn/plane.c |
| 18:57.57 | brlcad | <PROTECTED> |
| 18:57.58 | CIA-62 | BRL-CAD: 03starseeker * r46218 10/brlcad/trunk/src/librt/primitives/ (arbn/arbn.c table.c): |
| 18:57.59 | CIA-62 | BRL-CAD: Make a stab at arbn bbox. This is another one where prep won't call the bbox |
| 18:57.59 | CIA-62 | BRL-CAD: routine directly, since it needs the same work for other stuff. Tried to pix |
| 18:57.59 | CIA-62 | BRL-CAD: sensible defaults for tolerances, since we don't pass a tolerance into this |
| 18:57.59 | CIA-62 | BRL-CAD: function. |
| 18:58.47 | brlcad | looks like RT_DOT_TOL isn't used |
| 18:59.01 | starseeker | growl. It should be |
| 18:59.20 | brlcad | used during typein |
| 18:59.27 | brlcad | for hyp and ehy |
| 18:59.40 | starseeker | needs something in the arbn bbox routine |
| 18:59.53 | starseeker | sure don't want to hardcode a number |
| 19:00.20 | brlcad | looks like cline, ehy, epa, hyp, nmg, red, revolve, rhc, rpc, and tgc use RT_DOT_TOL internally |
| 19:00.44 | brlcad | so it is used.. just probably not in all the places it should |
| 19:00.52 | starseeker | nods |
| 19:03.33 | starseeker | yipe - pipe bbox is going to be a bit of fun |
| 19:07.06 | bhinesley | s/yipe/yipee |
| 19:07.41 | brlcad | starseeker: just call bbox on all the individual tgc and sph elements |
| 19:07.49 | brlcad | er, tor |
| 19:08.22 | starseeker | brlcad: actually, as I'm digging in it looks like there's already some more or less split out functionality for this |
| 19:08.33 | brlcad | hm, okay |
| 19:08.51 | starseeker | rt_bend_pipe_prep deals pretty much entirely with per-bend bbox issues,fromt he looks of it - just a head insertion at the end |
| 19:09.31 | starseeker | oh, wait - hmm |
| 19:09.38 | starseeker | scratch that, it is mixed abit |
| 19:10.29 | starseeker | that bp struct is not a throwaway |
| 19:11.08 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 19:11.34 | starseeker | and we do need this logic, otherwise it becomes possible (I think) to create pipes with really really bad bboxes |
| 19:16.40 | CIA-62 | BRL-CAD: 03r_weiss * r46219 10/brlcad/trunk/src/libbn/plane.c: (log message trimmed) |
| 19:16.41 | CIA-62 | BRL-CAD: Within file 'plane.c' updated functions 'bn_coplanar', 'bn_isect_2planes' and |
| 19:16.41 | CIA-62 | BRL-CAD: 'bn_isect_lseg3_lseg3_new'. Corrected a bug in 'bn_coplanar' when computing the |
| 19:16.41 | CIA-62 | BRL-CAD: distance between planes. Within function 'bn_isect_2planes' changed some |
| 19:16.41 | CIA-62 | BRL-CAD: floating point compares from zero to SMALL_FASTF and improved the comments. |
| 19:16.41 | CIA-62 | BRL-CAD: Within 'bn_isect_lseg3_lseg3_new' fixed a bug when line segments are colinear |
| 19:16.42 | CIA-62 | BRL-CAD: and the intersection in on the end point(s), the clamping of the exact end point |
| 19:40.18 | brlcad | now that's some good stuff |
| 19:40.49 | brlcad | r_weiss should get to more nitty gritty libbn review like that instead of futzing with nmg! |
| 19:41.08 | brlcad | someone should go pat him on the back, that's more like it :) |
| 19:42.23 | brlcad | except for the whole bn_isect_lseg3_lseg3_new() |
| 19:44.11 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 19:50.40 | CIA-62 | BRL-CAD: 03r_weiss * r46220 10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: Updated function 'nmg_ck_vert_on_fus' within file 'nmg_misc.c'. Simplified logic, did some code cleanup. Removed an unnecessary floating point compare to zero. |
| 20:09.18 | CIA-62 | BRL-CAD: 03kunigami * r46221 10/osl/trunk/compile.sh: oiio will add /dist, no need to do that with $prefix |
| 20:17.03 | CIA-62 | BRL-CAD: 03starseeker * r46222 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: Richard pointed out a pre-existing nmg bounding box function - use that. |
| 20:22.42 | bhinesley | considers investigating how much work it would be to get linkends between manual pages working |
| 20:24.34 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 20:28.34 | CIA-62 | BRL-CAD: 03bhinesley * r46223 10/brlcad/trunk/doc/docbook/system/mann/en/ (CMakeLists.txt Makefile.am translate.xml): Add placeholders for edit/translate commands |
| 20:29.07 | bhinesley | oops |
| 20:33.17 | CIA-62 | BRL-CAD: 03bhinesley * r46224 10/brlcad/trunk/doc/docbook/system/mann/en/ (edit.xml translate.xml): Overwrote translate.xml last commit... reverting and adding edit |
| 20:55.35 | CIA-62 | BRL-CAD: 03bhinesley * r46225 10/brlcad/trunk/doc/docbook/system/mann/en/ (CMakeLists.txt Makefile.am edit-translate.xml): |
| 20:55.35 | CIA-62 | BRL-CAD: Unless mged's translate command is deprecated, we'll need two sets of |
| 20:55.35 | CIA-62 | BRL-CAD: "translate" manuals. Name the new page "edit translate", where the command will |
| 20:55.35 | CIA-62 | BRL-CAD: display the page. Don't mention the Archer alias "translate", since the same man |
| 20:55.35 | CIA-62 | BRL-CAD: page will be seen in mged. |
| 20:56.16 | CIA-62 | BRL-CAD: 03r_weiss * r46226 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: |
| 20:56.16 | CIA-62 | BRL-CAD: Added a new function 'nmg_isect_2faceuse' to file 'nmg_inter.c' which finds the |
| 20:56.16 | CIA-62 | BRL-CAD: intersection line between two faceuse. This new function is based on function |
| 20:56.16 | CIA-62 | BRL-CAD: bn_isect_2planes but can better determine coplanar and parallel faceuse because |
| 20:56.18 | CIA-62 | BRL-CAD: vertex distances to the faceuse planes are used instead of the angle between the |
| 20:56.18 | CIA-62 | BRL-CAD: planes and the distance between the planes at their point closest to the origin. |
| 21:19.29 | CIA-62 | BRL-CAD: 03n_reed * r46227 10/brlcad/trunk/src/conv/obj-g_new.c: minor style and ws changes |
| 21:25.17 | CIA-62 | BRL-CAD: 03n_reed * r46228 10/brlcad/trunk/src/libgcv/wfobj/obj_parser.cpp: minor readability changes |
| 21:38.22 | CIA-62 | BRL-CAD: 03n_reed * r46229 10/brlcad/trunk/src/libgcv/wfobj/ (obj_grammar.h.in obj_grammar.yy obj_grammar.yy obj_rules.ll): Replaced Bison parser input with Lemon parser input. Parser gives identical output for a lot of input obj files, but there are still some discrepancies that need to get worked out. |
| 21:39.26 | brlcad | woot! |
| 21:45.17 | CIA-62 | BRL-CAD: 03starseeker * r46230 10/brlcad/trunk/src/librt/primitives/ (rpc/rpc.c table.c): Add rpc bbox routine - while we're at it, make a tighter bbox instead of bounding the bounding sphere. |
| 21:46.14 | starseeker | go n_reed! |
| 21:48.55 | CIA-62 | BRL-CAD: 03bhinesley * r46231 10/brlcad/trunk/src/libged/edit.c: |
| 21:48.55 | CIA-62 | BRL-CAD: I've been using the "translate" alias to test, so I didn't notice that the |
| 21:48.55 | CIA-62 | BRL-CAD: calling the edit command directly was recently broken. It was trying to call |
| 21:48.55 | CIA-62 | BRL-CAD: subcommand functions of the edit help command, which don't exist. Fixed other |
| 21:48.55 | CIA-62 | BRL-CAD: small problems with the help system. I replaced some 1-off goto's with the code |
| 21:48.56 | CIA-62 | BRL-CAD: they were redirecting to, to please the Lords of Kobol. |
| 21:50.00 | CIA-62 | BRL-CAD: 03r_weiss * r46232 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: |
| 21:50.00 | CIA-62 | BRL-CAD: Within file 'nmg_inter.c' updated function 'nmg_isect_two_generic_faces' and |
| 21:50.00 | CIA-62 | BRL-CAD: disabled functions 'nmg_isect_nearly_coplanar_faces' and |
| 21:50.00 | CIA-62 | BRL-CAD: 'nmg_isect_coplanar_edges' to quiet compiler errors/warnings because they are no |
| 21:50.00 | CIA-62 | BRL-CAD: longer used. Simplified the function 'nmg_isect_two_generic_faces' which was |
| 21:50.00 | CIA-62 | BRL-CAD: possible by using the new function 'nmg_isect_2faceuse'. |
| 21:55.14 | CIA-62 | BRL-CAD: 03r_weiss * r46233 10/brlcad/trunk/include/raytrace.h: Updated include file 'raytrace.h' to add the new function 'nmg_isect_2faceuse'. |
| 21:56.47 | CIA-62 | BRL-CAD: 03starseeker * r46234 10/brlcad/trunk/src/librt/primitives/rpc/rpc.c: comment doesn't apply anymore |
| 22:02.14 | CIA-62 | BRL-CAD: 03r_weiss * r46235 10/brlcad/trunk/src/librt/bbox.c: Updated file 'bbox.c' to stop compiler errors. |
| 22:14.48 | starseeker | wonders if smaller rpc bounding boxes are technically user visible... |
| 22:14.56 | starseeker | may have minor raytrace consequences |
| 22:49.42 | CIA-62 | BRL-CAD: 03r_weiss * r46236 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: Updated function 'nmg_ck_fu_verts' in file 'nmg_fuse.c'. Fixed a bug which caused a seg fault if a loopuse contained a single vertex instead of an edgeuse. Also did some code cleanup. |
| 22:51.38 | CIA-62 | BRL-CAD: 03kunigami * r46237 10/osl/trunk/boost/boost/math/policies/error_handling.hpp: workaround to resolve the problem with -fno-rtti and typeid. I've commented out... it wont change the logic of the program since typeid was only used to compose a print message |
| 22:52.31 | CIA-62 | BRL-CAD: 03kunigami * r46238 10/osl/trunk/compile.sh: osl was being wrongly build in /dest/dest/ |
| 00:26.06 | CIA-62 | BRL-CAD: 03kunigami * r46239 10/brlcad/trunk/src/liboptical/ (render_svc.cpp render_svc.h): the osl that I commited on svn defines a few more pure virtual functions. added definitons for these functions copying from /osl/src/testshade/ |
| 01:33.06 | abhi2011 | brlcad: regarding the bb function in librt, there was a issue with wdb_put_internal() always freeing the passed rt_db_internal * |
| 01:33.28 | abhi2011 | well making the rt_db_internal * parameter constant makes no difference |
| 01:34.39 | abhi2011 | the compiler discards the const qualifier and throws a warning : warning: passing argument 3 of ‘wdb_put_internal’ discards qualifiers from pointer target type , which is due to the same parameter not being declarared as const in wdb_put_internal() |
| 01:35.45 | abhi2011 | so I currently allow it to be freed and look it up again afterwards using db_lookup() and rt_db_get_internal() |
| 01:37.28 | abhi2011 | however after this, when I try to walk the tree for a combination, using db_functree(dbip, dp, comb_func, leaf_func, &rt_uniresource, NULL) the comb_func gets called as expected when the combination is detected |
| 01:37.54 | abhi2011 | but the leaf_func for the leaves of the combination, is not called |
| 01:40.16 | abhi2011 | instead db_lookup() reports missing primitives, so I don't think the primitives' information is still available for adding to the in-mem dbip , using db_functree() |
| 01:43.04 | abhi2011 | here is the modified code : http://bin.cakephp.org/view/1374634731 not committed yet as it does not work yet |
| 02:11.55 | bhinesley | abhi2011: it doesn't have to work to commit, it just has to build strict |
| 02:29.05 | bhinesley | abhi2011: there must not be any solids in your combination |
| 02:35.17 | bhinesley | redacts his last statement |
| 02:35.47 | bhinesley | I don't know what's happening, so personally, I would examine the tree in gdb |
| 04:07.36 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 06:56.10 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 07:44.25 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 09:51.45 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 10:34.10 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 10:40.29 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 11:41.44 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 11:44.45 | *** join/#brlcad juanman (~quassel@201.255.22.2) | |
| 11:44.51 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 11:57.49 | kunigami | is it possible to a script permanently set an environment variable? after building osl I'd like brl-cad to know where it is installed. any other option to do that? (maybe a config file...) |
| 11:59.35 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 12:07.34 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 12:09.39 | starseeker | kunigami: which part of BRL-CAD needs to know where osl is? |
| 12:10.35 | kunigami | starseeker: the cmake at liboptical and at other/osl/shaders |
| 12:15.27 | CIA-62 | BRL-CAD: 03kunigami * r46240 10/osl/trunk/compile.sh: added option to compile each library alone |
| 12:15.43 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 12:49.09 | starseeker | kunigami: I'd suggest looking at what we do for the src/other libraries |
| 12:49.44 | starseeker | however, if it's always going to be installed first, you probably want find_library |
| 12:50.01 | starseeker | or write a FindOSL.cmake file |
| 12:56.44 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 12:56.46 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:09.00 | CIA-62 | BRL-CAD: 03tbrowder2 * r46241 10/brlcad/trunk/sh/conversion.sh: added an OPATH (object path); added 's' to seconds displays; wrapped a long line for ease of checking output format |
| 13:09.38 | CIA-62 | BRL-CAD: 03tbrowder2 * r46242 10/brlcad/trunk/NEWS: updated for change to conversion.sh |
| 13:10.18 | CIA-62 | BRL-CAD: 03tbrowder2 * r46243 10/brlcad/trunk/NEWS: corrected my last entry |
| 13:11.07 | CIA-62 | BRL-CAD: 03tbrowder2 * r46244 10/brlcad/trunk/NEWS: wrapped overflowing entry |
| 13:22.58 | kunigami | starseeker: but src/other libraries are build together with brl-cad, so it can set cmake variables that brl-cad sees. osl is build separately and is not necessarily build in any default place or a fixed place relative to brl-cad, so unless osl itself informs cmake, I don't see how find_library or FindOSL would be able to find it |
| 13:41.25 | CIA-62 | BRL-CAD: 03kunigami * r46245 10/osl/trunk/openexr/configure: missing pthread flag on tests |
| 13:42.51 | CIA-62 | BRL-CAD: 03kunigami * r46246 10/osl/trunk/openexr/exrenvmap/main.cpp: missing string.h library |
| 13:43.25 | CIA-62 | BRL-CAD: 03kunigami * r46247 10/osl/trunk/openexr/exrmaketiled/main.cpp: missing string.h library |
| 13:44.56 | CIA-62 | BRL-CAD: 03kunigami * r46248 10/osl/trunk/oiio/src/ico.imageio/icooutput.cpp: missing zlib.h header |
| 14:15.15 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 15:06.46 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 15:06.54 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 15:13.45 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 15:24.24 | starseeker | FindOSL would work like any other find_package file |
| 15:24.40 | starseeker | assuming you're installing osl somewhere standard |
| 15:31.31 | dli | starseeker, what does this mean? http://pastebin.com/hHMAsVYd |
| 15:45.07 | starseeker | dli: I can't see that site - can you use another pastebin? (mozilla's should work) |
| 15:45.37 | dli | starseeker, never mind, I guess it's due to gentoo cmake-utils eclass changes, fixed already |
| 15:45.51 | starseeker | cool |
| 15:46.29 | dli | starseeker, pushed to overlay, when will 7.20.4 be released? |
| 15:46.52 | dli | starseeker, either I should try to make cmake work for 7.20.2 or just wait for 7.20.4 |
| 16:02.36 | starseeker | would recommend waiting for 7.20.5 |
| 16:02.40 | starseeker | er 7.20.4 |
| 16:03.03 | CIA-62 | BRL-CAD: 03starseeker * r46249 10/brlcad/trunk/src/librt/primitives/ (part/part.c table.c): Add a bbox routine for part |
| 16:06.30 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 16:06.47 | CIA-62 | BRL-CAD: 03starseeker * r46250 10/brlcad/trunk/NEWS: Tightened the bounding boxes for rpc primitives, particularly axis aligned rpcs - should slightly speed up rpc raytracing. |
| 16:10.31 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 16:16.58 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 16:20.17 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 16:22.46 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 16:30.23 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 17:28.58 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 17:33.13 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 17:42.05 | CIA-62 | BRL-CAD: 03kunigami * r46251 10/osl/trunk/osl/src/cmake/externalpackages.cmake: on ubuntu, llvm is installed in /usr/lib/llvm-2.8/include - how to specify this path to cmake such that it works for any library version? |
| 17:42.47 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 17:52.18 | CIA-62 | BRL-CAD: 03starseeker * r46252 10/brlcad/trunk/ (3 files in 3 dirs): epa bbox routine - also improved bounding boxes for epa, similar arrangement to the rpc. |
| 18:02.18 | CIA-62 | BRL-CAD: 03starseeker * r46253 10/brlcad/trunk/ (3 files in 3 dirs): Add improved bounding box logic for ehy, based on epa improvements. |
| 18:08.08 | kunigami | I'd like to use svn external do bring libz and libpng together with osl. Is it "svn propset svn:external https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/src/other/libz osl" ? |
| 18:18.20 | kunigami | command that worked: svn propset svn:externals 'https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/src/other/libz libz' . |
| 18:22.39 | CIA-62 | BRL-CAD: 03starseeker * r46254 10/brlcad/trunk/src/librt/primitives/ (eto/eto.c table.c): Add bbox routine for eto. |
| 18:24.36 | CIA-62 | BRL-CAD: 03n_reed * r46255 10/brlcad/trunk/src/libgcv/wfobj/ (obj_grammar.yy obj_parser.cpp obj_parser_state.h): storing lemon parser-handle in combined state object |
| 18:30.50 | CIA-62 | BRL-CAD: 03kunigami * r46256 10/osl/trunk/: adding libz and libpng as external dependence of osl/trunk |
| 18:41.52 | CIA-62 | BRL-CAD: 03kunigami * r46257 10/osl/trunk/compile.sh: added compile targets for libz and libpng |
| 18:47.35 | CIA-62 | BRL-CAD: 03starseeker * r46258 10/brlcad/trunk/src/librt/primitives/ (hf/hf.c table.c): add an hf bbox routine - not too worried about this one as hf is on its way out. |
| 18:48.47 | kunigami | hmmm osl is seg faulting with the local builds :( maybe it didn't like some of the versions. |
| 18:57.43 | CIA-62 | BRL-CAD: 03kunigami * r46259 10/osl/trunk/: svn propset svn:externals is not additive. have to specify all external dependences at once |
| 18:59.44 | CIA-62 | BRL-CAD: 03starseeker * r46260 10/brlcad/trunk/src/librt/primitives/ (dsp/dsp.c table.c): dsp bbox routine - this is another one that has to dupliate a lot of prep, so don't double up on the work - leave the prep calculations as-is. |
| 19:08.04 | CIA-62 | BRL-CAD: 03kunigami * r46261 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h osl_rt.cpp sh_osl.cpp): removed unnused code, debug messages and the old AddShader, which is not to be used |
| 19:11.47 | CIA-62 | BRL-CAD: 03bhinesley * r46262 10/brlcad/trunk/doc/docbook/system/mann/en/edit.xml: Started manual; more specifics on the argument style are needed. WIP |
| 19:11.52 | CIA-62 | BRL-CAD: 03kunigami * r46263 10/brlcad/trunk/src/liboptical/ (CMakeLists.txt Makefile.am osl_rt.cpp): deleting the stand-alone osl rt. It was already out-dated and it has no use since sh_osl is functional |
| 19:12.47 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 19:16.33 | CIA-62 | BRL-CAD: 03bob1961 * r46264 10/brlcad/trunk/src/libged/erase.c: |
| 19:16.34 | CIA-62 | BRL-CAD: This reverts the fix for r45409 (i.e. ged_splitGDL was no longer splitting |
| 19:16.34 | CIA-62 | BRL-CAD: things correctly. This caused a noticeable performance issue as well as the |
| 19:16.34 | CIA-62 | BRL-CAD: results of 'who' being wrong). The segmentation fault problem was resolved in |
| 19:16.34 | CIA-62 | BRL-CAD: _ged_eraseFirstSubpath. |
| 19:16.35 | plaes | kunigami: it could be running against system library |
| 19:16.58 | plaes | ldd is your friend ;) |
| 19:17.58 | kunigami | yup, ldd tells me it is using brlcad version. but that was the objective. I'm testing in a system with minimal system libraries to check if the libraries we're providing are enough |
| 19:33.36 | CIA-62 | BRL-CAD: 03starseeker * r46265 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: gah - extrude bbox logic is pretty close to worst case - don't see any immedate way to do a bbox better, so just try to do a 'self-contained' version that doesn't use stp structures and cleans up after itself. |
| 19:34.40 | CIA-62 | BRL-CAD: 03starseeker * r46266 10/brlcad/trunk/src/librt/primitives/table.c: whoops, add to table.c |
| 19:36.03 | CIA-62 | BRL-CAD: 03kunigami * r46267 10/osl/trunk/jpeg-8c/Makefile.in: missing file... |
| 19:39.07 | starseeker | humph - the way submodel is set up, I can't do a bbox routine for it without adding an rtip parameter |
| 19:41.51 | CIA-62 | BRL-CAD: 03kunigami * r46268 10/osl/trunk/tiff-3.9.5/Makefile.in: doh! missing file... |
| 19:48.09 | CIA-62 | BRL-CAD: 03kunigami * r46269 10/osl/trunk/tiff-3.9.5/ (23 files in 23 dirs): hmm! actually there are a lot more Makefile.in |
| 20:37.05 | CIA-62 | BRL-CAD: 03kunigami * r46270 10/osl/trunk/compile.sh: set linker path for linux env and make oiio use tbb |
| 20:54.37 | kunigami | here's the backtrace of the segfault: http://paste.ubuntu.com/669543/ -- the program does not even finished to load... it seems to be a runtime linking error |
| 21:00.31 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 21:31.43 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 21:37.47 | bhinesley | starseeker: what handles the generation of html files from docbook format? Using synopfragment tags would be really nice for my uses, but they're not getting formatted correctly. |
| 21:38.15 | bhinesley | I'll take a look at it if you can point me in the right direction |
| 21:39.12 | starseeker | um... the docbook stylesheets probably control that |
| 21:39.46 | starseeker | we haven't customized any of our output from docbook yet - that's a bit of a job |
| 21:40.02 | bhinesley | seems odd that they wouldn't format their own tag correctly |
| 21:41.07 | bhinesley | investigates |
| 21:46.27 | CIA-62 | BRL-CAD: 03starseeker * r46271 10/brlcad/trunk/src/librt/primitives/ (cline/cline.c table.c): add bbox routine for cline |
| 21:51.02 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 21:56.41 | CIA-62 | BRL-CAD: 03starseeker * r46272 10/brlcad/trunk/src/librt/primitives/ (superell/superell.c table.c): break out bbox logic for superell |
| 22:16.57 | CIA-62 | BRL-CAD: 03starseeker * r46273 10/brlcad/trunk/src/librt/primitives/ (4 files in 2 dirs): metaballs already had most of the bbox functionality broken out - make it conform to the new functab setup and have it call the sphere routine itself to make it standalone. |
| 22:45.23 | CIA-62 | BRL-CAD: 03starseeker * r46274 10/brlcad/trunk/src/librt/primitives/ (brep/brep.cpp table.c): |
| 22:45.24 | CIA-62 | BRL-CAD: Do the simple thing with rt_brep_bbox and call the openNURBS routine - a quick |
| 22:45.24 | CIA-62 | BRL-CAD: check results in a pretty good bbox, although we'll stick with the bvh result |
| 22:45.24 | CIA-62 | BRL-CAD: for prep. The fact that bi->brep is NULL'ed by prep is a bit worrisome, leading |
| 22:45.24 | CIA-62 | BRL-CAD: to questions about whether this routine will work after raytrace - why are we |
| 22:45.24 | CIA-62 | BRL-CAD: NUll'ing the bi->brep during prep? |
| 23:12.47 | CIA-62 | BRL-CAD: 03starseeker * r46275 10/brlcad/trunk/src/librt/primitives/ (hyp/hyp.c table.c): Go with the epa/ehy approach for hyp too. Might actually be slightly larger surface area for some views when hyp is rotated, but MUCH better than sphere for axis aligned cases. |
| 23:40.33 | CIA-62 | BRL-CAD: 03starseeker * r46276 10/brlcad/trunk/src/librt/primitives/ (revolve/revolve.c table.c): Make a stab at implementing a stand-alone bbox function for revolve - again, too much extra logic to want to have prep call it. |
| 23:44.08 | CIA-62 | BRL-CAD: 03bhinesley * r46277 10/brlcad/trunk/ (3 files in 2 dirs): |
| 23:44.09 | CIA-62 | BRL-CAD: Wrote synopsis for 'edit translate'. It looks fine in brlman, but there is a |
| 23:44.09 | CIA-62 | BRL-CAD: mysterious line break in the html manual browser, and no line breaks in several |
| 23:44.09 | CIA-62 | BRL-CAD: places where there should be. First priority is to fix the issue. Failing that, |
| 23:44.09 | CIA-62 | BRL-CAD: I can simply remove the synopfragment tags (which are what is breaking the |
| 23:44.09 | CIA-62 | BRL-CAD: formatting) and rearrange things a bit. Added synopsis for 'edit', and cleaned |
| 23:44.10 | CIA-62 | BRL-CAD: up indentation. |
| 23:46.45 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 23:54.00 | CIA-62 | BRL-CAD: 03starseeker * r46278 10/brlcad/trunk/src/librt/primitives/ (pnts/pnts.c table.c): Points apparently don't have any prep, but go ahead and add a bounding box function. |
| 00:34.04 | CIA-62 | BRL-CAD: 03bhinesley * r46279 10/brlcad/trunk/doc/docbook/system/mann/en/edit-translate.xml: |
| 00:34.05 | CIA-62 | BRL-CAD: Adding a few line breaks manually to make the synopsis fragments line up (like |
| 00:34.05 | CIA-62 | BRL-CAD: they're supposed to by default). Still not sure how to eliminate the one one in |
| 00:34.05 | CIA-62 | BRL-CAD: between the first and second lines (also not supposed to be there by default, |
| 00:34.05 | CIA-62 | BRL-CAD: according to examples in "DocBook 5" by O'Reilly), but it has to go. |
| 00:52.54 | CIA-62 | BRL-CAD: 03starseeker * r46280 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: |
| 00:52.55 | CIA-62 | BRL-CAD: Make the minimal changes to be able to add a bbox function for pipe that doesn't |
| 00:52.55 | CIA-62 | BRL-CAD: pass an stp pointer. Undoubtedly more optimization could be done here - the |
| 00:52.55 | CIA-62 | BRL-CAD: bbox process doesn't need to malloc and free the lp/bp storage, at least in |
| 00:52.55 | CIA-62 | BRL-CAD: principle) but for now go simple. |
| 00:53.30 | CIA-62 | BRL-CAD: 03starseeker * r46281 10/brlcad/trunk/src/librt/primitives/table.c: update table.c |
| 00:54.14 | starseeker | bhinesley: if it looks OK in a regular browser, then it's probably tkhtml's fault |
| 00:54.49 | starseeker | recalls some issue with search html... |
| 01:01.02 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 01:05.20 | CIA-62 | BRL-CAD: 03starseeker * r46282 10/brlcad/trunk/src/librt/primitives/ (rhc/rhc.c table.c): add bbox routine for rhc - this should also do much better with axis aligned rhcs. |
| 01:06.29 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 01:07.12 | starseeker | phew. probably not totally ideal, but with the possible exception of submodel I think that should cover all the primitives for which a bounding box makes sense |
| 02:47.00 | CIA-62 | BRL-CAD: 03abhi2011 * r46283 10/brlcad/trunk/src/librt/bbox.c: Modified rt_bound_internal() to use db_functree() |
| 04:27.26 | bhinesley | starseeker: it's not line breaking where it should (in any browser); but a simple fix there. However, the magic line break from nowhere only appears in the manual page browser. So it does indeed seem to be a tkhtml (er hv3) issue. |
| 04:45.44 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 05:06.28 | CIA-62 | BRL-CAD: 03bhinesley * r46284 10/brlcad/trunk/doc/docbook/system/mann/en/edit-translate.xml: |
| 05:06.28 | CIA-62 | BRL-CAD: hv3 was breaking the line on the first <a> tag it saw, which happened to be in |
| 05:06.28 | CIA-62 | BRL-CAD: the middle of the synopsis. I added a dummy link around a nonprintable character |
| 05:06.28 | CIA-62 | BRL-CAD: (to keep docbook from complaining) at the begining of the synopsis, and now |
| 05:06.28 | CIA-62 | BRL-CAD: everyone is happy. Also, added replaceable tags around the synopsis fragment |
| 05:06.28 | CIA-62 | BRL-CAD: references and a few other things I'd missed. |
| 07:10.56 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 09:40.22 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 09:43.29 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 09:53.43 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 11:22.04 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 12:20.16 | starseeker | bhinesley: so translate is complete? |
| 13:13.10 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:41.33 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 14:22.25 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-184-177.wlan.tudelft.nl) | |
| 14:42.42 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 14:56.49 | starseeker | reflects that someday he may have to dig deeper into the tkhtml display logic, but he dreads the prospect... |
| 15:42.13 | bhinesley | starseeker: I can't find any problems with it. There is one feature that I had originally planned on which is not implemented; an oversight(using the batch operator "." as an argument to an individual coordinate specifier "-x/-y/-z"). However, it isn't actually necessary, as you can achieve the same end another way that is just as easy. |
| 15:42.55 | bhinesley | "translate -k -x . -a 3 7 8" is identical to "translate -k . -a -x 3" |
| 15:44.45 | bhinesley | a complex use "translate -k -z 3 -y . -a -z . -y 7" would have to be broken down into 2 commands |
| 15:45.55 | bhinesley | "translate -k . -a -y 7" and "translate -k -z 3 -a ." |
| 15:51.50 | bhinesley | I don't know... what do you think? |
| 17:23.52 | CIA-62 | BRL-CAD: 03bhinesley * r46285 10/brlcad/trunk/src/libged/edit.c: clarify/cleanup/spellcheck comments |
| 17:26.01 | CIA-62 | BRL-CAD: 03bhinesley * r46286 10/brlcad/trunk/src/libged/edit.c: Remove temporary log of tests. |
| 17:31.50 | CIA-62 | BRL-CAD: 03bhinesley * r46287 10/brlcad/trunk/src/libged/edit.c: Make all functions HIDDEN (except ged_edit); their scope can be changed when they're needed. Fixed one function definition that was hosed in r46285. |
| 17:39.31 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 18:14.44 | CIA-62 | BRL-CAD: 03bhinesley * r46288 10/brlcad/trunk/doc/docbook/system/mann/en/edit-translate.xml: |
| 18:14.45 | CIA-62 | BRL-CAD: brlman was doing funny things; if I'm understanding things correctly, it looks |
| 18:14.45 | CIA-62 | BRL-CAD: like DocBook doesn't permit 'replaceable' in synopfragmentref's. In any case, |
| 18:14.45 | CIA-62 | BRL-CAD: this fixes formatting problems and makes a complicated syntax look a little |
| 18:14.45 | CIA-62 | BRL-CAD: clearer. |
| 18:29.23 | *** join/#brlcad DarkCalff (DC@173.231.40.98) | |
| 18:33.03 | *** join/#brlcad Don_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 18:36.17 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 18:43.51 | CIA-62 | BRL-CAD: 03bhinesley * r46289 10/brlcad/trunk/src/libged/edit.c: |
| 18:43.51 | CIA-62 | BRL-CAD: The reference manuals will point to the command "edit help" as the authorative |
| 18:43.51 | CIA-62 | BRL-CAD: list of which subcommands are available. Therefore, only usable commands should |
| 18:43.51 | CIA-62 | BRL-CAD: be shown. I added the capability to enable/disable commands via the command tab, |
| 18:43.51 | CIA-62 | BRL-CAD: so that it's a simple matter of setting a flag. rotate and scale are disabled, |
| 18:43.52 | CIA-62 | BRL-CAD: help and translate are enabled. |
| 18:45.26 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 18:46.59 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 19:08.28 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 19:47.22 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 20:37.42 | CIA-62 | BRL-CAD: 03starseeker * r46290 10/brlcad/trunk/ (18 files in 13 dirs): OK, for the first time a successful build of 32bit on a 64bit Linux box. |
| 21:04.57 | CIA-62 | BRL-CAD: 03starseeker * r46291 10/brlcad/trunk/CMakeLists.txt: Can't configure for 64bit then 32bit, all the find_library and find_package results are for the wrong arch. Hault configure and inform the user what needs to be done. |
| 21:34.34 | CIA-62 | BRL-CAD: 03starseeker * r46292 10/brlcad/trunk/doc/docbook/system/mann/en/ (CMakeLists.txt edit-translate.xml edit_translate.xml): Hmm, docbook man page output was getting named edit_translate.nged, so install rule didn't know to look for it. go ahead and use edit_translate.xml for the name, fixes install issue. |
| 22:22.12 | *** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no) | |
| 23:32.52 | CIA-62 | BRL-CAD: 03abhi2011 * r46293 10/brlcad/trunk/src/mged/setup.c: Linked the simulate command to the libged wrapper and libged function in the function table |
| 23:33.28 | CIA-62 | BRL-CAD: 03bhinesley * r46294 10/brlcad/trunk/src/librt/primitives/hf/hf.c: quiet compiler warning about unused var |
| 23:34.43 | CIA-62 | BRL-CAD: 03abhi2011 * r46295 10/brlcad/trunk/src/mged/cmd.h: Declared the simulate command wrapper here |
| 23:35.18 | CIA-62 | BRL-CAD: 03abhi2011 * r46296 10/brlcad/trunk/src/mged/cmd.c: Defined the simulate command wrapper here |
| 23:40.19 | abhi2011 | hmm getting an error due to mime type not set in a new c file that I am adding : src/libged/simulate.c |
| 23:43.06 | starseeker | abhi2011: http://brlcad.org/wiki/Mime-types |
| 23:43.36 | CIA-62 | BRL-CAD: 03bhinesley * r46297 10/brlcad/trunk/doc/docbook/system/mann/en/edit.xml: (log message trimmed) |
| 23:43.36 | CIA-62 | BRL-CAD: Started on description of translate command, and realized that it would be |
| 23:43.36 | CIA-62 | BRL-CAD: better if the edit page covered the general syntax more in depth, first. This |
| 23:43.36 | CIA-62 | BRL-CAD: way, subcommands will be easier to digest, and maintain the manuals. I'll still |
| 23:43.36 | CIA-62 | BRL-CAD: leave the long synopsis in the translate manual, however, to limit having to |
| 23:43.37 | CIA-62 | BRL-CAD: flip back and forth. The edit synopsis is complete; I'll have to update several |
| 23:43.38 | CIA-62 | BRL-CAD: key words throughout descriptions in both manuals to refer to the new terms used |
| 23:45.23 | abhi2011 | starseeker: thanks, I will manually add the eol and mime type for now |
| 23:47.21 | CIA-62 | BRL-CAD: 03abhi2011 * r46298 10/brlcad/trunk/src/libged/simulate.c: The Mged simulate command is implemented here(as a libged function) |
| 23:52.20 | CIA-62 | BRL-CAD: 03abhi2011 * r46299 10/brlcad/trunk/src/libged/simphysics.cpp: The C++ code for using a physics engine will go in here |
| 23:54.18 | CIA-62 | BRL-CAD: 03bhinesley * r46300 10/brlcad/trunk/doc/docbook/system/mann/en/edit_translate.xml: |
| 23:54.18 | CIA-62 | BRL-CAD: Clean up the description for the translate command, and move a paragraph to the |
| 23:54.18 | CIA-62 | BRL-CAD: edit command temporarily. This tiny translate description might actually be |
| 23:54.18 | CIA-62 | BRL-CAD: adequate, once the edit manual is done. The main thing left for the translate |
| 23:54.18 | CIA-62 | BRL-CAD: command is the examples, which should be mostly a cut/paste job. |
| 23:54.51 | CIA-62 | BRL-CAD: 03bhinesley * r46301 10/brlcad/trunk/doc/docbook/system/mann/en/edit.xml: missed a file in r46300 |
| 23:54.53 | CIA-62 | BRL-CAD: 03abhi2011 * r46302 10/brlcad/trunk/include/ged.h: The libged function that implements the simulate command is declared here |
| 23:57.18 | CIA-62 | BRL-CAD: 03abhi2011 * r46303 10/brlcad/trunk/src/libged/CMakeLists.txt: Finally, added 1 new .c and 1 .cpp file in libged to the CMake list |
| 00:01.07 | bhinesley | abhi2011: you can commit all your files at once if you want to, by using a `svn commit -m "msg"` from the parent directory of the files. Perhaps do a `svn status` to see what files would be included, and `svn diff` to confirm changes first. |
| 00:02.04 | bhinesley | abhi2011: just a friendly fyi, in case you didn't know :) |
| 00:02.23 | abhi2011 | bhinseley: thanks, yes, being a bit careful with my first commits :) |
| 00:02.35 | bhinesley | understandable :) |
| 00:05.56 | abhi2011 | bhinseley: so the gsoc coding phase is over ? |
| 00:06.42 | bhinesley | abhi2011: well, the official stop date is on Monday. The recommended stop date has passed. |
| 00:07.29 | bhinesley | I'm writing manuals for the last command I wrote |
| 00:07.33 | abhi2011 | ok |
| 00:08.29 | abhi2011 | so as I understand, you were migrating commands from mged to archer , those which were left |
| 00:12.37 | bhinesley | That's correct. I migrated a few, and then I started on the oed-related commands. I suggested a complete redesign rather than simply migrating them. brlcad liked it, we expanded on it a bit more, and I've been working on it ever since. |
| 00:13.46 | abhi2011 | cool :9 |
| 00:13.51 | abhi2011 | *:) |
| 00:14.12 | abhi2011 | I mean :) |
| 00:14.19 | bhinesley | hehe, I follow |
| 00:14.28 | abhi2011 | german keyboards ! |
| 00:14.45 | bhinesley | weird layout of the keys? |
| 00:14.59 | abhi2011 | yep : qwertz :P |
| 00:33.56 | abhi2011 | ok so a question, I want to link to the Bullet static libraries and headers |
| 00:34.51 | abhi2011 | bullet is installed in /usr/local/include/bullet and /usr/local/lib |
| 00:35.22 | abhi2011 | so what are the changes I would need to make to the CMake build system to allow the proper compilation flags to be added |
| 00:36.03 | abhi2011 | these flags must be added : -I/usr/local/include/bullet -L/usr/local/lib -lBulletDynamics -lBulletCollision -lLinearMath |
| 03:01.57 | starseeker | abhi2011: are you asking what to do to your local CMakeLists.txt file to build a BRL-CAD file that needs those libraries? |
| 03:03.56 | starseeker | a "proper" way to do it would be to add a FindBULLET.cmake file, e.g. http://code.google.com/p/mgep/source/browse/trunk/CMakeModules/FindBullet.cmake?r=506 |
| 03:04.09 | starseeker | then call find_package(BULLET) |
| 03:05.11 | starseeker | hah - cool: http://code.google.com/p/osgbullet/ |
| 03:06.17 | starseeker | or actually, there's already a FindBullet.cmake included in CMake itself - better and better |
| 03:06.26 | starseeker | abhi2011: so just do find_package(Bullet) |
| 03:06.56 | starseeker | BULLET_INCLUDE_DIRS will hold the include directory, and BULLET_LIBRARIES will hold the libs |
| 08:35.45 | *** join/#brlcad merzo (~merzo@114-136-132-95.pool.ukrtel.net) | |
| 09:43.18 | abhi2011 | starseeker: yes i am asking what to do the local CMakeLists.txt file so I can build a BRL-CAD file that needs those libraries |
| 10:22.18 | abhi2011 | ok its unable to find the headers still |
| 10:23.01 | abhi2011 | i think the BULLET_INCLUDE_DIRS will have to be added to BRLCAD_INCLUDE_FILE |
| 10:23.18 | abhi2011 | or the brlcad include path |
| 10:23.59 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 11:01.13 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 11:45.08 | starseeker | abhi2011: in your CMakeLists.txt, include_directories(${BULLET_INCLUDE_DIRS}) |
| 11:51.22 | abhi2011 | starseeker: ok, I am doing all the changes in the top level CMakeLists file, the one in the brlcad directory |
| 11:51.36 | abhi2011 | in the stage 4 of 9 section , where the libs are detected |
| 11:59.28 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 12:12.25 | abhi2011 | hmm BULLET_INCLUDE_DIR is not found by cmake : http://bin.cakephp.org/view/1479183805 |
| 12:12.38 | abhi2011 | is it an environment variable ? |
| 12:12.54 | abhi2011 | if so , then its not set, I can try setting it |
| 12:33.12 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 12:47.47 | abhi2011 | ok I put in the install folder manually : include_directories("/usr/local/include/bullet") |
| 12:50.57 | abhi2011 | now the linker flags need to be inserted : -L/usr/local/lib -lBulletDynamics -lBulletCollision -lLinearMath |
| 16:38.33 | abhi2011 | hmm I can see the FindBullet.cmake file in /usr/share/cmake/modules, will try to point CMAKE_MODULE_PATH to it |
| 16:43.41 | abhi2011 | ok, i copied FindBullet.cmake to brlcad/misc/CMake and it has found FindBullet.cmake, but now it complains that /home/abhi/socis/brlcad/misc/CMake/FindPackageHandleStandardArgs.cmake is missing |
| 16:44.30 | abhi2011 | probaby I should add the CMake directory /usr/share/cmake/modules instead and let find all the *.cmake files there |
| 16:52.03 | abhi2011 | I think I will need to SET(CMAKE_MODULE_PATH "${BRLCAD_CMAKE_DIR}; "/usr/share/cmake/modules"; ${CMAKE_MODULE_PATH}") but that would not be portable |
| 18:07.02 | abhi2011 | ok FIND_PACKAGE(Bullet) works to locate the include directories now, apparently bullet was installed in a non std location |
| 18:08.07 | abhi2011 | linking still doesnt seem to be occurring however |
| 23:33.53 | *** join/#brlcad plaes (~plaes@gn237.zone.eu) | |
| 01:12.52 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 01:12.59 | *** join/#brlcad Don_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 03:18.39 | CIA-62 | BRL-CAD: 03abhi2011 * r46304 10/brlcad/trunk/src/mged/titles.c: Check if illuminated solid still exists or it has been killed, illump and es_edflag both need to be checked |
| 03:18.44 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 06:09.47 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 06:51.47 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 12:57.30 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3080 10/wiki/User:Abhijit: /* Log */ |
| 12:59.44 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3081 10/wiki/User:Abhijit: /* Log */ |
| 13:24.19 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 13:48.49 | abhi2011 | starseeker: is there any way to check what flags are being used by the compiler when mged is being linked during the cmake build |
| 13:50.08 | abhi2011 | if the entire command used to compile is printed then I could make out if its looking at the wrong place for the libs with the -L option |
| 14:48.35 | starseeker | make VERBOSE=1 |
| 16:43.25 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 16:43.25 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 17:25.10 | abhi2011 | ok some progress on the linking issue |
| 17:25.54 | abhi2011 | so in the top level cmake file I have specified : FIND_PACKAGE(Bullet) |
| 17:25.56 | abhi2011 | LINK_DIRECTORIES("/usr/local/lib") |
| 17:28.19 | abhi2011 | apparently include_directories("/usr/local/include/bullet") is no longer needed since I am using the FindBullet.cmake file that comes with the standard cmake modules |
| 17:56.19 | abhi2011 | in the libged CMakeLists.txt file I have added BRLCAD_ADDLIB(libged "${LIBGED_SOURCES}" "libwdb librt libfb libbu libanalyze ${REGEX_LIBRARY} ${WINSOCK_LIB} ${M_LIBRARY} BulletDynamics BulletCollision LinearMath ") |
| 17:56.37 | abhi2011 | and include_directories(....${BULLET_INCLUDE_DIR}) |
| 18:04.15 | abhi2011 | however when linking libged it asks for the -fPIC flag now : (btTypedConstraint.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC |
| 18:04.41 | abhi2011 | will try adding it using C_FLAGS in cmake |
| 18:06.30 | *** join/#brlcad DarkCalfz (DC@173.231.40.98) | |
| 18:53.55 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 18:59.30 | CIA-62 | BRL-CAD: 03bhinesley * r46305 10/brlcad/trunk/doc/docbook/system/mann/en/edit.xml: The edit manual is complete, unless I think of something else to add as I'm finishing up the translate manual. |
| 20:02.49 | abhi2011 | ok I have finally got Bullet linked with libged : http://bin.cakephp.org/view/1033978153 |
| 20:03.45 | abhi2011 | Bullet produces static libs which were causing issues while compiling libged ..related to the fpic flag |
| 20:04.02 | abhi2011 | so now I have bullet dynamic libs |
| 20:04.09 | abhi2011 | and libged compiled ok |
| 20:05.01 | abhi2011 | its not recommended to link dynamically with bullet however, so have to look into why later |
| 20:41.35 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 20:47.39 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 21:13.21 | *** join/#brlcad DarkCalff (DC@173.231.40.98) | |
| 21:16.39 | *** join/#brlcad DarkCalf (~DC@173.231.40.98) | |
| 21:23.50 | *** join/#brlcad merzo (~merzo@25-83-132-95.pool.ukrtel.net) | |
| 21:24.17 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 21:25.49 | *** join/#brlcad DarkCalff (~DC@173.231.40.98) | |
| 21:28.32 | CIA-62 | BRL-CAD: 03bhinesley * r46306 10/brlcad/trunk/src/libged/edit.c: Deleted mock manuals for the edit command and the translate subcommand. |
| 21:29.31 | *** join/#brlcad DarkCalfz (DC@173.231.40.98) | |
| 21:29.34 | CIA-62 | BRL-CAD: 03bhinesley * r46307 10/brlcad/trunk/doc/docbook/system/mann/en/edit_translate.xml: Added several examples. |
| 21:34.47 | *** join/#brlcad DarkCalfz (DC@173.231.40.98) | |
| 21:36.53 | *** join/#brlcad DarkCalfz (DC@173.231.40.98) | |
| 21:40.06 | *** join/#brlcad DarkCalff (DC@173.231.40.98) | |
| 21:42.20 | CIA-62 | BRL-CAD: 03bhinesley * r46308 10/brlcad/trunk/doc/docbook/system/mann/en/edit.xml: Remove testing junk left behind. |
| 21:42.38 | CIA-62 | BRL-CAD: 03bhinesley * r46309 10/brlcad/trunk/doc/docbook/system/mann/en/edit_translate.xml: Several corrections and clarifications. |
| 21:43.37 | bhinesley | starseeker: I think that about does it for the documentation |
| 21:58.32 | *** join/#brlcad DarkCalfz (~DC@173.231.40.98) | |
| 22:08.57 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 22:29.11 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 22:29.44 | abhi2011 | yipee ! just ran a bullet simulation inside mged and it gave the right values ! |
| 22:29.48 | abhi2011 | so things have linked correctly |
| 22:33.54 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3082 10/wiki/User:Abhijit: /* Log */ |
| 22:53.29 | abhi2011 | cant commit this code yet however because it will fail to compile on machines which do not have bullet installed or installed in a non-std location |
| 22:54.27 | abhi2011 | have to add a condition in the libged/CMakeLists.txt file to exclude compiling simphysics.cpp if bullet is not detected |
| 23:47.28 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r3083 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */ |
| 02:06.02 | *** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 02:38.05 | starseeker | bhinesley: excellent! |
| 02:47.17 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 05:11.11 | abhi2011 | ok I have got objects updating inside mged now using rt_matrix_transform() according to bullet output |
| 10:44.25 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 11:48.08 | abhi2011 | ok I was wondering how conditional compiling is implemented in the build system |
| 11:48.43 | abhi2011 | so I have some files which are based on Bullet's libraries, but if Bullet is not installed then the compile will fail |
| 11:49.19 | abhi2011 | yet if these files are not compiled then a function which is called from libged will not exsist and that too would cause the build to fail |
| 11:50.05 | abhi2011 | perhaps there is a way to compile a dummy function in a separate file if bullet is not detected , so both the above errors can be avoided ? |
| 11:53.19 | kunigami1 | abhi2011: you can do something I did for OSL. take a look at Cmakelists.txt at liboptical |
| 11:53.39 | abhi2011 | kunigami1: thanks I ll take a look |
| 11:59.46 | abhi2011 | ok so you use a top level cmake flag to enable or disable osl : BRLCAD-ENABLE_OSL |
| 12:00.13 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 12:57.10 | starseeker | IF(BULLET_FOUND) could be my first guess |
| 13:07.34 | *** join/#brlcad Elrohir (~kvirc@p5B149541.dip.t-dialin.net) | |
| 13:50.19 | kunigami1 | abhi2011: by the way, to set the BLCAD-ENABLE_OSL flag there, you can call cmake with -DBRLCAD-ENABLE_OSL=ON |
| 13:54.14 | CIA-62 | BRL-CAD: 03erikgreenwald * r46310 10/brlcad/trunk/src/libged/simulate.c: #if 0 out some unused code |
| 13:54.48 | CIA-62 | BRL-CAD: 03erikgreenwald * r46311 10/brlcad/trunk/src/mged/cmd.c: remove unused variable |
| 14:00.21 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-185-238.wlan.tudelft.nl) | |
| 14:39.24 | ``Erik | fwiw, I believe today is "pencils down" for gsoc |
| 14:40.42 | ``Erik | abhi: awesome, very awesome |
| 14:47.32 | abhi2011 | yep preparing the cmake logic for commit now :) |
| 15:33.59 | CIA-62 | BRL-CAD: 03d_rossberg * r46312 10/brlcad/trunk/src/librt/ (bbox.c primitives/rpc/rpc.c): |
| 15:33.59 | CIA-62 | BRL-CAD: For the Windows build: MSVC is not C99 |
| 15:33.59 | CIA-62 | BRL-CAD: moved variable declarations upwards |
| 15:43.15 | CIA-62 | BRL-CAD: 03bob1961 * r46313 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): The rectangle used for selection was no longer being drawn due to a previous modification (i.e. not drawing rectangle if its lwidth is 0). This restores the desired behavior in Archer. |
| 15:44.55 | plaes | congrats on the new logo |
| 16:40.40 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 19:01.35 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 19:36.45 | brlcad | starseeker: for submodels, each callback is basically a mini program in itself meaning they have to open the subdatabase files (like rt and company) to do their processing |
| 19:36.58 | brlcad | responding to backlog so comments may be OBE |
| 19:45.27 | brlcad | abhi2011: there should be no reason to prefer static over dynamic libraries when linking bullet (and you shouldn't be adding /usr/local/* to the default link/search paths (e.g., LINK_DIRECTORIES)) .. that's something to be specified during cmake |
| 19:46.07 | brlcad | (i.e. that's a "non-std" location in itself) |
| 19:47.16 | brlcad | plaes: thx! it is pretty nifty |
| 19:47.40 | plaes | yup, nice and simple |
| 19:53.04 | brlcad | kunigami1: you can't export variables to a parent context so you'd have to wrap that in a script |
| 19:53.53 | plaes | are these images here created with brlcad: http://ronja.twibright.com/3d/ ? |
| 19:54.07 | brlcad | abhi2011: you can't just mark a variable as 'const' and expect it to work -- that's why I said you'd have to make a copy. if you're calling a non-const function but need the object to remain unmodified, you have to make your own copy of that object beforehand |
| 19:54.12 | brlcad | plaes: yes |
| 19:55.36 | plaes | how do I save such images? :) |
| 19:57.04 | brlcad | what do you mean? |
| 19:57.56 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 19:58.03 | plaes | well, I know that the models are made by brlcad, but how do I save such black-and-white images |
| 19:58.58 | brlcad | rtedge |
| 19:59.17 | plaes | \o/ |
| 19:59.20 | brlcad | rt is the usual renderer, but there are a handful of other rt* renderes |
| 19:59.54 | brlcad | rt and rtedge both work within mged equivalently |
| 20:00.04 | brlcad | some of the others are external to mged |
| 20:00.14 | brlcad | all can be run external |
| 20:01.09 | plaes | lots of cool stuff still hidden in all these programs ;) |
| 20:01.22 | brlcad | nods |
| 20:04.36 | plaes | building stuff with primitives is like "simulating" machining.. ;) |
| 20:06.20 | plaes | first build a part on the computer and then try it out in real life - http://timmu.store20.com/galerii/?galerie=frees |
| 20:17.45 | abhi2011 | brlcad: ok , yes I understand now |
| 20:19.43 | abhi2011 | I was checking with the db_functree() function and i saw that it tries to lookup the primitives for a combination in the dbip which I pass to it, which is of course what it should do |
| 20:20.31 | abhi2011 | and it fails as expected as the dbip does not have the primitive in it , as its the in mem db_i I made in the function |
| 20:22.20 | brlcad | plaes: that's a pretty nifty old machine there |
| 20:22.39 | abhi2011 | so its back to square one , which is how to get union tree for the constituent primitives when passed just the rt_db_internal for a region containing those primitives |
| 20:29.20 | brlcad | abhi2011: that's why I said earlier that in order to call db_functree(), you need to use the unmodified dbi from the original dbip ... not your in-mem copy |
| 20:29.50 | brlcad | to use the inmem, you'd need to recursively call db_functree() on the original dbi and copy them into the inmem, just so you could look them up again |
| 20:30.02 | brlcad | basically a big pain and probably unnecessary |
| 20:30.25 | brlcad | much easier to create a new comb, add your primitive, then have all objects go through the other existing bb routine |
| 20:30.42 | abhi2011 | brlcad: ok yah that would work, I was trying to find a way to not pass an extra parameter as the idea was to just pass a rt_db_internal |
| 20:31.08 | abhi2011 | yes so I tried making a comb too |
| 20:31.14 | abhi2011 | however it needs a tree as well |
| 20:31.27 | abhi2011 | if you lines 414 to 418 in bbox.c |
| 20:31.32 | abhi2011 | *if you see |
| 20:31.44 | brlcad | you don't need an extra parameter |
| 20:32.18 | abhi2011 | the unmodfiied db_i is globally available then ? |
| 20:32.35 | abhi2011 | the original db_i i mean |
| 20:33.21 | brlcad | I think you might be a bit confused by the different approaches being discussed |
| 20:34.22 | abhi2011 | well there are 2 approaches : either use db_functree() or make a comb :) |
| 20:35.10 | abhi2011 | since making a comb is easier , lets focus on that then |
| 20:36.14 | abhi2011 | so the idea was that make a rt_comb_internal with 1 leaf for shapes , for combinations, well they are already a rt_comb_internal |
| 20:36.43 | brlcad | so far, sounding good |
| 20:36.50 | abhi2011 | ok :P |
| 20:37.33 | abhi2011 | so the basics challenge in making a rt_comb_internal out of a shape is : the tree parameter in the rt_comb_internal structure |
| 20:37.50 | CIA-62 | BRL-CAD: 03bob1961 * r46314 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Updated ArcherCore::selectTreePath to make the selected tree item visible. |
| 20:38.10 | abhi2011 | or rather the tree member |
| 20:38.12 | brlcad | not a challenge at all erally :) |
| 20:38.38 | abhi2011 | umm but I would need the tree for the shape right, I cant get that from the rt_db_internal |
| 20:38.56 | brlcad | you need a tree, yes |
| 20:39.09 | brlcad | filling in a tree is simple |
| 20:39.34 | brlcad | if the rt_db_internal is already a comb, you can just access the comb's tree |
| 20:39.50 | brlcad | if the rt_db_internal is a primitive, you'll make a comb and add that primitive to the comb's tree |
| 20:40.21 | abhi2011 | so something like combp->tree = intern->tree |
| 20:40.23 | brlcad | see the comb.c file, for the comb command, shows creating an rt_comb_internal and filling it in |
| 20:40.34 | abhi2011 | where intern is the rt_db_internal |
| 20:40.41 | abhi2011 | for the primitive |
| 20:40.53 | brlcad | that doesn't look or sound right |
| 20:41.16 | brlcad | intern->tree is not valid |
| 20:41.39 | abhi2011 | yes rt_db_internal does not have a tree member, so the tree in the rt_db_internal has to be accessed |
| 20:42.01 | abhi2011 | ok that part should be easy |
| 20:42.11 | brlcad | IFF intern is a comb, then intern->idb_ptr is an rt_comb_internal |
| 20:42.20 | abhi2011 | oh! :P |
| 20:42.56 | abhi2011 | umm no I knew that |
| 20:43.22 | abhi2011 | IFF intern is a primitive, then where is the tree , will find that out |
| 20:43.29 | brlcad | so you'd call something like rt_bound_tree(intern->idb_ptr->tree) if it's a comb or rt_bound_tree(my_comb->tree) if it's a primitive |
| 20:43.29 | abhi2011 | :) |
| 20:43.46 | abhi2011 | yes I understand that |
| 20:44.03 | brlcad | you have to make my_comb |
| 20:44.08 | abhi2011 | yes |
| 20:44.13 | brlcad | see comb.c :) |
| 20:44.19 | abhi2011 | yep :) |
| 20:44.32 | brlcad | you'll need a tiny subset similar to what _ged_combadd() does |
| 20:45.02 | brlcad | look for the GETSTRUCT lines to see where an rt_comb_internal is allocated |
| 20:45.19 | abhi2011 | ok |
| 20:46.46 | abhi2011 | by the way , on a different note, I am curious about the other approach : that is using db_functree(), you said the original db_i need not be passed |
| 20:47.09 | abhi2011 | so then it can be got using a global variable or a function ? |
| 20:52.24 | brlcad | no, I think you're misunderstanding something I was saying -- you are passed a db_i to your function -- you can just use it |
| 20:52.32 | brlcad | you just need to make a copy of it if you're going to pass it to some other non-const function |
| 20:54.55 | abhi2011 | well , the function is like this : int rt_bound_internal(struct rt_db_internal *ip, point_t rpp_min, point_t rpp_max), so there is no db_i passed |
| 20:55.53 | brlcad | sorry, I was using "db_i" to mean db_internal |
| 20:56.21 | brlcad | not to be confused with a database instance db_i |
| 20:56.24 | abhi2011 | oh ok , I though you meant struct db_i |
| 20:56.28 | abhi2011 | yah i get it :) |
| 20:57.35 | brlcad | you only needed a db_i to call rt_dirbuild() iirc, so that primitive bounding boxes get calculated |
| 20:58.11 | abhi2011 | yes, this db_i however was constructed from the original .g database file |
| 20:58.20 | abhi2011 | so it had all the primitives |
| 20:58.21 | brlcad | that approach is still fine, it's just combs that are even simpler with rt_bound_tree(ip->idb_ptr->tree) |
| 20:58.41 | abhi2011 | yes |
| 20:58.46 | abhi2011 | <PROTECTED> |
| 20:59.00 | abhi2011 | meanwhile, I got bullet running in mged |
| 20:59.04 | abhi2011 | and the cmake logic done |
| 20:59.08 | brlcad | outstanding |
| 20:59.33 | abhi2011 | about to commit that : had some changes to top level cmake file , hope starseeker is standing by :P |
| 20:59.35 | brlcad | sounds like more work is needed on the cmake logic, but shouldn't be too difficult |
| 20:59.48 | brlcad | what's the diff look like? |
| 21:00.05 | abhi2011 | I ll pastebin it 1 sec |
| 21:01.19 | abhi2011 | basically added logic to compile a dummy simulate.c file that does nto bullet headers, if bullet is absent |
| 21:01.46 | abhi2011 | in the top level there is logic to find the bullet library and link /usr/local/lib |
| 21:03.10 | brlcad | presuming you saw my earlier comment, assuming /usr/local/lib is no good |
| 21:04.04 | abhi2011 | oh ok, I think I missed that |
| 21:04.31 | abhi2011 | reading now :) |
| 21:04.40 | brlcad | I mean, /usr/local is probalby the only "non-default" system locations that could be added, but adding it should be systematic for include headers, libs, and bins |
| 21:05.11 | brlcad | and it still shouldn't be subdir aware like /usr/local/lib/bullet/. |
| 21:06.03 | brlcad | libs not in "system" paths should be declared to cmake or handled by some Find*.cmake routines |
| 21:07.46 | abhi2011 | ok, I would have thought that /usr/local/lib would be searched by default by cmake |
| 21:07.57 | abhi2011 | so I would not need to specify it |
| 21:08.18 | abhi2011 | well I am using the stock FindBullet.cmake module |
| 21:09.09 | abhi2011 | its installed by cmake, and it finds and sets the ${BULLET_INCLUDE_DIR}, ${BULLET_LIBRARIES} correctly |
| 21:09.44 | abhi2011 | but its not setting the ${BULLET_LIBRARY_DIR} variable, which is what I would link to , to keep things standard |
| 21:10.35 | abhi2011 | here is the top level CMakeLists.txt diff : http://bin.cakephp.org/view/1810550039 |
| 21:10.46 | abhi2011 | will try to get rid of LINK_DIRECTORIES("/usr/local/lib") |
| 21:13.17 | abhi2011 | this is the libged/CMakeLists.txt file that also required changes : http://bin.cakephp.org/view/860235467 |
| 21:16.44 | abhi2011 | ok , so I am thinking maybe I can remove the LINK_DIRECTORIES("/usr/local/lib") line in the top level CMakeLists.txt file |
| 21:17.09 | abhi2011 | as long as a user does not enable bullet , the rest of the build will be fine |
| 21:17.27 | abhi2011 | if he does enable bullet, then there will be a linking error |
| 21:17.53 | abhi2011 | so the exact location where the user has installed the libs can be specified using a cmake command line flag |
| 21:18.20 | abhi2011 | that would eliminate any hardcoded library paths |
| 21:21.55 | abhi2011 | of course that begs the question as to why ${BULLET_LIBRARY_DIR} is not being set by the stock FindBullet.cmake module , its probably not looking at the right place |
| 21:26.28 | brlcad | so several comments |
| 21:26.50 | brlcad | sure, searching /usr/local/lib might be expected .. but that has nothing to do with bullet and shouldn't be part of your patch/commit |
| 21:27.12 | brlcad | certainly shouldn't be specific to an if(BRLCAD-ENABLE_BULLET) section |
| 21:27.58 | brlcad | which brings up my second point, and enable/disable toggle for that seems unnecessary -- it should test for bullet and, if found, use it. otherwise, the command implementation is disabled at compile-time |
| 21:30.08 | abhi2011 | brlcad: ok I understand |
| 21:30.26 | brlcad | abhi2011: you also do not need simulatedummy.c -- that should be logic contained within the simulate.c file (#ifdef) OR put it all in a subdir with it's own CMakeLists.txt file |
| 21:30.45 | brlcad | probably should put it all in a subdir anyways just because you have multiple implementation files |
| 21:31.13 | abhi2011 | ok , yes that will be easier |
| 21:32.25 | abhi2011 | yes I thought about the #ifdef , but I havent found a compile time symbol that is defined if bullet was found |
| 21:33.38 | abhi2011 | ok, I think there will be some symbol which will be defined if the bullet headers are detected, will go through the headers |
| 21:33.48 | brlcad | if one is not defined, you can define one |
| 21:33.59 | brlcad | but make sure one isn't already defined |
| 21:34.04 | abhi2011 | yes, but bullet is detected by cmake |
| 21:34.16 | brlcad | yes, so? :) |
| 21:34.20 | abhi2011 | i cant define a symbol to be used in a c file , in the cmake logic |
| 21:34.26 | brlcad | sure you can |
| 21:34.29 | abhi2011 | umm...but as usual i am off mark :P |
| 21:34.37 | abhi2011 | ok thats totally cool :) |
| 21:34.56 | abhi2011 | ok will find out about it |
| 21:35.15 | brlcad | see include/brlcad_config.h in your build directory for a list of symbols already being defined during cmake |
| 21:35.26 | abhi2011 | ok |
| 22:02.07 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 22:15.15 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 23:00.39 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 23:28.47 | CIA-62 | BRL-CAD: 03brlcad * r46315 10/brlcad/trunk/src/libged/edit.c: quellage, may be unitialized |
| 00:19.38 | *** join/#brlcad kanzure_ (~kanzure@131.252.130.248) | |
| 00:59.51 | CIA-62 | BRL-CAD: 03starseeker * r46316 10/brlcad/trunk/ (41 files in 39 dirs): (log message trimmed) |
| 00:59.51 | CIA-62 | BRL-CAD: Stub in a way for view information to be passed to plot routines. Inactive at |
| 00:59.51 | CIA-62 | BRL-CAD: the moment, and the struct being passed in just has a single token value - this |
| 00:59.51 | CIA-62 | BRL-CAD: is setting up the path through which information can be passed, not actually |
| 00:59.51 | CIA-62 | BRL-CAD: doing it (yet). This will introduce a binary compatibility, so it may need to |
| 00:59.52 | CIA-62 | BRL-CAD: be reverted, but I'm committing it at this time to preserve the information for |
| 00:59.53 | CIA-62 | BRL-CAD: future use; the commit diff is a good starting point when determing what |
| 02:04.48 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 02:13.51 | starseeker | crud s/compatibility/incompatibility |
| 02:15.47 | abhi2011 | ok I have modified the cmake logic and put the simulation files in libged/simulation |
| 02:16.30 | abhi2011 | added 1 symbol to indicate bullet was found or not |
| 02:27.45 | abhi2011 | here is the diff of the 3 cmake files, 2 existing, 1 added : http://bin.cakephp.org/view/295759995 |
| 02:29.39 | abhi2011 | minimal changes to the top level file |
| 02:30.36 | starseeker | abhi2011: you don't need the MESSAGE line for the Bullet find pakage |
| 02:30.38 | starseeker | package even |
| 02:31.56 | brlcad | starseeker: hm |
| 02:31.57 | starseeker | also, I would expect the BRLCAD_ADDLIB line to use "${BULLET_LIBRARIES}" instead of individually listing them - does that not work? |
| 02:32.03 | brlcad | isn't scale sufficient? |
| 02:32.29 | starseeker | brlcad: not for what I'm experimenting with at the moment |
| 02:32.38 | starseeker | if that doesn't pan out, then possibly |
| 02:32.44 | abhi2011 | starseeker: ok I will remove the message line |
| 02:33.09 | brlcad | I'd had similar thoughts to add view information to the plot callback for levels-of-detail, but data-wise the callback still only needs a single scaling factor |
| 02:33.41 | abhi2011 | well ${BULLET_LIBRARIES} contains the static libraries with the .a extensions as thats what applications normally use |
| 02:34.06 | abhi2011 | however when I tried linking against the static libraries I was getting an error related to the -fPIC flag |
| 02:34.12 | starseeker | brlcad: I'm experimenting with some view-dependent logic at the moment - too early to know if it's viable or not |
| 02:34.37 | abhi2011 | I ll try it once more, though I think -static needs to be specified when compiling mged |
| 02:34.48 | abhi2011 | to alllow bullet to link to it statically |
| 02:35.04 | brlcad | starseeker: er, like rtedge-style plotting? |
| 02:35.27 | starseeker | brlcad: no, some level-of-detail stuff for bots |
| 02:35.48 | abhi2011 | starseeker: therefore I compiled the dynamic libs for bullet with .so extensions and use those which requires individually specifiying the libs |
| 02:35.59 | starseeker | brlcad: I can revert that commit if it's a problem - it's way too early to know if what I'm thinking will work or not |
| 02:36.10 | brlcad | er, but how is it view-dependent (beyond scale) |
| 02:36.37 | starseeker | view direction and matrix |
| 02:36.55 | starseeker | window size, etc |
| 02:37.06 | brlcad | but how? :) |
| 02:37.25 | brlcad | window size I can see easily, but that is encompassed by scale |
| 02:37.27 | starseeker | sigh... OK, fine: http://vdslib.virginia.edu/ |
| 02:38.22 | starseeker | knew he shouldn't have committed that... |
| 02:38.33 | brlcad | i'm not looking for a bunny out of a hat, I'm really just curious how |
| 02:38.48 | brlcad | LoD doesn't need view dir |
| 02:39.27 | starseeker | this isn't a standard "decimate the mesh" approach - http://www.cs.virginia.edu/~luebke/publications/pdf/vds.cad.pdf |
| 02:41.00 | starseeker | the 1.0 code apparently isn't around anymore, but thanks to debian an earlier version is: http://bzflag.bz/~starseeker/vdslib-0.9-6.1.tar.gz |
| 02:41.28 | starseeker | is looking at the polyview example app they have in there, and intending to do what they're doing with bots and vlists |
| 02:42.22 | abhi2011 | ok I have modified libged/simulation/CMakeLists.txt to link to the static libs but I get an error : http://bin.cakephp.org/view/372893931 |
| 02:42.27 | abhi2011 | same one as before |
| 02:43.01 | starseeker | got libvds, libstdvds and polyview compiling today, and polyview kinda worked |
| 02:43.02 | abhi2011 | something to with 32 bit libraries on 64 bit platforms |
| 02:43.57 | starseeker | abhi2011: urm. what does the file command tell you about your bullet libraries? |
| 02:45.36 | starseeker | brlcad: it may be that once I fully understand what vds is doing scale will turn out to be sufficient for our needs, but I was going to first verify in the most straightforward way I could that I could duplicate what polyview is doing inside MGED |
| 02:46.56 | abhi2011 | libBulletCollision.a gives : libBulletCollision.a: current ar archive |
| 02:47.10 | starseeker | hmm |
| 02:47.19 | abhi2011 | libBulletCollision.so.2.78: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped |
| 02:47.36 | abhi2011 | those are the static and dynamic counterparts of the same basic library |
| 02:47.42 | brlcad | starseeker: interesting approach, I hadn't seen that paper before (or at least not that I remember) |
| 02:47.45 | starseeker | OK, but the bullet find_package isn't returning the dynamic lib? |
| 02:48.13 | abhi2011 | no , the stock FindBullet.cmake does not |
| 02:48.25 | brlcad | a quick read through the paper, there are several issues it claims that are somewhat non-issues these days (e.g., memory use for the lod) |
| 02:48.55 | abhi2011 | I could make a FindBullet.cmake specifically for returning dynamic libs |
| 02:49.01 | brlcad | and issues caused by his approach (distant object popping, trouble with the folding) |
| 02:49.01 | starseeker | brlcad: I got triggered by a comment from Bob when he was working with one of the big BoT models about how the interactivity sucked so bad, so I went hunting this weekend for something that might be viable (since it's for sure anybody dealing with a big BoT model would have the same issue) |
| 02:49.16 | starseeker | abhi2011: that might be worth doing |
| 02:49.36 | starseeker | abhi2011: we do custom Find*.cmake files when the stock ones don't suffice - there are several in misc/CMake |
| 02:50.19 | starseeker | brlcad: yeah, the mesh probably won't be perfect, but if it's "close enough" and interactive it will beat the heck out of one refresh every 30 sec. when zooming |
| 02:50.27 | abhi2011 | ok yes I can make a custom one, I wonder whats up with the compiler though, it should have allowed static linking |
| 02:50.48 | starseeker | abhi2011: are you compiling 32 or 64 bit? (-m32 or -m64?) |
| 02:51.06 | abhi2011 | maybe bullet builds the 32 bit version by default |
| 02:51.06 | brlcad | abhi2011: the subdir should match the command name |
| 02:51.14 | starseeker | brlcad: apparently it was a SIGGRAPH thing back in the late 1990s |
| 02:51.21 | starseeker | s/thing/paper |
| 02:51.31 | abhi2011 | starseeker: i avent checked that , will check now |
| 02:51.37 | brlcad | starseeker: I noticed |
| 02:51.46 | abhi2011 | brlcad: ok I ll change it |
| 02:51.51 | starseeker | was hoping to try it before he got told why it wouldn't be a good idea :-P |
| 02:51.58 | brlcad | heh |
| 02:52.48 | brlcad | it's not evidently a bad idea, just odd -- not many folks did research on view-dependent LoD |
| 02:52.48 | starseeker | it took a little time to propagate the rt_*_plot change, and I didn't want to leave it uncommitted, so I figured do it in one fell swoop that could be easily undone |
| 02:53.13 | brlcad | and from my quick read, it's still not entirely clear that it is exactly view-dependent from our plot-perspective |
| 02:53.48 | starseeker | it might not be - I was going on what the polyview app was feeding via vds functions |
| 02:53.49 | brlcad | you feed an initial mesh at a given LoD along with the view params, then it generates a quadree simplification based on the current view |
| 02:55.22 | starseeker | right - but since our plotting routines call the functab for each primitive to get the lines to draw, I was assuming that the simplification output (in vlist form) was what would need to come back from rt_bot_plot |
| 02:55.29 | brlcad | you could still keep plot view agnostic, returning a plot at some predetermined scale, then have a function churn through the view-dependent simplification |
| 02:56.10 | starseeker | maybe, but that starts to get deep into the tangle of code that is the draw logic |
| 02:56.25 | starseeker | was trying to stay below that rats nest, at least for the first trial |
| 02:56.53 | brlcad | that's where injecting view-dependent information is going to be a mess ... plot() for some of the prims is already a nightmare |
| 02:57.10 | brlcad | but yeah, that seems to be the way the algorithm wants it anyways |
| 02:57.16 | brlcad | you got to have the mesh to start with |
| 02:57.17 | starseeker | brlcad: but we don't have to use it unless we want to |
| 02:57.31 | brlcad | hm? |
| 02:57.36 | starseeker | for now, every primitive except BoT will totally ignore the view info |
| 02:58.37 | brlcad | that's my point, though -- the algorithm doesn't know or care about object types, and shouldn't need to |
| 02:58.44 | starseeker | the main problem I was looking at was caching the vds tree |
| 02:58.55 | brlcad | the same logic that'd let you simplify a bot will simplify any plot() data set |
| 02:58.56 | starseeker | uh... which algorithm? |
| 02:59.04 | brlcad | this view-dep lod paper |
| 02:59.07 | starseeker | oh - not sure about that, actually |
| 02:59.14 | starseeker | it may need face data as well as edges |
| 02:59.29 | brlcad | sure, it wants manifold surfaces |
| 02:59.39 | brlcad | several of the plot impls go through nmg anyways |
| 02:59.56 | starseeker | sure, so for those it might be viable - but (say) ell or eto won't care |
| 03:00.12 | starseeker | wasn't going to tangle with nmg in the first round |
| 03:01.47 | brlcad | that's actually a good point |
| 03:01.55 | brlcad | the paper did require topology |
| 03:02.45 | brlcad | which .. BoTs ain't got |
| 03:03.01 | brlcad | tess() would be more appropriate than plot() |
| 03:04.04 | brlcad | then it is back to being agnostic to entity type |
| 03:04.40 | brlcad | that said..... |
| 03:04.58 | brlcad | bob's problem is fixed with a *very* simple scale-based LoD reduction :) |
| 03:05.34 | starseeker | except how do we know how to draw the bots at various scales? |
| 03:05.45 | starseeker | this seemed like a systematic way to address that cleanly |
| 03:07.13 | brlcad | easy, you pass the scale you want to the bot |
| 03:07.27 | starseeker | and then the bot does... what? |
| 03:07.38 | brlcad | if the super-detailed bot is being drawn tiny, the scale factor will be tiny |
| 03:08.11 | starseeker | right, but that still begs the question of which subset of edges from the BoT to draw at that scale |
| 03:08.21 | brlcad | the scale factor is basically used to collapse edges or introduce new edges |
| 03:08.44 | brlcad | so at scale near zero, it's a point or a single tiny vlist segment |
| 03:09.00 | brlcad | at near one, it's whatever "full detail" means |
| 03:09.04 | starseeker | right, but the details of that collapsing are the difficulty |
| 03:09.18 | starseeker | that problem is probably a subset of what vds is doing, actually |
| 03:09.21 | brlcad | you have that info directly from the scale value |
| 03:09.28 | brlcad | that scale is in relation to the model size |
| 03:09.50 | brlcad | so tessellating as we do now, we make ton's of segments that are effectively all overlapping |
| 03:10.11 | brlcad | detecting that next_point == curr_point within tolerance is easy |
| 03:10.27 | brlcad | we just don't/didn't even have the scale to even know that |
| 03:11.45 | starseeker | isn't sure next_point == curr_point is enough, but I suppose I don't understand enough about how plot is doing its drawing |
| 03:12.13 | starseeker | bbiab |
| 03:12.14 | brlcad | it's not really == .. it's within tolerance given the current scale |
| 03:12.56 | brlcad | NEAR_EQUAL(curr_point, next_point, collapse_distance) |
| 03:15.30 | brlcad | the only thing you don't explictly know with just a scale size is the number of pixels since that's really what (should) drives the edge collapse |
| 03:16.33 | brlcad | so you encode that implicitly in the scale (e.g., 1.0 immplies 1024x1024 spacing of edges scaled to that object's bbox) |
| 03:16.56 | brlcad | or you pass the interpixel spacing (i.e., the collapse_distance) instead of scale |
| 03:19.57 | brlcad | OR you pass both and you get arbitrary on-demand LoD :) |
| 03:20.22 | brlcad | abhi2011: ../../../src/libged/simulate.c:63:1: error: C++ style comments are not allowed in ISO C90 |
| 03:28.31 | abhi2011 | brlcad: yes I removing those comments |
| 03:30.06 | brlcad | starseeker: another thought -- you could get a boost within libdm itself, agnostic to any primitive plot() implementation |
| 03:32.31 | brlcad | libdm knows the view size and pixel size so there are several optimizations that could be made right off the bat -- like not even calling plot if object is smaller than a pixel, and reducing the plot vlist eliminating edges that are less than half a pixel distance in length |
| 03:33.52 | brlcad | that's probably a couple hours effort in an afternoon to get something that simple working .. hmm! |
| 03:38.54 | brlcad | looks like drawH_part2() is where the action is at |
| 04:03.46 | CIA-62 | BRL-CAD: 03brlcad * r46317 10/brlcad/trunk/doc/docbook/system/mann/en/Makefile.am: file was renamed to edit_translate.xml |
| 04:26.24 | CIA-62 | BRL-CAD: 03brlcad * r46318 10/brlcad/trunk/include/ (bu.h magic.h raytrace.h): if NO_BOMBING_MACROS is enabled, then it will leave empty if-statements throughout the code making the compiler unhappy. sacrifice a no-opish ((void)0) to keep the compilation gods happy. |
| 05:15.35 | CIA-62 | BRL-CAD: 03brlcad * r46319 10/brlcad/trunk/src/libged/Makefile.am: update Makefile.am at the same time as CMakeLists.txt, add simulate.c and simphysics.cpp to unbreak autotools build. |
| 05:16.08 | CIA-62 | BRL-CAD: 03brlcad * r46320 10/brlcad/trunk/src/tclscripts/mged/CMakeLists.txt: no packages presently exist in mged dir |
| 05:26.04 | plaes | hum.. how do I "exit" from oed back to the viewing state? |
| 05:26.30 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 05:30.13 | plaes | aha.. reject |
| 05:33.52 | CIA-62 | BRL-CAD: 03brlcad * r46321 10/brlcad/tags/zlib_1_0_4/: there is no reason for keeping a tag of zlib 1.0.4 |
| 05:45.58 | brlcad | pressing escape in the graphics window will do it too |
| 05:57.59 | CIA-62 | BRL-CAD: 03brlcad * r46322 10/brlcad/tags/ (12 files in 12 dirs): similarly no reason to keep around the old cvs branch tags that were useful for tracking branch start points, end points, and branch termination. relegated the legacy into svn history. |
| 06:23.48 | plaes | hmm.. rtwizard doesn't set the path properly |
| 07:15.20 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:25.09 | CIA-62 | BRL-CAD: 03d_rossberg * r46323 10/brlcad/trunk/CMakeLists.txt: |
| 07:25.09 | CIA-62 | BRL-CAD: quell cmake warning |
| 07:25.09 | CIA-62 | BRL-CAD: and apparently trimmed trailing spaces |
| 07:25.18 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 07:57.09 | *** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no) | |
| 08:20.48 | *** join/#brlcad Unknown_Monkey (~max@netblock-208-127-49-10.dslextreme.com) | |
| 08:22.38 | Unknown_Monkey | hey I installed brlcad on my ubuntu machine and when i run mged and I draw a cone or anything It doesnt show up the screen is blank and when I click on the window the cone drawing shows up but then it disappers |
| 08:24.37 | *** join/#brlcad DarkCalf (DC@2002:ade7:2862::ade7:2862) | |
| 08:27.30 | Unknown_Monkey | DarkCalf: can you help me |
| 12:19.46 | CIA-62 | BRL-CAD: 03brlcad * r46324 10/brlcad/tags/ (itcl3-2/ libpng_1_0_2/ tcl8-3/ tk8-3/): revmoed additional 3rd party dependencies that don't really belong amongst our other tags |
| 13:09.05 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 13:35.15 | CIA-62 | BRL-CAD: 03abhi2011 * r46325 10/brlcad/trunk/src/libged/simulate.c: Removed C++ style comments in C file to conform to C90 |
| 13:37.36 | CIA-62 | BRL-CAD: 03abhi2011 * r46326 10/brlcad/trunk/src/libged/simphysics.cpp: Changed mode to C++ in the file style section at the bottom |
| 13:41.17 | CIA-62 | BRL-CAD: 03n_reed * r46327 10/brlcad/trunk/src/conv/obj-g_new.c: Fixed missing header and implicit return statement that g++ complained about. |
| 13:42.43 | CIA-62 | BRL-CAD: 03brlcad * r46328 10/brlcad/tags/ (10 files in 10 dirs): more removal of cvs branching artifacts where it was necessary to tag before and after merging, pushed into the depths of svn history |
| 14:07.26 | CIA-62 | BRL-CAD: 03n_reed * r46329 10/brlcad/trunk/src/libgcv/wfobj/ (10 files): Replaced flex scanner with re2c equivalent. |
| 14:12.51 | starseeker | woot! |
| 14:13.17 | starseeker | ditches view stuff and hits the re2c/lemon logic |
| 14:16.07 | CIA-62 | BRL-CAD: 03starseeker * r46330 10/brlcad/trunk/src/other/ (CMakeLists.txt byacc/ flex/ m4/): We're not using them right now, re2c/lemon work is progressing, and svn has our back if we have to return to this route - clear out m4/byacc/flex |
| 14:31.24 | CIA-62 | BRL-CAD: 03starseeker * r46331 10/brlcad/trunk/src/other/ (450 files in 13 dirs): Check in vanilla copies of re2c-0.13.5 and the latest lemon from sqlite.org. No build system logic yet, baselining with the vanilla sources. |
| 14:40.27 | CIA-62 | BRL-CAD: 03starseeker * r46332 10/brlcad/trunk/src/other/ (20 files in 3 dirs): Add first stages of CMake logic for re2c and lemon building |
| 14:59.43 | CIA-62 | BRL-CAD: 03starseeker * r46333 10/brlcad/trunk/ (4 files in 2 dirs): Add more CMake logic for re2c/lemon, this time relating to deciding whether or not to build local copies - this is Not Done, particularly the FindRE2C and FindLEMON files, but checkpointing. |
| 15:18.34 | *** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no) | |
| 15:30.48 | CIA-62 | BRL-CAD: 03bob1961 * r46334 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Updated Ged::pane_mouse_ray to calculate the mLastMouseRayStart point (i.e. the point from which to fire a ray) so that all displayed geometry is in front of the ray firing point. |
| 15:36.28 | abhi2011 | ok I have modified the cmake logic to detect bullet dynamic libs |
| 15:36.37 | abhi2011 | all I had to do was remove the static libs |
| 15:36.44 | abhi2011 | time for a whoosh! commit |
| 15:37.06 | brlcad | abhi2011: try to commit incrementally if you can without breaking the build |
| 15:37.15 | abhi2011 | brlcad: ok :P |
| 15:37.20 | brlcad | like one commit moves the files into a subdir, another fixes the bullet rules, etc |
| 15:37.45 | brlcad | you shouldn't move modified files, for example |
| 15:38.17 | brlcad | edit, commit, then move, commit OR move, commit, then edit, commit |
| 15:40.03 | abhi2011 | ok I have deleted 2 files : simulate.c and simphysics.cpp in libged however |
| 15:40.20 | abhi2011 | moved them to libged/simulate directory |
| 15:40.50 | abhi2011 | ok for those 2, I ll commit last |
| 15:40.54 | brlcad | that's wrong |
| 15:41.10 | brlcad | svn will handle the move for you, and is preferred because it will preserve the commit history |
| 15:43.04 | brlcad | cd src/libged && svn revert simulate.c simphysics.cpp && mv simulate simulate.backup && mkdir simulate && svn add simulate && svn commit -m "stub in simulate dir" simulate && svn mv simulate.c simulate/simulate.c && svn mv simphysics.cpp simulate/simphysics.cpp && .... etc |
| 15:43.42 | abhi2011 | ok |
| 15:44.26 | CIA-62 | BRL-CAD: 03brlcad * r46335 10/brlcad/tags/ (merge-to-head-20051223/ stable-branch/): move cvs branch tagging artifact removal |
| 15:45.07 | abhi2011 | ok then I ll checkout fresh again , and do the changes one by one |
| 15:47.42 | abhi2011 | hmm, no i think just deleting the simulate directory and recreating through the commands you gave should be enough, ok will do that |
| 15:47.57 | CIA-62 | BRL-CAD: 03brlcad * r46336 10/brlcad/tags/temp_tag/: remove what looks like a tag related to the merging of the bobWinPort work, some artifact tag that was retained through conversion from cvs. |
| 15:52.03 | CIA-62 | BRL-CAD: 03brlcad * r46337 10/brlcad/tags/CMD/: nice.. remove very old version of remrt that was tagged in the early 90's. nice and easy to read. |
| 15:56.45 | CIA-62 | BRL-CAD: 03brlcad * r46338 10/brlcad/tags/help/: remove mysterious 'help' tag from 7.8, no apparent purpose and certainly no need to keep it around now |
| 16:03.56 | CIA-62 | BRL-CAD: 03abhi2011 * r46339 10/brlcad/trunk/src/libged/simulate/: stub in simulate dir |
| 16:10.08 | CIA-62 | BRL-CAD: 03abhi2011 * r46340 10/brlcad/trunk/src/libged/ (5 files in 2 dirs): stub for 2 files moved to simulate dir |
| 16:13.20 | CIA-62 | BRL-CAD: 03abhi2011 * r46341 10/brlcad/trunk/src/mged/cmd.c: stub for simulate cmd wrapper modification |
| 16:23.12 | CIA-62 | BRL-CAD: 03brlcad * r46342 10/brlcad/tags/Original/: remove '98 tagging of the html docs |
| 16:27.27 | CIA-62 | BRL-CAD: 03brlcad * r46343 10/brlcad/tags/release-7-0/: clearly not actually release 7.0 .. remove the cvs tag relic that was made on a few files just before the project was converted to open source. |
| 16:30.44 | CIA-62 | BRL-CAD: 03brlcad * r46344 10/brlcad/tags/rel-5-0beta/: remove the rel-5-0beta cvs-to-svn relic as it's not actually the 5.0 beta release. the rel-5-0-beta tag has that so this one that just has tcl/tk can get gone. |
| 16:31.29 | brlcad | and with that, our tags should now be all in order, each representing some snapshot in time for a given production |
| 16:40.40 | CIA-62 | BRL-CAD: 03abhi2011 * r46345 10/brlcad/trunk/CMakeLists.txt: Added detection of bullet dynamic libraries using the stock CMAKE FindCMake.cmake module |
| 16:42.59 | *** join/#brlcad plaes (~plaes@gn237.zone.eu) | |
| 16:45.01 | CIA-62 | BRL-CAD: 03abhi2011 * r46346 10/brlcad/trunk/src/libged/ (4 files in 2 dirs): Changes in the CMake build logic and source files to allow the simulate command to link to bullet |
| 16:45.22 | abhi2011 | and that completes the changes to link to bullet for the mged simulate command |
| 16:46.37 | abhi2011 | hope I didnt break anything |
| 16:52.26 | abhi2011 | so if anyone installs bullet (has to be told to specifically compile shared libs) and tries out the simulate command then let me know :) |
| 17:02.36 | CIA-62 | BRL-CAD: 03n_reed * r46347 10/brlcad/trunk/src/libgcv/wfobj/Makefile.sample: Adding local makefile to demonstrate necessary build steps. |
| 17:42.33 | *** join/#brlcad molto_crescendo (~molto_cre@BZ.BZFLAG.BZ) | |
| 17:42.57 | brlcad | I wonder |
| 17:43.45 | molto_crescendo | okay |
| 17:49.48 | starseeker | brlcad: wonder... what? |
| 17:50.10 | brlcad | starseeker: never mind :) |
| 17:51.13 | starseeker | heh - k |
| 18:00.25 | starseeker | wheee - that was fun! |
| 18:10.02 | CIA-62 | BRL-CAD: 03starseeker * r46348 10/brlcad/trunk/src/other/lemon/CMakeLists.txt: need lempar.c in the same directory as the lemon binary |
| 18:10.48 | molto_crescendo | yep, same directory |
| 18:11.18 | CIA-62 | BRL-CAD: 03brlcad * r46349 10/brlcad/trunk/src/other/Makefile.am: bison/flex/m4 removed, stay in sync with CMakeLists.txt |
| 18:12.27 | CIA-62 | BRL-CAD: 03brlcad * r46350 10/brlcad/trunk/src/other/Makefile.am: add lemon and re2c dirs |
| 18:16.59 | brlcad | abhi2011: nice work regardless, hopefully get a chance to test it later this wek |
| 18:17.03 | brlcad | s/wek/week/ |
| 18:23.35 | ``Erik | weeeee, earthquakes |
| 18:23.36 | brlcad | abhi2011: one cleanup, the " |
| 18:24.27 | brlcad | abhi2011: the simulate "library" can just be named simulate (not libgedsim) since it's not intended to be installed/used as a standalone library but as a module to libged |
| 18:25.01 | abhi2011 | brlcad: ok |
| 18:49.39 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 19:28.50 | CIA-62 | BRL-CAD: 03starseeker * r46351 10/brlcad/trunk/ (391 files in 59 dirs): Get the new obj-g building as part of BRL-CAD. |
| 19:29.20 | CIA-62 | BRL-CAD: 03brlcad * r46352 10/brlcad/trunk/TODO: |
| 19:29.21 | CIA-62 | BRL-CAD: primitive testing has uncovered off-by-one raytrace errors during identical |
| 19:29.21 | CIA-62 | BRL-CAD: subsequent invocations of rt due to some floating point issue during parallel |
| 19:29.21 | CIA-62 | BRL-CAD: processing. single processor results in zero errors yet parallel gives subtle |
| 19:29.21 | CIA-62 | BRL-CAD: changes. should investigate to see if there's a code issue though the problem |
| 19:29.21 | CIA-62 | BRL-CAD: persists back as far as at least 7.8 (on 64-bit Linux). |
| 19:38.03 | brlcad | starseeker: I presume you put boost there because of conflicts or uncertainty with src/other/boost ? |
| 19:41.13 | starseeker | yep |
| 20:58.45 | *** join/#brlcad Elrohir (~kvirc@p5B14AEDB.dip.t-dialin.net) | |
| 20:59.49 | CIA-62 | BRL-CAD: 03starseeker * r46353 10/brlcad/trunk/src/other/boost/ (88 files in 30 dirs): Clear old boost libs |
| 21:22.25 | CIA-62 | BRL-CAD: 03n_reed * r46354 10/brlcad/trunk/src/libged/ (CMakeLists.txt simulate/CMakeLists.txt): get the build working - probably not the 'right' fix (starseeker) |
| 21:40.51 | CIA-62 | BRL-CAD: 03n_reed * r46355 10/brlcad/trunk/src/mged/setup.c: Need to use HAVE_BULLET in mged too - no ged_simulate, no simulate command. |
| 21:52.46 | CIA-62 | BRL-CAD: 03n_reed * r46356 10/brlcad/trunk/src/conv/obj-g_new.c: Removed obsolete debug output. |
| 22:00.40 | CIA-62 | BRL-CAD: 03n_reed * r46357 10/brlcad/trunk/src/libgcv/wfobj/obj_rules.re: Removed obsolete debug output. |
| 22:30.31 | CIA-62 | BRL-CAD: 03starseeker * r46358 10/brlcad/trunk/src/other/boost/ (1467 files in 127 dirs): add the bcp reported subset of boost 1.47 needed for spirit.hpp. Made a quick stab at CMakeLists.txt build logic for the libs, not sure if it's right. |
| 22:33.30 | CIA-62 | BRL-CAD: 03starseeker * r46359 10/brlcad/trunk/src/libpc/CMakeLists.txt: because we have both boost and libs dirs now, include src/other/boost not src/other |
| 22:36.31 | molto_crescendo | exit |
| 22:38.30 | *** join/#brlcad abhi2011 (~chatzilla@x033197.its-s.tudelft.nl) | |
| 22:39.37 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 22:45.28 | bhinesley | hmm... playing around with Blender. There is a setting to "manipulate object centers only". I didn't think of allowing translations based on angles (without actually rotating the object being translated). |
| 22:46.08 | brlcad | bhinesley: not sure I follow |
| 22:46.30 | brlcad | a translation based on an angle means what exactly? |
| 22:47.34 | brlcad | like only translating against an object's local coordinate system instead of global? |
| 22:48.15 | brlcad | so a box tilted 45 degrees and translated "by x" would go "up" at a 45 degree translation? |
| 22:48.20 | bhinesley | brlcad: hard to explain. In Blender, you can set your 3d cursor where you would like the center of a rotation to take place. Then you enable "manipulate object centers only". When you "rotate", you're not really rotating. You're just moving the object to some other point. |
| 22:48.52 | bhinesley | brlcad: no, it does local vs. global translations too, but that's not what I'm refering to. |
| 22:49.27 | brlcad | yeah .. okay .. confused then :) |
| 22:51.30 | bhinesley | brlcad: say you place a box at 1,0,0 and the center of rotation at 0,0,0. If you rotate the box 90 degrees on the z-axis, you'll end up at 0,1,0 with the cube still facing the same directions. |
| 22:51.40 | brlcad | finds http://blenderunderground.com/blender-3d-faq/#mi_centers to be unhelpful |
| 22:52.24 | brlcad | ahh, good example |
| 22:53.40 | brlcad | sounds like a flag to the rotate command ;) |
| 22:53.57 | brlcad | or a different "pivot" command |
| 22:54.29 | brlcad | since you're really pivoting around a point, seems apropos |
| 22:55.17 | bhinesley | nods |
| 22:55.36 | bhinesley | rotate is already too complex |
| 22:57.03 | bhinesley | to the user it would "feel" like a special type of rotation, but under cover a pivot command would just call translate. |
| 22:57.41 | brlcad | or call rotate twice |
| 22:57.58 | bhinesley | hmm, not a bad idea. |
| 23:02.13 | bhinesley | could be used to create polar arrays (i.e. lugnuts on a wheel) |
| 23:02.38 | brlcad | the existing pattern tool already does that albeit manually in the implementation |
| 23:03.06 | brlcad | spherical and cylindrical |
| 23:03.14 | bhinesley | ah, nice |
| 23:04.25 | bhinesley | brlcad: what is it called? is it in Archer? |
| 23:04.26 | CIA-62 | BRL-CAD: 03brlcad * r46360 10/brlcad/trunk/TODO: potential lead, -B works with parallel enabled so something fishy is going on. possibly conversion from float to double ... but random numbers should not be involved! |
| 23:04.45 | brlcad | bhinesley: the interface is just atrocious |
| 23:04.49 | brlcad | so it's in mged ;) |
| 23:05.22 | brlcad | Pattern tool under the Tools menu |
| 23:05.27 | bhinesley | ah, I see, thanks |
| 23:07.16 | CIA-62 | BRL-CAD: 03starseeker * r46361 10/brlcad/trunk/src/ (CMakeLists.txt util/CMakeLists.txt): libpc ain't happy about the boost change - turn it off for now. |
| 23:14.07 | CIA-62 | BRL-CAD: 03starseeker * r46362 10/brlcad/trunk/src/libgcv/wfobj/ (CMakeLists.txt boost_shared_ptr/): Well, can now use src/other/boost for obj-g anyway... |
| 23:23.57 | CIA-62 | BRL-CAD: 03starseeker * r46363 10/brlcad/trunk/src/other/boost/boost/spirit/ (32 files in 11 dirs): hmm - may not have gotten everything. bcp --scan of the libpc headers resulted in a few more boost files. |
| 00:29.04 | CIA-62 | BRL-CAD: 03starseeker * r46364 10/brlcad/trunk/CMakeLists.txt: Since it's proving convenient to make a build directory in the src dir for a cmake .. build, ignore the two most common cases when doing cpack |
| 01:39.49 | CIA-62 | BRL-CAD: 03starseeker * r46365 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: Be nice to source file flags set prior to the target being defined and bring them along for the ride. |
| 01:46.38 | CIA-62 | BRL-CAD: 03starseeker * r46366 10/brlcad/trunk/misc/CMake/BRLCAD_CompilerFlags.cmake: Check if we have the no-unused flag |
| 01:51.24 | CIA-62 | BRL-CAD: 03starseeker * r46367 10/brlcad/trunk/src/other/boost/ (1083 files in 93 dirs): One last round of additions - this is enough to let libpc build again, surprisingly - so good news everybody, boost can be upgraded without wiping out libpc |
| 01:59.04 | *** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 02:00.31 | *** part/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 02:51.51 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096600997.dsl.bell.ca) | |
| 08:04.00 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 09:37.02 | jordisayol | starseeker: congratulations! text properly render on mged and archer when compiling with cmake :-) |
| 09:37.44 | jordisayol | now i'll move to cmake the scripts to build deb and rpm packages |
| 09:40.52 | jordisayol | and change some files names on misc/debian dir. Until now, I just need to modify "misc/Makefile.am" with the new files names. May I modify something else? |
| 10:11.49 | CIA-62 | BRL-CAD: 03jordisayol * r46368 10/brlcad/trunk/misc/ (18 files in 3 dirs): Change some debian file names and mime-type names. |
| 10:22.33 | CIA-62 | BRL-CAD: 03jordisayol * r46369 10/brlcad/trunk/ (5 files in 2 dirs): |
| 10:22.33 | CIA-62 | BRL-CAD: Move deb/rpm building scripts to CMAKE. |
| 10:22.33 | CIA-62 | BRL-CAD: Update debian/changelog to the next BRL-CAD release. |
| 12:59.47 | CIA-62 | BRL-CAD: 03d_rossberg * r46370 10/osl/trunk/compile.sh: it's a bash script, neither sh nor tcsh works |
| 13:01.27 | CIA-62 | BRL-CAD: 03d_rossberg * r46371 10/brlcad/trunk/src/liboptical/CMakeLists.txt: osl_rt.cpp was removed some days before |
| 14:08.13 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 14:11.07 | *** join/#brlcad nick (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:16.34 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 15:28.55 | *** join/#brlcad bhinesley (~bhinesley@99.104.175.216) | |
| 16:18.55 | *** join/#brlcad DarkCalff (DC@173.231.40.98) | |
| 16:26.55 | CIA-62 | BRL-CAD: 03n_reed * r46372 10/brlcad/trunk/src/conv/obj-g_new.c: Fixed buffer overflow in collect_grouping_faces_indexes. Realloc test was being done after bad index had already been used. |
| 16:52.22 | CIA-62 | BRL-CAD: 03n_reed * r46373 10/brlcad/trunk/src/libgcv/wfobj/re2c_utils.c: Explicitly initializing vls to reassure valgrind. |
| 17:44.29 | CIA-62 | BRL-CAD: 03n_reed * r46374 10/brlcad/trunk/src/libgcv/wfobj/ (obj_parser.cpp re2c_utils.c re2c_utils.h): Properly freeing scanner and parser objects. |
| 17:51.52 | CIA-62 | BRL-CAD: 03starseeker * r46375 10/brlcad/trunk/misc/CMake/BRLCAD_CompilerFlags.cmake: revert r46366 |
| 17:57.39 | CIA-62 | BRL-CAD: 03starseeker * r46376 10/brlcad/trunk/src/CMakeLists.txt: turn libpc back on, as long as we're not on MSVC - not quite ready for that can of worms yet. |
| 17:58.19 | jordisayol | starseeker: hi |
| 17:59.27 | jordisayol | starseeker: now, compiling in linux with cmake, text in mged anf archer is properly rendered :-) |
| 17:59.52 | starseeker | jordisayol: awesome! |
| 18:00.47 | jordisayol | starseeker: well, I supose that You do the necessary changes |
| 18:01.52 | jordisayol | i'm trying to compile it in opensuse in virtualbox, and I've got some errors |
| 18:05.22 | jordisayol | starseeker: the error is this: |
| 18:05.22 | jordisayol | -- Check if the system is big endian |
| 18:05.22 | jordisayol | -- Searching 16 bit integer |
| 18:05.22 | jordisayol | CMake Error at /usr/share/cmake/Modules/TestBigEndian.cmake:44 (MESSAGE): |
| 18:05.22 | jordisayol | <PROTECTED> |
| 18:05.22 | jordisayol | Call Stack (most recent call first): |
| 18:05.23 | jordisayol | <PROTECTED> |
| 18:05.24 | jordisayol | -- Configuring incomplete, errors occurred! |
| 18:05.46 | jordisayol | starseeker: is there a way to override it? |
| 18:26.07 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 18:39.17 | starseeker | jordisayol: I'm seeing that error on another platform actually - stand by |
| 18:39.51 | jordisayol | starseeker: ok, thanks |
| 18:55.43 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 19:07.10 | CIA-62 | BRL-CAD: 03starseeker * r46377 10/brlcad/trunk/misc/CMake/FindTERMLIB.cmake: Bad CMake module - don't pollute CMAKE_REQUIRED_LIBRARIES for other tests. |
| 19:07.27 | starseeker | jordisayol: give that a shot |
| 19:15.31 | jordisayol | starseeker: now it works |
| 19:15.34 | jordisayol | ;-) |
| 19:38.02 | starseeker | excellent |
| 19:38.11 | starseeker | sneaky devil, but it's gone now :-) |
| 20:17.03 | CIA-62 | BRL-CAD: 03starseeker * r46378 10/brlcad/trunk/src/other/boost/boost/ (indirect_reference.hpp iterator/indirect_iterator.hpp): Hmm - different machine is showing more missing boost headers. |
| 20:24.43 | CIA-62 | BRL-CAD: 03starseeker * r46379 10/brlcad/trunk/src/other/boost/ (742 files in 112 dirs): More boost stuff |
| 20:26.44 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 20:27.13 | jordisayol | I got another compiling error: http://paste.debian.net/127285/ |
| 20:27.23 | CIA-62 | BRL-CAD: 03starseeker * r46380 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: With the new boost, depth 50 isn't gonna cut it - some indications even 128 won't... |
| 20:27.30 | jordisayol | in opensuse 11.4 64 bit |
| 20:31.10 | brlcad | starseeker: getting rt differences raytracing bot after something recent |
| 20:31.13 | brlcad | maybe the bb? |
| 20:35.39 | brlcad | several other primitives too, i'll see if I can get a list |
| 20:36.30 | starseeker | growl |
| 21:11.46 | CIA-62 | BRL-CAD: 03n_reed * r46381 10/brlcad/trunk/src/libgcv/wfobj/obj_grammar.yy: Appeasing compiler by adding gratuitous code to lemon directives so that previously unused parameters get used in the generated output. |
| 21:13.50 | CIA-62 | BRL-CAD: 03n_reed * r46382 10/brlcad/trunk/src/libgcv/wfobj/ (obj_rules.h obj_rules.re): Changed obj_parser_set_extra return type from void* to more appropriate void. Removed unused YY_INPUT macro. |
| 21:22.06 | CIA-62 | BRL-CAD: 03n_reed * r46383 10/brlcad/trunk/src/conv/obj-g_new.c: Suppressing compiler warnings: compressed oversized usage string, added missing test_face prototype, removed unused variables, fixed bad branch statements. |
| 21:29.18 | jordisayol | on Fedora14 32bit got this error: |
| 21:29.18 | jordisayol | /home/jordi/Escriptori/b/src/other/togl/src/../include/GL/glew.h:1165:20: fatal error: GL/glu.h: No such file or directory |
| 21:42.56 | *** part/#brlcad molto_crescendo (~molto_cre@BZ.BZFLAG.BZ) | |
| 22:14.32 | CIA-62 | BRL-CAD: 03jordisayol * r46384 10/brlcad/trunk/ (misc/debian/changelog sh/make_deb.sh sh/make_rpm.sh): |
| 22:14.32 | CIA-62 | BRL-CAD: Change deb/rpm building dependencies. |
| 22:14.32 | CIA-62 | BRL-CAD: Update debian/changelog. |
| 22:23.32 | CIA-62 | BRL-CAD: 03jordisayol * r46385 10/brlcad/trunk/sh/make_rpm.sh: Change mime-type name on rpm builder script |
| 22:56.07 | *** join/#brlcad merzo (~merzo@111-9-132-95.pool.ukrtel.net) | |
| 23:04.36 | starseeker | is the glu.h header present on your system? |
| 23:07.34 | CIA-62 | BRL-CAD: 03starseeker * r46386 10/brlcad/trunk/src/librt/primitives/bot/ (bot.c g_bot_include.c): Apparently rt_bot_bbox does not correctly calculate a minimal bbox - until it's clear why, restore old behavior. |
| 23:34.59 | CIA-62 | BRL-CAD: 03brlcad * r46387 10/brlcad/trunk/BUGS: document a few more bugs encountered via the brep/csg/bot comparison testing. crashes during rtarea and/or gqa (but pix raytracing actually works...) for revolve, brep (revolve), and bot (hyp). |
| 23:36.18 | CIA-62 | BRL-CAD: 03brlcad * r46388 10/brlcad/trunk/TODO: |
| 23:36.18 | CIA-62 | BRL-CAD: document some of the NURBS issues encountered via the brep/csg/bot comparison |
| 23:36.18 | CIA-62 | BRL-CAD: testing. need to speed up brep prep, need to tighten the bounding box (ideally |
| 23:36.18 | CIA-62 | BRL-CAD: so that tools like csgbrep generate equivalent bounding boxes for the brep |
| 23:36.18 | CIA-62 | BRL-CAD: version as the equivalent csg version -- good test cases). |
| 23:45.14 | CIA-62 | BRL-CAD: 03brlcad * r46389 10/brlcad/trunk/sh/facetall.sh: |
| 23:45.15 | CIA-62 | BRL-CAD: this script could use some love, but it can be pretty useful -- particularly |
| 23:45.15 | CIA-62 | BRL-CAD: with these helper scripts. move the converted bot objects into place within the |
| 23:45.15 | CIA-62 | BRL-CAD: hierarchy and show an easy way to count the size of all those polygons within a |
| 23:45.15 | CIA-62 | BRL-CAD: .g file hierarchy. |
| 23:46.15 | CIA-62 | BRL-CAD: 03brlcad * r46390 10/brlcad/trunk/sh/facetall.sh: killtree is probably more appropriate since the region will usually have children |
| 00:17.49 | jordisayol | starseeker: yes, You're right. I'll try to find the rpm package containing this header, thanks |
| 00:26.10 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 00:29.00 | *** join/#brlcad Yoshi477 (~jan@d72-39-60-53.home1.cgocable.net) | |
| 00:33.46 | CIA-62 | BRL-CAD: 03jordisayol * r46391 10/brlcad/trunk/sh/ (make_deb.sh make_rpm.sh): Changed more deb/rpm building dependencies. |
| 00:36.17 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 01:06.22 | CIA-62 | BRL-CAD: 03starseeker * r46392 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/ResetCache.cmake): |
| 01:06.22 | CIA-62 | BRL-CAD: Need more testing, but this setup swaps between 32 and 64 bit compilation |
| 01:06.22 | CIA-62 | BRL-CAD: without requiring the nuking of the build directory files. In other words, |
| 01:06.22 | CIA-62 | BRL-CAD: changing the BRLCAD-CPU_TYPE in cmake-gui and running configure should 'do the |
| 01:06.22 | CIA-62 | BRL-CAD: right thing' automatically, and does on the system tested so far. |
| 01:07.28 | starseeker | sweet |
| 01:08.59 | CIA-62 | BRL-CAD: 03starseeker * r46393 10/brlcad/trunk/CMakeLists.txt: mark BULLET_INCLUDE_DIR as advanced |
| 01:33.35 | brlcad | starseeker: nice list of extra deps there in jordi's stuff (sh/make_deb.sh) |
| 01:36.00 | brlcad | and nice fixup with RESET_CACHE_FILE :) |
| 01:41.49 | CIA-62 | BRL-CAD: 03starseeker * r46394 10/brlcad/branches/STABLE/src/mged/ (mged.c setup.c): Add r45544 to stable - restores rt and rtarea output to mged. |
| 01:45.54 | brlcad | aha .. that's right -- not a vls init issue, it was a ged init issue, the struct gets reinitialized when a database is closed, but was never resetting the i/o handlers |
| 01:51.24 | CIA-62 | BRL-CAD: 03starseeker * r46395 10/brlcad/branches/STABLE/src/librt/opennurbs_ext.h: Add the nurbs wireframe fix from 45532 and 45533 - prevents an infinite loop. |
| 03:46.44 | CIA-62 | BRL-CAD: 03starseeker * r46396 10/brlcad/trunk/src/conv/obj-g_new.c: Mac didn't like NULL, go with 0 |
| 04:43.19 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 05:51.39 | CIA-62 | BRL-CAD: 03starseeker * r46397 10/brlcad/trunk/misc/CMake/FindLEMON.cmake: Can't use a system lemon unless lempar.c is present in the same directory - check that too. |
| 06:15.25 | CIA-62 | BRL-CAD: 03starseeker * r46398 10/brlcad/trunk/misc/CMake/FindLEMON.cmake: lemon generates a .out file by default - could just add -q arg, but we may want that out file for debugging at some point so just go ahead and add it to the output list for now. |
| 06:17.33 | starseeker | come to think of it, our uce-dirent.h file is third party |
| 06:25.45 | CIA-62 | BRL-CAD: 03starseeker * r46399 10/brlcad/trunk/src/mged/CMakeLists.txt: fix mged linking if bullet is around |
| 06:45.59 | CIA-62 | BRL-CAD: 03starseeker * r46400 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: If all the flags fail, don't try it - need to be able to successfully tell the compiler 32/64 bit, otherwise configure specifically for something the compiler can't do should fail. |
| 07:30.21 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 08:01.07 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 08:35.31 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 10:35.03 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-184-039.wlan.tudelft.nl) | |
| 11:28.17 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:40.47 | *** join/#brlcad abhi2011_ (~chatzilla@wlan-145-94-184-039.wlan.tudelft.nl) | |
| 12:50.22 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-184-039.wlan.tudelft.nl) | |
| 13:03.01 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 14:06.06 | brlcad | it is, should get moved |
| 14:36.30 | CIA-62 | BRL-CAD: 03starseeker * r46401 10/brlcad/trunk/src/other/uce-dirent/: uce-dirent is external, prepare a src/other home |
| 14:51.29 | CIA-62 | BRL-CAD: 03starseeker * r46402 10/brlcad/trunk/misc/CMake/FindLEMON.cmake: tweak so things are quieter on repeat runs of cmake |
| 14:51.52 | CIA-62 | BRL-CAD: 03starseeker * r46403 10/brlcad/trunk/src/ (5 files in 2 dirs): move uce-dirent to src/other |
| 15:01.25 | brlcad | thinks we could probably do what that header is doing easier and more simply without it |
| 15:02.27 | brlcad | shouldn't even be needed on most modern non-windows platforms |
| 15:04.12 | starseeker | possibly - it was a quick and functional solution for near-zero work at the time |
| 15:18.29 | CIA-62 | BRL-CAD: 03starseeker * r46404 10/brlcad/trunk/src/other/lemon/README: Add a README file for lemon. probably should add the lemon docs as a text file too but that'll take a bit more reformatting |
| 15:25.20 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-184-039.wlan.tudelft.nl) | |
| 15:31.59 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 16:09.48 | CIA-62 | BRL-CAD: 03starseeker * r46405 10/brlcad/trunk/src/libpc/CMakeLists.txt: Oh yeah, probably should uncomment the tests too. |
| 16:12.33 | CIA-62 | BRL-CAD: 03starseeker * r46406 10/brlcad/trunk/CMakeLists.txt: don't want recursive behavior, so spot .. and ignore it in distcheck path handling. |
| 16:13.52 | CIA-62 | BRL-CAD: 03starseeker * r46407 10/brlcad/trunk/ (10 files in 4 dirs): Update/add dist files and ignore lists for CMake distcheck |
| 16:27.17 | CIA-62 | BRL-CAD: 03starseeker * r46408 10/brlcad/trunk/src/libpc/CMakeLists.txt: Bah, spoke too soon - test apps aren't happy. |
| 16:35.16 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 16:46.43 | starseeker | can't wait to see what happens on windows with obj-g </sarcasm> |
| 19:02.36 | CIA-62 | BRL-CAD: 03n_reed * r46409 10/brlcad/trunk/src/conv/obj-g_new.c: Reformatted usage string to be less verbose. |
| 19:17.01 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 20:00.22 | CIA-62 | BRL-CAD: 03starseeker * r46410 10/brlcad/trunk/CMakeLists.txt: These variables are not needed by default, but useful in some situations - put commented out lines in to illustrate how they would be set |
| 20:45.29 | *** join/#brlcad merzo (~merzo@206-1-132-95.pool.ukrtel.net) | |
| 21:18.51 | *** join/#brlcad ScribbleJ (~chris@99-35-164-204.lightspeed.dwgvil.sbcglobal.net) | |
| 21:20.57 | CIA-62 | BRL-CAD: 03brlcad * r46411 10/brlcad/trunk/TODO: the nmg->brep conversion routine could use a more simple 2d bounding box technique that should give tighter fitting surfaces for quad faces. could go hog wild with a convex hull calculation too. |
| 21:25.44 | ScribbleJ | I'm just getting started on trying to figure out brl-cad... is there a commonly used parts library anyplace, like for bolts, bolt holes, common shapes that aren't primitives, etc? |
| 21:29.13 | CIA-62 | BRL-CAD: 03n_reed * r46412 10/brlcad/trunk/src/librt/primitives/bot/bot.c: Having rt_bot_ifree free normals and face_normals arrays along with the others. |
| 21:32.14 | CIA-62 | BRL-CAD: 03n_reed * r46413 10/brlcad/trunk/ (include/wdb.h src/libwdb/bot.c): Marking unmodified parameters of mk_bot_w_normals as const. |
| 21:37.34 | brlcad | ScribbleJ: hello |
| 21:38.54 | ScribbleJ | Howdy! |
| 21:39.14 | brlcad | ScribbleJ: two answers to that question -- 1) there is and it's rather extensive, but you don't have access to it (it's a proprietary parts database) and more usefully 2) there are various tools in brl-cad that will generate various common shapes |
| 21:39.23 | brlcad | bolt being one of the examples |
| 21:39.37 | ScribbleJ | Those are both good answers. |
| 21:40.16 | brlcad | bolt, coil, fence, gastank, handle, human, picket_fence, tire, window, window_frame, and wire are the currently available "shape" tools (of varying quality and usefulness) |
| 21:42.22 | brlcad | there is also a different bolt script floating around that someone in the community made that will apply threading and supports standard bolt specifications |
| 21:44.25 | ScribbleJ | All right. I'm probably ahead of myself anyhow; I'll need to figure out how to do anything at all first. :) |
| 21:44.41 | brlcad | have you seen the tutorial series on the website? |
| 21:44.44 | ScribbleJ | I'm coming from having only used OpenSCAD and hoping I could find something a little more powerful. |
| 21:44.53 | ScribbleJ | I have - I've read it but I need to walk through it I think. |
| 21:45.43 | brlcad | yeah, until some of the core commands are familiar (the ones on the mged quick reference), you'll have a tough time being productive -- the tutorials help you get there if you actually do them |
| 21:46.31 | brlcad | the tutorials go through a lot of material, but even then only begin to scratch the surface of what you can do |
| 21:54.36 | *** join/#brlcad b0ef (~b0ef@160.24.202.84.customer.cdi.no) | |
| 22:15.11 | CIA-62 | BRL-CAD: 03n_reed * r46414 10/brlcad/trunk/src/conv/obj-g_new.c: Fixed memory leak. A couple allocated arrays were being missed in the free_ti routine. |
| 22:31.53 | CIA-62 | BRL-CAD: 03brlcad * r46415 10/brlcad/trunk/ (5 files in 4 dirs): |
| 22:31.53 | CIA-62 | BRL-CAD: deprecate db_regexp_match() since it's nearly identical to bu_fnmatch(). it's |
| 22:31.53 | CIA-62 | BRL-CAD: probably a minimally impacting change that could be removed, but the meaning of |
| 22:31.53 | CIA-62 | BRL-CAD: the function's boolean return value is flipped making regexp substitution |
| 22:31.53 | CIA-62 | BRL-CAD: clumsy. instead, mark it for removal and make the guts call bu_fnmatch(). this |
| 22:31.53 | CIA-62 | BRL-CAD: was prompted by the existing implementation not supporting an expected feature |
| 22:31.54 | CIA-62 | BRL-CAD: for 'not' character classes ala [^abc] which bu_fnmatch does support. |
| 22:39.30 | CIA-62 | BRL-CAD: 03brlcad * r46416 10/brlcad/trunk/NEWS: |
| 22:39.30 | CIA-62 | BRL-CAD: improved globbing of object names in mged by calling the libbu bu_fnmatch() |
| 22:39.30 | CIA-62 | BRL-CAD: routine instead of the weaker librt db_regexp_match() function. this was |
| 22:39.30 | CIA-62 | BRL-CAD: prompted by noticing that support for negated character classes (e.g., [^abc]) |
| 22:39.30 | CIA-62 | BRL-CAD: was not supported but it should also improve support for other operators such as |
| 22:39.31 | CIA-62 | BRL-CAD: repetitions of character sets and anchoring to beginning and end of object |
| 22:39.32 | CIA-62 | BRL-CAD: names. |
| 22:47.50 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 22:54.12 | CIA-62 | BRL-CAD: 03brlcad * r46417 10/brlcad/trunk/NEWS: |
| 22:54.12 | CIA-62 | BRL-CAD: go ahead and be specific since the four prims affected will fit, cliff tightened |
| 22:54.12 | CIA-62 | BRL-CAD: the bounding boxes which 'should' improve performance but at a minimum will |
| 22:54.12 | CIA-62 | BRL-CAD: affect the autoview size of those primitives when drawn alone (as well as the bb |
| 22:54.12 | CIA-62 | BRL-CAD: command) |
| 23:25.27 | CIA-62 | BRL-CAD: 03brlcad * r46418 10/brlcad/trunk/sh/conversion.sh: |
| 23:25.28 | CIA-62 | BRL-CAD: accommodate the new options, but keeping them ordered similar to the intended |
| 23:25.28 | CIA-62 | BRL-CAD: grouping. renamed the SAVE option to KEEP to avoid ambiguity. restore output |
| 23:25.28 | CIA-62 | BRL-CAD: formatting so that column 70 isn't exceeded (keeping the output neatly |
| 23:25.28 | CIA-62 | BRL-CAD: consistent). lastly, make KEEP respect the VERBOSE setting. |
| 23:25.55 | CIA-62 | BRL-CAD: 03brlcad * r46419 10/brlcad/trunk/sh/conversion.sh: make sure the SEARCH binary exists too, set and use it as SGED |
| 23:35.05 | CIA-62 | BRL-CAD: 03brlcad * r46420 10/brlcad/trunk/sh/conversion.sh: since the working file might no longer be deleted, give it a proper .g suffix. |
| 23:35.40 | *** join/#brlcad ScribbleJ (~chris@99-35-164-204.lightspeed.dwgvil.sbcglobal.net) | |
| 23:40.38 | CIA-62 | BRL-CAD: 03brlcad * r46421 10/brlcad/trunk/NEWS: |
| 23:40.38 | CIA-62 | BRL-CAD: tom browder updated the conversion.sh script with new options for KEEP and |
| 23:40.38 | CIA-62 | BRL-CAD: OPATH, which respectively allow users to keep the working copy and specify the |
| 23:40.38 | CIA-62 | BRL-CAD: object path to use for searching. combine two changes together and remove |
| 23:40.38 | CIA-62 | BRL-CAD: multiline. (multiline news items are rare, usually reserved for multiple |
| 23:40.39 | CIA-62 | BRL-CAD: contributors. also, reworded to fit to column 70.) |
| 23:45.40 | CIA-62 | BRL-CAD: 03brlcad * r46422 10/brlcad/trunk/NEWS: |
| 23:45.40 | CIA-62 | BRL-CAD: technically, memory issues are user visible, so document the recent fix from |
| 23:45.40 | CIA-62 | BRL-CAD: nicholas reed where BoT object memory was not being freed during export. this |
| 23:45.40 | CIA-62 | BRL-CAD: potentially could be a lot of memory for large bots and bots that are frequently |
| 23:45.40 | CIA-62 | BRL-CAD: edited. |
| 23:46.39 | brlcad | abhi2011: how's the progress coming along? |
| 23:47.25 | brlcad | haven't seen any bb updates or questions in a couple days |
| 23:47.45 | abhi2011 | Well havent been able to work on it for the pass 2 days, but will code a bit today :) |
| 23:47.57 | abhi2011 | a bit of thesis writing :P |
| 23:48.02 | brlcad | ah, okay |
| 23:48.59 | abhi2011 | I was wondering, the ultimate aim of the simulate command is to fire it through a mged script and then run rt on the scene ? |
| 23:49.37 | abhi2011 | so like simulate is run for say 1 step and then a scene is rendered and stored as a png image |
| 23:49.48 | abhi2011 | then its run for 2 steps and again a scene is rendered |
| 23:50.12 | abhi2011 | and then all these images will be combined using imagemagik to make a movie |
| 23:50.25 | abhi2011 | for illustration purposes |
| 23:57.54 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 23:58.38 | brlcad | abhi2011: initially, sure |
| 23:59.14 | brlcad | actually, the aim is to perform the simulation itself -- there are a variety of ways to visualize that simulation |
| 00:00.17 | brlcad | the goal, to me, is to get the sim working for the purpose of demonstrating contact/collisions and having objects respond |
| 00:00.51 | brlcad | so I can drop a box onto a ground plane, and watch it tumble after hitting the ground |
| 00:01.01 | abhi2011 | ok |
| 00:01.47 | brlcad | or simulate a virtual brl-cad pool table with accurate friction resistance, spin, n-body collisions |
| 00:02.12 | brlcad | the goal is the sim itself :) |
| 00:02.37 | abhi2011 | ok yes I understand |
| 00:03.37 | abhi2011 | by the way I was trying to have some fun with the current state of the simulate command :P |
| 00:03.44 | abhi2011 | so I was running the simulate command in a tcl loop in mged the other day, and the positions were not getting updated till the loop completes |
| 00:04.02 | abhi2011 | but that I guess is due to the change you mentioned a while back that is required to made |
| 00:04.25 | abhi2011 | before position updates can occur |
| 00:05.39 | brlcad | yep |
| 00:07.00 | brlcad | if you want to see the updates now, you could write a shell script that invokes mged for each iteration and renders a frame |
| 00:08.08 | brlcad | or you could write a tcl proc that invokes your tcl script for just one timestep |
| 00:08.47 | brlcad | iirc -- it should update interactively, just not via the 'source' command |
| 00:10.47 | abhi2011 | ok |
| 00:11.20 | abhi2011 | I noticed the line SET(GEDSIM_LIB libgedsim) was added to the simulate/CMakeLists.txt file |
| 00:11.49 | abhi2011 | so do I still proceed with changing the name of the build target to simulate ? |
| 00:11.59 | abhi2011 | like so : BRLCAD_ADDLIB(simulate "${SIMULATE_SOURCES}" ${BULLET_LIBRARIES}) |
| 00:12.20 | brlcad | same reasonsing still holds true :) |
| 00:13.08 | brlcad | it's not a library, don't want to start a convention for libged commands |
| 00:14.13 | brlcad | it's only being built as a library due to cmake limitations -- and it might still get folded into the parent SOURCES with different rules later |
| 00:14.29 | abhi2011 | yes, ok then I will proceed with the change to the target at both places, libged/simulate/CMakeLists.txt and libged/CMakeLists.txt |
| 00:18.25 | abhi2011 | umm by parent sources you mean mged's code ? |
| 00:18.36 | brlcad | libged |
| 00:18.40 | abhi2011 | oh ok |
| 00:26.00 | CIA-62 | BRL-CAD: 03brlcad * r46423 10/brlcad/trunk/TODO: |
| 00:26.00 | CIA-62 | BRL-CAD: need to create a class that inherits from ON_Brep so we can cleanly implement |
| 00:26.00 | CIA-62 | BRL-CAD: methods that openNURBS intentionally removes. that way we won't have to fork |
| 00:26.00 | CIA-62 | BRL-CAD: and merge changes each time openNURBS is updated, our additions can be managed |
| 00:26.00 | CIA-62 | BRL-CAD: more easily, and our changes can be consolidated. |
| 00:49.15 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 00:58.34 | CIA-62 | BRL-CAD: 03brlcad * r46424 10/brlcad/trunk/src/librt/opennurbs_ext.h: if the child node being added is null, do nothing |
| 01:03.24 | CIA-62 | BRL-CAD: 03brlcad * r46425 10/brlcad/trunk/src/librt/opennurbs_ext.cpp: |
| 01:03.24 | CIA-62 | BRL-CAD: so the big crash is happening due to the surfaces being NULL after a call to |
| 01:03.24 | CIA-62 | BRL-CAD: Split(). not yet at all clear how that's happening so add debug abort code, |
| 01:03.24 | CIA-62 | BRL-CAD: return null, and protect against null derefences. would be cleaner to ensure |
| 01:03.24 | CIA-62 | BRL-CAD: that subdivideSurfaceByKnots() will never return NULL (and someone (tm) should |
| 01:03.24 | CIA-62 | BRL-CAD: fix that) but it's not immediately clear to me what the Split() failure means |
| 01:03.25 | CIA-62 | BRL-CAD: yet. |
| 01:13.13 | CIA-62 | BRL-CAD: 03brlcad * r46426 10/brlcad/trunk/src/librt/opennurbs_ext.cpp: ws indent consistency cleanup |
| 01:16.47 | CIA-62 | BRL-CAD: 03brlcad * r46427 10/brlcad/trunk/src/librt/pr.c: why hasn't this missing semicolon caused a build failure before now?? |
| 01:21.35 | abhi2011 | regarding the cmake target changes for simulate, I wanted to confirm that these were the desired changes |
| 01:21.40 | abhi2011 | here is the diff : http://bin.cakephp.org/view/269125967 |
| 01:23.03 | abhi2011 | I removed SET(GEDSIM_LIB libgedsim) as the new target 'simulate' can be directly specified everywhere instead of another variable ${GEDSIM_LIB} ..or ${SIMULATE} |
| 01:23.05 | CIA-62 | BRL-CAD: 03brlcad * r46428 10/brlcad/trunk/src/librt/primitives/ (4 files in 3 dirs): more missing semicolons.. wtf. |
| 01:25.35 | brlcad | abhi2011: most of the devs receive an e-mail for every commit that includes the diff -- if there's a problem, someone will usually say something or fix it |
| 01:26.01 | brlcad | so don't hesitate on committing unless you've not tested it or know it'll break something |
| 01:26.44 | abhi2011 | ok, yes I have tested it, since its the build system, being careful :) |
| 01:30.22 | CIA-62 | BRL-CAD: 03abhi2011 * r46429 10/brlcad/trunk/src/ (3 files in 3 dirs): Changed the name of the simulation sources build target to simulate, removed GEDSIMLIB |
| 01:30.51 | brlcad | being careful is good, but being productive is better ;) |
| 01:31.36 | abhi2011 | true :) |
| 01:31.42 | brlcad | no worries, someone will let you know if it's messed up, and if it is then it definitely is your responsibility to fix (ideal) or revert (if you can't fix it immediately) |
| 01:32.44 | CIA-62 | BRL-CAD: 03brlcad * r46430 10/brlcad/trunk/src/libwdb/pipe.c: aha! it was the (void *)0 change to the runtime-debug disabled mode macros (knew it would catch if-statements, did not expect it to catch missing semis). awesome side effect. :) |
| 01:40.42 | brlcad | woot, raytrace works! |
| 01:45.43 | CIA-62 | BRL-CAD: 03brlcad * r46431 10/brlcad/trunk/src/conv/patch/patch-g.c: last one, another semi missing. |
| 01:57.52 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 01:59.42 | abhi2011 | hmm, trying to find out how you resolved that missing semi colon issue , looking at pipe.c and magic.c, so NO_BOMBING_MACROS is used when runtime debug is disabled ? |
| 02:03.01 | abhi2011 | * is defined |
| 02:03.31 | brlcad | disabling runtime debug sets NO_BOMBING_MACROS (among others) |
| 02:03.53 | brlcad | the macros used to be empty when disabled, so no problem |
| 02:04.06 | brlcad | likewise, when enabled, it was an if {} so no problem |
| 02:04.19 | CIA-62 | BRL-CAD: 03starseeker * r46432 10/brlcad/trunk/src/ (4 files in 4 dirs): Make a stab at a CMake setup for libged commands in subdirectories. |
| 02:04.32 | brlcad | turned into a no-op statement, though, it became a syntax error and the missing semis could be detected |
| 02:08.07 | abhi2011 | brlcad: ok |
| 02:18.45 | CIA-62 | BRL-CAD: 03brlcad * r46433 10/brlcad/trunk/NEWS: |
| 02:18.45 | CIA-62 | BRL-CAD: due to the slew of 'i seemed to encounter bad geometry' messages that print out |
| 02:18.45 | CIA-62 | BRL-CAD: during raytracing, note that the fix for the m1151 geometry that made rt stop |
| 02:18.45 | CIA-62 | BRL-CAD: crashing was probably due to bad geometry. either way, it was a crash case that |
| 02:18.45 | CIA-62 | BRL-CAD: is no longer crashing. |
| 02:32.18 | starseeker | abhi2011: give that a a shot for ged simulate building - I can't test it on this machine (no bullet) but hopefully that will be cleaner |
| 02:33.24 | brlcad | heh, 5 hours to prep if it were single cpu |
| 02:33.30 | brlcad | (nurbs) |
| 02:34.47 | starseeker | winces |
| 03:43.06 | CIA-62 | BRL-CAD: 03starseeker * r46434 10/brlcad/trunk/CMakeLists.txt: Fix comment - we aren't interested in setting for debug on Windows at the moment - usual pattern there is to run from build directory and then create the .exe installer |
| 04:00.59 | CIA-62 | BRL-CAD: 03starseeker * r46435 10/brlcad/trunk/src/libged/CMakeLists.txt: Ah, right - need to format this so that the BRLCAD_ADDLIB macro is OK with it. |
| 04:11.24 | starseeker | there we go - simulate command builds on my home box now |
| 07:19.20 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 07:29.56 | CIA-62 | BRL-CAD: 03jordisayol * r46436 10/brlcad/trunk/sh/make_rpm.sh: Add "ISO-8859-1 75dpi fonts" for fedora rpm building dependency. |
| 09:21.13 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 09:53.15 | abhi2011 | starseeker: yes the changes built cleanly on my machine as well |
| 11:44.20 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 12:13.43 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-186-249.wlan.tudelft.nl) | |
| 12:36.27 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 12:43.57 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 14:01.05 | *** join/#brlcad plaes_ (~plaes@gn237.zone.eu) | |
| 14:06.29 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 14:28.28 | *** join/#brlcad kunigami2 (~kunigami@loco-gw.ic.unicamp.br) | |
| 14:37.35 | brlcad | gmornin peoples! |
| 14:44.25 | *** join/#brlcad CIA-62 (~CIA@cia.atheme.org) | |
| 15:10.03 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:26.57 | abhi2011 | goedemorgen brlcad :P |
| 15:33.16 | abhi2011 | hmm RT_GET_TREE(tp, &rt_uniresource); doesnt appear to be setting a good magic number when I try to create a rt_comb_internal by manually filling up a tree |
| 15:34.44 | abhi2011 | got something like this now : http://bin.cakephp.org/view/151711593 |
| 15:35.39 | abhi2011 | RT_GET_TREE() sets a wierd magic number like ((tp))->magic = 0x91191191 |
| 15:36.02 | abhi2011 | there is probably a version specific marco for setting a valid number |
| 15:47.27 | abhi2011 | will try RT_TREE_INIT(tp); |
| 15:49.57 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 16:18.27 | abhi2011 | brlcad: is there a reason why OP_DB_LEAF is not handled in rt_bound_tree() ? |
| 16:19.06 | abhi2011 | I use it when filling up the values in a rt_comb_internal for primitives |
| 16:28.18 | abhi2011 | tp->tr_l.tl_op = OP_SOLID does not work , and that is the closest case I can see(to primitives) |
| 16:32.24 | abhi2011 | hm, maybe I should start with an union op in the tree |
| 16:48.27 | CIA-62 | BRL-CAD: 03n_reed * r46437 10/brlcad/trunk/src/librt/prep.c: Removed dead code from rt_clean_resource_basic. It was an uncompiled duplication of the code in rt_clean_resource_complete. |
| 17:04.04 | abhi2011 | ok I need to use OP_SOLID and somehow I need to convert the idb_meth member in rt_db_internal * to the a struct soltab *stp; so rt_bound_tree() can get the bb |
| 17:04.22 | abhi2011 | aaaargh....almost there |
| 17:22.29 | CIA-62 | BRL-CAD: 03n_reed * r46438 10/brlcad/trunk/src/librt/shoot.c: rt_res_pieces_clean was dereferencing rtip without checking for NULL value. |
| 17:38.30 | abhi2011 | well it seems the struct soltab is not needed and nor is rt_bound_tree() for primitives, a simple call to ip->idb_meth->ft_bbox(ip, &rpp_min, &rpp_max) suffices for getting the bb of primitives |
| 17:38.33 | CIA-62 | BRL-CAD: 03n_reed * r46439 10/brlcad/trunk/src/conv/obj-g_new.c: Cleaning rt_uniresource after it's no longer needed. |
| 17:52.45 | abhi2011 | its onto regions now |
| 18:29.06 | *** join/#brlcad ScribbleJ (~chris@99-35-164-204.lightspeed.dwgvil.sbcglobal.net) | |
| 18:38.55 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 18:48.13 | abhi2011 | hmm, no , cant just insert a new OP_DB_LEAF case into rt_bound_tree() , seems even after I reach the leaf, the most information I can get from the leaf node is the name of the primitive, with no other information , like points etc |
| 19:02.47 | abhi2011 | seems a rt_db_internal representing a region has only information about the operations that build the region and the primitive names, not the shape information about the primitives themselves |
| 19:11.58 | CIA-62 | BRL-CAD: 03n_reed * r46440 10/brlcad/trunk/src/libgcv/wfobj/ (obj_grammar.yy obj_parser_state.h): indent/ws cleanup |
| 19:13.28 | CIA-62 | BRL-CAD: 03n_reed * r46441 10/brlcad/trunk/src/libgcv/wfobj/ (7 files): Applied standard headers and footers. |
| 20:12.29 | starseeker | abhi2011: that bbox interface is brand new, and some of them (BoT for certain) aren't really correct yet |
| 20:12.49 | starseeker | abhi2011: if you want to use that, you probably need to start by fixing rt_bot_bbox |
| 20:15.06 | CIA-62 | BRL-CAD: 03starseeker * r46442 10/brlcad/trunk/src/libgcv/wfobj/obj_parser_state.h: stray character |
| 20:18.40 | abhi2011 | starseeker: oh shoot, no easy way out then :P |
| 20:19.21 | starseeker | abhi2011: well, fixing rt_bot_bbox is definitely the right way to go - the intent is for rt_*_bbox routines to be a fast way to get a correct bbox |
| 20:19.58 | starseeker | would suggest looking at what rt_bot_plot does - it can draw lines, so it must have logic for visiting the data structure |
| 20:20.24 | abhi2011 | ok, by the way do you have any idea about the other issue, about the op_db_leaf case |
| 20:20.39 | abhi2011 | i though OP_SOLID would be used uniformly for primtives |
| 20:20.46 | abhi2011 | in the tree nodes I mean |
| 20:21.08 | starseeker | not offhand - would have to study the code, and unfortunately I'm in the middle of house stuff |
| 20:21.16 | starseeker | (nice big storm on the way...) |
| 20:21.30 | abhi2011 | ah yah i heard |
| 20:22.38 | abhi2011 | irene ? |
| 20:26.36 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 20:30.48 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 20:43.06 | *** join/#brlcad ScribbleJ (~chris@99-35-164-204.lightspeed.dwgvil.sbcglobal.net) | |
| 22:40.08 | CIA-62 | BRL-CAD: 03n_reed * r46443 10/brlcad/trunk/src/conv/obj-g_new.c: Removed call to perror after syntax error. Error message is already printed elsewhere, and errno is not set. |
| 22:50.51 | CIA-62 | BRL-CAD: 03n_reed * r46444 10/brlcad/trunk/src/libgcv/wfobj/obj_grammar.yy: Making return codes clear. |
| 22:50.57 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 23:30.41 | *** part/#brlcad roberthl (~robert@mediawiki/RobertL) | |
| 02:50.01 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 07:41.35 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 12:45.30 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 13:22.30 | CIA-62 | BRL-CAD: 03brlcad * r46445 10/brlcad/trunk/src/mged/dodraw.c: doesn't look like mged_bound_solid() is used outside of this file, so mark as static. |
| 15:09.04 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 19:51.38 | *** join/#brlcad merzo (~merzo@12-152-132-95.pool.ukrtel.net) | |
| 20:35.40 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 23:25.24 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 09:01.02 | *** join/#brlcad DarkCalfz (DC@173.231.40.98) | |
| 09:19.28 | *** join/#brlcad plaes (~plaes@gn237.zone.eu) | |
| 10:24.09 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 10:38.15 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 10:38.15 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 10:38.51 | *** join/#brlcad CIA-62 (~CIA@cia.atheme.org) | |
| 10:39.08 | *** join/#brlcad plaes (~plaes@gn237.zone.eu) | |
| 10:39.43 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 10:39.43 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 10:40.33 | *** join/#brlcad DarkCalfz (DC@173.231.40.98) | |
| 10:40.33 | *** join/#brlcad kunigami2 (~kunigami@loco-gw.ic.unicamp.br) | |
| 10:40.33 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 10:40.38 | *** join/#brlcad merzo (~merzo@12-152-132-95.pool.ukrtel.net) | |
| 10:41.58 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 10:41.58 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 10:41.58 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 10:45.33 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 10:45.33 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 13:45.10 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 13:46.37 | abhi2011 | is there a way to calculate a transformation matrix to convert between co-ordinate systems |
| 13:47.17 | abhi2011 | bullet's co-ordinate system assumes the y axis as up, but is right handed, just like mged |
| 13:48.09 | abhi2011 | so objects fall towards the xz plane when gravity is applied |
| 13:48.45 | abhi2011 | the transformation matrix has to map the translations and rotations to mged's co-ordinate system correctly |
| 13:57.08 | abhi2011 | i ll try a simple rotation about the x-axis |
| 14:55.21 | abhi2011 | trying to reset some primtives to the origin before the simulation starts |
| 14:55.47 | abhi2011 | apparently rt_matrix_transform() applies a translation/rotation to the existing transform |
| 14:56.22 | abhi2011 | there does not seem to be a functions that can directly set the absolute world transform of a comb/primitive |
| 15:29.17 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 17:19.42 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 17:29.05 | *** join/#brlcad merzo (~merzo@77-191-133-95.pool.ukrtel.net) | |
| 18:28.00 | brlcad | abhi2011: perhaps there's a way to specify the coordinate system to bullet |
| 18:29.37 | brlcad | otherwise, you can just apply the rotation before you feed values to bullet and the reverse when you read values and apply them back on geometry |
| 18:32.40 | abhi2011 | brlcad: ok |
| 18:33.57 | abhi2011 | about the bounding box function, I have been trying with combp = (struct rt_comb_internal *)ip->idb_ptr; and rt_bound_tree(combp->tree, tree_min, tree_max) |
| 18:34.32 | abhi2011 | however rt_bound_tree() does not implement the OP_DB_LEAF case which causes the traversal of the tree to get stuck |
| 18:35.50 | abhi2011 | so I was considering adding that case, but even if I rt_bound_tree() does get me to the leaf, it seems the leaf only had information about a primtive's name |
| 18:36.22 | abhi2011 | not its shape information such as a pointer to its ft_bbox() method etc, or any geometry info |
| 18:49.29 | brlcad | abhi2011: so it sounds like there's some disconnect, that you're not setting up something correctly |
| 18:50.59 | brlcad | if I recall correctly, you had it working earlier, when you were mimicking what the bb command does (ala _ged_get_obj_bounds) |
| 18:51.13 | brlcad | now you're basically saying that method doesn't work |
| 18:51.22 | brlcad | but you had it working for combs, so what's changed? |
| 18:55.53 | brlcad | IF ip is a comb (which you have to check), then you still have to call rt_gettree() to "load" the members of that comb and calculate the primitive bb's (and THEN you can call rt_bound_tree() to get the overall comb bb) |
| 18:56.57 | brlcad | read src/libged/get_obj_bounds.c again -- it does what you're trying to do |
| 18:57.12 | brlcad | it just starts with a char*name instead of an rt_db_internal |
| 18:58.39 | brlcad | when your function is done and working, it should drop right into _ged_get_obj_bounds() and _ged_get_obj_bounds2() |
| 18:58.58 | brlcad | (or better still, into the callers of those functions so they can be eliminated) |
| 19:30.08 | abhi2011 | brlcad: yes I just found that out, that I need to call rt_gettree() for combs, otherwise the members are not loaded |
| 19:30.24 | abhi2011 | well now I ll get it working |
| 19:35.28 | abhi2011 | ok I got the reason why I had said rt_bound_tree() was working before |
| 19:36.15 | abhi2011 | it was with a standalone program which obtained a struct rt_i *rtip directly from the the database file , using rtip = rt_dirbuild(argv[1], title, sizeof(title)); |
| 19:36.54 | abhi2011 | this trip does have the primtives and can be safely passed to rt_gettree(rtip, argv[2]), to load all the primtives for a combination |
| 19:37.19 | abhi2011 | but in the bb box function, I create an in-mem rtip |
| 19:37.40 | abhi2011 | which does not know anything about the primitives |
| 19:37.59 | abhi2011 | as it was not made from the original file |
| 19:39.09 | abhi2011 | so calling rt_gettree() as follows : ( when I am trying to find the bb for a comb of course), would lead to the members of that comb still not getting loaded |
| 19:40.52 | abhi2011 | if (rt_gettree(rtip, "dummy") < 0){... |
| 19:42.36 | abhi2011 | the only thing thats changed is the rtip between the 2 cases (the one where I build rtip using rt_dirbuild() and the bb function case which uses an in-mem rtip ) |
| 19:46.44 | abhi2011 | brlcad: thats why the original rtip that was made from the database file would be needed to get to the primtives, because rt_gettree() needs to get the original rtip |
| 20:14.34 | brlcad | I'm not sure much of that made sense to me :) |
| 20:16.05 | brlcad | recounting what you did to me isn't necessary, I know what you did :) it was a question to ask yourself to hopefully help you figure out what you now need to do to get things working |
| 20:18.14 | abhi2011 | yes ok :) , I am certain now that the original dbip needs to be passed and I ll get the bb using it and wrap up the function |
| 20:18.29 | abhi2011 | perhaps in the near future i ll be able to remove it |
| 20:19.02 | brlcad | if it's a comb, your job is really easy |
| 20:19.58 | brlcad | the only real work remaining is/was supposed to be figuring out how to calculate the bb for a primitive |
| 20:20.14 | brlcad | you had *A* solution, just not the ideal solution |
| 20:20.55 | brlcad | so you could go with what you had (using the inmem) ... or figure out how to build an rt_comb_internal by hand with just that one primitive |
| 20:22.31 | brlcad | I'd suggest getting it to work for both comb and prims using the two methods you already know work, then trying to build the rt_comb_internal as a replacement method for prims |
| 20:22.56 | brlcad | that way, the code will be at least functional and can be tested for any object type |
| 20:43.09 | *** join/#brlcad merzo (~merzo@194-13-133-95.pool.ukrtel.net) | |
| 21:02.24 | abhi2011 | brlcad: yes, I will be building a rt_comb_internal for finding the bb of both prims and combs |
| 21:03.46 | abhi2011 | the only other thing I will be doing is adding an extra paramter to rt_bound_internal() |
| 21:04.42 | abhi2011 | will make it like : rt_i rt_bound_internal(struct rt_i *rtip, struct rt_db_internal *ip, point_t rpp_min, point_t rpp_max) |
| 21:05.06 | brlcad | why? you shouldn't need to do that |
| 21:05.14 | abhi2011 | ah ha...:) |
| 21:05.20 | abhi2011 | so that is because |
| 21:05.39 | abhi2011 | the rtip that I pass to rt_gettree() should be the original rtip |
| 21:05.53 | abhi2011 | not one created from an in-mem dbip |
| 21:07.19 | brlcad | it feels like we're talking in circles :) |
| 21:07.53 | abhi2011 | the in-mem dbip has no geometry information about the primtives in the model, and consequently neither does the struct rt_i* made from it |
| 21:08.25 | abhi2011 | well, yeah I know it feels that way, and its my fault really |
| 21:09.09 | abhi2011 | the rt_bound_tree(combp->tree, tree_min, tree_max) method never worked before actually |
| 21:09.13 | brlcad | sure, that you found out last week -- you'd have to add all of the comb's members (that's why you were researching db_functree()) |
| 21:09.22 | abhi2011 | yes exactly |
| 21:09.35 | abhi2011 | and db_functree() runs against the same problem see |
| 21:09.45 | abhi2011 | its unable to add the primtives |
| 21:10.03 | brlcad | because? |
| 21:10.04 | abhi2011 | because it uses db_lookup() on the in-mem db_i |
| 21:10.24 | abhi2011 | the one I create and pass to it inside the rt_bound_internal() function |
| 21:10.24 | brlcad | you don't run functree on the inmem |
| 21:11.11 | brlcad | youd run functree on the original dbi to add them to the inmem |
| 21:11.11 | abhi2011 | yes, I should run it on the original struct db_i |
| 21:11.31 | abhi2011 | yes, but the original db_i is not passed |
| 21:11.34 | abhi2011 | to the function |
| 21:11.43 | abhi2011 | so I would need to pass it |
| 21:12.30 | brlcad | that would be better than passing an rtip, but still seems unnecessary.. |
| 21:12.39 | abhi2011 | yes, umm why |
| 21:12.51 | abhi2011 | there is no other way to add the primitives |
| 21:13.14 | abhi2011 | other than picking them form the original struct db_i and putting them in the in-mem struct db_i |
| 21:16.27 | brlcad | the why would be because the rt_comb_internal should already have a union tree * filled out |
| 21:16.46 | brlcad | the inmem one you were trying didn't, but that's obvious why .. you only added the comb |
| 21:18.25 | brlcad | the caller will be passing you an rt_db_internal that should be filled out, that tree should be passable to rt_bound_tree() as-is .. no? |
| 21:18.42 | brlcad | if it's not, it sounds like a problem in the caller code |
| 21:19.24 | brlcad | (like not calling dirbuild or gettrees or something .. don't think it matters which) |
| 21:19.24 | abhi2011 | yes it should be passable to rt_bound_tree(), however the structure of the tree is wrong |
| 21:20.09 | abhi2011 | the tree leads to the primtive node , but that node has just the primtive name |
| 21:20.49 | abhi2011 | it does not have any geometry information and the tr_op is not OP_SOLID |
| 21:20.55 | abhi2011 | its OP_DB_LEAF |
| 21:20.59 | abhi2011 | which is not correct |
| 21:21.18 | brlcad | so why is that, sounds like something not getting set up right |
| 21:21.30 | abhi2011 | yes so let me explain :) |
| 21:21.39 | brlcad | like I said -- "it sounds like a problem in the caller code" |
| 21:22.21 | abhi2011 | hmm yeah |
| 21:22.33 | abhi2011 | the rt_db_internal() should have a complete tree |
| 21:23.56 | abhi2011 | but the caller code is very straight forward : http://bin.cakephp.org/view/1978180787 |
| 21:24.36 | brlcad | rt_bound_tree() is clearly used by src/libged/bb.c (via get_obj_bounds.c()) so if they can do the setup, you should be able to too (even if it requires the caller to do something first) |
| 21:25.23 | abhi2011 | ok |
| 21:25.28 | brlcad | so if that caller code isn't working right, there's something else you need to have it do |
| 21:26.35 | brlcad | maybe see what rt_gettree() does since that's what get_obj_bounds.c calls before calling librt |
| 21:26.45 | abhi2011 | ah! |
| 21:26.46 | brlcad | you may need to do some subportion of what it's doing |
| 21:27.00 | abhi2011 | so its called before |
| 21:27.11 | abhi2011 | yes I ll check it |
| 21:27.13 | brlcad | there's no point in calling rt_gettree in the caller code because you don't have an rtip |
| 21:27.33 | brlcad | but maybe there is some other rt function that sets up and initializes the rt_comb_internal properly |
| 21:27.40 | brlcad | very likely :) |
| 21:27.44 | abhi2011 | ok |
| 21:28.00 | brlcad | something related to loading a union tree * |
| 21:29.48 | abhi2011 | yeah the first thing get_obj_bounds() does it /* Make a new rt_i instance from the existing db_i sructure */ and finally calls rt_gettree() on it |
| 21:31.05 | abhi2011 | which I could do in my caller code too :P, but lets see if there some other way |
| 21:34.47 | brlcad | yeah, if the caller had to do all of that, it would defeat the simplicity we're going for |
| 21:35.13 | brlcad | if you find out that you have to add a dbip parameter, that's fine -- but you should make sure first |
| 21:37.25 | abhi2011 | well yes, there is no way to intialize the tree of an rt_comb_internal() for a regions without doing walk on the database instance tree using the original db_i |
| 21:38.09 | brlcad | how do you know that? |
| 21:39.14 | abhi2011 | because only the original db_i would have the information about the geometry of the primitives |
| 21:40.02 | abhi2011 | and that db_i would need to be used to look up any primitive names that we encounter while traversing the tree for a comb |
| 21:40.21 | brlcad | right, okay -- I misread what you were saying |
| 21:40.50 | brlcad | the question is whether there is already a routine or simple method that will initialize it for you |
| 21:41.02 | brlcad | other than rt_gettree() |
| 21:46.16 | brlcad | if something doesn't exist, that actually might be a good case for adding a function that creates a non op_db_leaf union tree suitable for your function (which calling code would then be required to call beforehand) |
| 21:47.31 | brlcad | basically something like rt_gettree() but specifically for combs, like maybe a new rt_comb_tree() function |
| 21:48.15 | abhi2011 | ok |
| 21:48.58 | abhi2011 | i did come across |
| 21:48.59 | abhi2011 | db_comb_describe |
| 21:49.07 | abhi2011 | and rt_comb_describe() |
| 21:52.32 | abhi2011 | ok yeah, adding a function that creates a non op_db_leaf union tree would still require passing the original db_i to it, so all the geometry info about the model is available |
| 21:53.00 | brlcad | yes, something like: union tree *rt_comb_tree(const struct db_i *dbip, const struct rt_db_internal *ip) |
| 21:55.41 | abhi2011 | ok |
| 21:55.45 | brlcad | I hate to say it, because that's probably the way to go, but I think we're getting out of scope |
| 21:55.51 | brlcad | a bit at least |
| 21:56.27 | brlcad | figuring out how to implement that function properly would probably take a few days at best, a couple weeks at worst |
| 21:56.33 | abhi2011 | yeah I dont see any other function in raytrace.h that could make a rt_comb_internal |
| 21:57.10 | brlcad | plus figuring out the important parts from rt_gettree() is probably a little bit out of depth |
| 21:57.26 | brlcad | that's relatively complex code so it'd be a challenge |
| 21:57.44 | abhi2011 | yah that would really go deep into 3D geometry I think :P |
| 21:57.59 | brlcad | not really |
| 21:58.06 | brlcad | it gets deep into librt structures is all |
| 21:58.13 | abhi2011 | ok |
| 21:58.15 | brlcad | at lot of recursion and complex data structures |
| 21:58.41 | brlcad | doable, but not immediately relevant for the goals of this project |
| 21:59.07 | brlcad | so pass the dbip, but add a FIXME note to the comment header with the details we've talked about |
| 21:59.31 | abhi2011 | ok |
| 21:59.34 | brlcad | stating the need for something like rt_comb_tree to get a portion of the rt_gettree() initialization |
| 21:59.54 | abhi2011 | right |
| 03:50.06 | CIA-62 | BRL-CAD: 03Jimblack 07http://brlcad.org * r3084 10/wiki/Main_Page: |
| 05:06.55 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 05:06.55 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 07:18.40 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 09:35.05 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3085 10/wiki/User:Abhijit: /* Log */ |
| 09:35.25 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3086 10/wiki/User:Abhijit: /* Log */ |
| 11:10.13 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:38.19 | abhi2011 | brlcad: about passing the struct db_i* in rt_bound_internal() |
| 12:40.13 | abhi2011 | it would be necessary to call rt_gettree() inside this function |
| 12:40.33 | abhi2011 | to get the primtives for a comb loaded |
| 12:40.55 | abhi2011 | is that fine, or would it be better to avoid calling rt_gettree() ? |
| 12:41.37 | abhi2011 | if I do need to call rt_gettree(), then the 2nd parameter is the name of the comb/primitive |
| 12:44.16 | abhi2011 | which is generally got using a directory pointer using dp->d_namep |
| 12:45.42 | abhi2011 | the only way to get a directory pointer is to use again use name of the comb and then db_lookup() |
| 12:48.17 | abhi2011 | I have been searching for getting the comb or primitive name from a struct rt_db_internal if at its possible |
| 12:51.10 | abhi2011 | seems all of this can be avoided if the caller code simply calls rt_gettree() before passing the struct rt_db_internal* |
| 12:51.23 | abhi2011 | then we do not even need to pass the struct db_i * |
| 12:54.56 | abhi2011 | or the calling code can pass the name of the comb/primitive |
| 13:18.20 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 14:16.20 | CIA-62 | BRL-CAD: 03starseeker * r46446 10/brlcad/trunk/TODO.cmake: Update todo items for CMake |
| 14:48.43 | CIA-62 | BRL-CAD: 03starseeker * r46447 10/brlcad/trunk/src/other/CMakeLists.txt: mark BRLCAD_TERMLIB_BUILD as advanced |
| 14:53.27 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-186-249.wlan.tudelft.nl) | |
| 14:57.11 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:04.18 | CIA-62 | BRL-CAD: 03starseeker * r46448 10/brlcad/trunk/src/other/re2c/bootstrap/parser.hh: May need the parser.hh file too... |
| 15:04.54 | CIA-62 | BRL-CAD: 03starseeker * r46449 10/brlcad/trunk/src/other/re2c/bootstrap/parser.hh: fix comment |
| 15:08.16 | CIA-62 | BRL-CAD: 03starseeker * r46450 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: MSVC doesn't know what to do with D_FORTIFY_SOURCE, apparently |
| 16:38.14 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-186-249.wlan.tudelft.nl) | |
| 16:42.44 | brlcad | abhi2011: gah |
| 16:44.22 | brlcad | that's a problem, rt_db_internals are nameless ... forgot about that |
| 16:44.30 | abhi2011 | oh shoot :P |
| 16:44.42 | abhi2011 | yeah by the time its reaches the rt layer |
| 16:44.46 | abhi2011 | names are no longer relevant |
| 16:45.01 | brlcad | that's by design, so you can write a given rt_db_internal as many times as you want with different names |
| 16:45.19 | abhi2011 | ok |
| 16:45.21 | brlcad | you might have to resort one layer higher, with a struct directory * |
| 16:46.26 | abhi2011 | yes , however a struct directory * is made using db_lookup(), which unfortunately also requires a name , and I cannot use a dummy name, I have to use the exact name of the comb the user passed |
| 16:46.59 | brlcad | huh? |
| 16:47.14 | brlcad | libged knows the name |
| 16:47.26 | brlcad | the same name you used to get the rt_db_internal |
| 16:47.36 | brlcad | instead of that, you'll just pass the directory |
| 16:48.48 | abhi2011 | oh ok, so I pass the directory and the struct db_i *, something like this : rt_bound_internal(struct db_i *dbip, struct directory *dp , struct rt_db_internal *ip, point_t rpp_min, point_t rpp_max) |
| 16:49.04 | brlcad | if you pass the dp, you no longer should pass the ip |
| 16:49.09 | brlcad | you can get the ip from the dp |
| 16:49.12 | abhi2011 | yes right |
| 16:49.15 | abhi2011 | ok |
| 16:49.26 | abhi2011 | I was wondering :) |
| 16:49.39 | abhi2011 | why we simply have a function which accepts the dp and the name |
| 16:49.52 | abhi2011 | um no scratch that |
| 16:50.05 | abhi2011 | dp and dbip is enough |
| 16:50.38 | abhi2011 | i thought it would be easy to have a function that just accept the name of the comb/primitive and the dbip |
| 16:50.49 | abhi2011 | that would be easy to pass by a user |
| 16:51.37 | abhi2011 | something like rt_bound_internal(char*name , struct db_i *dbip, point_t rpp_min, point_t rpp_max) |
| 16:52.14 | brlcad | that's libged's responsibility |
| 16:52.22 | abhi2011 | oh ok |
| 16:52.25 | brlcad | libged works with strings, names |
| 16:52.34 | abhi2011 | ok |
| 16:53.56 | abhi2011 | yeah I get it now :) |
| 16:53.57 | brlcad | really, I want to just pass the rt_db_internal, but as we already discussed, another routine needs to be written first to fill out the comb's tree properly |
| 16:54.04 | abhi2011 | yes |
| 16:54.14 | brlcad | don't are about names (or even directory), just want the bb given geometry |
| 16:54.28 | abhi2011 | yes true |
| 16:54.37 | brlcad | working with a dbip+dp is a start, though |
| 16:55.13 | brlcad | that can be refactored to call a lower-level calculate-my-bb-with-just-this-ip later |
| 16:55.53 | abhi2011 | ok |
| 16:57.59 | abhi2011 | I have a question regarding the transformation matrices of primitives |
| 16:58.45 | abhi2011 | so in the commands that somehow transform the object, I can see that the commands generally call rt_matrix_transform() |
| 17:00.00 | abhi2011 | and this function ultimately goes and put a new matrix in the tl_mat member of the struct union tree |
| 17:00.22 | abhi2011 | that exists in the tr_l member of a union tree* |
| 17:00.40 | brlcad | usually |
| 17:00.46 | abhi2011 | however this is a transform matrix, not the matrix representing the absolute world position |
| 17:01.07 | abhi2011 | however bullet gives me the matrix that represents the transform in absolute world co-ordinates |
| 17:01.50 | abhi2011 | so if the object were to start from (0,0,0) and with no rotations along any of the axes, then the transform matrix from bullet can be applied to get the object to its intended position |
| 17:02.27 | abhi2011 | now the thing is, I generally copy an existing object in mged, and then apply bullet's transform on it |
| 17:02.41 | abhi2011 | however this new object is no made at the origin |
| 17:02.58 | abhi2011 | its made in the existing object's position |
| 17:03.09 | abhi2011 | which is correct as far as copying is concerned |
| 17:03.42 | brlcad | waits for the question |
| 17:03.51 | abhi2011 | however , it would be great if I were able to reset any copies I make , to the origin |
| 17:04.02 | abhi2011 | there are no such commands to do this in mged however |
| 17:04.38 | abhi2011 | and if I apply bullet's transforms on a copy, which is not in the origin, then the translation adds to the existing position |
| 17:04.57 | brlcad | you're going way too far down the rabbit hole |
| 17:05.08 | abhi2011 | :) |
| 17:05.11 | brlcad | ask a question :) |
| 17:05.46 | brlcad | or at least ask me to explain how brl-cad tracks positions if you don't know what to ask :) |
| 17:05.52 | abhi2011 | ok |
| 17:06.39 | abhi2011 | yeah it would be better if you explain :) |
| 17:07.02 | abhi2011 | my issue is how to apply the bullet transforms on a object which is not at the origin |
| 17:07.48 | abhi2011 | since the transforms got from bullet specify the translations of the object with respect to the origin, not the position of the object at the start of the simulation |
| 17:08.28 | brlcad | so if you remember my earlier comments from when you first got started -- and why you've been messing around with bounding boxes for so long... |
| 17:10.15 | brlcad | geometry in brl-cad is described in a rather pure mathematical sense, sometimes in implicit form and sometimes in an explicit form |
| 17:11.13 | abhi2011 | yes |
| 17:12.28 | abhi2011 | however the positions of the objects are stored explicitly somewhere in a comb/prims attributes |
| 17:12.44 | brlcad | yes and no (sorry multitasking) |
| 17:12.52 | brlcad | combinations, for example, have no position |
| 17:12.59 | brlcad | they are just a grouping |
| 17:13.06 | abhi2011 | ah yes right |
| 17:13.08 | brlcad | they can apply a transformation to that grouping |
| 17:13.20 | abhi2011 | ok |
| 17:13.21 | brlcad | that have an *implicit* position |
| 17:13.35 | abhi2011 | ok |
| 17:13.41 | brlcad | it's implied that the position of a combination is the position of all it's continuent submembers |
| 17:13.48 | abhi2011 | yes right |
| 17:14.06 | brlcad | so if you calculate that bb of a comb, for example, you could pretend that one of the corners or that the center is that comb's "position" |
| 17:14.30 | abhi2011 | ok |
| 17:14.36 | brlcad | the same can be said of all of the primitives |
| 17:14.57 | brlcad | many/most of them have an explicit position, but it's defined per primitive |
| 17:15.18 | abhi2011 | ok |
| 17:16.25 | starseeker | remembers he needs to look at rt_bot_bbox again... |
| 17:16.26 | brlcad | for a sphere, it's the center point; for a cylinder, it's the center of the base oval; for a torus, it's also at the center which doesn't even happen to be *on* the object (it's in the void in the middle) |
| 17:17.00 | brlcad | you could get at that "position", but it's somewhat meaningless for this purpose |
| 17:17.10 | brlcad | all that matters really is having a consistent handle |
| 17:17.13 | brlcad | that's where the bb comes in |
| 17:17.33 | abhi2011 | ok |
| 17:17.35 | brlcad | get the bb for any object, then you can consistently consider the bb center to be a position |
| 17:18.00 | abhi2011 | ok |
| 17:18.02 | brlcad | from bullet's perspective, all you're dealing with is a lot of boxes |
| 17:18.09 | abhi2011 | yes true |
| 17:18.24 | brlcad | you can implement an overlap/collision detection handler later |
| 17:18.42 | abhi2011 | however a bb would not roll on a surface even if it represents a sphere |
| 17:18.49 | abhi2011 | yes right |
| 17:19.00 | brlcad | sure it will |
| 17:19.24 | brlcad | at least, it should be able to |
| 17:19.47 | brlcad | you're not using the "box" as *geometry* |
| 17:19.54 | brlcad | that's just your handle |
| 17:19.59 | abhi2011 | yes right I get that now |
| 17:20.20 | abhi2011 | its the handle to the geometry in mged |
| 17:21.31 | brlcad | the bbox routines you're working with are also not oobb's, they' aabb's |
| 17:21.42 | abhi2011 | yes right |
| 17:22.25 | brlcad | so even for simple arb8's, you'll not be able to get objects doing anything more than translating without collision detection |
| 17:22.39 | brlcad | translation should be the first proof-of-concept step though |
| 17:22.58 | abhi2011 | ok |
| 17:23.49 | brlcad | e.g., take a 10x10x10 axis-aligned box at 0 0 100, drop it to a ground plane at 0 0 0 |
| 17:24.06 | brlcad | demo should either stop immediately or bounce :) |
| 17:24.12 | CIA-62 | BRL-CAD: 03starseeker * r46451 10/brlcad/trunk/src/other/CMakeLists.txt: when doing win, also need xlib |
| 17:24.17 | abhi2011 | yes ok |
| 17:24.51 | abhi2011 | but say the user runs the sim for 100 steps |
| 17:24.56 | brlcad | that initial collision detection could rely purely on bullet since the bb's are all axis-aligned |
| 17:25.23 | brlcad | or you write a collision detection routine that just returns 1 if the bb's overlap |
| 17:25.23 | abhi2011 | ok |
| 17:25.33 | abhi2011 | right |
| 17:25.52 | abhi2011 | about setting the position of the box |
| 17:25.57 | abhi2011 | in mged |
| 17:27.14 | brlcad | so for starters, you should only work with comb's for now (in mged and in code), just to keep things simple |
| 17:27.18 | brlcad | one entity type |
| 17:28.07 | brlcad | no primitives by themselves |
| 17:28.43 | abhi2011 | ok, and I set the comb position by simply obtaining how far the object has translated along z axis and using rt_matrix_transform() to translate the comb to the new position |
| 17:29.06 | abhi2011 | I mean *how far the* comb* has translated |
| 17:29.28 | brlcad | you know how to apply a translation matrix, I presume? |
| 17:29.53 | abhi2011 | yes, just pass it to rt_matrix_transform() |
| 17:30.12 | abhi2011 | with the proper elements set |
| 17:30.46 | brlcad | there are loads of vector and matrix routines in vmath.h and libbn (bn.h and src/libbn) |
| 17:31.24 | abhi2011 | ok |
| 17:33.16 | brlcad | for example |
| 17:33.57 | brlcad | the 'rot' and 'orot' (aka orotate) commands are how rotations are applied to geometry within mged |
| 17:34.09 | brlcad | src/libged/rot.c and src/libged/orot.c |
| 17:34.45 | brlcad | you can see there how rot.c sets up a rotation vector and calls bn_mat_angles() to obtain a rotation matrix |
| 17:35.47 | abhi2011 | yes, I have seen rot.c and orot.c, they both transform the object's existing orientation |
| 17:35.56 | brlcad | similarly orotate.c calls bn_mat_angles() but then also bn_mat_xform_about_pt() along with some routines to normalize the matrix before applying it to a comb |
| 17:36.28 | abhi2011 | so I would need to get the transform of the comb wrt the position of the comb at the beginning of the sim |
| 17:36.46 | abhi2011 | so if the comb is say at position 0,0,100 and at the end of it at 0,0,1 |
| 17:37.19 | abhi2011 | then I would need the translation matrix to be set for a translation of 0,0,99 |
| 17:37.21 | abhi2011 | and not the translation with respect to the origin of 0,0,1 |
| 17:38.36 | brlcad | for translation (what you need first), tra.c is keen which sets up a translation vector then calls vutil.c |
| 17:39.15 | abhi2011 | yes I checked that yesterday, quite straighforward code |
| 17:39.57 | abhi2011 | the mistake I was making was applying the wrong translations (with respect to the origin) |
| 17:40.05 | brlcad | actually, if it starts at 0,0,100, it won't end at 0,0,1 .. :) |
| 17:40.37 | abhi2011 | yeah it will fall to 0,0,0 |
| 17:40.58 | abhi2011 | at the end |
| 17:41.25 | abhi2011 | before bouncing around |
| 17:42.08 | abhi2011 | if the ground plane is at 0,0,0 |
| 17:42.37 | brlcad | if the box is 10x10x10, and you're using center as V and ground at 0,0,0, then it'll stop at 0,0,5 :) |
| 17:43.02 | abhi2011 | yes , i was ignoring the height, yes right |
| 17:46.06 | brlcad | so what I imagine will happen is you'll get the bb's for all objects, pass those to bullet to set up the scene, perform one timestep and bullet is going to return some information indicating that the box moves down (a vector) OR that the box is in a new position (a new position) |
| 17:46.14 | brlcad | if it's a vector, you just apply it like tra |
| 17:46.42 | brlcad | if it's a point, you calculate the vector based on the previous position and apply that vector like tra |
| 17:47.13 | abhi2011 | yes , I would need to create a rigid body and give it a collision shape in bullet, so I ll just use a box for now |
| 17:47.49 | abhi2011 | yes right |
| 17:49.03 | CIA-62 | BRL-CAD: 03starseeker * r46452 10/brlcad/trunk/src/other/incrTcl/itk/CMakeLists.txt: Ah, right - if itk is taking responsibility for its path setting, need to be more complete. |
| 17:55.07 | *** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 18:03.34 | CIA-62 | BRL-CAD: 03n_reed * r46453 10/brlcad/trunk/src/libgcv/wfobj/obj_grammar.yy: Only reporting first syntax error instead of all of them. |
| 18:06.22 | CIA-62 | BRL-CAD: 03starseeker * r46454 10/brlcad/trunk/src/other/incrTcl/itk/CMakeLists.txt: more itk build logic cleanup |
| 18:14.07 | brlcad | nice ... in response to "why reinvent the wheel?" |
| 18:14.12 | brlcad | "Because after long enough time, there's always someone who's irked about the performance of the wheel and wants to replace it with conveyor belts or robot legs. Sometimes even square wheels. And because we've done round wheels for so long, old lessons have faded or been deemed outdated and so we try it. Then it turns out it's not that great except for very limited use cases, but we're too deep invested and stubborn so we'll try fixing it. After a lot of fightin |
| 18:15.48 | brlcad | that probably trucated the end... |
| 18:15.50 | brlcad | "After a lot of fighting against windmills, we slowly reinvent and rediscover the reasons why we used a wheel in the first place. Then the cycle starts over. Same with most NIH projects, they start out as being radically different and then end up looking much the same after tackling the same challenges." |
| 18:17.01 | starseeker | heh |
| 18:18.07 | starseeker | supposes some of the CMake logic probably would fall into that category... |
| 18:20.51 | starseeker | "oh, so THAT |
| 18:20.58 | starseeker | 's why that compile flag is there" |
| 18:45.17 | brlcad | starseeker: you could change the -D_FORTIFY_SOURCE=2 to a #define and you'd elimiante the MSVC conditional |
| 18:46.09 | starseeker | erm. you mean #define D_FORTIFY_SOURCE 2 in brlcad_config.h? |
| 18:46.17 | starseeker | how would that eliminate the conditional? |
| 18:46.38 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 18:46.54 | brlcad | you're presently checking for a "c flag" (which is bogus, it's a cppflag) named "D_FORTIFY_SOURCE=2" |
| 18:47.02 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 18:47.12 | brlcad | that turns into -D_FORTIFY_SOURCE=2 to gcc |
| 18:47.17 | starseeker | right |
| 18:47.26 | brlcad | presumably /D_FORTIFY_SOURCE=2 for msvc or something similar |
| 18:48.06 | brlcad | either way, I assume you hit some compilation error due to that since the D_FORTIFY_SOURCE is rather lame gcc-specific way to test that flag |
| 18:48.06 | CIA-62 | BRL-CAD: 03n_reed * r46455 10/brlcad/trunk/src/conv/obj-g_new.c: Added check for valid number of command line arguments. |
| 18:48.17 | brlcad | that is equivalent to #define _FORTIFY_SOURCE 2 |
| 18:48.25 | starseeker | not an error, just a blathering warning from MSVC |
| 18:48.26 | brlcad | -DVAR=VAL |
| 18:48.36 | brlcad | is #define VAR VAL |
| 18:49.24 | brlcad | so that's my point, you could eliminate the blather by outputting the symbol instead of trying to pass it as a compile flag |
| 18:49.40 | brlcad | less logic, no conditionals |
| 18:51.07 | brlcad | if (MSVC) conditionals make baby jesus cry, el no le gusta |
| 18:51.11 | starseeker | should it still be conditionalized on debugging? |
| 18:51.15 | brlcad | sure |
| 18:51.20 | starseeker | hmm... |
| 18:51.59 | starseeker | <snort> I'd say MSVC takes care of the crying all by itself |
| 18:52.51 | brlcad | sure, but it still gets to the whole platform vs feature issue -- the conditional is only valid today and is a major pita to maintain, debug, and unwind later |
| 18:54.11 | brlcad | there's always a better way and it's usually not even more code if refactored according to dry principle |
| 18:56.34 | CIA-62 | BRL-CAD: 03starseeker * r46456 10/brlcad/trunk/ (3 files in 3 dirs): Make _FORTIFY_SOURCE a config.h define instead of a compile flag check. |
| 18:56.47 | starseeker | that what you mean? |
| 18:57.45 | brlcad | exactly |
| 18:58.19 | starseeker | wonders why he didn't do that initially... did I misread the autotools logic? |
| 18:59.09 | brlcad | wouldn't have been an msvc issue for autotools build |
| 18:59.27 | brlcad | most all *nix platforms support -DVAR=VAL |
| 18:59.37 | brlcad | s/platforms/compilers/ so the test works |
| 18:59.48 | starseeker | ah, right |
| 18:59.48 | brlcad | that assumption is flawed for non |
| 18:59.54 | brlcad | "non gcc-like" compilers |
| 19:00.21 | brlcad | CHECK_C_FLAG_GATHER must be something you wrote? |
| 19:00.25 | starseeker | yes |
| 19:00.35 | brlcad | because stfw results only in references to brl-cad :) |
| 19:01.44 | starseeker | yeah, there are a few custom macros - I really should probably try to cut down / consolidate those at some point |
| 19:03.32 | n_reed | brlcad: stfw... your initialisms are starting to get obscure |
| 19:14.59 | brlcad | ~stfw |
| 19:14.59 | ibot | [stfw] Search The F*cking Web. See http://justf*ckinggoogleit.com/ |
| 19:15.56 | n_reed | Already looked it up. |
| 19:17.02 | n_reed | Just that "pita" took me a sec because it wasn't in caps. "dry" I knew, but stfw... |
| 19:17.22 | brlcad | wow, you knew dry but now stfw.. that's pretty much backwards ;) |
| 19:17.36 | brlcad | dry is pretty obscure |
| 19:17.54 | brlcad | half million hits for stfw can't be that obscure |
| 19:18.20 | n_reed | well i don't text or chat as a rule, but i have read 97 things, so... |
| 19:23.26 | brlcad | stfw is pretty chat-specific, maybe even irc-specific |
| 19:23.34 | brlcad | (but not likely) |
| 19:25.50 | ``Erik | dry is pretty big with ruby and python folk O.o |
| 19:26.59 | n_reed | of which i'm neither; that makes sense though i guess |
| 19:56.29 | starseeker | O.o http://labs.qt.nokia.com/2011/08/24/qt-quick-3d-tutorial-video/ |
| 20:03.52 | CIA-62 | BRL-CAD: 03n_reed * r46457 10/brlcad/trunk/src/libgcv/wfobj/obj_grammar.yy: Allowing "" as a user-defined object name. |
| 20:05.14 | CIA-62 | BRL-CAD: 03starseeker * r46458 10/brlcad/trunk/src/mged/CMakeLists.txt: Fix space in mged CMakeLists.txt - also did this for bwish, got sucked into a previous commit. |
| 20:29.41 | starseeker | woot! new obj-g (kinda) works on Windows |
| 21:14.36 | abhi2011 | brlcad: I have a question regarding solid table pointers : const struct soltab |
| 21:15.40 | abhi2011 | so is there a way to get one from the struct rt_db_internal of a primtive |
| 21:16.30 | abhi2011 | I need to insert it into the rt_comb_internal |
| 21:16.40 | abhi2011 | while finding the bb of a primtive |
| 21:26.06 | abhi2011 | or I can avoid making a rt_comb_internal and just use the bounds already got in the rtip (as rt_gettree() has been called) |
| 21:31.07 | abhi2011 | there is a third option to use ip->idb_meth->ft_bbox() which is the new interface for finding bbs of primitives, but thats known to not work correctly for BOTs |
| 21:39.01 | abhi2011 | hmm found rt_find_solid(), will use that |
| 22:11.48 | *** join/#brlcad merzo (~merzo@24-13-133-95.pool.ukrtel.net) | |
| 23:11.30 | CIA-62 | BRL-CAD: 03n_reed * r46459 10/brlcad/trunk/src/conv/obj-g_new.c: MSVC compiler doesn't support %zu format. Changed all instances to %lu. |
| 00:57.35 | brlcad | n_reed: MSVC doesn't need to support %zu for those functions, that's OUR function |
| 00:58.24 | brlcad | bu_log() implements support for %z along with the other bu_* vararg functions, so what was there before was correct |
| 01:00.08 | starseeker | it didn't work though |
| 01:00.38 | starseeker | on MSVC anyway |
| 01:15.02 | brlcad | why |
| 01:16.09 | brlcad | it's perfectly valid code, so if msvc is complaining, the complaint should be scrutinized as to why |
| 01:16.53 | brlcad | either there was some *other* stdlib printf-style function it encountered with a %zu (in which case the "fix" should have been just for that instance) |
| 01:17.51 | brlcad | or it really is complaining just because it thinks it recognizes a varargs-style function with print specifiers (in which case if it's trying to be that clever, there should be options to turn the behavior off) |
| 01:18.39 | brlcad | given we have %zu's sprinkled in hundreds of places throughout the code, and have for several releases, I find it a little hard to believe that it's the latter... |
| 01:19.45 | brlcad | on a somewhat related note... msvc is an environment where we've not yet vetted "warnings mean error" because it reports too many false positives by default, if that's coming into play |
| 01:23.35 | brlcad | if it's just a warning being spit out, there are hundreds of other places so that'd be a good one to just ignore in the output or disable for that compiler |
| 01:44.30 | *** join/#brlcad merzo (~merzo@24-13-133-95.pool.ukrtel.net) | |
| 01:57.25 | starseeker | it was incorrect behavior - printing "zu" instead of the number in question |
| 01:57.40 | starseeker | dunno if it was one instance in the code or not though - have to ask n_reed |
| 01:58.48 | starseeker | it compiles fine and runs, just getting the strings messed up somewhere along the line on WIN32 |
| 02:36.46 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 02:43.21 | brlcad | yeah, that sounds like a bonefide libbu bug then |
| 02:43.37 | brlcad | all printf-style printing is consolidated into just one or two functions |
| 02:44.26 | brlcad | yeah, src/libbu/vls.c:bu_vls_vprintf() |
| 02:44.58 | brlcad | ooh, I think I see the issue |
| 02:57.00 | CIA-62 | BRL-CAD: 03brlcad * r46460 10/brlcad/trunk/CMakeLists.txt: might help to actually test for size_t :) |
| 02:59.38 | starseeker | winces |
| 02:59.41 | starseeker | thanks |
| 03:01.46 | CIA-62 | BRL-CAD: 03starseeker * r46461 10/brlcad/trunk/src/conv/obj-g_new.c: Put zu back - hopefully actually testing for size_t fixed it (oopsie). |
| 03:02.05 | brlcad | not likely, working ona fix |
| 03:13.37 | CIA-62 | BRL-CAD: 03brlcad * r46462 10/brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: take a stab at implementing a new build test for c99 format specifiers. not all of them, though, only care about %z for now since it's the one currently causing havoc with msvc builds. |
| 03:18.21 | CIA-62 | BRL-CAD: 03brlcad * r46463 10/brlcad/trunk/CMakeLists.txt: |
| 03:18.21 | CIA-62 | BRL-CAD: arguable whether testing libc supports %z as a print width specifier is a |
| 03:18.21 | CIA-62 | BRL-CAD: compiler characteristic or type testing but go with the latter. add the (new |
| 03:18.21 | CIA-62 | BRL-CAD: and untested) BRLCAD_CHECK_C99_FORMAT_SPECIFIERS macro so we can toggle code |
| 03:18.21 | CIA-62 | BRL-CAD: logic based on HAVE_C99_FORMAT_SPECIFIERS |
| 03:18.57 | brlcad | starseeker: feel free to sanity check my feeble cmake foo there |
| 03:25.08 | CIA-62 | BRL-CAD: 03brlcad * r46464 10/brlcad/trunk/src/libbu/vls.c: use bu_strlcpy() instead of strncpy() since it guarantees null-termination which we were doing manually |
| 03:33.16 | starseeker | main concern is that HAVE_STDINT_H may not be defined in that context without setting a flag... |
| 03:54.13 | CIA-62 | BRL-CAD: 03starseeker * r46465 10/brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: This test succeeds on a platform where I would expect it to succeed - may need more tweaking, but I *think* this will do it. |
| 03:54.32 | CIA-62 | BRL-CAD: 03brlcad * r46466 10/brlcad/trunk/src/libbu/vls.c: |
| 03:54.33 | CIA-62 | BRL-CAD: add in initial logic to replace instances of %z in format specifiers for |
| 03:54.33 | CIA-62 | BRL-CAD: platforms that don't support that c99 feature. since msvc is presently the only |
| 03:54.33 | CIA-62 | BRL-CAD: known platform with this busted feature behavior, scan the format specifier and |
| 03:54.33 | CIA-62 | BRL-CAD: replace instances of %z with %I which is presently more commonly found on |
| 03:54.33 | CIA-62 | BRL-CAD: win32/win64 environments. |
| 03:58.20 | CIA-62 | BRL-CAD: 03brlcad * r46467 10/brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: we definitely need stdio.h (for sprintf()) but it shouldn't be conditional (c89 is required) |
| 03:58.48 | starseeker | brlcad: you were checking for 1 as a return from sprintf, but even on gentoo it returns 3 (I'm fairly sure my system is new enough to support zu...) |
| 04:01.05 | brlcad | hm |
| 04:05.36 | starseeker | what about printing 1234 as a size_t and looking for 4 instead of 3? |
| 04:07.28 | CIA-62 | BRL-CAD: 03brlcad * r46468 10/brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: in that same vein, we need string.h for strcmp |
| 04:09.38 | brlcad | starseeker: BRLCAD_HEADER_STDC looks somewhat useless as-is |
| 04:09.54 | starseeker | brlcad: yeah, probably |
| 04:10.00 | CIA-62 | BRL-CAD: 03starseeker * r46469 10/brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: tweak so that number of chars in number doesn't match number of chars in specifer |
| 04:10.01 | brlcad | iirc, the point of AC_HEADERS_STDC is to halt if they're available |
| 04:10.02 | starseeker | IIRC it was marked as obsolete |
| 04:10.14 | brlcad | er, not available |
| 04:10.23 | brlcad | so we know not to even try proceeding |
| 04:10.25 | starseeker | usually I just define it as 1... |
| 04:10.50 | brlcad | it? |
| 04:10.57 | starseeker | wasn't sure if any of our supported platforms wouldn't have STDC |
| 04:11.24 | brlcad | we've had a minimum compilation requirement of c89 for a couple years now |
| 04:11.31 | starseeker | #define STDC_HEADERS 1 |
| 04:11.58 | brlcad | yeah, that's useless to set unless it's used somewhere by a 3rd party relying on it getting set |
| 04:12.03 | brlcad | if we rely on it, we shouldn't |
| 04:12.19 | starseeker | I think it's just tcl (where I'm hhandling it anyway) |
| 04:12.40 | brlcad | we shouldn't be testing anything c89 provides as a strict matter of principle (other than as a build environment sanity check like I mentioned, to halt) |
| 04:13.16 | starseeker | the only reason it was ever there was because I was going for full parity with the autotools build |
| 04:13.37 | brlcad | then it should halt, not set a #define :) |
| 04:13.59 | starseeker | brlcad: I was going to yank it |
| 04:14.44 | brlcad | *shrug* it's fine in that one place, but it should serve a purpose (sanity test) |
| 04:15.14 | brlcad | that's particularly why configure.ac has that whole block that itemizes which headers are c89, which are c95, which are c99, etc .. |
| 04:15.22 | starseeker | doubt it's worth maintaining unless there's a realistic chance we'll need it - IIRC it was a bit of a poin |
| 04:15.25 | starseeker | pain even |
| 04:15.46 | brlcad | absolutely shouldn't waste time testing for c89 headers, setting HAVE_*_H defines, nor wrapping them in #ifdef blocks |
| 04:16.36 | starseeker | yeah, looks like only tcl/tk really cares |
| 04:17.06 | brlcad | it's just 16 lines of "code" ... if that's painful ... some threshold might need adjusting :) |
| 04:17.28 | starseeker | more painful trying to figure out what the AC macro in question was doing |
| 04:17.38 | brlcad | that macro by itself is inconsequential |
| 04:17.40 | starseeker | still doubts he fully duplicated all of its testing |
| 04:18.01 | brlcad | it's more making sure we don't check for c89 headers in other places like you'd just added to that new macro |
| 04:18.53 | brlcad | undoubtedly, looks like you test for but never even use HAVE_STRING_H_MEMCHR |
| 04:19.12 | brlcad | and HAVE_STDLIB_H_FREE |
| 04:19.55 | brlcad | unless you make it halt, just yank it |
| 04:20.21 | CIA-62 | BRL-CAD: 03starseeker * r46470 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_CheckFunctions.cmake): nevermind about STDC_HEADERS - we don't really need it, only tcl/tk really use it so let them deal with it. |
| 04:20.28 | brlcad | more effective would be a test for exactly all of the c89 headers |
| 04:21.33 | brlcad | starseeker: where'd be a good place to replicate the header comment block from configure.ac to help prevent folks from adding unnecessary tests? |
| 04:22.10 | starseeker | probably stage 5 in the toplevel CMakeLists.txt file |
| 04:22.16 | brlcad | oh, duh .. |
| 04:22.32 | brlcad | sprintf returns number of chars printed -- was thinking sscanf |
| 04:22.42 | starseeker | most of the tests are there and should go there - CheckFunctions was for special stuff that needed something more complicated than just checking the include file |
| 04:23.37 | starseeker | again based on the autoconf tests - it may be that a lot of those could be reduced to header checks on modern hardware |
| 04:24.43 | starseeker | (around line 1031 in CMakeLists.txt) |
| 04:25.04 | brlcad | ah, already there .. got it |
| 04:25.39 | starseeker | mostly went with what was in configure.ac - "foreign" tests that crept in usually resulted from AC_* macros of one sort or another |
| 04:25.49 | brlcad | maybe worth a build system regression? |
| 04:26.09 | starseeker | oh, checking for improper tests? |
| 04:26.41 | brlcad | yeah |
| 04:27.10 | brlcad | probably fine |
| 04:27.35 | starseeker | shrugs - yeah, at some point that might be worth doing |
| 04:27.51 | starseeker | is hoping like heck that once this is done the build system will require only occasional tweaking |
| 04:31.52 | brlcad | no chance |
| 04:32.31 | brlcad | the only time the build system doesn't require changes is when the source code doesn't change |
| 04:33.35 | brlcad | even for fully managed IDE environments like msvc, you want/need/have to change the build system all the time as the code evolves |
| 04:34.39 | CIA-62 | BRL-CAD: 03starseeker * r46471 10/brlcad/trunk/CMakeLists.txt: Hmm... it might be that platforms with multiple CFG types shouldn't share the same output directories... try this. |
| 04:35.28 | starseeker | growl |
| 04:35.31 | brlcad | the best you can aim for is make the build system logic simple enough to maintain and clean enough to be extended by a new/inexperienced developer easily |
| 04:35.51 | brlcad | that's why I kept saying "this is still code" |
| 04:36.35 | brlcad | all the same coding rules and guidelines still apply, dry principle, neat organized code, concise yet descriptive vars, etc |
| 04:38.08 | CIA-62 | BRL-CAD: 03brlcad * r46472 10/brlcad/trunk/CMakeLists.txt: |
| 04:38.08 | CIA-62 | BRL-CAD: checking order changed. update docs. need to check compiler characteristics |
| 04:38.08 | CIA-62 | BRL-CAD: earlier within cmake so that flags are set properly. remember there was a |
| 04:38.08 | CIA-62 | BRL-CAD: specific reason for delaying the compiler testing until after headers/libs/types |
| 04:38.08 | CIA-62 | BRL-CAD: with the autotools build but don't remember what that reason was any longer (and |
| 04:38.09 | CIA-62 | BRL-CAD: it's not documented) so go with the flow -- makes more sense to test the |
| 04:38.10 | CIA-62 | BRL-CAD: compiler flags earlier anyways. |
| 04:42.11 | CIA-62 | BRL-CAD: 03starseeker * r46473 10/brlcad/trunk/CMakeLists.txt: typo, wording tweak |
| 04:47.52 | CIA-62 | BRL-CAD: 03starseeker * r46474 10/brlcad/trunk/CMakeLists.txt: more rewording |
| 04:50.45 | CIA-62 | BRL-CAD: 03starseeker * r46475 10/brlcad/trunk/CMakeLists.txt: I suppose the date/timestamp code failing to generate a date should be fatal - that has to be fixed if it breaks. |
| 04:55.18 | starseeker | hmm - I may need to keey the #define DEBUG statement off of something other than CMAKE_BUILD_TYPE... |
| 04:55.38 | starseeker | makes a note to check what that's used for tomorrow... |
| 05:03.14 | CIA-62 | BRL-CAD: 03starseeker * r46476 10/brlcad/trunk/CMakeLists.txt: don't need the math expression anymore |
| 07:27.29 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 08:08.14 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 08:35.31 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 10:32.48 | CIA-62 | BRL-CAD: 03n_reed * r46477 10/brlcad/trunk/src/libbu/vls.c: Typo; statement with no effect. |
| 10:42.18 | *** join/#brlcad n_reed_ (44378e88@gateway/web/freenode/ip.68.55.142.136) | |
| 11:30.51 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-186-249.wlan.tudelft.nl) | |
| 11:53.23 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:24.28 | brlcad | thx n_reed, didn't get a chance to compile-test it yet |
| 13:05.45 | abhi2011 | phew finally the bb function works for all cases |
| 13:06.38 | abhi2011 | seems the tree returned in a struct rt_db_internal by the function rt_db_lookup_internal(), has the wrong op codes |
| 13:07.15 | abhi2011 | even if I use the dbip got from a rtip : rt_db_lookup_internal(rtip->rti_dbip, dp->d_namep, &dp, &intern, LOOKUP_NOISY, &rt_uniresource) |
| 13:07.59 | abhi2011 | had to resort to getting the region for a passed comb (if the comb is a region) : regp = _rt_getregion(rtip, dp->d_namep); |
| 13:08.18 | abhi2011 | once I get the region, then rt_bound_tree(regp->reg_treetop, tree_min, tree_max) always works |
| 13:09.34 | abhi2011 | cant understand why the tree returned in the struct rt_db_internal by the function rt_db_lookup_internal() should have the wrong op_code |
| 13:16.29 | abhi2011 | its certainly not due to a lack of preparing the rtip by using rt_gettree() etc |
| 13:18.51 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 14:27.49 | brlcad | abhi2011: what do you mean by wrong op code? |
| 14:28.43 | abhi2011 | the code at the primitive node is set to OP_DB_LEAF (12) when it should be set to OP_SOLID (1) |
| 14:30.11 | abhi2011 | so by the code i mean tr_a.tu_op |
| 14:30.29 | abhi2011 | in the union tree of combp->tree |
| 14:31.57 | abhi2011 | so one would expect this to work : http://bin.cakephp.org/view/716816388 |
| 14:32.09 | abhi2011 | but it returns the bb for a region as 0 |
| 14:33.41 | abhi2011 | because the tree could not be traversed completely due to the wrong code in tr_a.tu_op, which is used during the recursion in rt_bound_tree() as switch ( tp->tr_op)... |
| 14:38.49 | abhi2011 | all the other functions which use rt_bound_tree() find a matching a region by using for (BU_LIST_FOR(regp, region, &(rtip->HeadRegion))) {... |
| 14:38.56 | abhi2011 | so they never encounter this problem |
| 14:42.40 | CIA-62 | BRL-CAD: 03brlcad * r46478 10/brlcad/trunk/src/libbu/ (10 files): |
| 14:42.40 | CIA-62 | BRL-CAD: rename all of the test programs to have a test_ prefix instead of a tester |
| 14:42.40 | CIA-62 | BRL-CAD: suffix. makes them easier to identify and groups tests together. should help |
| 14:42.40 | CIA-62 | BRL-CAD: keep things more organized moving forward as more unit tests are written. |
| 14:45.46 | CIA-62 | BRL-CAD: 03brlcad * r46479 10/brlcad/trunk/src/libbu/ (test_basename.c test_htond.c test_progname.c test_timer.c): update file names in headers and usage |
| 14:56.56 | brlcad | abhi2011: the code is fine |
| 14:57.17 | brlcad | that code just means that it's a leaf node (which it is) and that the node is still in db format (which it is) |
| 14:57.56 | brlcad | the problem may just be that rt_bound_tree() needs to implement that switch case |
| 14:58.51 | brlcad | very likely is the problem |
| 15:00.58 | brlcad | nice work on the new rt_bound_internal() though, looking great in that paste -- only issue I see are the exact (== 0) floating point comparisons at the bottom, those should be NEAR_ZERO()) |
| 15:51.33 | brlcad | starseeker: running cmake in debug mode and encountering some strange issues |
| 15:52.37 | brlcad | variety of tests that fail but shouldn't, failures detecting 32bit/64bit, error about TEST_BIG_ENDIAN during debug but not during non-debug |
| 15:56.49 | abhi2011 | brlcad: ok then I ll add a OP_DB_LEAF case to rt_bound_internal |
| 15:57.02 | brlcad | abhi2011: cool |
| 15:58.09 | abhi2011 | just hope its that simple :P |
| 15:59.36 | brlcad | you can't just pretend an OP_DB_LEAF is an OP_SOLID if that's what you're thinking |
| 15:59.41 | brlcad | you have to add the logic for that case |
| 16:01.26 | abhi2011 | yes i understand that, however I do expect the solid pointer to be present in tp->tr_a.tu_stp; |
| 16:02.24 | abhi2011 | because a OP_DB_LEAF is the end of the line for the tree , there should no more recursion needed |
| 16:02.32 | brlcad | actually I believe that is exactly what OP_DB_LEAF means is not done yet |
| 16:02.59 | brlcad | if it's in db format, then a solid hasn't been loaded yet |
| 16:03.04 | abhi2011 | yes |
| 16:03.09 | abhi2011 | hmm |
| 16:03.29 | abhi2011 | and rt_db_lookup_internal() always returns in db format |
| 16:03.41 | brlcad | look around some other switch statements that use OP_DB_LEAF to see what they do |
| 16:03.47 | abhi2011 | yes |
| 16:05.58 | abhi2011 | umm but a question, why would the logic work if I get the same region using a match from : for (BU_LIST_FOR(regp, region, &(rtip->HeadRegion))) {... |
| 16:06.07 | abhi2011 | somehow that is not in db format |
| 16:06.50 | abhi2011 | the regions got from the rtip->HeadRegion contains a "all solids loaded" format which works with rt_bound_tree() |
| 16:07.54 | abhi2011 | so something like this works : http://bin.cakephp.org/view/1320641560 |
| 16:08.23 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 16:08.26 | brlcad | not sure, but probably simply because it's just a different container -- gettrees happens to fill out a soltab because it needs it, yet the "other" one you get from lookup has not been loaded |
| 16:09.24 | brlcad | the region search is a bit bogus, though .. not sure what that will do for models that have no regions defined |
| 16:12.50 | abhi2011 | yes they would then have groups |
| 16:13.21 | abhi2011 | but hmm, even for groups I search for regions that the group contains |
| 16:13.36 | abhi2011 | it maybe that the group has just prims |
| 16:41.06 | abhi2011 | hmm most cases using the OP_DB_LEAF simply play around with the prim name in tp->tr_l.tl_name , moving it from x to y :P |
| 16:41.23 | abhi2011 | or they exists at the lowest db_* function level |
| 16:42.22 | abhi2011 | dont see any case of converting a union tree with a OP_DB_LEAF op to a solid with usable geometry |
| 16:45.35 | abhi2011 | I would have though that there would be a function which would accept a union tree with a OP_DB_LEAF in one of its leaves and look it up using the db_lookup() function, then fill it with the corresponding "all solids loaded" representation |
| 16:45.41 | abhi2011 | something like that |
| 16:46.39 | abhi2011 | maybe I can lookup the solid in the rtip using the tp->tr_l.tl_name, in the OP_DB_LEAF case |
| 16:48.29 | brlcad | even if you can, that's pretty much self-defeating |
| 16:48.36 | abhi2011 | yah :P |
| 16:49.12 | brlcad | better question to ask is how the OP_SOLID was created |
| 16:49.48 | abhi2011 | very deep inside rt_gettree() |
| 16:50.41 | abhi2011 | or rather rt_gettrees_muves() |
| 16:55.22 | abhi2011 | hmm db_walk_tree() in the above function preps the leaves |
| 17:02.21 | abhi2011 | struct soltab *_rt_find_identical_solid() seems interesting |
| 17:05.58 | CIA-62 | BRL-CAD: 03starseeker * r46480 10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: Quiet potentially uninitialized warning. |
| 17:54.44 | CIA-62 | BRL-CAD: 03brlcad * r46481 10/brlcad/trunk/src/libbu/ (CMakeLists.txt Makefile.am test_vls.c): |
| 17:54.44 | CIA-62 | BRL-CAD: add a preliminary vls unit test to make sure our printing format specifier |
| 17:54.44 | CIA-62 | BRL-CAD: behavior is consistent with stdio's behavior. particularly for non-standard |
| 17:54.44 | CIA-62 | BRL-CAD: format specifier issues like %z and %ll, make sure something sane is happening. |
| 18:10.58 | CIA-62 | BRL-CAD: 03starseeker * r46482 10/brlcad/trunk/ (CMakeLists.txt src/conv/obj-g_new.c): Ah, right - we include tcl headers, so we define STDC_HEADERS for them. Document that. |
| 18:28.11 | CIA-62 | BRL-CAD: 03brlcad * r46483 10/brlcad/trunk/src/libbu/test_vls.c: expand to include more types, legths, and some precision tests. |
| 18:30.19 | CIA-62 | BRL-CAD: 03brlcad * r46484 10/brlcad/trunk/src/libbu/vls.c: bu_strlcpy() size includes the null character, make sure len is adjusted accordingly |
| 18:44.49 | CIA-62 | BRL-CAD: 03brlcad * r46485 10/brlcad/trunk/src/libbu/str.c: consistency in the >= logic -- looks like it is/was right, but was misleading how it was using the operator |
| 18:48.32 | CIA-62 | BRL-CAD: 03brlcad * r46486 10/brlcad/trunk/src/libbu/vls.c: revert back to strncpy() until we can get a proper debug in. |
| 18:54.42 | CIA-62 | BRL-CAD: 03erikgreenwald * r46487 10/brlcad/trunk/src/libbu/test_vls.c: mark unused variable |
| 18:59.20 | ``Erik | huh, for all asc2g runs: db_dirbuild(/usr/tmp/brlcadbuild/share/brlcad/7.20.3/db/xmp.g): improper database, _GLOBAL object attribute 'units'= is invalid |
| 19:05.19 | brlcad | yeah, that's probably r46486 off-by-one |
| 19:10.10 | CIA-62 | BRL-CAD: 03brlcad * r46488 10/brlcad/trunk/src/libbu/vls.c: len is not -1 |
| 19:15.11 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 19:16.09 | abhi2011 | there is some code supporting the 'E' command which involves case OP_DB_LEAF |
| 19:16.30 | abhi2011 | seems the directory pointer is lookedup using dp=db_lookup() |
| 19:16.43 | abhi2011 | and then a solid is added using eptr = add_solid(dp, tp->tr_l.tl_mat, dgcdp); |
| 19:18.28 | abhi2011 | hmm nope, its seems libged related , struct _ged_client_data has to be passed to add_solid() |
| 19:18.38 | brlcad | ``Erik: does that fix it? |
| 19:23.55 | starseeker | brlcad: fixes it here |
| 19:25.59 | abhi2011 | brlcad: I think the only way to convert the OP_DB_LEAF would be to try and look it up using db_look() |
| 19:26.16 | abhi2011 | prep.c uses that for example |
| 19:27.04 | brlcad | abhi2011: sounds reasonable |
| 19:27.09 | abhi2011 | otherwise the only other way is to pick some code from rt_gettree() which is going to take quite a while |
| 19:27.22 | brlcad | db_lookup() would be needed to get a handle on geometry anyways (at some point) |
| 19:28.16 | CIA-62 | BRL-CAD: 03brlcad * r46489 10/brlcad/trunk/src/libbu/test_vls.c: put ac and av to good use |
| 19:28.49 | abhi2011 | ok |
| 19:29.17 | brlcad | you just shouldn't need an rtip |
| 19:29.24 | brlcad | it's a db operation |
| 19:30.31 | brlcad | (rt_gettree() obviously uses an rtip, but that's because it's specificially "getting geometry trees ready for ray tracing") |
| 19:32.52 | ``Erik | brlcad: yup |
| 19:33.45 | brlcad | cool, thx |
| 19:35.07 | ``Erik | (hopefully their eyes don't bleed too much from my cmake patch) O:-) |
| 19:48.54 | CIA-62 | BRL-CAD: 03brlcad * r46490 10/brlcad/trunk/src/libbu/test_vls.c: test more width, precision, and format specifier flags to make sure vls does what libc does |
| 19:57.00 | starseeker | brlcad: http://www.cmake.org/pipermail/cmake/2011-August/046044.html |
| 20:01.20 | brlcad | "or the stuff from the previous try-compile might affect the next one" <-- shouldn't happen, imho |
| 20:01.58 | brlcad | that sounds like the bug to me or unexpected behavior at best |
| 20:02.46 | brlcad | good to hear there's somewhat of a way to debug, but that's kinda beating around the bush |
| 20:03.56 | starseeker | brlcad: I was going to ask if the behavior could be changed to saving the files of each test in its own subdirectory - did you want to respond yourself? You'll undoubtedly make a more compelling case than I'll be able to |
| 20:08.19 | brlcad | I'd just say what I said here save the bush part, maybe ask why reuse the same directory (particularly given it makes the build tests stateful) .. the tests should be stateless, shouldn't matter if there was already output |
| 20:08.33 | brlcad | (it shouldn't read then write, it should write then read ...) |
| 20:10.07 | brlcad | otherwise, i'm not on that mailing list so I won't be responding anytime soon :) |
| 20:10.25 | CIA-62 | BRL-CAD: 03brlcad * r46491 10/brlcad/trunk/src/libbu/test_vls.c: couple more tests |
| 20:15.03 | starseeker | urk https://sites.google.com/site/x32abi/ |
| 20:15.15 | starseeker | just in case 32/64 bit wasn't complicated enough... |
| 20:29.01 | brlcad | ? |
| 20:29.27 | starseeker | sounded like that might be yet a third option to the 32/64 bit option matrix... |
| 20:29.35 | brlcad | that's just describing the 64bit abi |
| 20:30.34 | brlcad | options on how to run a 32-bit app on 64-bit platform (and do so portably per the abi) |
| 20:31.00 | starseeker | it says it's a "32bit psABI for x86-64 with 32bit pointer size" - does that just mean a 32 bit API for 64 bit hardware? |
| 20:31.08 | starseeker | ah |
| 20:31.18 | starseeker | so no compiler flags needed (hopefully) |
| 20:31.56 | brlcad | that's part of it, an implementation of part of the spec |
| 20:32.48 | brlcad | so you can run a 32-bit app with it's 32-bit pointers and have it play nicely |
| 20:33.08 | brlcad | not something we'll likely have to care about |
| 20:33.15 | starseeker | phew |
| 21:45.36 | CIA-62 | BRL-CAD: 03starseeker * r46492 10/brlcad/trunk/src/other/re2c.dist: add the new re2c file to the ignore list |
| 22:29.20 | CIA-62 | BRL-CAD: 03n_reed * r46493 10/brlcad/trunk/src/other/lemon/CMakeLists.txt: |
| 22:29.20 | CIA-62 | BRL-CAD: Lemon needs the template file in the same directory as the binary. On systems |
| 22:29.20 | CIA-62 | BRL-CAD: using configurations, that means we need to copy this file into the |
| 22:29.20 | CIA-62 | BRL-CAD: configuration binary directory, not just bin. May be more files where this is |
| 22:29.20 | CIA-62 | BRL-CAD: true - TODO. |
| 22:54.49 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 22:54.49 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 23:05.27 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 23:05.27 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 00:20.27 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 00:29.57 | abhi2011 | brlcad: are globals allowed if its not possible to pass a variable to a function |
| 00:30.44 | abhi2011 | I need a dbip in the rt_bound_tree() function but it cant be passed via parameters(assuming the currents parameters are not changed) |
| 00:37.00 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 00:37.17 | abhi2011 | hm ok I ll just add it to the parameter list of rt_bound_tree() |
| 00:37.54 | abhi2011 | oops no cant do that , its used in too many places already |
| 00:59.35 | abhi2011 | global it is then |
| 01:19.37 | CIA-62 | BRL-CAD: 03starseeker * r46494 10/brlcad/trunk/README.cmake: mention ccmake |
| 01:27.59 | CIA-62 | BRL-CAD: 03starseeker * r46495 10/brlcad/trunk/CMakeLists.txt: Explain the DEBUG header definition a little more thoroughly. |
| 01:28.36 | brlcad | abhi2011: no, you cannot add globals to librt |
| 01:28.55 | abhi2011 | yeah I made it an optional paramter |
| 01:29.03 | abhi2011 | rt_bound_tree(struct rt_i * rtip = NULL, const union tree *tp, fastf_t *tree_min, fastf_t *tree_max) |
| 01:29.12 | brlcad | there's no such thing as an optional parameter in C |
| 01:29.16 | brlcad | that's a c++ism |
| 01:29.24 | abhi2011 | ok |
| 01:29.43 | brlcad | what is it that you're trying to do? |
| 01:29.58 | abhi2011 | i am trying to fill out the case OP_DB_LEAF: |
| 01:30.22 | abhi2011 | so I am trying to lookup the encountered solid using stp = rt_find_solid(rtip, tp->tr_l.tl_name); |
| 01:30.36 | abhi2011 | in that case |
| 01:31.17 | abhi2011 | I havent come across any other way to convert the information present in a OP_DB_LEAF node to a OP_SOLID |
| 01:32.00 | abhi2011 | in fact the only single information present is the prim name :P, which is really very less info to proceed on :P |
| 01:32.20 | abhi2011 | other than doing a lookup of some sort |
| 01:33.33 | brlcad | what does that have to do with rt_bound_tree() though? |
| 01:33.57 | brlcad | i mean the rtip |
| 01:34.11 | brlcad | so you can call rt_find_solid within rt_bound_tree()? |
| 01:34.16 | abhi2011 | yes |
| 01:35.17 | abhi2011 | like this : http://bin.cakephp.org/view/820530027 |
| 01:36.48 | abhi2011 | the return internal from rt_db_lookup_internal() has really mucked things up |
| 01:36.52 | brlcad | so you can add a new parameter, but it'd need to be a different function (i.e., you'd need to copy most of rt_bound_tree()) because it breaks the API |
| 01:37.02 | abhi2011 | yes |
| 01:37.03 | abhi2011 | ok |
| 01:37.29 | brlcad | so back to the original idea |
| 01:37.50 | brlcad | just add your own new function that converts the tp |
| 01:37.57 | brlcad | before it gets to rt_bound_tree() |
| 01:38.26 | brlcad | basically a switch for just that case statement in a new function, called before rt_bound_tree() |
| 01:38.36 | brlcad | that way you can pass an rtip or whatever else you may need |
| 01:38.44 | abhi2011 | ok , this function will also recursively desend the tree |
| 01:38.49 | abhi2011 | calling rt_gettree() |
| 01:38.55 | abhi2011 | on any regions it encounters |
| 01:39.00 | brlcad | that's fine -- maybe all the more reason to keep it separate |
| 01:39.08 | abhi2011 | ok |
| 01:39.13 | abhi2011 | that make sense |
| 01:40.19 | abhi2011 | seems the delay in all this function will be much more than the way get_obj_bounds() does it |
| 01:40.52 | abhi2011 | but ok, all this occurs before the simulation, so it should be ok |
| 01:41.21 | brlcad | they're also not expensive operations |
| 01:41.34 | abhi2011 | yes |
| 01:41.47 | brlcad | you could probably convert a tp a hundred times over and still achieve 100fps updates |
| 01:42.00 | abhi2011 | ok |
| 01:42.58 | abhi2011 | yeah makes more sense to traverse recursively anyway, since it *is* a tree,no logical errors that way due to a model having no groups, or no regions etc etc |
| 02:15.00 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 04:35.04 | CIA-62 | BRL-CAD: 03starseeker * r46496 10/brlcad/trunk/ (101 files in 13 dirs): (log message trimmed) |
| 04:35.04 | CIA-62 | BRL-CAD: Took a stab at using http://www.projectpluto.com/win32a.htm (WIN32 native |
| 04:35.04 | CIA-62 | BRL-CAD: curses) to get the terminal code working on Windows, but so far falling way |
| 04:35.04 | CIA-62 | BRL-CAD: short of success. The termio_win32.c file doesn't seem to have much in the way |
| 04:35.04 | CIA-62 | BRL-CAD: of contents, and termio.c doesn't want to build on windows (among other errors, |
| 04:35.05 | CIA-62 | BRL-CAD: getting illegal indirection errors associated with copyTio). Even when using |
| 04:35.06 | CIA-62 | BRL-CAD: termio_win32.c, MSVC doesn't want to generate a .lib file. The pdcurses demo |
| 04:37.37 | brlcad | neat |
| 04:38.00 | starseeker | not really - so far it's slapping me around for daring to think I could compile it :-/ |
| 04:38.28 | brlcad | fwiw, plain ol pdcurses should be more than adequate for our needs |
| 04:39.12 | starseeker | nods - the win32a variation has been actively maintained very recently, and is trying to be merged into the "mainline" |
| 04:39.14 | brlcad | we don't actually use curses, so everything win32a implements/extends won't actually get invoked |
| 04:39.20 | brlcad | I noticed |
| 04:39.25 | brlcad | looks good, if it works great |
| 04:39.33 | brlcad | if not, might try the fallback |
| 04:39.39 | brlcad | pdcurses is dead simple to compile |
| 04:39.57 | starseeker | pdcurses isn't the issue - it's getting our code to use it (so far) |
| 04:40.21 | brlcad | shouldn't even really need to modify our code |
| 04:40.24 | brlcad | just link the lib |
| 04:40.39 | starseeker | shakes his head - doesn't look like it |
| 04:40.50 | starseeker | if that were the case, the above would have worked a while ago |
| 04:41.09 | brlcad | that presumes there's not bugs in win32a |
| 04:41.10 | starseeker | libcursor needed BC and UC, which aren't provided by pdcurses |
| 04:41.20 | starseeker | nods - fair enough |
| 04:41.39 | starseeker | and libtermio is a lot more annoying |
| 04:42.09 | starseeker | some of the compile errors for termio.c didn't appear related to termlib at all |
| 04:42.36 | starseeker | would appreciate a second pair of eyeballs - I'm in a bit over my head |
| 04:42.49 | brlcad | there's a lot of platform logic in there, it might need some minor mods |
| 04:43.12 | starseeker | I was planning to reverse-merge 46496 to leave the build in a working state, but if you want to take a wack at it I can leave it for now |
| 04:43.23 | brlcad | BC and UC aren't important, if it has tgetstr() then we're good |
| 04:43.33 | brlcad | tgetstr("bc", ...) |
| 04:43.56 | starseeker | seems to be in there |
| 04:44.41 | starseeker | hrm, actually... |
| 04:45.28 | brlcad | also, presume you meant UP, not UC .. |
| 04:45.41 | brlcad | libtermlib defines those two globals |
| 04:45.49 | starseeker | er, yeah |
| 04:45.57 | brlcad | but they're not really needed |
| 04:46.25 | brlcad | so that'd be a two-line mod if pdcurses left them out for some reason (unlikely) |
| 04:46.58 | brlcad | I don't have a windows environment set up at the moment to test it |
| 04:47.27 | starseeker | brlcad: you can bump nick off my box temporarily tomorrow ;-) |
| 04:47.51 | starseeker | is not reassured by this: (main pdcurses sources, not just win32a) http://pdcurses.cvs.sourceforge.net/viewvc/pdcurses/PDCurses/pdcurses/terminfo.c?revision=1.37&view=markup |
| 04:48.00 | brlcad | I'm backlogged with NURBS and GS work, it'll have to wait a bit |
| 04:48.19 | brlcad | that's a good friday or weekend project |
| 04:48.24 | starseeker | nods |
| 04:48.34 | starseeker | k - I'll revert it for now then, so the build still works for nick |
| 04:49.05 | brlcad | why is that not reassuring? what's it's supposed to reassure? |
| 04:49.10 | starseeker | shouldn't have tangled with it either, just an impulse |
| 04:50.13 | CIA-62 | BRL-CAD: 03starseeker * r46497 10/brlcad/trunk/ (11 files in 10 dirs): Revert 46496 until more work can be done on it - leave trunk in a working state. Main point was to checkpoint, and revision history now has work done so far. |
| 04:50.43 | starseeker | tgetstr is a stub |
| 04:50.50 | starseeker | doubts we want a stub |
| 04:52.06 | starseeker | i.e. not a good sign |
| 04:54.38 | starseeker | makes a note at some point to try the ersatz editor against pdcurses - that would be nifty it if ended up working |
| 04:55.05 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 04:55.18 | starseeker | splits before he gets in any worse trouble ;-) |
| 04:55.43 | brlcad | heh |
| 05:03.48 | starseeker | erk: pdcurses term.h: PDCurses doesn't operate with terminfo, but we need these functions for compatibility, to allow some things (notably, interface libraries for other languages) to be compiled. Anyone who tries to actually _use_ them will be disappointed, since they only return ERR. |
| 05:04.14 | starseeker | really splits this time |
| 05:27.27 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 06:18.45 | starseeker | makes a note of this article for possible future reference: http://www.halcyon.com/~ast/dload/guicon.htm |
| 06:46.26 | starseeker | this might be a useful guide for making an editor that doesn't use terminfo: http://sandyeditor.sourceforge.net/ |
| 06:56.49 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 07:03.05 | starseeker | winces http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/win-command-prompt.html |
| 07:03.33 | starseeker | too bad he didn't succeed, that sounds quite interesting |
| 07:16.56 | starseeker | humph - ersatz against pdcurses is a no-go |
| 07:19.07 | starseeker | heavy terminfo use |
| 07:45.29 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 14:01.38 | starseeker | if I thought I could get away with it I'd CMakeify vim for cross-platform building and use that (maybe with vimacs mode...) |
| 14:11.01 | ``Erik | nvi might be easier |
| 14:20.20 | starseeker | looks like it needs terminfo of some sort too |
| 16:04.20 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 16:08.10 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 17:10.33 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-185-119.wlan.tudelft.nl) | |
| 17:46.38 | CIA-62 | BRL-CAD: 03n_reed * r46498 10/brlcad/trunk/src/ (3 files in 2 dirs): Group names were being stored in volatile memory, causing garbage output. Now copying strings to memory we actually own. |
| 18:16.12 | CIA-62 | BRL-CAD: 03n_reed * r46499 10/brlcad/trunk/src/conv/obj-g_new.c: Addressed compiler warnings. |
| 18:44.56 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 18:47.41 | CIA-62 | BRL-CAD: 03starseeker * r46500 10/brlcad/trunk/src/tclscripts/mged/ (CMakeLists.txt exists.tcl tclIndex): add exists command to check whether a db object exists - maybe should be a libged cmd... |
| 18:49.02 | CIA-62 | BRL-CAD: 03starseeker * r46501 10/brlcad/trunk/src/tclscripts/mged/ (CMakeLists.txt exists.tcl tclIndex): Nevermind, Bob is doing a libged version |
| 19:06.37 | CIA-62 | BRL-CAD: 03starseeker * r46502 10/brlcad/trunk/misc/CMake/FindLEMON.cmake: cmake -E rename isn't and won't be functional across multiple volumes - use cp or copy if we can find them, and rename as a last resort if we can't |
| 19:19.22 | CIA-62 | BRL-CAD: 03bob1961 * r46503 10/brlcad/trunk/src/tclscripts/archer/ (CMakeLists.txt PipeEditFrame.tcl): Added the initial code for editing pipes in Archer. More to come. |
| 19:20.42 | CIA-62 | BRL-CAD: 03bob1961 * r46504 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added the initial code for editing pipes in Archer. More to come. |
| 19:23.52 | CIA-62 | BRL-CAD: 03starseeker * r46505 10/brlcad/trunk/misc/CMake/FindLEMON.cmake: Er whoops, need mv/move, not cp/copy. builds once more |
| 19:23.57 | CIA-62 | BRL-CAD: 03bob1961 * r46506 10/brlcad/trunk/src/tclscripts/archer/ (21 files): Calling GeometryEditFrame::updateGeometry. |
| 19:31.06 | CIA-62 | BRL-CAD: 03bob1961 * r46507 10/brlcad/trunk/ (6 files in 5 dirs): Added ged_exists() in libged to check for the existence of a database object and make it available in mged and archer. |
| 19:45.11 | CIA-62 | BRL-CAD: 03n_reed * r46508 10/brlcad/trunk/src/conv/obj-g_new.c: Freeing all group strings and containing array; should be leak-free again. |
| 19:52.37 | *** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 20:04.11 | ``Erik | starseeker: "catch [get $name]" isn't good enough? O.o |
| 20:08.20 | CIA-62 | BRL-CAD: 03starseeker * r46509 10/brlcad/trunk/CMakeLists.txt: X11 is an advanced option under Windows, mark it as such. |
| 20:11.33 | starseeker | nope |
| 20:38.53 | CIA-62 | BRL-CAD: 03starseeker * r46510 10/brlcad/trunk/ (4 files in 3 dirs): Start working on how to test for hypot on Windows - most of the warning messages we're getting in MSVC seem to relate to redefining that function in config_win (I think)... |
| 20:40.55 | CIA-62 | BRL-CAD: 03starseeker * r46511 10/brlcad/trunk/ (CMakeLists.txt include/config_win_cmake.h.in): give this a hypot test a shot... don't know if it will work, untested |
| 20:43.35 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 20:50.13 | CIA-62 | BRL-CAD: 03starseeker * r46512 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/test_srcs/hypot_test.c): try required libs and check_function_exists |
| 20:54.50 | *** join/#brlcad juanman (~quassel@186.136.168.73) | |
| 20:54.52 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 21:12.17 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 21:30.33 | CIA-62 | BRL-CAD: 03starseeker * r46513 10/brlcad/trunk/ (3 files in 2 dirs): utter failure - cannot confirm hypot is present as a function, always get unresolved errors even when I manually feed it msvcrt. revert for now |
| 21:42.39 | CIA-62 | BRL-CAD: 03bob1961 * r46514 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Add "exists" to the help object. |
| 21:44.07 | CIA-62 | BRL-CAD: 03bob1961 * r46515 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Using the exists command in a few places. It's cleaner. |
| 21:55.54 | CIA-62 | BRL-CAD: 03starseeker * r46516 10/brlcad/trunk/ (3 files in 2 dirs): Try again - take a hit from kicad and use check_symbol_exists this time, let's see how that does |
| 22:10.13 | *** join/#brlcad Yoshi477 (~jan@bas1-guelph22-1177695115.dsl.bell.ca) | |
| 22:20.48 | starseeker | yes, much better |
| 22:49.28 | *** join/#brlcad Yoshi477 (~jan@bas1-guelph22-1177620315.dsl.bell.ca) | |
| 22:54.47 | *** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 23:19.34 | CIA-62 | BRL-CAD: 03n_reed * r46517 10/brlcad/trunk/src/ (conv/obj-g_new.c libgcv/wfobj/obj_parser_state.h): Properly allocating and freeing the rest of the file strings. |
| 23:19.42 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 00:13.02 | *** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 00:33.34 | CIA-62 | BRL-CAD: 03abhi2011 * r46518 10/brlcad/trunk/src/librt/bbox.c: Modified the BB function to get the BB for groups, combs and prims through tree traversal |
| 00:39.47 | *** join/#brlcad juanman (~quassel@201.255.13.201) | |
| 00:39.51 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 00:55.00 | CIA-62 | BRL-CAD: 03starseeker * r46519 10/brlcad/trunk/include/raytrace.h: fix the rt_bound_internal header definition |
| 01:18.01 | CIA-62 | BRL-CAD: 03starseeker * r46520 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: There's a TODO item to check for the -mss3 compiler flag - this does so and adds it, but raises the qeustion about the original concerns documented for sse flags |
| 02:18.57 | *** join/#brlcad DarkCalff (DC@173.231.40.98) | |
| 02:28.19 | CIA-62 | BRL-CAD: 03brlcad * r46521 10/brlcad/trunk/src/conv/obj-g_new.c: don't peek into the struct, bu_vls_addr() was correct. vls_str is just the internal memory buffer allocated which may be offset and truncated. |
| 02:33.04 | CIA-62 | BRL-CAD: 03brlcad * r46522 10/brlcad/trunk/src/conv/obj-g_new.c: ws consistency, indent, trailing ws |
| 02:41.30 | CIA-62 | BRL-CAD: 03brlcad * r46523 10/brlcad/trunk/src/libgcv/wfobj/obj_parser_state.h: simplify, there's a libbu bu_strdup() function for copying strings (and if there wasn't, there's a libc function for that too, strdup()). |
| 02:50.38 | CIA-62 | BRL-CAD: 03n_reed * r46524 10/brlcad/trunk/src/ (conv/obj-g_new.c libgcv/wfobj/obj_parser.cpp): Don't have to copy vector elements to array since C++ promises they are contiguous. |
| 02:59.46 | CIA-62 | BRL-CAD: 03brlcad * r46525 10/brlcad/trunk/src/libgcv/wfobj/obj_parser.cpp: should be using c++ or (better) libbu memory management so error behavior is consistent during out-of-memory conditions. signatures don't match, though, so not a drop-in replacement as a registered callback function. |
| 03:04.29 | brlcad | starseeker: if you're testing for hypot, you could just add it to brlcad_config.h instead of config_win.h .. the latter should nearly go away entirely with cmake |
| 03:04.59 | brlcad | we couldn't test for them with autotools, so here's a place where cmake can outshine if it's cleaned up |
| 03:05.42 | brlcad | everything it was just setting should be a functionality test (that either is tested every time or at least run if msvc) |
| 03:17.08 | *** join/#brlcad n_reed (44378e88@gateway/web/freenode/ip.68.55.142.136) | |
| 03:18.18 | starseeker | brlcad: it's a little different... I need to define hypot to _hypot if hypot isn't a symbol... I don't actually know how hypot and math.h are set up elsewhere... hmm... |
| 03:19.12 | starseeker | again rams his head into the hard reality that There Is No Good non-GPL Open Source Terminal Emulation For Windows |
| 03:21.24 | starseeker | brlcad: is libtermlib in src/other portable to Windows? |
| 03:29.35 | starseeker | yeah, the test needed for windows will fail when it shouldn't on Linux |
| 03:30.35 | starseeker | and check_function_exists refused to work on windows |
| 03:33.18 | starseeker | however, even in the worst case I can certainly do the MSVC tests and add them to brlcad_config.h instead of config_win |
| 03:33.56 | starseeker | have to be careful about maintaining the order in which they appear in the header though |
| 03:35.07 | starseeker | safe way to go would be to make some MSVC_TEST macros that would generate a config_win the way brlcad_config is being generated now |
| 03:35.40 | starseeker | would eliminate the hardcoded file, but still maintain the position of config_win relative to brlcad_config in the include order |
| 03:38.37 | starseeker | hmm - have we ever looked at this? http://en.wikipedia.org/wiki/Tera_Term |
| 03:40.17 | starseeker | might just be another putty... |
| 03:42.12 | n_reed | I think I've heard it mentioned in the same sentence as putty before |
| 03:46.56 | CIA-62 | BRL-CAD: 03n_reed * r46526 10/brlcad/trunk/src/libgcv/wfobj/obj_parser_state.h: Changed remaining instances of local string copy to bu_strdup. This memory is freed in obj-g_new.c. |
| 03:49.46 | starseeker | yeah, same as putty - if they go local they use the cygwin term stuff |
| 03:49.58 | starseeker | cygwin seems to be the only game in town |
| 03:58.44 | CIA-62 | BRL-CAD: 03brlcad * r46527 10/brlcad/trunk/src/conv/obj-g_new.c: bu_free_array() does the same as free_lib_array() plus a sanity null |
| 04:00.22 | n_reed | clearly there is a bu routine for everything |
| 04:02.18 | CIA-62 | BRL-CAD: 03brlcad * r46528 10/brlcad/trunk/src/conv/obj-g_new.c: reorder to avoid forward decl |
| 04:05.04 | brlcad | starseeker: they're all just symbols that exist or don't exist, how's that different? |
| 04:05.53 | brlcad | thinks you're making it more complicated than it needs to be |
| 04:06.21 | starseeker | a quick test I just did indicates neither hypot nor _hypot exist as symbols directly on linux |
| 04:07.12 | brlcad | I don't believe that |
| 04:07.24 | brlcad | more than likely, the test was flawed |
| 04:07.39 | starseeker | me either, but the tests did not succeed (either CHECK_SYMBOL_EXISTS or CHECK_FUNCTION_EXISTS) |
| 04:07.50 | brlcad | and why did they fail exactly? |
| 04:08.10 | brlcad | more exactly, if you wrote a little main with hypot, does it work? |
| 04:08.37 | brlcad | taking cmake out of the picture first will tell you if it's a test setup problem |
| 04:09.06 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 04:09.45 | ``Erik | um, with ffast-math, several math 'functions' become "magic" keywords to gcc |
| 04:09.52 | brlcad | from a pure feature test perspective, the way to platform-agnostically "do it right" would be to test for hypot, if not found then test for _hypot, if not found then error else #define _hypot hypot |
| 04:10.29 | brlcad | last time I tested it, ffast-math won't pass benchmark validation |
| 04:10.54 | ``Erik | compile/link with the same flags should find 'em (as a "run" test), but a pure compile/link test might show weirdness in some circumstances |
| 04:12.01 | brlcad | even with ffast-math, you can still capture a pointer to the function and it should compile/link |
| 04:12.03 | ``Erik | I think fabs is in the same bucket |
| 04:12.15 | ``Erik | (haven't read backlog, just got home) |
| 04:14.41 | ``Erik | (or mebbe it was an -O level that changed 'em from libray funcs to intrinsics, hrm) |
| 04:18.21 | starseeker | either way, the simple test is not working, which means it's not just a snap of the fingers to do this |
| 04:19.07 | starseeker | the hypot case was important because it's extremely noisy in VS10, but otherwise it's not terribly urgent |
| 04:20.58 | starseeker | oh, that remeinds me |
| 04:21.02 | starseeker | brlcad: http://www.cmake.org/pipermail/cmake/2011-August/046059.html |
| 04:22.15 | starseeker | writing a main with hypot does not work in isolation, I have to include math.h |
| 04:22.37 | brlcad | I still don't buy his reasonsing -- of course it'd leave a lot of dirs if there were a lot of tests |
| 04:22.39 | starseeker | but math.h does not directly define hypot the way it does in MSVC - tis somewhere further down the include list |
| 04:22.51 | brlcad | but then the user asked for all of those tests to get left around |
| 04:23.01 | starseeker | brlcad: oh, I agree - my initial response was "yeah, it's a lot of dirs... so?" |
| 04:23.39 | brlcad | starseeker: I expect hypot() to fail on windows |
| 04:23.46 | brlcad | it's a c99 function, msvc is not c99 compliant |
| 04:23.57 | starseeker | it did, until VS10 |
| 04:24.21 | brlcad | it has/had _hypot() |
| 04:24.34 | starseeker | essentially, VS10 does the #define hypot _hypot in math.h for us |
| 04:25.38 | brlcad | so then back to the original assertion that it should be sufficient to test for hypot, if not found then test for _hypot, if not found then error else #define |
| 04:26.03 | starseeker | right - but the test for hypot that succeeds on Windows fails on Linux |
| 04:26.04 | brlcad | if that means a simple custom test, that's still a very simple test |
| 04:26.24 | brlcad | so why does linux fail? |
| 04:27.04 | brlcad | #include "math.h" ; int main(int ac, char *av[]) { return (int)hypot(1.0, 2.0); } fails? |
| 04:27.12 | brlcad | you probably need -lm |
| 04:28.29 | brlcad | or LIBM or whatever you tested earlier |
| 04:29.17 | starseeker | yeah, looks like it |
| 04:29.45 | starseeker | I can write a macro to do that, I guess |
| 04:30.43 | brlcad | doesn't cmake already do that? |
| 04:30.54 | brlcad | how are functions tested if you can't specify link libraries? |
| 04:31.10 | starseeker | there's a global variable you temporarily populate |
| 04:31.45 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 04:32.27 | brlcad | sounds akin to how you do it in autotools for custom tests, but standard func tests had that already built into the macro (because it's pretty much necessary) |
| 04:33.58 | starseeker | some of the macros have the extra options to let you pass stuff - check_symbol_exists doesn't happen to be one of them, so a BRLCAD_CHECK_SYMBOL_EXISTS wrapper is in order |
| 04:35.09 | starseeker | can also add an option for a "fallback" symbol that is used for a define (e.g. BRLCAD_CHECK_SYMBOL_EXISTS(hypot "math.h" HAVE_HYPOT _hypot) or some such |
| 04:35.41 | starseeker | er BRLCAD_CHECK_SYMBOL_EXISTS(hypot "math.h" "${M_LIBRARY}" _hypot) rather |
| 04:35.53 | brlcad | check_library_exists didn't do it? |
| 04:37.10 | brlcad | I wouldn't recommend having a fallback -- even on windows, some of them have _funcs and some don't (and it has changed over the years across versions of msvc) |
| 04:37.13 | starseeker | hmm... that might have worked - wasn't my first thought, as I wasn't looking to confirm that the library exists but detect a symbol within it |
| 04:37.32 | brlcad | really are two separate tests, might as well be named "foo" and "bar" |
| 04:37.57 | brlcad | check_library_exists tests whether a function is in the specified library |
| 04:38.04 | starseeker | shakes his head - in this case, testing for _hypot and doing the #define hypot _hypot is conditional on the outcome of the first test |
| 04:38.58 | brlcad | them being conditional doesn't mean they're not separate tests, it's what you do with the results that is conditional |
| 04:39.21 | *** part/#brlcad n_reed (44378e88@gateway/web/freenode/ip.68.55.142.136) | |
| 04:39.40 | starseeker | testing for _hypot is a total waste of time if we have hypot though |
| 04:40.02 | brlcad | of course, you test for hypot first |
| 04:40.11 | brlcad | it's just nested testing |
| 04:40.33 | brlcad | if test funcA fails, test funcB; if test funcB succeeds, "do something useful" .. which in this case is #define funcA funcB |
| 04:40.35 | starseeker | oh, I know why check_library_exists wasn't the right approach - with MSVC, there IS no math library |
| 04:40.38 | starseeker | M_LIBRARY is empty |
| 04:40.50 | brlcad | not true |
| 04:41.05 | starseeker | our M_LIBRARY variable is empty |
| 04:41.06 | brlcad | there IS a math library .. it's just not self-contained |
| 04:41.13 | brlcad | sure |
| 04:41.18 | starseeker | that's what matters |
| 04:41.21 | brlcad | there is not "m.dll :) |
| 04:41.27 | starseeker | right |
| 04:41.55 | brlcad | so you're not testing all the possible libraries that might have that symbol |
| 04:42.20 | starseeker | on Windows it's not necessary - we don't have to specifically link a math library |
| 04:42.50 | brlcad | irrelevant from a configuration perspective |
| 04:43.28 | *** join/#brlcad BenDansie (~chatzilla@182-239-205-11.ip.adam.com.au) | |
| 04:44.14 | brlcad | I'm not disagreeing, this is all old old news to me :) .. it's how to think about solving the problem in generic non-platform specific terms |
| 04:44.28 | BenDansie | Hi all |
| 04:44.44 | brlcad | this isn't really specific to windows, there are other symbols that behave exactly like this for other platforms/environments |
| 04:44.48 | brlcad | BenDansie: hello |
| 04:44.57 | starseeker | brlcad: sure, but there are practical aspects to this - our Windows config is already a factor of 10 longer than any other platform |
| 04:45.12 | starseeker | all of these new tests we're talking about here will make that worse |
| 04:45.24 | brlcad | our source code is probably a factor 10 larger than other software too, not sure that matters |
| 04:46.04 | starseeker | I mean it takes forever to run a CMake config on Windows - from a development cycle standpoint, lengthening it further sucks |
| 04:46.26 | brlcad | like the earlier discussion -- IFF after all the tests are added it really drags things down, then the tests could all get wrapped in *just one* big if-MSVC-then-do-these-tests conditional |
| 04:46.28 | starseeker | I'm not denying it may be worth it from a "cross platform cleanliness" standpoint, but it will have an impact |
| 04:47.14 | BenDansie | Hope I'm not interrupting, but could someone lend me a hand with how to import an iges file and export to something else like stl or obj? I'm new to BRL-CAD. Would be greatly appreciated |
| 04:47.58 | brlcad | adding 10 min to the windows build at arl is frankly inconsequential, that's a limitation of that environment and specific to that platform |
| 04:48.01 | brlcad | the build already takes a couple hours, barely a blip |
| 04:48.15 | brlcad | BenDansie: it depends what kind of iges file you have |
| 04:48.30 | brlcad | it'll either work or crash and burn |
| 04:49.26 | brlcad | the iges importer hasn't been updated in quite a while so there are several "gotchyas" possible, some out of our control, some specific to iges versioning, some specific to what software exported the iges file |
| 04:49.41 | BenDansie | Right. The deal is I work for a multimedia company, and we've been supplied the .igs file straight from the cad designers. So we are figuring it out as we go to convert the file into something we can use. |
| 04:50.06 | BenDansie | So assuming it works, what is the process? Trying to read through the documentation on the website |
| 04:50.18 | brlcad | what software are you trying to use the geometry in? |
| 04:50.38 | brlcad | iges-g has pretty extensive usage |
| 04:51.16 | brlcad | iges-g -d -o file.g file.igs |
| 04:51.21 | brlcad | or -3 instead of -d |
| 04:51.47 | brlcad | or maybe -p in addition to -d |
| 04:51.53 | starseeker | if it brings in spline/NURBS surfaces, that's not going to export to an stl file at the moment |
| 04:51.54 | BenDansie | 3ds Max, which has an importer, but it fails on the larger of the two files we need. |
| 04:51.55 | brlcad | it totally depends what's in the .igs file |
| 04:51.57 | BenDansie | thanks |
| 04:52.28 | brlcad | that doesn't bode well if 3dsmax fails :) |
| 04:52.57 | BenDansie | ah. Rhino also fails, but due to memory. Rhino still being 32 bit |
| 04:53.06 | brlcad | I can take a quick look at trying the conversion myself if you care to share the datafile |
| 04:53.08 | starseeker | BenDansie: can you have them send you several smaller .igs files with pieces? |
| 04:53.36 | brlcad | could be a simple matter of blowing out 32-bit memory, in which case you may need a 64-bit compile of BRL-CAD too |
| 04:53.45 | brlcad | though I suspect our iges importer is leaner than 3ds |
| 04:54.35 | brlcad | notes that exists is a nice parallel to "test" |
| 04:54.52 | brlcad | should use a similar syntax |
| 04:55.30 | brlcad | starseeker: that's up there with 'search' ;) |
| 04:55.37 | brlcad | a lot simpler to implement though |
| 04:55.56 | starseeker | erm... test being the unix command line program test? |
| 04:56.11 | BenDansie | Well, step one is to go back and grab the 64 bit version it seems... :) |
| 04:56.42 | starseeker | reads the man page... |
| 04:58.10 | starseeker | irk. there are a few dragons here. what does it mean for an object to be greater than or less than another object? we don't support modification date for objects (at the moment, anyway)... |
| 04:59.07 | starseeker | the -d, -f, etc options would probably translate into something like test -g sph obj1.s, test -g eto obj1.s, etc... |
| 05:00.42 | starseeker | could really go hog wild and do test -O obj1.s obj2.s for overlap testing :-P |
| 05:01.34 | starseeker | or I guess test obj1.s -O obj2.s would be more in keeping with the STRING1 = STRING2 theme |
| 05:02.11 | starseeker | would have to be dbtest though - looks like test does something in tcl |
| 05:04.06 | brlcad | starseeker: right, so the date-baesd tests cannot be implemented today (but will be with rel8) |
| 05:04.32 | brlcad | the other >, < tests are lexicographical, though, are trivial to implemnet |
| 05:04.50 | starseeker | sure, if we go with string comparisons of the names |
| 05:05.01 | brlcad | and EXACTLY regarding specialty options like overlap testing |
| 05:05.06 | starseeker | rather liked the idea of bounding box volumes... |
| 05:05.10 | brlcad | that'd be the bomb |
| 05:05.34 | brlcad | "test" does existance, date, lexi, and more |
| 05:06.11 | brlcad | exists even works as an alternate name like search:find |
| 05:06.33 | BenDansie | "file is not in iges ascii format" - am I out of luck on this one? |
| 05:06.41 | brlcad | does foo exist lexicographically before bar? well: exists foo < bar |
| 05:07.07 | brlcad | BenDansie: no, there are binary and ascii versions of iges files |
| 05:07.45 | brlcad | er, scratch that |
| 05:07.50 | brlcad | thinking of a different format |
| 05:08.19 | starseeker | considers exists vs. dbtest... hmm. exists might be a little too specific for something so general |
| 05:08.55 | starseeker | exists "works" lexicographically perhaps, but I wouldn't have thought of it out of context |
| 05:09.15 | brlcad | BenDansie: do you know if your file is binary or ascii? |
| 05:09.44 | starseeker | or we could make a ged tcl namespace and stuff all of our commands in there, then default to that namespace in mged |
| 05:10.16 | starseeker | require explicit tcl namespace calls or a "set namespace tcl" option or some such |
| 05:10.33 | starseeker | then search really could be find and test could be test :-) |
| 05:11.41 | BenDansie | ahah! making progress now. Seems the first time I tried I did the export filenames the wrong way around and wrote over the .igs |
| 05:11.48 | brlcad | if you read the manpage for test, most of the tests are "does this exist" |
| 05:11.51 | BenDansie | copied the original again and got further |
| 05:12.01 | brlcad | that's what makes "exists" a particularly good fit |
| 05:12.53 | brlcad | BenDansie: aha, that'll do it ;) |
| 05:13.16 | starseeker | checks out the bsd test codebases... yay, another deliverable nobody asked for :-P |
| 05:13.35 | brlcad | I wouldn't even use bsd as a starting point |
| 05:13.52 | brlcad | the tests are simple to write |
| 05:14.38 | starseeker | was thinking the multiple expression evaluation logic |
| 05:14.45 | brlcad | ah, perhaps |
| 05:14.57 | BenDansie | Converting solid entities: |
| 05:14.58 | brlcad | that is pretty powerful stuff |
| 05:14.59 | BenDansie | No parameter curve for eu x5a97f20 |
| 05:15.00 | BenDansie | ivert=x67c9b20, jvert=x67ca0c0, eu->vu_p->v_p=x67ca0c0, eu->eumate_p->vu_p->v_p= |
| 05:15.00 | starseeker | EXPRESSION1 -a EXPRESSION2 etc. |
| 05:15.02 | BenDansie | x67ca0a0 |
| 05:15.03 | BenDansie | Add_nurb_loop_to_face: Edgeuse/vertex mixup! |
| 05:15.18 | brlcad | BenDansie: don't use -n |
| 05:15.20 | starseeker | sounds like it's importing NURBS |
| 05:16.09 | brlcad | nor -t |
| 05:16.49 | brlcad | if you run without any options, it should give an analysis of what is in the file |
| 05:16.55 | brlcad | iges-g -o file.g file.igs |
| 05:17.05 | brlcad | probably saying, "try adding -3" |
| 05:17.43 | brlcad | default may even work if you're REALLY really REALLY lucky |
| 05:22.31 | starseeker | sweet - public domain even: http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/bin/test/test.c |
| 05:23.35 | starseeker | will vacuum out the file specific stuff tomorrow and see about converting that into exists |
| 05:26.23 | CIA-62 | BRL-CAD: 03brlcad * r46529 10/brlcad/trunk/TODO: the new 'exists' command is a beautiful corollary to the unix 'test' command.. embrace the familiar usage (make it the same where possible) and extend with geometry-specific features. |
| 05:27.12 | brlcad | I love how core unix commands are so short and sweet, easy to understand and modify |
| 05:27.35 | brlcad | great examples of how less is more |
| 07:48.36 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 09:42.49 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 09:42.50 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 09:43.47 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 10:13.56 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) | |
| 10:46.37 | CIA-62 | BRL-CAD: 03Ontwe 07http://brlcad.org * r3087 10/wiki/Wiki_Support_for_unexperienced_users: New page: New Users often need help about [http://www.mediawiki.com Mediawiki] |
| 11:03.37 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 12:31.49 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 12:32.45 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 12:42.44 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 13:07.11 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:15.45 | CIA-62 | BRL-CAD: 03erikgreenwald * r46530 10/brlcad/trunk/src/conv/obj-g_new.c: cast const char** to char ** to match type. Add missing third parameter to bu_free_array. |
| 13:40.58 | CIA-62 | BRL-CAD: 03erikgreenwald * r46531 10/brlcad/trunk/src/libgcv/bottess.c: Convert big scary macros to functions. Change explicit static to HIDDEN. Add more optional output. |
| 13:49.59 | CIA-62 | BRL-CAD: 03erikgreenwald * r46532 10/brlcad/trunk/src/libgcv/bottess.c: remove inline keyword |
| 14:08.18 | CIA-62 | BRL-CAD: 03n_reed * r46533 10/brlcad/trunk/src/conv/obj-g_new.c: Should be passing char**, not char***, to bu_free_array. |
| 14:15.07 | abhi2011 | anyone else getting an error during install like : CMake Error at include/cmake_install.cmake:36 (FILE): file INSTALL cannot find "/home/abhi/socis/brlcad/include/config_win_cmake.h". |
| 14:34.37 | CIA-62 | BRL-CAD: 03erikgreenwald * r46534 10/brlcad/trunk/TODO: add marching cubes to libged facetize |
| 14:38.51 | brlcad | gah, we really need to get continuous integration going .. |
| 14:38.56 | brlcad | too many commit/compile failures |
| 14:39.48 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Wiki Support for unexperienced users]]": content was: 'New Users often need help about [http://www.mediawiki.com Mediawiki]' (and the only contributor was '[[Special:Contributions/Ontwe|Ontwe]]') |
| 14:41.25 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Ontwe]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 14:51.39 | CIA-62 | BRL-CAD: 0391.124.110.50 07http://brlcad.org * r3088 10/wiki/Google_Summer_of_Code: |
| 14:53.11 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:00.11 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3089 10/wiki/Google_Summer_of_Code: Reverted edits by [[Special:Contributions/91.124.110.50|91.124.110.50]] ([[User talk:91.124.110.50|Talk]]); changed back to last version by [[User:Sean|Sean]] |
| 15:30.15 | starseeker | abhi2011: ah, sorry - that's me |
| 15:30.25 | starseeker | abhi2011: one second... |
| 15:32.52 | CIA-62 | BRL-CAD: 03starseeker * r46535 10/brlcad/trunk/include/CMakeLists.txt: Ooops, right - config_win_cmake is now a configure_file, treat it accordingly. |
| 15:34.38 | starseeker | that should do it |
| 15:34.44 | starseeker | bhinesley: around? |
| 15:43.47 | CIA-62 | BRL-CAD: 03d_rossberg * r46536 10/brlcad/trunk/src/librt/bbox.c: |
| 15:43.47 | CIA-62 | BRL-CAD: for the Windows build: MSVC is not C99 |
| 15:43.47 | CIA-62 | BRL-CAD: moved variable declarations upwards |
| 15:51.46 | CIA-62 | BRL-CAD: 03n_reed * r46537 10/brlcad/trunk/src/conv/obj-g_new.c: Freeing the rest of the arrays with bu_free_array. |
| 16:20.53 | CIA-62 | BRL-CAD: 03n_reed * r46538 10/brlcad/trunk/src/libgcv/wfobj/re2c_utils.c: Using bu_vls_addr instead of accessing vls_str directly. |
| 16:23.57 | abhi2011 | starseeker: all good now :) |
| 17:22.12 | CIA-62 | BRL-CAD: 03erikgreenwald * r46539 10/brlcad/trunk/src/conv/stl/g-stl.c: add -8 (marching cubes) to usage |
| 17:33.23 | brlcad | starseeker: so I have a clean checkout/configure going now and still seeing a slew of tests fail that should not be failing |
| 17:34.52 | brlcad | dlopen, getprogname (which might be "correct"), setprogname (also maybe "correct" with std99), strlcat, strlcpy, sizeof(socklen_t) |
| 17:35.08 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 17:41.43 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 18:25.51 | *** join/#brlcad merzo (~merzo@98-229-132-95.pool.ukrtel.net) | |
| 19:05.58 | CIA-62 | BRL-CAD: 03brlcad * r46540 10/brlcad/trunk/CMakeLists.txt: distinguish compilation of 3rd party sources from our own build settings with different labels. Use 'Compile' instead of 'Build' since that helps disambiguate what the ON/OFF means (i.e., action not feature). |
| 19:06.55 | *** join/#brlcad merzo (~merzo@98-229-132-95.pool.ukrtel.net) | |
| 20:32.51 | CIA-62 | BRL-CAD: 03abhi2011 * r46541 10/brlcad/trunk/src/libged/simulate/simulate.h: Added new header file to declare structures for passing sim parameters |
| 20:33.42 | CIA-62 | BRL-CAD: 03abhi2011 * r46542 10/brlcad/trunk/src/libged/simulate/CMakeLists.txt: Added simulate.h new header to CMake |
| 20:35.10 | CIA-62 | BRL-CAD: 03abhi2011 * r46543 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c): Changed simulate command logic to duplicate and pass regions to bullet |
| 20:38.21 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3090 10/wiki/User:Abhijit: /* Log */ |
| 20:42.35 | CIA-62 | BRL-CAD: 03abhi2011 * r46544 10/brlcad/trunk/src/libged/simulate/simulate.h: Modified some comments to indicate the reason for simulate.h |
| 21:00.12 | CIA-62 | BRL-CAD: 03bob1961 * r46545 10/brlcad/trunk/ (include/ged.h include/tclcad.h src/libtclcad/tclcad_obj.c): Moved and renamed a few mode related macros that are used only by libtclcad from ged.h to tclcad.h. |
| 21:22.24 | starseeker | brlcad: out of curiosity, what does autotools configure say about those on the same machine? |
| 21:23.41 | brlcad | don't know, blew away my autotools build |
| 21:23.55 | starseeker | ah, k |
| 21:24.03 | brlcad | don't want to mix the two for a few days just to make sure everything I'm seeing is "pure cmake" |
| 21:24.24 | brlcad | still trying to verify that nothing in main dir isn't getting modified |
| 21:25.36 | brlcad | so far looking good after a full build |
| 21:28.16 | starseeker | if you really want to go whole hog on that, strip all the svn:ignore stuff we've got |
| 21:28.24 | starseeker | did that in the cmake branch |
| 21:28.40 | starseeker | was planning to do it in trunk once we no longer support autotools |
| 22:32.44 | CIA-62 | BRL-CAD: 03n_reed * r46546 10/brlcad/trunk/src/conv/obj-g_new.c: Distance tolerance changed from .0005 to .005. |
| 22:33.29 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 22:46.07 | CIA-62 | BRL-CAD: 03starseeker * r46547 10/brlcad/trunk/ (CMakeLists.txt include/CMakeLists.txt): Improve handling of newlines for system conf files |
| 22:49.51 | CIA-62 | BRL-CAD: 03starseeker * r46548 10/brlcad/trunk/CMakeLists.txt: use all the CPUs we can - go with 20 as a good number given current systems (2011) |
| 23:16.04 | *** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 23:35.32 | *** join/#brlcad n_reed (44378e88@gateway/web/freenode/ip.68.55.142.136) | |
| 23:51.02 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 00:11.38 | CIA-62 | BRL-CAD: 03starseeker * r46549 10/brlcad/trunk/src/libdm/CMakeLists.txt: Apparently we don't need the termlib include dir in libdm after all. |
| 00:49.03 | *** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 02:43.11 | CIA-62 | BRL-CAD: 03starseeker * r46550 10/brlcad/trunk/ (5 files in 5 dirs): |
| 02:43.11 | CIA-62 | BRL-CAD: Do for other files what we do for .dist - fatal error if we're trying to ignore |
| 02:43.11 | CIA-62 | BRL-CAD: something that doesn't exist, unless it's a generated file (which will specify |
| 02:43.11 | CIA-62 | BRL-CAD: itself in a src list with a full path, and thus can be recognized.) Actually |
| 02:43.11 | CIA-62 | BRL-CAD: caught a number of bugs in the CMake logic, which are also fixed in this commit. |
| 08:18.16 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) | |
| 08:50.36 | plaes | uhh.. r46548 -- passing 20 compile jobs for build is a bit too much |
| 09:51.59 | ``Erik | plaes: yeah... I'd argue it should be single threaded unless otherwise requested... I'll alter that once I get into the office, mebbe about an hour from now... and roll up a newspaper to swat starseeker some :D |
| 09:57.42 | plaes | ;) |
| 09:58.21 | plaes | \o/ |
| 10:55.42 | CIA-62 | BRL-CAD: 03erikgreenwald * r46551 10/brlcad/trunk/CMakeLists.txt: Remove -j20. Parallel builds should be at the builders explicit request to avoid accidentally hammering the machine. |
| 11:16.03 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 11:19.33 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 12:24.26 | brlcad | meh, that was specifically for distcheck builds which only affects devs -- make is running the build so the dev user doesn't have an immediate means to specify parallel |
| 12:25.02 | brlcad | it should sense the number of cpus and use that by default |
| 12:32.32 | ``Erik | cmake doesn't carry MAKE_FLAGS for you? |
| 12:35.23 | brlcad | not that I'm aware of |
| 12:35.26 | brlcad | maybe something like that could be added |
| 12:36.32 | brlcad | maybe a poor-mans version like: http://www.cmake.org/pipermail/cmake/2010-October/040122.html |
| 12:50.30 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:51.54 | ``Erik | I'm not keen on the automatically parallel thing, *shrug* if I set up a cron to do a distcheck on, say, bz, any parallel would cause a bit of service degredation. mebbe set NPROCS=1 and do "make NPROC=`sysctl -n hw.ncpu` distcheck" or something? |
| 12:53.19 | ``Erik | ('cept with the var names matching and all that) |
| 12:55.02 | ``Erik | hm, survice is putting on another BRL-CAD training course on sept 19, this time in eglin (ft walton beach, florida) O.o |
| 12:59.22 | CIA-62 | BRL-CAD: 03d_rossberg * r46552 10/brlcad/trunk/CMakeLists.txt: |
| 12:59.22 | CIA-62 | BRL-CAD: WIN32 is an add_executable() flag => sort it out from the source file names too |
| 12:59.22 | CIA-62 | BRL-CAD: because it's a CMake variable it has to be prefixed by a "x" e.g. |
| 13:01.00 | brlcad | ``Erik: mebbe, it just needs *some* way to go parallel or nobody will perform a distcheck very often -- it'll take way too long |
| 13:01.42 | brlcad | better to be useful and dangerous than relatively useless and safe |
| 13:03.11 | ``Erik | *shrug* or mebbe go parallel by default and have some way to force it to be low(ered) impact? |
| 13:03.28 | brlcad | if it can come from the initial command-line, even better, then it's both safe and useful but the goal should definitely be towards getting everyone running distcheck more frequently |
| 13:04.09 | ``Erik | I'm thinking more towards having it run automatically, continuous integration style :) |
| 13:04.43 | brlcad | we should *also* be doing that :) |
| 13:05.24 | brlcad | shouldn't be a crutch, imho though |
| 13:05.58 | brlcad | i should be able to invoke a distcheck on-demand without hesitation and get a result within 2x-3x of a regular build time |
| 13:06.14 | brlcad | if it's any longer or has more steps, most won't do it |
| 13:06.51 | ``Erik | regular build is single threaded, though... I do "nice make -j17 build install" on the 16 core machines |
| 13:07.17 | ``Erik | I wouldn't mind having to type "nice make -j17 distcheck", if that'd work on the subdir build |
| 13:07.19 | brlcad | I can't even do the on-demand part right now because there are extra steps (got to have a pristine checkout), but we talked about that one last night and it should be doable to get it going on any checkout |
| 13:07.46 | brlcad | yeah, that'd make sense except how the make distcheck rule is implemented |
| 13:07.53 | brlcad | make -jXX distcheck won't work |
| 13:08.11 | ``Erik | yeah, back to the MAKE_FLAGS ... :D |
| 13:08.30 | brlcad | just calls a distcheck rule that reinvokes a cmake build rule -- so you can distcheck from msvc or xcode, etc |
| 13:09.02 | brlcad | the cmake build rule knows nothing of the make -j flag that might have been set (though there might be some way to capture that) |
| 13:09.30 | brlcad | finds this disturbing, and highly suspect: https://sourceforge.net/tracker/?func=detail&atid=640803&aid=3402908&group_id=105292 |
| 13:10.56 | ``Erik | saw that, dunno what 'comodo' is, where the exe came from, if it's a false positive, mebbe a marketing move by that comodo company, ... :/ |
| 13:12.09 | ``Erik | comodo seems to be a chinese company that sells services which involve them having remote admin access to your winderz boxen |
| 13:15.28 | ``Erik | http://en.wikipedia.org/wiki/Comodo_Group hm |
| 13:16.32 | ``Erik | anim_cascade.exe is the only one marked |
| 13:19.33 | CIA-62 | BRL-CAD: 03d_rossberg * r46553 10/brlcad/trunk/include/CMakeLists.txt: |
| 13:19.33 | CIA-62 | BRL-CAD: there is no brlcad_config.h.in in the repository |
| 13:19.33 | CIA-62 | BRL-CAD: it appears to be CMake generated and lives in the CMake binaries' directory |
| 13:35.06 | brlcad | yeah, I saw the pic -- incredibly unlikely but possible |
| 13:35.35 | brlcad | who made the 7.20.0 binary? |
| 14:37.49 | *** join/#brlcad n_reed (~nreed1@c-68-55-142-136.hsd1.md.comcast.net) | |
| 14:43.35 | brlcad | n_reed: 0.0005 is what it's "supposed" to be .. there are just a LOT of places that value is inconsistent |
| 14:44.24 | brlcad | so you had it right ;) |
| 14:44.50 | n_reed | brlcad: I'll change it back then. |
| 14:45.39 | n_reed | brlcad: Richard told me yesterday that it was supposed to be .005. |
| 14:46.27 | n_reed | brlcad: That is the tolerance that prints if you open a db model and type tol in mged. |
| 14:51.37 | brlcad | yeah, that's part of the inconsistency |
| 14:52.45 | brlcad | changing tolerance values requires a fair bit of retesting to make sure it's backwards-compatible |
| 15:34.29 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 15:39.18 | CIA-62 | BRL-CAD: 03n_reed * r46554 10/brlcad/trunk/src/conv/obj-g_new.c: Reverted to previous revision. .0005mm is the correct distance tolerance. |
| 15:41.06 | brlcad | abhi2011: a matter of nomenclature -- the word "region" has a very specific meaning within BRL-CAD |
| 15:41.45 | brlcad | a region is a database combination with a flag set that indicates the combination occupies physical space |
| 15:42.43 | brlcad | all regions are combinations, but not all combinations are regions .. and no primitive is a region |
| 15:43.08 | brlcad | "groups" (aka assemblies) is a combination that contains one or more regions |
| 15:45.12 | abhi2011 | brlcad: ok |
| 15:46.18 | brlcad | simulate is pretty much agnostic to all of that, just working with "geometry objects" |
| 15:46.35 | brlcad | which can be regions, groups, combs, prims, etc :) |
| 15:57.31 | CIA-62 | BRL-CAD: 03brlcad * r46555 10/brlcad/trunk/src/tclscripts/mged/ (pattern.tcl tclIndex): use the new 'exists' command instead of rolling our own |
| 16:21.32 | CIA-62 | BRL-CAD: 03brlcad * r46556 10/brlcad/trunk/src/tclscripts/ (6 files in 2 dirs): more cases where the new 'exists' command can be put to use. use exists instead of db get or db get_type to test whether a database object already exists. |
| 16:54.27 | CIA-62 | BRL-CAD: 03starseeker * r46557 10/brlcad/trunk/CMakeLists.txt: Get a bit fancier with the package name and version for RPMs - commented out by default, but available if desired. |
| 16:59.31 | brlcad | conforming to HACKING or different? we need to be consistent for all our releases (for a whole variety of reasons) |
| 16:59.57 | brlcad | otherwise, it's basically "wrong" and should be fixed |
| 17:02.28 | brlcad | the format as-is "should" fit most any distribution system I'm aware of including support for optional notes and annotations |
| 17:09.47 | CIA-62 | BRL-CAD: 03abhi2011 * r46558 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c simulate.h): Modified simulate to look through all regions in the current DB and add them as rigid bodies to the sim, objects now fallto the ground correctly |
| 17:31.13 | *** join/#brlcad n_reed (~nreed1@c-68-55-142-136.hsd1.md.comcast.net) | |
| 19:00.17 | CIA-62 | BRL-CAD: 03erikgreenwald * r46559 10/brlcad/trunk/src/libgcv/bottess.c: simplify some bit mangling |
| 19:23.47 | CIA-62 | BRL-CAD: 03starseeker * r46560 10/brlcad/trunk/doc/docbook/system/mann/en/ (CMakeLists.txt exists.xml): Add preliminary man page for new version of the exists command. |
| 19:24.18 | starseeker | brlcad: figured I'd let you have a go at that before I start getting TOO deep into the C code |
| 19:31.43 | CIA-62 | BRL-CAD: 03starseeker * r46561 10/brlcad/trunk/doc/docbook/system/mann/en/exists.xml: whoops, extra char - stay consistent, 3 letters for those options |
| 19:37.40 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 19:58.24 | CIA-62 | BRL-CAD: 03starseeker * r46562 10/brlcad/trunk/src/libged/exists.c: Start roughing out the test.c->exists.c translation. Not doing any major rewiring yet until we've got the options more solidly pinned down, but it's a start. |
| 20:04.08 | abhi2011 | here is the obligatory bricks toppling over video : http://www.youtube.com/watch?v=TIgm0tNYseM |
| 20:04.21 | abhi2011 | made entirely with mged and rt |
| 20:06.48 | starseeker | cool! |
| 20:07.03 | starseeker | how come the block at the right on the end doesn't end up flat? (just curious) |
| 20:07.20 | starseeker | doesn't look like things quite go to equilibrium... |
| 20:11.30 | abhi2011 | yes there is some penetration of the ground plane , probably due to a error with positioning it or the default collision detection not working as expected :P |
| 20:11.56 | ``Erik | bullet ftw, awesome stuff |
| 20:13.11 | abhi2011 | so whats the easiest way to convert the image sequence output by rt into a mpeg movie in linux |
| 20:14.09 | abhi2011 | tried imagemagick, but its requires ffmpeg delegates or something similar |
| 20:14.15 | ``Erik | I used ffmpeg a while back |
| 20:14.22 | ``Erik | I hear the linux mplayer does well, too |
| 20:17.18 | ``Erik | making a driving game? O.o |
| 20:19.12 | abhi2011 | hehe yeah was trying to integrate bullet raycast vehicle into a moon buggy kinda thing |
| 20:19.36 | abhi2011 | was quite smooth with a basic engine model |
| 20:41.27 | *** join/#brlcad b0ef (~b0ef@166.195.251.212.customer.cdi.no) | |
| 21:49.15 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 22:02.28 | ``Erik | huzzah, truck is fixed |
| 22:02.44 | starseeker | awesome |
| 22:04.37 | ``Erik | idjit who rotated the tires didn't do a very good job of tightening the lug nuts, that was all |
| 22:15.07 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096600997.dsl.bell.ca) | |
| 22:32.45 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 23:07.07 | brlcad | abhi2011: hah, that's f'n awesome :) |
| 23:07.24 | brlcad | starseeker: will do (reviewing the exists usage) |
| 23:08.42 | brlcad | abhi2011: so I see the view keeps changing on you as the simulation progresses -- that's due to something getting redrawn |
| 23:09.07 | brlcad | for animation purposes, you can either set up a view script and just keep re-rendering that script for each frame |
| 23:09.43 | brlcad | or you can capture the view size before and restore it after the command is updated (or don't erase and redraw, just redraw) |
| 23:10.40 | brlcad | abhi2011: I'd love to showcase that to the website if you can pull together a better video |
| 23:10.54 | brlcad | suggest a 2x zoom |
| 23:11.29 | brlcad | and maybe a different starting configuration if only to avoid the block that penetrates the surface |
| 23:48.01 | ``Erik | <PROTECTED> |
| 23:48.18 | ``Erik | I think the ogl demos that come with bullet do it that way :/ not sure |
| 01:44.48 | brlcad | yeah, the two should be decoupled, but even at a low framerate, that penetration shouldn't happen -- implies something is amiss |
| 01:44.55 | brlcad | still, that is fantastic |
| 01:45.17 | brlcad | haven't seen a proper brl-cad animation since the old joint days, probably 8 years ago |
| 03:59.59 | *** part/#brlcad n_reed (~nreed1@c-68-55-142-136.hsd1.md.comcast.net) | |
| 04:28.20 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 05:42.02 | abhi2011 | Thanks everyone :) |
| 05:42.45 | abhi2011 | brlcad: Yes the view seems to change to accomodate all objects with the 1024 by 1024 image size |
| 05:43.03 | abhi2011 | I ll play around with the rtcheck parameters to see whats up |
| 05:43.49 | abhi2011 | I mean rt |
| 05:45.12 | abhi2011 | Yeah I think the penetration will no happen if I specify a plane as the ground plane |
| 05:46.15 | abhi2011 | currently I make a box shape with the same parameters as a arb8 shape in mged (the command looks for a gp.s arb8 shape and uses its bb for the ground plane) |
| 05:46.39 | abhi2011 | but yeah that cant be an excuse, penetration shouldnt happen either way |
| 09:12.51 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 09:52.50 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 12:27.38 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 12:56.30 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 12:58.13 | brlcad | abhi2011: the "what's up" is that a view isn't specified, so it just autosizes the view based on what is being drawn |
| 12:58.50 | brlcad | the view merely needs to be specified (if you run "saveview" within mged, you'll get a view script that you could re-use to render each frame consistently) |
| 12:59.02 | abhi2011 | oh ok, I ll try that |
| 12:59.23 | abhi2011 | I have 1 more question |
| 12:59.30 | abhi2011 | so I have been trying to draw a stack of cubes |
| 12:59.34 | abhi2011 | upon each other |
| 12:59.36 | abhi2011 | in mged |
| 12:59.44 | abhi2011 | so I run a tcl loop |
| 12:59.54 | brlcad | I suspect the penetration is because you're using AABBs |
| 13:00.25 | brlcad | you're passing the aabb's to bullet as simple cubes .. bullet applies rotations to them which causes them to tumble |
| 13:00.38 | brlcad | you correctly apply the tumble transformation to them |
| 13:01.15 | brlcad | but don't feed bullet new aabbs (as they get bigger when the arb8 tumbles), so it's allowed to get too close to the surface |
| 13:02.22 | brlcad | I suspect if you changed the arb8s to all spheres, it wouldn't penetrate (but then the spheres would bounce off each other before they actually touch) |
| 13:02.36 | brlcad | at least until you get the custom collision handler implemented |
| 13:02.37 | abhi2011 | yes, but bullet maintains it own aabbs too |
| 13:02.55 | abhi2011 | thats how it eliminates a large number of objects in broadphase collison detection |
| 13:02.55 | brlcad | so sounds like three things todo |
| 13:03.54 | brlcad | 1) you need some means to update the bb to bullet each timestep if that's not happening already, not just reusing the original bb |
| 13:05.13 | brlcad | 2) you'll need to register a custom collision detection callback for bullet to call, this will be a callback you write that shoots a simple small grid of rays |
| 13:05.33 | brlcad | 3) render with a view set ;) |
| 13:13.24 | abhi2011 | ok |
| 13:13.48 | abhi2011 | yes, actually I dont set the aabb at all in bullet |
| 13:14.08 | abhi2011 | I just make a box with the same dimensions as the aabb |
| 13:14.29 | abhi2011 | I suspect bullet updates the aabb, but maybe not |
| 13:15.11 | abhi2011 | so I was thinking about the sphere dropping on a plane scenario |
| 13:15.35 | abhi2011 | what I would do now is create a cube aligned to the aabb of the sphere |
| 13:15.39 | abhi2011 | and start the sim |
| 13:16.08 | abhi2011 | when the cube touches the ground plane, then bullet would generate a bunch of contact points all along the bottom face of the aabb |
| 13:16.27 | abhi2011 | however at this point I am arranging for a callback to my code |
| 13:17.42 | abhi2011 | in this callback function, I ll use rtcheck or something similar to check the regions which overlap, which in this case would be a sphere region and a ground plane region |
| 13:18.25 | abhi2011 | and I ll modify the contact point list to the 1 single point at the bottom of the sphere which actually makes contact from the region perspective |
| 13:19.10 | abhi2011 | consequently the sphere region aabb may roll over as its contact points have been modified |
| 13:19.32 | abhi2011 | note I am not talking about geometry here at all as discussed before |
| 13:20.34 | abhi2011 | I am dealing simply with regions and their aabbs :) |
| 13:21.14 | abhi2011 | all this is based on the fact that a tool does exist in brl-cad which can give me a list of contact points when 2 regions overlap in 3d space |
| 13:37.40 | brlcad | so a tool exists, but I think you'll find it even easier to shoot the rays yourself (where you can easily control the resolution) |
| 13:38.12 | abhi2011 | ok |
| 13:39.18 | brlcad | as for the aabbs, that was my point -- you pass the aabb (which you feed to bullet as a box), bullet treats it as a box and begins to tumble and apply rotations |
| 13:39.57 | brlcad | once you apply that rotation which came back from bullet, the bb needs to be recalculated and set AGAIN in bullet |
| 13:40.22 | brlcad | if you do that, then there will be no object bounding box penetration |
| 13:40.50 | brlcad | then you can write the collision detection callback that will more accurately report the contact points when bb's overlap |
| 13:41.44 | abhi2011 | ok yeah I can do that for sure, it would require calculating the aabb every simulation tick but that should be ok |
| 13:42.01 | brlcad | yeah, should be instantaneous until the objects get into the thousands |
| 13:42.39 | brlcad | the collision detection callback is going to be what slows things down a little |
| 13:43.18 | brlcad | but what I suggest is starting with the bare minimum, shooting two 3x3 grids of rays |
| 13:44.22 | abhi2011 | ok, but 3 by 3 grid means, if the rays are far apart then they may miss many cubes |
| 13:44.25 | brlcad | er, 3x3x3 grid of rays, a 3x3 for each axis, giving you 27 rays |
| 13:44.35 | abhi2011 | ok |
| 13:44.51 | brlcad | that's just a starting point to make sure things are working |
| 13:44.55 | abhi2011 | ok |
| 13:45.47 | brlcad | that number can EASILY be increased for better detection, but it will slow things down at a cubic rate |
| 13:46.02 | abhi2011 | yes true |
| 13:46.21 | abhi2011 | no point in resetting the contatc manifold multiple times in the same frame |
| 13:48.06 | abhi2011 | though different rays would pass through the overlap region in different places, so new points would be generated by every ray within the overlap region |
| 13:50.11 | brlcad | yes, and the points generated would be precise including the contact point and hit point normal |
| 14:42.53 | abhi2011 | by the way I came across a strange issue while moving objects into position in mged |
| 14:43.07 | abhi2011 | so I generally use rt_matrix_transform() |
| 14:43.43 | abhi2011 | seems if i directly pass it a matrix in the opengl format (after transposing it as brlcad is row major while opengl is column major) |
| 14:43.56 | abhi2011 | then the rotations are applied first and then the translation |
| 14:44.10 | abhi2011 | so the object ends up in a wierd place |
| 14:44.44 | abhi2011 | currently i translate to the origin , do the rotation and then translate again wrt orgin to get to the final position |
| 17:22.31 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 17:26.43 | *** join/#brlcad abhi2011_ (~chatzilla@x033197.its-s.tudelft.nl) | |
| 17:30.23 | *** join/#brlcad abhi2011 (~chatzilla@x033197.its-s.tudelft.nl) | |
| 18:19.57 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 19:14.18 | *** join/#brlcad merzo (~merzo@170-171-133-95.pool.ukrtel.net) | |
| 19:33.52 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 20:56.07 | CIA-62 | BRL-CAD: 03jordisayol * r46563 10/brlcad/trunk/misc/debian/control: Change building dependencies from make to cmake for debian sources |
| 21:04.40 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 00:48.39 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 01:34.29 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 02:01.29 | CIA-62 | BRL-CAD: 03jordisayol * r46564 10/brlcad/trunk/ (4 files in 2 dirs): |
| 02:01.29 | CIA-62 | BRL-CAD: Correct wrong building dependencies. |
| 02:01.29 | CIA-62 | BRL-CAD: Force cmake to compile all 3rd party sources in brlcad. |
| 08:59.33 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 09:17.18 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 12:39.27 | abhi2011 | yeah i found why the blocks are penetrating the plane |
| 12:39.34 | abhi2011 | the positioning is wrong |
| 12:39.48 | abhi2011 | I was checking the rotation matrices |
| 12:40.15 | abhi2011 | for a block lying on the ground plane there should not be any rotation about the z axis |
| 12:40.30 | abhi2011 | and bullet returns it as that |
| 12:40.43 | abhi2011 | however i am not properly transferring that rotation to mged |
| 12:41.15 | abhi2011 | *correction : there should not be any rotation about the y axis |
| 14:26.42 | CIA-62 | BRL-CAD: 03173.208.51.136 07http://www.solidgeometry.org * r3092 10/wiki/Lmfao_bookmarking_that_33: New page: [[Image:social_bookmarking_service_2557.jpg|thumb|]] Delightful is some [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that allows consumers to share links on ... |
| 14:37.39 | abhi2011 | fixed, no interpenetration now, now for the movie |
| 14:44.56 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 15:04.58 | plaes | um.. spam ^^ ? |
| 15:30.53 | CIA-62 | BRL-CAD: 03abhi2011 * r46565 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c simulate.h): Updated the positioning code to transfer positions and orientations correctly from bullet to mged |
| 16:33.15 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 16:35.15 | abhi2011 | updated video : http://www.youtube.com/watch?v=SByoQQStH2s |
| 16:35.27 | abhi2011 | still not quite the way I would like to render it |
| 16:35.34 | abhi2011 | I made a view script and rendered this time |
| 16:35.44 | abhi2011 | however I want a 1024 by 768 render |
| 16:35.58 | abhi2011 | i get only 512 by 512 |
| 16:41.13 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3093 10/wiki/User:Abhijit: /* Log */ |
| 17:29.34 | starseeker | <PROTECTED> |
| 17:29.38 | starseeker | whoops |
| 17:31.13 | starseeker | hah, that rocks |
| 17:31.40 | starseeker | video is a tad long - looks like an extra 10-15 sec after all the blocks stop moving? |
| 17:33.06 | starseeker | abhi2011: if you do that in mged, do the wireframes update and display interactively? |
| 17:33.27 | starseeker | (say, if you wanted to do a quick check of the behavior before you kicked off all the raytracing?) |
| 17:37.11 | starseeker | can't wait to see a raytracer based interaction :-) |
| 17:49.00 | abhi2011 | starseeker: does not yet update interactively even if I run the simulate command in a loop or thru' a proc, that will require some changes to the way commands are run now currently |
| 17:50.08 | abhi2011 | yeah, I ran for 600 steps when all the action gets over after 300, also made that movie in windows movie maker and didnt set the delay small enough so it looks in slow motion :P |
| 17:51.21 | abhi2011 | yes integrating the raytracer is the next steps, things ll get pretty interesting now :) |
| 19:39.18 | *** join/#brlcad merzo (~merzo@156-124-133-95.pool.ukrtel.net) | |
| 19:54.00 | CIA-62 | BRL-CAD: 0369.147.248.153 07http://brlcad.org * r3094 10/wiki/I_don_t_have_service_appropriate_now_I_will_as_soon_as_I_get_home_3_56: New page: [[Image:social_bookmarking_service_2281.jpg|thumb|]] StumbleUpon is a [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] to buyers to find out new websites based o... |
| 19:56.37 | CIA-62 | BRL-CAD: 03173.234.123.184 07http://ist.brlcad.org * r3095 10/wiki/HQ_Service_0: New page: [[Image:social_bookmarking_service_975.jpg|thumb|]] Whilst checking your daily internet site metrics within Google Analytics, you might be delighted to secure that is someone has shared s... |
| 20:50.56 | CIA-62 | BRL-CAD: 03starseeker * r46566 10/brlcad/trunk/CMakeLists.txt: Ah, right - using cfg in the path messes with the file placements we need to run in build dir. |
| 21:25.15 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 21:25.15 | CIA-62 | BRL-CAD: deleted "[[Lmfao bookmarking that 33]]": content was: |
| 21:25.15 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_2557.jpg|thumb|]]Delightful is some |
| 21:25.15 | CIA-62 | BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] |
| 21:25.15 | CIA-62 | BRL-CAD: th...' (and the only contributor was |
| 21:25.16 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.208.51.136|173.208.51.136]]') |
| 21:25.25 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.51.136]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 21:26.27 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[I don t have service appropriate now I will as soon as I get home 3 56]]": spam |
| 21:26.40 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:69.147.248.153]] with an expiry time of infinite (anonymous users only, account creation disabled) |
| 21:27.14 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[HQ Service 0]]": spam |
| 21:27.27 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.123.184]] with an expiry time of infinite (anonymous users only, account creation disabled) |
| 21:29.58 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User:Cadev]]": spam? |
| 23:39.08 | CIA-62 | BRL-CAD: 03173.208.24.246 07http://www.solidgeometry.org * r3096 10/wiki/Sunday_morning_televised_service_at_the_crystal_cathedral_Channel_40_25: New page: [[Image:social_bookmarking_service_4995.jpg|thumb|]] Web 2.0 describes the shift toward cooperative, shared, multimedia experiences on the Web. Particular sites, these kinds of whereas th... |
| 23:49.47 | CIA-62 | BRL-CAD: 03173.234.187.29 07http://ist.brlcad.org * r3097 10/wiki/Not_long_after_support_had_to_stay_choir_practice_lol_39: New page: [[Image:social_bookmarking_service_3018.jpg|thumb|]] StumbleUpon remains a [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] to users to uncover new internet site... |
| 23:51.14 | CIA-62 | BRL-CAD: 03173.234.11.159 07http://brlcad.org * r3098 10/wiki/Que_puto_empinado_social_53: New page: [[Image:social_bookmarking_service_3786.jpg|thumb|]] StumbleUpon remains some [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that allows you browse by way of r... |
| 00:14.21 | CIA-62 | BRL-CAD: 0364.120.86.29 07http://ist.brlcad.org * r3099 10/wiki/Hunderte_gratis_Besucher_mit_Social_Bookmarking_26: New page: [[Image:social_bookmarking_service_1862.jpg|thumb|]] Toothsome yous any [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that permits owners to share links on th... |
| 00:25.28 | CIA-62 | BRL-CAD: 03173.208.25.215 07http://brlcad.org * r3100 10/wiki/Service_was_lovely_71: New page: [[Image:social_bookmarking_service_5574.jpg|thumb|]] StumbleUpon is a [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] with users to find new websites based on t... |
| 00:30.48 | CIA-62 | BRL-CAD: 03173.234.94.105 07http://bz.brlcad.org * r3101 10/wiki/Shitty_service_at_friendlys_on_57_79: New page: [[Image:social_bookmarking_service_2992.jpg|thumb|]] Whilst checking your daily website metrics within Google Analytics, you might be delighted to find that is someone has shared a link t... |
| 00:31.18 | CIA-62 | BRL-CAD: 03173.234.175.26 07http://www.solidgeometry.org * r3102 10/wiki/Okay_now_I_m_just_annoyed_Can_Social_Distortion_consider_the_stage_now_75: New page: [[Image:social_bookmarking_service_3643.jpg|thumb|]] StumbleUpon may be an essential device to increase your amount about visitors. StumbleUpon is a [http://lease-a-seo.com/social-bookma... |
| 00:51.26 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 00:58.30 | CIA-62 | BRL-CAD: 03173.234.143.96 07http://brlcad.org * r3103 10/wiki/The_Bayou_Bonfouca_Bridge_on_LA_433_is_back_in_service_St_Tammany_87: New page: [[Image:social_bookmarking_service_5054.jpg|thumb|]] Delicious is some [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that is allows buyers to share links on t... |
| 01:03.25 | CIA-62 | BRL-CAD: 03173.234.94.105 07http://bz.brlcad.org * r3104 10/wiki/I_am_not_anti_public_I_just_Do_Not_like_you_20: New page: [[Image:social_bookmarking_service_2366.jpg|thumb|]] StumbleUpon is any [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] to users to learn new websites based on ... |
| 01:13.07 | CIA-62 | BRL-CAD: 03173.234.143.96 07http://ist.brlcad.org * r3105 10/wiki/Baby_Social_Worker_Doctor_is_my_favourite_Doctor_24: New page: [[Image:social_bookmarking_service_5000.jpg|thumb|]] Whilst checking your everyday web site metrics in Google Analytics, you might be thrilled to find that is someone has shared a link to... |
| 01:17.55 | CIA-62 | BRL-CAD: 0364.120.117.41 07http://ist.brlcad.org * r3106 10/wiki/Lol_mi_no_put_on_me_service_yet_eno_beb_Oh_lol_when_74: New page: [[Image:social_bookmarking_service_1881.jpg|thumb|]] Tasty is some [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that allows consumers to share links on the w... |
| 01:42.30 | CIA-62 | BRL-CAD: 03173.234.187.29 07http://bz.brlcad.org * r3107 10/wiki/Ppc_services_social_bookmarking_website_promotion_14: New page: [[Image:social_bookmarking_service_1744.jpg|thumb|]] Web 2.0 tools can link your students along with resources around the world. Web 2.0 explains the progress toward collaborative, share... |
| 01:57.46 | CIA-62 | BRL-CAD: 03173.234.176.193 07http://ist.brlcad.org * r3108 10/wiki/In_two_weeks_yeah_haha_get_off_twitter_this_is_my_social_network_30: New page: [[Image:social_bookmarking_service_5335.jpg|thumb|]] Whilst checking your regular website metrics in Google Analytics, you might be delighted to find that someone has shared some link to ... |
| 02:03.10 | CIA-62 | BRL-CAD: 03173.234.93.135 07http://brlcad.org * r3109 10/wiki/La_vida_social_no_me_dejo_escribir_mucho_estas_ultimas_horas_87: New page: [[Image:social_bookmarking_service_1607.jpg|thumb|]] Web 2.0 gear can link your students by resources around the community. Web 2.0 explains the progress toward collaborative, shared, mu... |
| 02:04.54 | CIA-62 | BRL-CAD: 0364.120.38.9 07http://bz.brlcad.org * r3110 10/wiki/Amr_ta_On_em_alguma_rede_social_67: New page: [[Image:social_bookmarking_service_4116.jpg|thumb|]] While checking your every day internet site metrics from Google Analytics, you might be delighted to find that somebody has shared any... |
| 02:05.06 | CIA-62 | BRL-CAD: 03173.234.245.28 07http://www.solidgeometry.org * r3111 10/wiki/At_your_service_sir_87: New page: [[Image:social_bookmarking_service_4617.jpg|thumb|]] While checking your regular website metrics with Google Analytics, you might be delighted to discover that someone has shared a link t... |
| 02:33.55 | CIA-62 | BRL-CAD: 0364.120.38.9 07http://bz.brlcad.org * r3112 10/wiki/I_dont_have_no_service_26: New page: [[Image:social_bookmarking_service_4706.jpg|thumb|]] Label the website in keywords to assist other owners identify hers content. Trouble: Tolerably Easy Directions 1 Warning up for a [... |
| 02:34.37 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.24.246]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 02:35.40 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 02:35.40 | CIA-62 | BRL-CAD: deleted "[[Sunday morning televised service at the crystal cathedral Channel 40 |
| 02:35.40 | CIA-62 | BRL-CAD: 25]]": content was: '[[Image:social_bookmarking_service_4995.jpg|thumb|]]Web 2.0 |
| 02:35.40 | CIA-62 | BRL-CAD: describes the shift toward cooperative, shared, multimedia experiences on the |
| 02:35.40 | CIA-62 | BRL-CAD: Web. Parti...' (and the only contributor was |
| 02:35.40 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.208.24.246|173.208.24.246]]') |
| 02:36.11 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.187.29]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 02:36.46 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 02:36.46 | CIA-62 | BRL-CAD: deleted "[[Not long after support had to stay choir practice lol 39]]": content |
| 02:36.46 | CIA-62 | BRL-CAD: was: '[[Image:social_bookmarking_service_3018.jpg|thumb|]]StumbleUpon remains a |
| 02:36.46 | CIA-62 | BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service]...' |
| 02:36.46 | CIA-62 | BRL-CAD: (and the only contributor was |
| 02:36.47 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.234.187.29|173.234.187.29]]') |
| 02:37.12 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.11.159]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 02:37.22 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 02:37.22 | CIA-62 | BRL-CAD: deleted "[[Que puto empinado social 53]]": content was: |
| 02:37.22 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_3786.jpg|thumb|]]StumbleUpon remains some |
| 02:37.22 | CIA-62 | BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking servi...' (and |
| 02:37.23 | CIA-62 | BRL-CAD: the only contributor was |
| 02:37.23 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.234.11.159|173.234.11.159]]') |
| 02:38.07 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:64.120.86.29]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 02:38.18 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 02:38.18 | CIA-62 | BRL-CAD: deleted "[[Hunderte gratis Besucher mit Social Bookmarking 26]]": content was: |
| 02:38.18 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_1862.jpg|thumb|]]Toothsome yous any |
| 02:38.18 | CIA-62 | BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] |
| 02:38.19 | CIA-62 | BRL-CAD: th...' (and the only contributor was |
| 02:38.19 | CIA-62 | BRL-CAD: '[[Special:Contributions/64.120.86.29|64.120.86.29]]') |
| 02:38.39 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.25.215]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 02:38.54 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 02:38.54 | CIA-62 | BRL-CAD: deleted "[[Service was lovely 71]]": content was: |
| 02:38.54 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_5574.jpg|thumb|]]StumbleUpon is a |
| 02:38.54 | CIA-62 | BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] |
| 02:38.54 | CIA-62 | BRL-CAD: with...' (and the only contributor was |
| 02:38.55 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.208.25.215|173.208.25.215]]') |
| 02:39.04 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.94.105]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 02:39.16 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 02:39.16 | CIA-62 | BRL-CAD: deleted "[[Shitty service at friendlys on 57 79]]": content was: |
| 02:39.16 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_2992.jpg|thumb|]]Whilst checking your daily |
| 02:39.16 | CIA-62 | BRL-CAD: website metrics within Google Analytics, you might be delighted to fi...' (and |
| 02:39.17 | CIA-62 | BRL-CAD: the only contributor was |
| 02:39.17 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.234.94.105|173.234.94.105]]') |
| 02:40.02 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 02:40.02 | CIA-62 | BRL-CAD: deleted "[[Okay now I m just annoyed Can Social Distortion consider the stage |
| 02:40.02 | CIA-62 | BRL-CAD: now 75]]": content was: |
| 02:40.02 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_3643.jpg|thumb|]]StumbleUpon may be an |
| 02:40.02 | CIA-62 | BRL-CAD: essential device to increase your amount about visitors.StumbleUpon is a...' |
| 02:40.03 | CIA-62 | BRL-CAD: (and the only contributor was |
| 02:40.04 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.234.175.26|173.234.175.26]]') |
| 02:40.22 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.143.96]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 02:40.44 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 02:40.44 | CIA-62 | BRL-CAD: deleted "[[The Bayou Bonfouca Bridge on LA 433 is back in service St Tammany |
| 02:40.44 | CIA-62 | BRL-CAD: 87]]": content was: |
| 02:40.44 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_5054.jpg|thumb|]]Delicious is some |
| 02:40.44 | CIA-62 | BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] |
| 02:40.45 | CIA-62 | BRL-CAD: tha...' (and the only contributor was |
| 02:40.45 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.234.143.96|173.234.143.96]]') |
| 02:41.15 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 02:41.15 | CIA-62 | BRL-CAD: deleted "[[I am not anti public I just Do Not like you 20]]": content was: |
| 02:41.15 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_2366.jpg|thumb|]]StumbleUpon is any |
| 02:41.15 | CIA-62 | BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] |
| 02:41.15 | CIA-62 | BRL-CAD: to...' (and the only contributor was |
| 02:41.15 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.234.94.105|173.234.94.105]]') |
| 02:41.52 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 02:41.52 | CIA-62 | BRL-CAD: deleted "[[Baby Social Worker Doctor is my favourite Doctor 24]]": content was: |
| 02:41.52 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_5000.jpg|thumb|]]Whilst checking your |
| 02:41.52 | CIA-62 | BRL-CAD: everyday web site metrics in Google Analytics, you might be thrilled to fin...' |
| 02:41.52 | CIA-62 | BRL-CAD: (and the only contributor was |
| 02:41.52 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.234.143.96|173.234.143.96]]') |
| 02:42.04 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:64.120.117.41]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 02:42.25 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 02:42.26 | CIA-62 | BRL-CAD: deleted "[[Lol mi no put on me service yet eno beb Oh lol when 74]]": content |
| 02:42.26 | CIA-62 | BRL-CAD: was: '[[Image:social_bookmarking_service_1881.jpg|thumb|]]Tasty is some |
| 02:42.26 | CIA-62 | BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that |
| 02:42.26 | CIA-62 | BRL-CAD: al...' (and the only contributor was |
| 02:42.26 | CIA-62 | BRL-CAD: '[[Special:Contributions/64.120.117.41|64.120.117.41]]') |
| 02:42.39 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 02:42.39 | CIA-62 | BRL-CAD: deleted "[[Ppc services social bookmarking website promotion 14]]": content was: |
| 02:42.39 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_1744.jpg|thumb|]]Web 2.0 tools can link your |
| 02:42.39 | CIA-62 | BRL-CAD: students along with resources around the world.Web 2.0 explains th...' (and the |
| 02:42.39 | CIA-62 | BRL-CAD: only contributor was '[[Special:Contributions/173.234.187.29|173.234.187.29]]') |
| 02:42.55 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.176.193]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 02:43.08 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 02:43.08 | CIA-62 | BRL-CAD: deleted "[[In two weeks yeah haha get off twitter this is my social network |
| 02:43.08 | CIA-62 | BRL-CAD: 30]]": content was: '[[Image:social_bookmarking_service_5335.jpg|thumb|]]Whilst |
| 02:43.08 | CIA-62 | BRL-CAD: checking your regular website metrics in Google Analytics, you might be |
| 02:43.09 | CIA-62 | BRL-CAD: delighted to find...' (and the only contributor was |
| 02:43.09 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.234.176.193|173.234.176.193]]') |
| 02:43.41 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.93.135]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 02:43.52 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 02:43.53 | CIA-62 | BRL-CAD: deleted "[[La vida social no me dejo escribir mucho estas ultimas horas 87]]": |
| 02:43.53 | CIA-62 | BRL-CAD: content was: '[[Image:social_bookmarking_service_1607.jpg|thumb|]]Web 2.0 gear |
| 02:43.53 | CIA-62 | BRL-CAD: can link your students by resources around the community.Web 2.0 explains the |
| 02:43.53 | CIA-62 | BRL-CAD: pro...' (and the only contributor was |
| 02:43.53 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.234.93.135|173.234.93.135]]') |
| 02:44.05 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:64.120.38.9]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 02:44.21 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 02:44.21 | CIA-62 | BRL-CAD: deleted "[[Amr ta On em alguma rede social 67]]": content was: |
| 02:44.21 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_4116.jpg|thumb|]]While checking your every |
| 02:44.21 | CIA-62 | BRL-CAD: day internet site metrics from Google Analytics, you might be delighte...' (and |
| 02:44.22 | CIA-62 | BRL-CAD: the only contributor was '[[Special:Contributions/64.120.38.9|64.120.38.9]]') |
| 02:44.31 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 02:44.31 | CIA-62 | BRL-CAD: deleted "[[At your service sir 87]]": content was: |
| 02:44.31 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_4617.jpg|thumb|]]While checking your regular |
| 02:44.31 | CIA-62 | BRL-CAD: website metrics with Google Analytics, you might be delighted to dis...' (and |
| 02:44.32 | CIA-62 | BRL-CAD: the only contributor was |
| 02:44.32 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.234.245.28|173.234.245.28]]') |
| 02:44.41 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 02:44.41 | CIA-62 | BRL-CAD: deleted "[[I dont have no service 26]]": content was: |
| 02:44.41 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_4706.jpg|thumb|]]Label the website in |
| 02:44.41 | CIA-62 | BRL-CAD: keywords to assist other owners identify hers content.Trouble:Tolerably ...' |
| 02:44.42 | CIA-62 | BRL-CAD: (and the only contributor was |
| 02:44.42 | CIA-62 | BRL-CAD: '[[Special:Contributions/64.120.38.9|64.120.38.9]]') |
| 02:46.28 | CIA-62 | BRL-CAD: 03173.208.56.140 07http://ist.brlcad.org * r3113 10/wiki/Wer_nutzt_Evernote_f%C3%BCr_bookmarking_3: New page: [[Image:social_bookmarking_service_2094.jpg|thumb|]] Web 2.0 tools can connect your students with assets around the planet. Trouble: Average Directions 1 Permit students to use Web 2.0... |
| 02:50.59 | starseeker | hopes he's doing the blocking right... |
| 02:51.38 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.56.140]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 02:51.49 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 02:51.49 | CIA-62 | BRL-CAD: deleted "[[Wer nutzt Evernote f??r bookmarking 3]]": content was: |
| 02:51.49 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_2094.jpg|thumb|]]Web 2.0 tools can connect |
| 02:51.49 | CIA-62 | BRL-CAD: your students with assets around the planet.Trouble:AverageDirect...' (and the |
| 02:51.49 | CIA-62 | BRL-CAD: only contributor was '[[Special:Contributions/173.208.56.140|173.208.56.140]]') |
| 03:04.11 | CIA-62 | BRL-CAD: 03173.208.101.9 07http://brlcad.org * r3114 10/wiki/At_T_must_have_constructed_lines_all_over_my_house_because_I_now_have_service_3: New page: [[Image:social_bookmarking_service_2703.jpg|thumb|]] Web 2.0 tools can connect your scholars along with assets around the globe. Web 2.0 explains the proceed toward collaborative, shared... |
| 03:05.04 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.101.9]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 03:05.15 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 03:05.15 | CIA-62 | BRL-CAD: deleted "[[At T must have constructed lines all over my house because I now have |
| 03:05.15 | CIA-62 | BRL-CAD: service 3]]": content was: |
| 03:05.15 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_2703.jpg|thumb|]]Web 2.0 tools can connect |
| 03:05.16 | CIA-62 | BRL-CAD: your scholars along with assets around the globe.Web 2.0 explains th...' (and |
| 03:05.16 | CIA-62 | BRL-CAD: the only contributor was |
| 03:05.17 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.208.101.9|173.208.101.9]]') |
| 03:07.59 | starseeker | brlcad: is there some magic wand that needs to be waved to stop the crapstorm? |
| 03:22.37 | CIA-62 | BRL-CAD: 03173.234.244.30 07http://www.solidgeometry.org * r3115 10/wiki/Yeah_with_the_invention_about_social_networking_that_s_an_easy_feat_Lol_73: New page: [[Image:social_bookmarking_service_3389.jpg|thumb|]] Label the website with keywords to help other consumers identify thems content. Directions 1 Warning increase with some [http://leas... |
| 03:23.56 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.244.30]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 03:24.18 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 03:24.18 | CIA-62 | BRL-CAD: deleted "[[Yeah with the invention about social networking that s an easy feat |
| 03:24.18 | CIA-62 | BRL-CAD: Lol 73]]": content was: |
| 03:24.18 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_3389.jpg|thumb|]]Label the website with |
| 03:24.18 | CIA-62 | BRL-CAD: keywords to help other consumers identify thems content.Directions1 W...' (and |
| 03:24.18 | CIA-62 | BRL-CAD: the only contributor was |
| 03:24.19 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.234.244.30|173.234.244.30]]') |
| 03:33.39 | CIA-62 | BRL-CAD: 03173.208.41.35 07http://ist.brlcad.org * r3116 10/wiki/Red_social_96: New page: [[Image:social_bookmarking_service_2017.jpg|thumb|]] While checking your regular website metrics with Google Analytics, you might be happy to reveal that someone has shared some link to y... |
| 03:34.08 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.41.35]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 03:34.17 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 03:34.17 | CIA-62 | BRL-CAD: deleted "[[Red social 96]]": content was: |
| 03:34.17 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_2017.jpg|thumb|]]While checking your regular |
| 03:34.17 | CIA-62 | BRL-CAD: website metrics with Google Analytics, you might be happy to reveal ...' (and |
| 03:34.18 | CIA-62 | BRL-CAD: the only contributor was |
| 03:34.18 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.208.41.35|173.208.41.35]]') |
| 03:36.20 | CIA-62 | BRL-CAD: 03173.208.50.128 07http://brlcad.org * r3117 10/wiki/Vou_sair_aqui_e_ter_uma_vida_social_55: New page: [[Image:social_bookmarking_service_2071.jpg|thumb|]] Tasty is some [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that is permits users to share links on the w... |
| 03:36.48 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.50.128]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 03:36.58 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 03:36.58 | CIA-62 | BRL-CAD: deleted "[[Vou sair aqui e ter uma vida social 55]]": content was: |
| 03:36.58 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_2071.jpg|thumb|]]Tasty is some |
| 03:36.58 | CIA-62 | BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that |
| 03:36.59 | CIA-62 | BRL-CAD: is...' (and the only contributor was |
| 03:36.59 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.208.50.128|173.208.50.128]]') |
| 03:37.40 | starseeker | can't figure out how the heck to disable automatic posting on the wiki... |
| 03:50.50 | CIA-62 | BRL-CAD: 03173.208.40.36 07http://ist.brlcad.org * r3118 10/wiki/Esse_joguinho_The_Sims_Social_do_facebook_esta_me_irritando_j%C3%A1_D_16: New page: [[Image:social_bookmarking_service_4382.jpg|thumb|]] StumbleUpon yous a [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that lets you scan by means of random we... |
| 03:52.45 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.40.36]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 03:52.58 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 03:52.58 | CIA-62 | BRL-CAD: deleted "[[Esse joguinho The Sims Social do facebook esta me irritando j?? D |
| 03:52.58 | CIA-62 | BRL-CAD: 16]]": content was: |
| 03:52.58 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_4382.jpg|thumb|]]StumbleUpon yous a |
| 03:52.59 | CIA-62 | BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] |
| 03:52.59 | CIA-62 | BRL-CAD: th...' (and the only contributor was |
| 03:53.00 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.208.40.36|173.208.40.36]]') |
| 03:53.31 | starseeker | hmm, interesting article: http://www.devtopics.com/programmer-productivity-the-tenfinity-factor/ |
| 03:54.56 | CIA-62 | BRL-CAD: 03173.234.245.28 07http://bz.brlcad.org * r3119 10/wiki/It_s_vintage_social_networking_bro_H_16: New page: [[Image:social_bookmarking_service_1825.jpg|thumb|]] Tag the website in keywords to support other buyers identify its content. The social bookmarking phenomenon started on 1996 together ... |
| 03:55.26 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.245.28]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 03:55.46 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 03:55.46 | CIA-62 | BRL-CAD: deleted "[[It s vintage social networking bro H 16]]": content was: |
| 03:55.46 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_1825.jpg|thumb|]]Tag the website in keywords |
| 03:55.46 | CIA-62 | BRL-CAD: to support other buyers identify its content.The social bookmarkin...' (and the |
| 03:55.46 | CIA-62 | BRL-CAD: only contributor was '[[Special:Contributions/173.234.245.28|173.234.245.28]]') |
| 04:36.27 | abhi2011 | starseeker: nice article |
| 04:45.33 | CIA-62 | BRL-CAD: 03173.234.177.115 07http://brlcad.org * r3120 10/wiki/J%C3%A1_voltei_faz_tempo_me_distra%C3%AD_com_o_The_Sims_Social_85: New page: [[Image:social_bookmarking_service_5120.jpg|thumb|]] StumbleUpon can be one essential tool to improve your number of visitors. StumbleUpon yous a [http://lease-a-seo.com/social-bookmarki... |
| 04:58.11 | CIA-62 | BRL-CAD: 03173.234.127.10 07http://www.solidgeometry.org * r3121 10/wiki/To_resist_anything_yous_to_be_in_the_service_of_it_bashar_53: New page: [[Image:social_bookmarking_service_4981.jpg|thumb|]] Tasty yous any [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that is permits buyers to share links on the... |
| 04:59.05 | CIA-62 | BRL-CAD: 03173.234.174.28 07http://www.solidgeometry.org * r3122 10/wiki/I_have_this_reputation_of_being_this_promiscuous_non_committing_man_29: New page: [[Image:reputation_management_1051.jpg|thumb|]] Purchaser confidence plays any crucial rule with the success of any B2C company. Difficulty: Moderately Challenging Directions 1 Connect... |
| 05:03.10 | CIA-62 | BRL-CAD: 03173.234.158.36 07http://bz.brlcad.org * r3123 10/wiki/Have_I_become_anti_social_81: New page: [[Image:social_bookmarking_service_3704.jpg|thumb|]] Trouble: Moderately Easy Directions 1 Sign up with some [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] s... |
| 05:12.32 | CIA-62 | BRL-CAD: 03173.234.177.115 07http://ist.brlcad.org * r3124 10/wiki/Estou_mt_anti_social_D_20: New page: [[Image:social_bookmarking_service_676.jpg|thumb|]] Web 2.0 describes the proceed toward collaborative, shared, multimedia experiences on the Web. Specific sites, such because the wide op... |
| 05:28.42 | CIA-62 | BRL-CAD: 03starseeker * r46567 10/brlcad/trunk/CMakeLists.txt: |
| 05:28.42 | CIA-62 | BRL-CAD: Apparently a default VC 2010 Express install doesn't have all the |
| 05:28.42 | CIA-62 | BRL-CAD: redistributable dlls CMake is looking for - do as CMake does, suppress the |
| 05:28.42 | CIA-62 | BRL-CAD: (rather verbose) messages. This may need more investigation, not clear if a |
| 05:28.42 | CIA-62 | BRL-CAD: valid NSIS installer can be made as-is. |
| 05:35.08 | CIA-62 | BRL-CAD: 03173.234.120.97 07http://www.solidgeometry.org * r3125 10/wiki/Yeah_if_you_want_shitty_service_and_shitty_burgers_95: New page: [[Image:social_bookmarking_service_2822.jpg|thumb|]] StumbleUpon remains a [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] with users to discover new web site b... |
| 05:43.30 | CIA-62 | BRL-CAD: 03173.234.167.21 07http://ist.brlcad.org * r3126 10/wiki/I_m_only_social_at_concerts_84: New page: [[Image:social_bookmarking_service_2486.jpg|thumb|]] Web 2.0 tools can connect your students together with means around the world. Web 2.0 describes the move toward cooperative, shared, ... |
| 06:10.33 | CIA-62 | BRL-CAD: 03173.234.126.69 07http://brlcad.org * r3127 10/wiki/U_sang_well_worship_service_81: New page: [[Image:social_bookmarking_service_3180.jpg|thumb|]] StumbleUpon is some [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that is lets you browse via random web ... |
| 06:11.05 | starseeker | woo hoo - early testing suggests that the windows version of xsltproc will work! |
| 06:31.39 | CIA-62 | BRL-CAD: 0364.120.39.21 07http://www.solidgeometry.org * r3128 10/wiki/Listening_music_to_and_watching_the_social_network_17: New page: [[Image:social_bookmarking_service_2049.jpg|thumb|]] StumbleUpon yous any [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that lets you browse via random websit... |
| 06:32.00 | CIA-62 | BRL-CAD: 03173.208.100.10 07http://bz.brlcad.org * r3129 10/wiki/I_barely_have_service_in_here_64: New page: [[Image:social_bookmarking_service_5522.jpg|thumb|]] StumbleUpon is some [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] with owners to learn new internet site ... |
| 06:39.31 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 06:41.55 | CIA-62 | BRL-CAD: 0364.120.39.21 07http://ist.brlcad.org * r3130 10/wiki/Yeah_with_the_invention_of_social_networking_that_s_an_easy_feat_Lol_10: New page: [[Image:social_bookmarking_service_1937.jpg|thumb|]] StumbleUpon is a [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that is allows you browse by means of rand... |
| 06:43.35 | starseeker | http://bzflag.bz/~starseeker/archer_win32_native_built_docs.png |
| 06:47.47 | CIA-62 | BRL-CAD: 03173.234.158.36 07http://bz.brlcad.org * r3131 10/wiki/No_shoes_no_shirt_and_I_still_get_service_87: New page: [[Image:social_bookmarking_service_3631.jpg|thumb|]] StumbleUpon is some [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] for users to uncover new internet site ... |
| 07:06.18 | CIA-62 | BRL-CAD: 03173.234.177.115 07http://brlcad.org * r3132 10/wiki/Social_life_has_plummeted_sgoingon_2: New page: [[Image:social_bookmarking_service_4197.jpg|thumb|]] Web 2.0 tools may connect your students by resources around the globe. Web 2.0 explains the progress toward cooperative, shared, mult... |
| 07:21.54 | CIA-62 | BRL-CAD: 03173.234.159.17 07http://ist.brlcad.org * r3133 10/wiki/Benefits_of_Using_an_Attorney_Answering_Service_40: New page: [[Image:social_bookmarking_service_3324.jpg|thumb|]] Web 2.0 gear may connect your students by resources all over the world. Web 2.0 describes the proceed toward collaborative, shared, m... |
| 07:22.53 | CIA-62 | BRL-CAD: 03173.234.126.69 07http://brlcad.org * r3134 10/wiki/I_swear_my_parents_will_be_the_death_of_me_also_my_social_life_17: New page: [[Image:social_bookmarking_service_2312.jpg|thumb|]] Toothsome remains any [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that allows buyers to share links on ... |
| 07:28.58 | CIA-62 | BRL-CAD: 03173.234.122.130 07http://www.solidgeometry.org * r3135 10/wiki/Went_to_a_church_service_today_21: New page: [[Image:social_bookmarking_service_3486.jpg|thumb|]] Difficulty: Reasonable 1 Authorize scholars to utilize Web 2.0 social networking gear like because Facebook, Twitter and YouTube to f... |
| 07:55.54 | CIA-62 | BRL-CAD: 0364.120.116.42 07http://bz.brlcad.org * r3136 10/wiki/Who_would_have_thought_bookmarking_now_Thanks_76: New page: [[Image:social_bookmarking_service_1481.jpg|thumb|]] StumbleUpon is a [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that is lets you scan by means of random i... |
| 08:10.47 | CIA-62 | BRL-CAD: 03173.234.142.127 07http://bz.brlcad.org * r3137 10/wiki/Excellent_article_worth_bookmarking_2: New page: [[Image:social_bookmarking_service_2937.jpg|thumb|]] Difficulty: Moderate Directions 1 Allow scholars to make use of Web 2.0 social networking gear such as Facebook, Twitter plus YouTub... |
| 08:24.34 | CIA-62 | BRL-CAD: 0364.120.116.42 07http://www.solidgeometry.org * r3138 10/wiki/Lol_ppl_alway_making_up_stupid_shit_for_social_networks_its_lame_af_1: New page: [[Image:social_bookmarking_service_2855.jpg|thumb|]] Whilst checking your everyday internet site metrics in Google Analytics, you might be delighted to find that someone has shared some l... |
| 09:35.53 | CIA-62 | BRL-CAD: 03173.208.70.163 07http://brlcad.org * r3139 10/wiki/Gotta_love_when_your_friends_fahk_with_your_public_networks_39: New page: [[Image:social_bookmarking_service_1624.jpg|thumb|]] StumbleUpon is a [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] for users to find new websites based on th... |
| 10:16.06 | plaes | there was spam added to bz.brlcad.org mainpage: http://bz.brlcad.org/w/index.php?title=Main_Page&oldid=3034 |
| 10:19.07 | plaes | well, this user: http://bz.brlcad.org/wiki/Special:Contributions/Martinpaul |
| 11:23.06 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 11:42.22 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 12:15.45 | CIA-62 | BRL-CAD: 03173.234.174.28 07http://bz.brlcad.org * r3140 10/wiki/There_administration_picked_fans_to_spend_the_day_with_1Dx_98: New page: [[Image:reputation_management_2361.jpg|thumb|]] One estimated 57 percent regarding adults use seek out engines to find information on themeselves, according to a Pew Research Center revie... |
| 12:33.35 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 14:51.27 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.177.115]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 14:52.32 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 14:52.33 | CIA-62 | BRL-CAD: deleted "[[J?? voltei faz tempo me distra?? com o The Sims Social 85]]": content |
| 14:52.33 | CIA-62 | BRL-CAD: was: '[[Image:social_bookmarking_service_5120.jpg|thumb|]]StumbleUpon can be one |
| 14:52.33 | CIA-62 | BRL-CAD: essential tool to improve your number of visitors.StumbleUpon yous a [h...' (and |
| 14:52.33 | CIA-62 | BRL-CAD: the only contributor was |
| 14:52.33 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.234.177.115|173.234.177.115]]') |
| 14:54.04 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.127.10]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 14:54.17 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.174.28]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 14:54.34 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 14:54.34 | CIA-62 | BRL-CAD: deleted "[[To resist anything yous to be in the service of it bashar 53]]": |
| 14:54.34 | CIA-62 | BRL-CAD: content was: '[[Image:social_bookmarking_service_4981.jpg|thumb|]]Tasty yous any |
| 14:54.34 | CIA-62 | BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that |
| 14:54.35 | CIA-62 | BRL-CAD: i...' (and the only contributor was |
| 14:54.35 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.234.127.10|173.234.127.10]]') |
| 14:54.42 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 14:54.42 | CIA-62 | BRL-CAD: deleted "[[I have this reputation of being this promiscuous non committing man |
| 14:54.42 | CIA-62 | BRL-CAD: 29]]": content was: '[[Image:reputation_management_1051.jpg|thumb|]]Purchaser |
| 14:54.42 | CIA-62 | BRL-CAD: confidence plays any crucial rule with the success of any B2C |
| 14:54.43 | CIA-62 | BRL-CAD: company.Difficulty:Moderat...' (and the only contributor was |
| 14:54.43 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.234.174.28|173.234.174.28]]') |
| 14:56.42 | brlcad | plaes: thanks |
| 14:57.08 | brlcad | looks like there's some new mediawiki attack vector working |
| 14:57.52 | starseeker | brlcad: should I keep scrubbing? |
| 14:59.53 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.158.36]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 15:00.33 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.167.21]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 15:01.09 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.120.97]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 15:01.38 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 15:01.38 | CIA-62 | BRL-CAD: deleted "[[I m only social at concerts 84]]": content was: |
| 15:01.38 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_2486.jpg|thumb|]]Web 2.0 tools can connect |
| 15:01.38 | CIA-62 | BRL-CAD: your students together with means around the world.Web 2.0 describes...' (and |
| 15:01.39 | CIA-62 | BRL-CAD: the only contributor was |
| 15:01.39 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.234.167.21|173.234.167.21]]') |
| 15:02.21 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 15:02.21 | CIA-62 | BRL-CAD: deleted "[[Yeah if you want shitty service and shitty burgers 95]]": content |
| 15:02.21 | CIA-62 | BRL-CAD: was: '[[Image:social_bookmarking_service_2822.jpg|thumb|]]StumbleUpon remains a |
| 15:02.21 | CIA-62 | BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service]...' |
| 15:02.21 | CIA-62 | BRL-CAD: (and the only contributor was |
| 15:02.21 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.234.120.97|173.234.120.97]]') |
| 15:02.22 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 15:02.22 | CIA-62 | BRL-CAD: deleted "[[Estou mt anti social D 20]]": content was: |
| 15:02.23 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_676.jpg|thumb|]]Web 2.0 describes the |
| 15:02.23 | CIA-62 | BRL-CAD: proceed toward collaborative, shared, multimedia experiences on the Web. Sp...' |
| 15:02.24 | CIA-62 | BRL-CAD: (and the only contributor was |
| 15:02.24 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.234.177.115|173.234.177.115]]') |
| 15:02.44 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 15:02.45 | CIA-62 | BRL-CAD: deleted "[[Have I become anti social 81]]": content was: |
| 15:02.45 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_3704.jpg|thumb|]]Trouble:Moderately |
| 15:02.45 | CIA-62 | BRL-CAD: EasyDirections1 Sign up with some [http://lease-a-seo.com/social-bookmar...' |
| 15:02.45 | CIA-62 | BRL-CAD: (and the only contributor was |
| 15:02.45 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.234.158.36|173.234.158.36]]') |
| 15:04.13 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.126.69]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 15:04.27 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:64.120.39.21]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 15:04.34 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.100.10]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 15:04.46 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.159.17]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 15:04.49 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.122.130]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 15:05.02 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:64.120.116.42]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 15:05.46 | archivist | starseeker, front page has spam |
| 15:05.59 | starseeker | archivist: working on it - I don't really know what I'm doing |
| 15:06.20 | starseeker | is not skilled in mediawiki, but crapflood was too severe, so I'm trying |
| 15:06.36 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.142.127]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 15:06.51 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.70.163]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 15:08.02 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 15:08.02 | CIA-62 | BRL-CAD: deleted "[[U sang well worship service 81]]": content was: |
| 15:08.02 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_3180.jpg|thumb|]]StumbleUpon is some |
| 15:08.02 | CIA-62 | BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] t...' |
| 15:08.02 | CIA-62 | BRL-CAD: (and the only contributor was |
| 15:08.03 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.234.126.69|173.234.126.69]]') |
| 15:08.05 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 15:08.05 | CIA-62 | BRL-CAD: deleted "[[Listening music to and watching the social network 17]]": content |
| 15:08.05 | CIA-62 | BRL-CAD: was: '[[Image:social_bookmarking_service_2049.jpg|thumb|]]StumbleUpon yous any |
| 15:08.05 | CIA-62 | BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] ...' |
| 15:08.06 | CIA-62 | BRL-CAD: (and the only contributor was |
| 15:08.06 | CIA-62 | BRL-CAD: '[[Special:Contributions/64.120.39.21|64.120.39.21]]') |
| 15:08.07 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 15:08.07 | CIA-62 | BRL-CAD: deleted "[[I barely have service in here 64]]": content was: |
| 15:08.08 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_5522.jpg|thumb|]]StumbleUpon is some |
| 15:08.23 | CIA-62 | BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] f...' |
| 15:08.23 | CIA-62 | BRL-CAD: (and the only contributor was |
| 15:08.23 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.234.158.36|173.234.158.36]]') |
| 15:08.23 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 15:08.23 | CIA-62 | BRL-CAD: deleted "[[Social life has plummeted sgoingon 2]]": content was: |
| 15:08.24 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_4197.jpg|thumb|]]Web 2.0 tools may connect |
| 15:08.24 | CIA-62 | BRL-CAD: your students by resources around the globe.Web 2.0 explains the pro...' (and |
| 15:08.25 | CIA-62 | BRL-CAD: the only contributor was |
| 15:08.25 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.234.177.115|173.234.177.115]]') |
| 15:08.26 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 15:08.26 | CIA-62 | BRL-CAD: deleted "[[Benefits of Using an Attorney Answering Service 40]]": content was: |
| 15:08.52 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_3324.jpg|thumb|]]Web 2.0 gear may connect |
| 15:08.52 | CIA-62 | BRL-CAD: your students by resources all over the world.Web 2.0 describes the p...' (and |
| 15:08.52 | CIA-62 | BRL-CAD: the only contributor was |
| 15:08.52 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.234.159.17|173.234.159.17]]') |
| 15:08.53 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 15:08.53 | CIA-62 | BRL-CAD: deleted "[[I swear my parents will be the death of me also my social life 17]]": |
| 15:08.54 | CIA-62 | BRL-CAD: content was: '[[Image:social_bookmarking_service_2312.jpg|thumb|]]Toothsome |
| 15:08.54 | CIA-62 | BRL-CAD: remains any [http://lease-a-seo.com/social-bookmarking.php social bookmarking |
| 15:08.55 | CIA-62 | BRL-CAD: service]...' (and the only contributor was |
| 15:08.55 | CIA-62 | BRL-CAD: '[[Special:Contributions/173.234.126.69|173.234.126.69]]') |
| 15:08.56 | CIA-62 | (12 lines omitted) |
| 15:08.57 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: |
| 15:08.57 | CIA-62 | BRL-CAD: deleted "[[Excellent article worth bookmarking 2]]": content was: |
| 15:08.58 | CIA-62 | BRL-CAD: '[[Image:social_bookmarking_service_2937.jpg|thumb|]]Difficulty:ModerateDirections1 |
| 15:08.58 | CIA-62 | BRL-CAD: Allow scholars to make use of Web 2.0 social networking gear...' (and the only |
| 15:08.59 | CIA-62 | BRL-CAD: contributor was '[[Special:Contributions/173.234.142.127|173.234.142.127]]') |
| 15:11.07 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r3141 10/wiki/Main_Page: Undo revision 3084 by [[Special:Contributions/Jimblack|Jimblack]] ([[User talk:Jimblack|Talk]]) - spamming |
| 15:11.36 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Jimblack]] with an expiry time of infinite (account creation disabled): Spamming links to external sites |
| 15:16.49 | brlcad | starseeker: looks like you're doing just fine to me ... :) |
| 15:17.01 | brlcad | block the ip/user and delete the page is all there is to it |
| 15:17.17 | starseeker | the interface I'm using absolutely sucks - need a "batch delete" UI |
| 15:17.27 | brlcad | I sometimes try to remember to clear out the "comment" when deleting the page so the spam doesn't get repeated |
| 15:17.34 | starseeker | ah, sorry |
| 15:17.39 | brlcad | there probably is a MW module for that |
| 15:17.55 | brlcad | sometimes I don't remember, no big deal either way |
| 15:18.15 | starseeker | on a more positive note, the windows xsltproc succeeds in building our docs |
| 15:18.45 | brlcad | nods, good to know |
| 15:19.08 | starseeker | I don't suppose there's a mediawiki module that will let us reject posts based on regex matching of links? (sort of adblock for wikis?) |
| 15:19.24 | brlcad | probably is, there are hundreds of mw modules |
| 15:19.33 | brlcad | many many related to various blocking vectors |
| 15:20.11 | brlcad | i'm looking at fixing one issue now -- the problem is multiplied right now because multiple domain names are responding, going to fix that |
| 15:21.08 | starseeker | ah, so that's what the http://bz.brlcad.org links were about |
| 15:21.59 | starseeker | hmm... http://www.mediawiki.org/wiki/Extension:SpamBlacklist |
| 15:39.50 | brlcad | there, done |
| 15:42.32 | starseeker | brlcad: awesome, thanks! |
| 15:44.49 | brlcad | that's not going to stop the spam, though |
| 15:45.06 | starseeker | every little bit helps |
| 15:45.52 | starseeker | doesn't understand how they're getting by recaptcha |
| 15:46.05 | brlcad | we're already using a blacklist iirc, but haven't updated the list in a long while |
| 15:47.18 | brlcad | there's been news about spammers getting more clever |
| 15:47.46 | starseeker | growl |
| 15:47.51 | brlcad | coupling their software with other client software that pays people to answer prompts |
| 15:48.25 | brlcad | so the recaptcha is sent to some kid in india/china/wherever that gets paid something like 1cent per response |
| 15:48.46 | starseeker | yeesh |
| 15:49.34 | brlcad | on the upside, recaptcha's OCR processing is up 3000% :) |
| 15:49.41 | starseeker | hehe |
| 15:49.55 | starseeker | yeah, I guess there is that |
| 15:50.52 | starseeker | supposes if we're going to have to deal with spam, getting the world's public domain works OCR'ed for free is at least a little payback |
| 15:53.22 | starseeker | ah, poop. test is like search, uses globals. here we go again... |
| 15:58.04 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 16:24.44 | brlcad | is excited, got ahold of more than 100+ real .step files and about 25+ iges files |
| 16:25.12 | brlcad | starseeker: make the globals static |
| 16:25.28 | starseeker | is working on passing them around in a struct "properly" |
| 16:25.33 | brlcad | ah, k |
| 16:25.50 | starseeker | smaller code than search, so doable "relatively quickly" |
| 16:26.06 | starseeker | factering in my goober pointing skills, of course |
| 16:26.37 | starseeker | brlcad: holy cow, that's a lot of .step data |
| 16:30.44 | brlcad | yeah |
| 16:31.02 | brlcad | 2.2GB worth |
| 16:31.31 | brlcad | 900MB of iges |
| 16:34.41 | starseeker | O.o - does step-g work on any of it? |
| 16:34.52 | starseeker | or iges-g for that matter? |
| 16:35.09 | starseeker | (we really need to get the iges convertor making new NURBS, not old...) |
| 16:35.22 | brlcad | haven't tested |
| 16:35.30 | brlcad | spent most of yesterday downloading them all |
| 16:35.36 | starseeker | heh |
| 17:03.28 | starseeker | pokes CIA-62 |
| 17:14.27 | CIA-62 | BRL-CAD: 03starseeker * r46568 10/brlcad/trunk/src/libged/exists.c: will be bounding box routines and raytracing routines for volume eventually, so name accordingly. |
| 17:18.12 | CIA-62 | BRL-CAD: 03starseeker * r46569 10/brlcad/trunk/src/libged/exists.c: not hooked up or tested beyond 'it builds', and will need the specific test functions for each case implemented, but get the basic expression handling code building for exists. |
| 17:28.47 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 19:05.31 | CIA-62 | BRL-CAD: 03starseeker * r46570 10/brlcad/trunk/src/libged/exists.c: replace syntax calls with ged result string prints |
| 19:13.44 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 19:13.57 | jordisayol | hello |
| 19:14.30 | jordisayol | is there an schedule for the next brlcad release? |
| 19:35.37 | *** join/#brlcad merzo (~merzo@91-87-132-95.pool.ukrtel.net) | |
| 21:03.51 | CIA-62 | BRL-CAD: 03starseeker * r46571 10/brlcad/trunk/src/libged/exists.c: Get exists using the new code, although the only thing implemented at the moment is the db_lookup based call. |
| 21:10.28 | *** join/#brlcad merzo (~merzo@91-87-132-95.pool.ukrtel.net) | |
| 21:14.24 | CIA-62 | BRL-CAD: 03starseeker * r46572 10/brlcad/trunk/src/libged/exists.c: oops - managed to gut the and/or code by mistake. Start putting it back together, lot more to fix here probably. |
| 22:11.20 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 01:35.19 | CIA-62 | BRL-CAD: 03173.234.131.70 07http://brlcad.org * r3142 10/wiki/R_U_still_long_Gold_I_hope_so_48: New page: [[Image:Gold_Bullion_Silver_Coins_4919.jpg|thumb|]] If you are a coin collector with Florida, you may well want to portion with most of your collection at certain point. Whether you are a... |
| 01:54.56 | CIA-62 | BRL-CAD: 03173.208.19.167 07http://brlcad.org * r3143 10/wiki/SHAMROCKGOLD_64: New page: [[Image:Gold_Bullion_Silver_Coins_2957.jpg|thumb|]] Trouble: Moderately Easy Instructions 1 See what a gold bullion is. Gold bullion is any investment grade of gold that comes within s... |
| 02:06.53 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.131.70]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 02:07.03 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.19.167]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 02:07.15 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[R U still long Gold I hope so 48]]" |
| 02:07.24 | CIA-62 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[SHAMROCKGOLD 64]]" |
| 02:35.32 | CIA-62 | BRL-CAD: 03starseeker * r46573 10/brlcad/trunk/src/libged/exists.c: be smarter about how we handle a case without an explicit operation. |
| 03:11.06 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 03:28.41 | CIA-62 | BRL-CAD: 03starseeker * r46574 10/brlcad/trunk/src/libged/exists.c: |
| 03:28.41 | CIA-62 | BRL-CAD: Need to handle no-explicit-op tests elsewhere to be robust in multi-test cases. |
| 03:28.41 | CIA-62 | BRL-CAD: Got a couple returns flipped apparently - fixed to the point where 'exists |
| 03:28.41 | CIA-62 | BRL-CAD: obj1.s -a obj2.s' and 'exists obj1.s -o obj2.s' are returning what I would |
| 03:28.41 | CIA-62 | BRL-CAD: expect, but not sure yet if it's 'right' |
| 03:37.16 | CIA-62 | BRL-CAD: 03starseeker * r46575 10/brlcad/trunk/src/libged/exists.c: call out the need to keep the option tables sorted - it's 'implicit' in the use of bsearch but make it explicit in a comment for new coders who are wondering why a new option isn't working... |
| 04:28.02 | CIA-62 | BRL-CAD: 03starseeker * r46576 10/brlcad/trunk/src/libged/exists.c: reset t_wp_op for -o as well as -a. |
| 05:13.40 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 09:53.38 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 09:57.11 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 10:52.07 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 10:58.43 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) | |
| 11:30.22 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:19.47 | *** join/#brlcad juanman (~quassel@186.136.168.73) | |
| 13:19.54 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 15:03.49 | brlcad | yawns |
| 15:08.05 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:33.27 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 15:42.46 | *** join/#brlcad kunigami_ (~kunigami@187.106.4.105) | |
| 15:44.38 | brlcad | howdy kunigami_ |
| 15:46.37 | brlcad | kunigami: I'd like to pull together an announcement of your work and am looking to showcase some awesome imagery along with a brief writeup |
| 15:55.11 | brlcad | kunigami: so any thoughts you have on what might make a great demonstration or particular items to cover in the writeup would be appreciated :) |
| 16:01.20 | brlcad | on an unrelated thought, time to post a release! |
| 16:02.58 | brlcad | also unrelated, starseeker: curious cmake (make -j20) build failure in tcl .. fixed by just rerunning make -j20 again |
| 16:03.28 | brlcad | (this was a fresh clean out-of-dir build) |
| 17:12.55 | *** join/#brlcad kunigami_ (~kunigami@201.82.92.180) | |
| 17:29.24 | starseeker | um. xsltproc occasionally has a problem with massively parallel situations (I think it's an xsltproc bug) but I don't recall tcl failing |
| 18:43.59 | CIA-62 | BRL-CAD: 03n_reed * r46577 10/brlcad/trunk/src/conv/obj-g_new.c: Setting defaults so parser can be run without specifying options. |
| 18:50.10 | CIA-62 | BRL-CAD: 03starseeker * r46578 10/brlcad/trunk/src/libged/exists.c: tweak message handling for errors, null out t_wp_op for LPAREN |
| 19:04.59 | *** join/#brlcad merzo (~merzo@98-189-132-95.pool.ukrtel.net) | |
| 19:36.26 | CIA-62 | BRL-CAD: 03n_reed * r46579 10/brlcad/trunk/src/librt/primitives/poly/poly.c: Having rt_pg_to_bot use initialized memory for rt_bot_internal struct. |
| 19:49.30 | *** join/#brlcad kunigami1 (~kunigami@loco-gw.ic.unicamp.br) | |
| 22:33.18 | kunigami | brlcad: I'll try to prepare something tomorrow! BTW, I intend to keep on this project, at least one day a week |
| 23:21.14 | brlcad | kunigami: oh, that'd be awesome |
| 23:21.40 | starseeker | bhinesley: still around? :-P |
| 23:21.44 | brlcad | maybe something with a more complex model in a scene, something that really showcases the nice lighting |
| 23:22.39 | brlcad | n_reed: if you're interested, uploading a slew of nurbs obj files -- same dir as before: OBJ/NURBS |
| 23:23.34 | brlcad | it's about 60MB across a couple dozen examples |
| 23:25.01 | brlcad | s/couple dozen/18ish/ |
| 23:25.38 | brlcad | from what I can tell, it looks like rhino and blender are two common exports that will pump out nurbs obj |
| 23:32.40 | n_reed | brlcad: looks like the few defective outputs I saw in obj-g were just tolerance issues |
| 23:33.09 | n_reed | so I have no problem starting work on NURBS support |
| 23:40.52 | *** join/#brlcad Yoshi47 (~jan@d72-39-60-53.home1.cgocable.net) | |
| 23:43.25 | brlcad | n_reed: any way to handle the tolerance failures automatically? |
| 23:44.23 | brlcad | mm.. server migration priority just went up a notch .. all this new STEP data is too much for .bz |
| 00:05.56 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 00:14.18 | n_reed | brlcad: specifically the issue was that two inputs had outputs with unwanted holes in them |
| 00:14.55 | n_reed | problem should be that too few or too many points are being considered identical |
| 00:15.12 | n_reed | using meters as units (now the default) is enough to fix one of the cases |
| 00:15.28 | n_reed | fixing the other should require adjusting hte distance tolerance |
| 00:16.30 | n_reed | distance tolerance could be adjusted automatically, but i'm not sure it could be done smartly enough to work in every case |
| 00:26.10 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) | |
| 00:26.31 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 00:29.52 | *** join/#brlcad juanman (~quassel@201.255.47.86) | |
| 00:29.54 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 00:53.40 | bhinesley | starseeker: yep, I'm here |
| 00:53.57 | *** join/#brlcad kunigami (~kunigami@201.82.92.180) | |
| 01:11.43 | brlcad | bhinesley: same for your project too, ideas on how to characterize your summer work into a showcase piece? |
| 01:12.37 | brlcad | visuals are a bit less effective except for maybe a diagram |
| 01:13.26 | brlcad | easy enough to show how three commands now becomes just one, or a harder case where translating relative to something else turns 10+ steps into just one |
| 01:17.54 | brlcad | starseeker: I'm not too concerned about the cax-if at this point -- I considered going through the efforts to join them a while back anyways |
| 01:18.56 | brlcad | certainly not concerned about any of their data tainting the scl just because they don't even provide that kind of information |
| 01:29.08 | starseeker | cool |
| 01:54.18 | starseeker | ifcOpenShell is kinda interesting |
| 01:58.14 | *** join/#brlcad merzo (~merzo@98-189-132-95.pool.ukrtel.net) | |
| 04:01.23 | *** join/#brlcad DarkCalfz (DC@173.231.40.98) | |
| 04:23.32 | CIA-62 | BRL-CAD: 0378.8.106.10 07http://brlcad.org * r3144 10/wiki/User:78.8.106.10: New page: [http://www.williamhickswi.com williamhickswi] Hello, im williamhicksw |
| 04:43.56 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:78.8.106.10]] with an expiry time of infinite (anonymous users only, account creation disabled): Inserting nonsense/gibberish into pages |
| 04:44.05 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User:78.8.106.10]]": spam |
| 05:27.42 | *** join/#brlcad merzo (~merzo@32-92-132-95.pool.ukrtel.net) | |
| 05:32.23 | bhinesley | brlcad: the DESCRIPTION section of the "edit" man page was my attempt at summarizing what it's all about. |
| 05:32.26 | bhinesley | main concepts you could touch on: use of apparent positions of objects + offsets as references (particular/instance/of/obj 0 2.5 -5), ability to use those object references or actual coordinates interchangably in specifying any of the x/y/z coordinates, performing batch operations (i.e. perform a similar operation on each of *these*) |
| 05:32.31 | bhinesley | Examples 3 or 4 in the edit_translate manual are practical/interesting uses that show off several features at once. They're simple to understand, yet they would take many steps to perform by conventional means (true for many other modeling packages as well). They would be even harder to replicate if specific instances of objects were used, ex: |
| 05:32.36 | bhinesley | edit translate -k . -a -z C/D/E/F/G A/obj1 A/obj2 B/obj1 B/obj2 |
| 05:32.39 | bhinesley | (move each object instance from the elevation of their respective bb center to the elevation of the apparent bb_center of C/D/E/F/G; in other words, align them at the elevation that C/D/E/F/G is drawn) |
| 05:32.43 | bhinesley | besides requiring 4 sets of oed + translate + accept (12 steps) at a minimum, personally, I wouldn't even know how to accomplish the exact same task using other mged/libged commands. |
| 05:33.48 | bhinesley | btw, as shown in example 10, I'm not sure the -r option is strictly necessary since I added the ability to specify offsets with objects. Something to consider at least, assuming we'll refactor. |
| 05:34.27 | bhinesley | brlcad: hopefully that's the type of thing you were looking for, if not, let me know. |
| 07:49.19 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 08:32.13 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3145 10/wiki/User:Abhijit: /* Log */ |
| 12:58.52 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:15.30 | *** join/#brlcad kunigami (~kunigami@201.82.92.180) | |
| 13:35.01 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 13:46.09 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-186-184.wlan.tudelft.nl) | |
| 14:56.04 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:14.33 | CIA-62 | BRL-CAD: 03tbrowder2 * r46580 10/brlcad/trunk/sh/make_deb.sh: correct typo |
| 15:14.38 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 15:36.36 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 16:33.55 | brlcad | bhinesley: that might work -- I think part of the effort will involve actually characterizing one of the examples into what steps would need to be taken now, to drive that point home |
| 16:46.38 | CIA-62 | BRL-CAD: 03tbrowder2 * r46581 10/brlcad/trunk/sh/make_deb.sh: making a little more robust--allow for non-package utilities such as a locally installed cmake |
| 16:52.26 | brlcad | nifty for those that haven't seen it before: http://xlinux.nist.gov/dads/termsImpl.html |
| 18:10.34 | CIA-62 | BRL-CAD: 03brlcad * r46582 10/brlcad/trunk/src/tclscripts/lib/ (8 files): |
| 18:10.35 | CIA-62 | BRL-CAD: add deprecation warnings to the following widgets: Database, Db, Display, Dm, |
| 18:10.35 | CIA-62 | BRL-CAD: Drawable, Mged, QuadDisplay, and View. They are all supplanted by the newer Ged |
| 18:10.35 | CIA-62 | BRL-CAD: widget (which hooks to libtclcad for dm/fb/view bindings as well as libged |
| 18:10.35 | CIA-62 | BRL-CAD: commands). |
| 18:13.31 | CIA-62 | BRL-CAD: 03brlcad * r46583 10/brlcad/trunk/ (TODO doc/deprecation.txt): |
| 18:13.31 | CIA-62 | BRL-CAD: formally deprecate the old mged megawidget tcl infrastructure since there may be |
| 18:13.31 | CIA-62 | BRL-CAD: users out there using it. they were the precursor to archer, but now archer |
| 18:13.31 | CIA-62 | BRL-CAD: goes through a different Ged widget interface that binds to libtclcad. |
| 19:03.57 | CIA-62 | BRL-CAD: 03brlcad * r46584 10/brlcad/trunk/TODO: loadview can be better |
| 20:01.48 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 20:01.48 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 20:01.50 | jordisayol | brlcad: anyway, is there a way in SF to make as default download for an OS a directory instead a file? |
| 20:04.56 | jordisayol | brlcad: I've seen that, if I mark as default a 64 bit package, it was the most downloaded, but if I mark the 32 bit package as default, this is the most downloaded too!!! So the conclusion is, people clicks without read/think too much... |
| 20:05.43 | brlcad | jordisayol: not that I'm aware of, it's be a feature enhancement request |
| 20:06.15 | jordisayol | brlcad: ok, many thanks |
| 20:34.27 | CIA-62 | BRL-CAD: 03erikgreenwald * r46585 10/brlcad/trunk/src/libgcv/bottess.c: begin soup2bot(). Cleanup. |
| 20:39.11 | *** join/#brlcad merzo (~merzo@32-92-132-95.pool.ukrtel.net) | |
| 22:06.03 | *** join/#brlcad merzo (~merzo@32-92-132-95.pool.ukrtel.net) | |
| 22:40.04 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 22:43.43 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 22:53.54 | *** join/#brlcad Stattrav (~Stattrav@203.196.190.162) | |
| 22:53.54 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 23:02.27 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 00:59.23 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 05:37.48 | CIA-62 | BRL-CAD: 03brlcad * r46586 10/brlcad/trunk/include/fb.h: these macros aren't very safe. debugged a crash in rtxray related to dereferencing a null fbp. add a FIXME to turn them into proper functions. |
| 05:43.06 | CIA-62 | BRL-CAD: 03brlcad * r46587 10/brlcad/trunk/src/rt/viewxray.c: not sure how we're getting to this point, but prevent fb_write() from crashing if fbp is NULL. |
| 06:00.12 | CIA-62 | BRL-CAD: 03brlcad * r46588 10/brlcad/trunk/ (BUGS src/rt/do.c): rtxray crashes if you specify rtxray -o any.bw output file as there are assumptions in the rtuif front-end that assume output will be a pix file. |
| 06:06.21 | *** join/#brlcad merzo (~merzo@244-11-133-95.pool.ukrtel.net) | |
| 06:24.45 | CIA-62 | BRL-CAD: 03brlcad * r46589 10/brlcad/trunk/TODO: noticed some issues with pixdiff. doesn't handle bw input correctly and default output is misleading (and sometimes wrong). |
| 11:37.10 | CIA-62 | BRL-CAD: 0391.198.94.86 07http://brlcad.org * r3146 10/wiki/User:91.198.94.86: New page: [http://www.williamhickswi.com williamhickswi] Hello, im williamhickswi |
| 11:59.36 | CIA-62 | BRL-CAD: 0391.198.94.86 07http://brlcad.org * r3147 10/wiki/User_talk:91.198.94.86: New page: [http://www.williamhickswi.com williamhickswi] Hello, im williamhickswi |
| 12:46.21 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User:91.198.94.86]]" |
| 12:46.35 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:91.198.94.86]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 12:47.09 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User talk:91.198.94.86]]" |
| 13:09.19 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 13:09.32 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 13:46.53 | CIA-62 | BRL-CAD: 03109.230.251.132 07http://brlcad.org * r3148 10/wiki/Wiki_syntax_explained: New page: Guide for writing by using wiki syntax will follow [http://www.mediawiki.com Official Mediawiki Site] |
| 14:01.42 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Wiki syntax explained]]": probing |
| 14:01.56 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:109.230.251.132]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 14:02.17 | brlcad | we're going to have to do something about that soon ... |
| 14:34.31 | CIA-62 | BRL-CAD: 03erikgreenwald * r46590 10/brlcad/trunk/src/libged/Makefile.am: reflect that the bullet integration stuff has moved into a simulate/ subdir |
| 14:42.20 | CIA-62 | BRL-CAD: 03erikgreenwald * r46591 10/brlcad/trunk/src/conv/intaval/Makefile.am: need both and , or libtcl won't be found |
| 14:43.56 | CIA-62 | BRL-CAD: 03erikgreenwald * r46592 10/brlcad/trunk/src/libged/Makefile.am: add exists.c |
| 14:44.13 | ``Erik | huh, vim ate ${WDB} and ${WDB_LIBS} on that commit, whups |
| 14:46.34 | CIA-62 | BRL-CAD: 03erikgreenwald * r46593 10/brlcad/trunk/ (bench/Makefile.am src/gtools/beset/Makefile.am): add _LIBS for libtcl link |
| 14:50.59 | brlcad | ``Erik: cool, you testing autotools build on bsd? |
| 14:51.26 | ``Erik | I'm using fbsd for autogen, but linux for the build |
| 14:51.48 | brlcad | k |
| 14:51.53 | ``Erik | rweiss complained that he wasn't updating because it's "always broken", we steered him to installing cmake |
| 14:52.32 | ``Erik | (our autoconf has gotten gamey over detecting system tcl correctly, but it's not worth the effort with deprecation in effect) |
| 14:52.33 | brlcad | if it's "always broken" for him, then he's doing something wrong |
| 14:53.01 | ``Erik | infrequent updates + wrong build system? :) |
| 14:53.18 | brlcad | calls BS |
| 14:53.31 | ``Erik | but I got a complete build on rhel5/x86_64 *shrug* |
| 14:53.37 | brlcad | the build system should work, especially if he updates infrequently :) |
| 14:54.00 | brlcad | either way, I only care because I want to tag release |
| 14:54.25 | brlcad | did/can you check if autotools distchecks clean? |
| 14:54.38 | ``Erik | running |
| 14:54.41 | brlcad | cool |
| 14:54.47 | ``Erik | and a fail |
| 14:55.10 | brlcad | when that passes, i'll do a mac build test and sync stable |
| 14:56.23 | CIA-62 | BRL-CAD: 03erikgreenwald * r46594 10/brlcad/trunk/include/Makefile.am: config_win_cmake.h went back to having a .in suffix |
| 15:02.36 | CIA-62 | BRL-CAD: 03erikgreenwald * r46595 10/brlcad/trunk/src/other/libz/Makefile.am: remove nonexistant header |
| 15:09.46 | starseeker | jabs CIA-62 |
| 15:10.13 | starseeker | brlcad: I think I fixed the togl build to not aways rebuild every time cmake is run |
| 15:14.15 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 15:14.15 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 15:14.21 | ``Erik | neat, http://paste.lisp.org/display/124557 I don't know what exactly to do about that |
| 15:15.02 | starseeker | winces |
| 15:15.13 | starseeker | that's that new plugin stuff I put in for libged |
| 15:15.46 | ``Erik | sh/cmakecheck.sh |
| 15:16.18 | starseeker | nods - not sure what to do about it either |
| 15:16.18 | *** join/#brlcad CIA-133 (~CIA@cia.atheme.org) | |
| 15:24.00 | CIA-133 | BRL-CAD: 03starseeker * r46598 10/brlcad/trunk/src/other/tktable/CMakeLists.txt: Same deal for tktable - only rebuild if something actually changes. |
| 15:27.31 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:30.29 | CIA-133 | BRL-CAD: 03starseeker * r46599 10/brlcad/trunk/src/other/togl/src/CMakeLists.txt: Generating message is a bit messy for togl stubs, go simple. |
| 15:42.56 | CIA-133 | BRL-CAD: 03erikgreenwald * r46600 10/brlcad/trunk/src/libged/ (4 files in 3 dirs): |
| 15:42.57 | CIA-133 | BRL-CAD: Hoise subdir build information for CMake build. While the subdir CMake stuff |
| 15:42.57 | CIA-133 | BRL-CAD: does work, it causes sh/cmakecheck.sh to fail in automakes dist-hook. Once |
| 15:42.57 | CIA-133 | BRL-CAD: automake is completely removed, we may decide to move the cmake build logic back |
| 15:42.57 | CIA-133 | BRL-CAD: into the subdirs. |
| 15:43.09 | ``Erik | hoist, even |
| 15:43.56 | CIA-133 | BRL-CAD: 03erikgreenwald * r46601 10/brlcad/trunk/misc/Makefile.am: update to reflect numerous changes in CMake/ |
| 15:46.49 | ``Erik | dist succeeds, doing the subdir build right now |
| 15:48.10 | starseeker | brlcad: I think for the remainder of the issues (relinking everything because we're updating the count) we're looking at something along these lines: http://cmake.org/Bug/view.php?id=8655 |
| 15:48.38 | CIA-133 | BRL-CAD: 03starseeker * r46602 10/brlcad/trunk/src/libged/CMakeLists.txt: move the macro to the top to avoid an undefined macro error. |
| 16:03.57 | CIA-133 | BRL-CAD: 03erikgreenwald * r46603 10/brlcad/trunk/src/other/Makefile.am: add missing files to EXTRA_DIST |
| 16:09.08 | starseeker | cmake looking ok here - make regress just passed (gentoo) |
| 16:30.17 | CIA-133 | BRL-CAD: 03erikgreenwald * r46604 10/brlcad/trunk/src/other/Makefile.am: add OSL files |
| 16:32.41 | CIA-133 | BRL-CAD: 03erikgreenwald * r46605 10/brlcad/trunk/src/other/incrTcl/ (itcl/Makefile.am itk/Makefile.am): add ac_std_funcs.cmake |
| 16:40.06 | CIA-133 | BRL-CAD: 03erikgreenwald * r46606 10/brlcad/trunk/src/adrt/Makefile.am: add isst.bat to EXTRA_DIST |
| 17:03.03 | CIA-133 | BRL-CAD: 03erikgreenwald * r46607 10/brlcad/trunk/src/fbed/ (CMakeLists.txt sgi_dep.c): eliminate sgi_dep.c |
| 17:09.24 | CIA-133 | BRL-CAD: 03erikgreenwald * r46608 10/brlcad/trunk/src/tclscripts/archer/Makefile.am: add PipeEditFrame.tcl |
| 17:17.38 | CIA-133 | BRL-CAD: 03erikgreenwald * r46609 10/brlcad/trunk/db/ (4 files): convert cornell-kunigami from .g to .asc with build rules |
| 17:27.42 | CIA-133 | BRL-CAD: 03erikgreenwald * r46610 10/brlcad/trunk/doc/docbook/system/mann/en/Makefile.am: add exists.xml |
| 17:35.52 | CIA-133 | BRL-CAD: 03erikgreenwald * r46611 10/brlcad/trunk/misc/Makefile.am: add Doxyfile.in |
| 17:41.10 | CIA-133 | BRL-CAD: 03erikgreenwald * r46612 10/brlcad/trunk/Makefile.am: add configure.cmake.sh |
| 17:43.29 | ``Erik | I think that's all done O.o |
| 17:43.45 | ``Erik | first time we've been able to do a cmake build from an automake dist generated tarball, to boot |
| 17:59.06 | starseeker | awesome |
| 18:05.34 | brlcad | excellent |
| 18:06.17 | brlcad | so was the previous source dist from an autotools make dist? there was a post to the help forum about missing isst.bat in 7.20.2 |
| 18:06.31 | brlcad | I thought 7.20.2 was a cmake dist |
| 18:40.03 | starseeker | I don't think so - IIRC, that might have been before we sorted out the zlib header thing |
| 18:53.19 | ``Erik | from the saved timestamps in the tarball, I'd assume something like (svn co ... brlcad-7.20.2 && find brlcad-7.20.2 -name '\.svn' -exec rm "{}"\; && (cd brlcad-7.20.2 && sh autogen.sh) && tar zcvf brlcad.7.20.2.tar.gz brlcad-7.20.2) |
| 18:54.03 | ``Erik | (mebbe with a -r to the rm and various fixes like that...) |
| 19:05.56 | CIA-133 | BRL-CAD: 03starseeker * r46613 10/brlcad/trunk/ (4 files in 2 dirs): (log message trimmed) |
| 19:05.56 | CIA-133 | BRL-CAD: Take some steps to mitigate the 'relink everything every cmake run' issue. Use |
| 19:05.56 | CIA-133 | BRL-CAD: the build types to decide whether we want to increment COUNT - only do so when |
| 19:05.56 | CIA-133 | BRL-CAD: we're doing a build configuration other than Debug, since it's those cases where |
| 19:05.56 | CIA-133 | BRL-CAD: we might be concerned how many times CMake has been run. Also change the way |
| 19:05.56 | CIA-133 | BRL-CAD: we're getting the timestamp (DATE) in Debug configurations - old method gave the |
| 19:05.57 | CIA-133 | BRL-CAD: to-the-second ascii string conversion that's standard in C. For Debug cases, |
| 19:25.13 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 19:25.13 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 19:35.11 | brlcad | not sure that's entirely true |
| 19:35.49 | brlcad | if someone's build debug 10 times then release 1, count will be 1 and that's not useful |
| 19:36.31 | brlcad | one of the critical things the count conveys is "this is not the first/only time a build was performed on this checkout" |
| 19:38.14 | brlcad | the other is that this is the Nth attempt where a large N indicates a build from a particularly active checkout, small N but non-1 indicating that maybe a few tweak passes/rebuilds (maybe cause for concern), and N=1 .. pristine checkout/build/install |
| 19:39.15 | brlcad | whines that scripting maths is hard |
| 19:42.00 | starseeker | what about counting in a non-included file in debug, and then adding in the result of that (if present) when switching to release? |
| 19:48.46 | brlcad | hm, doesn't sound like it's worth having that kind of specific logic around, almost seems better to just incr on every cmake like it was and let it relink because it's simple |
| 19:49.17 | starseeker | don't think it's hard - there was some positive developer response here to the idea of avoiding relinking |
| 19:49.19 | brlcad | the benefit was really only if it was easy enough to detect a config change |
| 19:49.29 | starseeker | give me a sec... |
| 19:49.39 | brlcad | not that it's hard or not |
| 19:50.04 | brlcad | that it sounds like the type of quirky logic that one looks back at in a few years and wonders, wtf, right before ripping it out |
| 19:50.04 | starseeker | brlcad: it's got to be worth avoiding relinking 100+ executables |
| 19:50.33 | brlcad | is it not feasible to do your earlier idea? |
| 19:50.40 | starseeker | which earlier idea? |
| 19:51.05 | brlcad | you'd mentioned being able to detect that something in the config changed, incrementing then |
| 19:51.21 | brlcad | like saving the previous cache or detecting a cache change or similar |
| 19:51.56 | starseeker | the problem is, the headers DO change each time you run config if you increment COUNT |
| 19:51.57 | brlcad | i don't recall the exact mechanism you had in mind, it was getting late |
| 19:52.02 | starseeker | count is included in the headers |
| 19:52.09 | brlcad | riiight |
| 19:52.14 | starseeker | if the COUNT file changes, relinking is guaranteed |
| 19:52.22 | brlcad | yes, understood |
| 19:52.30 | brlcad | the idea was to only incr count if config changed |
| 19:52.43 | starseeker | oh, I recall - diffing the cache files? |
| 19:52.50 | brlcad | not every cmake, but every cmake where something is different from the previous |
| 19:52.57 | starseeker | um... |
| 19:53.08 | brlcad | it was your idea, I liked it ;) |
| 19:53.37 | brlcad | that basically caters to all the cases |
| 19:53.43 | brlcad | and keeps relinking to a useful minimum |
| 19:54.08 | starseeker | the difficult was that a cache file isn't written until the end of the CMake process - so it's comparing an old cache file with the current "in memory" state of CMake |
| 19:54.24 | starseeker | that sounds more complex than COUNT trickery |
| 19:54.54 | brlcad | not at all complicated to explain though and no unintended side effects |
| 19:55.23 | brlcad | maybe more complex to implement, but not more complex to maintain (it doesn't smell wierd, the other method really does) |
| 19:55.33 | starseeker | MUCH more complex to implement |
| 19:55.41 | starseeker | much MUCH more complex |
| 19:55.52 | brlcad | has confidence in starseeker's cmake magic ;) |
| 19:56.18 | starseeker | grumble... |
| 19:56.37 | brlcad | so leave it to relink each cmake, I still think that's better than something that makes the count toggled based on specific parameter values |
| 19:57.26 | brlcad | i.e., more important that "the value" have a simple definition than the build system wrapping around it |
| 19:57.39 | brlcad | incrementing every cmake (or make) isn't ideal, but it's bad either |
| 19:57.45 | starseeker | thinks the developer time saved avoiding all the useless relinking is more valuable than the COUNT variable (which, to be fair, he has NEVER used, so he may not have a good appreciation of its benefits...) |
| 19:57.48 | brlcad | every config would probably be ideal |
| 19:58.23 | brlcad | actually, what I said earlier -- the original behavior -- was ideal, incrementing every build pass but only using it every link :) |
| 19:58.50 | starseeker | not possible in CMake as it exists today, apparently |
| 19:58.59 | brlcad | sure, not possible with autotools either |
| 19:59.48 | brlcad | maybe with a custom make rule .. but not that big an issue |
| 20:01.13 | brlcad | I actually check that number every time I sit down at an unknown install to see what the user (even if it's just me) is running |
| 20:01.45 | brlcad | e.g., right now: "Compilation 18" |
| 20:01.54 | brlcad | definitely a dev checkout |
| 20:02.45 | CIA-133 | BRL-CAD: 03starseeker * r46614 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Snarf environment variables like we're supposed to, don't ignore the user's CFLAGS... |
| 20:03.07 | starseeker | suspects he is far more included than brlcad to just check out a clean repo and/or blow away and rebuild... |
| 20:03.09 | brlcad | I'd frankly probably be more inclined to drop the count before changing the meaning of the number |
| 20:03.20 | brlcad | "Compilation 18 (or possibly more)" just isn't useful |
| 20:05.55 | brlcad | I do that for some builds too -- it's not about the dev, it's the code -- that's what the number tells you |
| 20:06.39 | brlcad | *when* it isn't a clean repo, that can be very useful to know |
| 20:06.58 | CIA-133 | BRL-CAD: 03starseeker * r46615 10/brlcad/trunk/CMakeLists.txt: Sean wants this COUNT to be independent of build type |
| 20:07.02 | starseeker | svn status ftw |
| 20:07.14 | brlcad | eh? |
| 20:07.20 | starseeker | "not a clean repo" |
| 20:07.29 | brlcad | I don't necessarily have svn status when I'm running the binaries |
| 20:07.41 | starseeker | oh, you mean a build from a clean repo |
| 20:07.43 | brlcad | I'm running mged or rt or something else from an install |
| 20:08.10 | brlcad | this is all about having an install let us know what kind of environment it came from |
| 20:08.19 | brlcad | not just build settings, that's easy |
| 20:09.03 | starseeker | brlcad: can I at least add an advanced developer option to disable the COUNT? |
| 20:10.51 | brlcad | if I encounter a crash while running rt and I see Compilation 18, the very first thing that begs (no matter where or who's desk I'm sitting at) is to not even mess with debugging it -- redo the install |
| 20:12.20 | starseeker | brlcad: I restored the default behavior (I suppose I should yank the copy_if_diff logic for that file, since it's now useless) |
| 20:12.24 | brlcad | that would completely defeat the purpose of the COUNT, back to the same "Compilation 1 (or possibly more)" situation |
| 20:12.43 | starseeker | brlcad: only if a developer specifically turns it on though |
| 20:12.59 | starseeker | I could locally tweak the CMake logic to do exactly the same thing |
| 20:13.41 | brlcad | how will I know when I run a random installed rt whether the dev turned it on or off? |
| 20:13.54 | brlcad | good faith trust? |
| 20:14.21 | starseeker | what about setting the count to -1 or something like that when turned off? |
| 20:17.33 | CIA-133 | BRL-CAD: 03starseeker * r46616 10/brlcad/trunk/CMakeLists.txt: copy_if_different logic is useless for COUNT, so remove it |
| 20:17.57 | brlcad | this is not a productive way to continue discussing changes like this |
| 20:18.10 | brlcad | might as well remove it entirely because it's either useful and used or it's not |
| 20:18.35 | starseeker | you use it, so we'll got with that |
| 20:18.50 | brlcad | you obviously don't use it, so you're asking every question to modify the feature into the minimalist way to make you not have to care about it |
| 20:19.03 | brlcad | the answer should be to either use it or have a discussion on the merits to remove it |
| 20:19.05 | starseeker | probably should use it |
| 20:20.25 | starseeker | more productive then... you mentioned the original system incrementing every build pass but only using it every link |
| 20:20.44 | brlcad | I'm not opposed to removing it, I'd choose removing it over making it only sometimes a useful value for example |
| 20:20.47 | starseeker | what would be a good way to have CMake generate logic to do that? |
| 20:20.57 | brlcad | I have no idea :) |
| 20:22.19 | brlcad | in Make lingo, it involved putting the version into into a compilation unit (vers.c), and then specifying vers.o during link but not as a make rule dependency |
| 20:22.59 | brlcad | so it only compiled and linked vers.c when it was going to link |
| 20:23.11 | brlcad | something like that at least |
| 20:24.03 | starseeker | um. you mean vers.o was linked with the executables directly, or with the libraries? |
| 20:24.23 | brlcad | separate ones for both |
| 20:24.45 | brlcad | I got rid of all the front-end versioning, not as useful as knowing the library |
| 20:24.51 | brlcad | s/all/most/ |
| 20:29.04 | starseeker | erm. We're agreed that if I can detect whether there was any actual configuration change, that's the best criteria for incrementing the count? |
| 20:33.01 | brlcad | that sounds like the best closest useful fit to me |
| 20:33.31 | starseeker | ok. I might be wrong about how tricky that is - let me do some tests |
| 20:35.18 | brlcad | if you can't figure it out, don't sweat it -- I won't cry if the feature is removed, it's installation metadata |
| 20:36.01 | starseeker | if you do check it everytime though, it's telling you something useful (/me has a lot of respect for brlcad's notions of efficiency, if it wasn't useful you would have optimized it out already :-P) |
| 20:36.09 | brlcad | I find it useful, but certainly not critical or even worth debate, just informative when needed |
| 20:45.48 | brlcad | I will conceed that it's probably not worth keeping if it'll relink every cmake since we're talking about a time savings of approximately 30 minutes a couple times a year to redo an install |
| 20:46.03 | brlcad | that's generously maybe 3 hours throughout the year |
| 20:46.46 | starseeker | hang in there - I just got a parse out of the CMakeCache.txt contents |
| 20:47.36 | brlcad | if cmake changes once a week across half a dozen developers and relinking takes optimistically 1 minute, that's 52 * 6 or roughly five hours |
| 20:48.06 | starseeker | was just trying to get everything all nice and tidy after figuring out how to get togl and tktable to stop rebuilding, which is fundamentally a pretty stupid motivation |
| 20:48.21 | brlcad | similarly, if it takes you more than 3 hours to figure it out, it's not worth it ;) |
| 20:48.28 | starseeker | mea culpa |
| 20:48.46 | brlcad | hey, a love nice and tidy |
| 20:48.52 | brlcad | you know that! :) |
| 20:49.11 | brlcad | obsessive attention to detail ftw |
| 21:37.33 | *** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 22:27.47 | starseeker | brlcad: what about the date stamp? I cut down the info in it to avoid seconds/minute changes triggering the same linking issue, should I just use that stamp for all builds? |
| 22:28.31 | ``Erik | hm, kernel.org seems to be down :/ |
| 22:28.48 | starseeker | they fixing their servers? |
| 22:30.20 | ``Erik | can't get a dns resolve |
| 22:30.31 | ``Erik | which sucks, cuz an updated version of git came out |
| 22:30.33 | starseeker | winces |
| 22:30.51 | starseeker | is Linus hosting that on github too? |
| 22:31.02 | starseeker | or the git devs rather? |
| 22:31.05 | ``Erik | tried several country resolves, I assume their toplevel dns crapped out a bit ago, long enough for propogation |
| 22:31.24 | ``Erik | they have a git repo and a .zip file, plus old files... but not the tar.bz2 that fbsd/ports wants |
| 22:31.47 | ``Erik | and I'd kinda like the signed checksums, y'know? :D |
| 22:31.55 | starseeker | ah |
| 22:36.02 | brlcad | starseeker: no entiendo |
| 22:37.02 | starseeker | the date stamp I had been writing out into include/conf/DATE printed the asciitime string including hours:minutes:seconds, so it got changed each time cmake ran |
| 22:37.25 | ``Erik | eigo kudasai O.o |
| 22:39.48 | n_reed | english, spanish, japanese... doesn't matter to me :) |
| 22:40.02 | starseeker | they're all greek? :-P |
| 22:40.22 | n_reed | no, i can read them all |
| 22:40.47 | ``Erik | don't make me dig up translate.google.com to find something incredibly obscure O.o |
| 22:40.53 | starseeker | heh cool :-) |
| 22:41.03 | ``Erik | ano bakka kuso ttare |
| 22:44.43 | starseeker | needs to see what autotools does for DATE, come to think of it |
| 22:45.19 | ``Erik | probably runs "date" |
| 22:45.30 | CIA-133 | BRL-CAD: 03starseeker * r46617 10/brlcad/trunk/ (4 files in 2 dirs): (log message trimmed) |
| 22:45.30 | CIA-133 | BRL-CAD: Make a serious stab at incrementing the COUNT variable only when the |
| 22:45.30 | CIA-133 | BRL-CAD: configuration actually changes. For the moment, this is accomplished by reading |
| 22:45.30 | CIA-133 | BRL-CAD: the old CMakeCache.txt file (stashed at the beginning of the second cmake run) |
| 22:45.30 | CIA-133 | BRL-CAD: and comparing values found there to values in the current CMake enviornment. |
| 22:45.31 | CIA-133 | BRL-CAD: It's not perfect in that new variables in the working environment won't trigger |
| 22:45.32 | CIA-133 | BRL-CAD: the COUNT increase, but for most reconfiguration situations something will be |
| 22:45.52 | starseeker | yeah, that's gonna trigger a relinking then - date includes minutes and seconds of current time |
| 22:47.27 | starseeker | brlcad: see how that looks - if that doesn't look good I can pose the problem on the CMake list. |
| 22:49.40 | ``Erik | *look* autoconf does use date, but with the format string |
| 22:50.00 | ``Erik | CONFIG_DAY=`date +%d` |
| 22:50.47 | starseeker | echo "\"`LANG=C date -R 2>/dev/null || date +'%a, %d %b %Y %H:%M:%S %z' 2>/dev/null || date`\"" > $@ |
| 22:53.25 | starseeker | %M and %s are the trick, maybe %H too |
| 22:53.34 | starseeker | s/%s/%S |
| 22:54.46 | ``Erik | when I used B|X instead of irssi, I was putting logs in seperate dirs by day, the cron job had mkdir `date +%Y%m%d` |
| 22:55.35 | ``Erik | and for dump scripts, I do something like $host-$fs-`date +%Y%m%d%H%M`.dump.bz2 |
| 22:55.37 | starseeker | in CMake I'm actually generating the date stamp with C code (date available on all platforms) - I can do a custom string, the issue is that means not using the "standard" format |
| 22:55.54 | starseeker | date ISN'T available on all platforms |
| 22:55.58 | starseeker | sheesh |
| 22:56.27 | ``Erik | strftime() is :) |
| 22:56.54 | starseeker | ah, didn't know about that |
| 22:57.07 | starseeker | cool, that will simplify the time.c.in code |
| 22:57.42 | starseeker | but that gets back to whether brlcad wants to have the DATE file do something different from the standard ascii string |
| 22:57.49 | starseeker | isn't going to assume this time |
| 23:01.28 | *** join/#brlcad merzo (~merzo@248-122-133-95.pool.ukrtel.net) | |
| 23:08.05 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 23:20.47 | CIA-133 | BRL-CAD: 03starseeker * r46618 10/brlcad/trunk/CMakeLists.txt: Silly developer. If detecting config changes, need the copy_if_diff code again |
| 23:22.00 | brlcad | autotools writes out the date in RFC 2822 format |
| 23:22.04 | brlcad | date -R |
| 23:22.14 | brlcad | for gnu date, or date +'%a, %d %b %Y %H:%M:%S %z' for others |
| 23:22.30 | brlcad | ah, you found it |
| 23:25.28 | brlcad | RFC 2822 is particularly useful because it's easily human readable and computer parsable without sacrificing info |
| 23:25.36 | CIA-133 | BRL-CAD: 03starseeker * r46619 10/brlcad/trunk/CMakeLists.txt: copy/paste strikes again |
| 23:26.46 | starseeker | brlcad: no argument - the issue is that when cmake re-runs and makes a new DATE, we've got the linker issue all over again if we include minutes and seconds |
| 23:26.54 | starseeker | (those for sure - hours may be an issue) |
| 23:28.43 | brlcad | couple the date stamp regeneration to COUNT? |
| 23:28.53 | starseeker | hmm, good idea |
| 23:29.00 | starseeker | digs |
| 23:29.14 | brlcad | if you need to generate 2822, this should help: http://inn.eyrie.org/svn/tags/2.4.4/lib/date.c |
| 23:29.24 | brlcad | bsd-licensed, only need one or two functions from it |
| 23:29.30 | starseeker | was assuming asciitime did that, but maybe not... |
| 23:31.04 | starseeker | asctime rather |
| 23:32.02 | starseeker | and.... bzzt, wrong |
| 23:32.06 | starseeker | looks at date.c |
| 23:34.37 | brlcad | starseeker: yeah, I don't believe so |
| 23:34.41 | brlcad | but strftime() should |
| 23:34.53 | brlcad | since you can specify the '%a, %d %b %Y %H:%M:%S %z' format string |
| 23:35.12 | brlcad | forgot all about asctime() |
| 23:36.19 | brlcad | hopefully shouldn't need that date.c impl .. strftime() is c90 |
| 23:36.33 | starseeker | tries that to start |
| 23:36.41 | brlcad | http://msdn.microsoft.com/en-us/library/fe06s4ak(v=vs.80).aspx woot |
| 23:37.11 | brlcad | been there since '95, better than good enough |
| 23:37.46 | brlcad | alrighty! .. finally finished revamping the nurbs test script |
| 23:39.13 | brlcad | now with matching view rendering, better percentage deviation reporting, and normalized rays/s calculations |
| 23:39.18 | starseeker | awesome! |
| 23:40.26 | brlcad | haven't been able to think of a good way to make this script more useful in a general context .. it does a lot of workhorsing |
| 23:41.12 | brlcad | actually might make for a nice regression test.. ends up invoking about a dozen different tools |
| 23:42.26 | starseeker | cool |
| 23:42.49 | starseeker | we could probably use a NURBS regression test |
| 23:43.14 | ``Erik | (might wanna contemplate migrating #!/bin/sh to tclsh or something some day) |
| 23:45.23 | starseeker | we discussed that once - apparently that comes under the "labor of Hercules" heading :-/ |
| 23:46.31 | ``Erik | same category as cmake, heracles? :) |
| 23:46.44 | starseeker | is betting worse, actually... |
| 23:47.09 | ``Erik | mebbe not, say, footer, header, indent... but regress, bench... things winderz folk might want to try |
| 23:48.25 | ``Erik | 'nut' tells me I should eat pizza :/ (available on bz) |
| 23:51.06 | starseeker | ``Erik: brlcad has put a lot of pretty serious work into those sh scripts - I don't even want to think about what it would take to reach parity with tclsh |
| 23:54.05 | starseeker | probaby easier to stuff an sh impliementation into src/other and make it work on Windows - I think brlcad may have mentioned pdksh as a possibility, but I'm not sure |
| 23:58.52 | brlcad | yeah, I'm pretty adept at tcl, but some of those scripts do things I don't think I could easily do with tcl (or python or perl ...) |
| 23:59.59 | brlcad | some shell tricks just aren't possible, so you'd end up having to do some manual expansion of logic into something equivalent |
| 00:00.31 | starseeker | is looking, but doesn't see any immediate indication that anyone has pdksh compiling with MSVC... |
| 00:03.33 | brlcad | http://en.wikipedia.org/wiki/Korn_shell says some versions of windows already include a posix-compliant ksh, and http://en.wikipedia.org/wiki/UWIN |
| 00:03.43 | CIA-133 | BRL-CAD: 03starseeker * r46620 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/test_srcs/time.c.in): Yay! RFC2822-ify the DATE stamp code, and go with Sean's idea of linking the DATE regeneration to the COUNT regeneration. |
| 00:04.23 | brlcad | the main portability issue is getting a pseudo terminal interface, which was the other part of that equation |
| 00:04.24 | starseeker | urm. CPL? not very familiar with that license |
| 00:04.54 | brlcad | you need a terminal to run a shell, if you have that, porting the underlying shell is pretty trivial |
| 00:05.25 | starseeker | winces |
| 00:05.52 | starseeker | so I guess it boils down to whether implementing a terminal emulator in Windows is easer than the sh->tclsh port |
| 00:06.18 | brlcad | meh |
| 00:06.24 | brlcad | the shell scripts are all developer infrastructure |
| 00:06.56 | starseeker | would be nice to do regress/bench with MSVC |
| 00:07.00 | brlcad | not a big deal if you can't test some parts of the system on Windows, you can everywhere else |
| 00:07.11 | brlcad | bench is a diff issue, already on it |
| 00:07.51 | starseeker | ah, cool :-) |
| 00:08.27 | brlcad | sure it would be nice to have all of regress on windows, but not "absolutely must have necessary" .. and there is cygwin/mingw if we really want to be pedantic, it's pretty trivially possible |
| 00:09.39 | brlcad | let a windows diehard rewrite them :) |
| 00:11.21 | starseeker | heh |
| 00:21.46 | starseeker | brlcad: how does that new setup look? |
| 00:22.02 | starseeker | seems to be behaving OK here, so far |
| 00:33.42 | brlcad | been working on getting the final nurbs rerun kicked off again for another 10-20 hours of processing |
| 00:35.30 | brlcad | now that it's done and churning, hopefully it'll be a clean run and the stats can be distributed as a baseline |
| 00:36.07 | brlcad | i'll be kicking off some builds here in a couple minutes so i'll let you know how it goes :0 |
| 02:44.46 | CIA-133 | BRL-CAD: 03173.234.97.161 07http://brlcad.org * r3149 10/wiki/User:108.62.162.154: New page: [http://www.galeriabali.pl/pl/Ryby owoce morza] Szeroki wybor w karcie dan spowoduje, ze znajdziesz cos wyjatkowego a ciekawosc jak smakuja inne dania sprawi, ze nie beziesz mogl sie docze... |
| 03:17.31 | CIA-133 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User:108.62.162.154]]" |
| 03:17.32 | CIA-133 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.97.161]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 03:27.47 | CIA-133 | BRL-CAD: 03starseeker * r46621 10/brlcad/trunk/src/libged/CMakeLists.txt: need to ignore the simulate files if we're not building them |
| 03:32.13 | starseeker | brlcad: I'm a bit confused about how to approach an aspect of the distcheck rule - I can ignore files that the build logic doesn't know about and not include them in the tarball, but how do I distinguish between "junk" files that should be ignored and files that the developer genuinely forgot to include? (like the simulate files if bullet isn't found) |
| 03:41.38 | CIA-133 | BRL-CAD: 03starseeker * r46622 10/brlcad/trunk/misc/CMake/distcheck_buildsys.cmake.in: Improvements to the distcheck logic - haven't quite got to activting the CPack tweaking logic, but close. In the meantime, better error reporting. |
| 03:54.30 | CIA-133 | BRL-CAD: 03starseeker * r46623 10/brlcad/trunk/misc/CMake/distcheck_buildsys.cmake.in: more TODO notes for dist |
| 04:02.02 | brlcad | starseeker: the autotools build checks the svn manifest -- if they're in svn, then they should be in the dist |
| 04:02.51 | starseeker | urm. So I need to parse the svn manifests. |
| 04:04.00 | brlcad | 12-liner coming: |
| 04:04.03 | brlcad | dist-hook: |
| 04:04.03 | brlcad | <PROTECTED> |
| 04:04.07 | brlcad | <PROTECTED> |
| 04:04.09 | brlcad | <PROTECTED> |
| 04:04.12 | brlcad | <PROTECTED> |
| 04:04.14 | brlcad | <PROTECTED> |
| 04:04.17 | brlcad | <PROTECTED> |
| 04:04.19 | brlcad | <PROTECTED> |
| 04:04.22 | brlcad | <PROTECTED> |
| 04:04.24 | brlcad | <PROTECTED> |
| 04:04.27 | brlcad | <PROTECTED> |
| 04:04.29 | brlcad | <PROTECTED> |
| 04:04.55 | brlcad | that's how autotools does it -- gets the list of names from the ".svn/entries" files, then looks to see if they're in the source dist that was built |
| 04:05.10 | brlcad | if missing, reports then halts |
| 04:05.39 | brlcad | that script-fu should convert pretty simply to cmake funcs |
| 04:06.31 | starseeker | those entries files are per .svn directory? |
| 04:06.40 | brlcad | yes |
| 04:07.04 | brlcad | they're simple text, pop one up |
| 04:07.52 | brlcad | basically xml blocks with name="filename" identifiers |
| 04:08.18 | starseeker | what does it do without the .svn directories then? |
| 04:09.06 | brlcad | no manifest, no way to know what's actually missing |
| 04:09.09 | brlcad | so it does nothing |
| 04:09.12 | starseeker | ah |
| 04:09.24 | starseeker | that's actually the case I have implemented then :-/ |
| 04:09.38 | brlcad | it could report what files were found, but meh .. 99% of the time, we have the list |
| 04:10.10 | starseeker | nods - I'll leave what I have for that case (no .svn entities files found) and figure out the .svn manifest part |
| 04:10.30 | brlcad | yeah, that's probably very reasonable behavior -- no svn files, report and could even halt |
| 04:10.56 | brlcad | but if there is a manifest, it probably shouldn't halt on the unknowns |
| 04:11.29 | starseeker | nods |
| 04:11.38 | CIA-133 | BRL-CAD: 03starseeker * r46624 10/brlcad/trunk/CMakeLists.txt: Echo some messages to identify various stages of distcheck. |
| 04:11.39 | brlcad | arguably useful to even report them since our actual "correctness" rule is only to make sure what's in svn is in the dist |
| 04:11.41 | starseeker | that's what I was figuring - with svn manifests, it's sane to continue |
| 04:12.04 | brlcad | but even reporting them could be good sanity too |
| 04:12.18 | starseeker | <shrugs> at least flags the trouble spot |
| 04:12.28 | brlcad | the biggest catch is finding things you *know* are in svn but are missing |
| 04:12.31 | brlcad | yeah |
| 04:13.15 | starseeker | I doubt I'll be ready with an svn based distcheck for this release :-( |
| 04:13.36 | brlcad | that's fine |
| 04:13.45 | brlcad | planning on distchecking with both anyways |
| 04:13.57 | brlcad | if you want to get fancy -- one thing I never got around to fixing is if you svn delete a file, the entry remains (with a deleted flag in the entries record) |
| 04:14.45 | starseeker | nods - sounds worth doing |
| 04:14.55 | brlcad | rarely hit it in practice so not a big deal, but one more place to knock the autotools build down a notch |
| 04:15.24 | brlcad | would be a bigger issue if we deleted/renamed files more frequently between releases (and not just whole dirs) |
| 04:16.17 | starseeker | nods |
| 04:16.29 | brlcad | oh wow, so I thought it was still relinking everything .... |
| 04:17.04 | brlcad | but turns out it's just that slow to walk over all 400+ targets to evaluate and print "Built target ..." |
| 04:17.24 | starseeker | O.o |
| 04:17.41 | brlcad | cool, so looks like it works |
| 04:17.47 | brlcad | to do nothing: |
| 04:17.48 | brlcad | Elapsed compilation time: 1 minute 7 seconds |
| 04:18.07 | starseeker | what's the autotools time to do nothing? |
| 04:18.39 | starseeker | actually, with all the docbook targets present (even without pdf) I think it's over a thousand targets... |
| 04:18.57 | brlcad | yeah, it is |
| 04:19.08 | starseeker | that was fun in Visual Studio |
| 04:19.14 | brlcad | good question, I don't recall off the top of my head but was less |
| 04:19.38 | brlcad | counts the number of targets |
| 04:19.40 | starseeker | bets it's about 50-60%, mostly due to faster docbook |
| 04:20.14 | CIA-133 | BRL-CAD: 03108.62.166.91 07http://brlcad.org * r3150 10/wiki/User:108.62.173.114: New page: [http://www.willa-sloneczna.euroadres.pl noclegi kazimierz dolny] .Kiedy mysli sie nad slowami dluzszy pobyt to prawdopodobnie rozwazasz o kilku tygodniach lub miesiacach. W rzeczywistosc... |
| 04:20.22 | brlcad | sunufa! |
| 04:20.38 | brlcad | looks like I know what I'm doing tomorrow |
| 04:20.56 | CIA-133 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User:108.62.173.114]]" |
| 04:21.03 | starseeker | oddly enough, I'll be doing something similar (cleaning bathrooms ;-) |
| 04:21.06 | CIA-133 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:108.62.166.91]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 04:21.48 | brlcad | good thing is that it takes less than 30 seconds to revert and block .. but still, pita! |
| 04:21.52 | brlcad | 1175 targets :) |
| 04:22.32 | starseeker | <evil laugh>MWA_HAHAHAHAHA</evil laugh> |
| 04:23.09 | starseeker | hmm - time to do nothing on my Linux box here - 4 seconds |
| 04:24.04 | starseeker | can't wait to post a table somewhere with Linux, Mac and Windows build times side by side |
| 04:25.03 | starseeker | brlcad: you're feeding it the make -j# for the empty case? |
| 04:26.22 | starseeker | tries on a mac once... |
| 04:26.35 | brlcad | I had the first time, but not that timed one |
| 04:27.00 | starseeker | it should make a difference |
| 04:27.43 | brlcad | probably, but not a huge one .. this laptop only has two procs and the disks are too fast and os x is an i/o bottleneck |
| 04:27.52 | starseeker | ah |
| 04:27.53 | brlcad | 1min9sec |
| 04:28.02 | starseeker | phooy |
| 04:28.03 | brlcad | so .. bout the same |
| 04:33.16 | starseeker | brlcad: so it looks like we're closing in - svn manifests for distcheck and turning the MSVC stuff into tests are the two biggies I know about |
| 04:33.28 | starseeker | oh, and finishing updating the docs |
| 04:33.38 | brlcad | msvc into tests? |
| 04:33.46 | starseeker | config_win going byebye |
| 04:33.55 | brlcad | ah great |
| 04:35.17 | brlcad | should probably hit the docs first, the sooner the deprecation statements get added, the sooner we can remove the build in a couple months |
| 04:35.17 | starseeker | is considering making a small convenience NSIS installer for the Windows xsltproc |
| 04:36.39 | starseeker | knows you had a list of things to add statements to - configure obviously, and autogen.sh |
| 04:36.50 | starseeker | is that in a TODO somewhere? |
| 04:37.01 | starseeker | (just so I know what to hit) |
| 04:37.41 | brlcad | those two are the main ones |
| 04:38.22 | starseeker | did you want to add notes in the current documentation files, or just swap them out when the time comes? |
| 04:38.46 | brlcad | just swap, if it's deprecated then there's no need to educate on the old system |
| 04:39.07 | brlcad | the statements are just added to the remnants visible for those that did learn the old way |
| 04:39.09 | starseeker | nods - oh, is the new Bundled/System/Auto option setup to your liking? |
| 04:39.23 | brlcad | haven't dove that deep again |
| 04:39.31 | starseeker | ah, k |
| 04:39.37 | brlcad | hm, libpc bustage |
| 04:41.52 | starseeker | probably the new boost |
| 04:41.57 | brlcad | yep |
| 04:42.26 | starseeker | grim? |
| 04:43.09 | brlcad | trivial |
| 04:43.13 | CIA-133 | BRL-CAD: 03brlcad * r46625 10/brlcad/trunk/configure.ac: reflect new location of boost headers |
| 04:43.37 | starseeker | ah :-) |
| 04:45.07 | brlcad | the new normalized rays/s is pretty cool |
| 04:45.52 | starseeker | oh, in your benchmark? |
| 04:46.04 | brlcad | yeah |
| 04:46.25 | starseeker | tries clang as long as he's on the mac... |
| 04:46.42 | starseeker | how're nurbs stacking up? |
| 04:47.03 | brlcad | pulls rays/s from the summary for a given trace, but then also calculates how many pixels actually involved geometry and weights the rtfm value |
| 04:47.25 | starseeker | sweet |
| 04:47.32 | starseeker | was that the math you were scripting earlier? |
| 04:48.00 | brlcad | related, but that was actually for the projected area and volume cases |
| 04:48.12 | starseeker | yow |
| 04:48.47 | brlcad | they have to do something a bit more tricky since I'm trying to report a relative deviation as percentage error |
| 04:49.00 | starseeker | kinda sounds like stuff mged should have had tools for |
| 04:49.44 | brlcad | mmm, dunno |
| 04:49.52 | brlcad | not seeing general utility |
| 04:50.01 | brlcad | for the pix comparisons, sure |
| 04:51.00 | brlcad | but there the math is easy, just 1 - (num_pixels_wrong / num_pixels) |
| 04:51.33 | starseeker | ah - guess I was thinking something like having rt report the "pixels involving geometry" metric |
| 04:51.56 | brlcad | ah, maybe but that was also pretty easy to script |
| 04:52.01 | brlcad | with existing tools |
| 04:52.18 | starseeker | cool |
| 04:52.18 | brlcad | the hard one is the volume and error |
| 04:52.48 | starseeker | hmm: src/conv/g-vrml.c:99:21: warning: using extended field designator is an extension [-pedantic] |
| 04:52.50 | brlcad | amount_vol_wrong / amount_vol doesn't give what you want |
| 04:53.20 | brlcad | well, at least doesn't give what *I* want :) .. that just reports the % difference |
| 04:53.27 | starseeker | nods |
| 04:53.39 | starseeker | sounds like a problem for our resident math genius ;-) |
| 04:53.58 | brlcad | ended up with this little bit of goodness: dc -e "1k 100.0 $bvol $vol - d * v $bvol / 100.0 * - d [0] sa 0.0 >a p" |
| 04:54.08 | starseeker | O.o |
| 04:55.25 | starseeker | watches SdaiCONFIG_CONTROL_DESIGN.h barf warnings and reflects that he REALLY needs to try the newer SCL code... |
| 04:57.00 | brlcad | which is basically: 100.0 - abs(actual_volume - real_volume) / actual_volume * 100.0 but then clamping the value to 0.0 if it goes negative |
| 04:57.30 | starseeker | nods |
| 04:57.47 | brlcad | actual is tiny and real is huge, then the "difference factor" is going to be huge |
| 04:58.28 | starseeker | so it's amplifying the difference? |
| 04:58.29 | brlcad | basically means objects that are smaller than the baseline will have an error value that is the percentage of the actual volume |
| 04:58.49 | brlcad | an object half as big as it's supposed to be is going to report a volume error of 50% |
| 04:58.59 | starseeker | ah, gotcha |
| 05:00.43 | brlcad | but then for objects larger than they're supposed to be, it'll report 50% when it's 50% larger and 100% error when it's double (*or* more) in size |
| 05:00.58 | brlcad | that's the case that was hard to figure out |
| 05:01.13 | brlcad | since it can be unboundedly larger than the baseline |
| 05:01.46 | brlcad | good stuff |
| 05:01.52 | starseeker | are you seeing cases much larger than baseline? |
| 05:02.00 | starseeker | is curious how that could come about... |
| 05:02.37 | brlcad | there are some clear failures, but most are slight larger/smaller deviations |
| 05:02.42 | brlcad | bots |
| 05:02.58 | brlcad | the calcs will work for any case though |
| 05:03.10 | starseeker | nods - that's cool :-) |
| 05:04.44 | starseeker | aw - clang build busted on obj-g_new.c |
| 05:05.26 | starseeker | ok, I gotta get out of here |
| 05:05.59 | starseeker | brlcad: let me know if you see an problems with the new COUNT setup, but I think that will do the trick for most situations we're likely to see |
| 05:11.10 | CIA-133 | BRL-CAD: 03starseeker * r46626 10/brlcad/trunk/src/conv/obj-g_new.c: size_t -> size_t * for comparison |
| 05:11.20 | starseeker | and we build with clang again :-) |
| 05:11.27 | starseeker | hits the road |
| 05:12.09 | brlcad | it's looking great |
| 07:43.37 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 07:43.37 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 09:07.01 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 09:50.29 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 12:07.35 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-185-071.wlan.tudelft.nl) | |
| 13:28.28 | starseeker | oh, beautiful - apparently a Makefile doesn't know what N is in make -j N |
| 13:28.33 | starseeker | http://old.nabble.com/MAKEFLAGS-var-does-not-show-%22-j%22-param-----td15983337.html |
| 13:36.33 | brlcad | starseeker: that's not what that thread says |
| 13:38.55 | brlcad | says make-w32 doesn't implement the parallel build with the "job server" mechanism, so it redoes the parameter for some other mechanism on windows |
| 13:45.14 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 14:02.59 | *** join/#brlcad abhi2011_ (~chatzilla@wlan-145-94-185-071.wlan.tudelft.nl) | |
| 14:06.32 | starseeker | brlcad: not the windows part, the part where $(MAKEFLAGS) will never show the -jN option in parallel |
| 14:07.09 | starseeker | needs to introspect in the Makefile what the -j option passed in was, and it apparently can't be accessed at all |
| 14:08.25 | starseeker | just gives back the --jobserver-fds=3,4 -j contents regardless |
| 14:08.29 | starseeker | confirms that in tests here |
| 14:16.16 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 14:20.01 | brlcad | starseeker: ah, I see what you're getting at |
| 14:20.12 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 14:20.38 | brlcad | that's undoubtedly because the jobserver is being entrusted with that detail |
| 14:25.08 | brlcad | starseeker: couldn't you just set it up so that it just toggles off a cmake variable? cmake -DJOBS=3 |
| 14:25.38 | brlcad | then you can access that to add -j$JOBS during dist or wherever |
| 14:27.01 | starseeker | that would mean doing something like cmake -P distcheck.cmake -DJOBS=3 instead of make -j3 distcheck |
| 14:27.18 | starseeker | workable, but it takes distcheck outside the make system |
| 14:27.39 | brlcad | not necessarily |
| 14:28.30 | brlcad | so you could run "cmake -DJOBS=3 path/to/src" during setup, but it doesn't actually do anything with it other than stash it |
| 14:28.56 | starseeker | oh, set the job count at cmake configure time instead of make time? |
| 14:29.04 | brlcad | then "make distcheck" would use the stashed value, or at worst maybe "make distcheck JOBS=3" instead |
| 14:29.18 | brlcad | to override at make-time |
| 14:29.28 | starseeker | isn't sure the override would work... |
| 14:29.33 | brlcad | another options is just "-j" |
| 14:29.46 | brlcad | -j without a number means "go hog wild" |
| 14:29.50 | starseeker | heh |
| 14:30.30 | starseeker | even that's tricky though - accessing make values to feed to CMake isn't really something the CMake generated scripts are set up for |
| 14:30.47 | starseeker | has an email into the CMake list to ask about it |
| 14:31.31 | starseeker | ideal case would be to add the ability to CMake generated make files to respect some variable (JOBS or CPUS) passed in at make time |
| 14:32.53 | starseeker | maybe have a ${CMAKE_CPU_COUNT} variable at CMakeLists.txt level that could be added to the --build line, e.g. ${CMAKE_COMMAND} --build -j${CMAKE_CPU_COUNT} and then have the CMake makefiles do the right thing |
| 14:35.51 | brlcad | that's kind of what I mean, just s/CMAKE_CPU_COUNT/JOBS/ |
| 14:36.15 | starseeker | nods - that would take support on the CMake generator backend |
| 14:36.46 | brlcad | CMAKE_NCPU would be a "proper" prefixed form I guess :) |
| 14:36.52 | starseeker | hehe |
| 14:36.57 | starseeker | will suggest that |
| 14:37.26 | starseeker | make NCPU=3 isn't make -j3, but it is probably as close as make will let us get |
| 15:04.07 | CIA-133 | BRL-CAD: 03brlcad * r46630 10/brlcad/trunk/ (include/bu.h src/libbu/fnmatch.c src/librt/search.c): |
| 15:04.08 | CIA-133 | BRL-CAD: expose the documented minmum inteface for bu_fnmatch() including the various |
| 15:04.08 | CIA-133 | BRL-CAD: flags that a caller might set as well as the nomatch return value. remove the |
| 15:04.08 | CIA-133 | BRL-CAD: other BU_-prefixed symbols from the implementation since they're not public api. |
| 15:04.08 | CIA-133 | BRL-CAD: renamed BU_CASEFOLD to BU_FNMATCH_CASEFOLD in the process for bu api |
| 15:04.08 | CIA-133 | BRL-CAD: consistency. |
| 15:18.35 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 15:33.54 | brlcad | starseeker: do you remember why you made the plans in librt/search.c void* instead of db_plan_t* ? |
| 15:35.25 | starseeker | might have had something to do with how I was calling things from libged |
| 15:37.58 | CIA-133 | BRL-CAD: 03starseeker * r46631 10/brlcad/trunk/ (CMakeLists.txt autogen.sh configure.ac): Make the depends explicit for these initial commands - looks like ninja actually caught one out. |
| 15:38.04 | starseeker | ah crud |
| 15:38.24 | starseeker | brlcad: well, how do those look for autogen.sh and configure.ac deprecation warnings? |
| 15:40.00 | CIA-133 | BRL-CAD: 03brlcad * r46632 10/brlcad/trunk/src/librt/search.c: lets not add 50 new functions to librt's API. mark all of the implementation functions as HIDDEN. |
| 15:44.05 | CIA-133 | BRL-CAD: 03brlcad * r46633 10/brlcad/trunk/src/librt/search.c: ws indent consistency cleanup |
| 15:44.38 | CIA-133 | BRL-CAD: 03brlcad * r46634 10/brlcad/trunk/include/raytrace.h: migrated command doc from impl to header for db_search_formplan() |
| 15:53.30 | CIA-133 | BRL-CAD: 03brlcad * r46635 10/brlcad/trunk/include/common.h: better document why we use HIDDEN, emphasize that it's not really appropriate for front-end code but is expected for libraries. |
| 15:53.55 | CIA-133 | BRL-CAD: 03brlcad * r46636 10/brlcad/trunk/src/libged/search.c: mark the private functions as HIDDEN |
| 15:55.26 | CIA-133 | BRL-CAD: 03starseeker * r46637 10/brlcad/trunk/ (autogen.sh configure.ac): these got sucked in by mistake |
| 15:56.28 | brlcad | starseeker: good start, but a few changes -- s/may be/will be/ |
| 15:56.39 | starseeker | ah, right |
| 15:56.44 | brlcad | and "Please use .." doesn't really say anything |
| 15:57.14 | brlcad | they're using what they know, so we should tell them what the new command is AND where to read for more info |
| 15:57.39 | starseeker | k |
| 16:33.50 | CIA-133 | BRL-CAD: 03starseeker * r46638 10/brlcad/trunk/CMakeLists.txt: Try a recommendation from Dave Cole of CMake - this is (more or less) what they do in their ExternalProject code to handle subbuilding |
| 16:44.25 | brlcad | starseeker: is ninja one of the cmake devs or some system?? |
| 17:02.12 | CIA-133 | BRL-CAD: 03brlcad * r46639 10/brlcad/trunk/src/libbu/ (argv.c vls.c): move bu_argv_from_string() from vls.c to argv.c |
| 17:06.12 | starseeker | oh, sorry - new CMake generater for this: http://martine.github.com/ninja/manual.html |
| 17:06.45 | brlcad | ah |
| 17:07.05 | starseeker | in development at the moment |
| 17:11.33 | starseeker | http://www.cmake.org/pipermail/cmake/2011-September/046145.html |
| 17:11.53 | brlcad | nods |
| 17:12.11 | starseeker | faster building ftw, if it actually works |
| 17:15.37 | CIA-133 | BRL-CAD: 03brlcad * r46640 10/brlcad/trunk/ (include/bu.h src/libbu/argv.c): make bu_argv_from_string() work with size_t instead of int for the size parameters. move the decl over with the other argv functions. need ctype.h header for isspace() too. |
| 17:31.19 | CIA-133 | BRL-CAD: 03bob1961 * r46641 10/brlcad/trunk/src/tclscripts/lib/TkTable.tcl: Added a -singleSelectCallback option. If specified this essentially puts the table widget into a mode where only one row at a time can be selected. |
| 17:35.03 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-185-071.wlan.tudelft.nl) | |
| 18:06.25 | CIA-133 | BRL-CAD: 03173.234.121.94 07http://brlcad.org * r3151 10/wiki/Haha_Spoil_her_reputation_81: New page: [[Image:reputation_management_1273.jpg|thumb|]] ya estamos listas pa salir al shows miados aki en Tijuana, agarrensen poke este pedo va a estar mamalon x 1 vez "las you you" !!!! NCBI ROF... |
| 18:12.34 | CIA-133 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Haha Spoil her reputation 81]]" |
| 18:12.45 | CIA-133 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.121.94]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 18:32.37 | *** join/#brlcad abhi2011_ (~chatzilla@wlan-145-94-185-071.wlan.tudelft.nl) | |
| 18:37.23 | brlcad | so there are now a couple new wiki extensions installed |
| 18:38.16 | brlcad | one is a new blacklist extension that pulls the massive lists maintained by mediawiki and wikipedia folks (they are separate lists) that block posts that contain blacklisted url/content |
| 18:39.06 | brlcad | another is a Q&A tension -- anyone care to suggest some good hard cad/math-related questions? |
| 18:44.40 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 18:45.45 | n_reed | not sure i understand the notion of a Q&A extension |
| 18:45.56 | n_reed | is the idea to post questions and answers |
| 18:46.04 | n_reed | or to get people to answer questions |
| 18:47.12 | brlcad | we pose a question, they have to answer it correctly to modify the wiki |
| 18:47.40 | brlcad | like "What is the name of this software?" answer: BRL-CAD |
| 18:48.21 | n_reed | so like a captcha, but harder |
| 18:49.14 | brlcad | what is the square root of 1000-100? |
| 18:49.15 | brlcad | sure |
| 18:50.25 | n_reed | are you asking for suggesstions because you want to populate a list of options? |
| 18:53.29 | brlcad | that is the idea |
| 18:54.52 | n_reed | i'll ask the obvious math person to send you some |
| 18:56.15 | brlcad | mere (CAD) mortals should be able to answer them |
| 18:56.38 | brlcad | I already have about 10, probably enough -- more just whether others wanted to add a couple |
| 19:22.31 | CIA-133 | BRL-CAD: 0368.34.98.23 07http://brlcad.org * r3152 10/wiki/Testing_something_bogus: New page: This is a test. |
| 19:23.26 | CIA-133 | BRL-CAD: 0368.34.98.23 07http://brlcad.org * r3153 10/wiki/Testing_something_bogus: |
| 19:28.22 | starseeker | phew - parallel distcheck |
| 19:28.55 | CIA-133 | BRL-CAD: 03bob1961 * r46642 10/brlcad/trunk/ (11 files in 5 dirs): Added more editing support for pipes (i.e. append, prepend, delete, move, select and scale). |
| 19:31.18 | starseeker | re-enables the "make your life miserable" parts until he gets proper svn manifest checking working |
| 19:40.42 | CIA-133 | BRL-CAD: 03bob1961 * r46643 10/brlcad/trunk/src/libged/Makefile.am: Added edpipe.c to libged/Makefile.am |
| 19:41.02 | CIA-133 | BRL-CAD: 0368.34.98.23 07http://brlcad.org * r3154 10/wiki/Testing_something_bogus: |
| 19:42.14 | CIA-133 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Testing something bogus]]": just testing |
| 19:44.36 | brlcad | so we'll see if that helps -- recaptcha is no longer enabled and logged in users still have no captcha |
| 19:49.33 | starseeker | brlcad: nice, thanks! |
| 19:52.40 | starseeker | pwd |
| 19:52.42 | starseeker | whoops |
| 20:03.26 | starseeker | hmm: http://www.opencascade.org/about/news/issue173/ |
| 20:03.40 | starseeker | wonders if that constitutes a glimmer of hope or not |
| 20:05.49 | CIA-133 | BRL-CAD: 03starseeker * r46644 10/brlcad/trunk/CMakeLists.txt: turn back on the repo checks. distcheck will need to become its own CMake file I think - this is getting too complex for one custom target. |
| 20:10.23 | brlcad | probably in response to OCE |
| 20:11.15 | starseeker | almost certainly - question will be whether it's just words or if they actually change |
| 20:11.33 | brlcad | they need to start with the license itself |
| 20:11.37 | starseeker | would be awesome if they went LGPL |
| 20:11.59 | brlcad | or better |
| 20:13.32 | starseeker | dunno how technically compatible we would be even if the license were ironed out, but they do have some bits we don't right now... |
| 20:41.23 | brlcad | and vice versa, but cleanly integrating pieces from two large codebases is arguably more work than implementing from scratch for each |
| 20:41.54 | brlcad | better to collaborate on the pieces that can be fully abstracted from both (like SCL) |
| 20:42.19 | CIA-133 | BRL-CAD: 03r_weiss * r46645 10/brlcad/trunk/include/bn.h: |
| 20:42.19 | CIA-133 | BRL-CAD: Updated include file 'bn.h' to enable the prototype versions of functions |
| 20:42.19 | CIA-133 | BRL-CAD: bn_isect_lseg3_lseg3, bn_isect_line3_line3, and bn_isect_line_lseg and remove |
| 20:42.19 | CIA-133 | BRL-CAD: the original versions. This change is the first of three. The remaining changes |
| 20:42.19 | CIA-133 | BRL-CAD: will be to files 'plane.c' and 'nmg_tri.c'. |
| 20:44.27 | CIA-133 | BRL-CAD: 03r_weiss * r46646 10/brlcad/trunk/src/libbn/plane.c: Updated file 'plane.c' to enable the prototype versions of functions bn_isect_lseg3_lseg3, bn_isect_line3_line3, and bn_isect_line_lseg. The original functions are removed. |
| 20:47.28 | CIA-133 | BRL-CAD: 03r_weiss * r46647 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: Updated file 'nmg_tri.c' to change function calls from the prototype names of functions bn_isect_lseg3_lseg3, and bn_isect_line3_line3 back to their original names. |
| 21:04.07 | brlcad | http://vim.wikia.com/wiki/Remove_unwanted_spaces |
| 21:04.07 | brlcad | http://vim.wikia.com/wiki/Highlight_unwanted_spaces |
| 21:04.23 | brlcad | possibly of interest to some of the vimragers in here |
| 21:08.09 | CIA-133 | BRL-CAD: 03brlcad * r46648 10/brlcad/trunk/src/ (70 files in 70 dirs): ws consistency removing trailing ws and much more (see sh/ws.sh) |
| 21:21.36 | CIA-133 | BRL-CAD: 03brlcad * r46649 10/brlcad/trunk/src/ (12 files in 12 dirs): more ws consistency cleanup |
| 21:22.09 | brlcad | starts to see a pattern |
| 21:33.21 | CIA-133 | BRL-CAD: 03bob1961 * r46650 10/brlcad/trunk/src/libged/edpipe.c: Collapse the functionality of ged_append_pipept() and ged_prepend_pipept() into _ged_append_pipept_common(). |
| 21:36.33 | CIA-133 | BRL-CAD: 03r_weiss * r46651 10/brlcad/trunk/src/librt/primitives/nmg/ (8 files): Updated files nmg_class.c, nmg_fuse.c, nmg_info.c, nmg_inter.c, nmg_mk.c, nmg_mod.c, nmg_rt_isect.c and nmg_tri.c to turn on the prototype triangulation code of nmg primitives. |
| 21:38.48 | CIA-133 | BRL-CAD: 03bob1961 * r46652 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: |
| 21:38.48 | CIA-133 | BRL-CAD: Collapse the functionality of to_mouse_append_pipept() and |
| 21:38.48 | CIA-133 | BRL-CAD: to_mouse_prepend_pipept() into to_mouse_append_pipept_common(). Added a call to |
| 21:38.48 | CIA-133 | BRL-CAD: ged_snap_to_grid() in to_mouse_append_pipept_common for snap-to-grid behavior |
| 21:38.48 | CIA-133 | BRL-CAD: when adding/inserting pipe points. |
| 21:40.38 | CIA-133 | BRL-CAD: 03r_weiss * r46653 10/brlcad/trunk/include/raytrace.h: Updated raytrace.h to turn on the prototype triangulation of nmg primitives. |
| 21:40.50 | brlcad | r_weiss' change really begs for some thorough retesting with the conversion script |
| 21:48.33 | CIA-133 | BRL-CAD: 03r_weiss * r46654 10/brlcad/trunk/src/librt/primitives/ars/ars.c: Updated ars.c to turn on changes which were disabled until the prototype version of nmg triangulation was enabled. |
| 21:52.00 | CIA-133 | BRL-CAD: 03n_reed * r46655 10/brlcad/trunk/src/external/CMakeLists.txt: syntax error |
| 21:59.04 | starseeker | brlcad: the pattern being my files having busted whitespace? |
| 22:00.05 | starseeker | hides |
| 22:02.26 | starseeker | tried to set his editors to behave, really he did... |
| 22:08.29 | starseeker | winces - did Richard see your source release announcement? |
| 22:09.47 | starseeker | makes a note to look into astyle sometime http://astyle.sourceforge.net/ |
| 22:35.12 | CIA-133 | BRL-CAD: 03r_weiss * r46656 10/brlcad/trunk/src/librt/primitives/tor/tor.c: Updated file tor.c to enable removing of zero length edges from torus primitives. This was disabled until the prototype nmg triangulation was made available. |
| 23:09.00 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 23:45.57 | starseeker | huh - of course it's not quite the same since the tcl pkgIndex building macros aren't firing, but if I turn off docbook and compare: |
| 23:46.50 | starseeker | make: 7m8s, ninja: 6m13s to build all of BRL-CAD on my gentoo box |
| 23:47.13 | starseeker | (debug config) |
| 01:00.16 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 01:00.17 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 01:23.04 | CIA-133 | BRL-CAD: 03brlcad * r46657 10/brlcad/trunk/sh/ws.sh: |
| 01:23.04 | CIA-133 | BRL-CAD: wow, the 'e' case has been wrong from the get-go but only now seen with the |
| 01:23.04 | CIA-133 | BRL-CAD: inadvertent modification of src/external/CMakeLists.txt where it removed the (0) |
| 01:23.04 | CIA-133 | BRL-CAD: at the end of the file. this was due to using emacs-style quoting of the () |
| 01:23.04 | CIA-133 | BRL-CAD: parens instead of perl's unquoted style. fixed to the original intent of |
| 01:23.05 | CIA-133 | BRL-CAD: ensuring that text files have a trailing newline. |
| 01:23.57 | brlcad | misses the 2min enable-all compiles, that was a couple years of super high-productivity |
| 01:24.35 | brlcad | changes how you code when you can turn a build around in less than 3min, about as drastic as 3sec builds do for test code |
| 01:38.54 | CIA-133 | BRL-CAD: 03brlcad * r46658 10/brlcad/trunk/sh/ws.sh: the $ anchor matches a newline at end of file, so use the \z metasymbol instead to match the true end of string, which with 0777 should be the EOF. |
| 02:02.42 | CIA-133 | BRL-CAD: 03brlcad * r46659 10/brlcad/trunk/ (22 files in 18 dirs): more ws consistency, trailing ws elimination, and such. |
| 03:19.41 | starseeker | brlcad: the difference may be more pronounced on a non-gentoo box |
| 03:20.13 | starseeker | on this machine I'd get >50% of that time is straight up C/C++ compilation |
| 03:20.25 | starseeker | s/get/guess |
| 03:44.26 | starseeker | not sure how to benchmark that, come to think of it... |
| 04:13.21 | starseeker | brlcad: has the svn entries format changed? I don't see any name= strings in mine here... |
| 06:19.29 | brlcad | it's the same here, but certainly possible .. the files are listed there somewhere, though |
| 06:19.38 | brlcad | alternative to searching the files is to ask svn directly |
| 06:19.40 | brlcad | svn info -R | grep Path | awk '{print $2}' |
| 11:17.25 | *** join/#brlcad kunigami (~kunigami@201.82.92.180) | |
| 13:08.34 | CIA-133 | BRL-CAD: 03starseeker * r46660 10/brlcad/trunk/misc/CMake/distcheck_buildsys.cmake.in: Not functional yet, but start working on logic to snarf file lists from svn info and do something intelligent with them. |
| 14:09.22 | brlcad | nice |
| 14:15.41 | starseeker | will be even nicer when I figure out how to manipulate it right - it's Not Doing What I Want right now :-P |
| 14:15.55 | starseeker | still, I think the proof of concept is there |
| 14:16.32 | starseeker | I take it the key operation is to compare the results of the expanded tarball archive with the subversion manifests? |
| 14:17.17 | starseeker | (we don't really care about the original source archive except insofar as detecting modified files disqualifies the tarball from "distribution ready status"?) |
| 17:47.15 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096600997.dsl.bell.ca) | |
| 18:03.28 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 22:12.27 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 23:03.08 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 23:17.38 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 23:23.46 | *** join/#brlcad DarkCalf (DC@2002:ade7:2862::ade7:2862) | |
| 02:11.00 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 02:14.06 | starseeker | yay, couches are in |
| 02:49.35 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) | |
| 02:49.44 | yukonbob | hello, #brlcad |
| 03:48.05 | *** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net) | |
| 03:56.02 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 03:56.11 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 08:16.46 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) | |
| 11:09.55 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 12:27.39 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 13:12.11 | kunigami | hm, I'm getting the following error with mged after a clean build: http://paste.ubuntu.com/686851/ (mac os) |
| 13:20.16 | CIA-133 | BRL-CAD: 03Kunigami 07http://brlcad.org * r3155 10/wiki/User:Kunigami: updated profile |
| 13:22.14 | CIA-133 | BRL-CAD: 03Kunigami 07http://brlcad.org * r3156 10/wiki/User:Kunigami: added more information |
| 13:58.05 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 15:02.35 | starseeker | kunigami: can you get a gdb backtrace? |
| 15:09.15 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 15:13.59 | kunigami | starseeker: seems a tcl/tk issue: http://paste.ubuntu.com/686945/ |
| 15:15.06 | starseeker | erum |
| 15:15.23 | starseeker | apparently it doesn't like your freetype |
| 15:15.31 | starseeker | iirc it was finding a freetype in opt? |
| 15:15.46 | starseeker | do you have one in the "normal" system install for Mac? |
| 15:18.12 | kunigami | starseeker: yup, I have one at /usr/X11/lib |
| 15:18.37 | starseeker | if you could, edit your CMakeCache.txt file result pertaining to freetype to point to the one in /usr |
| 15:19.01 | starseeker | FREETYPE_LIBRARY in particular |
| 15:19.04 | ``Erik | if linking gets both /opt/local and /usr/X11, there might be symbol issues between the two |
| 15:19.34 | starseeker | had to jump through hoops for X11 and OpenGL, looks like freetype needs to get added to the mix |
| 15:19.43 | starseeker | yargh |
| 15:19.44 | ``Erik | starseeker needs to figure out how to convince cmake to ONLY use /opt/local if those exists O.o :) |
| 15:20.05 | starseeker | kunigami: then just run "make" again - cmake will rerun itself |
| 15:20.16 | starseeker | <snort> |
| 15:20.31 | starseeker | usually go for the system versions |
| 15:21.08 | ``Erik | personally, I'd favor the macports or fink variants... they tend to be a lot more recent and less ... 'adjusted' |
| 15:21.42 | starseeker | if I REALLY wanted to get fancy I could try detecting macports/fink installations and then making a sort of global "Use System/MacPorts/Fink" versions of things |
| 15:22.09 | ``Erik | I think the auto* stuff had exactly that |
| 15:23.11 | starseeker | what's a good way to reliably detect macports and/or fink? |
| 15:23.28 | ``Erik | aaaanyways, it's sunday morning, I spent yesterday dragging my sick arse around the rennfest, and I believe my sick arse is going to the botanical gardens O.o |
| 15:23.38 | starseeker | uh oh |
| 15:23.48 | ``Erik | um, I believe both have a program called "port" |
| 15:24.02 | ``Erik | a tcl variant of the fbsd ports or gentoo portage |
| 15:24.10 | ``Erik | yes, it really is that sick. |
| 15:24.53 | starseeker | kunigami: you're using macports you said? |
| 15:25.02 | kunigami | starseeker: yup |
| 15:25.09 | starseeker | ``Erik: hey, gentoo is copying freebsd more or less :-P |
| 15:25.44 | ``Erik | quite aware, I believe my first port commit to fbsd was 2001... :) |
| 15:25.47 | starseeker | kunigami: is the "port" command in your normal system path? |
| 15:26.05 | ``Erik | no, it's in the macports dir |
| 15:26.11 | kunigami | starseeker: yes |
| 15:26.23 | ``Erik | macports will attempt to adjust your $PATH in your .bashrc for you |
| 15:26.30 | starseeker | ``Erik: so to freebsd folk gentoo is like some sick distorition from a horror movie in the mirror? :-P |
| 15:26.53 | starseeker | kunigami: does your ports command tell you if it's a macports or fink port? |
| 15:26.59 | ``Erik | more like a little kid jumping up and down and saying "me too!" |
| 15:27.06 | starseeker | (e.g. port -v or port --some-option?) |
| 15:27.28 | ``Erik | $port -v |
| 15:27.33 | ``Erik | MacPorts 2.0.99 |
| 15:27.37 | kunigami | starseeker: it tells me "MacPorts 2.0.1" |
| 15:27.39 | starseeker | awesome |
| 15:27.57 | starseeker | does it happen to tell you where macports is installed? |
| 15:28.07 | starseeker | or is the path to the port binary a reliable indicator? |
| 15:28.48 | ``Erik | fink uses /sw/, macports uses /opt/local |
| 15:29.04 | starseeker | consistently? |
| 15:29.11 | starseeker | or can users change the install local? |
| 15:29.15 | ``Erik | glenns did something stupid and work macs use /usr/local/macports or something stupid like that |
| 15:30.05 | starseeker | nods - so I'd like to key off the location of port if possible |
| 15:30.15 | starseeker | and then use port -v to identify fink vs macports |
| 15:30.22 | ``Erik | 99.99% of users will be either /sw for fink or /opt/local for macports |
| 15:30.40 | starseeker | so /sw/bin/port for fink? |
| 15:31.05 | kunigami | starseeker: my ports seems to be in /opt/local too. don't know how to get this information from port itseilf |
| 15:31.21 | ``Erik | I think, it's been a bazillion years since I've used fink |
| 15:31.22 | starseeker | is assuming some folks will have both fink and macports at the same time, so will have to sort that out (when possible) |
| 15:31.37 | ``Erik | man 3 read |
| 15:31.40 | starseeker | kunigami: as long as port is located in /opt/local/bin we should be good |
| 15:31.44 | ``Erik | er, wait, 1? hrm |
| 15:32.00 | ``Erik | there's a bash read command, might be usefull... "I cn't guess, tell me" |
| 15:32.46 | starseeker | find_program(PORT_BIN port) should do the trick and give me the full path to port |
| 15:33.07 | starseeker | then I'll run port -v (hopefully the fink version supports that too) and snarf macports or fink out of the result |
| 15:33.39 | starseeker | then do a little path surgery and either enforce or ignore searching in sw or opt/local or whatever (that'll be the trickest bit, probably) |
| 15:34.13 | starseeker | then I can revert a lot of the changes I made to the FindX11 and FindGL cmake scripts, which would be a Good Thing |
| 15:35.24 | ``Erik | later tonight, I'll look at my ancient g3 ibook and see if it's fink only and how to detect that... otherwise, everything I have is all mac ports, srry |
| 15:35.35 | starseeker | no biggie |
| 15:35.59 | ``Erik | a dmg with a self contained .app is what most mac users will expect *shrug* |
| 15:36.22 | starseeker | I just have to figure out how to exclusivly search for stuff only system or first macports then sytem (ignoring fink if there) or first fink then system (ignoring macports if there) |
| 15:36.26 | starseeker | blegh |
| 15:36.51 | starseeker | nods - but for people doing devel on Mac, the fink and macports installs are a Common Problem |
| 15:37.03 | starseeker | which means we really should handle it Right if it can be handled Right |
| 15:38.30 | starseeker | kunigami: you might end up having to play guinea pig to test some detection logic - I don't have a macports mac handy ;-) |
| 15:38.49 | starseeker | probably won't be today though |
| 15:38.54 | starseeker | more house stuff to do |
| 15:39.04 | kunigami | no problem :) |
| 15:39.25 | starseeker | kunigami: in the meantime, does setting the freetype to your system version work? |
| 15:39.59 | kunigami | starseeker: nope :( I just edited the path for libfontconfig and I'm compiling again |
| 15:41.11 | starseeker | absolute worst case we may have to look at what the TEA tcl/tk build is doing for that system - it's always possible the CMake logic missed a trick |
| 15:41.58 | starseeker | (the autotools build just got fixed thanks mostly to ``Erik and brlcad, so it should be viable to try that as well to see if it works) |
| 15:46.06 | kunigami | starseeker: changing both libfontconfig and libfreetype paths did the trick. Thanks! |
| 16:22.53 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 16:26.31 | kunigami | Is there any simple scene where I can apply osl shaders? (besides cornell). All files I'm opening have tons of regions :( |
| 17:07.28 | *** join/#brlcad kunigami (~kunigami@201.82.92.180) | |
| 17:18.55 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 18:31.06 | ``Erik | mossworld.g ? |
| 22:45.52 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 04:59.57 | brlcad | autotools had no fink/macports-specific logic -- it was attempted very early on but was quickly completely removed because of all the problems it caused |
| 05:04.08 | brlcad | kunigami1: a real scene would make the best demo .. the complexity of the model shouldn't matter |
| 05:04.39 | brlcad | it's pretty easy to change the shader on all objects in a hierarchy |
| 05:04.52 | brlcad | or apply a new shader to a top-level and have it override everything below |
| 07:37.49 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 09:58.18 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 10:14.08 | *** join/#brlcad kunigami (~kunigami@201.82.92.180) | |
| 11:17.34 | *** join/#brlcad kunigami (~kunigami@201.82.92.180) | |
| 13:08.18 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:39.27 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 14:24.05 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 14:55.42 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 15:16.58 | CIA-133 | BRL-CAD: 03r_weiss * r46661 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: Updated file nmg_tri.c to quiet compiler warnings. |
| 16:36.51 | *** join/#brlcad merzo (~merzo@72-107-132-95.pool.ukrtel.net) | |
| 17:51.09 | *** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net) | |
| 18:19.26 | CIA-133 | BRL-CAD: 03starseeker * r46662 10/brlcad/trunk/ (10 files in 8 dirs): Still experimental, but make a stab at being able to enable/disable fink and macports on Macs. |
| 18:29.14 | CIA-133 | BRL-CAD: 03starseeker * r46663 10/brlcad/trunk/misc/CMake/Fink_MacPorts.cmake: remove debugging print statements |
| 19:24.56 | *** join/#brlcad alex_joni (~alex_joni@81.196.65.201) | |
| 19:24.57 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 19:36.01 | abhi2011 | hmm, I have been trying to provide the proper paramters to ged_mater() to get an object autmatically shaded |
| 19:36.15 | abhi2011 | but it seems ged_mater() is no longer used for the mater commands |
| 19:36.26 | abhi2011 | it seems to be going to ged_glob() now |
| 19:37.22 | brlcad | ged_glob does glob name expansion, so *.tgc will expand to "asdf.tgc foo.tgc" |
| 19:38.39 | abhi2011 | ok |
| 19:39.52 | abhi2011 | hmm but after that, in cmd_ged_plain_wrapper(), it should call get_mater() |
| 19:40.26 | abhi2011 | hmm no its probably called from a different place |
| 19:40.59 | abhi2011 | i was trying to set a break point in the ged_mater() function to see what paramters gets passed |
| 19:41.14 | abhi2011 | but control never seems to land there |
| 19:43.50 | abhi2011 | thought I could shade objects to any color by simply calling ged_mater() with the proper parameters |
| 20:01.49 | abhi2011 | yup best to use avs and librt directly |
| 20:09.43 | *** join/#brlcad Stattrav (~Stattrav@203.196.190.162) | |
| 20:10.02 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:11.19 | brlcad | abhi2011: not all commands in mged are hooked into libged yet -- archer uses libged exclusively |
| 20:14.34 | brlcad | you have to look at the command binding table in mged (setup.c) to see what actually gets called |
| 20:15.45 | brlcad | that said, setup.c does list ged_mater() for 'mater', so you inability to set a breakpoint is probably a different problem |
| 21:10.16 | *** join/#brlcad merzo (~merzo@60-98-133-95.pool.ukrtel.net) | |
| 21:22.38 | abhi2011 | ok got the color in now for showing the object state with respect to physics |
| 21:23.08 | abhi2011 | colors are different now for idle, active and sleeping states...purely for debugging later on |
| 21:23.31 | abhi2011 | now looking to draw the bounding box for each object as reported by bullet |
| 21:24.21 | abhi2011 | so looking for a single command that lets me make a nearly transparent arb8 , with some light color and with the vertices i specifiy |
| 22:08.04 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 22:25.23 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 22:54.45 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 23:07.59 | brlcad | abhi2011: mk_arb8() or mk_rpp() will make a box, mk_comb() to make a combination -- there you can specify a mater string and color |
| 23:09.41 | *** join/#brlcad kunigami1 (~kunigami@loco-gw.ic.unicamp.br) | |
| 00:02.13 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 00:16.47 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 00:18.53 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 01:11.43 | *** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 02:57.51 | CIA-133 | BRL-CAD: 03starseeker * r46664 10/brlcad/trunk/misc/CMake/distcheck_buildsys.cmake.in: |
| 02:57.51 | CIA-133 | BRL-CAD: Total rework of distcheck. Not 'hooked up' but it can spot disagreements |
| 02:57.51 | CIA-133 | BRL-CAD: between build logic and svn info results. Main problem right now is diffing the |
| 02:57.51 | CIA-133 | BRL-CAD: two generated text files - CMake is hideously slow at what should be a quick, |
| 02:57.51 | CIA-133 | BRL-CAD: easy task. May need to provide minimalist diff utility for this to work |
| 02:57.52 | CIA-133 | BRL-CAD: acceptably performance wise, but it does appear that it will work. |
| 03:11.14 | CIA-133 | BRL-CAD: 03starseeker * r46665 10/brlcad/trunk/ (97 files in 97 dirs): Closing in on svn-ified distcheck for CMake, if performance issues can be addressed. |
| 03:17.18 | *** join/#brlcad DarkCalff (DC@173.231.40.98) | |
| 04:23.30 | CIA-133 | BRL-CAD: 03starseeker * r46666 10/brlcad/trunk/ (doc/CMakeLists.txt src/librtserver/CMakeLists.txt): Couple more CMakeLists.txt tweaks |
| 04:54.58 | CIA-133 | BRL-CAD: 03brlcad * r46667 10/brlcad/trunk/include/ (config_win.h config_win_cmake.h.in): |
| 04:54.58 | CIA-133 | BRL-CAD: add compatibility macros for S_ISDIR(), S_ISREG(), and S_ISLNK(). for the first |
| 04:54.58 | CIA-133 | BRL-CAD: two, the existing S_IF* defines are sufficient, but we punt for symbolink links. |
| 04:54.58 | CIA-133 | BRL-CAD: could maybe do something for 'shortcuts' but it would probably be the suck. |
| 04:56.36 | CIA-133 | BRL-CAD: 03brlcad * r46668 10/brlcad/trunk/include/bu.h: add a declaration for a new bu_file_directory() function that returns truthfully whether a given filepath is one. add a note that bu_file_delete() tries really really hard to delete the file. |
| 04:59.30 | CIA-133 | BRL-CAD: 03brlcad * r46669 10/brlcad/trunk/include/bu.h: add bu_file_symoblic() while we're at it for api-completeness. |
| 05:01.33 | CIA-133 | BRL-CAD: 03brlcad * r46670 10/brlcad/trunk/src/libbu/file.c: add initial implementations for bu_file_directory() and bu_file_symbolic() |
| 05:52.12 | CIA-133 | BRL-CAD: 03starseeker * r46671 10/brlcad/trunk/misc/ (CMake/distcheck_buildsys.cmake.in CMakeLists.txt comm.c): |
| 05:52.13 | CIA-133 | BRL-CAD: Not entirely clear if we can keep CMake's notions of sorting compatible with |
| 05:52.13 | CIA-133 | BRL-CAD: comm's, but in some early testing this seems to work - a little libbu-ification |
| 05:52.13 | CIA-133 | BRL-CAD: of netbsd's comm code (very simple if we can get away with it) and presto, |
| 05:52.13 | CIA-133 | BRL-CAD: distcheck is failing (correctly) in reasonable time. |
| 07:34.54 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 08:42.00 | CIA-133 | BRL-CAD: 03173.208.18.213 07http://brlcad.org * r3157 10/wiki/Ahahahahaha_What_reputation_Quiet_you_11: New page: [[Image:reputation_management_3486.jpg|thumb|]] Bulgarian Exports to European Union Soar [] TourDeFrance starts today! Will it be the same without ? Get on your bike here - One step ahead... |
| 09:39.01 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 11:11.35 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 11:39.47 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 12:19.02 | CIA-133 | BRL-CAD: 03erikgreenwald * r46672 10/brlcad/trunk/misc/CMakeLists.txt: add TCL_INCLUDE_DIRS to satisfy the use of bu.h |
| 12:19.25 | CIA-133 | BRL-CAD: 03tbrowder2 * r46673 10/brlcad/trunk/doc/docbook/books/README: correct typo |
| 12:27.09 | CIA-133 | BRL-CAD: 03tbrowder2 * r46674 10/brlcad/trunk/doc/docbook/resources/standard/xsl/README: correct typos |
| 12:28.02 | CIA-133 | BRL-CAD: 03tbrowder2 * r46675 10/brlcad/trunk/doc/docbook/resources/standard/xsl/highlighting/README: correct typo |
| 12:44.33 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 13:16.21 | CIA-133 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.18.213]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 13:16.21 | CIA-133 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Ahahahahaha What reputation Quiet you 11]]": spam |
| 13:34.33 | CIA-133 | BRL-CAD: 03brlcad * r46676 10/brlcad/trunk/src/libbu/malloc.c: if the caller passes a NULL string value, don't rely on libc to do something reasonable with it. turn it into '(null)' for the debug printing (which is what most libc impls do now anyways). |
| 14:28.31 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 14:56.07 | *** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net) | |
| 14:56.12 | yukonbob | hello #brlcad |
| 15:18.37 | brlcad | hello |
| 15:56.37 | *** join/#brlcad plaes (~plaes@gn237.zone.eu) | |
| 15:57.28 | jordisayol | brlcad: what about the new 7.20.4 source release? |
| 16:43.43 | brlcad | jordisayol: yeah, got distracted with some other coding |
| 18:12.27 | CIA-133 | BRL-CAD: 03erikgreenwald * r46677 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: s/static/HIDDEN/ |
| 20:41.09 | CIA-133 | BRL-CAD: 03starseeker * r46678 10/brlcad/trunk/doc/docbook/Makefile.am: Sort the files for EXTRA_DIST docbook |
| 21:37.16 | *** join/#brlcad merzo (~merzo@100-177-133-95.pool.ukrtel.net) | |
| 23:15.44 | abhi2011 | trying to get a glass shader to work |
| 23:15.47 | abhi2011 | shader gp.r "glass {tr 0.8 re 0.7}" 0 0 255 |
| 23:15.59 | abhi2011 | but mged refusing to accept it |
| 00:04.01 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 00:04.49 | brlcad | mm e-mail troll |
| 00:35.44 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 00:51.23 | abhi2011 | brlcad , is there a way to change the rt resolution from the default 512 by 512 |
| 00:56.24 | abhi2011 | ok got it |
| 00:56.28 | abhi2011 | the -s option |
| 01:00.14 | abhi2011 | hmm trying with -s1024, seems like have to leave the rendering job overnight :P |
| 01:10.42 | CIA-133 | BRL-CAD: 03abhi2011 * r46679 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c simulate.h): Added code to simulate command for showing bounding boxes and rigid body activation state |
| 01:24.01 | CIA-133 | BRL-CAD: 03starseeker * r46680 10/brlcad/trunk/ (6 files in 4 dirs): More distcheck progress, although there's still at least one bug to iron out. |
| 03:17.59 | brlcad | abhi2011: the number of pixels increases quadratically as you increase the image size |
| 03:18.27 | brlcad | so going from 512x512 to 1024x1024 is a 4x increase in the number of pixels being rendered |
| 03:21.08 | brlcad | usually better to get your scene set up exactly how you want it at 256x256 or similar without materials for a quick preview, then render high at some much higher resolution (I tend to like 4096x4096 with jitter and hypersampling) with materials and custom light sources |
| 03:21.37 | brlcad | but then those usually beg for some quick distributed rendering with lots of computers :) |
| 03:27.44 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 05:18.45 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 05:18.45 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 11:38.52 | CIA-133 | BRL-CAD: 03starseeker * r46681 10/brlcad/trunk/src/libged/simulate/simulate.c: comment out rv until it's actually used, breaks strict building as the code currently stands. |
| 12:00.34 | CIA-133 | BRL-CAD: 03starseeker * r46682 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_Util.cmake): fix paths that are appended to cmakefiles.cmake and cmakedirs.cmake |
| 12:25.03 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 12:56.07 | CIA-133 | BRL-CAD: 03tbrowder2 * r46683 10/brlcad/trunk/doc/docbook/Makefile.am: correct XSLTPROC options; add new document to tree |
| 13:17.26 | CIA-133 | BRL-CAD: 03starseeker * r46684 10/brlcad/trunk/ (28 files in 5 dirs): (log message trimmed) |
| 13:17.26 | CIA-133 | BRL-CAD: Variety of distcheck fixes, including a nifty problem where a directory named |
| 13:17.26 | CIA-133 | BRL-CAD: 'off' was causing a logic failure in the path building logic. dist files are |
| 13:17.26 | CIA-133 | BRL-CAD: now actual cmake files that are included - this allows CMake to re-run after one |
| 13:17.26 | CIA-133 | BRL-CAD: is edited, which is the correct behavior. directories that are specified (as |
| 13:17.27 | CIA-133 | BRL-CAD: opposed to recognized as parents of files specfied) use svn info to build the |
| 13:17.28 | CIA-133 | BRL-CAD: list of files below the ignored directory, which means temporary files should be |
| 13:41.14 | CIA-133 | BRL-CAD: 03tbrowder2 * r46685 10/brlcad/trunk/doc/docbook/presentations/ (13 files in 3 dirs): new document added to tree |
| 14:08.24 | CIA-133 | BRL-CAD: 03brlcad * r46686 10/brlcad/trunk/doc/docbook/Makefile.am: fully sort the list |
| 14:08.56 | CIA-133 | BRL-CAD: 03Tbrowder 07http://brlcad.org * r3158 10/wiki/FAQ: add a new bit of trivia from the old-timers |
| 14:17.39 | CIA-133 | BRL-CAD: 03starseeker * r46687 10/brlcad/trunk/misc/CMake/distcheck_buildsys.cmake.in: |
| 14:17.39 | CIA-133 | BRL-CAD: OK. First rule if building a dist tarball from a tarball or other non-svn |
| 14:17.39 | CIA-133 | BRL-CAD: checkout source, don't. CPack has no way of knowing what to exclude in the |
| 14:17.39 | CIA-133 | BRL-CAD: fully ignored sub-directories. If you must, distcheck will do what it can where |
| 14:17.39 | CIA-133 | BRL-CAD: it can to spot files that don't belong, and warn you of your peril. |
| 14:20.59 | CIA-133 | BRL-CAD: 03Tbrowder 07http://brlcad.org * r3159 10/wiki/SVN: add link to some more SVN info |
| 14:27.42 | CIA-133 | BRL-CAD: 03Tbrowder 07http://brlcad.org * r3160 10/wiki/SVN: |
| 14:29.52 | CIA-133 | BRL-CAD: 03Tbrowder 07http://brlcad.org * r3161 10/wiki/SVN: add link to more svn info |
| 14:50.24 | CIA-133 | BRL-CAD: 03starseeker * r46688 10/brlcad/trunk/misc/CMake/distcheck_buildsys.cmake.in: |
| 14:50.24 | CIA-133 | BRL-CAD: Be nice to the users, if the ignored file count gets too large refer them to a |
| 14:50.24 | CIA-133 | BRL-CAD: file instead of dumping thousands of lines to the terminal. Need to do |
| 14:50.24 | CIA-133 | BRL-CAD: something more intelligent for in-src distcheck building, which is what prompted |
| 14:50.24 | CIA-133 | BRL-CAD: the change, but might as well handle this for cases with lots of stray files |
| 14:50.25 | CIA-133 | BRL-CAD: too. |
| 14:56.06 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:07.45 | CIA-133 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3162 10/wiki/User:Abhijit: /* Log */ |
| 15:16.21 | CIA-133 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3163 10/wiki/User:Abhijit: /* Development timeline */ |
| 15:32.20 | CIA-133 | BRL-CAD: 03tbrowder2 * r46689 10/brlcad/trunk/doc/docbook/Makefile.am: more file name sorting |
| 16:16.37 | brlcad | interesting, http://www.cs.washington.edu/research/constraints/cassowary/ |
| 16:32.02 | brlcad | secondary lead if spirit work ever hits a roadblock |
| 16:51.07 | CIA-133 | BRL-CAD: 03tbrowder2 * r46690 10/brlcad/trunk/doc/docbook/README: added blub on new presentations directory |
| 16:52.50 | CIA-133 | BRL-CAD: 03tbrowder2 * r46691 10/brlcad/trunk/doc/docbook/ (Makefile.am system/man1/en/Makefile.am): renamed build variable to better track file tree name |
| 16:53.13 | *** join/#brlcad Stattrav (~Stattrav@61.12.114.82) | |
| 16:53.13 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:55.36 | starseeker | brlcad: does it do floating point? |
| 16:56.45 | starseeker | ah, I think I've run across that before |
| 16:57.29 | starseeker | that also needs GTL: http://www.fim.uni-passau.de/en/fim/faculty/chairs/theoretische-informatik/projects.html |
| 16:58.53 | starseeker | O.o am I seeing that right, Apple is using it? |
| 17:00.48 | starseeker | perhaps I underestimated it |
| 17:05.19 | starseeker | looks like it also wants guile |
| 17:29.58 | brlcad | nods |
| 17:30.29 | brlcad | it's also dead/unsupported along with GTL, but an interesting lib nonetheless |
| 17:31.24 | brlcad | i'd be a little surprised if guile was actually required |
| 17:31.30 | brlcad | there's lots of bindings to various languages, I suspect that's where it's used |
| 17:35.04 | starseeker | nods - yeah, most of it looks like demos |
| 17:35.21 | starseeker | probably not too hard to get the interesting subset building |
| 17:35.57 | starseeker | nifty: http://www.badros.com/greg/cassowary/js/quaddemo.html |
| 17:36.55 | starseeker | is quite intrigued by Apple's use |
| 17:43.53 | starseeker | doesn't see any code from Apple on the cassowary site... wonder if they just used it as-is? |
| 17:44.02 | starseeker | would be surprising for code that old |
| 17:46.34 | starseeker | brlcad: was that the academic library you were thinking of? |
| 17:47.26 | starseeker | vaguely remembers getting as far as determining it needed GTL and that GTL still exists before, but I didn't follow up since gecode looked more modern and maintained |
| 17:48.20 | starseeker | wasn't fully aware of gecode's lack of floating point solver support at the time |
| 18:00.26 | brlcad | starseeker: it might have been, don't remember for certain |
| 18:01.14 | starseeker | will play with it later - struggling to convince CPack not to include build files in its tarballs |
| 18:01.18 | brlcad | still, greener pastures and all -- it's just a good thought to keep in mind's back pocket, maybe wire up to the libpc test cases to see how it does |
| 18:01.51 | starseeker | may have to at least require a subdirectory within the source tree - the source=build case is a nightmare |
| 18:02.12 | brlcad | nightmare in what sense? |
| 18:02.37 | starseeker | I have to tell CPack to exclude files, but the simple act of RUNNING cpack within the build tree creates more files |
| 18:03.07 | starseeker | which I can't list for CPack because they don't exist ahead of time |
| 18:03.22 | brlcad | you mean for distcheck? |
| 18:03.24 | starseeker | yeah |
| 18:04.05 | brlcad | if it's *only* for distchecking, not a big deal -- or even let cpack pack them, it'll just warn on them down the line |
| 18:04.33 | starseeker | as long as it's smart enough to not be recursive, I guess... |
| 18:04.34 | brlcad | in practice for proper dist building, it can be out of dir no worries |
| 18:05.11 | brlcad | in source build support is really only needed to support simple compilation/install |
| 18:05.30 | brlcad | distchecking is "in-house stuff, in-house rules" |
| 18:05.54 | starseeker | I thought one of the points though was to verify the tarball had everything we wanted it to |
| 18:06.01 | brlcad | sure |
| 18:06.13 | starseeker | (admittedly that works a little different now, with that verification happening up front, sorta...) |
| 18:06.35 | brlcad | so it has too much if someone built in-dir and ran distcheck, but it could warn and still run all the tests |
| 18:07.03 | starseeker | nods... true |
| 18:07.28 | brlcad | checking the tarball is only half the picture, and the lesser-utilized half at that |
| 18:07.41 | brlcad | the other half of the distcheck is all the testing |
| 18:07.54 | brlcad | that is desirable to run and re-run as often as possible |
| 18:08.16 | brlcad | so is distcheck ready to go now? |
| 18:08.26 | brlcad | I'm going through commits now to see if everything is documented |
| 18:08.43 | starseeker | close, but I wouldn't consider it properly hooked in yet |
| 18:10.31 | CIA-133 | BRL-CAD: 03brlcad * r46692 10/brlcad/trunk/NEWS: tom converted traNese's intro to Tcl/Tk presentation into the docbook format. that means it'll get installed in html form (and potentially as pdf). |
| 18:10.42 | brlcad | close enough for me to distcheck a source release tarball? :) |
| 18:10.55 | starseeker | urm. from out of dir build, maybe |
| 18:11.13 | brlcad | was hoping for better than maybe :D |
| 18:11.32 | starseeker | brlcad: I've totally rewritten it twice in the last two days :-P |
| 18:11.36 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 18:11.38 | starseeker | it's hard to be definitive just yet |
| 18:11.41 | brlcad | I know, that's why I'm asking |
| 18:12.47 | brlcad | abhi2011: how's that render coming along? |
| 18:13.06 | brlcad | wants to set up his own scene here real soon now... |
| 18:24.29 | jordisayol | brlcad: I see that "sh/make-deb.sh" was modified by tbrowder2 |
| 18:25.28 | jordisayol | brlcad: is there some problem with my maintenance? |
| 18:25.44 | piksi | are there screenshots or feature lists of the current archer ui? |
| 18:26.29 | CIA-133 | BRL-CAD: 03brlcad * r46693 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: if the code added to quiet compiler warnings has to also be quieted (with #if 0), then it should just be removed... |
| 18:30.18 | starseeker | piksi: this is fairly current: http://bzflag.bz/~starseeker/archer_win32_native_built_docs.png |
| 18:30.58 | starseeker | this is still fairly close appearance wise: http://bzflag.bz/~starseeker/archer_latest.png |
| 18:31.41 | brlcad | jordisayol: not at all, at least not that I'm aware of -- were the changes significant/controversial? |
| 18:31.55 | brlcad | I think he was just trying to help |
| 18:32.29 | brlcad | tom's a relatively new committer, communicates via mailing list |
| 18:32.49 | jordisayol | brlcad: I'm just checking, it appear that only added a "test dependency only" ability |
| 18:33.55 | jordisayol | brlcad: is just to know if I have to continue to build new deb/rpm packages |
| 18:33.59 | piksi | starseeker: thanks. last time i tried modeling something with MGED i found it extremely cumbersome compared to e.g. current versions of autocad or autodesk revit. archer ui looks pretty much like autocad circa 2004. what kind of an ui philosophy is being used with archer? |
| 18:34.12 | brlcad | jordisayol: oh, please! :) |
| 18:34.46 | brlcad | you don't "have to" but it's greatly helpful and appreciated (as seen by the loads and loads of downloads) |
| 18:35.13 | starseeker | piksi: um. "make it not suck?" not sure what you mean by a ui philosophy |
| 18:35.30 | piksi | jordisayol is responsible for rpm packaging? |
| 18:35.40 | jordisayol | brlcad: no no, it's ok. i just want to know |
| 18:35.45 | piksi | then i have to thank you, i was pleasantly surprised to find a fedora package for my system :-) |
| 18:36.12 | jordisayol | piksi: i do my best, and yes i buils rpm packages |
| 18:36.18 | jordisayol | build* |
| 18:36.45 | jordisayol | piksi: is there some problem with them? |
| 18:36.54 | brlcad | piksi: my goal is towards a completely modeless redesigned ui but we're not going to get there in one jump |
| 18:37.18 | piksi | jordisayol: no, i was just very happy that there was an rpm and i didn't have to compile :-) |
| 18:37.33 | jordisayol | piksi: ;-) |
| 18:37.36 | piksi | starseeker: ui philosophy, i.e. all tools working in a consistent manner, designing the tools from the viewpoint of a designer (for example having good 3d snapping capabilities, versatile extruding/lofting/revolving tools etc) |
| 18:37.50 | brlcad | archer is already a huge stepping stone as it is, even if it just brings us into the 90's ;) .. to do more would increase risk of delays (or outright failure) |
| 18:39.26 | piksi | brlcad: if by mode you mean the command line type interface of autocad, i find it extremely fast compared to many of the recent autodesk ui changes that move towards clicking (without being "in a command state") |
| 18:39.43 | brlcad | a lot of the nifty UI features you mention require extensive backend support, too -- which has little if anything to do with the overarching ui design |
| 18:39.57 | jordisayol | brlcad: as a main developer, can You tell tbrowder2 to communicate me just ins deb/rpm modifications? just for a better building result |
| 18:40.22 | brlcad | piksi: that is not what is meant by mode, http://en.wikipedia.org/wiki/Mode_(computer_interface) |
| 18:40.25 | piksi | brlcad: yes, i understand that the ui features i'm longing for require an *extensive* framework which is not easy to do at all |
| 18:41.11 | piksi | brlcad: ah now i understood. yes, that is a good thing to avoid |
| 18:41.17 | brlcad | jordisayol: hm? didn't understand the "just ins" |
| 18:42.02 | brlcad | jordisayol: if you see something undesirable, you can revert it from the deb/rpm files -- that merely begs a dev-dev discussion |
| 18:42.04 | jordisayol | brlcad: sorry, is a typo. just for files directly involved in deb/rpm building packages |
| 18:42.37 | piksi | brlcad: is any kind of an input/suggestions/feature requests for the upcoming ui features needed or accepted from users? my background is in architecture but i've used brl from time to time to model csg-stuff instead of autocad |
| 18:43.01 | jordisayol | well, I've modified "sh/make_debsh" to disable source build, and now i find this modification, that's all |
| 18:43.05 | brlcad | fwiw, a commit effectively is a means of communication -- and one that's guaranteed to reach everyone |
| 18:43.22 | brlcad | otherwise it's a bit tricky with him on the mailing list and you on irc -- the discussions shouldn't be in private |
| 18:44.23 | starseeker | brlcad: yep, though so - new docbook stuff sets off cmake distcheck |
| 18:44.26 | starseeker | one sec... |
| 18:45.28 | jordisayol | brlcad: ok |
| 18:47.00 | brlcad | piksi: input/suggestions/feature requests are always welcome but with heeded caution that we've probably heard/thought of it too (we have a TODO list that probably represents a 1000-staff years of effort and that still wouldn't get us all the features of the "big five") |
| 18:47.11 | piksi | :-) |
| 18:47.44 | piksi | brlcad: yeah i wasn't expecting to introduce anything groundbreaking in terms of design. is the todo list public? |
| 18:47.55 | brlcad | piksi: more constructive is the suggestions that have real productive effort tied to them -- like coming up with a detailed use case or a real prototype mock up |
| 18:48.07 | piksi | yeah i always try to provide mockups |
| 18:49.25 | brlcad | even better is to relate it to the current state of the software, like looking at MGED or Archer's horrid menu hierarchy and detailing exactly what a new/better hierarchy would look like, etc |
| 18:50.09 | brlcad | as for the 3rd generation interface, a good bit of mock-up design effort has already happened (in a non-CAD/agnostic way to help with the underlying usability concepts) |
| 18:51.58 | brlcad | one prototype video is here: http://brlcad.org/design/gui/ |
| 18:52.17 | CIA-133 | BRL-CAD: 03starseeker * r46694 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/distcheck_buildsys.cmake.in): |
| 18:52.17 | CIA-133 | BRL-CAD: Deduce the in-source build directory rather than hardcode one devs typical |
| 18:52.17 | CIA-133 | BRL-CAD: defaults. Have the distcheck routine use the variable as well to clean up its |
| 18:52.17 | CIA-133 | BRL-CAD: output. Looks like this is helpful, but not clear yet if it is a full solution. |
| 18:53.03 | brlcad | jordisayol: to reiterate, if he modified one of the scripts your using and it affects your ability to prepare a release, there is ABSOLUTELY no problem reverting that change |
| 18:53.30 | brlcad | if it doesn't affect what you're doing or can be accommodated, then great .. just ignore it or accommodate or ask him to make it optional or whatever works ;) |
| 18:53.52 | brlcad | if you reply to the commit e-mail, it'll go to the brlcad-devel mailing list and reach him |
| 18:54.26 | jordisayol | brlcad: well,the only two files out of /misc/debian dir that I modified are make_deb.sh and make_rpm.sh |
| 18:54.42 | jordisayol | brlcad: and he modified make_deb.sh |
| 18:55.01 | starseeker | jordisayol: the changes conflict? |
| 18:55.33 | jordisayol | is not a bit modification, just added a new option to just test is dependencies are present in system and exit |
| 18:55.51 | jordisayol | is => if |
| 18:56.14 | brlcad | modifications are to be expected anywhere in the source tree, part of collaborative development |
| 18:56.42 | brlcad | what's really cool is having three devs all working in the same file at the same time, frequently updating, and just seeing the code flow :) |
| 18:57.00 | brlcad | i've only seen it a couple times in my career, but it's a thing of beauty :D |
| 18:57.29 | brlcad | hyperproductivity! |
| 18:58.19 | CIA-133 | BRL-CAD: 03starseeker * r46695 10/brlcad/trunk/doc/docbook/ (3 files in 3 dirs): Fix up the presentations CMakeLists.txt logic |
| 18:59.04 | jordisayol | brlcad: I apologize, I was surprised for this modification, that's all |
| 18:59.28 | starseeker | jordisayol: generally, that's a good thing - it means people are taking an interest in your work :-) |
| 19:00.26 | jordisayol | brlcad: yes, shure, but it can means to that i'm not doing it so good too :-) |
| 19:01.54 | brlcad | it didn't even occur to me to think that it meant you were doing something so good :) |
| 19:02.59 | brlcad | what starseeker said, just someone else taking an interest in the scripts, in what you'd done .. that's usually a "really good" thing |
| 19:03.57 | jordisayol | brlcad: You and starseeker have a couple of beers payed ;-) |
| 19:05.37 | starseeker | brlcad actually went to some trouble to remove individual authorship entries from the various source files and instead record them in the AUTHORS file - we don't want to wind up with a situation where people don't want to touch code because "it's somebody else's" |
| 19:06.53 | starseeker | so no worries - we're all trying to Make Things Better :-) |
| 19:08.46 | CIA-133 | BRL-CAD: 03brlcad * r46696 10/brlcad/trunk/NEWS: bob has initial support in for editing pipe primitives within archer. support for appending, prepending, deleting, moving, selecting, and scaling. |
| 19:13.23 | CIA-133 | BRL-CAD: 03starseeker * r46697 10/brlcad/trunk/CMakeLists.txt: |
| 19:13.23 | CIA-133 | BRL-CAD: Be sure we don't do anything in the case where the build and the source |
| 19:13.23 | CIA-133 | BRL-CAD: directories are the same directory - unless I'm missing some CPack option or |
| 19:13.23 | CIA-133 | BRL-CAD: feature (possible) that case is just not going to mix well with CPack's approach |
| 19:13.23 | CIA-133 | BRL-CAD: to archive creation. |
| 19:15.33 | starseeker | brlcad: cmake distcheck now succeeds |
| 19:18.05 | CIA-133 | BRL-CAD: 03starseeker * r46698 10/brlcad/trunk/CMakeLists.txt: fix if location |
| 19:25.59 | jordisayol | brlcad: there are some errors on tbrowder2 make_deb.sh modifications. He treat some packages names as executable files names, and this will cause the script failure |
| 19:29.56 | piksi | brlcad: thanks, i'll look into it |
| 19:31.31 | brlcad | piksi: the TODO file in any source distribution contains several hundred items (some huge, some tiny) |
| 19:31.48 | piksi | :-) |
| 19:32.30 | brlcad | the documentation section at the bottom is particularly ripe for getting involved in a useful way, but that extends to (unlisted) developer documents (aforementioned mockups etc) too |
| 20:05.31 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 20:05.31 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 20:05.31 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 20:05.31 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 20:05.31 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 20:05.31 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 20:05.31 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 20:05.31 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 20:05.31 | *** join/#brlcad plaes (~plaes@gn237.zone.eu) | |
| 20:05.31 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 20:05.31 | *** join/#brlcad kunigami1 (~kunigami@loco-gw.ic.unicamp.br) | |
| 20:05.31 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 20:05.31 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 20:05.31 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 20:05.31 | *** join/#brlcad CIA-133 (~CIA@cia.atheme.org) | |
| 20:19.05 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 20:45.23 | CIA-133 | BRL-CAD: 03starseeker * r46699 10/brlcad/trunk/ (4 files in 2 dirs): Make a stab at consolidation of all distcheck logic into one file. |
| 21:12.00 | CIA-133 | BRL-CAD: 03starseeker * r46700 10/brlcad/trunk/ (4 files in 2 dirs): Hmm. $(MAKE) isn't working as expected in EXECUTE_PROCESS - revert the one file solution. |
| 21:14.18 | starseeker | oh, duh - right, $(MAKE) is specific to make files |
| 21:21.17 | CIA-133 | BRL-CAD: 03starseeker * r46701 10/brlcad/trunk/CMakeLists.txt: Fix numbers on distcheck stages. |
| 21:24.35 | CIA-133 | BRL-CAD: 03starseeker * r46702 10/brlcad/trunk/CMakeLists.txt: try searching for cpack rather than hardcoding it. |
| 21:31.40 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 21:32.09 | CIA-133 | BRL-CAD: 03starseeker * r46703 10/brlcad/trunk/ (3 files in 2 dirs): completed distcheck does not necessarily imply distribution ready files, so don't assert that. No need for distcheck message file, and not using the old svncheck anymore. |
| 22:20.42 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 22:57.26 | CIA-133 | BRL-CAD: 03tbrowder2 * r46704 10/brlcad/trunk/doc/docbook/resources/docbook-5.0/ (36 files in 8 dirs): add DocBook schemas for validation |
| 22:58.30 | CIA-133 | BRL-CAD: 03tbrowder2 * r46705 10/brlcad/trunk/doc/docbook/Makefile.am: add make target for DocBook validation |
| 23:18.43 | CIA-133 | BRL-CAD: 03jordisayol * r46706 10/brlcad/trunk/sh/make_deb.sh: Correct some minor erros. |
| 23:58.28 | CIA-133 | BRL-CAD: 03r_weiss * r46707 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: Updated function nmg_isect_two_face2p_jra within file nmg_inter.c. Improved the logic for determining where edges should be cut. |
| 00:07.01 | CIA-133 | BRL-CAD: 03r_weiss * r46708 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mk.c: Updated function nmg_loop_g within file 'nmg_mk.c'. Changed the padding of the loop bounding box to only pad the dimension with is less than distance tolerance. The result is faster boolean operations on nmg primitives. |
| 00:28.22 | *** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 00:49.38 | CIA-133 | BRL-CAD: 03r_weiss * r46709 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: Updated function nmg_isect_two_face2p_jra in file 'nmg_inter.c' adding more conditions for edge cutting. |
| 02:02.53 | CIA-133 | BRL-CAD: 03tbrowder2 * r46710 10/brlcad/trunk/doc/docbook/fop.xconf.in: the docbook directory works fine as the base directory for fop |
| 02:14.13 | starseeker | growls - cassowary c++ will need updating |
| 02:21.47 | CIA-133 | BRL-CAD: 03tbrowder2 * r46711 10/brlcad/trunk/doc/docbook/fop.xconf.in: add more info and default fonts for embedding in pdf |
| 02:23.21 | CIA-133 | BRL-CAD: 03tbrowder2 * r46712 10/brlcad/trunk/doc/docbook/resources/fonts/ (15 files in 3 dirs): add GNU free fonts for defaults for pdf |
| 02:26.23 | CIA-133 | BRL-CAD: 03tbrowder2 * r46713 10/brlcad/trunk/doc/docbook/resources/offo-hyphenation-binary-v2.0/ (15 files in 3 dirs): add hyphenation for fop version 1.0 |
| 04:25.00 | *** join/#brlcad Stattrav (~Stattrav@61.12.114.82) | |
| 04:25.00 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:46.29 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 11:18.00 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 12:50.10 | CIA-133 | BRL-CAD: 03brlcad * r46714 10/brlcad/trunk/configure.ac: need HAVE_C99_FORMAT_SPECIFIERS to be defined for %zu printing |
| 13:15.49 | starseeker | brlcad: I emailed Tom on the list about the stuff he's adding to Docbook - let me know if I should yank it until the license questions are resolved |
| 13:22.02 | CIA-133 | BRL-CAD: 03brlcad * r46715 10/brlcad/trunk/src/libbu/argv.c: if we get a null argv, nothing to do |
| 14:25.39 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 16:16.00 | *** join/#brlcad Stattrav (~Stattrav@61.12.114.82) | |
| 16:16.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:12.50 | ``Erik | <@joosa> how do you say float in java? just 1.5f? |
| 17:12.50 | ``Erik | <@Gliptic> FloatFactoryFactory.getInstance(FloatFactoryFactory.defaultInstanceDescriptionString).getFactory(Locale.getLocale("en-US")).createBuilder().setString("1.5").getResult() |
| 17:32.01 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 17:36.00 | starseeker | heh |
| 19:01.09 | brlcad | nice |
| 19:24.57 | ``Erik | huh http://omnesviae.org/ |
| 19:47.19 | n_reed | Irssi 0.8.11 (20070425) - http://irssi.org/ end |
| 19:48.16 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 20:19.38 | CIA-133 | BRL-CAD: 03starseeker * r46720 10/brlcad/trunk/ (3 files in 2 dirs): back to configuring a message, but this time have it actually say something based on whether the tarballs are good or not. |
| 21:41.36 | CIA-133 | BRL-CAD: 03erikgreenwald * r46722 10/brlcad/trunk/src/libgcv/bottess.c: fix up nmgregion tree for return. Completely eliminate soup2bot. |
| 22:18.37 | CIA-133 | BRL-CAD: 03tbrowder2 * r46724 10/brlcad/trunk/doc/docbook/resources/fonts/truetype/gnu-freefonts/: removing fonts with incompatible license |
| 22:26.24 | CIA-133 | BRL-CAD: 03tbrowder2 * r46725 10/brlcad/trunk/doc/docbook/resources/fonts/truetype/stix-v1.0.0/ (6 files): adding STIX fonts with SIL Open Font License |
| 22:38.21 | CIA-133 | BRL-CAD: 03tbrowder2 * r46726 10/brlcad/trunk/doc/docbook/resources/fonts/truetype/stix-v1.0.0/ (4 files): pdf files showing all glyphs and unicode points for the four font faces |
| 23:01.25 | CIA-133 | BRL-CAD: 03tbrowder2 * r46727 10/brlcad/trunk/doc/docbook/fop.xconf.in: restoring base to '@srcdir@' for testing cmake and autotools |
| 00:02.17 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 01:41.26 | abhi2011 | starseeker: is the header simphysics.h not required to be mentioned in the CMakeLists.txt file for libged ? |
| 01:42.18 | abhi2011 | I am trying to add a new source and header in the simulate command, and I think only the cpp file needs to be included in the libged/CMakeLists.txt file |
| 01:42.23 | abhi2011 | at SET(ged_ignore_files simulate/simphysics.cpp simulate/simulate.c) |
| 01:43.50 | abhi2011 | so I ll change it to SET(ged_ignore_files simulate/simphysics.cpp simulate/simulate.c simulate/simcollisionalgo.cpp simulate/simcollisionalgo.h) |
| 03:14.02 | brlcad | abhi2011: how'd that new render animation turn out? |
| 03:14.26 | brlcad | was showing a bunch of folks your previous animation earlier this week, they love it! :) |
| 03:14.39 | abhi2011 | yes it turned out fine |
| 03:14.49 | abhi2011 | I ll make a movie over the night today :) |
| 03:15.42 | abhi2011 | pentium dual core :P |
| 03:25.14 | ``Erik | abhi: if you have something scriptable you can give us, we can throw a LOT of cpu into making you up a movie |
| 03:26.23 | ``Erik | like a stack of 16 core xeons :) |
| 03:54.14 | abhi2011 | oh wow! |
| 03:54.25 | abhi2011 | umm but u wud need bullet installed and working too |
| 03:54.50 | abhi2011 | which reminds me, does the simulate command work on any other system correctly |
| 03:55.21 | abhi2011 | also I have got a database and 2 tcl scripts |
| 03:55.45 | abhi2011 | so I ll put these in the samples and tclscripts folders if i want to share it ? |
| 03:59.43 | abhi2011 | well database not needed actually, since the script can be run from a new database and creates everything |
| 04:00.23 | abhi2011 | right, so i ll give clean up the script and pastebin it for now |
| 05:02.56 | CIA-133 | BRL-CAD: 03abhi2011 * r46728 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simcollisionalgo.h): Added 2 files for containing a RT based contact manifold generator |
| 05:26.35 | abhi2011 | ok here is the tcl script for generating the scene : http://bin.cakephp.org/view/350938158 |
| 05:35.14 | abhi2011 | := |
| 05:36.08 | abhi2011 | and here is the shell script |
| 05:40.17 | abhi2011 | http://bin.cakephp.org/view/572543350 |
| 06:07.42 | CIA-133 | BRL-CAD: 03abhi2011 * r46729 10/brlcad/trunk/src/libged/ (CMakeLists.txt simulate/simphysics.cpp simulate/simulate.c): Began rt integration into the bullet collision pipeline, added callback to show aabb overlaps and contact points |
| 06:27.02 | CIA-133 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3164 10/wiki/User:Abhijit: /* Log */ |
| 06:28.47 | CIA-133 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3165 10/wiki/User:Abhijit: /* Log */ |
| 06:38.56 | abhi2011 | the minute i submit the shell script the laptop fan ramps up a few notches |
| 06:38.58 | abhi2011 | :P |
| 12:47.28 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 13:04.43 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 13:23.00 | brlcad | senses a big remrt session in his near future |
| 13:45.43 | ``Erik | abhi: is it possible to run a bullet simulation and export a series of 'geometry at time X' definitions? so a single machine can generate the 2000 or so 'states' to be farmed out for raytracing? |
| 13:48.23 | brlcad | pretty impressive scripting |
| 13:49.16 | brlcad | ``Erik: he's not here right now, but it is possible -- his script could just call clone before running simulate |
| 13:50.35 | brlcad | then his rt script could be issued for all 2000 frames at once for remrt instead of one at a time (which will kick rt into multi-frame render mode to make sure there isn't temporal tearing across frames) |
| 13:57.41 | ``Erik | cool (didn't think he was here, but y'know, post and wait) |
| 14:21.00 | CIA-133 | BRL-CAD: 03d_rossberg * r46730 10/brlcad/trunk/CMakeLists.txt: |
| 14:21.00 | CIA-133 | BRL-CAD: a non visible function prototype yields a warning "warning C4013: 'hypot' undefined; assuming extern returning int" => turned the warnings into errors |
| 14:21.00 | CIA-133 | BRL-CAD: a possible consequence of missing prototypes is a floating point stack overflow (as it happened in this case) |
| 14:54.59 | brlcad | ouch |
| 15:17.24 | CIA-133 | BRL-CAD: 03tbrowder2 * r46731 10/brlcad/trunk/doc/docbook/presentations/en/intro-to-tcltk.xml: corrected image file references for cuurent file structure |
| 15:27.44 | *** join/#brlcad b0ef (~b0ef@166.195.251.212.customer.cdi.no) | |
| 15:29.20 | CIA-133 | BRL-CAD: 03Sean 07http://brlcad.org * r3166 10/wiki/ESA_Summer_of_Code_in_Space: update with post-selection details -- link to abhijit's log |
| 15:45.24 | brlcad | where's the b0ef! |
| 15:59.05 | CIA-133 | BRL-CAD: 03tbrowder2 * r46732 10/brlcad/trunk/doc/docbook/fop.xconf.in: get the base URL for fop back to its rightful place |
| 16:23.48 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 17:04.37 | CIA-133 | BRL-CAD: 03tbrowder2 * r46733 10/brlcad/trunk/README.cmake: some more details for newbies |
| 17:32.28 | brlcad | hm, not so fond of so much irrelevant info before getting to the heart of the readme .. |
| 17:35.19 | brlcad | jordisayol: thx for being patient :) |
| 17:35.25 | brlcad | he's learning |
| 17:35.40 | jordisayol | brlcad: I see |
| 17:35.44 | jordisayol | :-) |
| 18:22.22 | abhi2011 | any luck running those scripts on the server |
| 18:25.43 | CIA-133 | BRL-CAD: 03tbrowder2 * r46734 10/brlcad/trunk/doc/docbook/articles/en/pipes.xml: adding unicode point for two symbols |
| 18:26.46 | brlcad | abhi2011: was looking them over earlier today while you were out |
| 18:27.19 | *** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net) | |
| 18:27.24 | yukonbob | hello, #brlcad |
| 18:27.29 | brlcad | abhi2011: nice work, btw .. impressive scripting pulling things together exactly the way they're supposed to be |
| 18:27.34 | brlcad | howdy yukonbob |
| 18:27.58 | yukonbob | hey brlcad -- how're things? |
| 18:28.34 | brlcad | abhi2011: with only a few modifications, those two scripts will work pretty well for setting up a completely distributed rendering |
| 18:29.29 | brlcad | yukonbob: good as ever, lots of skewers in the fire |
| 18:29.40 | brlcad | what are you working on these days? |
| 18:30.13 | abhi2011 | brlcad: yep learning :) |
| 18:30.43 | yukonbob | head-down in Tcl/C whenever I can, and started w/ Apache working on Tcl bindings for search-engine-in-development |
| 18:30.55 | yukonbob | <-- bch@apache.org :) |
| 18:30.57 | abhi2011 | so what modifications would u do for distributed rendering ? |
| 18:31.03 | brlcad | abhi2011: for the distributed render, you'd want to clone each object before running simulate so that you keep all timestep revisions, then make the rt script one *mega* script that renders all frames in sequence with only one call to rt |
| 18:31.30 | yukonbob | poking at my local brlcad/tcl/nbsd integration when I get chances... |
| 18:31.56 | brlcad | that will kick rt into a video-rendering mode where it becomes frame-aware and can apply tricks to make the frame-by-frame output better |
| 18:32.23 | yukonbob | and actually stumbled on an omission on my part that should help push that ahead -- took a while to get a version a few months old up/running, and now need to do a smaller leap fwd and getting running w/ latest brlcad code again... |
| 18:32.52 | brlcad | then it's as simple as copying the db to your render clients, replacing 'rt' with 'rtsrv' and running remrt some place to collect all of the results |
| 18:33.00 | abhi2011 | oh ok, so as I understand you generate all the different position the objects are in by running simulate for 1 step, 2 steps , 3steps.....300 steps and record them in different dbs |
| 18:33.12 | abhi2011 | so 300 dbs |
| 18:33.14 | brlcad | they can be in the same db |
| 18:33.21 | abhi2011 | ah yes right |
| 18:33.25 | abhi2011 | but with different names |
| 18:33.26 | brlcad | scene.001 scene.002 .. whatever |
| 18:33.41 | abhi2011 | oh the db supports scenes too |
| 18:33.45 | abhi2011 | didnt know that |
| 18:33.56 | yukonbob | <PROTECTED> |
| 18:34.37 | brlcad | abhi2011: you'll notice in rt script that it has a bunch of lines starting with viewsize, then start 0; clean; |
| 18:34.51 | abhi2011 | yes right |
| 18:34.58 | brlcad | that actually is a command to start frame 0 .. |
| 18:35.15 | abhi2011 | ok |
| 18:35.17 | brlcad | so after clean, you can load the next object, start 1, etc |
| 18:35.27 | abhi2011 | ok |
| 18:35.55 | brlcad | pretty much exactly what you have, just pulling the rt command outside that for loop |
| 18:35.56 | abhi2011 | and by default..the way I have been working with mged so far, that just creates 1 scene : scene 0 and puts everyting there |
| 18:36.02 | brlcad | and building up the command inside the for loop |
| 18:36.38 | abhi2011 | ok |
| 18:37.05 | brlcad | abhi2011: another thing I noticed is the hard-coded hack you have in there for knowing what is what in the db :) |
| 18:37.25 | abhi2011 | in the c code ? |
| 18:37.33 | brlcad | for starters, you should pass the list of objects to be simulated as a parameter to the simulate command :) |
| 18:37.37 | brlcad | yeah |
| 18:37.41 | abhi2011 | ok |
| 18:37.52 | abhi2011 | ah yes right |
| 18:38.01 | brlcad | sim_gp.r :) |
| 18:38.19 | abhi2011 | yeah that needs more flexibility :P |
| 18:38.21 | brlcad | that way you know which object(s) to work on |
| 18:38.42 | abhi2011 | so all the objects to be simulated get passed as paramters |
| 18:39.03 | abhi2011 | but then i would need to know which one of the passed objects is the ground plane |
| 18:39.21 | brlcad | maybe Usage: simulate timestep(s) object0 [object1 ...] |
| 18:39.31 | brlcad | right |
| 18:39.37 | abhi2011 | ok |
| 18:39.39 | brlcad | that brings me to my next suggestion :) |
| 18:40.09 | brlcad | so there's two concepts that I think bullet represents, correct me if I'm wrong |
| 18:40.18 | brlcad | one is this concept of a ground plane |
| 18:40.29 | brlcad | which is defined by a plane equation vector |
| 18:40.47 | brlcad | then it's marked immutable (i.e., with 0 volume) |
| 18:41.39 | brlcad | that being the second concept |
| 18:41.43 | brlcad | yes? |
| 18:41.55 | abhi2011 | welll almost , actually its more general, there can be 2 types of objects in bullet : static objects (with mass 0) and dynamic objects (with non zero mass) |
| 18:41.58 | CIA-133 | BRL-CAD: 03tbrowder2 * r46735 10/brlcad/trunk/TODO: add tasks to be done to clean up DocBook source |
| 18:42.08 | brlcad | s/volume/mass/ .. that's what I meant ;) |
| 18:42.24 | abhi2011 | yes right |
| 18:42.31 | abhi2011 | so I can actually mark any object as static |
| 18:42.33 | brlcad | but a ground plane isn't just a mass 0 entity iirc, no? |
| 18:42.41 | abhi2011 | true |
| 18:42.41 | brlcad | you have to say "this is ground" too, no? |
| 18:42.51 | abhi2011 | no there is no need to say so |
| 18:42.55 | abhi2011 | i just have to make it static |
| 18:43.00 | abhi2011 | that is fixed in space |
| 18:43.07 | brlcad | otherwise if I put an immutable box above your boxes, they'd have gravity pulling them in two directions |
| 18:43.08 | abhi2011 | there is no separate concept of ground |
| 18:43.40 | abhi2011 | no becuase the gravity is specified independently for the entire world |
| 18:43.45 | abhi2011 | there is no concept of ground |
| 18:43.54 | abhi2011 | if i have a plane that is rigid |
| 18:43.55 | brlcad | so gravity is global |
| 18:44.00 | abhi2011 | then it appears as the ground |
| 18:44.11 | abhi2011 | but its not specfied as such |
| 18:44.21 | brlcad | mm, okay |
| 18:44.39 | brlcad | so then all you need is some means to designate or calculate an object's mass |
| 18:44.57 | abhi2011 | yes, right now i use the volume of the objects bb and density of 0 |
| 18:44.58 | brlcad | we have a tool that does that (gqa) calculating mass, but it's not yet an API function |
| 18:45.00 | abhi2011 | sorry 1 |
| 18:45.05 | brlcad | nods |
| 18:45.05 | abhi2011 | oh ok |
| 18:45.07 | abhi2011 | cool |
| 18:45.21 | brlcad | so how about this |
| 18:46.00 | brlcad | you assume all regions specified for simulation (via specifying a given scene/combination/group) have a mass of 1 |
| 18:46.10 | brlcad | unless a mass-value is set |
| 18:46.22 | abhi2011 | ok |
| 18:46.26 | abhi2011 | yes |
| 18:46.35 | brlcad | that way all you need is some means to set an object's mass |
| 18:46.46 | abhi2011 | however a larger object may appear to have the same mass as a smaller object |
| 18:46.54 | abhi2011 | yes , the mass can be set |
| 18:46.56 | abhi2011 | true |
| 18:47.04 | brlcad | which fortunately there is a system already in place for :D |
| 18:47.06 | abhi2011 | if the user want more realistic simulation |
| 18:47.12 | abhi2011 | yes :) |
| 18:47.46 | abhi2011 | so i guess i can call upon the code in the gqa thingie to get me the mass |
| 18:48.00 | brlcad | nah, that'd be hell |
| 18:48.12 | abhi2011 | ok :P |
| 18:48.27 | brlcad | it's not API yet and it'd take a week or more to make it proper API |
| 18:48.47 | brlcad | your time is better spent getting collisions working ;) |
| 18:48.51 | abhi2011 | right ok, so i ll make it trhe way we dicusssed then |
| 18:48.57 | abhi2011 | assume mass of 1 |
| 18:49.03 | abhi2011 | unoless specified |
| 18:49.12 | brlcad | right, but then you need a way to specify mass :) |
| 18:49.18 | abhi2011 | yes |
| 18:49.23 | abhi2011 | so a -m flag |
| 18:49.24 | brlcad | do you know how already? :) |
| 18:49.30 | brlcad | no no |
| 18:49.31 | abhi2011 | with the masses in order |
| 18:49.45 | brlcad | object-oriented, you want objects to specify themselves |
| 18:50.06 | abhi2011 | ok but the user is going to pass the mass right |
| 18:50.29 | brlcad | pass the mass .. hehe |
| 18:50.29 | brlcad | yes :) |
| 18:50.45 | abhi2011 | ok |
| 18:50.51 | brlcad | so the missing piece of this puzzle... |
| 18:50.55 | brlcad | perhaps a new brl-cad concept, we have an attribute system where you can store key=value on arbitrary db objects |
| 18:51.10 | abhi2011 | ok |
| 18:51.17 | brlcad | that will probably work perfect for this |
| 18:51.22 | abhi2011 | right |
| 18:51.26 | abhi2011 | like the avs thing |
| 18:51.35 | abhi2011 | for the attributes of an object |
| 18:51.38 | brlcad | what avs thing? |
| 18:51.47 | abhi2011 | there is this avs variable all over the c code |
| 18:51.52 | brlcad | ah, yes |
| 18:51.53 | brlcad | that's this |
| 18:51.59 | abhi2011 | its used to access the attributes |
| 18:52.00 | brlcad | avs == attribute value system |
| 18:52.04 | abhi2011 | yes |
| 18:52.06 | abhi2011 | :) |
| 18:52.10 | abhi2011 | so not so new after all |
| 18:52.12 | abhi2011 | :P |
| 18:52.26 | abhi2011 | well yeah but i understand what you are saying |
| 18:52.28 | brlcad | yeah, so just need to use it for your own settings :) |
| 18:52.28 | abhi2011 | :) |
| 18:52.57 | abhi2011 | ok |
| 18:53.06 | abhi2011 | now about passing the mass while invoking the command |
| 18:53.06 | brlcad | attr set ground.r simulate:mass=0 |
| 18:53.17 | abhi2011 | oh ok |
| 18:53.19 | abhi2011 | ah now i get it |
| 18:53.19 | brlcad | then in the code, just look up the "simulate:mass" attribute and use the value |
| 18:53.26 | abhi2011 | right |
| 18:53.28 | abhi2011 | cool |
| 18:53.40 | brlcad | can use that for a whole slew of things then :) |
| 18:53.45 | abhi2011 | so its like any other attribute of the object, like radius etc |
| 18:53.47 | abhi2011 | yes |
| 18:53.51 | abhi2011 | we can specfiy friction |
| 18:53.54 | abhi2011 | for custom materials |
| 18:53.58 | abhi2011 | or density |
| 18:54.13 | brlcad | just prefix your variables so they can be conceptually grouped together |
| 18:54.19 | abhi2011 | ok |
| 18:54.40 | brlcad | but you should always have a "default" too .. so if nothing is set, it'll do something sane |
| 18:54.49 | abhi2011 | ok |
| 18:54.55 | abhi2011 | now about the ground plane thing |
| 18:55.19 | abhi2011 | see the user will invoke the command like : simulate a.r b.r |
| 18:55.22 | brlcad | like maybe if there is no immutable mass=0 objects being simulated, it defaults to making the biggest one be mass=0 |
| 18:55.33 | abhi2011 | ok |
| 18:55.42 | brlcad | simulate 10 scene |
| 18:55.54 | brlcad | or simulate 10 grp1 grp2 grp3 ... |
| 18:56.10 | brlcad | not necessarily just the region objects |
| 18:56.13 | abhi2011 | ok |
| 18:56.19 | abhi2011 | 1 more question |
| 18:56.21 | brlcad | trivial to walk the object(s) specified, get a list of all regions |
| 18:56.30 | abhi2011 | right |
| 18:56.37 | abhi2011 | i guess a scene's objects can be accessed |
| 18:56.44 | abhi2011 | not yet worked with scenes |
| 18:56.45 | brlcad | if there are no regions, maybe treat the object specified as a region or error out if you have to have a region |
| 18:56.59 | brlcad | db_walk_tree() is your friend |
| 18:57.02 | abhi2011 | cool |
| 18:57.52 | abhi2011 | umm so about scenes, if i want to create a new scene |
| 18:57.58 | abhi2011 | there is an mged comand for it ? |
| 18:58.01 | brlcad | that way your code doesn't even need to know the name(s) of anything |
| 18:58.14 | brlcad | 'g' ? |
| 18:58.25 | brlcad | scenes are just logical groupings of objects |
| 18:58.41 | abhi2011 | oh ok |
| 18:58.46 | brlcad | you can group a bunch of regions and groups together with the 'g' command |
| 18:59.00 | abhi2011 | yes of course :) |
| 18:59.08 | abhi2011 | thought they were a new kinda thing |
| 18:59.16 | abhi2011 | :P |
| 18:59.17 | brlcad | they're implicit |
| 18:59.20 | abhi2011 | ok |
| 18:59.44 | abhi2011 | ok there is 1 other thing |
| 18:59.53 | abhi2011 | about custom forces |
| 19:00.07 | abhi2011 | so suppose i want some impulse applied on a specfic object |
| 19:00.08 | brlcad | objects above the region level are groups, groups are "assemblies" in CAD terminology -- a scene is just another assembly |
| 19:00.16 | abhi2011 | can be used to shoot a sphere at a cube stack for example |
| 19:01.52 | abhi2011 | ok about the assemblies, so about the custom forces should I consider at this stage , something liek this : simulate 10 -f{obj, 10,0,0} grp1 grp2 .... |
| 19:02.33 | abhi2011 | so that would apply a force of 10 newtons on the region/group named as 'obj' only |
| 19:02.43 | abhi2011 | the remainign objects stay the same |
| 19:02.52 | CIA-133 | BRL-CAD: 03tbrowder2 * r46736 10/brlcad/trunk/doc/docbook/articles/en/mgedrc.xml: adding unicode point for two symbols; lifting XInclude namespace to root element |
| 19:02.59 | abhi2011 | obj should appear somewhere in grp1, grp2 etc |
| 19:03.03 | brlcad | abhi2011: I'd probably still use the attributes for that |
| 19:03.11 | abhi2011 | ah yes of course |
| 19:03.13 | brlcad | because you need to persist the force across frames |
| 19:03.31 | abhi2011 | yes true, that would be much easier then parsing comples flags |
| 19:03.43 | abhi2011 | yes |
| 19:04.06 | abhi2011 | interesting and very useful this attributes thing :) |
| 19:04.13 | brlcad | granted, that means you'll have to read all objects to see if any have forces applied, run the simulation step, then write out any remaining/residual forces (for the next timestep) |
| 19:04.29 | CIA-133 | BRL-CAD: 03tbrowder2 * r46737 10/brlcad/trunk/TODO: add another task to be done to clean up DocBook source |
| 19:04.43 | brlcad | becomes a persistent database for any values you need during the sim |
| 19:04.52 | abhi2011 | yes |
| 19:04.53 | CIA-133 | BRL-CAD: 03starseeker * r46738 10/brlcad/trunk/README.cmake: Toplevel readme probably isn't the place for these details. Also, if the environment variables may cause a problem, the thing to do is to have CMake check them as part of the configure process and warn about them. |
| 19:06.15 | abhi2011 | yes, that is another thing which was bothering me actually, see there are 2 options, to run all the simulation timesteps without any thing else happening. or run 1 timestep, do overlp checks then run the next steps |
| 19:06.26 | brlcad | starseeker: if CMake is a faithful conversion of configure, there should already be a big honking warning about BRLCAD_ROOT being set ;) |
| 19:06.44 | abhi2011 | but if there is break between the steps and i have to recreate the entire scene again , then all the dynamic foce and acceleration info would need to be persisted |
| 19:06.53 | abhi2011 | can use the attributes for that |
| 19:06.58 | brlcad | sure |
| 19:07.28 | abhi2011 | right so a whole slew of new attributes to be added |
| 19:07.39 | abhi2011 | for all objects in brl-cad |
| 19:07.54 | abhi2011 | force , mass, |
| 19:07.56 | brlcad | all regions objects |
| 19:08.02 | abhi2011 | yes ok |
| 19:08.15 | abhi2011 | yes true |
| 19:08.17 | abhi2011 | only regions |
| 19:08.40 | brlcad | pretty limited subset, and only after simulate has run once (and there are forces remaining) or as part of scene setup to override defaults |
| 19:09.21 | brlcad | e.g., you wouldn't want to write out simulate:force=0.0 .. you'd delete the attribute |
| 19:09.31 | abhi2011 | yes |
| 19:09.41 | brlcad | (assumes default force==0.0 of course) |
| 19:09.57 | abhi2011 | yes, so all these attributes are listed in a header, and i just go add to them |
| 19:10.29 | CIA-133 | BRL-CAD: 03tbrowder2 * r46739 10/brlcad/trunk/doc/docbook/articles/en/projection_shader.xml: adding unicode point for two symbols; lifting XInclude namespace to root element |
| 19:10.53 | abhi2011 | and maybe increase a counter which currently tracks the number of attributes that can exist for a region |
| 19:10.53 | starseeker | brlcad: yeah, yeah... :-P |
| 19:11.08 | starseeker | is catching up on backlog... |
| 19:18.08 | CIA-133 | BRL-CAD: 03tbrowder2 * r46740 10/brlcad/trunk/doc/docbook/articles/en/build_region.xml: lifting XInclude namespace to root element |
| 19:22.16 | abhi2011 | on thinking more about it, the velocity of the objects, both rotational and translational needs to be persisted for the next frame, and if any custom force should still to be applied in the next frame(since there is no concept of a residual force as such like 10 newtons force is applied and 5 newtons is left for next frame, that would result in wrong physics ) |
| 19:25.01 | abhi2011 | ok so I ll proceed with adding the new attributes : translational velocities in x y, z directions and rotational velocities for the 3 axes , and see if I can store then after 1 frame and reload them at the beginning of the next frame and see if physics continues properly |
| 19:26.08 | abhi2011 | this can then be extended to calling rt at the end of a frame to create the contact manifolds , which can then be inserted into the collision pipeline befpre starting the next frame, so collision proceeds according to rt output |
| 19:26.41 | CIA-133 | BRL-CAD: 03tbrowder2 * r46741 10/brlcad/trunk/doc/docbook/articles/en/build_pattern.xml: adding unicode point for one symbols; lifting XInclude namespace to root element |
| 19:31.56 | CIA-133 | BRL-CAD: 03tbrowder2 * r46742 10/brlcad/trunk/doc/docbook/lessons/en/mged01_creating_primitive_shapes.xml: lifting XInclude namespace to root element |
| 19:56.17 | brlcad | starseeker: if you knew the support hell that was when BRLCAD_ROOT was the norm, it probably would have been one of the first things you added |
| 19:57.30 | brlcad | how many times I'd spend half a day debugging some really bizzare bug or crash only to discover they were running a 7.4 binary but using 7.0 libraries |
| 19:58.50 | CIA-133 | BRL-CAD: 03starseeker * r46743 10/brlcad/trunk/CMakeLists.txt: Get a version of the warnings about BRLCAD_ROOT into CMake, as well as (reluctantly) using the environment variable if it's defined. |
| 20:00.56 | brlcad | abhi2011: couldn't you have a situation like where you'd have an electromagnetic field applying some force but then the force on the next frame would be different because of the different position in the field? |
| 20:01.23 | brlcad | the idea being that you'd have some sort of force emitter objects, of course, with some sort of parametric force being applied |
| 20:01.30 | brlcad | not just impulse or load |
| 20:02.27 | brlcad | abhi2011: I'd suggest combining the xyz velocities into one attribute (one for linear, one for rotational) |
| 20:02.49 | brlcad | should limit the number of writes if values naturally group together |
| 20:04.17 | CIA-133 | BRL-CAD: 03starseeker * r46744 10/brlcad/trunk/CMakeLists.txt: /usr is bad whether or not it came from BRLCAD_ROOT, adjust warning. |
| 20:06.11 | brlcad | starseeker: you missed the warning part |
| 20:06.46 | brlcad | "if test ! "x$BRLCAD_ROOT" = "x" ; then" ... |
| 20:07.11 | brlcad | that's the important part |
| 20:07.15 | starseeker | that's IF(BRLCAD_ROOT) |
| 20:07.47 | starseeker | SET(BRLCAD_ROOT "$ENV{BRLCAD_ROOT}") get's it from the environment variable - if that variable is empty, the if test fails. otherwise, the warning proceeds |
| 20:08.15 | brlcad | not following |
| 20:08.33 | starseeker | we're warning if BRLCAD_ROOT is set, correct? |
| 20:08.39 | brlcad | correct |
| 20:08.44 | starseeker | this will do that |
| 20:09.03 | abhi2011 | brlcad : about the electro magnetic fields, yes true |
| 20:09.41 | brlcad | ah, I see it.. the logic is further down .. I was expecting statement parity, or close to it |
| 20:10.00 | brlcad | a quiet little "BRLCAD_ROOT is not necessary and may cause unexpected behavior" is not parity at all... |
| 20:10.00 | CIA-133 | BRL-CAD: 03starseeker * r46745 10/brlcad/trunk/CMakeLists.txt: comment first, then code |
| 20:10.37 | starseeker | has tested it - seems to do the trick |
| 20:11.20 | brlcad | that's probably the distinction |
| 20:11.30 | brlcad | there's no indication on the severity of the messages being printed |
| 20:11.40 | CIA-133 | BRL-CAD: 03tbrowder2 * r46746 10/brlcad/trunk/HACKING: add reference to more DocBook details |
| 20:12.31 | brlcad | configure had something like four output levels, regular print message, warning, severe warning, and error (halting) |
| 20:12.48 | starseeker | yeah, I don't think cmake has warning vs. severe warning |
| 20:12.53 | brlcad | otherwise the messages will just get lost in the noise |
| 20:13.31 | brlcad | the }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} markers screamed out "this is really bad" .. and it worked |
| 20:13.33 | starseeker | heh - I'm calling sleep on the first one, and flat out exiting with failure on /usr (with a message that tells them how to get it to go forward if they're really that stubborn) |
| 20:13.40 | starseeker | ah, k |
| 20:13.51 | CIA-133 | BRL-CAD: 03tbrowder2 * r46747 10/brlcad/trunk/doc/docbook/README: add more details on DB character code requirements |
| 20:15.15 | brlcad | the only half-severe }}} message I think we ever reported was about the IEEE encoding, which I'm just not sure what it means in terms of valid calculations |
| 20:15.28 | CIA-133 | BRL-CAD: 03tbrowder2 * r46748 10/brlcad/trunk/doc/docbook/README: correct typo |
| 20:22.40 | CIA-133 | BRL-CAD: 03starseeker * r46749 10/brlcad/trunk/CMakeLists.txt: Make warnings noiser, also complain about BRLCAD_DATA |
| 20:23.45 | brlcad | starseeker: er, BRLCAD_ROOT doesn't set prefix in configure ... |
| 20:24.35 | starseeker | ah, my mistake |
| 20:24.39 | starseeker | wasn't parsing the m4 logic right |
| 20:25.25 | brlcad | it pulls the value from prefix (setting BRLCAD_ROOT) .. but that's os we set BRLCAD_ROOT as a define in the config header (so things like bu_brlcad_root() work correctly) |
| 20:25.33 | brlcad | s/os/so/ |
| 20:26.19 | starseeker | nods - I never use BRLCAD_ROOT as a variable at all in CMake - it gets set to CMAKE_INSTALL_PREFIX in the config header |
| 20:27.00 | brlcad | "it" being BRLCAD_ROOT? |
| 20:27.06 | starseeker | yes |
| 20:27.40 | brlcad | yeah, I wouldn't have expected you to use it as a var |
| 20:29.44 | CIA-133 | BRL-CAD: 03starseeker * r46750 10/brlcad/trunk/CMakeLists.txt: My mistake, we're not setting CMAKE_INSTALL_PREFIX to BRLCAD_ROOT. Tweak the logic and warnings accordingly |
| 20:31.19 | brlcad | it was needed for the m4 logic because BRLCAD_ROOT exists as a shell variable, an m4 variable, a make variable, and a #define -- cmake effectively eliminates the m4+make cases (unless you allow the same make-time override) |
| 20:31.21 | CIA-133 | BRL-CAD: 03starseeker * r46751 10/brlcad/trunk/CMakeLists.txt: match closing tag |
| 20:31.29 | brlcad | does miss the various make-time overrides |
| 20:34.05 | brlcad | e.g., make TCLDIR= TKDIR= (skip rebuilding tcl/tk even if dependency tracking wants to rebuild them) |
| 20:34.34 | starseeker | winces - not sure how I'd make that work |
| 20:34.40 | brlcad | make CPPFLAGS=-w (skip strict for this pass) |
| 20:34.56 | brlcad | no worries, not a major feature |
| 20:35.08 | brlcad | just one of those things :) |
| 20:35.53 | brlcad | overriding the dependency tracking system wasn't something universal, there had to be a make variable defined for the directory |
| 20:36.01 | brlcad | getting that in cmake terms would probably suck |
| 20:36.39 | brlcad | because it'd probably take some round-about checking mechanism instead of just letting make do what it does |
| 20:37.02 | CIA-133 | BRL-CAD: 03starseeker * r46752 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: That's actually CXXFLAGS, not CXX_FLAGS... |
| 20:37.18 | brlcad | one of the merits of automake+make .. but not one that trumps the windows portability aspect of cmake |
| 20:37.22 | starseeker | probably mattered more when build times were slower |
| 20:37.41 | brlcad | nah, still matters .. I used it just last week :) |
| 20:38.13 | starseeker | shakes his head - I think my developer skills are going to forever remain at the "midrange" level |
| 20:38.40 | starseeker | can get there eventually, usually... |
| 20:39.00 | brlcad | think if you're working on building a proc-db or something simple, find out you need to add a libbu function that begs for a new configure/cmake header test, .. it's going to rightly want to rebuild everything |
| 20:39.47 | starseeker | make -j9 procdb_target would build only what that proc-db needs, I'd probably call that close enough... |
| 20:40.07 | brlcad | you don't care about rebuilding everything in that moment, whether it's 2min or 10min .. your procdb builds and links in 2 milliseconds and that's what you're focusing on :) |
| 20:40.31 | starseeker | make procdb_target/FAST I think might do what you want there |
| 20:40.43 | brlcad | maybe |
| 20:40.51 | brlcad | but I *did* need libbu rebuilt :) |
| 20:41.12 | brlcad | just not every f'n thing that uses libbu, and certainly not all of src/other :) |
| 20:41.40 | starseeker | nods |
| 20:41.51 | brlcad | like I said, not a huge deal .. just something different |
| 20:41.57 | starseeker | maybe if you describe the scenario to the CMake devs they could come up with something... |
| 20:42.10 | brlcad | not even that important |
| 20:42.49 | brlcad | might even be something similar in cmake terms that will work "good enough", like make libbu/FAST && make my_proc/FAST |
| 20:43.20 | starseeker | thought about suggesting that, but assumed it would be rejected for "too much typing" reasons :-P |
| 20:44.17 | brlcad | it's better than waiting 2-10min :) |
| 21:30.59 | starseeker | tcl/tk 2011 schedule is up: http://www.tcl.tk/community/tcl2011/schedule.html |
| 22:02.19 | brlcad | looks like Cliff F. is all over the place in the schedule this year |
| 22:02.32 | brlcad | quirky funny guy :) |
| 22:03.33 | brlcad | at least in a geek humor kind of way :) |
| 22:03.38 | brlcad | bets $20 that he says "Any questions? Any answers?" at least a few times during the week |
| 22:57.25 | brlcad | oh snap! |
| 22:57.33 | brlcad | thank you tom browder! |
| 22:58.01 | brlcad | looks like sourceforge folks made ideatorret an option, that's outstanding! |
| 00:31.48 | louipc | what's ideatorrent all about? |
| 01:02.59 | starseeker | was wondering that too... |
| 01:55.35 | *** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ) | |
| 02:00.13 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 04:38.46 | brlcad | ideatorrent is a community-driven feature request ranking system |
| 04:39.37 | brlcad | sort of a cross between digg and stackoverflow, it lets users post a feature request that others are then able to rank up, rank down, comment on, etc |
| 04:40.37 | brlcad | ubuntu brainstorm ( http://brainstorm.ubuntu.com/ ) came up with the idea and was a pretty big success -- that got forked off as it's own project called IdeaTorrent |
| 04:42.05 | brlcad | here's ours set up: https://sourceforge.net/apps/ideatorrent/brlcad/ |
| 04:42.18 | brlcad | I added three initial ideas to the sandbox to get things going |
| 04:44.26 | brlcad | so there's two parts to it too |
| 04:45.41 | brlcad | you propose a problem or lacking feature area (rt has too many command line options making it hard to use) as well as a solution (introduce long options and remove the following short options:...) |
| 04:45.58 | brlcad | others can propose alternate solutions (and other feature areas) |
| 04:46.08 | brlcad | and everyone can vote on the problems and proposed solutions |
| 10:54.02 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 11:19.50 | CIA-133 | BRL-CAD: 03tbrowder2 * r46753 10/brlcad/trunk/doc/docbook/articles/en/pipes.xml: added missing 'x' for hex unicode points |
| 12:55.24 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-186-249.wlan.tudelft.nl) | |
| 13:22.06 | CIA-133 | BRL-CAD: 03Sean 07http://brlcad.org * r3167 10/wiki/BOT: Redirecting to [[BoT]] |
| 13:41.52 | ``Erik | wee, I submitted one to ideatorrent O.o (interface seems a bit of a pita) |
| 16:24.05 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 18:22.52 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 20:19.37 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 20:31.56 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 00:14.08 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 08:16.45 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) | |
| 09:21.47 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 11:04.43 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 11:18.29 | CIA-133 | BRL-CAD: 03tbrowder2 * r46754 10/brlcad/trunk/HACKING: add discussion of floating point comparisons |
| 13:51.36 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 16:52.15 | *** join/#brlcad Elrohir (~kvirc@p5B14B167.dip.t-dialin.net) | |
| 19:29.11 | CIA-133 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3168 10/wiki/Animation: /* With ffmpeg */ |
| 19:30.53 | CIA-133 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3169 10/wiki/Animation: /* With ffmpeg */ |
| 19:55.57 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 20:19.09 | abhi2011 | about the ideas for improvement, I really think it would be great to have all the tools accessible from the single point archer gui |
| 20:19.26 | abhi2011 | like 3ds max or maya does |
| 20:21.06 | abhi2011 | I think most new users would expect to start with a gui and then move on to scripting and command line tools later |
| 21:30.54 | abhi2011 | is it possible to draw simply arrows and labels in the mged window |
| 21:31.23 | abhi2011 | i want to show the direction of velocity and the value |
| 21:31.30 | abhi2011 | maybe sketches can help |
| 00:58.48 | CIA-133 | BRL-CAD: 03abhi2011 * r46755 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c simulate.h): started adding sim attributes |
| 01:38.56 | CIA-133 | BRL-CAD: 03tbrowder2 * r46756 10/brlcad/trunk/doc/docbook/presentations/en/intro-to-tcltk.xml: prettying |
| 01:44.25 | CIA-133 | BRL-CAD: 03tbrowder2 * r46757 10/brlcad/trunk/doc/docbook/resources/fonts/truetype/dejavu-lgc-fonts-ttf-2.33/ (23 files in 2 dirs): adding another free font |
| 01:45.01 | CIA-133 | BRL-CAD: 03tbrowder2 * r46758 10/brlcad/trunk/doc/docbook/fop.xconf.in: update with currently used fonts |
| 01:47.43 | CIA-133 | BRL-CAD: 03tbrowder2 * r46759 10/brlcad/trunk/doc/docbook/system/man1/en/obj-g.xml: correct typos; correct terminology |
| 01:48.54 | CIA-133 | BRL-CAD: 03tbrowder2 * r46760 10/brlcad/trunk/doc/docbook/lessons/es/mged01_crear_figuras_primitivas.xml: lift xinclude namespace to root element |
| 01:49.54 | CIA-133 | BRL-CAD: 03tbrowder2 * r46761 10/brlcad/trunk/doc/docbook/lessons/es/mged03_utilizar_comando_in.xml: lift xinclude namespace to root element |
| 01:50.34 | CIA-133 | BRL-CAD: 03tbrowder2 * r46762 10/brlcad/trunk/doc/docbook/lessons/es/mged02_opciones_vistas.xml: lift xinclude namespace to root element |
| 01:51.27 | CIA-133 | BRL-CAD: 03tbrowder2 * r46763 10/brlcad/trunk/doc/docbook/books/en/tutorial_series_authors.xml: added xml header |
| 01:56.37 | brlcad | abhi2011: bu_argv_from_vls() + strtol() would probably be a "better way" |
| 01:56.47 | brlcad | (in regards to your TODO) |
| 02:43.36 | CIA-133 | BRL-CAD: 03tbrowder2 * r46764 10/brlcad/trunk/doc/docbook/presentations/en/intro-to-tcltk.xml: correct well-formedness error |
| 02:45.47 | CIA-133 | BRL-CAD: 03tbrowder2 * r46765 10/brlcad/trunk/doc/docbook/system/man1/en/obj-g.xml: remove extraneous char |
| 02:50.24 | CIA-133 | BRL-CAD: 03tbrowder2 * r46766 10/brlcad/trunk/doc/docbook/system/man1/en/obj-g.xml: remove extraneous char |
| 08:14.47 | abhi2011 | brlcad: thanks! |
| 08:22.20 | abhi2011 | hmmm just realized that I cannot simply assume integers as the components of the vector |
| 08:22.54 | abhi2011 | so need to split the string based on whitespaces and convert each part into a floating point number |
| 08:58.23 | abhi2011 | so something like sscanf(str, "%f %f %f", &vec[0], &vec[1], &vec[2]) |
| 11:34.40 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:44.25 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:55.07 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 14:24.52 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 14:28.09 | brlcad | abhi2011: bu_argv_from_vls()+strtod() |
| 14:28.28 | brlcad | sscanf could work, but it's not nearly as robust as strtod |
| 14:28.39 | abhi2011 | oh ok |
| 14:28.59 | brlcad | and the whitespace parsing you'll get from bu_argv_from_vls() provides a little more flexibility |
| 14:29.13 | abhi2011 | ok |
| 14:31.45 | brlcad | also meant to say about your other comments -- completely agree that it should all be accessible within archer/mged ... |
| 14:32.11 | brlcad | just think it's a bit much to tackel before it's working |
| 14:32.31 | brlcad | that said, drawing arrows and labels is something you could add before then |
| 14:33.17 | brlcad | the nirt command does that along with a few other commands (it's very low-level) |
| 17:30.56 | *** join/#brlcad dli (~dli@67.55.34.89) | |
| 19:43.14 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 19:43.14 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 20:13.25 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 20:13.25 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 20:49.52 | brlcad | happens |
| 20:49.55 | brlcad | (a lot) :) |
| 21:03.44 | CIA-133 | BRL-CAD: 03tbrowder2 * r46767 10/brlcad/trunk/TODO: add check for properly embedded fonts in pdf docs |
| 21:06.54 | CIA-133 | BRL-CAD: 03tbrowder2 * r46768 10/brlcad/trunk/TODO: correct typo: 'et al.' is short for 'et alii' which is Latin for 'and others' |
| 21:08.39 | CIA-133 | BRL-CAD: 03tbrowder2 * r46769 10/brlcad/trunk/doc/docbook/Makefile.am: remove all DB xml validation references |
| 22:43.25 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 23:57.30 | CIA-133 | BRL-CAD: 03tbrowder2 * r46770 10/brlcad/trunk/doc/docbook/system/mann/mged_cmd_template.xml: moving template to normal location |
| 23:59.25 | CIA-133 | BRL-CAD: 03tbrowder2 * r46771 10/brlcad/trunk/doc/docbook/system/mann/mged_cmd_template.xml: moving template back to original location--easier to find here |
| 00:15.07 | brlcad | ``Erik: crit now points to new machine again, just sync'd pw/group db's again, and more to come... |
| 01:23.42 | CIA-133 | BRL-CAD: 03tbrowder2 * r46772 10/brlcad/trunk/doc/docbook/resources/fonts/truetype/dejavu-lgc-fonts-ttf-2.33/ (AUTHORS BUGS LICENSE NEWS README): more docs for dejavu fonts |
| 01:24.45 | CIA-133 | BRL-CAD: 03tbrowder2 * r46773 10/brlcad/trunk/doc/docbook/books/en/ (2 files): lifting xinclude namespace to root element |
| 01:25.37 | CIA-133 | BRL-CAD: 03tbrowder2 * r46774 10/brlcad/trunk/doc/docbook/specifications/en/BRL_CAD_g_format_V5.xml: eliminating unneeded info elements |
| 01:32.20 | CIA-133 | BRL-CAD: 03tbrowder2 * r46775 10/brlcad/trunk/doc/docbook/README: add info on DB processing and validation tools |
| 01:33.21 | CIA-133 | BRL-CAD: 03tbrowder2 * r46776 10/brlcad/trunk/doc/docbook/ (BRLCAD_DB_VALIDATION.pm find-db-files.pl validate.pl): add DB validation tools |
| 01:35.09 | CIA-133 | BRL-CAD: 03tbrowder2 * r46777 10/brlcad/trunk/doc/docbook/books/ (it/ ru/): add Italian and Russian lang subdirs for BRL-CAD Overview |
| 03:59.23 | ``Erik | awesomesauce |
| 04:01.40 | ``Erik | there's been some shuffle in system accounts and groups, need to be a bit careful about that for the real transition |
| 05:10.02 | brlcad | I did diffs, seemed fine |
| 05:10.50 | brlcad | won't bother syncing passwords until it's time to turn off the lights |
| 06:16.11 | brlcad | finishes scanning /etc |
| 11:19.54 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 11:57.32 | CIA-133 | BRL-CAD: 03tbrowder2 * r46778 10/brlcad/trunk/TODO: add more DB tasks |
| 12:07.49 | CIA-133 | BRL-CAD: 03tbrowder2 * r46779 10/brlcad/trunk/doc/docbook/resources/brlcad/ (. xsl/): add new dir for BRL-CAD DB xsl customizations |
| 12:42.17 | CIA-133 | BRL-CAD: 03tbrowder2 * r46780 10/brlcad/trunk/doc/docbook/resources/brlcad/xsl/ (6 files): add intial xsl customizations |
| 12:43.06 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 12:50.25 | CIA-133 | BRL-CAD: 03tbrowder2 * r46781 10/brlcad/trunk/doc/docbook/resources/brlcad/xsl/brlcad-xhtml-header-navigation.xsl: remove offending xml comment |
| 12:59.15 | CIA-133 | BRL-CAD: 03tbrowder2 * r46782 10/brlcad/trunk/doc/docbook/resources/brlcad/ (12 files in 2 dirs): eliminating unnecessary dir |
| 14:30.08 | *** join/#brlcad n_reed (~nicholas@c-68-55-142-136.hsd1.md.comcast.net) | |
| 15:24.40 | CIA-133 | BRL-CAD: 03tbrowder2 * r46783 10/brlcad/trunk/AUTHORS: correct name and company |
| 15:27.11 | CIA-133 | BRL-CAD: 03tbrowder2 * r46784 10/brlcad/trunk/configure.ac: need an absolute build path for DocBook xml catalogs |
| 15:29.01 | CIA-133 | BRL-CAD: 03tbrowder2 * r46785 10/brlcad/trunk/doc/docbook/DBPATH.pm.in: add config file for a Perl module for DocBook home path |
| 15:30.22 | CIA-133 | BRL-CAD: 03tbrowder2 * r46786 10/brlcad/trunk/doc/docbook/ (BRLCAD_DOC.pm create-xml-catalogs.pl): adding DB tools for xsl customization and configuration |
| 15:33.20 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-186-181.wlan.tudelft.nl) | |
| 15:50.54 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 16:00.23 | *** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net) | |
| 16:10.08 | CIA-133 | BRL-CAD: 03n_reed * r46787 10/brlcad/trunk/src/libgcv/wfobj/ (tri_face.c tri_face.h): added make_faceuse_from_face func; usefull elsewhere |
| 16:11.35 | CIA-133 | BRL-CAD: 03n_reed * r46788 10/brlcad/trunk/src/conv/obj-g_new.c: using nmg triangulation for concave faces when making bots |
| 16:16.34 | CIA-133 | BRL-CAD: 03n_reed * r46789 10/brlcad/trunk/src/conv/obj-g_new.c: making native bot the default conversion mode |
| 16:36.03 | CIA-133 | BRL-CAD: 03tbrowder2 * r46790 10/brlcad/trunk/doc/docbook/resources/standard/svg/: adding W3C resource files for svg |
| 16:42.55 | CIA-133 | BRL-CAD: 03tbrowder2 * r46791 10/brlcad/trunk/doc/docbook/resources/standard/svg/ (58 files): adding W3C resource files for svg |
| 16:55.59 | CIA-133 | BRL-CAD: 03tbrowder2 * r46792 10/brlcad/trunk/doc/docbook/resources/brlcad/xsl/: removing unneeded dir |
| 16:58.49 | CIA-133 | BRL-CAD: 03tbrowder2 * r46793 10/brlcad/trunk/doc/docbook/resources/brlcad/: ignore auto-generated files |
| 17:29.44 | *** part/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 17:30.14 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 17:55.11 | CIA-133 | BRL-CAD: 03erikgreenwald * r46794 10/brlcad/trunk/src/libgcv/bottess.c: add support for the writer callback |
| 18:20.39 | CIA-133 | BRL-CAD: 03tbrowder2 * r46795 10/brlcad/trunk/doc/docbook/resources/brlcad/center-table-print.xsl: new specialized stylesheet |
| 20:22.09 | *** join/#brlcad b0ef (~b0ef@78.58.34.95.customer.cdi.no) | |
| 20:48.46 | CIA-133 | BRL-CAD: 03brlcad * r46796 10/brlcad/trunk/src/proc-db/: ignore menger binary |
| 20:50.15 | CIA-133 | BRL-CAD: 03brlcad * r46797 10/brlcad/trunk/src/libbu/: ignore new tester binaries |
| 20:51.21 | CIA-133 | BRL-CAD: 03brlcad * r46798 10/brlcad/trunk/src/libbu/: ignore test_htond too |
| 20:57.15 | CIA-133 | BRL-CAD: 03brlcad * r46799 10/brlcad/trunk/src/libged/ged_private.h: rename pipe to pipe_internal to avoid shadowing the system function |
| 21:53.39 | *** part/#brlcad n_reed (~nicholas@c-68-55-142-136.hsd1.md.comcast.net) | |
| 21:58.23 | CIA-133 | BRL-CAD: 03tbrowder2 * r46800 10/brlcad/trunk/doc/docbook/create-xml-catalogs.pl: get uri mapping right for xml catalog |
| 22:00.39 | CIA-133 | BRL-CAD: 03tbrowder2 * r46801 10/brlcad/trunk/doc/docbook/resources/fonts/: ignore STIX src dir |
| 22:02.06 | CIA-133 | BRL-CAD: 03tbrowder2 * r46802 10/brlcad/trunk/doc/docbook/resources/fonts/truetype/dejavu-lgc-fonts-ttf-2.33/: ignore a dejavu font dir |
| 22:20.32 | CIA-133 | BRL-CAD: 03brlcad * r46803 10/brlcad/trunk/src/libbu/temp.c: it's not a warning, it's an outright unexpected error but do what the caller asked for anyways, truncating the result. |
| 23:01.37 | *** join/#brlcad CIA-63 (~CIA@cia.atheme.org) | |
| 23:02.20 | *** join/#brlcad kanzure_ (~kanzure@131.252.130.248) | |
| 23:02.32 | *** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 23:03.14 | CIA-63 | BRL-CAD: 03tbrowder2 * r46805 10/brlcad/trunk/doc/docbook/BRLCAD_DB_VALIDATION.pm: added path for oNVDL validation method |
| 23:04.13 | CIA-63 | BRL-CAD: 03tbrowder2 * r46806 10/brlcad/trunk/doc/docbook/README: added info on oNVDL validation method |
| 23:05.07 | CIA-63 | BRL-CAD: 03tbrowder2 * r46807 10/brlcad/trunk/doc/docbook/validate.pl: added oNVDL validation method |
| 23:10.04 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 00:29.28 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 00:33.20 | starseeker | ah, nuts - that's why the tcl/tk cmake was faster, left out an optimization flag TEA was adding |
| 00:36.54 | CIA-63 | BRL-CAD: 03tbrowder2 * r46808 10/brlcad/trunk/doc/docbook/validate.pl: more check and options available--help completely documented |
| 00:42.24 | CIA-63 | BRL-CAD: 03tbrowder2 * r46809 10/brlcad/trunk/doc/docbook/BRLCAD_DB_VALIDATION.pm: correcting path |
| 00:43.45 | CIA-63 | BRL-CAD: 03tbrowder2 * r46810 10/brlcad/trunk/doc/docbook/Makefile.am: add xml catalogs to xsltproc and fop execution |
| 01:10.42 | CIA-63 | BRL-CAD: 03brlcad * r46811 10/brlcad/trunk/src/librt/comb/comb.c: we don't use the resource, so only check validity if non-null |
| 01:16.47 | CIA-63 | BRL-CAD: 03brlcad * r46812 10/brlcad/trunk/src/librt/db5_io.c: use the rt_uniresource if we get passed a null resource since the functab functions require one for resource allocation. |
| 01:22.09 | CIA-63 | BRL-CAD: 03brlcad * r46813 10/brlcad/trunk/src/librt/db5_io.c: be consistent about checking the resource pointer, but only set rt_uniresource if it's a routine that calls into the functab. |
| 01:26.25 | starseeker | annnd adding those flags exposes other problems |
| 01:26.26 | starseeker | sighs - guess I know what I'm doing tomorrow |
| 01:29.17 | CIA-63 | BRL-CAD: 03brlcad * r46814 10/brlcad/trunk/src/librt/bundle.c: don't set the magic, it's not necessarily initialized. |
| 01:32.16 | CIA-63 | BRL-CAD: 03brlcad * r46815 10/brlcad/trunk/src/librt/shoot.c: note to self, there's a lot more work to be done here. unstable implementation that erroneously relies on zero-initialization. since this is in a critical path, it'll take more effort to 'make it better' and verify. |
| 01:47.25 | CIA-63 | BRL-CAD: 03brlcad * r46816 10/brlcad/trunk/src/librt/ (5 files in 2 dirs): more resource cleanup. setting the RESOURCE_MAGIC blindly is asking for trouble, don't do it. all calls to &rt_uniresource should go through a function so the global can be eliminated and initialization guaranteed. |
| 01:48.56 | CIA-63 | BRL-CAD: 03brlcad * r46817 10/brlcad/trunk/src/librt/db5_io.c: missing close paren |
| 01:52.56 | CIA-63 | BRL-CAD: 03brlcad * r46818 10/brlcad/trunk/src/librt/db_walk.c: don't halt on an RT_CK_RESOURCE check since it's not necessary that the parameter be non-NULL. pass the buck down. |
| 01:53.35 | CIA-63 | BRL-CAD: 03brlcad * r46819 10/brlcad/trunk/src/librt/db_walk.c: ws consistency cleanup |
| 02:02.36 | starseeker | :q |
| 02:03.36 | CIA-63 | BRL-CAD: 03starseeker * r46820 10/brlcad/trunk/src/other/ (4 files in 4 dirs): Backport some tcl.cmake changes from tcl/tk 8.6 work |
| 02:20.51 | CIA-63 | BRL-CAD: 03brlcad * r46821 10/brlcad/trunk/src/libged/lt.c: redundant nullity check |
| 02:50.42 | CIA-63 | BRL-CAD: 03tbrowder2 * r46822 10/brlcad/trunk/doc/docbook/validate.pl: correcting evaluating dbfils hash |
| 02:51.20 | CIA-63 | BRL-CAD: 03tbrowder2 * r46823 10/brlcad/trunk/doc/docbook/resources/brlcad/ (3 files): first cut at cleanup of customization xsl files |
| 03:17.32 | CIA-63 | BRL-CAD: 03brlcad * r46824 10/brlcad/trunk/src/conv/ (CMakeLists.txt Makefile.am g-dot.c): (log message trimmed) |
| 03:17.32 | CIA-63 | BRL-CAD: add an initial implementation of a BRL-CAD exporter for the DOT plain text graph |
| 03:17.32 | CIA-63 | BRL-CAD: description language. This exporter outputs the CSG DAG for a given set of |
| 03:17.32 | CIA-63 | BRL-CAD: objects with color coding based on the node type (presently only recognizing |
| 03:17.32 | CIA-63 | BRL-CAD: non-region combinations, regions, and primitives). works like a charm on a .g |
| 03:17.32 | CIA-63 | BRL-CAD: file and unlike the other exporters, will default to all top-level objects if |
| 03:17.33 | CIA-63 | BRL-CAD: none are specified (a concept that should be extended to all our exporters). |
| 03:19.15 | CIA-63 | BRL-CAD: 03brlcad * r46825 10/brlcad/trunk/src/libged/lt.c: free the vls that was initialized |
| 07:49.27 | *** join/#brlcad b0ef (~b0ef@78.58.34.95.customer.cdi.no) | |
| 07:51.30 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 07:51.30 | *** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 07:52.02 | *** join/#brlcad dli (~dli@67.55.34.89) | |
| 07:52.02 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 07:52.22 | *** join/#brlcad CIA-63 (~CIA@cia.atheme.org) | |
| 07:52.23 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 07:52.23 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 07:53.56 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 07:53.56 | *** join/#brlcad 13WAADT8D (~kanzure@131.252.130.248) | |
| 07:53.56 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 07:53.56 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 07:53.56 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 07:53.56 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 11:58.55 | CIA-63 | BRL-CAD: 03tbrowder2 * r46826 10/brlcad/trunk/TODO: add pdf index |
| 12:02.20 | CIA-63 | BRL-CAD: 03tbrowder2 * r46827 10/brlcad/trunk/TODO: index is really a contents listing and link reference |
| 12:04.29 | CIA-63 | BRL-CAD: 03tbrowder2 * r46828 10/brlcad/trunk/TODO: correct typo |
| 13:21.52 | CIA-63 | BRL-CAD: 03tbrowder2 * r46829 10/brlcad/trunk/doc/docbook/find-db-files.pl: always use strict and warnings for good Perl practice |
| 13:23.09 | CIA-63 | BRL-CAD: 03tbrowder2 * r46830 10/brlcad/trunk/doc/docbook/find-db-files.pl: tidy ws and sub names |
| 13:44.15 | CIA-63 | BRL-CAD: 03tbrowder2 * r46831 10/brlcad/trunk/doc/docbook/create-index.pl: add a new tool to create an index for DB products |
| 14:14.15 | CIA-63 | BRL-CAD: 03tbrowder2 * r46832 10/brlcad/trunk/src/other/tcl/generic/tcl.h: correct typo |
| 14:41.46 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:19.21 | CIA-63 | BRL-CAD: 03n_reed * r46833 10/brlcad/trunk/ (include/raytrace.h src/conv/iges/iges.c): removed last use of nmg_moveeu, now permanently renamed to nmg_je |
| 15:27.12 | CIA-63 | BRL-CAD: 03n_reed * r46834 10/brlcad/trunk/doc/deprecation.txt: added nmg_movveu->nmg_je substitution under minmally impacting api changes |
| 15:27.45 | *** join/#brlcad dli (~dli@67.55.34.89) | |
| 15:54.10 | CIA-63 | BRL-CAD: 03tbrowder2 * r46835 10/brlcad/trunk/doc/docbook/validate.pl: now all options should work including '--stop' |
| 16:04.21 | *** join/#brlcad dli (~dli@67.55.34.89) | |
| 16:21.51 | CIA-63 | BRL-CAD: 03bob1961 * r46836 10/brlcad/trunk/src/libged/get_autoview.c: libged/get_autoview now returns the largest of the radial vector components as the value for "size" instead of radial[X]. |
| 16:22.33 | CIA-63 | BRL-CAD: 03tbrowder2 * r46837 10/brlcad/trunk/doc/docbook/validate.pl: better info for output--option stop works on all three methods |
| 18:01.35 | *** join/#brlcad dli (~dli@67.55.34.89) | |
| 18:19.02 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1128565177.dsl.bell.ca) | |
| 18:24.35 | CIA-63 | BRL-CAD: 03brlcad * r46838 10/brlcad/trunk/src/libbu/ptbl.c: make sure buffer has been allocated before trying to free it. might be valid and null. also, make sure we don't dereference the ptbl until after BU_CK_PTBL(). |
| 18:25.47 | CIA-63 | BRL-CAD: 03brlcad * r46839 10/brlcad/trunk/src/libbu/ptbl.c: gah, fix copy/paste error. |
| 18:46.46 | ``Erik | huh, interesting http://blogs.msdn.com/b/oldnewthing/archive/2011/09/21/10214405.aspx |
| 18:47.17 | CIA-63 | BRL-CAD: 03brlcad * r46840 10/brlcad/trunk/ (include/bu.h src/libbu/quote.c): |
| 18:47.17 | CIA-63 | BRL-CAD: change the signature of bu_vls_encode/bu_vls_decode to return pointers to the |
| 18:47.17 | CIA-63 | BRL-CAD: strings that were encoded/decoded. this allows the functions to be chained |
| 18:47.17 | CIA-63 | BRL-CAD: together and embedded within printing statements without additional calls to |
| 18:47.17 | CIA-63 | BRL-CAD: bu_vls_addr(). tries to account for vls strings with existing content too. |
| 19:05.33 | ``Erik | "every time you make a powerpoint, edward tufte kills a kitten" |
| 19:15.33 | brlcad | it's true |
| 19:16.21 | ``Erik | http://tkkc.org |
| 19:54.30 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 20:44.37 | CIA-63 | BRL-CAD: 03brlcad * r46841 10/brlcad/trunk/TODO: some thoughts on the ambiguous historic use of u,+,- for the boolean operators and what to consider moving forward for rel8 |
| 21:15.40 | CIA-63 | BRL-CAD: 03brlcad * r46842 10/brlcad/trunk/src/libbu/ (CMakeLists.txt Makefile.am test_quote.c): stub in an initial unit test harness for new string quoting api |
| 21:23.33 | CIA-63 | BRL-CAD: 03brlcad * r46843 10/brlcad/trunk/src/conv/g-dot.c: |
| 21:23.33 | CIA-63 | BRL-CAD: keep track of which objects have already been written out with a creative (if I |
| 21:23.33 | CIA-63 | BRL-CAD: do say so myself) use of bu_ptbl using the bu_hash() of the object name. |
| 21:23.33 | CIA-63 | BRL-CAD: tracking each node type separately so they can be formatted as a group later. |
| 21:23.33 | CIA-63 | BRL-CAD: also include the title and name of the input file as a label on the graph. |
| 21:27.15 | CIA-63 | BRL-CAD: 03erikgreenwald * r46844 10/brlcad/trunk/src/libgcv/bottess.c: initialize intersect points. minor cleanup |
| 21:51.22 | CIA-63 | BRL-CAD: 03r_weiss * r46845 10/brlcad/trunk/src/conv/g-vrml.c: (log message trimmed) |
| 21:51.22 | CIA-63 | BRL-CAD: Significate updates to the 'g-vrml' converter. Some logic bugs were fixed. |
| 21:51.22 | CIA-63 | BRL-CAD: Triangulation was changed to use 'nmg_triangulate_model' instead of its own |
| 21:51.22 | CIA-63 | BRL-CAD: function which was very limited. Added two new options. A '-b' option to perform |
| 21:51.22 | CIA-63 | BRL-CAD: a bot dump (all csg geometry is ignored) and '-e' to perform an evaluation or |
| 21:51.22 | CIA-63 | BRL-CAD: all opjects including bots. By default bots are dumped and csg evaluation is |
| 21:51.23 | CIA-63 | BRL-CAD: perform ignoring the bots. Some code refactoring was also done. More testing is |
| 22:17.58 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 22:36.17 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 22:50.28 | CIA-63 | BRL-CAD: 03abhi2011 * r46846 10/brlcad/trunk/src/libged/simulate/simulate.c: fixed the parse_vector function to use libbu |
| 23:10.48 | CIA-63 | BRL-CAD: 03tbrowder2 * r46847 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: squash compiler warning of uninitiated var |
| 23:41.31 | CIA-63 | BRL-CAD: 03abhi2011 * r46848 10/brlcad/trunk/src/libged/simulate/simulate.c: added linear velocity and angular velocity properties to the list passed to physics |
| 23:57.46 | CIA-63 | BRL-CAD: 03tbrowder2 * r46849 10/brlcad/trunk/doc/docbook/ (6 files): ignore autogenerated files |
| 01:25.24 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 02:48.28 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 07:41.03 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 13:00.12 | CIA-63 | BRL-CAD: 03tbrowder2 * r46850 10/brlcad/trunk/doc/docbook/lessons/es/mged03_utilizar_comando_in.xml: remove period from title |
| 13:10.30 | CIA-63 | BRL-CAD: 03tbrowder2 * r46851 10/brlcad/trunk/doc/docbook/books/en/BRL-CAD_Tutorial_Series-VolumeIV.xml: add missing title |
| 14:15.41 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 14:42.31 | ``Erik | (union (difference s1 s2) s3) <-- that looks keen to me :D |
| 14:52.00 | CIA-63 | BRL-CAD: 03bob1961 * r46852 10/brlcad/trunk/ (13 files in 5 dirs): |
| 14:52.00 | CIA-63 | BRL-CAD: Changed the way dm-ogl and dm-wgl were handling zclipping (i.e. setting a value |
| 14:52.00 | CIA-63 | BRL-CAD: in the GL_MODELVIEW matrix). This adversely affected lighting if the window |
| 14:52.00 | CIA-63 | BRL-CAD: bounds were relatively big and was noticeable when viewing geometry in shaded |
| 14:52.00 | CIA-63 | BRL-CAD: mode. Added GUI components in Archer to control the front and back zclipping |
| 14:52.00 | CIA-63 | BRL-CAD: planes. |
| 14:54.15 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:10.14 | brlcad | ``Erik: heh, that adds potentially an order of magnitude to the processing time parsing those expressions |
| 15:10.48 | brlcad | especially nasty for expressions with more than a dozen operations (which is VERY common) |
| 15:12.29 | ``Erik | (define-symbol-macro + union) |
| 15:13.25 | brlcad | then it's back to the same issue of what to use for union and intersection :) |
| 15:14.20 | ``Erik | but but but lisp is magic fairy dust that makes everything right! :D |
| 15:53.33 | CIA-63 | BRL-CAD: 03bob1961 * r46853 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Don't need the extra call to go_draw() in the interlay section of go_refresh_draw(). |
| 16:42.05 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 18:20.51 | CIA-63 | BRL-CAD: 03r_weiss * r46854 10/brlcad/trunk/src/conv/g-vrml.c: |
| 18:20.52 | CIA-63 | BRL-CAD: Updated the 'g-vrml' converter. Corrected some bugs in the count of regions |
| 18:20.52 | CIA-63 | BRL-CAD: converted and regions attempted. Also added a count of the number of failed due |
| 18:20.52 | CIA-63 | BRL-CAD: to bombs. Changed the logic so that if errors occur during conversion, the |
| 18:20.52 | CIA-63 | BRL-CAD: conversion will continue and at the end report the number of errors. |
| 18:33.22 | CIA-63 | BRL-CAD: 03bob1961 * r46855 10/brlcad/trunk/src/libdm/dm-wgl.c: Fix a cut-n-paste error. |
| 18:33.37 | *** join/#brlcad abhi2011 (~chatzilla@x033197.its-s.tudelft.nl) | |
| 19:41.56 | abhi2011 | is there a macro for testing if a floating point value is exactly 0 |
| 19:42.00 | abhi2011 | not just near 0 |
| 19:42.14 | abhi2011 | or is fabs(f) == 0 the only option |
| 20:05.01 | brlcad | abhi2011: there is no way you can portably guarantee that a floating point value is exactly 0 |
| 20:05.34 | brlcad | relying on that usually implies a flaw in the math/logic that doesn't account for the actual nature of floating point math |
| 20:06.58 | brlcad | fabs(f) == 0 isn't necessarily reliable either (and doesn't address the issue of wanting to rely on zeroness) |
| 20:08.19 | abhi2011 | well I want to check if the passed mass is 0 |
| 20:08.22 | abhi2011 | by the user |
| 20:08.54 | brlcad | so check with ZERO(), what's the issue? |
| 20:09.16 | abhi2011 | ok, there is a line about it not being recommended in the comments |
| 20:10.15 | brlcad | well it's not recommended, but it's certainly better than trying to fake it with things like fabs(f) == 0 :) |
| 20:10.32 | abhi2011 | yup, stuck that into the code now |
| 20:10.51 | brlcad | the issue is that you haven't defined how close to zero you have to be |
| 20:11.07 | abhi2011 | yeah, the epsilon |
| 20:11.14 | brlcad | that's why it recommends against it (instead favoring NEAR_ZERO() with the tolerance defined) |
| 20:11.32 | brlcad | is 0.0000000000000000001 "close enough"? |
| 20:11.54 | brlcad | how about 6 zeros, 3 zeros, 1 zero? .. |
| 20:12.05 | abhi2011 | ok, hehe yeah, bullet wroks with sngle point precision so it should be :P |
| 20:12.50 | brlcad | ZERO() still uses a tolerance |
| 20:13.12 | abhi2011 | yes it used near_zero(), well i think the less than and greater than comparisons should be fine |
| 20:13.27 | abhi2011 | for the == stuff ZERO() is good enuf |
| 20:13.30 | brlcad | it just uses a hard-coded platform-varying tolerance that should roughly equate to "roughly as precise as this hardware is capable of being" .. |
| 20:13.38 | abhi2011 | ah nice |
| 20:13.43 | brlcad | which is often not what the math actually affords, that makes it dangerous |
| 20:14.52 | brlcad | the hardware may be capable of 1e-40, but if you take a square root of something a few times, or use single precision, or pass through print specifiers, or divide, or ... you might end up with a "zero" 1e-7 |
| 20:15.02 | brlcad | and ZERO() will be false |
| 20:17.43 | brlcad | if bullet uses single precision (really? wtf..) |
| 20:17.55 | brlcad | then you should probably define your tolerance |
| 20:18.15 | brlcad | single precision is much looser than most hardware is cabable of ... |
| 20:19.01 | brlcad | I'd suggest something like 0.001 |
| 20:19.23 | brlcad | that's roughly sqrt(FLT_EPSILON) |
| 20:20.15 | brlcad | 0.0005 if you want to be consistent with the rest of BRL-CAD |
| 20:21.17 | abhi2011 | ok |
| 20:21.25 | abhi2011 | yes, bullet can be set to double precision |
| 20:22.00 | brlcad | that'd probably be better as a default |
| 20:22.15 | brlcad | maybe have a -f fast flag that will use single precision instead |
| 20:23.20 | abhi2011 | right ok, btw if 0.0005 is default , there should be a constant that defines it |
| 20:24.25 | abhi2011 | will have a look at vmath.h |
| 20:25.08 | abhi2011 | hmm ok FLT_EPSILON & DBL_EPSILON |
| 20:48.23 | CIA-63 | BRL-CAD: 03abhi2011 * r46856 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c simulate.h): |
| 20:48.23 | CIA-63 | BRL-CAD: modified simulation code to persist velocities between each simulation step Now |
| 20:48.23 | CIA-63 | BRL-CAD: bullet does a single step of simulation and saves the state of rigid bodies as |
| 20:48.23 | CIA-63 | BRL-CAD: well as updates the transforms in the dbthis will allow rt to shoot rays in the |
| 20:48.23 | CIA-63 | BRL-CAD: updated model |
| 21:02.08 | brlcad | abhi2011: it's not a constant globally defined for that tolerance, each application defines the tolerance |
| 21:02.43 | brlcad | in your case, you're running as a libged command, so you can just use whatever tolerance is presently set |
| 21:02.49 | brlcad | ``Erik: http://brlcad.org/tmp/rtvstie.png |
| 21:03.26 | brlcad | lots of off-by-many on that center poly |
| 21:05.08 | brlcad | abhi2011: ged_wdbp->tol->dist is there the current tolerance should be stashed |
| 21:26.31 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 22:01.20 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 22:33.52 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 22:55.06 | CIA-63 | BRL-CAD: 03abhi2011 * r46857 10/brlcad/trunk/src/libged/simulate/simulate.c: fixed a crash due to usage of memory before mallocing it |
| 23:31.32 | *** join/#brlcad sparrW (~kvirc@pdpc/supporter/active/sparr) | |
| 23:47.56 | brlcad | 277MB step file churning away... giggity |
| 00:35.41 | louipc | whoa |
| 02:27.00 | brlcad | 102480 surface edges, 27195 edge loops, 51393 edge curves, 18359 advanced faces, 10015 cylindrical surfaces, 2691 bspline surfaces, ... |
| 02:56.31 | CIA-63 | BRL-CAD: 03brlcad * r46858 10/brlcad/trunk/src/librt/db_match.c: get rid of the stupid BU_ASSERTING, they're really just UNUSED. |
| 02:56.50 | CIA-63 | BRL-CAD: 03brlcad * r46859 10/brlcad/trunk/src/librt/prep.c: client_data isn't actually UNUSED.. |
| 02:58.15 | CIA-63 | BRL-CAD: 03brlcad * r46860 10/brlcad/trunk/src/librt/ (db_match.c prep.c): ws consistency cleanup |
| 03:11.28 | CIA-63 | BRL-CAD: 03brlcad * r46861 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: hit_count is potentially used prior to initialization, account for it and all of his friends by initializing to zero/null. |
| 03:15.19 | CIA-63 | BRL-CAD: 03brlcad * r46862 10/brlcad/trunk/src/librt/primitives/ (ehy/ehy.c epa/epa.c hyp/hyp.c rpc/rpc.c submodel/submodel.c): remove a slew of BU_ASSERT hacks that were only added to quell use warnings. use the UNUSED() macro for betterness. |
| 03:15.57 | CIA-63 | BRL-CAD: 03brlcad * r46863 10/brlcad/trunk/src/libgcv/bottess.c: someone was just kidding, tol isn't really unused |
| 03:44.09 | CIA-63 | BRL-CAD: 03brlcad * r46864 10/brlcad/trunk/src/libged/push.c: curtree is actually used. hard to miss it. |
| 04:11.21 | CIA-63 | BRL-CAD: 03brlcad * r46865 10/brlcad/trunk/include/nmg.h: not your responsibility to define NULL and it's a crappy definition anyways. |
| 05:12.06 | CIA-63 | BRL-CAD: 03brlcad * r46866 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: more unused LIARS |
| 05:14.57 | CIA-63 | BRL-CAD: 03brlcad * r46867 10/brlcad/trunk/src/liboptical/ (sh_air.c sh_light.c): and a few more checks added for quellage, but they're really UNUSED |
| 05:28.59 | CIA-63 | BRL-CAD: 03brlcad * r46868 10/brlcad/trunk/src/ (mged/dodraw.c remrt/remrt.c): couple more UNUSED tricksters |
| 05:32.28 | CIA-63 | BRL-CAD: 03brlcad * r46869 10/brlcad/trunk/include/common.h: |
| 05:32.28 | CIA-63 | BRL-CAD: add a new IGNORE() macro for use by all of the various macros that turn into |
| 05:32.28 | CIA-63 | BRL-CAD: 'nothing' if the right compilation flags are set. for now, go with a simple |
| 05:32.28 | CIA-63 | BRL-CAD: '(void)param' to quell unused usage warnings but begs testing on msvc2010. |
| 05:32.28 | CIA-63 | BRL-CAD: while we're at it, mangle parameters marked as UNUSED() with a prefix so we can |
| 05:32.28 | CIA-63 | BRL-CAD: catch failings in both directions, catching instances where UNUSED() was |
| 05:32.29 | CIA-63 | BRL-CAD: erroneously set yet the parameter is actually used. |
| 05:34.39 | CIA-63 | BRL-CAD: 03brlcad * r46870 10/brlcad/trunk/include/ (bu.h magic.h raytrace.h): |
| 05:34.39 | CIA-63 | BRL-CAD: put the new IGNORE() macro to use in place of (void)0 since we were still |
| 05:34.39 | CIA-63 | BRL-CAD: getting strict warnings about parameters not being used because they were only |
| 05:34.39 | CIA-63 | BRL-CAD: being used in ifdef sections or CK macros. IGNORE() shouldn't be used in |
| 05:34.39 | CIA-63 | BRL-CAD: application code, but these bombing/checking macros are perfect use cases. |
| 05:37.06 | brlcad | whew, finally got all of them |
| 05:43.38 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 07:13.28 | brlcad | boo, hiss .. step import churned and churned but only a few things came in |
| 07:13.42 | brlcad | and the few that did come in aren't looking so hot |
| 07:13.56 | brlcad | wanders |
| 08:24.42 | *** join/#brlcad dli_ (~dli@dsl-173-248-196-72.acanac.net) | |
| 09:43.08 | *** join/#brlcad dli_ (~dli@dsl-173-248-235-17.acanac.net) | |
| 12:54.32 | abhi2011 | i have been getting this stranger error whenever I try to include raytrace.h in simphysics.cpp |
| 12:55.30 | abhi2011 | the error is : /home/abhi/socis/brlcad/include/brep.h:36:23: fatal error: opennurbs.h: No such file or directory |
| 12:56.21 | abhi2011 | raytrace.h:47 > rtgeom.h:42:0, > brep.h |
| 12:56.53 | abhi2011 | this is because now I am trying to do librt stuff inside the cpp file |
| 12:57.33 | abhi2011 | I need to use rt for detecting overlaps and generate contact points, but I do not want to that in the simulate.c file |
| 12:58.08 | abhi2011 | so I am going to transforms the objects into their new position in the db and then shoot rays within functions defined in the cpp file |
| 12:58.46 | abhi2011 | but it seems that the minute i try to include raytrace.h in the cpp file the build breaks :( |
| 13:00.39 | abhi2011 | i of course need raytrace.h included to have access to rt_matrix_transform() to position the simulated objects, after each physics step |
| 13:40.39 | ``Erik | probably means an omission from the cmake/automake file about legitimage paths... though this does expose something; rt_matrix_transform might be better placed as bn_matrix_transform O.o |
| 14:12.10 | brlcad | rt_matrix_transform isn't just a general matrix function |
| 14:12.23 | brlcad | it applies that matrix and writes it out on specified geometry |
| 14:13.10 | brlcad | the db internal geometry is transformed, not the matrix |
| 14:19.12 | brlcad | abhi2011: so you're somehow missing a common include directory (src/other/opennurbs) |
| 14:19.42 | brlcad | what does "make VERBOSE=1" output (pastebin)? |
| 14:27.30 | ``Erik | rt_write_matrix(bn_matrix_transform(m)); ? |
| 14:29.47 | ``Erik | (symbol documentation, I spew what I assume as a reasonably knowledgeable codemonkey) |
| 14:31.32 | brlcad | that's my point, there is no transform being done on a matrix |
| 14:31.46 | brlcad | so it's just be a rename to rt_write_matrix perhaps |
| 14:32.05 | brlcad | rt_apply_matrix() is probably more apt |
| 14:32.17 | brlcad | since it won't necessarily "write" anything |
| 14:33.38 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:35.30 | ``Erik | I'm in favor of renaming that function, fwiw |
| 14:39.07 | CIA-63 | BRL-CAD: 03starseeker * r46871 10/brlcad/trunk/src/libged/CMakeLists.txt: Add the opennurbs include dir to libged's include list |
| 14:40.32 | starseeker | abhi2011: give that a shot |
| 14:42.05 | brlcad | starseeker: it seems backwards (and it's not your fault, autotools is also to blame) to have to list include dirs like that |
| 14:44.20 | brlcad | think there should be top-level BU_CPPFLAGS, RT_CPPFLAGS, etc or BU_INCLUDE_DIRS, RT_INCLUDE_DIRS, etc that have those interface paths defined, then lower-level CMakeLists.txt files would just use them if they use the library |
| 14:44.50 | brlcad | otherwise we're just going to end up with "include everything all the time" and that's not very useful or safe |
| 14:45.38 | starseeker | disagrees - i never liked those vars in autotools, it made it difficult to see where a particular directory was coming from in the logic |
| 14:45.50 | starseeker | too much obfuscation |
| 14:46.13 | brlcad | the alternative is excessive replication |
| 14:46.41 | starseeker | how bad is that, really though? |
| 14:46.51 | starseeker | once set up, the changes aren't too bad |
| 14:47.00 | starseeker | (this one was a straightforward one-liner) |
| 14:47.24 | brlcad | short term gain, long term cost (like any code duplication) |
| 14:47.30 | brlcad | change one of them |
| 14:47.35 | starseeker | if this had happened with toplevel vars, I would have had to track back through to see what the toplevel vars contained and which one might be a logica candidate for this dir... |
| 14:47.49 | brlcad | you have to find the 400+ instances it's used (or dozens if it's per dir) |
| 14:48.04 | brlcad | doesn't have to be top-level vars |
| 14:48.24 | brlcad | in terms of encapsulation, it's make more sense for the libs to define their needs |
| 14:49.21 | brlcad | think of libbu as its own product, it'd declare cppflags that included tcl, for example .. but users of libbu just use libbu's declared interface |
| 14:50.10 | brlcad | that wasn't done for autotools because it wasn't easily doable with our recursive automake setup, so the variables propagated up to the top |
| 14:50.17 | brlcad | for cmake, that's not the case |
| 14:50.58 | starseeker | concedes the point, but still doesn't like the idea of "what gets included" being buried so deep - it feels like C++, digging through layers to find an int at the bottom of the type pile... |
| 14:54.16 | starseeker | but I always lose these arguments ;-), so let's see... how to do it... probably the BU_INCLUDE_DIRS approach would be best... |
| 14:54.24 | brlcad | another way to look at it -- just about every app (400+) uses librt which uses libbu which results in *always* needing paths for zlib, regex, tcl, opennurbs, .. always needing to include ${ZLIB_INCLUDE_DIR}, ${REGEX_INCLUDE_DIR}, ${TCL_INCLUDE_DIRS}, ${OPENNURBS_INCLUDE_DIR} |
| 14:54.58 | starseeker | nods - yeah, it would be a LoC reduction, no question |
| 14:55.08 | brlcad | there are minimally about 50 source dirs where those have to be specified |
| 14:55.36 | brlcad | add one more, rename one, remove one ... that's 50+ edits |
| 14:55.47 | brlcad | massive DRY fail :) |
| 14:58.18 | starseeker | I'm going to do one additional thing though, if I introduce the BU_INCLUDE_DIRS style mechanisms - I'm going to build a list of dirs and then remove duplicates before the actual include command, to try and keep the command line verbosity down... |
| 15:08.24 | brlcad | yeah, that'd be awesome |
| 15:08.35 | starseeker | blinks in surprise - apparently libbu doesn't use regex |
| 15:09.25 | brlcad | librt |
| 15:09.35 | starseeker | nods |
| 15:10.01 | starseeker | I knew it was in there, just a little startled it hasn't crept down to the libbu level yet |
| 15:10.23 | starseeker | would have thought some sort of regex something or other would have been packaged up for general consumption by now ;-) |
| 15:10.31 | brlcad | another benefit of the encapsulation, catch issues like that more obviously so you don't include regex by default everywhere bu is used |
| 15:11.06 | brlcad | regex it is needed, but indirect |
| 15:11.09 | brlcad | bu -> tcl -> regex |
| 15:11.28 | brlcad | so tcl should have it specified in tcl's include dirs |
| 15:11.35 | starseeker | nods |
| 15:12.18 | brlcad | last night was a good coding night, trying to get some new libbu interfaces in place |
| 15:12.34 | starseeker | sweet |
| 15:13.24 | brlcad | better string management to help with processing object names and lists of objects (which all of libged could use) |
| 15:13.47 | brlcad | basic things that makes one slap the forehead and ask why they weren't there 10 years ago |
| 15:14.04 | brlcad | but some more complex ones too, like globbing |
| 15:14.16 | starseeker | something beyond fnmatch? |
| 15:14.21 | brlcad | yep |
| 15:15.01 | starseeker | that would be awesome - I'd love to be able to do per-command globbing on mged command line to avoid having to quote the bejeezus out of search commands... |
| 15:15.03 | brlcad | basically a corollary to glob(3) |
| 15:15.16 | brlcad | including a mechanism for iterating |
| 15:28.32 | CIA-63 | BRL-CAD: 03starseeker * r46872 10/brlcad/trunk/src/ (3 files in 3 dirs): Start figuring out how to wrap includes needed for a directory into a variable and use that variable in other CMakeLists.txt files that are including the library |
| 15:48.38 | brlcad | hm, careful use there -- BU_INCLUDE_DIRS only needs to include headers used by the public headers |
| 15:49.00 | brlcad | implementation headers don't need to be included, they're still just regular include_dirs() |
| 15:49.24 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 15:50.11 | brlcad | uce-dirent, png being the two examples not publicly used |
| 15:50.47 | brlcad | zlib too, hm! |
| 15:51.09 | brlcad | those are INCLUDE_DIRS like regex, needed by src/other stuff |
| 15:52.20 | brlcad | opennurbs, png, and tkpng use zlib |
| 15:55.48 | brlcad | doesn't look like anything uses png publicly |
| 15:56.20 | brlcad | bu, fb, dm, ged, tclcad, and a few util tools use it privately |
| 16:53.22 | abhi2011 | brlcad: here is the verbose build output : http://bin.cakephp.org/view/1626192759 |
| 16:54.17 | abhi2011 | ah ok, just saw starseeker's update, will try it |
| 17:04.50 | CIA-63 | BRL-CAD: 03bob1961 * r46873 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Set zclip flag to 0 in ArcherCore::doLighting. |
| 17:13.00 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 17:25.50 | abhi2011 | cool, now the raytrace.h related errors are gone, however I also need to pass gedp to the functions in simphysics.cpp, so I have included ../ged_private.h in the simulate.h file(as that file declares struct ged in ged.h) |
| 17:26.24 | abhi2011 | i get this warning : /home/abhi/socis/brlcad/include/ged.h:2289:78: warning: ‘int ged_view(ged*, int, const char**)’ hides constructor for ‘struct ged_view’ |
| 17:27.37 | starseeker | so... once we get tcl out of libbu, we'll have no need for BU_INCLUDE_DIRS? |
| 17:32.12 | CIA-63 | BRL-CAD: 03n_reed * r46874 10/brlcad/trunk/src/ (conv/obj-g_new.c libgcv/wfobj/tri_face.c): plugged a few leaks |
| 17:36.49 | abhi2011 | hmm I think the warning is coming because ged.h is being compiled by the c++ component of gcc |
| 17:37.09 | abhi2011 | otherwise no constructor stuff should have been seen |
| 17:39.08 | abhi2011 | i do need the gedp as i get the internal representation of a object using GED_DB_GET_INTERNAL(gedp,.... |
| 17:39.17 | abhi2011 | in the cpp file |
| 17:39.38 | abhi2011 | however I ll see if I can use just librt instead, so all gedp references can be removed |
| 17:45.13 | CIA-63 | BRL-CAD: 03starseeker * r46875 10/brlcad/trunk/src/ (4 files in 2 dirs): Swap in the new obj-g for the old, stop building both. |
| 17:54.51 | starseeker | didn't realize the current installed layout wasn't ideal... I'm not really sure how much logic would have to be reworked to suport another layout, I was assuming the current layout was *the* layout... |
| 17:56.36 | starseeker | thought the version number in the share subdirectory was to allow for warnings/wipeouts running one version of brlcad and having the root directory set to another version's location... then attempts to get "version x.y.z" data from that direcory would fail despite being set to the wrong directory... |
| 17:58.32 | starseeker | seemed like a nice way to avoid subtle "almost working but it failed" situations... |
| 19:17.24 | brlcad | abhi2011: you should only include ged_private.h if you use something that header provides -- just include ged.h directly |
| 19:18.27 | brlcad | starseeker: there's still a need for BU_INCLUDE_DIRS -- it's presently just the top-level include dir |
| 19:19.04 | brlcad | your logic that eliminates duplicates will take care of keeping only one instance, while letting bu-only and rt-only apps to behave correctly |
| 19:20.47 | brlcad | starseeker: having the versioned sub-directory does help with multi-version installs, that was also intentional |
| 19:21.50 | brlcad | but the fact that it's only the datadir wasn't -- the goal was fully versioned installs into a NON-VERSIONED root directory (like /usr) |
| 19:25.09 | brlcad | having separation of BRLCAD_DATA and BRLCAD_ROOT provides similar multi-redundancy protections from using the wrong data |
| 19:25.23 | brlcad | should probably just write this all up on the wiki |
| 19:36.20 | brlcad | n_reed: a cleanup chare, should mark all of the non-public functions as static in wfobj |
| 19:36.59 | n_reed | consider it done |
| 19:37.58 | n_reed | although HIDDEN would be better right? |
| 19:38.16 | brlcad | if there is value in being able to debug into that function, sure |
| 19:38.38 | brlcad | not for front-end code, that should use static |
| 19:38.58 | brlcad | but library funcs can use either -- HIDDEN for public API and discretion for non-public |
| 19:42.58 | n_reed | trying to understand... so the point of HIDDEN is just to allow toggling static-ness |
| 19:49.42 | CIA-63 | BRL-CAD: 03n_reed * r46876 10/brlcad/trunk/ (doc/docbook/system/man1/en/obj-g.xml src/conv/obj-g.c): some updates to obj-g documentation |
| 19:56.39 | starseeker | erm. the top level include dir I've been including in *all* of src via the src/CMakeLists.txt file... |
| 19:58.55 | brlcad | n_reed: basically |
| 19:59.50 | brlcad | some compilers will fully inline static functions at their discretion, making it impossible to set a breakpoint for debugging |
| 20:00.56 | brlcad | so if there is any value at any time to be able to debug into that function as a breakpoint (which there is for most public API, by definition), then HIDDEN should be used instead of static |
| 20:03.05 | brlcad | coincidentally, it also helps to avoid function name ambiguity by not allowing implementation-detail functions to have the same name as front-end application functions |
| 20:03.43 | brlcad | helps ensure functions are properly named with some non-conflicting prefix or other name convention |
| 20:09.22 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 20:30.21 | CIA-63 | BRL-CAD: 03starseeker * r46877 10/brlcad/trunk/src/ (7 files in 7 dirs): Make another try at include_dirs updates... |
| 20:30.42 | starseeker | brlcad: that more what you had in mind? (before I go any further...) |
| 20:34.40 | brlcad | starseeker: yeah, that's looking great |
| 20:36.01 | starseeker | k. actually kinda handy that I was including the toplevel include in src - taking it out makes for a very simple "fail because I'm not converted yet" situation :-) |
| 20:36.16 | brlcad | also makes a couple low-lying fruit obvious, things that should get fixed |
| 20:36.31 | brlcad | like libfb needing to include pkg.h .. stupid |
| 20:36.52 | brlcad | should be hidden in the impl or passed by the caller |
| 20:37.10 | brlcad | it's for just one pointer |
| 20:40.31 | starseeker | I realize it's a bit premature, but with the "every command in libged being a plugin" approach, will the policy be that headers included by the individual commands not be part of the required includeds at the toplevel? Or, put another way, can we require that any include dir needed for ged users be specified at the toplevel ged CMakeLists.txt and not in the command subdirectories? |
| 20:45.21 | CIA-63 | BRL-CAD: 03starseeker * r46878 10/brlcad/trunk/src/ (3 files in 3 dirs): Convert a few more directories to new include_dir scheme |
| 20:52.26 | starseeker | man liborle is so small it's hardly even there... |
| 20:53.23 | starseeker | wonders if that could fold entirely into something else like libicv... |
| 21:28.43 | brlcad | that's just sad.. |
| 21:29.22 | brlcad | came across some old tcl code in some old directory in my data archive |
| 21:30.27 | brlcad | my fingerprints are all over it .. naming conventions, code structure, style .. and sure enough my name is in one of the files as the author |
| 21:31.02 | brlcad | but it took a solid 10 minutes of actually running the code, seeing the gui that pops up, poking on it to even have a glimmer of memory doing that |
| 21:33.07 | brlcad | (it was an inteface for shooting rays at geometry, plotting the hit points (similar to nirt), and providing the option to create actual geometry for the hit points (spheres) and path segments (cylinders/arb8s) .. which someone had requested at some point) |
| 21:35.38 | starseeker | hmm, nifty |
| 21:35.45 | brlcad | starseeker: liborle and the two tools that use it can be deprecated, but they've just not been a maintenance burden to even bother |
| 21:35.46 | starseeker | surprised it didn't get rolled into mged |
| 21:35.53 | brlcad | it wasn't completed |
| 21:35.58 | starseeker | ah |
| 21:36.15 | starseeker | brlcad: is code tidiness a sufficient motive to depricate? :-P |
| 21:36.19 | brlcad | the gui is actually pretty far along |
| 21:36.21 | starseeker | deprecate even |
| 21:37.50 | brlcad | *shrug*, if you want to both go for it, but there are *hundreds* of code tidiness issues like that such that it's been plenty enough as-is to just deprecate when they incur some cost (like a build failure that might take more than 10 seconds to fix) |
| 21:38.30 | brlcad | deprecating has a cost too .. those little 10 minute activities add up with context switching :) |
| 21:38.32 | starseeker | <snort> in this case, it's just rewriting the CMake logic for liborle everytime a paradigm change takes place - once that stops, I suppose i twon't matter |
| 21:38.46 | brlcad | that's a maintenance cost actually |
| 21:39.14 | brlcad | so if you deprecate now, they could go when autotools goes |
| 21:39.33 | brlcad | then you don't even have to worry, let autotools build and yank the cmake |
| 21:39.40 | starseeker | nods - let me check which tools those are... - src/util I presume? |
| 21:39.48 | brlcad | fb and util |
| 21:41.10 | brlcad | that goes MUCH farther back than my tcl discovery today, but i *think* it used to be a hand-rolled rle library that was replaced when urtoolkit's librle came out |
| 21:42.08 | CIA-63 | BRL-CAD: 03starseeker * r46879 10/brlcad/trunk/doc/deprecation.txt: list liborle and corresponding tools for deprecation |
| 21:42.15 | brlcad | new tools were written but the old ones were kept around for some reason that's been lost in time (probably out-perform) |
| 21:42.22 | starseeker | nods |
| 21:42.47 | starseeker | has yet to use *any* of the rle utils at all... guess I just haven't needed 'em yet |
| 21:42.53 | brlcad | should put the version too |
| 21:43.05 | starseeker | hmm? |
| 21:43.22 | starseeker | oh |
| 21:43.32 | starseeker | 7.20? |
| 21:43.35 | brlcad | nods |
| 21:44.05 | CIA-63 | BRL-CAD: 03starseeker * r46880 10/brlcad/trunk/doc/deprecation.txt: add version |
| 21:44.51 | brlcad | that's so deprecations can be cherry-picked into the obsolete section with just a copy-paste |
| 21:46.00 | CIA-63 | BRL-CAD: 03starseeker * r46881 10/brlcad/trunk/src/ (8 files in 8 dirs): Add a few more to the 'converted' list for include dirs - got a ways to go, pretty far reaching change. |
| 21:46.39 | brlcad | starseeker: since there are binaries going away, they get a statement too (see src/util/dbcp.c) |
| 21:47.04 | starseeker | each one gets a statement? |
| 21:47.27 | brlcad | so a message is printed when run |
| 21:47.34 | starseeker | oh, gotcha |
| 21:47.42 | starseeker | not in doc/deprecation, but in the C code itself |
| 21:47.43 | brlcad | doesn't have to be the same message as dbcp's, but should be something similar |
| 21:47.47 | brlcad | right |
| 21:48.11 | brlcad | doc/deprecation is meant to let devs know -- if a tool is going to disappear, we just put a statement in the tool |
| 21:48.58 | brlcad | (and in doc/deprecation, but users just aren't likely to or expected to look there .. they just use the tools they know) |
| 21:49.04 | brlcad | would be good to point them to the new tools |
| 21:49.09 | CIA-63 | BRL-CAD: 03starseeker * r46882 10/brlcad/trunk/src/fbserv/CMakeLists.txt: that was easy... convert fbserv to new includes |
| 21:49.16 | brlcad | "Use rle-fb instead!" |
| 21:51.10 | brlcad | been consistently using the marker DEPRECATED for both dev code comments and user printing statements |
| 21:51.17 | brlcad | so they're all easy to find |
| 21:51.36 | starseeker | do I need to support the D option? |
| 21:52.40 | starseeker | interesting - fb-orle's usage statement says fb-rle |
| 21:55.35 | CIA-63 | BRL-CAD: 03n_reed * r46883 10/brlcad/trunk/src/libgcv/wfobj/ (6 files): interface cleanup, including hiding local functions |
| 21:57.27 | CIA-63 | BRL-CAD: 03starseeker * r46884 10/brlcad/trunk/src/ (fb/fb-orle.c fb/orle-fb.c util/orle-pix.c util/pix-orle.c): Add deprecation warning messages to the fb and pix tools pertaining to orle. |
| 21:59.40 | *** join/#brlcad dli (~dli@dyn-157-046.wireless.concordia.ca) | |
| 22:14.48 | CIA-63 | BRL-CAD: 03starseeker * r46885 10/brlcad/trunk/src/ (5 files in 5 dirs): Convert a few more include dir lists. |
| 23:10.58 | *** join/#brlcad dli (~dli@dyn-157-046.wireless.concordia.ca) | |
| 23:16.57 | CIA-63 | BRL-CAD: 03abhi2011 * r46886 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c simulate.h): Moved position transformation functions into simphysics.cpp and rearranged some code to fit in a call to rt |
| 23:42.56 | *** join/#brlcad dli (~dli@dyn-157-046.wireless.concordia.ca) | |
| 00:16.12 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 00:16.40 | *** join/#brlcad dli (~dli@dyn-157-046.wireless.concordia.ca) | |
| 03:06.22 | *** join/#brlcad starseek1r (~starseeke@BZ.BZFLAG.BZ) | |
| 03:10.44 | *** join/#brlcad CIA-54 (~CIA@cia.atheme.org) | |
| 03:11.44 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 03:35.50 | CIA-54 | BRL-CAD: 03starseeker * r46887 10/brlcad/trunk/ (18 files in 18 dirs): A pattern emerges - time for a macro. 4 lines to one line. |
| 04:33.25 | *** join/#brlcad dli (~dli@66.49.232.173) | |
| 09:18.59 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 13:04.24 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 20:54.47 | starseek1r | hah - grapviz high level view of BRL-CAD's build system: http://bzflag.bz/~starseeker/brlcad_build_graphviz.png |
| 21:16.18 | *** join/#brlcad dli (~dli@66.49.232.173) | |
| 23:29.31 | *** join/#brlcad abhi2011 (~chatzilla@x033197.its-s.tudelft.nl) | |
| 00:08.59 | *** join/#brlcad Otto_ (~Otto@cpe-24-210-25-11.columbus.res.rr.com) | |
| 01:15.37 | brlcad | starseeker: what do the lines represent? |
| 01:21.39 | starseeker | you mean the lines in the macro? they're the duplication elimination and setting values in the cache to allow use of the include dirs in other locations |
| 01:21.58 | starseeker | oh, the graphic |
| 01:22.09 | starseeker | build dependency information |
| 01:22.31 | starseeker | libraries and executables (they don't include custom targets, at least for now) |
| 01:22.55 | starseeker | so a line between two nodes means one depends on the other during build |
| 01:25.07 | brlcad | hm, a bit more chaotic than I'd expect actually |
| 01:25.43 | brlcad | or just a very poor default layout .. |
| 01:26.13 | brlcad | neat though |
| 01:26.55 | brlcad | maybe a different layout scheme, not radial .. what's digraph look like? |
| 02:14.15 | starseeker | digraph? |
| 02:14.51 | starseeker | brlcad: if you want to play with it, you can generate it with cmake .. --graphviz=brlcad.dot |
| 02:17.29 | starseeker | original svg file is here: http://bzflag.bz/~starseeker/brlcad.svg |
| 02:19.51 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 03:47.01 | brlcad | starseeker: digraph is an alternate graph style used for directed graphs |
| 07:35.11 | CIA-54 | BRL-CAD: 03starseeker * r46888 10/brlcad/trunk/src/ (28 files in 28 dirs): Not sure the sets are absolutely correct, but this should be most of the remaining conversion to the new include_directories setup |
| 07:39.10 | CIA-54 | BRL-CAD: 03starseeker * r46889 10/brlcad/trunk/bench/CMakeLists.txt: bench's pixdiff uses libbu |
| 11:24.30 | *** join/#brlcad kunigami_ (~kunigami@201.82.92.180) | |
| 13:07.35 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-185-172.wlan.tudelft.nl) | |
| 13:08.29 | abhi2011 | hmm ran into some issues the minute I moved the transformation code for transforming objects in the db , into the cpp file |
| 13:09.06 | abhi2011 | have to make changes in small increments now...lots of functions that have to be called in the correct sequence |
| 17:31.56 | CIA-54 | BRL-CAD: 03abhi2011 * r46890 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c simulate.h): fixing some functions after I had to revert back to resolve some positioning issues, modifying the code step by step now |
| 17:32.04 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 17:57.20 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 17:57.20 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 00:02.07 | *** join/#brlcad dli (~dli@dsl-69-172-118-38.acanac.net) | |
| 00:22.18 | CIA-54 | BRL-CAD: 03abhi2011 * r46892 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c): ok, now the functions are arranged the way i want it with the physics properly working again, should be able to shoot rays by tomorrow and create contact manifolds |
| 02:31.34 | *** join/#brlcad dli_ (~dli@dsl-173-248-194-55.acanac.net) | |
| 09:10.11 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 09:10.11 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 09:30.01 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 10:25.58 | *** join/#brlcad kunigami_ (~kunigami@201.82.92.180) | |
| 11:02.41 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-186-097.wlan.tudelft.nl) | |
| 11:17.17 | CIA-54 | BRL-CAD: 03tbrowder2 * r46893 10/brlcad/trunk/doc/docbook/create-book-covers.pl: add prog to generate book covers for pdf |
| 11:24.03 | *** join/#brlcad abhi2011_ (~chatzilla@wlan-145-94-186-097.wlan.tudelft.nl) | |
| 11:25.20 | *** join/#brlcad CIA-48 (~CIA@cia.atheme.org) | |
| 12:22.00 | CIA-48 | BRL-CAD: 03tbrowder2 * r46894 10/brlcad/trunk/doc/docbook/Makefile.am: add special non-auto-build target for pdf cover generation and testing |
| 12:49.53 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 13:20.17 | CIA-48 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3170 10/wiki/User:Abhijit: /* Log */ |
| 13:24.37 | CIA-48 | BRL-CAD: 03brlcad * r46895 10/brlcad/trunk/src/conv/Makefile.am: obj-g.c no longer compiles with autotools since libgcv's wfobj sources aren't set up with autotools, so turn it off |
| 14:18.09 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:46.33 | CIA-48 | BRL-CAD: 03tbrowder2 * r46896 10/brlcad/trunk/doc/docbook/create-xml-catalogs.pl: add more rewrite rules for xsl locations |
| 15:47.55 | CIA-48 | BRL-CAD: 03tbrowder2 * r46897 10/brlcad/trunk/doc/docbook/Makefile.am: add more defs and rules for making a test pdf doc with covers |
| 15:49.21 | brlcad | starseeker: heh, you |
| 15:49.29 | brlcad | you're going to have your work cut out for you! |
| 15:49.33 | CIA-48 | BRL-CAD: 03tbrowder2 * r46898 10/brlcad/trunk/doc/docbook/dummy.xml: add short DB source file for testing pdf covers |
| 15:50.31 | brlcad | tbrowder's putting in quite an elaborate document processing build system -- it'll be interesting to get that converted to a build script or (eek) cmake logic |
| 15:50.32 | CIA-48 | BRL-CAD: 03tbrowder2 * r46899 10/brlcad/trunk/doc/docbook/book-covers-fo-template.xsl: add covers template |
| 15:52.29 | CIA-48 | BRL-CAD: 03tbrowder2 * r46900 10/brlcad/trunk/doc/docbook/brlcad-fo-stylesheet-covers.xsl: add master stylesheeet for DB with covers; location is temporary during initial cover testing |
| 15:56.39 | CIA-48 | BRL-CAD: 03tbrowder2 * r46901 10/brlcad/trunk/doc/docbook/brlcad-gendata.xsl: add a stylesheet with common definitions--temporary location during initial covers testing; final location for all stylesheets will be ./resources/brlcad |
| 16:03.00 | CIA-48 | BRL-CAD: 03tbrowder2 * r46902 10/brlcad/trunk/doc/docbook/ (. create-book-covers.pl create-index.pl validate.pl): add ignored files |
| 16:38.57 | CIA-48 | BRL-CAD: 03brlcad * r46903 10/brlcad/trunk/doc/docbook/ (18 files in 10 dirs): using the application/xml mime puts subversion into binary-diff mode so we don't get to see the diff contents. convert to text/xml instead like our other xsl files, setting the eol-style to native while we're at it. |
| 16:46.20 | CIA-48 | BRL-CAD: 03brlcad * r46904 10/brlcad/trunk/doc/docbook/ (10 files in 4 dirs): make all of our xml files use text/xml as their mime-type |
| 16:50.58 | CIA-48 | BRL-CAD: 03starseeker * r46905 10/brlcad/trunk/src/ (conv/step/CMakeLists.txt other/CMakeLists.txt): Add (commented out, for now) logic to use generated files from fedex_plus instead of static files |
| 17:13.19 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 17:25.33 | CIA-48 | BRL-CAD: 03erikgreenwald * r46906 10/brlcad/trunk/src/libgcv/bottess.c: begin single face splitting |
| 19:05.14 | CIA-48 | BRL-CAD: 03erikgreenwald * r46907 10/brlcad/trunk/src/libgcv/bottess.c: kill some debugging stuff. mark actual vertex in vertex/intersectpt test. |
| 20:35.43 | CIA-48 | BRL-CAD: 03brlcad * r46908 10/brlcad/trunk/include/bu.h: stub in the preliminary interface declaration for bu_file_glob() prior to definition. |
| 20:48.43 | CIA-48 | BRL-CAD: 03bob1961 * r46909 10/brlcad/trunk/ (3 files in 2 dirs): |
| 20:48.43 | CIA-48 | BRL-CAD: Added a member to "struct application" for disabling bot normal reversal in |
| 20:48.43 | CIA-48 | BRL-CAD: librt/primitive/bot so that hitting a bot would yield, among other things, the |
| 20:48.43 | CIA-48 | BRL-CAD: bot's actual normal. With "bot normal reversal" disabled, a ray can be used to |
| 20:48.43 | CIA-48 | BRL-CAD: determine if a bot's normal needs to be flipped. |
| 20:54.39 | CIA-48 | BRL-CAD: 03bob1961 * r46910 10/brlcad/trunk/src/librt/tcl.c: |
| 20:54.39 | CIA-48 | BRL-CAD: Added rt_tcl_rt_set to librt/tcl.c. This adds the ability to get/set the values |
| 20:54.39 | CIA-48 | BRL-CAD: of bot_reverse_normal_disabled, onehit and no_bool. Other variables could be |
| 20:54.39 | CIA-48 | BRL-CAD: exposed here and the onehit and no_bool subcommands could be deprecated. |
| 21:03.25 | CIA-48 | BRL-CAD: 03bob1961 * r46911 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): |
| 21:03.25 | CIA-48 | BRL-CAD: Added bot_flip_check and bot_flip_check_all commands to Archer. bot_flip_check |
| 21:03.25 | CIA-48 | BRL-CAD: takes a logfile and a list of bots to be checked for possible flipping. The log |
| 21:03.25 | CIA-48 | BRL-CAD: file records whether a bot gets skipped (i.e. if not a volume mode bot), flipped |
| 21:03.25 | CIA-48 | BRL-CAD: or not flipped. It also records if the fired ray misses. |
| 21:11.05 | starseeker | starseeker: eh? |
| 21:11.21 | starseeker | brlcad: I'm going to have my work cut out for me? |
| 21:11.46 | starseeker | oh, you mean translating all that |
| 21:11.59 | starseeker | yeah, I'm letting it all settle down before I look at it |
| 21:12.53 | starseeker | not real crazy about all the perl, but figure let him get it set up how he wants and then look at how to achieve the effect |
| 21:25.58 | CIA-48 | BRL-CAD: 03starseeker * r46912 10/brlcad/trunk/src/ (7 files in 7 dirs): Clean up a little fallout from the new include_dirs setup |
| 21:54.23 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 21:58.35 | CIA-48 | BRL-CAD: 03starseeker * r46913 10/brlcad/trunk/src/other/ (CMakeLists.txt step/src/express/CMakeLists.txt): Redo comments a bit in src/other/CMakeLists.txt |
| 22:06.50 | CIA-48 | BRL-CAD: 03starseeker * r46914 10/brlcad/trunk/src/other/step/src/express/CMakeLists.txt: oops |
| 22:09.38 | *** join/#brlcad kunigami_ (~kunigami@201.82.92.180) | |
| 22:13.56 | brlcad | starseeker: given everything it depends on and assumes, it's almost guaranteed to required a unix environment so the best path is probably to just wrap it all in a script and call that if Perl and a posix shell are detected |
| 22:32.07 | CIA-48 | BRL-CAD: 03brlcad * r46915 10/brlcad/trunk/CMakeLists.txt: remove trailing ws |
| 22:41.52 | CIA-48 | BRL-CAD: 03brlcad * r46916 10/brlcad/trunk/Makefile.am: ws |
| 22:58.18 | CIA-48 | BRL-CAD: 03brlcad * r46917 10/brlcad/trunk/ (38 files in 22 dirs): (log message trimmed) |
| 22:58.19 | CIA-48 | BRL-CAD: consistently use 0.0005 for a default distance tolerance and 1e-6 for a default |
| 22:58.19 | CIA-48 | BRL-CAD: perpedicularity tolerance throughout BRL-CAD. over time, a default of 5e-3 and |
| 22:58.19 | CIA-48 | BRL-CAD: 5e-4 have been used for the distance tolerance with the latter used in more |
| 22:58.19 | CIA-48 | BRL-CAD: places; similarly 1e-5 and 1e-6 for perpendicularity. choosing the more |
| 22:58.19 | CIA-48 | BRL-CAD: prevalent and tighter bounds for both which constitute a default nearness |
| 22:58.20 | CIA-48 | BRL-CAD: tolerance of approximately 1/2000ths of 1mm. that is just under the sqrt of |
| 22:59.43 | CIA-48 | BRL-CAD: 03brlcad * r46918 10/brlcad/trunk/src/fb/polar-fb.c: missed one tolerance straggler |
| 23:52.30 | *** join/#brlcad kunigami_ (~kunigami@201.82.92.180) | |
| 01:12.12 | CIA-48 | BRL-CAD: 03tbrowder2 * r46919 10/brlcad/trunk/doc/docbook/ (7 files in 2 dirs): various error corrections to get a working test cover |
| 01:47.31 | starseeker | brlcad: we've got a conflict on Windows between winbase.h(1090) IGNORE and common.h(251) IGNORE macros |
| 01:52.43 | brlcad | starseeker: no problem, we can just undef IGNORE before including windows then redef |
| 02:33.23 | CIA-48 | BRL-CAD: 03starseeker * r46920 10/brlcad/trunk/ (3 files in 3 dirs): Add a couple more includes that slipped through the cracks and showed up on Windows, plus make a stab at squashing the conflicting definition warning between winbase.h(1090) IGNORE and common.h(251) IGNORE macros. |
| 03:12.21 | starseeker | huh, cool: http://clucene.sourceforge.net/ |
| 03:39.46 | CIA-48 | BRL-CAD: 03brlcad * r46921 10/brlcad/trunk/include/common.h: if IGNORE is already defined, say so and take control |
| 03:41.35 | CIA-48 | BRL-CAD: 03brlcad * r46922 10/brlcad/trunk/include/bio.h: don't repeat yourself. stash the IGNORE macro definition and restore it later since windows api defines their own |
| 03:59.35 | brlcad | that is pretty nifty |
| 04:00.04 | brlcad | something the GS could potentially utilize later next year or after |
| 04:08.02 | CIA-48 | BRL-CAD: 03brlcad * r46923 10/brlcad/trunk/include/bio.h: do it proper. only need the IGNORE protection if it's defined (which it _usually_ should be but there is no guarantee). |
| 04:26.01 | CIA-48 | BRL-CAD: 03brlcad * r46924 10/brlcad/trunk/src/conv/g-obj.c: ws style indent comment cleanup |
| 05:09.29 | CIA-48 | BRL-CAD: 03brlcad * r46925 10/brlcad/trunk/include/bn.h: expand macros for initializing and inspecting a bn_tol struct with doxygen comments |
| 05:32.30 | CIA-48 | BRL-CAD: 03brlcad * r46926 10/brlcad/trunk/include/ (CMakeLists.txt Makefile.am tol.h): |
| 05:32.30 | CIA-48 | BRL-CAD: add a new tol.h header to librt in the style of the new header groupings (albeit |
| 05:32.30 | CIA-48 | BRL-CAD: not fully realized until RT_EXPORT is broken out) that declares a new |
| 05:32.30 | CIA-48 | BRL-CAD: rt_tol_default() function for obtaining/initializing a tolerance struct with |
| 05:32.30 | CIA-48 | BRL-CAD: geometry tolerances common to librt geometry processing (namely, 0.0005 dist tol |
| 05:32.31 | CIA-48 | BRL-CAD: and 1e-6 perp tol). |
| 05:34.00 | CIA-48 | BRL-CAD: 03brlcad * r46927 10/brlcad/trunk/src/librt/ (CMakeLists.txt Makefile.am tol.c): |
| 05:34.01 | CIA-48 | BRL-CAD: add the initial implementation of rt_tol_default() used for returning a |
| 05:34.01 | CIA-48 | BRL-CAD: librt-centric tolerance structure useful for geometry processing so we don't |
| 05:34.01 | CIA-48 | BRL-CAD: have the issue of hard-coded tolerance values all over the package that get out |
| 05:34.01 | CIA-48 | BRL-CAD: of sync over time. |
| 06:15.48 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 06:50.26 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 09:39.09 | *** join/#brlcad kunigami_ (~kunigami@201.82.92.180) | |
| 13:22.24 | CIA-48 | BRL-CAD: 03tbrowder2 * r46928 10/brlcad/trunk/doc/docbook/books/en/BRL-CAD_Tutorial_Series-VolumeI.xml: change root element to book--required to get a cover in the pdf file |
| 16:17.44 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 16:56.04 | CIA-48 | BRL-CAD: 03tbrowder2 * r46929 10/brlcad/trunk/doc/docbook/dummy.xml: correct file format for book and cover |
| 17:15.09 | CIA-48 | BRL-CAD: 03bob1961 * r46930 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Updated Archer::bot_flip_check to fire another ray if the first one missed. This time use points from the first triangle to compute the start and target points. |
| 19:12.56 | CIA-48 | BRL-CAD: 03indianlarry * r46931 10/brlcad/trunk/src/adrt/isst_tcltk.c: needed "common.h" for build on windows |
| 19:18.25 | CIA-48 | BRL-CAD: 03erikgreenwald * r46932 10/brlcad/trunk/src/adrt/CMakeLists.txt: Add OpenGL include dir for issttcltk |
| 21:18.22 | brlcad | fop is a bitch to install via ports, ugh |
| 21:23.53 | CIA-48 | BRL-CAD: 03bob1961 * r46933 10/brlcad/trunk/src/mged/mged.c: Supposed to be turning zbuffer back on here. |
| 21:24.13 | brlcad | well for relative values of bitching, of course .. most ports are downright trivial, but java is a royal pita due to all the custom click-through license agreements (no less than 5 so far) |
| 22:18.28 | brlcad | starseeker: like how I just volunteered you there? |
| 22:27.11 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 22:38.50 | *** join/#brlcad kunigami_ (~kunigami@201.82.92.180) | |
| 22:43.40 | *** join/#brlcad dli_ (~dli@dsl-67-55-11-95.acanac.net) | |
| 23:20.45 | *** join/#brlcad Yoshi477 (~jan@d72-39-60-53.home1.cgocable.net) | |
| 23:33.20 | starseeker | brlcad: heh, awesome |
| 23:33.34 | starseeker | figured |
| 23:34.26 | starseeker | yeah, it's unfortunate that fop is java based, but it's also the *only* open source docbook->pdf tool I know of :-/ |
| 23:34.43 | brlcad | no matter, it's all installed now |
| 02:27.26 | starseeker | arrgh, gentoo doesn't have fop 1.0 |
| 05:14.11 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601580.dsl.bell.ca) | |
| 06:23.15 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 08:38.17 | *** join/#brlcad dli__ (~dli@dsl-69-171-140-58.acanac.net) | |
| 10:15.28 | *** join/#brlcad kunigami_ (~kunigami@201.82.92.180) | |
| 11:02.14 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 11:20.24 | CIA-48 | BRL-CAD: 03tbrowder2 * r46934 10/brlcad/trunk/doc/docbook/BRLCAD_DOC.pm: mods to pdf cover elements |
| 11:29.20 | CIA-48 | BRL-CAD: 03tbrowder2 * r46935 10/brlcad/trunk/doc/docbook/DBPATH.pm.in: need an absolute path for DB cover images for fop |
| 11:35.35 | CIA-48 | BRL-CAD: 03tbrowder2 * r46936 10/brlcad/trunk/doc/docbook/resources/brlcad/images/: add new dir for common use images |
| 11:36.16 | CIA-48 | BRL-CAD: 03tbrowder2 * r46937 10/brlcad/trunk/doc/docbook/resources/brlcad/images/brlcad-logo-red.svg: new BRL-CAD logo in svg format |
| 11:38.23 | CIA-48 | BRL-CAD: 03tbrowder2 * r46938 10/brlcad/trunk/configure.ac: add another dir for DB and fop |
| 11:45.12 | CIA-48 | BRL-CAD: 03tbrowder2 * r46939 10/brlcad/trunk/doc/docbook/create-book-covers.pl: mods for a working cover generator |
| 11:53.59 | CIA-48 | BRL-CAD: 03tbrowder2 * r46940 10/brlcad/trunk/doc/docbook/DBPATH.pm.in: eliminate dup end value statement |
| 11:55.45 | CIA-48 | BRL-CAD: 03tbrowder2 * r46941 10/brlcad/trunk/doc/docbook/create-xml-catalogs.pl: make catalog resolver paths relative; name xml catalog in same dir as resolver |
| 11:57.12 | CIA-48 | BRL-CAD: 03tbrowder2 * r46942 10/brlcad/trunk/doc/docbook/book-covers-fo-template.xsl: mods to get a working and decent pdf book cover |
| 12:07.37 | CIA-48 | BRL-CAD: 03tbrowder2 * r46943 10/brlcad/trunk/doc/docbook/resources/offo-hyphenation-source-v2.0/ (66 files in 2 dirs): add offo v2.0 source so licenses are available for reference |
| 12:46.11 | CIA-48 | BRL-CAD: 03tbrowder2 * r46944 10/brlcad/trunk/doc/docbook/README.DB_authors_notes: special notes and aids for DB authors--may want to rename this file HACKING to parallel the HACKING file for thetop-level dir |
| 12:46.52 | CIA-48 | BRL-CAD: 03tbrowder2 * r46945 10/brlcad/trunk/doc/docbook/README: add more on DB processing and supporting files and dirs |
| 14:03.39 | CIA-48 | BRL-CAD: 03tbrowder2 * r46946 10/brlcad/trunk/doc/docbook/make-svg.sh: add svg equation tool |
| 14:08.26 | CIA-48 | BRL-CAD: 03tbrowder2 * r46947 10/brlcad/trunk/doc/docbook/README: add more info on DB processing, tools, and requirements |
| 14:11.04 | starseeker | brlcad: http://www.cmake.org/pipermail/cmake/2011-September/046455.html |
| 14:12.08 | CIA-48 | BRL-CAD: 03tbrowder2 * r46948 10/brlcad/trunk/doc/docbook/README: add a note on MathML to SVG processing |
| 14:18.34 | CIA-48 | BRL-CAD: 03tbrowder2 * r46949 10/brlcad/trunk/doc/docbook/README.DB_authors_notes: clarify that the listitems customization is in the brlcad stylesheets |
| 14:29.02 | CIA-48 | BRL-CAD: 03starseeker * r46950 10/brlcad/trunk/CMakeLists.txt: Figure out what Apache FOP version we've got. |
| 14:45.09 | CIA-48 | BRL-CAD: 03tbrowder2 * r46951 10/brlcad/trunk/doc/docbook/README: add specific recommendation for fop version 1.0 |
| 14:46.13 | CIA-48 | BRL-CAD: 03tbrowder2 * r46952 10/brlcad/trunk/doc/docbook/README: add specific recommendation for fop version >= 1.0 |
| 14:54.09 | CIA-48 | BRL-CAD: 03tbrowder2 * r46953 10/brlcad/trunk/doc/docbook/resources/brlcad/book-covers-fo-template.xsl: move to final location |
| 14:54.36 | CIA-48 | BRL-CAD: 03tbrowder2 * r46954 10/brlcad/trunk/doc/docbook/book-covers-fo-template.xsl: move to final location |
| 14:57.21 | CIA-48 | BRL-CAD: 03tbrowder2 * r46955 10/brlcad/trunk/doc/docbook/ (6 files in 2 dirs): move xsl files to final location; modify prog to use new location |
| 15:13.58 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:16.04 | CIA-48 | BRL-CAD: 03tbrowder2 * r46956 10/brlcad/trunk/doc/docbook/resources/brlcad/images/brlcad-logo-green.svg: add a green logo |
| 15:37.26 | CIA-48 | BRL-CAD: 03tbrowder2 * r46957 10/brlcad/trunk/doc/docbook/resources/brlcad/images/ (brlcad-logo-green.svg brlcad-logo-red.svg): correct color values |
| 15:38.10 | CIA-48 | BRL-CAD: 03tbrowder2 * r46958 10/brlcad/trunk/doc/docbook/resources/brlcad/images/ (brlcad-logo-blue.svg brlcad-logo-limegreen.svg): add new color choices |
| 15:40.56 | CIA-48 | BRL-CAD: 03tbrowder2 * r46959 10/brlcad/trunk/doc/docbook/resources/brlcad/brlcad-fo-stylesheet-covers.xsl: correct for new file location; add provision for auto color changes |
| 16:01.48 | brlcad | starseeker: the fact that it's a symbolic link is beside the point |
| 16:02.04 | brlcad | it could just as easily be a data file or text file named as such |
| 16:06.23 | brlcad | what is it about build system programmers that make them so resistant to admitting fault or limitations of design ... |
| 16:08.28 | brlcad | that macro might as well be called "find_file_by_name" |
| 16:08.50 | brlcad | a glorified call to fnmatch() |
| 16:57.31 | CIA-48 | BRL-CAD: 03brlcad * r46960 10/brlcad/trunk/doc/docbook/Makefile.am: avoid gnu-makeisms by expanding the list manually since we still need to portably build via autotools for a few more releases. cmake should have a better solution. |
| 17:00.26 | CIA-48 | BRL-CAD: 03brlcad * r46961 10/brlcad/trunk/doc/docbook/resources/brlcad/brlcad-xhtml-stylesheet.xsl: seems the base URI path is doc/docbook/resources/brlcad? .. refer to docbook.xsl with a relative path |
| 17:00.40 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 17:04.01 | CIA-48 | BRL-CAD: 03brlcad * r46962 10/brlcad/trunk/doc/docbook/Makefile.am: getting an error about 'make[1]: *** No rule to make target all'. Stop.' .. don't yet know who is supposed to be generating that. |
| 17:05.17 | CIA-48 | BRL-CAD: 03brlcad * r46963 10/brlcad/trunk/doc/docbook/resources/brlcad/brlcad-man-stylesheet.xsl: another absolute reference that made compilation unhappy. refer to xsl with relative path. now completes successfully. |
| 17:09.15 | CIA-48 | BRL-CAD: 03tbrowder2 * r46964 10/brlcad/trunk/doc/docbook/resources/brlcad/images/ (4 files): add logo svg files in brlcad site palette shadow colors |
| 17:26.11 | CIA-48 | BRL-CAD: 03tbrowder2 * r46965 10/brlcad/trunk/doc/docbook/resources/brlcad/book-covers-fo-template.xsl: make cover color a variable input |
| 17:26.59 | CIA-48 | BRL-CAD: 03tbrowder2 * r46966 10/brlcad/trunk/doc/docbook/resources/brlcad/brlcad-fo-stylesheet-covers.xsl: remove incorrect include file |
| 17:27.54 | CIA-48 | BRL-CAD: 03tbrowder2 * r46967 10/brlcad/trunk/doc/docbook/BRLCAD_DOC.pm: make cover color a variable input |
| 17:30.28 | CIA-48 | BRL-CAD: 03tbrowder2 * r46968 10/brlcad/trunk/doc/docbook/create-book-covers.pl: make cover color a variable; use color code to allow for hex color definition |
| 18:06.28 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 18:39.19 | CIA-48 | BRL-CAD: 03tbrowder2 * r46969 10/brlcad/trunk/doc/docbook/Makefile.am: correct final location of stylesheets |
| 18:47.58 | CIA-48 | BRL-CAD: 03tbrowder2 * r46970 10/brlcad/trunk/doc/docbook/Makefile.am: only want first dependency for the commands to operate on |
| 19:09.35 | *** join/#brlcad FAMULUS (~mark@ool-44c47217.dyn.optonline.net) | |
| 19:10.00 | FAMULUS | In BRL CAD, how do I select menu command with my keyboard? |
| 19:10.06 | FAMULUS | on a mac |
| 19:34.56 | *** join/#brlcad FAMULUS (~mark@ool-44c47217.dyn.optonline.net) | |
| 19:45.22 | CIA-48 | BRL-CAD: 03tbrowder2 * r46971 10/brlcad/trunk/doc/docbook/resources/brlcad/ (3 files): updating include references to use the prefix rewrite rules in the catalog |
| 19:46.08 | CIA-48 | BRL-CAD: 03tbrowder2 * r46972 10/brlcad/trunk/doc/docbook/fop.xconf.in: updating some font info |
| 19:46.40 | CIA-48 | BRL-CAD: 03tbrowder2 * r46973 10/brlcad/trunk/doc/docbook/resources/brlcad/: adding some ignores |
| 20:13.20 | CIA-48 | BRL-CAD: 03bob1961 * r46974 10/brlcad/trunk/src/libdm/ (dm-ogl.c dm-wgl.c): Initialize light and zbuffer when creating display manager windows. |
| 20:25.19 | CIA-48 | BRL-CAD: 03erikgreenwald * r46975 10/brlcad/trunk/src/libgcv/bottess.c: Detect vertex intersection cases, Stub logic for splitting. |
| 20:26.08 | CIA-48 | BRL-CAD: 03bob1961 * r46976 10/brlcad/trunk/src/tclscripts/mged/openw.tcl: Set zbuffer after dm creation. |
| 20:35.12 | brlcad | starseeker: http://www.gnu.org/s/hello/manual/autoconf/Libraries.html |
| 20:35.41 | brlcad | the autoconf way does specify a symbol (but that symbol can be "main" if you don't care/know) |
| 20:35.56 | brlcad | tried and true |
| 21:05.17 | CIA-48 | BRL-CAD: 03brlcad * r46977 10/brlcad/trunk/TODO: killall is reporting lookup failures |
| 21:50.25 | *** join/#brlcad kunigami_ (~kunigami@201.82.92.180) | |
| 22:27.46 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 23:33.17 | *** join/#brlcad kunigami_ (~kunigami@201.82.92.180) | |
| 00:50.03 | starseeker | brlcad: yow, there's a lot of perl code for the docbook stuff |
| 00:50.24 | starseeker | do we go with that or did you want it translated into CMake+xml? |
| 00:51.48 | starseeker | wonders how much of this generation of pages can be done using templates and configure_file... |
| 00:54.00 | starseeker | sets up the autotools build to see what is being done... |
| 00:55.01 | starseeker | prefers not to rely on perl if we don't have to... don't think there's anywhere else we need it... |
| 00:57.58 | starseeker | brlcad: http://www.cmake.org/pipermail/cmake/2011-September/046475.html |
| 01:00.10 | starseeker | no dice :-/ |
| 02:22.33 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 03:15.23 | CIA-48 | BRL-CAD: 03tbrowder2 * r46978 10/brlcad/trunk/doc/docbook/create-book-covers.pl: allow for both xml and fo suffixes to be recognized for generation to work |
| 03:16.26 | CIA-48 | BRL-CAD: 03tbrowder2 * r46979 10/brlcad/trunk/doc/docbook/fop.xconf.in: correct font data to cover font substitution warnings |
| 03:18.38 | CIA-48 | BRL-CAD: 03tbrowder2 * r46980 10/brlcad/trunk/doc/docbook/Makefile.am: add targets for testing book covers\nexectute create-book-covers for bot fo and pdf due to files changes with color changes for each volume |
| 04:01.13 | brlcad | starseeker: installing perl on windows wouldn't be an unreasonable requisite if we want to make building the pdfs on windows possible |
| 04:01.21 | brlcad | so it's really about converting the Makefile.am logic into cmake terms |
| 04:02.48 | brlcad | if perl isn't detected, it doesn't try |
| 04:02.52 | brlcad | just like fop |
| 04:06.07 | brlcad | starseeker: as for the find_library reply, he sets it up for you right there at the end... "job is to find library files" |
| 04:36.45 | brlcad | starseeker: sent you what I'd reply, not that you have to use it.. but his response was a particularly heavy stuffed straw-man |
| 04:37.17 | starseeker | was trying to figure out how to continue the discussion without pissing him off |
| 04:37.46 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 04:38.02 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 04:38.05 | brlcad | he's intentionally trolling for some reason (or is just a bit of a jerk) |
| 04:38.38 | brlcad | reminds me of one of the bz devs, hyperbole overload |
| 04:41.24 | brlcad | left to implement tools like 'ls', you'd not actually get a current listing of files because, well, you can't actually detect if the disk drive failed or if the filesystem is corrupted, so it's better if it just returns the listing that was there at boot-up |
| 04:44.05 | *** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 04:52.42 | starseeker | brlcad: he mentioned /usr/lib/x86_64-linux-gnu/libc.so on ubuntu is a linker script - would that be all <128 characters? |
| 04:56.40 | brlcad | starseeker: yep that would be, though that's actually one of the points I'm claiming -- that's not a library, it's a gnu linker script |
| 04:57.18 | ``Erik | <PROTECTED> |
| 04:57.19 | brlcad | basically a gnu-ld-specific symbolic link of sorts |
| 04:58.11 | brlcad | it's not a libtool archive .. they actually gang up and use the same filename/suffix pattern -- ld reads the file and recognizes it as an ld script |
| 04:58.19 | brlcad | f'd up |
| 04:58.29 | ``Erik | that's... very.... linuxy. |
| 04:58.43 | ``Erik | sorry, gnu/linuxy |
| 04:59.41 | brlcad | "special" is the word |
| 04:59.53 | brlcad | needs-a-helmet "special" |
| 05:00.20 | ``Erik | meh, synonymous O:-) |
| 05:00.44 | brlcad | starseeker: that gets back to the original point that the only real way to tell it to try and link it |
| 05:01.17 | brlcad | if you're cross-compiling, you just don't halt/fail/test/whatever .. though presumably I have a cross-compiler and cross-compilation libs somewhere that will work! |
| 05:02.37 | ``Erik | that'd be an interesting experiment... install a cross compiler from /usr/ports/, try to build BRL-CAD, then try to run it in an emulator for that platform O.o |
| 05:06.38 | starseeker | has never tangled with cross-compilation - scary sounding stuff from the early days of bootstrapping computers is where I know the phrase from |
| 05:08.17 | ``Erik | I used to do it on linux to target win32, and have fairly recently done it to generate an arm fbsd tftp/nfsboot |
| 05:09.41 | ``Erik | as far as the compiler, it's no big deal, just CC=/usr/local/bin/gcc-mingw32 make... figuring out how to set all the right config options and flags can expose a lot in an automatic configuration system, though :) |
| 05:20.16 | starseeker | once more unto the breach dear friends... http://www.cmake.org/pipermail/cmake/2011-September/046478.html |
| 05:48.27 | brlcad | thinks the glorified fnmatch() comparison was warranted, but not too shabby |
| 05:48.54 | brlcad | left yourself open to attack in a few places, but the point was in there |
| 06:19.34 | starseeker | is a rather straightforward sort, not too good at this sort of manuvering |
| 06:45.42 | brlcad | not that straighforward .. very wordy reply :) |
| 06:47.27 | brlcad | my tort respones were direct, you're timidly beating around the bush trying to be polite while skirting around your point before getting to it |
| 06:47.38 | brlcad | at least that's my take, it's still good |
| 06:49.30 | brlcad | I just suspect he'll nit pick something minor, hemhaw on some irrelevant detail, and ignore your points (like how he basically ignored your earlier reference to AC_CHECK_LIB) |
| 06:52.42 | kanzure | hi brlcad |
| 06:52.49 | kanzure | thanks for the scl/step update |
| 07:39.13 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 08:08.45 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 08:26.56 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 10:06.54 | *** join/#brlcad kunigami_ (~kunigami@201.82.92.180) | |
| 10:10.56 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 10:14.23 | *** part/#brlcad kunigami_ (~kunigami@201.82.92.180) | |
| 10:44.18 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 11:37.46 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-170-216.wlan.tudelft.nl) | |
| 11:44.59 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 12:19.30 | CIA-48 | BRL-CAD: 03tbrowder2 * r46981 10/brlcad/trunk/doc/docbook/README: added scribus as a program for DB authors for converting eps to svg format |
| 12:22.12 | CIA-48 | BRL-CAD: 03tbrowder2 * r46982 10/brlcad/trunk/doc/docbook/README.DB_authors_notes: add info on pdf graphics and eps conversions |
| 12:29.52 | CIA-48 | BRL-CAD: 03tbrowder2 * r46983 10/brlcad/trunk/doc/docbook/Makefile.am: trimmed some fat; added missing tools to dist list |
| 12:49.20 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-196-228.wlan.tudelft.nl) | |
| 13:36.32 | brlcad | kanzure: no problem |
| 13:41.21 | starseeker | yawns |
| 13:42.46 | brlcad | yawns |
| 13:49.15 | starseeker | http://www.cmake.org/pipermail/cmake/2011-September/046479.html |
| 13:49.23 | starseeker | even better, http://www.cmake.org/pipermail/cmake/2011-September/046481.html |
| 13:52.58 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 14:04.39 | CIA-48 | BRL-CAD: 03d_rossberg * r46984 10/brlcad/trunk/CMakeLists.txt: |
| 14:04.39 | CIA-48 | BRL-CAD: the current setting of compiler flags does not work for the MSVC compiler, it results in a broken build |
| 14:04.39 | CIA-48 | BRL-CAD: (The CMake standard for MSVC is linking with the C-runtime-DLL, which is OK. The ridiculous gcc flags force MSVC to use its own standards: Linking every DLL statically with a separate C-runtime.) |
| 14:05.18 | starseeker | d_rossberg: hmm. I just built with MSVC a day or two ago... |
| 14:05.49 | starseeker | you mean MSVC is mis-interperting a gcc flag? |
| 14:07.10 | d_rossberg | i'm afraid it misinterprets every gcc flag (see the compiler warnings) |
| 14:08.20 | d_rossberg | the gcc flags will only be set for the choosen build type |
| 14:09.25 | d_rossberg | i.e. if you have choosen release for CMake but compiling Debug with your Visual Studio the build could work |
| 14:10.20 | starseeker | winces |
| 14:10.20 | d_rossberg | but otherwise asc2g will crash many time during the build |
| 14:11.13 | starseeker | that business of allowing MSVC and/or XCode to have multiple configs is a real pain |
| 14:11.15 | d_rossberg | btw: i couldn't find a way to build libitcl.dll |
| 14:11.48 | starseeker | you mean it crashes? |
| 14:11.52 | d_rossberg | the CMake defaults are doing a good job for MSVC |
| 14:12.29 | d_rossberg | there are undefined symbols in itcl |
| 14:12.55 | starseeker | brlcad: what's your take - should we let the MSVC defaults ride? |
| 14:13.20 | starseeker | d_rossberg: can you post a build log for itcl? (also, which Visual Studio? I recently built with 10...) |
| 14:23.16 | d_rossberg | do you mean something like this: http://brlcad.org/~rossberg/BuildLog.htm |
| 14:24.35 | d_rossberg | MSVC 2008 (German :) |
| 14:25.28 | starseeker | that looks right... |
| 14:30.22 | d_rossberg | all i did was making a svn checkout and choosing an "aBuild" subdirectory as cmake working directory |
| 14:30.51 | starseeker | what library implements sprintf in MSVC2008? |
| 14:31.20 | starseeker | that looks like we need another MSVC library in the linker line, but I'm not sure which one |
| 14:33.36 | starseeker | this might pertain to one of those linker errors... http://support.microsoft.com/kb/894573 |
| 14:35.15 | d_rossberg | sprintf is part of the c-runtime library |
| 14:35.31 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 14:35.38 | starseeker | what do we feed to the linker list to get the c-runtime? |
| 14:41.31 | starseeker | is there a /GS or /Gs flag in the build somewhere? |
| 14:42.09 | d_rossberg | i think saying /MD or /MDd does it, /NODEFAULTLIB would remove all defaults (in this case one had to set the libraries all by hand) |
| 14:43.53 | starseeker | d_rossberg: go ahead and add what you need - I'll try it on 2010 later |
| 14:53.08 | d_rossberg | 1st: it looks like its a problem with the debug configuration, release is ok (at least at the moment) |
| 14:53.41 | brlcad | starseeker: they're obsessing over symbolic links, but that's still ignoring the elephant in the room to me -- just looking at the file name makes it a glorified fnmatch() wrapper |
| 14:54.34 | d_rossberg | then i could compile and link the debug too by changing the c-runtime to debug-dll in the compiler settings |
| 14:55.01 | d_rossberg | it looks like the is somewhere a /MD instead of /MDd ... |
| 15:03.09 | brlcad | how are gcc flags getting added to the msvc build? a simple compile test should ensure that they're detected as non-functional |
| 15:03.20 | brlcad | if they're not, sounds like the compile test is flawed |
| 15:03.25 | starseeker | hah, cool: http://www.evilmadscientist.com/article.php/visdiff |
| 15:04.24 | starseeker | brlcad: if I understood him correctly, it's when you tell CMake one thing for build configuration and then do the other thing in MSVC |
| 15:04.42 | starseeker | XCode probably has similar issues |
| 15:04.58 | brlcad | how would that result in it thinking that -pipe is a valid flag? |
| 15:05.34 | starseeker | d_rossberg: what were the specific errors you were seeing? (and what compile flags were getting passed in?) |
| 15:05.59 | brlcad | there should have been a -pipe test (which fails), and both debug and release configs would use $PIPE_FLAG or whatever so it'd never get added |
| 15:06.30 | starseeker | I don't know if it was pipe specifically |
| 15:06.39 | brlcad | his error log lists a -pipe |
| 15:07.03 | brlcad | if pipe got through, they all would probably get through |
| 15:07.13 | starseeker | d_rossberg: do you happen to have your CMake log handy? |
| 15:08.52 | starseeker | that's the itcl build, it's probably a lot dumber than our mail BRL-CAD build |
| 15:09.44 | starseeker | main even |
| 15:10.27 | starseeker | did he post a build log for the original gcc compile failure? |
| 15:10.45 | brlcad | not that I saw |
| 15:10.51 | starseeker | that'd be the one we need |
| 15:11.38 | brlcad | or examine the build log on our end with that action, cmake as debug, change to release in studio, compile |
| 15:11.44 | d_rossberg | unknown compile flags are ignored (what you can see in the log) |
| 15:12.07 | starseeker | ignored and the compile succeeds? (crud) |
| 15:13.00 | d_rossberg | the problem arise when you replace the reasonable cmake defaults by garbage |
| 15:13.32 | d_rossberg | then you have the msvc defaults, which are not optimal bor brl-cad |
| 15:13.39 | starseeker | clang has that same issue - it'll cheerfully ignore unknown flags and succeed |
| 15:14.15 | starseeker | the cmake defaults shouldn't be getting replaced by garbage though |
| 15:14.19 | d_rossberg | adding garbage is no problem, replacing the right settings is |
| 15:14.44 | starseeker | if we need to add MSVC specific compiler tests to make sure the right MSVC settings are there, then we should do that in CompilerFlags.cmake |
| 15:16.00 | d_rossberg | btw, i think i found the place to chage in the itcl configuration; there are similar settings in other tcl/tk libraries; need some time to test it out |
| 15:16.15 | starseeker | cool, thanks |
| 17:29.32 | brlcad | yay, search crashed |
| 17:40.16 | CIA-48 | BRL-CAD: 03brlcad * r46985 10/brlcad/trunk/src/librt/search.c: prevent search from crashing if we can't get a directory pointer to a specified path. encountered this with an object erroneously containing slashes in the name. |
| 17:50.23 | CIA-48 | BRL-CAD: 03brlcad * r46986 10/brlcad/trunk/src/librt/ (db_anim.c db_tree.c prep.c tcl.c tree.c wdb.c): check other callers of DB_FULL_PATH_CUR_DIR() to make sure we don't try to dereference a NULL pointer. |
| 17:56.45 | CIA-48 | BRL-CAD: 03brlcad * r46987 10/brlcad/trunk/src/conv/3dm/3dm-g.cpp: don't use the file path as the toplevel object name. use its basename instead since the slashes cause hell. |
| 18:10.13 | CIA-48 | BRL-CAD: 03tbrowder2 * r46988 10/brlcad/trunk/doc/docbook/README: add info on the saxon-he xslt 2.0 processor and news of the recent release of the DB xslt 2.0 stylesheets |
| 18:49.36 | CIA-48 | BRL-CAD: 03tbrowder2 * r46989 10/brlcad/trunk/doc/docbook/Makefile.am: current process for DB book covers does not allow parallel make processes so using special .NOTPARALLEL target; also requires having book pdf generation in one recipe from xml to fo to pdf |
| 18:50.48 | CIA-48 | BRL-CAD: 03tbrowder2 * r46990 10/brlcad/trunk/doc/docbook/README: reword; add release date of new DB stylesheets for XSLT 2.0 |
| 20:23.56 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 20:59.02 | CIA-48 | BRL-CAD: 03starseeker * r46991 10/brlcad/trunk/src/librt/comb/comb.c: |
| 20:59.02 | CIA-48 | BRL-CAD: Gah. Older versions of BRL-CAD are hard-coded to look for oshader in the |
| 20:59.02 | CIA-48 | BRL-CAD: attributes when importing combs. This makes the particular label oshader an |
| 20:59.02 | CIA-48 | BRL-CAD: actual part of the .g file format itself, and NOT writing it out was breaking |
| 20:59.02 | CIA-48 | BRL-CAD: import of shaders when a .g file is created in a new version of BRL-CAD and |
| 20:59.03 | CIA-48 | BRL-CAD: subsequently opened in an older version. Need to check what other hard-coded |
| 20:59.04 | CIA-48 | BRL-CAD: assumptions got accidently messed with. |
| 22:17.08 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 22:26.44 | CIA-48 | BRL-CAD: 03bob1961 * r46992 10/brlcad/trunk/src/tclscripts/archer/images/component_select.png: Update component_select image. |
| 01:49.44 | *** join/#brlcad DarkCalff (DC@173.231.40.98) | |
| 04:12.03 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 04:12.03 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 04:12.03 | *** join/#brlcad CIA-48 (~CIA@cia.atheme.org) | |
| 04:12.03 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 04:12.03 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 04:12.03 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 04:12.03 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 04:12.03 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 04:12.03 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 04:45.49 | CIA-48 | BRL-CAD: 03brlcad * r46993 10/brlcad/trunk/doc/docbook/books/en/BRL-CAD_Tutorial_Series-VolumeIV.xml: |
| 04:45.49 | CIA-48 | BRL-CAD: looks like this has been 'wrong' since the original. add the requisite dashes |
| 04:45.49 | CIA-48 | BRL-CAD: to all of the various -whatever command-line options so users aren't trying to |
| 04:45.49 | CIA-48 | BRL-CAD: type things like 'g-dxf o file.dxf file.g object'. that detail was picked up |
| 04:45.49 | CIA-48 | BRL-CAD: and reported on the help forum recently by kerryhall. |
| 06:17.02 | *** join/#brlcad DarkCalff (DC@173.231.40.98) | |
| 07:13.11 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 07:35.17 | CIA-48 | BRL-CAD: 03d_rossberg * r46994 10/brlcad/trunk/src/other/ (6 files in 6 dirs): (log message trimmed) |
| 07:35.17 | CIA-48 | BRL-CAD: removed release build-type specific MSVC compiler option |
| 07:35.17 | CIA-48 | BRL-CAD: CMake generates per default many configurations for MSVC, e.g. |
| 07:35.17 | CIA-48 | BRL-CAD: "Debug;Release;MinSizeRel;RelWithDebInfo". However, the /MD option (use |
| 07:35.17 | CIA-48 | BRL-CAD: muti-thread DLL C-runtime) is valid for release configurations only. The debug |
| 07:35.17 | CIA-48 | BRL-CAD: needs the /MDd option (muti-thread debug DLL C-runtime, for example. Using the |
| 07:35.18 | CIA-48 | BRL-CAD: wrong C-runtime may lead to unresolved symbol errors during linking. |
| 08:16.14 | *** join/#brlcad merzo (~merzo@171-13-133-95.pool.ukrtel.net) | |
| 08:40.28 | *** join/#brlcad hackrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 08:40.28 | *** join/#brlcad merzo (~merzo@171-13-133-95.pool.ukrtel.net) | |
| 08:40.28 | *** join/#brlcad DarkCalff (DC@173.231.40.98) | |
| 08:40.28 | *** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 08:40.28 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 08:40.28 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 08:40.28 | *** join/#brlcad CIA-48 (~CIA@cia.atheme.org) | |
| 08:40.28 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 08:40.28 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 08:40.28 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 08:40.28 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 08:40.28 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 08:40.28 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 08:40.47 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 08:40.47 | *** join/#brlcad b0ef (~b0ef@78.58.34.95.customer.cdi.no) | |
| 08:41.12 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 08:41.12 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 08:41.12 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 09:21.13 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 11:10.45 | *** join/#brlcad merzo (~merzo@171-13-133-95.pool.ukrtel.net) | |
| 11:49.02 | CIA-48 | BRL-CAD: 03bob1961 * r46995 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Added code to call rt_gettrees and prep etc. only when the display list changes. |
| 11:53.06 | CIA-48 | BRL-CAD: 03bob1961 * r46996 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Got rid of some dead code (i.e. mouse_ray). Removed everything related to COMP_ERASE_MODE. Added a component pick mode and associated menu for using the component pick button for many different purposes. |
| 15:43.48 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 15:43.48 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 16:00.27 | CIA-48 | BRL-CAD: 03tbrowder2 * r46999 10/brlcad/trunk/doc/docbook/Makefile.am: remove unused dependencies in suffix rules |
| 18:00.15 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 19:11.22 | CIA-48 | BRL-CAD: 03bob1961 * r47000 10/brlcad/trunk/src/libged/bot_split.c: Update libged/bot_split.c to return a list of sublists where each sublist contains the original bot and a subsublist containing the new bots created by the split. |
| 19:17.54 | CIA-48 | BRL-CAD: 03bob1961 * r47001 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: |
| 19:17.54 | CIA-48 | BRL-CAD: Comparing mRayCurrWho with mRayLastWho is not adequate for determining whether |
| 19:17.54 | CIA-48 | BRL-CAD: or not to create a ray object or use the old one. The current and previous who |
| 19:17.54 | CIA-48 | BRL-CAD: lists may match and yet contain a different hierarcy (i.e. things could have |
| 19:17.54 | CIA-48 | BRL-CAD: changed out from under it). More needs to be done here. |
| 19:22.15 | CIA-48 | BRL-CAD: 03bob1961 * r47002 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): |
| 19:22.15 | CIA-48 | BRL-CAD: Cleaned up a bit of crud in Archer.tcl. Also added code to enhance bot_split |
| 19:22.15 | CIA-48 | BRL-CAD: when splitting via component pick mode. The old bot (i.e. the one getting split) |
| 19:22.15 | CIA-48 | BRL-CAD: becomes a group containing the newly created bots resulting from the split. |
| 20:28.13 | *** join/#brlcad merzo (~merzo@152-234-132-95.pool.ukrtel.net) | |
| 20:38.10 | CIA-48 | BRL-CAD: 03tbrowder2 * r47003 10/brlcad/trunk/doc/docbook/Makefile.am: added a test for the xml catalog, and regeneration if necessary, to all suffix rules that use xsltproc; added xml catalog as a dependency to other rules using xsltproc |
| 21:05.27 | CIA-48 | BRL-CAD: 03tbrowder2 * r47004 10/brlcad/trunk/doc/docbook/books/en/images/ (11 files): add missing Vol IV images |
| 21:58.21 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 23:16.14 | CIA-48 | BRL-CAD: 03n_reed * r47005 10/brlcad/trunk/doc/ (4 files): added notes on converting bison/flex to re2c/lemon |
| 23:48.22 | CIA-48 | BRL-CAD: 03n_reed * r47006 10/brlcad/trunk/src/other/step/src/express/ (Makefile.am expparse_new.y): added initial bison to lemon syntax conversion of expparse.y |
| 23:50.59 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 23:57.20 | CIA-48 | BRL-CAD: 03abhi2011 * r47007 10/brlcad/trunk/src/libged/simulate/simulate.c: |
| 23:57.20 | CIA-48 | BRL-CAD: Added code to display bounding boxes, recalculating the BB every iteration is |
| 23:57.20 | CIA-48 | BRL-CAD: causing boxes that have moved to stay bent in their new position as each |
| 23:57.20 | CIA-48 | BRL-CAD: bounding box is inserted as a new cube in the next iteration. This problem |
| 23:57.20 | CIA-48 | BRL-CAD: should disappear when contact points are calculated correctly |
| 23:59.21 | CIA-48 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3171 10/wiki/User:Abhijit: /* Log */ |
| 23:59.50 | CIA-48 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3172 10/wiki/User:Abhijit: /* Log */ |
| 03:50.58 | *** join/#brlcad nsd (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 06:07.26 | *** join/#brlcad merzo (~merzo@152-234-132-95.pool.ukrtel.net) | |
| 06:56.34 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 08:27.18 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 10:24.56 | abhi2011 | Getting some weird cases like this now : http://postimage.org/image/lkepvy2s/full/ |
| 10:25.08 | abhi2011 | its due to recalculation of the bb each iteration |
| 10:28.03 | abhi2011 | but should be gone when I start calculating the points using rt |
| 10:28.26 | abhi2011 | the challenge now is to generate contact points between colliding objects based on the same criteria that bullet does |
| 10:36.20 | abhi2011 | apparently it generates points exactly along edges or to maximize the area covered by them |
| 11:40.23 | CIA-48 | BRL-CAD: 03abhi2011 * r47008 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simphysics.cpp simulate.c): Added code to check the collision points during collision processing |
| 13:20.45 | CIA-48 | BRL-CAD: 03abhi2011 * r47009 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simulate.c simulate.h): Added contact manifold related members to the sim_params struct to communicate them back to libged and display them |
| 13:53.30 | brlcad | abhi2011: looking great! |
| 13:54.00 | brlcad | I expected that the bounding box recalc would cause "wrong" collision detection, but it's right ;) |
| 13:54.42 | brlcad | so bullet can basically do preliminary intersection calculations applying velocity and rotation adjustments on objects that aren't touching without problem |
| 13:55.00 | ``Erik | bullet does 'sweep' cd, iirc |
| 13:55.14 | brlcad | until two bounding boxes intersect, at which point rays have to be fired to determine whether they "actually" intersect yet (and where those points are) |
| 13:58.08 | abhi2011 | brlcad: yes, well bullet also calculates the same bounding box as we do at the start of each iteration, so the results should be ok |
| 14:00.45 | abhi2011 | yes, so after every iteration I am going to fire a bunch of rays and report upto 4 points for every case where objects touch |
| 14:01.01 | abhi2011 | these have to have the maximum possible volume |
| 14:01.17 | abhi2011 | which should be easy to get, just get the points with maximum x,y |
| 14:01.24 | abhi2011 | and minimum |
| 14:04.55 | abhi2011 | so where can i find some code to help me draw arrows in mged |
| 14:05.32 | abhi2011 | i need to draw the contact normals to check if they are being calculated correctly, then reproduce the same through rt |
| 14:06.07 | abhi2011 | the normals have to point correctly so that forces are apllied in the right direction |
| 19:43.47 | abhi2011 | thats strange , I am trying to setup a linked list of manifold points, but I get an error after the function that allocates memory for each node has completed |
| 19:44.06 | abhi2011 | #0 0x00007fffe2e6a6eb in malloc_consolidate () from /lib64/libc.so.6 |
| 19:44.08 | abhi2011 | #1 0x00007fffe2e6be14 in _int_malloc () from /lib64/libc.so.6 |
| 19:44.09 | abhi2011 | #2 0x00007fffe2e6ed99 in malloc () from /lib64/libc.so.6 |
| 19:47.25 | CIA-48 | BRL-CAD: 03abhi2011 * r47010 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simulate.c simulate.h): Trying to pass contact manifolds via a linked list back to libged |
| 20:13.56 | abhi2011 | are there any issues with bu_malloc() in c++ |
| 20:27.29 | *** join/#brlcad merzo (~merzo@177-241-132-95.pool.ukrtel.net) | |
| 20:48.54 | CIA-48 | BRL-CAD: 03abhi2011 * r47011 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simulate.c): Fixed some memory bugs |
| 20:49.00 | abhi2011 | ah shoot, it was a bug in my code...casting aspersion on bu_malloc() unnecessarily :P |
| 20:54.45 | abhi2011 | ah frack!!!....had the arguments for VMOVE() reversed, was therefore pushing weird data into the bullet simulation instead of getting points out and got some extremely strange results.....get a grip abhi !!! |
| 20:55.23 | CIA-48 | BRL-CAD: 03abhi2011 * r47012 10/brlcad/trunk/src/libged/simulate/simcollisionalgo.cpp: fixed order of arguments in the VMOVE() which retrieve the collision points |
| 21:04.12 | CIA-48 | BRL-CAD: 03abhi2011 * r47013 10/brlcad/trunk/src/libged/simulate/simulate.c: More bug fixes, forgot to uncomment the memory cleanup routine |
| 23:37.54 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 09:08.56 | CIA-48 | BRL-CAD: 03abhi2011 * r47014 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c): |
| 09:08.56 | CIA-48 | BRL-CAD: checked to see if some subtle positioning issues could be solved by not |
| 09:08.56 | CIA-48 | BRL-CAD: calculating the BB each iteration, but that created large differences between |
| 09:08.56 | CIA-48 | BRL-CAD: the correct and rendered position, so sticking with the recalculation of BB each |
| 09:08.56 | CIA-48 | BRL-CAD: iteration approach and focusing on adding rt |
| 09:14.39 | abhi2011 | I was wondering if I can add a fix to the primitive editor in mged to take the in focus object by default and show its attributes, instead of having to type in the name each time |
| 10:36.18 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 11:06.00 | abhi2011 | hmm there seems to be no options for an overlap function in struct application_bundle |
| 11:10.53 | abhi2011 | hmm I ll just shoot the rays one by one at the moment using the single ray shooting functions, translating their position a bit across and up/down to shoot a grid |
| 11:23.54 | abhi2011 | hmm so to get the exact bounds of the overlap I ll have to shoot at least a 100 rays in each of the x,y, z direction |
| 11:23.59 | abhi2011 | probably more |
| 11:24.06 | abhi2011 | if the scene is large |
| 11:24.58 | abhi2011 | I ll probably get the bounding box of the scene and shoot rays at 0.1 mm intervals in each of the 3 directions in a 3d grid |
| 13:19.22 | ``Erik | that'd be an awful lot of rays... the "marching cubes" tesselator does that kinda thing and can take gobs of cpu time on even simple stuff |
| 13:20.22 | ``Erik | um, try "g-stl -8 -a 10 /path/to/db/m35.g component" for an idea, -8 uses marching cubes and -a is grid spacing in mm |
| 13:21.29 | ``Erik | (and it only shoots one direction until intersections are found) |
| 13:23.02 | ``Erik | conversly, raytrace the three views at -s100000 or so, which'd ignore the book keeping and matching parts *shrug* |
| 14:34.11 | abhi2011 | umm ok, I actually need to use librt functions to do this, so I cant do it in the command line |
| 14:35.15 | abhi2011 | if 100 is too high will probably have to settle for smaller scenes as of now with max about 20 rays in each direction |
| 14:39.19 | ``Erik | just noting ways to see the amount of computation necessary, not saying how to do your certain task :) |
| 14:44.44 | abhi2011 | :) |
| 14:55.37 | abhi2011 | hmm I need to undo a affine transformation and I have the matrix that did the transformation |
| 14:55.42 | abhi2011 | so I need to invert the matrix |
| 14:55.56 | abhi2011 | no direct macro for that I guess |
| 14:56.01 | abhi2011 | in vmath.h |
| 15:47.08 | abhi2011 | hmm ok just transposing the upper left 3 by 3 matrix and inverting the translation vector seems to work for inverting an affine transf. |
| 16:05.15 | abhi2011 | phew!...solved a particularly annoying positioning issue : http://postimage.org/image/113v0wsmc/full/ |
| 16:06.17 | abhi2011 | since bullet returns world transformations, it's important to undo the object transformation in mged, before applying rt_matrix_transform() |
| 16:06.35 | abhi2011 | I was inverting the translation from the previous iteration |
| 16:06.39 | abhi2011 | but not the rotation |
| 16:07.02 | abhi2011 | leading to subtle differences, like objects outside their BB over large iterations |
| 16:07.59 | CIA-48 | BRL-CAD: 03abhi2011 * r47015 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simulate.c simulate.h): Corrected positioning code and removed BB calculation in every iteration |
| 16:09.07 | abhi2011 | Also another change is that I do not calculate the BB every iteration, just at the first iteration, to give me something(a cuboid) to create as a collision shape in the bullet world |
| 16:11.37 | abhi2011 | after that bullet manages the aabb quiet well and its best not to recalculate the AABB and insert larger cubes into the physics world when the simulation has begun |
| 16:12.19 | abhi2011 | that tends to lock the objects into their rotated position leading to no manifolds being generated etc.....well all set to shoot rays now |
| 16:17.01 | CIA-48 | BRL-CAD: 03abhi2011 * r47016 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simulate.c): Corrected some // comments in C code to prevent warnings |
| 17:27.32 | CIA-48 | BRL-CAD: 03tbrowder2 * r47017 10/brlcad/trunk/doc/docbook/resources/brlcad/book-covers-fo-template.xsl: mod to allow unique colors file per each en book |
| 17:28.16 | CIA-48 | BRL-CAD: 03tbrowder2 * r47018 10/brlcad/trunk/doc/docbook/resources/brlcad/brlcad-fo-stylesheet-covers.xsl: remove old multi-book file not usable for parallel make |
| 17:29.18 | CIA-48 | BRL-CAD: 03tbrowder2 * r47019 10/brlcad/trunk/doc/docbook/resources/brlcad/ (4 files): add unique entry stylesheet per en book |
| 17:30.40 | CIA-48 | BRL-CAD: 03tbrowder2 * r47020 10/brlcad/trunk/doc/docbook/BRLCAD_DOC.pm: mods for generating and inserting unique color file per en book |
| 17:32.28 | CIA-48 | BRL-CAD: 03tbrowder2 * r47021 10/brlcad/trunk/doc/docbook/create-book-covers.pl: mods for generating and using unique cover and color file per en book |
| 17:34.09 | CIA-48 | BRL-CAD: 03tbrowder2 * r47022 10/brlcad/trunk/doc/docbook/Makefile.am: mods to allow en book pdf generation with no parallel make restrictions; some convenience definition macros used |
| 18:28.20 | abhi2011 | hmm trying to find a simple way to draw a line for the rays, like nirt does |
| 18:28.44 | abhi2011 | draw.c seems to do it by inventing a solid....a bit confusing what its doing though |
| 18:29.03 | abhi2011 | _ged_invent_solid() in draw.c |
| 20:26.36 | *** join/#brlcad merzo (~merzo@237-14-132-95.pool.ukrtel.net) | |
| 22:23.42 | *** join/#brlcad b0ef (~b0ef@78.58.34.95.customer.cdi.no) | |
| 22:23.42 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 22:23.42 | *** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 23:55.32 | CIA-48 | BRL-CAD: 03abhi2011 * r47023 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simphysics.cpp simulate.c simulate.h): Added manifold drawing code |
| 07:45.06 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 08:48.46 | *** join/#brlcad abhi2011 (~chatzilla@x033197.its-s.tudelft.nl) | |
| 10:17.35 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-186-018.wlan.tudelft.nl) | |
| 11:05.31 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-184-236.wlan.tudelft.nl) | |
| 13:04.44 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 13:27.55 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 13:38.23 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 13:58.16 | CIA-48 | BRL-CAD: 03tbrowder2 * r47024 10/brlcad/trunk/doc/docbook/README.DB_authors_notes: add figure template and explanation for better control of DB images |
| 14:14.29 | CIA-48 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3173 10/wiki/User:Abhijit: /* Log */ |
| 14:20.20 | CIA-48 | BRL-CAD: 03bob1961 * r47025 10/brlcad/trunk/src/librt/primitives/bot/bot.c: Modified rt_bot_split_func() to look for shared edges instead of a shared point. |
| 14:24.06 | *** join/#brlcad n_reed (~nicholas@c-68-55-142-136.hsd1.md.comcast.net) | |
| 15:03.58 | CIA-48 | BRL-CAD: 03tbrowder2 * r47026 10/brlcad/trunk/doc/docbook/README.DB_authors_notes: corrected role settings |
| 15:35.55 | CIA-48 | BRL-CAD: 03tbrowder2 * r47027 10/brlcad/trunk/doc/docbook/README.DB_authors_notes: reword section on image control, add DB references |
| 15:59.35 | CIA-48 | BRL-CAD: 03n_reed * r47028 10/brlcad/trunk/src/other/step/src/express/expparse_new.y: indent/ws |
| 16:43.10 | CIA-48 | BRL-CAD: 03tbrowder2 * r47029 10/brlcad/trunk/doc/docbook/css/ (. brlcad.css): add css stylesheet for BRL-CAD html docs |
| 16:45.04 | CIA-48 | BRL-CAD: 03tbrowder2 * r47030 10/brlcad/trunk/doc/docbook/Makefile.am: add suffix rule dependencies portably; remove recipe statements no longer needed; add helpful comments |
| 16:46.00 | CIA-48 | BRL-CAD: 03tbrowder2 * r47031 10/brlcad/trunk/doc/docbook/lessons/en/mged01_creating_primitive_shapes.xml: changes to improve appearance of first figure in html and pdf |
| 16:46.43 | CIA-48 | BRL-CAD: 03tbrowder2 * r47032 10/brlcad/trunk/doc/docbook/resources/brlcad/brlcad-xhtml-stylesheet.xsl: add reference to new BRL-CAD css stylesheet for html |
| 17:04.05 | *** join/#brlcad abhi2011 (~chatzilla@x033197.its-s.tudelft.nl) | |
| 18:23.25 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 19:01.51 | CIA-48 | BRL-CAD: 03tbrowder2 * r47033 10/brlcad/trunk/doc/docbook/Makefile.am: ensure doc/docbook/css dir and files are installed |
| 19:45.37 | CIA-48 | BRL-CAD: 03brlcad * r47034 10/brlcad/trunk/src/libged/simulate/simulate.c: use vls strings instead of a fixed buffer. strcat for efficiency. may want to consider bn_mat_print*() functions instead of rolling your own like this. remove c++-style comment. |
| 19:47.12 | CIA-48 | BRL-CAD: 03brlcad * r47035 10/brlcad/trunk/src/libged/simulate/simulate.c: ws indent style cleanup. should be following HACKING. |
| 19:53.41 | CIA-48 | BRL-CAD: 03bob1961 * r47036 10/brlcad/trunk/src/libged/bot_split.c: Modified libged/bot_split to reset make_name's counter before creating new bots. |
| 20:08.14 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 20:12.33 | CIA-48 | BRL-CAD: 03brlcad * r47037 10/brlcad/trunk/src/libged/simulate/ (5 files): more mass ws indent style comment cleanup. very hard to follow when even the file itself is so self-inconsistent. update copyright year to 2011 as year of inception. |
| 20:27.33 | *** join/#brlcad merzo (~merzo@40-197-132-95.pool.ukrtel.net) | |
| 21:16.14 | brlcad | trudges through commits |
| 21:56.51 | *** join/#brlcad DarkCalff (DC@2002:ade7:2862::ade7:2862) | |
| 22:09.52 | *** join/#brlcad DarkCalfz (DC@173.231.40.98) | |
| 22:13.30 | *** join/#brlcad DarkCalff (DC@2002:ade7:2862::ade7:2862) | |
| 23:17.52 | *** join/#brlcad DarkCalfz (DC@173.231.40.98) | |
| 23:25.21 | CIA-48 | BRL-CAD: 03n_reed * r47038 10/brlcad/trunk/src/other/step/src/express/expparse_new.y: making choice for ambigous reduction explicit to suppress conflict error from lemon |
| 23:33.00 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 23:58.12 | brlcad | abhi2011: several :) |
| 23:59.47 | brlcad | abhi2011: if you run the sh/ws.sh and sh/indent.sh scripts on your files from time to time, that should help keep them in order |
| 00:01.58 | brlcad | basically should always be clean, even if temporary code or works in progress -- not a huge deal but it becomes more and more important as code tends to hang around much longer than the original author and becomes paramount as a codebase grows and ages |
| 00:03.20 | brlcad | it's a "clean house all the time" not just when you have guests (because it's a huge hotel and there are always guests) |
| 00:09.15 | brlcad | nice, tessellation of 5th level sphflake is still going (4+ days) |
| 00:09.27 | brlcad | the 6th level might be impractical.. :) |
| 00:15.03 | starseeker | if it's exponential... how long did the 4th level take? |
| 00:36.26 | CIA-48 | BRL-CAD: 03n_reed * r47039 10/brlcad/trunk/ (2 files in 2 dirs): seems lemon requires real type name in type declaration |
| 01:02.07 | *** join/#brlcad _pseudonym (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net) | |
| 01:02.31 | *** part/#brlcad _pseudonym (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net) | |
| 01:03.11 | *** join/#brlcad pacman87 (~Timothy@adsl-208-191-158-89.dsl.hstntx.swbell.net) | |
| 01:13.31 | *** join/#brlcad pacman87 (~Timothy@adsl-208-191-158-89.dsl.hstntx.swbell.net) | |
| 01:13.31 | *** join/#brlcad DarkCalfz (DC@173.231.40.98) | |
| 01:13.31 | *** join/#brlcad merzo (~merzo@40-197-132-95.pool.ukrtel.net) | |
| 01:13.31 | *** join/#brlcad n_reed (~nicholas@c-68-55-142-136.hsd1.md.comcast.net) | |
| 01:13.31 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 01:13.31 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 01:13.31 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 01:13.31 | *** join/#brlcad CIA-48 (~CIA@cia.atheme.org) | |
| 01:13.31 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 01:13.31 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 01:13.31 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 01:13.31 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 01:14.18 | *** part/#brlcad n_reed (~nicholas@c-68-55-142-136.hsd1.md.comcast.net) | |
| 01:50.14 | starseeker | glowers at all these perl routines generating xml pages... I'm kinda wondering if this shouldn't be some .xml.in files |
| 01:50.23 | starseeker | feels like overkill |
| 01:54.36 | *** join/#brlcad pacman87 (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net) | |
| 02:41.08 | brlcad | starseeker: dunno, few hours maybe or a half a day or something |
| 02:41.52 | brlcad | undoubtedly overkill but if it works, it's definitely great progress .. can't wait to see everything getting regenerated nightly |
| 02:42.33 | brlcad | so the build worked for you? I'm seeing the previous error still but haven't done a clean rebuild to see if it's some other issue |
| 02:42.37 | brlcad | doc build |
| 02:45.06 | starseeker | had to manually run the perl script to create that catalog file, then change the APACHEFOP invocation |
| 02:45.19 | starseeker | he hardcoded the fop path |
| 02:46.46 | starseeker | my sense is we can do most of what he's doing with .in files, and the little bit that can't be (e.g. pulling subversion revision number) can be handled without perl |
| 02:46.54 | starseeker | sounds like he may agree |
| 02:49.59 | starseeker | I'll poke at it more tomorrow - need to run the wife in to work, she's got car trouble |
| 02:50.40 | starseeker | since I have to go exactly the wrong way in the morning anyway, might as well come back here and do fop stuff :-) |
| 02:54.45 | starseeker | here's what got generated for volume 1: http://bzflag.bz/~starseeker/BRL-CAD_Tutorial_Series-VolumeI.pdf |
| 02:57.31 | brlcad | the svn revision number doesn't really belong -- it should be using the include/conf files with good ol' revision numbers or a date stamp ala 20110412 |
| 02:58.19 | starseeker | even easier then |
| 02:59.24 | starseeker | looks like at least one extra title page, and probably we need some way to tell it not to do things like figure lists when n=1... |
| 02:59.50 | starseeker | 'course, "volume 1" isn't properly a book at all... |
| 02:59.53 | starseeker | not now, anyway |
| 05:46.42 | starseeker | brlcad: http://www.cmake.org/pipermail/cmake/2011-October/046553.html |
| 05:46.58 | starseeker | http://www.cmake.org/pipermail/cmake/2011-October/046554.html |
| 06:12.54 | *** join/#brlcad pacman87 (~Timothy@adsl-208-191-158-89.dsl.hstntx.swbell.net) | |
| 06:28.14 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 06:45.47 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:09.27 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 08:05.12 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 08:10.38 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 10:15.47 | *** join/#brlcad mattS_ (792cfb6c@gateway/web/freenode/ip.121.44.251.108) | |
| 10:16.26 | mattS_ | Hi! Is anyone around here? |
| 10:17.42 | pacman87 | ~ask |
| 10:17.43 | ibot | Questions in the channel should be specific, informative, complete, concise, and on-topic. Don't ask if you can ask a question first. Don't ask if a person is there; just ask what you intended to ask them. Better questions more frequently yield better answers. We are all here voluntarily or against our will. |
| 10:18.34 | mattS_ | Hm, the bot is telling me to ask better questions... |
| 10:19.18 | mattS_ | OK, I am interested in getting the sweep / revolve feature working, and may have the time to do it these days. |
| 10:19.35 | mattS_ | Not so sure about the programming skills, but that's to be determined. |
| 10:19.57 | pacman87 | Ah, I was the one who suggested you come here |
| 10:20.07 | mattS_ | Indeed. |
| 10:20.31 | mattS_ | So, where should I look? |
| 10:21.15 | pacman87 | From what I remember, the revolve uses a "sketch" as its base, and only straight line segments are supported for the revolve |
| 10:21.29 | pacman87 | do you have the code checked out? |
| 10:21.37 | pacman87 | ~brlsvn |
| 10:21.37 | ibot | try ~cadsvn instead |
| 10:21.42 | pacman87 | ~cadsvn |
| 10:21.42 | ibot | To obtain BRL-CAD from Subversion: svn checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk brlcad |
| 10:22.10 | mattS_ | ack. no svn client on this particular computer... |
| 10:22.16 | pacman87 | what OS? |
| 10:22.20 | mattS_ | OK, lemme put one on. |
| 10:22.23 | mattS_ | OSX. |
| 10:22.24 | mattS_ | yuck |
| 10:23.08 | pacman87 | try https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/src/librt/primitives/ |
| 10:23.53 | mattS_ | That's rather a lot for a browser based approach. |
| 10:24.00 | mattS_ | lemme find an svn client. |
| 10:24.16 | pacman87 | specifically, https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/src/librt/primitives/revolve/ |
| 10:24.28 | pacman87 | revolve.c, revolve.h, and revolve_brep.cpp |
| 10:25.46 | mattS_ | kk |
| 10:25.56 | mattS_ | u+p for svn checkout? |
| 10:26.31 | pacman87 | try blank |
| 10:27.29 | pacman87 | if not, try your sourceforge user/pass |
| 10:28.09 | mattS_ | blank it is. |
| 10:28.11 | mattS_ | got it. |
| 10:28.25 | pacman87 | yeah, you should only need user/pass for commit access |
| 10:28.38 | mattS_ | Makes sense. |
| 10:30.27 | mattS_ | so in a sentence or two, how far did you get with this project? |
| 10:33.29 | pacman87 | I think it should work for sketches with only straight-line segments |
| 10:33.58 | mattS_ | Great! |
| 10:34.33 | pacman87 | since straight line + revolve axis = cone/cylinder/plane |
| 10:34.41 | pacman87 | so the intersection calculation wasn't too hard |
| 10:35.35 | pacman87 | the next step would probably be to look up what other segment types are supported by the sketch primitive, and start adding those |
| 10:35.51 | mattS_ | Indeed. Ah yes, I recall now that you were taking a different approach to this than what I had first thought of... |
| 10:36.13 | pacman87 | probably circular arcs would be easiest, since that's a toroid |
| 10:36.21 | mattS_ | Any chance you have a document somewhere outlining your approach? |
| 10:36.28 | pacman87 | http://brlcad.org/wiki/Revolve_Primitive |
| 10:36.49 | mattS_ | Circular arcs would be next logical step, yes. |
| 10:38.24 | mattS_ | OK, I need some sleep. I will have a look + think about this tomorrow. |
| 10:38.32 | mattS_ | Thanks for your help! |
| 10:38.46 | pacman87 | from https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/src/librt/primitives/sketch/sketch.c , it looks like the sketch can have line segments, circular arcs, nurb, and bezier curves |
| 10:39.03 | pacman87 | re: sleep, me too |
| 10:40.03 | *** part/#brlcad mattS_ (792cfb6c@gateway/web/freenode/ip.121.44.251.108) | |
| 10:44.39 | pacman87 | brlcad: looks like the revolve primitive may be getting some work soon (see above) |
| 10:59.27 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 12:56.52 | CIA-48 | BRL-CAD: 03n_reed * r47040 10/brlcad/trunk/src/other/step/src/express/ (CMakeLists.txt expscan.re): Added disabled macros to build temp fedex_new target for development. Added expscan.re to build against, but it has not yet been converted to re2c. |
| 13:31.25 | CIA-48 | BRL-CAD: 03bob1961 * r47041 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: |
| 13:31.26 | CIA-48 | BRL-CAD: bot_split2, if the specified bot was split, now returns a list containing the |
| 13:31.26 | CIA-48 | BRL-CAD: name of the original bot and the backup name. The original name is used for the |
| 13:31.26 | CIA-48 | BRL-CAD: group containing the new bots resulting from the split. The backup name |
| 13:31.26 | CIA-48 | BRL-CAD: references the original bot. |
| 13:33.59 | CIA-48 | BRL-CAD: 03bob1961 * r47042 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added bot_split_all, bot_sync_all and bot_fix_all. Updated bot_flip_check to return a built up string instead of spewing things directly to the command window. |
| 13:55.49 | ``Erik | http://gcc.gnu.org/wiki/CompileFarm |
| 15:33.21 | CIA-48 | BRL-CAD: 03bob1961 * r47043 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Ripped out Archer's undo mechanism in preparation for using transactions. |
| 15:38.54 | brlcad | ``Erik: nifty, going to set us up the bomb? |
| 15:40.35 | brlcad | mm, that might explain why my revolve sketch performance test case was crashing if it only supports straight line segments... |
| 15:46.29 | ``Erik | I sent a request for an account just before linking it |
| 15:50.35 | CIA-48 | BRL-CAD: 03starseeker * r47044 10/brlcad/trunk/doc/docbook/ (CMakeLists.txt resources/brlcad/brlcad-xml-catalog.xml.in): |
| 15:50.35 | CIA-48 | BRL-CAD: First baby steps towards more advanced Docbook processing with CMake. Make the |
| 15:50.35 | CIA-48 | BRL-CAD: catalog file a CMake configure template, and add the environment variables |
| 15:50.35 | CIA-48 | BRL-CAD: needed for xsltproc to the custom command invocations. Lot more and lot tricker |
| 15:50.36 | CIA-48 | BRL-CAD: to come, but this is a start. |
| 16:15.32 | CIA-48 | BRL-CAD: 03starseeker * r47045 10/brlcad/trunk/doc/docbook/ (CMakeLists.txt resources/brlcad/brlcad-xml-catalog.xml.in): switch a couple of the xsl stylesheet targets, fix paths. |
| 16:54.04 | CIA-48 | BRL-CAD: 03starseeker * r47046 10/brlcad/trunk/doc/docbook/ (CMakeLists.txt books/CMakeLists.txt): Getting closer to getting pdf working, but not finding fonts... missing something. |
| 16:58.22 | CIA-48 | BRL-CAD: 03starseeker * r47047 10/brlcad/trunk/doc/docbook/ (articles/en/CMakeLists.txt presentations/en/CMakeLists.txt): Couple stray leftover variables. |
| 17:16.48 | *** join/#brlcad pacman87 (~Timothy@adsl-208-191-158-89.dsl.hstntx.swbell.net) | |
| 17:29.56 | CIA-48 | BRL-CAD: 03starseeker * r47048 10/brlcad/trunk/doc/docbook/CMakeLists.txt: fix typo. Try and get the fop command line to match that from autotools |
| 17:41.00 | *** join/#brlcad n_reed (~nreed1@ool-457cb1ab.dyn.optonline.net) | |
| 17:47.23 | CIA-48 | BRL-CAD: 03abhi2011 * r47049 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simphysics.cpp simulate.c simulate.h): Added more code to check the generated manifolds |
| 18:16.06 | CIA-48 | BRL-CAD: 03bob1961 * r47050 10/brlcad/trunk/src/libged/ (bot_flip.c bot_split.c bot_sync.c): Modify bot_split, bot_sync and bot_flip to accept arguments containing full paths to bots. |
| 18:20.46 | CIA-48 | BRL-CAD: 03brlcad * r47051 10/brlcad/trunk/src/libged/simulate/simulate.h: separate out struct members into one per line so they can be individually documented; revert the ws changes. |
| 18:21.16 | brlcad | abhi2011: your previous commit just undid all of the whitespace corrections applied yesterday |
| 18:24.40 | brlcad | the only way that would occur is if either a) you got a conflict and resolved it incorrectly or b) ran a source formatter before committing and applied the wrong style |
| 18:26.56 | CIA-48 | BRL-CAD: 03bob1961 * r47052 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Simplify ArcherCore::redrawObj. |
| 18:28.38 | CIA-48 | BRL-CAD: 03brlcad * r47053 10/brlcad/trunk/src/libged/simulate/simulate.c: use vmath macros where appropriate, reduces line count. restore indent for the affected functions. |
| 18:31.55 | abhi2011 | brlcad: I just applied the sh/ws.sh and sh/indent.sh on all the files in simulate/* files |
| 18:32.06 | abhi2011 | before committing |
| 18:32.28 | abhi2011 | is only one of them supposed to be run and not both ? |
| 18:39.50 | abhi2011 | hmm the indentation should be 4 spaces, however after i ran indent.sh it indented everything by 2 spaces |
| 18:43.06 | CIA-48 | BRL-CAD: 03brlcad * r47054 10/brlcad/trunk/src/libbu/ (11 files): trailing ws and indent cleanup |
| 18:43.11 | brlcad | abhi2011: yeah, something didn't go right with the indent |
| 18:43.31 | brlcad | for what it's worth, you should always separate ws/indent commits from logic changes |
| 18:43.38 | brlcad | otherwise you can't tell what the changes were |
| 18:44.00 | abhi2011 | ok |
| 18:44.10 | brlcad | something apparently went wrong with the indent.sh script -- do you use emacs? |
| 18:44.13 | abhi2011 | hmm i just ran indent again and its indented everything by 2 spaces |
| 18:44.15 | abhi2011 | yes |
| 18:44.20 | abhi2011 | i instaled emacs today |
| 18:44.28 | brlcad | do you have a C hook registered? |
| 18:44.30 | abhi2011 | does it require configuration |
| 18:44.32 | abhi2011 | no |
| 18:44.53 | abhi2011 | i do not have a C hook registered |
| 18:45.00 | brlcad | it shouldn't require configuration, but if you have an existing config it can override the file settings |
| 18:45.20 | brlcad | try running indent.sh on one file and see what it does |
| 18:45.31 | brlcad | pastebin the output |
| 18:46.33 | abhi2011 | http://bin.cakephp.org/view/530534711 |
| 18:46.44 | abhi2011 | i ran : sh/indent.sh src/libged/simulate/simulate.c |
| 18:47.26 | CIA-48 | BRL-CAD: 03tbrowder2 * r47055 10/brlcad/trunk/doc/docbook/resources/other/: start of resources restructuring |
| 18:47.50 | abhi2011 | i think after installation, emacs needs to be told to indent by 4 spaces, else it defaults to 2 |
| 18:47.56 | brlcad | I meant the output from indent.sh :) |
| 18:47.58 | abhi2011 | hmm maybe something missing in the trailer |
| 18:48.00 | abhi2011 | ok |
| 18:48.51 | abhi2011 | http://bin.cakephp.org/view/2025222878 |
| 18:49.08 | abhi2011 | i think the trailer needs to contain the indentation info in the c file |
| 18:49.12 | abhi2011 | i ll add it and see |
| 18:49.43 | abhi2011 | though I would have thought that the one already there will work |
| 18:50.33 | CIA-48 | BRL-CAD: 03tbrowder2 * r47056 10/brlcad/trunk/doc/docbook/resources/ (docbook/ docbook-5.0/): rename to remove version |
| 18:50.34 | brlcad | abhi2011: c-file-style: "stroustrup" sets an indentation of 4 |
| 18:50.39 | abhi2011 | hmm trailer in the simulate.c file is same as any other file |
| 18:50.41 | abhi2011 | yes |
| 18:51.11 | abhi2011 | emacs messing around with my code :P |
| 18:51.17 | brlcad | what version of emacs? |
| 18:51.32 | abhi2011 | GNU Emacs 23.2.1 |
| 18:52.17 | CIA-48 | BRL-CAD: 03tbrowder2 * r47057 10/brlcad/trunk/doc/docbook/resources/ (docbook/ docbook-schema/): rename for clarity; avoid confusion with stylesheets |
| 18:53.12 | abhi2011 | something needs to be put in .emacs |
| 18:53.25 | brlcad | hm, yours is slightly newer than mine, what does M-x describe-variable c-file-style report? |
| 18:53.41 | CIA-48 | BRL-CAD: 03tbrowder2 * r47058 10/brlcad/trunk/doc/docbook/resources/ (docbook-schema/ other/docbook-schema/): segregate external resources |
| 18:54.41 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 18:54.59 | CIA-48 | BRL-CAD: 03tbrowder2 * r47059 10/brlcad/trunk/doc/docbook/resources/ (other/standard/ standard/): segregate external resources |
| 18:55.14 | brlcad | I have nothing in my .emacs |
| 18:55.32 | brlcad | the only thing that might be affecting this is if local variable parsing is off by default in 23.2.1 |
| 18:55.43 | CIA-48 | BRL-CAD: 03tbrowder2 * r47060 10/brlcad/trunk/doc/docbook/resources/ (fonts/ other/fonts/): segregate external resources |
| 18:55.58 | brlcad | do you know how to run M-x describe-variable c-file-style ? |
| 18:56.22 | brlcad | (run that with a buffer open to src/libged/simulate/simulate.c |
| 18:56.22 | abhi2011_ | brlcad: no I dont |
| 18:56.45 | brlcad | M-x is the starting key binding, usually "ESC x" or "ALT+x" |
| 18:56.58 | CIA-48 | BRL-CAD: 03tbrowder2 * r47061 10/brlcad/trunk/doc/docbook/resources/other/offo/: restucturing external resources |
| 18:57.03 | brlcad | then type "describe-variable[ENTER]" |
| 18:57.21 | brlcad | it'll prompt you for a variable name, type "c-file-style[ENTER]" |
| 18:57.27 | abhi2011_ | ok |
| 18:57.34 | brlcad | if should split the buffer and show you the value |
| 18:57.52 | brlcad | saying something like "Its value is 'stroustrup'" |
| 18:57.57 | CIA-48 | BRL-CAD: 03tbrowder2 * r47062 10/brlcad/trunk/doc/docbook/resources/ (4 files in 4 dirs): segregate external resources |
| 18:58.09 | abhi2011_ | ok got it, alt x |
| 18:58.36 | abhi2011_ | hmm No match |
| 18:58.39 | brlcad | ctrl-g ctrl-g if you mess up :) |
| 18:58.52 | abhi2011 | for c-file-style |
| 18:58.56 | abhi2011 | i ll have to set it |
| 18:59.14 | brlcad | no you don't |
| 18:59.21 | abhi2011 | yeah its thr in the file |
| 18:59.41 | brlcad | M-x describe-mode |
| 19:00.26 | brlcad | should be something like "C/l mode" |
| 19:01.00 | abhi2011 | no match there either |
| 19:01.15 | abhi2011 | though i did get lot of messages |
| 19:03.20 | brlcad | then you're doing something wrong :0 |
| 19:03.22 | brlcad | :) |
| 19:03.27 | brlcad | there's always a mode |
| 19:03.32 | abhi2011 | http://bin.cakephp.org/view/916412370 |
| 19:03.56 | brlcad | ah, Fundamental mode |
| 19:04.01 | abhi2011 | :P |
| 19:04.02 | brlcad | that's wrong |
| 19:04.14 | brlcad | or you were in the wrong buffer |
| 19:05.08 | abhi2011 | ok wait |
| 19:05.24 | abhi2011 | i think i did not open a buffer to simulate.c |
| 19:05.27 | abhi2011 | thats why |
| 19:05.35 | brlcad | ah, yes |
| 19:05.42 | brlcad | *before* running M-x .. make sure your cursor is in the buffer for simulate.c |
| 19:06.07 | brlcad | "C-x o" will jump to the "other"/next buffer |
| 19:06.30 | CIA-48 | BRL-CAD: 03tbrowder2 * r47063 10/brlcad/trunk/doc/docbook/resources/other/fonts/truetype/stix-v1.0.0/README: document version of the STIX fonts |
| 19:06.51 | abhi2011 | ok c file style is strousup |
| 19:07.07 | abhi2011 | *stroustrup |
| 19:07.20 | brlcad | so last thing to check.. |
| 19:07.38 | brlcad | and that's "good" because it means it read the local vars block |
| 19:07.53 | abhi2011 | mode is C/l mode |
| 19:08.20 | brlcad | M-x describe-variable c-indentation-style |
| 19:08.24 | brlcad | great |
| 19:09.10 | abhi2011 | stroustrup |
| 19:09.23 | abhi2011 | next must check indetation value |
| 19:10.05 | abhi2011 | c-indentation-style's value is "stroustrup" |
| 19:10.08 | abhi2011 | Local in buffer simulate.c; global value is nil |
| 19:12.04 | brlcad | that's right |
| 19:12.57 | abhi2011 | it indents c++ files correctly |
| 19:13.02 | abhi2011 | 4 spaces |
| 19:13.25 | brlcad | now the big one: M-x describe-variable c-style-alist |
| 19:13.58 | brlcad | pastebin the whole thing or at least the section where "stroustrup" begins |
| 19:14.27 | CIA-48 | BRL-CAD: 03tbrowder2 * r47064 10/brlcad/trunk/doc/docbook/resources/other/fonts/truetype/ (stix/ stix-v1.0.0/): rename to remove version |
| 19:15.54 | abhi2011 | http://bin.cakephp.org/view/1824577032 |
| 19:16.11 | abhi2011 | (c-basic-offset . 2) |
| 19:16.42 | abhi2011 | hmm no for stroustrup its correct at 4 |
| 19:16.59 | brlcad | exactly, something else is going on |
| 19:17.31 | brlcad | go to the first function in simulate.c and press tab down each line starting at the beginning of the function |
| 19:17.40 | brlcad | does it indent the lines to 4 or leave them at 2 ? |
| 19:18.14 | CIA-48 | BRL-CAD: 03tbrowder2 * r47065 10/brlcad/trunk/doc/docbook/resources/other/fonts/truetype/ (dejavu-lgc/ dejavu-lgc-fonts-ttf-2.33/): rename to remove version |
| 19:20.27 | *** join/#brlcad merzo (~merzo@137-237-132-95.pool.ukrtel.net) | |
| 19:20.44 | CIA-48 | BRL-CAD: 03tbrowder2 * r47066 10/brlcad/trunk/doc/docbook/resources/other/fonts/ (dejavu-lgc/ stix/ truetype/dejavu-lgc/ truetype/stix/): restructure external resources |
| 19:20.50 | abhi2011 | hmm no matter what i insert : spaces or tab at the beginning of each line of the 1st function, its forcing it all back to 2 spaces indent |
| 19:21.15 | abhi2011 | maybe i can try running the formatting command from inside emacs |
| 19:21.26 | abhi2011 | as soon as I know wat it is :P |
| 19:23.59 | CIA-48 | BRL-CAD: 03tbrowder2 * r47067 10/brlcad/trunk/doc/docbook/resources/other/fonts/truetype/: remove unused dir |
| 19:24.23 | brlcad | abhi2011: if tab isn't indenting to column 4, something else is still overriding |
| 19:24.52 | brlcad | with mode C/l and style stroustrup, indent shoudl be 4 |
| 19:25.04 | brlcad | do you have a .emacs file? |
| 19:25.09 | abhi2011 | yes |
| 19:25.14 | brlcad | pastebin? |
| 19:26.13 | abhi2011 | http://bin.cakephp.org/view/994500422 |
| 19:26.20 | starseeker | never could get emacs to indent right... |
| 19:26.38 | brlcad | starseeker: or vim :P |
| 19:27.10 | starseeker | brlcad: what about using astyle? can it do what we need? That would avoid requiring any specific editor (or version of that editor...) |
| 19:27.27 | starseeker | http://astyle.sourceforge.net/ |
| 19:27.53 | CIA-48 | BRL-CAD: 03tbrowder2 * r47068 10/brlcad/trunk/doc/docbook/resources/other/offo/README: document what version of offo this is |
| 19:28.19 | brlcad | starseeker: are you offering to set up the style file? :) |
| 19:28.46 | brlcad | a tool is a tool, you'd still have to spell out the style in detail to astyle just like is being done here |
| 19:28.50 | starseeker | if it would resolve all of this and give us a consistent, editor independent way to proceed it would be worth it |
| 19:29.00 | CIA-48 | BRL-CAD: 03tbrowder2 * r47069 10/brlcad/trunk/doc/docbook/resources/other/offo/ (binary/ offo-hyphenation-binary-v2.0/): rename to remove version |
| 19:29.01 | starseeker | nods - I can give it a go |
| 19:29.14 | abhi2011 | hmm there is a .gnu-emacs file too |
| 19:29.16 | brlcad | from indent.sh's pespective, it isn't an editor -- it might as well be running astyle |
| 19:29.21 | abhi2011 | in /etc/skel |
| 19:29.30 | abhi2011 | thats probaly loaded |
| 19:29.35 | brlcad | abhi2011: but is there a .gnu-emacs in your home dir? |
| 19:29.46 | CIA-48 | BRL-CAD: 03tbrowder2 * r47070 10/brlcad/trunk/doc/docbook/resources/other/offo/ (offo-hyphenation-source-v2.0/ source/): rename to remove version |
| 19:29.49 | abhi2011 | no |
| 19:30.16 | starseeker | brlcad: right. I just mean it's probably a better bet to get astyle doing the exact same thing consistently than an editor (I'm clearly not the only one having emacs troubles...) |
| 19:30.16 | brlcad | what's in the one in skel? |
| 19:30.57 | starseeker | grabs astyle for a look while tbrowder2 is organizing... |
| 19:31.11 | brlcad | starseeker: I don't disagree, it's just actually at least a solid days work to get the style spelled out correctly |
| 19:31.50 | abhi2011 | saw this in the gnu-emacs file: http://bin.cakephp.org/view/89434569 |
| 19:31.59 | starseeker | <snort> considering the number of times I barf all over ws/indenting, I'll probably make up the time in fairly short order (or save you cleaning it up, anyway :-P) |
| 19:32.06 | brlcad | and last I checked, astyle had some significant bugs that made it parse either macros or C++ files poorly .. been a while |
| 19:32.49 | brlcad | abhi2011: that looks benign |
| 19:34.42 | brlcad | basically saying that it "should" be a better bet to get something like astyle going, but five years ago emacs was the only one that actually got it right for both our C and C++ files by just saying "use stroustrup style" plus a few pedantic tweaks |
| 19:35.37 | starseeker | nods - well, it looks like astyle has been developed since then so perhaps worth anothe rlook |
| 19:35.44 | brlcad | if it does better now, that'd be great but it'll beg for some careful testing |
| 19:36.12 | brlcad | for example, libbu is pretty clean right now -- should be able to run it on the files there and basically have nothing change |
| 19:36.47 | abhi2011 | i wrote a * c-basic-offset: 4 in the trailer :P |
| 19:36.53 | abhi2011 | it worked now |
| 19:37.15 | brlcad | except maybe for a few nicities that astyle can manage that emacs cannot, like making sure there is curlies on the if clause there are curlies on the else clause and vice-versa |
| 19:37.21 | abhi2011 | beginners can get really silly :P |
| 19:37.33 | brlcad | abhi2011: that's still *highly* suspect |
| 19:37.45 | brlcad | that means it's not necessarily applying stroustrup style |
| 19:37.47 | CIA-48 | BRL-CAD: 03tbrowder2 * r47071 10/brlcad/trunk/doc/docbook/create-xml-catalogs.pl: rename dirs for new structure |
| 19:37.52 | abhi2011 | hmm yeah |
| 19:38.31 | brlcad | indent them and commit, I can retest on my end to see if anything else changes |
| 19:44.04 | CIA-48 | BRL-CAD: 03tbrowder2 * r47072 10/brlcad/trunk/doc/docbook/fop.xconf.in: make more general - absolute file path for out-of-directory build |
| 19:45.41 | abhi2011 | hmm, the indenting seems to have a number of passes , it indented the simulate.h correctly while doing these passes (i reloaded the file while it was indenting) then in some subsequent pass it indented back to 2 |
| 19:45.50 | abhi2011 | the simulate.c file is still correct |
| 19:46.01 | abhi2011 | says its Loading vc-svn... |
| 19:47.56 | CIA-48 | BRL-CAD: 03tbrowder2 * r47073 10/brlcad/trunk/doc/docbook/fop.xconf.in: update font path for restucturing |
| 19:48.25 | abhi2011 | will do a build then commit |
| 19:49.22 | brlcad | vc-svn is to be expected, it knows the file is from svn |
| 19:49.57 | brlcad | abhi2011: another thing you can try, use this .emacs file: http://brlcad.org/wiki/Emacs |
| 19:50.08 | brlcad | you'll have to restart emacs in order for it to be loaded properly |
| 19:50.43 | brlcad | shouldn't affect anything but it might turn off some hook that was being registered by default |
| 19:51.57 | abhi2011 | ok, btw I dont use emacs for normal editing, eclipse is kinda easier :P |
| 19:54.58 | CIA-48 | BRL-CAD: 03brlcad * r47074 10/brlcad/trunk/src/libged/bot_flip.c: instead of manually searching down path elements, just use bu_basename(). it does exactly that and is the well defined reusable interface. |
| 20:00.29 | abhi2011 | hmm that .emacs didnt make a difference |
| 20:02.32 | CIA-48 | BRL-CAD: 03brlcad * r47075 10/brlcad/trunk/src/libged/ (bot_split.c bot_sync.c): |
| 20:02.32 | CIA-48 | BRL-CAD: more reuse of bu_baseame() instead of replicating the same strrchr() code. |
| 20:02.32 | CIA-48 | BRL-CAD: probably deserves a librt routine for getting a basename from a path so we can |
| 20:02.32 | CIA-48 | BRL-CAD: avoid dynamic memory but this is still a reuse improvement for now. |
| 20:02.53 | brlcad | abhi2011: well that's good to hear -- it shouldn't have made a difference :) |
| 20:03.36 | brlcad | so there's basically just something else going on that is perhaps specific to emacs 23, which I don't have handy to test on |
| 20:04.18 | abhi2011 | brlcad: time to upgrade :) |
| 20:05.29 | CIA-48 | BRL-CAD: 03abhi2011 * r47076 10/brlcad/trunk/src/libged/simulate/ (simulate.c simulate.h): Corrected indenting by adding c-basic-offset: 4 to file trailer and running indent.sh only |
| 20:06.12 | brlcad | abhi2011: and emacs is notorious for it's learning curve -- it takes a solid week to get the basics fluent -- but definitely pays off in the long run with the usability and programmability efficiencies it affords (at least in my experience and everyone I've known that made it over the learning curve) |
| 20:10.38 | CIA-48 | BRL-CAD: 03brlcad * r47077 10/brlcad/trunk/misc/batch-indent-region.el: set the c-basic-offset forcibly in case there's something specific about batch mode in emacs23 |
| 20:11.16 | brlcad | abhi2011: you said it was working sometimes indenting correctly and other times not? |
| 20:13.14 | abhi2011 | well no, i reloaded the file in gedit while the indentation was going on, and then i noticed that the lines in simulate.h only were indented by 4 spaces |
| 20:13.40 | abhi2011 | but when the indent script finished, i reloaded again and it was 2 spaces again |
| 20:14.13 | abhi2011 | that made me think that maybe it was doing it correctly, but later on something over rode the default indenting |
| 20:18.02 | brlcad | if you remove the local variable (the line in the footer) and re-run indent.sh after r47077, does it correctly indent to 4? |
| 20:30.27 | abhi2011 | brlcad: nope, its back to 2 again |
| 20:31.52 | *** join/#brlcad _pseudonym (~tvanruite@yoshi.ece.utexas.edu) | |
| 20:34.20 | brlcad | abhi2011: k, researching |
| 20:34.40 | abhi2011 | brlcad: thanks :) |
| 20:35.01 | brlcad | pretty awesome.. fully svg website: http://emacsformacosx.com/ |
| 20:35.55 | CIA-48 | BRL-CAD: 03brlcad * r47078 10/brlcad/trunk/misc/batch-indent-region.el: no-go, remove the basic offset since files are supposed to define it via their style. |
| 20:38.07 | n_reed | brlcad: nice. if i scale the page in my browser, i can see the fallback msg for people with ie |
| 20:39.53 | CIA-48 | BRL-CAD: 03tbrowder2 * r47079 10/brlcad/trunk/doc/docbook/Makefile.am: correct path for new offo hyphenation binary |
| 20:43.44 | starseeker | ah, phooey - astyle --style=stroustrup isn't a no-op on vls.c |
| 20:44.03 | brlcad | abhi2011: bah, 23.3 is working just fine here... |
| 20:44.51 | brlcad | starseeker: stroustrup might be the same word but doesn't necessarily mean the same thing to those two apps |
| 20:45.07 | starseeker | nods |
| 20:45.22 | brlcad | you'd hope it meant something close to similar |
| 20:45.44 | brlcad | but to astyle's credit, they have a lot more knobs to worry about when it comes to formatting |
| 20:45.51 | starseeker | whitespace didn't agree, other than that just a few bracket placements |
| 20:46.07 | starseeker | will poke at it some more |
| 20:46.08 | abhi2011 | hmm |
| 20:46.25 | brlcad | starseeker: like I said, it's going to take nearly a full day at best to get right |
| 20:46.44 | brlcad | useful to have, but it is a distraction |
| 20:46.44 | starseeker | nods |
| 20:47.09 | starseeker | so is trying to figure out why emacs is being quirky :-P |
| 20:47.34 | brlcad | only because I don't have access to his box to poke at it myself |
| 20:48.12 | brlcad | until I updated, could only assume it was something 23-specific, but even that isn't proving to be the case |
| 20:48.58 | brlcad | abhi2011: so don't worry about style for now -- but ws.sh should still work |
| 20:49.08 | brlcad | it uses manual regexps |
| 20:49.25 | brlcad | if you're going to use emacs, I can send you some lines to put in your .emacs file that will make it work |
| 20:49.58 | brlcad | otherwise you'll just have to follow convention on braces and internal spacing |
| 20:51.18 | abhi2011 | brlcad: yes please send me the lines, I ll be using emacs to format it , through the indent.sh script |
| 20:52.51 | starseeker | here's what astyle is doing with vls.c by default: http://bzflag.bz/~starseeker/vls_astyle.c |
| 20:53.13 | starseeker | actually doesn't look bad, at a glance... |
| 20:55.24 | abhi2011 | so is there an easy way to draw a line in the mged window |
| 20:55.29 | abhi2011 | I need to draw some normals |
| 20:55.40 | starseeker | some of the stuff it indented, I'm almost wondering why it wasn't indented that way initially... |
| 20:56.18 | abhi2011 | otherwise i ll use a bot, with 1 triangle |
| 20:57.10 | *** join/#brlcad mattS_ (cb3af1be@gateway/web/freenode/ip.203.58.241.190) | |
| 20:59.02 | mattS_ | Hi there, looking for some background info on the "revolve" project; is there anyone here who knows a bit about it? Specifically, I'm looking for some fundamental background details, as opposed to questions about the current code. |
| 21:03.07 | brlcad | starseeker: yeah, I'm seeing lots of undesirableness already |
| 21:03.24 | brlcad | at least, rather drastic style changes |
| 21:03.41 | mattS_ | Or, for that matter, anyone familiar with the projective geometry employed in most any raytrace alg. in brlcad. |
| 21:03.45 | brlcad | eliminated all tabs, unindented case statements |
| 21:03.48 | brlcad | mattS_: howdy |
| 21:04.02 | mattS_ | brlcad: Hi. |
| 21:04.27 | brlcad | mattS_: I saw your thread with pacman87 earlier, sounds fantastic |
| 21:04.49 | brlcad | hopefully can help, what are your questions? |
| 21:05.14 | brlcad | "<starseeker> some of the stuff it indented, I'm almost wondering why it wasn't indented that way initially" such as? |
| 21:05.24 | mattS_ | well, the thing I'm struggling with at the moment is *why* everything involves a hyperbolic transformation. |
| 21:05.57 | brlcad | you'll have to point me at some code, what are you referring to specifically? |
| 21:06.19 | mattS_ | Hm, hang on... |
| 21:07.20 | brlcad | otherwise, I'm not sure that's a true statement .. some of the primitives are cubit, quadratic, quartic, ... |
| 21:07.30 | mattS_ | This is from an old correspondence with pacman that I left hanging: |
| 21:07.33 | mattS_ | There are two parts to a sweep: the sketch (2d surface outline), and the path (3d spline). For a revolve, the path is a circle. My basic algorithm for shot() is: 1. Calculate a transformation to make the sweep path a straight line. 2. Apply the transformation to the ray. 3. Project the transformed ray onto the sketch plane. 4. Find all intersection points between the ray and the sketch. The ray is given in terms of a point, vector |
| 21:08.08 | mattS_ | <PROTECTED> |
| 21:08.17 | starseeker | brlcad: line 57 - the bu_bomb |
| 21:08.28 | mattS_ | The sketch uses 4 types of lines: line segments, circular arcs, bezier splines, and nurbs. If the 3d spline is piece-wise define, then the transformation will also be piecewise defined, and the intersection check in (4) will have to check each ray piece with each sketch piece. |
| 21:08.41 | mattS_ | For the specific case of a revolve, the transformed ray will be a hyperbola in 2d, so steps 1-3 can be condensed into finding the hyperbola given the point and vector of the ray, and the point and vector about which to revolve. |
| 21:09.01 | mattS_ | <end quote> |
| 21:09.03 | brlcad | starseeker: it didn't change the indent on that line, it removed the tab |
| 21:09.20 | starseeker | ah |
| 21:09.30 | starseeker | tries with tabs turned on... |
| 21:09.37 | mattS_ | So, what I'm missing is where the hyperbola comes from in the transformation... |
| 21:09.55 | mattS_ | Or, more specifically, what the transformation is, I guess. |
| 21:10.33 | mattS_ | I'm assuming that something similar is done elsewhere in the software, hence the approach. |
| 21:11.21 | mattS_ | But, in order to attempt to finish things off, I need to "get" what it is that is going on. |
| 21:12.01 | brlcad | mattS_: actually, I don't believe that approach is taken elsewhere in the software (because it doesn't need to) |
| 21:12.15 | brlcad | except for maybe the hyperbola primitive ;) |
| 21:12.24 | brlcad | hyperboloid |
| 21:12.42 | mattS_ | OK, so if I were to try something different, that wouldn't mess things up elsewhere? |
| 21:13.00 | brlcad | which actually may be where he's got the idea from -- he implemented the hyperboloid of one sheet primitive |
| 21:13.20 | mattS_ | Yes, I saw that. |
| 21:15.52 | mattS_ | OK, I'll try putting something together then, and if I can get it working at all, then I'll hope that somebody here with better programming skills than me (I'm an engineer with a strong mathematics background) can help me clean things up. |
| 21:16.28 | mattS_ | But I really would like to understand the logic behind what he's done... |
| 21:16.30 | brlcad | I'm not exactly seeing how it's a hyperboloid myself, but then I've only been thinking about it all of 2 minutes now |
| 21:16.51 | mattS_ | Yeah, that's where I' |
| 21:16.59 | brlcad | things make much more sense to me in code form ;) |
| 21:17.13 | mattS_ | I'm stuck. The steps are all fairly straightforward, I just don't get why he's done them. |
| 21:17.55 | mattS_ | OK, have a look at brlcad/trunk/src/librt/primitives/revolve/revolve.c |
| 21:18.20 | brlcad | mattS_: I assume you have a general understanding of the transformations being aplied to the ray in general, yes? |
| 21:18.42 | mattS_ | I thought I did... |
| 21:18.46 | brlcad | even for something as simple as the sphere, it's not just plugging in values into the quadratic formulat |
| 21:19.03 | mattS_ | Yes, I know that. |
| 21:19.13 | brlcad | it transforms the sphere into an idealized unitized sphere at the origin, then transforms the ray to match |
| 21:19.20 | brlcad | in order to give stable numerics |
| 21:20.38 | mattS_ | Yup, based around a mapping of the surface onto the plane. |
| 21:21.36 | mattS_ | So there would be a transformation of the g_{ij} metric based on... |
| 21:21.42 | mattS_ | some sort of projection. |
| 21:21.44 | mattS_ | ? |
| 21:22.30 | mattS_ | I'm assuming it's this projection that leads to the hyperbolic transform, which is where I guess my question lies. |
| 21:23.00 | brlcad | hm, maybe |
| 21:23.18 | brlcad | that'd actually be a great question to pose to the mailing list or to d_rossberg if you can catch him in here |
| 21:23.34 | mattS_ | Do you know where I could read up on this sort of stuff? |
| 21:23.36 | brlcad | he was pacman's gsoc mentor so he's a lot more familiar with the project and approach taken |
| 21:23.54 | brlcad | mailing list: brlcad-devel on sourceforge |
| 21:24.02 | mattS_ | OK, I could try emailing him as well... |
| 21:24.11 | mattS_ | do you know if that's possible? |
| 21:24.37 | brlcad | that'd be the mailing list |
| 21:24.56 | mattS_ | I'm new to this; how do I access the mailing list? |
| 21:25.00 | brlcad | easiest way to reach him and maybe get some input from other devs too |
| 21:25.23 | brlcad | mailing lists are all listed here: https://sourceforge.net/mail/?group_id=105292 |
| 21:25.36 | brlcad | you'll want to subscribe to at least this one: https://lists.sourceforge.net/lists/listinfo/brlcad-devel |
| 21:26.16 | brlcad | a source code reference that *may* be of reference that goes into extensive math detail is the elliptical hyperboloid primitive |
| 21:26.31 | brlcad | it documents the algorithm in nicedetail |
| 21:26.39 | brlcad | src/librt/primitives/ehy/ehy.c |
| 21:27.31 | brlcad | if pacman is somehow approaching the surface as some sort of hyperboloid transformation, he may be using similar techniques that would be documented in the hyp primitive |
| 21:27.37 | brlcad | er ehy primitive |
| 21:27.53 | mattS_ | Could be. |
| 21:28.37 | brlcad | starseeker: also note that case statements should be indented from switches, as should case body lines |
| 21:29.47 | mattS_ | OK, subscribed. I'll have a look at ehy.c, and post question(s) to the mailing list. |
| 21:29.53 | mattS_ | Thanks for the help! |
| 21:29.57 | starseeker | brlcad: I'm emailing the astyle author - not immediately clear to me if he supports the mixed spaces and tabs style we're using |
| 21:30.24 | starseeker | when I turn on tabs, it replaces our 4 space indents with tabs too |
| 21:32.10 | starseeker | might be a bug, more probably I'm doing something wrong |
| 21:32.14 | mattS_ | OK, back to work for now... |
| 21:32.48 | brlcad | mattS_: a much simpler algorithm explanation of a quadratic is in src/librt/primitives/ell/ell.c |
| 21:33.03 | brlcad | pacman would have also have gone over that as a foundation |
| 21:33.14 | brlcad | starseeker: definitely does |
| 21:33.55 | brlcad | it's one of only three common indent styles |
| 21:34.02 | brlcad | only spaces |
| 21:34.03 | brlcad | only tabs |
| 21:34.07 | brlcad | and mixed |
| 21:34.43 | brlcad | then you have the concept of indent levels and tabstops to get what you want |
| 21:35.33 | starseeker | so far has yet to find a combination of options that doesn't rejigger our whitespace |
| 21:39.08 | *** part/#brlcad n_reed (~nreed1@ool-457cb1ab.dyn.optonline.net) | |
| 21:41.25 | brlcad | starseeker: what about "-s4 -t" |
| 21:41.49 | brlcad | or -s4 -T4 |
| 21:42.26 | starseeker | shakes his head - neither one |
| 21:42.45 | starseeker | was thinking along those same lines - that's why I emailed him, one of those ought to have worked |
| 21:44.04 | starseeker | brlcad: might be able to add -S and -K to address some of the switch/case concerns |
| 21:44.15 | starseeker | if we can get the whitespace to behave |
| 21:44.37 | brlcad | on the offchance it doesn't, I'd shelve the project for the time-being since changing the indent is going to affect every file and is a bit more of a major change |
| 21:44.47 | starseeker | nods |
| 21:45.04 | starseeker | yeah, I have no desire to tangle with it |
| 21:45.21 | starseeker | just thought I'd check and see if the problem could be solved once and for all |
| 21:46.55 | *** join/#brlcad merzo (~merzo@137-237-132-95.pool.ukrtel.net) | |
| 21:49.41 | brlcad | starseeker: what about -s4 -t8 |
| 22:03.56 | starseeker | nope :-/ |
| 22:05.29 | starseeker | author just replied - "currently no way to do this with astyle" |
| 22:12.53 | *** join/#brlcad pacman87 (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net) | |
| 22:27.11 | brlcad | starseeker: wow, that's surprising |
| 22:27.25 | brlcad | oh well |
| 22:29.31 | brlcad | we could update our style to the next best compromise, but it'd probably be better to hold off for a planned minor |
| 23:02.14 | starseeker | nods - yeah, change on that scale'd be a minor for sure |
| 23:02.50 | starseeker | grins - maybe we could plan it for the same time as the copyright update - as long as we're touching so many files anyhow, kill two birds with one stone |
| 23:04.13 | starseeker | ooo, interesting: http://code.google.com/p/chibi-scheme/ |
| 23:27.52 | *** join/#brlcad bhinesley (~bhinesley@99.144.92.88) | |
| 01:00.47 | CIA-48 | BRL-CAD: 03brlcad * r47080 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simphysics.cpp): minor alignment |
| 02:39.49 | CIA-48 | BRL-CAD: 03starseeker * r47081 10/brlcad/trunk/doc/docbook/ (CMakeLists.txt resources/brlcad/brlcad-xml-catalog.xml.in): Accomidate new directory locations |
| 03:05.51 | CIA-48 | BRL-CAD: 03brlcad * r47082 10/brlcad/trunk/src/librt/comb/comb.c: leave a NOTE about the anamoly so it's documented and so someone doesn't accidentally remove it later without understanding the implications. |
| 03:18.36 | CIA-48 | BRL-CAD: 03brlcad * r47083 10/brlcad/trunk/src/libged/simulate/simulate.h: include vmath. headers need to include the headers they require. |
| 03:25.59 | CIA-48 | BRL-CAD: 03brlcad * r47084 10/brlcad/trunk/src/libged/simulate/ (4 files): header cleanup. helps to identify redundant and avoid cyclic includes. |
| 03:48.50 | CIA-48 | BRL-CAD: 03brlcad * r47085 10/brlcad/trunk/NEWS: |
| 03:48.50 | CIA-48 | BRL-CAD: richard improved the g-vrml exporter so that it no longer halts conversion on |
| 03:48.50 | CIA-48 | BRL-CAD: the first bomb encountered, but now keeps track of the failure count and |
| 03:48.50 | CIA-48 | BRL-CAD: continues processing (similar to the other converters). this feature was |
| 03:48.50 | CIA-48 | BRL-CAD: requested by tim mallory and has been mentioned by other users. |
| 04:00.57 | CIA-48 | BRL-CAD: 03brlcad * r47086 10/brlcad/trunk/NEWS: |
| 04:00.57 | CIA-48 | BRL-CAD: I implemented a new g-dot exporter for exporting to the Graphviz DOT format, |
| 04:00.57 | CIA-48 | BRL-CAD: allowing for impressive visualization of geometry structure's DAG. intended as |
| 04:00.57 | CIA-48 | BRL-CAD: a plugin piece for the GCV/GS and new geometry editor (way) down the road. |
| 04:07.54 | CIA-48 | BRL-CAD: 03brlcad * r47087 10/brlcad/trunk/NEWS: (log message trimmed) |
| 04:07.55 | CIA-48 | BRL-CAD: richard also added new options to the g-vrml exporter. to quote: Significate |
| 04:07.55 | CIA-48 | BRL-CAD: updates to the 'g-vrml' converter. Some logic bugs were fixed. Triangulation was |
| 04:07.55 | CIA-48 | BRL-CAD: changed to use 'nmg_triangulate_model' instead of its own function which was |
| 04:07.55 | CIA-48 | BRL-CAD: very limited. Added two new options. A '-b' option to perform a bot dump (all |
| 04:07.55 | CIA-48 | BRL-CAD: csg geometry is ignored) and '-e' to perform an evaluation or all opjects |
| 04:07.56 | CIA-48 | BRL-CAD: including bots. By default bots are dumped and csg evaluation is perform |
| 06:39.32 | *** join/#brlcad pacman87 (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net) | |
| 06:40.34 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 06:40.53 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 09:42.16 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 11:01.31 | CIA-48 | BRL-CAD: 03abhi2011 * r47088 10/brlcad/trunk/src/libged/simulate/simulate.c: Added code to display the normals generated at each manifold |
| 11:48.05 | CIA-48 | BRL-CAD: 03tbrowder2 * r47089 10/brlcad/trunk/HACKING: add comma |
| 12:24.16 | CIA-48 | BRL-CAD: 03abhi2011 * r47090 10/brlcad/trunk/src/libged/simulate/simutils.c: Number of functions hitting the roof, moving utility stuff out to seperate file |
| 12:24.47 | CIA-48 | BRL-CAD: 03abhi2011 * r47091 10/brlcad/trunk/src/libged/simulate/simutils.h: Number of functions hitting the roof, moving utility stuff out to separate file |
| 12:26.15 | CIA-48 | BRL-CAD: 03abhi2011 * r47092 10/brlcad/trunk/src/libged/ (CMakeLists.txt simulate/simulate.c): Modified simulate.c to use the the utils from the utility files now and some related cmake changes |
| 13:20.42 | CIA-48 | BRL-CAD: 03abhi2011 * r47093 10/brlcad/trunk/src/libged/simulate/ (simulate.c simutils.c simutils.h): Corrected some code related to prefixing names |
| 13:46.48 | CIA-48 | BRL-CAD: 03bob1961 * r47094 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Added ArcherCore::redrawWho. |
| 13:52.04 | CIA-48 | BRL-CAD: 03bob1961 * r47095 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: |
| 13:52.04 | CIA-48 | BRL-CAD: Added a tool panel to the attributes view panel and initially populated it with |
| 13:52.04 | CIA-48 | BRL-CAD: a set of component pick mode radiobuttons and a few bot related buttons for |
| 13:52.04 | CIA-48 | BRL-CAD: splitting, syncing and/or flipping bots. Added a radiobutton to the attribute |
| 13:52.04 | CIA-48 | BRL-CAD: view's toolbar and updated the images associated with the buttons. |
| 13:56.28 | CIA-48 | BRL-CAD: 03bob1961 * r47096 10/brlcad/trunk/src/tclscripts/archer/images/ (5 files): Added tools.png and option_edit.png. Removed option_tree.png. Updated option_text.png |
| 14:30.22 | brlcad | abhi2011: you have a series of memory leaks in the simulate code |
| 14:31.11 | brlcad | if you know how to run valgrind or some other memory debugger, it'd probably be a good time to clean up memory management |
| 14:31.35 | brlcad | basically for every bu_malloc/bu_calloc there needs to be a corresponding bu_free call |
| 14:32.03 | brlcad | and for every bu_vls, there needs to be a bu_vls_free() call |
| 14:32.36 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 14:37.06 | CIA-48 | BRL-CAD: 03brlcad * r47097 10/brlcad/trunk/NEWS: |
| 14:37.06 | CIA-48 | BRL-CAD: bob added a new panel (and menu) of edit pick options to archer for cleaning up |
| 14:37.06 | CIA-48 | BRL-CAD: non-solid BoT geometry. initially populated it with a set of component pick |
| 14:37.06 | CIA-48 | BRL-CAD: mode radiobuttons and a few bot related buttons for splitting, syncing and/or |
| 14:37.06 | CIA-48 | BRL-CAD: flipping bots. |
| 14:40.59 | brlcad | starseeker: browder's latest reminds me that cmake should be doing a test for perl existence if it's not already, and disabling docs if it doesn't exist (assuming perl is used in any fashion) |
| 15:13.13 | starseeker | brlcad: I just this second (literally, within the minute ;-) got a pdf build with the covers using just CMake and templates :-) |
| 15:13.43 | starseeker | let me commit and we'll see what he thinks |
| 15:21.47 | CIA-48 | BRL-CAD: 03starseeker * r47098 10/brlcad/trunk/doc/docbook/ (3 files in 2 dirs): Add CMake logic to support the covers on the Tutorial volumes. |
| 15:30.53 | abhi2011 | brlcad: yes, i was trying pinpoint them using valgrind yesterday |
| 15:31.22 | abhi2011 | haven't quite figured out which functions exactly yet |
| 15:34.13 | abhi2011 | any easier tool that can be used to detect the region of code whr leaks are happening |
| 15:40.51 | CIA-48 | BRL-CAD: 03brlcad * r47099 10/brlcad/trunk/NEWS: |
| 15:40.51 | CIA-48 | BRL-CAD: the obj-g importer has gotten lots of love and attention from nick and richard |
| 15:40.51 | CIA-48 | BRL-CAD: over the past year. none of it was user-visible until very recently, so begin |
| 15:40.51 | CIA-48 | BRL-CAD: documenting the changes. bigger announcement will get added on the next minor |
| 15:40.51 | CIA-48 | BRL-CAD: bump summarizing the new importer. |
| 15:44.46 | brlcad | abhi2011: valgrind is about as good as it gets :) |
| 15:45.08 | brlcad | it tells you exactly where the allocation occurred that wasn't released |
| 15:45.46 | brlcad | one place, for example, is a function you wrote that adds a prefix -- it creates a vls, prints into it, then returns the char * to that vls |
| 15:46.04 | CIA-48 | BRL-CAD: 03starseeker * r47100 10/brlcad/trunk/doc/docbook/CMakeLists.txt: handle brlcad.css |
| 15:46.06 | brlcad | once you leave that function, you no longer have access to that vls, so you cannot call bu_vls_free() to properly release the memory allocated |
| 15:47.20 | brlcad | best is to probably return the vls* instead of a char* so you can free it later |
| 15:47.28 | abhi2011 | yes |
| 15:47.51 | brlcad | or just start with a vls beforehand |
| 15:47.56 | brlcad | then you don't even need that function |
| 15:47.57 | abhi2011 | was thinking something might be wrong with that, due to the cha* inside |
| 15:48.07 | brlcad | it's basically a one-liner print |
| 15:48.30 | abhi2011 | yes, that would be better |
| 15:48.44 | abhi2011 | the linked lists should be ok though |
| 15:48.48 | abhi2011 | there is 1 big list |
| 15:48.50 | starseeker | woo hoo! |
| 15:48.53 | abhi2011 | for the rigd bodies |
| 15:49.01 | abhi2011 | and another for the manifolds |
| 15:49.36 | brlcad | starseeker: what was the last/current status on the exists command? is it in there usable now, or not yet? |
| 15:49.37 | abhi2011 | i think the last iteration , causes the manifold list to not be freed |
| 15:50.03 | starseeker | um, iirc it's usable but still very basic |
| 15:50.05 | brlcad | manual linked list or a bu_list ? |
| 15:50.13 | brlcad | starseeker: that's fine - but it's there? |
| 15:50.18 | starseeker | nods |
| 15:50.20 | abhi2011 | manual linked list |
| 15:50.21 | brlcad | ok |
| 15:50.43 | starseeker | man page is a lier at the moment because I was trying to outline all the eventual planned features |
| 15:51.04 | brlcad | what was the original command name from bob? was it test? |
| 15:51.07 | starseeker | *might* have basic boolean operations going, but not sure how robust that'll be |
| 15:51.18 | starseeker | urm |
| 15:51.29 | starseeker | don't recall - I can ask him later today |
| 15:51.33 | brlcad | 'urm' is a funny command name :) |
| 15:51.38 | starseeker | hehe |
| 15:51.44 | starseeker | good alias for help |
| 15:52.04 | starseeker | is at home at the moment - needed the flexible setup for Apache FOP stuff |
| 15:52.27 | brlcad | nods, no worry -- just getting a commit message worded right |
| 15:52.45 | starseeker | I think it's in the commit history |
| 15:53.06 | starseeker | LOL - "Ubuntu" - an African word meaning "Gentoo is too hard for me". |
| 15:53.28 | CIA-48 | BRL-CAD: 03brlcad * r47101 10/brlcad/trunk/NEWS: |
| 15:53.28 | CIA-48 | BRL-CAD: sparked by a new testing command added by bob parker, cliff stubbed in initial |
| 15:53.29 | CIA-48 | BRL-CAD: functionality for a new 'exists' command. this command is intended to be a |
| 15:53.29 | CIA-48 | BRL-CAD: corollary to the unix 'test' command with features for detecting various |
| 15:53.29 | CIA-48 | BRL-CAD: geometry conditions and expressions |
| 15:56.25 | CIA-48 | BRL-CAD: 03brlcad * r47102 10/brlcad/trunk/BUGS: make a note, exists documentation claims more than is possible |
| 16:09.25 | CIA-48 | BRL-CAD: 03brlcad * r47103 10/brlcad/trunk/BUGS: bot bbox routine isn't calculating the bbox correctly |
| 16:12.13 | CIA-48 | BRL-CAD: 03brlcad * r47104 10/brlcad/trunk/NEWS: by converting the flex/bison logic to re2c/lemon, that effectively ported the obj-g importer to windows since it can now be compiled without the flex/bison dependency. |
| 16:17.31 | CIA-48 | BRL-CAD: 03brlcad * r47105 10/brlcad/trunk/NEWS: |
| 16:17.31 | CIA-48 | BRL-CAD: a lot of fingers have been in the obj-g pie. document the new obj parser |
| 16:17.31 | CIA-48 | BRL-CAD: engine, originally written by mike tegtmeyer, integrated by richard weiss, and |
| 16:17.31 | CIA-48 | BRL-CAD: rewritten/translated by nicholas reed. the fact that it's a structured parser |
| 16:17.31 | CIA-48 | BRL-CAD: improves parsing robustness. |
| 16:18.29 | brlcad | whew.. only 218 to go |
| 16:22.23 | CIA-48 | BRL-CAD: 03brlcad * r47106 10/brlcad/trunk/NEWS: abhijit nandy (abhi2011) fixed an mged crash where bad things happened if you killed an object that was illuminated for editing. no longer crashes by testing for NULL. |
| 16:23.22 | abhi2011 | naaaaece :) |
| 16:25.17 | CIA-48 | BRL-CAD: 03brlcad * r47107 10/brlcad/trunk/NEWS: |
| 16:25.17 | CIA-48 | BRL-CAD: abhijit nandy added a new 'simulate' command to mged/archer that allows applying |
| 16:25.17 | CIA-48 | BRL-CAD: physical interactions such as gravity, friction, and linear/angular |
| 16:25.17 | CIA-48 | BRL-CAD: accelleration forces. this is anticipatory documentation for the next minor |
| 16:25.17 | CIA-48 | BRL-CAD: release bump, but warrants a paragraph highlight with additional detail. |
| 16:27.00 | abhi2011 | *acceleration |
| 16:56.35 | CIA-48 | BRL-CAD: 03brlcad * r47108 10/brlcad/trunk/src/librt/db_path.c: add common footer, update style |
| 17:03.31 | brlcad | abhi2011: heh, noted |
| 17:15.57 | CIA-48 | BRL-CAD: 03abhi2011 * r47109 10/brlcad/trunk/src/libged/simulate/ (simulate.c simutils.c simutils.h): Got rid of the prefix_name function which was hogging memory, directly using bu_vls instead |
| 17:32.59 | brlcad | abhi2011: heh, looks much better .. though you could have just named your vls strings prefixed_reg_name or whatever instead of having a separate pointer for the char* |
| 17:33.39 | brlcad | vls ARE strings |
| 17:34.37 | abhi2011 | yeah I can do that, since I only need the actual pointer when passing command arguments |
| 17:34.44 | abhi2011 | the char* I mean |
| 17:35.03 | brlcad | nods |
| 17:39.20 | CIA-48 | BRL-CAD: 03brlcad * r47110 10/brlcad/trunk/src/librt/ (CMakeLists.txt Makefile.am parse.c): wow, duplicate file ignored (yet updated and maintained) for many years that doesn't even belong in here any longer. the struct parsing functions were migrated to libbu a long time ago, so delete this remnant file. |
| 18:04.15 | CIA-48 | BRL-CAD: 03brlcad * r47111 10/brlcad/trunk/src/librt/uvpoints.cpp: add missing footer, update style and ws |
| 18:08.21 | CIA-48 | BRL-CAD: 03brlcad * r47112 10/brlcad/trunk/src/librt/ (26 files): comment cleanup, remove F U N C T I O N _ N A M E S written out in comments since the reasoning becomes moot with the migration of comments into headers and automatic doxygen parsing. |
| 18:09.32 | CIA-48 | BRL-CAD: 03brlcad * r47113 10/brlcad/trunk/src/librt/ (23 files): sweepting ws style indent and comment cleanup |
| 18:56.23 | *** join/#brlcad pacman87 (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net) | |
| 19:30.12 | CIA-48 | BRL-CAD: 03bob1961 * r47114 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Minor tweak to Archer::handleTreeSelect. |
| 19:35.23 | ``Erik | brlcad: bob is reporting issues with libged bot_* stuff on windows, it's doing bu_basename() on db stuff, which uses / on all platforms |
| 19:55.06 | brlcad | ``Erik: ahhh, yes... that's because bu_basename() was changed to NOT use / on all platforms ... |
| 19:55.25 | brlcad | it was / .. and my mod would have worked |
| 19:55.53 | brlcad | but I think he changed it to the platform's dir separator a while back, forgot about that |
| 19:55.56 | brlcad | I'll revert |
| 20:01.45 | ``Erik | bu_db_basename() ? |
| 20:04.34 | CIA-48 | BRL-CAD: 03bob1961 * r47115 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Tweaked Archer::pluginLoader to accomodate spaces in a filename. |
| 20:05.15 | CIA-48 | BRL-CAD: 03brlcad * r47116 10/brlcad/trunk/src/libged/ (bot_flip.c bot_split.c bot_sync.c): revert the bu_basename() modification, back to r47050, since that function was updated to not only handle '/' but whatever the platform separator is. sorry bob. |
| 20:11.48 | starseeker | or just db_basename, since it's for .g files? |
| 20:23.27 | ``Erik | <-- fond of the library prefix munge |
| 20:39.10 | CIA-48 | BRL-CAD: 03abhi2011 * r47117 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simulate.c simulate.h simutils.c): Converted some strings to vls |
| 21:00.45 | *** join/#brlcad mattS_ (cb3af1be@gateway/web/freenode/ip.203.58.241.190) | |
| 21:05.26 | brlcad | hm, it might be as simple as keeping support for '/' in basename |
| 21:06.21 | brlcad | it would basically mean we wouldn't allow windows files with a / in the file name, which I don't think windows allows either |
| 21:29.40 | ``Erik | dos used / as a mandatory switch, "dir/w" |
| 21:29.47 | ``Erik | d'no about nt variants |
| 21:43.26 | brlcad | sure, but still wouldn't be in a path |
| 21:44.06 | brlcad | this is isolated to places that would call basename()/dirname() feeding a path |
| 21:45.38 | brlcad | given we're not implementing dir with /switches, should be a safe assumption |
| 22:22.39 | CIA-48 | BRL-CAD: 03brlcad * r47118 10/brlcad/trunk/src/libbu/test_basename.c: add a few more tests to make sure we get reasonable (dos-style) drive prefix behavior |
| 22:36.10 | CIA-48 | BRL-CAD: 03brlcad * r47119 10/brlcad/trunk/ (include/bu.h src/libbu/basename.c): (log message trimmed) |
| 22:36.10 | CIA-48 | BRL-CAD: enhanced bu_basename(), now with more slashy flavor. always interprets '/' as a |
| 22:36.10 | CIA-48 | BRL-CAD: path separator in addition to whatever the native separator is so that we can |
| 22:36.10 | CIA-48 | BRL-CAD: use libbu for geometry paths as well as filesystem paths. also added a quick |
| 22:36.11 | CIA-48 | BRL-CAD: check to make sure drive paths are removed if this is windows so we don't get |
| 22:36.11 | CIA-48 | BRL-CAD: the drive letter returned as a path. also started to add code to recognize |
| 22:36.12 | CIA-48 | BRL-CAD: escaped paths but it turns out that the system basename() (bsd/mac) doesn't |
| 22:36.15 | brlcad | there, now it should work |
| 22:38.50 | CIA-48 | BRL-CAD: 03brlcad * r47120 10/brlcad/trunk/src/libged/ (bot_flip.c bot_split.c bot_sync.c): unrevert the r47116 revert of r47050, making the routines use bu_basename() for path trimming instead of rolling custom. does that fix it, bob? |
| 23:24.00 | starseeker | growls... the hacked up hv3 tcl/tk html browsers we've been using aren't going to cut it when we add .css files into the mix, looks like |
| 23:24.16 | starseeker | should just get the full browser working... |
| 23:24.48 | brlcad | or a Qt HTML window/app for down the road |
| 23:25.11 | starseeker | eventually sure, but right now we don't want to add Qt as a requirement for help... |
| 23:25.42 | starseeker | has had the full hv browser running in the past - thought I could "streamline" it down to just what we need but apparently that's not so simple |
| 23:25.51 | CIA-48 | BRL-CAD: 03brlcad * r47121 10/brlcad/trunk/src/libbu/basename.c: simplify, just call bu_strdup() like bu_dirname() does |
| 23:26.59 | starseeker | I suppose there's no particular reason *not* to have http support... |
| 23:28.49 | starseeker | oh, well - I guess this is a good time to move the hv3 code back into src/other too |
| 23:57.39 | CIA-48 | BRL-CAD: 03brlcad * r47122 10/brlcad/trunk/src/libbu/test_basename.c: couple more test cases, make sure escaping behavior works as expected (more important on windows where it becomes a dir separator). |
| 00:02.12 | CIA-48 | BRL-CAD: 03brlcad * r47123 10/brlcad/trunk/src/libbu/ (Makefile.am test_dirname.c): add in a new unit test for bu_dirname() similar to bu_basename(). |
| 00:03.40 | CIA-48 | BRL-CAD: 03brlcad * r47124 10/brlcad/trunk/src/libbu/CMakeLists.txt: enable logic for new test_dirname binary. also removing what should be unnecessary link libraries (htond doesn't use libpng) and comment on bad MSVC platform toggle. |
| 00:06.07 | CIA-48 | BRL-CAD: 03brlcad * r47125 10/brlcad/trunk/src/libbu/dirname.c: |
| 00:06.07 | CIA-48 | BRL-CAD: similar to bu_basename(), make bu_dirname() also always treat unix-style '/' |
| 00:06.07 | CIA-48 | BRL-CAD: forward slashes as path separators even on platforms that use a different |
| 00:06.07 | CIA-48 | BRL-CAD: directory separator (windows). that will make the function continue to be |
| 00:06.07 | CIA-48 | BRL-CAD: useful for geometry paths, which are always url/unix-style. fixed a bug |
| 00:06.08 | CIA-48 | BRL-CAD: detected during unit testing while at it, collapsing sequences of trailing path |
| 00:06.09 | CIA-48 | BRL-CAD: separators to just one. |
| 00:18.30 | CIA-48 | BRL-CAD: 03brlcad * r47126 10/brlcad/trunk/include/bu.h: document the new bu_dirname() particulars as well as cleaning up the wording on bu_basename() too to be consistent. |
| 00:19.23 | CIA-48 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3174 10/wiki/User:Abhijit: /* Log */ |
| 00:20.54 | CIA-48 | BRL-CAD: 03brlcad * r47127 10/brlcad/trunk/include/bu.h: how about an informative parameter name |
| 00:21.14 | *** join/#brlcad pacman87 (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net) | |
| 00:25.09 | CIA-48 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3175 10/wiki/User:Abhijit: /* Updated Development Time line(Sept 14th) */ |
| 00:26.03 | CIA-48 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3176 10/wiki/User:Abhijit: /* Updated Development Time line(Sept 14th) */ |
| 00:27.32 | CIA-48 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3177 10/wiki/User:Abhijit: /* Detailed project description */ |
| 00:30.22 | abhi2011 | Normals and contact manifolds getting drawn ok now : http://postimage.org/image/2dqu5964k/full/ |
| 00:30.42 | CIA-48 | BRL-CAD: 03brlcad * r47128 10/brlcad/trunk/NEWS: minor code, but technically user-visible -- archer will now load plugins with spaces in the name. |
| 00:30.54 | abhi2011 | These are still bullet output, have to convert to raytrace yet |
| 01:01.26 | CIA-48 | BRL-CAD: 03abhi2011 * r47129 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h): Began implementing a raytrace based manifold generator |
| 01:07.34 | CIA-48 | BRL-CAD: 03abhi2011 * r47130 10/brlcad/trunk/src/libged/ (CMakeLists.txt simulate/simulate.c simulate/simulate.h): Related changes to simulate command to use the raytraced manifolds |
| 01:33.59 | brlcad | cool |
| 02:12.36 | *** join/#brlcad mattS_ (cb3af1be@gateway/web/freenode/ip.203.58.241.190) | |
| 02:48.49 | CIA-48 | BRL-CAD: 03brlcad * r47131 10/brlcad/trunk/NEWS: |
| 02:48.49 | CIA-48 | BRL-CAD: richard fixed a bug which caused a seg fault if a loopuse contained a single |
| 02:48.49 | CIA-48 | BRL-CAD: vertex instead of an edgeuse. presumably this improves a tess case where |
| 02:48.49 | CIA-48 | BRL-CAD: invalid geometry ends up in a loopuse that would later result in a bomb or |
| 02:48.49 | CIA-48 | BRL-CAD: crash. |
| 03:10.26 | CIA-48 | BRL-CAD: 03brlcad * r47132 10/brlcad/trunk/TODO: need to rerun previous conversion comparison to see how things have changed with all of the recent NMG changes |
| 03:23.16 | starseeker | hmm: http://www.xmailserver.org/xdiff-lib.html |
| 03:29.28 | starseeker | http://code.google.com/p/dtl-cpp/ |
| 03:32.50 | CIA-48 | BRL-CAD: 03brlcad * r47133 10/brlcad/trunk/TODO: need to test the new edit command. |
| 04:13.55 | CIA-48 | BRL-CAD: 03brlcad * r47134 10/brlcad/trunk/NEWS: richard fixed a bug in mged's mater command (in r45415) where the inheritance could not be changed unless the color is changed at the same. should affect archer too, but only tested with mged. |
| 04:16.56 | CIA-48 | BRL-CAD: 03brlcad * r47135 10/brlcad/trunk/NEWS: |
| 04:16.56 | CIA-48 | BRL-CAD: richard also committed a fix to a bug in the rm/erase command affecting at least |
| 04:16.56 | CIA-48 | BRL-CAD: mged and presumably archer too. A segmentation fault would occur when a region |
| 04:16.56 | CIA-48 | BRL-CAD: is displayed in 'mged' and the 'rm' command is used to remove a member of the |
| 04:16.56 | CIA-48 | BRL-CAD: displayed region and the member occurs in the region more than once. |
| 04:28.10 | CIA-48 | BRL-CAD: 03brlcad * r47136 10/brlcad/trunk/src/libgcv/bottess.c: there's no need to call rt_bot_ifree2() directly. create an rt_db_internal with the right juju and we can call rt_bot_ifree() which will call ifree2 for us. no more wet shoes. |
| 04:29.24 | CIA-48 | BRL-CAD: 03brlcad * r47137 10/brlcad/trunk/src/libgcv/ (bottess.c region_end_mc.c): ws |
| 04:34.32 | CIA-48 | BRL-CAD: 03brlcad * r47138 10/brlcad/trunk/src/librt/primitives/bot/bot.c: And lead us not into temptation, but deliver us from evil. rename rt_bot_ifree2() to bot_ifree2() so it's not considered public api. in fact, mark it hidden too. |
| 04:38.22 | CIA-48 | BRL-CAD: 03brlcad * r47139 10/brlcad/trunk/NEWS: |
| 04:38.23 | CIA-48 | BRL-CAD: richard made a slew of changes to improve NMG processing which have been |
| 04:38.23 | CIA-48 | BRL-CAD: enabled, but not yet independently validated so schedule their announcement in |
| 04:38.23 | CIA-48 | BRL-CAD: the next minor bump. one specific example is r45358 where he improved the |
| 04:38.23 | CIA-48 | BRL-CAD: success of boolean ops when there coplanar faces. this affects mged |
| 04:38.23 | CIA-48 | BRL-CAD: tessellation commands (facetize, E, ev) as well as most of our exporters. |
| 04:40.22 | CIA-48 | BRL-CAD: 03brlcad * r47140 10/brlcad/trunk/NEWS: another category of changes richard made centered around improving boolean evaluation and NMG processing performance. don't yet have specific numbers, but document the changes anyways (see r45319) |
| 04:46.01 | CIA-48 | BRL-CAD: 03brlcad * r47141 10/brlcad/trunk/src/librt/CMakeLists.txt: is this why autotools is still catching more errors that cmake build? remove the -Wno-error flag from non-static compilation. |
| 04:52.58 | CIA-48 | BRL-CAD: 03brlcad * r47142 10/brlcad/trunk/NEWS: cliff improved the mged/archer 'attr' command to only halt on read-only databases if it's a write attr action. allow get/list/show |
| 04:55.36 | CIA-48 | BRL-CAD: 03brlcad * r47143 10/brlcad/trunk/NEWS: cliff improved the mged/archer 'attr' command to only halt on read-only databases if it's a write attr action. allow get/list/show. credited to the .0 release. |
| 04:58.04 | CIA-48 | BRL-CAD: 03brlcad * r47144 10/brlcad/trunk/NEWS: |
| 04:58.04 | CIA-48 | BRL-CAD: bob worked around some glitches with the windows gl display manager by copying |
| 04:58.04 | CIA-48 | BRL-CAD: display list data into a GLdouble array before sending to opengl (r44645) |
| 04:58.04 | CIA-48 | BRL-CAD: remedying strange behavior on windows where arrows were sometimes being drawn |
| 04:58.04 | CIA-48 | BRL-CAD: incorrectly. sounds like corrupt memory, but this works around the issue |
| 04:58.05 | CIA-48 | BRL-CAD: successfull. |
| 05:07.26 | CIA-48 | BRL-CAD: 03brlcad * r47145 10/brlcad/trunk/NEWS: keith improved the step-g importer fixing some issues importing ellipse and circle conics. another user-visible change that didn't make the .0 release notes. |
| 05:09.55 | CIA-48 | BRL-CAD: 03brlcad * r47146 10/brlcad/trunk/NEWS: keith also improved the step-g importer presumably preventing it from crashing or otherwise doing bad things where it was overrunning an array during cubit interpolation. another undocumented change to the .0 release. |
| 05:12.24 | brlcad | starseeker: r44618 looks no good. if we don't have a void* then the void* test is flawed... that's kinda important to just gloss over it with a conditional.. |
| 05:16.34 | brlcad | starseeker: hm, looks like that was later fixed? (apologies, reading commits in reverse) |
| 05:17.47 | brlcad | i think what triggered caution is that I think I've seen the fallback case where it spits out "CMAKE_SIZEOF_VOID_P is not defined - assuming 32 bit platform" and that just shouldn't happen for any platform less than two decades old |
| 05:24.49 | brlcad | wasn't even you that made the original patch .. so that's probably a cue that my eyes are getting tired and need a walkabout break |
| 05:32.53 | CIA-48 | BRL-CAD: 03brlcad * r47147 10/brlcad/trunk/misc/CMake/BRLCAD_CompilerFlags.cmake: ffast-math is never a good option for our code because the math that results is extremely unstable an unreliable for useful calculations. |
| 05:58.43 | CIA-48 | BRL-CAD: 03brlcad * r47148 10/brlcad/trunk/src/librt/uvpoints.cpp: big cleanup. remove 'using namespace std' abomination, quell warnings, fix shadowings, and more. |
| 06:03.35 | *** join/#brlcad pacman87 (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net) | |
| 06:08.33 | brlcad | pacman87: you still on the dev mailing list? question posed by the guy you referred in here about how exactly the ray path is hyperbolic |
| 06:09.26 | brlcad | starseeker: better question, r44413 .. curious that black is not being written out. the default color is actually white, so does that mean I can't create black objects? :) |
| 06:10.16 | brlcad | starseeker: and AGAIN.. I see that you noticed the err in r44414! .. okay, I'll stop :) |
| 06:11.11 | brlcad | needs to learn that there's probably a follow-up commit that addresses the red flag |
| 06:35.07 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 06:40.43 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 08:25.26 | pacman87 | brlcad: it looks like d_rossberg has answered it fairly well, were there any specific points that still need to be addressed? |
| 08:27.30 | pacman87 | http://en.wikipedia.org/wiki/Skew_lines#Skew_lines_and_ruled_surfaces might also be useful |
| 10:47.33 | abhi2011 | is it possible to specify a rectangular grid of rays to be shot in a specific direction |
| 10:47.58 | abhi2011 | rather than shooting the rays one by one, translating the direction across and up/down |
| 11:23.30 | *** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz) | |
| 11:23.46 | pawleeq | hello |
| 11:24.58 | pawleeq | I am building current svn check and make ended with errors: http://pastebin.com/jrejqagB |
| 11:49.16 | CIA-48 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3178 10/wiki/User:Abhijit: /* Log */ |
| 12:03.42 | CIA-48 | BRL-CAD: 03abhi2011 * r47149 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simutils.c simutils.h): Added initial code to create the AABB overlap regions |
| 12:33.31 | d_rossberg | pawleeq: Makefile.am is out of date in src/tclscripts/archer/images but CMake should work |
| 12:39.33 | pawleeq | d_rossberg: i tried cmake brlcad, but cmake also failed, result is here: http://pastebin.com/GPfiMqXs |
| 12:46.32 | d_rossberg | i may only guess what's wrong: sometimes cmake needs to run twice; i've no *nix brl-cad at hand to test it |
| 12:56.24 | CIA-48 | BRL-CAD: 03abhi2011 * r47150 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simulate.c simutils.c): Finished creating the AABB overlap regions |
| 13:37.23 | CIA-48 | BRL-CAD: 03abhi2011 * r47151 10/brlcad/trunk/src/libged/simulate/ (5 files): Merged bullet and rt manifold info in 1 structure, easier that way |
| 13:49.37 | CIA-48 | BRL-CAD: 03n_reed * r47152 10/brlcad/trunk/src/other/step/src/express/expparse_new.y: working through type-mismatch compile errors |
| 13:54.19 | abhi2011 | pawleeq: you need to install ITK |
| 13:54.34 | abhi2011 | thats the object oriented extension to tcl/tk |
| 13:55.02 | abhi2011 | then the ITK_LIBRARY path will be set to the .so files which implements that library |
| 13:56.08 | brlcad | except we bundle itk so something else seems to be going wrong, unless it's using an incompatible system tcl/tk |
| 13:56.17 | starseeker | binks - that shouldn't happen... |
| 13:56.35 | starseeker | pawleeq: can you post your configure log? |
| 13:57.39 | starseeker | we really really really really need to get package require Itk working from bwish and friends |
| 13:58.03 | abhi2011 | hmm then maybe he is not building itk during make |
| 13:58.20 | starseeker | no, it's not finding the ITK library |
| 13:58.39 | starseeker | but it must be finding the Itk package itself, othewise it should have been turned on |
| 13:59.53 | starseeker | my best guess is that line 339 in src/other/CMakeLists.txt isn't succeeding |
| 14:00.55 | starseeker | pawleeq: where is the libitk.so on your system? |
| 14:01.29 | starseeker | if they stuck it in a weird place, that would explain the ITK_LIBRARY issue |
| 14:02.27 | starseeker | we're not set up for it right now, but I suppose what I should be doing in those special cases is to build the local one in the case of ITCL_LIBRARY or ITK_LIBRARY not being found |
| 14:03.13 | starseeker | it breaks the paradigm being used for all the other Tcl/Tk packages, but it looks like I may not have a choice since the ITK_LIBRARY issue has appeared in the wild |
| 14:03.34 | starseeker | pawleeq: if you want to work around it, you can just feed cmake -DBRLCAD_BUNDLED_LIBS=Bundled |
| 14:04.36 | CIA-48 | BRL-CAD: 03erikgreenwald * r47153 10/brlcad/trunk/src/libgcv/wfobj/tri_face.c: common.h needs to come before bu.h |
| 14:14.24 | CIA-48 | BRL-CAD: 03starseeker * r47154 10/brlcad/trunk/src/other/CMakeLists.txt: Make a stab at turning Itcl/Itk back on if we can't find the libraries. |
| 14:14.38 | starseeker | ew |
| 14:14.44 | starseeker | pawleeq: see if that helps... |
| 14:16.36 | starseeker | might end up having to build both Itcl and Itk if ITK_LIBRARY doesn't show up... |
| 14:39.14 | pawleeq | starseeker: I will give it try and report back, but right now I am babysittter rather than brlcad enthusiast :) |
| 14:46.05 | CIA-48 | BRL-CAD: 03erikgreenwald * r47155 10/brlcad/trunk/ (NEWS src/tclscripts/mged/reid.tcl): return last assigned id value from reid command |
| 15:28.16 | CIA-48 | BRL-CAD: 03erikgreenwald * r47156 10/brlcad/trunk/ (NEWS src/tclscripts/mged/reid.tcl): Added a -n <val> arg to reid for incrementing by a specified value. |
| 15:48.08 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 16:56.53 | CIA-48 | BRL-CAD: 03n_reed * r47157 10/brlcad/trunk/src/other/step/src/express/ (CMakeLists.txt expparse_new.y): got lemon source compiling; not yet operational |
| 17:04.51 | pawleeq | starseeker: so the workaround with cmake -DBRLCAD_BUNDLED_LIBS=Bundled failed this way: http://pastebin.com/VmDaFq7L |
| 17:09.13 | pawleeq | starseeker: pastebin does not accept my, so I uploaded it here: www.pawleeq.com/config.log |
| 18:10.43 | abhi2011 | whats is the use of the ap.a_uptr = (genptr_t)a_tab.attrib; while initializing the struct application ap; in nirt |
| 18:10.57 | abhi2011 | is it used to specifiy some special attributes |
| 18:11.25 | abhi2011 | was wondering if I can NOT set it and just use the rest of the application structure |
| 18:26.33 | CIA-48 | BRL-CAD: 03abhi2011 * r47158 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simulate.c): Added initial code to shoot rays during manifold generation |
| 18:30.06 | *** join/#brlcad pacman87 (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net) | |
| 19:36.54 | *** join/#brlcad pacman87 (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net) | |
| 21:11.06 | CIA-48 | BRL-CAD: 03abhi2011 * r47159 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simutils.c): Trying to get the overlap points by shooting raysat the AABB overlap region |
| 21:39.03 | abhi2011 | that is strange, just compiled bullet to use double precision , and bullet compiled fine |
| 21:39.12 | abhi2011 | the demos of bullet are also running |
| 21:39.17 | abhi2011 | however mged crashes |
| 21:39.26 | abhi2011 | inside the bullet related code |
| 21:39.44 | abhi2011 | specifically when allocating memory for a particular bullet object |
| 21:41.08 | abhi2011 | http://bin.cakephp.org/view/1090178448 |
| 21:41.24 | abhi2011 | the crash seems to be in malloc |
| 21:52.03 | abhi2011 | hmm tried a clean build but that didnt work either, I ll switch bullet back to single precision, maybe malloc is unable to allocate 64 bits |
| 21:52.19 | abhi2011 | though I dont know how the demos work then |
| 22:09.23 | abhi2011 | now it works fine again after switching back to single precision! |
| 22:36.54 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 23:53.56 | *** join/#brlcad pacman87 (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net) | |
| 00:43.55 | CIA-48 | BRL-CAD: 03abhi2011 * r47160 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simutils.c): Began to actually shoot rays towards simulation geometry, needs some debugging(issues during memory cleanup) |
| 00:45.44 | CIA-48 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3179 10/wiki/User:Abhijit: /* Log */ |
| 02:14.18 | CIA-48 | BRL-CAD: 03starseeker * r47161 10/brlcad/trunk/misc/CMake/FindLEMON.cmake: Hmm. Don't try moving things if source and destination are the same... |
| 02:14.42 | starseeker | bet that's what pawleeq hit |
| 02:48.39 | brlcad | abhi2011: your build is lacking debug information -- you should get a much more informative crash report, but what's there obviously indicates memory management gone bad |
| 02:49.15 | brlcad | switching to single precision more than likely just changes memory alignment so you just happen to avoid the crash, but the problem is still there -- just not provoking a crash (yet) |
| 02:49.58 | brlcad | if you run valgrind, it will report all of the allocation problems (you should have a perfectly clean report except for one or two structures in librt |
| 02:50.38 | starseeker | woot - got the hv3 browser up and running again. this time I'll try and work with it instead of gutting it :-) |
| 02:50.49 | brlcad | the crash does shed light that the memory problem is not with brl-cad structures, but rather with some bullet or memory with one of your classes |
| 02:50.57 | brlcad | yay |
| 02:51.19 | brlcad | starseeker: be sure to bring an appetite.. there very well may be too much food |
| 02:51.26 | brlcad | might have to send people home with some :) |
| 02:51.29 | starseeker | hehe :-) |
| 02:51.56 | starseeker | everything coming together OK? |
| 02:52.26 | brlcad | as good as to be expected, it's a lot being coordinated |
| 02:52.31 | starseeker | nods |
| 02:53.01 | starseeker | hmm... actually, if this sucker works on Mac and Windows it could be a good "demo app" for the conference... |
| 02:53.01 | brlcad | nothing fancy, nice and casual, but there are a lot of things coming together and everything was too short notice to get into as much detail as we would have liked |
| 02:53.08 | brlcad | nods |
| 02:53.46 | starseeker | the new venue worked out? |
| 02:53.58 | starseeker | recalls concerns it might be too large... |
| 03:47.21 | brlcad | yeah, it'll be just fine |
| 03:51.36 | brlcad | not as neat as the boathouse, but in a really gorgeous garden area |
| 03:51.57 | brlcad | though we'll be indoors where it's cooler and bug free ;) |
| 06:04.21 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 07:04.42 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 08:33.12 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 10:10.17 | abhi2011 | a conference about to happen with lots of food I hear :) |
| 10:22.00 | *** join/#brlcad cvds (~leila@s537510ac.adsl.wanadoo.nl) | |
| 10:22.36 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 10:31.14 | cvds | Hello, I ma just starting with brl-cad and was wondering if one could reuse regions in different combinations where the regions would be in a different position ? |
| 13:18.11 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 14:02.15 | brlcad | cvds: absolutely |
| 14:03.29 | brlcad | basically you apply a matrix transformation to a parent combination |
| 14:03.44 | brlcad | see the oed tutorial/overview on the website for lots of examples and explanation |
| 14:05.14 | brlcad | if you have /some/path/to/region and /some/path/another/region where you want 'region' to be in different places for the 'to' and 'another' combinations, you'd run oed |
| 14:06.16 | brlcad | "oed /some/path/to region/down/towards/a/primitive" and "oed /some/path/another region/down/towards/a/primitive" would do the trick |
| 14:22.07 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 14:22.08 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 14:26.08 | cvds | brlcad: thanks! I shall check that tutorial after I finished thise goblet. (ota is one "interesting" command to specify on the command line btw) |
| 14:59.34 | cvds | now to find out why it wont render with rt .. |
| 15:00.25 | cvds | and now it works ... |
| 17:23.09 | cvds | It seems that I can not use the tra command to translate my solid using only the dz component (tra 0 0 0.5) Am I missing something ? |
| 17:50.50 | ``Erik | solids don't have translation matrices associated yet, what about putting your solid in a comb/region/assmbly, doing the tra on that, then doing an xpush to modify the solid directly? (if I grok right, I might not) |
| 18:04.00 | *** join/#brlcad pacman87 (~Timothy@adsl-208-191-158-89.dsl.hstntx.swbell.net) | |
| 18:05.37 | cvds | ``Erik: I see.. odd tho, since I can use tra if I make all arguments non-zero, would that be a fluke ? |
| 18:09.39 | ``Erik | I'm unqualified to say anything, there may be a bug :) I almost exclusively work in the low level C stuff and know nothing of the interface |
| 18:15.31 | cvds | I see :) .. and darn this tutorial document is vast |
| 18:30.39 | ``Erik | knowledgable people respond usually within ~24hr, so *shrug* ask and lurk :) |
| 18:31.44 | *** join/#brlcad merzo (~merzo@40-119-133-95.pool.ukrtel.net) | |
| 18:39.50 | abhi2011 | valgrind reports a lot of definitely lost memory for mged code |
| 18:40.04 | abhi2011 | I mean the normal execution code, without invoking simulate |
| 18:43.43 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 19:08.16 | abhi2011 | hmm after calling rt_free_rti(rtip), there are still some blocks reachable : by 0x70BC003: rt_free_rti (prep.c:159), 512 bytes in 1 blocks are still reachable in loss record 3,106 of 3,598, assuming this can be ignored as its some rt related structures |
| 19:16.25 | cvds | Riddle me this... according to the tutorial I should specify a command, but then I noticed that the result is different and it seems that I need to use the <v6.0 version of the command |
| 19:17.13 | cvds | however a mged -version gives me a 7.18.4 which seems to contradict the fact that I need the pre6.0 version. |
| 19:17.27 | cvds | command in question is inside |
| 19:33.26 | abhi2011 | hmm thats strange I have got reasonably valgrind-clean code now barring a few functions which are related to librt which are producing reachable/definitely lost blocks, but switching bullet to double precision still causes a crash : http://bin.cakephp.org/view/1315005894 |
| 19:35.01 | abhi2011 | seems there are some invalid writes by Bullet code |
| 20:17.24 | starseeker | cvds: there may be tutorial bugs |
| 20:17.51 | starseeker | the pdfs on the website are quite old, unfortuantely |
| 20:18.08 | starseeker | if you have specific issues, let us know and we'll try to clarify |
| 20:39.40 | cvds | starseeker: at the moment its mainly some parameter ordering that seems to be inconsistent. Only "odd" thing was the tra command not working for input: 0 0 0.5 in solid edit mode (sed). |
| 21:11.54 | CIA-48 | BRL-CAD: 03starseeker * r47162 10/brlcad/trunk/src/other/ (30 files in 12 dirs): Try to make the 8.5.9 tcl build logic look a little more like the latest 8.6b2 files. |
| 21:12.43 | *** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl) | |
| 21:14.39 | cvds_ | Good night all. This client will stay open so I can check the answers in the morning. |
| 21:29.45 | CIA-48 | BRL-CAD: 03n_reed * r47163 10/brlcad/trunk/src/other/step/src/ (4 files in 2 dirs): added new version of express.c with lemon parsing loop; building fedex_plus with lemon as well |
| 22:19.41 | CIA-48 | BRL-CAD: 03starseeker * r47164 10/brlcad/trunk/src/other/ (95 files in 7 dirs): |
| 22:19.41 | CIA-48 | BRL-CAD: Add the full hv3 browser to src/other - preliminary for switching from |
| 22:19.41 | CIA-48 | BRL-CAD: special-purpose man and help viewers to customizations of the more powerful hv3 |
| 22:19.41 | CIA-48 | BRL-CAD: browser. Prompted by the css additions to the Docbook output, but may also |
| 22:19.41 | CIA-48 | BRL-CAD: provide a text searching capability. |
| 22:20.02 | brlcad | "ota" ? |
| 22:22.14 | starseeker | ota? |
| 22:22.20 | brlcad | cvds_: huh, tra 0 0 0.5 should have worked -- sounds like maybe a bug got introduced recently |
| 22:22.36 | brlcad | 10:26 < cvds> brlcad: thanks! I shall check that tutorial after I finished thise goblet. (ota is one "interesting" command to specify on the command line btw) |
| 22:22.46 | starseeker | ah, found it |
| 22:22.51 | brlcad | don't know what ota is |
| 22:23.07 | starseeker | nods |
| 22:24.58 | brlcad | cvds_: you definitely don't need a pre6.0 version, but things certainly have changed a little since the tutorials were written so (very) minor changes (mostly syntactic) are to be expected -- some bugs in the documentation have already been fixed but we've not yet posted new versions of them onto the web (actively being worked on) |
| 22:25.30 | brlcad | that said, could try the 'translate' command instead of tra -- slightly different parameters, I believe using absolute positions instead of relative |
| 22:44.43 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 23:05.50 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 00:19.36 | *** join/#brlcad nsd (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 01:02.08 | CIA-48 | BRL-CAD: 03abhi2011 * r47165 10/brlcad/trunk/src/ (5 files in 2 dirs): Fixed list freeup issues for the overlap and hit list generated while shooting rays, also searched and destroyed some memory leaks |
| 01:52.04 | *** join/#brlcad nsd (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 02:30.43 | *** join/#brlcad nsd (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 03:57.31 | brlcad | abhi2011: nice set of memory fixes! |
| 03:57.43 | brlcad | is the valgrind close to clean? |
| 03:58.10 | brlcad | cleaning up the rtip is a known leak case (there's no free so librt doesn't know when to release the cpu-specific resources) |
| 05:26.15 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 06:18.45 | cvds_ | Good morning |
| 06:19.58 | cvds_ | brlcad: I meant eliptical torus (eto) |
| 06:21.15 | cvds_ | brlcad: indeed translate works fine. |
| 07:10.21 | cvds_ | Is there a way to multipane the attached X screen from mged -c ? |
| 11:22.59 | CIA-48 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3180 10/wiki/User:Abhijit: /* Log */ |
| 13:10.19 | brlcad | cvds_: yes and no |
| 13:11.39 | brlcad | cvds_: you can't mulitpane a plain attached X display, but you can get a multipane from -c |
| 13:11.49 | brlcad | if you run: set mged_default(multi_pane) 1 |
| 13:12.12 | brlcad | or turn on multipane on the menu or set it in your config file, whatever |
| 13:12.17 | brlcad | and then run "gui" |
| 13:12.25 | cvds_ | tries |
| 13:12.38 | brlcad | you can close the command window and you'll be left with just a multipaned window |
| 13:12.56 | brlcad | otherwise you could run "attach X" four times :) |
| 13:14.30 | cvds_ | Nice that will work, that setting is on a per run basis unless I put it in the config file ? |
| 13:14.39 | brlcad | which setting? |
| 13:14.51 | brlcad | set mged_default(multi_pane) ? |
| 13:15.28 | brlcad | running attach X multiple times doesn't require a setting (and you could put that in your config file) |
| 13:15.44 | brlcad | setting the multi_pane default could also be put into your config file |
| 13:15.53 | cvds_ | that mged_default yes |
| 13:16.20 | cvds_ | and running attach x and trying to draw something made mged crash |
| 13:16.26 | brlcad | on the GUI File menu, there's an item for "Update/Create .mgedrc" |
| 13:16.36 | brlcad | o.O |
| 13:17.51 | cvds_ | something about X not liking the input. I think yakuake or fancy kde things are interfering sometimes |
| 13:18.30 | CIA-48 | BRL-CAD: 03brlcad * r47166 10/brlcad/trunk/BUGS: report of attach X crashing after attempting to draw an object in classic mode |
| 13:18.49 | brlcad | will look into it |
| 13:19.39 | *** join/#brlcad merzo (~merzo@218-96-132-95.pool.ukrtel.net) | |
| 13:20.24 | cvds_ | Ah this is nice, a normal X window that I can control with ae and a multipane next to it |
| 13:22.55 | cvds_ | well lets continue the oed tutorial |
| 13:23.13 | CIA-48 | BRL-CAD: 03abhi2011 * r47167 10/brlcad/trunk/src/libged/simulate/ (simrt.c simulate.c simutils.c): More memory leak search n' destroy |
| 13:23.49 | abhi2011 | brlcad: yes it seems reasonably clean now, though there are some I dunno how to get rid of yet....will discuss them |
| 13:24.32 | abhi2011 | man! valgrind really slows the mged to a crawl |
| 13:25.28 | brlcad | nods |
| 13:27.28 | brlcad | that last round of cleanup seems fishy.. bu_free()'ing specific ranges of some array .. should be none or all (in which case you can use bu_free_array()) |
| 13:27.41 | cvds_ | brlcad: http://pastebin.com/mpYhaKWe is what it tells me, this was ataching an ogl window after closing one |
| 13:28.49 | brlcad | cvds_: yeah, there's some bug there where it's not keeping track of the window properly |
| 13:29.33 | cvds_ | okies |
| 13:30.39 | abhi2011 | brlcad: yes, the specific ranges contains bu_strdup() 'ed strings |
| 13:30.53 | abhi2011 | so they have to be freed afaik |
| 13:31.18 | abhi2011 | they show up as lost blocks in valgrind |
| 13:31.37 | brlcad | understood, but that's my point :) |
| 13:31.46 | brlcad | should be none or all |
| 13:32.08 | brlcad | i.e., don't strdup them if you can or strdup the others so you can categorically free them all |
| 13:32.14 | abhi2011 | ok |
| 13:32.17 | abhi2011 | yeah |
| 13:32.34 | brlcad | having a 5-17 loop is just very error-prone |
| 13:32.40 | abhi2011 | yes |
| 13:32.43 | abhi2011 | true |
| 13:32.51 | abhi2011 | right i ll correct that |
| 13:56.37 | cvds_ | hmm the rot command is still baffeling me, also it seems that the output after object inspection is totally different from the tutorial |
| 14:12.42 | cvds_ | Is there any documentation on how rot acutally works cause the effect apears to be totally random to me |
| 14:14.44 | cvds_ | hmm does it depend ae, but that would mean that I am not actually editing the combination but just rotating the view |
| 14:19.09 | cvds_ | seems that using orot instead of rot actually does more or less what I expect |
| 15:55.46 | CIA-48 | BRL-CAD: 03erikgreenwald * r47168 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: quell uninitialized variable warning |
| 15:59.48 | CIA-48 | BRL-CAD: 03erikgreenwald * r47169 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: quell uninitialized variable warning |
| 17:17.13 | CIA-48 | BRL-CAD: 03brlcad * r47170 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: can use V2INIT_ZERO for initialization |
| 18:47.47 | cvds_ | what is the easiest way to define a single parameter of a shape, if I want to change the height of a cylinder I now kill the shape and then add it again |
| 18:49.46 | CIA-48 | BRL-CAD: 03brlcad * r47171 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: fix typo and turn them into vect2d_t |
| 19:56.24 | cvds_ | well there is ted of course |
| 21:32.12 | *** join/#brlcad merzo (~merzo@134-5-132-95.pool.ukrtel.net) | |
| 05:46.50 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 08:36.22 | cvds_ | having a "pretend" switch for inserting a solid would be nice, you could fiddle with the params without actually creating the object till you are done |
| 08:37.31 | cvds_ | or is there some edit mode I am not aware of that does the same thing ? |
| 10:01.07 | cvds_ | subtracting a disc (rcc) from the top a cube (rpp) such that I should have a small concave corner does not seem to work |
| 10:03.04 | cvds_ | I expected a quarter pie to be removed from the top of the cube, instead only 2 small bars are removed |
| 15:51.32 | starseeker | cvds_: can you post your .g file somewhere? |
| 16:29.33 | CIA-48 | BRL-CAD: 03abhi2011 * r47172 10/brlcad/trunk/src/libged/simulate/simutils.c: Eliminating some fishy memory leak fixes |
| 20:56.45 | cvds_ | starseeker: euhm let me check if I still have it. I switched to using a pipe to cut away that layer and that seems to work |
| 21:06.27 | cvds_ | starseeker: I am afraid I can no longer reproduce the effect |
| 21:07.54 | cvds_ | Most likely I did something wrong myself |
| 21:47.11 | *** join/#brlcad merzo (~merzo@64-4-133-95.pool.ukrtel.net) | |
| 00:23.32 | CIA-48 | BRL-CAD: 03abhi2011 * r47173 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simulate.c simutils.c simutils.h): Added ray shooting in the X direction in the manifold generator to query the overlap area(of the AABBs) of 2 regions |
| 01:32.17 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 07:02.57 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:23.48 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 08:50.47 | cvds_ | Is there a place that explains the datastructure in more detail. I am mainly interested in how references work and are created. It seems that running cp makes a shallow copy of the combination for instance. Meaning that I can change the refered shape but is the same true for adding a shape ? This kind of behavior is what I would like to read up on, I think it will help me reusing more shapes / combinations with less effort to change things in the mode |
| 11:44.59 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 14:54.53 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-187-190.wlan.tudelft.nl) | |
| 16:53.13 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 19:53.04 | *** join/#brlcad merzo (~merzo@230-115-133-95.pool.ukrtel.net) | |
| 21:09.29 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 00:35.35 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 01:59.28 | brlcad | cvds_: have you read the mged tutorial? |
| 01:59.53 | brlcad | cvds_: cp will perform a shallow copy and clone will perform a deep copy |
| 02:03.35 | brlcad | as for adding a shape, it is only added to the combination you specify -- so if you cp FROM TO or clone FROM TO and then add to the TO object, it will not affect the FROM object |
| 02:06.53 | brlcad | if you *do* want to affect "all instances", then you can simply keep a base combination that you reference in your various usages .. e.g., make a REAL1 comb/region that references BASE, a REAL2 comb/region that also references BASE .. then if you modify BASE it'll affect both REAL1 and REAL2 or you can modify REAL1 or REAL2 directly to just modify that instance |
| 02:07.13 | brlcad | vol3 goes into more detail as does the oed tutorial (both on the website under the Docs section) |
| 05:14.08 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 06:13.51 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 06:43.31 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:45.47 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 14:24.39 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 15:01.30 | *** join/#brlcad hackrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 15:44.44 | *** join/#brlcad n_reed (~nicholas@c-68-55-142-136.hsd1.md.comcast.net) | |
| 16:01.30 | cvds_ | brlcad: thanks, I shall dig up vol3. but running a cp on an combibation X giving me an X' will mean that whatever I do to X will end up in X' ? |
| 16:03.43 | cvds_ | ALso, the oed command one is a very useful read |
| 16:05.58 | cvds_ | just which one is the third, I did introduction to mged, the oed command and principles of effective modelling. |
| 17:13.27 | brlcad | cvds_: if you cp X to X1 then whatever you do to X will NOT end up in X |
| 17:13.29 | brlcad | ' |
| 17:13.54 | brlcad | principles of effective modeling is Vol3 |
| 17:14.10 | brlcad | talks about how to structure geometry |
| 17:14.23 | brlcad | as does volume 2 (into mged) but it's spread across multiple tutorials |
| 17:17.36 | cvds_ | will reread the passeges in effective modelling then |
| 17:18.24 | cvds_ | and I did some experimenting already, that oed command + shallow copies is realy nice |
| 17:53.40 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 17:54.41 | cvds_ | is it normal when rendering a combination to get overlap warnings when raytracing (I am getting these on a union of shapes I put together |
| 18:14.32 | brlcad | cvds_: it's normal when you have modeling "errors", sure ;) |
| 18:14.55 | brlcad | if you've not defined any regions, then the raytracer assumes that primitives are regions |
| 18:15.23 | brlcad | a region is brl-cad terminology for a part, when something becomes solid and occupies physical space |
| 18:16.12 | brlcad | probably as simple as marking your combination as a region or creating a region that unions that one combination you were using |
| 18:16.21 | brlcad | (see the 'r' command) |
| 18:20.03 | cvds_ | brlcad: That is what I expected, but wrapping the combination in a region and raytracing it still gave me the erros. I revised the combination to just substract overlapping solids |
| 18:21.04 | cvds_ | and now the raytracer is happy again |
| 18:55.12 | CIA-48 | BRL-CAD: 03erikgreenwald * r47174 10/brlcad/trunk/src/libgcv/bottess.c: fix broken indentation |
| 18:58.41 | brlcad | cvds_: I suspect when you wrapped it in a region, you were still displaying the non-region combination, so it would have still resulted in primitives getting turned into regions resulting in overlaps |
| 19:08.09 | cvds_ | that would make sense -_- I thought I blasted it tho. Let met try this |
| 19:12.12 | cvds_ | brlcad: that seems to be it indeed |
| 19:24.36 | CIA-48 | BRL-CAD: 03starseeker * r47175 10/brlcad/trunk/src/other/ (5 files in 5 dirs): TCL_CHECK_LIBRARY -> CHECK_LIBRARY_EXISTS |
| 19:29.09 | CIA-48 | BRL-CAD: 03starseeker * r47176 10/brlcad/trunk/src/other/ (4 files in 4 dirs): Whoops, not a simple one to one mapping of the macros. |
| 19:30.08 | CIA-48 | BRL-CAD: 03starseeker * r47177 10/brlcad/trunk/src/other/sqlite3/tcl/CMake/tcl.cmake: missed one... |
| 19:30.50 | cvds_ | Is there a more powerful insert command that does not add an object to the end of the combination? Since adding to the end of the tree does not always result in the result I want because of the boolean operator precedence |
| 19:34.47 | brlcad | cvds_: hm! that's actually not come up before (of recent memory) |
| 19:36.28 | brlcad | I've thought about that myself -- a command that allows position-based insertion/removal -- but afaik, doesn't exist |
| 19:36.50 | brlcad | it's usually easy enough to modify the comb with the gui or text edit (red command) or get/put commands |
| 19:37.23 | brlcad | note that the latter is very powerful, but also very unforgiving if you mess up (even simple typos can result in an unusable comb) |
| 19:37.34 | brlcad | put/get is about as low-level as it gets |
| 19:42.42 | cvds_ | brlcad: red seems to work just fine :). I wonder if I should more lower level combinations to prevent very large trees from forming ... |
| 19:43.09 | cvds_ | if I should create* |
| 19:50.21 | CIA-48 | BRL-CAD: 03starseeker * r47178 10/brlcad/trunk/src/other/incrTcl/ (itcl/CMakeLists.txt itk/CMakeLists.txt): Make a stab at updating the incrTcl CMakeLists.txt files |
| 19:51.27 | cvds_ | also considering to wrap a combination that I intend to duplicate around inside a wrapper object before copying. That way I hope that I can add solids the base object and see it propagate over the copties |
| 19:57.28 | cvds_ | heh the c command looks interesting as well |
| 19:59.17 | cvds_ | or can one use parenthesis in comb as well /me tests |
| 20:08.08 | cvds_ | parenthesis are not allowed in comb but are in c, results seems to be the same tree. Using an extra wrapper before making shallow copies allows me to add solids to the copies by adding them to the base combination |
| 20:15.17 | CIA-48 | BRL-CAD: 03starseeker * r47179 10/brlcad/trunk/src/other/tk/CMakeLists.txt: Oops - handle X11 dirs better for tk |
| 20:30.23 | CIA-48 | BRL-CAD: 03brlcad * r47180 10/brlcad/trunk/TODO: |
| 20:30.23 | CIA-48 | BRL-CAD: some reid support requests from the modeling team. add an option to increment |
| 20:30.23 | CIA-48 | BRL-CAD: with values other than 1 and another for reporting/detecting if the region |
| 20:30.23 | CIA-48 | BRL-CAD: numbers being used conflict with existing region numbers elsewhere in the |
| 20:30.23 | CIA-48 | BRL-CAD: database. |
| 20:33.06 | CIA-48 | BRL-CAD: 03brlcad * r47181 10/brlcad/trunk/HACKING: there is a facebook and twitter feed, mention them as part of the release process (ask me for the pw if you need to post) |
| 21:32.50 | CIA-48 | BRL-CAD: 03bob1961 * r47182 10/brlcad/trunk/src/libbu/dirname.c: In bu_dirname, need to check to see if slash is NULL (i.e. we could be on Windows and actually using a forward slash instead of BU_DIR_SEPARATOR which is a backslash on this platform). Don't you just love Windows? |
| 21:40.20 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 21:59.55 | CIA-48 | BRL-CAD: 03n_reed * r47183 10/brlcad/trunk/doc/bison_to_lemon.txt: additions and corrections |
| 22:26.20 | CIA-48 | BRL-CAD: 03starseeker * r47184 10/brlcad/trunk/src/other/sqlite3/ (CMakeLists.txt tcl/CMakeLists.txt): Couple tweaks to the sqlite3 build - we have now successfully run hv3 on Windows. |
| 22:30.48 | brlcad | ``Erik: indentation is broken because the macros are missing semi's |
| 22:31.48 | brlcad | they're expected after all the vmath macros (even if they technically expand to code that might not need it, that's not the intent) |
| 22:47.20 | CIA-48 | BRL-CAD: 03brlcad * r47185 10/brlcad/trunk/src/mged/ (CMakeLists.txt Makefile.am fbserv_win32.c): remove the unused-and-not-being-compiled fbserv_win32.c file, especially now that cmake is building fbserv.c across all platforms. file was referring to a non-existing pkgtypes.h libfb header too. |
| 22:49.41 | CIA-48 | BRL-CAD: 03brlcad * r47186 10/brlcad/trunk/src/conv/iges/ (CMakeLists.txt Makefile.am spl.c): remove the similarly unused spl.c file that was referring to a non-existent b_spline.h header. |
| 22:57.14 | CIA-48 | BRL-CAD: 03brlcad * r47187 10/brlcad/trunk/src/other/step/src/clutils/ (dirobj.cc stat.h): #include ridiculousness. full path to sys/stat.h (and dirent) is not portable. |
| 23:01.34 | CIA-48 | BRL-CAD: 03brlcad * r47188 10/brlcad/trunk/src/librt/ (CMakeLists.txt Makefile.am timer52brl.c): |
| 23:01.35 | CIA-48 | BRL-CAD: remove timer52brl.c for referring to header files that haven't existed in about |
| 23:01.35 | CIA-48 | BRL-CAD: a decade. there doesn't seem to be much utility in even keeping this bsd-style |
| 23:01.35 | CIA-48 | BRL-CAD: implementation around for reference since it just emulates bsd calls, and |
| 23:01.35 | CIA-48 | BRL-CAD: nowhere close to a compiling state regardless. |
| 23:07.42 | CIA-48 | BRL-CAD: 03brlcad * r47189 10/brlcad/trunk/src/adrt/ (4 files in 2 dirs): tie.h no longer lives in a libtie subdir |
| 23:11.03 | CIA-48 | BRL-CAD: 03starseeker * r47190 10/brlcad/trunk/src/other/sqlite3/CMakeLists.txt: More sqlite3 CMake tweaks |
| 23:20.48 | CIA-48 | BRL-CAD: 03brlcad * r47191 10/brlcad/trunk/src/libbu/dirname.c: |
| 23:20.48 | CIA-48 | BRL-CAD: bob's change in r47182 made it obvious that there is more logic failure and |
| 23:20.48 | CIA-48 | BRL-CAD: potential for crash.. need to make sure both slash and slash2 are non-null |
| 23:20.48 | CIA-48 | BRL-CAD: before setting them (and we want to always set them if they're not at the |
| 23:20.48 | CIA-48 | BRL-CAD: beginning of the path) |
| 23:24.45 | CIA-48 | BRL-CAD: 03brlcad * r47192 10/brlcad/trunk/src/libbu/dirname.c: rename slash/slash2 to found_dslash/found_fslash respectively so logic is a lil easier to read |
| 23:25.56 | *** part/#brlcad n_reed (~nicholas@c-68-55-142-136.hsd1.md.comcast.net) | |
| 23:49.59 | *** join/#brlcad mattS_ (cb3af1be@gateway/web/freenode/ip.203.58.241.190) | |
| 00:09.43 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 01:15.12 | CIA-48 | BRL-CAD: 03starseeker * r47193 10/brlcad/trunk/misc/CMake/FindLEMON.cmake: even if we're in toplevel src, we need to rename lemon's output if we're doing cpp instead of c files - give this a try. |
| 01:44.37 | CIA-48 | BRL-CAD: 03starseeker * r47194 10/brlcad/trunk/src/libgcv/ (7 files in 2 dirs): obj_grammar.h is being overwritten by lemon before its output gets renamed to obj_grammer.hpp when srcdir=bindir. Rename the file to obj_grammar_decls.h to avoid the problem. |
| 01:46.30 | CIA-48 | BRL-CAD: 03starseeker * r47195 10/brlcad/trunk/misc/CMake/FindLEMON.cmake: Fix lemon comment |
| 01:53.07 | starseeker | that should fix the in-src-dir cmake build |
| 06:50.14 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 06:57.28 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:06.31 | starseeker | O.o http://compcert.inria.fr/compcert-C.html too bad it's not properly open source |
| 07:34.48 | cvds_ | I must say I am amazed that a 1979? software tool is still being actively worked on |
| 07:39.40 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 09:55.24 | starseeker | cvds_: BRL-CAD? Oh, there are others - maxima and reduce computer algebra systems come readily to mind |
| 09:57.15 | starseeker | spice: http://embedded.eecs.berkeley.edu/pubs/downloads/spice/index.htm |
| 10:06.48 | cvds_ | starseeker: fair point, adn actually I hope to get into spice a little later when I need to start on the electronic design |
| 11:51.32 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:01.12 | cvds_ | there has to be a better way to change the height of a rcc than ted |
| 12:31.56 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 12:54.57 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:55.55 | starseeker | cvds_: sed in mged is how I usually do it |
| 12:56.14 | starseeker | draw the specific primitive, sed it, and then use the gui controls |
| 12:56.42 | starseeker | or use the edit menu to select the height parameter and then use the p command on the mged command line |
| 12:58.01 | starseeker | cvds_: actually, most commercial cad systems have at least ancestor codes that date way back - a task so complex just takes a LOT of time to get done |
| 13:04.59 | cvds_ | starseeker: I am not using the gui |
| 13:05.21 | cvds_ | fonts are way to small to read from the couche :) |
| 13:05.42 | cvds_ | right... debugging in 3d is fun |
| 13:32.41 | brlcad | cvds_: the fonts are fully customizable |
| 13:33.06 | brlcad | you may also appreciate the "press" command |
| 13:34.21 | brlcad | you can "press" any edit option that would be on the edit menu, so like to edit an rcc value, it's something like: sed myrcc ; press "Edit H" ; p 10.4 ; accept |
| 13:35.01 | brlcad | just an example, it might not actually be "Edit H" .. don't recall the options from memory |
| 13:40.28 | CIA-48 | BRL-CAD: 03bob1961 * r47196 10/brlcad/trunk/src/libdm/ (dm-ogl.c dm-wgl.c): Restore calls to glOrtho in wgl_reshape() and ogl_reshape(). |
| 14:19.11 | cvds_ | brlcad: I tried to customize the fonts, but they did not seem to scale a lot. Tho that could be my window manager and dpi settings. The press command seems realy interesting tho |
| 14:19.41 | cvds_ | also did find the 0.5 mm offset that was wrong |
| 14:55.29 | starseeker | yawns |
| 15:29.28 | brlcad | cvds_: if you select "Update/Create .mgedrc" on the file menu, it'll put a .mgedrc configuration file in your home directory -- in there, you can change the font values to whatever your system allows, potentially much greater than the gui allows |
| 15:47.33 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 16:28.33 | cvds_ | Interesting, I must try that sometime. Tho I am quite happy using yakuake and having the model full screen at the moemnt |
| 16:29.07 | brlcad | nods |
| 16:31.37 | cvds_ | or rather.. all 5 of them |
| 16:34.07 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 17:04.30 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 17:14.04 | CIA-48 | BRL-CAD: 03n_reed * r47197 10/brlcad/trunk/src/other/step/src/express/CMakeLists.txt: build new scanner output into new libexpress |
| 17:23.11 | cvds_ | is there an example sheet of primitives about.. like I am trying to figure out the vector A and B for a rec |
| 17:25.41 | cvds_ | ah the tutorial2 had one for the walkie talky |
| 17:27.32 | CIA-48 | BRL-CAD: 03n_reed * r47198 10/brlcad/trunk/src/other/step/src/express/ (expparse_new.y token_type.h): putting token type definition in its own header |
| 18:02.11 | *** join/#brlcad akissimouyt (~arcosauro@ppp-115-45.32-151.iol.it) | |
| 18:02.21 | akissimouyt | Hello! |
| 18:02.27 | akissimouyt | !list |
| 18:02.37 | *** part/#brlcad akissimouyt (~arcosauro@ppp-115-45.32-151.iol.it) | |
| 18:03.28 | *** join/#brlcad akissimouyt (~arcosauro@ppp-115-45.32-151.iol.it) | |
| 18:04.18 | *** part/#brlcad akissimouyt (~arcosauro@ppp-115-45.32-151.iol.it) | |
| 19:22.16 | CIA-48 | BRL-CAD: 03brlcad * r47199 10/brlcad/trunk/src/tclscripts/archer/images/Makefile.am: option_tree is no more |
| 19:43.14 | CIA-48 | BRL-CAD: 03n_reed * r47200 10/brlcad/trunk/src/other/step/ (include/express/lexact.h src/express/lexact.c): replaced conditional variable declarations with explcit ones to simplify building |
| 19:50.36 | CIA-48 | BRL-CAD: 03n_reed * r47201 10/brlcad/trunk/src/other/ (10 files in 3 dirs): making lemon parser sources the only parser sources |
| 19:52.57 | CIA-48 | BRL-CAD: 03bob1961 * r47202 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: update bot_flip_check to set the flipped bot's orientation to rh if previously oriented |
| 19:53.31 | CIA-48 | BRL-CAD: 03n_reed * r47203 10/brlcad/trunk/src/other/step/src/express/express.c: remove debug output |
| 20:16.39 | CIA-48 | BRL-CAD: 03starseeker * r47204 10/brlcad/trunk/src/other/sqlite3/CMakeLists.txt: Er, oops - how about -D |
| 20:33.52 | brlcad | cvds_: there's a list of most primitives at the end of vol2 |
| 20:42.04 | CIA-48 | BRL-CAD: 03starseeker * r47205 10/brlcad/trunk/src/other/togl/include/GL/glew.h: glew.h patch from Tim Myers for Mac |
| 20:44.25 | *** join/#brlcad mattS_ (cb3af1be@gateway/web/freenode/ip.203.58.241.190) | |
| 20:46.10 | *** join/#brlcad merzo (~merzo@115-2-132-95.pool.ukrtel.net) | |
| 20:48.27 | cvds_ | brlcad: perfect |
| 22:00.25 | abhi2011 | anyone else getting errors related to some undefined sqlite3 symbols ? |
| 22:01.16 | starseeker | abhi2011: have you updated to the very latest trunk? |
| 22:01.23 | CIA-48 | BRL-CAD: 03brlcad * r47206 10/brlcad/trunk/doc/docbook/create-xml-catalogs.pl: create the directory if it doesn't yet exist (which it never does for an out-of-dir build) |
| 22:02.20 | CIA-48 | BRL-CAD: 03brlcad * r47207 10/brlcad/trunk/ (configure.ac doc/docbook/DBPATH.pm.in): no need to define and substitute new variables here, just use the default abs_top_srcdir which lets us keep the path logic where it belongs too (in DBPATH.pm). |
| 22:03.33 | abhi2011 | ah ok, i ll update again |
| 22:03.36 | CIA-48 | BRL-CAD: 03brlcad * r47208 10/brlcad/trunk/doc/docbook/Makefile.am: this seems to get things working for an out-of-dir build. needed to tell perl where the perl module resided and not assume the generated catalog generator file is in the source dir. |
| 22:07.06 | brlcad | arf, very unhappy parallel cmake build |
| 22:07.42 | brlcad | make -j20 .. failed four times before making it through to the end |
| 22:10.01 | CIA-48 | BRL-CAD: 03brlcad * r47209 10/brlcad/trunk/TODO: only two show-stopper items holding up the release. need to make sure rtcheck works and testing multipe blank lines in mged. |
| 22:51.32 | CIA-48 | BRL-CAD: 03n_reed * r47210 10/brlcad/trunk/configure.ac: disable STEP build |
| 22:51.47 | brlcad | starseeker: done a distcheck in a while? looking like hv3 and sqlite3 aren't getting added |
| 22:52.02 | brlcad | plus a bunch of the doc files for some reasons |
| 23:05.56 | CIA-48 | BRL-CAD: 03n_reed * r47211 10/brlcad/trunk/src/other/step/src/express/Makefile.am: remove reference to non-existant file |
| 23:18.19 | CIA-48 | BRL-CAD: 03starseeker * r47212 10/brlcad/trunk/doc/ecosystem.dot: Graphviz generated layout detailing relationships between 3rd party libraries and BRL-CAD components. High level overview. |
| 23:20.17 | starseeker | brlcad: not recently... |
| 23:38.58 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 23:45.56 | abhi2011 | starseeker: I just updated to the latest build a few minutes ago, the cmake build shows some errors : http://bin.cakephp.org/view/417920177 |
| 23:47.06 | starseeker | abhi2011: did you clear out your old CMakeCache.txt file? |
| 23:47.35 | abhi2011 | oh , I didnt, a make clean should do that I guess |
| 23:47.54 | starseeker | it's like the config.cache file from autotools |
| 23:48.11 | starseeker | it stays around until you specifically nuke it (either from the GUI or manually) |
| 23:49.08 | abhi2011 | ok |
| 00:49.19 | CIA-48 | BRL-CAD: 03starseeker * r47213 10/brlcad/trunk/src/tclscripts/ (CMakeLists.txt Makefile.am hv3_man_browser_test.tcl): first baby steps, but this demonstrates the fundamental possibility of customizing the hv3 browser to serve as a man page help browser. Just a checkpoint. |
| 01:01.35 | CIA-48 | BRL-CAD: 03starseeker * r47214 10/brlcad/trunk/ (5 files in 5 dirs): Add some files to the CMake logic. For the moment, just ignore sqlite3 and hv3 - functionality using those repositories isn't quite ready yet. |
| 01:12.43 | CIA-48 | BRL-CAD: 03abhi2011 * r47215 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h): Wrote some initial code to generate contact pairs out of overlaps detected while shooting rays down the x axis |
| 01:15.09 | CIA-48 | BRL-CAD: 03starseeker * r47216 10/brlcad/trunk/doc/docbook/books/ (CMakeLists.txt it/ ru/): Remove empty dirs until they have contents |
| 01:34.37 | starseeker | ok, fwiw, cmake distcheck passed |
| 02:33.10 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 02:41.53 | brlcad | starseeker: great, thx |
| 03:48.31 | CIA-48 | BRL-CAD: 03starseeker * r47217 10/brlcad/trunk/src/archer/archer: Er, don't want to complain if we've just launched via symlink (e.g. the /usr/brlcad/bin -> /usr/brlcad/rel-x.x.x/bin situation) so resolve the argv0 file up front. |
| 04:15.50 | CIA-48 | BRL-CAD: 03starseeker * r47218 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: use bu_brlcad_data. Still just a trivial example thus far. |
| 04:41.34 | ``Erik | starseeker: rhel complains about dlopen/dlsym/etc in src/other/sqlite3 (not getting -ldl), fbsd complains about header paths on incrTk (have /usr/local/include/X11/Xlib.h and /usr/X11R6/include/X11/Xlib.h, header not being found at preprocessor) |
| 04:42.20 | starseeker | ``Erik: in the rhel case, did you try clearing out the CMakeCache.txt file and rebuilding? |
| 04:44.11 | CIA-48 | BRL-CAD: 03starseeker * r47219 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: Still need a scrollbar, but coming along nicely - can now pull up manual pages. |
| 04:44.41 | starseeker | ``Erik: I'll give freebsd a try tomorrow |
| 06:24.03 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 06:41.03 | cvds_ | I am starting on the first "irregular" shape that contains many curves. Is there a "best" way to do this or does it come down to "be creative"? |
| 06:44.45 | cvds_ | it sorta looks like a banana with a flat bottom -_- |
| 08:00.40 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 08:46.41 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 11:03.54 | CIA-48 | BRL-CAD: 03abhi2011 * r47220 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simulate.c simutils.c simutils.h): Corrected some indentations in the code |
| 11:43.50 | CIA-48 | BRL-CAD: 03abhi2011 * r47221 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h): Rayshot results structure corrected to be initialized for every manifold now, instead of for every ray |
| 11:44.06 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 11:50.39 | CIA-48 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3181 10/wiki/User:Abhijit: /* Log */ |
| 12:03.24 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:35.57 | brlcad | cvds_: there are some best practices but coming up with a good CSG recipe for a given shape can take some thought |
| 12:37.45 | brlcad | it's generally best to capture most of the shape with just one or a couple primitives unioned together that exceeds the volume, then perform subtractions to scuplt a perfect match |
| 12:38.38 | brlcad | another method involves following contours and walking a pattern around prescribed axes, then intersecting them together |
| 12:40.19 | brlcad | for a banana, I'd probably approach it as a union of base shapes matching the exterior curves, then subtract the interior curves |
| 12:57.00 | cvds_ | brlcad: that is what I was planning, I think I can do it with 4 recs |
| 13:22.59 | CIA-48 | BRL-CAD: 03starseeker * r47222 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: Add the search option for pages back in. |
| 13:25.42 | CIA-48 | BRL-CAD: 03starseeker * r47223 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: key bindings too. |
| 13:30.42 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:37.00 | brlcad | o.O ... Re-run cmake file: CMakeFiles/cmake.check_cache older than: ../src/archer/archer |
| 13:37.12 | brlcad | cmake rebuild dependent on a tcl script getting updated?? |
| 13:37.49 | brlcad | cmake -j10 distcheck failure .. retrying with verbose (died in tcl) |
| 13:38.32 | starseeker | brlcad: it probably depends on how I have src/archer/archer called out |
| 13:40.20 | brlcad | undoubtedly, but on the surface doesn't seem right :) |
| 13:40.25 | brlcad | it's a script :) |
| 13:41.23 | brlcad | that's along with docs are some of the few/only things in the package that can be updated independent of cmake detection logic |
| 13:41.37 | brlcad | hits road |
| 13:46.37 | starseeker | IIRC, that's one of the ones I'm copying into bin (so ./bin/archer works from the build directory) |
| 13:46.56 | starseeker | should probably be doing a symlink... |
| 14:02.55 | CIA-48 | BRL-CAD: 03starseeker * r47224 10/brlcad/trunk/src/archer/CMakeLists.txt: Try a symlink when possible for archer |
| 14:11.20 | CIA-48 | BRL-CAD: 03starseeker * r47225 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: getting close. Have scrollbar now, get the search bindings working even if the focus is in the tree. |
| 14:51.06 | brlcad | starseeker: it looks like the distcheck failure is in the docs processing |
| 14:51.49 | brlcad | copying into bin sounds fine .. it's where the dep is coming from |
| 14:52.32 | brlcad | the distcheck error seems to be: |
| 14:52.34 | brlcad | runtime error |
| 14:52.34 | brlcad | xsltApplyStylesheet: saving to /n/uf1/e/vld/other/morrison/brlcad/.cmake/_brlcad-7.20.3-build/share/brlcad/7.20.3/html/mann/en/all_sf.html may not be possible |
| 14:53.05 | brlcad | make[6]: *** [share/brlcad/7.20.3/html/mann/en/all_sf.html] Error 9 |
| 14:53.05 | brlcad | make[5]: *** [doc/docbook/system/mann/en/CMakeFiles/all_sf_mann_html.dir/all] Error 2 |
| 14:53.52 | brlcad | unrelated, but tcl also seems to have an rpath oddity: |
| 14:54.44 | brlcad | all of the linker lines have -Wl,-rpath,::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: |
| 14:57.19 | CIA-48 | BRL-CAD: 03starseeker * r47226 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: Use paned view. This may do it, except for the itcl/itk integration issues in Archer... |
| 14:58.15 | starseeker | brlcad: that's an xsltproc problem. I've seen that before |
| 14:59.11 | starseeker | http://mail.gnome.org/archives/xslt/2009-December/msg00011.html |
| 15:00.40 | brlcad | ah, so then we can work around it by making sure the output directory is already created |
| 15:01.22 | brlcad | does cmake have an equivalent to mkdir -p? |
| 15:01.30 | starseeker | I believe so |
| 15:01.37 | starseeker | one sec... |
| 15:06.15 | CIA-48 | BRL-CAD: 03starseeker * r47227 10/brlcad/trunk/doc/docbook/CMakeLists.txt: Try to make soure our target directory is present before running xsltproc, to avoid multiple instances arguing - see http://mail.gnome.org/archives/xslt/2009-December/msg00011.html |
| 15:06.21 | starseeker | see if that helps |
| 15:06.41 | brlcad | k |
| 15:26.05 | CIA-48 | BRL-CAD: 03starseeker * r47228 10/brlcad/trunk/src/other/ (CMakeLists.txt Makefile.am hv3.dist sqlite3/): Shaping up somewhat - looks like we will want hv3 but don't (yet) need sqlite, at least for the functionality we're currently interested in. |
| 15:29.22 | starseeker | hits road |
| 16:55.47 | brlcad | starseeker: that seems to have helped, now it's choking on some scl generated output |
| 16:55.51 | brlcad | cd /n/uf1/e/vld/other/morrison/brlcad/.cmake/brlcad-7.20.3/src/other/step/src/express && /bin/mv expparse.out /n/uf1/e/vld/other/morrison/brlcad/.cmake/_brlcad-7.20.3-build/src/other/step/src/exp |
| 16:55.55 | brlcad | ress/expparse.out |
| 16:55.57 | brlcad | Dependee "/n/uf1/e/vld/other/morrison/brlcad/.cmake/_brlcad-7.20.3-build/src/other/step/src/express/expparse.c" is newer than depender "src/other/step/src/express/CMakeFiles/express.dir/expparse. |
| 16:56.01 | brlcad | c.o". |
| 16:56.04 | brlcad | /bin/mv: cannot stat `expparse.out': No such file or directory |
| 16:56.11 | brlcad | (ignore Dependee line.. lots of those) |
| 16:56.50 | brlcad | presumably it's trying to move a file before it was generated, I'd guess implying that some ordering dependency isn't being described |
| 16:57.55 | brlcad | fix could be as simple as copying the file instead of trying to move it |
| 17:09.08 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 18:33.14 | CIA-48 | BRL-CAD: 03starseeker * r47229 10/brlcad/trunk/misc/CMake/FindLEMON.cmake: |
| 18:33.14 | CIA-48 | BRL-CAD: Sean had a good idea - rather than fight to get all of lemon's outputs out of |
| 18:33.15 | CIA-48 | BRL-CAD: the src dir, just copy the input file into the build dir and run lemon there. |
| 18:33.15 | CIA-48 | BRL-CAD: Cleaner from a 'don't write in the src tree' standpoint AND simplifies the |
| 18:33.15 | CIA-48 | BRL-CAD: logic. Nice. |
| 18:54.42 | CIA-48 | BRL-CAD: 03starseeker * r47230 10/brlcad/trunk/src/other/ (20 files in 5 dirs): Hmm, spoke too soon (or more precisely, did the test incorrectly.) hv3 still needs sqlite3. Put it back, with proper dist file and fixing dl test. |
| 19:09.57 | CIA-48 | BRL-CAD: 03starseeker * r47231 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: Accept a value from the command line, althought this is probably not the final mechanism we'll want to use. |
| 19:26.28 | CIA-48 | BRL-CAD: 03erikgreenwald * r47232 10/brlcad/trunk/src/libgcv/bottess.c: Pass opposite face normal to splitter (for in place classification). De-macro, simplifiy, clean up. Add line checking via bn. |
| 19:48.25 | CIA-48 | BRL-CAD: 03starseeker * r47233 10/brlcad/trunk/src/other/hv3/ (hv3_form.tcl hv3_http.tcl): Couple of catches to prevent error messages. |
| 19:54.22 | CIA-48 | BRL-CAD: 03starseeker * r47234 10/brlcad/trunk/src/other/tkhtml/src/htmlimage.c: Don't toss out this warning every time. |
| 19:58.57 | CIA-48 | BRL-CAD: 03starseeker * r47235 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: Add tkpng to the mix, even though we aren't likely to need it for man pages. |
| 20:26.47 | CIA-48 | BRL-CAD: 03starseeker * r47236 10/brlcad/trunk/src/other/ (CMakeLists.txt incrTcl/itk/CMakeLists.txt): In the case of Itk, do as Tk does for X11 includes |
| 20:31.17 | starseeker | hah, cool: http://www.cnn.com/2011/10/13/tech/innovation/pavegen-kinetic-pavements/index.html |
| 21:13.46 | CIA-48 | BRL-CAD: 03starseeker * r47237 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: Fix hiding and re-enabling the extra parts of the gui. |
| 21:30.24 | CIA-48 | BRL-CAD: 03starseeker * r47238 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: Start working towards being able to do the hv3 browser in Itcl/Itk, or rather, discovering whether that is technically workable. |
| 21:44.50 | CIA-48 | BRL-CAD: 03n_reed * r47239 10/brlcad/trunk/src/other/step/include/exppp/exppp.h: added missing header guard |
| 22:30.52 | brlcad | starseeker: looks like distcheck passes! |
| 22:31.21 | brlcad | cmake, that is .. now to validate auto |
| 22:40.29 | CIA-48 | BRL-CAD: 03brlcad * r47240 10/brlcad/trunk/regress/repository.sh: looks like failures were accidentally committed as non-fatal so failures were being reported but not halting. make them halt so the problems get noticed/fixed. |
| 22:58.50 | CIA-48 | BRL-CAD: 03brlcad * r47241 10/brlcad/trunk/regress/repository.sh: actually, the problem was that we don't increment the FOUND count for this particular subtest. make the CPPFLAGS test not-so-strict, though, recognizing and ignoring lines that have a comment (e.g., our libpng) |
| 23:28.31 | CIA-48 | BRL-CAD: 03brlcad * r47242 10/brlcad/trunk/sh/ (CMakeLists.txt Makefile.am cmp.sh): |
| 23:28.31 | CIA-48 | BRL-CAD: add the initial comparison script that was used to evaluate, validate, and |
| 23:28.31 | CIA-48 | BRL-CAD: compare geometry representations for implicit, nurbs, and polygonal mesh |
| 23:28.31 | CIA-48 | BRL-CAD: geometry. the script makes a variety of assumptions (various tools must be in |
| 23:28.31 | CIA-48 | BRL-CAD: PATH), but is relatively useful for comparing how similar/different two geometry |
| 23:28.31 | CIA-48 | BRL-CAD: objects are. |
| 23:54.39 | CIA-48 | BRL-CAD: 03n_reed * r47243 10/brlcad/trunk/src/other/step/ (45 files in 3 dirs): Removed toggled declarations/definitions in headers. Headers include only declarations, and explicit definitions found in appropriate sources. |
| 00:30.25 | CIA-48 | BRL-CAD: 03n_reed * r47244 10/brlcad/trunk/src/other/step/include/ (CMakeLists.txt express/Makefile.am): remove references to non-existent headers |
| 00:31.14 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 06:47.20 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 09:41.18 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 11:54.34 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 13:20.13 | brlcad | yawns |
| 13:56.22 | CIA-48 | BRL-CAD: 03brlcad * r47245 10/brlcad/trunk/src/other/Makefile.am: we cannot traverse into 'step' even as a DIST_SUBDIR because the build logic in there will attempt (and fail) to generate files to be included in the dist. just include the whole directory as an EXTRA_DIST item. |
| 14:06.02 | CIA-48 | BRL-CAD: 03bob1961 * r47246 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Using separate variables for keeping track of the zclip values for the front/near and back/far zclip values. |
| 14:11.25 | CIA-48 | BRL-CAD: 03brlcad * r47247 10/brlcad/trunk/src/external/Makefile.am: there is no CMakeLists.txt file defined for src/external, cannot yet build proe or ug plugins with new build system. |
| 14:13.36 | CIA-48 | BRL-CAD: 03brlcad * r47248 10/brlcad/branches/STABLE/ (4 files in 4 dirs): mergeinfo |
| 14:44.39 | CIA-48 | BRL-CAD: 03brlcad * r47249 10/brlcad/trunk/misc/Makefile.am: CMake/svncheck.cmake.in no longer exists |
| 14:48.57 | CIA-48 | BRL-CAD: 03erikgreenwald * r47250 10/brlcad/trunk/src/libgcv/bottess.c: Fixes to face split logic. Remove classifier, as face classification will be done at split time instead of trying to guess later (NMG) or caching (unnbolean). |
| 14:50.47 | brlcad | starseeker: what does it do with the symlink when you later install? |
| 15:18.54 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:20.53 | CIA-48 | BRL-CAD: 03brlcad * r47251 10/brlcad/trunk/misc/Makefile.am: slew of other cmake files missing from the dist, sort list |
| 15:23.43 | CIA-48 | BRL-CAD: 03brlcad * r47252 10/brlcad/trunk/doc/Makefile.am: got to keep both in sync, just a couple more releases. add ecosystem.dot |
| 15:48.55 | CIA-48 | BRL-CAD: 03brlcad * r47253 10/brlcad/trunk/TODO: add a section specifically for cmake items still pending |
| 15:51.20 | CIA-48 | BRL-CAD: 03brlcad * r47254 10/brlcad/trunk/doc/docbook/books/en/Makefile.am: add missing image files to dist |
| 16:15.33 | CIA-48 | BRL-CAD: 03brlcad * r47255 10/brlcad/trunk/TODO: specify some of the material traits we may be interested in, scalar values |
| 16:50.21 | CIA-48 | BRL-CAD: 03bob1961 * r47256 10/brlcad/trunk/src/libdm/dm_obj.c: |
| 16:50.21 | CIA-48 | BRL-CAD: The relatively new call to fb_close_existing() in dmo_closeFb() frees the |
| 16:50.21 | CIA-48 | BRL-CAD: framebuffer's memory. The older code in dmo_closeFb() that frees this same |
| 16:50.21 | CIA-48 | BRL-CAD: memory has been removed. This fixes a double free problem encountered when using |
| 16:50.21 | CIA-48 | BRL-CAD: the old CAD widgets. |
| 16:53.55 | CIA-48 | BRL-CAD: 03n_reed * r47257 10/brlcad/trunk/src/other/step/src/express/express.c: yylval is YYSTYPE, not int |
| 18:14.45 | CIA-48 | BRL-CAD: 03starseeker * r47258 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: Probably not the way to approach hv3 - remove extra stuff. |
| 18:41.25 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 18:56.43 | CIA-48 | BRL-CAD: 03n_reed * r47259 10/brlcad/trunk/src/other/step/src/express/ (expparse.y express.c): Doing state init via func call since lemon isn't running start-symbol action as soon as bison was. |
| 19:33.12 | CIA-48 | BRL-CAD: 03erikgreenwald * r47260 10/brlcad/trunk/src/libgcv/bottess.c: begin "point in face" handling |
| 21:54.41 | CIA-48 | BRL-CAD: 03n_reed * r47261 10/brlcad/trunk/src/other/step/src/express/expparse.y: typo in action was causing segfault |
| 22:18.04 | brlcad | starseeker: now that you have the docs building in cmake, is perl still being used? |
| 23:08.54 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 23:17.30 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 23:24.17 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 23:27.36 | starseeker | brlcad: not for CMake, but it is for autotools... |
| 23:27.48 | starseeker | 'course, I don't have the validation stuff running with CMake yet |
| 01:02.47 | *** join/#brlcad sydneysider (792c923d@gateway/web/freenode/ip.121.44.146.61) | |
| 01:02.56 | *** part/#brlcad sydneysider (792c923d@gateway/web/freenode/ip.121.44.146.61) | |
| 01:26.57 | *** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 02:27.24 | CIA-48 | BRL-CAD: 03abhi2011 * r47262 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simrt.c simrt.h simulate.h simutils.h): Added logic to generate contact pairs, need to still find a way to properly generalize it to all cases |
| 02:38.12 | starseeker | brlcad: symlink... you mean my check in archer? |
| 02:39.05 | starseeker | it seems to be resolving the directory paths, but not switching the path to the final location - i.e. the behavior I would have hoped for, although I wasn't sure I would get it until I actually tried it |
| 02:47.07 | CIA-48 | BRL-CAD: 03starseeker * r47263 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: Shouldn't hurt anything and may make testing easier, go ahead and commit - the shell stuff... |
| 02:55.34 | starseeker | i.e. if the file itself is a symlink, it normalizes the path to that symlink but doesn't follow the symlink itself |
| 02:57.06 | starseeker | so if /usr/brlcad is a symlink to /usr/brlcad/rel-7.20.2, /usr/brlcad/bin/archer resolves to /usr/brlcad/rel-7.20.2/bin/archer |
| 02:57.17 | *** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 02:58.04 | starseeker | but if I symlink (say) /tmp/archer to /usr/brlcad/rel-7.20.2/bin/archer, tcl will normalize /tmp/archer to /tmp/archer and not follow the file symlink to /usr/brlcad/rel... |
| 02:59.06 | starseeker | at least, that's the behavior I'm observing here |
| 03:13.23 | CIA-48 | BRL-CAD: 03starseeker * r47264 10/brlcad/trunk/src/ (other/CMakeLists.txt tclscripts/hv3/hv3.tcl): |
| 03:13.23 | CIA-48 | BRL-CAD: Until the more powerful help browser has been worked out, let's go with a |
| 03:13.23 | CIA-48 | BRL-CAD: solution that at least avoids printing the error messages - there doesn't seem |
| 03:13.23 | CIA-48 | BRL-CAD: to be any actual regression in functionality due to *not* reading the css (not |
| 03:13.23 | CIA-48 | BRL-CAD: too surprising since it wasn't originally there at all) so turn off the full hv3 |
| 03:13.24 | CIA-48 | BRL-CAD: and quell the warning message in our local hv3 subset. Should let things |
| 03:13.25 | CIA-48 | BRL-CAD: proceed until the full-powered system gets sorted out. |
| 03:15.03 | starseeker | probably what I should have done in the first place... |
| 08:35.08 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 11:06.31 | *** join/#brlcad kaushikG (Kaushik@122.178.17.110) | |
| 11:06.47 | kaushikG | Hello |
| 11:08.14 | kaushikG | I'm interested in developing for BRL-CAD as my undergraduate final year project. Who would help me in this regard? |
| 16:16.37 | brlcad | left too quick! |
| 16:19.47 | brlcad | starseeker: so if perl isn't being used by cmake, it'd be great to not introduce it into the mix |
| 16:20.29 | brlcad | even if the cpan module is small, which I suspect it's not, it's pretty complicated for anything more than a one-shot processing (which WOULD be fine) |
| 16:25.29 | brlcad | but then like I mentioned, I think the best long-term goal is to get the docs for each command colocated with the commands so they can more easily stay in sync .. specifically with usage coming from the source code itself since it has to be there already |
| 16:47.13 | *** join/#brlcad yiyus (~124271242@je.je.je) | |
| 17:05.38 | abhi2011 | yes, could have gotten some one to work on the GUI for the simulation stuff :P |
| 17:42.23 | abhi2011 | is there a standard way to temporarily quell unused function variables |
| 17:42.50 | abhi2011 | i currently simply print there values so that they get used somewhere |
| 18:05.16 | starseeker | brlcad: that sounds like a step toward literate programming :-) |
| 18:05.52 | starseeker | one issue I see is if we put the "short help" statements in the code, there will be a tendency to just update those and not review the man page for that command (which may also need to be updated) |
| 18:06.30 | starseeker | that was my thought with the usage being extracted from the docbook - if we go that route, it *doesn't* have to be in the source code |
| 18:07.55 | starseeker | then 1) update the source 2) update the help statements in the code 3) review and update the docbook man page becomes just 1) update the source 2) review and update the docbook man page |
| 18:08.31 | starseeker | I didn't want (and don't want) to use perl to extract bits from the xml - my hope was xsl + xsltproc alone would be sufficient |
| 18:08.44 | starseeker | not convinced it isn't, for that matter |
| 18:52.13 | brlcad | abhi2011: you can wrap them in UNUSED() though printing them is good too since it's a reminder that you still need to use or lose them |
| 18:53.06 | brlcad | starseeker: the case of extended docs not getting update will always be an issue -- moving the synopsis to the code ensures that at least the usage is always correct |
| 18:54.38 | brlcad | 1 and 2 (updating sort and help statements) are effectively one in the same -- to add a new option means adding new code, which self-documents |
| 18:54.59 | brlcad | there would be no extended documentation for any new option, but then we could script that into a regression test |
| 18:55.18 | brlcad | checking the usage is much harder though |
| 18:55.32 | brlcad | not something that can be reliably tested for given the variety of synposes |
| 18:59.18 | starseeker | brlcad: but moving usage to the code doesn't really ensure it's always correct - it puts the usage "closer" to the coding action, but that doesn't necessarily mean anything |
| 18:59.54 | starseeker | and I sometimes wonder how useful the usage statements are without the full man page - they often don't help me much in isolation |
| 19:06.51 | starseeker | if we can script a check on the extended documentation in Docbook based on the command, couldn't we also do the same thing for a usage statement defined in docbook, once extracted to a txt file? |
| 19:40.56 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 20:05.42 | CIA-48 | BRL-CAD: 03abhi2011 * r47265 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simrt.c): Generated the manifold, trying to inject them correctly into the bullet collision pipeline |
| 20:27.59 | CIA-48 | BRL-CAD: 03abhi2011 * r47266 10/brlcad/trunk/src/libged/simulate/simrt.c: Floating point issues, had to increase the limit of a loop by TOLerance to ensure rays are shot from edge to edge in overlap volume, strangely NEAR_EQUAL() doesnt seem to work |
| 20:57.27 | brlcad | starseeker: I wasn't talking about "moving" usage to the code -- that usage is actually derived from the code |
| 20:58.44 | brlcad | part of a bu_opt interface, supporting long and short options and their dependencies, working with bu_getopt() but also having a helper routine(s) to auto-generate usage statements |
| 20:58.55 | brlcad | or output xml or whatever really at that point |
| 20:59.07 | starseeker | oh, I see |
| 20:59.26 | brlcad | started getting into it with the libged zoom template, is a clear need |
| 20:59.39 | brlcad | so that's actually what I've been working on next |
| 21:00.07 | brlcad | just a little stalled by the nurbs and release review taking so long |
| 21:41.18 | CIA-48 | BRL-CAD: 03abhi2011 * r47267 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simphysics.cpp simrt.c simulate.c): Bullet seems to be deleting the contact pairs, added some more callbacks to investigate |
| 21:46.48 | CIA-48 | BRL-CAD: 03abhi2011 * r47268 10/brlcad/trunk/src/libged/simulate/simulate.c: Manfold generation cant happen before the physics is run, otherwise the list of manifolds are cleared, it has to happen later |
| 22:49.46 | abhi2011 | i was wondering how bu_free knows how many bytes to free as there is size paramter to it : bu_free(current_manifold, "simulate : current_manifold"); |
| 22:51.15 | abhi2011 | *there is no size |
| 22:52.46 | abhi2011 | probably the C runtime keeps track of allocated chunks |
| 22:54.03 | brlcad | abhi2011: same way free() knows how to release memory from malloc() |
| 22:54.08 | brlcad | keeps track of the pointer |
| 22:54.20 | abhi2011 | yes, ok |
| 00:01.29 | brlcad | abhi2011: NEAR_EQUAL() probably didn't work because it compares against the open set |
| 00:02.12 | brlcad | i.e., the values between val-tol to val+tol, but not including those values |
| 00:02.12 | abhi2011 | brlcad: open set ? |
| 00:02.21 | abhi2011 | ok |
| 00:03.00 | abhi2011 | a simple == may work |
| 00:03.29 | brlcad | no, that's the point of the macros |
| 00:03.38 | brlcad | you cannot rely on == with floating point, it is not reliable |
| 00:03.45 | abhi2011 | hmm yes |
| 00:04.14 | abhi2011 | so there are no macros which include the boundary values ? |
| 00:04.28 | brlcad | that's part why NEAR_EQUAL() uses the open set, you cannot reliably compare if a value <= some other value |
| 00:04.41 | brlcad | you can only compare if it's < or < |
| 00:04.43 | brlcad | er > |
| 00:04.48 | abhi2011 | ok |
| 00:05.16 | brlcad | so to get the looping effect you were attempting, you were basically just off-by-one due to the tolerance |
| 00:05.45 | abhi2011 | yes i wanted it to go upto 1.0000, but it stopped at 0.96 |
| 00:05.52 | brlcad | changing to what you did is fine, val < (max+tol) |
| 00:06.00 | abhi2011 | ok |
| 00:07.16 | brlcad | though that should have been effectively equiv to !NEAR_EQUAL(val, max, tol) |
| 00:08.03 | brlcad | er, I mean !NEAR_EQUAL(val, max+tol, tol) |
| 01:29.26 | abhi2011 | yes right :) |
| 06:14.27 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 09:11.33 | cvds_ | why is delete used as a "quit terminal" >_> |
| 09:52.35 | cvds_ | I wonder what the easiest way would be to get a prism with a 10degree slope |
| 10:02.54 | CIA-48 | BRL-CAD: 03tbrowder2 * r47269 10/brlcad/trunk/doc/docbook/ (ElNode.pm read-db-xml.pl): add two tools to read DB xml and extract data for archer |
| 11:09.12 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 12:17.38 | brlcad | cvds_: delete used as a quit terminal? in what? |
| 12:19.01 | cvds_ | brlcad: in mged console mode |
| 12:19.10 | cvds_ | if I hit delete on an empty command line mged closes |
| 12:19.32 | cvds_ | not a problem unless it happens the first time, I went o_O |
| 12:29.50 | brlcad | eek, that doesn't sound like a quit terminal, that sounds like it's crashing! |
| 12:29.57 | brlcad | have you ever run gdb before? |
| 12:30.12 | brlcad | gdb --args path/to/mged |
| 12:30.14 | brlcad | run |
| 12:30.36 | brlcad | use it, hit delete, see if it returns you to a gdb prompt |
| 12:30.41 | brlcad | then "bt" |
| 12:42.15 | cvds_ | will do |
| 12:43.54 | cvds_ | I need to install that ghdb first tho |
| 12:46.20 | cvds_ | gdb* |
| 12:58.11 | cvds_ | also should I worry if rendering with 'E' gives me a wall of text ? |
| 13:05.53 | cvds_ | brlcad: http://pastebin.com/rrtTqJpC however I dont have a version including debug symbols, so not sure i useful |
| 13:05.59 | cvds_ | if its* |
| 13:06.55 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 13:09.35 | brlcad | cvds_: typing delete inserted that "exit" command? |
| 13:10.11 | brlcad | that's not a crash, that's a normal exit .. but it's certainly not expected |
| 13:10.32 | brlcad | E giving a wall of text is normal - it's the output from tessellating the geometry into a polygonal mesh |
| 13:13.12 | cvds_ | including: ERROR: first hit on bodyCOuter.s (surfno = 12) is an exit at (-6.42262 13 11) ray start = (-4.451251276587e+00 1.300000000000e+01 1.100000000000e+01), ray dir = (1.000000000000e+00 0.000000000000e+00 -1.366428338000e-16) |
| 13:13.37 | cvds_ | and technically its not "typing" delete but pressing the delete key :) |
| 13:14.30 | cvds_ | but its indeed curious why its linked to exit, ctrl-d works as well btw, but that I do find expectid behavior |
| 13:14.39 | cvds_ | expected* |
| 13:20.09 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 13:33.46 | cvds_ | another thing I noticed that after using red the comb_color will have reset |
| 13:50.47 | brlcad | which version are you using? |
| 14:02.54 | cvds_ | brlcad: http://pastebin.com/3VmSQiZt |
| 14:19.16 | brlcad | cvds_: for future reference, pastebin.com not only sucks but is inaccessible to most in the channel some of the time due to network blocks -- suggest pastebin.ca or paste.debian.org or just about any other ;) |
| 14:19.34 | brlcad | yeah, I'll verify, but I'm pretty sure that red bug was fixed in 7.20 |
| 14:23.26 | cvds_ | brlcad: okies, will divert to the debian one for further posts |
| 14:23.51 | cvds_ | first component is nearing the done stage... took a long time |
| 14:26.13 | cvds_ | well the first version... no doubt that after printing I will be making adjustments |
| 14:41.35 | starseeker | cusses Windows and Tcl/Tk both |
| 14:42.11 | starseeker | just when I thought I finally had this licked, I can't get wish going on Win32 with 8.6 |
| 14:49.02 | brlcad | heh |
| 14:49.19 | brlcad | cvds_: would love to see pics of your work (before and after printing) |
| 15:10.57 | cvds_ | brlcad: Maybe I can post some renders on flickr later today |
| 15:12.28 | cvds_ | last couple of primitives to add |
| 16:01.08 | cvds_ | brlcad: http://flic.kr/s/aHsjwoVYoK |
| 16:07.48 | starseeker | growses... what's the poing of a HAVE_ZLIB flag if you're going to guarantee you always have zlib... |
| 16:17.38 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 16:57.14 | brlcad | cvds_: that's pretty awesome! |
| 16:57.26 | brlcad | so you're going to have that geometry printed? |
| 16:57.56 | brlcad | either way, pretty cool .. nice level of detail |
| 16:57.59 | brlcad | what is it? :) |
| 16:58.02 | cvds_ | brlcad: yes, but have to build the printer first :) |
| 16:58.31 | cvds_ | its a finger switch with 5 directions, N E S W and down |
| 16:59.36 | cvds_ | and I would not be amazed that I need to adjust some of it to make it printer compitable |
| 16:59.46 | cvds_ | comaptible* |
| 17:02.02 | cvds_ | hmm here is to hoping I can fit the 2 missing optocoupler space |
| 17:02.03 | cvds_ | s |
| 17:15.13 | *** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 17:59.12 | cvds_ | and thanks for the compliment |
| 18:01.50 | cvds_ | hmm a raytrace from a sliced version takes way longer |
| 18:23.47 | *** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 19:16.04 | cvds_ | brlcad: more renders: http://flic.kr/s/aHsjwoVYoK |
| 20:11.25 | CIA-48 | BRL-CAD: 03abhi2011 * r47270 10/brlcad/trunk/src/libged/simulate/ (7 files): Separated the list of manifolds generated by bullet and that generated by rt, as they are required at different times during the simulation iterations |
| 20:24.51 | CIA-48 | BRL-CAD: 03abhi2011 * r47271 10/brlcad/trunk/src/libged/simulate/ (simrt.c simulate.h): Corrected some errors in setting up the linked list |
| 20:56.25 | CIA-48 | BRL-CAD: 03abhi2011 * r47272 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simrt.c): Corrected some code for generating the normals and depth values correctly |
| 23:27.01 | CIA-48 | BRL-CAD: 03abhi2011 * r47273 10/brlcad/trunk/src/libged/simulate/simcollisionalgo.cpp: The manifold points were not getting inserted correctly, fixed it to some extent, still cant keep objects steady on top of each other, hunting for what I am missing out |
| 23:55.05 | starseeker | cvds_: the -k option to rt is helpful when you're doing sliced views |
| 23:55.24 | starseeker | (think it's -k - the cutting plane) |
| 00:17.28 | CIA-48 | BRL-CAD: 03abhi2011 * r47274 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simrt.c): |
| 00:17.28 | CIA-48 | BRL-CAD: More changes to help in debugging, disabled rayshooting for now, generating |
| 00:17.28 | CIA-48 | BRL-CAD: points only from the overlap region as I am debugging the case of a small box |
| 00:17.28 | CIA-48 | BRL-CAD: lying on a thin but larger box, so the overlap region can be used to generate |
| 00:17.28 | CIA-48 | BRL-CAD: correct contact pairs. Apparently the contact pairs are getting inserted but are |
| 00:17.29 | CIA-48 | BRL-CAD: not making it till the dynamics component of Bullet |
| 01:15.28 | brlcad | abhi2011: BU_STR_EQUAL() is your friend |
| 01:18.51 | abhi2011 | brlcad: ah yes, I forgot that macro |
| 01:58.54 | brlcad | exists specifically to avoid that common logic bug and to improve readability |
| 07:23.54 | CIA-48 | BRL-CAD: 03d_rossberg * r47275 10/brlcad/trunk/src/archer/CMakeLists.txt: the DESTINATION of FILE(COPY ~) is a directory |
| 08:28.00 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 11:22.08 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 13:00.05 | cvds_ | starseeker: thanks |
| 13:00.26 | cvds_ | for the -k tip, will need to try that for the next render batch |
| 14:20.12 | brlcad | -k should be a good bit faster than manually creating a cut view yourself (if it's not, file a report!) :) |
| 14:28.21 | CIA-48 | BRL-CAD: 03erikgreenwald * r47276 10/brlcad/trunk/src/libgcv/bottess.c: Bump up memory pool grow size. Add face splitting for vert/line case. Step back indices on split to make sure all splits are computed. |
| 14:57.44 | CIA-48 | BRL-CAD: 03erikgreenwald * r47277 10/brlcad/trunk/src/libgcv/bottess.c: collapse switch down to math and ternaries |
| 16:56.27 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 17:35.43 | CIA-48 | BRL-CAD: 03erikgreenwald * r47278 10/brlcad/trunk/src/libgcv/bottess.c: Woops, triangles should be CCW, not CW |
| 17:53.12 | CIA-48 | BRL-CAD: 03erikgreenwald * r47279 10/brlcad/trunk/src/libgcv/bottess.c: cheesy hardcoded stl output to avoid the nmg mess for now |
| 19:56.36 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 19:56.54 | cvds_ | brlcad: it would also clutter the database less ;) |
| 20:29.03 | CIA-48 | BRL-CAD: 03erikgreenwald * r47280 10/brlcad/trunk/src/libgcv/bottess.c: add in/out classifier to vert/line splitter |
| 23:43.01 | CIA-48 | BRL-CAD: 03abhi2011 * r47281 10/brlcad/trunk/src/libged/simulate/simcollisionalgo.cpp: Debugging continues, apparently the points in rigid body A which is calculated from the point for B and the normal pointing from A to B, is not getting calculated |
| 00:55.39 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 00:55.39 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) | |
| 00:55.39 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 00:55.39 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 00:55.39 | *** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 04:34.59 | CIA-48 | BRL-CAD: 03abhi2011 * r47282 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simrt.c): Some corrections to normals and contact pair generation |
| 05:25.52 | abhi2011 | hmm, I need to call the rt related C functions from the c++ code of Bullet's physics pipeline |
| 05:26.22 | abhi2011 | however when I try to call them from within the C++ code, I see to run into undefined reference errors |
| 05:26.40 | abhi2011 | even though I have declared the functions by including the header |
| 05:27.20 | abhi2011 | is it possible to directly call C functions from within C++ |
| 05:29.49 | abhi2011 | hmm there seems to be some compiler mangling of C functions going on, need to smooth the linkage |
| 05:31.02 | abhi2011 | this is turning out to be really loopy....from C code of libged >>>> C++ Code of Bullet >>> C code of RT to get the contact pairs >>>> C++ code of bullet for dynamics >>>> back to C code of libged to finish off |
| 05:38.38 | abhi2011 | ok some useful info here : http://developers.sun.com/solaris/articles/external_linkage.html |
| 05:49.03 | abhi2011 | hmm got around the linkage issue, seems raytracing code has to be inserted right into the bullet nearphase callback to ensure contact pairs are generated at the right place |
| 06:35.27 | *** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ) | |
| 08:29.15 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 11:12.36 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 14:27.58 | CIA-48 | BRL-CAD: 03erikgreenwald * r47283 10/brlcad/trunk/src/libgcv/bottess.c: Finish up split cases. Fix bug in composer that didn't throw away faces. Combine both triangle sets in composer. |
| 14:33.04 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 14:43.21 | CIA-48 | BRL-CAD: 03erikgreenwald * r47284 10/brlcad/trunk/src/libgcv/bottess.c: collapse switch into ternary/math |
| 14:46.50 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:00.42 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 15:18.00 | CIA-48 | BRL-CAD: 03abhi2011 * r47285 10/brlcad/trunk/src/libged/simulate/ (7 files): Moving towards tighter integration of raytracing with the Bullet pipeline to ensure the contact pairs are injected at the right point during the simulation, added some extern C linkage code to allow this integration |
| 15:29.33 | abhi2011 | cant seem to find a way to get rid of this warning : http://bin.cakephp.org/view/975048800 |
| 17:16.07 | tofu | abhi2011: that's not your problem .. it's a valid warning when compiling that C struct within the context of a C++ file |
| 17:17.18 | abhi2011 | tofu: ok |
| 18:34.05 | tofu | basically, there's a C function (ged_view()) and a struct named ged_view .. |
| 18:34.57 | tofu | struct is == class when compiling in C++, so when it creates the default constructor (ged_view()) it ends up shadowing the existing function |
| 19:26.51 | CIA-48 | BRL-CAD: 03brlcad * r47286 10/brlcad/trunk/ (Makefile.am configure.ac): |
| 19:26.51 | CIA-48 | BRL-CAD: add the tar-ustar option to AM_INIT_AUTOMAKE so that we're not limited to paths |
| 19:26.51 | CIA-48 | BRL-CAD: 99 chars or less. ustar increases the limit to 256 chars (tar-pax would |
| 19:26.51 | CIA-48 | BRL-CAD: increase it to unlimited, but requires 1.9). this effectively drops |
| 19:26.51 | CIA-48 | BRL-CAD: out-of-the-box build support on Mac OS X 10.4 but it's an old system and |
| 19:26.52 | CIA-48 | BRL-CAD: autotools is almost out the door so allow the bump in order to get a valid |
| 19:26.53 | CIA-48 | BRL-CAD: release tarball. |
| 19:45.59 | CIA-48 | BRL-CAD: 03abhi2011 * r47287 10/brlcad/trunk/src/libged/simulate/ (7 files): Removed 2 linked lists and replaced with static allocation, dynamic memory is more of a hassle than its worth |
| 20:46.20 | CIA-48 | BRL-CAD: 03brlcad * r47288 10/brlcad/trunk/src/tclscripts/mged/reid.tcl: accept reid patch from carl moore that reorganizes the arg checking logic and reports a statement when the assembly is not a combination. |
| 20:54.47 | CIA-48 | BRL-CAD: 03brlcad * r47289 10/brlcad/trunk/src/tclscripts/mged/reid.tcl: dry principle, put usage in only one place to reduce logic |
| 20:57.23 | CIA-48 | BRL-CAD: 03brlcad * r47290 10/brlcad/trunk/AUTHORS: credit carl moore from ARL for tclscript patches (reid/remat/relos) |
| 20:59.33 | CIA-48 | BRL-CAD: 03brlcad * r47291 10/brlcad/trunk/src/tclscripts/mged/remat.tcl: another change from carl moore, making remat similarly report 'Not a combination.' if the assembly isn't a comb. |
| 21:02.29 | CIA-48 | BRL-CAD: 03brlcad * r47292 10/brlcad/trunk/src/tclscripts/mged/relos.tcl: add a new 'relos' command, similar to reid and remat, contributed from carl moore of ARL. |
| 21:02.52 | CIA-48 | BRL-CAD: 03brlcad * r47293 10/brlcad/trunk/src/tclscripts/mged/ (CMakeLists.txt Makefile.am): add the new relos.tcl file to the build/install/dist |
| 21:03.27 | CIA-48 | BRL-CAD: 03brlcad * r47294 10/brlcad/trunk/src/tclscripts/mged/relos.tcl: fix header |
| 21:04.56 | CIA-48 | BRL-CAD: 03brlcad * r47295 10/brlcad/trunk/src/tclscripts/mged/help.tcl: apply final patch from carl moore, updating documentation to reflect the new relos command |
| 21:05.54 | CIA-48 | BRL-CAD: 03abhi2011 * r47296 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simutils.c): Corrected some indexing errors which arose while removing the linked lists |
| 21:08.09 | CIA-48 | BRL-CAD: 03brlcad * r47297 10/brlcad/trunk/NEWS: credit carl moore with his last-minute contribution of a new 'relos' command to mged. similar to remat, assigns the specified los to all regions under a given assembly. |
| 22:38.19 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 23:10.52 | CIA-48 | BRL-CAD: 03abhi2011 * r47298 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simrt.c): Corrected manifold point generation again to report the deepest points as those belonging to body B |
| 01:23.21 | *** join/#brlcad Otto_ (~Otto@cpe-24-210-25-11.columbus.res.rr.com) | |
| 01:26.38 | *** part/#brlcad Otto_ (~Otto@cpe-24-210-25-11.columbus.res.rr.com) | |
| 02:16.29 | CIA-48 | BRL-CAD: 03brlcad * r47299 10/brlcad/trunk/ (configure.ac src/other/Makefile.am): turn off our libpng subbuild entirely by default, even for enable-all, just so we're closer to a clean autotool distcheck for release |
| 02:40.07 | CIA-48 | BRL-CAD: 03brlcad * r47300 10/brlcad/trunk/doc/docbook/Makefile.am: typo, should be CatalogManager.properties |
| 07:26.20 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 12:09.45 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 14:56.06 | CIA-48 | BRL-CAD: 03brlcad * r47301 10/brlcad/trunk/doc/docbook/Makefile.am: this looks like the last problem remaining with the autotools distcheck. there are two files being generated in resources/brlcad that do not belong in the dist that were causing a problem. have to itemize. |
| 15:01.07 | CIA-48 | BRL-CAD: 03brlcad * r47302 10/brlcad/trunk/doc/docbook/Makefile.am: uncomment, was just for debugging |
| 15:01.45 | brlcad | abhi2011: how's it going? been a while since checked in on progress |
| 15:01.52 | brlcad | been watching the commits |
| 15:03.26 | abhi2011 | well brl-cad I am just putting up some pictures in web log explaining my work so far :) |
| 15:03.39 | brlcad | excellent :) |
| 15:03.51 | abhi2011 | so basically I have inserted a custom algorithm for collision detection between 2 boxes |
| 15:04.09 | abhi2011 | and this algorithm inserts manifold points |
| 15:04.13 | CIA-48 | BRL-CAD: 03erikgreenwald * r47303 10/brlcad/trunk/src/libgcv/bottess.c: fix bad comparison in 5 face split |
| 15:04.24 | abhi2011 | generated by raytracing in the overlap region(aabb overlap region) |
| 15:04.51 | abhi2011 | however when I do this I am not able to make a smaller box lie still on a thinner but bigger one |
| 15:05.31 | abhi2011 | so I am trying to figure out why bullet is not keeping the smaller box stable, even though I insert manifold points exactly as bullet does |
| 15:06.03 | abhi2011 | it involves investigating the dynamics part of bullet |
| 15:06.18 | abhi2011 | which is not the easiest thing I have done so far :P |
| 15:06.37 | abhi2011 | so I have posted the issue in the bullet forums |
| 15:06.40 | brlcad | lie still? |
| 15:06.45 | abhi2011 | yes |
| 15:06.56 | abhi2011 | if a box is lying on a plane |
| 15:07.04 | abhi2011 | it will stay as it is |
| 15:07.21 | abhi2011 | that is what I meant by lying still...stationery |
| 15:07.22 | brlcad | because the bb's don't overlap |
| 15:07.44 | abhi2011 | well, actually they overlap very slightly |
| 15:07.51 | abhi2011 | about 0.00001 m |
| 15:07.53 | brlcad | k |
| 15:08.06 | abhi2011 | thats allowed for smooth physics |
| 15:08.15 | brlcad | so that creates a contact interface, presumably |
| 15:08.16 | abhi2011 | some interpenetration is necesssary |
| 15:08.34 | abhi2011 | yes correct |
| 15:08.59 | brlcad | so can you explain the general algorithm to me? or is it written down somewhere? |
| 15:09.08 | brlcad | given two arbitrary bb's |
| 15:09.11 | abhi2011 | yes sure, its quite simple |
| 15:09.12 | abhi2011 | yes |
| 15:09.56 | abhi2011 | so given 2 bounding boxes I calculate where they overlap |
| 15:10.06 | abhi2011 | that will also be a cuboidal volume |
| 15:10.10 | brlcad | giving some smaller intersection box |
| 15:10.20 | brlcad | smaller or equal, rather |
| 15:10.55 | abhi2011 | yes thats right |
| 15:11.25 | abhi2011 | the volume where the 2 aabbs intersect will of course be smaller than the 2 aabbs we are intersecting |
| 15:11.34 | abhi2011 | or equal of they exactly overlap |
| 15:11.43 | abhi2011 | *if they |
| 15:11.47 | brlcad | nods |
| 15:12.30 | abhi2011 | so there is a function called get_overlap() in simrt.c which does this |
| 15:12.55 | abhi2011 | so once i have the overlap volume |
| 15:13.07 | abhi2011 | then I shoot rays along the x axis |
| 15:13.32 | abhi2011 | specifically from the minimum X towards the maximum X |
| 15:13.47 | abhi2011 | so if the overlap box is from -1,-1,-1 to 1,1,1 |
| 15:13.58 | abhi2011 | then I shoot rays from -1 to 1 parallel to x axis |
| 15:14.13 | abhi2011 | the rays will be perpendicular to the yz plane |
| 15:14.17 | brlcad | that will likely be insufficient (but can be fixed later) |
| 15:14.25 | brlcad | shooting down just one axis |
| 15:14.37 | abhi2011 | yes I intend to shoot along the y and z too |
| 15:14.53 | abhi2011 | but for the simple case that I am testing with |
| 15:15.00 | abhi2011 | its sufficient |
| 15:15.07 | brlcad | okay, though .. so you shoot a grid of rays (presumably with one_hit turned off?) |
| 15:15.20 | abhi2011 | so Iyes |
| 15:15.22 | abhi2011 | *yes |
| 15:15.36 | brlcad | so then you have partitions |
| 15:15.38 | abhi2011 | so the rays shoot though the overlap region |
| 15:15.40 | abhi2011 | yes |
| 15:15.41 | brlcad | segments |
| 15:15.46 | abhi2011 | I have a overlap callback |
| 15:15.59 | abhi2011 | which records the overlap partitions in a structure |
| 15:16.29 | abhi2011 | and I later analyze them to see the maximum X, min X etc when the ray is passing through a overlap region |
| 15:16.51 | abhi2011 | all goed so far :) |
| 15:17.51 | abhi2011 | so the place where say a ray enters a overlap region is a single point in 3D space |
| 15:17.59 | abhi2011 | so i make this one of the contact points |
| 15:19.41 | brlcad | what does bullet want? |
| 15:19.53 | abhi2011 | the contact points and the penetration depth |
| 15:20.07 | abhi2011 | so if a body A is penetrating body B |
| 15:20.08 | brlcad | do you just provide contact points, or points and vectors based on thickness of overlap? |
| 15:20.13 | brlcad | or a surface? |
| 15:20.40 | abhi2011 | I provide only the contact points for body B , the depth upto which body B has penetrated into body A and the normal from body B to A |
| 15:20.44 | abhi2011 | so 3 things |
| 15:21.00 | abhi2011 | so if we have a box lying on a ground plane |
| 15:21.12 | abhi2011 | and say the box is body A and the ground is B |
| 15:21.20 | abhi2011 | then A will slight penetrate B |
| 15:22.15 | abhi2011 | then I generate contact points for B, which will be slightly inside it |
| 15:22.25 | abhi2011 | the extent of penetration is the depth |
| 15:22.44 | abhi2011 | and the normal will simple be 0,0,1 (positive Z axis) |
| 15:23.02 | brlcad | abhi2011: hold up, gotta run out for a second .. very interesting, to be continued... :) |
| 15:23.14 | abhi2011 | yeah sure, will get some pics up meanwhile :) |
| 15:23.22 | brlcad | this is getting into meat and I'm sure I'll have more questions :) |
| 15:23.33 | abhi2011 | hehe |
| 15:30.30 | abhi2011 | right so since geometry is involves it will be easier to be on the same page (so to speak :P) : https://docs.google.com/drawings/d/1FVUPyeoq6YWHKPzlDadrZch8qOw0jBjeFgJ3FHtL1SE/edit?hl=en_GB |
| 15:52.58 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:58.13 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 16:00.19 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 16:39.19 | abhi2011 | more discussion here : http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=7517&p=25901#p25901 |
| 16:39.33 | abhi2011 | no replies however :( |
| 17:07.29 | brlcad | abhi2011: your message was trimmed :) |
| 17:07.52 | abhi2011 | in the forum ? |
| 17:07.55 | brlcad | yeah |
| 17:07.56 | abhi2011 | I am still updating it |
| 17:08.08 | abhi2011 | too much text to put in |
| 17:08.09 | brlcad | aha! i see |
| 17:08.24 | abhi2011 | the basic thing i want to convey is |
| 17:08.33 | abhi2011 | if i look at the bullet points |
| 17:08.43 | abhi2011 | i see A penetrate B initially |
| 17:08.53 | abhi2011 | but its gradually pushed out after iteration 12 |
| 17:09.00 | abhi2011 | and by 20 its quite stable |
| 17:09.09 | abhi2011 | however for me it justs keeps on sinking |
| 17:09.40 | brlcad | you mean some example that bullet provides? |
| 17:09.42 | abhi2011 | so the constraint solver is not constraining the contact points , which would have held the box foxed in 3d space |
| 17:10.04 | abhi2011 | no the example that I am discussing in that thread |
| 17:10.06 | brlcad | or just allowing the regular collision detection to work |
| 17:10.21 | abhi2011 | regular collision detection |
| 17:10.32 | brlcad | you're discussing a LOT of points in that thread |
| 17:10.45 | abhi2011 | if i allow regular collision detection to work then it holds the box stable on the plane |
| 17:11.16 | brlcad | might be part why there's no response .. there are lots of questions and they all probably warrant a fair bit of discussion :) |
| 17:11.37 | brlcad | you mean it's stable after 20 iterations |
| 17:11.51 | abhi2011 | hmm yeah, yet I am focussing on 1 very simple case, just that there is a lot to it |
| 17:12.07 | abhi2011 | injecting custom contact points takes some changes to the code |
| 17:12.21 | abhi2011 | yes its stable after 20 iterations |
| 17:12.32 | abhi2011 | using regular collision detection |
| 17:13.02 | abhi2011 | however if I start to inject my own contact points, then its not stable , the box passes right through the plane |
| 17:13.07 | abhi2011 | as gravity is acting |
| 17:13.43 | brlcad | so there's something happening with the default collision detection that you're not doing |
| 17:14.45 | abhi2011 | exactly |
| 17:14.54 | abhi2011 | i have been seaching for that |
| 17:15.14 | abhi2011 | the only interface is the addcontactpoints() function |
| 17:16.32 | brlcad | have you looked at the code for the default? |
| 17:16.46 | brlcad | or do they have an example that calls addcontactpoints() |
| 17:17.18 | abhi2011 | yes they have code that calls addcontactpoints() in their default box-box collider |
| 17:17.57 | abhi2011 | I dont see anything else being set, but its possible that some global member of derived member gets set in the 800 lines+ of code |
| 17:18.05 | abhi2011 | *or derived |
| 17:18.05 | brlcad | I'm thinking that you may have to not only provide the contact points and normals, but also invoke some callback to apply the forces |
| 17:18.29 | abhi2011 | yes that will happen automatically after the points are put in |
| 17:18.37 | abhi2011 | its all in 1 flow |
| 17:18.48 | abhi2011 | i just inject the points at the right point in the flow |
| 17:18.53 | brlcad | i'm saying maybe it's not automatic |
| 17:19.09 | brlcad | unless you set something that says "do it automatically" |
| 17:19.18 | abhi2011 | hmm, but the forces do act as otherwise the top box wouldnt move |
| 17:19.19 | brlcad | that would explain it |
| 17:19.33 | brlcad | there's still a global gravity force |
| 17:19.44 | abhi2011 | yes |
| 17:19.51 | brlcad | it's not applying the new force from the collision interaction |
| 17:20.05 | abhi2011 | yep, its pretty certain I am not doing something like that |
| 17:20.20 | brlcad | but then you've defined a cusom collision handler, so I could easily see them adding a callback or state value that lets you override/ignore/modify the force too |
| 17:20.40 | brlcad | the *collision/interaction* force |
| 17:20.49 | brlcad | force(s) |
| 17:21.16 | abhi2011 | yes, the thing is there is no callbacks in the force-application part of the pipeline |
| 17:21.40 | abhi2011 | only in the collision point generation part there is some callbacks and the possiblity to inject points |
| 17:21.53 | abhi2011 | so I ll go ahead with gdb |
| 17:22.16 | abhi2011 | and step through the force-application part and see whats happemning |
| 17:22.18 | brlcad | doesn't have to be a callback, could just be a bullet function that gets called (recalculateForcesBasedOnNewContactPoints()) |
| 17:22.41 | abhi2011 | yes |
| 17:22.46 | brlcad | or, like I said, some global environment set up that happens earlier |
| 17:23.20 | abhi2011 | yes |
| 17:23.49 | abhi2011 | but apart from that the algorithm is as shown in that google doc |
| 17:24.36 | abhi2011 | the rays are shot and the entry points can be converted to contact points ...and some extra logic of course for the depth and normals(VCROSS the points) |
| 17:25.31 | brlcad | nods (though I can't get to google docs until later) |
| 17:25.58 | abhi2011 | ok, yeah its the same picture as the one on the thread, the white colored background |
| 17:30.10 | abhi2011 | the last post summarizes it all |
| 17:36.42 | abhi2011 | wish there was a irc for Bullet too :) |
| 17:37.49 | brlcad | you mean like #bulletphysics? |
| 17:38.37 | abhi2011 | hehe clicked on it and got hopeful for a second :P |
| 17:38.52 | brlcad | hm? |
| 17:39.21 | abhi2011 | #bulletphysics is not an actual channel , I hoped it was |
| 17:39.31 | brlcad | it is |
| 17:39.39 | abhi2011 | oh wait the question mark came |
| 17:39.42 | abhi2011 | :P |
| 17:39.46 | abhi2011 | i ll try again |
| 17:39.57 | brlcad | just type /join #bulletphyics |
| 17:40.01 | abhi2011 | ah |
| 17:40.03 | abhi2011 | yes |
| 17:40.05 | abhi2011 | am in |
| 17:40.13 | abhi2011 | thanks :P |
| 17:41.25 | brlcad | abhi2011: have you read http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=5365&p=19270&hilit=+contact+pair+#p19270 ? |
| 17:41.59 | abhi2011 | no not yet, will have a look |
| 17:43.18 | brlcad | might not be related, but speaks some about contact pairs with a couple responses |
| 17:43.42 | abhi2011 | hmm it seems to add points over multiple iterations, I however add them in 1 shot as every iteration is a cold start |
| 17:43.58 | abhi2011 | that is from the beginning with world setup an everthing |
| 17:44.27 | brlcad | you using a btGImpactMeshShape ? |
| 17:44.34 | abhi2011 | no |
| 17:44.36 | abhi2011 | only boxes |
| 17:44.40 | abhi2011 | btBoxShape |
| 17:44.45 | brlcad | k |
| 17:45.24 | abhi2011 | for all BRL-CAD shapes (the actual shapes are of course resolved based on rt etc etc as dicussed before) |
| 17:46.07 | brlcad | hm, http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=7498&hilit=custom+collision implies there is a callback for adding contacts |
| 17:46.19 | brlcad | so perhaps the default is simply "do nothing" when you override |
| 17:46.35 | brlcad | or setCollisionFlags() needs some magic |
| 17:48.09 | brlcad | interesting snippet that uses ray casting for collision detection (car demo) |
| 17:48.09 | brlcad | http://code.google.com/p/game-ws/source/browse/branches/cardemo/src/raycast_car.cpp |
| 17:48.32 | abhi2011 | oh awesome |
| 17:48.34 | abhi2011 | :) |
| 17:52.30 | brlcad | calculateCombinedRestitution() looks somewhat important |
| 17:53.09 | brlcad | along with the CF_CUSTOM_MATERIAL_CALLBACK collision flag |
| 17:53.28 | abhi2011 | yes, I think those will be called anyway as those parts are unchanged |
| 17:53.48 | brlcad | the example I was looking at called them directly |
| 17:53.54 | abhi2011 | hmm will verify that though |
| 17:54.00 | abhi2011 | yes |
| 18:07.36 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 18:13.23 | CIA-48 | BRL-CAD: 03n_reed * r47304 10/brlcad/trunk/src/other/step/src/express/express.c: add token printing debug routine |
| 18:17.18 | CIA-48 | BRL-CAD: 03brlcad * r47305 10/brlcad/trunk/doc/docbook/Makefile.am: DO need the catalogs to be listed as BUILT_SOURCES so that they're properly cleaned up for distclean. hopefully the last dist issue. |
| 18:18.27 | abhi2011 | hmm I think I see a way out of this mess :p |
| 18:18.56 | abhi2011 | so there are basically 2 approaches possible for supporting arbitrary shapes inside Bullet |
| 18:19.53 | brlcad | yes? |
| 18:19.57 | abhi2011 | 1. The more 'low level' one , where , whenever a body touches another body , I let them penetrate a bit so I can detect the overlap using rays and generate contact points |
| 18:20.29 | abhi2011 | these contact points are injected into the bullet physics pipeline and are kept fixed in space by the constraint solver |
| 18:20.37 | abhi2011 | thus fixing the body they belong to, also in space |
| 18:20.49 | abhi2011 | 2. The more higher level approach |
| 18:21.00 | abhi2011 | which the raycast vehicle appears to use |
| 18:21.10 | abhi2011 | detect overlap using raycast as usual |
| 18:21.18 | abhi2011 | however apply the force yourself |
| 18:21.28 | abhi2011 | at the contact point |
| 18:21.46 | abhi2011 | instead of hoping-against-hope that bullet will do it for you :P |
| 18:22.02 | abhi2011 | which it wont :) |
| 18:22.35 | abhi2011 | so I think this should work for convex shapes too and any arbitrary shape |
| 18:23.29 | abhi2011 | except that the force at the contact point has to applied in the right direction : normal to the surface, and also on both bodies |
| 18:23.42 | abhi2011 | but then there is the question of how much force to apply |
| 18:24.29 | abhi2011 | that has to be calculated using restitution etc and then there is friction, so basically doing a lot of the stuff that bullet should do |
| 18:26.16 | abhi2011 | hmm guess I ll take the second approach for now since it seems to offer some control over the restitution etc too |
| 18:30.37 | abhi2011 | for calculating the magnitude of force to be applied at the point of contact, I would need to acceleration of the body in the previous frame |
| 18:32.20 | abhi2011 | concave objects can have multiple overlap regions(eg wine goblet lying on its side on the floor), but that can be dealt with later |
| 18:50.19 | brlcad | abhi2011: whichever path you plough down, handling the concave case is going to be critical |
| 18:50.52 | brlcad | it won't be usable for anything except very simple demos if it only supports convex shapes |
| 18:51.18 | brlcad | fun and neat, but not practical |
| 18:57.10 | CIA-48 | BRL-CAD: 03brlcad * r47306 10/brlcad/trunk/TODO: rtcheck within mged seems to be working just fine |
| 19:00.55 | CIA-48 | BRL-CAD: 03brlcad * r47307 10/brlcad/trunk/TODO: couldn't get red to crash with multiple/any blanks lines, so shoould be good to go for release. did notice that the mac input bug seems to be back, though. |
| 19:03.56 | ``Erik | hm, tesla lost the libel case against top gear |
| 19:04.03 | CIA-48 | BRL-CAD: 03brlcad * r47308 10/brlcad/trunk/doc/docbook/Makefile.am: define a creation rule for FOP_XML_CATALOG too since it's also a dep on all |
| 19:28.29 | CIA-48 | BRL-CAD: 03bob1961 * r47309 10/brlcad/trunk/src/tclscripts/lib/Accordian.tcl: This is an implementation in Itcl/Itk of an Accordian widget. Internally it uses ttk widgets. |
| 19:29.25 | CIA-48 | BRL-CAD: 03bob1961 * r47310 10/brlcad/trunk/src/tclscripts/lib/CMakeLists.txt: Added an entry for Accordian.tcl |
| 19:49.21 | abhi2011 | brlcad: yes i think concave objects will generally cause forces acting at various distances from the body's center leading to torques |
| 19:49.39 | abhi2011 | if these torques cancel each other out, the body will be stable |
| 19:51.06 | abhi2011 | like if we take the case of a marble dropping inside a cup |
| 19:51.56 | abhi2011 | then the forces acting on the bottom points of the marble as it makes contact with the base of the cup will stop its fall |
| 19:52.17 | abhi2011 | but contact with inside edges of the cup will cause it to roll about for some time |
| 19:57.33 | abhi2011 | i have 1 question though |
| 19:58.02 | abhi2011 | wlll the rays report the normals to the surfaces of objects |
| 19:58.42 | abhi2011 | even if the rays themsleves are entering the targetted object at an angle to the surface |
| 20:08.54 | brlcad | you can get the surface normals for all hit points |
| 20:09.20 | brlcad | RT_GET_NORMAL() as well as other means |
| 20:12.36 | CIA-48 | BRL-CAD: 03bob1961 * r47311 10/brlcad/trunk/src/tclscripts/lib/Accordian.tcl: Added the togglePanel method to cadwidgets::Accordian |
| 23:36.47 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 00:27.57 | abhi2011 | brlcad: ok :) |
| 05:02.16 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 06:43.04 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 12:58.52 | *** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 15:09.42 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 15:09.43 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 16:28.52 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 16:28.52 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 18:36.57 | *** join/#brlcad saltan (~lieven@d51530284.static.telenet.be) | |
| 18:37.18 | *** part/#brlcad saltan (~lieven@d51530284.static.telenet.be) | |
| 22:52.41 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 02:54.58 | brlcad | arrives in cali, stickers look awesome :) |
| 06:36.33 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 08:27.43 | starseeker | awesome! |
| 08:27.50 | starseeker | heads out |
| 09:05.29 | ``Erik | pics or it didn't happen |
| 11:38.55 | *** join/#brlcad mattS_ (792c03a7@gateway/web/freenode/ip.121.44.3.167) | |
| 11:40.00 | mattS_ | Hiya! |
| 11:40.30 | mattS_ | I'm trying to find the source code for rcc (presumably rcc.c?) |
| 11:40.52 | mattS_ | Can't sem to find it in SVN |
| 14:05.31 | *** join/#brlcad merzo (~merzo@53-130-132-95.pool.ukrtel.net) | |
| 14:27.05 | CIA-48 | BRL-CAD: 03bob1961 * r47312 10/brlcad/trunk/src/librt/primitives/bot/bot.c: Modified rt_bot_split_func() and rt_bot_sync_func() to NOT be recursive. Still a brute-force approach however (more to follow in this regard). |
| 14:38.54 | brlcad | howdy mattS_ |
| 14:39.38 | brlcad | mattS_: src/librt/primitives/rcc |
| 14:41.28 | brlcad | closely related to the general case in src/librt/primitives/tgc (truncated general cone) |
| 14:57.07 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:50.48 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 15:55.52 | CIA-48 | BRL-CAD: 03bob1961 * r47313 10/brlcad/trunk/src/librt/primitives/bot/bot.c: Using size_t for indices into stacks for rt_bot_split_func() and rt_bot_sync_func(). Note - struct rt_bot_internal should be using "size_t *" instead of "int *" for the faces and face_normals members. |
| 16:57.56 | CIA-48 | BRL-CAD: 03n_reed * r47314 10/brlcad/trunk/src/other/step/ (6 files in 3 dirs): Developing routine to print parser return object, useful for inferring parser behavior. |
| 16:58.46 | CIA-48 | BRL-CAD: 03abhi2011 * r47315 10/brlcad/trunk/src/libged/simulate/ (6 files): |
| 16:58.46 | CIA-48 | BRL-CAD: Added tick callbacks to apply forces, the current plan is to balance objects |
| 16:58.46 | CIA-48 | BRL-CAD: correctly by applying an appropriate force on them when they collide. The force |
| 16:58.46 | CIA-48 | BRL-CAD: will be applied through the center of the contact volume. Friction forces have |
| 16:58.46 | CIA-48 | BRL-CAD: to calculated explicitly but we will cross that bridge once objects can be kept |
| 16:58.46 | CIA-48 | BRL-CAD: stable upon each other. |
| 17:11.29 | CIA-48 | BRL-CAD: 03abhi2011 * r47316 10/brlcad/trunk/src/libged/simulate/ (8 files): Indentations corrected in simulate files |
| 17:18.37 | CIA-48 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3182 10/wiki/User:Abhijit: /* Log */ |
| 20:27.12 | mattS_ | brlcad: Yeah, that's where I thought it would have been too. But alas... |
| 22:00.34 | *** join/#brlcad mattS_ (792c03a7@gateway/web/freenode/ip.121.44.3.167) | |
| 22:11.21 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 22:35.32 | CIA-48 | BRL-CAD: 03n_reed * r47317 10/brlcad/trunk/src/other/step/src/express/expprint.c: making progress; learning about the Express object structure as I go |
| 22:36.35 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 01:37.51 | brlcad | mattS_: what do you mean ... alas, you found it? |
| 01:39.34 | brlcad | oh right, sorry mattS_ -- rcc is *just* a specialization of tgc, so the source link I mentioned for tgc is the one you want |
| 03:30.13 | mattS_ | Hence why I could not find the rcc.c code :-) Thanks, this has helped. Revolve coming along nicely, just slowly. Full time job and all that sort of stuff getting in the way of fun! |
| 05:19.35 | brlcad | mattS_: as soon as you have anything that works better, you're welcome to submit a patch so someone can review and integrate it |
| 05:20.56 | brlcad | as long as it compiles and is an improvement, it's worth making a patch for it -- "svn diff > mychanges.patch" will make the patch for you if you have an svn checkout |
| 05:22.09 | brlcad | also, the smaller the patch, the easier it is to review and integrate, so emphasis that the feature doesn't have to be "complete" .. if you get something working, make a patch, upload it to sourceforge, and that'll also give other devs a chance to review and comment on it |
| 05:35.26 | mattS_ | That is my basic plan, but my programming skills are really quite poor. So, I've sketched out how to "complete" the tool, and am ironing all the (mathematical) kinks out. I will require a fair bit of input to get the code working, though... |
| 05:42.38 | mattS_ | Probably require, that is. |
| 07:03.22 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 09:47.53 | cvds_ | ted and red grow on you when you are used to them. Just wondering why ted must be called from inside sed mode |
| 10:37.57 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 13:29.05 | *** join/#brlcad merzo (~merzo@181-75-133-95.pool.ukrtel.net) | |
| 15:26.01 | CIA-48 | BRL-CAD: 03AbbyStokes 07http://brlcad.org * r3183 10/wiki/Overview: |
| 15:28.28 | CIA-48 | BRL-CAD: 03AbbyStokes 07http://brlcad.org * r3184 10/wiki/Building_from_SVN: /* Obtain the sources */ |
| 15:29.24 | cvds_ | new renders of a simplified design: http://flic.kr/s/aHsjwsSZmT |
| 15:55.41 | CIA-48 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:AbbyStokes]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 15:56.01 | CIA-48 | BRL-CAD: 03Sean 07http://brlcad.org * r3185 10/wiki/Overview: Reverted edits by [[Special:Contributions/AbbyStokes|AbbyStokes]] ([[User talk:AbbyStokes|Talk]]); changed back to last version by [[User:Sean|Sean]] |
| 15:56.25 | CIA-48 | BRL-CAD: 03Sean 07http://brlcad.org * r3186 10/wiki/Building_from_SVN: Reverted edits by [[Special:Contributions/AbbyStokes|AbbyStokes]] ([[User talk:AbbyStokes|Talk]]); changed back to last version by [[User:Willdye|Willdye]] |
| 16:09.37 | *** join/#brlcad ibidem (~idunham@scfib1G217.snowcrest.net) | |
| 16:10.19 | ibidem | trying to build brlcad on debian squeeze |
| 16:11.12 | ibidem | have the dependencies installed, ./configure works |
| 16:12.30 | ibidem | but when I compile, it errors out in librt |
| 16:17.06 | ibidem | apparently search.c has several static declarations while search.h has nonstatic declarations |
| 16:19.11 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 16:25.06 | ibidem | i'd guessed that it might be from using the wrong yacc version |
| 16:26.15 | ibidem | but it looks like search.{c,h} aren't generated by yacc |
| 16:55.28 | ibidem | well, I got librt to compile |
| 16:55.58 | ibidem | s/^int/static int/ |
| 16:56.25 | ibidem | on search.h |
| 16:56.55 | ibidem | was that a bad idea? |
| 17:08.17 | brlcad | ibidem: no, that should be fine |
| 17:21.11 | ibidem | ok, just got it installed--no more problems |
| 17:45.33 | ibidem | one more thing-apparently archer needs tools.png installed before it will run |
| 17:46.24 | ibidem | copy that over and archer runs fine on squeeze |
| 19:25.12 | CIA-48 | BRL-CAD: 03brlcad * r47318 10/brlcad/trunk/src/librt/ (search.c search.h): ibidem (via irc) noted a declaration mismatch between search.h and search.c; eliminate the unnecessary forward declarations save for the few c_* callbacks used in the options array. |
| 19:26.13 | brlcad | ibidem: ah, that would probably be mismatch between the autotools build and our new cmake build |
| 19:28.18 | CIA-48 | BRL-CAD: 03brlcad * r47319 10/brlcad/trunk/src/tclscripts/archer/images/Makefile.am: tools.png missing from dist/install, thx to ibidem (via irc) for reporting issue. |
| 19:29.12 | brlcad | we're in the process of migrating to a new cmake-based build system, so the autotools infrastructure will be removed in a few months |
| 19:29.55 | brlcad | cvds_: that's a relic from mged's original heavy-modal heritage (ala vim) |
| 19:30.16 | brlcad | slowly migrating towards becomging completely modeless |
| 19:31.46 | brlcad | cvds_: you may like running rtwizard or manually running rtedge in overlay mode to emphasize the edges in your renderings ;) |
| 19:35.40 | CIA-48 | BRL-CAD: 03brlcad * r47320 10/brlcad/trunk/TODO: so sayeth bob, struct rt_bot_internal should be using size_t * instead of int * for the faces and face_normals members |
| 01:52.13 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 06:32.05 | cvds_ | hmm more low level command, must try those |
| 15:35.27 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 15:35.27 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 15:49.54 | CIA-48 | BRL-CAD: 03n_reed * r47321 10/brlcad/trunk/src/other/step/src/express/express.c: pass null to parser at eof |
| 16:14.35 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 20:31.59 | CIA-48 | BRL-CAD: 03n_reed * r47322 10/brlcad/trunk/src/other/step/src/express/expparse.y: Added missing rule assignment. Lemon parser now gives same (error) output as bison parser for all but ap239. |
| 22:46.54 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 00:30.34 | starseeker | gets back and prepares for round two |
| 04:57.39 | abhi2011 | hmm, so I am trying to figure out how to calculate the amount of force to be applied while simulating their fall from a height. |
| 04:57.50 | abhi2011 | here is the plan at the moment : https://docs.google.com/drawings/d/1Fp44t9AcZZurbNufXti64u-23CRjC49Z3r0WSmim5tU/edit?hl=en_GB |
| 04:58.07 | abhi2011 | so I plan to shoot rays in the overlap region |
| 04:58.39 | abhi2011 | and apply forces along the normals |
| 04:59.21 | abhi2011 | so for the box in the above figure, all the forces acting on it along the x-axis will cancel each other out |
| 04:59.39 | abhi2011 | and only the Z force will remain , pushing it up, |
| 05:00.25 | abhi2011 | this would be the case in the real world, with the reaction from the collision acting on the box to make it bounce on the GP(ground plane) |
| 05:02.31 | abhi2011 | however if I start summing the normals(encountered while shooting rays) for the box I end up with something like 4.9999 , 3.9999, 6.00002 |
| 05:02.57 | abhi2011 | which is not pointing along +ve z as one would expect |
| 05:03.47 | abhi2011 | So I will probably, ignore a direction which I have encountered before |
| 05:12.19 | abhi2011 | that will I will need to store normals and check every new normal generated , with the previous ones |
| 05:47.37 | abhi2011 | instead of investigating the surface of a primitive using rays and shooting rays in a direction opposite to surface normals, I can also apply forces in a direction opposite to the velocity, but that will probably not work in all cases |
| 06:28.42 | CIA-48 | BRL-CAD: 03abhi2011 * r47323 10/brlcad/trunk/src/libged/simulate/ (6 files): Formatting corrections |
| 06:46.01 | *** join/#brlcad sashha (~saschi@77-22-42-58-dynip.superkabel.de) | |
| 06:46.06 | sashha | hello |
| 09:57.20 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 11:01.04 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 12:44.34 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 13:32.40 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 15:09.42 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 16:50.27 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 16:50.27 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 18:11.39 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 18:11.39 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 18:22.01 | brlcad | hellos sashha |
| 19:01.41 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 19:03.35 | brlcad | abhi2011: no // c++-style comments in .c file ... |
| 19:03.52 | brlcad | breaks the compilation for others |
| 19:15.16 | abhi2011 | oh shoot, I forgot to check that again, sorry about that |
| 20:20.53 | CIA-48 | BRL-CAD: 03n_reed * r47324 10/brlcad/trunk/src/other/step/src/express/resolve.c: remove dead code |
| 20:37.24 | *** join/#brlcad DarkCalf (DC@2002:ade7:2862::ade7:2862) | |
| 00:02.40 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 03:34.37 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 04:02.33 | CIA-48 | BRL-CAD: 03brlcad * r47325 10/brlcad/trunk/ (NEWS src/nirt/interact.c): |
| 04:02.33 | CIA-48 | BRL-CAD: add support for carriage returns in addition to newlines since nirt is doing |
| 04:02.33 | CIA-48 | BRL-CAD: it's own parsing thing. untested, but should just make windows-style text files |
| 04:02.33 | CIA-48 | BRL-CAD: act like they have double newlines (and should make ancient mac-style text files |
| 04:02.33 | CIA-48 | BRL-CAD: not look like a long single line). prompted by sf support request #3426854 from |
| 04:02.34 | CIA-48 | BRL-CAD: Fred W (NIRT scriptfile) where he assumedly ran into this issue. |
| 04:29.02 | CIA-48 | BRL-CAD: 03brlcad * r47326 10/brlcad/trunk/src/tclscripts/lib/Makefile.am: add new Accordian.tcl file to dist |
| 04:30.22 | CIA-48 | BRL-CAD: 03brlcad * r47327 10/brlcad/trunk/src/tclscripts/lib/Accordian.tcl: awesome to see this widget get implemented, but it started in 2011. add footer too. |
| 04:44.47 | brlcad | good luck starseeker :) |
| 04:52.18 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1128565147.dsl.bell.ca) | |
| 15:49.36 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 15:49.36 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 15:53.32 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 15:53.32 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 16:42.31 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 18:40.23 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 21:55.27 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 22:45.56 | CIA-48 | BRL-CAD: 03brlcad * r47334 10/brlcad/trunk/NEWS: |
| 22:45.56 | CIA-48 | BRL-CAD: bob added radio buttom options to archer for selecting among various lighting |
| 22:45.56 | CIA-48 | BRL-CAD: model styles particularly relevant for visualization of BoT models. the modes |
| 22:45.56 | CIA-48 | BRL-CAD: allow a user to specify double-sided polygon lighting so that even (incorrect) |
| 22:45.56 | CIA-48 | BRL-CAD: back-facing polygons will be visible. |
| 22:52.24 | brlcad | abhi2011: what was that google docs link? |
| 22:53.30 | abhi2011 | brlcad: https://docs.google.com/drawings/d/1Fp44t9AcZZurbNufXti64u-23CRjC49Z3r0WSmim5tU/edit |
| 22:55.53 | brlcad | thx |
| 22:56.00 | brlcad | abhi2011: presume you've read http://www.bulletphysics.org/mediawiki-1.5.8/index.php?title=Collision_Callbacks_and_Triggers yes? |
| 22:57.30 | abhi2011 | brlcad: yes I am aware of the callbacks and I use them to calculate the force at the right point, before the simulation step |
| 22:57.52 | abhi2011 | they do not however explain what to do , so as to insert contact points correctly in the pipeline |
| 22:57.59 | brlcad | abhi2011: the approach sounds good -- the only part I'm concerned about is whether manually calculating and applying forces yourself is necessary |
| 22:58.14 | abhi2011 | it probably is not |
| 22:58.38 | abhi2011 | however as a first shot we can try that |
| 22:58.49 | brlcad | applying forces won't take care of torque or friction .. and definitely no dynamic body behaviors |
| 22:58.59 | abhi2011 | meanwhile i havent removed any of the code pertaining to contact points |
| 22:59.11 | abhi2011 | yes , torque will be taken care of |
| 22:59.22 | abhi2011 | I have to only apply the force at a distance |
| 22:59.32 | abhi2011 | there is a API for that which I will use |
| 22:59.48 | abhi2011 | applyforce(vector) |
| 23:00.10 | abhi2011 | the dynamics part which actually calculates the position of the body is not touched |
| 23:00.27 | abhi2011 | that will come into action, after I apply the forces correctly |
| 23:00.33 | abhi2011 | so it will still work |
| 23:00.39 | abhi2011 | friction is just another force |
| 23:01.07 | abhi2011 | I can apply friction by calculating the tangent to the surface which is touching |
| 23:01.27 | brlcad | that's my point -- YOU have to do all that work |
| 23:01.36 | brlcad | so it'll only be as good as all of the various forces you desribe |
| 23:01.44 | brlcad | that's not at all optimal... |
| 23:02.49 | brlcad | not that it's not doable -- it's that it's basically a potential subset of "real" behavior or even a subset of what bullet already calculates when left to it's own computations |
| 23:02.58 | abhi2011 | yes |
| 23:03.21 | brlcad | really sounds like we need to figure out what's up with the callbacks |
| 23:03.36 | brlcad | you call setCollisionFlags() ? |
| 23:03.40 | abhi2011 | yes |
| 23:03.55 | abhi2011 | the callbacks allow me to examine the contact points |
| 23:03.59 | abhi2011 | but not insert them |
| 23:04.53 | brlcad | I don't see any reference to CF_CUSTOM_MATERIAL_CALLBACK in existing code |
| 23:05.07 | brlcad | that seemed critical to several examples |
| 23:05.59 | brlcad | hm, I don't see setCollisionFlags() either for that matter.. |
| 23:06.05 | abhi2011 | yes, as when I last checked that, it was to set a custom friction specific to the material |
| 23:06.06 | brlcad | where is it being called? |
| 23:06.27 | abhi2011 | yes I had tried that, it is used in run_physics() |
| 23:06.35 | abhi2011 | *it was used there |
| 23:07.12 | abhi2011 | I used to set the collision flags, such that objects dont collide with each other at all |
| 23:07.22 | abhi2011 | and then apply forces |
| 23:07.35 | brlcad | the behavior you described earlier where you generated the contact manifolds, but they simply didn't cause a contact response really sounds related to the collision flags |
| 23:08.01 | brlcad | as that looks to be how bullet controls which callbacks are even called, which are used, and how updates are performed |
| 23:08.07 | abhi2011 | well collision flags are to filter out collisions between objects |
| 23:08.16 | abhi2011 | so if I want 2 objects to not collide |
| 23:08.24 | abhi2011 | then I will set differnt flags for themm |
| 23:08.36 | abhi2011 | thats what the examples do |
| 23:08.57 | abhi2011 | yes, during collision detection the flags are ANDed |
| 23:09.23 | abhi2011 | and if the result is false then for those 2 objectcs, there is no collision detection carried out |
| 23:09.29 | abhi2011 | that is what the collision flags are for |
| 23:09.45 | abhi2011 | they do not directly control the contact points |
| 23:09.46 | brlcad | ANDed? that'll zero it out unless it was already set |
| 23:10.05 | brlcad | ORd would be for setting a flag |
| 23:10.14 | abhi2011 | no by default bullet sets them all to one for all objects |
| 23:10.27 | abhi2011 | so all objects collide with each other |
| 23:10.40 | brlcad | blinks |
| 23:11.03 | brlcad | the "flags" represent more than just whether two objects collide |
| 23:11.06 | brlcad | that's just one of the flags |
| 23:11.37 | ``Erik | '!' != '~' |
| 23:11.43 | brlcad | bitwise |
| 23:11.51 | brlcad | | .. not & |
| 23:12.11 | brlcad | if you were using &, that would explain a lot |
| 23:12.45 | brlcad | the wiki docs have several examples where the flags are or'd |
| 23:12.56 | brlcad | refers to http://www.bulletphysics.org/mediawiki-1.5.8/index.php?title=Collision_Callbacks_and_Triggers |
| 23:13.45 | ``Erik | simpsons do mad men: http://www.youtube.com/watch?v=KcmM7Jh2Y3k |
| 23:14.46 | abhi2011 | yes but I do get use the contact callbacks, and they do get called when points are added or processed |
| 23:15.25 | abhi2011 | I get those callbacks even if I do not set mBody->setCollisionFlags(mBody->getCollisionFlags() | btCollisionObject::CF_CUSTOM_MATERIAL_CALLBACK); |
| 23:16.08 | abhi2011 | whenever 2 boxes overlap for example and I insert points using my own algorithm, then the contact added/contact processed callbacks etc are called |
| 23:16.30 | abhi2011 | thse callbacks are not the places where the contact points themselves are inserted |
| 23:16.46 | brlcad | abhi2011: sure, but if the right flags aren't set/unset, then the values might not get used (at all or correctly) |
| 23:17.04 | abhi2011 | thats is true |
| 23:17.05 | brlcad | what you described is that you added a bunch of contact points but they weren't getting used, right? |
| 23:17.11 | abhi2011 | yes |
| 23:17.24 | brlcad | that points almost directly at a statefulness problem |
| 23:17.35 | brlcad | which would be those silly flags |
| 23:18.03 | brlcad | you could try printing out the flags for the example code that works and the flags for your code, see how they differ |
| 23:18.07 | abhi2011 | thats is of course possible and I will try with that, however if that were the case, then bullet would not send me a contacts processed callback with the points that I inserted, |
| 23:18.36 | abhi2011 | yes I will try with the flags once more |
| 23:18.51 | brlcad | right, but one of the flags seemed to be a flag that toggled whether it needed to do anything |
| 23:19.13 | brlcad | if that flag was unset, it'd still make all the callbacks but not perform any collision response |
| 23:19.23 | abhi2011 | yes that is possible |
| 23:19.32 | brlcad | should hunt down the documentation on what all the flags are and what they do |
| 23:19.51 | abhi2011 | ok, yes I will have a more careful look at the flags |
| 23:21.47 | brlcad | cool |
| 23:23.59 | ``Erik | brlcad: any experience with apache mod_proxy ? |
| 23:24.37 | ``Erik | (I wanna futz with your server, but want second eyes before pulling the trigger) |
| 23:26.23 | brlcad | ``Erik: nope |
| 23:27.16 | ``Erik | 'k, I'll RCS up files before mods, I guess |
| 23:27.34 | ``Erik | (can all those bazillion *~ files in the httpd conf dir be shot?) |
| 23:29.39 | CIA-48 | BRL-CAD: 03abhi2011 * r47335 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simrt.c simulate.c): Putting up the code which uses only forces to stabilize objects, so I can refer to this later |
| 23:32.15 | brlcad | those ~ files are backup reference |
| 23:34.16 | ``Erik | dang emacs shenanigans O.o git init && git add -a . && git commit -m 'init' |
| 23:36.02 | brlcad | meh |
| 23:36.45 | brlcad | my method requires zero-effort and has been sufficient for decades :P |
| 23:40.25 | ``Erik | provided only emacs users admin it and only one level of mistake is made... :D |
| 23:46.25 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 00:18.24 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 01:22.10 | *** join/#brlcad yottabit (~heath@unaffiliated/ybit) | |
| 01:22.14 | *** part/#brlcad yottabit (~heath@unaffiliated/ybit) | |
| 01:35.55 | brlcad | like I said, zero-effort and has sufficient for decades :) |
| 04:06.18 | brlcad | gets through most of the trackers for the night |
| 07:05.54 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 09:29.51 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 09:33.35 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 10:34.08 | jordisayol | brlcad: I mistakenly closed "mged crash on startup - ID: 3341960" report. If you can reopen it please? sorry for that |
| 11:07.24 | brlcad | sure, np |
| 11:33.49 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 12:58.54 | d_rossberg | is there any template for writing a function to copy a nmg model? |
| 13:25.07 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 13:27.42 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 14:41.48 | brlcad | d_rossberg: there is nmg_dup_shell() in src/librt/primitives/nmg/nmg_misc.c |
| 14:43.05 | brlcad | it's not used anywhere so you may want to verify that it actually/still works, but it could be moved to an nmg_dup.c file and made into new public api if you need something like that |
| 14:44.08 | brlcad | otherwise, you could do what the 'clone' command does calling export on the nmg to create a copy |
| 14:46.18 | brlcad | i.e., rt_get_internal()+db_lookup() -> rt_put_internal() to an in-mem should do the trick |
| 14:46.38 | brlcad | nmg_dup_shell() is probably a better way, though :) |
| 15:23.39 | d_rossberg | thanks, as far as i can see nmg_dup_shell() is used in nmg_hollow_shell() (nmg_extrude.c) but it seems to be a good reference |
| 15:47.40 | CIA-48 | BRL-CAD: 03n_reed * r47336 10/brlcad/trunk/src/other/step/src/express/expparse.y: have lemon print message on stack overflow |
| 15:48.45 | CIA-48 | BRL-CAD: 03n_reed * r47337 10/brlcad/trunk/src/other/step/src/express/lexact.c: set dangling pointers to null |
| 16:07.27 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 16:07.27 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 16:42.30 | CIA-48 | BRL-CAD: 03n_reed * r47338 10/brlcad/trunk/src/other/step/src/express/error.c: s/malloc/calloc |
| 16:55.48 | CIA-48 | BRL-CAD: 03bob1961 * r47339 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Modified libtclcad/tclcad_obj.c/go_draw() to use ged_mike_persp_mat. This works better when drawing things in shaded mode. |
| 17:42.24 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 20:14.27 | starseeker | growls - alright, why is archer suddenly not showing raytracing? |
| 20:14.57 | starseeker | friggin external projectors... messed with my graphical setup good, apparently |
| 20:23.08 | brlcad | starseeker: another nice metric from today.. got a clean build on a 20-proc debian box |
| 20:23.29 | brlcad | not tried a debian build in several months, so good to see that's still working out of the box |
| 20:24.00 | brlcad | but more cool, the cmake build took about 1min 20sec vs about 3min for autotools :) |
| 20:24.48 | starseeker | hah - sweet! |
| 20:25.43 | starseeker | (that's a big Debian machine) |
| 20:25.48 | brlcad | of course, I'm assuming the builds were near parity, but neat nonetheless |
| 20:26.36 | starseeker | nods - should be pretty close now... is the step stuff still turned on in autotools? |
| 20:27.44 | starseeker | brlcad: is archer's raytracing working for you? (I think it's me, but a second datapoint would be nice) |
| 20:39.04 | brlcad | starseeker: works fine for me |
| 20:39.17 | starseeker | cool |
| 20:39.20 | starseeker | (phew) |
| 20:39.21 | brlcad | other than an hv3 error |
| 20:39.22 | brlcad | Error in -requestcmd home://blank/css/brlcad.css: wrong # args: should be "::hv3::request::inst1 m ..." |
| 20:39.27 | brlcad | during startup |
| 20:39.38 | starseeker | blinks - that should be gone in the latest trunk |
| 20:59.53 | brlcad | was a latest trunk build |
| 21:16.58 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 23:29.58 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 01:19.21 | starseeker | grr |
| 01:19.28 | starseeker | not seeing that here |
| 03:01.33 | CIA-48 | BRL-CAD: 03brlcad * r47340 10/brlcad/trunk/NEWS: |
| 03:01.34 | CIA-48 | BRL-CAD: (reword) erik added a new 'ringworld' procedural geometry generator tool that |
| 03:01.34 | CIA-48 | BRL-CAD: creates the Ringworld described in the 1970's novel by Larry Niven. next |
| 03:01.34 | CIA-48 | BRL-CAD: release is expected to be a minor bump with the various major features. |
| 03:04.21 | CIA-48 | BRL-CAD: 03brlcad * r47341 10/brlcad/trunk/ (NEWS include/conf/PATCH include/rt/): finally beginning final release steps for release 7.20.4, only three releases late. bump patch to release rev. |
| 03:15.16 | CIA-48 | BRL-CAD: 03brlcad * r47342 10/brlcad/trunk/ChangeLog: update changelog for 7.20.4 release with entries since the previous release. |
| 03:43.16 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 03:43.17 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 03:54.13 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 03:54.13 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 04:16.35 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 04:16.35 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 04:22.32 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 04:22.32 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 04:46.48 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 04:46.48 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 04:47.17 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 04:47.17 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 04:47.49 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 04:47.49 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 04:48.39 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 04:48.39 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 04:49.02 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 04:49.02 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 04:49.36 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 04:49.36 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 04:50.10 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 04:50.10 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 04:50.28 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 04:50.28 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 04:51.31 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 04:51.31 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 04:57.58 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 04:57.58 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 05:28.04 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 05:28.04 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 05:29.45 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 05:29.45 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 05:54.52 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 05:54.52 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 06:01.46 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 06:01.46 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 06:06.20 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 06:06.20 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 06:12.34 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 06:12.34 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 06:14.23 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 06:14.23 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 06:21.45 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 06:21.45 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 06:29.41 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 06:29.41 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 06:43.59 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 08:00.30 | CIA-48 | BRL-CAD: 03Phentermine 07http://brlcad.org * r3187 10/wiki/Main_Page: |
| 08:14.56 | CIA-48 | BRL-CAD: 03Sean 07http://brlcad.org * r3188 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/Phentermine|Phentermine]] ([[User talk:Phentermine|Talk]]); changed back to last version by [[User:Starseeker|Starseeker]] |
| 08:15.15 | CIA-48 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Phentermine]] with an expiry time of infinite (account creation disabled, e-mail blocked): Inserting nonsense/gibberish into pages |
| 08:19.35 | CIA-48 | BRL-CAD: 03brlcad * r47343 10/brlcad/branches/STABLE/ (12433 files in 654 dirs): merging trunk to STABLE from r45378 to HEAD r47342 for release 7.20.4 |
| 08:49.25 | CIA-48 | BRL-CAD: 03brlcad * r47344 10/brlcad/branches/STABLE/ (README src/libged/erase.c): changes from trunk slipped through merging somehow. sync. |
| 09:12.51 | CIA-48 | BRL-CAD: 03brlcad * r47345 10/brlcad/tags/rel-7-20-4/: finally tagging release 7.20.4 |
| 09:20.12 | CIA-48 | BRL-CAD: 03brlcad * r47346 10/brlcad/trunk/ (NEWS README include/conf/MINOR include/conf/PATCH): bump to 7.21.0 after tagging the 7.20.4 release in anticipation of a big upcoming 7.22.0 release |
| 09:20.32 | brlcad | tagged and bumped, but not posted .. will do that in a bit later, must take a lil break |
| 09:47.15 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 12:31.11 | ``Erik | cool, does server migration fit in after? |
| 13:48.27 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:01.40 | starseeker | hmm - this looks interesting |
| 15:01.43 | starseeker | https://github.com/antirez/linenoise |
| 15:03.36 | starseeker | or actually probably would want the jimtcl version, per tcl channel: |
| 15:03.40 | starseeker | https://github.com/msteveb/jimtcl/blob/master/linenoise.c |
| 15:03.54 | starseeker | https://github.com/msteveb/jimtcl/blob/master/linenoise.h |
| 15:06.04 | brlcad | ah, another one saying "I can do that in fewer lines of code" |
| 15:06.23 | brlcad | at which point they are fewer lines by eliminating various features they don't care about :) |
| 15:17.02 | starseeker | heh - true |
| 15:17.18 | starseeker | can be handy though if they're also features we don't care about |
| 15:18.01 | starseeker | wonders if the new coroutines in 8.6 might be of interest for our gui stuff... |
| 15:22.49 | starseeker | wonders if we're using tkcon or something else for our terminals... |
| 15:24.24 | starseeker | always the problem with attending conferences - I get a whole lot of hairbrained ideas I'd like to go try out... |
| 15:26.10 | CIA-48 | BRL-CAD: 03brlcad * r47347 10/brlcad/trunk/src/libbu/test_htond.c: remove commented out bulk conversion line |
| 16:09.32 | brlcad | starseeker: that's not a problem, that's one of the main points! |
| 17:16.02 | ``Erik | starseeker: are you back from the tcl conf? |
| 17:27.22 | CIA-48 | BRL-CAD: 03n_reed * r47348 10/brlcad/trunk/src/other/step/src/express/express.c: add declarations for lemon functions |
| 18:37.20 | CIA-48 | BRL-CAD: 03n_reed * r47349 10/brlcad/trunk/src/other/step/src/express/expparse.y: s/int/YYSTYPE for yylval. Incorrect type was causing memory corruption. |
| 18:57.23 | *** join/#brlcad abhi2011 (~chatzilla@117.200.81.138) | |
| 22:50.54 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 23:14.42 | brlcad | darn, tagged cmake build failed, autotools succeeded |
| 23:15.03 | brlcad | [ 11%] Building C object src/other/tk/CMakeFiles/tk.dir/unix/tkUnixRFont.c.o |
| 23:15.04 | brlcad | In file included from /Users/morrison/brlcad-7.20.4/src/other/tk/unix/tkUnixRFont.c:16: |
| 23:15.06 | brlcad | /usr/include/X11/Xft/Xft.h:41:35: error: fontconfig/fontconfig.h: No such file or directory |
| 23:15.09 | brlcad | In file included from /usr/include/X11/Xft/Xft.h:51, from /Users/morrison/brlcad-7.20.4/src/other/tk/unix/tkUnixRFont.c:16: |
| 23:15.12 | brlcad | /usr/include/X11/Xft/XftCompat.h:31: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?XftChar8? |
| 23:15.15 | brlcad | ... |
| 02:38.43 | starseeker | O.o |
| 02:38.49 | starseeker | what platform? |
| 02:39.03 | starseeker | is assuming mac with that path structure... |
| 02:39.26 | starseeker | do you have fontconfig.h anywhere? |
| 02:40.01 | starseeker | ``Erik: technically back, will be in Monday |
| 02:48.37 | starseeker | wishes in some ways Archer had gone with snit instead of incrTcl... oh well |
| 02:52.49 | starseeker | currently has the urge to rewrite Archer using the tktreectrl widget, snit and tkconv + whatever parts of tcl3d work reliably cross platform, but will recover by Monday :-P |
| 02:53.12 | starseeker | s/tkconv/tkcon |
| 02:57.00 | starseeker | aaaand my OSX build of trunk just succeeded |
| 02:57.03 | starseeker | (crud) |
| 06:55.20 | *** join/#brlcad abhi2011 (75c854c8@gateway/web/freenode/ip.117.200.84.200) | |
| 09:29.10 | *** join/#brlcad abhi2011 (75c85104@gateway/web/freenode/ip.117.200.81.4) | |
| 10:38.29 | *** join/#brlcad abhi2011 (~chatzilla@117.200.89.171) | |
| 11:02.27 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.242) | |
| 11:03.52 | abhi2011 | yet I know that SSL does work , as I am able to access sites like gmail etc |
| 11:13.41 | *** join/#brlcad abhi2011 (~chatzilla@117.200.92.212) | |
| 11:32.07 | CIA-48 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3189 10/wiki/User:Abhijit: /* Log */ |
| 11:57.42 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 12:07.07 | *** join/#brlcad abhi2011 (~chatzilla@117.200.84.101) | |
| 13:21.28 | brlcad | starseeker: yes mac, and fontconfig.h is in /usr/X11/include/fontconfig/fontconfig.h |
| 13:22.06 | brlcad | my trunk build succeeded, this was a checkout of the tagged 7.20.4 |
| 13:23.54 | brlcad | possible that something somewhere didn't merge due to a variety of custom non-merge edits that went into the STABLE branch |
| 14:41.21 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.102) | |
| 16:33.44 | abhi2011 | ok finally got a reply from Erwin |
| 16:34.26 | abhi2011 | he says the contact depths have to be negative to show that an object is penetrating another, which I have tried already of course |
| 16:34.50 | abhi2011 | I ll try with a simpler case of sphere-sphere collision and see what happens |
| 16:55.29 | brlcad | huh, freshmeat just changed their name to freecode |
| 17:26.58 | CIA-48 | BRL-CAD: 03brlcad * r47350 10/brlcad/trunk/src/libged/edit.c: quell mac strict compilation warnings, not liking the excessive constness casting. update ws/indent too. |
| 17:29.06 | CIA-48 | BRL-CAD: 03brlcad * r47351 10/brlcad/tags/rel-7-20-4/src/libged/edit.c: apply strict compilation warning fix that slipped through testing since tarball hasn't yet been posted. |
| 18:36.21 | brlcad | did a comparison of the flags used by autotools and the flags being used by cmake for the tk build and it's impressive that it works given all of the differences... slew of differences on the comand line declarations being used |
| 18:37.44 | brlcad | one of which being the cause of the compile failure, different sets of include paths being used, it's missing /usr/X11/include |
| 18:44.19 | brlcad | http://brlcad.org/tmp/cmake_fail.patch |
| 18:44.43 | brlcad | that's the diff of the same file being compiled by autotools and cmake |
| 18:45.22 | brlcad | adds a slew, omits a few, changes a few others, and same with includes |
| 18:50.35 | brlcad | should attempt to minimize/elimiate most of those differences .. each one is potentially an obscure bug that can cause differences and problems down the road (like now) |
| 19:19.54 | brlcad | this is very annoying.. i've removed all references to X11R6 from all our cmake files, yet it keeps finding and using it |
| 19:23.10 | brlcad | (and yes, cache files and such all deleted |
| 19:56.30 | brlcad | starseeker: you're going to have to teach me what I'm doing wrong sometime next week, because I've been fighting cmake all day now trying to add a basic cppflag and it's still not working... |
| 19:57.37 | brlcad | finally got it working by forcibly setting CMAKE_C_FLAGS, but there has to be a better way |
| 20:38.35 | CIA-48 | BRL-CAD: 03brlcad * r47352 10/brlcad/trunk/doc/docbook/ (CMakeLists.txt Makefile.am): ElNode.pm and read-db-xml.pl are missing from dist, add them |
| 20:43.27 | CIA-48 | BRL-CAD: 03brlcad * r47353 10/brlcad/tags/rel-7-20-4/: too many problems slipped through distcheck, including files missing from dist and a default cmake fail on mac 10.6. need to resync to STABLE and retag. |
| 20:45.15 | CIA-48 | BRL-CAD: 03brlcad * r47354 10/brlcad/trunk/NEWS: need to retag, update release date |
| 21:00.30 | CIA-48 | BRL-CAD: 03brlcad * r47355 10/brlcad/trunk/misc/CMake/FindX11.cmake: |
| 21:00.30 | CIA-48 | BRL-CAD: assuming the X11 include and lib search paths are in some sort of reverse |
| 21:00.30 | CIA-48 | BRL-CAD: priority order, sort them to help ensure system dirs take precedence over legacy |
| 21:00.30 | CIA-48 | BRL-CAD: package system dirs (except for /usr/local). make sure /usr/X11 comes 'before' |
| 21:00.30 | CIA-48 | BRL-CAD: (i.e., after due to reverse priority order?) the previous /usr/X11R6 convention. |
| 21:00.31 | CIA-48 | BRL-CAD: eliminate trailing ws waste too. |
| 21:10.06 | CIA-48 | BRL-CAD: 03brlcad * r47356 10/brlcad/trunk/misc/CMake/FindX11.cmake: having trouble believing the paths are really searched in reverse order, so reverse/revert the ordering. give 64-bit precedence. |
| 21:11.13 | CIA-48 | BRL-CAD: 03brlcad * r47357 10/brlcad/trunk/misc/CMake/FindGL.cmake: more X11 hard-coded path craziness. reorder and eliminate unnecessary trailing ws. |
| 21:15.20 | CIA-48 | BRL-CAD: 03brlcad * r47358 10/brlcad/trunk/src/other/ (6 files in 6 dirs): update the cmake copies (might make sense to make them use an svn:external so there is only one copy) |
| 21:33.43 | CIA-48 | BRL-CAD: 03brlcad * r47359 10/brlcad/trunk/src/other/step/include/: ignore scl_cf.h.in since autoheader will create it during autogen.sh |
| 22:19.07 | CIA-48 | BRL-CAD: 03brlcad * r47360 10/brlcad/trunk/src/util/pixclump.c: gcc 4.3.2 is curiously reporting that cte is exceeding the array bounds, but seems fine if we avoid the unsigned char pointer. possibly a bug or possibly valid detection of same bad pointer juju. either way, quelled. |
| 23:55.50 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 01:25.22 | *** join/#brlcad abhi2011 (~chatzilla@117.200.81.140) | |
| 01:40.48 | brlcad | apparently cmake has some parallel build race condition bug too... ended up compiling one file to a 0-length .o file, linking it in and naturally then resulting in undefined symbols |
| 01:50.03 | CIA-48 | BRL-CAD: 03brlcad * r47361 10/brlcad/trunk/src/conv/g-vrml.c: remove dead code, #if 0 |
| 01:50.59 | CIA-48 | BRL-CAD: 03brlcad * r47362 10/brlcad/trunk/src/conv/g-x3d.c: restructure bu exception handling into try/catch form, make 'reg' also be static in order to avoid gcc longjmp clobbering |
| 02:01.47 | CIA-48 | BRL-CAD: 03brlcad * r47363 10/brlcad/trunk/src/conv/intaval/regtab.h: quell warning about being unable to inline this constructor. move the init of desc over with the others. |
| 02:02.59 | CIA-48 | BRL-CAD: 03brlcad * r47364 10/brlcad/trunk/src/conv/ (36 files in 10 dirs): ws |
| 03:15.10 | starseeker | O.o |
| 03:15.17 | starseeker | has never encountered that... |
| 04:04.35 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 04:07.59 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 04:54.53 | *** join/#brlcad abhi2011 (~chatzilla@117.200.84.208) | |
| 06:16.33 | abhi2011 | hmm , the contact point approach works with the simple case of sphere-sphere collision |
| 06:16.42 | abhi2011 | forces are getting applied now |
| 06:16.55 | abhi2011 | lets see whats the issue with box shapes then |
| 07:08.17 | CIA-48 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3190 10/wiki/User:Abhijit: /* Log */ |
| 08:07.39 | *** join/#brlcad forth (~10497E4F9@92.242.118.253) | |
| 09:55.16 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 11:37.11 | *** join/#brlcad CIA-109 (~CIA@cia.atheme.org) | |
| 12:22.44 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.21) | |
| 12:46.07 | *** join/#brlcad abhi2011 (~chatzilla@117.200.83.165) | |
| 14:01.10 | CIA-109 | BRL-CAD: 03brlcad * r47365 10/brlcad/trunk/include/rt/defines.h: not yet used, but add the start of a common definitions file for librt just so this directory isn't empty |
| 14:02.38 | abhi2011 | ok now the box-box collision also works |
| 14:02.46 | abhi2011 | with contact pairs |
| 14:02.54 | abhi2011 | will try to roll a sphere on a plane |
| 14:03.33 | CIA-109 | BRL-CAD: 03brlcad * r47366 10/brlcad/trunk/include/ (CMakeLists.txt Makefile.am): add the new rt/defines.h header for install/dist |
| 14:07.48 | brlcad | abhi2011: so have you figured out what the problem was? |
| 14:08.10 | brlcad | too many contact points? |
| 14:08.18 | brlcad | wrong vector direction? |
| 14:08.21 | abhi2011 | yes, the problem seems to lie on the direction of the normals |
| 14:08.35 | brlcad | that'd 'splain it ;) |
| 14:08.37 | abhi2011 | which have to point from what ever object that bullet considers as object B |
| 14:08.46 | abhi2011 | to whichever points towards object A |
| 14:09.27 | abhi2011 | yes, I think I can try to roll a sphere now and see if I can generate contact points when its touching the ground |
| 14:09.47 | brlcad | awesome |
| 14:09.55 | abhi2011 | I have to use the curvature information of the sphere though, to ensure I dont generate more than 1 contact point |
| 14:10.16 | abhi2011 | as more than 1 point separated by a non zero distance would prevent its roll |
| 14:10.18 | abhi2011 | :) |
| 14:10.34 | abhi2011 | so some logic has to figured out there to work on all cases |
| 14:11.08 | brlcad | after that, a great test case for the ray casting would be to roll an ellipsoid down a bit bowl |
| 14:11.21 | abhi2011 | a bit bowl ? |
| 14:11.24 | abhi2011 | what does the bit mean |
| 14:11.44 | brlcad | a *big* bowl |
| 14:11.53 | abhi2011 | ah ok |
| 14:11.55 | abhi2011 | :P |
| 14:11.58 | brlcad | yeah :) |
| 14:12.03 | abhi2011 | yes |
| 14:12.11 | brlcad | a big concave dish |
| 14:12.17 | abhi2011 | yes, the thing that I have to think about though is |
| 14:12.33 | abhi2011 | that i can only generate contact points when objects interpenetrate |
| 14:13.05 | abhi2011 | which can cause the motion to be bumpy as an ellipsoid rolls along a bowl surface for example |
| 14:13.34 | brlcad | sure, maybe |
| 14:13.52 | brlcad | but if that can be reduced with more sampling points, that might just work fine |
| 14:14.08 | abhi2011 | maybe i can reduce the bumpiness to un-noticeable extents |
| 14:14.13 | brlcad | right |
| 14:14.16 | abhi2011 | ok |
| 14:14.58 | brlcad | by the way, there are lots of folks really excited about your work :) |
| 14:15.18 | brlcad | your quick youtube demo made the rounds amongst many of the expert modelers |
| 14:15.40 | brlcad | they loved it! .. of course wanting to try it right away |
| 14:15.48 | brlcad | told them they'll have to wait a bit still :) |
| 14:17.26 | abhi2011 | hehe, yes I am on it for sure, should have something by tomorrow hopefully :) |
| 14:17.54 | brlcad | well, I told them at least a month, so no worries :) |
| 14:18.03 | abhi2011 | and dont worry I ll keep working on it inspite of socis completing |
| 14:18.10 | abhi2011 | as i had promised :) |
| 14:18.27 | brlcad | that's great news ;) |
| 14:18.33 | brlcad | this is really going to be big |
| 14:19.42 | abhi2011 | cool, I am actually plannning to add this to Bullet also , so that it supports irregular objects, since the raytracing is done within the small overlap region and can be parallelized, it may be near real time |
| 14:31.08 | brlcad | that'd probably make a huge impact in their flexibility |
| 14:31.46 | brlcad | even for polygonal shapes, our ray engine can shoot a mesh prety darn fast |
| 14:32.33 | brlcad | starseeker: CPack Error: Cannot create symlink: .cmake/share/brlcad/7.20.3/html/presentations/en/images/tk-based-gui-for-mged.png--> /home/sean/brlcad/doc/docbook/presentations/en/images/tk-based-gui-for-mged.png |
| 14:56.50 | *** join/#brlcad abhi2011 (~chatzilla@117.200.83.165) | |
| 15:25.44 | *** join/#brlcad abhi2011 (~chatzilla@117.200.87.86) | |
| 15:27.14 | CIA-109 | BRL-CAD: 03brlcad * r47367 10/brlcad/trunk/NEWS: getting much closer, should be today if this last pass succeeds |
| 15:31.45 | CIA-109 | BRL-CAD: 03brlcad * r47368 10/brlcad/branches/STABLE/ (57 files in 26 dirs): again merging trunk to STABLE from r47343 to HEAD r47367, in prep for retagging release 7.20.4 |
| 15:51.00 | CIA-109 | BRL-CAD: 03brlcad * r47369 10/brlcad/trunk/doc/docbook/Makefile.am: update CatalogManager.properties file for autotools dist, in builddir, not srcdir |
| 16:02.20 | CIA-109 | BRL-CAD: 03brlcad * r47370 10/brlcad/branches/STABLE/doc/docbook/Makefile.am: merging trunk to STABLE from r47367 to HEAD r47369 |
| 18:00.51 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.50) | |
| 19:29.54 | brlcad | finishes implementing support for our whitespace indentation standard into astyle |
| 19:30.23 | brlcad | crappy indentation of continuations, though .. wonder if there's a way to fix that |
| 19:47.06 | brlcad | finishes what is hopefully the last distcheck for retag |
| 21:17.11 | starseeker | erm... is that CPack error consistent? |
| 21:17.53 | starseeker | astyle... cool! |
| 21:18.27 | starseeker | hopes he will accept the patch |
| 21:20.30 | starseeker | wonders why he does not see these CMake errors... |
| 21:45.12 | cvds_ | !seen rkoeppl_printing |
| 21:45.23 | cvds_ | sorry wrong windos |
| 23:54.12 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-52-241-103.dsl.bkfd14.sbcglobal.net) | |
| 02:09.21 | brlcad | starseeker: if you always do a build the exact same way every time, nothing is likely going to ever change |
| 02:09.27 | brlcad | s/change/fail/ |
| 02:09.45 | brlcad | but then that's not very flexible either, akin to coding with blinders on |
| 02:51.16 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 03:07.47 | starseeker | will be curious what you did differently... |
| 03:08.22 | jordisayol | hello |
| 03:09.13 | starseeker | howdy |
| 03:09.25 | jordisayol | when will be the 7.20.4 release out? |
| 03:09.45 | starseeker | within a couple days would be my guess |
| 03:10.01 | jordisayol | aha, thanks! |
| 03:22.58 | brlcad | starseeker: I've long since moved on with all of the other release testing |
| 03:23.02 | brlcad | jordisayol: within a couple hours |
| 03:23.15 | brlcad | last round of distchecking now |
| 03:23.30 | jordisayol | good! |
| 03:23.34 | starseeker | brlcad: ah - was figuring there was busted CMake stuff I would have to look at... |
| 03:23.48 | brlcad | starseeker: fyi, I seem to consistently run into that fontconfig failure on 10.6 |
| 03:24.11 | brlcad | something wrong with the X11 search logic |
| 03:24.28 | starseeker | k. |
| 03:24.42 | starseeker | will see if a test machine is available |
| 03:25.11 | brlcad | it ends up not searching in /usr/X11/include where fontconfig/fontconfig.h lives, no -I/usr/X11/include on the compile line either |
| 03:25.21 | starseeker | growls |
| 03:25.31 | starseeker | why did trunk succeed and stable fail? |
| 03:25.50 | starseeker | or was that a separate issue? |
| 03:26.02 | brlcad | curiously, through all my mods of misc/CMake/FindX11.cmake, it didn't even seem to be using that macro/file |
| 03:26.19 | starseeker | nods - it probably was using one of the src/other copies |
| 03:26.22 | brlcad | separate issue I think |
| 03:26.27 | brlcad | I updated all the src/other copies too |
| 03:26.42 | brlcad | (can see in the commit history) |
| 03:26.46 | starseeker | that's one of the drawbacks of doing src/other configures before ours - we get their Find*.cmake files running first |
| 03:26.53 | starseeker | k |
| 03:27.42 | starseeker | all the more reason to try and get maintainership of the ones we care about in CMake |
| 03:27.44 | brlcad | in fact, curiously -- it's finding /usr/X11R6 during cmake .. and I removed ALL of our cmake file references to /usr/X11R6 and it still found/used it |
| 03:27.53 | starseeker | O.o |
| 03:28.24 | starseeker | darn Mac anyway... |
| 03:29.13 | starseeker | needs to make another try at Aqua support... heck with X11 on Mac... |
| 03:29.17 | brlcad | the mac X11 dirs are actually set up very sane on 10.6 |
| 03:29.46 | brlcad | autotools passes no problem, something is wrong in the logic |
| 03:29.55 | starseeker | nods |
| 03:29.59 | starseeker | I believe it |
| 03:30.12 | starseeker | I'll try to take a look tomorrow |
| 03:31.31 | brlcad | as it's the last remaining release issue, I'm going to tag the release with that issue unresolved so some users might get bitten |
| 03:31.53 | starseeker | nods - yeah, CMake isn't "official" yet so I'd say go |
| 03:32.27 | starseeker | does X11R6 *exist* on your Mac? |
| 03:32.50 | brlcad | yes, it is a symlink to X11 |
| 03:33.09 | starseeker | hmm |
| 03:33.38 | starseeker | and yet -I/usr/X11R6/include doesn't work for fontconfig.h? |
| 03:33.58 | brlcad | sure that'd work, but it's not on the compile line |
| 03:34.08 | starseeker | confound it |
| 03:34.32 | starseeker | alright, I'll have to debug it |
| 03:34.55 | brlcad | that's why I started trying to just debug the find macro, but couldn't seem to get it to do anything useful |
| 03:35.04 | brlcad | spent a day working on various angles |
| 03:35.12 | starseeker | winces - sorry about that |
| 03:35.18 | brlcad | not you, cmake just was not cooperating |
| 03:35.20 | starseeker | was rather fried after the last week |
| 03:35.59 | starseeker | has done various surgeries on the FindX11.cmake file to try and account for one issue or another, may have really messed it up somehow |
| 03:36.33 | brlcad | uncovered a rather extensive bit of scary differences on the tk command line... |
| 03:36.46 | starseeker | snorts - not surprised, actually |
| 03:37.02 | starseeker | I was trying to get it working, not shooting for command line parity |
| 03:37.07 | brlcad | i'm almost surprised that tk even works... |
| 03:37.11 | brlcad | http://brlcad.org/tmp/cmake_fail.patch |
| 03:37.32 | brlcad | don't show the tk guys that :) |
| 03:38.06 | starseeker | oh, I doubt they'll care either way - when I talked to Andreas, he didn't sound especially interested in changing the existing system |
| 03:38.23 | starseeker | (unfortunately, he was making Tcl/Tk usb drives and didn't see my talk :-( |
| 03:39.15 | brlcad | package name isn't right, features off that should be on, features on that should be off, worrisome threading settings, incorrect symbol import/export settings, .. :) |
| 03:40.21 | brlcad | subtleties for sure, but definitely enough "cause for concern" if/when tk ever crashes or has odd behavior |
| 03:40.55 | brlcad | first thing I'd want to do if we ran into a serious bug is try again with stock tk |
| 03:41.06 | brlcad | (or get closer to parity) |
| 03:41.07 | starseeker | nods - I pretty much reached burn-out trying to unwind their existing build settings |
| 03:41.45 | starseeker | that stupid thing they have to do with putting all their settings on the command line instead of a config.h file made it tough |
| 03:42.05 | brlcad | I would have thought that makes things easier |
| 03:42.49 | brlcad | always have the command line, and then "sometimes" compile_line+some_unknown_number_of_files_with_magical_#defines |
| 03:43.03 | brlcad | that just eliminates the latter, one list to worry about matching |
| 03:43.10 | starseeker | prefers diffing the resulting config.h files between old and new builds |
| 03:43.28 | brlcad | but then even the compile flags don't match |
| 03:44.31 | brlcad | I *think* they're all benign, but not sure |
| 03:44.37 | brlcad | especially about __attribute__\(\(__visibility__\(\"hidden\"\)\)\) |
| 03:44.48 | starseeker | didn't know what to make of that one |
| 03:45.23 | starseeker | it was bad enough trying to figure out all the tests for the stuff I *knew* I needed - pretty much if it wasn't clearly essential it got ignored |
| 03:45.47 | starseeker | remember the original effort was a side issue, a distraction from BRL-CAD itself |
| 03:46.21 | brlcad | a distraction to you perhaps :) |
| 03:46.30 | brlcad | to me, it's all part of the effort |
| 03:46.43 | starseeker | <snort> I was worried about being called to the carpet as it was |
| 03:46.43 | brlcad | if it's worth doing at all ... |
| 03:46.49 | brlcad | knows |
| 03:47.11 | brlcad | it's fine, it obviously works fairly well enough as it is |
| 03:48.01 | starseeker | oh, I agree it's worth doing right - maybe it's a side-effect of the conference, but I do think Tcl/Tk is a nice combination of features, license and small size compared to it's feature-set |
| 03:48.12 | brlcad | there are just so many rough edges that there are going to be numerous long-term maintenance and debugging costs, obscure errors down the road that take forever to dig into |
| 03:48.36 | starseeker | unfortunately, my compiling foo is relatively weak compared to the complexities of the build |
| 03:49.30 | starseeker | half the time I didn't know if a particular flag was a hold-over from ancient history I could ignore |
| 03:49.52 | starseeker | or a flag I would need on some platform other than the current one |
| 03:50.51 | starseeker | that __attribute__ flag being one case in point |
| 03:51.07 | brlcad | that's gcc linker hinting |
| 03:52.38 | brlcad | a quick google search would have answered that one :P |
| 03:52.45 | brlcad | most of them, really |
| 03:53.27 | brlcad | http://gcc.gnu.org/wiki/Visibility |
| 03:53.28 | starseeker | maybe *what* they were, but not whether they actually mattered for thing things we care about |
| 03:53.55 | brlcad | basically, it's gcc's way to hide a symbol that needs to be extern but you don't want to be public api |
| 03:54.09 | brlcad | very similar to dll_import/dll_export in msvc |
| 03:54.16 | starseeker | retches |
| 03:54.28 | starseeker | that has caused more grief... |
| 03:55.15 | brlcad | to whom? pretty straightforward linking concepts (and not unique to msvc) |
| 03:55.38 | brlcad | most compilers have the notion, some are through much more archane methods like explicit lists of symbols in text files |
| 03:56.04 | brlcad | gcc was actually a bit late to the game, but most commercial compilers have that feature |
| 03:58.23 | starseeker | nods - OK, looking over this article I can see why it might be useful in some situations... |
| 03:58.27 | brlcad | it lets you write a function "secret_special_sauce()" used by public API in several places, say rt_brilliant() and rt_awesome(), but not actually have to expose that function in the library |
| 03:59.10 | starseeker | do we use such a mechanism? I don't recall seeing it in our own build logic... |
| 03:59.41 | brlcad | we do not, it takes a little bit of API awareness and best practice to keep things clean |
| 03:59.53 | brlcad | libged is a prime example, though .. |
| 04:00.28 | brlcad | lots of functions bob keeps adding that need to be reusable within the library .. but make for HORRIBLE public api functions, completely inconsistent with the rest of the ged api |
| 04:01.09 | brlcad | been resorting to simple naming conventions to at least remove the ged_ prefix, helps |
| 04:01.39 | brlcad | but then they still need to be declared in ged's private header, not ged.h |
| 04:01.46 | brlcad | and that takes awareness, restraint, etc |
| 04:02.01 | starseeker | nods |
| 04:02.21 | brlcad | yay, final builds completed |
| 04:02.45 | starseeker | if I ever feel like tinkering with our build system again, sit on me 'til the urge passes |
| 04:02.50 | brlcad | cept cmake of course, |
| 04:03.43 | brlcad | doing something I probably shouldn't .. comparing the two distfiles from cmake and autotools |
| 04:03.44 | starseeker | will look into that tomorrow if he can get access to a 10.6 system |
| 04:04.10 | brlcad | I can post any files you think might help |
| 04:04.12 | starseeker | I believe there is at least one step that autotools has that I haven't put in CMake |
| 04:04.31 | starseeker | brlcad: I need to do some configure-time debugging, to check what is and isn't being set at various steps |
| 04:04.44 | starseeker | basically a bunch if MESSAGE calls at various points in the file |
| 04:04.50 | starseeker | s/if/of |
| 04:05.13 | starseeker | brlcad: your CMakeCache.txt file might be informative |
| 04:06.25 | brlcad | http://brlcad.org/tmp/cmake_build_fail.txt and http://brlcad.org/tmp/CMakeCache.txt |
| 04:06.26 | starseeker | is disturbed that editing the FindX11.cmake files didn't do squat - did you erase your CMakeCache.txt file between each CMake run? (or at least clear out the X variables in it?) |
| 04:06.48 | brlcad | yep, started out just wiping out the cache |
| 04:07.04 | brlcad | then was eventually blowing away the whole dir, trying to get some changes |
| 04:08.00 | brlcad | build dir out of src dir only, parallel |
| 04:08.11 | starseeker | hmm - is there a /usr/include/X11 dir? |
| 04:09.35 | starseeker | is wondering why there seems to be both a /usr/X11/include and a /usr/include/X11 - one one a symlink to the other? |
| 04:09.43 | brlcad | there is a /usr/include/X11 symlink to /usr/X11/include/X11 |
| 04:10.03 | starseeker | and fontconfig.h is where? |
| 04:10.16 | brlcad | /usr/X11/include/fontconfig/fontconfig.h |
| 04:10.28 | starseeker | that may be what's happening |
| 04:10.34 | starseeker | /usr/include is getting checked first |
| 04:10.35 | brlcad | /usr/X11/include is the "proper" one-stop shop for X11 |
| 04:10.38 | starseeker | right |
| 04:10.50 | starseeker | but I'll bet the find routines are looking in /usr/include |
| 04:10.57 | brlcad | so #include <X11/Xlib.h> works, as well as #include <fontconfig/fontconfig.h> |
| 04:11.18 | starseeker | your cache file reports: X11_X11_INCLUDE_PATH:PATH=/usr/include |
| 04:11.39 | starseeker | and /usr/include/fontconfig doesn't exist |
| 04:11.43 | brlcad | which is true for that specific test |
| 04:12.56 | starseeker | let me check... it's now looking like there needs to be a specific fontconfig_include_dir var set... |
| 04:13.16 | brlcad | fontconfig is one of a half-dozen entities in /usr/X11/include |
| 04:13.29 | brlcad | GL, cairo, freetype2, ... |
| 04:14.02 | starseeker | yeah, but unless we convince the FindX11 routines to not look in /usr/include (or at least, not until after /usr/X11/include) the X11 includes aren't going to get fontconfig |
| 04:14.55 | brlcad | the problem isn't fontconfig -- the failure is 1) assuming that the dir containing X11 also contains those deps and 2) not checking /usr/X11/include first .. and maybe 3) not having the equivalent of --with-x=/usr/X11 :) |
| 04:15.47 | starseeker | did you try moving /usr/include below /usr/X11/include in the X11_INC_SEARCH_PATH variable in FindX11.cmake? |
| 04:17.05 | brlcad | so here's another mystery .. when I first started editing FindX11.cmake .. /usr/include was at the BOTTOM of the X11_INC_SEARCH_PATH list .. which is why my commit comments asserted that the list seemed to be processed in reverse order |
| 04:17.26 | brlcad | I had trouble believing that, even with the evidence, so I reverted and resorted back |
| 04:17.52 | brlcad | that's what I meant about not getting that list to make one bit of difference |
| 04:18.28 | starseeker | what about reducing that list to *just* /usr/X11/include - does that work? |
| 04:18.38 | starseeker | (take the order out of it, for the moment) |
| 04:19.06 | brlcad | I'll give that a quick test |
| 04:19.41 | brlcad | my earlier test was to remove X11R6 since that's what most of the X11-related tests actually detect/use |
| 04:19.55 | brlcad | and even after removing all instances of it, still would only detect/use X11R6 |
| 04:20.27 | brlcad | like maybe some system Find* was getting called first and our list was pointless |
| 04:20.31 | starseeker | that's strange... it almost sounds like it's getting the system FindX11.cmake and not our local copies |
| 04:20.34 | starseeker | er, yeah :-) |
| 04:21.24 | starseeker | iirc, one of the src/other instances (tk, I think) ends up called first, the way our toplevel currently works |
| 04:21.42 | starseeker | (with all bundled libs on - otherwise of course it depends) |
| 04:22.25 | starseeker | I had that problem earlier. But since you changed 'em all and cleared the cache, it can't be that |
| 04:22.46 | brlcad | well, like I said, I thought of that too and diligently overwrote all FindX11.cmake on each edit attempt |
| 04:22.56 | starseeker | knows |
| 04:22.58 | brlcad | as well as FindGL.cmake since it has some X11 tests of it's own |
| 04:23.31 | brlcad | edit made, re-cmaking |
| 04:23.51 | starseeker | only other thing I can think of (what I would be doing) is to put some MESSAGE statements into the FindX11.cmake files to see what is set when. |
| 04:24.43 | brlcad | so that reminds me of another bitching point .. what is up with ccmake not giving the "g"enerate files option most of the time? |
| 04:24.50 | starseeker | something like MESSAGE("X11 include path with FindX11.cmake in ${CMAKE_CURRENT_SOURCE_DIR}: ${X11_X11_INCLUDE_PATH X11}") |
| 04:25.27 | starseeker | uh - if it's acting like the gui, you need to do the configure twice before generate is available... |
| 04:25.45 | starseeker | recalls a complaint about that on the CMake list a while back... |
| 04:26.50 | brlcad | it annoyingly starts up with EMPTY CACHE in an empty/new build dir, I run 'c'onfigure, I wait... get list of options, make my edits, 'c'onfigure *again* .. and sometimes it'll give me the 'g'enerate option, but usually I have to exit and "cmake ." to generate the makefiles for that last config |
| 04:27.11 | starseeker | O.o |
| 04:27.33 | starseeker | as far as I know, it's supposed to give you the generate option once no new variables have been added to the var list |
| 04:27.42 | starseeker | which is typically after the second configure |
| 04:28.04 | brlcad | well I have no list the first time, so presumably they all get added |
| 04:28.08 | starseeker | if your option edits prompt more variables to appear, you'll have to do it again |
| 04:28.13 | starseeker | yes |
| 04:28.31 | starseeker | in the gui, the first configure never allows the geerate button to activate |
| 04:28.40 | brlcad | then the second time, I usually do BUNDLED on the all deps option, turn on debugging, turn on opt, 'c'onfigure |
| 04:28.53 | starseeker | the second does, provided no new variables are added as a result of opition changes between the first and the second |
| 04:29.16 | starseeker | ah - yeah, that'll add new options as it runs the src/other configures it didn't run the first time |
| 04:29.34 | starseeker | a third configure (with no option changes) should get you the generate button |
| 04:29.40 | starseeker | (or 'g' option) |
| 04:31.00 | brlcad | blech |
| 04:31.38 | starseeker | once the configure emulation script is done it should feel like autotools on the command line |
| 04:31.46 | starseeker | then you won't have to mess with the guis |
| 04:32.26 | brlcad | yeah, I'm really not digging ccmake |
| 04:33.07 | starseeker | usually does the command line: cmake -DBRLCAD_BUNDLED_LIBS=Bundled |
| 04:33.52 | brlcad | the options aren't usefully grouped/sorted, can't see the curses cursor without color, no description/help for options (which you'd think would be a prime benefit of having a fancy curses gui) |
| 04:35.18 | starseeker | cmake-gui probably isn't much better then (I prefer it personally, but that's just me...) |
| 04:35.28 | starseeker | drop-down options are kinda cool though |
| 04:37.36 | brlcad | of course, patches welcome ;) |
| 04:37.54 | brlcad | so yeah, no-go on the path change |
| 04:38.16 | starseeker | *bleep* |
| 04:38.33 | brlcad | removed all except /usr/X11/include in all FindX11 and FindGL files, still detecting /usr/include for headers and /usr/X11R6/lib for libs |
| 04:38.36 | starseeker | is this a machine I can remotely access? |
| 04:39.10 | brlcad | i could probably set up access in a couple min |
| 04:39.19 | starseeker | is willing to give it a go... |
| 04:53.00 | CIA-109 | BRL-CAD: 03brlcad * r47371 10/brlcad/tags/rel-7-20-4/: retagging release 7.20.4 now that most of the build and distcheck issues have been cleaned up. tested numerous configurations on debian and mac 10.6 |
| 04:55.36 | starseeker | brlcad: take a look at: cmake --help-command find_path |
| 04:56.05 | starseeker | #5 in the search list is a list of pre-defined paths for each Platform |
| 04:56.28 | starseeker | that could be interfering |
| 04:57.18 | brlcad | maybe, or the path being searched for isn't useful |
| 04:57.32 | brlcad | looking for an X11 dir seems a bit of a weak test, for example |
| 04:58.04 | brlcad | you generally look for X11/Xlib.h or some other primary header |
| 05:00.50 | CIA-109 | BRL-CAD: 03brlcad * r47372 10/brlcad/trunk/src/librt/CMakeLists.txt: shouldn't be any reason to disable strict mode on librt. change the code, not the messenger. |
| 05:02.34 | CIA-109 | BRL-CAD: 03brlcad * r47373 10/brlcad/trunk/CMakeLists.txt: match the original autotools logic, detect all the way back to 8-bit architectures so we might have a prayer's chance of working out of the box on an embedded platform. |
| 05:26.50 | CIA-109 | BRL-CAD: 03starseeker * r47374 10/brlcad/trunk/ (6 files in 6 dirs): Tweak FindX11.cmake for Mac OSX 10.6 |
| 05:26.58 | starseeker | brlcad: give that a go |
| 05:34.52 | brlcad | hey, I believe you -- if you say it works :) |
| 05:35.08 | starseeker | is finishing the compile now - at 89% |
| 05:35.09 | brlcad | is there an option that says "try these first, THEN try system"? |
| 05:35.21 | brlcad | oh, it wouldn't have gotten that far |
| 05:35.27 | brlcad | failed in tk early |
| 05:35.47 | starseeker | not to my knowledge - I could achieve that behavior, but only by doing so "manually" |
| 05:36.08 | brlcad | so if the list is now being walked in order, /usr/include should probably come last |
| 05:37.18 | brlcad | and any system dirs being searched by default should probably get added |
| 05:37.57 | starseeker | bets that's where the X11R6 stuff was coming from though - the Developer SDKs have multiple copies of usr/X11R6 dirs |
| 05:37.59 | brlcad | rather, dirs that WERE being searched by that default logic |
| 05:38.04 | brlcad | nods |
| 05:38.16 | brlcad | makes sense, fits the symptoms |
| 05:39.00 | starseeker | nods - we could play with it some - if you want to do that, we'd have to investigate where the platform specific dirs are listed and append those variables |
| 05:39.18 | brlcad | I suspected as much very early into the testing, but didn't know an fix and it took a while to isolate the problem |
| 05:39.59 | starseeker | nods - I experimented with something like this once before, but didn't (quite) need to go all the way to the no cmake system path option |
| 05:40.09 | starseeker | this time it's legit - we need it |
| 05:40.27 | brlcad | given how critical proper detection of X11 is to our ability to even compile in a useful manner on most platforms, it warrants making it as robust as possible |
| 05:40.46 | starseeker | nods - probably will have to add FindGL to this mix, too |
| 05:41.15 | starseeker | that is isn't technically as necessary as X11 at the moment, but I don't expect that to last much longer |
| 05:41.24 | brlcad | even better would probably be to find what the autotools logic is, and *also* use that since it's more likely to be more exhaustive |
| 05:41.54 | brlcad | yeah, we're to the point of needing GL for anything serious .. we need to fix our gl problems |
| 05:42.13 | brlcad | if we can't even detect gl cleanly, we certainly can't dev reliably with it |
| 05:42.30 | starseeker | *ding* *ding* *ding* - build complete on your mac. logging off now |
| 05:42.36 | brlcad | awesome, thanks |
| 05:43.11 | starseeker | np - thank you! that would have been a toughie without the system itself to test on |
| 05:43.40 | brlcad | if you want to sync that to stable and branch, and regenerate the tarballs, go for it ;) |
| 05:44.06 | brlcad | otherwise, I'll go with the ones already tagged since they're also tested on linux and don't want to do that whole round of retesting again |
| 05:44.39 | starseeker | votes for leaving it - autotools will work for this round |
| 06:43.41 | brlcad | source tarballs uploading now, release notes hopefully sometime tomorrow |
| 07:38.02 | jordisayol | brlcad: congratulations for the new release! |
| 07:39.15 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 07:39.34 | jordisayol | brlcad: I see that the package size is bigger than the previous ones. What's the cause of this size difference? |
| 07:50.02 | CIA-109 | BRL-CAD: 03d_rossberg * r47375 10/rt^3/tags/rel-7-20-4/: tag the C++ core interface with the corresponding BRL-CAD version (i.e. 7.20.4) |
| 12:44.16 | CIA-109 | BRL-CAD: 03indianlarry * r47376 10/brlcad/trunk/src/conv/iges/treecheck.c: Change Treecheck() return from void to int |
| 13:42.29 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 14:05.46 | *** join/#brlcad abhi2011 (~chatzilla@117.200.81.53) | |
| 14:38.52 | starseeker | jordisayol: which packages are you building? RPM? |
| 14:39.52 | jordisayol | yes, RPM for Fedora/Centos, RPM for OpenSUSE and DEB for Debian/Ubuntu/LinuxMint/... |
| 14:41.02 | starseeker | jordisayol: we have more docbook stuff (more advanced html and pdf is being generated thanks to Tom Browder) |
| 14:41.10 | starseeker | awesome |
| 14:41.49 | starseeker | tries to remember if this last release is the one that will have the upgraded Boost - that might have upped the size too |
| 14:43.26 | jordisayol | aha, but what is needed to compile brlcad with docbook? |
| 14:44.13 | jordisayol | ...in linux (ubuntu) |
| 14:51.06 | jordisayol | I got this: |
| 14:51.06 | jordisayol | Generate extra docs ...................: ON (man/html |
| 14:51.38 | jordisayol | with "fop" installed |
| 14:52.20 | jordisayol | Generate extra docs ...................: ON (man/html only) |
| 14:54.41 | CIA-109 | BRL-CAD: 03erikgreenwald * r47377 10/brlcad/trunk/src/libgcv/bottess.c: change double ptrs to explicit point_t ptrs. |
| 16:23.30 | jordisayol | starseeker: so, do you think that pdf files must be included in linux packages? |
| 16:39.22 | jordisayol | starseeker: deb package w/o pdf (until now), 50 Mb. with pdf 80 Mb. |
| 16:40.17 | jordisayol | starseeker: please tell me what do you think |
| 16:41.10 | jordisayol | you too brlcad |
| 16:41.29 | jordisayol | i've to go |
| 16:41.52 | jordisayol | please leave your opinion here |
| 16:41.54 | jordisayol | bye |
| 16:55.15 | *** join/#brlcad abhi2011 (~chatzilla@117.200.85.105) | |
| 17:28.59 | starseeker | jordisayol: no, pdf's shouldn't be included (IMO) |
| 17:29.37 | starseeker | you have to explicitly turn on PDF building - it's another option |
| 17:29.58 | starseeker | (that option won't even appear unless fop is around) |
| 17:30.44 | starseeker | pdf building is expensive and (unlike the html output) isn't directly used by any of the editing environments |
| 17:37.15 | brlcad | jordisayol: since the pdf files are not yet in the final desired form (layout, images, structure), it's not necessary that they be included in binary distributions but not a problem if they're included either |
| 17:37.45 | brlcad | requiring fop to build brl-cad is a huge requirement, so I wouldn't make it a .deb build dependency (pulls in all of fop+java) |
| 17:38.51 | brlcad | jordisayol: as for the size of the download, the size tends to increase with every release because the size of the code tends to increase every release (ohloh has graphs) |
| 17:41.23 | jordisayol | ok, many thanks starseeker and brlcad. i'l keep as they are |
| 17:41.26 | brlcad | most cad distros are 10x our binary size due to docs and metadata, so I won't really be concerned until we cross the max CD-size barrier (about 860MB) |
| 17:42.17 | brlcad | even then, that'll just to a good audit point to make sure we're not being too wasteful and inefficient with 3rd party deps and data, real practical limit is dvd capacity |
| 17:47.08 | jordisayol | another question. can i switch archer as default graphic app, or is i still in pre-alfa state? |
| 17:47.15 | abhi2011 | I am trying to do a windows build and I read README.windows |
| 17:47.35 | abhi2011 | but there is no brlcad.sln file in brlcad\misc\win32-msvc |
| 17:48.09 | abhi2011 | is the cmake approachm the only approach at the moment ? |
| 17:51.23 | brlcad | jordisayol: it's still pre-alpha, I'm hoping we push out an alpha before the new year |
| 17:51.55 | brlcad | abhi2011: the readme is out of date, cmake is THE approach at the moment, install it on windows and the build should go pretty smoothly |
| 17:52.06 | jordisayol | brlcad: ok, mani thanks. i'll keep everything as is |
| 17:52.07 | abhi2011 | ok |
| 18:01.20 | abhi2011 | so I have visual studio 2008 express edition installed but i get errors with cmake |
| 18:01.30 | abhi2011 | I guess the best option then is to go with mingw |
| 18:01.43 | brlcad | what errors? |
| 18:02.54 | abhi2011 | http://bin.cakephp.org/view/611912235 |
| 18:04.05 | abhi2011 | support for platforms, hmm |
| 18:07.22 | abhi2011 | seems like a bug : http://social.msdn.microsoft.com/Forums/en-US/vssmartdevicesnative/thread/88685f18-11a0-469f-902d-08a00aa01554/ |
| 18:07.34 | abhi2011 | maybe i ll get vc express 2010 and try |
| 18:10.38 | abhi2011 | hmm ok, I had chosen the win64 compiler |
| 18:10.48 | abhi2011 | choosing the normal 32 bit build , works |
| 18:14.28 | abhi2011 | though there are a large number of libs that were not found : http://bin.cakephp.org/view/1966265968 |
| 18:15.46 | abhi2011 | its probably looking for the DLLs in Windows/SysWOW64 and not finding them, maybe I should install them |
| 18:17.00 | abhi2011 | oh wait , its going to compile them, so its probably ok |
| 18:18.20 | abhi2011 | ok got the sln file |
| 18:25.52 | brlcad | abhi2011: yeah, no worries |
| 18:26.04 | abhi2011 | :) |
| 18:26.08 | brlcad | the lib detection is just to decide whether or not we need to use our bundled versions |
| 18:26.33 | brlcad | on windows, where pretty much nothing exists already, it's to be expected that most of the tests will result in using the bundled lib |
| 18:28.14 | brlcad | you might still run into a compilation failure, windows doesn't get tested very often |
| 18:31.04 | brlcad | if you do, though, post it so someone can fix it .. or fix it yourself ;) |
| 18:35.04 | abhi2011 | yes sure |
| 18:35.30 | abhi2011 | i cant find the my simulate project under libged though :P |
| 18:35.40 | abhi2011 | *simulate folder |
| 18:36.32 | abhi2011 | probably removed from the files in the solution, due to bullet not being detected, by cmake |
| 18:37.49 | abhi2011 | yeah , hav to move to windows for a few days, as I am unable to access the svn from linux suddenly, probably some isp issue |
| 18:43.47 | starseeker | is sorry, but will be a Good Thing if you can get things working on Windows as well |
| 18:44.22 | starseeker | yeah, if it can't find bullet it won't try building things needing it |
| 18:46.11 | abhi2011 | starseeker: hehe , np, yeah will compile bullet dynamic libs now :) |
| 18:49.39 | starseeker | makes a note to try out tileQt and check its license... |
| 18:52.44 | abhi2011 | ok, the build completed smoothly, now its saying to run 'make install', I think that would need make to be installed, which is only in linux |
| 18:53.32 | abhi2011 | hmm maybe i ll just run the INSTALL target |
| 18:53.59 | abhi2011 | right that did it |
| 19:09.49 | starseeker | grins - tileQt already has a CMake build :-) |
| 19:09.51 | starseeker | awesome |
| 19:30.04 | abhi2011 | strange, I have just pointed the system environment variables BULLET_DYNAMICS_LIBRARY BULLET_COLLISION_LIBRARY BULLET_MATH_LIBRARY BULLET_SOFTBODY_LIBRARY BULLET_INCLUDE_DIR |
| 19:30.22 | abhi2011 | and set them to the proper paths where bullet .libs are installed |
| 19:30.31 | abhi2011 | still I get the Bullet missing error |
| 19:30.54 | abhi2011 | arent the variables supposed to be system variables ? |
| 19:31.32 | starseeker | abhi2011: try setting them in CMake |
| 19:31.39 | abhi2011 | ah ok |
| 19:33.47 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 19:43.44 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.3) | |
| 19:52.14 | abhi2011 | starseeker: that does not seem to work either |
| 19:52.32 | starseeker | what's the error? |
| 19:52.54 | abhi2011 | i defined all 5 variables in cmake, but it says : Could NOT find Bullet (missing: BULLET_DYNAMICS_LIBRARY BULLET_COLLISION_LIBRARY BULLET_MATH_LIBRARY BULLET_SOFTBODY_LIBRARY BULLET_INCLUDE_DIR) |
| 19:53.05 | abhi2011 | then it removes them after configuring |
| 19:53.18 | starseeker | hmm. Where did you define them? |
| 19:53.49 | abhi2011 | by adding an entry with the add entry button in the cmake-gui |
| 19:55.22 | starseeker | OK. you might try editing the CMakeCache.txt file... |
| 19:55.33 | abhi2011 | ok |
| 19:58.26 | abhi2011 | i guess the path should only mention the folder name, and not include the filename, as in : F:\Code\libraries\bullet-build\lib\Debug |
| 20:00.52 | starseeker | right |
| 20:01.05 | starseeker | for the includes anyway |
| 20:01.14 | starseeker | the libs will want the full name |
| 20:02.23 | starseeker | so the 5 variables you listed include 4 libs - those are full path with filename |
| 20:02.37 | abhi2011 | ok |
| 20:02.57 | starseeker | BULLET_INCLUDE_DIR should be just the directory with the .h files, or possibly a parent directory depending on the includes |
| 20:32.20 | abhi2011 | ok, now it found it |
| 20:32.44 | abhi2011 | I think setting them as enviromment vars should now also work as long as the full files names are given where needed |
| 21:06.05 | abhi2011 | Bullet running fine in windows now, linked against the static libs |
| 21:06.25 | abhi2011 | starseeker: thanks! |
| 21:09.37 | starseeker | hah - awesome! |
| 21:10.48 | starseeker | abhi2011: I know you've posted links before, but I don't recall - where are you stashing the various videos of your progress? |
| 21:15.10 | abhi2011 | starseeker: they are here : http://brlcad.org/wiki/User:Abhijit#Log |
| 21:15.18 | abhi2011 | there is just 1 video currently |
| 21:15.41 | abhi2011 | another requires the server as its a large scene with glass affects, so its not been done yet |
| 21:16.06 | abhi2011 | *glass shaders |
| 21:19.36 | abhi2011 | has anyone noticed that ws-indent and other scripts which format the code, format it for the older editors like emacs, the code appears misaligned in eclipse and visual studio |
| 21:20.11 | abhi2011 | code aligned in eclipse and vs appears misaligned in emacs :P |
| 01:31.51 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 04:11.16 | *** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 04:40.55 | *** join/#brlcad abhi2011 (~chatzilla@117.200.89.98) | |
| 05:31.21 | *** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 06:43.57 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.54) | |
| 06:44.01 | CIA-109 | BRL-CAD: 0323.19.56.171 07http://brlcad.org * r3191 10/wiki/Talk:Main_Page: |
| 06:50.53 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 07:10.23 | *** join/#brlcad abhi2011 (~chatzilla@117.200.89.69) | |
| 08:15.19 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.86.172) | |
| 08:31.34 | *** join/#brlcad merzo (~merzo@109-45-133-95.pool.ukrtel.net) | |
| 11:07.28 | *** join/#brlcad abhi2011 (~chatzilla@117.200.89.50) | |
| 11:41.38 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:22.00 | *** join/#brlcad abhi2011 (~chatzilla@117.200.85.236) | |
| 12:40.08 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:46.32 | *** join/#brlcad merzo (~merzo@72-3-133-95.pool.ukrtel.net) | |
| 13:31.16 | *** join/#brlcad abhi2011 (~chatzilla@117.200.84.105) | |
| 13:54.23 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r3192 10/wiki/Talk:Main_Page: Reverted edits by [[Special:Contributions/23.19.56.171|23.19.56.171]] ([[User talk:23.19.56.171|Talk]]); changed back to last version by [[User:X Tin Basher|X Tin Basher]] |
| 13:54.36 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:23.19.56.171]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 14:15.35 | brlcad | abhi2011: funny coincidence, someone on the bullet channel was bitching just yesterday about bullet's internal ray tracing sucking |
| 14:16.00 | brlcad | told them about your efforts to integrate with librt, excitedness ;) |
| 14:27.27 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 14:29.58 | *** join/#brlcad abhi2011 (~chatzilla@117.200.91.35) | |
| 14:30.07 | abhi2011 | brlcad: cool :) |
| 14:30.19 | abhi2011 | so there is someone replying in that channel :P |
| 14:31.00 | abhi2011 | I have been trying to figure out a algorithm that uses all the normal and curvature info to generate the points |
| 14:31.22 | abhi2011 | guess I ll first go with the box-box case |
| 14:31.50 | abhi2011 | a important thing to figure out is the direction in which an object is penetrating another object |
| 14:32.08 | abhi2011 | as the normal has to point along that direction |
| 14:33.36 | abhi2011 | currently I ll just check to see which ever dimension is the least in the overlapping volume , i.e. if the object is penetrating another along the z axis, then the dimension of the overlap region along the z axis will be least |
| 14:35.14 | abhi2011 | of course the best way would be to make the normal point according to the curvature of the 2nd body |
| 14:39.16 | abhi2011 | like so : https://docs.google.com/drawings/d/1Fp44t9AcZZurbNufXti64u-23CRjC49Z3r0WSmim5tU/edit |
| 14:40.23 | abhi2011 | but then rays hitting the curving surface would give many normals, so the proper normal has to be chosen, which can be got by vector summing I guess |
| 14:45.59 | abhi2011 | funny warning about the IGNORE symbol being redefined : http://bin.cakephp.org/view/1298213576 |
| 14:46.24 | brlcad | yeah, that channel is quite most of the time, but every now and then a discussion sparks up |
| 14:47.39 | brlcad | good to know about the IGNORE redefinition |
| 14:52.10 | brlcad | abhi2011: we actually include measures to define our IGNORE macro without conflicting with the windows macro |
| 14:52.23 | brlcad | so somewhere a windows header is getting included without our usual protections |
| 14:53.44 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.84.102) | |
| 14:53.45 | brlcad | abhi2011: AHA ... I think I found the problem -- you must include common.h before any/all *system* headers |
| 14:54.01 | abhi2011_ | ok |
| 14:54.25 | brlcad | you saw my other comments? |
| 14:55.52 | brlcad | irc problems? |
| 15:03.30 | abhi2011 | brlcad: yes , yes I saw them till : good to know about the IGNORE redefinition and then AHA |
| 15:03.47 | abhi2011 | yeah, disconnected in between |
| 15:05.44 | abhi2011 | yep I ll move up common.h |
| 15:10.34 | abhi2011 | hmm ,warning is still there though |
| 15:11.54 | abhi2011 | I think the issues is that a similar macro has been defined in both places |
| 15:11.57 | abhi2011 | not the order |
| 15:12.14 | abhi2011 | winbase.h & common.h |
| 15:20.11 | CIA-109 | BRL-CAD: 03abhi2011 * r47378 10/brlcad/trunk/src/libged/simulate/ (9 files): |
| 15:20.33 | abhi2011 | ok hope the commit went through fine, committing from windows with tortoise svn for the 1st time |
| 15:35.38 | abhi2011 | so is there a function already, which lets me check if a solid is present in the tree of a comb |
| 15:36.26 | abhi2011 | I can write one to recursively check the tree of a comb, and if it find the solid, then return true, but perhaps one already exists |
| 15:37.03 | abhi2011 | I need it for checking which comb, a solid belongs to , when rt gives me a solid at the point where a ray exits |
| 15:37.26 | abhi2011 | I then need to sum the normal only for that comb(rigid body) |
| 15:38.46 | abhi2011 | dbfind is there I see |
| 15:46.49 | abhi2011 | yep, ged_find, does exactly that , traversing in LNR order, will modify it a bit(in my own file) :P |
| 16:42.13 | CIA-109 | BRL-CAD: 03abhi2011 * r47379 10/brlcad/trunk/src/libged/simulate/ (simutils.c simutils.h): Added a function to check if a solid is present in a comb, required for checking which rigid body(a comb), a particular solid belongs to , while raytracing. |
| 18:04.29 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 18:52.50 | CIA-109 | BRL-CAD: 03abhi2011 * r47380 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simulate.h): |
| 18:54.23 | CIA-109 | BRL-CAD: 03abhi2011 * r47381 10/brlcad/trunk/src/libged/simulate/simrt.c: Added code for normals |
| 19:10.11 | *** join/#brlcad Forth (~Forth@92.242.118.253) | |
| 19:11.55 | *** part/#brlcad Forth (~Forth@92.242.118.253) | |
| 19:16.19 | CIA-109 | BRL-CAD: 03abhi2011 * r47382 10/brlcad/trunk/src/libged/simulate/simrt.c: More supporting code to test if the normals are being recorded correctly during the ray trace |
| 19:18.11 | brlcad | abhi2011: of course the macro is defined in both places, but the places we include windows headers takes care of that |
| 19:18.40 | brlcad | so if that conflict is encountered, some assumption is failing or the header inclusion ordering is wrong or the wrong headers are being included |
| 19:19.35 | brlcad | winbase.h shouldn't be directly included anywhere, so you have to look at the header includes to recursively see who includes winbase.h |
| 19:19.36 | abhi2011 | ok |
| 19:20.44 | brlcad | abhi2011: what was r47378? |
| 19:21.14 | brlcad | commit message got left off, not clear what changed since it was a fairly big commit .. wondering what it was |
| 19:21.25 | abhi2011 | it was an update of the source code to use contact pairs again |
| 19:21.33 | brlcad | ah, okay |
| 19:21.39 | abhi2011 | new svn software :P |
| 19:21.44 | abhi2011 | forgot to add message |
| 19:21.46 | brlcad | yep, realized that |
| 19:22.01 | abhi2011 | so I have an awesome idea now about how to generate normals |
| 19:22.22 | abhi2011 | basically summing the normals in the surface inside the overlap region |
| 19:23.03 | brlcad | sounds good :) |
| 19:23.20 | abhi2011 | the vector sum of the normals on the outer surface of the body gives the direction of the force that the body would apply on anything touching it |
| 19:23.28 | abhi2011 | as is the case in the real world |
| 19:23.54 | abhi2011 | once I have the normal, I ll shoot rays in that direction to get the depth of penetration |
| 19:24.27 | abhi2011 | and then the contact points (which should be on the surface of the body always), are the points where these rays leave the object |
| 19:24.33 | brlcad | could you use the velocity vector of the object in motion too? |
| 19:24.49 | abhi2011 | yes I can vectgr sum that to the normal too |
| 19:24.56 | abhi2011 | or just use the velocity vector |
| 19:25.08 | abhi2011 | but the point is no matter what the velocity vectpr |
| 19:25.19 | brlcad | why wouldn't you just use the velocity vector, shoot rays in the direction of the velocity, calculate the depth of penetration? |
| 19:25.20 | abhi2011 | the force will be based on the surface |
| 19:25.41 | abhi2011 | well because it depeds on both |
| 19:26.01 | abhi2011 | the angle of the surface and the velocity direction at which the object strikes |
| 19:26.09 | abhi2011 | that surface |
| 19:26.18 | brlcad | okay |
| 19:26.36 | abhi2011 | like a ray reflecting off a glass at an angle |
| 19:26.43 | brlcad | nods, makes sense |
| 19:26.46 | brlcad | misunderstood |
| 19:26.47 | abhi2011 | so hav to think about how to account for the velocity |
| 19:26.52 | abhi2011 | ah |
| 19:27.00 | abhi2011 | the angle between normal and velocity |
| 19:27.13 | abhi2011 | law of reflection calculation maybe |
| 19:27.45 | abhi2011 | but hmm, I think bullet will take care of that |
| 19:27.56 | abhi2011 | the fnal velocity direction i mean |
| 19:28.04 | abhi2011 | all I need to give it is the normal |
| 19:28.12 | abhi2011 | at the point of contact |
| 19:29.34 | abhi2011 | here are some sample cases : https://docs.google.com/drawings/d/1Fp44t9AcZZurbNufXti64u-23CRjC49Z3r0WSmim5tU/edit |
| 19:30.49 | abhi2011 | so the lower left case, shows that the concave case should also be possible to calculate correctly |
| 19:31.27 | abhi2011 | if this works out then I can check how to insert multiple manifolds, which I have read somewhere , is possible |
| 19:52.51 | brlcad | can't get to gdocs at the moment, will have to take a look later |
| 19:54.54 | CIA-109 | BRL-CAD: 03bob1961 * r47383 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: When opening a database also change the current working directory to the directory where the database lives. |
| 20:02.17 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.81.190) | |
| 20:15.49 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.81.155) | |
| 20:46.01 | CIA-109 | BRL-CAD: 03starseeker * r47384 10/brlcad/trunk/doc/docbook/resources/brlcad/brlcad-xml-catalog.xml.in: I don't think this variable needs to be specific to BRL-CAD in this case... |
| 20:52.33 | CIA-109 | BRL-CAD: 03starseeker * r47385 10/geomcore/trunk/ (12 files in 5 dirs): Turn on docbook documentation for geomcore. Stub in a geometry protocol doc, but nothing much there at the moment. |
| 20:56.01 | CIA-109 | BRL-CAD: 03abhi2011 * r47386 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simutils.c simutils.h): Now the entry and exit solids of a ray passing through an overlap region are checked to see if they belong to the comb of rigid body B |
| 20:59.16 | brlcad | deadline is today -- feel free to fill out quick/easy tasks that could be completed in 1-3 days at http://brlcad.org/wiki/Contributor_Quickies |
| 20:59.40 | brlcad | I'm crafting together our proposal now |
| 20:59.58 | brlcad | ideally we need 10 topics for each of the 8 categories |
| 21:00.49 | ``Erik | 'separate out libnmg' O.o I have vague recollection of libnmg not too long ago :) |
| 21:00.55 | brlcad | well, 5-10 tasks per topic |
| 21:01.37 | ``Erik | think simd/sse vmath might be worth an entry? |
| 21:03.02 | brlcad | iirc, include/vector_*.h was (as anticipated) an attempt at that |
| 21:03.04 | brlcad | and it failed |
| 21:03.53 | brlcad | test harness for vmath.h might be something though |
| 21:04.28 | brlcad | example of gnome tasks https://live.gnome.org/GoogleCodeIn/Tasks |
| 21:04.55 | brlcad | I'm inclined to direct all students to either IRC or the mailing list, thoughts on which? |
| 21:05.12 | brlcad | keeping in mind that it might be a lot of students 24-7 |
| 21:05.13 | ``Erik | in looking at that a while back, the choice to go with typedef point_t fastf_t[3]; instead of typedef point_t struct { fastf_t f[3]; }; or something was ... critical |
| 21:06.16 | brlcad | it wasn't a fail in terms of being a drop-in replacement -- that would have been the technical issue there |
| 21:06.46 | brlcad | it was a fail in that the simd version wasn't actually faster -- needed more data, not just one vector/matrix at a time |
| 21:07.01 | starseeker | fix tkhtml3 on Win64? |
| 21:07.22 | starseeker | for large numbers of students, I'd vote mailing list |
| 21:07.23 | ``Erik | I think irc will be quicker and more accepting of newbs |
| 21:07.31 | starseeker | hard to track conversations though |
| 21:07.34 | brlcad | starseeker: can you explain the problem? |
| 21:07.39 | ``Erik | but irc would lack good record |
| 21:07.45 | starseeker | probably not well enough for a student |
| 21:07.46 | brlcad | remember that these are *high school* students |
| 21:08.08 | brlcad | the questions are going to be very much "hold my hand", what's next? |
| 21:09.23 | brlcad | bhinesley: jordisayol: louipc: kanzure: anyone else: interested in being a GCI mentor? |
| 21:10.20 | starseeker | brlcad: what about bu_getopt_long or some such? |
| 21:10.57 | starseeker | just getting it working + adding it to one command would be a good start |
| 21:11.45 | brlcad | I don't think bu_getopt_long is what we want really (at least there's little-to-no value in having a bu version of getopt_long()) |
| 21:12.09 | starseeker | uh... rt with -- options seems worthwhile... |
| 21:12.10 | brlcad | we need long options, but there's no reason it needs to be compatible with that extension |
| 21:12.42 | starseeker | do they do it the wrong way? |
| 21:12.43 | brlcad | getopt_long() is an overlay with getopt() .. the two work suckily together |
| 21:13.04 | brlcad | pretty much |
| 21:13.28 | starseeker | we need something - what do you suggest? |
| 21:14.09 | brlcad | writing an option interface for bu |
| 21:14.20 | brlcad | already sketched out the basics a month or two ago |
| 21:14.31 | starseeker | erm. link? |
| 21:14.45 | brlcad | no link |
| 21:14.46 | brlcad | code in a checkout |
| 21:14.50 | starseeker | ah |
| 21:15.02 | brlcad | still, too advanced for gci I think |
| 21:15.08 | starseeker | k. pity |
| 21:15.24 | brlcad | if it's not something that'd take you less than a half a day from start to finish, it's probably too complex |
| 21:15.59 | brlcad | 13 year olds ... |
| 21:16.02 | starseeker | well, there's always fixing the bbox function for bots |
| 21:16.29 | brlcad | sure -- could put that one up, but i'd mark it hard :) |
| 21:18.50 | abhi2011 | I think tcl and gui will be easier for high school students :) |
| 21:19.04 | abhi2011 | maybe more of tcl and some libged related code |
| 21:19.10 | brlcad | from other project's reviews from prior years, the kids really do end up being a nearly full-time effort so we need to manage the complexity up front -- things we can explain and point trivially |
| 21:19.19 | starseeker | heh - I can't seem to come up with small projects from the gui side... |
| 21:19.25 | brlcad | abhi2011: you have some project ideas? |
| 21:19.30 | abhi2011 | for example the idea about integrating some of the visualization tools into the gui |
| 21:19.45 | abhi2011 | most of them have a fixed interface I guess |
| 21:19.48 | brlcad | remember that it's basically a contest -- they're looking for tasks that take hours or a day or two at most |
| 21:20.00 | abhi2011 | oh ok |
| 21:20.22 | brlcad | which includes the time to download the software, become familiar with the problem, find their way around, run a tool, etc |
| 21:21.05 | abhi2011 | hmm, then tcl and gui stuff would be tough |
| 21:21.23 | brlcad | came up with what I think is a GREAT idea at the mentor summit... we can create a preconfigured disk image for the students that already has a source checkout and compiled install ready to go |
| 21:22.14 | brlcad | that with a few simple instructions to download qemu, download disk image, create new image, run .. source is here, binaries are there, go! |
| 21:24.46 | abhi2011 | yes, that can really get things going fast, did that for virtual box images once |
| 21:25.21 | abhi2011 | so we are not expecting code from them I guess, they design something using the tools already present in brlcad ? |
| 21:25.59 | brlcad | you seen the http://brlcad.org/wiki/Contributor_Quickies list? |
| 21:26.03 | brlcad | it can be a code project |
| 21:26.12 | brlcad | or docs, or web or ... anything really |
| 21:26.21 | brlcad | something that'd take hours of time |
| 21:28.19 | abhi2011 | ok |
| 21:33.14 | abhi2011 | well I was thinking along the lines of making mged a bit easier to use : like when an object is selected and the primitive editor is opened, then the selected object's name should already be there and it should be displaying the object name |
| 21:33.48 | CIA-109 | BRL-CAD: 03128.63.32.62 07http://brlcad.org * r3193 10/wiki/Contributor_Quickies: /* Code */ add rt_bot_bbox item |
| 21:34.03 | abhi2011 | or even simpler, ensuring that closing the command window closes the application |
| 21:34.47 | abhi2011 | including the gfx window |
| 21:35.04 | starseeker | that... might not be so simple, actually |
| 21:35.13 | abhi2011 | oh :) |
| 21:35.23 | starseeker | seems to recall brlcad working with that once... |
| 21:35.26 | abhi2011 | low level opengl callbacks ? |
| 21:35.35 | starseeker | don't recall now |
| 21:36.25 | starseeker | brlcad: is excising Tcl functions from libraries too hard? (guessing yes...) |
| 21:37.02 | abhi2011 | also is there a script for moving the view along a specified path, it would be awesome to write a script or a simple c function that revolves the camera around the scene as objects are dropping |
| 21:37.08 | abhi2011 | *moving the camera |
| 21:37.18 | cvds_ | abhi2011: please dont, since I use that feature (closing thecommand window but keeping the gfx window) |
| 21:37.29 | abhi2011 | hehe ok :) |
| 21:37.53 | abhi2011 | so you run a script then close the command window I guess |
| 21:38.27 | cvds_ | mged -c to attach a single window and then set mged_default(multi_pane) 1; gui; and close the mged command window ;) |
| 21:38.54 | abhi2011 | ah ok |
| 21:40.13 | cvds_ | and using yakuake as the input. Works like a charm |
| 21:40.32 | starseeker | brlcad: http://directory.fsf.org/wiki/Popt |
| 21:40.40 | starseeker | http://rpm5.org/files/popt/popt-1.16.tar.gz |
| 21:40.46 | starseeker | would that be of interest? |
| 21:41.38 | starseeker | looks like MIT style license |
| 21:48.02 | starseeker | (not for GCI per say, but as an alternative to rolling our own option parsing?) |
| 21:59.21 | brlcad | abhi2011: having the closure of all of mged's windows actually close mged sounds like a great task -- can you add that to the wiki? |
| 22:00.04 | brlcad | starseeker: not sure what you meant with the excising |
| 22:00.34 | starseeker | doing whatever is needed to get the Tcl/Tk C api usage up to libtclcad (or steps in that direction) |
| 22:00.35 | brlcad | abhi2011: camera 360 script sounds like another great one, wiki? |
| 22:01.20 | starseeker | blinks - must have been thinking something else - I thought that "close all windows" issue was tied up with something else more complex |
| 22:01.28 | brlcad | cvds_: interested in being a mentor? :) |
| 22:02.01 | abhi2011 | brlcad: sure and sure :) |
| 22:02.22 | brlcad | starseeker: it's a bug, it used to close mged |
| 22:02.37 | brlcad | now you can close those two windows and mged is still running |
| 22:02.41 | brlcad | abhi2011: awesome :) |
| 22:08.42 | CIA-109 | BRL-CAD: 03starseeker * r47387 10/brlcad/trunk/src/ (3 files in 2 dirs): Shouldn't have moved this, used only internally in libbu and it's one file. |
| 22:11.06 | brlcad | starseeker: Makefile.am |
| 22:11.20 | starseeker | coming now |
| 22:11.39 | CIA-109 | BRL-CAD: 03starseeker * r47388 10/brlcad/trunk/src/ (5 files in 3 dirs): Clean up the rest of the uce stuff |
| 22:11.41 | starseeker | prods CIA |
| 22:21.20 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3194 10/wiki/Contributor_Quickies: /* Code */ |
| 22:54.32 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3195 10/wiki/Contributor_Quickies: /* Code */ |
| 22:55.37 | brlcad | ~abhi2011++ |
| 22:55.41 | brlcad | awesome |
| 22:55.44 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3196 10/wiki/Contributor_Quickies: /* EASY: Camera 360: A Tcl script to capture images while rotating the view around a scene */ |
| 22:56.47 | abhi2011 | will try to come up with some more tomorrow :) |
| 22:56.53 | brlcad | we need at least 3 more outreach and translation tasks, and at least 1 more research and UI task :) |
| 22:57.01 | brlcad | and QA |
| 22:57.09 | brlcad | need at least 5 for each |
| 22:57.58 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 22:59.16 | abhi2011 | how about starting the primitive editor with the currently selected object instead of having the user type it in each time |
| 22:59.53 | brlcad | you mean sed? |
| 22:59.58 | brlcad | sure |
| 23:00.16 | brlcad | oh, in the gui |
| 23:00.20 | abhi2011 | yes |
| 23:00.30 | brlcad | yeah, that'd be possible .. a bit complicated to explain, definitely a hard task |
| 23:00.43 | brlcad | your camera task is probably medium or hard for that matter :) |
| 23:00.47 | abhi2011 | yeah it requires familairity with mged |
| 23:01.01 | abhi2011 | yeah :P |
| 23:01.02 | brlcad | easy if you know mged and know scripting.. but that's a big IF for a 13 year old :) |
| 23:12.14 | ``Erik | iff, even |
| 23:12.38 | ``Erik | *ponder* logo on mged? |
| 23:12.59 | brlcad | perfect, add it |
| 23:13.16 | brlcad | great idea |
| 23:13.37 | ``Erik | iirc, logo was a variant of scheme, soooo... yeah, let's ditch tcl for lisp! |
| 23:14.11 | brlcad | heh |
| 23:14.23 | brlcad | took that to mean .. model the BRL-CAD logo in MGED :P |
| 23:14.52 | ``Erik | if mged ate lisp, it'd be automatable... |
| 23:15.00 | ``Erik | "just a couple lines" |
| 23:17.38 | ``Erik | has an old sorbel filter in C *ponder* |
| 23:20.45 | ``Erik | (whuddya mean, making each pixel a colored arb8 ain't what ya meant?) |
| 23:23.18 | brlcad | mmhmm |
| 23:23.33 | brlcad | pix-g will do it now :) |
| 23:25.33 | ``Erik | pix2g ya mean? |
| 23:25.43 | brlcad | right |
| 23:25.55 | brlcad | didn't want it to look like a proper tool :) |
| 23:26.07 | ``Erik | does not recall that puppy |
| 23:26.30 | brlcad | proc-db |
| 23:26.35 | ``Erik | and I keep typing 'git log', starseeker has poisoned my brain |
| 23:26.57 | ``Erik | it's old, even |
| 23:27.12 | brlcad | yeah, did that a long time ago |
| 23:27.21 | brlcad | fairly useless, but fun hack |
| 23:27.39 | ``Erik | is it actually a planar arb8 set with colors? |
| 23:28.01 | brlcad | I started with arbs, but I think that last rev uses spheres |
| 23:28.15 | brlcad | trivial to put it back |
| 23:28.38 | ``Erik | painter and smoother might replicate something acceptable... push it to nurbs and it's all good |
| 23:29.31 | ``Erik | (curve fit on a nurb is a whole lot easier than attempting to replicate geometry in implicits, right?) |
| 23:29.57 | ``Erik | srry, on a nurbs |
| 23:32.00 | brlcad | you going to add that logo task? that really is a great idea |
| 23:32.55 | ``Erik | I'll let you... I actually meant the language "logo" |
| 23:33.59 | ``Erik | if you want to give me credit for sparking the idea in you, that's cool, but that definitely isn't what I meant :) |
| 23:36.26 | brlcad | even better if you'd write it, cause writing this proposal is going to have me right up against the submission deadline |
| 23:36.54 | ``Erik | which logo? |
| 23:37.18 | brlcad | the new logo |
| 23:37.38 | brlcad | point them to the news page on the main website |
| 23:38.25 | ``Erik | I have a cat on my lap, and I'm not sure if he's actually alive anymore O.O |
| 23:40.29 | ``Erik | abhi has no user page |
| 23:42.32 | ``Erik | I d'no, doco or ux? |
| 23:43.06 | ``Erik | I'll go ahead and call it ux |
| 23:49.38 | ``Erik | ffs, WoW is stomping my machine here O.o 20-30 seconds before a keypress registers in other apps :/ |
| 23:49.39 | brlcad | <PROTECTED> |
| 23:55.08 | CIA-109 | BRL-CAD: 03Erik 07http://brlcad.org * r3197 10/wiki/Contributor_Quickies: /* User Interface */ Add .g of logo task |
| 23:55.53 | ``Erik | wordsmith your heart out, probably needs a time guess |
| 23:56.00 | brlcad | k |
| 23:56.41 | brlcad | ideas on hold.. the deadline apparently isn't .. what I calculated it to be .. (ffs.) |
| 23:56.52 | brlcad | just went to submit (early) and .. it's not |
| 23:59.34 | CIA-109 | BRL-CAD: 03128.63.32.74 07http://brlcad.org * r3198 10/wiki/Contributor_Quickies: move logo to outreach, needs two more |
| 00:00.18 | ``Erik | ooh, not logged in, and still at the office |
| 00:00.42 | brlcad | wonder who that is |
| 00:01.16 | CIA-109 | BRL-CAD: 03Erik 07http://brlcad.org * r3199 10/wiki/Contributor_Quickies: /* EASY: Model new BRL-CAD Logo using BRL-CAD */ Add time guess |
| 00:03.43 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r3200 10/wiki/Contributor_Quickies: clarify docs |
| 00:04.31 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r3201 10/wiki/Contributor_Quickies: already had time estimate added, update |
| 00:06.15 | ``Erik | whups, assumed fime would be between body and references |
| 00:09.06 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r3202 10/wiki/Contributor_Quickies: /* Outreach */ idea on interviewing jordi |
| 00:14.11 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r3203 10/wiki/Contributor_Quickies: /* Outreach */ another on writing geometry cpp articles |
| 00:26.48 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r3204 10/wiki/Contributor_Quickies: /* Quality Assurance */ deep unit test, and find bugs in archer |
| 00:32.44 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r3205 10/wiki/Contributor_Quickies: /* Research */ update the spreadsheet |
| 00:39.42 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) | |
| 00:41.04 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r3206 10/wiki/Contributor_Quickies: /* User Interface */ reorganize mged's menu |
| 00:47.38 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r3207 10/wiki/Contributor_Quickies: /* Translation */ translate our intro mged docs |
| 00:55.12 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r3208 10/wiki/Contributor_Quickies: /* Translation */ be specific on the desired languages |
| 00:56.57 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r3209 10/wiki/Contributor_Quickies: /* Translation */ |
| 01:01.55 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r3210 10/wiki/Contributor_Quickies: /* Translation */ HACKING |
| 01:04.40 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r3211 10/wiki/Contributor_Quickies: /* Translation */ our portuguese contingent deserve props for all the attention they've given over the years |
| 01:07.25 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 02:09.50 | starseeker | hah cool, didn't know about this project: http://www.helenos.org/ |
| 04:04.36 | *** join/#brlcad abhi2011 (~chatzilla@117.200.89.70) | |
| 04:09.09 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3212 10/wiki/Contributor_Quickies: /* EASY: Translate a chapter from the Introduction to MGED to Hindi */ |
| 04:09.21 | abhi2011 | :P |
| 06:16.49 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 06:25.15 | abhi2011 | hmm getting a number of erros from a custom build rule in cmakelist.txt : http://bin.cakephp.org/view/1879910803 |
| 07:00.39 | CIA-109 | BRL-CAD: 03abhi2011 * r47389 10/brlcad/trunk/src/libged/simulate/simutils.c: Corrected a bug in the primitive lookup code for a comb |
| 08:36.30 | cvds_ | tgc(thumbPlungerTop1.s): A not perpendicular to B, f=-0.21693 <-- hmmm I did not know this was a requirement -_- |
| 08:36.57 | cvds_ | in thumbPlungerTop1.s rec 0 0 0 0 0 3 0 7.5 0 22.5 -5 0 <-- this is what I more or less want |
| 08:38.29 | cvds_ | (its combined with a in thumbPlungerTop2.s rpp 0 32.5 -7.5 7.5 0 3 thats why its not perpendicular) |
| 08:53.55 | cvds_ | resolved it by orot the rec inside the combination then pushing it |
| 10:03.53 | cvds_ | brlcad: I ordered a lot of thing for the printer so hopefully I can give you those pictures somewhere december (provided I can tune the printer well enough) |
| 10:32.45 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 10:32.45 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 10:32.45 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 10:32.45 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 10:33.21 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 10:34.09 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 10:34.18 | *** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl) | |
| 10:34.50 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 10:51.43 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-52-241-103.dsl.bkfd14.sbcglobal.net) | |
| 10:51.43 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 10:51.43 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 10:51.43 | *** mode/#brlcad [+o ChanServ] by calvino.freenode.net | |
| 11:21.43 | CIA-109 | BRL-CAD: 03starseeker * r47390 10/brlcad/trunk/src/libbu/CMakeLists.txt: Whoops, ignoring wrong file |
| 11:53.06 | *** join/#brlcad abhi2011 (~chatzilla@117.200.84.234) | |
| 12:02.05 | *** join/#brlcad abhi2011 (~chatzilla@117.200.88.30) | |
| 12:05.36 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:45.27 | *** join/#brlcad juanman (~quassel@201.216.198.121) | |
| 12:45.32 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:51.41 | brlcad | cvds_: if you'd like to generalize the tgc even further, go for it ;) |
| 12:52.02 | brlcad | the intersection calculations get even more hairy if they're not perpendicular |
| 12:52.54 | brlcad | you can get non-perpendicular caps with a subtraction, so it's still an achievable shape -- just not with one tgc |
| 12:53.32 | brlcad | can't wait to see the pics ;) |
| 13:34.12 | CIA-109 | BRL-CAD: 03brlcad * r47391 10/brlcad/trunk/HACKING: freshmeat change their name to freecode |
| 13:47.28 | *** join/#brlcad abhi2011 (~chatzilla@117.200.86.135) | |
| 14:53.45 | cvds_ | brlcad: I see, I sorted it with a normal rec, looks good enough for now |
| 14:55.44 | cvds_ | http://flic.kr/p/aBer23 you can see the result here |
| 14:57.59 | CIA-109 | BRL-CAD: 03brlcad * r47392 10/brlcad/trunk/HACKING: |
| 14:57.59 | CIA-109 | BRL-CAD: add a regex one-liner awesomeness for automatically extracting the latest NEWS |
| 14:57.59 | CIA-109 | BRL-CAD: section into a release notes README-#-#-#.txt file. also fix the release steps |
| 14:57.59 | CIA-109 | BRL-CAD: so that binary platform maintainers are notified before public release |
| 14:57.59 | CIA-109 | BRL-CAD: announcements are posted (so they can have a chance to get started on binary |
| 14:57.59 | CIA-109 | BRL-CAD: builds) |
| 15:07.14 | cvds_ | and for the live of me I dont get solid rotation |
| 15:15.38 | cvds_ | rot takes into account current view angle ? |
| 15:18.39 | cvds_ | hmm arot actually seem to do what I expect |
| 15:30.33 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:36.47 | brlcad | cvds_: primitives rotate around some primitive-specific keypoint, which might not be where you'd expect an origin to be |
| 15:37.01 | brlcad | for a cylinder, for example, it's the center of the base ellipse |
| 15:37.11 | brlcad | for an arb8, it's the first corner |
| 15:37.50 | brlcad | you'd probably expect the object center for both, but to get that behaviour you'll either need to use one of the other rotation commands or set a keypoint explicitly |
| 15:38.50 | cvds_ | brlcad: nope, with rot I was expecting a rotation over 1 primary vertex, but it rotated over more. with arot I specify the vertex explicitly and things are spiffy ;_ |
| 15:38.53 | cvds_ | :) |
| 15:47.38 | CIA-109 | BRL-CAD: 03brlcad * r47393 10/brlcad/trunk/src/util/ (bw-png.c pix-png.c png-bw.c png-pix.c png_info.c): zlib.h needs to be included before png.h in case compression flags are used. also, they're system headers, so use brackets instead of quotes and pull them up into the right section. |
| 15:50.07 | CIA-109 | BRL-CAD: 03brlcad * r47394 10/brlcad/trunk/src/libged/png.c: they're system headers, so use brackets instead of quotes and pull them up into the right section. |
| 15:52.35 | CIA-109 | BRL-CAD: 03brlcad * r47395 10/brlcad/trunk/src/fb/ (fb-png.c png-fb.c): more header cleanup. png/zlib are system headers. use bin.h instead of directly including winsock.h |
| 16:11.34 | *** join/#brlcad abhi2011 (~chatzilla@117.200.83.152) | |
| 16:31.16 | CIA-109 | BRL-CAD: 03abhi2011 * r47396 10/brlcad/trunk/src/libged/simulate/simrt.c: Shooting rays in y direction now and analyzing the normals generated. |
| 16:40.11 | brlcad | ``Erik: you see the new gcc farm server? |
| 16:40.25 | brlcad | 64-proc power7 .. frickin awesome :) |
| 16:40.52 | brlcad | rather, 64-core |
| 16:47.08 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 17:04.46 | brlcad | starseeker: http://paste.debian.net/142105/ |
| 17:05.39 | brlcad | that was a default "cmake .." build |
| 17:48.52 | cvds_ | http://flic.kr/p/aBfMH8 <-- fun making these shapes |
| 17:56.59 | CIA-109 | BRL-CAD: 03abhi2011 * r47397 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h): Added code for shooting z rays and analyzing normals. |
| 18:07.46 | brlcad | cvds_: nice :) |
| 18:07.59 | brlcad | some sort of switch? |
| 18:08.08 | brlcad | electric contact switch ? |
| 18:12.14 | *** join/#brlcad Forth (~Forth@92.242.118.253) | |
| 18:53.45 | CIA-109 | BRL-CAD: 03128.63.32.62 07http://brlcad.org * r3213 10/wiki/Early_Raytracing_History: Stub out page for organizing early raytracing historical reports |
| 18:55.31 | starseeker | brlcad: are the opengl headers present? |
| 18:56.01 | starseeker | what platform? |
| 18:58.29 | brlcad | I don't see any opengl headers |
| 18:58.36 | brlcad | it's a linux |
| 18:59.06 | brlcad | looks like it's Fedora 16 |
| 19:01.26 | starseeker | hmm. Yeah, that's not going to be a widely tested setup |
| 19:01.30 | brlcad | obviously I could probably disable opengl and get past this, but implies the cmake logic isn't right if the default case doesn't properly autodetect and disable |
| 19:01.52 | brlcad | fedora is basically a future RHEL |
| 19:01.52 | starseeker | it's supposed to turn off opengl if it's not there, but I'm not surprised it's not quite right |
| 19:02.10 | starseeker | sans-opengl machines are a rarity these days |
| 19:02.40 | brlcad | this is a brand new system, so not really -- just a different type of configuration |
| 19:03.04 | brlcad | brand new ibm power series |
| 19:03.08 | starseeker | correction - they *should* be a rarity these days, even if they aren't |
| 19:03.17 | brlcad | server platform |
| 19:03.21 | starseeker | still |
| 19:03.25 | brlcad | servers rarely have graphics cards :P |
| 19:03.32 | starseeker | people run opengl apps on servers |
| 19:03.56 | brlcad | not necessarily on compute servers |
| 19:05.36 | brlcad | regardless, it's a bonefide build system bug so it should get fixed... |
| 19:23.19 | *** join/#brlcad Forth (~Forth@92.242.118.253) | |
| 19:47.18 | CIA-109 | BRL-CAD: 03starseeker * r47398 10/brlcad/trunk/ (3 files in 3 dirs): Tweak the OpenGL find routines to care more if the headers are found. |
| 20:00.17 | cvds_ | brlcad: thumb controlled switch. Magnetic / optical |
| 20:01.45 | brlcad | ~starseeker++ |
| 20:01.52 | brlcad | that seems to have done the trick, trying the build now |
| 20:02.31 | brlcad | giggles at make -j100 |
| 20:02.57 | cvds_ | -j100 ... thats many many cores |
| 20:03.07 | cvds_ | I run -j9 *3 |
| 20:09.22 | brlcad | it's a 64 core server |
| 20:09.37 | brlcad | so it actually should be able to juggle that many efficiently :) |
| 20:10.03 | brlcad | lesse how long this build takes.. :) |
| 20:10.18 | starseeker | winces... that's some heavy duty parallelism |
| 20:11.05 | starseeker | haven't actually tried a non-opengl build for months |
| 20:22.25 | CIA-109 | BRL-CAD: 03abhi2011 * r47399 10/brlcad/trunk/src/libged/simulate/simrt.c: |
| 20:22.25 | CIA-109 | BRL-CAD: Some bug fixes to ray shots, now the normals for rigid body B are summed |
| 20:22.25 | CIA-109 | BRL-CAD: correctly when there are overlapping objects : rigid body A and rigid body B. |
| 20:22.25 | CIA-109 | BRL-CAD: Next is shooting a bunch of rays in the direction opposite to this normal, to |
| 20:22.25 | CIA-109 | BRL-CAD: measure the depth of penetration of B into A and finally calculate the bunch of |
| 20:22.26 | CIA-109 | BRL-CAD: contact points on the surface of B which lies inside A(due to the penetration). |
| 20:22.27 | CIA-109 | BRL-CAD: Then we have all the required info to inject into Bullet |
| 20:22.33 | CIA-109 | BRL-CAD: 03starseeker * r47400 10/brlcad/trunk/src/other/CMakeLists.txt: If we turn off opengl, turn off togl too |
| 20:32.11 | brlcad | starseeker: hehe, we have a new winner! |
| 20:32.12 | brlcad | Elapsed compilation time: 41 seconds |
| 20:32.13 | brlcad | Elapsed time since configuration: 1 minute 19 seconds |
| 20:32.21 | starseeker | O.O |
| 20:32.37 | starseeker | it succeeded? |
| 20:32.38 | brlcad | attempts autotools for comparison |
| 20:32.39 | brlcad | yep |
| 20:32.53 | starseeker | if you're doing autotools compare, make sure you turn off the static libs |
| 20:33.01 | starseeker | (unless you enabled them in CMake) |
| 20:33.40 | brlcad | they're default enabled in cmake, so it's fair |
| 20:33.50 | starseeker | only for release config |
| 20:34.01 | starseeker | unless something changed, I have them off in Debug mode |
| 20:35.15 | brlcad | hm, hm |
| 20:35.40 | starseeker | (cept for opennurbs - need to fix that) |
| 20:36.34 | brlcad | is the summary not written out anywhere? |
| 20:36.43 | starseeker | you mean to a file? |
| 20:36.51 | brlcad | I see nothing in the CMakeOutput.log where I'd expect it.. |
| 20:37.02 | starseeker | no - it's just on the console |
| 20:37.22 | brlcad | mm, that's nfg .. there's no way to see the summary ? |
| 20:37.48 | brlcad | seeing AUTO in the cache tells me nothing :) |
| 20:37.59 | starseeker | ah |
| 20:38.26 | starseeker | can probably write it to a file easy enough |
| 20:38.47 | brlcad | ideally the entire cmake output |
| 20:39.34 | brlcad | but minimally the summary is super helpeful for debugging, can tell people to just send you the log file and see what they saw |
| 20:39.57 | starseeker | I don't know of any way offhand to capture just the on-screen output of CMake |
| 20:39.58 | brlcad | use config.log that way all the time |
| 20:40.14 | brlcad | it doesn't have to be just the output |
| 20:40.16 | starseeker | I can teach my summary logic to make a CMakeSummary.log file |
| 20:40.22 | brlcad | config.log is a superset, for example |
| 20:40.42 | brlcad | better to write to the existing CMakeOutput.log |
| 20:41.11 | brlcad | if you need someone to send you a log, you really only want to have to explain how to find/send one file |
| 20:44.53 | starseeker | right - I should be able to append to that file |
| 20:45.51 | brlcad | three times I've been bitten by the bundled/system/auto trio |
| 20:46.29 | starseeker | bitten how? |
| 20:46.35 | brlcad | most of the vars are on/off/auto, but the dep build flags aren't |
| 20:46.53 | CIA-109 | BRL-CAD: 03bob1961 * r47401 10/brlcad/trunk/src/tclscripts/mged/openw.tcl: Check the display manager type before setting the zbuffer state in "proc gui" |
| 20:47.15 | brlcad | I configure with BRLCAD_BUNDLED_LIBS as "ON" .. and don't get them all on, defaults back to auto because I didn't enter "BUNDLED" ;) |
| 21:24.00 | CIA-109 | BRL-CAD: 03brlcad * r47402 10/brlcad/trunk/src/ (12 files in 6 dirs): gcc continues to get smarter. apply fixes for issues detected by gcc 2.6.1, vars set but unused, unsigned 'char' that need to be int, and other type corrections. |
| 21:24.24 | starseeker | 2.6.1? |
| 21:24.28 | starseeker | yow |
| 21:26.34 | *** join/#brlcad merzo (~merzo@205-134-133-95.pool.ukrtel.net) | |
| 21:27.41 | CIA-109 | BRL-CAD: 03abhi2011 * r47403 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simutils.c): Need to keep track of normals encountered so far, for a ray passing through rigid_body B, otherwise the same normals added twice will skew the resultant normal direction. |
| 21:28.37 | brlcad | with static: Elapsed compilation time: 57 seconds |
| 21:29.01 | brlcad | though not as controlled as the first build |
| 21:29.22 | brlcad | libpng is provoking some ld bug that I had to work around |
| 21:30.37 | CIA-109 | BRL-CAD: 03abhi2011 * r47404 10/brlcad/trunk/src/libged/simulate/simrt.c: Corrected the initialization of the number of normals. |
| 21:31.16 | starseeker | still - pretty darn impressive |
| 21:31.43 | starseeker | (or possibly impressive - perhaps autotools will do as well) |
| 21:33.36 | starseeker | brlcad: does that include docbook? |
| 21:34.59 | brlcad | if I had the summary in a log file, I could tell you ;) |
| 21:35.10 | starseeker | heh |
| 21:35.30 | starseeker | getting close |
| 21:35.47 | brlcad | autotools failed in the docbook section after 3min, so presuming it's compiling the same stuff, cmake is considerably faster |
| 21:36.53 | brlcad | though that's really a comparison of recursive make to non-recursive make, it's still a huge gain |
| 21:39.47 | CIA-109 | BRL-CAD: 03starseeker * r47405 10/brlcad/trunk/ (3 files in 2 dirs): |
| 21:39.47 | CIA-109 | BRL-CAD: Try a cute trick - override the message command to enhance logging. |
| 21:39.47 | CIA-109 | BRL-CAD: CMakeFiles/CMakeOutput.log should now have almost all messages from the cmake |
| 21:39.47 | CIA-109 | BRL-CAD: configure process - possible exceptions are those written out without using the |
| 21:39.47 | CIA-109 | BRL-CAD: MESSAGE command. Also make a stab at accepting ON and OFF for the |
| 21:39.48 | CIA-109 | BRL-CAD: AUTO/BUNDLED/SYSTEM vars |
| 21:39.48 | brlcad | there we go, so yeah .. about 3min20sec for autotools, enable-all, debug, with docs (no pdf) |
| 21:40.03 | brlcad | that's my usual compilation benchmark |
| 21:40.12 | starseeker | nifty :-) |
| 21:40.33 | starseeker | that's configure + build? |
| 21:40.54 | brlcad | configure was faster than cmake.. :) |
| 21:41.05 | starseeker | humph - figures |
| 21:41.33 | brlcad | and that's not even considering that I have to run cmake three times if run via ccmake to get an enable-all build |
| 21:41.51 | starseeker | nods - command line cmake ftw |
| 21:41.57 | brlcad | the system is using ccache, so I'll have to rerun to make sure there's not some object file caching going on too |
| 21:43.25 | brlcad | if I could get a list of our variables from cmake (e.g., cmake --help-variables) like configure, it'd be more feasible to run via command-line |
| 21:43.36 | brlcad | don't have the vars memorized |
| 21:43.48 | starseeker | nods - I need to finish the configure.cmake script |
| 21:44.20 | starseeker | I've got enable-all in there, but not the static libs flag |
| 21:44.52 | brlcad | in where? |
| 21:45.01 | brlcad | oooh, wrapper |
| 21:45.05 | starseeker | yeah |
| 21:45.21 | brlcad | bleh, that's cheating :) |
| 21:45.27 | starseeker | have expected you to take that and finish it so you wouldn't have to worry about the CMake options anymore |
| 21:45.33 | starseeker | :-P |
| 21:46.07 | brlcad | only after the core system is already near-optimal |
| 21:46.16 | brlcad | hacking on top of hacks is bad practice |
| 21:46.57 | brlcad | that goes for absolutely any code, it's only closed API that you have to put up with that |
| 21:47.14 | starseeker | hopes to $deity that we don't have much further to go, but suppose he knows better... |
| 21:47.28 | brlcad | I give it about two years |
| 21:52.38 | brlcad | doesn't persist an "off" setting, otherwise looks like it's closer |
| 21:55.33 | brlcad | there, more controlled rebuild was 1min38sec |
| 21:55.49 | brlcad | cmake, enable all (cept png), debug, with docs |
| 21:55.55 | brlcad | not too shabby |
| 21:56.08 | brlcad | double that time for the three config passes |
| 21:57.23 | starseeker | the second and third config passes should be considerably shorter... |
| 21:59.27 | cvds_ | about 50% according to the previous statement ? |
| 22:00.51 | brlcad | there, about 3min30sec for a repeat autotools build |
| 22:01.10 | brlcad | so roughly cutting the time in half or a third |
| 22:01.46 | cvds_ | heh... using combination and oed you can cut back on a lot of solids |
| 22:04.47 | CIA-109 | BRL-CAD: 03starseeker * r47406 10/brlcad/trunk/misc/CMake/ (BRLCAD_Util.cmake ThirdParty_TCL.cmake): Check for on and off in the optname, not the default |
| 22:38.06 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 00:34.10 | CIA-109 | BRL-CAD: 03starseeker * r47407 10/brlcad/trunk/src/libged/simulate/simrt.c: Need unused on these parameters for now to allow strict build to succeed |
| 01:05.58 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 01:14.52 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 01:50.39 | CIA-109 | BRL-CAD: 03Starseeker 07http://brlcad.org * r3214 10/wiki/Early_Raytracing_History: Flesh out intro, add list of MAGIC documents (most of the links not live yet) |
| 02:01.27 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 02:02.26 | Technicus | ello . . . I have about no extensive practical CAD or significant knowledge and I am attempting to design a cabin for a motorhome. I am undertaking the opportunity to learn what I can with this project. Currently I would like to start desiging the framework, would BRL-CAD be an adaquat application for this task? |
| 02:39.25 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 03:05.08 | CIA-109 | BRL-CAD: 03Starseeker 07http://brlcad.org * r3215 10/wiki/Early_Raytracing_History: Stub in some more categories and tables, smattering of links - GIFT and BRL-CAD will have much longer lists than MAGIC! |
| 03:23.00 | CIA-109 | BRL-CAD: 03Starseeker 07http://brlcad.org * r3216 10/wiki/Early_Raytracing_History: Another comgeom model report |
| 03:31.10 | CIA-109 | BRL-CAD: 03Starseeker 07http://brlcad.org * r3217 10/wiki/Early_Raytracing_History: com-geom debugger |
| 03:32.20 | *** join/#brlcad abhi2011 (~chatzilla@117.200.81.173) | |
| 03:37.45 | CIA-109 | BRL-CAD: 03Starseeker 07http://brlcad.org * r3218 10/wiki/Early_Raytracing_History: /* GIFT */ add another GIFT/COMGEOM application report |
| 05:27.39 | *** join/#brlcad abhi2011 (~chatzilla@117.200.81.254) | |
| 05:27.54 | CIA-109 | BRL-CAD: 03abhi2011 * r47408 10/brlcad/trunk/src/libged/simulate/ (simrt.c simutils.c simutils.h): |
| 05:27.54 | CIA-109 | BRL-CAD: Normals already encountered, were not being added to the list of normals, fixed |
| 05:27.54 | CIA-109 | BRL-CAD: that. There are situations where summing the normals in the overlapping surface |
| 05:27.54 | CIA-109 | BRL-CAD: alone will not give the exact direction from which a body is hitting another |
| 05:27.54 | CIA-109 | BRL-CAD: body. But simply using the velocity also does not work for all cases to find |
| 05:27.54 | CIA-109 | BRL-CAD: this direction. Somewhere these 2 ways need to be merged or chosen from , based |
| 05:27.55 | CIA-109 | BRL-CAD: upon criteria. |
| 05:34.38 | CIA-109 | BRL-CAD: 03Starseeker 07http://brlcad.org * r3219 10/wiki/Early_Raytracing_History: tweaks |
| 05:36.59 | CIA-109 | BRL-CAD: 03Starseeker 07http://brlcad.org * r3220 10/wiki/Early_Raytracing_History: /* MAGIC */ tweak |
| 08:22.08 | *** join/#brlcad b0ef (~b0ef@78.58.34.95.customer.cdi.no) | |
| 09:39.04 | *** join/#brlcad abhi2011 (~chatzilla@117.200.89.195) | |
| 11:50.56 | brlcad | Technicus: it depends on your goals, but for the basic modeling for layout and visualization, sure |
| 11:51.26 | brlcad | if you're hoping for it to spit out blueprints or construction parts lists, then not so adaquate |
| 11:58.31 | cvds_ | is it possible to get the actual dimensions of a primitive from within a combination ? |
| 11:58.40 | cvds_ | (with all matrices in the tree applied) |
| 12:05.14 | CIA-109 | BRL-CAD: 03Caddui 07http://brlcad.org * r3221 10/wiki/NURBS_TODO: |
| 12:25.04 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r3222 10/wiki/NURBS_TODO: Reverted edits by [[Special:Contributions/Caddui|Caddui]] ([[User talk:Caddui|Talk]]); changed back to last version by [[User:Sean|Sean]] |
| 12:25.58 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Caddui]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 12:34.07 | cvds_ | aha, using l with the full path seems to provide just that |
| 12:45.15 | Technicus | brlcad: Thanks . . . that might possibly be about enough to get me started. |
| 13:12.27 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 13:27.28 | brlcad | cvds_: yep, exactly that way ;) |
| 13:27.54 | brlcad | you could also clone the object, xpush, then l the primtive |
| 13:28.34 | brlcad | you can get dimensions on other non-primitive objects on a line-of-sight basis using the ruler tool, the ADC angle-distance-cursor, and/or nirt |
| 13:31.30 | cvds_ | brlcad: I can not push, same sub-combination used in other bigger combinations but rotated and translated |
| 13:32.17 | cvds_ | i will check those other tools later /me makes mental notes. |
| 13:32.32 | cvds_ | Now to fix a clean way for these not critical overlaps ... |
| 13:34.17 | cvds_ | I guess I just have to clip the corners of these parts |
| 13:36.39 | brlcad | cvds_: xpush is not the same as push :) |
| 13:36.51 | brlcad | xpush will split multiply referenced objects |
| 13:37.51 | brlcad | I'd recommend avoiding xpush/push regardless just because you lose a localized coordinate space on the primitives, but it can be useful if you repeatedly need their values in global position |
| 13:38.52 | brlcad | that's also why I suggested clone first, since that will perform a deep copy that you can "destroy" with xpush, just to peek at the values in global position |
| 13:40.23 | cvds_ | brlcad: ah with clone, that makes sense :) |
| 13:40.45 | cvds_ | hrmz... this design tidbit is becoming a nightmare |
| 13:50.41 | *** join/#brlcad abhi2011 (~chatzilla@117.200.87.121) | |
| 14:03.05 | cvds_ | phew made it fit |
| 14:15.28 | *** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz) | |
| 14:15.40 | pawleeq | Hello |
| 14:16.52 | pawleeq | I have written a short article introducing BRL-CAD to wider czech public: http://www.abclinuxu.cz/clanky/brl-cad-strucne-predstaveni |
| 14:33.33 | cvds_ | hmm copymat on the quickref says that I can copy a matrix from one path to another path... but when I try this its complaining about arcs ? |
| 14:35.46 | cvds_ | (I want to use it to move an object to the exact space of another object so that I can subtract it) |
| 14:46.40 | cvds_ | and googling this only finds c files |
| 14:48.22 | cvds_ | hmm Ensure that each argument contains exactly one slash <-- hint located |
| 15:06.30 | cvds_ | yup that worked |
| 16:11.14 | ``Erik | nice http://article.gmane.org/gmane.comp.version-control.git/57918 |
| 16:14.53 | abhi2011 | I am trying to use rt_gen_circular_grid() to generate a circular grid of rays (its defined in mkbundle.c) |
| 16:15.08 | abhi2011 | int rt_gen_circular_grid(struct xrays *rays, const struct xray *center_ray, fastf_t radius, const fastf_t *up_vector, fastf_t gridsize) |
| 16:15.50 | abhi2011 | so here gridsize is the size of the edge of the square, which bounds the circle of radius = radius |
| 16:16.48 | abhi2011 | I think thats the case, but I would like to be certain of that |
| 17:02.41 | ``Erik | iirc, that func does a funky polar fill, 'gridsize' comes out to some combination of layers and radians |
| 17:02.51 | ``Erik | so the outer rings are less dense than the inner ones |
| 17:03.31 | ``Erik | there was a similar one that indianlarry bolted in a few months back due to different ray density requirements, I think |
| 17:15.53 | CIA-109 | BRL-CAD: 03abhi2011 * r47409 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simrt.c simrt.h): Started shooting for getting the depth and points on surface of object B |
| 17:27.45 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 17:36.05 | abhi2011 | Erik: ok I thought that rays would be generated in a square grid, with those rays that lie within the circle getting accepted in the structure returned to the caller |
| 17:37.04 | brlcad | pawleeq: ah, that was you! .. saw that a couple days ago |
| 17:37.12 | brlcad | awesome |
| 17:37.30 | brlcad | my czech-to-english translator totally failed on it, though :) |
| 17:38.00 | brlcad | looks like ia nice detailed discussion got started |
| 18:08.08 | pawleeq | brlcad: czech is quite hard to learn and even impossible for automated translators |
| 18:12.09 | pawleeq | the discussion is full of trolls flaming about CATIA and how BRL-CAS is unusable for construction design |
| 18:13.10 | CIA-109 | BRL-CAD: 03Starseeker 07http://brlcad.org * r3223 10/wiki/Early_Raytracing_History: /* MAGIC */ Add links to MAGIC docs |
| 18:17.43 | CIA-109 | BRL-CAD: 03Starseeker 07http://brlcad.org * r3224 10/wiki/Early_Raytracing_History: /* MAGIC */ tweaks |
| 19:21.30 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.114) | |
| 19:33.50 | CIA-109 | BRL-CAD: 03starseeker * r47410 10/brlcad/trunk/doc/docbook/system/man1/en/coil.xml: fix coil man page |
| 19:35.24 | CIA-109 | BRL-CAD: 03starseeker * r47411 10/geomcore/trunk/doc/docbook/CMakeLists.txt: remove debug blather |
| 20:10.10 | CIA-109 | BRL-CAD: 03abhi2011 * r47412 10/brlcad/trunk/src/libged/simulate/simrt.c: Trying to fix a bug related to generating a circular grid of rays along a specific direction. |
| 20:18.17 | CIA-109 | BRL-CAD: 03brlcad * r47413 10/brlcad/trunk/include/magic.h: match BU_CKMAG() |
| 20:20.34 | CIA-109 | BRL-CAD: 03brlcad * r47414 10/brlcad/trunk/include/fb.h: |
| 20:20.34 | CIA-109 | BRL-CAD: fix abort on 64-bit power7 (big endian) due to bad magic number checking. the |
| 20:20.34 | CIA-109 | BRL-CAD: cast through intptr_t was causing a zero-value to result, failing the magic |
| 20:20.34 | CIA-109 | BRL-CAD: number test. change the macro to just treat the ifp pointer as a pointer to a |
| 20:20.34 | CIA-109 | BRL-CAD: uint32_t and we should get the number we were looking for. |
| 20:23.35 | CIA-109 | BRL-CAD: 03brlcad * r47415 10/brlcad/trunk/include/fb.h: dumbass. else if. |
| 21:21.22 | CIA-109 | BRL-CAD: 03brlcad * r47416 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: don't fake the alloc. sizes might be null and we'll just bomb. |
| 21:27.56 | CIA-109 | BRL-CAD: 03brlcad * r47417 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: do what was done for v4, validate the dsp dimensinos are non-zero |
| 21:41.53 | CIA-109 | BRL-CAD: 03brlcad * r47418 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: vls might be null, so don't try to get the address. allow 1x1 dsp without warning. fix y-axis warning. |
| 21:47.35 | CIA-109 | BRL-CAD: 03brlcad * r47419 10/brlcad/trunk/include/rtgeom.h: add a TODO. dsp_name should probably be a pointer so we know when it's been initialized and so the dsp struct itself will consume less memory. |
| 21:48.09 | CIA-109 | BRL-CAD: 03brlcad * r47420 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: still have to init the vls, otherwise we can't print it even if it's empty. |
| 21:51.14 | *** part/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz) | |
| 22:12.38 | CIA-109 | BRL-CAD: 03starseeker * r47421 10/brlcad/trunk/src/other/ (7 files in 2 dirs): Add a vanilla check-in of clipper 4.6 - Bob needs to track some tweaks he is making to it. Extra dist it until it goes live. |
| 22:28.12 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 22:48.20 | brlcad | starseeker: er, you changed it from -l to -L but then documented extra detail on -l ... ;) |
| 22:49.37 | CIA-109 | BRL-CAD: 03brlcad * r47422 10/brlcad/trunk/NEWS: cliff expanded the manpage on how the -l/-L parameter works |
| 22:51.00 | brlcad | ah, nevermind.. misread the patch .. cool |
| 02:13.17 | *** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 02:13.49 | *** part/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 10:32.55 | CIA-109 | BRL-CAD: 03Fywijydoze 07http://brlcad.org * r3225 10/wiki/Uk_essays: New page: All students obviously want to imppress their teachers but not always want to do their best. Better let anyone else do monkey job for them. Writing essays is boring and takes a lot of time... |
| 11:57.31 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 12:21.41 | CIA-109 | BRL-CAD: 03bob1961 * r47423 10/brlcad/trunk/src/other/clipper/ (clipper.cpp clipper.hpp): Eliminate using == and != to compare doubles. Now using CLIPPER_NEAR_ZERO and CLIPPER_NEAR_EQUAL. Also fixed a few syntax errors. |
| 12:53.22 | CIA-109 | BRL-CAD: 03bob1961 * r47424 10/brlcad/trunk/src/other/clipper/ (clipper.cpp clipper.hpp): Added methods to overload the AddPolygon and AddPolygons methods for adding ExPolygons. |
| 13:29.05 | *** join/#brlcad abhi2011 (~chatzilla@117.200.85.105) | |
| 13:49.14 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Uk essays]]": a$$hole |
| 13:49.29 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Fywijydoze]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 13:51.10 | *** join/#brlcad abhi2011 (~chatzilla@117.200.86.161) | |
| 13:54.52 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 16:30.35 | *** join/#brlcad abhi2011 (~chatzilla@117.200.87.255) | |
| 17:19.11 | CIA-109 | BRL-CAD: 03brlcad * r47425 10/brlcad/trunk/src/libbn/ (CMakeLists.txt Makefile.am README): add a basic readme for libbn so I can document the list of core functions heavily used during tessellation identified by richard. |
| 17:37.39 | CIA-109 | BRL-CAD: 03brlcad * r47426 10/brlcad/trunk/ (6 files in 4 dirs): move and remove rt_dist_pt3_line3 from librt's nmg_misc.c to libbn's plane.c where it's in better/related company. minimally impacting change for the upcoming minor release. |
| 17:48.48 | CIA-109 | BRL-CAD: 03brlcad * r47427 10/brlcad/trunk/src/libbn/README: renamed to bn_dist_pt3_line3 |
| 17:54.26 | starseeker | build busted... |
| 17:55.23 | starseeker | ah |
| 17:55.37 | CIA-109 | BRL-CAD: 03starseeker * r47428 10/brlcad/trunk/include/bn.h: Should be BN_EXPORT here |
| 18:00.26 | brlcad | sorry about that -- I'd already fixed it locally but you beat me to the commit |
| 18:00.46 | CIA-109 | BRL-CAD: 03brlcad * r47429 10/brlcad/trunk/ (7 files in 5 dirs): also migrate the remaining two API smells from librt to libbn: rt_dist_line3_line3 and rt_dist_line3_lseg3. minimally impacting. |
| 18:04.52 | *** join/#brlcad abhi2011 (~chatzilla@117.200.82.44) | |
| 18:09.06 | starseeker | np |
| 18:12.31 | CIA-109 | BRL-CAD: 03starseeker * r47430 10/brlcad/trunk/include/bn.h: need semicolon here |
| 18:15.47 | CIA-109 | BRL-CAD: 03starseeker * r47431 10/brlcad/trunk/src/libbn/plane.c: we're in libbn, so used the same debug triggers as other bn functions... |
| 18:18.53 | starseeker | there we go :-) |
| 18:56.15 | abhi2011 | hm I am getting linking errors in windows |
| 18:57.01 | abhi2011 | http://bin.cakephp.org/view/1262657315 |
| 18:57.46 | abhi2011 | probably not linking to opengl in someway |
| 19:05.23 | brlcad | that's exactly what's happening |
| 19:06.08 | brlcad | it's on the issttcltk binary, so it may simply be a lib missing from that build file |
| 19:08.49 | brlcad | abhi2011: try that |
| 19:08.50 | CIA-109 | BRL-CAD: 03brlcad * r47432 10/brlcad/trunk/src/adrt/CMakeLists.txt: do the same hack that libfb uses, specify the .lib file for opengl explicitly, even though it should be added by the OPENGL_LIBRARIES var |
| 19:31.32 | abhi2011 | brlcad: thanks ! that worked :) |
| 19:39.04 | brlcad | great |
| 19:39.05 | CIA-109 | BRL-CAD: 03abhi2011 * r47433 10/brlcad/trunk/src/libged/simulate/simrt.c: Generating a circular bundle of rays to shoot in the direction of the resultant normal by calling rt_gen_circular_grid() through a BU_LIST |
| 19:39.48 | brlcad | maybe starseeker can add the proper juju to test for and link opengl32.lib |
| 19:40.36 | CIA-109 | BRL-CAD: 03abhi2011 * r47434 10/brlcad/trunk/src/libged/simulate/simrt.c: woops, must free the list too. |
| 19:41.16 | abhi2011 | yes, cmake would return opengl32.lib correctly I think |
| 19:42.34 | abhi2011 | the Bullet project seems to now have support for premake as well |
| 19:43.11 | abhi2011 | some debates on about cmake vs premake :P |
| 19:44.16 | abhi2011 | http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?t=7445 |
| 19:44.52 | abhi2011 | a more interesting one : http://altdevblogaday.com/2011/03/13/meta-build-systems/ |
| 20:19.17 | CIA-109 | BRL-CAD: 03abhi2011 * r47435 10/brlcad/trunk/src/libged/simulate/simrt.c: Circular bunch of rays are being generated correctly, time to shoot 'em. |
| 20:24.07 | brlcad | "Unfortunately, the main cmake developers don?t want to support distributable project file generation, and I felt they were very reluctant to discuss further changes to support distributable project files." <-- very sad |
| 20:48.04 | abhi2011 | yeah, but that may just be a bit overboard, maybe they want to just stabilize the current code base :) |
| 20:48.22 | abhi2011 | before adding features |
| 21:39.24 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 21:42.26 | CIA-109 | BRL-CAD: 03n_reed * r47436 10/brlcad/trunk/src/other/re2c/ (CMake/FindLEMON.cmake parser.y.lemon): working on lemon input to replace re2c's yacc input |
| 22:15.25 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 22:38.03 | starseeker | abhi2011: no, I've had that conversation with the CMake list as well |
| 22:38.26 | abhi2011 | oh ok |
| 22:38.48 | abhi2011 | so I have a question regarding a warning I keep getting in the windows build |
| 22:38.56 | starseeker | they're not going to re-engineer CMake to be able to work without CMake being present - they use the CMake executable itself as a cross-platform substitute for a lot of things |
| 22:39.30 | starseeker | having to use OS specific tools for that is a considerable complication, and I'm not surprised they want to avoid it |
| 22:39.42 | starseeker | what's the warning? |
| 22:39.59 | abhi2011 | ok |
| 22:40.03 | abhi2011 | <PROTECTED> |
| 22:40.03 | starseeker | expects there are a few build flags floating around that MSVC doens't understand... |
| 22:40.04 | abhi2011 | 4> f:\code\socis\brlcad\include\common.h(252) : see previous definition of 'IGNORE' |
| 22:40.16 | starseeker | oh, that one |
| 22:40.30 | abhi2011 | so I tried putting common.h on the top of all my files |
| 22:40.36 | starseeker | nods - correct |
| 22:40.37 | abhi2011 | but that doesnt seem to solve the issue |
| 22:40.45 | starseeker | really... |
| 22:41.16 | abhi2011 | I guess the macro will still be defined in both places, because the winbase.h files is included after again |
| 22:41.48 | starseeker | uh... why is it getting included again? |
| 22:42.38 | abhi2011 | hmm, no its probably not |
| 22:43.06 | abhi2011 | but somewhere both are conflicting |
| 22:43.24 | abhi2011 | let me check common.h |
| 22:48.19 | abhi2011 | hmm I can find winbase.h only in the binaries in the cmake build directory |
| 22:48.36 | abhi2011 | so they must be getting included in some source file |
| 22:53.45 | abhi2011 | hmm, an include is there in ./other/tcl/win/tclWinInit.c:#include <winbase.h> |
| 23:00.55 | CIA-109 | BRL-CAD: 03abhi2011 * r47437 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h): Got the contact points, removed some unnecessary older code, now they need to inserted correctly in Bullet. Need to check if the area of the contact points need to be maximized. |
| 23:01.46 | starseeker | the bullet headers aren't pulling it in anywhere? |
| 23:05.28 | abhi2011 | they probably are :P |
| 23:07.10 | starseeker | wonders how to suggest to Microsoft that it add support to Visual Studio for CMake projects directly... AFAIK the license would all them to bundle the CMake engine under the hood and just eat the CMakeLists.txt projects directly... |
| 23:08.00 | abhi2011 | yes |
| 23:08.02 | starseeker | s/all/allow |
| 23:08.54 | starseeker | *really* doesn't want to see Bullet switch off of CMake - that just means we'd have to pick up maintaining it - growl |
| 23:11.10 | starseeker | hmm... I suppose we could spam this site... http://visualstudio.uservoice.com/forums/121579-visual-studio/category/35066-ide |
| 23:12.21 | starseeker | and tell them to make the clang compiler an option here... http://visualstudio.uservoice.com/forums/121579-visual-studio/category/30937-languages-c- |
| 23:15.22 | abhi2011 | yep I ll put the word in there :) |
| 23:15.39 | abhi2011 | I just get winbase.h in binary files though |
| 23:15.58 | abhi2011 | seems like the compiler is putting it in the .pdb and .idb files |
| 23:16.11 | abhi2011 | which I think are debugging symbol databases |
| 23:17.02 | abhi2011 | hmm .obj files too |
| 23:22.10 | brlcad | abhi2011: the issue is where winbase.h is getting included |
| 23:22.27 | brlcad | you have to put a wrapper around whatever is including it |
| 23:22.48 | brlcad | we wrap all the places I know if in our headers where windows headers get included |
| 23:23.02 | brlcad | find where it's getting included, then it can be fixed |
| 23:23.23 | abhi2011 | yes, I searched the source directory of bullet and the build directory, same for brl-cad directories, didnt find it anywhere |
| 23:23.35 | brlcad | not likely going to find it that way.. :) |
| 23:23.48 | abhi2011 | grep :) |
| 23:24.01 | abhi2011 | well I did grep through them |
| 23:24.08 | brlcad | grep will only work if you're grepping the right header files |
| 23:24.30 | abhi2011 | yeah I grepped at the top level source folder |
| 23:24.36 | abhi2011 | and include folder too |
| 23:24.39 | brlcad | I suspect winbase.h is getting included indirectly by some *other* windows header, perhaps by even some other header still, then getting included in source |
| 23:24.40 | abhi2011 | will try once more |
| 23:24.47 | abhi2011 | yeah |
| 23:24.50 | abhi2011 | maybe windows.h |
| 23:24.59 | abhi2011 | in the visual c++ includes |
| 23:25.01 | brlcad | grepping for winbase.h isn't useful, nor is guessing :) |
| 23:25.10 | brlcad | your files are short, only include a few files |
| 23:25.43 | brlcad | put an #undef IGNORE before the last header, compile -- see if error goes away |
| 23:25.55 | brlcad | assuming it doesn't, move #undef up before the next-to-last header, repeat |
| 23:26.04 | abhi2011 | ah ok |
| 23:26.24 | brlcad | repeat until you find which one makes the error go away, if it's one of your headers, then repeat the whole process on the #includes within that header |
| 23:26.28 | brlcad | same if it's one of ours |
| 23:26.44 | brlcad | if it's one of bullet's then you have your inclusion point |
| 23:26.56 | abhi2011 | ok |
| 23:27.01 | brlcad | once you find it, then you can wrap that header with protections like we use in include/bin.h |
| 23:27.15 | brlcad | it's about 5 or 6 lines |
| 23:28.53 | abhi2011 | ok |
| 23:29.04 | abhi2011 | yes I ll try that :) |
| 02:05.38 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 02:16.51 | *** join/#brlcad abhi2011 (~chatzilla@117.200.84.170) | |
| 05:29.26 | CIA-109 | BRL-CAD: 03abhi2011 * r47438 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simulate.c simulate.h): Cleaned up some redundant code and completed contact point generation logic. |
| 06:45.02 | *** join/#brlcad abhi2011 (~chatzilla@117.200.92.33) | |
| 07:44.22 | CIA-109 | BRL-CAD: 03abhi2011 * r47439 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simulate.c simulate.h): Fixing some bugs in the contact generation logic. |
| 09:15.33 | CIA-109 | BRL-CAD: 03Johnjones 07http://brlcad.org * r3226 10/wiki/Main_Page: minor edit |
| 09:17.38 | *** join/#brlcad abhi2011 (~chatzilla@2002:6ee3:d46a::6ee3:d46a) | |
| 12:56.34 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r3227 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/Johnjones|Johnjones]] ([[User talk:Johnjones|Talk]]); changed back to last version by [[User:Sean|Sean]] |
| 12:56.37 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Johnjones]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 13:25.55 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 13:51.28 | *** join/#brlcad abhi2011 (~chatzilla@117.200.88.67) | |
| 14:00.23 | abhi2011 | finally, the box-box case seems to be working : http://imageshack.us/photo/my-images/407/force.png/ |
| 14:00.30 | abhi2011 | one box falling on another |
| 14:01.02 | abhi2011 | this is using contact points, normals, and penetration depth only(all 3 got using raytracing) |
| 14:01.31 | abhi2011 | except for the normal which is simply the velocity direction |
| 14:02.05 | abhi2011 | of whichever body, Bulletr considers to be body B in a colliding pair |
| 14:02.22 | abhi2011 | s/Bulletr/Bullet |
| 14:04.38 | abhi2011 | will try dropping a sphere now and check if the manifold is generated at the correct point on its surface |
| 14:13.07 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3228 10/wiki/User:Abhijit: /* Log : Nov 5th */ |
| 14:15.37 | brlcad | abhi2011: that is totall awesome :) |
| 14:16.04 | abhi2011 | woops, bad screen shoot :P |
| 14:16.17 | abhi2011 | *shot |
| 14:17.21 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3229 10/wiki/User:Abhijit: /* Log */ |
| 14:19.03 | abhi2011 | so the linear velocity approach you suggested , helps avoid a lot of raytracing and thus each iteration is much faster |
| 14:19.57 | abhi2011 | a slowdown is evident only when a big box falls directly on an even larger box, in which cased the contact region is quite large and a large number of rays need to be shot |
| 14:21.07 | abhi2011 | it can be optimized however by shooting rays inwards from the periphery of the overlap region and as soon as about 4 points are got, the density of the rays can be reduced (for shooting near the inner regions etc) |
| 14:21.23 | abhi2011 | maybe it can be yet be optimized to real time :) |
| 14:33.14 | brlcad | should be possible -- the biggest time is going to be prep setup |
| 14:34.48 | brlcad | without prep, you could shoot 100000 rays and still remain interactive on most models |
| 14:35.54 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3230 10/wiki/User:Abhijit: /* Log */ |
| 14:36.28 | abhi2011 | so you mean, I should not prep ? |
| 14:37.01 | abhi2011 | since the bounding box function will work without prep |
| 14:37.09 | brlcad | you have to prep :) |
| 14:37.17 | abhi2011 | oh hmm :P |
| 14:37.25 | brlcad | well, you have to prep to shoot rays |
| 14:37.33 | abhi2011 | yeah for rt , have to prep |
| 14:37.40 | brlcad | if the boxes don't even overlap, then definitely .. don't prep, don't shoot rays :) |
| 14:37.51 | abhi2011 | yes |
| 14:39.01 | abhi2011 | if the boxes move even by a millimeter, there is no way to update a tiny part of the model saved for raytracing, (after prep ) ? |
| 14:39.33 | abhi2011 | so like, if anything moves, the raytracing process needs to be done all over again ? |
| 14:41.07 | abhi2011 | I do that currently, but was wondering if its at all possible to modify a part of the model and then prep only that part (after the whole scene is prepped, but something has moved - in the next physics iteration, )which would be faster |
| 14:43.20 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3231 10/wiki/User:Abhijit: /* Log Nov 5th, more info */ |
| 14:43.54 | brlcad | yeah, we've talked about adding support for cache objects but it's a fairly complex subject |
| 14:44.03 | abhi2011 | ok |
| 14:44.28 | brlcad | you'd have to cache per object and have some way to quickly determine whether a cache is invalid and for even medium-sized objects, it's almost faster to just reprep |
| 14:44.30 | abhi2011 | possible a warm start kind of thing, rather than a complete cold start from scratch each time |
| 14:44.47 | abhi2011 | oh ok |
| 14:45.04 | brlcad | the dominant time is setting up the spatial partitioning, which does have to change with every change to the scene |
| 14:45.29 | abhi2011 | but will it change drastically for millimeter scale movements |
| 14:45.42 | brlcad | no way to know |
| 14:45.50 | abhi2011 | ok |
| 14:46.04 | brlcad | if it pops into a different cell, it could be a drastic change to the spatial partitioning |
| 14:46.14 | abhi2011 | yeah |
| 14:46.31 | brlcad | would have to employ a completely different spatial partitioning algorithm, something more tuned for incremental updates |
| 14:46.52 | abhi2011 | ok |
| 14:47.03 | brlcad | generally don't perform as well for static scenes, but they can be updated more quickly ... |
| 14:47.07 | brlcad | something maybe for down the road |
| 14:47.25 | abhi2011 | yes :) |
| 14:47.29 | brlcad | but I suspect cpus will be faster before that happens to the point that it won't matter or some other solution will present itself ;) |
| 14:47.40 | abhi2011 | hehe yeah , true |
| 14:48.05 | brlcad | that new power7 server I was playing with earlier in the week was impressive, giving about 512x512 at 30fps |
| 14:48.22 | brlcad | 30fps raytraced :) |
| 14:48.40 | abhi2011 | oh wow |
| 14:49.00 | abhi2011 | 64 cores you said ? |
| 14:49.11 | brlcad | not the fastest I've seen, and you can get a WHOLE lot faster with polygonal models, but for full shotline (solid) raytracing, that's pretty impressive |
| 14:49.27 | abhi2011 | ok |
| 14:49.36 | brlcad | yeah, 64 cores |
| 14:49.39 | abhi2011 | how many solid were there in the scene |
| 14:50.30 | brlcad | technically I believe it's 8 cpus with 2 cores per cpu and 4 asynchronous threads per core |
| 14:50.59 | abhi2011 | ok |
| 14:51.15 | brlcad | so not much faster than the fastest workstation you can already buy today |
| 14:52.14 | brlcad | maybe a dozen solids, it wasn't a huge model, but even a complex model with a few thousand regions (and thousands of prims) was >10fps iirc |
| 14:52.42 | abhi2011 | oh , thats pretty cool :) |
| 14:52.46 | abhi2011 | <PROTECTED> |
| 14:52.50 | abhi2011 | caustic rt i think |
| 14:53.07 | abhi2011 | on FPGAs |
| 14:53.12 | brlcad | yeah, there's a bunch of them |
| 14:54.00 | brlcad | the stats become completely different when you only consider triangle mesh models, and even further still only consider making pretty pictures (i.e., first hit only) |
| 14:54.26 | brlcad | both things that *substantially* make things faster, but aren't practical for analysis or solid ray tracing |
| 15:57.37 | starseeker | ponders trying to get his hands on an IBM T221 |
| 17:17.37 | starseeker | ``Erik: know anything about how to hook up a T221 to a modern machine? |
| 17:31.22 | cvds_ | is there an easy way to combine rpp with 2 arb6 in between ? |
| 20:07.03 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.159) | |
| 20:51.00 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.107) | |
| 01:45.37 | *** join/#brlcad abhi2011 (~chatzilla@117.200.83.94) | |
| 07:20.18 | *** join/#brlcad abhi2011 (~chatzilla@117.200.83.219) | |
| 10:29.56 | cvds_ | just omitting the 2 arb6 and just use and arb8 as the center part makes it a lot easier |
| 11:47.30 | *** join/#brlcad abhi2011 (~chatzilla@117.200.83.227) | |
| 11:56.43 | *** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 12:34.58 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 12:55.05 | *** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 13:24.07 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 13:39.45 | ``Erik | starseeker: no... 3840x2400, impressive... wiki page says it's several dvi plugs striped together, the 221 has linux drivers, even... just make sure you have enough DVI out ports to drive it? *shrug* |
| 13:42.49 | ``Erik | (204dpi, not bad at all... overkill, even... human discrepency is roughly 287 dpi at 1' distance, iphone4 is 324dpi, average monitor I believe is 72dpi...) |
| 14:26.27 | starseeker | nods - I'm thinking at 204ppi, I'd never need another monitor until it died for some reason :-) |
| 14:26.41 | starseeker | (or I couldn't connect it to modern hardware, I suppose...) |
| 14:27.21 | starseeker | had better not die, considering they don't make 'em anymore... grr |
| 14:28.21 | starseeker | basically the monitor equalivent to my Model M keyboard :-) |
| 14:29.16 | cvds_ | Model M that is a good keyboard |
| 14:30.13 | starseeker | still has and uses an original - probably will have to switch to one of the newer ones I got a while back because they're discontinuing the old-style connectors and this sucker draws too much power for a USB plug |
| 15:11.02 | *** join/#brlcad merzo (~merzo@42-90-132-95.pool.ukrtel.net) | |
| 17:05.54 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.176) | |
| 03:24.29 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.247) | |
| 05:00.19 | starseeker | bhinesley: iirc, you had the translate functions fully working in edit? |
| 05:00.35 | bhinesley | starseeker: correct |
| 05:00.58 | starseeker | how much was remaining for the rotation part? |
| 05:01.19 | bhinesley | I'd written the mock manual for it, but that's it |
| 05:01.25 | starseeker | nods |
| 05:02.10 | starseeker | that's a good start |
| 05:02.51 | starseeker | would be curious to hook up edit under MGED's mouse-based translation |
| 05:03.33 | starseeker | we have had bugs reported for a long time about the movement getting into a bizarre state under certain conditions, but not reproducibly |
| 05:03.53 | starseeker | wonder if using edit under the hood might avoid them |
| 05:06.43 | bhinesley | blows off dust |
| 05:06.57 | bhinesley | I should probably reevaluate this manual, now that translate is running |
| 05:07.13 | bhinesley | *rotate manual |
| 05:08.03 | bhinesley | it's been a while, and rotate is pretty complex |
| 05:13.21 | bhinesley | brlcad: Fall qtr ends in 3 weeks, and I'll have 6 weeks off before Winter. It would be a good time to consider any potential refactoring of edit.c, before I get going on rotate. |
| 07:14.40 | *** join/#brlcad OvaleZ (~OvaleZ@213.5.25.68) | |
| 07:17.11 | OvaleZ | Hello all! Help me please. I trying to compile latest release 7.20.4 of BRL-CAD on Windows 7 using mingw32 and cMake 2.8.6. This is correct way to compile under windows? now i have some error... What tools you are used to compile BRL-CAD for windows? Thx |
| 07:35.31 | *** join/#brlcad abhi2011 (~chatzilla@117.200.94.164) | |
| 07:40.01 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 08:57.34 | *** join/#brlcad abhi2011 (~chatzilla@117.200.89.171) | |
| 10:53.30 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 16:34.31 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 16:34.31 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 18:13.06 | CIA-109 | BRL-CAD: 03starseeker * r47444 10/brlcad/trunk/src/other/ (5 files in 5 dirs): Keep all the FindX11.cmake files consistent. |
| 18:34.53 | starseeker | hah, cool: http://www.scientificamerican.com/article.cfm?id=sticky-situation-gecko-toe-adhesive |
| 19:16.57 | *** join/#brlcad merzo (~merzo@214-221-132-95.pool.ukrtel.net) | |
| 20:40.29 | CIA-109 | BRL-CAD: 03n_reed * r47445 10/brlcad/trunk/src/other/re2c/parser.y.lemon: finished bison to lemon syntax converion |
| 22:05.53 | CIA-109 | BRL-CAD: 03n_reed * r47446 10/brlcad/trunk/src/other/re2c/parser.y.lemon: suppress errors by using precedence information to make default conflict resolution explicit |
| 23:04.31 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 03:14.20 | *** join/#brlcad abhi2011 (~chatzilla@117.200.85.212) | |
| 03:16.09 | abhi2011 | hmm getting a strange raytracing result : http://imageshack.us/photo/my-images/849/forceh.png/ |
| 03:16.30 | abhi2011 | overlaps being reported where objects do not appear to overlap at all |
| 03:16.57 | abhi2011 | some mistake in loading the objects into the raytracing instance |
| 04:12.09 | CIA-109 | BRL-CAD: 03abhi2011 * r47447 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simrt.c simrt.h simulate.c): |
| 04:12.09 | CIA-109 | BRL-CAD: Changed the location of raytrace initialization to the main simulate file in an |
| 04:12.09 | CIA-109 | BRL-CAD: attempt to eliminate as many function calls as possible and get to the bottom of |
| 04:12.09 | CIA-109 | BRL-CAD: why objects appear to be in a different location in the rt_i as compared to the |
| 04:12.09 | CIA-109 | BRL-CAD: one shown by mged. |
| 04:39.58 | *** join/#brlcad abhi2011 (~chatzilla@117.200.85.212) | |
| 04:42.09 | abhi2011 | hmm shooting the saem ray with nirt in mged gives no overlap where there are no overlaps shown visually |
| 05:35.28 | *** join/#brlcad abhi2011 (~chatzilla@117.200.91.67) | |
| 06:45.51 | *** join/#brlcad abhi2011 (~chatzilla@117.200.83.165) | |
| 07:19.22 | abhi2011 | hmm neither nirt in mged, or nirt running in the command line , on the same db file shows overlaps for a ray particular ray origination point and direction |
| 07:20.14 | abhi2011 | yet when I rt_gettree() the same regions into a new rt_i and shoot the same ray, an overlap gets reported |
| 07:26.42 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 07:47.31 | *** join/#brlcad abhi2011 (~chatzilla@117.200.83.246) | |
| 07:52.47 | CIA-109 | BRL-CAD: 03d_rossberg * r47448 10/brlcad/trunk/ (4 files in 3 dirs): |
| 08:23.24 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 08:24.14 | d_rossberg | nmg_copy.c doesn't compile with gcc yet, i should be able to fix it today ... |
| 09:05.06 | *** join/#brlcad abhi2011 (~chatzilla@117.200.93.18) | |
| 10:00.54 | *** join/#brlcad milamber (~devlin@d118-75-244-176.try.wideopenwest.com) | |
| 10:07.44 | CIA-109 | BRL-CAD: 03d_rossberg * r47449 10/brlcad/trunk/src/librt/primitives/nmg/nmg_copy.c: quell gcc warnings/errors: 1st iteration |
| 13:44.29 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 14:50.14 | *** join/#brlcad abhi2011 (~chatzilla@117.200.81.70) | |
| 15:50.32 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 15:51.10 | *** join/#brlcad abhi2011 (~chatzilla@117.200.88.16) | |
| 17:15.22 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 17:15.23 | *** join/#brlcad Technicus|2 (~Technicus@DSLPool-net208-2.wctc.net) | |
| 17:31.31 | *** join/#brlcad abhi2011 (~chatzilla@117.200.88.16) | |
| 18:36.26 | CIA-109 | BRL-CAD: 03indianlarry * r47450 10/brlcad/trunk/src/anim/anim_script.c: End condition for reading file buggered up, added count of needed fields for scanf() based on program options. |
| 18:36.59 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.170) | |
| 18:42.14 | CIA-109 | BRL-CAD: 03indianlarry * r47451 10/brlcad/trunk/src/tclscripts/mged/anim.tcl: CAD object not used when processing "view" script so don't test existence in "view" case. |
| 18:46.17 | *** join/#brlcad milamber (~devlin@d118-75-244-176.try.wideopenwest.com) | |
| 21:24.44 | CIA-109 | BRL-CAD: 03n_reed * r47452 10/brlcad/trunk/src/other/re2c/parser.y.lemon: type corrections and casting; yyparse calls lemon parser |
| 21:31.23 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 01:16.58 | starseeker | woo hoo! http://gitorious.org/boost/cmake/trees/cmake-1.47.0 |
| 01:17.04 | starseeker | does happy dance |
| 01:20.16 | starseeker | builds successfully too |
| 02:20.43 | starseeker | Idea: Could we put a CMakeified Boost into our svn repo and use svn:external to pull that as part of a checkout? Then people using a system Boost could just do svn co --ignore-externals and not have to pull Boost at all |
| 02:59.46 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.166) | |
| 03:03.28 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.166) | |
| 03:32.50 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 03:32.50 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 03:57.07 | abhi2011 | yippeee!!!, the sphere - sphere case also works :), wasnt unitizing the direction vector while shooting rays ! |
| 03:58.05 | abhi2011 | just cant seem to get out of the newbie group :P with rt |
| 04:01.43 | CIA-109 | BRL-CAD: 03abhi2011 * r47453 10/brlcad/trunk/src/libged/simulate/ (simrt.c simulate.c): Committing the code used to debug errors in generating manifolds using rt, in case I need to get back to it again quickly later. |
| 04:10.04 | CIA-109 | BRL-CAD: 03abhi2011 * r47454 10/brlcad/trunk/src/libged/simulate/ (simrt.c simulate.c): Now the proper working code with all debugging stuff removed. |
| 04:12.02 | abhi2011 | http://imageshack.us/photo/my-images/406/forceb.png/ |
| 04:15.51 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3232 10/wiki/User:Abhijit: /* Log */ |
| 04:37.13 | starseeker | abhi2011: any chance of making a video with the spheres? |
| 04:37.38 | abhi2011 | starseeker: yes I am working on that |
| 04:37.43 | starseeker | sweet! |
| 04:38.11 | abhi2011 | I need the spheres to overlap somewhat , to generate contact points and rt does some wierd colors when objects overlap |
| 04:38.48 | abhi2011 | but it should be ok for small velocites |
| 04:39.08 | starseeker | hmm. So it's not actually a "true" contact test but a "slightly intersecting" test? |
| 04:39.27 | abhi2011 | yes thats right |
| 04:39.50 | abhi2011 | because rt will create contact points based on the overlap area |
| 04:40.06 | abhi2011 | or rather to put it better |
| 04:40.42 | abhi2011 | I can create contact points using rt, only when they overlap |
| 04:41.20 | starseeker | would it be possible to use the intersecting rays to "back up" just to the point where the longest intersecting ray becomes zero, and proceed again from there using the information? |
| 04:41.22 | abhi2011 | as the rays report overlap regions |
| 04:42.30 | abhi2011 | by becoming zero you mean, there is no overlap region reported for the longest overlapping ray ? |
| 04:42.39 | starseeker | something like that |
| 04:42.44 | abhi2011 | *longest ray |
| 04:42.46 | abhi2011 | ok |
| 04:42.50 | starseeker | just a thought |
| 04:42.56 | abhi2011 | yes I think it should be possible |
| 04:43.14 | starseeker | basically the idea would be to not have to solid things "merge slightly" when interacting... |
| 04:43.26 | abhi2011 | yes, I was also thinking that if 2 objects are very close to each other |
| 04:43.27 | starseeker | but I don't know if that's compatible with the approach - just a random thought |
| 04:43.35 | abhi2011 | then the air gap will be very small too |
| 04:43.46 | abhi2011 | so if I shoot rays in their overlap region |
| 04:43.57 | abhi2011 | and check for the smallest air gap |
| 04:44.18 | abhi2011 | then at a certain points ...say 0.04 mm, I could generate the points |
| 04:44.44 | abhi2011 | then the objects have not yet physically intersected as there is still small air gap between them |
| 04:44.49 | starseeker | nods |
| 04:45.27 | starseeker | may not need to ensure an air gap even - just stray thoughts |
| 04:45.31 | starseeker | you're the expert :-) |
| 04:45.44 | abhi2011 | currently I seem to have an issue with 2 objects penetrating too much into each other, if alowed to do so, when they have high relative velocities |
| 04:46.01 | abhi2011 | hehe, yep all ideas help :) |
| 04:46.19 | starseeker | well, it is "bullet" ;-) |
| 04:46.30 | abhi2011 | hehe yeah |
| 04:47.06 | abhi2011 | ok I ll make 2 vids, one with a sphere dropped from a low altitude |
| 04:47.15 | abhi2011 | and an another from a high one |
| 04:47.18 | abhi2011 | and see what happens |
| 04:47.22 | starseeker | sweet |
| 04:47.34 | starseeker | still fantastic progress |
| 04:47.42 | abhi2011 | thanks :) |
| 04:47.59 | abhi2011 | cant wait to try the billiard table case with custom forces :P |
| 04:48.04 | starseeker | who knows - brlcad might even think up some scenarios where overlapping would be useful |
| 04:48.08 | starseeker | hehe :-) |
| 04:48.22 | starseeker | "BRL-CAD - now, with pool simulations!" |
| 04:48.48 | abhi2011 | :) |
| 04:49.02 | abhi2011 | so , there is this powerful server everyone keeps talking about |
| 04:49.09 | abhi2011 | bullet is not installed there ? |
| 04:49.14 | starseeker | um |
| 04:49.16 | starseeker | dunno |
| 04:49.25 | starseeker | ``Erik: we have a powerful server? |
| 05:19.27 | *** join/#brlcad abhi2011 (~chatzilla@117.200.82.100) | |
| 06:05.19 | *** join/#brlcad abhi2011 (75c85d7f@gateway/web/freenode/ip.117.200.93.127) | |
| 07:38.43 | *** join/#brlcad abhi2011 (~chatzilla@117.200.89.207) | |
| 07:41.18 | abhi2011 | http://www.youtube.com/watch?v=nrOtSd07rCY |
| 07:41.25 | abhi2011 | this is with slow striking spheres |
| 07:42.33 | abhi2011 | the reaction force from the sphere at the bottom is straight upwards, opposite to the velocity of the upper sphere |
| 07:42.55 | abhi2011 | yet , it does not seem correct as the reaction should be at 45 degrees to the vertical |
| 07:43.22 | abhi2011 | so I ll try with the summing normals at the overlapping region approach and check if that gives better results |
| 07:44.49 | abhi2011 | for fast moving sphere , this more of an issue, as a fast sphere suddenly penetrates deep into the lower sphere : http://www.youtube.com/watch?v=7cZesIJapF4 |
| 07:45.10 | abhi2011 | causing a sudden high reaction force |
| 07:45.22 | abhi2011 | which does not seem correct either |
| 07:45.33 | abhi2011 | will try and figure out a solution |
| 07:49.57 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 07:50.03 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3233 10/wiki/User:Abhijit: /* Log */ |
| 07:50.47 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3234 10/wiki/User:Abhijit: /* Log */ |
| 07:51.29 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3235 10/wiki/User:Abhijit: /* Log */ |
| 08:46.50 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3236 10/wiki/User:Abhijit: /* Log Nov 9th */ |
| 08:50.21 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3237 10/wiki/User:Abhijit: /* Updated Development Time line(Oct 6th) */ |
| 08:50.50 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3238 10/wiki/User:Abhijit: /* Updated Development Time line(Nov 9th) */ |
| 08:57.04 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3239 10/wiki/User:Abhijit: /* Log */ |
| 09:02.09 | CIA-109 | BRL-CAD: 03abhi2011 * r47455 10/brlcad/trunk/src/libged/simulate/ (simrt.c simulate.c): Switched to summing of normals approach to generate contact pairs. Added a #define to switch back to velocity based generation quickly if needed. |
| 09:15.07 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3240 10/wiki/User:Abhijit: /* Log */ |
| 09:54.30 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.178) | |
| 12:10.47 | ``Erik | starseeker: he might be referring to the new gcc compile farm machine that brlcad was playing on? I think it's 64 power7 cores? |
| 12:12.09 | ``Erik | http://gcc.gnu.org/wiki/CompileFarm gcc110... 64 power7 cores at 3.55ghz, 64g ram, fedora ppc64 |
| 12:13.55 | ``Erik | I see brlcad logged into it right now, and the load is 0... altivec capable, even |
| 12:16.11 | ``Erik | would guess a hair over half a million VGR's |
| 12:17.36 | ``Erik | we also have the cat machines, those're 16 xeon cores a whack, not exactly chump change |
| 12:23.11 | ``Erik | hm, abhi isn't here |
| 12:34.40 | ``Erik | ffs, this email is going to be a book. |
| 13:54.36 | *** join/#brlcad abhi2011 (~chatzilla@117.200.87.72) | |
| 13:58.44 | abhi2011 | ``Erik: Thanks for the mail :) |
| 13:58.57 | abhi2011 | very insightful |
| 13:59.14 | abhi2011 | trying to digest all the info now |
| 14:02.35 | starseeker | abhi2011: nifty video! |
| 14:03.01 | abhi2011 | hehe, I ll try n pop in a few more stuff |
| 14:03.04 | starseeker | agree it's not quite right, but still nice progress! |
| 14:05.12 | abhi2011 | hmm, so the basic idea now is to do zero penetration physics |
| 14:05.19 | abhi2011 | or to recover from penetration |
| 14:08.32 | abhi2011 | hehe, agree on the "fairly gross simplifications of geometry" part player characters :P |
| 14:08.35 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 14:08.54 | abhi2011 | I think bullet uses just a capsule shape for a player, rotating it or making it jump as needed |
| 14:08.55 | ``Erik | :D most of my background comes from old (quake2 era) video games, so take it with a fat grain of salt |
| 14:09.37 | abhi2011 | :), yeah me have never done it, so any info is useful |
| 14:09.39 | ``Erik | back when I was doing it, the 'hot' thing was to have the entire character represented by a stretched sphere |
| 14:09.47 | abhi2011 | ok |
| 14:10.35 | ``Erik | the capsule supposedly better represents *shrug* |
| 14:10.48 | ``Erik | I tried to cc brlcad and starseeker, not sure if they got 'em |
| 14:11.13 | ``Erik | I think brlcad won't be back until next week, maybe :/ |
| 14:11.13 | abhi2011 | ok, hmm, yes, for large time delta, bullet breaks up the update into smaller internal sub steps |
| 14:11.20 | abhi2011 | oh ok |
| 14:12.15 | abhi2011 | was thinking about the " extending the boundary of an object slightly" idea though |
| 14:12.26 | abhi2011 | I think bullet does it with the basic shapes it uses |
| 14:12.41 | abhi2011 | but I guess trying that approach for brl-cad shapes would be tough |
| 14:13.31 | ``Erik | BRL-CAD provides both a bounding sphere and aabb for each primitive, both are easy to extend |
| 14:13.32 | abhi2011 | 'cause the entire periphery of an object would need to be detected and extended |
| 14:14.09 | abhi2011 | ok |
| 14:14.50 | abhi2011 | so a ray shot though the primitive, would give the exit point a little but further along than , it would , without extension |
| 14:15.01 | abhi2011 | and the entry point a little bit earlier |
| 14:15.19 | ``Erik | oh, and http://brlcad.svn.sourceforge.net/viewvc/brlcad/rtcmp/trunk/rt/rt.c?revision=34030 is about as simple as you're going to get for ray-tracing in BRL-CAD, the 'hit' function is more complex than you need, but the rest should be minimal |
| 14:16.05 | abhi2011 | ok |
| 14:20.22 | abhi2011 | ``Erik: so by "solve the impulse vector", you mean calculating the reaction force from the collision , by using change in momentum etc ? |
| 14:29.12 | ``Erik | yeh, though thinking, the resultant velocity vector is what you actually want in the end, not just the delta *shrug* |
| 14:37.56 | abhi2011 | well yes |
| 14:38.25 | abhi2011 | actually I let Bullet calculate the resultant velocity :) |
| 14:38.32 | abhi2011 | I just give it a resultant normal |
| 14:38.38 | abhi2011 | pointing from object A to B |
| 14:48.36 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 14:54.23 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:20.32 | CIA-109 | BRL-CAD: 03bob1961 * r47456 10/brlcad/trunk/src/other/clipper/ (clipper.cpp clipper.hpp): Updates from Angus. |
| 17:37.24 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.182) | |
| 17:37.39 | CIA-109 | BRL-CAD: 03bob1961 * r47457 10/brlcad/trunk/src/tclscripts/mged/skt_ed.tcl: Update calls to dist and find_arc_center to reflect the fact that they are no longer in the Sketch_editor namespace. |
| 18:32.43 | CIA-109 | BRL-CAD: 03starseeker * r47458 10/brlcad/trunk/src/conv/g-obj.c: Faces were all using the same value due to variable i not being changed in the loop... report from Christopher Pitts, bug tracker #3435642 |
| 19:13.47 | CIA-109 | BRL-CAD: 03bob1961 * r47459 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Added a method for "l". The "g" command will now expand it's argument list. |
| 19:22.12 | *** join/#brlcad merzo (~merzo@91-101-133-95.pool.ukrtel.net) | |
| 21:43.15 | ``Erik | nice. http://technet.microsoft.com/en-us/security/bulletin/ms11-083 |
| 21:43.41 | ``Erik | possible remote code execution by dumping udp packets at a target machine. |
| 22:17.59 | CIA-109 | BRL-CAD: 03n_reed * r47460 10/brlcad/trunk/doc/bison_to_lemon.txt: minor update on aliases |
| 22:53.06 | CIA-109 | BRL-CAD: 03n_reed * r47461 10/brlcad/trunk/src/other/step/CMake/FindLEMON.cmake: add modified lemon_target macro |
| 22:58.52 | CIA-109 | BRL-CAD: 03n_reed * r47462 10/brlcad/trunk/src/ (2 files in 2 dirs): modified CMakeLists for alt lemon macro |
| 23:41.34 | CIA-109 | BRL-CAD: 03starseeker * r47463 10/brlcad/trunk/ (4 files in 4 dirs): Get the FindLEMON logic working with the new paradigm (specifying the target header file) |
| 23:53.11 | CIA-109 | BRL-CAD: 03n_reed * r47464 10/brlcad/trunk/src/other/re2c/ (6 files in 2 dirs): switched re2c yacc parser with lemon parser |
| 23:58.07 | CIA-109 | BRL-CAD: 03n_reed * r47465 10/brlcad/trunk/src/other/step/ (CMake/FindYACC.cmake CMakeLists.txt): FindYACC no longer used; removed |
| 00:17.04 | CIA-109 | BRL-CAD: 03starseeker * r47466 10/brlcad/trunk/src/other/re2c/CMakeLists.txt: need the lemon bootstrap before doing the re2c bootstrap |
| 00:25.31 | CIA-109 | BRL-CAD: 03starseeker * r47467 10/brlcad/trunk/src/other/re2c/ (CMakeLists.txt parser.yy): Couple more tweaks - re2c builds now |
| 00:30.18 | starseeker | woo hoo! |
| 00:36.22 | CIA-109 | BRL-CAD: 03starseeker * r47468 10/brlcad/trunk/src/other/step/src/express/CMakeLists.txt: quiet messages for now |
| 00:46.37 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 00:59.08 | CIA-109 | BRL-CAD: 03n_reed * r47469 10/brlcad/trunk/src/other/ (5 files in 3 dirs): remove old re2c bison sources |
| 00:59.12 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 01:09.47 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 09:49.37 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 12:47.18 | *** join/#brlcad abhi2011 (~chatzilla@117.200.93.61) | |
| 15:32.11 | *** join/#brlcad abhi2011 (~chatzilla@117.200.89.240) | |
| 15:34.37 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 16:13.10 | CIA-109 | BRL-CAD: 03n_reed * r47470 10/brlcad/trunk/misc/CMake/FindLEMON.cmake: updated example usage comment |
| 16:23.11 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 16:25.45 | d_rossberg | i just saw a strange effect in version 7.20.4: the ray-trace doesn't return the regions but the solids for V4 databases |
| 16:26.23 | d_rossberg | both in windows and linux |
| 17:04.47 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 17:58.56 | CIA-109 | BRL-CAD: 03starseeker * r47471 10/geomcore/trunk/src/GS/testclient/gstestclient.c: Put in the definitions for ntohll and htonll. |
| 20:41.55 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 20:50.49 | CIA-109 | BRL-CAD: 03starseeker * r47472 10/brlcad/trunk/src/other/CMakeLists.txt: handle lemon before re2c, since re2c is using lemon now |
| 23:49.27 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 00:08.04 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 00:27.15 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 00:48.52 | *** join/#brlcad abhi2011 (~chatzilla@117.200.82.161) | |
| 02:28.36 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.82.161) | |
| 03:25.15 | *** join/#brlcad abhi2011 (~chatzilla@117.200.86.46) | |
| 04:44.29 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.242) | |
| 05:46.37 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 06:20.42 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 07:16.17 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 07:28.39 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 07:42.04 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 11:54.31 | CIA-109 | BRL-CAD: 03d_rossberg * r47473 10/brlcad/trunk/src/librt/dir.c: |
| 11:54.31 | CIA-109 | BRL-CAD: removed a bug (at least) in versions 7.20.2 and 7.20.4 which prevents the detection of V4 database's regions in ray-trace |
| 11:54.31 | CIA-109 | BRL-CAD: this is more a work-around than a real bug-fix, I couldn't find the place where the detection was changed from region-flag to -attribute |
| 12:25.14 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 14:48.39 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 16:20.15 | CIA-109 | BRL-CAD: 03HarveyTodd 07http://brlcad.org * r3241 10/wiki/Main_Page: /* BRL-CAD Wiki */ |
| 17:45.11 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r3242 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/HarveyTodd|HarveyTodd]] ([[User talk:HarveyTodd|Talk]]); changed back to last version by [[User:Sean|Sean]] |
| 17:45.38 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:HarveyTodd]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 20:27.48 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 21:00.02 | *** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 21:24.07 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 01:31.46 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 02:43.31 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 05:52.32 | *** join/#brlcad abhi2011 (~chatzilla@117.200.82.200) | |
| 08:28.56 | *** join/#brlcad abhi2011 (~chatzilla@117.200.90.209) | |
| 11:49.52 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 12:18.36 | *** join/#brlcad abhi2011 (~chatzilla@117.200.82.48) | |
| 15:23.27 | *** join/#brlcad abhi2011 (~chatzilla@117.200.86.154) | |
| 16:19.42 | *** join/#brlcad abhi2011 (~chatzilla@117.200.86.235) | |
| 18:18.23 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.138.104) | |
| 18:40.29 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 18:42.48 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.139.145) | |
| 18:56.08 | *** join/#brlcad Forth (~Forth@92.242.118.253) | |
| 19:25.11 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.130.219) | |
| 19:31.24 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 19:32.42 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.131.0) | |
| 19:44.08 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 19:45.26 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 01:55.53 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1128565288.dsl.bell.ca) | |
| 01:56.44 | IriX64 | http://pastebin.ca/2094069 |
| 01:57.05 | IriX64 | a cmake attempt |
| 01:57.46 | IriX64 | ciao |
| 03:07.47 | starseeker | that looks like an incomplete checkout, if it's from svn |
| 03:07.59 | starseeker | no version info... |
| 03:35.02 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 04:24.24 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 04:28.13 | starseeker | O.o http://gizmodo.com/5351348/amazon-kindle-2-hacked-to-run-linux |
| 04:55.16 | louipc | the INSTALL.cmake file isn't up to date is it? |
| 04:55.27 | starseeker | probably not |
| 04:55.45 | starseeker | don't know if I fixed it after the latest Big Rework |
| 04:56.08 | starseeker | louipc: any specific troubles? |
| 04:56.15 | louipc | under configuration options seems like it's not using cmake |
| 04:56.50 | starseeker | ah, right - it's not done yet in that sense |
| 04:59.16 | louipc | starseeker: yeah was just wondering how to disable strict with cmake |
| 04:59.25 | starseeker | ah |
| 04:59.32 | starseeker | one sec |
| 04:59.51 | starseeker | -DBRLCAD-ENABLE_STRICT=OFF |
| 05:00.32 | starseeker | although I'm sure i'd be interesting to know what's failing for strict |
| 05:01.52 | louipc | I'll get back to you on that |
| 05:08.19 | CIA-109 | BRL-CAD: 03starseeker * r47474 10/brlcad/trunk/INSTALL.cmake: Change a few of the now wildly incorrect sections of INSTALL.cmake - more work to do here, if the current setup is in fact the final configuration. |
| 05:13.14 | starseeker | er s/i'd/we'd ;-) |
| 05:19.17 | CIA-109 | BRL-CAD: 03starseeker * r47475 10/brlcad/trunk/src/libged/simulate/simrt.c: remove unused var |
| 05:19.26 | starseeker | louipc: that help? |
| 06:20.02 | louipc | starseeker: yeah a bit less confusing thanks |
| 06:20.41 | louipc | starseeker: here's where it failed - http://louipc.mine.nu/brlcad/builderr20111113 |
| 06:27.15 | starseeker | O.o |
| 07:08.37 | *** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl) | |
| 10:50.40 | *** join/#brlcad b0ef (~b0ef@78.58.34.95.customer.cdi.no) | |
| 13:09.41 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 13:28.59 | *** join/#brlcad milamber (~devlin@d118-75-244-176.try.wideopenwest.com) | |
| 13:28.59 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 13:28.59 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 13:29.00 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 13:29.00 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 13:29.00 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 13:29.00 | *** join/#brlcad CIA-109 (~CIA@cia.atheme.org) | |
| 13:29.00 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 13:29.00 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 13:29.00 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-52-241-103.dsl.bkfd14.sbcglobal.net) | |
| 13:29.00 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 13:29.00 | *** mode/#brlcad [+o ChanServ] by wolfe.freenode.net | |
| 13:30.15 | *** join/#brlcad b0ef (~b0ef@78.58.34.95.customer.cdi.no) | |
| 13:30.15 | *** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl) | |
| 13:30.15 | *** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 13:30.15 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 13:30.15 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 13:30.15 | *** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 13:30.15 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 13:30.15 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 13:30.48 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 13:45.33 | *** join/#brlcad bhinesley (~bhinesley@99.52.241.103) | |
| 13:45.51 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 13:45.51 | *** join/#brlcad CIA-109 (~CIA@cia.atheme.org) | |
| 13:48.05 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 13:48.05 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 13:48.05 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 13:48.05 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 13:48.05 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 13:48.05 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 13:48.05 | *** join/#brlcad milamber (~devlin@d118-75-244-176.try.wideopenwest.com) | |
| 14:27.19 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 15:39.19 | *** join/#brlcad piksi (~piksi@pi-xi.net) | |
| 15:45.11 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 16:40.44 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 17:46.34 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 18:03.19 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 18:24.09 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 20:42.44 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 23:09.45 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 23:18.25 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 23:38.56 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 23:39.55 | *** join/#brlcad Technicus|2 (~Technicus@DSLPool-net208-2.wctc.net) | |
| 01:05.27 | *** join/#brlcad FrantiK (~FrantiK@unaffiliated/frantik) | |
| 02:38.40 | *** part/#brlcad FrantiK (~FrantiK@unaffiliated/frantik) | |
| 03:22.22 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 07:51.51 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 08:05.52 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 08:41.01 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) | |
| 12:04.16 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 12:25.58 | CIA-109 | BRL-CAD: 03d_rossberg * r47476 10/brlcad/trunk/src/librt/primitives/nmg/nmg_copy.c: the mate's parent was the parent's mate |
| 12:42.46 | CIA-109 | BRL-CAD: 03d_rossberg * r47477 10/rt^3/trunk/ (5 files in 2 dirs): torso of a C++ class interface to BRL-CAD's non-manifold geometry element |
| 12:45.49 | CIA-109 | BRL-CAD: 03d_rossberg * r47478 10/brlcad/trunk/misc/win32-msvc/Dll/CMakeLists.txt: included NonManifoldGeometry in the brlcad.dll build |
| 13:10.01 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 14:08.14 | *** join/#brlcad abhi2011 (~chatzilla@117.200.90.157) | |
| 14:52.40 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 17:23.54 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 18:08.31 | brlcad | waves |
| 18:11.04 | brlcad | bhinesley: duly noted, awesome (delayed response) |
| 18:12.08 | ``Erik | brlcad: did you have something for indianlarry? |
| 18:29.15 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 19:30.14 | brlcad | sent |
| 19:41.07 | brlcad | louipc: that's pretty impressive |
| 19:42.17 | brlcad | those warnings are actually errors -- it's overrunning an array |
| 19:43.18 | brlcad | impressive that it figured out that a double[2] was passed to function as a double* then to another function as a double* and then dereferenced as a double[3] ... |
| 19:43.34 | brlcad | louipc: what compiler version and OS was that? |
| 19:54.18 | *** join/#brlcad merzo (~merzo@194-214-132-95.pool.ukrtel.net) | |
| 21:13.03 | louipc | brlcad: gcc 4.6.2, arch linux |
| 21:13.59 | louipc | it's a multilib build of gcc, so I can build 32 bit binaries on my 64bit system if needed |
| 21:14.13 | louipc | not sure if that's significant |
| 21:53.56 | starseeker | Oooo: http://www.techworld.com.au/article/407302/amd_16-core_opteron_chips_arrive_after_wait |
| 21:57.46 | starseeker | ah, phooey - not full fledged cores |
| 22:22.38 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 23:21.05 | *** join/#brlcad jarray52 (~bigbear@unaffiliated/jarray52) | |
| 23:23.37 | jarray52 | Is BRL-CAD a good tool for CAD/CAE/CAM work on something like a DIY motorcycle, snow blower, or diesel generator? |
| 23:59.55 | louipc | jarray52: ok for cad, if you have pro/e you can exchange data I think (but have to compile the extension and need a license), no CAM features |
| 00:05.45 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 01:08.54 | jarray52 | louipc: What would be the primary limitations of using brl-cad for designing something like a car, motorcycle, diesel generator, or satellite? |
| 01:10.56 | jarray52 | And the primary advantages over AutoCad or solidworks? |
| 01:59.46 | starseeker | makes a note to read this in more detail: http://www.linuxjournal.com/article/3687 |
| 02:02.42 | louipc | jarray52: brl-cad has no dimensioning feature, or 2d drafting ability, no step export, and step import is still in development |
| 02:05.41 | louipc | jarray52: one of brl-cad's main purposes was for ballistics analysis for the military, so it doesn't have the regular CAD stuff you usually expect |
| 02:08.42 | louipc | jarray52: not even a shaded view for solids in editing.. you have to explicitly render the view |
| 02:09.32 | jarray52 | What are its primary advantages? |
| 02:10.34 | louipc | seems more geared for making 'true' solids |
| 02:10.36 | jarray52 | over something like solidworks |
| 02:10.40 | jarray52 | or autocad |
| 02:10.43 | jarray52 | other than cost |
| 02:11.04 | louipc | it's not really in the same realm at the moment |
| 02:11.17 | louipc | or ever? dunno |
| 02:12.29 | louipc | depends on what you want to do I guess |
| 02:12.37 | jarray52 | in quality or purpose? |
| 02:12.45 | louipc | purpose |
| 02:13.01 | jarray52 | it can export .dxf |
| 02:13.25 | louipc | think so |
| 02:54.54 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.13) | |
| 03:23.19 | *** join/#brlcad abhi2011 (~chatzilla@117.200.86.180) | |
| 03:38.20 | brlcad | jarray52: the primary limitation is usability -- like any cad system, there's a significant learning curve |
| 03:38.30 | brlcad | and ours is particularly steep |
| 03:40.39 | brlcad | jarray52: BRL-CAD's strength is for assisting with a variety of engineering analysis work, generally niche fields that have varied/unpredicatble requirements |
| 03:42.41 | jarray52 | brlcad: After getting past the learning curve, is the system nicely useable? |
| 03:42.53 | brlcad | for basic design/modeling, BRL-CAD is good once you get up the learning curve but it is a different command-line driven approach that usually favors people with scripting skills |
| 03:43.21 | brlcad | it's usable, been used for production analysis work in the DoD for several decades |
| 03:43.29 | jarray52 | I'm a python/c++ programmer with little CAD experience. So, I really like the idea of scripting oriented CAD. |
| 03:43.54 | brlcad | but make no mistake, that learning curve is steep -- brl-cad is huge with lots of features and lots of ways to get tasks done ;) |
| 03:44.02 | jarray52 | Is the engineering analysis work limited to ballistics/electromagnetics. |
| 03:44.06 | jarray52 | ? |
| 03:44.36 | jarray52 | brlcad: Is the learning curve steeper than learning a programming language like C++ for the first time? |
| 03:44.45 | brlcad | not really, and we don't even include that analysis logic directly within BRL-CAD -- hooks are provided to the analysis codes |
| 03:44.58 | brlcad | oh heavens no |
| 03:45.15 | jarray52 | what about learning python for the first time? |
| 03:46.03 | brlcad | the biggest issue is probably that it's not a discoverable system, you'll only learn by going through tutorials (for which there are EXTENSIVE tutorials across a range of topics), reading man pages, and modeling, modeling, modeling |
| 03:46.41 | brlcad | I don't think so, but that's a bit of a skewed question to ask... |
| 03:46.59 | jarray52 | Once mastered, does it have lots of features not found in programs like autocad, catia, and pro engineer? |
| 03:47.11 | brlcad | is it harder to learn being a professional woodworker or a professional mechanic? |
| 03:47.24 | jarray52 | sorry... |
| 03:47.27 | brlcad | they both can take decades to master ;) |
| 03:47.40 | jarray52 | the questions were misguided... |
| 03:47.57 | brlcad | it's fine, just don't want you to have unrealistic expectations |
| 03:48.27 | brlcad | there are some features BRL-CAD provides that are arguably better or more powerful than features in commercial CAD systems |
| 03:48.38 | jarray52 | such as? |
| 03:49.15 | brlcad | we are one of the very best at loading superbly complex models with minimal memory and processing, and still being able to render/analyse those models more quickly than anyone else |
| 03:49.51 | brlcad | notorious for being able to open models that bring Pro/E, NX, and others to their knees on a powerful workstation |
| 03:50.24 | brlcad | our other flexibility is in the breadth of flexibility, lots and lots of tools that you can chain together to get a job done |
| 03:51.47 | jarray52 | Just so I understand... this type of thing could for example be used to model an aircraft carrier with planes taking off and landing or a space station with multiple space vehicles docking, leaving, and so on. |
| 03:52.27 | jarray52 | Is that the type of specialized thing that brlcad would do well? |
| 03:52.28 | brlcad | if we were an operating system code, we'd be more like bsd userland tools and a bsd microkernel -- not the pretty shiny layer on top ala osx or the facades of gnome/gtk, windows, etc |
| 03:52.53 | starseeker | Our graphical interactions are very primitive by modern standards |
| 03:52.54 | jarray52 | microkernel? |
| 03:53.47 | starseeker | jarray52: more like using a (relatively) small amount of information to represent complex geometry - that's a specialty |
| 03:53.48 | jarray52 | Would this be a good tool to design and model a diesel or car engine? |
| 03:54.12 | jarray52 | with internal moving parts and all... |
| 03:54.22 | brlcad | jarray52: nevermind the microkernel analogy if it's unfamiliar, the linux kernel works as an analogy too -- we're (presently) more of a kernel, not an easy-to-use distribution like ubuntu or fedora |
| 03:54.22 | starseeker | we don't currently simlulate part interactions |
| 03:54.43 | brlcad | jarray52: you can model just about anything -- it's what you do with the model once you're done |
| 03:54.45 | starseeker | (some nifty work going on to integrate bullet, but that's in the experimental stages) |
| 03:55.12 | brlcad | so yeah, you could model up an entire aircraft carrier down to every nut bolt and wire, no problem |
| 03:55.15 | starseeker | jarray52: if you're going to create a model in BRL-CAD, you'll need to use constructive solid geometry |
| 03:55.20 | brlcad | generate renderings and visualizations, no problem |
| 03:56.02 | brlcad | but then if you want blueprints -- we can provide the hidden line blueprint-style image, but not with dimensions or labels annotated |
| 03:56.33 | brlcad | or if you want an animation, no problem .. but we don't (yet) provide physics simulations with contact constraints |
| 03:57.16 | jarray52 | starseeker: I don't understand what you mean by "we don't currently simulate part interactions". |
| 03:57.25 | brlcad | jarray52: take a look at the introduction to mged tutorial and scripting tutorial on the website, they'll give you a good idea of some things possible (along with the image gallery) |
| 03:57.29 | jarray52 | in light of the other comments made by yourself and brlcad. |
| 03:57.46 | starseeker | jarray52: if you model two gears and try to have one turn the other, for example |
| 03:58.00 | starseeker | we don't do that right now |
| 03:58.18 | brlcad | jarray52: http://brlcad.org/wiki/Documentation <-- #2 |
| 03:58.34 | brlcad | and http://brlcad.org/wiki/SGI_Cube for a very brief scripting example |
| 03:59.12 | jarray52 | starseeker: Does any cad program allow one gear to turn another? |
| 03:59.30 | brlcad | yeah, the big five all have that ability |
| 04:00.02 | jarray52 | brlcad: big five=CATIA, Pro/Engineer, NX, AutoCAD, xxx? |
| 04:00.09 | brlcad | you have to specify a lot of crap to make it happen automagically, but it's "possible" |
| 04:00.13 | brlcad | solidworks |
| 04:00.18 | jarray52 | right |
| 04:00.56 | brlcad | technically, it's sorta possible in brl-cad, but that's functionality that was last used more than 10 years ago |
| 04:01.17 | brlcad | we have someone working on a new system now, way way cooler and easier to use .. but just getting started :) |
| 04:01.53 | jarray52 | brlcad: So, the user has to specify the motion for animations along with contact constraints, but it is possible, right? |
| 04:03.06 | brlcad | jarray52: this may be more familiar with your python background .. it's a perl modeling example, but could do almost exactly the same with python: http://brlcad.org/wiki/Spiral |
| 04:03.49 | brlcad | jarray52: well like I said -- it's a new system and I wouldn't recommend trying to use the old system unless you're willing to help debug |
| 04:04.31 | brlcad | until then, you basically have to manually put geometry where you want it, motion is just basic model transformations |
| 04:05.06 | brlcad | ala claymation, just not quite as tedious |
| 04:05.21 | brlcad | (because you can script it all) |
| 04:05.58 | jarray52 | brlcad: That's actually very cool because an external program could be doing calculations and transformations and moving the parts. |
| 04:06.05 | brlcad | louipc: ah, interesting, I'd tried .1 and it found some new issues .. .2 finds more .. someone must be actively boosting up those detection abilities |
| 04:06.41 | brlcad | jarray52: that's actually the intent (and you can see how we start to "fit in" with external analysis codes) |
| 04:07.59 | jarray52 | brlcad: And, once the model and external analysis code work the way they are intended to work(in theory at least), the parts can be exported to .dxf and manufactured. |
| 04:08.55 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 04:09.28 | jarray52 | brlcad: I think you have me sold on BRL-CAD now. |
| 04:10.09 | starseeker | jarray52: the thing that will probably feel strangest about BRL-CAD in its current form is the lack of 3D shaded displays - we visualize only with wireframes or raytracing now, unless you happen to have a triangle based model |
| 04:10.53 | jarray52 | Raytracing with wireframes only? |
| 04:11.05 | starseeker | no, interactive display with wireframe only |
| 04:11.13 | starseeker | raytrace is when it gets pretty :-) |
| 04:11.23 | brlcad | interactive as in grab the mouse and spin the model around -- wireframe only |
| 04:11.34 | brlcad | hit the render button, though, and you get your pretty shaded picture |
| 04:12.04 | jarray52 | brlcad: That's acceptable. |
| 04:12.33 | jarray52 | brlcad: At the end of the day, one can sell the pretty picture to a boss or investors. |
| 04:12.39 | jarray52 | :) |
| 04:12.41 | brlcad | nods :) |
| 04:12.52 | brlcad | you've seen the gallery yes? |
| 04:12.58 | jarray52 | brlcad: Yes. |
| 04:13.06 | jarray52 | brlcad: And read through some of the manuals. |
| 04:13.19 | brlcad | so that's a pretty wide range of different types of projects and different ability levels |
| 04:13.21 | jarray52 | brlcad: I'm a CAD/CAE/CAM newbie. |
| 04:13.27 | jarray52 | brlcad: Yes. |
| 04:13.33 | brlcad | all the better, less to unlearn :) |
| 04:14.20 | starseeker | folks expecting a Blender-like GUI are in for a shock, but there's a lot of power under the hood |
| 04:14.56 | jarray52 | starseeker: I prefer scripted model development. |
| 04:15.07 | starseeker | longer term we're planning to get there, but there's a *lot* of foundational work that has to come before the pretty interactive 3d |
| 04:15.10 | starseeker | :-) |
| 04:15.18 | starseeker | jarray52: then you're in the right place :-) |
| 04:15.38 | jarray52 | In theory, scripted development should be faster, right? |
| 04:15.55 | starseeker | for some classes of problems, absolutely |
| 04:15.59 | jarray52 | probably depends on the designer. |
| 04:16.10 | jarray52 | starseeker: Yes. Most definitely. |
| 04:16.13 | brlcad | very much so |
| 04:16.18 | starseeker | if you have data you can feed the script, that's where scripting shines |
| 04:16.31 | brlcad | if the designer doesn't know how to write a script, that's a pretty huge hurdle ;) |
| 04:16.37 | starseeker | jarray52: if you really want to go to town, there are C apis for model generation |
| 04:17.05 | brlcad | jarray52: a case study example that may be of interest: http://brlcad.org/wiki/Ronja |
| 04:17.06 | starseeker | that's what the tire tools does, for example - tire dimensions in, tire geometry out. |
| 04:17.10 | starseeker | procedural modeling |
| 04:18.04 | brlcad | jarray52: that's an individual that learned to model in less than a day, spent maybe a week modeling his design, then another week writing scripts to generate various images and animations: http://ronja.twibright.com/3d/ |
| 04:19.15 | brlcad | not the best example of good modeling practices in his models, but a decent showcase of what is possible within just a few days time |
| 04:19.40 | starseeker | oh, this one is kinda fun for "what's possible" http://more.brlcad.org/model/basic-impeller |
| 04:20.13 | brlcad | that'd be a fun one to feed to an arylic printer |
| 04:20.27 | starseeker | reflects we really should get that default GPL license label off the more.brlcad.org listings... |
| 04:21.45 | jarray52 | brlcad: BRL-CAD would probably be a good tool for modelling a network of telephone or power transmission lines including the powerplant, right? |
| 04:21.59 | brlcad | sure |
| 04:22.17 | brlcad | starseeker: you going to close out and document sf bug #3435642 ? |
| 04:22.22 | brlcad | the obj export bug |
| 04:22.23 | starseeker | fun with the pipe primitive :-) |
| 04:22.33 | starseeker | brlcad: oh, right - he confirmed the fix, didn't he |
| 04:22.36 | jarray52 | brlcad: This would be the type of design for which BRL-CAD shines, right? |
| 04:23.50 | brlcad | yeah, there are only a few types of models that BRL-CAD is ill-suited for direct modeling (import is fine though) |
| 04:25.28 | brlcad | namely: soft bodies (e.g., human skin) and highly curved surfaces (e.g., some modern car bodies) |
| 04:26.47 | brlcad | objects that can be broken down into constituent primitives shapes can be directly modeled much easier |
| 04:27.17 | louipc | brlcad: http://louipc.mine.nu/brlcad/brlcad-7.20.4-1-x86_64-build.log |
| 04:27.39 | louipc | that's a full build log with my version of gcc if that interests you |
| 04:27.52 | louipc | strict=off |
| 04:31.45 | CIA-109 | BRL-CAD: 03brlcad * r47479 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: |
| 04:31.46 | CIA-109 | BRL-CAD: attempt a fix for a variety of gcc 4.6.2 strict compilation failures reported by |
| 04:31.46 | CIA-109 | BRL-CAD: louipc (irc). compiler was clever enough to figure out that 2d-arrays were |
| 04:31.46 | CIA-109 | BRL-CAD: getting passed around as pointers and getting later treated as 3d-arrays. |
| 04:32.03 | brlcad | louipc: thanks... but do you have an svn checkout? :) |
| 04:32.09 | louipc | yeah |
| 04:32.10 | CIA-109 | BRL-CAD: 03starseeker * r47480 10/brlcad/trunk/NEWS: |
| 04:32.10 | CIA-109 | BRL-CAD: obj export was producing facets that all shared the same number instead of |
| 04:32.10 | CIA-109 | BRL-CAD: pointing to the correct points - problem was very precisely identified by |
| 04:32.10 | CIA-109 | BRL-CAD: Christopher Pitts (down to the incorrect variable in the source file), so he |
| 04:32.10 | CIA-109 | BRL-CAD: gets credit for the fix - thanks\! |
| 04:32.26 | brlcad | line numbers will be askew and easier to verify if you can svn up while I fix |
| 04:32.40 | louipc | ok |
| 04:34.11 | brlcad | starseeker: cool, thx |
| 04:35.02 | brlcad | unrelared, r47471 seems wrong .. removed bu.h and pulled in a bunch of header foo it was using in the test client? |
| 04:35.19 | brlcad | presume you encountered some problem? |
| 04:35.44 | starseeker | the point of that client was to be totally self contained |
| 04:36.29 | brlcad | is ntohll required for something in the test client?? |
| 04:36.35 | brlcad | that seems .. wrong :) |
| 04:36.50 | starseeker | IIRC, Eric was using it to ensure network order when packing some stuff |
| 04:37.35 | starseeker | shrugs - I'm still doing remedial education at this point, I did that to ensure the build worked |
| 04:37.40 | brlcad | no problem |
| 04:37.45 | brlcad | it was more a curiosity |
| 04:37.55 | brlcad | it could frankly be a shell script making telnet calls |
| 04:38.33 | starseeker | in principle, sure - in practice I'm trying to at least *pretend* the goal is to be portable to Windows :-P |
| 04:38.42 | brlcad | but by "self contained" the main requirement is actually just not calling any gs/ge code |
| 04:38.47 | starseeker | right |
| 04:39.01 | brlcad | bu.h isn't in that category, so it's an impl detail |
| 04:39.31 | brlcad | it's the stuff in the geomcore checkout that should be avoided (for the indep test only of course) |
| 04:39.54 | starseeker | nods - I could have fixed the build logic too, but the logic ran "why's this failing - oh, that's supposed to be self-contained - huh it's just using that one feature - commit" |
| 04:39.54 | brlcad | either way, like I said -- more just a curiosity, carry on ;) |
| 04:40.18 | starseeker | resumes wallowing in ignorance :-P |
| 04:40.30 | starseeker | btw, welcome back |
| 04:41.25 | brlcad | it raised my "what?" radar simply because it fails DRY and that usually trumps |
| 04:41.39 | starseeker | ponders whether SCL should do as BRL-CAD does with version numbers... |
| 04:42.36 | brlcad | for a project that small, the version number could live in the top-level CMakeLists.txt file, maybe wrap in a macro if it's needed in multiple places but the built-in versioning hooks are probably sufficient |
| 04:43.08 | brlcad | we're more of a platform where that number is used all over the place in various ways |
| 04:43.11 | brlcad | scl not so much |
| 04:43.38 | starseeker | nods - that was my thought |
| 04:43.56 | starseeker | just do some .in files if they want it in headers |
| 04:44.51 | starseeker | s/Eric/Erik |
| 04:44.57 | starseeker | alright, bedtime |
| 04:47.09 | brlcad | hasta la pasta |
| 04:48.42 | louipc | oops? http://louipc.mine.nu/brlcad/brlcad-svn47480-build.log |
| 04:48.48 | jarray52 | brlcad: Thanks for answering my questions. |
| 04:49.11 | jarray52 | I want to thank starseeker and others as well. |
| 04:50.23 | louipc | thanks for being patient and sticking around ;) |
| 05:39.25 | jordisayol | brlcad: hasta la pasta!? |
| 05:41.11 | jarray52 | 8-) |
| 08:10.20 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 08:52.57 | *** join/#brlcad abhi2011 (~chatzilla@117.200.85.67) | |
| 09:07.51 | *** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 11:39.05 | *** join/#brlcad abhi2011 (~chatzilla@117.200.88.176) | |
| 12:45.29 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.88.176) | |
| 12:50.03 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.88.176) | |
| 13:27.18 | *** join/#brlcad abhi2011 (~chatzilla@117.200.88.176) | |
| 13:42.04 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 14:10.20 | *** join/#brlcad abhi2011 (~chatzilla@117.200.82.152) | |
| 14:22.24 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 14:34.32 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 15:03.38 | CIA-109 | BRL-CAD: 03d_rossberg * r47481 10/rt^3/trunk/ (2 files in 2 dirs): |
| 15:03.39 | CIA-109 | BRL-CAD: method to get a simple facetized boundary-representation of a subtree |
| 15:03.39 | CIA-109 | BRL-CAD: it's a method of the database because not only one element is involved but the tree below the requested element |
| 15:09.48 | ``Erik | the GS "ping/pong" uses a network order uint64, so ntohll() was needed... personally, I think the protocol should evolve as a human readable ascii thing over the line (yes, so telnet can be used, and it can be easily debugged), then add a 'binary' command and mode down the road |
| 15:14.28 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:41.40 | brlcad | d_rossberg: not that it matters much, but "nmg" stands for n-manifold geometry |
| 15:42.07 | brlcad | the original paper was entitled non-manifold, but by the time it was implemented and announced, it became n-manifold |
| 15:48.35 | brlcad | of course, the generalized structure happens to support n-manifold surfaces as well as non-manifold vertices and edges (not sure about non-manifold faces) |
| 16:00.29 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.84.128) | |
| 16:02.07 | d_rossberg | these n-manifold vs. non-manifold sounds unfortunate, espaecially because it is still the original Weiler non-manifild |
| 16:02.51 | d_rossberg | including all its ballast |
| 16:03.23 | brlcad | it's mainly due to the audience perspective, though |
| 16:03.46 | brlcad | weiler was trying to solve the academic problem of how to model non-manifold entities |
| 16:04.17 | brlcad | the structure does that, even if the dominant use is for n-manifold surface boundaries |
| 16:05.18 | d_rossberg | i wouldn't mind to get rid of the burden |
| 16:05.23 | brlcad | from our users perspective, it should really just be called a "mesh" or "solid polygonal mesh" or similar :) |
| 16:05.50 | brlcad | burden? |
| 16:06.14 | d_rossberg | the model, region and lower dimensional things |
| 16:07.02 | brlcad | you mean implement a non-weiler polygonal mesh api or something else? :) |
| 16:07.17 | d_rossberg | all we really need is a single shell |
| 16:08.36 | d_rossberg | it looks like most of the algorothms using nmg can't handle models with multiple regions |
| 16:09.30 | brlcad | that's because they're all just copies of each other and the first guy was lazy |
| 16:09.34 | d_rossberg | these are relics of the original nmg CAD project |
| 16:09.48 | ``Erik | most assume an NMG is a single NMG region with a single NMG shell, iirc |
| 16:11.21 | brlcad | I don't believe the boolean evaluator used for E/ev is that limited |
| 16:11.58 | d_rossberg | and support of Euler operations would be nice |
| 16:13.27 | brlcad | if I have an rcc and subtract an arb8 from the middle, makes two shells -- you really don't want to create two single-shell nmg objects, you want just one named object with the two shells in it |
| 16:15.25 | d_rossberg | nmg_booltree_leaf_tess creates a new model for every primitive |
| 16:16.13 | brlcad | nmg supports most euler operations iirc |
| 16:16.37 | brlcad | perhaps not all |
| 16:22.28 | brlcad | creates a new model for each prim, but then pairwise extracts their (single) shell and performs the boolean |
| 16:22.53 | brlcad | the limitation is only on a single primitive that might have multiple shells (BoT, pnts, dsp, ..) |
| 16:24.14 | brlcad | otherwise, the boolean of two shells will result in n-shells |
| 16:28.14 | d_rossberg | a shell is a simple collection of faces, loops, edges and a vertex, there is no real restriction to a single connected volume |
| 16:28.24 | d_rossberg | however, i plan to write down my impress |
| 16:28.44 | d_rossberg | -ions and send them to the devel-list |
| 16:28.55 | d_rossberg | ... later |
| 16:29.54 | brlcad | well, no restriction other than that is the (current) definition of a shell :) |
| 16:32.31 | brlcad | that said, I do agree that there's no practical benefit that comes to mind for having models and regions (to a slightly lesser degree) |
| 16:33.49 | brlcad | there would be a purpose for regions and models if you could associate user-data (void*) to caller API |
| 16:34.58 | *** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 16:35.42 | *** join/#brlcad abhi2011 (~chatzilla@117.200.82.93) | |
| 17:21.04 | *** join/#brlcad abhi2011 (~chatzilla@117.200.82.93) | |
| 18:22.46 | starseeker | hah, cool: http://code.google.com/p/libmv/ |
| 18:51.57 | ``Erik | was looking at that a while ago, have they actually been working on it? O.o seemed like a dead end at the time |
| 18:52.48 | CIA-109 | BRL-CAD: 03erikgreenwald * r47482 10/geomcore/trunk/tests/func/GE/GeometryEngineTest.cxx: fix usage typo |
| 19:00.53 | *** join/#brlcad merzo (~merzo@128-101-133-95.pool.ukrtel.net) | |
| 19:02.24 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.80.170) | |
| 19:06.11 | brlcad | "BRLCAD" is a typo too |
| 19:06.32 | brlcad | dash merely in the wrong place |
| 19:59.25 | CIA-109 | BRL-CAD: 03brlcad * r47483 10/brlcad/trunk/ (5 files in 5 dirs): |
| 19:59.25 | CIA-109 | BRL-CAD: make the invoking wrapper batch scripts all set the PATH before running |
| 19:59.25 | CIA-109 | BRL-CAD: mged/archer/bwish/rtwizard so that tools invoked by commands can be found. |
| 19:59.25 | CIA-109 | BRL-CAD: untested, but should do the trick without requiring the user to have |
| 19:59.25 | CIA-109 | BRL-CAD: admin/profile rights to modify the PATH permanently. this is in response to a |
| 19:59.25 | CIA-109 | BRL-CAD: feature request from the dwayne kregel. |
| 20:13.25 | CIA-109 | BRL-CAD: 03brlcad * r47484 10/brlcad/trunk/ (4 files in 2 dirs): apply another tclscript update from carl g moore jr that reports what the input object names are that weren't combs and makes reid report the highest value set. |
| 20:20.56 | CIA-109 | BRL-CAD: 03brlcad * r47485 10/brlcad/trunk/TODO: document dwayne's detailed feature request for a geometry prep lintian command |
| 20:55.02 | CIA-109 | BRL-CAD: 03brlcad * r47486 10/brlcad/trunk/NEWS: |
| 20:55.02 | CIA-109 | BRL-CAD: daniel applied a fix in r47473 for a bug that was preventing the detection of V4 |
| 20:55.02 | CIA-109 | BRL-CAD: regions during raytrace. it looks like this is the same bug reported by chris |
| 20:55.02 | CIA-109 | BRL-CAD: pitts a couple weeks ago, which he'd traced down to db5_sync_attr_to_comb() |
| 20:55.02 | CIA-109 | BRL-CAD: wiping out the comb structure. |
| 21:02.47 | CIA-109 | BRL-CAD: 03brlcad * r47487 10/brlcad/trunk/NEWS: bob added the 'l'ist command to archer, which improves/fixes the 'g' grouping command |
| 21:08.45 | CIA-109 | BRL-CAD: 03brlcad * r47488 10/brlcad/trunk/AUTHORS: special thanks to chris pitts for his efforts to report, diagnose, and even help pinpoint where in the source code a problem was occurring. helped with v4 raytracing and obj export issue. |
| 21:11.02 | CIA-109 | BRL-CAD: 03brlcad * r47489 10/brlcad/trunk/AUTHORS: browder now belongs up in the code contributions section given all of the recent documentation efforts. |
| 22:53.22 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 23:10.59 | CIA-109 | BRL-CAD: 03n_reed * r47490 10/brlcad/trunk/src/other/ (9 files in 2 dirs): adding sources for an experimental scanner-generator |
| 23:11.24 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 23:20.54 | *** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 00:13.37 | *** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 00:22.42 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 00:49.18 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 03:20.27 | starseeker | hah, sweet! http://spacenav.sourceforge.net/ |
| 03:32.32 | brlcad | shame only the windows port is lgpl, but pretty cool regardless |
| 03:47.37 | *** join/#brlcad abhi2011 (~chatzilla@117.200.88.17) | |
| 03:55.26 | starseeker | brlcad: we wouldn't need to bundle the driver though would we? |
| 03:55.29 | starseeker | the sdk is BSD license |
| 04:05.43 | abhi2011 | brlcad: with regard the mail, so can you explain a bit more about what you mean by the segment closest to the object |
| 04:19.13 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.90.21) | |
| 04:33.09 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.88.129) | |
| 04:39.54 | brlcad | abhi2011: probably best demonstrated with a picture, but the basic idea is to shoot a grid of rays from behind object A towards object B |
| 04:42.06 | brlcad | for all the rays that hit B, you find the one with the furthest "back" starting point, use it's normal on B's surface |
| 08:32.54 | *** join/#brlcad abhi2011 (~chatzilla@117.200.90.206) | |
| 09:28.54 | *** join/#brlcad abhi2011 (~chatzilla@117.200.90.206) | |
| 10:32.30 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.90.206) | |
| 10:59.27 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.82.25) | |
| 13:42.14 | *** join/#brlcad kanzure_ (~kanzure@131.252.130.248) | |
| 13:48.05 | ``Erik | brlcad: new crit == 3268 vgr's (opposed to 1100 for current and 1300 for old replacement) |
| 14:59.08 | CIA-109 | BRL-CAD: 03erikgreenwald * r47491 10/geomcore/trunk/tests/func/GE/GeometryEngineTest.cxx: minor tweaks to usage output |
| 15:16.20 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:28.05 | brlcad | not too shabby |
| 16:27.09 | CIA-109 | BRL-CAD: 03brlcad * r47492 10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c: remove the pointer indirection since that messes with array indexing and causes a compiler warning on some platform somewhere. |
| 16:33.30 | *** join/#brlcad yukonbob (~bch@S01060024a5c9dad4.ok.shawcable.net) | |
| 16:33.35 | yukonbob | hello, #brlcad |
| 16:44.19 | *** join/#brlcad abhi2011 (~chatzilla@117.200.81.168) | |
| 17:08.39 | *** join/#brlcad abhi2011 (~chatzilla@117.200.81.168) | |
| 17:19.05 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.81.168) | |
| 17:50.11 | CIA-109 | BRL-CAD: 03starseeker * r47493 10/brlcad/trunk/src/ (4 files in 3 dirs): Turn on clipper library for Bob's stuff |
| 17:53.07 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.81.168) | |
| 19:32.47 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 19:46.11 | CIA-109 | BRL-CAD: 03bob1961 * r47494 10/brlcad/trunk/ (9 files in 2 dirs): Added a flag to the drawLines3D functions for optionally drawing line strips instead of lines. |
| 20:16.05 | CIA-109 | BRL-CAD: 03bob1961 * r47495 10/brlcad/trunk/ (include/ged.h src/libged/view.c src/mged/setup.c): Changed the ged_view function to ged_view_func so that it's different from struct ged_view. This eliminates a problem that appears when including ged.h in a C++ file. |
| 20:25.49 | CIA-109 | BRL-CAD: 03erikgreenwald * r47496 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: reflect change from ged_view to ged_view_func in table |
| 20:27.49 | CIA-109 | BRL-CAD: 03erikgreenwald * r47497 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: pass 0 to new sflags field |
| 20:31.53 | CIA-109 | BRL-CAD: 03bob1961 * r47498 10/brlcad/trunk/ (3 files in 2 dirs): Added code to interface with src/other/clipper. More work to do here --- checking in for safety. |
| 20:40.27 | CIA-109 | BRL-CAD: 03brlcad * r47499 10/brlcad/trunk/TODO: they already have the init funcs, need pkgIndex.tcl file for our core libs |
| 20:43.13 | CIA-109 | BRL-CAD: 03brlcad * r47500 10/brlcad/trunk/src/tclscripts/archer/BotUtility.tcl: include requisite dependency packages as well as loading libbu so we can find botEditor.tcl and quell failure message during build. |
| 20:44.33 | CIA-109 | BRL-CAD: 03bob1961 * r47501 10/brlcad/trunk/ (include/tclcad.h src/libtclcad/tclcad_obj.c): Added code to utilize src/other/clipper. Needs more work --- checking in for safety. |
| 21:02.33 | CIA-109 | BRL-CAD: 03brlcad * r47502 10/brlcad/trunk/TODO: added dwayne's idea to wrong section, promote up a few easy tasks for this upcoming minor |
| 21:13.39 | CIA-109 | BRL-CAD: 03bob1961 * r47503 10/brlcad/trunk/ (include/ged.h src/libtclcad/tclcad_obj.c): Added the gdps_prev_point and gdps_curr_polygon members to struct ged_data_polygon_state. |
| 21:37.29 | CIA-109 | BRL-CAD: 03brlcad * r47504 10/brlcad/trunk/src/librt/primitives/nmg/nmg_copy.c: convert //-style comments to /**/ |
| 21:45.58 | CIA-109 | BRL-CAD: 03brlcad * r47505 10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c: bah, still issues with quellage. expand the vmove to avoid the parens. make the nmg_good_dirs container size be consistently checked too. |
| 22:01.11 | CIA-109 | BRL-CAD: 03brlcad * r47506 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: copy paste error. ret isn't actually set/used, so shouldn't conditionalize on it. |
| 22:06.37 | CIA-109 | BRL-CAD: 03brlcad * r47507 10/brlcad/trunk/src/libged/Makefile.am: tclcad uses clipper so have to enable it for autotools compilation. include src/other/clipper as header search dir too. |
| 22:14.31 | CIA-109 | BRL-CAD: 03brlcad * r47508 10/brlcad/trunk/src/libged/clipper.cpp: update header |
| 22:19.38 | CIA-109 | BRL-CAD: 03brlcad * r47509 10/brlcad/trunk/src/libged/ (CMakeLists.txt Makefile.am clipper.cpp polyclip.cpp): |
| 22:19.38 | CIA-109 | BRL-CAD: rename clipper.cpp to polyclip.cpp so as to not conflict with the same-named |
| 22:19.38 | CIA-109 | BRL-CAD: clipper.cpp in src/other. this was path of least resistance since it's not |
| 22:19.38 | CIA-109 | BRL-CAD: worth the effort to add autotools build logic for clipper or conditionalize |
| 22:19.38 | CIA-109 | BRL-CAD: compilation. |
| 22:21.35 | *** join/#brlcad yukonbob (~bch@207.6.71.53) | |
| 22:21.40 | yukonbob | hello, #brlcad |
| 22:25.24 | CIA-109 | BRL-CAD: 03brlcad * r47510 10/brlcad/trunk/src/libged/polyclip.cpp: update function names to match new file name. common.h before sys header too. |
| 22:28.10 | CIA-109 | BRL-CAD: 03brlcad * r47511 10/brlcad/trunk/src/libged/polyclip.cpp: non-API functions shouldn't have ged_ prefix and should be made static when possible. |
| 22:56.00 | CIA-109 | BRL-CAD: 03n_reed * r47512 10/brlcad/trunk/src/other/perplex/ (Makefile.local perplex.c perplex.h scanner.re template.c): borrowing flex's dynamic buffers to implement yytext string |
| 23:00.39 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 23:23.18 | CIA-109 | BRL-CAD: 03bob1961 * r47513 10/brlcad/trunk/ (3 files in 3 dirs): Added more parameters (i.e. scale factors and matrices for transforming to/from model/view) to ged_clip_polygon, ged_clip_polygons, load_polygon, load_polygons and extract. |
| 23:58.16 | CIA-109 | BRL-CAD: 03bob1961 * r47514 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Fixed to_mouse_poly_rect to work in an arbitrary plane. |
| 00:03.25 | CIA-109 | BRL-CAD: 03bob1961 * r47515 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Updated to_data_polys() to call ged_clip_polygon() with a scale factor of LONG_MAX. |
| 01:38.33 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 02:03.20 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 03:32.15 | *** join/#brlcad abhi2011 (~chatzilla@117.200.84.149) | |
| 04:49.58 | CIA-109 | BRL-CAD: 03starseeker * r47516 10/geomcore/trunk/geomserv_boost/ (258 files in 34 dirs): |
| 04:49.59 | CIA-109 | BRL-CAD: Checkpoint some work studying boost::asio + Google's protobuf - probably not a |
| 04:49.59 | CIA-109 | BRL-CAD: direction we want to go right now, but saving what has been done in case it |
| 04:49.59 | CIA-109 | BRL-CAD: should prove useful at some point in the future. Decided not to add the entire |
| 04:49.59 | CIA-109 | BRL-CAD: CMake-ified boost, just include the one tweak needed. Same deal for protobuf - |
| 04:49.59 | CIA-109 | BRL-CAD: see README for the locations to get them from. |
| 05:32.47 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.88.52) | |
| 05:42.38 | CIA-109 | BRL-CAD: 03starseeker * r47517 10/geomcore/trunk/geomserv_boost/: Ah, checkpoint succeeded. Can clear it now, version control knows about it. |
| 08:02.39 | *** join/#brlcad abhi2011 (~chatzilla@117.200.88.52) | |
| 08:14.53 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 08:30.14 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 09:12.04 | *** join/#brlcad abhi2011 (~chatzilla@117.200.88.52) | |
| 09:39.35 | abhi2011 | there seems to be ummatched endif at the end of brlcad_config.h |
| 09:39.45 | abhi2011 | *an unmatched |
| 09:41.38 | abhi2011 | brlcad_config.h is generated by cmake logic I think |
| 09:49.01 | abhi2011 | ok removed an extra : FILE(APPEND ${CONFIG_H_FILE} "#define __CONFIG_H__\n") |
| 09:49.06 | abhi2011 | lets see if it compiles ok |
| 10:13.19 | abhi2011 | nope that wasnt the right line |
| 10:13.32 | abhi2011 | probably something else |
| 12:02.25 | *** join/#brlcad abhi2011 (~chatzilla@117.200.84.80) | |
| 12:30.39 | *** join/#brlcad abhi2011 (~chatzilla@117.200.84.80) | |
| 12:48.24 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.84.80) | |
| 13:03.14 | *** join/#brlcad abhi2011 (~chatzilla@117.200.84.80) | |
| 13:42.40 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.84.80) | |
| 14:50.46 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 14:54.26 | starseeker | abhi2011: can you post your brlcad_config.h somewhere? also, are you trying a clean compile? |
| 14:56.31 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.85.81) | |
| 15:12.05 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:22.22 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.85.81) | |
| 15:44.53 | CIA-109 | BRL-CAD: 03bob1961 * r47518 10/brlcad/trunk/src/libged/polyclip.cpp: Added a try catch block around a call to clipper's AddPolygon method. |
| 15:46.35 | CIA-109 | BRL-CAD: 03bob1961 * r47519 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Use clipper's weird upper limit as a scale factor for the call to ged_clip_polgon(). |
| 15:50.10 | CIA-109 | BRL-CAD: 03starseeker * r47520 10/geomcore/trunk/geomserv_boost/ (5 files in 4 dirs): Gah, missed a couple things. Try again to checkpoint a building version of geomserv_boost |
| 15:50.34 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.82.230) | |
| 16:00.51 | CIA-109 | BRL-CAD: 03starseeker * r47521 10/geomcore/trunk/geomserv_boost/: OK, this time it actually built based on what was in svn tree (given the boost/protobuf downloads and glog/gflags/gtest in third_party) so we're good. |
| 16:20.19 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.82.230) | |
| 16:33.49 | CIA-109 | BRL-CAD: 03bob1961 * r47522 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Added functions to expose the current poly modes. |
| 17:06.23 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.82.230) | |
| 17:50.29 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.82.230) | |
| 17:57.37 | starseeker | abhi2011: were you still having brlcad_config.h problems? |
| 18:11.30 | *** join/#brlcad yukonbob (~bch@207.6.71.53) | |
| 18:11.33 | yukonbob | hello, #brlcad |
| 18:26.27 | starseeker | hello yukonbob |
| 18:26.32 | starseeker | what's new? |
| 18:28.07 | yukonbob | oh -- what's new... working on getting to Seattle for a new gig... |
| 18:28.31 | yukonbob | seeing lots of brlcad mailing list activity lately, which is exciting. |
| 18:28.44 | starseeker | :-) |
| 18:28.52 | starseeker | doing anything with Tcl/Tk lately? |
| 18:29.05 | yukonbob | occasionally working on my nbsd/tcl/brlcad integration, which is satisfying. |
| 18:29.18 | yukonbob | starseeker: always. |
| 18:29.20 | yukonbob | :) |
| 18:29.32 | starseeker | yukonbob: did you get a chance to check out the CMake Tcl/Tk build? |
| 18:29.46 | yukonbob | haven't looked in detail, no. |
| 18:30.03 | starseeker | https://github.com/starseeker/tcltk |
| 18:30.05 | yukonbob | I saw discssion on tcl mailing list, and I've seen commits over the months. |
| 18:30.29 | starseeker | needs to put a TIP together, apparently - not sure how else to keep that process moving |
| 18:30.54 | yukonbob | these "big" changes always throw me for a loop. |
| 18:31.05 | starseeker | how so? |
| 18:31.09 | yukonbob | and they're always tcl-related ;) |
| 18:31.19 | starseeker | heh |
| 18:31.40 | starseeker | you mean 8.5 -> 8.6? |
| 18:32.18 | yukonbob | well, when tcl8.5 was introduced, 8.5 was beta or alpha, and not widely distributed... my env is nbsd, and I had already done surgery to tease out nbsd-provided support and get a good build system running, then a beta version of tcl was tossed in. |
| 18:32.31 | yukonbob | that pretty much killed my involvement for long time. |
| 18:32.40 | starseeker | ah, right |
| 18:32.51 | starseeker | well, rest assured we aren't requiring 8.6 :-) |
| 18:32.59 | yukonbob | Now I've actually got 8.6 integration working, and the build system is shifting under my feet ;) |
| 18:33.05 | starseeker | that's just the version in the github project because I figured it would be an easier sell |
| 18:33.09 | yukonbob | is already there.. |
| 18:33.13 | starseeker | ah, cool! |
| 18:33.42 | starseeker | yukonbob: actually, there's not really a shift in the Tcl/Tk build - just another option |
| 18:34.02 | yukonbob | starseeker: in conversation w/ brlcad he suggested auto* is on it's way out. |
| 18:34.06 | yukonbob | over the months... |
| 18:34.11 | starseeker | oh, the BRL-CAD build |
| 18:34.13 | starseeker | yeah |
| 18:34.29 | starseeker | does netbsd have CMake? |
| 18:41.35 | starseeker | yukonbob: out of curiosity, have you submitted your tcl/tk 8.6 patches for BRL-CAD? |
| 18:45.20 | yukonbob | I haven't. Am parallelly (sp?) working locally -- I *think* I've got commit status... I should build a branch and hack. |
| 18:45.42 | yukonbob | The work is basically: make things modular on nbsd. |
| 18:46.09 | yukonbob | I've committed some patches and discussion as issues come up, but haven't been doing dev in-tree. |
| 18:46.11 | starseeker | would advocate branching in svn - we're all curious :-) |
| 18:47.04 | yukonbob | tests something. |
| 18:48.18 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 19:02.47 | yukonbob | starseeker: mind if I try an inconsequential test commit? Like adding a space to README? |
| 19:08.28 | CIA-109 | BRL-CAD: 03bharder * r47523 10/brlcad/trunk/README: ws test commit |
| 19:09.03 | yukonbob | ok -- I still have access; I'll create a branch and get this h4x0ring closer to the canonical project. |
| 19:14.03 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 19:16.25 | CIA-109 | BRL-CAD: 03starseeker * r47524 10/brlcad/trunk/src/libpkg/ (7 files in 2 dirs): Add separate client and server examples based on tpkg.c for libpkg. Use localhost by default if client doesn't specify a host for simplicity. |
| 19:20.19 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 19:20.54 | CIA-109 | BRL-CAD: 03brlcad * r47525 10/brlcad/trunk/src/ (19 files in 10 dirs): replace all calls to unlink() and remove() with calls to bu_file_delete() so we can get more consistent and portable behavior. |
| 19:23.45 | abhi2011 | starseeker: there were some linking errors : http://bin.cakephp.org/view/2126104478 |
| 19:25.17 | abhi2011 | ok trying with a fresh chkout now |
| 19:27.30 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.82.230) | |
| 19:30.07 | starseeker | abhi2011: ah, that's the new clipper stuff |
| 19:30.40 | CIA-109 | BRL-CAD: 03brlcad * r47526 10/brlcad/trunk/HACKING: add bu_file_delete to the use-this-instead-of-that function list |
| 19:41.21 | CIA-109 | BRL-CAD: 03starseeker * r47527 10/brlcad/trunk/src/other/clipper/ (CMakeLists.txt clipper.hpp): Make a stab at getting clipper to act like a library in Windows - untested. |
| 19:43.07 | starseeker | abhi2011: see if that helps any... |
| 19:49.19 | abhi2011 | starseeker: the clipper related errors are gone, I have some errors due to linking with opengl : http://bin.cakephp.org/view/129832489 |
| 19:51.09 | abhi2011 | hmm there is some clipper.lib related things there too |
| 19:53.51 | starseeker | abhi2011: not sure what the opengl stuff is about - the clipper.lib stuff is probably our not having that whipped into shape as a Windows library |
| 19:54.27 | abhi2011 | ok |
| 19:54.41 | starseeker | abhi2011: I'd recommend disabling the togl build |
| 19:54.54 | abhi2011 | ok |
| 19:55.44 | starseeker | hmm, oops |
| 19:55.48 | starseeker | one second |
| 19:55.52 | abhi2011 | ok |
| 19:55.55 | abhi2011 | :) |
| 19:55.59 | starseeker | that's only supposed to be on for X11 builds... |
| 19:56.02 | starseeker | grumble... |
| 19:57.25 | abhi2011 | ok,,,yaawwwnn,,,will chk it tomorrow then...getting kinda late in the night here :) |
| 20:00.40 | CIA-109 | BRL-CAD: 03starseeker * r47528 10/brlcad/trunk/src/ (adrt/CMakeLists.txt other/CMakeLists.txt): Togl isn't behaving well yet under non-X11 builds - turn it off unless we are X11 |
| 20:00.56 | starseeker | abhi2011: k |
| 20:12.46 | CIA-109 | BRL-CAD: 03n_reed * r47529 10/brlcad/trunk/src/other/perplex/ (Makefile.local perplex.c perplex.h scanner.re template.c): make scanner input buffer dynamic |
| 20:15.29 | CIA-109 | BRL-CAD: 03brlcad * r47530 10/brlcad/trunk/include/bn.h: document what range of values are returned from bn_randmt() |
| 20:31.41 | *** join/#brlcad yukonbob (~bch@207.6.71.53) | |
| 21:18.20 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 21:30.15 | brlcad | starseeker: some of the "AUTO" items in cmake shouldn't be, only the ones that are detection-based |
| 21:30.26 | brlcad | e.g., optimized .. it's on and off |
| 21:30.39 | brlcad | auto doesn't make sense, you don't know :) |
| 21:31.06 | brlcad | 64bit is detection-based but most of the compile flags aren't |
| 21:34.37 | CIA-109 | BRL-CAD: 03brlcad * r47531 10/brlcad/trunk/ (5 files in 3 dirs): |
| 21:34.38 | CIA-109 | BRL-CAD: formally mark all of the muves-specific commands as DEPRECATED, making them |
| 21:34.38 | CIA-109 | BRL-CAD: report a deprecation warning if they're used. this includes em, e_muves, |
| 21:34.38 | CIA-109 | BRL-CAD: l_muves, lm, read_muves, and t_muves. rationale is that those are |
| 21:34.38 | CIA-109 | BRL-CAD: domain-specific extensions that don't really belong in brl-cad (they belong with |
| 21:34.38 | CIA-109 | BRL-CAD: muves). they would make for a potentially suitable set of plugins to a |
| 21:34.39 | CIA-109 | BRL-CAD: plugin-oriented libged, but not something we maintain and bundle. |
| 21:43.44 | CIA-109 | BRL-CAD: 03brlcad * r47532 10/brlcad/trunk/BUGS: critical TIE bug encountered. seems to be corrupting the application structure. maybe related to or be known 32-bit bug. |
| 21:44.13 | brlcad | ``Erik: that was supposedly a 64-bit compile, returning garbage in app structure and wrong segment hit count |
| 21:56.42 | CIA-109 | BRL-CAD: 03brlcad * r47533 10/brlcad/trunk/BUGS: more info on TIE bug, return value seems wrong |
| 21:58.25 | CIA-109 | BRL-CAD: 03lbutler * r47534 10/brlcad/trunk/src/rt/view.c: a quick hack to add ambient occlusion |
| 22:29.15 | CIA-109 | BRL-CAD: 03lbutler * r47535 10/brlcad/trunk/src/rt/view.c: ambient occlusion computations included. set ambSamples non-zero to get sampling of ambient occlusion. set ambRadius non-zero to bound the distance considered "occluding". |
| 22:39.54 | CIA-109 | BRL-CAD: 03bob1961 * r47536 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Incorporate snap-to-grid with polygon rectangle/circle creation. Update to_data_pick() and to_data_move() to work with data polygons. Change data_polys to data_polygons. |
| 22:50.26 | CIA-109 | BRL-CAD: 03n_reed * r47537 10/brlcad/trunk/src/other/perplex/ (6 files): adding lemon parser; moving towards useful conversion of input |
| 23:07.39 | CIA-109 | BRL-CAD: 03starseeker * r47538 10/brlcad/trunk/src/ (libged/CMakeLists.txt other/clipper/clipper.hpp): More clipper tweaks |
| 23:10.18 | CIA-109 | BRL-CAD: 03lbutler * r47539 10/brlcad/trunk/src/rt/view.c: get two partitions by default. Shouldn't need more. |
| 00:50.33 | CIA-109 | BRL-CAD: 03starseeker * r47540 10/brlcad/trunk/misc/CMake/ (BRLCAD_Util.cmake ThirdParty.cmake ThirdParty_TCL.cmake): Make the third party options a bit more informative |
| 01:08.31 | *** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 01:12.30 | CIA-109 | BRL-CAD: 03starseeker * r47541 10/brlcad/trunk/ (TODO.cmake misc/CMake/BRLCAD_Util.cmake): Get the on/off toggles with auto option displaying their actual state, not just 'AUTO' |
| 01:17.50 | CIA-109 | BRL-CAD: 03starseeker * r47542 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: AUTO isn't always in the front with new labels |
| 01:23.34 | CIA-109 | BRL-CAD: 03starseeker * r47543 10/brlcad/trunk/CMakeLists.txt: Be more informative about what's going on with the CPU type, too |
| 01:24.18 | starseeker | brlcad: hopefully that'll be more informative |
| 01:27.19 | CIA-109 | BRL-CAD: 03starseeker * r47544 10/brlcad/trunk/TODO.cmake: add a todo item for the alias mechanism |
| 02:49.23 | CIA-109 | BRL-CAD: 03starseeker * r47545 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_Util.cmake): Proof-of-concept implementation of a BRLCAD_OPTION macro that supports aliases for an option and appends documentation to a txt file. |
| 02:50.16 | starseeker | brlcad: before I go too much farther with that I'd appreciate some feedback (in particular, how to write out the documentation) |
| 02:54.04 | CIA-109 | BRL-CAD: 03starseeker * r47546 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: tweak |
| 02:57.48 | CIA-109 | BRL-CAD: 03starseeker * r47547 10/brlcad/trunk/CMakeLists.txt: correct global example |
| 03:04.42 | *** join/#brlcad abhi2011 (~chatzilla@117.200.86.6) | |
| 03:06.09 | CIA-109 | BRL-CAD: 03starseeker * r47548 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_Util.cmake): Wait - not handling things quite right with the macro. FORCE shouldn't be needed for that var in the GLOBAL file. |
| 03:14.32 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 03:17.02 | CIA-109 | BRL-CAD: 03starseeker * r47549 10/brlcad/trunk/ (CMakeLists.txt src/other/CMakeLists.txt): Fix some of the stray variables that should be advanced |
| 03:18.56 | CIA-109 | BRL-CAD: 03starseeker * r47550 10/brlcad/trunk/CMakeLists.txt: Hmm, that one is easier to change than I thought. Static libs, not the whole thing static |
| 03:36.22 | abhi2011 | starseeker: there are mismatched if/endif pairs in brlcad_config.h : http://bin.cakephp.org/view/430932163 |
| 03:37.07 | abhi2011 | there are 2 endifs at the end |
| 04:21.11 | *** join/#brlcad abhi2011 (~chatzilla@117.200.89.252) | |
| 04:35.11 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 04:52.56 | abhi2011 | probably its the cmakecache again, will clear and check |
| 05:20.15 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.89.252) | |
| 05:39.19 | starseeker | abhi2011: yeah, that's usually the cache or a stale file, and after that series of changes to the build logic this evening you'll probably have to clear out and reconfigure |
| 09:21.00 | *** join/#brlcad abhi2011 (~chatzilla@117.200.89.252) | |
| 09:48.34 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 14:25.25 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.155) | |
| 14:45.25 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:23.10 | CIA-109 | BRL-CAD: 03starseeker * r47551 10/brlcad/trunk/src/libpkg/example/CMakeLists.txt: Add libbu to the link lines... |
| 15:37.18 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.83.178) | |
| 16:03.08 | *** join/#brlcad Elrohir (~kvirc@p5B149B04.dip.t-dialin.net) | |
| 16:03.08 | abhi2011 | starseeker: the other errors are gone now, however 3 link errors are still there for libpkg : http://bin.cakephp.org/view/1734456229 |
| 16:25.56 | starseeker | abhi2011: does commit 47551 fix it? |
| 16:41.10 | abhi2011 | starseeker: yes thanks :), that did the trick |
| 17:22.45 | CIA-109 | BRL-CAD: 03starseeker * r47552 10/brlcad/trunk/misc/CMake/ (BRLCAD_Util.cmake ThirdParty.cmake ThirdParty_TCL.cmake): Tweaks and corrections to new CMake labeling. |
| 17:25.00 | CIA-109 | BRL-CAD: 03n_reed * r47553 10/brlcad/trunk/doc/bison_to_lemon.txt: update on alias substitution |
| 17:37.12 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.83.178) | |
| 18:01.22 | abhi2011 | nope spoke too early :P |
| 18:01.26 | abhi2011 | same error |
| 18:01.52 | abhi2011 | http://bin.cakephp.org/view/412812688 |
| 18:03.40 | abhi2011 | well libged compiles , so I can proceed with testing the simulate command :) |
| 18:11.48 | abhi2011 | so when a ray is travelling through a air region , is there some flag set in the struct partition for it (that is returned in the hit call back) |
| 18:12.43 | abhi2011 | or is only way to check that a ray segment is travelling through air, to check the order of the out and in primitives |
| 18:32.31 | CIA-109 | BRL-CAD: 03bob1961 * r47554 10/brlcad/trunk/src/ (libtclcad/tclcad_obj.c tclscripts/lib/Ged.tcl): These mods add the functionality to apply snap-to-grid to data polygon editing. |
| 19:19.04 | *** join/#brlcad yukonbob (~bch@S01060024a5c9dad4.ok.shawcable.net) | |
| 19:19.09 | yukonbob | hello, #brlcad |
| 19:19.12 | brlcad | hello |
| 19:19.34 | yukonbob | hey brlcad :) -- how're things? |
| 19:19.47 | yukonbob | seeing lots of interesting discussions in newsletters. |
| 19:20.25 | brlcad | usual, busy, fun, frustrating, interesting, difficult, routine, new, etc |
| 19:20.59 | yukonbob | what's "new"? |
| 20:22.27 | *** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 20:53.36 | CIA-109 | BRL-CAD: 03n_reed * r47555 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.c perplex.h scanner.re template.c): pass app data to lemon parser; first try at embellishing input |
| 21:03.04 | starseeker | yukonbob: any luck with making the tcltk 8.6 branch of BRL-CAD/ |
| 21:03.10 | starseeker | ? |
| 21:03.31 | yukonbob | starseeker: haven't even tried yet. |
| 21:04.31 | yukonbob | I have a local copy and installation; has been a while since I've played w/ the build, so I'd retry that, confirm it works. The code base will be out-of-date w/ current repo, *but* should be a working piece, which is the important part. |
| 21:04.45 | CIA-109 | BRL-CAD: 03brlcad * r47556 10/brlcad/trunk/src/rt/view.c: retStatus is unused |
| 21:05.09 | yukonbob | from there, pull changes from trunk -> 8.6, test, fix, test, fix, commit, lather, rinse, repeat. |
| 21:09.02 | CIA-109 | BRL-CAD: 03brlcad * r47557 10/brlcad/trunk/src/librtserver/rtserverTest.c: remove/comment out unused code. removes -a option since use_air isn't used. |
| 21:09.25 | starseeker | if the changes for 8.6 are something we can integrate back into trunk, it might make your life easier |
| 21:10.13 | CIA-109 | BRL-CAD: 03starseeker * r47558 10/brlcad/trunk/src/libpkg/example/CMakeLists.txt: Ah, right - need special compile flags for MSVC... (ugh) |
| 21:11.48 | yukonbob | starseeker: the work I've got so far is as it relates to my work w/ NetBSD, modularization, and BRLCAD. I'll see how it works; I know that I'm not at tip of repo, and that I've tried/failed w/ more recent code; I'll take stock though, and get something (with a description of that "something") committed. |
| 21:13.35 | starseeker | archivist: does 47558 do the trick? |
| 21:13.40 | starseeker | yukonbob: sounds good! |
| 21:14.02 | starseeker | when you say "modularization", what are you referring to? |
| 21:15.04 | brlcad | yukonbob: more nurbs, physics engine, geometry editing goodness, cmake stabilizing, archer revitalizing, ... |
| 21:15.34 | brlcad | getting 8.6 tested and udpated would be pretty helpful |
| 21:15.56 | yukonbob | will need to come to know nurbs. and is also still pretty interested in (and may have work for) dsp. |
| 21:16.18 | yukonbob | dsp still a stable, maintained, first-class citizen in BRLCADville? |
| 21:16.25 | brlcad | dsp is awesome |
| 21:16.37 | brlcad | underutilized and underdocumented, but good stuff nonetheless |
| 21:16.50 | starseeker | for head-scratching values of "maintained" :-P |
| 21:16.58 | yukonbob | dsp was one of my first forrays into brlcad, and I think my first bug-report ;) |
| 21:17.26 | yukonbob | anyway -- I'll get my scratch-work massaged and committed. |
| 21:17.42 | brlcad | lots of ways it can be improved further still, but hard-pressed to find better in-memory solid geometry terrain representation on the scale it supports |
| 21:17.50 | yukonbob | was not a fan of 8.5, but -is- a fan of 8.6, so happy to have that a side-effect of his work. |
| 21:18.01 | starseeker | sweet |
| 21:18.06 | CIA-109 | BRL-CAD: 03n_reed * r47559 10/brlcad/trunk/src/other/perplex/ (scanner.re template.c): use re2c syntax for setting conditions |
| 21:18.12 | starseeker | can build 8.6 with CMake - took some pains to be sure I could, actually |
| 21:18.23 | brlcad | well, as you noted.. you do still have commit ability :) |
| 21:18.39 | starseeker | needs to get a TIP written up - would REALLY love to have the CMake build logic just "there" in 8.6 final |
| 21:21.28 | starseeker | yukonbob: I need to set up a virtual machine with NetBSD so I can try a build - any recommendations on pre-cooked VirtualBox images? |
| 21:23.21 | yukonbob | starseeker: no... |
| 21:23.40 | yukonbob | 1s. |
| 21:24.14 | yukonbob | starseeker: virtualbox == that sun vm? |
| 21:24.34 | yukonbob | sees "yes". |
| 21:25.14 | CIA-109 | BRL-CAD: 03brlcad * r47560 10/brlcad/trunk/ (9 files in 9 dirs): |
| 21:25.15 | CIA-109 | BRL-CAD: rename BRLCAD-CPU_TYPE and CMAKE_CPU_TYPE to BRLCAD-WORD_SIZE and |
| 21:25.15 | CIA-109 | BRL-CAD: CMAKE_WORD_SIZE respectively so as not to imply chip type or architecture. CPU |
| 21:25.15 | CIA-109 | BRL-CAD: may be multimode as could the compiler, so it's not a good moniker. also |
| 21:25.15 | CIA-109 | BRL-CAD: consistently use either ##BIT or ##-bit styles when referring to the size in |
| 21:25.15 | CIA-109 | BRL-CAD: text. |
| 21:26.02 | starseeker | brlcad: awesome, thanks! |
| 21:26.08 | brlcad | starseeker: so I'm leaning more towards renaming all the BRLCAD- cases to BRLCAD_ grouping all vars together, for improved usability |
| 21:26.35 | starseeker | nods - sounds good. I have no particularly strong feelings on that, so whatever you feel is best |
| 21:26.51 | brlcad | it'd be nice to have subgroupings, but not at that usability crux since we'd still want to document what it really is |
| 21:27.02 | brlcad | then the aliases can just be shorthand and typo preventions |
| 21:27.14 | starseeker | nods |
| 21:27.15 | brlcad | not every _- permutation :) |
| 21:29.32 | CIA-109 | BRL-CAD: 03starseeker * r47561 10/brlcad/trunk/src/libpkg/example/ (client.c server.c): Hmm... trying to send a message back to the client from the server. Doing something wrong... |
| 21:31.43 | starseeker | I suppose I should have known it wouldn't be that simple... |
| 21:36.58 | yukonbob | starseeker: re: nbsd -- nothing I see off top of head. |
| 21:37.08 | starseeker | no problem |
| 21:37.54 | yukonbob | brl-cad still maintains own build server? |
| 21:38.19 | starseeker | um... you mean brlcad's setup? |
| 21:38.42 | yukonbob | not sure -- I've had an account on what I thought was a brl-cad machine in past. |
| 21:39.33 | starseeker | yeah, that's probably it - yeah, he's still got it up |
| 21:39.47 | yukonbob | only wondering for same reasons you're wondering about nbsd -- If there was some other box that's linux or fbsd or $whatever, just another opportunity to test build/run, shake out bugs, etc., etc. |
| 21:40.08 | starseeker | hmm... well, here's a bunch of images... no netbsd though http://virtualboxes.org/images/ |
| 21:40.38 | starseeker | come to think of it, that might be the opensolaris image I grabbed |
| 21:41.05 | starseeker | hopes he remember how to get into that - it was set up for building, and it's a long shot whether that could be done again |
| 21:41.06 | yukonbob | ah -- my account is still good. |
| 21:41.27 | yukonbob | oh wow. timewarp. |
| 21:41.29 | yukonbob | :) |
| 21:41.34 | starseeker | hehe |
| 21:41.44 | yukonbob | s'all good in the 'hood. ;) |
| 21:58.40 | brlcad | starseeker: fyi, I did a quick check and confirmed that the server should be able to send back to the client bidirectionally |
| 21:58.48 | brlcad | your comment yesterday didn't sound right.. |
| 21:59.34 | brlcad | fbserv sends back error notifications to the client being one relatively obvious example |
| 22:00.51 | brlcad | that's a pretty nifty virtualization OS list .. would be great for automated compilation testing for someone to set up |
| 22:01.21 | brlcad | run vm with each OS image, add brl-cad sources, compile, report to dashboard |
| 22:01.45 | brlcad | shudders at the awesome power of that |
| 22:05.16 | starseeker | was discussing that with some of the GSoC guys |
| 22:05.49 | brlcad | interesting, I was too |
| 22:05.58 | starseeker | Jenkins is apparently one of the relevant tools for managing something like that... |
| 22:06.16 | brlcad | more for gci purposes, though -- provide an image completely preconfigured, go! |
| 22:06.18 | yukonbob | a build dashboard? |
| 22:06.27 | starseeker | nods |
| 22:06.39 | yukonbob | cbuild |
| 22:07.08 | yukonbob | err. ctest. |
| 22:07.33 | starseeker | oh - we don't have ctest integrated yet |
| 22:07.38 | yukonbob | http://www.vtk.org/Wiki/CMake_Testing_With_CTest <--- w/ cdash, or dart... |
| 22:07.56 | yukonbob | has never actually used these, but is aware. |
| 22:08.49 | yukonbob | out. |
| 22:08.54 | yukonbob | chat later, cadheads. |
| 22:08.57 | starseeker | later! |
| 22:09.04 | brlcad | jenkins is one of the top ones |
| 22:09.17 | starseeker | hmm https://wiki.jenkins-ci.org/display/JENKINS/VirtualBox+Plugin |
| 22:09.18 | brlcad | hudson is a fork that seems more promising |
| 22:09.38 | brlcad | cruisecontrol is the old steadfast best |
| 22:09.54 | starseeker | um... thought jenkins was a fork of hudson? |
| 22:09.57 | brlcad | buildbot is one of the newercomers with some neat features |
| 22:10.45 | brlcad | sorry, that's right |
| 22:11.48 | brlcad | "Both the Jenkins and Hudson projects appear to consider the other to be a fork." |
| 22:12.04 | brlcad | more Oracle stupidity |
| 22:13.09 | CIA-109 | BRL-CAD: 03bob1961 * r47562 10/brlcad/trunk/ (3 files in 3 dirs): Added the mechanism for sketching out elliptical shaped polygons. |
| 22:13.11 | brlcad | I think any one of those four choices would be perfect for our needs, it's mostly just needing someone to champion setting it up proper |
| 22:13.36 | starseeker | brlcad: OK, I'll take a look at fbserv |
| 22:14.26 | brlcad | suggest just trying to figure it out with your own example still :) |
| 22:14.59 | brlcad | master of your own domain and whatnot |
| 22:15.14 | brlcad | plus it then requires really understanding what state both client and server are in |
| 22:15.43 | starseeker | doen't want to understand pkg... just wants it to work and go away... |
| 22:15.44 | brlcad | put printing statements before and after all of your send() and recv() statements in both client and server, so you can see who is waiting on what |
| 22:16.53 | brlcad | don't think that's a productive mindset |
| 22:17.00 | brlcad | it's not a means to an end, we use it already |
| 22:17.24 | brlcad | so you either want to learn it so you can/could use it or debug it or extend it, or you leave it to someone else... |
| 22:18.22 | starseeker | fair enough |
| 22:18.32 | brlcad | that would even be the case if we picked up some 3rd party package .. it's all fine and dandy when it works, but then it's a brick wall black box when anything goes wrong (which it eventually always does) |
| 22:19.15 | velociostrich | Activity on this channel? Unheard of! |
| 22:19.23 | velociostrich | goes back into hiding |
| 22:19.44 | brlcad | velociostrich: it's usually like this most days... |
| 22:19.47 | CIA-109 | BRL-CAD: 03bob1961 * r47563 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Removed junk that was mistakenly included with the previous commit. |
| 22:19.49 | brlcad | save maybe for last week |
| 22:20.08 | velociostrich | I wouldn't know, I'm not in here often, but when I have been I rarely noticed activity |
| 22:20.35 | velociostrich | Besides the 'e' command, is there any way to get a nicer preview of work in mged ala other cad packages, e.g., opencascade based alternatives? |
| 22:20.41 | brlcad | *shrug* |
| 22:20.41 | velociostrich | iirc it was 'e', anyway |
| 22:21.02 | brlcad | velociostrich: you can render via raytracing (File menu) |
| 22:21.29 | velociostrich | Yes, I do realize that |
| 22:21.32 | brlcad | for simple models, you can use the E or ev commands to get a polygonal wireframe |
| 22:21.42 | velociostrich | how do e and ev differ? |
| 22:21.58 | brlcad | e just draws the fundamental wireframe |
| 22:22.05 | brlcad | ev evaluates a polygonal wireframe |
| 22:22.18 | brlcad | E also evaluates, but with a slightly different algorithm |
| 22:22.43 | brlcad | you probably are looking for shaded display support, which is available for certain types of models but not all so it's disabled by default |
| 22:23.01 | brlcad | future release will enable shaded display support for all geometry types |
| 22:23.19 | velociostrich | strange, it seems that ev is having some depth buffer related issues (Does brlcad use a depth buffer?) |
| 22:23.30 | velociostrich | things on top of things that shouldn't be |
| 22:23.34 | brlcad | the depth buffer can be turned on/off under Misc |
| 22:23.59 | brlcad | along with depth lighting, and a few other modes |
| 22:25.31 | velociostrich | aha |
| 22:25.48 | velociostrich | although it seems that the depth buffer doesn't work unless Z clipping and the buffer are enabled |
| 22:25.57 | brlcad | starseeker: maybe you can convince bob to make that nsegs=30 dynamically adjust |
| 22:26.09 | brlcad | velociostrich: yep, iirc that sounds right |
| 22:26.45 | velociostrich | strange |
| 22:28.16 | velociostrich | Might I ask if there is any particular reason for the use of Tk and not a (as far as I know, ignorant as I am) more modern toolkit like Qt/Gtk for Archer (which afaik is much newer than mged)? |
| 22:30.13 | CIA-109 | BRL-CAD: 03brlcad * r47564 10/brlcad/trunk/ (25 files in 20 dirs): rename all of the BRLCAD- cmake variables to BRLCAD_ so we can consistently only use underscores everywhere. should help improve simplicity of docs and use. |
| 22:30.18 | brlcad | velociostrich: archer is still mged, just the project name -- it's a refactoring of mged's existing code from pure tcl to itcl |
| 22:30.33 | velociostrich | oooh |
| 22:30.42 | brlcad | main reason is that tcl/tk was adopted long before any of the modern toolkit's existed |
| 22:30.53 | velociostrich | Yeah, I assumed as much |
| 22:30.59 | brlcad | qt is on our horizon for archer's eventual replacement, couple years out on our planning schedule |
| 22:31.20 | velociostrich | Yeah, from and end-users' standpoint, Tk makes Archer/mged look dated unfortunately |
| 22:31.35 | velociostrich | I've noticed that most people are quick to judge a book by its cover |
| 22:31.37 | brlcad | still need to refactor more of mged's internal engine code down into lower library layers so the new GUI doesn't have to reinvent the wheel |
| 22:32.15 | brlcad | in all fairness, Tk can be made to look like most modern GUIs... it just takes a bit of effort to get off the defaults |
| 22:32.25 | velociostrich | perhaps |
| 22:32.32 | brlcad | we just use the defaults because there are more pressing engine matters to develop |
| 22:32.40 | velociostrich | I can understand that |
| 22:33.02 | velociostrich | Especially considering the KLOCs you guys have on your hands |
| 22:33.04 | brlcad | if you'd like to help in that regard (or library refactoring or whatever really), have at it |
| 22:33.14 | brlcad | lemme know how I can help you get started ;) |
| 22:33.16 | starseeker | archer is better that way than mged - we're mostly using the new tile/ttk widgets there |
| 22:33.19 | velociostrich | If only I had time, I would :/ |
| 22:33.45 | brlcad | you just need a mutual itch to scratch ;) |
| 22:33.58 | brlcad | a project that is interesting and tangible perhaps |
| 22:34.03 | velociostrich | And time |
| 22:34.33 | brlcad | time is merely a matter of priorities |
| 22:34.43 | brlcad | if you had that itch, some need, you'd scratch it |
| 22:34.53 | brlcad | because itchy things get scratched |
| 22:34.54 | brlcad | :) |
| 22:35.40 | velociostrich | You're damn right, now stop enticing me before my priorities go out of wack for a few weeks while I do that ;) |
| 22:35.54 | CIA-109 | BRL-CAD: 03tbrowder2 * r47565 10/brlcad/trunk/INSTALL.cmake: give a tad bit of help for a novice cmake builder; indent the configuration args to cmake; eliminate the old autotools stuff to eliminate confusion; show as a work in progress |
| 22:37.12 | velociostrich | Also, out of curiosity, do you know if the ARL still uses BRL-CAD, or have they abandoned it in favor of Autocad and friends? |
| 22:38.15 | brlcad | velociostrich: yep, still heavily used |
| 22:38.50 | brlcad | it's pretty much core business to the DoD for the foreseeable decade |
| 22:39.00 | velociostrich | interesting |
| 22:39.03 | velociostrich | likely with certain extras that the public won't ever see, though |
| 22:39.12 | velociostrich | namely extra ballistics bits |
| 22:39.38 | velociostrich | Which I assume was the point of it being solid geometry based and having the raytracing library and all that |
| 22:39.39 | brlcad | there are other CAD packages that have to interoperate with more these days than before, so strong focus on STEP import, for example, so we can bring in external CAD models without changing the representation format |
| 22:39.57 | brlcad | those extra ballistic bits aren't part of brl-cad, never have been |
| 22:40.24 | velociostrich | Yes, but would have used the raytracing library, correct? |
| 22:40.29 | brlcad | those bits call into our core libraries, which are built for exactly that purpose (and are still pretty much the best at it barnone) |
| 22:40.39 | velociostrich | Yes, that's what I meant |
| 22:41.56 | velociostrich | Y'know, that makes me wonder if perhaps brlcad's raytracing library might be well suited to the games industry; from what I understand AI makes heavy use of raytracing for pathfinding and such, and they claim it's quite expensive to compute |
| 22:42.16 | velociostrich | which I think is typically done using whatever partitioning scheme they're using |
| 22:42.29 | velociostrich | which is less than ideal |
| 22:42.30 | brlcad | it is very well suited for that purpose |
| 22:42.57 | brlcad | used within DoD by a couple groups playing wargames in that way (sorta) |
| 22:43.00 | CIA-109 | BRL-CAD: 03n_reed * r47566 10/brlcad/trunk/src/other/perplex/ (perplex.h scanner.re template.c): changed token text allocation scheme to be leak resistant |
| 22:48.17 | brlcad | starseeker: /home/sean/brlcad/src/libpkg/example/server.c:117:10: error: variable ?bytes? set but not used [-Werror=unused-but-set-variable] |
| 22:48.18 | CIA-109 | BRL-CAD: 03bob1961 * r47567 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Dynamically calculate the number of segments used to approximate circles and ellipses using the window size. |
| 22:48.53 | starseeker | brlcad: hang on - will be doing a commit in a sec anyhow |
| 22:54.03 | CIA-109 | BRL-CAD: 03starseeker * r47568 10/brlcad/trunk/src/libpkg/example/ (client.c server.c): Back to basics - don't worry about the file, just dirt simple back-and-forth. |
| 22:54.14 | starseeker | brlcad: convinced ;-) |
| 22:56.00 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 23:12.10 | starseeker | ok, I see why it was doing what it was doing, I think... |
| 23:12.41 | starseeker | brlcad: thanks for the print statement suggestion, that helped |
| 23:12.59 | starseeker | didn't realize it didn't break out of the while loop after completing the file transfer |
| 23:30.43 | *** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 23:35.38 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 23:43.08 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 01:48.23 | brlcad | starseeker: np |
| 02:06.58 | *** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 03:14.14 | CIA-109 | BRL-CAD: 03108.21.96.185 07http://brlcad.org * r3243 10/wiki/Category:Summer_of_Code: Google Money is Dirty Money |
| 03:26.53 | *** join/#brlcad abhi2011 (~chatzilla@117.200.86.187) | |
| 03:31.47 | CIA-109 | BRL-CAD: 03brlcad * r47569 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: (log message trimmed) |
| 03:31.47 | CIA-109 | BRL-CAD: basing the number of segments off of a chord length that's 5% of the view width |
| 03:31.47 | CIA-109 | BRL-CAD: will still create chunkly segments (50px long for a 1024 display) for large |
| 03:31.47 | CIA-109 | BRL-CAD: circles and sub-pixel chords for small circles (less than 20px). instead, try |
| 03:31.47 | CIA-109 | BRL-CAD: basing the size off of the circle's circumference in terms of pixels. this uses |
| 03:31.48 | CIA-109 | BRL-CAD: a chord length of 4px so the circles are always relatively smooth regardless of |
| 03:31.49 | CIA-109 | BRL-CAD: size. assumes from glancing through the logic that 'r' is actually the diameter |
| 03:33.44 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:108.21.96.185]] with an expiry time of infinite (anonymous users only, account creation disabled): Inserting nonsense/gibberish into pages |
| 03:33.54 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Category:Summer of Code]]": idiot |
| 03:35.37 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r3244 10/wiki/Category:Summer_of_Code: add some content |
| 03:42.48 | *** join/#brlcad yukonbob (~bch@S01064ce67640d81d.ok.shawcable.net) | |
| 03:42.52 | yukonbob | hello, #brlcad |
| 04:19.37 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.84.2) | |
| 04:53.59 | CIA-109 | BRL-CAD: 03abhi2011 * r47570 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h): Started adding air gap detection code. |
| 05:05.09 | CIA-109 | BRL-CAD: 03brlcad * r47571 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: there were two places a chord length was being calculated, one circular and one elliptical. looks like the diameter in this second section is the greater of the x or y delta. |
| 05:16.05 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 05:46.11 | abhi2011 | brlcad: setting rtip->useair = 1 is sufficient for getting air regions , reported as one of the hit regions ? |
| 06:20.37 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.84.2) | |
| 06:56.06 | abhi2011 | http://imageshack.us/photo/my-images/192/forcei.png/ |
| 06:57.02 | abhi2011 | no airgaps seem to be reported, there must some setting in the rt_i* I am missing |
| 06:58.54 | CIA-109 | BRL-CAD: 03abhi2011 * r47572 10/brlcad/trunk/src/libged/simulate/ (simrt.c simulate.c): Trying to convert the air regions to hit regions, so they are inserted in the hit regions list. |
| 11:14.32 | *** join/#brlcad merzo (~merzo@53-232-132-95.pool.ukrtel.net) | |
| 11:21.06 | *** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 12:16.09 | *** join/#brlcad abhi2011 (~chatzilla@117.200.90.203) | |
| 12:41.33 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.90.203) | |
| 13:28.04 | abhi2011 | SIGPIPE seems to be exposed to the windows compile : ..\..\..\..\brlcad\src\libpkg\example\server.c(221) : error C2065: 'SIGPIPE' : undeclared identifier |
| 13:31.18 | CIA-109 | BRL-CAD: 03abhi2011 * r47573 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simulate.c): Added initial code to detect and show air gaps. |
| 14:49.39 | *** join/#brlcad milamber1 (~devlin@d118-75-244-176.try.wideopenwest.com) | |
| 15:01.27 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.84.242) | |
| 15:50.18 | CIA-109 | BRL-CAD: 03abhi2011 * r47574 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h): Committing the logic for airgaps in case I need to use it later, before switching to the proper one using a_onehit = 0 |
| 16:11.06 | CIA-109 | BRL-CAD: 03starseeker * r47575 10/brlcad/trunk/src/libpkg/example/server.c: Windows doesn't like the SIGPIPE stuff. |
| 16:31.47 | abhi2011 | thanks |
| 16:31.54 | starseeker | np |
| 16:33.39 | abhi2011 | haha..not so fast |
| 16:33.45 | abhi2011 | more incoming : http://bin.cakephp.org/view/1415770574 |
| 16:33.48 | abhi2011 | :) :) |
| 16:34.58 | abhi2011 | this opengl linking thing seems to turn up in many places |
| 16:46.25 | starseeker | um |
| 16:48.01 | starseeker | ah - brlcad changed a lot of the variable names |
| 16:48.13 | starseeker | you may need to clean out your cache and re-run CMake |
| 17:01.31 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.84.242) | |
| 19:09.39 | abhi2011 | yep finally compile went ok |
| 19:31.52 | *** join/#brlcad yukonbob (~bch@S01060024a5c9dad4.ok.shawcable.net) | |
| 20:38.50 | brlcad | starseeker: caution on r47575, should understand what that does |
| 20:49.29 | CIA-109 | BRL-CAD: 03brlcad * r47576 10/brlcad/trunk/src/libpkg/example/CMakeLists.txt: there's no point in conditionalizing the BRLCAD_DLL compile flag. it's only used on Windows already. |
| 20:51.17 | CIA-109 | BRL-CAD: 03brlcad * r47577 10/brlcad/trunk/bench/CMakeLists.txt: more unnecessary conditionalization of preprocessor flags |
| 21:02.00 | CIA-109 | BRL-CAD: 03brlcad * r47578 10/brlcad/trunk/src/ (6 files in 6 dirs): more removal of unnecessary MSVC conditionalization for Windows. all of the MSVC sections outside of the very top-level CMakeLists.txt do not belong there, low-hanging poisoned fruit that should be gotten rid of. |
| 22:40.08 | CIA-109 | BRL-CAD: 03brlcad * r47579 10/brlcad/trunk/TODO.cmake: add two items. eliminate MSVC from non-top-level CMakeLists.txt files and add deprecation warnings. |
| 22:40.18 | starseeker | brlcad: I conditionalized BRLCAD_DLL to keep it out of the non-MSVC command lines in VERBOSE mode - intent was to avoid cluttering the gcc lines with non-functional stuff |
| 22:41.50 | starseeker | and removing some of the MSVC flags may get into other issues - like getting libpc working with Visual Studio... |
| 23:59.42 | CIA-109 | BRL-CAD: 03tbrowder2 * r47580 10/brlcad/trunk/HACKING.cmake: add references to Debian packages and Fedora rpms |
| 00:01.07 | CIA-109 | BRL-CAD: 03tbrowder2 * r47581 10/brlcad/trunk/doc/README.Linux: add info on Debian packages and Fedora rpms |
| 03:46.21 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 04:52.41 | *** join/#brlcad abhi2011 (~chatzilla@117.200.84.98) | |
| 05:03.02 | *** join/#brlcad Forth (~Forth@92.242.118.253) | |
| 05:03.45 | *** part/#brlcad Forth (~Forth@92.242.118.253) | |
| 06:15.27 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.92.64) | |
| 09:47.15 | *** join/#brlcad abhi2011 (~chatzilla@117.200.92.64) | |
| 09:48.37 | abhi2011 | hmm, the windows compile went fine, but mged seems to have lost its windows |
| 09:48.58 | abhi2011 | says libpng15d.dll is missing from your computer |
| 09:52.03 | abhi2011 | ok, its working now :) |
| 12:02.26 | *** join/#brlcad Forth (~Forth@92.242.118.253) | |
| 12:03.50 | *** part/#brlcad Forth (~Forth@92.242.118.253) | |
| 12:28.09 | *** join/#brlcad abhi2011 (~chatzilla@117.200.82.135) | |
| 12:30.53 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.82.135) | |
| 02:52.29 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 02:52.29 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 03:49.08 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 07:37.45 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 08:11.18 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 09:14.28 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 13:01.00 | *** join/#brlcad abhi2011 (~chatzilla@117.200.90.204) | |
| 13:58.00 | *** join/#brlcad abhi2011 (~chatzilla@117.200.88.113) | |
| 14:30.48 | *** join/#brlcad abhi2011 (~chatzilla@117.200.88.113) | |
| 14:44.31 | brlcad | starseeker: I know, and that was one of the points being made .. they're never "worth it" in the long run :) |
| 14:45.23 | brlcad | at least not when maintaining excessive portability (backwards and forewards) is the goal |
| 14:59.38 | brlcad | and it's worth saying that "it's all good" given past misinterpretations of ranting -- just a lot to say on the topic ;) |
| 15:12.49 | starseeker | do I undersdand you correctly that you want to change the conditionalized mechanism currently being used in the .h files? |
| 15:13.01 | starseeker | s/undersdand/understand |
| 15:13.07 | starseeker | kick brain into gear |
| 15:13.55 | starseeker | or just change how the CMake logic triggers it? |
| 15:19.16 | starseeker | is certainly in favor of excessive portability :-) - just not sure how that blasted import/export trick Windows needs can be made to play nicely |
| 15:21.12 | starseeker | both the shared library and executable targets currently need BRLCAD_DLL with MSVC, but if I understand correctly the static libraries *shouldn't* have it |
| 15:23.43 | CIA-109 | BRL-CAD: 03brlcad * r47582 10/brlcad/trunk/src/libbu/vls.c: |
| 15:23.43 | CIA-109 | BRL-CAD: it was an interesting idea, but not a great one. did a quick test to see how |
| 15:23.43 | CIA-109 | BRL-CAD: much time might be gained if we skipped the initial vls allocation. looked to |
| 15:23.43 | CIA-109 | BRL-CAD: be about 25% for bu_vls_printf() which is marginally interesting at best. |
| 15:23.43 | CIA-109 | BRL-CAD: probably not worth the complexity and long-term maintenance (error-prone), at |
| 15:23.44 | CIA-109 | BRL-CAD: least for now. |
| 15:23.57 | starseeker | which rules out any global setting of it, unless... perhaps we want to have toplevel BRLCAD_SHARED_COMPILE_FLAGS and BRLCAD_STATIC_COMPILE_FLAGS variables? |
| 15:32.18 | brlcad | starseeker: the .h files still are conditionalized, changing how cmake triggers |
| 15:41.35 | brlcad | probably don't need different flag variables |
| 15:43.25 | brlcad | if you conditionally set flags and add them (as vars), then those variables you add them to are implicitly conditionalized too |
| 15:45.15 | brlcad | I think the problem stems from the logic in bu.h presently only providing BU_EXPORT_DLL with no corresponding BU_IMPORT_DLL |
| 15:45.41 | brlcad | not export does not mean import .. e.g., when compiling static |
| 15:46.46 | brlcad | so that could simplify to a three-way if/elseif/else toggling on just those two variables -- then cmake has to set either BU_EXPORT_DLL or BU_IMPORT_DLL or neither |
| 15:48.19 | brlcad | with that, BRLCAD_DLL can go away and a cmake test is needed to determine whether __declspec(dllimport) works .. if it does, then variables get triggered |
| 15:51.45 | brlcad | if (dllimport_works) then LIBBU_CPPFLAGS+="-DBU_EXPORT_DLL" ; LIBBU_STATIC_CPPFLAGS+="..nada.." ; bu-using non-static apps CPPFLAGS+="-DBU_IMPORT_DLL" |
| 15:52.48 | brlcad | may need a layer of variables in there to avoid duplicating information all over the place but that's the gist in pseudocode |
| 16:40.41 | CIA-109 | BRL-CAD: 03brlcad * r47583 10/brlcad/trunk/NEWS: |
| 16:40.41 | CIA-109 | BRL-CAD: butler added an initial stab and providing ambient occlusion to rt. this is |
| 16:40.41 | CIA-109 | BRL-CAD: presently disabled by default and enabled with the ambSamples and ambRadius rt |
| 16:40.41 | CIA-109 | BRL-CAD: variables. more work is needed on controlling the sample pattern and noise. |
| 16:42.23 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 17:43.04 | CIA-109 | BRL-CAD: 03n_reed * r47584 10/brlcad/trunk/doc/bison_to_lemon.txt: more on assigning types to symbols |
| 17:45.49 | CIA-109 | BRL-CAD: 03n_reed * r47585 10/brlcad/trunk/src/other/perplex/ (scanner.re template.c): don't allocate new token string without freeing existing string |
| 18:04.28 | CIA-109 | BRL-CAD: 03n_reed * r47586 10/brlcad/trunk/src/other/perplex/ (parser.y scanner.re): fix separator pattern; properly close output scanner |
| 18:26.59 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 19:30.09 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 19:55.47 | *** join/#brlcad Forth (~Forth@92.242.118.253) | |
| 19:57.53 | *** part/#brlcad Forth (~Forth@92.242.118.253) | |
| 20:13.07 | CIA-109 | BRL-CAD: 03n_reed * r47587 10/brlcad/trunk/src/other/perplex/ (Makefile.local perplex.h scanner.re template.c): fixed start condition initialization; removed requirement for EOF rule in input |
| 20:27.47 | brlcad | starseeker: n_reed: e-mail sent, assistance requested |
| 20:28.04 | *** join/#brlcad merzo (~merzo@19-255-132-95.pool.ukrtel.net) | |
| 21:25.33 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 22:46.58 | *** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 22:47.18 | *** part/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 22:53.09 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 00:20.33 | *** part/#brlcad milamber (~devlin@d118-75-244-176.try.wideopenwest.com) | |
| 01:12.10 | *** join/#brlcad n_reed (~nreed1@c-68-55-142-136.hsd1.md.comcast.net) | |
| 01:52.53 | *** join/#brlcad CIA-61 (~CIA@cia.atheme.org) | |
| 05:27.54 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 05:53.49 | brlcad | wanders into the night |
| 06:20.29 | n_reed | observes the night from a safe distance |
| 12:35.23 | starseeker | slept through the night... |
| 12:35.46 | starseeker | hangs head in shame |
| 14:46.49 | *** part/#brlcad n_reed (~nreed1@c-68-55-142-136.hsd1.md.comcast.net) | |
| 15:21.36 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:49.15 | CIA-61 | BRL-CAD: 03indianlarry * r47588 10/brlcad/trunk/src/conv/CMakeLists.txt: Wrapped ON_DLL_IMPORTS definition for MSVC only. |
| 17:01.09 | CIA-61 | BRL-CAD: 03brlcad * r47589 10/brlcad/trunk/TODO: looks like twist is also not an option, so make sure we can set the size and rotation |
| 17:07.02 | CIA-61 | BRL-CAD: 03brlcad * r47590 10/brlcad/trunk/TODO: uv callback missing for BoT, NMG, and BREP |
| 17:10.45 | starseeker | brlcad: if I'm understanding correctly (re: understanding r47575) ignoring SIGPIPE is what allows the server to keep running when a pipe connection unexpectedly dies? |
| 17:11.01 | starseeker | so not having it means a client misbehaving can take down the server? |
| 17:11.15 | starseeker | what would be the cross-platform solution? |
| 17:32.05 | ``Erik | I think that'd be more for the servers shell being jerked out from under it, like if your ssh dropped... not a socket issue |
| 17:42.51 | CIA-61 | BRL-CAD: 03bob1961 * r47591 10/brlcad/trunk/src/libdm/ (dm-ogl.c dm-wgl.c): Ignore if less than 2 points. |
| 17:54.53 | CIA-61 | BRL-CAD: 03n_reed * r47592 10/brlcad/trunk/ (doc/docbook/system/man1/en/obj-g.xml src/conv/obj-g.c): add r option to obj-g for setting orientation on imported bots |
| 17:59.17 | CIA-61 | BRL-CAD: 03bob1961 * r47593 10/brlcad/trunk/ (4 files in 3 dirs): Add polygon contour mode for specifying arbitrary polygonal contours. |
| 17:59.19 | *** join/#brlcad merzo (~merzo@72-4-133-95.pool.ukrtel.net) | |
| 18:07.57 | CIA-61 | BRL-CAD: 03bob1961 * r47594 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Change the number of segments calculation to reflect the fact that "r" is the radius. |
| 18:26.19 | CIA-61 | BRL-CAD: 03starseeker * r47595 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_Util.cmake): |
| 18:26.19 | CIA-61 | BRL-CAD: Ah - the '-' to '_' conversion ended up with BRLCAD_BUNDLED_LIBS being listed in |
| 18:26.19 | CIA-61 | BRL-CAD: its own alias list. That exposes two problems - one it doesn't need to list |
| 18:26.19 | CIA-61 | BRL-CAD: itself as an alias, and two the macro shouldn't be treating it as an alias when |
| 18:26.19 | CIA-61 | BRL-CAD: it's the actual variable (Bad Things happen.) |
| 19:05.49 | CIA-61 | BRL-CAD: 03indianlarry * r47596 10/brlcad/trunk/include/rtgeom.h: magic for solid type 'uint32_t ' not 'unsigned long', 'brep' debug command was broken where long not 32bit |
| 19:22.14 | CIA-61 | BRL-CAD: 03bob1961 * r47597 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Update bindings for the top and bottom views to match MGED. |
| 19:22.19 | CIA-61 | BRL-CAD: 03starseeker * r47598 10/brlcad/trunk/src/libpkg/example/server.c: put SIGPIPE ignore back in, wrapping it this time for platforms that don't define it (Windows) |
| 19:23.41 | CIA-61 | BRL-CAD: 03starseeker * r47599 10/brlcad/trunk/src/libpkg/tpkg.c: tpkg should be checking for SIGPIPE too... |
| 19:35.57 | *** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 20:18.22 | CIA-61 | BRL-CAD: 03bob1961 * r47600 10/brlcad/trunk/ (include/ged.h src/libtclcad/tclcad_obj.c): Change matp_t members of ged_data_polygon_state to mat_t. Added gdps_rotation and gdps_origin to ged_data_polygon_state. Getting ready to export ged_polygons to sketches. |
| 20:29.41 | CIA-61 | BRL-CAD: 03bob1961 * r47601 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: The number of segments calculations for circles and ellipses needs to be scaled by gv_scale because "r" is in view coordinates. Also set a minimum for the number of segments. |
| 20:49.01 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 20:57.28 | CIA-61 | BRL-CAD: 03starseeker * r47602 10/brlcad/trunk/include/bu.h: Stub in an example for how the new declspec ifdef will look... |
| 21:05.53 | CIA-61 | BRL-CAD: 03starseeker * r47603 10/brlcad/trunk/ (3 files in 2 dirs): Start preparing to use some kind of test for the declspec import/export flags - sub in a variable instead of MSVC platform conditional. |
| 21:08.26 | starseeker | brlcad: was that example more what you were looking for (bu.h) |
| 21:14.54 | CIA-61 | BRL-CAD: 03starseeker * r47604 10/brlcad/trunk/src/ (libged/CMakeLists.txt other/clipper/clipper.hpp): Try a localized test with libged and clipper... |
| 21:17.57 | starseeker | brlcad: should timer-nt and timer42 in librt be folded back into libbu's timer? |
| 21:25.21 | ``Erik | has thought about doing that recently |
| 21:29.39 | starseeker | probably should be done if we're going to remove the MSVC conditional pertaining to them... |
| 01:19.35 | brlcad | starseeker: you still have to check if BU_EXPORTS is defined, else you can end up with a double-definition error |
| 01:19.55 | brlcad | er, BU_EXPORT |
| 01:22.37 | brlcad | the plural naming convention you pulled from opennurbs doesn't really apply to C code too (wasn't even necessary for opennurbs really, they're all the same macro) |
| 01:23.23 | brlcad | that one's not a big deal, of course, just not necessary |
| 01:24.20 | brlcad | maybe better to keep it consistent with opennurbs, that's fine too |
| 01:44.19 | CIA-61 | BRL-CAD: 03brlcad * r47605 10/brlcad/trunk/include/bu.h: make sure BU_EXPORT isn't already defined (so callers have some means to override), and error out if caller tries to import and export simultaneously. |
| 01:45.28 | CIA-61 | BRL-CAD: 03starseeker * r47606 10/brlcad/trunk/src/other/clipper/CMakeLists.txt: tweak clipper dll CMake logic. |
| 01:46.12 | starseeker | brlcad: this still feels funny to me somehow - explicitly calling out the import with a library specific flag, rather than using the more "global" BRLCAD_DLL seems to complicate the build logic quite a bit... |
| 01:46.14 | brlcad | that template should work well, how's it look? |
| 01:48.24 | brlcad | it does complicate matters some given each library has to be listed now, that was to be expected |
| 01:48.43 | brlcad | the problem and benefit of BRLCAD_DLL is that it was global |
| 01:48.59 | starseeker | brlcad: don't we still need that last else case with the empty BU_EXPORT ? |
| 01:49.03 | brlcad | it effectively meant *_IMPORT_DLL |
| 01:49.23 | starseeker | nods - finding myself thinking that wasn't such a bad idea, really... |
| 01:50.17 | brlcad | it's not a terrible idea but there are some downsides |
| 01:50.39 | brlcad | can't make a target that both exports and imports (plugins, libraries) |
| 01:51.22 | starseeker | brlcad: the "check for both definitions" case - will the logic ever get there? |
| 01:51.26 | brlcad | also means that there's cross-library pollution which prevents core library components from standing on their own |
| 01:51.29 | starseeker | shouldn't we be checking for that first? |
| 01:51.34 | brlcad | e.g., a libbu distribution akin to apr |
| 01:52.27 | brlcad | yeah, you're right |
| 01:52.31 | brlcad | on both counts |
| 01:52.57 | starseeker | one sec.. |
| 01:53.40 | brlcad | already fixed |
| 01:53.43 | CIA-61 | BRL-CAD: 03brlcad * r47607 10/brlcad/trunk/include/bu.h: starseeker right on both counts, need the empty BU_EXPORT so preprocessor makes the symbol go away and the error case needs to be tested first |
| 01:53.52 | CIA-61 | BRL-CAD: 03starseeker * r47608 10/brlcad/trunk/src/other/clipper/clipper.hpp: Upgrade the export macro logic for clipper (hopefully)... |
| 01:54.46 | starseeker | do we need BU_DLL_IMPORTS for a library that just links to librt? |
| 01:56.15 | brlcad | I don't remember the dll import/export rules that closely but I believe it depends how the library is defined |
| 01:56.38 | starseeker | mm. Well, I guess there's always the "try it and see" approach... |
| 01:56.41 | brlcad | if librt imports bu/bn and exports it's symbols, then I *think* it'll look for their dll when librt is loaded |
| 01:56.55 | starseeker | guess I'll be playing with the windows build again tomorrow (joy...) |
| 01:57.08 | brlcad | if it doesn't import, they get linked static and have to be resolved at compile time |
| 01:57.50 | starseeker | is trying to decide if librt should define an RT_DEFINES variable that holds BU_DLL_IMPORTS, BN_DLL_IMPORTS, etc... |
| 01:58.51 | brlcad | to do it "proper", I believe so |
| 01:59.25 | brlcad | rather, it needs to have them defined when librt is compiled .. but not necessarily when rt is compiled |
| 01:59.45 | brlcad | (but can) |
| 02:00.54 | brlcad | it needs them when rt is compiled if librt doesn't import them or if it also uses bu/bn too (which it does) |
| 02:02.08 | starseeker | needs to think tactically about how to set this up... would *really* suck to have to specify defines for executables per-exec instead of per directory |
| 02:03.53 | starseeker | probably need to for exec targets in the same directory as a library (test apps, etc.) since I can't go defining both, but (say) in util I would prefer to "define 'em all and let the compiler sort it out", so to speak |
| 02:12.14 | brlcad | starseeker: how about in a/the exec wrapper macro, have it look for variables matching the provided prefix -- then it's a naming convention all our libs use to define their vars in one place |
| 02:12.43 | starseeker | you mean use the library list to go after the variables? |
| 02:13.07 | starseeker | might work, except when we send in libraries that aren't ours... |
| 02:13.14 | brlcad | something like BUILD_MY_EXEC(rt, LIBRT LIBBN LIBBU) |
| 02:13.38 | starseeker | nods - BRLCAD_EXEC already has most of that |
| 02:13.46 | brlcad | which would then look for LIBRT_LIBS, LIBRT_CPPFLAGS, LIBRT_CFLAGS, LIBBN_LIBS, LIBBN_CPPFLAGS, LIBBN_CFLAGS, etc |
| 02:14.01 | starseeker | come to think of it... |
| 02:14.30 | starseeker | yeah, there might be a way to handle it there |
| 02:14.39 | starseeker | will look into it tomorrow |
| 02:14.51 | brlcad | LIBRT_LDFLAGS might be different from LIBRT_LIBS |
| 02:15.07 | brlcad | -lrt vs deps -lbn -lbu -ltcl ... |
| 02:15.19 | starseeker | cmake uses full paths for most things |
| 02:15.37 | starseeker | I can recognize when I'm looking at a full path (do so for the distcheck logic) |
| 02:15.49 | brlcad | path isn't the issue |
| 02:16.09 | brlcad | it's what libraries are added to the link line (and in what order if you want to get pedantic) |
| 02:16.26 | starseeker | I was thinking to use the list of libraries passed to BRLCAD_EXEC |
| 02:17.09 | starseeker | couple ideas, actually |
| 02:17.10 | brlcad | right, but then if libraries are self-aware of their dependencies (and they are) |
| 02:17.31 | brlcad | then you wouldn't need to specify all the (potential) dependencies any time a library is used |
| 02:17.58 | brlcad | like my example above -- kind of silly to list libbn and libbu since librt requires them |
| 02:18.11 | starseeker | oh, I see... |
| 02:18.14 | starseeker | different issue |
| 02:18.16 | brlcad | I couldv'e queried a var set by librt that told me bn, bu, etc |
| 02:18.36 | brlcad | that could greatly reduce redundancy throughout the build files |
| 02:19.06 | starseeker | nods... again less explicit though |
| 02:19.55 | brlcad | yet less error-prone too |
| 02:20.20 | brlcad | most devs don't think very long about what the actual libs are, they copy-paste another similar and add libs until it compiles |
| 02:20.40 | starseeker | true... the way we're trending here though, I'm going to *have* to write up some sort of detailed overview of what we're doing and why |
| 02:21.42 | starseeker | granting there are usually good reasons for what's being done, the further we get from "vanilla" the greater the hurdles become for a newbie to figure out what's happening and why |
| 02:22.08 | brlcad | already warranted with any custom macro -- it's obvious to you now because you wrote it and you still remember |
| 02:22.19 | starseeker | right |
| 02:22.38 | starseeker | in fact, for a lot of reasons I'd *better* do it now |
| 02:22.51 | starseeker | 's memory is... quirky |
| 02:23.13 | brlcad | might let you clean out some unnecessary macros too if you attempt to document them :) |
| 02:23.24 | brlcad | "oh yeah .. no longer need this one" |
| 02:23.48 | starseeker | heh - one of the fundamental arguments for literate programming, actually - "if I have to explain to a human what I'm trying to do, it's hard to hide the stupid parts :-P" |
| 02:24.00 | brlcad | it actually looks like you already do some sort of lib dependency expansion in BRLCAD_ADDEXEC |
| 02:24.32 | starseeker | uh... where are you looking? |
| 02:24.45 | brlcad | just looking at some binaries |
| 02:24.53 | brlcad | src/rt/CMakeLists.txt for example |
| 02:25.04 | brlcad | no mention of libbu, but guarantee they all use it |
| 02:25.29 | starseeker | actually that's probably just dumb luck |
| 02:25.35 | brlcad | heh |
| 02:25.53 | brlcad | enfeeds |
| 02:26.43 | starseeker | that list is passed pretty much as-is to target_link_libraries - did it mainly because it cut a few hundred add_executable/target_link_libraries/install triplets down to a one-liner |
| 02:27.10 | starseeker | s/a one-liner/one-liners/ |
| 02:27.20 | starseeker | yeah, gotta get outta here |
| 02:34.59 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 03:14.39 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 04:13.23 | CIA-61 | BRL-CAD: 03brlcad * r47609 10/brlcad/trunk/NEWS: nick added a new -r orientation option for the obj-g importer so you can specify 1/2/3 as values for unoriented, ccw, and cw orientation. |
| 05:26.30 | brlcad | starseeker: then I'd wonder if cmake is doing some expansion for us since the libs deps are listed with the libs and it expands correctly |
| 05:26.48 | brlcad | either way, somehow it's happening now, so that's a good sign |
| 05:27.12 | brlcad | installs cmake on gcc12 (openbsd sparc64) |
| 06:26.23 | *** join/#brlcad milamber (~devlin@d118-75-244-176.try.wideopenwest.com) | |
| 07:42.45 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 11:50.28 | CIA-61 | BRL-CAD: 03erikgreenwald * r47610 10/brlcad/trunk/include/bu.h: add missing #endif |
| 12:12.02 | ``Erik | hm, anne mccaffrey passed |
| 12:13.06 | ``Erik | doom3 source released, too |
| 13:36.21 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 16:37.07 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 16:37.07 | *** join/#brlcad 77CAA2ALN (~Technicus@DSLPool-net208-2.wctc.net) | |
| 16:59.53 | CIA-61 | BRL-CAD: 03brlcad * r47611 10/brlcad/trunk/HACKING: gentoo folks moved brl-cad from sci-misc to media-gfx |
| 17:32.32 | brlcad | starseeker: any technical reason for the lack of blank lines in the cmake files? |
| 17:33.17 | starseeker | uh... not really |
| 17:33.31 | brlcad | k |
| 17:34.04 | starseeker | can't think of any offhand, although there may be a few cases where it matters (messages can't have stray end-of-line characters, for example...) |
| 17:34.29 | starseeker | or rather, they can but it messes with the formatting of the printed result |
| 17:41.19 | brlcad | that's fine, it's more whether there was some reason the logic or macros prohibited it |
| 17:42.37 | brlcad | like a C file without blank lines, a bit of a readability hindrance |
| 18:12.40 | CIA-61 | BRL-CAD: 03brlcad * r47612 10/brlcad/trunk/misc/CMake/ (BRLCAD_CompilerFlags.cmake CompilerFlags.cmake): relax the comparisons to substring matches |
| 18:14.22 | CIA-61 | BRL-CAD: 03brlcad * r47613 10/brlcad/trunk/CMakeLists.txt: similar, relax string comparisons. makes the unknown value test a little more robust |
| 18:18.12 | CIA-61 | BRL-CAD: 03brlcad * r47614 10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake: trying to make some sense of the logic, add ws for readability |
| 18:29.43 | CIA-61 | BRL-CAD: 03brlcad * r47615 10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake: simplify logic with relaxed substring searching |
| 18:41.02 | CIA-61 | BRL-CAD: 03brlcad * r47616 10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake: more logic simplification. reorder IF/ELSE to avoid needing NOT, eliminate need for multiple comparisons by using substring comparison. reword cache string to indicate what action is being taken. |
| 18:42.44 | CIA-61 | BRL-CAD: 03starseeker * r47617 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: |
| 18:42.44 | CIA-61 | BRL-CAD: Make an initial stab at support for library-wide usage of <LIB>_DLL_IMPORTS |
| 18:42.44 | CIA-61 | BRL-CAD: approach to building with MSVC. This is just hte macro logic and (for the |
| 18:42.44 | CIA-61 | BRL-CAD: moment, until the rest of this is worked out) the Windows build is almost |
| 18:42.44 | CIA-61 | BRL-CAD: certainly well and truly busted. |
| 18:48.13 | CIA-61 | BRL-CAD: 03starseeker * r47618 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: remove debug prints for now. |
| 18:48.38 | CIA-61 | BRL-CAD: 03brlcad * r47619 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: |
| 18:48.39 | CIA-61 | BRL-CAD: big restructuring in support of better reporting for whether bundled or sys libs |
| 18:48.39 | CIA-61 | BRL-CAD: are being used (and why). few cases weren't being handled and the string |
| 18:48.39 | CIA-61 | BRL-CAD: STREQUAL testing was causing cmake to report warnings. simplify string |
| 18:48.39 | CIA-61 | BRL-CAD: comparisons to substrings where applicable, reduce/reorder logic for clarity, |
| 18:48.39 | CIA-61 | BRL-CAD: and reword messages for consistency. |
| 18:52.33 | CIA-61 | BRL-CAD: 03starseeker * r47620 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: stray duplicate comment line |
| 19:01.05 | CIA-61 | BRL-CAD: 03brlcad * r47621 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: |
| 19:01.06 | CIA-61 | BRL-CAD: sync up with the same that was done for ThirdParty_Tcl.cmake using consistent |
| 19:01.06 | CIA-61 | BRL-CAD: printing statements (e.g., they might not be libs), relax to substring matching |
| 19:01.06 | CIA-61 | BRL-CAD: and reduced logic where we can. inject blank lines, separators, and comments |
| 19:01.06 | CIA-61 | BRL-CAD: for improved readabaility. |
| 19:09.19 | CIA-61 | BRL-CAD: 03starseeker * r47622 10/brlcad/trunk/include/ (22 files): Convert all the include headers to the <LIB>_DLL_IMPORTS format |
| 19:15.34 | CIA-61 | BRL-CAD: 03brlcad * r47623 10/brlcad/trunk/misc/CMake/ (33 files): |
| 19:15.34 | CIA-61 | BRL-CAD: as these are build system infrastructure and not actual build rules, they should |
| 19:15.34 | CIA-61 | BRL-CAD: include the requisite license headers and footers like any other source file. |
| 19:15.34 | CIA-61 | BRL-CAD: CMakeLists.txt don't need the wrapping, but macro files should |
| 19:26.11 | starseeker | brlcad: uh... - a lot of those Find* cmake macro files are based on other macro files, might want to be careful |
| 19:26.43 | starseeker | I'd have to dig back to make sure, but I think at least FindGL, FindX11 and FindYACC are based off of other macros |
| 19:27.02 | starseeker | I was waiting until things settled to do a thorough review of all of that |
| 19:38.47 | CIA-61 | BRL-CAD: 03brlcad * r47624 10/brlcad/trunk/autogen.sh: given the magnitude of impact, add a massive deprecation notice to begin our requisite deprecation notification process. refer them to the INSTALL file for now since there's not (yet?) an equivalent step |
| 19:39.23 | ``Erik | is seeing tons of cmake breakage right now, http://paste.lisp.org/display/126045 |
| 19:39.48 | brlcad | legally, that needs to happen asap and should have happened before a release was made with them |
| 19:40.17 | starseeker | k - I'll do a scan-through |
| 19:41.21 | brlcad | if they are mererly bundled for convenience, our header should be pulled or appended after theirs |
| 19:41.36 | starseeker | most of them are tweaked |
| 19:41.52 | starseeker | maybe all of them |
| 19:45.34 | brlcad | if it's not significant (like no logic changes, just additions of paths, removal of code, or just a couple lines) then our header is arguably not necessary |
| 19:47.19 | brlcad | ``Erik: your build failure looks related to r47617, work in progress .. though my build curiously worked, maybe I need to wipe cache to hit it |
| 19:47.58 | CIA-61 | BRL-CAD: 03starseeker * r47625 10/brlcad/trunk/misc/CMake/ (BRLCAD_Util.cmake CheckCFileRuns.cmake): Add the full license text for ChechCFileRuns.cmake - need to fix up the rest of the Kitware-based files to have the full BSD license txt. |
| 19:51.05 | brlcad | starseeker: do they use the same 3-clause license? |
| 19:53.03 | brlcad | if they do, there can just be 2 copyright lines instead of two copies of the text |
| 19:53.07 | starseeker | I believe so, give or take some minor wording and formatting... |
| 19:53.19 | starseeker | take a look at CheckCFileRuns.cmake, it's got both |
| 19:54.06 | CIA-61 | BRL-CAD: 03starseeker * r47626 10/brlcad/trunk/misc/CMake/CheckPrototypeExists.cmake: CheckPrototypeExists.cmake is from KDE, flesh out their BSD license and add a link to the file origin |
| 19:59.30 | CIA-61 | BRL-CAD: 03brlcad * r47627 10/brlcad/trunk/autogen.sh: move the deprecation section down so we're more sure echo -n work. still before anything is printed. |
| 20:00.51 | CIA-61 | BRL-CAD: 03starseeker * r47628 10/brlcad/trunk/misc/CMake/FindLEMON.cmake: FindLEMON was originally based on FindBISON - note that fact. Trying to stay close to the formatting of 'standard' CMake modules for those that we might have a hope of getting accepted into CMake proper at some point. |
| 20:03.11 | CIA-61 | BRL-CAD: 03starseeker * r47629 10/brlcad/trunk/misc/CMake/FindLEX.cmake: FindLEX.cmake is basically FindFLEX.cmake slightly generalized, and we already had ourselves listed in the 'standard' CMake BSD license. We may not even need this at all once the perplex/re2c/lemon work is complete... |
| 20:04.07 | starseeker | mutter... looks like I got some of them "properly" containing the full license, but missed a few |
| 20:04.44 | starseeker | I think in the GL/X11 case I might have been hoping to get the changes accepted back... ah well, no matter |
| 20:08.22 | CIA-61 | BRL-CAD: 03starseeker * r47630 10/brlcad/trunk/misc/CMake/ (FindGL.cmake FindX11.cmake FindZLIB.cmake): Add the rest of the 'full' licenses for the Kitware stuff - was hoping to commit these changes back to Kitware, but either way we'll have to hang on to these until we can require a modern enough CMake with the changes. |
| 20:15.29 | CIA-61 | BRL-CAD: 03brlcad * r47631 10/brlcad/trunk/configure.ac: add a similar massive deprecation notice with an annoying pause to configure. |
| 20:18.38 | CIA-61 | BRL-CAD: 03brlcad * r47632 10/brlcad/trunk/configure.ac: put a deprecation notice in the summary too since most people actually read it. |
| 20:23.06 | CIA-61 | BRL-CAD: 03brlcad * r47633 10/brlcad/trunk/Makefile.am: last one, repeat the deprecation warning when they run autotools make too. |
| 20:58.01 | CIA-61 | BRL-CAD: 03brlcad * r47634 10/brlcad/trunk/src/rt/view.c: |
| 20:58.01 | CIA-61 | BRL-CAD: can't compile due to cmake errors, but add an ambOffset parameter so you can |
| 20:58.01 | CIA-61 | BRL-CAD: control how far we pull away from a surface before shooting ambient rays. this |
| 20:58.01 | CIA-61 | BRL-CAD: is intended to help 'smooth out' shots against polygonal models where you get |
| 20:58.01 | CIA-61 | BRL-CAD: artifacts from hitting nearby/neighboring polygons. |
| 20:58.09 | starseeker | reflects that with the new open source SCL activity, he's probably going to need to beef up the FindSCL macro... |
| 21:02.04 | CIA-61 | BRL-CAD: 03brlcad * r47635 10/brlcad/trunk/src/rt/view.c: reduce the code duplication in ambient occlusion. pulling the branch out of both loops is inconsequential to performance in the long term. |
| 21:02.45 | CIA-61 | BRL-CAD: 03starseeker * r47636 10/brlcad/trunk/ (9 files in 9 dirs): This should get the build working again on non Windows platforms... also, start the process of clearing out BRLCAD_DLL |
| 21:04.18 | starseeker | brlcad: something else is busted - LEMON_EXECUTABLE is set to NOTFOUND |
| 21:06.10 | starseeker | and the global BRLCAD_BUNDLED_LIBS flag being set to bundled isn't turning everything on anymore |
| 21:20.18 | brlcad | curious, I didn't modify FindLEMON |
| 21:21.15 | brlcad | the BRLCAD_BUNDLED_LIBS isn't too surprising, couldn't test it with the breakage and the logic in BRLCAD_Util seems quite a mess.. |
| 21:40.14 | brlcad | looks like the problem is actually in ThirdParty, fix forthcoming |
| 21:42.22 | CIA-61 | BRL-CAD: 03bob1961 * r47637 10/brlcad/trunk/include/ged.h: Added gdps_scale to ged_data_polygon_state. |
| 21:52.05 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 21:58.59 | CIA-61 | BRL-CAD: 03brlcad * r47638 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: getting a feel for how the aggregate BRLCAD_BUNDLED_LIBS was implemented. this makes ccmake report proper propagation of the parent BUNDLED (AUTO) setting (but still keying off AUTO at higher precedence than BUNDLED). |
| 22:35.56 | CIA-61 | BRL-CAD: 03brlcad * r47639 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: |
| 22:35.57 | CIA-61 | BRL-CAD: this seems to get things back to working for the parent BRLCAD_BUNDLED_LIBS |
| 22:35.57 | CIA-61 | BRL-CAD: option. wasn't accounting for a stray STREQUAL in the parent logic and wasn't |
| 22:35.57 | CIA-61 | BRL-CAD: setting the ON/OFF variable consistently with the statements being printed |
| 22:48.01 | CIA-61 | BRL-CAD: 03brlcad * r47640 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: |
| 22:48.01 | CIA-61 | BRL-CAD: if BRLCAD_BUNDLED_LIBS is set to SYSTEM and system-installed libs aren't |
| 22:48.01 | CIA-61 | BRL-CAD: available, it's not our problem -- let them proceed as if it was installed and |
| 22:48.01 | CIA-61 | BRL-CAD: found since that's what they asked for. perhaps useful for distribution |
| 22:48.01 | CIA-61 | BRL-CAD: debugging. |
| 22:52.34 | CIA-61 | BRL-CAD: 03brlcad * r47641 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: mark BRLCAD_LIBS as advanced |
| 23:16.09 | CIA-61 | BRL-CAD: 03brlcad * r47642 10/brlcad/trunk/src/other/ (re2c/CMake/FindLEMON.cmake step/CMake/FindLEMON.cmake): sync top-level cmake file |
| 23:46.32 | CIA-61 | BRL-CAD: 03starseeker * r47643 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: LIBRARY->EXECUTABLE |
| 00:15.42 | CIA-61 | BRL-CAD: 03starseeker * r47644 10/brlcad/trunk/misc/CMake/CheckCFileRuns.cmake: Tweak CheckCFileRuns.cmake |
| 00:20.28 | CIA-61 | BRL-CAD: 03starseeker * r47645 10/brlcad/trunk/misc/CMake/distcheck_buildsys.cmake.in: Add header and footer to core distcheck file checking logic |
| 00:24.51 | CIA-61 | BRL-CAD: 03starseeker * r47646 10/brlcad/trunk/misc/CMake/ResolveCompilerPaths.cmake: Not our file - revert copyright statement |
| 00:26.13 | CIA-61 | BRL-CAD: 03starseeker * r47647 10/brlcad/trunk/misc/CMake/ (BRLCAD_Util.cmake util_macros.cmake): Not only is it not ours, it doesn't apper to be used anywhere. Just clear it until there's a clear need. |
| 02:08.43 | CIA-61 | BRL-CAD: 03starseeker * r47648 10/brlcad/trunk/ (5 files in 4 dirs): (log message trimmed) |
| 02:08.43 | CIA-61 | BRL-CAD: Get the build working again. Interestingly, the new approach to defines appears |
| 02:08.43 | CIA-61 | BRL-CAD: to actually have beneficial DRY consequences even beyond MSVC - the display |
| 02:08.43 | CIA-61 | BRL-CAD: manager definitions needed for libdm had been required in libtclcad and mged as |
| 02:08.43 | CIA-61 | BRL-CAD: well, but now they automatically inherit libdm's settings. Which means we can't |
| 02:08.43 | CIA-61 | BRL-CAD: cheat by defining something for a library and then defining that same flag |
| 02:08.44 | CIA-61 | BRL-CAD: differently when compiling an app that uses that library, but on the whole an |
| 02:38.05 | CIA-61 | BRL-CAD: 03starseeker * r47649 10/brlcad/trunk/ (5 files in 5 dirs): Do a little more reworking of local defines - also make the ADD_DEFS routines more robust/cleaner. |
| 02:49.53 | CIA-61 | BRL-CAD: 03starseeker * r47650 10/brlcad/trunk/ (3 files in 3 dirs): rename, add a utility macro for easer testing/assignment of defines without lists... |
| 02:49.57 | starseeker | nifty |
| 03:43.35 | CIA-61 | BRL-CAD: 03louipc * r47651 10/brlcad/trunk/misc/archlinux/PKGBUILD: |
| 03:43.35 | CIA-61 | BRL-CAD: Update PKGBUILD... |
| 03:43.35 | CIA-61 | BRL-CAD: Uses package function |
| 03:43.35 | CIA-61 | BRL-CAD: Update dependencies |
| 03:43.35 | CIA-61 | BRL-CAD: Use cmake for configuration. |
| 03:43.36 | CIA-61 | BRL-CAD: Trim comments. |
| 04:30.49 | louipc | sourceforge doesn't allow svn access via ssh? |
| 05:00.57 | CIA-61 | BRL-CAD: 03starseeker * r47652 10/brlcad/trunk/src/libged/simulate/simrt.c: Hmm - gentoo build didn't like TRUE and FALSE... |
| 05:57.01 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 08:00.28 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 12:52.24 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 13:03.25 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 13:13.29 | ``Erik | louipc: they do, but you need to upload your keys via their web interface and wait for propogation |
| 13:13.51 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 13:26.12 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 13:47.10 | *** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 14:24.22 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 19:32.52 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 19:35.04 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 20:48.17 | *** join/#brlcad yukonbob (~bch@70.97.16.199) | |
| 20:48.21 | yukonbob | hello, #brlcad |
| 22:46.28 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 23:17.39 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 23:17.39 | *** join/#brlcad CIA-61 (~CIA@cia.atheme.org) | |
| 23:17.39 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 23:17.39 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 23:17.39 | *** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 23:17.39 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 23:17.39 | *** join/#brlcad bhinesley (~bhinesley@99.52.241.103) | |
| 23:17.39 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 23:17.39 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 23:17.39 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 23:17.39 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 23:17.40 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 23:17.40 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 23:17.40 | *** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 23:17.40 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 23:17.40 | *** join/#brlcad louipc (~louipc@archlinux/fellow/louipc) | |
| 23:17.40 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 23:17.40 | *** mode/#brlcad [+o ChanServ] by kornbluth.freenode.net | |
| 23:39.43 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 00:40.02 | louipc | ``Erik: yeah I did that a ages ago. What's the path to the repo for that? |
| 01:18.29 | *** join/#brlcad yukonbob (~bch@50.46.245.87) | |
| 01:18.32 | yukonbob | hello, #brlcad |
| 01:26.23 | starseeker | hello yukonbob |
| 01:27.38 | yukonbob | hai |
| 01:28.18 | yukonbob | have you ever heard of (or better, know of) "weird" renderers for brlcad, ie: toon shader, or "8 bit", or other fx like that? |
| 01:38.55 | yukonbob | tracks core dumps. |
| 02:01.56 | CIA-61 | BRL-CAD: 03starseeker * r47653 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/CMakeFiles.cmake): Move macro out of toplevel CMakeLists.txt file |
| 02:05.13 | CIA-61 | BRL-CAD: 03starseeker * r47654 10/brlcad/trunk/CMakeLists.txt: not using the contents of the VARIABLES setting - remove this macro and calls |
| 03:46.10 | CIA-61 | BRL-CAD: 03starseeker * r47655 10/brlcad/trunk/misc/CMake/ (BRLCAD_Util.cmake ThirdParty.cmake ThirdParty_TCL.cmake): Make a stab at consolidating TCL_BUNDLE_OPTION and BUNDLE_OPTION, mark the _DEFINES vars as advanced. |
| 06:14.48 | starseeker | huh - http://polarssl.org/ |
| 06:56.33 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 08:24.59 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 08:36.41 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 17:02.25 | CIA-61 | BRL-CAD: 03n_reed * r47656 10/brlcad/trunk/src/tclscripts/mged/comb.tcl: Don't save existing color attribute. It overrides comb color set in gui. |
| 20:39.33 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 21:59.36 | CIA-61 | BRL-CAD: 03n_reed * r47657 10/brlcad/trunk/src/libbu/parse.c: only treat shader string as stack or envmap if shader name matches exactly |
| 22:15.37 | CIA-61 | BRL-CAD: 03n_reed * r47658 10/brlcad/trunk/src/libbu/parse.c: removed is_stack bool from bu_shader_to_tcl_list; was always false, and would cause bad output if true |
| 22:37.10 | n_reed | . |
| 00:05.34 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 00:05.34 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 00:13.09 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 00:33.45 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 01:44.58 | CIA-61 | BRL-CAD: 03n_reed * r47659 10/brlcad/trunk/src/libbu/parse.c: allow braces around shader parameters, e.g. "plastic {sp .5 di .5}" as well as "plastic sp=.5 di=.5", in bu_shader_to_tcl_list (used by mater) |
| 04:43.17 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 13:21.44 | *** join/#brlcad merzo (~merzo@227-73-132-95.pool.ukrtel.net) | |
| 15:54.54 | brlcad | .. |
| 16:16.04 | jordisayol | brlcad: After this extensive discourse, I have nothing more to add... |
| 19:35.33 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 20:27.35 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 21:22.08 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177872364.dsl.bell.ca) | |
| 21:22.27 | IriX64 | http://pastebin.com/V1hgkCeZ |
| 21:22.33 | IriX64 | just happened |
| 21:22.37 | IriX64 | ciao |
| 23:11.06 | *** join/#brlcad merzo (~merzo@175-9-133-95.pool.ukrtel.net) | |
| 08:18.53 | *** join/#brlcad Forth (~Forth@92.242.118.253) | |
| 15:16.14 | n_reed | I'm guessing Irix64's problem is the result of an in-source build |
| 22:42.00 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 22:42.01 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 22:45.14 | *** join/#brlcad CIA-59 (~CIA@cia.atheme.org) | |
| 23:23.24 | *** join/#brlcad yukonbob (~bch@50.46.245.87) | |
| 23:23.26 | yukonbob | hello, #brlcad |
| 23:34.30 | DarkCalf | hello yukonbob |
| 23:35.34 | yukonbob | hello, DarkCalf |
| 23:39.21 | DarkCalf | hello world! |
| 23:40.33 | yukonbob | puts "hello, world!" |
| 00:35.22 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 17:21.44 | *** join/#brlcad merzo (~merzo@75-37-132-95.pool.ukrtel.net) | |
| 17:32.35 | CIA-59 | BRL-CAD: 03starseeker * r47660 10/brlcad/trunk/src/other/ (10 files in 3 dirs): |
| 17:32.35 | CIA-59 | BRL-CAD: move parser.h to re2c_parser.h - renaming the lemon generated parser.h file |
| 17:32.35 | CIA-59 | BRL-CAD: after generation to avoid conflict only works when src dir != build dir. If |
| 17:32.35 | CIA-59 | BRL-CAD: doing an in src build, lemon will still stomp parser.h on its way to generating |
| 17:32.35 | CIA-59 | BRL-CAD: parser_tokens.h |
| 17:57.20 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 17:57.58 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 18:33.28 | CIA-59 | BRL-CAD: 03starseeker * r47661 10/brlcad/trunk/src/libpkg/example/ (client.c server.c): |
| 18:33.28 | CIA-59 | BRL-CAD: Start trying to figure out how to properly shuffle a file back and forth between |
| 18:33.28 | CIA-59 | BRL-CAD: client and server. Ideally, want to have the server send the file to the |
| 18:33.28 | CIA-59 | BRL-CAD: client, have the client reconstitute the file, and then fire the file back at |
| 18:33.29 | CIA-59 | BRL-CAD: the server, which reconstitutes it in turn and maybe compares it to the original |
| 18:33.29 | CIA-59 | BRL-CAD: buffer. Not immediately clear how to achieve this yet. |
| 18:34.50 | CIA-59 | BRL-CAD: 03starseeker * r47662 10/brlcad/trunk/src/other/CMakeLists.txt: Mark as advanced |
| 18:57.42 | CIA-59 | BRL-CAD: 03starseeker * r47663 10/brlcad/trunk/misc/CMake/FindGL.cmake: Whoops, broke the GL logic for MSVC - try again... |
| 19:26.56 | CIA-59 | BRL-CAD: 03n_reed * r47664 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.c scanner.re template.c): addressing some compiler warnings |
| 20:23.40 | CIA-59 | BRL-CAD: 03n_reed * r47665 10/brlcad/trunk/src/other/perplex/ (perplex.h scanner.re template.c): fix scanning from string |
| 20:32.55 | CIA-59 | BRL-CAD: 03starseeker * r47666 10/brlcad/trunk/src/librt/CMakeLists.txt: Try tweaking the DLL variables for librt - working on unbreaking Windows... |
| 21:12.51 | CIA-59 | BRL-CAD: 03starseeker * r47667 10/brlcad/trunk/src/CMakeLists.txt: Add the __WIN32__ definition - may need it for some headers. |
| 21:20.28 | CIA-59 | BRL-CAD: 03n_reed * r47668 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.c): allow empty code section |
| 22:03.06 | CIA-59 | BRL-CAD: 03n_reed * r47669 10/brlcad/trunk/src/other/perplex/ (perplex.c scanner_template.c template.c): renamed scanner template |
| 22:12.36 | brlcad | starseeker: __WIN32__ is a compiler define, provided by the compiler |
| 22:13.43 | brlcad | defining any __* variable invariably can lead to problems down the road, they are reserved for compiler-use |
| 22:14.26 | brlcad | technically all _* preprocessor symbols, but most compilers aren't that strict |
| 23:32.06 | CIA-59 | BRL-CAD: 03starseeker * r47670 10/brlcad/trunk/src/CMakeLists.txt: remove __WIN32__ - compiler define, and in any case it didn't have the desired result. |
| 23:45.28 | CIA-59 | BRL-CAD: 03starseeker * r47671 10/brlcad/trunk/src/libdm/CMakeLists.txt: dm-tk still has issues on Windows. |
| 23:46.27 | *** join/#brlcad merzo (~merzo@29-12-132-95.pool.ukrtel.net) | |
| 23:49.46 | brlcad | looks like astyle 2.03 is going to include my patch for our format, will have to give it a try |
| 23:55.51 | starseeker | woo hoo! |
| 00:02.27 | starseeker | if it works, should we add it to allow a tweaked indent.sh to work "out of the box", as it were? |
| 00:07.13 | brlcad | you mean add astyle to our repo? nah |
| 00:09.36 | brlcad | it's enough to point an offender at the download with instructions that they need to install/run it |
| 00:10.21 | brlcad | it's a thought, but still not necessary until a complete style is defined |
| 00:10.56 | starseeker | alrightie |
| 00:11.02 | brlcad | which would still take at least a day I think to get right, test, verify |
| 00:11.43 | brlcad | next step is for someone(tm) to work on a matching style definition |
| 00:12.00 | brlcad | that would have been a good GCI task :) |
| 00:12.51 | starseeker | heh - next year :-) |
| 00:13.04 | brlcad | maybe :) |
| 00:13.35 | brlcad | it's still a highly dubious program from an efficiency perspective -- most I talked to said it's a wash at best |
| 00:13.56 | starseeker | hmm. Maybe just as well then |
| 00:14.01 | brlcad | I was interested more from a community building/awareness perspective, get 'em aware young |
| 00:17.06 | starseeker | sees the core chromium browser is BSD licensed... cool. Might have to try that. Been avoiding Chrome itself. |
| 00:18.18 | starseeker | Oo - lots of design docs |
| 00:18.41 | starseeker | yow - multi *process* architecture? |
| 00:19.00 | starseeker | backs away slowly... |
| 00:22.11 | brlcad | you do realize why it's designed that way though, right? |
| 00:22.23 | brlcad | flash crashing doesn't bring down your browser |
| 00:22.27 | starseeker | sure - so the browser is robust when individual pages fail |
| 00:22.35 | starseeker | er, yeah :-) |
| 00:22.59 | starseeker | not very useful for our own problem domain though |
| 00:22.59 | brlcad | if a plugin fails, no impact other than maybe a page load failing |
| 00:23.15 | brlcad | if we had lots of unreliable plugins, perhaps |
| 00:53.55 | CIA-59 | BRL-CAD: 03starseeker * r47672 10/brlcad/trunk/src/librt/CMakeLists.txt: Because librt is using so many different DLL_IMPORTS/EXPORTS flags, we're going to have to handle a few things manually. Any reason not to roll TIE_DLL and DB5_DLL into RT_DLL? |
| 01:01.45 | brlcad | no reason comes to mind, wondered why they were separate to begin with |
| 01:05.41 | CIA-59 | BRL-CAD: 03starseeker * r47673 10/brlcad/trunk/ (include/db5.h include/tie.h src/librt/CMakeLists.txt): DB5 and TIE export prefixes switched to RT |
| 02:09.46 | *** join/#brlcad louipc (~louipc@archlinux/fellow/louipc) | |
| 02:15.08 | CIA-59 | BRL-CAD: 03starseeker * r47674 10/brlcad/trunk/src/ (8 files in 7 dirs): Make a stab at dealing with more MSVC build issues with new setup. Not tested yet. |
| 02:59.06 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 03:11.55 | starseeker | huh, cool - wonder if features could be snarfed from this for astyle: http://gcgreatcode.cvs.sourceforge.net/viewvc/gcgreatcode/GC/GC.txt?revision=1.4&view=markup |
| 03:22.42 | starseeker | BRL-CAD builds on Windows once more |
| 03:22.51 | starseeker | is outta here |
| 03:22.57 | louipc | bye |
| 03:27.17 | louipc | Anyone know the address/url to checkout/commit via svn+ssh? or is brlcad not set up for that? |
| 05:35.56 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177872364.dsl.bell.ca) | |
| 05:36.07 | IriX64 | http://pastebin.com/6qAwbny1 |
| 05:36.16 | IriX64 | just checked out and happened |
| 05:36.22 | IriX64 | ciao |
| 06:19.11 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 13:28.37 | brlcad | ~cadsvn |
| 13:28.37 | ibot | To obtain BRL-CAD from Subversion: svn checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk brlcad |
| 13:32.32 | brlcad | louipc: it should work, though I admittedly haven't used that method in a very long time |
| 13:33.24 | brlcad | I believe svn+ssh requires uploading your ssh key ( https://sourceforge.net/apps/trac/sourceforge/wiki/SSH%20keys ) or it will prompt for password multiple times for a single checkout |
| 13:41.21 | brlcad | louipc: I take it back, looks like they changed it to be https-only some time ago (about a year ago) though they keys will still work and get used |
| 13:45.53 | brlcad | louipc: ahh, and their new beta website interface will support it in the upcoming months: https://sourceforge.net/p/forge/documentation/svn%20-%20Beta/ |
| 13:46.57 | brlcad | brl-cad has not yet migrated to the beta interface |
| 14:00.48 | ``Erik | TIE_DLL being seperate is legacy from when libtie linked librt |
| 14:27.47 | CIA-59 | BRL-CAD: 03d_rossberg * r47675 10/brlcad/trunk/src/ (librt/CMakeLists.txt libwdb/CMakeLists.txt): the brlcad.dll needs an openNURBS.dll: setting the compiler switches |
| 14:31.33 | CIA-59 | BRL-CAD: 03d_rossberg * r47676 10/rt^3/trunk/src/coreInterface/ConstDatabase.cpp: the result of a test for NULL should be honored |
| 14:36.56 | starseeker | hmm... IriX64's error raises the question of how hard we should look for jni.h... at least on my system, no special effort is required |
| 14:37.36 | starseeker | not sure if that should be regarded as a system configuration issue... |
| 14:39.21 | starseeker | oh, right, I've got that config thing working |
| 14:39.24 | starseeker | hmm... |
| 14:47.22 | starseeker | might have to treat it as a config issue, or there are other issues |
| 14:47.42 | starseeker | my system has both java itself and gcc supplying jni.h headers |
| 14:48.42 | starseeker | (incompatible ones, I might add) |
| 14:50.53 | starseeker | shakes head - need help for this one, don't know enough about Java/JNI |
| 15:07.07 | ``Erik | at the moment, the only jni using stuff is incredibly muves specific, so I'd say "not at all" for the time being... :D make 'em set the variable |
| 15:46.39 | CIA-59 | BRL-CAD: 03brlcad * r47677 10/brlcad/trunk/src/rt/viewedge.c: carl reported a typo |
| 15:54.25 | CIA-59 | BRL-CAD: 03brlcad * r47678 10/brlcad/trunk/src/tclscripts/rtwizard/examples/ (5 files in 5 dirs): various additional corrections from carl for rtwizard. |
| 16:18.00 | CIA-59 | BRL-CAD: 03brlcad * r47679 10/brlcad/trunk/src/adrt/isst_tcltk.c: TIE_EXPORT is dead |
| 16:42.40 | CIA-59 | BRL-CAD: 03bob1961 * r47680 10/brlcad/trunk/src/rt/do.c: Remove call to do_ae() from within cm_ae(). This causes a segmentation fault. Besides, do_ae() gets called later in main.c if necessary. |
| 17:22.06 | CIA-59 | BRL-CAD: 03n_reed * r47681 10/brlcad/trunk/src/other/perplex/ (9 files): borrowing re2c's option parser |
| 17:22.28 | CIA-59 | BRL-CAD: 03starseeker * r47682 10/brlcad/trunk/CMakeLists.txt: Do a little more to disable librtserver - may have to eventually do an actual compile test on this, but hopefully this will avoid some issues. |
| 17:50.14 | CIA-59 | BRL-CAD: 03bob1961 * r47683 10/brlcad/trunk/ (4 files in 4 dirs): Added a data_polygons subcommand for saving a polygon as a sketch. Also added one for importing polygon data from a sketch. |
| 18:07.07 | CIA-59 | BRL-CAD: 03starseeker * r47684 10/brlcad/trunk/src/other/libutahrle/CMakeLists.txt: Hmm, must have had a stale libutahrle lib file around. Tweak MSVC build flags. |
| 18:11.56 | CIA-59 | BRL-CAD: 03n_reed * r47685 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.cpp perplex.h scanner_template.c): added option for specifying output file |
| 19:07.16 | *** join/#brlcad merzo (~merzo@29-12-132-95.pool.ukrtel.net) | |
| 19:09.21 | *** join/#brlcad Forth (~Forth@92.242.118.253) | |
| 19:11.58 | *** part/#brlcad Forth (~Forth@92.242.118.253) | |
| 19:12.50 | CIA-59 | BRL-CAD: 03bob1961 * r47686 10/brlcad/trunk/src/rt/do.c: Revert the previous commit. |
| 19:22.12 | CIA-59 | BRL-CAD: 03bob1961 * r47687 10/brlcad/trunk/src/rt/do.c: Check rtip for NULL before trying to use withing do_ae(). |
| 19:33.44 | CIA-59 | BRL-CAD: 03erikgreenwald * r47688 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: remove uninitialized (and basically unused) ret variable |
| 19:34.34 | CIA-59 | BRL-CAD: 03starseeker * r47689 10/brlcad/trunk/ (3 files in 3 dirs): Clean up the OSX framework detection |
| 19:43.38 | CIA-59 | BRL-CAD: 03erikgreenwald * r47690 10/brlcad/trunk/src/librt/CMakeLists.txt: Set OBJ_BREP on all statics, not just windows |
| 19:59.17 | CIA-59 | BRL-CAD: 03starseeker * r47691 10/brlcad/trunk/src/libdm/CMakeLists.txt: the libdm static build does need some defines - add those. |
| 20:04.14 | CIA-59 | BRL-CAD: 03starseeker * r47692 10/brlcad/trunk/src/librt/CMakeLists.txt: just BUILD_STATIC_LIBS |
| 20:05.34 | CIA-59 | BRL-CAD: 03n_reed * r47693 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.cpp perplex.h scanner.re scanner_template.c): add ability to generate a header file |
| 20:17.05 | CIA-59 | BRL-CAD: 03erikgreenwald * r47694 10/brlcad/trunk/src/libged/CMakeLists.txt: Move FB includes to end to try to shuffle macports include dir out... |
| 20:32.12 | starseeker | ``Erik: brlcad said defining that broke some other platform |
| 20:32.27 | starseeker | apparently defining that can have Bad Side-effects... |
| 20:35.48 | ``Erik | hm, thought I had it safely wrapped *shrug* |
| 21:05.24 | CIA-59 | BRL-CAD: 03bob1961 * r47695 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: ae2dir doesn't take a view parameter |
| 21:08.27 | brlcad | ``Erik: you did have it wrapped, and it still caused a problem because it was a compiler variable |
| 21:09.33 | brlcad | that's why the _* vars aren't supposed to be used, compiler is allowed to claim imminent domain on them and screw up caller code in seeminly unreasonable ways |
| 21:11.31 | brlcad | if I remember the problem correctly, it would fail the build even if you #undef _VAR ; #define _VAR 1 ; it would abort saying you're screwing with an already defined _VAR and no #ifdef logic could get around it |
| 21:12.42 | ``Erik | hm *shrug* if fails on my laptop, too (very up to date), but turning off strict allows it to pass |
| 21:12.49 | brlcad | so need some other fix (like always putting X11 includes last) |
| 21:14.31 | brlcad | so great, you have a repeatable platform environment where you can find another solution :P |
| 21:14.35 | CIA-59 | BRL-CAD: 03starseeker * r47696 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: Just remove duplicates regardless |
| 21:14.55 | starseeker | votes for smacking the zlib developers with a wet trout |
| 21:16.40 | ``Erik | also have slews of warnings from variatic macros in an X header, :D all good fun here |
| 21:17.50 | brlcad | I just got those for the first time today from an autotools build, FD_SET() and FD_ISSET() |
| 21:18.21 | brlcad | at least seemingly related |
| 21:18.45 | brlcad | error: ISO C forbids braced-groups within expressions |
| 21:28.32 | CIA-59 | BRL-CAD: 03n_reed * r47697 10/brlcad/trunk/src/other/perplex/ (parser.y scanner.re scanner_template.c): address compiler warnings |
| 21:35.12 | brlcad | starseeker: false alarm on the strict failure discrepancy, it wasn't compiling optimized which triggers the failure |
| 21:50.18 | CIA-59 | BRL-CAD: 03bob1961 * r47698 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: When using "put" to create an extrude primitive it's possible to get a segmentation fault if the sketch name is not specified. This updates rt_extrude_adjust() to check if sketch_name is NULL. |
| 21:53.44 | CIA-59 | BRL-CAD: 03erikgreenwald * r47699 10/brlcad/trunk/misc/CMake/Fink_MacPorts.cmake: add include dirs to remove command |
| 21:58.41 | starseeker | phew :-) |
| 21:59.26 | starseeker | looks like we can work around the zlib thing by disabling macports |
| 22:23.16 | CIA-59 | BRL-CAD: 03brlcad * r47700 10/brlcad/trunk/src/libged/polyclip.cpp: curr_lsg won't be initialized if the list is empty. make sure we don't dereference. |
| 22:28.54 | CIA-59 | BRL-CAD: 03brlcad * r47701 10/brlcad/trunk/include/ (CMakeLists.txt Makefile.am bselect.h): |
| 22:28.56 | CIA-59 | BRL-CAD: add a new header for wrapping the logic and functionality necessary for |
| 22:28.56 | CIA-59 | BRL-CAD: protecting against a bug in gcc 4.6.2 where the FD_*() macros aren't marked as |
| 22:28.56 | CIA-59 | BRL-CAD: extensions causing gcc to emit a warning during -O3 compilation about ISO C |
| 22:28.56 | CIA-59 | BRL-CAD: forbidding braced-groups within expressions. this may need some more |
| 22:28.56 | CIA-59 | BRL-CAD: precautions to ensure we only perform this workaround when absolutely necessary, |
| 22:28.57 | CIA-59 | BRL-CAD: but it seems to work well for the platform (linux) exhibiting the error. |
| 22:32.59 | CIA-59 | BRL-CAD: 03brlcad * r47702 10/brlcad/trunk/src/ (7 files in 5 dirs): |
| 22:32.59 | CIA-59 | BRL-CAD: replace includes of sys/select with the new bselect.h header so we can avoid a |
| 22:33.00 | CIA-59 | BRL-CAD: gcc 4.6.2 'ISO C forbids braced-groups within expressions' -O3 -pedantic error. |
| 22:33.00 | CIA-59 | BRL-CAD: looks like the '-Werror=edantic' problem is already reported. |
| 22:36.28 | CIA-59 | BRL-CAD: 03brlcad * r47703 10/brlcad/trunk/src/conv/enf-g.c: initialize variables before use. atof may fail. |
| 22:42.40 | CIA-59 | BRL-CAD: 03brlcad * r47704 10/brlcad/trunk/src/ (6 files in 3 dirs): few more select() caller stragglers that didn't include sys/select.h directly. include bselect.h ftw. |
| 23:08.31 | CIA-59 | BRL-CAD: 03brlcad * r47705 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: |
| 23:08.31 | CIA-59 | BRL-CAD: reworking more variables since compilation is halting on bugs that gcc 4.6.2 |
| 23:08.31 | CIA-59 | BRL-CAD: detected where we're calling V3ARGS on point2d_t variables being passed around. |
| 23:08.31 | CIA-59 | BRL-CAD: make isect_line2_ellipse() take 2d entities and promote the rest to 3d for now. |
| 00:44.22 | louipc | brlcad: ok thanks for the info |
| 00:53.35 | CIA-59 | BRL-CAD: 03starseeker * r47706 10/brlcad/trunk/CMakeLists.txt: with any luck, we don't need to separately call out tcl and tk build deps... |
| 03:03.03 | *** join/#brlcad pacman87 (~Timothy@adsl-208-191-158-89.dsl.hstntx.swbell.net) | |
| 03:05.25 | pacman87 | brlcad: ping/pm? |
| 03:44.19 | *** join/#brlcad Forth (~Forth@92.242.118.253) | |
| 03:45.01 | *** part/#brlcad Forth (~Forth@92.242.118.253) | |
| 03:45.22 | brlcad | pacman87: hm? sure? what? |
| 03:48.53 | *** part/#brlcad pacman87 (~Timothy@adsl-208-191-158-89.dsl.hstntx.swbell.net) | |
| 03:49.11 | *** join/#brlcad pacman87 (~Timothy@adsl-208-191-158-89.dsl.hstntx.swbell.net) | |
| 03:50.13 | pacman87 | brlcad: pm'd |
| 04:02.31 | pacman87 | has there been any progress on the revolve primitive lately? |
| 04:03.45 | brlcad | yeah, it was included in an exhaustive performance profile a couple weeks ago |
| 04:03.58 | brlcad | along with all of the other primitives, it was part of a NURBS performance analysis |
| 04:04.19 | brlcad | it didn't fare so well and unfortunately crashed for some of the test cases |
| 04:04.50 | brlcad | so there are some new to-do entries to investigate and fix |
| 04:10.59 | pacman87 | I might be able to take another look at it mid-january, once all the dust settles from graduation/christmas/moving |
| 04:30.25 | brlcad | awesome |
| 06:01.27 | *** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl) | |
| 07:00.23 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 07:01.57 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 08:25.25 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 15:24.08 | CIA-59 | BRL-CAD: 03erikgreenwald * r47707 10/brlcad/trunk/src/libgcv/bottess.c: disable function level static declarations. fix debugging output parameters. |
| 15:49.51 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 16:01.41 | CIA-59 | BRL-CAD: 03n_reed * r47708 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.h scanner.re): added support for braces and strings inside actions |
| 16:36.07 | CIA-59 | BRL-CAD: 03n_reed * r47709 10/brlcad/trunk/src/other/perplex/ (perplex.h scanner.re): added support for single quote strings and comments inside actions |
| 18:49.29 | *** join/#brlcad Forth (~Forth@92.242.118.253) | |
| 18:58.36 | CIA-59 | BRL-CAD: 03starseeker * r47710 10/brlcad/trunk/src/other/CMakeLists.txt: If we're not able to build SCL, set the build var to off so it gets reported that way... |
| 19:11.26 | CIA-59 | BRL-CAD: 03starseeker * r47711 10/brlcad/trunk/src/other/CMakeLists.txt: Mark BUILD_SCL as advanced |
| 19:31.23 | CIA-59 | BRL-CAD: 03starseeker * r47712 10/brlcad/trunk/src/other/CMakeLists.txt: Ah, right - was setting the wrong thing for the toplevel mechanism. This is tested and works on Win32 |
| 19:51.27 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 21:05.21 | CIA-59 | BRL-CAD: 03bob1961 * r47713 10/brlcad/trunk/ (3 files in 3 dirs): Provide a way to select the target polygon. |
| 21:10.52 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 21:11.09 | brlcad | networking woes at the isp apparently |
| 21:13.06 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 21:16.22 | CIA-59 | BRL-CAD: 03brlcad * r47714 10/brlcad/trunk/src/ (conv/iges/iges.c lgt/do_options.c proc-db/csgbrep.cpp): more strict quellage. |
| 22:28.56 | brlcad | if I had been using cmake instead of ccmake for specifying options, I would have expected tom browder's example to work |
| 22:29.03 | brlcad | did he typo one of the names? |
| 22:31.57 | CIA-59 | BRL-CAD: 03n_reed * r47715 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.h scanner.re): added basic support for start condition scopes |
| 23:12.54 | *** join/#brlcad pacman87 (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net) | |
| 23:26.58 | *** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl) | |
| 23:29.42 | CIA-59 | BRL-CAD: 03starseeker * r47716 10/brlcad/trunk/ (15 files in 15 dirs): Add a scheme for sorting include directories for BRL-CAD libraries, with an eye towards favoring local includes over system directories. Not tested in any of the problem cases as yet. |
| 00:44.05 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 02:46.43 | CIA-59 | BRL-CAD: 03starseeker * r47717 10/brlcad/trunk/misc/CMake/DiffCache.cmake: The new _DEFINES showed some holes in the cache diffing routine. This should be more robust and cleaner. |
| 02:52.20 | CIA-59 | BRL-CAD: 03starseeker * r47718 10/brlcad/trunk/src/libged/CMakeLists.txt: Put FB back in alphabetical order - hopefully the sorting logic will handle the situation, if not the 'correct' approach will have to be to disable macports. |
| 02:54.26 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 02:55.30 | starseeker | wonders what on earth he did to irssi... |
| 02:55.46 | starseeker | hope I didn't miss anything... |
| 03:00.46 | starseeker | pulls up archives... |
| 03:01.02 | starseeker | brlcad: he's using the old CMake variable setup |
| 03:01.26 | starseeker | (tom browder) |
| 03:02.00 | starseeker | emailed the correct settings for 7.20.4, which is new enough to be using the newer multi-variable options |
| 03:55.08 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 04:09.40 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 04:19.07 | *** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl) | |
| 06:14.52 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 10:13.49 | *** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl) | |
| 11:10.24 | *** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 11:29.39 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 13:52.07 | brlcad | starseeker: you didn't do anything to irssi, it just got disconnected due to some isp routing issue |
| 13:52.22 | brlcad | (.bz was briefly disconnected yesterday) |
| 14:00.35 | CIA-59 | BRL-CAD: 03erikgreenwald * r47719 10/brlcad/trunk/src/libgcv/ (CMakeLists.txt Makefile.am test_bottess.c): stub in unit testing for bottess |
| 14:01.11 | ``Erik | starseeker: run irssi inside of screen(1) (irssi lacks bx style nohup miniscreen) |
| 14:13.11 | CIA-59 | BRL-CAD: 03brlcad * r47720 10/brlcad/trunk/src/libgcv/test_bottess.c: fix header file name and copyright year (starts with file) |
| 14:16.37 | CIA-59 | BRL-CAD: 03brlcad * r47721 10/brlcad/trunk/NEWS: bob fixed a bug in rt where it'd crash if the ae command was called during -c (before rtip was initialized). fixed by delaying the do_ae() processing until after all args are processed. |
| 14:43.34 | CIA-59 | BRL-CAD: 03brlcad * r47722 10/brlcad/trunk/AUTHORS: |
| 14:43.34 | CIA-59 | BRL-CAD: developers already have the prestige badge and will invariably/usually have all |
| 14:43.34 | CIA-59 | BRL-CAD: contributed to docs in some fashion by the time they get that designation (100+ |
| 14:43.34 | CIA-59 | BRL-CAD: features), so avoid double-listing any dev. also, expand docs to include the |
| 14:43.34 | CIA-59 | BRL-CAD: website so we can credit robert leverginton for his work redesigning the main |
| 14:43.35 | CIA-59 | BRL-CAD: site back in 2007. responded to my sf posting in june 2007, unveiled new |
| 14:43.36 | CIA-59 | BRL-CAD: unified theme drupal+mediawiki+gallery2 site in march 2008. |
| 15:01.16 | CIA-59 | BRL-CAD: 03brlcad * r47723 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: prevent a pipe tesselation double-free, detected by the conversion script and verbose blather on linux |
| 15:09.00 | starseeker | ``Erik: do run it inside of screen - got into a funky state regardless |
| 15:09.08 | starseeker | probably hit some weird key combo |
| 15:13.51 | ``Erik | ah, fun |
| 15:16.26 | CIA-59 | BRL-CAD: 03brlcad * r47724 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: cleanup |
| 15:53.30 | CIA-59 | BRL-CAD: 03brlcad * r47726 10/brlcad/trunk/NEWS: nick fixed a bug affecting the combination editor where it wasn't preserving the color value set. tcl script was preserving the original color, so needed to not do that. |
| 15:56.59 | CIA-59 | BRL-CAD: 03n_reed * r47727 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.cpp perplex.h scanner_template.c): add option for toggling definition of condition routines |
| 16:21.59 | brlcad | starseeker: that "funky state" was simply "disconnected from freenode" |
| 16:22.31 | brlcad | if you looked at irssi window 1, you probably would have seen all the notices saying you weren't connected any more |
| 16:23.34 | brlcad | needed to run /connect or /server |
| 16:26.47 | CIA-59 | BRL-CAD: 03brlcad * r47725 10/brlcad/trunk/src/libbu/ (parse.c tcl.c): ws |
| 16:35.00 | CIA-59 | BRL-CAD: 03n_reed * r47728 10/brlcad/trunk/src/other/perplex/ (parser.y scanner.re scanner_template.c): minor changes to macro names |
| 16:45.33 | CIA-59 | BRL-CAD: 03tbrowder2 * r47729 10/brlcad/trunk/include/brlcad.h: correct typo |
| 17:36.38 | CIA-59 | BRL-CAD: 03bob1961 * r47730 10/brlcad/trunk/ (3 files in 3 dirs): Added color, line width and line style at the polygon level. |
| 18:17.36 | *** join/#brlcad Johnnie (~Johns@host161-101-dynamic.2-79-r.retail.telecomitalia.it) | |
| 18:17.38 | Johnnie | hi all |
| 18:19.51 | Johnnie | I need to render an IGES/STEP that contains solid geometry with OpenGL. Can BRL-CAD output a tringulated mesh from a solid? |
| 18:24.25 | starseeker | not currently |
| 18:24.38 | starseeker | at least, not for the NURBS geometry that usually makes up a STEP file |
| 18:25.24 | Johnnie | there's other library that permit this? |
| 18:25.33 | starseeker | if you strictly want to visualize a NURBS surface with OpenGL, you might see if OpenSG's support for NURBS can do what you need... |
| 18:25.52 | Johnnie | my problem is that I need to do an IGES/STEP viewer |
| 18:25.55 | Johnnie | in opengl |
| 18:26.27 | Johnnie | but I can't find a valid IGES/STEP triangulator |
| 18:27.15 | starseeker | http://cg.cs.uni-bonn.de/en/publications/paper-details/kahlesz-2002-nurbs/ |
| 18:27.24 | starseeker | the trick would be to get STEP nurbs into OpenSG |
| 18:28.10 | starseeker | you might try hooking up opensg and https://github.com/mpictor/StepClassLibrary |
| 18:30.34 | Johnnie | I see. |
| 18:31.05 | starseeker | BRL-CAD is planning to support what you're describing, but we aren't there yet |
| 18:31.35 | Johnnie | so actually BRL-CAD can render IGES via ray-tracing? |
| 18:31.44 | Johnnie | (only) |
| 18:32.47 | Johnnie | I wonder if exists some triangulation library that can already do it |
| 18:32.56 | Johnnie | like GTS |
| 18:33.11 | starseeker | that's why I suggested opensg - they seem to have some triangulation code |
| 18:33.57 | starseeker | my todo list includes isolating the tesselation code in opensg and seeing whether it can be adapted for use with BRL-CAD |
| 18:35.03 | Johnnie | many library use OpenCascade to achieve this |
| 18:35.27 | Johnnie | but it's an huge library |
| 18:35.28 | starseeker | nods. Unfortunately, opencascade isn't license compatible with BRL-CAD |
| 18:35.34 | Johnnie | yep |
| 18:36.08 | starseeker | Johnnie: what are your requirements? (licensing wise) |
| 18:36.42 | Johnnie | I need to create a commercial IGES/STEP viewer only (no modeling). |
| 18:37.10 | starseeker | commercial... not open source then? |
| 18:37.33 | Johnnie | I'm trying to figure out if some LGPL library exists. |
| 18:37.57 | starseeker | ah - opensg is LGPL, last time I looked. |
| 18:38.09 | Johnnie | but can OpenSG import IGES/STEP? |
| 18:38.26 | starseeker | not as far as I know |
| 18:38.45 | Johnnie | there's perhaps commercial library? |
| 18:39.06 | starseeker | I'm sure there are, but I don't know much about those |
| 18:39.14 | Johnnie | Avoid that one that are too expensive (like ACIS, Parasolid) |
| 18:39.49 | Johnnie | Looklike that for AutoCAD file format there's by far more support |
| 18:39.56 | Johnnie | (DWG/DXF) |
| 18:40.04 | Johnnie | than IGES/STEP |
| 18:40.52 | starseeker | our focus here is open source only - commercial CAD is only of interest when it comes to supporting data read/write |
| 18:42.19 | Johnnie | I see. I hope to find some other channel here (on irc.freenode.net) that can give me some other hints. Thanks. |
| 18:47.16 | starseeker | grr |
| 18:47.19 | starseeker | pipe.c:2932: warning: assignment from incompatible pointer type |
| 18:47.41 | Johnnie | (openNURBS toolkit look like interesting) |
| 18:55.24 | CIA-59 | BRL-CAD: 03erikgreenwald * r47731 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: split assignments to avoid incompatible pointer error |
| 19:15.00 | starseeker | Johnnie: we use opennurbs, but they don't include tessellation routines |
| 19:15.00 | *** part/#brlcad Johnnie (~Johns@host161-101-dynamic.2-79-r.retail.telecomitalia.it) | |
| 19:41.43 | CIA-59 | BRL-CAD: 03starseeker * r47732 10/brlcad/trunk/src/fb/CMakeLists.txt: Ah, right - even though it's not a library, we need to sort includes for at least some of the binaries. Do so for the fb directory. |
| 20:11.35 | ``Erik | starseeker: hehehe "On the other hand, my strategy is not top down, it is bottoms up." http://www.foxnews.com/on-air/hannity/transcript/herman-cain-solving-americas-problems-not-rocket-science |
| 20:11.49 | ``Erik | (and yes, it did fail on the same _LARGEFILE64_SOURCE issue) |
| 20:12.32 | starseeker | nods |
| 20:12.44 | starseeker | at least turning everything on succeeds |
| 20:13.02 | ``Erik | as does disabling strict |
| 20:13.34 | starseeker | or (IIRC) disabling macports includes |
| 20:15.01 | brlcad | starseeker: fyi, our iges importer will result in a bspline that can be triangulated -- would have been worth trying |
| 20:15.17 | starseeker | oh, really? |
| 20:15.23 | starseeker | didn't know that |
| 20:15.26 | starseeker | cool |
| 20:15.42 | brlcad | i've mentioned that the old nurbs code had tessellation already implemented |
| 20:16.02 | brlcad | it's not adaptive, super slow, but it works |
| 20:16.13 | starseeker | ah - didn't realize it was operational |
| 20:16.36 | brlcad | simple walk over the uv space, chop them up into polys |
| 20:16.57 | starseeker | does it "stitch" together for a solid? |
| 20:17.12 | brlcad | don't know |
| 20:17.23 | brlcad | at least, don't remember |
| 20:17.30 | brlcad | exercise left to the reader |
| 20:17.34 | starseeker | heh |
| 20:18.00 | brlcad | for his described purpose, it would have been sufficient |
| 20:18.23 | starseeker | will mention it if he comes back |
| 20:18.48 | starseeker | rather doubts it would be robust/fast enough, but agrees it would have been worth a shot |
| 20:38.53 | *** join/#brlcad merzo (~merzo@94-41-132-95.pool.ukrtel.net) | |
| 20:47.34 | starseeker | anybody else getting a regression failure on the solids test? |
| 20:49.33 | starseeker | looks as if the light is "brighter" |
| 20:53.15 | ``Erik | only on certain primitives, though |
| 20:54.01 | CIA-59 | BRL-CAD: 03brlcad * r47733 10/brlcad/trunk/ (include/bu.h src/libbu/tcl.c): |
| 20:54.02 | CIA-59 | BRL-CAD: remove declaration of bu_tcl*() functions that are not used outside of |
| 20:54.02 | CIA-59 | BRL-CAD: src/libbu/tcl.c, part of gradual elimination of tcl from libbu. looks like two |
| 20:54.02 | CIA-59 | BRL-CAD: are directly used (bu_tcl_structparse_argv() by edsol.c and bu_tcl_setup() by |
| 20:54.02 | CIA-59 | BRL-CAD: ssampview) and four others indirectly used through tclscripts. |
| 20:55.41 | CIA-59 | BRL-CAD: 03n_reed * r47734 10/brlcad/trunk/src/other/perplex/ (perplex.h scanner.re): improved parsing of patterns |
| 20:57.39 | ``Erik | linux and fbsd show 25006 off by many for solids, mac shows 25009 |
| 21:45.57 | CIA-59 | BRL-CAD: 03starseeker * r47735 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_Util.cmake): Tweak the BRLCAD_OPTION macro - try for supporting DISABLE_ forms of ENABLE_ vars |
| 21:46.08 | starseeker | great... |
| 21:47.12 | CIA-59 | BRL-CAD: 03n_reed * r47736 10/brlcad/trunk/src/other/perplex/ (parser.y scanner_template.c): adding required re2c configuration options for condition support to output |
| 21:59.02 | CIA-59 | BRL-CAD: 03brlcad * r47737 10/brlcad/trunk/src/libbu/tcl.c: mark the bu_cmdtab functions as HIDDEN as they don't need to be public API. change their function prefix from bu_tcl_ to tcl_bu_ so they merely prefix the bu function name they wrap. |
| 22:03.48 | CIA-59 | BRL-CAD: 03brlcad * r47738 10/brlcad/trunk/doc/deprecation.txt: all of the bu_tcl_* functions are no longer public API. |
| 22:06.52 | CIA-59 | BRL-CAD: 03brlcad * r47739 10/brlcad/trunk/doc/deprecation.txt: oops, fix the regex to use both matched patterns. |
| 22:09.45 | CIA-59 | BRL-CAD: 03starseeker * r47740 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_Util.cmake): Add a second 'BRLCAD_OPTION' to test the setup. Need to think about how to handle this for third party cases - may need an option to go with either BRLCAD_OPTION or just a regular option. |
| 22:12.48 | CIA-59 | BRL-CAD: 03starseeker * r47741 10/brlcad/trunk/CMakeLists.txt: Nevermind the BRLCAD_ prefix on the aliases - if we need that it can be automated at the macro level |
| 22:26.05 | *** join/#brlcad Johnnie (~Johns@host161-101-dynamic.2-79-r.retail.telecomitalia.it) | |
| 22:28.51 | ``Erik | http://www.codeschool.com/courses/rails-for-zombies vrry cool approach, mebbe brlcad should make some BRL-CAD ones of those :> *duck* |
| 23:14.27 | CIA-59 | BRL-CAD: 03brlcad * r47742 10/brlcad/trunk/src/libbu/tcl.c: |
| 23:14.27 | CIA-59 | BRL-CAD: eliminate 7 seemingly minimal-value bu tcl commands that also seem to be |
| 23:14.27 | CIA-59 | BRL-CAD: completely unused within our code: bu_ck_malloc_ptr, bu_malloc_len_roundup, |
| 23:14.27 | CIA-59 | BRL-CAD: bu_printb, bu_key_eq_to_key_val, bu_shader_to_tcl_list, bu_key_val_to_key_eq, |
| 23:14.27 | CIA-59 | BRL-CAD: bu_shader_to_key_eq. 200 line reduction. |
| 23:17.33 | brlcad | starseeker: haven't seen the regression failure, but it should be investigated |
| 23:17.56 | brlcad | possible the ambient occlusion patch changed some lighting default and might need to be conditionalized |
| 23:18.16 | brlcad | you could unroll that commit and see if it still fails |
| 23:22.15 | CIA-59 | BRL-CAD: 03brlcad * r47743 10/brlcad/trunk/src/libbu/parse.c: the _bu_ prefix convention on static functions was a bad idea. use a prefix based on the group/file these functions belong to, i.e., parse_ |
| 23:28.40 | CIA-59 | BRL-CAD: 03brlcad * r47744 10/brlcad/trunk/src/rttherm/ssampview.tcl: replace bu_get_all_keyword_values with calls to bu_get_value_by_keyword. this was the only use with ill-defined side effects, so reduce. |
| 23:31.32 | CIA-59 | BRL-CAD: 03brlcad * r47745 10/brlcad/trunk/src/libbu/tcl.c: removed the only call to bu_get_all_keyword_values from tcl code so its binding can go away. another 100 lines. |
| 23:34.49 | CIA-59 | BRL-CAD: 03brlcad * r47746 10/brlcad/trunk/src/rttherm/ssampview.c: replace the call to bu_tcl_setup() and rt_tcl_setup() with the same initialization call used by bwish and mged, calling Bu_Init() and Rt_Init() respectively. allows bu_tcl_setup() to go away. |
| 23:38.29 | CIA-59 | BRL-CAD: 03brlcad * r47747 10/brlcad/trunk/ (doc/deprecation.txt include/bu.h src/libbu/tcl.c): remove bu_tcl_setup() in favor of equivalent Bu_Init() |
| 23:48.30 | ``Erik | starseeker: http://projects.goldelico.com/p/gta04-main/ |
| 00:00.25 | CIA-59 | BRL-CAD: 03brlcad * r47748 10/brlcad/trunk/ (include/bu.h src/libbu/tcl.c src/mged/edsol.c): do the same with bu_tcl_structparse_argv(). it was only used in one place, so eliminate it by just making the caller code call bu_structparse_argv() directly. |
| 00:06.22 | starseeker | hah - cool! |
| 00:24.27 | starseeker | doesn't look like it was the ambient occlusion patch |
| 00:30.10 | starseeker | whadya bet it's compile flag related... |
| 00:30.20 | starseeker | fires up autotools |
| 00:53.23 | starseeker | ok, failure is in autotools too... |
| 00:58.55 | starseeker | 47656 is OK... |
| 00:59.55 | starseeker | 47659 is bad |
| 01:05.21 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 01:21.23 | CIA-59 | BRL-CAD: 03starseeker * r47749 10/brlcad/trunk/src/libbu/parse.c: Try to undo r47659 without ruining the subsequent commits... this was breaking the solids shader regression test, so needs more checking into. |
| 01:21.41 | brlcad | ah, right -- nick changed how shaders are parsed so tcl syntax works |
| 01:21.47 | brlcad | mater command |
| 01:27.39 | CIA-59 | BRL-CAD: 03brlcad * r47750 10/brlcad/trunk/sh/template.sh: don't just delete the header/footer file before aborting. we might have been running adding a header/footer to a file that already existed. instead restore the backup. |
| 01:28.14 | CIA-59 | BRL-CAD: 03brlcad * r47751 10/brlcad/trunk/sh/ (footer.sh header.sh): add support for adding header/footers to .cmake files, using sh-mode |
| 01:28.39 | CIA-59 | BRL-CAD: 03brlcad * r47752 10/brlcad/trunk/TODO.cmake: added the deprecation warning to the old build system |
| 01:29.38 | CIA-59 | BRL-CAD: 03brlcad * r47753 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: a bug? do what the comment says it is supposed to be doing. |
| 01:34.02 | CIA-59 | BRL-CAD: 03starseeker * r47754 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_Util.cmake): Handle setting of default option in BRLCAD_OPTION |
| 01:40.15 | CIA-59 | BRL-CAD: 03brlcad * r47755 10/brlcad/trunk/ (9 files in 7 dirs): |
| 01:40.15 | CIA-59 | BRL-CAD: removed bu_badmagic_tcl() and all of the tcl-specific badmagic macros like |
| 01:40.15 | CIA-59 | BRL-CAD: BU_CKMAG_TCL and the various bn and rt macros that wrapped it (like |
| 01:40.15 | CIA-59 | BRL-CAD: RT_CK_AP_TCL, RT_CK_RTI_TCL, BN_CK_VLIST, etc). one step closer to decoupling |
| 01:40.16 | CIA-59 | BRL-CAD: libbu from tcl |
| 02:56.29 | CIA-59 | BRL-CAD: 03brlcad * r47756 10/brlcad/trunk/src/libbu/observer.c: _bu_ prefix was a bad idea |
| 03:14.29 | *** join/#brlcad merzo (~merzo@48-62-132-95.pool.ukrtel.net) | |
| 03:24.43 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 03:30.42 | CIA-59 | BRL-CAD: 03brlcad * r47757 10/brlcad/trunk/src/libbu/cmdhist.c: _bu_ prefix was a bad idea, use the file name as the prefix |
| 03:35.05 | CIA-59 | BRL-CAD: 03brlcad * r47758 10/brlcad/trunk/ (include/bu.h src/libbu/tcl.c): change Bu_Init() to take a void* since dynamic loading should still work just fine without knowing the type. helps decouple the header from needing tcl.h |
| 03:42.54 | CIA-59 | BRL-CAD: 03brlcad * r47759 10/brlcad/trunk/src/libbu/cmdhist_obj.c: unfortunately not so simple to remove/move the tcl side of the command history implementation from libbu since it involves non-deprecated tclscripts api. |
| 03:56.06 | CIA-59 | BRL-CAD: 03brlcad * r47760 10/brlcad/trunk/ (10 files in 3 dirs): |
| 03:56.06 | CIA-59 | BRL-CAD: move command history tcl objects from libbu to libtclcad, changing them from |
| 03:56.06 | CIA-59 | BRL-CAD: init during loading of libbu to loading of libtclcad. this should keep things |
| 03:56.06 | CIA-59 | BRL-CAD: working for archer and get libbu one step closer to tcliberation. |
| 04:16.04 | CIA-59 | BRL-CAD: 03brlcad * r47761 10/brlcad/trunk/TODO: break cyclic dependency between libdm and libged |
| 04:16.51 | CIA-59 | BRL-CAD: 03brlcad * r47762 10/brlcad/trunk/doc/deprecation.txt: ws and 3 months should be necessary, not sufficient |
| 14:53.10 | CIA-59 | BRL-CAD: 03erikgreenwald * r47763 10/brlcad/trunk/src/libtclcad/cmdhist_obj.c: Move Cho_Init() to the end to avoid undefined function errors (prototypes were removed). |
| 16:12.04 | n_reed | is looking into the solids-regress failure |
| 16:29.06 | n_reed | I assert that r47659 is correct. I believe the test is what needs to be fixed. |
| 16:29.53 | n_reed | r47659 produces different shader strings for the mater calls in solids.sh which wrap plastic shader parameters in curly braces |
| 16:30.04 | ``Erik | reference and output pix's are different in brightness, dude |
| 16:30.25 | n_reed | that's correct |
| 16:32.55 | ``Erik | heh, long standing bug, even O.o |
| 16:34.03 | ``Erik | brlcad: any special approach to altering reference data? (quorum, s2 signoff, anything?) |
| 16:34.57 | ``Erik | this, the m35 torus intersecting geom for tires edge hit difference, mebbe re-normalizing vgr's to fix sphflake? |
| 16:43.52 | n_reed | so everyone's on the same page: in the old code, plastic {di .9 sp .5} becomes plastic {{di .9 sp .5} } |
| 16:44.08 | n_reed | this doesn't parse correctly, and is the same as applying default plastic shader |
| 16:44.47 | n_reed | r47659 fixed this, causing the parameters to actually be applied, resulting in different/brighter/correct output |
| 16:49.56 | ``Erik | out of curiosity, have you tried putting in a bu_log to display the actual values used before and after the change? |
| 17:09.32 | CIA-59 | BRL-CAD: 03bob1961 * r47764 10/brlcad/trunk/src/libged/polyclip.cpp: Fix ged_export_polygon() and ged_import_polygon() to handle multiple contours. |
| 17:11.40 | CIA-59 | BRL-CAD: 03bob1961 * r47765 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Update to_data_polygons() import sub-command to set the polygon color, line-width and line-style. |
| 17:27.17 | *** join/#brlcad milamber_ (414f0e1c@gateway/web/freenode/ip.65.79.14.28) | |
| 17:27.26 | *** part/#brlcad milamber_ (414f0e1c@gateway/web/freenode/ip.65.79.14.28) | |
| 17:44.12 | n_reed | erik: I have now. Logs show that phong shader gets correct parameters before revert, and defaults after revert. |
| 17:45.48 | n_reed | furthermore, rt log from post-revert shows error messages indicating the parsing failure and change to defaults |
| 17:46.55 | n_reed | like: "ERROR mlib_setup(/all.g/rec.r) failed. material='plastic', parameters='{sp .4 di .9 re .1}'. Changing /all.g/rec.r material to default and retrying." |
| 17:50.07 | n_reed | it's actually interesting that the shaders-regress didn't fail |
| 17:51.15 | n_reed | that test never uses the tcl-list syntax so it was unaffected, but maybe now it should |
| 20:18.47 | ``Erik | iiiiinteresting: http://stevehanov.ca/blog/index.php?id=130 http://pnylab.com/pny/papers/vptree/vptree/ |
| 20:45.51 | starseeker | ``Erik: is that useful for your bot work? |
| 20:55.32 | ``Erik | nah, there's too much invested in kd trees with tie... but it might be a good approach for the nurbs trimming, among other things |
| 20:56.10 | ``Erik | it's neat stuff, though... always neat learning new data structures and all |
| 21:05.06 | *** join/#brlcad merzo (~merzo@48-62-132-95.pool.ukrtel.net) | |
| 22:39.54 | CIA-59 | BRL-CAD: 03n_reed * r47766 10/brlcad/trunk/ (6 files in 3 dirs): initial cmake build logic for perplex |
| 03:14.18 | *** join/#brlcad merzo (~merzo@51-61-132-95.pool.ukrtel.net) | |
| 06:15.42 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 09:29.24 | *** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl) | |
| 12:06.05 | *** join/#brlcad merzo (~merzo@51-61-132-95.pool.ukrtel.net) | |
| 13:22.40 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 13:36.08 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 16:11.27 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 16:17.23 | ``Erik | cl |
| 16:20.42 | ``Erik | hm, aptera is over |
| 16:33.59 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 18:54.04 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 19:13.16 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 19:52.12 | *** join/#brlcad Forth (~Forth@92.242.118.253) | |
| 20:36.05 | *** join/#brlcad merzo (~merzo@120-176-132-95.pool.ukrtel.net) | |
| 22:12.47 | starseeker | mourns, but isn't really surprised |
| 23:46.43 | *** join/#brlcad DarkCalff (DC@173.231.40.98) | |
| 02:43.27 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 02:43.27 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 05:33.42 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 05:58.31 | CIA-28 | BRL-CAD: 03brlcad * r47767 10/brlcad/trunk/src/mged/CMakeLists.txt: apparently doing seomthing wrong, so document the FIXME accordingly mged needs to depend on the tclscripts or it won't work for non default and make install target builds (e.g., make regress) |
| 06:04.45 | brlcad | wonders what he's doing wrong given that's what looks like the documented way to do it |
| 06:06.15 | CIA-28 | BRL-CAD: 03brlcad * r47768 10/brlcad/trunk/src/tclscripts/mged/CMakeLists.txt: ws |
| 12:00.51 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 15:22.33 | brlcad | n_reed: it's not inconceivable that the solids test image is flawed, but would be a little bit surprising |
| 15:24.00 | brlcad | the regression scripts used to use mater "plastic var=val var2=val2" prior to release 7.0 (open sourcing) |
| 15:25.21 | brlcad | they were all yanked at 7.0 since a couple had problems (unrelated), but then later returned a few months later in their current form |
| 15:26.12 | brlcad | presumably butler was specifically testing whether the mater "plastic {var val var2 val}" syntax worked as that was when that change was made |
| 15:31.05 | n_reed | I agree that the presence of the brace syntax suggests an intent to test said syntax |
| 15:32.41 | n_reed | still, all my testing thus far suggests that the syntax, at least recently, has not worked as intended |
| 15:34.02 | n_reed | it could be that the ineffectiveness of the brace syntax simply went unnoticed because it didn't generate any obvious errors (the raytrace and test still succeed) |
| 15:34.27 | n_reed | of course i could be wrong, and would be happying to continue investigating |
| 15:35.36 | n_reed | but honestly i think it's best if you look into it yourself, because if your not convinced one way or another, I'm not going to bother with any changes |
| 15:37.42 | n_reed | s/happying/happy/ |
| 15:37.59 | n_reed | s/your/you're |
| 15:38.38 | n_reed | need's more caffeine |
| 15:41.10 | n_reed | NEEDS more sleep too x/ |
| 15:46.54 | brlcad | I just pulled up the "original" solids reference image from before it was tclified |
| 15:47.25 | brlcad | looks like a bug |
| 15:48.04 | brlcad | OR he was intentionally testing to make sure {} syntax fails ;) |
| 15:48.49 | brlcad | that there be funny |
| 15:52.53 | brlcad | I bet I see what happened. he also added a new dsp primitive to the test, so the image already changed/needed to change |
| 15:53.16 | brlcad | so a pixdiff would have already been reporting changes, even more easy to overlook those four others that changed due to syntax |
| 15:54.50 | brlcad | n_reed: looks like you're good to un-revert your fix back in |
| 15:54.58 | brlcad | just update the reference while you're at it ;) |
| 15:55.38 | brlcad | the old one doesn't have a dsp or I'd just drop it in, needs a new reference |
| 15:56.31 | brlcad | cross-check it with a couple platforms to make sure you get no off-by errors .. |
| 15:57.13 | brlcad | wishes we had a simh vgr |
| 15:58.30 | n_reed | what is a simh vgr? |
| 15:58.53 | brlcad | vgr was the name of the original baseline reference computer |
| 15:59.24 | brlcad | the numerics were stable and rather well-understood for "correctness" |
| 16:00.39 | brlcad | the benchmark reference images were mostly all created on vgr, so then if you were on a different computer and got pixel values that were ever so slightly off, you could investigate |
| 16:01.20 | brlcad | off by more than one rgb value, and you were looking at a bug (either in code, or compiler, or hardware ... all encountered over the years) |
| 16:02.32 | brlcad | simh is the "simulation hardware" project where they simulate various legacy systems (including a couple systems very similar to vgr's hardware) |
| 16:02.54 | brlcad | basically, it's a VM for really old hardware |
| 16:03.39 | brlcad | if we could simulate vgr, we could regenerate new baseline images with a fair amount of confidence that they're "correct" |
| 16:04.32 | brlcad | two of our benchmark images frequently results in a handful of off-by-one differences -- those were the two not generated on vgr |
| 17:13.25 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 17:38.52 | CIA-28 | BRL-CAD: 03n_reed * r47769 10/brlcad/trunk/regress/solidspix.asc: changed solids-regress reference image to agree with change in output-pix caused by fix in r47659 |
| 17:47.07 | CIA-28 | BRL-CAD: 03n_reed * r47770 10/brlcad/trunk/src/libbu/parse.c: revert to previous revision |
| 19:33.03 | *** join/#brlcad merzo (~merzo@131-179-132-95.pool.ukrtel.net) | |
| 19:50.00 | *** join/#brlcad Forth (~Forth@92.242.118.253) | |
| 20:10.54 | brlcad | starseeker: how do you rebuild a specific object file? |
| 20:12.10 | brlcad | I just modified vls.c, want to make sure it still compiles, but don't want to relink libbu or some other binary .. is there some/any way to do that? |
| 20:12.49 | brlcad | old school makefile would have been a simple "make vls.o" |
| 20:22.42 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 20:24.19 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 20:28.45 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 21:45.35 | starseeker | brlcad: not sure you can :-( |
| 22:03.34 | CIA-28 | BRL-CAD: 03n_reed * r47771 10/brlcad/trunk/src/other/perplex/scanner_template.c: allow name of lexer routine and app data parameter to be specified with defines |
| 22:04.06 | CIA-28 | BRL-CAD: 03starseeker * r47772 10/brlcad/trunk/src/ (mged/CMakeLists.txt tclscripts/CMakeLists.txt): Make mged depend on all pkgIndex/tclIndex targets. Probably should do the same for archer... |
| 22:05.02 | starseeker | ah HAH! |
| 22:05.13 | starseeker | brlcad: try this: make vls.c.o |
| 22:05.58 | starseeker | I think that'll do what you want |
| 22:07.35 | starseeker | scratch that - only need to do that for archer if we make archer into a binary target ala mged |
| 22:08.12 | starseeker | unless we fake an archer build target just to hang those dependencies off of... |
| 22:08.14 | starseeker | hmm... |
| 22:16.58 | CIA-28 | BRL-CAD: 03starseeker * r47773 10/brlcad/trunk/src/archer/CMakeLists.txt: Make a stab at switching archer over to a real live build target instead of just a configure-time copy. Untested on Windows. |
| 22:20.21 | CIA-28 | BRL-CAD: 03starseeker * r47774 10/brlcad/trunk/src/archer/CMakeLists.txt: Now that we have an archer target, hang the tclscript dependencies off of it. |
| 22:21.15 | starseeker | re-reads his channel comments and realizes they're a bit mixed - brlcad, in my testing the make vls.c.o worked |
| 22:25.57 | CIA-28 | BRL-CAD: 03starseeker * r47775 10/brlcad/trunk/src/CMakeLists.txt: checking clean configure - need tclscripts target lists defined before archer and mged targets are defined so a one-shot configure gets the right information. |
| 22:39.26 | CIA-28 | BRL-CAD: 03starseeker * r47776 10/brlcad/trunk/src/archer/CMakeLists.txt: |
| 22:39.27 | CIA-28 | BRL-CAD: Archer needs some more dependencies called out (mostly tcl/tk packages it uses). |
| 22:39.27 | CIA-28 | BRL-CAD: 'make archer' now does more or less what you expect - the only exception being |
| 22:39.27 | CIA-28 | BRL-CAD: the Docbook man pages. Not sure whether to make those dependencies... |
| 22:41.45 | brlcad | starseeker: hm, looks like that'll only work if I'm in the cmake subdir for that .o, yes? |
| 22:41.48 | brlcad | should work |
| 22:42.11 | brlcad | libbu/tcl.c.o would have been cool |
| 22:44.10 | brlcad | starseeker: and what was wrong with my ADD_DEPENDENCIES() line? from my reading of the target names, that should have at least gotten the top-level tclscripts/tclIndex and pkgIndex.tcl files |
| 22:45.45 | starseeker | I think there was a capitalization error somewhere... anyway, the new logic should get 'em all |
| 22:46.05 | starseeker | tclindex vs tclIndex, I think... |
| 22:46.05 | brlcad | wouldn't it have given me an error about an unknown dep though? |
| 22:46.32 | starseeker | um. not sure - let me do a quick test |
| 22:47.08 | brlcad | and for that same reason, I added the one for pkgindex too -- or did it also have some case problem? |
| 22:47.27 | starseeker | nope - no error. It's probably figuring it will be defined later or something... |
| 22:48.11 | starseeker | not sure - as soon as I saw what you were trying to do I knew something more... energetic would be needed, so I just dove into the macro logic |
| 22:48.38 | brlcad | I knew something more generic was needed |
| 22:48.50 | starseeker | we *should* be good now |
| 22:48.50 | brlcad | more questioning why that simple test wasn't working |
| 22:49.15 | starseeker | unless you want all the docbook man pages added as dependencies of archer/mged when they're turned on |
| 22:49.20 | starseeker | ah |
| 22:49.45 | starseeker | looks again... |
| 22:49.49 | brlcad | yeah, i wasn't just trying to get past it, trying to understand what was going on |
| 22:49.53 | starseeker | yeah, it was pkgindex not pkgIndex |
| 22:49.57 | brlcad | makes sense if it's case sensitive |
| 22:50.43 | brlcad | means I DID understand everything, just a pedantic detail missing from the auto-target naming that the macro was doing |
| 22:50.46 | starseeker | must confess it's kinda cool to be able to do "make archer" and have it jsut work... |
| 22:50.49 | starseeker | right |
| 22:50.57 | brlcad | test confirmed here |
| 22:51.57 | brlcad | make regress from a new build was failing due to the scripts dep |
| 22:52.45 | brlcad | a nice side effect now is that you can "make regress", have it compile everything the regress suite uses, then make and see what else is likely not being exercised by the testing |
| 22:52.52 | starseeker | yeah, make libbu/tcl.c.o doesn't work work... at a guess, they didn't want to populate all the parent make files with all child targets... |
| 22:55.34 | starseeker | yeah, that makes sense - I was probably always running "make regress" *after* doing make all |
| 22:55.45 | starseeker | oops |
| 22:55.56 | brlcad | likewise, I just happened to have a fresh build and was testing nick's discovery |
| 22:56.06 | brlcad | s/build/checkout/ |
| 22:56.33 | starseeker | talk about an oldie... |
| 22:56.46 | brlcad | that's not old, less than 10 years ;) |
| 22:57.05 | starseeker | well, true, but I mean as part of the regression logic/data |
| 22:57.11 | starseeker | eeep |
| 22:58.19 | starseeker | brlcad: how do you want me to handle it with the thrid party packages/options? I can just document all 3rd party options in the file, or I can set it up to only document the subset that are already documented for configure.ac... |
| 22:58.25 | starseeker | third even... |
| 22:58.42 | starseeker | instructs fingers to get with the program... |
| 23:12.49 | brlcad | what do you mean? options such as? |
| 23:13.41 | brlcad | what was documented by configure? it autodocumented subconfigures and we didn't directly document anything that I'm aware of other than the enable/disable-build options |
| 23:13.45 | starseeker | well, for example, right now there aren't any descriptions for re2c, lemon, tkhtml, tkpng, etc. in INSTALL |
| 23:14.19 | brlcad | the documenting stopped when cmake docs were rolled in, those mostly all came after |
| 23:14.23 | starseeker | we do have zlib, png, opennurbs, utahrle, etc. |
| 23:14.32 | starseeker | right - so what are my criteria for adding things? |
| 23:14.34 | brlcad | so more enable/disable options |
| 23:14.52 | starseeker | vs. ignoreing 'em |
| 23:15.25 | brlcad | if they're significant enough to warrant a src/other building, they should be listed |
| 23:15.40 | starseeker | alrightie |
| 23:15.59 | brlcad | all the more reason to be cautious about adopting new deps, they have overhead to be consistent |
| 23:16.34 | brlcad | can ignore any that are going away in the next 3-6 months (like jove) |
| 23:17.33 | starseeker | won't be too bad once I get up and rolling, just wanted to be sure I wasn't wasting my time on things you didn't want documented |
| 23:18.59 | brlcad | could put re2c, lemon, and perplex into their own subdir in src/other, all toggled off just one flag |
| 23:19.34 | starseeker | really? arrgh :-) after all that nice find logic too... |
| 23:19.58 | brlcad | don't have to |
| 23:20.01 | brlcad | it's fine separate |
| 23:20.08 | brlcad | it's if you wanted to consolidate logic |
| 23:20.38 | starseeker | nods - worth keeping in mind for later, but right now I'd say leave it as-is, since it's functional |
| 23:20.46 | brlcad | similarly with hv3 under tkhtml, similarly minor |
| 23:21.50 | starseeker | nods |
| 23:22.14 | brlcad | aside from hv3 being a versioned-dir tsker |
| 23:22.35 | starseeker | should bug bob about trying that shiny new accordian widget out on the new-improved help browser |
| 23:27.39 | CIA-28 | BRL-CAD: 03starseeker * r47777 10/brlcad/trunk/src/tclscripts/CMakeLists.txt: mind the advanced markings... |
| 23:28.03 | CIA-28 | BRL-CAD: 03starseeker * r47778 10/brlcad/trunk/CMakeLists.txt: Add some aliases for the strict flags. |
| 23:43.52 | starseeker | isn't entirely sure if he cares for the idea of enable/disable options for word size |
| 23:46.20 | CIA-28 | BRL-CAD: 03brlcad * r47779 10/brlcad/trunk/src/libfb/fb_obj.c: reorder to avoid the need for forward declarations. make the command table internal to the function (yet still static so it persists). |
| 23:52.40 | CIA-28 | BRL-CAD: 03starseeker * r47780 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: build the disable options list in a different way. |
| 23:54.01 | CIA-28 | BRL-CAD: 03starseeker * r47781 10/brlcad/trunk/CMakeLists.txt: Add docs for 32/64 bit BRLCAD_WORD_SIZE |
| 23:57.52 | brlcad | they don't really make sense for word size |
| 23:58.16 | brlcad | word size is just that, unless you change it back to configure's meaning being a flag for 64-bit on/off |
| 00:35.02 | starseeker | right now I've got the enable and disable 64bit vars setting to 32/64bit... fairly compatible with the old configure behavior |
| 00:36.26 | starseeker | not particularly attached to it though if you think it's a bad move - did it mainly for compatibility with old INSTALL doc... |
| 01:19.02 | brlcad | I think that since the variable isn't defined the same way that using the old names just makes it more confusing as to what the variable actually represents |
| 01:19.50 | brlcad | it's either a word size setting or it's a toggle to turn 64-bit on/off .. shouldn't be both |
| 01:20.40 | brlcad | either makes sense |
| 01:21.32 | brlcad | the build system is deprecated, we're not aiming for compatibility or we wouldn't have needed to deprecate |
| 01:22.16 | brlcad | the goal should be clarity, simplicity, and as dead-obvious easy-to-use as we can make it |
| 01:43.05 | starseeker | works for me |
| 01:45.27 | CIA-28 | BRL-CAD: 03starseeker * r47782 10/brlcad/trunk/CMakeLists.txt: Nevermind - we have a different variable, so don't emulate the old system for 64 bit. |
| 01:48.36 | CIA-28 | BRL-CAD: 03starseeker * r47783 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: begone debug printout |
| 03:46.48 | *** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl) | |
| 04:26.46 | *** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl) | |
| 05:34.26 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 05:35.26 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 06:07.37 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 07:50.41 | brlcad | aaaalmost done reworking the bu_cmd() interface to all be devoid of tcl and to update all callers accordingly... |
| 10:31.58 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 11:49.33 | CIA-28 | BRL-CAD: 03brlcad * r47784 10/brlcad/trunk/ (15 files in 2 dirs): make the file argument to if_open() const. |
| 11:57.39 | CIA-28 | BRL-CAD: 03brlcad * r47785 10/brlcad/trunk/src/libfb/tcl.c: reorder to avoid forward decls, make cmdtab private to init func. |
| 12:06.46 | CIA-28 | BRL-CAD: 03brlcad * r47786 10/brlcad/trunk/src/libtclcad/tclcad.c: |
| 12:06.46 | CIA-28 | BRL-CAD: provide an alternative to bu_register_cmds() so we can make remove the bu func |
| 12:06.46 | CIA-28 | BRL-CAD: as a minimally impacting API change. to do this, we need to wrap the bu_cmdtab |
| 12:06.46 | CIA-28 | BRL-CAD: functions since they're similarly undergoing a signature change to eliminate the |
| 12:06.46 | CIA-28 | BRL-CAD: tcl binding. |
| 12:08.03 | CIA-28 | BRL-CAD: 03brlcad * r47787 10/brlcad/trunk/include/tclcad.h: declare/export the new tclcad_register_cmds() function so we can eliminate bu_register_cmds(). |
| 12:08.14 | CIA-28 | BRL-CAD: 03brlcad * r47788 10/brlcad/trunk/src/libtclcad/tclcad.c: remove extra semi |
| 12:11.35 | CIA-28 | BRL-CAD: 03brlcad * r47789 10/brlcad/trunk/src/libfb/ (if_X24.c if_ogl.c if_wgl.c): propagate const to all of the argv of the various open_existing() functions |
| 12:22.45 | CIA-28 | BRL-CAD: 03indianlarry * r47790 10/brlcad/trunk/src/other/step/src/clstepcore/sdaiString.h: Fixed asStr(), was broken in the scl_string -> std::string rework. |
| 12:23.16 | CIA-28 | BRL-CAD: 03indianlarry * r47791 10/brlcad/trunk/src/other/step/src/clstepcore/STEPattribute.cc: Looks like possible debugging code left in during the scl_string -> std::string rework breaking STEPattribute::is_null() for STRING_TYPE and BINARY_TYPE, commented out for now. |
| 14:03.20 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 14:16.59 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 15:05.28 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 16:03.35 | CIA-28 | BRL-CAD: 03n_reed * r47792 10/brlcad/trunk/src/other/perplex/scanner_template.c: readability |
| 16:39.54 | CIA-28 | BRL-CAD: 03n_reed * r47793 10/brlcad/trunk/src/other/perplex/ (perplex.h scanner.re): allow C comments in rules section |
| 17:21.07 | CIA-28 | BRL-CAD: 03brlcad * r47794 10/brlcad/trunk/src/libged/ (vdraw.c view_obj.c wdb_vdraw.c): move the static command tables into the functions that use them |
| 17:23.13 | CIA-28 | BRL-CAD: 03brlcad * r47795 10/brlcad/trunk/src/libged/dg_obj.c: move the static command table into the function that uses it |
| 17:33.51 | CIA-28 | BRL-CAD: 03n_reed * r47796 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.h scanner.re): add support for re2c named-definitions syntax |
| 17:44.07 | CIA-28 | BRL-CAD: 03brlcad * r47797 10/brlcad/trunk/src/libged/ (dg_obj.c wdb_nirt.c): massive reordering to eliminate forward declarations. moved dgo_pr_wait_status to nirt as pr_wait_status since that's the only place it's used. |
| 17:54.16 | CIA-28 | BRL-CAD: 03brlcad * r47798 10/brlcad/trunk/src/libged/wdb_obj.c: more massive reordering to eliminate forward decls |
| 18:08.07 | CIA-28 | BRL-CAD: 03starseeker * r47799 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: go full path on src/other executables, since if we're trying to build bundled and there is a system version of the exec present in path, the target name will end up calling the system binary when it trys to run. |
| 18:35.54 | CIA-28 | BRL-CAD: 03n_reed * r47800 10/brlcad/trunk/src/other/perplex/parser.y: reduce code duplication |
| 19:13.23 | CIA-28 | BRL-CAD: 03r_weiss * r47801 10/brlcad/trunk/src/libbu/pool.c: New code for memory pooling within libbu. This is a work is progress. Adding file "pool.c". |
| 19:17.45 | CIA-28 | BRL-CAD: 03r_weiss * r47802 10/brlcad/trunk/src/libbu/Makefile.am: Update to "Makefile.am" to add file "pool.c" to libbu. |
| 19:18.54 | CIA-28 | BRL-CAD: 03r_weiss * r47803 10/brlcad/trunk/src/libbu/CMakeLists.txt: Update to file "CMakeLists.txt" to add file "pool.c" to libbu. |
| 19:26.05 | CIA-28 | BRL-CAD: 03brlcad * r47804 10/brlcad/trunk/src/conv/step/Axis2Placement3D.cpp: possibly unitialized, init with VINIT_ZERO |
| 19:32.59 | CIA-28 | BRL-CAD: 03r_weiss * r47805 10/brlcad/trunk/include/bu.h: Update to include file "bu.h", adding definitions for memory pool functions "bu_get_elem_from_pool" and "bu_free_elem_pool". |
| 19:37.55 | CIA-28 | BRL-CAD: 03n_reed * r47806 10/brlcad/trunk/src/other/perplex/parser.y: remove debug output |
| 19:38.02 | CIA-28 | BRL-CAD: 03brlcad * r47807 10/brlcad/trunk/src/conv/step/ (169 files): indent |
| 19:56.21 | CIA-28 | BRL-CAD: 03n_reed * r47808 10/brlcad/trunk/src/other/perplex/scanner.re: Testing cursor position to detect exhaustion of buffered input, so don't append null at EOI, which caused parsing failure in some cases, and put restrictions on patterns. |
| 20:24.18 | CIA-28 | BRL-CAD: 03n_reed * r47809 10/brlcad/trunk/src/other/perplex/ (perplex.h scanner.re scanner_template.c): have caller specify end of string input rather than testing for null |
| 20:27.50 | CIA-28 | BRL-CAD: 03r_weiss * r47810 10/brlcad/trunk/include/nmg.h: Update to "nmg.h" to enable the new libbu memory pooling for nmg structures. |
| 20:40.49 | CIA-28 | BRL-CAD: 03r_weiss * r47811 10/brlcad/trunk/src/librt/db5_io.c: Update to file "db5_io.c" for function "db5_get_raw_internal_fp" within librt to enable new libbu memory pooling. |
| 20:42.15 | CIA-28 | BRL-CAD: 03r_weiss * r47812 10/brlcad/trunk/src/librt/db5_scan.c: Update to file "db5_scan.c" for function "db5_scan" within librt to enable the new libbu memory pooling. |
| 21:45.57 | CIA-28 | BRL-CAD: 03n_reed * r47813 10/brlcad/trunk/src/other/perplex/scanner_template.c: sync r47808 changes to template |
| 21:54.54 | CIA-28 | BRL-CAD: 03brlcad * r47814 10/brlcad/trunk/src/libged/view_obj.c: reorder to eliminate forward decls |
| 21:55.43 | CIA-28 | BRL-CAD: 03brlcad * r47815 10/brlcad/trunk/src/libged/view_obj.c: indent |
| 22:20.25 | CIA-28 | BRL-CAD: 03brlcad * r47816 10/brlcad/trunk/include/ (CMakeLists.txt Makefile.am ged.h obj.h): add new obj.h header with the remaining view_obj and ged_obj structures that are in ged.h; don't want or need them, especially for libged. |
| 22:22.42 | CIA-28 | BRL-CAD: 03brlcad * r47817 10/brlcad/trunk/include/ged.h: need fbserv_obj.h for structure decls. another dependency that should be decoupled.. |
| 22:24.25 | CIA-28 | BRL-CAD: 03brlcad * r47818 10/brlcad/trunk/ (4 files in 2 dirs): propagate obj.h where necessary |
| 22:27.45 | CIA-28 | BRL-CAD: 03starseeker * r47819 10/brlcad/trunk/ (4 files in 3 dirs): Make sure the executables are present before we try doing anything with them. |
| 22:28.17 | CIA-28 | BRL-CAD: 03brlcad * r47820 10/brlcad/trunk/src/gtools/g_diff.c: looks like wdb objects are used here by g_diff.. need to remove dependency since code is going away. |
| 22:32.41 | CIA-28 | BRL-CAD: 03n_reed * r47821 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.h scanner.re): fixed support of re2c state transition syntax, broken by r47796 |
| 22:49.37 | CIA-28 | BRL-CAD: 03brlcad * r47822 10/brlcad/trunk/include/obj.h: give the obj structures a tcl_index stash-point so their funcs don't need to pass it explicitly |
| 00:40.23 | CIA-28 | BRL-CAD: 03brlcad * r47823 10/brlcad/trunk/ (include/raytrace.h src/librt/primitives/bot/bot.c): make rt_bot_smooth() bot name be const |
| 01:20.53 | CIA-28 | BRL-CAD: 03brlcad * r47824 10/brlcad/trunk/TODO: deprecation statements added, progress underway to rework rtarea. |
| 01:22.04 | CIA-28 | BRL-CAD: 03brlcad * r47825 10/brlcad/trunk/NEWS: given this is a minor bump and we're a week deep, release should be stabilized by the end of dec. |
| 01:27.15 | CIA-28 | BRL-CAD: 03starseeker * r47826 10/brlcad/trunk/src/archer/CMakeLists.txt: Er, right - iwidgets isn't a build target... |
| 01:28.04 | CIA-28 | BRL-CAD: 03brlcad * r47827 10/brlcad/trunk/src/libdm/dm_obj.c: reorder to eliminate forward decls. move command table into function scope. staticness of data shouldn't be marked with HIDDEN. |
| 01:53.42 | brlcad | oooooooow... to painful to de-tcl |
| 01:53.49 | brlcad | s/to pain/so pain/ |
| 02:11.09 | brlcad | a nearly 8k loc patch, damn sucky |
| 02:11.41 | brlcad | and that's not even all of it, that's fixing just two (pervasive) functions |
| 02:11.50 | louipc | ! |
| 02:15.31 | brlcad | of course fixing those two functions ended up affecting the signatures to about 2000 other functions |
| 02:34.52 | brlcad | gives his pinky a rest |
| 02:35.13 | CIA-28 | BRL-CAD: 03brlcad * r47828 10/brlcad/trunk/ (32 files in 9 dirs): (log message trimmed) |
| 02:35.13 | CIA-28 | BRL-CAD: De-tcl two rather intertwined libbu functions, bu_observer_cmd() and bu_cmd(), |
| 02:35.14 | CIA-28 | BRL-CAD: along with all of the command history functions. Define bu_cmdtab callback |
| 02:35.14 | CIA-28 | BRL-CAD: signature so we get proper type checking, but instead of clientdata+tclinterp, |
| 02:35.14 | CIA-28 | BRL-CAD: make it a void* and make argv const. Those changes end up impacting nearly 8k |
| 02:35.14 | CIA-28 | BRL-CAD: lines of caller code where we have to update the (mostly-but-not-all-deprecated) |
| 02:35.15 | CIA-28 | BRL-CAD: various "tcl object" codes to pass their data around within the new observer and |
| 04:00.18 | CIA-28 | BRL-CAD: 03starseeker * r47829 10/brlcad/trunk/ (185 files in 19 dirs): (log message trimmed) |
| 04:00.19 | CIA-28 | BRL-CAD: Coming very close to building xsltproc cross-platform for guaranteed |
| 04:00.19 | CIA-28 | BRL-CAD: docbook->html documentation generation. Only known problem is on Windows, and |
| 04:00.19 | CIA-28 | BRL-CAD: that seems to be primarily related to the new catalog usage with the advanced |
| 04:00.19 | CIA-28 | BRL-CAD: Docbook formatting (to the best of my knowledge, the new Docbook formatting |
| 04:00.19 | CIA-28 | BRL-CAD: logic has never been tested on Windows before.) Setting environment variables |
| 04:00.20 | CIA-28 | BRL-CAD: in the CMake COMMAND lines didn't go over well on Windows, so have shifted to a |
| 04:14.59 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 06:52.47 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 09:57.49 | CIA-28 | BRL-CAD: 0394.122.66.247 07http://brlcad.org * r3249 10/wiki/Talk:Main_Page: |
| 11:26.41 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 11:28.04 | *** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 15:47.19 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 17:14.58 | CIA-28 | BRL-CAD: 03erikgreenwald * r47830 10/brlcad/trunk/include/ (CMakeLists.txt Makefile.am icv.h): add icv.h |
| 17:20.36 | CIA-28 | BRL-CAD: 03starseeker * r47831 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: Don't automatically flag a BRLCAD_OPTION as advanced... |
| 17:23.12 | CIA-28 | BRL-CAD: 03starseeker * r47832 10/brlcad/trunk/src/other/xsltproc/ (CMakeLists.txt libxml/CMakeLists.txt libxml/src/xmlIO.c): Tweaks to try improving build on Windows... |
| 17:28.14 | CIA-28 | BRL-CAD: 03erikgreenwald * r47833 10/brlcad/trunk/ (5 files in 2 dirs): copy bu_image stuff into icv |
| 17:32.50 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 17:33.50 | CIA-28 | BRL-CAD: 03erikgreenwald * r47834 10/brlcad/trunk/ (doc/deprecation.txt src/libbu/image.c): list bu_image_* as deprecated |
| 17:57.05 | CIA-28 | BRL-CAD: 03erikgreenwald * r47835 10/brlcad/trunk/src/ (10 files in 3 dirs): bu_image -> icv_image |
| 18:32.09 | CIA-28 | BRL-CAD: 03erikgreenwald * r47836 10/brlcad/trunk/src/libgcv/ (6 files): break moller triangle intersection stuff out into seperate file |
| 18:33.13 | brlcad | ``Erik: nifty .. considered that myself a while back |
| 18:33.26 | ``Erik | which? bu_image -> icv? |
| 18:33.48 | brlcad | yep |
| 18:34.33 | brlcad | fwiw, it's minimally impacting (meaning you can remove the bu_image* stuff) if caller code can be updated with a simple regex |
| 18:34.34 | ``Erik | I doubt any third party stuff is using bu_image, but I'll wait before eradicating it (and removing the png dependancy of libbu) *shrug* |
| 18:35.00 | ``Erik | well, then... it's gone :D is that a NEWS item? |
| 18:35.06 | brlcad | nope |
| 18:35.20 | brlcad | regex goes into the bottom of doc/deprecation |
| 18:36.34 | brlcad | NEWS is only "user-visible", which is not extended to "developer users" .. just folks that run the binaries |
| 18:37.06 | brlcad | the equivalent for devs is "the source is the documentation" |
| 18:37.13 | brlcad | and doc/deprecation.txt of course :) |
| 18:37.13 | ``Erik | test builds |
| 18:37.50 | ``Erik | yeh, hadn't looked at the bottom of deprecation.txt ... and doubted the sed4 script was still right |
| 18:38.55 | brlcad | only the first (oldest v4->v5 api) one is sed, the rest are perl |
| 18:39.18 | brlcad | perl -0777 -pi -e 'EXPRESSION' FILE |
| 18:39.39 | brlcad | should work with most if not all of them |
| 18:40.30 | brlcad | main diff is using \( \) to capture \1 \2 \3 matches, () match literal |
| 18:42.51 | CIA-28 | BRL-CAD: 03brlcad * r47837 10/brlcad/trunk/TODO: |
| 18:42.51 | CIA-28 | BRL-CAD: others may work on annotations, so dump core. provide all the nitty gritty |
| 18:42.51 | CIA-28 | BRL-CAD: details for what is needed from a GD&T perspective. focus is fully generalized |
| 18:42.51 | CIA-28 | BRL-CAD: compact binary on-disk form specified via user-friendly command-line interface. |
| 18:42.52 | CIA-28 | BRL-CAD: include references as there are standard conventions (iso and asme) expected on |
| 18:42.52 | CIA-28 | BRL-CAD: how they're presented. initial stab implementation should focus on text and |
| 18:42.53 | CIA-28 | BRL-CAD: leader annotations.. |
| 18:44.35 | CIA-28 | BRL-CAD: 03erikgreenwald * r47838 10/brlcad/trunk/ (4 files in 3 dirs): eradicate bu_image. s/bu_image/icv_image/g;s/BU_IMAGE/ICV_IMAGE/g (and link libicv) to migrate. |
| 18:48.52 | CIA-28 | BRL-CAD: 03brlcad * r47839 10/brlcad/trunk/TODO: the radius 'R' has come before the value since 1982. get it right. |
| 18:53.40 | ``Erik | neat, link breakage |
| 19:08.55 | CIA-28 | BRL-CAD: 03erikgreenwald * r47840 10/brlcad/trunk/src/libicv/CMakeLists.txt: Fix link error. Apparently cmake uses arg ordering, not the duck method. |
| 19:31.49 | CIA-28 | BRL-CAD: 03erikgreenwald * r47841 10/brlcad/trunk/src/ (fb/CMakeLists.txt util/CMakeLists.txt): add PNG_LIBRARY to programs needs libpng (was getting it from libbu before) |
| 19:36.15 | CIA-28 | BRL-CAD: 03erikgreenwald * r47842 10/brlcad/trunk/src/libbu/CMakeLists.txt: add math lib |
| 20:05.59 | brlcad | that mean you removed libpng from libbu? |
| 20:08.39 | ``Erik | yeah |
| 20:22.08 | starseeker | hmm... another new opennurbs is out |
| 20:31.14 | CIA-28 | BRL-CAD: 03brlcad * r47843 10/brlcad/trunk/src/libbu/tcl.c: bu_cmdtab callbacks take a void* |
| 20:39.46 | CIA-28 | BRL-CAD: 03brlcad * r47844 10/brlcad/trunk/src/libbu/tcl.c: |
| 20:39.46 | CIA-28 | BRL-CAD: fix the first of hopefully few bugs injected with the de-tcl'ing of libbu. in |
| 20:39.46 | CIA-28 | BRL-CAD: order for these script callbacks to return a tcl value, they need to be set as |
| 20:39.46 | CIA-28 | BRL-CAD: the result. noticed the '?' command no longer working in mged due to |
| 20:39.46 | CIA-28 | BRL-CAD: bu_brlcad_data printing but not returning the path. |
| 21:06.30 | CIA-28 | BRL-CAD: 03starseeker * r47845 10/brlcad/trunk/src/other/xsltproc/libxslt/CMakeLists.txt: no default path for win32 platforms |
| 21:24.11 | brlcad | woot distcheck succeeds |
| 21:24.17 | brlcad | er, regress rather |
| 23:46.47 | CIA-28 | BRL-CAD: 03brlcad * r47846 10/brlcad/trunk/ (10 files in 5 dirs): |
| 23:46.48 | CIA-28 | BRL-CAD: make a minimally impacting change to bu_cmd()'s signature swapping the arguments |
| 23:46.48 | CIA-28 | BRL-CAD: so they are inputs followed by outputs convention. add a new result parameter |
| 23:46.48 | CIA-28 | BRL-CAD: so we can distinguish between commands that don't exist and commands that fail. |
| 23:46.48 | CIA-28 | BRL-CAD: the return value now indicates existence only while the result parameter will |
| 23:46.48 | CIA-28 | BRL-CAD: contain the command's return value. this allows us to fix a few caller |
| 23:46.49 | CIA-28 | BRL-CAD: instances that needed to distinguish the two. |
| 23:49.05 | CIA-28 | BRL-CAD: 03brlcad * r47847 10/brlcad/trunk/doc/deprecation.txt: |
| 23:49.05 | CIA-28 | BRL-CAD: document the minimally impacting change to bu_cmd() and (hopefully, untested) |
| 23:49.05 | CIA-28 | BRL-CAD: fix several other minimally impacting regexes that escaped ()'s incorrectly. |
| 23:49.05 | CIA-28 | BRL-CAD: perl captures matches with () and matches literals with \(\). logic was |
| 23:49.05 | CIA-28 | BRL-CAD: reversed. |
| 23:52.20 | CIA-28 | BRL-CAD: 03brlcad * r47848 10/brlcad/trunk/src/libged/dg_obj.c: potential crasher due to bad decl. wdb_print_node() no longer takes an interp. |
| 00:15.54 | CIA-28 | BRL-CAD: 03r_weiss * r47849 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: Update to function nmg_crackshells in file 'nmg_inter.c'. Improved bounding box checking to determine which faces will be intersected. This improves the speed of boolean operations on nmg objects. |
| 00:18.39 | CIA-28 | BRL-CAD: 03r_weiss * r47850 10/brlcad/trunk/include/vmath.h: Updated include file 'vmath.h' adding the macro 'V3RPP_DISJOINT_TOL'. |
| 00:24.06 | *** join/#brlcad cjdevlin (~devlin@d118-75-244-176.try.wideopenwest.com) | |
| 00:50.48 | CIA-28 | BRL-CAD: 03brlcad * r47851 10/brlcad/trunk/ (13 files in 4 dirs): (log message trimmed) |
| 00:50.48 | CIA-28 | BRL-CAD: avoid the assumption that tol is a bn_tol. since they all just call the |
| 00:50.48 | CIA-28 | BRL-CAD: distance tolerance, leave it up to the caller to provide the value so as an API |
| 00:50.48 | CIA-28 | BRL-CAD: call, it only needs to be a tolerance value instead of a struct. propagate |
| 00:50.48 | CIA-28 | BRL-CAD: accordingly throughout nmg. also leave FIXME notes for three macros that are |
| 00:50.49 | CIA-28 | BRL-CAD: apparently using >= and <= comparisons with floating point values where the '=' |
| 00:50.50 | CIA-28 | BRL-CAD: case is not guaranteed to give stable behavior. the testing interval must be an |
| 00:51.24 | brlcad | open interval |
| 00:55.06 | CIA-28 | BRL-CAD: 03brlcad * r47852 10/brlcad/trunk/src/libfb/fb_obj.c: oops, libfb dir slipped through the cracks. apply bu_cmd() signature change. |
| 01:05.08 | CIA-28 | BRL-CAD: 03brlcad * r47853 10/brlcad/trunk/doc/deprecation.txt: V3*_TOL() macros in vmath used to assume a structure with a ->dist element, which is kinda silly from an API standpoint. made them be a simple tolerance value. |
| 01:05.23 | CIA-28 | BRL-CAD: 03brlcad * r47854 10/brlcad/trunk/src/libbu/Makefile.am: image.c is no more here, he go home now |
| 01:09.39 | CIA-28 | BRL-CAD: 03brlcad * r47855 10/brlcad/trunk/src/libgcv/CMakeLists.txt: soup.h and tri_intersect.h missing from decls |
| 01:10.03 | brlcad | ../../src/libged/.libs/libged.so: undefined reference to `icv_image_save_open' |
| 01:10.27 | brlcad | tools build, missing some libs decls |
| 02:22.42 | CIA-28 | BRL-CAD: 03starseeker * r47856 10/brlcad/trunk/doc/docbook/ (CMakeLists.txt books/en/CMakeLists.txt): |
| 02:22.42 | CIA-28 | BRL-CAD: Well, the downloadable Windows xsltproc isn't succeeding either, and at least |
| 02:22.42 | CIA-28 | BRL-CAD: some of the failure signature looks similar. Time to figure out why. Also, |
| 02:22.42 | CIA-28 | BRL-CAD: need some fixes to executable calls - quite in docbook logic to allow for spaces |
| 02:22.43 | CIA-28 | BRL-CAD: in pathnames (there'll probably be a lot more of this needed later on...) Still |
| 02:22.43 | CIA-28 | BRL-CAD: need to rework the third party exec macro somewhat to allow for manual |
| 02:22.44 | CIA-28 | BRL-CAD: specification of the executable path. |
| 02:30.18 | *** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl) | |
| 03:56.34 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 04:28.51 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 04:50.02 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 05:17.05 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 05:28.55 | CIA-28 | BRL-CAD: 03Sean 07http://brlcad.org * r3250 10/wiki/Talk:Main_Page: Reverted edits by [[Special:Contributions/94.122.66.247|94.122.66.247]] ([[User talk:94.122.66.247|Talk]]); changed back to last version by [[User:Sean|Sean]] |
| 05:29.03 | CIA-28 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:94.122.66.247]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 06:03.15 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 06:22.18 | CIA-28 | BRL-CAD: 03brlcad * r47857 10/brlcad/trunk/include/bu.h: |
| 06:22.19 | CIA-28 | BRL-CAD: create corollary macros for BU_GETSTRUCT(), BU_GETUNION(), and BU_GETTYPE() |
| 06:22.19 | CIA-28 | BRL-CAD: named BU_PUTSTRUCT(), BU_PUTUNION(), and BU_PUTTYPE() respectively. regardless, |
| 06:22.19 | CIA-28 | BRL-CAD: deprecate at least the struct/union macros in favor of the single type-agnostic |
| 06:22.19 | CIA-28 | BRL-CAD: macro (though a better name might be simply BU_GET() and BU_PUT() to avoid the |
| 06:22.19 | CIA-28 | BRL-CAD: klunky TT-name) |
| 06:31.53 | CIA-28 | BRL-CAD: 03brlcad * r47858 10/brlcad/trunk/src/libbu/pool.c: ws indent consistency cleanup |
| 06:34.56 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 07:04.31 | CIA-28 | BRL-CAD: 03brlcad * r47859 10/brlcad/trunk/ (5 files in 3 dirs): (log message trimmed) |
| 07:04.31 | CIA-28 | BRL-CAD: rename the new libbu pool routines to be consistent with the existing libbu api. |
| 07:04.31 | CIA-28 | BRL-CAD: groups functions are bu_GROUP prefix, so rename bu_get_elem_from_pool() to |
| 07:04.31 | CIA-28 | BRL-CAD: bu_pool_get() and bu_free_elem_pool() to bu_pool_put() respectively. rename all |
| 07:04.31 | CIA-28 | BRL-CAD: of the non-public implementation functions with a non-'bu_' and simpler 'pool_' |
| 07:04.31 | CIA-28 | BRL-CAD: prefix. update existing callers accordingly. added notes on a few show-stopper |
| 07:04.32 | CIA-28 | BRL-CAD: issues in the implementation, namely semaphore locking issues and not building |
| 09:58.08 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 14:17.46 | *** join/#brlcad piksi (~piksi@pi-xi.net) | |
| 14:49.50 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 15:17.22 | brlcad | howdy d_rossberg, ltns |
| 15:34.00 | d_rossberg | writing reports as every year's end |
| 16:13.27 | brlcad | fun fun, sorry :) |
| 16:13.41 | CIA-28 | BRL-CAD: 03brlcad * r47860 10/brlcad/trunk/include/bu.h: |
| 16:13.41 | CIA-28 | BRL-CAD: implement more generalized BU_GET() and BU_PUT() macros intended to replace |
| 16:13.41 | CIA-28 | BRL-CAD: BU_GETSTRUCT(), BU_GETUNION(), and BU_GETTYPE(). these versions should provided |
| 16:13.41 | CIA-28 | BRL-CAD: added application security by guaranteeing zero-init and sanity cleanup when |
| 16:13.41 | CIA-28 | BRL-CAD: released/put. used appropriately, they become convenient places to hook in a |
| 16:13.41 | CIA-28 | BRL-CAD: pool allocator given the allocations are intrinsically small and defined as |
| 16:13.42 | CIA-28 | BRL-CAD: dynamic. |
| 16:36.56 | CIA-28 | BRL-CAD: 03starseeker * r47861 10/brlcad/trunk/doc/docbook/ (5 files in 2 dirs): |
| 16:36.57 | CIA-28 | BRL-CAD: Rework the docbook logic again, to not use the catalog file - as near as I can |
| 16:36.57 | CIA-28 | BRL-CAD: tell, it's just using the catalog file to all 'abbreviated' paths in a couple |
| 16:36.57 | CIA-28 | BRL-CAD: other style files. Rather than do that, we can just make them .in files and |
| 16:36.57 | CIA-28 | BRL-CAD: have CMake fill in the paths directly. Hopefully will put less strain on |
| 16:36.57 | CIA-28 | BRL-CAD: xsltproc... |
| 16:38.32 | CIA-28 | BRL-CAD: 03starseeker * r47862 10/brlcad/trunk/doc/docbook/resources/brlcad/ (9 files): Clear out files not needed by the CMake build (may have to put 'em back for autotools, so doing this as a separate commit to be easily reverted if need be.) |
| 17:10.13 | ``Erik | heh, forget DRY, let's do WET (write everything twice)! :D |
| 18:14.21 | CIA-28 | BRL-CAD: 03r_weiss * r47863 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: Cleanup of function 'nmg_crackshells' in file 'nmg_inter.c'. |
| 18:52.52 | brlcad | ``Erik: heh |
| 18:53.22 | CIA-28 | BRL-CAD: 03r_weiss * r47864 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: Update to function 'nmg_crackshells' to be consistent with macro changes. |
| 18:53.57 | brlcad | this will be valuable to us: http://www.itworld.com/software/231515/usenix-dartmouth-expanding-diff-grep-unix-tools |
| 18:54.18 | brlcad | not exactly what I had in mind for GS diffing, but it would probably work just as well |
| 19:16.23 | CIA-28 | BRL-CAD: 03brlcad * r47865 10/brlcad/trunk/ (194 files in 57 dirs): |
| 19:16.23 | CIA-28 | BRL-CAD: convert instances of the ol' BU_GETSTRUCT() macro over to the new BU_GET() |
| 19:16.24 | CIA-28 | BRL-CAD: macro. callers now have to specify the full type (gasp, have to type struct .. |
| 19:16.24 | CIA-28 | BRL-CAD: which they still had to type with bu_getSTRUCT...) which should help reduce |
| 19:16.28 | CIA-28 | BRL-CAD: obfuscation for new devs (and reduces 3 API macros to 1). |
| 19:20.54 | starseeker | www.cs.dartmouth.edu/reports/TR2011-705.pdf |
| 19:22.31 | starseeker | no code yet, I take it |
| 19:22.35 | CIA-28 | BRL-CAD: 03brlcad * r47866 10/brlcad/trunk/ (34 files in 14 dirs): convert instances of the ol' BU_GETUNION() macro over to the new BU_GET() macro. callers now have to specify the full type which should help reduce obfuscation for new devs. |
| 19:26.30 | starseeker | was plotting to look into libxdiff at some point... http://www.xmailserver.org/xdiff-lib.html |
| 19:29.58 | CIA-28 | BRL-CAD: 03brlcad * r47867 10/brlcad/trunk/src/ (2 files in 2 dirs): last one, only a couple BU_GETTYPE() callers |
| 19:36.07 | CIA-28 | BRL-CAD: 03starseeker * r47868 10/brlcad/trunk/doc/docbook/resources/brlcad/ (3 files): go from file:// to file:/// in xsl files, per suggestion from xml/xslt devs - unix doesn't seem to care, but on Windows it appears to matter... reindent as well |
| 19:50.32 | CIA-28 | BRL-CAD: 03r_weiss * r47869 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: Update to function 'nmg_crackshells' in file 'nmg_inter.c' to quiet compiler warnings of signed/unsighed compares. |
| 20:02.06 | CIA-28 | BRL-CAD: 03starseeker * r47870 10/brlcad/trunk/doc/docbook/resources/brlcad/brlcad-man-stylesheet.xsl.in: fully qualify center-table-print path |
| 20:40.41 | CIA-28 | BRL-CAD: 03r_weiss * r47871 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: Updated function 'nmg_bool' in file 'nmg_bool.c'. Removed unnecessary checking for dangling faces. This will improve the speed of nmg boolean operations. |
| 21:22.54 | CIA-28 | BRL-CAD: 03starseeker * r47872 10/brlcad/trunk/src/other/xsltproc/ (libxml/CMakeLists.txt libxslt/CMakeLists.txt): Modules aren't behaving well on Windows for some reason, and we don't seem to need them anyway - disable |
| 21:24.38 | CIA-28 | BRL-CAD: 03brlcad * r47873 10/brlcad/trunk/src/remrt/remrt.c: BU_GETSTRUCT->BU_GET |
| 21:25.34 | CIA-28 | BRL-CAD: 03brlcad * r47874 10/brlcad/trunk/ (doc/deprecation.txt include/bu.h): replacement of BU_GETSTRUCT/UNION/TYPE with BU_GET are all minimally impacting, so go ahead and remove them now |
| 21:41.52 | CIA-28 | BRL-CAD: 03starseeker * r47875 10/brlcad/trunk/doc/docbook/ (5 files in 3 dirs): |
| 21:41.52 | CIA-28 | BRL-CAD: Take the 'write a cmake script file' to its logical conclusion and have a |
| 21:41.52 | CIA-28 | BRL-CAD: template that is configured for each target. Simplifies the 'in CMakeLists.txt' |
| 21:41.52 | CIA-28 | BRL-CAD: logic and avoids duplication, and if we need more tweakage on running xsltproc |
| 21:41.52 | CIA-28 | BRL-CAD: or fop it's a lot simpler. |
| 22:00.11 | CIA-28 | BRL-CAD: 03starseeker * r47876 10/brlcad/trunk/src/libged/dg_obj.c: Fix some stuff in ifdef win32 code related to the bu tcl changes |
| 22:03.11 | CIA-28 | BRL-CAD: 03bob1961 * r47877 10/brlcad/trunk/src/libbu/tcl.c: Changed free() back to Tcl_Free(). |
| 22:22.34 | CIA-28 | BRL-CAD: 03brlcad * r47878 10/brlcad/trunk/ (4 files in 2 dirs): remove the obsolete libbu.3 manual page that has fallen significantly out of sync with the library API. migrate the (still useful) documentation bits into the bu.h header as doxygen comments for future doc purposing. |
| 22:27.47 | CIA-28 | BRL-CAD: 03starseeker * r47879 10/brlcad/trunk/src/other/perplex/CMakeLists.txt: Don't assume the math library - bad assumption on Windows |
| 22:56.07 | CIA-28 | BRL-CAD: 03brlcad * r47880 10/brlcad/trunk/ (7 files in 7 dirs): prefix the cmd.h defines with BU_ since they are part of the libbu api |
| 22:56.33 | brlcad | note to self, check on archer drawing geometry: bu_get_value_by_keyword messages |
| 23:13.43 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 23:18.17 | CIA-28 | BRL-CAD: 03brlcad * r47881 10/brlcad/trunk/src/libdm/dm-rtgl.c: crash reported by Peter Machon ( muhala ) via sf bu report 3454338 that detected a bad magic failure on segs from rtgl's hit callback (finding a bu_list instead of a seg). it's not used so just don't perform that check. |
| 00:50.20 | CIA-28 | BRL-CAD: 03starseeker * r47882 10/brlcad/trunk/ (7 files in 5 dirs): Make another stab at reworking the third party executable logic - idea is to support specifying the full path to an executable from the command line and have 'the right thing' happen. |
| 01:16.03 | CIA-28 | BRL-CAD: 03starseeker * r47883 10/brlcad/trunk/src/libged/dg_obj.c: argc is int and i is size_t... |
| 01:28.13 | CIA-28 | BRL-CAD: 03starseeker * r47884 10/brlcad/trunk/src/archer/archer: Tweak wording |
| 01:47.32 | CIA-28 | BRL-CAD: 03starseeker * r47885 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: whoops - mark as advanced |
| 02:01.20 | CIA-28 | BRL-CAD: 03starseeker * r47886 10/brlcad/trunk/CMakeLists.txt: |
| 02:01.20 | CIA-28 | BRL-CAD: Slightly alter the pdf options logic, to avoid unexpected behavior. By default, |
| 02:01.20 | CIA-28 | BRL-CAD: when enabling PDF building, ALL pdfs are now built. The PDF_MAN option still |
| 02:01.20 | CIA-28 | BRL-CAD: appears after PDF is enabled, but it defaults to on rather than off to avoid |
| 02:01.20 | CIA-28 | BRL-CAD: surprises - avoids the 'why didn't the man page pdfs get built even though I |
| 02:01.20 | CIA-28 | BRL-CAD: enabled pdf?' question. |
| 02:05.40 | starseeker | ah, FINALLY - a successful generation of an html man page on Windows |
| 02:05.56 | starseeker | will try the full build later to see what's still busted |
| 04:13.12 | CIA-28 | BRL-CAD: 03starseeker * r47887 10/brlcad/trunk/src/other/openNURBS/CMakeLists.txt: Do as the parent does when building static/shared libraries, opennurbs |
| 04:38.09 | starseeker | learns another nifty vim trick - gq for dealing with long lines :-) |
| 05:23.48 | starseeker | watches bemusedly as KDevelop tries to slug it out with BRL-CAD's toplevel CMakeLists.txt file... |
| 07:07.34 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 07:26.55 | starseeker | note to self - do for html and man what has already been done for pdf - allow enable/disable of the formats and set some sane defaults based on conditions |
| 07:27.42 | starseeker | no point in doing man pages when building with MSVC, and html is questionable when build is non-graphical... |
| 07:28.19 | starseeker | also need to review the re2c/lemon dep callouts some more |
| 07:41.10 | starseeker | also saw a warning about read being undefined in util/lowp.c (IIRC) - probably need bio.h or some other win32 headers in there somewhere... |
| 07:42.42 | starseeker | all that said, I present the first Windows exe installer generated using Visual Studio Express from trunk without any manual additions - CMake -> MSVC -> NSIS package |
| 07:43.52 | starseeker | http://brlcad.org/~starseeker/BRL-CAD_7.21.0_x86.exe |
| 07:44.51 | starseeker | more properly, first installer including documentation without manual additions |
| 07:45.02 | starseeker | zzz |
| 12:46.55 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 17:24.58 | CIA-28 | BRL-CAD: 03bob1961 * r47888 10/brlcad/trunk/src/librt/wdb.c: Needs \!dp_curr instead of dp_curr. |
| 19:05.38 | CIA-28 | BRL-CAD: 03bob1961 * r47889 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Remove temporary code. |
| 19:07.05 | CIA-28 | BRL-CAD: 03bob1961 * r47890 10/brlcad/trunk/include/tclcad.h: Declare Cho_Init(). |
| 19:07.54 | CIA-28 | BRL-CAD: 03bob1961 * r47891 10/brlcad/trunk/src/bwish/main.c: Call Cho_Init(). |
| 19:10.23 | CIA-28 | BRL-CAD: 03starseeker * r47892 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: (hopefully) fix some third_party_executable issues |
| 20:56.59 | CIA-28 | BRL-CAD: 03brlcad * r47893 10/brlcad/trunk/src/libbu/cmdhist.c: printing the commands via bu_log is kinda pointless since they need to be passed back as values. rely on the fact that they're set in chop->cho_curr, so no need to print them (except for the 'history' case |
| 20:58.28 | CIA-28 | BRL-CAD: 03brlcad * r47894 10/brlcad/trunk/src/libtclcad/cmdhist_obj.c: capture the command set by libbu as the curr/prev/next command and feed it to Tcl_AppendResult so archer can do something with the strings. better than having the command sent to stderr... |
| 21:05.34 | CIA-28 | BRL-CAD: 03starseeker * r47895 10/brlcad/trunk/ (3 files in 3 dirs): Add some more options to the Docbook building, and improve reporting for Itcl/Itk building. |
| 21:08.13 | CIA-28 | BRL-CAD: 03starseeker * r47896 10/brlcad/trunk/src/ (13 files in 4 dirs): Tweaks to get things building with the (admittedly rare) case of disabling Tk. |
| 21:18.43 | CIA-28 | BRL-CAD: 03brlcad * r47897 10/brlcad/trunk/src/libbu/tcl.c: Tcl_SplitList() returns TCL_OK/TCL_ERROR, not BRLCAD_OK... not equivalent |
| 21:22.27 | CIA-28 | BRL-CAD: 03starseeker * r47898 10/brlcad/trunk/doc/docbook/CMakeLists.txt: Make sure we've got the cmake.in files listed |
| 21:26.05 | CIA-28 | BRL-CAD: 03brlcad * r47899 10/brlcad/trunk/src/libbu/tcl.c: don't print a message if we can't find the object in a list, let the error return take over |
| 21:35.27 | CIA-28 | BRL-CAD: 03starseeker * r47900 10/brlcad/trunk/src/other/re2c/CMakeLists.txt: make sure re2c depends on the lemon build target, if there is one. |
| 21:47.23 | starseeker | hmm... mged appears to be unhappy |
| 21:48.03 | starseeker | or more specifically, wdb_open is unhappy - "invalid command name" |
| 22:13.56 | CIA-28 | BRL-CAD: 03starseeker * r47901 10/brlcad/trunk/src/util/lowp.c: Add bio.h to lowp.c |
| 22:23.40 | brlcad | starseeker: undoubtedly recent tcl changes, when do you see the error? |
| 22:23.45 | brlcad | also: |
| 22:23.46 | brlcad | [ 15%] [LEMON][ExpParser] Building parser with LEMON_EXECUTABLE-NOTFOUND |
| 22:23.46 | brlcad | /bin/sh: LEMON_EXECUTABLE-NOTFOUND: command not found |
| 22:23.46 | brlcad | [ 15%] [LEMON][ExpParser] Building parser with LEMON_EXECUTABLE-NOTFOUND |
| 22:23.46 | brlcad | /bin/sh: LEMON_EXECUTABLE-NOTFOUND: command not found |
| 22:23.55 | brlcad | recent rebuild |
| 22:24.11 | brlcad | in src/other/step/src/express/expparse.c |
| 22:42.47 | starseeker | any time I'm trying to do an opendb in MGED |
| 22:42.50 | starseeker | (not archer) |
| 22:42.54 | starseeker | urm |
| 22:46.14 | starseeker | what build options are you using? |
| 22:46.42 | starseeker | I'd try with a clean cache and the latest... there have been a couple changes recently that might not deal well with an intermediate cache state |
| 22:55.59 | starseeker | both auto and bundled seem to succeed here... |
| 23:06.04 | CIA-28 | BRL-CAD: 03starseeker * r47902 10/brlcad/trunk/CMakeLists.txt: add spacer |
| 23:07.14 | starseeker | hello... |
| 23:08.12 | starseeker | blinks - wait, just saw something... |
| 23:12.18 | starseeker | brlcad: OK, I'm seeing it |
| 23:12.26 | starseeker | or something related, at any rate |
| 23:30.28 | CIA-28 | BRL-CAD: 03starseeker * r47903 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: Don't cache the build target path. |
| 23:31.03 | starseeker | ok, I think that's got it - I tried repeated configures with bundled/auto settings and I'm not seeing any surprises |
| 00:14.57 | CIA-28 | BRL-CAD: 03n_reed * r47904 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.cpp perplex.h scanner.re): redesigning parser to address readability and robustness |
| 00:32.46 | CIA-28 | BRL-CAD: 03n_reed * r47905 10/brlcad/trunk/src/other/perplex/parser.y: generate default code for rules that specify none |
| 02:10.38 | *** part/#brlcad milamber (~devlin@d118-75-244-176.try.wideopenwest.com) | |
| 03:40.10 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 05:37.51 | starseeker | hmm... should probably take a look at the Point Cloud Library's kdtree and octree stuff... |
| 11:47.24 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 19:38.58 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 06:05.56 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 07:40.11 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 07:49.54 | *** join/#brlcad abhi2011 (~chatzilla@117.200.86.131) | |
| 12:18.57 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 15:27.42 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) | |
| 15:31.55 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 16:35.04 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 17:09.18 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 22:05.33 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 22:18.02 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 22:19.23 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 22:19.42 | *** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl) | |
| 22:19.45 | *** join/#brlcad brlcad (~sean@63.246.136.16) | |
| 22:19.48 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 22:20.08 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 22:20.08 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 22:20.10 | *** join/#brlcad starseeker (~starseeke@63.246.136.16) | |
| 22:20.10 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 22:20.56 | *** join/#brlcad alex_joni (~alex_joni@81.196.65.201) | |
| 22:20.57 | *** join/#brlcad louipc (~louipc@archlinux/fellow/louipc) | |
| 22:21.32 | *** join/#brlcad DarkCalff (DC@173.231.40.98) | |
| 22:23.08 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 22:23.08 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 22:25.33 | *** join/#brlcad CIA-28 (~CIA@cia.atheme.org) | |
| 22:25.48 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 22:57.12 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 00:57.35 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 02:02.47 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 02:15.56 | *** join/#brlcad abhi2011 (~chatzilla@117.200.84.253) | |
| 02:23.58 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 03:00.15 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 04:06.07 | *** join/#brlcad abhi2011 (~chatzilla@117.200.88.218) | |
| 04:35.44 | *** join/#brlcad abhi2011 (~chatzilla@117.200.88.43) | |
| 04:36.52 | abhi2011 | Hi, I am getting these errors related to _vsnprintf in the windows build |
| 04:36.57 | abhi2011 | http://bin.cakephp.org/view/250238996 |
| 04:37.38 | abhi2011 | its in the xml project |
| 07:29.49 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 09:05.44 | *** join/#brlcad abhi2011 (~chatzilla@117.200.86.190) | |
| 09:36.15 | *** join/#brlcad abhi2011 (~chatzilla@117.200.87.190) | |
| 10:46.07 | *** join/#brlcad abhi2011 (~chatzilla@117.200.94.106) | |
| 10:58.26 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 13:14.41 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 13:19.03 | CIA-28 | BRL-CAD: 03d_rossberg * r47906 10/brlcad/trunk/src/other/xsltproc/ (libexslt/src/exslt.c libxml/include/libxml.h xsltproc.c): MSVC-build: the _vsnprintf declaring stdio.h has to be included before the config.h whith its vsnprintf define |
| 13:19.11 | CIA-28 | BRL-CAD: 03Tbrowder 07http://brlcad.org * r3251 10/wiki/Continuous_Integration: add links to more buildbot info |
| 13:21.23 | CIA-28 | BRL-CAD: 03Tbrowder 07http://brlcad.org * r3252 10/wiki/Continuous_Integration: |
| 13:26.06 | CIA-28 | BRL-CAD: 03Tbrowder 07http://brlcad.org * r3253 10/wiki/Main_Page: /* Getting started */ |
| 14:03.05 | *** join/#brlcad abhi2011 (~chatzilla@117.200.82.193) | |
| 14:33.25 | abhi2011 | starseeker. thanks, that fixed it |
| 14:34.49 | abhi2011 | getting an error while opening files: http://imageshack.us/f/841/forcel.png/ |
| 14:35.46 | abhi2011 | invalid command name wdp_open ,hmmm |
| 14:42.07 | abhi2011 | incorrect command generated in event_check() in mged.c i think |
| 14:46.24 | starseeker | abhi2011: that was d_rossberg fixing it :-) |
| 14:46.55 | abhi2011 | woops, ok :) |
| 14:47.08 | abhi2011 | any idea about the wdb_open bug though |
| 14:47.23 | abhi2011 | I am not that good with the Tcl/Tk event management thing |
| 14:47.26 | abhi2011 | :P |
| 14:48.45 | starseeker | I'm seeing it myself, but I'm not sure what to do about it |
| 14:50.00 | abhi2011 | I ll check the mged.c changes recently |
| 14:58.46 | d_rossberg | src/mged/setup.c +line 445: Wdb_Init(INTERP); |
| 14:59.29 | d_rossberg | (just a thought) |
| 15:15.07 | abhi2011 | wow, that was it |
| 15:15.27 | abhi2011 | so the Tcl interface for libwdb was not added |
| 15:19.00 | CIA-28 | BRL-CAD: 03abhi2011 * r47907 10/brlcad/trunk/src/mged/setup.c: Added a line to create the Tcl command for wdb_open. |
| 15:20.11 | d_rossberg | :) |
| 15:33.15 | n_reed | the only thing with Wdb_Init is that it has been listed as deprecated in include/obj.h |
| 15:37.27 | abhi2011 | yes, so what would be the alternative to adding the command |
| 15:38.54 | abhi2011 | it seems to be simply a Tcl_CreateCommand() call |
| 15:39.16 | abhi2011 | wonder why it has been depreciated |
| 15:39.34 | n_reed | me too |
| 15:42.16 | n_reed | wdb_open doesn't appear to be used by archer |
| 15:42.50 | n_reed | it only appears in a deprecated widget |
| 15:43.28 | n_reed | could be that wdb_open itself is deprecated, and its use at mged.c:2906 needs to go away |
| 15:43.44 | abhi2011 | yeah, that could be it |
| 15:48.49 | abhi2011 | I wonder if there is an alternate command to open DB files in Tcl |
| 16:24.20 | CIA-28 | BRL-CAD: 03n_reed * r47908 10/brlcad/trunk/src/other/perplex/perplex.cpp: reformat error string |
| 16:29.48 | CIA-28 | BRL-CAD: 03n_reed * r47909 10/brlcad/trunk/src/other/perplex/parser.y: fix typo causing segfault when using empty condition |
| 17:01.17 | *** join/#brlcad abhi2011 (~chatzilla@117.200.84.243) | |
| 17:46.35 | CIA-28 | BRL-CAD: 03abhi2011 * r47910 10/brlcad/trunk/src/libged/simulate/simrt.c: Corrected crash during air gap calculations due to a wrong index being used. |
| 18:58.49 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.82.176) | |
| 20:01.35 | CIA-28 | BRL-CAD: 03n_reed * r47911 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.cpp perplex.h scanner.re): put support for condition scopes back in |
| 20:12.33 | CIA-28 | BRL-CAD: 03r_weiss * r47912 10/brlcad/trunk/src/libbn/plane.c: Update to the libbn function 'bn_pt3_pt3_equal' in file 'plane.c'. This change was to improve performance. |
| 20:31.22 | CIA-28 | BRL-CAD: 03r_weiss * r47913 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: Updated function 'nmg_model_break_e_on_v' in file 'nmg_fuse.c'. Added bounding box testing to improve performance. |
| 20:51.12 | CIA-28 | BRL-CAD: 03r_weiss * r47914 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: |
| 20:51.12 | CIA-28 | BRL-CAD: Update to function 'nmg_isect_eu_eu' in file 'nmg_inter.c'. Added bounding box |
| 20:51.12 | CIA-28 | BRL-CAD: testing, removed excessive magic checks, fixed some float zero compares. The |
| 20:51.12 | CIA-28 | BRL-CAD: bounding box and magic check changes were to improve performance. |
| 20:52.53 | CIA-28 | BRL-CAD: 03n_reed * r47915 10/brlcad/trunk/src/other/perplex/scanner.re: fix pattern for matching condition list |
| 21:13.38 | CIA-28 | BRL-CAD: 03n_reed * r47916 10/brlcad/trunk/src/other/perplex/ (parser.y scanner.re): put support for re2c-style named definitions back in |
| 21:15.16 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.81.218) | |
| 21:49.27 | CIA-28 | BRL-CAD: 03r_weiss * r47917 10/brlcad/trunk/src/librt/primitives/nmg/nmg_info.c: Updated function 'nmg_2edgeuse_g_coincident' in file 'nmg_info.c'. Removed an unnecessary parallel test and excessive magic tests. These changes were to improve performance. |
| 23:14.35 | CIA-28 | BRL-CAD: 03starseeker * r47918 10/brlcad/trunk/src/other/Makefile.am: Add xsltproc dir and dist file to Makefile.am EXTRA_DIST |
| 23:51.49 | CIA-28 | BRL-CAD: 03starseeker * r47919 10/brlcad/trunk/src/libbu/Makefile.am: uce-dirent.h is back in libbu - let autotools know about it. |
| 00:01.17 | CIA-28 | BRL-CAD: 03starseeker * r47920 10/brlcad/trunk/misc/Makefile.am: Hmm, another Makefile.am list out of date... |
| 00:24.38 | starseeker | hmm... apparently OCE has jabbed the OpenCascade guys into some more energetic activity... http://dev.opencascade.org/ |
| 00:25.03 | starseeker | can't help thinking the requirement for a "Contributor License Agreement" will be a non-starter... |
| 00:26.15 | CIA-28 | BRL-CAD: 03n_reed * r47921 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.cpp perplex.h scanner.re): should only look for named definitions outside of rule actions |
| 01:16.17 | CIA-28 | BRL-CAD: 03r_weiss * r47922 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: Updated functions 'nmg_crackshells' and 'nmg_isect_two_generic_faces'. Added function 'nmg_no_isect_fu_pl' which compares a face to a plane and determines if there is no intersection. |
| 01:19.56 | CIA-28 | BRL-CAD: 03starseeker * r47923 10/brlcad/trunk/ (5 files in 5 dirs): I *think* this turns off the Docbook building for Autotools, which is no longer expected to be fully working... getting icv errors when building rt, so can't so a full distcheck yet. |
| 01:20.29 | starseeker | s/can't so/can't do/ |
| 02:11.45 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 07:53.05 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 09:26.57 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 09:28.47 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 09:29.18 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 09:39.36 | *** join/#brlcad cvds_ (~leila@e255180.upc-e.chello.nl) | |
| 12:41.14 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 12:42.32 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 12:45.49 | *** join/#brlcad brlcad (~sean@63.246.136.16) | |
| 17:00.45 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 17:10.40 | CIA-28 | BRL-CAD: 03n_reed * r47924 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.cpp scanner.re): change matching of named definitions to not conflict with matching of condition changes |
| 17:17.48 | *** join/#brlcad n_reed (~nicholas@c-68-55-142-136.hsd1.md.comcast.net) | |
| 17:32.45 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 17:36.35 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 17:49.51 | *** join/#brlcad starseek1r (~starseeke@BZ.BZFLAG.BZ) | |
| 17:53.23 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 17:54.53 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 18:02.12 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 18:25.50 | starseeker | hmm... fun connection today |
| 19:16.57 | CIA-28 | BRL-CAD: 03starseeker * r47925 10/brlcad/trunk/src/other/ (6 files in 5 dirs): Add the license information and a brief README to xsltproc |
| 20:36.19 | CIA-28 | BRL-CAD: 03starseeker * r47926 10/brlcad/trunk/src/rt/Makefile.am: Add ICV to rt Makefile.am |
| 20:44.33 | CIA-28 | BRL-CAD: 03starseeker * r47927 10/brlcad/trunk/src/ (Makefile.am remrt/Makefile.am): Couple more icv tweaks |
| 21:18.05 | starseeker | woot - autotools distcheck passes again |
| 21:46.45 | CIA-28 | BRL-CAD: 03r_weiss * r47928 10/brlcad/trunk/src/librt/primitives/nmg/nmg_info.c: Updated function 'nmg_2edgeuse_g_coincident' in file 'nmg_info.c'. Removed unnecessary tests to improve performance. |
| 23:26.11 | CIA-28 | BRL-CAD: 03n_reed * r47929 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.cpp perplex.h scanner.re): improvements to named definition matching and input buffering |
| 00:11.13 | *** join/#brlcad b0ef (~b0ef@78.58.34.95.customer.cdi.no) | |
| 01:13.42 | CIA-28 | BRL-CAD: 03n_reed * r47930 10/brlcad/trunk/src/other/perplex/scanner.re: cleanup of buffering routines |
| 01:37.13 | *** join/#brlcad louipc (~louipc@archlinux/fellow/louipc) | |
| 02:53.55 | *** join/#brlcad n_reed (~nicholas@c-68-55-142-136.hsd1.md.comcast.net) | |
| 03:08.36 | CIA-28 | BRL-CAD: 03starseeker * r47931 10/brlcad/trunk/ (61 files in 12 dirs): Make a stab at adding an xml validation step to the build. Looks like xml/xslt upgrades are needed, and even then the results are... a little confusing. |
| 03:23.16 | starseeker | Hmm... the rnv results actually look more promising/useful... |
| 08:13.22 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 12:34.33 | CIA-28 | BRL-CAD: 03125.62.202.148 07http://brlcad.org * r3254 10/wiki/User:Abhijit: |
| 14:15.23 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 14:21.51 | *** join/#brlcad n_reed (~nicholas@c-68-55-142-136.hsd1.md.comcast.net) | |
| 14:37.37 | CIA-28 | BRL-CAD: 03starseeker * r47932 10/brlcad/trunk/doc/docbook/ (DB_VALIDATE.cmake xmllint.cmake.in): |
| 14:37.38 | CIA-28 | BRL-CAD: Don't use the rng schema with xmllint, per advice from the libxml list - |
| 14:37.38 | CIA-28 | BRL-CAD: fortunately, we can also use a more standard schema. Also, rather than defining |
| 14:37.38 | CIA-28 | BRL-CAD: the flags somewhere other than the 'command' file, make it self contained - in |
| 14:37.38 | CIA-28 | BRL-CAD: prinicple, that should make swapping in a different validator as simple as |
| 14:37.38 | CIA-28 | BRL-CAD: defining a .cmake.in file for that command and setting a toplevel setting. Need |
| 14:37.39 | CIA-28 | BRL-CAD: to experiment a little. |
| 14:39.51 | CIA-28 | BRL-CAD: 03starseeker * r47933 10/brlcad/trunk/doc/docbook/lessons/en/ (4 files): Few tweaks to lesson files from xmllint testing... undoubtedly more needed in the various docbook files. |
| 14:44.13 | CIA-28 | BRL-CAD: 03starseeker * r47934 10/brlcad/trunk/doc/docbook/books/en/ (2 files): Some tweaks to the book files - volume IV looks like a bit more work... |
| 15:17.36 | CIA-28 | BRL-CAD: 03starseeker * r47935 10/brlcad/trunk/ (5 files in 2 dirs): Reorganize Docbook build logic - try to keep command-specific stuff in the command files. |
| 15:19.27 | CIA-28 | BRL-CAD: 03starseeker * r47936 10/brlcad/trunk/doc/docbook/ (21 files in 11 dirs): Docbook is off in autotools, so the Makefile.am files aren't needed anymore. Scrub. |
| 15:34.17 | CIA-28 | BRL-CAD: 03starseeker * r47937 10/brlcad/trunk/ (doc/docbook/CMakeLists.txt misc/CMake/Docbook.cmake): Move the Docbook target macros to Docbook.cmake |
| 16:32.34 | CIA-28 | BRL-CAD: 03starseeker * r47938 10/brlcad/trunk/ (9 files in 2 dirs): Modularize the DocBook processing - can now specify custom tools, so long as a misc/CMake/tool.cmake.in file is written to tell CMake how to run the tool. Add rnv as a validation example. |
| 16:41.20 | *** join/#brlcad abhi2011 (~chatzilla@117.200.85.163) | |
| 16:54.30 | brlcad | abhi2011: hello! ltns.. |
| 16:54.46 | abhi2011 | hello brlcad :) |
| 16:55.13 | brlcad | how are classes going? |
| 16:55.23 | CIA-28 | BRL-CAD: 03n_reed * r47939 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.cpp scanner.re): make named definitions look like rules to simplify grammar and avoid confusing parser |
| 16:58.18 | brlcad | mm, classes are probably over actually. |
| 17:39.32 | CIA-28 | BRL-CAD: 03starseeker * r47940 10/brlcad/trunk/ (8 files in 4 dirs): |
| 17:39.32 | CIA-28 | BRL-CAD: Make a stab at supporting multiple executables in one subdir with |
| 17:39.32 | CIA-28 | BRL-CAD: THIRD_PARTY_EXECUTABLE. Move xsltproc dir to xmltools since it is no longer |
| 17:39.32 | CIA-28 | BRL-CAD: just about xsltproc. Validation xml targets should now properly depend on the |
| 17:39.33 | CIA-28 | BRL-CAD: xmllint target. |
| 17:47.14 | CIA-28 | BRL-CAD: 03starseeker * r47941 10/brlcad/trunk/src/other/CMakeLists.txt: CMake can be run multiple times... |
| 17:53.49 | CIA-28 | BRL-CAD: 03starseeker * r47942 10/brlcad/trunk/CMakeLists.txt: Comment tweaks |
| 18:05.49 | CIA-28 | BRL-CAD: 03n_reed * r47943 10/brlcad/trunk/src/other/perplex/scanner.re: need to include null element when copying buffer |
| 18:13.19 | CIA-28 | BRL-CAD: 03starseeker * r47944 10/brlcad/trunk/misc/CMake/Docbook.cmake: Make the generation targets depend on the validation targets for docbook, if they are enabled. |
| 18:19.25 | CIA-28 | BRL-CAD: 03n_reed * r47945 10/brlcad/trunk/src/other/perplex/scanner.re: address compiler warnings |
| 18:22.06 | CIA-28 | BRL-CAD: 03n_reed * r47946 10/brlcad/trunk/src/other/perplex/scanner_template.c: sync scanner buffer routine changes to template |
| 19:29.41 | CIA-28 | BRL-CAD: 03n_reed * r47947 10/brlcad/trunk/src/other/perplex/scanner_template.c: add macro at scanner entrance for user entrance code |
| 20:27.00 | CIA-28 | BRL-CAD: 03r_weiss * r47948 10/brlcad/trunk/include/nmg.h: Update to file 'nmg.h' to add a pointer to a manifolds list within the nmg 'model' structure. This is necesary to globally track the current manifolds in the nmg model. |
| 20:32.59 | CIA-28 | BRL-CAD: 03r_weiss * r47949 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mk.c: Update to file 'nmg_mk.c' modifying functions 'nmg_mm' (nmg make model) and 'nmg_km' (nmg kill model) to support the addition of the 'manifolds' pointer to the model structure. |
| 20:37.23 | CIA-28 | BRL-CAD: 03r_weiss * r47950 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: |
| 20:37.24 | CIA-28 | BRL-CAD: Update to file 'nmg_bool.c' function 'nmg_bool'. Moved the execution of function |
| 20:37.24 | CIA-28 | BRL-CAD: 'nmg_manifolds' (which creates the manifolds list) from a lower level to |
| 20:37.24 | CIA-28 | BRL-CAD: 'nmg_bool' so it is only executed once per boolean operation. Previously is was |
| 20:37.24 | CIA-28 | BRL-CAD: executed for every ray that was shot during the classification of the nmg |
| 20:37.24 | CIA-28 | BRL-CAD: objects. |
| 20:42.21 | CIA-28 | BRL-CAD: 03r_weiss * r47951 10/brlcad/trunk/src/librt/primitives/nmg/nmg_rt_isect.c: Updated file 'nmg_rt_isect.c' function 'nmg_class_ray_vs_shell' so that it will use an existing manifold list, if one is available. Also to not free the manifold list if it was not created in this function. |
| 20:45.28 | CIA-28 | BRL-CAD: 03r_weiss * r47952 10/brlcad/trunk/src/librt/primitives/nmg/nmg_index.c: Update to file 'nmg_index.c' function 'nmg_merge_models' to support the addition of the 'manifolds' pointer to the model structure. When models are merged, any manifold lists will be invalid so free them. |
| 20:46.26 | CIA-28 | BRL-CAD: 03brlcad * r47953 10/brlcad/trunk/src/librt/primitives/nmg/nmg_rt_isect.c: NULL for sanity |
| 20:47.22 | CIA-28 | BRL-CAD: 03starseeker * r47954 10/brlcad/trunk/doc/ecosystem.dot: graphviz, not docbook |
| 20:53.24 | CIA-28 | BRL-CAD: 03brlcad * r47955 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: rename 'new' variable to 'newdata' so it won't conflict with c++ compilation. also null out our stp->st_specific after releasing it for good measure. |
| 20:57.14 | CIA-28 | BRL-CAD: 03brlcad * r47956 10/brlcad/trunk/src/librt/primitives/nmg/nmg_rt_isect.c: hitmiss is local data, so no sanity offered by nulling; but rt.manifolds is misleading as the actual pointer is in rd.rd_m that we want to free and unset. |
| 21:21.06 | CIA-28 | BRL-CAD: 03r_weiss * r47957 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: Updated file 'nmg_fuse.c' function 'nmg_ptbl_vfuse' and added function 'x_comp'. Improved the performance of vertex fusing during nmg boolean operations. The new function 'x_comp' supports the 'nmg_ptbl_vfuse' function. |
| 21:55.09 | CIA-28 | BRL-CAD: 03brlcad * r47958 10/brlcad/trunk/src/libbu/ (11 files): _bu_ prefix on statics was a bad idea. use filename/group as prefix instead. in most cases, simplifies names and improves readability. |
| 21:59.33 | CIA-28 | BRL-CAD: 03brlcad * r47959 10/brlcad/trunk/src/libbu/ (hist.c log.c malloc.c parallel.c tcl.c): remove _ B U _ from comments too, update names |
| 22:01.21 | CIA-28 | BRL-CAD: 03brlcad * r47960 10/brlcad/trunk/src/libbu/ (cmd.c observer.c): these files no longer require tcl.h |
| 22:03.37 | CIA-28 | BRL-CAD: 03brlcad * r47961 10/brlcad/trunk/src/libbu/parse.c: parse_tcl_list_length() is not a public function, rename to parse_list_length() |
| 22:20.22 | CIA-28 | BRL-CAD: 03brlcad * r47962 10/brlcad/trunk/ (8 files in 6 dirs): renaming bu_shader_to_tcl_list() to bu_shader_to_list() as the function applies to any list in {} form, tcl or otherwise. part of making libbu be entirely tcl-agnostic. |
| 22:37.54 | CIA-28 | BRL-CAD: 03brlcad * r47963 10/brlcad/trunk/src/libbu/ (globals.c log.c): bu_log_hook_list doesn't need to be global as accessor functions exist. move it into log.c and make it static. |
| 22:40.34 | CIA-28 | BRL-CAD: 03brlcad * r47964 10/brlcad/trunk/src/libbu/log.c: simplify, consistency. rename the static variables sans bu_ prefix since they're not public api. |
| 22:49.06 | CIA-28 | BRL-CAD: 03brlcad * r47965 10/brlcad/trunk/ (4 files in 3 dirs): |
| 22:49.06 | CIA-28 | BRL-CAD: add a new bu_bomb_add_hook_list() function similar to bu_log_add_hook_list() so |
| 22:49.06 | CIA-28 | BRL-CAD: that we can eliminate the bu_bomb_hook_list from global API visibility/use. |
| 22:49.06 | CIA-28 | BRL-CAD: since mged is sole use, presently no means to remove or inspect hooks is being |
| 22:49.06 | CIA-28 | BRL-CAD: added. |
| 22:56.15 | CIA-28 | BRL-CAD: 03brlcad * r47966 10/brlcad/trunk/ (4 files in 2 dirs): rename the hook function callbacks to be consistent with other parts of libbu api using bu_hook_ as the function prefix. minimally impacting change. |
| 22:59.13 | CIA-28 | BRL-CAD: 03starseeker * r47967 10/brlcad/trunk/ (5 files in 4 dirs): Group distcheck file ignoring macros, fix a couple distcheck items. |
| 23:03.22 | CIA-28 | BRL-CAD: 03starseeker * r47968 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/CMakeFiles.cmake): There's no particular reason the subbuild logic or distcheck macros need to be BRL-CAD specific. |
| 23:09.03 | CIA-28 | BRL-CAD: 03brlcad * r47969 10/brlcad/trunk/src/libged/wdb_obj.c: |
| 23:09.03 | CIA-28 | BRL-CAD: register a bu_log() hook with the wdb command object so we don't get libbu |
| 23:09.03 | CIA-28 | BRL-CAD: blather about not finding a valid command. this fixes obtuse misleading output |
| 23:09.03 | CIA-28 | BRL-CAD: from g_diff since it unfortunately uses the wdb object interface to get/compare |
| 23:09.03 | CIA-28 | BRL-CAD: attributes. |
| 23:10.47 | CIA-28 | BRL-CAD: 03starseeker * r47970 10/brlcad/trunk/ (3 files in 2 dirs): Split the option macros into their own file - BRLCAD_Util is too long. Need to organize better. |
| 23:16.50 | CIA-28 | BRL-CAD: 03brlcad * r47971 10/brlcad/trunk/src/rt/view.c: fix a structparse crash in rt if you tried to set ambSlow=1. the offset was off-by-one indexing the wrong parse entry so ambSlow's field was never initialized (causing a NULL dereference). |
| 23:29.08 | CIA-28 | BRL-CAD: 03starseeker * r47972 10/brlcad/trunk/ (3 files in 2 dirs): Do some more option macro reworking. |
| 23:29.57 | CIA-28 | BRL-CAD: 03brlcad * r47973 10/brlcad/trunk/src/libbu/parse.c: prevent a segfault if we encounter an uninitialized bu_structparse table entry. it implies there is an outright bug in that table's entry definition/setup. bomb so we can get a stacktrace to fix it. |
| 00:12.59 | CIA-28 | BRL-CAD: 03starseeker * r47974 10/brlcad/trunk/ (3 files in 2 dirs): At long last, begin integrating the option documentation mechanism into the 3rd party macro system. This handles only the libraries at the moment, not the executables and tcl/tk packages. |
| 00:28.04 | CIA-28 | BRL-CAD: 03starseeker * r47975 10/brlcad/trunk/ (doc/docbook/books/en/CMakeLists.txt misc/CMake/Docbook.cmake): Oops - fix couple of issues that crept into docbook pdf logic. |
| 00:36.47 | CIA-28 | BRL-CAD: 03starseeker * r47976 10/brlcad/trunk/doc/docbook/ (CMakeLists.txt ElNode.pm README validate.pl): Perl is no longer needed in doc/docbook. Should test out xslt tools other than xsltproc - if they work, provide example(s) for those too, not just rnv validation tool. |
| 00:39.29 | CIA-28 | BRL-CAD: 03starseeker * r47977 10/brlcad/trunk/doc/docbook/README: Call out necessary config options for rnv usage. |
| 03:28.03 | starseeker | grins at the IRC history - now that's a good commit density :-) |
| 03:42.20 | *** join/#brlcad abhi2011 (~chatzilla@117.200.86.134) | |
| 03:52.19 | CIA-28 | BRL-CAD: 03starseeker * r47978 10/brlcad/trunk/ (doc/docbook/README misc/CMake/msv.cmake.in): Add an msv example for docbook validation with CMake (the original recommended tool - it just uses java, so not available by default...) also, correct the documentation configuration example. |
| 04:04.48 | CIA-28 | BRL-CAD: 03starseeker * r47979 10/brlcad/trunk/ (3 files in 2 dirs): Add documentation and aliases for the third party executables. Last up, the tcl libs... |
| 04:06.11 | starseeker | hmm, I see why msv is recommended... |
| 04:06.25 | starseeker | doggone it, why do all the best DocBook tools have to be in Java... |
| 04:12.14 | *** join/#brlcad abhi2011 (~chatzilla@117.200.85.83) | |
| 04:46.32 | CIA-28 | BRL-CAD: 03Sean 07http://brlcad.org * r3255 10/wiki/User:Abhijit: Reverted edits by [[Special:Contributions/125.62.202.148|125.62.202.148]] ([[User talk:125.62.202.148|Talk]]); changed back to last version by [[User:Abhi2011|Abhi2011]] |
| 04:46.34 | CIA-28 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:125.62.202.148]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 04:58.30 | CIA-28 | BRL-CAD: 03starseeker * r47980 10/brlcad/trunk/ (misc/CMake/ThirdParty_TCL.cmake src/other/CMakeLists.txt): |
| 04:58.30 | CIA-28 | BRL-CAD: Have the THIRD_PARTY_TCL_PACKAGE macro handle the question of what to do when Tk |
| 04:58.30 | CIA-28 | BRL-CAD: is required and disabled - we're going to want the option defined regardless so |
| 04:58.30 | CIA-28 | BRL-CAD: we get the documentation, once we turn those features on. Still need to rework |
| 04:58.30 | CIA-28 | BRL-CAD: the itcl/itk logic so it doesn't have to double-call the macro. |
| 05:48.20 | brlcad | starseeker: because java is xml-happy |
| 05:50.44 | brlcad | stupid kdc not responding |
| 06:54.13 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 14:23.07 | starseeker | brlcad: bomb.c:84: warning: implicit declaration of function 'bu_hook_add' |
| 14:35.35 | starseeker | guessing a bu.h update missed getting committed? |
| 14:40.31 | CIA-28 | BRL-CAD: 03d_rossberg * r47981 10/brlcad/trunk/src/librt/primitives/nmg/nmg_rt_isect.c: just a thought (probable a typing error) |
| 15:00.31 | CIA-28 | BRL-CAD: 03starseeker * r47982 10/brlcad/trunk/ (include/bu.h src/other/CMakeLists.txt): Don't double-call THIRD_PARTY_TCL_PACKAGE - getting set to add documentation to this macro |
| 15:17.05 | *** join/#brlcad n_reed_ (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:23.36 | CIA-28 | BRL-CAD: 03starseeker * r47983 10/brlcad/trunk/include/bu.h: Whoops, didn't mean to commit that - wait for Sean's solution. |
| 15:36.18 | brlcad | starseeker: yeah, sorry -- fixing |
| 15:37.00 | brlcad | was working on a bu bug late into last night |
| 15:49.42 | CIA-28 | BRL-CAD: 03brlcad * r47984 10/brlcad/trunk/include/bu.h: update the bu_hook_* decls |
| 16:05.27 | CIA-28 | BRL-CAD: 03brlcad * r47985 10/brlcad/trunk/src/libbu/backtrace.c: waiting for 60 seconds for a debugger to attach seems a little too long. needs to be just long enough to run top/ps and gdb --attach. reduce wait to 45 seconds. |
| 17:15.09 | CIA-28 | BRL-CAD: 03r_weiss * r47986 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: Updated functions 'nmg_two_face_fuse', 'nmg_model_face_fuse' and 'nmg_edge_g_fuse' in file 'nmg_fuse.c'. Removed magic checks reducing performance. Also simplified/changed logic to improve performance. |
| 17:18.04 | CIA-28 | BRL-CAD: 03r_weiss * r47987 10/brlcad/trunk/src/librt/primitives/nmg/nmg_extrude.c: Updated function 'nmg_find_vertex_in_lu' in file 'nmg_extrude.c'. Removed magic checks reducing performance. Changed 'eu' to a register variable. |
| 17:22.27 | CIA-28 | BRL-CAD: 03r_weiss * r47988 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: |
| 17:22.28 | CIA-28 | BRL-CAD: Updated functions 'nmg_bool' and 'nmg_kill_anti_loops' in file 'nmg_bool.c'. |
| 17:22.28 | CIA-28 | BRL-CAD: Removed magic checks reducing performance. Removed the input parameter 'tol' |
| 17:22.28 | CIA-28 | BRL-CAD: from function 'nmg_kill_anti_loops' since it was unused. Changed many variable |
| 17:22.29 | CIA-28 | BRL-CAD: to register variables in function 'nmg_kill_anti_loops'. |
| 17:26.27 | CIA-28 | BRL-CAD: 03r_weiss * r47989 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mod.c: Updated function 'nmg_shell_coplanar_face_merge' in file 'nmg_mod.c'. Removed magic tests which were reducing performance. Modified logic to improve performance. Did code cleanup. |
| 18:29.11 | *** join/#brlcad dli (~dli@66.49.253.83) | |
| 18:29.36 | dli | 7.20.4 building error: ld: ../../lib/librttherm.a(main.c.o): undefined reference to symbol 'fb_open' |
| 18:38.58 | brlcad | dli: I believe that is already fixed |
| 18:39.13 | brlcad | dli: can you try an svn checkout build to confirm? |
| 18:39.25 | dli | brlcad, one moment |
| 18:46.47 | CIA-28 | BRL-CAD: 03n_reed * r47990 10/brlcad/trunk/src/other/perplex/scanner_template.c: need to provide default macro definition |
| 18:51.30 | CIA-28 | BRL-CAD: 03brlcad * r47991 10/brlcad/trunk/src/librt/constraint.c: BU_VLS_IS_INITIALIZED() is evil, avoid. don't need the structparse table to be public too. |
| 18:53.25 | CIA-28 | BRL-CAD: 03starseeker * r47992 10/brlcad/trunk/misc/CMake/FindPERPLEX.cmake: Make a stab at macros for perplex targets |
| 18:55.58 | CIA-28 | BRL-CAD: 03brlcad * r47993 10/brlcad/trunk/src/libwdb/constraint.c: always init the vls |
| 19:01.43 | CIA-28 | BRL-CAD: 03brlcad * r47994 10/brlcad/trunk/src/rt/reshoot.c: always initialize vls members |
| 19:03.13 | CIA-28 | BRL-CAD: 03brlcad * r47995 10/brlcad/trunk/src/rt/viewedge.c: always init bu_vls, especially if they're going to be used in a structparse table. |
| 19:06.52 | CIA-28 | BRL-CAD: 03brlcad * r47996 10/brlcad/trunk/src/ (11 files in 3 dirs): (log message trimmed) |
| 19:06.52 | CIA-28 | BRL-CAD: structparse refactoring to fix a couple long outstanding issues. structparse |
| 19:06.52 | CIA-28 | BRL-CAD: tables chained together via %p no longer stash the address in sp_count, instead |
| 19:06.52 | CIA-28 | BRL-CAD: using sp_offset just like everything else. update all callers accordingly. |
| 19:06.52 | CIA-28 | BRL-CAD: also, update the %V bu_vls handlers to not do their own thing merely because |
| 19:06.52 | CIA-28 | BRL-CAD: callers weren't initializing their vls before calling a structparse function. |
| 19:06.53 | CIA-28 | BRL-CAD: require init and make all callers initialize beforehand (e.g., via |
| 19:26.33 | CIA-28 | BRL-CAD: 03starseeker * r47997 10/brlcad/trunk/ (misc/CMake/ThirdParty_TCL.cmake src/other/CMakeLists.txt): Make the 'don't build this tcl/tk extension because of X mechanism a bit more general. Also, try to handle Togl a bit more like the other Tcl/Tk packages. |
| 19:30.21 | dli | error: variable ‘m’ set but not used [-Werror=unused-but-set-variable] |
| 19:30.32 | dli | -DBRLCAD-ENABLE_STRICT=OFF |
| 19:30.55 | brlcad | need the line preceeding |
| 19:31.24 | brlcad | dli: also, all of the BRLCAD- variables are now uniformly BRLCAD_ |
| 19:31.59 | dli | brlcad, so, -DBRLCAD_ENABLE_STRICT=OFF |
| 19:32.08 | brlcad | yep |
| 19:33.02 | brlcad | though getting a list of those error/warnings is useful too .. should be clean and passing with strict enabled |
| 19:33.57 | brlcad | been compiling with the very latest gcc, so anything that comes up should be very recent issue in the last day or so |
| 19:36.54 | dli | brlcad, also, building fails with "g++ -std=c++0x ", I suppose it should be c++11 compatible eventually |
| 19:57.10 | CIA-28 | BRL-CAD: 03starseeker * r47998 10/brlcad/trunk/ (misc/CMake/ThirdParty_TCL.cmake src/other/CMakeLists.txt): |
| 19:57.10 | CIA-28 | BRL-CAD: Add documentation and aliases for Tcl/Tk packages. Most of the way there |
| 19:57.10 | CIA-28 | BRL-CAD: (although the documentation blurbs undoubtedly need work) - remaining issues are |
| 19:57.10 | CIA-28 | BRL-CAD: options that can be completely conditionalized away (termlib, scl) - need to |
| 19:57.10 | CIA-28 | BRL-CAD: make sure the options are called to generate the doc strings, may need to extend |
| 19:57.11 | CIA-28 | BRL-CAD: the 'required vars' mechanism in used for Tcl/Tk packages to THIRD_PARTY itself. |
| 20:09.28 | CIA-28 | BRL-CAD: 03starseeker * r47999 10/brlcad/trunk/ (misc/CMake/ThirdParty.cmake src/other/CMakeLists.txt): add the required vars mechanism to THIRD_PARTY, update src/other/CMakeLists.txt |
| 20:16.45 | CIA-28 | BRL-CAD: 03brlcad * r48000 10/brlcad/trunk/src/librt/columnparse.c: looks like struct attr_obj isn't used anywhere, so get rid of it. convert to BU_VLS_INIT_ZERO |
| 21:05.39 | CIA-28 | BRL-CAD: 03starseeker * r48001 10/brlcad/trunk/ (CMakeLists.txt INSTALL.cmake): (log message trimmed) |
| 21:05.40 | CIA-28 | BRL-CAD: And now, the final piece of the configuration options documentation. |
| 21:05.40 | CIA-28 | BRL-CAD: Automatically update the INSTALL file (currently pulling INSTALL.cmake, but that |
| 21:05.40 | CIA-28 | BRL-CAD: will change later) with changes in BRL-CAD options and aliases. In keeping with |
| 21:05.40 | CIA-28 | BRL-CAD: the principle of not touching the source directory the original INSTALL file is |
| 21:05.40 | CIA-28 | BRL-CAD: not altered - instead, a new file is generated (INSTALL.new) and a warning is |
| 21:05.40 | CIA-28 | BRL-CAD: printed at the end of the configure process notifying the developer of the |
| 21:07.55 | starseeker | heh 48000 |
| 21:07.57 | starseeker | nice |
| 21:09.33 | brlcad | dli: failing with a c++ compiler is known, regardless of c++0x |
| 21:10.10 | brlcad | there is a to-do item to attempt to get a complete build with g++-only, but nobody has tackled it in a long time |
| 21:16.27 | CIA-28 | BRL-CAD: 03brlcad * r48002 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: looks like 'm'odel is set but not used, so eliminate it. presumes nmg_find_model() has no side effects |
| 21:16.58 | brlcad | that should fix that earlier strict warning |
| 21:36.28 | CIA-28 | BRL-CAD: 03brlcad * r48003 10/brlcad/trunk/src/ (113 files in 36 dirs): |
| 21:36.28 | CIA-28 | BRL-CAD: conversion from bu_vls_init() to BU_VLS_INIT_ZERO initialization. this |
| 21:36.28 | CIA-28 | BRL-CAD: performance tune avoids a function call and memory allocation if the string is |
| 21:36.28 | CIA-28 | BRL-CAD: never used but, more importantly, simplifies the code and makes it less |
| 21:36.28 | CIA-28 | BRL-CAD: error-prone in the situations where we only conditionally initialized or |
| 21:36.29 | CIA-28 | BRL-CAD: initialized much later in the logic. this commit covers approximately 45% of |
| 21:36.37 | CIA-28 | BRL-CAD: the bu_vls_init() calls. woot: +366 -718. |
| 22:19.24 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 22:50.27 | CIA-28 | BRL-CAD: 03starseeker * r48004 10/brlcad/trunk/CMakeLists.txt: Print the summary unless told not to - let a parent build turn it off if it doesn't want it, but the default is on. |
| 23:22.47 | CIA-28 | BRL-CAD: 03starseeker * r48005 10/brlcad/trunk/HACKING.cmake: Sync HACKING.cmake with HACKING, make a few updates. |
| 00:08.46 | CIA-28 | BRL-CAD: 03starseeker * r48006 10/brlcad/trunk/CMakeLists.txt: Need to do the 32/64 bit check earlier in the game, before we try to find anything at all. |
| 00:09.41 | CIA-28 | BRL-CAD: 03n_reed * r48007 10/brlcad/trunk/src/other/perplex/ (scanner.re scanner_template.c): Comparing disparate pointers is undefined. Don't do it. |
| 00:37.42 | CIA-28 | BRL-CAD: 03n_reed * r48008 10/brlcad/trunk/src/other/perplex/ (scanner.re scanner_template.c): need to update input markers if input buffer is reallocated |
| 01:55.12 | CIA-28 | BRL-CAD: 03starseeker * r48009 10/brlcad/trunk/ (10 files in 2 dirs): Slew of documentation updates. Not claiming final form yet, but closer. |
| 02:07.49 | CIA-28 | BRL-CAD: 03starseeker * r48010 10/brlcad/trunk/doc/README.Windows: Start reworking the Windows docs for CMake. |
| 02:13.23 | CIA-28 | BRL-CAD: 03starseeker * r48011 10/brlcad/trunk/ (8 files): Move the CMake versions of doc files into place. |
| 02:19.18 | dli | svn version building error: http://pastebin.com/HUC6ibBc |
| 02:23.58 | CIA-28 | BRL-CAD: 03starseeker * r48012 10/brlcad/trunk/ (INSTALL src/other/CMakeLists.txt): Copy/paste strikes again |
| 02:33.51 | CIA-28 | BRL-CAD: 03starseeker * r48013 10/brlcad/trunk/configure.cmake.sh: Add a bunch more of the options to the configure script. Looking more like it will be possible to simply autogenerate the verbose part of this. Also points out there are a few toplevel options that still need docs. |
| 02:34.39 | starseeker | dli: can you paste it using the mozilla pastebin? |
| 02:34.52 | dli | starseeker, ok |
| 02:35.40 | dli | starseeker, http://pastebin.mozilla.org/1407174 |
| 02:39.59 | starseeker | um... not sure what's going on - I just got a clean build from latest trunk here... what were your configure options? |
| 02:41.58 | dli | starseeker, one moment |
| 02:45.05 | dli | starseeker, http://pastebin.mozilla.org/1407179 |
| 02:45.58 | dli | starseeker, reported from cmake: http://pastebin.mozilla.org/1407180 |
| 02:46.34 | starseeker | holy bleep |
| 02:46.43 | starseeker | are you building it as part of a packaging system? |
| 02:46.56 | dli | starseeker, yes, in gentoo |
| 02:46.59 | starseeker | oh, I see gentoo |
| 02:47.21 | starseeker | well, for one thing, a lot of the options are incorrect for trunk |
| 02:48.23 | starseeker | and they shouldn't be trying to turn off scl or utahrle, unless they've got ebuilds of our own src/other srcs |
| 02:48.39 | starseeker | dli: where did you get that ebuild from? |
| 02:48.43 | starseeker | is that an overlay? |
| 02:48.48 | dli | starseeker, yes |
| 02:48.53 | starseeker | which one? |
| 02:49.06 | dli | starseeker, science-overlay |
| 02:49.50 | starseeker | hmm. I'd have to take a look, but it looks like someone either isn't maintaining that ebuild or isn't paying close enough attention |
| 02:50.09 | dli | starseeker, very old ebuilds |
| 02:54.30 | starseeker | yeah, this needs a total overhaul |
| 02:54.36 | starseeker | who's maintaining it? |
| 02:55.37 | starseeker | he DISABLED opengl?? |
| 02:56.03 | starseeker | and did it wrong to boot - it's -DBRLCAD_ENABLE_OPENGL=OFF, not -BRLCAD_ENABLE_OPENGL=OFF |
| 02:56.06 | dli | starseeker, I disabled opengl, because builds fails with opengl |
| 02:56.35 | starseeker | O.o - why? |
| 02:57.17 | starseeker | dli: can you do me a favor? Just grab a trunk checkout and build it "stand-alone" without the ebuild? |
| 02:57.35 | starseeker | cmake .. -DBRLCAD_BUNDLED_LIBS=ON and see what happens? |
| 02:57.50 | dli | starseeker, sure |
| 03:00.17 | starseeker | all the BRLCAD_BUILD_LOCAL variables are obsolete and not doing anything |
| 03:00.49 | dli | starseeker, reported from cmake: http://pastebin.mozilla.org/1407198 |
| 03:00.58 | starseeker | to achieve what it looks like he's after, all he had to do was -DBRLCAD_BUNDLED_LIBS=System , but that doesn't stand a good chance of working... |
| 03:01.18 | starseeker | dli: try building once |
| 03:01.40 | dli | starseeker, it's building |
| 03:02.25 | dli | starseeker, /var/tmp/portage/media-gfx/brlcad-9999/work/brlcad-9999/include/sysv.h:61:26: error: conflicting types for ‘strchr’ |
| 03:02.58 | dli | starseeker, that's from cmake -DBRLCAD_BUNDLED_LIBS=ON . |
| 03:04.58 | starseeker | what's the full error? |
| 03:05.10 | starseeker | previous definition? |
| 03:06.17 | dli | starseeker, that's all I got: http://pastebin.mozilla.org/1407203 |
| 03:06.32 | starseeker | also, you're still using the gentoo brlcad-9999 sources? |
| 03:07.41 | dli | starseeker, should not be, I run cmake in the source folder, gentoo builds it in a different folder |
| 03:07.56 | dli | starseeker, I can try to copy the source and try again |
| 03:09.20 | starseeker | dli: I'd suggest starting totally clean, if you can |
| 03:09.34 | dli | starseeker, no problem |
| 03:10.09 | starseeker | in your home directory: svn co https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/trunk brlcad && mkdir brlcad-build && cd brlcad-build && cmake ../brlcad -DBRLCAD_BUNDLED_LIBS=ON && make |
| 03:10.38 | starseeker | clearly turning off opengl in CMake is causing some... unexpected issues, I'll have to look into it |
| 03:11.59 | dli | starseeker, trying again |
| 03:17.49 | dli | starseeker, better, that error doesn't show up |
| 03:19.07 | CIA-28 | BRL-CAD: 03starseeker * r48014 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: Correct a few gross errors in ThirdParty.cmake, but still not clear how disabling opengl is messing with everything. |
| 03:19.41 | starseeker | I gotta go - dli, post how that turns out. Clearly I've got a bug to fix, but that ebuild is hopelessly out of date |
| 03:20.03 | dli | starseeker, ok |
| 04:43.57 | CIA-28 | BRL-CAD: 03starseeker * r48015 10/brlcad/trunk/misc/CMake/ (ThirdParty.cmake ThirdParty_TCL.cmake): Er, right, macros. Reset a conditional variable before using it again... |
| 05:01.34 | starseeker | dli: did it build? |
| 05:03.12 | dli | starseeker, it builds in a fresh folder |
| 05:03.25 | dli | starseeker, but still couldn't get it build in ebuild |
| 05:05.30 | starseeker | that ebuild's settings are way too aggressive |
| 06:11.59 | CIA-28 | BRL-CAD: 03starseeker * r48016 10/brlcad/trunk/ (3 files in 3 dirs): |
| 06:12.01 | CIA-28 | BRL-CAD: Do more work to make BRLCAD_BUNDLED_LIBS=System do what it claims to do. Also |
| 06:12.01 | CIA-28 | BRL-CAD: make Tcl packages respect it, unless BRLCAD_TCL is overridden locally - then |
| 06:12.01 | CIA-28 | BRL-CAD: respect the local Tcl setting rather than BUNDLED_LIBS. Still needs some |
| 06:12.01 | CIA-28 | BRL-CAD: testing - not a terribly useful setting for us, but the Linux distributions will |
| 06:12.01 | CIA-28 | BRL-CAD: probably want it so we should shake it out and make it behave. |
| 06:12.40 | CIA-28 | BRL-CAD: 03starseeker * r48017 10/brlcad/trunk/INSTALL: Doing Tk as a Tcl extension, so docs are generated for it - add 'em. |
| 06:48.24 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 10:33.02 | *** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 11:54.46 | *** join/#brlcad ``Erik (~erik@BRLCAD.ORG) | |
| 14:12.25 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 16:22.42 | CIA-28 | BRL-CAD: 03starseeker * r48018 10/brlcad/trunk/src/other/CMakeLists.txt: Needing the C library from a Tcl/Tk package is compilcating things... however, a bit of a pattern is emerging... |
| 16:27.11 | dli | starseeker, I updated ebuilds in gentoo science overlay. Noticed building failures due to: LDFLAGS "--as-needed", BRLCAD_ENABLE_RTSERVER=ON, and CXXFLAGS="-std=c++0x" |
| 16:32.28 | starseeker | hmm. yeah, rtserver's build can be a bit finicky |
| 16:32.44 | starseeker | that's the java bit - I doubt most people would miss it |
| 16:33.11 | starseeker | hehe - this is awesome: |
| 16:33.23 | starseeker | '"Computer scientists" don't write code, they write books explaining why all existing implementations are wrong.' |
| 16:34.58 | dli | starseeker, still, gentoo wants features be specified by USE flags, not but auto-detection, so, it's not encouraged to use BRLCAD_BUNDLED_LIBS=AUTO |
| 16:42.23 | starseeker | dli: yeah, I know - one of the longer active bugs in the history of the gentoo bug database was the "here's a BRL-CAD ebuild" discussion arguing about things like autodetection and default installation location |
| 16:43.11 | dli | starseeker, default location settled down to /usr/brlcad/, iirc |
| 16:43.16 | starseeker | The commits last night were working to fix the "System" setting for BRLCAD_BUNDLED_LIBS. That's what distributions *should* set in the future if they don't want any of our bundled libs |
| 16:44.04 | starseeker | It will still annoy them because System won't disable opennurbs, scl, and one or two other src/other libraries |
| 16:44.32 | starseeker | the reason for that, however, is those are *locally modified* copies - a system version, at least at the moment, would not be expected to work correctly |
| 16:45.39 | starseeker | we *could* stick those local "forks" into our own source tree and avoid the issue, but the point/hope is to eventually establish those as separate projects - progress is already being made in that regard with scl |
| 16:46.10 | starseeker | src/other libraries and tools tend to have more uses than just BRL-CAD, so there is a reasonable hope they will attract other interest |
| 16:46.47 | starseeker | the odds of that go up if it's easy to build the library "in isolation" |
| 16:47.38 | starseeker | so we maintain our build system in such a way that those libraries are seaprate projects, even though we're the only users/source for those particular versions |
| 16:47.51 | starseeker | s/seaprate/separate/g |
| 16:50.28 | starseeker | scl (the Step Class Libraries) is showing activity on a github project, and once we get things to the point where their build and auto-generated output work for us and support our step-g convertor, we'll be able to use a hypothetical system SCL install |
| 16:51.10 | dli | starseeker, setting to System fails with svn: http://pastebin.mozilla.org/1408136 |
| 16:51.54 | starseeker | dli: do you have itcl and itk installed? |
| 16:52.38 | dli | starseeker, yes: Installed versions: 3.4_beta1, Installed versions: 3.4_pre20090417-r1 |
| 16:53.05 | starseeker | where is libitcl located? |
| 16:53.11 | starseeker | and libitk? |
| 16:53.39 | dli | starseeker, /usr/lib64/itcl3.4/libitcl3.4.so |
| 16:53.53 | dli | /usr/lib64/itk3.4/libitk3.4.so |
| 16:54.23 | starseeker | alright... let me see if I can tell why the find_library calls aren't seeing those |
| 16:56.13 | starseeker | oh, by the way - unless gentoo's lemon package puts lempar.c in /usr/bin/, lemon isn't going to work |
| 16:59.45 | CIA-28 | BRL-CAD: 03starseeker * r48019 10/brlcad/trunk/src/other/CMakeLists.txt: We need the ITCL version set for find_library... since we aren't testing for it when we're going whole-hog system, set it to 3.4 if it's not defined. |
| 17:00.44 | starseeker | need to think about that one... ideally, even if we're forcing system we'd still want the version installed if there is one... |
| 17:01.10 | starseeker | jeez, this business of using Tcl/Tk package C libraries is a nightmare |
| 17:07.58 | starseeker | actually, gentoo doesn't even have its own lemon package - must be part of sqlite |
| 17:09.33 | starseeker | aaand the installed one doesn't like something |
| 17:09.39 | starseeker | even with lempar.c present |
| 17:14.31 | starseeker | dli: you have re2c installed? |
| 17:14.52 | starseeker | dev-util/re2c-0.13.5 is what I've got here... |
| 17:15.03 | dli | starseeker, yes, Installed versions: 0.13.5 |
| 17:15.07 | starseeker | ok |
| 17:15.24 | starseeker | that looks like it should work, but the system lemon is a disaster |
| 17:15.35 | starseeker | it's not even versioned on its own |
| 17:16.21 | starseeker | and I can't stick lempar.c in /usr/bin even if this version HAD worked... talk about your sandbox violations |
| 17:16.47 | starseeker | perplex is written by one of our own developers to wrap re2c, so there won't be a package for that one |
| 17:16.51 | starseeker | one sec... |
| 17:19.25 | CIA-28 | BRL-CAD: 03starseeker * r48020 10/brlcad/trunk/ (misc/CMake/ThirdParty.cmake src/other/CMakeLists.txt): (log message trimmed) |
| 17:19.25 | CIA-28 | BRL-CAD: Extend the NOSYS mechanism to tools as well. Perplex is our own tool, so even a |
| 17:19.25 | CIA-28 | BRL-CAD: SYSTEM install isn't going to have it available (it's our own code, just being |
| 17:19.25 | CIA-28 | BRL-CAD: treated as a separate project) and trying to use a system version of lemon is... |
| 17:19.25 | CIA-28 | BRL-CAD: problematic, to say the very least. lempar.c isn't likely to be present, and |
| 17:19.25 | CIA-28 | BRL-CAD: even when our copy is placed in /usr/bin problems occurred. lemon isn't |
| 17:19.25 | CIA-28 | BRL-CAD: packaged by itself, so it's hard to know what to do about that... suggest |
| 17:22.06 | CIA-28 | BRL-CAD: 03starseeker * r48021 10/brlcad/trunk/src/libged/simulate/simrt.c: shadowed variable warning... |
| 17:29.48 | *** join/#brlcad Elrohir (~kvirc@p579F0159.dip.t-dialin.net) | |
| 17:33.32 | dli | starseeker, it works now, with System |
| 17:34.08 | starseeker | There's a lemon ebuild in an overlay: http://gpo.zugaina.org/dev-util/lemon/euscan |
| 17:37.55 | CIA-28 | BRL-CAD: 03n_reed * r48022 10/brlcad/trunk/src/other/perplex/ (scanner.re scanner_template.c): cleanup |
| 17:38.09 | starseeker | that DOES work, if I re-work the FindLEMON logic a bit |
| 17:38.25 | starseeker | http://gentoo-overlays.zugaina.org/gentoo-zh/portage/dev-util/lemon/ |
| 17:38.49 | starseeker | that would be a good one to advocate for in the main gentoo trunk, to help a system BRL-CAD build work |
| 17:39.06 | starseeker | he's patched lemon so the template file can live in /usr/share |
| 17:52.49 | CIA-28 | BRL-CAD: 03starseeker * r48023 10/brlcad/trunk/ (misc/CMake/FindLEMON.cmake src/other/CMakeLists.txt): Redo the handling of lemon a bit, since there does exist at least one working path for a viable system lemon installation. |
| 17:54.18 | starseeker | hah - there's a redhat package too, that apparently does the same thing |
| 17:54.20 | starseeker | sweet |
| 17:54.28 | starseeker | http://rpm.pbone.net/index.php3/stat/4/idpl/15156214/dir/redhat_el_5/com/lemon-3.6.20-1.el5.i386.rpm.html |
| 18:00.11 | starseeker | and it looks like FreeBSD does something sane |
| 18:00.18 | starseeker | looks like Gentoo is behind the curve |
| 18:00.24 | starseeker | embarassing on a dev tool |
| 18:03.18 | CIA-28 | BRL-CAD: 03starseeker * r48024 10/brlcad/trunk/src/other/CMakeLists.txt: Rework explanatory text for lemon |
| 18:04.51 | starseeker | dli: it should still work with Gentoo, but you'll probably need that overlay ebuild install of lemon |
| 18:05.04 | starseeker | or specify -DBRLCAD_LEMON=Bundled |
| 18:09.28 | starseeker | and there's no tkhtml ebuild that I can see, so out of the box archer won't work... |
| 18:18.25 | CIA-28 | BRL-CAD: 03starseeker * r48025 10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake: Add a note about another refactor needed to allow local enabling - right now can't set SYSTEM and then turn on just Tkhtml |
| 19:39.56 | CIA-28 | BRL-CAD: 03bob1961 * r48026 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Allow empty polygons. |
| 19:45.46 | CIA-28 | BRL-CAD: 03bob1961 * r48027 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Add callbacks for polygon creation. |
| 21:50.30 | CIA-28 | BRL-CAD: 03n_reed * r48028 10/brlcad/trunk/misc/CMake/FindPERPLEX.cmake: Corrected perplex and re2c options. Basing re2c intermediate name on output name, not output path. |
| 22:46.09 | CIA-28 | BRL-CAD: 03n_reed * r48029 10/brlcad/trunk/src/libgcv/wfobj/tri_face.c: s/BU_GET/bu_pool_get/ so that freeing with standard nmg routines doesn't cause bomb. |
| 00:06.22 | CIA-28 | BRL-CAD: 03starseeker * r48030 10/brlcad/trunk/misc/CMake/FindPERPLEX.cmake: remove FindPERPLEX template logic - as an integral part of BRL-CAD we don't need it, and if it becomes more general later we can plug in a variation of the updated TEMPLATE variable setting just added to FindLEMON. |
| 00:26.53 | CIA-28 | BRL-CAD: 03n_reed * r48031 10/brlcad/trunk/src/libgcv/wfobj/tri_face.c: Use the NMG macros instead of bu_pool_get. NMG memory scheme may change, but allocation macros should always be compatible with nmg_k* routines. |
| 05:32.25 | CIA-28 | BRL-CAD: 03starseeker * r48032 10/brlcad/trunk/misc/CMake/ (ThirdParty_TCL2.cmake tcltest.tcl.in): Checkpoint a work-in-progress rewrite of the Tcl 3rd party extension macro. Not working yet, but far enough along I'd hate to lose it so get what is written into the tree. |
| 05:37.28 | CIA-28 | BRL-CAD: 03starseeker * r48033 10/brlcad/trunk/src/other/ (re2c/CMake/FindLEMON.cmake step/CMake/FindLEMON.cmake): Update the other FindLEMON files |
| 08:03.21 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 18:34.05 | CIA-28 | BRL-CAD: 03Watchmoviesonlinestream 07http://brlcad.org * r3256 10/wiki/User:Watchmoviesonlinestream: New page: This is a review on the movie Sherlock Holmes: A Game of Shadows. The sequel to 2009's "Sherlock Holmes" carries the subtitle "A Game of Shadows." What that means, exactly, is anyone's ... |
| 18:34.12 | CIA-28 | BRL-CAD: 03Watchmoviesonlinestream 07http://brlcad.org * r3257 10/wiki/User:Watchmoviesonlinestream: |
| 19:00.44 | *** join/#brlcad ``Erik_ (erik@c-69-140-109-104.hsd1.md.comcast.net) | |
| 20:53.08 | CIA-28 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User:Watchmoviesonlinestream]]": Spamming content |
| 20:55.58 | CIA-28 | BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Watchmoviesonlinestream]] with an expiry time of infinite (account creation disabled): Inserting nonsense/gibberish into pages |
| 03:49.53 | *** join/#brlcad louipc (~louipc@archlinux/fellow/louipc) | |
| 05:26.55 | CIA-28 | BRL-CAD: 03starseeker * r48034 10/brlcad/trunk/misc/CMake/BRLCAD_Options.cmake: Add a disabled option to BUNDLED_OPTIONS |
| 05:53.55 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 11:07.14 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 15:21.34 | ``Erik | el chalupacabra strikes again :/ |
| 17:20.35 | starseeker | pokes CIA |
| 17:21.47 | starseeker | crosses fingers - hopefully that'll solve the Tcl/Tk system package issues |
| 17:21.54 | starseeker | (phew) |
| 19:39.38 | *** join/#brlcad merzo (~merzo@50-178-133-95.pool.ukrtel.net) | |
| 23:52.54 | CIA-28 | BRL-CAD: 03starseeker * r48035 10/brlcad/trunk/misc/CMake/ThirdParty_TCL2.cmake: More work on the Tcl/Tk 3rd party macro rewrite |
| 00:01.03 | CIA-28 | BRL-CAD: 03starseeker * r48036 10/brlcad/trunk/ (5 files in 3 dirs): |
| 00:01.04 | CIA-28 | BRL-CAD: Swap in the new Tcl macro system. Needs debugging, but this will hopefully be a |
| 00:01.04 | CIA-28 | BRL-CAD: more organized framework within which to find the bugs. Also added one |
| 00:01.04 | CIA-28 | BRL-CAD: additional feature to the summary - if a component is disabled that is to be |
| 00:01.04 | CIA-28 | BRL-CAD: reported in the summary, and a system version was NOT found, put an exclamation |
| 00:01.04 | CIA-28 | BRL-CAD: point after the OFF to indicate potential trouble. |
| 00:21.13 | CIA-28 | BRL-CAD: 03tbrowder2 * r48037 10/brlcad/trunk/src/libged/tables.c: correcting type coercion on matrices fixes bug 3392558 (soilds and regions commands cause core dump) |
| 00:24.22 | CIA-28 | BRL-CAD: 03tbrowder2 * r48038 10/brlcad/trunk/src/libged/tables.c: fixed some ws formatting |
| 03:33.44 | CIA-28 | BRL-CAD: 03starseeker * r48039 10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake: try a little harder to reset the library variable for proper searching. also ended up reindenting. |
| 03:39.07 | CIA-28 | BRL-CAD: 03starseeker * r48040 10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake: Stray debug print statement |
| 03:47.53 | CIA-28 | BRL-CAD: 03starseeker * r48041 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: tweak for generic ThirdParty macro to fix handling of cached build targets... |
| 03:55.18 | starseeker | almost there... |
| 07:29.26 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 08:32.35 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 09:44.40 | *** join/#brlcad merzo (~merzo@173-242-132-95.pool.ukrtel.net) | |
| 12:23.51 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 12:52.44 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 12:58.22 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 12:58.35 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 13:00.08 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 16:05.28 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 16:32.18 | CIA-28 | BRL-CAD: 03n_reed * r48042 10/brlcad/trunk/src/other/perplex/ (scanner.re scanner_template.c): add missing malloc casts |
| 16:41.45 | CIA-28 | BRL-CAD: 03n_reed * r48043 10/brlcad/trunk/src/other/perplex/ (scanner.re scanner_template.c): need array notation to quell const char warning |
| 16:51.28 | CIA-28 | BRL-CAD: 03n_reed * r48044 10/brlcad/trunk/src/other/perplex/scanner_template.c: typo |
| 17:13.41 | brlcad | should make the fmt strings const too n_reed_ |
| 17:47.30 | CIA-28 | BRL-CAD: 03tbrowder2 * r48045 10/brlcad/trunk/doc/docbook/presentations/en/intro-to-tcltk.xml: correct error in result of 'lindex' command; amplify lead-in text |
| 17:48.57 | CIA-28 | BRL-CAD: 03n_reed * r48046 10/brlcad/trunk/src/other/perplex/ (scanner.re scanner_template.c): more type corrections |
| 17:49.37 | CIA-28 | BRL-CAD: 03r_weiss * r48047 10/brlcad/trunk/src/librt/primitives/nmg/nmg_rt_isect.c: Updated function 'nmg_class_ray_vs_shell' in file 'nmg_rt_isect.c'. Corrected a bug with the manifolds creating and freeing. Added some comments. |
| 17:55.23 | CIA-28 | BRL-CAD: 03r_weiss * r48048 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mod.c: Updated function 'nmg_gluefaces' in file 'nmg_mod.c'. Removed magic checks to improve performance. Changed a variable to a register variable to improve performance. |
| 17:58.27 | CIA-28 | BRL-CAD: 03r_weiss * r48049 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: |
| 17:58.27 | CIA-28 | BRL-CAD: Rewrote function 'nmg_model_edge_fuse' and added function 'v_ptr_comp' to file |
| 17:58.27 | CIA-28 | BRL-CAD: 'nmg_fuse.c'. These changes were to improve the performance of edge fusing for |
| 17:58.27 | CIA-28 | BRL-CAD: nmg objects. This change reduces the time to perform nmg boolean operations. |
| 18:51.15 | CIA-28 | BRL-CAD: 03r_weiss * r48050 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mesh.c: Updated function 'nmg_mesh_two_faces' in file 'nmg_mesh.c'. Removed magic tests to improve performance. |
| 19:47.17 | CIA-28 | BRL-CAD: 03brlcad * r48051 10/brlcad/trunk/src/libgcv/wfobj/obj_rules.re: looks like the memset parameters are transposed. was setting 0 bytes. |
| 20:13.13 | CIA-28 | BRL-CAD: 03brlcad * r48052 10/brlcad/trunk/src/librt/comb/comb.c: increase buffer to 1024 to minimize risk of (bogus or valid) user-input encountering the limit. don't perform an isupper() test .. tolower() already has to. |
| 20:21.39 | CIA-28 | BRL-CAD: 03brlcad * r48053 10/brlcad/trunk/src/librt/ (comb/comb.c db_tree.c search.c vlist.c): 'new' is a terrible non-descript name for a variable and causes compilation problems for c++ compilers. rename. |
| 22:55.50 | CIA-28 | BRL-CAD: 03r_weiss * r48054 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: Updated function 'nmg_break_all_es_on_v' in file 'nmg_fuse.c'. Removed unnecessary logic and removed magic checks. These changes were to improve performance. |
| 22:57.55 | CIA-28 | BRL-CAD: 03r_weiss * r48055 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: |
| 22:57.56 | CIA-28 | BRL-CAD: Updated functions 'nmg_isect_two_face2p_jra' and 'nmg_isect_eu_fu' in file |
| 22:57.56 | CIA-28 | BRL-CAD: 'nmg_inter.c'. Reduced the number of edges to process when calling the function |
| 22:57.56 | CIA-28 | BRL-CAD: 'nmg_break_all_es_on_v'. These changes were to improve performance. |
| 23:01.22 | CIA-28 | BRL-CAD: 03n_reed * r48056 10/brlcad/trunk/src/other/perplex/ (perplex.cpp scanner.re): remove debug output |
| 23:10.32 | CIA-28 | BRL-CAD: 03r_weiss * r48057 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 23:10.32 | CIA-28 | BRL-CAD: Updated function 'nmg_triangulate_rm_degen_loopuse' in file 'nmg_tri.c'. Changed |
| 23:10.32 | CIA-28 | BRL-CAD: the logic for the status messages so that debug must be enabled for the messages |
| 23:10.32 | CIA-28 | BRL-CAD: to be displayed. The reason is the messages are not useful to the user and |
| 23:10.32 | CIA-28 | BRL-CAD: clutter the display during triangulation of nmg objects. |
| 23:11.49 | CIA-28 | BRL-CAD: 03n_reed * r48058 10/brlcad/trunk/src/libgcv/wfobj/ (10 files): replaced obj re2c scanner with perplex scanner |
| 23:27.39 | CIA-28 | BRL-CAD: 03starseeker * r48059 10/brlcad/trunk/ (16 files in 6 dirs): Rework the non-tcl 3rd party logic as well. Split the build target macros for code generators into their own files, so we don't have to load the Find*.cmake files in all situations. |
| 23:34.34 | CIA-28 | BRL-CAD: 03starseeker * r48060 10/brlcad/trunk/INSTALL: Add tweak to documentation string. |
| 23:37.54 | starseeker | n_reed_: sweet! |
| 23:54.57 | CIA-28 | BRL-CAD: 03brlcad * r48061 10/brlcad/trunk/src/libbu/str.c: file name changed |
| 23:56.53 | CIA-28 | BRL-CAD: 03starseeker * r48062 10/brlcad/trunk/src/librt/db_tree.c: Um... why are we bu_bombing when we call this? asc2g isn't happy when building the db targets... |
| 00:15.25 | CIA-28 | BRL-CAD: 03starseeker * r48063 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: oops - zigging when we need to zag. no turning things on when we have SYSTEM settings. |
| 00:21.17 | brlcad | whaaa .... when did that file get committed??? |
| 00:21.36 | brlcad | ah, r48053 |
| 00:34.59 | CIA-28 | BRL-CAD: 03starseeker * r48064 10/brlcad/trunk/ (misc/CMake/ThirdParty_TCL.cmake src/other/CMakeLists.txt): Few more tweaks for that annoying 'system only even though there's nothing installed on it that I need' case... |
| 00:38.17 | CIA-28 | BRL-CAD: 03starseeker * r48065 10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake: No need to double warn |
| 00:52.51 | CIA-28 | BRL-CAD: 03starseeker * r48066 10/brlcad/trunk/misc/CMake/ (ThirdParty.cmake ThirdParty_TCL.cmake): Don't show disabled 3rd party opts, and make sure to show them if they become enabled. |
| 00:56.07 | CIA-28 | BRL-CAD: 03starseeker * r48067 10/brlcad/trunk/misc/CMake/xsltproc.cmake.in: Note why it's important to make the directory first when running xsltproc |
| 01:02.51 | CIA-28 | BRL-CAD: 03starseeker * r48068 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: Oops - just because we've already added the subdirectory, that doesn't mean we don't need to set the executable variable for the second executable... |
| 01:04.09 | CIA-28 | BRL-CAD: 03starseeker * r48069 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: in fact, the exe var setting is only conditional on the build setting. |
| 01:07.18 | CIA-28 | BRL-CAD: 03starseeker * r48070 10/brlcad/trunk/doc/docbook/books/en/BRL-CAD_Tutorial_Series-VolumeI.xml: fix xmllint error |
| 01:07.43 | starseeker | what's the LOTR line... |
| 01:07.51 | starseeker | "but that is only a few leaves in a forest" |
| 01:08.27 | starseeker | isn't feeling OCD enough to tackle 'em all right now... |
| 01:09.16 | starseeker | Looks like the on/off behavior of the CMake logic is improved considerably - will have to ask dli to give it a go when comes back |
| 02:15.43 | CIA-28 | BRL-CAD: 03starseeker * r48071 10/brlcad/trunk/ (8 files in 2 dirs): Woo hoo! autogenerate the guts of the configure rosetta script right along with the docs. |
| 02:17.05 | starseeker | "I object to doing things that computers can do." - Olin Shivers |
| 04:33.01 | CIA-28 | BRL-CAD: 03starseeker * r48072 10/brlcad/trunk/src/tclscripts/archer/BotUtility.tcl: use bu_brlcad_root to find libbu.<whatever> - wasn't working from build directory |
| 04:54.22 | starseeker | holds his breath... do I actually have it fully working now? |
| 08:08.13 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 13:00.36 | starseeker | hmm http://pastebin.mozilla.org/1413600 |
| 13:01.29 | starseeker | clang 2.9 |
| 13:01.36 | starseeker | tries 3.0 |
| 13:44.55 | starseeker | /src/libbu/simd.c:33:5: error: extension used [-Werror,-pedantic,-Wlanguage-extension-token] asm volatile("cpuid":"=b"(b),"=c"(c),"=d"(d):"a"(0x1)); ^ |
| 13:45.11 | starseeker | apparently asm isn't standard ANSI C? |
| 13:54.32 | starseeker | well... it builds a working archer with the strict flag off at least |
| 14:28.32 | brlcad | looks like a valid bug it detected with the [Z] indexing past the end of the array |
| 14:30.22 | brlcad | asm isn't ansi, it's gcc |
| 14:30.35 | brlcad | could try changing it to __asm__ which gcc also supports |
| 14:32.06 | brlcad | otherwise, that logic can have another strict define added to keep clang from entering |
| 14:32.44 | brlcad | yeah, from clang manual: The parser recognizes "asm" and "typeof" as keywords in gnu* modes; the variants "__asm__" and "__typeof__" are recognized in all modes |
| 14:32.53 | brlcad | so it might not consider it an extension as __ |
| 14:33.03 | ``Erik | or break the func out to a .s file (which is probably the strict ansi permissible approach, but not exactly portable) |
| 14:47.48 | *** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 14:48.06 | starseeker | ``Erik: why is that not portable? |
| 14:48.29 | starseeker | (sure you're right, just wondering what the reasons would be) |
| 14:52.16 | ``Erik | a unix system will expect an at&t format .s file, windows will expect an intel format .asm file |
| 14:52.35 | ``Erik | linux will depend on whether you're using nasm or gas or yasm or ... |
| 14:52.51 | starseeker | ah - so embedding it in C code lets the C compiler translate it? |
| 14:53.17 | ``Erik | nah, but it lets the precompiler choose the code path |
| 14:53.53 | ``Erik | hm, I thought I put the winderz one in simd.c, guess I only did *nix |
| 14:53.58 | ``Erik | (gcc specific, even) |
| 14:55.06 | starseeker | so we'd have to conditionalize in CMake, looks like: http://www.cmake.org/Wiki/CMake/Assembler |
| 14:55.33 | starseeker | doable |
| 14:55.42 | ``Erik | and maintain parallel versions, unfortunately... I believe bullet has cross platform detection, so if that becomes a core part, we can let them handle that detail |
| 14:57.56 | starseeker | ``Erik: iirc, wasn't the simd stuff in bullet nicely contained in its own little bit of code? |
| 14:59.12 | starseeker | ah, right |
| 14:59.16 | starseeker | http://bullet.svn.sourceforge.net/viewvc/bullet/trunk/Extras/simdmathlibrary/ |
| 15:00.24 | starseeker | any reason not to just use that? |
| 15:01.30 | starseeker | bemusedly notes we could just use that instead of looking for the "m" library, assuming it actually supported all the platforms we're interested in... |
| 15:01.42 | starseeker | "a SIMDized version of the |
| 15:01.44 | starseeker | 7 C99 standard math library (libm)" |
| 15:02.04 | starseeker | "a SIMDized version of the C99 standard math library (libm)" rather |
| 15:09.10 | starseeker | ah, phooey - looks like it's only for PowerPC and Cell |
| 15:14.16 | starseeker | oh, I see - they've got it in vectormath, I think... http://code.google.com/p/bullet/source/browse/trunk/src/vectormath/ |
| 15:22.20 | starseeker | humph |
| 15:22.49 | starseeker | why can't someone just do a straight-up simd-libm under BSD license somewhere... |
| 15:23.49 | starseeker | ptview guy has one that looks close, but it's GPL3 |
| 15:26.49 | starseeker | oh, here's the bullet overview: http://bulletphysics.com/ftp/pub/test/physics/demos/Vector_Math_Library-Overview.pdf |
| 15:39.28 | starseeker | ah... looks like the benefits of simd manifest more at the higher vector level operations... could be the libm implementations for those platforms are because they needed 'em there... |
| 15:41.46 | starseeker | shakes head - ``Erik, I leave it to you :-) |
| 16:29.08 | CIA-28 | BRL-CAD: 03tbrowder2 * r48073 10/brlcad/trunk/src/tclscripts/mged/botedit.tcl: need manual dependency to define BotEditor' this fixes bug number 3392650 |
| 16:31.44 | CIA-28 | BRL-CAD: 03tbrowder2 * r48075 10/brlcad/trunk/NEWS: shameless credit for two bug fixes |
| 16:31.44 | CIA-28 | BRL-CAD: 03tbrowder2 * r48074 10/brlcad/trunk/src/tclscripts/boteditor/botTools.tcl: correct typo in menu |
| 16:56.15 | CIA-28 | BRL-CAD: 03starseeker * r48076 10/brlcad/trunk/src/other/step/src/express/expprint.c: Not really sure what's going on with printScope here... |
| 17:31.03 | brlcad | simd calls for just a few ops is utterly ridiculous |
| 17:31.25 | brlcad | you get a benefit when you can push your data into the simd pipeline AND KEEP IT THERE |
| 17:31.48 | brlcad | so a low-level simdified-libm isn't really feasible unless you overhaul all math |
| 17:34.07 | brlcad | as for the original elephant in the room, fixing that clang error is trivial and amounts to probably a 1-line tweak to the cpp logic |
| 17:36.07 | brlcad | moving the asm conditionalization from cppland to cmake wouldn't actually fix anything (and it'd be worse imho) |
| 18:23.15 | starseeker | brlcad: so Sony probably did it just to have a libm api for those platforms. Probably why bullet stuck it in extra |
| 18:28.18 | CIA-28 | BRL-CAD: 03starseeker * r48077 10/brlcad/trunk/src/libbu/simd.c: asm -> __asm__ |
| 18:37.25 | brlcad | that looks like the right fix :) |
| 18:39.01 | brlcad | starseeker: I meant feasible for our use -- a libm where your data is already in simd entities wouldn't be a bad idea |
| 18:39.38 | brlcad | heck, even something like gpm using simd under the hood would probably be a (modest) benefit (to us) |
| 18:46.28 | CIA-28 | BRL-CAD: 03n_reed * r48078 10/brlcad/trunk/src/other/perplex/scanner.re: fixed patterns that sometimes skipped quote characters, causing bad parsing of quoted text |
| 19:26.11 | CIA-28 | BRL-CAD: 03tbrowder2 * r48079 10/brlcad/trunk/regress/mged.sh: add more detailed regression tests for the mged solids and regions commands |
| 19:35.54 | CIA-28 | BRL-CAD: 03n_reed * r48080 10/brlcad/trunk/src/other/perplex/scanner.re: need to update scope flag at end of condition scope |
| 20:15.53 | CIA-28 | BRL-CAD: 03bob1961 * r48081 10/brlcad/trunk/ (3 files in 3 dirs): Added the ability to move a data object (i.e. line, arrow, polygon) or point. Previously only data points could be moved. |
| 20:59.55 | CIA-28 | BRL-CAD: 03erikgreenwald * r48082 10/brlcad/trunk/src/libgcv/test_bottess.c: add some meat |
| 21:13.22 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 21:32.30 | CIA-28 | BRL-CAD: 03brlcad * r48083 10/brlcad/trunk/src/libbu/str.c: mark a few more of the expressions that result in logging as UNLIKELY |
| 22:15.19 | CIA-28 | BRL-CAD: 03brlcad * r48084 10/brlcad/trunk/ (4 files in 2 dirs): |
| 22:15.20 | CIA-28 | BRL-CAD: add a new bu_str_escape() function for escaping string characters with |
| 22:15.20 | CIA-28 | BRL-CAD: backslashes. supports static and dynamic memory models as well as overlapping |
| 22:15.20 | CIA-28 | BRL-CAD: or same input/output buffers. should be threadsafe and re-entrant as long as |
| 22:15.20 | CIA-28 | BRL-CAD: the inputs are. |
| 22:55.26 | CIA-28 | BRL-CAD: 03brlcad * r48085 10/brlcad/trunk/ (include/bu.h src/libbu/escape.c): |
| 22:55.27 | CIA-28 | BRL-CAD: add a new bu_str_unescape() function for removing backslash characters from |
| 22:55.27 | CIA-28 | BRL-CAD: strings. simpler to implement since the output is always less than or equal in |
| 22:55.27 | CIA-28 | BRL-CAD: size to the input. otherwise,similar to bu_str_escape() in that it supports |
| 22:55.27 | CIA-28 | BRL-CAD: static and dynamic memory models as well as overlapping or same input/output |
| 22:55.27 | CIA-28 | BRL-CAD: buffers and should be threadsafe and re-entrant as long as the inputs are. make |
| 22:55.28 | CIA-28 | BRL-CAD: sure we null-terminate. |
| 23:06.31 | CIA-28 | BRL-CAD: 03n_reed * r48086 10/brlcad/trunk/src/other/perplex/ (CMakeLists.txt scanner_template.c): lose libm dependency |
| 23:16.51 | CIA-28 | BRL-CAD: 03brlcad * r48087 10/brlcad/trunk/src/libbu/test_quote.c: doesn't actually use stdarg or stdlib |
| 23:17.12 | CIA-28 | BRL-CAD: 03tbrowder2 * r48088 10/brlcad/trunk/regress/mged.sh: document reason for new special tests |
| 23:39.23 | CIA-28 | BRL-CAD: 03brlcad * r48089 10/brlcad/trunk/src/libbu/escape.c: don't call strlen() before we know whether input is NULL |
| 23:49.20 | CIA-28 | BRL-CAD: 03brlcad * r48090 10/brlcad/trunk/src/libbu/test_escape.c: add an initial stab at a unit test for the new escape/unescape routines |
| 23:49.36 | CIA-28 | BRL-CAD: 03brlcad * r48091 10/brlcad/trunk/src/libbu/ (CMakeLists.txt Makefile.am): hook test_escape into the build |
| 00:16.57 | CIA-28 | BRL-CAD: 03brlcad * r48092 10/brlcad/trunk/src/libbu/test_escape.c: simplify testing, generalizing for bu_str_escape() cases |
| 00:32.28 | CIA-28 | BRL-CAD: 03brlcad * r48093 10/brlcad/trunk/src/libbu/test_escape.c: add escape test cases |
| 00:46.24 | CIA-28 | BRL-CAD: 03starseeker * r48094 10/brlcad/trunk/regress/repository.sh: remove the INSTALL check, doesn't apply in this form and its breaking distcheck. Leave the Makefile.am check until there aren't any more Makefile.am files... |
| 01:06.57 | CIA-28 | BRL-CAD: 03brlcad * r48095 10/brlcad/trunk/src/libbu/escape.c: yay for unit testing doing its job. if there's a slash at the end, we might run past the buffer end so make sure we don't. |
| 01:07.46 | CIA-28 | BRL-CAD: 03brlcad * r48096 10/brlcad/trunk/src/libbu/test_escape.c: a few more enhanced tests to check for round-trip behavior |
| 01:48.34 | *** join/#brlcad scooby (~Robert@host-92-21-209-117.as13285.net) | |
| 02:22.41 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 05:05.26 | brlcad | starseeker: did you sync the doc files before moving the .cmake files into place? |
| 05:10.51 | brlcad | just a double-check since there've been a lot of edits since they were first added |
| 05:13.07 | brlcad | a build system functionality assertion came to mind earlier today, making sure the build still works and runs correctly on a non-X11 build |
| 05:13.43 | starseeker | brlcad: yeah - did a diff on them, synced a fair bit of stuff |
| 05:13.44 | brlcad | temporarily renaming/moving Xlib.h or libX11.so should do the trick |
| 05:13.48 | brlcad | awesome |
| 05:14.23 | starseeker | figured you'd want to do a read-through anyhow - I've been doing the CMake stuff so long I'm not the best guy for an intro anymore |
| 05:14.43 | brlcad | I do/am/will, but wanted to check on that status before I get dirty |
| 05:14.45 | starseeker | updated all the platform readme's at the same time |
| 05:14.50 | starseeker | nods |
| 05:15.40 | starseeker | I tried disabling X11, I think... haven't done a full "move the X11 lib and header" test though |
| 05:15.54 | brlcad | fwiw, the src/other/step/express declaration you added masked a bug |
| 05:16.03 | starseeker | yeah, was afraid of that... |
| 05:16.15 | brlcad | that function is called with two args and three args |
| 05:16.43 | starseeker | has no clue why gcc wasn't barfing... |
| 05:16.59 | brlcad | there's nothing wrong if the types happen to be coercable |
| 05:17.08 | brlcad | C allows feeding too few |
| 05:17.10 | starseeker | is betting most of the changes needed for a non-Tk build apply to the non-X11 build... |
| 05:17.33 | brlcad | not an important issue, just noteworthy |
| 05:18.01 | brlcad | I wouldn't look into it myself until nick is done and we're merged with the git branch |
| 05:18.04 | starseeker | nods - didn't want to dig too hard into it, since we've got to sync with the github version at some point and I think that's diverged pretty significantly |
| 05:18.08 | starseeker | er, yeay :-) |
| 05:18.26 | brlcad | mental check for later though, as that's a crasher |
| 05:18.35 | brlcad | or rather, a memory corruption |
| 05:18.54 | starseeker | is of the opinion that codebase needs a thorough housecleaning |
| 05:19.51 | starseeker | hopefully the github work will help some, but I must admit that "we yanked frees to avoid crashes and the memory usage exploded" wasn't particularly reassuring |
| 05:20.34 | brlcad | grain of salt |
| 05:20.54 | brlcad | there's a couple weeks of reviewing each commit one by one ahead |
| 05:21.16 | brlcad | preceeded by a week or two setting up regression tests for step-g |
| 05:21.27 | brlcad | er, s/week/day/ |
| 05:21.42 | starseeker | winces... that'll be fun (in a pulling teeth kinda way...) |
| 05:22.31 | starseeker | does want to check out the ctest setup they have for testing |
| 05:22.48 | brlcad | meh |
| 05:25.10 | CIA-28 | BRL-CAD: 03starseeker * r48097 10/brlcad/trunk/src/other/CMakeLists.txt: only look for tk.h if we actually want Tk... |
| 05:38.55 | CIA-28 | BRL-CAD: 03starseeker * r48098 10/brlcad/trunk/misc/CMake/BRLCAD_Options.cmake: If it walks like a bool and quacks like a bool, call it a bool |
| 06:07.29 | CIA-28 | BRL-CAD: 03starseeker * r48099 10/brlcad/trunk/ (CMakeLists.txt src/libfb/tcl.c src/mged/doevent.c): These tweaks get things building without X11 headers on Gentoo linux... |
| 06:20.39 | starseeker | woo-hoo! make regress passed on an X11-disabled build (after the above changes) |
| 06:21.02 | starseeker | build with the X11 headers and /usr/lib64/libX11.so moved |
| 06:21.06 | starseeker | s/build/built |
| 06:21.37 | starseeker | wonders how long it's been since that config was tested... or the non-Tk one, for that matter... lot of the changes were C code... |
| 06:22.22 | brlcad | they were all strict issues, which wasn't in place before this year |
| 06:22.58 | brlcad | my last non-x build was probably 2 years ago |
| 06:23.08 | brlcad | mged works? |
| 06:23.21 | brlcad | mged test.g ... should kick off classic iirc |
| 06:26.42 | starseeker | uh... it launches mged with the nu display manager |
| 06:26.55 | brlcad | right, good |
| 06:27.07 | brlcad | nu = null |
| 06:27.11 | starseeker | does prompt first, which is a bit silly when nu is the only option |
| 06:31.51 | CIA-28 | BRL-CAD: 03starseeker * r48100 10/brlcad/trunk/CMakeLists.txt: Disable opengl like we mean it if the required criteria aren't met |
| 06:32.29 | starseeker | actually didn't expect all of regress to pass - figured the gui or loadtk commands would have an issue |
| 06:33.34 | starseeker | well, another checkbox ticked :-) |
| 06:33.36 | starseeker | zzzzz |
| 06:40.36 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 07:03.12 | brlcad | it's worked in the past so even if it didn't work, wouldn't likely have been anything significant -- usually just code creep from that mode not getting exercised regularly |
| 07:03.43 | brlcad | nice to have that baseline confirmed working again, though and in strict nonetheless |
| 07:04.11 | brlcad | though those fb funcs shouldn't exist public (missing fb callbacks) |
| 08:55.24 | brlcad | calls it, wanders |
| 10:16.53 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 14:12.11 | ``Erik | heh http://brlcad.org/~erik/brlcad.svg |
| 14:16.02 | archivist | monitor not wide enough error at line one |
| 14:21.22 | ``Erik | heh, it's a mess, and it's the cleanest one from the base graphviz algorithm set |
| 15:16.33 | brlcad | ``Erik: funny but more useful would be seeing just one tool instead of 400 .. that's most of the complexity |
| 15:17.21 | brlcad | there's approximately 25 base libraries, so one tool is going to have somewhere around that many lines anyways |
| 15:17.26 | brlcad | ~400 * 25 |
| 15:17.26 | ibot | 10000 |
| 15:21.24 | ``Erik | I don't see any obvious way to do that, this was just "cmake --graphviz=brlcad.dot /path/to/brlcad" |
| 15:22.21 | ``Erik | they may be add-on generators to cmake *shrug* |
| 15:28.31 | starseeker | yawns |
| 15:49.48 | CIA-28 | BRL-CAD: 03starseeker * r48101 10/brlcad/trunk/src/other/step/src/express/ (CMakeLists.txt expprint.c): Nick says he created this for debugging purposes and it can go. |
| 15:55.19 | CIA-28 | BRL-CAD: 03starseeker * r48102 10/brlcad/trunk/ (3 files in 3 dirs): |
| 15:55.19 | CIA-28 | BRL-CAD: Do a little rework on the lemon target macro - saw an error: Error renaming from |
| 15:55.19 | CIA-28 | BRL-CAD: 'expparse.c' to 'expparse.c': No such file or directory - this might happen if |
| 15:55.19 | CIA-28 | BRL-CAD: lemon does something wrong, but it could also mean lemon isn't done and the copy |
| 15:55.19 | CIA-28 | BRL-CAD: command tries to proceed anyway, so split out the steps to make intermediate |
| 15:55.20 | CIA-28 | BRL-CAD: file dependencies explicit - may help. |
| 15:56.25 | kanzure | hello world |
| 16:17.19 | CIA-28 | BRL-CAD: 03n_reed * r48103 10/brlcad/trunk/src/other/perplex/scanner_template.c: better to create string scanner from pointer and length |
| 16:26.23 | brlcad | hello kanzure |
| 16:37.35 | CIA-28 | BRL-CAD: 03n_reed * r48104 10/brlcad/trunk/src/other/perplex/scanner_template.c: copy input string to buffer so it can be modified if necessary |
| 16:37.47 | CIA-28 | BRL-CAD: 03brlcad * r48105 10/brlcad/trunk/regress/mged.sh: don't need two tests just to make sure mged will receive commands. keep the more complex example since it creates geometry. |
| 16:39.11 | CIA-28 | BRL-CAD: 03r_weiss * r48106 10/brlcad/trunk/src/librt/primitives/nmg/nmg_info.c: Updated function 'nmg_find_pt_in_lu' in file 'nmg_info.c'. Made changes to improve performance. |
| 16:42.43 | CIA-28 | BRL-CAD: 03n_reed * r48107 10/brlcad/trunk/src/other/perplex/scanner_template.c: avoid mixing code and declarations |
| 16:45.43 | CIA-28 | BRL-CAD: 03r_weiss * r48108 10/brlcad/trunk/src/librt/primitives/nmg/nmg_info.c: Updated function 'nmg_find_pt_in_face' in file 'nmg_info.c'. Made changes to improve performance. |
| 16:48.27 | CIA-28 | BRL-CAD: 03tbrowder2 * r48109 10/brlcad/trunk/regress/mged.sh: only one test tgm now |
| 17:03.35 | CIA-28 | BRL-CAD: 03n_reed * r48110 10/brlcad/trunk/src/other/perplex/scanner_template.c: added an unput routine similar to lex unput |
| 18:49.03 | CIA-28 | BRL-CAD: 03n_reed * r48111 10/brlcad/trunk/src/other/perplex/scanner_template.c: add missing prototype |
| 18:57.12 | CIA-28 | BRL-CAD: 03brlcad * r48112 10/brlcad/trunk/regress/mged.sh: readd an even simpler test that makes sure mged will run and exit before we start piping in commands |
| 19:24.25 | CIA-28 | BRL-CAD: 03brlcad * r48113 10/brlcad/trunk/src/librt/primitives/nmg/nmg_info.c: (log message trimmed) |
| 19:24.25 | CIA-28 | BRL-CAD: magic number checking overhaul. remove most of the interior loop and interior |
| 19:24.25 | CIA-28 | BRL-CAD: logic magic number checking. it's important to perform magic number checks as |
| 19:24.25 | CIA-28 | BRL-CAD: part of input validation (akin to assert()) but need not be part of ongoing |
| 19:24.25 | CIA-28 | BRL-CAD: calculations. checking inputs insures that we'll at least narrow in on memory |
| 19:24.26 | CIA-28 | BRL-CAD: corruption to a function scope, which is usually good enough. technically, this |
| 19:24.26 | CIA-28 | BRL-CAD: may introduce a logic change if there is some nasty code relying on a bu_bomb() |
| 20:27.44 | CIA-28 | BRL-CAD: 03brlcad * r48114 10/brlcad/trunk/src/other/perplex/mbo_getopt.cpp: make the mbo_getopt replacement func return -1 like getopt(3), not EOF |
| 20:28.57 | CIA-28 | BRL-CAD: 03brlcad * r48115 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.cpp scanner.re scanner_template.c): fgetc() returns an int, not a char so capture the EOF return value being cast through unsigned char as an int instead of a char (255) |
| 20:36.38 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 20:42.38 | CIA-28 | BRL-CAD: 03starseeker * r48116 10/brlcad/trunk/regress/weight.sh: |
| 20:42.38 | CIA-28 | BRL-CAD: Add a (commented out, for now) additional test for rtweight that feeds it a |
| 20:42.38 | CIA-28 | BRL-CAD: more... quirky density file. As rtweight's parsing of density files is |
| 20:42.38 | CIA-28 | BRL-CAD: currently set up, this will infinite loop (and fill up your hard drive) but |
| 20:42.38 | CIA-28 | BRL-CAD: after rtweight is improved enable this test (will need to replace the current |
| 20:42.39 | CIA-28 | BRL-CAD: 'results text' for weight2 with the correct output. |
| 21:00.43 | CIA-28 | BRL-CAD: 03brlcad * r48117 10/brlcad/trunk/src/librt/prcomb.c: file is unused |
| 21:06.25 | CIA-28 | BRL-CAD: 03brlcad * r48118 10/brlcad/trunk/src/libicv/Makefile.am: manually include the png dirs |
| 21:36.48 | starseeker | brlcad: does the Clarified Artistic License pose any problems for us? http://www.ncftp.com/ncftp/doc/LICENSE.txt |
| 21:55.22 | brlcad | starseeker: given it's a license we don't presently use or have to manage, absolutely .. it'd be yet another with potential incompatibility subtleties |
| 21:55.47 | brlcad | reading the history, the license is an improvmement but was later replaced by the artistic 2.0 license |
| 21:55.56 | brlcad | currently the osi-recommended one to use |
| 21:56.31 | brlcad | still, I'd be leary simply because it's "yet another" .. something would have to be darn worthy and that .. seems unlikely |
| 22:04.54 | starseeker | OK, kinda figured... |
| 22:06.21 | starseeker | nuts |
| 22:06.32 | brlcad | from my quick layman reading.. |
| 22:06.40 | brlcad | it seems to me like it's entirely gpl-comaptible |
| 22:06.50 | brlcad | but not necessarily lgpl compatible |
| 22:08.17 | starseeker | alrightie. Not terribly critical - the elvis clone of Vi has a Win32 port and uses that license. |
| 22:08.28 | brlcad | hehe |
| 22:08.57 | starseeker | ? |
| 22:09.11 | brlcad | nothing :) |
| 22:09.17 | brlcad | I'd just agree |
| 22:09.23 | brlcad | not terribly critical :P |
| 22:09.37 | starseeker | ah |
| 22:11.53 | starseeker | just thought I'd ask - jove is ever more glaring on the "thorns in the side of the Windows port" list |
| 22:12.26 | CIA-28 | BRL-CAD: 03bob1961 * r48119 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Modified the signature of the polygon callback. Added calls to polygon callback in end_poly_move. |
| 22:12.56 | brlcad | http://developer.qt.nokia.com/doc/qt-4.8/widgets-codeeditor.html |
| 22:13.18 | brlcad | or even http://developer.qt.nokia.com/doc/qt-4.8/qtextedit.html#id-2c12966c-5a94-46ac-a1ef-dc375be82992 |
| 22:14.48 | CIA-28 | BRL-CAD: 03bob1961 * r48120 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Added functionality to get/set the polygon list in view coordinates. |
| 22:52.53 | CIA-28 | BRL-CAD: 03n_reed * r48121 10/brlcad/trunk/src/other/ (10 files in 3 dirs): initial build of step express parser using perplex scanner |
| 23:26.42 | CIA-28 | BRL-CAD: 03starseeker * r48122 10/brlcad/trunk/TODO: Add note to work on rtweight/density file parsing. |
| 23:42.02 | CIA-28 | BRL-CAD: 03Tbrowder 07http://brlcad.org * r3258 10/wiki/Contributor_Quickies: correct typo |
| 00:06.45 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 00:07.04 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 00:53.38 | CIA-28 | BRL-CAD: 03tbrowder2 * r48123 10/brlcad/trunk/src/librt/primitives/bot/bot.c: ws cleanup |
| 01:02.22 | CIA-28 | BRL-CAD: 03Tbrowder 07http://brlcad.org * r3259 10/wiki/Contributor_Quickies: correct name of mged command (bb, not bbox); correct typo |
| 02:16.32 | CIA-28 | BRL-CAD: 03tbrowder2 * r48124 10/brlcad/trunk/src/librt/primitives/bot/g_bot_include.c: ws format |
| 02:54.29 | *** join/#brlcad IriX64 (~kvirc@64.229.226.37) | |
| 05:09.49 | CIA-28 | BRL-CAD: 03Sean 07http://brlcad.org * r3260 10/wiki/Contributor_Quickies: better |
| 07:46.58 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 07:51.19 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 08:22.56 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 12:36.23 | *** join/#brlcad cvds_ (~leila@e255180.upc-e.chello.nl) | |
| 13:31.27 | CIA-28 | BRL-CAD: 03tbrowder2 * r48125 10/brlcad/trunk/TODO: expand list of missing man pages so it can be easily viewed |
| 13:50.58 | CIA-28 | BRL-CAD: 03tbrowder2 * r48126 10/brlcad/trunk/src/libged/bb.c: correct file name in intro comment |
| 13:52.27 | CIA-28 | BRL-CAD: 03tbrowder2 * r48127 10/brlcad/trunk/regress/main.sh: correct typo |
| 13:53.08 | CIA-28 | BRL-CAD: 03tbrowder2 * r48128 10/brlcad/trunk/INSTALL: correct typo |
| 13:55.11 | *** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz) | |
| 13:55.17 | pawleeq | hello |
| 13:56.15 | pawleeq | I published another popular article about modeling in brlcad, it can be found here: http://www.abclinuxu.cz/clanky/brl-cad-zaklady-modelovani |
| 13:56.28 | pawleeq | it is in czech |
| 13:58.18 | brlcad | pawleeq: awesome! |
| 13:58.43 | brlcad | I was reading that earlier today :) |
| 14:00.00 | brlcad | well not "reading" per-se, but skimming over the article and looking at the BRL-CAD portions I recognized ;) |
| 14:01.03 | pawleeq | I will continue with this and deeper I will go, the more I could use your help |
| 15:02.13 | CIA-28 | BRL-CAD: 03tbrowder2 * r48129 10/brlcad/trunk/t.c: adding temp file to test ssh access |
| 15:03.08 | CIA-28 | BRL-CAD: 03tbrowder2 * r48130 10/brlcad/trunk/t.c: modding temp file to test ssh access |
| 15:15.58 | CIA-28 | BRL-CAD: 03tbrowder2 * r48131 10/brlcad/trunk/t.c: modding temp file to test ssh access |
| 15:16.25 | CIA-28 | BRL-CAD: 03tbrowder2 * r48132 10/brlcad/trunk/t.c: modding temp file to test ssh access |
| 15:17.41 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 15:23.52 | CIA-28 | BRL-CAD: 03tbrowder2 * r48133 10/brlcad/trunk/t.c: modding temp file to test ssh access |
| 15:24.29 | CIA-28 | BRL-CAD: 03tbrowder2 * r48134 10/brlcad/trunk/t.c: modding temp file to test ssh access |
| 15:37.59 | CIA-28 | BRL-CAD: 03tbrowder2 * r48135 10/brlcad/trunk/t.c: modding temp file to check ssh access |
| 15:50.16 | CIA-28 | BRL-CAD: 03tbrowder2 * r48136 10/brlcad/trunk/t.c: test ssh access |
| 15:53.19 | CIA-28 | BRL-CAD: 03tbrowder2 * r48137 10/brlcad/trunk/t.c: test ssh access |
| 15:54.06 | CIA-28 | BRL-CAD: 03tbrowder2 * r48138 10/brlcad/trunk/t.c: testing ssh access |
| 16:09.40 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) | |
| 16:12.19 | CIA-28 | BRL-CAD: 03bob1961 * r48139 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Tweak cadwidgets::Ged::pane_mouse_3dpoint to also use polygon points. |
| 16:15.57 | CIA-28 | BRL-CAD: 03tbrowder2 * r48140 10/brlcad/trunk/t.c: test ssh access |
| 16:16.27 | CIA-28 | BRL-CAD: 03tbrowder2 * r48141 10/brlcad/trunk/t.c: testing ssh access |
| 16:19.49 | CIA-28 | BRL-CAD: 03tbrowder2 * r48142 10/brlcad/trunk/t.c: testing ssh access |
| 17:55.42 | CIA-28 | BRL-CAD: 03brlcad * r48143 10/brlcad/trunk/include/bu.h: |
| 17:55.42 | CIA-28 | BRL-CAD: document the extensively expaned support being added to bu_str_escape() to make |
| 17:55.42 | CIA-28 | BRL-CAD: the previous 'chars' parameter actually represent a full-fledged regular bracket |
| 17:55.42 | CIA-28 | BRL-CAD: expression. this includes support for negative (^) expressions and named |
| 17:55.42 | CIA-28 | BRL-CAD: character classes. |
| 18:00.26 | CIA-28 | BRL-CAD: 03brlcad * r48144 10/brlcad/trunk/src/libbu/escape.c: stub in initial function for expanding the previous 'chars' input into an expanded list of chars to match |
| 18:05.29 | CIA-28 | BRL-CAD: 03starseeker * r48145 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: we want full path for this binary... |
| 18:19.45 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 18:27.45 | CIA-28 | BRL-CAD: 03tbrowder2 * r48146 10/brlcad/trunk/src/tclscripts/mged/help.tcl: add mged 'bb' command help |
| 18:57.17 | CIA-28 | BRL-CAD: 03n_reed * r48147 10/brlcad/trunk/src/other/step/src/express/ (expparse.y expscan.l): fixed a few typos |
| 18:58.14 | CIA-28 | BRL-CAD: 03tbrowder2 * r48148 10/brlcad/trunk/doc/docbook/system/mann/en/bb.xml: correct typo |
| 19:08.09 | CIA-28 | BRL-CAD: 03brlcad * r48149 10/brlcad/trunk/src/libbu/test_escape.c: some clarify on the escape test output |
| 19:08.58 | CIA-28 | BRL-CAD: 03brlcad * r48150 10/brlcad/trunk/src/libbu/escape.c: add support for negative expressions (start with circumflex/carat '^'). |
| 20:09.54 | CIA-28 | BRL-CAD: 03brlcad * r48151 10/brlcad/trunk/src/libbu/vls.c: |
| 20:09.54 | CIA-28 | BRL-CAD: prevent crashing after bu_vls_strgrab() if the vls was never initialized. |
| 20:09.54 | CIA-28 | BRL-CAD: bu_vls_addr() will return the address to a static buffer if it's empty, so care |
| 20:09.54 | CIA-28 | BRL-CAD: must be taken to not return that as the char* from bu_vls_strgrab(). |
| 20:26.23 | CIA-28 | BRL-CAD: 03brlcad * r48152 10/brlcad/trunk/src/libbu/escape.c: fix/add support for negative expressions specified with ^ where we needed to iterate over all chars to make sure none match before escaping |
| 20:26.31 | CIA-28 | BRL-CAD: 03brlcad * r48153 10/brlcad/trunk/src/libbu/test_escape.c: Add some not-cases to the testing |
| 21:59.58 | CIA-28 | BRL-CAD: 03starseeker * r48154 10/brlcad/trunk/t.c: clear stray file from ssh testing... |
| 22:07.04 | CIA-28 | BRL-CAD: 03starseeker * r48155 10/brlcad/trunk/CMakeLists.txt: Oops - put the DATA_DIR prefix in the MAN_DIR variable |
| 22:14.45 | CIA-28 | BRL-CAD: 03tbrowder2 * r48156 10/brlcad/trunk/regress/mged.sh: redfine 'tgms' |
| 22:18.54 | CIA-28 | BRL-CAD: 03tbrowder2 * r48157 10/brlcad/trunk/src/libged/analyze.c: fix typo |
| 22:21.17 | CIA-28 | BRL-CAD: 03tbrowder2 * r48158 10/brlcad/trunk/src/libged/bb.c: remove extra blank line |
| 23:36.00 | CIA-28 | BRL-CAD: 03starseeker * r48159 10/brlcad/trunk/misc/CMake/Docbook.cmake: copy-paste fix in error messages for Docbook tools |
| 04:07.45 | CIA-28 | BRL-CAD: 03starseeker * r48160 10/brlcad/trunk/misc/CMake/Docbook.cmake: Docbook.cmake is logic (one of the reasons for breaking it out here) so put the header on it. |
| 04:09.30 | CIA-28 | BRL-CAD: 03starseeker * r48161 10/brlcad/trunk/ (3 files in 2 dirs): Might as well match the spelling for DocBook that docbook.org is using. |
| 04:18.16 | CIA-28 | BRL-CAD: 03starseeker * r48162 10/brlcad/trunk/ (CMakeLists.txt src/other/CMakeLists.txt): go for consistency |
| 09:01.58 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 09:32.13 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 09:33.16 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 18:04.24 | CIA-28 | BRL-CAD: 03erikgreenwald * r48163 10/brlcad/trunk/src/libgcv/test_bottess.c: macro up the test harness for simple triangle intersection (obfuscate to clarify) |
| 19:12.18 | CIA-28 | BRL-CAD: 03n_reed * r48164 10/brlcad/trunk/src/libgcv/wfobj/ (CMakeLists.txt Makefile.sample): remove unused makefile |
| 19:34.00 | *** join/#brlcad fosburg (~steve@or-67-238-28-16.dhcp.embarqhsd.net) | |
| 19:36.26 | CIA-28 | BRL-CAD: 03n_reed * r48165 10/brlcad/trunk/src/libgcv/wfobj/ (obj_grammar.yy obj_parser.cpp obj_rules.h obj_rules.l): Renaming to distinguish extra type and state type. Remember to free extra. |
| 19:51.55 | CIA-28 | BRL-CAD: 03n_reed * r48166 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.cpp): initialize conditions string, close output file, and free special-op strings |
| 19:56.31 | *** part/#brlcad fosburg (~steve@or-67-238-28-16.dhcp.embarqhsd.net) | |
| 22:02.35 | CIA-28 | BRL-CAD: 03n_reed * r48167 10/brlcad/trunk/src/libbu/escape.c: don't declare variable in for's init expression |
| 22:37.25 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 22:50.31 | CIA-28 | BRL-CAD: 03n_reed * r48168 10/brlcad/trunk/src/libgcv/wfobj/obj_token_type.h: avoid comparison between bool and unsigned char |
| 22:51.34 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 23:15.02 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 03:23.50 | CIA-28 | BRL-CAD: 03Starseeker 07http://brlcad.org * r3261 10/wiki/Lexer_Parser: Update lexer/parser page with actual outcome, mention Nick's work with perplex |
| 03:43.24 | *** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 03:54.37 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 04:15.57 | *** join/#brlcad n_reed_ (~molto_cre@BZ.BZFLAG.BZ) | |
| 04:16.39 | *** join/#brlcad DarkCalf (DC@173.231.40.98) | |
| 04:21.28 | *** join/#brlcad DarkCalff (DC@173.231.40.98) | |
| 08:26.46 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 16:28.52 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 21:55.51 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 23:44.45 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 00:16.38 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 04:38.11 | *** join/#brlcad DarkCalfz (DC@173.231.40.98) | |
| 07:02.47 | *** join/#brlcad merzo (~merzo@152-186-133-95.pool.ukrtel.net) | |
| 09:30.32 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 13:39.36 | *** join/#brlcad merzo (~merzo@98-66-132-95.pool.ukrtel.net) | |
| 00:23.36 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 03:50.06 | *** join/#brlcad Sparxz (~mark@213-94-252-200-dynamic.b-ras1.dbn.dublin.eircom.net) | |
| 04:01.56 | *** part/#brlcad Sparxz (~mark@213-94-252-200-dynamic.b-ras1.dbn.dublin.eircom.net) | |
| 11:05.39 | *** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 13:40.25 | *** join/#brlcad merzo (~merzo@141-81-200-46.pool.ukrtel.net) | |
| 16:10.18 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 17:15.32 | *** join/#brlcad xFirex_ (75c19b3e@gateway/web/freenode/ip.117.193.155.62) | |
| 17:16.22 | xFirex_ | Hello Everyone, I have a problem with BRLCad brlcad-7.20.4-0.fedora.i386.rpm in Fedora 16 |
| 17:16.55 | xFirex_ | Getting this error when trying to start it "/usr/brlcad/bin/mged: error while loading shared libraries: libtclcad.so.19: cannot open shared object file: No such file or directory " |
| 17:23.51 | *** part/#brlcad xFirex_ (75c19b3e@gateway/web/freenode/ip.117.193.155.62) | |
| 17:25.52 | *** join/#brlcad N0Nick (75c19b3e@gateway/web/freenode/ip.117.193.155.62) | |
| 17:28.09 | *** join/#brlcad Konopen (75c19b3e@gateway/web/freenode/ip.117.193.155.62) | |
| 17:32.15 | *** part/#brlcad Konopen (75c19b3e@gateway/web/freenode/ip.117.193.155.62) | |
| 17:34.27 | *** join/#brlcad Konopen (75c19b3e@gateway/web/freenode/ip.117.193.155.62) | |
| 17:35.11 | Konopen | Hello Everyone, I have problem running brlcad 7.20.4-0 in fedora 16 |
| 17:40.23 | *** part/#brlcad Konopen (75c19b3e@gateway/web/freenode/ip.117.193.155.62) | |
| 17:42.06 | *** join/#brlcad konopen (~nawin@117.193.155.62) | |
| 17:46.24 | konopen | Hello |
| 17:52.29 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 17:57.04 | konopen | Is anyone available to help me with an issue in brlcad |
| 18:02.58 | *** part/#brlcad konopen (~nawin@117.193.155.62) | |
| 18:14.46 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 22:50.43 | *** join/#brlcad ibot_ (~ibot@rikers.org) | |
| 22:50.43 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 05:46.56 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 06:02.12 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 06:05.18 | *** join/#brlcad cadnewbie (cadnewbie@ool-4a58d269.dyn.optonline.net) | |
| 07:41.56 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 11:03.19 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 11:32.08 | CIA-28 | BRL-CAD: 03Kides 07http://brlcad.org * r3262 10/wiki/FullHostList: |
| 11:32.16 | CIA-28 | BRL-CAD: 03Kides 07http://brlcad.org * r3263 10/wiki/FullHostList: |
| 13:40.55 | *** join/#brlcad merzo (~merzo@31-143-201-46.pool.ukrtel.net) | |
| 16:41.05 | CIA-28 | BRL-CAD: 03n_reed * r48169 10/brlcad/trunk/src/other/perplex/ (perplex.h scanner.re): remove unused member from scanner data struct |
| 17:15.15 | CIA-28 | BRL-CAD: 03erikgreenwald * r48170 10/brlcad/trunk/src/libgcv/CMakeLists.txt: disable test prog on win32 (dll export/import issue) |
| 18:23.30 | *** join/#brlcad Stattrav (u3131@gateway/web/irccloud.com/x-jchpvqokxrprekcq) | |
| 19:20.24 | CIA-28 | BRL-CAD: 03Sean 07http://brlcad.org * r3264 10/wiki/FullHostList: Reverted edits by [[Special:Contributions/Kides|Kides]] ([[User talk:Kides|Talk]]); changed back to last version by [[User:Dloman|Dloman]] |
| 19:20.27 | CIA-28 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Kides]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 20:22.06 | CIA-28 | BRL-CAD: 03n_reed * r48171 10/brlcad/trunk/src/other/perplex/scanner.re: typo |
| 20:22.40 | CIA-28 | BRL-CAD: 03n_reed * r48172 10/brlcad/trunk/src/other/perplex/ (parser.y token_type.h): add header and footer |
| 20:41.41 | CIA-28 | BRL-CAD: 03n_reed * r48173 10/brlcad/trunk/src/other/perplex/README.txt: initial documentation |
| 22:43.36 | CIA-28 | BRL-CAD: 03n_reed * r48174 10/brlcad/trunk/src/libgcv/wfobj/obj_grammar.yy: Per-vertex colors are a non-standard extension, but may be found in Meshlab OBJ exports. Accept but ignore them. |
| 23:46.00 | brlcad | jordisayol: presume you saw those rpm failure reports? .. any ideas on what the issue is? |
| 23:46.27 | jordisayol | brlcad: nop :-/ |
| 23:46.39 | jordisayol | I did not see |
| 23:48.24 | jordisayol | brlcad: where are those reports? |
| 00:03.39 | jordisayol | brlcad: can you please give me some info about rpm failure reports? |
| 00:38.26 | jordisayol | I have to go |
| 00:38.42 | jordisayol | brlcad: bye bye |
| 00:38.49 | brlcad | ok |
| 00:38.52 | brlcad | sorry, got distracted |
| 00:38.56 | brlcad | the reports were here |
| 00:39.05 | brlcad | 12:16 < xFirex_> Hello Everyone, I have a problem with BRLCad brlcad-7.20.4-0.fedora.i386.rpm in Fedora 16 |
| 00:39.08 | brlcad | 12:16 < xFirex_> Getting this error when trying to start it "/usr/brlcad/bin/mged: error while loading shared libraries: libtclcad.so.19: cannot open shared object file: No such file or directory " |
| 00:39.31 | brlcad | then another individual a little while later12:35 < Konopen> Hello Everyone, I have problem running brlcad 7.20.4-0 in fedora 16 |
| 00:42.23 | jordisayol | brlcad: do you know if they re-login after install? |
| 00:42.32 | brlcad | onope |
| 00:42.40 | brlcad | ill ask if they come back |
| 00:42.54 | jordisayol | brlcad: paths need re-login to be loaded |
| 00:43.00 | brlcad | do you modify ldconfig or something? |
| 00:43.41 | jordisayol | nop, i just modify the path and manpath env variables |
| 00:44.08 | brlcad | hm, interesting |
| 00:44.52 | brlcad | okay, well if someone else reports same error we'll see if that does the trick :) |
| 00:45.00 | brlcad | good to know, thanks |
| 00:45.18 | brlcad | would be good note for the release notes if it wasn't included |
| 00:45.19 | jordisayol | wait a moment.... |
| 00:49.37 | jordisayol | brlcad: the script executed during the installation is: brlcad/misc/debian/brlcad.postinst and when removed brlcad/misc/debian/brlcad.postrm , that's all |
| 00:49.46 | brlcad | k |
| 00:51.03 | brlcad | under traditional gnu ld behavior, that shouldn't affect a runtime error loading shared libraries |
| 00:51.24 | brlcad | but I know there have apparently been some major changes to the behavior of ld recently on linux |
| 00:52.44 | jordisayol | tomorrow I'll create a virtual machine with fedora 16 . is important the bit, 32 or 64? |
| 00:52.56 | brlcad | no idea, they weren't specific |
| 00:53.28 | jordisayol | well, I don't think so |
| 00:54.17 | jordisayol | ok, tomorrow i'll tell you something about |
| 00:55.12 | jordisayol | brlcad: goog night for me :-) near 2 o'clock here |
| 00:55.19 | brlcad | cya :) |
| 00:55.24 | jordisayol | bye |
| 07:07.43 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 07:12.13 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 08:14.34 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 12:57.12 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 13:15.22 | jordisayol | brlcad: ping |
| 15:18.14 | ``Erik | O.o |
| 15:19.16 | ``Erik | jordisayol: personal, or something that someone else can help with? |
| 15:19.46 | jordisayol | ``Erik: hello! |
| 15:20.31 | ``Erik | this laptop isn't letting me scroll up right, you're doing something with a debain leenewx variant? |
| 15:20.43 | ``Erik | debian, even :) |
| 15:21.16 | ``Erik | and something about fedora, even... but still linux |
| 15:21.19 | jordisayol | No, is just that yesterday brlcad toll me that some fedora 16 users experienced problems with our rmp packages |
| 15:21.48 | ``Erik | I vagually recall something about some sigill stuff, is that it |
| 15:22.27 | jordisayol | well, he says something about the shared libraries |
| 15:22.41 | jordisayol | missing for mged command |
| 15:23.19 | ``Erik | hm, you'll have to help me help you... the typical issue is requiring dev libs (.so) instead of user libs (.so.0.0) |
| 15:23.26 | ``Erik | in the link stage |
| 15:23.40 | ``Erik | (linux uses .so, right?) |
| 15:24.17 | jordisayol | yes, but this problem do not happen on fedora 15 and previous releases |
| 15:24.25 | ``Erik | if you do, um, the command to show link deps on the mged binary, that'll tell you a lot |
| 15:25.07 | jordisayol | the case is that today I've installed fedora 16 (64-bit) on a virtualbox, and in this clean linux, the mged properly works without problems |
| 15:25.48 | ``Erik | and 64b is the issue they complain about? or 32b? |
| 15:25.55 | brlcad | ``Erik: you read up on the penny arcade lashing? hilarious |
| 15:26.00 | brlcad | jordisayol: pong :0 |
| 15:26.03 | jordisayol | brlcad don't know |
| 15:26.08 | ``Erik | brlcad: ocean marketing? yeah... |
| 15:26.13 | jordisayol | hello brlcad |
| 15:26.14 | brlcad | hehe |
| 15:26.22 | ``Erik | talk about putting a foot in ones mouth |
| 15:26.33 | ``Erik | "bah, I can get into pax, who is this gabe guy? |
| 15:26.50 | jordisayol | hmmm, I already take lunch today.... |
| 15:27.22 | ``Erik | brlcad: bz->crit ? |
| 15:27.42 | brlcad | good idea actually |
| 15:28.07 | brlcad | been catching up on mails and commits, but this would be a good time |
| 15:28.22 | ``Erik | over a year coming |
| 15:28.52 | ``Erik | I put up an ssl httpd on crit, that might... complicate things. |
| 15:28.59 | jordisayol | brlcad: I've installed rpm for fedora on a fresh installed fedora 16 in virtualbox, and there is not any problem, even without re-login, just typing the full path /usr/brlcad/bin/mged |
| 15:29.29 | brlcad | jordisayol: okay, that's all that can be done for now then |
| 15:29.44 | jordisayol | brlcad: yes |
| 15:29.49 | ``Erik | jordisayol: can you pastebin ldd path/to/mged to see if there's an dev vs user lib issue? |
| 15:29.51 | brlcad | if it can't be reproduced and the person isn't here, we'll just have to wait for a follow-up report if any |
| 15:30.15 | ``Erik | (it's ldd, right? so used to otool -L) |
| 15:30.19 | jordisayol | ok, just a moment |
| 15:30.49 | jordisayol | yes, it is |
| 15:32.27 | brlcad | what I suspect is happening is there's some incompatible library already installed on their fedora system |
| 15:32.45 | brlcad | that or it was a partial/failed rpm download |
| 15:33.10 | brlcad | from the report, libtclcad.so.19 fails to load |
| 15:33.23 | ``Erik | if this is the sigill, it's a damaged binary, damaged cpu, or cpu spec'd for a different arch (686 vs 586 using 686 only opcodes) |
| 15:33.29 | brlcad | that may simply be the first library attempting to be loaded |
| 15:33.33 | ``Erik | illegal instruction and all |
| 15:34.11 | brlcad | it wasn't getting that farb |
| 15:34.17 | brlcad | far even |
| 15:34.22 | brlcad | 12:16 < xFirex_> Getting this error when trying to start it "/usr/brlcad/bin/mged: error while loading shared libraries: libtclcad.so.19: cannot open shared object file: No such file or directory " |
| 15:34.54 | ``Erik | ah, my bad, thought I saw a sigill convo and this was pertinant... this laptop won't let me page up to read backlog :) |
| 15:36.33 | ``Erik | brlcad: I took the day off, I want crit to get to 'stable' asap, I don't want to be responsible for other biz's and such, but will aid how I can... lets DO THI! YEAH! </joeswansonfromfamilyguy> |
| 15:38.38 | jordisayol | brlcad: here you have it: http://paste.debian.net/150390/ |
| 15:40.28 | jordisayol | brlcad: partial/failed is very unprovable because as rpm are compresses gz files, they cannot uncompress. |
| 15:41.22 | brlcad | yeah, so libtclcad is the first lib listed there |
| 15:41.54 | ``Erik | my guess would be that the issue is because someone installed to somewhere other than /usrbrlcad |
| 15:42.05 | brlcad | that could be |
| 15:42.31 | brlcad | whew, that mystery is solved |
| 15:43.11 | jordisayol | well, i can test this, by installing one by one on the system and testing mged. but this requires some time |
| 15:43.26 | ``Erik | can it be scripted? |
| 15:43.29 | brlcad | jordisayol: if you like, but I wouldn't worry about it |
| 15:43.43 | ``Erik | machine time is cheap, human time is expensive :) |
| 15:44.00 | brlcad | it's all speculation without that user -- more time effective to just wait for someone else to report an issue since it can't be easily reproduced |
| 15:44.07 | jordisayol | brlcad: can you make a "short" list of the probably libraries from the list? |
| 15:44.29 | brlcad | it seemed like more than that given two people reported a failure within a couple hours for fed16 but could have just been coincidence |
| 15:44.47 | brlcad | still all speculation though |
| 15:44.55 | jordisayol | or just the same user loget with different nicks |
| 15:45.17 | jordisayol | loed* |
| 15:45.35 | jordisayol | arggg! "logged" |
| 15:45.59 | ``Erik | smells like someone thought they were smarter than they were and screwed up being "clever" |
| 15:46.12 | brlcad | jordisayol: looks like they were the same person, same ip |
| 15:46.21 | jordisayol | hehe |
| 15:46.23 | brlcad | so yeah, don't worrya bout it ;) |
| 15:48.56 | jordisayol | well, if this "schizophrenic" user re-login, then we can continue the research |
| 15:49.18 | ``Erik | brlcad: bz lacks modssl and modproxy, which is why i'm reliant on crit. I'm using app servers behind modproxy, thus my interest in migration :) think we can knock it out before the newyear? |
| 15:49.56 | brlcad | possibly |
| 15:50.05 | brlcad | quite likely even |
| 15:51.03 | ``Erik | jordisayol: yeah, I'd call it pebcak, awesome that you're so aggressive in making it right :) |
| 15:52.43 | jordisayol | well, I don't know what "pebcak" is, but thank you :-) |
| 15:53.52 | ``Erik | "problem exists between computer and keyboard" |
| 15:54.46 | jordisayol | wow! i'll keep this sentence, hehe |
| 15:55.26 | brlcad | ~pebcak |
| 15:55.26 | ibot | methinks pebcak is Problem Exists Between Chair And Keyboard |
| 15:55.28 | ``Erik | <-- marks jordisayol down as a hero of open source software maintenance O.o :) |
| 15:55.35 | ``Erik | er, chair and keyboard, my bad |
| 15:55.55 | jordisayol | I think ``Erik is right :-/ |
| 15:55.58 | brlcad | usb isn't likely the problem ;) |
| 15:56.08 | ``Erik | din5, beeyotch |
| 15:56.18 | ``Erik | sometimes ps2 |
| 15:57.58 | ``Erik | brlcad: ponder... ssh tunnel for 3306 to new machine, migrate mysqldb, test on various hosted sites, then start moving sites? |
| 15:58.21 | ``Erik | (or is there an acceptable downtime window?) |
| 15:59.15 | brlcad | downtime is acceptable if it's less than a few hours |
| 15:59.21 | brlcad | tunnel would work too |
| 16:00.46 | ``Erik | I don't know the write rates of the variou sites, so I can't plot optimal migration |
| 16:01.29 | ``Erik | but I do want you to stop paying for that old clunker ;) |
| 16:02.22 | brlcad | this biggest one should be no longer active (bzflag's list service) |
| 16:03.41 | ``Erik | personally, I'd bias impact based on $$'s... a free service can take several hours downtime... a day or two, even |
| 16:03.43 | brlcad | I'll get working on moving our site today, that should at least get things going again |
| 16:04.00 | ``Erik | it's those $'s that scare me |
| 16:04.01 | brlcad | when was the last fs sync? |
| 16:04.10 | ``Erik | iuhho |
| 16:04.25 | ``Erik | I don't know if this machine has ever been synced |
| 16:05.16 | ``Erik | ya starting one up? |
| 16:05.19 | brlcad | .bz is technically a free service to those $$ users, so that's why a few hours is still acceptable .. just within reason shouldn't be more than a couple hours tops and that's with things going horribly wrong |
| 16:05.47 | brlcad | i'll check on it, don't want to migrate everything but user data is a good one to start with |
| 16:06.04 | ``Erik | I'm an rsync newb, so if you know it, I'll step back |
| 16:06.15 | ``Erik | otherwise, I'll pull up tutorial sites and start, let me know |
| 16:06.51 | ``Erik | I had some c&p scripts on the old crit, but no understanding |
| 16:09.16 | ``Erik | http://www.solitechgmbh.com/2010/03/06/using-rsync-for-quick-server-migartion/ seems useful |
| 16:09.20 | brlcad | you can sync the passwd/group files |
| 16:12.55 | ``Erik | done |
| 16:13.05 | brlcad | gettings an fs manifest, I'll sync user data |
| 16:13.37 | brlcad | is the sslified apache from ports or custom install? |
| 16:14.57 | ``Erik | ports |
| 16:15.07 | brlcad | great |
| 16:15.12 | ``Erik | lacks a primary, is all for vhost |
| 16:15.43 | ``Erik | well, it has a self-signed for primary, rather |
| 16:16.10 | ``Erik | "namecheap" was offering a free year of ssl for one name, so I grabbed one for elfga.com |
| 16:16.26 | brlcad | that's fine, nothing else using ssl obviously :) |
| 16:16.40 | ``Erik | they're also offering discounts and donations to eff for people who move from godaddy after the sopa mess |
| 16:16.55 | ``Erik | $10/yr for a basic cert |
| 16:17.01 | ``Erik | or so |
| 16:17.41 | brlcad | another task you could take up, setting up intrusion detection/monitoring and stats |
| 16:18.18 | ``Erik | I'm not sure what all you have set up, I've been manually setting the ipfw rules |
| 16:18.26 | brlcad | my manual scripts are rather old school now .. I'd imagine there has to be some better tools in ports that could be set up |
| 16:18.34 | brlcad | or even just migrating what's there, but that's not needed |
| 16:19.27 | brlcad | basically "figure something out" so some measure is in place, ideally something that firewalls based on some profile of bad actvitivity |
| 16:19.43 | ``Erik | we're not running telnetd, so there's no remote issue... I really don't know heh :( |
| 16:19.56 | ``Erik | what's the, uh, auto-ipfw deny script on bz? |
| 16:20.02 | ``Erik | I'll migrate it as a first stage |
| 16:20.19 | ``Erik | and we can todo a better solution |
| 16:21.22 | ``Erik | (I mean, no default accounts, no simple pw's, I don't think the risk profile is that high righ tnow) |
| 16:21.47 | ``Erik | ack, lappy assploded |
| 16:22.44 | ``Erik | defcon slides say "don't be stupid with setup" |
| 16:22.58 | brlcad | /etc/sbin and /etc/crontab have the juicy details |
| 16:23.23 | brlcad | but you'll have to go through each crontab one at a time to make sure it still is applicable for crit |
| 16:23.41 | brlcad | potential path and tool changes, safeguard changes, etc |
| 16:23.51 | brlcad | nothing terribly complicated, should be obvious |
| 16:24.03 | ``Erik | oh, your logging stuff, I've no idea what's up with that stuff |
| 16:24.07 | ``Erik | go set that up |
| 16:24.22 | brlcad | that can be later |
| 16:24.33 | ``Erik | ok, crit has been unlogged so far, fwiw |
| 16:24.47 | brlcad | knows |
| 16:24.49 | ``Erik | pheer my botnets |
| 16:25.05 | brlcad | so that's why you're logged in 15 times |
| 16:26.47 | ``Erik | don't make me slap your fro |
| 16:27.42 | ``Erik | (I believe this is the first time I've seen bz below 1.0 load) |
| 16:29.24 | brlcad | http://www.zazzle.com/dont_tease_my_fro_tshirt-235666363645812532 |
| 16:34.02 | ``Erik | http:/crit.brlcad.org:3000 |
| 16:37.16 | brlcad | don't know what to make of that |
| 16:38.55 | ``Erik | did it not work? |
| 16:40.07 | brlcad | I get a page, but have no idea what "Advertising Testes" are .. sounds sticky |
| 16:40.52 | ``Erik | that's bottom goop, it's basically a 'todo' list on steroids, or a project management suite stripped down |
| 16:41.15 | ``Erik | add locations, add tasks to locations, ... |
| 16:41.37 | brlcad | what about locationless tasks? :) |
| 16:41.51 | ``Erik | location called "anywhere" ;) I have one called "internet" |
| 16:42.47 | ``Erik | (seriosuly, tell me what sucks, obviously the landing page pitch sucks... but learn and adjust, right?) |
| 16:44.01 | brlcad | having to add a location sucks :) |
| 16:44.35 | ``Erik | "better default settings", roger |
| 16:45.06 | ``Erik | home and work, big honkin' delete buttons, yeh |
| 16:46.37 | brlcad | after I created a location, I could add a task but then I can't get back to that page if I merely start over .. back to creating a location |
| 16:46.43 | brlcad | i.e, better navigation |
| 16:47.34 | ``Erik | hroger, I've been unhappy with the default rails navigation myself |
| 16:47.37 | brlcad | when I recreated the same location, now it lists twice on the tasks page (along with a handful of other locations I didn't add) |
| 16:47.45 | ``Erik | uniq opt, ok |
| 16:48.04 | ``Erik | bah, other locs/ |
| 16:48.18 | ``Erik | ok, hold up... is the basic premise something you might use |
| 16:48.21 | ``Erik | ? |
| 16:49.32 | brlcad | dunno |
| 16:49.39 | brlcad | utility of task tracking software is mostly dependant on usability (and some on flexibility) |
| 16:50.03 | ``Erik | the idea is a todo list with deps, so things that are not readt are not listed |
| 16:50.06 | brlcad | it's hard to get that usability down to dead-simple obvious and still be flexible enough for a given purpose |
| 16:50.41 | ``Erik | (this is a throw-away to help me learn rails, btw) |
| 16:52.29 | ``Erik | yeah, actually, I wrote this to help me, and I haven't used it... imma call it :) |
| 16:52.49 | brlcad | heh |
| 17:58.34 | brlcad | woot, transfer underway |
| 18:32.08 | CIA-28 | BRL-CAD: 03n_reed * r48175 10/brlcad/trunk/src/tclscripts/boteditor/botTools.tcl: rename some labels to increase clarity |
| 22:03.45 | *** join/#brlcad b0ef (~b0ef@241.194.251.212.customer.cdi.no) | |
| 22:07.51 | CIA-28 | BRL-CAD: 03n_reed * r48176 10/brlcad/trunk/src/tclscripts/boteditor/ (botEditor.tcl botPropertyBox.tcl): allow setting bot mode and orientation from gui |
| 22:23.42 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 22:23.42 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 23:34.10 | *** join/#brlcad kunigami (~kunigami@201.53.198.241) | |
| 23:35.32 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 00:12.46 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 00:12.46 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 00:25.08 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 00:25.08 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 00:27.39 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 00:27.39 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 08:49.08 | *** join/#brlcad DarkCalfz (DC@173.231.40.98) | |
| 08:49.09 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 09:39.23 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 11:34.41 | *** join/#brlcad kunigami (~kunigami@201.53.198.241) | |
| 17:33.12 | CIA-28 | BRL-CAD: 03n_reed * r48177 10/brlcad/trunk/src/ (5 files in 2 dirs): handle app data more opaquely |
| 19:08.04 | *** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 21:59.15 | *** join/#brlcad kunigami (~kunigami@201.53.198.241) | |
| 23:32.17 | CIA-28 | BRL-CAD: 03n_reed * r48178 10/brlcad/trunk/include/dm.h: update drawLines3D macro prototype to agree with r47494 |
| 01:37.12 | *** join/#brlcad kunigami (~kunigami@201.53.198.241) | |
| 03:19.12 | *** join/#brlcad jarray52 (~bigbear@unaffiliated/jarray52) | |
| 04:23.25 | jarray52 | Is it possible to create parametric models in BRL CAD using scripts? |
| 04:24.34 | jarray52 | Actually, I should say, "Is it possible to create smooth surfaces using scripts?" |
| 04:27.34 | jarray52 | For example, an aerodynamic car body constructed from lots of small cubes. |
| 05:10.17 | *** join/#brlcad louipc (~louipc@archlinux/fellow/louipc) | |
| 10:00.05 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 13:53.56 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 14:18.44 | piksi | uhh |
| 14:19.10 | piksi | jordisayol: why would you want to create curved surfaces with cubes? you want nurbs for that |
| 14:21.03 | jordisayol | piksi: !? |
| 14:51.04 | piksi | whops |
| 14:51.28 | piksi | jordisayol: sorry, i didn't notice jarray52 left and used tab completion too hastly :-) |
| 14:52.09 | jordisayol | piksi: no problem :-) |
| 14:52.09 | jordisayol | Happy New Year! |
| 14:52.44 | piksi | same to you! :-) |
| 16:37.18 | ``Erik | starseeker: http://alvyray.com/Art/AndreAndWally.htm and look at the 'making of' pdf, some interesting history and a mention of MAGI |
| 18:47.27 | CIA-28 | BRL-CAD: 03n_reed * r48179 10/brlcad/trunk/src/other/CMakeLists.txt: condition SCL build on perplex/lemon rather than lex/yacc |
| 19:12.42 | *** join/#brlcad DarkCalfz (DC@173.231.40.98) | |
| 19:12.42 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) | |
| 19:21.32 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 19:24.01 | *** join/#brlcad louipc (~louipc@archlinux/fellow/louipc) | |
| 19:24.02 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 19:24.02 | *** join/#brlcad yiyus (1242712427@je.je.je) | |
| 19:24.02 | *** join/#brlcad cvds_ (~leila@e255180.upc-e.chello.nl) | |
| 19:24.02 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 19:24.02 | *** mode/#brlcad [+o ChanServ] by bartol.freenode.net | |
| 19:55.21 | CIA-28 | BRL-CAD: 03n_reed * r48180 10/brlcad/trunk/src/other/step/ (3 files in 3 dirs): remove old debug header |
| 20:54.42 | *** part/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 07:34.45 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 18:46.27 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 19:21.29 | CIA-28 | BRL-CAD: 03RobertoBhr11 07http://brlcad.org * r3265 10/wiki/User:RobertoBhr11: New page: Profuse Sweating - Three Solutions to prevent Excessive sweating Around 8 million people in The United States alone suffer from hyperhidrosis. Sweating profusely is labeled as a medical p... |
| 19:21.35 | CIA-28 | BRL-CAD: 03RobertoBhr11 07http://brlcad.org * r3266 10/wiki/User:RobertoBhr11: |
| 20:54.41 | CIA-28 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User:RobertoBhr11]]": idiot |
| 20:54.50 | CIA-28 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:RobertoBhr11]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 22:01.25 | brlcad | damn.. long conversion script had been processing for more than 30 days before the server rebooted .. didn't finish, not even halfway I think |
){kind=link}
