From the book Introduction to the Practice of Statistics
Explore the docs »
Report Bug
·
Request Feature
·
View Outputs
This repository contains:
- An OCI (docker) definition for a Jupyter notebook for statistical analysis
- Worked Lisp-Stat examples from the book, Introduction to the Practice of Statistics, ninth edition
- Tools to support publishing example notebooks to GH pages (for use on the lisp-stat.dev documentation website)
You only need the tools if you are developing documention for Lisp-Stat, otherwise you will be using the generated image.
Click on the link above to launch the notebook on mybinder.org. This is probably the option you want.
Codespaces is a recent offering that allows you to run devcontainer online (they offer 60 free hours per month) Use this option if you want to run from VS Code, though you can also use the JupyterLab interface on Codespaces. If it's not obvious how to access Jupyter Lab, see the step-by-step instructions in the cl-jupyter-image (the base image for this repo).
This image is based on Jupyter Docker Stacks and using the image is well documented there, but with an important difference: that is a base image. Here you need to build/run from the Dockerfile, but since we only layer on the statistical computing machinery, the stopping/starting/user/etc. is all the same.
For a quickstart:
# From the directory where Dockerfile is...
docker build -t ips9 .Now you've built the image locally with the name (tag) 'ips9' and it will behave just like any other Jupyter Docker Stacks image. You can start by following the instructions for running the containers. For example:
docker run -it --rm -p 10000:8888 -v "${PWD}":/home/jovyan/work ips9
This command starts your container running a Jupyter Server and exposes the server on host port 10000. The server logs appear in the terminal and include a URL to the Server but with the internal container port (8888) instead of the correct host port (10000). It will mount the current directory into work/ of the image.
See the open issues for a list of proposed features (and known issues). We will include additional examples in the chapter order of the book
This system is part of the Lisp-Stat project; that should be your first stop for information. Also see the
community page for more information.
Contributions are what make the open source community such an amazing place to be learn, inspire, and create. Any contributions you make are greatly appreciated. Please see CONTRIBUTING for details on the code of conduct, and the process for submitting pull requests.
Distributed under the MS-PL License. See LICENSE for more information.
Project Link: https://github.com/lisp-stat/IPS
Unless you are working on Lisp Stat or common-lisp-jupyter, you can ignore this section.
common-lisp-jupyter (JupyterLab) and VS Code take different approaches to cell execution, and there isn't (yet) a good VS Code extension for Common Lisp. If you run a notebook in VS Code you should set the cell language to 'clojure', which is the closest language for which VS Code does have support. You'll lose some of the Common Lisp syntax highlighting, but the cells will run. Here's a detailed explanation of the differences:
- No cell-level language identifiers - cells don't have individual language metadata
- Kernel determines everything - the notebook kernel (Python, R, Julia, Common Lisp, etc.) handles all code execution and language features
- Uniform syntax highlighting - all code cells use the same syntax highlighting based on the kernel language
- Simple model - one kernel = one language for the entire notebook
- Cell-level language metadata - each cell can have its own language identifier
- Hybrid approach - kernel handles execution, but cell language affects editor features
- Per-cell syntax highlighting - each cell can have different syntax highlighting
- More complex - allows mixed-language notebooks (though execution still goes through one kernel)
VS Code's approach allows for:
- Better editor integration - language servers, IntelliSense, error checking per cell
- Mixed content - you could have SQL in one cell, Python in another (with appropriate kernels)
- Consistent editor experience - same language features as regular files
- Flexibility - syntax highlighting can differ from execution kernel
JupyterLab's simpler approach:
- No language confusion - kernel = language
- Consistent experience
- No metadata overhead
VS Code's approach:
- More flexible and powerful
- Can create confusion
- Requires language metadata management
In JupyterLab with a Common Lisp kernel:
- All cells automatically get Common Lisp syntax highlighting
- No need to specify language per cell
- Kernel handles everything
In VS Code:
- You need to set cell language to the closest syntax (Clojure)