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 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 QDateTime::currentDateT
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 QDateTime::currentDateTimeUtc(). That avoids refreshing the timezone
> > database to convert
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 causes
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 yo
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 Fa
On Thursday, July 30, 2015 09:23:00 PM Mark Gaiser wrote:
> On Tue, Jul 28, 2015 at 4:28 PM, David Faure 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 w
On Tue, Jul 28, 2015 at 4:28 PM, David Faure 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 Reininghaus wr
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 Reininghaus wrote: ...
> >
> > It has. Querying the current time repeatedly
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
> >
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 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-devel&m=143533622526705&w=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 t
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 t
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 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 rid
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 k
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 changes, it
> > should post a task to these
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 changes, it should post a
> task to these threads-with-no-eventloop which says "sycoca has changed".
> I
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 somethi
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
> 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, 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 o
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
25 matches
Mail list logo
