[Top][All Lists]

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

Function definitios not refreshed after modifing .M files

From: Canton Gonzalez, Daniel
Subject: Function definitios not refreshed after modifing .M files
Date: Wed, 9 Oct 2013 16:00:29 +0000

Dear all,


We are currently using Octave as a formula calculator engine which we invoke from Java applications using JavaOctave libraries ( We are experimenting following issue when working with custom Octave functions. If functions defined in .m files are modified after calling them using “eval” command, changes are not applied and subsequent invocations to function returns results corresponding to first version of .m file, not for the current one. This issue does not happen if we execute Octave process directly from Windows command line and modify same .m files.


We know Octave regularly checks .m files timestamps and when a newer file is detected its functions definitions are replaced with new ones. This is what is said about this mechanism at following URL


“When Octave defines a function from a function file, it saves the full name of the file it read and the time stamp on the file. If the time stamp on the file changes, Octave may reload the file. When Octave is running interactively, time stamp checking normally happens at most once each time Octave prints the prompt. Searching for new function definitions also occurs if the current working directory changes.”


Octave processes are started from JavaOctave using “--no-history --no-line-editing --silent --traditional” modifiers. We tried to remove or change some of these parameters like “no-line-editing” with no luck. Also we tried executing ignore_function_time_stamp(“none”) at octave startup with same result.


As a workaround we found that executing “rehash” function after editing .m files solves the issue but we would like to know if there is a less intrusive solution to avoid executing this command each time a function is altered.


Best regards and many thanks for your kind support,


Daniel Canton.

reply via email to

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