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: Mon, 31 Dec 2007 00:18:45 +0800


On Dec 31, 2007, at 12:08 AM, Thomas Treichl wrote:

Ben Abbott schrieb:
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?

Right, so my thoughts about this are that an experienced user does know about .octaverc and at least does know what to do if he called (expected or not) 'savepath()' without input argument and modified his .octaverc file. Further, if the nargin==0 option wouldn't be there right now then the experienced user could easily use

 savepath ("~/.octaverc");

An unexperienced user calls 'savepath()' and does not see anything happen on screen. In real he modified his .octaverc file. He (platform independent) upgrades to a newer version of Octave and nothing does work anymore (because of the version specific path names). However, version specific path names seem to have much higher priority to me.

I summarize my thoughts here: Per default (eg. without any input argument) an Octave function should not modify any of the files on a disc as long as it is not absolutely clear and/or absolutely necessary. Better throw an error here with the 'savepath' function if nargin==0.

ok. One point, the patch I submitted respects the version specifics.

Meaning that you can run different versions of Octave and all should work (fingers-crossd) as expected.

Regarding the silent change to .octaverc, we could add a warning when nargin==0 and still save the current working path is ~/.octaverc.

Would that be satisfactory?

Ben




reply via email to

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