<ambasta>
w0rm, is the pgo build supposed to work? Looking at meson, pgo is linking pgolib and syslibs, where pgolib itself builds from grid/selection/terminal.c
<w0rm>
ambasta: it does work for me...
<ambasta>
However, pgo executable doesn't link against fdm.c/render.c both of which are required by terminal.c?
<ambasta>
that is odd.. I get a '/home/amitprakash/foot/foot/builddir/../terminal.c:2268: undefined reference to `fdm_init''
<ambasta>
w0rm, could you provide a regular build log?
<dnkl>
ambasta: make sure you're doing a release build. The line you referenced is a unit test, only included in debug builds
<ambasta>
I am doing a debug build
<ambasta>
That doesn't support pgo?
<dnkl>
No
<ambasta>
I see
<dnkl>
(there's no point in pgo:ing a debug build)
<ambasta>
I was so confused, I couldn't see how people were building w/ PGO when clearly function references were missing (and none of the linked deps covered it)
<dnkl>
:)
<dnkl>
ambasta: you'll want to enable LTO (-Db_lto=true) as well. It isn't required, but improves performance even more
<ambasta>
dnkl, in which case, why does buildtype plain, trigger a debug build?
<ambasta>
Yeah, that bit is enabled
<dnkl>
ambasta: hmm, might be that the unit tests are enabled in non-release builds. I.e pain builds too
<dnkl>
Could even be that we define _DEBUG in that case, which is even worse
<ambasta>
Shouln't be though , is_debug_build = get_option('buildtype').startswith('debug') which then goes on to be used as (is_debug_build ? ['-D_DEBUG']: ....
<dnkl>
Yeah, just checked. Which means I have currently no idea why a plain build would include the unit tests. If that's what you said was happening...
<dnkl>
ambasta: on my phone right now, will have to check later
<ambasta>
Sure, shared for your reference
<ambasta>
will try to debug on my end as well
<emersion>
dnkl: may have, since the pixman renderer holds buffers for longer
<dnkl>
emersion: oh yeah, right, we end up hitting the double buffering path in foot... Yes, that will make *some* difference
<dnkl>
But I think the difference is minimal. We still run the rest of the renderer as usual. We'll end up optimizing the code that reapplies the previous frame's damage.
<dnkl>
The only sure fire way to find out is of course to benchmark. But I wouldn't worry about it
<w0rm>
even if you decide not to change/tweak - no big deal, people who would have a problem with the current state are probably few and far between
<w0rm>
I only found out when I was adding pgo to my custom ebuild and hit on the violation
<dnkl>
w0rm: I'll run your PR through our standard benchmarks. If it turns out to be a difference, we'll deal with it then
<w0rm>
ack
<w0rm>
Not sure how useful it would be - I've seen https://github.com/alacritty/vtebench being mentioned to test a bunch of aspects here and there but I am sure you've seen that already
<dnkl>
w0rm: that's what I use :)
<w0rm>
psst, don't tell anyone
<dnkl>
One can use the "generate-random-...py" script in the scripts dir as well... :)
<ambasta>
emer is here too.. do all wl project devs know each other =D
<w0rm>
it's a (not-so) secret cabal apparently...
<ambasta>
dnkl: Found the issue, project is configured with b_ndebug=if-release
<ambasta>
That would set DNDEBUG even when buildtype is plain
<dnkl>
ambasta: ah, and unit tests are enabled if NDEBUG isn't set, I assume?
<ambasta>
Yeah, verified w/ setting b_ndebug=True, that works correctly for buildtypes plain, debug and release
<ambasta>
i.e. debug pulls in the macro CONSTRUCTOR from unittest, while release/plain pull in UNUSED
<dnkl>
Ok, thanks, will look into that
ambasta has quit [Remote host closed the connection]
novakane has quit [Quit: WeeChat 3.3]
novakane has joined #foot
micr0 has joined #foot
micr0 has joined #foot
micr0 has quit [Ping timeout: 252 seconds]
<w0rm>
so foot is supposed to support IME however I could never get it to work... Not a huge deal since I don't currently need it but I wonder - is there some magic I am missing?
<w0rm>
specifically - fcitx 5.x, firefox and bunch of other apps work as expected
<dnkl>
w0rm: you need a compositor, and IME provider that both support the correct protocols
<w0rm>
right, I know there were changes to the versions etc
<dnkl>
Fcitx5 under sway sort of works, but no pre-edit
<w0rm>
I thought the ibus was still on old version
<w0rm>
so anyway - IME switching/input works in FF, Libreoffice, slack etc but not foot
<w0rm>
(and I did compile with +ime to be clear)
<dnkl>
Gtk apps talk to the IME over something other than Wayland protocols. But foot only supports the Wayland approach
<w0rm>
aha
<dnkl>
w0rm: anthywl and wlanthy are two IMEs that work. Though limited to Japanese...
<w0rm>
good enough for the mystery explanation for my case...
<dnkl>
Also, Sway still has no support for IME popups
<w0rm>
yeah, I needed more libpinyin
<dnkl>
Thus, no IME provided suggestion lists etc
<w0rm>
yeah, I guess the GTK apps working was confusing
<w0rm>
anyway, ty for explanation - it has been on my mind here and there