IRC log for #brlcad on 20130728

05:28.24brlcadk
05:58.37Notify03BRL-CAD:brlcad * 56274 (brlcad/trunk/src/burst/burst.c brlcad/trunk/src/burst/extern.h and 4 others): address an ancient FIXME about supporting the plotting of both lines and points. total fast-hack method via global but matches the existing code well.
06:00.09Notify03BRL-CAD:brlcad * 56275 brlcad/trunk/NEWS: added -p/-P plot options to the burst command while fixing an old FIXME.
06:08.21Notify03BRL-CAD:brlcad * 56276 brlcad/trunk/src/conv/step/STEPWrapper.cpp: these look useful, but need some indication to keep them
06:10.17Notify03BRL-CAD:brlcad * 56277 (brlcad/trunk/src/conv/asc/asc2dsp.c brlcad/trunk/src/conv/g-vrml.c): eliminate dead code
06:10.49Notify03BRL-CAD:brlcad * 56278 brlcad/trunk/src/external/ProEngineer/proe-brl.c: we're not buying the module
06:17.19Notify03BRL-CAD:brlcad * 56279 brlcad/trunk/src/external/Unigraphics/ug-g.c: kill lots of dead code that isn't doing anything for us.
06:17.29Notify03BRL-CAD:brlcad * 56280 brlcad/trunk/src/libbrep/libbrep_brep_tools.h: convert the dead block to a comment
06:19.47Notify03BRL-CAD:brlcad * 56281 (brlcad/trunk/src/libdm/dm-ogl.c brlcad/trunk/src/libdm/dm-rtgl.c brlcad/trunk/src/libdm/dm-wgl.c): comment insufficient to retain. how does a glFinish() help testing? poof.
10:07.00Notify03BRL-CAD:phoenixyjll * 56282 brlcad/trunk/src/libbrep/intersect.cpp: Remove debug messages.
11:59.07*** join/#brlcad zero_level (~mohit@66-118-151-70.static.sagonet.net)
12:05.32Notify03BRL-CAD Wiki:Phoenix * 5853 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 6 */
12:09.10Notify03BRL-CAD Wiki:Phoenix * 5854 /wiki/User:Phoenix/GSoc2013/Reports: /* Test Results */
12:09.33Notify03BRL-CAD Wiki:Phoenix * 0 /wiki/File:Five_rec.png:
12:09.51Notify03BRL-CAD Wiki:Phoenix * 5856 /wiki/User:Phoenix/GSoc2013/Reports: /* Test Results */
12:10.40Notify03BRL-CAD Wiki:Phoenix * 5857 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 7 */
14:08.14*** join/#brlcad Ch3ck (~Ch3ck@195.24.220.16)
14:28.28Notify03BRL-CAD Wiki:Vladbogolin * 5858 /wiki/User:Vladbogolin/GSoC2013/Logs:
14:30.29*** join/#brlcad kesha (~kesha@49.249.9.72)
14:37.45Notify03BRL-CAD:brlcad * 56283 brlcad/trunk/src/libdm/labels.c: remove dead code, can revisit later if/when this gets pushed up into the primitives
15:14.41Notify03BRL-CAD:brlcad * 56284 brlcad/trunk/src/libfb/if_wgl.c: remove inactive code, hasn't been active since the original winport merge
15:24.39*** join/#brlcad kesha__ (~kesha@49.249.19.104)
15:30.39Notify03BRL-CAD:brlcad * 56285 brlcad/trunk/src/libfb/if_ogl.c: inactive code for far too long, need a general interface for forking
15:39.02Notify03BRL-CAD:brlcad * 56286 brlcad/trunk/src/libfb/if_X24.c: get rid of the old debug printing code, poor dev substitute for a debugger
15:41.34starseekerCh3ck: your push patches are rather large - I've started looking at them, but it will take time
15:41.54starseekeris there any way you can "break them up" into smaller incremental changes?
15:41.54Ch3ckI don't understand what you mean by large!
15:42.14Ch3ckwell thats the new push and xpush routine combined
15:42.22Ch3cki don't see how i could break it up..
15:42.29Ch3cksince its a single file actually.
15:43.02starseekerbrlcad: any thoughts on how the push/xpush patches might be made more "incremental"?
15:44.10starseekerCh3ck: one issue with the "pull" command patch seems to be that the pull command doens't work yet?
15:44.11Ch3ckand everything in the file needs to be there for the routine to work.. push -x
15:44.23Ch3ckwell i'm still working the code
15:44.57Ch3ckstarseeker: The pull routine is still underdevelopment. So I wanted to stub the routine into the software while continuing development.
15:45.28starseekerCh3ck: bear in mind, you were supposed to have created smaller patches early in the process that would have let you get commit access
15:45.32starseekerthis is why
15:46.25Ch3ckstarseeker: well looking at the way i wanted to combine them. Everything in that file needs to be there for push -x to work properly.
15:46.44Ch3ckI don't see how i can break a file into smaller bits.
15:46.53starseekerI would suggest shifting gears for a moment and making some smaller patches on a different topic then
15:47.06starseekermake some unit test patches for some of the libbn functions
15:47.41starseekersomething that is small, self contained, adds net benefit to the code base, and can be easily reviewed
15:48.01Ch3ckstarseeker: first of all does my patch apply?
15:48.19starseekerCh3ck: don't worry about that right now - your first priority is to get commit access
15:48.32starseekerthese patches are going to be very difficult to review for that purpose
15:49.28Ch3ckstarseeker: well in that case look at my smaller patch which changes the bn_mat_inverse and bn_mat_determinant routines
15:49.40starseekerCh3ck: Sean is reviewing that
15:49.46Ch3ckok
15:49.49starseekerthat's exactly the right idea
15:50.27Ch3ckso before any review of the patches I want to first of all know whether there are any of the patches that don't apply cleanly since Sean made some emphasis on that?
15:50.39Notify03BRL-CAD:brlcad * 56287 brlcad/trunk/src/libgcv/bottess.c: eliminating the dead code uncovers dead functions too, get rid of the mess
15:51.10Ch3ckbefore waiting for the reviews..
15:52.47starseekerdon't wait for the reviews.  That's why I'm saying you need to take the time to do some smaller, easily reviewed patches to work towards commit access.  the bn_mat_inverse patch is a step in the right direction - do more patches like that
15:53.04Ch3ckok
15:53.33starseekeryou're trying to skip the "get commit access" step and go straight to the pull/push work - that's a mistake
15:53.57Notify03BRL-CAD:brlcad * 56288 brlcad/trunk/src/libgcv/wfobj/obj_grammar.yy: more string debugging removal
15:54.10starseekertesting and improving libbn is an *excellent* place to start
15:54.25Ch3ckstarseeker: So I should write some performance tests on the libbn routines? or should I test some of the libbn routines and do some improvements?
15:54.31Ch3ckok
15:54.50starseekerlook at the unit tests in the src/libbu/tests and src/libbn/tests directories
15:55.00Ch3ckok
15:55.23starseekersee how they test specific pieces of functionality in isolation - making sure it works with standard and difficult cases, and then hooking that into the build system's test framework
15:55.53starseekerbecause those tests are self contained, they are a good way to make stand-alone, easy to review patches
15:56.58starseekerthe tests don't *change* the existing libbn routines, which is another factor - they don't run the risk of breaking existing functionality
15:57.17Ch3ckaight. will do so what about debugging my pull routine? or continuing the work of my GsoC proj?
15:57.42starseekeryour first priority is to get commit access
15:57.47Ch3ckok
15:57.55starseekeronce you do so, continuting the pull work will be *much* easier
15:58.31Ch3ckBut this is what I would have been told earlier about keeping aside the push/xpush work
15:58.47starseekersorry?
15:58.53starseekerI don't follow
15:58.55Ch3ckany ways. will get on that tomorrow..
15:59.27Ch3ckI had told Sean about my work on push/xpush earlier long before GSoC started and its also written on my logs.
15:59.56starseekerCh3ck: that's fine, but remember what the general instructions to all GSoC students where
16:00.02Notify03BRL-CAD:brlcad * 56289 brlcad/trunk/src/libged/analyze.c: yes, incorrect analyze code is worse than no analyze code. remove rhc.
16:00.02starseekers/where/were
16:00.18Ch3ckabout my progress on combining both routines which I believe its related to my proj.
16:00.50Ch3ckI was thinking if I combined both routines well it'll just give me commit access.
16:01.24starseekerCh3ck: the problem is those are both complex commands with a lot of logic, and any mistake will break important functionality
16:01.34starseekerthey are complex to review and take a fair bit of testing
16:02.03Ch3ckthats why it took me so long to what i've done so far..
16:02.05starseekerfor commit access, you want small, easily reviewed, self-contained patches that are simplier to read and test
16:02.13Ch3ckaight.
16:02.30starseekeryour commit access patches don't necessarily have to relate directly to what you are doing in your main GSoC project
16:03.01starseekerand work on libbn testing, in particular, is *extremely* useful
16:03.38starseekerespecially since understanding those routines can only help you in your main project
16:03.42Ch3ckalright. I'll focus now on testing the libbn routines..
16:04.08Ch3ckdeveloping easy-to-review patches so i can get this commit access.
16:04.17starseekerexcellent
16:05.49Ch3ckOk since i started looking at the /src/mat.c routines. will continue from there
16:05.54starseekersounds good
16:06.03Ch3ckbefore moving on to other files in libbn.
16:06.33starseekerCh3ck: if it makes it easier, you can thing of this as making sure you have a firm foundation numerically in libbn before continuing with the pull work
16:06.50Ch3ckalright I see
16:07.00starseekerbugs in lower level APIs that interfere with the correct working of higher level APIs are just evil to figure out
16:07.47starseekerand end users are extremely skilled at finding that one special case nobody thought to handle
16:07.51Ch3ckyeah push/xpush taught me that.. ;)
16:09.38Notify03BRL-CAD:brlcad * 56290 brlcad/trunk/src/libged/analyze.c: just rename them, avoid the preprocessor issue altogether
16:13.03*** join/#brlcad vladbogo (~vlad@188.25.238.209)
16:16.30Notify03BRL-CAD:brlcad * 56291 brlcad/trunk/src/libged/analyze.c: FIXED, tom made bu_vls_printf() teh awesome. now can avoid using sprintf for complex table printing.
16:20.36Notify03BRL-CAD:brlcad * 56292 brlcad/trunk/src/libged/bev.c: not yet supported, not yet an option
16:28.09Notify03BRL-CAD:brlcad * 56293 brlcad/trunk/src/libged/bot_dump.c: remove material section that hasn't been used
16:50.15Notify03BRL-CAD:brlcad * 56294 brlcad/trunk/src/libged/edpipe.c: re-enable the debug messages, but go through bu_log intead of Tcl_AppendResult
16:54.46Notify03BRL-CAD:brlcad * 56295 brlcad/trunk/src/libged/edit.c: remove the BU_ASSERT() that are in dead code blocks. seem flaky logic to base an abort on.
17:00.57Notify03BRL-CAD:brlcad * 56296 (brlcad/trunk/src/libged/human.c brlcad/trunk/src/libged/inside.c): more dead code elimination
17:01.21*** join/#brlcad zero_level (~mohit@66-118-151-70.static.sagonet.net)
17:02.12*** join/#brlcad zero_level (~mohit@66-118-151-70.static.sagonet.net)
17:03.14*** join/#brlcad zero_level1 (0e8bf3a2@gateway/web/freenode/ip.14.139.243.162)
17:06.21*** join/#brlcad vladbogo (~vlad@188.25.238.209)
17:38.37*** join/#brlcad zero_level_ (0e8bf3a2@gateway/web/freenode/ip.14.139.243.162)
17:38.50*** part/#brlcad zero_level1 (0e8bf3a2@gateway/web/freenode/ip.14.139.243.162)
17:39.49zero_level_starseeker : Apparently I have found the answers to your 2 interesting questions
17:41.00zero_level_The close image call in do.c is called when i remove the close call from viewedge.c
17:41.42zero_level_But When viewedge.c closes the image in function view_end() do.c doesnt close the image.
17:42.56zero_level_These all testings were done in revision before the current modifications in icv.h
17:43.23zero_level_Thus making it clear. That icv_save_close not needed in viewedge.c
17:43.33zero_level_I ran the following command to test these.
17:44.01zero_level_rtedge -s 1024 -o new.pix brlcad-build/share/db/havoc.g havoc
18:08.48Notify03BRL-CAD:tbrowder2 * 56297 brlcad/trunk/doc/docbook/system/man1/en/fbserv.xml: document the '-v' option
20:11.12Notify03BRL-CAD Wiki:Vladbogolin * 5859 /wiki/User:Vladbogolin/GSoC2013/Logs: /* Week 6 */
20:11.51Notify03BRL-CAD Wiki:Vladbogolin * 5860 /wiki/User:Vladbogolin/GSoC2013/Logs:
20:12.39Notify03BRL-CAD Wiki:Vladbogolin * 5861 /wiki/User:Vladbogolin/GSoC2013/Logs:
22:01.15*** join/#brlcad DarkCalf (~DarkCalf@173.231.40.99)

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