On Tue, Oct 20, 2009 at 10:00:52PM +0200, Jaroslav Hajek wrote:
2009/10/20 Thomas Weber thomas.weber.m...@gmail.com:
Hi,
On Thu, Oct 15, 2009 at 02:09:30PM +, Sébastien Villemot wrote:
Hi,
I think I found the culprit for what I thought was a race condition in
Octave.
The
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)
{
On 20-Oct-2009, Judd Storrs wrote:
| If we're already keeping track of when we last read a
| directory/file,
No, we were keeping track of the timestamp on the directory, and then
re-reading the list of files if the timestamp changed. But that fails
for a sequence like
system (echo 1+1
I'm still looking to see if there's a generic way to determine the
file-system time resolution. I have seen stated multiple places that
FAT/FAT32 is limited to a time resolution of 2 seconds. For example
http://docs.python.org/library/os.html#os.stat says:
Note
The exact meaning and resolution
Hi,
On Thu, Oct 15, 2009 at 02:09:30PM +, Sébastien Villemot wrote:
Hi,
I think I found the culprit for what I thought was a race condition in
Octave.
The problem has to do with the way Octave 3.2 updates its load-path: it
only updates its cache of the current directory if the
2009/10/20 Thomas Weber thomas.weber.m...@gmail.com:
Hi,
On Thu, Oct 15, 2009 at 02:09:30PM +, Sébastien Villemot wrote:
Hi,
I think I found the culprit for what I thought was a race condition in
Octave.
The problem has to do with the way Octave 3.2 updates its load-path: it
only
tir, 20 10 2009 kl. 22:00 +0200, skrev Jaroslav Hajek:
The problem is in load_path::update, which checks the directory's
modification time to decide on whether to rescan it. The resolution is
only in seconds, though. But some check is surely wanted because you
want to avoid useless rescans. I
On 20-Oct-2009, Søren Hauberg wrote:
| tir, 20 10 2009 kl. 22:00 +0200, skrev Jaroslav Hajek:
| The problem is in load_path::update, which checks the directory's
| modification time to decide on whether to rescan it. The resolution is
| only in seconds, though.
It is possible to get better
If we're already keeping track of when we last read a directory/file,
wouldn't it be easiest to make the comparison know about the tolerance? i.e.
use something equivalent to
if modtime + tolerance cachetime
reparse
endif
Then when the file/directory is older than the tolerance full caching
Hi,
I think I found the culprit for what I thought was a race condition in
Octave.
The problem has to do with the way Octave 3.2 updates its load-path: it
only updates its cache of the current directory if the modification time
of the directory changes (see load_path::dir_info::update() in
10 matches
Mail list logo
