On Monday 14 September 2015 20:49:26 Thiago Macieira wrote:
> On Sunday 13 September 2015 23:04:01 David Faure wrote:
> > On Tuesday 14 July 2015 16:01:09 Thiago Macieira wrote:
> > > If you need a machine-comparable time with other systems or across
> > > reboots,
> > > use
On Saturday 14 November 2015 14:19:18 David Faure wrote:
> indeed.
> > > This code:
> > > qCDebug(SYCOCA) << "checking file timestamps";
> > > const QDateTime stamp = QDateTime::fromMSecsSinceEpoch(timestamp);
> >
> > You're using the function that creates a LocalTime timestamp and yet:
>
On Tuesday 14 July 2015 16:01:09 Thiago Macieira wrote:
>
> If you need a machine-comparable time with other systems or across reboots,
> use QDateTime::currentDateTimeUtc(). That avoids refreshing the timezone
> database to convert to local time.
>
> Only use QDateTime::currentDateTime() if
On Sonntag, 13. September 2015 23:04:01 CEST, David Faure wrote:
It's really a problem that QDateTime isn't threadsafe, it's
really unexpected for application programmers.
The particular conversion happens because /you/ followed Thiago's advise to use
UTC, but QFileInfo does not - what
On Thursday, July 30, 2015 09:23:00 PM Mark Gaiser wrote:
On Tue, Jul 28, 2015 at 4:28 PM, David Faure fa...@kde.org wrote:
On Tuesday 14 July 2015 19:28:58 Thomas Lübking wrote:
On Dienstag, 14. Juli 2015 19:00:14 CEST, Milian Wolff wrote:
On Tuesday, July 14, 2015 11:49:25 AM David
On Thursday 30 July 2015 21:23:00 Mark Gaiser wrote:
You can ignore this message if QMimeType::inherits internally calls the
method you optimized thus this function would be greatly improved already.
It does. Why not apply existing known fixes before profiling for more issues? :)
--
David
On Tue, Jul 28, 2015 at 4:28 PM, David Faure fa...@kde.org wrote:
On Tuesday 14 July 2015 19:28:58 Thomas Lübking wrote:
On Dienstag, 14. Juli 2015 19:00:14 CEST, Milian Wolff wrote:
On Tuesday, July 14, 2015 11:49:25 AM David Faure wrote:
On Friday 26 June 2015 18:03:00 Frank
On Friday 26 June 2015 18:03:00 Frank Reininghaus wrote:
https://bugs.kde.org/show_bug.cgi?id=346974
According to the backtrace, the process is busy inside
QMimeDataBase::mimeTypeForName(QString) doing time-related things and
accessing /etc/localtime all the time, probably because of the
On Monday 20 July 2015 16:05:06 David Faure wrote:
Or maybe QDateTime::currentDateTime() could avoid calling the awful tzset()?
Thiago, any input?
QDateTime::currentDateTimeUtc() does not call tzset.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect -
On Monday 20 July 2015 16:05:06 David Faure wrote:
On Friday 26 June 2015 18:03:00 Frank Reininghaus wrote:
https://bugs.kde.org/show_bug.cgi?id=346974
According to the backtrace, the process is busy inside
QMimeDataBase::mimeTypeForName(QString) doing time-related things and
accessing
On Friday 26 June 2015 18:03:00 Frank Reininghaus wrote:
checking the mtime frequently can have a bad effect on the performance
though if it's done incorrectly. There is a bug report about high CPU
usage in Dolphin if sort by type is used:
https://bugs.kde.org/show_bug.cgi?id=346974
On Tuesday, July 14, 2015 11:49:25 AM David Faure wrote:
On Friday 26 June 2015 18:03:00 Frank Reininghaus wrote:
checking the mtime frequently can have a bad effect on the performance
though if it's done incorrectly. There is a bug report about high CPU
usage in Dolphin if sort by type is
On Tuesday 14 July 2015 19:28:58 Thomas Lübking wrote:
Actually, checking currentTime() is already the problem here (causing the IO
for the timezone stuff), see
http://marc.info/?l=kde-core-develm=143533622526705w=1 (the 1st paragraph
part of my comment somehow turned into a second-level
On Dienstag, 14. Juli 2015 19:00:14 CEST, Milian Wolff wrote:
On Tuesday, July 14, 2015 11:49:25 AM David Faure wrote:
On Friday 26 June 2015 18:03:00 Frank Reininghaus wrote: ...
It has. Querying the current time repeatedly is quite costly,
and often shows
up in code that extensively uses
Hi,
2015-06-21 16:54 GMT+02:00 David Faure:
On Friday 19 June 2015 22:00:09 Vishesh Handa wrote:
On Sat, Jun 13, 2015 at 9:26 PM, David Faure wrote:
3 bis:
I assume the threads without an event loop have some way to get tasks,
right? So when the gui thread gets notified about ksycoca
On Freitag, 26. Juni 2015 18:03:00 CEST, Frank Reininghaus wrote:
Hi,
2015-06-21 16:54 GMT+02:00 David Faure:
On Friday 19 June 2015 22:00:09 Vishesh Handa wrote:
On Sat, Jun 13, 2015 at 9:26 PM, David Faure wrote: ...
I thought about it again, and there's a much simpler solution.
We get
On Friday 19 June 2015 22:00:09 Vishesh Handa wrote:
On Sat, Jun 13, 2015 at 9:26 PM, David Faure fa...@kde.org wrote:
3 bis:
I assume the threads without an event loop have some way to get tasks,
right? So when the gui thread gets notified about ksycoca changes, it
should post a task to
On Sat, Jun 13, 2015 at 9:26 PM, David Faure fa...@kde.org wrote:
3 bis:
I assume the threads without an event loop have some way to get tasks, right?
So when the gui thread gets notified about ksycoca changes, it should post a
task to these threads-with-no-eventloop which says sycoca has
On Saturday 13 June 2015 08:59:57 Ivan Čukić wrote:
7. the gui thread listens to dbus and sends a signal to the other threads?
It can not send signals since those are not loopy threads.
There is no need for a lot of locking if you put one instance of
KSycoca. You could do something like
7. the gui thread listens to dbus and sends a signal to the other threads?
It can not send signals since those are not loopy threads.
There is no need for a lot of locking if you put one instance of
KSycoca. You could do something like this (class names are not real :)
):
class MainThread {
On Saturday 13 June 2015 02:04:03 Vishesh Handa wrote:
3. The gui thread on receiving the dbus signal updates its db as well
as the database of all other threads. This is slightly complex and
would require locking code similar to (2) since the other threads
could be in the process of using
On Saturday, June 13, 2015 02:04:03 Vishesh Handa wrote:
[...]
3. The gui thread on receiving the dbus signal updates its db as well
as the database of all other threads. This is slightly complex and
would require locking code similar to (2) since the other threads
could be in the process of
Hey David
There is a bug in KRunner that new applications do not show up unless
KRunner is restarted. The problem is as follows -
* Every thread has its own KSysCoca instance
* Each KSysCoca interface listens for a dbus signal on when it should
update its db
* Without an event loop, dbus signals
23 matches
Mail list logo
