IPython notebook hangs about oct2py HOT 92 CLOSED

Sorry @dhermes didn't reply. I'm in a similar scenario to him and still seeing a hang. I saw your instructions above, and got it unstuck using -g. However, now it matches the failure that I get in my linux installation.

Thoughts? (Please be a bit patient- I'm likely to only be able to test a solution this weekend).

from oct2py.

That was my laptop. Works fine on my desktop (previous stacktrace was erroneous).

It seems causing the entire laptop to hang is related to windowing / UI frameworks but I'm not very familiar with them.

As a (potentially helpful) start, I have the following matplotlib plotting backends:

    OPTIONAL BACKEND EXTENSIONS
                    macosx: no  [Mac OS-X only]
                    qt5agg: no  [PyQt5 not found]
                    qt4agg: yes [installing, Qt: 4.8.6, PyQt: 4.8.6]
                    pyside: yes [installing, Qt: 4.8.6, PySide: 1.2.1]
                   gtk3agg: yes [installing, version 3.8.10]
                 gtk3cairo: yes [installing, version 3.8.10]
                    gtkagg: yes [installing, Gtk: 2.24.23 pygtk: 2.24.0]
                     tkagg: yes [installing, version 81008]
                     wxagg: yes [installing, version 2.8.12.1]
                       gtk: yes [installing, Gtk: 2.24.23 pygtk: 2.24.0]
                       agg: yes [installing]
                     cairo: yes [installing, pycairo version 1.8.8]
                 windowing: no  [Microsoft Windows only]

from oct2py.

Sorry @dhermes, I just saw this Issue report. Do you have gnuplot-x11 installed?

from oct2py.

Yes:

$ dpkg -s gnuplot-x11
Package: gnuplot-x11
Status: install ok installed
Priority: optional
Section: math
...

Should it be un-installed? (i.e. is that a good thing or a bad thing)

from oct2py.

Hmm, can you try firing up just ipython (no notebook) and running %paste with this code on your clipboard:

from oct2py import octave
octave.eval("""
subplot(121);
[x, y] = meshgrid(0:0.1:3);
r = sin(x - 0.5).^2 + cos(y - 0.5).^2;
surf(x, y, r);

subplot(122);
sombrero()
""")

from oct2py.

@blink1073 It works just fine from IPython.

from oct2py.

How about this (from ipython), copy this to clipboard:

%%octave -g
subplot(121);
[x, y] = meshgrid(0:0.1:3);
r = sin(x - 0.5).^2 + cos(y - 0.5).^2;
surf(x, y, r);
subplot(122);
sombrero()

And run this IPython session:

In [1]:  %load_ext oct2py.ipython
In [2]:  %paste

from oct2py.

No issues there either.

I need to re-run the offending notebook (haven't since 11/6). It may be a heisenbug based on some transient kernel / install issue that no longer exists.

I will update after trying (it may take awhile if I have to reboot my machine).

UPDATE: @blink1073 it still brings my machine to its knees.

from oct2py.

Sometimes I have to kill my .ipython folder to clear up notebook issues.

On Fri, Dec 19, 2014 at 8:45 PM, Danny Hermes [email protected]
wrote:

No issues there either.

I need to re-run the offending notebook (haven't since 11/6). It may be a
heisenbug based on some transient kernel / install issue that no longer
exists.

I will update after trying (it may take awhile if I have to reboot my
machine).

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

from oct2py.

I blew up ~/.ipython and it still brought the machine to its knees.

The %%octave -s 500,500 statements are what cause the issue. I isolated this for both of the cells (butterworth filter and sombrero) and got the same behavior.

from oct2py.

Does using the size argument have the same effect in the console (just adding it to my example above)?

from oct2py.

@blink1073 The size argument is the deal breaker. It caused the same issue from the console. I still had to reboot.

from oct2py.

I tried an almost identical setup on my machine with no failures:

$ /usr/bin/ipython --version
2.3.1
silvester: ~ 
$ sudo pip show oct2py
---
Name: oct2py
Version: 2.4.0
Location: /usr/local/lib/python2.7/dist-packages
Requires: 
silvester: ~ 
$ cat /etc/lsb-release
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=17
DISTRIB_CODENAME=qiana
DISTRIB_DESCRIPTION="Linux Mint 17 Qiana"
silvester: ~ 
$ octave --version
GNU Octave, version 3.8.1

Perhaps try uncommenting this line (it should be commented in the released version) and run again from the console?

from oct2py.

Yes I have a Desktop set up identically with no issues. It has to be some low-level library that either isn't installed on one machine or that doesn't work with the drivers on the laptop.

I adding the logging and tried a few things.

I ran just from oct2py import octave and the only thing logged was

'NoneType' object has no attribute 'terminate'

on exit. (This was the same if I executed octave.eval(...) after the import.)

Just loading %load_ext oct2py.ipython resulted in

'NoneType' object has no attribute 'write'
'NoneType' object has no attribute 'terminate'

on exit. Executing the sombrero plot with -g (which works fine) I got a large log output but it doesn't seem to be insightful.

Executing with -s (the butterworth snippet from the example notebook) the log was identical except for the code snippet. (I didn't get a chance to capture because the computer froze.)

from oct2py.

Yep, I'm at a loss. The only thing I can think of that might do it is setting the DefaultFigurePosition might not work with your setup. You could try commenting out those lines and see if it works.

from oct2py.

I'm happy to dig into the source to debug, I'm just unfamiliar with how -g and -s pass from IPython to your extension. Can you provide some pointers?

from oct2py.

When you pass -s, the magic function passes the height and width to Oct2Py.eval, which then gets the appropriate plotting commands from Oct2Py._get_plot_commands. This function adds Octave commands to set the figure size (using DefaultFigurePostion), and to optionally save the figure to a file (if the plot dir was set).

If the -g flag is not set, the plot_dir is set to a temp directory, which the magic function reads and passes to IPython, and the Octave plot window is not shown. I don't think the -g flag is your problem, but you could try leaving it out.

from oct2py.

So two interesting things have happened.

1. I've traved the error to _Session.evaluate, particularly self.write when the output is the command wrapped with some other stuff.
2. When Chrome is closed, my computer does not freeze. However, the command still takes about 15 seconds to complete and no plot is ever created. I also tried this with Chrome closed, but Firefox open, and there are no issues there.

Any thoughts?

from oct2py.

I have no idea about your second item, but there's a couple more things we can check. How about:

from oct2py import octave
octave.eval("set(0, 'DefaultFigurePosition', [300, 200, 500, 500]);")
print('one')
octave.eval("__oct2py_figures = [];")
print('two')
octave.eval("close all;")
print('three')
octave.eval("__oct2py_figure_visible = 'off';")
print('four')
octave.eval("plot([1,2,3])")
print('five')

from oct2py.

(preferrably from the IPython prompt using %paste)

from oct2py.

That works just fine and creates a plot. (With Chrome open, whatever issue that might be responsible for.)

from oct2py.

Grasping at straws (trying to mimic the OctaveMagic function call)...

from oct2py import octave
octave.eval("set(0, 'DefaultFigurePosition', [300, 200, 500, 500]);", return_both=True, verbose=False)
print('one')
octave.eval("__oct2py_figures = [];", return_both=True, verbose=False)
print('two')
octave.eval("close all;", return_both=True, verbose=False)
print('three')
octave.eval("__oct2py_figure_visible = 'off';", return_both=True, verbose=False)
print('four')
octave.eval("plot([1,2,3])", return_both=True, verbose=False)
print('five')

from oct2py.

ISTM the issue is process contention and I don't fully understand what is happening when you write to an active process:

    def write(self, message):
        """Write a message to the process using utf-8 encoding"""
        os.write(self.wfid, message.encode('utf-8'))

Also, I captured the output after using -g and it seems that

• __oct2py_figures never gets populated in the -g case or the -s case
• -s doesn't make a plot from the console because there is no drawnow("expose") statement (this is probably not true)

from oct2py.

• The write method is the same one used by pexpect when writing to a child process stdin. I don't think that's the problem, but IPC is a black art.
• You can tell if __oct2py_figures is getting populated by not using -g and adding disp(outfile) after the outfile = sprintf(...) line in core.py.
• drawnow is tied to -g, not -s (it should be there when -g is set, because it forces the Octave plot window to draw).

from oct2py.

Hi @dhermes, would you care to try this with the latest version (3.5) and see if it works for you?

from oct2py.

@josephcslater, I'll look at this after we get Calysto/octave_kernel#50 fixed.

from oct2py.

Thanks. Let me know if I can test anything.

from oct2py.

@josephcslater, your issue should be fixed by upgrading oct2py to v3.5.10.

from oct2py.

Unfortunately, it's still hanging.

%load_ext oct2py.ipython
%%octave
a = 1:10
disp(a)

Just hangs.

Likewise

x = %octave [1 2; 3 4];
x

hangs.

How do I verify that the update "stuck" and I am loading the new extension?

from oct2py.

I just tried it again on Ubuntu 14.04, and it is working fine, can you verify the following?

In [1]: import oct2py; oct2py.__version__
Out[1]: '3.5.10'

from oct2py.

Confirmed.

Works fine on my Ubuntu installation as well. Failing on my Mac.

from oct2py.

Ah, I had to follow the "Using Aquaterm with Gnuplot" from http://wiki.octave.org/Octave_for_MacOS_X to get it to work on my Mac.

from oct2py.

I'm not even trying to plot. Should this matter?

from oct2py.

Yes because oct2py doesn't know if you are trying to plot until after you run the command, so we treat every command as a possible plotting command.

from oct2py.

Hmmm, so this may not work for me. What I have working is octave 4.0.3 installed using macports (not brew). It plots via xterm, not aquaterm . Not sure where to go from here.

from oct2py.

I don't think this is my problem. I just ran gnu plot, changed the terminal to aqua (set term aqua) and plotting followed fine. So, gnu plot will recognize aqua. It may be that I need to set the default to aqua for oct2py interacting with it to work?

from oct2py.

That shouldn't be required, AFAIK. Are you able to plot from octave-cli without changing any settings?

from oct2py.

Yes.

from oct2py.

At least this isn't (so far?) the face plant of my issue #50 (I owe you a beer for that level of stupid on my part!).

from oct2py.

I'm not entirely sure where to go from here. I am not keen to install Macports and spending another round of debugging the inner loop at the moment.

from oct2py.

I get it. Have an idea how I could trace it?

from oct2py.

It's not a strong need of mine right now, but more of a "this would be nice to have", so I appreciate how much you've already put into it.

from oct2py.

You could try putting print statements in the inner evaluate function, that is essentially what I ended up doing this morning to debug the Homebrew plotting. I'll be afk for the rest of the day.

from oct2py.

Thank you, and enjoy the time away.

Sent from my iPhone

On Nov 19, 2016, at 12:14 PM, Steven Silvester [email protected] wrote:

You could try putting print statements in the inner evaluate function, that is essentially what I ended up doing this morning to debug the Homebrew plotting. I'll be afk for the rest of the day.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

from oct2py.

Okay, I think the problem is trying to do control flow logic (for loops in this case) through the pipe, which is too brittle. v3.6.0 adds a separate _make_figs.m function that encapsulates the logic. Do you mind testing that release?

from oct2py.

Works! Thanks!

That you would ask if I mind... I owe it to you (and other freeware authors (which I am as well) to do so. Thank you for coming back to this.

FWIW: The failure happened even when no figures were involved. Further, figures are indeed working.

In light of this: I thought I should test your demo ipynb, it unfortunately failed on the cell

%%octave -s 500,500

# butterworth filter, order 2, cutoff pi/2 radians
b = [0.292893218813452  0.585786437626905  0.292893218813452];
a = [1  0  0.171572875253810];
freqz(b, a, 32);

the fail results being:

---------------------------------------------------------------------------
ExpatError                                Traceback (most recent call last)
<ipython-input-10-bca0f2444242> in <module>()
----> 1 get_ipython().run_cell_magic('octave', '-s 500,500', '\n# butterworth filter, order 2, cutoff pi/2 radians\nb = [0.292893218813452  0.585786437626905  0.292893218813452];\na = [1  0  0.171572875253810];\nfreqz(b, a, 32);')

/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/IPython/core/interactiveshell.py in run_cell_magic(self, magic_name, line, cell)
   2113             magic_arg_s = self.var_expand(line, stack_depth)
   2114             with self.builtin_trap:
-> 2115                 result = fn(magic_arg_s, cell)
   2116             return result
   2117 

<decorator-gen-124> in octave(self, line, cell, local_ns)

/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/IPython/core/magic.py in <lambda>(f, *a, **k)
    186     # but it's overkill for just that one bit of state.
    187     def magic_deco(arg):
--> 188         call = lambda f, *a, **k: f(*a, **k)
    189 
    190         if callable(arg):

/Users/jslater/Library/Python/3.5/lib/python/site-packages/oct2py/ipython/octavemagic.py in octave(self, line, cell, local_ns)
    337             if plot_format == 'svg':
    338                 image = self._fix_gnuplot_svg_size(image, size=(plot_width,
--> 339                                                                 plot_height))
    340             display_data.append((key, {plot_mime_type: image}))
    341 

/Users/jslater/Library/Python/3.5/lib/python/site-packages/oct2py/ipython/octavemagic.py in _fix_gnuplot_svg_size(self, image, size)
    109 
    110         """
--> 111         (svg,) = minidom.parseString(image).getElementsByTagName('svg')
    112         viewbox = svg.getAttribute('viewBox').split(' ')
    113 

/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/xml/dom/minidom.py in parseString(string, parser)
   1966     if parser is None:
   1967         from xml.dom import expatbuilder
-> 1968         return expatbuilder.parseString(string)
   1969     else:
   1970         from xml.dom import pulldom

/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/xml/dom/expatbuilder.py in parseString(string, namespaces)
    923     else:
    924         builder = ExpatBuilder()
--> 925     return builder.parseString(string)
    926 
    927 

/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/xml/dom/expatbuilder.py in parseString(self, string)
    221         parser = self.getParser()
    222         try:
--> 223             parser.Parse(string, True)
    224             self._setup_subset(string)
    225         except ParseEscape:

ExpatError: not well-formed (invalid token): line 189, column 92

from oct2py.

Now hanging is:

%%octave -s 600,200 -f png
# Note: On Windows, this will not show the plots unless Ghostscript is installed.

subplot(121);
[x, y] = meshgrid(0:0.1:3);
r = sin(x - 0.5).^2 + cos(y - 0.5).^2;
surf(x, y, r);

subplot(122);
sombrero()

from oct2py.

The final cell (using the octave plotting GUI) works fine.

Of course, order matters. It can't be executed with the others hanging.

from oct2py.

Also hanging is:

%%octave -f svg
# Note: On Windows, this will not show the plots unless Ghostscript is installed.

subplot(121);
[x, y] = meshgrid(0:0.1:3);
r = sin(x - 0.5).^2 + cos(y - 0.5).^2;
surf(x, y, r);

subplot(122);
sombrero()

Interrupting yields the following. I have no idea of the value:

---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-3-7e66b99b039b> in <module>()
----> 1 get_ipython().run_cell_magic('octave', '-f svg', '# Note: On Windows, this will not show the plots unless Ghostscript is installed.\n\nfigure(1)\nsubplot(121);\n[x, y] = meshgrid(0:0.1:3);\nr = sin(x - 0.5).^2 + cos(y - 0.5).^2;\nsurf(x, y, r);\n\nsubplot(122);\nsombrero()')

/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/IPython/core/interactiveshell.py in run_cell_magic(self, magic_name, line, cell)
   2113             magic_arg_s = self.var_expand(line, stack_depth)
   2114             with self.builtin_trap:
-> 2115                 result = fn(magic_arg_s, cell)
   2116             return result
   2117 

<decorator-gen-124> in octave(self, line, cell, local_ns)

/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/IPython/core/magic.py in <lambda>(f, *a, **k)
    186     # but it's overkill for just that one bit of state.
    187     def magic_deco(arg):
--> 188         call = lambda f, *a, **k: f(*a, **k)
    189 
    190         if callable(arg):

/Users/jslater/Library/Python/3.5/lib/python/site-packages/oct2py/ipython/octavemagic.py in octave(self, line, cell, local_ns)
    305                                                 plot_name=plot_name,
    306                                                 verbose=False,
--> 307                                                 return_both=True)
    308         except oct2py.Oct2PyError as exception:
    309             msg = str(exception)

ValueError: too many values to unpack (expected 2)

However, it works fine with the -g option.

from oct2py.

Thanks again for the reports @josephcslater, I'll try to sneak in some time to work on this over the holiday.

from oct2py.

It's hard. I know. I can't even get nose tests to work on one of my packages on travis-ci. I know (believe) the package works, but I'd like to eventually be able to rely on nose tests to determine release. Programing gremlins are the worst time sinks.

from oct2py.

I tracked down the issue to gnuplot creating an invalid SVG file in this case:

from oct2py.

egad. I suppose the only solution is a bug report to gnuplot.

from oct2py.

I have a work-around coming, it ends up loading as such (notice the error character in the caption):

from oct2py.

7581f39 has the fix. The sombrero example is showing no output at all for me on OSX, I'll look at that next.

from oct2py.

I released 3.6.1 that should address the problems you saw.

from oct2py.

I dread saying this, but indeed that plot works, but

# Note: On Windows, this will not show the plots unless Ghostscript is installed.

subplot(121);
[x, y] = meshgrid(0:0.1:3);
r = sin(x - 0.5).^2 + cos(y - 0.5).^2;
surf(x, y, r);

subplot(122);
sombrero()

hangs now, along with the subsequent `%%octave -f svg cell.

from oct2py.

The second cell will never execute if the first hangs. Are you able to execute both if you change the first to:

%%octave -s 600,200 -f svg
# Note: On Windows, this will not show the plots unless Ghostscript is installed.

subplot(121);
[x, y] = meshgrid(0:0.1:3);
r = sin(x - 0.5).^2 + cos(y - 0.5).^2;
surf(x, y, r);

subplot(122);
sombrero()

from oct2py.

"The second cell will never execute if the first hangs. Are you able to execute both if you change the first to:"

Of course. I restarted the entire notebook to test the second cell, skipping the one that had hung.

Tested, and indeed, the answer is unfortunately "no."

from oct2py.

Let's try and rule this out from an Octave session:

subplot(121);
[x, y] = meshgrid(0:0.1:3);
r = sin(x - 0.5).^2 + cos(y - 0.5).^2;
surf(x, y, r);

subplot(122);
sombrero()
print(gcf, 'test.png')
print(gcf, 'test.svg')

from oct2py.

There are three ways for me to launch: from terminal, octave or octave-cli, of double clicking in the GUI.

The first two work fine as long as I'm launching from a directory I can write to. If not, it hangs. I got to that thought only after running from the GUI and realizing it defaults to /, which is non-user writable.

That seems like it. The issue might be that octave is launching with pwd set to /. The trick may very well be to set that to /tmp or pretty much anything else (if only to test). After that, of course, in the software design process you want the file saved to some appropriate place, which is likely the directory that jupyter notebook was launched from. I have no idea how easy/hard this is. It's either trivial or a pain, but that depends on how your code works (which is a bit of voodoo to me!).

from oct2py.

We can change directory to your home directory at startup with this change (note it adds cd to the list of commands on that line). Does making this change allow your notebook to run?

diff --git a/oct2py/core.py b/oct2py/core.py
index e4bf3f5..3846679 100644
--- a/oct2py/core.py
+++ b/oct2py/core.py
@@ -860,7 +860,7 @@ class _Session(object):
     def _handle_first_run(self):
         here = os.path.realpath(os.path.dirname(__file__))
         here = here.replace(os.path.sep, '/')
-        self.write('disp(available_graphics_toolkits());more off;addpath(genpath("%s"));disp(char(3))\n' % here)
+        self.write('disp(available_graphics_toolkits());more off;cd;addpath(genpath("%s"));disp(char(3))\n' % here)
         resp = self.expect(chr(3))
         if not os.name == 'nt':
             try:

from oct2py.

I presume there is a simple way to apply this, I'm going to manually edit the file core.py for the sake of expediency. Excuse my barbarism.

from oct2py.

Hack away ;). Applying a git diff is not high on the list of intuitive tasks to do ;).

from oct2py.

I've applied such before... but don't trust myself.

Nevertheless, :(. This failed. I also tried to explicitly put in a path that would be clearly writable. To my desktop, with and without training /.

from oct2py.

%%octave  -f svg
# Note: On Windows, this will not show the plots unless Ghostscript is installed.

subplot(121);
[x, y] = meshgrid(0:0.1:3);
r = sin(x - 0.5).^2 + cos(y - 0.5).^2;
surf(x, y, r);

subplot(122);
sombrero()

works,
but

%%octave -s 600,200 -f svg
# Note: On Windows, this will not show the plots unless Ghostscript is installed.

subplot(121);
[x, y] = meshgrid(0:0.1:3);
r = sin(x - 0.5).^2 + cos(y - 0.5).^2;
surf(x, y, r);

subplot(122);
sombrero()

fails.

Clearly the -s option is the issue.

from oct2py.

%%octave -f svg -s 600,200 (swapping order of arguments) did not help.

from oct2py.

That is weird, because the height and width are getting set either way even if you don't specify them.

from oct2py.

The fact that what I said makes no sense did not elude me.

from oct2py.

So, as a piece of information that I can't understand,

%%octave -s 500,500
# Note: On Windows, this will not show the plots unless Ghostscript is installed.

subplot(121);
[x, y] = meshgrid(0:0.1:3);
r = sin(x - 0.5).^2 + cos(y - 0.5).^2;
surf(x, y, r);

subplot(122);
sombrero()

doesn't work, but

%%octave -s 500,500

# butterworth filter, order 2, cutoff pi/2 radians
b = [0.292893218813452  0.585786437626905  0.292893218813452];
a = [1  0  0.171572875253810];
freqz(b, a, 32);

does.

from oct2py.

Ready to flip out? I've made progress (dramatic pause).

from oct2py.

The comment line:

# Note: On Windows, this will not show the plots unless Ghostscript is installed.

needed to be removed.

from oct2py.

The png example is still failing... I'm working on editing the cell itself to see of the comment line is an issue.

from oct2py.

%%octave -s 600,200 -f png

subplot(121);
[x, y] = meshgrid(0:0.1:3);
r = sin(x - 0.5).^2 + cos(y - 0.5).^2;
surf(x, y, r);

subplot(122);
sombrero()

works, but

%%octave -s 600,200 -f png

% Note: On Windows, this will not show the plots unless Ghostscript is installed.

subplot(121);
[x, y] = meshgrid(0:0.1:3);
r = sin(x - 0.5).^2 + cos(y - 0.5).^2;
surf(x, y, r);

subplot(122);
sombrero()

doesn't.

lmao.

from oct2py.

So, it seems that a comment line before you get to code causes a problem, regardless of using # or %.

In the middle: unchecked. I think at the end doesn't matter (last example) because the work is already done.

from oct2py.

Of course, that's apparently not always true, as the buterworth example has been working fine all along.

Removing the comment in that example does not fix the odd character issue, btw. I thought I'd try, though I didn't expect it to.

from oct2py.

So...

for the butterworth example,
%%octave -f svg -s 200,600

does to change the size at all.

Neither does

%%octave -s 200,600
versus
%%octave -s 500,500

It seems the first line parsing has some odd issue that it's ignoring something, including getting messed up when there is a subsequent comment line.

from oct2py.

Some extreme numbers in sizing show that it does something, but I think something in Jupyter is rescaling, and Octave might be doing something similar. It's hard to find a value to it's use right now watching what I'm seeing. The result is coming through clean by default.

from oct2py.

(tyfys)

from oct2py.

We have two problems: our ability to differentiate between a %magic and a % comment, and yes, I did notice that our ability to set the size is wonky. I am going to take a break for this for a while, at least we made some progress ;).

from oct2py.

It is also # comments that have problems. Easy enough to work around (avoid) for the user, but programming may be impossible as it's possible jupyter chews up anything after a % so you are stuck with it feeding oct2py comment garbage that you can't interpret.

I'm betting your wife is giving you a hard time. I'm in work, and this is more fun that what I need to be doing. You taking a break may save my marriage.

from oct2py.

Right, Octave supports either kind of comment character: https://www.gnu.org/software/octave/doc/v4.0.3/Single-Line-Comments.html

This could be related to how we're evaluating the input, I have been meaning to switch to the method used by pymatbridge. Their method of setting the image size is also better. The image size handling I can add soon, the other my family would not appreciate right now ;).

from oct2py.

I might need a couch tonight the way my day is going.

from oct2py.

I don't need anything quickly on this, so don't do it for me.

from oct2py.

v3.6.2 should fix the size wonkiness. Thanks for all the detailed follow-ups :).

from oct2py.

Everything seems to work, sizing seems better (I have't thoroughly tested), but comments still break it. (even in the 3.6.3 release).

from oct2py.

FWIW: The README.rst section regarding crate.io should be removed.

.. image:: https://pypip.in/d/oct2py/badge.png
        :target: https://crate.io/packages/oct2py/

I'm not familiar with crate.io, but it seems to no longer work as a mirror for pypi.

I should probably have cloned, pull requested, etc., but for a trivial change it seems just a tad silly.

I'm likely to try to use oct2py as a template for my packages array_to_latex and vibration_toolbox, so helping out helps me as well.

Right now I feel like they are held together with duct tape. I definitely feel like a monkey banging on keyboard when working on them!

from oct2py.

Thanks for the heads up, I removed the badge. Yup, writing libraries is hard. This was my first one, and I'm still learning after 5 years ;).

from oct2py.

My career path has taken me far from this, but coding is my outlet and helps me feel like I'm still relevant in modern computing. Can I ask- for the life of me I can't see how the oct2py web pages end up being served on github. I didn't find the repository, I see the make files and all, but in my head I would have to build at my terminal to an html out directory that I would also have defined as a repository on github. It's exactly how I built vibrationtoolbox.github.io. I'd like to to better going forward, but boy it seems mystifying to me. Your .travis.yml file gave me some thoughts on some of my issues, though. Sorry for detouring from the thread, but I have no idea where else to ask.

from oct2py.

By default, the github.io site points to the index.html in the root directory of the gh-pages branch of the repo. Recently they added the ability to point the page to other locations, in the settings for the repo.

from oct2py.

My mind just got blown.

So, the pages are in the sources directory, but the make file makes the pages and puts them in a separate branch somehow? I think in this.

gh-pages:
	git checkout master
	git pull origin master
	cp oct2py/tests/*.m example
	git commit -a -m "Keep examples in sync"; true
	git push origin; true
	make docs
	ghp-import -n -p -m $(GHP_MSG) docs/_build/html

This will take a while to deconstruct.

from oct2py.

The last two lines are all you should need. It builds the docs and uses the ghp-import python package to publish automagically. See the docs for the package for what the options mean.

from oct2py.