fstamour/breeze

Experiments on workflow with common lisp

👋 Hi, I’m Francis St-Amour

Support my common lisp projects (mainly breeze): https://ko-fi.com/fstamour

breeze's Issues

New version of eclector released

https://github.com/s-expressionists/Eclector/releases/tag/0.9.0

Easier to run specific tests

Something like that

https://github.com/felixjb/testify

add docstring generator

Make a screencast of the features of breeze

Possible solutions:

emacs-director to drive emacs (example: emacs-run-command's demo.el)

emacs-gif-screencast to make gifs

keycast to show the key strokes (in the modeline)

asciinema or termtosvg

CI: run notes.org's elisp code in the pipeline

I have some emacs lisp code in notes.org that does some light validation on the tasks in notes.org.

It would be nice to run that automatically.

I should start by making a small scripts, then add it to my local git hooks (the pre-commit probably), and finally add it to the CI.

Please, enable github-pages for the docs folder.

Or give a link to the page: https://htmlpreview.github.io/?https://github.com/fstamour/breeze/blob/master/docs/index.html

But it is better to enable github-pages.

Add tutorials

Add to quicklisp

What do I want to be done before I add this to quicklisp??

• A tad more tests
• A tad more integrations (e.g. with parachute at least)
• Create a tag/release

add tests for the "capture" and "scaffold" commands

The "capture" and "scaffold" features are very much under-tested.

They're very good candidates for the "demo" a.k.a integration tests.

breeze update

Look into adding git hook to generate the doc before pushing or commiting

I keep forgetting to generate the documentation.

An alternative would be to setup some CI pipeline to take care of it. It might be better in the long run.

Apparently, github pages supports Jeekyll (more or less) out of the box.
https://docs.github.com/en/github/working-with-github-pages/about-github-pages-and-jekyll

make it easier to inspect dependencies

While working on testing, inside a container, I realized that breeze current has a loooot of dependencies.

In order to keep this under control, I would like a nice way to see where the dependencies come from.

• generate a graph of the dependencies (using graphiviz)
• either include the licences in the graph, or make a table (e.g. a csv) that shows the licences of each dependencies

Reminder: there are some dependencies that I might want to add as a git submodule, for easier pinning and/or because they are not in quicklisp.

Better test reporting

Some ideas:

• cl-ascii-table could be interesting
• tap compatible
• junit's xml format
• indicator for Emacs' mode-line

Document Workers

CI: run the e2e tests

I have a few scripts that:

• build a container
• run emacs, breeze and X in the container
• automates emacs, runs some commands
• takes screenshots

I would like to show those screenshots in the documentation.

And ofc, this would help stability a lot, by catching more complex issues.

Emacs: tag the commands so they show only in the right context (mode)

https://lars.ingebrigtsen.no/2021/02/16/command-discovery-in-emacs/

Resources about refactorings

Add these references to notes.org:

• Darlington, J., Burstall, R.M. A system which automatically improves programs. Acta Informatica 6, 41–60 (1976). https://doi.org/10.1007/BF00263742
• Huet, G., Lang, B. Proving and applying program transformations expressed with second-order patterns. Acta Informatica 11, 31–55 (1978). https://doi.org/10.1007/BF00264598

Add `symbol-macro-p` to xref.lisp

(defun symbol-macro-p (sym &optional env)
  (let ((*macroexpand-hook* (constantly nil)))
    (nth-value 1 (macroexpand-1 sym env))))

CI: use `scripts/test.sh`

Here

breeze/.github/workflows/ci.yml

Line 56 in cab25cf

run: sbcl --noinform --non-interactive --load 'breeze.asd' --eval '(ql:quickload :breeze)' --eval '(breeze.user:selftest)'

add a command to open l1sp.org

Add CI pipeline

see https://github.com/yitzchak/common-lisp-jupyter/blob/689f47667ab6a4a9865776fdd159d8bbdc222f20/.github/workflows/ci.yml

CI: test other implementations than sbcl

Ideas for helping common lisp newbies

https://lobste.rs/s/qb07ja/modern_hello_world_program_needs_more#c_ledxfb

Integrate with Parachute

I want to integrate with other test frameworks, but I want to start with parachute because it's the one I use the most in other projects.

CI: Generate the documentation pages

• generating the documentation should be one of the (integration) tests
• PRs should upload the generated documentation to a "dev" directory in AWS S3
• PRs from non-maintainers should not have access to S3 (or any secrets for that matter)
• When merging into the main branch, the CI job should upload the generated documentation to S3

Host the documentation elsewhere

like https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteHosting.html

(ql:quickload :introspect-environment)

Add CI

try to detect wrong argument order

Related or interesting projects

• https://gitlab.common-lisp.net/mraskin/local-variable-debug-wrapper
• https://gitlab.common-lisp.net/mraskin/metering (profiling)
• https://gitlab.common-lisp.net/mraskin/agnostic-lizard (core walker)
• SICL
  • Video ELS2020 - Omnipresent and low overhead application debugging
• Video ELS2020 - Indexing Common Lisp with Kythe
• LEM
  • Lem can now be started as a full featured Lisp REPL
  • GTFL - A Graphical Terminal For Lisp
• tracer (profiling)
• lisp-repl-core-dumper
• cl-flamegraph

More in State of the Common Lisp ecosystem, 2020

=> colisper ❤️

Not lisp

• For rust, for inspiration: https://alastairreid.github.io/automatic-rust-verification-tools-2021/
• https://tylr.fun/ - fancy visualisation and structured editing of an ML-like language
• Hypothesis' ghostwriter (python library)