--- layout: ../Site.layout.js --- # `cl-eepitch` - Farming out common lisp automation to eev eepitch Okay, okay! Hear me out. This graph is crazy. As things have finally started coming together for our space, I am happy to report on driving [emacs eev eepitch](https://anggtwu.net/eepitch.html) [slime](https://slime.common-lisp.dev/doc/html/) [ecl](https://ecl.common-lisp.dev/) from [common lisp](https://www.lispworks.com/documentation/HyperSpec/) (running in slime.). Common lisp programs using [swank](https://www.cliki.net/SWANK) to drive emacs using [Eduardo Ochs'](https://anggtwu.net/) masterpiece human interactive tool reflects [Sandewall's point that AI must be using the same tools for the same challenges as humans](https://codeberg.org/tfw/pawn-75/src/branch/main/aica-1-core.pdf). (Otherwise they would be authentic-something-else not artificial-intelligence). The key thing is that common lisp programs outside of emacs can use eepitch to use emacs to use common lisp programs outside of emacs. In fact, I hope that [akater](https://www.cliki.net/akater)'s [*cl-el*](https://framagit.org/akater/cl-el/-/blob/master/el.org) will be able to run eev eepitch external processes such that the rest of emacs can be dropped for this family of interprogram in-lisp communications. ## Start and register slime common lisp for eepitch in eev I guess this looks familiar from me. ``` #|  (setq inferior-lisp-program "ecl")  (slime)  (setq eepitch-buffer-name "*slime-repl ECL*") |# ``` # Enable `slime-enable-evaluate-in-emacs` in emacs In my opinion, the best way to do this is to issue 1. `M-x slime` 1. `M-x customize-variable` 1. `slime-enable-evaluate-in-emacs` (autocompletes, don't worry about typing) 1. `Toggle` 1. `Apply and Save` This sticks it on. If your lisp programs are untrustworthy, don't trust them. # Define package Putting this in [screwlisps-knowledge, refer to cons-grapher](/clim/cons-tree-graphics/). ``` (uiop:define-package :screwlisps-knowledge/cl-eepitch.page (:import-from :swank eval-in-emacs) (:export #:eepitch #:red-star-line #:target-eepitch #:eepitch-expr)) (in-package :screwlisps-knowledge/cl-eepitch.page) ``` # `eepitch-line` This is the tricky bit I pulled out of eepitch's low level internals. ``` (defun eepitch (line) (eval-in-emacs `(let ((line ,line)) (setq line (eepitch-preprocess-line line)) (eepitch-prepare) (eepitch-line line)))) ``` # `red-star-line` - actually just `eval-in-emacs` `red-star-line` just evaluates emacs lisp. ``` (defun red-star-line (elisp-expr &optional (wait nil)) (eval-in-emacs elisp-expr wait)) ``` # `target-eepitch` - choose eepitch target I.e. set the buffer name that will receive from `eepitch`. ``` (defun target-eepitch (string) (red-star-line `(setq eepitch-buffer-name ,string))) ``` # `eepitch-expr` possibly targetting common lisp Utility for sending expressions rather than strings. ``` (defun eepitch-expr (expr) (let ((*print-pretty* nil)) (eepitch (format nil "~s" expr)))) ``` # Useage Alright, a thorough write-up later. More than one. I am just indicating that calling `(eepitch-expr '(get-decoded-time))` works as you would hope. ``` #| CLIM-USER> (asdf:load-system :screwlisps-knowledge/tangle) T CLIM-USER> (use-package :sk/tangle) T CLIM-USER> (tangle "~/gits/screwlisps-kitten/screwniverse/cl-eepitch.page.md" :screwlisps-knowledge) T CLIM-USER> (asdf:load-system :screwlisps-knowledge/cl-eepitch.page) ; (register new packages) ;;; T CLIM-USER> (use-package :screwlisps-knowledge/cl-eepitch.page) T CLIM-USER> (eepitch-expr '(get-decoded-time)) (GET-DECODED-TIME) T CLIM-USER> 6 40 19 1 7 2025 1 NIL -12 CLIM-USER> (eepitch "(get-decoded-time)") (get-decoded-time) T CLIM-USER> 27 40 19 1 7 2025 1 NIL -12 CLIM-USER> |# ``` Now ## The flow is like this Emacs sends `(eepitch-expr '(get-decoded-time))` to the lisp image The lisp image calls `swank:eval-in-emacs` to `eepitch` (it's complicated) `"(get-decoded-time)"` back to the lisp image Eepitch enters and sends `(get-decoded-time)` in the lisp image like-you-typed-it. The lisp image receives, evaluates and prints `(get-decoded-time)` as normal Control returns to the lisp image. This lets the lisp image (or whatever process) easily interact with emacs buffers as though it could type into them, and these buffers are interactively available and watchable by you. This is different from just using `swank:eval-in-emacs` on its own, because all of the confusing automation infrastructure is handled by `eev-mode` to provide a useable complex automation interface to humans. In our case, our human is a [good old fashioned lisp AI](https://en.wikipedia.org/wiki/GOFAI). # Conclusion This useage solves a huge swathe of common lisp directed inter-image communication for me like-a-human-did-it. I hope that cl-el will move this functionality basically entirely inside of common lisp. Secondarily, it implies common lisp programs using emacs modes via red-star-lines with eepitch. Having farmed out inter-image community communication to eepitch, which is both elegant and sophisticated and previously human-focused, I am finally in a position to pick up Sandewall's papers on inter-agent communication protocol and we can attach heavy-duty meanings to [Pawn-75 software individuals](https://codeberg.org/tfw/pawn-75). I think I see live kittens' kittenDBs as monadic IO in this scheme of things. I am not sure what the relation between madman and Kitten will be. I will explore the first blush of eepitch-modulated communities of lisp images and emacs modes incrementally henceforth. # Fin. Talk as always about this on [the mastodon thread please](https://gamerplus.org/@screwlisp/114777025680968913). See everyone for the live show in about 15 hours as always at 000UTC on [anonradio.net](https://anonradio.net), watch [the mastodon](https://gamerplus.org/@screwlisp) (same as last week). Soliloquyzing about this.