6 files changed, 276 insertions, 0 deletions
diff --git a/2023/talks/cubing.md b/2023/talks/cubing.md
new file mode 100644
index 00000000..19e88dde
--- /dev/null
+++ b/2023/talks/cubing.md
@@ -0,0 +1,32 @@
+[[!meta title="Speedcubing in Emacs"]]
+[[!meta copyright="Copyright &copy; 2023 Vasilij "wasamasa" Schneidermann"]]
+[[!inline pages="internal(2023/info/cubing-nav)" raw="yes"]]
+
+<!-- Initially generated with emacsconf-publish-talk-page and then left alone for manual editing -->
+<!-- You can manually edit this file to update the abstract, add links, etc. --->
+
+
+# Speedcubing in Emacs
+Vasilij "wasamasa" Schneidermann (he/him) - Pronunciation: [vɐˈsʲilʲɪj] [vazamaza] [ˈʃnaɪ̯dɐman], IRC: wasamasa, Website: <https://emacsninja.com> Fediverse: @wasamasa@lonely.town, <mailto:mail@vasilij.de>
+
+[[!inline pages="internal(2023/info/cubing-before)" raw="yes"]]
+
+Emacs is well-known for its kitchen-sink nature and sheer extensibility.
+However, its utility for tasks beyond text manipulation is still
+disputed. While it is possible to do most of your computing inside
+Emacs, the existing solutions are of varying quality. Sometimes it is
+necessary to create a custom solution tailored to one's personal needs
+and I believe Emacs to be a worthwhile platform for this.
+
+In this talk I present my journey of building a package to assist me
+with speedcubing, a competitive sport with the goal of solving the
+Rubik's Cube as fast as possible. Along with a demo, useful Emacs
+features and challenges that came up during development will be shown.
+
+
+
+[[!inline pages="internal(2023/info/cubing-after)" raw="yes"]]
+
+[[!inline pages="internal(2023/info/cubing-nav)" raw="yes"]]
+
+
diff --git a/2023/talks/gc.md b/2023/talks/gc.md
new file mode 100644
index 00000000..82a465e1
--- /dev/null
+++ b/2023/talks/gc.md
@@ -0,0 +1,29 @@
+[[!meta title="emacs-gc-stats: Does garbage collection actually slow down Emacs?"]]
+[[!meta copyright="Copyright &copy; 2023 Ihor Radchenko"]]
+[[!inline pages="internal(2023/info/gc-nav)" raw="yes"]]
+
+<!-- Initially generated with emacsconf-publish-talk-page and then left alone for manual editing -->
+<!-- You can manually edit this file to update the abstract, add links, etc. --->
+
+
+# emacs-gc-stats: Does garbage collection actually slow down Emacs?
+Ihor Radchenko (he) - Mastodon: <https://emacs.ch/@yantar92>, <mailto:yantar92@posteo.net>
+
+[[!inline pages="internal(2023/info/gc-before)" raw="yes"]]
+
+Is Emacs responsiveness really affected by slow garbage collector?
+Should \`gc-cons-threshold' be increased during startup?
+Or maybe during the whole Emacs session?
+
+I will try to answer these questions using the real data collected from
+Emacs users who installed
+<https://elpa.gnu.org/packages/emacs-gc-stats.html> package and submitted
+their results to <https://lists.gnu.org/archive/html/emacs-gc-stats/>.
+
+
+
+[[!inline pages="internal(2023/info/gc-after)" raw="yes"]]
+
+[[!inline pages="internal(2023/info/gc-nav)" raw="yes"]]
+
+
diff --git a/2023/talks/matplotllm.md b/2023/talks/matplotllm.md
new file mode 100644
index 00000000..453eb114
--- /dev/null
+++ b/2023/talks/matplotllm.md
@@ -0,0 +1,40 @@
+[[!meta title="MatplotLLM, iterative natural language data visualization in org-babel"]]
+[[!meta copyright="Copyright &copy; 2023 Abhinav Tushar"]]
+[[!inline pages="internal(2023/info/matplotllm-nav)" raw="yes"]]
+
+<!-- Initially generated with emacsconf-publish-talk-page and then left alone for manual editing -->
+<!-- You can manually edit this file to update the abstract, add links, etc. --->
+
+
+# MatplotLLM, iterative natural language data visualization in org-babel
+Abhinav Tushar (he/him) - abhinav@lepisma.xyz, https://lepisma.xyz, @lepisma@mathstodon.xyz, <mailto:abhinav@lepisma.xyz>
+
+[[!inline pages="internal(2023/info/matplotllm-before)" raw="yes"]]
+
+Large Language Models (LLMs) have improved in capabilities to an extent
+where a lot of manual workflows can be automated by just providing
+natural language instructions.
+
+On such manual work is to create custom visualizations. I have found the
+process to be really tedious if you want to make something non-standard
+with common tools like matplotlib or d3. These frameworks provide low
+level abstractions that you can then use to make your own
+visualizations.
+
+Earlier to make a new custom visualization, I would open two windows in
+Emacs, one for code, other for the generated image. In this talk, I will
+show how a powerful LLM could lead to a much more natural interface
+where I only need to work with text instructions and feedback on the
+currently generated plot. The system isn't perfect, but it shows us how
+the future or such work could look like.
+
+The package is called MatplotLLM and lives here
+<https://github.com/lepisma/matplotllm>
+
+
+
+[[!inline pages="internal(2023/info/matplotllm-after)" raw="yes"]]
+
+[[!inline pages="internal(2023/info/matplotllm-nav)" raw="yes"]]
+
+
diff --git a/2023/talks/parallel.md b/2023/talks/parallel.md
new file mode 100644
index 00000000..ea966383
--- /dev/null
+++ b/2023/talks/parallel.md
@@ -0,0 +1,45 @@
+[[!meta title="Parallel Text Replacement: Does P = NP?"]]
+[[!meta copyright="Copyright &copy; 2023 Lovro"]]
+[[!inline pages="internal(2023/info/parallel-nav)" raw="yes"]]
+
+<!-- Initially generated with emacsconf-publish-talk-page and then left alone for manual editing -->
+<!-- You can manually edit this file to update the abstract, add links, etc. --->
+
+
+# Parallel Text Replacement: Does P = NP?
+Lovro - IRC: hokomo, <mailto:hokomo@airmail.cc>
+
+[[!inline pages="internal(2023/info/parallel-before)" raw="yes"]]
+
+We present our Emacs package for performing parallel text 
+replacement.
+
+"Parallel" in this context does not refer to improving 
+efficiency through parallelism, but to the concept of performing 
+more than one text replacement without them interfering with 
+each other. This is in line with the usage of the term in the 
+Lisp community when contrasting the behaviors of LET and LET\*, 
+SETQ and PSETQ, etc. (e.g. 
+<http://www.lispworks.com/documentation/lw60/CLHS/Body/s_let_l.htm>).
+
+We will present the package's features and its integration with 
+Emacs' query-replace system, a comparison with previous 
+solutions, and a few notes on our implementation. We will 
+describe some common use-cases and showcase how the package is 
+used.
+
+The package is currently not yet published in a package archive, 
+but the code is already publicly available at 
+<https://github.com/hokomo/query-replace-parallel>. The name 
+"query-replace-parallel" is not yet final and we are thinking of 
+alternatives. Our current best candidate is "replace-parallel" 
+(similar to the built-in "replace.el"), but suggestions are 
+welcome.
+
+
+
+[[!inline pages="internal(2023/info/parallel-after)" raw="yes"]]
+
+[[!inline pages="internal(2023/info/parallel-nav)" raw="yes"]]
+
+
diff --git a/2023/talks/repl.md b/2023/talks/repl.md
new file mode 100644
index 00000000..3dc75db7
--- /dev/null
+++ b/2023/talks/repl.md
@@ -0,0 +1,87 @@
+[[!meta title="REPLs in strange places: Lua, LaTeX, LPeg, LPegRex, TikZ"]]
+[[!meta copyright="Copyright &copy; 2023 Eduardo Ochs"]]
+[[!inline pages="internal(2023/info/repl-nav)" raw="yes"]]
+
+<!-- Initially generated with emacsconf-publish-talk-page and then left alone for manual editing -->
+<!-- You can manually edit this file to update the abstract, add links, etc. --->
+
+
+# REPLs in strange places: Lua, LaTeX, LPeg, LPegRex, TikZ
+Eduardo Ochs - IRC: edrx, edrx <http://anggtwu.net/>, <mailto:eduardoochs@gmail.com>
+
+[[!inline pages="internal(2023/info/repl-before)" raw="yes"]]
+
+Many years ago, when I started programming, my dream was to write
+games. I failed miserably in that, but I became fascinated by
+languages, and I discovered Forth - that was perfect for writing
+languages whose syntax was as simple as possible. Then I switched to
+GNU/Linux and I had a series of favorite languages; at some point I
+discovered Lua, that became not only my favorite language but also my
+favorite tool for implementing other languages. One of the main
+libraries of Lua is something called LPeg, that lets "people"
+implement complex parsers in just a few lines of code using PEGs -
+Parsing Expression Grammars.
+
+I've put the "people" in the last paragraph between quotes because for
+many years I wasn't included in the "people who can implement complex
+parsers with LPeg"&#x2026; lots of things in LPeg didn't make sense to me,
+and I couldn't visualize how it worked. Something was missing - some
+diagrams, maybe?
+
+The main tool for drawing diagrams in LaTeX is something called TikZ,
+that is HUGE - its manual has over 1000 pages. TikZ includes lots of
+libraries and extensions, and each one of these libraries and
+extensions extends TikZ's core language with some extra constructs.
+
+I don't know anyone - except for a handful of experts - who knows what
+is the "core language" of Tikz, that lies, or that should lie, below
+all these extensions&#x2026; all of my friends who use TikZ are just
+"users" of TikZ - they've learned some parts of TikZ by starting with
+exemples, and by then modifying these examples mostly by trial and
+error. In particular, no one among my friends knows how styles in TikZ
+really work; styles are implemented using "keys", that are hard to
+inspect from a running TeX - see [1] - and I found the chapter on "key
+management" in the manual very hard to understand. It feels as if
+something is missing from it&#x2026; some diagrams, maybe?
+
+In my day job I am a mathematician. I work in a federal university in
+Brazil, and besides teaching I do some research - mostly in areas in
+which the papers and theses have lots of diagrams, of many different
+kinds, and in which people use zillions of different programs to draw
+their diagrams. Every time that I see those diagrams I think "wow, I
+<span class="underline">need</span> to learn how to draw diagrams like that!", but until a few
+months ago this seemed to be impossible, or very hard, or very
+painful&#x2026;
+
+This presentation will be about a point in which all these ideas
+intersect. I am the author of an Emacs package called eev, that
+encourages using REPLs in a certain way; Lua can be used in several
+different styles, and if we use it in a certain way that most people
+hate - with lots of globals, and with an implementation of OO that
+makes everything inspectable and modifiable - then it becomes very
+REPL-friendly; there is an extension of LPeg called LPegRex ([2],
+[3]), that I found promising but hard to use, so I rewrote some parts
+of it to make them more REPL-friendly, and to make it print its ASTs
+in 2D ASCII art. The core of my presentation will be about how I am
+using REPLs written in Lua to write grammars, parsers, and tools to
+generate many kinds of diagrams, and how I am using these diagrams to
+document both my own code and other people's programs - the parts of
+them in which some diagrams seem to be missing. My hope is that people
+will find these ideas easy to port to other languages besides Lua, to
+other tools for generating diagrams besides LaTeX - SVG, maybe? - and
+to other ways to use REPLs in Emacs besides eev. Some ideas in this
+presentation were inspired by the blog post [4].
+
+[1]
+<https://tex.stackexchange.com/questions/663740/alternative-to-edef-c-pgfkeys-a>
+[2] <https://github.com/edubart/lpegrex>
+[3] <https://github.com/edubart/lpegrex/blob/main/parsers/lua.lua>
+[4] <https://ianthehenry.com/posts/my-kind-of-repl/>
+
+
+
+[[!inline pages="internal(2023/info/repl-after)" raw="yes"]]
+
+[[!inline pages="internal(2023/info/repl-nav)" raw="yes"]]
+
+
diff --git a/2023/talks/solo.md b/2023/talks/solo.md
new file mode 100644
index 00000000..addfeab0
--- /dev/null
+++ b/2023/talks/solo.md
@@ -0,0 +1,43 @@
+[[!meta title="How I play TTRPGs in Emacs"]]
+[[!meta copyright="Copyright &copy; 2023 Howard Abrams"]]
+[[!inline pages="internal(2023/info/solo-nav)" raw="yes"]]
+
+<!-- Initially generated with emacsconf-publish-talk-page and then left alone for manual editing -->
+<!-- You can manually edit this file to update the abstract, add links, etc. --->
+
+
+# How I play TTRPGs in Emacs
+Howard Abrams - Website: <https://www.howardism.org> - Mastodon: @howard@emacs.ch, <mailto:howard@howardabrams.com>
+
+[[!inline pages="internal(2023/info/solo-before)" raw="yes"]]
+
+As an eternal Dungeon Master, I have a long history of collecting my notes
+in Emacs. When my son was very young, I would export my Org files to
+an HTML page that would include some magic JavaScript, so that when
+displayed on my iPad, I could touch a table to have it randomly return a
+line, or touch a phrase like `3d6+1`, to have the web page return a dice
+roll.
+
+Lately I’ve been getting into Solo versions of tabletop role playing games
+(TTRPG), and have had a fun time writing Lisp to support this style of
+play, and thought I’d share my code and my fun.
+
+I’d like to begin by showing my  game play in action: I’m currently playing
+Ironsworn with the Mythic GM Emulator and various other tables and
+procedures to stike a balance between *playing a game* and *writing a
+book*. Next I would like to show the code that supports the interface, and
+perhaps dive a bit deeper into some of the underlying mechanisms and
+functions, especially that function that randomly chooses entries from Org
+tables. I’ll end with a plan for turning my code into a community project,
+if people are interested.
+
+Format (10 minutes, 20 minutes, description of other format) and outline:
+20 minutes, but I could do less if you have too many submissions.
+
+
+
+[[!inline pages="internal(2023/info/solo-after)" raw="yes"]]
+
+[[!inline pages="internal(2023/info/solo-nav)" raw="yes"]]
+
+