I've finally managed to implement

@JupyterLibrary

support for

krangl

and

kravis

in https://github.com/holgerbrandl/krangl/blob/master/CHANGES.md#v017 and https://github.com/holgerbrandl/kravis/blob/master/CHANGES.md#v08. I took the opportunity to improve krangl-interop with

lets-plot

and have rebuilt one of my favourite R/ggplot teaching examples in kotlin&jupyter. Enjoy https://nbviewer.jupyter.org/github/holgerbrandl/krangl/blob/master/examples/jupyter/sleep_patterns.ipynb. Feel welcome with feedback and criticism. @Ilya Muradyan What is the intended process for the jsons such as https://github.com/Kotlin/kotlin-jupyter/blob/master/libraries/krangl.json? Are they legacy and will be kept, or will they be removed as soon as a library adopts the new integration model?

Thank you! I'll take a look. These jsons may be kept just for having a short name for referring the library jar. Description and link may be also left because they are reflected in readme. Imports, renderers, init and other sections should be removed from json and maintained by library author in the integration code. I'll update the descriptors for krangl and kravis correspondingly the next week

Thanks @Ilya Muradyan for the clarification.

Great job @holgerbrandl! BTW, I didn't know that syntax with %use is legacy style.

Oh, I was/am wrong here then. I just got this impression while studying https://blog.jetbrains.com/kotlin/2021/04/kotlin-kernel-for-jupyter-notebook-v0-9-0/ And also to me the new format seemed more consistent with kotlin-scripting and is more reproducible (because of versioning), so I went with it. Clearly, I also understand @Ilya Muradyan s point that a short concise format may provide a better user experience.

Descriptors may be also versioned by refs in this repo: https://github.com/Kotlin/kotlin-jupyter-libraries I.e.

%use krangl@241c80d57

will always use this version of descriptor: https://github.com/Kotlin/kotlin-jupyter-libraries/blob/241c80d57fd4ea1d9b2b10f5c1b2db81640427ff/krangl.json

Cool, I did not know about that. I've fixed my workbook accordingly in https://github.com/holgerbrandl/krangl/commit/01a6a6c46c954dda7671c8a4cb6063a5a1cedc46 to not provide any wrong information to the reader.

Just as a question: Why do we have two separate efforts at DataFrame (

krangl

and

Kotlin/dataframe

)? Is there some type of roadmap difference where one aims at one thing and the other at another?

My impression is that the small kotlin data science community is still struggling  to converge to a common theme here. kotlin/dataframe is using very neat compiler tricks to provide a typed interface, whereas krangl seems more complete to me in terms of features. One design flaw in krangl which we/I still need to correct is the failed attempt to build a vectorized api similar to its R counterpart dplyr. To me the current state is simply not user friendly enough and does not fall in line with the nice collection apis in stdlib. Clearly this will impact overall library performance, but I guess that the pill we have to swallow to provide an intuitive kotlinesque API. My hope is, that from kotlinDL and related efforts some performant framework will emerge which could be used to build a fast and scalable dataframe API on top. In any case, it still seems a long road ahead of us.

Hi all!

DataFrame

started as

krangl

fork, but then dipped into experiments with typed API, null safety and data hierarchies. Currently DataFrame is targeting two main design goals: 1. Create new typed, intuitive, toolable and powerful API for data manipulations 2. Support hierarchical data structures (e.g. JSON input) It is still in experimental state, but I’m going to present it soon and involve more people in design, discussions and development.

@Anatoly Nikitin sounds cool. Is there any thoughts in adding a API like

kravis

but using

lets-plot

? 🙂

@Hampus Londögård Yes, I have prototype of integration with lets-plot here: https://github.com/nikitinas/lets-plot-dsl