[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ~/.octaverc overwrites OCTAVE_PATH!!
|
From: |
Ben Abbott |
|
Subject: |
Re: ~/.octaverc overwrites OCTAVE_PATH!! |
|
Date: |
Mon, 22 Dec 2008 23:15:25 -0500 |
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