ipython notebook using oct2py.ipython extension hangs

[schlichtanders]

this bug was already reported in some earlier version, see http://stackoverflow.com/questions/24999313/octave-hangs-in-ipython
it appeared now again to me with the new oct2py version 2.1

When I use ipython 2.2, octave 3.8, oct2py 2.1 on my Ubuntu 14.04 (everything well linked) simple tests like

%load_ext oct2py.ipython
x = %octave [1 2; 3 4];
x

hang in ipython notebook. The kernel is busy and nothing happens

I uninstall oct2py and installed version oct2py version 1.6 like it was said to work in the above stackoverflow-link, and indeed everything works fine now (of course still not in oct2py 2.1).

[blink1073]

Thanks for the report, I'll take a look.

[blink1073]

Okay, I can replicate the behavior. I should have a fix and a new release today.

[schlichtanders]

That's great to hear! Thank you very much for the effort. will it also be
available on pypi so soon?
Best
Stephan
On Sep 13, 2014 3:18 PM, "Steven Silvester" notifications@github.com
wrote:

Okay, I can replicate the behavior. I should have a fix and a new release
today.

—
Reply to this email directly or view it on GitHub
#55 (comment).

[blink1073]

That is the plan.

[schlichtanders]

Great
On Sep 13, 2014 5:33 PM, "Steven Silvester" notifications@github.com
wrote:

That is the plan.

—
Reply to this email directly or view it on GitHub
#55 (comment).

[blink1073]

The problem is Octave 3.8 is being a bugger and not letting me override the DefaultFigureCreateFcn. If I can't find a workaround, I'll disable inline plotting for Octave 3.8. I'll try again tomorrow.

[blink1073]

I tracked it down to not using the pty module to interact with Octave. I got away with it on 12.04, but apparently not on 14.04. I've almost got it fixed, save for some errant printing.

[blink1073]

Released, thanks again. I added you to CONTRIBUTORS.rst.

[schlichtanders]

Thank you very much.
​ I saw you had a really long night. Impressive commitment.​

​I suppose I am the first one testing the new version ;) The following are
my comments

​The first obvious change is that if I do pip install oct2py, pip does not
only try to install oct2py's current version, but also scipy's. I had to
include many other packages to make the new scipy​ work (and it installed
with many warnings still). Is this wanted?

​I then tried my octave notebook and indeed it does not hang any longer! I
tried to build common figures and it worked. e.g.

%%octave

plot(1:10, sin(1:10))

And right​, now comes the but...

​​
%%octave
p = linspace(0,1, 50);
a_b = [1 1; 0.5 0.5; 1 3; 4 1; 10 10]'; % transpose to enable
for-each-loop (columnwise)
legend_strings = cell();

hold all
for e=a_b
a=e(1); b=e(2);
legend_strings(end+1) = ["a=",num2str(a),", b=", num2str(b)];
plot(p, betapdf(p, a, b), "LineWidth", 2)
end

title("prior distributions"); ylabel("probability"); xlabel("phi")
legend(legend_strings)

​the above outputs no figure with all different colored plots ​on it,
however returns surprisingly ";legend(legend_strings)". Tested directly in
octave, everything runs well and plots and labels the beta-functions.

I uninstalled the new scipy version (using now the ubuntu python-scipy)
just for testing and everything kept to be the same in my little examples.
If I now try "pip install oct2py", it says "Requirements already
satisfied", no prompt to install scipy again.

Hoping that you can regard these new comments rather as help than bad news
I can pretty well imagine that these errors are hard stuff to fix

best,
Stephan

On Sep 14, 2014 1:49 PM, "Steven Silvester" notifications@github.com
wrote:

Released, thanks again. I added you to CONTRIBUTORS.rst.

—
Reply to this email directly or view it on GitHub
#55 (comment).

[blink1073]

I use Anaconda for testing, which only has scipy >= 0.12. I changed it to not install the libraries during install, while still signalling that only scipy >= 0.12 is officially supported. I tried your code on Windows, and it works. I'll try it on Ubuntu 14.04. I'm not sure if I can get rid of the return statement, that is part of the hassle of using pty.

[blink1073]

Hmm, here's what I get:

[[ 0.          0.02040816  0.04081633  0.06122449  0.08163265  0.10204082
   0.12244898  0.14285714  0.16326531  0.18367347  0.20408163  0.2244898
   0.24489796  0.26530612  0.28571429  0.30612245  0.32653061  0.34693878
   0.36734694  0.3877551   0.40816327  0.42857143  0.44897959  0.46938776
   0.48979592  0.51020408  0.53061224  0.55102041  0.57142857  0.59183673
   0.6122449   0.63265306  0.65306122  0.67346939  0.69387755  0.71428571
   0.73469388  0.75510204  0.7755102   0.79591837  0.81632653  0.83673469
   0.85714286  0.87755102  0.89795918  0.91836735  0.93877551  0.95918367
   0.97959184  1.        ]]

[blink1073]

Ah, nevermind. I had removed your inline comment. That is what breaks it.

[blink1073]

Okay, comments are stripped now prior to sending to Octave, and the above code works now. I will release this afternoon.

[blink1073]

2.3 is shipped! Thanks again for the bug reports.

[schlichtanders]

Thank you for all the work. I now tested the new version and everything
works like it did in 1.6 which I used before. Great job!

now in the end, I want to make a wish for a new feature for some future
version -- I hoped that in the newer oct2py version it already might be
available, however it behaved the same as 1.6:
using "%%octave -f svg", the svg images returned looks pretty well, despite
of the legend, where the line-color code of the plot overlaps with the
label. In the png output this is not the case and so far as I can see it
also octave's plots saved as svg do not show this overlap. (The example
from last time is also an example for this behaviour.)
It is only an issue of beauty, but I would be glad to have it.

So thank you once again and have a good start into the week.
best,
Stephan

On 14 September 2014 20:47, Steven Silvester notifications@github.com
wrote:

2.3 is shipped! Thanks again for the bug reports.

—
Reply to this email directly or view it on GitHub
#55 (comment).

[blink1073]

I took a stab at it, but have not yet had a chance to test it in the notebook. If you do not specify the size now, it will not arbitrarily assign it one when saving.

[blink1073]

Sweet, we have svg:

[schlichtanders]

gorgeous

do I get it if I clone github and run "python setup.py install"?

On 15 September 2014 05:16, Steven Silvester notifications@github.com
wrote:

Sweet, we have svg:

[image: image]
https://cloud.githubusercontent.com/assets/2096628/4266757/95236b88-3c86-11e4-8cd5-724ccb55dd3d.png

—
Reply to this email directly or view it on GitHub
#55 (comment).

[blink1073]

Yep, I'm going to wait a little bit before releasing again.

[schlichtanders]

I installed the new version with the following impressive behaviour:

running for example this code:

%%octave -f svg
k = [0:25];
n_phi = [5 0.5; 10 0.2; 10 0.7; 20 0.9; 30 0.1]'; % transpose to enable
for-each-loop (columnwise)
legend_strings = cell();

hold all
for e=n_phi
n=e(1); phi=e(2);
legend_strings(end+1) = ["n=",num2str(n),", phi=", num2str(phi)];
plot(k, binopdf(k, n, phi), "LineWidth", 2)
end

title("likelihood distributions"); ylabel("probability"); xlabel("k")
legend(legend_strings);

​will first draw a plot with a correctly aligned legend flying above
everything. Then this disappears and gets integrated within the normal
output of ipython, however now again the legend is as bad aligned as
before. It is really not serious, but just looks not as perfect.

On 15 September 2014 12:39, Steven Silvester notifications@github.com
wrote:

Yep, I'm going to wait a little bit before releasing again.

—
Reply to this email directly or view it on GitHub
#55 (comment).

[blink1073]

The figure above was from a notebook output on Windows. I'll try on Ubuntu tonight.

[blink1073]

The figure above was from a notebook output on Windows. I'll try on Ubuntu tonight.

[blink1073]

This is what I see on Ubuntu 14.04. Is this not correct?

[schlichtanders]

I just recognized, that the legend I get is left-right reversed to the one
you showed
(I copied it from the screen via shutter, thus it became a png but was
originally a svg)

the same holds by the way for the first plot with correct legend "flying
above"

On 15 September 2014 13:46, Stephan Sahm Stephan.Sahm@gmx.de wrote:

I installed the new version with the following impressive behaviour:

running for example this code:

%%octave -f svg
k = [0:25];
n_phi = [5 0.5; 10 0.2; 10 0.7; 20 0.9; 30 0.1]'; % transpose to enable
for-each-loop (columnwise)
legend_strings = cell();

hold all
for e=n_phi
n=e(1); phi=e(2);
legend_strings(end+1) = ["n=",num2str(n),", phi=", num2str(phi)];
plot(k, binopdf(k, n, phi), "LineWidth", 2)
end

title("likelihood distributions"); ylabel("probability"); xlabel("k")
legend(legend_strings);

​will first draw a plot with a correctly aligned legend flying above
everything. Then this disappears and gets integrated within the normal
output of ipython, however now again the legend is as bad aligned as
before. It is really not serious, but just looks not as perfect.

On 15 September 2014 12:39, Steven Silvester notifications@github.com
wrote:

Yep, I'm going to wait a little bit before releasing again.

—
Reply to this email directly or view it on GitHub
#55 (comment).

[blink1073]

Yes, it looks like they are swapped between Operating Systems, just one of those things I guess...

[blink1073]

Are we good to close this Issue?

[schlichtanders]

now that you ask, I indeed went back to oct2py version1.6 because the
newest version has slight drawbacks considering output of cell-magic
%%octave.

v2.3 just outputs seemingly arbitrary commands, even if they end by ";"
(surpressing output in matlab)
v1.6 works just right, outputting nothing if all lines are ended by ";" or
exactly those lines which do not end on ";"

On 21 September 2014 03:52, Steven Silvester notifications@github.com
wrote:

Are we good to close this Issue?

—
Reply to this email directly or view it on GitHub
#55 (comment).

[blink1073]

Thanks again for the candid feedback. I removed the arbitrary output, would you mind testing again?

[schlichtanders]

I just tried it. I cloned the current github master version.
However, I am quite sorry, the output is now even weirder:

just executing

%%octave

imshow(rand(10,10), interpolation="none");

will first open a new window (indended?), close it again and then print an
immensely big picture with some unintended output-lines in front of it

On 21 September 2014 13:05, Steven Silvester notifications@github.com
wrote:

Thanks again for the candid feedback. I removed the arbitrary output,
would you mind testing again?

—
Reply to this email directly or view it on GitHub
#55 (comment).

[blink1073]

Hmm, I'm not seeing that on Windows, I'll try Ubuntu 14.04.

[blink1073]

I fixed the window opening issue. The huge size is a direct result of not enforcing a size up front anymore (which allowed us to get a nice-looking SVG earlier). If you specify the size, it should look good now.

[schlichtanders]

I pulled today
the weird output disappeared, however the extra windows still open.
I tested a bit further and made the following two cases:

• lines without ";" are still not displayed as in oct2py==1.6
  [image: Inline images 1]

further, it is just the same as long ago, the svg-alignment in linux still
does not work (as also already said, everything is right in the extra
window opening, however not in the end-version. I am not shure, whether
this is easily fixable)

%%octave -f svg
k = [0:25];
n_phi = [5 0.5; 10 0.2; 10 0.7; 20 0.9; 30 0.1]'; % transpose to enable
for-each-loop (columnwise)
legend_strings = cell();

hold all
for e=n_phi
n=e(1); phi=e(2);
legend_strings(end+1) = ["n=",num2str(n),", phi=", num2str(phi)];
plot(k, binopdf(k, n, phi), "LineWidth", 2)
end

title("likelihood distributions"); ylabel("probability"); xlabel("k")
legend(legend_strings);

[image: Inline images 2]

On 21 September 2014 21:34, Steven Silvester notifications@github.com
wrote:

I fixed the window opening issue. The huge size is a direct result of not
enforcing a size up front anymore (which allowed us to get a nice-looking
SVG earlier). If you specify the size, it should look good now.

—
Reply to this email directly or view it on GitHub
#55 (comment).

[blink1073]

Fixed in 3.0.