<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 7, 2015 at 2:22 PM, Andrew Gibiansky <span dir="ltr"><<a href="mailto:andrew.gibiansky@gmail.com" target="_blank">andrew.gibiansky@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Agreed. In my mind, this is something that can be done as part of the kernel.<div><br></div><div>For example, kernelspec.json can specify a list of formats that the kernel accepts as import and export; then messages in the messaging spec can be used to transmit notebook data forward and backward. Trying to make nbconvert or nbconvert wrappers do everything is an infinite problem -- you could instead delegate this to the kernels themselves. This would allow kernels to take all of this effort onto themselves.</div></div></blockquote><div><br></div><div>I wouldn't consider this a kernel feature, but that might be a question of definitions. IHaskell, as a project, may provide *both* a kernel for Jupyter and some advanced notebook export/conversion tools. But I doubt that such things should be a part of the kernel specifications themselves. But we should also hear from other kernel authors about that. If it's something that's common to many kernels, then maybe Jupyter as the coordinating point should define some APIs or at least conventions to follow.</div><div><br></div><div>-MinRK</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Anyway, it's clear that there's some design work to be done here. I'm happy to discuss this further when things come around to it :)</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-- Andrew</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 7, 2015 at 1:44 PM, MinRK <span dir="ltr"><<a href="mailto:benjaminrk@gmail.com" target="_blank">benjaminrk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Sat, Mar 7, 2015 at 1:23 PM, Andrew Gibiansky <span dir="ltr"><<a href="mailto:andrew.gibiansky@gmail.com" target="_blank">andrew.gibiansky@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks Min! That's exactly the sort of feedback I was hoping to get.<div><br></div><div>To respond to your question about what I've found lacking, my main desires for additions to IPython are for a better import and export story for kernels. Specifically, right now IPython supports the following exports:</div><div><ul><li>txt</li><li>PDF via latex</li><li>Markdown</li><li>HTML</li></ul><div>These are all well and good, but they're not enough. In my experience, the formats used vary by technology and community, and thus need to be someone more flexible. Specifically, in the Haskell world, we at least would want the following:</div></div><div><ul><li>Import from literate Haskell (two different types of literate haskell)</li><li>Export to literate Haskell (two different types)</li><li>Export to a Haskell module (which would require some processing to make the cells actually valid compilable Haskell code)</li><li>Export to a cabal package (which would be like exporting to a Haskell module, but with more postprocessing)</li></ul><div>These are things that are pretty integral to the Haskell ecosystem, and so it would make sense to ship them with the IHaskell kernel, and not as some sort of extensions. That said I totally understand why these don't exist (yet) -- there's tons of stuff going on in the IPython world and there's not enough developer manpower to do <i>everything, </i>but I do hope that going forward to 3.1 or 4 or whatever is next, there might be some design work put into a more compelling configurable import/export story.</div></div></div></blockquote><div><br></div></span><div>It is clear that there are changes that need to be made in nbconvert. I was just talking with Jess Hamrick yesterday about some of the changes we should make for nbgrader, another of the more demanding nbconvert use cases, revealing problems in how nbconvert is put together.</div><div><br></div><div>I don't think nbconvert on its own is going to cover quite everything you described. For instance, the cabal package export might be a separate tool that *uses* nbconvert, rather than being implemented as a highly configured invocation of nbconvert itself. And fully custom templates that don't match any of the pre-installed formats are possible right now, but it's not at all clear how to use them, and both how we communicate that, and how they actually work need to be improved.</div><div><br></div><div>It is super helpful to have as many use cases as we can get, even if our answer to some of them is "that's best done with a separate tool that wraps nbconvert," we can still make changes in nbconvert to facilitate these things.</div><span><font color="#888888"><div><br></div><div>-MinRK</div></font></span><div><div><div> <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><font color="#888888"><div><br></div><div>-- Andrew</div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 7, 2015 at 12:17 PM, MinRK <span dir="ltr"><<a href="mailto:benjaminrk@gmail.com" target="_blank">benjaminrk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, Mar 6, 2015 at 11:50 PM, Andrew Gibiansky <span dir="ltr"><<a href="mailto:andrew.gibiansky@gmail.com" target="_blank">andrew.gibiansky@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hey all, <div><br></div><div>I have a few frontend modifications I'd like to make for the IHaskell kernel, and I'd love to get some pointers on where to start and how feasible these are. I have some ideas, but since you are much more familiar with the client-side JS than I am, I'd like to hear if you think these are possible and/or reasonable, and perhaps how you would approach them (no detailed response required, maybe just something like "Use the CodeMirror api" or "we have some undocumented capabilities for this in IPython" or "wait until CodeMirror 5" or "impossible").</div><div><br></div><div>The extensions are:</div><div><br></div><div>1. Get some info about an identifier from the kernel when I hover my mouse over that identifier, and display it as a popup.</div><div><br></div><div>Idea: Use CodeMirror API and IPython comms to communicate with kernel.</div></div></blockquote><div><br></div></span><div>I think CM.coorsChar is the relevant API.</div><div><br></div><div>You might not need to use comms for this one, if `inspect_request` is the right action. If the output should be distinguished from inspection via other means, then a custom comm would be appropriate.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>2. Add a keyboard shortcut to automatically reformat a cell, and have this actually change the contents of whichever cell is currently selected, provided it is a Haskell cell.</div><div><br></div><div>Idea: Use the IPython API to add a keyboard shortcut, use comms to communicate with backend to do reformatting, use IPython API to get currently selected cell and send contents to kernel via comm, and  use  IPython APIs to change the contents of a cell.</div></div></blockquote><div><br></div></span><div>Sounds right to me.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>If you have any suggestions for better routes, words of caution, I'd love to hear them. </div><div><br></div><div>(As an aside, one reason I am asking like this rather than just going ahead and trying it and seeing how far I get is that some of these may be tackled by some other contributors to IHaskell; I would like to make sure I am not sending them off on a wild goose chase with a method that is overcomplicated or unlikely to work before giving them instructions.)</div></div></blockquote><div><br></div></span><div>I see no geese here to chase.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Thanks!</div><span><font color="#888888"><div>Andrew</div></font></span><div><br></div><div>PS. IHaskell `master` now supports IPython 3.0. There's still a bit of work to be done before I'm ready to make a Jupyter-ready *release*, but it is no more than a week or two out. So far, I've really enjoyed working with IPython 3; the interface is great, the kernel interface is well thought out (if perhaps missing a few things I want, but there's always room for extension, I hope :) ), and all in all it's been very good.</div></div></blockquote><div><br></div></span><div>Great to hear that 3.0 is working out for you. Can you describe the missing things? It may be a while before there's another revision, but it's good to keep track of what shortcomings kernel authors find, so we can make the right adjustments in the future.</div><div><br></div><div>-MinRK</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org" target="_blank">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
<br></blockquote></div><br></div></div>
<br>_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org" target="_blank">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org" target="_blank">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
<br></blockquote></div></div></div><br></div></div>
<br>_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org" target="_blank">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
<br></blockquote></div><br></div></div>