| 00:08.51 | Notify | 03BRL-CAD:brlcad * 56298 brlcad/trunk/src/libged/polyclip.cpp: well if they are, should be okay |
| 00:13.24 | Notify | 03BRL-CAD:brlcad * 56299 (brlcad/trunk/src/libged/polyclip.cpp brlcad/trunk/src/libged/view_obj.c and 4 others): eliminate undocumented dead code |
| 00:14.58 | Notify | 03BRL-CAD:brlcad * 56300 brlcad/trunk/src/libpc/solver_test.cpp: document why the libpc tests are disabled |
| 00:22.45 | Notify | 03BRL-CAD:brlcad * 56301 brlcad/trunk/src/librt/cut.c: eliminate the manual recursion dead code since rt_ct_optim() is better reuse and the implications of the dead one are not clear. |
| 02:34.22 | Notify | 03BRL-CAD:brlcad * 56302 (brlcad/trunk/src/librt/mkbundle.c brlcad/trunk/src/librt/tests/CMakeLists.txt): extract the ray bundle test harness into its own proper test program |
| 02:41.46 | zero_level_ | brlcad : I found an interesting and an annoying bug |
| 02:42.48 | zero_level_ | at L:811 in viewedge.c |
| 02:43.09 | zero_level_ | When i remove the acquire semaphore (comment it) |
| 02:43.53 | zero_level_ | the rtedge command works fine. else it hangs in between ?Do we need the semaphore there. |
| 02:44.43 | zero_level_ | Because evidently even if it is done parallelly. each process will be writing at separate lines. |
| 02:55.40 | Notify | 03BRL-CAD:phoenixyjll * 56303 brlcad/trunk/src/libbrep/intersect.cpp: If we insert the inner points of overlap2d like this, the points may not be in order. So we don't use these points. A better approach would be using a mapping of m_a and m_b. |
| 03:58.40 | brlcad | zero_level_: yes the semaphore is needed |
| 03:58.46 | brlcad | if it hangs, something else is wrong |
| 03:58.55 | brlcad | like something else acquired that same semaphore |
| 03:59.17 | brlcad | or even the same process that is running acquired one and didn't release it |
| 04:08.53 | Notify | 03BRL-CAD:phoenixyjll * 56304 brlcad/trunk/src/libbrep/intersect.cpp: Remove duplicated curves. |
| 04:11.50 | brlcad | zero_level_: make sure icv doesn't acquire that same semaphore before calling/returning back to viewedge |
| 04:14.11 | Notify | 03BRL-CAD:mohitdaga * 56305 (brlcad/trunk/include/icv.h brlcad/trunk/include/magic.h brlcad/trunk/src/libicv/fileformat.c): Converting ICV_IMAGE_FILE_MAGIC to ICV_IMAGE_MAGIC. |
| 04:37.31 | *** join/#brlcad zero_level_ (0e8bf3a2@gateway/web/freenode/ip.14.139.243.162) | |
| 04:39.02 | zero_level_ | brlcad : icv doesnt acquire any semaphore. |
| 04:39.55 | zero_level_ | brlcad: can it be machine dependent ? |
| 04:49.43 | zero_level_ | It is something like a deadlock happening here. |
| 04:49.53 | zero_level_ | And I seem to have no idea how to resolve this. |
| 04:50.22 | zero_level_ | brlcad : can we track the acquired semaphores ? |
| 05:07.46 | brlcad | zero_level_: you can set BU_DEBUG_PARALLEL, but you'll do better to set breakpoints in a debugger |
| 05:09.49 | brlcad | BU_DEBUG_PARALLEL is set with the bu debug flags (which is the -! option for rtedge, see src/rt/opt.c) |
| 05:09.58 | brlcad | see include/bu.h for the value to set (in hex) |
| 05:10.14 | *** join/#brlcad zero_level__ (0e8bf3a2@gateway/web/freenode/ip.14.139.243.162) | |
| 05:15.30 | *** join/#brlcad zero_level_ (0e8bf3a2@gateway/web/freenode/ip.14.139.243.162) | |
| 05:15.40 | zero_level_ | looks ab bu.h |
| 05:16.10 | zero_level_ | brlcad : I found this error by setting debug points in the code. |
| 05:16.21 | zero_level_ | which debugger do u suggest ? |
| 05:16.52 | zero_level_ | also i saw the presentation you gave |
| 05:17.26 | zero_level_ | It helped me understanding the architecture of rt |
| 05:59.46 | *** join/#brlcad caen23 (~caen23@92.83.175.255) | |
| 06:55.03 | zero_level_ | brlcad : one of the threads of bu_parallel in do_run(..) function in worker.c is not getting completed. |
| 06:55.23 | zero_level_ | wonder how has this anything to do with icv ? |
| 06:59.59 | Notify | 03BRL-CAD Wiki:Phoenix * 5862 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 7 */ |
| 08:46.24 | *** join/#brlcad phoenixyjll (0e889157@gateway/web/freenode/ip.14.136.145.87) | |
| 09:05.21 | *** join/#brlcad caen23 (~caen23@92.83.175.255) | |
| 09:22.45 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) | |
| 09:30.30 | *** join/#brlcad Ch3ck (~Ch3ck@195.24.220.16) | |
| 10:16.43 | Ch3ck | Hi i've just logged into my bz.bzflag.bz account and I wish to change my password. Can anyone tell me how? |
| 10:19.46 | ``Erik | run 'passwd' |
| 10:23.21 | Ch3ck | yeah did that already thanks |
| 11:48.36 | *** join/#brlcad Ch3ck_ (~Ch3ck@66-118-151-70.static.sagonet.net) | |
| 12:09.05 | *** join/#brlcad Ch3ck (~Ch3ck@66-118-151-70.static.sagonet.net) | |
| 12:15.04 | *** join/#brlcad DarkCalf (~DarkCalf@173.231.40.99) | |
| 12:17.56 | *** join/#brlcad Ch3ck (~Ch3ck@66-118-151-70.static.sagonet.net) | |
| 12:21.15 | zero_level | hi ``Erik, brlcd : still unable to find the bug. |
| 12:23.08 | zero_level | It seems that at 819. the semaphore is not acquired thus a deadlock |
| 12:23.24 | zero_level | at 819 in rt/viewedge.c |
| 12:23.26 | ``Erik | with icv saving in viewedge.c? I don't remember exactly what, but there was something 'weird' about it that required a special bailout |
| 12:24.31 | ``Erik | iirc (and this is a huge if, that was years ago), once I figured it out, I just put in the fix with the plan to re-do viewedge.c completely to make it more like a normal rt |
| 12:25.11 | ``Erik | unfortunately, I failed to document it and did not rewrite viewedge and don't remember what the exact issue was :/ srry |
| 12:25.26 | zero_level | no issues. |
| 12:25.35 | zero_level | i am just copying what I found. |
| 12:25.44 | zero_level | We can together fix it. |
| 12:26.03 | zero_level | at 757 in worker.c parallel process are created. |
| 12:26.13 | zero_level | in function do_run(..) |
| 12:26.19 | ``Erik | yes, via bu_parallel() |
| 12:26.59 | zero_level | all parallel function call worker(..0 |
| 12:27.07 | zero_level | worker then call do_pixel |
| 12:27.45 | zero_level | do_pixel() then calls view_eol(...) in viewedge.c |
| 12:28.12 | ``Erik | I believe I was wrapping the icv stuff in a bu_semaphore, that might be unnecessary... if we can trust that each worker has an exclusive memory segment |
| 12:28.38 | zero_level | A semaphore is to be acquired in view_eol for wriiting in the icv_struct |
| 12:28.42 | ``Erik | exclusively accessed, but globally accessable, so the final write out can get them all |
| 12:29.07 | zero_level | yes, indeed I asked brlcad : and he says the semaphore is required. |
| 12:29.19 | ``Erik | why? |
| 12:29.35 | zero_level | I tried to get rid of the semaphore (commenting them) and it worked. |
| 12:29.55 | zero_level | 23:58 < brlcad> zero_level_: yes the semaphore is needed |
| 12:29.57 | zero_level | 23:58 < brlcad> if it hangs, something else is wrong |
| 12:29.57 | zero_level | 23:58 < brlcad> like something else acquired that same semaphore |
| 12:29.57 | zero_level | 23:59 < brlcad> or even the same process that is running acquired one and didn't release it |
| 12:29.58 | zero_level | 23:58 < brlcad> zero_level_: yes the semaphore is needed |
| 12:30.00 | zero_level | 23:58 < brlcad> if it hangs, something else is wrong |
| 12:30.03 | zero_level | 23:58 < brlcad> like something else acquired that same semaphore |
| 12:30.05 | zero_level | 23:59 < brlcad> or even the same process that is running acquired one and didn't release it |
| 12:30.08 | zero_level | oops ! copied twice |
| 12:30.30 | ``Erik | please don't paste large bodies to channel, if it's more than a line or two, use one of the paste websites :) |
| 12:30.39 | ``Erik | there's no answer in what he said |
| 12:30.39 | zero_level | alright |
| 12:30.47 | zero_level | yes |
| 12:32.13 | ``Erik | viewedge adds some necessary locking requirements, but it also has a lot of very bad approaches... my take-away was that the original author had no idea what they were doing and hacked until it seemed to work |
| 12:32.54 | ``Erik | it uses two pixels on the current scanline and one on the previous scan line to compute the color, iirc |
| 12:34.17 | ``Erik | so there is some weird memory management and locking that has to occur, but ... hm, I'd need to review the code and collect my thoughts to see where I'm going :) |
| 12:34.27 | zero_level | ok. |
| 12:34.47 | ``Erik | it's a "here be dragons" bit of code, I'd recommend putting it on the back burner and focusing elsewhere in the meantime |
| 12:35.00 | zero_level | alrigt. |
| 12:35.30 | zero_level | But we goto do smth since this bugs an important command. |
| 12:35.39 | zero_level | If u suggest i can remove that semaphore. |
| 12:35.48 | zero_level | Since it works without it. |
| 12:36.25 | ``Erik | try removing the semaphore and then doing a raytrace on bz with, hm, say 16 threads... or 100... and see if the output seems correct |
| 12:37.00 | zero_level | can i compile the src code on bz.? |
| 12:37.03 | ``Erik | if you have a machine with more than 8 cores, try on that? |
| 12:37.17 | ``Erik | sure, bz has a full dev suite |
| 12:38.05 | zero_level | ``Erik : If I recall correctly from my class knowledge, Semaphore is required when a resource is to be used by more than one process. |
| 12:38.21 | ``Erik | it's currently slightly hacked up to force clang instead of gcc |
| 12:38.22 | zero_level | where as here each process will be writting different line. |
| 12:38.47 | ``Erik | that is true, and since each line is a unique chunk of memory, there should be no conflict |
| 12:38.56 | zero_level | yes. Exactly. |
| 12:39.50 | ``Erik | <-- points up where he said that the bu_sempahore might be unnecessary since the workers have access to an exclusive memory segment :) |
| 12:40.39 | zero_level | ? |
| 12:41.22 | zero_level | ``Erik is there a documentation on how to compile on bz ? |
| 12:41.36 | ``Erik | same as any unix machine, get a fresh checkout, run cmake, run make |
| 12:41.45 | zero_level | alright. |
| 12:42.38 | ``Erik | if you need any tools installed on that machine, let me or brlcad know and we'll figure it out |
| 12:43.17 | zero_level | Also ``Erik apart from the rtede issue. |
| 12:43.50 | zero_level | I think the FIXME in rt/do.c is now fixed. |
| 12:44.29 | zero_level | regarding bw images and rtxray |
| 12:55.23 | ``Erik | I've sent myself an email to my work account and will look over these with care tomorrow, ok? today is one of my 'unemployed' days and I have some ios work to do :) |
| 12:55.56 | zero_level | sure no issues. |
| 12:57.10 | ``Erik | I'll still keep an eye on irc if any immediate questions come up, so still feel free to ask/contemplate in chan, just don't expect a code review until tomorrow |
| 12:57.53 | ``Erik | effin' ios 7 deleting the top status bar and moving 0,0 up to dead coordinates |
| 12:58.16 | zero_level | ``Erik I will also want to learn IOS stuff from you. :-) |
| 12:58.47 | ``Erik | I'd probably be the wrong person to learn from... but if you have a certain interest, I can probably direct you towards a good resource |
| 13:00.24 | ``Erik | I have a trivial "lottery calculator" app in the store, an opengl based version of the atari classic "kaboom!" that they won't accept due to the artwork and I'm currently gearing up to do a guitar tuner app... I'm no guru for ios :D |
| 13:03.11 | zero_level | i am getting this strange issue on svn at bz |
| 13:03.14 | zero_level | svn: E170000: Unrecognized URL scheme for |
| 13:03.53 | zero_level | on searching, they direct to re install. |
| 13:04.01 | ``Erik | crap, .. |
| 13:04.02 | zero_level | i am sure i am doing smth wrong here. |
| 13:04.05 | ``Erik | no |
| 13:04.31 | ``Erik | I've been having issues with flags on the subversion install and handling of repo's via libcurl |
| 13:05.40 | ``Erik | maybe try svn checkout svn://svn.code.sf.net/p/brlcad/code/brlcad/trunk brlcad-code |
| 13:07.28 | zero_level | works. |
| 13:07.31 | zero_level | :-) |
| 13:07.48 | ``Erik | might be a bad solution.. I'm reinstalling svn and going to try with the http addy |
| 13:12.11 | ``Erik | ok, svn should be fixed on bz |
| 13:12.16 | ``Erik | (works for me) |
| 13:15.43 | Ch3ck | initially tried an svn checkout with svn https link and it said svn does not work but with the link u've just given works fine for me too |
| 13:24.01 | *** join/#brlcad Ch3ck_ (~Ch3ck@195.24.220.16) | |
| 13:27.43 | zero_level | Apparently It turns out i cannot do sudo make install on bz. |
| 13:28.02 | zero_level | did make install |
| 13:28.11 | *** join/#brlcad Izak_ (~Izak@195.24.220.16) | |
| 13:28.24 | zero_level | not sure if it will compile correctly. |
| 13:29.06 | Ch3ck_ | currently compiling code here and getting the same problem looks like its in Polyclipp.cpp |
| 13:29.21 | Izak_ | Build is failing due to a typo in line 286 src/libged/polyclip.cpp. currently fixing this typo |
| 13:29.43 | Ch3ck_ | waiting on some corrections of this. |
| 13:33.07 | zero_level | so Izak_ so that be small v instead of CAP V |
| 13:33.09 | zero_level | ? |
| 13:33.51 | Izak_ | yes I am working on that patch |
| 13:34.36 | Ch3ck_ | could someone please fix thing and update code repository? flying blind here! |
| 13:35.05 | Ch3ck_ | gotta continue working on libbn |
| 13:36.07 | Notify | 03BRL-CAD Wiki:Level zero * 5863 /wiki/User:Level_zero/GSOC13/logs: LOGS |
| 13:49.08 | brlcad | zero_level: what I don't yet understand is how you are encountering a hang with rtedge |
| 13:49.42 | brlcad | so let me be more specific as to what I hear you're suggesting and you can correct me if what I'm saying is not true |
| 13:50.16 | brlcad | you're encountering some sort of hang with rtedge (on/near line 811) and if you remove the semaphore lock, it works, no longer hangs |
| 13:50.28 | zero_level | yes |
| 13:51.14 | brlcad | if I remove the semaphore lock, rtedge reliably produces a segmentation violation (it crashes) because of multiple unprotected writes to framebuffer memory |
| 13:51.56 | brlcad | this means you've got the initiative |
| 13:52.10 | brlcad | why is yours locking is the first question to figure out |
| 13:52.27 | brlcad | not what line of code causes it to lock, WHY is it locking conceptually |
| 13:52.59 | brlcad | zero_level: do you see it hanging on an unmodified brl-cad? |
| 13:53.06 | zero_level | thats what ``Erik suggested |
| 13:53.09 | brlcad | or is the hang due to something you've changed? |
| 13:53.11 | zero_level | to run |
| 13:53.16 | zero_level | it on bz. |
| 13:53.33 | zero_level | It doesnt hang on unmodified. |
| 13:53.50 | brlcad | so then almost certainly it is something you've introduced/changed |
| 13:54.00 | brlcad | make a smaller modification |
| 13:54.28 | brlcad | do you think you understand how locking works? |
| 13:54.42 | zero_level | never tried practically. |
| 13:54.50 | zero_level | apart from systems lab |
| 13:54.59 | zero_level | though have some textbook knowledge. |
| 13:55.23 | zero_level | also brlcad do we have some flag to find semaphore locks ? |
| 13:55.25 | brlcad | i'm talking about general textbook knowledge of what a semaphore/mutex lock is and how it pertains to code execution |
| 13:55.33 | zero_level | yes. |
| 13:56.14 | brlcad | so then all you need to know is to understand how libbu does it's locking, which is actually quite a simplified form |
| 13:56.58 | zero_level | some debug flags to find locks? |
| 13:57.17 | brlcad | you could add something simple, but no this is usually not an issue |
| 13:57.22 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 5864 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 29 July - 4 August */ |
| 13:57.25 | brlcad | bu_semaphore_acquire(KEY) ... bu_semaphore_release(KEY) |
| 13:58.26 | brlcad | for that line 811 to hang, it really only means one thing has happened |
| 13:58.57 | brlcad | that a lock has already been acquired on the KEY=BU_SEM_SYSCALL semaphore |
| 14:01.03 | brlcad | zero_level: if you run in a debugger, just put a break point on bu_semaphore_acquire |
| 14:01.07 | zero_level | probably at L:695 |
| 14:01.40 | brlcad | line numbers aren't going to be useful if you've made a modificiation, since it's the modification that is introducing a problem |
| 14:01.50 | zero_level | oops! nevermind :-) |
| 14:02.02 | zero_level | doesnt go to that block |
| 14:02.04 | zero_level | yepp. |
| 14:03.17 | brlcad | I think you need to make your patch smaller to where you isolate what exactly is causing this, if you cannot use the debugger to find it |
| 14:03.29 | brlcad | do you know how to set a breakpoint on functions in a debugger? |
| 14:03.42 | zero_level | no! |
| 14:03.56 | brlcad | well why not? :) |
| 14:04.00 | zero_level | can u suggest me a debugger. |
| 14:04.05 | zero_level | :-) |
| 14:04.11 | ``Erik | gdb |
| 14:04.16 | zero_level | alright |
| 14:04.19 | Izak_ | gdb |
| 14:04.33 | zero_level | but it has issues related to commands with args. |
| 14:04.48 | brlcad | it doesn't have issues |
| 14:04.51 | brlcad | you might have issues :) |
| 14:04.52 | zero_level | ok. |
| 14:05.04 | zero_level | sure then I am on my way to gdb. |
| 14:05.27 | brlcad | gdb --args bin/rt share/db/moss.g all.g |
| 14:05.37 | brlcad | b bu_semaphore_acquire |
| 14:05.38 | brlcad | run |
| 14:06.33 | ``Erik | gdb is a bit tricky to get started with, but is a very powerful tool... (much like vim or emacs) |
| 14:09.12 | ``Erik | also; you won't get sudo. by the time you're ready for sudo, you won't really want it. so forget that, just ask brlcad or me for software installs, we'll assess and if it makes sense, we'll take care of it. |
| 14:10.52 | zero_level | Alright, I understand its server issue. |
| 14:11.16 | zero_level | But can i still install brl-cad. |
| 14:11.54 | ``Erik | when you run cmake, do -DCMAKE_INSTALL_PREFIX=$HOME/brlcad or something |
| 14:11.55 | zero_level | <PROTECTED> |
| 14:12.00 | zero_level | ok |
| 14:12.10 | Ch3ck_ | hey what about this error on polyclipp.cpp that i'm getting when compiling code? |
| 14:12.15 | Ch3ck_ | anybody fixed it yet? |
| 14:16.37 | Izak_ | ps developers : Apply ticket 218 of patches on sf.net |
| 14:18.17 | Izak_ | brlcad: A small typo on line 286 of src/libged/polyclip.cpp has been fixed in ticket 218 . ps apply so build succeeds :) |
| 14:25.04 | Notify | 03BRL-CAD:mohitdaga * 56306 brlcad/trunk/src/libged/polyclip.cpp: Fixing typo. Applying patch 218 by Isaac Kamga. |
| 14:26.24 | zero_level | Izak_ u must do an svn up now. |
| 14:26.39 | zero_level | Ch3ck : one can edit the file manually ;) |
| 14:26.47 | Izak_ | yap |
| 14:28.30 | Ch3ck_ | yeah did that code compiles now perfectly :) |
| 14:29.05 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 14:34.12 | brlcad | Izak_: thanks |
| 14:37.57 | brlcad | zero_level: you'll wnat to delete your build directory and re-run cmake with that -DCMAKE_INSTALL_PREFIX option |
| 14:38.17 | brlcad | so that brl-cad installs into your home directory instead of the system path |
| 14:39.48 | zero_level | brlcad : did u run the rtege command without removing the bu_log_semaphore ? |
| 14:39.49 | brlcad | Ch3ck_: the issues that starseeker was telling you last night are all things that I've said as well |
| 14:40.10 | brlcad | zero_level: yes |
| 14:40.13 | brlcad | I run it all the time |
| 14:40.17 | brlcad | it's a heavily used command |
| 14:40.30 | zero_level | I mean after applying icv |
| 14:40.32 | zero_level | changed |
| 14:40.40 | zero_level | that is modified icv |
| 14:40.46 | zero_level | so to say |
| 14:40.49 | brlcad | no, of course not - I hear it hangs ;) |
| 14:40.59 | zero_level | can u do it now ? |
| 14:41.02 | brlcad | not really |
| 14:41.09 | brlcad | I'm in the middle of several other things |
| 14:41.09 | zero_level | alright |
| 14:41.12 | zero_level | sure |
| 14:41.31 | Ch3ck_ | brlcad: Well I thought if i finish combining the push/xpush it'll give me commit access |
| 14:41.35 | Ch3ck_ | which is what i've done. |
| 14:41.45 | brlcad | I can try to take a look later this evening, but this really is your issue to resolve since you introduced it |
| 14:41.57 | brlcad | Ch3ck_: commit access does not work like that |
| 14:42.08 | zero_level | alright. :-) |
| 14:42.38 | brlcad | commit access is a process unique to each individual depending on how good they are at communicating, creating good patches, etc |
| 14:43.32 | brlcad | that task to merge push+xpush could have been sufficient, but it's problematic because of the way it's been worked and communicated |
| 14:43.55 | brlcad | for example, you said last night that you could not see a way to break the patch up |
| 14:44.15 | brlcad | which I think is curious, because I can think of dozens of ways to break that patch up |
| 14:44.35 | brlcad | with the goal-mindset you have, sure, but then patches are NOT about the goal |
| 14:44.47 | brlcad | they're about demonstrating competency communicating with other developers |
| 14:45.19 | Ch3ck_ | yeah |
| 14:46.21 | brlcad | if you can only explain a concept by making me read the entire concept, you've not yet figured out how to communicate effectively, right? |
| 14:46.35 | Ch3ck_ | Did not see it that way. Was thinking more about getting the problem solved. |
| 14:46.52 | brlcad | which it doesn't do |
| 14:47.01 | brlcad | sure it merges the two |
| 14:47.11 | brlcad | but the PROBLEM is what I stated on the mailing list many weeks ago |
| 14:47.21 | Ch3ck_ | yes. |
| 14:47.25 | brlcad | if the two are going to be merged, the user interface question has to be addressed |
| 14:47.49 | brlcad | you don't address that, you just merged them code-wise without regard to the interface impliciation |
| 14:48.06 | brlcad | which means the code must be scrutinized that much more closely |
| 14:48.09 | Ch3ck_ | Well I made xpush 'push -x' |
| 14:48.14 | brlcad | exactly |
| 14:48.16 | brlcad | is that best? |
| 14:48.18 | Ch3ck_ | and push stayed the same |
| 14:48.31 | brlcad | how does that affect users? |
| 14:48.45 | Ch3ck_ | well you had told me to write in such a way which the command could figure that out and do the right |
| 14:49.01 | Ch3ck_ | thing. Which I could still do. |
| 14:49.21 | brlcad | figure what out? |
| 14:49.46 | Ch3ck_ | in case where an object that moves in more than one direction is given to the push command |
| 14:50.15 | Ch3ck_ | the command will be able to detect that case and do the right push on it which is like 'xpush' ing the object |
| 14:50.58 | brlcad | are you saying you made 'push' without -x behave that way? |
| 14:51.03 | Ch3ck_ | yes. |
| 14:51.06 | brlcad | if so, how's that different from push -x ? |
| 14:51.18 | Ch3ck_ | well its the same thing basically |
| 14:51.29 | Ch3ck_ | then its preferable i remove the push -x |
| 14:51.32 | Ch3ck_ | and leave it as push |
| 14:51.33 | brlcad | so then you just made the old push command go away? |
| 14:51.51 | Ch3ck_ | No the old push |
| 14:51.51 | brlcad | s/command/functionality/ |
| 14:52.17 | Ch3ck_ | command is stil there but in a case where an object is detected to be moving in more than one direction |
| 14:52.42 | Ch3ck_ | the push command calls a special pushx() routine which then pushes the object. |
| 14:52.59 | Ch3ck_ | which is like xpush ing the object |
| 14:53.46 | Ch3ck_ | so there will be no need for neither push -x nor xpush altogether |
| 14:53.51 | brlcad | zero_level: I presume that is you crashing tools? :) |
| 14:54.21 | Ch3ck_ | which I figure will be cleaner and easier for end-users who'll not need to remember so many commands |
| 14:54.24 | brlcad | Ch3ck_: so on the surface that sounds good but it's also a HUGE change in behavior |
| 14:54.42 | brlcad | at least for the use-cases where the previous push command was desirable over xpush |
| 14:54.45 | brlcad | if any |
| 14:55.25 | Ch3ck_ | well the old push command still stays in tact |
| 14:55.46 | Ch3ck_ | but I added the ability for it to detect the special case of xpush and still do a push on it |
| 14:55.53 | brlcad | not what you just said, you said it calls this xpush() routine when an object is duplicate-referenced |
| 14:55.54 | Ch3ck_ | using the pushx() subroutine in push.c |
| 14:56.30 | Ch3ck_ | well not xpush() pushx() which works like ged_xpush() |
| 14:56.38 | Ch3ck_ | similar but not the same |
| 14:56.39 | *** join/#brlcad hickoryknoll (~hickorykn@66-118-151-70.static.sagonet.net) | |
| 14:56.40 | Ch3ck_ | actually |
| 14:56.45 | brlcad | if I just run push() does it call pushx() or does a user have to specify an option? |
| 14:57.01 | Ch3ck_ | if he does it'll work |
| 14:57.09 | Ch3ck_ | and if the user does not do it'll still work\ |
| 14:57.17 | brlcad | that doesn't answer my question |
| 14:57.39 | brlcad | if I just run ged_push(), does it call pushx() automatically when it detects duplciate reference or does a user have to specify an option? |
| 14:57.49 | Ch3ck_ | yes |
| 14:57.54 | brlcad | it's not a yes no question! |
| 14:57.54 | Ch3ck_ | it calls automatically |
| 14:58.06 | Ch3ck_ | Yes it can call automatically |
| 14:58.22 | brlcad | so then that's a change in behavior |
| 14:58.31 | Ch3ck_ | yeah |
| 14:58.55 | brlcad | all the more emphasis on what starseeker was saying then |
| 14:59.00 | brlcad | we don't just change things on users |
| 14:59.04 | brlcad | that's the best way to lose users |
| 14:59.20 | Ch3ck_ | so how do I proceed now |
| 14:59.22 | brlcad | it can be changed, but the impact has to be inspected |
| 14:59.30 | Ch3ck_ | ok |
| 14:59.43 | Ch3ck_ | well since the aim was to merge both commands |
| 14:59.46 | brlcad | this is a question you probably cannot answer, except maybe to try and start a discussion on the mailing list |
| 14:59.56 | brlcad | NO |
| 15:00.02 | brlcad | the aim was to get you commit access |
| 15:00.06 | brlcad | through a set of simple patches |
| 15:00.13 | Ch3ck_ | ok |
| 15:00.27 | brlcad | merging push+xpush had the potential to be a reasonable set of patches |
| 15:00.34 | brlcad | but not like this |
| 15:01.04 | Ch3ck_ | So how best do i do it.. |
| 15:01.15 | brlcad | and the notion that you still do not understand why just further indicates the need for more patches |
| 15:01.32 | brlcad | do you really not see how this could have been a set of patches? |
| 15:01.38 | brlcad | instead of one big patch |
| 15:01.43 | Ch3ck_ | I now see |
| 15:02.02 | Ch3ck_ | I have made alot of changes and included in one big patch |
| 15:02.28 | Ch3ck_ | which I could have made in a small set of incremental changes and uploaded small patches instead |
| 15:02.34 | Ch3ck_ | thats the error I made |
| 15:03.05 | Ch3ck_ | Well concerning commit access that's why i'm looking at the libbn |
| 15:03.14 | brlcad | even if you had not changed push's default behavior, this could have been done step by step (and you would have had commit access more than a month ago)... :) |
| 15:03.36 | Ch3ck_ | to see how I could optimise some of its routines. |
| 15:03.49 | brlcad | do you know what a unit test is? |
| 15:04.00 | Ch3ck_ | not really |
| 15:04.03 | brlcad | okay |
| 15:04.38 | brlcad | say I gave you a function, maybe even that pushx() function or really ANY single function |
| 15:04.52 | brlcad | and I asked you to prove that the implementation is correct for all possible inputs |
| 15:04.58 | Ch3ck_ | ok |
| 15:05.16 | brlcad | so you write a little main() program ... and feed it all possible inputs |
| 15:05.31 | brlcad | and check what you expect the value to be from what the function actually produces |
| 15:05.38 | brlcad | that's basically a unit test |
| 15:05.49 | Ch3ck_ | ok like the one I did for my_inverse routines.. |
| 15:05.53 | brlcad | not really |
| 15:06.07 | brlcad | it's similar in the sense that it's a small program |
| 15:06.19 | brlcad | but that program did not test for correct behavior |
| 15:06.31 | Ch3ck_ | ok |
| 15:06.31 | brlcad | it merely tested the last computed one to make sure it matched |
| 15:06.58 | brlcad | unit tests should test all possible values without user having to inspect |
| 15:07.31 | brlcad | what happens if I feed an array of 'inf' or 'nan' values or a mix of both to the inverse routine? |
| 15:07.36 | brlcad | does it produce the right answer? |
| 15:07.39 | brlcad | does it crash? |
| 15:07.53 | brlcad | a unit test ideally answers those questions automatically |
| 15:08.05 | Ch3ck_ | ok |
| 15:08.20 | *** join/#brlcad Izak_ (~Izak@195.24.220.16) | |
| 15:08.50 | brlcad | Ch3ck_: you're familiar with sscanf() I presume? |
| 15:08.56 | Ch3ck_ | yes |
| 15:09.07 | brlcad | we implement our own secure version of sscanf in LIBBU |
| 15:09.26 | brlcad | and there's a unit test to make sure that our implementation behaves identically to the system libc scanf() implementation |
| 15:09.34 | brlcad | see src/libbu/tests/bu_sscanf.c |
| 15:09.45 | Ch3ck_ | ok |
| 15:09.57 | brlcad | that's one extreme |
| 15:10.20 | brlcad | in the same folder, you can see src/libbu/tests/bu_dirname.c which is a much more simple unit test that compares with libc's dirname() function |
| 15:10.43 | brlcad | perhaps a better simple example to start with |
| 15:10.49 | Ch3ck_ | ok |
| 15:10.59 | brlcad | read both quickly just to get an idea |
| 15:11.28 | brlcad | the complexity of the robustness requirements usually drives the complexity of the unit test |
| 15:11.47 | brlcad | in bu_sscanf's case, it's a crazy complicated command so the test is crazy complicated |
| 15:12.01 | brlcad | in bu_dirname's case, the function is very simple, so the test is simple |
| 15:12.24 | Ch3ck_ | yes |
| 15:12.26 | brlcad | libbn doesn't yet really have any unit tests |
| 15:12.33 | Ch3ck_ | ok |
| 15:12.47 | Ch3ck_ | So i'm to write some for libbn |
| 15:12.49 | Ch3ck_ | right? |
| 15:12.50 | brlcad | all of it's CURRENT testing is done at a very high level through what are called integration tests |
| 15:13.08 | brlcad | we make sure outputs are what we expect |
| 15:13.13 | brlcad | that would be good |
| 15:13.13 | brlcad | Ch3ck_: you can make your patches be anything |
| 15:13.18 | brlcad | the smaller the better |
| 15:13.22 | Ch3ck_ | ok |
| 15:13.35 | brlcad | the point is to demonstrate your ability to communicate, not get homework completed ... remember that |
| 15:13.46 | brlcad | this is a communication problem |
| 15:13.47 | Ch3ck_ | So i could write tests for basically most of the functions in say /src/libn/mat.c |
| 15:13.48 | brlcad | not a code problem |
| 15:14.02 | brlcad | I would suggest starting more simple actually |
| 15:14.09 | Ch3ck_ | yes.. GSoC has taught me that. |
| 15:14.15 | brlcad | you could do mat.c, but it's one of the biggest files in libbn |
| 15:14.22 | Ch3ck_ | :) ok |
| 15:14.57 | Ch3ck_ | So i'll start writing some unit tests to make sure most of the functions are actually doing what they're expected to do right? |
| 15:15.10 | brlcad | sure |
| 15:15.43 | brlcad | actually, I have a good one for you that is actually needed |
| 15:15.47 | brlcad | test poly.c |
| 15:15.48 | Ch3ck_ | ok thanks :) will get on that and make sure everyone is informed |
| 15:15.49 | Ch3ck_ | ok |
| 15:15.55 | *** join/#brlcad caen23 (~caen23@92.83.175.255) | |
| 15:17.01 | brlcad | Ch3ck_: or src/librt/roots.c |
| 15:17.29 | brlcad | Ch3ck_: when I say it's a communication problem, that doesn't mean spamming the mailing list with a lot of information about your progress |
| 15:17.38 | brlcad | it means creaing a patch that tells a simple and clean story |
| 15:17.46 | brlcad | a patch that conforms to our style |
| 15:17.58 | brlcad | that is in "our language" |
| 15:18.39 | Ch3ck_ | Yes :) I get it |
| 15:18.58 | Izak_ | brlcad: i enjoy your sense of humour :) |
| 15:19.26 | brlcad | I wasn't aware I had one ;) |
| 15:19.38 | Ch3ck_ | nahh :) you really have.. |
| 15:27.02 | Notify | 03BRL-CAD:d_rossberg * 56307 (brlcad/trunk/doc/docbook/system/man1/en/CMakeLists.txt brlcad/trunk/src/conv/raw/CMakeLists.txt): apply Jonathan's patch from https://sourceforge.net/p/brlcad/patches/195/ adding a g-raw converter in response to the GCI task http://www.google-melange.com/gci/task/view/google/gci2012/7945223 |
| 15:27.40 | brlcad | woo hoo! |
| 15:28.05 | brlcad | ejno: congrats |
| 15:33.45 | zero_level | brlcad :on bz? |
| 15:44.07 | zero_level | brlcad: rt tools ? |
| 16:04.22 | *** join/#brlcad kesha__ (~kesha@14.139.122.114) | |
| 16:09.52 | *** join/#brlcad zero_level (~mohit@66-118-151-70.static.sagonet.net) | |
| 16:13.01 | brlcad | zero_level: yes, on .bz |
| 16:13.47 | brlcad | and I see that it was actually Ch3ck_ with the crashes, not you |
| 16:14.56 | zero_level | alright! |
| 16:29.42 | Notify | 03BRL-CAD Wiki:KeshaSShah * 5865 /wiki/Patches: /* How to Submit a patch */ |
| 16:43.06 | zero_level | brlcad : I got the error. |
| 16:43.26 | zero_level | http://blogs.adobe.com/flascc/2012/11/30/finding-multi-threading-bugs-with-gdb/ |
| 16:43.30 | *** join/#brlcad caen23 (~caen23@92.85.90.139) | |
| 16:43.56 | zero_level | my writeline function allocates memory. |
| 16:44.13 | zero_level | UCHAR -> Double conversion |
| 16:44.30 | zero_level | and bu_malloc acquires the same semaphore. |
| 16:44.37 | zero_level | BU_SEM_SYSCALL |
| 16:45.35 | zero_level | gdb rocks. |
| 16:47.17 | Izak_ | zero_level : sure it does :) |
| 16:49.19 | zero_level | Izak_ : I lacked motivation initially. |
| 16:50.46 | Izak_ | zero_level: understood :) have you closed the ticket you just applied ? |
| 16:53.57 | Notify | 03BRL-CAD:mohitdaga * 56308 brlcad/trunk/src/libicv/fileformat.c: Free redundant memory in icv_image_writeline |
| 16:56.28 | zero_level | brlcad : I am not sure which semaphore must be apt there. |
| 16:56.46 | zero_level | at819 in viewedge.c |
| 16:57.21 | zero_level | I wish to define another semaphore for icv activities |
| 16:57.56 | zero_level | I mean there will be many cases where one might wish to writelines in parallel. |
| 16:58.06 | zero_level | write pixels in parallel |
| 16:59.15 | zero_level | or indeed do many image proessing tasks in parallel. |
| 16:59.32 | zero_level | I think i have. |
| 16:59.39 | zero_level | checks again. |
| 16:59.48 | zero_level | Izak_ |
| 17:00.25 | zero_level | Izak_ : yes |
| 17:00.40 | zero_level | ``Erik any suggestions regarding semaphore for ICV ? |
| 17:00.44 | Izak_ | zero_level :Still shows status : open |
| 17:01.42 | zero_level | Izak_ : http://sourceforge.net/p/brlcad/patches/218/ |
| 17:01.53 | zero_level | closed-accepted |
| 17:02.01 | Izak_ | zero_level:seen it :) its closed :) |
| 17:02.13 | zero_level | Izak_ thanks :-) |
| 17:02.27 | Izak_ | thanks too :) |
| 17:06.46 | ``Erik | zero_level: remove 'em and see... hit it with a multi-proc machine (like bz), I'll take a more meticulous look tomorrow |
| 17:08.38 | ``Erik | in rt, each proc will try to address a single scanline, so lockless should be ok... in rtedge, you need just enough locking to guarantee that the previous scanline has had it's primary shot set done before the pixel value run is done... it might make sense to break it up so a pass of all depths is done, then the 'edge' algorithm is done on the result |
| 17:10.46 | brlcad | zero_level: outstanding, that's probably your best accomplishment to date, figuring that out :) |
| 17:11.06 | brlcad | makes perfect sense .. malloc also acquiring the lock |
| 17:11.37 | brlcad | learning a debugger should be required first-year coding activity |
| 17:12.52 | brlcad | zero_level: it SHOULD be possible to access libfb (fb_write() and friends) without semaphore locking .. why rtedge does it will require some rework/fixing |
| 17:13.08 | *** join/#brlcad mpictor (~mark@2601:d:b280:b5:d63d:7eff:fe2d:2505) | |
| 17:13.42 | brlcad | might require re-writing rtedge, but that's not that hard either |
| 17:13.50 | brlcad | i've done it in a couple days before, we could do it again .. probably should just to fix some other issues |
| 17:19.21 | *** join/#brlcad hickoryknoll (~hickorykn@66-118-151-70.static.sagonet.net) | |
| 17:28.46 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 5866 /wiki/User:Izak/GSOC_2013_logs: /* From July 22th to July 27th */ |
| 17:31.24 | zero_level | brlcad : Its a bug i introduced. Wasted my two days. Can take that as the best accomplishments. |
| 17:31.57 | zero_level | but yes in the meanwhile i learnt to learn new things. |
| 17:32.14 | zero_level | correction/Can/Can't |
| 17:32.50 | zero_level | ``Erik, brlcad : I suggest introducing a new semaphore. BU_SEM_ICV |
| 17:33.08 | zero_level | among the list of semaphores in bu.h |
| 17:34.05 | Notify | 03BRL-CAD Wiki:KeshaSShah * 5867 /wiki/User:KeshaSShah/GSoC13/Reports: /* Week 7 */ |
| 17:36.20 | zero_level | I will need guidance to rework on rtedge. |
| 17:36.46 | zero_level | brlcad: We both can work together to fix issues. |
| 17:37.14 | zero_level | But first we need to identify issues and a plan on how to handle them. |
| 17:41.12 | ``Erik | education is valuable... |
| 17:41.27 | ``Erik | new semaphore is probably a bad idea |
| 17:41.35 | zero_level | alright. |
| 17:41.59 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 5868 /wiki/User:Izak/GSOC_2013_logs: /* Mid-term Evaluation week */ |
| 17:42.07 | zero_level | but ``Erik writting in a memory buffer categorized as system semaphore ? |
| 17:42.32 | ``Erik | could be... is there a reason to lock the memory writes? |
| 17:42.44 | zero_level | dont know ? |
| 17:43.48 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 5869 /wiki/User:Izak/GSOC_2013_logs: /* Mid-term Evaluation week */ |
| 17:43.50 | ``Erik | then you need to read/learn more :) |
| 17:44.51 | ``Erik | how apropos.. just now in another channel: 13:44 < oGMo> C itself may complicate issues, though like wiht most things in C, if you can't determine it's safe you don't do it |
| 17:47.37 | zero_level | ``Erik write. |
| 17:47.50 | zero_level | oops! |
| 17:49.10 | zero_level | ``Erik how do u think we shld aproach this issue now ? |
| 17:51.19 | zero_level | was going through the log of this file. It turns out that the src had the semaphore from its existence. |
| 17:53.06 | zero_level | ``Erik : apart from r27878 (by you). "spinlock to avoid scanlines being written out of order" |
| 18:21.57 | zero_level | ``Erik ran rtedge on bz with -P100 option. |
| 18:22.13 | zero_level | without semaphores. |
| 18:22.24 | zero_level | turns out that it works fine. |
| 18:22.31 | zero_level | check this |
| 18:22.32 | zero_level | http://brlcad.org/~mohit/new.png |
| 18:33.35 | zero_level | also ran with 10,20,30,40,100,500 threads |
| 18:33.48 | zero_level | brlcad, ``Erik : results are identical |
| 18:33.51 | zero_level | see this |
| 18:33.59 | zero_level | http://brlcad.org/~mohit/rtedgeMP/ |
| 18:46.11 | Notify | 03BRL-CAD:mohitdaga * 56309 brlcad/trunk/src/rt/viewedge.c: Fixed bug of rtedge after applying modified icv. Apparently icv_image_writeline usage bu_mallo(..) which in turn acquires semaphore BU_SEM_SYSCALL. Thus there was a deadlock. After removing this semaphore tested on bz with 10,20,30,40,100,500 process and resultant image was identical and correct. |
| 18:49.10 | zero_level | brlcad, ``Erik view.c also has similar semaphore |
| 18:49.24 | zero_level | at line:571 |
| 18:55.58 | brlcad | zero_level: I was just doing to say that the bug is not specific to to rtedge |
| 18:56.10 | brlcad | rt hangs as well once I put a full compile through its paces |
| 18:57.02 | zero_level | brlcad : yes atleast rtedge is fixed now. :-) |
| 18:57.13 | zero_level | lets move to next command in raytracer |
| 18:57.37 | zero_level | I shld be able to fix them all |
| 18:57.54 | brlcad | zero_level: it's not fixed |
| 18:58.03 | brlcad | now rtedge crashes for me after your 56309 |
| 18:58.17 | zero_level | oops !! |
| 18:58.25 | zero_level | how many process ? |
| 18:58.39 | zero_level | can u run gdb? |
| 18:58.43 | zero_level | ;) |
| 18:59.08 | zero_level | on it ran perfectly alright . |
| 18:59.45 | zero_level | ^bz it ran .. |
| 19:00.33 | brlcad | the non-existence of a crash doesn't say anything about the existence of a problem |
| 19:00.34 | brlcad | I need to run some more tests to make sure there aren't ancilliary affects involved |
| 19:01.36 | brlcad | see if rt works for you after applying a similar change |
| 19:01.36 | zero_level | logically its tue. |
| 19:01.36 | brlcad | logically its mon. |
| 19:01.36 | zero_level | brlcad : but i went to the logs to find out the origin of semaphores |
| 19:01.37 | zero_level | *true. |
| 19:02.38 | zero_level | brlcad : and as ``Erik wrote on the logs of r27878:- "spinlock to avoid scanlines being written out of order" |
| 19:02.40 | brlcad | conceptually, it seems on the surface that it should work |
| 19:03.17 | zero_level | so there shld be no issues of such kind with icv. |
| 19:03.47 | zero_level | because icv uses pointer airthmetic to find the start of the scaline in the image_struct->data/ |
| 19:04.14 | brlcad | like I said, it should work |
| 19:04.37 | zero_level | Although I am not sure about fb_write, where spinlock was originally introduced. |
| 19:05.18 | brlcad | blocking around fb_write() is the fundamental issue, as that is platform specific -- you don't know what kind of libfb interface will be used |
| 19:06.07 | zero_level | yes on 27 Jan 2007; ``Erik found that ;) |
| 19:07.04 | zero_level | no 16 Mar 2007. |
| 19:07.52 | zero_level | but we shldnt refrain from testing more result. |
| 19:08.32 | zero_level | I am planning to test on more bigger images. |
| 19:08.51 | zero_level | brlcad: can suggest some tests. |
| 19:09.28 | zero_level | can ^you suggest |
| 19:10.28 | brlcad | benchmark is a first pass test |
| 19:10.37 | brlcad | "make benchmark" or just "benchmark" post-install |
| 19:15.07 | zero_level | Fatal error. |
| 19:16.58 | zero_level | I am testing that after removing semaphore from view.c |
| 19:18.46 | zero_level | sees midterm evaluation is on at melange |
| 19:21.17 | zero_level | brlcad : benchmark is producing results. |
| 19:25.54 | zero_level | brlcad : In some time I should be able to send you benchmark results. |
| 19:26.18 | zero_level | brlcad : I am running benchmark after removing semaphores from view.c |
