So as I told about minus which I was working for the last few weeks. There’s some good news. Yes! It’s ready for use. I think we should use the tokio feature of minus. This would also require some refactoring. But I can definitely say, It is really worth the effort. It’s threaded, asynchronous and most importantly cross platform

Here’s the GitHub link

https://github.com/arijit79/minus

What do you think @pmeunier

Wow, that was fast! I think this is really cool. I want to try it out, is it on crates.io already?

How do you handle memory when the input is reaaaally long? Does it start displaying right away? I’m super excited.

No it’s not in crates.io. But I will publish it after a few hours.

Also I did some testing with the tokio version and things went fine.

The output is inside a Arc>. It only displays untill all visie rows in the terminal is not filled and stops to put output after that. Whenever the user presses any Up/Down keys. It re outputs everything + 1 line at the bottom and - 1 line at the top

Hello @pmeunier. I just wanted to inform you that I have uploaded minus on crates.io. You can now get it directly from crates.io like this

minus = { version = "1.0.1", features = "tokio_lib" }

EDIT: I have updated the version number, since 1.0.1 fixes a bug where output would get weird when terminal is resized

I’m super excited to try out this crate!

Fantastic! Do you want to submit a change to use it here?

Also, I checked the source code of Cargo, they’re using libgit2 instead of calling git, so unless someone makes a generic “VCS” lib, Pijul won’t get integrated very soon. One thing I’d love from Cargo is to be able to call cargo publish without --allow-dirty.

Since we are using tokio, the run() function in Log would require a rewrite using async/await. I don’t understand everything, so I am leaving it up to you

Also I am kinda busy fixing any bugs with minus

Hi! I just looked into this, and I’m not sure what to do, since it depends on Tokio-0.3, and the Hyper crate is forcing us to stay on Tokio-0.2.

This has been a little bit annoying for Thrussh, for example, where I’m maintaining two versions at the same time, and porting fixes to both channels in parallel (fully utilising change commutation there, btw).

hyper 0.14, which updates to tokio 0.3, is in the works.

Hey @pmeunier. You don’t have to wait for hyper .0.14, I have added the support for tokio 0.2.23 also. Use feature tokio2_lib and not tokio_lib with minus 1.0.3

I tried today, it doesn’t work. I copy-pasted code from the examples, it doesn’t compile.

Could you tell me which version are you using and what is the exact error message. I don’t recommend compiling directly from the master branch, but rather from one of the crates.io versions

I’m using the latest version from crates.io (2.1 I think).

I can’t writeln! into x.lines, and the locks aren’t awaitable (they seem to be plain old std::sync::Mutex).

I see your problem. You followed the examples written in the GitHub page which I have updated with the new API. I recommend that you follow the crates.io instructions which are correct.

I first tried to follow the instructions from https://docs.rs/minus , they don’t work either.

I don’t know what code you followed and wrote. But I am going to release a new major version of minus today or tomorrow. You should now probably use the new one

Hey @pmeunier, I have released minus 3.0.1, which should compile correctly and work as expected

Could you reconsider reimplementing minus into pijul

Wait, I’m not un-considering it, this discussion is still open. The main blocker at the moment is that there are MANY things that need to settle down before reaching the beta, and Minus seems to be moving quite a bit still. I still think it’s a cool project.

At the moment, I’m working on plugging the new Sanakirja into Pijul. I’m expecting a giant performance improvement with this, for many reasons:

• The new Sanakirja is more than 4 times faster than the old one on basic benchmarks.
• It also gives a greater flexibility in terms of memory alignment. Even though it doesn’t matters much on x86 CPUs, it means reading from the database is as simple as dereferencing a pointer, and there’s no deserialization involved.
• Also, the new Sanakirja is really zero-copy.

But it’s also a massive change: I’m in the middle of fixing ~500 compilation errors (all the types have changed), and it will break everybody’s repositories.

What I mean is, I haven’t worked much on Pijul in the last few weeks, because I was busy with that other sub-project. I like the idea of Minus, but I also want to avoid as many future bugs as possible.

I also wanted to mention that your versioning scheme looks a bit scary. For your particular ambition of writing a pager, version 1.0 should be completely ready, and significantly better than less. less has probably been run hundreds of billions of time by millions of people on many different architectures, so we must be extraordinarily careful when we make claims like “1.0”. Another example of this is ripgrep, i.e. grep rewritten in Rust. I don’t think they called it 1.0 before beating grep on at least some benchmarks, which is an extraordinary achievement (even a consistent 1% performance improvement over these 30-years old GNU tools is an achievement).

This is the reason so many crates on crates.io are still in their 0.x versions. For example, I wrote my first line of Rust in 2015, yet I haven’t published any 1.0 crate so far. I’m obviously working towards 1.0 for Pijul, but it won’t be another months before this happens. I’m considering it for Thrussh, since it hasn’t really moved in quite a while, and mostly stopped moving a few weeks ago. I’ve also tested it in production and served a few thousand sessions to random (including potentially malicious) clients without any major incident. And calling it 1.0 at this scale would probably be considered reckless by many (yet it would probably receive even more testing if it were called 1.0).

I do understand your point. But I kinda didn’t get it why you straight up compared to less. I Personally, I never thought of minus to be a complete alternative to less. I just wrote it to so that we can have paging in pure Rust, rather than depending on any external pager, not just less while also having some asynchronous data capabilities