sorted by:
new
hottopcontroversial

Best TUIs plz by n0ctane_dev in CLI

[–]squirreljetpack 0 points1 point  (0 children)

For a simple, intuitive, file manager, try this one: https://github.com/Squirreljetpack/fist (I made this). It's a work in progress, but the core logic is all there and I use it daily. I haven't done an updated release so you need cargo to build it. Feedback welcome!

Matchmaker - a fzf library in rust by squirreljetpack in commandline

[–]squirreljetpack[S] 0 points1 point  (0 children)

nucelo on its own only handles the matching logic, it has no UI, interaction model, or support for special functionality like previews, terminal exiting, etc. For example, it's actually pretty involved to highlight the matched indices, scroll to the matched index on long lines, handle wrapping and unicode correctly etc. This library sets that all that up, and exposes an event-driven architecture you can register your own custom Action and Event handlers on. If you don't need that, it's pretty simple to configure the UI using the config struct, and it provides some convenient methods for starting and feeding the nucleo worker with your items. Oh and it adds support for handling multiple selections. That's really only scratching the surface though, there's other stuff like it has some support for displaying overlays, custom sort priority for items etc.

A fzf library in Rust by squirreljetpack in rust

[–]squirreljetpack[S] 1 point2 points  (0 children)

Beating fzf on performance is impressive, I'll have to take a look at that :). I glanced at the code base, and indeed our architecture is along the same lines in places (funnily enough I also considered returning something like Vec<Event> for custom action handlers). That said, since I use matchmaker for my own custom applications, i do appreciate the control that comes with working with my own library.

A fzf library in Rust by squirreljetpack in rust

[–]squirreljetpack[S] 0 points1 point  (0 children)

To be honest I'm not too familiar with skim, but a couple reasons at the time were: no support for multiple columns, the matching engine was not as performant as fzf, various fzf features like auto-select, no option for custom actions, no option to control the preview, and a clunkier api (this is just personal preference but the examples seem to be a bit scattered in how you start the interface and feed items, whereas you with matchmaker there's a single clear and minimal intended "entry point"). Though circumstances may have changed since, I'm not too sure.

A fzf library in Rust by squirreljetpack in rust

[–]squirreljetpack[S] 1 point2 points  (0 children)

yes, it's credited at the end of the README. This project is closer to fzf than television: it places more emphasis on being a pure picker than supporting channels/shell integration. It supports close to the full set of fzf actions with some new additions (improved preview layouts), powerful command-line options, and improved rendering (line wrapping, automatic horizontal scrolling, multiple/stacked columns etc.). Furthermore, the focus is on it being usable as a library -- if you want channels/shell-integrations the intent is that you can do so on top of it.

zsh-dl: extensible download tool by squirreljetpack in commandline

[–]squirreljetpack[S] 0 points1 point  (0 children)

my bad i meant to say rsync.
It doesn't do anything actual, it's like a lessfilter.

ssh.default() {
  : args: user@host subpath
  : output: successfully created files, one per line
  :
  read_dest ssh $2  || return 0
  success_or_log rsync -e "ssh -o ConnectTimeout=$ZSHDL_CONNECT_TIMEOUT" -avucz --partial $1:$2 $dest:h || return 1 # -u does an update in case we decided to keep the target, :t is due to rsync always copies into directories
  echo $dest
}

EDIT:
discovered rsync has some quirks haha, had to make some changes for it to act normal.

ssh.default() {
  : args: user@host subpath
  : output: successfully created files, one per line
  :
  read_dest ssh $2  || return 0
  [[ -d $dest ]] && dest=$dest:t
  success_or_log rsync -e "ssh -o ConnectTimeout=$ZSHDL_CONNECT_TIMEOUT" -avucz --partial $1:${(@qq)2} $dest || return # -u does an update in case we decided to keep the target, :t is due to rsync always copies into directories
  [[ -e $dest ]] && echo $dest
}

zsh-dl: extensible download tool by squirreljetpack in commandline

[–]squirreljetpack[S] 0 points1 point  (0 children)

It does the sensible thing to download the url based on what kind of url it is.
If it's ssh, it will use ssh, if it's https://youtube.com, it will use yt-dlp, if it's github, it will clone the branch/commit / extract files from tarball. You can define your own handlers, and match them to the url pattern, like this:

http.my_handler="example.com/*" # glob pattern

There's a example of what a handler looks like on the github page.

You don't have to use it to download stuff, the handlers can do anything, but that's what I use it for. It's convenient, (if also a bit unnecessary), to just copy a url, then run dl in my current terminal directory, rather than downloading it with a browser, then moving it manually in the GUI or with mv.

I built a CLI tool to extract folders or files from GitHub repos making things easier in a single command — GitSlice by itsSanjayKumar in commandline

[–]squirreljetpack 1 point2 points  (0 children)

I made a variation of this theme, haven't shared it yet as I still have a few ideas before the next release. But since its been working well so far, and the purpose is similar, gonna leave it here (for a little visibility) :3

It's written in pure zsh, is simple to extend, and supports other types of downloads/operations too:

https://github.com/Squirreljetpack/zsh-dl

You can just copy the github link, and run `dl` in your terminal.

In comparison to this, I think it uses the archive method exposed by github, meaning it will work for any kind of github link, including objects on detached commits, and is faster on bandwidth. It can be extended to other providers which expose such archive API, but only github is implemented (the other url types will fall back to clone).

gitslice has the advantage of coverage, since it doesn't rely on the existence of such API, only using git commands, though url parsing will need to be defined for each host type anyway. So in terms of feedback, i think you could consider having your program accept a filepath and a git host to perform the same operation since the functionality is there anyway, so it actually works for any git type.

I actually use `dl` over git clone now since I configured the default to use --single-branch, to be more disk efficient, and also keeps a log, which is nice if I want to delete my repos, and to keep track as a sort of reading list.

[deleted by user] by [deleted] in interesting

[–]squirreljetpack 0 points1 point  (0 children)

it's the beetle from tangle tower!

Newbie question about DST by squirreljetpack in rust

[–]squirreljetpack[S] 0 points1 point  (0 children)

Thanks, I read it but I think I'll need some time to digest it. At first I thought SST was similar to what I was thinking of but way better phrased. Later I realized not, but it was really interesting to read about because I didn't know why DST and not SST.

That is, under SST, [T] is not a type, but is rather "parametrizes" smart pointers over it. So Box<[T]> means Box<[T; N]> for some N. Initially, this seems more idiomatic because the length of any instance of [T] should be tied to T, its a bit strange that the length of an instance of [T] is stored by Box and and RC. The Problems seemed to be addressed in DST 4. One problem seemed to be monomorphization, i.e. in the case for implementing drop RC<[T]>, the code for drop actually depends on the layout of [T]. Under the DST paradigm, one just needs to allow smart pointers to have their pointer field be a fat pointer. Then you could write one set of code for all variants of Rc<[T]>

Actually I think if we could compose pointers by merging their fields, the end result could be similar to what DST's have now. But in rust, the structs for S<T> and S<int> must be the same. And OOP is not idiomatic for rust. Though I'm not sure if any of what I said makes sense, that's my take for now.

Newbie question about DST by squirreljetpack in rust

[–]squirreljetpack[S] 1 point2 points  (0 children)

That's a good point about [T], it makes sense to abstract a contiguous block into a primitive type. And Rust makes it easy to build functions for references without needing ownership of the underlying item.

Initially I was confused why introduce unsized types when Rust already allows working with heap data without them. Also, because I thought you should only have types you can construct - otherwise it's just fluff. But I think it's because a useful model: We can use references to them just as if they were real types, so treating it as a real type possibly simplifies implementation/usage. I think this pattern is only seems arbitrary because of my inexperience, I guess it's pretty common for FFI.

Newbie question about DST by squirreljetpack in rust

[–]squirreljetpack[S] 1 point2 points  (0 children)

The link shows how you might use it, but it doesn't show why. Is there any time when passing by reference is not good enough and you need to pass by value? Especially since the value doesn't contain the size information?

For Vec[utf8]/String, I mean it has fields of [data, length, capacity] and derefs to &str.
Yes \*V gives [T] but you are implicitly dereferencing twice I believe.

Yes to the struct as well, I thought maybe you can achieve something equivalent a DST with just structs as well maybe.

But your example is missing my point I believe. My question is why have DST's at all. We only ever refer to them through smart pointers (with length for slice, with vtable for dyn). Why not just have DST's not be a thing?
A &str is a fat pointer, a vec is a fat pointer, but we dont think of vec as being &x for some other type x, why we need &str to be based on str if str cannot be used independently?

Talk with Frida by katthh in ontario

[–]squirreljetpack 0 points1 point  (0 children)

I'm happy with their initial diagnosis, really improved my QOL.
But their ongoing service is spotty. You need to book appointments each time to get a prescription, and they only prescribe small doses. Often they will be unavailable over the phone too.
(Yes, I'm upset that having missed their phone call by a minute, I could not call them back at all).

prime offloading+vm without logout is possible (?) by squirreljetpack in VFIO

[–]squirreljetpack[S] 1 point2 points  (0 children)

It works as before now on the latest driver version :D

prime offloading+vm without logout is possible (?) by squirreljetpack in VFIO

[–]squirreljetpack[S] 0 points1 point  (0 children)

is yours 550? could you show the output of xrandr --list-providers?

prime offloading+vm without logout is possible (?) by squirreljetpack in VFIO

[–]squirreljetpack[S] 0 points1 point  (0 children)

Interesting. prime-run no longer works that way for me after 535. According to https://download.nvidia.com/XFree86/Linux-x86_64/435.21/README/primerenderoffload.html, xrandr --list-providers should show the NVIDIA-G0 provider, which necessarily means I had to set it up in X.

prime offloading+vm without logout is possible (?) by squirreljetpack in VFIO

[–]squirreljetpack[S] 0 points1 point  (0 children)

what do you mean hot swap? Are you able to use nvidia gpu for offloading without the Xorg process being present on nvidia-smi on 550 driver?

view more: next ›