diff options
| author | Darren Bane <darren.bane@gmail.com> | 2020-12-10 00:05:39 +0000 |
|---|---|---|
| committer | Darren Bane <darren.bane@gmail.com> | 2020-12-10 00:05:39 +0000 |
| commit | 930adcd596cf28b41ee26c8ffdc98640dfc9b4bd (patch) | |
| tree | 201fe6178b1efbedfc5be603246bf21d40bf3546 | |
| parent | ca5768f305d4f7d152fe3f8098be28914086ca7e (diff) | |
| download | lsp-930adcd596cf28b41ee26c8ffdc98640dfc9b4bd.tar.gz | |
Making changes
| -rw-r--r-- | ccap-muck.lisp | 1 | ||||
| -rw-r--r-- | doc/Makefile | 2 | ||||
| -rw-r--r-- | doc/breaking_rules.md | 5 |
3 files changed, 5 insertions, 3 deletions
diff --git a/ccap-muck.lisp b/ccap-muck.lisp index 3374606..d9de3b0 100644 --- a/ccap-muck.lisp +++ b/ccap-muck.lisp @@ -40,6 +40,7 @@ (defconstant +rdb+ "room.tam") (defconstant +adb+ "avatar.tam") +;; TODO: should I use print-object & the reader for serialisation? (defun read-room-database () (with-open-file (file +rdb+ :direction :input) )) diff --git a/doc/Makefile b/doc/Makefile index 4139f63..6e549c5 100644 --- a/doc/Makefile +++ b/doc/Makefile @@ -29,4 +29,4 @@ clean: .PHONY: push push: $(GEMINI) - scp $^ dbane@republic.circumlunar.space:/usr/home/dbane/gemini/lsp_doc + scp -6 $^ dbane@republic.circumlunar.space:/usr/home/dbane/gemini/lsp_doc diff --git a/doc/breaking_rules.md b/doc/breaking_rules.md index 29f20d1..7cfc99c 100644 --- a/doc/breaking_rules.md +++ b/doc/breaking_rules.md @@ -150,7 +150,7 @@ it may make sense to write the documentation (and contracts, and tests) "bottom- Depend only on GFM, in the same spirit as the software. The use of tools like -PP and Pandoc should be minised. +nw2md and Pandoc should be minised. PlantUML *should* be used where it can replace ad-hoc text. Documents should be stored under git in a "doc" subdirectory of the project. @@ -189,6 +189,7 @@ However, some of this documentation is better in the source code: ``` `lisp-critic` can be used to perform static analysis of the codebase. +But it's not worth writing custom rules. ### UI @@ -231,7 +232,7 @@ System tests grow in parallel with the requirements spec. It's ok for system tests to use the same interfaces as the ltk code. All tests should be automated, except possibly for the UI/view layer. -Q: These scripts could be generated from a literate test plan? A: yes, probably one of the few places to use "PP". +Q: These scripts could be generated from a literate test plan? A: yes, probably one of the few places to use nw2md. As much of the testing work should be pushed "back" in the V model to contracts for the functions, following the pattern above. |