| 00:33.50 | *** join/#brlcad xodjdvyxvkyfsivy (~armin@dslb-088-066-148-051.088.066.pools.vodafone-ip.de) | |
| 00:36.21 | brlcad | starseeker: thanks for the tarball info .. I've got no sense how risky or safe an autodetect build is right now given we're several years since last full release, so fine either way |
| 00:36.37 | brlcad | don't think we should do /opt until next release, but good to know |
| 00:37.02 | brlcad | does fontconfig not have a cmake build? |
| 00:41.02 | brlcad | if it does, I'd say just comment them all out and leave 'em alone |
| 00:45.19 | Notify | 03BRL-CAD:brlcad * 68645 brlcad/trunk/TODO: old bugs are not necessarily priority, nor are 'newer' ones that have now become really old. restoring shelved code is important, though, as they will diverge quickly and cost more over time. |
| 00:57.04 | Notify | 03BRL-CAD:brlcad * 68646 brlcad/trunk/TODO: more time-sensitive code patches; add another exponential algorithm noticed |
| 02:58.49 | Notify | 03BRL-CAD:brlcad * 68647 brlcad/trunk/TODO: promote items specifically important to the next two months and demote items not strictly necessary (because they've not new issues) |
| 04:12.29 | *** join/#brlcad KimK (~Kim__@2600:8803:7a85:6d00:1caf:7123:9f:4304) | |
| 04:25.32 | *** join/#brlcad tandoorichick (3d0c28b1@gateway/web/freenode/ip.61.12.40.177) | |
| 04:40.29 | Notify | 03BRL-CAD:brlcad * 68648 brlcad/trunk/src/libfb/if_ogl.c: test impact of making delayed writes the default. boosts interactive performance of transient buffers. the slowdown caused by flushing updates is more than an order of magnitude now and unbearably increases as the framebuffer size increases. |
| 04:48.16 | Notify | 03BRL-CAD:brlcad * 68649 brlcad/trunk/src/libfb/if_wgl.c: ditto on windows, give delayed writes a trial test. |
| 05:01.52 | Notify | 03BRL-CAD:brlcad * 68650 brlcad/trunk/NEWS: might not survive release, but definitely user-visible if it does. changed framebuffers to delay writes until the full frame is complete. this is worse usability on long-run rendering since there's no interactive feedback, but considerably better usability on the more common case of things that take sub-second or even sub-minute rendering time. hopefully the osg |
| 05:01.54 | Notify | framebuffer will make this all obsolete. |
| 05:01.56 | Notify | ... |
| 06:48.03 | *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee) | |
| 06:50.25 | *** join/#brlcad tandoorichick (b64b2de1@gateway/web/freenode/ip.182.75.45.225) | |
| 07:11.00 | *** join/#brlcad d_rossberg (~rossberg@104.225.5.10) | |
| 07:19.59 | Notify | 03BRL-CAD:brlcad * 68651 (brlcad/trunk/include/dm.h brlcad/trunk/src/libdm/dm-Null.c and 9 others): dm_reshape() was declared and is in the callback table, but was not implemented. provide it, and change the return type to be consistent with the other callbacks. |
| 07:30.43 | Notify | 03BRL-CAD:brlcad * 68652 brlcad/trunk/src/mged/mged.c: spent some time debugging the mac initialization issue. looks like it's ogl-specific and double-buffer-specific, fixed by doing a swap buffer after 'gui' command completes. this is achieved by calling dm_set_bg(). several dm funcs swap the backbuffer, but setting the color explicitly gives clear intent despite it being unclear why this is needed or why the |
| 07:30.45 | Notify | front buffer contains garbage. |
| 07:30.47 | Notify | ... |
| 08:38.43 | *** join/#brlcad teepee] (bc5c2134@gateway/web/freenode/ip.188.92.33.52) | |
| 11:25.23 | *** join/#brlcad tandoorichick (3d0c28b1@gateway/web/freenode/ip.61.12.40.177) | |
| 11:39.35 | starseeker | brlcad: fontconfig doesn't have a cmake build. I'm tempted to wait on it until we do the svn external thing and try treating it as an external project under that system, since it was always the need to do make install first that caused a big problem with combining the ExternalProject builds with our own |
| 11:40.09 | starseeker | fontconfig isn't needed on Windows, so there's no functionality gain to be had porting it there... |
| 12:13.22 | d_rossberg | tandoorichick: back at work again? |
| 12:18.06 | tandoorichick | d_rossberg: yes.. |
| 13:11.47 | *** join/#brlcad asad_ (~asad00@host10-2.natpool.mwn.de) | |
| 13:23.00 | starseeker | blinks... |
| 13:23.14 | starseeker | The following tests FAILED: |
| 13:23.14 | starseeker | <PROTECTED> |
| 13:23.25 | starseeker | that's with strict build off |
| 13:23.33 | starseeker | it succeeds with it on |
| 13:55.32 | *** join/#brlcad sniok (~sniok@89.252.29.238) | |
| 13:57.25 | *** join/#brlcad amarjeet (~amarjeet@101.211.243.215) | |
| 14:08.22 | starseeker | ah, wait - might be my setup here... |
| 14:15.53 | *** join/#brlcad amarjeet (~amarjeet@101.211.243.215) | |
| 14:39.15 | *** join/#brlcad amarjeet (~amarjeet@101.211.243.215) | |
| 14:41.00 | *** join/#brlcad sniok (~sniok@89.252.29.238) | |
| 14:56.33 | *** join/#brlcad yorik (~yorik@187.57.207.104) | |
| 15:05.46 | *** join/#brlcad sniok_ (~sniok@89.252.29.238) | |
| 15:23.26 | starseeker | nope, still failing |
| 15:26.18 | d_rossberg | tandoorichick: don't forget to update your development log |
| 15:29.07 | *** join/#brlcad amarjeet (~amarjeet@101.211.222.24) | |
| 15:59.44 | *** join/#brlcad Mandeep_Singh (~mandeep@117.220.146.135) | |
| 16:09.42 | *** join/#brlcad amarjeet (~amarjeet@101.211.236.25) | |
| 16:16.19 | *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee) | |
| 16:25.05 | *** join/#brlcad amarjeet (~amarjeet@101.211.236.25) | |
| 17:03.19 | *** join/#brlcad amarjeet (~amarjeet@101.211.236.25) | |
| 17:03.58 | *** join/#brlcad sniok_ (~sniok@89.252.29.238) | |
| 17:26.33 | *** join/#brlcad amarjeet (~amarjeet@101.211.236.25) | |
| 17:34.57 | *** join/#brlcad amarjeet (~amarjeet@101.211.236.25) | |
| 18:20.29 | Notify | 03BRL-CAD:starseeker * 68653 brlcad/trunk/src/libbu/rb_diag.c: Do void cast for p printf type |
| 18:45.23 | starseeker | ok, this is really really weird |
| 18:46.16 | starseeker | as near as I can tell (or as gdb can tell) the return statement at bu_badmagic.c:75 is being skipped when we don't build strict |
| 18:49.53 | Notify | 03BRL-CAD:starseeker * 68654 brlcad/trunk/src/libbu/rb_diag.c: OK, gcc didn't like that. |
| 18:59.32 | ejno | starseeker: it seems the previous line calls bu_badmagic() which has _BU_ATTR_NORETURN but which does usually return |
| 19:48.18 | Notify | 03BRL-CAD:starseeker * 68655 brlcad/trunk/src/libbu/tests/bu_badmagic.c: When we turn off strict, the _BU_ATTR_NORETURN is causing problems with bu_badmagic in the test case (where we do in fact return.) Since we do return here, undo the _BU_ATTR_NORETURN locally. |
| 19:50.41 | starseeker | ejno: heh - nice job! you spotted it much quicker than Bob and I did |
| 19:51.51 | starseeker | we marked that as no return for the clang static analyzer to avoid a whole bunch of "technically accurate but not useful" paths it finds |
| 19:52.35 | starseeker | usually we bomb out if we hit bad magic, and apparently with the normal strict flags the compilers were letting us get away with it for the test case |
| 20:17.46 | brlcad | the function probably shouldn't have this bimodal behavior |
| 20:19.34 | brlcad | given we only directly use that function in like three places, we should probably pull the bomb out and make the caller call bomb itself |
| 20:19.51 | brlcad | let badmagic return a code |
| 20:20.19 | brlcad | true if bad, false otherwise, callers bomb on true |
| 21:07.30 | Notify | 03BRL-CAD:starseeker * 68656 (brlcad/trunk/CHANGES brlcad/trunk/include/bu/CMakeLists.txt and 7 others): Consolidate the red-black tree files into one .c file, rename header. Should compare this to the implementations in jemalloc (http://www.canonware.com/rb/), openbsd (http://www.canonware.com/download/rb/tree/) and sudo (https://github.com/millert/sudo/blob/master/plugins/sudoers/redblack.c) for correctness and |
| 21:07.32 | Notify | performance. |
| 21:07.34 | Notify | ... |
| 21:09.35 | Notify | 03BRL-CAD:starseeker * 68657 brlcad/trunk/src/libbu/tests/bu_badmagic.c: Explain why we're undeffing _BU_ATTR_NORETURN in this test. |
| 21:10.25 | starseeker | brlcad: sounds good to me |
| 21:11.07 | starseeker | I wasn't sure if there was some specific reason it was set up the way it was (is) |
| 21:13.24 | starseeker | wonders what *other* seldom-used configurations we should have in distcheck-full... |
| 21:24.41 | Notify | 03BRL-CAD:starseeker * 68658 brlcad/trunk/include/bu/redblack.h: fix header label |
| 21:24.45 | starseeker | has a feeling there's too much public API for the redblack trees... |
| 21:26.52 | starseeker | brlcad: should I go ahead and update our stepcode to the latest github srcs? I think I merged in most of the key changes from our local branch, but we'll need to rework our code slightly to use access methods for a ptr that Mark made private |
| 21:37.28 | Notify | 03BRL-CAD Wiki:Tandoorichick * 9814 /wiki/User:Tandoorichick/GSoC2016/Logs: /* Development Logs */ |
| 21:46.29 | *** join/#brlcad tandoorichick (b64b2d01@gateway/web/freenode/ip.182.75.45.1) | |
| 22:16.23 | *** join/#brlcad merzo (~merzo@188.173.16.122) | |