summaryrefslogtreecommitdiffstats
path: root/2022/talks/async.md
diff options
context:
space:
mode:
authorSacha Chua <sacha@sachachua.com>2022-09-30 15:59:56 -0400
committerSacha Chua <sacha@sachachua.com>2022-09-30 15:59:56 -0400
commit67f0f1c500091db27a69cb3a05fffd20c137d6e4 (patch)
tree22f66de124999dca2f6d965795c8135d747aa6eb /2022/talks/async.md
parent0e44a3f1f7dbc27c92aa51aa50e898b163d56ac3 (diff)
downloademacsconf-wiki-67f0f1c500091db27a69cb3a05fffd20c137d6e4.tar.xz
emacsconf-wiki-67f0f1c500091db27a69cb3a05fffd20c137d6e4.zip
Add 2022 talks
Diffstat (limited to '2022/talks/async.md')
-rw-r--r--2022/talks/async.md56
1 files changed, 56 insertions, 0 deletions
diff --git a/2022/talks/async.md b/2022/talks/async.md
new file mode 100644
index 00000000..2e78a338
--- /dev/null
+++ b/2022/talks/async.md
@@ -0,0 +1,56 @@
+[[!meta title="Emacs was async before async was cool"]]
+[[!meta copyright="Copyright &copy; 2022 Michael Herstine"]]
+[[!inline pages="internal(2022/info/async-nav)" raw="yes"]]
+
+<!-- Initially generated with emacsconf-generate-talk-page and then left alone for manual editing -->
+<!-- You can manually edit this file to update the abstract, add links, etc. --->
+
+
+# Emacs was async before async was cool
+Michael Herstine (IRC: sp1ff)
+
+[[!inline pages="internal(2022/info/async-before)" raw="yes"]]
+
+While async is all the rage in the JavaScript, Go and Rust
+communities, Emacs has had the ability to (certain) asynchronous
+processing all along. I learned this while writing an Emacs package to
+program to my music server's API.
+
+Music Player Daemon is a project that does what it says: hangs out in
+the background & plays your music. It has an API that I wanted to call
+from Emacs. I had just learned async Rust, so I decided to see if I
+could do something similar here. It turns out I could: I wound-up
+writing a little async runtime that allows callers to "send" commands
+to the daemon by queueing them up and returning immediately. In the
+background, as output from previous commands comes in, new commands
+are dequeued and sent.
+
+This required callers to provide callbacks in order to receive the
+results of their commands, which led to a situation all too familiar
+to Javascript programmers: callback hell. The coda to my story was
+(finally) coming to understand Lisp macros in order to extend Emacs
+Lisp with a more convenient construct for sending multiple commands.
+
+This talk will dive into the details of the Emacs Lisp process API,
+specifically the Low-Level Network Access API, with illustrations as
+to how it can be used to build an asynchronous queue. It will also
+introduce Lisp macros and how powerful they can be.
+
+Outline:
+
+- introduce myself & the problem
+ - go into more depth on the problem
+- overview of the solution:
+ - sketch out the Emacs API available to me
+ - sketch out the purpose-built async runtime I came up with in Emacs Lisp
+- coda: this worked but led to ugly code on the part of callers
+ - insight: in Lisp, the code is just data!
+- non-trivial demo
+
+
+
+[[!inline pages="internal(2022/info/async-after)" raw="yes"]]
+
+[[!inline pages="internal(2022/info/async-nav)" raw="yes"]]
+
+