| 01:04.09 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) | |
| 02:47.31 | brlcad | heh, just a little bias there |
| 03:32.17 | Notify | 03BRL-CAD:brlcad * 56229 (brlcad/trunk/src/tclscripts/helplib.tcl brlcad/trunk/src/tclscripts/lib/Drawable.tcl and 3 others): more .pl to .plot3 conversion |
| 03:57.43 | FLOSSrookie | I just installed brl-cad from source using cmake. Umm...What do I type in at the terminal to start it? |
| 03:59.40 | FLOSSrookie | Never mind. |
| 03:59.57 | FLOSSrookie | I needed to add it to the path. Forgot. |
| 04:05.04 | *** part/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) | |
| 04:47.39 | Notify | 03BRL-CAD:brlcad * 56230 brlcad/trunk/NEWS: bob fixed/changed archer to now respect and propagate the LIBRT_BOT_MINTIE environment variable. previously, the existing archer preference for that variable would override if a .archerrc file even got saved and users would still have to set the environment variable for sub-process rt/rtedge invocations. now the preference will pass down to sub-processes and it respects |
| 04:47.41 | Notify | the env var if it's set. |
| 04:50.30 | Notify | 03BRL-CAD:brlcad * 56231 brlcad/trunk/NEWS: erik upgraded libpng to 1.6.3 from 1.6.2 (from 1.5.12). the subsequent upgrade makes the prior 1.6.2 work no longer user-visible. |
| 04:52.00 | *** join/#brlcad caen23 (~caen23@92.81.168.84) | |
| 07:53.47 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) | |
| 09:28.59 | Notify | 03BRL-CAD Wiki:Level zero * 5831 /wiki/User:Level_zero/GSOC13/logs: /* Week 6 */ |
| 09:37.46 | *** join/#brlcad Ch3ck (~Ch3ck@195.24.220.16) | |
| 09:52.50 | *** join/#brlcad caen23 (~caen23@92.81.168.84) | |
| 11:30.57 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 5832 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 22 July - 28 July */ |
| 11:37.38 | brlcad | Ch3ck: you really need to stop yourself every time you send an e-mail |
| 11:42.30 | Ch3ck | I don't understand. |
| 11:43.38 | brlcad | Ch3ck: there are still problems with your e-mails ... :) |
| 11:44.07 | brlcad | your very last e-mail, you 1) top-posted and 2) included the entire message in reply |
| 11:44.30 | brlcad | and this is AFTER we've just talked about this exact point several times now |
| 11:45.08 | brlcad | Do you understand now? |
| 11:47.20 | Ch3ck | yes i get But i usually try to delete the previous message before writing the reply |
| 11:47.21 | Ch3ck | But i see some ...(3 dots) below i don't know if thats the previous message |
| 11:47.21 | Ch3ck | i need to delete.. |
| 11:48.09 | brlcad | Ch3ck: what is your e-mail program? |
| 11:48.24 | Ch3ck | i reply straight from gmail. |
| 11:48.40 | brlcad | dear lord then why does every e-mail have a problem? :) |
| 11:48.49 | brlcad | gmail is built to do this right |
| 11:49.28 | brlcad | "Respond inline: If you want to see the previous message within your reply, scroll down until you see the "Show trimmed content" icon and click it. |
| 11:49.33 | brlcad | THAT |
| 11:49.42 | brlcad | is from here: https://support.google.com/mail/answer/2645922?hl=en |
| 11:49.47 | Ch3ck | ok |
| 11:49.49 | Ch3ck | i see .. |
| 11:49.51 | brlcad | basically, you should always click that ... |
| 11:50.02 | Ch3ck | ok |
| 11:50.07 | *** join/#brlcad Izak_ (~Izak@195.24.220.16) | |
| 11:50.09 | brlcad | and then insert your replies, and delete the portions not relevant |
| 11:50.15 | Ch3ck | was never clicking it just used to reply directly. |
| 11:50.16 | Ch3ck | ok |
| 11:50.16 | brlcad | no need to copy-paste anything |
| 11:50.36 | Ch3ck | ok |
| 11:50.53 | brlcad | send me a test message |
| 11:51.04 | brlcad | I e-mailed you in private yesterday |
| 11:51.20 | brlcad | e-mail me back and respond to two separate sentences, delete the rest |
| 11:51.46 | Ch3ck | ok |
| 11:52.20 | brlcad | Ch3ck: and again, really truly impressive work with the libbn change validation |
| 11:52.22 | brlcad | nice work |
| 11:52.32 | brlcad | what made you think to rewrite those functions? |
| 11:52.54 | Ch3ck | well just looked at them and thought code was just so complex |
| 11:53.07 | Ch3ck | since I need them for the pull |
| 11:53.25 | Ch3ck | guessed i should make them better and integrate into the pull |
| 11:53.35 | brlcad | the reason for that is probably just because they were written once long ago and not much uses them |
| 11:53.56 | brlcad | most of libbn is decently optimized if it's at all used |
| 11:54.10 | brlcad | but yeah, that was definitely a cool improvement |
| 11:54.27 | brlcad | would make sense to audit and see where it can be put to use more |
| 11:54.51 | Ch3ck | yeah |
| 11:55.08 | Ch3ck | currently working on debugging the -x option for the new push routine |
| 11:55.22 | Ch3ck | then later continue with cleaning up the xpush from the src |
| 11:55.34 | Ch3ck | before getting back to finishing the pull routine.. |
| 11:55.46 | Ch3ck | then as you said i'll take a good look into libbn |
| 11:55.54 | Ch3ck | and see how much improvements i can make. |
| 11:56.09 | Ch3ck | since code base is pretty old actually |
| 11:56.17 | brlcad | we'll see |
| 11:56.43 | brlcad | heh, and 'old' means what? |
| 11:57.14 | Ch3ck | just a way of saying some improvements need to be made thats all |
| 11:57.21 | Ch3ck | :) |
| 11:57.40 | brlcad | age of code never implies that |
| 11:57.45 | brlcad | I gave a talk on that just last week |
| 11:57.56 | brlcad | code can ALWAYS be improved |
| 11:58.02 | Ch3ck | yeah. |
| 11:58.04 | brlcad | and different times merely focus on different issues |
| 11:58.34 | brlcad | I could easily see those functions having a VERY different performance profile 20 years ago |
| 11:58.41 | Ch3ck | well i'll take a look into libbn and try optimising most math routines the best I can |
| 11:58.44 | brlcad | your division operations used to be taboo, for example |
| 11:58.58 | brlcad | they would have killed the performance |
| 11:59.00 | Ch3ck | :) really |
| 11:59.48 | brlcad | what libbn is lacking most is not performance, but validation |
| 11:59.55 | brlcad | a methodical review |
| 12:00.23 | brlcad | to go over each function and ask, "Is this one right?" and then proving it with a unit test |
| 12:00.43 | brlcad | if it can be opitimized during the process, even better |
| 12:00.58 | Ch3ck | ok |
| 12:02.10 | brlcad | Ch3ck: another consideration is platform variability |
| 12:02.16 | starseek1r | brlcad: could that "loop over random matricies" test be worked into a standard template for unit testing libbn? |
| 12:02.23 | brlcad | for example, here are the results from your program on my system: |
| 12:02.31 | brlcad | My implementation: |
| 12:02.32 | brlcad | <PROTECTED> |
| 12:02.32 | brlcad | <PROTECTED> |
| 12:02.32 | brlcad | libbn implementation: |
| 12:02.32 | brlcad | <PROTECTED> |
| 12:02.35 | brlcad | <PROTECTED> |
| 12:03.07 | Ch3ck | ok |
| 12:03.07 | brlcad | that was for determinant, this is for inverse: |
| 12:03.09 | brlcad | My implementation: 560 cycles minimum 560 cycles median |
| 12:03.12 | brlcad | libbn implementation: 532 cycles minimum 672 cycles median |
| 12:04.00 | Ch3ck | So this means when doing the checks I'll have to consider the code running on different platforms right> |
| 12:04.01 | Ch3ck | ? |
| 12:04.09 | brlcad | starseeker: sure, a header even |
| 12:04.51 | brlcad | Ch3ck: well just to be very cautious with anything you assume (i.e., don't assume anything) |
| 12:05.03 | brlcad | ask someone to test it for you |
| 12:05.12 | starseeker | doubt we want it to run for a minute in the unit test context by default, but we could probably make that a parameter to be passed in... |
| 12:05.23 | brlcad | someone not using the same compiler or operating system or (best) hardward |
| 12:05.37 | Ch3ck | yeah thats true.. |
| 12:06.01 | Ch3ck | i'll ask some friends to test on their hardware too.. |
| 12:06.02 | brlcad | starseeker: heh, true .. though what ran for him in a minute ran for me in less than a second |
| 12:06.54 | starseeker | <snort> well, we could aways use the new timer - exercise that at the same time we're testing libbn... |
| 12:06.57 | brlcad | plus the random number generation is included in the wallclock timing, needs to get pulled out |
| 12:07.33 | Ch3ck | well what machine specifications should i check for when i'll want to start the tests.. |
| 12:07.51 | Ch3ck | any way i'll be ready for that. I'll let you know. |
| 12:08.25 | brlcad | Ch3ck: the machine you're sitting at is always a good one to start with |
| 12:08.32 | Ch3ck | ok |
| 12:09.50 | Ch3ck | I've seen the mistake i was making on Gmail |
| 12:10.12 | Ch3ck | discovered the small little icon at the bottom where i can edit and reply as needed |
| 12:10.14 | Ch3ck | thanks |
| 12:11.13 | brlcad | excellent |
| 12:11.21 | brlcad | did you send me that test? |
| 12:11.55 | Ch3ck | sending.. |
| 12:12.17 | Ch3ck | but I had uploaded them and sent to you yesterday. i think |
| 12:14.21 | Ch3ck | should see it now.. |
| 12:16.16 | starseeker | Ch3ck: if you want to integrate libbn tests into our overall testing harness, take a look a how the tests in libbu/tests and libbn/tests are set up - the code you have written to test your matrix functions should be fairly easily adaptable to that framework and could become part of the "standard" unit tests for libbn |
| 12:18.22 | starseeker | robustness testing of libbn functions is of broad benefit to all of BRL-CAD, so if you want to do more work along those lines I'd be all for it |
| 12:19.30 | Ch3ck | ok |
| 12:19.38 | brlcad | hmmm... |
| 12:20.00 | starseeker | for example, you said your matrix code succeeded in some cases where the existing libbn functions did not - those would be excellent candidates for specific tests in libbn unit test definitions for those functions |
| 12:20.01 | brlcad | Ch3ck: i've reworked your cycle timing since I had my doubts about it... |
| 12:20.10 | brlcad | and now I'm getting very different numbers |
| 12:20.15 | Ch3ck | ok better |
| 12:20.16 | brlcad | at least for determinant |
| 12:20.26 | brlcad | it's calculating much slower |
| 12:20.37 | Ch3ck | yeah there was really no big change in the determinant tests compared to the |
| 12:20.41 | Ch3ck | inverse routine |
| 12:20.49 | Ch3ck | so it should not be that surprising. |
| 12:21.05 | brlcad | it's surprising that it's slower ;) |
| 12:21.38 | brlcad | your test loop was completely nearly instantly for me, just a few ms, and this is on a very old laptop |
| 12:21.43 | Ch3ck | yeah i'm surprised that its slower.. |
| 12:21.47 | starseeker | didn't you say for one of those functions you were doing a fully general approach where the libbn function was doing something else? |
| 12:22.01 | starseeker | reads emails... |
| 12:22.24 | brlcad | when I increase the numbers and remove the calculation portions that weren't relevant, it really changes the profile |
| 12:23.05 | Ch3ck | startseeker: I don't think so. |
| 12:23.52 | Ch3ck | brlcad: so what results does it give now.. |
| 12:23.52 | starseeker | ah, I'm thinking about the inverse: "mine does a full 4x4 matrix inverse, and the old libbn one something else" |
| 12:24.01 | Ch3ck | is it slower of faster. |
| 12:29.47 | brlcad | Ch3ck: give me a couple minutes to confirm |
| 12:33.13 | brlcad | need to test in a couple more places as well |
| 12:47.46 | Notify | 03BRL-CAD:phoenixyjll * 56232 brlcad/trunk/src/libbrep/intersect.cpp: Use a struct to represent the overlap segments. Split the curves with the intersection points (with other curves), so that we can get closed regions. |
| 12:55.53 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b112:5514:0:46:bb5:201) | |
| 13:13.20 | Notify | 03BRL-CAD Wiki:195.24.220.16 * 5833 /wiki/User:Izak/GSOC_2013_logs: /* From July 22th to July 27th */ |
| 13:21.42 | Notify | 03BRL-CAD:phoenixyjll * 56233 brlcad/trunk/src/libbrep/intersect.cpp: right might be NULL, causing sub_curve() to crash. Fix this by returning NULL. |
| 13:29.50 | ``Erik | *readreadread* yeah, div used to be ~20x as slow as mult in the way-long-ago (80486dx/80586) |
| 13:31.11 | ``Erik | there's a decent (and very fast) random number generator in libbn, a mersenne twister ripped from old adrt |
| 13:32.50 | ``Erik | *readreadread* for performance testing, one thing I've done in the past is set an alarm and have each call of a function increment a counter... downside is that the slower machines get way less accurate |
| 14:00.00 | Notify | 03BRL-CAD:starseeker * 56234 brlcad/trunk/CMakeLists.txt: Fix Qt compilation enablement logic - the only time to override the user setting is when we can't do what they asked due to system limitations. |
| 14:24.14 | ``Erik | starseeker: is 56234 going to address the dm-qt issue I saw on my ubuntu box, and do I need to blow away my cache? |
| 14:36.24 | Notify | 03BRL-CAD:erikgreenwald * 56235 (brlcad/trunk/include/db5.h brlcad/trunk/include/raytrace.h and 3 others): Apply patch 207 from Izak https://sourceforge.net/p/brlcad/patches/207/ |
| 14:38.19 | ``Erik | they seem to be getting their shit together |
| 14:38.48 | ``Erik | (about time, we're up on the midpoint) |
| 14:57.11 | brlcad | Ch3ck: where's that test e-mail? |
| 14:57.23 | brlcad | or maybe you misunderstood me again |
| 14:57.51 | brlcad | I see you sent me the bn test, but we were not discussing that -- we were discussing your ability to reply to an e-mail and comment on sections |
| 14:58.37 | brlcad | 07:51 < brlcad> I e-mailed you in private yesterday |
| 14:58.38 | brlcad | 07:51 < brlcad> e-mail me back and respond to two separate sentences, delete the rest |
| 15:01.00 | brlcad | I think I have a good grasp on the numbers now, your cpu cycle timer just wasn't very accurate/relevant |
| 15:01.36 | brlcad | your new determinant is clearly a lot slower, your new inverse is clearly a lot faster :) |
| 15:16.59 | brlcad | if anyone else would like to test how your system evaluates, I've uploaded an updated tarball to http://brlcad.org/tmp/bnmatinvdet.tar.gz |
| 15:17.26 | brlcad | you'll have to update the paths in the Makefile so it finds our headers and libs |
| 15:25.39 | brlcad | zero_level: congratulations |
| 15:25.48 | brlcad | and thanks :) |
| 15:27.24 | zero_level | brlcad :you are welcome! But I am not sure what is this about ? |
| 15:36.50 | brlcad | zero_level: see your e-mail |
| 16:16.14 | zero_level | brlcad: :-) |
| 16:17.53 | brlcad | zero_level: so go ahead and make a test commit now just to get that over with, make sure you're set up correctly |
| 16:21.33 | zero_level | brlcad : I am doing a fresh checkout. |
| 16:21.46 | brlcad | didn't need to :) |
| 16:21.50 | zero_level | ok |
| 16:22.38 | zero_level | i did svn status and apparently there are lots of file which are deleted so it shows '?' in front of lot of files |
| 16:22.56 | brlcad | ? means it doesn't know what those files are |
| 16:23.10 | brlcad | files you created directly or indirectly |
| 16:23.36 | zero_level | yes.! all the files which are not under svn |
| 16:24.36 | brlcad | ? files are ignored and will continue to be ignored until you tell svn otherwise |
| 16:24.50 | zero_level | alright! |
| 16:24.51 | brlcad | they're not deleted |
| 16:25.09 | brlcad | if you want to delete them, you can easily with: svn status | xargs rm |
| 16:25.26 | brlcad | of course, assumes you ONLY have ? files |
| 16:25.38 | brlcad | otherwise that'll delete any modified or added as well |
| 16:26.00 | brlcad | if you want to be more safe: svn status | grep '^?' | xargs rm |
| 16:28.22 | zero_level | alright I just ran a script to delete all them |
| 16:28.25 | zero_level | did svn up |
| 16:31.13 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b112:5514:0:46:bb5:201) | |
| 16:33.18 | zero_level | brlcad : I am making the following first commit |
| 16:33.19 | zero_level | - * Functions provided by the LIBICV image conversion library. |
| 16:33.19 | zero_level | + * Functions provided by the LIBICV image processing library. |
| 16:33.29 | zero_level | just wanted to be 100% sure |
| 16:35.22 | starseeker | ``Erik: with any luck that'll avoid building the dm-qt code unless you specifically turn it on - I don't think you'll need to remove your cache |
| 16:38.35 | Ch3ck | brlcad: just came back from a break. I understand what you said now.. |
| 16:43.06 | Notify | 03BRL-CAD:mohitdaga * 56236 brlcad/trunk/include/icv.h: Changing the scope of libicv to be a image processing library. This increases the purview of libicv to contain the image processing APIs. |
| 16:44.39 | ``Erik | zero_level: commit and we will yell at you later :D |
| 16:45.06 | ``Erik | the upside of a decent vcs is we can 'undo' any damage |
| 16:45.07 | zero_level | zero_level : :D |
| 16:45.40 | zero_level | i think in the absence of notify, email is the right place ;) |
| 16:45.45 | zero_level | did it! |
| 16:46.08 | zero_level | ready for your yellings now ;) |
| 16:47.08 | ``Erik | absense of notify? eh? |
| 16:47.40 | zero_level | ops ! didnt notice the notify ! |
| 16:48.01 | zero_level | r56236 it is! |
| 16:51.28 | ``Erik | grats! and work on, just be prepared when you get chewed out a bit for a bad commit and understand that it's not a personal attack, we're merely trying to do the best for the project :) |
| 16:54.04 | zero_level | alright! Thanks :-) |
| 16:54.46 | zero_level | assures everyone. |
| 16:55.33 | zero_level | Also If I will not be certain about a commit I will talk to you here or on the list. |
| 17:02.03 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 5834 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 22 July - 28 July */ |
| 17:04.27 | brlcad | zero_level: so this raises the bar significantly |
| 17:04.46 | brlcad | we'll expect to see LOTS of small frequent commits |
| 17:05.07 | brlcad | throughout the day, basically about as often as you save the file and it compiles cleanly, you should probably be committing |
| 17:05.29 | ``Erik | welcome to the next level :D |
| 17:06.19 | Notify | 03BRL-CAD Wiki:195.24.220.16 * 5835 /wiki/User:Izak/GSOC_2013_logs: /* From July 22th to July 27th */ |
| 17:07.55 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 5836 /wiki/User:Izak/GSOC_2013_logs: /* From July 22th to July 27th */ |
| 17:12.45 | zero_level | brlcad, ``Erik I am thinking to work on using this weekend to commiting the already written codes. |
| 17:28.17 | *** join/#brlcad kesha (~kesha@49.249.191.140) | |
| 18:09.55 | brlcad | zero_level: why not now? :) |
| 18:10.03 | brlcad | kesha: what are you up to? |
| 18:11.35 | zero_level | Iam counting (today) friday in it. |
| 18:12.17 | Ch3ck | brlcad: will check the code. |
| 18:12.19 | zero_level | just working on putting every thing right for the new code i have written. |
| 18:12.44 | zero_level | I mean the first commit regarding the new icv_struct. |
| 18:32.45 | zero_level | starseeker : I want to discuss about r50507 in rt/src/viewedge.c |
| 18:34.02 | zero_level | You seem to have removed icv_save_save_open from viewedge.c |
| 18:34.50 | zero_level | The primrary reason being "It was called in do.c, thus creating a failure" |
| 18:35.32 | zero_level | Do we also remove icv_image_save_close(bif) at L849in viewedge.c |
| 18:36.08 | zero_level | correction// rt/src/viewedge.c // src/rt/viewedge.c |
| 18:44.17 | Ch3ck | brlcad: Fixed the bug hanging in the new push routine |
| 18:45.06 | Ch3ck | but given the given state of the routine it can push only an object at a time but the previous push could push many objects at a time so should and wait till I add this option or I should upload the current patch? |
| 18:50.41 | brlcad | Ch3ck: you should ALWAYS upload a new patch, hasn't this been stated many times already? |
| 18:51.07 | Ch3ck | ok just wanted to make sure i'm doing the right thing. :) |
| 18:51.22 | brlcad | you say the status of the patch in your comment, and do your best to make sure it works as best as you can right NOW |
| 18:53.31 | Ch3ck | thanks. |
| 18:53.35 | Ch3ck | will do. |
| 19:12.37 | *** join/#brlcad vladbogo (~vladbogo@188.25.236.163) | |
| 19:23.11 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 5837 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 22 July - 28 July */ |
| 19:25.39 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 0 /wiki/File:Testing_new_push_routine.png: This shows tests of new push command with -x support |
| 19:27.17 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 5839 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 22 July - 28 July */ |
| 20:02.07 | Notify | 03BRL-CAD Wiki:Vladbogolin * 0 /wiki/File:Tkqt.png: |
| 20:03.58 | Notify | 03BRL-CAD Wiki:Vladbogolin * 5841 /wiki/User:Vladbogolin/GSoC2013/Logs: /* Week 6 */ |
| 20:07.14 | brlcad | kesha: and that we can discuss here |
| 20:07.16 | brlcad | to obtain commit access with brl-cad, you have to make brl-cad patches |
| 20:08.03 | brlcad | remember to always default to open, unless it's a private matter |
| 20:08.20 | Notify | 03BRL-CAD Wiki:Vladbogolin * 0 /wiki/File:Tkqt1.png: |
| 20:08.31 | brlcad | refactoring is one of the best ways to learn, but you have to really put in effort to understand each of the issues you're working on and why |
| 20:09.06 | brlcad | like your question a few weeks ago about why a program wasn't working right, printing a char[] buffer that you only wrote one byte into |
| 20:09.20 | brlcad | but printing lots of characters |
| 20:09.28 | brlcad | kesha: did you ever understand that issue? |
| 20:10.46 | kesha | ya. Later I realized that it was passing the pointer to starting of character array and not just asking for char[0] as I interpreted at that time |
| 20:11.40 | brlcad | and why did it print so much? |
| 20:13.11 | kesha | the buffer got flushed when it encountered end of function/return 0; |
| 20:15.04 | Notify | 03BRL-CAD Wiki:Vladbogolin * 5843 /wiki/User:Vladbogolin/GSoC2013/Logs: /* Week 6 */ |
| 20:15.32 | Notify | 03BRL-CAD Wiki:Vladbogolin * 5844 /wiki/User:Vladbogolin/GSoC2013/Logs: |
| 20:15.51 | kesha | whenever specified field width, it will take input till that field. and consider that string as a pointer to that string |
| 20:16.39 | kesha | Anyways, I get your point of digging up the issue thoroughly |
| 20:17.16 | Notify | 03BRL-CAD Wiki:Vladbogolin * 5845 /wiki/User:Vladbogolin/GSoC2013/Logs: |
| 20:26.03 | brlcad | no |
| 20:27.28 | brlcad | the buffer did not get flushed then, buffering of I/O is independent of most function calls |
| 20:27.54 | brlcad | the question actually has nothing to do with buffering |
| 20:28.09 | brlcad | you told it to print something, and it did |
| 20:28.16 | brlcad | why did it print what it printed? |
| 20:28.34 | brlcad | perhaps first off, what exactly did it print and what did you expect it to print? |
| 20:35.01 | kesha | I had tried about 20-25 different codes and I don't remember which exactly are you talking about? http://paste.kde.org/pa21f9c45/ ? |
| 20:36.03 | Notify | 03BRL-CAD:tbrowder2 * 56237 brlcad/trunk/TODO: remove 2 man pages done |
| 20:37.08 | brlcad | yep, that one has the issue regardless |
| 20:37.15 | Notify | 03BRL-CAD:tbrowder2 * 56238 brlcad/trunk/src/util/dsp_add.c: improve basic usage statement |
| 20:37.56 | brlcad | kesha: so that printf probably prints more than "kesh" I'm better, at least if it's not an unoptimized compile |
| 20:38.11 | brlcad | s/better/betting/ |
| 20:38.43 | kesha | http://paste.kde.org/pf7bb25ed/ I think it was this one |
| 20:40.34 | brlcad | sure, related problem albeit subtle difference |
| 20:41.22 | brlcad | so what's the problem there? |
| 20:43.47 | Notify | 03BRL-CAD:brlcad * 56239 (brlcad/trunk/NEWS brlcad/trunk/TODO): cliff added a -w 'wrapping' option to the comb command in r56221 that will create a child comb under the top level comb and move all contents of the toplevel comb into that sub-comb. the feature pertains to dave's old wrapper script and is in response to numerous user requests. needs to be documented still. |
| 20:45.29 | Notify | 03BRL-CAD:brlcad * 56240 brlcad/trunk/TODO: tcl scripts generate via cmake now and src/other should be vanilla |
| 20:46.53 | kesha | The sscanf line says accept three characters ("%3s") from the input pointer passed as first argument instring, skip in between chars and next integer in c. |
| 20:48.28 | brlcad | so if you ran that program under a different environment, it would potentially crash |
| 20:49.00 | kesha | ya ..on windows gcc compiler I got "t:)" in place of "thi" |
| 20:49.03 | brlcad | but yes, that is basically what sscanf says |
| 20:49.13 | kesha | I tried on windows |
| 20:49.16 | brlcad | so still, what's the problem? |
| 20:49.31 | brlcad | i'm gathering you didn't figure it out? :) |
| 20:49.46 | Notify | 03BRL-CAD:tbrowder2 * 56241 brlcad/trunk/src/util/dsp_add.c: ws cleanup |
| 20:49.52 | brlcad | understanding this is necessary for knowing the proper fix |
| 20:50.47 | brlcad | it's a common C mistake, btw |
| 20:51.33 | brlcad | I can tell you that the error in your understanding is actually spelled out on line 12 |
| 20:57.22 | zero_level | brlcad : I want to ask a naive question. Do we have any script that removes trailing white space ? ;) |
| 20:59.27 | brlcad | kesha: don't fester in confusion .. if you don't know, you can say that after thinking about it and searching for a little bit |
| 20:59.41 | brlcad | I've pointed you to a line, did that help? |
| 20:59.49 | brlcad | zero_level: yes, sh/ws.sh |
| 20:59.59 | brlcad | or get a better editor :) |
| 21:00.28 | brlcad | emacs and vim can both be configured VERY EASILY to display trailing whitespace in bright red |
| 21:00.47 | brlcad | it's worth doing to know where you're dropping turds |
| 21:01.10 | brlcad | if only to not waste other people's time, but it's just a disorderly waste regardless |
| 21:01.26 | kesha | Cant get it. |
| 21:03.34 | brlcad | "scanfBuf is a string with length 1" |
| 21:03.45 | brlcad | that is not correct, why might that be? |
| 21:04.19 | kesha | I tried with printf("%d",sizeof(scanBuf)); and it showd 1 |
| 21:05.23 | brlcad | and that is correct |
| 21:05.42 | brlcad | so then what's wrong |
| 21:05.58 | brlcad | what remains in that statement? |
| 21:06.43 | kesha | "still when ssacnf() has %3s as argument, it accepts and shows "thi" from the instring as output. " |
| 21:07.10 | brlcad | don't get distracted, stick with "scanfBuf is a string with length 1" |
| 21:07.40 | brlcad | you confirmed that scanBuf is length 1 (byte) with sizeof() |
| 21:07.42 | Notify | 03BRL-CAD:vladbogo * 56242 brlcad/trunk/src/libdm/dm-qt.cpp: Sanity checks, ws, log calls |
| 21:07.44 | brlcad | so what remains wrong? |
| 21:08.15 | kesha | string ? |
| 21:08.27 | brlcad | yes |
| 21:08.50 | kesha | string pointer ? |
| 21:08.56 | brlcad | nope |
| 21:10.16 | brlcad | it's not "a string" |
| 21:10.28 | brlcad | what is a C string? |
| 21:10.57 | brlcad | careful googling for that ;) |
| 21:12.22 | brlcad | https://en.wikipedia.org/wiki/C_string |
| 21:13.53 | *** join/#brlcad kesha__ (31f8f459@gateway/web/freenode/ip.49.248.244.89) | |
| 21:14.01 | brlcad | gah |
| 21:14.47 | *** join/#brlcad kesha (~kesha@49.248.244.89) | |
| 21:15.11 | brlcad | kesha: what was the last thing you saw? |
| 21:15.37 | kesha | nope |
| 21:15.45 | brlcad | 17:10 < brlcad> it's not "a string" |
| 21:15.45 | brlcad | 17:10 < brlcad> what is a C string? |
| 21:16.03 | brlcad | and you can read web pages later .. now is time for discussion |
| 21:16.45 | kesha | string - char *c |
| 21:16.57 | brlcad | that is a character pointer |
| 21:17.10 | kesha | and then str(c) |
| 21:17.11 | brlcad | later you should read this: https://en.wikipedia.org/wiki/C_string |
| 21:17.26 | brlcad | notably this statement: The only support for strings in the C programming language itself is that the compiler will translate a quoted string constant into a null-terminated string, which is stored in static memory. |
| 21:17.46 | brlcad | this is at the heart of the misunderstanding: https://en.wikipedia.org/wiki/Null-terminated_string |
| 21:18.00 | brlcad | C strings are merely null-terminated string by convention |
| 21:18.19 | brlcad | your scanBuf is an array of characters |
| 21:18.46 | brlcad | if it's size is 1, it only has enough room to store a nul byte |
| 21:19.08 | brlcad | i.e., it can only ever store "" to be considered a string |
| 21:19.51 | brlcad | hello? |
| 21:19.58 | kesha | ya. so how come printf("%s",scanBuf); |
| 21:20.02 | kesha | gave "this" |
| 21:20.25 | kesha | s/thi/this |
| 21:20.31 | brlcad | well first off, you gave it scanBuf and you told printf that scanBuf is a string |
| 21:20.46 | kesha | hmm |
| 21:20.49 | brlcad | what does %s tell printf to do in terms of bytes? |
| 21:21.24 | kesha | store all bytes till null char is encountered |
| 21:21.35 | brlcad | right |
| 21:21.59 | brlcad | rather, "PRINT all bytes till null char is encountered", right? |
| 21:22.11 | kesha | right |
| 21:22.47 | brlcad | so it reads the first byte, which was not a nul |
| 21:22.59 | brlcad | so it keeps reading bytes that follow |
| 21:23.18 | kesha | hmm, then ? |
| 21:23.20 | brlcad | scanBuf is how big? |
| 21:23.34 | kesha | 1 |
| 21:23.55 | brlcad | so what happens when printf reads the second byte, since the first was not nul? |
| 21:24.28 | kesha | it will look for next |
| 21:24.36 | brlcad | buf scanBuf doesn't have a next |
| 21:25.10 | brlcad | what did it read? |
| 21:25.27 | kesha | 'h' |
| 21:25.36 | brlcad | not the value |
| 21:26.03 | kesha | the second byte of instring |
| 21:26.05 | brlcad | what memory did it read if scanBuf was only 1 byte long |
| 21:26.30 | brlcad | you don't know that |
| 21:26.35 | kesha | addof(scanBuf+1) |
| 21:26.41 | brlcad | better |
| 21:27.02 | brlcad | yes, it just read whatever byte happens to be after scanBuf's memory |
| 21:27.44 | kesha | I was wondering how did it then stop after 3rd |
| 21:27.44 | brlcad | all you know is that it's NOT scanBuf |
| 21:27.51 | brlcad | it's random memory, it could be literally anything |
| 21:27.59 | brlcad | well, when does %s stop? |
| 21:28.21 | kesha | finds NULL |
| 21:28.32 | brlcad | right (sort of) |
| 21:28.39 | brlcad | so it found a nul character |
| 21:29.13 | kesha | but there is still 's' at scanBuf+4 then a NULL |
| 21:29.32 | brlcad | in your case, it just happened to be the case that the next four bytes were 'h', 'i', 's', and '\0' (nul) |
| 21:29.51 | brlcad | or 'h', 'i', '\0' actually |
| 21:30.16 | brlcad | so it got the 't' from scanbuf, then two more bytes, then finally encountered a 0 |
| 21:30.19 | kesha | hmm..yes.. |
| 21:30.27 | brlcad | note that it's not "NULL" .. that means something else |
| 21:30.42 | brlcad | it's a nul character ... a '\0' byte |
| 21:31.39 | kesha | ya .. I know it. |
| 21:32.10 | brlcad | do you really? |
| 21:32.21 | brlcad | shall I query you on what NULL means too? :) |
| 21:33.01 | kesha | '\0'=NULL but was it beacuse of %3s that " 'h', 'i', '\0" |
| 21:33.51 | brlcad | you just said you know it .. so then stop saying '\0' is NULL! ... it's not |
| 21:34.32 | zero_level | NULL = 0 |
| 21:34.38 | brlcad | '\0' is a nul character, there's a difference and it's sometimes important |
| 21:34.49 | brlcad | NULL is not necessarily 0 |
| 21:34.50 | kesha | NULL byte |
| 21:35.29 | brlcad | nul byte |
| 21:35.33 | brlcad | nul != NULL |
| 21:36.08 | zero_level | brlcad : I applied the new icv_struct and changing the functions for commiting |
| 21:36.09 | kesha | I was confused here nul == NULL ! |
| 21:36.37 | brlcad | uhm.. |
| 21:36.38 | zero_level | It turns out to be whooping 900 lines in a patch. |
| 21:36.45 | brlcad | 17:30 < brlcad> note that it's not "NULL" .. that means something else |
| 21:36.46 | brlcad | 17:31 < kesha> ya .. I know it. |
| 21:36.57 | brlcad | kesha: then what was that? :) |
| 21:37.00 | zero_level | Although I can remove 100 lines or so. |
| 21:37.22 | zero_level | but this is really a large one :-) |
| 21:37.32 | zero_level | And dont see a alternative |
| 21:37.50 | kesha | :P |
| 21:37.51 | brlcad | zero_level: okay, just dont' break anything ;) |
| 21:38.00 | zero_level | alright |
| 21:38.15 | brlcad | you should make them as small as possible, even if it means more work for you to do changes incrementally |
| 21:38.23 | brlcad | but that's not always possible |
| 21:38.28 | brlcad | it's far easier to review commits either way |
| 21:38.30 | zero_level | I am not sure about one thing. |
| 21:38.40 | zero_level | Which requires help of starseeker |
| 21:38.49 | brlcad | kesha: it's a fair question -- I can't help you if you tell me you understand when you don't :) |
| 21:38.53 | zero_level | but using my intution there |
| 21:39.09 | brlcad | fortunately you immediately contradicted your understanding ;) |
| 21:39.21 | brlcad | kesha: read this quick: 17:31 < kesha> ya .. I know it. |
| 21:39.23 | brlcad | oops |
| 21:39.27 | brlcad | this: http://faq.cprogramming.com/cgi-bin/smartfaq.cgi?answer=1047589067&id=1043284376 |
| 21:40.29 | brlcad | kesha: SO ... |
| 21:40.43 | brlcad | 17:33 < kesha> '\0'=NULL but was it beacuse of %3s that " 'h', 'i', '\0" <-- YES |
| 21:41.08 | kesha | yes, had it clear now . |
| 21:41.09 | brlcad | you overwrote the scanBuf buffer there, and wrote to memory that was not part of scanBuf |
| 21:41.10 | kesha | :) |
| 21:41.15 | brlcad | classic buffer overflow |
| 21:41.33 | brlcad | once you went 1 byte over, a program might crash, might not |
| 21:41.37 | brlcad | the memory can be anything |
| 21:42.00 | kesha | hmmm |
| 21:42.41 | brlcad | when you pass a buffer or a pointer to any function that expects a "C string", it's assuming you've properly nul terminated the string and has no way of knowing the length (without you telling it) |
| 21:42.59 | brlcad | even functions like strlen() are just going to read until they find a '\0' |
| 21:43.29 | brlcad | think about it some, read those two wikipedia pages |
| 21:43.37 | brlcad | ask questions if you have them |
| 21:43.46 | brlcad | this is an important concept to understand very clearly |
| 21:43.58 | kesha | okay. I will read up webpages. |
| 21:43.59 | brlcad | it's a fundamental tenant of C |
| 21:44.31 | brlcad | probably can find some "C string tutorials" that might help too, write a couple test main() programs until you're confident you understand it |
| 21:45.47 | kesha | if I get some problems, will come again to eat up your head. ;) |
| 21:55.13 | Notify | 03BRL-CAD Wiki:Vladbogolin * 5846 /wiki/User:Vladbogolin/GSoC2013/Logs: |
| 22:15.57 | Notify | 03BRL-CAD:mohitdaga * 56243 (brlcad/trunk/include/icv.h brlcad/trunk/src/libged/screengrab.c and 9 others): Changes the icv library to accomodate double type data. Also changes the existing use of icv in the rt, rmrt, libged |
| 22:28.02 | starseeker | zero_level: hmm? |
| 22:31.23 | Notify | 03BRL-CAD:mohitdaga * 56244 brlcad/trunk/include/icv.h: Added DOXYGEN comments to the tweaked functions |
| 22:32.00 | zero_level | starseeker can u quickly see src/rt/viewedge.c now |
| 22:33.04 | starseeker | what about it? |
| 22:33.35 | zero_level | 14:32 < zero_level> starseeker : I want to discuss about r50507 in rt/src/viewedge.c |
| 22:33.38 | zero_level | 14:34 < zero_level> You seem to have removed icv_save_save_open from viewedge.c |
| 22:33.40 | zero_level | 14:34 < zero_level> The primrary reason being "It was called in do.c, thus creating a failure" |
| 22:33.43 | zero_level | 14:35 < zero_level> Do we also remove icv_image_save_close(bif) at L849in viewedge.c |
| 22:33.46 | zero_level | 14:36 < zero_level> correction// rt/src/viewedge.c // src/rt/viewedge.c |
| 22:33.58 | zero_level | I have removed icv_save_image_close |
| 22:34.10 | zero_level | from viewedge.c |
| 22:34.48 | zero_level | because as per your comment in r50507 u mentioned that opening is handled by do.c |
| 22:34.49 | starseeker | If I recall correctly, I removed the open call from viewedge.c because it was also being invoked in do.c |
| 22:35.04 | zero_level | yeah! exactly. |
| 22:35.07 | starseeker | I don't know that do.c also handles closing |
| 22:35.11 | starseeker | did you look? |
| 22:35.16 | zero_level | yes |
| 22:35.19 | zero_level | it does |
| 22:35.38 | zero_level | check L923 in do.c |
| 22:36.44 | starseeker | so you're wondering if we still need the close call in viewedge.c? Or is that call causing a problem? |
| 22:37.13 | starseeker | ``Erik: do you remember the details of the icv stuf in the rt tools? |
| 22:37.23 | zero_level | I am nt sure how to test viewedge.c |
| 22:37.28 | starseeker | rtedge |
| 22:37.32 | zero_level | Moroever |
| 22:37.34 | starseeker | that's the command that uses it |
| 22:37.53 | zero_level | As per the new api of icv we do it the following way |
| 22:37.58 | zero_level | icv_create(..) |
| 22:38.15 | Notify | 03BRL-CAD:n_reed * 56245 brlcad/trunk/src/libbrep/intersect.cpp: ON_zaxis is obsolete |
| 22:38.24 | starseeker | zero_level: check out the man page for rtedge - that should tell you how to write out to an image |
| 22:38.45 | starseeker | brlman rtedge |
| 22:38.54 | zero_level | do // write line, write pixel// |
| 22:39.00 | zero_level | and icv_save |
| 22:39.43 | starseeker | zero_level: I'm not intimately familiar with the details of how icv is used in the rt tools - your best bet is to test |
| 22:40.17 | zero_level | yes |
| 22:40.44 | zero_level | just working at finding the man details |
| 22:41.09 | starseeker | zero_level: there's a command |
| 22:41.11 | starseeker | brlman |
| 22:41.30 | zero_level | found that |
| 22:41.39 | starseeker | so you can see the man page? |
| 22:42.50 | zero_level | oops Neither man page viewer nor Tk graphics available - man page viewing is not supported. |
| 22:42.53 | zero_level | Neither man page viewer nor Tk graphics available - man page viewing is not supported. |
| 22:42.59 | zero_level | Neither man page viewer nor Tk graphics available - man page viewing is not supported. |
| 22:43.09 | zero_level | sry for repited copying. |
| 22:43.11 | starseeker | blinks - what platform are you on? |
| 22:43.24 | zero_level | linux |
| 22:43.33 | starseeker | does the command "man" work? |
| 22:43.34 | zero_level | flavour=ubuntu |
| 22:43.46 | zero_level | yes |
| 22:44.40 | starseeker | um |
| 22:44.57 | starseeker | the brlman script should work then |
| 22:44.59 | zero_level | downloading tk |
| 22:45.26 | zero_level | rather installing it through synaptic |
| 22:45.40 | starseeker | the message you got is what happens when tcl can't run either "man" or "bwish" |
| 22:47.26 | starseeker | if you're just installing Tk, you'll have to re-compile BRL-CAD with Tk enabled |
| 22:47.56 | zero_level | yeah i am doing that. can u pm me the man of rtedge. In the meanwhile i will try to test this |
| 22:51.20 | starseeker | notes with some surprise that we don't seem to have an online version of our man pages in html... |
| 22:52.37 | starseeker | http://brlcad.org/~starseeker/rtedge.html |
| 22:52.45 | starseeker | use that until you get your compile going |
| 22:54.22 | zero_level | starseeker I have never used rt. I now it doews raytracing but can u help me write a basic command ? |
| 22:54.40 | starseeker | zero_level: are you familiar with how to read man pages? |
| 22:54.53 | zero_level | alright, on to this ;) |
| 22:55.09 | starseeker | the synopsis gives you a basic idea of how to run the command |
| 22:55.48 | zero_level | i am wondering from where can i get a .g file |
| 22:55.55 | starseeker | in the case of rt (or rtedge) you'll need a .g file, the name of the object within that file you want to raytrace, and any options you want to provide (in you case, how to output an image) |
| 22:56.13 | starseeker | the BRL-CAD compilation creates several |
| 22:56.50 | starseeker | they are placed in the directory "share/db" in your build directory |
| 22:57.41 | zero_level | meanwhile even after installing tk the cofig reports says this |
| 22:57.42 | zero_level | Compile Tk ............................: OFF |
| 22:58.09 | starseeker | zero_level: never mind fiddling with that, just pass the option -DENABLE_ALL=ON to cmake |
| 22:58.14 | starseeker | that will build Tk for you |
| 22:59.50 | starseeker | brlcad: interesting - I get this line when doing a moss.g raytrace: |
| 22:59.59 | starseeker | shade_inputs(cone.s) flip N xy=168, 218 ID_TGC surf=1 dot=2.04196e-05 |
| 23:00.27 | starseeker | zero_level: here's a basic rt command to get you started: |
| 23:00.36 | starseeker | ./bin/rt share/db/moss.g all.g |
| 23:01.16 | starseeker | the man page will tell you how to write the image to an output file (what you're looking for to test) rather than having the image show up onscreen |
| 23:05.37 | zero_level | starseeker can u r56243 |
| 23:05.42 | zero_level | ^compile |
| 23:06.09 | starseeker | zero_level: what error are you seeing? |
| 23:07.03 | zero_level | I am not sure but it gave a seg fault |
| 23:07.20 | starseeker | zero_level: compiling the code? |
| 23:07.46 | zero_level | I ran this rtedge -s 1024 -Fnew.pix havoc.g hav |
| 23:08.02 | zero_level | one of the examples there |
| 23:09.36 | starseeker | -Fnew.pix is not correct |
| 23:10.00 | zero_level | compile r56243 |
| 23:10.25 | starseeker | sorry about that... |
| 23:10.31 | starseeker | sees the man page is at fault |
| 23:10.47 | starseeker | try this: rtedge -s 1024 -o new.pix havoc.g havoc |
| 23:12.01 | starseeker | zero_level: ok, something's wrong |
| 23:12.05 | starseeker | give me a minute... |
| 23:12.31 | zero_level | I got an output file new.pix |
| 23:12.40 | zero_level | 1024x1024 dim |
| 23:15.12 | zero_level | it looks like an edge of a helicopter. |
| 23:15.17 | zero_level | did pix-png |
| 23:15.26 | starseeker | that's correct |
| 23:15.34 | starseeker | is still seeing a problem here though |
| 23:16.54 | starseeker | ah, nevermind |
| 23:17.04 | starseeker | zero_level: ok, so you've got it generating an image |
| 23:17.26 | starseeker | now, if you change the .pix file extension to a .png, you should be able to have rtedge directly output a .png file |
| 23:17.32 | starseeker | that will test icv |
| 23:17.39 | zero_level | alright |
| 23:18.15 | zero_level | but i have removed png-save for a while |
| 23:18.26 | zero_level | will be adding in the next revision |
| 23:18.36 | starseeker | zero_level: if you want to test whether it's reaching the icv close function call if you remove it from viewedge.c, you can use gdb and add a break on that function name |
| 23:18.58 | zero_level | ok |
| 23:20.31 | Notify | 03BRL-CAD:starseeker * 56246 brlcad/trunk/doc/docbook/system/man1/en/rtedge.xml: Use -o for a file, not -F |
| 23:20.52 | zero_level | also, since this was able to save new.pix dont u think it has done this in do.c |
| 23:21.10 | zero_level | because i am running this on r56243 |
| 23:21.15 | starseeker | sure, but your question was whether you needed the extra close statement in viewedge.c |
| 23:21.41 | zero_level | so doesn't that answers this ? |
| 23:23.02 | starseeker | no - you need to figure out a) whether the close call in do.c is actually being called (i.e. can you recognize the problem if the close function is *not* called) and b) whether the viewedge.c call is ever needed |
| 23:23.45 | starseeker | I don't know the answer to either, offhand |
| 23:24.14 | starseeker | ``Erik might, but either way that sort of exploration and reading of the code is something you need to learn how to do - it's a never-ending part of working with pre-existing code bases |
| 23:24.49 | zero_level | alright :) |
| 23:25.24 | zero_level | also what was the problem u saw? |
| 23:30.52 | zero_level | I just ask so, that i can improve upon. |