Dear Rik and Mike, sorry for the delay in responding to this ticket.

The documentation change is useful and welcome, and I can confirm that I can reproduce Mike's steps on my machine at this point in time, running octave 6.4.0.

I am happy that this ticket is resolved to my satisfaction within the scope of the original submission and the example I provided.

But.

Having said that, the original issue that prompted me to open this ticket (see [1] in the original submission, namely: https://stackoverflow.com/questions/67334895/access-private-functions-from-private-functions-in-octave-bug) persists, and it is true in that particular instance the ignore_function_time_stamp function does not resolve the issue, even though a manual edit has been performed, and that the problem persists until a manual "clear functions" has been issued.

Presumably this means I misrepresented the original issue, for which I can only apologise, and that a bug affecting ignore_function_time_stamp still persists, which is unrelated to whether a return to the interactive prompt has taken place or not.

If you prefer, I'm happy for this issue to be closed and a new one opened representing the bug shown in the more elaborate example in [1].

Again, apologies for the trouble my unfortunate choice of example has caused.

Tasos, does the attached change to the ignore_function_time_stamp doc string resolve this for you?

(file #51415)

Regarding comment #7
I'm on Windows and cannot say it is reproducible unless someone test it on Windows.

So to resolve this bug, should there be a documentation update to make it clear that the command prompt needs to be shown for any out-of-date checks to be performed? Is there some other resolution worth pursuing?

A related bug is that "octave_user_function::is_system_fcn_file ()" from version 6 onward doesn't work any more. I attached a .oct function "is_system_function" for test.

Example usage :

is_system_function ("unique")

which returns 1 on Octave 5 but returns 0 on Octave 6.


(file #51393)

Also, note that the original Stack Overflow example was done on Windows.  Time stamps on that platform can be horrendously crude (for example, everything within 100 milliseconds is tagged with the same timestamp).  That lack of precision is not Octave's fault.  Running interactively helps mitigate this because each change to an m-file is done after the user copy and pastes the new code and then hits return.  This operation typically takes at least 1 second so there is no issue with the imprecise timestamps.

Hi Mike, thanks for the input!

Would you mind giving an example of what you mean?

The process I mention below (and also the one in the stackoverflow link) do not work as expected even when done manually with calls in the interpreter and edits done manually (i.e. not via fopen). If you edit the function files manually, the outcome is an error about C() being undefined,m as per the description in the stackoverflow link.

According to the octave manual[0] the command

ignore_function_time_stamp none

will cause octave to "always check time stamps on files to determine whether functions defined in function files need to recompiled".

The intent of this command, as I understand it, is to always check files for modifications, allowing one to modify a function file and use the updated definition within an ongoing session, without having to restart the session, and without having to run "clear functions" first.

However, the command seems to have no effect in practice.

Example (adapted from [1]):

ignore_function_time_stamp none
fA = fopen( 'A.m', 'w' ); fprintf( fA, "function A()\n  disp( 'Hello from A' )\n  B()\nend\n" ); fclose( fA );
mkdir private
fB = fopen( 'private/B.m', 'w' ); fprintf( fB, "function B()\n  disp( 'Hello from B' )\n%%  C()\nend\n" ); fclose( fB );
fC = fopen( 'C.m', 'w' ); fprintf( fC, "function C()\n  disp( 'Hello from C' )\nend\n" ); fclose( fC );

fprintf( "-- before activating C within B --\n" )
A()

fprintf( "-- after editing B and activating C within it --\n" )
fB = fopen( 'private/B.m', 'w' ); fprintf( fB, "function B()\n  disp( 'Hello from B' )\n  C()\nend\n" ); fclose( fB );
A()

fprintf( "-- after clearing manually --\n" )
clear functions
A()

When the above is run as a script, the second step doesn't show the call to C(), even though that instruction is now 'active' (i.e. uncommented) in the file. Futhermore, if the modifications aren't made via 'fopen', but manually in an editor, this results in an explicit error, as detailed in [1].

If my understanding is correct, the role of 'ignore_function_time_stamp none' is to explicitly always check if a function file has been modified and fetch the updated definition before running it, so the above behaviour is not the intended behaviour. (I have no problem with this behaviour from an optimisation point of view, but based on the documentation of that command, this is a bug).

[0] https://octave.org/doc/v6.2.0/Function-Files.html#index-ignore_005ffunction_005ftime_005fstamp
[1] https://stackoverflow.com/questions/67334895/access-private-functions-from-private-functions-in-octave-bug