| 00:01.54 | brlcad | cristina: you're in the best position to fix it ;) |
| 00:02.48 | brlcad | if you're on the commits mailing list, you saw that my change was minimal to address that issue |
| 00:11.27 | cristina | brlcad: you were right, the c++ warnings weren't considered errors, it built completely after I eliminated the 'error' mentioned above. |
| 00:11.40 | cristina | yes, I saw that your change :) |
| 00:13.59 | brlcad | cristina: you should commit it too, not just a local mod |
| 00:14.31 | cristina | this is what I am doing right now |
| 00:14.38 | brlcad | awesome |
| 00:19.39 | CIA-55 | BRL-CAD: 03cprecup * r50838 10/brlcad/trunk/src/conv/g-voxel.c: set-but-unused warning for numVoxelX variable |
| 00:59.47 | CIA-55 | BRL-CAD: 03Cprecup 07http://brlcad.org * r3799 10/wiki/User:Cprecup/GSoC2012_progress: 02-03/06/2012 - week 2: libavoid integration |
| 02:05.15 | CIA-55 | BRL-CAD: 03starseeker * r50839 10/brlcad/trunk/src/librt/primitives/brep/brep_debug.cpp: default case doesn't use tmpname - fix for strict compilation |
| 02:21.24 | CIA-55 | BRL-CAD: 03starseeker * r50840 10/brlcad/trunk/ (6 files in 4 dirs): |
| 02:21.25 | CIA-55 | BRL-CAD: By default, turn on STRICT for C++ as well as C files. Add a specific option, |
| 02:21.25 | CIA-55 | BRL-CAD: NOSTRICTCXX, to allow targets to specifically disable strict compilation for C++ |
| 02:21.25 | CIA-55 | BRL-CAD: files only (beneficial for targets that use both C++ and C - allows the C to |
| 02:21.25 | CIA-55 | BRL-CAD: remain strict enabled.) |
| 02:23.05 | CIA-55 | BRL-CAD: 03starseeker * r50841 10/brlcad/trunk/src/libpc/CMakeLists.txt: update TODO in libpc |
| 02:23.27 | starseeker | brlcad: there we go |
| 02:23.47 | starseeker | only tested on gentoo, so far |
| 03:16.04 | brlcad | starseeker: curious, why'd you undo the macro? |
| 03:16.31 | brlcad | those bodies look identical, prime for macro reduction |
| 07:22.51 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 07:42.48 | CIA-55 | BRL-CAD: 03Escortnewcastle 07http://brlcad.org * r3800 10/wiki/Talk:Main_Page: |
| 07:42.48 | CIA-55 | BRL-CAD: Replacing page with '[http://www.escortsnewcastle.co.uk newcastle escorts] |
| 07:42.48 | CIA-55 | BRL-CAD: [http://www.escortsnewcastle.co.uk escorts in newcastle] |
| 07:42.48 | CIA-55 | BRL-CAD: [http://www.escortsnewcastle.co.uk newcastle escort]' |
| 09:00.36 | cristina | http://brlcad.org/wiki/Talk:Main_Page seems like someone really wanted to post this escort announcement: http://brlcad.org/w/index.php?title=Talk:Main_Page&action=history |
| 09:42.23 | CIA-55 | BRL-CAD: 03phoenixyjll * r50842 10/brlcad/trunk/src/librt/ (opennurbs_ext.h primitives/brep/brep_debug.cpp): quell set-but-unused warnings. |
| 10:02.15 | CIA-55 | BRL-CAD: 03Al Da Best 07http://brlcad.org * r3801 10/wiki/Talk:Main_Page: Undo revision 3800 by a spammer/spambot |
| 10:02.29 | Al_Da_Best | cristina, just undo them when that happens :) |
| 10:09.15 | *** join/#brlcad anrgmrty (u6512@gateway/web/irccloud.com/x-syfaefukhgasjgzf) |
| 10:36.53 | *** join/#brlcad anuragmurty (~anurag@14.139.128.14) |
| 10:48.06 | anrgmrty | brlcad: hi |
| 11:16.59 | d_rossberg | anrgmrty: the grid you are shooting looks reasonable but the evaluation can't be done in hit(), especially if you shoot many rays per voxel |
| 11:24.36 | CIA-55 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Escortnewcastle]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 11:41.03 | *** join/#brlcad Mahi (~Mahi@li364-30.members.linode.com) |
| 11:52.07 | *** join/#brlcad ksuzee (~ksu@193.151.107.42) |
| 12:12.42 | CIA-55 | BRL-CAD: 03bob1961 * r50843 10/brlcad/trunk/src/tclscripts/lib/Accordian.tcl: Added callbacks for when a panel is toggled open. Added a rename command for renaming panels. |
| 12:18.29 | CIA-55 | BRL-CAD: 03Phoenix 07http://brlcad.org * r3802 10/wiki/User:Phoenix/GSoc2012/Reports: /* Week 3 */ |
| 12:38.19 | anrgmrty | d_rossberg : do you mean i should somehow do the evaluation in main itself? |
| 12:39.26 | *** part/#brlcad anuragmurty (~anurag@14.139.128.14) |
| 12:40.12 | *** join/#brlcad anuragmurty (~anurag@14.139.128.14) |
| 12:41.49 | brlcad | anrgmrty: hit() is the callback for a single ray -- you can't evaluate before you've shot all rays for a given voxel (which might be multiple rays) |
| 12:42.09 | brlcad | so yes, in main() or better still in some routine that main() is calling |
| 12:42.22 | d_rossberg | as in the code i send to you: collect the data in the hit() function and evaluate it afterwards |
| 12:43.00 | anrgmrty | ok.. i will do that.. |
| 12:43.23 | d_rossberg | however, you could do the analysis inside the z and y loops |
| 12:43.37 | d_rossberg | this will save memory |
| 12:44.44 | brlcad | and doing it outside will probably be easier to parallelize ;) |
| 12:45.00 | anrgmrty | umm? |
| 12:45.34 | anrgmrty | ok.. i will try it both ways first.. and make sure it doesnt give errors.. |
| 12:45.43 | anrgmrty | sorry about that.. :-/ |
| 12:47.20 | d_rossberg | brlcad: from my own experience: with a large model and small voxels i run into memory problems |
| 12:48.41 | d_rossberg | anrgmrty: sorry for what? |
| 12:48.42 | brlcad | I could see that with a fixed grid size |
| 12:48.55 | anrgmrty | ohh.. the commit i made led to errors |
| 12:49.38 | anrgmrty | because i had set but unused variables |
| 12:50.32 | brlcad | wasn't trying to convince one way or the other, just that it is generally easier to parallelize work processed in stages/phases |
| 12:50.40 | brlcad | I can easily see a fixed grid blowing out memory |
| 12:51.30 | brlcad | you'd probably need to build up an adaptive structure, akin to a bsp tree |
| 12:52.03 | d_rossberg | anrgmrty: ah, i saw it .. but today isn't my day too: i send an e-mail w/o a subject :( |
| 12:52.11 | brlcad | anrgmrty: the warnings about unused variables are dependent on the version of compiler being used -- as long as you're not ignoring warnings, you're okay |
| 12:52.29 | anrgmrty | d_rossberg: haha.. |
| 12:52.44 | anrgmrty | brlcad: i will keep that in mind.. |
| 12:52.46 | brlcad | more problematic was the code style was off in a couple places |
| 12:53.05 | anrgmrty | that too ,yes.. |
| 12:53.29 | brlcad | if you review the commits that are made to code you're working on, you'll have a good idea what to make sure you fix going forward |
| 12:53.36 | brlcad | so you don't repeat |
| 12:55.26 | anrgmrty | i reviewed the commits on g-voxel.. will ensure it doesnt happen.. |
| 12:57.10 | d_rossberg | because of memory vs. parallel: maybe the should be a first evaluation and memory reduction inside the z and y loops and the final analysis outside these loops |
| 12:58.20 | CIA-55 | BRL-CAD: 03brlcad * r50844 10/brlcad/trunk/src/libpc/CMakeLists.txt: libpc throws compilation warnings when building bundled boost due to undefined symbols in their header fu |
| 13:02.20 | brlcad | if it's functionally broken out to where one of the loops is iterated in its own function, that can be easily parallelized too |
| 13:03.05 | brlcad | main_thread iterates over Z, secondary over all Y(Z) |
| 13:06.27 | anrgmrty | parallelizable i understand(i think).. what exactly do you mean by memory reduction? |
| 13:11.01 | d_rossberg | one structure in the memory vor every voxel vs. holding only the filled voxels in memory (for example in a list) |
| 13:13.47 | anuragmurty | ohh.. this depends on how sparse our object is, right? as in (filled) to (total in bounding box) ratio.. |
| 13:37.19 | CIA-55 | BRL-CAD: 03Plussai 07http://brlcad.org * r3803 10/wiki/User:Plussai/GSoC_2012_log: /* 31 May 2012 */ |
| 13:40.04 | *** part/#brlcad anuragmurty (~anurag@14.139.128.14) |
| 14:14.56 | CIA-55 | BRL-CAD: 03Tbrowder 07http://brlcad.org * r3804 10/wiki/BRL-CAD_Primitives: /* dsp */ reference a tutorial |
| 14:26.09 | starseeker | brlcad: yeah, guess I should - was initially thinking maybe two or three lines would do it, but didn't work out that way |
| 14:28.27 | CIA-55 | BRL-CAD: 03starseeker * r50845 10/brlcad/trunk/regress/CMakeLists.txt: Add outputs from regression to clean list |
| 14:32.18 | brlcad | starseeker: it was only noticable because of the diff -- you replaced the macro with a block of text that was as big as the macro (and nearly identical) ;) |
| 14:32.24 | CIA-55 | BRL-CAD: 03Tbrowder 07http://brlcad.org * r3805 10/wiki/DSP: /* Preparing your height field data */ expand information |
| 14:32.32 | brlcad | then did it again :) |
| 14:33.02 | starseeker | heh. Fixing it now -just need to test |
| 14:34.09 | starseeker | anyhow, looks like you were right - enough C++ passes strict to be worth it |
| 14:39.46 | CIA-55 | BRL-CAD: 03Sean 07http://brlcad.org * r3806 10/wiki/DSP: technically a displacement map |
| 14:41.45 | brlcad | even the few that don't are close to working and should be fixed |
| 15:12.03 | CIA-55 | BRL-CAD: 03r_weiss * r50846 10/brlcad/trunk/src/conv/raw/RegionList.cpp: Update to RegionList.cpp to fix build error. |
| 15:16.41 | CIA-55 | BRL-CAD: 03r_weiss * r50847 10/brlcad/trunk/src/conv/step/PullbackCurve.cpp: Update to PullbackCurve.cpp to quiet build warnings. |
| 15:32.50 | *** join/#brlcad _fkr (el@iceland.sdf.org) |
| 16:07.12 | CIA-55 | BRL-CAD: 03starseeker * r50848 10/brlcad/trunk/misc/CMake/BRLCAD_Targets.cmake: Rework C++ strict logic a bit. |
| 16:11.54 | CIA-55 | BRL-CAD: 03brlcad * r50849 10/brlcad/trunk/src/conv/step/PullbackCurve.cpp: remove dead code instead of commenting it out. revision control preserves what was there. |
| 16:22.05 | CIA-55 | BRL-CAD: 03starseeker * r50850 10/brlcad/trunk/src/conv/step/CMakeLists.txt: step-g is fully C++, not mixed - use the plain NOSTRICT flag |
| 16:31.00 | *** join/#brlcad bhinesle1 (~bhinesley@108.220.113.189) |
| 16:31.00 | *** join/#brlcad _fkr (el@iceland.sdf.org) |
| 16:31.00 | *** join/#brlcad anrgmrty (u6512@gateway/web/irccloud.com/x-syfaefukhgasjgzf) |
| 16:31.00 | *** join/#brlcad cristina (~quassel@unaffiliated/cristina) |
| 16:31.00 | *** join/#brlcad jbschw (~jbschw@ool-4355ee10.dyn.optonline.net) |
| 16:31.00 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 16:31.00 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 16:34.31 | *** join/#brlcad yukonbob (~bch@methodlogic.net) |
| 16:34.35 | yukonbob | hello, #brlcad |
| 16:36.02 | brlcad | howdy yukonbob |
| 16:36.45 | yukonbob | hey brlcad -- another year, another nice GSoC :) |
| 16:37.20 | brlcad | yeah, it's looking pretty good overall |
| 16:37.48 | yukonbob | 11 projects -- busy! |
| 16:37.48 | brlcad | though there are a couple students already in danger of failing, which I supposed is to be expected having accepted a larger group |
| 16:38.29 | yukonbob | nods. Hopefully they learn something regardless... |
| 16:38.35 | yukonbob | lots to be learned here... |
| 16:38.58 | brlcad | yeah, it's unfortunate too seeing them squander such a great opportunity |
| 16:40.02 | yukonbob | well -- w/o knowing their circumstances, "squander" might be harsh -- if they're just lazy or not realizing what's going on here, that's another story.... |
| 16:40.55 | brlcad | they're well aware, just not putting in time and effort, not communicating even to the level they were during applications |
| 16:41.26 | yukonbob | :( |
| 16:41.39 | brlcad | I don't think squander is harsh at all in this circumstance |
| 16:41.57 | yukonbob | you'd know better than I |
| 16:42.07 | brlcad | gsoc is highly competitive, they were selected among thousands of students trying to get accepted |
| 16:42.45 | yukonbob | I guess that's a big shame too -- somebody else was denied to reserve space for somebody who (apparently) doesn't really give a damn. |
| 16:42.59 | brlcad | ah well, sometimes it's a hard lesson |
| 16:43.11 | _fkr | Perhaps some of them feel depressed and that shows in lack of communication. |
| 16:43.13 | yukonbob | how're things going otherwise? |
| 16:43.24 | brlcad | otherwise, busy as usual :) |
| 16:43.44 | brlcad | just about finished reviewing a couple thousand commits so we can get back on release schedule |
| 16:43.48 | yukonbob | still living on 4h of sleep/day and full time coding/fitness? |
| 16:43.59 | brlcad | of course, what else is there? |
| 16:44.06 | yukonbob | :) |
| 16:44.12 | _fkr | I see a list of available display managers in my build as X and Tk. What about the Null DM? Would I need to add some compile time options? |
| 16:44.12 | brlcad | oh right, food :) |
| 16:44.27 | yukonbob | brlcad :) |
| 16:44.34 | brlcad | _fkr: null is the one dm that cannot be disabled, it's always there |
| 16:44.44 | brlcad | you don't want to disable it anyways |
| 16:44.56 | _fkr | what about members of the opposite sex? Who needs them, when you have a nice warm keyboard to touch, eh? |
| 16:44.57 | brlcad | tk can/should be disabled, though, unless you plan on working on developing it |
| 16:45.45 | _fkr | I tried 'mged -a null' but it tends to launch up in X... not sure if it should be like that. |
| 16:45.45 | brlcad | I think those fit under "fitness" .. physical, mental, familiar, social fitness |
| 16:45.46 | yukonbob | _fkr: they are welcome to commit to BRL-CAD too |
| 16:46.00 | brlcad | mged -c |
| 16:46.05 | brlcad | "nu" |
| 16:46.15 | _fkr | I dont want to disable null, wanted to test it instead. |
| 16:47.03 | brlcad | it's effectively the absense of a display manager, so it's accessed under the -c console/command interface |
| 16:47.04 | _fkr | thank you, that looks nice |
| 16:47.41 | brlcad | "attach X" if you want one from console mode |
| 16:47.59 | brlcad | that's all old-school stuff |
| 16:48.19 | _fkr | yeah, was just testing the release and attach and started wondering about the null DM. |
| 16:48.28 | _fkr | Well, old-school is nice sometimes... |
| 16:51.09 | _fkr | although that "nu" sounds more like "new" - nu-school |
| 16:51.46 | CIA-55 | BRL-CAD: 03Phoenix 07http://brlcad.org * r3807 10/wiki/User:Phoenix/GSoc2012/Reports: /* Week 3 */ |
| 17:44.53 | *** join/#brlcad ksuzee (~ksu@193.151.107.42) |
| 18:07.45 | brlcad | hi ksuzee |
| 18:12.43 | ksuzee | brlcad: hello, Sean |
| 18:14.28 | *** join/#brlcad cristina (~quassel@188.24.64.37) |
| 18:14.41 | *** join/#brlcad cristina (~quassel@unaffiliated/cristina) |
| 18:15.33 | CIA-55 | BRL-CAD: 03brlcad * r50851 10/brlcad/trunk/src/libged/preview.c: add a readme about the static array that should become dynamic memory |
| 18:17.09 | CIA-55 | BRL-CAD: 03brlcad * r50852 10/brlcad/trunk/src/conv/CMakeLists.txt: library ordering wrong, libtclcad is the highest-level lib so should be listed first |
| 18:36.05 | CIA-55 | BRL-CAD: 03brlcad * r50853 10/brlcad/trunk/NEWS: bob fixed a bug in the edcodes command in r48741 where argc was being incremented without changing av. overread detected by coverity. would have made it hard to get help and probably caused memory corruption. |
| 19:04.40 | CIA-55 | BRL-CAD: 03brlcad * r50854 10/brlcad/trunk/ (NEWS src/libwdb/wdb.c): |
| 19:04.40 | CIA-55 | BRL-CAD: fix a 7+ year old bug making 32-bit and 64-bit binary uniform data objects |
| 19:04.40 | CIA-55 | BRL-CAD: (binunif). they were getting stored as 16-bit and 32-bit respectively. |
| 19:04.40 | CIA-55 | BRL-CAD: coverity noticed the unreachable 128-bit condition, but the 'fix' in r48823 |
| 19:04.40 | CIA-55 | BRL-CAD: didn't catch the underlying bit-offset error in the switch statement. |
| 19:04.41 | CIA-55 | BRL-CAD: commenting out the 128-bit case merely masked the problem further. fortunately, |
| 19:04.42 | CIA-55 | BRL-CAD: dsp binunif and byte files (the two common use cases) are unaffected. |
| 19:32.05 | CIA-55 | BRL-CAD: 03brlcad * r50855 10/brlcad/trunk/src/ (libged/gqa.c rt/viewweight.c): leave a note about rtweight's density file 32k index limitation that browder noted in r48837. also worth noting that gqa overcomes that limitation (but could also use some reuse improvements. |
| 19:53.46 | CIA-55 | BRL-CAD: 03brlcad * r50856 10/brlcad/trunk/src/rt/viewweight.c: caps implies const, so convert to lower |
| 19:54.04 | yukonbob | some might get kick out of this if not already familiar: http://www.youtube.com/watch?v=z7q5DLS1rAU&ob=av2n |
| 19:54.21 | yukonbob | (REM music vid. w/ nice wireframe gfx) |
| 19:57.52 | CIA-55 | BRL-CAD: 03brlcad * r50857 10/brlcad/trunk/NEWS: (log message trimmed) |
| 19:57.53 | CIA-55 | BRL-CAD: minor rewording. tom fixed rtweight to handle blanks, comment lines, malformed |
| 19:57.53 | CIA-55 | BRL-CAD: lines, and the modified NIST materials file; problem was fscanf stops scanning |
| 19:57.53 | CIA-55 | BRL-CAD: on input at first error and thus the infinite loop: using fgets forces each line |
| 19:57.53 | CIA-55 | BRL-CAD: to be read; an extra buffer is needed in that case to handle the line input |
| 19:57.53 | CIA-55 | BRL-CAD: versus the sscan buffer for reading tokens (but I didn't try using the same |
| 19:57.53 | CIA-55 | BRL-CAD: buffer for both). he also improved rtweight behavior on windows by converting |
| 20:02.54 | CIA-55 | BRL-CAD: 03brlcad * r50858 10/brlcad/trunk/doc/docbook/README: we don't have any hungarian docs. the hy translation is armenian. |
| 20:04.18 | _fkr | What are GLX and PEX display managers? Some experiment that is in very early stages? |
| 20:12.29 | brlcad | _fkr: glx is the system for opengl on x11 |
| 20:12.35 | brlcad | not sure where you got pex from |
| 20:12.54 | brlcad | our 'ogl' display manager uses glx on linux |
| 20:15.44 | _fkr | src/mged/attach.c:96 Has a declaration for Pex_dm_init(), which is #ifdef DM_PEX, that's all I found about it at the moment. Perhaps it's a project that never quite started... |
| 20:16.05 | _fkr | 7.20.6 sources, not current |
| 20:17.32 | CIA-55 | BRL-CAD: 03brlcad * r50859 10/brlcad/trunk/HACKING: doc/docbook also has a readme |
| 20:37.25 | CIA-55 | BRL-CAD: 03Stattrav 07http://brlcad.org * r3808 10/wiki/User:Stattrav/GSoC2012_log: Updation of the logs. |
| 20:51.56 | starseeker | brlcad: ah ha. librt C++ strict fails when release flags are added |
| 20:53.25 | starseeker | http://pastebin.mozilla.org/1655501 |
| 21:00.08 | brlcad | starseeker: that looks like a bonefide concern |
| 21:01.00 | brlcad | perfect example why it's good to not ignore warnings |
| 21:01.28 | brlcad | it's basically saying there's something wrong with brep/nurbs subdivision spatial partitioning |
| 21:03.16 | brlcad | the BANode is marked as inline, but it cannot do the inline because it makes the compilation unit much bigger than is normally expected |
| 21:05.06 | brlcad | so either the class composition is wrong or pulling in data that it shouldn't (C++ inheritance/code problem) or it really is bloating the class that much |
| 21:05.18 | brlcad | either way, we're getting slowed spatial partitioning performance and that's what it's warning about |
| 21:05.52 | _fkr | Is it a bit hard to debug C++? |
| 21:06.34 | CIA-55 | BRL-CAD: 03starseeker * r50860 10/brlcad/trunk/regress/solids.sh: Try an alternative means of feeding the mged scripts - cat+sh doesn't mix well with the odd pathnames regression test. |
| 21:08.21 | CIA-55 | BRL-CAD: 03starseeker * r50861 10/brlcad/trunk/regress/Makefile.am: Update regress Makefile.am clean list |
| 21:08.41 | brlcad | _fkr: hard is relative, but not usually any harder than any other compiled code being fed to a debugger |
| 21:10.14 | CIA-55 | BRL-CAD: 03starseeker * r50862 10/brlcad/trunk/src/librt/CMakeLists.txt: Add NOSTRICTCXX to librt for the moment - getting a warning when compiled with optimization flags |
| 21:10.16 | brlcad | starseeker: someone needs to look at BANode to see why inlining a BANode<ON_BoundingBox>::addChild() would bloat more than 50% |
| 21:12.45 | starseeker | um. Is the new in opennurbs_ext.h:305 the problem? |
| 21:13.09 | _fkr | http://yosefk.com/c++fqa/fqa.html <-- C++ Frequently Questioned Answers. |
| 21:15.44 | CIA-55 | BRL-CAD: 03brlcad * r50863 10/brlcad/trunk/TODO: release issue, brep spatial partitioning sadness |
| 21:17.13 | _fkr | "Second, when it doesn't compile, the error messages are frequently incomprehensible (the smallest error which a human reader wouldn't notice completely confuses the compiler). And three, parsing C++ right is very hard, so different compilers will interpret it differently, and tools like debuggers and IDEs periodically get awfully confused." - Just a quote from the aforementioned doc. Anyways, time to rest for me. |
| 21:18.17 | brlcad | starseeker: could be, but then that line is already suspect for other reasons -- making a copy of the passed reference seems like a slow way to fill in a tree... |
| 21:20.43 | brlcad | _fkr: that's not really relevant -- anecdotal bitching with unqualified hyperbole |
| 21:23.28 | _fkr | Yeah, it was meant for entertainment purposes and it's not a help with dealing with the current problem you are discussing. |
| 21:23.29 | brlcad | that exact same snippet subjectively applies IDENTICALLY to any compiled language |
| 21:24.13 | brlcad | depending on the dev/author/reader, you can get complete agreement or disagreement and everything in between |
| 21:24.21 | _fkr | Sure, there's no absolute truth in this universe... probably. |
| 21:25.27 | brlcad | starseeker: who wrote BANode? |
| 21:25.37 | brlcad | predominantly |
| 21:25.43 | brlcad | jason? |
| 21:25.48 | starseeker | indianlarry, but I believe it was based on earlier BVNode work by jason |
| 21:26.30 | starseeker | re-thinking the tree setup was what initially prompted that earlier discussion on map/hash/STL storage containers |
| 21:28.10 | brlcad | usage of stl there is fine, it's a vector which is suboptimal for large vector sizes, but the time is going to be dominated by that call to new |
| 21:28.15 | brlcad | and the copy |
| 21:28.35 | brlcad | i'd look into seeing if a pointer couldn't be passed instead and just stashed as-is |
| 21:35.39 | brlcad | starseeker: cat+sh would have worked just fine if $TGM were quoted during the cat invocation, just fyi |
| 21:35.54 | brlcad | modified version is better anyways |
| 21:37.47 | starseeker | brlcad: was actually discussing the tree stuff with Keith earlier - he thinks it could be slimmed down quite a bit |
| 21:48.29 | brlcad | of course it can ... :) |
| 21:50.27 | brlcad | there's never been the least bit of doubt about that, just someone actually spending the time |
| 21:52.48 | brlcad | thinks we'd actually fix twice as many issues if we fixed them instead of all the dancing around the issue that is sometimes done, talking about it, ignoring the issues |
| 21:53.50 | brlcad | writing todo or fixmes and playing a blind eye instead of just doing the right fix then and there when the problem is discovered |
| 21:54.02 | brlcad | is just as guilty as the rest, admittedly |
| 21:55.45 | _fkr | Word... |
| 21:59.45 | CIA-55 | BRL-CAD: 03brlcad * r50864 10/brlcad/trunk/NEWS: erik fixed a crash from icv_image when writing to a file failed. (rewording r48211) |
| 22:00.39 | _fkr | Even better is to try to do it in an appropriate manner from the start. Measure 9 times and cut one time. That of course takes more time and then perhaps nothing gets done. Sometimes getting something on the table quickly might be the way to start. How to find the balance? But if a problem has already arised then it's the question whether to try to hack quickly something up to reduce the leakage, so to say, or to just do it all over again. |
| 22:01.12 | _fkr | find a diff approach, diff design. |
| 22:06.12 | _fkr | Problems give bread to engineers who find solutions... Having the right problem solving attitude and engineer's way of thinking helps to crush the problems more effectively. |
| 22:09.52 | brlcad | _fkr: so do you plan to get involved in coding, or are you working on a self-help book for coders or something? :) |
| 22:13.31 | _fkr | hehe, good question. I would of course like to get more in to coding, if I have time and so on. I like to learn and I do not know much, but I just need to see what I am able to do besides real life and so on. Not too much time to sit behind keyboard usually. Yeah, the self-help book question is good too. Not specifically working on it, but I might like to get a bit philosophical at times. |
| 22:14.03 | _fkr | Seen a bit of real-life problem solving too, which is not related to coding, but is nevertheless useful in various engineering disciplines. |
| 22:14.48 | _fkr | I like computers and would love to be more involved. Just need to see, how things go... |
| 22:17.10 | _fkr | Are my comments too off-topic? That's why you make a joke about the book and not getting involved in real thing and so on? It's just something that people know already and doesnt help too much? |
| 22:18.43 | _fkr | Anyways, I'll see, what I can do... |
| 22:32.25 | kanzure | brlcad: hilarious |
| 23:46.28 | cristina | brlcad: I've added a cmake check in order to find the system-installed version of libavoid. If it doesn't find it, it prints a status message saying it couldn't find it - no error occurs in either cases. Should I commit this or leave it local as I am the only person that needs it so far? |
| 23:50.31 | CIA-55 | BRL-CAD: 03Cprecup 07http://brlcad.org * r3809 10/wiki/User:Cprecup/GSoC2012_progress: 04/06/2012: cmake check for system-installed libavoid |