| 00:00.51 | cogitokat | brlcad, I just tried what you said and it let me do a swig command without anymore errors, neat! It still isn't creating a proper python module, yet, but at least I can tinker with that now. |
| 00:28.36 | ``Erik | hearing rumor that the inner harbor is starting to fill up with bronies O.o |
| 03:29.16 | Notify | 03BRL-CAD:starseeker * 56457 brlcad/trunk/doc/docbook/system/mann/en/comb.xml: Add examples illustrating the various behaviors of the -l option for comb. |
| 04:48.31 | Notify | 03BRL-CAD Wiki:Harman052 * 5901 /wiki/User:Harman052/GSoc2013/Logs: |
| 04:56.37 | Notify | 03BRL-CAD:phoenixyjll * 56458 (brlcad/trunk/include/brep.h brlcad/trunk/src/libbrep/intersect.cpp): Reuse the surface trees and curve trees during multiple intersections to reduce repeat computation. |
| 05:08.58 | *** join/#brlcad witness__ (uid10044@gateway/web/irccloud.com/x-esmwfsspckywvnea) | |
| 05:08.58 | Notify | 03BRL-CAD Wiki:Harman052 * 5902 /wiki/User:Harman052/GSoc2013/Logs: /* July 01 2013 */ |
| 06:34.18 | *** join/#brlcad caen23_ (~caen23@92.81.193.198) | |
| 06:37.39 | Notify | 03BRL-CAD:phoenixyjll * 56459 brlcad/trunk/src/libbrep/intersect.cpp: Make sure the results after iterations are inside the domains. |
| 06:49.51 | Notify | 03BRL-CAD:mohitdaga * 56460 brlcad/trunk/include/icv.h: Improve comments of routines in operations.c |
| 07:01.41 | *** join/#brlcad witness__ (uid10044@gateway/web/irccloud.com/x-ywdhpckytrlbnxzi) | |
| 08:28.18 | *** join/#brlcad merzo (~merzo@207-17-133-95.pool.ukrtel.net) | |
| 08:30.52 | *** join/#brlcad witness__ (uid10044@gateway/web/irccloud.com/x-xmppilpmofuwgrrd) | |
| 09:22.33 | Notify | 03BRL-CAD:mohitdaga * 56461 brlcad/trunk/include/icv.h: Add comments for stats routines |
| 09:26.35 | *** join/#brlcad Ch3ck_ (~Ch3ck@195.24.220.16) | |
| 09:35.05 | Ch3ck_ | brlcad: starseeker: ``Erik: when creating the code patches for these unit tests should I add them as iterations of each other or as independent patches, whereby one does not depend on another both in application and integration in code? |
| 09:37.11 | *** join/#brlcad Izak_ (~Izak@66-118-151-70.static.sagonet.net) | |
| 09:37.38 | *** join/#brlcad Izak__ (~Izak@195.24.220.16) | |
| 10:21.38 | ``Erik | if the two patches can be applied in either order (no conflicts), then they can be seperate patches... if they conflict in some fashion, then they should be done serially and a note the dependancy in the comments |
| 10:28.20 | Ch3ck_ | ok I made them to apply independently with no conflicts what so ever |
| 10:28.23 | Ch3ck_ | so its ok |
| 10:38.09 | Izak_ | brlcad:I am finding difficulties calculating the bounding box of the heart |
| 12:35.01 | starseeker | gah - regression tests are broken (rtweight) |
| 12:40.39 | zero_level | starseeker : I believe it is not because of ICV :P |
| 12:41.13 | zero_level | Ch3ck notified this few days back. |
| 12:41.50 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 12:44.06 | starseeker | goes hunting |
| 12:55.18 | zero_level | I was not sure why my shrink routines were not workin while doing a unit test. |
| 12:55.58 | zero_level | zero level sees there are seg faults in bwshrink (undersample and normal) pixshrink(undersample). |
| 12:56.08 | zero_level | I am trying to fix them. |
| 12:56.19 | *** join/#brlcad Ch3ck_ (~Ch3ck@195.24.220.16) | |
| 13:04.36 | starseeker | rtweight breakage was introduced in r56243 |
| 13:11.44 | starseeker | Izak_: I think that's why the free logic for the output file didn't live in do.c - the commands using the -o file for image output can get away with that, but the ones using it for text output can't - and do.c is reused by all of them, so it has to be handled on a per-command basis |
| 13:13.20 | Izak__ | starseeker: i don't understand :( |
| 13:15.49 | Izak__ | starseeker: I am taking a look at do.c |
| 13:15.56 | Notify | 03BRL-CAD:phoenixyjll * 56462 brlcad/trunk/src/libbrep/intersect.cpp: When i < 2 and >= 2, the iso-curve is on surface A and surface B respectively. |
| 13:17.26 | zero_level | starseeker can u paste the error. I am getting this http://paste.kde.org/p58ae57e2/ |
| 13:18.04 | starseeker | zero_level: try make regress-weight |
| 13:18.23 | Notify | 03BRL-CAD:phoenixyjll * 56463 brlcad/trunk/src/libbrep/intersect.cpp: Fix wrong use of m_a and m_b. |
| 13:18.32 | zero_level | still getting same. |
| 13:18.57 | starseeker | Izak__: you should be seeing something about rtweight segfaulting |
| 13:19.15 | starseeker | you didn't post your full output there |
| 13:19.42 | starseeker | I may not have the cause correct yet, still digging |
| 13:19.50 | zero_level | alright. Thanks. |
| 13:20.54 | Notify | 03BRL-CAD:phoenixyjll * 56464 brlcad/trunk/src/libbrep/intersect.cpp: Remove the curves that doesn't have shared points on both starting point and end point (it's impossible for them to be a part of the loop) |
| 13:22.07 | Notify | 03BRL-CAD:phoenixyjll * 56465 brlcad/trunk/src/libbrep/intersect.cpp: Should be non-strictly in and strictly out. |
| 13:24.15 | starseeker | huh. Yeah, that's not it, but it's still something introduced in r56243 |
| 13:26.49 | zero_level | starseeker can u paste the error. |
| 13:27.25 | zero_level | Is it the same as the link I gave ? |
| 13:28.00 | Notify | 03BRL-CAD:carlmoore * 56466 (brlcad/trunk/doc/burst/paper.mm brlcad/trunk/doc/burst/screen.tbl and 2 others): fix spellings and remove trailing blanks/tabs |
| 13:32.05 | Notify | 03BRL-CAD Wiki:Phoenix * 5903 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 7 */ |
| 13:32.39 | Ch3ck_ | starseeker: just wrote the unit tests for all the routines in poly.c. So I wish to know if i really need to write unit tests for bn_pr_poly() and bn_pr_roots() routines since they simply just print output? |
| 13:33.09 | Ch3ck_ | which I don't think its really that useful. |
| 13:33.34 | *** join/#brlcad kesha_ (~kesha@14.139.122.114) | |
| 13:34.15 | starseeker | Ch3ck_: nah (at least, not a priority). How are you getting the "valid" poly results to compare to? |
| 13:34.40 | Ch3ck_ | yes |
| 13:34.49 | starseeker | GNU Octave, Maxima, ...? |
| 13:35.25 | Ch3ck_ | tried extreme cases of known results using online poly calculators |
| 13:35.38 | Notify | 03BRL-CAD Wiki:Phoenix * 5904 /wiki/User:Phoenix/GSoc2013/Reports: /* Mid-term summary */ |
| 13:35.49 | starseeker | "online poly calculators"? |
| 13:35.51 | Notify | 03BRL-CAD Wiki:Phoenix * 5905 /wiki/User:Phoenix/GSoc2013/Reports: /* Mid-term summary */ |
| 13:36.00 | starseeker | did you document which ones in the source code of the tests? |
| 13:36.16 | Ch3ck_ | like mathportal.org |
| 13:36.23 | starseeker | important for something like this to explain why the control numbers you are testing against are believed to be correct |
| 13:37.01 | Ch3ck_ | ok like actually explaining how i get the correct numbers in the source codes? |
| 13:37.11 | starseeker | absolutely |
| 13:37.41 | Ch3ck_ | well did not include that in the source code |
| 13:38.02 | Ch3ck_ | but will do the modifications and give a link to the mathportal.org site |
| 13:38.05 | Ch3ck_ | is that ok? |
| 13:38.13 | starseeker | if you use the numbers from our solver to make the control numbers, the unit test just verifies the behavior is consistent from release to release |
| 13:38.45 | starseeker | that's valuable, but as long as you're crafting the tests its also an opportunity to document the correctness of our solver as compared to results from "trusted" sources |
| 13:39.18 | starseeker | isn't familiar with mathportal... do they say what they are using as their solver engine? |
| 13:39.44 | starseeker | want to document what solver software is used, not just the web address - a website can change its backend. |
| 13:40.00 | Ch3ck_ | yeah.. let me check that. |
| 13:40.12 | starseeker | I.e., are they using Mathematica version 4.1, Matlab 3.2, GNU Octave version 2.3, etc... |
| 13:40.48 | starseeker | and if there *are* differences, need to investigate why |
| 13:41.47 | Ch3ck_ | ok will do |
| 13:42.14 | Ch3ck_ | so how do i include the documentation in the code? as a comment at the beginning of the file? or what? |
| 13:42.19 | starseeker | Izak__: http://paste.kde.org/peefb18ad/ |
| 13:42.25 | starseeker | Ch3ck_: that's fine |
| 13:42.51 | starseeker | when you encode the "correct" comparison result, add a comment with that definition that documents where it came from |
| 13:43.05 | Ch3ck_ | ok |
| 13:44.02 | starseeker | Izak__: that's the crash I'm seeing for rtweight |
| 13:44.59 | Izak__ | starseeker: I don't get it. I have not compiled the code I have written yet. |
| 13:46.25 | starseeker | Izak__: backtrace is crashing at viewweight.c:381 when it tries to write to outfp |
| 13:51.34 | *** join/#brlcad Izak_ (~Izak@66-118-151-70.static.sagonet.net) | |
| 13:52.04 | *** join/#brlcad zero_level (~mohit@66-118-151-70.static.sagonet.net) | |
| 13:52.05 | *** join/#brlcad tofu (~sean@66-118-151-70.static.sagonet.net) | |
| 13:52.09 | *** join/#brlcad ejno_ (~ejno@unaffiliated/kazaik) | |
| 13:52.19 | *** join/#brlcad n_reed_ (~molto_cre@66-118-151-70.static.sagonet.net) | |
| 13:56.41 | Izak__ | starseeker: I am building right now. I am not working on these source files now. Maybe some other developer is |
| 14:08.16 | Notify | 03BRL-CAD:tbrowder2 * 56467 brlcad/trunk/doc/burst/Make-paper.sh: don't need ps.tmac |
| 14:15.40 | zero_level | starseeker : how do u think we can fix this ? |
| 14:16.32 | Notify | 03BRL-CAD:starseeker * 56468 brlcad/trunk/src/rt/viewweight.c: Have rtweight handle outfp locally based on the options. Not sure if this is the 'correct' fix given the problem was somehow introduced in r56243 (not sure why yet) but it does seem to make sense and gets regress passing again. |
| 14:18.35 | starseeker | zero_level: need to understand why it suddenly fails in r56243. I've committed a change to get it working, but I don't know if that's the 'correct' fix because I don't know yet what about r56243 originally broke it |
| 14:19.00 | zero_level | strange. It is |
| 14:19.08 | starseeker | zero_level: take a look at it without my fix and see if you can reproduce it |
| 14:19.40 | zero_level | After libicv i want to work on organizing rt. |
| 14:20.09 | zero_level | It seems to involve a lot of files. |
| 14:20.20 | zero_level | I hope it will be interesting to work on it. |
| 14:20.38 | zero_level | starseeker : looking at this. |
| 14:26.19 | zero_level | starseeker : outputfile is the file where we write images. |
| 14:26.31 | zero_level | it is the argument in icv_save() |
| 14:26.50 | Notify | 03BRL-CAD:starseeker * 56469 brlcad/trunk/src/libged/comb.c: Thank you repository regression test. Use bu_strcmp instead of strcmp |
| 14:36.03 | Notify | 03BRL-CAD:starseeker * 56470 brlcad/trunk/doc/CMakeLists.txt: Tell the build system about the burst doc files - not something to install in this form, but still need to be aware that they are there. |
| 14:43.18 | Notify | 03BRL-CAD Wiki:Deep bidhare * 0 /wiki/User:Deep_bidhare: |
| 15:02.33 | starseeker | Izak__: sorry, a couple of zero_level's comments got directed to you by mistake |
| 15:02.40 | Ch3ck_ | starseeker: checked mathworld and they have given their math solver. should i retry the values with octave? since i have it installed |
| 15:02.49 | starseeker | Ch3ck_: sure |
| 15:03.41 | Ch3ck_ | then i will have to edit the patches so as to include the references and reference values. |
| 15:04.05 | starseeker | right (regenerate them, don't edit the patch files directly) |
| 15:04.33 | starseeker | zero_level: I may have already fixed the issue with rtweight - I just want to be sure you understand what was happening and why |
| 15:04.42 | Ch3ck_ | ok |
| 15:05.12 | starseeker | zero_level: was talking about it with ``Erik, and what r56468 did should work |
| 15:05.41 | starseeker | zero_level: but the key when working with the rt tools like this is to be aware of when you might be breaking things |
| 15:06.20 | starseeker | Ch3ck_: hopefully, everybody should agree on the solutions to the equations |
| 15:06.33 | Ch3ck_ | ok |
| 15:07.13 | Ch3ck_ | just want to verify the values with octave.But my octave keeps giving me this error " libhdf5.so.6" |
| 15:07.27 | starseeker | that's a library |
| 15:07.29 | Ch3ck_ | do you have any idea on how to fix it? :( |
| 15:07.31 | Ch3ck_ | yeah |
| 15:07.40 | Ch3ck_ | probably a yum command on how to downlaod it. |
| 15:07.41 | starseeker | either need to install hdf5 or rebuild octave |
| 15:07.58 | Ch3ck_ | i have installed hdf5 already but |
| 15:08.04 | Ch3ck_ | i still get the same msg |
| 15:08.06 | Notify | 03BRL-CAD:erikgreenwald * 56471 brlcad/trunk/TODO: add note about rtweight in regress, breakage was observed from a seemingly unrelated modification |
| 15:08.20 | starseeker | what distribution? |
| 15:08.26 | Ch3ck_ | SL 6 |
| 15:08.37 | Ch3ck_ | a clone of RHEL |
| 15:09.29 | starseeker | http://octave.1599824.n4.nabble.com/Problem-in-3-6-2-on-SL6-with-hdf5-td4631690.html |
| 15:09.34 | starseeker | does that help? |
| 15:09.49 | Ch3ck_ | checking it out.. |
| 15:13.35 | Notify | 03BRL-CAD:carlmoore * 56472 (brlcad/trunk/doc/burst/fb.tbl brlcad/trunk/doc/docbook/system/mann/en/comb.xml and 4 others): fix spellings and grammar |
| 15:14.09 | zero_level | starseeker can u guide me how should I find what made this error . |
| 15:14.14 | Ch3ck_ | starseeker: this doesn't help me much. |
| 15:14.29 | zero_level | A) I have not touched rtweight.c |
| 15:14.51 | *** join/#brlcad merzo (~merzo@54-12-133-95.pool.ukrtel.net) | |
| 15:15.04 | zero_level | B) I have no clue how changing other rt tool brought in that error. |
| 15:23.43 | zero_level | investigates what was wrong in 56243 |
| 15:25.13 | ``Erik | heh neat http://www.boredpanda.com/fun-maps-they-didnt-teach-you-in-school/ |
| 15:26.07 | Notify | 03BRL-CAD:starseeker * 56473 brlcad/trunk/src/gtools/CMakeLists.txt: In order for beset to work with the LOCAL flag (which a recent change rolled in with NO_INSTALL) it needs to have its build target in the beset subdirectory - otherwise, the binary output name conflicts with the directory in the gtools build dir holding the beset information. Should fix the in-src-dir build. |
| 15:27.37 | starseeker | zero_level: yeah, the rt tools are intertwined - they all share a lot of the same source code files. |
| 15:28.11 | starseeker | it looks like viewweight.c was assuming something from the previous image handling behavior, and its assumption is no longer valid. |
| 15:28.59 | starseeker | zero_level: I would suggest running the regress scripts regularly as you're making changes |
| 15:29.33 | starseeker | Ch3ck_: installing newer RPMs doesn't help? |
| 15:30.46 | Ch3ck_ | well i have the libhdf5.so.7 |
| 15:31.07 | starseeker | right, so if there is a newer octave rpm that you can get that uses that version... |
| 15:31.22 | Ch3ck_ | well looking at a solution where which shows i'll have to create a symbolic link or something like that 'ln -s /directory' |
| 15:31.35 | Ch3ck_ | got it already. |
| 15:31.35 | zero_level | alright. |
| 15:31.45 | zero_level | Just found the bug. |
| 15:32.26 | zero_level | Since the new icv api doesnt open the image therefore we dont have anythin in output pointer |
| 15:33.14 | zero_level | but starseeker you were quick to identify the error ? How did u do this ? |
| 15:33.21 | starseeker | nods. Figured it was something like that. That's probably OK, actually, since now rtweight fopens with just 'w' rather than the binary output |
| 15:33.33 | zero_level | yes. |
| 15:33.44 | starseeker | zero_level: eh? I just used gdb to see what was segfaulting |
| 15:34.16 | zero_level | alright. So you ran the whole regress with gdb ? |
| 15:35.06 | starseeker | led me to viewweight.c |
| 15:35.19 | starseeker | just the rtweight command from regress |
| 15:36.30 | Notify | 03BRL-CAD:erikgreenwald * 56474 brlcad/trunk/TODO: nevermind, rtweight is already in regress |
| 15:36.30 | starseeker | gdb --args ../bin/rtweight <options> (but without the redirect at the end) |
| 15:36.52 | starseeker | when it segfaulted, that let me use the backtrace command bt |
| 15:37.09 | starseeker | which showed that the failure was trying to fprintf to outfp |
| 15:37.42 | starseeker | the most logical reason for that to fail was outfp never got opened. Then the challenge was to figure out where it *should* have been opened |
| 15:38.27 | zero_level | gets back to some shrinking... |
| 15:38.32 | starseeker | that was the time consuming part. Eventually concluded that it made sense for viewweight.c to take care of it locally, since binary and ascii write modes are different anyway |
| 15:42.28 | Ch3ck_ | starseeker: fixed the problem with octave created the sym links correctly so verifying the values.. |
| 15:51.02 | Notify | 03BRL-CAD:mohitdaga * 56475 brlcad/trunk/src/util/bwshrink.c: Remove unwanted bu_free |
| 15:53.57 | *** join/#brlcad kesha_ (~kesha@14.139.122.114) | |
| 15:54.20 | Ch3ck_ | verifying values and they are returning the correct results as mathforum.org |
| 15:54.37 | Ch3ck_ | modifying patches to resubmit on sourceforge. |
| 15:54.52 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b11e:c3ca:0:1:a9a:e801) | |
| 16:42.19 | *** join/#brlcad vladbogo (~vladbogo@188.25.239.5) | |
| 17:01.14 | Notify | 03BRL-CAD:mohitdaga * 56476 brlcad/trunk/src/util/pixshrink.c: Fix buffer freeing issue. |
| 17:02.07 | zero_level | hi ``Erik, brlcad : I would like you to see shrink function in both util/pixshrink.c and util/bwshrink.c |
| 17:02.12 | zero_level | There are issues here. |
| 17:02.33 | zero_level | * It must do boxcar averaging. |
| 17:04.17 | *** join/#brlcad kesha_ (~kesha@14.139.122.114) | |
| 17:04.32 | zero_level | * but it seems the function repatedly goes to the same locations and does redundancy. (Thus performs horizontal redundancy.) |
| 17:04.55 | zero_level | I have two wasy to fix this. |
| 17:06.24 | zero_level | A remove the box car averaging and do horizontal averaging . (Improves performance by shrink_factor) |
| 17:06.30 | zero_level | OR |
| 17:07.01 | zero_level | Intorduce a new buffer.(needs more memory byt performance remains same). |
| 17:07.10 | *** join/#brlcad kesha_ (~kesha@14.139.122.114) | |
| 17:20.59 | zero_level | alright taking my call. |
| 17:21.21 | zero_level | Doing it with the 2nd way. |
| 17:25.06 | *** join/#brlcad kesha__ (~kesha@14.139.122.114) | |
| 17:27.11 | Notify | 03BRL-CAD Wiki:195.24.220.16 * 5906 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 29 July - 4 August */ |
| 17:27.41 | zero_level | BTW is it mandatory to write the MidTerm Evaluation report in the logs ? |
| 17:27.51 | Ch3ck_ | nope |
| 17:27.54 | zero_level | I am sort of following the regular way. |
| 17:27.58 | Ch3ck_ | nahh |
| 17:28.04 | Ch3ck_ | have you read the rules? |
| 17:28.09 | zero_level | which? |
| 17:28.23 | Ch3ck_ | its a private matter between you and Google-melange |
| 17:28.28 | Ch3ck_ | same goes for mentors |
| 17:28.38 | Ch3ck_ | but you could still decide to paste it there |
| 17:28.43 | Ch3ck_ | its your choice. |
| 17:28.56 | zero_level | ok Carol's mail |
| 17:29.01 | zero_level | read them. |
| 17:34.17 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b11e:c3ca:0:1:a9a:e801) | |
| 17:34.37 | Ch3ck_ | what about them? |
| 17:38.32 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b11e:c3ca:0:1:a9a:e801) | |
| 17:43.22 | Notify | 03BRL-CAD:starseeker * 56477 (brlcad/trunk/NEWS brlcad/trunk/src/libged/gqa.c): Per user request, have gqa include information about what grid size is being used, rather than simply reporting 'empty' or 'Summary' |
| 17:49.00 | *** join/#brlcad avneet (~avneet@202.164.53.122) | |
| 17:49.43 | Notify | 03BRL-CAD:starseeker * 56478 brlcad/trunk/NEWS: Added -l option to comb command that 'lifts' the region flag to the top level comb and clears all region flags in the tree below that comb. Has some advanced features, like automatically wrapping regions that are used elsewhere in the .g file and referencing the comb created by the wrap, and refusing to perform the operation if it cannot be done without changing |
| 17:49.45 | Notify | assembly definitions used elsewhere in the tree (see the comb man page for examples.) |
| 17:49.54 | Notify | 03BRL-CAD:tbrowder2 * 56479 (brlcad/trunk/doc/burst/Makefile =================================================================== and 29 others): add missing Makefile |
| 17:51.05 | Notify | 03BRL-CAD:tbrowder2 * 56480 (brlcad/trunk/doc/burst/Make-paper.sh =================================================================== and 17 others): rename for clarity of intent |
| 17:52.33 | Notify | 03BRL-CAD:tbrowder2 * 56481 brlcad/trunk/doc/burst/Makefile: add a couple of more files for cleaning |
| 17:53.34 | *** join/#brlcad kesha__ (~kesha@14.139.122.114) | |
| 18:00.16 | Notify | 03BRL-CAD:tbrowder2 * 56482 brlcad/trunk/doc/burst/Makefile: reflect changed file names; rename target for clarity |
| 18:00.58 | Notify | 03BRL-CAD:tbrowder2 * 56483 (brlcad/trunk/doc/burst/paper.mm =================================================================== and 1016 others): rename main troff source fiel for clarity |
| 18:01.09 | Notify | 03BRL-CAD:starseeker * 56484 brlcad/trunk/doc/CMakeLists.txt: Sync doc/CMakeLists.txt file with burst changes |
| 18:03.12 | Notify | 03BRL-CAD:tbrowder2 * 56485 (brlcad/trunk/doc/burst/run_doclifter.sh =================================================================== and 7 others): add script for experimenting with doclifter |
| 18:04.34 | Notify | 03BRL-CAD:starseeker * 56486 brlcad/trunk/doc/CMakeLists.txt: Nevermind - just ignore the burst directory while work is ongoing. |
| 18:12.25 | Notify | 03BRL-CAD:mohitdaga * 56487 brlcad/trunk/src/util/pixshrink.c: Improve Box Average method in shrink function |
| 18:12.39 | Izak__ | Well I have already written prep,shot,bbox,print,vshot and curretly on norm |
| 18:14.13 | Notify | 03BRL-CAD:mohitdaga * 56488 (brlcad/trunk/src/util/dunncolor.c brlcad/trunk/src/util/dunnsnap.c brlcad/trunk/src/util/pixshrink.c): trailing ws |
| 18:15.27 | zero_level | nevermind. This new change doesnot increases memory burden. :-) |
| 18:17.46 | Ch3ck_ | ok |
| 18:18.02 | Ch3ck_ | updating patches on sf |
| 18:18.41 | Ch3ck_ | starseeker: I have modified all the patches I submitted to make sure the reference value was from Octave. Waiting on your review. |
| 18:24.49 | *** join/#brlcad kesha__ (~kesha@14.139.122.114) | |
| 18:29.55 | Notify | 03BRL-CAD:mohitdaga * 56489 brlcad/trunk/src/util/bwshrink.c: Improve BOX Average in shrink function. |
| 18:54.12 | starseeker | Ch3ck_: looking at bn_poly_mul patch - a comment and a question |
| 18:54.31 | Ch3ck_ | yes |
| 18:54.39 | starseeker | Ch3ck_: question: why use string comparison between the input and output, as opposed to a numerical comparison? |
| 18:55.09 | Ch3ck_ | well guessed it would be easier since the variables are stored on an array |
| 18:55.36 | Ch3ck_ | so casting it to a string and comparing string would be easier than actually iterating the array |
| 18:55.58 | Ch3ck_ | and comparing each indext of the val.cf[] array |
| 18:56.22 | Ch3ck_ | which i think is more efficient algorithmicall |
| 18:56.23 | Ch3ck_ | y |
| 18:57.09 | starseeker | OK, I guess I can see that |
| 18:57.16 | Ch3ck_ | yeah |
| 18:57.52 | starseeker | comment: re-read Code Conventions section in HACKING and tell me what you need to change |
| 18:58.38 | Ch3ck_ | for the bn_poly_multiply.patch |
| 18:58.48 | Ch3ck_ | because thats the one you are to apply |
| 18:59.03 | Ch3ck_ | well Sean talked about white spaces |
| 18:59.24 | Ch3ck_ | ohh i see |
| 18:59.27 | starseeker | those too |
| 18:59.31 | Ch3ck_ | function definitions are wrong! |
| 18:59.42 | Ch3ck_ | don't know why this slipped away |
| 18:59.48 | Ch3ck_ | working on it right away |
| 19:00.06 | starseeker | Ch3ck_: also, try something for me |
| 19:00.20 | Ch3ck_ | yes |
| 19:00.22 | starseeker | change one number in your "control" input and see if the test fails correctly |
| 19:00.48 | Ch3ck_ | ok |
| 19:10.48 | *** join/#brlcad merzo_ (~merzo@54-12-133-95.pool.ukrtel.net) | |
| 19:13.32 | starseeker | To run just your test, try "make tester_bpoly_multiply && ctest -I 234,234,1" |
| 19:14.01 | starseeker | if 234 isn't the right number, run "make test" once and look for your poly test in the output - that'll tell you the number to use |
| 19:16.14 | Notify | 03BRL-CAD:tbrowder2 * 56490 brlcad/trunk/doc/burst/burst.mm: macro P is ignored following macro H |
| 19:16.28 | starseeker | need to verify that your test both fails when expected and succeeds when expected |
| 19:18.11 | *** join/#brlcad Ch3ck__ (~Ch3ck@195.24.220.16) | |
| 19:19.32 | *** join/#brlcad kesha__ (~kesha@14.139.122.114) | |
| 19:24.25 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 19:25.01 | Ch3ck__ | starseeker: well since my main() function takes void i substituted the values in the poly_init() routine and it failed correctly |
| 19:25.04 | Ch3ck__ | is that ok? |
| 19:26.28 | starseeker | so your ctest -I reported failure? |
| 19:26.57 | starseeker | Ch3ck__: there's still another thing from Code Conventions that needs to be fixed |
| 19:33.34 | starseeker | Ch3ck__: when I change one digit in one of the output numbers and do the following: |
| 19:33.37 | starseeker | make tester_bn_poly_multiply && ctest -I 234,234 |
| 19:33.47 | starseeker | the test still reports success |
| 19:35.01 | Ch3ck__ | well my test report failure as expected. |
| 19:35.37 | Ch3ck__ | ok |
| 19:35.46 | starseeker | what are you changing? |
| 19:36.01 | Ch3ck__ | well the main function takes no argument |
| 19:36.13 | Ch3ck__ | so i don 't see how giving arguments change the output withing file |
| 19:36.21 | starseeker | yeah - I'm talking about the c source code where you define the expected numerical outputs |
| 19:36.45 | Ch3ck__ | yes |
| 19:36.50 | Ch3ck__ | well let me check |
| 19:37.01 | starseeker | try changing output[2].cf[0] = 0; |
| 19:37.12 | starseeker | shouldn't it fail? |
| 19:37.27 | Ch3ck__ | let me check |
| 19:37.38 | starseeker | not DOES it fail - SHOULDN'T it fail? |
| 19:37.54 | starseeker | output would contain an incorrect number |
| 19:38.31 | Ch3ck__ | ok let me c |
| 19:39.32 | Ch3ck__ | could you please give me the original value for output[2].cf[1] |
| 19:39.46 | Ch3ck__ | starseeker? |
| 19:41.23 | starseeker | output[2].cf[0] = 61685316; |
| 19:41.36 | starseeker | oh, hang on |
| 19:41.40 | Ch3ck__ | yes.. |
| 19:41.46 | starseeker | output[2].cf[1] = 33552288; |
| 19:42.53 | Ch3ck__ | yes |
| 19:43.01 | Ch3ck__ | tested and function fails correctly |
| 19:43.04 | Ch3ck__ | as expected |
| 19:43.59 | Ch3ck__ | starseeker: what about yours? |
| 19:46.30 | Ch3ck__ | does not printed output as in the pass case! |
| 19:46.41 | Ch3ck__ | any contradictions on your side? |
| 19:47.09 | starseeker | it's passing here no matter what is in output2.cf[0] |
| 19:49.19 | starseeker | Ch3ck__: can you paste to the kde.or pastebin what you're seeing? |
| 19:49.45 | Ch3ck__ | ok |
| 19:52.45 | Ch3ck__ | doing it and getting an error now.. |
| 19:52.50 | Ch3ck__ | I don't understand.. |
| 19:52.53 | Ch3ck__ | checking code |
| 19:55.35 | starseeker | Ch3ck__: why are you assigning output[1] = bn_Zero_poly ? that's a bn_poly_t, not an integer or float |
| 19:56.06 | starseeker | oh, nevermind |
| 19:56.16 | Ch3ck__ | well checking the strings and seeing that its a null string |
| 19:56.27 | Ch3ck__ | stored at both outputs thats why its printing correct |
| 19:56.37 | Ch3ck__ | will do some further tests on the patch tomorrow. |
| 19:56.50 | starseeker | Ch3ck__: ok - something doesn't look right here though |
| 19:56.55 | Ch3ck__ | yes.. |
| 20:00.11 | Ch3ck__ | wanna go get something to eat. been starving since morning |
| 20:00.33 | Ch3ck__ | could you please msg me the errors so I could start work on them. thanks :) |
| 20:08.46 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 5907 /wiki/User:Izak/GSOC_2013_logs: /* Mid-term Evaluation week */ |
| 20:09.19 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 5908 /wiki/User:Izak/GSOC_2013_logs: /* Mid-term Evaluation week */ |
| 20:19.37 | starseeker | Ch3ck: it's not even compile or test errors - I'm not convinced the setup is correct at all. Start by printing out our poly solver's results and visually comparing them to the Octave numbers. If those look close, then you know you're calling the solver correctly and can build up from there |
| 20:34.02 | Notify | 03BRL-CAD Wiki:Level zero * 5909 /wiki/User:Level_zero/GSOC13/logs: /* Spelling corrections and Organizing in a better way */ |
| 20:36.25 | Notify | 03BRL-CAD Wiki:Level zero * 5910 /wiki/User:Level_zero/GSOC13/logs: /* Making a different section for pre Coding Period*/ |
| 20:37.27 | zero_level | brlcad, ``Erik thanks. :) |
| 20:55.21 | Notify | 03BRL-CAD:starseeker * 56491 (brlcad/trunk/src/libged/search.c brlcad/trunk/src/librt/search.c): Preparing to remove dbfind, add -a and -h/-? options for search. The latter are the standard help options, and the former allows search to look at hidden combs. Still don't offer exactly the same functionality as dbfind with the -a option - because search always does a full pathc search under the hood, combs that exist |
| 20:55.23 | Notify | only under a hidden comb won't show up. May want to add a -f option to allow a truly 'flat' search |
| 20:56.02 | Notify | 03BRL-CAD:starseeker * 56492 brlcad/trunk/NEWS: Add ability to see hidden combs in searches with the -a option for search |
| 21:23.27 | Notify | 03BRL-CAD:starseeker * 56493 brlcad/trunk/src/libged/search.c: Ah, right. Because search expressions run the risk of looking like options, we need to constrain the bu_getopt search to the front of the argv string. Do one pass to count the maximum possible number of options. Then, do a second pass and make sure that anything counted as an option is in the front of the argv array. May have to impose even stronger |
| 21:23.29 | Notify | restrictions by identifying a valid path or search expression term and haulting there - we'll see. |
| 21:45.19 | Notify | 03BRL-CAD:starseeker * 56494 brlcad/trunk/src/libged/search.c: Don't need to bother with multiple bu_getopt calls, and for the purpose here that's not ideal anyway. Just loop until we hit something that isn't a flag. |
| 22:06.45 | Notify | 03BRL-CAD:r_weiss * 56495 brlcad/trunk/src/conv/fast4-g.c: Allow the fast4-g converter to skip blank lines. |