K-ballo 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/
bita has joined #ste||ar
bita has quit [Ping timeout: 260 seconds]
hkaiser has quit [Quit: bye]
akheir has quit [Quit: Leaving]
surbhi has joined #ste||ar
LiliumAtratum has joined #ste||ar
<LiliumAtratum>
Small question. I am running a thread, spawned by `hpx::async` on a `hpx::threads::executors::main_pool_executor`. When I try to get an id on a thread (`hpx::this_thread::get_id()`) I get a value 0. Is there a way to assign an actual, unique ID for a thread managed by such an executor?
<LiliumAtratum>
I tried `hpx::register_thread` but that didn't help
<heller1>
No, that's currently not possible. What is it you are trying to achieve?
<LiliumAtratum>
I have threads that read/write to a repository. The access is performed under the mutex
<LiliumAtratum>
The problem is, one of the threads is a render thread, which is run by the said executor and not a "native" hpx thread
<heller1>
ok
<LiliumAtratum>
and I use get_id() for debugging, to check if the proper mutex is actually set
<heller1>
If I am not completely mistaken, both `hpx::mutex` and `hpx::spinlock` work in non HPX threads
<LiliumAtratum>
I certainly hope so :)
<LiliumAtratum>
mutex is not the problem, get_id for debugging problems is
<LiliumAtratum>
but I think I found a walkaround
<heller1>
`hpx::threads::get_self_id` maybe?
<LiliumAtratum>
get_id for debugging purposes is (I type to fast :P )
<LiliumAtratum>
I used `hpx::this_thread::get_id()`. The other one does something different?
<heller1>
I'd have to check
<heller1>
the other one is the one that is being used by `hpx::mutex` :P
<heller1>
what would work is something like: `hpx::execution_base::agent().description()`
<heller1>
* what would work is something like: `hpx::execution_base::agent().description()` (for debugging that is)
<LiliumAtratum>
You think it would work in this context: `std::set<hpx::thread::id> g_readingThreads` ?
<heller1>
yes, it returns a string
<LiliumAtratum>
worth a try then
<LiliumAtratum>
is there such a thing? Do you mean `hpx::threads::execution_agent::description` ?
<LiliumAtratum>
There seems to be no `hpx::execution_base::agent()` and I can't find it in the documentation either. Or maybe I am at an old version of HPX (still 1.4.1 I believe)
<heller1>
not sure anymore when this was added..
<LiliumAtratum>
but it's not in the 1.5.1 doc
<heller1>
sorry, it is `hpx::execution_base::this_thread::agent()` sorry
<heller1>
* sorry, it is `hpx::execution_base::this_thread::agent()`
LiliumAtratum has quit [Remote host closed the connection]
K-ballo has quit [Ping timeout: 260 seconds]
hkaiser has quit [Quit: bye]
K-ballo has joined #ste||ar
akheir has joined #ste||ar
hkaiser has joined #ste||ar
<ms[m]>
LiliumAtratum: nope, hpx::mutex won't work on a non-hpx thread
<ms[m]>
the question is: what are you trying to do? the main_pool_executor doesn't run separate tasks/threads for each invocation of hpx::async, it just runs those functions directly in the main thread
<ms[m]>
meaning there isn't really an id to keep track of
<ms[m]>
K-ballo: yeah, no worries, I wasn't expecting you to do anything about the rp
<ms[m]>
I'm moderately familiar with it nowadays and can try to do something about it
nanmiao11 has joined #ste||ar
louisa[m] has quit [Quit: Idle for 30+ days]
dagmar[m] has quit [Quit: Idle for 30+ days]
k-ballo[m] has quit [Quit: Idle for 30+ days]
hkaiser has quit [Ping timeout: 260 seconds]
hkaiser has joined #ste||ar
bita has joined #ste||ar
<gnikunj[m]>
diehlpk_work_: did you read the latest email regarding gsoc 2021?
<diehlpk_work_>
gnikunj[m], Not yet
<gnikunj[m]>
diehlpk_work_ they're reducing total working hours from 350h to 175h and also cutting gsoc stipends to half
<gnikunj[m]>
Also, they're now open to any student (need not be accredited)
<gnikunj[m]>
Others were minor changes
<diehlpk_work_>
Ok, so we need to think about smaller projects
<K-ballo>
need not be accredited?
<diehlpk_work_>
There is not need to be a student
<K-ballo>
meaning I could do gsoc?
<K-ballo>
sounds... not good
<diehlpk_work_>
Yes, I think so
<gnikunj[m]>
k-ballo if you're a student, sure!
<gnikunj[m]>
Essentially they're open to a student who's part of let's say a coding boot camp as well. Earlier they were not eligible. But with recent changes, they can also apply.
<gnikunj[m]>
Or a community college student
<K-ballo>
community college students are not accredited?
<gnikunj[m]>
According to them, they weren't. That's what they wrote in the email
<weilewei>
They cut the project time (30hr to 15hr) to half as well as stipend lol
weilewei has quit [Remote host closed the connection]
gonidelis[m] has quit [*.net *.split]
kordejong has quit [*.net *.split]
gdaiss[m] has quit [*.net *.split]
mdiers[m] has quit [*.net *.split]
tiagofg[m] has quit [*.net *.split]
mdiers[m] has joined #ste||ar
tiagofg[m] has joined #ste||ar
kordejong has joined #ste||ar
gdaiss[m] has joined #ste||ar
gonidelis[m] has joined #ste||ar
jaafar has quit [Ping timeout: 240 seconds]
jaafar has joined #ste||ar
<gnikunj[m]>
hkaiser: yt?
<hkaiser>
gnikunj[m]: here
<gnikunj[m]>
hkaiser: I'm going through the boost spirit tutorial and have a doubt in this code :https://www.boost.org/doc/libs/1_66_0/libs/spirit/example/qi/roman.cpp
<hkaiser>
ok
<hkaiser>
what's your question?
<gnikunj[m]>
in the main function boost::spirit::qi::parse it directly adds the roman's object
<gnikunj[m]>
should it not add the rule instead?
<gnikunj[m]>
the function parse takes in a qi::rule so why does the object work?
<gnikunj[m]>
talking about the line: bool r = parse(iter, end, roman_parser, result);
<hkaiser>
roman_parser is a grammr object, why shouldn't this work?
<gnikunj[m]>
so the function parse takes in grammar objects as well?
<gnikunj[m]>
In the tutorial it was talking about rules
<hkaiser>
gnikunj[m]: HPX docs will be well written once somebody is interested in investing time to produce it ;-)
<gnikunj[m]>
:D
<gnikunj[m]>
I was writing blogs in summers when I got bombarded with work
<gnikunj[m]>
I'll take that up once I have time. That should help beginners to get started in HPX
bita has quit [Ping timeout: 260 seconds]
<gnikunj[m]>
hkaiser: curious question why do have both [_val = _1] and %= when the latter is shorter and more elegant?
<K-ballo>
have you seen [_val = _1] actually being used? is it a sequence parser?
<gnikunj[m]>
K-ballo: I'm going through boost spirit tutorials. I saw them in the beginning
<gnikunj[m]>
but in the tutorial with boost fusion adapt, it uses %= and says it's equivalent to adding [_val = _1]
<K-ballo>
in the simplest cases it is
<K-ballo>
but then [_val = _1] is a special case of a general pattern [_val = foo]
<gnikunj[m]>
It says this in the tutorial: r = p[_val = _1]; If you have a rule definition such as the above, where the attribute of the RHS (right hand side) of the rule is compatible with the attribute of the LHS (left hand side), then you can rewrite it as: r %= p;
<gnikunj[m]>
true [_val = foo] would be a generalized case
<K-ballo>
yeah, for the right kind of "above" that would apply
<K-ballo>
[_val = _1] wasn't created as an alternative to %=, %= was created as an alternative to [_val = _1] (except _1 isn't always the right thing either)
<K-ballo>
my suggestion would be: don't learn those things
<gnikunj[m]>
sounds good.
<K-ballo>
if you can ignore semantic actions entirely, even better
<gnikunj[m]>
are semantic actions bad?
<gnikunj[m]>
why should I ignore them?
<K-ballo>
it's a whole entire level of complexity, mostly unnecessary
<gnikunj[m]>
I see. I may require them when writing a language though.
<K-ballo>
no
<gnikunj[m]>
ohh, how so? (spoiler alert: I'm still doing tutorials and have no clue if I can avoid them)
<K-ballo>
you can definitely avoid them, you'd only use them to coerce your parser to an unnatural AST, and you don't even need them for that either
<K-ballo>
I think I've used it once in my C parser, for dealing with precedence
<K-ballo>
should have done a real parser, but back in v2 defining parsers was super annoying, full of boilerplate
<K-ballo>
x3 is.. something else, not necessarily better
<K-ballo>
it is lighter at compile time, there is that
<K-ballo>
it is less powerful, part of it by design and part because it was never actually completed
<gnikunj[m]>
lol what do you mean it was not completed? Did the person working on it leave?
<K-ballo>
well.. joel did... and so did I... so kinda, yes
<gnikunj[m]>
ohh, I didn't know you were part of boost as well!
<gnikunj[m]>
that's so amazing! what part of x3 is not completed btw, if i may ask?
<K-ballo>
inherited attributes was the most salient one that I remember
<K-ballo>
but plenty of other stuff hadn't been done, at least when I stopped looking at it
<K-ballo>
stuff was being added on demand, based on actual usages
<gnikunj[m]>
aah, so boost spirit is kind of dead atm?
<K-ballo>
no idea about now
<gnikunj[m]>
I see. In any case, I really like the documentation with boost spirit v2 (qi and karma)
<K-ballo>
oh that's another thing x3 was missing, docs
<K-ballo>
it had some partial thing, rushed out for the cppnow talk
<gnikunj[m]>
lol, I'm not looking at x3 then.
<K-ballo>
looks like it got a more mature port now
<K-ballo>
people kept asking whether x3 was meant for public use or not, since it was shipped by boost but the crude docs were hosted somewhere else outside of boost
<gnikunj[m]>
ohh
<gnikunj[m]>
that's strange
<K-ballo>
if I was forced to, I'd pick x3 over qi, but that's because I count on being able to add whatever functionality x3 is missing
<K-ballo>
oh, x3 didn't have any lexer support either
<K-ballo>
I did implement that, lexers are crucial for any real parser, I have it somewhere
<gnikunj[m]>
but that never got merged into x3?
<K-ballo>
joel doesn't believe on lexers
<K-ballo>
I even had an x3-based lexer prototype, so I would have x3 grammars working on top of x3 lexers
<gnikunj[m]>
but qi does have lexer right? (and he did work on it)
<K-ballo>
spirit has a lexer, qi has lexer support
<gnikunj[m]>
ohhk
<K-ballo>
the lexer was a contribution from Ben something
<gnikunj[m]>
boost spirit is a magical piece of code that I'm loving right now.
<gnikunj[m]>
curious ques: why is char_ under boost::spirit::ascii but others (like int_, lit and lexeme) under boost::spirit::qi?
<K-ballo>
character encodings are a property of characters?
<gnikunj[m]>
sure but why not having under qi as well?
<gnikunj[m]>
like everything else seems to under qi
<K-ballo>
ascii_char, unicode_char, etc?
<gnikunj[m]>
yes
<K-ballo>
what's the advantage?
<gnikunj[m]>
apart from not needing to remember a different namespace, none
<K-ballo>
how is ascii::char_ harder to remember than ascii_char?
<gnikunj[m]>
it's not harder to remember. It gets easier to code when you know everything is in the same namespace
<K-ballo>
I don't see why that would be the case, but note character encodings are classes, not namespaces
<gnikunj[m]>
ohh. Didn't know that
<K-ballo>
I guess if one coded by looking only at what the current namespace offers, except nested namespaces, maybe...
<gnikunj[m]>
then it doesn't matter. I'll have to remember it that way.
<K-ballo>
there's really no alternative to having to remember it, one way or another
<gnikunj[m]>
true. I like it when a library has everything in the same namespace and have only utility functions in another namespace
<gnikunj[m]>
or implementation details in another namespace
<gnikunj[m]>
but I like it when user facing classes and functions are in same namespace
<gnikunj[m]>
also, boost::fusion is an amazing library. Didn't know one can create such powerful constructs!
<K-ballo>
you should have a look at boost.hana then
<K-ballo>
and the missing link, something in between
<gnikunj[m]>
what's boost.hana?
<K-ballo>
it was going to be kind of a modern redesign of fusion, but it went way past that
<gnikunj[m]>
ohh
<K-ballo>
it supports the use cases for fusion, and plenty other stuff too
<K-ballo>
initially it was going to be mpl for C++11, then it realized it could extend the mpl (pure types) cases to the fusion cases (type/value hybrids) by operating entirely in the value domain, and eventually it figured out that it wasn't really such a good idea after all
<gnikunj[m]>
haha. I'll certainly look into hana. It sounds really cool.
<K-ballo>
it's a good thing to use as a replacement for fusion, but not so much for mpl
<K-ballo>
mp11 is probably best for the mpl cases anyhow
<K-ballo>
on the other hand, hana has cute syntax
<gnikunj[m]>
I've been using boost.mpl, didn't know mp11 existed
<K-ballo>
why would you be using boost.mpl in the year 2011?
<gnikunj[m]>
I was using boost.mpl in 2019 lol when hkaiser gifted me the book on boost mpl
<K-ballo>
dave's book?
<gnikunj[m]>
if you mean David, yes
<K-ballo>
abrahams
<gnikunj[m]>
yes
<gnikunj[m]>
C++ Template Metaprogramming: Concepts, Tools, and Techniques from Boost and Beyond (C++ In-Depth Series)
<gnikunj[m]>
this one ^^
<K-ballo>
it's a great book on metaprogramming, yeah
<gnikunj[m]>
he gave another book by Andrei on Modern C++ design
<gnikunj[m]>
<K-ballo "it's a great book on metaprogram"> definitely!