package dependency error, extract-msg package

Hello! Thanks for your great work!
I have already install chatgpt-wrapper by using these commends:
git clone https://github.com/mmabrouk/chatgpt-wrapper.git
cd chatgpt-wrapper
pip install -e .
and this is my pip list:
ai21                    1.1.4
aiohttp                 3.8.4
aiosignal               1.3.1
alembic                 1.11.1
ansible                 8.0.0
ansible-core            2.15.0
argcomplete             1.10.3
async-timeout           4.0.2
attrs                   23.1.0
backoff                 2.2.1
beautifulsoup4          4.8.2
blinker                 1.6.2
certifi                 2023.5.7
cffi                    1.15.1
chardet                 3.0.4
charset-normalizer      3.1.0
chatGPT                 0.12.2      d:\3d\unitychatgpt-master\service\chatgpt-wrapper
click                   8.1.3
cohere                  4.11.2
colorama                0.4.6
compressed-rtf          1.0.6
cryptography            41.0.1
dataclasses-json        0.5.8
dnspython               2.3.0
docx2txt                0.8
ebcdic                  1.1.1
email-validator         2.0.0.post2
et-xmlfile              1.1.0
extract-msg             0.28.7
filelock                3.12.2
Flask                   2.3.2
frozenlist              1.3.3
fsspec                  2023.6.0
greenlet                2.0.2
huggingface-hub         0.15.1
idna                    3.4
IMAPClient              2.1.0
importlib-metadata      6.6.0
importlib-resources     5.0.7
itsdangerous            2.1.2
Jinja2                  3.1.2
langchain               0.0.199
langchainplus-sdk       0.0.10
lxml                    4.9.2
Mako                    1.2.4
markdown-it-py          3.0.0
MarkupSafe              2.1.3
marshmallow             3.19.0
marshmallow-enum        1.5.1
mdurl                   0.1.2
multidict               6.0.4
mypy-extensions         1.0.0
names                   0.3.0
numexpr                 2.8.4
numpy                   1.24.3
olefile                 0.46
openai                  0.27.8
openapi-schema-pydantic 1.2.4
openpyxl                3.1.2
packaging               23.1
pdfminer.six            20191110
Pillow                  9.5.0
pip                     23.1.2
playwright              1.35.0
prompt-toolkit          3.0.38
pycparser               2.21
pycryptodome            3.18.0
pydantic                1.10.9
pydantic-computed       0.2.2
pyee                    9.0.4
Pygments                2.15.1
pyperclip               1.8.2
pyreadline3             3.4.1
python-frontmatter      1.0.0
python-pptx             0.6.21
PyYAML                  6.0
regex                   2023.6.3
requests                2.31.0
resolvelib              1.0.1
rich                    13.4.2
setuptools              67.8.0
six                     1.12.0
sortedcontainers        2.4.0
soupsieve               2.4.1
SpeechRecognition       3.8.1
SQLAlchemy              2.0.0
tenacity                8.2.2
textract                1.6.5
tiktoken                0.4.0
tqdm                    4.65.0
typing_extensions       4.6.3
typing-inspect          0.9.0
tzdata                  2023.3
tzlocal                 5.0.1
urllib3                 2.0.3
wcwidth                 0.2.6
Werkzeug                2.3.6
wheel                   0.38.4
xlrd                    1.2.0
XlsxWriter              3.1.2
yarl                    1.9.2
zipp                    3.15.0
However, when I inpur chatgpt  in the prompt, it shows:
C:\ProgramData\Anaconda3\lib\site-packages\requests_init_.py:104: RequestsDependencyWarning: urllib3 (1.26.15) or chardet (2.3.0)/charset_normalizer (2.0.12) doesn't match a supported version!
RequestsDependencyWarning)
(chatgpt) D:\3D\UnityChatGPT-master\Service>pip install -r requirements.txt
Ignoring readline: markers 'platform_system != "Windows"' don't match your environment
Requirement already satisfied: flask in c:\programdata\anaconda3\envs\chatgpt\lib\site-packages (from -r requirements.txt (line 1)) (2.3.2)
Requirement already satisfied: playwright in c:\programdata\anaconda3\envs\chatgpt\lib\site-packages (from -r requirements.txt (line 2)) (1.35.0)
Requirement already satisfied: pyreadline3 in c:\programdata\anaconda3\envs\chatgpt\lib\site-packages (from -r requirements.txt (line 4)) (3.4.1)
Requirement already satisfied: rich in c:\programdata\anaconda3\envs\chatgpt\lib\site-packages (from -r requirements.txt (line 5)) (13.4.2)
Requirement already satisfied: Werkzeug>=2.3.3 in c:\programdata\anaconda3\envs\chatgpt\lib\site-packages (from flask->-r requirements.txt (line 1)) (2.3.6)
Requirement already satisfied: Jinja2>=3.1.2 in c:\programdata\anaconda3\envs\chatgpt\lib\site-packages (from flask->-r requirements.txt (line 1)) (3.1.2)
Requirement already satisfied: itsdangerous>=2.1.2 in c:\programdata\anaconda3\envs\chatgpt\lib\site-packages (from flask->-r requirements.txt (line 1)) (2.1.2)
Requirement already satisfied: click>=8.1.3 in c:\programdata\anaconda3\envs\chatgpt\lib\site-packages (from flask->-r requirements.txt (line 1)) (8.1.3)
Requirement already satisfied: blinker>=1.6.2 in c:\programdata\anaconda3\envs\chatgpt\lib\site-packages (from flask->-r requirements.txt (line 1)) (1.6.2)
Requirement already satisfied: importlib-metadata>=3.6.0 in c:\programdata\anaconda3\envs\chatgpt\lib\site-packages (from flask->-r requirements.txt (line 1)) (6.6.0)
Requirement already satisfied: greenlet==2.0.2 in c:\programdata\anaconda3\envs\chatgpt\lib\site-packages (from playwright->-r requirements.txt (line 2)) (2.0.2)
Requirement already satisfied: pyee==9.0.4 in c:\programdata\anaconda3\envs\chatgpt\lib\site-packages (from playwright->-r requirements.txt (line 2)) (9.0.4)
Requirement already satisfied: typing-extensions in c:\programdata\anaconda3\envs\chatgpt\lib\site-packages (from pyee==9.0.4->playwright->-r requirements.txt (line 2)) (4.6.3)
Requirement already satisfied: markdown-it-py>=2.2.0 in c:\programdata\anaconda3\envs\chatgpt\lib\site-packages (from rich->-r requirements.txt (line 5)) (3.0.0)
Requirement already satisfied: pygments<3.0.0,>=2.13.0 in c:\programdata\anaconda3\envs\chatgpt\lib\site-packages (from rich->-r requirements.txt (line 5)) (2.15.1)
Requirement already satisfied: colorama in c:\programdata\anaconda3\envs\chatgpt\lib\site-packages (from click>=8.1.3->flask->-r requirements.txt (line 1)) (0.4.6)
Requirement already satisfied: zipp>=0.5 in c:\programdata\anaconda3\envs\chatgpt\lib\site-packages (from importlib-metadata>=3.6.0->flask->-r requirements.txt (line 1)) (3.15.0)
Requirement already satisfied: MarkupSafe>=2.0 in c:\programdata\anaconda3\envs\chatgpt\lib\site-packages (from Jinja2>=3.1.2->flask->-r requirements.txt (line 1)) (2.1.3)
Requirement already satisfied: mdurl~=0.1 in c:\programdata\anaconda3\envs\chatgpt\lib\site-packages (from markdown-it-py>=2.2.0->rich->-r requirements.txt (line 5)) (0.1.2)
(chatgpt) D:\3D\UnityChatGPT-master\Service>python chatgpt_service.py
Traceback (most recent call last):
File "D:\3D\UnityChatGPT-master\Service\chatgpt_service.py", line 1, in
from chatgpt_wrapper import ChatGPT
ModuleNotFoundError: No module named 'chatgpt_wrapper'
(chatgpt) D:\3D\UnityChatGPT-master\Service>chatgpt
Traceback (most recent call last):
File "C:\ProgramData\Anaconda3\envs\chatgpt\lib\site-packages\pkg_resources_init_.py", line 3108, in _dep_map
return self._dep_map
File "C:\ProgramData\Anaconda3\envs\chatgpt\lib\site-packages\pkg_resources_init.py", line 2901, in getattr
raise AttributeError(attr)
AttributeError: _DistInfoDistribution__dep_map
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\ProgramData\Anaconda3\envs\chatgpt\lib\site-packages\pkg_resources_vendor\packaging\requirements.py", line 35, in init
parsed = parse_requirement(requirement_string)
File "C:\ProgramData\Anaconda3\envs\chatgpt\lib\site-packages\pkg_resources_vendor\packaging_parser.py", line 64, in parse_requirement
return _parse_requirement(Tokenizer(source, rules=DEFAULT_RULES))
File "C:\ProgramData\Anaconda3\envs\chatgpt\lib\site-packages\pkg_resources_vendor\packaging_parser.py", line 82, in _parse_requirement
url, specifier, marker = _parse_requirement_details(tokenizer)
File "C:\ProgramData\Anaconda3\envs\chatgpt\lib\site-packages\pkg_resources_vendor\packaging_parser.py", line 120, in _parse_requirement_details
specifier = _parse_specifier(tokenizer)
File "C:\ProgramData\Anaconda3\envs\chatgpt\lib\site-packages\pkg_resources_vendor\packaging_parser.py", line 209, in _parse_specifier
tokenizer.consume("WS")
File "C:\ProgramData\Anaconda3\envs\chatgpt\lib\contextlib.py", line 124, in exit
next(self.gen)
File "C:\ProgramData\Anaconda3\envs\chatgpt\lib\site-packages\pkg_resources_vendor\packaging_tokenizer.py", line 183, in enclosing_tokens
self.raise_syntax_error(
File "C:\ProgramData\Anaconda3\envs\chatgpt\lib\site-packages\pkg_resources_vendor\packaging_tokenizer.py", line 163, in raise_syntax_error
raise ParserSyntaxError(
pkg_resources.extern.packaging._tokenizer.ParserSyntaxError: Expected closing RIGHT_PARENTHESIS
extract-msg (<=0.29.*)
~~~~~~~^
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "C:\ProgramData\Anaconda3\envs\chatgpt\Scripts\chatgpt-script.py", line 33, in
sys.exit(load_entry_point('chatGPT', 'console_scripts', 'chatgpt')())
File "C:\ProgramData\Anaconda3\envs\chatgpt\Scripts\chatgpt-script.py", line 25, in importlib_load_entry_point
return next(matches).load()
File "C:\ProgramData\Anaconda3\envs\chatgpt\lib\importlib\metadata.py", line 77, in load
module = import_module(match.group('module'))
File "C:\ProgramData\Anaconda3\envs\chatgpt\lib\importlib_init_.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1030, in _gcd_import
File "", line 1007, in _find_and_load
File "", line 972, in _find_and_load_unlocked
File "", line 228, in _call_with_frames_removed
File "", line 1030, in _gcd_import
File "", line 1007, in _find_and_load
File "", line 986, in find_and_load_unlocked
File "", line 680, in load_unlocked
File "", line 790, in exec_module
File "", line 228, in call_with_frames_removed
File "d:\3d\unitychatgpt-master\service\chatgpt-wrapper\lwe_init.py", line 1, in
from lwe.backends.api.backend import ApiBackend
File "d:\3d\unitychatgpt-master\service\chatgpt-wrapper\lwe\backends\api\backend.py", line 9, in
from lwe.core.provider_manager import ProviderManager
File "d:\3d\unitychatgpt-master\service\chatgpt-wrapper\lwe\core\provider_manager.py", line 4, in
from lwe.core.plugin_manager import PluginManager
File "d:\3d\unitychatgpt-master\service\chatgpt-wrapper\lwe\core\plugin_manager.py", line 3, in
import pkg_resources
File "C:\ProgramData\Anaconda3\envs\chatgpt\lib\site-packages\pkg_resources_init.py", line 3327, in
def initialize_master_working_set():
File "C:\ProgramData\Anaconda3\envs\chatgpt\lib\site-packages\pkg_resources_init.py", line 3301, in call_aside
f(*args, **kwargs)
File "C:\ProgramData\Anaconda3\envs\chatgpt\lib\site-packages\pkg_resources_init.py", line 3339, in initialize_master_working_set
working_set = WorkingSet.build_master()
File "C:\ProgramData\Anaconda3\envs\chatgpt\lib\site-packages\pkg_resources_init.py", line 629, in build_master
ws.require(requires)
File "C:\ProgramData\Anaconda3\envs\chatgpt\lib\site-packages\pkg_resources_init.py", line 966, in require
needed = self.resolve(parse_requirements(requirements))
File "C:\ProgramData\Anaconda3\envs\chatgpt\lib\site-packages\pkg_resources_init.py", line 832, in resolve
new_requirements = dist.requires(req.extras)[::-1]
File "C:\ProgramData\Anaconda3\envs\chatgpt\lib\site-packages\pkg_resources_init.py", line 2821, in requires
dm = self.dep_map
File "C:\ProgramData\Anaconda3\envs\chatgpt\lib\site-packages\pkg_resources_init.py", line 3110, in _dep_map
self.__dep_map = self.compute_dependencies()
File "C:\ProgramData\Anaconda3\envs\chatgpt\lib\site-packages\pkg_resources_init.py", line 3120, in compute_dependencies
reqs.extend(parse_requirements(req))
File "C:\ProgramData\Anaconda3\envs\chatgpt\lib\site-packages\pkg_resources_init.py", line 3173, in init
super(Requirement, self).init(requirement_string)
File "C:\ProgramData\Anaconda3\envs\chatgpt\lib\site-packages\pkg_resources_vendor\packaging\requirements.py", line 37, in init
raise InvalidRequirement(str(e)) from e
pkg_resources.extern.packaging.requirements.InvalidRequirement: Expected closing RIGHT_PARENTHESIS
extract-msg (<=0.29.*)
I create the env in Anaconda, Windows10

from chatgpt_wrapper import ChatGPT
ModuleNotFoundError: No module named 'chatgpt_wrapper'

Check the release notes for v0.12.0, the module namespace changed: https://github.com/mmabrouk/chatgpt-wrapper/releases/tag/v0.12.0

packages\pkg_resources_vendor\packaging\requirements.py", line 37, in init
raise InvalidRequirement(str(e)) from e
pkg_resources.extern.packaging.requirements.InvalidRequirement: Expected closing RIGHT_PARENTHESIS
extract-msg (<=0.29.*)

This project doesn't list extract-msg in its requirements, so you'll probably need to track down the module that has that faulty syntax and report the issue.
Clean install for me on a Linux server works fine, so I'm pretty sure it's an issue with your environment:
[:~/git/llm-workflow-engine] [temp] functions ± pip install -e .
Obtaining file:///home/hunmonk/git/llm-workflow-engine
  Installing build dependencies ... done
  Checking if build backend supports build_editable ... done
  Getting requirements to build editable ... done
  Preparing editable metadata (pyproject.toml) ... done
Collecting ansible>=8.0 (from chatGPT==0.12.2)
  Using cached ansible-8.0.0-py3-none-any.whl (42.2 MB)
Collecting ansible-core>=2.15 (from chatGPT==0.12.2)
  Using cached ansible_core-2.15.0-py3-none-any.whl (2.2 MB)
Collecting alembic (from chatGPT==0.12.2)
  Using cached alembic-1.11.1-py3-none-any.whl (224 kB)
Collecting ai21>=1.0.5 (from chatGPT==0.12.2)
  Using cached ai21-1.1.4-py3-none-any.whl
Collecting beautifulsoup4 (from chatGPT==0.12.2)
  Using cached beautifulsoup4-4.12.2-py3-none-any.whl (142 kB)
Collecting cohere>=4.3.1 (from chatGPT==0.12.2)
  Downloading cohere-4.11.2-py3-none-any.whl (39 kB)
Collecting email-validator (from chatGPT==0.12.2)
  Using cached email_validator-2.0.0.post2-py3-none-any.whl (31 kB)
Collecting Flask (from chatGPT==0.12.2)
  Using cached Flask-2.3.2-py3-none-any.whl (96 kB)
Collecting huggingface-hub>=0.13.2 (from chatGPT==0.12.2)
  Using cached huggingface_hub-0.15.1-py3-none-any.whl (236 kB)
Collecting Jinja2 (from chatGPT==0.12.2)
  Using cached Jinja2-3.1.2-py3-none-any.whl (133 kB)
Collecting langchain==0.0.199 (from chatGPT==0.12.2)
  Using cached langchain-0.0.199-py3-none-any.whl (1.0 MB)
Collecting names (from chatGPT==0.12.2)
  Using cached names-0.3.0-py3-none-any.whl
Collecting numexpr>=2.8.4 (from chatGPT==0.12.2)
  Using cached numexpr-2.8.4-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (383 kB)
Collecting openai>=0.27.2 (from chatGPT==0.12.2)
  Using cached openai-0.27.8-py3-none-any.whl (73 kB)
Collecting openpyxl (from chatGPT==0.12.2)
  Using cached openpyxl-3.1.2-py2.py3-none-any.whl (249 kB)
Collecting pdfminer.six (from chatGPT==0.12.2)
  Using cached pdfminer.six-20221105-py3-none-any.whl (5.6 MB)
Collecting playwright (from chatGPT==0.12.2)
  Using cached playwright-1.35.0-py3-none-manylinux1_x86_64.whl (35.3 MB)
Collecting prompt-toolkit (from chatGPT==0.12.2)
  Using cached prompt_toolkit-3.0.38-py3-none-any.whl (385 kB)
Collecting pydantic-computed (from chatGPT==0.12.2)
  Using cached pydantic_computed-0.2.2-py3-none-any.whl (4.6 kB)
Collecting pyperclip (from chatGPT==0.12.2)
  Using cached pyperclip-1.8.2-py3-none-any.whl
Collecting python-frontmatter (from chatGPT==0.12.2)
  Using cached python_frontmatter-1.0.0-py3-none-any.whl (9.0 kB)
Collecting PyYAML (from chatGPT==0.12.2)
  Using cached PyYAML-6.0-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (757 kB)
Collecting rich (from chatGPT==0.12.2)
  Using cached rich-13.4.2-py3-none-any.whl (239 kB)
Collecting textract (from chatGPT==0.12.2)
  Using cached textract-1.6.5-py3-none-any.whl (23 kB)
Collecting sqlalchemy>=1.4.48 (from chatGPT==0.12.2)
  Using cached SQLAlchemy-2.0.16-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (2.8 MB)
Collecting tiktoken (from chatGPT==0.12.2)
  Using cached tiktoken-0.4.0-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (1.7 MB)
Collecting aiohttp<4.0.0,>=3.8.3 (from langchain==0.0.199->chatGPT==0.12.2)
  Using cached aiohttp-3.8.4-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (1.0 MB)
Collecting dataclasses-json<0.6.0,>=0.5.7 (from langchain==0.0.199->chatGPT==0.12.2)
  Using cached dataclasses_json-0.5.8-py3-none-any.whl (26 kB)
Collecting langchainplus-sdk>=0.0.9 (from langchain==0.0.199->chatGPT==0.12.2)
  Downloading langchainplus_sdk-0.0.10-py3-none-any.whl (21 kB)
Collecting numpy<2,>=1 (from langchain==0.0.199->chatGPT==0.12.2)
  Using cached numpy-1.24.3-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (17.3 MB)
Collecting openapi-schema-pydantic<2.0,>=1.2 (from langchain==0.0.199->chatGPT==0.12.2)
  Using cached openapi_schema_pydantic-1.2.4-py3-none-any.whl (90 kB)
Collecting pydantic<2,>=1 (from langchain==0.0.199->chatGPT==0.12.2)
  Using cached pydantic-1.10.9-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (3.1 MB)
Collecting requests<3,>=2 (from langchain==0.0.199->chatGPT==0.12.2)
  Using cached requests-2.31.0-py3-none-any.whl (62 kB)
Collecting tenacity<9.0.0,>=8.1.0 (from langchain==0.0.199->chatGPT==0.12.2)
  Using cached tenacity-8.2.2-py3-none-any.whl (24 kB)
Collecting cryptography (from ansible-core>=2.15->chatGPT==0.12.2)
  Using cached cryptography-41.0.1-cp37-abi3-manylinux_2_28_x86_64.whl (4.3 MB)
Collecting packaging (from ansible-core>=2.15->chatGPT==0.12.2)
  Using cached packaging-23.1-py3-none-any.whl (48 kB)
Collecting resolvelib<1.1.0,>=0.5.3 (from ansible-core>=2.15->chatGPT==0.12.2)
  Using cached resolvelib-1.0.1-py2.py3-none-any.whl (17 kB)
Collecting backoff<3.0,>=2.0 (from cohere>=4.3.1->chatGPT==0.12.2)
  Using cached backoff-2.2.1-py3-none-any.whl (15 kB)
Collecting importlib_metadata<7.0,>=6.0 (from cohere>=4.3.1->chatGPT==0.12.2)
  Using cached importlib_metadata-6.6.0-py3-none-any.whl (22 kB)
Collecting filelock (from huggingface-hub>=0.13.2->chatGPT==0.12.2)
  Using cached filelock-3.12.2-py3-none-any.whl (10 kB)
Collecting fsspec (from huggingface-hub>=0.13.2->chatGPT==0.12.2)
  Using cached fsspec-2023.6.0-py3-none-any.whl (163 kB)
Collecting tqdm>=4.42.1 (from huggingface-hub>=0.13.2->chatGPT==0.12.2)
  Using cached tqdm-4.65.0-py3-none-any.whl (77 kB)
Collecting typing-extensions>=<IP_ADDRESS> (from huggingface-hub>=0.13.2->chatGPT==0.12.2)
  Using cached typing_extensions-4.6.3-py3-none-any.whl (31 kB)
Collecting MarkupSafe>=2.0 (from Jinja2->chatGPT==0.12.2)
  Using cached MarkupSafe-2.1.3-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (28 kB)
Collecting greenlet!=0.4.17 (from sqlalchemy>=1.4.48->chatGPT==0.12.2)
  Using cached greenlet-2.0.2-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (618 kB)
Collecting Mako (from alembic->chatGPT==0.12.2)
  Using cached Mako-1.2.4-py3-none-any.whl (78 kB)
Collecting soupsieve>1.2 (from beautifulsoup4->chatGPT==0.12.2)
  Using cached soupsieve-2.4.1-py3-none-any.whl (36 kB)
Collecting dnspython>=2.0.0 (from email-validator->chatGPT==0.12.2)
  Using cached dnspython-2.3.0-py3-none-any.whl (283 kB)
Collecting idna>=2.0.0 (from email-validator->chatGPT==0.12.2)
  Using cached idna-3.4-py3-none-any.whl (61 kB)
Collecting Werkzeug>=2.3.3 (from Flask->chatGPT==0.12.2)
  Using cached Werkzeug-2.3.6-py3-none-any.whl (242 kB)
Collecting itsdangerous>=2.1.2 (from Flask->chatGPT==0.12.2)
  Using cached itsdangerous-2.1.2-py3-none-any.whl (15 kB)
Collecting click>=8.1.3 (from Flask->chatGPT==0.12.2)
  Using cached click-8.1.3-py3-none-any.whl (96 kB)
Collecting blinker>=1.6.2 (from Flask->chatGPT==0.12.2)
  Using cached blinker-1.6.2-py3-none-any.whl (13 kB)
Collecting et-xmlfile (from openpyxl->chatGPT==0.12.2)
  Using cached et_xmlfile-1.1.0-py3-none-any.whl (4.7 kB)
Collecting charset-normalizer>=2.0.0 (from pdfminer.six->chatGPT==0.12.2)
  Using cached charset_normalizer-3.1.0-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (197 kB)
Collecting pyee==9.0.4 (from playwright->chatGPT==0.12.2)
  Using cached pyee-9.0.4-py2.py3-none-any.whl (14 kB)
Collecting wcwidth (from prompt-toolkit->chatGPT==0.12.2)
  Using cached wcwidth-0.2.6-py2.py3-none-any.whl (29 kB)
Collecting markdown-it-py>=2.2.0 (from rich->chatGPT==0.12.2)
  Using cached markdown_it_py-3.0.0-py3-none-any.whl (87 kB)
Collecting pygments<3.0.0,>=2.13.0 (from rich->chatGPT==0.12.2)
  Using cached Pygments-2.15.1-py3-none-any.whl (1.1 MB)
Collecting argcomplete~=1.10.0 (from textract->chatGPT==0.12.2)
  Using cached argcomplete-1.10.3-py2.py3-none-any.whl (36 kB)
Collecting beautifulsoup4 (from chatGPT==0.12.2)
  Using cached beautifulsoup4-4.8.2-py3-none-any.whl (106 kB)
Collecting chardet==3.* (from textract->chatGPT==0.12.2)
  Using cached chardet-3.0.4-py2.py3-none-any.whl (133 kB)
Collecting docx2txt~=0.8 (from textract->chatGPT==0.12.2)
  Using cached docx2txt-0.8-py3-none-any.whl
Collecting extract-msg<=0.29.* (from textract->chatGPT==0.12.2)
  Using cached extract_msg-0.28.7-py2.py3-none-any.whl (69 kB)
Collecting pdfminer.six (from chatGPT==0.12.2)
  Using cached pdfminer.six-20191110-py2.py3-none-any.whl (5.6 MB)
Collecting python-pptx~=0.6.18 (from textract->chatGPT==0.12.2)
  Using cached python_pptx-0.6.21-py3-none-any.whl
Collecting six~=1.12.0 (from textract->chatGPT==0.12.2)
  Using cached six-1.12.0-py2.py3-none-any.whl (10 kB)
Collecting SpeechRecognition~=3.8.1 (from textract->chatGPT==0.12.2)
  Using cached SpeechRecognition-3.8.1-py2.py3-none-any.whl (32.8 MB)
Collecting xlrd~=1.2.0 (from textract->chatGPT==0.12.2)
  Using cached xlrd-1.2.0-py2.py3-none-any.whl (103 kB)
Collecting pycryptodome (from pdfminer.six->chatGPT==0.12.2)
  Using cached pycryptodome-3.18.0-cp35-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (2.1 MB)
Collecting sortedcontainers (from pdfminer.six->chatGPT==0.12.2)
  Using cached sortedcontainers-2.4.0-py2.py3-none-any.whl (29 kB)
Collecting regex>=2022.1.18 (from tiktoken->chatGPT==0.12.2)
  Using cached regex-2023.6.3-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (781 kB)
Collecting attrs>=17.3.0 (from aiohttp<4.0.0,>=3.8.3->langchain==0.0.199->chatGPT==0.12.2)
  Using cached attrs-23.1.0-py3-none-any.whl (61 kB)
Collecting multidict<7.0,>=4.5 (from aiohttp<4.0.0,>=3.8.3->langchain==0.0.199->chatGPT==0.12.2)
  Using cached multidict-6.0.4-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (117 kB)
Collecting async-timeout<5.0,>=4.0.0a3 (from aiohttp<4.0.0,>=3.8.3->langchain==0.0.199->chatGPT==0.12.2)
  Using cached async_timeout-4.0.2-py3-none-any.whl (5.8 kB)
Collecting yarl<2.0,>=1.0 (from aiohttp<4.0.0,>=3.8.3->langchain==0.0.199->chatGPT==0.12.2)
  Using cached yarl-1.9.2-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (282 kB)
Collecting frozenlist>=1.1.1 (from aiohttp<4.0.0,>=3.8.3->langchain==0.0.199->chatGPT==0.12.2)
  Using cached frozenlist-1.3.3-cp311-cp311-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl (154 kB)
Collecting aiosignal>=1.1.2 (from aiohttp<4.0.0,>=3.8.3->langchain==0.0.199->chatGPT==0.12.2)
  Using cached aiosignal-1.3.1-py3-none-any.whl (7.6 kB)
Collecting marshmallow<4.0.0,>=3.3.0 (from dataclasses-json<0.6.0,>=0.5.7->langchain==0.0.199->chatGPT==0.12.2)
  Using cached marshmallow-3.19.0-py3-none-any.whl (49 kB)
Collecting marshmallow-enum<2.0.0,>=1.5.1 (from dataclasses-json<0.6.0,>=0.5.7->langchain==0.0.199->chatGPT==0.12.2)
  Using cached marshmallow_enum-1.5.1-py2.py3-none-any.whl (4.2 kB)
Collecting typing-inspect>=0.4.0 (from dataclasses-json<0.6.0,>=0.5.7->langchain==0.0.199->chatGPT==0.12.2)
  Using cached typing_inspect-0.9.0-py3-none-any.whl (8.8 kB)
Collecting imapclient==2.1.0 (from extract-msg<=0.29.*->textract->chatGPT==0.12.2)
  Using cached IMAPClient-2.1.0-py2.py3-none-any.whl (73 kB)
Collecting olefile>=0.46 (from extract-msg<=0.29.*->textract->chatGPT==0.12.2)
  Using cached olefile-0.46-py2.py3-none-any.whl
Collecting tzlocal>=2.1 (from extract-msg<=0.29.*->textract->chatGPT==0.12.2)
  Using cached tzlocal-5.0.1-py3-none-any.whl (20 kB)
Collecting compressed-rtf>=1.0.6 (from extract-msg<=0.29.*->textract->chatGPT==0.12.2)
  Using cached compressed_rtf-1.0.6-py3-none-any.whl
Collecting ebcdic>=1.1.1 (from extract-msg<=0.29.*->textract->chatGPT==0.12.2)
  Using cached ebcdic-1.1.1-py2.py3-none-any.whl (128 kB)
Collecting zipp>=0.5 (from importlib_metadata<7.0,>=6.0->cohere>=4.3.1->chatGPT==0.12.2)
  Using cached zipp-3.15.0-py3-none-any.whl (6.8 kB)
Collecting mdurl~=0.1 (from markdown-it-py>=2.2.0->rich->chatGPT==0.12.2)
  Using cached mdurl-0.1.2-py3-none-any.whl (10.0 kB)
Collecting lxml>=3.1.0 (from python-pptx~=0.6.18->textract->chatGPT==0.12.2)
  Using cached lxml-4.9.2-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.manylinux_2_24_x86_64.whl (7.2 MB)
Collecting Pillow>=3.3.2 (from python-pptx~=0.6.18->textract->chatGPT==0.12.2)
  Using cached Pillow-9.5.0-cp311-cp311-manylinux_2_28_x86_64.whl (3.4 MB)
Collecting XlsxWriter>=0.5.7 (from python-pptx~=0.6.18->textract->chatGPT==0.12.2)
  Using cached XlsxWriter-3.1.2-py3-none-any.whl (153 kB)
Collecting urllib3<3,>=1.21.1 (from requests<3,>=2->langchain==0.0.199->chatGPT==0.12.2)
  Using cached urllib3-2.0.3-py3-none-any.whl (123 kB)
Collecting certifi>=2017.4.17 (from requests<3,>=2->langchain==0.0.199->chatGPT==0.12.2)
  Using cached certifi-2023.5.7-py3-none-any.whl (156 kB)
Collecting cffi>=1.12 (from cryptography->ansible-core>=2.15->chatGPT==0.12.2)
  Using cached cffi-1.15.1-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (462 kB)
Collecting pycparser (from cffi>=1.12->cryptography->ansible-core>=2.15->chatGPT==0.12.2)
  Using cached pycparser-2.21-py2.py3-none-any.whl (118 kB)
Collecting mypy-extensions>=0.3.0 (from typing-inspect>=0.4.0->dataclasses-json<0.6.0,>=0.5.7->langchain==0.0.199->chatGPT==0.12.2)
  Using cached mypy_extensions-1.0.0-py3-none-any.whl (4.7 kB)
Building wheels for collected packages: chatGPT
  Building editable for chatGPT (pyproject.toml) ... done
  Created wheel for chatGPT: filename=chatGPT-0.12.2-0.editable-py3-none-any.whl size=12173 sha256=8ef18f0c7a202322d71d6f4e73ad88118678676c4bf56d5ee08ee50de87c1281
  Stored in directory: /tmp/pip-ephem-wheel-cache-jiu34jyj/wheels/ad/b6/34/bc3aa0272ac86bc4c3cdac506d2f670b19a4c2172afd4de02c
Successfully built chatGPT
Installing collected packages: wcwidth, SpeechRecognition, sortedcontainers, resolvelib, pyperclip, names, ebcdic, docx2txt, compressed-rtf, chardet, argcomplete, zipp, XlsxWriter, xlrd, urllib3, tzlocal, typing-extensions, tqdm, tenacity, soupsieve, six, regex, PyYAML, pygments, pycryptodome, pycparser, prompt-toolkit, Pillow, packaging, olefile, numpy, mypy-extensions, multidict, mdurl, MarkupSafe, lxml, itsdangerous, idna, greenlet, fsspec, frozenlist, filelock, et-xmlfile, dnspython, click, charset-normalizer, certifi, blinker, backoff, attrs, async-timeout, yarl, Werkzeug, typing-inspect, sqlalchemy, requests, python-pptx, python-frontmatter, pyee, pydantic, pdfminer.six, openpyxl, numexpr, marshmallow, markdown-it-py, Mako, Jinja2, importlib_metadata, imapclient, email-validator, cffi, beautifulsoup4, aiosignal, tiktoken, rich, pydantic-computed, playwright, openapi-schema-pydantic, marshmallow-enum, langchainplus-sdk, huggingface-hub, Flask, extract-msg, cryptography, alembic, aiohttp, ai21, textract, openai, dataclasses-json, cohere, ansible-core, langchain, ansible, chatGPT
Successfully installed Flask-2.3.2 Jinja2-3.1.2 Mako-1.2.4 MarkupSafe-2.1.3 Pillow-9.5.0 PyYAML-6.0 SpeechRecognition-3.8.1 Werkzeug-2.3.6 XlsxWriter-3.1.2 ai21-1.1.4 aiohttp-3.8.4 aiosignal-1.3.1 alembic-1.11.1 ansible-8.0.0 ansible-core-2.15.0 argcomplete-1.10.3 async-timeout-4.0.2 attrs-23.1.0 backoff-2.2.1 beautifulsoup4-4.8.2 blinker-1.6.2 certifi-2023.5.7 cffi-1.15.1 chardet-3.0.4 charset-normalizer-3.1.0 chatGPT-0.12.2 click-8.1.3 cohere-4.11.2 compressed-rtf-1.0.6 cryptography-41.0.1 dataclasses-json-0.5.8 dnspython-2.3.0 docx2txt-0.8 ebcdic-1.1.1 email-validator-2.0.0.post2 et-xmlfile-1.1.0 extract-msg-0.28.7 filelock-3.12.2 frozenlist-1.3.3 fsspec-2023.6.0 greenlet-2.0.2 huggingface-hub-0.15.1 idna-3.4 imapclient-2.1.0 importlib_metadata-6.6.0 itsdangerous-2.1.2 langchain-0.0.199 langchainplus-sdk-0.0.10 lxml-4.9.2 markdown-it-py-3.0.0 marshmallow-3.19.0 marshmallow-enum-1.5.1 mdurl-0.1.2 multidict-6.0.4 mypy-extensions-1.0.0 names-0.3.0 numexpr-2.8.4 numpy-1.24.3 olefile-0.46 openai-0.27.8 openapi-schema-pydantic-1.2.4 openpyxl-3.1.2 packaging-23.1 pdfminer.six-20191110 playwright-1.35.0 prompt-toolkit-3.0.38 pycparser-2.21 pycryptodome-3.18.0 pydantic-1.10.9 pydantic-computed-0.2.2 pyee-9.0.4 pygments-2.15.1 pyperclip-1.8.2 python-frontmatter-1.0.0 python-pptx-0.6.21 regex-2023.6.3 requests-2.31.0 resolvelib-1.0.1 rich-13.4.2 six-1.12.0 sortedcontainers-2.4.0 soupsieve-2.4.1 sqlalchemy-2.0.16 tenacity-8.2.2 textract-1.6.5 tiktoken-0.4.0 tqdm-4.65.0 typing-extensions-4.6.3 typing-inspect-0.9.0 tzlocal-5.0.1 urllib3-2.0.3 wcwidth-0.2.6 xlrd-1.2.0 yarl-1.9.2 zipp-3.15.0
[:~/git/llm-workflow-engine] [temp] functions ± lwe
PluginManager - ERROR - Plugin test_2 not found in search path

                                        Provide a prompt, or type /help or ? to list commands.

(0.5/8192/0): default
hunmonk@gpt-4-chatbot-responses 1>

See here, this user fixed their Conda-related issue: https://github.com/mmabrouk/chatgpt-wrapper/issues/313

See here, this user fixed their Conda-related issue: #313

Thanks a lot, I will try it.

pipdeptree -r -p extract-msg
extract-msg==0.28.7
└── textract==1.6.5 [requires: extract-msg<=0.29.*]
    └── chatGPT==0.12.2 [requires: textract]

As you can see, the textract package is the one requiring extract-msg.
I suggest you try to reproduce the error by installing textract directly, and if so, file an issue with the textract project.

Same issue here. Installed on conda env in Linux :
pkg_resources.extern.packaging.requirements.InvalidRequirement: Expected closing RIGHT_PARENTHESIS
extract-msg (<=0.29.*)
The issue is known in textract package:
https://github.com/deanmalmgren/textract/issues/461
https://github.com/tfeldmann/organize/issues/283
Installing textract separately didn't work.
(conda install -c conda-forge textract)

Found a workaround:
uninstalled (pip uninstall): textract, extract-msg, speechrecognition and pdfminer.six
git clone to textract:  git clone --recurse-submodules  https://github.com/deanmalmgren/textract.git
Change this source file: textract/requirements/python
Changed these lines:
extract-msg**<=0.29** #Last with python2 support
pdfminer.six==20200517 #Last with python2 support
python-pptx~=0.6.18
six~=1.12.0
SpeechRecognition~=3.10.0
And then install from source:
pip install -e .

Sadly, textract isn't being well-maintained, and there's no other good general use extraction package I could find.
So, I rolled a custom version of the package to fix the issue.
Installing the newest version of this package should now work: https://github.com/mmabrouk/chatgpt-wrapper/releases/tag/v0.12.3


[Event Request]Application “Tests-SMB”, Codeunit 138000 "O365 Simplify UI Sales Invoice"

[Event Request]Application “Tests-SMB”, Codeunit 138000 "O365 Simplify UI Sales Invoice"

We need the possibility to expand the excluded fields for the Sales Header and Sales Line in function VerifySalesDocumentsMatch.
As an example we switched from array to list and added an event for header and line.
Same also for Purchase Header and Purchase Line in function VerifyPurchaseDocumentsMatch.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


Problem with Pallas in JAX 0.4.24

Description
I trying to setup an environment for jax 0.4.24
When I try to running a pallas kernel (like an example), I get an error:
LLVM ERROR: Trying to register different dialects for the same namespace: builtin
Triton kernels work well
System info (python version, jaxlib version, accelerator, etc.)
Tax 0.4.24, jaxlib 0.4.24, triton on commit https://github.com/openai/triton/commits/9f816a7b984ce20ec684866f9c8bb5ffd49e2500, jax-triton on commit 3666738dd9fef74f702a82a3fa068d7e2bc80e2a

That error should have been fixed in https://github.com/google/jax/commit/5e2e609a9b8da90989a593575ad83eb2e43109e8, so you would need a version including that.
If it suits your workflow, you could try the containers distributed as ghcr.io/nvidia/jax:pallas-YYYY-MM-DD (or ghcr.io/nvidia/jax:pallas for the latest one).

Got it! Thank you for the answer

Tried the latest one (2024-02-14) and got en error:
"""
python3: /opt/openxla-triton/include/triton/Tools/Sys/GetEnv.hpp:49: bool triton::tools::getBoolEnv(const string&): Assertion `::triton::ENV_VARS.find(env.c_str()) != ::triton::ENV_VARS.end() && msg.c_str()' failed.
"""
As I understand, it rises because of the commit: https://github.com/openxla/triton/commit/f2d49c8fd08cef4adbfddd6e428d93f98576653f
The flag ENABLE_MMA_V3 was renamed to ENABLE_MMA_V3 without fixing it in https://github.com/openxla/triton/blob/f2d49c8fd08cef4adbfddd6e428d93f98576653f/include/triton/Tools/Sys/GetEnv.hpp#L32-L35

jaxlib 0.4.25 no longer has this issue. Closing as fixed.


data structure

First, thanks for your previous reply.
Can I ask you another question about the data structure in the student.csv? I read the Keys() there and found that there are mainly: "x, y, vx, vy, vx_, vy_, gx, gy, gvx, gvy" . I can figure out "x, y (position), vx_, vy_ (distance to next position) , gx, gy (goal position)", but what are " vx, vy, gvx, gvy" ?
Best

Given the item with timestamp t, (vx, vy)_t is the current velocity, namely, the velocity to reach the position (px, py)t from (px, py)t-1.  (vx, vy)t is the velocity to leave from (px, py)t. Therefore, we have (vx, vy)t = (vx, vy)t+1 in dataset file. When accepting the states at timestamp t as the input, the expert network is expected to give an output as the estimation to (vx, vy)_t.
(gvx, gvy) is the goal velocity computed by Appendix.A in Crowd Space: A Predictive Crowd Analysis Technique. It is considered as the final leaving velocity at an agent's last timestamp. It is used only in a special case when we do interpolation at some time t' between the timestamp t0 and t1. If an agent appears as a neighbor of some other one at timestamp t0 but not at timestamp t1, we actually do not know directly whether it appears as a neighbor at t'. In that case, we estimate the position of that agent by using the velocity of (gvx, gvy). For simplicity, (vx_, vy_) can be used as the replacement of (gvx, gvy), but it will not necessarily reflect the movement trends of an agent better than (gvx, gvy): (1) (vx_, vy_) cannot be computed for the last timestamp in the raw data; and (2) the items associated with the real last few timestamps in the raw data may be removed when we do re-sampling to reduce the data recording frequency and in that case (vx_, vy_) is just a transient leaving velocity.

Thanks so much for your kindness and detailed explanation. This helps a lot~
All the best!


uWSGI / nginx documentation is incorrect

The Flask documentation for how to use it with uWSGI and nginx is incorrect. As the uWSGI docs say at http://uwsgi-docs.readthedocs.org/en/latest/Nginx.html#hosting-multiple-apps-in-the-same-process-aka-managing-script-name-and-path-info, "ancient uWSGI versions used to support the so called “uwsgi_modifier1 30” approach.  The documentation should be updated to talk about the manage-script-name and mount options instead.

@davidism just in case you didn't see my comment on the PR... I dug into this pretty heavily a few weeks ago--submitted a couple of fixes to the uWSGI docs. The updates in #1558 are solid. Like Flask, uWSGI offers more than one way to do things, so there are alternative configs, but this works and is a lot better than what the Flask docs currently recommend. I don't see any reason to hold off on merging it.

@jeffwidman just to carify: do you suggest merging #1558?

Yes

Merged :)

:+1:


Improve docker build

Use current code instead of cloning from github.
Use multi-stage instead of deleting everything.

Hmm this fails for me.
Also, I don't like the fact that now we have lost the ability to see the specific git tag that this was built from.
g++ -DHAVE_CONFIG_H -I. -I.. <...> -DDRACHTIO_VERSION=\"1.0.0\"

The failure is:
Killed signal terminated program cc1plus

I don't see how that's related to any of my changes.

How about now? You can build with ./build-docker.sh, and it should use the current version.

Rebased. @davehorton ping.


Log errors before rewriting them

In https://github.com/mcollina/fastify-gql/blob/aa8ef7eb2fcfea1838fff5563c502ff2bcd25966/index.js#L458 we rewrite the errors and we display those in the GraphQL result. In case of a developer error, we should log it out.
I think we should log the errors as warn or error level, so that a developer could diagnose the problem if it exists.

what do you think @asciidisco @pscarey ?

I have mixed views on this:

I don't think the server should force logging (which isn't customisable / can't be disabled).
It's useful to log things for developers who haven't chosen to customise things.

The originalError property is populated on the GraphQLError which is created, so it should get escalated up to the errorHandler and therefore the defaultErrorFormatter.
If logging was added to the defaultErrorFormatter here, then it would log by default but still provide developer choice.
Happy to make the PR if desired.
Side note, the implementation of the execution.errors block could be tidied up slightly..
    if (execution.errors) {
      const err = new InternalServerError()
      err.errors = execution.errors.map(e => {
        if (e.originalError && (Object.prototype.hasOwnProperty.call(e.originalError, 'extensions'))) {
          return new GraphQLError(e.originalError.message, e.nodes, e.source, e.positions, e.path, e.originalError, e.originalError.extensions)
        }
        return e
      })
      err.data = execution.data
      throw err
    }

That's ok, good idea!


[release/6.0] Include ARM64 bits in smoke-test-prereqs

This will enable testing of ARM64 builds before they are officially released.

Dupe of https://github.com/dotnet/source-build/issues/2848.


fan control

[ ] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.1 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

bro, this is 1.3 Shema, dear bot

M


chore: add example of rerunning failed

Updates @currents/playwright (for additional reporter support)
Adds an example workflow that shows how one can collect failed tests, and feed them into new runs

Trying to map this implementation to using Currents API, or enhancing pwc to automate the steps:

I like the idea of  --pwc-failed-from . One of the reasons I avoid the API to begin with was I wanted to see what the use-case / workflows looks like.
Like, what does this achieve that orchestration + fail fast cannot? Couldn't we just have orchestration run failed tests first as an option instead?

Trying to map this implementation to using Currents API, or enhancing pwc to automate the steps:

I like the idea of --pwc-failed-from . One of the reasons I avoid the API to begin with was I wanted to see what the use-case / workflows looks like.

I think it can only be used with pwc as a CLI and not as a reporter - i.e. if we ever going to do that, we'll need a "standalone" solution.

Like, what does this achieve that orchestration + fail fast cannot? Couldn't we just have orchestration run failed tests first as an option instead?

or8n + fail fast will run all the tests and can cause a failure in different test / spec. From my experience, they know their tests are flaky and have the mindset of "each test should pass at least once" to merge.  Practically, it can be tricky to comprehend and setup the whole "orchestration" bundle. My guess is that they just want to enable the native GHA "rerun-failed" functionality.
I know that Stephan from Ramp (laid off recently) was working on it extensively.


BUG: Bulldog Magazine Articles are Missing

Issue Type
Bug
Summary
Mack Bulldog category pages do not display articles and article search by category returns no results.
Priority
High
Description
Impact to production: The articles that should display on the following pages in all of the Bulldog Magazine categories (all categories under "Loading Dock" header) do not display:

https://www.macktrucks.com/magazine/categories/customer-profiles
https://www.macktrucks.com/magazine/categories/product-updates
https://www.macktrucks.com/magazine/categories/technology-at-work
https://www.macktrucks.com/magazine/categories/features
https://www.macktrucks.com/magazine/categories/in-the-news
https://www.macktrucks.com/magazine/categories/viewpoint

Affected Device Classes
Desktop, Mobile, Tablet
Affected Browsers/Devices and Versions
Chrome and Edge
Steps to Reproduce

Navigate to Bulldog Magazine section from home page (Experience>Explore & Experience>Bulldog Magazine)
Scroll down to Loading Dock section
Select any of the categories (Customer Profiles, Product Updates, Technology at Work, Features, In the News, and Viewpoint) and the selected category page does not display any articles.
Selecting Explore All Articles CTA and searching for articles by specifying a category returns no results, except for "All Categories," which displays 85 articles.

Expected Results
Articles will display for each category and user will be able to find articles by searching by category.
Actual Results
No articles display. No search for articles by category returns results.
Attachment

Thankyou for guiding me on the steps @santi-homps. The issue is now sorted and all the magazine articles are displaying in each category.

This issue will re-occur if the magazine-articles.json query is re-triggered since all the articles now have been published replacing category for article-category.
The definitive fix for this will come with completion of issue #127 that depends as well on issue #106 currently blocked by work done by the search team.

Testing Completed. Bug is fixed and articles are displayed as expected.


Tidy up some filenames and documentation from #25382

OpenTest4j classes were named incorrectly (Opentest instead OpenTest), with some documentation missing.

@bot-gradle test and merge please

I've triggered a build for you. Click here to see all failures if there's any.


backtrace doesn't link to my source code reliably (subprojects)

Version of VSCode: 1.10.2
Version of the extension: 0.3.10
OS: Windows 10
Description:
When I run my tests, the stack traces sometimes link to my source code (so that I can ctrl-click a filename in the traceback and have it open the editor to that file/line etc), and sometimes doesn't. This may be related to the fact that I use Cargo workspaces with subprojects.
As an example, if I hit ctrl-shift-t in one of my subproject files, rust-vscode very nicely figures out which subproject to run the tests for. Since I have RUST_BACKTRACE=1 set up in my environment, the output shows the tracebacks for my test failures.  Here's an example of a traceback:
---- combat::test::target_range stdout ----
	thread 'combat::test::target_range' panicked at 'called `Result::unwrap()` on an `Err` value: CreatureLacksAbility(CreatureID(Uuid("b972f025-769d-417f-ba02-830a8c9f2a36")), AbilityID("shoot"))', src\libcore\result.rs:860
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: core::result::Result<pandt::game::ChangedGame, pandt::types::GameError>::unwrap<pandt::game::ChangedGame,pandt::types::GameError>
             at C:\projects\rust\src\libcore\result.rs:737
   1: pandt::combat::test::target_range
             at ./src\combat.rs:270
   2: test::{{impl}}::call_box<(),closure>
             at C:\projects\rust\src\libtest\lib.rs:140
   3: panic_unwind::__rust_maybe_catch_panic
             at C:\projects\rust\src\libpanic_unwind\lib.rs:98
   4: std::panicking::try::do_call<std::panic::AssertUnwindSafe<closure>,()>
             at C:\projects\rust\src\libstd\panicking.rs:450
   5: panic_unwind::__rust_maybe_catch_panic
             at C:\projects\rust\src\libpanic_unwind\lib.rs:98
   6: alloc::boxed::{{impl}}::call_box<(),closure>
             at C:\projects\rust\src\liballoc\boxed.rs:638
   7: std::sys::imp::thread::{{impl}}::new::thread_start
             at C:\projects\rust\src\libstd\sys\windows\thread.rs:50

Notice in particular the line with the filename ./src\combat.rs:270. I believe the reason this isn't automatically being rendered as a link, is that it's probably looking for the filename from the root of my project instead of from the subproject directory.
I don't know if vscode-rust can actually do anything to solve this. Maybe there's a way to get cargo to always show absolute paths in tracebacks?

@radix,
I have opened such an issue in rust a week ago.

@KalitaAlexey oh, cool :) I tracked it down so I could subscribe (and for anyone who is interested): https://github.com/rust-lang/rust/issues/40149 I assume that's the one you meant.

Yes, it is.

I have checked it.
The issue has been fixed.


Update sticky header offset CSS & JS

Should fix #23252. This sets user-select: none; on the heading-elements and user-select: auto; on the direct child. All content in the heading-elements are wrapped in spans by jQuery.

Hi @MartijnCuppens!
Thanks for wanting to contribute to Bootstrap by sending this pull request!
Unfortunately, your pull request seems to have some problems:

Changes must be made to the original Sass or Less source code file(s), not just the compiled CSS file(s).

You'll need to fix these mistakes and revise your pull request before we can proceed further.
Once you've fixed these problems, you can either ask the maintainers to re-open this pull request, or you can create a new pull request.
Thanks!
(Please note that this is a fully automated comment.)


Alignment with FOM schema

I just wanted to follow up from a conversation from #11 and discuss integration of the FOM schema with this effort as there are probably both synergies and overlaps in scope. I am thinking of renaming FOM to something like “Matrix and Analysis Metadata Standards (MAMS)” because the primary purpose (at least for the first half of the working group) was to develop metadata fields (i.e. a database-like schema) that can be used to describe the data contained within matrices, how they relate to each other, and provenance of what tools/functions created them. This includes fields for the data matrices (X or FOM), annotation matrices (var/obs or FAM/OAM), ID arrays/matrices (OID/FID), and potentially graph data.
To probably oversimplify things a bit, my initial impressions are that the matrix-api schema uses a combination of a “directory-like” structures and ID labels (e.g. “RNA.raw”) to encode the information about relationships between matrices and what each matrix is within a dataset. Using hierarchical directory-like structures to define groups is intuitive and similar to the way toolchain objects arrange their data so it can make sense to do that here. As an aside, minor limitations may be that a matrix can only “live” in one group and there may be multiple ways to define the hierarchy. A database-like schema with metadata tags can be a bit less intuitive but potentially more flexible (e.g. can define many-to-many relationships) and extensible to new situations (don’t have to redefine the hierarchy with new scenarios). I’m sure that there are other upsides/downsides to each, but they are probably not mutually exclusive either.
There are some simple potential synergies. Some of the ID labels that are being proposed in the matrix api are directly related to FOM fields. RNA.raw is just a combination of two FOM fields “analyte” and “processing” and could be referenced in the matrix api docs with something like analyte.processing. Referring to these fields and encouraging (but not forcing) people to use the suggested ontologies for these fields will ultimately help integration across datasets and probably make the api more useful. The one place where this a potential discrepancy with the current description is RNA.filtering. FOM currently has separate fields describing the level of filtering that has been done to the observations or features (obs_subset, feature_subset) and this is distinct from the processing field which describes what type of data is in the matrix. These fields might be useful for naming different sc_groups. There have been some grouping-like metadata tags drafted in the FOM schema. I’m debating on removing these and leaving that for the implementations like matrix-api.
I am hoping that the metadata fields defined in FOM can be stored in the various objects (maybe in __meta). This may also help with cross dataset queries. For example, getting the rna.clean.counts matrix from datasets A, B, and C will to start integrative analyses likely be easier if tags are standardized and stored in a consistent way.
Sorry for the long post, but it would be great to get other’s thoughts at some point.

I don't entirely understand everything in the previous as I lack knowledge of the FOM schema, but I agree on it being a great idea to write down examples of the interplay between matrix-api and the FOM schema.
Maybe one could start documenting some examples in this issue, and then point out potentials for improvements? Right now, the only major question seems how to represent filtering in a way that plays well with the current matrix-api specification and the FOM schema.
As filtering is a very important basic question, I'd love us to resolve it either by adapting matrix-api or the FOM schema.
Btw, I'd be happy about the MAMS abbreviation and corresponding long form! I think it's much easier understandable than "FOM".

Closing as outdated, but happy to revisit if there continues to be interest.


Taking gametime after player leaves to update statistics then.

https://github.com/sopra-fs23-group-40/Server/commit/8b7c5b18518ccdd05706522e8333265ea5fd2dda


doc find sapmap fix

This did not fix the issue.  Suggest instead of using pip install -e . to install sapmap in editable mode (thus symlinking it into the global namespace to make its code accessible to sphinx to build its api docs), to add sapmap to the python path in the container environment.
One possibility is to set PYTHONPATH directly when running the doc build action, if that's the only step that needs it


modifyAckDeadline is duplicating messages

Environment details

OS: macOS 10.13.4 (High Sierra)
Node.js version: 9.11.1
npm version: 5.6.0
@google-cloud/pubsub version: 0.18.0

Steps to reproduce

Create a subscriber and topic
Send a message to the topic
Use v1's pull method
modifyAckDeadline of a single message
ack said message a couple seconds later

I'm using Pub/Sub for processes that normally take a couple minutes, but can sometimes extend to 30+ mins. Here's a second by second look at what my little test setup does.
0:00 - pulldown 1 message from subscription with 20 second deadline (or 600 seconds, same result)
0:05 - modifyAckDeadline by 20 seconds
0:15 - ack message; then pull down the same message from the queue
I decided to try this with two instances pulling down messages. After sending one message, as soon as I would modifyAckDeadline on the instance that got the message, the other instance would pull down the message and start the same process.
Eventually, an ack finally sticks and the message goes away.
So it seems that modifyAckDeadline is creating a duplicate message.

@callmehiphop -- I believe this is a common report. Do we have an issue or PR that would cover this already? Or is this part of the redesign we're about to go through?

@stephenplusplus I could be wrong, but it sounds like he's using the autogen layer. We don't allow users to use pull or modack within the hand written client.
@JamesTheTerry can you confirm that you're using the autogen layer?

@callmehiphop Forgive me, what is the autogen layer? I'm using the v1.SubscriberClient if that helps.

My apologies for not clarifying. We offer 2 different clients - one of which is auto generated and offers bare bones functionality, the other is hand written (on top of the autogen) with some convenience methods/etc. Typically anything with the version prefix/namespace is a reference to the autogen.
@kir-titievsky any idea why we might be seeing re-deliveries here? Could this be a side effect of the pull method? Would receipting the messages prevent a redelivery?

@danoscarmike I stopped using it and built a small load balancer instead, which works out better for me given that my tasks take like an hour sometimes.

I can confirm the issue: @google-cloud/pubsub 0.22.2 (consitst to a few lower version)
nodejs 8.12.0
npm 6.5.0
linux mint 17.3
I'm having the same issue with retrieving message before the lock is over, this is out test in nodejs:
const cp = CloudProvider({type: GCP, env: 'INT'});
            const rand = Math.random().toString(16);
            await cp.queue.sendMessage(GCP_TOPIC_QUEUE, {test: rand});

            const messages = await cp.queue.receiveMessage(GCP_QUEUE, {maxMessages: 10, waitTimeout: 2});
            const message = messages.find(m => m.data.test === rand);

            // Retrieving the message
            assert.ok(message);

            await cp.queue.extendMessageLock(GCP_QUEUE, message, {lockTimeout: 400});
            await delay(360000);
            const messages2 = await cp.queue.receiveMessage(GCP_QUEUE, {
                maxMessages: 10,
                waitTimeout: 2
            });
            const message2 = messages2.find(m => m.data.test === rand);

            // Message should not be not be here, but is retrieved (it usually don't work but sometimes it
            // does)
            assert.ok(!message2);
            // wait for the lock to be done
            await delay(50000);

            const messages3 = await cp.queue.receiveMessage(GCP_QUEUE, {maxMessages: 10, waitTimeout: 2});
            const message3 = messages3.find(m => m.data.test === rand);

            // Message should be here because `extendMessageLock` is over
            assert.ok(message3);

extendMessageLock function
async function extendMessageLock(queue, message, options = {}) {
        const client = new pubSubHelper.v1.SubscriberClient({});
        const subscription = client.subscriptionPath(GCP_PROJECT_ID, queue);
        const ackDeadlineSeconds = isFinite(options.lockTimeout) ? options.lockTimeout : MESSAGE_LOCK_TIMEOUT;
        const ids = messagesToIdArray(message);

        return await client.modifyAckDeadline({subscription, ackIds: ids, ackDeadlineSeconds});
    }

I'm seeing this as well. By not doing modifyAckDeadline no duplicate is generated.
Do we even need to use this in userland? I believe I read somewhere that the convenience client will keep extending for you?


Failed to register dimension crash

Upon using the mod with many other mods I have found that another dimension is registered with the ID of -2 so I was wondering if you could provide an update to change this dimension id to be something else.
Thanks in advance :smile:
Here is the crash in case you want it
crash-2016-12-15_17.09.49-client.txt

There is an option in the AdvancedRocketry config to change the dimId for use for space stations.  See if changing the config option "spaceStationId" to some other value works for you.

Sorry I didn't notice that :smile:

It's fine.  If that works feel free to close the issue, if not let me know so I can see what's wrong,


[BUG] volume is stuck in attaching/detaching loop with error Failed to init frontend: device...

Volume stuck in attaching/detaching loop with the error:
2022-11-24T11:26:30.985743332Z tgtd: target_mgmt(147) Failed to unbind by address: ALL
Failed to init frontend: device pvc-3b45d723-d8fa-4c75-b334-0508faa92ea0: fail to delete target iqn.2019-10.io.longhorn:pvc-3b45d723-d8fa-4c75-b334-0508faa92ea0

From Longhorn engine, the error tgtd: target_mgmt(147) Failed to unbind by address: ALL comes from this function call
From the tgtadm, it comes from this line of code. Digging deeper we can see that it was probably there is no tgt target with the corresponding target id at here
@innobead and I feel like we shouldn't error out when trying to unbind while tgt target does not exist. However, we will need to investigate more and try to reproduce the issue

cc @shuo-wu @derekbit @joshimoo

root@instance-manager-e-6a2937ea:/# tgtadm --lld iscsi --op show --mode target
Target 1: iqn.2019-10.io.longhorn:pvc-3b45d723-d8fa-4c75-b334-0508faa92ea0
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
        I_T nexus: 1
            Initiator: iqn.1994-05.com.redhat:84a88f6477d0 alias: si0vm06569
            Connection: 0
                IP Address: <IP_ADDRESS>
        I_T nexus: 2
            Initiator: iqn.1994-05.com.redhat:84a88f6477d0 alias: si0vm06569
            Connection: 0
                IP Address: <IP_ADDRESS>
        I_T nexus: 3
            Initiator: iqn.1994-05.com.redhat:84a88f6477d0 alias: si0vm06569
            Connection: 0
                IP Address: <IP_ADDRESS>
        I_T nexus: 4
            Initiator: iqn.1994-05.com.redhat:84a88f6477d0 alias: si0vm06569
            Connection: 0
                IP Address: <IP_ADDRESS>
        I_T nexus: 5
            Initiator: iqn.1994-05.com.redhat:84a88f6477d0 alias: si0vm06569
            Connection: 0
                IP Address: <IP_ADDRESS>
        I_T nexus: 6
            Initiator: iqn.1994-05.com.redhat:84a88f6477d0 alias: si0vm06569
            Connection: 0
                IP Address: <IP_ADDRESS>
        I_T nexus: 7
            Initiator: iqn.1994-05.com.redhat:84a88f6477d0 alias: si0vm06569
            Connection: 0
                IP Address: <IP_ADDRESS>
        I_T nexus: 8
            Initiator: iqn.1994-05.com.redhat:84a88f6477d0 alias: si0vm06569
            Connection: 0
                IP Address: <IP_ADDRESS>
        I_T nexus: 9
            Initiator: iqn.1994-05.com.redhat:84a88f6477d0 alias: si0vm06569
            Connection: 0
                IP Address: <IP_ADDRESS>
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: null
            Backing store path: None
            Backing store flags:
        LUN: 1
            Type: disk
            SCSI ID: IET     00010001
            SCSI SN: beaf11
            Size: 1074 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: longhorn
            Backing store path: /var/run/longhorn-pvc-3b45d723-d8fa-4c75-b334-0508faa92ea0.sock
            Backing store flags:
    Account information:
    ACL information:
root@instance-manager-e-6a2937ea:/#

The old TGT target is actually still here (with the id 1) as shown in the output.  One thing to notice is that the ACL information is already empty which means that this UnbindInitiator function call already succeeded once before. Now Longhorn retries the function call with the empty ACL information . This will always error out. I am able to reproduce this issue. This seems a bug in Longhorn volume shutdown/startup procedure.

RCA:

Before a new attachment, Longhorn tries to clean up the old TGT target with the same name.
Deleting the old TGT target means calling the function DeleteTarget. Within this function, somehow UnbindInitiator function call succeeded (ACL information becomes empty) but then there is a transient error in the rest of the shutdown flow.
Because the first attachment failed, Longhorn retries the 2nd time. However, since the ACL information is already empty, UnbindInitiator function call always fails. This prevents the cleanup which then prevents the 2nd attachment. This cycle repeated again and again

Reproduce steps:

Create a Longhorn volume, testvol
Attach the Longhorn volume to a node, say node-1
Find the instance manager e pod on node-1
kubectl exec into the above instance manager e pod
List all the targets:

root@instance-manager-e-3382c653:/# tgtadm --lld iscsi --op show --mode target
Target 1: iqn.2019-10.io.longhorn:testvol
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
        I_T nexus: 1
            Initiator: iqn.1993-08.org.debian:01:5e999e2fae73 alias: phan-v190-pool2-66ea5213-hjpfg
            Connection: 0
                IP Address: <IP_ADDRESS>
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: null
            Backing store path: None
            Backing store flags:
        LUN: 1
            Type: disk
            SCSI ID: IET     00010001
            SCSI SN: beaf11
            Size: 5369 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: longhorn
            Backing store path: /var/run/longhorn-testvol.sock
            Backing store flags:
    Account information:
    ACL information:
        ALL

Manually unbind the initiator from the access control list (which is a part of the shutdown flow)

root@instance-manager-e-3382c653:/# tgtadm --lld iscsi --op unbind --mode target --tid 1 -I ALL

List all the targets again, notice that ACL information  is empty this time
If we try to unbind again with empty ACL information , we will always get error:

root@instance-manager-e-3382c653:/# tgtadm --lld iscsi --op unbind --mode target --tid 1 -I ALL
tgtadm: this access control rule does not exist
root@instance-manager-e-3382c653:/# echo $?
22

Detach the volume
Attach the volume.
Observe that the volume is stuck in attaching/detaching loop. Same as what customers experiencing:

[instance-manager-e-3382c653] [testvol-e-7c714976] time="2022-11-29T20:34:16Z" level=info msg="Shutdown SCSI target iqn.2019-10.io.longhorn:testvol"
[instance-manager-e-3382c653] tgtd: target_mgmt(147) Failed to unbind by address: ALL
[instance-manager-e-3382c653] [testvol-e-7c714976] time="2022-11-29T20:34:16Z" level=error msg="Failed to init frontend: device testvol: fail to delete target iqn.2019-10.io.longhorn:testvol"
...

---
Workaround:

Note down the current attaching NodeID

kubectl get volumes.longhorn.io <volume-name> -n longhorn-system
# note down the spec.nodeID

Detach the volume by scaling down the workload pods that are using the volume
kubectl exec into the instance manager e pod on the spec.nodeID above
Find the TGT target id corresponding to the volume:

root@instance-manager-e-3382c653:/# tgtadm --lld iscsi --op show --mode target
Target 1: iqn.2019-10.io.longhorn:testvol
    System information:
        Driver: iscsi
        State: ready
...
# in this case, the TGT target id is 1

Try to bind the missing initiator:

tgtadm --lld iscsi --op bind --mode target --tid <TGT-ID-FROM_ABOVE-STEP> -I ALL

scale up the workload again. Volume should be able to attach

tgtadm return codes.
https://github.com/fujita/tgt/blob/master/usr/tgtadm.c#L56-L87

Assigned @PhanLe1010 here, because he was working on the analysis, but @derekbit will do the rest of the implementation. Thanks, both.

Verified in longhorn master 0e56cd with test steps
Result Pass
I can reproduce the detach attach loop by deploying previous version of engine image. After using latest engine image,  when ACL information become empty in instance manager e pod , do volume detach attach operation, volume can successfully attached and become healthy.

Verified in longhorn master 0e56cd with test steps Result Pass
I can reproduce the detach attach loop by deploying previous version of engine image. After using latest engine image, when ACL information become empty in instance manager e pod , do volume detach attach operation, volume can successfully attached and become healthy.

root@instance-manager-e-6a2937ea:/# tgtadm --lld iscsi --op show --mode target
Target 1: iqn.2019-10.io.longhorn:pvc-3b45...a92ea0
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
        I_T nexus: 1
           ...
        I_T nexus: 2
          ...
        I_T nexus: 3
           ...
        I_T nexus: 4
           ...
        I_T nexus: 5
           ...
        I_T nexus: 6
           ...
        I_T nexus: 7
          ...
        I_T nexus: 8
           ...
        I_T nexus: 9
            ...
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: null
            Backing store path: None
            Backing store flags:
        LUN: 1
            Type: disk
            SCSI ID: IET     00010001
            SCSI SN: beaf11
            Size: 1074 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: longhorn
            Backing store path: /var/run/longhorn-pvc-3b45d...92ea0.sock
            Backing store flags:
    Account information:
    ACL information:
root@instance-manager-e-6a2937ea:/#

The old TGT target is actually still here (with the id 1) as shown in the output. One thing to notice is that the ACL information is already empty which means that this UnbindInitiator function call already succeeded once before. Now Longhorn retries the function call with the empty ACL information . This will always error out. I am able to reproduce this issue. This seems a bug in Longhorn volume shutdown/startup procedure.旧的TGT目标实际上仍然在这里（id为1），如输出所示。 需要注意的一点是，ACL information已经为空，这意味着这个UnbindInitiator函数调用已经成功过一次。现在Longhorn用空的ACL information重试函数调用。这将始终出错。我可以重现这个问题。这似乎是Longhorn卷关闭/启动过程中的一个错误。
RCA:RCA：
1. Before a new attachment, Longhorn tries to clean up the old TGT target with the same name.在创建新的附件之前，Longhorn会尝试清除同名的旧TGT目标。

2. Deleting the old TGT target means calling the function [DeleteTarget](https://github.com/longhorn/longhorn-engine/blob/d9b87bed2172b93ab463287d33f988bba67d441c/vendor/github.com/longhorn/go-iscsi-helper/iscsidev/iscsi.go#L230). Within this function, somehow [UnbindInitiator](https://github.com/longhorn/longhorn-engine/blob/d9b87bed2172b93ab463287d33f988bba67d441c/vendor/github.com/longhorn/go-iscsi-helper/iscsidev/iscsi.go#L236) function call succeeded (`ACL information` becomes empty) but then there is a transient error in [the rest of the shutdown flow](https://github.com/longhorn/longhorn-engine/blob/d9b87bed2172b93ab463287d33f988bba67d441c/vendor/github.com/longhorn/go-iscsi-helper/iscsidev/iscsi.go#L240-L258).删除旧的TGT目标意味着调用函数[DeleteTarget](https://github.com/longhorn/longhorn-engine/blob/d9b87bed2172b93ab463287d33f988bba67d441c/vendor/github.com/longhorn/go-iscsi-helper/iscsidev/iscsi.go#L230)。在此函数中，[UnbindInitiator](https://github.com/longhorn/longhorn-engine/blob/d9b87bed2172b93ab463287d33f988bba67d441c/vendor/github.com/longhorn/go-iscsi-helper/iscsidev/iscsi.go#L236)函数调用成功（`ACL information`变为空），但随后在关闭流的其余部分中出现暂时性错误。

3. Because the first attachment failed, Longhorn retries the 2nd time. However, since the `ACL information` is already empty, [UnbindInitiator](https://github.com/longhorn/longhorn-engine/blob/d9b87bed2172b93ab463287d33f988bba67d441c/vendor/github.com/longhorn/go-iscsi-helper/iscsidev/iscsi.go#L236) function call always fails. This prevents the cleanup which then prevents the 2nd attachment. This cycle repeated again and again由于第一次连接失败，Longhorn重试第二次。但是，由于`ACL information`已经为空，因此[UnbindInitiator](https://github.com/longhorn/longhorn-engine/blob/d9b87bed2172b93ab463287d33f988bba67d441c/vendor/github.com/longhorn/go-iscsi-helper/iscsidev/iscsi.go#L236)函数调用总是失败。这阻止了清理，然后阻止了第二次附接。这样的循环周而复始

Reproduce steps:重现步骤：
1. Create a Longhorn volume, `testvol`创建Longhorn卷，`testvol`

2. Attach the Longhorn volume to a node, say `node-1`将Longhorn卷连接到一个节点，例如`node-1`

3. Find the instance manager e pod on `node-1`在`node-1`上找到实例管理器e pod

4. kubectl exec into the above instance manager e podkubectl exec到上面的实例管理器e pod中

5. List all the targets:列出所有目标：

root@instance-manager-e-3382c653:/# tgtadm --lld iscsi --op show --mode target
Target 1: iqn.2019-10.io.longhorn:testvol
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
        I_T nexus: 1
            Initiator: iqn.1993-08.org.debian:01:5e999e2fae73 alias: phan-v190-pool2-66ea5213-hjpfg
            Connection: 0
                IP Address: <IP_ADDRESS>
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: null
            Backing store path: None
            Backing store flags:
        LUN: 1
            Type: disk
            SCSI ID: IET     00010001
            SCSI SN: beaf11
            Size: 5369 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: longhorn
            Backing store path: /var/run/longhorn-testvol.sock
            Backing store flags:
    Account information:
    ACL information:
        ALL

6. Manually unbind the initiator from the access control list (which is a part of the shutdown flow)手动解除启动器与访问控制列表的绑定（这是关闭流的一部分）

root@instance-manager-e-3382c653:/# tgtadm --lld iscsi --op unbind --mode target --tid 1 -I ALL

7. List all the targets again, notice that `ACL information`  is empty this time再次列出所有目标，注意这次`ACL information`为空

8. If we try to unbind again with empty `ACL information` , we will always get error:如果我们再次尝试使用空的`ACL information`解除绑定，我们总是会得到错误：

root@instance-manager-e-3382c653:/# tgtadm --lld iscsi --op unbind --mode target --tid 1 -I ALL
tgtadm: this access control rule does not exist
root@instance-manager-e-3382c653:/# echo $?
22

9. Detach the volume分离卷

10. Attach the volume.连接卷。

11. Observe that the volume is stuck in attaching/detaching loop. Same as what customers experiencing:观察体积卡在连接/分离环中。

Workaround:解决方法：
1. Note down the current attaching NodeID记下当前附加的NodeID

kubectl get volumes.longhorn.io <volume-name> -n longhorn-system
# note down the spec.nodeID

2. Detach the volume by scaling down the workload pods that are using the volume通过缩小正在使用卷的工作负载Pod来分离卷

3. kubectl exec into the instance manager e pod on the `spec.nodeID` abovekubectl exec到上面`spec.nodeID`的实例管理器e pod中

4. Find the TGT target id corresponding to the volume:查找与卷对应的TGT目标ID：

root@instance-manager-e-3382c653:/# tgtadm --lld iscsi --op show --mode target
Target 1: iqn.2019-10.io.longhorn:testvol
    System information:
        Driver: iscsi
        State: ready
...
# in this case, the TGT target id is 1

5. Try to bind the missing initiator:尝试绑定缺少的启动器：

tgtadm --lld iscsi --op bind --mode target --tid <TGT-TARGET-ID-FROM_ABOVE-STEP> -I ALL

6. Scale up the workload again. Volume should be able to attach再次扩展工作负载。卷应该能够连接

I used the tgtadm -- lld iscsi -- op bind -- mode target -- tid 7- I ALL command to add ACL information, and then restarted the container. However, I still couldn't mount the volume or was in an infinite loop of connection separation

Verified in longhorn master 0e56cd with test steps Result Pass
I can reproduce the detach attach loop by deploying previous version of engine image. After using latest engine image, when ACL information become empty in instance manager e pod , do volume detach attach operation, volume can successfully attached and become healthy.

root@instance-manager-e-6a2937ea:/# tgtadm --lld iscsi --op show --mode target
Target 1: iqn.2019-10.io.longhorn:pvc-3b45...a92ea0
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
        I_T nexus: 1
           ...
        I_T nexus: 2
          ...
        I_T nexus: 3
           ...
        I_T nexus: 4
           ...
        I_T nexus: 5
           ...
        I_T nexus: 6
           ...
        I_T nexus: 7
          ...
        I_T nexus: 8
           ...
        I_T nexus: 9
            ...
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: null
            Backing store path: None
            Backing store flags:
        LUN: 1
            Type: disk
            SCSI ID: IET     00010001
            SCSI SN: beaf11
            Size: 1074 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: longhorn
            Backing store path: /var/run/longhorn-pvc-3b45d...92ea0.sock
            Backing store flags:
    Account information:
    ACL information:
root@instance-manager-e-6a2937ea:/#

The old TGT target is actually still here (with the id 1) as shown in the output. One thing to notice is that the ACL information is already empty which means that this UnbindInitiator function call already succeeded once before. Now Longhorn retries the function call with the empty ACL information . This will always error out. I am able to reproduce this issue. This seems a bug in Longhorn volume shutdown/startup procedure.旧的TGT目标实际上仍然在这里（id为1），如输出所示。 需要注意的一点是，ACL information已经为空，这意味着这个UnbindInitiator函数调用已经成功过一次。现在Longhorn用空的ACL information重试函数调用。这将始终出错。我可以重现这个问题。这似乎是Longhorn卷关闭/启动过程中的一个错误。
RCA:RCA：
1. Before a new attachment, Longhorn tries to clean up the old TGT target with the same name.在创建新的附件之前，Longhorn会尝试清除同名的旧TGT目标。

2. Deleting the old TGT target means calling the function [DeleteTarget](https://github.com/longhorn/longhorn-engine/blob/d9b87bed2172b93ab463287d33f988bba67d441c/vendor/github.com/longhorn/go-iscsi-helper/iscsidev/iscsi.go#L230). Within this function, somehow [UnbindInitiator](https://github.com/longhorn/longhorn-engine/blob/d9b87bed2172b93ab463287d33f988bba67d441c/vendor/github.com/longhorn/go-iscsi-helper/iscsidev/iscsi.go#L236) function call succeeded (`ACL information` becomes empty) but then there is a transient error in [the rest of the shutdown flow](https://github.com/longhorn/longhorn-engine/blob/d9b87bed2172b93ab463287d33f988bba67d441c/vendor/github.com/longhorn/go-iscsi-helper/iscsidev/iscsi.go#L240-L258).删除旧的TGT目标意味着调用函数[DeleteTarget](https://github.com/longhorn/longhorn-engine/blob/d9b87bed2172b93ab463287d33f988bba67d441c/vendor/github.com/longhorn/go-iscsi-helper/iscsidev/iscsi.go#L230)。在此函数中，[UnbindInitiator](https://github.com/longhorn/longhorn-engine/blob/d9b87bed2172b93ab463287d33f988bba67d441c/vendor/github.com/longhorn/go-iscsi-helper/iscsidev/iscsi.go#L236)函数调用成功（`ACL information`变为空），但随后在关闭流的其余部分中出现暂时性错误。

3. Because the first attachment failed, Longhorn retries the 2nd time. However, since the `ACL information` is already empty, [UnbindInitiator](https://github.com/longhorn/longhorn-engine/blob/d9b87bed2172b93ab463287d33f988bba67d441c/vendor/github.com/longhorn/go-iscsi-helper/iscsidev/iscsi.go#L236) function call always fails. This prevents the cleanup which then prevents the 2nd attachment. This cycle repeated again and again由于第一次连接失败，Longhorn重试第二次。但是，由于`ACL information`已经为空，因此[UnbindInitiator](https://github.com/longhorn/longhorn-engine/blob/d9b87bed2172b93ab463287d33f988bba67d441c/vendor/github.com/longhorn/go-iscsi-helper/iscsidev/iscsi.go#L236)函数调用总是失败。这阻止了清理，然后阻止了第二次附接。这样的循环周而复始

Reproduce steps:重现步骤：
1. Create a Longhorn volume, `testvol`创建Longhorn卷，`testvol`

2. Attach the Longhorn volume to a node, say `node-1`将Longhorn卷连接到一个节点，例如`node-1`

3. Find the instance manager e pod on `node-1`在`node-1`上找到实例管理器e pod

4. kubectl exec into the above instance manager e podkubectl exec到上面的实例管理器e pod中

5. List all the targets:列出所有目标：

root@instance-manager-e-3382c653:/# tgtadm --lld iscsi --op show --mode target
Target 1: iqn.2019-10.io.longhorn:testvol
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
        I_T nexus: 1
            Initiator: iqn.1993-08.org.debian:01:5e999e2fae73 alias: phan-v190-pool2-66ea5213-hjpfg
            Connection: 0
                IP Address: <IP_ADDRESS>
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: null
            Backing store path: None
            Backing store flags:
        LUN: 1
            Type: disk
            SCSI ID: IET     00010001
            SCSI SN: beaf11
            Size: 5369 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            SWP: No
            Thin-provisioning: No
            Backing store type: longhorn
            Backing store path: /var/run/longhorn-testvol.sock
            Backing store flags:
    Account information:
    ACL information:
        ALL

6. Manually unbind the initiator from the access control list (which is a part of the shutdown flow)手动解除启动器与访问控制列表的绑定（这是关闭流的一部分）

root@instance-manager-e-3382c653:/# tgtadm --lld iscsi --op unbind --mode target --tid 1 -I ALL

7. List all the targets again, notice that `ACL information`  is empty this time再次列出所有目标，注意这次`ACL information`为空

8. If we try to unbind again with empty `ACL information` , we will always get error:如果我们再次尝试使用空的`ACL information`解除绑定，我们总是会得到错误：

root@instance-manager-e-3382c653:/# tgtadm --lld iscsi --op unbind --mode target --tid 1 -I ALL
tgtadm: this access control rule does not exist
root@instance-manager-e-3382c653:/# echo $?
22

9. Detach the volume分离卷

10. Attach the volume.连接卷。

11. Observe that the volume is stuck in attaching/detaching loop. Same as what customers experiencing:观察体积卡在连接/分离环中。

Workaround:解决方法：
1. Note down the current attaching NodeID记下当前附加的NodeID

kubectl get volumes.longhorn.io <volume-name> -n longhorn-system
# note down the spec.nodeID

2. Detach the volume by scaling down the workload pods that are using the volume通过缩小正在使用卷的工作负载Pod来分离卷

3. kubectl exec into the instance manager e pod on the `spec.nodeID` abovekubectl exec到上面`spec.nodeID`的实例管理器e pod中

4. Find the TGT target id corresponding to the volume:查找与卷对应的TGT目标ID：

root@instance-manager-e-3382c653:/# tgtadm --lld iscsi --op show --mode target
Target 1: iqn.2019-10.io.longhorn:testvol
    System information:
        Driver: iscsi
        State: ready
...
# in this case, the TGT target id is 1

5. Try to bind the missing initiator:尝试绑定缺少的启动器：

tgtadm --lld iscsi --op bind --mode target --tid <TGT-TARGET-ID-FROM_ABOVE-STEP> -I ALL

6. Scale up the workload again. Volume should be able to attach再次扩展工作负载。卷应该能够连接

I used the tgtadm -- lld iscsi -- op bind -- mode target -- tid 7- I ALL command to add ACL information, and then restarted the container. However, I still couldn't mount the volume or was in an infinite loop of connection separation

Can I directly delete this tgt ID information？

Why is this closed? The bug still persists.


x/pkgsite: Please remove this deprecated package

What did you expect to see?
Please remove this unused deprecated package.
URL : https://pkg.go.dev/github.com/MohamedBRH/ray-operator

Done.


Add configurable group track names

The mapping of Omaha track to a group ID was hardcoded for the stable,
beta, alpha, and edge channel using only the initial the group IDs.
When the groups were recreated, resolving the track was broken and then
the groups always had to use the group ID as track which is confusing.
For user-created groups there should be a way to add a track name.
Add track name fields to the groups and expose them in the UI. The
track names are optional but if used, should be unique in combination
with the channel architecture. The original behavior is preserved
meaning that when a track name couldn't be resolved it is assumed to
be a group UUID.
Closes https://github.com/kinvolk/nebraska/issues/286
Replaces https://github.com/kinvolk/nebraska/pull/284
I realize that the UI doesn't explain at all what these group UUIDs strings are. Since I added displaying the track name there, too, I think we could also rework this to have a proper label like Group UUID and optional track name: … but currently Card.js is shared between Applications and Groups.

The CI generates a different bindata Go file. Can somebody reproduce this?
(Such behavior is one reason why I don't like to have computer-generated stuff be committed…)

the Makefile for this has too many .PHONY and ought to do a little more for detecting changes...
anyways, when running make backend && git diff locally (with go1.15.3):
diff --git a/pkg/api/bindata.go b/pkg/api/bindata.go
index 987bea0..002ffc6 100644
--- a/pkg/api/bindata.go
+++ b/pkg/api/bindata.go
@@ -94,7 +94,7 @@ func dbDrop_all_tablesSql() (*asset, error) {
                return nil, err
        }

-       info := bindataFileInfo{name: "db/drop_all_tables.sql", size: 781, mode: os.FileMode(0644), modTime: time.Unix(1, 0)}
+       info := bindataFileInfo{name: "db/drop_all_tables.sql", size: 781, mode: os.FileMode(0664), modTime: time.Unix(1, 0)}
        a := &asset{bytes: bytes, info: info, digest: [32]uint8{0xde, 0xcf, 0xbe, 0xfb, 0xd5, 0xe3, 0xea, 0xab, 0xec, 0x78, 0x43, 0x41, 0x2, 0x31, 0xfc, 0x52, 0x9a, 0x8b, 0x30, 0x84, 0xc8, 0xab, 0x83, 0x9c, 0x5b, 0x64, 0xf8, 0xbe, 0xbc, 0xfd, 0x0, 0x97}}
        return a, nil
 }
@@ -114,7 +114,7 @@ func dbSample_dataSql() (*asset, error) {
                return nil, err
        }

-       info := bindataFileInfo{name: "db/sample_data.sql", size: 15819, mode: os.FileMode(0644), modTime: time.Unix(1, 0)}
+       info := bindataFileInfo{name: "db/sample_data.sql", size: 15819, mode: os.FileMode(0664), modTime: time.Unix(1, 0)}
        a := &asset{bytes: bytes, info: info, digest: [32]uint8{0x33, 0xc, 0x4c, 0x4c, 0x3, 0xb6, 0xaf, 0x7d, 0x14, 0x8b, 0xa6, 0x97, 0xe4, 0x22, 0xfd, 0xa3, 0x37, 0xdb, 0xb7, 0xf9, 0xa8, 0xbb, 0x94, 0xbe, 0x5e, 0xd3, 0x92, 0xab, 0xfe, 0xe5, 0x7e, 0x87}}
        return a, nil
 }
@@ -134,7 +134,7 @@ func dbMigrations0001_initialSql() (*asset, error) {
                return nil, err
        }

-       info := bindataFileInfo{name: "db/migrations/0001_initial.sql", size: 7125, mode: os.FileMode(0644), modTime: time.Unix(1, 0)}
+       info := bindataFileInfo{name: "db/migrations/0001_initial.sql", size: 7125, mode: os.FileMode(0664), modTime: time.Unix(1, 0)}
        a := &asset{bytes: bytes, info: info, digest: [32]uint8{0x3e, 0x34, 0xf7, 0x7a, 0x71, 0x9b, 0x8b, 0x7b, 0xc6, 0x47, 0x8a, 0x1b, 0x3e, 0xb5, 0xb5, 0x2f, 0x29, 0xf5, 0xc3, 0xce, 0x5b, 0x2f, 0xc1, 0xd8, 0xdd, 0x23, 0xa0, 0x20, 0x34, 0x50, 0x6, 0x9f}}
        return a, nil
 }
@@ -154,7 +154,7 @@ func dbMigrations0002_event_dataSql() (*asset, error) {
                return nil, err
        }

-       info := bindataFileInfo{name: "db/migrations/0002_event_data.sql", size: 729, mode: os.FileMode(0644), modTime: time.Unix(1, 0)}
+       info := bindataFileInfo{name: "db/migrations/0002_event_data.sql", size: 729, mode: os.FileMode(0664), modTime: time.Unix(1, 0)}
        a := &asset{bytes: bytes, info: info, digest: [32]uint8{0x93, 0xe9, 0x46, 0x83, 0xf5, 0x9c, 0x90, 0x5b, 0xa7, 0xd8, 0xdf, 0xb6, 0xb9, 0xf4, 0x9e, 0x1a, 0x6b, 0x5f, 0x66, 0x58, 0x61, 0xb9, 0x54, 0x3c, 0x93, 0x3b, 0xd9, 0x5b, 0xae, 0xf, 0x92, 0x8f}}
        return a, nil
 }
@@ -174,7 +174,7 @@ func dbMigrations0003_longer_team_namesSql() (*asset, error) {
                return nil, err
        }

-       info := bindataFileInfo{name: "db/migrations/0003_longer_team_names.sql", size: 142, mode: os.FileMode(0644), modTime: time.Unix(1, 0)}
+       info := bindataFileInfo{name: "db/migrations/0003_longer_team_names.sql", size: 142, mode: os.FileMode(0664), modTime: time.Unix(1, 0)}
        a := &asset{bytes: bytes, info: info, digest: [32]uint8{0xea, 0xbb, 0x50, 0xf, 0x77, 0x25, 0x2e, 0xe6, 0x66, 0x6, 0x9c, 0xed, 0x44, 0xb2, 0x8a, 0xa6, 0x3c, 0xe7, 0xef, 0xb2, 0x49, 0x4, 0x81, 0x57, 0xc7, 0x6d, 0x91, 0x47, 0xe, 0xba, 0xb0, 0x57}}
        return a, nil
 }
@@ -194,7 +194,7 @@ func dbMigrations0004_rename_coreos_actionSql() (*asset, error) {
                return nil, err
        }

-       info := bindataFileInfo{name: "db/migrations/0004_rename_coreos_action.sql", size: 139, mode: os.FileMode(0644), modTime: time.Unix(1, 0)}
+       info := bindataFileInfo{name: "db/migrations/0004_rename_coreos_action.sql", size: 139, mode: os.FileMode(0664), modTime: time.Unix(1, 0)}
        a := &asset{bytes: bytes, info: info, digest: [32]uint8{0x3c, 0x8b, 0xdd, 0x9e, 0x19, 0x1e, 0xdd, 0xa3, 0xd6, 0x9c, 0x2d, 0x5, 0x74, 0xe6, 0x9c, 0x1, 0xac, 0xde, 0x80, 0x9b, 0xa1, 0xb, 0xa8, 0xe2, 0xa4, 0x70, 0x48, 0x9b, 0xed, 0xe5, 0xae, 0xc6}}
        return a, nil
 }
@@ -214,7 +214,7 @@ func dbMigrations0005_default_team_idSql() (*asset, error) {
                return nil, err
        }

-       info := bindataFileInfo{name: "db/migrations/0005_default_team_id.sql", size: 333, mode: os.FileMode(0644), modTime: time.Unix(1, 0)}
+       info := bindataFileInfo{name: "db/migrations/0005_default_team_id.sql", size: 333, mode: os.FileMode(0664), modTime: time.Unix(1, 0)}
        a := &asset{bytes: bytes, info: info, digest: [32]uint8{0x19, 0xdb, 0x8b, 0x9, 0xd, 0x3e, 0x9f, 0x64, 0xf9, 0x8f, 0x94, 0xe1, 0xf7, 0x95, 0x28, 0x12, 0xe7, 0xe6, 0x39, 0x30, 0xda, 0x5c, 0x68, 0x3d, 0x1f, 0xd0, 0xcd, 0x82, 0xd0, 0x8c, 0x4c, 0x52}}
        return a, nil
 }
@@ -234,7 +234,7 @@ func dbMigrations0006_initial_applicationSql() (*asset, error) {
[...]

and https://github.com/kinvolk/nebraska/pull/294 fixes that mode change

You can rebase on master now

Thanks, ah, one of these errors again, good to have it fixed.

I will review this tomorrow. Sorry I wwas busy today.


Data Collection: Twitter not appearing

code adjusted and checked in to add toggle since text change event was not triggering properly


⚠ Bofrost.at has degraded performance

In 98daa22, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1093 ms

Resolved: Bofrost.at performance has improved in 163894d after 7 minutes.


Neutral loss

Subset of #156

Notes after discussion with D:

http://www.colby.edu/chemistry/PChem/StableLoss.html has a list of commonly lost molecules
The molecules on METASPACE tend to have neutral losses less often because they're smaller
There's no easy way to describe the sum formula format we use for molecules in METASPACE, so only providing free-text input could be problematic if we can't parse formulas. A pre-set list showing the regular molecular formula would be best to minimize confusion, with an option to provide manual input as a last resort
We should note that choosing specific isotopes is not supported (e.g. 37Cl mentioned in the above link)
People usually only check for neutral loss if they can't find something they expect

To minimize unnecessary use of processing power it is probably acceptable to disable scanning for neutral losses in the initial upload.
People guess which molecule(s) may have been lost based on knowledge of the molecule structure & intuition
An interface that would allow searching for singular molecules combined with a neutral loss would be much more helpful than having to reprocess the whole dataset

Annotations with neutral losses will certainly cause more noise than signal - it would be a good idea to filter them out by default

Current thought: We measure FDR by comparing M + [Plausible Adduct] vs M + [Implausible Adduct]. Our current plan to combine the neutral loss with the adduct might invalidate the measured FDR, because we'd be calculating M + [Plausible Adduct] - [Neutral Molecule] vs M + [Implausible Adduct], when we should instead be calculating against M + [Implausible Adduct] - [Neutral Molecule].

Superceded by concrete tasks #312 and #313


test: a

Codecov Report

Merging #779 (4e2d29d) into main (80395a4) will decrease coverage by 0.02%.
The diff coverage is n/a.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
@@            Coverage Diff             @@
##             main     #779      +/-   ##
==========================================
- Coverage   92.52%   92.50%   -0.02%
==========================================
  Files         154      154
  Lines        6272     6272
==========================================
- Hits         5803     5802       -1
- Misses        469      470       +1

Flag
Coverage Δ

unittests
92.50% <ø> (-0.02%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.
see 1 file with indirect coverage changes


RestClient::InternalServerError: 500 Internal Server Error

Check full details on Airbrake: #1517395850977326862
Backtrace:
[GEM_ROOT]/gems/rest-client-1.6.7/lib/restclient/abstract_response.rb:48:in return!
 Here's the ETE log:
I, [2015-09-25T16:34:40.071570 #32079]  INFO -- : Processing by Api::V3::ConvertersController#stats as JSON
I, [2015-09-25T16:34:40.072162 #32079]  INFO -- :   Parameters: {"keys"=>["households_solar_pv_solar_radiation", "households_space_heater_heatpump_air_water_electricity", "households_space_heater_heatpump_ground_water_electricity", "households_water_heater_heatpump_air_water_electricity", "households_water_heater_heatpump_ground_water_electricity", "transport_car_using_electricity", "households_flexibility_p2p_electricity", "energy_flexibility_p2g_electricity", "households_flexibility_p2h_electricity", "base_load", "generic", "base_load_buildings", "base_load_edsn"], "scenario_id"=>"405671"}
I, [2015-09-25T16:34:40.204906 #32079]  INFO -- : Completed 500 Internal Server Error in 133ms
I, [2015-09-25T16:34:40.820713 #32079]  INFO -- : ** [Airbrake] Success: Net::HTTPOK
F, [2015-09-25T16:34:40.823656 #32079] FATAL -- :
NoMethodError (undefined method `converter_api' for nil:NilClass):
  app/models/api/v3/converter_stats_presenter.rb:20:in `initialize'
  app/controllers/api/v3/converters_controller.rb:33:in `new'
  app/controllers/api/v3/converters_controller.rb:33:in `block in stats'
  app/controllers/api/v3/converters_controller.rb:32:in `map'
  app/controllers/api/v3/converters_controller.rb:32:in `stats'

Maybe this migration, which would have added an importable attribute to all techs, not just those in ETEngine?


Adding continued_pretraining task

As discussed internally, it could be very valuable to expand the alignment handbook with a prior step to sft/dpo, namely continued pretraining. This is especially useful when doing domain or language adaptation of a language model.
The main contribution is the addition of the run_continued_pretraining.py script, as suggested by @lewtun. (A shorter alternative could be cpt, although that is not a well-known abbreviation.) It is very similar to the run_sft.py script with only minor changes to ensure that no chat templating is needed. We can even re-use the SFTConfig class for setting hyperparameters (especially sequence length). I've also ensured that the eval dataset is allowed to be optional but that a training set must always be present.
One question: I am not sure about how the SFTTrainer deals with truncation. My assumption is that the code now will simply truncate long samples but we'd likely want something that does not throw so much data away, like with the run_clm.py script over at transformers, where the data is first tokenized (no truncation) and then grouped in block_size items. I did not currently implement this because I wasn't sure what the best approach would be, considering the SFTTrainer does the packing and such under the hood, which amy already be covering this?
There are also two changes that are related to the existing scripts:

model_utils.get_tokenizer now has an auto_set_chat_template (default: True). In SFT/DPO we always want to make sure that the tokenizer has a chat_template set, so this function used to automatically set a default template if the tokenizer did not have one yet. However, during continued pretraining we do not want to set that chat template yet, so this automatic step should be skippable. When running the run_continued_pretraining.py script, get_tokenizer will have auto_set_chat_template=False for this reason. Since True is the default value, nothing changes for the sft/dpo scripts.
the option to specify dataset_configs is added to all scripts. With a new data_arguments.dataset_configs, a user can specify which config to use for which dataset. If not given, will use None but otherwise the argument must be the same length as the number of datasets that are given in the dataset mixer. So if you specify to use two datasets, your dataset_configs must also contain two items, one for each dataset. (Or it can of course be left out.)

An example recipe is added for language adapting gpt2 to Dutch. I ran the scripts so I can verify that they work, but I did not do any hyperparameter optimisation and the output model is quite bad (it's gpt2-small after all). But it serves as a guideline for users.

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

I'm not sure that I understand the point of this failing test or why it is failing (since the default case remains unchanged) so advice is welcome.

Thanks for iterating! Excited to see what the community does with this for domains like code and math 🔥


upgrade to 1.3 breaks cpo200 lab

The same issue discussed here also affects the startup script in this repo.
The workaround is to get the previous version of the script.

Changed last line of script.


Rename validate functions

rename validate functions to describe its behavior

our validate functions return an error message. Previous naming was confusing because I'd expect it to return true if it's valid, but its functions return true if there's an error aka it returns an error message.

Preview is available here:http://laboratory-pr919.previews.kube001.services.stellar-ops.com/


Trying to use SNAPSHOT

When trying to use the SNAPSHOT I get this error during the Gradle sync. Any idea of how to fix it?
Error:Failed to resolve: com.apollographql.apollo:apollo-runtime:0.3.2-SNAPSHOT

Did you add
buildscript {
  repositories {
    jcenter()
    maven { url 'https://oss.sonatype.org/content/repositories/snapshots/' }
  }
  dependencies {
    classpath 'com.apollographql.apollo:gradle-plugin:0.3.2-SNAPSHOT'
  }
}

To your gradle file?

Yes

That very strange as if you go to https://oss.sonatype.org/content/repositories/snapshots/com/apollographql/apollo/apollo-runtime/
you can see it there.
Plus just verified on my sample app, it resolves this dep correctly.
So I would say look into your gradle build file.

I'll double check with the sample. Thanks


Fixed no feedback from widgets in disabled frames

This fixes the issue reported here: http://www.qlcplus.org/forum/viewtopic.php?f=33&t=10796
I'm still not sure if the use case is intended by QLC+, so if a disabled frame should send any feedback. But if it is considered as expected, we could simply use the visibility status of a widget in addition to the acceptsInput method (still needed for collapsed frames, in which the widgets are hidden).

This also fixes that no feedback is sent to the enable button when disabling the frame. So I assume it should be merged since it is more near the current behavior, too.
Mentioned here: http://www.qlcplus.org/forum/viewtopic.php?p=46699#p46699

Alright, let's merge this, even though I'm pretty sure it will make some users happy and some others not

Alright, let's merge this, even though I'm pretty sure it will make some users happy and some others not

Sure - but this applies to nearly every change. And this PR brought the behavior closer to the original one (before "Feedback from other pages" - fix).


Translate partners/_index.html in Korean.

This is a Feature Request
What would you like to be added
Translate partners/_index.html in Korean.
Why is this needed
The following files are not translated into Korean.

[ ] /en/partners/_index.html

Comments
Page to update: https://kubernetes.io/partners/
I am translating this document.
The translated document will be submitted to dev-1.18-ko.1 branch.
/language ko

/assign

/close


Add interface change for worker data server

What changes are proposed in this pull request?
Add interface change for worker data server
Why are the changes needed?
That is for the extension
Does this PR introduce any user facing changes?
NA

alluxio-bot, merge this please


From mjfet<PHONE_NUMBER>49961789):
<Add an Unsupported command so people can easily find the Supported/Unsupported list, along with repeating the rule about the unsupported distros in rules.>

From V.XLII Senhara | she/her<PHONE_NUMBER>36010755):
This is made redundant by the info supported command