Topics:
Connor is back! yayyy
JupyterCon presentation 11 May!
JuliaSyntax.jl and ExpressionExplorer.jl
https://github.com/fonsp/Pluto.jl/pull/2526
Gave Paul more ideas! Maybe we could us it as part of ExpressionExplorer.
Then we can get the range for each definition, usage, etc
That will be the lezer thing but from Julia
Maybe then we don't need scopestate_statefield.js ? But right now we also use it for local changes, i.e. when you type code before you click Shift+Enter.
For merging the Operational Transform PR: the dirty cell states will also be shared with the server, so we can add this in that process: for each :push_changes (broadcast of local changes), we can also run JuliaSyntax.jl and make the epxressionexplorer result (with ranges) part of the state/update.
Then we can do cooler things like renaming a variable across the whole notebook! Because the JS based version that we have right now is not accurate enough.
Maybe make a WASM version of just JuliaSyntax.parse 😳
We need to still support Expr to deal with macro expansions. Maybe this works?
ExpressionExplorer.explore(expr::Expr) = JuliaSytax.parse(string(expr))If we publish ExpressionExplorer then there are lots of cool projects that we can do!
Maybe standalone ExpressionExplorer is a bit weird without Pluto's macro handling.
@reactive begin
y = 2 + x
x = 1
endPreparing a talk for JupyterCon! Notes so far:
Hint
reactivity
slider
file format
beknopte geschiedenis van pluto
wat is julia
Ju in Jupyter
computationalthinking
foto grant
een slide met 4 unieke manieren waarop pluto wordt gebruikt
reactiviteit
HTML export – recording
Edit or run
Binder (thebe)
reproducibility
activate notebook environment
accessible mission statement
here at JUPYTERcon, we can look at pluto as an EXPERIMENT, exploration of a specific niche. we hope that some of our ideas and discoveries are transferrable to the jupyterverse!
julia only
home-made backend and frontend (e.g. not a jupyter kernel)
– and the two languages, Julia and JS, are also the languages you use inside notebooks – only modern Julia, modern web browsers supported
focus on julia learners and their teachers
– developed alongside teaching computationalthinking
(each has a con as well, which might not be admissable for other projects like jupyter)
people of all coding levels use it and like it
interactivity should be the core! and actually isn't that why we use notebooks?
because we only support one language, and our backend is written in that language, we can have really
because of some Julia syntax features (macros, using import, multiple dispatch), reactivity requires more than just an isolated "topological sort" (
niet zeggen dat het onmogelijk is als jup kernel
very tempting to make setup more difficult / less reliable (add-ons, powerful features, etc)
Fons van der Plas work at Julia Lab @ MIT
fonsp
fons@mit.edu
altijd aanspreekbaar mailen bellen
leuk om jup ontwikkelaars te ontmoeten
regular meetings, discord server
plutojl.org/contribute
stickers
PlutoSliderServer
PlutoTest time machine
Pluto.jl is a new, open source notebook programming environment for Julia, written in Julia and JavaScript. Our mission is to make Julia more accessible and fun! 🎈
In this talk, we would like to introduce Pluto.jl to the JupyterCon audience, and we will talk specifically about our approach to reproducibility and reactivity. While Pluto.jl is not directly connected to the Jupyter ecosystem, we think that our position (Julia-only, beginners-first) has led to new discoveries and solutions that are exciting to discuss!
We see package management as one of the major hurdles for beginner programmers. It can be intimidating to set up an environment to start programming, but it is especially difficult to set it up in a reproducible way. We want to flip this paradigm: a simple, reproducible environment should be the default, and more advanced users can set up an environment themselves. As a whole, 'scientific computing' has an awful onboarding process, and we scare away so many creative and wonderful people before they are able to contribute. Let's fix that!
One of our goals is to make notebooks reproducible by default. Each notebook file (or HTML export) contains the Manifest.toml file that can be used to exactly recreate the package environment. When you open a Pluto notebook file, the embedded package information is used to automatically recreate the package environment that was used to write it.
A second big feature is automatic package management: instead of a terminal interface, packages are automatically installed and removed as they are used in code. We show package GUI inline in code, and we relay installation progress to the user visually. As a user, it feels like you can simply import any package you want (we even autocomplete all registered package names!), and Pluto takes care of installation and reproducibility.
Pluto notebooks are reactive, which means that – just like a spreadsheet – your notebook forms a computational graph, and cells re-run automatically when one of their dependencies changes. We also have a "managed scope": we delete variables from scope when the definition disappears.
Reactivity makes Pluto fun and interactive, but it also avoids effects from old code lingering around until a restart. Reactivity and managed scope mean that the notebook is always in its correct state, the same state you would get if you would restart the notebook. At any instant, the notebook state is completely defined by the code you see.
Pluto can be installed as a JupyterLab extension, which means that we also run on Binder, the free cloud compute service. We went one step further, and integrated the Binder startup directly into our notebook UI. Inspired by the Thebe project, this allows users to launch a Binder session directly from the website where they are reading a notebook!
Every HTML export file has the original code, and an embedded project environment. But as part of our Binder integration, each HTML file also contains a reference to a version-pinned Binder image, meaning that the exports from Pluto can be re-run in exactly the same environment years into the future.
Pluto is deeply integrated with Julia's package manager, metaprogramming and runtime, something that we were able to freely explore by limiting ourselves to a single language. Originally inspired by Jupyter, which supports more languages and use cases each year, our experiment is to see what happens when we really narrow down our scope: we focus on one language and one audience (Julia newcomers and educators).
We hope to offer an interesting new take on existing topics in the Jupyter ecosystem, and we really look forward to hear what you think!