[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Crash with inline
From: |
David Bateman |
Subject: |
Re: Crash with inline |
Date: |
Thu, 16 Sep 2004 22:12:08 +0200 |
User-agent: |
Mutt/1.4.1i |
Ok this patch made the function that was picked up change after a CD,
but WHICH still identifies the incorrect function, even after it is
reparsed (ie. used).
On another point what about the issue raised in
http://www.octave.org/mailing-lists/octave-maintainers/2004/701
for inline functions. Should octave be saving the curr_sym_tab, fbi_sym_tab,
loadpath as context for the function handles? Can I implement copy functions
for symbol_table, which would be needed for this? Or is there a reason why
such a copy function should be avoided?
Regards
David
According to John W. Eaton <address@hidden> (on 09/16/04):
> On 16-Sep-2004, I wrote:
>
> | I'd guess that CD is not doing anything special. Instead, WHICH
> | is probably looking up what symbol should be found, and instead of
> | assuming that a symbol in memory must be the correct one, is looking
> | at the load path. If we decide to fix this in Octave, then I think we
> | need to change the way symbol_out_of_data works. Instead of just
> | checking symbol timestamps, we need to see if the function found in
> | the path is different from the one found in the current symbol table.
>
> I think the following patch will make Octave work in a compatible way.
>
> | Then the which command may also need to be changed to check for out of
> | date symbols (probably instead of duplicating any code or logic, it
> | needs to use the same method of looking up a symbol that the
> | interpreter uses when attempting to evaluate a symbol).
>
> This part was already done.
>
> | Now, what to do about functions with the same name defined on the
> | command line? Should those always be favored over what is found in
> | the load path?
>
> Currently we will always favor the function defined on the command
> line. Doing something like
>
> octave:1> function foo () ... end
>
> and then
>
> which foo
>
> or
>
> cd some-directory-with-a-foo.m-file
> which foo
>
> will tell you that foo is a user defined function.
>
> BTW, it would be nice if in this case WHICH would till us that it has
> no corresponding file. Likewise, for built-in functions, it would be
> nice to have it say in what file it was originally defined.
>
> jwe
>
>
> 2004-09-16 John W. Eaton <address@hidden>
>
> * variables.cc (symbol_out_of_date): Always look in LOADPATH.
>
>
> Index: src/variables.cc
> ===================================================================
> RCS file: /usr/local/cvsroot/octave/src/variables.cc,v
> retrieving revision 1.260
> diff -u -r1.260 variables.cc
> --- a/src/variables.cc 11 Sep 2004 13:05:39 -0000 1.260
> +++ b/src/variables.cc 16 Sep 2004 18:41:17 -0000
> @@ -772,19 +772,28 @@
> {
> time_t tp = tmp->time_parsed ();
>
> - std::string fname;
> + std::string nm = tmp->name ();
>
> - if (tmp->is_dld_function ())
> - fname = ff;
> - else
> - fname = fcn_file_in_path (ff);
> + string_vector names (2);
>
> - tmp->mark_fcn_file_up_to_date (octave_time ());
> + names[0] = nm + ".oct";
> + names[1] = nm + ".m";
>
> - file_stat fs (fname);
> + std::string file = octave_env::make_absolute
> + (Vload_path_dir_path.find_first_of (names),
> + octave_env::getcwd ());
>
> - if (fs && fs.is_newer (tp))
> + if (file != ff)
> retval = true;
> + else
> + {
> + tmp->mark_fcn_file_up_to_date (octave_time ());
> +
> + file_stat fs (ff);
> +
> + if (fs && fs.is_newer (tp))
> + retval = true;
> + }
> }
> }
> }
--
David Bateman address@hidden
Motorola CRM +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax)
91193 Gif-Sur-Yvette FRANCE
The information contained in this communication has been classified as:
[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary
Re: Crash with inline, John W. Eaton, 2004/09/16
Re: Crash with inline, David Bateman, 2004/09/16