I’v been using ProfileView.jl for some time now, with success. However, recently, the display changed, and the tooltips and various other displayed strings started using some font which doesn’t have regular ASCII characters. Based on the codes in the little boxes, the characters it draws are fine, they just don’t have proper glyphs in the used font.
julia> using ProfileView; @profview rand(100,100) * rand(100,100)
I don’t really know if this was caused by a package upgrade or some of my other actions, but the issue seems to be persistent. I tried downgrading ProfileView to the previous, 1.8.1, version, it didn’t help.
I don’t even know where to start looking for the root cause. Whether this is an issue with Cairo.jl, or Gtk4.jl, or some of my own hidden settings…
I also get a warning when displaying the first profile window:
(julia:3208466): Gtk-WARNING **: 09:37:10.062: No IM module matching GTK_IM_MODULE=ibus found
But I’m guessing this is unrelated. Any help would be appreciated!
I think the GTK warning is saying that you have requested to use ibus, by setting the environment variable GTK_IM_MODULE to ibus, but ibus isn’t installed. I don’t know if this is related, however it can be a serious issue, I remember @Oscar_Smith used to have the same warning and it made his ProfileView.jl segfault. Try either installing ibus or unsetting the environment variable.
It appears to be a lack of font support. The “characters” are tofu/character-not-supported/.notdef glyphs. They may appear as rectangles or filled diamonds, possibly blank or with things like ? or X in the middle. In this case, it seems to be a rectangle holding codepoints, or rather attempts. I had to use some substitute characters for the failed codepoints, but here’s part of the characters:
I can guess that’s trying to say All Threads, compiler/typeinfer.jl, MethodInstance, typeinf_edge, line 923. Never used ProfileView so I don’t know if those are supposed to show up there.
Yeah, totally, that’s what I also wrote in the post itself. What’s odd is that it worked well until about two days ago, and then yesterday, it went poof. I will try a restart, maybe it will solve the issue.
Did you upgrade any font intentionally (meaning from outside of Julia likely)? Are you on Windows (or which platform, I’m not implicating, just asking), and which font do you think you’re using?
I would think this is a bug, i.e. in some upgraded (or downgraded) package dependency, so it would be nice if you have some old Manifest.toml file to test. But I’m not sure if the packages provide fonts, i.e. a given dependency always uses the same one, or refers to some system install.
I tried unsetting the envvar, the warning disappeared, but the issue remained.
I checked the overriding document, but it doesn’t seem trivial, because the system layout of the gtk4 lib differs significantly from the artifact’s. Hence it is not just a matter of 3ee0f31a7c7548d37e6bf688b682c088c50f506f = "/usr"
No, I haven’t touched the fonts. This is a Debian 12 system, with Gnome desktop. I have no idea what the font picked by ProfileView/Gtk in this case could be. Otherwise, I’m using Gnome default system fonts.
Reboot didn’t help. I tried it with a fresh depot, to make sure that it’s not caused by a corrupted artifact or precompiled lib, using Julia 1.11.2:
$ JULIA_DEPOT_PATH=/tmp/julia julia
julia> using Pkg; Pkg.add("ProfileView"); using ProfileView
...
julia> @profview rand(100,100) * rand(100,100)
Still wrong. The same thing happens with Julia 1.10 as well.
For some reason, Gtk4.jl v0.7.2 is installed, as opposed to the newest v0.7.4. Pkg.status() says that it can be upgraded, but Pkg.upgrade() doesn’t do anything with it. If I manually set its version to v0.7.4, however, it is able to install it:
(@v1.11) pkg> st --outdated -m
Status `/tmp/julia/environments/v1.11/Manifest.toml`
⌃ [9db2cae5] Gtk4 v0.7.2 (<v0.7.4)
⌅ [e9f186c6] Libffi_jll v3.2.2+2 (<v3.4.6+4): Glib_jll, HarfBuzz_jll, Wayland_jll
⌅ [30392449] Pixman_jll v0.43.4+0 (<v0.44.2+0): Cairo_jll
⌅ [b53b4c65] libpng_jll v1.6.40+0 (<v1.6.46+0): Gtk4
(@v1.11) pkg> up -m
Updating registry at `/tmp/julia/registries/General.toml`
No Changes to `/tmp/julia/environments/v1.11/Project.toml`
No Changes to `/tmp/julia/environments/v1.11/Manifest.toml`
(@v1.11) pkg> up Gtk4
Updating registry at `/tmp/julia/registries/General.toml`
No Changes to `/tmp/julia/environments/v1.11/Project.toml`
No Changes to `/tmp/julia/environments/v1.11/Manifest.toml`
(@v1.11) pkg> up Gtk4 @0.7.4
Updating registry at `/tmp/julia/registries/General.toml`
No Changes to `/tmp/julia/environments/v1.11/Project.toml`
No Changes to `/tmp/julia/environments/v1.11/Manifest.toml`
(@v1.11) pkg> up -m Gtk4 @0.7.4
Updating registry at `/tmp/julia/registries/General.toml`
No Changes to `/tmp/julia/environments/v1.11/Project.toml`
No Changes to `/tmp/julia/environments/v1.11/Manifest.toml`
(@v1.11) pkg> add Gtk4@0.7.4
Resolving package versions...
Installed Pango_jll ─ v1.54.1+0
Installed Gtk4 ────── v0.7.4
Downloaded artifact: Pango
Updating `~/.julia/environments/profile/Project.toml`
[9db2cae5] + Gtk4 v0.7.4
Updating `~/.julia/environments/profile/Manifest.toml`
[9db2cae5] ↑ Gtk4 v0.7.2 ⇒ v0.7.4
⌅ [36c8627f] ↓ Pango_jll v1.55.5+0 ⇒ v1.54.1+0
Info Packages marked with ⌅ have new versions available but compatibility constraints restrict them from upgrading. To see why use `status --outdated -m`
Precompiling project...
10 dependencies successfully precompiled in 46 seconds. 132 already precompiled.
And if I load ProfileView after this, the texts display correctly!
Now I don’t know why Pango_jll.jl prohibits the use of the newest version of Gtk4.jl. Here is what Pkg.why() says, although this doesn’t really help:
That sort of explains it. What I still don’t get, though, is why the package manager decides to upgrade Pango_jll and keep Gtk4 downgraded, and not vice versa. Gtk4 is a more direct dependency of my manually added package than Pango_jll. I guess don’t understand how the version resolution works in Pkg.jl.
Anyhow, I added a comment to the (closed) Gtk4 PR to explain the situation.
