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
anushi has quit [Remote host closed the connection]
parsa has quit [Quit: Zzzzzzzzzzzz]
hkaiser has quit [Quit: bye]
nanashi55 has quit [Ping timeout: 240 seconds]
nanashi55 has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
parsa has joined #ste||ar
jaafar has quit [Ping timeout: 264 seconds]
parsa has quit [Quit: Zzzzzzzzzzzz]
nikunj has joined #ste||ar
jgolinowski has joined #ste||ar
jgolinowski has quit [Quit: Leaving]
jgolinowski has joined #ste||ar
<heller> jbjnr: what's wrong with pyicle nowadays, I see a lot of pending statuses
hkaiser has joined #ste||ar
<ms[m]1> heller: I've most likely messed up the github status submission on my instance
<heller> oh ok
<heller> it's a bit annoying ;)#
K-ballo has joined #ste||ar
<nikunj> diehlpk_work, yt?
jaafar has joined #ste||ar
<ms[m]1> I know... I'll fix it soon
parsa has joined #ste||ar
AnujSharma has joined #ste||ar
AnSh has joined #ste||ar
AnujSharma has quit [Remote host closed the connection]
AnSh has quit [Remote host closed the connection]
AnujSharma has joined #ste||ar
<hkaiser> heller: are you ok with merging #3398?
<heller> hkaiser: I'm a little hesitant since the status reporting isn't working reliably and we miss some failures caused by it
<hkaiser> heller: ok, fair enough
<hkaiser> this is a risky change
<heller> Yeah
<heller> My arm machines are down... I'd like to test it there as well
<heller> Can do it tomorrow
<K-ballo> hkaiser: I'm thinking setting the state to ready under the lock might be a good thing
dmarce1 has quit [Quit: Page closed]
<K-ballo> yep
<K-ballo> we are about to grab the lock anyways
<K-ballo> and if someone grabs the lock then checks then forcing them to wait a tinsy bit until we set the state to ready wouldn't be a bad thing since the value is already there
<hkaiser> k
<hkaiser> let me change that
<hkaiser> done
<hkaiser> github can't post here anymore now either :/
<K-ballo> it's set to message without join
<K-ballo> now it should be able, with some annoying extra join/leave activity
<hkaiser> did you change the settings on github?
<K-ballo> yep
<K-ballo> mmh nope
<K-ballo> I failed apparently
<K-ballo> oh but it won't be able to join the channel anyways since the nick is not registered
parsa has quit [Quit: Zzzzzzzzzzzz]
<hkaiser> K-ballo: we can ask github to use a specific nick for posting
<K-ballo> we should be able to set an exception for a specific nick, I'm checking the modes
<K-ballo> maybe not.. could we have a registered nickname just for github to use for us?
AnSh has joined #ste||ar
AnujSharma has quit [Ping timeout: 256 seconds]
AnSh has quit [Ping timeout: 244 seconds]
<hkaiser> K-ballo: sure
<hkaiser> use stellar-github or something
AnSh has joined #ste||ar
parsa has joined #ste||ar
<ms[m]1> jgolinowski: in case my pm doesn't arrive, yes, I'll be there
parsa has quit [Quit: Zzzzzzzzzzzz]
AnSh has quit [Ping timeout: 256 seconds]
jgolinowski has quit [Quit: Leaving]
<jbjnr> heller: pycicle is useless anyway because we still get random fails on every PR that make it meaningless since nothing ever passes consistnetly.
<hkaiser> jbjnr: that has nothing to do with pycicle
K-ballo is now known as ste||ar-github
<ste||ar-github> hkaiser: this nick is now tied to hpx-devel@stellar.cct.lsu.edu, there should be an activation email on the way
<hkaiser> k
<hkaiser> don't see it yet
<hkaiser> also, not sure how I could confirm it
<hkaiser> hpx-devel is a ML
<ste||ar-github> don't you get an admin interface?
<hkaiser> I do
ste||ar-github has quit [Quit: ste||ar-github]
K-ballo has joined #ste||ar
<K-ballo> oh, is the confirmation via reply rather than via link?
<hkaiser> K-ballo: no idea, I have not seen that email yet
<nikunj> K-ballo, hkaiser: the email sent to you comes with a random generated password with which you need to verify that you wish to register
<K-ballo> ah, perfect
<nikunj> something similar to: /msg NickServ VERIFY REGISTER nikunj ourpasswordhere
<nikunj> once you are registered, you can then identify yourself using: /msg NickServ identify <password>
<nikunj> note that password with identify is the password you set while registering and the above query contains the randomly generated password sent by freenode server
parsa has joined #ste||ar
<nikunj> just to make sure I'm understanding things right, We can code till 14th of August (and provide with final links) and Google will accept it right?
parsa has quit [Quit: Zzzzzzzzzzzz]
jbjnr has quit [Remote host closed the connection]
<hkaiser> nikunj: you don't have to stop coding on Aug 14th ;-)
<nikunj> hkaiser, I don't intend to :)
<nikunj> I'm still researching on ways to integrate the HPX runtime completely with C++ such that the user does not need to worry about hpx::init or hpx::finalize ever again
<nikunj> and everything works out of the box
<hkaiser> nikunj: nice!
<hkaiser> we have another idea that might help with that
<nikunj> hkaiser, oh sounds intriguing. What is it?
<hkaiser> hpx threads are identified by having a thread local variable pointing to a thread_self object
<hkaiser> if we create a thread_self for pthreads that emulates the behavior expected we could simply add such a thread local to main and call it a day
<hkaiser> not sure if that's possible and if yes, how much effort that would be
<nikunj> so you want to add an abstraction to the pthreads model to include the thread_self as well?
<hkaiser> yes
<hkaiser> that should make a non-hpx thread look like one
<nikunj> sounds interesting! but I'm not sure if it can be made possible. I'll look into it
<hkaiser> the main distinguishing feature of a hpx thread is its suspension behavior which is invoked through the thread_self object
<nikunj> I'm sorry, I didn't get what you meant by "suspension behavior"
<hkaiser> if a pthread is suspended it goes to sleep in the kernel
<hkaiser> if an hpx thread is suspended it gives back control to the hpx scheduler
<hkaiser> that is their main distinguishing characteristic
<nikunj> ok
<nikunj> I think it makes sense to give back control to keep it lightweight
<hkaiser> and that's the reason why a lot of hpx functionality is not available to pthreads
<hkaiser> but suspension of an hpx thread is done by calling a member of the thread_self object associated with it
<hkaiser> so if we added a thread_self specific to pthreads all should be fine
<nikunj> yes, that makes things clearer
<nikunj> can you please point me to the code so that I can get how it's all implemented?
<hkaiser> get_self pulls the pointer out of a thread local variable
<nikunj> thanks! I will take an in depth look into it. I will let you know of my findings
<nikunj> I'm not sure if it's implementable. I think if we could do something before main (similar to what I've implemented) we might just be able to get away with it
<nikunj> And since we will only need to add to the thread_self object, things should run well on Windows as well
<nikunj> This implementation sounds promising (if possible). I will surely research on it
<nikunj> This implementation will also get us rid of thinking about global objects not running on HPX threads
nikunj has quit [Quit: goodnight]
jbjnr has joined #ste||ar
<jbjnr> heller: the point I wanted to make is merely that pycicle isn't any help at the moment because I dare not merge anything due to random fails on every PR (or most of them it seems)