Re: D kernel for Jupyter notebook
On Sunday, 19 August 2018 at 20:33:45 UTC, Laeeth Isharc wrote: Proof of concept works, but it requires some further development to be useful to do work in. [...] Great. I have tried DUB integration. It seems to work. https://github.com/ShigekiKarita/grain/blob/master/example/repl.d
Re: D kernel for Jupyter notebook
On Sunday, 19 August 2018 at 20:33:45 UTC, Laeeth Isharc wrote: Proof of concept works, but it requires some further development to be useful to do work in. https://github.com/kaleidicassociates/jupyterd It uses D repl currently - this was written for a console interface and probably you will encounter difficulties running it in a notebook environment. I guess one would like to treat all functions defined in a single notebook as part of the same session and to execute immediate statements as part of a main specific to that cell. The kernel is a bit flakey - takes time to come on line and you might need to reconnect to it sometimes. To Do: 1.Add HTML and markdown table output to display arrays of structs or of dicts in a useful manner 2.Integrate with mir and other numeric libraries 3.Integrate with charting 4.Consider adding to Dlang tour and run.dlang.io when stable 5.Integrate with dpp 6.Integrate with dub 1 and 3 should be quite simple. One wouldn't want to write a large program in Jupyter, but it's helpful for exploratory data analysis and programming where the code that does the work is already in D. Note that the D repl will only work on platforms where drepl works i.e. platform with shared library support. It will _build_ on OSX due to https://github.com/kaleidicassociates/jupyterd/blob/master/source/jupyterd/kernel.d#L393 but it won't work.
D kernel for Jupyter notebook
Proof of concept works, but it requires some further development to be useful to do work in. https://github.com/kaleidicassociates/jupyterd It uses D repl currently - this was written for a console interface and probably you will encounter difficulties running it in a notebook environment. I guess one would like to treat all functions defined in a single notebook as part of the same session and to execute immediate statements as part of a main specific to that cell. The kernel is a bit flakey - takes time to come on line and you might need to reconnect to it sometimes. To Do: 1.Add HTML and markdown table output to display arrays of structs or of dicts in a useful manner 2.Integrate with mir and other numeric libraries 3.Integrate with charting 4.Consider adding to Dlang tour and run.dlang.io when stable 5.Integrate with dpp 6.Integrate with dub 1 and 3 should be quite simple. One wouldn't want to write a large program in Jupyter, but it's helpful for exploratory data analysis and programming where the code that does the work is already in D.
Re: LDC 1.11.0
On Sunday, 19 August 2018 at 12:56:28 UTC, Matthias Klumpp wrote: [...] Does that Git has thing work if there is no Git involved? ;-) [...] Ewww, looks like I can't write today... At the moment, we get ``` LDC - the LLVM D compiler (1.8.0): based on DMD v2.078.3 and LLVM 5.0.2 built with LDC - the LLVM D compiler (0.17.5) ``` unconditionally - if I switch to a ltsmaster snapshot, it will likely display 0.17.6 with no direct way of knowing which snapshot was taken. (I could manually record that as an info file in the package, so it at least is recorded somewhere, but that's not easily accessible at all...)
Re: LDC 1.11.0
On Sunday, 19 August 2018 at 12:48:15 UTC, kinke wrote: [...] The used host compiler, incl. git hash if untagged, can be found in the --version output: ``` LDC - the LLVM D compiler (1.12.0git-1c87fd7): based on DMD v2.082.0 and LLVM 6.0.0 built with LDC - the LLVM D compiler (0.17.6git-79d2284) ``` Does that Git has thing work if there is no Git involved? ;-) To make this work I will have to download a tarball of ltsmaster, with no Git involved to get the hash from.
Re: LDC 1.11.0
On Sunday, 19 August 2018 at 12:36:07 UTC, Matthias Klumpp wrote: The thing is, a release is actually tremendously helpful for the Debian packaging - we are using the latest tagged version there for ages. I could, if you think that it is a good idea, just use a snapshot of the current ltsmaster Git branch That'd be no work for us, so I'd clearly prefer it this way. ;) but that makes it harder to track with which ltsmaster state the Debian package was actually built with. The used host compiler, incl. git hash if untagged, can be found in the --version output: ``` LDC - the LLVM D compiler (1.12.0git-1c87fd7): based on DMD v2.082.0 and LLVM 6.0.0 built with LDC - the LLVM D compiler (0.17.6git-79d2284) ```
Re: LDC 1.11.0
On Sunday, 19 August 2018 at 10:11:42 UTC, 鲜卑拓跋枫 wrote: And hope the subsequent LDC releases with LLVM 7.0 will be mature enough on AArch64 and RISC-V for production environment. Hope is good, contributing better. ;) AArch64 needs polishing, wading through the logs and analyzing & fixing (or disabling/adapting unfitting tests) the remaining test failures. As to RISC-V, I don't think there's any library support at all right now, so there's probably still a long way to go for something close to being usable. Claiming (and maintaining) production-readiness requires a CI service for RISC-V.
Re: LDC 1.11.0
On Sunday, 19 August 2018 at 12:23:37 UTC, kinke wrote: On Saturday, 18 August 2018 at 21:05:42 UTC, Matthias Klumpp wrote: Will we get a release of the ltsmaster branch as well? From the release notes it sounds like building with a more recent version is a good idea... Using latest ltsmaster is always a good idea. I'm a bit reluctant to tag a new version, as it's a moving target (e.g., needed another adaptation yesterday in order to be able to bootstrap 2.082-based LDC, and will need more adaptations in a few weeks for LLVM 7...). 0.17.6 has been stuck in the pipeline for half a year now; perhaps we finally manage after LLVM 7 is supported. The thing is, a release is actually tremendously helpful for the Debian packaging - we are using the latest tagged version there for ages. I could, if you think that it is a good idea, just use a snapshot of the current ltsmaster Git branch, but that makes it harder to track with which ltsmaster state the Debian package was actually built with.
Re: LDC 1.11.0
On Saturday, 18 August 2018 at 21:05:42 UTC, Matthias Klumpp wrote: Will we get a release of the ltsmaster branch as well? From the release notes it sounds like building with a more recent version is a good idea... Using latest ltsmaster is always a good idea. I'm a bit reluctant to tag a new version, as it's a moving target (e.g., needed another adaptation yesterday in order to be able to bootstrap 2.082-based LDC, and will need more adaptations in a few weeks for LLVM 7...). 0.17.6 has been stuck in the pipeline for half a year now; perhaps we finally manage after LLVM 7 is supported.
Re: LDC 1.11.0
Many thanks for your effort! And hope the subsequent LDC releases with LLVM 7.0 will be mature enough on AArch64 and RISC-V for production environment. On Saturday, 18 August 2018 at 16:47:35 UTC, kinke wrote: Glad to announce LDC 1.11: * Based on D 2.081.2. * Prebuilt packages now using LLVM 6.0.1 and including additional cross-compilation targets (MIPS, MSP430, RISC-V and WebAssembly). * Rudimentary support for compiling & linking directly to WebAssembly. See the dedicated Wiki page [1] for how to get started. * AArch64 (64-bit ARM) now mostly working on Linux/glibc and Android. * Some support for classes without TypeInfos, for -betterC and/or a minimal (d)runtime. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.11.0 Thanks to all contributors! [1] https://wiki.dlang.org/Generating_WebAssembly_with_LDC es
