octaverc and version in path?

[Ben Abbott]

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

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

As you suggested I've attached that patch.

In my case, my user .octaverc file contains these three lines

	## Begin savepath auto-created section, do not edit
	  path ([pathdef,pathsep,'/Users/bpabbott/Documents/Octave']);
	## End savepath auto-created section

To All, I'd like to hear more opinions. Is this patch a good idea, is  
there a better way?

Ben

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.cae.wisc.edu/pipermail/octave-maintainers/attachments/20071230/e85b0d53/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: savepath.patch
Type: application/octet-stream
Size: 2799 bytes
Desc: not available
Url : https://www.cae.wisc.edu/pipermail/octave-maintainers/attachments/20071230/e85b0d53/attachment.obj 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.cae.wisc.edu/pipermail/octave-maintainers/attachments/20071230/e85b0d53/attachment-0001.html