hkaiser 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/ | GSoC2018: https://wp.me/p4pxJf-k1
parsa has joined #ste||ar
parsa has quit [Client Quit]
anushi has joined #ste||ar
parsa has joined #ste||ar
parsa has quit [Client Quit]
anushi has quit [Ping timeout: 260 seconds]
eschnett has joined #ste||ar
anushi has joined #ste||ar
anushi has quit [Ping timeout: 260 seconds]
anushi has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: bye]
anushi has quit [Ping timeout: 260 seconds]
parsa has joined #ste||ar
parsa has quit [Client Quit]
galabc has joined #ste||ar
<galabc>
Hi I am having trouble building a simple code with cmake
<galabc>
I want to use the program_options from the boost library
parsa has joined #ste||ar
<galabc>
Im simply trying to compile the first.cpp file located at BOOST_ROOT/libs/program_options/example on the rostam clusters
<ms[m]1>
jakub_golinowski: yeah, that works, but I meant getting the current executor/pool (`hpx::this_thread::get_executor` or something like that)
<jakub_golinowski>
ms[m]1, so I will for now just refrain from doing that
<jakub_golinowski>
also I have just commited a working version to github
<jakub_golinowski>
Windows open and the processing happens as expected. Nevertheless some options from the Settings menu does not work as expected -> which is probably due to deleted signals I will look into that now
<jakub_golinowski>
ms[m]1, How should I interpret such an error? {what}: data has already been set for this future: HPX(promise_already_satisfied)
<ms[m]1>
jakub_golinowski: hmm, a future has a counterpart called a promise, the promise is where you set a value and the future is where you get a value
<jakub_golinowski>
ms[m]1, but I did not use any promise
<ms[m]1>
in what context does this happen? are you using something other than just plain async and futures?
<jakub_golinowski>
ms[m]1, to give more context this error occurs when i press the X on the GUI. So I guess the exit sequence is not correct and nasty stuff is happening
<ms[m]1>
mmh, hard to say anything without code
<ms[m]1>
do you get a line number/stack trace/something?
<jakub_golinowski>
ms[m]1, so the error is not deterministic I get different things -> I am now tracking what exactly happens after the X button is pressed
<jakub_golinowski>
ms[m]1, I remember that future is usable only once, yes?
<ms[m]1>
jakub_golinowski: it's move only and I think you can only call get once
<jakub_golinowski>
ms[m]1, because my thaughts went into the direction that having a future as a member field may not be a good idea
<jakub_golinowski>
won't pointer be better -> such that I can delete the future and create next?
<ms[m]1>
it could be, depends maybe on where you create a new one, you can always just assign a new one
<ms[m]1>
but I'll have a look at the code a bit closer now
<jakub_golinowski>
ms[m]1, or when I use the "=" operator on the class member variable of type future assigning a newly created future then old one is deleted automatically and I have a brand new future?
<ms[m]1>
yes
nikunj has joined #ste||ar
<ms[m]1>
jakub_golinowski, is this about for example hpx::future<void> captureThreadFinished?
mcopik has quit [Ping timeout: 260 seconds]
<jakub_golinowski>
ms[m]1, yes - this is it
<ms[m]1>
ok
<nikunj>
hkaiser, did you get time to look into my pr?
_bibek_ has joined #ste||ar
bibek has quit [Ping timeout: 265 seconds]
_bibek_ is now known as bibek
hkaiser has quit [Quit: bye]
parsa[w] has quit [Read error: Connection reset by peer]
parsa[w] has joined #ste||ar
<jakub_golinowski>
ms[m]1, I am working on changing the resolution so far. I undertook the approach in which I want to restart the capture task each time resolution is changed because otherwise I was getting resource busy errors
<jakub_golinowski>
However when I set the flag and wait for the future to end and then reschedule the future I get the following error
<jakub_golinowski>
What is interesting I do not get this error when I do a step-by-step debug
<jakub_golinowski>
it seems like some kind of race condition
nikunj has quit [Quit: Leaving]
<jakub_golinowski>
ms[m]1, the solution seems to be using hpx::apply -> which further proves that main thread pool requires a special treatment
<ms[m]1>
jakub_golinowski: hmm, do you call wait on the main thread?
<diehlpk_work>
Your current usage represents 683% of your STEllAR-GROUP Linux plan's limit. Please upgrade in order to ensure no disruption in building.
<diehlpk_work>
Has someone seen this warning too?
<zao>
Circle?
<diehlpk_work>
Yes
<K-ballo>
683% wow
<zao>
Imagine if we had a test suite that didn't take ages to run. And a codebase that didn't take ages to build :D
<K-ballo>
you may say I'm a dreamer...
<K-ballo>
I failed horribly at getting build times under control
<diehlpk_work>
At least I updated HPXCL to curcle-ci 2.0