IRC log for #brlcad on 20150602

00:22.09*** join/#brlcad kintel (~kintel@unaffiliated/kintel)
00:40.07starseekerbrlcad: OK - I didn't spot it in the functab initially.  I'll try to swat it tomorrow
01:09.38Notify03BRL-CAD:starseeker * 65147 brlcad/trunk/src/libanalyze/raydiff.c: protect the free calls.
01:10.16Notify03BRL-CAD:starseeker * 65148 brlcad/trunk/src/libanalyze/CMakeLists.txt: Add a stab at an object-inside-object test.
02:33.14Notify03BRL-CAD Wiki:117.199.103.107 * 8509 /wiki/User:Gurwinder_Singh/GSoc15/log_developmen:
03:04.12*** join/#brlcad kintel (~kintel@unaffiliated/kintel)
03:22.34*** join/#brlcad merzo (~merzo@133-14-133-95.pool.ukrtel.net)
04:01.14*** join/#brlcad kintel (~kintel@unaffiliated/kintel)
04:21.32*** join/#brlcad merzo (~merzo@21-39-132-95.pool.ukrtel.net)
04:46.34*** join/#brlcad merzo (~merzo@238-15-133-95.pool.ukrtel.net)
05:07.25*** join/#brlcad merzo (~merzo@108-0-132-95.pool.ukrtel.net)
06:21.23*** join/#brlcad merzo (~merzo@154-69-133-95.pool.ukrtel.net)
06:59.31*** join/#brlcad andrei_il (~andrei@109.100.128.78)
07:32.59*** join/#brlcad sofat (~sofat@202.164.53.117)
08:10.19*** join/#brlcad merzo (~merzo@92.60.189.225)
08:35.36*** join/#brlcad dracarys983 (dracarys98@nat/iiit/x-exrmxgvrqdqiqdci)
11:01.14Notify03BRL-CAD Wiki:MeShubham99 * 8510 /wiki/Google_Summer_of_Code/2015: /* Online Geometry Viewer (OGV): Back-end */
11:35.55Notify03BRL-CAD Wiki:Shaina7837 * 8511 /wiki/User:Shainasabarwal/GSoC15/logs: /* 28 May */
12:14.47Notify03BRL-CAD Wiki:MeShubham99 * 8512 /wiki/User:MeShubham99/GSoc15/proposal: /* Things that I will Improve and add on: - */
12:15.19Notify03BRL-CAD Wiki:MeShubham99 * 8513 /wiki/User:MeShubham99/GSoc15/proposal: /* Things that I will Improve and add on: - */
12:15.56Notify03BRL-CAD Wiki:MeShubham99 * 8514 /wiki/User:MeShubham99/GSoc15/proposal: /* Things that I will Improve and add on: - */
12:16.44Notify03BRL-CAD Wiki:MeShubham99 * 8515 /wiki/User:MeShubham99/GSoc15/proposal: /* Brief Summary */
12:33.50Notify03BRL-CAD Wiki:MeShubham99 * 8516 /wiki/User:MeShubham99/GSoc15/proposal: /* Milestones */
12:35.30Notify03BRL-CAD Wiki:MeShubham99 * 8517 /wiki/User:MeShubham99/GSoc15/log_developmen:
13:39.50Notify03BRL-CAD:starseeker * 65149 brlcad/trunk/include/analyze.h: Helps to commit the header...
13:47.15Notify03BRL-CAD Wiki:85.246.127.87 * 8518 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Phase */
13:48.01Notify03BRL-CAD Wiki:85.246.127.87 * 8519 /wiki/User:Vasco.costa/GSoC15/logs:
13:52.28Notify03BRL-CAD:starseeker * 65150 brlcad/trunk/src/libged/gdiff.c: Use -R option to trigger gdiff with raytracing, draw all visuals if none are specified, clean up previous gdiff drawing if we're drawing again.
13:53.50Notify03BRL-CAD Wiki:85.246.127.87 * 8520 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Phase */
13:54.40*** join/#brlcad vasc (~vasc@bl13-127-87.dsl.telepac.pt)
13:55.39*** join/#brlcad kintel (~kintel@unaffiliated/kintel)
13:59.36brlcadhi vasc
13:59.58brlcadany questions?  how's progress?
14:22.59Notify03BRL-CAD:ejno * 65151 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: fixes
14:28.07Notify03BRL-CAD:ejno * 65152 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: set default material ID to 1 (must be greater than zero)
14:46.27vaschello brlcad
14:46.32vasci mean sean
14:46.55vasci'm working on a simplified rendering loop
14:47.27``Erikhah :D  the slad 'vision statement' probably came from this: http://www.buzzwordipsum.com/
14:51.10vascit helped a lot to use netbeans to read the code
14:51.16vascthe doxygen wasn't cutting it
14:51.27vascand its quite entangled
14:52.56vasci'm getting compilation errors with the svn
14:53.11vasc[ 91%] /home/vasco/brlcad/src/libged/gdiff.c: In function ‘ged_gdiff’:
14:53.11vasc/home/vasco/brlcad/src/libged/gdiff.c:49:9: error: variable ‘right_dbip_specified’ set but not used [-Werror=unused-but-set-variable]
14:53.11vasc<PROTECTED>
14:53.11vasc<PROTECTED>
14:53.11vasc/home/vasco/brlcad/src/libged/gdiff.c:48:9: error: variable ‘left_dbip_specified’ set but not used [-Werror=unused-but-set-variable]
14:53.14vasc<PROTECTED>
14:53.16vasc<PROTECTED>
14:53.55vascyou guys need to check that one
14:55.08vasci guess i shouldn't have updated. i'll go eat something until this gets fix.
14:59.31*** join/#brlcad kintel (~kintel@unaffiliated/kintel)
15:11.39``Erikhm, those vars are reasonably old. Either the flag wasn't being used until now or the code was removed... you can just comment those lines out (or delete them or whatever)
15:12.28``Erikupdates and tries a build
15:39.18*** join/#brlcad Gurwinder (3b5be9d4@gateway/web/freenode/ip.59.91.233.212)
15:50.30Notify03BRL-CAD:ejno * 65153 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: refactoring geometry detection (in progress)
16:05.24vascactually its GCC that's dumb
16:05.33vascif i  comment the variables it doesn't work
16:05.45vascbecause they're set something in the switch below
16:05.56vascbut GCC, for whatever reason, doesn't get that
16:06.10vasc-Werror=unused-but-set-variable is the problem
16:06.20vascor maybe a GCC upgrade would fix it
16:07.23vascnow how do i shut that up...
16:09.59vasc#pragma GCC diagnostic ignored "-Wunused-but-set-variable"
16:10.01vascshut it up
16:10.17vascyou guys shouldn't enable that as error though
16:10.50vascmaybe i'll upgrade ubuntu and that will upgrade gcc as well
16:11.03vascit'll take me hours to upgrade ubuntu though
16:12.12vasci'm using gcc 4.9.1
16:12.32vasci'll make a ticket
16:17.30vasctime to upgrade to ubuntu 15.04
16:23.10Notify03BRL-CAD Wiki:85.246.127.87 * 8521 /wiki/User:Vasco.costa/GSoC15/logs:
16:33.04*** join/#brlcad andrei_il (~andrei@109.100.128.78)
16:33.51Notify03BRL-CAD Wiki:MeShubham99 * 8522 /wiki/User:MeShubham99/GSoc15/log_developmen:
16:35.42*** join/#brlcad devinder (~chatzilla@27.97.111.96)
16:51.57Notify03BRL-CAD:carlmoore * 65154 brlcad/trunk/src/util/bwmod.c: if using ABS, still need numop++, but don't care about that member of val; also, in 2 places, if we are being kicked out of program, don't care about that member of op array
16:53.55*** join/#brlcad sofat (~sofat@202.164.45.204)
16:54.34*** join/#brlcad elf11 (~elf11@82.137.13.214)
16:54.46Notify03BRL-CAD Wiki:85.246.127.87 * 8523 /wiki/Google_Summer_of_Code/2015: /* Sigourney: a Boolean Weaver for BRL-CAD */
16:55.39Notify03BRL-CAD Wiki:85.246.127.87 * 8524 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Phase */
16:57.51sofatbrlcad, starseeker how i add new xsl stylesheet in brlcad build system so when i  ./configure all .cmake(also add the new xsl stylesheet commands) will update and make php directory in share/docbook/ folder to handle the wordpress php files.
16:57.58sofathow i do this where i need to edit the code in brlcad source code.?
17:43.01Notify03BRL-CAD:erikgreenwald * 65155 brlcad/trunk/src/libged/gdiff.c: The code that uses "left_dbip_specified" and "right_dbip_specified" was commented out, but the declarations and setting were left. This causes issues with unused variables, so they're being commented out for now with notes.
17:43.58vasckewl
17:44.07vascso the problem was we had writes but no reads
17:44.12``Erikyeah
17:44.26vasci saw there were writes later on but didn't check there were no reads
17:44.44vascso GCC DID know what is was doing. great.
17:45.32vasci'm nearly finished upgrading my distro by now though
17:46.06``Eriklooks like the 'use' code was commented out, then uncommented to fix the warnings, then recommented out... O.o
17:46.40*** part/#brlcad elf11 (~elf11@82.137.13.214)
17:49.45vascrebooting
17:52.52*** join/#brlcad vasc (~vasc@bl13-127-87.dsl.telepac.pt)
18:09.22Notify03BRL-CAD Wiki:85.246.127.87 * 8525 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Phase */
18:09.36vascsbbl
18:09.38vascbbl
18:11.56Notify03BRL-CAD Wiki:85.246.127.87 * 8526 /wiki/User:Vasco.costa/GSoC15/logs:
18:12.19Notify03BRL-CAD Wiki:85.246.127.87 * 8527 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Phase */
18:40.26*** join/#brlcad DarkCalf (~DarkCalf@64.185.232.90)
19:33.45*** join/#brlcad Milinda (7c2bcb89@gateway/web/freenode/ip.124.43.203.137)
20:03.49*** join/#brlcad vasc (~vasc@bl13-127-87.dsl.telepac.pt)
20:08.13*** join/#brlcad LordOfBikes (~armin@dslb-092-074-230-024.092.074.pools.vodafone-ip.de)
20:09.00Notify03BRL-CAD:starseeker * 65156 (brlcad/trunk/include/bu/opt.h brlcad/trunk/src/conv/gcv/gcv.cpp and 2 others): Remove dynamic opt table API.
20:27.31Notify03BRL-CAD:starseeker * 65157 brlcad/trunk/src/libbu/opt.c: Simplify since we are't supporting dynamic tables
20:31.44*** join/#brlcad terrywen (~twen6@pool-71-97-144-189.bltmmd.fios.verizon.net)
20:45.25*** join/#brlcad merzo (~merzo@105-83-133-95.pool.ukrtel.net)
20:47.16brlcadvasc: gcc's warning reporting has actually gotten rather advanced in the last couple years in particular -- it's almost never wrong ...
20:47.59brlcadso much so that I'd wager it's almost absurd to disable a warning unless there's a system header involved
20:50.36brlcadboth llvm and gcc now basically use a form of advanced graph-based quasi-regex-style pattern matching to detect conditions
20:51.00brlcadcoverity used to be the only shop in town using that method, but the open source kids are growing up fast :)
20:52.21vasci upgraded my distro and gcc and now i get this:
20:52.45vaschome/vasco/brlcad/src/other/stepcode/src/clutils/gennodearray.cc:23:57: error: declaration of ‘void* memmove(void*, const void*, size_t)’ has a different exception specifier
20:52.45vasc<PROTECTED>
20:52.45vasc<PROTECTED>
20:52.45vascIn file included from /home/vasco/brlcad/src/other/stepcode/src/clutils/gennodearray.h:25:0,
20:52.45vasc<PROTECTED>
20:52.49vasc/usr/include/string.h:50:14: error: from previous declaration ‘void* memmove(void*, const void*, size_t) throw ()’
20:52.52vasc<PROTECTED>
20:52.54vasc<PROTECTED>
20:52.56vascsrc/other/stepcode/src/clutils/CMakeFiles/steputils.dir/build.make:146: recipe for target 'src/other/stepcode/src/clutils/CMakeFiles/steputils.dir/gennodearray.cc.o' failed
20:52.59vascmake[2]: *** [src/other/stepcode/src/clutils/CMakeFiles/steputils.dir/gennodearray.cc.o] Error 1
20:53.01vascrepeated like 8 times
20:53.03vascdunno if i need to re-run cmake or what
20:53.51brlcadyep.. every upgrade they have been introducing new detections .. pretty exciting stuff!
20:53.55vascfor whatever reason i thinks i don't have a memmove declared somewhere and then redeclares it
20:54.11vascand the new declaration is different
20:54.11StragusI find the "might be unused" warnings are often wrong, eh
20:55.03brlcadStragus: I haven't seen one wrong in .. years, at least not technically wrong if you follow the data
20:55.13brlcadmany that seemed wrong
20:55.15vasci have a past history of headbutting with gcc warning fails so i am usually kind of suspicious when i see something like that
20:55.41vascbut its good if they're better at it now
20:56.10brlcadI have a history of chasing them down, even if they are false positives, as even those tend to be bad-smelling code
20:56.43Stragusbrlcad, I have seen logic too "complex" for the compiler to follow... Like setting some variable and later reading it only when the bit 3 of some other variable is set
20:56.44brlcadthe biggest source I've seen are issues that cannot be worked around (bugs or deficiencies in system headers)
20:57.45brlcadStragus: I'd be happy to inspect a case you think is a false positive if it's ever handy
20:58.30brlcadI've inspected cases far more complex than some bit fiddling too
20:58.39brlcadlike I said, it's been years
20:59.30vascoops. i did one rm -rf too much
20:59.35StragusI'm always silencing that warning since I get too many false positives with SSE
20:59.36brlcadvasc: if you don't want to deal with those warnings, you can turn them off during cmake
20:59.53brlcadSSE and asm code I can easily see causing false positives
21:00.04brlcadbut then that's technically leaving C
21:00.06StragusLike modifying only the lower 64 bits of a 128 bits XMM, which implies reading it, and GCC complains
21:00.27brlcad(asm that is)
21:01.26StragusEven if you build your xmm variable just by writing the lower 64 bits then the upper 64 bits, gcc complains
21:02.06brlcadwould need to see a specific example, way too many variables
21:02.26vascit messes up with union types?
21:03.15StragusUnions are fine, in my experience
21:03.47brlcadStragus: it wasn't a challenge to say that they're not possible :)
21:04.21brlcadit's that over decades, I've seen a pattern of devs arrogantly declaring the compiler is wrong and 9/10 they've been wrong and in recent years, even more so
21:04.30vasci just nuked the simple .g files i made to test the primitives. oops
21:04.55vasci used to think that was true
21:05.12brlcadvasc there is a slew of sample .g files in the share/db build dir
21:05.12vascuntil i was doing my final course project and found a bug in templates with ms visual studio c++ 6.0
21:05.30vascwhich they fixed in sp4 i think
21:05.35brlcadmsvc is a different beast -- all bets off there :)
21:06.14vasci still remember the wesnoth game devs complaining a lot about c++ support in gcc as well
21:06.23vasci never had many issues with it because i usually code in c
21:06.38vasci only use c++ quite sparingly
21:06.39StragusThat's unexpected, GCC's support for the standards is pretty good
21:06.54vascwell this was nearly a decade ago
21:06.54StragusUnlike MSVC which still only supports C89 (come on!)
21:06.56brlcadwe hit a slew of issues in bzflag too, but mostly were portability-related
21:06.58vascthings could have changed
21:07.06brlcad(bz is c++)
21:07.55vascthere was a time when i was enamoured with the object oriented fluff but i quickly grew out of it
21:08.02Stragusbrlcad, I turned on "might be uninitialized" warnings (for the first time in a long time) and it looks a lot better than before
21:08.16StragusI assume they silenced a bunch of warnings that were often wrong
21:08.22StragusSSE/AVX still causes some issues
21:08.24brlcadStragus: msvc technically is a C++ compiler that happens to support C89 -- they directly said they had no intention of ever supporting C99
21:08.45vascits ms. they are idiots.
21:08.59brlcadthey happen to support many of the new standard features simply by way of supporting the newer c++ standards (which they have been on top of pretty well)
21:09.33vasci actually liked c# though
21:09.33StragusAs long as you do a #define restrict __restrict and such, yes
21:10.31vascits much better than java. java's basic type system is whacked.
21:10.59vascit was kludged and kludged and nobody wants to rewrite it
21:11.16vascwant unsigned ints? fast floats? good luck.
21:11.42vasci think the DoD once even paid Sun to fix their broken FP performance in Java at once point
21:12.03vascwhich they 'fixed' by inventing a new programming language that no one uses
21:12.21StragusUsing Java when you care about performance is a mistake
21:12.21vasci think it was called fortress
21:12.30StragusNot as bad as using Python, but still a mistake
21:13.15vasci really like python
21:13.21vascfor prototyping its great
21:13.45vascor doing scripts and things like that
21:18.51vascthe thing is java could have a lot faster performance on FP than it has
21:18.57vascbut the type system is totally broken
21:19.44vascits never going to be faster than c++ or c but
21:33.02vascthere are virtual machines for python btw
21:34.14vascpypy and there used to be psyco
21:34.56vasci think i was playing that ddr clone game once and it was written in python and compiled with pypy
21:35.28vascah no it was the frets on fire game
22:12.05Notify03BRL-CAD Wiki:Konrado DJ * 8528 /wiki/User:Konrado_DJ/GSoc2015/logs: /* 1 JUNE 2015 */
22:14.30vaschmm
22:24.11vaschope i didn't delete too much code
22:24.34vascnope
22:26.13vascok i cut the ray casting code to the bare bones
22:26.21vascray generation
22:26.36vascnow the problem is the hierarchy traversal bool weaving and whatever
22:26.56vasci gotta cut it all down into just testing with all the objects without traversing bsps and things like that
22:28.22vascman even the simple code like view_pixel which is only supposed to copy the color in pixel to the buffer are complicated like heckk
22:29.06vascdon't wanna deal with that now but eventually this needs to be redone too
22:32.01vascoh i see it calls a view_eol function in the end which does zip
22:32.05vascanother thing to delete
22:32.46vascit probably did something at some point i guess
22:39.23vascneat. well i just cut away supersampling, and jittered sampling and so on
22:39.35vascbut we have to start someplace and its just too much noise at this point
22:39.59vascno more branching
22:59.32Notify03BRL-CAD Wiki:Deekaysharma * 8529 /wiki/User:Deekaysharma/logs:
23:03.44vascuhoh
23:04.46vascthe ray segments are stored in a linked list of indetermined size
23:04.50vascthat's baddddd...
23:05.24vasci'm supposed to know how much memory i need to allocate BEFORE running the algorithm. opencl doesn't support dynamic memory allocation inside kernels
23:05.45vascso much for that
23:06.39vasci guess i could run the algorithm TWICE. one to know how much memory i need and another to store the segments themselves
23:06.46vascbut i wonder how slow that will be....
23:07.20vascoh well don't have a better plan now
23:09.07Notify03BRL-CAD Wiki:85.246.127.87 * 8530 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Phase */
23:32.40StragusLinked list of ray segments? Darn
23:34.01StragusI would use an implicitely allocated chunk of X segments per ray, then use a big fat buffer of "overflow" segments from which it "allocates" extra segments by global atomic read/write an offset counter
23:35.23StragusMy raytracer just had a callback per hit (even a CUDA callback) to let the user process hits directly as they come, which is by far a preferable approach
23:35.33StragusThe user can still buffer up if he really wants to
23:37.51Notify03BRL-CAD:starseeker * 65158 brlcad/trunk/src/librt/db_diff.c: Use ft_internal_size from the functab.
23:58.14vaschmm
23:58.49vascthat reminded me of something
23:58.59vascah but it won'twork
23:59.25vasci think i'll just do everything twice
23:59.34StragusThat sounds terrible
23:59.43StragusWhat's wrong with preallocating X segments per ray?
23:59.47vascyeah. it SOUNDS terrible
23:59.54vascbut memory allocation is slow too

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