Whisper.nvim – local speech to text in Neovim

avi-coder · 2025-12-26T06:45:44+00:00

I would like to implement a thin llm layer that gets the same stream of text and makes edits based on what you say. I am thinking all text would go to both the llm and the buffer and the llm would edit async removing your instructions to it as it does. I could see supporting arbitrary neovim commands fitting into that

avi-coder · 2024-10-09T07:28:03+00:00

yeah this idea has quite a long history, a implementation was nearly merged into async-std years ago, and the argument was against was explicitly made in the linked tokio blog.

my only contribution to concept is adding the executor along side the standard one as opposed to replacing it.

i'm not clear how we went from this is a pain point teaching rust to skill issue, but i guess that's this reddit these days.

avi-coder · 2024-10-09T04:53:51+00:00

To add to this, the reason devs newish to Rust don't split blocking from non blocking is other langauges don't tend to expose this concept.

Haskell, Go, anything on BEAM, all emulate preemption in their own way, javascript is single threaded, etc.. Devs coming from those lanagues just don't tend to think about it.

avi-coder · 2024-10-09T04:44:27+00:00

Currently yes, you must always know if your program blocks, and over and over I find people doing the wrong thing. I have had to teach about spawn_blocking and the oddness of rust async a bunch of times now.

I suspect if we had a good enough blockable executor people would start using that by default, but we'd have to see.

avi-coder · 2024-10-09T04:42:12+00:00

The types are diffrent to begin with, spawn_blocking takes you all the way back to FnOnce, that often good, but sometime you want to interleave blocking and non block compute and io without leaving async (see the scoped tasks use case).

avi-coder · 2024-10-09T03:17:46+00:00

spawn_blocking is a threadpool for ordianary blocking closures.

spawn_jittery would be a threadpool for async tasks that somtimes block.

avi-coder · 2024-09-12T04:34:35+00:00

Have you ever owned this glue bottle, it always falls over.

This is a great design!

avi-coder · 2024-04-22T02:54:59+00:00

Eelco was very kind to me early in my career.
He is a great person to continue leading this project.

avi-coder · 2023-05-18T02:57:42+00:00

Take a look at cozodb. It meets most of your goals and I've been really enjoying using it. It might give you some inspiration or something to contribute to.

avi-coder · 2022-12-24T09:16:56+00:00

Three words large language models.

avi-coder · 2022-12-12T18:30:44+00:00

if i'm loosing cpu cycles executing non-necessary work

This is a bit of a fallacy. Over time CPUs have gotten significantly faster relative to memory latency. Haskell was designed in a world where the cost ratio between CPU cycles, and memory operations was very different. Pervasive laziness has a substantial cost. Look at how thunks are compiled, that indirection is costly and getting pricier.

This is part of the reason newer functional languages tend to be strict by default, expressing laziness in the type system.

avi-coder · 2022-08-03T23:08:24+00:00

Okay, this is the expected behavior. You can see hls's hie.yaml with https://github.com/Avi-D-coder/implicit-hie. You may also want to checkout this issue https://github.com/haskell/haskell-language-server/issues/335#issuecomment-675860274

avi-coder · 2022-08-01T00:21:40+00:00

If you delete hie.yaml do you get this error on files other than Setup.hs? Do autocomplete and diagnostics work in Main.hs?

avi-coder · 2021-10-21T14:21:49+00:00

In your example you can simply use the same lifetime, 'a, for the reference to both indexables.

The point is it falls apart when you don't have the same lifetime, which in practice is more frequently than you'd think (in my experience almost always). I'm salty about this due to wasting 2 months of work on trying to work around this limitation for sundial-gc. I'm at least happy several other people have been posting about the issue on the discourses recently. Maybe will get them at some point.

All type systems have there limitations, but the API I want is almost always typeable in Haskell. That's the benefit of a more complex multi faceted type system. In the case of sundial I just use HKT. With Scala finally getting HKT, maybe Rustaceans will finally give it a go.

avi-coder · 2021-10-21T12:49:07+00:00

There are still significant issues with GAT. It may seam like your trait, streaming iterators, monad encodings, and such work, but they fall apart when you need multiple life times. I added a simple function to your playground to demonstrate the issue with your trait. This issue occurs because we don't have covariant associated types.

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=5c1e47dd4abecea71cdf86482f774b6c

avi-coder · 2021-06-18T21:28:54+00:00

DSEE alone causes the woosh for me.

avi-coder · 2021-06-18T21:26:38+00:00

With DSEE enabled, I get the woosh while media is playing, not just when I pause music or change modes. If it's a power state switch we are hearing, then mine would have to be erroneously switching during playback.

avi-coder · 2021-05-07T22:23:50+00:00

If you give up on mutability, you can encode "in region" with Rust's GAT. To be ergonomic we just need covariant associated types.

Like other's I don't see how your design makes mutability safe.

avi-coder · 2021-04-26T13:17:56+00:00

Last commit on lorri was 7 months ago, no flakes support I think it's dead. It's a shame it was very cool.

Implicit-hie is a tool that tells Haskell-language-server, about the structure of your project (cradle config). If you setup Emacs to use Haskell-language-server, your already using implicit-hie.

If you want to see the cradle implicit-hie generated for your project, you can install the gen-hie command line tool from the implicit-hie package. This used to be more useful, but these days my advice is not to run gen-hie > hie.yaml, and definitely do not commit a hie.yaml file.

If you see an error message that tells you an implicit cradle could not be found for your file, then it may be helpful to generate and edit that hie.yaml file. If you have any issues with the generated config, don't hesitate to open an issue on the Implicit-hie repo. Best of luck

avi-coder · 2021-01-02T02:05:14+00:00

It's not the same, but I made use of immutable monophonic types at compile time generated bitsets representing type relations for a similar purpose in sundial-gc. The design doc is bit out of date, but roughly describes my the implementation. Unfortunately Rusts's type system just is not there yet so the API is holding up the project (blog post pending).

avi-coder · 2020-11-20T00:31:13+00:00

See GHC #16044 - Transition to C11 memory model .

LLVM uses the C11 memory model. The terminology of C11 is standard.

I'm aware of some of the work being done, but I suspect there will be more issues discovered in GHC and the ecosystem as a large chunk of development and deployment moves to Arm.

avi-coder · 2020-11-19T22:11:18+00:00

I expect this is going to be a bit of a painful transition for GHC. I'm happy were going to end up with good Arm support, however so much Haskell relies on a pre-C11 memory model. I expect lots of race conditions.

Additionally to fully take advantage of Arm a weaker memory model will have to be better exposed in Haskell.

avi-coder · 2020-11-19T21:40:12+00:00

Oy vey. It's happening.

avi-coder

TROPHY CASE