1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
|
WEBVTT
00:00:00.000 --> 00:00:02.999
...Troy Hinckley's project that I'm talking about. I was going
00:00:03.000 --> 00:00:08.799
to mention this in my presentation, but it's possible,
00:00:08.800 --> 00:00:16.359
theoretically, that Troy Hinckley, his project could be
00:00:16.360 --> 00:00:18.559
used as a scheme of limitation that actually runs my own
00:00:18.560 --> 00:00:23.759
version of Emacs. And although, you know, This is
00:00:23.760 --> 00:00:30.719
completely theoretical, and I don't know how difficult
00:00:30.720 --> 00:00:34.079
that would be. But if Troy Hinckley implemented enough of
00:00:34.080 --> 00:00:39.879
the R7-RS standard in Rust, it would theoretically be
00:00:39.880 --> 00:00:46.719
possible to run the Gypsum editor in Troy Hinckley's own
00:00:46.720 --> 00:00:50.239
editor. I thought that was kind of interesting, and I
00:00:50.240 --> 00:00:59.119
thought it was worth mentioning, at least in the questions
00:00:59.120 --> 00:01:12.159
and answers.
00:01:12.160 --> 00:01:16.199
I also mentioned this in the presentation. I wanted to see
00:01:16.200 --> 00:01:20.119
Robin Templeton's project presentation, but
00:01:20.120 --> 00:01:22.399
unfortunately it's going to be at like four in the morning
00:01:22.400 --> 00:01:26.239
for me. So I'm going to try and watch that tomorrow, but
00:01:26.240 --> 00:01:29.559
that's also going to be a very interesting project to keep an
00:01:29.560 --> 00:01:34.039
eye on if you're interested in Scheme. That's the project
00:01:34.040 --> 00:01:37.519
where you've got the Guylain interpreter running inside of
00:01:37.520 --> 00:02:04.679
the Emacs process. It's dynamically linked as a library.
00:02:04.680 --> 00:02:08.759
I'm ready for questions from anybody. You can ask or you can
00:02:08.760 --> 00:02:32.079
type. It's up to you.
00:02:32.080 --> 00:02:37.319
Okay, let me check the etherpad.
00:02:37.320 --> 00:02:41.159
Let's see here.
00:02:41.160 --> 00:02:42.719
I'm not sure if I'm doing that right.
00:02:42.720 --> 00:02:54.199
Let me check one more time. Oh, there it goes.
00:02:54.200 --> 00:03:00.079
Let's see, so this is...
00:03:00.080 --> 00:03:02.239
I didn't know about that first bit of history. Oh, I've heard
00:03:02.240 --> 00:03:06.119
RMS say that Scheme Guile is just a nicer Lisp, but I didn't
00:03:06.120 --> 00:03:09.079
know there were concrete talks attempts to use Guile for
00:03:09.080 --> 00:03:14.319
Emacs that early. Let's see, that was from janneke.
NOTE Q: I'm curious to know how the hell guile-emacs deals with all of the dynamically scoped modules out there. Is there any effort to automatically modularize and namespace stuff?
00:03:14.320 --> 00:03:17.439
I'm curious to know how the hell Guile Emacs deals with all the
00:03:17.440 --> 00:03:21.359
dynamically scoped modules out there. Is there any effort
00:03:21.360 --> 00:03:29.759
to automatically modularize and name? Let's see.
00:03:29.760 --> 00:03:40.919
That might be a better question for Robin Templeton. In my
00:03:40.920 --> 00:03:44.639
own project,
00:03:44.640 --> 00:03:49.399
there's no module system for Emacs Lisp. There is a module
00:03:49.400 --> 00:03:55.559
system for Scheme. And the Emacs Lisp interpreter runs in
00:03:55.560 --> 00:04:01.599
its own environment. the require system or whatever module
00:04:01.600 --> 00:04:06.359
system that Emacs has, once it's implemented, all of that
00:04:06.360 --> 00:04:09.759
would just happen inside of the Emacs Lisp environment,
00:04:09.760 --> 00:04:12.399
which is inside of the Scheme environment. And
00:04:12.400 --> 00:04:21.479
environments are objects in Scheme.
00:04:21.480 --> 00:04:26.399
I think a more difficult question is how to handle
00:04:26.400 --> 00:04:33.279
threading, and Scheme has very good threading built in, in
00:04:33.280 --> 00:04:34.839
Serphe-18[??].
00:04:34.840 --> 00:04:43.399
But I don't think it will be easy to write Emacs Lisp form
00:04:43.400 --> 00:04:48.479
bindings to the Scheme multi-threading implementation.
00:04:48.480 --> 00:04:52.279
Emacs Lisp was just not cut out for that kind of thing. So I
00:04:52.280 --> 00:04:56.559
think each Emacs Lisp, you could, I suppose, have multiple
00:04:56.560 --> 00:05:00.039
threads each running their own Emacs Lisp environment.
00:05:00.040 --> 00:05:04.999
Scheme would make that very simple to do.
00:05:05.000 --> 00:05:08.759
And then there'd just be a question of how you would get those
00:05:08.760 --> 00:05:11.679
different interpreters to communicate with each other,
00:05:11.680 --> 00:05:16.279
perhaps using the same protocol that's used by the Emacs
00:05:16.280 --> 00:05:23.639
server. But I haven't thought that far ahead yet.
NOTE Q: Would it be possible to support a GUI toolkit other than GTK?
00:05:23.640 --> 00:05:26.839
Would it be possible to support a GUI toolkit other than the
00:05:26.840 --> 00:05:31.319
GTK? Like, how is it still supports Lucid? Yes, this is
00:05:31.320 --> 00:05:36.999
absolutely a goal of the project. I'm trying to keep the back
00:05:37.000 --> 00:05:41.599
end separate as possible. The scheme has what you call
00:05:41.600 --> 00:05:45.239
parameters. And these are like global variables that are
00:05:45.240 --> 00:05:50.519
still somewhat thread safe. And every call to the GUI goes
00:05:50.520 --> 00:05:58.199
through a parameter. So the Emacs, the interpreter and the
00:05:58.200 --> 00:06:01.679
editor logic is all in one module. And then that module calls
00:06:01.680 --> 00:06:06.319
out into a separate GUI module. And then you can implement
00:06:06.320 --> 00:06:11.599
different GUI modules. So you could have one for GTK3, one
00:06:11.600 --> 00:06:16.879
for GTK4, if you want to write the extern C bindings around Qt
00:06:16.880 --> 00:06:21.199
or full tick, that would certainly be possible as well. It
00:06:21.200 --> 00:06:25.919
would be nice maybe to have an SDL implementation based
00:06:25.920 --> 00:06:30.999
maybe on Chikiti or some kind of immediate mode GUI,
00:06:31.000 --> 00:06:37.399
something like that. But definitely GTK3 through Guile GI
00:06:37.400 --> 00:06:41.319
is the reference implementation. Things start there. But
00:06:41.320 --> 00:06:43.999
I'm very interested in supporting other GUIs, yes. Let's
00:06:44.000 --> 00:06:46.039
see.
NOTE Q: Do you plan to provide improvements to Elisp as a language, or is the focus on a compatibility layer to facilitate doing all new extensions, etc. in Scheme?
00:06:46.040 --> 00:06:50.759
Question, do you plan to provide improvements to ELisp
00:06:50.760 --> 00:06:54.519
as a language or focus on a compatibility layer to
00:06:54.520 --> 00:06:57.999
facilitate all new extensions in Scheme? Yeah, the second
00:06:58.000 --> 00:07:04.719
one. I want to move off to Scheme. I would like for this
00:07:04.720 --> 00:07:08.999
project to try and keep up to date with each new release of
00:07:09.000 --> 00:07:13.799
Emacs and Emacs Lisp. That's a difficult moving target to
00:07:13.800 --> 00:07:18.639
follow, I realize. But to the greatest extent possible, any
00:07:18.640 --> 00:07:25.239
new features to Emacs Lisp will be pulled in from GNU Emacs.
00:07:25.240 --> 00:07:28.599
If we happen to be able to implement something cool in
00:07:28.600 --> 00:07:31.639
Scheme, and be able to port it over to Emacs Lisp, then sure,
00:07:31.640 --> 00:07:35.799
it'd be nice to be able to upload or to submit that upstream to
00:07:35.800 --> 00:07:43.079
the GNU Emacs. But I think I would prefer to have new features
00:07:43.080 --> 00:07:47.799
written in Scheme. I would like this gypsum to be more of a
00:07:47.800 --> 00:07:51.479
Scheme app platform that just happens to be able to also run
00:07:51.480 --> 00:07:56.199
Emacs Lisp. That's how I see it. Of course, this will be a
00:07:56.200 --> 00:08:00.799
community project. I'm open to debate about that if anybody
00:08:00.800 --> 00:08:02.079
wants to convince me otherwise.
00:08:02.080 --> 00:08:11.759
Why is being able to interpret all of that EL a useful goal?
00:08:11.760 --> 00:08:15.519
Sure, there is a lot of code written in Elisp. Can we
00:08:15.520 --> 00:08:18.959
consider... Oh, it's still being written. Please go ahead
00:08:18.960 --> 00:08:19.439
and finish writing.
NOTE Q: Can we consider a translator like utility to convert elisp to scheme, once guile-emacs becomes a reality?
00:08:19.440 --> 00:08:32.519
Can we consider a translator like utility to convert eLisp
00:08:32.520 --> 00:08:37.519
to Scheme once Guile-Emacs has become a reality?
00:08:37.520 --> 00:08:42.119
Certainly. For the time being, I just wanted to get the
00:08:42.120 --> 00:08:47.559
interpreter running. So the actual, the Guile-Emacs Lisp,
00:08:47.560 --> 00:08:51.919
the one that was written in 2011 that I didn't write, that
00:08:51.920 --> 00:08:57.599
actually does compile to, I think it's the tree
00:08:57.600 --> 00:08:59.239
intermediate representation It's one of the intermediate
00:08:59.240 --> 00:09:03.759
languages that Guile uses to compile Guile scheme itself.
00:09:03.760 --> 00:09:09.079
So the Emacs lisp that was written before actually does
00:09:09.080 --> 00:09:13.119
that. It actually compiles and makes use of the entire Guile
00:09:13.120 --> 00:09:17.479
compiler tool chain and actually produces like JIT
00:09:17.480 --> 00:09:21.719
compilable binaries, which is really cool. Like I said,
00:09:21.720 --> 00:09:27.519
that's the one that I had trouble getting to work properly.
00:09:27.520 --> 00:09:34.399
Maybe we can follow that architecture. I'm not sure how to do
00:09:34.400 --> 00:09:37.919
that, but I would like to be able to do some kind of
00:09:37.920 --> 00:09:41.999
translating, keeping in mind that we want to have this be
00:09:42.000 --> 00:09:48.919
portable, do various schemes. And so Guile makes this very
00:09:48.920 --> 00:09:52.719
easy, but other schemes don't. Gambit might do this pretty
00:09:52.720 --> 00:09:57.919
well as well. It compiles to C and then compiles C down to a
00:09:57.920 --> 00:10:06.159
dynamically linkable library. So yeah, I think probably
00:10:06.160 --> 00:10:09.559
the most portable, I'm just thinking out loud right now,
00:10:09.560 --> 00:10:13.239
most portable implementation will just be able to
00:10:13.240 --> 00:10:17.119
translate Emacs Lisp directly to Scheme, which is not what
00:10:17.120 --> 00:10:22.439
the old Guile Emacs Lisp implementation does. That goes to
00:10:22.440 --> 00:10:26.439
TreeIL, so it's very, very Guile-specific, can't be
00:10:26.440 --> 00:10:30.799
ported. But yeah, if we could somehow get Emacs Lisp
00:10:30.800 --> 00:10:36.999
translated to Scheme and then compiled, say, in Shea Scheme
00:10:37.000 --> 00:10:40.879
or Gambit or MIT Scheme or one of those other compilers, that
00:10:40.880 --> 00:10:44.919
would be very cool. And I would absolutely love to do that.
00:10:44.920 --> 00:10:49.279
And I would very quickly accept any code into the code base
00:10:49.280 --> 00:10:50.599
that would do that.
NOTE Q: Why is being able to interpret all of \`init.el\` an useful goal?
00:10:50.600 --> 00:10:59.119
Oh, and to answer the question about init.el,
00:10:59.120 --> 00:11:02.839
It's just because people spend a lot of time on their configs
00:11:02.840 --> 00:11:06.959
and it would be nice if, you know, you're starting to use this
00:11:06.960 --> 00:11:14.079
new editor and want it to be similar to Emacs users, just the
00:11:14.080 --> 00:11:16.519
Emacs community in general and people who are familiar with
00:11:16.520 --> 00:11:20.879
using Emacs. It would be more useful to everybody in the
00:11:20.880 --> 00:11:25.119
Emacs community if this were more compatible with GNU
00:11:25.120 --> 00:11:35.999
Emacs. And so that's why that's, I think that's an important
00:11:36.000 --> 00:11:38.559
goal.
00:11:38.560 --> 00:12:01.839
Question is not yet. Great. Oh, here comes another
00:12:01.840 --> 00:12:02.279
question.
NOTE Q: What is the plan to handle elisp packages that depend on 3rd party/external libraries? (libgit/magit or rg/ripgrep)?
00:12:02.280 --> 00:12:11.879
Okay, what is the plan to handle elisp packages that depend
00:12:11.880 --> 00:12:16.119
on third-party or external libraries like git or magit
00:12:16.120 --> 00:12:22.719
or ripgrep? So that's going to be tricky. It depends on how
00:12:22.720 --> 00:12:27.079
these external packages are linked into emacs. If it's
00:12:27.080 --> 00:12:32.879
going to be a dynamic library like Robin Templeton's
00:12:32.880 --> 00:12:38.039
project which you load the libgit library into the Emacs
00:12:38.040 --> 00:12:43.159
process, that is going to be extremely difficult. So if you
00:12:43.160 --> 00:12:49.359
have an external library like, I don't know, libgit or
00:12:49.360 --> 00:12:59.279
what's the GUI thing? Cabal. No, not Cabal. Cairo, libcairo
00:12:59.280 --> 00:13:01.439
to do SVG graphics and so on.
00:13:01.440 --> 00:13:09.719
You can do that very easily with Guile, but then on top of
00:13:09.720 --> 00:13:14.719
that, implementing Emacs list bindings to it, I mean,
00:13:14.720 --> 00:13:17.199
you've got two layers there, and that makes things pretty
00:13:17.200 --> 00:13:23.119
difficult. So it's possible. And to some degree, maybe
00:13:23.120 --> 00:13:27.799
necessary for example, Cairo, if we want to do SVG graphics
00:13:27.800 --> 00:13:30.599
the way that Emacs Lisp does, we're going to have to have
00:13:30.600 --> 00:13:33.959
that. So that would be necessary. We would have to have those
00:13:33.960 --> 00:13:39.199
two layers. Yes, let's do that. But if it's like for Magit,
00:13:39.200 --> 00:13:45.479
you can just call out to your git process, and then you're
00:13:45.480 --> 00:13:50.719
just using the regular process APIs that Emacs Lisp has. And
00:13:50.720 --> 00:13:57.119
that can be, already we, like Guile has some very good
00:13:57.120 --> 00:14:08.079
implementations for process management. And so it would
00:14:08.080 --> 00:14:12.439
just be a matter of wrapping up those in the Emacs lisp form
00:14:12.440 --> 00:14:24.919
bindings. So yeah, dynamic libraries, I wanna try to avoid.
00:14:24.920 --> 00:14:32.799
And I would prefer to do things more through, you know,
00:14:32.800 --> 00:14:40.399
launching a child process in the Emacs process. and then
00:14:40.400 --> 00:14:47.239
communicating over the standard in, standard out
00:14:47.240 --> 00:14:47.959
channels.
00:14:47.960 --> 00:14:52.799
That's the easier way to do things, I think, because then you
00:14:52.800 --> 00:14:58.519
can just use the process library that Emacs already has, and
00:14:58.520 --> 00:15:03.239
you can just reuse all of that code.
00:15:03.240 --> 00:15:09.079
I'm not sure how ripgrep works, unfortunately, but I
00:15:09.080 --> 00:15:15.279
believe that's also a process, a child process. So, we can
00:15:15.280 --> 00:15:23.479
just reuse all of the Emacs Lisp code that does that already.
00:15:23.480 --> 00:15:30.399
We just need to make sure that the process management
00:15:30.400 --> 00:15:35.119
implementation and scheme is properly bound to Emacs Lisp,
00:15:35.120 --> 00:15:43.359
and it works the same as GNU Emacs does. Once that's all set,
00:15:43.360 --> 00:15:48.399
then these porcelains, like around git, should fall into
00:15:48.400 --> 00:15:55.279
place. without too much difficulty, hopefully.
NOTE Q: Not really a question, but how about Schemacs as a name?
00:15:55.280 --> 00:15:59.199
How about Schemax as a name? I like the name. I like that name.
00:15:59.200 --> 00:16:03.119
I haven't really looked into like, is that already used or is
00:16:03.120 --> 00:16:09.759
that going to be confusing? But certainly something we can
00:16:09.760 --> 00:16:10.959
discuss.
00:16:10.960 --> 00:16:13.039
Another thing I should mention,
00:16:13.040 --> 00:16:18.759
I should probably set up a server or something like Discord
00:16:18.760 --> 00:16:25.359
or something like that. Discourse, not Discord.
00:16:25.360 --> 00:16:31.599
Discourse, the open source one, where we could actually
00:16:31.600 --> 00:16:49.239
chat about this stuff. For the time being, ActivityPub,
00:16:49.240 --> 00:16:52.399
mostly Mastodon, is how I communicate with people in real
00:16:52.400 --> 00:16:57.279
time, that or email. So if you want to get a hold of me, check
00:16:57.280 --> 00:17:02.439
the notes for this presentation and just send me an email.
00:17:02.440 --> 00:17:09.039
Any question at all is fine. If you want to contribute code,
00:17:09.040 --> 00:17:12.799
if you want to just learn how to contribute code, send me any
00:17:12.800 --> 00:17:22.199
questions. It's fine. I'm happy to answer them. And we can
00:17:22.200 --> 00:17:25.879
talk about the name as well.
NOTE Q: Why is it not feasible for the Emacs layer that interprets Emacs Lisp (the core in C) ot have a Scheme interpreter, instead of using Guile?
00:17:25.880 --> 00:17:30.239
Okay, why is it not feasible for the Emacs layer that
00:17:30.240 --> 00:17:34.319
interprets Emacs Lisp, the core in C, have a Scheme
00:17:34.320 --> 00:17:39.799
interpreter instead of using Guile? Let's see, I have to,
00:17:39.800 --> 00:17:48.799
okay. Emacs layer interprets Emacs Lisp, the core in C, have
00:17:48.800 --> 00:17:54.079
a Scheme interpreter instead of using Guile. Okay, so that,
00:17:54.080 --> 00:17:59.959
the question xlarsx is asking, xlars, x, So Lars is asking,
00:17:59.960 --> 00:18:02.319
is it not feasible for there to be an
00:18:02.320 --> 00:18:06.839
Emacs layer that interprets Emacs Lisp have a scheme
00:18:06.840 --> 00:18:33.079
interpreter? This is Robin Templeton's project. And
00:18:33.080 --> 00:18:39.839
they're presenting later today. So check the roster and be
00:18:39.840 --> 00:18:45.199
sure to see that presentation because that's exactly what
00:18:45.200 --> 00:18:52.119
Robin Templeton is doing. That's not what I'm doing though.
00:18:52.120 --> 00:18:57.239
I'm trying to create something in Scheme. But yes, there is
00:18:57.240 --> 00:19:02.959
an attempt to get an Scheme interpreter to run inside of
00:19:02.960 --> 00:19:07.159
Emacs itself. And it has its own method of binding to Emacs
00:19:07.160 --> 00:19:11.199
Lisp functions and translating data like Lisp structures
00:19:11.200 --> 00:19:14.439
between Guile Scheme and Emacs Lisp. Robin will explain all
00:19:14.440 --> 00:19:15.799
of that in their presentation.
00:19:15.800 --> 00:19:18.919
OK, I think I've got through all the questions on Etherpad.
00:19:18.920 --> 00:19:23.879
But I'm going to hang out here for a bit longer. And yeah, feel
00:19:23.880 --> 00:19:28.239
free to do a video chat with me or send me more questions on
00:19:28.240 --> 00:19:33.839
Etherpad or here in the big blue button. And so I'm just going
00:19:33.840 --> 00:21:49.119
to hang out. And thanks for asking all your questions. And
00:21:49.120 --> 00:21:50.839
yeah, I look forward to working with all of you if you're
00:21:50.840 --> 00:21:51.799
interested. take it easy. Thanks so much for the talk and
00:21:51.800 --> 00:21:53.199
looking forward to seeing some of your progress as this
00:21:53.200 --> 00:21:54.359
moves forward, exciting space. We'll go ahead and leave the
00:21:54.360 --> 00:21:54.879
room open for you and thanks for offering to hang out and chat
00:21:54.880 --> 00:21:55.639
with other people that come by. Feel free to throw something
00:21:55.640 --> 00:21:56.719
in the chat if you want to remind people you're still here.
00:21:56.720 --> 00:21:57.919
Meanwhile, on the stream, we have moved along to our next
00:21:57.920 --> 00:21:59.599
talk on Rust, and that is just getting started. But again,
00:21:59.600 --> 00:22:00.479
we're continuing to record this, and I'll just keep an eye on
00:22:00.480 --> 00:22:01.239
it to stop the recording. Thank you. Thank you. It was
00:22:01.240 --> 00:22:01.559
awesome.
00:22:01.560 --> 00:22:03.959
So it seems like it's slowed down here for the Q&A. I don't see
00:22:03.960 --> 00:22:05.439
anybody else on BBB, so I'm going to go ahead and stop the
00:22:05.440 --> 00:22:08.479
recording. We can start it back up. I would say, yes, there's
00:22:08.480 --> 00:22:09.519
a lot of things you can do with this. You can handle
00:22:09.520 --> 00:22:11.239
processing. Yeah, I'm going to try and join over the chat for
00:22:11.240 --> 00:22:14.679
the next talk. I'm not sure if I can do both big blue buttons at
00:22:14.680 --> 00:22:15.759
the same time. You should be able to just watch your mute
00:22:15.760 --> 00:22:19.159
settings and mute tab settings and whatever all you have to
00:22:19.160 --> 00:23:37.800
avoid bleed through. Okay.
|