| 05:28.24 | brlcad | k |
| 05:58.37 | Notify | 03BRL-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.09 | Notify | 03BRL-CAD:brlcad * 56275 brlcad/trunk/NEWS: added -p/-P plot options to the burst command while fixing an old FIXME. |
| 06:08.21 | Notify | 03BRL-CAD:brlcad * 56276 brlcad/trunk/src/conv/step/STEPWrapper.cpp: these look useful, but need some indication to keep them |
| 06:10.17 | Notify | 03BRL-CAD:brlcad * 56277 (brlcad/trunk/src/conv/asc/asc2dsp.c brlcad/trunk/src/conv/g-vrml.c): eliminate dead code |
| 06:10.49 | Notify | 03BRL-CAD:brlcad * 56278 brlcad/trunk/src/external/ProEngineer/proe-brl.c: we're not buying the module |
| 06:17.19 | Notify | 03BRL-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.29 | Notify | 03BRL-CAD:brlcad * 56280 brlcad/trunk/src/libbrep/libbrep_brep_tools.h: convert the dead block to a comment |
| 06:19.47 | Notify | 03BRL-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.00 | Notify | 03BRL-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.32 | Notify | 03BRL-CAD Wiki:Phoenix * 5853 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 6 */ |
| 12:09.10 | Notify | 03BRL-CAD Wiki:Phoenix * 5854 /wiki/User:Phoenix/GSoc2013/Reports: /* Test Results */ |
| 12:09.33 | Notify | 03BRL-CAD Wiki:Phoenix * 0 /wiki/File:Five_rec.png: |
| 12:09.51 | Notify | 03BRL-CAD Wiki:Phoenix * 5856 /wiki/User:Phoenix/GSoc2013/Reports: /* Test Results */ |
| 12:10.40 | Notify | 03BRL-CAD Wiki:Phoenix * 5857 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 7 */ |
| 14:08.14 | *** join/#brlcad Ch3ck (~Ch3ck@195.24.220.16) | |
| 14:28.28 | Notify | 03BRL-CAD Wiki:Vladbogolin * 5858 /wiki/User:Vladbogolin/GSoC2013/Logs: |
| 14:30.29 | *** join/#brlcad kesha (~kesha@49.249.9.72) | |
| 14:37.45 | Notify | 03BRL-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.41 | Notify | 03BRL-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.39 | Notify | 03BRL-CAD:brlcad * 56285 brlcad/trunk/src/libfb/if_ogl.c: inactive code for far too long, need a general interface for forking |
| 15:39.02 | Notify | 03BRL-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.34 | starseeker | Ch3ck: your push patches are rather large - I've started looking at them, but it will take time |
| 15:41.54 | starseeker | is there any way you can "break them up" into smaller incremental changes? |
| 15:41.54 | Ch3ck | I don't understand what you mean by large! |
| 15:42.14 | Ch3ck | well thats the new push and xpush routine combined |
| 15:42.22 | Ch3ck | i don't see how i could break it up.. |
| 15:42.29 | Ch3ck | since its a single file actually. |
| 15:43.02 | starseeker | brlcad: any thoughts on how the push/xpush patches might be made more "incremental"? |
| 15:44.10 | starseeker | Ch3ck: one issue with the "pull" command patch seems to be that the pull command doens't work yet? |
| 15:44.11 | Ch3ck | and everything in the file needs to be there for the routine to work.. push -x |
| 15:44.23 | Ch3ck | well i'm still working the code |
| 15:44.57 | Ch3ck | starseeker: The pull routine is still underdevelopment. So I wanted to stub the routine into the software while continuing development. |
| 15:45.28 | starseeker | Ch3ck: 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.32 | starseeker | this is why |
| 15:46.25 | Ch3ck | starseeker: 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.44 | Ch3ck | I don't see how i can break a file into smaller bits. |
| 15:46.53 | starseeker | I would suggest shifting gears for a moment and making some smaller patches on a different topic then |
| 15:47.06 | starseeker | make some unit test patches for some of the libbn functions |
| 15:47.41 | starseeker | something that is small, self contained, adds net benefit to the code base, and can be easily reviewed |
| 15:48.01 | Ch3ck | starseeker: first of all does my patch apply? |
| 15:48.19 | starseeker | Ch3ck: don't worry about that right now - your first priority is to get commit access |
| 15:48.32 | starseeker | these patches are going to be very difficult to review for that purpose |
| 15:49.28 | Ch3ck | starseeker: well in that case look at my smaller patch which changes the bn_mat_inverse and bn_mat_determinant routines |
| 15:49.40 | starseeker | Ch3ck: Sean is reviewing that |
| 15:49.46 | Ch3ck | ok |
| 15:49.49 | starseeker | that's exactly the right idea |
| 15:50.27 | Ch3ck | so 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.39 | Notify | 03BRL-CAD:brlcad * 56287 brlcad/trunk/src/libgcv/bottess.c: eliminating the dead code uncovers dead functions too, get rid of the mess |
| 15:51.10 | Ch3ck | before waiting for the reviews.. |
| 15:52.47 | starseeker | don'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.04 | Ch3ck | ok |
| 15:53.33 | starseeker | you're trying to skip the "get commit access" step and go straight to the pull/push work - that's a mistake |
| 15:53.57 | Notify | 03BRL-CAD:brlcad * 56288 brlcad/trunk/src/libgcv/wfobj/obj_grammar.yy: more string debugging removal |
| 15:54.10 | starseeker | testing and improving libbn is an *excellent* place to start |
| 15:54.25 | Ch3ck | starseeker: 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.31 | Ch3ck | ok |
| 15:54.50 | starseeker | look at the unit tests in the src/libbu/tests and src/libbn/tests directories |
| 15:55.00 | Ch3ck | ok |
| 15:55.23 | starseeker | see 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.53 | starseeker | because those tests are self contained, they are a good way to make stand-alone, easy to review patches |
| 15:56.58 | starseeker | the tests don't *change* the existing libbn routines, which is another factor - they don't run the risk of breaking existing functionality |
| 15:57.17 | Ch3ck | aight. will do so what about debugging my pull routine? or continuing the work of my GsoC proj? |
| 15:57.42 | starseeker | your first priority is to get commit access |
| 15:57.47 | Ch3ck | ok |
| 15:57.55 | starseeker | once you do so, continuting the pull work will be *much* easier |
| 15:58.31 | Ch3ck | But this is what I would have been told earlier about keeping aside the push/xpush work |
| 15:58.47 | starseeker | sorry? |
| 15:58.53 | starseeker | I don't follow |
| 15:58.55 | Ch3ck | any ways. will get on that tomorrow.. |
| 15:59.27 | Ch3ck | I had told Sean about my work on push/xpush earlier long before GSoC started and its also written on my logs. |
| 15:59.56 | starseeker | Ch3ck: that's fine, but remember what the general instructions to all GSoC students where |
| 16:00.02 | Notify | 03BRL-CAD:brlcad * 56289 brlcad/trunk/src/libged/analyze.c: yes, incorrect analyze code is worse than no analyze code. remove rhc. |
| 16:00.02 | starseeker | s/where/were |
| 16:00.18 | Ch3ck | about my progress on combining both routines which I believe its related to my proj. |
| 16:00.50 | Ch3ck | I was thinking if I combined both routines well it'll just give me commit access. |
| 16:01.24 | starseeker | Ch3ck: the problem is those are both complex commands with a lot of logic, and any mistake will break important functionality |
| 16:01.34 | starseeker | they are complex to review and take a fair bit of testing |
| 16:02.03 | Ch3ck | thats why it took me so long to what i've done so far.. |
| 16:02.05 | starseeker | for commit access, you want small, easily reviewed, self-contained patches that are simplier to read and test |
| 16:02.13 | Ch3ck | aight. |
| 16:02.30 | starseeker | your commit access patches don't necessarily have to relate directly to what you are doing in your main GSoC project |
| 16:03.01 | starseeker | and work on libbn testing, in particular, is *extremely* useful |
| 16:03.38 | starseeker | especially since understanding those routines can only help you in your main project |
| 16:03.42 | Ch3ck | alright. I'll focus now on testing the libbn routines.. |
| 16:04.08 | Ch3ck | developing easy-to-review patches so i can get this commit access. |
| 16:04.17 | starseeker | excellent |
| 16:05.49 | Ch3ck | Ok since i started looking at the /src/mat.c routines. will continue from there |
| 16:05.54 | starseeker | sounds good |
| 16:06.03 | Ch3ck | before moving on to other files in libbn. |
| 16:06.33 | starseeker | Ch3ck: 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.50 | Ch3ck | alright I see |
| 16:07.00 | starseeker | bugs in lower level APIs that interfere with the correct working of higher level APIs are just evil to figure out |
| 16:07.47 | starseeker | and end users are extremely skilled at finding that one special case nobody thought to handle |
| 16:07.51 | Ch3ck | yeah push/xpush taught me that.. ;) |
| 16:09.38 | Notify | 03BRL-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.30 | Notify | 03BRL-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.36 | Notify | 03BRL-CAD:brlcad * 56292 brlcad/trunk/src/libged/bev.c: not yet supported, not yet an option |
| 16:28.09 | Notify | 03BRL-CAD:brlcad * 56293 brlcad/trunk/src/libged/bot_dump.c: remove material section that hasn't been used |
| 16:50.15 | Notify | 03BRL-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.46 | Notify | 03BRL-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.57 | Notify | 03BRL-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.49 | zero_level_ | starseeker : Apparently I have found the answers to your 2 interesting questions |
| 17:41.00 | zero_level_ | The close image call in do.c is called when i remove the close call from viewedge.c |
| 17:41.42 | zero_level_ | But When viewedge.c closes the image in function view_end() do.c doesnt close the image. |
| 17:42.56 | zero_level_ | These all testings were done in revision before the current modifications in icv.h |
| 17:43.23 | zero_level_ | Thus making it clear. That icv_save_close not needed in viewedge.c |
| 17:43.33 | zero_level_ | I ran the following command to test these. |
| 17:44.01 | zero_level_ | rtedge -s 1024 -o new.pix brlcad-build/share/db/havoc.g havoc |
| 18:08.48 | Notify | 03BRL-CAD:tbrowder2 * 56297 brlcad/trunk/doc/docbook/system/man1/en/fbserv.xml: document the '-v' option |
| 20:11.12 | Notify | 03BRL-CAD Wiki:Vladbogolin * 5859 /wiki/User:Vladbogolin/GSoC2013/Logs: /* Week 6 */ |
| 20:11.51 | Notify | 03BRL-CAD Wiki:Vladbogolin * 5860 /wiki/User:Vladbogolin/GSoC2013/Logs: |
| 20:12.39 | Notify | 03BRL-CAD Wiki:Vladbogolin * 5861 /wiki/User:Vladbogolin/GSoC2013/Logs: |
| 22:01.15 | *** join/#brlcad DarkCalf (~DarkCalf@173.231.40.99) | |