<K-ballo>
"sentinel_for<S, I> && ..." that means refinement
<hkaiser>
jbjnr: did the scheduler benchmarks run this time?
<jbjnr>
yes, they look ok. Sorry forgot to post an update
<gonidelis[m]>
K-ballo: but we use it to find out whether we could jump from the iterator to the sentinel in constant time... right?
<K-ballo>
not... really
<K-ballo>
sized sentinel can tell you how far you are from it
<gonidelis[m]>
ok same thing
<K-ballo>
not really
<K-ballo>
it's possible you can tell how far you are from the sentinel, but not jump there in constant time
<gonidelis[m]>
K-ballo: yeah you are right
<gonidelis[m]>
so where do we used sized_sentinel_for ? I can't recall
<K-ballo>
we? as in hpx? no idea
<hkaiser>
jbjnr: thanks
<gonidelis[m]>
yeah eyah
<hkaiser>
gonidelis[m]: in distance()
<gonidelis[m]>
duh.... it was just in front of me.
weilewei has joined #ste||ar
<hkaiser>
rori, ms[m]: thanks for the release candidate! Good job!
<gonidelis[m]>
hkaiser: you have an email ;)
jbjnr_ has joined #ste||ar
jbjnr has quit [Read error: Connection reset by peer]
<ms[m]>
thank you rori for all the work on the release!
<rori>
you're welcome :)
akheir has joined #ste||ar
<gonidelis[m]>
rori: bravo!
kale[m] has quit [Ping timeout: 244 seconds]
<hkaiser>
gonidelis[m]: very nice writeup, thanks
<gonidelis[m]>
thank you very very much for your help
<gonidelis[m]>
Do you think that Google may reject it as informal maybe?
<hkaiser>
nah
<hkaiser>
use it as your report
<gonidelis[m]>
hkaiser: great. Thanks a lot! As I already told you... I would love it if someone who wanted to start working with us could understand the process of what to study and how ot prepare from a studen't prespective
bita_ has joined #ste||ar
<hkaiser>
gonidelis[m]: when is the evaluation deadline?
<gonidelis[m]>
monday
<gonidelis[m]>
hkaiser: august 31
jbjnr__ has joined #ste||ar
jbjnr_ has quit [Read error: Connection reset by peer]
<hkaiser_>
weilewei: this atomic is a global one, i.e. it will be initialized before HPX is initialized, so you will always get the default value, as your settings have not been handled yet
<hkaiser_>
also, why is it an atomic?
<hkaiser_>
do you anticipate this value changing concurrently?
<weilewei>
Oh, I see, no, it is not necessary an atomic value.
<weilewei>
Let me change it later hkaiser_
<diehlpk_work>
ms[m], The JOSS paper got accepted
<diehlpk_work>
We need some release of HPX to attach. Should we use HPX 1.5.0 or do a new release HPX 1.4.1-joss for the paper?
<diehlpk_work>
We have to upload the release to Zenodo and the author list there has to match the JOSS paper.
<diehlpk_work>
Let me know what you would prefer?
<diehlpk_work>
1) Have the 1.4.1-joss release and modify the Zenodo list there
<diehlpk_work>
2) Have 1.5.0 and have two Zenodo releases
<hkaiser_>
diehlpk_work: let's wait for V1.5
<hkaiser_>
why 2 zenodo releases?
<hkaiser_>
there is only one zenodo doi that automatically refers to the latest release
<diehlpk_work>
hkaiser_, The HPX 1.5.0 Zenodo release will have all authors contributing to HPX 1.5.0
<diehlpk_work>
However, we need for the JOSS paper the same authors as on the JOSS paper
<diehlpk_work>
So, we need two releases
<diehlpk_work>
or not releases, better two Zenodo DOIs
<diehlpk_work>
So it might would better do do the HPX 1.4.1-joss release with a Zenodo DOI matching the JOSS paper
<ms[m]>
diehlpk_work: that seems strange... do we then have to make a x-joss release for every new release? or is the joss paper forever going to refer to 1.4.1-joss (or 1.5.0 if we wait for that?)
weilewei has quit [Remote host closed the connection]
<diehlpk_work>
hkaiser_, we only need one release and the JOSS paper points to this release since the reviwers reviewed this version of HPX
<ms[m]>
and is there going to be a chicken and egg problem with having the joss paper citation in the docs? or do we already have a doi for it now that it's accepted?
<hkaiser_>
diehlpk_work: sure, let the paper refer to V1.5, it will be released next week or so
<hkaiser_>
we can wait with the paper until its out
<hkaiser_>
(if needed)
<hkaiser_>
we should also merge the paper into the release
<diehlpk_work>
ms[m], We need a release and Zenodo DOI to get the paper published
<hkaiser_>
the zenodo doi will be generated automatically once we release it
<diehlpk_work>
hkaiser_, Yes, and we can not use this Zendo doi
<hkaiser_>
I think we should refer to the generic zenodo doi instead
<hkaiser_>
yah, it's a circular dependency
<hkaiser_>
we could merge the paper after the release, that would allow us to have it refer to the zeonodo doi generated by the release
<diehlpk_work>
hkaiser_, we can not use the automaticaly generated Zendo DOI
<hkaiser_>
why not?
<diehlpk_work>
this will have any commiter to the gitgub repo
<diehlpk_work>
which does not match the JOSS authors
<hkaiser_>
ok, so what?
<diehlpk_work>
The Zenodo DOI *have to match* the authors on the JOSS paper
<hkaiser_>
all authors are listed by zenodo
<hkaiser_>
no idea how this can be done
<diehlpk_work>
Yes, but not all are on the JOSS paper
<hkaiser_>
correct
<diehlpk_work>
I need to use the tar ball of the HPX 1.5.0 release and do a manually zendo release
<diehlpk_work>
And add the authors by hand
<diehlpk_work>
So we would have two Zendo DOIs for HPX 1.5.0
<hkaiser_>
uhh
<hkaiser_>
well, whatever
<diehlpk_work>
HPX 1.5.0 and HOX 1.5.0-joss or whatever
<hkaiser_>
ok
<diehlpk_work>
Ok, let us use HPX 1.5.0 and I will generate the package
weilewei has joined #ste||ar
<hkaiser_>
yah, Dan said, the title of the zenodo release should match the paper title
<diehlpk_work>
Yes, another point
<hkaiser_>
diehlpk_work: alternatively we could use figshare for the archived version, that would avoid the zenodo mess
<diehlpk_work>
hkaiser_, Sounds good
<weilewei>
hkaiser_ I removed the atomic but still kept the static for that variable, and it is still unchanged after I pass different runtime value
<hkaiser_>
weilewei: sure it stays unchanged
<hkaiser_>
why should change now?
<weilewei>
I thought we can pass different runtime value, and update the max_concurrent_attach_thread_hazard_pointer_
<hkaiser_>
sure you can
<hkaiser_>
the problem is that you initialize the global value directly, which happens before HPX is initialized
<hkaiser_>
so you can't ask HPX for the value as it has not even processed the command linen at that point
<weilewei>
oh I see, so I should not make the variable global
<hkaiser_>
you can make it global if you want (which I don't like, btw), you need to initialize it later, however, for instance whenever the first libcds operation is invoked
<hkaiser_>
you might not need a variable in the first place
<hkaiser_>
just call get_config_value() whenever you need the number of threads
<weilewei>
I see... let me try it
nanmiao11 has quit [Remote host closed the connection]
<hkaiser_>
weilewei: difficult to tell from just looking at the code
<hkaiser_>
when is that called? is HPX up and running at that point already?
<weilewei>
Yes, it is called when HPX is up
kale[m] has quit [Ping timeout: 258 seconds]
kale[m] has joined #ste||ar
<hkaiser_>
weilewei: then I don't know, how do you set the value?
<weilewei>
hkaiser_ I think I found the issue, I accidentally exported HPX_NUM_CONCURRENT_HAZARD_POINTER_THREADS=10 a very small number, and the executable picks it up; Now I export it to a large value 100
<weilewei>
now it works, and I can update the value as well. also I missed -- before --hpx:ini=hpx.cds.num_concurrent_hazard_pointer_threads=256 so it does not recognize the value
<hkaiser_>
ok
weilewei has quit [Remote host closed the connection]
weilewei has joined #ste||ar
jaafar has joined #ste||ar
diehlpk_work has quit [Remote host closed the connection]
diehlpk_work has joined #ste||ar
nanmiao11 has joined #ste||ar
jaafar has quit [Ping timeout: 260 seconds]
nanmiao11 has quit [Remote host closed the connection]
nanmiao11 has joined #ste||ar
jbjnr__ has quit [Ping timeout: 272 seconds]
bita_ has quit [Ping timeout: 260 seconds]
jaafar has joined #ste||ar
jaafar has quit [Ping timeout: 264 seconds]
weilewei has quit [Remote host closed the connection]