🐛 [bat warning]: Unknown theme 'Monokai Extended' #1075
Comments
|
Probably a reincarnation of #895. |
|
Similar issue also with bat 0.21.0. Probably due to this:
|
|
Facing the same error when running I temporarily fixed it by: |
|
Hi all, I think these errors are related to the bat cache and that @rashil2000 has the right fix: can you try installing a recent version of To be clear, delta does not use the |
|
So rebuilding the [bat warning]: Unknown theme 'gruvbox-dark', using default.
thread 'main' panicked at 'something is very wrong if the default theme is missing', /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_textproc_git-delta/git-delta/work/.home/.cargo/macports/bat-0.20.0/src/assets.rs:204:22Took me a minute, but it's looking for |
|
It seems like the cache that |
|
Hm, thanks, maybe I need to update the bat Rust library used by delta. (It's not bat's fault btw -- delta is using their on-disk cache, which is not a public API! So delta is getting what it deserves in the form of these backwards-incompatibility problems. On the plus side, the bat developers have told me informally that such breaking changes will be rare; and delta gets a lot of utility from sharing that cache. I believe they did warn me earlier this year that this second breaking change was coming up.)
Just to make sure we're all on the same page, delta does not have any run time dependency on bat: the delta executable works without bat being installed. But delta does use bat as a Rust library, and indeed, it uses Line 18 in a53dc02 I assume MacPorts is compiling the Rust code on your machine? In that case I think it's all fine and proper that MacPorts has v0.20.0 of that Rust library on your system: it's just some Rust library it needs privately to build delta, and is unrelated to any bat executable you may or may not have. |
|
I've pushed an update to master which updates the bat library that delta uses. I'll try to release it shortly. So, if you are able to install from master, then it will work with latest bat (v0.21) after running |
|
Thx @dandavison - I've encountered this problem since my bat cache is v0.21. After rebuilding delta from master, this is fixed. |
|
Yes, thanks so much, latest build works great. |
|
Homebrew waiting on Homebrew/homebrew-core#101419 |
|
This is fixed in the latest release (which is now available in homebrew). Thanks everyone for the help here. |
Is it possible to reconsider this strategy? Because of this implicit, runtime dependency it makes it so anyone using If the utility provided by using a single cache for |
|
Hi @kschat,
Certainly possible. A downside is that it would be (semantically, if not in bytes) identical to the bat cache -- a user wanting to create a custom syntax theme or language grammar would have to do it in both places (the chances are that such a user would be using both applications).
I honestly think there may be good news there -- I believe that bat is not planning to make more backwards incompatible changes to their cache format. There have only been two during delta's existence, and both recent since there was a pulse of bat development aimed at lazy-loading assets (from which delta benefits!).
Yes, and I'd be happy to receive PRs in this area. I don't think I'd want to try to start a bat process on every delta startup, but maybe we could simply improve the error message that results? |
I personally don't think that's a con (but others likely disagree). I actually find it surprising that upgrading the cache of one disparate application affects another, seemingly unrelated application. I understand that under the hood
That is good news, and perhaps I'm making a bigger deal out of this than needed.
Great! I won't make any promises of being able to do this soon, but it's something I'm happy to contribute when I find the time. Speaking of time, thanks for yours and
Yeah, totally. Perhaps it could be a first time check that is cached? Or maybe there's a heuristic that can be used to determine the current version of |
Yes, I don't disagree with you. I don't want to give the impression that this is really by design. It's more that, to recreate the cache lifecycle management functionality, I'd have to vendor a bunch of code from bat (or help them move it into the bat library, if that made sense). And while there is some vendored bat code, it's very little now due to the bat Rust library. But I think possibly I, and maybe the bat devs, feel that a separate library dedicated to managing the syntax highlighting assets could make more sense ultimately than that being in the bat crate. So all in all, as you can imagine, it's easier, for a side project, to leave it be and try to deal with the backwards incompatible upgrades with minimal disruption to my users! |
|
There is a metadata.yml file in the cache that you could use. See here: for the bat code for this check. Disclaimer: This is not a commitment to keep the format of that file stable over time (see e.g. sharkdp/bat#2085). But it should work for the foreseeable future. |
Sure, I understand and empathize with that stance. I had some downtime at work today, so I took a quick stab at it. @Enselic the code you linked was very helpful, thanks for it. Unfortunately I'm stuck on getting the current built version of @dandavison if there isn't a programmatic way of getting the current built version of |
|
@kschat the main thing I am reluctant to do is read files at delta start time. |
|
Can you explain what you would be reading from a (a) I'm not convinced that it's going to happen frequently But I would like to make error messages as helpful as possible. |
|
Sure. In order to use the If you're opposed to a build script, I can open a PR against |
|
I see, thanks. Right, this change does seem quite attractive then seeing as bat has the
Unless @Enselic says in this thread that they would not be interested in that change, could you look into that possibility? I see that bat has a build script already and that it might be a relatively small change (though of course, only really justified if it might be useful to other bat crate users). |
|
I'm not sure exposing the version from bat would help much, because the version is for bat-as-a-library, and not for binary assets. In other words, we can expect the bat 0.x.0 version to be increased without binary assets becoming incompatible. My thinking goes like this:
Based on the above, delta could have a user-friendly check of compatibility. So the way I see it, there is no need for new APIs in bat. |
|
Hey sorry to hijack this as it should be solved but I'm running bat 0.20.0 (just noting even though apparently it doesn't matter) and delta 0.13.0 and I still get the message: I'm running Arch and installed both from the community repo ( |
|
@Frederick888 I'm not sure what you mean. Can you elaborate? |
You need to either update bat to 0.21.0 or roll delta back to 0.12.1. |
|
Ah yeah, thanks! Sorry I got lost in this thread somehow. So just to clarify (also for others): The issue is not your installed As 0.21.0 of bat was not available in the Arch repos at the time of writing I resolved to installing it using cargo directly. |
AFAIU to be accurate it happens when there's some breaking change in |
|
@Enselic I might be misunderstanding what |
|
The problem with I'm thinking the best short-term fix for delta is to parse the yml yourself (which is close to trivial) and then simply add a check "if binary assets come from bat v0.20.0, then print an error message", since we know that the latest version of delta is incompatible with bat v0.20.0 assets. It is not possible today to say if bat v0.22.0 assets will be compatible or not with bat v0.21.0 assets. But right now it looks like they will be compatible. The right long-term fix here seems to me to be to make bat properly version its binary files format separately from the bat-as-a-library version, and expose the necessary API for clients to make their own checks. Assuming we want binary files to be part of the API at all, which is not self-evident. This is all my personal opinions and thoughts. I have not synced with other bat maintainers about this yet. |
FWIW, here is an updated PKGBUILD you can install with # Maintainer: Alexander F. Rødseth <xyproto@archlinux.org>
# Contributor: Wesley Moore <wes@wezm.net>
pkgname=bat
pkgver=0.21.0
pkgrel=1
pkgdesc='Cat clone with syntax highlighting and git integration'
arch=(x86_64)
url='https://github.com/sharkdp/bat'
license=(APACHE MIT)
depends=(gcc-libs libgit2 oniguruma)
makedepends=(clang cmake git rust)
source=("git+$url#commit=405e5f7") # tag: v0.21.0
b2sums=('SKIP')
prepare() {
cargo fetch \
--locked \
--manifest-path "$srcdir/$pkgname/Cargo.toml"
}
build() {
export CFLAGS+=' -ffat-lto-objects -w'
cargo build \
--locked \
--manifest-path "$srcdir/$pkgname/Cargo.toml" \
--release
}
# check() {
# cargo test \
# --locked \
# --manifest-path "$srcdir/$pkgname/Cargo.toml"
# }
package() {
install -Dm755 $pkgname/target/release/$pkgname "$pkgdir/usr/bin/$pkgname"
# Package licenses
install -Dm644 $pkgname/LICENSE-APACHE \
"$pkgdir/usr/share/licenses/$pkgname/LICENSE-APACHE"
install -Dm644 $pkgname/LICENSE-MIT \
"$pkgdir/usr/share/licenses/$pkgname/LICENSE-MIT"
cd $pkgname/target/release/build
# Find and package the man page (because cargo --out-dir is too new)
find . -name bat.1 -type f -exec install -Dm644 {} \
"$pkgdir/usr/share/man/man1/bat.1" \;
# Find and package the zsh completion file (not in zsh-completions yet)
find . -name bat.zsh -type f -exec install -Dm644 {} \
"$pkgdir/usr/share/zsh/site-functions/_bat" \;
# Find and package the fish completion file
find . -name bat.fish -type f -exec install -Dm644 {} \
"$pkgdir/usr/share/fish/vendor_completions.d/bat.fish" \;
}(I had to disable the tests as they were failing for me, didn't feel like investigating in detail) |
Thank you for delta.
It was working fine for me for a long time and then recently it stopped working.
Perhaps some update with bat or something on my end.
Running delta on any two files now reports -
% delta file1 file2
[bat warning]: Unknown theme 'Monokai Extended', using default.
thread 'main' panicked at 'something is very wrong if the default theme is missing', /home/kellma02/.cargo/registry/src/github.com-1ecc6299db9ec823/bat-0.20.0/src/assets.rs:204:22
% delta --version
delta 0.12.2 - latest ToT built - commit a53dc02
% bat --version
bat 0.20.0 (dc7d5a8) - also latest ToT built
OS:
linux 5.13.0-41 (ubuntu 20.04 + hwe)
ok, seems like a bat problem. But bat alone for me seems ok.
I cannot get bat by itself to fail like this. Should I submit this to bat ?
% bat --theme "Monokai Extended" file1
works ok.
% bat --list-themes shows the theme is present -
Theme: Monokai Extended
A full stack trace from the delta cmdline is -
stack backtrace:
0: 0x5614e7351b7d - std::backtrace_rs::backtrace::libunwind::trace::hee598835bc88d35b
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
1: 0x5614e7351b7d - std::backtrace_rs::backtrace::trace_unsynchronized::h9cdc730ba5cf5d72
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2: 0x5614e7351b7d - std::sys_common::backtrace::_print_fmt::h75aeaf7ed30e43fa
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/sys_common/backtrace.rs:66:5
3: 0x5614e7351b7d - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h606862f787600875
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/sys_common/backtrace.rs:45:22
4: 0x5614e737902c - core::fmt::write::he803f0f418caf762
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/fmt/mod.rs:1190:17
5: 0x5614e734cc28 - std::io::Write::write_fmt::h70bc45872f37e7bb
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/io/mod.rs:1657:15
6: 0x5614e7353ee7 - std::sys_common::backtrace::_print::h64d038cf8ac3e13e
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/sys_common/backtrace.rs:48:5
7: 0x5614e7353ee7 - std::sys_common::backtrace::print::h359300b4a7fccf65
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/sys_common/backtrace.rs:35:9
8: 0x5614e7353ee7 - std::panicking::default_hook::{{closure}}::hf51be35e2f510149
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:295:22
9: 0x5614e7353bb0 - std::panicking::default_hook::h03ca0f22e1d2d25e
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:314:9
10: 0x5614e7354639 - std::panicking::rust_panic_with_hook::h3b7380e99b825b63
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:698:17
11: 0x5614e7354327 - std::panicking::begin_panic_handler::{{closure}}::h8e849d0710154ce0
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:588:13
12: 0x5614e7352044 - std::sys_common::backtrace::__rust_end_short_backtrace::hedcdaddbd4c46cc5
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/sys_common/backtrace.rs:138:18
13: 0x5614e7354039 - rust_begin_unwind
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:584:5
14: 0x5614e7092cf3 - core::panicking::panic_fmt::he1bbc7336d49a357
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/panicking.rs:143:14
15: 0x5614e7377ad1 - core::panicking::panic_display::hb184394d54dc8360
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/panicking.rs:73:5
16: 0x5614e7377a7b - core::panicking::panic_str::ha42887cd972750c9
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/panicking.rs:56:5
17: 0x5614e7092b66 - core::option::expect_failed::h9159c9d16ed9fb7c
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/option.rs:1852:5
18: 0x5614e7203cce - bat::assets::HighlightingAssets::get_theme::hc7467125c4edc0ea
19: 0x5614e70dc4a8 - delta::options::theme::set__is_light_mode__syntax_theme__syntax_set::h677759c10e43ad69
20: 0x5614e715b390 - delta::options::set::set_options::h8d58af2bf0c84dcf
21: 0x5614e7095c1f - delta::cli::Opt::from_clap_and_git_config::h61c2a01edb15a7ff
22: 0x5614e709599f - delta::cli::Opt::from_args_and_git_config::hdbf699dc115ec9e4
23: 0x5614e7175084 - delta::main::hf4df0a35130e1bc7
24: 0x5614e71291c3 - std::sys_common::backtrace::__rust_begin_short_backtrace::h62d7051c2c241ccc
25: 0x5614e717791d - std::rt::lang_start::{{closure}}::hcdf5d85a768ff03e
26: 0x5614e7351261 - core::ops::function::impls::<impl core::ops::function::FnOnce for &F>::call_once::hb7014f43484a8b4e
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/ops/function.rs:259:13
27: 0x5614e7351261 - std::panicking::try::do_call::h7bc9dc436daeb8c7
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:492:40
28: 0x5614e7351261 - std::panicking::try::h653d68a27ff5f175
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:456:19
29: 0x5614e7351261 - std::panic::catch_unwind::h9d739f9f59895e68
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panic.rs:137:14
30: 0x5614e7351261 - std::rt::lang_start_internal::{{closure}}::hf006f2bc7ce22bbe
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/rt.rs:128:48
31: 0x5614e7351261 - std::panicking::try::do_call::hfb39d6df61a2e69f
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:492:40
32: 0x5614e7351261 - std::panicking::try::h13e2d225134958ac
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:456:19
33: 0x5614e7351261 - std::panic::catch_unwind::h3bd49b5a5dfb1a50
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panic.rs:137:14
34: 0x5614e7351261 - std::rt::lang_start_internal::h2ba92edce36c035e
at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/rt.rs:128:20
35: 0x5614e71787c2 - main
36: 0x14d5f048b0b3 - __libc_start_main
at /build/glibc-sMfBJT/glibc-2.31/csu/../csu/libc-start.c:308:16
37: 0x5614e709352e - _start
Is there anything else I can provide ?
thx,
-m
The text was updated successfully, but these errors were encountered: