| 02:12.33 | brlcad | starseeker: "struct db_full_path" and "union tree" were two that came to mind, also "struct combined_tree_state" and ... maybe most apropriately "struct rt_tree_array" |
| 02:15.27 | brlcad | keeping in mind that adding a void*data pointer to any of them is always a possibility too |
| 02:15.46 | brlcad | for attaching extra data if needed |
| 02:15.57 | brlcad | caen23: "clrs"? |
| 02:17.06 | brlcad | caen23: a python interpreter would be very cool indeed -- my long-term goal is something like gimp's skript-fu interface |
| 02:19.07 | brlcad | starseeker: an array of ints would be very invasive, but a pointer to an array stuffed into a void* would not |
| 02:20.11 | Notify | 03BRL-CAD:starseeker * 56366 (brlcad/trunk/include/raytrace.h brlcad/trunk/src/librt/db_fullpath.c and 2 others): This needs some careful tests - I'm not sure that I'm properly interpreting the meaning of the left/right tree walk for all the boolean cases - but add an array to db_full_path that lets us stash the boolean states all along the tree. The f_bool test can now query based on the current path, which should |
| 02:20.13 | Notify | let options like -above do the right thing. |
| 02:20.54 | starseeker | winces |
| 02:21.06 | starseeker | brlcad: sorry, my chat window was frozen and I didn't notice |
| 02:22.16 | starseeker | brlcad: in some quick testing r56366 seems to work... |
| 02:25.35 | starseeker | I'm definitely not getting something right with the booleans though |
| 02:31.03 | brlcad | starseeker: that's fine |
| 02:31.42 | brlcad | actually doesn't seem incredibly invasive |
| 02:32.14 | brlcad | would be concerned that it valgrinds clean since there is a fair bit of memory bloat involved for a big tree |
| 02:33.33 | starseeker | nods |
| 02:35.20 | Notify | 03BRL-CAD:starseeker * 56367 brlcad/trunk/src/librt/search.c: Ah - need to set the bool node when entering the comb too. |
| 02:35.45 | starseeker | once I'm sure it's behaving search wise I'll try to run it through valgrind |
| 02:36.19 | starseeker | basically looked for everywhere fp_names was getting malloced and freed in db_fullpath.c and had the int array tag along |
| 02:36.36 | starseeker | need to scan the rest of the code to see if anyone else monkeys with it directly |
| 02:36.59 | brlcad | this is why I abhor adding new structs |
| 02:37.13 | brlcad | nobody does the work to encapsulate them properly |
| 02:37.14 | starseeker | hmm? |
| 02:37.32 | brlcad | there shouldn't be a dozen places where fp_names is malloced |
| 02:37.39 | starseeker | ah |
| 02:37.41 | brlcad | should have been one place |
| 02:38.03 | starseeker | well, it does need to realloc in a few cases... |
| 02:39.10 | brlcad | it doesn't "need" to realloc |
| 02:39.18 | brlcad | it needs to grow |
| 02:39.42 | brlcad | or more generically change in size |
| 02:39.50 | brlcad | add/remove methods usually handle that |
| 02:40.00 | starseeker | ah |
| 02:40.08 | brlcad | addfp() |
| 02:40.23 | brlcad | mallocs if needed, reallocs if needed, etc |
| 02:41.07 | starseeker | not too bad on instances of fp_names elsewhere in the code, actually... looks like some places where the DB_FULL_PATH_* macros could stand in for explicit fp_names indexing |
| 02:43.18 | starseeker | doesn't shorten anything though - would just let us (mostly) encapsulate the detail that the directory pointer array is called fp_names |
| 02:43.30 | starseeker | which I guess is a good thing... |
| 03:05.14 | Notify | 03BRL-CAD:starseeker * 56368 brlcad/trunk/src/librt/search.c: valgrind reported lost memory from f_print - oops. |
| 03:12.17 | Notify | 03BRL-CAD:starseeker * 56369 brlcad/trunk/src/libged/search.c: Free bu_basename, like bu.h tells us to |
| 03:20.29 | Notify | 03BRL-CAD:starseeker * 56370 brlcad/trunk/src/libged/search.c: Couple of more memory freeing responsibilities for the search command to live up to. |
| 03:25.21 | Notify | 03BRL-CAD:phoenixyjll * 56371 brlcad/trunk/src/libbrep/intersect.cpp: Eliminate compiler warnings. |
| 03:41.09 | Notify | 03BRL-CAD:brlcad * 56372 brlcad/trunk/NEWS: jon engbert improved g-stl's docs, updating the option listings and descriptions |
| 03:42.36 | Notify | 03BRL-CAD:phoenixyjll * 56373 brlcad/trunk/src/libbrep/intersect.cpp: Take the tolerance into consideration when deciding whether a box is inside the overlap region. |
| 03:51.39 | Notify | 03BRL-CAD:brlcad * 56374 brlcad/trunk/NEWS: jon engbert implemented a new g-raw exporter per specifications and patch review assistance from daniel. implements export support for a 'raw' file format described via GCI task (http://www.google-melange.com/gci/task/view/google/gci2012/7945223) |
| 03:55.26 | *** join/#brlcad caen23 (~caen23@92.81.173.189) |
| 04:03.03 | Notify | 03BRL-CAD:phoenixyjll * 56375 brlcad/trunk/src/libbrep/intersect.cpp: Delete the OverlapSegment when its curves are NULL. |
| 04:06.08 | brlcad | so the benchmark is royally busted at the moment with out-of-order render lines |
| 04:07.09 | brlcad | zero_level: this is undoubtedly releated to your work -- we need to get you testing on parallel hardware or recompiling cleanly |
| 04:08.48 | brlcad | with the semaphore locks removed, scanlines are ending up out of order so have to put some thought into how that is happening and finding a fix, and restoring back to a working state otherwise if a fix is not achieved within a day |
| 04:12.50 | Notify | 03BRL-CAD:brlcad * 56376 brlcad/trunk/CMakeLists.txt: don't silently turn off a user-specified configuration setting. probably should halt (because they requested something impossible). |
| 04:14.09 | brlcad | starseeker: 56219 is undoubtedly user-visible, but what's the impact? |
| 04:14.22 | brlcad | fixed some issue clobbering avs? |
| 04:14.44 | Notify | 03BRL-CAD:phoenixyjll * 56377 brlcad/trunk/src/libbrep/intersect.cpp: Avoid using dynamic memory allocation for the events. |
| 04:15.59 | starseeker | brlcad: that's just part of my thrashing with comb |
| 04:16.33 | starseeker | -c/-r didn't exist for comb previously |
| 04:17.21 | brlcad | what do they do? |
| 04:19.02 | starseeker | -c unsets the region flag on a comb, -r sets it |
| 04:19.15 | brlcad | ugh |
| 04:19.25 | starseeker | same as the 'c' command's flags |
| 04:20.04 | brlcad | yep |
| 04:20.20 | Notify | 03BRL-CAD:brlcad * 56378 brlcad/trunk/NEWS: cliff added the -c/-r options to the comb command like the 'c' command to set/unset the region flag |
| 04:20.24 | brlcad | ughing at the complexity for what is effectively an on/off flag |
| 04:20.33 | starseeker | nods |
| 04:21.02 | brlcad | would expect something like -r/-R to set/unset so it's clear they pair |
| 04:21.36 | brlcad | and more consistent with some other commands |
| 04:21.53 | starseeker | was planning to make a bigger deal out of comb once he figured out how to merge the various related commands into it... |
| 04:22.29 | starseeker | not sure what to do about some of the more subtle bits - for example, comb won't create an empty combination, but I believe c will |
| 04:22.51 | starseeker | should be consistent - either do or don't create it, imho... |
| 04:23.45 | starseeker | comb also silently switches the first boolean operator to a union for a new combination, regardless of what the user supplies |
| 04:24.04 | starseeker | i.e. comb test.c - s1.s u s2.s will result in a union of s1.s and s2.s |
| 04:24.18 | starseeker | just as if the user entered comb test.c u s1.s u s2.s |
| 04:24.54 | starseeker | c, on the other hand, doesn't want that first operator since it's doing the boolean expression evaluation |
| 04:25.09 | starseeker | and c won't update an existing combination, but comb will |
| 04:25.28 | brlcad | so both have issues :) |
| 04:25.32 | brlcad | classic |
| 04:25.36 | starseeker | nods |
| 04:26.17 | starseeker | dunno whether we deprecate behaviors in comb we don't like and deprecate c altogether, adding its features (sans mis-features) to comb or what... |
| 04:27.37 | starseeker | g and r, of course, are just special cases of the more general commands |
| 04:29.20 | starseeker | was planning to discuss that with you when things got quieter (how to approach merging them) |
| 04:34.13 | brlcad | those both are so old that I'd rather migrate them en masse |
| 04:35.47 | brlcad | but yeah, the incremental path would probably be to migrate c's parser over into comb, remove the bad, adding anything else useful, then getting rid of c so it can be an alias or tab-completion shortcut |
| 04:36.01 | brlcad | iirc, c might be the one that also supports parenthetical expressions |
| 04:37.23 | brlcad | need to spend a couple days to audit the existing commands and make sure an end-goal is well thought through from a usability and feature perspective |
| 04:43.26 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 05:05.17 | Notify | 03BRL-CAD:phoenixyjll * 56379 brlcad/trunk/src/libbrep/intersect.cpp: Use build_curve_root() instead of duplicating that routine. |
| 05:16.03 | Notify | 03BRL-CAD:phoenixyjll * 56380 brlcad/trunk/src/libbrep/intersect.cpp: Use sub_curve() instead of repeating that routine. |
| 05:18.55 | zero_level | blcad : was it related to yesterday's commits. |
| 05:18.59 | zero_level | ? |
| 05:21.18 | zero_level | brlcad : |
| 05:21.42 | zero_level | one of the possible solution could be using a different seamapore lock. |
| 05:22.18 | zero_level | has put bz to compile and benchmark. |
| 05:40.06 | *** join/#brlcad KimK (~Kim__@wsip-184-176-200-171.ks.ks.cox.net) |
| 06:12.49 | zero_level | brlcad: here are the logs http://brlcad.org/~mohit/benchmark_result_31_JUL.log |
| 07:28.39 | *** join/#brlcad merzo (~merzo@user-94-45-58-138-1.skif.com.ua) |
| 07:34.44 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) |
| 07:35.08 | *** join/#brlcad Ch3ck_ (~Ch3ck@195.24.220.16) |
| 09:13.41 | Ch3ck_ | brlcad: starseeker: could you please review the unit test patches I've posted on sf. So I could continue writing others while correcting any errors(I doubt if there is any!) that comes up with these! |
| 09:18.15 | *** join/#brlcad caen23 (~caen23@92.81.173.189) |
| 09:27.37 | Notify | 03BRL-CAD:mohitdaga * 56381 brlcad/trunk/src/libicv/fileformat.c: Changed icv_writeline to not allocate memory. Although the functionality remains same. |
| 09:35.44 | Notify | 03BRL-CAD Wiki:Phoenix * 5887 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 7 */ |
| 10:20.35 | *** join/#brlcad Ch3ck_ (~Ch3ck@195.24.220.16) |
| 10:23.59 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 10:42.00 | *** join/#brlcad kamaljeet (~kamaljeet@202.164.53.122) |
| 10:42.00 | *** join/#brlcad jasvir (~jasvir@202.164.53.122) |
| 11:20.08 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b125:3b01:0:1a:d75b:101) |
| 11:44.37 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b12a:408c:0:39:d1b9:e801) |
| 11:56.33 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b12a:408c:0:39:d1b9:e801) |
| 12:07.34 | zero_level | brlcad : I think benchmark ran succcessfully. But still dont have experience reading the problems. |
| 12:07.54 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b12a:408c:0:39:d1b9:e801) |
| 12:16.39 | zero_level | Morover I have changed the function,And it works right. |
| 12:16.56 | zero_level | So It doesnt need to allocate memory. |
| 12:21.51 | zero_level | pls review this benchmark lo : http://brlcad.org/~mohit/benchmark_result_r56381.txt |
| 12:22.22 | zero_level | I tired looking for the bug in this report but didnt see any. |
| 12:23.52 | zero_level | Also we can now use spinlocks. Pls tell me if we need to. (If the benchmark doesnt have issues.) |
| 12:29.29 | brlcad | zero_level: do you have a multiprocessor machine? |
| 12:30.48 | zero_level | i3 4 core. |
| 12:30.57 | zero_level | also bz. ? |
| 12:31.56 | brlcad | i'll try again after r56381, but the issue was a classic smp race issue |
| 12:32.45 | zero_level | although if the issue u saw earlier, Then It must also be an an issue now. |
| 12:32.55 | brlcad | if an SMP machine happens to keep things in order, you could just be getting lucky |
| 12:33.07 | zero_level | lucky :-) |
| 12:33.21 | brlcad | and you'll repeatedly get lucky, so you need a different environment |
| 12:33.27 | brlcad | are you compiling optimized? |
| 12:34.00 | brlcad | make sure you're optimized, perhaps try running two benchmarks simultanously |
| 12:34.06 | zero_level | do we add a flag ? |
| 12:34.11 | brlcad | yes |
| 12:34.21 | brlcad | see INSTALL |
| 12:34.25 | zero_level | looks at INSTALL |
| 12:34.40 | brlcad | that could be the difference |
| 12:41.48 | Notify | 03BRL-CAD Wiki:KeshaSShah * 5888 /wiki/User:KeshaSShah/GSoC13/Reports: /* Week 7 */ |
| 12:42.46 | zero_level | zero_level has put a fresh build on bz for benchmark test. |
| 12:46.55 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b12a:408c:0:39:d1b9:e801) |
| 12:54.39 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 13:06.26 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b12a:408c:0:39:d1b9:e801) |
| 13:06.31 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 13:15.42 | Ch3ck_ | brlcad: working on a unit test for bn_poly_division_routine() while trying an extreme case division against zero. Its not really clear with the source code. I'll like to know how the routine handles division by zero, what becomes of the quotient and remainder polynomials. Kinda stuck here |
| 13:19.30 | ``Erik | div/0 is an error and should return NaN... |
| 13:20.53 | ``Erik | which func are you actually testing? poly.c bn_poly_synthetic_division() ? |
| 13:22.32 | Ch3ck_ | ``Erik: yes bn_poly_synthetic_division |
| 13:23.03 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 13:24.39 | Ch3ck_ | so the remainder and quotient actually become NAN? or its rem->cf == NAN? |
| 13:24.58 | Ch3ck_ | I want to clearly get it |
| 13:26.34 | Ch3ck_ | so as to be able to generate correct input from know values needed for the test |
| 13:28.48 | zero_level | brlcad : I am still not sure why spinlock issue is arising after all. |
| 13:29.04 | zero_level | ``Erik, brlcad : |
| 13:29.25 | zero_level | A) We allocate the complete memory in icv_ceate_image(..) |
| 13:30.13 | zero_level | B) We do have an arg in icv_image_writeline(...) which takes care of the index. |
| 13:30.29 | zero_level | *icv_writeline (modified now) |
| 13:32.22 | zero_level | brlcad,``Erik : Why after all do we have an issue of resource race. |
| 13:32.54 | *** join/#brlcad kimz (~AndChat56@14.139.122.114) |
| 13:32.56 | zero_level | because Its technically a different resource. That is different memory chunck in the same buffer. |
| 13:33.49 | zero_level | brlcad : Can u send me the log Report which showed error. So That I can get the number of pixels which are not same. |
| 13:33.59 | zero_level | after the pixclump result. |
| 13:34.35 | zero_level | In the meanwhile /me saw |
| 13:34.50 | zero_level | the benchmark screen. |
| 13:35.33 | zero_level | The answers are right for moss.pix, world.pix (all other results are running) |
| 13:40.37 | Notify | 03BRL-CAD:starseeker * 56382 brlcad/trunk/doc/docbook/system/mann/en/search.xml: typo |
| 13:42.47 | *** join/#brlcad caen23 (~caen23@92.81.173.189) |
| 13:44.29 | zero_level | brlcad.org/benchmark_result_r56381_optimized.txt |
| 13:44.50 | zero_level | brlcad : log file for the benchmark result after optimized. |
| 13:45.02 | zero_level | Do you still think i must move to a new hardware ? |
| 13:47.24 | zero_level | ``Erik : Please run benchmark on a window on your machine. |
| 13:47.52 | zero_level | I will move to my friend's place to see if benchmark results are fine on his machine. |
| 13:49.40 | zero_level | oops wrong link brlcad.org/~mohit/brlcad.org/benchmark_result_r56381_optimized.txt |
| 13:49.54 | zero_level | brlcad.org/~mohit/brlcad.org/benchmark_result_r56381_optimized.txt |
| 13:50.01 | zero_level | oops.. |
| 13:50.33 | zero_level | the correct one http://brlcad.org/~mohit/benchmark_result_r56381_optimized.txt |
| 14:00.53 | brlcad | zero_level: the report will say WRONG WRONG WRONG with lots of values off-by-many (because entire scanlines are out of order) |
| 14:01.23 | brlcad | a log that says OK says nothing useful at this point |
| 14:01.48 | brlcad | just means that run did not result in any calculations out of order |
| 14:08.32 | Notify | 03BRL-CAD:carlmoore * 56383 (brlcad/trunk/doc/docbook/system/mann/en/comb.xml brlcad/trunk/include/icv.h and 4 others): fix spelling, spacing; also, remove trailing blanks/tabs |
| 14:09.30 | Notify | 03BRL-CAD:starseeker * 56384 brlcad/trunk/doc/docbook/system/mann/en/search.xml: Update search man page to document new -bool option, add some examples showing how to use it. |
| 14:12.18 | Notify | 03BRL-CAD:starseeker * 56385 brlcad/trunk/doc/docbook/system/mann/en/search.xml: ws |
| 14:12.33 | zero_level | yeoo. |
| 14:13.52 | Notify | 03BRL-CAD:starseeker * 56386 brlcad/trunk/doc/docbook/system/mann/en/search.xml: remove db4-upgrad comment |
| 14:14.41 | starseeker | particularly likes the "find nested regions that aren't subtractions" trick |
| 14:15.01 | zero_level | can u tell me, Which type of system it was. |
| 14:18.04 | zero_level | because I want to try with semaphore now. |
| 14:23.31 | brlcad | zero_level: well I most recently saw the failure on a 10.6 Mac |
| 14:26.46 | Notify | 03BRL-CAD:starseeker * 56387 brlcad/trunk/doc/docbook/system/mann/en/search.xml: tweaks |
| 14:39.03 | Ch3ck_ | brlcad: ``Erik: i'm stuck at writing the unit test for bn_poly_synthetic_division() since I don't know what becomes of rem->cf and quo->cf after div/0 |
| 14:54.06 | brlcad | me either without doing some research to remember ;) |
| 14:55.59 | Ch3ck_ | well ``Erik says NAN is returned I don't understand if its the pointer for quo and rem |
| 14:56.37 | Ch3ck_ | structures or its for the quo->cf and rem->cf fields in the structure. |
| 14:56.55 | Ch3ck_ | The source code is not really clear as to what happens in this case. |
| 14:58.27 | Ch3ck_ | well looking at the source its for all the cf[] array elements for quo->cf |
| 14:58.47 | Ch3ck_ | still looking at what happens to rem->cf structure |
| 15:02.30 | Ch3ck_ | well will try NAN for rem->cf and see how it works out. |
| 15:09.07 | zero_level | brlcad : oops. No. Mac. |
| 15:09.24 | zero_level | do u still see it ? |
| 15:09.56 | zero_level | If yes we have I will make a commit including the semaphores. |
| 15:12.03 | zero_level | is testing with semaphores. |
| 15:27.14 | zero_level | brlcad : rtedge works find after spin locking and r56381 |
| 15:33.00 | zero_level | brlcad : What is expected after rtxray |
| 15:33.13 | zero_level | I see a monocolour helicopter. ;) |
| 15:36.33 | *** join/#brlcad Ch3ck_ (~Ch3ck@195.24.220.16) |
| 15:36.51 | zero_level | has hit benchmark after applying semphore in all the writepixel and writeline functions in rt |
| 15:43.17 | *** join/#brlcad Izak (~Izak@195.24.220.16) |
| 15:44.17 | *** join/#brlcad Izak__ (~Izak@195.24.220.16) |
| 15:45.08 | Izak__ | brlcad: ``Erik : What is really a bounding box ? |
| 15:48.23 | zero_level | blinks. runs perfect. |
| 15:49.03 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 15:49.10 | zero_level | I think i shld bring back the semaphores. (through a commit) so that brlcad or ``Erik can test on other machine as well. |
| 15:50.36 | zero_level | although I am still not sure why the error on benchmark on a Mac O.o |
| 15:58.26 | Izak__ | <PROTECTED> |
| 16:12.01 | zero_level | Izak__, Ch3ck_,kesha : I need your help |
| 16:12.20 | Ch3ck_ | zero_level: what up? |
| 16:12.38 | Izak__ | zero_level: yes |
| 16:12.39 | zero_level | Apparently I have done some changes in brl-cad code which has busted benchmark. |
| 16:13.08 | zero_level | So i wish If all of you could run benchmark on your machine |
| 16:13.10 | Izak__ | What kind of changes exactly ? |
| 16:13.18 | zero_level | and report if it fails. |
| 16:13.30 | zero_level | Apparently it Doesnt fail on my machine. |
| 16:13.49 | zero_level | So the following is the procedure for benchmark. |
| 16:13.54 | Ch3ck_ | alright so should i update the code repository first? |
| 16:14.08 | Ch3ck_ | so as to have the recent changes as you do right? |
| 16:14.17 | zero_level | a) update code repository by svn up. |
| 16:14.45 | zero_level | b) If you dont compile with Optimized flag. |
| 16:14.58 | zero_level | .. Do a fresh build. |
| 16:15.31 | Ch3ck_ | ok |
| 16:15.32 | Izak__ | I am doing an svn update now |
| 16:15.35 | Ch3ck_ | let me see what it gives |
| 16:15.46 | Izak__ | It says at r56387 |
| 16:15.50 | zero_level | adding optimization flag. -DBRLCAD_FLAGS_OPTIMIZATION=ON in the cmake command. |
| 16:16.10 | zero_level | Izak__ : That is fine. |
| 16:16.23 | zero_level | Ch3ck thanks. |
| 16:16.54 | zero_level | c) do sudo make install in the build directory. |
| 16:17.13 | zero_level | d) make benchmark in the build directory. |
| 16:17.44 | zero_level | Izak__, Ch3ck : pls ask if anything is not clear. |
| 16:18.23 | Ch3ck_ | ij |
| 16:18.25 | Ch3ck_ | ok |
| 16:18.35 | Ch3ck_ | but what about the Debug flag |
| 16:18.47 | Ch3ck_ | given to brlcad |
| 16:18.59 | Izak__ | sure will do |
| 16:19.00 | Ch3ck_ | during compilation -DBRLCAD_BUILD_TYPE=Debug |
| 16:19.04 | Ch3ck_ | ? |
| 16:19.12 | Ch3ck_ | should i ignore that? |
| 16:19.16 | Izak__ | Ch3ck_:defintely |
| 16:19.20 | zero_level | You can add that. But I believe that will not be needed. |
| 16:19.46 | zero_level | <PROTECTED> |
| 16:19.51 | zero_level | this should be fine. |
| 16:20.01 | Ch3ck_ | ok |
| 16:20.11 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 16:21.15 | zero_level | Perhaps I have been given a deadline to resurrect benchmark. |
| 16:21.48 | Ch3ck_ | OK |
| 16:21.53 | Ch3ck_ | compiling.. |
| 16:21.55 | zero_level | So Izak_, Ch3ck : your help will be crucial |
| 16:22.07 | Ch3ck_ | seeing what i can do. |
| 16:22.29 | zero_level | Also Ch3ck_, Izak__ : what systems do you use. |
| 16:22.36 | zero_level | Dont run on bz. |
| 16:22.42 | zero_level | I have taken care of that. |
| 16:23.12 | Izak__ | hp Compaq running Scientific Linux 6.2 |
| 16:24.30 | Ch3ck_ | well here is what lscpu gives |
| 16:24.33 | Ch3ck_ | root@localhost matrix test]# lscpu |
| 16:24.33 | Ch3ck_ | Architecture: i686 |
| 16:24.34 | Ch3ck_ | CPU op-mode(s): 32-bit, 64-bit |
| 16:24.34 | Ch3ck_ | Byte Order: Little Endian |
| 16:24.34 | Ch3ck_ | CPU(s): 2 |
| 16:24.34 | Ch3ck_ | On-line CPU(s) list: 0,1 |
| 16:24.36 | Ch3ck_ | Thread(s) per core: 1 |
| 16:24.38 | Ch3ck_ | Core(s) per socket: 2 |
| 16:24.40 | Ch3ck_ | CPU socket(s): 1 |
| 16:24.42 | Ch3ck_ | Vendor ID: GenuineIntel |
| 16:24.44 | Ch3ck_ | CPU family: 6 |
| 16:24.46 | Ch3ck_ | Model: 23 |
| 16:24.48 | Ch3ck_ | Stepping: 10 |
| 16:24.50 | Ch3ck_ | CPU MHz: 1203.000 |
| 16:24.52 | Ch3ck_ | BogoMIPS: 5585.69 |
| 16:24.54 | Ch3ck_ | Virtualization: VT-x |
| 16:24.58 | Ch3ck_ | L1d cache: 32K |
| 16:25.00 | Ch3ck_ | L1i cache: 32K |
| 16:25.02 | Ch3ck_ | L2 cache: 2048K |
| 16:28.46 | zero_level | oops Ch3ck_ ``Erik advised me to use paste sites. For pasting this inputs. |
| 16:29.10 | Ch3ck_ | like? |
| 16:29.14 | zero_level | http://pastebin.com/ |
| 16:29.19 | Ch3ck_ | give me an example |
| 16:29.20 | Ch3ck_ | ok |
| 16:32.54 | zero_level | Izak__, Ch3ck_ just put the compile on some window and let it go on. I wouldnt want you to be ocupied for long. |
| 16:32.57 | Izak__ | zero_level : 42% made |
| 16:33.33 | Izak__ | zero_level : No big deal. Its all the same BRL-CAD :) |
| 16:44.06 | Ch3ck_ | well benchmark tests are coming up wrong |
| 16:44.43 | Izak__ | zero_level: moss,world,star, bldg391, .....: show WRONG WRONG WRONG WRONG WRONG WRONG6 times |
| 16:44.44 | Ch3ck_ | from what brlcad explained to me benchmark tests work based on computed pix and stored already stored in the code |
| 16:45.11 | Ch3ck_ | so its to open the images and actually see if they are significant changes |
| 16:45.33 | Ch3ck_ | but based on the fact almost all of them are coming wrong then something is wrong somewhere. |
| 16:46.43 | zero_level | ok. |
| 16:48.52 | Ch3ck_ | well the first thing is to revert all the changes you made before the code went sour and see how it goes |
| 16:49.01 | Ch3ck_ | before starting any new changes. |
| 16:50.41 | zero_level | well Ch3ck_ : before that I would like to make one more commit. |
| 16:50.58 | zero_level | This has some issue with the spinlocks. |
| 16:51.07 | Ch3ck_ | well if you know it won't further degerate the problem fine. |
| 16:51.45 | Ch3ck_ | but you have to recheck all you previous commits and see which one in particular started this and work from there. |
| 16:58.34 | Notify | 03BRL-CAD:mohitdaga * 56388 (brlcad/trunk/src/rt/view.c brlcad/trunk/src/rt/viewedge.c brlcad/trunk/src/rt/viewxray.c): Applying seamaphore locks after modifying icv_writeline(..). This now doesnt hang since icv_writeline doesnt ask for memory allocation any more. Thus doesn't acquire BU_SEM_SYSCALL. This is expected to ensure sanctity in image writting from rt. |
| 16:59.01 | zero_level | Ch3ck_ : thanks. |
| 16:59.32 | zero_level | But this has an error, which, me, ``Erik and brlcad have discovered. |
| 16:59.43 | Ch3ck_ | aight |
| 16:59.50 | zero_level | related to mutex lokcs. |
| 16:59.57 | Ch3ck_ | kk |
| 17:00.01 | zero_level | c/lokcs/locks |
| 17:00.43 | zero_level | Can u do svn up. And sudo make install followed by sudo make benchmark. |
| 17:01.01 | zero_level | this will not take much time now. |
| 17:01.10 | Ch3ck_ | will have to generate a patch now.. |
| 17:01.17 | Ch3ck_ | so will update |
| 17:01.32 | zero_level | Since you already have a build at place with optimization flag. |
| 17:02.55 | zero_level | Izak__, Ch3ck_ : thanks for your support. This last test and we are done. |
| 17:03.08 | Ch3ck_ | :D |
| 17:04.04 | Izak__ | zero_level : What's that ? |
| 17:04.52 | zero_level | do svn up, then in your build directory run sudo make install. and then sudo make benchmark. |
| 17:05.37 | zero_level | Izak__: This must not take much time .Since you already have a build at place with optimization flag. |
| 17:08.29 | Ch3ck_ | zero_level: compiling .. |
| 17:13.29 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 17:17.01 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 5889 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 29 July - 4 August */ |
| 17:17.31 | Izak__ | zero_level : All benchmark tests still fail :( |
| 17:20.02 | zero_level | alright Izak__. |
| 17:20.20 | zero_level | Can u send me the image file from brlcad-build/bench folder. |
| 17:20.50 | zero_level | I believe you have run it twice. |
| 17:21.03 | zero_level | So send me the file corresponding to the latest build. |
| 17:22.15 | Ch3ck_ | zero_level: also getting a seg fault on regression tests |
| 17:22.21 | zero_level | I wish to be 100 % sure that this writes images in a sprinkled scanlines way. |
| 17:22.40 | zero_level | Ch3ck_ thanks for the info. |
| 17:24.08 | Ch3ck_ | zero_level:http://pastebin.com/FDdgCfHZ |
| 17:24.16 | Ch3ck_ | there are the details ;) |
| 17:25.04 | zero_level | is recompiling in the meantime. |
| 17:25.47 | Ch3ck_ | starseeker: brlcad: finished writing the unit test for bn_poly_synthetic_division() patches on sf waiting review. |
| 17:29.58 | zero_level | Ch3ck_ I believe the seg issue doesnt have any thing to do with ICV. |
| 17:30.23 | Ch3ck_ | aight but its in there somewhere I don't think I have anything to do with it. |
| 17:30.38 | zero_level | brlcad : Ch3ck_ has found an intresting error. |
| 17:31.00 | zero_level | <-- points to the pastebin link. |
| 17:31.04 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 5890 /wiki/User:Izak/GSOC_2013_logs: /* Mid-term Evaluation week */ |
| 17:31.37 | Ch3ck_ | ok |
| 17:31.53 | Ch3ck_ | will take a peek |
| 17:32.31 | zero_level | Izak__ or Ch3ck can u send me the images from the bench folder in your build directory. |
| 17:32.46 | zero_level | You could email me. |
| 17:33.13 | zero_level | mohit(dot)daga[at]ieee(dot)org |
| 17:34.12 | Ch3ck_ | will do. |
| 17:34.39 | Izak__ | zero_level : Which ones exactly ? They are many ! |
| 17:35.25 | zero_level | I would require from the latest benchmark test(I believe you ran two.) |
| 17:36.09 | Izak__ | Which file exactly? I don't see any picture? |
| 17:36.35 | zero_level | *.pix |
| 17:37.00 | zero_level | it must have a number |
| 17:37.00 | Izak__ | ok |
| 17:38.21 | zero_level | like moss-*.pix |
| 17:39.17 | zero_level | you could send me the complete bench folder. OR the images with the latest benchmark number. |
| 17:41.39 | Ch3ck_ | well i'll send you the whole thing and u do the sorting ok? |
| 17:41.52 | Izak__ | zero_level:I have sent all the *.pix files in a tar ball. Have u sen them ? |
| 17:43.12 | zero_level | Izak__ : thanks |
| 17:43.37 | Izak__ | zero_level : Are they the right ones ? |
| 17:44.11 | zero_level | Izak__ : Thanks. |
| 17:44.27 | zero_level | is converting them to png. |
| 17:45.31 | *** join/#brlcad vladbogo (~vlad@188.25.238.209) |
| 17:59.19 | Ch3ck_ | uploading files |
| 17:59.31 | Ch3ck_ | zero_level: should see them shortly.. |
| 18:06.35 | *** join/#brlcad caen23_ (~caen23@92.81.164.86) |
| 18:10.38 | zero_level | Ch3ck_, Izak__ : thanks ! |
| 18:10.42 | zero_level | :-) |
| 18:10.56 | zero_level | Apparently It turns out to be some floating point errors. |
| 18:11.22 | zero_level | It would not have been possible without your support. |
| 18:12.11 | Ch3ck_ | :-) |
| 18:12.23 | zero_level | Because the matter of the fact is that the error didnt show up on my machine and bz. |
| 18:14.49 | zero_level | Ch3ck_ Izak__ is it a national holiday in USA ? |
| 18:15.17 | zero_level | dont see brlcad, ``Erik, starseeker :around. |
| 18:15.44 | Izak__ | zero_level: Why do you ask that ? I think its like July 4th |
| 18:16.13 | zero_level | nevermind:-) |
| 18:18.36 | zero_level | I wonder how did brlcad concluded this ? |
| 18:18.39 | zero_level | 00:08 < brlcad> with the semaphore locks removed, scanlines are ending up out of order so have to put some thought into how that is happening and findi to a working state otherwise if a fix is not achieved within a day |
| 18:39.38 | *** join/#brlcad zero_level_ (0e8bf3a2@gateway/web/freenode/ip.14.139.243.162) |
| 18:40.17 | *** join/#brlcad zero_level (~mohit@66-118-151-70.static.sagonet.net) |
| 18:44.25 | Notify | 03BRL-CAD:n_reed * 56389 brlcad/trunk/src/libtclcad/tclcad_obj.c: Handle hidden line mode in to_edit_redraw. Fixes an archer bug where editing something drawn in hidden line mode caused it to be redrawn in shaded mode. |
| 18:48.05 | Notify | 03BRL-CAD:mohitdaga * 56390 brlcad/trunk/src/libicv/fileformat.c: Sanitize the conversion from double to unsigned char. Instead of floor which can introduce a error upto a difference of 2 intensities, adapt a more robust conversion where it rounds off to nearest integer. |
| 18:48.32 | zero_level | Ch3ck_ : Can you do it a last time? |
| 18:48.45 | zero_level | update to 56390. |
| 18:49.07 | zero_level | brlcad : Pls run benchmark after r56390 |
| 18:49.49 | zero_level | ``Erik : I am confident this time. That after r56390 we must not get benchmark error. |
| 18:51.21 | zero_level | Still I wish you to run benchmark. |
| 18:51.38 | zero_level | So that I cld be 100 % sure and move on. |
| 19:03.43 | zero_level | brlcad: I have written on the leaset seeking help. |
| 19:03.49 | zero_level | *list |
| 19:05.49 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 19:06.14 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 19:06.37 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 19:07.02 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 19:07.32 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 19:07.56 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 19:08.21 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 19:08.46 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 19:09.08 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 19:09.33 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 19:09.59 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 19:10.24 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 19:10.50 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 19:11.16 | *** join/#brlcad kesha (~kesha@14.139.122.114) |
| 19:12.49 | Notify | 03BRL-CAD Wiki:Level zero * 5891 /wiki/User:Level_zero/GSOC13/logs: /* Week 7 */ |
| 19:13.16 | zero_level | goes for sleep. |
| 20:01.40 | ``Erik | ERROR: reference image /home/erik/src/brlcad/build/gcc/bin/../share/pix/moss.pix not found |
| 20:02.39 | Notify | 03BRL-CAD:carlmoore * 56391 brlcad/trunk/src/gtools/g_transfer.c: add 'OR' line to usage, remove H and add ? (for help) |
| 20:22.11 | Notify | 03BRL-CAD:starseeker * 56392 (brlcad/trunk/doc/docbook/system/mann/en/comb.xml brlcad/trunk/include/raytrace.h and 2 others): Add a -f option to the comb command that will flatten a combination that contains only unions, and delete any orphaned combinations that were formerly present in that comb's tree but not used elsewhere in the .g file. This is the first significant programmatic use of the search capabilities |
| 20:22.13 | Notify | other than the search command itself. Full comb -f example added to the comb man page. |
| 20:24.26 | Notify | 03BRL-CAD:r_weiss * 56393 brlcad/trunk/src/librt/primitives/bot/btg.c: Fixed an intermittent seg fault when raytracing bots with bot-tie enabled. |
| 20:27.46 | *** join/#brlcad mpictor (~mark@2601:d:b280:b5:d63d:7eff:fe2d:2505) |
| 20:46.19 | Notify | 03BRL-CAD:carlmoore * 56394 brlcad/trunk/src/gtools/remapid.c: implement use of h for help |
| 20:48.26 | Notify | 03BRL-CAD:starseeker * 56395 brlcad/trunk/src/libged/comb.c: Re-arrange some of the memory freeing. |
| 20:55.24 | Notify | 03BRL-CAD:starseeker * 56396 brlcad/trunk/src/libged/comb.c: tweaks |
| 21:06.31 | Notify | 03BRL-CAD:n_reed * 56397 brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Handle hidden line mode when redrawing from script side. Extends r56389 fix to object rotate/translate/scale. |
| 21:21.35 | Notify | 03BRL-CAD Wiki:Vladbogolin * 5892 /wiki/User:Vladbogolin/GSoC2013/Logs: /* Week 7 */ |
| 23:40.17 | Notify | 03BRL-CAD:starseeker * 56398 brlcad/trunk/NEWS: Added the -bool option to search, which allows filtering based on whether a given instance of an object is combined into its parent comb with a union (u), intersection (+), or subtraction (-) boolean operator. |
| 23:42.45 | Notify | 03BRL-CAD:starseeker * 56399 brlcad/trunk/NEWS: Added -f option to the comb command, which will take a single comb as an input, check whether all boolean operations in its tree are unions, and if they are make a new tree under the comb that unions all the solids directly into the comb. Will also remove 'orphaned' combs that are no longer used by any other object in the tree, but ignores combs that are used |
| 23:42.47 | Notify | elsewhere. |