- User Since
- Mar 5 2015, 12:44 PM (150 w, 3 d)
"autotests" and unittests are the same thing. The files are in the right place.
Fri, Jan 19
and now it compiles
What is slow in my experience is feeding a KDW instance.
Pushed in https://commits.kde.org/kcompletion/31f226116f99bcf40ddc67fe6328594d5fb46222, thanks for the contribution! Keep 'em coming ;-)
Note: if someone wants to use XDG_RUNTIME_DIR with Qt, use QStandardPaths::RuntimeLocation (which includes the proper security checks for that directory, and fallbacks).
Thu, Jan 18
This patch fixes a O(n) performance issue in the inotify backend using a cache, which makes KDirWatch *better* suited for applications that use KDirWatch heavily. Clearly a step in the right direction. Yes a cache needs memory, like all caches, how else is one going to optimize linear searches [in unsorted data]...
The more I dig into this, the more I think all of my previous commits on the topic of timezones might be wrong.
This whole idea of using UTC everywhere comes from 9e65b991 / https://phabricator.kde.org/D876 which doesn't really tell me much about the reasoning.
Wed, Jan 17
Tue, Jan 16
mention Gammaray too
Mon, Jan 15
Done, kwidgetaddons-5.42.1 is out: https://download.kde.org/stable/frameworks/5.42/
I'm 100% sure the same rules applies, because the "limitations" of operator come from C++ and therefore apply to all associative containers.
Oh, right. I see. Still very strange that QTRY_COMPARE_WITH_TIMEOUT behaves differently (if more signals are coming in than expected, the current (old) code could have caught them too, during the 50ms. Actually that might explain some of the flakiness I sometimes saw....
"The third one touches all files in the tree and measure how long it
takes until all dirty signals arrive. If you subtract that measurement
from the third benchmark"
Sun, Jan 14
This goes against the whole redesign of ksycoca that I did some time ago. It's supposed to check timestamps on dirs, to rebuild the cache on demand, much like many other caches out there. Did you run the unittests in kservice after this change? I strongly doubt they pass.
Sat, Jan 13
Fri, Jan 12
Thanks for the fix. Looking at the reasoning in 737a983feb the added emit is definitely wrong, as the unittest proves. Please push.
I certainly hope QListView doesn't trigger a nested event loop, that would be horribly nasty and the cause for a million more problems.... (up to and including crashes when closing the view/window while this is happening). But I'm assuming this is just a supposition, and I'm strongly hoping it's unfounded ;-)
Nice investigation and fix! Do you happen to know the actual change in Qt which broke this? Wondering if it should 1) be mentioned in the commit log, 2) lead to an #if QT_VERSION.
But if it's just a supposition, then that's fine, don't spend a week tracking down the change in Qt :-)
Thu, Jan 11
Sorry to be a pain, but can you also update the description, which still talks about textEmitted()?
Wed, Jan 10
Doesn't execWithElevatedPrivilege call ERR_USER_CANCELED on cancel?
That was the idea, at least.
Please keep in mind that we should remove one of the two flags before the end of the month, after people tested this as much as possible ;)
The proper way to push the fix is arc land...
https://phabricator.kde.org/D9807 (to be applied after reverting this commit)
I don't either ;)
Tue, Jan 9
Wrong tooling :-)
Mon, Jan 8
As a KDE sysadmin ticket; the sysadmins want to centralize KDE's issues with Phabricator before reporting them upstream (to present a unified front and avoid duplicates).
Sun, Jan 7
The rest looks good.
Fri, Jan 5
Thu, Jan 4
Just missing a 'e' in "execution" in the commit log ;)
Tue, Jan 2
Let's discard this one and proceed with https://phabricator.kde.org/D9480 instead.