DLang Jupyter Kernel

[wilzbach]

It would be great to have a D Kernel for the Jupyter project (it's quite huge and basically every language is supported).

Documentation:

http://ipython.readthedocs.io/en/stable/development/index.html

Overview of existing kernels:

https://github.com/ipython/ipython/wiki/IPython-kernels-for-other-languages

[MartinNowak]

Yes, interesting indeed. Does that really need a REPL interface or could it be done via batch execution?

[wilzbach]

Does that really need a REPL interface or could it be done via batch execution?

It's very similar to a REPL (imho it's one), because you need to keep track of the stack / currently available symbols.

[wilzbach]

could it be done via batch execution?

Btw if you are unfamiliar with Jupyter, you can try a couple of Notebooks online
https://try.jupyter.org/

[wilzbach]

A couple of popular kernels for statically typed languages:

https://github.com/gibiansky/IHaskell
https://github.com/gophergala2016/gophernotes
https://github.com/mattpap/IScala
https://github.com/Bachmann1234/java9_kernel
https://github.com/robbielynch/ierlang
https://github.com/andrewray/iocaml

[carljv]

I believe there are some that just execute cells as batch, but typically aren't able to share state across cells and are otherwise pretty limited. The ones in interpreted languages, or languages with a REPL seem to work better.

[m3m0ry]

Just to revive this issue a little bit.
Since there is now jupyter-wire in D I have done some experiments: dlang-jupyter

I basically just connected the packages drepl and jupyter-wire. Nothing fancy so far.
It works (somewhat). Yes it has its limitations. But I spend only 4 hours, 3 of which were just me being stupid.

[m3m0ry]

Current limitations:
I have a weird behavior with imports. (this is probably due to fact that drepl doesn't expect 2 lines at a time???)

import std.stdio;
import std.algorithm;

The second one won't work,because only the first one is imported as public.

I have also seen some issues with variable declarations/statements as well (which according to unittests here should work).

The general question is: should I try to fix it in my package, or should we make changes/adjustments/improvements to drepl?
(I'd say it depends. In this example, i would think that drepl should be able to handle multiple statements at once)

[wilzbach]

The general question is: should I try to fix it in my package, or should we make changes/adjustments/improvements to drepl?

It looks like all your issues could be fixed in drepl, so that's very likely the way to go. The drepl isn't set into stone, so it's definitely possible to improve.