bugGNU Octave - Bugs: bug #65548, Every time a new function is...


bug #65548: Every time a new function is created in a separate m-file, an 'undefined' error message is displayed

Submitter:  Roozbeh <rgrayeli>
Submitted:  Tue 02 Apr 2024 02:45:02 PM UTC
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  Fixed Assigned to:  None
Originator Name:  Roozbeh Open/Closed:  * Closed
Release:  * 9.1.0 Operating System:  * Any
Fixed Release:  9.2.0 (current stable) Planned Release:  9.2.0 (current stable)
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Thu 02 May 2024 09:40:04 PM UTC, comment #11: 

Marking as Fixed and closing report.

Rik <rik5>
Group administrator
Mon 15 Apr 2024 02:40:41 PM UTC, comment #10: 

No more comments in the past week.
So, I went ahead, added a comment and FIXME note next to the new line, and pushed the change to the stable branch (it fixes a regression since Octave 8):

Marking as ready for test.

Markus Mützel <mmuetzel>
Group administrator
Mon 08 Apr 2024 12:48:22 PM UTC, comment #9: 

Thinking about it a bit longer: Although rehashing the load path is an expensive operation that should be avoided if possible, it probably takes much less than 100 ms on most systems. (`tic, rehash(); toc` takes about 18 ms on my system. And that includes some time for the function call overhead.)

Starting a script from the editor (either with F5 or by clicking on one of the buttons or menu options), requires a human interaction. Adding a few milliseconds to the response time might not actually be critical.
(It would be more critical if this added time to calling things from a script or function.)

What do you think?

Markus Mützel <mmuetzel>
Group administrator
Wed 03 Apr 2024 08:55:41 PM UTC, comment #8: 

> I'm not sure this is the correct place for that though. Rehashing the load_path on each F5 seems wasteful. Do we know whether the file is new at that point? Should we maybe trigger a load_path rehash when a new file is saved, not when F5-ing it?

I agree that this is a performance hit we don't need every time a file is executed (F5).  I seem to recall that this very point has been discussed---that it would be good to rehash or otherwise add a new file to the load path---but I can't remember where it might have been.  It could have even been back on the mailing-list.

Rik <rik5>
Group administrator
Wed 03 Apr 2024 08:07:17 PM UTC, comment #7: 

I appreciate all of your responses.

I wanted to make it clear that the issue appeared when I attempted to manually create a new m-file (not programmatically). I should have mentioned this earlier.

The question is: what was altered between this version and the previous release (8.4.0) that resulted in the appearance of this issue? given that I was not experiencing this issue before upgrading to version 9.1.0.

Thank you again.


Roozbeh <rgrayeli>
Wed 03 Apr 2024 07:47:43 PM UTC, comment #6: 

The following change makes F5 work for a new file for me:

diff -r 91f7c8246a98 libgui/src/main-window.cc
--- a/libgui/src/main-window.cc        Sun Mar 31 15:57:02 2024 +0200
+++ b/libgui/src/main-window.cc        Wed Apr 03 21:32:56 2024 +0200
@@ -1166,6 +1166,7 @@
            // debug.

            load_path& lp = interp.get_load_path ();
+           lp.rehash ();

            std::string path = info.absolutePath ().toStdString ();

I'm not sure this is the correct place for that though. Rehashing the load_path on each F5 seems wasteful. Do we know whether the file is new at that point? Should we maybe trigger a load_path rehash when a new file is saved, not when F5-ing it?
On the other hand, rehashing the load path immediately after a file is saved might lead to problems on slow file systems (where the file might only be available after a short time later).

Anyway, this turns out to be a different issue than the one described in comment #0.
Regarding that issue, I think we have a BIST for it (i.e., creating .m files in a script and executing them in the same script):

That BIST contains a `pause (1)` and `rehash ()`. ISTR that the test occasionally still fails in CI (maybe when disc load is high?).
Does some combination of that work for the OP?

Markus Mützel <mmuetzel>
Group administrator
Wed 03 Apr 2024 05:38:47 PM UTC, comment #5: 

Thanks for the pointer.

I don't see immediately what could be wrong with that. But everything load_path seems to be able to surprise me in one way or the other...

Found another way to work around the issue: Set a breakpoint in some line of the script (e.g., by clicking at that line in the left side bar) after it was saved but before executing it the first time with F5. In this case, the script starts executing and stops at the breakpoint as expected. It continues to be found on the load path also after the breakpoint is removed.

Is there a pattern? What happens to the load path when a function is executed from the command window and a break point is added to a new function (but not otherwise?)?

Markus Mützel <mmuetzel>
Group administrator
Wed 03 Apr 2024 05:16:36 PM UTC, comment #4: 

F5 finally leads to the function main_window::run_file_in_terminal


where an interpreter thread is actually calling the desired file.

Torsten Lilge <ttl>
Group Member
Wed 03 Apr 2024 11:01:33 AM UTC, comment #3: 

I don't know if it is related to comment #0. But I can confirm the behavior described in comment #2.
However, that only seems to happen when using F5 to run the newly created script immediately after it has been saved.
If I create and save a new script and then run it immediately afterwards by writing its name at the command prompt, it is working. After that, it also executes with F5 in the built-in editor.

`path(path())` seems to get the file to execute even after it failed to run with F5. `rehash()` doesn't help.

I don't know what actually happens when running a script from the editor with F5...

Markus Mützel <mmuetzel>
Group administrator
Wed 03 Apr 2024 09:48:49 AM UTC, comment #2: 

Perhaps a complement because I experienced the same behavior, not only for new functions but also for new m-files.

And the problem concerns MANUALLY (not programmatically) created new m-files.

The way to reproduce this:

In the Editor:
Menu : File -> New Script
Type fore example : disp('Ok')
Menu : File -> Save ...

The following error appears

error: 'test_new_file_0' undefined near line 1, column 1

None of the following things help :
- rehash()
- closing and reopening the file
- continue editing, resaving
- saving as ...
- waiting an eternity (20 minutes)

As said by Roozbeh the only way to solve this is to restart Octave.

Charles Praplan <charprap>
Wed 03 Apr 2024 07:24:21 AM UTC, comment #1: 

IIRC, Octave checks the last-modified time-stamp of folders in the load path when some conditions occur (e.g., the command prompt is displayed or the user changes the current directory). If this time-stamp updated since the last check, the containing files are rehashed.

It might be that none of those triggering conditions are reached when you programmatically create new m-files and try to execute them immediately.
It might also be that one of those triggering conditions is reached. But the last-modified time-stamp didn't update yet. (Windows is known to have a poor time-stamp resolution. It's also known that it doesn't correctly update time-stamps at all, e.g., on some shared file systems.)

It is hard to guess what is causing the particular issue that you are seeing as long as you don't provide any code that reproduces the issue for you. Could you please upload a minimum example that reproduces the issue?

Alternatively to relying on one of the "automatic triggers" for re-hashing the load path, you could try to manually trigger a rehash by calling the function `rehash()` after you created the new .m files.
Depending on the speed of file operations on your system, you might need to wait a bit after the file creation for it to be actually visible (e.g., using pause). (The latter might explain why you are seeing the issue in some versions of Octave but not in others: Maybe, some timings have changed?)

Markus Mützel <mmuetzel>
Group administrator
Tue 02 Apr 2024 02:45:02 PM UTC, original submission:  


Every time I try to call a newly created function that I've created in a separate m-file from the main script, I receive an undefined error message stating that the function doesn't exist. To fix the problem, I have to exit the program and open it again.

This problem is limited to the most recent version, 9.1.0. never experienced an issue before.


Roozbeh <rgrayeli>


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

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by charprap (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by rgrayeli (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.


    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-05-15 philipnienhuis Open/ClosedOpen Closed
    2024-05-02 rik5 StatusReady For Test Fixed
        Fixed ReleaseNone 9.2.0 (current stable)
    2024-04-15 mmuetzel StatusNeed Info Ready For Test
        Operating SystemMicrosoft Windows Any
        Planned ReleaseNone 9.2.0 (current stable)
    2024-04-03 mmuetzel StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code