bugGNU Octave - Bugs: bug #55437, Files in editor are reported as...


bug #55437: Files in editor are reported as modified while heavily parsing date strings with datenum()

Submitted by:  Lars Kindermann <larskindermann>
Submitted on:  Thu 10 Jan 2019 11:06:39 AM UTC  
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Need Info Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  GNU/Linux

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Thu 24 Jan 2019 07:39:03 PM UTC, comment #7: 

Ah, there's a test failure in "test datevec". My patch breaks the millisecond-handling hack.

I'll look in to it. Sorry for not testing first.

Andrew Janke <apjanke>
Thu 24 Jan 2019 07:29:47 PM UTC, comment #6: 

Andrews patch fixed the popup messages and timstamp changes in the file browser, as expected when removing the TZ changes.

But I am not sure wether just handing GMT0 over to strptime really solves all conversion problems. Did you try all the tests and assertions in datevec.m?

An what happens if the PC clock itself is in the daylight saving period, when the clock is just turned back? We have to make sure everything is always correct.    

Lars Kindermann <larskindermann>
Mon 21 Jan 2019 12:41:02 AM UTC, comment #5: 

Here's a patch to try out the "munge with explicit time zone" approach: file #46052:  datevec-munge-strings-instead-of-TZ-env-var.patch. Lars, want to try this out?

Negligible effect on parsing speed. Before:

>> bench_datenum
Parsed 5000 dates in 0.972425938 s, 194 usec per date
>> bench_datenum (50000)
Parsed 50000 dates in 9.472014904 s, 189 usec per date


>> bench_datenum
Parsed 5000 dates in 0.983253002 s, 197 usec per date
>> bench_datenum (50000)
Parsed 50000 dates in 9.850703001 s, 197 usec per date

There was one test it broke when I tried it out. But that was for `eigs`, which doesn't even use dates as far as I can tell. I suspect that was just  an existing intermittent failure cropping up.

Andrew Janke <apjanke>
Sat 12 Jan 2019 11:48:17 AM UTC, comment #4: 

@Andrew: See comment 23 at bug #53539 for an answer

Lars Kindermann <larskindermann>
Sat 12 Jan 2019 04:46:47 AM UTC, comment #3: 

Makes sense that the temporary TZ change would cause this. I can't reproduce on macOS, but I think that's because macOS does its file change notifications differently, subscribing to a system service that pushes filesystem change notification events.

Maybe there's a way to do the "zone-independent" date parsing locally instead of fiddling with the global TZ environment variable: Check the date format string, and if it doesn't include an explicit `%z` or `%Z`, then concatenate ' %Z' to the format string and ' GMT' to the input date strings, so the strptime() parsing logic doesn't have to refer to TZ at all.

Andrew Janke <apjanke>
Fri 11 Jan 2019 03:52:10 PM UTC, comment #2: 

Ubuntu 16.04, Core i5, 4Gig RAM, Ext4 on HD
Just 5 open files in the current folder
While the script is running, I get up to three warnings popping up

Additionally, I see the dates in the file-browser erratically changing while the script is running.

In bug #53539 this was caused by changing the timezone temporarily within datenum() and the gui asynchronically checking filedates at the same time.

Lars Kindermann <larskindermann>
Fri 11 Jan 2019 02:56:05 PM UTC, comment #1: 

I modified your script to generate N open m-files easily.

N = 100;
list = dir ('/path/to/repo/scripts/*/*.m');
list = strcat({list.folder}', filesep (), {list.name}');
cellfun (@edit, list(1:N))

disp preparing
for i=1:100000
disp starting
disp done

But I cannot reproduce the problem on openSUSE 15.0, Intel Core i5, 16 GB RAM.

>> __octave_config_info__ ("hg_id")
ans = 02a9e1bb314a

You speak of slow systems, what does this mean for you?  Do you store the files on some special location?  The opened files are stored on a XFS partition.

Kai Torben Ohlhus <siko1056>
Project Member
Thu 10 Jan 2019 11:06:39 AM UTC, original submission:  

Reappearing behaviour of bug #53539, which was fixed a year ago.

How to trigger: Open some files in the editor (the more the better), including this script

disp preparing
for i=1:100000
disp starting
disp done

Running this script, during datenum() the GUI sometimes pops up a message box, stating that some file opened in editor has changed.

It happens more frequently on a slower CPU.

Lars Kindermann <larskindermann>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by apjanke (Posted a comment)
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by larskindermann (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-02-26 mtmiller Release5.0.1 => dev
    2019-01-21 apjanke Attached File- => Added datevec-munge-strings-instead-of-TZ-env-var.patch, #46052
    2019-01-11 siko1056 StatusNone => Need Info

    Back to the top

    Powered by Savane 3.6