May 22 2020
We have read-only memory hole support and decrypt messages on sync for local search support.
Not really a problem in practice, and a solution would be search.
We're using flatpak
Also, support configuring starttls in the UI (necessary for some services).
May 5 2020
@mbohlender I've taken the liberty of adding you here. I appreciate you're pretty busy.
Apr 4 2020
Initial support for syntaxhighlighting based on sonnet is now available.
I'm closing this due to inactivity, feel free to reopen if it becomes relevant again.
Feb 22 2020
The reason was that we had a concurrent read-only transaction so we ended up accumulating a lot of free pages. Fixed in 0dc8aa249d063a3d6eaa248950c57ed5a1709524
Jan 13 2020
Dec 20 2019
Thanks that did the trick.
Dec 19 2019
OK, I have reverted the commit in master now. Sink tests pass again.
To be honest I think it makes most sense to revert back to default constructing T for the time being.
Dec 18 2019
There's no easy way how to fix this without reverting back to default-constructing T in Future<T>::Future().
It's not exactly the lifetime- it's a more deep-rooted issue with error handling.
Dec 17 2019
Generally, I'm wondering if I should deprecate this API and introduce a promise-future based API, where, instead of being passed a future from KAsync, the continuation would construct a Promise object internally a return a Future that KAsync would wait for....internally the continuation would own the Promise - it's closer to the common promise-future pattern and solves the lifetime issue, since the Promise is owned by the continuation, rather than by KAsync (which only holds the Future).
I can probably solve the life-time of the future, however you are still calling setError twice on it, which should be undefined behavior - or, following what std::future does, would, well, not throw (because Qt), but might as well assert.
Hmm, I believe the bug might be in the Sink code. Here specifically, it's ResourceControl::flush():
Dec 15 2019
tests/notificationtest in sink will produce a similar crash.
Dec 13 2019
I have rebuilt the flatpak completely and can reproduce the crash. Also, I can reproduce the crash outside of the flatpak again, not sure what I did above.
Dec 9 2019
Ever since I have rebuilt a with -fsanitize=address I can no longer reproduce outside of the flatpak, so there's a chance that the fault is with flatpaks internal build chaching that somehow results in something that crashes (I can't think of a reasonable scenario, but who knows).
I'll try to completely rebuild the flatpak as well and see if this fixes the issue.
Dec 6 2019
Nothing very obvious from the address sanitizer so far, but I also haven't managed to run kube with it yet (only sinksh).
I'll try that. Next week is fine, no hurry.
Looks like some memory issue...could you try compiling with -fsanitize=address? I won't get to look into it properly before some time next week, sorry.
Dec 4 2019
FWIW; I have attempted but failed to reproduce this in a kasync testcase. I can reproduce it by starting latest kube with latest sink and latest kasync, and I can reproduce the crash in both flatpak (which I have now reverted to kasync 0.3.0), and a locally built kube.
Dec 3 2019
Sep 1 2019
Aug 29 2019
Jun 27 2019
See the calendar for a model how this could be implemented.
Jun 26 2019
Jun 16 2019
Jun 8 2019
I managed to get rid of this crash with a patch to xapian (https://github.com/cmollekopf/xapian-core/commit/6061b69c4b2f6b9d310558df1b285b5125364de8) that I have yet to upstream (don't know if they'd accept it since it seems like a compiler bug).
May 20 2019
Apr 23 2019
Git branch visualizations were indeed a major inspiration =)
Where we'd put it exactly is indeed up for debate, I think it would in either case have to be in a location that remains available as you scroll down the conversation.