aserio changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | | HPX: A cure for performance impaired parallel applications | | Buildbot: | Log:
eschnett has joined #ste||ar
eschnett has quit [Quit: eschnett]
hkaiser has quit [Quit: bye]
EverYoung has quit [Ping timeout: 260 seconds]
pree has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
<pree> what the HPX_REGISTER do ? Is it something related to AGAS service stuff's. I found lot more in hp
<pree> * hpx components . And how they are useful?
<pree> and what's the diff between hpx_regiter_action and hpx_register_action_declaration ?
eschnett has joined #ste||ar
eschnett has quit [Quit: eschnett]
patg has joined #ste||ar
pree_ has joined #ste||ar
pree has quit [Ping timeout: 240 seconds]
patg has quit [Quit: See you later]
<heller_> pree_: the difference between declaration and definition
pree_ has quit [Ping timeout: 260 seconds]
pree_ has joined #ste||ar
<pree_> sorry i was disconnected. But my question is what HPX_REGISTER actually do ? Because I didn't come from distributed background.
<pree_> It makes me think why we need this.
quaz0r has quit [Ping timeout: 245 seconds]
quaz0r has joined #ste||ar
Matombo has joined #ste||ar
<heller_> pree_: they register actions for portable serialization
<taeguk> In hpx, Doesn't Circle CI perform all unit tests?
<taeguk> It seems to perform only hello_world tests...
<taeguk> and inspection..
<jbjnr> taeguk - it should run unit tests ...
<jbjnr> but I can't see them either on the circleci page
<heller_> It does not, unfortunately
<heller_> It would take way too long
<heller_> We clearly need a better pr testing
<heller_> Better testing infrastructure in general
<jbjnr> odd. running the unit tests only takes 5 minutes if none of them hang and with a ctest timeout of (say) 30 seconds and an overall kill of the ctest, we could surely run the unit tests as well
<jbjnr> heller_: question :
<jbjnr> why is there an executor_base class and an executor class, but they are not part of the same heirarchy?
<taeguk> Currently, Circle-Ci just check compile-success, inspection-success, and just hello world tests. I think it is very lack. It should be improved.
<jbjnr> taeguk correct
<taeguk> Most of time (3hours) is used for just only checking compile-success.
<jbjnr> you can (and should) do a "ctest -R tests.unit " before you submit your PR of course.
<heller_> jbjnr: ask Hartmut, no idea ;)
<jbjnr> ok
<heller_> jbjnr: 5 minutes on a fast machine, iirc
<jbjnr> of cpourse, the problem is that we never have a green dashboard with all tests passing, so no PRs would ever be allowed if all tests had to pass :(
<taeguk> Why are all failed in ctest to tests.unit.parallel?
<jbjnr> did you make test.unit first?
<taeguk> ah sorry ;)
<jbjnr> use ctest -V to see verbose and then you might see the reason
<jbjnr> do a "make help" and you can see all the targets. there are pseudo targets to help you build test.unit.parallel for example, then ctest -R tests.unit.parallel
<jbjnr> to ust build/run subsets of the tests
<taeguk> jbjnr: Good. Thank you to your advice.
Matombo has quit [Remote host closed the connection]
bikineev has joined #ste||ar
<heller_> jbjnr: blame hartmut, he always comits broken tests :P
wash[m]_ has joined #ste||ar
wash[m] has quit [*.net *.split]
wash[m]_ is now known as wash[m]
<jbjnr> heller_: lol
bikineev has quit [Ping timeout: 240 seconds]
<github> [hpx] StellarBot pushed 1 new commit to gh-pages:
<github> hpx/gh-pages 0e1fc62 StellarBot: Updating docs
pree_ has quit [Quit: AaBbCc]
pree_ has joined #ste||ar
bikineev has joined #ste||ar
pree_ has quit [Ping timeout: 260 seconds]
david_pfander has joined #ste||ar
pree_ has joined #ste||ar
bikineev has quit [Ping timeout: 240 seconds]
K-ballo has joined #ste||ar
heller_ has quit [Quit: - Chat comfortably. Anywhere.]
heller_ has joined #ste||ar
hkaiser has joined #ste||ar
<jbjnr> hkaiser: hello. Got time for a quick question?
<hkaiser> sure
<jbjnr> in this case, there is slicing.
<jbjnr> but the executor only hold a pointer to the executor_base, so is it actually bad?
<hkaiser> how can it slice if both types just hold a pointer to the implementation?
<hkaiser> you shouldn't add members to your customized_pool_executor, though
<jbjnr> well, I'm assigning a derived class to the scheduled_executor, so I am doing a 'bad thing' but in this case it ought to be safe. I just wanted to have a second opinion
<jbjnr> I wanted to avoidn executors by pointer
<hkaiser> no bad thing, perfectly valid operation
<jbjnr> ok, great
<jbjnr> aah. meeting. gtg
<hkaiser> I'm assuming the custom_pool_executor is derived from scheduled_executor
<heller_> jbjnr: did my access to tave got removed?
<heller_> jbjnr: I should read the MOTD...
<jbjnr> heller_: system wide maintenance today
<jbjnr> all machines down
<jbjnr> hkaiser: yes, the custom pool executor is derived from scheduled_executor.
denis_blank has joined #ste||ar
bikineev has joined #ste||ar
hkaiser has quit [Quit: bye]
akheir has joined #ste||ar
aserio has joined #ste||ar
<wash[m]> aserio: I am planning to be on the call
<aserio> wash[m]: thanks
hkaiser has joined #ste||ar
<github> [hpx] hkaiser opened pull request #2664: Adding uninitialized_move and uninitialized_move_n (master...uninitialized_move)
<wash[m]> aserio: on skype
<aserio> wash[m]: the meetings now take place at 10:30am
<aserio> (8:30atPT)
<wash[m]> Oh
<wash[m]> I am in eastern time
<wash[m]> So it's 11:30, haha
<github> [hpx] Naios opened pull request #2665: Hide the `detail` namespace in doxygen per default (master...hide_detail)
<pree_> while Invoking copy-constructor for components ( on gid of the component) Are we making 2 copies on same component instance ? because hpx::components::copy function already creates a copy and gives it's gid.
<zao> My interpretation of a 'gid' is that it's the distributed analogue of a shared_ptr.
<zao> Copying a gid itself should just make another ref to the same component, while explicitly copying a component clones the component itself, however you do that.
bikineev has quit [Ping timeout: 268 seconds]
<zao> Someone should probably fix the docstring on the single argument copy too, as there's no target_locality:
<zao> (note, I have no idea how HPX actually is designed)
<pree_> Thanks @ zao
Matombo has joined #ste||ar
bikineev has joined #ste||ar
<aserio> wash[m]: Are you on?
<wash[m]> Yes
<wash[m]> At least it shows me as on on my end, bryce.lelbach
<aserio> Calling
hkaiser has quit [Quit: bye]
bikineev has quit [Read error: Connection reset by peer]
bikineev has joined #ste||ar
justwagle has joined #ste||ar
hkaiser has joined #ste||ar
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
justwagle has quit [Quit: Leaving]
david_pfander has quit [Ping timeout: 260 seconds]
jaafar has joined #ste||ar
denis_blank has quit [Quit: denis_blank]
denis_blank has joined #ste||ar
bikineev has quit [Read error: Connection reset by peer]
Matombo has quit [Remote host closed the connection]
bikineev has joined #ste||ar
<denis_blank> Is there any difference between `dataflow(<callable>, <futures>...)` and `when_all(<futures>...).then(<callable>)` - also regarding its cababilities (launch policies...)? Because when crawling the codebase, I perceive the opinion that we theoretically could deprecate `dataflow`, because it basically duplicates `when_all(...).then(...)`.
<denis_blank> hkaiser: ^
<K-ballo> one shared state vs two
<K-ballo> does that mean `when_all` lets non-futures pass thru now?
<hkaiser> denis_blank: dataflow is the same (conceptually) as when_all().then()
<pree_> Can anyone please tell me what are the differences bwt hpx::managed::component and hpx::fixed::component ? I didn't find in docs
<pree_> thanks
<hkaiser> but it's implementation is more efficient
<hkaiser> pree_: fixed_components have a predefine global id
<hkaiser> managed_components get one assigned
<denis_blank> K-ballo: No, it's not possible yet (but lets assume it would, for the comparison).
<K-ballo> fair, but I don't think when_all should accept non-future inputs
<pree_> Okay. I will look at it's use cases. Thank you @hkaiser
<hkaiser> : I agree
<hkaiser> pree_: I think you can ignore fixed_components
<hkaiser> they are used internally only
<pree_> oh okay !
<denis_blank> K-ballo, hkaiser: Theoretically it's possible to return an intermediate future class from when_all which delays the creation of its state so we would just create one shared state when using `when_all(...).then(...)`. Assuming that would it be theoretically possible then, to deprecate dataflow?
<K-ballo> yes, if you assume all the things that can't be done or aren't a good idea, then it would be possible :)
<K-ballo> someone once's suggested an expression template kinda return for when_all, I think it was chandler
<hkaiser> denis_blank: I don't think you should try to 'optimize' when_all() for the case that it has a then()
<K-ballo> we don't want to go there, those are different separate things
<hkaiser> right
<K-ballo> but yes, it is technically possible, for some definition of possible
aserio has quit [Ping timeout: 246 seconds]
<denis_blank> Alright, thank you for your answers
<hkaiser> K-ballo: the difference between value-construct and default-construct is significant for build-in data types, yes?
Matombo has joined #ste||ar
<hkaiser> i.e. new (p) T; and new (p) T();
<K-ballo> yep
<hkaiser> ok
<K-ballo> and for all trivially-constructible-types
<hkaiser> sure
Matombo has quit [Remote host closed the connection]
<heller_> denis_blank: also consider the signature of callable. Two very different things there
pree_ has quit [Ping timeout: 260 seconds]
<diehlpk_work> heller_, hkaiser When do we have our meeting today?
<denis_blank> heller_: In which way are the signatures different?
aserio has joined #ste||ar
eschnett has joined #ste||ar
aserio has quit [Ping timeout: 255 seconds]
akheir has quit [Remote host closed the connection]
aserio has joined #ste||ar
bikineev has quit [Remote host closed the connection]
<hkaiser> K-ballo: how can I verify whether a value-constructor was actually called for a variable
<hkaiser> sorry, 'whether a variable was vaue-constructed
<hkaiser> value*
<hkaiser> (for testing purposes)
<K-ballo> you can't, really, not 100% guaranteed
<hkaiser> nod
<hkaiser> thought so
<K-ballo> if you have a union, it tends to show...
<hkaiser> ok, how so?
<K-ballo> value-constructed union value-initializes the first alternative and zero-fills the rest
<K-ballo> default-constructed union doesn't touch any bytes
<hkaiser> I would like to be able to test uninitialized_value_construct
<hkaiser> how could I do that?
<K-ballo> union { int first; char canary[256]; } u{}; u.canary[255] == 0;
<K-ballo> but there's always a chance the garbage on the stack was already 0
<hkaiser> I could malloc th ememory and prefill with 0xcd
<K-ballo> sounds good
<hkaiser> k
<K-ballo> hkaiser: btw I was lazy above and accessed an inactive union member, don't do that, just memcmp against 0
<K-ballo> or walk the bytes or whatever
<K-ballo> actually you don't even need the union
<hkaiser> K-ballo: what do you mean
<K-ballo> if you can prefill the memory with 0xcd, then for a trivially-constructible-type value-init will fill with 0s whereas default-init won't touch it
<hkaiser> default-init can be tested with a simple type which has an explicit default constructor
<K-ballo> sure, any type that is trivially constructible
<K-ballo> say, int
<K-ballo> if you are in control of the memory then it's easy
<hkaiser> struct foo { foo() : value(42) {} int value; };
<K-ballo> for such a struct default-init and value-init are the same thing, you can't tell them apart
<hkaiser> yah, but I know I test for default initialization or for value init, so I can use different methods to verify
<hkaiser> memcmp to 0 for value-init and cmp to 42 for the above
<K-ballo> I don't follow... but if it works for you
<hkaiser> nod, thanks anyways
<K-ballo> the above will always set the memory to 42
<K-ballo> for either default-init or value-init
<hkaiser> I don't want to find out whether something was default initialized or value initialized
<hkaiser> so that is fine
<hkaiser> thanks
<K-ballo> so the test ...
<K-ballo> so you are not verifying that a value-ctor is called?
<K-ballo> just add a global, and up the count on each default constructor
<K-ballo> *construction
<hkaiser> I want to verify that a value ctor is actually called, and independently (for a different test) whether default constructor was called
<K-ballo> I suppose we are using different terminology
<K-ballo> anyways, I'll see it later in code
<hkaiser> right, I'm inprecise
hkaiser has quit [Quit: bye]
bikineev has joined #ste||ar
hkaiser has joined #ste||ar
<github> [hpx] hkaiser closed pull request #2665: Hide the `detail` namespace in doxygen per default (master...hide_detail)
<github> [hpx] hkaiser created uninitialized_default_construct (+1 new commit):
<github> hpx/uninitialized_default_construct a3b25d7 Hartmut Kaiser: Adding uninitialized_default_construct and uninitialized_default_construct_n
eschnett has quit [Quit: eschnett]
<K-ballo> hkaiser: are those supposed to be testing default-init ?
<hkaiser> yes
<github> [hpx] hkaiser pushed 1 new commit to uninitialized_move:
<github> hpx/uninitialized_move e1ee7b0 Hartmut Kaiser: Documentation fixes
<K-ballo> I believe those would still pass if someone were to "fix" the implementation from new T to new T()
<hkaiser> K-ballo: well, I think I got it wrong anyways :/
<K-ballo> you did? how?
<hkaiser> should be value_type()
<hkaiser> no, that's correct
<hkaiser> value-init would be value_type()
<K-ballo> right
<hkaiser> K-ballo: but yah, this still would pass if somebody 'fixed' the implementation ;)
<hkaiser> K-ballo: let me implement value-init first, then I'll have a second look atthis
<aserio> hkaiser: yt?
<hkaiser> aserio: here
<aserio> hkaiser: see pm
<zbyerly_> aserio, hey how many PIs are in the cluster?
<aserio> zbyerly_: you would have to ask Frank
<github> [hpx] hkaiser created fixing_doc_index (+1 new commit):
<github> hpx/fixing_doc_index 1503600 Hartmut Kaiser: Fixing documentation index,...
aserio has quit [Quit: aserio]
<github> [hpx] hkaiser opened pull request #2668: Fixing documentation index (master...fixing_doc_index)
justwagle has joined #ste||ar
justwagle has quit [Client Quit]
hkaiser_ has joined #ste||ar
hkaiser has quit [Read error: Connection reset by peer]
bikineev has quit [Remote host closed the connection]
bikineev has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
K-ballo has joined #ste||ar
denis_blank has quit [Quit: denis_blank]
bikineev has quit [Remote host closed the connection]