Synthesis failed for nodejs-promisify

Hello! Autosynth couldn't regenerate nodejs-promisify. :broken_heart:
Here's the output from running synth.py:
2020-12-11 21:34:00,621 autosynth [INFO] > logs will be written to: /kokoro/artifacts/logs/nodejs-promisify
2020-12-11 21:34:01,248 autosynth [DEBUG] > Running: git config --global core.excludesfile /root/.autosynth-gitignore
2020-12-11 21:34:01,250 autosynth [DEBUG] > Running: git config user.name yoshi-automation
2020-12-11 21:34:01,253 autosynth [DEBUG] > Running: git config user.email<EMAIL_ADDRESS>2020-12-11 21:34:01,255 autosynth [DEBUG] > Running: git config push.default simple
2020-12-11 21:34:01,258 autosynth [DEBUG] > Running: git branch -f autosynth
2020-12-11 21:34:01,261 autosynth [DEBUG] > Running: git checkout autosynth
Switched to branch 'autosynth'
2020-12-11 21:34:01,267 autosynth [DEBUG] > Running: git rev-parse --show-toplevel
2020-12-11 21:34:01,269 autosynth [DEBUG] > Running: git log -1 --pretty=%H
2020-12-11 21:34:01,272 autosynth [DEBUG] > Running: git remote get-url origin
2020-12-11 21:34:01,937 autosynth [DEBUG] > Running: git log 15013eff642a7e7e855aed5a29e6e83c39beba2a..HEAD --pretty=%H --no-decorate
2020-12-11 21:34:01,940 autosynth [DEBUG] > Running: git log -1 --pretty=%at 15013eff642a7e7e855aed5a29e6e83c39beba2a
2020-12-11 21:34:01,943 autosynth [DEBUG] > Running: git log -1 --pretty=%at c2de32114ec484aa708d32012d1fa8d75232daf5
2020-12-11 21:34:01,946 autosynth [DEBUG] > Running: git log -1 --pretty=%at 32af6da519a6b042e3da62008e2a75e991efb6b4
2020-12-11 21:34:01,949 autosynth [DEBUG] > Running: git log -1 --pretty=%at 69629b64b83c6421d616be2b8e11795738ec8a6c
2020-12-11 21:34:01,953 autosynth [DEBUG] > Running: git log -1 --pretty=%at f94318521f63085b9ccb43d42af89f153fb39f15
2020-12-11 21:34:01,956 autosynth [DEBUG] > Running: git log -1 --pretty=%at 18c5dbdb4ac8cf75d4d8174e7b4558f48e76f8a1
2020-12-11 21:34:01,959 autosynth [DEBUG] > Running: git log -1 --pretty=%at 5d11bd2888c38ce1fb6fa6bf25494a4219a73928
2020-12-11 21:34:01,961 autosynth [DEBUG] > Running: git log -1 --pretty=%at 3559dd8cb634347737632776ef4089443eacdb4f
2020-12-11 21:34:01,964 autosynth [DEBUG] > Running: git log -1 --pretty=%at 7d1ee3207371ef72a1ca931a0964c4007e687280
2020-12-11 21:34:01,967 autosynth [DEBUG] > Running: git log -1 --pretty=%at 352f25621c28d2fa0784984ea0ed5ea697aa1525
2020-12-11 21:34:01,970 autosynth [DEBUG] > Running: git log -1 --pretty=%at 996775eca5fd934edac3c2ae34b80ff0395b1717
2020-12-11 21:34:01,973 autosynth [DEBUG] > Running: git checkout ee6524fe9030259540c241c9bcad452a42e1ac3c
Note: checking out 'ee6524fe9030259540c241c9bcad452a42e1ac3c'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at ee6524f docs: spelling correction for "targetting" (#242)
2020-12-11 21:34:01,978 autosynth [DEBUG] > Running: git checkout 996775eca5fd934edac3c2ae34b80ff0395b1717
Note: checking out '996775eca5fd934edac3c2ae34b80ff0395b1717'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 996775e fix(python): skip samples readmegen in synthtool (#875)
2020-12-11 21:34:01,985 autosynth [DEBUG] > Running: git branch -f autosynth-11
2020-12-11 21:34:01,988 autosynth [DEBUG] > Running: git checkout autosynth-11
Switched to branch 'autosynth-11'
2020-12-11 21:34:01,993 autosynth [INFO] > Running synthtool
2020-12-11 21:34:01,993 autosynth [INFO] > ['/usr/local/bin/python', '-m', 'synthtool', '--metadata', 'synth.metadata', 'synth.py', '--']
2020-12-11 21:34:01,993 autosynth [DEBUG] > log_file_path: /kokoro/artifacts/logs/nodejs-promisify/11/sponge_log.log
2020-12-11 21:34:01,995 autosynth [DEBUG] > Running: /usr/local/bin/python -m synthtool --metadata synth.metadata synth.py --
2020-12-11 21:34:02,244 synthtool [DEBUG] > Executing /root/.cache/synthtool/nodejs-promisify/synth.py.
On branch autosynth-11
nothing to commit, working tree clean
2020-12-11 21:34:02,394 synthtool [DEBUG] > Using precloned repo /root/.cache/synthtool/synthtool
DEBUG:synthtool:Using precloned repo /root/.cache/synthtool/synthtool
.eslintignore
.eslintrc.json
.gitattributes
.github/ISSUE_TEMPLATE/bug_report.md
.github/ISSUE_TEMPLATE/feature_request.md
.github/ISSUE_TEMPLATE/support_request.md
.github/PULL_REQUEST_TEMPLATE.md
.github/release-please.yml
.github/workflows/ci.yaml
.kokoro/.gitattributes
.kokoro/common.cfg
.kokoro/continuous/node10/common.cfg
.kokoro/continuous/node10/docs.cfg
.kokoro/continuous/node10/test.cfg
.kokoro/continuous/node12/common.cfg
.kokoro/continuous/node12/lint.cfg
.kokoro/continuous/node12/samples-test.cfg
.kokoro/continuous/node12/system-test.cfg
.kokoro/continuous/node12/test.cfg
.kokoro/docs.sh
.kokoro/lint.sh
.kokoro/populate-secrets.sh
.kokoro/presubmit/node10/common.cfg
.kokoro/presubmit/node12/common.cfg
.kokoro/presubmit/node12/samples-test.cfg
.kokoro/presubmit/node12/system-test.cfg
.kokoro/presubmit/node12/test.cfg
.kokoro/publish.sh
.kokoro/release/docs-devsite.cfg
.kokoro/release/docs-devsite.sh
.kokoro/release/docs.cfg
.kokoro/release/docs.sh
.kokoro/release/publish.cfg
.kokoro/samples-test.sh
.kokoro/system-test.sh
.kokoro/test.bat
.kokoro/test.sh
.kokoro/trampoline.sh
.kokoro/trampoline_v2.sh
.mocharc.js
.nycrc
.prettierignore
.prettierrc.js
.trampolinerc
CODE_OF_CONDUCT.md
CONTRIBUTING.md
LICENSE
README.md
api-extractor.json
renovate.json
samples/README.md
2020-12-11 21:34:02,579 synthtool [DEBUG] > Installing dependencies...
DEBUG:synthtool:Installing dependencies...
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/local/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/synthtool/synthtool/__main__.py", line 102, in <module>
    main()
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "/synthtool/synthtool/__main__.py", line 94, in main
    spec.loader.exec_module(synth_module)  # type: ignore
  File "<frozen importlib._bootstrap_external>", line 678, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/root/.cache/synthtool/nodejs-promisify/synth.py", line 12, in <module>
    node.install()
  File "/synthtool/synthtool/languages/node.py", line 167, in install
    shell.run(["npm", "install"], hide_output=hide_output)
  File "/synthtool/synthtool/shell.py", line 33, in run
    encoding="utf-8",
  File "/usr/local/lib/python3.6/subprocess.py", line 423, in run
    with Popen(*popenargs, **kwargs) as process:
  File "/usr/local/lib/python3.6/subprocess.py", line 729, in __init__
    restore_signals, start_new_session)
  File "/usr/local/lib/python3.6/subprocess.py", line 1364, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'npm': 'npm'
2020-12-11 21:34:02,654 autosynth [ERROR] > Synthesis failed
2020-12-11 21:34:02,654 autosynth [DEBUG] > Running: git reset --hard HEAD
HEAD is now at ee6524f docs: spelling correction for "targetting" (#242)
2020-12-11 21:34:02,661 autosynth [DEBUG] > Running: git checkout autosynth
Switched to branch 'autosynth'
2020-12-11 21:34:02,668 autosynth [DEBUG] > Running: git clean -fdx
Removing __pycache__/
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/local/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/synthtool/autosynth/synth.py", line 354, in <module>
    main()
  File "/synthtool/autosynth/synth.py", line 189, in main
    return _inner_main(temp_dir)
  File "/synthtool/autosynth/synth.py", line 334, in _inner_main
    commit_count = synthesize_loop(x, multiple_prs, change_pusher, synthesizer)
  File "/synthtool/autosynth/synth.py", line 65, in synthesize_loop
    has_changes = toolbox.synthesize_version_in_new_branch(synthesizer, youngest)
  File "/synthtool/autosynth/synth_toolbox.py", line 259, in synthesize_version_in_new_branch
    synthesizer.synthesize(synth_log_path, self.environ)
  File "/synthtool/autosynth/synthesizer.py", line 120, in synthesize
    synth_proc.check_returncode()  # Raise an exception.
  File "/usr/local/lib/python3.6/subprocess.py", line 389, in check_returncode
    self.stderr)
subprocess.CalledProcessError: Command '['/usr/local/bin/python', '-m', 'synthtool', '--metadata', 'synth.metadata', 'synth.py', '--']' returned non-zero exit status 1.

Google internal developers can see the full log here.

Autosynth is still having trouble generating nodejs-promisify. :sob:
Here's the output from running synth.py:
2020-12-11 21:47:59,218 autosynth [INFO] > logs will be written to: /kokoro/artifacts/logs/nodejs-promisify
2020-12-11 21:47:59,708 autosynth [DEBUG] > Running: git config --global core.excludesfile /root/.autosynth-gitignore
2020-12-11 21:47:59,711 autosynth [DEBUG] > Running: git config user.name yoshi-automation
2020-12-11 21:47:59,713 autosynth [DEBUG] > Running: git config user.email<EMAIL_ADDRESS>2020-12-11 21:47:59,716 autosynth [DEBUG] > Running: git config push.default simple
2020-12-11 21:47:59,719 autosynth [DEBUG] > Running: git branch -f autosynth
2020-12-11 21:47:59,721 autosynth [DEBUG] > Running: git checkout autosynth
Switched to branch 'autosynth'
2020-12-11 21:47:59,727 autosynth [DEBUG] > Running: git rev-parse --show-toplevel
2020-12-11 21:47:59,729 autosynth [DEBUG] > Running: git log -1 --pretty=%H
2020-12-11 21:47:59,732 autosynth [DEBUG] > Running: git remote get-url origin
2020-12-11 21:48:00,068 autosynth [DEBUG] > Running: git log 15013eff642a7e7e855aed5a29e6e83c39beba2a..HEAD --pretty=%H --no-decorate
2020-12-11 21:48:00,071 autosynth [DEBUG] > Running: git log -1 --pretty=%at 15013eff642a7e7e855aed5a29e6e83c39beba2a
2020-12-11 21:48:00,074 autosynth [DEBUG] > Running: git log -1 --pretty=%at c2de32114ec484aa708d32012d1fa8d75232daf5
2020-12-11 21:48:00,077 autosynth [DEBUG] > Running: git log -1 --pretty=%at 32af6da519a6b042e3da62008e2a75e991efb6b4
2020-12-11 21:48:00,080 autosynth [DEBUG] > Running: git log -1 --pretty=%at 69629b64b83c6421d616be2b8e11795738ec8a6c
2020-12-11 21:48:00,083 autosynth [DEBUG] > Running: git log -1 --pretty=%at f94318521f63085b9ccb43d42af89f153fb39f15
2020-12-11 21:48:00,085 autosynth [DEBUG] > Running: git log -1 --pretty=%at 18c5dbdb4ac8cf75d4d8174e7b4558f48e76f8a1
2020-12-11 21:48:00,088 autosynth [DEBUG] > Running: git log -1 --pretty=%at 5d11bd2888c38ce1fb6fa6bf25494a4219a73928
2020-12-11 21:48:00,091 autosynth [DEBUG] > Running: git log -1 --pretty=%at 3559dd8cb634347737632776ef4089443eacdb4f
2020-12-11 21:48:00,094 autosynth [DEBUG] > Running: git log -1 --pretty=%at 7d1ee3207371ef72a1ca931a0964c4007e687280
2020-12-11 21:48:00,096 autosynth [DEBUG] > Running: git log -1 --pretty=%at 352f25621c28d2fa0784984ea0ed5ea697aa1525
2020-12-11 21:48:00,099 autosynth [DEBUG] > Running: git log -1 --pretty=%at 996775eca5fd934edac3c2ae34b80ff0395b1717
2020-12-11 21:48:00,102 autosynth [DEBUG] > Running: git checkout ee6524fe9030259540c241c9bcad452a42e1ac3c
Note: checking out 'ee6524fe9030259540c241c9bcad452a42e1ac3c'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at ee6524f docs: spelling correction for "targetting" (#242)
2020-12-11 21:48:00,107 autosynth [DEBUG] > Running: git checkout 996775eca5fd934edac3c2ae34b80ff0395b1717
Note: checking out '996775eca5fd934edac3c2ae34b80ff0395b1717'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 996775e fix(python): skip samples readmegen in synthtool (#875)
2020-12-11 21:48:00,113 autosynth [DEBUG] > Running: git branch -f autosynth-11
2020-12-11 21:48:00,116 autosynth [DEBUG] > Running: git checkout autosynth-11
Switched to branch 'autosynth-11'
2020-12-11 21:48:00,119 autosynth [INFO] > Running synthtool
2020-12-11 21:48:00,120 autosynth [INFO] > ['/usr/local/bin/python', '-m', 'synthtool', '--metadata', 'synth.metadata', 'synth.py', '--']
2020-12-11 21:48:00,120 autosynth [DEBUG] > log_file_path: /kokoro/artifacts/logs/nodejs-promisify/11/sponge_log.log
2020-12-11 21:48:00,121 autosynth [DEBUG] > Running: /usr/local/bin/python -m synthtool --metadata synth.metadata synth.py --
2020-12-11 21:48:00,329 synthtool [DEBUG] > Executing /root/.cache/synthtool/nodejs-promisify/synth.py.
On branch autosynth-11
nothing to commit, working tree clean
2020-12-11 21:48:00,456 synthtool [DEBUG] > Using precloned repo /root/.cache/synthtool/synthtool
DEBUG:synthtool:Using precloned repo /root/.cache/synthtool/synthtool
.eslintignore
.eslintrc.json
.gitattributes
.github/ISSUE_TEMPLATE/bug_report.md
.github/ISSUE_TEMPLATE/feature_request.md
.github/ISSUE_TEMPLATE/support_request.md
.github/PULL_REQUEST_TEMPLATE.md
.github/release-please.yml
.github/workflows/ci.yaml
.kokoro/.gitattributes
.kokoro/common.cfg
.kokoro/continuous/node10/common.cfg
.kokoro/continuous/node10/docs.cfg
.kokoro/continuous/node10/test.cfg
.kokoro/continuous/node12/common.cfg
.kokoro/continuous/node12/lint.cfg
.kokoro/continuous/node12/samples-test.cfg
.kokoro/continuous/node12/system-test.cfg
.kokoro/continuous/node12/test.cfg
.kokoro/docs.sh
.kokoro/lint.sh
.kokoro/populate-secrets.sh
.kokoro/presubmit/node10/common.cfg
.kokoro/presubmit/node12/common.cfg
.kokoro/presubmit/node12/samples-test.cfg
.kokoro/presubmit/node12/system-test.cfg
.kokoro/presubmit/node12/test.cfg
.kokoro/publish.sh
.kokoro/release/docs-devsite.cfg
.kokoro/release/docs-devsite.sh
.kokoro/release/docs.cfg
.kokoro/release/docs.sh
.kokoro/release/publish.cfg
.kokoro/samples-test.sh
.kokoro/system-test.sh
.kokoro/test.bat
.kokoro/test.sh
.kokoro/trampoline.sh
.kokoro/trampoline_v2.sh
.mocharc.js
.nycrc
.prettierignore
.prettierrc.js
.trampolinerc
CODE_OF_CONDUCT.md
CONTRIBUTING.md
LICENSE
README.md
api-extractor.json
renovate.json
samples/README.md
2020-12-11 21:48:00,612 synthtool [DEBUG] > Installing dependencies...
DEBUG:synthtool:Installing dependencies...
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/local/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/synthtool/synthtool/__main__.py", line 102, in <module>
    main()
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "/synthtool/synthtool/__main__.py", line 94, in main
    spec.loader.exec_module(synth_module)  # type: ignore
  File "<frozen importlib._bootstrap_external>", line 678, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/root/.cache/synthtool/nodejs-promisify/synth.py", line 12, in <module>
    node.install()
  File "/synthtool/synthtool/languages/node.py", line 167, in install
    shell.run(["npm", "install"], hide_output=hide_output)
  File "/synthtool/synthtool/shell.py", line 33, in run
    encoding="utf-8",
  File "/usr/local/lib/python3.6/subprocess.py", line 423, in run
    with Popen(*popenargs, **kwargs) as process:
  File "/usr/local/lib/python3.6/subprocess.py", line 729, in __init__
    restore_signals, start_new_session)
  File "/usr/local/lib/python3.6/subprocess.py", line 1364, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'npm': 'npm'
2020-12-11 21:48:00,675 autosynth [ERROR] > Synthesis failed
2020-12-11 21:48:00,675 autosynth [DEBUG] > Running: git reset --hard HEAD
HEAD is now at ee6524f docs: spelling correction for "targetting" (#242)
2020-12-11 21:48:00,683 autosynth [DEBUG] > Running: git checkout autosynth
Switched to branch 'autosynth'
2020-12-11 21:48:00,688 autosynth [DEBUG] > Running: git clean -fdx
Removing __pycache__/
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/local/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/synthtool/autosynth/synth.py", line 354, in <module>
    main()
  File "/synthtool/autosynth/synth.py", line 189, in main
    return _inner_main(temp_dir)
  File "/synthtool/autosynth/synth.py", line 334, in _inner_main
    commit_count = synthesize_loop(x, multiple_prs, change_pusher, synthesizer)
  File "/synthtool/autosynth/synth.py", line 65, in synthesize_loop
    has_changes = toolbox.synthesize_version_in_new_branch(synthesizer, youngest)
  File "/synthtool/autosynth/synth_toolbox.py", line 259, in synthesize_version_in_new_branch
    synthesizer.synthesize(synth_log_path, self.environ)
  File "/synthtool/autosynth/synthesizer.py", line 120, in synthesize
    synth_proc.check_returncode()  # Raise an exception.
  File "/usr/local/lib/python3.6/subprocess.py", line 389, in check_returncode
    self.stderr)
subprocess.CalledProcessError: Command '['/usr/local/bin/python', '-m', 'synthtool', '--metadata', 'synth.metadata', 'synth.py', '--']' returned non-zero exit status 1.

Google internal developers can see the full log here.

Autosynth is still having trouble generating nodejs-promisify. :sob:
Here's the output from running synth.py:
nsider supporting our open collective:
> https://opencollective.com/compodoc/donate

npm WARN lifecycle<EMAIL_ADDRESS>cannot run in wd<EMAIL_ADDRESS>npm run compile (wd=/root/.cache/synthtool/nodejs-promisify)
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/live-server/node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

added 920 packages from 841 contributors and audited 924 packages in 19.558s

75 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

2020-12-11 22:04:19,546 synthtool [DEBUG] > Running prelint...
DEBUG:synthtool:Running prelint...

><EMAIL_ADDRESS>prelint /root/.cache/synthtool/nodejs-promisify
> cd samples; npm link ../; npm install

npm WARN lifecycle<EMAIL_ADDRESS>cannot run in wd<EMAIL_ADDRESS>npm run compile (wd=/root/.cache/synthtool/nodejs-promisify)
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/live-server/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

audited 924 packages in 4.585s

75 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

/root/.nvm/versions/node/v14.15.1/lib/node_modules/@google-cloud/promisify -> /root/.cache/synthtool/nodejs-promisify
/root/.cache/synthtool/nodejs-promisify/samples/node_modules/@google-cloud/promisify -> /root/.nvm/versions/node/v14.15.1/lib/node_modules/@google-cloud/promisify -> /root/.cache/synthtool/nodejs-promisify
npm WARN deprecated<EMAIL_ADDRESS>Debug versions >=3.2.0 <3.2.7 || >=4 <4.3.1 have a low-severity ReDos regression when used in a Node.js environment. It is recommended you upgrade to 3.2.7 or 4.3.1. (https://github.com/visionmedia/debug/issues/797)
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

added 108 packages from 71 contributors and audited 110 packages in 4.556s

75 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

2020-12-11 22:04:31,099 synthtool [DEBUG] > Running fix...
DEBUG:synthtool:Running fix...

><EMAIL_ADDRESS>fix /root/.cache/synthtool/nodejs-promisify
> gts fix

version: 14

/root/.cache/synthtool/nodejs-promisify/src/index.ts
   71:18  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any
  103:27  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any
  169:35  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any
  178:13  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any

/root/.cache/synthtool/nodejs-promisify/test/index.ts
   29:18  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any
   49:11  warning  'fc' is assigned a value but never used   @typescript-eslint/no-unused-vars
  151:20  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any
  162:20  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any
  203:22  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any
  216:21  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any
  275:18  warning  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any
  344:36  warning  '_this' is defined but never used         @typescript-eslint/no-unused-vars
  370:36  warning  '_this' is defined but never used         @typescript-eslint/no-unused-vars
  379:36  warning  '_this' is defined but never used         @typescript-eslint/no-unused-vars

/root/.cache/synthtool/nodejs-promisify/samples/quickstart.js
  16:29  error  "@google-cloud/promisify" is not found  node/no-missing-require

✖ 15 problems (1 error, 14 warnings)

Error: Command failed with exit code 1: node ./node_modules/eslint/bin/eslint --fix **/*.ts **/*.js **/*.tsx **/*.jsx --no-error-on-unmatched-pattern
    at makeError (/root/.cache/synthtool/nodejs-promisify/node_modules/gts/node_modules/execa/lib/error.js:59:11)
    at handlePromise (/root/.cache/synthtool/nodejs-promisify/node_modules/gts/node_modules/execa/index.js:114:26)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at async run (/root/.cache/synthtool/nodejs-promisify/node_modules/gts/build/src/cli.js:120:17) {
  shortMessage: 'Command failed with exit code 1: node ./node_modules/eslint/bin/eslint --fix **/*.ts **/*.js **/*.tsx **/*.jsx --no-error-on-unmatched-pattern',
  command: 'node ./node_modules/eslint/bin/eslint --fix **/*.ts **/*.js **/*.tsx **/*.jsx --no-error-on-unmatched-pattern',
  exitCode: 1,
  signal: undefined,
  signalDescription: undefined,
  stdout: undefined,
  stderr: undefined,
  failed: true,
  timedOut: false,
  isCanceled: false,
  killed: false
}
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>fix: `gts fix`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>fix script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2020-12-11T22_04_33_725Z-debug.log
2020-12-11 22:04:33,739 synthtool [ERROR] > Failed executing npm run fix:

None
ERROR:synthtool:Failed executing npm run fix:

None
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/local/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/synthtool/synthtool/__main__.py", line 102, in <module>
    main()
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.6/site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "/synthtool/synthtool/__main__.py", line 94, in main
    spec.loader.exec_module(synth_module)  # type: ignore
  File "<frozen importlib._bootstrap_external>", line 678, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/root/.cache/synthtool/nodejs-promisify/synth.py", line 13, in <module>
    node.fix()
  File "/synthtool/synthtool/languages/node.py", line 179, in fix
    shell.run(["npm", "run", "fix"], hide_output=hide_output)
  File "/synthtool/synthtool/shell.py", line 39, in run
    raise exc
  File "/synthtool/synthtool/shell.py", line 33, in run
    encoding="utf-8",
  File "/usr/local/lib/python3.6/subprocess.py", line 438, in run
    output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['npm', 'run', 'fix']' returned non-zero exit status 1.
2020-12-11 22:04:33,810 autosynth [ERROR] > Synthesis failed
2020-12-11 22:04:33,810 autosynth [DEBUG] > Running: git reset --hard HEAD
HEAD is now at ee6524f docs: spelling correction for "targetting" (#242)
2020-12-11 22:04:33,820 autosynth [DEBUG] > Running: git checkout autosynth
Switched to branch 'autosynth'
2020-12-11 22:04:33,826 autosynth [DEBUG] > Running: git clean -fdx
Removing __pycache__/
Removing node_modules/
Removing package-lock.json
Removing samples/node_modules/
Removing samples/package-lock.json
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/local/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/synthtool/autosynth/synth.py", line 354, in <module>
    main()
  File "/synthtool/autosynth/synth.py", line 189, in main
    return _inner_main(temp_dir)
  File "/synthtool/autosynth/synth.py", line 334, in _inner_main
    commit_count = synthesize_loop(x, multiple_prs, change_pusher, synthesizer)
  File "/synthtool/autosynth/synth.py", line 65, in synthesize_loop
    has_changes = toolbox.synthesize_version_in_new_branch(synthesizer, youngest)
  File "/synthtool/autosynth/synth_toolbox.py", line 259, in synthesize_version_in_new_branch
    synthesizer.synthesize(synth_log_path, self.environ)
  File "/synthtool/autosynth/synthesizer.py", line 120, in synthesize
    synth_proc.check_returncode()  # Raise an exception.
  File "/usr/local/lib/python3.6/subprocess.py", line 389, in check_returncode
    self.stderr)
subprocess.CalledProcessError: Command '['/usr/local/bin/python', '-m', 'synthtool', '--metadata', 'synth.metadata', 'synth.py', '--']' returned non-zero exit status 1.

Google internal developers can see the full log here.


Person who places the request should be notified on request confirmation and fulfillment, not only the partner contact.

Summary
Currently, on request confirmation and fulfillment, only the partner main contact is notified of the fulfillment.   We should also notify the person who placed the request.
Why
For some partners,  there are multiple people and 'the boss' isn't the one who needs to know when things are ready.
Details
The confirmation and fulfillment notices should be sent to the person who entered the request.  The partner contact, if different, should be cc'd.
Recreation
After setup,
1/ Sign in as<EMAIL_ADDRESS> Click on<EMAIL_ADDRESS>to see the list of co-workers.  Grab the email of the other user.
2/ Logout and sign in as that other user.  Create a request.  Wait a bit for the email to pop up in your browser
The confirmation email currently goes to<EMAIL_ADDRESS> It should go to the user who created the request, and cc the partner contact (in this case, verified@example.com).
3/ Sign in as<EMAIL_ADDRESS> Click on Partner Agencies,  then Pawnee Parent Service.  Edit Partner Information.  Check "Do you want this partner to receive emails for distributions and reminders from the system?".   Click Update Partner
4/  Click on the Groups tab.  Edit Group 1. Click Yes under "Do you want to send deadline reminders to them every month?"
4/ Click on requests.  View the request you just entered.
5/ Click on fulfill request.  Choose Bulk Storage Location.   Check that there is enough inventory, and reduce the amounts if needed.   Click save. (wait a bit)
6/  You'll see that The fullfillment email currently goes to<EMAIL_ADDRESS> It should go to the user who created the request, and cc the partner contact (in this case<EMAIL_ADDRESS>So -- both those emails should go to the person who created the request, cc'd to the partner contact, if different.
Criteria for completion

[ ] Fulfilment emails go to the person who entered the request
[ ] Partner contact, if different, is cc'd
[ ] tests to support this (may require changing existing tests)

is someone working on this?

Not that I know of -- would you like to?

Is this of a decent priority? If so I can take it on

Go for it!

Was able to solve this pretty quickly by passing current_user.email down as an argument from the requests controller. Haven't modified any tests or gone any further. Is this an acceptable approach for you guys?

Can I be granted access to create a new branch? @dorner @cielf

@lokisk1155 for now you can fork the repo and work on it that way!

That's still what I do!

lol, would have been nice to know that before I started committing changes to a branch off the main repo, but it's no problem

Heh it's the standard open source workflow. :slightly_smiling_face:

my repo
Let me know how it's looking. Both cases are currently being sent to the correct email. Haven't configured any tests etc to account for my changes

https://github.com/rubyforgood/human-essentials/pull/3452/files

Sorry new to open source -
I've had to make a lot of assumptions. For issue 1, I am finding the correct email via current_user.email and for distribution, I am finding the user email via partner_user_id associated with the request.

Just want to confirm this approach is good with you guys before I bring it to the standard necessary to be merged

https://github.com/rubyforgood/human-essentials/pull/3454


fix message parenthesis color

Hello!
Using Bundler version 1.13.1 i noticed a small graphic inconsistency on parentheses color:

This commit resets the opening parenthesis color:

Is this the expected behaviour? The spec was only checking the closing parenthesis color.
p.s:
Imho green parentheses look better here.

👍

@alepore I would prefer that both the open and close parens be green--can we do that instead? 😀  Thanks!

👍 updated will green parens, looks better

@homu r+

:pushpin: Commit 53bbe68 has been approved by indirect

:hourglass: Testing commit 53bbe68 with merge 03633e1...

:sunny: Test successful - status


Can't download .jar of latest version

Title

The latest stable release at the moment can be downloaded here: https://www.spigotmc.org/resources/message-editor.82154/download?version=480361 while the latest dev build can be downloaded here: https://github.com/jaqobb/message-editor/suites/10116832620/artifacts/493557557


Fastmate tip: label-specific inbox

I'm putting this here as a tip. I'm using Fastmate with different automatically labeled messages in my inbox. Sometimes I want to focus on just the inbox messages for a specific label. I can do that with search, but e.g. the automatic From address and other label-specific features don't work then. That's why I've written the JS below. Include this in a startup JS script with Fastmate and it will load an Inbox view for a label if you click that label in the sidebar.
let previousUrl = '';
const observer = new MutationObserver(function(mutations) {
	if (window.location.href !== previousUrl) {
                let mailboxRegex = /\/mail\/(Inbox|LabelA|LabelB|LabelC)/;
                let previousMailbox = mailboxRegex.test(previousUrl) ? previousUrl.match(mailboxRegex)[1] : null;
                let mailbox = mailboxRegex.test(window.location.href) ? window.location.href.match(mailboxRegex)[1] : null;
                if(mailbox !== "Inbox" && mailbox != null && previousMailbox !== null && (previousMailbox !== mailbox || (previousMailbox == mailbox && /filter=Inbox/.test(window.location.href)))) {
		    let v102 = document.getElementById('v102')
                    if (v102) {
                        v102.click();
		                document.evaluate("//span[contains(.,'In Inbox')]", document, null, XPathResult.ANY_TYPE, null).iterateNext().click();
                        console.log("Filter inbox activated");
                    }
                }
   	        previousUrl = window.location.href;
	}
});
// start listening to changes
observer.observe(document, {subtree: true, childList: true});

Thank you for this! Converting this to a discussion to keep it around 👌


Plot not showing up

I'm seeing a suggested learning rate, but no plot when calling .plot() with all default arguments.

Hi @sciadopitys,
The notebook examples/lrfinder_mnist.ipynb can be executed successfully without problems, maybe you can try from it first.
Besides, could you attach the script of how you run with LRFinder? If there is any error message, it would be better to post them here too.

Hello,
I'm actually running my script on a remote server.  I simply copy-and-pasted the lines from the gradient accumulation section:
desired_batch_size, real_batch_size = 44, 2
accumulation_steps = desired_batch_size // real_batch_size
lr_finder = LRFinder(model, optimizer, criterion, device="cuda")
lr_finder.range_test(train_loader, end_lr=.001, num_iter=100, step_mode="exp", accumulation_steps=accumulation_steps)
lr_finder.plot()
lr_finder.reset()
, only changing the batch sizes and the end_lr argument of range_test.  The lr finder seems to be working correctly and no error message is produced, its just that no plot is displayed at the end.  All I see is
Learning rate search finished. See the graph with {finder_name}.plot()
LR suggestion: steepest gradient
Suggested LR: value

If you are running in a remote server matplotlib probably can't create the graph because the display backend is not set: https://stackoverflow.com/questions/3453188/matplotlib-display-plot-on-a-remote-machine

OK, I'm not sure whether the actual problem is currently.
If I understand you correctly, the title "Plot not showing up" means "the window of a matplotlib plot didn't show up", rather than "content of a matplotlib plot window is empty".
Regarding this meaning, my first guess it's resulted by the environment you were using.
If you run the script through a terminal + SSH on remote server, there might be extra setup you have to done to make the plot able to show up on your client machine. Or if you run the script in a Jupyter Notebook, we requires more information to investigate the issue.
But here is a thing you can try first: could you check that lr_finder.history isn' empty after running lr_finder.range_test()?

It's definitely an issue with the display backend.  However, I'm still getting "gdk_cursor_new_for_display: assertion 'GDK_IS_DISPLAY (display)' failed" even when I specify matplotlib to use a different backend.  Regardless, the issue doesn't really have to do with pytorch-lr-finder itself.

If it still doesn't work after configuring SSH config (X11 forwarding), maybe you can try the following workarounds:

Save the figure as an image, then copy it and view it on your local machine. (see also this comment)
Save the figure as an image, then view it with other tools. e.g. https://superuser.com/questions/557622
Try matplotlib-terminal.
Use Jupyter notebook or JupyterLab.


refactor(@ciscospark/eslint-config): use remote eslint-config module

Remove the packages/node_modules/@ciscospark/eslint-config module and use the remote @ciscospark/eslint-config module by pulling it in as a dependency in package.json. Fix ESLint errors in tooling directory

@ianwremmel I have made the requested changes. There will probably need to be more when the pipeline is fixed, so please let me know what general changes need to be made there. Thanks

are you looking at the issues in the eslint config repo?

No I need to go do that ! Thanks!

no longer relevant


[Feature][Cherry-Pick] CTAS support automatic partition

Fixes #30226
What type of PR is this:

[ ] BugFix
[x] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[x] Yes, this PR will result in a change in behavior.
[ ] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[x] I have added test cases for my bug fix or my new feature
[x] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[ ] I have checked the version labels which the pr will be auto-backported to the target branch

[ ] 3.1
[ ] 3.0
[ ] 2.5
[ ] 2.4

[FE Incremental Coverage Report]
:heart_eyes: pass : 78 / 97 (80.41%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/analyzer/CTASAnalyzer.java
13
22
59.09%
[177, 178, 182, 183, 184, 185, 186, 187, 189]

:large_blue_circle:
com/starrocks/sql/analyzer/AnalyzerUtils.java
64
74
86.49%
[1144, 1160, 1165, 1170, 1178, 1186, 1192, 1203, 1217, 1232]

:large_blue_circle:
com/starrocks/sql/ast/RangePartitionDesc.java
1
1
100.00%
[]

[BE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)


Feature: Allow multiple test reporters

What is the current behavior?
Currently you can pass a single test reporter so that your tests results are formatted.
What is the expected behavior?
Where jest is lacking in contrast to other frameworks, is that you can only ever pass a single reporter. Our business wants a visual, html display of test results, output by CI (CircleCI), and our developers want the built-in junit-xml results so that CI can automatically parse the output and visually display failures so that they can be quickly detected and fixed.
My options right now are to install a post-junit formatter and use it to process the xml, which adds time to the build, or to run the test suite twice for two different report formats. However - neither of these are optimal as you can imagine.
Please provide your exact Jest configuration and mention your Jest, node,
yarn/npm version and operating system.
ant@vanta:~/Projects/xyz-app$ node -v
v9.3.0
ant@vanta:~/Projects/xyz-app$ ./node_modules/.bin/jest --version
v22.1.4
ant@vanta:~/Projects/xyz-app$ cat /etc/*-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=17.10
...
ant@vanta:~/Projects/xyz-app$ npm -v
5.5.1

This seems to work for me in config, but not on the console. Will re-try and re-report if required.

Reporters are an array already? https://facebook.github.io/jest/docs/en/configuration.html#reporters-array-modulename-modulename-options
Closing as this is already the case. Happy to reopen if I've misunderstood something, though

Yep my bad - forgot to re-close. I guess the difference between reporters and test-result-processors isn't immediately clear, so I got confused. I ended up writing this:
https://github.com/antony/jest-multi-test-result-processor
as I was actually trying to fork to two test-result-processors (which are not an array), not reporters. My bad!


Send error if user isn't authorised to send request

Yeah, I'm wondering if this might be worth bundling info a debug option rather than just an option on it's own, but yeah, that's fine. Will add

Alright, I added a debug option, defaulted to false, and only print the error if debug is enabled.


Unify logging

I think I've got it all - am I supposed to push some other button now?

I cleaned up the last issues with missing spaces, and cleaned up the code a bit as I was looking through. Added some comments to methods and added some log messages.

Great.  Sorry about the spaces (black black black . . .)...


Unescape html entities

Some characters, such as the apostrophe ('), are too common within commit messages, and they are getting sent as HTML entities that Telegram cannot render (' for the character ' ).
This PR unescapes all texts to make sure that such characters are sent as proper characters.
Fixes #50

@dmlambea Thanks.


Layout - frontend site

Hey @JoseCage , i was seeing the gulpfile.js from doesangue.org site, and i want to know if you have a layout image from the site? Or an ideia of how the site is gonna stay?

@Guilherme-Chinaglia Yes i have a basic (older) prototype i have created :point_down:
Note: the site is doesangue.me not .org. I keep the site off because the repo is empty at moment (the domain is registered)..

@JoseCage did you have a mobile prototype layout?

@Guilherme-Chinaglia i have created a repo for android app version. At this moment i think i have only designed a prototype for signup steps.

android repo


Use of eval in "node_modules/editorjs-button/dist/bundle.js" is strongly discouraged as it poses security risks and may cause issues with minification.

"editorjs-button": "~1.0.4",

This seems to be used for rendering CSS. Agreed, there should be a better way to do this.

@evtuhovdo @ConnectGrid Can you think of a good solution?


SR-10157: XMLParser shouldn't swap the parts of the element name.

XMLParser swaps the prefix with the local name. This behavior is apparently a bug. This PR fixes it.
Resolves SR-10157.

@swift-ci test


Add "path-whitelist" option.

Hello Quinn,
I worked on the path-whitelist option to whitelist only specific paths of dependencies to prevent having too broad exceptions. I am working currently on the warning when a whitelisted path is specified in the configuration but does not match an actual path.
In the mean time, what do you think about the feature? Please tell me if the formatting, the tests, or anything else is not correct and should be improved.
Cheers

@quinnturner
Did you have time to look into it?
Several developers in my company are really excited about this coming feature 😄


bump(ocaml-lsp): v1.18.0

Describe your changes
Update from v.1.17.0 to v.1.8.0
https://github.com/ocaml/ocaml-lsp/releases/tag/1.18.0
Issue ticket number and link

Checklist before requesting a review

[x] I have successfully tested installation of the package.
[x] I have successfully tested the package after installation.

Screenshots

https://github.com/mason-org/mason-registry/pull/6739#pullrequestreview-2217841342


pip install -r requirements.txt throws error

» pip install -r requirements.txt
  Using cached waitress-1.0.2-py2.py3-none-any.whl
Collecting pyyaml (from -r requirements.txt (line 2))
  Using cached PyYAML-3.12.tar.gz
Installing collected packages: waitress, pyyaml
Exception:
Traceback (most recent call last):
  File "/Library/Python/2.7/site-packages/pip/basecommand.py", line 215, in main
    status = self.run(options, args)
  File "/Library/Python/2.7/site-packages/pip/commands/install.py", line 342, in run
    prefix=options.prefix_path,
  File "/Library/Python/2.7/site-packages/pip/req/req_set.py", line 784, in install
    **kwargs
  File "/Library/Python/2.7/site-packages/pip/req/req_install.py", line 851, in install
    self.move_wheel_files(self.source_dir, root=root, prefix=prefix)
  File "/Library/Python/2.7/site-packages/pip/req/req_install.py", line 1064, in move_wheel_files
    isolated=self.isolated,
  File "/Library/Python/2.7/site-packages/pip/wheel.py", line 345, in move_wheel_files
    clobber(source, lib_dir, True)
  File "/Library/Python/2.7/site-packages/pip/wheel.py", line 316, in clobber
    ensure_dir(destdir)
  File "/Library/Python/2.7/site-packages/pip/utils/__init__.py", line 83, in ensure_dir
    os.makedirs(path)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.py", line 157, in makedirs
    mkdir(name, mode)
OSError: [Errno 13] Permission denied: '/Library/Python/2.7/site-packages/waitress'

Fixed by running sudo pip install -r requirements.txt


Fix copyright statements that have year-year range

Some of the copyright statements specify a range of years, e.g. "Copyright 2016-2020 ...".
The copyright is claimed automatically for all following years, so only the oldest year needs to be mentioned. It is in fact important to claim the oldest year in any copyright dispute.
If significant changes are made in a particular year, that year can optionally be listed, but the years then must be separated by comma.
This ticket is to change all copyright statements that specify a range of years, to use comma instead of hyphen (assuming that the second year was somehow significant enough to be mentioned).
The following command can be used to list all copyright statements with a year range:
grep -i "Copyright .*20..-20.." . -r

See PR https://github.com/zhmcclient/zhmc-ansible-modules/pull/879 for how this was done in the zhmc ansible project.

Searching for such forms of copyright statements in this repo revealed none.


606- UTC datetimes

Description
All datetime/temporal values are created knowing about the users current timezone, this change ensures all datetime/temporal values are disconnected from the users time-zone and uses UTC always instead.
Changes

Use OffsetDateTime insteadof LocalDateTime
Emit datetimes with a Z suffix to highlight that they are UTC
Treat all input datetimes as UTC offset, there is no need to include the Z suffix, but suffix is supported for interoperability (i.e. output from the generator can be used in the input)
Cucumber framework updated to allow, but always emit, datetimes with the Z suffix
Cucumber scenarios updated to include a Z suffix for all dates
Documentation updated to clarify new behaviour

Issue
Resolves #606

Codecov Report

Merging #812 into master will decrease coverage by <.01%.
The diff coverage is 92.5%.

@@            Coverage Diff             @@
##             master   #812      +/-   ##
==========================================
- Coverage     66.01%    66%   -0.01%
  Complexity     1711   1711
==========================================
  Files           281    281
  Lines          6008   6013       +5
  Branches        695    696       +1
==========================================
+ Hits           3966   3969       +3
- Misses         1794   1795       +1
- Partials        248    249       +1

Impacted Files
Coverage Δ
Complexity Δ

...dation/validators/DateTimeConstraintValidator.java
0% <ø> (ø)
0 <0> (ø)
:arrow_down:

...gic/deg/generator/fieldspecs/FieldSpecFactory.java
97.14% <ø> (ø)
69 <0> (ø)
:arrow_down:

...ator/outputs/datasetwriters/JsonDataSetWriter.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...messages/DateTimeConstraintValidationMessages.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...com/scottlogic/deg/generator/guice/BaseModule.java
85.36% <100%> (ø)
3 <0> (ø)
:arrow_down:

...generator/inputs/AtomicConstraintReaderLookup.java
94.83% <100%> (+0.17%)
51 <5> (+1)
:arrow_up:

...ic/IsAfterOrEqualToConstantDateTimeConstraint.java
36.84% <100%> (ø)
4 <1> (ø)
:arrow_down:

...ints/atomic/IsAfterConstantDateTimeConstraint.java
36.84% <100%> (ø)
4 <1> (ø)
:arrow_down:

...rator/outputs/datasetwriters/CsvDataSetWriter.java
71.87% <100%> (ø)
11 <1> (ø)
:arrow_down:

...c/IsBeforeOrEqualToConstantDateTimeConstraint.java
36.84% <100%> (ø)
4 <1> (ø)
:arrow_down:

... and 6 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 791f1b2...c2f3f8d. Read the comment docs.

seems to be missing updates to:

ProfileGrammar.md
datahelix.profile.bnf
datahelix.profile.json

I think you could argue we should be using Instants rather than OffsetDateTimes, but not gonna fuss about that. I'm happy with the PR if we also bring in the changes I just put on the branch.

I tried this and it didn't work, I guess it's working here with the temporal accessor change.


[robot] verify record type validation settings

Critical Changes
Changes
Issues Closed
New Metadata
Unpackaged Metadata
Deleted Metadata
Testing Notes

Issue with PR. Closing and trying again.


Ability to control or turn off logging

Have been playing with this as I get the chance and really enjoy using it!
Would you consider exposing a way to control the logs from the module, or maybe turn logs off?

We could add a silent option, but the status updates are can be pretty important. And some notifications like uncaught exceptions in handlers probably should never be silenced. Is it just the "[hot] Loaded 1 new module, reevaluated 2 existing modules in 224ms." message that is bothering you?

In an ideal world, I would like to be able to get informed of the lifecycle/errors etc by a message event:
That way, I could choose what to log.
https://nodejs.org/api/module.html#communication-with-module-customization-hooks

My specific use case is that I log in JSON and I have an external worker that processes my logs during development for pretty-printing. (standard usage of pino really)
but dynohot is outputting logs that I can't format or ignore

Communication with module customization hooks

This actually communicates with the loader thread but in dynohot most of the interesting logic lives in the runtime which runs in the same context as the script.
Anyway I'll see about adding a way to listen for the log messages explicitly.


problem: dissaperance freezes about 1:20 left

it freezes when those side notes come in when miku screames

bros making issues about online songs 💀 jokes aside im not working on this repo anymore, should archive it soon

ok sorry sorry

dw lol

i should prob close this

i will check on it soon, prob some song events shit dunno

you’re fine
On Feb 19, 2023 at 2:14 PM -0500, SanicBTW @.***>, wrote:

i will check on it soon, prob some song events shit dunno
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you modified the open/close state.Message ID: @.***>

oki


Generating structures for new images

Hello,
Please can your model be used to generate table structures for the ICDAR 2019 Modern table images?
Thanks

That can be difficult. ReS2TIM is time-consuming and a lot tables in ICDAR 2019 has a large of cells. Another reason is that ReS2TIM cannot well handle graphs with circle.
You can try TGRNet that is more robust.

TGRNet only includes ICDAR 2019 historical tables but does not include the modern tables. Also, how can I use TGRNet to generate structures for new table images? Can you point me to the right script to do that?
Thanks

TGRNet only includes ICDAR 2019 historical tables but does not include the modern tables.

TableGraph-24K contains tables that are converted from Latex files.

Also, how can I use TGRNet to generate structures for new table images? Can you point me to the right script to do that?

If you just use the pretrained model to infer on new images, you can prepare a test.txt file as other datasets.

TGRNet only includes ICDAR 2019 historical tables but does not include the modern tables.

TableGraph-24K contains tables that are converted from Latex files.

Also, how can I use TGRNet to generate structures for new table images? Can you point me to the right script to do that?

If you just use the pretrained model to infer on new images, you can prepare a test.txt file as other datasets.

It appears that the results for ReS2TIM are for the threshold of 0.5 IOU, please can you point me to how I can vary this threshold for ReS2TIM? I could do that for TGRNet in the evaluator_vis.py script
Thanks


nan Obj value

Hi, guys:
I'm trying CTC on a big dataset more than 2000hours, using steps/train_ctc_parallel_h.sh --nj 3
job 1
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 280196 sequences (343.467Hr): Obj(log[Pzx]) = -34.12   TokenAcc = 65.5557%
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 290214 sequences (356.577Hr): Obj(log[Pzx]) = -35.0829   TokenAcc = 66.0633%
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 300228 sequences (369.041Hr): Obj(log[Pzx]) = -35.5174   TokenAcc = 64.8673%
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 310238 sequences (382.234Hr): Obj(log[Pzx]) = -35.9657   TokenAcc = 65.8774%
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 320254 sequences (394.763Hr): Obj(log[Pzx]) = -33.7356   TokenAcc = 66.6929%
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 330265 sequences (407.316Hr): Obj(log[Pzx]) = -32.8957   TokenAcc = 67.0366%
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 340269 sequences (420.524Hr): Obj(log[Pzx]) = -36.0733   TokenAcc = 66.5803%
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 350272 sequences (433.553Hr): Obj(log[Pzx]) = -3.06908e+29   TokenAcc = 13.6926%

job 2
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 290240 sequences (361.23Hr): Obj(log[Pzx]) = -34.8453   TokenAcc = 65.5767%
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 300251 sequences (374.192Hr): Obj(log[Pzx]) = -34.6744   TokenAcc = 65.9575%
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 310255 sequences (386.489Hr): Obj(log[Pzx]) = -32.8376   TokenAcc = 66.4874%
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 320258 sequences (399.27Hr): Obj(log[Pzx]) = -34.0779   TokenAcc = 66.6884%
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 330274 sequences (411.385Hr): Obj(log[Pzx]) = -31.8291   TokenAcc = 67.3521%
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 340285 sequences (423.992Hr): Obj(log[Pzx]) = -32.077   TokenAcc = 67.5502%
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 350304 sequences (437.536Hr): Obj(log[Pzx]) = -3.17996e+29   TokenAcc = 18.6188%

job 3
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 290221 sequences (367.77Hr): Obj(log[Pzx]) = -33.8591   TokenAcc = 65.0273%
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 300232 sequences (380.856Hr): Obj(log[Pzx]) = -36.8064   TokenAcc = 65.3367%
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 310232 sequences (393.478Hr): Obj(log[Pzx]) = -33.5105   TokenAcc = 65.6533%
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 320235 sequences (406.032Hr): Obj(log[Pzx]) = -9.997e+25   TokenAcc = 66.9717%
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 330242 sequences (418.355Hr): Obj(log[Pzx]) = -32.2745   TokenAcc = 66.3963%
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 340247 sequences (433.924Hr): Obj(log[Pzx]) = -41.3272   TokenAcc = 67.6148%
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 350257 sequences (448.286Hr): Obj(log[Pzx]) = nan   TokenAcc = 29.8061%

job2 crash
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 350304 sequences (437.536Hr): Obj(log[Pzx]) = -3.17996e+29   TokenAcc = 18.6188%
LOG (train-ctc-parallel:comm_avg_weights():net/communicator.h:106) Waiting for averaged model at exp/train_phn_l3_c320/nnet/nnet.iter1.avg500
ERROR (train-ctc-parallel:Check():net.cc:397) 'nan' in network parameters
WARNING (train-ctc-parallel:Close():kaldi-io.cc:446) Pipe apply-cmvn --norm-vars=true --utt2spk=ark:data_fbank/train_nodup_tr/utt2spk scp:data_fbank/train_nodup_tr/cmvn.scp scp:exp/train_phn_l3_c320/feats_tr.2.scp ark:- | add-deltas ark:- ark:- | had nonzero return status 36096
ERROR (train-ctc-parallel:Check():net.cc:397) 'nan' in network parameters

[stack trace: ]
eesen::KaldiGetStackTrace()
eesen::KaldiErrorMessage::~KaldiErrorMessage()
eesen::Net::Check() const
eesen::Net::Write(std::ostream&, bool) const
eesen::Net::Write(std::string const&, bool) const
comm_avg_weights(eesen::Net&, int const&, int const&, int const&, std::string const&, std::string const&)
train-ctc-parallel(main+0x1223) [0x48b1e7]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f777206eec5]
train-ctc-parallel() [0x488aa9]

I'll spend some time on this.

All jobs exploded. What's your model scale and learning rate?
Xingyu
在 2016/6/7 11:14, Feiteng Li 写道:

Hi, guys:
I'm trying CTC on a big dataset more than 2000hours, using
|steps/train_ctc_parallel_h.sh --nj 3|
job 1
|VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After
280196 sequences (343.467Hr): Obj(log[Pzx]) = -34.12 TokenAcc =
65.5557% VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182)
After 290214 sequences (356.577Hr): Obj(log[Pzx]) = -35.0829 TokenAcc
= 66.0633% VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182)
After 300228 sequences (369.041Hr): Obj(log[Pzx]) = -35.5174 TokenAcc
= 64.8673% VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182)
After 310238 sequences (382.234Hr): Obj(log[Pzx]) = -35.9657 TokenAcc
= 65.8774% VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182)
After 320254 sequences (394.763Hr): Obj(log[Pzx]) = -33.7356 TokenAcc
= 66.6929% VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182)
After 330265 sequences (407.316Hr): Obj(log[Pzx]) = -32.8957 TokenAcc
= 67.0366% VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182)
After 340269 sequences (420.524Hr): Obj(log[Pzx]) = -36.0733 TokenAcc
= 66.5803% VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182)
After 350272 sequences (433.553Hr): Obj(log[Pzx]) = -3.06908e+29
TokenAcc = 13.6926% |
job 2
|VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After
290240 sequences (361.23Hr): Obj(log[Pzx]) = -34.8453 TokenAcc =
65.5767% VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182)
After 300251 sequences (374.192Hr): Obj(log[Pzx]) = -34.6744 TokenAcc
= 65.9575% VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182)
After 310255 sequences (386.489Hr): Obj(log[Pzx]) = -32.8376 TokenAcc
= 66.4874% VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182)
After 320258 sequences (399.27Hr): Obj(log[Pzx]) = -34.0779 TokenAcc =
66.6884% VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182)
After 330274 sequences (411.385Hr): Obj(log[Pzx]) = -31.8291 TokenAcc
= 67.3521% VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182)
After 340285 sequences (423.992Hr): Obj(log[Pzx]) = -32.077 TokenAcc =
67.5502% VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182)
After 350304 sequences (437.536Hr): Obj(log[Pzx]) = -3.17996e+29
TokenAcc = 18.6188% |
job 3
|VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After
290221 sequences (367.77Hr): Obj(log[Pzx]) = -33.8591 TokenAcc =
65.0273% VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182)
After 300232 sequences (380.856Hr): Obj(log[Pzx]) = -36.8064 TokenAcc
= 65.3367% VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182)
After 310232 sequences (393.478Hr): Obj(log[Pzx]) = -33.5105 TokenAcc
= 65.6533% VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182)
After 320235 sequences (406.032Hr): Obj(log[Pzx]) = -9.997e+25
TokenAcc = 66.9717% VLOG[1]
(train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After 330242
sequences (418.355Hr): Obj(log[Pzx]) = -32.2745 TokenAcc = 66.3963%
VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After
340247 sequences (433.924Hr): Obj(log[Pzx]) = -41.3272 TokenAcc =
67.6148% VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182)
After 350257 sequences (448.286Hr): Obj(log[Pzx]) = nan TokenAcc =
29.8061% |
job2 crash
|VLOG[1] (train-ctc-parallel:EvalParallel():ctc-loss.cc:182) After
350304 sequences (437.536Hr): Obj(log[Pzx]) = -3.17996e+29 TokenAcc =
18.6188% LOG
(train-ctc-parallel:comm_avg_weights():net/communicator.h:106) Waiting
for averaged model at exp/train_phn_l3_c320/nnet/nnet.iter1.avg500
ERROR (train-ctc-parallel:Check():net.cc:397) 'nan' in network
parameters WARNING (train-ctc-parallel:Close():kaldi-io.cc:446) Pipe
apply-cmvn --norm-vars=true
--utt2spk=ark:data_fbank/train_nodup_tr/utt2spk
scp:data_fbank/train_nodup_tr/cmvn.scp
scp:exp/train_phn_l3_c320/feats_tr.2.scp ark:- | add-deltas ark:-
ark:- | had nonzero return status 36096 ERROR
(train-ctc-parallel:Check():net.cc:397) 'nan' in network parameters
[stack trace: ] eesen::KaldiGetStackTrace()
eesen::KaldiErrorMessage::~KaldiErrorMessage() eesen::Net::Check()
const eesen::Net::Write(std::ostream&, bool) const
eesen::Net::Write(std::string const&, bool) const
comm_avg_weights(eesen::Net&, int const&, int const&, int const&,
std::string const&, std::string const&)
train-ctc-parallel(main+0x1223) [0x48b1e7]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)
[0x7f777206eec5] train-ctc-parallel() [0x488aa9] |
I'll spend some time on this.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/srvk/eesen/issues/60, or mute the thread
https://github.com/notifications/unsubscribe/ADKpxPDC7_oR5QnhqGG0RK5SqlhrmpJfks5qJOIEgaJpZM4IvhCq.

Parallel training from the very beginning is risky. Training with one GPU for one or two iterations and then switching to parallel training might give you greater stability.
@gowayyed may have more insight on this.

@naxingyu
input_feat_dim=120   # dimension of the input features; we will use 40-dimensional fbanks with deltas and double deltas
lstm_layer_num=3    # number of LSTM layers
lstm_cell_dim=320    # number of memory cells in every LSTM layer

 --num-sequence 20 --frame-num-limit 25000 --learn-rate 0.00004

I agree with Yajie, that the training would be very unstable if you parallelize it from the beginning. Part of the reason is that nnet1 does not have the tricks for penalize the parameters in parallel training besides natural gradient, which are applied in nnet2 and nnet3, especially and extensively for training LSTMs. And last time I checked, half a year ago..., the parallel training of nnet1 in Eesen is still far from properly tuned...

I am currently adding natural gradient to nnet1 in eesen. Hopefully, this will add stability to our parallel training.


Build with GitHub Actions

Start experimenting with GitHub Actions.

Coverage remained the same at 91.379% when pulling db8c71e2169d32455a0072d2dcff688bb331c361 on migrate-github-action into e4eb519edb7e28be68a23f21e9f842fbb78fefaf on master.


When parameter's type is incorrect, print the type of the parameter, not its value

should be
        ), f"Wrong kind of query parameters found: {type(query_params)}"
https://github.com/aryn-ai/sycamore/blob/b4fc331e82ed5a7f693945d6b5e294c95ccbd98d/lib/sycamore/sycamore/connectors/duckdb/duckdb_reader.py#L37

I think this gives you both pieces of information - query_params are typically dataclasses, which get a repr method like DuckDBQueryParams(table_name=blah, query=blah, create_hnsw_table=blah)... although I guess in this case we're getting one of the other ReaderQueryParams.
I like to err on the side of putting too much information in error messages rather than too little. That said there may be cases where the type doesn't get reported - e.g. if you override the repr / str method or pass in some other kind of object. Nonetheless users typically won't be interacting with this api - the assert mostly exists for typechecking.
If you want to change this, go ahead an open a PR!


Module has no exported member

Description
I expect to be able to export Combobox and Select from the @ark-ui/vue library using TypeScript.
Link to Reproduction (or Detailed Explanation)
https://stackblitz.com/edit/nuxt-starter-wec8zb?file=components%2FSelect.vue
Steps to Reproduce

Navigate to https://stackblitz.com/edit/nuxt-starter-wec8zb?file=components%2FSelect.vue
Check console for errors

Ark UI Version
0.9.0
Framework

[ ] React
[ ] Solid
[X] Vue

Browser
No response
Additional Information
It seems like some work like ToggleGroup but others like Select and Combobox do not export.

Resolved in v0.10 :)


return an error instead of panicking (#419)

Related issue(s)
Resolves #419
Description
Summary of changes
We return an error instead of unreachable!() when trying to compute with a non supported field operation

Checklist

[X] I have tested the changes locally.
[X] I have formatted the changes with Prettier and/or cargo fmt with default settings.
[X] I have linked this PR to the issue(s) that it resolves.
[X] I have reviewed the changes on GitHub, line by line.
[X] I have ensured all changes are covered in the description.

Additional context
Note that the error is less user-friendly than the previous panic message, this is because errors with no location do not print the secondary message.

let z: Field = 2 << 2;

I believe this should be a type error that we cannot use bitwise operations on fields. What do you think? The error could suggest users cast the fields to an integer type first.

This should no longer be needed now that #687 is merged. I'd expect this condition to be unreachable for bitwise operators now but haven't tested thoroughly.

Closing as this has been handled on the frontend, so the ssa pass can assume that it won't ever happen


base: pagination macro and ckeditor module

[x] using ckeditor as a module
[x] pagination macro

git commit --amend & s/base:/global:/

Thanks for the review @jirikuncar. I've just repushed code with the changes.

I see one more improvement I need to do here. Please do not merge yet.


Some problems with non-English dataset

First of all, I'm really appreciate all of your job here, make this thing become wonderful repo. I'm a student and trying to use this implementation to synthesize Vietnamese for pet project. Because Vietnamese is a tonal language and have accent mark (ex: Xin chào (vietnamese) = Hello) so I have to change something in repo code.

The dataset is about 2 hours and I format this just like LJSpeech
In text/symbols I changed _character into _characters = 'AÁÀẠẢÃĂẰẮẶẲẴÂẤẦẬẨẪBCDĐEÉÈẺẼẸÊẾỀỂỄỆFGHIÍÌỊỈĨJKLMNOÓÒỌỎÕƠỚỜỢỠỞÔỐỒỘỖỔPQRSTUÚÙỤỦŨƯỨỪỰỮỬVWXYZaáàạảãăắằặẳẵâấầậẩẫbcdđeéèẻẽẹêếềểễệfghiíìịỉĩjklmnoóòọỏõơớờợỡởôốồộỗổpqrstuúùụủũưứừựữửvwxyz!\'(),-.:;? ' and I also changed cleaner in hparams to basic_cleaners
In audio.py, I added librosa.effects.trim to trim leading and trailing silence sound.
Then I went to training stuff and when I got to step 10000, i want to test if the model could generate some sound for me but the only thing that i received is just one beep sound and it doesn't last even for 1 second :(
I just try to figure out what is happening for the whole 2 days but i still don't know why and how to fix it so I really need some help. I will attach some pictures, sounds and logs file below here. Tks for support.
P/s: Sry for the bad English though.
source.zip

Try training for longer. 10000 steps is a little bit short for learning a good alignment, and looking at your alignment images, it seems like that may be the case.
It also appears from the images that it's learning to start attending the beginning of the input at a late decoder timestep. This could be caused by not properly trimming the audio. You may want to verify that librosa is correctly trimming the audio.  librosa.effects.trim doesn't always work well with the defaults; you may need to tune some of the optional parameters.
The synthesis code has a heuristic to trim the audio when it thinks it's over.  If your model is learning to synthesize silence at the start of the output, this may not work properly. Try commenting out this line:
https://github.com/keithito/tacotron/blob/master/synthesizer.py#L37

Hope that helps!

@keithito I think change the parameter top_db to higher value in librosa.effects.trim will make the difference. I'll try and report the result to you later. Tks for helping me.
Btw, if i change the batch_size to smaller value, will the model learn alignment badly? Because my GPU has only 2GB RAM so it can only handle batch_size 16 :(

Yes, decreasing batch_size is fine.


Napp management refactor

Adds the NApps directory into the system path, so we can access the napps as python libraries;
Improve the "Load Napp" method;
Adds "Enable" and "Disable" napps methods.

Note: build failed :(


[ClickAwayListener] Fix mounting behavior in Portals in React 17

Backport of #23315
Closes #23215 (magic comment for codesandbox)
Test plan

[x] Added test fails in React 17 before fix: https://app.circleci.com/pipelines/github/mui-org/material-ui/25789/workflows/643b9945-d657-453c-b43b-3bf9de1f512d/jobs/192359
[x] Added test passes in React 17 after fix: https://app.circleci.com/pipelines/github/mui-org/material-ui/25799/workflows/d06820c4-c97d-4e6c-babd-3adbb085d83e/jobs/192367
[ ] Verify fix in codesandbox using this PR:
[ ] existing test pass in React 16 and 17

Will we backport #23311 too?

Will we backport #23311 too?

Let's not stress this and take one step at a time. React 17 is just fresh and I have not seen a reason to rush this out. I'm not aware of any big feature that React 17 needs to be rolled out as soon as possible

Agree, we don't need to rush it. I was wondering about the coming weeks. Should we allow upgrading React and Material-UI independently?

Should we allow developers to upgrade React and Material-UI independently?

This is already possible. The main offender is npm 7. If you're upgrading npm and React 17 at the same time then you're on your own.


refactor: update the Image Optimizer content hook

Summary
Local is going to use the old Image Optimizer content hook, so this migrates back.
Also downgrades the version and minimum Local versions so that we can immediately cut a build and release it once this is merged.

QQ - is 1.1.0 the intended rollback version? Just making sure that's not a typo.

Original slack message had a typo. Intended rollback version is 1.1.0. Sorry for the confusion!


Promise.all for loading wasm

I noticed that in https://github.com/spacebudz/lucid/blob/main/src/core/core.ts modules are loaded sequentially. In Flint, we noticed that at least for us use Promise.all for loading the modules led to a 10% faster startup time

Hey @SebastienGllmt thanks for the hint. So your suggestion is to change it to something like this:
const [resolvedC, resolvedMsg] = await Promise.all([
  importForEnvironmentCore(),
  importForEnvironmentMessage(),
]);

export const C: typeof Core = resolvedC!;

export const M: typeof Msg = resolvedMsg!;

Am I getting this right?


tinyxml: apply patches for CVE-2023-34194 and CVE-2021-42260

Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage (made almost a full rebuild on Linux x86_64, I do not have the resources right now to finish this)
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

nixpkgs-review reveals no new failures, nixos x86_64. Built pkgsMusl, pkgsCross.aarch64-multiplatform, pkgsi686Linux, pkgsLLVM variants successfully.


Refactor ideep workarounds in F.batch_normalization

Addresses https://github.com/chainer/chainer/pull/8175#pullrequestreview-295345169
Takes over  #8206
Note that  #8211 is required to enable relevant test configurations in CIs.

Jenkins, test this please

Jenkins CI test (for commit 23bad23be05bf299bfa7a0a222c4ebbcfeafc3a8, target branch master) failed with status FAILURE.

Jenkins, test this please

Jenkins CI test (for commit 23bad23be05bf299bfa7a0a222c4ebbcfeafc3a8, target branch master) succeeded!


[CT-1599] [Feature] dbt should know more semantic information

Learnings from the past year
Before we get into what this issue is proposing to add to dbt-core, we want to make sure that the community understands what this functionality is building towards. Over the coming years, we envision dbt expanding beyond its current scope to provide users with the best experience in creating their data knowledge graph, comprising three layers:

The Physical Layer: the underlying object, location where data is stored
The Logical Layer: the method of applying dbt transformations to create datasets
The Semantic Layer: the mapping of business noun/verbs onto the logical/physical layer

dbt will tie all of these into a cohesive experience but recognizing them as distinct components provides an experience that is easy to adopt but flexible for many use cases.

Today, dbt has tightly coupled logical and physical layers and a new semantic layer that has initially focused on metrics. But in the past year, we’ve learned that in order to build the broader vision, we have to lay the groundwork of a fully featured semantic layer. Our goals are:

Create a loosely coupled abstraction on top of the logical layer where users can define and consume semantic logic (definitions, relationships, etc.) in their dbt projects.
Maximize efficiency and minimize the error of dbt asset definition for knowledge builders.
Maximize discoverability of dbt assets for data consumers.
Expand the range of tools that can interact with the Semantic Layer and the use cases it can serve.

What problems are we solving?
Here’s what we aim to accomplish in the near- to medium-term with this proposed scope:

Provide users with the foundation for a broader and more flexible semantic layer.
Decrease the effort and difficulty of defining metrics, namely dimension definition.
Ensure that finding the right semantic constructs is possible at scale.

Introducing the entity
To both solve these problems and lay the foundation for a semantic future, we are proposing a new node type called an entity.  entities are top-level nodes within dbt-core and represent the declared interface to a specific model, containing additional metadata (semantic information) that can’t live within models. Each entity will be associated with a distinct business noun/verb and allow for dbt users to create a single universal semantic model across their entire project.
To quote our lovely @jtcohen6 , entities are for everyone. We envision a world where there might be teams of different humans managing the logical layer and the semantic layer given their interest and expertise.

What are our building blocks?
In order to solve these problems, we need to figure out what our building blocks are and whether we need to add anything new:

model: A data transformation that provides the business-conformed representation of the dataset, or more specifically a discrete unit of transformation. This is the building block component of the logical layer.
metric: An aggregation of data (defined on top of an entity) that represents a measurable indicator for the business.

With the introduction of entities, metrics need to change so that they can be built on top of entities as opposed to models. But this is good news! Not only does it allow metrics to inherit a lot of the defined information (making metrics more DRY), but it is also a forcing function to make metrics more flexible.

entity: A new abstraction loosely coupled with a model that allows users to map business concepts onto the underlying logical model.

This is the new “building block” that we’re proposing! We believe this will unlock new functionality and give us the best framework on which to continue building the Semantic Layer.
In other words, the entity construct allows you to define all of your business concepts as first-class representations in your dbt project so all this information can be consumed downstream in your analytics tools of choice.

Fitting in with our story
The ever-present theme of dbt Labs’ story is taking the best practices of software engineering and converting them to the data world. In the case of entities, we’re taking the best practice of API design and contracts between consumers and producers. Software engineering teams don’t expose the underlying table to their consumers – they bundle it in a format that they know matches the consuming behavior. So too should dbt users employ those principles to build their semantic layers.
The entity spec

Property
Description
Example
Required

name
The name of the entity
orders
Yes

model
The name of the model that the entity is dependent on
fact_orders
Yes

description
The description of the entity
Lorem Ipsum
No

dimensions
The list of dimensions and their properties associated with the entity.
See below
No

dimensions.include
Either * to denote all columns or a list of columns that will be inherited
* or [column_a, column_b]
No

dimensions.exclude
If * is set at include_columns, this is a list of columns to be excluded from that list
[column_a]
No

dimensions.name
The name of the dimension
order_location
No

dimensions.column_name
The name of the column in the model if not 1:1. Serves as mapping
location
No

dimensions.data_type
The data type of the dimension
string
No

dimensions.description
Description of the dimension
The location of the order
No

dimensions.default_timestamp
Setting datetime dimension as default for metrics
false
No

dimensions.time_grains
Acceptable time grains for the datetime dimension
[day, week, month]
No

dimensions.primary_key
Whether this dimension is part of the primary key
false
No

What would an example look like?
# models/semantic_layer/product/schema.yml

entity:
  - name: orders
    model: ref('fact_orders')
    dimensions:
       - include: *
       - exclude: [column_c]

    ## An example where we don't want it to inherit everything the model
  - name: organization
    model: ref('dim_organization')
    dimensions:
      - name: organization_id
         type: primary_key

      - name: some_dimension_name
         column_name: some_column_name_that_doesnt_match

Functional requirements

Entities will participate in the dbt DAG as a distinct node type
Entity nodes should be accessible in the dbt Core compilation context via:

the graph.entities variable

Entity nodes should be emitted into the manifest.json artifact
Entity should work with partial parsing
Metric nodes should be supported in node selection and should be selectable with the entity: selector

When listing nodes, existing graph operators (+, &, etc) should be supported

Entities should be surfaced in the dbt Docs website

Similar to metrics, dbt Core itself will not evaluate or materialize entities. These are virtualized abstractions that are exposed to downstream tools/packages for use for the purpose of discovery/understanding and dynamic dataset generation. Properties like data type are also useful for Semantic Layer integrations.
Just as dbt_metrics exists to interact with metrics, we’ll provide a method of interacting with entities that will evolve in this way until it is stable and bundled with dbt-core. The exact format will come in a future issue.
The updated metric spec
With the addition of entities:

Property
Description
Example
Required
Changed

name
The name of the metric
new_customers
Yes
No

label
The human readable name of the metric
New Customers
Yes
No

entity
The name of the entity that the metric is dependent on
customers
Yes
Yes

calculation_method
The method of calculation (aggregation or derived) that is applied to the expression
count_distinct
Yes
No

expression
The expression to aggregate/calculate over
user_id
Yes
No

description
The description of the metric
Lorem Ipsum
No
No

dimensions.include
Either * to denote all columns or a list of columns that will be inherited
* or [column_a, column_b]
No
Yes

dimensions.exclude
If * is set at include_columns, this is a list of columns to be excluded from that list
[column_a]
No
Yes

timestamp
The time-based component of the metric
signup_date
No
No

time_grains
One or more "grains" at which the metric can be evaluated.
[day, week, month, quarter, year]
No
No

window
A dictionary for aggregating over a window of time.
{count: 14, period: day}
No
No

filters
A list of filters to apply before calculating the metric
See below
No
No

config
Optional configurations for calculating this metric
{treat_null_values_as_zero: true}
No
No

meta
Arbitrary key/value store
{team: Finance}
No
No

What would an example look like?
metrics:
 - name: new_customers
   label: New Customers
   entity: customers
   calculation_method: count_distinct
   expression: user_id

   dimensions:
      include: *
      exclude:
        - column_a
        - column_b

What’s changed:

Metrics are now built on top of a entity instead of a model
The timestamp property is now optional.
The time_grains property is now optional. If a timestamp is provided that does not have time_grains associated with it, we will now provide defaults of day, week, month, year
The dimensions property has been split into two properties:

include: This property is either set to * which inherits all of the dimensions from the entity or a list of columns that limits the input
exclude: If include is configured as * then this property can be used to exclude the listed dimensions from the dimension list

How does this impact what you’ve currently built with metrics?
Similar to how we handled changes to the metric spec in the release of dbt-core 1.3.0, we will support the old behavior for a full minor version with backwards compatibility. After that, we will fully deprecate the old properties.
This means that your metric definitions will remain viable for a full minor version upgrade - so if this is launched as part of 1.5.0 then you don’t need to migrate until 1.6.0. That being said, we hope you migrate over earlier for the advantages of using entities 🙂.
Let’s talk about joins
All right, it’s time to address the complex elephant in the room: joins. Supporting joins has been one of the top feature requests that we’ve heard since adding metrics to dbt and we understand why. Joins will allow you to fit metrics into your overall data model (be it Kimball, Inmon, etc.) and expand the ease with which your teams can adopt metrics.
But they’re not part of this issue. And that’s for a good reason: joins are hard.
We’re committed to adding joins in the future but are very aware that supporting this functionality effectively means building two-thirds of a query planner ourselves. And it’s a query planner that needs the underlying information that we will add loosely coupled entities.
This is only further complicated by our goal of providing a universal semantic layer across all entities defined in your project, as opposed to an explore-based semantic layer where relationships may need to be defined multiple times. In this world, our query construction process has to be able to traverse the semantic graph to determine whether a query is not only viable but also if it makes semantic sense. To quote the original metrics issue:

It is extremely common to see folks perform syntactically correct but semantically meaningless calculations over data. This looks like averaging an average or adding two distinct counts together. You get a number back... but it's not a useful or meaningful result.

With all this said, we are committed to adding joins in the future but are taking our time to ensure what we launch is right for analytics engineers, the data consumers, and our integration partners who will build on top of it.
Describe alternatives you've considered
Including this semantic information in the model config
We explored a number of different designs during the ideation process and one of the main alternatives was storing this type of semantic information inside of the model configuration. Ultimately we determined it wasn’t the path forward for a number of reasons:

Storing semantic information in the model config creates a tightly coupled experience between the logical and semantic layers, which would make it difficult to enable our vision of different groups of humans simultaneously contributing to different layers
The goal of the model config is to serve as the implementation detail, whereas the goal of the entity is to be a declared interface. Coupling them together reduces the flexibility of the declared interface
Coupled entities cannot move/migrate to a new underlying model without significant effort, whereas a loosely coupled interface can be pointed at a new model easily.

Are you interested in contributing to this feature?
Absolutely.

Footnotes

A kind soul asked what this new node type would mean for exposures. We imagine exposures serving a very similar, if somewhat more important, role that they do today in that they would represent the consuming experiences sitting on top of entities and metrics!

Resurfacing this related proposal from last year 😄:

https://github.com/dbt-labs/dbt-core/discussions/4621

@aaronsteers we had a response to #4621 in earlier versions of this issue but I think I must have gotten it lost along the way! Let me know if you feel that below is a fair characterization - the problems you raise are very valid but we weren't fully aligned on the implementation existing at that fine a grain.

We’d be remiss to not mention a fantastic issue opened(https://github.com/dbt-labs/dbt-core/discussions/4621) by AJ Steers of Meltano fame! In this issue/discussion, he proposes the addition of a new node type called Attributes . He describes it as:

a foundation for deeper metadata understandings within dbt and to unify the documentation effort for existing dbt projects

We thought about this issue for a while and considered this as a paradigm for expanding semantic layer capability but in the end decided that it felt like it was trying to tackle it two problems at one - both column consistency/documentation across a project and semantic information/structure in a project. The former is very important problem for dbt to consider but not something we consider to be in scope for the semantic layer. Additionally we believe entities are the best building block for semantic information because they are similar in grain/scope to models, whereas attributes map more closely to columns.
Column-level consistency and documentation are problems that we’ll want to tackle but most likely as parts of a separate initiative.

This is so cool. I want to define data models for exploratory data analysis as code. dbt metrics almost meets my expectations. But, as for me, one of the missing pieces is a measure to interactively seek metrics on a BI tool. Of course, We can technically deal with a table created by dbt without dbt semantic layer. But, I would like to define them semantically.
Maturity of metrics defined as dbt metrics may be relatively high in an organization. All stakeholders including business divisions agree with the metrics they should track. We may be able to create dashboards on a BI tool based on dbt semantic layer so that business divisions can track.
Meanwhile, in my opinion, we need another step for data analysts or data scientists to figure out candidates of metrics. After that, they can start a discussion about metrics  which all stakeholders should track. I would like to define and export something to a BI tool for such exploratory data analysis.
If that makes sense, we may be able to put some parts of calculation_method  to the entity layer so that we can define consistent measures like revenue. By doing so, multiple data analysts can use the same definitions even on exploratory data analysis. And ideally I would like to enable to export the definitions through dbt server.

Hello! I've had my tea, finished my digestive 🍪 and have collected my thoughts.

To create a new layer between models and metrics is to add extra complexity. I am not opposed to it, and can understand the desire to add a decoupled layer, but I don't think I've seen a strong enough reason to justify it. That doesn't mean there isn't one, just that it wasn't immediately clear what it is. I believe the core argument is for better collaboration, but wondering if there are others?

Given 1, I think it's important to acknowledge the increase in maintainability and boilerplate that this will cause for AEs. Today an AE is responsible for sources, specs, schemas, docs, tests, exposures, and sql. We are now asking them to also be responsible for metrics.

Apologies for this long-winded example but: consider the experience of writing a new model: experimenting with SQL outside of dbt until the query looks good, migrating that query to dbt as a sql file and updating the references. Opening up a separate file to create the docs, spec, and specify other model attributes, often jumping back and forth between the two. Deciding between where to document a model when there are several models that reference the same data.
Now, open up a third file and create metrics, perhaps with a browser window open to validate the schema of the metrics file. There is a lot of complexity here!
To add Yet Another Yaml (YaYaML ™) to the mix would increase the burden on AEs for maintainability.
What would it look like to update the amount column to incremental_amount as an example?
Update the source, update the staging table, find all usages of that column in all downstream tables and update, find all references in all documentation and tests, and all metrics, and all metric documentation. This change could add another level to these changes. (I understand that you can use include: * but that doesn't preclude column name changes either.
I would love to see some care given to improve this experience somehow, if another level of abstraction is deemed necessary. I wish I had an easy solution that I could just dream up, but alas.

The name entity doesn't give me a strong indication of which models deserve entities and which don't, so would be great to have some opinionated advice here for users.

First off, it’s great to see this new layer being built in public. That the community is invited to chip in.
I hear some of the "concerns" shared above about what would be the added value of defining entities outside their source models. I hear as well the opportunity for greater participation from non-AE folks in defining the semantic layer and not getting their hands dirty in those source models.
An interesting bit that caught my attention in the Slack discussion is "And that doesn't even get into some of the crazy ideas @abhi has around all SaaS businesses having the same entities/metrics and being able to map across all businesses", where common entities+metrics could be uniformed.
So I’m seeing that there might be a case for semantic packages. Something like marketing analytics, product analytics, which usually use the same set of entities and metrics could be packaged. Now it would only just be a matter of setting model source hooks to make those work. So there could be additional value here where communities are responsible for semantic packages and everyone benefits.
I guess my question is what you see as the future that will be unlocked by that building block? Am I off the mark? Or is there something else that you are envisioning that might not be immediately obvious when just focusing on those entities?

@olivierdupuis Thanks for your comment. You're on 🎯 about entities as semantic building blocks.
The main advantage of structuring this design around entities is its ability to detach itself from the logical layer (models) and re-attach itself to any new implementation. This unlocks interesting possibilities by allowing data teams to map sources to entities and gradually standardizing/automating metric and even entity definition (in line with Abhi’s vision). You can see this trend toward (semi-)automation with the dbt metric packages that Fivetran and Houseware released.
We recognize @PedramNavid 's  point about entities adding more complexity for analytics engineers to keep track of. There's a definite tradeoff to adding a new layer to the dbt project. But we've weighed the options: it doesn't make sense to overload models, and while treating metrics as first-class objects helps with lineage, modularity, etc., their definition is too inefficient right now (speaking of having to keep track of columns...).
Introducing entities will help unlock metric definition at scale, lower the barrier of entry for data consumers to get involved (both in entity definition and analysis), and start paving this path to standardized packages.

Zooming in the proposed entity spec's  dimensions.data_type field: If the configuration of datatype on an entity deviated from the corresponding data_type configured on an underlying model column (if provided), would this result in data type coercions within entity query compilation?
If not, validation at parse-time would be necessary to ensure consistency if data_type is configured both in the model column information and a downstream entity dimension. This begs the question - should there be more than one way to encode the same metadata? Perhaps there is actually is a benefit in this case:

We envision a world where there might be teams of different humans managing the logical layer and the semantic layer given their interest and expertise.

Or perhaps this metadata really should just live in the logical layer (on the model), and propagate it's way up to a metric through an entity. Either way - we'd want to be precise in documentation about how this attribute is set and used by consumers.

Now that we've opened https://github.com/dbt-labs/dbt-core/issues/6626 to track the technical implementation, I'm going to convert this more-conceptual issue to a discussion. Members of the community should continue to feel encouraged to respond to threads above, or weigh in with new thoughts.