summaryrefslogtreecommitdiffstats
path: root/2024
diff options
context:
space:
mode:
Diffstat (limited to '2024')
-rw-r--r--2024/info/org-update-before.md8
-rw-r--r--2024/talks/color.md38
-rw-r--r--2024/talks/open-mic.md77
-rw-r--r--2024/talks/theme.md36
-rw-r--r--2024/talks/transducers.md163
5 files changed, 316 insertions, 6 deletions
diff --git a/2024/info/org-update-before.md b/2024/info/org-update-before.md
index eac4398a..f75ca40b 100644
--- a/2024/info/org-update-before.md
+++ b/2024/info/org-update-before.md
@@ -2,12 +2,14 @@
[[!toc ]]
Format: 40-min talk ; Q&A: BigBlueButton conference room
Etherpad: <https://pad.emacsconf.org/2024-org-update>
-Status: TO_REVIEW_QA
+Status: TO_INDEX_QA
+# Talk
+
<div class="vid"><video controls preload="none" id="org-update-mainVideo"><source src="https://media.emacsconf.org/2024/emacsconf-2024-org-update--the-future-of-org--ihor-radchenko--main.webm" />captions="""<track label="English" kind="captions" srclang="en" src="/2024/captions/emacsconf-2024-org-update--the-future-of-org--ihor-radchenko--main.vtt" default />"""<track kind="chapters" label="Chapters" src="/2024/captions/emacsconf-2024-org-update--the-future-of-org--ihor-radchenko--main--chapters.vtt" /><p><em>Your browser does not support the video tag. Please download the video instead.</em></p></video>[[!template id="chapters" vidid="org-update-mainVideo" data="""
00:00.000 Introduction
01:14.280 Message from Bastien Guerry
@@ -39,5 +41,9 @@ Status: TO_REVIEW_QA
39:12.997 Thank you
"""]]<div></div>Duration: 39:35 minutes<div class="files resources"><ul><li><a href="https://pad.emacsconf.org/2024-org-update">Open Etherpad</a></li><li><a href="https://media.emacsconf.org/2024/emacsconf-2024-org-update--the-future-of-org--ihor-radchenko--intro.vtt">Download --intro.vtt</a></li><li><a href="https://media.emacsconf.org/2024/emacsconf-2024-org-update--the-future-of-org--ihor-radchenko--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2024/emacsconf-2024-org-update--the-future-of-org--ihor-radchenko--main--chapters.vtt">Download --main--chapters.vtt</a></li><li><a href="https://media.emacsconf.org/2024/emacsconf-2024-org-update--the-future-of-org--ihor-radchenko--main.vtt">Download --main.vtt</a></li><li><a href="https://media.emacsconf.org/2024/emacsconf-2024-org-update--the-future-of-org--ihor-radchenko--main.webm">Download --main.webm (88MB)</a></li><li><a href="https://media.emacsconf.org/2024/emacsconf-2024-org-update--the-future-of-org--ihor-radchenko--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2024/emacsconf-2024-org-update--the-future-of-org--ihor-radchenko--pad.md">Download --pad.md</a></li><li><a href="https://toobnix.org/w/2DAHY6wCAXnpeSqwUHaidv">View on Toobnix</a></li></ul></div></div>
+
+# Q&A
+
+<div class="vid"><video controls preload="none" id="org-update-qanda"><source src="https://media.emacsconf.org/2024/emacsconf-2024-org-update--the-future-of-org--ihor-radchenko--answers.webm" />captions="""<track label="English" kind="captions" srclang="en" src="/2024/captions/emacsconf-2024-org-update--the-future-of-org--ihor-radchenko--answers.vtt" default />"""<p><em>Your browser does not support the video tag. Please download the video instead.</em></p></video><div></div>Duration: 30:39 minutes<div class="files resources"><ul><li><a href="https://pad.emacsconf.org/2024-org-update">Open Etherpad</a></li><li><a href="https://media.emacsconf.org/2024/emacsconf-2024-org-update--the-future-of-org--ihor-radchenko--answers.vtt">Download --answers.vtt</a> (unedited)</li><li><a href="https://media.emacsconf.org/2024/emacsconf-2024-org-update--the-future-of-org--ihor-radchenko--answers.webm">Download --answers.webm (68MB)</a></li></ul></div></div>
# Description
<!-- End of emacsconf-publish-before-page --> \ No newline at end of file
diff --git a/2024/talks/color.md b/2024/talks/color.md
index c14b8ce9..dedfa00a 100644
--- a/2024/talks/color.md
+++ b/2024/talks/color.md
@@ -47,6 +47,44 @@ his Emacs looks and works better than many other editors. He works for Civo
as a Principal Engineer.
+# Discussion
+
+## Questions and answers
+
+- Q: Is there any intention to create a library for working with more
+ experimental color spaces? Pulling code out of Hasliberg for this
+ purpose, perhaps?
+ - A: Started the journey just for myself, and didn't think this
+ would be useful for others.
+ - A: Making it a library is definitely something that I can think
+ about.
+- Q: Can we have a dark as well as light theme variations made from
+ your theme?
+ - A: You can customize the code easily into dark, light and change
+ something based on someone's mood. Keep in mind that it is a
+ personal theme, so customize as you see fit.
+
+## Notes
+
+- \<ElephantErgo\> Great talk! Thank you 🙂
+- \<jsiegel62\> Excellent talk, thanks! \[11:33\]
+- \<codeasone\> Beautiful theme
+- \<inkpotmonkey\> Interesting idea to be inspired from tailwind and
+ frontend dev, thanks for talk  \[11:34\]
+- \<@sachac\>
+ [https://github.com/alphapapa/prism.el](https://github.com/alphapapa/prism.el){rel="noreferrer noopener"}
+ has some interesting colour experiments as well
+- \<polezaivsani\> i felt about same with the christmas tree colored
+ code editor
+- sachac: annoyance is a great motivator for learning Emacs Lisp
+ - sachac: Yay fellow Dvorak user!
+- \<neil\> :
+ [https://github.com/rytswd/hasliberg-theme](https://github.com/rytswd/hasliberg-theme){rel="noreferrer noopener"}
+- Thanks :)
+- \<ryota\> Thank you everyone for tuning in! Also my slides are
+ available at
+ [https://codeberg.org/rytswd/emacsconf-2024](https://codeberg.org/rytswd/emacsconf-2024){rel="noreferrer noopener"}
+
[[!inline pages="internal(2024/info/color-after)" raw="yes"]]
diff --git a/2024/talks/open-mic.md b/2024/talks/open-mic.md
index 58ae8937..8680c648 100644
--- a/2024/talks/open-mic.md
+++ b/2024/talks/open-mic.md
@@ -12,11 +12,78 @@
[[!inline pages="internal(2024/info/open-mic-before)" raw="yes"]]
-# Table of Contents
-
-
-
-
+# Discussion
+
+- sachac: I had fun writing some code to copy a line from ERC for easier copying to Etherpad, that was a nice new thing for EmacsConf 2024. Also the random package mentions on our countdown screen was fun too. This year I've had less time to work on Emacs-y things (about half the time compared to last year's leadup to EmacsConf), but it's nice to see we can still pull it off!
+- transient discussion:\
+- \<maxxcan\`\> do you like to much hydra? Leo?
+- \<gg\> I love which-key.
+ - \<oylenshpeegul\> Yeah, I think adding which-key to Emacs 30 was
+ a great idea!
+- \<srandby\> I wrote a transient to make it easy to access various
+ Emacs help resources, and I don't know Elisp very well.    
+- \<lounge-502\> Its amazing how in emacs people don't need to
+ frequently migrate to the newer packages all the time.
+- \<inkpotmonkey\> at one point i experimented a bit with using
+ transcient as an interface to run shell commands that I was trying
+ to parse from the man pages, i still think this is an interesting
+ discoverability into all the options that shell commands offer
+ - \<lounge-502\> inkpotmonkey: ffmpeg comes to mind
+- \<maxxcan\`\> I use transient for my job, and that save my life.
+- \<plattfot\> I wrote a little package that combines transient and
+ tabulated list mode to fetch issues from services as jira. 
+ Transient is a nice package to quickly get an UI going.
+- \<zaeph\> eldoc-mode.\
+- \<ElephantErgo\> I also kinda just had a thought for discussion. Browser related thoughts and speculation
+- sachac: I've been using spookfox to control Firefox from Elisp,
+ which has been handy for some automation (can both send stuff to and
+ get stuff out of Firefox, I have some blog posts about it)
+- \<ElephantErgo\>
+ [https://github.com/browsh-org/browsh](https://github.com/browsh-org/browsh){rel="noreferrer noopener"}
+- Discussion: Right now it exist as a bunch of hacks on top of sly 
+ 12:16:19 
+- \<karthik\> re: qutebrowser \--
+ [https://github.com/lrustand/qutebrowser.el](https://github.com/lrustand/qutebrowser.el){rel="noreferrer noopener"}
+- \<ElephantErgo\> karthik: WOW! I am going to have to start using
+ this immediately! Thank you!
+- \<ElephantErgo\> I've been really meaning to try out Meow as a
+ long-time Evil user 🙂
+
+\<fristed\> I've been experimenting with using emacs as a GUI toolkit
+for common lisp applications\
+
+- \- \<robin\> fristed, ooo, does your experiment have a home/name?
+ i've been wondering about using emacs as an interface for clim apps
+ (partly as a step towards using clim in emacs, possibly), seems
+ possible considering that their was a web-based interface in the
+ 1990s
+- \<edrx\> fristed: have you shared links about this? "emacs as a GUI
+ toolkit for common lisp applications"
+- \<edrx\> I would like to take a look
+ - \<robin\> edrx, did you see my guile talk? you might be
+ interested in the long-term future section :)
+- \<fristed\> edrx: Currently I do not have any public items yet, but
+ now I know that there is interest i'll look into it
+- \<fristed\> If i have something working next year i'll consider
+ having a emacsconf talk. It is inspired by CLOG, but using emacs
+ instead of the browser
+- oooh, another possible topic for discussion: what's something you've recently started trying in Emacs?
+
+- \- \<wasamasa\> I've been experimenting with using semgrep to
+ review elisp for security issues 
+
+- \<ElephantErgo\> It was really cool being able to jump in! 😊
+- \<edrx\> hey hey, I've been experimenting with ways to make packages
+very easy to try! link:
+[http://anggtwu.net/2024-find-tryit-links.html](http://anggtwu.net/2024-find-tryit-links.html){rel="noreferrer noopener"}\
+
+- \<edrx\> to the person who was lounge-928 a few minutes ago: I found
+ the slide in which I start to discuss choosing the right level of
+ detail! See here:
+ [http://anggtwu.net/emacsconf2024.html#16:06](http://anggtwu.net/emacsconf2024.html#16:06){rel="noreferrer noopener"}
+
+- \<cow_2001\> everyone should know of greader-mode.  it is amazing.  i
+use it all the time\
[[!inline pages="internal(2024/info/open-mic-after)" raw="yes"]]
diff --git a/2024/talks/theme.md b/2024/talks/theme.md
index 9df68c8b..6358b33d 100644
--- a/2024/talks/theme.md
+++ b/2024/talks/theme.md
@@ -25,6 +25,42 @@ I'm picky about how it looks. This talk shows how may hoops I'm
willing to jump through to make it look "right".
+# Discussion
+
+## Questions and answers
+
+- Q: When you choose colors based on the same lightness, does it not
+ hurt readability since the eye sees lightness most?
+ - A: 
+- Q: One area I see emacs able to do themes that is "underused?" is
+ changing the font. font size, font typee, monospace or perpotional,
+ bold. based on the varios faceets of emacs. Is it a magit issie a
+ code comment a  code string or varible name etc\...
+ - A:
+- Q:
+ - A:
+- Q: For monte-carlo, are all the "random" colors picked using a
+ colorwheel/hue rotation? 
+ - A:
+- Q: Have you ever kept any of the random themes that were thrown up?
+ - A: No. When Emacs picks monte carlo by chance, I wouldn't know
+ about it. That's why I didn't keep any of the themes it
+ generated.
+- Q:
+ - A:
+
+## Notes
+
+- Links:
+ - [https://github.com/MetroWind/flucui-theme](https://github.com/MetroWind/flucui-theme){rel="noreferrer noopener"}
+ - [https://github.com/MetroWind/lab-theme](https://github.com/MetroWind/lab-theme){rel="noreferrer noopener"}
+ - [https://github.com/MetroWind/notink-theme](https://github.com/MetroWind/notink-theme){rel="noreferrer noopener"}
+ - [https://github.com/MetroWind/monte-carlo-theme](https://github.com/MetroWind/monte-carlo-theme){rel="noreferrer noopener"}
+- Comment: Hi MetroWind, your lab-theme was the inspo for my initial
+ color space journey \~6 years ago, thanks for putting your work out
+ there
+ - Wow I'm so glad you found your inspiration! Thanks!
+
[[!inline pages="internal(2024/info/theme-after)" raw="yes"]]
diff --git a/2024/talks/transducers.md b/2024/talks/transducers.md
index 5abe4371..8f5ee12d 100644
--- a/2024/talks/transducers.md
+++ b/2024/talks/transducers.md
@@ -39,6 +39,169 @@ ported the pattern to three other Lisps.
Colin is originally from Canada and lives in Japan.
+# Discussion
+
+## Questions and answers
+
+- Q: When I tried comparing transducers.el to cl-lib and dash
+ (benchmark-compiled), I got the following results:
+ ```
+cl-lib: 0.5 sec, 2 GCs
+dash: 0.3 sec, 1 GC,
+transducers: 0.75 sec, 2 GC
+cl-loop: 0.025 sec, 0 GC (note: 0.025, one order-of-magnitude faster)
+I expected transducers to be slower than cl-loop but faster than the
+cl-lib or dash.  However this isn't the case.  Any idea why? (benchmark
+is here:
+[https://old.reddit.com/r/emacs/comments/1h5c778/which_emacsconf_2024_talks_have_your_attention/m061dge/](https://old.reddit.com/r/emacs/comments/1h5c778/which_emacsconf_2024_talks_have_your_attention/m061dge/){rel="noreferrer noopener"})
+ ```
+ - (benchmark-run-compiled 1000  (cl-loop for n from 1 below
+ 2000 by 2           sum (\* n n) into total          
+ finally return total))
+- - A: Loop is always going to win in cases like this where we are
+ not doing two nested (e.g.) change calls, what I called comp
+ steps.  tranducers shines while we need to do things which chain
+ things together; we can sometimes express ourselves more clearly
+ vs loop.  this may sound sounds like moving the goal-posts:
+ it's really about internal function calls, avoiding stepping
+ though each loop in ways which loop doesn't need to do, so loop
+ might "win".
+ - Note: I'm comparing against cl-lib and dash \-- the cl-loop is
+ only for reference. I'm curious about the performance gap
+ between transducers and cl-lib/dash.  The number of function
+ calls is the same for cl-lib and dash and transducers.
+
+- Q: Did you think about generators as a source cf lists, vectors,
+ etc? Maybe I got a word wrong. After the development that generators
+ and Series operations needed-each-other, not being redundant as had
+ been thought. I forgot who the generators person was in lisp.
+ - A:
+
+- Q:  Do you know of any theoretical texts on transducers?
+ - A: My README and Rich Hickey (inventor of Clojure) may be the
+ key texts on transducers. 
+ - and his talks/videos (on the topic)
+ - [https://andreyorst.gitlab.io/posts/2022-08-13-understanding-transducers/](https://andreyorst.gitlab.io/posts/2022-08-13-understanding-transducers/){rel="noreferrer noopener"}
+ - (not fosskers): I think AIM-1082 is interesting to read. 
+ ([https://dspace.mit.edu/handle/1721.1/6035](https://dspace.mit.edu/handle/1721.1/6035){rel="noreferrer noopener"}?)
+ Yes
+
+- Q: Waters (lazy series in lisp, late 70s) said that this \*should
+ have\* been done as an additional compiler feature in compilers, but
+ if not it must be a macro package. Did you think about that viz your
+ cl, fennel, elisp, porting of your transducers?
+ - A: I think my work could help provide the basis for this;
+ there's much more to be done.
+
+- Q: Does t-buffer-read provide a lazy stream that's linewise, or
+ charwise, or do something else entirely?
+ - A: t-file-read
+
+- Q: Can the Elisp library be combined with the stream.el API
+ ([https://elpa.gnu.org/packages/stream.html](https://elpa.gnu.org/packages/stream.html){rel="noreferrer noopener"})? 
+ Or seq in general?
+ - A: I'd say these libraries are completely orthogonal. (Re: what
+ made me ask this question was seeing \`t-buffer-read' and
+ hoping that this doesn't convert a buffer into a string)  With
+ seq/generics it should just work: magic of defgeneric
+
+- Q: How does one debug a t-comp expression? Can you single step and
+ see intermediate results of the different statements you declare?
+ - A: In Common Lisp it is wonderful. In Emacs Lisp it is more
+ complicated. I don't know if step debugging would work, but
+ there is a "log" (?) function to print out values.
+
+- Q: Is there a path for transducers to enable elisp processing of
+ otherwise overly large datasets as if just normal Emacs "buffers"
+ (i.e. just pulling one thing at a time so essentially stream-like
+ under the hood but buffer-like in interface), with none of the usual
+ perf issues with a traditional buffer structure?
+ - A: Possibly so yes
+
+- Q: Re the performance issues mentioned and that popped up recently
+ in the lists/forums, to what extend does tailcall optimization and
+ other mechanisms (incl. inlining, GC-friendliness, etc.) could
+ eventually alleviate issues and enable their use at little to no
+ extra cost?
+ - A: Over time, with further work and optimizations. Some already
+ there (taillcall notably)
+
+- Q: Is there an option to read a csv/json and produce an alist or
+ plist instead of a hash table for an entry?
+ - A:  Absolutely.
+
+- Q: Is the common lisp version ready for 'production' use? Is it
+ complete enough and the API stable enough?
+ - A: I use it all the time. I use it extensively. Programming a
+ game, not realizing a dent in the frame rate.
+
+- Q: Do we need a pre-written "t-" version for every already
+ existing reducing function like + or is there a function to
+ construct them from already defined reducer 2-arg functions?
+ - A:
+
+- Q: Is the compelling argument for transducers is that it's a better
+ abstraction? Seems like a lot of concerns/objections (while
+ pragmatically valid) are focused on implementation. Can this
+ abstraction allow for advances in implementation?
+ - A:
+
+- Time for the closing remarks, but people can stay on the pad or join
+ the BBB and keep going
+
+## Notes
+
+- \<lounge-081\> What made transducers click for me way back when was
+ realizing that the usual operations (think map/reduce/filter/etc and
+ their generalizations) implicitly or explicitly demand realized
+ collections, plus intermediate ones between those operations (and
+ GC), instead of composing such transformations into one operation
+ and then making this applicable to streams of unknown-sizes and
+ such.
+ - \<robin\> lounge-081, ah, like\...\*thinks very hard\*\...stream
+ fusion, iirc?
+ [http://lambda-the-ultimate.org/node/2192](http://lambda-the-ultimate.org/node/2192){rel="noreferrer noopener"}
+ that makes a lot of sense
+ - \<lounge-081\> "Rich Hickey has a point" need never be said :)
+- \<Ez3\> Sorry but map is collect and filter is select for me :)
+- \<lounge-081\> \@robin: there are many ways to get to them (some may
+ already think of those functions as folds, etc.), but for the bulk
+ of people familiar with map/reduce/filter/etc, it's useful to enter
+ the thinking realizing that you may have infinite streams (of any
+ type even) on input, and may not want to have realized collections
+ at every step of the usual function applications, thus the need to
+ compose the things that make up a map/reduce/filter/etc before
+ applying them one by one on a continued stream of things one at a
+ time
+- \<NullNix\> ellis: I wrote about half of one in binutils libctf
+ (generators, anyway). See the \*\_next() functions. Having seen this
+ I'll try to mutate the internals to something closer, right now
+ every iterator is independently implemented (mostly).
+ - \<NullNix\> (inspired by generators, not transducers, since I
+ didn't know about them)
+ - \<NullNix\> still \*far\* less ugly than "call a function with
+ every item" \*\_iter() stuff
+- \<lounge-081\> Thanks for the answers fosskers, I'm quite hopeful
+ with transducers working their way into many things, so thinking
+ ahead to where that may happen and to solving perf hurdles
+- \<ElephantErgo\> I'm totally sold. I'm working on a CL codebase
+ right now, and these are going in there immediately
+- \<robin\> (also CL does not require TCO but good compilers support
+ it to the extent that extensive use of FP is practical)
+- \<ellis\> it's a tricky protocol to get perfect the first time for
+ sure, is something that transcends language barriers so always fun
+ to see more impls :)
+- \<robin\> CLTL2 docs on SERIES for those who are curious
+ [http://www.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/html/cltl/clm/node347.html#SECTION003400000000000000000](http://www.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/html/cltl/clm/node347.html#SECTION003400000000000000000){rel="noreferrer noopener"}
+ - \<robin\> (lisp.se mirror in case the ai repository disappears
+ someday:
+ [http://cltl2.lisp.se/cltl/clm/node347.html](http://cltl2.lisp.se/cltl/clm/node347.html){rel="noreferrer noopener"}
+ )
+- \<robin\> definitely watching this one more carefully. if it's
+ CLOS-oriented i'm going to like it
+- \<robin\> note that full TCO is strictly more expressive than
+ special-case optimizations as with emacs's cl-labels
+
[[!inline pages="internal(2024/info/transducers-after)" raw="yes"]]
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-13 04:03:11 +0000