Pyright not respecting pyenv virtualenv

nvim --version: NVIM v0.5.0-dev+1064-gb96db38af
nvim-lsp version(commit hash): 2eb8567507ee9c28ec53b9db8911b1aab55590f1
What language server (If the problem is related to a specific language server): pyright
Operating system/version: arch

How to reproduce the problem from neovim startup
I have set up two virtualenvs containing pynvim, and set the python hosts in init.vim accordingly.
pyenv virtualenv 3.9.1 neovim3
pyenv virtualenv 2.7.18 neovim2
pyenv activate neovim3
pip install pynvim
pyenv activate neovim2
pip install pynim

let g:python_host_prog = '~/.pyenv/versions/neovim2/bin/python'
let g:python3_host_prog = '~/.pyenv/versions/neovim3/bin/python'

I then created a third virtualenv
pyenv virtualenv 3.8.7 tensorflow_py38
pyenv activate tensorflow_py38
pip install numpy, tensorflow

Prior to opening a python file, I have already activated the virtualenv by setting pyenv local tensorflow_py38

Actual behaviour

Pyright is not detecting the libraries in the virtualenv
Instead it is pointing to
pyenv global 3.9.1

Expected behaviour
Minimal init.vim or init.lua and code sample

let g:python_host_prog = '~/.pyenv/versions/neovim2/bin/python'
let g:python3_host_prog = '~/.pyenv/versions/neovim3/bin/python'

call plug#begin('~/.config/nvim/plugged')
Plug 'nvim-lua/completion-nvim'
Plug 'neovim/nvim-lspconfig'
call plug#end()

set updatetime=50
set completeopt+=menuone,noselect,noinsert
set completeopt-=preview
set shortmess+=c

autocmd BufEnter * lua require'completion'.on_attach()

:lua <<EOF

require'lspconfig'.pyright.setup{}
EOF

lua vim.lsp.set_log_level('debug')
" log_path: ~/.cache/nvim/lsp.log

Health check

Checkhealth result

```
health#completion_nvim#check
general

OK: neovim version is supported

completion source

OK: all completion sources are valid

snippet source

INFO: You haven't set up any snippet source

health#lspconfig#check
Checking language server protocol configuration

INFO: pyright: configuration checked.

health#nvim#check
Configuration

OK: no issues found

Performance

OK: Build type: RelWithDebInfo

Remote Plugins

OK: Up to date

terminal

INFO: key_backspace (kbs) terminfo entry: key_backspace=\177
INFO: key_dc (kdch1) terminfo entry: key_dc=\E[3~
INFO: $COLORTERM='truecolor'

health#provider#check
Clipboard (optional)

OK: Clipboard tool found: xclip

Python 2 provider (optional)

INFO: pyenv: Path: /home/henryw/.pyenv/libexec/pyenv
INFO: pyenv: Root: /home/henryw/.pyenv
INFO: Using: g:python_host_prog = "~/.pyenv/versions/neovim2/bin/python"
INFO: Executable: /home/henryw/.pyenv/versions/neovim2/bin/python
INFO: Python version: 2.7.18
INFO: pynvim version: 0.4.2
OK: Latest pynvim is installed.

Python 3 provider (optional)

INFO: pyenv: Path: /home/henryw/.pyenv/libexec/pyenv
INFO: pyenv: Root: /home/henryw/.pyenv
INFO: Using: g:python3_host_prog = "~/.pyenv/versions/neovim3/bin/python"
INFO: Executable: /home/henryw/.pyenv/versions/neovim3/bin/python
INFO: Python version: 3.9.1
INFO: pynvim version: 0.4.2
OK: Latest pynvim is installed.

Python virtualenv

WARNING: $VIRTUAL_ENV is set to: /home/henryw/.pyenv/versions/3.8.7/envs/tensorflow_py38
And its /bin directory contains: python, python3, python3.8
But $PATH yields this python executable: /home/henryw/.pyenv/versions/tensorflow_py38/bin/python
And $PATH in subshells yields this python executable: /home/henryw/.pyenv/versions/tensorflow_py38/bin/python
And $PATH yields this python3 executable: /home/henryw/.pyenv/versions/tensorflow_py38/bin/python3
And $PATH in subshells yields this python3 executable: /home/henryw/.pyenv/versions/tensorflow_py38/bin/python3
And $PATH yields this python3.8 executable: /home/henryw/.pyenv/versions/tensorflow_py38/bin/python3.8
And $PATH in subshells yields this python3.8 executable: /home/henryw/.pyenv/versions/tensorflow_py38/bin/python3.8
So invoking Python may lead to unexpected results.

ADVICE:

$PATH ambiguities arise if the virtualenv is not properly activated prior to launching Nvim. Close Nvim, activate the virtualenv, check that invoking Python from the command line launches the correct one, then relaunch Nvim.
$PATH ambiguities in subshells typically are caused by your shell config overriding the $PATH previously set by the virtualenv. Either prevent them from doing so, or use this workaround: https://vi.stackexchange.com/a/7654

Ruby provider (optional)

INFO: Ruby: ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-linux]
WARNING: neovim-ruby-host not found.

ADVICE:

Run gem install neovim to ensure the neovim RubyGem is installed.
Run gem environment to ensure the gem bin directory is in $PATH.
If you are using rvm/rbenv/chruby, try "rehashing".
See :help |g:ruby_host_prog| for non-standard gem installations.

Node.js provider (optional)

INFO: Node.js: v15.8.0
INFO: Nvim node.js host: /usr/lib/node_modules/neovim/bin/cli.js
OK: Latest "neovim" npm/yarn package is installed: 4.9.0

Perl provider (optional)

ERROR: perl provider error:

ADVICE:

"Neovim::Ext" cpan module is not installed

</details>

### LSP log
<!-- If not using the minimal_init.lua please add vim.lsp.set_log_level("debug") to your lua block
     in init.vim and paste a link to your log file, located at  $HOME/.cache/nvim/lsp.log (formerly $HOME/.local/share/nvim/lsp.log) -->
<details>
<summary>Log file</summary>
<!-- past you log between here -->

[ INFO ] 2021-02-04T15:59:13+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:311 ]	"Starting RPC client"	{  args = { "--stdio" },  cmd = "pyright-langserver",  extra = {}}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ....mount_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp.lua:647 ]	"LSP[pyright]"	"initialize_params"	{  capabilities = {    callHierarchy = {      dynamicRegistration = false,       = <1>{        __tostring = <function 1>      }    },    textDocument = {      codeAction = {        codeActionLiteralSupport = {          codeActionKind = {            valueSet = { "", "Empty", "QuickFix", "Refactor", "RefactorExtract", "RefactorInline", "RefactorRewrite", "Source", "SourceOrganizeImports", "quickfix", "refactor", "refactor.extract", "refactor.inline", "refactor.rewrite", "source", "source.organizeImports" },             = <table 1>          },           = <table 1>        },        dynamicRegistration = false,         = <table 1>      },      completion = {        completionItem = {          commitCharactersSupport = false,          deprecatedSupport = false,          documentationFormat = { "markdown", "plaintext" },          preselectSupport = false,          snippetSupport = false,           = <table 1>        },        completionItemKind = {          valueSet = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25 },           = <table 1>        },        contextSupport = false,        dynamicRegistration = false,         = <table 1>      },      declaration = {        linkSupport = true,         = <table 1>      },      definition = {        linkSupport = true,         = <table 1>      },      documentHighlight = {        dynamicRegistration = false,         = <table 1>      },      documentSymbol = {        dynamicRegistration = false,        hierarchicalDocumentSymbolSupport = true,        symbolKind = {          valueSet = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26 },           = <table 1>        },         = <table 1>      },      hover = {        contentFormat = { "markdown", "plaintext" },        dynamicRegistration = false,         = <table 1>      },      implementation = {        linkSupport = true,         = <table 1>      },      publishDiagnostics = {        relatedInformation = true,        tagSupport = {          valueSet = { 1, 2 },           = <table 1>        },         = <table 1>      },      references = {        dynamicRegistration = false,         = <table 1>      },      rename = {        dynamicRegistration = false,        prepareSupport = true,         = <table 1>      },      signatureHelp = {        dynamicRegistration = false,        signatureInformation = {          documentationFormat = { "markdown", "plaintext" },           = <table 1>        },         = <table 1>      },      synchronization = {        didSave = true,        dynamicRegistration = false,        willSave = false,        willSaveWaitUntil = false,         = <table 1>      },      typeDefinition = {        linkSupport = true,         = <table 1>      },       = <table 1>    },    window = {      showDocument = {        support = false,         = <table 1>      },      showMessage = {        messageActionItem = {          additionalPropertiesSupport = false,           = <table 1>        },         = <table 1>      },      workDoneProgress = true,       = <table 1>    },    workspace = {      applyEdit = true,      configuration = true,      symbol = {        dynamicRegistration = false,        hierarchicalWorkspaceSymbolSupport = true,        symbolKind = {          valueSet = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26 },           = <table 1>        },         = <table 1>      },      workspaceFolders = true,       = <table 1>    }  },  clientInfo = {    name = "Neovim",    version = "0.5.0"  },  initializationOptions = vim.empty_dict(),  processId = 4180585,  rootPath = "/home/henryw/Documents/Study/Pattern_Recognition,_Neural_Networks_and_Deep_Learning/coursework_wk5",  rootUri = "file:///home/henryw/Documents/Study/Pattern_Recognition,_Neural_Networks_and_Deep_Learning/coursework_wk5",  trace = "off",  workspaceFolders = { {      name = "/home/henryw/Documents/Study/Pattern_Recognition,_Neural_Networks_and_Deep_Learning/coursework_wk5",      uri = "file:///home/henryw/Documents/Study/Pattern_Recognition,_Neural_Networks_and_Deep_Learning/coursework_wk5"    } }}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:388 ]	"rpc.send.payload"	{  id = 1,  jsonrpc = "2.0",  method = "initialize",  params = {    capabilities = {      callHierarchy = {        dynamicRegistration = false,         = <1>{          __tostring = <function 1>        }      },      textDocument = {        codeAction = {          codeActionLiteralSupport = {            codeActionKind = {              valueSet = { "", "Empty", "QuickFix", "Refactor", "RefactorExtract", "RefactorInline", "RefactorRewrite", "Source", "SourceOrganizeImports", "quickfix", "refactor", "refactor.extract", "refactor.inline", "refactor.rewrite", "source", "source.organizeImports" },               = <table 1>            },             = <table 1>          },          dynamicRegistration = false,           = <table 1>        },        completion = {          completionItem = {            commitCharactersSupport = false,            deprecatedSupport = false,            documentationFormat = { "markdown", "plaintext" },            preselectSupport = false,            snippetSupport = false,             = <table 1>          },          completionItemKind = {            valueSet = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25 },             = <table 1>          },          contextSupport = false,          dynamicRegistration = false,           = <table 1>        },        declaration = {          linkSupport = true,           = <table 1>        },        definition = {          linkSupport = true,           = <table 1>        },        documentHighlight = {          dynamicRegistration = false,           = <table 1>        },        documentSymbol = {          dynamicRegistration = false,          hierarchicalDocumentSymbolSupport = true,          symbolKind = {            valueSet = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26 },             = <table 1>          },           = <table 1>        },        hover = {          contentFormat = { "markdown", "plaintext" },          dynamicRegistration = false,           = <table 1>        },        implementation = {          linkSupport = true,           = <table 1>        },        publishDiagnostics = {          relatedInformation = true,          tagSupport = {            valueSet = { 1, 2 },             = <table 1>          },           = <table 1>        },        references = {          dynamicRegistration = false,           = <table 1>        },        rename = {          dynamicRegistration = false,          prepareSupport = true,           = <table 1>        },        signatureHelp = {          dynamicRegistration = false,          signatureInformation = {            documentationFormat = { "markdown", "plaintext" },             = <table 1>          },           = <table 1>        },        synchronization = {          didSave = true,          dynamicRegistration = false,          willSave = false,          willSaveWaitUntil = false,           = <table 1>        },        typeDefinition = {          linkSupport = true,           = <table 1>        },         = <table 1>      },      window = {        showDocument = {          support = false,           = <table 1>        },        showMessage = {          messageActionItem = {            additionalPropertiesSupport = false,             = <table 1>          },           = <table 1>        },        workDoneProgress = true,         = <table 1>      },      workspace = {        applyEdit = true,        configuration = true,        symbol = {          dynamicRegistration = false,          hierarchicalWorkspaceSymbolSupport = true,          symbolKind = {            valueSet = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26 },             = <table 1>          },           = <table 1>        },        workspaceFolders = true,         = <table 1>      }    },    clientInfo = {      name = "Neovim",      version = "0.5.0"    },    initializationOptions = vim.empty_dict(),    processId = 4180585,    rootPath = "/home/henryw/Documents/Study/Pattern_Recognition,_Neural_Networks_and_Deep_Learning/coursework_wk5",    rootUri = "file:///home/henryw/Documents/Study/Pattern_Recognition,_Neural_Networks_and_Deep_Learning/coursework_wk5",    trace = "off",    workspaceFolders = { {        name = "/home/henryw/Documents/Study/Pattern_Recognition,_Neural_Networks_and_Deep_Learning/coursework_wk5",        uri = "file:///home/henryw/Documents/Study/Pattern_Recognition,_Neural_Networks_and_Deep_Learning/coursework_wk5"      } }  }}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:489 ]	"decoded"	{  jsonrpc = "2.0",  method = "window/logMessage",  params = {    message = "Pyright language server 1.1.107 starting",    type = 3  }}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ....mount_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp.lua:500 ]	"notification"	"window/logMessage"	{  message = "Pyright language server 1.1.107 starting",  type = 3}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...imdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:407 ]	"default_handler"	"window/logMessage"	{  client_id = 1,  params = {    message = "Pyright language server 1.1.107 starting",    type = 3  }}
[ INFO ] 2021-02-04T15:59:13+0000 ] ...imdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:379 ]	"Pyright language server 1.1.107 starting"
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:489 ]	"decoded"	{  jsonrpc = "2.0",  method = "window/logMessage",  params = {    message = "Server root directory: /usr/lib/node_modules/pyright/dist/",    type = 3  }}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ....mount_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp.lua:500 ]	"notification"	"window/logMessage"	{  message = "Server root directory: /usr/lib/node_modules/pyright/dist/",  type = 3}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...imdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:407 ]	"default_handler"	"window/logMessage"	{  client_id = 1,  params = {    message = "Server root directory: /usr/lib/node_modules/pyright/dist/",    type = 3  }}
[ INFO ] 2021-02-04T15:59:13+0000 ] ...imdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:379 ]	"Server root directory: /usr/lib/node_modules/pyright/dist/"
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:489 ]	"decoded"	{  id = 1,  jsonrpc = "2.0",  result = {    capabilities = {      callHierarchyProvider = true,      codeActionProvider = {        codeActionKinds = { "quickfix", "source.organizeImports" },        workDoneProgress = true      },      completionProvider = {        resolveProvider = true,        triggerCharacters = { ".", "[" },        workDoneProgress = true      },      definitionProvider = {        workDoneProgress = true      },      documentHighlightProvider = {        workDoneProgress = true      },      documentSymbolProvider = {        workDoneProgress = true      },      executeCommandProvider = {        commands = {},        workDoneProgress = true      },      hoverProvider = {        workDoneProgress = true      },      referencesProvider = {        workDoneProgress = true      },      renameProvider = {        workDoneProgress = true      },      signatureHelpProvider = {        triggerCharacters = { "(", ",", ")" },        workDoneProgress = true      },      textDocumentSync = 2,      workspaceSymbolProvider = {        workDoneProgress = true      }    }  }}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:388 ]	"rpc.send.payload"	{  jsonrpc = "2.0",  method = "initialized",  params = {    [true] = 6  }}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:388 ]	"rpc.send.payload"	{  jsonrpc = "2.0",  method = "workspace/didChangeConfiguration",  params = {    settings = {      python = {        analysis = {          autoSearchPaths = true,          useLibraryCodeForTypes = true,           = <1>{            __tostring = <function 1>          }        },         = <table 1>      },       = <table 1>    }  }}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ....mount_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp.lua:674 ]	"LSP[pyright]"	"server_capabilities"	{  callHierarchyProvider = true,  codeActionProvider = {    codeActionKinds = { "quickfix", "source.organizeImports" },    workDoneProgress = true  },  completionProvider = {    resolveProvider = true,    triggerCharacters = { ".", "[" },    workDoneProgress = true  },  definitionProvider = {    workDoneProgress = true  },  documentHighlightProvider = {    workDoneProgress = true  },  documentSymbolProvider = {    workDoneProgress = true  },  executeCommandProvider = {    commands = {},    workDoneProgress = true  },  hoverProvider = {    workDoneProgress = true  },  referencesProvider = {    workDoneProgress = true  },  renameProvider = {    workDoneProgress = true  },  signatureHelpProvider = {    triggerCharacters = { "(", ",", ")" },    workDoneProgress = true  },  textDocumentSync = 2,  workspaceSymbolProvider = {    workDoneProgress = true  }}
[ INFO ] 2021-02-04T15:59:13+0000 ] ....mount_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp.lua:675 ]	"LSP[pyright]"	"initialized"	{  resolved_capabilities = {    call_hierarchy = true,    code_action = {      codeActionKinds = { "quickfix", "source.organizeImports" },      workDoneProgress = true    },    completion = true,    declaration = false,    document_formatting = false,    document_highlight = {      workDoneProgress = true    },    document_range_formatting = false,    document_symbol = {      workDoneProgress = true    },    execute_command = true,    find_references = {      workDoneProgress = true    },    goto_definition = {      workDoneProgress = true    },    hover = {      workDoneProgress = true    },    implementation = false,    rename = true,    signature_help = true,    signature_help_trigger_characters = { "(", ",", ")" },    text_document_did_change = 2,    text_document_open_close = true,    text_document_save = false,    text_document_save_include_text = false,    text_document_will_save = false,    text_document_will_save_wait_until = false,    type_definition = false,    workspace_folder_properties = {      changeNotifications = false,      supported = false    },    workspace_symbol = {      workDoneProgress = true    }  }}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:388 ]	"rpc.send.payload"	{  jsonrpc = "2.0",  method = "textDocument/didOpen",  params = {    textDocument = {      languageId = "python",      text = "import numpy as np\nimport tensorflow as tf\n\n\n",      uri = "file:///home/henryw/Documents/Study/Pattern_Recognition,_Neural_Networks_and_Deep_Learning/coursework_wk5/test.py",      version = 0    }  }}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:489 ]	"decoded"	{  id = 0,  jsonrpc = "2.0",  method = "client/registerCapability",  params = {    registrations = { {        id = "e0ec5f4c-1b36-44c6-aab7-99b8cd0763ff",        method = "workspace/didChangeWorkspaceFolders",        registerOptions = vim.empty_dict()      } }  }}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ....mount_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp.lua:514 ]	"server_request"	"client/registerCapability"	{  registrations = { {      id = "e0ec5f4c-1b36-44c6-aab7-99b8cd0763ff",      method = "workspace/didChangeWorkspaceFolders",      registerOptions = {}    } }}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ....mount_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp.lua:517 ]	"server_request: found handler for"	"client/registerCapability"
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...imdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:407 ]	"default_handler"	"client/registerCapability"	{  client_id = 1,  params = {    registrations = { {        id = "e0ec5f4c-1b36-44c6-aab7-99b8cd0763ff",        method = "workspace/didChangeWorkspaceFolders",        registerOptions = {}      } }  }}
[ WARN ] 2021-02-04T15:59:13+0000 ] ...imdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:108 ]	"The language server pyright triggers a registerCapability handler despite dynamicRegistration set to false. Report upstream, this warning is harmless"
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:500 ]	"server_request: callback result"	{  result = vim.NIL,  status = true}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:388 ]	"rpc.send.payload"	{  id = 0,  jsonrpc = "2.0",  result = vim.NIL}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:489 ]	"decoded"	{  id = 1,  jsonrpc = "2.0",  method = "workspace/configuration",  params = {    items = { {        scopeUri = "file:///home/henryw/Documents/Study/Pattern_Recognition,_Neural_Networks_and_Deep_Learning/coursework_wk5",        section = "python"      } }  }}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ....mount_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp.lua:514 ]	"server_request"	"workspace/configuration"	{  items = { {      scopeUri = "file:///home/henryw/Documents/Study/Pattern_Recognition,_Neural_Networks_and_Deep_Learning/coursework_wk5",      section = "python"    } }}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ....mount_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp.lua:517 ]	"server_request: found handler for"	"workspace/configuration"
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...imdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:407 ]	"default_handler"	"workspace/configuration"	{  client_id = 1,  params = {    items = { {        scopeUri = "file:///home/henryw/Documents/Study/Pattern_Recognition,_Neural_Networks_and_Deep_Learning/coursework_wk5",        section = "python"      } }  }}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:500 ]	"server_request: callback result"	{  result = { {      analysis = {        autoSearchPaths = true,        useLibraryCodeForTypes = true,         = <1>{          __tostring = <function 1>        }      },       = <table 1>    } },  status = true}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:388 ]	"rpc.send.payload"	{  id = 1,  jsonrpc = "2.0",  result = { {      analysis = {        autoSearchPaths = true,        useLibraryCodeForTypes = true,         = <1>{          __tostring = <function 1>        }      },       = <table 1>    } }}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:489 ]	"decoded"	{  id = 2,  jsonrpc = "2.0",  method = "workspace/configuration",  params = {    items = { {        scopeUri = "file:///home/henryw/Documents/Study/Pattern_Recognition,_Neural_Networks_and_Deep_Learning/coursework_wk5",        section = "python.analysis"      } }  }}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ....mount_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp.lua:514 ]	"server_request"	"workspace/configuration"	{  items = { {      scopeUri = "file:///home/henryw/Documents/Study/Pattern_Recognition,_Neural_Networks_and_Deep_Learning/coursework_wk5",      section = "python.analysis"    } }}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ....mount_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp.lua:517 ]	"server_request: found handler for"	"workspace/configuration"
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...imdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:407 ]	"default_handler"	"workspace/configuration"	{  client_id = 1,  params = {    items = { {        scopeUri = "file:///home/henryw/Documents/Study/Pattern_Recognition,_Neural_Networks_and_Deep_Learning/coursework_wk5",        section = "python.analysis"      } }  }}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:500 ]	"server_request: callback result"	{  result = { {      autoSearchPaths = true,      useLibraryCodeForTypes = true,       = {        __tostring = <function 1>      }    } },  status = true}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:388 ]	"rpc.send.payload"	{  id = 2,  jsonrpc = "2.0",  result = { {      autoSearchPaths = true,      useLibraryCodeForTypes = true,       = {        __tostring = <function 1>      }    } }}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:489 ]	"decoded"	{  id = 3,  jsonrpc = "2.0",  method = "workspace/configuration",  params = {    items = { {        scopeUri = "file:///home/henryw/Documents/Study/Pattern_Recognition,_Neural_Networks_and_Deep_Learning/coursework_wk5",        section = "pyright"      } }  }}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ....mount_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp.lua:514 ]	"server_request"	"workspace/configuration"	{  items = { {      scopeUri = "file:///home/henryw/Documents/Study/Pattern_Recognition,_Neural_Networks_and_Deep_Learning/coursework_wk5",      section = "pyright"    } }}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ....mount_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp.lua:517 ]	"server_request: found handler for"	"workspace/configuration"
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...imdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:407 ]	"default_handler"	"workspace/configuration"	{  client_id = 1,  params = {    items = { {        scopeUri = "file:///home/henryw/Documents/Study/Pattern_Recognition,_Neural_Networks_and_Deep_Learning/coursework_wk5",        section = "pyright"      } }  }}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:500 ]	"server_request: callback result"	{  result = { vim.NIL },  status = true}
[ DEBUG ] 2021-02-04T15:59:13+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:388 ]	"rpc.send.payload"	{  id = 3,  jsonrpc = "2.0",  result = { vim.NIL }}
[ DEBUG ] 2021-02-04T15:59:14+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:489 ]	"decoded"	{  jsonrpc = "2.0",  method = "window/logMessage",  params = {    message = "No configuration file found.",    type = 3  }}
[ DEBUG ] 2021-02-04T15:59:14+0000 ] ....mount_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp.lua:500 ]	"notification"	"window/logMessage"	{  message = "No configuration file found.",  type = 3}
[ DEBUG ] 2021-02-04T15:59:14+0000 ] ...imdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:407 ]	"default_handler"	"window/logMessage"	{  client_id = 1,  params = {    message = "No configuration file found.",    type = 3  }}
[ INFO ] 2021-02-04T15:59:14+0000 ] ...imdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:379 ]	"No configuration file found."
[ DEBUG ] 2021-02-04T15:59:14+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:489 ]	"decoded"	{  jsonrpc = "2.0",  method = "window/logMessage",  params = {    message = "stubPath /home/henryw/Documents/Study/Pattern_Recognition,_Neural_Networks_and_Deep_Learning/coursework_wk5/typings is not a valid directory.",    type = 1  }}
[ DEBUG ] 2021-02-04T15:59:14+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:489 ]	"decoded"	{  jsonrpc = "2.0",  method = "window/logMessage",  params = {    message = "Assuming Python platform Linux",    type = 3  }}
[ DEBUG ] 2021-02-04T15:59:14+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:489 ]	"decoded"	{  jsonrpc = "2.0",  method = "window/logMessage",  params = {    message = "Exception received when installing recursive file system watcher",    type = 1  }}
[ DEBUG ] 2021-02-04T15:59:14+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:489 ]	"decoded"	{  jsonrpc = "2.0",  method = "window/logMessage",  params = {    message = "Searching for source files",    type = 3  }}
[ DEBUG ] 2021-02-04T15:59:14+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:489 ]	"decoded"	{  jsonrpc = "2.0",  method = "window/logMessage",  params = {    message = "Found 1 source file",    type = 3  }}
[ DEBUG ] 2021-02-04T15:59:14+0000 ] ....mount_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp.lua:500 ]	"notification"	"window/logMessage"	{  message = "stubPath /home/henryw/Documents/Study/Pattern_Recognition,_Neural_Networks_and_Deep_Learning/coursework_wk5/typings is not a valid directory.",  type = 1}
[ DEBUG ] 2021-02-04T15:59:14+0000 ] ...imdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:407 ]	"default_handler"	"window/logMessage"	{  client_id = 1,  params = {    message = "stubPath /home/henryw/Documents/Study/Pattern_Recognition,_Neural_Networks_and_Deep_Learning/coursework_wk5/typings is not a valid directory.",    type = 1  }}
[ ERROR ] 2021-02-04T15:59:14+0000 ] ...imdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:375 ]	"stubPath /home/henryw/Documents/Study/Pattern_Recognition,_Neural_Networks_and_Deep_Learning/coursework_wk5/typings is not a valid directory."
[ DEBUG ] 2021-02-04T15:59:14+0000 ] ....mount_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp.lua:500 ]	"notification"	"window/logMessage"	{  message = "Assuming Python platform Linux",  type = 3}
[ DEBUG ] 2021-02-04T15:59:14+0000 ] ...imdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:407 ]	"default_handler"	"window/logMessage"	{  client_id = 1,  params = {    message = "Assuming Python platform Linux",    type = 3  }}
[ INFO ] 2021-02-04T15:59:14+0000 ] ...imdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:379 ]	"Assuming Python platform Linux"
[ DEBUG ] 2021-02-04T15:59:14+0000 ] ....mount_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp.lua:500 ]	"notification"	"window/logMessage"	{  message = "Exception received when installing recursive file system watcher",  type = 1}
[ DEBUG ] 2021-02-04T15:59:14+0000 ] ...imdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:407 ]	"default_handler"	"window/logMessage"	{  client_id = 1,  params = {    message = "Exception received when installing recursive file system watcher",    type = 1  }}
[ ERROR ] 2021-02-04T15:59:14+0000 ] ...imdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:375 ]	"Exception received when installing recursive file system watcher"
[ DEBUG ] 2021-02-04T15:59:14+0000 ] ....mount_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp.lua:500 ]	"notification"	"window/logMessage"	{  message = "Searching for source files",  type = 3}
[ DEBUG ] 2021-02-04T15:59:14+0000 ] ...imdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:407 ]	"default_handler"	"window/logMessage"	{  client_id = 1,  params = {    message = "Searching for source files",    type = 3  }}
[ INFO ] 2021-02-04T15:59:14+0000 ] ...imdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:379 ]	"Searching for source files"
[ DEBUG ] 2021-02-04T15:59:14+0000 ] ....mount_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp.lua:500 ]	"notification"	"window/logMessage"	{  message = "Found 1 source file",  type = 3}
[ DEBUG ] 2021-02-04T15:59:14+0000 ] ...imdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:407 ]	"default_handler"	"window/logMessage"	{  client_id = 1,  params = {    message = "Found 1 source file",    type = 3  }}
[ INFO ] 2021-02-04T15:59:14+0000 ] ...imdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:379 ]	"Found 1 source file"
[ DEBUG ] 2021-02-04T15:59:14+0000 ] ...nt_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:489 ]	"decoded"	{  jsonrpc = "2.0",  method = "textDocument/publishDiagnostics",  params = {    diagnostics = { {        code = "reportMissingImports",        codeDescription = {          href = "https://github.com/microsoft/pyright/blob/master/docs/configuration.md"        },        message = 'Import "numpy" could not be resolved',        range = {          end = {            character = 12,            line = 0          },          start = {            character = 7,            line = 0          }        },        severity = 1,        source = "Pyright"      }, {        code = "reportMissingImports",        codeDescription = {          href = "https://github.com/microsoft/pyright/blob/master/docs/configuration.md"        },        message = 'Import "tensorflow" could not be resolved',        range = {          end = {            character = 17,            line = 1          },          start = {            character = 7,            line = 1          }        },        severity = 1,        source = "Pyright"      }, {        message = '"np" is not accessed',        range = {          end = {            character = 18,            line = 0          },          start = {            character = 16,            line = 0          }        },        severity = 4,        source = "Pyright",        tags = { 1 }      }, {        message = '"tf" is not accessed',        range = {          end = {            character = 23,            line = 1          },          start = {            character = 21,            line = 1          }        },        severity = 4,        source = "Pyright",        tags = { 1 }      } },    uri = "file:///home/henryw/Documents/Study/Pattern_Recognition%2C_Neural_Networks_and_Deep_Learning/coursework_wk5/test.py"  }}
[ DEBUG ] 2021-02-04T15:59:14+0000 ] ....mount_nvimdJSQYn/usr/share/nvim/runtime/lua/vim/lsp.lua:500 ]	"notification"	"textDocument/publishDiagnostics"	{  diagnostics = { {      code = "reportMissingImports",      codeDescription = {        href = "https://github.com/microsoft/pyright/blob/master/docs/configuration.md"      },      message = 'Import "numpy" could not be resolved',      range = {        end = {          character = 12,          line = 0        },        start = {          character = 7,          line = 0        }      },      severity = 1,      source = "Pyright"    }, {      code = "reportMissingImports",      codeDescription = {        href = "https://github.com/microsoft/pyright/blob/master/docs/configuration.md"      },      message = 'Import "tensorflow" could not be resolved',      range = {        end = {          character = 17,          line = 1        },        start = {          character = 7,          line = 1        }      },      severity = 1,      source = "Pyright"    }, {      message = '"np" is not accessed',      range = {        end = {          character = 18,          line = 0        },        start = {          character = 16,          line = 0        }      },      severity = 4,      source = "Pyright",      tags = { 1 }    }, {      message = '"tf" is not accessed',      range = {        end = {          character = 23,          line = 1        },        start = {          character = 21,          line = 1        }      },      severity = 4,      source = "Pyright",      tags = { 1 }    } },  uri = "file:///home/henryw/Documents/Study/Pattern_Recognition%2C_Neural_Networks_and_Deep_Learning/coursework_wk5/test.py"}
[ DEBUG ] 2021-02-04T15:59:14+0000 ] ...imdJSQYn/usr/share/nvim/runtime/lua/vim/lsp/handlers.lua:407 ]	"default_handler"	"textDocument/publishDiagnostics"	{  client_id = 1,  params = {    diagnostics = { {        code = "reportMissingImports",        codeDescription = {          href = "https://github.com/microsoft/pyright/blob/master/docs/configuration.md"        },        message = 'Import "numpy" could not be resolved',        range = {          end = {            character = 12,            line = 0          },          start = {            character = 7,            line = 0          }        },        severity = 1,        source = "Pyright"      }, {        code = "reportMissingImports",        codeDescription = {          href = "https://github.com/microsoft/pyright/blob/master/docs/configuration.md"        },        message = 'Import "tensorflow" could not be resolved',        range = {          end = {            character = 17,            line = 1          },          start = {            character = 7,            line = 1          }        },        severity = 1,        source = "Pyright"      }, {        message = '"np" is not accessed',        range = {          end = {            character = 18,            line = 0          },          start = {            character = 16,            line = 0          }        },        severity = 4,        source = "Pyright",        tags = { 1 }      }, {        message = '"tf" is not accessed',        range = {          end = {            character = 23,            line = 1          },          start = {            character = 21,            line = 1          }        },        severity = 4,        source = "Pyright",        tags = { 1 }      } },    uri = "file:///home/henryw/Documents/Study/Pattern_Recognition%2C_Neural_Networks_and_Deep_Learning/coursework_wk5/test.py"  }}
</details>

pyenv does weird things with shims, I can tell you that if VIRTUAL_ENV is pointing to the correct virtual environment, then pyright will use the correct virtual environment (I use it almost every day).

pyenv does weird things with shims, I can tell you that if VIRTUAL_ENV is pointing to the correct virtual environment, then pyright will use the correct virtual environment (I use it almost every day).
hmm, healthcheck showing error for python provider, and I don't know how to fix it. I tried the solution on the suggested stackoverflow but its not working.

Well, the python provider is orthogonal since we don't use it for neovim's language server client :)

Well, the python provider is orthogonal since we don't use it for neovim's language server client :)

"""
Python virtualenv

WARNING: $VIRTUAL_ENV is set to: /home/henryw/.pyenv/versions/3.8.7/envs/tensorflow_py38
And its /bin directory contains: python, python3, python3.8
But $PATH yields this python executable: /home/henryw/.pyenv/versions/tensorflow_py38/bin/python
And $PATH in subshells yields this python executable: /home/henryw/.pyenv/versions/tensorflow_py38/bin/python
And $PATH yields this python3 executable: /home/henryw/.pyenv/versions/tensorflow_py38/bin/python3
And $PATH in subshells yields this python3 executable: /home/henryw/.pyenv/versions/tensorflow_py38/bin/python3
And $PATH yields this python3.8 executable: /home/henryw/.pyenv/versions/tensorflow_py38/bin/python3.8
And $PATH in subshells yields this python3.8 executable: /home/henryw/.pyenv/versions/tensorflow_py38/bin/python3.8
So invoking Python may lead to unexpected results.

ADVICE:

$PATH ambiguities arise if the virtualenv is not properly activated prior to launching Nvim. Close Nvim, activate the virtualenv, check that invoking Python from the command line launches the correct one, then relaunch Nvim.
$PATH ambiguities in subshells typically are caused by your shell config overriding the $PATH previously set by the virtualenv. Either prevent them from doing so, or use this workaround: https://vi.stackexchange.com/a/7654
"""

I tried echo $VIRTUAL_ENV, and apparently it is pointing at the correct path:

Maybe try with a standard virtual_environment and work backwards then?

Maybe try with a standard virtual environment and work backwards then?

It works with a standard virtual environment created with virtualenv.

Ohhh, interesting. I have no idea then. Are you in the folder tensorflow_py38 before launching neovim?

I didn't launch neovim in the virtualenv folder, but in this:

pyenv local is only going to trigger on directory change into that folder

Can you try launching neovim from within the folder, and then opening your file?

Nope still not working.

If I do pyenv activate tensorflow_py38, even if I have already set pyenv local tensorflow_py38, then it works! How strange! I think pyenv local is not working.

🤷♀ I don't use pyenv, I always found it's system of managing python versions a bit clunky

I haven't used pyenv in a while. But if I remember correctly, it's using some kind of hook and/or wraps cd. But the server will be started in a new environment/shell, and would have to trigger whatever machinery is behind pyenv local.

Put another way, imagine you had function python in your .bashrc that will lookup the correct interpreter using pyenv local. Which means when you type python in your shell it will magically use the correct Python version. This is more or less how pyenv works with its shims.
But this only works in an interactive shell that will source .bashrc. But the language server isn't running inside an interactive shell, which means it won't source .bashrc. So the python function you created doesn't exist and it will lookup python in $PATH instead.
Using pyenv shell tensorflow_py38 works because it will alter your environment (update $PATH etc). Same when you activate a regular virtualenv. And when you launch Neovim this is inherited all the way to starting the language server which will (again) look in updated $PATH and find the correct python.

Put another way, imagine you had function python in your .bashrc that will lookup the correct interpreter using pyenv local. So when you type python in your shell it will magically use the correct Python version according to pyenv. This is more or less how pyenv works with its shims.
The problem is this only works in an interactive shell that will source .bashrc. But the language server isn't running inside an interactive shell, which means it won't source .bashrc. So the python function you created doesn't exist and it will try to lookup python in $PATH instead.
Using pyenv shell tensorflow_py38 works because it will alter your environment (update $PATH etc). Same when you activate a regular virtualenv. And when you launch Neovim this is inherited all the way to starting the language server which will (again) look in the altered $PATH and find the correct python.

Thank you for your explanation, I have put this in my config.fish, I just have to run this function everytime before I open vim :/
function act
    if set -q VIRTUAL_ENV
        pyenv shell (echo $VIRTUAL_ENV | sed 's/\(.*\)\/\(.*\)/\2/')
    else
        pyenv shell --unset
    end
end

Thank you @mjlbach, you are a legend as always :)
I'll open an issue on pyenv to see if I could do pyenv shell automatically.

After quite a few hours of struggling, I am going to give up on using pyenv-virtualenv. I'm just going to use pyenv as a python version manager, and use manually activate virtualenvs.

I think that's actually the recommended workflow when using pyenv.

Hello people, checkout this plugin pyenv-pyright I created.
With it you can setup pyright to use pyenv venvs with only one command:
pyenv local my-venv
pyenv pyright

or
pyenv pyright my-venv

This will automatically create/update .pyrightconfig.json file. Its a convenient way to overcome neovim+pyright+pyenv virtualenvs setup.
https://github.com/alefpereira/pyenv-pyright

For anyone interested in alternatives: I've been a pyenv/pyenv-virtualenv for many years, and I have been a coc-pyright user for good time, never had any issue to tackle pyenv/pyenv-virtualenv. I kinda see the struggle here with estrangement.

It seems pyright or vim repsects the PYENV_VERSION environment variable.
Running nvim with PYENV_VERSION=myvirtualenvname nvim  makes nvim pick up the right virtual environment.

Hello people, checkout this plugin pyenv-pyright I created. With it you can setup pyright to use pyenv venvs with only one command:
pyenv local my-venv
pyenv pyright

or
pyenv pyright my-venv

This will automatically create/update .pyrightconfig.json file with the pyenv virtualenv of your choice. Its a convenient way to overcome neovim+pyright+pyenv virtualenvs setup. https://github.com/alefpereira/pyenv-pyright

Thanks, this is such a neat implementation. :)

Hi folks,
@alefpereira - TY very much for the help with pyright! pyenv pyright plugin works like a charm! That helps immensely! I don't see anyone commenting about pylint however - am I maybe missing something obvious or are other people using a different linter?

I don't know why but i just put the result of my observation here
If your set $PYENV_VERSION like export $PYENV_VERSION="tensorflow_py38" , it works.
The only difference between pyenv local tensorflow_py38 and pyenv activate tensorflow_py38 is that the former does not include the  $PYENV_VERSION variable

Hello people, checkout this plugin pyenv-pyright I created. With it you can setup pyright to use pyenv venvs with only one command:
pyenv local my-venv
pyenv pyright

or
pyenv pyright my-venv

This will automatically create/update .pyrightconfig.json file with the pyenv virtualenv of your choice. Its a convenient way to overcome neovim+pyright+pyenv virtualenvs setup. https://github.com/alefpereira/pyenv-pyright

Neat! Thanks so much I confirmed it worked for me!

Related #500

Other workaround, add
vim.env.PYENV_VERSION = vim.fn.system('pyenv version'):match('(%S+)%s+%(.-%)')

at the beginning of the lua config.


[Outlook] (ui) Change recommendation from Framework7 to Fluent UI

Fixes 2778
This is too trivial to need a review.

Docs Build status updates of commit df54f6d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/outlook/outlook-addin-design.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Problem running Gendarme plugin

Jenkins test failure:    DevAudit.Linux.netfx
SA-NETFX-0001-GendarmeRules analyzing...SA-NETFX-0001-GendarmeRules analyzing.../ 06:36:01<04> [SCRIPT] [ERROR] Exception: Could not load file or assembly '/home/vor/.jenkins/jobs/DevAudit.Linux/workspace/DevAudit.CommandLine/bin/Debug/Gendarme.Rules.Security.dll' or one of its dependencies at   at (wrapper managed-to-native) System.Reflection.Assembly:InternalGetAssemblyName (string,System.Reflection.AssemblyName)
  at System.Reflection.AssemblyName.GetAssemblyName (System.String assemblyFile) [0x0001d] in <8f2c484307284b51944a1a13a14c0266>:0
  at DevAudit.AuditLibrary.DevAuditGendarmeRunner.LoadRulesFromAssembly (System.String assemblyName) [0x00001] in <f07acba1d0914a8f81f3553175c6537d>:0
  at DevAudit.AuditLibrary.DevAuditGendarmeRunner..ctor (Mono.Cecil.AssemblyDefinition assembly, System.String rules_library_name, DevAudit.AuditLibrary.ScriptEnvironment environment) [0x00052] in <f07acba1d0914a8f81f3553175c6537d>:0
  at DevAudit.AuditLibrary.Analyzers.GendarmeRulesAnalyzer.Analyze () [0x00047] in <3deae16756f949ec924ae196483af742>:0 .

Was DevAudit built with the build.sh script? The script contains a command to copy the Gendarme assembly DLLs to the runtime folder. The directory DevAudit.CommandLine/bin/Debug should have a bunch of Gendarme.Rules.*.dll files.

Good call. I am surprised it was working earlier when running xbuild directly.


Change ternary expression parsing to be more restrictive

Just realized that this change may break existing templates :-/

One of the biggest things I've learnt from this project is that "backwards compatibility" is a surprisingly ill-defined term. Relevant xkcd comic..

Hahaha, good one!


Push image to ECS instead of Hub

This should make the initial image pull faster, if everything is inside of AWS.

Relevant example: https://github.com/opensyllabus/osp-api/blob/master/deploy.sh


Incorrect amino acid prediction for variant

The prediction (p.Arg149Ter) given for variant 19:11230785 A / T is incorrect and should be p.Thr621Thr

Hi - the gene page shows the worst annotation across all transcripts for that specific variant. In this case one of the Gencode transcripts (ENST00000559340) has a different reading frame from the others, and as a result the impact of this variant is a nonsense rather than synonymous substitution. (This transcript is likely to be spurious, but it is nonetheless a valid Gencode transcript.)
To see the functional impact of variants with respect to the canonical transcript you can select the starred transcript from the drop-down menu at the top of the page - in this case http://exac.broadinstitute.org/transcript/ENST00000558518.


Plugins crashed on import styles

Hi,
With a clean install of the plugin I try to import styles but the plugin crashes and white screens. If I uncheck the options checkbox and import styles then styles seem to be imported fine. However if I then close the plugin and reopen it then it is blank again?
I've attached 2 recording to help.
https://user-images.githubusercontent.com/1845961/112463302-fb245480-8d59-11eb-8d15-bc9a73079d10.mov
https://user-images.githubusercontent.com/1845961/112463379-1000e800-8d5a-11eb-98f1-6e67c3be2d30.mov
I hope this helps and that you can help? This has been such great work so far!
Thanks

Thanks for raising this issue @andywd7 ! Could you by any chance share the Figma file with me? So that I could reproduce it? If you could email me at<EMAIL_ADDRESS>then I could take a closer look 🙏

@six7 I've duplicated the file and shared it with you. Let me know if there are any issues 👍

Thank you! I found the root cause:
Your typography tokens have one group named .docs - the plugin uses dot notation to create groups, so it basically created an empty group and was then unable to find aliases for your values. I'll publish a fix later in the day, so the plugin will stop looking for aliases after a few retries.

Awesome thank you very much! Thankfully it was a simple thing. I can just rename that group with an underscore in the meantime 👍


central cache freelist leak?

I’m running a process for a while, and I have a problem with the memory usage, which never decrease.
The TCMalloc statistics says:
MALLOC:<PHONE_NUMBER>8 (10194.7 MiB) Bytes in use by application
MALLOC: +    284106752 (  270.9 MiB) Bytes in page heap freelist
MALLOC: +<PHONE_NUMBER> ( 2050.6 MiB) Bytes in central cache freelist
MALLOC: +      6489856 (    6.2 MiB) Bytes in transfer cache freelist
MALLOC: +     85912808 (   81.9 MiB) Bytes in thread cache freelists
MALLOC: +     56754176 (   54.1 MiB) Bytes in malloc metadata
MALLOC:   ------------
MALLOC: =<PHONE_NUMBER>2 (12658.5 MiB) Actual memory used (physical + swap)
MALLOC: +    621199360 (  592.4 MiB) Bytes released to OS (aka unmapped)
MALLOC:   ------------
MALLOC: =<PHONE_NUMBER>2 (13250.9 MiB) Virtual address space used
MALLOC:
MALLOC:         846714              Spans in use
MALLOC:            110              Thread heaps in use
MALLOC:           8192              Tcmalloc page size
Why there are so many bytes which is not release in central cache freelist ?
Any kind of help will be appreciated. Thanks in advance

(This might be a profile from https://github.com/gperftools/gperftools, since there's no mention of the per-CPU cache.)
The central freelist holds spans of multiple objects that have not been fully reassembled.  So if there's a span of memory with 8 objects, all 8 of those objects must be returned to the central freelist before the span can be deallocated to the page heap.


Towards safer migration

This PR adds a new AGAS API: hpx::agas::begin_migration and hpx::agas::end_migration. These functions make sure that no address resolution proceeds while a migration operation is in flight. All address resolution requests will be deferred until end_migration is called.
This PR also adapts the existing API functions hpx::components::migrate, hpx::components::migrate_to_storage, and hpx::components::migrate_from_storage to use the new AGAS API.
Overall, this is the first step to make the process of migrating objects transparent to the user (see #559).

While this is absolutely the step in the right direction, I don't like the proposed API:

What happens in the case of an exception between begin and end migration?
In the case of a migration to storage, isn't the end of the migration only marked when the component is migrated back into AGAS?

While this is absolutely the step in the right direction, I don't like the proposed API:

What would you suggest doing differently?

What happens in the case of an exception between begin and end migration?

The code makes sure that end_migration is always executed (even if some exception is thrown in between (see for instance here).

In the case of a migration to storage, isn't the end of the migration only marked when the
component is migrated back into AGAS?

Even if an object is migrated to storage, it still stays registered with AGAS. Otherwise we will not be able to bring it back transparently later on.

On Friday, February 20, 2015 12:37:04 Hartmut Kaiser wrote:

While this is absolutely the step in the right direction, I don't like the
proposed API:
What would you suggest doing differently?

For the 1) case i'd suggest to implement something akin to scoped_lock.

What happens in the case of an exception between begin and end
migration?
The code makes sure that end_migration is always executed (even if some
exception is thrown in between (see for instance
[here](https://github.com/STEllAR-GROUP/hpx/blob/towards_safer_migration/hp
x/runtime/components/server/migrate_component.hpp#L169)).
In the case of a migration to storage, isn't the end of the migration
only marked when the component is migrated back into AGAS?

Even if an object is migrated to storage, it still stays registered with
AGAS. Otherwise we will not be able to bring it back transparently later
on.

That's true, however, it doesn't make sense to resolve the gid as long as it
is in the storage space. This can be interpreted as that migration hasn't been
completed yet. Guess it is a semantic peculiarity of migration to some storage
that needs to be discussed.

Reply to this email directly or view it on GitHub:
https://github.com/STEllAR-GROUP/hpx/pull/1378#issuecomment-75314832

While this is absolutely the step in the right direction, I don't like the
proposed API:
. What would you suggest doing differently?

What happens in the case of an exception between begin and end
migration?
The code makes sure that end_migration is always executed (even if some
exception is thrown in between (see for instance
[here](https://github.com/STEllAR-GROUP/hpx/blob/towards_safer_migration/hp
x/runtime/components/server/migrate_component.hpp#L169)).
For the 1) case i'd suggest to implement something akin to scoped_lock.

That's exactly what has been implemented (semantically). All exceptions will go through the futures returned from the separate steps of the operation. Once one of the futures has an exception it will bubble up through all remaining continuations, which will make sure that end_migration ends up being executed. I wouldn't know how to have literal scoped_guard as the whole thing is an asynchronous operation.

In the case of a migration to storage, isn't the end of the migration
only marked when the component is migrated back into AGAS?

Even if an object is migrated to storage, it still stays registered with
AGAS. Otherwise we will not be able to bring it back transparently later
on.

That's true, however, it doesn't make sense to resolve the gid as long as it
is in the storage space. This can be interpreted as that migration hasn't been
completed yet. Guess it is a semantic peculiarity of migration to some storage
that needs to be discussed.

Sorry, I don't understand what you mean. An object which was moved to storage (or to disk) still maintains its global id and stays registered with the AGAS instance where it was initially registered. If somebody resolves this global id while the object is on disk (not in main memory), this will return the global id of the storage component (as the object's 'locality') and an invalid local virtual address.
IOW, storage components act like a special locality which puts those objects to disk which are migrated there. Migrating objects from this special locality resurrects the original object using its old global id.

Am 20.02.2015 22:32 schrieb "Hartmut Kaiser"<EMAIL_ADDRESS>

While this is absolutely the step in the right direction, I don't like
the
proposed API:
. What would you suggest doing differently?

What happens in the case of an exception between begin and end
migration?
The code makes sure that end_migration is always executed (even if some
exception is thrown in between (see for instance
here).

For the 1) case i'd suggest to implement something akin to scoped_lock.

That's exactly what has been implemented (semantically). All exceptions
will go through the futures returned from the separate steps of the
operation. Once one of the futures has an exception it will bubble up
through all remaining continuations, which will make sure that
end_migration ends up being executed. I wouldn't know how to have literal
scoped_guard as the whole thing is an asynchronous operation.

In the case of a migration to storage, isn't the end of the
migration
only marked when the component is migrated back into AGAS?

Even if an object is migrated to storage, it still stays registered with
AGAS. Otherwise we will not be able to bring it back transparently later
on.

That's true, however, it doesn't make sense to resolve the gid as long
as it
is in the storage space. This can be interpreted as that migration
hasn't been
completed yet. Guess it is a semantic peculiarity of migration to some
storage
that needs to be discussed.

Sorry, I don't understand what you mean. An object which was moved to
storage (or to disk) still maintains its global id and stays registered
with the AGAS instance where it was initially registered. If somebody
resolves this global id while the object is on disk (not in main memory),
this will return the global id of the storage component (as the object's
'locality') and an invalid local virtual address.
IOW, storage components act like a special locality which puts those
objects to disk which are migrated there. Migrating objects from this
special locality resurrects the original object using its old global id.

You can't call on action on a component that's stored away, can you? As
such, it might look like the migration is still in process (until after
migrate_from_storage) is called. That is,
begin_migration->migrate_to_storage and
migrate_from_storage->end_migration. If that wouldn't be the case, it might
be extremely difficult to transparently hide the fact that a component has
been swapped out from a user of such a component.

—
Reply to this email directly or view it on GitHub.

You can't call an action on a component that's stored away, can you? As
such, it might look like the migration is still in process (until after
migrate_from_storage) is called. That is,
begin_migration->migrate_to_storage and
migrate_from_storage->end_migration. If that wouldn't be the case, it might
be extremely difficult to transparently hide the fact that a component has
been swapped out from a user of such a component.

Currently, you can't call an action on a migrated object, that's what I said above - it would blow up. However, the plan is to transparently bring the object back if somebody invokes and action on it. For this to happen, more work is required, though. But I have the distinct feeling that I still not understand what you have in mind...

Ok, one more try:
In general, migration of a component is the process of moving that object from locality A to locality B, correct?
Now, as far as I understand, before migration starts, one calls begin_migration to mark the start of the migration process. This protects the component to be resolved incorrectly while being in transit. end_migration is then called when the component has been fully transfered (or some error occured) to locality B, correct?
In my understanding, migration to disk does not form an exception to the semantic described above. The "medium" through which the component is transfered is some storage, and possibly network. As such, begin_migration still forms the start of a migration process which is initiated with migrate_to_storage. As long as the component "lives" on the storage device, it can be seen as being "in transit". Now, whenever migrate_from_storage is called and succesfully returned, then migration process is done and end_migration should be called to mark the component as being fully migrated.
Having a special handling for the above described case sounds dangerous. How do you differentiate between program failure (naming::address being invalid and the GID accidently pointing to a component storage, yet the type of the component and the type of the storage mismatches) and an intentional call?
I hope that explains everything a little clearer.

Ok, one more try:
In general, migration of a component is the process of moving that object from locality A to
locality B, correct?

yes.

Now, as far as I understand, before migration starts, one calls begin_migration to mark the start of > the migration process. This protects the component to be resolved incorrectly while being in transit. > end_migration is then called when the component has been fully transfered (or some error
occured) to locality B, correct?
In my understanding, migration to disk does not form an exception to the semantic described above. > The "medium" through which the component is transfered is some storage, and possibly network.
As such, begin_migration still forms the start of a migration process which is initiated with
migrate_to_storage. As long as the component "lives" on the storage device, it can be seen as
being "in transit". Now, whenever migrate_from_storage is called and succesfully returned, then
migration process is done and end_migration should be called to mark the component as being
fully migrated.
Having a special handling for the above described case sounds dangerous. How do you
differentiate between program failure (naming::address being invalid and the GID accidently
pointing to a component storage, yet the type of the component and the type of the storage
mismatches) and an intentional call?
I hope that explains everything a little clearer.

Ok, that explains your point. The misunderstanding however is, that you see the process of migrating an object to storage and back as a whole as 'migration'.
The way I see it is that the storage is just another 'locality'. That means that migrating something to the storage itself comprises the migration step. Same would be true for migrating an object back from the storage locality. That means that in between the two migration operations the object 'lives' in the storage.
The goal is to have a mechanism which transparently blurs the boundary between in-core and out-of-core memory, where objects are brought back to life transparently once needed.

Can we merge this now?

On Friday, February 20, 2015 15:17:58 Hartmut Kaiser wrote:

Ok, one more try:
In general, migration of a component is the process of moving that object
from locality A to>
locality B, correct?

yes.

Now, as far as I understand, before migration starts, one calls
begin_migration to mark the start of > the migration process. This
protects the component to be resolved incorrectly while being in transit.

end_migration is then called when the component has been fully
transfered (or some error occured) to locality B, correct?

In my understanding, migration to disk does not form an exception to the
semantic described above. > The "medium" through which the component is
transfered is some storage, and possibly network. As such,
begin_migration still forms the start of a migration process which is
initiated with migrate_to_storage. As long as the component "lives" on
the storage device, it can be seen as being "in transit". Now, whenever
migrate_from_storage is called and succesfully returned, then migration
process is done and end_migration should be called to mark the
component as being fully migrated.
Having a special handling for the above described case sounds dangerous.
How do you differentiate between program failure (naming::address being
invalid and the GID accidently pointing to a component storage, yet the
type of the component and the type of the storage mismatches) and an
intentional call?
I hope that explains everything a little clearer.

Ok, that explains your point. The misunderstanding however is, that you see
the process of migrating an object to storage and back as a whole as
'migration'.

Quite some misunderstanding indeed. I made all those implications from reading
through the code. The only thing that didn't add up was the strange (IMHO)
semantics imposed by the way begin_migration and end_migration is called.
The primary use case I see in this migrate_to_storage is for micro
checkpointing or any other case where you don't immediately need the
components data again, for example swapping if you run out of main memory.

The way I see it is that the storage is just another 'locality'. That means
that migrating something to the storage itself comprises the migration
step. Same would be true for migrating an object back from the storage
locality. That means that in between the two migration operations the
object 'lives' in the storage.

I don't think the current implementation is suitable for that kind of
migration. There are far more efficient solutions to that that don't require to
completely swap the data out of the processes address space. That is such a
facility should come with some kind of allocation policy that takes care of
constructing the component in the appropriate place (different NUMA domain,
file, etc.), see for example memkind or memory mapped files. If there really is
a scenario where you don't have direct access to the memory region, one could
hide that through a "smart pointer" which marshals the data back and forth
with special attention to concurrent accesses (for example only serialize the
data once, this could be done by reference counting). By having such a
allocation policy which constructs the component appropriately instead of
storing it away and mark it as invalid, the order in which begin_migration
and end_migration is called makes sense again.

The goal is to have a mechanism which transparently blurs the boundary
between in-core and out-of-core memory, where objects are brought back to
life transparently once needed.

Why do they need to be not alive in the first place? By having them "not really
alive" it gets hard to argue which components are alive and which are not.
Additionally, this transparent layer is currently missing completely and it is
very hard for me to imagine how this might work, despite of adding a lot of
complexity and imposing artificial overheads to something that is, IMHO, not
needed for this particular use case. For a matter of fact, we already use in-
core memory (L1-Cache, L2-Cache, registers) and out-of-core memory (last level
cache, main memory) transparently already, which can be easily extended to any
other kind of memory (files, memory on dedicated accelerators, etc.). Why not
use the same mechanisms that are already available, instead of inventing yet
another layer of complexity?

@sithhell: Sorry, but I don't think the issues you're raising have any relation to the PR at hands. This PR is introducing 2 additional safeguards necessary to make migration more transparent in use (any kind of migration, even that which we already have for over a year).
I also think I have not been able to properly explain the migrate_to_storage and migrate_from_storage functionalities. Both are btw completely independent of HPX itself, they are implemented as a component, which could be easily separated from the core library.
The migrate_to_storage and migrate_from_storage functionalities are meant to test out the infrastructure needed to truly put objects to disk (or any other non-volatile memory like NVRAM, SDRAM, etc.). Those objects would maintain their global ids while being stored on disk, even beyond the lifetime of the application they were created by. In the end, AGAS itself could be put to disk this way. We need this functionality for one of our projects where we look into integration of HPX with parallel file systems in the context of some DNA sequencing application.

On 02/25/2015 05:20 AM, Hartmut Kaiser wrote:

@sithhell https://github.com/sithhell: Sorry, but I don't think the
issues you're raising have any relation to the PR at hands. This PR is
introducing 2 additional safeguards necessary to make migration more
transparent in use (any kind of migration, even that which we already
have for over a year).

Right, this PR adds the safe guard and implements the safe guard for the
migration facilities we already have: migration between localities and
migration to/from storage. It's the implementation of the migration
to/from storage (part of this PR) that I disagree with.

I also think I have not been able to properly explain the
|migrate_to_storage| and |migrate_from_storage| functionalities. Both
are btw completely independent of HPX itself, they are implemented as a
component, which could be easily separated from the core library.
The |migrate_to_storage| and |migrate_from_storage| functionalities are
meant to test out the infrastructure needed to truly put objects to disk
(or any other non-volatile memory like NVRAM, SDRAM, etc.). Those
objects would maintain their global ids while being stored on disk, even
beyond the lifetime of the application they were created by. In the end,
AGAS itself could be put to disk this way. We need this functionality
for one of our projects where we look into integration of HPX with
parallel file systems in the context of some DNA sequencing application.

Ok, let's recap how the safeguard works and what it should protect from:

It implements a facility that prevents a GID from being resolved
while it is being migrated
begin_migration marks the start of a migration process, it's a
asynchronous functions. After the future
returned by this function is returned, it's safe to start the
migration process.
end_migration is the counter part. After that function returns,
the migration process should have been
finished, and it is safe to resolve that GID again.
Any resolve request that happened between begin_migration and
end_migration is being suspended and continues
to be executed after end_migration has been finished.

I hope I got those points correct. The implications I derive from this
semantics are that hpx::agas::resolve will always return a valid
hpx::naming::address. Anything else doesn't make sense to me.
Now here comes the, IMHO, problematic part: Those derived semantics are
broken with how this safeguard is implemented for migrate_to_storage.
After migrate_to_storage returns, the migration is being marked as
being "done", that is hpx::agas::resolve would return some nonsensical
address.
This is in contradiction to the implementation: The migrated component
is archived away to some storage location (which can be main memory,
disk, or any other non-volatile memory) and is therefor not alive, as
such, the migration process has not been finished.
The rationale you brought up for having this difference in semantics is
to still be able to use the component as it where still alive (this
functionality is clearly missing). I think persistent archiving of
components and the ability to use components stored in different
locations is sufficiently different such that they deserve a separation
of concerns. As explained in my previous mail, this scenario doesn't
even necessarily need serialization to begin with. If it turns out to
need it though, there shouldn't be a problem to implement that on top of
the existing migration_to_storage' and 'migration_from_storage' facilities. In either case, the reason why I am reluctant to agree to merge this PR  is that neither of the use cases described here are sufficiently handled  and the change in semantics with respect to what hpx::agas::resolve`
returns is, IMHO, very troublesome.

Ok, let's recap how the safeguard works and what it should protect from:

It implements a facility that prevents a GID from being resolved
while it is being migrated
begin_migration marks the start of a migration process, it's a
asynchronous functions. After the future
returned by this function is returned, it's safe to start the
migration process.
end_migration is the counter part. After that function returns,
the migration process should have been
finished, and it is safe to resolve that GID again.
Any resolve request that happened between begin_migration and
end_migration is being suspended and continues
to be executed after end_migration has been finished.

All of this is correct.

Those derived semantics are
broken with how this safeguard is implemented for migrate_to_storage.
After migrate_to_storage returns, the migration is being marked as
being "done", that is hpx::agas::resolve would return some nonsensical
address.

Ok, I see your point. I will make sure that any object in storage is transparently brought back when accessed. This PR however is all about the two safeguarding mechanisms, not about the migration to storage. I take it that you have no objections to the safeguarding code as it is.

As explained in my previous mail, this scenario doesn't
even necessarily need serialization to begin with

FWIW, you always have to serialize an object in order to put it to disk.

FWIW, you always have to serialize an object in order to put it to disk.

That's not entirely true. One could imagine an allocator that uses a memory mapped file to store the necessary data (similar to boost::interprocess::allocator). This of course requires that all members of said component are either not heap allocated or support an allocator. Allocators using pointers into non-volatile memory can be thought of as well. Nevertheless, this is completely orthogonal to this PR, but is IMHO important for further considerations on how to proceed for migrating components to different storage locations.

Ok, I see your point. I will make sure that any object in storage is transparently brought back when accessed. This PR however is all about the two safeguarding mechanisms, not about the migration to storage. I take it that you have no objections to the safeguarding code as it is.

No objection to the general safe guarding mechanism. The only objection is the way it is used for migrate_to_storage and migrate_from_storage which is also part of this PR. Before merging this PR I would like to have some form of consensus about how to proceed on that issue, either by filing a separate issue or by fixing the issues in question within that PR prior to the merge.

[Feb 25th, 08:17]	heller: hkaiser: gtg now ... I'm fine with merging the PR ... but please create issue that explains what needs to be done so that migrate_to_storage/migrate_from_storage works again as expected


remove opscode-chef-mover service

This has not been used in migrations since prior to 12.17.15,
which is the earliest version we support upgrading from.
I have based this off of branch mp/remove-unsupported-upgrades since it removes the upgrades that reference mover.
Signed-off-by: Marc A. Paradise<EMAIL_ADDRESS>

There are some minor cookstyle fixes required, but looks good other than that.

Updated for cookstyle, and waiting for umbrella pipeline's final verdict.

https://buildkite.com/chef/chef-chef-server-main-omnibus-adhoc/builds/4236


Add support to toggle Sampler bean configuration

We had to do this:
  @Bean
  @ConditionalOnMissingBean
  // This override is required because the default sampler that comes with OtelAutoConfiguration is
  // TraceIdRatioBased. In our case the API gateway is going to make the decision whether to sample
  // a request or not, and all downstream services will simply propagate the sampling flag in the context
  // that they receive.
  Sampler otelSampler() {
    return Sampler.parentBased(Sampler.alwaysOff());
  }

It would be convenient to be able to toggle the Sampler bean by configuration, perhaps with a list of options like "default" and "always-honor-parent", etc.

We don't mind overriding beans--that's normal in Spring. But some of the beans in auto-configure are pretty involved, and overriding those creates a double-maintenance problem. (Sampler isn't complicated.)

We're not planning on making everything configurable via properties. You can create your own starter that your apps can use with your custom setup.


dump shaders in game folder

I tried use your add-on for remove color filter and vignette in Resident Evil 2 Remake but turn game overbright too. I need manual editing hand editing shaders and dont have tools for do this in DX12 games. Only your mod closer to that in years.

My camera mod removes the vignette, which doesn't make it overly bright (by disabling it in the engine) so it must be the color filter which does that. Dumping shaders is a lot of work (and doesn't always work as well), so that's not in the scope of this addon, sorry


[TVMC] Fix error while compile paddle model with tvmc

The tvmc command will throw a error while the passed path of model is not exist,  But for PaddlePaddle model, it contains 2 file model_name.pdmodel and model_name.pdiparams, we only pass the prefix like inference_model/model_name.
@leandron
Thanks for contributing to TVM!   Please refer to guideline https://tvm.apache.org/docs/contribute/ for useful information and tips. After the pull request is submitted, please request code reviews from Reviewers by @ them in the pull request thread.
cc @gromero

@jiangjiajun Hi. Thanks for reporting this issue and for the fix.
I think paddle import kind violates the expectation that FILE is always a file on tvmc compile...
@jiangjiajun @leandron My preference for consistence here is to keep FILE argument being passed to tvmc compile as only a file  (not a directory). In this case we would need to change the current behavior to load a paddle model passing a model_name.pmodel file, for example:
$ tvmc compile --target "llvm" ~/scripts/picodet_PPLCNet_x2_5_mainbody_lite_v1.0_infer/inference.pdmodel
instead of a directory as we do currently. Then it would be necessary to change class PaddleFrontend, load() method to use maybe os.path.splitext() to acquire the "Directory path to save model + model name without suffix" expected by Paddle's load_inference_model.
This would also have the benefit that the model format could now be guessed for Paddle as well.  ( @jiangjiajun I think that before this issue one needed to pass explicitly the model format  for Paddle models (i.e. --model-format paddle) since although we have suffixes() properly in place for Paddle there is no way guess_frontend() can use it when FILE is in the inference_model/model_name form?)
Finally, we need a test case for compiling a simple paddle model to avoid such kind of regressions (to be submitted with this PR also).
@jiangjiajun @leandron WDYT?

@jiangjiajun @leandron WDYT?

I agree with @gromero, that we can use the path to a provided *.pdmodel to infer the path to the other required files. Does that seem feasible @jiangjiajun?

@gromero @leandron I have no problem. Could you provide an example of  test case for other tvmc frontend, I will update in this PR

@gromero @leandron I have no problem. Could you provide an example of test case for other tvmc frontend, I will update in this PR

@jiangjiajun So, since I understand we need to test the code path between tvmc' s main() (in main.py) and compile_model() (in compiler.py), which includes exercising any logic/check to validate the args attributes passed to fronends.load_model() plus the load method itself (i.e. it's a command line test), I suggest something like:
diff --git a/tests/python/driver/tvmc/test_command_line.py b/tests/python/driver/tvmc/test_command_line.py
index 5b15492aa..1d9180fed 100644
--- a/tests/python/driver/tvmc/test_command_line.py
+++ b/tests/python/driver/tvmc/test_command_line.py
@@ -20,9 +20,11 @@ import pytest
 import shutil

 from pytest_lazyfixture import lazy_fixture
+from unittest import mock
+
 from tvm.driver.tvmc.main import _main
 from tvm.driver.tvmc.model import TVMCException
-
+from tvm.driver.tvmc import compiler

 @pytest.mark.skipif(
     platform.machine() == "aarch64",
@@ -155,3 +157,25 @@ def test_tvmc_tune_file_check(capsys, invalid_input):
     )
     on_assert_error = f"'tvmc tune' failed to check invalid FILE: {invalid_input}"
     assert captured.err == expected_err, on_assert_error
+
<EMAIL_ADDRESS>+def paddle_model(paddle_resnet50):
+    # If we can't import "paddle" module, skip testing paddle
+    if pytest.importorskip("paddle", reason="'paddle' module not installed"):
+        return paddle_resnet50
+
+@pytest.mark.parametrize("model", [lazy_fixture("paddle_model"), ])
+# compile_model() can take too long and is tested elsewhere, hence it's mocked below
+@mock.patch.object(compiler, "compile_model")
+def test_tvmc_compile_input_model(mock_compile_model, tmpdir_factory, model):
+
+    output_dir = tmpdir_factory.mktemp("output")
+    output_file = output_dir / "model.tar"
+
+    compile_cmd =  f"tvmc compile --target 'llvm' {model} --model-format paddle --output {output_file}"
+    run_arg = compile_cmd.split(" ")[1:]
+
+    _main(run_arg)
+
+    mock_compile_model.assert_called_once()

This way we could also easily extend  test_tvmc_compile_input_model  to test other input formats. For instance, a tflite model, by adding:
diff --git a/tests/python/driver/tvmc/test_command_line.py b/tests/python/driver/tvmc/test_command_line.py
index 505faea65..8e4a116b4 100644
--- a/tests/python/driver/tvmc/test_command_line.py
+++ b/tests/python/driver/tvmc/test_command_line.py
@@ -164,7 +164,14 @@ def paddle_model(paddle_resnet50):
     if pytest.importorskip("paddle", reason="'paddle' module not installed"):
         return paddle_resnet50

-@pytest.mark.parametrize("model", [lazy_fixture("paddle_model"), ])
+
<EMAIL_ADDRESS>+def tflite_model(tflite_mobilenet_v1_1_quant):
+    if pytest.importorskip("tflite", reason="'tflite' module not installed"):
+        return tflite_mobilenet_v1_1_quant
+
+
+@pytest.mark.parametrize("model", [lazy_fixture("paddle_model"), lazy_fixture("tflite_model"), ])
 # compile_model() can take too long and is tested elsewhere, hence it's mocked below
 @mock.patch.object(compiler, "compile_model")
 # @mock.patch.object(compiler, "compile_model")

I've also used mock() for compile_model() because it takes too long and it's also tested elsewhere.
Also compile_cmd in the test won't have --model-format paddle after the fix in the sense we've discussed, so it would work for other formats too.
Note I've mentioned the tflite format just as an example on how to extend the test in the future, it's out of scope for the PR.
You probably know it already, but just in case, you can use pytest -k flags to select only that test to run, for example:
$ pytest -k test_tvmc_compile_input_model -vvvv ./test_command_line.py
[02:37:03] /home/gromero/git/tvm/src/target/target_kind.cc:163: Warning: Unable to detect CUDA version, default to "-arch=sm_20" instead
enabled targets: llvm
pytest marker:
==================================================================================== test session starts =====================================================================================
platform linux -- Python 3.9.5, pytest-6.2.4, py-1.10.0, pluggy-0.13.1 -- /usr/bin/python3
cachedir: .pytest_cache
rootdir: /home/gromero/git/tvm/tests/python/driver/tvmc
plugins: lazy-fixture-0.6.3
collected 10 items / 8 deselected / 2 selected

test_command_line.py::test_tvmc_compile_input_model[paddle_model] PASSED                                                                                [ 50%]
test_command_line.py::test_tvmc_compile_input_model[tflite_model] SKIPPED ('tflite' module not installed)                                                                              [100%]

========================================================================= 1 passed, 1 skipped, 8 deselected in 1.67s =========================================================================

Feel free to adapt it or use your own test version.
HTH.

@jiangjiajun Hi. Let me know if you need any help with the test or with the fix itself.

@gromero Sorry, I'm supporting new project in Paddle team these days, I saw you commit a code for the command line, I'll check it and update this pull request next week.

@gromero I have updated the code, could you help to review this PR? Also there's a strange error happened in ci, is it caused by this PR? I have tested in my environment without any failing.

@leandron @gromero Hi, is there any problem? I think this pull request is ready to merge

Sorry I forgot to review this one again. I have only one comment in there. Once that is fixed, I'm happy for this PR to be merged.

@leandron  Fixed. But the ci failed again, I have no idea why this error happened, is it caused by this pull request? https://ci.tlcpack.ai/blue/organizations/jenkins/tvm/detail/PR-11108/10/pipeline

HI, after I remove the tflite test from command line, the pull request passed the ci.
Since this pull request is to provide a command line testing for paddle frontend, I remove the unrelated code.
Could you help to review and merge this PR? @gromero @leandron

@gromero Hi Gromero, we may need this to be fixed in time so hope to get your support to review it! Thank you so much for the great support!

I have only one comment in there. Once that is fixed, I'm happy for this PR to be merged.

Looks like this thread has been inactive for a month, while according to the conversation above, the PR itself has been mature enough to merge. To this end, to quickly unblock our open-source contributors, I would love to propose that we create a new PR based on the latest HEAD, and get it merged as soon as we could.


[feature] Fade Effect

Steps to implement this:

Find a code hook that is placed right behind the rendering of the ingame GUI (hand & HUD).
Take the original fade-code from here: https://github.com/tiffit/TaleCraft/blob/master/src/main/java/de/longor/talecraft/client/ClientRenderer.java#L493 and ...
...implement it at the hook from step 1.
Add a /tc_fade-command and a network packet to handle fade effects.
Make sure that the fade effect does NOT affect the normal GUI rendering.
Make sure that the fade effect does not last for more than ~5 seconds.
(Optional) Make it possible to use a textured instead of a plain colored fade.

Done.


Support for 10x HDF5 input data; Input data validation and sanitation

@fedorgrab while you're at it, please update README for different use cases (10x HDF5 file, AnnData file, loaded AnnData object).


Inconsistent naming of stubs

Not a big issue, but it might be a good idea to be consistent about using (or not using) the -stubs prefix for stubs in source code.
Unless there's an odd reason with Pylance integration I'm not aware of.

one with -stubs is, I believe, a partial stub packages (https://peps.python.org/pep-0561/#partial-stub-packages). we can make full stub packages as -stubs as well, I believe for now, we kind of use -stubs to distinguish what packages are partial or not.


Make the pretrained model available

Hi, I would like to try out your pretrained models, it has been a while after sending a request for downloading the models. Why don't you simply make them accessible to everyone? Or you would like to know who is using the models?

Thanks for pointing out. It was accessible to everyone at Google Drive, but I just realized that my university's Google account was inactivated because I graduated last March. I'm reaching out to my former laboratory to get it re-uploaded somewhere else, so could you please wait for several more days?

I updated README. Does this link work?
https://drive.google.com/file/d/1LwE2BzvtDaPGYv0OR6iBjmsqoloH885N/view?usp=sharing

Thanks a lot, the link worked. I have downloaded it.


Emitting or deriving trait implementations

Let's implement all the traits!!
All of the "Derive Blah when possible" issues have code in tree already that they can crib from, so shouldn't be too difficult to write.
Once we start deriving  lots of different traits, I expect we may find that we can unify their implementations, or at least make a generic CanDeriveTrait<T: DerivableTrait> kind of generic thing.

[x] "manually" implement Debug when we cannot derive it: https://github.com/rust-lang-nursery/rust-bindgen/issues/875

[x] Derive Hash when possible: https://github.com/rust-lang-nursery/rust-bindgen/issues/876

[ ] "manually" implement Hash when we cannot derive it: https://github.com/rust-lang-nursery/rust-bindgen/issues/877

[x] Derive PartialEq when possible: https://github.com/rust-lang-nursery/rust-bindgen/issues/878

[ ] "manually" implement PartialEq when we cannot derive it: https://github.com/rust-lang-nursery/rust-bindgen/issues/879

[x] Derive Eq when possible: https://github.com/rust-lang-nursery/rust-bindgen/issues/880

[ ] "manually" implement Eq when we cannot derive it: https://github.com/rust-lang-nursery/rust-bindgen/issues/881

[ ] Derive PartialOrd when possible: https://github.com/rust-lang-nursery/rust-bindgen/issues/882

[ ] "manually" implement PartialOrd when we cannot derive it: https://github.com/rust-lang-nursery/rust-bindgen/issues/883

[ ] Derive Ord when possible: https://github.com/rust-lang-nursery/rust-bindgen/issues/884

[ ] "manually" implement Ord when we cannot derive it: https://github.com/rust-lang-nursery/rust-bindgen/issues/885

Should Copy be included in this meta-issue (as discussed in #934)?  It would be a real odd-man-out if not.

Should Copy be included in this meta-issue (as discussed in #934)? It would be a real odd-man-out if not.

We already derive/impl Clone and Copy when possible, it's just that there's that caveat discussed in #934. This meta issue is for tracking traits we don't derive/impl yet.

@fitzgen derive Hash is implemented. But miss the mark there.

@fitzgen derive Hash(#876) is implemented. But miss the mark there.

Fixed, thanks!

We already derive/impl Clone and Copy when possible, it's just that there's that caveat discussed in #934. This meta issue is for tracking traits we don't derive/impl yet.

My point is that #934 says that WIBNI to derive Copy where possible and (only) otherwise manually implement it; and that this issue says pretty much the same thing for every other trait.  In particular, bindgen often does not derive Copy when it would have been possible to do so.
But I don't suppose it really matters!  Tracking that in one place is certainly enough; I was just trying to tie some loose ends together.


MockGraphics.getFramesPerSecond should return fps

Issue details

MockGraphics.getFramesPerSecond always returns 0 even though fps is calculated correctly

Reproduction steps/code

Create a HeadlessApplication
Run it
call Gdx.graphics.getFramesPerSecond()
Expected result: current fps
Actual result: 0

Version of LibGDX and/or relevant dependencies
gdxVersion: 1.9.9 (but I checked the latest sources)
Stacktrace
N/A
Please select the affected platforms

Headless

If you created a pull request close this.

Please close as your PR has been accepted.


[Wikipedia] Match and Missing counts are incorrect

When searching 5000 articles, a Missings count of 9000 was returned. This is impossible. There should only be one Missing["NoMatchFound"] per article without matches.
A similar issue occurred for match counts, where the count given was effectively the number of articles a match appeared in, not the number of occurrences of the word.

Fixed locally, among other slight changes which seem to have slowed down article collection, but not worried about it.


Link to "Microsoft Azure Projects Contribution Guidelines" results in 404 redirect.

Describe the bug
https://github.com/Azure/azure-sdk-for-c/blob/master/CONTRIBUTING.md, Line 38. Link is broken.
Exception or Stack Trace
Add the exception log and stack trace if available
To Reproduce
Steps to reproduce the behavior: Click on the link.
Code Snippet
Add the code snippet that causes the issue.
Expected behavior
Link directs to an actual guidelines page.
Screenshots
If applicable, add screenshots to help explain your problem.
Setup (please complete the following information):

OS: [e.g. iOS]
IDE: [e.g. IntelliJ]
Version of the Library used

Additional context
Add any other context about the problem here.
Information Checklist
Please make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[ ] Bug Description Added
[ ] Repro Steps Added
[ ] Setup information Added

@ahsonkhan this is an interesting broken link scenario. I'm not sure we can easily detect it with our link verification script unless we start following all different types of redirects, however I've filed an issue https://github.com/Azure/azure-sdk-tools/issues/910 to investigate.

Same here: https://github.com/Azure/azure-libraries-for-net/issues/1201

Same here: https://github.com/Azure/azure-libraries-for-net/issues/1201


Latest ionic 5 design updates do not work with stencil/vanilla JS apps

Stencil version:

<EMAIL_ADDRESS>
I'm submitting a:

[x] bug report
[ ] feature request
[ ] support request => Please do not submit support requests here, use one of these channels: https://stencil-worldwide.herokuapp.com/ or https://forum.ionicframework.com/
Current behavior:

Latest design update for iOS do not appear the same way in stencil/vanilla JS apps as they do for angular apps. For example larget titles and swipe to close modals etc.
Expected behavior:

The latest design/feature updates work for a stencil/vanilla JS app.
Steps to reproduce:

Create a stencil app and install the latest @ionic/core and then make a sample component with a large title. Run the app in chrome and use the developer tools to fake an iOS device.
Related code:
            <ion-header collapse="condense">
                <ion-toolbar>
                    <ion-title size="large">Profile</ion-title>
                </ion-toolbar>
            </ion-header>

Other information:

https://ionicframework.com/blog/announcing-ionic-5/

Thanks for the issue. Can you provide a repo with the code required to reproduce this issue? I am unable to reproduce the issue using the code snippet provided.

@liamdebeasi Use the ionic stencil conference app repo. This is a stenciljs/ionic app issue not an angular/ionic app issue. It's not reproducible in an angular project. That is the point I am making.  https://github.com/ionic-team/ionic-stencil-conference-app use that repo and upgrade the ionic core package.

Thanks for the follow up. I am unable to reproduce this issue using the Ionic Stencil Conference App. Can you please provide a repo with the code required to reproduce this issue?

The code provided in the original issue is displaying an accurate toolbar, but it looks like you may be missing the header that goes on top of the content. The Stencil conference app hasn't been updated to Ionic 5 yet, so the usage in that app does not reflect the proper large title usage.
Please verify that you are following the usage examples here, notice that there are two ion-header elements: https://ionicframework.com/docs/api/title#collapsible-large-titles
If this doesn't solve the problem please provide more code or a repo as Liam requested, thank you!


fix(vera): Update vera to sync rod height and track in-use materials

:tada: This PR is included in version 2.2.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Return callback from RTMClient.run_on

Summary
Returns the callback passed into RTMClient.run_on so that it can be called elsewhere. For example:
@RTMClient.run_on("message")
def magic(**payload):
  print('🔮')

magic()
# before PR -> errors because `magic` is `None`
# after PR  -> prints 🔮

Fixes #485.

Requirements

[x] I've read and understood the Contributing Guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.

This seems like a useful change also for chaining multiple similar events to the same callback:
@RTMClient.run_on(event="group_deleted")
@RTMClient.run_on(event="channel_deleted")
def channel_deleted(**payload):
    pass

Will currently attach channel_deleted to  RTMClient._callbacks["channel_deleted"] but then raise
SlackClientError: The specified callback 'None' is not callable.

But with this patchset would hook up the method to both events.

Thanks a lot for this work @clavin as well as for the review @onlined & @tgerdes!


[Feature] Any plan to support StarCoder?

Motivation
Any plan to support StarCoder?
Related resources
No response
Additional context
No response

PR #1468


Likely this will be rationalised later once we understand what makes a vNext project.
Changes

Added BuildAndDeploy folder and assets
Added Build Attributes
Added Utilities editor functions and some MRDL editor base

TODO
Once stable, rationalisation of the build tools and editor base

@SimonDarksideJ which  version of the build tools is this?

This is using the Build Tools from Master, which included most of the dev fixes as far as I'm aware @StephenHodgson

@SimonDarksideJ I'd like to do the PR for the Build tools.
@davidkline-ms any word back about the async utilities license?

I can push this to it's own branch for now, so you can re-work it if you like.
or just update once merged

Redacted post Shiproom


added new setMontiors and setMonitors2 methods to MCMC configuration objects

The title says it all

Testing passed.  Merging this in.