From 1147abeaa0686a5ae3c71df674ccd709b4b3617f Mon Sep 17 00:00:00 2001 From: Sacha Chua Date: Fri, 13 Dec 2024 11:03:03 -0500 Subject: add answers captions --- ...eemacs-relaunched--robin-templeton--answers.vtt | 720 +++++++++++++++++++++ 1 file changed, 720 insertions(+) create mode 100644 2024/captions/emacsconf-2024-guile--beguiling-emacs-guileemacs-relaunched--robin-templeton--answers.vtt (limited to '2024/captions/emacsconf-2024-guile--beguiling-emacs-guileemacs-relaunched--robin-templeton--answers.vtt') diff --git a/2024/captions/emacsconf-2024-guile--beguiling-emacs-guileemacs-relaunched--robin-templeton--answers.vtt b/2024/captions/emacsconf-2024-guile--beguiling-emacs-guileemacs-relaunched--robin-templeton--answers.vtt new file mode 100644 index 00000000..510e556e --- /dev/null +++ b/2024/captions/emacsconf-2024-guile--beguiling-emacs-guileemacs-relaunched--robin-templeton--answers.vtt @@ -0,0 +1,720 @@ +WEBVTT + +00:00:00.000 --> 00:00:08.119 +All right. Hey, thanks for bearing with us there. We had a + +00:00:08.120 --> 00:00:11.239 +couple of bumps in the road, a cross between a couple of + +00:00:11.240 --> 00:00:13.479 +different versions of our program that we deliver here, + +00:00:13.480 --> 00:00:17.959 +different ways that we bring this stream together between + +00:00:17.960 --> 00:00:22.359 +the recorded content that that speakers are putting + +00:00:22.360 --> 00:00:26.879 +together in advance in the live content, such as what you're + +00:00:26.880 --> 00:00:31.039 +seeing right here. So thanks go to Sacha and Leo, and + +00:00:31.040 --> 00:00:34.359 +everybody behind the stages gluing it all together. And + +00:00:34.360 --> 00:00:40.199 +we're back here now, and I'm speaking with Robin, who us + +00:00:40.200 --> 00:00:42.799 +ready to take on some of your questions and address some of + +00:00:42.800 --> 00:00:46.879 +the comments over here on the etherpad. If you want to jump in + +00:00:46.880 --> 00:00:51.319 +there, there's links in the chat. And thanks so much, Robin, + +00:00:51.320 --> 00:00:53.999 +for your talk. And it's also been a pleasure chatting with + +00:00:54.000 --> 00:00:57.919 +you just a little bit over the last couple of months on IRC. + +00:00:57.920 --> 00:01:33.319 +Yeah, absolutely. Great meeting you. + +00:01:33.320 --> 00:01:37.679 +All right. All right, everyone. I think I am streaming now. + +00:01:37.680 --> 00:01:42.439 +So let's look at it. Let's see. I see the IRC scrolling. So + +00:01:42.440 --> 00:01:47.199 +let's see where that's going. Yes, the Common Lisp is what I + +00:01:47.200 --> 00:01:50.519 +thought would piss people off. And because it's not part of + +00:01:50.520 --> 00:01:54.239 +either community, but I think it would be a good compromise + +00:01:54.240 --> 00:01:57.839 +for building a Lisp into a language that's more suitable for + +00:01:57.840 --> 00:02:01.879 +building large systems like the kind that we are building in + +00:02:01.880 --> 00:02:07.279 +Emacs today. I also left out an important part of the talk, + +00:02:07.280 --> 00:02:12.079 +which is part of the motivation for transitioning from C to + +00:02:12.080 --> 00:02:15.599 +Lisp. And that's the performance characteristics + +00:02:15.600 --> 00:02:19.399 +fundamentally change when you get a modern and high + +00:02:19.400 --> 00:02:23.559 +performance Lisp system involved. it starts getting less + +00:02:23.560 --> 00:02:27.799 +practical to just call out to C to speed up every operation. + +00:02:27.800 --> 00:02:31.559 +Among other things, you lose the ability to use more + +00:02:31.560 --> 00:02:34.759 +advanced control structures, like the limited + +00:02:34.760 --> 00:02:40.039 +continuations. And you also have to pay the overhead of + +00:02:40.040 --> 00:02:43.879 +calling out to our foreign function. So it gets to be an + +00:02:43.880 --> 00:02:47.879 +increasingly better deal to optimize your list + +00:02:47.880 --> 00:02:52.719 +implementation and provide ways for building faster list + +00:02:52.720 --> 00:02:55.879 +programs, such as type annotations, once you've gotten + +00:02:55.880 --> 00:03:01.479 +over a certain threshold of performance. + +NOTE Q: About fibers: My understanding is that the problem with making Elisp concurrent is that none of the data structures (buffer, cons, vector, window etc) are concurrency-safe.  How do fibers help with this? + +00:03:01.480 --> 00:03:07.359 +I'm going to look at the pad. Here we go. The first question is + +00:03:07.360 --> 00:03:12.519 +about fibers and whether they help with making Elisp + +00:03:12.520 --> 00:03:18.279 +concurrent in terms of its data structures. Yes, that's + +00:03:18.280 --> 00:03:23.879 +absolutely correct. Fibers by themselves do not provide + +00:03:23.880 --> 00:03:26.799 +thread safety for any of the existing Emacs data + +00:03:26.800 --> 00:03:32.879 +structures. What they are useful for is building things + +00:03:32.880 --> 00:03:38.199 +that don't use Emacs data structures, say a network client + +00:03:38.200 --> 00:03:44.559 +that reads input from a stream or in scheme, a port or a stream + +00:03:44.560 --> 00:03:49.679 +instead of a buffer. And we can also take a look at options for + +00:03:49.680 --> 00:03:54.199 +making more Emacs features concurrency safe or thread + +00:03:54.200 --> 00:03:58.079 +safe. For example, we could introduce the idea of a thread + +00:03:58.080 --> 00:04:03.039 +local buffer that didn't require locks for sharing between + +00:04:03.040 --> 00:04:09.239 +different threads. And I'm not sure how that would develop, + +00:04:09.240 --> 00:04:12.319 +but I'm sure the Emacs maintainers already have some ideas + +00:04:12.320 --> 00:04:17.519 +in this direction. Fibers will basically provide a + +00:04:17.520 --> 00:04:22.159 +high-performance system that you can use apart from + +00:04:22.160 --> 00:04:28.079 +ordinary Emacs-less constructs. + +NOTE Q: Do you have a rough idea of how much of Guile is written in C? + +00:04:28.080 --> 00:04:34.839 +Let's see. We have another question. Emacs is roughly 25% C. + +00:04:34.840 --> 00:04:38.839 +How much of Guile is in C? + +00:04:38.840 --> 00:04:45.679 +Well, part of my point about C is not so much that there, well, + +00:04:45.680 --> 00:04:50.279 +obviously, I phrased it a little provocatively, but the + +00:04:50.280 --> 00:04:54.719 +problem is not so much that there is C, but that there is so + +00:04:54.720 --> 00:05:00.279 +much C involved in every single layer of the application. + +00:05:00.280 --> 00:05:04.559 +So, for example, we're limited in our ability to use tools + +00:05:04.560 --> 00:05:08.159 +like limit continuations, which can be used to express + +00:05:08.160 --> 00:05:13.599 +buffer local variable binding in a few dozen lines, because + +00:05:13.600 --> 00:05:21.839 +Emacs has so much calling back and forth between guile and C, + +00:05:21.840 --> 00:05:26.599 +due to so much basic functionality being in primitive C + +00:05:26.600 --> 00:05:34.119 +subroutines. So that's one issue apart from the question of + +00:05:34.120 --> 00:05:38.359 +how much is in a particular language. To answer the question + +00:05:38.360 --> 00:05:45.879 +about Guile, Guile has about 165,000 lines of scheme code + +00:05:45.880 --> 00:05:51.599 +and about 160,000 lines of C code, so it's about half and + +00:05:51.600 --> 00:05:55.879 +half. And that shouldn't really be surprising given that it + +00:05:55.880 --> 00:06:00.359 +is actually focused on low-level things like building a + +00:06:00.360 --> 00:06:05.079 +high-performance bytecode compiler, and a just-in-time + +00:06:05.080 --> 00:06:09.719 +compiler, and so on, as well as providing its own fairly + +00:06:09.720 --> 00:06:14.999 +rich, but still far less complete than Emacs's standard + +00:06:15.000 --> 00:06:19.239 +library, in terms of Ice9 and other system libraries + +NOTE Q: A Common Lisp implementation for Guile sounds really cool! Is there already work on this underway? + +00:06:19.240 --> 00:06:24.359 +shipped with Guile. The next question is on a Common Lisp + +00:06:24.360 --> 00:06:27.759 +implementation for Guile, and whether work on it is + +00:06:27.760 --> 00:06:33.079 +underway. In fact, work on it is already underway. I've been + +00:06:33.080 --> 00:06:36.399 +working on it on and off in my spare time for a couple of years + +00:06:36.400 --> 00:06:40.039 +now. I've gotten, I think, a couple of chapters of the + +00:06:40.040 --> 00:06:43.519 +hyperspectin, if you want to measure it that way. But I've + +00:06:43.520 --> 00:06:51.719 +been focusing my work more on research and on what we need to + +00:06:51.720 --> 00:06:57.399 +do to have a LISP environment, a polyglot LISP environment, + +00:06:57.400 --> 00:07:02.759 +wherein the features of Common Lisp and Scheme and Emacs + +00:07:02.760 --> 00:07:08.919 +Lisp can all work easily and ergonomically together. So + +00:07:08.920 --> 00:07:13.879 +this involves things like the question of Lisps having + +00:07:13.880 --> 00:07:22.079 +Lisp1s versus Lisp2s. That is, a Lisp1-like scheme has one + +00:07:22.080 --> 00:07:27.599 +namespace, like every variable is a single name that can + +00:07:27.600 --> 00:07:31.999 +refer to one value, whereas in Lisp2s like EmacsLisp, + +00:07:32.000 --> 00:07:37.399 +symbols can have different definitions as functions and as + +00:07:37.400 --> 00:07:41.119 +variables, as well as other namespaces like property + +00:07:41.120 --> 00:07:45.719 +lists. So Kent Pittman has some interesting thoughts on + +00:07:45.720 --> 00:07:51.039 +this that I've been looking into. Another issue is the + +00:07:51.040 --> 00:07:57.519 +interaction between package and module systems. So I don't + +00:07:57.520 --> 00:08:01.839 +have really anything ready to publish just yet on this, but I + +00:08:01.840 --> 00:08:05.279 +have been looking into the background issues of + +00:08:05.280 --> 00:08:08.119 +integrating this into Guile in a useful way. + +00:08:08.120 --> 00:08:15.719 +And let's see, one other thing I was going to mention. + +00:08:15.720 --> 00:08:27.679 +Okay, I've lost it. But yeah, there is some work already. And + +00:08:27.680 --> 00:08:30.399 +if people are interested in moving Emacs in this direction, + +00:08:30.400 --> 00:08:34.479 +then we'll certainly start working on it in earnest. + +NOTE Q: Did switching from guile 2 to 3 give any performance benefits? + +00:08:34.480 --> 00:08:41.119 +Another question, did switching from Guile 2 to 3 give any + +00:08:41.120 --> 00:08:46.279 +performance benefits? Well, honestly, we're not really + +00:08:46.280 --> 00:08:50.759 +benchmarking stuff here because Guile Emacs has so much + +00:08:50.760 --> 00:08:55.759 +overhead from structuring the compiler to closely conform + +00:08:55.760 --> 00:08:59.879 +to Emacs in terms of like even things as simple as metadata + +00:08:59.880 --> 00:09:03.879 +layout for variable information. + +00:09:03.880 --> 00:09:11.999 +So I haven't actually noticed a perceptual change. I would + +00:09:12.000 --> 00:09:15.359 +guess based on the Gabriel benchmark results that is + +00:09:15.360 --> 00:09:21.399 +benefited from what somewhat from Gal 3's performance + +00:09:21.400 --> 00:09:27.479 +improvements but for Emacs I just don't know yet and working + +00:09:27.480 --> 00:09:30.199 +on the compiler's code generation and lowering the + +00:09:30.200 --> 00:09:33.719 +overhead is going to be the thing that provides the most + +00:09:33.720 --> 00:09:37.319 +return for improving that aspect of Gal Emacs. + +00:09:37.320 --> 00:09:54.079 +Let's see, I see SICL mentioned here, as well as SPCL. And it + +00:09:54.080 --> 00:09:56.919 +could certainly help with the implementation of + +00:09:56.920 --> 00:10:01.519 +Commonwealth and Guile, because a lot of the basic stuff is + +00:10:01.520 --> 00:10:05.559 +just providing a new interface to some bit of + +00:10:05.560 --> 00:10:08.879 +functionality. Like the sequence library, it's mostly + +00:10:08.880 --> 00:10:13.279 +stuff that we already have through SR5 and so on. The + +00:10:13.280 --> 00:10:16.879 +difficult, well, not the difficult but the time consuming + +00:10:16.880 --> 00:10:21.599 +parts are going to be all the little DSL sitcom on this path + +00:10:21.600 --> 00:10:26.999 +packed up inside it like pretty printing format loop and so + +00:10:27.000 --> 00:10:32.359 +on. It's for those high-level features that I think we could + +00:10:32.360 --> 00:10:34.959 +potentially share code with other Common Lisp + +00:10:34.960 --> 00:10:39.039 +implementations. And Common Lisp implementations do tend + +00:10:39.040 --> 00:10:43.239 +to be permissively licensed, SPCL's public domain, for + +00:10:43.240 --> 00:10:46.439 +example, so there's no barrier to sharing code with them. + +NOTE Q: Do you know if the Emacs maintainers are interested in switching to Guile as the engine for Emacs Lisp? + +00:10:46.440 --> 00:10:52.719 +There's another question about whether the Emacs + +00:10:52.720 --> 00:10:55.679 +maintainers are interested in switching to Guile as the + +00:10:55.680 --> 00:10:59.199 +engine for Emacs Lisp. I can't speak for the current + +00:10:59.200 --> 00:11:05.439 +maintainers. I can say that people have talked to previous + +00:11:05.440 --> 00:11:10.439 +Emacs maintainers about the whole idea, and their attitude + +00:11:10.440 --> 00:11:15.479 +was generally cautiously optimistic. As in, it's not + +00:11:15.480 --> 00:11:18.799 +something they, it's somewhat political, they didn't want + +00:11:18.800 --> 00:11:23.479 +to get into it, but they didn't think that it was a bad idea, + +00:11:23.480 --> 00:11:25.919 +and they wanted to know more about how it might evolve in the + +00:11:25.920 --> 00:11:31.879 +future. I can comment that Eli Zaretsky, who I believe is the + +00:11:31.880 --> 00:11:36.879 +current Emacs maintainer, is very concerned about + +00:11:36.880 --> 00:11:44.679 +cross-platform compatibility. And so if I can guess at his + +00:11:44.680 --> 00:11:48.519 +priorities correctly, I think that that's something that + +00:11:48.520 --> 00:11:52.599 +we'll have to make sure is rock solid before we propose any + +00:11:52.600 --> 00:11:58.359 +kind of upstreaming of Gala Emacs. but in general + +00:11:58.360 --> 00:12:03.719 +maintainers have been cautious but curious. So I just + +00:12:03.720 --> 00:12:06.719 +wanted to break in and note at this point that as lives I + +00:12:06.720 --> 00:12:09.519 +didn't sorry I couldn't do so more gracefully while we were + +00:12:09.520 --> 00:12:13.439 +still on stream but I wanted to let you know that just as of 10 + +00:12:13.440 --> 00:12:17.399 +seconds ago or so we've had to cut away into our next talk but + +00:12:17.400 --> 00:12:22.199 +we can keep going here as long as we like. Okay, let's wrap up. + +00:12:22.200 --> 00:12:25.399 +There's only a couple questions left on the pad, so I'll + +00:12:25.400 --> 00:12:29.999 +answer those, and then I'll be available on IRC. So, the next + +NOTE Q: Do you think guile-emacs will be able to use or (collaborate with) some of the other awesome projects around Emacs Lisp? + +00:12:30.000 --> 00:12:33.319 +question is whether Guile Emacs will be able to collaborate + +00:12:33.320 --> 00:12:35.959 +with projects like Gypsum and + +00:12:35.960 --> 00:12:44.319 +the native compilation projects or the pre-scheme + +00:12:44.320 --> 00:12:48.039 +efforts. Oh, yes, that is one of the things I forgot to bring + +00:12:48.040 --> 00:12:53.199 +up in my talk. So, first of all, Gypsum is approaching a + +00:12:53.200 --> 00:12:58.199 +similar idea from a different direction. And we clearly + +00:12:58.200 --> 00:13:03.919 +have a different focus. My focus is on improving Emacs Lisp + +00:13:03.920 --> 00:13:09.279 +and making Emacs itself better by integrating Guile Elisp + +00:13:09.280 --> 00:13:15.159 +and Emacs, rather than replacing eLisp or deprecating it in + +00:13:15.160 --> 00:13:20.159 +any way. But given gypsum's requirements, I do think that we + +00:13:20.160 --> 00:13:26.439 +could share a lot of code required for emulating basic Emacs + +00:13:26.440 --> 00:13:29.839 +functionality. And this could even become interesting if + +00:13:29.840 --> 00:13:35.799 +we get to the point of rewriting parts of Emacs in Lisp. With + +00:13:35.800 --> 00:13:41.279 +respect to the native compilation effort, I'm familiar + +00:13:41.280 --> 00:13:45.879 +with it. I'm not that impressed with the results of it. It's a + +00:13:45.880 --> 00:13:52.359 +very impressive effort, but as far as I can tell, it's + +00:13:52.360 --> 00:13:57.239 +accelerating a bytecode interpreter that just simply has + +00:13:57.240 --> 00:14:02.719 +an out-of-date design, to be quite blunt. It's possible + +00:14:02.720 --> 00:14:08.919 +that Emacs's JIT has ideas that Guile should adopt, like + +00:14:08.920 --> 00:14:14.039 +perhaps libgccjit might perhaps be better than GNU + +00:14:14.040 --> 00:14:16.999 +Lightning, which is a relatively simple JIT that Guile + +00:14:17.000 --> 00:14:17.639 +uses. + +00:14:17.640 --> 00:14:25.839 +But it doesn't have to have a direct relationship to Guile + +00:14:25.840 --> 00:14:31.159 +Emacs. And as far as pre-scheme goes, I have been watching + +00:14:31.160 --> 00:14:36.199 +Flat Watson's work on pre-scheme with great interest + +00:14:36.200 --> 00:14:39.999 +because Scheme 48 used to be my favorite implementation. + +00:14:40.000 --> 00:14:44.919 +And I do think that it could be, it's a tool that we should look + +00:14:44.920 --> 00:14:47.879 +at when we're thinking about moving functionality into + +00:14:47.880 --> 00:14:53.199 +Lisp and could certainly make it easier to upstream some of + +00:14:53.200 --> 00:14:54.519 +the work we may end up doing. + +00:14:54.520 --> 00:15:04.199 +All right, do we have more questions? + +NOTE Q: SBCL, ...You mentioned Robert Strandh's SICL along with SBCL---does that work help with the implementation of CL in Guile? + +00:15:04.200 --> 00:15:13.159 +There's a question about SICL and SBCL. I think I answered + +00:15:13.160 --> 00:15:17.519 +that earlier. It should help us implement Common Lisp when + +00:15:17.520 --> 00:15:24.999 +it comes to high-level features and the various large + +00:15:25.000 --> 00:15:28.759 +subcomponents of Common Lisp. Another important factor is + +00:15:28.760 --> 00:15:32.279 +that Guile already has decent support for the Common Lisp + +00:15:32.280 --> 00:15:35.799 +object system. Without that, it would be far more + +00:15:35.800 --> 00:15:41.919 +difficult. But I do expect that we can share code with other + +00:15:41.920 --> 00:15:44.799 +Common Lisp implementations. I've personally rated + +00:15:44.800 --> 00:15:49.199 +Common Lisp compiler code when working on Guile Hoot, for + +00:15:49.200 --> 00:15:52.959 +example. So there are definitely places where they can + +00:15:52.960 --> 00:15:54.039 +contribute. + +00:15:54.040 --> 00:16:02.839 +Regarding the Hoot project and its relationship to + +00:16:02.840 --> 00:16:11.079 +Galimax, it's a purely speculative thing. First of all, + +00:16:11.080 --> 00:16:17.079 +Hoot is only tested on Scheme-to-WebAssembly + +00:16:17.080 --> 00:16:22.599 +compilations. I've heard some suggestions that some uses + +00:16:22.600 --> 00:16:26.439 +of Tree.io may not be compatible with the Hoot compiler. I'm + +00:16:26.440 --> 00:16:29.999 +not sure if that's the case or not. + +00:16:30.000 --> 00:16:41.199 +But it is a complete enough project that if Emacs is, say, 90% + +00:16:41.200 --> 00:16:45.119 +Lisp, there's only a few thousand lines of C code to + +00:16:45.120 --> 00:16:49.159 +implement, then it would be entirely practical to compile + +00:16:49.160 --> 00:16:54.159 +Emacs WebAssembly, as long as we had a back end, like one + +00:16:54.160 --> 00:16:58.119 +based on the browser's document object model, or some sort + +00:16:58.120 --> 00:17:04.439 +of graphical interface through WASI. And that may have some + +00:17:04.440 --> 00:17:07.359 +interesting applications for portability to unusual + +00:17:07.360 --> 00:17:11.359 +platforms. It may even bring performance advantages in + +00:17:11.360 --> 00:17:18.959 +cases where the WebAssembly implementation is connected + +00:17:18.960 --> 00:17:22.759 +to a tracing just-in-time compiler, because that may be + +00:17:22.760 --> 00:17:26.839 +more appropriate to the high level of dynamism the Emacs + +00:17:26.840 --> 00:17:32.439 +list has than the kind of simple template JITs that both + +00:17:32.440 --> 00:17:34.519 +Emacs and Guile are using. + +00:17:34.520 --> 00:17:39.799 +What a fascinating point. Just to break into active + +00:17:39.800 --> 00:17:43.999 +listening a little so this doesn't, to you, feel like you're + +00:17:44.000 --> 00:17:46.919 +talking to yourself. I can see from chat and the questions + +00:17:46.920 --> 00:17:51.439 +still coming in, you know, comments. You know, it isn't, but + +00:17:51.440 --> 00:17:54.999 +I just want you to be able to hear and feel that. Yeah, great, + +00:17:55.000 --> 00:18:00.679 +great point there. All right. Thank you. And yes, if there + +00:18:00.680 --> 00:18:04.679 +are more questions, keep throwing them at me. I should + +00:18:04.680 --> 00:18:07.999 +probably also mention I will have to jump out myself, but the + +00:18:08.000 --> 00:18:10.799 +recording will automatically end when we all jump out or + +00:18:10.800 --> 00:18:15.199 +just drop a note anywhere, ping me, whatever. And I'll come + +00:18:15.200 --> 00:18:18.439 +along and shut off the recording and we'll trim it up before + +00:18:18.440 --> 00:18:21.879 +we publish it. I'm looking forward to reading through + +00:18:21.880 --> 00:18:30.199 +anything I do miss. Thank you. Sounds good. + +00:18:30.200 --> 00:19:08.439 +All right, I'm not seeing changes in the etherpad. So I'm + +00:19:08.440 --> 00:19:14.999 +going to close this in maybe 30 seconds if there are no more + +00:19:15.000 --> 00:19:21.159 +additions. Thanks, everyone, for the interesting and very + +00:19:21.160 --> 00:19:26.399 +pointed questions on some of the most significant areas. I + +00:19:26.400 --> 00:19:31.919 +appreciate everyone's feedback. I'm glad this provoked so + +00:19:31.920 --> 00:19:33.679 +much curiosity in people. + +00:19:33.680 --> 00:19:44.519 +Thank you, janneke. + +00:19:44.520 --> 00:19:51.439 +All right, I think we are done with the Q&A session, so I'm + +00:19:51.440 --> 00:19:57.199 +going to close this BBB and we can continue with the rest of + +00:19:57.200 --> 00:19:58.719 +EmacsConf. + +00:19:58.720 --> 00:20:10.160 +You are currently the only person in this conference. -- cgit v1.2.3