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) |