I've finally managed to implement `@JupyterLibrary...

# datascience

[holgerbrandl]

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?

[Ilya Muradyan]

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

[Ilya Muradyan]

Wow, the notebook you've created is a real beauty. Awesome introduction to lets-plot

[Ilya Muradyan]

@Igor Alshannikov you may be interested

[holgerbrandl]

Thanks @Ilya Muradyan for the clarification.

[Igor Alshannikov]

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

[holgerbrandl]

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.

[Ilya Muradyan]

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

[holgerbrandl]

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.

[Hampus Londögård]

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?

[holgerbrandl]

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.

[Anatoly Nikitin]

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.

[Hampus Londögård]

@Anatoly Nikitin sounds cool. Is there any thoughts in adding a API like kravis but using lets-plot? 🙂

[Anatoly Nikitin]

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