- Core Common Lisp sources live at the repo root, notably
py.lisp(Python emitter),pipe.lisp(pipeline helpers), andpackage.lisp/cl-py-generator.asd(package/system definitions). - Tests are defined in
transpiler-tests.lisp. Thetests.lispfile is ad-hoc scratch usage, not the main suite. - Example outputs and experiments are under
example/(many numbered subprojects). - Tooling and hooks live in
tools/(notablylisp-formatand a pre-commit script). SUPPORTED_FORMS.mdis generated from tests; do not edit it by hand.
./run-tests.shruns SBCL, loadstranspiler-tests.lisp, and executesrun-transpiler-tests.- When running SBCL tests or tools programmatically, always pass the
--disable-debuggercommand-line argument. This prevents SBCL from hanging in the interactive debugger on error. Refer to the lisp-dev skill for detailed options. ./generate-docs.shregeneratesSUPPORTED_FORMS.mdfrom the test cases.- Both scripts assume Quicklisp and the repo path
~/quicklisp/local-projects/cl-py-generator; adjust if your local setup differs.
- Use idiomatic Common Lisp naming (lowercase with hyphens, e.g.,
emit-py,run-transpiler-tests). - Keep s-expression indentation consistent with existing files; prefer formatting via
git lisp-format(seetools/pre-commit). - Avoid editing generated artifacts directly; regenerate them from source tests instead.
- Add new forms to
*test-cases*intranspiler-tests.lispwith:name,:description,:lisp,:python, and:tags. - Use
:exec-test tand:expected-outputwhen validating runtime behavior. - The test runner formats Python using
ruff formatand executes withpython3; ensure both are available. - Float Reader Precision Alert: When formatting and parsing floating-point representations in Lisp (
read-from-string), be aware of*read-default-float-format*. A mismatch between the default read format (single-float) and the printed float type (e.g. double-float) will cause precision mismatches and infinite print-reconstruct loops. Always bind*read-default-float-format*to match the target float type.
- Recent history shows short, descriptive messages (e.g., “pose plotter”) and occasional Conventional Commits (
feat(scope): ...). Keep messages concise and specific. - PRs should include a clear summary, the tests run (or a note if not run), and regenerated docs when emitter behavior changes.