Le mardi 20 octobre 2009 à 18:07 -0400, John W. Eaton a écrit :
> The symbol table code already includes the following:
>
> octave_value
> symbol_table::fcn_info::fcn_info_rep::find (const octave_value_list& args,
> bool local_funcs)
> {
> octave_value retval = xfind (args, local_funcs);
>
> if (! retval.is_defined ())
> {
> // It is possible that the user created a file on the fly since
> // the last prompt or chdir, so try updating the load path and
> // searching again.
>
> load_path::update ();
>
> retval = xfind (args, local_funcs);
> }
>
> return retval;
> }
>
> So if this is not sufficient, why not? Is it because update always
> checks the time stamp? In that case, maybe we need to have a "force"
> parameter to tell load_path::update to ignore the time stamp? That
> would make this update operation slow, but it would only happen when a
> symbol is not found the first time around, so I wouldn't expect it to
> be a big problem.
This solution sounds good to me. It should fix the problem I encounter
with Dynare.
Also note that this granularity problem doesn't occur with Octave 3.0.
Something must have changed between the two releases, but I don't know
what since I haven't gone through Octave 3.0 source code.
Thanks,
--
Sébastien Villemot
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
