octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #60122] Save and Run in editor does not always


From: Rik
Subject: [Octave-bug-tracker] [bug #60122] Save and Run in editor does not always save
Date: Fri, 12 Mar 2021 18:03:35 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.66 Safari/537.36

Follow-up Comment #5, bug #60122 (project octave):

This could be a problem specifically with Windows and, possibly, specifically
with networked drives.

When you first run an m-file, Octave parses it and stores an internal
representation of the code.  It also records the last modification time of the
file.

Now, when you go to run a function a second time Octave first looks into it's
cache of parsed code to see if the function exists.  If it does, it then looks
at the timestamp of the m-file and compares it to the recorded timestamp.  If
they are the same, nothing has changed and Octave can go ahead and use the
cached code.  Otherwise, it has to go out to the disk, parse the new code, and
build the internal representation which it then runs.

There are two issues with your current setup.  First, some Windows file
systems (for example, VFAT) store timestamps with only 2-second resolution
(see
https://unix.stackexchange.com/questions/470856/timestamps-of-files-copied-to-usb-drive).
 So if you save a file, make a quick change, and then save again Octave may
not even notice that a change has been made.  If you can, you might check if
you can use NTFS as a file system since it has 100 nanosecond resolution.

Second, if the drive is networked there is going to be some time between
issuing a save command and when the timestamp on the disk is actually
modified.  It could be that Octave issues a save command to the operating
system, which returns quickly because it has sent the command off on the
network.  Octave then goes to run the script which begins by checking the
timestamp.  Maybe the operating system returns the old timestamp before the
write command is executed.  This seems perfectly plausible because once you go
on to an IP network order of packets is not guaranteed.

There is a way that we could address this on our side.  The sequence of
commands is

1. Save
2. Run

Since the expectation, intention is that the programmer must have made a
change and that is why the Save operation is required, it should be okay to
invalidate Octave's local cache and force the file to be re-parsed.  In this
case, the command sequence would be

1. 'clear -f FUNCTION_NAME'
2. Save
3. Run

It's not perfect if the m-file has nested function or subfunctions, since
those should be cleared as well.  But maybe this is a step in the right
direction.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60122>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]