LFortran works in JupyterLite

Announcements
1

Thanks to great work by Anutosh Bhat and the QuantStack team, LFortran now works in JupyterLite with our main LLVM backend:

So it runs fully in your browser, served with a static website.

12 Likes
SC26 and Fortran
2

Congratulations!

Excellent Epilogue:

When Fortran arrived in 1957, using it meant punching cards, standing in line at the keypunch and the card reader, and waiting for the batch to come back around. Today it means opening a URL, typing a few lines, and pressing Shift+Enter. The formulas look much the same as they did sixty-nine years ago.

What changed is everything around them.

Can the WASM generated by LFortran be included into a static website? That would be a nice way to make some simulation demos. I know Jupyter Notebooks can be published as webpages, but I was just wondering about the more direct route.

1 Like
3

Yes, that’s been done many times, e.g.: The Oregon Trail in the browser – FORTRAN 77 to WebAssembly with LFortran.

1 Like
4

This is a big milestone, and exactly what we need to get Fortran into modern learning environments without friction. Congratulations and thanks to you, Anutosh, the QuantStack and LFortran teams. :tada:

1 Like
5

Section «Play with Fortran» on Learn — Fortran Programming Language currently links to https://dev.lfortran.org/. In comparison with the GUI of JupyterLight the blog post links to, the latter may appeal as one more attractive to beginners (the intended audience?) because of an interface already familiar by using jypyter for Python* including, but not limited to, the optional organization in multiple cells one can rearrange/locally execute, or an import/export of a (previous) session as .ipynb notebook and report generation (for instance .ipynb as input format to pandoc).

In comparison, perhaps except for the output to stdout, the interface of dev.lfortran.org with optional inspection of AST, ASR, etc seems to address an audience with deeper insight / more interest in the inner working and continuous development of LFortran in addition to an interest in Fortran.

This is the reason why I would rise the idea if an instance of JupyterLight were even more advantageous to the learning section’s intent «venture out our language with little risk/without need of an installation» than the already present instance of dev.lfortran.org. This could be complemented by a short note right on fortran-lang how to locally install and setup such an instance with an eventual mutual benefit of the communities of Fortran, LFortran, and jupyter.

* I’m aware jupyter notebooks equally can interact with the BASH shell, recall a presentation about R based on a jupyter notebook; maybe this list of kernels provides a better/more round picture.

1 Like
6

@nbehrnd here are the current differences and pros and cons as I see it (you mentioned some):

JupyterLite:

  • Uses LLVM backend, so almost all Fortran now fully works
  • Slower to load (for example this link took 11s to load for me)
  • Sometimes seems a bit finicky, so there are likely still some bugs to iron out and fix

dev.lfortran.org:

  • Uses our direct WASM backend (not LLVM), which is not as advanced, so not everything compiles yet
  • Fast to load (about 2s for me), can inspect the compiler internals
  • Maybe quicker to get started — just load and press a button to run
  • Seems rock solid, has been working for years without major issues

I was thinking of maybe creating almost identical interface to dev.lfortran.org but powered by JupiterLite, to see if it loads a bit faster, and can be made rock solid. That way it would also be more 1:1 comparison and we can see what the pros/cons are better. It will still be slower to load, but it will support all of Fortran, so should be really usable.

But the JupyterLite is also awesome, that’s what motivated me to create this pure Fortran plotting library: GitHub - certik/fplotlib: Fortran plotting library · GitHub, so that we can plot from it, etc.

So we just need to iterate on this, but I think the hardest is behind us, now we just need to smooth out the user experience.

1 Like
7

@certik Thank you for sharing the additional technical insight.

While testing the instance on GitHub.io you mentioned, I observed the time needed to access the site, then starting the dedicated kernel aware of Fortran again equally depends on the infrastructure I use as a visitor to the site; since both machines tested differ considerably in their age, most likely due to processor and RAM available. The experience of such a \Delta{}\Delta{}t until an application lives in the the browser was not totally new for me (e.g., the InChI demo page).

Best wishes for the further development of LFortran.

1 Like
8

@nbehrnd yes for sure. We need to iterate to speed everything up. And it might be that ultimately we might need to use our own backend, not LLVM. But now it’s “just” a performance issue, not a correctness issue, so that’s great.