cl-eepitch
- Farming out common lisp automation to eev eepitchOkay, 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 slime ecl from common lisp (running in slime.).
Common lisp programs using swank to drive emacs using Eduardo Ochs’ masterpiece human interactive tool reflects Sandewall’s point that AI must be using the same tools for the same challenges as humans. (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’s cl-el 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.
I guess this looks familiar from me.
#|
(setq inferior-lisp-program "ecl")
(slime)
(setq eepitch-buffer-name "*slime-repl ECL*")
|#
slime-enable-evaluate-in-emacs
in emacsIn my opinion, the best way to do this is to issue
M-x slime
M-x customize-variable
slime-enable-evaluate-in-emacs
(autocompletes, don’t worry about typing)Toggle
Apply and Save
This sticks it on. If your lisp programs are untrustworthy, don’t trust them.
Putting this in screwlisps-knowledge, refer to cons-grapher.
(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 targetI.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 lispUtility for sending expressions rather than strings.
(defun eepitch-expr
(expr)
(let ((*print-pretty* nil))
(eepitch (format nil "~s" expr))))
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
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.
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. 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.
Talk as always about this on the mastodon thread please.
See everyone for the live show in about 15 hours as always at 000UTC on anonradio.net, watch the mastodon (same as last week). Soliloquyzing about this.
screwlisp proposes kittens