jupyter-vim VS tup

In this config, under the Plugins folder there are various plugins that aren't found in the Astrocommunity repo (aka "Custom" plugins). A great example that I found interesting and included into my own config was mehalters repl.lua file that installs the jupyter-vim plugin. From my limited understanding to install packages into astrovim, we need to make a file in the Plugins folder, make the necessary configurations, and then it should load.

Is there any way to communicate with jupyter like jupyter-vim? I am aware of python-repl in emacs, but it does not support inline plots/figures. Moreover, it is nice to nice to show outputs in different windows (especially using multiple monitors).

Now here comes the endboss: Jupyter. For the first time, I feel like I'm missing out on stuff when using vim. I've started a job in datascience, which is actually awesome. However, I work a lot with image data. I also do a lot of analysis on results, meaning I do a lot of fancy plots that hopefully show the weaknesses of our prediction models. I recently wrote an augmentation algorithm where I had to see the output in form of an image after every step to make sure it's correct. This is not a possible workflow in vim right now. I know of many solutions that I already tried, like for example jupyter-vim or the jupyter vim mode. I'd like to work inside my terminal though. I'm not this kind of purist who needs to have a terminal that is compatible with VT100 or whatever people came up with in the 80ies. I also don't care if my terminal in based on an ascii like grid or actually rendered in HTML. I just want (Neo)vim, with the functionality of jupyter (inline plotting) even if this means vim has to be rendered inside an electron app or whatever people use these days for fancy GUIs. Imagine an electron based editor like Oni which not only runs the "real" neovim in the background, but is also able to do inline figures, images, plots and even interactive stuff. It seems to me like I can't be the only one who wants this. So after all this, here's the question: Is there anything you now of that allows for this kind of stuff? Is there any other workflow that I'm not aware of? Or do people just not use those features when working with vim? Pls help a vimmer stay at vim.

For Matlab-like "cell-mode", have a look at https://github.com/jupyter-vim/jupyter-vim/.

To work in a py file (or py codelines selection from whatever format): https://github.com/jupyter-vim/jupyter-vim

Whenever looking at one these, I think back to the obscure but interesting "tup":

“How is it so awesome? In a typical build system, the dependency arrows go down. Although this is the way they would naturally go due to gravity, it is unfortunately also where the enemy's gate is. This makes it very inefficient and unfriendly. In tup, the arrows go up.”

https://gittup.org/tup/

Once upon a time, you could roll your own of this using `tup` which might have my favorite "how it works" in the readme:

How is it so awesome?

In a typical build system, the dependency arrows go down. Although this is the way they would naturally go due to gravity, it is unfortunately also where the enemy's gate is. This makes it very inefficient and unfriendly. In tup, the arrows go up. This is obviously true because it rhymes. See how the dependencies differ in make and tup:

[ Make vs. Tup ]

See the difference? The arrows go up. This makes it very fast.

https://gittup.org/tup/

Also has a whitepaper: https://gittup.org/tup/build_system_rules_and_algorithms.pdf

Ten years ago, I used reStructuredText and its support for LaTeX math and syntax highlighting. I used tup (tup monitor -a -f) to take care of running rst2html on save.

I might be showing my ignorance here, but this just sounds like Tup? https://gittup.org/tup/

I agree. While I like the idea of tup (https://gittup.org/tup/ -- the first "forward" build system I remember hearing of), writing a makefile is easy enough that thinking about the problem upside-down doesn't offer a compelling reason to switch.

Ptrace is one option for tracing dependencies, but it comes with a performance hit. A low-level alternative would be ftrace (https://lwn.net/Articles/608497/) or dtrace (https://en.wikipedia.org/wiki/DTrace).

Tup uses LD_PRELOAD (or equivalent) to intercept calls to C file i/o functions. On OSX it looks DYLD_INSERT_LIBRARIES would be the equivalent.

* order-only prerequisites - X must happen before Y if it's happening but a change in X doesn't trigger Y

This is just a small selection and there are missing things (like how to handle rules that affect multiple targets).

It's all horrible and complex because like a lot of languages there's a manual listing the features but not much in the way of motivations for how or why you'd use them so you have to find that out by painful experience.

It's also very difficult to address the warts and problems in (GNU) make because it's so critical to the build systems of so many packages that any breaking change could end up being a disaster for 1000s of packages used in your favorite linux distribution or even bits of Android and so on.

So it's in a very constrained situation BECAUSE of it's "popularity".

Make is also not a good way to logically describe your build/work - something like Meson would be better - where you can describe on the one hand what a "program" model was as a kind of class or interface and on the other an implementation of the many nasty operating system specific details of how to build an item of that class or type.

Make has so many complex possible ways of operating (sometimes not all needed) that it can be hard to think about.

The things that Make can do end up slowing it down as a parser such that for large builds the time to parse the makefile becomes significant.

Make uses a dependency tree - when builds get large one starts to want an Inverted Dependency Tree. i.e. instead of working out what the aim of the build is and therefore what subcomponents need to be checked for changes we start with what changed and that gives us a list of actions that have to be taken. This sidesteps parsing of a huge makefile with a lot of build information in it that is mostly not relevant at all to the things that have changed. TUP is the first tool I know about that used this approach and having been burned hard by make and ninja when it comes to parsing huge makefiles (ninja is better but still slow) I think TUP's answer is the best https://gittup.org/tup/

You might enjoy Tup[1] if you've not checked it out before.

[1]: https://gittup.org/tup/