Inexplicable offline crises aside, here is my idiom for Sandewall’s Leonardo System software individuals in emacs (eev).
Forgive the lack of exposition, I am writing this for myself right now. Cloning a software individual setup is also given.
(in emacs)
• (eww "screwlisp.small-web.org")
find this article you are looking at now
• (setq inferior-lisp-program "clisp -E iso-8859-1 -modern")
• (slime)
• (setq eepitch-buffer-name "*slime-repl clisp*")
• (eepitch-shell)
cd
git clone https://codeberg.org/tfw/pawn-75
mkdir -p leocommunity
cp -r Pawn-75/Pawn-75 leocommunity/saturn
• (setq eepitch-buffer-name "*slime-repl clisp*")
(uiop:chdir "~/leocommunity/saturn/utilus/Process/main/")
(load #P"../../../remus/Startup/cl/acleo.leos")
(cle)
Now here I diverge from Sandewall’s useage of persisting knowledge changes made in one agent in one individual, quitting lisp, restarting lisp in a different agent in that one individual (both using the same remus kernel agent), and copying some knowledgebases from adjacent agents in the same individual to pull in their current knowledge.
Instead, I leave the one universe running, change the relative path to the other agent, [don’t do this: purge the old catalog of available knowledgebases], load the switched-to agent’s catalog, and then we are working in a different agent. This still fulfills the requirement of an individual’s internal agents sharing one remus kernel agent. The substantive change is that instead of agents explicitly cloning knowledgebases from each other i.e. to form a cached belief about the state of another agent, I switch to an agent, load its knowledgebase into the universe (lisp image application database), then switch to the other agent; unless it personally overwrites the values, its predicates will simply find what a previously active agent put there. In order to freshen/change/persist the knowledgebase, we would need to switch back to the other agent. I think this is an example of defeasible inheritance: My lisp universe satisfies the precondition for some action, but it is ambiguous how it came to be in that state (presumably I do know; it is simply not explicit in the values in this application).
. (uiop:chdir "~/leocommunity/saturn/demus/Process/main/")
. (setf (get *my-id* 'leoname) 'demus (get *my-id* 'self-location) "../../../demus/")
. (load-ef 'kb-catal)
crek in-demus-kb
loadk in-demus-kb
setk in-demus-kb
crefil in-demus-entityfile
loadk in-demus-entityfile
and go back
. (uiop:chdir "~/leocommunity/saturn/utilus/Process/main/")
. (setf (get *my-id* 'leoname) 'utilus (get *my-id* 'self-location) "../../../utilus/")
. (load-ef 'kb-catal)
crek in-utilus-kb
loadk in-utilus-kb
setk in-utilus-kb
crefil in-utilus-entityfile
loadk in-utilus-entityfile
put utility type thingtype
put utility attributes {usefulness}
addmember (get in-utilus-entityfile contents) utility
writefil in-utilus-entityfile
loadk in-utilus-entityfile
This spans activating different agents inside one software-individual in turn, abrogating the need to restart emacs. Instead of one agent making a local cache of a same-individual agent’s knowledgebase representing its (potentially stale) beliefs about that agent, we switch to the agent with the knowledge, load the knowledge, switch to the next agent who simply finds the entities they need left around by previously active agents.
We saw that it works because we can find we made and loaded a knowledgebase and entityfile in that knowledge base in demus, and another different knowledgebase and entityfile in the utilus agent, which we started in.
We used emacs eev to send commands to the image one by one. By the way, a quick hack since slime’s connection method to clisp leaves the cursor in clisp is to just keyboard macro C-x ( C-x o F8 C-x ) after which C-x eeeeeee performs F8 on subsequent lines in the last ('o’ther) buffer.
The awkwardness of stopping and starting lisp to switch between agents, and explicitly vendoring copies of each others’ knowledgebases between them was a severe problem for me for multi-agent programming. We can see that changing leoname and self-location in *my-id* is sufficient to work in a continuous lisp universe.
I am continuing to be missing from the Mastodon for a while, since I collapsed under the weight of the world (nothing to do with our real technical internet life). Hopefully you found you can make a software individual too. As to why, my feeling is that bringing agents to life inside a software individual whom expects to be always running and acting autonomously has more sticking power than writing a software that I have to program with further to even use in every specific case.
Since I’m not boosting toots on the Mastodon at the moment, please tell other people you think should be interested.
screwlisp proposes kittens