Editing User:Andy1978



== ToDo ==

=== Core ===
* fix imread bug with opaque images, see https://savannah.gnu.org/bugs/?func=detailitem&item_id=36820
* remove removed but still referenced function in "seealso" blocks
* <strike>FFTW multithreaded https://savannah.gnu.org/patch/?7922</strike>

=== Forge ===

==== image ====

* implement [http://en.wikipedia.org/wiki/SURF 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{:})

== 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

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:
<pre>~/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
</pre>
good or bad?

 cd ../octave-src && hg bisect -g

After this you try make again, bootstrap && configure if this fails, run the testscript, tell hg bisect if its 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 [http://jordi.platinum.linux.pl/tmp/bisect-32818.sh 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