Problems opening notebooks with inline images (yes, I read issue #121)

[millejoh]

Check list

• I read "Avoid standard Emacs traps" section in
  https://github.com/tkf/emacs-ipython-notebook/blob/master/CONTRIBUTING.md
• I checked that IPython works with the browser interface.
• I checked that the problem was not due to badly compiled
  files. Removing *.elc files from source directory of EIN and
  its dependencies did not solve the problem.
• I checked that the libraries are loaded from intended place.
  (You can check the location in the "System info" section below)

Description of the problem you have

Looks like repeat of issue #121 even with commit 146fc45 applied. Below is the output in Messages:

ein: [info] Opening notebook e4f8d516-3978-4b85-be7e-50062bce23d8...
Contacting host: 127.0.0.1:8888
ein: [info] Kernel started: 23955ec1-7c75-4fab-8f65-63b95ba6c849
ein: [info] Starting WS: "ws://127.0.0.1:8888/kernels/23955ec1-7c75-4fab-8f65-63b95ba6c849"
ein: [info] Unknown event: status_busy.Kernel
ein: [info] Unknown event: execution_count.Kernel
ein: [info] Unknown event: status_idle.Kernel

Here is what IPython is logging:

2013-07-31 10:58:58.934 [NotebookApp] Using existing kernel: 23955ec1-7c75-4fab-
8f65-63b95ba6c849
2013-07-31 10:58:59.005 [NotebookApp] Connecting to: tcp://127.0.0.1:58694
2013-07-31 10:58:59.015 [NotebookApp] Connecting to: tcp://127.0.0.1:58693

The handshake is working, but maybe some essential setup (event callback binding?) isn't occurring???

Wish I knew where else to look. ein-notifications.el looks like it defines events for status_idle.Kernel and status_busy.Kernel - so I'm confused why ein:events-trigger seems to think those events don't exist.

It looks like the event callback hashtable (you probably have a better name for that structure) isn't getting set up properly. My edebug-fu is pretty weak so I'm not sure how to view what is actually in the event hashtable when ein:events-trigger is called.

Maybe ein:notification-bind-events isn't getting called soon enough?

What else could I look at to try debugging?

Steps to reproduce the problem

1. Open notebook list.
2. Open notebook containing inline images.
3. Watch the notbook not open! (Unhappy face here).

Expected output

Opened notebook.

Your EIN configuration (in .emacs.d/init.el or somewhere else)

Downloaded from melpa, with commit 146fc45 applied.

Your IPython configuration

1. What is your IPython version? (run ipython --version):

1.0.0a1

1. How do you start IPython? (e.g., ipython notebook --port 9999):

C:\Python33\Scripts\ipython3.exe notebook --pylab=inline

1. What is your IPython notebook port number or URL?:

8888

Additional information (if any)

System info:

("EIN system info"
 :emacs-version "GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601)
 of 2013-03-17 on MARVIN"
 :emacs-bzr-version nil
 :window-system w32
 :emacs-variant nil
 :os
 (:uname nil
     :lsb-release nil)
 :image-types
 (png gif tiff jpeg xpm xbm pbm)
 :image-types-available
 (xpm xbm pbm)
 :request
 (:backend url-retrieve)
 :ein
 (:version "0.2.1alpha2"
       :source-dir "c:/Users/e341194/.emacs.d/elpa/ein-20130710.2114/")
 :lib
 ((:name "websocket"
     :path "~/.emacs.d/elpa/websocket-20130706.1746/websocket.elc"
     :featurep t
     :version-var websocket-version
     :version "1.01")
  (:name "request"
     :path "~/.emacs.d/elpa/request-20130526.1915/request.elc"
     :featurep t
     :version-var request-version
     :version "0.2.0")
  (:name "auto-complete"
     :path "~/.emacs.d/elpa/auto-complete-20130724.1750/auto-complete.elc"
     :featurep t
     :version-var nil
     :version nil)
  (:name "auto-complete"
     :path "~/.emacs.d/elpa/auto-complete-20130724.1750/auto-complete.elc"
     :featurep t
     :version-var nil
     :version nil)
  (:name "popup"
     :path "~/.emacs.d/elpa/popup-20130324.1305/popup.elc"
     :featurep t
     :version-var popup-version
     :version "0.5.0")
  (:name "python"
     :path "c:/emacs/lisp/progmodes/python.elc"
     :featurep nil
     :version-var nil
     :version nil)
  (:name "markdown-mode"
     :path "~/.emacs.d/elpa/markdown-mode-20130726.2142/markdown-mode.elc"
     :featurep nil
     :version-var nil
     :version nil)))

[millejoh]

A bit more information: looks like ein gets as far as creating a buffer for the notebook and loading the contents of the notebook into the buffer up to where the inline image appears.

[millejoh]

And even more info. I opened the notebook in using the browser interface and eliminate the cell generating the inline image. Now the notebook opens fine in ein. When I, however, try to execute code that generates an inline image using the ein interface the result is no image, simply "<matplotlib.image.AxesImage at 0x5687590>" (i.e. the repr of the object) and the following messages:

Error (websocket): in callback on-message': Unbound slot: "#<class ein:codecell>", "#<ein:codecell Cell>", :events, oref Error (websocket): in callbackon-message': Unbound slot: "#", "#<ein:codecell Cell>", :events, oref
Error (websocket): in callback on-message': error: "Not an image: nil" Error (websocket): in callbackon-message': Unbound slot: "#", "#<ein:codecell Cell>", :events, oref

I am using matplotlib 1.3.0rc5 - wonder if that is causing the problem. Let's see what happens when I downgrade...

And later...

Downgraded to 1.2.1 and ... still have the same problem and same messages. So much for that brilliant idea.

And even later...

Think I have it - ipython is returning a png image, but according to 'image-type-available-p' png is not an available type. Looks like this is a problem with my Windows installation of Emacs, not ein. I'll root around a bit more and report back if/how I solve the problem...

[millejoh]

And success! Apparently not any version of libpng will do (as Stack overflow implied), but Wisdom and Wonder's link to libpng14-14 did the trick.

Amazing.

[tkf]

Apparently the related issue was #117

Sorry for the delay and thanks for your investigation. We should make the error message and manual more informative: #118

[millejoh]

Thanks - don't worry about the delay, it motivated me to look further into the issue. It was good mental exercise trying to figure out what was happening. I certainly could have done a better job looking through the issue archives before submitting the bug report.

It all became clear quite quickly once I started seeing the websocket messages, which I didn't see until I had called ein:dev-start-debug.

I think it might be good to at least add this step (call ein:dev-start-debug) to the checklist for the bug report template.

I appreciate the email. Good work on the tool, it's been very useful!

Regards,

John

On Aug 03, 2013, at 03:09 PM, Takafumi Arakaki notifications@github.com wrote:

Apparently the related issue was #117
Sorry for the delay and thanks for your investigation. We should make the error message and manual more informative: #118
—
Reply to this email directly or view it on GitHub.