Re: ~/.octaverc overwrites OCTAVE_PATH!!

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: ~/.octaverc overwrites OCTAVE_PATH!!

bpabbott
Administrator

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 <[hidden email]>:
>>>
>>> On Dec 22, 2008, at 1:37 PM, Rosen Diankov wrote:
>>>>
>>>> 2008/12/21 Ben Abbott <[hidden email]>:
>>>>>
>>>>> 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 | Threaded
Open this post in threaded view
|

Re: ~/.octaverc overwrites OCTAVE_PATH!!

Rosen Diankov-2
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 <[hidden email]>:

>
> 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 <[hidden email]>:
>>>>
>>>> On Dec 22, 2008, at 1:37 PM, Rosen Diankov wrote:
>>>>>
>>>>> 2008/12/21 Ben Abbott <[hidden email]>:
>>>>>>
>>>>>> 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 | Threaded
Open this post in threaded view
|

Re: ~/.octaverc overwrites OCTAVE_PATH!!

Rosen Diankov-2
sorry, separate it with commas:

path(path,'/my/other/paths','asdfas')

rosen,

2008/12/23 Rosen Diankov <[hidden email]>:

> 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 <[hidden email]>:
>>
>> 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 <[hidden email]>:
>>>>>
>>>>> On Dec 22, 2008, at 1:37 PM, Rosen Diankov wrote:
>>>>>>
>>>>>> 2008/12/21 Ben Abbott <[hidden email]>:
>>>>>>>
>>>>>>> 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 | Threaded
Open this post in threaded view
|

Re: ~/.octaverc overwrites OCTAVE_PATH!!

bpabbott
Administrator

On Dec 23, 2008, at 2:41 PM, Rosen Diankov wrote:

2008/12/23 Rosen Diankov <[hidden email]>:
2008/12/23 Ben Abbott <[hidden email]>:

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 <[hidden email]>:

On Dec 22, 2008, at 1:37 PM, Rosen Diankov wrote:

2008/12/21 Ben Abbott <[hidden email]>:

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.

Reply | Threaded
Open this post in threaded view
|

Re: [changeset] ~/.octaverc overwrites OCTAVE_PATH!!

bpabbott
Administrator

On Dec 23, 2008, at 10:17 PM, Ben Abbott wrote:
> <snip>

This changeset is intended to avoid having the path statement in  
octaverc (generated by savepath.m) over-write the paths originating  
from the environment and/or from the command line, the next time  
octave is run.

This is done by

(1) Having savepath.m place an addpath(...) rather than path(...)  
statement in octaverc.

(2) Removing the command-line & environment paths from the working  
path prior to writing the addpath statement to octaverc. In the event  
that pathdef() is empty, only the path from the environment is removed  
from the working path (which is assumed to be generated via the  
procedure used by run-octave)

(3) As knowledge of the command_line_path was needed by savepath.m,  
load-path.cc and load-path.h were modified to add the new function  
commandlinepath().

It may also be desired to remove the path associated with pathdef()  
from the working path prior to writing the addpath statement to  
octaverc.

By doing so only the portion added by the user should remain. This  
would also make upgrading from one version of octave to another more  
convenient (on my Mac the path to the core functions includes the  
version number). This would be my personal preference.

However, this will make it much more likely that the ordering of the  
path will not be preserved for subsequent executions of octave.  
Meaning that the user specified portions would either be added at the  
beginning or the end, but would not show up both ways.

As that may be a relatively significant compatibility issue, the path  
associated with pathdef() is still saved to octaverc.

My local octave package I had been using to install a working copy of  
octave build from mercurial broke rather recently. I've not yet been  
able to resolve the problem. Thus, I'm presently running a fresh build  
with these changes via run-octave.

  Ben





changeset-octave_path.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] ~/.octaverc overwrites OCTAVE_PATH!!

Rosen Diankov-2
Hi Ben,

great work!

As for the ordering issue, I would argue that if any user is advanced
enough to care about ordering, they will save the path history
themselves and not rely on savepath. Calling addpath is much cleaner
now since user and system paths have a smaller chance of getting mixed
up.

rosen,

2008/12/24 Ben Abbott <[hidden email]>:

>
> On Dec 23, 2008, at 10:17 PM, Ben Abbott wrote:
>>
>> <snip>
>
> This changeset is intended to avoid having the path statement in octaverc
> (generated by savepath.m) over-write the paths originating from the
> environment and/or from the command line, the next time octave is run.
>
> This is done by
>
> (1) Having savepath.m place an addpath(...) rather than path(...) statement
> in octaverc.
>
> (2) Removing the command-line & environment paths from the working path
> prior to writing the addpath statement to octaverc. In the event that
> pathdef() is empty, only the path from the environment is removed from the
> working path (which is assumed to be generated via the procedure used by
> run-octave)
>
> (3) As knowledge of the command_line_path was needed by savepath.m,
> load-path.cc and load-path.h were modified to add the new function
> commandlinepath().
>
> It may also be desired to remove the path associated with pathdef() from the
> working path prior to writing the addpath statement to octaverc.
>
> By doing so only the portion added by the user should remain. This would
> also make upgrading from one version of octave to another more convenient
> (on my Mac the path to the core functions includes the version number). This
> would be my personal preference.
>
> However, this will make it much more likely that the ordering of the path
> will not be preserved for subsequent executions of octave. Meaning that the
> user specified portions would either be added at the beginning or the end,
> but would not show up both ways.
>
> As that may be a relatively significant compatibility issue, the path
> associated with pathdef() is still saved to octaverc.
>
> My local octave package I had been using to install a working copy of octave
> build from mercurial broke rather recently. I've not yet been able to
> resolve the problem. Thus, I'm presently running a fresh build with these
> changes via run-octave.
>
>  Ben
>
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] ~/.octaverc overwrites OCTAVE_PATH!!

John W. Eaton
Administrator
In reply to this post by bpabbott
On 24-Dec-2008, Ben Abbott wrote:

| However, this will make it much more likely that the ordering of the  
| path will not be preserved for subsequent executions of octave.  
| Meaning that the user specified portions would either be added at the  
| beginning or the end, but would not show up both ways.

If some elements were added before and some after the default path,
wouldn't it be possible to determine that when parsing the path, and
then use addpath to append/prepend as necessary?

| +function [ subpaths ] = parsepath (p)

There is no need for the [] if there is only one return value, so
please write

  function subpaths = parsepath (p)

instead.

| +  pat = '([^:]+[:$])';
| +  [S, E, TE, subpaths] = regexpi(strcat (p, ':'), '([^:]+[$:])');
| +endfunction

To avoid confusion with the transpose operator, please use " to
delimit strings.  Also, for consistency with the rest of Octave,
please avoid upper-case variable names.

| diff -r 654bcfb937bf -r 8f389284c849 src/load-path.h
| --- a/src/load-path.h Tue Dec 23 08:28:23 2008 +0100
| +++ b/src/load-path.h Tue Dec 23 17:09:25 2008 -0500
| @@ -218,6 +218,8 @@
|        command_line_path += dir_path::path_sep_str () + p;
|    }
|  
| +  static std::string command_line_path;
| +

Instead of making this public, which will allow users to modify it,
please create a static function that returns the value instead.  Then
the value will still be protected from having users change it.

Thanks,

jwe
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] ~/.octaverc overwrites OCTAVE_PATH!!

bpabbott
Administrator

On Dec 24, 2008, at 1:17 PM, John W. Eaton wrote:

> On 24-Dec-2008, Ben Abbott wrote:
>
> | However, this will make it much more likely that the ordering of the
> | path will not be preserved for subsequent executions of octave.
> | Meaning that the user specified portions would either be added at  
> the
> | beginning or the end, but would not show up both ways.
>
> If some elements were added before and some after the default path,
> wouldn't it be possible to determine that when parsing the path, and
> then use addpath to append/prepend as necessary?

Yes, I think that is a better strategy. However, as It is possible  
that some path element are also placed inside the elements of  
pathdef() (by a mischievous user perhaps?). How might that be handled?

I can check to see if user specified elements (1) precede the the 1st  
element in pathdef(), (2) follow the last element of pathdef(), or (3)  
precede the entire pathdef() block. I'll assume that either (1) or (2)  
would be preferred. I'll implement (1) as it looks like the more  
obvious choice (to me).

> | +function [ subpaths ] = parsepath (p)
>
> There is no need for the [] if there is only one return value, so
> please write
>
>  function subpaths = parsepath (p)
>
> instead.
>
> | +  pat = '([^:]+[:$])';
> | +  [S, E, TE, subpaths] = regexpi(strcat (p, ':'), '([^:]+[$:])');
> | +endfunction
>
> To avoid confusion with the transpose operator, please use " to
> delimit strings.  Also, for consistency with the rest of Octave,
> please avoid upper-case variable names.

ok, done!

> | diff -r 654bcfb937bf -r 8f389284c849 src/load-path.h
> | --- a/src/load-path.h Tue Dec 23 08:28:23 2008 +0100
> | +++ b/src/load-path.h Tue Dec 23 17:09:25 2008 -0500
> | @@ -218,6 +218,8 @@
> |        command_line_path += dir_path::path_sep_str () + p;
> |    }
> |
> | +  static std::string command_line_path;
> | +
>
> Instead of making this public, which will allow users to modify it,
> please create a static function that returns the value instead.  Then
> the value will still be protected from having users change it.

ah-ha ... it didn't occur to me that I'd made command_line_path  
writable. My intent was to permit is value to be passed on the an m-
file. I'll take another look.

Ben


Reply | Threaded
Open this post in threaded view
|

Re: [changeset] ~/.octaverc overwrites OCTAVE_PATH!!

bpabbott
Administrator
In reply to this post by John W. Eaton

On Dec 24, 2008, at 1:17 PM, John W. Eaton wrote:

> Instead of making this public, which will allow users to modify it,
> please create a static function that returns the value instead.  Then
> the value will still be protected from having users change it.


Regarding the load-path.cc/h portions, please review the attached  
changeset and comment.

This solution works for me, but only because I've basically mimicked  
some exiting code (I lack the expertise needed to be confident I've  
done this correctly).

Ben
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] ~/.octaverc overwrites OCTAVE_PATH!!

bpabbott
Administrator

On Dec 24, 2008, at 6:04 PM, Ben Abbott wrote:

> On Dec 24, 2008, at 1:17 PM, John W. Eaton wrote:
>
>> Instead of making this public, which will allow users to modify it,
>> please create a static function that returns the value instead.  Then
>> the value will still be protected from having users change it.
>
> Regarding the load-path.cc/h portions, please review the attached  
> changeset and comment.
>
> This solution works for me, but only because I've basically mimicked  
> some exiting code (I lack the expertise needed to be confident I've  
> done this correctly).
>
> Ben
I've completed another attempt at a changeset. The changes to load-
path.h/cc should be reviewed before checking them in (btw, my  
apologies for neglecting to attached these files on my prior email).

With the changes in place savepath should not include path elements  
respecting (1) octave's core, (2) system packages, (3) user packages,  
(4) command line, or (5) the environment (OCTAVE_PATH) when saving the  
path to octaverc.

I'm uncertain as to whether or not it is proper to include the path  
elements respecting the user and/or system pkgs, but as these should  
be included during the initialization process, I decided to remove  
them as well (to avoid redundancy).

There are two addpath statements written by savepath() to octaverc.  
One adds path elements to the beginning of the path, and another adds  
them to the end of the path. In normal operation, the middle is  
representative of pathdef(). When Octave is launched via run-octave,  
the middle is representative of the path specified on the command line.

Ben




changeset-octave_path.patch (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [changeset] ~/.octaverc overwrites OCTAVE_PATH!!

bpabbott
Administrator

On Dec 25, 2008, at 5:28 PM, Ben Abbott wrote:

>
> On Dec 24, 2008, at 6:04 PM, Ben Abbott wrote:
>
>> On Dec 24, 2008, at 1:17 PM, John W. Eaton wrote:
>>
>>> Instead of making this public, which will allow users to modify it,
>>> please create a static function that returns the value instead.  
>>> Then
>>> the value will still be protected from having users change it.
>>
>> Regarding the load-path.cc/h portions, please review the attached  
>> changeset and comment.
>>
>> This solution works for me, but only because I've basically  
>> mimicked some exiting code (I lack the expertise needed to be  
>> confident I've done this correctly).
>>
>> Ben
>
> I've completed another attempt at a changeset. The changes to load-
> path.h/cc should be reviewed before checking them in (btw, my  
> apologies for neglecting to attached these files on my prior email).
>
> With the changes in place savepath should not include path elements  
> respecting (1) octave's core, (2) system packages, (3) user  
> packages, (4) command line, or (5) the environment (OCTAVE_PATH)  
> when saving the path to octaverc.
>
> I'm uncertain as to whether or not it is proper to include the path  
> elements respecting the user and/or system pkgs, but as these should  
> be included during the initialization process, I decided to remove  
> them as well (to avoid redundancy).
>
> There are two addpath statements written by savepath() to octaverc.  
> One adds path elements to the beginning of the path, and another  
> adds them to the end of the path. In normal operation, the middle is  
> representative of pathdef(). When Octave is launched via run-octave,  
> the middle is representative of the path specified on the command  
> line.
>
> Ben

I've pushed this changeset as well.

Ben