octave-maintainers
[Top][All Lists]
Advanced

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

pathdef, savepath, ocaverc and Matlab


From: Ben Abbott
Subject: pathdef, savepath, ocaverc and Matlab
Date: Thu, 3 Jan 2008 17:37:43 +0800


On Dec 31, 2007, at 12:30 PM, Ben Abbott wrote:


On Dec 31, 2007, at 1:12 AM, Ben Abbott wrote:


On Dec 31, 2007, at 12:49 AM, John W. Eaton wrote:

The savepath function only exists for compatibility with Matlab, so
whatever it does should be compatible.

jwe

Good point.


I've spent some time looking over the differences between Matlab and Octave regarding path related functions. I've enumerated what I found below.

(1) pathdef: In Octave, pathdef() load's the virgin default path. In Matlab pathdef.m is a script created by savepath.m, and pathdef.m is used to setup Matlab's path each time Matlab is run.

(2) savepath: In Octave, savepath.m saves to current working path to ~/.octaverc. In Matlab, it saves the current working path to pathdef.m. On my Mac, Matlab doesn't require admin access to execute savepath.m ... Can someone tell us if it does on Linux?

(3) restoredefaultpath: In Matlab this allows a user to restore the working path to its virgin form. It only impacts the current session. In Octave, this may be done by path (pathdef);

(4) matlabroot: In Matlab this returns the path to the root of Matlab's installation directory. The Octave equivalent is OCTAVE_HOME.

(5) matlabrc: In Matlab matlabrc.m is supposed to have admin access (?) and is run each time Matlab is started. It is located in <matlabroot>/toolbox/local. The Octave equivalent [of startup] is octaverc located in octave-home/share/octave/version/m/startup.

(6) startup: In Matlab startup.m is run (if it exists in the path) each time Matlab is started, but only after matlabrc.m. The Octave equilvalent is ~/.octaverc.

(7) finish: In Matlab finish.m is run upon a clean exit. From what I can tell there is no Octave equivalent.

There are many differences. Some will require changes to c-code while the majority require changes to m-files.

I'm up to the task of handling the m-files but will need someone to take on the c part.

If it is desirable and appropriate to reconcile these differences, I can put together an approach that will allow for incremental changes that ensures a functional Octave.

I'll get started on the sequence of events needed. In the meantime, I'm eager for feedback so that I'm not wasting effort and/or time.

Ben

I thought I'd rename the thread, as we've branched into a new direction.

Regarding a possible sequence of events to resolve these differences between Octave and Matlab, I'd like to propose the following.

(1) Rename the built-in function "pathdef" with to "defaultpath".

(2) Introduce ".../scripts/path/restoredefaultpath.m", which is essentially "path (defaultpath);"

(3) Introduce a new script, named ".../scripts/path/pathdef.m", which returns the path which an octave session begins with, prior to running "~/.octaverc".

(4) The purpose of "savepath" can be left as it is, but might be modified to save the path to "octave-home/share/octave/version/m/ startup/octavrc" when run with admin privilege. In either event, the script should warn the user of which file is modified, when a file is not explicitly specified.

(5) Add script "matlabroot.m" to ".../scripts/path/matlabroot.m" ... perhaps an "octaveroot.m" also/instead?

(6) If it exists in the path, run script "finish.m" upon exiting.

As I have no experience in c/c++ programming, it is likely a bad idea for me to take on (1) or (6), but I'm willing to give (1) a try ... However, if someone is up to posting a patch for (1), I'll incorporate it into my local build and take on the rest.

Ben







reply via email to

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