| 30 May 2018 |
 Github [@aberchek:matrix.org] (deprecated) | [ajberchek/matrix-olm-cpp] ajberchek synchronize pull request #6: Add Travis files and clang-format options [open] - https://github.com/ajberchek/matrix-olm-cpp/pull/6 | 02:28:53 |
| Github [@aberchek:matrix.org] (deprecated) | [ajberchek/matrix-olm-cpp] ajberchek pushed to anoa/travis_setup: This will need to be squashed - https://github.com/ajberchek/matrix-olm-cpp/commit/0ed43cf50fdfcd734dddc00528669f853d668f10 | 04:01:26 |
| Github [@aberchek:matrix.org] (deprecated) | [ajberchek/matrix-olm-cpp] ajberchek synchronize pull request #6: Add Travis files and clang-format options [open] - https://github.com/ajberchek/matrix-olm-cpp/pull/6 | 04:01:27 |
| Github [@aberchek:matrix.org] (deprecated) | [ajberchek/matrix-olm-cpp] ajberchek pushed to anoa/travis_setup: Attempt to fix clang compiler issues from lack of optional - https://github.com/ajberchek/matrix-olm-cpp/commit/506b03a2f616f40b63f4a60bada44e1ecd4df611 | 04:25:09 |
| Github [@aberchek:matrix.org] (deprecated) | [ajberchek/matrix-olm-cpp] ajberchek synchronize pull request #6: Add Travis files and clang-format options [open] - https://github.com/ajberchek/matrix-olm-cpp/pull/6 | 04:25:09 |
 @kitsune:matrix.org | I didn't know Travis knows about xenial and even zesty these days. | 05:04:01 |
 ajberchek | It's all really new to me, pretty cool it has so much support though! | 05:53:13 |
| ajberchek | I was browsing through the docs, and saw "android" for a second I thought there was an android target, and got excited at the thought of testing this with the NDK, but then I realized it was referring to the language hahaha | 05:54:43 |
| 2 Jun 2018 |
| Github [@aberchek:matrix.org] (deprecated) | [ajberchek/matrix-olm-cpp] ajberchek pushed 6 commits to dev: https://github.com/ajberchek/matrix-olm-cpp/commit/2201e144aa2a7d9b93a01fdef5cfa15554de7b20
anoadragon453: Add Travis files and clang-format options
anoadragon453: We should probably run the script that runs stuff
anoadragon453: permission access for travis
ajberchek: Temporarily remove format check
ajberchek: Merge branch 'anoa/travis_setup' of https://github.com/ajberchek/matrix-olm-cpp into dev
ajberchek: Migrated callbacks to future in order to allow for proper exception handling | 06:44:05 |
| ajberchek | The API has been migrated to require clients provide functions which return futures rather than accept a callback to improve exception handling potential. The only downside I've found so far is such functions cant return references since the variables could go out of scope and be deallocated on the thread owning the reference, so returns are by value which could cause a slowdown | 06:47:56 |
| ajberchek | The other option, I suppose, is to require a reference be passed to these functions from the callers that will stay in scope when the function executes | 06:49:20 |
| @kitsune:matrix.org | ajberchek: futures, as in future<>? | 07:50:14 |
| @kitsune:matrix.org | (std::future<>, to be even more specific) | 07:50:30 |
 anoa | Looking at the code, yes. | 09:48:09 |
| * @kitsune:matrix.org thinks how much it is possible to wrap the event/signal-slot system of Qt into std::future | 09:50:51 |
| * anoa shudders | 09:52:38 |
| anoa | Surely you could use futures yourself though? Unless Qt's C++ is wildly different. | 09:53:50 |
| @kitsune:matrix.org | Well, I think I could do some std::packaged_task<> and execute it synchronously... The thing is that with Qt you effectively have single-threaded concurrency, so producing a future via std::async is not really an option. I didn't use standard library's concurrency in that way, not sure how much it allows that. | 10:02:47 |
| anoa | Wonder if it's possible/horrible to provide both a future and a callback as an optional parameter. | 10:04:58 |
| @kitsune:matrix.org | Smells like Perl, with its "everything can be done in more than one way" :) | 10:07:42 |
| * @kitsune:matrix.org still would prefer futures | 10:08:21 |
| @kitsune:matrix.org | How to marry them with a single-threaded model is another question | 10:08:54 |
| anoa | Let us know if it's not possible/a hassle to use them with Qt, as that'll probably be what the majority of clients use. | 10:09:03 |
| ajberchek | oh no! I didnt know about that, oops. The only reason they are there is to provide the opportunity for these functions to be concurrent while also handling exceptions the API user may not have dealt with. It can be migrated to assume a non-concurrent model, so that function calls execute synchronously, then anyone wanting to use this code asynchronously can simply call async themselves. It would be much easier for an API user to add an async wrapper than to remove it, so I can change the code to reflect that | 17:16:33 |
| ajberchek | Key replenishment runs on a separate thread so it can occur in the background every 10 (whatever the spec says) minutes. Would that cause any issues with your model? I'd rather it run this way so the API user doesn't need to think about running key replenishment, though I'd be open to suggestions for changing this if it will be an issue :) | 17:18:29 |
| @kitsune:matrix.org | As long as you give and take control flow within the same thread, things will be fine for me. If you do it in different threads, well, I'll have to switch to the right thread on my side. In Qt there's one solid invariant: GUI thread is only one. Everything else can be switched around. So I wouldn't be too much concerned given that you're doing pretty much backend things. But if you expect me to call your function with data from user input or confirmation, I'll do it in the main thread context. Or, e.g., if you call my user interfacing function in std::async I'll have to immediately switch the context to another (GUI) thread, locking this one until the result is given. | 23:42:24 |
| @kitsune:matrix.org | So in fact it's rather about threading hygiene between the client and matrix-olm-wrapper than about some limitations of Qt | 23:43:57 |
| 3 Jun 2018 |
| ajberchek | Okay, that should be doable. The only interaction between the API and qt (rather than the API and the client) is when the API calls the client provided notification function to notify a user of an unverified key. I'll avoid calling async with that, though it will be coming from a thread with the context of whatever called the function to decrypt and verify a message | 01:47:44 |
| @kitsune:matrix.org | ajberchek: Thanks! Yes, that kind of things I was talking about. | 02:28:48 |
| ajberchek | Sweet! :D | 02:49:39 |
