scriptisto
emlop
scriptisto | emlop | |
---|---|---|
8 | 15 | |
601 | 36 | |
- | - | |
4.8 | 9.0 | |
4 months ago | about 2 months ago | |
Rust | Rust | |
Apache License 2.0 | GNU General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
scriptisto
- Scriptisto: "Shebang interpreter" that enables writing scripts in compiled langs
-
Running a zig file like a script
Nice, didn't know about this project. Looks like a zig template was added in 2021
-
What's the emerge command to have emlop p display the whole estimate?
Hyperfine is much better than time for quick speed comparison, as it runs the commands as many times as needed to get a statistically significant result. If you have an Emlop git checkout and scriptisto, you can also look at ./benches/exec_compare.rs --help
-
Announcement: xshell 0.2.0
I don't know if you've ever seen it before, but scriptisto does something similar to that. I've used it a wee bit, it's a fairly cool tool
-
Learnability of Rust
I ended up favoring scriptisto for the added versatility, but I must admit that having something integrated into mainline cargo would be much more enticing (only one tool to tell users to install). cargo new --from is a pretty neat idea too.
-
Shell Scripting in Rust
To make the workflow more script-like, tools like scriptisto make your rust code file executable, no project structure needed.
-
Using self-compiling & self-executing rust source code to replace quick-and-dirty shell scripts in under 10 lines
Scriptisto is another alternative which I personally use.
emlop
-
20 Years of Gentoo
My oldest remaining emerge.log started in 2007. That desktop went thru some hardware upgrades, that you can spot them in the build time logs. Would love to see [emlop](https://github.com/vincentdephily/emlop) s -st -gy and emlop s -gy -e gcc from your machine.
-
emerge monitor written in C
Genlop is indeed slow, but qlop is comfortably fast, and emlop is even faster. I encourage you to check them out.
-
New to Gentoo. Is it safe to use - jN when emerging packages?
Happy to help. The size and number of packages is what's important, not whether you're installing or updating. I tend to only use emerge -j2 if I have 10 or more packages that can each build in a minute or less. You can always stop an emerge and restart it with emerge -rO -jN if you feel you made the wrong choice. You can use emlop p to get an estimate of how long the current emerge will take (current release is a bit outdated, I suggest installing from git: cargo install emlop --git https://github.com/vincentdephily/emlop).
-
What's the emerge command to have emlop p display the whole estimate?
Emlop is much faster than genlop, gives better estimates, has fewer bugs, and more features.
-
Compile time newbie help
That's a huge variation in merge times, things are usually a bit more predictable than this. They might just get progressively slower as new package versions get bigger.
-
dev-libs/icu and dev-libs/boost causing at least 2 hours of rebuilds
On the positive side, it inspired me to implement display of the current merge phase in emlop:
-
Portage doesn't show verbose output after using -q once.
emerge -rOp|emlop p can tell you how long the currently running merge will take, if it's something you've merged on that machine before. You could also suspend your laptop instead of shutting it down.
-
My turn to cry about compile times
emlop
-
Remind me why qtwebengine-bin does not exist?
While genlop works, I highly recommend emlop instead, as it is much faster (emerge -rOp | genlop -c is unusably slow) and featureful. The version in the GURU overlay is outdated at the moment, so either get it from the moltonel overlay or using cargo install emlop.
-
Announcing Pijul 1.0 beta, a Version Control System written in rust
There are a handful of commits that take especially long, for example cc8fa62c which updates many lines of a 5Mb test file. I've observed similar issues with the vim import. It seems that large diffs slow pijul down greatly, import time is not linear to diff size.
What are some alternatives?
sysinfo - Cross-platform library to fetch system information
git-from-the-bottom-up - An introduction to the architecture and design of the Git content manager
quicli - Quickly build cool CLI apps in Rust.
emwa - Portage Log-Analysis
evcxr
gentoo - [MIRROR] Official Gentoo ebuild repository
rust-script - Run Rust files and expressions as scripts without any setup or compilation step.
portage-utils - [MIRROR] Small and fast Portage helper tools written in C
cicada - An old-school bash-like Unix shell written in Rust
Git - Git Source Code Mirror - This is a publish-only repository but pull requests can be turned into patches to the mailing list via GitGitGadget (https://gitgitgadget.github.io/). Please follow Documentation/SubmittingPatches procedure for any of your improvements.
cargo-run-script - Bringing `npm run-script` to Rust
gentooLTO - A Gentoo Portage configuration for building with -O3, Graphite, and LTO optimizations