octave-maintainers
[Top][All Lists]
Advanced

[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



reply via email to

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