nikunj has quit [Remote host closed the connection]
nikunj has joined #ste||ar
bita_ has quit [Read error: Connection reset by peer]
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 260 seconds]
K-ballo1 is now known as K-ballo
nikunj has quit [Ping timeout: 260 seconds]
nikunj has joined #ste||ar
<ms[m]>
piz daint is down for maintenance which is why there are no pycicle builds currently, for anyone wondering...
<tarzeau>
ms[m]: is there an rss feed for such maintenances?
<ms[m]>
tarzeau: not as far as I know... you probably get emails if you have an account, right? you could open a ticket, they might just add something like that but I think it would be quite low priority
gonidelis has joined #ste||ar
mcopik has joined #ste||ar
mcopik has quit [Client Quit]
gonidelis has quit [Remote host closed the connection]
gonidelis has joined #ste||ar
hkaiser has joined #ste||ar
hkaiser has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
<gonidelis>
I have just started making changes to source (algorithms). What is the standard way of running/testing (with the existing tests) the changes without having to recompile the whole library?
<rori>
Assuming you already compiled the library, running `make -j` will just recompile the modified parts of your source code
<rori>
To compile the tests you can just compile the one related to your module with `make -j tests.unit.modules.algorithms tests.regression.modules.algorithms`
<rori>
To run them `ctest -R tests.*modules.algorithms --output-on-failure`
<rori>
the `output-on-failure` will detail the error whereas without it is just specifying that it has failed
<rori>
ones*
<gonidelis>
If I make changes to a certain module, just compiling the test won't do the work, right?
<rori>
yes it will
<gonidelis>
0.0
<rori>
cause the test is depending on the main hpx target I believe
<rori>
but not 100% sure
<rori>
cmake magic
<gonidelis>
oh! ok... I 'll try it. So `make -j4` may not be necessary then... (?)
<gonidelis>
Another question is... do I have to work with clang as I write the code or is it just trivial to go along the formatting policies for such small changes?
<gonidelis>
hkaiser thank you... I ll give it a look
<hkaiser>
gdaiss[m]: you mean clang-format?
<gonidelis>
yes
<hkaiser>
gonidelis: ^^
<hkaiser>
you can do that at any time
<hkaiser>
there are ways to do that directly in the editor
<hkaiser>
all editors have ways to integrate clang-format nowadays
weilewei has quit [Remote host closed the connection]
<zao>
Some have it on hotkey, some have it on save, some in a menu item.
<gonidelis>
oh ok... so it's not something HPX specific. I reckon it is sth like, I embed clang-format on my sublime editor and it just warns me every time a bad syntax occurs
<zao>
clang-format reshapes source code to conform to the code style without changing behaviour.
<zao>
It doesn't do any compilation/completion or warning/error extraction.
jaafar has quit [Ping timeout: 240 seconds]
<zao>
The only relation to "clang" the compiler is that it's built with the same codebase for parsing your code.
<gonidelis>
ok I will install it immediately... zao Yeah, makes sense.
<zao>
We use it to ensure that code looks equally bad for everyone viewing it, and if you enforce formatting before committing, it ensures that this quality level is kept.
<gonidelis>
oh and one more question. How often do you guys recompile hpx? Is it sth like, everytime a merge occurs and you notice it, you just run a `make -j`? Or do you just run `make -j` like once a week just to be safe? (more kind of personal newbie question) ;D ;D
<zao>
A common workflow is to work in a feature branch, which keeps you isolated from things that people break/fix upstream.
<zao>
You can occasionally merge/rebase in master into it to ensure that you're reasonably up to date so that the PR to master becomes easier to merge.
<zao>
A lot of the routine building is handled by the CI infrastructure we have, so you mostly only have to be on your guard for things that affect the features you're working on, or if you're in a strange environment not covered by the CI variations.
<zao>
It's probably not a bad idea to occasionally build master/stable just to see if there's something weird that broke on your machine.
<zao>
Makes it easier to troubleshoot if you know that the thing you base your work on actually works :D
<hkaiser>
gonidelis: you yourself run make as often as needed, in gneral our CI runs all tests on each push to gthub
<gonidelis>
zao Yeah, sometimes I forget how intuitive/great version control is. So, should I just make a `git pull origin master` just to be safe, and then just `git checkout -b my_code` and just handle my work there? I just am careful about no one changing the algorithms directories for the time being in order to avoid conflicts? So after havng completed my
<gonidelis>
work I merge to my base I pull one last time and then push for review? Am i missing sth? hkaiser what is a CI? rori thank you!
<hkaiser>
CI == continuous integration
<hkaiser>
we use CirclCI, github actions, and our own home grown named 'pycicle'
<gonidelis>
hkaiser oh ok. But i think I need to be sure that my code works before pushing and just use the CI as a final test evaluation...
<hkaiser>
gonidelis: whenever you do work, you commit locally to a git branch, once you think it's ready to be merged to the master branch you push to your repository clone on github and create a PR (pull request)
<hkaiser>
you usually make things work in your local environment first, the push to github/create PR which will trigger the CI everywhere
<hkaiser>
github will post the links to the CI results on your PR so you can follow what's happening
<hkaiser>
if things fail there (which they usually do) you keep pushing changes to the same branch, which will re-trigger the CI, etc.
<hkaiser>
we will also give comments and request changes on the PR
<gonidelis>
hkaiser shouldn't my github fork be up to date with your master in order to push the changes tho? =#
<hkaiser>
once everybody (including the CI) is happy, the PR gets merged into the master branch
<hkaiser>
also, you will receive a STE||AR group t-shirt for your first successful merge ;-)
Nikunj__ has joined #ste||ar
<hkaiser>
gonidelis: not necessarily
<zao>
The congratulatory pizza will be arriving later :P
<hkaiser>
however the longer you work on a branch the more divergent it becomes compared to master and the more the likelyhood that there will be conflicts that need to be resolved
<gonidelis>
hkaiser I have already made a mini documentation PR. No shirt yet '=D '=D . That just makes me more willing in order to obtain my trophy-shirt ;p
<hkaiser>
gonidelis: heh, the t-shirt will come - I just don't have physical access to those as they are in a box in my office I can't get to currently ;-)
<gonidelis>
hkaiser ok I am sure i will manage my push. My local hpx folder though derives from a git clone I made few weeks ago to your master (little did I know). Is there any way to keep my build and actually create my personal fork at the same time (and of course connect those two)?
<hkaiser>
gonidelis: sure
<hkaiser>
two ways: either you merge master into your branch, or you rebase your branch onto master - go read the web about the differences, advantages, disadvantages
<hkaiser>
both will update the code you didn't touch to be the same as master
<hkaiser>
and will integrate your changes into those on master for files you actually modified
<gonidelis>
It won't be necessary to run `make -j` after that, right?
<zao>
If you're afraid to ruin your work, you can zip the whole thing up, or look into `git stash`.
<hkaiser>
gonidelis: don't be afraid of running make
<hkaiser>
it's your friend, not your enemy
<hkaiser>
gonidelis: also, you don't have to rebuild everthing, specifying a target to build when using make is always a good idea
<heller1>
better yet, use ninja instead of make
<hkaiser>
I personally never build everything locally, just the things I'm working on (i.e. core HPX libraries and tests needed to check the changes I make are ok)
<hkaiser>
heller1: *sure* (eyeroll)
<heller1>
:P
<gonidelis>
hkaiser haha you are right... it's just a long time coming friend as compiling the whole HPX on my i5 takes about 40mins if I cecall correctly.
<heller1>
as hkaiser said, don't rebuild everything
<heller1>
ninja foreach_prefetching_test && /home/th/nosync/hpx/build/debug/bin/foreach_prefetching_test <-- this is what I am doing right now
<hkaiser>
gonidelis: a) don't recompile everything, b) talk to Alireza (akheir here) to get access to our local cluster (rostam) which is a nice machine you could use for your work if your local machine is too small
<heller1>
if you are using an IDE, those targets are exposed as well
<heller1>
and will rebuild everything that is needed
<gonidelis>
hkaiser i was just about to ask you abour rostam! perfect timing... point taken though. I will make sure to compile specific targets heller1 thank you very much :D
<hkaiser>
gonidelis: send an email to Alireza Kheirkhahan <akheir1@lsu.edu>, cc me, he will guide you
<heller1>
gonidelis: make help will give you all targets
<gonidelis>
hkaiser do you think that my work wil require serious computing power?
<hkaiser>
gonidelis: that's in the eye of the beholder ;-)
<hkaiser>
gonidelis: how much is 'serious'?
<gonidelis>
hkaiser you just keep disarming me with these questions :b
<zao>
It might help thinking about the kind of things you'll be doing. Compiling HPX is one thing, running the test is another, benchmarking the thing is a third.
<zao>
The last one may require multiple compute nodes or many cores, depending on what your project is.
<gonidelis>
zao are just about right... that's what I thought. I ll probably need to use the cluster for the benchmarking part
jaafar has joined #ste||ar
Nikunj__ has quit [Ping timeout: 258 seconds]
<heller1>
gonidelis: it helps to have a bit of power when compiling as well
<heller1>
yay, finally found the asan problem and why it didn't recognized our context switchting anymore
<ms[m]>
heller: amazing! what was the problem?
<heller1>
Missing include
<heller1>
Will file a pr later today
<ms[m]>
...
<ms[m]>
damn
<heller1>
A few leaks are still there
<heller1>
But getting there...
gonidelis has quit [Remote host closed the connection]
<ms[m]>
that's fine, those are at least manageable unlike false positives
<ms[m]>
how did you figure out the missing include?
<heller1>
#ifndef DEFINE \n #error ... #endif
<heller1>
then -E -dM on the source that's giving me the headache.
<weilewei>
ms[m] got a meeting, had to run... but will be back in an hour or so
<ms[m]>
weilewei: np
<ms[m]>
when you're back you'll have to check where gtest is linked
<ms[m]>
hpx_wrap.a would have to end up before gtest_main.a for this to work
gonidelis has quit [Ping timeout: 245 seconds]
Yorlik has quit [Read error: Connection reset by peer]
gonidelis has joined #ste||ar
<weilewei>
ms[m] is there anyway to force prioritizing hpx_wrap before gtest_main? Though I believe I have re-arranged the order, or maybe something goes wrong...
LiliumAtratum has joined #ste||ar
LiliumAtratum has quit [Remote host closed the connection]
nikunj has quit [Read error: Connection reset by peer]
nikunj has joined #ste||ar
<hkaiser>
weilewei: cmake does not have a way to enforce it
<hkaiser>
weilewei: I think the only way would be to make hpx_wrap depend on gtest, not sure whether this is desired/possible
<hkaiser>
ms[m]: ?
<weilewei>
hkaiser ok... but in my cmake, I first link parallel_hpx (which has been linked to hpx_wrap) then link to gtest_main
<ms[m]>
weilewei: hkaiser there's no general way as far as I know (I'd tell you as soon as possible if I found a way)
<ms[m]>
it might be possible playing around with target properties manually and prepending hpx_wrap somewhere
<gonidelis>
should this minor grammatical error be fixed?
LiliumAtratum has joined #ste||ar
<ms[m]>
weilewei: are you sure there's only one place where you link to gtest? do try it the other way around and see if you the libraries move around on the linker line
<ms[m]>
I might have the order mixed up
<LiliumAtratum>
Hello, I am learning using hpx. May I ask some, probably trivial, questions here?
<weilewei>
ms[m] hkaiser or is there any explanation that why make verbose shows getst_main.a goes ahead of hpx_wrap even though I write my cmake order correctly
<weilewei>
ms[m] maybe, let me check
<ms[m]>
gonidelis: should depends on many things, but it would be nice no matter how small the mistake is ;)
<diehlpk_work_>
LiliumAtratum, Welcome
<K-ballo>
weilewei: cmake will order dependencies appropriately, they won't follow your manually specified order
Yorlik has joined #ste||ar
<gonidelis>
ms[m] ok I ll make sure to incorporate it on my next pr then
<weilewei>
K-ballo that's too smart...
<K-ballo>
sounds like you are playing linker tricks?
<K-ballo>
you could take a look at SDLMain for how to handle that kind of thing
<ms[m]>
K-ballo: right on the money (it's the hpx_wrap trickery)
<weilewei>
ms[m] but days ago (or maybe months), I don't have linker problem writing hpx_wrap
<ms[m]>
it needs to be forced to go before a static lib with main
<K-ballo>
hpx_wrap but also gtest_main... sounds wrong
<K-ballo>
you can only get the one main.. which one you want?
<LiliumAtratum>
Right now I fail to compile with hpx, because I have errors coming from Windows libraries: "...\10.0.17763.0\shared\ws2def.h(235): error C2011: 'sockaddr': 'struct' type redefinition; ...\10.0.17763.0\um\winsock.h(1007): note: see declaration of 'sockaddr'". Do I need to include hpx headers in some specific order to avoid that?
<Yorlik>
LiliumAtratum: Ask away!
<gonidelis>
LiliumAtratum I will probably not be able to answer your questions as I am quite new to hpx too but i can certainly tell you that these guys could provide you with serious help. Very supportive team of developers (most of your answers may lie on the documentation already though ;p)
<ms[m]>
it's madness
<ms[m]>
weilewei: if nothing else try to replace whatever you had working before with 1.4.1 with HPX::wrap_main
<ms[m]>
that's what wrap_main is for
<LiliumAtratum>
And my other question - quite trivial probably - which hpx header to include to have `hpx::future` and `hpx::shared_future`. I was surprised that there is no API reference page for those. Only examples. (or I failed finding one)
<zao>
LiliumAtratum: winsock1/2 and Windows.h is an eternal mess.
<Yorlik>
LiliumAtratum: What build environment are you using? BTW: You can install HPX with vcpkg to have it the easy way, though it's not always the latest version.
<LiliumAtratum>
We are using vcpkg and cmake
<nikunj97>
Yorlik, when did we have hpx through vcpkg!!
<nikunj97>
that's a mind saver for me
<zao>
nikunj97: I haven't dared try to install it, pulls in so much Boost.
<Yorlik>
:D
<Yorlik>
hwloc too btw
<nikunj97>
I knew about hwloc and boost
<nikunj97>
but I didn't know vcpkg has hpx as well now!
<Yorlik>
So all the hellish deps are resolved when building with vcpkg: hwloc and boost.
<nikunj97>
I last tried installing 2yrs ago. idk if it was present back then
<nikunj97>
all hail hkaiser _/\_
<zao>
Short answer - yes, you may need to reorder includes to get the right include order.
<Yorlik>
Uncle Kaiser? Whasn't it "Hartmut the White" with this magic staff and stuff? ;)
LiliumAtratum20 has joined #ste||ar
<zao>
Several of those OS headers are controlled by macros and one-shot, so you tend to need to do it right.
<LiliumAtratum20>
ugh... lost connection
<Yorlik>
Make sure you include HPX BEFORE you include boost !
<zao>
"Short answer - yes, you may need to reorder includes to get the right include order."
<Yorlik>
You can read up in the logs
<LiliumAtratum20>
yes, I see the logs. Thank you
LiliumAtratum has quit [Ping timeout: 245 seconds]
<Yorlik>
I wish we had Discord = instant logs
* Yorlik
pokes in some unspecified directions
<nikunj97>
Yorlik, discord is my personal favorite
<LiliumAtratum20>
I like Discord too ;)
<nikunj97>
I guess we're on irc for historic reasons
<gonidelis>
Yorlik nikunj97 can we check logs like one or two weeks old on discord?
<Yorlik>
Yes
<LiliumAtratum20>
I will search for boost usage in my project, but we hardly ever use it.
<gonidelis>
i mean, you have a calendar here
<Yorlik>
You can even search
<nikunj97>
gonidelis, it's a bot logging into a calendar format :)
<Yorlik>
It's a culture thing - Discord is just so incredibly more powerful.
<nikunj97>
Yorlik, agree 100%
<Yorlik>
I especially like the code formatting for snippets.
<gonidelis>
so we can may as well have this bot logging on discord too?
<Yorlik>
There are Discord bots, loggers and everything.
<nikunj97>
gonidelis, discord already has logs and search feature ;)
<Yorlik>
There are kits to writ your own bots too.
<nikunj97>
we can create more powerful bots for logging though
<Yorlik>
It's like using C or modern C++ :D
<gonidelis>
oh ok. not quite familiar. sounds pretty neat
<zao>
Yorlik: Rocket.Chat pushed a broken release in a snap last night.
<nikunj97>
I stream my games through discord. My friends and I have our own server for calls and stuff etc.
<zao>
Both our work instances went down, people scattered to the winds and regathered on IRC :)
<nikunj97>
zao, people still use rocket.chat?
<zao>
I'm amazed that no-one broke it more, as four people were independently trying to fix it.
<nikunj97>
I don't like the js code they have in there
<zao>
nikunj97: Why wouldn't you?
<zao>
It's the least horrible self-hosted choice we found.
<Yorlik>
zao: I guess if we'd use a self hosted solution for control (which I fully understand) there are also better solutions. Riot for example.
<nikunj97>
last time I heard jbjnr had problems with Riot :p
<zao>
Some sites run Matrix. The deployment story and client state is a bit bleh :)
<Yorlik>
There are always problems.
<Yorlik>
people have many problems with IRC
<Yorlik>
Like constant connection losses, being forsed to read the logs and all sorts of shenanigans
<zao>
With some luck I'll manage to get Synapse (Matrix) federation up and running this week.
<zao>
Then I can finally see how bad this channel looks :P
<nikunj97>
:p
<Yorlik>
I can understand the hesitation giving up self hosting - but the price for that is high, and you could alays use IRC as a fallback.
<weilewei>
ms[m] for hpx 1.4.1, and when I try to link my target to HPX::wrap_main, it complains: Target "parallel_hpx" links to target "HPX::wrap_main" but the target was not found.
<zao>
GDPR pretty much mandates self-hosting if we're to touch any form of data.
<nikunj97>
weilewei, what's the problem exactly?
<nikunj97>
I'm the hpx_wrap guy ;)
<weilewei>
nikunj97 you are!
<zao>
(I'll leave you people to topical talk)
<nikunj97>
weilewei, yea it was my gsoc project 2yrs back
<gonidelis>
There is sth probably wrong with my clong-format configs as the nested namespace declarations are stacked the one under the other.
<zao>
gonidelis: What clang-format --version are you on?
<nikunj97>
weilewei, I don't maintain it at the moment, but I haven't seen much changes in the code itself
<gonidelis>
zao 6.0.0
<zao>
That sounds like it might be a wee bit too low?
<weilewei>
So, I have an application where uses gtest_main and includes hpx_main.hpp, but it seems that hpx_wrap.a has to before gtest_main.a . Even though I manually write correct order, but cmake decides gtest_main.a goes before hpx_wrap.a, which is wrong
<nikunj97>
that's a cmake issue then not hpx
<gonidelis>
zao damn! i just `sudo apt`-ed the think. What version am I supposed to use? (I have commented my configs on the gist)
<nikunj97>
weilewei, also does it not work with swapped linking order?
<weilewei>
and then, with hpx 1.4.1, everything works (linking to hpx_wrap), but not not for current master or ms[m] 's PR.
<hkaiser>
K-ballo: would you know how to ensure a certain sequence of libraries on the linker line using cmake?
<K-ballo>
no, that's linker specific
<weilewei>
hkaiser so no solution at this point, yet? just to make sure...
<hkaiser>
weilewei: correct
<K-ballo>
link one of the targets to the other
<hkaiser>
have you tried disabling HPX_WITH_DYNAMIC_MAIN?
<K-ballo>
cmake will pick any correct linking order
<hkaiser>
karame_: yah, that's what I thought, introduce artificial dependencies
<hkaiser>
K-ballo: ^^
<K-ballo>
if there's no dependency then order can't possibly mater
<hkaiser>
can one make external targets depen on each other?
<K-ballo>
mmh.. as INTERFACE
<weilewei>
how to do that specifically? any example cmake code?
<K-ballo>
target_link_libraries(onetarget INTERFACE theothertarget), with a new enough cmake version (3.12+?)
<gonidelis>
Are you using "custom" as clang-format style?
<hkaiser>
gonidelis: no the .clang-format file in the HPX root
<hkaiser>
gdaiss[m]: clang-format should pick that up if you don't specify anything
<hkaiser>
gonidelis
<hkaiser>
darn auto completion
<gdaiss[m]>
^^
<K-ballo>
we never enforced the unique leading letter in nicks rule
<hkaiser>
sorry Gregor
<weilewei>
K-ballo like target_link_libraries(onetarget INTERFACE HPX::wrap_main)?
<hkaiser>
weilewei: well depends on what do you want to depend on what
<K-ballo>
onetarget would pressumably be the gtest_main cmake target
<K-ballo>
and then in whichever order the dependency goes
<gdaiss[m]>
@hkaiser Not a problem! I was wondering why I was getting so many notifications about clang-format - I half expected I forgot to format something :D
<hkaiser>
if hpx_wrap should come before gtest then it's probably target_link_libraries(gtest INTERFACE HPX::hpx_wrap)
<weilewei>
hkaiser K-ballo let me try it
<K-ballo>
but hpx_wrap should be last, no? or how does it work?
<hkaiser>
no idea
<K-ballo>
which ind of linker tricks does it play?
<hkaiser>
weak symbols
<K-ballo>
but then.. the goal is to have gtest_main's main be the real main? I'm confused
<K-ballo>
weilewei: just let me know which order works
<weilewei>
gtest_main has to go later, and hpx_wrap.a goes first K-ballo
<hkaiser>
K-ballo: our main implementation first initializes HPX and then calls the original main
<K-ballo>
I mean cmake order, should be backwards
<weilewei>
K-ballo in cmake, the order was hpx_wrap then gtest_main
<hkaiser>
weilewei: just try it
<K-ballo>
yes that's what I'd expect, link(A B) would put B after A
<zao>
I learned something new the other day, that you could say -l:libblargh.a to leverage library search paths and still specify a full filename.
<zao>
(not helping anything here, of course, just useful)
<gonidelis>
hkaiser well i can see that ther is this "Please do _not_ configure your editor to automatically format the source# file while saving edits to disk" in your .clang-format file. When should I apply the formatting then?
<hkaiser>
gonidelis: this is slightly outdated, we have started to auto-format all files in libs/
<ms[m]>
weilewei: is dca a pain to build? it might be easier if me or jbjnr have a go at it
<hkaiser>
for all other files, pls format only the code sections you touched
<ms[m]>
also, it would be good to know if jbjnr's changes actually compiled for him, because in that case it is really the linker on summit deciding to do something different than on daint (I presume this is where jbjnr was building, but he might have been on summit)
<weilewei>
hkaiser still, with target_link_libraries(gtest_main INTERFACE HPX::hpx_wrap), libhpx_wrap.a is after the libgtest_main.a
<weilewei>
jbjnr gets it working on his laptop, I believe, and said he will try summit today, however, no response so far...
<K-ballo>
weilewei: that's exactly what I'd expect.. you seem to want the other way around
<weilewei>
K-ballo sorry, what would you suggest in terms of the order?
<ms[m]>
it's the other way around
<ms[m]>
hpx_wrap calls the real main
<K-ballo>
link(A B) links A before B per gnu linker rules
<K-ballo>
whatever the proper name of the target is
<ms[m]>
not sure if INTERFACE will enforce that though...
<nikunj97>
zao, fun fact: Julich Supercomputing clusters have been hacked xD
<zao>
nikunj97: Everything's hosed.
<ms[m]>
that does have the downside of linking gtest_main to everything that uses the main wrapping and may blow up elsewhere
<zao>
So happy I'm not a security officer.
<nikunj97>
it's a pretty significant breach
<nikunj97>
they've even shut down the prototype clusters
<weilewei>
CMake Error at cmake/dca_testing.cmake:112 (target_link_libraries): Cannot specify link libraries for target "HPX::wrap_main" which is not built by this project.
<weilewei>
ms[m] K-ballo seems it goes too far ahead...
<K-ballo>
"too far ahead"?
<K-ballo>
which cmake version are you on?
<weilewei>
3.15.2
<weilewei>
what i meant is cmake did not build HPX::wrap_main yet...
<K-ballo>
it is not supposed to build it
<weilewei>
K-ballo so what should I try next
<K-ballo>
you could look for the gnu specific linker flags that let you set an ordered link group, extract absolute paths from targets, conjure some linker flags
<weilewei>
K-ballo ok, I will search it a bit
<gonidelis>
I have specified the binary like `"binary" : "/usr/bin/clang-format-2"`. Do you know how to specify the `.clang-format` file. It was supposed to be reached automatically but it seems it does not...
Yorlik has quit [Read error: Connection reset by peer]
<hkaiser>
weilewei: somewhere the dca app is made depend on gtest
<hkaiser>
try changing the sequence of making it depend on hpx_wrap and gtest
<zao>
gonidelis: It "should" search upwards in the directory hierarchy from where the file is.
<K-ballo>
weilewei: don't use gtest_main and/or hpx_main, that's certainly easier
<gonidelis>
zao I think that I need to declare "style" : "custom" first tho...
<K-ballo>
int main(int argc, char **argv) {
<K-ballo>
::testing::InitGoogleTest(&argc, argv);
<K-ballo>
}
<K-ballo>
return RUN_ALL_TESTS();
<gonidelis>
zao but even when i do, the nested namespaces won't get in the same line... i have installed clang-8
<gonidelis>
do you think i should go with sth like version-9?
<zao>
Does it Do What It Should if you run it on the command line?
<gonidelis>
e
<gonidelis>
sec *
<weilewei>
K-ballo so what you are suggesting is that if gtest_main is used, don't use hpx_main?
<hkaiser>
gonidelis: if you run clang-format from 'inside' the hpx source hierarchy it should pick up the file
<weilewei>
hkaiser ok, let me search it
<hkaiser>
weilewei: I think he's suggesting not to use gtest_main but use the explicit gtest initialization
<hkaiser>
then you can still use hpx_wrap with that
<hkaiser>
gonidelis: but you can stillpoint it to the file, if you want
<weilewei>
hkaiser that might change lots of tests where use gtest_main...
<K-ballo>
weilewei: that's one of the options, the other is to use hpx_main and not gtest_main, the last option is not using either
<K-ballo>
all of those tests can share one single main source
<weilewei>
K-ballo I see, but just too many files are using gtest_main, I don't wanna touch these codes at this point
<K-ballo>
you don't need to
<K-ballo>
there's no need for existing sources to change, they are already relying on their main() coming from elsewhere
<weilewei>
K-ballo then what should I do? Sorry, I might need more info to understand what should I change and not change
<K-ballo>
create your own main in a separate file, ideally integrate both gtest and hpx initialization in it, add that source file to all the tests (or if you must, build that single source as a static library and link it to all the tests in place of gtest_main and hpx_wrap)
<weilewei>
K-ballo I understand it now, let me try, thanks
<gonidelis>
hkaiser it goes like -style=.clang-format ?
<hkaiser>
no -style=file will pick up any .clang-format up the dir hierarchy
<gonidelis>
i reckon that's a version compatibility issue
<gonidelis>
?
<ms[m]>
gonidelis: you'll need clang-format-9
<gonidelis>
ms[m] thanks a lot :D
<gonidelis>
it works!!! thank you
<gonidelis>
`Default shortcut is super+option+a on OSX and option+cmd+a otherwise. This will apply clang-format to the selection.` I have a non-apple keyboard. Does anyone understand which keyes I am supposed to press?
Yorlik has joined #ste||ar
<hkaiser>
gonidelis: depends on your setup
<hkaiser>
your editor can probably have key bindings defined
Yorlik has quit [Read error: Connection reset by peer]
<gonidelis>
ok i will just work with terminal commands just to be safe. Is there going to be a problem here: https://imgur.com/a/2i7vYS9 ? There is an identation every 2 spaces in the first case while there is an identation every 4 spaces on the original format.
LiliumAtratum has joined #ste||ar
<LiliumAtratum>
Hello again :)
<gonidelis>
probably it has to do with sublime, but it appeared after applying `clang-format -i -style=file ...`
<LiliumAtratum>
... with a new question
<LiliumAtratum>
As I am integrating hpx threads into a project which already uses std threads (ultimately it will replace them, but we cannot do it all at ounce). How can I reenter the hpx threading ecosystem when I left into another, non-blocking std thread?
<LiliumAtratum>
I though I just use the `main_pool_executor` and run `hpx::async` on it. But it just hangs when getting from the future it returns.
<LiliumAtratum>
There is this note in the documentation "All tasks executed by one of these executors will run on one of the OS-threads dedicated for the main thread pool. The tasks will not run as HPX-threads.", but frankly I don't understand it, so I don't know if it is related or not.
<hkaiser>
hpx::run_on_hpx_thread(F, Args...)
<LiliumAtratum>
I thought `hpx::async` is executed as a hpx thread
<LiliumAtratum>
oh... I didn't know that function exists!
<hkaiser>
LiliumAtratum: it's a helper function we expose for that
<LiliumAtratum>
I don't see it in the documentation. Should I include <hpx/include/util.hpp> for that?
<LiliumAtratum>
I thought that hpx_main.hpp provides a default main implementation. However, in order to be 100% conformant to the instructions I do now: include <hpx/hpx_start.hpp>, implement main with just hpx::start and hpx::stop, and put all other logic into hpx_main. Still get the same exception much later, when I try to reenter the hpx ecosystem from a
<LiliumAtratum>
regular std thread.
<LiliumAtratum>
Is there a way to log things to help investigate?
<hkaiser>
give me a smallish example reproducing your issue (20 lines of code)
<LiliumAtratum>
oh... I see.... `static thread_local runtime* runtime_` in `src\runtime.cpp`
<LiliumAtratum>
this of course is `nullptr` in my own std thread
<LiliumAtratum>
because hpx has been initialized in a different (main) thread
<LiliumAtratum>
I see `register_thread` right below it. Something I should call, right?
<hkaiser>
LiliumAtratum: do you really want to mess with that?
<hkaiser>
you should be able to cross over into HPX land using the run_on_hpx_thread() facility
<LiliumAtratum>
In our current setup we have a bunch of custom std threads. hpx is called from one of those. Ultimately I want to get rid of those std threads, yes, but this is not a small code-base.
<hkaiser>
from there you have full access to hpx
<LiliumAtratum>
`run_at_hpx_thread` crashes with the exception I am facing
<hkaiser>
what exception?
<LiliumAtratum>
"The runtime system is not active"
<hkaiser>
if HPX was initialize this should just work (tm)
<hkaiser>
then you have not initialized hpx
nikunj has quit [Read error: Connection reset by peer]
<LiliumAtratum>
I did
<hkaiser>
have not called hpx::start or hpx::init yet
nikunj has joined #ste||ar
<LiliumAtratum>
hpx::start is the first thing I call in main
<hkaiser>
if you use hpx::run_on_hpx_thread right after hpx::start it might not be running yet
<LiliumAtratum>
hpx::run_on_hpx_thread is called from within hpx_main. It should be running already.
<hkaiser>
well, hpx_main() is a HPX thread, no need for run_on_hpx_thread from there
<LiliumAtratum>
but the problem seems that I am creating a buch of OS threads within hpx_main.
<hkaiser>
as I said, give me a 20 liner demonstrating your issue
<LiliumAtratum>
And the from what I see, the pointer to the system is stored in a thread-local variable
<hkaiser>
LiliumAtratum: you're trying to work around a problem that is caused by not knowing what you're doing ;-)
<LiliumAtratum>
probably ;)
<hkaiser>
let's step back and get things set up properly, then we can start talking about using register_thread and friends
<LiliumAtratum>
This is how I initialize things:
<LiliumAtratum>
int hpx_main(int argc, char **argv) { // Get a reference to one of the main thread hpx::threads::executors::main_pool_executor scheduler; // run an async function on the main thread to start the Qt application hpx::future<void> qt_application = hpx::async(scheduler, &qt_main, argc, argv); qt_application.wait(); return
<hkaiser>
yah, then it's the missing thread registration
<hkaiser>
LiliumAtratum: you need to get the pointer to the runtime on the main thread (or any thread known to hpx (by calling rts = hpx::get_runtime_ptr()) and marshal that pointer to the new thread wher eyou call hpx::register_thread(rts, "<some_unique_name>");
<hkaiser>
then you should be able to use run_on_hpx_thread
<LiliumAtratum>
and I see I should unregister it too
<LiliumAtratum>
OK. Shouldn't be a problem, now that I know what needs to be done.
<LiliumAtratum>
As I said, ultimately we want to get rid of those std threads entirely.
<zao>
Ooh, neat.
<hkaiser>
sure
<LiliumAtratum>
So - many thanks for your time!
<hkaiser>
thanks for your patience!
<hkaiser>
LiliumAtratum: the unregister is just to clean up things - its c++ after all
nikunj has quit [Ping timeout: 240 seconds]
nikunj has joined #ste||ar
sayefsakin has quit [Remote host closed the connection]
<LiliumAtratum>
Good night!
LiliumAtratum has quit [Remote host closed the connection]
karame_ has quit [Remote host closed the connection]
rtohid has quit [Remote host closed the connection]
nan11 has quit [Remote host closed the connection]
gonidelis has quit [Remote host closed the connection]
weilewei has quit [Write error: Broken pipe]
rtohid has joined #ste||ar
weilewei has joined #ste||ar
karame_ has joined #ste||ar
nan11 has joined #ste||ar
Yorlik has joined #ste||ar
<jbjnr>
weilewei: ms[m] I do not have any link problems with hpx_main or wrap on summit. I have some errors with dca::func, but apart from that thinks seem fine. It might be YET ANOTHER of those dodgy cmake cache problems caused by all the changes in modularization. weilewei I'll send you my output via slack. off to bed now.
rtohid has left #ste||ar [#ste||ar]
nikunj97 has quit [Read error: Connection reset by peer]
<weilewei>
jbjnr thanks for checking!
<Yorlik>
Building HPX on my new machine for the first time: 12 cores, 24 threads slammed :D
<Yorlik>
And done
<Yorlik>
That was crazy fast :D
<Yorlik>
After the download was finished just a tad over 2 minutes. Including tests but without examples.