octave-maintainers
[Top][All Lists]
Advanced

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

Re: help as m-files


From: Søren Hauberg
Subject: Re: help as m-files
Date: Wed, 29 Oct 2008 22:16:35 +0100

ons, 29 10 2008 kl. 14:30 -0400, skrev John W. Eaton:
> OK, I'm generally in favor of this change as I'd like to see more
> things implemented in .m files if possible.
> 
> Is lookfor faster only because of the switch to using a cache?  If
> there is no cache, is it still slow?

I think it's comparable to the current implementation, when there is no
cache. The slow part of lookfor is that we have to call makeinfo for
every single function. The fact that this happens in an interpreted
for-loop instead of a compiled one doesn't make much of a difference.

So, the speedup is definitely due to the use of caches. 

> Could we just check to ensure that the cache is up to date when adding
> directories to the load path?  I'm assuming you could do this by
> comparing the mtime of the cache file with the mtimes of .m files in the
> directory.  I think we already call stat on every file in each load
> path directory when we add the directory to the load path, so this
> additional check should not add much to Octave's startup time.

What would you do if the cache is out of date? Delete the cache?
Recompute it? I imagine that caches should only be used with the
functions that come with Octave (and hence shouldn't change), and
functions installed with the package manager (and hence shouldn't
change). It should be said, that my implementation of 'lookfor'
essentially works like this

  for_each_dir_in_path:
    if (dir_has_cache)
      search_cache ()
    else
      search_file_by_file ()

So, things work just fine if some directories are cached, while others
are not.

> Then later, when running lookfor, would you also want to ensure that the
> cache files are up to date, or would you just assume that they are?
> It seems it would be best to check timestamps, but that could slow
> things down again

I think we should just assume caches are up to date. If we only cache
files that are distributed with Octave, and files that are installed
with the package manager, then I think it's fair to assume that these
caches are up to date. Really, if people change these functions, then I
doubt that it'll be the help text they're changing. The rest of the
users functions can just be searched file by file. And if the user
wants, then (s)he can just generate a cache manually.

> | I also have the following on my outstanding-issues-list:
> | 
> |   * Perhaps move internal variables (eg 'makeinfo_program') to m-files?
> 
> Yes, I think that would be good to do.

Okay, I'll make that change then. I was unsure because some of these
internal variables seems to be changeable through command line options
to Octave at startup (e.g. octave --info-file). Is that functionality we
can just drop?

> |   * how should 'private' directories be treated in Makefiles ?
> 
> I'm not sure, but we do need to do something for this since there are
> other places where we could use private functions.

What I did was just to add 'private/myprivatefile.m' to the SRC list
along with 'myfile.m'. I think that works, but perhaps it's a bit ugly?

> |   * Fix XXX's in code (nothing major).
> 
> Please use FIXME instead of XXX as people have complained in the past
> about patches/mail with XXX being flagged as spam.

Really? Perhaps it's a feature to flag my code as spam ;-)

Søren



reply via email to

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