00:46 <hkaiser> gnikunj[m]: I always said that the book was old and probably a bit outdated, but it's still the best resource to understand the inner workings of meta programming

00:46 <gnikunj[m]> hkaiser: and you are totally right. It's just that I slacked off and didn't know mp11 existed :D

00:47 <gnikunj[m]> the more I'm learning about boost libraries, the more interesting it's getting. Historically, I only knew of boost functions that hpx relied on. But there's a lot more to boost than that.

00:48 <hkaiser> gnikunj[m]: btw, the main problem I have with spirit v2 is that it doesn't support move semantics for the attributes (as it predates C++11)

00:48 <gnikunj[m]> does it create any issues?

00:49 <hkaiser> well, all attributes are copied when being propagated up through a parser hierarchy

01:01 <zao> Spirit X3 is fun, especially when the parser compiles but doesn't do what it should to your data.

01:01 <zao> (std::ref is always good, btw :D )

01:01 <gnikunj[m]> lol I wouldn't want that to happen with my code

01:01 <zao> Reminds me of trying to use Parsec in Haskell with those weirdo Applicative operators that silently just skipped some of the parse.

01:12 <K-ballo> a very limited subset of Qi/X3 is actually mostly fine, the non magical stuff at least

07:52 <LiliumAtratum> ms[m], to answer your question from yesterday - I have worker threads + an OS thread (for rendering) accessing the same registry to fetch data, but these need to be performed under a RW-lock. I use `hpx::this_thread::get_id()` for debugging purposes to understand who holds the current locks.

07:53 <ms[m]> LiliumAtratum: all right

07:53 <LiliumAtratum> Today I have a slightly different question - do I have a guarantee that each `hpx::async` (invoked without main pool executor) will spawn a new task with a unique `hpx::this_thread::get_id()`? Or should I use a different function for a task, and the `hpx::this_thread::get_id()` just gives me a worker thread id?

07:54 <LiliumAtratum> (I mean "... different function for a task ID")

07:55 <ms[m]> the id will be unique among the tasks that are currently "active" (i.e. created, suspended, running, etc.) but the id's are reused for future tasks once a task is done

07:55 <LiliumAtratum> ah, ok, that should be fine. Task that has ended should never keep any RW locks.

07:58 <ms[m]> just an idea for the previous problem, would `std::this_thread::get_id` be enough for you? typically locks (hpx or any other locks) shouldn't be held across task suspension so those ids would tell you something about different tasks taking a lock (but of course you won't be able to distinguish different tasks taking taking a lock on the same worker thread... which you're not guaranteed to be able to do with

07:58 <ms[m]> `hpx::this_thread::get_id` either because of the reuse of ids)

08:02 <LiliumAtratum> Taking the same lock twice on the same worker or taking no lock on the worker that tries to access the registry - that is something that should not happen. However, in debug mode I want to detect those scenarios and throw an appropriate std::logic_error exception. That is what I use the get_id for.

08:02 <LiliumAtratum> However, at the moment sometimes I get the said exception on a newly spawned hpx::async thread and trying to figure out the possible cause.

09:31 <mdiers[m]> I have a small problem during the termination of my program. I'm loading a shared lib with hpx dependencies at runtime, but I don't perform any hpx functionality. after unload i get a crash when exiting the program. the problem is because i didn't link my main executable against hpx, because i don't use it in that case. maybe someone recognizes the object and can tell me how to get it initialized? the stack is here:

09:31 <mdiers[m]> https://gist.github.com/m-diers/6772b79936b785d8e43527e66e3b553a

15:26 <gnikunj[m]> hkaiser: yt?

15:26 <hkaiser> gnikunj[m]: here (for 3 seconds)

15:26 <gnikunj[m]> Is there a documentation for parsing the utree?

15:27 <hkaiser> only (one of) the talks

15:27 <gnikunj[m]> utree seems like the way to go for generating AST, but I need to parse it to generate the code

15:27 <gnikunj[m]> what should I search?

15:27 <hkaiser> there is a cppnow/bostcon talk just about this

15:27 <gnikunj[m]> ohh cool

15:27 <gnikunj[m]> lemme look it up

15:27 <hkaiser> let me see if I can find the slides

16:06 <bita> hkaiser, would you please add me to the NAIRI mailing list? thanks

16:29 <bita> would you please also forward the email you sent to this mailing list earlier today to me?

17:21 <hkaiser> bita: the text is also in the meetin gnotes

17:27 <hkaiser> gnikunj[m]: it's the talk from BoostCon 2010: A Framework for RAD Spirit

17:28 <hkaiser> gnikunj[m]: here are the slides: http://boost-spirit.com/home/2010/05/11/a-framework-for-rad-spirit/

17:29 <hkaiser> I think it's the talk you already looked at

17:46 <gnikunj[m]> Yes

17:46 <gnikunj[m]> hkaiser lemme look

19:37 <gnikunj[m]> hkaiser: curious question: why does Phylanx not use utree?

19:38 <hkaiser> gnikunj[m]: what we use is very similar to utree, just specific to handling array of various dimensionalities

19:38 <gnikunj[m]> I didn't get you, could you elaborate?

19:49 <bita> thank you

19:49 <hkaiser> gnikunj[m]: utree was not directly usable

19:50 <gnikunj[m]> how so?

19:50 <hkaiser> we switched to a variant-based data structure to support all the data types we wanted to support

19:50 <gnikunj[m]> ohh so utree's variant didn't have all the data types. is that what you mean?

19:50 <hkaiser> was easier than to extend utree which is very much focussed on numbers

19:51 <hkaiser> yes

19:51 <gnikunj[m]> got it. From what I can see. Utree isn't hard to implement.

19:51 <hkaiser> sorry for bein gobtuse

19:51 <hkaiser> it is not - you're right

19:52 <hkaiser> gnikunj[m]: and frankly, I can't recall what made me not to go with utree ;-)

19:53 <gnikunj[m]> lol, that looks like a more appropriate response :D

19:54 <gnikunj[m]> this compiler stuff is actually very interesting. I'm wondering why I never looked into Phylanx :/

19:54 <hkaiser> we kept you busy with other things