diff options
Diffstat (limited to '2023/talks')
| -rw-r--r-- | 2023/talks/cubing.md | 32 | ||||
| -rw-r--r-- | 2023/talks/gc.md | 29 | ||||
| -rw-r--r-- | 2023/talks/matplotllm.md | 40 | ||||
| -rw-r--r-- | 2023/talks/parallel.md | 45 | ||||
| -rw-r--r-- | 2023/talks/repl.md | 87 | ||||
| -rw-r--r-- | 2023/talks/solo.md | 43 |
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 © 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 © 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 © 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 © 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 © 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"… 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… 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… 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… + +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 © 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"]] + + |