octaverc and version in path?

[Ben Abbott]

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)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.cae.wisc.edu/pipermail/octave-maintainers/attachments/20071230/d441509d/attachment.html