octave-maintainers
[Top][All Lists]
Advanced

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

Problem with Octave 3.6.0


From: John W. Eaton
Subject: Problem with Octave 3.6.0
Date: Sun, 15 Jan 2012 17:54:58 -0500

On 15-Jan-2012, Jussi Lehtola wrote:

| I updated the Octave Fedora RPMs to 3.6.0, but before pushing them to
| the official repositorys I wanted to test them if they really work. So,
| I tried compiling the octave-gsl package.
| 
| + cd /builddir/build/BUILD
| + cd gsl-1.0.8
| + LANG=C
| + export LANG
| + unset DISPLAY
| + octave -H -q --no-window-system --no-site-file --eval 'pkg build
|   '\''-verbose'\'' /var/tmp/octave-gsl-1.0.8-2.fc17.x86_64 
/builddir/build/BUILD/gsl-1.0.8'
|   terminate called after throwing an instance of 'std::out_of_range'
|   what():  basic_string::at panic: Aborted -- stopping myself...
| /var/tmp/rpm-tmp.bdgnb5: line 33: 19075 Aborted                 (core
| dumped) octave -H -q --no-window-system --no-site-file --eval "pkg
| build
| '-verbose' /var/tmp/octave-gsl-1.0.8-2.fc17.x86_64 
/builddir/build/BUILD/gsl-1.0.8"
| 
| Since this is the default method we use in Fedora to compile
| packages from Octave forge, we need to fix this before I can push the
| new packages in Fedora 17.

Does the following change fix the problem for you?

I think the following change introduced this bug:

  http://hg.savannah.gnu.org/hgweb/octave/rev/8edece28cf4d

jwe

diff --git a/src/load-save.cc b/src/load-save.cc
--- a/src/load-save.cc
+++ b/src/load-save.cc
@@ -649,7 +649,7 @@
   std::string orig_fname = "";
 
   // Function called with Matlab-style ["filename", options] syntax
-  if (argc > 1 && argv[1].at(0) != '-')
+  if (argc > 1 && ! argv[1].empty () && argv[1].at(0) != '-')
     {
       orig_fname = argv[1];
       i++;
diff --git a/test/test_io.m b/test/test_io.m
--- a/test/test_io.m
+++ b/test/test_io.m
@@ -227,6 +227,8 @@
 %!
 %! delete matrix.ascii;
 
+%!error <unable to find file> load ("")
+
 %% FIXME: This test is disabled as it writes to stdout and there is no easy
 %% way to recover output.  Need to spawn new octave process and pipe stdout
 %% somewhere to treat this case.

reply via email to

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