hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar-group.org | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | This channel is logged: irclog.cct.lsu.edu
Yorlik_ has joined #ste||ar
Yorlik has quit [Ping timeout: 240 seconds]
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: Bye!]
yli has joined #ste||ar
yli has quit [Client Quit]
<bhumit[m]>
gonidelis: Hey, just got the feedback mail. Thank you very much for going through the application and giving such thorough feedback : ) I agree with everything you have suggested and will be making the changes by the end of this week.
<gonidelis[m]>
bhumit: awesome!
ahmed_ has quit [Quit: Connection closed for inactivity]
jbjnr[m] has joined #ste||ar
<jbjnr[m]>
Has the HPX chat/IRC migrated to another platform?
<ms[m]>
jbjnr: nope, you're in the right place
<jbjnr[m]>
do you happen to know if there's an API to do a condition variable.notify and specify move the woken task to high priority (like thread_priority::boost). I think there's one for yield, but I don't nsee one for notify ...
<ms[m]>
jbjnr: I don't think there is one, it would be a non-standard api (though that doesn't really prevent it from existing)
<jbjnr[m]>
Cn I directly set the thread priority of hpx:::this_thread just before waiting on a CV?
<jbjnr[m]>
(directly set = change)
<jbjnr[m]>
I can only see get_thread_priority and not set - and I don't want to change other state vars ...
<ms[m]>
hmm, there's `set_priority` on `thread_data`... definitely not a documented api and you shouldn't rely on it, but it may do what you want
<ms[m]>
I also see that `detail::condition_variable` has a priority parameter on `notify_one/all` but it's unused
<jbjnr[m]>
I'm just looking at that now ...
ahmed_ has joined #ste||ar
<ms[m]>
gonidelis: 1. you have to add the gpg key to your account, otherwise github will not know whose key a commit/tag was signed with (and they don't check keyservers...)
<ms[m]>
2. the tag is fine, but you have to create the release on github as well
<ms[m]>
the `hub release create ...` command is a way to programatically create the release
<ms[m]>
it's equivalent to manually saying "create a release" on github
<ms[m]>
and for `hub` you need to have a token (or username/password iirc) to be able to create the release (it has to authenticate you somehow)
<ms[m]>
and to be explicit, no creating the tag is not sufficient to create a release (you can have tags for many different purposes, many of which would not be releases)
<ms[m]>
also check `man hub` or https://hub.github.com/hub.1.html (specifically search for `GITHUB_TOKEN` or `GITHUB_USER`/`GITHUB_PASSWORD`)
<ms[m]>
ssh keys are the way to go for pushing/pulling/cloning, but that's plain git
<ms[m]>
for `hub` you need to authenticate without ssh keys
<gonidelis[m]>
<ms[m]> "gonidelis: 1. you have to add..." <- ok so let me put the stellar gpg on my github account and retry
<gonidelis[m]>
then i will recreate the tag and publish the release (didnt even announce the rc yet due to the conflicts)
<gonidelis[m]>
only thing, do i have to use hub explicitly to create the release from the tag? i understandt that you dont recommend using the github api
<gonidelis[m]>
(i guees i didn't consider RCs real releases rather than test-tags ;p)
<gonidelis[m]>
"test tags"
<gonidelis[m]>
<ms[m]> "also check `man hub` or https..." <- thanks for that
<ms[m]>
gonidelis[m]: no, you don't have to
<ms[m]>
using `hub` is effectively using the github api, wrapped into a command line tool
<ms[m]>
if you like using curl better that's fine
<gonidelis[m]>
ms: alright, added the gpg, it is unverified tho. i will ask hartmut to verify me
<gonidelis[m]>
ms[m]: ok sounds geekier, will go with that :)
<ms[m]>
do try out curl, but don't be cute with curl just for the sake of "geekier"
<ms[m]>
`hub release create` is pretty obvious
<ms[m]>
gonidelis[m]: I don't think hartmut verifies you
<ms[m]>
I've marked my account as requiring signed commits, and if they're not signed it shows up as unverified, which is what I think you're seeing?
<gonidelis[m]>
"signing commits authored by this email address (contact@stellar-group.org) will be unverified until the email address is verified"
<ms[m]>
hmm, ok, yes he may have to verify that :P
<ms[m]>
sorry
<gonidelis[m]>
cool
<gonidelis[m]>
ms[m]: should i embed it on the roll_release script tho?
<gonidelis[m]>
hkaiser: no, but if you see my discussion with mikael earlier it might not be that big of an issue
<hkaiser>
ok
<hkaiser>
have you uploaded the gpg key to your account?
<gonidelis[m]>
if it works.... 😅
<ms[m]>
gonidelis: nice!
<gonidelis[m]>
hkaiser: yes
<ms[m]>
but the tag and date are still wrong ;) just fyi to remember for the next release candidate (or if you're quick noone will notice for this one)
<hkaiser>
jbjnr[m]: might not be a more pervasive change to make this work - give me some time, pls
<hkaiser>
might *be* a more pervasive change
<jbjnr[m]>
thanks. I'm happy to poke around with the code, but before I spend time on it, I wondered if we had already done this somewhere. The yield has a thread boost if I recall correctly ... Easiest thing for me would be to just boot the priority BEFORE I wait on the CV, then when it is notified, all is well.
<jbjnr[m]>
^boost
<hkaiser>
jbjnr[m]: yah, that might work - but having the parameter activated again (not sure why it was removed) would be better
<hkaiser>
jbjnr[m]: otoh, it might be even viable to always boost the priority of threads that come out of a CV
<jbjnr[m]>
indeed.
<jbjnr[m]>
I didn't actually follow the wake up code beyond the CV notify call, so it is possible it already does that and I didn't check
<jbjnr[m]>
got pulled into a meeting all afternoon
<ms[m]>
"version tag" not "git tag" to be entirely clear
<ms[m]>
the tag is at least mentioned in the release procedure, not sure about the date
<gonidelis[m]>
oh!
<gonidelis[m]>
well the tag is correct in my local machine I just didn't include it on the pr :/
<gonidelis[m]>
the date is not though, and thanks for that :)
<gonidelis[m]>
i mean, you can checkout on the 1.8.0-rc1 tag, cannot u?
<gonidelis[m]>
ms[m]: ohhhhhh....
<gonidelis[m]>
ms: ok fixed locally. now redoing the release will overwrite the existing one?
<hkaiser>
gonidelis[m]: I'd leave it to the next rc
<hkaiser>
let's not mess with releases
<gonidelis[m]>
hkaiser: ok sorry for that
<hkaiser>
no worries
<ms[m]>
gonidelis: it's not a big deal, as I said earlier better do it now that for the final release ;)
<hkaiser>
it's a release _candidate_, so no harm done
<gonidelis[m]>
cool
<gnikunj[m]>
hkaiser: srinivasyadav227: I won’t be able to join the meeting today. Pls continue without me.
<hkaiser>
gnikunj[m]: we cancelled it for today
<dkaratza[m]>
for the contributors in the docs the emails are images. can somebody provide details about that (font, font size etc.) so that everything is uniform?
<hkaiser>
dkaratza[m]: uhh
<hkaiser>
no idea :/
<gnikunj[m]>
Yeah my bad. Just saw the cancelled notification.
<hkaiser>
it's most likely a run-of-the-mill font, nothing fancy
<hkaiser>
rori[m]: we cancelled the meeting today
<dkaratza[m]>
hkaiser: ook i will try to make it similar
<diehlpk_work>
New Octo-Tiger release with HIPS support
<hkaiser>
yay!
<hkaiser>
diehlpk_work: not sure if you have seen this, but gonidelis[m] has created the first RC for HPX V1.8 - would you be able to do your fedora magic?
<diehlpk_work>
hkaiser, Sure, I will do it this evening
<diehlpk_work>
We need to fix things
<diehlpk_work>
HPX 1.7.1 stopped compiling on the future fedora release
<diehlpk_work>
Fedora 36 will be published April 26, 2022
<diehlpk_work>
This hill still have 1.7.1
<diehlpk_work>
Fedora 37 will have hpx 1.8.0
<diehlpk_work>
But HPX 1.7.1 stopped compiling there
<diehlpk_work>
So we need to fix things, but I wanted to wait for hpx 1.8.0 to do the fixes there, since 1.7.1 will not be shipped there
<hkaiser>
diehlpk_work: ok
<hkaiser>
do you have a link to the compilation problems?
<diehlpk_work>
hkaiser, In the latest version, it is a cmake issue with cmake 3.23
<diehlpk_work>
I need to fix that and we will have the compilation error again
<diehlpk_work>
hkaiser, gcc 11
<diehlpk_work>
I think we might not tested HPX on gcc 12
<diehlpk_work>
I think we only had gcc 11 so far
<diehlpk_work>
That is the cmake error with cmake 3.23
<hkaiser>
diehlpk_work: where does the /builddir/build/BUILD/hpx-1.7.1/serial directory name come from?
<diehlpk_work>
I need to check that
<dkaratza[m]>
which do you think is the best way to collect some info about the most common issues that are faced when using/building hpx? i'm trying to enrich the troubleshooting page
<dkaratza[m]>
i thought sharing a doc but I doubt that one would take the time to open it and drop some ideas there
<diehlpk_work>
hkaiser, since Fedora 36 build is fine, I assume that sth changed in the fedora build script
<diehlpk_work>
I need to read the changelog and see what changed
<diehlpk_work>
I had that before
<diehlpk_work>
They renamed come internal envs
<gonidelis[m]>
<K-ballo> "hpx's age is starting to show..." <- lol!
<satacker[m]>
How do I expect a static assert to fail in HPX unit tests?
<gonidelis[m]>
satacker: if the condition is not true it pops the corresponding message ?
<gonidelis[m]>
dkaratza: an extreme and not explicit at all idea would be to ask for feedback at the end of the build instructions page with some form or sth
<K-ballo>
a failed static assert is a compilation error, doesn't make sense for a unit test
<gonidelis[m]>
Otherwise u could just browse on past issues that are related to building hpx and kinda sum up them to a concrete trohbleshooting document
<gonidelis[m]>
Cause if u wanna sample in a given point in time u will just get answers from the guys and gals that currently trying to build it
<dkaratza[m]>
gonidelis[m]: i dont want to add that at the docs...i want you people who use hpx to tell me what are the most common issues that you or new people face
<gonidelis[m]>
Ah I thought u were asking for ways to take answers, not for answers in the first place
<K-ballo>
satacker[m]: is sender.hpp your code? looks wrong
<satacker[m]>
K-ballo: Yes. It's the opposite of SFINAE right?
<K-ballo>
not sure what you mean
<gonidelis[m]>
So rn it’s a very good period to collect these data given that we have many new GSoC students that face firstcommers’ failures. Then u address to us (auriane, hartmut, Nikunj etc) who have been using hpx in a while and u get more advanced kind of failures
<satacker[m]>
K-ballo: Could you look at the pull request please?
<gonidelis[m]>
With either a form or a doc that is
<gonidelis[m]>
Form is easier and quicker
<dkaratza[m]>
gonidelis[m]: ok so i should talk individually with each one of u
<gonidelis[m]>
Yes. That would be the most explicit way
<K-ballo>
satacker[m]: what are you trying to achieve?
<gonidelis[m]>
The previous docs guy tried publishing a questionnaire but didn’t quite work
<gonidelis[m]>
He had zero responses
<satacker[m]>
K-ballo: I wanted to pass non_scheduler and expect an error
<dkaratza[m]>
gonidelis[m]: yah yeah i remember you told me
<K-ballo>
note you are computing out the invocation result (or attempting to) regardless of whether or not the type is a scheduler
<satacker[m]>
satacker[m]: As I understand that because enable_if does not pass the condition it does not have a typedef type member which turns this into an error
<satacker[m]>
K-ballo: Okay, so I should not do enable_if ?
<K-ballo>
as for the static_asserts, looks like they ought to be just regular old test checks
<satacker[m]>
K-ballo: Thanks, my initial concern was right this one whether to verify the concept schedule_t or to directly get the type of result of invocation
<K-ballo>
except for the last one, which will be a compile time error
<K-ballo>
you are "computing" both `is_scheduler_v<S>` and `hpx::util::invoke_result_t<schedule_t, S>` at the same time
<gonidelis[m]>
We have HPX_TEST too satacker
<K-ballo>
you can't "call" `enable_if_t` without figuring out the arguments
<satacker[m]>
K-ballo: Which is why I called is_scheduler_v , based on the value it'll enable and return the result type of invocation.
<satacker[m]>
Should I simply get the result type of invocation?
<satacker[m]>
> <@K-ballo:libera.chat> you can't "call" `enable_if_t` without figuring out the arguments
<satacker[m]>
* Which is why I called is\_scheduler\_v , based on the value it'll enable and return the result type of invocation.
<satacker[m]>
Should I simply get the result type of invocation without checking if it is a schedule_t or not?
<K-ballo>
enable_if<C, foo_t<X>> first computes C, then foo_t<X>, then instantiates enable_if with the result of those computations
<K-ballo>
by the time enable_if enters the picture, `invoke_result_t<...>` doesn't exist anymore, it's been "evaluated" already
<K-ballo>
whether or not you should guard on is_scheduler depends on how you will be using this and what you are trying to accomplish
<K-ballo>
if you are in a context that already expects schedulers you'll have some requires, enable_if, or static_assert for is_scheduler already
<satacker[m]>
Thanks for the detailed explanation of enable_if
<satacker[m]>
Lastly what would be more generic to have some requires or not?
<K-ballo>
it isn't related to generality, it depends on context and usage