RE: m file cache

[Billings, Paul]

Updating the cache in the dead time after prompt is printed (while user is
typing, etc.) avoids any delay after the user hits <enter>.

If this delay is negligible (as you indicated it probably is), there is no
compelling reason for the above approach.

It sure would be nice if a program could register with the OS as an observer
(of specific files/dirs) and get notified on file system changes.  Seems
like this comes up enough that it would have been included by now.  But that
would probably make too much sense. ;-)

Paul


> -----Original Message-----
> From: John W. Eaton [mailto:address@hidden
> Sent: Thursday, May 25, 2006 10:53 PM
> To: Paul Billings
> Cc: address@hidden
> Subject: RE: m file cache
>
>
> On 25-May-2006, Paul Billings wrote:
>
> | 1) I especially like the ability to list shadowed functions.
>
> I'm not doing anything with that yet, but the new data structure makes
> it easy to do.
>
> | 2) You mentioned checking timestamps "once per prompt": hopefully that's
> | just after the <enter> is pressed rather than just before or after the
> | prompt appears.  I can see arguments for both, but the latter could be
> | confusing.
>
> OK, that's a good point that I missed.  I now have the cache update
> happening just after the command editing function returns an input
> line.  That way, files added while Octave is waiting for input will be
> found before the next command is executed.  What is the argument for
> updating the cache before the prompt is printed?
>
> I think the revised load-path code will be ready for some testing in a
> day or so.  If it looks like it works, then I'll probably make a new
> snapshot sometime in the next week or two.
>
> jwe