octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #31080] User scripts or functions created duri


From: Philip Nienhuis
Subject: [Octave-bug-tracker] [bug #31080] User scripts or functions created during a session are not found
Date: Sun, 05 Jan 2014 10:20:04 +0000
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:25.0) Gecko/20100101 Firefox/25.0 SeaMonkey/2.22.1

Follow-up Comment #23, bug #31080 (project octave):

Normally, in root dirs there shouldn't be so awfully many files.

I don't know Octave's function/script file loading internals, so apologies if
the following is a dumb question; but I wonder, why stat all files? all that
seems to be needed is to just stat the called function file in question, and
then only once after entering each Octave command (as changing some called
function file contents while Octave is accessing it in e.g. a loop wouldn't be
a good idea.)

So if this needs to be fixed at all, maybe modding the function/script load
logic for Windows systems is the way to go?

I agree with Rik that this can get quite messy.
NTFS isn't a monolithic static file system; there are several versions around.
M$ also still has the WinFS looming somewhere, possibly with still other
behavior.
On NTFS it is possible to map other drives somewhere in the tree a la *nix
mount (on Windows it's called junctions IIRC); we would need to know how those
behave as well: as "local" subdirs, or do they behave as remote "root" dirs?
in the latter case we'd also need to detect them as such.


Even while this bug is quite old is hasn't seen many confirmations; so I'd
also agree with lowering priority/severity until we get more requests.
Repeating myself (see comment #13), having script or function files in root
dirs is something that can be avoided.

- IMO on local fixed drives (HDs) it's a bad idea anyway.

- Only on thumb drives and other removable drives, and in some cases on mapped
network drives, it can be more reasonable to keep m-files in the root dir.

Perhaps there is a way to detect a directory to be the root of a
removable/network device and act accordingly along Jordi's suggestion.
Note that thumb drives, and to a lesser extent network drives, are usually
slow; statting files may give a noticeable performance hit.
(I don't know if mapped network drives behave the same as "physical local"
drives as regards directory time stamps.)


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?31080>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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