text:
Specific theme for profile

Windows Terminal version
1.21.2701.0
Windows build number
10.0.22621.0
Other Software
No response
Steps to reproduce
I know I can create multiple themes and define which one to use like this:
"theme": "dark"
"themes":
[
    {
      "name": "dark",
      "window": {
          "applicationTheme": "dark"
      },
      "tab": {
          "background": "terminalBackground",
          "unfocusedBackground": "#00000000"
      },
      "tabRow": {
          "unfocusedBackground": "#333333FF"
      }
  }
]

But how do I assign a different theme to a profile (as I do with the colorScheme), I want the window color to be integrated, if this is in WSL everything should be orange and if I am in PowerShell Black, I have not achieved it, but I think it is possible because in this link, there is a gif that does exactly this:
https://learn.microsoft.com/en-us/windows/terminal/custom-terminal-gallery/theme-gallery

Expected Behavior
In Powershell the tabs and windows are blue, in Ubuntu purple, and in cmd black.
Actual Behavior
My config is as follows
"profiles": {
    "defaults": { "colorScheme": "Everblush" }
"list": [
{
        "commandline": "pwsh.exe -nologo",
        "guid": "{59e30915-7255-4c37-aac8-65e9eb49caa6}",
        "hidden": false,
        "icon": "ms-appx:///ProfileIcons/pwsh.png",
        "name": "PowerShell",
        "startingDirectory": "%USERPROFILE%"
      },
{
        "guid": "{10e14319-4cbb-4efc-95f8-4d48fdafdb75}",
        "name": "Plex",
        "icon": "%USERPROFILE%\\Pictures\\icons\\plex.ico",
        "hidden": false,
        "commandline": "ssh -i %USERPROFILE%\\.ssh\\private pw@localhost",
        "colorScheme": "Plex",
        "theme": "Plex" // This line has no effect, I want use only for this profile
      },
{
...
"themes": [
    {
      "name": "Everblush", // This is global theme
      "tab": {
        "background": "#141B1EFF",
        "iconStyle": "default",
        "showCloseButton": "always",
        "unfocusedBackground": "#232A2DFF"
      },
      "tabRow": {
        "background": "#232A2DFF",
        "unfocusedBackground": "#232A2DFF"
      },
      "window": {
        "applicationTheme": "dark",
        "experimental.rainbowFrame": false,
        "frame": null,
        "unfocusedFrame": null,
        "useMica": false
      }
    },
    {
      "name": "Plex", // Theme for only Plex profile
      "tab": {
        "background": "#141B1EFF",
        "iconStyle": "default",
        "showCloseButton": "always",
        "unfocusedBackground": "#232A2DFF"
      },
      "tabRow": {
        "background": "#232A2DFF",
        "unfocusedBackground": "#232A2DFF"
      },
      "window": {
        "applicationTheme": "dark",
        "experimental.rainbowFrame": false,
        "frame": null,
        "unfocusedFrame": null,
        "useMica": false
      }
    }
}

To address the issue you're encountering with assigning different themes to profiles in Windows Terminal, follow these steps:
1.Check the Configuration: Ensure your configuration is correctly formatted. Your JSON should be valid, and all brackets should match. Pay attention to commas between objects.
2.Profile-Specific Theme: The theme property is not currently supported for profiles in Windows Terminal. Instead, you should use the colorScheme property to define colors for each profile. Themes are global and cannot be assigned per profile directly.
3.Define Color Schemes: You can create specific color schemes that reflect the desired colors for each profile. Here’s an example of how to define a color scheme for your PowerShell and Plex profiles:
"schemes": [
    {
        "name": "PowerShell",
        "background": "#000000",
        "foreground": "#FFFFFF",
        "black": "#000000",
        "red": "#FF0000",
        "green": "#00FF00",
        "yellow": "#FFFF00",
        "blue": "#0000FF",
        "purple": "#800080",
        "cyan": "#00FFFF",
        "white": "#FFFFFF",
        "brightBlack": "#808080",
        "brightRed": "#FF5555",
        "brightGreen": "#50FA7B",
        "brightYellow": "#F1FA8C",
        "brightBlue": "#BD93F9",
        "brightPurple": "#FF79C6",
        "brightCyan": "#8BE9FD",
        "brightWhite": "#FFFFFF"
    },
    {
        "name": "Plex",
        "background": "#141B1EFF",
        "foreground": "#FFFFFF",
        // Define other colors as needed
    }
],

4.Assign Color Schemes to Profiles: Then, assign these color schemes to your profiles like this:
"profiles": {
    "list": [
        {
            "guid": "{59e30915-7255-4c37-aac8-65e9eb49caa6}",
            "name": "PowerShell",
            "commandline": "pwsh.exe -nologo",
            "colorScheme": "PowerShell",
            "hidden": false,
            "icon": "ms-appx:///ProfileIcons/pwsh.png",
            "startingDirectory": "%USERPROFILE%"
        },
        {
            "guid": "{10e14319-4cbb-4efc-95f8-4d48fdafdb75}",
            "name": "Plex",
            "commandline": "ssh -i %USERPROFILE%\\.ssh\\private pw@localhost",
            "colorScheme": "Plex",
            "hidden": false,
            "icon": "%USERPROFILE%\\Pictures\\icons\\plex.ico"
        }
    ]
}

5.Testing: After making these changes, save your settings and restart Windows Terminal to see if the profiles reflect the correct colors.
6.Creating an Issue on GitHub: If you believe this functionality (assigning themes per profile) should be supported, you can create an issue on the Windows Terminal GitHub repository. Provide a clear description of your use case, the current behavior, and your expected behavior.
7.Follow Up: Engage with any responses on the GitHub issue to provide additional context or answer questions from the maintainers.

"tabRow": {
       "background": "#232A2DFF",

If you set the background to terminalBackground, just like in your first post, it will use the same color as the profile.

authors: DHowett ketan270 pwsandoval


text:
Symbols with error, when updated the windows terminal

In a previous version it was working, however when it updated it stopped working.

Could you share what those glyphs are supposed to be?

@zadjii-msft

Apart from the small emoji (#900), it looks like these are working fine.

Can you make sure your MSYS profile specifies bash.exe --login -i or something equivalent? We've had a bunch of issues with that lately.
Resolving external since this seems to work outside msys/vue.

The settings are the same as the documentation
https://github.com/microsoft/terminal/blob/master/doc/user-docs/ThirdPartyToolProfiles.md
{     "name" : "Git Bash",     "commandline" : "C:/Program Files/Git/bin/bash.exe -li",     "icon" : "C:/Program Files/Git/mingw64/share/git/git-for-windows.ico",     "startingDirectory" : "%USERPROFILE%" }
I did the tests on other terminals (CMD, Cmder and Power Shell) and had the same problem.

All the applications depicted above are using the legacy input line. I'd be interested in seeing emoji output under those three shells.

In cmder, when I insert the emoji it appears normal, but when I remove selection the emoji disappears

source: gharchive/issue

repo: microsoft/terminal

license: MIT

license_type: permissive

license_source: github-api


text:
About box is not modal / masked improperly. Unexpectedly allows text entry behind it.

Environment
Windows build number: 10.0.19041.0
Windows Terminal version (if applicable): 0.11.1251.0

Any other software?
Using focus-follows-mouse

Steps to reproduce
Open a terminal.
click on the down arrow and bring up the about box.

Method 1: resize the terminal horizontally so it's wider than the original terminal width.
Method 2: resize the terminal vertically so it's taller than the original terminal width.

near the right edge you can see the lighter grey section. If you put your cursor there, you can enter text at the cursor (in the picture, you can see I added "hello covid-19")

similarly, when resized vertically, entering text in the light grey section works.

Once you've entered text in the textarea:
Pressing ESC in the light grey section doesn't close the About box.
Pressing ESC in the dark grey section outside the About box doesn't close the About box.
Pressing ESC anywhere doesn't close the About box.
The only way to dismiss the About box is to click the OK.

Expected behavior
The about box should be modal, it should not be possible to enter text behind it.
But perhaps, resizing the terminal should close the About box. Avoiding this issue.

Actual behavior

Thanks for the report! This is actually already being tracked by another issue on our repo - please refer to #2380 for more discussion.
/dup #2380

authors: fishzle zadjii-msft


text:
Add support for setting the cursor visibility in Terminal

Adds support for setting the cursor visibility in Terminal. Visibility
is a property entirely independent from whether the cursor is "on" or
not. The cursor blinker should change the "IsOn" property. It was
actually changing the "Visible" property, which was incorrect. This PR
additionally corrects the naming of the method used by the cursor
blinker, and makes it do the right thing.
I added a pair of tests, one taken straight from conhost. In
copy-pasting that test, I took it a step further and implemented
^[[?12h, ^[[?12l, which enables/disables cursor blinking, for the
TerminalCore. THIS DOES NOT ADD SUPPORT FOR DISABLING BLINKING IN THE
APP. Conpty doesn't emit the blinking on/off sequences quite yet, but
when it does, the Terminal will be ready.
References

I'd bet this conflicts with #2892
This isn't a solution for #1379
There shockingly isn't an issue for cursor blink state via conpty...?

PR Checklist

[x] Closes #3093
[x] Closes #3499
[x] Closes #4644
[x] I work here
[x] Tests added/passed
[n/a] Requires documentation to be updated

@msftbot merge this in 1 minute

source: gharchive/pull-request

authors: DHowett-MSFT zadjii-msft


text:
Adjust til::color's COLORREF conversion to be more optimal

Clang (10) has no trouble optimizing the COLORREF conversion operator to
a simple 32-bit load with mask (!) even though it's a series of bit
shifts across multiple struct members.
MSVC (19.24) doesn't make the same optimization decision, and it emits
three 8-bit loads and some shifting.
In any case, the optimization only applies at -O2 (clang) and above.
In this commit, we leverage the spec-legality of using unions for type
conversions and the overlap of four uint8_ts and a uint32_t to make the
conversion very obvious to both compilers.

x86_64 msvc
O0
O1
O2

shifts
12
11
11 (fully inlined)

union
5
1
1 (fully inlined)

x86_64 clang
O0
O1
O2 + O3

shifts
14
5
1 (fully inlined)

union
9
3
1 (fully inlined)

@j4james brought up some concerns about til::color's minor wastefulness
in https://github.com/microsoft/terminal/pull/7578#discussion_r487355989.
This is a clear, simple transformation that saves us a few instructions
in a relatively common case, so I'm proposing a micro-optimization even
though we don't have data showing this to be a hot spot.

Poke around at the implementation here:
https://godbolt.org/z/oWvj6z

You work on the weirdest things in your free time 😄

@zadjii-msft HA! haha. You know, you're right about that.

@DHowett This is awesome! Thank you for doing this.

@j4james Thanks for being a champion for perf here! :smile:

authors: DHowett j4james zadjii-msft


text:
Add splitMode to the args for split-pane

[x] Closes https://github.com/microsoft/terminal/issues/9579
[x] CLA signed.
[ ] Tests added/passed
[ ] Documentation updated - waiting for approval
[ ] Schema updated.
[ ] I've discussed this with core contributors already.

Beautiful, thanks!

authors: DHowett Don-Vito


text:
@autoInjectable() and @singleton() can't use together.

I have one class like this.
@autoInjectable()
@singleton()
export class AppEventEmitterService extends EventEmitter {
    private readonly logger: Logger

    constructor(private loggerService?: LoggerService) {
...

I created like this because I need to log on each event that emit and this class will using across of app. Problem that I found is this class will don't be singleton if I add autoInjectable. Right now I need to create logger as const variable outside of class and using from that.
Just ask at here if someone have same problem like me.

Is there additional state on AppEventEmitterService that necessitates it being a singleton? If not, then if we can make LoggerService a single instance (either singleton or a cached instance), you should be good.

You need to flip the decorator order since @singleton() registers the given constructor, and @autoInjectable() replaces the constructor with another.
I have added a test for this case: https://github.com/Microsoft/tsyringe/commit/9e24741fe5e76693e6a43bd3e7d719e1570e6112

@Xapphire13 Oh. Thank you. :)

@Xapphire13 It works

authors: MeltingMosaic Xapphire13 ethaizone kmasterycsl

repo: microsoft/tsyringe


text:
Using version in namespace route

For our APIs, we are using the version in our API routes. i.e. "/api/v1/Person", "/api/v2/Person", etc. We are also using TypeSpec to output OpenAPI3 files. This works well to give us a version per file, however, the routes do not work.
I expected to be able to do the below

@versioned(Person.Versions)
@route("/api/{version}")
namespace Person;

enum Versions{
  v1,
  v2
}

However, this does not work and have TypeSpec saying that it can't find the parameter "version" in the endpoints. Obviously, I don't really want version to be a parameter like that, but it highlights that this does not work. Is there another way to have the version number included in the route?

I think the versioning library is designed to version an entire service and not just a namespace.
I cooked up a playground example that uses an apiVersion parameter in the server definition. This avoids the error you reported but it has some "warts". The openapiv2.yaml is a bit misleading --it seems to say "you can use v1 or v2 in the server url" but some of the paths don't work for v1.

The playground example doesn't have too many warts, and really isn't that bad. Ultimately I really do want to version my entire service. I would just expect that if I am doing version as part of the URL, that it would live on the path definition of the endpoint rather than a server definition. It feels weird as if someone pulled the outputted spec, but had a different hosted base URL, I would expect them to be able to swap out the server URL and not have to be concerned with ensuring version matches.
So, like below is a snippet of what I'd want. This really means the server is just the bad URL for my API hosted service, where the path defines
openapi: 3.0.0
info:
  title: Versioning
  version: v2
tags: []
paths:
  /api/v2/widgets/customGet/{id}:
    get:

I think this idea of having a placeholder for version that can be referenced in api elements like routes is covered by this design issue, so closing this issue in favor of that

authors: markcowl mikekistler rboylesDev

repo: microsoft/typespec


text:
BEIT：How to fix the parameters of the pre-trained model for fine-tuning

When the model is fine-tuned, I want to fix its parameters and only update the parameters of the classifier. How should i set ？

This is a general pytorch question. Please refer to the pytorch document https://pytorch.org/docs/stable/generated/torch.no_grad.html

authors: L-xiaolu donglixp

repo: microsoft/unilm


text:
Added VCPKG_GENERATOR_TOOLSET to record visual studio version

VCPKG_GENERATOR_TOOLSET Will be used to generate the correct vs version of cmake - G
Fix https://github.com/microsoft/vcpkg/issues/21324
Fix https://github.com/microsoft/vcpkg/issues/7318

Moving this to draft until https://github.com/microsoft/vcpkg/pull/21342#issuecomment-968360596 is addressed

Moving this to draft until microsoft/vcpkg#21342 (comment) is addressed

Closing this PR since that PR was closed.

repo: microsoft/vcpkg-tool


text:
Make Linux dynamic linkage a first class citizen

Is your feature request related to a problem? Please describe.
Currently, and on the contrary to Windows platform, the official triplet on Linux is the one with static linkage. There are many problems with that:

The CI only test static linkage, which means the quality is not always paired with static build.
Static linking make linking big libraries like Qt very slow. Really, when debugging, this is painful
License problem: LGPL forbid static linking. Using static linking means your code will be GPL licensed. This is not acceptable for many of us.

Proposed solution

Add an official dynamic linkage triplet for linux, make them default, like on windows
Add a CI step to test it

Hmm... @BillyONeal what do you think about?

We choose static linking on the POSIX-ish platforms because dynamic linking generally forces you to use the system-provided libraries (e.g. those acquired through apt). It doesn't matter if you want to use the vcpkg version of boost in general, for example, because all the operating system's default load library paths are going to look in places owned by apt or dnf or similar.
Windows is different because on Windows your app can use version 1 of a shared library, and someone else can use version 2 of that shared library, and as long as those versions have different DLL names, a program can use both versions, since all symbols from that library are namespaced into the DLL in question. In contrast, in POSIX world, all the names go into the shared process symbol table, so trying to load multiple versions of a library into the same process will usually result in memory corruption.
(This is part of the problem domain and affects all non-system-wide package management solutions, so our ability to influence this is limited)

Yes, you are indeed right.
However, checking, at least, that the package build correctly on the CI would still increase the quality of the dynamic linkage packages. I guess the package must build out-of-the-box, in all case, even if static linking is the default (which I can live with it).
In the posix world, you have some mean to control where the dynamic loader finds their libraries (most notably by setting LD_LIBRARY_PATH to VCPKG 'installed' lib path). Another option, but this is harder, would be to use rpath at linking stage to ensure to load the dependencies of a library with a relative path from themself, so not the system one...
Agree, this is not easy, but other package management (Conan for stance) are able to (or they claim to) somewhat ensure that.

Agree, this is not easy, but other package management (Conan for stance)

While it's true that other package managers have decided to make dynamic linking on the POSIX platforms a more first class citizen, we believe that leads customer confusion; hence our strong recommendation of static linking on those platforms, and that triplet's community status.
We do have x64-linux-dynamic, and we do accept PRs that improve the experience for that triplet. However, even for folks who only use vcpkg locally, we believe it is too easy to accidentally get runtime libraries from the system at runtime resulting in "impossible" memory corruption, and we don't want to handle that support burden right now. For anything targeting wider distribution, those issues are much worse, since it's it might work due to rpath or similar on the dev box and then break when copied to an end user.
Despite the above, if some work is contributed to improve the experience for dynamic on those platforms, such as copying the right .sos in integrated build systems on the POSIX-ish platforms, that might be a reason to take that triplet out of community status. I think changing the default will remain off the table.

Yes, we already know the implication of this linkage type. However, it's not a matter of taste for us. The licence and the GPL contamination is a no go, as, even if most of our work are free and open (take a look at https://github.com/IRCAD-IHU/sight), some external part, are proprietary (just because it uses confidencial hardware, software, stuff that waits for a publication in a medical journal, ..) and we have no way to change that. Using for example static Qt (or any LGPL libraries) would mean we cannot go further than private and confidential prototype. No way to use our software in a OP room.
If your strong recommendations stays on static linkage, that's fair and understandable. We only beg for a CI support, to be sure that things compiles and that a submission doesn't break everything. We are in the process to evaluate VCPKG as a replacement for conan, and that is a real concern for us.
Anyway, thanks for listening :)

We do have x64-linux-dynamic,

Correction, we don't have that 😳

I've been able to build some ports with this overlay triplet:
set(VCPKG_TARGET_ARCHITECTURE x64)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE dynamic)

set(VCPKG_CMAKE_SYSTEM_NAME Linux)

# set rpath for libraries
if(PORT MATCHES "fribidi|harfbuzz|pkgconf")
    # Meson, nuff said
    set(pretty_ORIGIN_name "\$ORIGIN")
    set(VCPKG_LINKER_FLAGS "-Wl,-rpath,${pretty_ORIGIN_name}:${pretty_ORIGIN_name}/../lib")
elseif(PORT MATCHES "python2")
    # setting rpath here breaks build and I have no idea how to fix it.
    # But since python2 has no dependencies, not setting rpath is ok
else()
    set(VCPKG_LINKER_FLAGS "-Wl,-rpath,'$ORIGIN':'$ORIGIN/../lib'")
endif()

@BillyONeal I think there are new options today with dlmopen and RTLD_DEEPBIND. But I'm not a shared object expert.

authors: BillyONeal JackBoosY Osyotr abique dweckmann

repo: microsoft/vcpkg


text:
[SDL2] build failure with CMake, manifest and versioning

Host Environment

OS: Window x64
Compiler: MSVC 19.28.29336.0
CMake: 3.18

Generator: Visual Studio 16 2019 Win64
Environment: msvc_x64_x64

To Reproduce
Steps to reproduce the behavior:

Set up CMake project
Use manifest & versioning
Add SDL2 as dependency

Failure logs
vcpkg-manifest-install.log
The following packages will be built and installed:
    fmt[core]:x64-windows -> 7.1.3 -- C:\Users\Nekko\.vcpkg\buildtrees\versioning\versions\fmt\dd8cf5e1a2dce2680189a0744102d4b0f1cfb8b6
    sdl2[core]:x64-windows -> 2.0.14#2 -- C:\Users\Nekko\.vcpkg\buildtrees\versioning\versions\sdl2\df27b00967d099fabd3b9315a02105bd3e1be3d1
    spdlog[core]:x64-windows -> 1.8.0#2 -- C:\Users\Nekko\.vcpkg\buildtrees\versioning\versions\spdlog\83277d69ee0f37839d9f06c9fb658a3dd457e3eb
Could not locate cached archive: C:\Users\Nekko\AppData\Local\vcpkg\archives\59\59ed33b8518aee1a9b653ac20d446af9fc164c2a.zip
Using cached binary package: C:\Users\Nekko\AppData\Local\vcpkg\archives\a4\a4bbaf5e2d40c97e6b5558eaf425cd40207f99c6.zip
Using cached binary package: C:\Users\Nekko\AppData\Local\vcpkg\archives\3c\3cfe7fe9d111f1477297856c04a4ca56ea21b11f.zip
Starting package 1/3: sdl2:x64-windows
Building package sdl2[core]:x64-windows...
-- Installing port from location: C:\Users\Nekko\.vcpkg\buildtrees\versioning\versions\sdl2\df27b00967d099fabd3b9315a02105bd3e1be3d1
-- Downloading https://www.libsdl.org/release/SDL2-2.0.14.tar.gz -> SDL2-2.0.14.tar.gz...
-- Extracting source C:/Users/Nekko/.vcpkg/downloads/SDL2-2.0.14.tar.gz
-- Applying patch 0001-sdl2-Enable-creation-of-pkg-cfg-file-on-windows.patch
-- Applying patch 0002-sdl2-skip-ibus-on-linux.patch
CMake Error at scripts/cmake/vcpkg_apply_patches.cmake:63 (message):
  Applying patch failed.  Checking patch CMakeLists.txt 2020-10-28
  09:09:10.034165780 +0100...

  error: CMakeLists.txt 2020-10-28 09:09:10.034165780 +0100: No such file or
  directory

Call Stack (most recent call first):
  scripts/cmake/vcpkg_extract_source_archive_ex.cmake:145 (vcpkg_apply_patches)
  buildtrees/versioning/versions/sdl2/df27b00967d099fabd3b9315a02105bd3e1be3d1/portfile.cmake:8 (vcpkg_extract_source_archive_ex)
  scripts/ports.cmake:133 (include)

Error: Building package sdl2:x64-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: sdl2:x64-windows
  Vcpkg version: 2021-01-13-768d8f95c9e752603d2c5901c7a7c7fbdb08af35

Additionally, attach any relevant sections from the log files above.

vcpkg.json:
{
	//...
	"builtin-baseline": "a037d826492039db9d58af47a1e1248037d15f40",
	"dependencies": [
		//...
		{
			"name": "sdl2",
			"version>=": "2.0.14"
		}
	]
}

Additional context
Everything was working fine and built correctly until I added SDL2 as a dependency. I have tried manually applying the patch 0002 manually, pulling/updating my local install and cloning vcpkg with FetchContent.

Hi @NekkoDroid
Thanks for posting this issue.
It seems that there is something wrong with the patch. I have submitted a PR #16370 to update the patch.


text:
[libiconv] Build error

Host Environment

OS: Windows 10
Compiler: MSVC

To Reproduce
Steps to reproduce the behavior:
./vcpkg install glib
Failure logs
CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:158 (message):
Command failed: C:/vcpsf/vcpkg/downloads/tools/msys2/803521c5733336c9/usr/bin/make.exe -j 7 --trace -f Makefile all
Working Directory: C:/vcpsf/vcpkg/buildtrees/libiconv/x86-windows-dbg/
See logs for more information:
C:\vcpsf\vcpkg\buildtrees\libiconv\build-x86-windows-dbg-out.log
C:\vcpsf\vcpkg\buildtrees\libiconv\build-x86-windows-dbg-err.log
Call Stack (most recent call first):
scripts/cmake/vcpkg_build_make.cmake:187 (vcpkg_execute_build_process)
scripts/cmake/vcpkg_install_make.cmake:26 (vcpkg_build_make)
ports/libiconv/portfile.cmake:38 (vcpkg_install_make)
scripts/ports.cmake:145 (include)
package: libiconv[core]:x86-windows -> 1.16#11
vcpkg-tool version: 2022-02-11-dac008bf9b55ef48e10bcc81e273b97a82bbf72d
vcpkg-scripts version: c93faafe6 2022-02-13 (3 hours ago)
Additional context

Building is ok in another clean env.


text:
[qt-advanced-docking-system] update to 3.8.1

Can this revert be undone? I need to use version 3.8.1 for Qt6 support and people stuck on Qt 5.15 LTS will likely stick with an older version anyways as they want stability.

Use an overlay. My ports can be found here:
https://github.com/Neumann-A/my-vcpkg-ports
and it contains the 3.8.1 version for Qt6 with the required patches

@stijnherfst Sorry for that, you can use Neumann-A's library, we are still talking about qt6 support. If you have other questions please re-open this issue. :)

authors: FrankXie05 Neumann-A stijnherfst


text:
[glad] Build error

Copy issue body from C:/Users/zwj/vcpkg/installed/vcpkg/issue_body.md
System: Microsoft Windows Version 10.0.19045.3393
error: building glad:x64-windows failed with: BUILD_FAILED
I am using the latest port files with git pull and vcpkg update.

See #30604 on how to submit a failed port compile

Despite using the latest vcpkg version I still failed to build vcpkg install glfw3 glad glm.

@Guest-615695028 Please provide the error log.

This issue hasn’t been updated for a long time; if it is still an issue, please reopen this issue.


text:
[infoware] Add port of infoware library

This pull request adds a port for the C++ infoware library.
All triplets should be supported, with both dynamic and static builds available.
I could not find additional examples of CI that needed to change or more. The version of infoware being targeted by vcpkg should be 0.5.3.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: ThePhD sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Files changes (133)

I, uh. Seem to have irreversibly ruined my git commit. One moment. ;;

@ThePhD, the CI test with following triplet, does it expect? could you please take a look?
infoware:x64-uwp
infoware:arm-uwp
infoware:arm64-windows

I was not expecting this: there seems to be a specific problem with MSBuild on these platforms and building the tool to generate PCI data? Works fine with Ninja; I'll try to fix it up for MSBuild. Sorry about the failed tests...!

I actually don't understand what's going on in vcpkg in these cases. I can build for the platforms listed as failures independently outside of vcpkg, invoking the CMake build and install with either Ninja or MSBuild just fine. But inside of vcpkg, I get errors like these:

Desktop/vcpkg/buildtrees/infoware/arm64-windows-dbg/pciids/pci.ids > infoware_generated/pci_data.hpp"
FAILED: infoware_generated/pci_data.hpp
cmd.exe /C "cd /D Desktop\vcpkg\buildtrees\infoware\arm64-windows-dbg && Desktop\vcpkg\downloads\tools\cmake-3.17.2-windows\cmake-3.17.2-win32-x86\bin\cmake.exe -E make_directory infoware_generated/ && Desktop\vcpkg\buildtrees\infoware\arm64-windows-dbg\infoware_pci_generator.exe Desktop/vcpkg/buildtrees/infoware/arm64-windows-dbg/pciids/pci.ids > infoware_generated/pci_data.hpp"
This version of Desktop\vcpkg\buildtrees\infoware\arm64-windows-dbg\infoware_pci_generator.exe is not compatible with the version of Windows you're running. Check your computer's system information and then contact the software publisher.
ninja: build stopped: subcommand failed.

I sincerely am not sure how to handle this. Maybe I should just disable the x64_uwp, arm_uwp, and arm64 builds?

@ThePhD For UWP, I have no idea what's wrong; I would just set it as fail. There's often an issue getting ports which aren't designed for it to work on UWP.
For arm64-windows, the issue that you have is that you have build tools that need to run on the host architecture, but you're always running them on the target architecture; it's completely valid to do that, but it means cross-compilation is impossible. You may want to pull a boost, and require that the host binaries are installed before building the target libraries, or you may want to just wait until we have support for tool-depends. If the latter, I would set it to fail and write a comment to the effect of This port doesn't support cross-compilation.

Is the right thing to do Supports: !(uwp|arm) or is it better to modify scripts/ci.baseline.txt?

Also, I think the x64_osx pipeline is broken...!

/azp run

Currently we add the follow code when it unsupport some arch or platform.

CONTROL: Supports: !(uwp|arm)
Portfile.cmake:  vcpkg_fail_port_install(ON_ARCH "arm"  ON_TARGET  "uwp")
ci.baseline.txt:
inforware:arm-uwp=fail
inforware:arm64-windows=fail
inforware:x64-uwp=fail

Let's wait for the CI test results.

@ThePhD Thanks for your contribution!

Oh, nice, thanks for adding that function to the PR, glad it seems to all work now!!

Thanks for the PR!

authors: BillyONeal PhoebeHui ThePhD dan-shaw msftclas strega-nil


text:
[qhull] update version 8.0.0

The PR updates the port qhull to the latest version 8.0.0

What does your PR fix? Fixes #12004

Which triplets are supported/not supported?

x64-windows
x64-windows-static
x64-osx
x64-linux
x64-uwp

The macOS patch is required because of https://github.com/qhull/qhull/issues/65, while the uwp replicates the one already added in https://github.com/microsoft/vcpkg/pull/7370.
I was already able to compile the port through GitHub Actions on Windows Linux and Mac. Please check here.

Thanks for the PR!

authors: GiulioRomualdi vicroms


text:
Add NVTOOLSEXT_PATH to the env passthrough list

(CMake uses it to search for the toolkit)
  if(WIN32)
    # nvtools can be installed outside the CUDA toolkit directory
    # so prefer the NVTOOLSEXT_PATH windows only environment variable
    # In addition on windows the most common name is nvToolsExt64_1
    find_library(CUDA_nvToolsExt_LIBRARY
      NAMES nvToolsExt64_1 nvToolsExt64 nvToolsExt
      PATHS ENV NVTOOLSEXT_PATH
            ENV CUDA_PATH
      PATH_SUFFIXES lib/x64 lib
    )
  endif()

LGTM, thanks!


text:
[curl] Update to 7.22.0

Regular port update https://github.com/curl/curl/releases/tag/curl-7_72_0
No changes to triplet support, basic functionality tested
Add feature schannel as an alias to winssl for compatibility (upstream dropped the "WinSSL" naming altogether)
Does your PR follow the maintainer guide? Yes

Thanks for your PR. Now curl build failed on target UWP with the following error:
     4>LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/OPT:ICF' specification [D:\buildtrees\curl\x64-uwp-dbg\lib\libcurl.vcxproj]
            Creating library D:/buildtrees/curl/x64-uwp-dbg/lib/Debug/libcurl-d.lib and object D:/buildtrees/curl/x64-uwp-dbg/lib/Debug/libcurl-d.exp
     4>openssl.obj : error LNK2019: unresolved external symbol CertOpenSystemStore referenced in function ossl_connect_step1 [D:\buildtrees\curl\x64-uwp-dbg\lib\libcurl.vcxproj]
     4>D:\buildtrees\curl\x64-uwp-dbg\lib\Debug\libcurl-d.dll : fatal error LNK1120: 1 unresolved externals [D:\buildtrees\curl\x64-uwp-dbg\lib\libcurl.vcxproj]

Minimum supported client | Windows XP [desktop apps only]
Minimum supported server | Windows Server 2003 [desktop apps only]
Target Platform | Windows
Header | wincrypt.h
Library | Crypt32.lib
DLL | Crypt32.dll

On my end, that page says both desktop and UWP are supported 🤔

https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-certopensystemstorea

I think this is patchable because the segment in question is already wrapped in a USE_WIN32_CRYPTO define. However, even before it was calling CertOpenSystemStoreA...

@kevinlul Do you know which feature or its core caused this problem?

openssl in this case, though I just discovered that core also fails with these missing symbols from md4.c, md5.c, sha256.c
CryptAcquireContext
CryptCreateHash
CryptHashData
CryptGetHashParam
CryptDestroyHash

I think we need to ensure that we can successfully build on all triplets. So, please remove the broken default features on uwp.

I think I found the problem, though this CMake logic hasn't changed between 7.71.1 and 7.72.0.

Sorry, left a typo in.

Manually checked on x86-windows:

curl[core]
curl[core,tool]
curl[core,non-http]
curl[core,http2]
curl[core,ssh]
curl[core,openssl]
curl[core,schannel]
curl[core,mbedtls]
curl[core,sectransp] (failed because not supported on non-apple platforms)
curl[core,c-ares]
curl[core,sspi]
curl[core,brotli]
curl[core,brotli,tool,non-http,http2,ssh,schannel,c-ares,sspi]

Thanks for your contribution!

authors: BillyONeal JackBoosY LilyWangL kevinlul


text:
follow-up to PR #12926

also fix semicolons in vcpgk_execute_required_process (follow-up of #12926)
add optional output and error variable to vcpgk_execute_required_process
apply fix to gdal port (currently quotes lists to prevent expansion)
this PR is a spin-off of PR #13028 to separate changes in vcpgk_execute_required_process

@BillyONeal @Neumann-A Could you please review this PR?
Thanks.

I don't see any relation between remaining CI failures and code changes of this PR. Over the last 3 CI runs, errors appeared and disappeared without any code changes in this PR, just by re-running and/or merging master. In particular:
last but 2nd run:
x86-windows: ois osgearth
x64-windows: plib osgearth
x64-windows-static: openxr-loader qt5-tools
x64-uwp: vcpkg-gfortran protobuf
arm-windows: protobuf boost*
x64-linux: openxr-loader qt5-tools
last but 1st run:
x86-windows: ogre sqlcipher
x64-windows: ogre parmetis qt5-scxml qt5-sensors qt5-serialport sqlcipher
x64-windows-static: ogre openxr-loader
x64-linux: openxr-loader
last run:
x86-windows: sqlcipher
x64-windows: apr sqlcipher
x64-windows-static: ogre
x64-linux: apr
sqlcipher is currently broken also in master (Error: There are invalid field types in the CONTROL or manifest file of C:\work\tools\vcpkg\ports\sqlcipher\vcpkg.json). apr has transient error (SSL connection while downloading).

sqlcipher:
couldn't read file ";TCLVERSION=90;ORIGINAL_SRC=D:\buildtrees\sqlcipher\src\v4.4.0-36c69edad7.clean;EXT_FEATURE_FLAGS=-DSQLITE_TEMP_STORE=2": no such file or directory

I think that's related to your changes.

/azp run

sqlcipher:
couldn't read file ";TCLVERSION=90;ORIGINAL_SRC=D:\buildtrees\sqlcipher\src\v4.4.0-36c69edad7.clean;EXT_FEATURE_FLAGS=-DSQLITE_TEMP_STORE=2": no such file or directory

I think that's related to your changes.

Sorry, you're right. It turned out that the error I was seeing on my machine (Error: There are invalid field types in the CONTROL or manifest file) was hiding the error you quoted. After I rebuilt vcpkg.exe, I was able to reproduce the issue. I'll push a fix.

just re-running CI lead to these changes in CI failures:
previous run:
x86-windows: sqlcipher
x64-windows: apr sqlcipher
x64-windows-static: ogre
x64-linux: apr
after re-running:
x86-windows: sqlcipher osgearth
x64-windows: sqlcipher osgearth
x64-windows-static: plib ogre
arm-uwp: anyrpc
I then fixed sqlcipher to work wit my changes of this PR. Now all tests succeed. Thus, apr, ogre, osgearth, anyrpc were unrelated and transient issue.
Anyway, the main thing is: is working now :-) So, this PR is ready for final review and merge.

@JackBoosY BTW: The code you reviewed included the port version bump you requested. I don't find an option to acknowledge that your requested changes are done. How to get rid of the status "changes requested"?

Merging master caused these new CI failures:
x86-windows: akali, libpqxx, moos-core, osgearth
x64-windows-static: ogre, qt5-tools
arm64-windows: libpqxx
Looking through the logs, it's mostly some file or lib not found. I observed similar transient issues on my local machine, where the culprit was the anti-virus scanner locking a file while scanning and thus making it unavailable to the build process. As

ogre, osgearth, qt5-tools already had transient issues appearing and disappearing without code changes during the history of this PR (see above),
libpqxx was updated in master but I don't see any changes in the diff being affected by this PR,
akali, moos-core had no relevant code changes since previous merge of master,

can you please re-run all failed CI to see which of them are not transient errors?

Looking through the logs, it's mostly some file or lib not found. I observed similar transient issues on my local machine, where the culprit was the anti-virus scanner locking a file while scanning and thus making it unavailable to the build process.

As someone interested in getting this PR through to ultimately get tensorflow-cc back to life, I can see that this is much more painful than it should be. Please don’t give up, @jgehw, the world is counting on you :-)

Unfortunately the nature of this PR causes the entire binary cache to be invalidated, so that PR build tries to build everything, so you're subject to the union of build flakiness of all ~1350 ports and their associated servers. We are always working to make things more reliable and things are better now than they were a few months ago, but still not "rock solid". @ras0219 / @ras0219-msft is working on caching package sources rather than just outputs which will help a lot since it will mean we don't break because some server is down.

Today's CI failures:

libpqxx (x86-windows, x64-windows, arm64-windows) "dl.lib" not found - seems to be an issue with the build environment, it's compiling fine on my machine
qt5-multimedia (x86-windows, x64-windows, x64-windows-static) network issues while download -> transient error
freetds (x64-windows) permission denied on temp file -> transient error
ogre (x64-windows-static) compile error "definition of dllimport static data member not allowed" - not reproducable on my machine - either transient or specific to build environment

@BillyONeal @JackBoosY can you please re-run failed CIs? (I can't, insufficient permissions)

We talked about this today and resolved that for "rebuild the world from contributors" changes like this we will merge them upon manual review that all the failures match a previous CI nightly build (currently https://dev.azure.com/vcpkg/public/_build?definitionId=29 )

Well I was going to merge this anyway with potential failures but it passed now, yay! :D :D :D :D

Thanks so much for your contribution and dealing with our PR / CI system issues :D

authors: BillyONeal JackBoosY ianier jgehw


text:
[vcpkg baseline][many ports] Fix build error

Fix baseline issues, these changes need to fix togather, since they affected each other in CI testing.

[X] wxwidgets
[X] mlpack
[X] embree2
[X] embree3
[ ] opencv4
[ ] zxing-cpp
[ ] dbow2

Fix wxwidgets bug:

F:\vcpkg\buildtrees\wxwidgets\x86-windows-dbg\libs\stc\cotire\wxscintilla_CXX_prefix.hxx(4): fatal error C1083: Cannot open include file: 'F:\vcpkg\buildtrees\wxwidgets\src\54f4f955a1-1de49a51d0\build\cmake\lib\stc\CONFIG': No such file or directory

It's becuase the parameter wxSCINTILLA_PREC_HEADER is empty:
if(wxBUILD_PRECOMP)
    # The auto-generated header causes undefined members and identifiers in the
    # standard c++ headers when using clang.
    # Do not disable precompiled headers entirely but use the main Scintilla
    # header as prefix header so there is at least a small speedup.
    if ("${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang")
        set(wxSCINTILLA_PREC_HEADER "${wxSOURCE_DIR}/src/stc/scintilla/include/Scintilla.h")
    endif()
    wx_target_enable_precomp(wxscintilla ${wxSCINTILLA_PREC_HEADER})
endif()

causes the leaked field CONFIG to be set in set_target_properties in function wx_target_enable_precomp.
Then, get_property obtained the property and read its file path, resulting in the generation of the wrong wxscintilla_CXX_prefix.hxx:
/* cotire.cmake 1.8.0 generated file */
/* F:/vcpkg/buildtrees/wxwidgets/x86-windows-dbg/libs/stc/cotire/wxscintilla_CXX_prefix.hxx */
/* cotire.cmake 1.8.0 generated file */
/* F:/vcpkg/buildtrees/wxwidgets/x86-windows-dbg/libs/stc/cotire/wxscintilla_CXX_prefix.hxx */
#ifdef __cplusplus
#include "F:\vcpkg\buildtrees\wxwidgets\src\54f4f955a1-1de49a51d0\build\cmake\lib\stc\CONFIG"
#endif

which is not exist.

Fix mlpack configure bug, already fixed in upstream https://github.com/mlpack/mlpack/commit/52e123e56792638c957d0229b001ae14a9e94a75.

@cenit When building opencv4:x86-windows or opencv4:x64-windows, we met a error message:
CMake Error at cmake/OpenCVGenConfig.cmake:49 (export):
  export Export set "OpenCVModules" not found.
Call Stack (most recent call first):
  CMakeLists.txt:923 (include)

And for opencv4:x64-linux:
The following empty directories were found:

    /home/usr/work/vcpkg/packages/opencv4_x64-linux/debug

If a directory should be populated but is not, this might indicate an error in the portfile.
If the directories are not needed and their creation cannot be disabled, use something like this in the portfile to remove them:

    file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/a/dir" "${CURRENT_PACKAGES_DIR}/some/other/dir")

Found 1 error(s). Please correct the portfile:
    /home/usr/work/vcpkg/ports/opencv4/portfile.cmake

Can you please take a look?
Thanks.

Fix embree2/embree3 CI test failures:
CMake Error in CMakeLists.txt:
  You have set CMAKE_BACKWARDS_COMPATIBILITY to a CMake version less than
  2.4.  This version of CMake only supports backwards compatibility with
  CMake 2.4 or later.  For compatibility with older versions please use any
  CMake 2.8.x release or lower.

Reference https://cmake.org/cmake/help/latest/policy/CMP0001.html#policy:CMP0001

The opencv4 issue is OPENCV_MODULES_BUILD always be cleaned after insert items.
The dbow2 and zxing-cpp regressions are related to opencv4 regression.

The opencv4 failures start from https://github.com/microsoft/vcpkg/commit/b369b110b16b149066271a09ee56f1b9dcaec7d6.
Related PR https://github.com/microsoft/vcpkg/pull/17955

i saw few days ago that opencv is not even tested in many CI configs... i will take a look and send fixes asap (might take a couple of days, sorry)

yeah I can confirm anyway that in the last 24h OpenCV was broken for everybody here on vcpkg.
Again a PR was merged and that broke all my "bleeding edge" pipelines. They are really bleeding....

this is making the fix much more urgent also for me

#17991 will revert #17955 @JackBoosY

/azp run

@dan-shaw, could you help merge this PR?

authors: JackBoosY PhoebeHui cenit


text:
[scripts] Python MinGW port

Describe the pull request

What does your PR fix?
Fixes #21186

Which triplets are supported/not supported? Have you updated the CI baseline?
Windows MinGW x64 Dynamic Debug/Release, CI Baseline hasn't been updated.

Does your PR follow the maintainer guide?
Yes

If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?
I am still working on this PR

Did you test it at all?
Note that the list of patches msys2 needs to add pristine python in order to build for mingw:
https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-python

Yep this commit should be a normal / good change.
I'll update the portfile soon.
Now it can build but having errors when running test regarding to threading library. I'm fixing.

I have a question, how to make vcpkg_configure_make see the installed libs by VCPKG?
Such as, openssl, libffi, etc.
I've been trying multiple ways but so far still stuck at this.
set(PKG_CONFIG "${CURRENT_INSTALLED_DIR}/tools/pkgconf/pkgconf.exe")
set(PKG_CONFIG_LIBDIR "${CURRENT_INSTALLED_DIR}/lib/")
set(PKG_CONFIG_PATH "${CURRENT_INSTALLED_DIR}/lib/pkgconfig:${CURRENT_INSTALLED_DIR}/share/pkgconfig")

vcpkg_configure_make(
    SOURCE_PATH ${SOURCE_PATH}
    AUTOCONFIG
    OPTIONS
        MACHDEP=win32
        PKG_CONFIG=${PKG_CONFIG}
        PKG_CONFIG_LIBDIR=${PKG_CONFIG_LIBDIR}
        PKG_CONFIG_PATH=${PKG_CONFIG_PATH}
        --prefix=${CURRENT_INSTALLED_DIR}
)

set(PKG_CONFIG "${CURRENT_INSTALLED_DIR}/tools/pkgconf/pkgconf.exe")
set(PKG_CONFIG_LIBDIR "${CURRENT_INSTALLED_DIR}/lib/")
set(PKG_CONFIG_PATH "${CURRENT_INSTALLED_DIR}/lib/pkgconfig:${CURRENT_INSTALLED_DIR}/share/pkgconfig")
...
        PKG_CONFIG=${PKG_CONFIG}
        PKG_CONFIG_LIBDIR=${PKG_CONFIG_LIBDIR}
        PKG_CONFIG_PATH=${PKG_CONFIG_PATH}
        --prefix=${CURRENT_INSTALLED_DIR}

This is already handled by vcpkg_configure_make. In particular, libdir and search path must be different for the debug build. vcpkg builds both debug and release.

After some trials & errors it can build Python,

From your cpython issue comments I assume you build the msys2 fork, not pristine cpython as packaged in vcpkg.

Yep I tried again, setting PKG_ vars messed it up. OpenSSL has been found without those PKG vars.
About versions, the original Python3 was 3.10.5, I'm building 3.10.7 MSYS fork indeed, since it's intended for MinGW.

Now the build can't link libffi, maybe I'd need to patch Python's build script.
Btw MSYS2 MinGW64 shell builds fine !
It's only CMD / Powershell that couldn't build.
Maybe there's still a difference in environment emulation that makes autoconf fails to find libffi.

Time to patch Python's configure.ac file.
configure: WARNING: --with(out)-system-ffi is ignored on this platform

Now the build can't link libffi, maybe I'd need to patch Python's build script.

Well, you are building a fork which relies on MSYS2 mingw packages. They all would need to be packaged for vcpkg, too. If vcpkg accepts using a different python repo for mingw triplets.
Note that you don't need the autoconf-archive to use autoconf-archive for a particular build: Just use the ADDITIONAL_MSYS_PACKAGES option of ADDITIONAL_MSYS_PACKAGES.  Don't touch scripts/cmake/* unless really needed.
So either this PR is suggesting the autoconf-archive change, or the python fork for mingw.
And the mingw change should also work on linux hosts.

Thanks for telling me the ADDITIONAL_MSYS_PACKAGES, I was about to suggest similar change to vcpkg allowing to do so.
Guessed that I was a little overwhelmed and overlooked that feature.
This PR should be about MinGW port, I'll update the commits to revert the vcpkg_configure_make change.
But since vcpkg can build MinGW packages too (such as OpenSSL, libffi, etc) I'd not add those to ADDITIONAL_MSYS_PACKAGES, except for autoconf-archive which is only used one time at build configuration.
My main OS is Linux but now working on a Windows project so I'm porting, gonna test on Linux as well for sure.

Does it look odd to you? A naming error costs me hours to debug, re-run the vcpkg build process again many times haha.
It should be named as libffi.dll.a, not liblibffi.dll.a, or am I missing a naming collision case here that forces this lib to this name?
I don't know who committed this port but I kinda hate him 😄

Cleared libffi error, temporarily. I may fix the libffi port too, it makes other packages that uses autoconf fail to locate libffi installed by vcpkg. Now to next compile error of libuuid. This port is also not present for mingw.

I don't know who committed this port but I kinda hate him

Welcome to vcpkg. mingw is not tested in CI, and so you sometimes face a broken mix of MSVC and POSIX configurations. A port with many dependencies, such as python, will take a while to fix all dependencies.
On the positive side, if you now start another PR for fixing libffi, it will be an easier learning experience ;-)

Well I've built many POSIX-projects on Windows successfully (including cross-compiling from Linux to Win), just new to vcpkg.
It has been a fun already.
Vcpkg relies on CMake, that has certain friction to start for most people, i.e. if comparing to Conan where I just compile libraries with MSYS shell (which often works very well - including Python compilation but somehow not working well for other Shells), then ship pre-built packages for Projects.
The idea of compiling when installing any new package, especially on Windows looks very scary.
I'd like to use vcpkg to host our pre-built packages as well.
Regarding ffi, yeah I may fix it somehow. A quick dirty way is add a rename command 😄

Fixed libuuid for compiling, MinGW ships its own since it belongs to MinGW runtime. This package won't need to be included in vcpkg.

I'm steering to another direction. Maybe will only provide the Python Libs (include and lib files) as a new port called python3-dev.
Since the full Python distribution is rarely used in Vcpkg (one would go to Python.org to download). Even other packages download MSYS' Python to use in port build if needed.
Vcpkg should provide the package as development libraries only, instead of end-user software in this case. While a full Python distribution is possible to achieve, the priority is not now, I will continue to port this from time to time.
Gonna open another new PR for python3-dev port (review ready).

Gonna open another new PR for python3-dev port (review ready).

The way to do this is to add a feature to python3 which enables the building of tools.

Thanks @Neumann-A for the suggestion !

Ping @manhnt9 for response. Is work still being done for this PR?

@LilyWangLL not yet, it's not a good change actually. Though I can build for MinGW python.exe interpreter but other Python modules are still failed to build. (If someone only needs libPython or Python interpreter for their own modules then the PR is usable). It's still being worked on so I'll get back when it's more progressed.

Closing this PR since it seems that no progress is being made. Please ping us to reopen if work is still being done.


text:
[curl] fix curl find_package

Describe the pull request

What does your PR fix?
Fix find_package(CURL CONFIG REQUIRED)can't find CURLConfig.cmake because of case sensitive on linux

Which triplets are supported/not supported? Have you updated the CI baseline?
No, unchanged.

Does your PR follow the maintainer guide?
Yes

Does your PR follow the maintainer guide?
Yes

If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?
Yes

@microsoft-github-policy-service agree

Thanks for your contribution. But this change is invalid. CURL is the only valid package name, and it works as is in module mode and in config mode.
(If project CURL would want to support arbitrary case, they could have chosen to install curl-config.cmake.)

Thanks for your contribution. But this change is invalid. CURL is the only valid package name, and it works as is in module mode and in config mode.
(If project CURL would want to support arbitrary case, they could have chosen to install curl-config.cmake.)

@dg0yt
Thank you for answering, I found the relevant information as follows:
https://github.com/microsoft/vcpkg/blob/0d382380b9dbfd2e13afa37fc92092c5e1456f31/scripts/buildsystems/vcpkg.cmake#L783
https://github.com/microsoft/vcpkg/blob/0d382380b9dbfd2e13afa37fc92092c5e1456f31/ports/curl/vcpkg-cmake-wrapper.cmake#L11
Because file names are case-sensitive on linux, find_package(CURL CONFIG REQUIRED) is required to find curlConfig.cmake or curl-config.cmake in the configuration above. I will give feedback to curl community later.
[cmake] Not searching for unused variables given on the command line.
[cmake] -- VCPKG-Info: CMAKE_MAP_IMPORTED_CONFIG_MINSIZEREL set to MinSizeRel;Release;
[cmake] -- VCPKG-Info: CMAKE_MAP_IMPORTED_CONFIG_RELWITHDEBINFO set to RelWithDebInfo;Release;
[cmake] CMake Error at external/vcpkg/installed/x64-linux/share/curl/vcpkg-cmake-wrapper.cmake:12 (_find_package):
[cmake]   Could not find a package configuration file provided by "curl" with any of
[cmake]   the following names:
[cmake]
[cmake]     curlConfig.cmake
[cmake]     curl-config.cmake
[cmake]
[cmake]   Add the installation prefix of "curl" to CMAKE_PREFIX_PATH or set
[cmake]   "curl_DIR" to a directory containing one of the above files.  If "curl"
[cmake]   provides a separate development package or SDK, be sure it has been
[cmake]   installed.
[cmake] Call Stack (most recent call first):
[cmake]   external/vcpkg/scripts/buildsystems/vcpkg.cmake:797 (include)
[cmake]   cmake/monitor.cmake:14 (find_package)
[cmake]   CMakeLists.txt:29 (include)
[cmake]
[cmake]
[cmake] -- Configuring incomplete, errors occurred!

@dg0yt The name here in CURL does not conform to the case-insensitive lookup rules of find_package. Please refer to https://github.com/curl/curl/issues/10229.
But the best way to adapt here is in the file vcpkg-cmake-wrapper.cmake.
https://github.com/microsoft/vcpkg/blob/0d382380b9dbfd2e13afa37fc92092c5e1456f31/ports/curl/vcpkg-cmake-wrapper.cmake#L10-L11

@msclock: Your find_package call is wrong. End of story. It has to be find_package(CURL) due to CURLConfig.cmake upstream made it case sensitive by not using curl-config.cmake instead.

The name here in CURL does not conform to the case-insensitive lookup rules of find_package

To be clear. This is not a vcpkg issue that is a CURL issue.
Also why should it even conform to case-insensitive lookup? (its not a rule it is just an implementation detail of cmake.)

Oh!!
It's my fault. Thanks for answering the questions.
I will close the relevant questions later.
Thank you again for your tolerance and solution.

authors: Neumann-A dg0yt msclock


text:
[dbow2] Add new port

DBoW2 doesn't currently support arm as it depends on opengl.
Related issue #4505.

/azp run

Thanks for the PR!


text:
Error from learn.microsoft.com -  Enable automatic updates in a web application using Azure Functions and SignalR Service

Repro steps:

https://docs.microsoft.com/en-us/learn/modules/automatic-update-of-a-webapp-using-azure-functions-and-signalr/7-exercise-host-a-static-website-using-a-storage-account
Error 404

Action: azureFunctions.deploy
Error type: 403
Error Message: Failed with code "403".
Version: 0.20.2
OS: win32
Product: Visual Studio Code
Product Version: 1.41.1
Language: en

Call Stack
extension.bundle.js:218:502569extension.bundle.js:218:502569
s extension.bundle.js:218:111756
s extension.bundle.js:164:25792
extension.bundle.js:164:27036extension.bundle.js:164:27036
o extension.bundle.js:164:674848
extension.bundle.js:164:24705extension.bundle.js:164:24705
$._callback extension.bundle.js:1:634979
$.t._callback.t.callback.t.callback [as callback] extension.bundle.js:194:5590
$.emit events.js:200:13
$.EventEmitter.emit domain.js:471:20
$.<anonymous> extension.bundle.js:194:18450
$.emit events.js:205:15
$.EventEmitter.emit domain.js:471:20
IncomingMessage.<anonymous> extension.bundle.js:194:17282
Object.onceWrapper events.js:288:20
IncomingMessage.emit events.js:205:15
IncomingMessage.EventEmitter.emit domain.js:471:20
endReadableNT _stream_readable.js:1154:12
processTicksAndRejections task_queues.js:84:9

Closing as duplicate of https://github.com/microsoft/vscode-azurefunctions/issues/1859 and https://github.com/microsoft/vscode-azurefunctions/issues/1583

As a workaround, please try the "Advanced" option when creating a function app in azure, which should give you more options

authors: EricJizbaMSFT vglu

repo: microsoft/vscode-azurefunctions


text:
Quick Fix hover not working

After updating to VS Code 1.36.0 the option for quick fix when hovering does not apply the related action.

Using the quick fix on the bulb action does.

VS Code Info
Version: 1.36.0 (user setup)
Commit: 0f3794b38477eea13fb47fbe15a42798e6129338
Date: 2019-07-03T13:25:46.372Z
Electron: 4.2.5
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Windows_NT x64 10.0.18362

I'm having the same problem after updating VSCode. I'm going to use the bulb action meanwhile.
Version: 1.36.0 (user setup)
Commit: 0f3794b38477eea13fb47fbe15a42798e6129338
Date: 2019-07-03T13:25:46.372Z
Electron: 4.2.5
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Windows_NT x64 10.0.17763

Yes, after updating the latest version of vscode IDE today, eslink has changed. It used to be normal, but I can use Ctrl +. to fix code errors.

@mjbvz same as with the Java plugin. Has something changed here in VS Code ?

I move the issue to VS Code since the quick fix action computation is the same in both pathes.

repo: microsoft/vscode-eslint


text:
Failed to change kernel: Kernel Python 3.10.9 is not usable.

Applies To

[ ] Notebooks (.ipynb files)
[ ] Interactive Window and/or Cell Scripts (.py files with #%% markers)

What happened?
I'm unable to connect to the Kernel.  As I try to execute a cell in a notebook, VS Code tries to connect 5 times to the Kernel and then fails.  I've ported code working on an older Macbook to a new Macbook Pro M1.  I'm having problems configuring the correct version Python in VS Code / Jupyter.  I've set the Kernel to use Python 3.10.9 but can see the 3.8 being used.
I've missed a configuration VS Code / Jupyter somewhere and cannot seem to find the issue from the errors.
jupyter.log
I've run the notebook file from the command line jupyter notebook and it starts and runs well.
VS Code Version
Version: 1.74.3 Commit: 97dec172d3256f8ca4bfb2143f3f76b503ca0534 Date: 2023-01-09T17:05:47.808Z Electron: 19.1.8 Chromium: 102.0.5005.167 Node.js: 16.14.2 V8: 10.2.154.15-electron.0 OS: Darwin arm64 22.2.0 Sandboxed: Yes
Jupyter Extension Version
v2022.11.1003412109
Jupyter logs
Visual Studio Code (1.74.3, undefined, desktop)
Jupyter Extension Version: 2022.11.1003412109.
Python Extension Version: 2022.20.2.

Coding Language and Runtime Version
Python 3.10.9
Language Extension Version (if applicable)
No response
Anaconda Version (if applicable)
No response
Running Jupyter locally or remotely?
None

I've run the notebook file from the command line jupyter notebook and it starts and runs well.

when you do this please could you run the following code in a Jupyter notebook and let me know what you get
import sys
print(sys.executable)
print(sys.version)

I've set the Kernel to use Python 3.10.9 but can see the 3.8 being used.

Looks like /usr/local/bin/python is your Python 3.8 env and /usr/local/bin/python3 is your Python 3.10.9 env.
Please could you confirm this.
Right now 3.8 is used to start Jupyter.
Before we make further changes I'd like to get the output from Jupyter when you run it from the terminal.

Hi Don - Thank you for you fast response.

when you do this please could you run the following code in a Jupyter notebook and let me know what you get
import sys
print(sys.executable)
print(sys.version)

I built a test notebook with the 3 lines above and got a similar response as I did from my original execution...  I've attached the response here
rerun-test.txt

Looks like /usr/local/bin/python is your Python 3.8 env and /usr/local/bin/python3 is your Python 3.10.9 env.

Correct.

Before we make further changes I'd like to get the output from Jupyter when you run it from the terminal.

I've attached the terminal response here.
terminal_output.txt

I think you misunderstood something

I absolutely did mis-read your ask... and your explanation was very clear, sorry.
> import sys
> print(sys.executable)
> print(sys.version)

Output
/Library/Frameworks/Python.framework/Versions/3.10/bin/python3
3.10.9 (v3.10.9:1dd9be6584, Dec  6 2022, 14:37:36) [Clang 13.0.0 (clang-1300.0.29.30)]

@DonJayamanne Is there anything more you need?  Did I answer your question?

Hmm, looks like Python 3.8 env is unable to launch kernels,
Please could you:

Open VS Code
Select the command Jupyter: Select Interpreter to Start Jupyter Server from the command palette
From the quick pick, please select your /bin/python3 (Python 3.10.9) environment
If prompted to install some Jupyter related dependencies then please do so
After that is done, please re-load vscode
Try running a cell once again

Fixed.

authors: DonJayamanne johnfoneill

repo: microsoft/vscode-jupyter


text:
Cells interminable after server closed

Testing #9768
After closing the server in my local terminal, I tried running a cell on the browser. It started to run and did not stop, or respond to the stop button:

Thanks for the issue.
Seems like the remote kernel should fail? Might depend upon what the active connection does in this situation. It might sit there forever.

This issue applies to local as well, not specific to web. I.e. its an existing issue, but will be more common in web as web will only support remote (at least for now).

This might be fixed now.

Sorry still repros for me.

Pressing the stop button still does nothing. I have to wait for around a minute to see the message that the server isn't available.
One of the messages is in monospace and the link isn't rendered properly:

authors: DonJayamanne JacksonKearl rchiodo rzhao271


text:
Add banner to custom editor

Show this banner when opening a custom editor. We're deprecating the custom editor in 1.60 release.

Codecov Report

Merging #6876 (8abb462) into main (04dd691) will increase coverage by 0%.
The diff coverage is n/a.

:exclamation: Current head 8abb462 differs from pull request most recent head b4aafd0. Consider uploading reports for the commit b4aafd0 to get more accurate results

@@          Coverage Diff           @@
##            main   #6876    +/-   ##
======================================
  Coverage     68%     68%
======================================
  Files        410     410
  Lines      28522   28522
  Branches    4263    4263
======================================
+ Hits       19441   19618   +177
+ Misses      7404    7208   -196
- Partials    1677    1696    +19

Impacted Files
Coverage Δ

src/client/datascience/baseJupyterSession.ts
66% <0%> (-1%)
:arrow_down:

...ient/datascience/editor-integration/codewatcher.ts
69% <0%> (+<1%)
:arrow_up:

src/client/datascience/commands/commandRegistry.ts
39% <0%> (+<1%)
:arrow_up:

...client/datascience/commands/activeEditorContext.ts
88% <0%> (+<1%)
:arrow_up:

src/client/common/utils/decorators.ts
79% <0%> (+<1%)
:arrow_up:

.../datascience/editor-integration/codeLensFactory.ts
85% <0%> (+<1%)
:arrow_up:

...tascience/jupyter/liveshare/hostJupyterNotebook.ts
45% <0%> (+1%)
:arrow_up:

src/client/datascience/notebook/notebookEditor.ts
41% <0%> (+1%)
:arrow_up:

...datascience/editor-integration/codelensprovider.ts
84% <0%> (+2%)
:arrow_up:

src/client/common/platform/fileSystem.ts
66% <0%> (+2%)
:arrow_up:

... and 12 more

authors: codecov-commenter rchiodo


text:
WIP

For #

[ ] Pull request represents a single change (i.e. not fixing disparate/unrelated things in a single PR).
[ ] Title summarizes what is changing.
[ ] Has a news entry file (remember to thank yourself!).
[ ] Appropriate comments and documentation strings in the code.
[ ] Has sufficient logging.
[ ] Has telemetry for enhancements.
[ ] Unit tests & system/integration tests are added/updated.
[ ] Test plan is updated as appropriate.
[ ] package-lock.json has been regenerated by running npm install (if dependencies have changed).

Codecov Report

Merging #8308 (a968603) into main (35709dc) will increase coverage by 0%.
The diff coverage is 80%.

:exclamation: Current head a968603 differs from pull request most recent head e5caa37. Consider uploading reports for the commit e5caa37 to get more accurate results

@@          Coverage Diff          @@
##            main   #8308   +/-   ##
=====================================
  Coverage     72%     72%
=====================================
  Files        371     371
  Lines      23075   23168   +93
  Branches    3512    3539   +27
=====================================
+ Hits       16649   16721   +72
- Misses      4985    5000   +15
- Partials    1441    1447    +6

Impacted Files
Coverage Δ

...rc/client/common/process/pythonExecutionFactory.ts
79% <ø> (ø)

...ce/raw-kernel/liveshare/hostRawNotebookProvider.ts
76% <ø> (ø)

.../datascience/notebook/notebookControllerManager.ts
73% <25%> (-2%)
:arrow_down:

...client/datascience/kernel-launcher/jupyterPaths.ts
70% <58%> (+2%)
:arrow_up:

...t/datascience/kernel-launcher/localKernelFinder.ts
82% <71%> (-1%)
:arrow_down:

src/client/logging/trace.ts
82% <85%> (+4%)
:arrow_up:

src/client/api/pythonApi.ts
70% <100%> (+1%)
:arrow_up:

src/client/common/installer/productInstaller.ts
62% <100%> (+<1%)
:arrow_up:

src/client/common/process/processFactory.ts
90% <100%> (+<1%)
:arrow_up:

src/client/common/utils/decorators.ts
78% <100%> (ø)

... and 31 more

authors: DonJayamanne codecov-commenter


text:
Completion no longer working

Hello! I noticed recently that part of our LSP completion stopped working. I'm trying to figure out what happened, but I'm having some trouble and I would appreciate some guidance.
VS Code version: 1.83.1
vscode-languageclient version: 9.0.1
We provide completion for two things at the moment: require paths (which are like imports in TypeScript, but for Ruby) and constants. For some reason, only the require path completion stopped working.
Here you can see the behaviour working properly in the beginning of the GIF https://github.com/Shopify/vscode-ruby-lsp?tab=readme-ov-file#features.
This is our server capabilities for completion. The path completion happens on the / char (which isn't working anymore). Constant completion happens on any uppercase char and that continues to work fine.
{
  triggerCharacters: ["/", "A", "B", "C", "..."], // forward slash + all uppercase chars
  resolveProvider: false,
  completionItem?: {
    labelDetailsSupport?: true;
  }
}

For the path completion, we return an array that looks like this.
[
  {
    label: "ruby_lsp/listener",
    text_edit: {
      range: { ... },
      new_text: "ruby_lsp/listener",
    },
    kind: 18, // REFERENCE
  }
]

If I turn on verbose tracing for our server, I can see that the completion request is correctly returning an array of items like the one above when I press /, but nothing happens in the editor. It's really odd because constant completion continues to work as expected.
I thought it might be related to the languageDetailsSupport configuration, but so far no luck. I have tried:

Adding a labelDetails attribute to the response
Adding a documentation attribute to the response
Adding a detail attribute to the response
Removing the labelDetailsSupport capability
Downgrading vscode-languageclient

Any ideas on what I am missing? Should we be returning something else for the path completions?

The easiest way to find out what is going on is to debug this. The corresponding code is in completion.js in the client modules lib/common folder. The code in question is on line 94
return client.protocol2CodeConverter.asCompletionResult(result, defaultCommitCharacters, token);

result contains the items return from the server. They are then converted into VS Code items. Would be good to know how many are handed off to VS Code.

Let me know how it goes.

@vinistock actually the results look fine. I suspect that this is more a VS Code bug. Toi confirm this you could do the following:

implement a test extension that returns completion items as a hard coded list
do this using only a VS Code completion item provider.

I can provide you with a skeleton extension if it is of any help

Finally figured out the issue. We switched to using the new Ruby parser recently and I had not realized that it includes the string quotes as part of its node locations. We were returning off by one characters to the editor, which then didn't match the expected contents and VS Code refused to apply them.
It's working now after https://github.com/Shopify/ruby-lsp/pull/1203. Sorry for the confusion and thank you very much for your assistance!

authors: dbaeumer vinistock

repo: microsoft/vscode-languageserver-node

license: mit

license_source: bigquery


text:
preview

the preview is not loading to appear in split screen and not updating automaticallu

What do you have livePreview.autoRefreshPreview set to in your settings?

actually when I tried to change local ip address through in live preview it shows me the following error"198.168.1.101 is not in correct format" and it changes it to default one

live preview is not working properly

@Omnikam00007 @Deeraj1509 Does the issue still persist at your end?

repo: microsoft/vscode-livepreview


text:
Owner dropdown should list me first

I.e. put the creator of a PR first:

@bpasero do you want the creator first or you first?

@alexr00 I would mimic what GH does when I open the dropdown, I think it has a way to suggest users that fits best, I would probably put myself and creator of PR as suggestions. Maybe also reviewer.

repo: microsoft/vscode-pull-request-github


text:
Unable to checkout a PR in GitHub Enterprise Server 3.0.22

Type: Bug
Since past few versions, I am not able to checkout PR in VSCode using GitHub Pull Request extension.
PR list is displayed correctly but checkout is not working.
Steps to Reproduce:

From the 'Pull Requests' side panel expand the 'All Open' list
Expand any PR node and choose to checkout the PR.

Expected Results:-

PR should be checked out into the PR view.

Actual Results:-

Error message pop-up displayed 'Failed to resolve Pull Request #<PR_NO> in <BRANCH_NAME>
Error in output tab :
[Info] GithubRepository> Unable to fetch PR: Error: GraphQL error: Field 'autoMergeRequest' doesn't exist on type 'PullRequest'
GraphQL error: Field 'viewerCanEnableAutoMerge' doesn't exist on type 'PullRequest'
GraphQL error: Field 'viewerCanDisableAutoMerge' doesn't exist on type 'PullRequest'

Extension version: 0.49.2022081709
VS Code version: Code 1.70.2 (Universal) (e4503b30fc78200f846c62cf8091b76ff5547662, 2022-08-16T05:36:37.829Z)
OS version: Darwin x64 21.1.0
Modes:
Remote OS version: Linux x64 3.10.0-514.el7.x86_64

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz (12 x 2600)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
3, 4, 5

Memory (System)
16.00GB (0.28GB free)

Process Argv
--crash-reporter-id 4e1a7f74-58fc-4b9a-bed4-13f7d0786d16

Screen Reader
no

VM
0%

Item
Value

Remote
SSH: VA2 Machine-17

OS
Linux x64 3.10.0-514.el7.x86_64

CPUs
QEMU Virtual CPU version 1.5.3 (10 x 2399)

Memory (System)
60.79GB (1.59GB free)

VM
0%

A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscorecescf:30445987
pythondataviewer:30285071
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593:30376534
pythonvs932:30410667
wslgetstarted:30449410
cppdebug:30492333
pylanb8912:30545647
vsclangdc:30486549
c4g48928:30535728
d7fjc500:30543455
dsvsc012:30540252
azure-dev_surveyone:30548225

@saurabh-c-rai I've tested the extension with GitHub Enterprise all the way back to 3.1, and checking out a PR works fine there. 3.0 was deprecated on 2022-02-16. Are you still on 3.0 now (I recognize that you probably don't have control over which version you're on, but I'm hoping you got updated in the last month)?

@alexr00 As luck would have it we are upgrading to GitHub Enterprise 3.4.4 by this week so I guess it won't be an issue anymore. Thanks for your support.

🎉 glad to hear it! If you try out the extension after you're upgraded I recommend either waiting for the next stable release of the extension (probably in 2 weeks) or using the pre-release build. There is PAT-less auth and some general GitHub Enterprise fixes there.


text:
"Disable Jupyter Auto Start" setting does not work

Unchecking the settings box does not lead to Jupyter auto starting.  Jupyter does not start running until I run a cell whether the box is checked or not.
Win 10
latest python extension
latest vscode update
Anaconda 3.7

Thanks for the issue! I am unable to reproduce this issue, when I uncheck the box, the server auto starts for me. Could you send over the console log in developer tools?

Closing due to needing more information.

authors: greazer jmew rholland

repo: microsoft/vscode-python


text:
Moving computing Launch Info into kernelSelector

Here's some code from hostJupyterServer.ts file
    private async computeLaunchInfo(
        resource: Resource,
        sessionManager: IJupyterSessionManager,
        notebookMetadata?: INotebookMetadataLive,
        cancelToken?: CancellationToken
    ): Promise<{ info: INotebookServerLaunchInfo; changedKernel: boolean }> {
        // First we need our launch information so we can start a new session (that's what our notebook is really)
        let launchInfo = await this.waitForConnect();
        if (!launchInfo) {
            throw this.getDisposedError();
        }
        // Create a copy of launch info, cuz we're modifying it here.
        // This launch info contains the server connection info (that could be shared across other nbs).
        // However the kernel info is different. The kernel info is stored as a  property of this, hence create a separate instance for each nb.
        launchInfo = {
            ...launchInfo
        };

        // Determine the interpreter for our resource. If different, we need a different kernel.
        const resourceInterpreter = await this.interpreterService.getActiveInterpreter(resource);

        // Find a kernel that can be used.
        // Do this only if kernel information has been provided in the metadata, or the resource's interpreter is different.
        let changedKernel = false;
        if (
            notebookMetadata?.kernelspec ||
            notebookMetadata?.id ||
            resourceInterpreter?.displayName !== launchInfo.kernelConnectionMetadata?.interpreter?.displayName
        ) {
            const kernelInfo = await (launchInfo.connectionInfo.localLaunch
                ? this.kernelSelector.getKernelForLocalConnection(
                      resource,
                      'jupyter',
                      sessionManager,
                      notebookMetadata,
                      isTestExecution(),
                      cancelToken
                  )
                : this.kernelSelector.getKernelForRemoteConnection(
                      resource,
                      sessionManager,
                      notebookMetadata,
                      cancelToken
                  ));

            if (kernelInfo) {
                launchInfo.kernelConnectionMetadata = kernelInfo;

                // For the interpreter, make sure to select the one matching the kernel.
                launchInfo.kernelConnectionMetadata.interpreter =
                    launchInfo.kernelConnectionMetadata.interpreter || resourceInterpreter;
                changedKernel = true;
            }
        }

        return { info: launchInfo, changedKernel };
    }

Observations

If we have a kernel spec in notebook metadata, then we get the kernel info using getKernelForLocalConnection.
However, the interpreter is updated to point to the local interpreter if theres no interpreter.

Question: Why don't we update the kernelSelector to do this and return the default interpreter
Else code such as native notebooks will never get this same behavior
Are there any drawbacks in doing this? I.e. always defaulting the interpreter to the local active/corresponding interrpeter.
Personally this feels better, i.e. building up launch info in one place.
I.e. what I"m proposing is

interrpreter will always be non-empty in the return value of getKernelForRemoteConnection/getKernelForLocalConnection.

@rchiodo  @IanMatthewHuff Any thoughts

getKernelForRemoteConnection having an interpreter doesn't make any sense though. There's no interpreter that points to the remote machine.

So it should be undefined in that case.

Otherwise yeah seems good to me.

We want the connectionMetadata to be the one stop shop, so seems good. Looks like we might need some renaming in here as well for consistency.

Fixed

authors: DonJayamanne IanMatthewHuff rchiodo


text:
Walrus operator does not assign "suffix" variable in Debug Console

Environment data

VS Code version: 1.54.1
Extension version (available under the Extensions sidebar): v2021.2.633441544
OS and version: Win 10 20H2
Python version (& distribution if applicable, e.g. Anaconda): 3.8.8
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): none
Relevant/affected Python packages and their versions: none
Relevant/affected Python-related VS Code extensions and their versions: none
Value of the python.languageServer setting: not set

Expected behaviour
"x-y".endswith(suffix := "-y") assigns suffix
Actual behaviour

NameError: name 'suffix' is not defined

Steps to reproduce:

Debug Python code
Stop anywhere
Open Debug Console
Enter "x-y".endswith(suffix := "-y")
Enter suffix

Interesting, the same works with bar instead of suffix:

Logs
Nothing particular.

I can't reproduce this with a hello world type script, so the actual code in question probably matters somehow. Can you share it, or at least show the call stack?

For simple assignments, it seems to happen for any string literal that contain two or more __ in a row anywhere. Really weird. And definitely a debugpy issue, as the logs show that VSCode relays the expression correctly.


text:
Broken/Removed virtual environment can not be cleared

Testing #23482
I have an environment that's invalid but already removed (folder removed), but it can never be cleared (Clear Cache and Reload Window doesn't work).
Thus the log always prints following error. The only way to get rid of it is starting with a new user data dir. I ran into this with both JS and Native finder.
2024-05-28 10:28:44.342 [error] Error: Command failed: /Users/penlv/code/work/vscode-jupyter/src/test/datascience/.venvnokernel/bin/python -I /Users/penlv/.vscode-insiders/extensions/ms-python.python-2024.7.0-dev/python_files/get_output_via_markers.py /Users/penlv/.vscode-insiders/extensions/ms-python.python-2024.7.0-dev/python_files/interpreterInfo.py
/bin/sh: /Users/penlv/code/work/vscode-jupyter/src/test/datascience/.venvnokernel/bin/python: No such file or directory

    at ChildProcess.exithandler (node:child_process:423:12)
    at ChildProcess.emit (node:events:526:35)
    at maybeClose (node:internal/child_process:1105:16)
    at Socket.<anonymous> (node:internal/child_process:457:11)
    at Socket.emit (node:events:514:28)
    at Pipe.<anonymous> (node:net:337:12) {
  code: 127,
  killed: false,
  signal: null,
  cmd: '/Users/penlv/code/work/vscode-jupyter/src/test/datascience/.venvnokernel/bin/python -I /Users/penlv/.vscode-insiders/extensions/ms-python.python-2024.7.0-dev/python_files/get_output_via_markers.py /Users/penlv/.vscode-insiders/extensions/ms-python.python-2024.7.0-dev/python_files/interpreterInfo.py'
}

Possible you have this setup as the active environment or the like.
This should not be caused by native locator, hence removing that lablel.

authors: DonJayamanne rebornix


text:
No inline coverage shown

Testing #22827
Unsure if this is expected or not but I don't see any inline coverage even after I toggle it on and off
I see the correct numbers over in the test coverage view

fixed! There was a path bug for windows. I have pushed a new pre-release of the extension out so this can be tested whenever. Thanks!

authors: eleanorjboyd mjbvz


text:
Rename event "datascience.auto_save_enabled"

Rename telemetry event "datascience.auto_save_enabled" to "datascience.settings.auto_save_enabled"

We need to change the name as specified, AND make sure we only send it when data science is being used.

Validated

authors: DonJayamanne greazer ronglums


text:
Using VS Code Custom Editor API

https://github.com/microsoft/vscode/issues/77131
This doesn't include list of menus, messages that might have to be changed.
List of things that might have to be changed/considered

Add support for opening same notebook twice

Will the same notebook share the same execution environment (kernel, etc). I think yes

Separate NotebookEditor into at least two classes, one that handles editor functionality and the other than handles content.

Now that VSC implements editing, we don't need to mix to two. Similar to TextDocument vs TextEditor classes.
We might want to do this now, as we might need to eventually change the editor to use the in progress Notebook Editor from VS Code.
This makes it easier to support two editors that open the same notebook file. As we have a single instance that deals with the content.

Move formatting/exporting to various formats into a separate class

Currently this code is copied in around two/three places.
Saving to ipynb, html, pdf, etc would best be handled by separate classes (things that can be plugged in). Note: mentioning as we have some code related to exporting in NotebookEditor class.

Remove auto-save functionality
Ensure we load standard vscode diff viewer when user views the changes in source control.

let me know if you need a hand with that :)

@RandomFractals
Thanks for your feedback and offering your help.
At this stage we don't have any concerns with the VSCode API. I'm happy with the way it's been designed.
I was merely highlighting the changes we need to make within our extension. E.g. when opening an editor, the backed data source should be a Singleton, one that handles multiple views, just as it is today in VSCode. It's basically an (technical design) issue at our end.
I have just one question/issue upstream, when dealing with git/source control diff view.

authors: DonJayamanne RandomFractals


text:
use rust lang's analyzer

Update the extension name to "rust-lang.rust-analyzer" which seems to be the Rust Lang's supported rust-analyzer extension. I believe rust.analyzer was accepted by Rust Lang as the new LSP implementation for Rust.

This has been updated!

authors: Chuxel therapon

repo: microsoft/vscode-remote-try-rust


text:
Starting with vscode 1.43 non-ascii characters with braces and parentheses are not rendered correctly

Issue Type: Bug
I tried it with extensions disabled.
put the following line in a .lua file
note: also happens with other languages, it just happens that I was using lua.
what = (["على"] . ("محموله"))

this is how it looks in version 1.42.1

and this is in  the versions after

VS Code version: Code 1.46.0 (a5d1cc28bb5da32ec67e86cc50f84c67cc690321, 2020-06-10T08:59:04.923Z)
OS version: Linux x64 5.4.0-7634-generic

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz (12 x 4000)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: unavailable_offrasterization: disabled_softwareskia_renderer: disabled_off_okvideo_decode: unavailable_offviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_off_okwebgl: enabledwebgl2: enabled

Load (avg)
2, 1, 1

Memory (System)
31.01GB (20.07GB free)

Process Argv
--no-sandbox

Screen Reader
no

VM
0%

DESKTOP_SESSION
pop

XDG_CURRENT_DESKTOP
Unity

XDG_SESSION_DESKTOP
pop

XDG_SESSION_TYPE
x11

Extensions: none

I have the same Issue I am running vscode version 1.45 on windows.

Thanks, but I don't think the solution cover all the cases, this is in version 1.65.2

Which should look like this if rendered correctly

authors: Abdullah-AlAttar MustafaAbdalwahab

repo: microsoft/vscode


text:
SCM: Allow different providers sort order

Especially for folks with dozens of source code providers, it would be helpful to have options to sort the providers parametrically, rather than load order.
In the source control providers currently get:
development-tools
common
image_processing
I would like the option to get:
common
development-tools
image_processing
-Or-
image_processing
development-tools
common

This! Its especially annoying when a newly opened repo is not added to the list but is somewhere in the middle of the unsorted list.
Even the screenshot from the new unified Source Control list shows an unsorted list.


text:
Underlines of problems are glitched since switching to electron 9

VSCode Version: 1.48+
OS Version: linux 64

Steps to Reproduce:
Started occuring after electron was updated to 9. Didn't happen on electron 8 and 7.

Since electron 9, all underlines of problems (errors, warnings, infos) are visually wrong.

I'm aware of the fact, that electron 9 support was reverted, just letting you know, this probably needs to be addressed before switching to electron 9.

@deepak1556  Assigning to you as it is electron 9 related. Let me know if I have to do something while it is being adopted. Thanks.

Can we create a minimal repro with chromium so that a bug report can be created in upstream issue tracker.
/cc @alexdima I remember you had some similar issue upstream wrt to underline ?

Can we create a minimal repro with chromium so that a bug report can be created in upstream issue tracker.

Can I help with this? If yes, then, how?

@PF4Public what are the steps to repro this in vscode ?

Simplest would be to create an empty Javascript file and trigger a syntax error, like this:

Unable to repro with electron 9, what is the theme you are using ?

I'm using Monokai Dimmed Theme.
My screen has ~142 dpi, could it be related to that?

Tried that dpi along with the theme, still same issue
demohan@ubuntu:~$ xdpyinfo | grep resolution
  resolution:    142x142 dots per inch

are you able to repro on any other OS ?
also can you check if the issue disappears when you run with

--disable-gpu
--disable-features="LayoutNG"

also can you check if the issue disappears when you run with

--disable-gpu
--disable-features="LayoutNG"

None of these helped.
I tried with developer tools and come across a peculiar thing with
document.querySelector("#workbench\\.parts\\.editor > div.content > div.grid-view-container > div > div > div > div.split-view-container > div > div > div.editor-container > div > div > div.overflow-guard > div.monaco-scrollable-element.editor-scrollable.vs-dark > div.lines-content.monaco-editor-background > div.view-overlays > div:nth-child(1) > div.cdr.squiggly-error")

By default its height is 19 and it looks glitched:

Turns out any uneven value here corrupts it, like 17 or 15:

Even numbers are good, like 16:

Or 20:

With every resize this height (19px) gets recalculated for every line:

Changing editor font size gives similar results.
Default is 14:

Here is 15:

Any higher value does not corrupt the underline.
Here is 13:

12 Does not corrupt, but 11 does in a weird way:

10 and 9 are fine:

Unlike 11, 8 does it differently:

Thanks, thats helpful info!
I am still unable to repro with those sizes, one thing I would like to try is change my font family to what you are using. Can you provide the details.
also looping in @rebornix for additional thoughts on debugging

change my font family to what you are using. Can you provide the details.

It is "Fira Code"
Updating Electron to 9.2 didn't help either.
I have remembered that my screen's true dpi is 141,76744186 by 141,402061856 and Xorg was fine with determining it. At some point I did however set my dpi to 142 via my Desktop environment settings (xfce if you're curious). So I tried to revert this setting to "by default" or "unset". And this solved the issue. Should I set my dpi to 142 again, I see glitched underlines again.
In this light this looks like a Chromium/Electron issue. But I couldn't recreate this issue in Chromium 84. Either it is fixed there, or my test was incomplete:

Perhaps you could provide me with a test-html excerpt, that I could test in Chromium 84.
How could we proceed next?

The editor at https://microsoft.github.io/monaco-editor/ is the same editor as in VS Code, just a bit older at this point, so it could be used to try to repro outside of Electron, in Chromium.

Unfortunately, cannot recreate this in Chromium 85:

I have updated Electron to 11 and compiled vscode from master and no longer can reproduce this issue. Looks like it is indeed fixed in 11. Should I close this issue, or wait till next release of vscode arrives, test again and only then close it?

I would leave this open till insiders with electron 11 goes out.


text:
MOVE CURSOR TO TERMINAL AFTER RUN( ctrl+alt+n)

Issue Type: Feature Request
The following stuff is important for the user who don't use mouse so ofent. I have to drag my mouse to the terminal everytime I run the code which is time consuming when you debugging a big chunk of code or even when am using codeforces as time delay is there. Secondly, this is bit irritating.
I have demonstrated in a video what the issues is .   https://youtu.be/FJTbr8wLf9I
VS Code version: Code 1.48.0 (db40434f562994116e5b21c24015a2e40b2504e6, 2020-08-13T07:50:42.600Z)
OS version: Windows_NT x64 10.0.19041

ctrl+` can be used after you run to focus the terminal.

authors: Tyriar hrittikhere


text:
[themes] 'Generate Color Scheme From Current Settings' produces deprecated settings

VSCode Version: 1.48.1
OS Version: macOS 10.15.6

Steps to Reproduce:

Open Command Palette
Type 'Developer: Generate Color Scheme From Current Settings'
See warnings in the Problems view:

Deprecated color settings:

editorGroup.background
editorActiveLineNumber.foreground

tokenColors warnings:

Font style must be 'italic', 'bold' or 'underline' or a combination or the empty string.
Token background colors are currently not supported.

Does this issue occur when all extensions are disabled?: I assume so

Closing as stale issue


text:
Typescript died

Issue Type: Bug
I use a mac. The version 1.48.2, regulary colpase with typescript, the lint, the proposal solution with imports died, I have to restart the mac to get solved
VS Code version: Code 1.48.1 (3dd905126b34dcd4de81fa624eb3a8cbe7485f13, 2020-08-19T17:09:41.484Z)
OS version: Darwin x64 19.6.0

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-7267U CPU @ 3.10GHz (4 x 3100)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_off_okwebgl: enabledwebgl2: enabled

Load (avg)
4, 4, 3

Memory (System)
8.00GB (0.02GB free)

Process Argv
.

Screen Reader
no

VM
0%

Extensions (6)

Extension
Author (truncated)
Version

go
gol
0.16.1

plantuml
jeb
2.13.13

vscode-docker
ms-
1.5.0

mssql
ms-
1.9.0

vscode-typescript-tslint-plugin
ms-
1.2.3

partial-diff
ryu
1.4.1

Does this reproduce in the latest VS Code insiders build with all extensions disabled?

authors: marcogamaliel mjbvz


text:
Allow ability to do Search In Files (cmd+shift+f command) the way as in Sublime Text

In Sublime Text, when you do cmd+shift+f global search, the window opens in the bottom of the editor like so:

Then when you start a search, the results get opened in separate tab like so:

You get to see both the matches and also surrounding text. Then you can press return on a line to open the file in the editor.
In VSCode the same searches are forced to be done in the sidebar:

They lose context of surrounding files. You can press cmd+return to open the results in a separate file like so:

But you can't press return to open the file where the line is found in the editor. Plus if I press cmd+shift+f again, the focus goes here:

And not here:

Is it possible to achieve the Sublime global text search workflow in VSCode?

Perhaps I should create an issue for Add ability to press return in search results to go to file of the result?

I opened the issue here https://github.com/microsoft/vscode/issues/107025

You can drag search to panel which is by default at the bottom

I don't get how to do this.

What should I drag?

Also added this in settings:
  "search.searchEditor.defaultNumberOfContextLines": 2,
But still search shows no context:

I reran the search again.

If you need to focus input while cursor is somewhere in Search editor - Esc will do that.

What do you mean by input here. Also escape for me does nothing. I use vim extension so escape will go from insert to normal mode but in normal mode, escape does nothing. Perhaps it's a clash?

so Ctrl+Click or double click (by default) on Search results line performs navigation.

cmd+click does nothing. so is ctrl+click on VS Code insiders. Perhaps vim extension is blocking it, I'll check.

cmd+click does nothing. so is ctrl+click on VS Code insiders. Perhaps vim extension is blocking it, I'll check.

It's whatever "go to definition" is mapped to. Peek definition, open definition to side, etc, all also work.

What do you mean by input here. Also escape for me does nothing. I use vim extension so escape will go from insert to normal mode but in normal mode, escape does nothing. Perhaps it's a clash?

You can try searching "Search Editor: Focus Input" in command palette to see what the keybinding is.

But still search shows no context:

Only editors will show context, the sidebar will never show context

Is it possible to map return in sidebar global search to do what cmd+return does?

As there is no point in actually pressing return here:

Since the results get updated live as you type and you can cmd+down-arrow to go to them.

I'd rather map return to directly open the search results in the file.
Also would be nice to be able to map down arrow to do same as cmd-down-arrow in the sidebar search as I never use multi line to do global searches and want to just use down arrow to start going through results in sidebar.

What should I drag?

Open bottom panel (usually Terminal, Problems etc. are there)
Drag search icon from Action bar on the side to bottom panel tabs row, you should see vertical line where it will be placed.
Other were answered - context is only for editor that you already showed, keybindings are provided for default (Windows) config, so if you use Vim extension - you might need to redefine keybindings.
As for Enter  - responded in separate issue - you need to map to existing action whatever you want

As @IllusionMH has said, almost all keybindings can be configured in the editor, you can read here for more info: https://code.visualstudio.com/docs/getstarted/keybindings

I don't think this is exactly what you are looking for, but if you name a file with the extension .code-search, it gives you a search editor.
Here is a screenshot of an example.

@nrayburn-tech You can also run the command "Open Search Editor" :)

Also, I don't believe there are any open requests in this issue, going to close as question.

authors: IllusionMH JacksonKearl nikitavoloboev nrayburn-tech