3 ms·

Nice! From what I've gathered this has been in the works for a while(?) Thoughts ... 1. Yea, the Readme could do with a bit of polish. Your hero feature, AF

by maegul 3y ago

Nice! From what I've gathered this has been in the works for a while(?) Thoughts ... 1. Yea, the Readme could do with a bit of polish. Your hero feature, AFAIU, is the automatic reactivity. This is in your second GIF, put this front and center and make it really clear what is happening. You (and I) know what reactivity looks like so we know what to look for, but someone new to the idea in notebooks could easily blink and miss this. I'd work on a nicer GIF and even a little youtube video just to make it really clear what's going on here. Bostock and ObservableHQ advertised their reactivity a while ago, you might be able to get inspiration for how they demonstrated it? 2. The syntax extensions are cool! Integration with ipywidgets is Ace!! 3. Do you have any comments on how ObservableHQ (Javascript runtime by Bostock) and Pluto (inspired by previous) informed or inspired your choices and implementation here? Is this basically the same for python/jupyter as those are for JS/Julia? 4. Annoying Questions or feature requests ... Are there any overheads? Any timeout facilities for long running code? Can the full variable and/or cell dependency graph be surfaced and visualised (ObservableHQ put this into the UI a while back and it was kinda cool). Otherwise ... awesome to see this land! Congratulations!!!

smacke 3y ago
Thank you for all the feedback, positive and constructive! Yep docs definitely need a lot of polish :) 3. I actually started from scratch -- ipyflow's reactivity model is a bit different from these, since for Python, my experience is that static dependency inference is too unreliable to be useful. (Though after talking with the Pluto maintainer earlier today it sounds like Pluto may be reaching some of the same conclusions and also be moving toward a dynamic dependency inference strategy) In the future, my hope is that as a community we will develop a live-coding analogue to lsps which one might call a "language kernel protocol" so that we can standardize some of these features across different languages / editors 4. For top-level / module-level statements, yes there is lots of overhead (> 100x), but it's largely limited to those statements (i.e. external library calls, recursive function calls, etc have close to 0 overhead thanks to intelligent instrumentation disabling for these) and turns out to be OK in practice (more details in nbslicer paper https://smacke.net/papers/nbslicer.pdf https://smacke.net/papers/nbslicer.pdf). At some point I'll run it through a profiler and try to grab the low-hanging optimizations but it hasn't been noticeable so far. Surfacing the DAG is definitely something I want to do at some point; we have all the information in the backend so we should try to surface it in the frontend.

by maegul 3y ago

smacke 3y ago

Thank you for all the feedback, positive and constructive! Yep docs definitely need a lot of polish :) 3. I actually started from scratch -- ipyflow's reactivity model is a bit different from these, since for Python, my experience is that static dependency inference is too unreliable to be useful. (Though after talking with the Pluto maintainer earlier today it sounds like Pluto may be reaching some of the same conclusions and also be moving toward a dynamic dependency inference strategy) In the future, my hope is that as a community we will develop a live-coding analogue to lsps which one might call a "language kernel protocol" so that we can standardize some of these features across different languages / editors 4. For top-level / module-level statements, yes there is lots of overhead (> 100x), but it's largely limited to those statements (i.e. external library calls, recursive function calls, etc have close to 0 overhead thanks to intelligent instrumentation disabling for these) and turns out to be OK in practice (more details in nbslicer paper https://smacke.net/papers/nbslicer.pdf https://smacke.net/papers/nbslicer.pdf). At some point I'll run it through a profiler and try to grab the low-hanging optimizations but it hasn't been noticeable so far. Surfacing the DAG is definitely something I want to do at some point; we have all the information in the backend so we should try to surface it in the frontend.