add sat dev discussions

1 files changed, 109 insertions, 0 deletions

diff --git a/2025/talks/swanky.md b/2025/talks/swanky.md
index de939730..be639835 100644
--- a/2025/talks/swanky.md
+++ b/2025/talks/swanky.md
@@ -40,6 +40,115 @@ About the speaker:
 Python is eating the world. Emacs is eating my computing environment. I'm
 attempting to get them working together.
 
+## Discussion / notes
+
+- Q: Does swanky-python work with Sly?
+  - A: It doesn't, Sly is great but I went with slime for a few
+    reasons:
+    - I wanted to use some cool stuff from slime-star
+    - I actually think there's good potential with slime's presentations that sly removed.
+    - The main feature of sly missing from slime is stickers.
+      slime-star provides something similar in being able to
+      recompile a function with an expression traced, but I
+      think for python it'll be better to integrate with dape
+      for debugging
+  - In recent years slime has been more actively maintained
+    in terms of bug fixes and such.
+- Q: Does this work with Hy?
+  ([https://hylang.org](https://hylang.org),
+  lisp syntax for Python)
+  - A: I actually first wrote this in Hy.
+    [https://codeberg.org/sczi/swanky-python/src/commit/6d8f4e0c8000c931746edd0fb442704dff853492](https://codeberg.org/sczi/swanky-python/src/commit/6d8f4e0c8000c931746edd0fb442704dff853492)
+    is the last commit before I switched back to python.
+  - Though even when the swanky python backend was written in Hy, it
+     was still targeted at editing python code, not Hy. Implementing
+     it in Hy just made the implementation a bit easier, as the slime
+     "protocol" is just slime sending lisp forms to the swank
+     backend to evaluate, so to write the backend in python we need
+     to implement a lisp interpreter (swank_eval in server.py), which
+     we already have in Hy.
+  - To make it work for editing Hy code would require some changes
+    on the backend, around evaling code, returning source locations,
+    and autocomplete. But most would stay the same, so I think it
+    could be made to support both without needing to fork a separate
+    project. I don't plan to use Hy or work on it. When writing
+    lisp I'd rather write CL, and when writing python I'd rather
+    use standard python syntax. But if someone wants to add Hy
+    support I'd be happy to merge it and assist a bit.
+- Q: Where can I find a list of Slime-like interfaces for other
+  languages?
+  - A: I don't know that a slime-like interface really exists for
+    any languages outside of the lisp and smalltalk family. I made a
+    list of some of those at
+    [https://codeberg.org/sczi/swanky-python/src/branch/main/Hacking.org#headline-63](https://codeberg.org/sczi/swanky-python/src/branch/main/Hacking.org#headline-63)
+- Q: Is there an IRC channel for swanky-python? If not, are you
+  interested in creating one?
+  - A: Good idea to have, I just made #swankypython on libera
+- Q:How would this integrate with python notebooks such as marimo?
+  - A: I've never used marimo, just jupyter, but it looks nicer so
+    I'd like to try it out sometime. The most basic integration
+    would be to just run swanky python within the notebook. That way
+    you would use the notebook as normal, but get the interactive
+    backtrace buffer in emacs on any exception, and be able to use
+    the inspector, nicer repl, etc. A more complete integration
+    would probably be based on emacs-jupyter but I haven't looked
+    into it yet.
+- Q: Why not org babel as well? +1 for org-babel with this, would be
+  awesome
+  - A: That'd be great and probably not much work at all. I just
+    tried evaling python code as a "lisp" block, since babel for
+    lisp calls slime-eval, and it dies with an exception because I
+    haven't implemented swank:eval-and-grab-output in swanky python
+    yet. Maybe it's just needed to implement that and then
+    configure babel for python src blocks to use slime-eval rather
+    than running with org-babel-python-command.
+- Tangentially, did you see Kent Pitman's recent moves to introduce
+  his common lisp condition system to python? E.g. about resuming
+  execution after an exception. He showed it some sunday lispy gopher
+  climate. In my opinion, reach out to
+  [https://climatejustice.social/@kentpitman](https://climatejustice.social/@kentpitman)
+  since you asked for contact about lisp-style python exception
+  restarts which he has worked on recently.
+- I hadn't seen that, thanks, it's super interesting to hear the old
+  legends talk. Here's the link for anyone else:
+  [https://medium.com/@screwlisp/live-interview-with-kent-pitman-incoming-216092e24f44](https://medium.com/@screwlisp/live-interview-with-kent-pitman-incoming-216092e24f44)
+- But a condition system is a bit of a separate issue from the
+  exception restarts I'd like to have. A condition system can be
+  implemented without any changes to the runtime, in any language with
+  dynamic scope and first class functions. And dynamic scope can be
+  emulated in any language with global variables, so people have
+  implemented Common Lisp (CL) style condition systems as libraries
+  for many languages. If this was used universally in place of the
+  language's native exceptions, it would give the ability to drop
+  into a repl at the point of an otherwise uncaught exception, but not
+  the ability to restart execution from any stack frame. Smalltalk has
+  traditional exceptions and not a CL like condition system, but its
+  debugger does provide this ability, as does the JVM and v8
+  debuggers. In CL this ability (sldb-restart-frame in slime) isn't
+  provided by the condition system, but in SBCL for example by
+  internal functions in the sb-debug and sb-di packages.
+- It'd be interesting to experiment with a condition system in
+  Python, but what I'm more interested in is the ability on any
+  runtime error, to be able to fix the bug and restart execution from
+  any stack frame. 
+- Amazing work!
+- [https://slime.common-lisp.dev/doc/html/](https://slime.common-lisp.dev/doc/html/)
+  (anyone who doesn't have this bookmarked)
+- This is really cool, I am amazed how much functionality you have
+  implemented! I hope I can start using this in my day job!
+- Very very impressive. I will definitely try to use this in my
+  workflow. I love the Lisp development style.
+- very impressive. I am also working on a Python IDE with a python
+  process and a webview to host the python runtime and display the
+  IDE, but I am very far behind in terms of features. I just made the
+  reload system work and the code(AST)->html renderer
+- Neat, if you publish it send me a link!
+- Definitely going to give it a try! I've been missing interactive
+  since learning python many years ago, even before I knew Common Lisp
+  existed and one of the primary reasons why Common Lisp replaced
+  python as my go-to language
+- Such a package alone would automatically make Emacs a much better option than something like PyCharm.
+- I found it very funny how he showed M-x doctor But very interesting talk!
 
 
 [[!inline pages="internal(2025/info/swanky-after)" raw="yes"]]