| 00:22.09 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 00:40.07 | starseeker | brlcad: OK - I didn't spot it in the functab initially. I'll try to swat it tomorrow |
| 01:09.38 | Notify | 03BRL-CAD:starseeker * 65147 brlcad/trunk/src/libanalyze/raydiff.c: protect the free calls. |
| 01:10.16 | Notify | 03BRL-CAD:starseeker * 65148 brlcad/trunk/src/libanalyze/CMakeLists.txt: Add a stab at an object-inside-object test. |
| 02:33.14 | Notify | 03BRL-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.14 | Notify | 03BRL-CAD Wiki:MeShubham99 * 8510 /wiki/Google_Summer_of_Code/2015: /* Online Geometry Viewer (OGV): Back-end */ |
| 11:35.55 | Notify | 03BRL-CAD Wiki:Shaina7837 * 8511 /wiki/User:Shainasabarwal/GSoC15/logs: /* 28 May */ |
| 12:14.47 | Notify | 03BRL-CAD Wiki:MeShubham99 * 8512 /wiki/User:MeShubham99/GSoc15/proposal: /* Things that I will Improve and add on: - */ |
| 12:15.19 | Notify | 03BRL-CAD Wiki:MeShubham99 * 8513 /wiki/User:MeShubham99/GSoc15/proposal: /* Things that I will Improve and add on: - */ |
| 12:15.56 | Notify | 03BRL-CAD Wiki:MeShubham99 * 8514 /wiki/User:MeShubham99/GSoc15/proposal: /* Things that I will Improve and add on: - */ |
| 12:16.44 | Notify | 03BRL-CAD Wiki:MeShubham99 * 8515 /wiki/User:MeShubham99/GSoc15/proposal: /* Brief Summary */ |
| 12:33.50 | Notify | 03BRL-CAD Wiki:MeShubham99 * 8516 /wiki/User:MeShubham99/GSoc15/proposal: /* Milestones */ |
| 12:35.30 | Notify | 03BRL-CAD Wiki:MeShubham99 * 8517 /wiki/User:MeShubham99/GSoc15/log_developmen: |
| 13:39.50 | Notify | 03BRL-CAD:starseeker * 65149 brlcad/trunk/include/analyze.h: Helps to commit the header... |
| 13:47.15 | Notify | 03BRL-CAD Wiki:85.246.127.87 * 8518 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Phase */ |
| 13:48.01 | Notify | 03BRL-CAD Wiki:85.246.127.87 * 8519 /wiki/User:Vasco.costa/GSoC15/logs: |
| 13:52.28 | Notify | 03BRL-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.50 | Notify | 03BRL-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.36 | brlcad | hi vasc |
| 13:59.58 | brlcad | any questions? how's progress? |
| 14:22.59 | Notify | 03BRL-CAD:ejno * 65151 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: fixes |
| 14:28.07 | Notify | 03BRL-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.27 | vasc | hello brlcad |
| 14:46.32 | vasc | i mean sean |
| 14:46.55 | vasc | i'm working on a simplified rendering loop |
| 14:47.27 | ``Erik | hah :D the slad 'vision statement' probably came from this: http://www.buzzwordipsum.com/ |
| 14:51.10 | vasc | it helped a lot to use netbeans to read the code |
| 14:51.16 | vasc | the doxygen wasn't cutting it |
| 14:51.27 | vasc | and its quite entangled |
| 14:52.56 | vasc | i'm getting compilation errors with the svn |
| 14:53.11 | vasc | [ 91%] /home/vasco/brlcad/src/libged/gdiff.c: In function ged_gdiff: |
| 14:53.11 | vasc | /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.11 | vasc | <PROTECTED> |
| 14:53.11 | vasc | <PROTECTED> |
| 14:53.11 | vasc | /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.14 | vasc | <PROTECTED> |
| 14:53.16 | vasc | <PROTECTED> |
| 14:53.55 | vasc | you guys need to check that one |
| 14:55.08 | vasc | i 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 | ``Erik | hm, 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 | ``Erik | updates and tries a build |
| 15:39.18 | *** join/#brlcad Gurwinder (3b5be9d4@gateway/web/freenode/ip.59.91.233.212) | |
| 15:50.30 | Notify | 03BRL-CAD:ejno * 65153 brlcad/trunk/src/libgcv/conv/fastgen4/fastgen4_write.cpp: refactoring geometry detection (in progress) |
| 16:05.24 | vasc | actually its GCC that's dumb |
| 16:05.33 | vasc | if i comment the variables it doesn't work |
| 16:05.45 | vasc | because they're set something in the switch below |
| 16:05.56 | vasc | but GCC, for whatever reason, doesn't get that |
| 16:06.10 | vasc | -Werror=unused-but-set-variable is the problem |
| 16:06.20 | vasc | or maybe a GCC upgrade would fix it |
| 16:07.23 | vasc | now how do i shut that up... |
| 16:09.59 | vasc | #pragma GCC diagnostic ignored "-Wunused-but-set-variable" |
| 16:10.01 | vasc | shut it up |
| 16:10.17 | vasc | you guys shouldn't enable that as error though |
| 16:10.50 | vasc | maybe i'll upgrade ubuntu and that will upgrade gcc as well |
| 16:11.03 | vasc | it'll take me hours to upgrade ubuntu though |
| 16:12.12 | vasc | i'm using gcc 4.9.1 |
| 16:12.32 | vasc | i'll make a ticket |
| 16:17.30 | vasc | time to upgrade to ubuntu 15.04 |
| 16:23.10 | Notify | 03BRL-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.51 | Notify | 03BRL-CAD Wiki:MeShubham99 * 8522 /wiki/User:MeShubham99/GSoc15/log_developmen: |
| 16:35.42 | *** join/#brlcad devinder (~chatzilla@27.97.111.96) | |
| 16:51.57 | Notify | 03BRL-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.46 | Notify | 03BRL-CAD Wiki:85.246.127.87 * 8523 /wiki/Google_Summer_of_Code/2015: /* Sigourney: a Boolean Weaver for BRL-CAD */ |
| 16:55.39 | Notify | 03BRL-CAD Wiki:85.246.127.87 * 8524 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Phase */ |
| 16:57.51 | sofat | brlcad, 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.58 | sofat | how i do this where i need to edit the code in brlcad source code.? |
| 17:43.01 | Notify | 03BRL-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.58 | vasc | kewl |
| 17:44.07 | vasc | so the problem was we had writes but no reads |
| 17:44.12 | ``Erik | yeah |
| 17:44.26 | vasc | i saw there were writes later on but didn't check there were no reads |
| 17:44.44 | vasc | so GCC DID know what is was doing. great. |
| 17:45.32 | vasc | i'm nearly finished upgrading my distro by now though |
| 17:46.06 | ``Erik | looks 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.45 | vasc | rebooting |
| 17:52.52 | *** join/#brlcad vasc (~vasc@bl13-127-87.dsl.telepac.pt) | |
| 18:09.22 | Notify | 03BRL-CAD Wiki:85.246.127.87 * 8525 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Phase */ |
| 18:09.36 | vasc | sbbl |
| 18:09.38 | vasc | bbl |
| 18:11.56 | Notify | 03BRL-CAD Wiki:85.246.127.87 * 8526 /wiki/User:Vasco.costa/GSoC15/logs: |
| 18:12.19 | Notify | 03BRL-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.00 | Notify | 03BRL-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.31 | Notify | 03BRL-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.16 | brlcad | vasc: gcc's warning reporting has actually gotten rather advanced in the last couple years in particular -- it's almost never wrong ... |
| 20:47.59 | brlcad | so much so that I'd wager it's almost absurd to disable a warning unless there's a system header involved |
| 20:50.36 | brlcad | both llvm and gcc now basically use a form of advanced graph-based quasi-regex-style pattern matching to detect conditions |
| 20:51.00 | brlcad | coverity used to be the only shop in town using that method, but the open source kids are growing up fast :) |
| 20:52.21 | vasc | i upgraded my distro and gcc and now i get this: |
| 20:52.45 | vasc | home/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.45 | vasc | <PROTECTED> |
| 20:52.45 | vasc | <PROTECTED> |
| 20:52.45 | vasc | In file included from /home/vasco/brlcad/src/other/stepcode/src/clutils/gennodearray.h:25:0, |
| 20:52.45 | vasc | <PROTECTED> |
| 20:52.49 | vasc | /usr/include/string.h:50:14: error: from previous declaration void* memmove(void*, const void*, size_t) throw () |
| 20:52.52 | vasc | <PROTECTED> |
| 20:52.54 | vasc | <PROTECTED> |
| 20:52.56 | vasc | src/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.59 | vasc | make[2]: *** [src/other/stepcode/src/clutils/CMakeFiles/steputils.dir/gennodearray.cc.o] Error 1 |
| 20:53.01 | vasc | repeated like 8 times |
| 20:53.03 | vasc | dunno if i need to re-run cmake or what |
| 20:53.51 | brlcad | yep.. every upgrade they have been introducing new detections .. pretty exciting stuff! |
| 20:53.55 | vasc | for whatever reason i thinks i don't have a memmove declared somewhere and then redeclares it |
| 20:54.11 | vasc | and the new declaration is different |
| 20:54.11 | Stragus | I find the "might be unused" warnings are often wrong, eh |
| 20:55.03 | brlcad | Stragus: I haven't seen one wrong in .. years, at least not technically wrong if you follow the data |
| 20:55.13 | brlcad | many that seemed wrong |
| 20:55.15 | vasc | i 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.41 | vasc | but its good if they're better at it now |
| 20:56.10 | brlcad | I have a history of chasing them down, even if they are false positives, as even those tend to be bad-smelling code |
| 20:56.43 | Stragus | brlcad, 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.44 | brlcad | the biggest source I've seen are issues that cannot be worked around (bugs or deficiencies in system headers) |
| 20:57.45 | brlcad | Stragus: I'd be happy to inspect a case you think is a false positive if it's ever handy |
| 20:58.30 | brlcad | I've inspected cases far more complex than some bit fiddling too |
| 20:58.39 | brlcad | like I said, it's been years |
| 20:59.30 | vasc | oops. i did one rm -rf too much |
| 20:59.35 | Stragus | I'm always silencing that warning since I get too many false positives with SSE |
| 20:59.36 | brlcad | vasc: if you don't want to deal with those warnings, you can turn them off during cmake |
| 20:59.53 | brlcad | SSE and asm code I can easily see causing false positives |
| 21:00.04 | brlcad | but then that's technically leaving C |
| 21:00.06 | Stragus | Like modifying only the lower 64 bits of a 128 bits XMM, which implies reading it, and GCC complains |
| 21:00.27 | brlcad | (asm that is) |
| 21:01.26 | Stragus | Even if you build your xmm variable just by writing the lower 64 bits then the upper 64 bits, gcc complains |
| 21:02.06 | brlcad | would need to see a specific example, way too many variables |
| 21:02.26 | vasc | it messes up with union types? |
| 21:03.15 | Stragus | Unions are fine, in my experience |
| 21:03.47 | brlcad | Stragus: it wasn't a challenge to say that they're not possible :) |
| 21:04.21 | brlcad | it'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.30 | vasc | i just nuked the simple .g files i made to test the primitives. oops |
| 21:04.55 | vasc | i used to think that was true |
| 21:05.12 | brlcad | vasc there is a slew of sample .g files in the share/db build dir |
| 21:05.12 | vasc | until i was doing my final course project and found a bug in templates with ms visual studio c++ 6.0 |
| 21:05.30 | vasc | which they fixed in sp4 i think |
| 21:05.35 | brlcad | msvc is a different beast -- all bets off there :) |
| 21:06.14 | vasc | i still remember the wesnoth game devs complaining a lot about c++ support in gcc as well |
| 21:06.23 | vasc | i never had many issues with it because i usually code in c |
| 21:06.38 | vasc | i only use c++ quite sparingly |
| 21:06.39 | Stragus | That's unexpected, GCC's support for the standards is pretty good |
| 21:06.54 | vasc | well this was nearly a decade ago |
| 21:06.54 | Stragus | Unlike MSVC which still only supports C89 (come on!) |
| 21:06.56 | brlcad | we hit a slew of issues in bzflag too, but mostly were portability-related |
| 21:06.58 | vasc | things could have changed |
| 21:07.06 | brlcad | (bz is c++) |
| 21:07.55 | vasc | there was a time when i was enamoured with the object oriented fluff but i quickly grew out of it |
| 21:08.02 | Stragus | brlcad, 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.16 | Stragus | I assume they silenced a bunch of warnings that were often wrong |
| 21:08.22 | Stragus | SSE/AVX still causes some issues |
| 21:08.24 | brlcad | Stragus: msvc technically is a C++ compiler that happens to support C89 -- they directly said they had no intention of ever supporting C99 |
| 21:08.45 | vasc | its ms. they are idiots. |
| 21:08.59 | brlcad | they 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.33 | vasc | i actually liked c# though |
| 21:09.33 | Stragus | As long as you do a #define restrict __restrict and such, yes |
| 21:10.31 | vasc | its much better than java. java's basic type system is whacked. |
| 21:10.59 | vasc | it was kludged and kludged and nobody wants to rewrite it |
| 21:11.16 | vasc | want unsigned ints? fast floats? good luck. |
| 21:11.42 | vasc | i think the DoD once even paid Sun to fix their broken FP performance in Java at once point |
| 21:12.03 | vasc | which they 'fixed' by inventing a new programming language that no one uses |
| 21:12.21 | Stragus | Using Java when you care about performance is a mistake |
| 21:12.21 | vasc | i think it was called fortress |
| 21:12.30 | Stragus | Not as bad as using Python, but still a mistake |
| 21:13.15 | vasc | i really like python |
| 21:13.21 | vasc | for prototyping its great |
| 21:13.45 | vasc | or doing scripts and things like that |
| 21:18.51 | vasc | the thing is java could have a lot faster performance on FP than it has |
| 21:18.57 | vasc | but the type system is totally broken |
| 21:19.44 | vasc | its never going to be faster than c++ or c but |
| 21:33.02 | vasc | there are virtual machines for python btw |
| 21:34.14 | vasc | pypy and there used to be psyco |
| 21:34.56 | vasc | i think i was playing that ddr clone game once and it was written in python and compiled with pypy |
| 21:35.28 | vasc | ah no it was the frets on fire game |
| 22:12.05 | Notify | 03BRL-CAD Wiki:Konrado DJ * 8528 /wiki/User:Konrado_DJ/GSoc2015/logs: /* 1 JUNE 2015 */ |
| 22:14.30 | vasc | hmm |
| 22:24.11 | vasc | hope i didn't delete too much code |
| 22:24.34 | vasc | nope |
| 22:26.13 | vasc | ok i cut the ray casting code to the bare bones |
| 22:26.21 | vasc | ray generation |
| 22:26.36 | vasc | now the problem is the hierarchy traversal bool weaving and whatever |
| 22:26.56 | vasc | i gotta cut it all down into just testing with all the objects without traversing bsps and things like that |
| 22:28.22 | vasc | man 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.06 | vasc | don't wanna deal with that now but eventually this needs to be redone too |
| 22:32.01 | vasc | oh i see it calls a view_eol function in the end which does zip |
| 22:32.05 | vasc | another thing to delete |
| 22:32.46 | vasc | it probably did something at some point i guess |
| 22:39.23 | vasc | neat. well i just cut away supersampling, and jittered sampling and so on |
| 22:39.35 | vasc | but we have to start someplace and its just too much noise at this point |
| 22:39.59 | vasc | no more branching |
| 22:59.32 | Notify | 03BRL-CAD Wiki:Deekaysharma * 8529 /wiki/User:Deekaysharma/logs: |
| 23:03.44 | vasc | uhoh |
| 23:04.46 | vasc | the ray segments are stored in a linked list of indetermined size |
| 23:04.50 | vasc | that's baddddd... |
| 23:05.24 | vasc | i'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.45 | vasc | so much for that |
| 23:06.39 | vasc | i guess i could run the algorithm TWICE. one to know how much memory i need and another to store the segments themselves |
| 23:06.46 | vasc | but i wonder how slow that will be.... |
| 23:07.20 | vasc | oh well don't have a better plan now |
| 23:09.07 | Notify | 03BRL-CAD Wiki:85.246.127.87 * 8530 /wiki/User:Vasco.costa/GSoC15/logs: /* Development Phase */ |
| 23:32.40 | Stragus | Linked list of ray segments? Darn |
| 23:34.01 | Stragus | I 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.23 | Stragus | My 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.33 | Stragus | The user can still buffer up if he really wants to |
| 23:37.51 | Notify | 03BRL-CAD:starseeker * 65158 brlcad/trunk/src/librt/db_diff.c: Use ft_internal_size from the functab. |
| 23:58.14 | vasc | hmm |
| 23:58.49 | vasc | that reminded me of something |
| 23:58.59 | vasc | ah but it won'twork |
| 23:59.25 | vasc | i think i'll just do everything twice |
| 23:59.34 | Stragus | That sounds terrible |
| 23:59.43 | Stragus | What's wrong with preallocating X segments per ray? |
| 23:59.47 | vasc | yeah. it SOUNDS terrible |
| 23:59.54 | vasc | but memory allocation is slow too |