octave-maintainers
[Top][All Lists]
Advanced

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

Re: octaverc and version in path?


From: Ben Abbott
Subject: Re: octaverc and version in path?
Date: Sun, 30 Dec 2007 23:34:12 +0800

On Dec 30, 2007, at 10:41 PM, Thomas Treichl wrote:

Ben Abbott schrieb:

On Dec 30, 2007, at 6:03 AM, Thomas Treichl wrote:

Ben Abbott schrieb:
Thomas,
Thanks for the reply. I've  not used genpath before, but if I understand its functionality, won't that solution simply add all directories that lie within Users/dushanm/Octave?

I'm not very quick right now in reading and answering emails. That's why I've overlooked the end of the last thread.

Right Ben, all subdirectories are added too...

I'm not so organized. My octave directories are scattered and often contain directories I don't want in the path.

There is another nice command 'rmpath' to delete one or more entries in the path list.

 help rmpath

gives more info about how to use it.

By chance did you look over my email where I suggested a .octaverc resembling that below
## Begin savepath auto-created section, do not edit
 path ([pathdef,pathsep,'/Users/bpabbott']);
## End savepath auto-created section

Seems to work too, sure, an equivalent implementation would be

addpath ("/Users/bpabbott");

 Thomas

Thomas,

I think there is some confusion, perhaps it began on my end?

In any event, the problem I've been looking at occurs when savepath.m is run and then octave is updated to a new version.

For example, if savepath.m is run from octave 2.9.15(?), and octave is updated (say to 3.0.0), then when octave 3.0.0 is run the working path is replaced by the that of 2.9.15. In the event that the 2.9.15 version has been deleted, the result is a nonfunctional octave. If 2.9.15 is not deleted, octave 3.0.0 will still try to use the m-files and oct-files of the 2.9.15 version ... perhaps the result would be partially functional.

So what I was hoping to discuss were approaches to (1) update without worries of loading a non-functional path from .octaverc, and (2) would it be possible for .octaverc to support multiple versions of octave simultaneously?

There are many approaches to reconciling this. I decided to try to limit myself to savepath.m since it is responsible for adding the path information to .octaverc.

After some thought on how savepath.m might be modified to avoid including version specific paths, I decided to try extract the portions of that path that are not present in the pathdef (let's call that portion userpath), and then store the result in .octaverc as

path ([pathdef, pathsep, userpath]);

Then if a change to a new version of octave occurs, octave will load a functioning path. I have completed such a modification to savepath.m and it appears to work as expected.

One unfortunate feature of this approach is that the resulting path does not respect the "-end" and "-begin" options of addpath().

Thoughts?

Everything makes sense to me that you have found out. I would say you send a copy of your email (the part above) and your code modifications that you've implemented to the discussion that has been started at the maintainers-list.

The only thing that I'm currently thinking about: Should 'savepath' really write anything directly into the .octaverc file if no input argument is given?

 Thomas

What do you propose, if no input is given?

Also, how is a new (in some cases expeirenced) user to know about ~/.octaverc and its intended function?

Ben

p.s. we slipped off the list, so I'm trying to recover and put it all back on (my bad)


reply via email to

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