User:Andy1978
ToDo
Core
fix imread bug with opaque images, see https://savannah.gnu.org/bugs/?func=detailitem&item_id=36820Thanks CarneFFTW multithreaded https://savannah.gnu.org/patch/?7922remove removed but still referenced function in "seealso" blocks
- Add swisdom (single prec.) to /libinterp/dldfcn/fftw.cc documentation
- linguist-qt4: octave-src/libgui$ lupdate -recursive src qterminal -ts languages/de_DE.ts
GUI
When opening and closing the GUI HDF5: infinite loop closing library
Forge
signal or fltk plotting?
pkg load signal t=0:1/4e4:12; y=chirp(t,100,5,18000); graphics_toolkit fltk specgram(y)
-> r300: Implementation error: Render targets are too big in r300_set_framebuffer_state, refusing to bind framebuffer state!
video
fix build, see http://octave.1599824.n4.nabble.com/quot-package-video-is-empty-quot-td4656346.html
signal
- findpeaks.m, print error if data is not a column vector (error: vertical dimensions mismatch (1x10000 vs 1x1)
FAQ for windows user
octave-forge packages on windows
You should follow the README for the binary octave bundle, for example http://wiki.octave.org/Octave_for_Windows#Octave-3.6.4-mingw_.2B_octaveforge_pkgs
The additional forge-pkgs (ex. Octave3.6.4_gcc4.6.2_pkgs_20130331.7z) contains the already compiled packages for the specific (Octave-3.6.4) version.
Normally windows users can't just install octave forge packages with
pkg install package
or
pkg install -forge package
because their system lacks a build system with autotools, make, c++ compiler etc.
image
- implement SURF, integralImage is cumsum(cumsum(a,1),2)
corner/cornermetric, harris
First post on mailing list in 12.01.2013 http://octave.1599824.n4.nabble.com/corner-cornermetric-equivalent-in-octave-td4648802.html
brainstorming
- something like autobuilder for octave would be cool. Jordi mentioned http://hydra.nixos.org/jobset/gnu/octave-default
- perhaps http://www.phoronix-test-suite.com/?
Snippets
chain matrix multiplication
a=[1 2; 3 4];
b=[4 2; 8 1];
c=[2 3; 1 -1];
m=cat(3,a,b,c);
s=cell(3,1);
s{1}=a;s{2}=b; s{3}=c;
a*b*c
s{1}*s{2}*s{3}
mtimes(num2cell(m,[1,2]){:})
mtimes(s{:})
commands from which I regularly doesn't find the name
- octave_config_info ()
libgraphicsmagick++3 quantum-depth
in debian wheezy
sudo apt-get build-dep libgraphicsmagick++3 apt-get source libgraphicsmagick++3
edit debian/rules
--with-quantum-depth=16 \
works without problems
--with-quantum-depth=32 \
shows one error:
UYVY format ... mean-error=0.0209018218321559, maximum-error=0.816509137487552 not ok 77 Failed 1/77 subtests
debuild -i -us -uc -b dpkg -i ....
Tracking octave bugs with hg bisect
I had a strange problem when loading gzip compressed ascii files in octave. It failed dependent on the integer values. After some stripping I made a minimalistic test script (min_testcase_fails.m) which always fails in a current dev (88616c872933):
fn="file2.txt"
fid = fopen (fn,"w");
fprintf(fid, "%i %i %i %i\n",639, 25, 160, 978160);
fprintf(fid, "%i %i %i %i\n",687, 25, 171, 978160);
fprintf(fid, "%i %i %i %i\n",663, 31, 173, 978161);
fprintf(fid, "%i %i %i %i\n",663, 15, 154, 978161);
fprintf(fid, "%i %i %i %i\n",655, 21, 151, 978161);
fclose(fid);
## gzip it!
fn_gz=strcat(fn, ".gz");
cmd=cstrcat("gzip ",fn," -c > ",fn_gz)
system(cmd);
c=load("file2.txt.gz") #this fails in newer versions
When run:
$ octave -q min_testcase_fails.m fn = file2.txt cmd = gzip file2.txt -c > file2.txt.gz error: value on right hand side of assignment is undefined error: called from: error: /home/andy/src/octave-bugs/min_testcase_fails.m at line 17, column 2
If line 4 with "663, 15, 154, 978161" is changed to ""663, 16, 154, 978161", load works as expected. Strange, isn't it? I also had an old build (dev ab1c6e6d1be6 from Sun Oct 28 21:48:02 2012) and "load" worked in this version.
Running bisect
I decided to make a fresh clone in a separate directory:
cd ~/src hg clone http://www.octave.org/hg/octave octave-src cd octave-src hg bisect -b 88616c872933 hg bisect -g ab1c6e6d1be6
After this hg bisect uses a binary search strategy to test revisions:
Teste Änderungssatz 16428:f016a5342e19 (1380 Änderungssätze verbleiben, ~10 Tests)
So after checkout I had to compile the source tree (used ccache in the hope of faster checkout-compile cycles).
./bootstrap cd .. && mkdir octave-build && cd octave-build export CXX="ccache g++" export CC="ccache gcc" ../octave-src/configure make -j 7
After compilation I tried my test min_testcase_fails.m:
~/src/octave-build$ ./run-octave -q ../min_testcase_fails.m
fn = file2.txt
cmd = gzip file2.txt -c > file2.txt.gz
c =
639 25 160 978160
687 25 171 978160
663 31 173 978161
663 15 154 978161
655 21 151 978161
So this is apparently a good one. Tell it hg bisect!
cd ../octave-src && hg bisect -g
After this you try make again, bootstrap && configure if make fails, rerun the testscript, tell hg bisect if it's good or bad and repeat this until the revision which introduced the problem is found. Or you can use "hg bisect --command", see next point.
hg bisect --command
I used Jordis bisect script for bug 32818 and modified it to my needs:
~/src$ cat bisect-loadsave.sh #!/bin/bash SRCDIR=~/src/octave-src BUILDDIR=~/src/octave-build cd $SRCDIR ## Try a simple build first if ! make -j 7 then cd $SRCDIR ./bootstrap || exit 127 #rm -rf $BUILDDIR #mkdir $BUILDDIR cd $BUILDDIR $SRCDIR/configure || exit 127 make -j 7|| exit 127 fi $BUILDDIR/run-octave -q ~/src/min_testcase_fails.m || exit 1 exit 0
After making it executable, let hg bisect use it
~/src/octave-src$ hg bisect -c ../bisect-loadsave.sh
Now sit back and relax, this could last some hours... Finally:
Änderungssatz 16554:03a28487fa9d: good Die erste fehlerhafte Revision ist: Änderung: 16555:04fb96f4bea1 Nutzer: John W. Eaton <jwe@octave.org> Datum: Tue Apr 23 12:57:16 2013 -0400 Zusammenfassung: allow double-click in file browser to load data files