Bug#779943: [Pkg-octave-devel] Bug#779943: octave: Enable large arrays: Build octave such that it can use arrays larger than 2 GB
On 03/06/2015 10:57 AM, Fabrice Allibe wrote: Package: octave Version: 3.8.2-4 Severity: wishlist Dear Maintainer, the size of a single Octave array cannot exceed 2 GB of memory because octave is not built with --enable-64 flag I'm not disputing that a version of Octave built with 64-bit indexing enabled would be useful, but on a system with 64-bit pointers and 32-bit indexing, the limit for any array is approximately 2^32 *elements* not 2GB of memory. The actual amount of memory allocated and used can be larger than than 2GB. This is explained in the Octave manual pages that you linked to: www.gnu.org/software/octave/doc/interpreter/Compiling-Octave-with-64_002dbit-Indexing.html Also, there can be multiple arrays of up to this size. jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759426: [Pkg-octave-devel] Bug#759426: octave-common: includes arch-specific config.log build artifact
On 08/27/2014 04:08 AM, Mike Miller wrote: Package: octave-common Version: 3.8.2-1 Severity: normal Since version 3.8.1, the octave-common package, which is arch:all, now includes /usr/share/octave/$VER/etc/config.log. This file is copied directly from the build tree and contains architecture- and system-specific details about the build environment. This file should not be installed at all, and even more so that it's in an arch:all package but contains arch-specific details. I've reported this upstream at https://savannah.gnu.org/bugs/?43087, hopefully it will simply be removed from make install in a future version. I explained in a comment to the Octave bug report why I included the file in the install target and I don't plan to remove it. Is there a better location for it? jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714360: [Pkg-octave-devel] Bug#714360: src:octave: does not work with glpk 4.51-1
On 06/28/2013 08:27 AM, Sébastien Villemot wrote: Package: src:octave Version: 3.6.4-3 Severity: normal Tags: upstream Usertags: glpk Control: forwarded -1 https://savannah.gnu.org/bugs/?func=detailitemitem_id=39038 Octave 3.6.4 is not compatible with the last version of glpk (4.51-1) which is currently in experimental. Some obsolete functions were removed from glpk, but Octave still uses them. As a consequence, the configure script of Octave fails to detect glpk (but Octave nevertheless compiles), and the resulting Octave binary does not have the functionality provided by the glpk.m function. I attach a build log for reference. The severity of this bug report will be raised when the new version of glpk is uploaded to unstable. I looked at this problem in the last few days. My assessment was that an expert in glpk could probably make the changes fairly quickly, but it does not look something I could do in a few hours. The API has changed in ways that make it non-obvious to me exactly what changes we need to make. It's not a simple matter of changing the names of a few functions. jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706376: [Pkg-octave-devel] Bug#706376: Bug#706376: Bug#706376: Bug#706376: Bug#706376: Bug#706376: octave: sparse matrix n*2^16
On 06/19/2013 08:32 PM, David Bateman wrote: On 06/20/2013 01:10 AM, David Bateman wrote: I'd like to add some tests first and see if any other bugs have turned up after this change. For example the changes use made to sprand and sprandn 2 years ago to call randperm also overflows. At the moment I'm getting 791 failed tests with make check is that normal ? David Ok, it seems Jaroslav's code for idx_vector(Sparsebool hasn't been used much in the last 5 years as it was completely wrong and when I started using it, it caused 791 failures in make check. I've fixed his code as it makes sense to use it and pushed my changeset at http://hg.savannah.gnu.org/hgweb/octave/rev/8fce0ed4894a This change seems OK to me, but is there some reason to not use dim_vector dv = dims (); return (dv.any_zero ()); as the default definition for is_empty? jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706376: [Pkg-octave-devel] Bug#706376: Bug#706376: octave: sparse matrix n*2^16
On 04/30/2013 12:56 PM, Ed Meyer wrote: Not only is it desirable to have sparse and full matrices behave similarly, I believe the user should not need to be aware of which storage format is used so functions like eig() would work for either. The key is to use the C++ class system to have different implementations for each storage format. I haven't been following this thread closely and I haven't thought much about the details but I have no objection to trying to do a better job with handling numel and dimensions/indices generally. Is there some way we can get the better behavior in a minimally invasive way? Even if it requires significant changes, maybe we should consider what the options are anyway. What changes are needed to make octave_idx_type behave the way you way you want? jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676800: [Pkg-octave-devel] Bug#676800: octave-java: completely breaks octave
On 20-Jun-2012, Sébastien Villemot wrote: | John W. Eaton j...@octave.org writes: | | I'd like to help debug this problem but I need some help. | | Thanks for volunteering! | | I need to be able to install a debug version of Octave (preferably the | current development sources) and build the Java package also with | debugging symbols. I'm using Debian testing. What packages do I need | to install? After doing | |pkg install java-1.2.8.tar.gz | | apparently successfully, I'm seeing | |octave javaclasspath |warning: timestamp on file /usr/lib/jvm/default-java/jre/lib/amd64/client/libjvm.so is in the future |error: java_invoke: /usr/lib/jvm/default-java/jre/lib/amd64/client/libjvm.so: failed to load: /usr/lib/jvm/default-java/jre/lib/amd64/client/libjvm.so: cannot open shared object file: No such file or directory |error: called from: |error: /home/jwe/octave/java-1.2.8/javaclasspath.m at line 49, column 14 | | You need this patch (incorporated in the octave-java package): | | http://anonscm.debian.org/gitweb/?p=pkg-octave/octave-java.git;a=blob;f=debian/patches/libjvm.patch;h=cc847293d00ae09ac74e8eca833dbafdd48918a2;hb=19a7fdc2264cb0166f5324677bf2615252fda8e3 | | Also, /usr/lib/jvm/default-java points to OpenJDK 6 on my Debian sid | system. If you want to select OpenJDK 7, you need to set the JAVA_HOME | variable to: | | export JAVA_HOME = /usr/lib/jvm/java-7-openjdk-amd64 | | (this is done in debian/rules of the octave-java package). Thanks. With that, I'm able to build the java package. Running Octave with valgrind and executing javaclasspath at the Octave prompt, I see a lot of messages, starting with: ==29404== Warning: set address range perms: large range [0x393a7000, 0x1371a7000) (defined) ==29404== Warning: set address range perms: large range [0x393a7000, 0x1371a7000) (noaccess) ==29404== Warning: set address range perms: large range [0x393a7000, 0x1371a7000) (defined) ==29404== Warning: set address range perms: large range [0x1371a7000, 0x234fa7000) (defined) ==29404== Warning: set address range perms: large range [0x234fa7000, 0x332da7000) (defined) ==29404== Warning: set address range perms: large range [0x41036a000, 0x50e16a000) (defined) ==29404== Warning: set address range perms: large range [0x50e16a000, 0x60bf6a000) (defined) ==29404== Warning: set address range perms: large range [0x60bf6a000, 0x709d6a000) (defined) ==29404== Warning: set address range perms: large range [0x393a7000, 0x1371a7000) (noaccess) ==29404== Warning: set address range perms: large range [0x1371a7000, 0x234fa7000) (noaccess) ==29404== Warning: set address range perms: large range [0x234fa7000, 0x332da7000) (noaccess) ==29404== Warning: set address range perms: large range [0x41036a000, 0x50e16a000) (noaccess) ==29404== Warning: set address range perms: large range [0x50e16a000, 0x60bf6a000) (noaccess) ==29404== Warning: set address range perms: large range [0x60bf6a000, 0x70220) (noaccess) ==29404== Warning: set address range perms: large range [0x393a7000, 0x1371b7000) (defined) ==29404== Warning: set address range perms: large range [0x393a7000, 0x1371b7000) (noaccess) ==29404== Warning: set address range perms: large range [0x393a7000, 0x1371c) (defined) ==29404== Invalid write of size 4 ==29404==at 0x163212BD: ??? ==29404==by 0x16311437: ??? ==29404==by 0x1554C68D: JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==29404==by 0x1554C134: JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==29404==by 0x1550ECA0: instanceKlass::call_class_initializer_impl(instanceKlassHandle, Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==29404==by 0x1550ED1C: instanceKlass::call_class_initializer(Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==29404==by 0x1550EEF0: instanceKlass::initialize_impl(instanceKlassHandle, Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==29404==by 0x1550F40A: instanceKlass::initialize(Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==29404==by 0x1550F17F: instanceKlass::initialize_impl(instanceKlassHandle, Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==29404==by 0x1550F40A: instanceKlass::initialize(Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==29404==by 0x1582E6F5: Threads::create_vm(JavaVMInitArgs*, bool*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==29404==by 0x15569D67: JNI_CreateJavaVM (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==29404== Address 0x7feffd960
Bug#676800: [Pkg-octave-devel] Bug#676800: octave-java: completely breaks octave
On 20-Jun-2012, Sébastien Villemot wrote: | Looks like these valgrind errors are generated by the JVM and not by the | java package. They are probably not a cause of concern. | | I don't know how to generate a difference in the valgrind logs, and I | don't have one between OpenJDK 6 and 7. | | The only clear manifestation of the problem is the crashes that I | experience with octave-java compiled against Octave, as reported | initially in this bug. | | Are you able to replicate the crash? No, I haven't seen a crash yet. | On sid, install both octave-io and | octave-java, and octave should crash at runtime. Sorry, I've never been able to keep track of what sid or wheezy or whatever means. I stay fairly current with the testing distribution, whatever that is, on an amd64 system. You'll have to tell me precisely what to install and what commands to run to reproduce the crash. jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676800: [Pkg-octave-devel] Bug#676800: octave-java: completely breaks octave
On 9-Jun-2012, Sébastien Villemot wrote: | Package: octave-java | Version: 1.2.8-4 | Severity: grave | Tags: sid | | This version of octave-java completely breaks octave. | | For example, if octave-io is also installed, octave miserably fails at launch | time: | | octave: lex.ll :2420 : void handle_number(): L'assertion « nread == 1 » a échoué. | panic: Abandon -- stopping myself... | Abandon | | Various other kinds of strange breakage happens (e.g. numerical errors). It | looks like a memory corruption problem. | | Since downgrading to octave-java 1.2.8-3 solves the issue, the cause of the | problem is clearly the switch from OpenJDK 6 to 7. | | This needs to be investigated with the openjdk-7 maintainers. I'd like to help debug this problem but I need some help. I need to be able to install a debug version of Octave (preferably the current development sources) and build the Java package also with debugging symbols. I'm using Debian testing. What packages do I need to install? After doing pkg install java-1.2.8.tar.gz apparently successfully, I'm seeing octave javaclasspath warning: timestamp on file /usr/lib/jvm/default-java/jre/lib/amd64/client/libjvm.so is in the future error: java_invoke: /usr/lib/jvm/default-java/jre/lib/amd64/client/libjvm.so: failed to load: /usr/lib/jvm/default-java/jre/lib/amd64/client/libjvm.so: cannot open shared object file: No such file or directory error: called from: error: /home/jwe/octave/java-1.2.8/javaclasspath.m at line 49, column 14 I have the following packages installed: $ dpkg -l '*openjdk*' | grep ^ii ii openjdk-6-dbg: 6b24-1.11.1-6 Java runtime based on OpenJDK (debugging sym ii openjdk-6-jdk: 6b24-1.11.1-6 OpenJDK Development Kit (JDK) ii openjdk-6-jre: 6b24-1.11.1-6 OpenJDK Java runtime, using Hotspot JIT ii openjdk-6-jre- 6b24-1.11.1-6 OpenJDK Java runtime, using Hotspot JIT (hea ii openjdk-6-jre- 6b24-1.11.1-6 OpenJDK Java runtime (architecture independe ii openjdk-7-jdk: 7~u3-2.1.1~pre OpenJDK Development Kit (JDK) ii openjdk-7-jre: 7~u3-2.1.1~pre OpenJDK Java runtime, using Hotspot JIT ii openjdk-7-jre- 7~u3-2.1.1~pre OpenJDK Java runtime, using Hotspot JIT (hea ii openjdk-7-jre- 7~u3-2.1.1~pre OpenJDK Java runtime (architecture independe $ dpkg -l '*default-j*' | grep ^ii ii default-jdk1:1.6-47 Standard Java or Java compatible Development ii default-jre1:1.6-47 Standard Java or Java compatible Runtime ii default-jre-he 1:1.6-47 Standard Java or Java compatible Runtime (he What am I missing, or what is misconfigured that I don't have libjvm.so in the /usr/lib/jvm/default-java/jre/lib/amd64/client directory? jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650714: libc6: strptime memory access error
Package: libc6 Version: 2.13-21 Severity: normal Hi, Compililing the attached program with gcc and running the resulting binary with valgrind --tool=memcheck shows teh following errors. Compiling with -DEXTRA=10 to allocate and initialize more space for the first parameter passed to strptime avoids the valgrind errors. ==23362== Memcheck, a memory error detector ==23362== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==23362== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==23362== Command: ./a.out ==23362== ==23362== Invalid read of size 8 ==23362==at 0x4EAF49C: __GI___strncasecmp_l (strcmp.S:216) ==23362==by 0x4EC80D0: __strptime_internal (strptime_l.c:420) ==23362==by 0x400645: main (in /export/home/jwe/a.out) ==23362== Address 0x51b104b is 11 bytes inside a block of size 12 alloc'd ==23362==at 0x4C2779D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==23362==by 0x4005D7: strsave (in /export/home/jwe/a.out) ==23362==by 0x400629: main (in /export/home/jwe/a.out) ==23362== ==23362== Invalid read of size 8 ==23362==at 0x4EB0984: __GI___strncasecmp_l (strcmp.S:1362) ==23362==by 0x4EC8150: __strptime_internal (strptime_l.c:431) ==23362==by 0x400645: main (in /export/home/jwe/a.out) ==23362== Address 0x51b1048 is 8 bytes inside a block of size 12 alloc'd ==23362==at 0x4C2779D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==23362==by 0x4005D7: strsave (in /export/home/jwe/a.out) ==23362==by 0x400629: main (in /export/home/jwe/a.out) ==23362== ==23362== Invalid read of size 8 ==23362==at 0x4EAF49C: __GI___strncasecmp_l (strcmp.S:216) ==23362==by 0x4EC81E4: __strptime_internal (strptime_l.c:444) ==23362==by 0x400645: main (in /export/home/jwe/a.out) ==23362== Address 0x51b104b is 11 bytes inside a block of size 12 alloc'd ==23362==at 0x4C2779D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==23362==by 0x4005D7: strsave (in /export/home/jwe/a.out) ==23362==by 0x400629: main (in /export/home/jwe/a.out) ==23362== ==23362== Invalid read of size 8 ==23362==at 0x4EB0984: __GI___strncasecmp_l (strcmp.S:1362) ==23362==by 0x4EC8D07: __strptime_internal (strptime_l.c:446) ==23362==by 0x400645: main (in /export/home/jwe/a.out) ==23362== Address 0x51b1048 is 8 bytes inside a block of size 12 alloc'd ==23362==at 0x4C2779D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==23362==by 0x4005D7: strsave (in /export/home/jwe/a.out) ==23362==by 0x400629: main (in /export/home/jwe/a.out) ==23362== ==23362== Invalid read of size 8 ==23362==at 0x4EB1768: __GI___strncasecmp_l (strcmp.S:2113) ==23362==by 0x4EC80D0: __strptime_internal (strptime_l.c:420) ==23362==by 0x400645: main (in /export/home/jwe/a.out) ==23362== Address 0x51b1048 is 8 bytes inside a block of size 12 alloc'd ==23362==at 0x4C2779D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==23362==by 0x4005D7: strsave (in /export/home/jwe/a.out) ==23362==by 0x400629: main (in /export/home/jwe/a.out) ==23362== ==23362== Invalid read of size 8 ==23362==at 0x4EB0044: __GI___strncasecmp_l (strcmp.S:862) ==23362==by 0x4EC8150: __strptime_internal (strptime_l.c:431) ==23362==by 0x400645: main (in /export/home/jwe/a.out) ==23362== Address 0x51b1048 is 8 bytes inside a block of size 12 alloc'd ==23362==at 0x4C2779D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==23362==by 0x4005D7: strsave (in /export/home/jwe/a.out) ==23362==by 0x400629: main (in /export/home/jwe/a.out) ==23362== ==23362== Invalid read of size 8 ==23362==at 0x4EB1768: __GI___strncasecmp_l (strcmp.S:2113) ==23362==by 0x4EC81E4: __strptime_internal (strptime_l.c:444) ==23362==by 0x400645: main (in /export/home/jwe/a.out) ==23362== Address 0x51b1048 is 8 bytes inside a block of size 12 alloc'd ==23362==at 0x4C2779D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==23362==by 0x4005D7: strsave (in /export/home/jwe/a.out) ==23362==by 0x400629: main (in /export/home/jwe/a.out) ==23362== ==23362== Invalid read of size 8 ==23362==at 0x4EB0044: __GI___strncasecmp_l (strcmp.S:862) ==23362==by 0x4EC8D07: __strptime_internal (strptime_l.c:446) ==23362==by 0x400645: main (in /export/home/jwe/a.out) ==23362== Address 0x51b1048 is 8 bytes inside a block of size 12 alloc'd ==23362==at 0x4C2779D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==23362==by 0x4005D7: strsave (in /export/home/jwe/a.out) ==23362==by 0x400629: main (in /export/home/jwe/a.out) ==23362== ==23362== Invalid read of size 8 ==23362==at 0x4EB0734: __GI___strncasecmp_l (strcmp.S:1237) ==23362==by 0x4EC80D0: __strptime_internal (strptime_l.c:420) ==23362==by 0x400645: main (in /export/home/jwe/a.out) ==23362== Address 0x51b1048 is 8 bytes inside a block of size
Bug#637787: [Pkg-octave-devel] Bug#637787: Bug#637787: Bug#637787: Bug#637787: Bug#637787: Bug#637787: Bug#637787: Bug#637787: trivial fix
Hi, Did you see the following message from me? I think I found the reason that libranlib.la is not being built, and a relatively simple fix. jwe On 25-Oct-2011, John W. Eaton wrote: | On 24-Oct-2011, John W. Eaton wrote: | | | On 24-Oct-2011, Thomas Weber wrote: | | | | | On Thu, Sep 01, 2011 at 09:03:57PM +0200, Thomas Weber wrote: | | | On Tue, Aug 23, 2011 at 12:24:17PM -0400, John W. Eaton wrote: | | | If you don't want to change octlibdir, then you can change the lines | | | like | | | | | | octlib_LTLIBRARIES = liboctave.la | | | | | | in the Makefile.am files to be | | | | | | lib_LTLIBRARIES = liboctave.la | | | | | | instead. It's the octlib (or lib) prefix that is used to generate the | | | variable that determines the installation directory. | | | | | | I did the change above, but the build fails almost always (almost = in a | | | clean chroot). It builds reliable in my normal work directory, which is | | | strange (I already looked at timestamp issues, but I do not think that | | | that is the problem). It always fails when linking in libcruft/ with the | | | error message: | | | | | | libtool: link: cannot find the library `libranlib.la' or unhandled | | | argument `libranlib.la' | | | | | | I've put a log file of the build at | | | http://people.debian.org/~tweber/octave.log.bz2 | | | | | | The commands effectively run are: | | | automake --foreign --verbose | | | ./configure --build=x86_64-linux-gnu --prefix=/usr | | | make -j1 | | | | | | Do you have any ideas? | | | | I can't reproduce the problem, but I'm not sure I'm doing exactly the | | same thing as you. | | | | Can you please give me step-by-step instructions for how to download | | exactly the Debian package files and what to do with them to try to | | generate the package? Jordi gave me that info a few days ago and with | | what he showed me, I was able to generate the error you mention | | above. But now I can't find his instructions. | | OK, Jordi gave me the instructions and I can reproduce the problem. | | When libcruft/Makefile.am contains | | octlib_LTLIBRARIES = libcruft.la | noinst_LTLIBRARIES = libranlib.la | | The generated Makefile.in file contains | | LTLIBRARIES = $(noinst_LTLIBRARIES) $(octlib_LTLIBRARIES) | ... | all-am: Makefile $(LTLIBRARIES) $(HEADERS) | | and when it contains | | lib_LTLIBRARIES = libcruft.la | noinst_LTLIBRARIES = libranlib.la | | LTLIBRARIES is defined to be | | LTLIBRARIES = $(lib_LTLIBRARIES) $(noinst_LTLIBRARIES) | | So apparently these variables are sorted alphabetically when creating | the LTLIBRARIES variable. Then Make is building these libraries in | the order they are listed, so the latter fails, because libcruft.la | depends on libranlib.la, but it is not built yet. | | I think automake is supposed to be using the libcruft_la_LIBADD | variable to generate the dependency list for libcruft.la, but it | doesn't seem to be doing that. | | The quick fix appears to be adding libranlib.la to the | libcruft_la_DEPENDENCIES variable, so change the line | | libcruft_la_DEPENDENCIES = cruft.def | | in libcruft/Makefile.am to be | | libcruft_la_DEPENDENCIES = cruft.def libranlib.la | | instead. | | jwe | | | | ___ | Pkg-octave-devel mailing list | pkg-octave-de...@lists.alioth.debian.org | http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-octave-devel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637787: [Pkg-octave-devel] Bug#637787: Bug#637787: Bug#637787: Bug#637787: Bug#637787: Bug#637787: Bug#637787: trivial fix
On 24-Oct-2011, John W. Eaton wrote: | On 24-Oct-2011, Thomas Weber wrote: | | | On Thu, Sep 01, 2011 at 09:03:57PM +0200, Thomas Weber wrote: | | On Tue, Aug 23, 2011 at 12:24:17PM -0400, John W. Eaton wrote: | | If you don't want to change octlibdir, then you can change the lines | | like | | | | octlib_LTLIBRARIES = liboctave.la | | | | in the Makefile.am files to be | | | | lib_LTLIBRARIES = liboctave.la | | | | instead. It's the octlib (or lib) prefix that is used to generate the | | variable that determines the installation directory. | | | | I did the change above, but the build fails almost always (almost = in a | | clean chroot). It builds reliable in my normal work directory, which is | | strange (I already looked at timestamp issues, but I do not think that | | that is the problem). It always fails when linking in libcruft/ with the | | error message: | | | | libtool: link: cannot find the library `libranlib.la' or unhandled | | argument `libranlib.la' | | | | I've put a log file of the build at | | http://people.debian.org/~tweber/octave.log.bz2 | | | | The commands effectively run are: | | automake --foreign --verbose | | ./configure --build=x86_64-linux-gnu --prefix=/usr | | make -j1 | | | | Do you have any ideas? | | I can't reproduce the problem, but I'm not sure I'm doing exactly the | same thing as you. | | Can you please give me step-by-step instructions for how to download | exactly the Debian package files and what to do with them to try to | generate the package? Jordi gave me that info a few days ago and with | what he showed me, I was able to generate the error you mention | above. But now I can't find his instructions. OK, Jordi gave me the instructions and I can reproduce the problem. When libcruft/Makefile.am contains octlib_LTLIBRARIES = libcruft.la noinst_LTLIBRARIES = libranlib.la The generated Makefile.in file contains LTLIBRARIES = $(noinst_LTLIBRARIES) $(octlib_LTLIBRARIES) ... all-am: Makefile $(LTLIBRARIES) $(HEADERS) and when it contains lib_LTLIBRARIES = libcruft.la noinst_LTLIBRARIES = libranlib.la LTLIBRARIES is defined to be LTLIBRARIES = $(lib_LTLIBRARIES) $(noinst_LTLIBRARIES) So apparently these variables are sorted alphabetically when creating the LTLIBRARIES variable. Then Make is building these libraries in the order they are listed, so the latter fails, because libcruft.la depends on libranlib.la, but it is not built yet. I think automake is supposed to be using the libcruft_la_LIBADD variable to generate the dependency list for libcruft.la, but it doesn't seem to be doing that. The quick fix appears to be adding libranlib.la to the libcruft_la_DEPENDENCIES variable, so change the line libcruft_la_DEPENDENCIES = cruft.def in libcruft/Makefile.am to be libcruft_la_DEPENDENCIES = cruft.def libranlib.la instead. jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637787: [Pkg-octave-devel] Bug#637787: Bug#637787: Bug#637787: Bug#637787: Bug#637787: Bug#637787: trivial fix
On 24-Oct-2011, Thomas Weber wrote: | On Thu, Sep 01, 2011 at 09:03:57PM +0200, Thomas Weber wrote: | On Tue, Aug 23, 2011 at 12:24:17PM -0400, John W. Eaton wrote: | If you don't want to change octlibdir, then you can change the lines | like | | octlib_LTLIBRARIES = liboctave.la | | in the Makefile.am files to be | | lib_LTLIBRARIES = liboctave.la | | instead. It's the octlib (or lib) prefix that is used to generate the | variable that determines the installation directory. | | I did the change above, but the build fails almost always (almost = in a | clean chroot). It builds reliable in my normal work directory, which is | strange (I already looked at timestamp issues, but I do not think that | that is the problem). It always fails when linking in libcruft/ with the | error message: | | libtool: link: cannot find the library `libranlib.la' or unhandled | argument `libranlib.la' | | I've put a log file of the build at | http://people.debian.org/~tweber/octave.log.bz2 | | The commands effectively run are: | automake --foreign --verbose | ./configure --build=x86_64-linux-gnu --prefix=/usr | make -j1 | | Do you have any ideas? I can't reproduce the problem, but I'm not sure I'm doing exactly the same thing as you. Can you please give me step-by-step instructions for how to download exactly the Debian package files and what to do with them to try to generate the package? Jordi gave me that info a few days ago and with what he showed me, I was able to generate the error you mention above. But now I can't find his instructions. jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637787: [Pkg-octave-devel] Bug#637787: Bug#637787: Bug#637787: Bug#637787: Bug#637787: Bug#637787: trivial fix
On 1-Sep-2011, Thomas Weber wrote: | On Tue, Aug 23, 2011 at 12:24:17PM -0400, John W. Eaton wrote: | | Is the current problem that the libraries are placed in a directory | that has a version number in the name, or does dpkg-shlibeps not find | files in subdirectories of /usr/lib at all? | | That's a good question; I'm not really sure. | I don't think however, that the version should be in the installation | path - what happens when 3.4.3 comes around? | You should take my words on this with a grain of salt, though. I'm new | to it myself. I agree that if the shared libraries contain proper version information, then the package version number should not be a part of the name of the library directory. I asked about whether the libraries could go in a subdirectory because I think it would be better to have them installed in /usr/lib/octave instead of /usr/lib. Looking at /usr/lib on my Debian system, there seem to be a number of other packages that use subdirectories for library files, so maybe it is OK? jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637787: [Pkg-octave-devel] Bug#637787: Bug#637787: Bug#637787: Bug#637787: trivial fix
On 23-Aug-2011, Thomas Weber wrote: | On Mon, Aug 22, 2011 at 02:28:54PM -0400, John W. Eaton wrote: | On 19-Aug-2011, Thomas Weber wrote: | | | The problem is that dpkg-shlibdeps doesn't like the fact that Octave | | uses normal SONAMEs for its libraries now, but ships them in a private | | path (so dpkg-shlibdeps doesn't find them and aborts). | | So, I'm reading through far too many books/tutorials about libtool and | | friends now just so that the libraries end up under /usr/lib. | | Octave's Makefile.am files have lines like | |octlib_LTLIBRARIES = liboctave.la |octlib_LTLIBRARIES = liboctinterp.la | | so these files are installed in $(octlibdir) and the default | definition of octlibdir is set in configure.ac to be | |'$(libdir)/octave/$(version)' | | You are of course free to redefine this to be '$(libdir)' instead, and | I think that will cause the libraries to be installed into /usr/lib if | you set $(prefix) to be /usr. | | Yes, but I don't want to change $(octlibdir), because other software | might use that for specific libraries. Also, I need to get a better | understanding of libtool, autoconf and friends anyway. If you don't want to change octlibdir, then you can change the lines like octlib_LTLIBRARIES = liboctave.la in the Makefile.am files to be lib_LTLIBRARIES = liboctave.la instead. It's the octlib (or lib) prefix that is used to generate the variable that determines the installation directory. Maybe we should change the Octave sources to install the Octave libraries in $libdir instead of $octlibdir? Or would $pkglibdir be better? That is predefined by automake, so writing pkglib_LTLIBRARIES = liboctave.la should cause liboctave to be installed in $(libdir)/@PACKAGE@ (with octave substituted for @PACKAGE@ by configure. Is the current problem that the libraries are placed in a directory that has a version number in the name, or does dpkg-shlibeps not find files in subdirectories of /usr/lib at all? jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637787: [Pkg-octave-devel] Bug#637787: Bug#637787: Bug#637787: trivial fix
On 19-Aug-2011, Thomas Weber wrote: | The problem is that dpkg-shlibdeps doesn't like the fact that Octave | uses normal SONAMEs for its libraries now, but ships them in a private | path (so dpkg-shlibdeps doesn't find them and aborts). | So, I'm reading through far too many books/tutorials about libtool and | friends now just so that the libraries end up under /usr/lib. Octave's Makefile.am files have lines like octlib_LTLIBRARIES = liboctave.la octlib_LTLIBRARIES = liboctinterp.la so these files are installed in $(octlibdir) and the default definition of octlibdir is set in configure.ac to be '$(libdir)/octave/$(version)' You are of course free to redefine this to be '$(libdir)' instead, and I think that will cause the libraries to be installed into /usr/lib if you set $(prefix) to be /usr. jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603046: [Pkg-octave-devel] Bug#603046: Bug#603046: octave3.2: strchr triggers Octave:str-to-num
On 16-Nov-2010, Thomas Weber wrote: | strchr treats a string as a number implicitly: | | k...@raph:~/orion/svn/raph1/octave$ octave | GNU Octave, version 3.2.4 | | octave:1 warning error Octave:str-to-num | octave:2 strchr(Octave is the best software,best) | error: implicit conversion from string to real N-d array I don't see an error with the current development sources, so I think this problem has already been fixed. jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598059: [Pkg-octave-devel] Bug#598059: octave3.2: axis equal/square incorrect for gnuplot 4.4
On 26-Sep-2010, Yann Vernier wrote:
| Package: octave3.2
| Version: 3.2.4-7
| Severity: normal
|
|
| There is a bug in handling of 2d plots with Octave 3.2 and Gnuplot 4.4.
|
| I found that while axis equal or axis square change the plot, both
| on screen and in print, it does not calculate the ratios correctly.
| Whatever it is setting seems dependent on the window shape, which really
| should never affect the printout.
|
| Forcing __gnuplot_has_feature__(screen_coordinates_for_{lrtb}margin)
| to 0 fixes this problem. That variable appears to be intended to handle
| some change in gnuplot 4.3, which I am not aware of.
| Within __go_draw_axes__ that variable affects not only margin
| calculation but disables setting of gnuplot parameters origin and size.
| The variable also affects the axis command itself, as dataaspectratio
| seems to change format.
|
| axis equal and axis square should be equivalent to gnuplot set size
| ratio -1 and set size ratio 1 respectively.
|
| Additionally, there seems to be a developer note about this in
| __go_draw_axes__:
| ## FIXME -- nothing should change for gnuplot 4.2.x.
| Whoever wrote that probably has a better idea than I what's going on.
The right place to report a bug like this is the Octave bug tracker,
here:
https://savannah.gnu.org/bugs/?func=additemgroup=octave
jwe
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541251: [Pkg-octave-devel] Bug#541251: octave3.2-emacsen hanging at startup
On 12-Aug-2009, Pascal Dupuis wrote: | although there is close to no differences between octave3.0-emacsen | and octave3.2-emacsen, the 3.0 version works without any problems, | while with the 3.2, the message at bottom hangs indefinitelly at 'load | octave-inf'. The only cure is a 'kill -9' of emacs22. Just in case I | removed the octave3.0-emacsen, to keep only the 3.2 files, the problem | still persists. Should we even have an octave-emacsen package now that the Octave mode is distributed as part of GNU Emacs? jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570231: [Pkg-octave-devel] Bug#570231: octave3.2: Errors in working with complex matrices on i386
On 17-Feb-2010, Steven De Herdt wrote: | While working with complex matrices, I noticed strange things going on. | Some searching showed that there is definitely something wrong: | | octave3.2:2 a=orth(randn(3)); | octave3.2:3 a'*a | ans = | |1.e+00 -1.0742e-16 2.2264e-16 | -1.0742e-16 1.e+00 -3.1537e-17 |2.2264e-16 -3.1537e-17 1.e+00 | | octave3.2:4 b=orth(randn(3)+J*randn(3)); | octave3.2:5 b'*b | ans = | |1.06482 + 0.0i 0.10484 + 0.51574i 0.14882 + 0.71172i |0.10484 - 0.51574i 0.90395 + 0.0i -0.07914 + 0.08895i |0.14882 - 0.71172i -0.07914 - 0.08895i 1.06476 + 0.0i | | The result is Hermitian, but not quite unitary. | This also happens on octave3.0, but not on amd64 (either version). | | A look through Octave's own bug reports produces e.g. | http://old.nabble.com/wrong-output-for-complex-scalar-product-to26766409.html and | http://old.nabble.com/Wrong-results-for-svd-on-complex-numbers-to27079479.html , | so this kind of problem is not unheard of. | | Depending on one's needs, this may be an 'important' bug. I don't see this result on my system (Debian testing, amd64). I suspect a bug in the lapack package on your system. jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/19323.63820.271735.383...@segfault.lan
Bug#567975: [Pkg-octave-devel] Bug#567975: Bug#567975: FP error when filtering an empty vector
On 2-Feb-2010, Thomas Weber wrote: | Attached is a test case for this. No changelog entry, I don't think this | warrants one. I added one anyway. I also added a second test with the empty matrix being 1x0x2. Thanks, jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567962: [Pkg-octave-devel] Bug#567962: Bug#567962: needs to be rebuilt against libhdf5-1.8.4
On 1-Feb-2010, Thomas Weber wrote: | On Mon, Feb 01, 2010 at 03:59:25PM +0100, Bas Zoetekouw wrote: | Hi! | | octave-specfun is currently uninstallable in sid, as it depends on | libhdf5-1.8.3, while octave3.2 depends on libhdf5-1.8.4. | Please rebuild octave-specfun against libhdf5-1.8.4. | | Actually, on further inspection, it seems that there is no need at all | to link against libhdf (and zlib, and libfftw3, and libcurses5, etc). | The package itself doesn't use these symbols, so it shouldn't be linked | against them. | This seems to be an issue for all octave packages, BTW. | | Yes. mkoctfile (used to build these files) links them against all | libraries that Octave itself uses. I think this has changed in | upstream's development version, though. No, it hasn't changed. All .oct files depend on liboctinterp, which depends on liboctave and a number of other libraries, and liboctave depends on libcruft and a number of other libraries. So ultimately, a .oct file is linked with everything taht Octave is linked with. I don't see that it matters whether this is done directly or indirectly, and it seems to be that some systems cannot do the linking indirectly, so the dependencies are all listed when the .oct file is linked. If you have a better solution that is platform neutral and fits within the automake+libtool framework, then please start a thread on the maintain...@octave.org list. jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567975: [Pkg-octave-devel] Bug#567975: FP error when filtering an empty vector
On 1-Feb-2010, Bas Zoetekouw wrote: | Octave crashes when trying to filter() an empty vector: | | | octave:1 a=1; b=ones(10,1)/10; foo=filter(b,a,[]); | | panic: Floating point exception -- stopping myself... | | attempting to save variables to `octave-core'... | | save to `octave-core' complete | | zsh: floating point exception octave | | and I'm dropped back into the shell... | | Of course, filtering an empty vector doesnt make much sense, but it certainly | shouldn't cause a crash. | FWIT, Matlab simple returns an empty vector. | | -- System Information: | Debian Release: 5.0.4 | APT prefers stable | APT policy: (500, 'stable') | Architecture: amd64 (x86_64) | | Kernel: Linux 2.6.26-2-amd64 (SMP w/1 CPU core) | Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) | Shell: /bin/sh linked to /bin/bash I checked in the following change: http://hg.savannah.gnu.org/hgweb/octave/rev/a277ba5da4dc I'm not sure this fix places the return in exactly the right location. Should it be later in the function, after other dimension checks? It would be nice if someone who is more familiar with how filter is expected to work would comment. Also, in the future, please report bugs in Octave itself directly to the b...@octave.org mailing list and use the Debian bug reporting system for problems specific to the Debian package. Thanks, jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565136: [Pkg-octave-devel] Bug#565136: octave3.2: Function interp3.m not working.
On 13-Jan-2010, Jean-S bastien Kroll wrote:
|
| Branches 3.0 and 3.2 are affected by the same error. In the function
| interp3.m, there is a misplaced line break that has it not working at
| all.
|
| Following is the patch modifying the only line to be changed :
|
| --- /usr/share/octave/3.0.5/m/general/interp3.m 2009-10-12
21:05:55.0 +0200
| +++ ./interp3.m 2010-01-13 09:54:01.0 +0100
| @@ -82,7 +82,7 @@
| nargs = nargs - 2;
|endif
|
| - if (nargs 3 || (nargs == 4 ! isvector (varargin{1})
| + if (nargs 3 || (nargs == 4 ! isvector (varargin{1}) ...
|nargs == (ndims (varargin{1}) + 1)))
What failure is caused here? Octave doesn't require continuations
inside parens, so you should be able to write
if (some_long_variable_name == some_other_variable_name
some_other_condition)
without needing the explicit continuation. Exactly what error are you
seeing? Give us an example that demonstrates it.
Also, it is best to report generic bugs in Octave directly to the
b...@octave.org mailing list and use the debian bug reporting system
for packaging or Debian-specific problems.
jwe
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565216: [Pkg-octave-devel] Bug#565216: octave3.2: hdf5 failure with load()
On 13-Jan-2010, Francesco P. Lovergine wrote: | As reported in https://bugs.gentoo.org/show_bug.cgi?id=299876 also in | Debian octave there's a problem in hdf5 format management and that's | very unfortunate because hdf5 is quite an important format. It is best to report generic bugs in Octave directly to the b...@octave.org mailing list and use the debian bug reporting system for packaging or Debian-specific problems. Please include enough information in your report so that someone might have a chance to actually reproduce the error. For example, your report below is incomplete because it does not include a file that fails to load. Unless you can provide some code that will generate an unloadable file, then please include one. Please don't expect us to be able to guess how to generate a file that will not load properly. jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565216: [Pkg-octave-devel] Bug#565216: octave3.2: hdf5 failure with load()
On 14-Jan-2010, Francesco P. Lovergine wrote: | On Wed, Jan 13, 2010 at 06:19:58PM -0500, John W. Eaton wrote: | On 13-Jan-2010, Francesco P. Lovergine wrote: | | | As reported in https://bugs.gentoo.org/show_bug.cgi?id=299876 also in | | Debian octave there's a problem in hdf5 format management and that's | | very unfortunate because hdf5 is quite an important format. | | It is best to report generic bugs in Octave directly to the | b...@octave.org mailing list and use the debian bug reporting system | for packaging or Debian-specific problems. | | Please include enough information in your report so that someone might | have a chance to actually reproduce the error. For example, your | report below is incomplete because it does not include a file that | fails to load. Unless you can provide some code that will generate an | unloadable file, then please include one. Please don't expect us to | be able to guess how to generate a file that will not load properly. | | jwe | | A sample file is attached to the gentoo report and here enclosed. It is | correctly dumped by hdf5 tools. How did you create the file? Octave's load function is only designed to load HDF5 files created by Octave. There is no guarantee that it can load any and all arbitrary HDF5 files. If it loads anything else, then it was just luck. jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550823: Updating load-path cache based on modification times probably a bad idea (was: Race condition between Octave 3.2.3 and unlink())
On 20-Oct-2009, Judd Storrs wrote: | If we're already keeping track of when we last read a | directory/file, No, we were keeping track of the timestamp on the directory, and then re-reading the list of files if the timestamp changed. But that fails for a sequence like system (echo 1+1 foo.m); foo system (echo 2+2 bar.m); bar if the second call to system doesn't change the time stamp due to limited resolution. | wouldn't it be easiest to make the comparison know about the tolerance? i.e. | use something equivalent to | | if modtime + tolerance cachetime |reparse | endif | | Then when the file/directory is older than the tolerance full caching would | kick in? OK, this seems better than forcing all of the directories in the load path to be read again. So how about the following change? It seems to work for me. http://hg.savannah.gnu.org/hgweb/octave/rev/d6b2b708b6b0 jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550823: Updating load-path cache based on modification times probably a bad idea (was: Race condition between Octave 3.2.3 and unlink())
On 20-Oct-2009, Søren Hauberg wrote:
| tir, 20 10 2009 kl. 22:00 +0200, skrev Jaroslav Hajek:
| The problem is in load_path::update, which checks the directory's
| modification time to decide on whether to rescan it. The resolution is
| only in seconds, though.
It is possible to get better resolution, but only for filesystems that
support it. Currently, I'd guess that the most widely used filesystem
on Linux systems is probably ext3, and that only has one second
resolution for file time stamps.
| But some check is surely wanted because you
| want to avoid useless rescans. I don't have a better idea. One could
| even say this is a limitation of the system, which provides no way to
| tell whether the directory has changed during the last second. Maybe
| rehash() could ignore the stamp for some directories? But which ones?
|
| Perhaps it would be better to use a notification system instead of
| checking for file changes? Specifically, I'm thinking that we should be
| able to use, say, 'inotify' to notify us that a file has changed. When
| such a notification is sent Octave could then re-read the file. This
| would probably also be faster than the current approach of scanning for
| file changes.
I agree that being notified of changes would be better than checking
timestamps, but I don't think there is any portable way to be notified
when a file changes.
If possible, I'd rather avoid solutions that only work on some
systems.
The symbol table code already includes the following:
octave_value
symbol_table::fcn_info::fcn_info_rep::find (const octave_value_list args,
bool local_funcs)
{
octave_value retval = xfind (args, local_funcs);
if (! retval.is_defined ())
{
// It is possible that the user created a file on the fly since
// the last prompt or chdir, so try updating the load path and
// searching again.
load_path::update ();
retval = xfind (args, local_funcs);
}
return retval;
}
So if this is not sufficient, why not? Is it because update always
checks the time stamp? In that case, maybe we need to have a force
parameter to tell load_path::update to ignore the time stamp? That
would make this update operation slow, but it would only happen when a
symbol is not found the first time around, so I wouldn't expect it to
be a big problem.
jwe
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
On 16-Jun-2009, Rafael Laboissiere wrote: | * Rafael Laboissiere raf...@debian.org [2009-06-15 21:55]: | | * John W. Eaton j...@jweaton.org [2009-06-15 13:25]: | | On 15-Jun-2009, Rafael Laboissiere wrote: | | | Anyway, it is funny to see how long this bug lived in the code and was | | just awakened by the crappy mips/mipsel architecture... | | Also strange that it didn't show up until now, even on mips. Maybe a | compiler change? | | Probably. | | Anyway, these differences on floating point representation/manipulation | among the architectures make me kinda nervous. | | I am wondering whether we could add a regression test like the following | to data.cc (or wherever): | | /* | %!test | %! format short | %! for r = [0, Inf -Inf, NaN] | %! for i = [0, Inf -Inf, NaN] | %! complex (r, i) | %! endfor | %! endfor | */ | | Yes, the 'complex (r, i)' would lack the semicolon, just to exercise the | code in pr-output.cc. Are you sure you would want this? It won't tell you if the printing is correct without manual inspection, and will clutter the output from running make check with src/pr-output.cc ...ans = 0 + 0i ans =0 + Infi ans =0 - Infi ans =0 + NaNi ans = Inf + 0i ans = Inf + Infi ans = Inf - Infi ans = Inf + NaNi ans = -Inf + 0i ans = -Inf + Infi ans = -Inf - Infi ans = -Inf + NaNi ans = NaN + 0i ans = NaN + Infi ans = NaN - Infi ans = NaN + NaNi PASS1/1 Is there another way to test this without printing the output to the sreen? Maybe use fdisp to put the output in a file and then compare the contents of the file to some expected value? jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: [Pkg-octave-devel] Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
On 15-Jun-2009, Rafael Laboissiere wrote: | Attached below is a patch for pr-output.cc that makes Octave work as | expected for 'complex(NaN,0)' on mips (and amd64 as well, FWIW). The | package is being built right now on mips and on amd64 and, if everything | goes well on both arches, I will upload to unstable a new version of the | package, octave3.2_3.2.0-2, containing the patch. | | I am rushing with this because everything else is being held by this bug, | like the upload of the new octave-forge packages. | | -- | Rafael | | -- | --- a/pr-output.cc2009-06-15 08:48:48.0 +0200 | +++ b/pr-output.cc2009-06-15 11:28:58.0 +0200 | @@ -852,10 +852,12 @@ |double i_abs = ip 0.0 ? -ip : ip; | |int r_x = r_abs == 0.0 | -? 0 : static_castint (floor (log10 (r_abs) + 1.0)); | +? 0 : ((xisinf (rp) || xisnan (rp)) | +? INT_MIN : static_castint (floor (log10 (r_abs) + 1.0))); | |int i_x = i_abs == 0.0 | -? 0 : static_castint (floor (log10 (i_abs) + 1.0)); | +? 0 : ((xisinf (ip) || xisnan (ip)) | +? INT_MIN : static_castint (floor (log10 (i_abs) + 1.0))); | |int x_max, x_min; To be consistent with what is done int set_format (double, ...), I think this should be diff --git a/src/pr-output.cc b/src/pr-output.cc --- a/src/pr-output.cc +++ b/src/pr-output.cc @@ -851,10 +851,10 @@ double r_abs = rp 0.0 ? -rp : rp; double i_abs = ip 0.0 ? -ip : ip; - int r_x = r_abs == 0.0 + int r_x = (xisinf (rp) || xisnan (rp) || xr_abs == 0.0) ? 0 : static_castint (floor (log10 (r_abs) + 1.0)); - int i_x = i_abs == 0.0 + int i_x = (xisinf (ip) || xisnan (ip) || i_abs == 0.0) ? 0 : static_castint (floor (log10 (i_abs) + 1.0)); int x_max, x_min; Does that work for you? Similar changes may be needed in other functions in case all the elements of a matrix are NaN, for example. jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: [Pkg-octave-devel] Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
On 15-Jun-2009, Rafael Laboissiere wrote: | Anyway, it is funny to see how long this bug lived in the code and was | just awakened by the crappy mips/mipsel architecture... Also strange that it didn't show up until now, even on mips. Maybe a compiler change? jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: [Pkg-octave-devel] Bug#532656: Bug#532656: Bug#532656: Bug#532656: Bug#532656: Bug#532656: Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
On 11-Jun-2009, Rafael Laboissiere wrote: | * John W. Eaton j...@octave.org [2009-06-11 15:42]: | | Did you compile the simpler program with the same options used to | build Octave? | | Probably not. | | Can you run Octave under gdb and find where it hangs, either by | running | |log2 (complex (0, inf)) | | and interrupting it when the hang happens and getting a stack trace, | or by stepping through the log2 function (and the functions it calls) | to find where it hangs? | | When I run it through ./run-octave -g, the command above does not hang, | but gives immediately this, even when I set a breakpoint at log2: How did you set the breakpoint? You'll need to set it in Flog2 to stop in Octave's log2 function (the one that is callable from Octave scripts). | octave:1 log2 (complex (0, inf)) | | Program received signal SIGBUS, Bus error. | [Switching to Thread 0x2aad4d80 (LWP 11231)] | 0x2e17ae24 in std::num_putchar, std::ostreambuf_iteratorchar, std::char_traitschar ::_M_insert_floatdouble () from /usr/lib/libstdc++.so.6 | | Here is the stack: | | (gdb) bt | #0 0x2e17ae24 in std::num_putchar, std::ostreambuf_iteratorchar, std::char_traitschar ::_M_insert_floatdouble () from /usr/lib/libstdc++.so.6 | #1 0x2e17b048 in std::num_putchar, std::ostreambuf_iteratorchar, std::char_traitschar ::do_put () from /usr/lib/libstdc++.so.6 | #2 0x2e18fd44 in std::ostream::_M_insertdouble () from /usr/lib/libstdc++.so.6 | #3 0x2b04e65c in operator (o...@0x4328b0, pff=value optimized out) | at /usr/include/c++/4.3/ostream:214 | #4 0x2b054160 in pr_any_float (fmt=0x2bac0d40, o...@0x4328b0, d=2.2661800709135971, fw=0) | at pr-output.cc:1394 | #5 0x2b055ca4 in pr_complex (o...@0x4328b0, c=value optimized out, | r_fw=value optimized out, i_fw=0, scale=value optimized out) at pr-output.cc:1412 | #6 0x2b057a98 in octave_print_internal (o...@0x4328b0, c...@0x455cc8) at pr-output.cc:1958 Can you move to this frame and examine the value of C? So there is some problem printing the value? Maybe log2 is returning some invalid value. jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: [Pkg-octave-devel] Bug#532656: Bug#532656: Bug#532656: Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
On 11-Jun-2009, Rafael Laboissiere wrote:
| * Rafael Laboissiere raf...@debian.org [2009-06-11 16:07]:
|
| * Rafael Laboissiere raf...@debian.org [2009-06-11 01:08]:
|
| * Peter De Schrijver p...@debian.org [2009-06-10 19:40]:
|
|Package: octave3.2
|Version: 3.2.0-1
|Severity: serious
|
|There was an error while trying to autobuild your package:
|
| Automatic build of octave3.2_3.2.0-1 on mayr by sbuild/mips 99.999
| Build started at 20090607-1015
|
| Thanks, we are already aware of it. It also heppens on mipsel.
|
| I am currently investigating the problem using mahler.debian.org.
|
| I got the culprit. The test of data.cc never returns because the code below
| makes Octave 3.2.0 on mips (at least on mahler.debian.org) hangs forever:
|
| log2(complex(0,Inf))
|
| FWIW, the following works:
|
| octave:1 complex(0,Inf)
| ans = 0 + Infi
The log2 function is defined in src/data.cc. The relevant part is
if (args.length () == 1)
{
if (nargout 2)
retval(0) = args(0).log2 ();
which ultimately dispatches to
Complex
xlog2 (const Complex x)
{
#if defined (M_LN2)
static double ln2 = M_LN2;
#else
static double ln2 = log (2);
#endif
return std::log (x) / ln2;
}
So first, can you determine precisely where Octave is actually
hannging? Does the following program work, or does it also hang in
the same way?
#include cmath
#include complex
#include iostream
typedef std::complexdouble Complex;
Complex
xlog2 (const Complex x)
{
#if defined (M_LN2)
static double ln2 = M_LN2;
#else
static double ln2 = log (2);
#endif
return std::log (x) / ln2;
}
int
main (void)
{
std::complexdouble inf_i (0.0, 1.0/0.0);
std::cerr inf_i std::endl;
std::complexdouble result = xlog2 (inf_i);
std::cerr result std::endl;
return 0;
}
I expect this program to print:
(0,inf)
(inf,2.26618)
but if it hangs, then I think the problem is in the C++ or C library
functions, not Octave.
jwe
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532656: [Pkg-octave-devel] Bug#532656: Bug#532656: Bug#532656: Bug#532656: Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.
On 11-Jun-2009, Rafael Laboissiere wrote:
| * John W. Eaton j...@bevo.che.wisc.edu [2009-06-11 11:27]:
|
| So first, can you determine precisely where Octave is actually
| hannging? Does the following program work, or does it also hang in
| the same way?
|
|#include cmath
|#include complex
|#include iostream
|
|typedef std::complexdouble Complex;
|
|Complex
|xlog2 (const Complex x)
|{
|#if defined (M_LN2)
| static double ln2 = M_LN2;
|#else
| static double ln2 = log (2);
|#endif
|
| return std::log (x) / ln2;
|}
|
|int
|main (void)
|{
| std::complexdouble inf_i (0.0, 1.0/0.0);
| std::cerr inf_i std::endl;
| std::complexdouble result = xlog2 (inf_i);
| std::cerr result std::endl;
| return 0;
|}
|
| I expect this program to print:
|
|(0,inf)
|(inf,2.26618)
|
| but if it hangs, then I think the problem is in the C++ or C library
| functions, not Octave.
|
| No, it does not hang, but produces the following:
|
| (0,inf)
| (nan,nan)
|
| On my Debian sid chroot on amd64, it produces:
|
| (0,inf)
| (inf,nan)
Did you compile the simpler program with the same options used to
build Octave?
Can you run Octave under gdb and find where it hangs, either by
running
log2 (complex (0, inf))
and interrupting it when the hang happens and getting a stack trace,
or by stepping through the log2 function (and the functions it calls)
to find where it hangs?
jwe
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530858: [Pkg-octave-devel] Bug#530858: octave3.0: Unable to write files bigger than 2Go
On 28-May-2009, David Kremer wrote: | My system is unable to write file bigger than 2Go with octave on | i386 platform. | | A script to reproduce it : | | %% octave script %% | fd = fopen( test.bin , wb ) ; | for k = [ 1:300 ] | fwrite( fd , randn(1024,1024) , double); | end ; | fclose( fd ) ; | | ls -lh | %% end of script %% | | The file should be bigger than 2Go, but his size remains 2Go. This is a known problem, and isn't really something that the people making packages for Debian are likely to fix. jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528230: [Pkg-octave-devel] Bug#528230: Bug#528230: Bug#528230: Processed: Re: Bug#528230: Error in Octaviz.
On 11-May-2009, Thomas Weber wrote: | On Mon, May 11, 2009 at 10:33:13PM +0200, Rafael Laboissiere wrote: | * Thomas Weber thomas.weber.m...@gmail.com [2009-05-11 20:25]: | | On Mon, May 11, 2009 at 04:24:04PM +, Debian Bug Tracking System wrote: |Bug#528230: Error in Octaviz. |Warning: Unknown package 'octaviz.' |Bug reassigned from package `octaviz.' to `octaviz'. | | Okay, I guess the time has come to decide on Octaviz' future. Last time | I tried, it didn't compile against VTK 5.2. | | Candidate for removal? | | Probably, yes. | | There is a non-negligible amount of octaviz users, though: | http://qa.debian.org/popcon.php?package=octaviz | | Then they should get up and get the software in shape. Yes, bad | response, but what else should I say? We are just the messengers of the | bad news. Before removing it, would you consider posting a message to the h...@octave.org list asking whether anyone (or group) would like to start maintaining it? Maybe the message should also go to the maintain...@octave.org and octave-...@lists.sourceforge.net lists. OTOH, maybe we should just let it die and try to get more effort put into the OpenGL-based graphics code for core Octave. jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525113: [Pkg-octave-devel] Bug#525113: Bug#525113: Bug#525113: Inconsistant complex matrix multiplication
On 23-Apr-2009, Rafael Laboissiere wrote: | * Thomas Weber thomas.weber.m...@gmail.com [2009-04-22 23:04]: | | On Wed, Apr 22, 2009 at 12:01:19PM +0200, Laurent Mazet wrote: | Package: octave3.0 | Version: 1:3.0.1-7 | Arch: i386 | Severity: grave | | Hi, | | I've just realized that I can multiply a real 2x2 matrix by a complex vector. | | Uh, yes. Why shouldn't this work? Or in other words, how do you | distinguish the real matrix from a complex matrix with its complex | coefficients being zero | | [ 1, 2; 3,4] is the same as [1+0i, 2+0i; 3+0i, 4+0i], isn't it? | | I think Laurent meant I've just realized that I CANNOT multiply [...] And the multiplication appeared to work, but gave the wrong answer. I don't remember this bug, but I can't duplicate it now on my system. If it wasn't a bug that was fixed in Octave, then I'd guess it was a BLAS bug? Octave just uses BLAS to perform these mutliplications. jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523042: [Pkg-octave-devel] Bug#523042: octave3.0: loading a datafile skips every second line
On 9-Apr-2009, Drew Parsons wrote: | Hi Rafael, thanks for the forthcoming fix to the problem. | | About the severity, I appreciate you need to get the new version across | to testing but I don't think I could justify it with this bug. I agree that we should limit the spread of 3.0.4 as much as possible. 3.0.5 is now available (there is just one patch applied to 3.0.4 to fix this bug) so it would seem to me that it is better to generate the 3.0.5 package and upload that instead, and do whatever we can to keep 3.0.4 from being used by anyone. Thanks, jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516136: [Pkg-octave-devel] Bug#516136: Bug#516136: Bug#516136: octave3.1: crash
On 20-Feb-2009, Francesco Potorti` wrote: | Well, it is much simpler than I expected, you do not need to load any | data. This is what I observe: | | | error: fclose: invalid stream number = -1 | error: called from: | error: /usr/share/octave/3.1.52/m/pkg/pkg.m at line 365, column 1 | error: /usr/share/octave/3.1.52/m/startup/octaverc at line 27, column 1 | octave3.1 | octave3.1 r=0; | octave3.1 rs | octave3.1 system touch rs.m; | octave3.1 rs | panic: impossible state reached in file `pt-bp.cc' at line 171 | panic: Aborted -- stopping myself... | attempting to save variables to `octave-core'... | save to `octave-core' complete | I checked in the following change. Does it fix the problem for you? http://hg.savannah.gnu.org/hgweb/octave/rev/71742f45571e jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515962: [Pkg-octave-devel] Bug#515962: octave3.0-emacsen: octave mode does not respect tab-width
On 18-Feb-2009, Vladimir Z wrote: | Package: octave3.0-emacsen | Version: 1:3.0.1-6lenny3 | Severity: normal | | The octave mode does respect user's tab-width variable. | in octave-mode.el: | | (defcustom octave-block-offset 2 | Extra indentation applied to statements in Octave block structures. | :type 'integer | :group 'octave) | | 2 should be tab-width, I believe. Looking at other Emacs programming modes, I don't see that this is the common way to define indentation widths, so I don't see why Octave mode should do it. BTW, are you setting tab-width to something other than 8? I think that is almost always the wrong thing to do, because then if you share your files with someone else who doesn't know what your special tab-width setting is, the file will likely look garbled. jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515962: [Pkg-octave-devel] Bug#515962: [Fwd: Re: Bug#515962: octave3.0-emacsen: octave mode does not respect tab-width]
On 18-Feb-2009, Vladimir Zhuravlev wrote: | I set tab-width to 8, but Octave mode does not care about this. | Then I tell it to indent (say, M-C-q), it uses tabs of two | spaces, | which is _not_ nice. It's not that unfriendly, and it seems to be the same way other modes define indents. They don't seem to be doing it with tab-width either. So maybe you should ask the Emacs developers why? I don't know, I think Kurt just followed the lead of the other modes when he first wrote the Octave mode. jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514802: [Pkg-octave-devel] Bug#514802: Bug#514802: Bug#514802: octave-symbolic: (un)install accesses user .octave_hist
On 12-Feb-2009, Thomas Weber wrote: | Am Mittwoch, den 11.02.2009, 17:55 +0100 schrieb Rafael Laboissiere: | * Thomas Weber thomas.weber.m...@gmail.com [2009-02-11 13:34]: | | I don't think so. Seems to me like octave is accessing .octave_hist | despite the --no-history flag. Snippet from | $ strace -f octave --no-history | | open(/home/weber/.octave_hist, O_RDONLY) = 3 | open(/home/weber/.octave_hist, O_WRONLY|O_CREAT|O_TRUNC, 0600) = 3 | | I seem to remember that this came up once already, but can't find it | currently. | | Is this an upstream bug? | | If it's a bug, yes. It seems that --no-history only influences the | saving of the new command at the end of an Octave session. | | Then again, it seems logical to read it, so you can scroll the history | of past commands. I'm not sure that fixing the current corner-case of | non-readable .octave_hist file is worth the effort. The option --no-history is supposed to mean no history at all. What I see is that the history file is not read, and commands are not saved to the history list, but then the history (an empty list) is still saved to the history file when Octave exits, wiping out whatever was there before. I checked in the following change. Thanks, jwe # HG changeset patch # User John W. Eaton j...@octave.org # Date 1234548184 18000 # Node ID afbfd7f4fd931c9460102aec3eb073f78839276e # Parent 767ed8cc6634851b239e3b181fa18fd7984c2678 toplev.cc (do_octave_atexit): only save history if Vsaving_history is true diff --git a/src/ChangeLog b/src/ChangeLog --- a/src/ChangeLog +++ b/src/ChangeLog @@ -1,3 +1,8 @@ +2009-02-13 John W. Eaton j...@octave.org + + * toplev.cc (do_octave_atexit): Only save history if + Vsaving_history is true. + 2009-02-12 John W. Eaton j...@octave.org * data.cc, ov-base-diag.h, ov-base-mat.h, ov-base-scalar.h, diff --git a/src/toplev.cc b/src/toplev.cc --- a/src/toplev.cc +++ b/src/toplev.cc @@ -984,7 +984,8 @@ octave_history_write_timestamp (); - command_history::clean_up_and_save (); + if (Vsaving_history) + command_history::clean_up_and_save (); close_files ();
Bug#514802: [Pkg-octave-devel] Bug#514802: Bug#514802: Bug#514802: Bug#514802: Bug#514802: octave-symbolic: (un)install accesses user .octave_hist
On 13-Feb-2009, Rafael Laboissiere wrote: | * John W. Eaton j...@octave.org [2009-02-13 13:06]: | | The option --no-history is supposed to mean no history at all. What I | see is that the history file is not read, and commands are not saved | to the history list, but then the history (an empty list) is still | saved to the history file when Octave exits, wiping out whatever was | there before. | | I see that this bug affects the 3.1 branch. It seems that it is not the | case for the 3.0 branch. Could you please confirm? What I see with 3.0.3 is that it reads and writes the history file even with --no-history. So that is still wrong, but doesn't have the bad effect of truncating the history file as happens with the 3.1.x sources prior to the patch I checked in earlier today. jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504945: [CHANGESET] Fix compilation with g++ 4.4
On 8-Nov-2008, Rafael Laboissiere wrote: | package octave3.0 | tags 504945 upstream | found 504945 3.0.3-1 | thanks | | The patch attached below fixes Bug#504945 [1] reported against the | octave3.0 Debian package. I confirm that the patch fixes the compilation | with g++ 4.4 of both versions 3.0.3 and 3.1.51. I applied this changeset. | The bug report also mention a failure to generate liboctinterp.so due to an | undefined reference to `std::ctypechar::_M_widen_init'. I did not | investigate this issue. | | [1] http://bugs.debian.org/504945 Octave doesn't use _M_widen_init directly, so I suspect it is not a bug in Octave. But if this is still an issue and possibly a bug in Octave instead of GCC, will you please send another report? Thanks, jwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#492993: (no subject)
On 30-Jul-2008, Francesco Potorti` wrote: | package octave3.0 | tags 492993 upstream | stop | | Dear Octave maintainers, | | The bug report reproduced below has been filed against the Debian | package and regards the upstream sources. The report is recorded at | http://bugs.debian.org/492993 | | | Package: octave3.0 | Version: 1:3.0.1-4 | Severity: minor | | This is a proposed rewrite for the docs contained in the Axes Properties | manual page. | | 1) all of the properties should be included in the index. Which index? It doesn't seem appropriate to add them to any of the existing indices (concepts, variables, functions, operators). It seems strange to me to create a new index for graphics properties alone since they are already presented in itemized lists in the manual. What does an index entry add? I did add index entries for some more graphics concepts: @cindex root figure graphics object @cindex graphics object, root figure @cindex figure graphics object @cindex graphics object, figure @cindex axes graphics object @cindex graphics object, axes @cindex line graphics object @cindex graphics object, line @cindex text graphics object @cindex graphics object, text @cindex image graphics object @cindex graphics object, image @cindex patch graphics object @cindex graphics object, patch @cindex surface graphics object @cindex graphics object, surface @cindex graphics object properties @cindex figure properties @cindex axes properties @cindex line properties @cindex text properties @cindex image properties @cindex patch properties @cindex surface properties @cindex default graphics properties @cindex graphics properties, default @cindex graphics colors @cindex colors, graphics @cindex line styles, graphics @cindex graphics line styles @cindex graphics marker styles @cindex marker styles, graphics @cindex callbacks @cindex object groups @cindex data sources in object groups @cindex series objects @cindex area series @cindex series objects @cindex bar series @cindex series objects @cindex contour series @cindex series objects @cindex error bar series @cindex series objects @cindex line series @cindex group objects @cindex quiver group @cindex group objects @cindex scatter group @cindex group objects @cindex stair group @cindex group objects @cindex surface group @cindex graphics backends @cindex backends, graphics @cindex gnuplot interaction | 2) position should read: | A vector specifying the position of the plot, excluding titles, | axes and legend. The four elements of the vector are the | coordinates of the lower left corner and width and height of the | plot, in units normalized to the window width and height. For | example, `[0.2, 0.3, 0.4, 0.5]' sets the lower left corner of the | axes at (0.2, 0.3) and the width and height to be 0.4 and 0.5 | respectively. See *outerposition* | | 3) outerposition should read: | A vector specifying the position of the plot, including titles, | axes and legend. The four elements of the vector are the | coordinates of the lower left corner and width and height of the | plot, in units normalized to the window width and height. For | example, `[0.2, 0.3, 0.4, 0.5]' sets the lower left corner of the | axes at (0.2, 0.3) and the width and height to be 0.4 and 0.5 | respectively. See *position* I made these changes. Thanks, jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492992: (no subject)
On 30-Jul-2008, Francesco Potorti` wrote: | package octave3.0 | tags 492992 upstream | stop | | Dear Octave maintainers, | | The bug report reproduced below has been filed against the Debian | package and regards the upstream sources. The report is recorded at | http://bugs.debian.org/492992 | | Thanks, | | Package: octave3.0 | Version: 1:3.0.1-4 | Severity: normal | | The index of the manual does not contain the varargin keyword. Fixed. Thanks, jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492078: octave3.0: cannot change axes location in pcolor
On 27-Jul-2008, David Bateman wrote: | Francesco Potorti` wrote: | package octave3.0 | tags 492078 upstream | stop | | Dear Octave maintainers, | | The bug report reproduced below has been filed against the Debian | package and regards the upstream sources. The report is recorded at | http://bugs.debian.org/492078 | | Thanks, | | Package: octave3.0 | Version: 1:3.0.1-4 | Severity: normal | | octave pcolor(1:2,3:4,[5 6;7 8]) | octave set(gca, xaxislocation, top)# X axis disappears | octave set(gca, xaxislocation, bottom) # X axis reappears | octave set(gca, xaxislocation, top)# X axis disappears | octave set(gca, xaxislocation, bottom) # X axis reappears | octave set(gca, yaxislocation, right) # Y axis disappears | octave set(gca, yaxislocation, left)) # Y axis reappears | | | | Ok this is a real bug and is present in both 3.0.1+ and 3.1.51+. The fix | is not immediately obvious to me, but if no one else looks at this, I'll | try to fix it in the next couple of days. Did you have a chance to look at this? I don't see how to make the x2 tic labels appear in a plot like this. The pcolor plot uses splot, and the following set view map set x2tics splot x+y does not display the x2 tic labels. I am able to control the x and y tics, but not the x2 and y2 tics. That looks like it might be a bug in gnuplot. I'm using 4.2.2. Can someone check with the current gnuplot development sources? Thanks, jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492078: octave3.0: cannot change axes location in pcolor
On 22-Aug-2008, Dmitri A. Sergatskov wrote: | On Fri, Aug 22, 2008 at 1:02 PM, John W. Eaton [EMAIL PROTECTED] wrote: | | ... | | set view map | set x2tics | splot x+y | | does not display the x2 tic labels. I am able to control the x and y | tics, but not the x2 and y2 tics. That looks like it might be a bug | in gnuplot. I'm using 4.2.2. Can someone check with the current | gnuplot development sources? | | | I do not see any difference between 4.2.2 and current cvs versions. | But I also think this is a feature -- x2tics (and y2tics) are applicable to | 2-d plotting (note there is no z2tics) and splot is a 3-d plot. OK. Can we use plot instead of splot in this case? If not, then I think there is no way to make this feature work properly with the gnuplot backend unless gnuplot itself is fixed. jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492168: octave3.0: shading doc unclear and poor default shading
On 27-Jul-2008, David Bateman wrote: | Michael Goffioul wrote: | On Sun, Jul 27, 2008 at 2:33 AM, David Bateman [EMAIL PROTECTED] wrote: | I'm not that much on an expert on the graphics code and what its | supposed to do, so don't really know the best clarification for this. If | you have any suggestions for how this text might be clarified then the | suggested changes would be appreciated. | | faceted: edges visible, flat color | flat: edges invisible, flat color | interp: edges invisible, interpolated color | | Michael. | | I was kind of trying to cop out on supplying a changeset. Oh well what | about the attached then? I applied this patch. Thanks, jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492070: octave3.0: about axes properties in the manual
On 27-Jul-2008, David Bateman wrote: | Francesco Potorti` wrote: | package octave3.0 | tags 492070 upstream | stop | | Dear Octave maintainers, | | The bug report reproduced below has been filed against the Debian | package and regards the upstream sources. The report is recorded at | http://bugs.debian.org/492070 | | Thanks, | | Version: 1:3.0.1-4 | Severity: minor | | About the Axes Properties page of the manual: I read exactly the same | description for both the position and outerposition properties. | | | Effectively. The difference is the Position is the dimensions of the | plot window itself and OuterPosition is the same including the axes | labels, tics, etc.. I attach a changeset with a minor clarification of | this.. I applied this changeset. Thanks, jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492224: octave3.0: contourf is not documented
On 27-Jul-2008, David Bateman wrote: | Francesco Potorti` wrote: | package octave3.0 | tags 492224 upstream | stop | | Dear Octave maintainers, | | The bug report reproduced below has been filed against the Debian | package and regards the upstream sources. The report is recorded at | http://bugs.debian.org/492224 | | Thanks, | | Version: 1:3.0.1-4 | Severity: minor | | The manual does not mention contourf. | | | Changeset attached I applied it. Thanks, jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492223: octave3.0: contourf only accepts vector X and Y if same
On 27-Jul-2008, David Bateman wrote: | Francesco Potorti` wrote: | package octave3.0 | tags 492223 upstream | stop | | Dear Octave maintainers, | | The bug report reproduced below has been filed against the Debian | package and regards the upstream sources. The report is recorded at | http://bugs.debian.org/492223 | | Thanks, | | | Package: octave3.0 | Version: 1:3.0.1-4 | Severity: normal | File: /usr/share/octave/3.0.1/m/plot/contourf.m | | Contourf works with X and Y generated by meshgrid. | It also works with vector X and Y of the same size. | It fails if vector X and Y are of different size. | | octave x=1:5;y=x;z=vander(x);contourf(x,y,z,4) | octave x=1:5;y=x(1:end-1);z=vander(x)(1:end-1,:); | octave contourf(x,y,z,4) | error: patch: X and Y must be of same size | error: evaluating if command near line 230, column 3 | error: called from `contourf:parse_args' in file `/usr/share/octave/3.0.1/m/plot/contourf.m' | error: called from `contourf' in file `/usr/share/octave/3.0.1/m/plot/contourf.m' | octave [xx,yy]=meshgrid(x,y);contourf(xx,yy,z,4) | | | | Ok, changeset attached I applied it. Thanks, jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477688: [Pkg-octave-devel] Bug#477688: Bug#477688: [octave3.0] print()'ing a figure with title or (x|y)labels fails with gdImageStringFT error
On 29-Apr-2008, Thomas Weber wrote:
| On 29/04/08 17:18 +0200, Didier Raboud wrote:
| Le mardi, 29 avril 2008 17.08:04 Thomas Weber, vous avez écrit :
| I get the warnings as well, but my plot contains the labels (maybe in a
| different font, I don't know).
|
| Thomas
|
| The plot itself contains the labels, but the saved version does not (for
me).
|
| I see.
|
| Okay, two questions:
| 1) Do you actually have the font Helvetica? Unless you paid for it, I
| doubt that, as it doesn't seem to be freely available.
|
| 2) Do you actually care about the font being Helvetica?
|
| As the answer to question 2 is probably no, here you go:
|
| a) Set GDFONTPATH in your shell to a directory that contains the font
| you want to use, in my case
| export GDFONTPATH=/usr/share/fonts/truetype/msttcorefonts
| b) Start Octave and give the font type explicitely:
|
| figure;
| plot(1:2,1:2);
| xlabel('Label X', 'FontName', 'Arial');
| ylabel('Label Y', 'FontName', 'Arial');
| title('Title', 'FontName', 'Arial');
| legend('Blue Line');
|
| print('/tmp/testcase.png');
You may also specify a default font for all labels by setting a
default property in the root figure:
set (0, 'defaulttextfontname', 'Arial');
Then you do not need to specify individually in each text object.
jwe
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472069: [Pkg-octave-devel] Bug#472069: Bug#472069: octave3.0: plotyy leaves remains on future graphs
On 28-Mar-2008, David Bateman wrote: | Hey, I didn't look at the bug tracker, it was me who answered Tom on | comp.soft-sys.octave, Are you the only person who reads that? Should we maybe regularly post a mini-FAQ there that says Don't judge the level of interest in Octave by the level of activity on this newsgroup. Please check out and use the Octave mailing lists instead.? jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472069: [Pkg-octave-devel] Bug#472069: Bug#472069: octave3.0: plotyy leaves remains on future graphs
On 28-Mar-2008, David Bateman wrote: | Sure I'd suggest sending a message to this list with a title like Read | this before posting to this group and give the mailing lists and Nabble | archives as the suggested means of support. OK. I'll draft something and see if I can figure out how to post it from a cron job. | PS. The mail to [EMAIL PROTECTED] in debian bug 471273 didn't get | through to the maintainers lists. I don't know what happened. I don't see any messages in the moderator queue for the list. jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418158: [Pkg-octave-devel] Bug#418158: Bug#418158: Bug#418158: more info
On 29-Feb-2008, Rafael Laboissiere wrote: | * Rafael Laboissiere [EMAIL PROTECTED] [2008-02-24 18:23]: | | * Ólafur Jens Sigurðsson [EMAIL PROTECTED] [2008-02-24 12:34]: | | I just tried some values and the limit seems to be poisscdf(604,604), | after that the function fails, that is poisscdf(605,605) fails and | poisscdf(604,604) succeeds. | | It fails for smaller values than that, like poisscdf (599, 600). The | culprit is the gammainc function, which ultimately calls the function | defined in d9lgit.f. | | Just for the record, the gamma_inc_P function in the gsl octave-forge | package works fine in the range for which gammainc from d9lgit.f fails. For | instance: | | octave:1 gamma_inc_P (1e5,1e5) | ans = 0.50042 | | John, is there any chance of integrating GSL directly in Octave? At least | making the compilation in files like gammainc.cc conditional on the presence | of libgsl and, if not, falling back to Slatec. Yes, but maybe not until after 3.1 is released unless someone shows up with a patch. jwe
Bug#461558: [Pkg-octave-devel] Bug#461558: octave fails to invoke gnuplot
On 14-Feb-2008, Folkert van Heusden wrote: | Just tried 3.0 and it gives the same errors: | gnuplot set terminal aqua 1 enhanced | ^ |line 0: unknown or ambiguous terminal type; type just 'set terminal' for a list | | | gnuplot plot - using ($1):($2) axes x1y1 title with lines linestyle 1 ; | ^ |line 0: use 'set term' to set terminal type first | | Have you by any chance set the environment variable GNUTERM? What does the | follow yield for you? | | $ echo $GNUTERM | $ GNUTERM=x11 /usr/bin/octave3.0 -qf | octave:1 plot (randn (10, 1)); | | Tried it under X11 and then things work. So it seems X11 is required for | it to run. I thought and hoped it would emit a png/gif/jpg-file. | So the bug can be closed. To generate graphics files without displaying them on the screen, try something like figure (1, 'visible', 'off'); plot (randn (10, 1)); print -dpng foo.png jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434415: [EMAIL PROTECTED]: [Pkg-octave-devel] Bug#434415: octave2.9-headers: Changed F77_FUNC_ macro]
On 24-Jul-2007, Thomas Weber wrote: | Am Montag, 23. Juli 2007 22:12:14 schrieb Rafael Laboissiere: | - Forwarded message from Kim Hansen [EMAIL PROTECTED] - | | From: Kim Hansen [EMAIL PROTECTED] | Subject: [Pkg-octave-devel] Bug#434415: octave2.9-headers: Changed | F77_FUNC_ macro | Date: Mon, 23 Jul 2007 19:51:13 +0200 | To: Debian Bug Tracking System [EMAIL PROTECTED] | Reply-To: Kim Hansen [EMAIL PROTECTED], [EMAIL PROTECTED] | Message-ID: [EMAIL PROTECTED] | | Package: octave2.9-headers | Version: 1:2.9.12-2+b3 | Severity: normal | | | I don't know if this is a real bug, but between version 2.9.10-4.1 and | 1:2.9.12-2+b3 has the definition of the macro F77_FUNC_ in | /usr/include/octave/config.h changed from |#define F77_FUNC_(name,NAME) name ## _ | to |#define F77_FUNC_(name,NAME) name ## __ | | If I read the output of | cvs annotate configure.in | correctly, John hasn't touched these lines for about 5 years. Could this be | caused by our (=Debian) current mixture of g77 and gfortran? If you mean these lines in the generated config.h file: /* Define to a macro mangling the given C identifier (in lower and upper case), which must not contain underscores, for linking with Fortran. */ #define F77_FUNC(name,NAME) name ## _ /* As F77_FUNC, but for C identifiers containing underscores. */ #define F77_FUNC_(name,NAME) name ## __ then the definition depends on the Fortran compiler (the definition is generated by autoconf). The doubled underscore suffix for names that already contain an underscore was a convention used by f2c and copied by other Unix Fortran 77 compilers including g77. I guess gfortran does not use the same convention. If you mean these lines: #if defined(HAVE_F2C) !defined(F77_FUNC) # define F77_FUNC(name,NAME) name ## _ # define F77_FUNC_(name,NAME) name ## __ #endif Then I don't think they should change. In any case, we probably need to think about how to avoid installing the generated config.h. We may still need a subset of that file installed, but it should probably have a different name. jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418503: [Pkg-octave-devel] Bug#418503: octave2.9: Must not enter testing
On 10-Apr-2007, Thomas Weber wrote: | Package: octave2.9 | Version: 2.9.10-4 | Severity: grave | Justification: renders package unusable | | Octave 2.9.10 doesn't play well with the current octave2.9-forge packages in | Debian, so it shouldn't enter testing in the current state. I think this is unfortunate since Octave is useful on its own without Octave Forge and I think 2.9.10 is much better than 2.9.9. Also, for those who must have some or all of Octave Forge, there is now a way to install it using Octave's pkg function. jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417487: [Pkg-octave-devel] Bug#417487: FTBFS with GCC 4.3: missing #includes
On 3-Apr-2007, Martin Michlmayr wrote: | * Rafael Laboissiere [EMAIL PROTECTED] [2007-04-02 23:48]: | Does 2.9.10-3, the version currently in unstable also fail in the same | way? | | Yes, it does. Hopefully I'll be able to send a patch tomorrow or the | day after. I installed the gcc-snapshot package and cleaned up a few things so I think the current CVS sources should build with the current snapshot of GCC 4.3 now. Thanks, jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417486: [Pkg-octave-devel] Bug#417486: FTBFS with GCC 4.3: missing #includes
I expect that some 2.9.x version of Octave will be declared the recommended version of Octave before GCC 4.3 (or maybe even GCC 4.2) is released, so I don't have any plans to fix these problems in my 2.1.x sources. You're of course free to fix them in the Debian packages. I'd be much more interested in whether Octave 2.9.10 builds cleanly with GCC 4.2 and 4.3. jwe On 2-Apr-2007, Martin Michlmayr wrote: | Package: octave2.1 | Version: 1:2.1.73-13 | Usertags: ftbfs-gcc-4.3 | | Your package fails to build with GCC 4.3. Version 4.3 has not been | released yet but I'm building with a snapshot in order to find errors | and give people an advance warning. In GCC 4.3, the C++ header | dependencies have been cleaned up. The advantage of this is that | programs will compile faster. The downside is that you actually | need to directly #include everything you use (but you really should | do this anyway, otherwise your program won't work with any compiler | other than GCC). Some background of this can be found at | http://gcc.gnu.org/PR28080 | | You can reproduce this problem with gcc-snapshot (20070326-1 or higher) | from unstable. I'll try to look into this problem but I don't know when | I'll have time. | | | Automatic build of octave2.1_1:2.1.73-13 on coconut0 by sbuild/ia64 0.49 | ... | /usr/bin/g++ -c -fPIC -I. -I.. -I../liboctave -I../src -I../libcruft/misc -DHAVE_CONFIG_H -Wall -W -Wshadow -O2 data-conv.cc -o pic/data-conv.o | data-conv.cc: In static member function 'static void oct_data_conv::string_to_data_type(const std::string, int, oct_data_conv::data_type, oct_data_conv::data_type)': | data-conv.cc:280: error: 'atoi' was not declared in this scope | data-conv.cc: In static member function 'static void oct_data_conv::string_to_data_type(const std::string, int, oct_data_conv::data_type)': | data-conv.cc:344: error: 'atoi' was not declared in this scope | make[3]: *** [pic/data-conv.o] Error 1 | make[3]: Leaving directory `/build/tbm/octave2.1-2.1.73/liboctave' | | -- | Martin Michlmayr | http://www.cyrius.com/ | | | ___ | Pkg-octave-devel mailing list | [EMAIL PROTECTED] | http://lists.alioth.debian.org/mailman/listinfo/pkg-octave-devel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416046: octave2.9: pathdef doesn't include dir with info-emacs-info and info-emacs-octave-help
On 28-Mar-2007, Rafael Laboissiere wrote: | package octave2.9 | tags 416046 = upstream patch | thanks | | I am forwarding below a bug report filed against the octave2.9 package in | Debian. The full context can be seen at the Debian BTS [1]. The bug | reporter is correctly complaining that the docs are outdated regarding the | old built-in variables LOADPATH, INFO_FILES, and INFO_PROGRAM. Please, | consider the attached patch against the CVS sources, in which I tried to | chase down all the references to the variables above. I applied the patch. | Changelog entries are also provided. Diffs to ChangeLog files rarely apply cleanly, so rather than sending diffs for them, it is more helpful if you extract them from your files and send them without the diff markup. Thanks, jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416431: octave2.9-emacsen: replace gnudoit by gnuclient in wrapper scripts
On 29-Mar-2007, Rafael Laboissiere wrote: | * John W. Eaton [EMAIL PROTECTED] [2007-03-29 10:55]: | | On 28-Mar-2007, Rafael Laboissiere wrote: | | | package octave2.9-emacsen | | tags 416431 upstream patch | | thanks | | | | The bug report below was filed against the octave2.9 package in Debian. | | Full context is found in the Debian BTS [1]. Please consider the patch | | attached below, which fixes the problem. | | I applied this patch. | | I reviewed your changes in CVS. Unfortunately, the scripts do not work for | me. I am using Emacs 21.4 and gnuserv 3.12.7. When I type: | | $ cd /tmp | $ emacs -eval (gnuserv-start) | $ octave2.9 -q | octave2.9:1 info_program (info-emacs-info) | octave2.9:2 doc | | a gnuclient window pops up but no info file is loaded. Instead, a bunch of | buffers are created, as seen in the output of C-x C-b: | | MR Buffer Size Mode File | -- -- | . Top) 0 Fundamental /tmp/Top) | octave2.9.info 0 Fundamental /tmp//usr/share/info/octave2.9.info | (Info-find-node 0 Fundamental /tmp/(Info-find-node | info) 0 Fundamental /tmp//usr/share/info) | 'Info-directory-list 0 Fundamental/tmp/'Info-directory-list | (add-to-list0 Fundamental /tmp/(add-to-list | 'info) 0 Fundamental /tmp/'info) | (require0 Fundamental /tmp/(require | | | Using this instead (as in my original patch): | | gnuclient -batch -q -eval $cmd | | fixes the problem. Oops. I think it is fixed now. jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394982: [Pkg-octave-devel] Bug#394982: octave2.9: Crashes on x(:,
On 26-Oct-2006, David Bateman wrote: | Ok then use the attached patch in addition to the previous patch... It | essentially removes the previous patch and does it differently. | | Note that this is still a very bad idea as it reallocates the memory to | the sparse matrix and every assignment, even if you size the initial | matrix correctly. This is due to the fact that only enough space for the | nonzeros is ever created... I'd therefore highly recommended forming | vectors of row, col and value and use the sparse function instead. This | is discussed in the sparse section of the manual I applied the patch and now I see octave:5 x = sparse (2,0) x = Compressed Column Sparse (rows = 2, cols = 0, nnz = 0) octave:6 x(:,1:2) = speye (2) x = 1 0 0 1 octave:7 x(:,3:4) = speye (2) x = 1 0 1 0 0 1 0 1 so it seems OK, but what is happening here: octave:1 x = sparse (2,0) x = Compressed Column Sparse (rows = 2, cols = 0, nnz = 0) octave:2 x(:,2,3) = speye (2) error: A(I, J) = X: can only have 1 or 2 indexes for sparse matrices error: assignment failed, or no method for `sparse matrix = sparse matrix' error: evaluating assignment expression near line 2, column 10 octave:2 x x = Compressed Column Sparse (rows = 2, cols = 0, nnz = 0) octave:3 x(:,1:2) = speye (2) error: A(I, J) = X: can only have 1 or 2 indexes for sparse matrices error: assignment failed, or no method for `sparse matrix = sparse matrix' error: evaluating assignment expression near line 3, column 10 The command on line 2 was a mistake, but it seems to have a persistent effect. Even though x still seems to be a 2x0 sparse matrix, subsequent assignments fail after the first failure. Clearing x allows it to work again, but how is it that the error is causing the later failures? jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394982: [Pkg-octave-devel] Bug#394982: octave2.9: Crashes on x(:,
On 25-Oct-2006, John W. Eaton wrote:
| so it seems OK, but what is happening here:
|
| octave:1 x = sparse (2,0)
| x = Compressed Column Sparse (rows = 2, cols = 0, nnz = 0)
|
| octave:2 x(:,2,3) = speye (2)
| error: A(I, J) = X: can only have 1 or 2 indexes for sparse matrices
| error: assignment failed, or no method for `sparse matrix = sparse matrix'
| error: evaluating assignment expression near line 2, column 10
| octave:2 x
| x = Compressed Column Sparse (rows = 2, cols = 0, nnz = 0)
|
| octave:3 x(:,1:2) = speye (2)
| error: A(I, J) = X: can only have 1 or 2 indexes for sparse matrices
| error: assignment failed, or no method for `sparse matrix = sparse matrix'
| error: evaluating assignment expression near line 3, column 10
|
| The command on line 2 was a mistake, but it seems to have a persistent
| effect. Even though x still seems to be a 2x0 sparse matrix,
| subsequent assignments fail after the first failure. Clearing x
| allows it to work again, but how is it that the error is causing the
| later failures?
Never mind, I found the problem. The indices for the LHS were not
being cleared. I fixed it. with the following change. I checked in
your previous change and this one.
Thanks,
jwe
liboctave/ChangeLog:
2006-10-25 John W. Eaton [EMAIL PROTECTED]
* Sparse.cc (assign): Clear lhs index after error.
Index: liboctave/Sparse.cc
===
RCS file: /cvs/octave/liboctave/Sparse.cc,v
retrieving revision 1.19
diff -u -u -r1.19 Sparse.cc
--- liboctave/Sparse.cc 25 Oct 2006 01:40:26 - 1.19
+++ liboctave/Sparse.cc 25 Oct 2006 23:44:11 -
@@ -2387,6 +2387,8 @@
{
(*current_liboctave_error_handler)
(A(I, J) = X: can only have 1 or 2 indexes for sparse matrices);
+
+ lhs.clear_index ();
return 0;
}
Bug#391033: [Pkg-octave-devel] Bug#391033: octave2.9: bad behaviour with hold on/off
On 4-Oct-2006, Francesco Potorti` wrote:
| Package: octave2.9
| Version: 2.9.7-2
| Severity: normal
|
| In Octave 2.1, these two commands give the same result: they first show
| a segment for one second, then they show two segments:
|
| plot([1,2],[3,4]);sleep(1);clearplot;hold
on;plot([0,1],[3,4]);plot([3,2],[3,4]);hold off
| plot([1,2],[3,4]);sleep(1);hold
on;clearplot;plot([0,1],[3,4]);plot([3,2],[3,4]);hold off
|
| In Octave 2.9, they do different things, both wrong:
|
| - the first command line shows one segment, then three segments
| - the second command line shows one segment, then another single segment
| and, in quick succession, yet another single segment
I think the behavior for the second example above is correct. The
clearplot function is now the same as clf, which in Matlab also has
the effect of turning the hold state off.
To fix the first example, please try the following patch and let me
know if you notice any unexpected side effects from it.
Thanks,
jwe
scripts/ChangeLog:
2006-10-04 John W. Eaton [EMAIL PROTECTED]
* plot/__clear_plot__.m: New function.
* plot/__setup_plot__.m: Use __clear_plot__.
src/ChangeLog:
2006-10-04 John W. Eaton [EMAIL PROTECTED]
* DLD-FUNCTIONS/__gnuplot_raw__.l (Fclearplot):
Also call __clear_plot__.
Index: scripts/plot/__clear_plot__.m
===
RCS file: scripts/plot/__clear_plot__.m
diff -N scripts/plot/__clear_plot__.m
--- /dev/null 1 Jan 1970 00:00:00 -
+++ scripts/plot/__clear_plot__.m 4 Oct 2006 14:36:46 -
@@ -0,0 +1,42 @@
+## Copyright (C) 2006 John W. Eaton
+##
+## This file is part of Octave.
+##
+## Octave is free software; you can redistribute it and/or modify it
+## under the terms of the GNU General Public License as published by
+## the Free Software Foundation; either version 2, or (at your option)
+## any later version.
+##
+## Octave is distributed in the hope that it will be useful, but
+## WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+## General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with Octave; see the file COPYING. If not, write to the Free
+## Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+## 02110-1301, USA.
+
+function __clear_plot__ (cmd, sep, clear_data)
+
+ __plot_globals__
+
+ if (nargin 3)
+clear_data = true;
+if (nargin 2)
+ sep = ;
+ if (nargin 1)
+ cmd = ;
+ endif
+endif
+ endif
+
+ __plot_command__{__current_figure__}{__multiplot_xi__,__multiplot_yi__} =
cmd;
+ __plot_command_sep__ = sep;
+
+ if (clear_data)
+__plot_data__{__current_figure__}{__multiplot_xi__,__multiplot_yi__} = [];
+
__plot_data_offset__{__current_figure__}(__multiplot_xi__,__multiplot_yi__) = 1;
+ endif
+
+endfunction
Index: scripts/plot/__setup_plot__.m
===
RCS file: /cvs/octave/scripts/plot/__setup_plot__.m,v
retrieving revision 1.2
diff -u -u -r1.2 __setup_plot__.m
--- scripts/plot/__setup_plot__.m 26 Sep 2006 21:16:52 - 1.2
+++ scripts/plot/__setup_plot__.m 4 Oct 2006 14:36:46 -
@@ -22,16 +22,20 @@
__plot_globals__
if (ishold ())
-if (isempty
(__plot_command__{__current_figure__}{__multiplot_xi__,__multiplot_yi__}))
- __plot_command__{__current_figure__}{__multiplot_xi__,__multiplot_yi__}
= plotcmd;
- __plot_command_sep__ = ;
+cmd =
__plot_command__{__current_figure__}{__multiplot_xi__,__multiplot_yi__};
+if (isempty (cmd))
+ cmd = plotcmd;
+ sep = ;
else
- __plot_command_sep__ = ,\\\n;
+ sep = ,\\\n;
endif
+clear_data = false;
else
-__plot_command__{__current_figure__}{__multiplot_xi__,__multiplot_yi__} =
plotcmd;
-__plot_command_sep__ = ;
-__plot_data__{__current_figure__}{__multiplot_xi__,__multiplot_yi__} = [];
-
__plot_data_offset__{__current_figure__}(__multiplot_xi__,__multiplot_yi__) = 1;
+cmd = plotcmd;
+sep = ;
+clear_data = true;
endif
+
+ __clear_plot__ (cmd, sep, clear_data);
+
endfunction
Index: src/DLD-FUNCTIONS/__gnuplot_raw__.l
===
RCS file: /cvs/octave/src/DLD-FUNCTIONS/__gnuplot_raw__.l,v
retrieving revision 1.12
diff -u -u -r1.12 __gnuplot_raw__.l
--- src/DLD-FUNCTIONS/__gnuplot_raw__.l 23 Aug 2006 19:54:47 - 1.12
+++ src/DLD-FUNCTIONS/__gnuplot_raw__.l 4 Oct 2006 14:36:50 -
@@ -1601,9 +1601,11 @@
octave_value_list args;
args(0) = off;
-
feval (hold, args);
+ args.resize (0);
+ feval (__clear_plot__, args);
+
return octave_value_list ();
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387137: [Pkg-octave-devel] Bug#387137: spkron(a, b) not working when arguments are scalar
On 12-Sep-2006, Thomas Weber wrote: | Hi, | | Am Dienstag, den 12.09.2006, 14:39 +0200 schrieb Nicolas Guilbert: | Package: octave2.9 | Version: 2.9.8-1 | | Steps to reproduce: | octave-2.9.8:1 spkron(2,3) | error: octave_base_value::sparse_matrix_value(): wrong type argument `scalar' | error: octave_base_value::sparse_matrix_value(): wrong type argument `scalar' | | would expect | | ans = 6 | | Try | spkron(sparse(2), sparse(3)) | | I don't consider this a bug. The overhead for sparse-implementations | just doesn't make sense for scalars. Also, why are you using spkron directly? I think it would be better to use kron instead. It will handle both kron (2, 3) kron (sparse (2), sparse (3)) Once Octave has proper dispatching, spkron may only be available via kron with sparse arguments rather than being directly callable. jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368843: Broken info-emacs-info
On 3-Sep-2006, Rafael Laboissiere wrote: | * Rafael Laboissiere [EMAIL PROTECTED] [2006-09-03 16:46]: | | You will find attached below a bug report filed against the Debian package | octave2.9 regarding the info-emacs-info script. The followups to this bug | reported can be seen at: | | http://bugs.debian.org/368843 | | The info-emacs script seems to be still broken in CVS. As the reporter | writes, the order of the options in the invocation of INFO_PROGRAM | changed (--directory comes before --file now) and the old info-emacs-info | script gets confused. | | Here is a patch that fixes the problem. [...] | | The info-emacs-octave-help seems to suffer from the same problem. It | may be better to apply the simple patch below to doc.m: | | --- doc.m-orig2006-09-03 17:04:16.216249600 +0200 | +++ doc.m 2006-09-03 17:05:35.275230808 +0200 | @@ -73,7 +73,7 @@ |info_file_name = info_file (); | endif | | -cmd = sprintf (\%s\ --directory \%s\ --file \%s\, | +cmd = sprintf (\%s\ --file \%s\ --directory \%s\, | info_program (), info_dir, info_file_name); | | if (! isempty (fname)) I made this change. Is the other patch for info-emacs-info still needed? Thanks, jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362423: [EMAIL PROTECTED]: [Pkg-octave-devel] Bug#362219: FTBFS with GCC 4.2: ambiguous overload for 'operator==']
On 3-Sep-2006, Rafael Laboissiere wrote:
| package octave2.1
| forwarded 362423 [EMAIL PROTECTED]
| tags 362423 upstream
| thanks
|
| * Rafael Laboissiere [EMAIL PROTECTED] [2006-04-12 23:55]:
|
| I am forwarding below a bug report filed against the octave2.9 Debian
| package. I have not checked the problems myself, but Martin Milchmayr is
| doing a very good job on building the Debian packages with the prospective
| gcc compiler.
|
| This is just to register that the same problem has been reported against
| the octave2.1 package. See http://bugs.debian.org/362423
Does the following patch help? I think this is how we avoided the
problem for 2.9.x.
jwe
src/ChangeLog:
2006-09-05 John W. Eaton [EMAIL PROTECTED]
* load-save.cc (Fsave): Use tellp instead of pubseekoff to
determine whether we are at beginning of file.
Index: src/load-save.cc
===
RCS file: /cvs/octave/src/load-save.cc,v
retrieving revision 1.191.2.8
diff -u -u -r1.191.2.8 load-save.cc
--- src/load-save.cc18 Oct 2005 17:31:01 - 1.191.2.8
+++ src/load-save.cc5 Sep 2006 14:35:33 -
@@ -1478,9 +1478,7 @@
if (file)
{
- bool write_header_info
- = ((file.rdbuf ())-pubseekoff (0, std::ios::cur)
- == static_caststd::streampos (0));
+ bool write_header_info = ! file.tellp ();
save_vars (argv, i, argc, file, save_builtins, format,
save_as_floats, write_header_info);
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384195: [Pkg-octave-devel]
On 22-Aug-2006, Nicolas Guilbert wrote:
| Package: octave2.9
| Version: 2.9.7-2
|
| Steps to reproduce:
| octave:1 cumsum(zeros(1,0))
| panic: Floating point exception -- stopping myself...
Please try the following patch. It also fixes a similar problem with
the sum and prod functions.
| Would expect ans==0
I think the result should be an empty matrix of the same size as the
argument, which also has the advantage of being compatible with
Matlab.
Thanks,
jwe
liboctave/ChangeLog:
2006-08-22 John W. Eaton [EMAIL PROTECTED]
* mx-inlines.cc (MX_ND_CUMULATIVE_OP): Correctly detect empty arrays.
If array is empty, return value is same size as array.
(MX_ND_REDUCTION): Correctly detect empty arrays.
If array is empty, produce correctly sized return value.
Index: liboctave/mx-inlines.cc
===
RCS file: /cvs/octave/liboctave/mx-inlines.cc,v
retrieving revision 1.48
diff -u -u -r1.48 mx-inlines.cc
--- liboctave/mx-inlines.cc 10 Feb 2006 21:30:42 - 1.48
+++ liboctave/mx-inlines.cc 22 Aug 2006 18:24:17 -
@@ -372,24 +372,17 @@
dim_vector dv = this-dims (); \
int nd = this-ndims (); \
\
- int empty = true; \
+ int empty = false; \
\
for (int i = 0; i nd; i++) \
{ \
- if (dv(i) 0) \
+ if (dv(i) == 0) \
{ \
- empty = false; \
+ empty = true; \
break; \
} \
} \
\
- if (empty) \
-{ \
- dim_vector retval_dv (1, 1); \
- retval.resize (retval_dv, INIT_VAL); \
- return retval; \
-} \
- \
/* We need to find first non-singleton dim. */ \
\
if (dim == -1) \
@@ -435,36 +428,39 @@
\
retval.resize (dv, INIT_VAL); \
\
- octave_idx_type nel = dv.numel (); \
- \
- octave_idx_type k = 1; \
- \
- for (octave_idx_type result_idx = 0; result_idx nel; result_idx++) \
+ if (! empty) \
{ \
- OCTAVE_QUIT; \
+ octave_idx_type nel = dv.numel (); \
\
- for (octave_idx_type j = 0; j n_elts; j++) \
+ octave_idx_type k = 1; \
+ \
+ for (octave_idx_type result_idx = 0; result_idx nel; result_idx++) \
{ \
- OCTAVE_QUIT; \
+ OCTAVE_QUIT; \
\
- EVAL_EXPR; \
+ for (octave_idx_type j = 0; j n_elts; j++) \
+ { \
+ OCTAVE_QUIT; \
\
- iter_idx += incr; \
- } \
+ EVAL_EXPR; \
\
- if (k == reset_at) \
-{ \
- base = next_base; \
- next_base += base_incr; \
- iter_idx = base; \
- k = 1; \
-} \
- else \
- { \
- base++; \
- iter_idx = base; \
- k++; \
- } \
+ iter_idx += incr; \
+ } \
+ \
+ if (k == reset_at) \
+ { \
+ base = next_base; \
+ next_base += base_incr; \
+ iter_idx = base; \
+ k = 1; \
+ } \
+ else \
+ { \
+ base++; \
+ iter_idx = base; \
+ k++; \
+} \
+ } \
} \
\
retval.chop_trailing_singletons (); \
@@ -487,24 +483,17 @@
dim_vector dv = this-dims (); \
int nd = this-ndims (); \
\
- int empty = true; \
+ bool empty = false; \
\
for (int i = 0; i nd; i++) \
{ \
- if (dv(i) 0) \
+ if (dv(i) == 0) \
{ \
- empty = false; \
+ empty = true; \
break; \
} \
} \
\
- if (empty) \
-{ \
- dim_vector retval_dv (1, 1); \
- retval.resize (retval_dv, INIT_VAL); \
- return retval; \
-} \
- \
/* We need to find first non-singleton dim. */ \
\
if (dim == -1) \
@@ -548,47 +537,50 @@
\
retval.resize (dv, INIT_VAL); \
\
- octave_idx_type nel = dv.numel () / n_elts; \
- \
- octave_idx_type k = 1; \
- \
- for (octave_idx_type i = 0; i nel; i++) \
+ if (! empty) \
{ \
- OCTAVE_QUIT; \
+ octave_idx_type nel = dv.numel () / n_elts; \
\
- ACC_TYPE prev_val = INIT_VAL; \
+ octave_idx_type k = 1; \
\
- for (octave_idx_type j = 0; j n_elts; j++) \
+ for (octave_idx_type i = 0; i nel; i++) \
{ \
- OCTAVE_QUIT; \
+ OCTAVE_QUIT; \
\
- if (j == 0) \
+ ACC_TYPE prev_val = INIT_VAL; \
+ \
+ for (octave_idx_type j = 0; j n_elts; j++) \
{ \
- retval(iter_idx) = elem (iter_idx); \
- prev_val = retval(iter_idx); \
+ OCTAVE_QUIT; \
+ \
+ if (j == 0) \
+ { \
+ retval(iter_idx) = elem (iter_idx); \
+ prev_val = retval(iter_idx); \
+ } \
+ else \
+ { \
+ prev_val = prev_val OP elem (iter_idx); \
+ retval(iter_idx) = prev_val; \
+ } \
+ \
+ iter_idx += incr; \
} \
- else \
+ \
+ if (k
Bug#383149: [Pkg-octave-devel] Bug#383149: tried purging then reinstalling octave2.9 package
On 17-Aug-2006, John Dalton wrote:
| I sent an email yesterday pointing out that I had octave2.1
| installed before octave2.9. It seems to have gone missing.
|
| In case it is a problem with packaging, here is the
| sequence I followed in installing octave:
|
| 24/10/2005
| # apt-get install octave octave-forge octave-plplot octave2.1-doc
| octave2.1-info
| # apt-get install octave2.1-headers
|
| 15/8/2006
| Upgrade to octave 2.9:
| # apt-get install octave2.9 octave2.9-info octave2.9-doc
| octave2.9-htmldoc octave2.9-headers
|
| Try it out, then remove octave 2.1:
| # apt-get remove --purge octave octave2.1 octave2.1-info
| octave2.1-htmldoc octave2.1-headers
|
| Report bug #383149.
|
| 17/8/2006
| Wonder if the problem is an interaction between octave 2.1 and 2.9
| packages. Do a clean reinstall of octave2.9 (ie. with no octave2.1)
|
| # apt-get remove --purge octave2.9 octave2.9-info octave2.9-doc
| octave2.9-htmldoc octave2.9-headers
| # apt-get install octave2.9 octave2.9-info octave2.9-doc
| octave2.9-htmldoc octave2.9-headers
|
| After this fresh reinstall, symptoms are still present as before:
| $ mkoctfile -v uitest.cc
| g++ -c -fPIC -I/usr/include/octave-2.9.7
| -I/usr/include/octave-2.9.7/octave -m32 uitest.cc -o uitest.o
| /usr/bin/g++ -shared -Wl,-Bsymbolic -o uitest.oct uitest.o
| -L/usr/lib/octave-2.9.7 -loctinterp -loctave -lcruft -m32 -llapack-3
| -lblas-3 -lfftw3 -lreadline -lncurses -ldl -lhdf5 -lz -lm
| -L/usr/lib/gcc/x86_64-linux-gnu/4.1.2
| -L/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64 -L/lib/../lib64
| -L/usr/lib/../lib64 -lhdf5 -lz -lgfortranbegin -lgfortran -lm -lgcc_s
| /usr/bin/ld: skipping incompatible /usr/lib/octave-2.9.7/liboctinterp.so
| when searching for -loctinterp
| /usr/bin/ld: cannot find -loctinterp
| collect2: ld returned 1 exit status
| $
I'm unable to duplicate this problem. I have an up-to-date testing
system and I installed Octave 2.9.7 with
apt-get update
apt-get -t unstable octave2.9{,-{headers,info,doc}}
and then ran
update-alternatives --config mkoctfile
update-alternatives --config octave
update-alternatives --config octave-bug
update-alternatives --config octave-config
update-alternatives --config octave-depends
BTW, why do I have to run all these commands? I think it would be
more friendly if running update-alternatives --config octave would
take care of the rest automatically so they would all stay in sync.
In any case, here is what I see:
$ dpkg -l octave2.9
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name VersionDescription
+++-==-==-
ii octave2.9 2.9.7-2GNU Octave language for numerical computatio
$ pwd
/home/jwe/src/octave/examples
$ ls -l hello.cc
-rw-r--r-- 1 jwe users 3103 Apr 30 2003 hello.cc
$ mkoctfile -v hello.cc
/usr/bin/g++ -c -fPIC -I/usr/include/octave-2.9.7
-I/usr/include/octave-2.9.7/octave -O2 hello.cc -o hello.o
/usr/bin/g++ -shared -Wl,-Bsymbolic -o hello.oct hello.o
-L/usr/lib/octave-2.9.7 -loctinterp -loctave -lcruft -s -llapack-3 -lblas-3
-lfftw3 -lreadline -lncurses -ldl -lhdf5 -lz -lm
-L/usr/lib/gcc/x86_64-linux-gnu/4.1.2
-L/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64 -lhdf5 -lz -lgfortranbegin -lgfortran -lm -lgcc_s
$ octave
GNU Octave, version 2.9.7 (x86_64-pc-linux-gnu).
Copyright (C) 2006 John W. Eaton.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTIBILITY or
FITNESS FOR A PARTICULAR PURPOSE. For details, type `warranty'.
Additional information about Octave is available at http://www.octave.org.
Please contribute if you find this software useful.
For more information, visit http://www.octave.org/help-wanted.html
Report bugs to [EMAIL PROTECTED] (but first, please read
http://www.octave.org/bugs.html to learn how to write a helpful report).
octave:1 hello
Hello, world!
octave:2 type hello
hello is a dynamically-linked function
octave:3 which hello
hello is the dynamically-linked function from the file
/export/home/jwe/src/octave/examples/hello.oct
jwe
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373965: [Pkg-octave-devel] Bug#373965: error: `LOADPATH' undefined
On 16-Jun-2006, Kim Hansen wrote: | Package: octave2.9 | Version: 2.9.6-1 | Severity: normal | | The new octave package has a problem with its path, my octave programs fails | with 2.9.6-1 and works with 2.9.5-7. | | [EMAIL PROTECTED]:~$ octave | GNU Octave, version 2.9.6 (i486-pc-linux-gnu). | Copyright (C) 2006 John W. Eaton. | This is free software; see the source code for copying conditions. | There is ABSOLUTELY NO WARRANTY; not even for MERCHANTIBILITY or | FITNESS FOR A PARTICULAR PURPOSE. For details, type `warranty'. | | Additional information about Octave is available at http://www.octave.org. | | Please contribute if you find this software useful. | For more information, visit http://www.octave.org/help-wanted.html | | Report bugs to [EMAIL PROTECTED] (but first, please read | http://www.octave.org/bugs.html to learn how to write a helpful report). | | error: `LOADPATH' undefined near line 10 column 51 | error: evaluating assignment expression near line 10, column 10 | error: near line 10 of file `/usr/share/octave/2.9.6/m/startup/octaverc' | octave:1 | [EMAIL PROTECTED]:~$ This is not a bug, but a change in functionality. In 2.9 (a development version leading to 3.0, which will be a major new release with some backward-incompatible changes) all the built-in variables have been removed and replaced by functions. In most cases the functions have the same names as the old built-in variables, but some have been completely removed. LOADPATH is one that has been removed. Now you need to use addpath, rmpath, etc. to manipulate the path. See the current NEWS file for more information. jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361705: [Pkg-octave-devel] Bug#361705: octave2.1-info: wrong references in Variable index
On 10-Apr-2006, Rafael Laboissiere wrote:
| package octave2.1-info
| forwarded 361705 [EMAIL PROTECTED]
| tags 361705 upstream patch
| thanks
|
|
| The bug report below was filed against the Debian package octave2.1-info,
| version 2.1.72-10. I confirm that the same problems exist for 2.1.73 and
| 2.9.5. (For detailed information, see http://bugs.debian.org/361705.)
|
| My comments:
|
| * Francesco Potorti` [EMAIL PROTECTED] [2006-04-08 13:40]:
|
| Package: octave2.1-info
| Version: 1:2.1.72-10
| Severity: normal
|
| In Variable index there is a reference to return, which is not a
| variable.
|
| I do not know if this is fixable. The return keyword is defined with
| @defvr {Keyword} return in doc/interpreter/func.txi and will be indexed
| in the variable index in any case.
I changed the current CVS sources (2.9.x) to use deffn so it will
appear in the function index. Maybe we should also have a keyword
index, but I think that would be much more work.
| In variable index, automatic_replot refers to Summary of built-in
| variables, which in turn refers to :Two-dimensional plotting, where
| automatic_replot is not mentioned.
|
| This is indeed annoying. Here is my suggested patch to fix the problem:
OK, I checked in these changes, also to the 2.9.x CVS sources.
Thanks,
jwe
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#356194: [Pkg-octave-devel] Bug#356194: octave2.9: Octave-2.9.4 - random crashes
On 10-Mar-2006, LUK ShunTim wrote: | I'm experiencing random crashes of octave 2.9.4 on a debian/sid box. I | apt-get the source and rebuild with debug on and here is the backtrace. | | backtrace | | $ gdb octave | GNU gdb 6.4-debian | Copyright 2005 Free Software Foundation, Inc. | GDB is free software, covered by the GNU General Public License, and you are | welcome to change it and/or distribute copies of it under certain | conditions. | Type show copying to see the conditions. | There is absolutely no warranty for GDB. Type show warranty for details. | This GDB was configured as i486-linux-gnu...(no debugging symbols found) | Using host libthread_db library /lib/tls/i686/cmov/libthread_db.so.1. | | (gdb) run | Starting program: /usr/bin/octave | (no debugging symbols found) | (no debugging symbols found) | (no debugging symbols found) | (no debugging symbols found) | (no debugging symbols found) | (no debugging symbols found) | (no debugging symbols found) | (no debugging symbols found) | (no debugging symbols found) If you rebuilt with debugging enabled, then what happened to the symbols? Were they stripped at some point? | #1 0xb7b3b38d in octave_builtin::do_multi_index_op () |from /usr/lib/octave-2.9.4/liboctinterp.so With debugging symbols, I'd expect more info about the arguments. In any case, if it is truly a random crash that you can't reproduce, then the first thing I would check would be your system's memory. OTOH, if it is always crashing in the same place, then can you try to find some recipe for the failure? jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352671: [Pkg-octave-devel] Bug#352671: octave2.9: Control-C sends octave into a busy loop
On 13-Feb-2006, Andrey Romanenko wrote: | Package: octave2.9 | Version: 2.9.4-12 | Severity: normal | | If I hit Control-C in an Octave session, the interpreter enters a busy | loop (according to top) and stops responding. A gentle kill from | another shell is able to terminate the Octave session. It is possible to | reproduce the problem using the following simple example: | | for i=1:100 |printf(%d\n, i); |sleep(1); | endfor; | | It should be noted that this bug existed in the previous debian version | of 2.9 in the testing distribution. I'm not able to reproduce this problem with the current CVS sources on two different systems (Debian testing, amd64 and x86, mostly up to date). jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341906: [Pkg-octave-devel] Bug#341906: octave prints copyright/debugging information on stdout instead of stderr
On 9-Jan-2006, Frederik Eaton wrote: | On Mon, Jan 09, 2006 at 10:33:40AM +0100, Rafael Laboissiere wrote: | * Frederik Eaton [EMAIL PROTECTED] [2006-01-09 03:07]: | | You're right, mysql seems to print to stdout, while perl -d writes | directly to the terminal. In any case, I don't see a reason not to | adopt my suggestion. | | The convincing argument is that one typically wants to be able to have | rather strict control over what the output of a program is. When | 'stdout' gets cluttered with other messages, it loses its usefulness | very quickly. | | Why doesn't the -q command option suit your needs? | | One can only put so many options on the #! line, I think the limit | is 1. I could remember to put -q in every octave script, and | complain when I need to add another option and can't, but then, why | not have a sensible default? Hi, I think you already argued this point on the Octave mailing list, and I was not convinced that the change was needed. Would it really be good to have the Debian package include a special patch for this change that was not a part of the upstream Octave distribution? jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341906: [Pkg-octave-devel] Bug#341906: octave prints copyright/debugging information on stdout instead of stderr
On 4-Dec-2005, Frederik Eaton wrote: | On Sun, Dec 04, 2005 at 10:17:01AM -0500, John W. Eaton wrote: | On 4-Dec-2005, Frederik Eaton wrote: | | | By the way, why not have -q be the default when octave is run as part | | of a script? | | What do you mean by as part of a script? | | i.e. when you put #!/usr/bin/octave at the top of a file with octave | code in it. How would Octave be able to know that it has been started in this way? As far as I know, the only information Octave gets is what is passed to it in argv. In this case, the kernel (or the shell) starts Octave with whatever follows the #!, plus the name of the script file. So I think you have to include the -q yourself. Now, if you mean you would prefer to have every noninteractive invocation of Octave omit the copyright notice, then that would be possible. I don't see the reason it is needed, since -q is available. But if you'd like to try convince me why this is important or necessary, then please use the [EMAIL PROTECTED] list. Also, to combat spam on the lists, posting is restricted to subscribers (other mail is bounced to me to forward to the list if it is actually for the list and not spam), so please consider subscribing before posting. Thanks, jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341906: [Pkg-octave-devel] Bug#341906: octave prints copyright/debugging information on stdout instead of stderr
On 4-Dec-2005, Frederik Eaton wrote: | By the way, why not have -q be the default when octave is run as part | of a script? What do you mean by as part of a script? jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341906: [Pkg-octave-devel] Bug#341906: octave prints copyright/debugging information on stdout instead of stderr
On 3-Dec-2005, Frederik Eaton wrote: | Package: octave2.9 | Version: 2.9.4-8 | Severity: normal | | My version of Octave prints copyright/debugging information on stdout | instead of stderr... It would be better to have it on stderr so that I | can redirect just the output to a pipe or a file. I don't think this is a bug. If you don't want the startup message, then start Octave with -q. jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341759: [Pkg-octave-devel] Bug#341759: no obvious way to turn off comment indentation
On 2-Dec-2005, Frederik Eaton wrote: | Package: octave2.9-emacsen | Version: 2.9.4-8 | Severity: normal | | I have Auto Indent set to off in the octave customization group | but when I type a # character it still ends up indented by 32 | columns. I would like to make octave-mode stop doing this so that I | can easily type unindented comments, but I can't figure out what the | proper configuration variable is. I will try to look at this bug, but in the meantime, you can use ### to produce comments that are not indented, ## for comments that are indented to code level, and # for (aligned) end of line comments. jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341759: [Pkg-octave-devel] Bug#341759: no obvious way to turn off comment indentation
On 2-Dec-2005, Frederik Eaton wrote: | Package: octave2.9-emacsen | Version: 2.9.4-8 | Severity: normal | | I have Auto Indent set to off in the octave customization group | but when I type a # character it still ends up indented by 32 | columns. I would like to make octave-mode stop doing this so that I | can easily type unindented comments, but I can't figure out what the | proper configuration variable is. | | Here is a clip from the customization buffer: | | Auto Indent: [Hide] [Toggle] off (nil) |[State]: this option is unchanged from its standard setting. | Non-nil means indent line after a semicolon or space in Octave mode. Please try the following patch. Thanks, jwe ChangeLog: 2005-12-02 John W. Eaton [EMAIL PROTECTED] * emacs/octave-mod.el (octave-electric-space): Don't indent comments or strings if octave-auto-indent is nil. Index: emacs/octave-mod.el === RCS file: /cvs/octave/emacs/octave-mod.el,v retrieving revision 1.37 diff -u -r1.37 octave-mod.el --- emacs/octave-mod.el 30 Nov 2005 03:04:45 - 1.37 +++ emacs/octave-mod.el 3 Dec 2005 02:40:11 - @@ -1329,7 +1329,8 @@ Reindent the line of `octave-auto-indent' is non-nil. (interactive) (setq last-command-char ? ) - (if (not (octave-not-in-string-or-comment-p)) + (if (and octave-auto-indent + (not (octave-not-in-string-or-comment-p))) (progn (indent-according-to-mode) (self-insert-command 1)) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339442: [Pkg-octave-devel] Bug#339442: octave2.9: error at startup: __gnuplot_init__ undefined
On 16-Nov-2005, Alberto Maurizi wrote: | On Wed, Nov 16, 2005 at 04:48:57PM +0100, Rafael Laboissiere wrote: | Thanks for the extra-info. What do you get for this: | | echo which gplot | octave-2.9.4 -q | | | here it is: | | [EMAIL PROTECTED]:~/ echo which gplot | octave-2.9.4 -q | error: `__gnuplot_init__' undefined near line 141 column 1 | error: near line 141 of file `/usr/lib/octave/2.9.4/oct/i486-pc-linux-gnu//PKG_ADD' | error: source: error sourcing file `/usr/lib/octave/2.9.4/oct/i486-pc-linux-gnu//PKG_ADD' | error: near line 10 of file `/usr/share/octave/2.9.4/m/startup/octaverc' | gplot is the dynamically-linked function from the file | /usr/lib/octave/2.9.4/oct/i486-pc-linux-gnu/gplot.oct So what is in the file /usr/lib/octave/2.9.4/oct/i486-pc-linux-gnu//PKG_ADD on your system? Does it contain a line like autoload (__gnuplot_init__, ...); before the line __gnuplot_init__ (); ? If so, precisely what is the second argument to the autoload command? Does the file named there exist on your system? What permissions does it have? jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339442: [Pkg-octave-devel] Bug#339442: octave2.9: error at startup: __gnuplot_init__ undefined
On 16-Nov-2005, Rafael Laboissiere wrote:
| [Please, keep Cc: to [EMAIL PROTECTED]
|
| * John W. Eaton [EMAIL PROTECTED] [2005-11-16 12:49]:
|
| OK, I will fix this by generating this PKG_ADD file differently so we
| avoid problems related to creating a package by running make install
| with a value of prefix that is different from the one used at configure
| time.
|
| I am happy that the riddle is solved. Indeed, mk-pkg-add is called with
| --prefix having the DESTDIR in it. I could not reproduce the error,
| because I had the build tree present in my system.
|
| Please provide a patch that I can apply to the 2.9.4 tarball and I will
| immediately upload a fixed version of the package.
Try the following.
jwe
src/ChangeLog:
2005-11-16 John W. Eaton [EMAIL PROTECTED]
* Makefile.in (PKG_ADD.inst): New target.
(install): Dependo on it.
(clean): Remove it.
* mk-pkg-add: New option --install. Don't use --prefix option.
Delete obsolete comments.
Index: src/Makefile.in
===
RCS file: /cvs/octave/src/Makefile.in,v
retrieving revision 1.390
diff -u -r1.390 Makefile.in
--- src/Makefile.in 12 Nov 2005 02:31:23 - 1.390
+++ src/Makefile.in 16 Nov 2005 18:43:40 -
@@ -343,8 +343,12 @@
@$(top_srcdir)/move-if-change [EMAIL PROTECTED] $@
PKG_ADD: $(DLD_DEF_FILES)
- $(srcdir)/mk-pkg-add --prefix $(shell pwd) $(DLD_DEF_FILES) PKG_ADD-t
- mv PKG_ADD-t PKG_ADD
+ $(srcdir)/mk-pkg-add --prefix $(shell pwd) $(DLD_DEF_FILES) [EMAIL
PROTECTED]
+ mv [EMAIL PROTECTED] $@
+
+PKG_ADD.inst: $(srcdir)/mk-pkg-add $(DLD_DEF_FILES)
+ $(srcdir)/mk-pkg-add --install $(DLD_DEF_FILES) [EMAIL PROTECTED]
+ mv [EMAIL PROTECTED] $@
DOCSTRINGS: gendoc$(BUILD_EXEEXT)
./gendoc [EMAIL PROTECTED]
@@ -396,9 +400,9 @@
cd $(DESTDIR)$(bindir) ; $(LN_S) octave-$(version)$(EXEEXT)
octave$(EXEEXT)
.PHONY: install-bin
-install-oct:
+install-oct: PKG_ADD.inst
$(top_srcdir)/mkinstalldirs $(DESTDIR)$(octfiledir)
- $(srcdir)/mk-pkg-add --prefix $(octfiledir) $(DLD_DEF_FILES)
$(DESTDIR)$(octfiledir)/PKG_ADD
+ $(INSTALL_DATA) PKG_ADD.inst $(DESTDIR)$(octfiledir)/PKG_ADD
if [ -n $(OCT_FILES) ]; then \
xfiles=$(OCT_FILES); \
for f in $$xfiles; do \
@@ -472,6 +476,7 @@
rm -f $(PICOBJ) $(DLD_PICOBJ) stmp-pic gendoc$(EXEEXT)
rm -f builtins.cc ops.cc defaults.h oct-conf.h def-files var-files
rm -f PKG_ADD
+ rm -f PKG_ADD.inst
-rmdir pic
.PHONY: clean
Index: src/mk-pkg-add
===
RCS file: /cvs/octave/src/mk-pkg-add,v
retrieving revision 1.1
diff -u -r1.1 mk-pkg-add
--- src/mk-pkg-add 11 Nov 2005 17:45:51 - 1.1
+++ src/mk-pkg-add 16 Nov 2005 18:43:40 -
@@ -1,21 +1,25 @@
#! /bin/sh -e
-# Create additional links to .oct files that define more than one
-# function.
-
-# If the first arg is --print, only print the links we need to make.
-
-# The first non-option arg is taken as the directory where the .oct
-# files are installed. The remaining arguments should be the list of
-# .df files corresponding to the source files that were used to
-# create the .oct files.
-
SED=${SED:-'sed'}
+install=false
if [ $1 = --prefix ]; then
shift
prefix=$1
shift
+elif [ $1 = --install ]; then
+ install=true
+ shift
+fi
+
+if [ $# -gt 0 ]; then
+ if $install; then
+cat EOF
+__octfiledir__ = strrep (octave_config_info (octfiledir),
+ octave_config_info (prefix),
+ OCTAVE_HOME);
+EOF
+ fi
fi
for f in $@; do
@@ -33,7 +37,9 @@
true
else
if [ -n $prefix ]; then
- echo autoload (\$n\, \$prefix/$base.oct\);
+ echo autoload (\$n\, strcat (\$prefix\, filesep,
\$base.oct\));
+ elif $install; then
+echo autoload (\$n\, strcat (__octfiledir__, filesep,
\$base.oct\));
else
echo autoload (\$n\, \$base.oct\);
fi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335237: [Pkg-octave-devel] Re: Forking glpk
On 15-Nov-2005, Falk Hueffner wrote: | The difference is that the *ABI* changes frequently. I think that happens for a lot of software. | This will break horribly if the headers become out of sync with the | library. You absolutely need to provide matching headers. Yes, of course. So maybe a different solution is needed? | I'm not really convinced. The problem is that you'll need a new | package name each time you upgrade, and this will leave lots of stale | library packages behind and generally be a hassle. Why is it a hassle? How often are new releases of glpk happening? Every few weeks? Twice a year? Does the ABI change with every release? | If the goal is only | to provide a solution for octave, it would probably be easier to just | add a copy of glpk's source into the octave tarball and install it as | glpk-octave or something. No. I do not want to include external packages in Octave. Doing that would definitely be a hassle. jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327027: [Pkg-octave-devel] Bug#327027: octave2.1: not installable in sid
On 15-Sep-2005, Rafael Laboissiere wrote: | * John W. Eaton [EMAIL PROTECTED] [2005-09-14 02:07]: | | On 10-Sep-2005, Rafael Laboissiere wrote: | | | John, could you please confirm that this would fix the bug? | | Looking at the code, I think it will avoid the problem. | | Should we then file a bug report against the libc6 package requesting the | application of the patch? Yes, unless there will be a new release of glibc very soon. jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327027: [Pkg-octave-devel] Bug#327027: octave2.1: not installable in sid
On 10-Sep-2005, Rafael Laboissiere wrote: | John, could you please confirm that this would fix the bug? Looking at the code, I think it will avoid the problem. Thanks, jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327509: [Pkg-octave-devel] Bug#327509: octave2.1-headers: mkoctfile generates broken binaries (undefined symbol: _ZNSs4_Rep20_S_empty_rep_storageE)
On 10-Sep-2005, Graeme Smecher wrote: | Package: octave2.1-headers | Version: 2.1.71-2 | Severity: important | | mkoctfile no longer produces working .oct files. I've tried compiling | the hello.cc example: | | mkoctfile hello.cc | | The mkoctfile command appears to succed. Then: | | $ octave -q | octave:1 hello | error: /home/gsmecher/click/halfband/hello.oct: undefined symbol: | _ZNSs4_Rep20_S_empty_rep_storageE | octave:1 Running echo _ZNSs4_Rep20_S_empty_rep_storageE | c++filt shows std::basic_stringchar, std::char_traitschar, std::allocatorchar ::_Rep::_S_empty_rep_storage so I suspect a compiler issue or packaging problem, not a bug in Octave itself. What version of g++ was used to build your copy of Octave? You can get this information by typing octave_config_info (CXX_VERSION) at the octave prompt. What version of g++ is currently being used on your system by mkoctfile? Assuming the versions are not the same, then do you avoid the problem if you force mkoctfile to use the same compiler version as was used to compile Octave? jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327302: [Pkg-octave-devel] Bug#327302: octave-forge: not installable on unstable
On 9-Sep-2005, Juergen Rinas wrote: | octave-forge | depends on libginac1.3 (= 1.3.0) | but is not avaiable in unstable | due to C++ ABI transition A C++ ABI transition will likely cause some trouble for Octave as well. Does anyone have a suggestion for what the best solution is? jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327027: [Pkg-octave-devel] Bug#327027: octave2.1: not installable in sid
On 7-Sep-2005, Laurent Bonnaud wrote: | octave needs to be recompiled with g++ 4.0 and a newer libhdf5: The last time I tried compiling Octave with g++ 4.0 (actually 4.0.1), Octave failed several of its tests. So maybe g++ 4.0 is not quite ready yet? jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327027: [Pkg-octave-devel] Bug#327027: octave2.1: not installable in sid
On 9-Sep-2005, Laurent Bonnaud wrote: | Too bad :. Did you submit bugs to the gcc or Debian BTS (I looked | rapidly and did not find a relevant bug) ? No, sorry, I didn't. | g++ 3.4 could also be used as a fallback since it is ABI-compatible with | g++ 4.0. Is libstdc++ also completely compatible? Have there been absolutely no changes that could affect layout of class members? jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327027: [Pkg-octave-devel] Bug#327027: octave2.1: not installable in sid
On 9-Sep-2005, Laurent Bonnaud wrote: | Is libstdc++ also completely compatible? Have there been absolutely | no changes that could affect layout of class members? | | This question is no longer a concern since my tests have shown that g++ | 3.4 is worse than g++ 4.0. But unless we are absolutely sure that everything is compatible from one release to another, it does matter. Suppose the Octave package is compiled with 4.0 (for example) and the dependencies are set for g++ = 4.0 then later someone installs 4.1. Then if there are incompatibilities (a change in the layout of some data members in a standard class, for example) then there can be problems when an Octave user builds a dynamically linked function using mkoctfile, because mkoctfile is only asking for g++ and the user gets g++-4.1, not g++-4.0 In the old days, the I think Octave was configured with something like CC=gcc-4.0 CXX=g++-4.0 F77=g77-4.0 so that these names would be put into the mkoctfile script. That way, when someone later ran mkoctfile, they would be sure to get the same version of the compiler that was used to build the Octave binary they were using. Yes, I would prefer to not have to fix the compiler versions, but unless we know that they are compatible, I see no other option. jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327027: [Pkg-octave-devel] Bug#327027: octave2.1: not installable in sid
On 9-Sep-2005, Laurent Bonnaud wrote:
| Here is the build with g++-3.4. It is worse than with g++-4.0 (6
| failures instead of 2).
Odd. My results were:
3.3: all tests pass
3.4: all tests pass
4.0: 1 failed (FAIL: octave.test/arith/coth-1.m)
My system is Debian testing, updated to the latest packages just
before running my tests. I built Octave 2.1.71 (downloaded from the
Octave ftp site) using 3.3, 3.4, and 4.0, with the following commands:
tar zxf octave-2.1.71.tar.gz
top=`pwd`
for v in 3.3 3.4
do
mkdir $top/$v
cd $top/$v
## since there is no g77-4.0, I used the default g77 (3.4) when
## building with gcc/g++ 4.0
if [ $v = 4.0 ]; then G77=g77; else G77=g77-$v; fi
../octave-2.1.71/configure --enable-shared --disable-static CC=gcc-$v
CXX=g++-$v F77=$G77
make all check
done
The failed test is:
x = [pi/2*i, 3*pi/2*i];
v = [0, 0];
all (abs (coth (x) - v) sqrt (eps))
Running this by hand (and looking at what is actually produced by coth
instead of just the final result) shows
octave:4 coth(x)
ans =
NaN - NaNi NaN - NaNi
At least it is NaN, which will show up in obvious ways later on in a
calculation, instead of just some incorrect numerical result. But
still, I would prefer that this bug be fixed before Octave packages
built with gcc 4.0 are distributed.
Octave's coth function is just a simple
function w = coth (z)
if (nargin != 1)
usage (coth (z));
endif
w = 1 ./ tanh (z);
endfunction
but tanh is a built-in function, and it is returning
octave:7 tanh (x)
ans =
NaN + Infi NaN + Infi
for the same X as above.
The 4.0 complex header has
// 26.2.8/15 tanh(__z): Returns the hyperbolic tangent of __z.
templatetypename _Tp
inline complex_Tp
__complex_tanh(const complex_Tp __z)
{ return std::sinh(__z) / std::cosh(__z); }
#if _GLIBCXX_USE_C99_COMPLEX
inline __complex__ float
__complex_tanh(__complex__ float __z) { return __builtin_ctanhf(__z); }
inline __complex__ double
__complex_tanh(__complex__ double __z) { return __builtin_ctanh(__z); }
inline __complex__ long double
__complex_tanh(const __complex__ long double __z)
{ return __builtin_ctanhl(__z); }
templatetypename _Tp
inline complex_Tp
tanh(const complex_Tp __z) { return __complex_tanh(__z.__rep()); }
#else
templatetypename _Tp
inline complex_Tp
tanh(const complex_Tp __z) { return __complex_tanh(__z); }
#endif
while the 3.3 complex header has
templatetypename _Tp
inline complex_Tp
tanh(const complex_Tp __z)
{
return sinh(__z) / cosh(__z);
}
so my guess is the bug is in the __builtin_ctanh code.
Here is a simpler test case:
#include cmath
#include iostream
#include complex
int
main (void)
{
std::cout std::tanh (std::complexdouble (0, M_PI/2)) std::endl;
std::cout std::tanh (std::complexdouble (0, 3*M_PI/2)) std::endl;
return 0;
}
I think this should produce (0, inf) in both cases. With 3.3, it is
still not right, as it produces
(0,1.63318e+16)
(0,5.44393e+15)
but at least it does not give NaN.
Or, is the C math library standard written so that tanh is required to
give (nan, inf) here?
Thanks,
jwe
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324471: octave2.1-emacsen: problems if octave startup file contains cd()
I applied this change to my sources. Would you please also report this to the Emacs maintainers so that the version of octave-inf that is distributed with Emacs can also be fixed? Thanks, jwe On 27-Aug-2005, Rafael Laboissiere wrote: | package octave2.1-emacsen | tags 324471 upstream | forwarded 324471 [EMAIL PROTECTED] | stop | | | The bug report attached below was filed against version 2.1.69 of the | Debian package. I confirm that the patch provided fixes the problem also | for Octave 2.1.71. Please consider applying it to CVS. | | -- | Rafael | | Received: from fetchmail by laboiss2 with local (Exim 3.36 #1 (Debian)) | id 1E96vx-00044Z-00 | for [EMAIL PROTECTED]; Sat, 27 Aug 2005 22:05:45 +0200 | Received: from neukom.intra.mpipf-muenchen.mpg.de [10.129.1.23] | by localhost with POP3 (fetchmail-6.2.5) | for [EMAIL PROTECTED] (single-drop); Sat, 27 Aug 2005 22:05:45 +0200 (CEST) | Received: from kom.mpisoc.mpg.de ([192.129.1.23] helo=kom.mpipf-muenchen.mpg.de) | by amalie.intra.mpipf-muenchen.mpg.de with esmtp (Exim 4.05) | id 1E96rb-0007dF-00 | for [EMAIL PROTECTED]; Sat, 27 Aug 2005 22:01:15 +0200 | Received: from master.debian.org ([146.82.138.7]) | by kom.mpipf-muenchen.mpg.de with esmtp (Exim 4.34) | id 1E96ra-0002m8-Np | for [EMAIL PROTECTED]; Sat, 27 Aug 2005 22:01:15 +0200 | Received: from haydn.debian.org [192.25.206.28] | by master.debian.org with esmtp (Exim 3.35 1 (Debian)) | id 1E7u1M-Dl-00; Wed, 24 Aug 2005 07:06:20 -0500 | Received: from localhost ([127.0.0.1]:44789 helo=haydn.debian.org) | by haydn.debian.org with esmtp (Exim 4.50) | id 1E7u1L-0008MJ-Iu; Wed, 24 Aug 2005 12:06:20 + | Received: from spohr.debian.org ([140.211.166.43]:38932 ident=mail) | by haydn.debian.org with esmtp (Exim 4.50) id 1E79Q1-0008Dv-N0 | for [EMAIL PROTECTED]; | Mon, 22 Aug 2005 10:20:42 + | Received: from debbugs by spohr.debian.org with local (Exim 3.36 1 (Debian)) | id 1E798y-0006bd-00; Mon, 22 Aug 2005 03:03:04 -0700 | X-Loop: [EMAIL PROTECTED] | Resent-From: Pascal A. Dupuis [EMAIL PROTECTED] | Resent-To: debian-bugs-dist@lists.debian.org | Resent-CC: Debian Octave Group [EMAIL PROTECTED] | Resent-Date: Mon, 22 Aug 2005 10:03:02 UTC | Resent-Message-ID: [EMAIL PROTECTED] | X-Debian-PR-Message: report 324471 | X-Debian-PR-Package: octave2.1-emacsen | X-Debian-PR-Keywords: patch | Received: via spool by [EMAIL PROTECTED] id=B.11247040397540 | (code B ref -1); Mon, 22 Aug 2005 10:03:02 UTC | Received: (at submit) by bugs.debian.org; 22 Aug 2005 09:47:19 + | Received: from nibbel.kulnet.kuleuven.ac.be [134.58.240.41] | by spohr.debian.org with esmtp (Exim 3.36 1 (Debian)) | id 1E78ti-0001aC-00; Mon, 22 Aug 2005 02:47:19 -0700 | Received: from localhost (localhost [127.0.0.1]) | by nibbel.kulnet.kuleuven.ac.be (Postfix) with ESMTP id D31404C14F | for [EMAIL PROTECTED]; Mon, 22 Aug 2005 11:46:46 +0200 (CEST) | Received: from smtp02.kuleuven.be (lepidus.kulnet.kuleuven.ac.be | [134.58.240.72]) | by nibbel.kulnet.kuleuven.ac.be (Postfix) with ESMTP id 31DFA4C294 | for [EMAIL PROTECTED]; Mon, 22 Aug 2005 11:46:46 +0200 (CEST) | Received: from electa-30.esat.kuleuven.be (electa-30.esat.kuleuven.be | [10.33.135.40]) | by smtp02.kuleuven.be (Postfix) with ESMTP id 22F932CAA0B | for [EMAIL PROTECTED]; Mon, 22 Aug 2005 11:46:46 +0200 (CEST) | Received: by electa-30.esat.kuleuven.be (Postfix, from userid 2007) | id 546E41C196; Mon, 22 Aug 2005 11:46:44 +0200 (CEST) | Content-Type: multipart/mixed; boundary1476422183== | MIME-Version: 1.0 | From: Pascal A. Dupuis [EMAIL PROTECTED] | To: Debian Bug Tracking System [EMAIL PROTECTED] | X-Mailer: reportbug 3.15 | Date: Mon, 22 Aug 2005 11:46:43 +0200 | Message-Id: [EMAIL PROTECTED] | X-Virus-Scanned: by KULeuven Antivirus Cluster | Delivered-To: [EMAIL PROTECTED] | X-Mailman-Approved-At: Wed, 24 Aug 2005 12:06:13 + | Subject: [Pkg-octave-devel] Bug#324471: octave2.1-emacsen: problems if | octave startup file contains cd() | X-BeenThere: [EMAIL PROTECTED] | X-Mailman-Version: 2.1.5 | Precedence: list | Reply-To: Pascal A. Dupuis [EMAIL PROTECTED], | [EMAIL PROTECTED] | List-Id: Development discussion for Octave/Debian | pkg-octave-devel.lists.alioth.debian.org | List-Unsubscribe: http://lists.alioth.debian.org/mailman/listinfo/pkg-octave-devel, | mailto:[EMAIL PROTECTED] | List-Archive: http://lists.alioth.debian.org/pipermail/pkg-octave-devel | List-Post: mailto:[EMAIL PROTECTED] | List-Help: mailto:[EMAIL PROTECTED] | List-Subscribe: http://lists.alioth.debian.org/mailman/listinfo/pkg-octave-devel, | mailto:[EMAIL PROTECTED] | Sender: [EMAIL PROTECTED] | Errors-To: [EMAIL PROTECTED] | X-SA-Exim-Connect-IP: 127.0.0.1 | Resent-Date: Sat, 27 Aug 2005 22:01:15 +0200 | X-UIDL: oj~!UaM!!5]J!!M^B! | Resent-Sender:
Bug#253188: [Pkg-octave-devel] Re: Bug#253188: octave2.1: Keyword end confuses octave-mode.el
On 15-Mar-2005, Rafael Laboissiere [EMAIL PROTECTED] wrote: | package octave2.1-emacsen | tags 253188 fixed-upstream | thanks | | * John W. Eaton [EMAIL PROTECTED] [2005-03-15 00:14]: | | Note that Emacs also includes the code for Octave mode, so we should | probably try to stay in sync with it as well. | | Are both codes developed independently, or is the code distributed with | Octave the master one? Unfortunately, it seems that they have evolved independently. Fortunately, they are not that different at this point, so reconciling the changes should not be too hard. jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#253188: [Pkg-octave-devel] Re: Bug#253188: octave2.1: Keyword end confuses octave-mode.el
On 4-Mar-2005, Rafael Laboissiere [EMAIL PROTECTED] wrote: | * John W. Eaton [EMAIL PROTECTED] [2004-06-07 15:18]: | | On 7-Jun-2004, Dirk Eddelbuettel [EMAIL PROTECTED] wrote: | | | On Mon, Jun 07, 2004 at 03:19:10PM -0400, D. Goel wrote: | | Package: octave2.1 | | Version: 2.1.57-2 | | Severity: wishlist | | | | When i use a keyword end when referring to matrix entries, example, | | data(2:end), octave-mode.el takes that end to end the block and | | spoils the indentation going forward. | | | | Perhaps the block-end-regexp could use [^:]end instead of end ... | | | | Fair point. Could you possibly prepare a patch? | | You will also need to pay attention to things like (end or ,end | except the latter is valid in contexts other than indexing | expressions, so doing it right will probably require more than a | regexp. | | Also, this should only be a problem with end, since the other endXXX | keywords can't be confused. That's another good reason to use the | more specific keywords when writing Octave code. | | I am trying to clean up the bug record for the octave package in Debian and | I am resurecting this old discussion. I agree with John that the problem | cannot be easily fixed with a mere regexp. Also, I agree that people | writing Octave code should stick to the endXXX keywords. | | Therefore, I have a concrete proposal to fix the problem reported here | once and forever. The patch attached below drops end from the | octave-end-keywords variable, keeping it in octave-reserved-words though. | Furthermore, it drops end from the list of closing statements in | octave-block-match-alist. | | I hope this patch will be suitable upstream. I applied your patch. Note that Emacs also includes the code for Octave mode, so we should probably try to stay in sync with it as well. Thanks, jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296375: [bill@givebillmoney.com: Bug#296375: octave2.1: strftime crashes with an invalid structure as an argument]
On 22-Feb-2005, Laurent Mazet [EMAIL PROTECTED] wrote:
| On Tue, 22 Feb 2005 06:57:53 -0600
| Rafael Laboissiere [EMAIL PROTECTED] wrote:
| package octave2.1
| forwarded 296375 [EMAIL PROTECTED]
| thank
|
|
| Dear Octave maintainers,
|
| I confirm that the problem reported below against the octave2.1 Debian
| package persists in Octave 2.1.65.
|
| tm.year = 2000;
| tm.mon = 1;
| tm.day = 1;
|
| strftime(%Y%m%d, tm)
|
| This patch fixs the uncomplet tm structure
Thanks for the patch. I chose a slightly different solution.
jwe
src/ChangeLog:
2005-02-22 John W. Eaton [EMAIL PROTECTED]
* oct-map.cc (Octave_map::intfield, Octave_map::stringfield):
New functions.
* oct-map.h: Provide decls.
* DLD-FUNCTIONS/time.cc (extract_tm): Use intfield and stringfield
to access map elements.
Index: src/oct-map.cc
===
RCS file: /usr/local/cvsroot/octave/src/oct-map.cc,v
retrieving revision 1.37
diff -u -r1.37 oct-map.cc
--- src/oct-map.cc 9 Nov 2004 18:31:26 - 1.37
+++ src/oct-map.cc 22 Feb 2005 15:22:38 -
@@ -42,6 +42,33 @@
return p != end () ? p-second : Cell ();
}
+int
+Octave_map::intfield (const std::string k, int def_val) const
+{
+ int retval = def_val;
+
+ Cell c = contents (k);
+
+ if (! c.is_empty ())
+retval = c(0).int_value ();
+
+ return retval;
+}
+
+std::string
+Octave_map::stringfield (const std::string k,
+const std::string def_val) const
+{
+ std::string retval = def_val;
+
+ Cell c = contents (k);
+
+ if (! c.is_empty ())
+retval = c(0).string_value ();
+
+ return retval;
+}
+
string_vector
Octave_map::keys (void) const
{
Index: src/oct-map.h
===
RCS file: /usr/local/cvsroot/octave/src/oct-map.h,v
retrieving revision 1.35
diff -u -r1.35 oct-map.h
--- src/oct-map.h 9 Nov 2004 18:31:26 - 1.35
+++ src/oct-map.h 22 Feb 2005 15:22:38 -
@@ -99,6 +99,11 @@
Cell contents (const_iterator p) const
{ return contents (key(p)); }
+ int intfield (const std::string k, int def_val = 0) const;
+
+ std::string stringfield (const std::string k,
+ const std::string def_val = std::string ()) const;
+
const_iterator seek (const std::string k) const { return map.find (k); }
bool contains (const std::string k) const
Index: src/DLD-FUNCTIONS/time.cc
===
RCS file: /usr/local/cvsroot/octave/src/DLD-FUNCTIONS/time.cc,v
retrieving revision 1.18
diff -u -r1.18 time.cc
--- src/DLD-FUNCTIONS/time.cc 22 Sep 2004 12:38:10 - 1.18
+++ src/DLD-FUNCTIONS/time.cc 22 Feb 2005 15:22:39 -
@@ -60,17 +60,17 @@
{
octave_base_tm tm;
- tm.usec (m.contents (usec)(0) . int_value ());
- tm.sec (m.contents (sec)(0) . int_value ());
- tm.min (m.contents (min)(0) . int_value ());
- tm.hour (m.contents (hour)(0) . int_value ());
- tm.mday (m.contents (mday)(0) . int_value ());
- tm.mon (m.contents (mon)(0) . int_value ());
- tm.year (m.contents (year)(0) . int_value ());
- tm.wday (m.contents (wday)(0) . int_value ());
- tm.yday (m.contents (yday)(0) . int_value ());
- tm.isdst (m.contents (isdst)(0) . int_value ());
- tm.zone (m.contents (zone)(0) . string_value ());
+ tm.usec (m.intfield (usec));
+ tm.sec (m.intfield (sec));
+ tm.min (m.intfield (min));
+ tm.hour (m.intfield (hour));
+ tm.mday (m.intfield (mday));
+ tm.mon (m.intfield (mon));
+ tm.year (m.intfield (year));
+ tm.wday (m.intfield (wday));
+ tm.yday (m.intfield (yday));
+ tm.isdst (m.intfield (isdst));
+ tm.zone (m.stringfield (zone));
return tm;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293562: [Pkg-octave-devel] Bug#293562: octave2.1-doc: Provide a pdf version
On 21-Feb-2005, Rafael Laboissiere [EMAIL PROTECTED] wrote: | If nobody objects, I am going to | replace the PS files by the PDF files in the octave2.1-doc package. I don't object. I've been thinking of adding a PDF version of the manual to the core distribution. Now I've done that. I also added rules for the liboctave docs, though they were never complete and are hopelessly out of date now. | A suggestion for the upstream authors: you might include a rule for building | octave.pdf in doc/Makefile.in, something like this: | | octave.pdf: $(MAIN_TEXINFO) $(SUB_TEXINFO) ../conf.texi | -TEXINPUTS=$(srcdir):$(srcdir)/..:$(TEXINPUTS):; \ | export TEXINPUTS; \ | texi2pdf $ Thanks, this is what I used. BTW, I think Dirk will tell you that I'm usually fairly responsive and reasonable when it comes to changes like this, so it might be less work for you to simply propose changes in Octave (with patches if you can) and then wait for those changes to appear in the next snapshot. Then you won't have to add and later remove patches from your package. jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296376: [Pkg-octave-devel] Bug#296376: octave2.1-emacsen: Emacs indents the comments immediately under a function too much
On 21-Feb-2005, Dirk Eddelbuettel [EMAIL PROTECTED] wrote:
| Designed that way, as I recall. Try ## to enfore beginning-of-line.
Yes, it's similar to the Emacs mode for editing Lisp:
# in line comment aligned to the same column at the left of the code
##code level indented comment
### comments that start at the left margin, used occasionally for
comments within functions that should start at the margin
I don't think the Octave mode has the fourth level, which in the Lisp
mode is
comments aligned to the left margin and used for headings
of major sections of a program
If you want to customize this behavior, I think the function to look
at is
(defun octave-comment-indent ()
(if (or (looking-at \\s\\s\\s)
(octave-before-magic-comment-p))
0
(if (looking-at \\s\\s)
(calculate-octave-indent)
(skip-syntax-backward )
(max (if (bolp) 0 (+ 1 (current-column)))
comment-column
jwe
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293235: [Pkg-octave-devel] Bug#293235: octave2.1-emacsen: hangs Emacs
On 15-Feb-2005, Francesco Potorti` [EMAIL PROTECTED] wrote: | If you change the prompt for Octave, you'll need to modify the Emacs | variable inferior-octave-prompt. | | I see. I should have realized that before... | | The default definition is: | | (defcustom inferior-octave-prompt | \\(^octave\\(-[.0-9]+\\)?\\(:[0-9]+\\)?\\|^debug\\|^\\)+ | *Regexp to match prompts for the inferior Octave process. | :type 'regexp | :group 'octave-inferior) | | Hmm. Why not simply ^[^]++ ? That would probably be OK for most cases, though I'm sure some people reset the prompt to things that don't end with . | Or perhaps we should arrange for the prompt to be set when the | Octave process is started by Emacs? | | Anyway, setting PS1 inside .octaverc is useless with run-octave, because | PS1 is then reset to octave . Mh. inferior-octave-startup does it. | Why? I'd guess the goal was to ensure that we could match the prompt. But I'm no longer sure how all this is supposed to work. |But that still would solve the | problem of people changing the prompt during a session. I think I meant would not solve | In principle, the inferior octave mode could detect this and adjust | comint-prompt-regexp accordingly. How would you detect the change? | Or just ignore this problem (as it currently does). Certainly seems simpler. :-/ jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290470: octave2.1: Octave's bug_report needs emacs or $EDITOR
On 18-Jan-2005, Dirk Eddelbuettel [EMAIL PROTECTED] wrote:
| IIRC correctly, Thomas reported that (correctly, I may add) directly to the
| bug list for Octave (this being an upstream issue, after all). In doing so,
| he noticed the bug_report failure. I think I'd consider that upstream too,
| though we could apply a Debian only patch. I general I do not like such
| forks, though.
I'd be happy to fix Octave, but what is the right fix? The bug report
script uses
: ${EDITOR=emacs}
What would be better (and portable)?
jwe
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290470: octave2.1: Octave's bug_report needs emacs or $EDITOR
On 18-Jan-2005, Dirk Eddelbuettel [EMAIL PROTECTED] wrote:
| I don't really know either, or I would have suggested it. We, as you know,
| try to get by without environment variables. A Debian-only fix therefore
| would be to talk to /usr/bin/sensible-editor, which is guaranteed to be
| present. But that doesn't help in the general case for Octave.
|
| It may not be worth going overboard here. You could do some autoconf magic
| to check for emacs, xemacs, vi and remember the choice. Or do that with
| shell when the above is executed.
That would be better, since the binary may be running on a system
different from the one where configure was run.
| In either event, I think it would be fair
| to abort with a message no editor found, tempfile in /tmp/$foo left for
| manual continuation or some such.
I think we already do something like this:
devzero:260 EDITOR=foobar octave-bug
/usr/bin/octave-bug: line 226: foobar: command not found
problems with edit -- no bug report submitted
saving message in /home/jwe/dead-octave-bug-1
OK, I just checked the bashbug script (which I used as the starting
point for octave-bug way back when) and it now uses
if [ -z $DEFEDITOR ] [ -z $EDITOR ]; then
if [ -x /usr/bin/editor ]; then
DEFEDITOR=editor
elif [ -x /usr/local/bin/ce ]; then
DEFEDITOR=ce
elif [ -x /usr/local/bin/emacs ]; then
DEFEDITOR=emacs
elif [ -x /usr/contrib/bin/emacs ]; then
DEFEDITOR=emacs
elif [ -x /usr/bin/emacs ]; then
DEFEDITOR=emacs
elif [ -x /usr/bin/xemacs ]; then
DEFEDITOR=xemacs
elif [ -x /usr/contrib/bin/jove ]; then
DEFEDITOR=jove
elif [ -x /usr/local/bin/jove ]; then
DEFEDITOR=jove
elif [ -x /usr/bin/vi ]; then
DEFEDITOR=vi
else
echo $0: No default editor found: attempting to use vi 2
DEFEDITOR=vi
fi
fi
: ${EDITOR=$DEFEDITOR}
so I'll copy this method.
jwe
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
