[Amin]: Okay, so for folks, you can start asking your questions over IRC or the PAD,
and after a minute or two, we'll also open up this big blue button room
for those of you who would like to join here to ask these questions directly.
Michael, take it away.
[Michael]: Okay, cool. It looks like we've got two questions on the PAD.
The first, how does this approach compare to using TQ.L,
Emacs's built-in library for transaction queues?
Yeah, that's actually a great question.
I should have called out TQ in the talk
because I actually took a hard look at it in terms of my implementation.
You could absolutely build this using TQ.L. I chose not to because
I didn't see any compelling benefits to pay the cost
of adding another dependency and creating a buffer for each new connection.
In the actual implementation, input is buffered into a variable connected
to the connection object and just handled there.
Have you considered using the AIO.L library written by Chris Wellens,
implements async await for Emacs Lisp using promises. Implemented
using Elisp's record data structure turns the nested callbacks into
regular-looking Elisp code without introducing new keywords. Cool. No,
I didn't because I was not aware of the package. But the fact
that it was written by Chris Wellens alone is enough to get me to take a look.
So yeah, perhaps that could have been another implementation.
But I don't know. This kind of code journey finally got me
to understand Emacs Lisp. I don't regret anything else.
[Amin]: I think your last sentence was a little cutting off, Michael.
Maybe you were a little far from the mic.
But yeah. Okay. All I was going to say is, yeah, I mean,
leave it to Chris Wellens to solve the problem in all generality.
All I noted at the end was given that this little project
is what finally got me to understand Emacs macros or Lisp macros, you know,
I kind of, I don't regret running down this implementation.
We've got another question coming in.
Am I aware that Ems has an MPD, I absolutely am.
And there's actually another MPD client for Emacs called MPD-L.
Yes, yes there is. So again, I probably should have talked about this in before,
but I was pressed for time. I was not looking, yeah,
I was not looking for a full-fledged MPD client. Sometimes MPD-L
and MPC.L can give you a full UX within Emacs
and I would absolutely recommend them if that's what you're looking for.
I wanted to just add a few tweaks to my workflow.
Now increase the volume while coding, put the track name and the mode line,
things like that. So I felt like those were a little heavyweight.
In fact, I ended up corresponding with the author of MPD-L.
And kind of the analogy I came up with was if, you know, MPD-L is to MPD
as good news is to email, I wanted to build mail utils.
I just wanted a couple of very tight little utilities
that would get me what I wanted. But yeah, actually
that's also a great callout. Perhaps I should have included references
to those clients. One thing I will mention is
I think we've got plenty of time for questions.
Maybe close to 25 minutes or half an hour, which is very interesting.
I think in many cases it's been more than the actual length of the talks.
And I think that's a side effect of sort of, I guess, going with two tracks,
which is nicer. There's much more breathing room between the talks this year.
So if there are questions, as long as there are questions coming in,
or if you do also want to present anything extended, you know,
more than what you covered in your talk, you're also welcome to do that
and, like, stay here. So.
Okay. Cool. Now I'm happy to hang out. This is an interesting question.
Have I seen the Lonesome Pine specials?
During the talk he saw my music library and figured I'd be interested.
I have not. But oh, interesting. Bella Fleck. Cool.
I will be checking out Lonesome Pine, thank you.
Oh, that's an awesome, awesome tip. Cool.
That's probably going to be it for the questions.
Do we just, do we hang out for the balance of the time?
Yeah, sure. I think there's actually one new question on the pad
and I might have one to ask as well, but yeah, otherwise we can.
Oh, apologies. Yeah, I needed to scroll down.
Would using dynamic special VARs add anything interesting,
easier to async with? I'm not sure what you mean by
dynamic or special variables. Can you say a little more?
Okay, fair enough. I mean, certainly in the examples that I included,
we could use variables at a larger scope. Yeah, yeah.
Interesting. Good question. I would have to think on that one.
To be honest, I went hard down the lexical binding path a few years ago
when it was introduced to ELISP, precisely because I found dynamic binding
so much more difficult to reason about. Possibly.
[Amin]: So I guess one question I might have,
prefixing it with the fact that I wasn't able to fully follow your talk
because I've been basically behind the scenes.
But how would you say that your project compares to some of the other,
I guess, MPD clients?
[Michael]: Yeah, like a couple of years ago, I used to use ncmpcpp myself,
and also I tried a bunch of different ones.
I never quite got into using emms as one.
[Amin]: I noticed that you mentioned that, for example, for some of the other ones,
maybe like npc.l, yours may be much more lightweight.
But yeah, I was wondering how you would compare them.
[Michael]: Yeah, yeah. So those are what I would call full-fledged applications.
You're familiar with ncmpcpp. You could swap that out as your daily driver
for any of those. They show you the playlist. They let you browse.
They let you set up saved playlists, et cetera, et cetera, et cetera.
And this does none of that. This is basically a building block.
These are building blocks for building up Emacs commands.
So for instance, I actually have a little minor mode that holds the key cord.
You can adjust the volume. You can skip to the next track.
You can do a few things like that. But that's it.
More of a tool kit than an application, I guess, is the way I would put it.
[Amin]: Right, right. Makes a lot of sense.
Awesome. Another question. Can I share the code to the macro?
Help a bit for folks.
And it's on OPA. Let me share a link here. Or
I guess maybe GitHub would be the better UX. I can do that right now.
Let's see here.
I'll put it in the pad.
Don't judge me. It's my first list macro.
OK. So I can do that. I can do that. I can do that. I can do that.
I can do that. I can do that. I can do that. I can do that.
[Amin]: I think we got all the questions. I think this is an interesting sort of,
I guess, topic or thing that's come up today. I think multiple times,
there was also partly mentioned in RMS's talk as part of the Q&A
where he was sort of complaining a little bit or saying that
how he would like to see some of org's features, I guess,
be decoupled from org or org syntax
and just be made available either as libraries
or maybe as smaller minor modes that one could use then
throughout anywhere else in Emacs. And I think I do agree,
and especially now in the context of MPD and using it via Emacs,
I think it's very important to also have libraries or toolkits,
as you mentioned, to be able to build upon them however you wish. So kudos.
Thanks so much for working on this. It's very kind of you.
[Michael]: Yeah, I mean, there was a much remarked upon,
perhaps even controversial talk at last year's EmacsConf by Carl Voigt,
if memory serves, proposing that the org mode markup language be sort of
hoisted out and given a specification, he wanted to call it org down.
And I think some people, for reasons unclear to me,
were highly resistant to this.
But yeah, yeah, mm-hmm, yeah, interesting.
There's another package, Taro, perhaps,
pronouncing that phonetically, in addition to Welland's AIO
that also implements a coroutine trampoline on the Emacs event loop.
Interesting.
Any thoughts on the async await paradigm generally, red-blue functions,
et cetera? Oh, wow.
What color are my functions could be the topic of another talk in and of itself.
Yeah, that's sort of the problem with async, isn't it? It's like a virus
that infects your code base once you start.
And having spent a fair amount of time in the past year or two
writing async rust, I guess I've kind of made my peace with it.
I was highly resistant to it at first.
But who is that venture capitalist that diagrammed
the uptake of new technology? And at first,
you sort of saw this exponential curve of enthusiasm,
then a peak, and you called it the valley of despair,
and then sort of a plateau of acceptance.
I kind of feel like asynchronous programming is kind of the hot new topic,
and everybody's diving in, including in scenarios
where I'm not sure I see the benefit
to the additional complexity to your program.
So I did it here because, as I tried to demonstrate,
response latency back to the MPD server
can reach into the realm of human perception, depending on the query.
And my use case was, I'm in a buffer coding.
I just want to quick adjust the volume, and I didn't want any pauses.
But in a lot of other scenarios, I just don't see the benefit to.
So yeah, I mean, that's my two cents.
Yeah, I think there's a lot of care to be taken, well,
I guess in both in advance consideration, but also while implementation,
if one is going to add asynchronicity to an existing code base
and making sure to cover essentially as many as existing workflows
and code paths as possible.
Yeah, exactly, exactly.
You know, I've certainly gotten myself into trouble writing asynchronous code
and locked up the async runtime, and it's like, well, you know,
is the benefit worth it? I mean, look, if you're building a socket server
of some sort, like a web service, microservice type of thing, all
of the famous 10k connection problem from the last decade,
if you're writing a command line tool, you know, Klee,
I'm not sure why you need to spin up anything to run time for that. Yeah,
I mean, I'm not sure why you need to spin up anything to run time for that.
Yeah. Yeah. Yeah. Yeah, I mean, I'm not sure why you need
to spin up anything to run time for that. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah.
Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah.
We'll definitely be checking. It's. So, Centauro appears to be the author.
The package name is called Emacs Promise. Interesting. Okay,
I see you reacting, I just wanted to check out if my mic is working.
The talk, thank you for your interesting talk.
That's a yak. I already shaved myself
how to do async programming in Emacs.
I found about the TQQ and I improved on it, too,
and then I was thinking, okay, async programming.
It wasn't how to do macros, but it was my whole into, yes,
how to do async programming without callback hell.
And as you said in your title, you did async before it was cool,
because you often hear the opinion that Emacs doesn't do multithreading,
it's just single threaded and therefore old and useless.
Not like that, maybe.
The solution you found, do you think it's a viable future
for Emacs to get out of callback hell?
I think so, but I would certainly, in the pad,
somebody pointed out that Christopher Wellens
came up with a general purpose async await library
that I will definitely be taking a look at,
because I think he used the phrase yak shaving
and that's absolutely what I was doing here.
So this solution is purpose-built to my little personal problem.
It sounds like Wellens may have solved the problem in greater generality.
But yeah, absolutely. I mean, periodically
in the Emacs IRC channel or an Emacs devil, somebody will say, oh my God,
I can't believe Emacs is single threaded, this is hopeless, and yeah, I think
that here's another use case for asynchronous problem.
It's interesting that you mentioned like the AIO from Christopher Wellens,
because I had a look at it too.
And if I remember correctly, he uses Emacs generators.
I'm not really sure, I'm not sure anymore if that's the case. But yeah,
that's another cool macro use to get out of callback Emacs generators.
Did you see it already? I'm looking at it right now for the first time,
oh gosh, look at this. And if you want, I can spare you a lot of time,
because if you go down this road and you get the same direction as me,
you'll find out like, okay, that's a cool solution.
You already mentioned Go, the solution Go uses
with the coroutines or green threads
or whatever you name it. And I think, in my opinion, the best solution
or the neatest solution of this problem in this plant or in general is Futures,
no, not Futures, wrong name, host called, no, I just forgot.
It's a guy's scheme, and it's from Andy Wingo. And he does it with fibers,
not Futures, fibers, this is a really good solution for the problem of how
to do async, how to do multi-color functions
and say they have all functions the same name.
And it's fundamentally based on concurrent ML, and yeah, fibers on top, this
is cool. I would like to see this in the mix. Interesting.
So I found this talk, Channels, Concurrency, and Cores,
a New Concurrent ML Implementation.
This one, yes.
Okay, I will be taking a look at this, thank you.
You're welcome.
Maybe to expand on this, if you don't mind. Please.
The idea behind it is like Chris Wellon uses generators,
generators like in Python generators,
like you have some function, and it can yield,
and you can start it again at this point, and so on and so on.
It's an Emacs, and it's a hack. It uses a macro for the code processing,
and then it's bits of callbacks, more or less.
And it's a solution for like how do I specify callbacks
without writing actually callbacks with writing synchronous looking one color.
And the general solution, and that's the reason Andy Wingo can do it in Guile,
for them is the limited continuations. You have a delimited continuation,
that means you have a point in your program where you can yield,
and it yields until a prompt, like it yields a part of your code.
What that means is your code can stop
and pass the rest of the computation to something else,
and this something else can invoke the computation.
That means you can have a scheduler.
And How do you arrange for your continuation to be restarted or all can again?
Good question. That's exactly the thing the Fibers does, like the scheduler.
You could put it like an Apollo interface, even in Linux,
which Apollo network connection or a file creation, something like that,
or a socket.
Interesting.
This sounds not dissimilar from what I understand goes coroutines to be.
This is coroutines, more or less.
Right.
These are the things you can do when you have
like Andy Wingo can do it in Guile
because he's got his fingers into the interpreter.
Yes, he does. He sort of got inside knowledge.
I don't know.
Yeah, I think so, too.
He implemented the delimited continuations,
but yes, it was maybe my point I wanted to make.
Like there's a neat solution.
Sometimes you need these delimited continuations
and function-wise you need like some kind of callback.
Actually, you always need some kind of callback. You just hide it, well,
and you call the delimited continuation.
Right.
I mean, if you've ever tried to do asynchronous programming,
say, in C using EpoL, sort of wind up structuring your entire program
around this event loop and kind of you sort of have this state
that you move through as various things get signaled,
whether data shows up on a file descriptor or a timer goes off, whatever.
And it's kind of mind-bending.
It's definitely, you know,
humans seem to be most comfortable writing imperatively.
And so whether it's Ruster or Golang or JavaScript, it all seems to be like,
how can we wrap that state machine more ergonomically?
Yes, exactly. How much more time do we have for Q&A?
I think we have about seven and a half, eight more minutes.
Yeah. We don't have to use all of it if there are no questions,
but you're also welcome to hang out if you want.
I'm happy to wait.
Cool.
And also, if there are no questions, I mean,
one thing we could maybe do is to, if you
like to maybe give a quick demo, like walk through some of the parts of,
you know, your package, your code that could also work whichever,
whatever you're more comfortable with.
Honestly, I wasn't prepared for a live demo, so.
Oh, yeah, sure. No worries. Sorry. Don't mean to put you on the spot.
I'm going to steer clear of that.
That's fair enough.
Thank you.
Okay. you
questions maybe we can wrap it up sounds good
I actually think I need to check in for my next talk soon
oh yeah sure all right any last question before we wrap up folks
all right I think in that case we can go ahead and wrap up
thanks so much Michael for the great talk
I very much look forward to checking out your work
and yeah seeing what what could be done with it
and using it as a building block and toolkit all right well
thank you so much
I feel like I learned as much through the Q&A
as other people probably did from the talk
wonderful
yeah it's great it's a great way to get to know each other
and get to know each other
wonderful yeah it's great
and yeah we were very lucky to be able to do these sort of live Q&A's
and awesome speakers like yourself just being able to join in
and yeah just teach and learn
all right see you in a bit
awesome yep see you in a little bit bye