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/
hkaiser has quit [Quit: bye]
K-ballo has quit [Quit: K-ballo]
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
K-ballo has quit [Remote host closed the connection]
K-ballo has joined #ste||ar
<Yorlik> Did something change with make_action? I am getting this error since I compiled and am using 1.3.0 (as opposed to 1.2.1) : error C2027: use of undefined type 'hpx::actions::make_action<....
<Yorlik> Triggered here: "HPX_DEFINE_COMPONENT_ACTION ( controller, resume );"
<zao> Missing some header that might have been implicitly included in the past, maybe?
<Yorlik> Could be anything - I hoped someone would know without me digging a ton of gravel ...
<zao> Someone not me probably knows :)
<Yorlik> Seems its time to rebuild the doxygen docs ...
<K-ballo> is there a corresponding DECLARE somewhere?
<K-ballo> I don't recall the actions details anymore, there was something confusing in their use of declare vs define (vs register?)
<Yorlik> The code used to work with 1.2.1
<Yorlik> So - yes
<Yorlik> Though - wait a sec - I might have deleted sth - checking
<Yorlik> Yup - its all there
<Yorlik> But it's possible I did sth without noticing though I can't remember anything
<K-ballo> so we don't know for sure the code in its current form works with 1.2.1 then?
<Yorlik> I'm sure 99%
<K-ballo> not much has changed around basic actions definitions that I know of, but it's possible some new trait or something crept in and some corresponding #include is missing
<Yorlik> But I know my flaws - lol
<K-ballo> drop the error message on some paste site, for quick inspection
<Yorlik> kk
<K-ballo> another possibility is that we had some bogus earlier instantiation, in the form of implicit return type deduction, unsequenced sfinae, etc
<K-ballo> *have
<Yorlik> Do we have any preferred past sites here?
<zao> Github gists are always fine
<K-ballo> whatever works
<zao> ^^
<Yorlik> Its a secret gist - hoipe it works
<zao> Yeah.
<Yorlik> Its a beast of an output ...
<K-ballo> so this is not one of your actions, but one of hpx's own
<K-ballo> chances of an hpx bug just increased to 99.9%
<Yorlik> :(
<zao> VS 2019, eh?
<Yorlik> Yup
<Yorlik> Vs2019, boost 1.70, hpx 1.3.1
<K-ballo> presumably controller.hpp is using the remote latch? show me how you include its headers
<Yorlik> its using #include <hpx/runtime/components/component_factory_base.hpp> and the ..#hpx.hpp
<K-ballo> 99.999%
<Yorlik> If you want me help track this down just tell me what to do - I'm also open for a live session with screensharing
<K-ballo> there's a bit of a problem in that the declaration and the definitions are in the same header
<K-ballo> there must be an explicit specialization declaration somewhere, otherwise it would be impossible to hit an undefined type error
<K-ballo> but I don't think we have those...
<K-ballo> I think we may have, ages ago
<Yorlik> I get wiggles on HPX_DEFINE_COMPONENT_ACTION
<Yorlik> I think I'm missing a header
<Yorlik> It thinks the macro is a funbc
<Yorlik> *function
<Yorlik> doxygen is still chewing - lol
<K-ballo> could it be a circular include?
<Yorlik> possible - but I am trying hard to avoid these and all my headers are guarded
<K-ballo> I don't see how it is possible for HPX_DEFINE_COMPONENT_ACTION to see the make_action declaration, but not the definitions a couple lines below
<K-ballo> I must be misreading that error
<zao> Preprocess with /P and squint at the gigantic output, maybe?
<Yorlik> Inside the constroller class definition in my header i have this: // resume a suspended game
<Yorlik> uint8_t resume ( );
<Yorlik> HPX_DEFINE_COMPONENT_ACTION ( controller, resume );
<Yorlik> outside of the class I have this:
<Yorlik> HPX_REGISTER_ACTION_DECLARATION ( game::controller::resume_action, gamecontroller_resume_action )
<Yorlik> And in the .cpp:
<Yorlik> HPX_REGISTER_ACTION ( game::controller::resume_action, gamecontroller_resume_action )
<K-ballo> the first compiler error is on hpx's latch, that's the one that we have to focus on
<Yorlik> HPX_REGISTER_COMPONENT_MODULE ( ); and HPX_REGISTER_COMPONENT ( gamecontroller_type, gamecontroller ); are also there
<K-ballo> any errors after that could be from the compiler carring on
<Yorlik> OK
<K-ballo> could you try including #include <hpx/runtime/actions/component_action.hpp> as the very first thing in that cpp file?
<Yorlik> the cpp?
<K-ballo> yes
<K-ballo> repos\sim\src\controller.cpp
<Yorlik> compiling ...
<Yorlik> exploded again
<Yorlik> looks like the same error
<Yorlik> error in latch.hpp
<K-ballo> coming from that .cpp file, right?
<Yorlik> Yup
<K-ballo> then I can only think of circular includes, but I cannot reproduce locally
<hkaiser> Yorlik: I ran into that recently with the latest msvc
<Yorlik> Aww
<Yorlik> I just updated to 2019
<hkaiser> #3875 solves this
<Yorlik> yesterday ..
<hkaiser> some tests are failing there, but it should work in principle
<zao> (how cute, Boost binary Windows downloads are now on sourceforge again)
<K-ballo> Converted typedefs in actions submodule to using directives ??
<hkaiser> K-ballo: not only
<K-ballo> mmh
<K-ballo> so what's the relevant change?
<hkaiser> before it was typedef typename make_action<...>::type;, the trick was to remove the ::type
<hkaiser> I just converted the typedef to using's while I was at it ;-)
<Yorlik> So I could just update to master from 1.3.1 tagged ?
<K-ballo> ok, that's a slight change in behavior
<hkaiser> sure, but it since we access the action type through a trait all is well
<Yorlik> hkaiser: should I just update to master? Usually I stay with tagged releases
<K-ballo> ideally we should remove that inheritance in `make_action`, it was there to support some ancient use cases
<hkaiser> Yorlik: it's not merged to master yet
<hkaiser> K-ballo: I thought the other way around
<Yorlik> Aww
<hkaiser> moreso as msvc breaks now
<K-ballo> having that inheritance has strictly more requirements than having the alias
<K-ballo> the inheritance was there because some old use case was relying on the older implementation and skipping the ::type
<hkaiser> ok
<hkaiser> well, if you have an idea how to unbreak msvc, please be my guest
<K-ballo> if I can find some time I will try doing both changes at the same time, see what breaks
<hkaiser> k
<K-ballo> it should be the inheritance that it is breaking, but I cannot confirm.. it could just be just the usual bad pattern matching
<hkaiser> ok, I can try removing the inheritance
<K-ballo> inheriting from the action forces the type to be complete
<K-ballo> but then some of the gcc/clang builders would have caught this
<hkaiser> clang never complained (so far)
<Yorlik> I guess you're not using clang compiled Boost on windows?
<hkaiser> no
<hkaiser> does clang compile boost on windows now?
<hkaiser> natively?
<Yorlik> It always exploded for me with a ton of warnings
<Yorlik> So - no. I use cl for everything win.
<zao> Feels more like that Boost needs to care about the LLVM toolsets in the first place. No idea how well it does in a generic MSVC command prompt.
<zao> (I haven't bothered trying)
eschnett has quit [Quit: eschnett]
<Yorlik> hkaiser: any idea when this fix will make it into master?
<hkaiser> Yorlik: I'll try to work on it
<hkaiser> for now, just use that PR
<Yorlik> Thanks ! :)
<Yorlik> I thinbk I'll do some Lua in between
<hkaiser> Yorlik: I'll let you know
<Yorlik> Thank you !
eschnett has joined #ste||ar
eschnett has quit [Quit: eschnett]
bibek has quit [Read error: Connection reset by peer]
bibek has joined #ste||ar
eschnett has joined #ste||ar
bibek has quit [Quit: Konversation terminated!]
bibek has joined #ste||ar