Blinking spawn process on Windows

[gavr123456789]

Describe the bug
Each update of the project symbols causes the opening and closing processes to blink. They take over the focus that interrupts autocomplete.
I think its symbol extractor.

Software
OS and version (e.g. Ubuntu 20.04): Windows
Code editor (e.g. VSCode): VSCode
Vala Language Server (e.g. git commit, or PPA/AUR version): 0.48
Vala version (valac --version): 0.48.6

https://youtu.be/r3sY2NzDyiI

A temporary solution may be the ability to disable it in the client settings.

[Prince781]

I don't see how this has anything to do with VLS.

[gavr123456789]

@taozuhong do you have something similar?

[taozuhong]

yeah, me too. it's serious for the user.

Steps to reproduce:
Step 1. Enable extension, restart vscode, open project, cmd.exe window splashed twice
Step 2. Open a vala file, cmd.exe window splashed twice again.
Step 3. Input word chars, like: m_tab_work_books, while input the underline(_), wait about one second, cmd.exe window splashed twice again; repeat this as follows.
It will disappear while input chars continually, that's it.

BTW, I am tracking the change of VLS every day, but not yet use it in my project(using vala extension), because vala-code does not implement the template and context autocomplete of vala file.

fighting, friends.

[gavr123456789]

I think here it is
https://github.com/benwaffle/vala-language-server/blob/bd64b248fd94fc8ed1dd6a6d29f2e8ffc4c20bda/src/projects/mesonproject.vala#L148

[Prince781]

Hmm..there does seem to be a problem with path resolution under Windows, caused by 0aa20ba (found by bisecting).

[Prince781]

When I said VLS doesn't spawn a process for completion, that was correct. It does however spawn processes when initially setting up the Meson project. Perhaps issues with path resolution on Windows are causing the Meson project setup to be run multiple times.

[Prince781]

@gavr123456789 @taozuhong tell me if #121 fixes your issue (checkout the branch bug/windows-path-resolution)

[taozuhong]

not yet, the behavior same as the master branch.

[gavr123456789]

This is fun

Found ninja.EXE-1.10.0 at C:\msys64\mingw64\bin/ninja.EXE

ERROR: Clock skew detected. File C:/msys64/home/gavr/vala-language-server-bug-windows-path-resolution/build/../meson.build has a time stamp 9665.5390s in the future.

A full log can be found at C:/msys64/home/gavr/vala-language-server-bug-windows-path-resolution/build/meson-logs/meson-log.txt

[Prince781]

It seems the issues with dependencies on Windows are also fixed by the commit. However, I wasn't abl to reproduce the stuttering/flickering.

https://i.imgur.com/Omwifwj.gif

[taozuhong]

this is the screen recorder of vscode under MSYS2
vscode.zip

[Prince781]

@taozuhong, from this frame, it looks like the process being spawned is pkg-config. As VLS does not run pkg-config directly, this is done by the Vala compiler when checking for deprecated symbols.

Just curious, are you able to downgrade to Vala 0.48.3 on your MinGW installation? If so, then try running VLS with your project. It's possible that this commit (GNOME/vala@2ad4a6e) to Vala is responsible.

[Prince781]

@taozuhong @gavr123456789 Just to be clear, I think the behavior you're seeing is a result of Vala doing the right thing now, after a bug fix that I made for a separate issue. It seems that this might also be a new issue that was exposed. A temporary workaround right now might be to add --disable-since-check as a flag to all of the targets in your build system like below (for Meson):

if host_machine.system() == 'windows'
    # disable since check on Windows
    add_project_arguments(['--disable-since-check'], language: 'vala')
endif

[Prince781]

@taozuhong @gavr123456789 you can try downgrading to a Vala version before 0.48.3 by looking in /var/cache/pacman/pkg, where previously-installed packages are cached.

[taozuhong]

Exactly right, the Vala 0.48.3 is silent, and just splash the cmd.exe window once(not yet add the flag you mentioned).

[Prince781]

It seems what has also happened is that an update to other packages in MSYS2 changes the behavior of Process.spawn_*() and similar functions so that VLS cannot read the output of meson --version when running as a child process of VSCode.

[taozuhong]

the experience of VSCode on windows is back to bad again:
crashed, window flash, responsible slowly

I have to disable it. do you try it on windows?

[Prince781]

@taozuhong I test VLS on Linux and Windows, but I develop most of the time on Linux. I make sure to periodically test VLS on Windows after certain changes that I think might cause problems.

[Prince781]

@taozuhong can you post the output of VLS?

[Prince781]

@taozuhong There shouldn't be any crashes in VLS. I just test-ran the master branch with updated MSYS packages and there are no crashes. But there are issues with spawning Meson and of course there's still the issue with console windows being created when spawning subprocesses.

[taozuhong]

pls keep up making a great experience.

[gavr123456789]

So, we have to start doing something. I'm not sure if I need to create an issue in Vala or GLib. This is a very serious problem, VLS is not usable under windows as long as it exists.

[Prince781]

@gavr123456789 Agreed. After testing this with other programs that use GLib I've concluded this is a problem with how GLib spawns processes on Windows. The ultimate fix lies there, but perhaps if it takes too long to be fixed I could come up with a temporary hack in VLS that would minimize the problem (but not make it go away completely).

[Prince781]

@gavr123456789 I have an idea of how to fix this in GLib. Right now I'm finishing up symbol rename support with some edge cases. Give me a few days to start working on this issue.

[Prince781]

Just letting you know I haven't forgotten about this issue. I've opened a MR in GLib that I think will solve it:

https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1662

[gavr123456789]

Just checked win32 workaround branch, it doesnt help, still blinking (

[Prince781]

@gavr123456789 the win32-workaround branch only helps with launching meson from VLS. It doesn't change what libvala does with pkg-config.

If you want to test the fix in GLib, you can try installing this package I've built:
https://www.dropbox.com/s/oofngh6z897y471/mingw-w64-x86_64-glib2-2.66.1-1-any.pkg.tar.zst

If that doesn't work, try these steps in msys2 (you can use this to rebuild glib2 when it gets updated):

1. clone the MINGW-packages repository

git clone https://github.com/msys2/MINGW-packages

2. from msys2 terminal, install patch
3. then cd into MINGW-packages/mingw-w64-glib2
4. then edit the PKGBUILD, changing the first value in source=(...) to git+https://gitlab.gnome.org/Prince781/glib. At the same time, make sure to set the first hash value in sha256sums=(...) array to 'SKIP'
5. then change all instances of ${srcdir}/glib-${pkgver} to ${srcdir}/glib in the PKGBUILD
6. then in the prepare() { ... } function add the following line:

git checkout wip/prince781/fix-gspawn-terminal-win32

7. finally, build the package by running makepkg -s

Or you can just apply this patch instead of steps 4-6:
https://gist.github.com/Prince781/f526b5e5a379f365776851214639c8c5

[gavr123456789]

Ty, that woks! (that glitch only on record)
(for others, just pacman -U ....zst)

[Prince781]

Just letting you know I haven't forgotten about this issue. I've opened a MR in GLib that I think will solve it:

https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1662

While this MR is still in progress, I've rebuilt mingw-w64-x86_64-glib2 with the latest version of GLib and the patch. You can get it here:
mingw-w64-x86_64-glib2-2.68.1-1-any.pkg.tar.zip (you need to unzip it first—GitHub won't let me send a .pkg.tar file)

[Prince781]

My PR has been merged into GLib upstream. I think I can close this bug. Until the latest version of GLib lands in MinGW you can use the package I've built.

[Project-Magenta]

Thank you