01:34 <rainmaker6[m]> Please someone approve the workflows on https://github.com/STEllAR-GROUP/hpx/pull/5278

03:10 <rainmaker6[m]> * Please approve the workflows on https://github.com/STEllAR-GROUP/hpx/pull/5278

03:11 <rainmaker6[m]> * Please enable/approve ci testing on https://github.com/STEllAR-GROUP/hpx/pull/5278

07:59 <gonidelis[m]> ms[m]: yt?

12:24 <ms[m]> gonidelis[m]: sorry, here now

14:50 <ms[m]> diehlpk_work: did we already have a (n internal) gsod mailing list? I wanted to share the applications before the meeting tomorrow

14:52 <gonidelis[m]> ms[m]: about those includes

14:52 <gonidelis[m]> `#include <hpx/hpx_main.hpp>`

14:53 <gonidelis[m]> if I don't have them I get an `hpx namespace not found` error

14:53 <gonidelis[m]> i first tried including the `hpx/iterator_support/iterator_traits` header

14:53 <gonidelis[m]> but that didn't solve the issue

15:02 <srinivasyadav227> hkaiser: now i am a bit confused to what acutally do https://github.com/STEllAR-GROUP/hpx/pull/5319#discussion_r631079476 here, :), can you please tell what changes do i need make..?

15:03 <ms[m]> gonidelis[m]: you'll need to give me a bit more, what exactly triggers "hpx namespace not found" and why is hpx/hpx_main.hpp the right header to include for that? you're aware of what hpx_main.hpp does, right?

15:03 <ms[m]> srinivasyadav227: sorry for the noise there :P I just commented saying we can leave it as it is

15:04 <ms[m]> unless hkaiser changed his mind on that

15:04 <srinivasyadav227> ms: ok thanks :)

15:05 <hkaiser> ms[m]: on what should I have changed my mind? ;-)

15:06 <ms[m]> on that macro definition :P at least I understood your comment as saying you think the version with the identity is the better option

15:06 <ms[m]> both have weird corner cases, so I don't really mind which one we have

15:07 <ms[m]> hkaiser: question also for you: did we have an internal gsod mailing list where I could share the applications? I put the form on the contact@stellar-group.org google account, but I don't remember if anyone else has the password for it

15:08 <hkaiser> nod, let's go with the version that uses identify

15:09 <srinivasyadav227> ok, then changing the name of macro from HPX_HAVE_CXX20_STD_LAMBDA_CAPTURE to HPX_HAVE_CXX20_LAMBDA_CAPTURE would be sufficient right?

15:12 <hkaiser> ms[m]: we can create a mailing list, if you want - alternatively we could use the gsoc-mentors list

15:13 <ms[m]> hkaiser: ah, yeah, gsoc-mentors will do, thanks!

15:13 <ms[m]> if there's too much noise we can still create a gsod-mentors one later

15:26 <K-ballo> srinivasyadav227: did you find a way to make the feature test actually fail?

15:27 <srinivasyadav227> no

15:30 <K-ballo> a feature test case that always passes isn't really useful

15:57 <srinivasyadav227> yea, true :), but that feature test is throwing a warning when manually compiled with `g++ -std=c++14/17` but i am not clear how that can be turned into an error, after reading this (https://github.com/STEllAR-GROUP/hpx/pull/5319#discussion_r630197167) comment many times from yesterday, today i understood and so i tried this(https://godbolt.org/z/vqdexxsqK) but it did not work out, so i am still trying to figure

15:57 <srinivasyadav227> this out. ;-)

16:04 <ms[m]> srinivasyadav227: I had a quick try and it seems like that warning is not controlled by any -W flag (at least for GCC, clang has one c++20 related flag that might do the trick)

16:05 <ms[m]> if you can find a way to just generally set -Werror for the feature test that might work (I don't remember if we have a way to set compiler flags on the compile tests though)

16:06 <srinivasyadav227> okay i will try that

16:15 <srinivasyadav227> with clang its `-Wc++20-extensions` here https://godbolt.org/z/e1qWasaPf

16:23 <srinivasyadav227> gcc seems to have no other way than passing `-Wall` to compiler ;-( , i could find any info about lamda capture (this) warning here https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

17:27 <K-ballo> the warning itself includes the corresponding flag, when one exists

17:37 <ms[m]> K-ballo: right, that's the problem, "when one exists"

17:38 <ms[m]> in this case there is no corresponding flag

17:38 <K-ballo> there's an argument to be made that feature tests should all compile with warnings as errors anyhow

17:38 <ms[m]> yep, that's a fair point

17:39 <K-ballo> I remember fixing some warnings ages ago, but not all, something got in the way of setting warnings as errors

17:40 <K-ballo> also curious that -Werror=aligned-new doesn't work, sounds like a plain bug