IRC log for #brlcad on 20130802

00:00.51cogitokatbrlcad, 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``Erikhearing rumor that the inner harbor is starting to fill up with bronies O.o
03:29.16Notify03BRL-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.31Notify03BRL-CAD Wiki:Harman052 * 5901 /wiki/User:Harman052/GSoc2013/Logs:
04:56.37Notify03BRL-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.58Notify03BRL-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.39Notify03BRL-CAD:phoenixyjll * 56459 brlcad/trunk/src/libbrep/intersect.cpp: Make sure the results after iterations are inside the domains.
06:49.51Notify03BRL-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.33Notify03BRL-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.05Ch3ck_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``Erikif 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.20Ch3ck_ok I made them to apply independently with no conflicts what so ever
10:28.23Ch3ck_so its ok
10:38.09Izak_brlcad:I am finding difficulties calculating the bounding box of the heart
12:35.01starseekergah - regression tests are broken (rtweight)
12:40.39zero_levelstarseeker : I believe it is not because of ICV :P
12:41.13zero_levelCh3ck notified this few days back.
12:41.50*** join/#brlcad kesha (~kesha@14.139.122.114)
12:44.06starseekergoes hunting
12:55.18zero_levelI was not sure why my shrink routines were not workin while doing a unit test.
12:55.58zero_levelzero level sees there are seg faults in bwshrink (undersample and normal) pixshrink(undersample).
12:56.08zero_levelI am trying to fix them.
12:56.19*** join/#brlcad Ch3ck_ (~Ch3ck@195.24.220.16)
13:04.36starseekerrtweight breakage was introduced in r56243
13:11.44starseekerIzak_: 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.20Izak__starseeker: i don't understand :(
13:15.49Izak__starseeker: I am taking a look at do.c
13:15.56Notify03BRL-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.26zero_levelstarseeker can u paste the error. I am getting this http://paste.kde.org/p58ae57e2/
13:18.04starseekerzero_level: try make regress-weight
13:18.23Notify03BRL-CAD:phoenixyjll * 56463 brlcad/trunk/src/libbrep/intersect.cpp: Fix wrong use of m_a and m_b.
13:18.32zero_levelstill getting same.
13:18.57starseekerIzak__: you should be seeing something about rtweight segfaulting
13:19.15starseekeryou didn't post your full output there
13:19.42starseekerI may not have the cause correct yet, still digging
13:19.50zero_levelalright. Thanks.
13:20.54Notify03BRL-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.07Notify03BRL-CAD:phoenixyjll * 56465 brlcad/trunk/src/libbrep/intersect.cpp: Should be non-strictly in and strictly out.
13:24.15starseekerhuh.  Yeah, that's not it, but it's still something introduced in r56243
13:26.49zero_levelstarseeker can u paste the error.
13:27.25zero_levelIs it the same as the link I gave ?
13:28.00Notify03BRL-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.05Notify03BRL-CAD Wiki:Phoenix * 5903 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 7 */
13:32.39Ch3ck_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.09Ch3ck_which I don't think its really that useful.
13:33.34*** join/#brlcad kesha_ (~kesha@14.139.122.114)
13:34.15starseekerCh3ck_: nah (at least, not a priority).  How are you getting the "valid" poly results to compare to?
13:34.40Ch3ck_yes
13:34.49starseekerGNU Octave, Maxima, ...?
13:35.25Ch3ck_tried extreme cases of known results using online poly calculators
13:35.38Notify03BRL-CAD Wiki:Phoenix * 5904 /wiki/User:Phoenix/GSoc2013/Reports: /* Mid-term summary */
13:35.49starseeker"online poly calculators"?
13:35.51Notify03BRL-CAD Wiki:Phoenix * 5905 /wiki/User:Phoenix/GSoc2013/Reports: /* Mid-term summary */
13:36.00starseekerdid you document which ones in the source code of the tests?
13:36.16Ch3ck_like mathportal.org
13:36.23starseekerimportant for something like this to explain why the control numbers you are testing against are believed to be correct
13:37.01Ch3ck_ok like actually explaining how i get the correct numbers in the source codes?
13:37.11starseekerabsolutely
13:37.41Ch3ck_well did not include that in the source code
13:38.02Ch3ck_but will do the modifications and give a link to the mathportal.org site
13:38.05Ch3ck_is that ok?
13:38.13starseekerif 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.45starseekerthat'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.18starseekerisn't familiar with mathportal... do they say what they are using as their solver engine?
13:39.44starseekerwant to document what solver software is used, not just the web address - a website can change its backend.
13:40.00Ch3ck_yeah.. let me check that.
13:40.12starseekerI.e., are they using Mathematica version 4.1, Matlab 3.2, GNU Octave version 2.3, etc...
13:40.48starseekerand if there *are* differences, need to investigate why
13:41.47Ch3ck_ok will do
13:42.14Ch3ck_so how do i include the documentation in the code? as a comment at the beginning of the file? or what?
13:42.19starseekerIzak__: http://paste.kde.org/peefb18ad/
13:42.25starseekerCh3ck_: that's fine
13:42.51starseekerwhen you encode the "correct" comparison result, add a comment with that definition that documents where it came from
13:43.05Ch3ck_ok
13:44.02starseekerIzak__: that's the crash I'm seeing for rtweight
13:44.59Izak__starseeker: I don't get it. I have not compiled the code I have written yet.
13:46.25starseekerIzak__: 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.41Izak__starseeker: I am building right now. I am not working on these source files now. Maybe some other developer is
14:08.16Notify03BRL-CAD:tbrowder2 * 56467 brlcad/trunk/doc/burst/Make-paper.sh: don't need ps.tmac
14:15.40zero_levelstarseeker : how do u think we can fix this ?
14:16.32Notify03BRL-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.35starseekerzero_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.00zero_levelstrange. It is
14:19.08starseekerzero_level: take a look at it without my fix and see if you can reproduce it
14:19.40zero_levelAfter libicv i want to work on organizing rt.
14:20.09zero_levelIt seems to involve a lot of files.
14:20.20zero_levelI hope it will be interesting to work on it.
14:20.38zero_levelstarseeker : looking at this.
14:26.19zero_levelstarseeker : outputfile is the file where we write images.
14:26.31zero_levelit is the argument in icv_save()
14:26.50Notify03BRL-CAD:starseeker * 56469 brlcad/trunk/src/libged/comb.c: Thank you repository regression test. Use bu_strcmp instead of strcmp
14:36.03Notify03BRL-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.18Notify03BRL-CAD Wiki:Deep bidhare * 0 /wiki/User:Deep_bidhare:
15:02.33starseekerIzak__: sorry, a couple of zero_level's comments got directed to you by mistake
15:02.40Ch3ck_starseeker: checked mathworld and they have given their math solver. should i retry the values with octave? since i have it installed
15:02.49starseekerCh3ck_: sure
15:03.41Ch3ck_then i will have to edit the patches so as to include the references and reference values.
15:04.05starseekerright (regenerate them, don't edit the patch files directly)
15:04.33starseekerzero_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.42Ch3ck_ok
15:05.12starseekerzero_level: was talking about it with ``Erik, and what r56468 did should work
15:05.41starseekerzero_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.20starseekerCh3ck_: hopefully, everybody should agree on the solutions to the equations
15:06.33Ch3ck_ok
15:07.13Ch3ck_just want to verify the values with octave.But my octave keeps giving me this error " libhdf5.so.6"
15:07.27starseekerthat's a library
15:07.29Ch3ck_do you have any idea on how to fix it? :(
15:07.31Ch3ck_yeah
15:07.40Ch3ck_probably a yum command on how to downlaod it.
15:07.41starseekereither need to install hdf5 or rebuild octave
15:07.58Ch3ck_i have installed hdf5 already but
15:08.04Ch3ck_i still get the same msg
15:08.06Notify03BRL-CAD:erikgreenwald * 56471 brlcad/trunk/TODO: add note about rtweight in regress, breakage was observed from a seemingly unrelated modification
15:08.20starseekerwhat distribution?
15:08.26Ch3ck_SL 6
15:08.37Ch3ck_a clone of RHEL
15:09.29starseekerhttp://octave.1599824.n4.nabble.com/Problem-in-3-6-2-on-SL6-with-hdf5-td4631690.html
15:09.34starseekerdoes that help?
15:09.49Ch3ck_checking it out..
15:13.35Notify03BRL-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.09zero_levelstarseeker can u guide me how should I find what made this error .
15:14.14Ch3ck_starseeker: this doesn't help me much.
15:14.29zero_levelA) I have not touched rtweight.c
15:14.51*** join/#brlcad merzo (~merzo@54-12-133-95.pool.ukrtel.net)
15:15.04zero_levelB) I have no clue how changing other rt tool brought in that error.
15:23.43zero_levelinvestigates what was wrong in 56243
15:25.13``Erikheh neat http://www.boredpanda.com/fun-maps-they-didnt-teach-you-in-school/
15:26.07Notify03BRL-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.37starseekerzero_level: yeah, the rt tools are intertwined - they all share a lot of the same source code files.
15:28.11starseekerit looks like viewweight.c was assuming something from the previous image handling behavior, and its assumption is no longer valid.
15:28.59starseekerzero_level: I would suggest running the regress scripts regularly as you're making changes
15:29.33starseekerCh3ck_: installing newer RPMs doesn't help?
15:30.46Ch3ck_well i have the libhdf5.so.7
15:31.07starseekerright, so if there is a newer octave rpm that you can get that uses that version...
15:31.22Ch3ck_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.35Ch3ck_got it already.
15:31.35zero_levelalright.
15:31.45zero_levelJust found the bug.
15:32.26zero_levelSince the new icv api doesnt open the image therefore we dont have anythin in output pointer
15:33.14zero_levelbut starseeker you were quick to identify the error ? How did u do this ?
15:33.21starseekernods. 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.33zero_levelyes.
15:33.44starseekerzero_level: eh?  I just used gdb to see what was segfaulting
15:34.16zero_levelalright. So you ran the whole regress with gdb ?
15:35.06starseekerled me to viewweight.c
15:35.19starseekerjust the rtweight command from regress
15:36.30Notify03BRL-CAD:erikgreenwald * 56474 brlcad/trunk/TODO: nevermind, rtweight is already in regress
15:36.30starseekergdb --args ../bin/rtweight <options> (but without the redirect at the end)
15:36.52starseekerwhen it segfaulted, that let me use the backtrace command bt
15:37.09starseekerwhich showed that the failure was trying to fprintf to outfp
15:37.42starseekerthe 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.27zero_levelgets back to some shrinking...
15:38.32starseekerthat 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.28Ch3ck_starseeker: fixed the problem with octave created the sym links correctly so verifying the values..
15:51.02Notify03BRL-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.20Ch3ck_verifying values and they are returning the correct results as mathforum.org
15:54.37Ch3ck_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.14Notify03BRL-CAD:mohitdaga * 56476 brlcad/trunk/src/util/pixshrink.c: Fix buffer freeing issue.
17:02.07zero_levelhi ``Erik, brlcad : I would like you to see shrink function in both util/pixshrink.c and util/bwshrink.c
17:02.12zero_levelThere are issues here.
17:02.33zero_level* It must do boxcar averaging.
17:04.17*** join/#brlcad kesha_ (~kesha@14.139.122.114)
17:04.32zero_level* but it seems  the function repatedly goes to the same locations and does redundancy. (Thus performs horizontal redundancy.)
17:04.55zero_levelI have two wasy to fix this.
17:06.24zero_levelA remove the box car averaging and do horizontal averaging . (Improves performance by shrink_factor)
17:06.30zero_levelOR
17:07.01zero_levelIntorduce a new buffer.(needs more memory byt performance remains same).
17:07.10*** join/#brlcad kesha_ (~kesha@14.139.122.114)
17:20.59zero_levelalright taking my call.
17:21.21zero_levelDoing it with the 2nd way.
17:25.06*** join/#brlcad kesha__ (~kesha@14.139.122.114)
17:27.11Notify03BRL-CAD Wiki:195.24.220.16 * 5906 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 29 July - 4 August */
17:27.41zero_levelBTW is it mandatory to write the MidTerm Evaluation report in the logs ?
17:27.51Ch3ck_nope
17:27.54zero_levelI am sort of following the regular way.
17:27.58Ch3ck_nahh
17:28.04Ch3ck_have you read the rules?
17:28.09zero_levelwhich?
17:28.23Ch3ck_its a private matter between you and Google-melange
17:28.28Ch3ck_same goes for mentors
17:28.38Ch3ck_but you could still decide to paste it there
17:28.43Ch3ck_its your choice.
17:28.56zero_levelok Carol's mail
17:29.01zero_levelread them.
17:34.17*** join/#brlcad mpictor_ (~mpictor_@2600:1015:b11e:c3ca:0:1:a9a:e801)
17:34.37Ch3ck_what about them?
17:38.32*** join/#brlcad mpictor_ (~mpictor_@2600:1015:b11e:c3ca:0:1:a9a:e801)
17:43.22Notify03BRL-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.43Notify03BRL-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.45Notifyassembly definitions used elsewhere in the tree (see the comb man page for examples.)
17:49.54Notify03BRL-CAD:tbrowder2 * 56479 (brlcad/trunk/doc/burst/Makefile =================================================================== and 29 others): add missing Makefile
17:51.05Notify03BRL-CAD:tbrowder2 * 56480 (brlcad/trunk/doc/burst/Make-paper.sh =================================================================== and 17 others): rename for clarity of intent
17:52.33Notify03BRL-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.16Notify03BRL-CAD:tbrowder2 * 56482 brlcad/trunk/doc/burst/Makefile: reflect changed file names; rename target for clarity
18:00.58Notify03BRL-CAD:tbrowder2 * 56483 (brlcad/trunk/doc/burst/paper.mm =================================================================== and 1016 others): rename main troff source fiel for clarity
18:01.09Notify03BRL-CAD:starseeker * 56484 brlcad/trunk/doc/CMakeLists.txt: Sync doc/CMakeLists.txt file with burst changes
18:03.12Notify03BRL-CAD:tbrowder2 * 56485 (brlcad/trunk/doc/burst/run_doclifter.sh =================================================================== and 7 others): add script for experimenting with doclifter
18:04.34Notify03BRL-CAD:starseeker * 56486 brlcad/trunk/doc/CMakeLists.txt: Nevermind - just ignore the burst directory while work is ongoing.
18:12.25Notify03BRL-CAD:mohitdaga * 56487 brlcad/trunk/src/util/pixshrink.c: Improve Box Average method in shrink function
18:12.39Izak__Well I have already written prep,shot,bbox,print,vshot and curretly on norm
18:14.13Notify03BRL-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.27zero_levelnevermind. This new change doesnot increases memory burden. :-)
18:17.46Ch3ck_ok
18:18.02Ch3ck_updating patches on sf
18:18.41Ch3ck_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.55Notify03BRL-CAD:mohitdaga * 56489 brlcad/trunk/src/util/bwshrink.c: Improve BOX Average in shrink function.
18:54.12starseekerCh3ck_: looking at bn_poly_mul patch - a comment and a question
18:54.31Ch3ck_yes
18:54.39starseekerCh3ck_: question:  why use string comparison between the input and output, as opposed to a numerical comparison?
18:55.09Ch3ck_well guessed it would be easier since the variables are stored on an array
18:55.36Ch3ck_so casting it to a string and comparing string would be easier than actually iterating the array
18:55.58Ch3ck_and comparing each indext of the val.cf[] array
18:56.22Ch3ck_which i think is more efficient algorithmicall
18:56.23Ch3ck_y
18:57.09starseekerOK, I guess I can see that
18:57.16Ch3ck_yeah
18:57.52starseekercomment:  re-read Code Conventions section in HACKING and tell me what you need to change
18:58.38Ch3ck_for the bn_poly_multiply.patch
18:58.48Ch3ck_because thats the one you are to apply
18:59.03Ch3ck_well Sean talked about white spaces
18:59.24Ch3ck_ohh i see
18:59.27starseekerthose too
18:59.31Ch3ck_function definitions are wrong!
18:59.42Ch3ck_don't know why this slipped away
18:59.48Ch3ck_working on it right away
19:00.06starseekerCh3ck_: also, try something for me
19:00.20Ch3ck_yes
19:00.22starseekerchange one number in your "control" input and see if the test fails correctly
19:00.48Ch3ck_ok
19:10.48*** join/#brlcad merzo_ (~merzo@54-12-133-95.pool.ukrtel.net)
19:13.32starseekerTo run just your test, try "make tester_bpoly_multiply && ctest -I 234,234,1"
19:14.01starseekerif 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.14Notify03BRL-CAD:tbrowder2 * 56490 brlcad/trunk/doc/burst/burst.mm: macro P is ignored following macro H
19:16.28starseekerneed 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.01Ch3ck__starseeker: well since my main() function takes void i substituted the values in the poly_init() routine and it failed correctly
19:25.04Ch3ck__is that ok?
19:26.28starseekerso your ctest -I reported failure?
19:26.57starseekerCh3ck__: there's still another thing from Code Conventions that needs to be fixed
19:33.34starseekerCh3ck__: when I change one digit in one of the output numbers and do the following:
19:33.37starseekermake tester_bn_poly_multiply && ctest -I 234,234
19:33.47starseekerthe test still reports success
19:35.01Ch3ck__well my test report failure as expected.
19:35.37Ch3ck__ok
19:35.46starseekerwhat are you changing?
19:36.01Ch3ck__well the main function  takes no argument
19:36.13Ch3ck__so i don 't see how giving arguments change the output withing file
19:36.21starseekeryeah - I'm talking about the c source code where you define the expected numerical outputs
19:36.45Ch3ck__yes
19:36.50Ch3ck__well let me check
19:37.01starseekertry changing output[2].cf[0] = 0;
19:37.12starseekershouldn't it fail?
19:37.27Ch3ck__let me check
19:37.38starseekernot DOES it fail - SHOULDN'T it fail?
19:37.54starseekeroutput would contain an incorrect number
19:38.31Ch3ck__ok let me c
19:39.32Ch3ck__could you please give me the original value for output[2].cf[1]
19:39.46Ch3ck__starseeker?
19:41.23starseekeroutput[2].cf[0] =  61685316;
19:41.36starseekeroh, hang on
19:41.40Ch3ck__yes..
19:41.46starseekeroutput[2].cf[1] = 33552288;
19:42.53Ch3ck__yes
19:43.01Ch3ck__tested and function fails correctly
19:43.04Ch3ck__as expected
19:43.59Ch3ck__starseeker: what about yours?
19:46.30Ch3ck__does not printed output as in the pass case!
19:46.41Ch3ck__any contradictions on your side?
19:47.09starseekerit's passing here no matter what is in output2.cf[0]
19:49.19starseekerCh3ck__: can you paste to the kde.or pastebin what you're seeing?
19:49.45Ch3ck__ok
19:52.45Ch3ck__doing it and getting an error now..
19:52.50Ch3ck__I don't understand..
19:52.53Ch3ck__checking code
19:55.35starseekerCh3ck__: why are you assigning output[1] = bn_Zero_poly ? that's a bn_poly_t, not an integer or float
19:56.06starseekeroh, nevermind
19:56.16Ch3ck__well checking the strings and seeing that its a null string
19:56.27Ch3ck__stored at both outputs thats why its printing correct
19:56.37Ch3ck__will do some further tests on the patch tomorrow.
19:56.50starseekerCh3ck__: ok - something doesn't look right here though
19:56.55Ch3ck__yes..
20:00.11Ch3ck__wanna go get something to eat. been starving since morning
20:00.33Ch3ck__could you please msg me the errors so I could start work on them. thanks :)
20:08.46Notify03BRL-CAD Wiki:IIIzzzaaakkk * 5907 /wiki/User:Izak/GSOC_2013_logs: /* Mid-term Evaluation week */
20:09.19Notify03BRL-CAD Wiki:IIIzzzaaakkk * 5908 /wiki/User:Izak/GSOC_2013_logs: /* Mid-term Evaluation week */
20:19.37starseekerCh3ck: 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.02Notify03BRL-CAD Wiki:Level zero * 5909 /wiki/User:Level_zero/GSOC13/logs: /* Spelling corrections and Organizing in a better way */
20:36.25Notify03BRL-CAD Wiki:Level zero * 5910 /wiki/User:Level_zero/GSOC13/logs: /* Making a different section for pre Coding Period*/
20:37.27zero_levelbrlcad, ``Erik thanks. :)
20:55.21Notify03BRL-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.23Notifyonly under a hidden comb won't show up. May want to add a -f option to allow a truly 'flat' search
20:56.02Notify03BRL-CAD:starseeker * 56492 brlcad/trunk/NEWS: Add ability to see hidden combs in searches with the -a option for search
21:23.27Notify03BRL-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.29Notifyrestrictions by identifying a valid path or search expression term and haulting there - we'll see.
21:45.19Notify03BRL-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.45Notify03BRL-CAD:r_weiss * 56495 brlcad/trunk/src/conv/fast4-g.c: Allow the fast4-g converter to skip blank lines.

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.