On Wed, Feb 13, 2008 at 10:40:57AM +0100, Andrea Rossato wrote:
On Tue, Feb 12, 2008 at 05:37:11PM -0500, Adam Vogt wrote:
I guess that this place is the best to report this issue:
You just have to set your clock back a couple seconds (or more), and the time display doesn't update immediately. Going forward is fine.
I think that when you pass the time that is 'stuck' on xmobar, it sometimes starts updating again.
Not that this is much of a problem, I think that it is still a bug, the workaround being to restart xmobar.
It's always a problem when the system times is brought back (since that system is going to live twice the same moments - dovecot, my imap server, is going to exit). But the xmobar behaviour is unexpected.
I think this is a bug that is deeper than one may think at first, and it does not involve just the date plugin. Maybe something related to STM?
I don't know and I need to investigate.
Since there are another few bugs I need to take care of, I opened a bug tracker at code.google.com: http://code.google.com/p/xmobar/
I hope I'll be able to fix it rapidly.
Thanks for your report.
Andrea
This is an issue in GHC, I think. threadDelay must check the current system time, then the thread isn't run until system time reaches (initial time + wait time). Of course this might be a large amount of actual time if the system clock is turned back after threadDelay is executed. Cheers, Spencer Janssen