Git does not show gutters unless file is opened from changed files tab

Version: 1.42.0 (system setup)
Commit: ae08d5460b5a45169385ff3fd44208f431992451
Date: 2020-02-06T10:51:34.058Z
Electron: 6.1.6
Chrome: 76.0.3809.146
Node.js: 12.4.0
V8: 7.6.303.31-electron.0
OS: Windows_NT x64 10.0.18362
Steps to Reproduce:

The steps to reproduce are exactly the same as Bug# https://github.com/Microsoft/vscode/issues/41642. However, I haven't tried changing settings in settings.json file. I'm unable to paste GIFs here since that is against my company policy.

Expected result: gutters should be visible when a git tracked files has changes
Actual result: gutters are only visible when the file is opened the way it is depicted in #41642
Does this issue occur when all extensions are disabled?: Yes (only gitlens was installed)
More info:  The log below is from GitLens, but I feel that the issue is VSCode Git itself. Thus, opening it here. Both gutters and line blames in gitlens start working as soon as I open the file from the changes tab by right clicking on Open File.
GitLens log:

[2020-02-12 22:43:51:347] [251] GitService.getRepoPath
[2020-02-12 22:43:51:347] [252] GitService.getRepository
[2020-02-12 22:43:51:465] [c:/_repos/some_path] git ls-files -- foo/bar/lib/some_folder/some_file.rb • 116 ms
[2020-02-12 22:43:51:465] [257] GitService.isTracked returned false • 116 ms
[2020-02-12 22:43:51:465] [252] GitService.getRepository returned undefined • 117 ms
[2020-02-12 22:43:51:562] [c:_repos\some_path\foo\bar\lib\some_folder] git rev-parse --show-toplevel • 96 ms
[2020-02-12 22:43:51:562] [251] GitService.getRepoPath returned c:/_repos/some_path • 214 ms
[2020-02-12 22:43:51:562] [259] GitService.getRepository
[2020-02-12 22:43:51:562] [259] GitService.getRepository returned c:/_repos/some_path • 0 ms
[2020-02-12 22:43:51:650] [c:/_repos/some_path] git ls-files -- c:_repos\some_path\foo\bar\lib\some_folder\some_file.rb • 87 ms
[2020-02-12 22:43:51:650] [25a] GitService.isTracked returned false • 87 ms
[2020-02-12 22:43:57:132] [272] GitService.isTracked returned false • 0 ms
[2020-02-12 22:43:57:909] [286] GitService.isTracked returned false • 0 ms
[2020-02-12 22:44:10:276] [2ae] GitService.getRepoPath
[2020-02-12 22:44:10:276] [2af] GitService.getRepository
<------------------ This is where I right clicked and selected Open File from the changes tab ----------------->
[2020-02-12 22:44:10:404] [c:/_repos/some_path] git ls-files -- foo/bar/lib/some_folder/some_file.rb • 126 ms
[2020-02-12 22:44:10:404] [2b0] GitService.isTracked returned true • 126 ms
[2020-02-12 22:44:10:404] [2af] GitService.getRepository returned c:/_repos/some_path • 128 ms
[2020-02-12 22:44:10:404] [2ae] GitService.getRepoPath returned c:/_repos/some_path • 129 ms
[2020-02-12 22:44:10:405] [2b1] GitService.getRepository
[2020-02-12 22:44:10:405] [2b1] GitService.getRepository returned c:/_repos/some_path • 0 ms
[2020-02-12 22:44:10:504] [c:/_repos/some_path] git ls-files -- c:_repos\some_path\foo\bar\lib\some_folder\some_file.rb • 98 ms
[2020-02-12 22:44:10:504] [2b2] GitService.isTracked returned true • 99 ms
[2020-02-12 22:44:10:506] [2b3] GitService.getBlameForFile
[2020-02-12 22:44:10:509] [2b4] GitService.isTracked returned true • 0 ms
[2020-02-12 22:44:10:531] [2b5] GitService.getBlameForLine
[2020-02-12 22:44:10:531] [2b6] GitService.getBlameForFile
[2020-02-12 22:44:10:622] [c:/_repos/some_path] git blame --root --incremental -- foo/bar/lib/some_folder/some_file.rb • 112 ms
[2020-02-12 22:44:10:623] [2b7] GitService.getCurrentUser
[2020-02-12 22:44:10:623] [2b7] GitService.getCurrentUser completed • 0 ms
[2020-02-12 22:44:10:628] [2b3] GitService.getBlameForFile completed • 122 ms
[2020-02-12 22:44:10:628] [2b6] GitService.getBlameForFile completed • 96 ms
[2020-02-12 22:44:10:628] GitCodeLensProvider.provideCodeLenses: — 54 symbol(s) found
[2020-02-12 22:44:10:632] [2b5] GitService.getBlameForLine completed • 101 ms
[2020-02-12 22:44:14:796] [2c2] GitService.getBlameForLine
[2020-02-12 22:44:14:796] [2c3] GitService.getBlameForFile
[2020-02-12 22:44:14:797] [2c3] GitService.getBlameForFile completed • 0 ms
[2020-02-12 22:44:14:797] [2c2] GitService.getBlameForLine completed • 0 ms

My git config:

diff.astextplain.textconv=astextplain
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
http.sslbackend=openssl
http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
core.autocrlf=false
core.fscache=true
core.symlinks=false
core.editor="C:\Program Files\Microsoft VS Code\Code.exe" --wait
credential.helper=manager

Can you show me the full output of Git: Show Git Output?

Here is the git output (replaced by project name with some_folder):

git show :Orchestrator/ORC_Tools/lib/ssh_base.rb
git ls-files --stage -- C:_repos\some_folder\Orchestrator\ORC_Tools\lib\ssh_base.rb
git show :Orchestrator/ORC_Tools/lib/ssh_base.rb
git ls-files --stage -- C:_repos\some_folder\Orchestrator\ORC_Tools\lib\ssh_base.rb
git status -z -u
git symbolic-ref --short HEAD
git rev-parse virt_image
git rev-parse --symbolic-full-name virt_image@{u}
git rev-list --left-right virt_image...refs/remotes/origin/virt_image
git for-each-ref --format %(refname) %(objectname)
git remote --verbose
git config --get commit.template
<--- this is where i opened it again by right clicking and ....--->
git show :orchestrator/orc_tools/lib/ssh_base.rb
git ls-files --stage -- C:_repos\some_folder\orchestrator\orc_tools\lib\ssh_base.rb
git cat-file -s 176f53d0ac43a2e16010a658a6a67f0ed08569d2

I guess I figured out the issue:
This is due to Windows's ignore case. If one looks at the first few lines, one can see the path in Caps. At this point of time, the file is opened from the Explorer View (as per gitlens, the file is not tracked). If one makes a change now, it shows up in Source Control and this tab has the correct (all lower case) path and when someone opens it from there, the tracking is fixed and git gutters and GitLens work fine.
I have tried git config --global core.ignorecase true, but that too did not help.
This not only needs to be fixed from a repository end, I believe this should be fixed in VSCode too, where Windows ignores case and does a merge on the folder and thus, git losing all the tracking.

What Git version do you have? The latest 2.25 has known Windows casing issues: https://github.com/git-for-windows/git/issues/2499 https://github.com/git-for-windows/git/issues/2478
We already have a casing fix in the insider release, can you give that a try?

Yes. This is reproducible on
Version: 1.43.0-insider (system setup)
Commit: 595f98455be0aac7372a0ae7841efae9b91b848e
Date: 2020-02-18T13:52:42.988Z
Electron: 7.1.11
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.18362
I downgraded to 2.24 and that version too has the same issue.
$ git config --list
diff.astextplain.textconv=astextplain
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
http.sslbackend=openssl
http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
core.autocrlf=false
core.fscache=true
core.symlinks=true
core.editor="C:\\Program Files\\Microsoft VS Code\\Code.exe" --wait
credential.helper=manager
color.ui=auto
user.name=Rohan Sekhri
<EMAIL_ADDRESS>mergetool.sourcetree.cmd=''
mergetool.sourcetree.trustexitcode=true
core.ignorecase=true

 ~
$ git --version
git version 2.24.0.windows.2

Could you maybe show me the full Git Output after opening that folder?

Here is the git output from Insiders (used it since you mentioned it has a fix related to casing)
Open repository: c:\_repos\some_folder
> git status -z -u
> git symbolic-ref --short HEAD
> git rev-parse virt_image
> git rev-parse --symbolic-full-name virt_image@{u}
> git rev-list --left-right virt_image...refs/remotes/origin/virt_image
> git for-each-ref --format %(refname) %(objectname) --sort -committerdate
> git remote --verbose
> git check-ignore -v -z --stdin
> git config --get commit.template
> git check-ignore -v -z --stdin
> git show :Orchestrator/ORC_Tools/lib/ssh_base.rb
> git ls-files --stage -- C:\_repos\some_folder\Orchestrator\ORC_Tools\lib\ssh_base.rb
> git status -z -u
> git symbolic-ref --short HEAD
> git rev-parse virt_image
> git rev-parse --symbolic-full-name virt_image@{u}
> git rev-list --left-right virt_image...refs/remotes/origin/virt_image
> git for-each-ref --format %(refname) %(objectname) --sort -committerdate
> git remote --verbose
> git config --get commit.template
> git check-ignore -v -z --stdin
> git show :orchestrator/orc_tools/lib/ssh_base.rb
> git ls-files --stage -- C:\_repos\some_folder\orchestrator\orc_tools\lib\ssh_base.rb
> git cat-file -s 176f53d0ac43a2e16010a658a6a67f0ed08569d2
> git check-ignore -v -z --stdin

GitLens output:
[2020-02-19 14:29:38:435] [1] GitService.initialize
[2020-02-19 14:29:38:435] [2] GitService.getBuiltInGitApi
[2020-02-19 14:29:38:572] [2] GitService.getBuiltInGitApi completed • 136 ms
[2020-02-19 14:29:38:673] Git found: 2.24.0.windows.2 @ C:\Program Files\Git\cmd\git.exe • 101 ms
[2020-02-19 14:29:38:673] [1] GitService.initialize completed • 238 ms
[2020-02-19 14:29:38:676] Starting repository search in 1 folders
[2020-02-19 14:29:38:676] [3] GitService.repositorySearch(c:\_repos\some_folder) searching (depth=1)...
[2020-02-19 14:29:38:690] [6] LineAnnotationController.resume
[2020-02-19 14:29:38:691] [6] LineAnnotationController.resume completed • 0 ms
[2020-02-19 14:29:38:715] GitLens (v10.2.1) activated • 282 ms
[2020-02-19 14:29:38:716] [c] GitService.getRepository
[2020-02-19 14:29:38:779] [c:\_repos\some_folder] git rev-parse --show-toplevel • 102 ms
[2020-02-19 14:29:38:780] [3] GitService.repositorySearch(c:\_repos\some_folder) found root repository in 'c:/_repos/some_folder'
[2020-02-19 14:29:38:789] [3] GitService.repositorySearch(c:\_repos\some_folder) returned 1 repositories (c:/_repos/some_folder) • 112 ms
[2020-02-19 14:29:38:912] [c:/_repos/some_folder] git remote -v • 105 ms
[2020-02-19 14:29:38:926] [c] GitService.getRepository returned undefined • 210 ms
[2020-02-19 14:29:38:927] [1d] GitService.isTracked returned false • 0 ms
[2020-02-19 14:29:56:860] [23] GitService.getRepoPath
[2020-02-19 14:29:56:860] [24] GitService.getRepository
[2020-02-19 14:29:56:960] [c:/_repos/some_folder] git ls-files -- Orchestrator/ORC_Tools/lib/ssh_base.rb • 97 ms
[2020-02-19 14:29:56:960] [29] GitService.isTracked returned false • 98 ms
[2020-02-19 14:29:56:960] [24] GitService.getRepository returned undefined • 99 ms
[2020-02-19 14:29:57:055] [c:\_repos\some_folder\Orchestrator\ORC_Tools\lib] git rev-parse --show-toplevel • 95 ms
[2020-02-19 14:29:57:056] [23] GitService.getRepoPath returned c:/_repos/some_folder • 196 ms
[2020-02-19 14:29:57:056] [2b] GitService.getRepository
[2020-02-19 14:29:57:056] [2b] GitService.getRepository returned c:/_repos/some_folder • 0 ms
[2020-02-19 14:29:57:145] [c:/_repos/some_folder] git ls-files -- c:\_repos\some_folder\Orchestrator\ORC_Tools\lib\ssh_base.rb • 88 ms
[2020-02-19 14:29:57:146] [2c] GitService.isTracked returned false • 89 ms
[2020-02-19 14:30:05:092] [44] GitService.isTracked returned false • 0 ms
[2020-02-19 14:30:11:326] [5d] GitService.getRepoPath
[2020-02-19 14:30:11:326] [5e] GitService.getRepository
[2020-02-19 14:30:11:426] [c:/_repos/some_folder] git ls-files -- orchestrator/orc_tools/lib/ssh_base.rb • 99 ms
[2020-02-19 14:30:11:427] [5f] GitService.isTracked returned true • 100 ms
[2020-02-19 14:30:11:427] [5e] GitService.getRepository returned c:/_repos/some_folder • 101 ms
[2020-02-19 14:30:11:427] [5d] GitService.getRepoPath returned c:/_repos/some_folder • 101 ms
[2020-02-19 14:30:11:427] [60] GitService.getRepository
[2020-02-19 14:30:11:428] [60] GitService.getRepository returned c:/_repos/some_folder • 0 ms
[2020-02-19 14:30:11:516] [c:/_repos/some_folder] git ls-files -- c:\_repos\some_folder\orchestrator\orc_tools\lib\ssh_base.rb • 88 ms
[2020-02-19 14:30:11:516] [61] GitService.isTracked returned true • 88 ms
[2020-02-19 14:30:11:538] [62] GitService.getBlameForFile
[2020-02-19 14:30:11:540] [63] GitService.isTracked returned true • 0 ms
[2020-02-19 14:30:11:584] [64] GitService.getBlameForLine
[2020-02-19 14:30:11:584] [65] GitService.getBlameForFile
[2020-02-19 14:30:11:722] [c:/_repos/some_folder] git blame --root --incremental -- orchestrator/orc_tools/lib/ssh_base.rb • 181 ms
[2020-02-19 14:30:11:722] [66] GitService.getCurrentUser
[2020-02-19 14:30:11:811] [c:/_repos/some_folder] git config --get-regex user.(name|email) • 88 ms
[2020-02-19 14:30:11:893] [c:/_repos/some_folder] git check-mailmap Rohan Sekhri<EMAIL_ADDRESS>• 81 ms
[2020-02-19 14:30:11:894] [66] GitService.getCurrentUser completed • 171 ms
[2020-02-19 14:30:11:897] [62] GitService.getBlameForFile completed • 358 ms
[2020-02-19 14:30:11:897] [65] GitService.getBlameForFile completed • 312 ms
[2020-02-19 14:30:11:898] [64] GitService.getBlameForLine completed • 314 ms
[2020-02-19 14:30:12:164] [6d] GitService.getBlameForRangeSync
[2020-02-19 14:30:12:164] [6d] GitService.getBlameForRangeSync completed • 0 ms
[2020-02-19 14:30:15:088] [72] GitService.getBlameForLine
[2020-02-19 14:30:15:088] [73] GitService.getBlameForFile
[2020-02-19 14:30:15:088] [73] GitService.getBlameForFile completed • 0 ms
[2020-02-19 14:30:15:088] [72] GitService.getBlameForLine completed • 0 ms
[2020-02-19 14:30:16:889] [7c] GitService.getBlameForLine
[2020-02-19 14:30:16:889] [7d] GitService.getBlameForFile
[2020-02-19 14:30:16:890] [7d] GitService.getBlameForFile completed • 0 ms
[2020-02-19 14:30:16:890] [7c] GitService.getBlameForLine completed • 0 ms
[2020-02-19 14:30:17:709] [82] GitService.getCommitForFile
[2020-02-19 14:30:17:709] [83] GitService.getLogForFile
[2020-02-19 14:30:17:711] [84] GitService.getDiffForLine
[2020-02-19 14:30:17:711] [85] GitService.getDiffForFile
[2020-02-19 14:30:17:802] [c:/_repos/some_folder] git ls-files -- orchestrator/orc_tools/lib/ssh_base.rb • 90 ms
[2020-02-19 14:30:17:802] [86] GitService.isTracked returned true • 90 ms
[2020-02-19 14:30:17:820] [c:/_repos/some_folder] git show -M --format= --minimal -U0 30ae25d9238778919145133cee8761be583204e2 -- orchestrator/orc_tools/lib/ssh_base.rb • 95 ms
[2020-02-19 14:30:17:821] [85] GitService.getDiffForFile completed • 109 ms
[2020-02-19 14:30:17:822] [84] GitService.getDiffForLine completed • 110 ms
[2020-02-19 14:30:18:070] [c:/_repos/some_folder] git log --format=%x3c%x2ff%x3e%n%x3cr%x3e%x20%H%n%x3ca%x3e%x20%aN%n%x3ce%x3e%x20%aE%n%x3cd%x3e%x20%at%n%x3cc%x3e%x20%ct%n%x3cp%x3e%x20%P%n%x3cs%x3e%n%B%n%x3c%x2fs%x3e%n%x3cf%x3e -n2 --follow --numstat --summary 30ae25d9238778919145133cee8761be583204e2 -- orchestrator/orc_tools/lib/ssh_base.rb • 266 ms
[2020-02-19 14:30:18:070] [89] GitService.getCurrentUser
[2020-02-19 14:30:18:070] [89] GitService.getCurrentUser completed • 0 ms
[2020-02-19 14:30:18:073] [83] GitService.getLogForFile completed • 364 ms
[2020-02-19 14:30:18:073] [82] GitService.getCommitForFile completed • 364 ms
[2020-02-19 14:30:18:073] [8b] GitService.getRemotes
[2020-02-19 14:30:18:074] [8c] GitService.getRepository
[2020-02-19 14:30:18:074] [8c] GitService.getRepository returned c:/_repos/some_folder • 0 ms
[2020-02-19 14:30:18:074] [8b] GitService.getRemotes completed • 0 ms

Another piece of information: I added a file under orchestrator/orc_tools/lib/foo_folder and it is being tracked as expected.

You can omit GitLens output from now on, it's a separate extension.
It looks like everything is working, from the output.

Another piece of information: I added a file under orchestrator/orc_tools/lib/foo_folder and it is being tracked as expected.

So... there are paths which work, and others which don't? Can you try to distill what the rule is?

Already done that in my previous comment:
Paths with: C:\_repos\some_folder\orchestrator\orc_tools\lib\ssh_base.rb work and paths with C:\_repos\some_folder\Orchestrator\ORC_Tools\lib\ssh_base.rb don't (note the capital O's in the second one). If one opens the file from File Explorer, the latter path is taken and if one opens from the Source Control tab in VSCode, the former is taken, which is correct.
Take a look at the git bash output below. It seems to be ignoring the case in path:
 **/c/_repos/some_folder/Orchestrator/ORC_Tools (virt_image)**  --> paths have capital Os
$ git status
On branch virt_image
Your branch is up to date with 'origin/virt_image'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   **../../orchestrator/orc_tools/lib/ssh_base.rb**  --> path has lowercase 'o'

VSCode is treating them as different paths, else i would see just one instance of the file. The one on the right in the image below is tracked.

Hope all this helps. :)

Can you show me the very first lines of the git output, which show which git.exe Code is using?

Looking for git in: C:\Program Files\Git\cmd\git.exe
Using git 2.24.0.windows.2 from C:\Program Files\Git\cmd\git.exe
git rev-parse --show-toplevel
git rev-parse --git-dir
Open repository: c:\xxxxxxxxxx
git fetch
git status -z -u
git symbolic-ref --short HEAD

I'm having the same exact issue as described in this ticket. I'm running version 1.43.0 on a Darwin x64 19.2.0 OS connected to a remote server using the Remote-SSH extension. I can only see the gutters after I've saved a change and then right-clicked to open the file from the Source Control panel. I installed insiders and the problem was still there. Let me know if you need any other info.

I'm having a similar issue (git changes not discovered in file explorer and not shown in editor gutter). I was able to narrow it down to VSC expanding symlink in project path:

my project is placed in WSL in /home/piotr/workspace/project (and .git is here too)
in this path, workspace is a symlink to /mnt/c/Users/Piotr/workspace for my convenience
I open my project in VSC in /home/piotr/workspace/project
VSC opens repository with expanded symlink (/mnt/c/Users/Piotr/workspace)
VSC opens files for editing without expanding the symlink (note the breadcrumbs and which editor has gutter changes):

Show Git output for the file opened as /home/piotr/workspace/project/file.py:
Looking for git in: git
Using git 2.17.1 from git
> git rev-parse --show-toplevel
> git rev-parse --git-dir
Open repository: /mnt/c/Users/Piotr/workspace/carpentries/amy
> git status -z -u
> git symbolic-ref --short HEAD
> git rev-parse rqjob-status
> git rev-parse --symbolic-full-name rqjob-status@{u}
fatal: no upstream configured for branch 'rqjob-status'
> git for-each-ref --format %(refname) %(objectname) --sort -committerdate
> git remote --verbose
> git config --get commit.template
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git check-ignore -v -z --stdin
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git show HEAD:amy/autoemails/actions.py
> git ls-tree -l HEAD -- /mnt/c/Users/Piotr/workspace/carpentries/amy/amy/autoemails/actions.py
> git check-ignore -v -z --stdin
> git show :amy/autoemails/actions.py
> git ls-files --stage -- /mnt/c/Users/Piotr/workspace/carpentries/amy/amy/autoemails/actions.py
> git cat-file -s 2f1adf95480301bc03d56ec6e0ac97f250a4f4a2
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git rev-parse --show-toplevel
> git show :amy/autoemails/actions.py
> git ls-files --stage -- /mnt/c/Users/Piotr/workspace/carpentries/amy/amy/autoemails/actions.py
> git cat-file -s 2f1adf95480301bc03d56ec6e0ac97f250a4f4a2
> git rev-parse --show-toplevel

For now my workaround is to use the longer project path when opening it in VSC.

Seeing the exact same thing with symlinks in WSL, super annoying. Glad I found this, though so I can at least work around it. Whipped up a script that mitigates the issue for the time being...
# Alias for opening files and folders in VS Code
code() {
    target_path=$(readlink -f $1) # resolve the path
    "/mnt/c/Users/Jacob/AppData/Local/Programs/Microsoft VS Code/bin/code" $target_path # open the path
}

Obviously change the path to whatever your path to code is.

Quick update, just whipped up a more robust script that should retain support for all arguments. I'm not great at writing bash scripts, so this may be a bit fragline, and may not cover all use cases, but all flags seemed to work in my testing.
# Modify VS Code CLI to expand symlinks before opening, to fix git status highlighting
code() {
    # Set the path to VS Code
    code_path="/mnt/c/Users/Jacob/AppData/Local/Programs/Microsoft VS Code/bin/code";

    # Store converted arguments
    converted=""

    # Loop through all passed arguments
    for arg in "$@"
    do
        if [[ -d $arg ]] || [[ -f $arg ]]
        then
            # Expand paths, resolving symlinks
            converted="${converted} $(readlink -f $arg)"
        else
            # Retain non-path arguments
            converted="${converted} $arg"
        fi
    done

    # Reconstruct the command
    "$code_path" $converted
}

I confirm this is related to symlinks.
Long story short - our projects were in /var/www/html, we run out of space and we moved them to /data making html symlink to /data/var/www/html:
$ ls -l /var/www/
total 0
lrwxrwxrwx 1 root root 19 Oct  6 09:37 html -> /data/var/www/html/

I can even open the same file two times - once from Explorer, once from Source Control. Note that the breadcumbs are different too.

These screenshots are from the current stable version:
Version: 1.51.1
Commit: e5a624b788d92b8d34d1392e4c4d9789406efe8f
Date: 2020-11-10T23:31:29.624Z
Electron: 9.3.3
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.9.3-1-MANJARO snap
but it is the same on Insiders and on Linux(Manjaro) and Windows 10 working with remote-ssh to the linux machien.
I also tried disabling extensions if it matters.
Thanks to this ticket I simply reopened the projects from the path without symlink and everything works.

Confirming the issue:
When
When Opening VSCode on a FOLDER, then the gutters are always present:

When opening VSCode on a FOLDER, then the gutter change annotations are always present:

When using the logical or absolute path
When opening from the explorer pan or the SCM change pane.

When opening VSCOde on a WORKSPACE, there are issues:

When opening the file from the change pane, the gutter annotations are present.
When opening the file from the explorer pane, the gutter annotations are not present.
It doesn't seem to matter if my WORKSPACE is specified through the logical or the physical path (although my breadcrumbs are ALWAYS on the physical path)

My environment:
$ lsb_release -a
LSB Version:    :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: RedHatEnterpriseServer
Description:    Red Hat Enterprise Linux Server release 7.6 (Maipo)
Release:        7.6
Codename:       Maipo
$ code --version
1.51.0
fcac248b077b55bae4ba5bab613fd6e9156c2f0c
x64
So the "workaround" of starting in the logical path versus physical path doesn't seem to apply in my case...

Can confirm, experiencing this issue when the repo that I open is in a symlink path. When opening the repo through the "real" path, the git gutters work normally.

any updates, have the same issue

@lszomoru and @joaomoreno any update on this one? It's almost 2 years since I opened this. Thank you

@rohansekhri, based on your message I am assuming that you are still able to reproduce the same behaviour with the latest version of VS Code and with the latest version of Git for Windows. I have tried to distill the history of this issue which as you say it's 2 years old and I see that this issue has gone into various directions with various configurations.

Paths with: C:_repos\some_folder\orchestrator\orc_tools\lib\ssh_base.rb work and paths with C:_repos\some_folder\Orchestrator\ORC_Tools\lib\ssh_base.rb don't (note the capital O's in the second one). If one opens the file from File Explorer, the latter path is taken and if one opens from the Source Control tab in VSCode, the former is taken, which is correct.

Are still seeing paths with different casing for a resource in "Explorer" and the "Source Control" view? How do you open the folder/workspace?

Another piece of information: I added a file under orchestrator/orc_tools/lib/foo_folder and it is being tracked as expected.

Are you sill able to add a file in a folder and see that is being tracked as expected?
Could you also try the following and share the contents of the git output channel:

Open VS Code using the --disable-extensions flag and open your folder/workspace
Invoke the Git: Set Log Level... command and set the level to Trace
Modify a file that is being tracked correctly.
Modify a file that is not being tracked correctly.
Could you also please share the value of your files.watcherExclude setting.

I have very similar issue and I noticed one thing:
There is a different path used for opening files from "Explorer" and opening files from "Source control".
It also causes that I can actually open same file twice which can cause further sync/save bugs (I am NOT talking about split screen).
The difference:
When file is opened from VSCODE Explorer - it shows relative path in header:
src > modulepath > somefile.ext ... (src/modulepath/somefile.ext shown on tab)
X
When file is opened from Source control - it shows absolute path in header:
home > myuser > pathtoproject > src > modulepath > somefile.ext ...
The path shown on tab is ~/pathtoproject/src/modulepath/somefile.ext.
So there's clearly there are 2 bugs:

bug in recognizing the path equality by vscode itself
bug in SCM not putting gutters to relative path-opened files.

I am still having this issue in the latest version 1.66.1

@realjjaveweb, thanks for the additional information. Couple of questions:

Do you have any symbolic links on the path of the path that you are opening in VS Code?
How do you open the folder/workspace? Are you using the cli (ex: code folder), or the "File -> Open Folder" menu?
When you open a folder/workspace, could you please share the git output that you can access with the Git: Show Git Output command

@realjjaveweb, thanks for the additional information. Couple of questions:

Do you have any symbolic links on the path of the path that you are opening in VS Code?
How do you open the folder/workspace? Are you using the cli (ex: code folder), or the "File -> Open Folder" menu?
When you open a folder/workspace, could you please share the git output that you can access with the Git: Show Git Output command

@lszomoru

I am not aware, definitely not on the project folder itself, parent folder is bookmarked in Nemo file manager not sure if that can affect it or not
That is actually pretty strange - I usually right click folder and choose open with => Visual Studio Code (most likely the same behavior as with File > Open Folder - and that's where the problem is, if I use terminal command code folder it opens the folder as a whole new project = asks whether to trust authors again and no lastly opened files are there - however - then the problem is not there and the file paths in headers are always relative (in BOTH cases Explorer and Source Control)
This is from open with => Visual Studio Code way

[2022-04-11T18:46:30.142Z] Validating found git in: git
[2022-04-11T18:46:30.180Z] Using git  from git
[2022-04-11T18:46:30.280Z] > git rev-parse --git-dir [29ms]
[2022-04-11T18:46:30.284Z] Open repository: /home/myuser/pathtoproject
[2022-04-11T18:46:30.678Z] > git symbolic-ref --short HEAD [45ms]
[2022-04-11T18:46:30.730Z] > git for-each-ref --format=%(refname)%00%(upstream:short)%00%(objectname)%00%(upstream:track) refs/heads/master refs/remotes/master [24ms]
[2022-04-11T18:46:30.794Z] > git remote --verbose [5ms]
[2022-04-11T18:46:30.795Z] > git for-each-ref --sort -committerdate --format %(refname) %(objectname) %(*objectname) [42ms]
[2022-04-11T18:46:30.970Z] > git config --get commit.template [115ms]

And if I do this for the way code folder the only differing part (besides timestamps and [Nms]s) is this one (note that there's suddenly a git version - not sure if that can mean something or not):
 Using git 2.25.1 from git

@lszomoru correction for 1. - the parent folder is symlinked and yes the problem seems to be sourced there - when I choose open with/open folder in the real location, it acts the same as if opened with code folder. But how is it that both SCM know where the files are therefore know where the .git is but still don't show the gutters? Seems like some wrong path passing from Explorer/Tabs to SCM ?

@realjjaveweb, thank you very much for the clarifications.  The git extension relies on file system events to perform various tasks like refreshing the list of changes, or refresh the diff decorators that are being displayed in the editor gutter. There was explicit work in the past, so that when you open a folder using the cli (ex: code foo) the symbolic links are not resolved. This means that the file system events that are being sent to extensions use URIs that contain the symbolic link instead of the real path of the file.
In the git extension, we use a git command to determine the location of the repository. This git command always resolves symbolic links and there is no way to control that behaviour. This results in a mismatch between the URIs that the git extension receives from VS Code, and the location of the repository as far as the git extension goes.
At the moment, when symbolic links are involved, the only workaround is to open such folders using the "File -> Open Folder" menu as in that case, the OS will resolve the symbolic links (at least based on my tests) and VS Code will use the real path, which will match the one known by the git extension.

@realjjaveweb, thank you very much for the clarifications. The git extension relies on file system events to perform various tasks like refreshing the list of changes, or refresh the diff decorators that are being displayed in the editor gutter. There was explicit work in the past, so that when you open a folder using the cli (ex: code foo) the symbolic links are not resolved. This means that the file system events that are being sent to extensions use URIs that contain the symbolic link instead of the real path of the file.
In the git extension, we use a git command to determine the location of the repository. This git command always resolves symbolic links and there is no way to control that behaviour. This results in a mismatch between the URIs that the git extension receives from VS Code, and the location of the repository as far as the git extension goes.
At the moment, when symbolic links are involved, the only workaround is to open such folders using the "File -> Open Folder" menu as in that case, the OS will resolve the symbolic links (at least based on my tests) and VS Code will use the real path, which will match the one known by the git extension.

Ok thank you :slightly_smiling_face:  , but it's the other way around - project folder symlink is resolved through code but not through open with/open folder.
In any case - is there a solution how to force symlink resolution for open with/open folder being implemented or does it rely on this being closed/resolved? : https://github.com/microsoft/vscode/issues/34627
Also I'm confused why the issue you've linked and there-mentioned issues are closed but the last comment there obviously not addressed nor resolved O.o do you please maybe have a little bit more insight? Thank you :slightly_smiling_face:

Ok thank you 🙂 , but it's the other way around - project folder symlink is resolved through code but not through open with/open folder.

My understanding is (which is supported by my tests) is that when you run code symlinks are being maintained, based on the changes that were implemented as part https://github.com/microsoft/vscode/issues/18837. When you use "File -> Open Folder" than the OS will resolve the symlink into the canonical URI, and pass the canonical URI to VS Code.

In any case - is there a solution how to force symlink resolution for open with/open folder being implemented or does it rely on this being closed/resolved? : https://github.com/microsoft/vscode/issues/34627

I do think that having a setting described in https://github.com/microsoft/vscode/issues/34627 would help in this particular case as one would be able to disable that functionality hence VS Code would always use the canonical URI independent on how a folder/workspace with a symlink is being opened. I would recommend that you subscribe to that issue.

Also I'm confused why the issue you've linked and there-mentioned issues are closed but the last comment there obviously not addressed nor resolved O.o do you please maybe have a little bit more insight? Thank you 🙂

There are multiple issues that have been filed over the years with various problems related to source control that are caused by symlinks. I will have a conversation with the team to seem if there is anything that we can do to improve that experience.

@Noprop, thank you very much for the follow-up.
We will continue to explore options to make this experience better.


[dart:io] socket endian changes broke mac tests

d30be47a2064c023aa5d31e12480536e22912ca7 [dart:io] RawSocketOption.fromInt should follow the same endian as host
dartk...
Pass -> RuntimeError (expected Pass)
standalone_2/io/raw_datagram_socket_test
/======================================================================================\
| standalone_2/io/raw_datagram_socket_test broke (Pass -> RuntimeError, expected Pass) |
\======================================================================================/

--- Command "vm" (took 868ms):
DART_CONFIGURATION=ReleaseX64 xcodebuild/ReleaseX64/dart --ignore-unrecognized-flags --packages=/b/s/w/ir/.packages /b/s/w/ir/tests/standalone_2/io/raw_datagram_socket_test.dart

exit code:
255

stdout:
unittest-suite-wait-for-done

stderr:
Unhandled exception:
OS Error: Can't assign requested address, errno = 49
#0      _NativeSocket.setRawOption (dart:io-patch/socket_patch.dart:1194:25)
#1      _RawDatagramSocket.setRawOption (dart:io-patch/socket_patch.dart:2088:56)
#2      testDatagramSocketMulticastIf.test (file:///b/s/w/ir/tests/standalone_2/io/raw_datagram_socket_test.dart:134:12)
<asynchronous suspension>
#3      testDatagramSocketMulticastIf (file:///b/s/w/ir/tests/standalone_2/io/raw_datagram_socket_test.dart:148:7)
#4      main (file:///b/s/w/ir/tests/standalone_2/io/raw_datagram_socket_test.dart:399:3)
#5      _startIsolate.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:307:19)
#6      _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:174:12)

--- Re-run this test:
python tools/test.py -n dartk-mac-release-x64 standalone_2/io/raw_datagram_socket_test

Related bug: https://github.com/dart-lang/sdk/issues/39691.
Approving failures to turn bot green.

This CL https://dart-review.googlesource.com/c/sdk/+/128367 fixes the Mac test issue.


Stuck on Chapter 6

First, thanks for taking the time to write this! I'm early in my career and this is exactly the kind of thing I was looking for to help me improve. I even appreciate some of the small bugs I've come across working through the code provided in the PDF, as they've helped me better understand what I'm building by having to debug. That said, I'm stuck on Chapter 6. I went back through the code several times now and I can't seem to find my problem. My console.logs all fire as expected right up until the apiClient.items.fetchItems() call in src/store/index.ts, which does nothing. No error in the console and the green ball just bounces on. I know that's pretty vague, my apologies. I've looked at the repo code and I know that what's in the PDF isn't quite current in all cases, so what I'd really like is suggestions for how I can better approach debugging this if possible. Thanks again, I'm really learning a ton.

Thank you for the nice words, and I am not surprised there might be small syntax bugs as I proof read the book all the time and make corrections as I receive feedback.
Could you create a GitHub repo with the code you have so far? That would be the easiest way for me to help.

Just pushed my current code to the repo.

Ok the simple mistake is in the src/store/index.ts file, line 42:

   apiClient.items.fetchItems((data: any) => {

  apiClient.items.fetchItems().then((data: any) => {

Since fetchItems returns a promise, we need to use it with fetchItems().then((data: any) etc (or if you prefer you could start using async/await)
I'll review the book and see where I made that mistake. Sometime the editor I am using messes up the format of the code samples and I manually fix them within the editor without validating the changes in VSCode so that was my fault. My I am happy you reported this so I can fix it.
Do not hesitate to ask for more help if you get stuck, I'll try to always get to it as soon as you can, usually within 1-2 days max.

That did the trick, thank you! I really appreciate the quick response. Time for Ch.7.


Metering config

Is it intended that the report includes metering_plan_id, rating_plan_id, and pricing_plan_id?
I updated the perf and demo to include them because reporting app is returning them.
plan_id: 'basic/basic-object-storage/object-rating-plan/object-pricing-basic',
metering_plan_id: 'basic-object-storage',
rating_plan_id: 'object-rating-plan',
pricing_plan_id: 'object-pricing-basic',


ImportError: libcudnn.so.8: cannot open shared object file: No such file or directory

I installed nnabla using pip install nnabla-ext-cuda102 and I have CUDA-10.2 installed on my system. I have also added
export LD_LIBRARY_PATH=/usr/local/cuda-10.2/lib64:$LD_LIBRARY_PATH
export PATH=/usr/local/cuda-10.2/bin${PATH:+:${PATH}} in my .bashrc file. I am not able to solve this error. I am able to use nnabla with CPU extension though.

Hi,
To run nnabla with GPU, you need to install CUDA and cudNN.
Please refer this nvidia installation page to install cudnn: https://docs.nvidia.com/deeplearning/cudnn/install-guide/index.html
You need to join free nvidia developer program to download cudnn.
If you already installed cudnn8, please add the directory path to LD_LIBRARY_PATH.

Please let me close this issue.
If you still face this problem, please create new ticket with error messages.


Add a constraint to prevent using this gem with Rails 7.1

I am using Rails 7.1.1 and when I start my server(rails s) I get the following error
unknown keyword: :uses_transaction (ArgumentError)

Unfortunately that'll just send Bundler to find the latest version that had the more open-ended dependency.
Best might be to explicitly check the Rails version and no-op in the Railtie?

That's a good point. Yeah, either no-op or raise/deprecate with a message about removing the gem.

Perhaps try using trilogy gem instead of activerecord-trilogy-adapter?
Rails v7.1+ includes Trilogy support by default making this gem unnecessary due as part of https://github.com/rails/rails/pull/47880.
I experienced the same issue when using this gem, and did not have the error once I switched over.


using filters with pyarrow_additional_kwargs in wr.s3.read_parquet

I am trying to read a big dataset. However, I am trying to filter some rows, I tried to add filters param in pyarrow_additional_kwargs but it did not work.

Hi @mutasem-mattar yes, thanks for bringing this up - looks like pyarrow_additional_kwargs aren't fully passed to pyarrow. I'll send a PR with a fix

Actually, looks like filters are only available for ParquetDataset while we're using ParquetFile behind the scenes, and handle multithreading etc separately.
Being able to filter does make sense though, but I'll need to do a deeper analysis if moving ParquetDataset would be backward-compatible.

Hello, +1 here, I am trying to do something similar, but I can't use dataset True since I am reading multiple parquet files
Here is what I think should be an equivalent pandas / awswrangler
s3_parquet_df = wr.s3.read_parquet('s3://bucket/data/',
                                  columns=['X_EVT_ID'],
                                  pyarrow_additional_kwargs={"filters":[('EVT_ID', '=','1234')]})

local_parquet_df = pd.read_parquet('data/',
                                   columns=['X_EVT_ID'],
                                   filters=[('EVT_ID', '=', '1234')])

@kukushking Any update on the investigation into ParquetDataset vs. ParquetFile? Or whether setting dataset=True uses ParquetDataset? This would be a really useful feature for us too, to be able to load only some rows from our dataset.
WHERE clauses are obviously pretty common in SQL queries used for data engineering. Being able to do row filtering would be a nice equivalent to that SQL feature.
Separately, looks like a pretty small team working on this now, given how widely used this is! Thanks for all your efforts on this.

I would welcome any update as well.

Looks like this would be quite chunky refactoring to match all existing features, in addition, according to arrow docs looks like dataset API isn't stable yet. I will keep this open for now and we'll start the migration when it's stable
Meanwhile, you can use partition_filter argument to apply filters to partitions.

Not stale


Update tailwindcss plugin with .cjs support

If a project had type: module in package.json.
We had to provide tailwind.config.cjs to work.

Thanks @navin-moorthy! Happy to merge this. Just looked into tailwind source code for the default supported extensions (does not seem to be mentioned in their docs), could you please add mjs and ts as well?
(source: https://github.com/tailwindlabs/tailwindcss/blob/3c4cfb527252aeece3a72deeec0e963ec26a8328/src/util/resolveConfigPath.js#L5-L8)

Added them, seems the support for .mjs and .ts is coming in v3.3


Bluetooth: audio: BAP Unicast Client: Invalid Opcode and Invalid Length Response_Codes are not handled properly

Describe the bug
When the server rejects the operation with errors 0x01 = Unsupported Opcode or 0x02 = Invalid Length the "Number_of_ASEs shall be set to 0xFF";
Moreover,  the ASCS_v1.0 Table 4.7: Format of ASE Control Point characteristic value when notified  states that ASE_ID[i] "If the Response_Code value is 0x01 or 0x02, ASE_ID shall be set to 0x00, and [i] shall be set to 0."
Response_Code[i] and Reason[i] will be 0x00 as well, where [i] shall be 0.
Consider Config Codec operation request below :
Opcode:                                 0x01
Number_of_ASEs:                         0x02
ASE_ID[0]:                              0x01
Target_Latency[0]:                      0x01
Target_PHY[0]:                          0x01
Codec_ID[0]:                            0x0600000000
Codec_Specific_Configuration_Length[0]: 0x00
ASE_ID[0]:                              0x02
Target_Latency[0]:                      0x01
Target_PHY[0]:                          0x01
Codec_ID[0]:                            0x0600000000
Codec_Specific_Configuration_Length[0]: 0x05 <- here' the bug. The PDU seems to be truncated

Once the server received such PDU, it shall reject it with Invalid Length Response_Code
Opcode:                                 0x01
Number_of_ASEs:                         0xFF
ASE_ID[0]:                              0x00
Response_Code[0]:                       0x02
Reason[i]:                              0x00

The current implementation does not handle that.
It fails to parse the correctly formatted ASE Control Point notification. The Response_Code is not passed to the application. The Application is not informed about the failed operation, because the Client does not store the context of operation performed.

@MariuszSkamra I think this has been fixed.
I modified the stack to send an invalid length codec configure, and this is the notification I received:
Opcode:                                 0x01
Number_of_ASEs:                         0xFF
ASE_ID[0]:                              0x00
Response_Code[0]:                       0x02
Reason[i]:                              0x00

as seen from the log:
unicast_client_cp_notify: rsp->num_ase 255
unicast_client_cp_notify: op Config Codec (0x01) id 0x00 code Invalid Length (0x02) reason None (0x00)

I suggest to close this, unless you can otherwise provide evidence that this is still an issue


Stretching texture around edges of eyes screens in WMR

Hello, I have a strange problem in Windows Mixed Reality. I see a stretched texture on the edges of HMD screens.
I drew RT to my game screen. As you can see, the texture is completely filled in. The red outline in one pixel is the border of the RT (-1, -1, rtWidth + 2, rtHeight + 2).

When this texture is submitted to HMD it does not fill the eyes screens completely. There are empty edges on the left and right.
In SteamVR preview you can see black edges on the left and right, and you can notice that the border of the room is drawn over the black color. There is no such problem at the top and bottom.
WMR preview shows that the border is stretched and clamped. Only the left eye is shown here; the right one has such a stretched border on the right.

This error is also visible in the official workshop addon. It seems to be an error at the module/OpenVR level. Other VR games don't have this problem.
My HMD is "Samsung HMD Odyssey+"

This is intentional, vrmod currently expects the game views to be rendered using conventional symmetric perspective projection (for compatibility reasons), and then moves the images to make it look correct with headsets that require offset projection. It will result in the outside area being undefined (usually black but could be anything).
Typically the offset is small enough that the outside area is not displayed in the headset at all (as is the case on my vive and index) and should be a non-issue for most except during extreme lag where the outside areas are used for reprojection.
It would be possible to use offset projection which would fill the entire area but it causes compatibility issues as nothing expects you to be using offset projection in gmod. Frustum culling doesn't take it into account, reflections handled by the engine break, etc.
Another workaround might be rendering an oversized symmetric view with larger fov and cutting it down appropriately, but it would probably require a higher resolution and an additional intermediate rendertarget and wouldnt be very efficient (+ other potential issues i've probably missed)

This is intentional, vrmod currently expects the game views to be rendered using conventional symmetric perspective projection (for compatibility reasons), and then moves the images to make it look correct with headsets that require offset projection. It will result in the outside area being undefined (usually black but could be anything).
Typically the offset is small enough that the outside area is not displayed in the headset at all (as is the case on my vive and index) and should be a non-issue for most except during extreme lag where the outside areas are used for reprojection.
It would be possible to use offset projection which would fill the entire area but it causes compatibility issues as nothing expects you to be using offset projection in gmod. Frustum culling doesn't take it into account, reflections handled by the engine break, etc.
Another workaround might be rendering an oversized symmetric view with larger fov and cutting it down appropriately, but it would probably require a higher resolution and an additional intermediate rendertarget and wouldnt be very efficient (+ other potential issues i've probably missed)


NuttX HIL (actuator_control output in MAVLink app) not operational on master

@mcharleb I don't have the details yet, but something is not working as on stable / release_v1.0.0 branches when trying to run HIL.

check cxx_initalizers

If the bug was mavlink_if0: invalid data rate '(null)'  I think https://github.com/PX4/Firmware/pull/2334  will fix it

@davids5 Fix through 3f4b5fc, which was unrelated. Thanks!


Bicep Autocomplete and Microsoft Docs disagree on available API Versions

Bicep version
VS Code 0.3.255
Describe the bug
If you look at the documentation for Microsoft.Web/sites , it lists the latest API version as being 2020-09-01 , however bicep's auto completion also lists 2020-10-01 and 2020-12-01.   Why the inconsistency
To Reproduce
https://docs.microsoft.com/en-us/azure/templates/microsoft.web/sites?tabs=json:

@tfitzmac - do we need to regenerate what's available in docs?

@alex-frankel - yes, I'll create a work item.

Docs have been updated and those versions are now present.

https://docs.microsoft.com/en-us/azure/templates/microsoft.web/sites?tabs=json


Add unit test for goutil package

This PR will cover the gup/internal/goutil.

[x] Add initial test to draft a PR
[x] Add examples for public functions in goutil package to cover the basics
[x] Add examples for public methods
[x] Add tests for failed/error cases
[x] Apply dependency injection to enable mock/monkey-patch
[x] cover gouil up to 100%

@KEINOS
Your way of making unit tests is more careful than mine. Perhaps I will be satisfied enough with the tests you write in the future.

cover gouil up to 100%

You don't have to force yourself to aim for 100% coverage.
Coverage of 80% or more is sufficient.

@nao1215
I think it's ready! 👍 Please review it when you got time 🤞

@KEINOS
LGTM.
However, I do not know if the test will work on Windows.
Please merge the code from the main branch when you have time :pray:
Currently, the test passes on Linux, Mac, and Windows.
However, Mac and Windows may fail the test in rare cases due to an exceedance of the Race condition.

Windows...

Windows...

@nao1215
Sorry, I was wrong about the above comment. It IS my bad.
https://github.com/nao1215/gup/actions/runs/3079250233/jobs/4975350665#step:4:253

@KEINOS
You need to fix "--- FAIL" ar "Run unit test" result.
Windows has a different separator for file paths, so the hard-coded paths must be replaced with filepath.Join().

Windows has a different separator for file paths

Linux「Windows...」
macOS「Windows...」
UNIX「Indeed」

[MEMO]: Differences of module paths between platforms
macOS
$ go version -m "$(which gup)"
/Users/admin/go/bin/gup: go1.19.1
        path    github.com/nao1215/gup
        mod     github.com/nao1215/gup  v0.10.5 h1:kQKlfrQyNIBq4DlOKB26oLOFHStszgxSnTKyOtdMJbM=
        dep     github.com/fatih/color  v1.13.0 h1:8LOYc1KYPPmyKMuN8QV2DNRWNbLo6LZ0iLs8+mlH53w=
        dep     github.com/gen2brain/beeep      v0.0.0-20210529141713-5586760f0cc1      h1:Xh9mvwEmhbdXlRSsgn+N0zj/NqnKvpeqL08oKDHln2s=
        dep     github.com/mattn/go-colorable   v0.1.12 h1:jF+Du6AlPIjs2BiUiQlKOX0rt3SujHxPnksPKZbaA40=
        dep     github.com/mattn/go-isatty      v0.0.14 h1:yVuAays6BHfxijgZPzw+3Zlu5yQgKGP2/hcQbHb7S9Y=
        dep     github.com/spf13/cobra  v1.5.0  h1:X+jTBEBqF0bHN+9cSMgmfuvv2VHJ9ezmFNf9Y/XstYU=
        dep     github.com/spf13/pflag  v1.0.5  h1:iy+VFUOCP1a+8yFto/drg2CJ5u0yRoB7fZw3DKv/JXA=
        dep     golang.org/x/sys        v0.0.0-20220412211240-33da011f77ad      h1:ntjMns5wyP/fN65tdBD4g8J5w8n015+iIIs9rtjXkY0=
        build   -compiler=gc
        build   CGO_ENABLED=1
        build   CGO_CFLAGS=
        build   CGO_CPPFLAGS=
        build   CGO_CXXFLAGS=
        build   CGO_LDFLAGS=
        build   GOARCH=amd64
        build   GOOS=darwin
        build   GOAMD64=v1

Linux (Debian, Docker+golang:latest)
# go version -m "$(which gup)"
/go/bin/gup: go1.19.1
        path    github.com/nao1215/gup
        mod     github.com/nao1215/gup  v0.10.5 h1:kQKlfrQyNIBq4DlOKB26oLOFHStszgxSnTKyOtdMJbM=
        dep     github.com/fatih/color  v1.13.0 h1:8LOYc1KYPPmyKMuN8QV2DNRWNbLo6LZ0iLs8+mlH53w=
        dep     github.com/gen2brain/beeep      v0.0.0-20210529141713-5586760f0cc1      h1:Xh9mvwEmhbdXlRSsgn+N0zj/NqnKvpeqL08oKDHln2s=
        dep     github.com/godbus/dbus/v5       v5.0.3  h1:ZqHaoEF7TBzh4jzPmqVhE/5A1z9of6orkAe5uHoAeME=
        dep     github.com/mattn/go-colorable   v0.1.12 h1:jF+Du6AlPIjs2BiUiQlKOX0rt3SujHxPnksPKZbaA40=
        dep     github.com/mattn/go-isatty      v0.0.14 h1:yVuAays6BHfxijgZPzw+3Zlu5yQgKGP2/hcQbHb7S9Y=
        dep     github.com/spf13/cobra  v1.5.0  h1:X+jTBEBqF0bHN+9cSMgmfuvv2VHJ9ezmFNf9Y/XstYU=
        dep     github.com/spf13/pflag  v1.0.5  h1:iy+VFUOCP1a+8yFto/drg2CJ5u0yRoB7fZw3DKv/JXA=
        dep     golang.org/x/sys        v0.0.0-20220412211240-33da011f77ad      h1:ntjMns5wyP/fN65tdBD4g8J5w8n015+iIIs9rtjXkY0=
        build   -compiler=gc
        build   CGO_ENABLED=1
        build   CGO_CFLAGS=
        build   CGO_CPPFLAGS=
        build   CGO_CXXFLAGS=
        build   CGO_LDFLAGS=
        build   GOARCH=amd64
        build   GOOS=linux
        build   GOAMD64=v1

@KEINOS
Excellent, the test passed!! You are now friends with Windows.
The test I made seems to fail frequently. I will fix it next time.


Compiler Hangs With No Error/Output

Plugin Version: v0.0.136
Solidity Version: 0.8.9
I'm not sure if this issue is related to #296 since I'm not getting the error mentioned in there.
Steps to Reproduce:

Have a contract that will throw a compiler error (stack too deep in this case)
Right click and "Compile Contract"
Output hangs at Compiler using remote version: 'v0.8.9+commit.e5eed63a', solidity version: 0.8.9+commit.e5eed63a.Emscripten.clang

I've verified that the contract will actually stack-too-deep error via Remix.

Hi @AlphaSerpentis do you have an example you can provide to test it?

Hi @AlphaSerpentis do you have an example you can provide to test it?

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.9;

contract Test {
    function foo( // this will fail to compile
        address _1,
        address _2,
        address _3,
        address _4,
        address _5,
        address _6,
        address _7,
        address _8,
        address _9,
        address _10,
        address _11,
        address _12,
        address _13,
        address _14,
        address _15,
        address _16
    ) external {

    }
}


docs(dev): update env info in config docs

This was very old I think and it confused th outta me for a bit before I found the page I added the link to!

Description
There was some very outdated info on the config page about environment variables. I got rid of it and linked to the main env variable info in the guide, which seems to be more commonly kept up-to-date. This should hopefully avoid confusion for those who, like me, googled "Vite config" and ended up on the env variables section of the config page.
Additional context

What is the purpose of this pull request?

[ ] Bug fix
[ ] New Feature
[x] Documentation update
[ ] Other

Before submitting the PR, please make sure you do the following

[x] Read the Contributing Guidelines.
[x] Read the Pull Request Guidelines and follow the Commit Convention.
[x] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[x] Ideally, include relevant tests that fail without this PR but pass with it.

I'm not sure how a docs change broke tests lol. Anyone have suggestions?

It's flaky tests, but I don't think this PR change is correct. The config environment variables is for vite.config.js, while https://vitejs.dev/guide/env-and-mode.html is for your source code. And the information isn't oudated.


Made raid warning message look more professional by putting it in an embed

I made the raid warning message look more professional by putting it inside an embed, so it stands out more in the general chat.

Besides that I also added the time in the footer so you can see when the raid took place.

Currently it looks different, since the red color specifies it being an error, so a warning color was added, now it looks like this:

Currently it looks different, since the red color specifies it being an error, so a warning color was added, now it looks like this:
I don't believe you have pushed up this change?


FloatFromLeft using StackNavigator

Can i do the transition from left to right using StackNavigator?? I can't find the docs for that

Hi! In an effort to get the hundreds of issues on this repo under control I'm closing issues tagged as questions. Please don't take this personally - it's simply something we need to do to get the issues to a manageable point. If you still have a question I encourage you to re-read the docs, ask on StackOverflow, or ask on the #react-navigation Reactiflux channel. Thank you!


.withClasspathResourceMapping maps a directory with a requested filename instead of a file

Hello!
I've created a simple rule using GenericContainer:
@ClassRule
public static GenericContainer postgres = new GenericContainer("localhost:5000/postgres:10.2")
.withExposedPorts(5432)
.withEnv("POSTGRES_DB", "ib")
.withEnv("POSTGRES_USER", "postgres")
.withEnv("POSTGRES_PASSWORD", "admin")
.withClasspathResourceMapping("init.sql", "/docker-entrypoint-initdb.d/init.sql", BindMode.READ_ONLY);
But I've got an error during container creation:
[testcontainers-netty-1-6] INFO 🐳 [localhost:5000/postgres:10.2] - STDOUT: 2018-04-28 08:05:33.605 UTC [61] LOG:  database system is ready to accept connections
[testcontainers-netty-1-6] INFO 🐳 [localhost:5000/postgres:10.2] - STDOUT:  done
[testcontainers-netty-1-6] INFO 🐳 [localhost:5000/postgres:10.2] - STDOUT: server started
[testcontainers-netty-1-6] INFO 🐳 [localhost:5000/postgres:10.2] - STDOUT: CREATE DATABASE
[testcontainers-netty-1-6] INFO 🐳 [localhost:5000/postgres:10.2] - STDOUT:
[testcontainers-netty-1-6] INFO 🐳 [localhost:5000/postgres:10.2] - STDOUT: ALTER ROLE
[testcontainers-netty-1-6] INFO 🐳 [localhost:5000/postgres:10.2] - STDOUT:
[testcontainers-netty-1-6] INFO 🐳 [localhost:5000/postgres:10.2] - STDOUT:
[testcontainers-netty-1-6] INFO 🐳 [localhost:5000/postgres:10.2] - STDOUT: /usr/local/bin/docker-entrypoint.sh: running /docker-entrypoint-initdb.d/init.sql
[testcontainers-netty-1-6] INFO 🐳 [localhost:5000/postgres:10.2] - STDERR: psql:/docker-entrypoint-initdb.d/init.sql:0: could not read from input file: Is a directory
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 65.473 sec <<< FAILURE!
SimplePostgreSQLTest  Time elapsed: 65.466 sec  <<< ERROR!
Can't realise what I'm doing wrong. Any help is appreciated.
Update
After inspecting the container's contents I've found that init.sql is mapped as a directory, not a file.
How to map a file then?

@sjvatgit Docker creates an empty directory when there is no file on the host. Are you running the tests inside a container? If so, did you configure the path? ( -v $PWD:$PWD -w $PWD )?

You are right - that's the point. I forget about that. The container is a jenkins slave.
I'll try to map a container's jenkins home to the host's /jenkins/home using the standard Jenkins gui.
I think that will be enough.
Thank you!


Why are Gale preview images not loading on QA?

it looks like we lost the id somehow. Image results on qa return a 400 bad request, here's an example image url as we're generating it on the qua site.
https://callisto.ggsrv.com/imgsrv/FastFetch/UBER2/?format=png&boundbox=725 450
Here's the url for a working image on the production site:
https://callisto.ggsrv.com/imgsrv/FastFetch/UBER2/024700020200050?format=png&boundbox=225+350
@quadrismegistus relevant code is in the page_preview.html template; we are referencing an image_id variable. I don't know why that isn't available any longer.... I don't think we changed the page index data, so I would guess it's to do the change in logic for returning pages + page images.
Ah! 💡 Ok, I think this because we're not using an aliased queryset in get_pages method in the view, and so image_id is actually present asimage_id_s .
Proposed solution: create a second aliased queryset for pages and add aliases for group_id and image_id. That way the template doesn't need to be changed, and we can fix the group_id_s filter in the view. Only caveat is that aliasing uses Solr field limit, so we need to make sure the aliased queryset includes all the image fields we're using in the templates.

Thanks for these notes @rlskoeser. On it now.
Note to myself: here's a URL which shows a broken thumbnail: http://<IP_ADDRESS>:8000/archive/?query=balladry&pub_date_0=1700&pub_date_1=1799&collections=9&collections=10&collections=11&collections=3&collections=4&collections=0&sort=relevance

This looks fixed to me now! Thank you!


problem with seeing gameobjects outside of fov

Hi, after always ignoring this problem i decided to research more and i really cant find a fix.
The Objects that are hidding will get visible a lil bit out of the FOV ( see picture):

this is the LOS Source:

Are you talking about the npc character just outside the line of sight?
What kind of mesh is used to draw the sprite? The mesh might be intersecting the LOS source camera's frustum, while the texture only covers a part of the mesh.

yes, it looks like this:

can i change it(size  maybe...) in any way ?

it doesent seem to be the problem i guess because the fov is still far from the mesh...

The LOS Culler component uses the mesh's Axis Aligned Bounding Box (AABB) to calculate the visibility of the mesh.
Because the mesh generated from the sprite has some artifacts, the AABB is larger than the sprite itself and does intersect with the line of sight:

The best fix would be to clean up the sprite image, so that the generated mesh is cleaner and fits the sprite perfectly.

this is really interesting i didnt know that.
What you mean by cleaning the sprite?

i mage a png just of pixels:

but i still have these edges...

My guess is that the NPC sprite contains a couple of pixels which aren't completely transparent, so you might need to fix that in an image editor.
You could also try setting the Mesh Type for the texture to Full Rect instead of Tight.
But the topic of sprite mesh generation is no longer related to this asset, so might be better to ask on the Unity forum instead.

ok i will but you helped me alot. i thank you so much <33333


feat: output tag name and upload url

The tag name is useful to interact with the release on following steps,
and the upload url is useful to upload assets to the release.
Fix: https://github.com/GoogleCloudPlatform/release-please-action/issues/8
Fix: https://github.com/GoogleCloudPlatform/release-please-action/issues/41

@mmarchini thank you for the contribution 👌

@mmarchini tagged<EMAIL_ADDRESS>

what does tag_name and upload_url look like? we can update some doc around the change. thanks for putting this out!

Both are equal to their respective values in the Create Release API response. The tag_name is the tag name (not to be mistaken with the release name), and the upload_url is an URL to the upload asset API endpoint. Agreed we should add some documentation, maybe an extra section in the readme with all values set in the output of the action.


[BUG REPORT]: NBM acquirables/products missing date in filename

This will cause overwrites in S3 and serve incorrect past records.

[x] Fix airflow dag to include date in filename
[ ] review data in S3/db to determine what records to purge

Last properly timestamped acquirables in S3 stable (before fix) = 20220216

Fixed

Deployed to:

[ ] develop
[ ] stable

Before the refactor, it looks like the productfile was being saved in the format of:
cumulus/products/nbm-co-qpf/blend.t07z.core.f020.co-20220610-nbm-co-qpf.tif
The processor was adding the datetime to the file (no longer happening).
Those productfiles should be good and will be kept.
The following queries will delete productfiles that look like:
cumulus/products/nbm-co-qpf/blend.t11z.core.f035.co.tif
cumulus/products/nbm-co-airtemp/blend.t18z.core.f009.co.tif
-- delete nbm-co-qpf
delete from cumulus.productfile
where product_id = '5317d1c4-c6db-40c2-b527-72f7603be8a0'
and file not like '%-20%' and file not like '%/blend.20%';

-- delete nbm-co-airtemp
select * from cumulus.productfile
where product_id = 'd0c1d6f4-cf5d-4332-a17e-dd1757c99c94'
and file not like '%-20%' and file not like '%/blend.20%';

[ ] Delete develop productfiles
[ ] Delete develop acquirablefiles
[ ] Delete develop S3 productfiles
[ ] Delete develop S3 acquirablefiles
[ ] Delete stable productfiles
[ ] Delete stable acquirablefiles
[ ] Delete stable S3 productfiles
[ ] Delete stable S3 acquirablefiles

Delete develop acquirablefiles (134,476) - query time over 60+ min :-(

Yikes.

@brettpalmberg Looking into adding index.
Thoughts on adding this?
CREATE INDEX IF NOT EXISTS acquirablefile_acquirable_id_idx ON acquirablefile (acquirable_id);

@adamscarberry, this looks good. Excited to see how this speeds things up.

Index added in develop and stable manually.  Will be included in API migrations shortly.

Reopening to verify cleanup


Variance aggregator

Hi there,  I've got a scenario where users select several date ranges to compare data. I'd like to implement an aggregator for the table that shows the variance/percentage change between the first date column and each subsequent one.
For example, given 3 columns, the second and third would show the variance compared to the first.
My questions are;

Does something like this already exist?
If not, is it possible to access values in specific columns and rows from the aggregator callback? Ideally something like a column selector for am adjacent cell on the same row.

Perhaps I'm missing something and there's a better way to do this!
Many thanks

It sounds like you're asking about using multiple aggregators in the same table, which is not supported, unfortunately: https://github.com/nicolaskruchten/pivottable/wiki/Frequently-Asked-Questions#multi


Replace .triu calls to allow ONNX export for CPU runtime

Hi,
When exporting a model to ONNX and then using the ONNX RT CPU provider for optimizations, ORT complains about not finding an implementation for the triu op:
NotImplemented: [ONNXRuntimeError] : 9 : NOT_IMPLEMENTED : Could not find an implementation for Trilu(14) node with name '/attn_layers/layers.0.1/attend/Trilu'
To reproduce the error, you just need to create a model from the examples (with the corresponding input tensor), export it to ONNX using torch.export and then pass the exported model to ORT:
import onnx
import onnxruntime as rt
import onnxoptimizer

sess_options = rt.SessionOptions()
sess_options.graph_optimization_level = (
    rt.GraphOptimizationLevel.ORT_ENABLE_EXTENDED
)

sess_options.optimized_model_filepath = str("model_opt.onnx")
providers = ["CPUExecutionProvider"]
rt.InferenceSession("model.onnx", sess_options, providers=providers)

To fix it, I removed the triu calls and replaced with a similar code that you already used before (see commit https://github.com/lucidrains/x-transformers/commit/6119be8d815b9ee2eb01c08fdaa49190b83ab03d). This way we are able to export to ONNX and run the model on CPU.
Thanks,

@jorgetavares hey Jorge! so i'm googling around and it seems like Onnx has resolved the triu operator in version 14? can you confirm (or refute) that?

Hi, thanks for replying so fast! I'm using the latest versions of all the onnx packages: onnx 1.14.0 and onnxruntime 1.15.1. I re-run and I still the same error. However, this only happens for the CPU execution provider, for CUDA it's all fine. I also tried using the latest opset in torch.onnx.export but no luck either.
Perhaps that's what you saw mentioned, i.e., triu operator being solved but only for CUDA? Otherwise, can you point me to what you read because I might be missing something simple then.
I understand people are mostly interested in GPU runtime but CPU is still useful for some things :)

oh yes, you are right
let me think about this

Ok, thanks for looking into this!

@jorgetavares want to try 1.16.17? with Decoder(..., attn_onnxable = True) ?

Hi,
I just tested 1.16.17 and it works now! Thanks a lot for providing a fix! :-)

I think we can close this.


DebugText Color Fix

PR Details
RenderText.Print() will now work as intended when a custom text color (or colour) is set.
Description
If a custom color is set in RenderText.Print() the text will remain the default Light Green. This is because msg.TextColor != currentColor was essentially comparing against itself and as a result always returning a value of False. With this change, msg.TextColor is now being compared to the current/default TextColor value.
Related Issue
#1155
Types of changes

[ ] Docs change / refactoring / dependency upgrade
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[ ] My change requires a change to the documentation.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

As always, I'll backport and create a new 4.0 PR if this is accepted.


npm start fails

Is this a bug report?
Yes

Can you also reproduce the problem with npm 4.x?

Yes : npm 4.6.1
Which terms did you search for in User Guide?

(Write your answer here if relevant.)
Environment

node -v: v8.2.1
npm -v: 4.6.1
yarn --version (if you use Yarn):
npm ls react-scripts (if you haven’t ejected<EMAIL_ADDRESS>
Then, specify:

Operating system: Mac
Browser and version (if relevant):

Steps to Reproduce

(Write your steps here:)

npm install -g create-react-app
create-react-app my-app
cd my-app/
npm start

Expected Behavior

(Write what you thought would happen.)
server would start and I could open http://localhost:3000/ to see your app.
Actual Behavior

(Write what happened. Please add screenshots!)

Reproducible Demo

(Paste the link to an example project and exact instructions to reproduce the issue.)

Try this:
rm -rf node_modules
rm package-lock.json
npm install
npm start

If it doesn't help please provide full output from npm install (the one in the post has beginning cut out).

Thanks for reply. Did what you advise. Here is output of npm install:

[...]
.
.
.
.

Can you try on a different Node version? Could be an issue with 8.2.1.

Can you walk me through that? I am not sure how to do it...

I usually go to Node website and download the stable version there (currently it's 6.x).
I'll close this issue because it is clearly a bug in either Node or npm. To get help you'll need to go to the npm issue tracker and file an issue with this log attached. They can look into it and help figure out why it is crashing.
Unfortunately we can't help because we neither control this code, nor are Node/npm experts.

I downgraded to the stable version of node and npm and still get the issue.

Please file it here: https://github.com/npm/npm/issues/new
Something’s up with your local Node or npm setup. Unfortunately we can’t help you debug these. We rely on npm working, and if it doesn’t work, please report it to npm who can help you.


[Doc][Improve] Add landing pages

Motivation
Clearer navigation is needed from the doc home page.
Modifications
Add landing pages for content blocks in about.md. Update about.md to new link references.
Verifying this change

[ ] Make sure that the change passes the CI checks.

Documentation

[x] doc
[ ] doc-required
[ ] doc-not-needed
[ ] doc-complete

Pending resolution of local preview issue. @Anonymitaet @momo-jun

@DaveDuggins I've pushed a commit to fix some link and style issues left. Can you pls take a look and see if the changes meet your intentions/expectations?
The only concern in my mind is we don't have a place in the navigation to host the How-to topic and related tutorials, so these pages may look a bit unfinished and inconsistent. This can be the next step of improvement in the pipeline.

Hi @momo-jun - your changes are great, thank you! Much appreciated.


typo in api.md

more then -> more than
I haven't signed the cla so this patch is public domain. You may drop me from this patch and merge this under your address.

@burningTyger do you remember signing the CLA? The bot is having issues :\

ok, I signed


Work with non-iterable dictionaries.

The way dpath.util.get is implemented means that it requires all parts of the tree to be iterable. So if you have a node which is a dictionary, but isn't iterable, it does not allow you to find the children under that node. This is a consequence of using fold and walk to implement get. This is also not efficient if the node is a map (that is, it still iterates over the keys when it could do a direct lookup).
To make get more efficient and also allow non-iterable maps we need use kvs only when the related segment is a glob (that is, only iterate over them if it is strictly necessary). This means we can't use fold or walk anymore. There probably is additional fallout in the other methods like view and search. Unfortunately this will require some significant changes.
Originally reported here:
https://github.com/akesterson/dpath-python/pull/122/files#diff-f50eb92b27ecc897863ec0f0ef4f0f65R52-R66

Blocked by #136


[SPARK-37995][SQL] PlanAdaptiveDynamicPruningFilters should use prepareExecutedPlan rather than createSparkPlan to re-plan subquery

What changes were proposed in this pull request?

Use exists adaptive execution context to re-compile subquery.
Why are the changes needed?

If a subquery which is inferred by dpp contains a nested subquery, AQE can not compile it correctly.
the added test will fail before this pr:
java.lang.ClassCastException: org.apache.spark.sql.catalyst.plans.logical.Aggregate cannot be cast to org.apache.spark.sql.execution.SparkPlan
  at scala.collection.TraversableLike.$anonfun$map$1(TraversableLike.scala:286)
  at scala.collection.Iterator.foreach(Iterator.scala:943)
  at scala.collection.Iterator.foreach$(Iterator.scala:943)
  at scala.collection.AbstractIterator.foreach(Iterator.scala:1431)
  at scala.collection.IterableLike.foreach(IterableLike.scala:74)
  at scala.collection.IterableLike.foreach$(IterableLike.scala:73)
  at scala.collection.AbstractIterable.foreach(Iterable.scala:56)
  at scala.collection.TraversableLike.map(TraversableLike.scala:286)
  at scala.collection.TraversableLike.map$(TraversableLike.scala:279)
  at scala.collection.AbstractTraversable.map(Traversable.scala:108)
  at org.apache.spark.sql.execution.SparkPlanInfo$.fromSparkPlan(SparkPlanInfo.scala:75)
  at org.apache.spark.sql.execution.SparkPlanInfo$.$anonfun$fromSparkPlan$3(SparkPlanInfo.scala:75)

Does this PR introduce any user-facing change?

yes, bug fix
How was this patch tested?

add test

@cloud-fan  hope we can also backport this to branch-3.2/branch-3.3, thank you

thanks, merging to master/3.3/3.2!

thank you !


Move ownership to ROS Security working group

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@thomas-moulard the bit about this not being available via package managers isn't accurate. We bloom released this package
root@6dd92b66d489:/# apt search launch_ros
Sorting... Done
Full Text Search... Done
ros-dashing-launch-ros-sandbox/bionic 0.0.2-4bionic.20191016.193132 amd64
  Extension to launch_ros to provide the ability to run nodes in sandboxed environments.


fix categorical encoding and save X_train path

fix loading categories
add arg X_train to srsnv pipeline

Rebased an pushed (was missing a new commit fixing an unrelated bug I caused)


Problem after installing 0.2.x

When I try to run the migration I got this exception:
Exception 'yii\base\UnknownPropertyException' with message 'Setting unknown property: yii\console\Application::languages'
If I comment languages in common/config/main.php
return [     'vendorPath' => dirname(dirname(__DIR__)) . '/vendor',     'bootstrap' => ['comments'],     'language' => 'en-US',     /*     'languages' => [         'en-US' => 'English',         'uk' => 'Ukrainian',     ],     */
Migrations run.

@isalcedo Sorry, 0.2.x in not ready yet, it is under development. Please, wait for release.


Addnode

Any addnodes?

kindly expound..

kindly expound..

Hi, i meant, are there any peers (addnodes) for the coin please?
Thank you

yes.. there are peers of the network online

yes.. there are peers of the network online

What are they?

i dont understand ur question

i dont understand ur question

I meant, how to connect to the network? Because the wallet compiled from the source code won'T connect at all. Thanks

ooh.. i will be updating it soon, so ull need to recompile the source code. which OS are you using?

Windows, I compile under Linux tho
Ty


Support metadata/description for repository on UI

Talked with DQ, will start this task this week, then we move this issue to SP20

As not completed, move to sp22.
@ninjadq  Please drill down this task

pr requested #3742


Add Counters to Actions and Receivers

Adding counters inside State Machines which are incremented for each invocation of the OnEntry & OnExit actions, and message receivers would increase testability by enabling developers to easily assert that code was triggered.

Wink's original suggestion: https://github.com/AletheiaWareLLC/Wink/pull/24#pullrequestreview-1239208052


feat(translator): Implement BTP Timeout API

What this PR does / why we need it:
Implement the BackendTrafficPolicy Timeout API
Which issue(s) this PR fixes:
Fixes https://github.com/envoyproxy/gateway/issues/2401

A minor comment on the name of Timeout structure in the API: we may want to change it to BackendTimeout because the TCP ConnectTimeout can't be reused for the future client-side Timeouts.

Can we translate this to transport socket timeout for downstream connections? If so, it can be reused...

A minor comment on the name of Timeout structure in the API: we may want to change it to BackendTimeout because the TCP ConnectTimeout can't be reused for the future client-side Timeouts.

Can we translate this to transport socket timeout for downstream connections? If so, it can be reused...

Not sure about it, they look similar but not exactly the same. Are there any other possible different settings between client and backend timeouts?
@arkodg @zirain WDYT?

A minor comment on the name of Timeout structure in the API: we may want to change it to BackendTimeout because the TCP ConnectTimeout can't be reused for the future client-side Timeouts.

Can we translate this to transport socket timeout for downstream connections? If so, it can be reused...

Not sure about it, they look similar but not exactly the same. Are there any other possible different settings between client and backend timeouts?
@arkodg @zirain WDYT?

the go struct name can be changed anytime w/o breaking YAML API compatibility so no strong comments for now from my side

Regarding E2E test for this feature: echo server does support a /delay endpoint. However, since these settings are per-connection and not per-request, timed-out connections will not terminate active delayed requests. In other words, it's difficult to demonstrate a connection timeout on a specific request.

idle timeout: "The idle timeout is defined as the period in which there are no active requests."
max connection duration: "When max_connection_duration is reached and if there are no active streams, the connection will be closed"

One way to verify timeout settings with an e2e test is to trigger some upstream connections, wait for timeouts to occur and then check the relevant envoy cluster metrics.
I propose to handle the e2e test in a dedicated issue.

sure @guydc lets raise seperate GH issues for e2e and docs and tackle those in different PRs

/retest


Adding sms reference number for MA reporting

Adding sms reference number for reporting

How about adding a test that uses smsReferenceNumber?

Why? is it because you don't trust me?

How about I use it in a sentence instead?
"I added code for smsReference" .

LGTM


Fails to resolve files in multi-module Maven repo

After IDEA indexes everything, opening a file in a nested Maven repo only takes into account the source directory of the nested repo, without the parent directories. This means the LSP server can't find any files in that directory.

Fixed in 8167235ea192984d6145291a835a655e8c201082.


Ship and install git-remote-keybase on macOS

@keybase/react-hackers
This needs more testing, and there's a FIXME line to swap out before hitting the merge button.
This PR:

builds git-remote-keybase as part of doing a KBFS build (the code lives in the KBFS repo)
codesigns it
copies it into the Keybase.app/SharedSupport/bin/ dir inside the bundle being created
checks that the codesign validates
bumps the installer version
asks the installer/helper to install /usr/local/bin/git-remote-keybase at the same time it's installing /usr/local/bin/keybase
tells the build scripts to pull this newer version of the installer

The installer, unlike almost everything else, is not actually built as part of the build process.  It's just downloaded from a tarball on S3.  It's meant to be built, signed and uploaded locally.  That's why this PR bumps the installer version number.  I'm able to build/sign/upload it on my laptop.
It looks like there are changes that have been merged to the macOS installer but not built/shipped (!) that were merged as part of the split installer merge.  That might explain some of the bugs we've been seeing -- perhaps they're fixed with this code that's been merged but not shipped -- but it also means we should be extra cautious about these changes, since they're larger than we expected.

There's also the Sourcetree issue to content with: https://keybase.atlassian.net/browse/DESKTOP-5047

@chrisnojima: properly functioning software like Github Desktop and regular git seem to respect $PATH, but Sourcetree doesn't (as mentioned above). So dropping a symlink in /Applications/Xcode.app/Contents/Developer/usr/libexec/git-core will fix Sourcetree if you run with system git. It won't fix Sourcetree under the default settings (embedded git), which needs a symlink dropped in /Applications/Sourcetree.app/Contents/Resources/git_local/libexec/git-core/. @cjb's point that these symlinks will disappear after an upgrade is the biggest problem. Same goes for if these packages are installed after keybase.

yeah thats the git exec stuff i was mentioning. ok lets ignore that entire path for now and just do the path thing

ok so, this code looks fine to me. lets remove the todo and build and get this ready for testing through our regular tooling

@chrisnojima Pushed another commit (4d7cd57d).. the ObjC installer code is only called when there was an error reported by the Go installer code, so we have to try to install from Go first.


"Launch Franz on start" not working

Expected Behavior

"Launch Franz on start" disabled: Should not start at boot.
Current Behavior

"Launch Franz on start" disabled: Application starts at boot.
Screenshots (if appropriate):
Not necessary. Just disable "Launch Franz on start" in the settings.
Possible Solution

Looks like it does not remember the setting. Close and re-open -> "Launch Franz on start" is turn on (even if turned off before closing).
Steps to Reproduce (for bugs)

Disable "Launch Franz on start"
Restart (or just close and re-open application)
Look into the settings: "Launch Franz on start" is enabled

Context

I just want to disable launching at startup.
Your Environment

Franz Version used: 5.0.0-beta.10
Operating System and version: macOS 10.13

Seems like there is an issue with windows as well with Franz not starting even though the option is et.
https://twitter.com/aaneric/status/921429385495941120

@adlk can confirm the "start on windows" issue and disabling on MacOS

Ok, I did my tests on 10.12 and it worked fine. I'm going to upgrade now to 10.13 and hope that I'm able to reproduce it.

It seems like that there is an issue with Electron & High Sierra with disabling autostart.
I'll update Franz to not automatically start until this issue is resolved.
Here is the issue on electron for reference: https://github.com/electron/electron/issues/10880
If you need a solution to disable autostart

Go to System Preferences -> User -> Login
Select Franz
Remove it with the minus button

Sorry for the german screenshot but I assume you'll get it anyway :)

It continue failing on High Sierra

I'm currently using the built in electron autostart option but I'm not really satisfied how it works.
Might use node-auto-launch again as it did a much better job with previous Franz versions.
https://github.com/Teamwork/node-auto-launch

Would be better, on previous versions autostart on/off works very well

On my initial tweet https://twitter.com/aaneric/status/921429385495941120 I meant if u turn the start up option on and fully close franz and open it back up or after a reboot, "the launch franz on start" option is turned off again and thats why franz is not starting up with windows, hope it'll get fixed soon. anyways I love the new update so far, keep it up 💪😊

This bug also still exists for macOS High Sierra (10.13.3).
Please fix this!

@jakobsudau remove and download the latest version. then from dock, right click and open at startup.
for me it works. also macOS High Sierra.

Same here. Re-Installed Franz - removed it from Login Objects… it still start on Launch. macOS 10.13.2

Same problem for me. OSX v10.13.3 and Franz Version 5.0.0-beta.15

Same problem for me as well: OSX v10.13.13, Franz: 5.0.0-beta.15.  Come on guys ... I've been struggling with this for over a month now .. and it's really maddening.  This can't be complicated .. I don't understand how this is still not fixed. Can you please provide something asap on this? PLEASE!!!

Same problem here macOS 10.12.6.

Same problem on POP!_OS (Ubuntu) 17.10
Current version: 5.0.0-beta.15

Hey Guys ... FYI ... very happy to report .. the latest Beta Update which came out in the past few days (5.0.0-beta-16.762)  fixes the problem on all 3 of my Macs (all running High Sierra 10.13.3, and one 10.13.4 beta).    Note: after you first update and re-launch ... go into your Mac System Preferences to your user account "Login Items" settings, and check / remove all the Franz entries, as  the initial update may have added an extra one in there upon update ... which makes sense if you think about it.
Thanks to all the Franz dev guys ... as I know this probably didn't seem like a big deal as most people probably have it set to auto-launch anyway, but for the few of us who don't want it to auto-launch ... this really was driving us (at least me) mad. 👍


Limit max number of terminal input

VS Code Version: 1.61.2
OS Version: Windows Version 2004 (Os Build 19041.1288)

Steps to Reproduce:

Code:

import java.util.Scanner;
public class Demo{
    public static void main(String[] args) {
        Scanner sc=new Scanner(System.in);
        int N = sc.nextInt();
        int[] arr = new int[N];

        for(int i=0; i<N; i++){
          arr[i] = sc.nextInt();
        }

        for(int elem: arr){
          System.out.println(elem+" ");
    }

}
}

test_input: https://drive.google.com/file/d/1ayXET85FsCjQUJa6TDSVd7MA0OangykB/view
run java code, copy all the numbers shown in the above file but only part of them can be pasted to terminal

So i want to know what's the maximum input number in terminal. Is there any settings or option to edit its limitation?
Original Post: https://stackoverflow.com/questions/69826575/max-limit-on-number-of-input-in-vs-code-java

when I paste your example input into the terminal, it succeeds (although takes quite awhile) - what you might be seeing is the output (pasted text) trimmed relative to what you're expecting because of the maximum terminal scrollback which can be configured with terminal.integrated.scrollback


[SPARK-19229] [SQL] Disallow Creating Hive Source Tables when Hive Support is Not Enabled

What changes were proposed in this pull request?
It is weird to create Hive source tables when using InMemoryCatalog. We are unable to operate it. This PR is to block users to create Hive source tables.
How was this patch tested?
Fixed the test cases

Test build #71401 has started for PR 16587 at commit 0d2d9f2.

Test build #71401 has finished for PR 16587 at commit 0d2d9f2.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/71401/
Test FAILed.

The following test cases failed:

change-column.sql
describe.sql
show-tables.sql
show_columns.sql

All these test cases are creating hive serde tables. We might need to create another SQLQueryTestSuite in the hive package.

cc @cloud-fan @yhuai @hvanhovell Any comment?

Test build #71407 has started for PR 16587 at commit 5e0cd26.

Test build #71407 has finished for PR 16587 at commit 5e0cd26.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/71407/
Test FAILed.

Merged build finished. Test FAILed.

Test build #71485 has started for PR 16587 at commit 49e6e81.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/71485/
Test FAILed.

retest this please

Test build #71495 has started for PR 16587 at commit 49e6e81.

Test build #71495 has finished for PR 16587 at commit 49e6e81.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/71495/
Test FAILed.

Merged build finished. Test FAILed.

Test build #71528 has started for PR 16587 at commit c6d6a24.

Test build #71528 has finished for PR 16587 at commit c6d6a24.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/71528/
Test PASSed.

retest this please

Test build #71797 has started for PR 16587 at commit c6d6a24.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/71797/
Test FAILed.

retest this please

Test build #3545 has started for PR 16587 at commit c6d6a24.

Test build #3545 has finished for PR 16587 at commit c6d6a24.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

LGTM

Thanks! Merging to master.


Import FBX from Daz3D

It is nothing urgent but might be worth looking. I did just check that "Daz3D" feature  to see how it works. I did notice that after importing the model it looks wird. Even after "Fix Model" and switching from "Rest Position" to "Poste Position" we do get strage bone rotations. It is the same on Blende 2.79. It happen only when we have in import FBX option checkt "Use Pre/Post Rotation" If we uncheck that it will work just fine. Im not sure if it is good idea but maybe it might be good idea to add uncheck option  "Use Pre/Post Rotation" inside "Import Model"?

Good idea, it's now in the dev version of cats


Global $httpProvider responseInterceptors can not depend on services which depend on $http

Currently if you register a responseInterceptor on $httpProvider you can not inject a service which depends itself on $http as you get a circular dependency loop due to $http being instantiated when $httpProvider is accessed.
I'm not sure if this is a bug within the DI itself or how $httpProvider handles responseInterceptor instantiation. The error thrown is
Uncaught Error: Circular dependency: service <- $http <- $compile

Fiddle to show the problem:
http://jsfiddle.net/nkKpc/4/

thank you! :+1:

thanks. (Y)

:+1: thanks @rewritten!


Ensure mockstore's Upsert registers the call.

The reason tests of the mocked store started failing when I switched from UpsertId to Upsert.
Ref #1521. Needed for #1551

I'm going to go ahead and merge this, with the 99.9999% certainty that you won't have any suggestions :P


xen-tools: Revamp mmap allocation in QEMU

Change the algorithm of mmap-based memory allocation to
reduce the amount of PTE changes
Signed-off-by: Sergey Temerkhanov<EMAIL_ADDRESS>

Instead of calling mmap() twice, we do mmap(...PROT_READ|PROT_WRITE...) + mprotect(PROT_NONE) to get the guard pages

Right @temerkhanov -- I get this -- but what's the benefit of this way of doing things?

Instead of calling mmap() twice, we do mmap(...PROT_READ|PROT_WRITE...) + mprotect(PROT_NONE) to get the guard pages

Right @temerkhanov -- I get this -- but what's the benefit of this way of doing things?

At least it reduces amount of noise in memory profilers, and, apparently, the VSZ

The patch calls mprotect() on a memory region instead of a second mmap(), expecting, that this will reduce amount of PTE changes, which is not the case: mprotect splits VMA and updates PTE range, so performance benefits are not clear.
@eriknordmark let's close this.

Closing based on the comment from @rouming above.


conflict between yuiCssOptimize and fixVendorPrefixes

yuiCssOptimize removes unecessary semicolons in the css code but without the semicolon the regex for fixVendorPrefixes doesn't work.
example :
div.test {
-vendor-border-radius:3px;
}
after yuiCssOptimize (the semicolon is gone):
div.test {-vendor-border-radius:3px}
then fixVendorPrefixes has no effect

Can't you just move yuiCssOptimize after fixVendorPrefixes?

yes that's the solution
i've put the yuiCssOptimize in the postManipulate object


Add long-context data prep cookbook

This PR adds a cookbook that showcases to users what to do if their dataset contains many examples that are "long".
This should not appeal to users who usually end up with context-length of 512 but ones, but ones on the opposite end of the spectrum who ask themselves if their dataset will fit.

Adding a video walkthrough

Closing because I'm not on this team anymore and context has likely been lost


authenticator window size issue

https://youtu.be/Oeaw91zmw0A
Google authenticator window size issue
When click to the Google authenticator button, it open in normal size and then resize to little window. This is problem, because where is no possibility to use Google authenticator in this small window.
How ti fix?

Ooooops...
In fact, this is because I just pushed a new commit to solve issue #12... We have made JS detect zoom setting, and try to make the popup page look same under different zooms...
Depending on your video, I guess the code fails to detect zoom setting correctly, and it thinks you are under large zoom, so it scales the popup page to a small one.
Could you tell me your zoom settings and is your display a retina one?

I use 1280 x 1024 pixels on desktop Win XP SP3

Also, when for test change resolution to 1024 x 768 pixels - I have same story

And I don't use any zoom settings, all settings by default.

Could you please right click on the extension icon and click Inspect Popup, then click Console, and tell me the number you can see? Thanks.

320

I have rolled back the code to disable this feature(in fact a bug) in version 4.12, and please update your extension in 30min to 1hour to fix it.

Thanks for your feedback :-)

320 in 1024 x 768  px
400 in 1280 x 1024 px
ok, thank you)

The newest version is available in web store now, please manual update the extension by checking developer mode and clicking update extensions now button in extension settings page.


kojiapi: move to echo

Unify with the worker API and move from the chi to the echo libraries.

Test failures are due to #997, and unrelated to this PR.


Meta Description: For increased SEO

A new meta description can be added to any page of the site. The meta description is used when the site is found in google, bing, duckduckgo, etc. To inform people what the site page is about and is an important parameter in the search engine ranking of a site. A default meta description can be put in the main _config.yml
title: Hello World
description: A new page for the site.
date: 2020-09-07

good