diff options
Diffstat (limited to '')
| -rw-r--r-- | 2025/captions/emacsconf-2025-schemacs--one-year-progress-update-schemacs-formerly-gypsum--ramin-honary--answers.vtt | 1531 |
1 files changed, 1531 insertions, 0 deletions
diff --git a/2025/captions/emacsconf-2025-schemacs--one-year-progress-update-schemacs-formerly-gypsum--ramin-honary--answers.vtt b/2025/captions/emacsconf-2025-schemacs--one-year-progress-update-schemacs-formerly-gypsum--ramin-honary--answers.vtt new file mode 100644 index 00000000..738e9779 --- /dev/null +++ b/2025/captions/emacsconf-2025-schemacs--one-year-progress-update-schemacs-formerly-gypsum--ramin-honary--answers.vtt @@ -0,0 +1,1531 @@ +WEBVTT + +00:00:00.000 --> 00:00:03.839 +[oops, forgot to start] object protocol has a scheme implementation. + +00:00:03.840 --> 00:00:07.159 +Does this mean schemacs will be + +00:00:07.160 --> 00:00:11.079 +meta object changeable in practice? + +00:00:11.080 --> 00:00:16.599 +So I don't actually need the meta object protocol so far. + +00:00:16.600 --> 00:00:19.279 +In the reference implementation for Guile, + +00:00:19.280 --> 00:00:27.559 +Guile has its own object-oriented system called Goops. + +00:00:27.560 --> 00:00:29.239 +I'm sorry, I'm hearing a delay. + +00:00:29.240 --> 00:00:32.519 +Anyway, I'm going to turn off my stream quick. There we go. + +00:00:32.520 --> 00:00:39.439 +So, um. Yes, uh, I, I don't I wasn't aware of the, um. + +00:00:39.440 --> 00:00:43.919 +the meta-object protocol that you have mentioned here, + +00:00:43.920 --> 00:00:45.959 +but I will look into it. + +00:00:45.960 --> 00:00:48.719 +I know that there isn't really a standard + +00:00:48.720 --> 00:00:52.119 +meta-object protocol for Scheme. + +00:00:52.120 --> 00:00:53.519 +That was an issue for me + +00:00:53.520 --> 00:00:56.919 +because I'm trying to make this cross-platform, + +00:00:56.920 --> 00:00:59.639 +and so I've done all of my work so far + +00:00:59.640 --> 00:01:00.959 +without a meta-object protocol + +00:01:00.960 --> 00:01:02.439 +because that's the easiest way to make it work + +00:01:02.440 --> 00:01:04.879 +on multiple Scheme implementations. + +00:01:04.880 --> 00:01:07.359 +But if there is a nice portable one + +00:01:07.360 --> 00:01:12.559 +that works on many implementations, I would use that, yes. + +00:01:12.560 --> 00:01:14.999 +It's just that so far it hasn't been necessary. + +00:01:15.000 --> 00:01:19.279 +I've been doing mostly functional reactive programming + +00:01:19.280 --> 00:01:21.079 +and React.js-like framework. + +00:01:21.080 --> 00:01:23.239 +I've created that for the GUI front end. + +00:01:23.240 --> 00:01:26.199 +And that's all the more I've needed so far. + +00:01:26.200 --> 00:01:33.399 +So, yeah. Oh, yeah, please, next question. Sure. + +00:01:33.400 --> 00:01:39.599 +So how will the GUI display code be R7RS compliant? + +00:01:39.600 --> 00:01:45.079 +As far as I know, there's no DL open in R7RS. That's right. + +00:01:45.080 --> 00:01:48.879 +Yeah, R7RS small is extremely small + +00:01:48.880 --> 00:01:50.439 +and does not have any features at all. + +00:01:50.440 --> 00:01:54.799 +But it does provide a conv expand macro. + +00:01:54.800 --> 00:01:57.639 +And this allows you to load in different code + +00:01:57.640 --> 00:02:00.879 +depending on which scheme implementation you're using. + +00:02:00.880 --> 00:02:03.359 +So basically, I'll have to write a different back end + +00:02:03.360 --> 00:02:05.279 +for each scheme implementation. + +00:02:05.280 --> 00:02:06.639 +And I think that's really + +00:02:06.640 --> 00:02:10.919 +the only way is possible at all, + +00:02:10.920 --> 00:02:12.719 +because there's no standardization. + +00:02:12.720 --> 00:02:14.439 +So essentially, the libraries + +00:02:14.440 --> 00:02:15.719 +that I've written for schemacs + +00:02:15.720 --> 00:02:22.439 +will become kind of a platform-independent way + +00:02:22.440 --> 00:02:25.839 +of writing GUIs for Scheme. + +00:02:25.840 --> 00:02:27.119 +It's just a matter of, + +00:02:27.120 --> 00:02:28.679 +will your Scheme implementation + +00:02:28.680 --> 00:02:32.279 +support the Schemacs GUI protocol? + +00:02:32.280 --> 00:02:34.199 +So I've kind of written my own protocol, + +00:02:34.200 --> 00:02:36.679 +and it's entirely R7 RSML compliant. + +00:02:36.680 --> 00:02:38.239 +It's all done with record, + +00:02:38.240 --> 00:02:43.039 +what are they called, record types. + +00:02:43.040 --> 00:02:46.519 +Do you think some of the Schemacs + +00:02:46.520 --> 00:02:50.679 +could be extracted into SFRIs since you've made it portable + +00:02:50.680 --> 00:02:52.879 +between scheme implementations? + +00:02:52.880 --> 00:02:55.279 +Yes, I would definitely like to do that. + +00:02:55.280 --> 00:02:59.239 +Probably first thing I'll do is start splitting up + +00:02:59.240 --> 00:03:01.679 +and publishing independent libraries + +00:03:01.680 --> 00:03:04.319 +on the Aku package manager. + +00:03:04.320 --> 00:03:07.639 +This is a kind of a package manager ecosystem for Scheme, + +00:03:07.640 --> 00:03:11.679 +and in particular R7RS Scheme. + +00:03:11.680 --> 00:03:15.239 +And it's also mirrored on the other package manager, + +00:03:15.240 --> 00:03:18.279 +Snowfort, just by the way. + +00:03:18.280 --> 00:03:21.359 +But yeah, and then I might be also, + +00:03:21.360 --> 00:03:25.079 +I've considered creating a SRFI for the lens library, + +00:03:25.080 --> 00:03:27.399 +which is based on the Haskell lens library. + +00:03:27.400 --> 00:03:29.839 +I don't think that exists yet in Scheme, + +00:03:29.840 --> 00:03:34.319 +so I thought that might make a good SRFI. + +00:03:34.320 --> 00:03:36.719 +Is there a recommended Scheme implementation? + +00:03:36.720 --> 00:03:44.559 +Guile is the reference implementation. + +00:03:44.560 --> 00:03:47.279 +It's the only one that works with GUI, + +00:03:47.280 --> 00:03:51.359 +but as I demonstrated in my presentation, + +00:03:51.360 --> 00:03:52.599 +the Emacs Lisp interpreter + +00:03:52.600 --> 00:03:55.079 +works on multiple schemes so far, + +00:03:55.080 --> 00:04:00.039 +and I've had trouble with some of the scheme compilers. + +00:04:00.040 --> 00:04:04.839 +But yeah, I would recommend Guile. + +00:04:04.840 --> 00:04:07.719 +But how would schemacs deal with + +00:04:07.720 --> 00:04:10.039 +Emacs's re-display architecture + +00:04:10.040 --> 00:04:13.159 +will be having its own display architecture? + +00:04:13.160 --> 00:04:15.359 +And if so, how will you handle + +00:04:15.360 --> 00:04:18.479 +things like overlays and images? + +00:04:18.480 --> 00:04:25.239 +Yeah, definitely. That's to be determined. + +00:04:25.240 --> 00:04:31.279 +So basically, the scheme way of doing things + +00:04:31.280 --> 00:04:36.639 +So, I've created this React-like programming framework. + +00:04:36.640 --> 00:04:40.999 +It's like ReactJS or Vue.js. + +00:04:41.000 --> 00:04:45.119 +That is just the API of how you write GUI code in Scheme. + +00:04:45.120 --> 00:04:49.719 +And each Scheme implementation + +00:04:49.720 --> 00:04:52.279 +will have its own GUI backend, + +00:04:52.280 --> 00:04:55.599 +which implements that Protocol. + +00:04:55.600 --> 00:04:59.199 +And so when it comes time to link + +00:04:59.200 --> 00:05:03.079 +the Emacs Lisp built-in functions + +00:05:03.080 --> 00:05:08.279 +that do these things like overlays and so on, + +00:05:08.280 --> 00:05:11.079 +we're going to have to come up with some way + +00:05:11.080 --> 00:05:12.079 +of modeling that + +00:05:12.080 --> 00:05:15.799 +using the scheme framework that I've designed. + +00:05:15.800 --> 00:05:17.599 +And I may have to make alterations + +00:05:17.600 --> 00:05:22.039 +specifically to support Emacs Lisp. + +00:05:22.040 --> 00:05:28.559 +I don't know yet. I haven't got that far. + +00:05:28.560 --> 00:05:30.079 +You were saying that you would like + +00:05:30.080 --> 00:05:33.479 +to get the most out of the 1300 + +00:05:33.480 --> 00:05:36.519 +and something Emacs packages that exist. + +00:05:36.520 --> 00:05:38.759 +Are there technical blockers to doing them all + +00:05:38.760 --> 00:05:44.039 +or just a problem of getting enough people to jump into it? + +00:05:44.040 --> 00:05:48.639 +Yeah, it's just a matter of implementing enough + +00:05:48.640 --> 00:05:50.839 +of the Emacs built-in functions. + +00:05:50.840 --> 00:05:57.079 +Right now, there's kind of a big bug. + +00:05:57.080 --> 00:05:59.359 +I mentioned this also in the presentation. + +00:05:59.360 --> 00:06:02.599 +The stacks trace that you saw during my presentation, + +00:06:02.600 --> 00:06:05.799 +that is the biggest bug right now + +00:06:05.800 --> 00:06:08.159 +that's preventing me from running most other code. + +00:06:08.160 --> 00:06:10.359 +And I don't think other people + +00:06:10.360 --> 00:06:13.039 +will be able to contribute to the code base + +00:06:13.040 --> 00:06:14.559 +until I get that bug fixed, + +00:06:14.560 --> 00:06:18.679 +because it doesn't capture closures correctly. + +00:06:18.680 --> 00:06:22.519 +it doesn't behave like Emacs Lisp does, + +00:06:22.520 --> 00:06:26.959 +and that's the big problem. + +00:06:26.960 --> 00:06:31.759 +So once I get that worked out, + +00:06:31.760 --> 00:06:35.599 +then it's just a matter of implementing enough + +00:06:35.600 --> 00:06:37.879 +of the EmacsLisp built-in functions, + +00:06:37.880 --> 00:06:40.679 +these are the functions that are mostly implemented in C, + +00:06:40.680 --> 00:06:42.879 +implementing those in Scheme. + +00:06:42.880 --> 00:06:45.959 +And that, yeah, that's the thing + +00:06:45.960 --> 00:06:47.839 +that I'm going to need a lot of help with + +00:06:47.840 --> 00:06:49.719 +because there's quite a few of those APIs. + +00:06:49.720 --> 00:06:53.519 +But I imagine, I have no idea, no way of knowing, + +00:06:53.520 --> 00:06:56.459 +but I imagine we don't need 100% of them + +00:06:56.460 --> 00:06:58.167 +in order to run most of Elpa. + +00:06:58.168 --> 00:07:05.084 +We probably can get some of the important large Elpa packages + +00:07:05.085 --> 00:07:12.719 +like Magit and Org mode with just enough of the Emacs Lisp + +00:07:12.720 --> 00:07:14.959 +built-in functions to handle that. + +00:07:14.960 --> 00:07:19.279 +But we won't really know until we've tried. + +00:07:19.280 --> 00:07:22.519 +So yeah, I'll try to get this bug fixed right away. + +00:07:22.520 --> 00:07:24.979 +That way we can all start working on it together, hopefully. + +00:07:24.980 --> 00:07:27.126 +Highly relatable answer there. + +00:07:27.127 --> 00:07:31.959 +We'll burn that bridge when we're on it or something. + +00:07:31.960 --> 00:07:34.559 +What are your thoughts on chicken scheme? + +00:07:34.560 --> 00:07:37.199 +Will that be a good fit? Do you think? + +00:07:37.200 --> 00:07:41.039 +I think it will be, um, I, I did show + +00:07:41.040 --> 00:07:44.959 +trying to run chicken scheme in my, um, presentation + +00:07:44.960 --> 00:07:48.839 +and, uh, I ran up against some kind of issue, + +00:07:48.840 --> 00:07:51.079 +which I really don't know how to debug. + +00:07:51.080 --> 00:07:55.879 +Um, it's probably something to do with the, uh, pattern matcher. + +00:07:55.880 --> 00:07:58.919 +Um, I'm using the pattern matcher, + +00:07:58.920 --> 00:08:00.599 +uh, written by Alex shin, + +00:08:00.600 --> 00:08:02.599 +which seems to be the most portable. + +00:08:02.600 --> 00:08:05.919 +Pattern matcher, uh, for our seven RS scheme. + +00:08:05.920 --> 00:08:13.519 +But not all scheme compilers implement, what is it called? + +00:08:13.520 --> 00:08:19.559 +The macro, I can't remember what it's called. + +00:08:19.560 --> 00:08:24.199 +There's the macro expansion system for R7 RS small. + +00:08:24.200 --> 00:08:27.199 +All of these scheme implementations + +00:08:27.200 --> 00:08:29.319 +seem to have a slightly different take on how they work. + +00:08:29.320 --> 00:08:33.919 +And so that macro expander has been, for pattern matching, + +00:08:33.920 --> 00:08:35.719 +has been the biggest difficulty + +00:08:35.720 --> 00:08:37.359 +in making this code portable. + +00:08:37.360 --> 00:08:42.239 +And so I'm thinking of ways of maybe trying to ditch pattern matching, + +00:08:42.240 --> 00:08:44.999 +but that's such a useful feature and it's hard. + +00:08:45.000 --> 00:08:49.879 +So I don't know, we'll see if I can, + +00:08:49.880 --> 00:08:52.439 +if somebody can help me get it to work on chicken team, + +00:08:52.440 --> 00:08:56.599 +I'd really appreciate it. + +00:08:56.600 --> 00:09:01.799 +Can this implementation be used by Guile's Emacs Lisp mode? + +00:09:01.800 --> 00:09:08.199 +Guile's Emacs list mode. Okay. Yeah, good question. + +00:09:08.200 --> 00:09:10.919 +I did mention this last year in my presentation. + +00:09:10.920 --> 00:09:13.719 +Emacs list in Guile is totally different + +00:09:13.720 --> 00:09:16.199 +from what I've done. + +00:09:16.200 --> 00:09:21.292 +That implementation was written about 10 or 15 years ago. + +00:09:21.293 --> 00:09:26.501 +I can't remember exactly when. It is quite incomplete. + +00:09:26.502 --> 00:09:36.542 +I don't think it even runs most of the macro expanding code. + +00:09:36.543 --> 00:09:39.679 +Some of the code that is written + +00:09:39.680 --> 00:09:42.479 +for GNU Emacs in Emacs Lisp, + +00:09:42.480 --> 00:09:45.679 +where GNU Emacs is initializing itself, + +00:09:45.680 --> 00:09:51.319 +it can't even get the first file in that code. + +00:09:51.320 --> 00:09:53.479 +It hasn't been touched in 10 or 15 years. + +00:09:53.480 --> 00:09:57.239 +Initially, when I first started this project, + +00:09:57.240 --> 00:09:59.159 +I was using the parser + +00:09:59.160 --> 00:10:02.319 +for Guile's Emacs Lisp implementation, + +00:10:02.320 --> 00:10:05.319 +but it didn't give me things like source locations, + +00:10:05.320 --> 00:10:10.639 +so I had to rewrite that. And also, it wasn't portable. + +00:10:10.640 --> 00:10:14.279 +So yeah, because I want it to be portable, + +00:10:14.280 --> 00:10:16.919 +it's necessarily going to be not reliant + +00:10:16.920 --> 00:10:19.119 +on anything that's inside of the Guile library, + +00:10:19.120 --> 00:10:21.479 +including the Emacs LISP interpreter that's there. + +00:10:21.480 --> 00:10:24.959 +Maybe I could replace the Emacs LISP interpreter in Guile + +00:10:24.960 --> 00:10:29.599 +if Andy Wingo would be interested. All right. + +00:10:29.600 --> 00:10:31.599 +And I see we've got a few people + +00:10:31.600 --> 00:10:34.039 +that did jump into the BBB. + +00:10:34.040 --> 00:10:37.159 +I'm just going to quickly, oops. + +00:10:37.160 --> 00:10:40.679 +quickly try to make my text a little bigger + +00:10:40.680 --> 00:10:42.799 +so I can read a question that came here. + +00:10:42.800 --> 00:10:48.479 +I wonder if we can do some sort of pragmatic analysis + +00:10:48.480 --> 00:10:49.959 +on popular Emacs packages + +00:10:49.960 --> 00:10:52.399 +to see what list of functions they tend to depend on + +00:10:52.400 --> 00:10:54.799 +while a function calls down to the lower level. + +00:10:54.800 --> 00:10:57.209 +Yeah, that would be good. + +00:10:57.210 --> 00:11:02.251 +Somebody please do that for me. Awesome. + +00:11:02.252 --> 00:11:05.439 +Somebody's raising their hand. Divya. + +00:11:05.440 --> 00:11:08.799 +Let's see. Yeah, can you hear me? + +00:11:08.800 --> 00:11:12.359 +Yes, I can. Yeah, go ahead. Hello, thank you. + +00:11:12.360 --> 00:11:14.079 +Yeah, this is really awesome. + +00:11:14.080 --> 00:11:16.959 +I use Guile, and I love Guile, + +00:11:16.960 --> 00:11:18.919 +and I also love functional programming, + +00:11:18.920 --> 00:11:21.599 +so this is really nice that you took + +00:11:21.600 --> 00:11:22.719 +the declarative approach. + +00:11:22.720 --> 00:11:26.319 +One thing that I'm interested in is, + +00:11:26.320 --> 00:11:29.839 +are you also considering Racket in the scheme group? + +00:11:29.840 --> 00:11:32.959 +Because I know a lot of people do not consider Racket + +00:11:32.960 --> 00:11:36.639 +as a sort of scheme thing, because it grew out of it. + +00:11:36.640 --> 00:11:39.519 +Do you think you'll take something from Racket? + +00:11:39.520 --> 00:11:42.119 +Because I think Racket has + +00:11:42.120 --> 00:11:44.519 +a lot of good ideas that can be used. + +00:11:44.520 --> 00:11:48.439 +Yeah, I briefly looked at Racket's GUI library, + +00:11:48.440 --> 00:11:51.879 +but it's very, very heavily dependent + +00:11:51.880 --> 00:11:53.839 +on Racket's macro expander, + +00:11:53.840 --> 00:11:57.679 +which is, well, yeah, the macro expander + +00:11:57.680 --> 00:11:59.679 +is extremely complex for Racket, + +00:11:59.680 --> 00:12:02.159 +and I don't think it's possible to port it to any other scheme, + +00:12:02.160 --> 00:12:07.679 +as far as I know. But Racket is based on SheaScheme. + +00:12:07.680 --> 00:12:14.479 +And I am making an effort to port my code to Shea's scheme. + +00:12:14.480 --> 00:12:18.639 +I mentioned this earlier, + +00:12:18.640 --> 00:12:22.159 +but there's the Gwen Weinholdt Aku system, + +00:12:22.160 --> 00:12:25.439 +which allows you to translate R7RS to R6RS. + +00:12:25.440 --> 00:12:28.519 +And since Shea is an R6RS compiler, + +00:12:28.520 --> 00:12:33.919 +I did at one point get the Emacs Lisp interpreter + +00:12:33.920 --> 00:12:34.919 +to compile for Shea, + +00:12:34.920 --> 00:12:38.239 +although I think There's been a change + +00:12:38.240 --> 00:12:40.479 +either to Aku or somewhere in my own code base. + +00:12:40.480 --> 00:12:42.879 +It doesn't build anymore, and I'm not sure why. + +00:12:42.880 --> 00:12:47.039 +But I would also very much like to run this on Che. + +00:12:47.040 --> 00:12:54.679 +And I guess in that sense, we'll be able to work on Racket as well. + +00:12:54.680 --> 00:12:56.199 +There's also one other option. + +00:12:56.200 --> 00:13:03.519 +Alexis King has written an R7RS language package for Racket. + +00:13:03.520 --> 00:13:05.039 +I have not yet tried. + +00:13:05.040 --> 00:13:08.479 +running my package on R7RS for Racket. + +00:13:08.480 --> 00:13:11.599 +But that would be something interesting. + +00:13:11.600 --> 00:13:12.919 +Yes, I would like to try that. + +00:13:12.920 --> 00:13:13.919 +Yeah, it'll be interesting. + +00:13:13.920 --> 00:13:15.839 +I do have some experience with chairs. + +00:13:15.840 --> 00:13:17.479 +So, uh, if I can find some time, + +00:13:17.480 --> 00:13:21.239 +I'll, I'll, I'll certainly like to, I would appreciate. + +00:13:21.240 --> 00:13:24.039 +Yes. Yeah. Go ahead. Yeah. + +00:13:24.040 --> 00:13:26.079 +Another question I have is, like, + +00:13:26.080 --> 00:13:29.199 +what exactly is sort of, like, the, the approach is that + +00:13:29.200 --> 00:13:31.479 +you'll 1st want to do the interpreter + +00:13:31.480 --> 00:13:33.799 +and then have enough list functions. + +00:13:33.800 --> 00:13:36.479 +Uh, getting the max list functions + +00:13:36.480 --> 00:13:38.119 +interpreted or interpretable. + +00:13:38.120 --> 00:13:40.999 +And then go for GUI or do you want + +00:13:41.000 --> 00:13:42.759 +to sort of like go hand in hand + +00:13:42.760 --> 00:13:45.679 +is like we have the interpreter working on + +00:13:45.680 --> 00:13:46.959 +and we have also the GUI + +00:13:46.960 --> 00:13:53.199 +and we sort of use one for the other. + +00:13:53.200 --> 00:13:56.479 +Yeah, I consider the two tasks to be parallel. + +00:13:56.480 --> 00:13:59.639 +So I'm actually doing the GUI separately. + +00:13:59.640 --> 00:14:05.519 +The reason why is because the GUI for Schemacs + +00:14:05.520 --> 00:14:10.279 +is really just a clone of the look and feel of Emacs. + +00:14:10.280 --> 00:14:14.679 +It's not like an actual clone of the low-level C code + +00:14:14.680 --> 00:14:16.039 +that puts everything on screen. + +00:14:16.040 --> 00:14:18.679 +And I'm actually not really that interested + +00:14:18.680 --> 00:14:21.439 +in the low-level details + +00:14:21.440 --> 00:14:23.479 +of how Emacs draws things on screen either. + +00:14:23.480 --> 00:14:26.839 +I think it has a lot of historical baggage, + +00:14:26.840 --> 00:14:28.839 +and I'm actually trying to move away from that. + +00:14:28.840 --> 00:14:31.759 +So that was part of the reason why I started + +00:14:31.760 --> 00:14:36.399 +with this React.js or Vue.js-like Reactive GUI framework. + +00:14:36.400 --> 00:14:39.519 +So that GUI part is completely separate. + +00:14:39.520 --> 00:14:42.239 +And I want to worry about the details + +00:14:42.240 --> 00:14:46.719 +of how we make the GUI look and feel + +00:14:46.720 --> 00:14:50.319 +similar in Schemacs, similar to GNU Emacs. + +00:14:50.320 --> 00:14:54.799 +In Schemacs, using the Emacs programming language, + +00:14:54.800 --> 00:14:59.319 +I think that's something that we should worried about + +00:14:59.320 --> 00:15:03.399 +after we have enough of the Emacs list implemented. + +00:15:03.400 --> 00:15:04.919 +Yeah, that makes sense. + +00:15:04.920 --> 00:15:06.679 +There are sort of, I'm a bit worried. + +00:15:06.680 --> 00:15:10.599 +So, I don't know if, so one of my presentations + +00:15:10.600 --> 00:15:11.479 +is going to be tomorrow. + +00:15:11.480 --> 00:15:13.119 +I'm working on something called Emacs Viewer. + +00:15:13.120 --> 00:15:15.319 +It's a document viewer in Emacs. + +00:15:15.320 --> 00:15:17.679 +And essentially one of the issues that I'm up against + +00:15:17.680 --> 00:15:20.359 +is that Emacs's display system + +00:15:20.360 --> 00:15:25.439 +is sort of very let's say, not flexible. + +00:15:25.440 --> 00:15:31.839 +When trying to analyze where this inflexibility comes from, + +00:15:31.840 --> 00:15:35.759 +I don't think it's just the display architecture. + +00:15:35.760 --> 00:15:38.319 +I think parts of eLISP itself + +00:15:38.320 --> 00:15:43.599 +are connected to the display architecture. + +00:15:43.600 --> 00:15:48.399 +The notion of a cell in a buffer, + +00:15:48.400 --> 00:15:52.199 +itself is connected tightly to + +00:15:52.200 --> 00:15:54.519 +how the re-display architecture works. + +00:15:54.520 --> 00:15:57.199 +So I think you'll have to sort of figure out + +00:15:57.200 --> 00:16:00.679 +what exactly you can salvage from ELISP + +00:16:00.680 --> 00:16:05.199 +without taking the display architecture baggage. + +00:16:05.200 --> 00:16:08.001 +That's right. I do anticipate + +00:16:08.002 --> 00:16:09.876 +that's going to be fairly challenging. + +00:16:09.877 --> 00:16:14.584 +It's all Turing-complete, + +00:16:14.585 --> 00:16:17.879 +so I imagine we're probably going to end up + +00:16:17.880 --> 00:16:21.039 +creating something like an emulator + +00:16:21.040 --> 00:16:24.319 +for the Emacs Lisp display architecture in Scheme + +00:16:24.320 --> 00:16:27.559 +that will somehow translate down + +00:16:27.560 --> 00:16:30.039 +to the React-like protocol that I've written. + +00:16:30.040 --> 00:16:32.719 +But yeah, I don't I haven't that's nice. + +00:16:32.720 --> 00:16:36.319 +No, this is this is very exciting. Yeah. Oh Yes, it is. + +00:16:36.320 --> 00:16:39.559 +Yeah, I'm glad so like a lot of people have told me + +00:16:39.560 --> 00:16:41.679 +that they really Are excited to see this project + +00:16:41.680 --> 00:16:42.719 +and this really helps me + +00:16:42.720 --> 00:16:46.399 +You know keep focused on this project + +00:16:46.400 --> 00:16:48.319 +because a lot of people are very interested. + +00:16:48.320 --> 00:16:50.359 +So It's so I'd like to move on + +00:16:50.360 --> 00:16:52.159 +to a couple of questions from the past. + +00:16:52.160 --> 00:16:54.479 +We're starting to build up a good backlog. + +00:16:54.480 --> 00:16:59.719 +Thank you for that. Yeah Next question from the pad I have. + +00:16:59.720 --> 00:17:02.239 +Can you tell us more about the show stopping bug? + +00:17:02.240 --> 00:17:04.159 +How to squash it? How can people help? + +00:17:04.160 --> 00:17:08.799 +OK, well, that one, unfortunately, I think, + +00:17:08.800 --> 00:17:11.679 +unless you're really a scheme genius + +00:17:11.680 --> 00:17:13.799 +and you can really read my code + +00:17:13.800 --> 00:17:15.479 +and immediately understand how it all works, + +00:17:15.480 --> 00:17:18.319 +I don't think you'd be able to help. + +00:17:18.320 --> 00:17:22.599 +It shouldn't be too difficult for me to fix. + +00:17:22.600 --> 00:17:26.639 +So it has to do with how closures work. + +00:17:26.640 --> 00:17:30.719 +And a closure is basically an object + +00:17:30.720 --> 00:17:33.159 +that can be created with stuff that's on the stack. + +00:17:33.160 --> 00:17:37.079 +And this is a feature, I think, + +00:17:37.080 --> 00:17:39.679 +that was introduced with Emacs 27. + +00:17:39.680 --> 00:17:40.879 +I can't remember exactly, + +00:17:40.880 --> 00:17:43.439 +but it's actually a relatively recent feature. + +00:17:43.440 --> 00:17:45.879 +It was ever since they introduced + +00:17:45.880 --> 00:17:50.999 +lexically scoped variable bindings in Emacs Lisp. + +00:17:51.000 --> 00:17:54.519 +And so yeah, the problem is that + +00:17:54.520 --> 00:17:59.839 +when you create like a let structure + +00:17:59.840 --> 00:18:01.799 +and you could declare a variable in the let. + +00:18:01.800 --> 00:18:05.399 +And then you create inside of that a second let structure, + +00:18:05.400 --> 00:18:07.239 +and you have a lambda inside of that. + +00:18:07.240 --> 00:18:11.319 +And the lambda references or uses a variable + +00:18:11.320 --> 00:18:14.399 +that was declared in the outer let binding. + +00:18:14.400 --> 00:18:18.279 +That outer let binding is somewhere on the stack. + +00:18:18.280 --> 00:18:22.999 +And the lambda you can actually return it as a value. + +00:18:23.000 --> 00:18:25.319 +So when you do return that lambda, + +00:18:25.320 --> 00:18:27.679 +it has to have a note somewhere inside + +00:18:27.680 --> 00:18:31.279 +that says, by the way, I'm using that variable. + +00:18:31.280 --> 00:18:34.359 +So you need to capture it and restore it to the stack + +00:18:34.360 --> 00:18:38.199 +whenever this lambda is applied, whenever you execute it. + +00:18:38.200 --> 00:18:40.959 +And that is where the error is. + +00:18:40.960 --> 00:18:44.399 +It's not capturing the stack variable properly. + +00:18:44.400 --> 00:18:46.879 +And I think what I'm going to do, + +00:18:46.880 --> 00:18:49.759 +I haven't looked into it in detail yet + +00:18:49.760 --> 00:18:53.279 +because I've gone back to GUI stuff recently, + +00:18:53.280 --> 00:18:55.479 +but what I'm going to do, I think, + +00:18:55.480 --> 00:18:57.799 +is just do a static analysis + +00:18:57.800 --> 00:18:59.079 +of the code inside of the Lambda + +00:18:59.080 --> 00:19:02.919 +and see which symbols are being used, + +00:19:02.920 --> 00:19:05.079 +and then just capture all of those + +00:19:05.080 --> 00:19:07.559 +and place those into the record type + +00:19:07.560 --> 00:19:09.519 +that stores the lambda. + +00:19:09.520 --> 00:19:12.679 +That's how I'm going to fix that, I think. + +00:19:12.680 --> 00:19:15.999 +I hope anyway that's going to work. + +00:19:16.000 --> 00:19:17.239 +You never know with bugs. + +00:19:17.240 --> 00:19:21.759 +They're always a little bit tricky. Okay, next question. + +00:19:21.760 --> 00:19:23.119 +Are there performance concerns + +00:19:23.120 --> 00:19:28.479 +with implementing certain C primitives in PeerScheme? + +00:19:28.480 --> 00:19:32.879 +So who is it? The famous computer scientist that said + +00:19:32.880 --> 00:19:35.879 +premature optimization is the root of all evil. + +00:19:35.880 --> 00:19:39.799 +I think it was the guy who invented the A star algorithm. + +00:19:39.800 --> 00:19:42.719 +His name escapes me at the minute. + +00:19:42.720 --> 00:19:49.359 +But yeah, I'm not concerned about performance yet, + +00:19:49.360 --> 00:19:52.119 +although most of the scheme compilers that I have seen, + +00:19:52.120 --> 00:19:56.999 +especially Shea and Gambit + +00:19:57.000 --> 00:20:02.039 +have extremely good performance characteristics. + +00:20:02.040 --> 00:20:03.679 +And so I think there won't be + +00:20:03.680 --> 00:20:05.879 +too much difficulty with performance, + +00:20:05.880 --> 00:20:08.759 +even implementing some of the C stuff. + +00:20:08.760 --> 00:20:10.759 +And besides, a lot of the GUI stuff + +00:20:10.760 --> 00:20:12.719 +is already written in C anyway. + +00:20:12.720 --> 00:20:14.399 +I mean, it would be cool + +00:20:14.400 --> 00:20:16.879 +if we had a scheme GUI library + +00:20:16.880 --> 00:20:18.599 +that painted to a canvas, + +00:20:18.600 --> 00:20:21.639 +maybe for a Wayland implementation or something. + +00:20:21.640 --> 00:20:29.079 +But I don't know. It's not a concern for me, performance. + +00:20:29.080 --> 00:20:32.079 +Okay, there are a few more questions. I do want to mention + +00:20:32.080 --> 00:20:33.839 +that the stream has cut away at this point, + +00:20:33.840 --> 00:20:36.279 +but we're still recording live. + +00:20:36.280 --> 00:20:38.799 +All of this will be put up on the website + +00:20:38.800 --> 00:20:40.399 +and so on like that. + +00:20:40.400 --> 00:20:44.199 +So, I appreciate all the enthusiastic questions + +00:20:44.200 --> 00:20:47.799 +and you're kind of tanking through them all. + +00:20:47.800 --> 00:20:52.799 +Me too. I love how many questions I'm getting. + +00:20:52.800 --> 00:20:54.039 +This is very encouraging + +00:20:54.040 --> 00:20:55.999 +and it really makes me want to keep on working on it. + +00:20:56.000 --> 00:20:56.879 +So it's great. + +00:20:56.880 --> 00:21:00.199 +I'm so glad to hear that because that's exactly the message + +00:21:00.200 --> 00:21:01.439 +I think you should be receiving. + +00:21:01.440 --> 00:21:04.159 +This is a fantastic project. Thank you so much. + +00:21:04.160 --> 00:21:08.439 +I'll just say so myself. If the project is successful, + +00:21:08.440 --> 00:21:11.479 +are you worried about a possible split in the community + +00:21:11.480 --> 00:21:15.599 +between Schemacs and GNU Emacs? + +00:21:15.600 --> 00:21:18.959 +Oh, I have thought about that. + +00:21:18.960 --> 00:21:24.039 +And I really don't know what's going to happen. + +00:21:24.040 --> 00:21:26.239 +There seems to be already a huge demand + +00:21:26.240 --> 00:21:30.439 +for a scheme-based, a modern scheme-based editor. + +00:21:30.440 --> 00:21:33.399 +You know, the Edwin scheme for MIT scheme + +00:21:33.400 --> 00:21:37.279 +hasn't been touched since like 1987 or something, + +00:21:37.280 --> 00:21:41.439 +maybe 1993 or, but anyway. + +00:21:41.440 --> 00:21:43.159 +There seems to be huge demand. + +00:21:43.160 --> 00:21:45.119 +And so I guess a lot of people + +00:21:45.120 --> 00:21:47.679 +who are currently using GNU Emacs + +00:21:47.680 --> 00:21:49.079 +will probably just switch over + +00:21:49.080 --> 00:21:50.479 +because they've been wanting + +00:21:50.480 --> 00:21:53.159 +something like this for a very long time. + +00:21:53.160 --> 00:21:56.559 +And then, I mean, is that going to cause fragmentation? + +00:21:56.560 --> 00:21:58.679 +Is it really a big deal, though? + +00:21:58.680 --> 00:22:02.479 +I mean, it's all GPL-licensed code. + +00:22:02.480 --> 00:22:08.759 +I mean, I think a rising tide raises all the ships at the same time. + +00:22:08.760 --> 00:22:13.279 +So, yeah, also, the last thing I want to say about that + +00:22:13.280 --> 00:22:18.999 +is I would like to contribute some of what I do in Schemacs + +00:22:19.000 --> 00:22:24.399 +back into GNU Emacs, if I can. So, for example, I'm going + +00:22:24.400 --> 00:22:25.959 +to be working on like a canvas library + +00:22:25.960 --> 00:22:27.879 +where you can have interactive canvases + +00:22:27.880 --> 00:22:30.879 +and you know you can actually like draw pictures + +00:22:30.880 --> 00:22:33.559 +and put things with the mouse and drag things around. + +00:22:33.560 --> 00:22:36.079 +And I was thinking you know + +00:22:36.080 --> 00:22:37.667 +if if I can figure out how that works + +00:22:37.668 --> 00:22:41.917 +maybe I can write something like that for Emacs + +00:22:41.918 --> 00:22:47.759 +or GNU Emacs using the Cairo library, you know, + +00:22:47.760 --> 00:22:49.319 +SVG rendering library that they have. + +00:22:49.320 --> 00:22:51.319 +So, you know, if I have time, + +00:22:51.320 --> 00:22:55.799 +I would like to continue contributing to GNU Emacs as well. + +00:22:55.800 --> 00:22:57.839 +I'm sorry, what was the name of the library you mentioned? + +00:22:57.840 --> 00:23:01.039 +Oh, Cairo, like Cairo. + +00:23:01.040 --> 00:23:07.599 +Oh, Cairo, yeah. Absolutely. I spelled that poorly. + +00:23:07.600 --> 00:23:12.519 +The dream of never needing to change to the web browser. + +00:23:12.520 --> 00:23:18.376 +Would schemacs bring us closer to that? I hope so. + +00:23:18.377 --> 00:23:21.709 +That's also a dream of mine. + +00:23:21.710 --> 00:23:26.479 +The part of the reason why I wanted to work, you know, + +00:23:26.480 --> 00:23:30.999 +make sure I had a really good workable GUI framework + +00:23:31.000 --> 00:23:32.626 +is so that I could, you know, + +00:23:32.627 --> 00:23:34.879 +we could write apps like, you know, + +00:23:34.880 --> 00:23:38.759 +they have a mastodon client written in Emacs Lisp. + +00:23:38.760 --> 00:23:42.199 +that would be so nice to have this, you know, + +00:23:42.200 --> 00:23:43.439 +a really nice Mastodon client + +00:23:43.440 --> 00:23:47.479 +that was right inside of, you know, our scheme environment + +00:23:47.480 --> 00:23:50.039 +where we were doing our text editing and other stuff. + +00:23:50.040 --> 00:23:52.079 +I've always wanted something like that, + +00:23:52.080 --> 00:23:53.799 +or it would be cool to have + +00:23:53.800 --> 00:23:56.319 +just a slightly nicer GUI for Magit. + +00:23:56.320 --> 00:24:04.199 +So, yeah, I mean, like, yeah, being able to avoid the web entirely + +00:24:04.200 --> 00:24:08.199 +and just be able to like, you know, do social networking + +00:24:08.200 --> 00:24:11.439 +and do your GitHub stuff, + +00:24:11.440 --> 00:24:14.759 +everything from within Emacs or Schemacs in this case, + +00:24:14.760 --> 00:24:16.919 +that's a dream of mine as well. + +00:24:16.920 --> 00:24:20.079 +And so I hope that that's where we end up in a couple of years. + +00:24:20.080 --> 00:24:29.999 +The sooner the better. Anything, just double checking. + +00:24:30.000 --> 00:24:33.319 +Anything specific other than minimalism + +00:24:33.320 --> 00:24:35.799 +that made you choose Scheme over Commonwealth? + +00:24:35.800 --> 00:24:40.199 +Oh, yeah, it's kind of a philosophical question. + +00:24:40.200 --> 00:24:45.559 +So a couple of things. First of all, it was a conversation + +00:24:45.560 --> 00:24:47.399 +I had with William Byrd, + +00:24:47.400 --> 00:24:50.519 +and he's a guy who makes the Mini Conran framework for Scheme. + +00:24:50.520 --> 00:24:52.879 +It was his PhD thesis. + +00:24:52.880 --> 00:24:57.119 +He worked with, I'm sorry, I just can't remember his name. + +00:24:57.120 --> 00:24:59.679 +He worked at the University of Indiana. + +00:24:59.680 --> 00:25:03.839 +Another famous Scheme or Lisp person was there. + +00:25:03.840 --> 00:25:06.279 +Friedman, Dan Friedman was his advisor. + +00:25:06.280 --> 00:25:09.159 +Yeah, big name in Lisp. + +00:25:09.160 --> 00:25:12.839 +Anyway, so I was talking with William Byrd, + +00:25:12.840 --> 00:25:14.639 +and I'm a huge Haskell fan, + +00:25:14.640 --> 00:25:16.919 +and he told me why he didn't like Haskell at all, + +00:25:16.920 --> 00:25:19.639 +and kind of convinced me to try Scheme out. + +00:25:19.640 --> 00:25:22.759 +And what I really like about Scheme is, + +00:25:22.760 --> 00:25:25.399 +yeah, like you said, the minimalism, + +00:25:25.400 --> 00:25:29.839 +but it's more that it is very close + +00:25:29.840 --> 00:25:34.879 +to the mathematical framework of lambda calculus. + +00:25:34.880 --> 00:25:38.519 +Haskell is probably the most pure + +00:25:38.520 --> 00:25:39.919 +lambda calculus that I've ever used, + +00:25:39.920 --> 00:25:45.519 +but Scheme is like the simply typed lambda calculus, + +00:25:45.520 --> 00:25:47.799 +and That just appeals to me. + +00:25:47.800 --> 00:25:50.839 +I think, you know, if you have this tiny, tiny core language + +00:25:50.840 --> 00:25:55.599 +from which all of the computing can be defined, + +00:25:55.600 --> 00:25:57.119 +I think it's kind of a shame + +00:25:57.120 --> 00:26:00.079 +that so far we just haven't explored that space yet. + +00:26:00.080 --> 00:26:03.639 +I mean, there's compared to JavaScript or Python, + +00:26:03.640 --> 00:26:05.879 +there's very little scheme code out there + +00:26:05.880 --> 00:26:08.239 +and it could be doing so much. And I would just like to try + +00:26:08.240 --> 00:26:10.159 +and expand the scheme ecosystem + +00:26:10.160 --> 00:26:12.999 +and see just what this tiny little language can do. + +00:26:13.000 --> 00:26:14.479 +And I think we haven't even seen + +00:26:14.480 --> 00:26:16.839 +a fraction of what it can do. + +00:26:16.840 --> 00:26:22.399 +That's why I've chosen scheme. + +00:26:22.400 --> 00:26:24.719 +Divya, I see you've got a bunch more comments. + +00:26:24.720 --> 00:26:26.679 +I think we're just about close to our time here, + +00:26:26.680 --> 00:26:28.279 +but if you wanted to jump back in, + +00:26:28.280 --> 00:26:30.519 +I'm sorry, I had to cut you off a little before. + +00:26:30.520 --> 00:26:33.959 +No, it's fine. No, it's fine. + +00:26:33.960 --> 00:26:36.599 +I think I agree with most of what he said. + +00:26:36.600 --> 00:26:40.679 +So, yeah, thank you so much. + +00:26:40.680 --> 00:26:45.159 +Um, closing thoughts, Ramin. + +00:26:45.160 --> 00:26:51.639 +Yeah, I guess everybody, please, if you're interested, + +00:26:51.640 --> 00:26:56.719 +keep watching my Mastodon and keep watching my Codeberg. + +00:26:56.720 --> 00:27:01.559 +I'm going to try and squash this bug as quickly as I can. + +00:27:01.560 --> 00:27:03.279 +I hope early next year, + +00:27:03.280 --> 00:27:07.519 +hopefully not much later than February, + +00:27:07.520 --> 00:27:12.039 +I'll actually be able to start taking in contributions + +00:27:12.040 --> 00:27:16.719 +for some of the Emacs Lisp built-ins in the code base. + +00:27:16.720 --> 00:27:21.959 +So, please keep watching. The pace of my development + +00:27:21.960 --> 00:27:24.279 +has increased pretty rapidly recently, + +00:27:24.280 --> 00:27:25.839 +and I think we're pretty close + +00:27:25.840 --> 00:27:29.119 +to getting something that we can all use together. + +00:27:29.120 --> 00:27:31.719 +Thank you once again for your amazing talk, + +00:27:31.720 --> 00:27:34.039 +for your exceptional work, + +00:27:34.040 --> 00:27:36.599 +and for jumping in, doing the live Q&A, + +00:27:36.600 --> 00:27:40.039 +rolling with us here as we have yet another + +00:27:40.040 --> 00:27:42.079 +We'll See How It Goes conference. + +00:27:42.080 --> 00:27:44.279 +It's been just amazing so far, + +00:27:44.280 --> 00:27:46.839 +and this talk is no small part of that. Thank you. + +00:27:46.840 --> 00:27:50.279 +Oh, thank you so much. Yeah. OK, cool. + +00:27:50.280 --> 00:27:51.834 +And thanks for all the questions, everyone. |