I thought this immediately also. I already have ollama set up to run llm tasks locally. I don't want to duplicate that but it would be fun to try this front end.
That's great, I've struggled with this problem a lot. To double-check, this essentially allows you to specify a default app that is being opened when you click on a file via Finder or via terminal's `open` program, correct? I haven't seen this exact clarification in README
just is a great command runner[1], not a shell script. Looks like it is needed if you build from source or install from Github releases. Alternatively, use `brew install philocalyst/tap/infat`(haven't done it myself but I bet it has just as a dependency anyway)
[1] https://github.com/casey/just
Is there any good resource about class decorators specifically? It is more common to see function decorators in the wild, so my knowledge about the class ones is negligible at best
I can't name one off the top of my head, but conceptually they're the same because classes are also first-class in Python (i.e. they can be passed around as function arguments and even modified).
Classes in Python are actually themselves instances (of builtin class 'type'). So to make a decorator for one, you create a function that takes a class (i.e. an instance of 'type' with a lot of duck-typing already applied to it in the class definition) as an argument and returns a class (either the same class or a brand-new one; usually you make a brand new one by creating a new class inside the decorator that subclasses the class passed in, `MyNewClass(cls)`, and you return `MyNewClass`... The fact it's named `MyNewClass` inside the decorator won't matter to anyone because that's a local variable inside the decorator function body).
The syntactic sugar Python does when you go
@decorator
class Foo:
... is basically:
* Create a class (with no name yet)
* Pass that class to function `decorator`
* Bind the return value of `decorator` to the variable `Foo`.
---
Before decorators came along, you'd get their effects on classes with this pattern:
class Foo:
# the definition of Foo
Foo.some_new_method = ... # since Foo is also an instance of a class, you can just modify it in-place.
Foo = decorate_it(Foo) # ... or pass it as an argument to a function and re-bind its name to the result
Thanks for the detailed explanation! I assume that essentially, the same rules as with function decorators apply(in regards to parameterizing them etc.) but the main difference is that we accept the class object and then return the class object vs the function object and that's it?
The fact that even in the test example it took ripgrep 0.115 s with 97% CPU usage vs Krep's 0.106 s with 328% CPU usage is a testament of why ripgrep is still preferable. Such a huge tradeoff in resource consumption for such a small speed gain is hard to justify
Thanks for the useful article!
In addition to a lot of interesting info, it lead me to this repo containing an intro to git internals[1]. Would highly recommend everyone to take a look
[1] https://github.com/pluralsight/git-internals-pdf
Ah yes. It was pretty cool that when Peepcode was acquired, Pluralsight asked me what I wanted to do with my royalties there and was fine with me waiving them and just open-sourcing the content.
It also is a testament to the backwards compatibility of Git that even after 17 years, most of the contents of that book are still relevant.
Bonus points for "Bonus: where does uv install its virtual environments?" section! I was wondering the same question for a long time but haven't had a chance to dig in. It's great that venv is not being recreated unless any dependencies or Python version got modified
reply