octave-maintainers
[Top][All Lists]
Advanced

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

Re: ~/.octaverc overwrites OCTAVE_PATH!!


From: Rosen Diankov
Subject: Re: ~/.octaverc overwrites OCTAVE_PATH!!
Date: Tue, 23 Dec 2008 11:34:52 -0800

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,


2008/12/23 Ben Abbott <address@hidden>:
>
> 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 <address@hidden>:
>>>>
>>>> On Dec 22, 2008, at 1:37 PM, Rosen Diankov wrote:
>>>>>
>>>>> 2008/12/21 Ben Abbott <address@hidden>:
>>>>>>
>>>>>> 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
>
>


reply via email to

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