IRC log for #brlcad on 20180322

01:08.28 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
01:19.43 *** join/#brlcad vjxtranqtzdgdncl (~armin@dslb-178-010-187-110.178.010.pools.vodafone-ip.de)
07:09.19 *** join/#brlcad gabbar1947 (uid205515@gateway/web/irccloud.com/x-rffgqfouvdnfaccp)
09:44.17 *** join/#brlcad gabbar1947 (uid205515@gateway/web/irccloud.com/x-neoittfxjavyldlk)
10:46.18 *** join/#brlcad merzo (~merzo@185.39.197.205)
11:07.55 *** join/#brlcad skat00sh_ (uid103741@gateway/web/irccloud.com/x-lstdyxxpvkcgxlay)
11:35.43 *** join/#brlcad raingloom (~raingloom@C2267141.catv.pool.telekom.hu)
12:33.10 *** join/#brlcad AdityaGulati (ca034dcc@gateway/web/cgi-irc/kiwiirc.com/ip.202.3.77.204)
13:02.29 brlcad starseeker: that model is seriously cool .. looks like we might need to either fix step214 or iges import support to get that one :)
13:18.19 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
13:21.03 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
13:21.48 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
13:22.38 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)
13:46.09 *** join/#brlcad yorik (~yorik@2804:431:f720:db49:290:f5ff:fedc:3bb2)
14:44.50 *** join/#brlcad yorik (~yorik@2804:431:f720:db49:2268:9dff:fef9:3113)
15:03.54 brlcad starseeker: seems like it would be easier to just add condwait to bu for now
15:04.13 brlcad and whatever else it's using
15:04.14 brlcad then get rid of tinycthread
15:05.19 *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51)
15:23.43 *** join/#brlcad DenisP (d40d70a2@gateway/web/freenode/ip.212.13.112.162)
15:31.53 *** join/#brlcad merzo (~merzo@185.39.197.205)
16:28.46 *** join/#brlcad merzo (~merzo@185.39.197.205)
16:29.38 *** join/#brlcad raingloom (~raingloom@C2267141.catv.pool.telekom.hu)
16:37.35 brlcad regardless, we really shouldn't be mixing licenses per file .. that's going to be really tricky to manage after the motivation is long forgotten
17:27.13 starseeker brlcad: i can pull the bits out of tienet into separate files
17:28.39 starseeker or shove things into libbu - either way
17:29.00 starseeker that was a "shortest path to get things running" solution
18:13.08 starseeker wants to take another look at mmthreads.h after the release for C
18:14.38 Stragus If you are going to use that, I can clean up a little
18:14.55 Stragus Especially the custom stack option which is just ignored and doesn't work on Windows
18:15.04 Stragus (not my fault, Windows doesn't _allow_ it)
18:16.28 Stragus Which is somewhat messed up. In a NUMA system, I want to allocate the stack of the threads on the NUMA nodes that belong to the CPU cores I'm going to lock the threads on
18:18.40 starseeker Stragus: at some point I definitely want to look at updating the decimation code (IIRC, you said you had improved its robustness to some problem cases?) which means taking another look at how we integrate that code generally
18:20.27 Stragus Right. I could have a few other interesting pieces too
18:20.49 starseeker we had to do a lot of modding originally to make it fit in the BRL-CAD framework - I'd like to take a more careful look at that this time around
18:21.16 starseeker part of it is we tend to use configure tests and definitions rather than hard-coding platform specific pieces
18:22.11 Stragus *nod* I'm not generally fond of depending on the build process, I like when source code is independent of that
18:23.28 starseeker perhaps we could come up with some sort of middle ground where the configure defined flags are used if set, but ignored if unset...
18:23.38 Stragus Sounds perfect
18:29.32 starseeker with newer standards things should go a bit more smoothly, but I know you tend to pay attention to the details of compiler versions and what they support so I expect there will still be some work to do...
18:30.17 Stragus Just to clarify, this is the kind of stuff you don't like? #if __SSE2__ || defined(_M_X64) || ( defined(_M_IX86_FP) && ( _M_IX86_FP >= 2 ) )
18:31.01 starseeker Stragus: I'd want to rope brlcad into the discussion and see how we would want to handle situations like that
18:31.43 starseeker I understand why you're doing it, so the question would be how to match brlcad's design philosophy for build systems with those needs
18:32.41 Stragus Seems like tagging some extra checks to such lines should be able to incorporate configure-time options
18:38.41 brlcad starseeker: daniel reports that 70840 works for him again (presumably on windows)
18:38.52 brlcad Notify: hello?
18:41.52 brlcad it's usually not a matter of liking or not liking hardware/compiler flags, particularly when a bit of code has been made to work on such a broad range of environments that it typically just works, even on unseen platforms
18:43.26 brlcad the problem is usually when that code is not portable to different compilers, different hardware, doesn't have fallback cases, doesn't gracefully behave on things like openbsd or intel's compiler or an HPUX supercomputer or other less "popular" but perfectly valid environments
18:46.32 brlcad with our imminent adoption of c++11, a lot of the API arcanity will just go away but the portability issue conceptually remains
18:47.28 brlcad it would be good to finally get fast robust decimation ...
19:25.08 *** join/#brlcad merzo (~merzo@185.39.197.205)
19:36.08 Stragus Right. I believe I try to always have fallbacks, without SIMD or atomics...
19:40.15 Stragus Or perhaps now I do, more so than 7 years ago, it has been a long time since I contributed code
19:42.39 brlcad nods
19:43.07 brlcad just looking at your recent mmthread header, it's definitely looking more robust than the last revision we integrated
19:57.42 brlcad starseeker: and sean reports that 70841 works for him (on mac) ;)
20:29.38 *** join/#brlcad AdityaGulati (ca034dcc@gateway/web/cgi-irc/kiwiirc.com/ip.202.3.77.204)
22:26.01 *** join/#brlcad merzo (~merzo@239-13-133-95.pool.ukrtel.net)
22:55.05 *** join/#brlcad kintel (~kintel@unaffiliated/kintel)

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