~/.octaverc overwrites OCTAVE_PATH!!

Tue Dec 23 21:17:32 CST 2008

On Dec 23, 2008, at 2:41 PM, Rosen Diankov wrote:
>
> 2008/12/23 Rosen Diankov <rdiankov at cs.cmu.edu>:
>> 2008/12/23 Ben Abbott <bpabbott at mac.com>:
>>>
>>> On Dec 22, 2008, at 11:15 PM, Ben Abbott wrote:
>>>
>>>>
>>>> On Dec 22, 2008, at 5:34 PM, Rosen Diankov wrote:
>>>>
>>>>>
>>>>> 2008/12/22 Ben Abbott <bpabbott at mac.com>:
>>>>>>
>>>>>> On Dec 22, 2008, at 1:37 PM, Rosen Diankov wrote:
>>>>>>>
>>>>>>> 2008/12/21 Ben Abbott <bpabbott at mac.com>:
>>>>>>>>
>>>>>>>> On Dec 21, 2008, at 3:38 PM, Rosen Diankov wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I'm trying to append my own directory with octave files
>>>>>>>>> (/usr/local/myoctavefiles) to the automatically set octave
>>>>>>>>> paths. At
>>>>>>>>> first, I tried doing
>>>>>>>>>
>>>>>>>>> export OCTAVE_PATH=/usr/local/myoctavefiles
>>>>>>>>>
>>>>>>>>> but it didn't work since the auto-generated ~/.octaverc file  
>>>>>>>>> (from
>>>>>>>>> savepath) overwrites any added paths via the path function.  
>>>>>>>>> Ie,
>>>>>>>>> the
>>>>>>>>> ~/.octaverc file looks like:
>>>>>>>>>
>>>>>>>>> ## Begin savepath auto-created section, do not edit
>>>>>>>>> path ('/usr/local/share/...',...)
>>>>>>>>> ## End savepath auto-created section
>>>>>>>>>
>>>>>>>>> So the next obvious thing to do was to call
>>>>>>>>> addpath('/usr/local/myoctavefiles') right after the '## End
>>>>>>>>> savepath
>>>>>>>>> ...', but this has a very dangerous side-effect. The problem  
>>>>>>>>> is
>>>>>>>>> that
>>>>>>>>> the next time the user calls 'savepath', it will put
>>>>>>>>> /usr/local/myoctavefiles inside the auto-generated code. And
>>>>>>>>> even if I
>>>>>>>>> remove my addpath or set OCTAVE_PATH to something different,  
>>>>>>>>> my
>>>>>>>>> path
>>>>>>>>> will remain added to the octave path!
>>>>>>>>>
>>>>>>>>> So I propose a small savepath change that always puts
>>>>>>>>> getenv('OCTAVE_PATH') inside the auto-generated code.
>>>>>>>>> It would be great if this makes it into octave 3.0.4
>>>>>>>>>
>>>>>>>>> thank you,
>>>>>>>>> rosen diankov
>>>>>>>>
>>>>>>>> If I understand you correctly you'd like to be able to
>>>>>>>> dynamically add a
>>>>>>>> specific path when octave is run. Have you looked at the  
>>>>>>>> command
>>>>>>>> line
>>>>>>>> options. For example,
>>>>>>>>
>>>>>>>>  octave --path "/usr/local/myoctavefiles"
>>>>>>>>
>>>>>>>> Other command line options are detailed at the link below.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://www.gnu.org/software/octave/doc/interpreter/Command-Line-Options.html#Command-Line-Options
>>>>>>>>
>>>>>>>> Ben
>>>>>>
>>>>>>>
>>>>>>> It doesn't work, the ~/.octaverc file overwrites any paths from
>>>>>>> OCTAVE_PATH, -p, or --path because savepath directly calls  
>>>>>>> path. it
>>>>>>> would be great if at least it called addpath.
>>>>>>>
>>>>>>> rosen,
>>>>>>
>>>>>> Do you mean you'd like to have the lines added to .octaverc by
>>>>>> savepath use
>>>>>> "addpath(...)" rather than "path(...)"?
>>>>>>
>>>>>> sigh ... I find the savepath command more trouble that it is
>>>>>> worth :-(
>>>>>>
>>>>>> You may find the best solution it to modify .octaverc by manually
>>>>>> and use
>>>>>> addpath() to include your local octave directories.
>>>>>>
>>>>>> In any event, we will want to be compatible with matlab. Does
>>>>>> matlab provide
>>>>>> the functionality you're looking for?
>>>>>>
>>>>>> Ben
>>>>>>
>>>>>
>>>>> I agree with you. the current savepath does break some things  
>>>>> about
>>>>> the flow of paths in octave. We recently started using octave  
>>>>> for a
>>>>> robotics framework ROS
>>>>> (http://pr.willowgarage.com/wiki/rosoct#preview) and we are  
>>>>> starting
>>>>> to create many packages that optionally have octave code that  
>>>>> use a
>>>>> core ROS 'octave library'. In order for those functions to be  
>>>>> visible
>>>>> in octave, they have to be added to the path, so I would like the
>>>>> users to be able to add a simple
>>>>>
>>>>> export OCTAVE_PATH=...
>>>>>
>>>>> in their .bashrc that automatically finds the correct directory  
>>>>> and
>>>>> includes it. The path will be dependent on the particular  
>>>>> directory
>>>>> their checkout tree lies in (which can change).
>>>>>
>>>>> The problem with savepath is that it sucks in the current paths  
>>>>> into
>>>>> its one 'path' call, which makes using multiple build trees of the
>>>>> robotics framework very hard.
>>>>>
>>>>> According to the matlab savepath, there is a separate 'userpath'
>>>>> variable that gets combined with the current paths.
>>>>>
>>>>> Ideally, savepath would remove all directories in OCTAVE_PATH  
>>>>> before
>>>>> making the addpath call (there's no reason it should be calling  
>>>>> path).
>>>>>
>>>>> thanks,
>>>>> rosen,
>>>>
>>>> A proper fix will be slightly more a bit more difficult than  
>>>> patching
>>>> savepath.m. In addition to OCTAVE_PATH a proper solution should  
>>>> also
>>>> treat the command line path option in the same fashion. My c/c++
>>>> skills are essentially non-existent, but this looks like a simple  
>>>> task
>>>> (maybe even I can manage it).
>>>>
>>>> What is needed it to make the "tpath" in  
>>>> load_path::do_initialize  of
>>>> load-path.cc were available to m-files.
>>>>
>>>> ----------------------
>>>> std::string tpath = load_path::command_line_path;
>>>>
>>>> if (tpath.empty ())
>>>>   tpath = octave_env::getenv ("OCTAVE_PATH");
>>>> ----------------------
>>>>
>>>> Can anyone tell me if such is *already* available to m-files. I'd
>>>> tried adding the code below to load-path.cc, but it doesn't  
>>>> work ...
>>>> which I expect demonstrates my c/c++ incompetence ;-)
>>>>
>>>> ----------------------
>>>> DEFUN (commandlinepath, , ,
>>>>   "-*- texinfo -*-\n\
>>>> @deftypefn {Built-in Function} {} commandlinepath (@dots{})\n\
>>>> Return the command line path variable.\n\
>>>> \n\
>>>> @seealso{path, addpath, rmpath, genpath, pathdef, savepath,  
>>>> pathsep}\n\
>>>> @end deftypefn")
>>>> {
>>>> return octave_value (load_path::command_line_path);
>>>> }
>>>> ----------------------
>>>>
>>>> Can someone enlighten me as to what I'm doing wrong? ... a "make"  
>>>> from
>>>> the src directory produces the result below.
>>>>
>>>> ----------------------
>>>> $ make
>>>> making defaults.h from defaults.h.in
>>>> defaults.h is unchanged
>>>> make: --cppflags: Command not found
>>>> make: --ldflags: Command not found
>>>> making oct-conf.h from oct-conf.h.in
>>>> oct-conf.h is unchanged
>>>> g++ -c -g -I/sw/include -FOpenGL -I/sw/include/freetype2 -I/sw/ 
>>>> include
>>>> -fPIC -I. -I.. -I../liboctave -I../src -I../libcruft/misc  -
>>>> DHAVE_CONFIG_H -mieee-fp -Wall -W -Wshadow -Wold-style-cast -g -O2
>>>> load-path.cc -o pic/load-path.o
>>>> load-path.cc: In function 'octave_value_list Fcommandlinepath(const
>>>> octave_value_list&, int)':
>>>> load-path.cc:48: error: 'std::string  
>>>> load_path::command_line_path' is
>>>> private
>>>> load-path.cc:1783: error: within this context
>>>> make: *** [pic/load-path.o] Error 1
>>>> ----------------------
>>>>
>>>> Ben
>>>
>>> No need for anyone to point out what I missed. I noticed the  
>>> public/private
>>> declarations in load-path.h.
>>>
>>> However, it occurred to me that using addpath() in place of path()  
>>> is not
>>> ensured to preserve the order of the path definition.
>>>
>>> I'm moving this thread to the developers list (which I should have  
>>> done
>>> earlier).
>>>
>>> I'll make an attempt at implementing the desired change and  
>>> produce a
>>> changeset for the developers sources.
>>>
>>> Ben
>>>
>>
>> To preserve path order, you can have savepath do:
>>
>> path(path,'/my/other/paths:asdfas')
>>
>> i would do the necessary changes, but i'm not sure where the  
>> savepath code is.
>>
>> rosen,
>>
>
> sorry, separate it with commas:
>
> path(path,'/my/other/paths','asdfas')
>
> rosen,

I think you misunderstood my concern.

In any event, regarding where savepath is, you can find it by type  
"which savepath" at Octave's command prompt.

I'll follow up with a changeset as soon as octave compiles with my  
changes.

Ben

p.s. pls bottom post so that others may review the discussion more  
easily.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20081223/7d12dbc8/attachment-0001.html 