aserio changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irc.cct.lsu.edu/
vamatya_ has quit [Ping timeout: 268 seconds]
bikineev has quit [Remote host closed the connection]
Matombo has quit [Remote host closed the connection]
<github> [hpx] hkaiser force-pushed fixing_await from 10e32c4 to 4bbe3a0: https://git.io/v9Alv
<github> hpx/fixing_await 4bbe3a0 Hartmut Kaiser: Adapting to latest changes of TS...
hkaiser_ has quit [Quit: bye]
K-ballo has quit [Quit: K-ballo]
vamatya_ has joined #ste||ar
EverYoung has quit [Ping timeout: 258 seconds]
pree has joined #ste||ar
vamatya_ has quit [Ping timeout: 260 seconds]
thundergroudon has joined #ste||ar
thundergroudon has quit [Ping timeout: 246 seconds]
thundergroudon has joined #ste||ar
pree has quit [Ping timeout: 260 seconds]
Matombo has joined #ste||ar
thundergroudon has quit [Read error: Connection reset by peer]
thundergroudon has joined #ste||ar
Matombo has quit [Remote host closed the connection]
david_pfander has joined #ste||ar
jakemp has quit [Ping timeout: 260 seconds]
jakemp has joined #ste||ar
ABresting[m] has quit [Ping timeout: 240 seconds]
pree has joined #ste||ar
jakemp has quit [Ping timeout: 240 seconds]
jakemp has joined #ste||ar
thundergroudon has quit [Read error: Connection reset by peer]
thundergroudon has joined #ste||ar
pree has quit []
taeguk has joined #ste||ar
bikineev has joined #ste||ar
bikineev has quit [Ping timeout: 246 seconds]
bikineev has joined #ste||ar
bikineev has quit [Remote host closed the connection]
hkaiser has joined #ste||ar
<Smasher> hi hkaiser
<hkaiser> hey
<Smasher> it seems your patch fixed my serialization problem
<hkaiser> \o/
<Smasher> :)
<Smasher> but i bumped into the next error now
<hkaiser> hah, surprise, suprise
<Smasher> and luckily i know now how not to blame hpx on that :))
<Smasher> but that stacktrace doesnt make any sense to me: http://sprunge.us/dDLH
<Smasher> hpx_zfm_fingerprint_provider.cxx:32 is fclose(bmpfile);
<Smasher> and the head of the trace points to __parse_one_specwc
<Smasher> which is printf parsing?
<hkaiser> no idea
<Smasher> i also tried https://git.io/v9AqQ
<Smasher> still getting object too big message
<hkaiser> what object too big message?
K-ballo has joined #ste||ar
<Smasher> hkaiser while building hpx as debug
<Smasher> related to addressing_service
<hkaiser> Smasher: ok, you could split this file in two
ABresting[m] has joined #ste||ar
eschnett has quit [Quit: eschnett]
<thundergroudon> I was building hpx on a new machine
ABresting[m] has quit [Ping timeout: 255 seconds]
<thundergroudon> Severity Code Description Project File Line Suppression State
<thundergroudon> Error C2719 'in': formal parameter with requested alignment of 8 won't be aligned async_io_external_exe z:\gsoc\hpx\hpx\components\iostreams\server\output_stream.hpp 43
<thundergroudon> building on Windows with Visual Studio 2015
ABresting[m] has joined #ste||ar
<thundergroudon> MSVC 140
<Smasher> i know somebody who uses msvc too :)
<thundergroudon> There are several such errors but all of them are similar
<hkaiser> thundergroudon: is this caused by hpx itself or your code?
<thundergroudon> @hkaiser, caused by hpx
<thundergroudon> installing in a new machine
<hkaiser> thundergroudon: I have never seen this before
<hkaiser> how have you built hpx?
<hkaiser> what cmake settings?
<thundergroudon> I am not sure if this is because of configuration
<thundergroudon> running cmake 3.8.1, with BOOST_ROOT and HWLOC_ROOT
<hkaiser> I'm not sure either
<hkaiser> can you give me the build log, pls?
<hkaiser> what file is failing to compile?
<thundergroudon> output_stream.hpp
<thundergroudon> and this is being caused in multiple places
<hkaiser> no, that's not the translation unit causing it
<hkaiser> pls link the build log somewhere
<thundergroudon> I am rebuilding it, takes some time
<thundergroudon> will put the link here in a while
<Vir> MSVC shows this error for by value parameters where you specify a custom alignment (alignas)
<hkaiser> yah, that's what I thought - but we don't do that, normally
<hkaiser> not in HPX
<Vir> 8 sounds like it isn't Vc
<Vir> just use __vectorcall ;-)
ABresting[m] has quit [Ping timeout: 240 seconds]
ABresting[m] has joined #ste||ar
<hkaiser> Vir: Vc is disabled by default, I don't think this problem is caused by it
<Vir> nevertheless, __vectorcall should resolve the issue
<Vir> AFAIK __vectorcall is the only "sane" calling convention on Windows
<hkaiser> Vir: let's first see what the issue is
<Vir> sure
<hkaiser> Vir: might be, HPX does,t build with vectorcall out of the box, though - I tried
thundergroudon has quit [Ping timeout: 246 seconds]
thunderGroudon|2 has joined #ste||ar
<thunderGroudon|2> Build is only half done, taking much longer than usual
bikineev has joined #ste||ar
eschnett has joined #ste||ar
<thunderGroudon|2> please search for ': error'
<thunderGroudon|2> coz the document is way too long
<thunderGroudon|2> hkaiser: please take a look
bikineev has quit [Remote host closed the connection]
mcopik has joined #ste||ar
bikineev has joined #ste||ar
<hkaiser> thunderGroudon|2: what compiler is that?
<thunderGroudon|2> The CXX compiler identification is MSVC 19.0.24215.1
<hkaiser> is that a 32bit build?
<thunderGroudon|2> it is msvc
<thunderGroudon|2> yes 32 bit build
<hkaiser> ok, I'd strongly suggest not to do a 32 bit build, but build for 64bits
<hkaiser> I have not looked into building for 32 bits in a while
<thunderGroudon|2> is that what's causing the error?
<hkaiser> yes
<thunderGroudon|2> I shall try switching to 64 bit build
<zao> I don't remember if I had any problems last I tried building HPX for Win32, as it didn't fit into my existing application in other ways that made it unusable.
<hkaiser> also, 32bit builds of hpx are severly hampered by a windows system limitation
<hkaiser> thunderGroudon|2: but I will go back and try to make it work for 32bits again
<thunderGroudon|2> Sure! I shall also let you know if 64 bit build is successful
<hkaiser> thanks
<diehlpk_work> hkaiser, Thanks. I only test HPXCL on linux
<hkaiser> diehlpk_work: what are you talking about?
<diehlpk_work> On the problem of thunderGroudon|2
<hkaiser> ahh
<hkaiser> sure, any time
<diehlpk_work> Oh, sorry just realized that it is about hpx
<hkaiser> thunderGroudon|2: btw, the cmake scripts should have given you a warning about not using 32bit builds on windows
<diehlpk_work> I assumed it is about hpxcl
<thunderGroudon|2> hkaiser: It did!
<hkaiser> diehlpk_work: that will come next ;)
<hkaiser> diehlpk_work: I have not tried building hpxcl in a while either
<thunderGroudon|2> last time I did 64 bit build on another machine, both hpx and hpxcl was successful
<diehlpk_work> on linux it compiles, because we have the circle-ci test
<hkaiser> right
<github> [hpx] hkaiser closed pull request #2632: Making sure container serialization uses size-compatible types (master...fixing_container_serialization) https://git.io/v9bHO
pree has joined #ste||ar
<K-ballo> http://irc.cct.lsu.edu/ is down?
<hkaiser> K-ballo: they have changed the domain one more time, I think
<hkaiser> need to find out what the final name will be today
hkaiser has quit [Quit: bye]
aserio has joined #ste||ar
bikineev has quit [Ping timeout: 260 seconds]
shoshijak has joined #ste||ar
aserio changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/
<Smasher> very rebuild - every time new errors to see :)
<Smasher> what does that mean? {what}: assertion 'pp ? pp->here() == pp->agas_locality(cfg) : true' failed: HPX(assertion_failure)
<Smasher> trace http://sprunge.us/KjgP
hkaiser has joined #ste||ar
<Smasher> hkaiser repasted in a pm to you my messages i just posted here
pree has quit []
akheir has joined #ste||ar
<hkaiser> akheir: what is the new url for the irc logger?
<hkaiser> akheir: nvm, got it from the topic ;)
<akheir> hkaiser: it's irclog.cct.lsu.edu
<hkaiser> thanks
<akheir> hkaiser: ;)
shoshijak has quit [Remote host closed the connection]
aserio1 has joined #ste||ar
aserio has quit [Ping timeout: 245 seconds]
aserio1 is now known as aserio
bikineev has joined #ste||ar
hkaiser has quit [Quit: bye]
EverYoung has joined #ste||ar
aserio has quit [Ping timeout: 255 seconds]
hkaiser has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
<Smasher> sigh
<Smasher> never ending exceptions
<Smasher> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<hpx::exception> >' what(): HPX(unknown_error):
aserio has joined #ste||ar
<Smasher> my protocol seems to start working but then.. blam!
<Smasher> Thread 1 received signal SIGABRT, Aborted.
<Smasher> [Switching to Thread 8451.8451]
<Smasher> killpg (pgrp=0, sig=-1090526248) at ../sysdeps/posix/killpg.c:30
<Smasher> no idea what's wrong :(
akheir has quit [Remote host closed the connection]
<Smasher> backtrace looks odd
<Smasher> #0 killpg (pgrp=0, sig=-1090526248) at ../sysdeps/posix/killpg.c:30
<Smasher> #1 0xfffffffe in ?? ()
<hkaiser> Smasher: use gdb, catch throw, look at stack backtrace
<Smasher> that's what i did hkaiser
<Smasher> i catch only that SIGABRT
<Smasher> mhmhm, maybe that exception is thrown on the oder node?
<Smasher> lets start both in gdb (oh dear )
ABresting[m] has quit [Ping timeout: 272 seconds]
bikineev has quit [Ping timeout: 260 seconds]
bikineev has joined #ste||ar
<aserio> wash: will you be joining us today?
<Smasher> do you have something like daily meeting? :)
<aserio> Smasher: no, we have a weekly meeting
<aserio> hkaiser: ^^
<Smasher> aserio i c
hkaiser has quit [Quit: bye]
justwagle has joined #ste||ar
<zao> I strongly recommend digging into the current SLURM codebase. So many off-by-ones, pointer corruption, and more.
<zao> No pointer should ever end with 5.
<zao> (to non-char)
akheir has joined #ste||ar
hkaiser has joined #ste||ar
<K-ballo> packed bits?
EverYoung has joined #ste||ar
<zao> Boring old corrupt state.
<zao> Users get super happy when SLURM blows up, btw.
<zao> I'm sure you people are familiar with failing batch systems and clusters.
<K-ballo> scary
<taeguk> Excuse me, I have a question. What is the intent of the following code? (https://github.com/STEllAR-GROUP/hpx/blob/master/examples/quickstart/fibonacci_dataflow.cpp#L43-L44)
<taeguk> for fast construction of dependency tree?
<K-ballo> the intent is to execute those in parallel
<hkaiser> taeguk: it's an experiment, essentially
EverYoung has quit []
<taeguk> It is curious that hpx::async for the fibonacci function that returns hpx::future still returns hpx::future, not hpx::future<hpx::future<std::uint64_t>>.
<K-ballo> IIRC it doesn't, hpx::async still returns future<future<T>> and it is implicitly unwrapped when assigned to future<T>
vamatya_ has joined #ste||ar
<K-ballo> (unless it was changed recently to do the unwrapping at the `async` level)
<K-ballo> side-note: this looks like it might be obsolete https://github.com/STEllAR-GROUP/hpx/blob/master/hpx/async.hpp#L34 now
<taeguk> I think that there is waiting for unwrapping future<future<T>>, return value of fibonacci function in line 43.
<taeguk> So, I think there are no advantages to calling hpx::async in line 43.
hkaiser has quit [Quit: bye]
ABresting has joined #ste||ar
<K-ballo> no, or at least it shouldn't, if it was blocking it would defeat the purpose
<K-ballo> (meaning it'd be a bug in the implicit unwrapping implementation)
pree has joined #ste||ar
bikineev has quit [Ping timeout: 240 seconds]
EverYoung has joined #ste||ar
akheir has quit [Remote host closed the connection]
justwagle has quit [Quit: Leaving]
thunderGroudon|2 has quit [Read error: Connection reset by peer]
ajaivgeorge has joined #ste||ar
<taeguk> K-ballo: waiting for implicit wrapping is performed when lhs_future is moved in line 53. Right?
<K-ballo> taeguk: no
<taeguk> As I experimented, I assume that.
<K-ballo> as I said, implicit unwrapping is not meant to add any waiting
<K-ballo> if you experience any waiting you would have found a bug, please create a small repro
<K-ballo> though I suppose that's a tricky thing to observe deterministically, isn't it?
<K-ballo> moving a future is just swapping some pointers
<taeguk> I mean that implicit unwrapping is registered to lhs_future, and that implicit unwrapping is performed when lhs_future is moved.
<K-ballo> no, why?
ajaivgeorge has quit [Ping timeout: 240 seconds]
<taeguk> This is my modification for testing: https://gist.github.com/taeguk/0c4514ad3ec590701d104803fbb2e1da
<taeguk> And result:
<K-ballo> what's different, other than indentation?
<taeguk> And result is showed in comment.
mcopik has quit [Ping timeout: 240 seconds]
thundergroudon has joined #ste||ar
<K-ballo> I'm not sure what to read there, guide me?
<taeguk> That outputs mean recursive call tree.
<K-ballo> it doesn't, but sure let's say it does.. how would I observe implicit unwrapping in that tree?
<taeguk> sorry, " that implicit unwrapping is performed when lhs_future is moved." is my mistake.
<taeguk> Hmm, implicit unwrapping is executed when we need the value of future. is it right?
<taeguk> In that output, I assume that.
<K-ballo> implicit unwrapping is "executed" whenever the inner future is made ready
<K-ballo> nothing you do to lhs_future will trigger implicit unwrapping
<taeguk> Okay, I got it. But still, I have a doubtful point
<K-ballo> ask away
<taeguk> I put busy loop between hpx::async and fibonacci.
<taeguk> I assume that fibonacci in hpx::async is executed earlier than raw fibonacci call.
<taeguk> But, as a result, my assumption is incorrect.
<K-ballo> not necessarily
<K-ballo> async(fibonacci) is executed asynchronously, it's unsequenced with respect to the rest of the function
<K-ballo> what are you trying to observe, exactly?
<K-ballo> with the prints and the busy loops?
<taeguk> I just want to 'see' timings of async(fibonacci).
<taeguk> But after seeing, the result is strange.
<taeguk> Hmm. ah
<taeguk> hmm..
<K-ballo> like, the wall time when fibonacci is entered/exit?
<taeguk> no just sequence of fibonacci calls.
<K-ballo> ok, but they are unsequenced, so what kind of result would you expect?
<taeguk> I can't understand why async(fibonacci) is not executed when busy loop.
<taeguk> When busy loop, HPX scheduler is not working?
<K-ballo> no, HPX is cooperative multithreading
<K-ballo> if you keep the thread busy with a busy loop then it can't be used to do something else
<K-ballo> try replacing the busy loop with hpx::this_thread::yield()
<K-ballo> note however that this also guarantees nothing about order
<K-ballo> the calls are unsequenced, so there is any number of potential serializations
aserio has quit [Ping timeout: 258 seconds]
david_pfander has quit [Ping timeout: 260 seconds]
<taeguk> Ah, I got it.
<taeguk> async(fibonacci) is deferred in that case.
<K-ballo> mmmh.. maybe, depends on terminology.. do you mean deferred as in deferred futures? no
<taeguk> I doesn't mean..
<K-ballo> there's a property of some futures called "deferred", the future returned by async(fibonacci) does not have that property
<taeguk> I understand.
<taeguk> Maybe that's my mistake about terminology.
<taeguk> I just want to mean it to the result in only that case.
<taeguk> not fundamently
<taeguk> *fundamentally
hkaiser has joined #ste||ar
<taeguk> Okay, thank you so much, K-ballo !
EverYoun_ has joined #ste||ar
<wash> aserio: Sorry, forgot to send a mail. I am at C++NOw this week so no
EverYoun_ has quit [Remote host closed the connection]
<K-ballo> taeguk: before you go.. how many OS threads are you executing that example with?
EverYoun_ has joined #ste||ar
<taeguk> intel i7-3770 (4 core, 8 logical processor)
david_pf_ has joined #ste||ar
<K-ballo> and how many OS threads are you specifying? -t1? -t4? -threads=all?
<taeguk> not specified
<taeguk> oh
<K-ballo> ok, so the scheduler has only one thread to share
<taeguk> I got it....
<taeguk> mistery is gone away exactly!
<K-ballo> which means that it can only schedule whenever the running thread waits
EverYoung has quit [Ping timeout: 246 seconds]
<taeguk> I was falled into a trap called single thread :(
<taeguk> In single thread, that mystery is proved.
<K-ballo> sorry, I thought you were trying to diagnose a bug in the implicit unwrapping, should have realized earlier
<taeguk> I think it is a good experience :)
<taeguk> Next time, I never executed examples in single thread..
<taeguk> I forgot in default, single thread. :(
<K-ballo> wouldn't say never, sometimes doing so it's very useful
<K-ballo> helps understand how threads have to cooperate
<taeguk> Okay, you're right.
<taeguk> Thank you so much, K-ballo. Good day~
<github> [hpx] hkaiser opened pull request #2635: Fixing 32bit msvc (master...fixing_32bit_msvc) https://git.io/v9pJ1
mcopik has joined #ste||ar
<github> [hpx] hkaiser force-pushed fixing_32bit_msvc from 65a49e0 to 1b3488c: https://git.io/v9pUt
<github> hpx/fixing_32bit_msvc 1b3488c Hartmut Kaiser: Fixing 32bit MSVC compilation...
<hkaiser> thundergroudon: I created a patch fixing the 32bit compilation problems you were seeing
<hkaiser> pls see #2635
<thundergroudon> hkaiser: Sure! I have since then shifted the build to 64-bit
<thundergroudon> everything compiles and installs properly
<thundergroudon> ;) haha
mcopik has quit [Ping timeout: 240 seconds]
<thundergroudon> I shall test the 32-bit build and report if this fixes
<hkaiser> ok, good
<hkaiser> thanks
<thundergroudon> Thanks for making the changes :)
<hkaiser> :D
<hkaiser> that's what we're here for
mcopik has joined #ste||ar
david_pfander has joined #ste||ar
justwagle has joined #ste||ar
justwagle has quit [Client Quit]
aserio has joined #ste||ar
<Smasher> is locality = node in hpx termination?
<Smasher> terminology*
<pree> Is Mr.parsa amini here ?
<K-ballo> parsa[w]: ^
<K-ballo> Smasher: uh, somewhat.. you can and sometimes want to have more than one locality within a single node
<pree> Thanks @k-ballo
<zao> K-ballo: So approximately a MPI task?
<zao> But less MPI? :)
<zao> Err, rank?
<zao> Whatever they call them.
<K-ballo> ...maybe?
<zao> An addressable instance of the HPX borg collective.
<Smasher> K-ballo so a node is virtually a single system
<Smasher> and a locality is a hpx subsystem
<Smasher> comprendre
akheir has joined #ste||ar
aserio has quit [Ping timeout: 246 seconds]
mcopik has quit [Ping timeout: 240 seconds]
<pree> Is it necessary to tell actions to execute on which locality ? If we don't specify it whether it will take hpx::find_here as a default one?
bikineev has joined #ste||ar
<Smasher> pree you can use new_(find_here()) however it would require that your class is copyable
<Smasher> in case you really really want to use your component only locally, there is local_new<>()
ABresting has quit [Ping timeout: 260 seconds]
Matombo has joined #ste||ar
<pree> For hpx_plain_actions instances whether this is sufficient to call the actions -> action_instance(hpx::find_here(),parameters). *parametrs to the global function
david_pf_ has quit [Quit: david_pf_]
aserio has joined #ste||ar
mcopik has joined #ste||ar
akheir has quit [Remote host closed the connection]
akheir has joined #ste||ar
<pree> Thank You @Smasher :)
<Smasher> pree what have you used now?
<K-ballo> pree: you can call actions directly or asynchronously, locally or remotely
<pree> new_(find_here()) @Smasher
Matombo has quit [Remote host closed the connection]
<Smasher> pree good ;)
Matombo has joined #ste||ar
<pree> thanks@K-ballo
hkaiser has quit [Quit: bye]
<pree> I have connected to rostam but it is very slow. Whether this is due to poor connectivity or something else?
<pree> thank you
bikineev has quit [Read error: No route to host]
bikineev has joined #ste||ar
<K-ballo> pree: looks responsive enough to me
<pree> But it is very slow to me. whether it's because of poor internet connectivity?
<K-ballo> I can only guess
<zao> Does it have mosh?
<zao> Might behave a bit better over high-latency connections with dropouts.
<pree> mosh??
<zao> Like SSH, but sets up the shell over an encrypted tunnel on top of UDP with predictive text on the client end to make it feel smoother.
<zao> Probably won't work with all the firewalling around the clusters.
<pree> No don't have mosh
Matombo has quit [Remote host closed the connection]
bikineev has quit [Remote host closed the connection]
Matombo has joined #ste||ar
Matombo has quit [Remote host closed the connection]
Matombo has joined #ste||ar
pree has quit []
hkaiser has joined #ste||ar
pree has joined #ste||ar
<pree> @zao /usr/bin/mosh: Could not connect to rostam.cct.lsu.edu: No route to host ssh_exchange_identification: Connection closed by remote host /usr/bin/mosh: Did not find remote IP address (is SSH ProxyCommand disabled?)
<pree> when using mosh it gives the above message but i can able to connect to rostam with ssh
<zao> I've never touched the LSU machines, so no idea :)
<pree> okay no probelm i will fix it if i can :)
<zao> Protip - don't upgrade cmake in the middle of a build.
<zao> It calls itself a lot :)
bikineev has joined #ste||ar
bikineev has quit [Remote host closed the connection]
bikineev has joined #ste||ar
eschnett has quit [Quit: eschnett]
bikineev has quit [Remote host closed the connection]
bikineev has joined #ste||ar
pree has quit [Ping timeout: 260 seconds]
thundergroudon has quit [Ping timeout: 246 seconds]
Matombo has quit [Remote host closed the connection]
Matombo has joined #ste||ar
<Smasher> would actually hpx::components::client<bz_server> make sense?
<Smasher> i mean...client<Foo> is something like a global shared_ptr<Foo>
<hkaiser> yes
<Smasher> so if i want to pass a reference of a server to a client, could i pass it like this? Client c(hpx::components::client<bz_server>());
Matombo has quit [Remote host closed the connection]
<hkaiser> well, a default constructed client<Foo> does not represent a valid component instance
<Smasher> yes sure
<Smasher> Client c(hpx::components::local_new<hpx::components::client<server>>(...))
<hkaiser> but you do a client<bz_server> c = new_<bz_server>(id)
<hkaiser> right
Matombo has joined #ste||ar
<Smasher> or new_
<Smasher> that type name client is somewhat misleading, dont you think?
<Smasher> i would rather describe it more general like a stub
<hkaiser> shrug, bike-shedding...
bikineev has quit [Remote host closed the connection]
<Smasher> at least i got the idea
bikineev has joined #ste||ar
aserio has quit [Quit: aserio]
taeguk has quit [Ping timeout: 260 seconds]
Matombo has quit [Remote host closed the connection]
Matombo has joined #ste||ar
* zao bravely builds win32 of examples and tests
EverYoung has joined #ste||ar
mcopik has quit [Ping timeout: 246 seconds]
EverYoun_ has quit [Ping timeout: 272 seconds]
EverYoung has quit [Remote host closed the connection]
EverYoun_ has joined #ste||ar
<zao> hkaiser: Lots of more fun stuff that's sneakily broken in 32-bit.
<zao> nqueen has duplicate definitions and specializations for things that are unsigned int and size_t.
<zao> I'll see if I can produce logs tomorrow.
<zao> Also, those $$@#@#$ should-fail tests that keep polluting a default build.
<hkaiser> zao: ok, thanks
<zao> A lot of scary warnings too about size_t way earlier in the build too.
<zao> Sadly warnings go away on rebuild, in the infinite glory of build systems.
<K-ballo> the size_t warnings have been there since the early days
<zao> This is on your fix-win32-whatnot branch, btw.
<zao> There's a lot of failed overload resolution in there.
<zao> There, sorted on Build Order
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYou__ has joined #ste||ar
denis_blank has joined #ste||ar
EverYoun_ has quit [Ping timeout: 255 seconds]
<hkaiser> zao: ok
<hkaiser> zao: what compiler is that?
<zao> 2017 x86
<hkaiser> k
<zao> Up to date with whatever MS ships.
<zao> Boost 1.64.0 prebuilt from teeks99
<hkaiser> zao: I don't see any failed overload resolution
EverYoung has quit [Ping timeout: 240 seconds]
<K-ballo> prebuilt boost, how lazy :P
<zao> K-ballo: Still have no desire to find out how the b2 people did or did not bother to support 2017.
<K-ballo> they did, eventually
<K-ballo> but I hear it takes a dev command prompt or something
<zao> Anyway, what's target #23 in my log if not some sort of overload shenanigans?
<zao> Also the weirdness in #8.
EverYou__ has quit []
<K-ballo> wow #22, invalid character
<zao> Could've sworn there were a flag to skip the should-fail tests, but must've been dreaming.
<zao> K-ballo: Heh, yeah.
EverYoung has joined #ste||ar
<zao> Is it legal to have PP directives inside a macro invocation?
<zao> I know very little of such things.
<K-ballo> no
<K-ballo> ooh
Matombo has quit [Remote host closed the connection]
<hkaiser> that was heller__
<github> [hpx] hkaiser pushed 1 new commit to master: https://git.io/v9pNB
<github> hpx/master ff63e56 Hartmut Kaiser: Fix preprocessor problem
EverYoung has quit [Remote host closed the connection]
<github> [hpx] hkaiser pushed 1 new commit to master: https://git.io/v9pNb
<github> hpx/master 2546c6b Hartmut Kaiser: Fixing test for smpd_block
<hkaiser> zao: thanks again, those things should be fixed now
<github> [hpx] hkaiser pushed 1 new commit to fixing_32bit_msvc: https://git.io/v9pAK
<github> hpx/fixing_32bit_msvc 9be832f Hartmut Kaiser: Fixing NQueens example
<zao> I'll try those when this full build completes with log.
EverYoung has joined #ste||ar
<zao> So tomorrow or something.
<hkaiser> zao: the fixes are on two branches, so you might want to wait until the fix_32bit... was merged
EverYoung has quit [Ping timeout: 272 seconds]
Matombo has joined #ste||ar
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
Matombo has quit [Remote host closed the connection]
EverYoun_ has joined #ste||ar
eschnett has joined #ste||ar
EverYoung has quit [Ping timeout: 272 seconds]
EverYoun_ has quit [Ping timeout: 260 seconds]
<zao> Meh...
EverYoung has joined #ste||ar
<zao> 469>k:\stellar\hpx\hpx\parallel\algorithms\reduce_by_key.hpp(351): warning C4244: 'argument': conversion from 'const uint64_t' to 'int', possible loss of data
<zao> VC++ is so loaded down by the build that it took a few seconds to copy a line from the output window :)
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
<zao> (and yes, that diagnostic is largely useless without context)
Matombo has joined #ste||ar
EverYoung has quit [Ping timeout: 260 seconds]
bikineev has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
<zao> All the horror.
<K-ballo> :(
<K-ballo> well at least one of them got fixed
<K-ballo> more, 3?
<K-ballo> > error C2248: 'hpx::lcos::local::spinlock::spinlock': cannot access private member declared in class 'hpx::lcos::local::spinlock'
<K-ballo> we need to "fix" that and make =deleted functions public
<zao> This build does not include hk's fixes from just now.
<zao> Anyway, waaay too late, good night.
<K-ballo> g'night
Smasher has quit [Ping timeout: 240 seconds]
<zao> Heh, just in time for http://i.imgur.com/QM6ygCG.png