#+RESULTS: run-history-lobs
: #<process SLIME Lisp>
** Require mcclim then manually fiddle *slime-repl* into ==:clim-user==
(long unless cached (10 seconds to compile for me))
#+name: run-require-mcclim
#+begin_src lisp :noweb yes
<<require-clim>>
#+end_src
#+RESULTS: run-require-mcclim
: NIL
annoying manually ==(in-package :clim-user)== intercession
** Grab the message class from 029
#+name: define-test-message
#+begin_src lisp :noweb yes
<<message-class>>
#+end_src
#+RESULTS: define-test-message
: Hello, world
* Writing that isn't elisp org-wizardry shuffling of previous days
** Now basically we can send message strings!
#+name: stream-message
#+begin_src lisp
(let ((original (make-instance 'message :text "plz send help")))
(setq *received-message*
(with-input-from-string
(in
(with-output-to-string (out)
(present original 'message :stream out)))
(accept 'message :stream in))))
(text-of *received-message*)
#+end_src
#+RESULTS: stream-message
: plz send help
This is a kind of fiddly form to write, though hopefully sane:
1. Make an original message
2. setq the result in the session image of
1. an input stream from
1. an output stream of
1. PRESENTing the original message
2. ACCEPTing the input stream
We use WITHs which imply the streams are cleaned up by lisp's
UNWIND-PROTECT which does the job reliably. We need to mediate the two
streams with a string buffer (out -> in). Lisp basically requires we
handle that buffer ourselves. It would probably be more clear if we
made the intermediary buffer ourselves (which is an optional second
argument to those WITHs; otherwise it just uses an adjustable string I
think).
** Future presentation types
The string buffer modulated input and output will transparently become
socket-modulated (where the socket presumably has its own notion of
buffering) presumably from #:usocket.
Also instead of using a 'string (which may or may not be utf8), veilid
uses byte arrays. Translating to this is the purpose of the #:babel
library in lisp (confusing name collision with org).
In fact, the nature of veilid's spec seems struct-ish. Basically the
same data object (class instance) will have added presentation types
for message-is-a-struct, message-is-unsigned-byte-8s, as well as
message-is-a-string.
I regard it as a mistake to start by implementing a low level
cryptographic notion of a message, though eventually there will be
increasingly low level views downstream of MESSAGE,
CLIM:TEXTUAL-VIEW. In particular a PRIN1-like STRUCT (which I guess is
a different CLIM:PRESENTATION-TYPE), but which will eventually also
have a BITFIELD-VIEW. These messages will go in an envelope class. I'm
feeling that envelopes are created with a non-slot message key, which
is then signed ("compiled") into the payload slot.