IRC log for #brlcad on 20130822

02:06.15Notify03BRL-CAD:starseeker * 57049 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: FreeCAD doesn't yet import our step file, since we have no shape definition. Start listing out what we will need for one of those.
02:29.32Notify03BRL-CAD:starseeker * 57050 (brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake brlcad/trunk/misc/CMake/FindTERMLIB.cmake brlcad/trunk/misc/pkgconfig/CMakeLists.txt): We don't appear to need the RESOLVE_LIBRARIES macro
02:42.28Notify03BRL-CAD:starseeker * 57051 (brlcad/trunk/src/other/incrTcl/itcl/CMake/CheckSystemFunctionality.cmake brlcad/trunk/src/other/incrTcl/itcl/CMake/ac_std_funcs.cmake and 19 others): Remove ResolveCompilerPaths from src/other CMake as well.
03:30.50Notify03BRL-CAD:phoenixyjll * 57052 brlcad/trunk/src/libbrep/boolean.cpp: Simplify the code to output IsValid() information.
03:43.39Notify03BRL-CAD:phoenixyjll * 57053 brlcad/trunk/src/libbrep/boolean.cpp: Don't use explicit dynamic memory allocation for curvesarray, in case that we forget to delete it. Use ON_ClassArray instead.
03:48.29brlcadCh3ck: on modern linux systems, you also need to specify --rpath=/path/to/lib
03:48.40brlcadso that it knows where to look for the libraries at runtime
03:50.35brlcadn_reed: narrowed in on the ohloh problem, I found where in their code it's hanging, and have at least one terrible-but-better-than-nothing solution already
03:50.38brlcadlooking into another
03:50.46Notify03BRL-CAD:phoenixyjll * 57054 brlcad/trunk/src/libbrep/boolean.cpp: Rename the members in TrimmedFace with "m_" prefix for consistency.
03:57.13Notify03BRL-CAD:phoenixyjll * 57055 brlcad/trunk/src/libbrep/boolean.cpp: Swap start & end if start > end.
04:27.41Notify03BRL-CAD:phoenixyjll * 57056 brlcad/trunk/src/libbrep/boolean.cpp: Rename shadowed variable.
05:52.26*** join/#brlcad caen23_ (~caen23@92.83.164.173)
07:39.18*** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net)
07:53.23*** join/#brlcad kesha (~kesha@14.139.122.114)
07:56.20*** join/#brlcad vladbogo (~vladbogo@188.25.238.69)
09:01.02Notify03BRL-CAD:phoenixyjll * 57057 brlcad/trunk/src/libbrep/boolean.cpp: Keep the information of the usage of SSI curve, so that we can know the connection between two trimmed faces (split from two surfaces), and get the connectivity graph of the new geometry after boolean evaluation.
10:05.08Ch3ckfacing a problem with the l command whereby suppling an l command with no object "seg fault(mged dumped)" error is this how its supposed work..
10:06.21Notify03BRL-CAD:iiizzzaaakkk * 57058 brlcad/trunk/src/librt/primitives/superell/superell.c: Modifying a comment by punctuating the word primitive
10:52.24*** join/#brlcad caen23 (~caen23@92.83.164.173)
10:55.55Notify03BRL-CAD:starseeker * 57059 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: List out the C++ structs we'll need to populate and link up for shape definition
10:56.37starseekerhuh:  http://www.gecode.org/doc-latest/reference/group__TaskModelIntGeoPacking.html
10:58.42Notify03BRL-CAD:vladbogo * 57060 brlcad/trunk/src/libdm/dm-qt.cpp: Check if Qpainter is null in drawVList and changed log position.
11:03.53Notify03BRL-CAD:vladbogo * 57061 brlcad/trunk/src/libtclcad/tclcad_obj.c: Added the Qt display manager as a valid dm.
11:27.59Izak_brlcad:please can you explain to me what RT_GET_SEG(segp, ap->a_resource) and the code after it at the end of rt_???_shot() does ?
11:28.19Izak_brlcad: I don't understand that portion
11:42.35Ch3ckbrlcad: did that successfully everthing now works :)
12:02.10*** join/#brlcad mpictor_ (~mpictor_@2600:1015:b116:74eb:0:48:3095:3101)
12:27.45*** join/#brlcad Izak__ (~Izak@195.24.220.16)
12:28.01Izak__Ch3ck: What about the test?
12:30.40Ch3ckworking on it
12:45.45``ErikIzak__: RT_GET_SEG() allocates a segment (using a pool allocator for performance, not just malloc()) that gets the hit information (inhit, outhit, soltab) put in it
12:46.24Izak__``Erik: Don't follow :(
12:47.46``Erikwhen a ray is fired against a primitive, the intersection information has to be saved somehow for the boolean evaluator to process... a primitive can have multiple intersections, so a list of 'segments' holds all that information
12:49.38``ErikRT_GET_SEG(segp, app.resource); is sorta kinda like a fast version of segp = (struct segment *)malloc(sizeof(struct segment));
12:53.00Izak__``Erik: When generating the sextic polynomial, must I gradually build the equation up like in the tor primitive?
12:55.49``Erikassembling and solving the polynomial is the part where you're the expert, dude :D I think brlcad mentioned that the root solver that tor uses could be extended to handle the hrt primitive, but was not capable as it stands now?
13:02.02Izak__Well, I calculated the coefficients of the equation generated when the ray intersects the heart and proceeded
13:04.14Izak__``Erik: rt_hrt_shot() compiled but running the 'rt' command in the mged/archer interface gives me a message ending with "Raytrace failed". You can view the tr_hrt_shot() code here http://paste.kde.org/p425b3f28/
13:05.18``Erik(if it compiles, you might as well commit it, the primitive is not "official" yet so not working quite right isn't the end of the world)
13:07.06Izak__``Erik: Have you looked at the code already ?
13:07.26``ErikI'm looking at it, but it lacks the markup I'm used to :D
13:08.26Izak__Which markup is that ?
13:08.40``Erikthe color highlighting and code folding in vim
13:08.47Izak__ok
13:09.40``ErikI think your return values might be off, I think it might want the number of segments, not the number of intersection points
13:10.18``Erikno, my bad, it's the number of intersect points, you're right
13:10.39Izak__``Erik:This one has the highlighting and betterhttp://paste.kde.org/pda00a9e3/
13:10.43``ErikI don't know why it'd fail O.o maybe add some printf or bu_log statements to see what the code is doing?
13:11.19Izak__I'll do that
13:11.59Izak__Then I'll also try to build the sextic equation gradually like the tor as brlcad: proposed
13:12.16Ch3ckbrlcad: http://paste.kde.org/p41996ae7/ here is my test for pull_comb() routine. i'm unable to read object.
13:12.45Ch3ckand actually moving throught tree using the goblet.g object
13:12.53Izak__hope ``Erik is looking at the better syntax-highlighted shot()
13:15.38``Erikhm, fwiw, the default: label in a switch statement is usually at the end, but that shouldn't be the cause of the failure...
13:18.15``ErikI'd also suggest removing the register keyword, it should be completely ignored on i386/x86_64 with a relatively modern compiler
13:19.29Izak__``Erik: You mean removing the keyword from the entire routine ?
13:19.40``Erik:%s/register //g
13:20.07``Erik"register int i;" should just be "int i;"
13:20.48Izak__wondering what %s/register //g means
13:21.06``Erikvim command to globally replace any instance of "register " with ""
13:21.19Izak__using emacs
13:21.29``Eriklike "sed 's/register //g'"
13:22.14Izak__``Erik: You are really geeked up. I'm sure you think in 0s and 1s :)
13:23.05``ErikI felt for bender in the futurama episode where he had a nightmare... "one one zero one zero zero one TWO???"
13:24.37Izak__For now, I'll commit rt_hrt_shot with the register keyword in it
13:26.25Notify03BRL-CAD Wiki:Phoenix * 6019 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 10 */
13:26.38Notify03BRL-CAD:carlmoore * 57062 (brlcad/trunk/src/libbrep/boolean.cpp brlcad/trunk/src/librt/primitives/hrt/hrt.c): fix spelling and remove trailing blanks
13:36.45Izak__carlmoore:What have you done ?
13:39.34Izak__``Erik: Have you been able to view the last commit ?
13:39.57Izak__sf,net says "no more commits"
13:40.46Notify03BRL-CAD Wiki:IIIzzzaaakkk * 6020 /wiki/User:Izak/GSOC_2013_logs: /* August 19th to August 24th */
13:41.06Izak__hungry
13:43.49Notify03BRL-CAD:tbrowder2 * 57063 brlcad/trunk/src/util/dsp_add.c: add note about wiki
13:51.47Notify03BRL-CAD:tbrowder2 * 57064 (brlcad/trunk/doc/docbook/system/man5/en/CMakeLists.txt brlcad/trunk/doc/docbook/system/mann/en/attr.xml brlcad/trunk/include/raytrace.h): rename gattributes to attributes as file name and references to the man page
13:53.17``ErikIzak__: I don't think your commit worked (perhaps a conflict stopped it?). the last commit to hrt.c from you was 23 hours ago
14:44.49Notify03BRL-CAD:brlcad * 57065 brlcad/trunk/NEWS: tom renamed the 'gattributes' man page to just 'attributes' so it's easier to find. the page describes our v5 attribute system.
15:11.34*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
15:21.42Notify03BRL-CAD:carlmoore * 57066 brlcad/trunk/src/conv/nmg/g-nmg.c: remove a set of braces, and a mistakenly-inserted brace is changed to bracket in Usage statement
15:22.50jordisayolhello. Can I set archer as default application for brlcad mime types on Linux?
15:35.37brlcadjordisayol: too soon
15:35.49brlcadwe need to be at least in beta status
15:35.55brlcadright now, it's alpha
15:37.18jordisayolbrlcad: I remember we talk that when it becomes alpha, but no problem, we will change it when it's beta
15:59.45Notify03BRL-CAD:starseeker * 57067 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: Make a stab at adding at least some form of shape definition to the step output.
16:23.42Izak_b
16:42.32Notify03BRL-CAD:iiizzzaaakkk * 57068 brlcad/trunk/src/librt/primitives/hrt/hrt.c: Adding rt_hrt_shot to intersect a ray with the heart
16:43.40*** part/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
16:54.19brlcadCh3ck: a crash is never "how it is supposed to work"
16:54.40brlcadcan you fix it?
17:01.06Notify03BRL-CAD:brlcad * 57069 brlcad/trunk/src/conv/step/g-step/g-step.cpp: ws consistency
17:10.18Notify03BRL-CAD Wiki:Vladbogolin * 6021 /wiki/User:Vladbogolin/GSoC2013/Logs: /* Week 10 */
17:10.38Notify03BRL-CAD:brlcad * 57070 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: include comments and logically break up the wall of code so I can understand what's going on
17:11.35Ch3ckbrlcad: fixed the problem but having problems generating the dp from db_lookup(dbip, argv[1] ..)
17:11.46Ch3ckthis where the problem lies
17:12.18Ch3ckwas actually thinking of building the tree with db_build() as you did in the tree_walker_test
17:12.26Ch3ckbefore calling db_lookup
17:16.48``Erikbrlcad: any thoughts on why wish and bwish would do drastically different things with http://brlcad.org/~erik/tmp/whu.tcl ?
17:30.43Notify03BRL-CAD Wiki:IIIzzzaaakkk * 6022 /wiki/User:Izak/GSOC_2013_logs: /* August 19th to August 24th */
18:34.44Notify03BRL-CAD:erikgreenwald * 57071 brlcad/trunk/src/adrt/isst: use wish instead of bwish
18:45.54Notify03BRL-CAD Wiki:IIIzzzaaakkk * 6023 /wiki/User:Izak/GSOC_2013_logs: /* August 19th to August 24th */
18:47.58Notify03BRL-CAD:starseeker * 57072 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: tweaks - geometry still not coming in correctly with BRL-CAD step-g, looks like topology is off somewhere...
18:58.35*** part/#brlcad hickoryknoll (~hickorykn@66-118-151-70.static.sagonet.net)
18:58.45*** join/#brlcad hickoryknoll (~hickorykn@66-118-151-70.static.sagonet.net)
19:00.57Izak__``Erik:Please take a look at this picture. A test of shot using the 'rt' command  http://brlcad.org/~Izak/rt_shot_test.png
19:11.11brlcadIzak__: question for you regarding the doc camp, it's my understanding that you applied and were accepted as an individual.  is that true?
19:11.39Izak__brlcad:True
19:11.58brlcadcongrats, that's fantastic
19:12.09Izak__brlcad: Would prefer documenting for BRL-CAD though
19:12.19brlcadthat leads to a follow-up question then of .. heh
19:12.29brlcadwell that's my question actually
19:12.31brlcadyou have a choice
19:12.46brlcadyou either can go and get assigned to a project (maybe brl-cad maybe not)
19:12.56brlcador you can be one of our 5
19:13.23brlcadeither way, I need to know because it determines how many others we get to send
19:14.17brlcadand slot-wise, if you're one of our five, that leaves just one more slot open, otherwise two
19:14.19Izak__brlcad:Would prefer to get assigned to a project, to give others some one a chance
19:14.49brlcadgoing for a balance of 2 experience, 2 inexperienced, and 1 professional editor
19:15.35Izak__Wow: hoping BRL-CAD sends a diverse team
19:15.53brlcadokay, that works .. let me know within the next couple hours if you change your mind
19:16.07Izak__Okay then
19:16.17brlcadit'll be pretty diverse
19:16.17Notify03BRL-CAD Wiki:NyahCh3ck20 * 6024 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 19 August - 25 August */
19:16.50brlcadhave to balance people that understand and can write content quickly with people that will need to work on other aspects like structure, grammar, translations, etc
19:17.19brlcadjust know that it is entirely likely that you will NOT be assigned to BRL-CAD, just in terms of % chance
19:18.07Izak__meaning I will not sprint for BRL-CAD ?
19:18.20brlcadthat is possible
19:18.21brlcadlikely even
19:18.24brlcadI think there are 4 or 5 orgs if I recall correctly, so 20% or so
19:18.49brlcadI don't know how random the assignments are, or if you even have any say
19:18.55Izak__yeah I know of the chosen orgs
19:19.49brlcadsince you were accepted as an individual, you get to choose, but google asked that if you knowingly choose brl-cad, that we only send 4 others to keep things fair/balanced
19:19.58Izak__So will u advise me to take a look at their software or docs just to be prepared?
19:20.47brlcadwell I could certainly advise you for BRL-CAD, because we're going to have several meetings beforehand and do some work to make sure everyone is ready
19:21.01brlcadbut I don't even know what other orgs were accepted to prepare you for them
19:22.20Izak__I know them : Should I send them to you BRL-CAD, RTEMS, OpenMRS, Gnome
19:23.40Izak__brlcad: Seen them ?
19:25.49Notify03BRL-CAD:brlcad * 57073 brlcad/trunk/src/libbu/malloc.c: utilize posix_memalign() for allocations, starting with an ultra-conservative 8 byte alignment while more testing is performed. clean up some misplaced comments while we're at it.
19:33.30Notify03BRL-CAD:brlcad * 57074 brlcad/trunk/src/libbu/malloc.c: this just artificially makes malloc/calloc even slower than they already are, needs to be fixed
19:35.32Izak__wondering if brlcad: and Izak__: are done discussing
19:38.31Notify03BRL-CAD:brlcad * 57075 brlcad/trunk/include/bu.h: define a semaphore specifically for malloc. this will prevent the deadlock condition frequently encountered with libfb's i/o locking (which has absolutely nothing to do with a potentially threadunsafe malloc implementation.).
19:40.18Notify03BRL-CAD:brlcad * 57076 brlcad/trunk/src/libbu/malloc.c: utilize the new BU_SEM_MALLOC semaphore instead of BU_SEM_SYSCALL since this has been a historic source of confusion and unnecessary debugging hell. remove a few fprintf-wrapped locks as well since there are considerably more that remain unprotected, at least until a need is observed.
19:40.53brlcadCh3ck: you fixed the "l" command crash?  what was the cause?  do you have a patch?
19:41.34brlcadCh3ck: as for db_lookup, you must build the directory first as in the example
19:44.15Notify03BRL-CAD:carlmoore * 57077 brlcad/trunk/src/conv/nmg/g-nmg.c: print output file name ('default' if that is the case), and also do if-else for percent
19:44.36Ch3ckwell discovered the crash while building a test case for my pull_comb() routine
19:45.02brlcadsure
19:45.08Ch3ckwell still debuggin my test there appears to be some NULL Pointer lurking somewhere
19:45.13Ch3ckin my code
19:45.33Ch3ckill finish and look at the l command problem ;)
19:45.39brlcadokay
19:45.51brlcadif anything, a backtrace on the l command crash would help
19:46.20Ch3ckok thanks
19:46.30brlcaddo you remember gdb?
19:46.35brlcadgdb --args mged ...
19:46.38brlcadgdb> run
19:46.52brlcadrun the "l" command in mged, crash kicks back to gdb
19:46.57brlcadthen
19:47.02brlcadgdb> backtrace
19:47.10brlcadit'll print where exactly it crashed
19:47.36Notify03BRL-CAD:starseeker * 57078 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: Previous state caused step-g to crash
19:49.40brlcad``Erik: just fyi, I ran a global s/register //g a little while back and benchmark dropped a consistent 10-20%
19:50.00brlcadI was frankly shocked, but I it was clearly taking the hints to heart in at least some critical functions
19:50.54brlcadIzak__: carlmoore is not on irc, just so you know
19:51.20brlcadand what he did was right there in his commit message :)
19:51.28Izak__brlcad:Okay, 'cause he's always on my back :)
19:51.37brlcadwell you keep making spelling mistakes :)
19:52.22brlcadhe's very particular and has amazingly done well to eliminate nearly every spelling mistake in the entire package
19:52.50Izak__thinking that brlcad: assigned carlmoore: to "justb keep following this guy"
19:52.52brlcadwhich is pretty amazing when you think about it .. more than a million words of documentation alone, more than a million lines of code
19:53.01brlcadnope
19:53.05Izak__s/justb/just
19:53.07brlcadhe does that all by himself
19:53.55brlcadhe also writes scripts
19:54.03brlcadwhen someone makes a mistake more than once, they are then forever checked every day thereafter by his scripts
19:54.09Izak__acknowledging the great job carlmoore: is doing
19:54.14Ch3ckbrlcad: ok. Well looks like the problem comes from the bn_mat_inverse() routine.
19:54.31brlcador once he cleans up a directory and marks it clean, his scripts catch when anything makes them unclean
19:54.41brlcadCh3ck: stacktrace?
19:54.42Ch3ckwhen the matrix enters there it does not come out.. will do the backtrace with gdb
19:55.01Ch3cki mean for my test
19:57.06brlcadgot to migrate beyond using print statements for debugging ;)
19:57.35brlcadfar too slow for real work
20:00.45Ch3ckyeah never really used gdb before much..
20:01.04Ch3ckfollowing some online tutorials in order to maximise its power.
20:03.19Notify03BRL-CAD:brlcad * 57079 brlcad/trunk/src/conv/nmg/g-nmg.c: integer division for percentages is generally a bad idea. do it as doubles.
20:03.36brlcadCh3ck: feel free to ask questions here too .. we all use it
20:03.50brlcadvery powerful for figuring things out
20:05.35Ch3ckwell i want to enter the pull_comb and actually know the precise point where the seg fault occurs
20:05.44Ch3ckhow do i do that? do i set breakpoint?
20:10.49Ch3ckset break point at bn_mat_inverse. Then exec run but it gives me the following error: Program exited normally.
20:10.52Ch3ckMissing separate debuginfos, use: debuginfo-install glibc-2.12-1.47.el6.i686 libgcc-4.4.6-3.el6.i686 libstdc++-4.4.6-3.el6.i686 tcl-8.5.7-6.el6.i686 zlib-1.2.3-29.el6.i686
20:13.31starseekerbrlcad: nevermind, my build was in a bad intermediate state
20:23.52Ch3ckcurrently steppting through code using gdb 'n' and 's' command
20:41.47Ch3ckbrlcad: finally discovered the problem with gdb that "comb_leaf->tr_l.tl_mat" is a null pointer is this normal for every combination?
20:42.11Ch3ckor i need to declare one in case it does not exist
20:43.31Ch3ckor if the comb_leaf is like a xxx.r object then i'll have t create one or use the pull_leaf routine here right?
20:48.10Notify03BRL-CAD:starseeker * 57080 brlcad/trunk/src/conv/nmg/g-nmg.c: Fix build error
20:49.56Izak__a demain :)
20:53.35Ch3ckbut when i use t the tree_state_pointer(tsp) it gives me a valid matrix. is that ok?
20:54.09Ch3ckor must i use the comb_leaf->tr_l.ts_mat?
21:01.27Notify03BRL-CAD:mohitdaga * 57081 (brlcad/trunk/src/libicv/bw.c brlcad/trunk/src/libicv/pix.c): Few changes in bw.c and pix.c related to style. Also read function returns 0 when end of file is reached.
21:02.23Ch3ckwrapping up to go sleep ;)
21:03.32Ch3ckstarseeker: brlcad: still waiting on my patches to be reviewed ;)
21:04.31Notify03BRL-CAD:mohitdaga * 57082 (brlcad/trunk/src/util/CMakeLists.txt brlcad/trunk/src/util/bw-pix.c): Update bw-pix to use libicv. Also this imporves the usability of bw-pix.
21:06.41Notify03BRL-CAD:mohitdaga * 57083 (brlcad/trunk/src/util/CMakeLists.txt brlcad/trunk/src/util/pixfade.c): Update pixfade to use libicv. This now uses icv api to fade an image. This helps in writting/reading to/from pipes.
21:07.59zero_levelwaves to ``Erik and brlcad
21:15.26brlcadwaves to zero_level
21:15.36brlcadstarseeker: glad to hear it
21:31.30zero_levelhey getting this error while installing
21:31.32zero_levelhttp://paste.kde.org/p973ae891/
22:01.53brlcadthat's current development, Izak_ that's for you
22:02.12brlcadzero_level: you could fix that or turn off strict ;)
22:02.17brlcador wait for Izak_ to fix it
22:04.04brlcadCh3ck: there's no way to tell just looking at "comb_leaf->tr_l.tl_mat" whether it's normal for that to be null or not
22:04.12brlcadneed to see the stack trace that led to there
23:32.25*** join/#brlcad mpictor (~mark@2601:d:b280:b5:d63d:7eff:fe2d:2505)

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