text:
モデルの数が多いとビルドできない

不具合の内容
モデルの数が多いとビルドに失敗することがわかりました。
再現しようといろいろやってみた感じ、メモリや容量などいろんな原因で落ちえそうでした。
製品版のビルドができないので、どうにかできないか探りたいです。
現象・ログ
条件によって発生するエラーが変わりそうです。とりあえず最低３箇所ほどコケる箇所を見つけました。
ビルド時にメモリ不足エラーになるパターン
条件 build_and_deploy (windows-2019, x86_64-pc-windows-msvc, windows-x64-cuda, cuda, true)
モデル数は10個くらい（製品版）

直前のコマンド
set CARGO=\\?\C:\Users\runneradmin\.rustup\toolchains\1.66.0-x86_64-pc-windows-msvc\bin\cargo.exe&&
set CARGO_CRATE_NAME=voicevox_core&&
set CARGO_MANIFEST_DIR=D:\a\voicevox_core\voicevox_core\crates\voicevox_core&&
set CARGO_PKG_AUTHORS=""&&
set CARGO_PKG_DESCRIPTION=""&&
set CARGO_PKG_HOMEPAGE=""&&
set CARGO_PKG_LICENSE=""&&
set CARGO_PKG_LICENSE_FILE=""&&
set CARGO_PKG_NAME=voicevox_core&&
set CARGO_PKG_REPOSITORY=""&&
set CARGO_PKG_RUST_VERSION=""&&
set CARGO_PKG_VERSION=0.14.0-preview.3&&
set CARGO_PKG_VERSION_MAJOR=0&&
set CARGO_PKG_VERSION_MINOR=14&&
set CARGO_PKG_VERSION_PATCH=0&&
set CARGO_PKG_VERSION_PRE=preview.3&&
set CARGO_WORKSPACE_DIR=D:\a\voicevox_core\voicevox_core\&&
set ORT_OUT_DIR=D:\a\voicevox_core\voicevox_core\target/debug/deps&&
set OUT_DIR=D:\a\voicevox_core\voicevox_core\target\x86_64-pc-windows-msvc\release\build\voicevox_core-b9f66362e93ab750\out&&
set PATH="D:\a\voicevox_core\voicevox_core\target\release\deps;C:\Users\runneradmin\.rustup\toolchains\1.66.0-x86_64-pc-windows-msvc\bin;C:\Users\runneradmin\.rustup\toolchains\1.66.0-x86_64-pc-windows-msvc\bin;C:\Program Files\PowerShell\7;C:\Users\runneradmin\AppData\Roaming\Python\Python38\Scripts;C:\hostedtoolcache\windows\Python\3.8.10\x64\Scripts;C:\hostedtoolcache\windows\Python\3.8.10\x64;C:\Program Files\MongoDB\Server\5.0\bin;C:\aliyun-cli;C:\vcpkg;C:\cf-cli;C:\Program Files (x86)\NSIS\;C:\tools\zstd;C:\Program Files\Mercurial\;C:\hostedtoolcache\windows\stack\2.9.1\x64;C:\cabal\bin;C:\\ghcup\bin;C:\tools\ghc-9.4.2\bin;C:\Program Files\dotnet;C:\mysql\bin;C:\Program Files\R\R-4.2.2\bin\x64;C:\SeleniumWebDrivers\GeckoDriver;C:\Program Files (x86)\sbt\bin;C:\Program Files (x86)\GitHub CLI;C:\Program Files\Git\bin;C:\Program Files (x86)\pipx_bin;C:\npm\prefix;C:\hostedtoolcache\windows\go\1.17.13\x64\bin;C:\hostedtoolcache\windows\Python\3.7.9\x64\Scripts;C:\hostedtoolcache\windows\Python\3.7.9\x64;C:\hostedtoolcache\windows\Ruby\2.5.9\x64\bin;C:\tools\kotlinc\bin;C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\8.0.352-8\x64\bin;C:\Program Files\ImageMagick-7.1.0-Q16-HDRI;C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin;C:\ProgramData\kind;C:\Program Files\Eclipse Foundation\jdk-8.0.302.8-hotspot\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\ProgramData\Chocolatey\bin;C:\Program Files\PowerShell\7\;C:\Program Files\Microsoft\Web Platform Installer\;C:\Program Files\dotnet\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\140\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\150\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\160\DTS\Binn\;C:\Program Files\OpenSSL\bin;C:\Strawberry\c\bin;C:\Strawberry\perl\site\bin;C:\Strawberry\perl\bin;C:\ProgramData\chocolatey\lib\pulumi\tools\Pulumi\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files\CMake\bin;C:\ProgramData\chocolatey\lib\maven\apache-maven-3.8.6\bin;C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code;C:\Program Files\Microsoft SDKs\Service Fabric\Tools\ServiceFabricLocalClusterManager;C:\Program Files\nodejs\;C:\Program Files\Git\cmd;C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\usr\bin;C:\Program Files\GitHub CLI\;c:\tools\php;C:\Program Files (x86)\sbt\bin;C:\SeleniumWebDrivers\ChromeDriver\;C:\SeleniumWebDrivers\EdgeDriver\;C:\Program Files\Amazon\AWSCLIV2\;C:\Program Files\Amazon\SessionManagerPlugin\bin\;C:\Program Files\Amazon\AWSSAMCLI\bin\;C:\Program Files (x86)\Google\Cloud SDK\google-cloud-sdk\bin;C:\Program Files (x86)\Microsoft BizTalk Server\;C:\Program Files\LLVM\bin;C:\Users\runneradmin\.dotnet\tools;C:\Users\runneradmin\.cargo\bin;C:\Users\runneradmin\AppData\Local\Microsoft\WindowsApps"&&
rustc \
    --crate-name voicevox_core \
    --edition=2021 crates\voicevox_core\src\lib.rs \
    --error-format=json \
    --json=diagnostic-rendered-ansi,artifacts,future-incompat \
    --crate-type lib \
    --emit=dep-info,metadata,link -C opt-level=z -C panic=abort -C linker-plugin-lto -C codegen-units=1 \
    --cfg "feature=\"default\"" -C metadata=ed3d2571d29b86cc -C extra-filename=-ed3d2571d29b86cc \
    --out-dir D:\a\voicevox_core\voicevox_core\target\x86_64-pc-windows-msvc\release\deps \
    --target x86_64-pc-windows-msvc -C strip=symbols -L dependency=D:\a\voicevox_core\voicevox_core\target\x86_64-pc-windows-msvc\release\deps -L dependency=D:\a\voicevox_core\voicevox_core\target\release\deps \
    --extern anyhow=D:\a\voicevox_core\voicevox_core\target\x86_64-pc-windows-msvc\release\deps\libanyhow-e311d84d2ae5f1bd.rmeta \
    --extern cfg_if=D:\a\voicevox_core\voicevox_core\target\x86_64-pc-windows-msvc\release\deps\libcfg_if-1b2fefb99f35c1ac.rmeta \
    --extern derive_getters=D:\a\voicevox_core\voicevox_core\target\release\deps\derive_getters-bdc2b9be890608c2.dll \
    --extern derive_new=D:\a\voicevox_core\voicevox_core\target\release\deps\derive_new-193d5d398ca2b8b8.dll \
    --extern easy_ext=D:\a\voicevox_core\voicevox_core\target\release\deps\easy_ext-c8513404ba948c4d.dll \
    --extern humansize=D:\a\voicevox_core\voicevox_core\target\x86_64-pc-windows-msvc\release\deps\libhumansize-f92be8cf700737bf.rmeta \
    --extern once_cell=D:\a\voicevox_core\voicevox_core\target\x86_64-pc-windows-msvc\release\deps\libonce_cell-a8b363df0211d2af.rmeta \
    --extern onnxruntime=D:\a\voicevox_core\voicevox_core\target\x86_64-pc-windows-msvc\release\deps\libonnxruntime-745a3ab4dc786ce6.rmeta \
    --extern open_jtalk=D:\a\voicevox_core\voicevox_core\target\x86_64-pc-windows-msvc\release\deps\libopen_jtalk-10596d27880a956a.rmeta \
    --extern regex=D:\a\voicevox_core\voicevox_core\target\x86_64-pc-windows-msvc\release\deps\libregex-0ded4cbdca58710a.rmeta \
    --extern crypto=D:\a\voicevox_core\voicevox_core\target\x86_64-pc-windows-msvc\release\deps\libcrypto-0deec0492876c445.rmeta \
    --extern serde=D:\a\voicevox_core\voicevox_core\target\x86_64-pc-windows-msvc\release\deps\libserde-7a9f90bfb5f9363c.rmeta \
    --extern serde_json=D:\a\voicevox_core\voicevox_core\target\x86_64-pc-windows-msvc\release\deps\libserde_json-0d7954154b93def5.rmeta \
    --extern thiserror=D:\a\voicevox_core\voicevox_core\target\x86_64-pc-windows-msvc\release\deps\libthiserror-744b5f43c2548d0f.rmeta \
    --extern tracing=D:\a\voicevox_core\voicevox_core\target\x86_64-pc-windows-msvc\release\deps\libtracing-d7f48c81c4a45c7b.rmeta \
    --extern windows=D:\a\voicevox_core\voicevox_core\target\x86_64-pc-windows-msvc\release\deps\libwindows-fa63703c9fd56ce6.rmeta -L native=D:\a\voicevox_core\voicevox_core\target\x86_64-pc-windows-msvc\release\build\onnxruntime-sys-fe29254348da4667\out\onnxruntime_1.13.1_gpu\onnxruntime-win-x64-gpu-1.13.1\lib -L D:\a\voicevox_core\voicevox_core\target\x86_64-pc-windows-msvc\release\build\open_jtalk-sys-535ef1e8a7775d9b\out\lib -L native=D:\a\voicevox_core\voicevox_core\target\x86_64-pc-windows-msvc\release\build\link-cplusplus-49b32c1d24ce522c\out -L native=D:\a\voicevox_core\voicevox_core\target\x86_64-pc-windows-msvc\release\build\rust-crypto-a1ce123bc792a06e\out -L native=C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\windows_x86_64_msvc-0.42.0\lib

↓エラーログ
memory allocation of 2677983328 bytes failed
error: could not compile `voicevox_core`

whl作成時にディスク容量不足で落ちるパターン
条件 build_and_deploy (windows-2019, x86_64-pc-windows-msvc, windows-x64-cuda, cuda, true)
モデル数は15個くらい（OSS版）
Actions https://github.com/Hiroshiba/voicevox_core/actions/runs/3827454551/jobs/6512049285
↓エラーログ
LLVM ERROR: IO failure on output stream: no space on device
**m**merror**m:**m could not compile `voicevox_core`
💥 maturin failed
  Caused by: Failed to build a native library through cargo
  Caused by: Cargo build finished with "exit code: 1***1": `"cargo" "rustc" "--release" "--features" "," "--target" "x86_64-pc-windows-msvc" "--manifest-path" "./crates/voicevox_core_python_api/Cargo.toml" "--message-format" "json" "--lib"`
Error: Process completed with exit code 1.

エラーよくわからずubuntuでビルド中に落ちるパターン
条件 build_and_deploy (ubuntu-20.04, x86_64-unknown-linux-gnu, linux-x64-cpu, cpu, false)
モデル数は30個くらい（OSS版）
Actions https://github.com/Hiroshiba/voicevox_core/actions/runs/3827526829/jobs/6512187257

直前のコマンド
（0が***になっててよくわからなくなってる）
CARGO=/home/runner/.rustup/toolchains/1.66.***-x86_64-unknown-linux-gnu/bin/cargo \
CARGO_CRATE_NAME=voicevox_core \
CARGO_MANIFEST_DIR=/home/runner/work/voicevox_core/voicevox_core/crates/voicevox_core \
CARGO_PKG_AUTHORS='' \
CARGO_PKG_DESCRIPTION='' \
CARGO_PKG_HOMEPAGE='' \
CARGO_PKG_LICENSE='' \
CARGO_PKG_LICENSE_FILE='' \
CARGO_PKG_NAME=voicevox_core \
CARGO_PKG_REPOSITORY='' \
CARGO_PKG_RUST_VERSION='' \
CARGO_PKG_VERSION=***.***.*** \
CARGO_PKG_VERSION_MAJOR=*** \
CARGO_PKG_VERSION_MINOR=*** \
CARGO_PKG_VERSION_PATCH=*** \
CARGO_PKG_VERSION_PRE='' \
CARGO_WORKSPACE_DIR=/home/runner/work/voicevox_core/voicevox_core/ \
LD_LIBRARY_PATH='/home/runner/work/voicevox_core/voicevox_core/target/release/deps:/home/runner/.rustup/toolchains/1.66.***-x86_64-unknown-linux-gnu/lib:/home/runner/.rustup/toolchains/1.66.***-x86_64-unknown-linux-gnu/lib:/opt/hostedtoolcache/Python/3.8.15/x64/lib' \
ORT_OUT_DIR=/home/runner/work/voicevox_core/voicevox_core/target/debug/deps \
OUT_DIR=/home/runner/work/voicevox_core/voicevox_core/target/x86_64-unknown-linux-gnu/release/build/voicevox_core-238e8c15cdeefd83/out \
rustc \
    --crate-name voicevox_core \
    --edition=2***21 crates/voicevox_core/src/lib.rs \
    --error-format=json \
    --json=diagnostic-rendered-ansi,artifacts,future-incompat \
    --crate-type lib \
    --emit=dep-info,metadata,link -C opt-level=z -C panic=abort -C linker-plugin-lto -C codegen-units=1 \
    --cfg 'feature="default"' -C metadata=1eeee7***1b6db7cb7 -C extra-filename=-1eeee7***1b6db7cb7 \
    --out-dir /home/runner/work/voicevox_core/voicevox_core/target/x86_64-unknown-linux-gnu/release/deps \
    --target x86_64-unknown-linux-gnu -C strip=symbols -L dependency=/home/runner/work/voicevox_core/voicevox_core/target/x86_64-unknown-linux-gnu/release/deps -L dependency=/home/runner/work/voicevox_core/voicevox_core/target/release/deps \
    --extern anyhow=/home/runner/work/voicevox_core/voicevox_core/target/x86_64-unknown-linux-gnu/release/deps/libanyhow-f5c8cf85eb83ed9a.rmeta \
    --extern cfg_if=/home/runner/work/voicevox_core/voicevox_core/target/x86_64-unknown-linux-gnu/release/deps/libcfg_if-29861b95ab48e18a.rmeta \
    --extern derive_getters=/home/runner/work/voicevox_core/voicevox_core/target/release/deps/libderive_getters-9ff99167fb7***3ef2.so \
    --extern derive_new=/home/runner/work/voicevox_core/voicevox_core/target/release/deps/libderive_new-77b61***8dda354e88.so \
    --extern easy_ext=/home/runner/work/voicevox_core/voicevox_core/target/release/deps/libeasy_ext-5948e2ed9784755f.so \
    --extern once_cell=/home/runner/work/voicevox_core/voicevox_core/target/x86_64-unknown-linux-gnu/release/deps/libonce_cell-9a9ef365db46ccc6.rmeta \
    --extern onnxruntime=/home/runner/work/voicevox_core/voicevox_core/target/x86_64-unknown-linux-gnu/release/deps/libonnxruntime-2ee5***1deeb3ede***7.rmeta \
    --extern open_jtalk=/home/runner/work/voicevox_core/voicevox_core/target/x86_64-unknown-linux-gnu/release/deps/libopen_jtalk-a***693558ae2a8399.rmeta \
    --extern regex=/home/runner/work/voicevox_core/voicevox_core/target/x86_64-unknown-linux-gnu/release/deps/libregex-9***7cc5b41894985.rmeta \
    --extern serde=/home/runner/work/voicevox_core/voicevox_core/target/x86_64-unknown-linux-gnu/release/deps/libserde-2e***cfba92712d32c.rmeta \
    --extern serde_json=/home/runner/work/voicevox_core/voicevox_core/target/x86_64-unknown-linux-gnu/release/deps/libserde_json-3be7a6d916ee7812.rmeta \
    --extern thiserror=/home/runner/work/voicevox_core/voicevox_core/target/x86_64-unknown-linux-gnu/release/deps/libthiserror-8794de6c89319ad***.rmeta -L native=/home/runner/work/voicevox_core/voicevox_core/target/x86_64-unknown-linux-gnu/release/build/onnxruntime-sys-2***65e4eedc33aee5/out/onnxruntime_1.13.1_cpu/onnxruntime-linux-x64-1.13.1/lib -L /home/runner/work/voicevox_core/voicevox_core/target/x86_64-unknown-linux-gnu/release/build/open_jtalk-sys-86159944b2***fd882/out/lib -L native=/home/runner/work/voicevox_core/voicevox_core/target/x86_64-unknown-linux-gnu/release/build/link-cplusplus-ed73d1f25e411385/out

↓エラーログ
Error: Process completed with exit code 1***1.

（たぶんexit codeは101）
再現手順
crates\voicevox_core\src\include_models.rsのModelをいっぱいコピーしてビルド
期待動作
ビルドが通る
その他
モデル15個くらいはビルドできると嬉しいけど、難しそう。
たぶんモデルバイナリをinclude_bytesしてるのが重い原因･･･？
他に組み込みにできる方法あるとコード書き換え量が少なくて済むので嬉しい。
↑の実現が難しい場合は、クラス構造議論でも検討中な「外部ファイルモデルの読み込み」に対応させるしかない気がする。

https://github.com/rust-lang/rust/issues/65818#issuecomment-570298622
こちらに大きなblobファイルをinclude_bytes!すると莫大なメモリを消費してコンパイルにやたら時間がかかることが報告されていますね
https://github.com/rust-lang/rust/pull/103812
おそらくこのPRでコンパイル速度については解決されているようなので、これが入ったバージョン1.67.0からメモリ問題も解決される可能性がありますが、まだnighty buildのようです

代替手段を利用したとしても似たような問題はでそうなので根本的な解決はこれじゃないでしょうか

↑の実現が難しい場合は、https://github.com/VOICEVOX/voicevox_core/issues/280議論でも検討中な「外部ファイルモデルの読み込み」に対応させるしかない気がする。

とりあえず今回を乗り切るためにincludeの展開先のファイルを分けてみたりcrateを分けてみたりするのを試してみても良いかもしれません。成功する保証はないですが

個人的には @qwerty2501 さん意見に賛成で、抜本的な解決は外部ファイル化だと感じています。
メモリだけではなくディスク容量の不足とかもわりと近そうなので、抜本的にはこれかなと。
crate分けるのもそこそこ簡単にできそうなのであればぜひという感じではあります。
可能なら0.14を1月末辺りにリリースしたいなと思っていて、1.67が1月23日っぽく、ちょっと厳しいかも･･･？
（かなり大規模アプデになるのでちょっと１月末リリースは難しいかもという雰囲気を感じていますが）
うーーーーーん。

とりあえず30個くらいのモデル (https://github.com/Hiroshiba/voicevox_core/commit/9985ce6a3bde797633d6e7c4e2a1f1aac4490cdb) を手元で試しましたが、メモリを8GBちょっと使ったあたりで次のエラーになりました(Actionsに出ているのと同じ)。
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: TryFromIntError(())', compiler/rustc_metadata/src/rmeta/table.rs:234:49

この文面を見た感じ、計算機のリソースとは関係がなさそうに見えます。

nightly-2023-01-03ですが少なくともモデル30個版は駄目っぽいですね。

お試しありがとうございます！！

駄目っぽいですね

なるほど～～～～

モデル15個版は私の計算機だと1.66でも余裕なのでそもそも違いがわからず。maturin buildについては手元で実験するのが怖い...

僕も手元の環境だと動いたんですが、pushしてactions回すと（勝手に回る）エラーになったので悲しかったです。
まあ外部ファイル読み込み化かな～という気持ちになりつつあります！！
VOICEVOX初期は外部ファイルだったのでそこに戻る形になりそうな気持ちです。

nightly-2023-01-03に切り替えたやつを私のフォークにpushしてみました。違いが出るかどうか...
https://github.com/qryxip/voicevox_core/actions/runs/3830907932

あ、駄目ですね落ちた。

issue作成してみました！

https://github.com/VOICEVOX/voicevox_core/issues/363


text:
build.ymlのonnxruntimeがビルドできない

不具合の内容
linuxのarm用（？）にonnxruntimeの自動ビルドを用意しているのですが、エラーで落ちてしまうっぽいです。
現象・ログ
https://github.com/VOICEVOX/voicevox_core/runs/4641665798?check_suite_focus=true

再現手順
forkしてreleaseタグを作ってビルドする
その他
プライベートリポジトリでもビルドしているのですが、通らなくてちょっと困っています。
別途onnxruntimeをビルドするリポジトリを作ってそちらに移してしまってメンテするのもありなのかなと感じました。

@aoirint もし簡単に直せそうだったら修正お願いできるととても嬉しいです・・・！
とりあえず該当ビルドをパスできるようにしようかなと思います。

動的にmatrixを変更するのがちょっと泥沼になりそうだったので引き返してきました。
https://swfz.hatenablog.com/entry/2021/06/29/195359
別リポジトリにきりだそうとしてみます・・・！

別リポジトリを作って、onnxruntimeをビルドする部分を切り出してみました。

https://github.com/VOICEVOX/onnxruntime-builder/pull/1

checkoutで落ちるのは大分奇妙ですね。アクセスしているリポジトリは実在するようです。
https://www.githubstatus.com/ をみるとGitHub Actionの調子が悪いようなので放っておけば勝手に直るかもしれません

Investigating - We are investigating reports of degraded performance for GitHub Actions.
Dec 27, 13:20 UTC

おお、なるほどです！！　ステータスチェックしておけばよかったです。
別リポジトリにして管理しておくのは、たしか当時もorganizationできたら分離したいと思っていたことだったので、このまま別リポジトリにしちゃおうかなと思います。

Yosshi999さんの指摘通り、GitHub Actionsの一時的な不調だと思いました。
ONNX Runtimeのビルドはこのまま別リポジトリに分けてしまっていいと思います。
voicevox_core側では、分けたリポジトリのReleaseからビルド済みのarmhf用ONNX Runtimeをダウンロードしてくるようにすればいいかなと思いました！
armhf対応を入れたのはわたしなので、ENGINEのONNX対応が終わったら調整してみたいと思います（他にやってもいいという方いればおまかせします）。

ヒホさんONNX Runtimeのリリース作成ありがとうございます。
いくつか修正したいところがあったので、いったん書いておきます。
本家のONNX RuntimeのReleaseでは圧縮ファイルの中の一番上はディレクトリ（圧縮ファイルのファイル名と同じ名前）になっているので、それに合わせたいです（core側の自動ビルドはこれが前提になっています）。
形式はURL末尾の拡張子で分岐させているのでzipでもtgzでも動作しますが、本家のLinux版はtgzになっているので、Releaseではtgzにしておきたいです。
core側では、同一リポジトリでビルドしたONNX Runtime用にmatrixにonnxruntime_artifact_nameを用意していましたが、別リポジトリでビルドすることになったので不要になりました。coreのarmhfビルドを入れるときに、これを使った処理は消してしまってよさそうです。

異論ないです、使いやすいようにしちゃいましょう！

@aoirint プルリクマージしました！
releasesのタグはどうするのが都合良さそうでしょうか。
以前作った1.9.1を一回消してまた作り直すか、1.9.1.1みたいにさらに刻むかなどを考えています。
（どちらでもよければ後者にしようかなと思ってます）

タグ

1.9.1.1みたいに刻むのがいいかなと思いました。キャッシュでURLを使っていたと思うので、バージョンは変えたいと思いました。

source: gharchive/issue

authors: Hiroshiba Yosshi999 aoirint

license: MIT

license_type: permissive

license_source: github-api


text:
download_testのトリガーを更新

内容
download_testのon.pull_request.pushに #375 で追加したRust版ダウンローダーを入れます。
関連 Issue
その他

問題ないと思うのでマージします！

source: gharchive/pull-request

authors: Hiroshiba qryxip


text:
Taking confirmation from user if he want to leave the app or not

We can add an feature in which if user press the back button to leave the app a pop screen will come and ask the user Please confirm
do you want to leave the app.
As we are creating an app for childern there might be possiblity that by mistake the app is closed so if we add this feature it would be great

Instead confirmation add the toast saying press back again to exit.

okay so will you please assign it to me

@sapatevaibhav I have created a pull request of this issue. Please let me know if any change is needed.
Thank you for your kind attention

i would like to contribute to this issue... kindly assign me i am GSSOC'24 contributor

#46

authors: Prathme07 Shubham-Zone sapatevaibhav

repo: VaibhavCodeClub/learn


text:
Error after test has passed is not catched

If a test has passed succesfully but a error is logged after all assertions, this is not catched by the utility.

Do you have an example of such a case?

Do you have an example of such a case?

This works as expected:
it('tests something', () => {   console.error('hello');   expect(1).toEqual(1); });
But if the error comes from something asynchronous that errors after the assertion has successfully passed, catching the error won't happen. Something like this:
it('tests something', () => {   setTimeout(() => {       console.error('hello');     }, 100);   expect(1).toEqual(1); });

The issue is that the console error happens when the rest is supposed to be finished.
Having something run later like this without telling Jest about it is error prone.
You can use the done callback to handle this properly: https://jestjs.io/docs/asynchronous#callbacks

I ran into this problem unexpectedly and Jest is able to show me these errors but this utility is not able to make the test fail because of this error. And since it was unexpected I might not be able to take it into account using callbacks. So the problem I have is that I get an error that I'd like to have fixed before a PR is merged but Github actions is unable to let me know this happens because I'm not able to make the test fail even though there is an error.
I understand that this is problematic. Do you have any suggestions or is this just something I have to live with not being able to catch these in my Github actions?

I'm not sure there is much we can do. Indeed, the lib relies on the afterAll callback from Jest. If the error happens after Jest calls it, we will not be able to detect it.

I'm not sure there is much we can do. Indeed, the lib relies on the afterAll callback from Jest. If the error happens after Jest calls it, we will not be able to detect it.

I appreciate you taking the time to reply in a quick manner. Thanks! I'll close this one.

You are welcome. Thank for your understanding!

authors: ValentinH janpe

repo: ValentinH/jest-fail-on-console


text:
Need help with YouTube Live Ingest using HLS

Hi there,
I'm currently working on a project that involves live streaming to YouTube using the HLS protocol. I came across your webm-muxer library and was impressed with its performance and simplicity.
However, I'm having trouble figuring out how to use it with YouTube's Live Ingest feature. I was wondering if you could provide some guidance or examples on how to do this.
Any help would be greatly appreciated!
Thank you.
Best regards.

Ahh, I sadly don't know much about this area. Given YouTube's docs, it seems like you'll need to send the data using DASH (which supports VP9), a protocol that runs over HTTP. Not quite sure what goes into that format, but I recall this PR mentioning live-streaming + DASH. Also no idea if you can also send WebM stuff over HLS.
Not sure if this library alone is enough for live-streaming, seems like in that PR they also used ffmpeg. I personally don't think requiring ffmpeg for anything client-side is a good idea, 'cause it's big and bulky. But yeah, I'm afraid I can't help you very much here, but continue reading into the topic and I'm sure you'll get somewhere!

repo: Vanilagy/webm-muxer


text:
BinaryView subclasses without init crash

from binaryninja import *
class FooViewUpdateNotification(BinaryDataNotification):
def init(self, view):
self.view = view
class FooView(BinaryView):
name = "Foo"
def __init_(self, data):
    BinaryView.__init__(self, data.file)
    self.notification = FooViewUpdateNotification(self)

@classmethod
def is_valid_for_data(self, data):
    return True

def init(self):
    return True

FooView.register()
This crashes with a NULL dereference.

I just tried this code and failed to repro the NULL dereference. Does this still exist in the lastest build?

Unable to repro, could be fixed.

authors: gynophage plafosse


text:
[UpdatePlugin]  Martyx00 VulnFanatic 2.2

Please update my plugin:
Author: Me
Repo name: VulnFanatic
Release: https://github.com/Martyx00/VulnFanatic/releases/tag/2.2

Added, thanks.

license: mit

license_source: bigquery


text:
Mounted Maniac in Turn Based

In TB, for the first round, a mounted character can't charge. (Owlcat bug / limitation). The only way to charge is to select their mount and have the mount charge. When this happens the mount attacks, as does the character, but that doesn't seem to cause Mounted Maniac to proc.
Can this use case be handled?

Mounted Maniac is not proccing on Darean (with Mount from Second Mystery Nature) in any case, even in subsequent rounds when he isn't Staggered and Charges himself.

I think the issue might be that it is the Surprise Round - which only allows a Standard Action - while Charge is a Full Round action, therefore illegal in the Surprise round.
Either wait for the regular round to Charge or use Charge to initiate combat - then it should succeed.

authors: Bezhukov Haplokus Lazasar


text:
Include filename case doesn't match source includes

So how did you manage to get these to build?
Ok once case is changed.

Development of this library has actually mostly been abandoned due to time restraints. The library could still use a lot of rework. Feel free to submit pull requests for new code or bugfixes.

authors: gunthervb tvjon


text:
Goofy ahh hand!

Make it so the hand's distance wont change based on FOV or at least make it an option.

I support this. This even used to be vanilla behavior up until some point.

authors: Lassebq kianfakheriaghdam

repo: VendoAU/FOV


text:
[VEN-798] feat: add an allowlist for liquidations

In some cases we want to restrict those able to liquidate a certain borrower. This PR makes it possible to add "liquidation restrictions". If the liquidation is restricted, only those in allowlist can liquidate the borrower's position.

@kkirka Lint CI is failing. I usually run these commands to make it pass: yarn lint:sol --fix && yarn lint:ts --fix &&  yarn prettier

yarn lint:sol --fix && yarn lint:ts --fix && yarn prettier

We can add this command to the package.json too
"yarn:fix": "yarn lint:sol --fix && yarn lint:ts --fix && yarn prettier"

authors: coreyar kkirka narayanprusty

repo: VenusProtocol/venus-protocol


text:
feat: Working with multipart:form-data

Description
It will be good if dart_frog will work with multipart:form-data, for uploading images or files and for just requests
Requirements

[ ] Adding multipart:form-data
[ ] Adding support for image upload

is there a way to get shelf router's Request object from frog's Request?

is there a way to get shelf router's Request object from frog's Request?

No, Dart Frog abstracts shelf, shelf is just an implementation detail

i copied some code from shelf_multipart but Multipart() constructor ask for shelf's Request. ok then 🤷.

You can use shelf_adapters to use a Shelf implementation. https://github.com/VeryGoodOpenSource/dart_frog/blob/main/packages/dart_frog/lib/src/shelf_adapters.dart

authors: aaltynbek felangel qrhfz ushieru


text:
[QUESTION] GitHub Workflow Action

Is there a GitHub workflow action for this that you can use to run lint check? I'm currently using the Flutter lint, but would nice if there was an action for this

You should write analysis_options.yaml that include package:very_good_analysis/analysis_options.yaml, then it works.
You don't need to write something in workflow file

That is not how workflow file works, its will use the analysis provided in the workflow file in the GitHub actions

That is not how workflow file works, its will use the analysis provided in the workflow file in the GitHub actions

Very Good Workflows just runs the flutter/dart analyze command which uses the analysis options you have in your project. As @SuhwanCha mentioned you can adjust your analysis_options.yaml to your liking and if you don’t have warnings or errors being reported locally you shouldn’t have any warnings or errors reported by the workflow.
Hope that helps 👍

That is not how workflow file works, its will use the analysis provided in the workflow file in the GitHub actions

Please see the following workflow file, there isn't analysis options in workflow file
https://github.com/felangel/bloc/blob/master/.github/workflows/flutter_bloc.yaml#L29-L33
When used like this, that command uses analysis_options.yaml.  You don't adjust options in workflow file, you need to set them in analysis_options.yaml.

Closing for now since there doesn’t appear to be any actionable next steps but feel free to comment with any follow up questions and I’m happy to continue the conversation 👍

Hey Felix - I'm running into an issue with JSONSerializable and build_runner where the generated code doesn't satisfy the very_good analysis linter rules. Is the only fix to suppress the warning by setting cast_nullable_to_non_nullable: false in the linter rules? Or can this be resolved by changing something in my model?

@ericduffett in my case, I add **.g.dart in exclude
analyzer:
  exclude:
    - lib/**.g.dart

@ericduffett in my case, I add **.g.dart in exclude
analyzer:
  exclude:
    - lib/**.g.dart

Thank you! That's a much better solution!

authors: SuhwanCha ericduffett felangel isAlmogK


text:
Driver not working on Windows Server 2019

Description
I installed the latest version (ViGEmBus Setup 1.17.333) on a new Windows Server 2019 instance on AWS EC2.
Installation was successful and driver is visible in Device Manager. Unfortunately I cannot communication with the driver using the .NET API. The following error appears when connecting:
System.ComponentModel.Win32Exception: 'The operation completed successfully'
My program is working perfectly on my local Windows 10 machine with the same driver...
To Reproduce

Get new EC2 instance with Windows Server 2019
Install driver
try to .Connect() a new instance using .NET API.

Screenshots

System details (please complete the following information):

OS: Windows Server 2019
Feeder software: https://github.com/ViGEm/ViGEm.NET
Driver Version: 1.17.333

Additional info
I also tried to install the previous release (ViGEmBus Setup 1.16.116). With this version, the program runs without errors, BUT the commands do not come through...

Server 2019 lacks the mandatory Xbox 360 drivers, have you installed them? Is the bus driver even present in Device Manager? Call stack?

I just tried to install the Xbox 360 drivers from, here (https://www.techspot.com/drivers/driver/file/information/17648/) but this did not help. Is there another driver that I could try?
In the Device Manager I can see that the Nefarius Virtual Gamepad Emulation Bus is installed. And as long as my Visual Studio Application is not stopped and stuck at the .Connect() command the "Other Device" Virtual Xbox 360 Controller gets visible. Maybe that helps?

The Call Stack is not very helpful:

Thanks a lot for your help!

Yeah, as I said, Xbox 360 Driver is missing so the virtual controller can't boot and therefore nothing will work as expected.
Please don't just randomly copy parts of drivers around like that, it's a brilliant way to test if you have a good backup 🙂
Use the archived copy of the X360 driver instead.

Great this was the missing piece! 😉
Thank you!

authors: benjaminburkhardt nefarius

repo: ViGEm/ViGEmBus


text:
MGUI ThreadSafety ?

Is MGUI threadsafe by design ?
Would the following code be threadsafe and work as expected ?
 MGTextBlock Button_Text = Window.GetElementByName<MGTextBlock>("Button_Text");
 Task.Run(() => Button_Text.Text = "REERD" );

There is no explicit multi-threading safety. I'd venture a guess that it would work fine in most cases. If you're just planning to use a single background thread then I doubt it'd cause issues. But if you plan to use multiple threads, which may need to modify the same properties concurrently, I'd guess that there could be some issues.
For example, when the Text property on an MGTextBlock is modified, some computations take place to re-calculate which substrings of the text should go on which line numbers. If thread 1 changed Text, and then thread 2 changed Text while thread 1 was still recalculating the text lines, and then thread 2 finished calculating the lines before thread 1, it could end up setting the text lines to a value that corresponds to an old Text. This scenario is unlikely since it's usually not a very expensive operation, so the threads probably wouldn't interweave those calculations (although I guess it could be expensive if the textblock had a very large amount of text to parse).
Input handling and layout calculations are always processed during MGDesktop.Update so those should be unaffected by multi-threading.
Also, I once did run into an issue when running code from a non-STA thread.
0ee22f375bd5100fc49688ac8e1c5b3aec3987d2
I was opening a file browser dialog in response to a button click, but using an OpenFileDialog from a non-STA thread was throwing an error. So it's possible that other obscure issues like that could occur with multi-threading.


text:
Add files via upload

Description
This is a folder, containing the basic if/else programs made with the solidity programming lang.
It contains basic logic based and application based programs.
Fixes #<39>
Type of change
Please delete options that are not relevant. In order to tick the check box just put x inside them for example [x] like this :

[x] Add a new project

[x] Improve the readme of any project

Domain of Contribution
Please delete options that are not relevant. In order to tick the check box just put x inside them for example [x] like this

[x] Project using only Solidity

[x] Project Test on the Remix IDE

Checklist ✓
Please delete options that are not relevant. In order to tick the check box just put x inside them for example [x] like this

[x] l have performed a self-review of my own code or work.

[x] I'm a SSOC'23 contributor

Fixes #<39> please give a space b/w these two
Write like this in  this PR template Fixes #39 . Hop u get  this ,

Thank's for raising this pr . Hope  to see more  PR like this from your side .


text:
🛑 ASIP is down

In 967981d, ASIP (https://asip10.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ASIP is back up in 106433f.

repo: Vikingfr/upptime


text:
🛑 Rue de la coloc is down

In fb5a102, Rue de la coloc ($COLOC) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Rue de la coloc is back up in c61b740.


text:
🛑 flashform is down

In e1fd4e0, flashform ($FLASHFORM) was down:

HTTP code: 503
Response time: 1082 ms

Resolved: flashform is back up in 9b944ac.


text:
🛑 SCOP276 is down

In 6e1d88b, SCOP276 ($SCOP276) was down:

HTTP code: 0
Response time: 0 ms

Resolved: SCOP276 is back up in 3a53f2f.


text:
fix list page filtering not working

When I started using the blank theme, I found urls like http://example.com/tags/js would list all posts instead of just posts tagged 'js' which is what I expected. Changing .Site.Pages to 'Data.Pages' fixes this, and now my site can have lists that filter posts by category and tags. Maybe this is useful for someone else too.
There's a discussion about the difference between .Site.Pages and .Data.Pages here: https://discourse.gohugo.io/t/whats-the-difference-between-site-pages-and-data-pages/2252

Good catch! Thank you.

authors: Vimux adamsullovey

repo: Vimux/blank


text:
Pretraining/Finetuning XPhoneBERT on custom languages

Hi,
I'm planning to pre-train/finetune the XPhoneBERT model for other indic languages (which do not support currently) for my research work. For this, I'm training the CharsiuG2P with the indic languages. It would be very helpful to know if anyone has fine-tuned or pre-trained this model on custom languages. If anyone has done this before or has relevant resources, please share your insights here.

I think you can pre-train a BERT-based model for phoneme representation for only indic languages. For converting text2phoneme, you can use another tool like phonemizer that can convert text2phoneme instead of training a new tool to do it. You can read some papers like MixPhoneBERT or MPhoneBERT, which are phoneme representation models for only English language.

repo: VinAIResearch/XPhoneBERT


text:
Fix typo

PR to fix a small typo

@rafaelcpalmeida thank you for your fix!

authors: c-seeger rafaelcpalmeida

repo: Virtomize/confluence-go-api


text:
Refactor/icons kidnapping

There's a problem with hijacking icons like that: they're subject to change b/w Intellij versions, and at some point they might be changed so that they still will be adequate for their original purpose, but no longer match our use case. Maybe instead copy the original icon to our project?... TBD how that works with the IntelliJ's Apache license.

https://github.com/VirtusLab/git-machete-intellij-plugin/pull/319#discussion_r435226926

Haha I don't think kidnap can be used in the figurative sense as easily as hijack can TBH ;D

authors: PawelLipski mkondratek

repo: VirtusLab/git-machete-intellij-plugin


text:
where to find the results and to visualize them

Thanks for your work!
I have run the code successfully I think ,
`Forwarding video...
0018
Loading forwarded detections from file...
Done.
Loading images for visualization...
Done.
Time for tracking (s): 6.499499977508094e-05 FPS for tracking including forwarding: 0.0
Exporting tracking results
Visualizing tracks
Time for forwarding (s): 0.0002299799998581875 FPS for forwarding (wo. tracking): 0.0
Process finished with exit code 0`
BUT where to find the results? And how can I visulize the results, I dont know ,it will help me a lot if you can tell me,thanks!

the should be a folder TrackR-CNN/forwarded/... in which you can find the results.
For visualization, use the mots tools https://github.com/VisualComputingInstitute/mots_tools

Thanks！I have found the results,detections and tracking_data.
Then I want to visualize the results,following the readme , run the commands

python mots_eval/visualize_mots.py tracking_results img_folder output_folder seqmap

The tracking_results == /TrackR-CNN/forwarded/conv3d_sep2/tracking_data
But get error:

AssertionError: Can't find data in directory /TrackR-CNN/forwarded/conv3d_sep2/tracking_data

Do you know where the problem is?

sorry, I have found the problem is  detections and tracking_data are o bytes.

I have read the answers you gave to others,and changed the path the right way, I don't know how can fix the problem.when I run the Trackrcnn it didn't get errors, but the results are 0 bytes. Can you help me with this ? Thanks a lot!

@pvoigtlaender

It seems that the network hasn't read the input images. When I testing Kitti dataset, image path is /media/ubuntu/SSD/TrackR-CNN/data/kitti_mots/train/images/0000,and the path in conv3d_sep2 is "KITTI_segtrack_data_dir": "/media/ubuntu/SSD/TrackR-CNN/data/kitti_mots/train" . It works well.

@LiXm1002  sorry,but what is the 0000 refering to  in image path ? uh ,I only change the path in conv3d_sep2.py, it's "KITTI_segtrack_data_dir": "/home/echo/a_project/TrackR-CNN/kitti_mots/kitti/images/data_tracking_image_2/training"

Mine is like this.

That make no sense, I have tried many times ,but the results are 0 bytes,so confused/(ㄒoㄒ)/~~

Maybe you can try to print path of the images or some parameter information when testing.

OK，thanks very much! I am tring

I know the problem now...the folder must be named /images and /instances, when I downloaded them ,the name is  /image_02  , so I ignored this !so silly error!!!

Glad to hear you found the problem. Thanks also to @LiXm1002 ! Closing this for now, please reopen if needed

authors: EchoAmor LiXm1002 ahnonay pvoigtlaender

repo: VisualComputingInstitute/TrackR-CNN


text:
[Feature Request] New Menu/Replace the Invite Friends with lobby code

maybe make it show to code somewhere in the steam menu or something or open another lil menu/popup that lets you select which one you want
reasoning is this damn overlapping:

So ima just take that as a no

I'll get into this eventually

Should be fixed in the 2.0.1 release

authors: CatsArmy VisualError

repo: VisualError/Better-Lobbies


text:
Dengeki Bunko: Fighting Climax [PCSB00763]

App summary

App name: Dengeki Bunko: Fighting Climax
App serial: PCSB00763
App version: 1.00

Vita3K summary

Version: v0.1.6
Build number: 3002
Commit hash: https://github.com/vita3k/vita3k/commit/4dfc391

Test environment summary

Tested by: Zangetsu38
OS: Windows 10
CPU: AMD Ryzen 9 3900X
GPU: NVIDIA RTX 2070 Super
RAM: 16 GB

Screenshots:

Log

Vita3K summary

Version: v0.2.0
Build number: 3691
Commit hash: https://github.com/vita3k/vita3k/commit/31826697
CPU backend: Dynarmic
GPU backend: Vulkan

Test environment summary

Tested by: Slade
OS: Microsoft Windows 10 Professional (build 19045)
CPU: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz
GPU: NVIDIA GeForce GTX 1060 6GB
RAM: 16 GB

Issues

The game is still playable with no apparent issues.
Just adding screen shots and log for completeness.

Screenshots

Log
vita3k.log
Recommended labels

Playable


text:
Feature/ind land cover

Overview
Adds a new Indonesian Land Cover Layer to the GFW map 🌍

Still awaiting final approval - check the BC thread for status updates.

repo: Vizzuality/gfw


text:
feat(Project Tags): New GET endpoint to retrieve a Project's Tags

Substitute this line for a meaningful title for your changes
Overview
Please write a description. If the PR is hard to understand, provide a quick explanation of the code.
Designs
Link to the related design prototypes (if applicable)
Testing instructions
Please explain how to test the PR: ID of a dataset, steps to reach the feature, etc.
Feature relevant tickets
Link to the related task manager tickets

Checklist before submitting

[ ] Meaningful commits and code rebased on develop.
[ ] If this PR adds feature that should be tested for regressions when
deploying to staging/production, please add brief testing instructions
to the deploy checklist (docs/deployment-checklist.md)
[ ] Update CHANGELOG file

I've reworked the GET endpoint to better conform to JSON API standards, reusing the FetchSpecification construct, although it's handled more manually because of the highly narrow use case

repo: Vizzuality/marxan-cloud


text:
Doesn't collect AJAX Dependencies

I notice some differences between using AppInsights via the MS provided snippet vs using angular-applicationinsights.  Not collected page load stats is already known and captured in another issue, but I also get AJAX Dependency Info if I use the MS snippet which I don't with angular-applicationinsights.
The below screenshot is what I get automatically from just including the MS provided JS snippet inside my index.html.  With angular-applicationinsights all I get is the Page View.

I've tried combining using both angular-appinsights and the MS snippet, but then the information gets split between 2 different sessions.  If there was a way to make them both use the same session ID when reporting that might be the easiest fix.  Both for dependency data and page load stats.

Hey @dylan-smith ,
I faced the same problem and after looking at the code, I found out that "trackDependency" method wasn't implemented.  I suppose that I shouldn't be hard to do.
cc @VladimirRybalko

Hello @n0is
This issue has label "up for grabs". So feel free to do it. It will be really cool, if you add a PR. I appreciate any helps from community.
Thanks in advance.

authors: VladimirRybalko dylan-smith n0is


text:
Feature request: FPU

CPU core should be improved, but should be compatible with old one.
What new core should be able:

FPU unit (single precision)
Improved barrel shifter
Improved comparator
Faster execution generally

Pull request is opened so I'm closing this issue.


text:
Custom Redirects

Manage custom 301 and 302 redirects to map old URLs to new locations when your content structure has changed.

Hi @ChiquitaV2 let me know if you are still working on this item. Thanks a lot.

repo: Vontigo/Vontigo


text:
Fix drop order of JoinedCell fields

Closes #20

Let me know if you agree with https://github.com/Voultapher/self_cell/pull/21/commits/2ca0660884e55886505633e33f37ea5280f1d8ec

Also do you think switching to ManuallyDrop would be worth it? We have pointers anyway, so the use seems limited to me. And I suspect this simple pointer based code is quite fast to compile.

2ca0660 Seems like a valid approach as well.
I’m not sure if it’d be superflous, but I’d feel even better if the code used addr_of_mut!((*ptr).field) instead of the &mut (*ptr).field. I’m just being paranoid that &mut (*ptr).field might require that the whole *ptr is supposed to be valid, even though a different field is already dropped. (Probably not, but I’m not sure and the change wouldn’t hurt anyway I guess?)

Note that even without 2ca0660, drop order of fields is clearly specified.
But with the addr_of_mut, I like it even better than the previous drop_in_place(joined_ptr.as_ptr());, because in my mind that one could also try to get mutable access to the whole *joined_ptr.as_ptr() first, which would invalidate the shared reference to owner that dependent might contain.
In other words: I’m not quite sure if it makes a difference but if any version is sound then the current one with drop_in_place(addr_of_mut!((*joined_ptr.as_ptr()).dependent)); drop_in_place(addr_of_mut!((*joined_ptr.as_ptr()).owner)); should be sound, too.

I, too, don’t really think using ManuallyDrop adds anything useful.

Squashed the commits a bit.

Added another commit with more changes. I’m more confident that these operations are sound with addr_of_mut. In particular, the UnsafeSelfCell::borrow_mut seemed problematic because it returned a mutable reference to the whole JoinedCell even though owner must not be borrowed mutably while dependent can hold a reference to it.

Another usage of addr_of_mut added. I’m not sure if &mut (*self.joined_ptr.as_ptr()).owner is allowed when the dependent field contains uninitialized data. Better safe than sorry.

Did some more reading, turns out the addr_of[_mut] usage is unnecessary in most cases, but 2 things were legitimate AFAICT:

the UnsafeSelfCell::borrow_mut was problematic, creating an intermediate mutable reference to the whole JoinedCell
thelet owner_ptr: *mut $Owner = core::ptr::addr_of_mut!((*joined_ptr.as_ptr()).owner);
let dependent_ptr: *mut $Dependent = core::ptr::addr_of_mut!((*joined_ptr.as_ptr()).dependent);

are important, because previously they would create intermediate references to uninitialized memory.

Reduced usage of addr_of[_mut] to those cases now :-), squashed again

authors: Voultapher steffahn


text:
Offline report: RF feature importance figures

This adds figures for the random forest's feature importances to the offline report, if applicable.
Significant internal changes:

Made fv3fit._shared.packer.count_features_2d public

[x] Tests added

Example: https://storage.googleapis.com/vcm-ml-public/annak/2021-05-24-rf-feature-importance/model_sensitivity.html

Thanks Andre, the plotting code is much tidier now with the suggestions implemented! This is ready for re-review.


text:
feature/update react-helmet

The NFL has released version 6.0.0 of react-helmet. It has one breaking change re named import/export: https://github.com/nfl/react-helmet/wiki/Upgrade-from-5.x.x----6.x.x-beta

Thanks! Could you please also check for the Starter for the same update?

On it.

cf https://github.com/VulcanJS/Vulcan-Starter/pull/168

Awesome thank you

authors: eric-burel kevinashworth

repo: VulcanJS/Vulcan


text:
Transpose Does Not Work on Infinite Lists

while True:
        if any(has_ind(row, r) for row in matrix):
            this_row = gen_row(r)
            if all(type(x) is str for x in this_row):
                yield "".join(this_row)
            else:
                yield this_row

        else:
            break
        r += 1

That any is going to never finish on an infinite matrix if there's no such row

Hey, @Lyxal, that's a nice issue you've got there! It'd sure be a shame if somebody were to assign you to it!

L + ratio + don't care

Expected behaviour

repo: Vyxal/Vyxal


text:
Image Batch not working

The Image Batch node fails to run, and throws an error about missing required inputs. Adding in an empty required section has fixed it for me:
class WAS_Image_Batch:
    def __init__(self):
        pass

    @classmethod
    def INPUT_TYPES(cls):
        return {
            "required": {
            },
            "optional": {
                "images_a": ("IMAGE",),
                "images_b": ("IMAGE",),
                "images_c": ("IMAGE",),
                "images_d": ("IMAGE",),
                # "images_e": ("IMAGE",),
                # "images_f": ("IMAGE",),
                # Theoretically, an infinite number of image input parameters can be added.
            },
        }

If you want you can PR the patch, otherwise I'll get to it when I get a chance. I think that was a PR cause I don't remember adding it.

Just made a PR, should be good to go.

authors: HermitCrabe WASasquatch

repo: WASasquatch/was-node-suite-comfyui


text:
Added support for unique admin layer boundary

Added support for specifying a unique boundary for an admin-level-data layer by just providing boundary as a valid boundary layer.

Changed how we define boundaries by adding display boolean property. With the display property we load only boundaries which have true as display value

Test country: Myanmar all boundaries are now set with display: true

Test admin-level-data layer: Vulnerability Index with boundary: inform

A few comments:

Don't make the display attribute required. It should default to false
I added another layer to test which uses admin 1 boundaries but it gives errors when it loads. Please try with the new layer I added.
The scenario we should be thinking about has a new layer loaded which references a different set of admin boundaries and codes

@erwagasore - i'm not still seeing admin1 level data projected onto the map layer as expected when i test the 'test_admin1_data' layer in the myanmar config

PR pointing to a wrong branch. Re-creating a new PR and omitting this one

👉🏾  https://github.com/WFP-VAM/prism-frontend/pull/338

authors: erwagasore wadhwamatic

repo: WFP-VAM/prism-frontend


text:
Set Thumbnail Display Size: Special Collections Asset Results

Like the Stock Sales website, the already created asset thumbnails are of various sizes so they need to be cropped as they are displayed on the Special Collections asset results pages to 362 x 228px.

Special collections thumbnails are showing consistently, though the ratio might be tweaked, pending feedback. closing.

authors: Muraszko mccalluc


text:
harmonisation with the doc

I'm not sure of the change, but in the current state the doc confuses both my interns and me.

It appears the function signature no longer needs to be changed as it was refactored to use an ibc parameter at some point after this PR.


text:
Wrong Definition of control gains in calcAero function of Rotor.py

I've been looking into the code of the aerodynamics calculations of raft because I am trying to understand if some results on the OC4 platform I am getting are reasonable, and I believe I've stumbled on a small error in the calcAero function of the rotor.py file. In line 872, where the torque control gains are defined, in both the integral and proportional gains, the kp_tau value is used, when it should be ki_tau for the integral term and kp_tau for the proportional term. The results I am getting after correcting this are very different from the original code (for cases where wind speed is below the rated speed).

Thank you! This seems like quite the important correction! @lucas-carmo, could you look into this?
Matt

Thank you for finding this bug, @giannikosk! Do you want to open a pull request with your fix (which would formally record your contribution here on GitHub) or do you prefer that I push your fix (mentioning you) to the repo?
Lucas

@lucas-carmo thank you I would rather you push a fixed version, I am not very familiar with git.
Giannikos

Ok, thanks @giannikosk! This bug is fixed in commit

authors: giannikosk lucas-carmo mattEhall

repo: WISDEM/RAFT


text:
Remove usb0 references

Remove references to usb0 in switcher scripts & files as no longer required

I believe @wifinigel has already done this?

Yes, completed.

authors: jiribrejcha wifinigel

repo: WLAN-Pi/wlanpi-hotspot


text:
cannot POST /wp/v2/posts (404)

I can't create a post, I got error of cannot POST /wp/v2/posts (404)
My code is from the doc
var wp = new WPAPI({
    endpoint: 'https://example.com',
    username: 'ss',
    password: 'ssss'
  })

  wp
    .posts()
    .create({
      title: 'Your Post Title',
      content,
      status: 'publish'
    })
    .then(function(response) {
      // "response" will hold all properties of your newly-created post,
      // including the unique `id` the post was assigned on creation
      console.log('response id', response.id)
    })
    .catch(response => {
      console.log(response)
    })

I googled and most of the people recommendation were to turn off permalink, I did, but no effect. I have mod_rewrite by default is enabled.

Do you have /wp-json at the end of your endpoint url?

Yeah
On Wed, Nov 21, 2018, 7:41 AM brionace <notifications@github.com wrote:

Do you have /wp-json at the end of your endpoint url?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/WP-API/node-wpapi/issues/395#issuecomment-440468724,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACqqnQBIFoTbRQ2-ommtAWBcAyZu86itks5uxJMUgaJpZM4YCI8B
.

@eldyvoon Based on your confirmation about the endpoint URL above, if your example reads
var wp = new WPAPI( {
  endpoint: 'https://example.com/wp-json', // Note the "wp-json"
  username: 'ss',
  password: 'sss',
} );

and you still have this issue, then I'm not sure what the issue would be. I would expect an auth issue in that case. However, I do want to reconfirm that the above is true, because while you responded to the prior question by confirming that you had the wp-json string at the end of your endpoint URL, it did not appear in your original post.
Permalinks must be enabled for this to work, unlike what you described; I'm not sure what your search was, but for the /wp-json endpoint to be accessible, some permalink scheme is required.

authors: brionace eldyvoon kadamwhite

repo: WP-API/node-wpapi


text:
Issue# 118 - Sort Config.json

This PR is in reference to #118
the changes have been tested and verified.
I also changed 3 aliases so they no longer use aliases (where, select, sort)
<don't hate me for that>

Ahh i think it has a merge conflict. It must be because i didn't notice i had those two test tacked onto it  : [
It is possible to remove those two test files? or would it need to be a new PR.

Sure, you can delete the files from the branch and make another commit.

Awesome. That is good to know.

:shipit:

authors: Midacts brianbunke

repo: WahlNetwork/Vester


text:
Storybook >Component > Billing Address >Default > After submitting field is not clear.

Describe the bug
After submitting field is not clear.
Steps to reproduce bug

Go to 'https://stage-react.raaghu.ai/'
Navigate to 'Storybook >Component > Billing Address >Default'
Fill the data and click on save.

Actual result-
After submitting field is not clear.
Screenshots

Expected result-
After submitting all field should be clear.
Desktop (please complete the following information):
-OS: [Windows 10 Enterprise]
-Browser [ edge]
-Version [ 125.0.2535.92]

Completed -

Describe the bug
Placeholder issue.
Steps to reproduce bug

Go to 'https://stage-react.raaghu.ai/'
Navigate to 'Storybook >Component > Billing Address >Default'
3.Placeholder issue.

Actual result-
Placeholder is not correct.
Screenshots

Expected result-
Enter Address
Desktop (please complete the following information):
-OS: [Windows 10 Enterprise]
-Browser [ edge]
-Version [ 125.0.2535.92]

Fixed on staging

repo: Wai-Technologies/raaghu-react


text:
[bug] Next.js webpack errors because of missing documentation

Link to minimal reproducible example
https://web3modal.justfixit.dev/
Summary
Web3Modal uses 3 libraries that cause repeated and annoying webpack errors in Next.js. This is resolvable by adding this snippet of code to the documentation for Next.js users:
// Path: next.config.js
const nextConfig = {
  webpack: (config) => {
    config.externals.push(
      "pino-pretty",
      "lokijs",
      "encoding"
    );
  return config;
}

List of related npm package versions
https://github.com/dirtycajunrice/web3modal-bug-examples-2023-10-21/blob/9269c51dfe95d7ec2a5e0efebd3fb3923c9b79f1/package.json#L11-L19
  "dependencies": {
    "@web3modal/wagmi": "^3.1.0",
    "next": "13.5.6",
    "react": "^18",
    "react-code-blocks": "^0.1.4",
    "react-dom": "^18",
    "viem": "^1.16.6",
    "wagmi": "^1.4.5"
  },

Thanks for documenting this -- Saved me a lot of frustration.

authors: dirtycajunrice nftchance


text:
last is technically unsound?

last takes a self argument, but returns a lend from self... after dropping self... so a dangling pointer is possible... and somehow still passes MIRI tests? I can't tell if MIRI test is simply failing to catch this or I'm being dumb?
The fix is easy, use &mut self instead of self:
fn last(&mut self) -> ...

I am just opening this issue to make sure I'm not just being delusional at 2:30AM ...

I tried this:
struct TestLast {
    vec: Vec<u32>,
    i: usize,
}

impl<'lend> Lending<'lend> for TestLast {
    type Lend = &'lend mut u32;
}

impl Lender for TestLast {
    fn next(&mut self) -> Option<Lend<'_, Self>> {
        let i = self.i;
        self.i += 1;
        self.vec.get_mut(i)
    }
}

#[test]
fn test_last() {
    let test = TestLast { vec: vec![1u32, 2, 3, 4, 5], i: 0 }.into_lender();
    dbg!(test.last().unwrap());
}

and it prints 0, which I think is really wrong.

I can confirm—AddressSanitizer is very angry about this:
[lender/src/bin/test.rs:22:5] test.last().unwrap() = =================================================================
==877186==ERROR: AddressSanitizer: heap-use-after-free on address 0x5030000000e0 at pc 0x5651981c3409 bp 0x7ffc78d1bf90 sp 0x7ffc78d1bf88
READ of size 4 at 0x5030000000e0 thread T0
    #0 0x5651981c3408 in core::fmt::num::imp::_$LT$impl$u20$core..fmt..Display$u20$for$u20$u32$GT$::fmt::h69a163923fb7eb1c /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/num.rs:284:38
    #1 0x565197c5b447 in core::fmt::num::_$LT$impl$u20$core..fmt..Debug$u20$for$u20$u32$GT$::fmt::h62e29134da02bb5e /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/num.rs:195:21
    #2 0x565197c5db92 in _$LT$$RF$mut$u20$T$u20$as$u20$core..fmt..Debug$GT$::fmt::h69ea2d1d8eb47a69 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:2298:62
    #3 0x565197c5db42 in _$LT$$RF$T$u20$as$u20$core..fmt..Debug$GT$::fmt::h6c7b76c986e1530a /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:2294:62
    #4 0x5651981c7f48 in core::fmt::rt::Argument::fmt::hac285b9a25d237fd /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/rt.rs:142:9
    #5 0x5651981c7f48 in core::fmt::run::h9231b999e207daf9 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:1168:5
    #6 0x5651981c791a in core::fmt::write::h93e53792323789a1 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/mod.rs:1136:26
    #7 0x565197dbe67d in std::io::Write::write_fmt::h5b0da961950a1ea8 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/io/mod.rs:1810:15
    #8 0x565197dbc1c2 in _$LT$$RF$std..io..stdio..Stderr$u20$as$u20$std..io..Write$GT$::write_fmt::h415615a1a53a10be /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/io/stdio.rs:947:9
    #9 0x565197dbbf5f in _$LT$std..io..stdio..Stderr$u20$as$u20$std..io..Write$GT$::write_fmt::h83f30b8efcdbd5a7 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/io/stdio.rs:921:9
    #10 0x565197dbcfbd in std::io::stdio::print_to::h8747fc5bf3cae778 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/io/stdio.rs:1020:21
    #11 0x565197dbe41f in std::io::stdio::_eprint::hfec64e2278d5d726 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/io/stdio.rs:1108:5
    #12 0x565197c5d2d0 in test::main::ha897e0faa57670ca /home/vigna/git/Lender/lender/src/bin/test.rs:22:5
    #13 0x565197c5f58a in core::ops::function::FnOnce::call_once::h15cc4cb4329d8185 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5
    #14 0x565197c5dc67 in std::sys_common::backtrace::__rust_begin_short_backtrace::h06a17f6f342bae33 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:155:18
    #15 0x565197c5eb03 in std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h12ad8905f6938aaa /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:166:18
    #16 0x565197ff48bd in core::ops::function::impls::_$LT$impl$u20$core..ops..function..FnOnce$LT$A$GT$$u20$for$u20$$RF$F$GT$::call_once::h01b250a103b67c28 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:284:13
    #17 0x565197f83b9e in std::panicking::try::do_call::h310ad436d5f24204 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:552:40
    #18 0x565197f8a31a in __rust_try std.f61ab866ecd17e83-cgu.12
    #19 0x565197f823f5 in std::panicking::try::h80f365cc2924b493 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:516:19
    #20 0x565197e47d19 in std::panic::catch_unwind::h0e5ad325990ff66f /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:142:14
    #21 0x5651980203b0 in std::rt::lang_start_internal::_$u7b$$u7b$closure$u7d$$u7d$::hf3d106d027d059a6 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:148:48
    #22 0x565197f839e6 in std::panicking::try::do_call::h285724d113369ab6 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:552:40
    #23 0x565197f8a31a in __rust_try std.f61ab866ecd17e83-cgu.12
    #24 0x565197f82d15 in std::panicking::try::hb390df9406819d6a /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:516:19
    #25 0x565197e47ea9 in std::panic::catch_unwind::h6ec74337f6895c3b /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:142:14
    #26 0x56519801fecf in std::rt::lang_start_internal::hf098f510e9aa04a4 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:148:20
    #27 0x565197c5ea5f in std::rt::lang_start::h62fb2d0cf3e8186f /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:165:17
    #28 0x565197c5d3cd in main (/home/vigna/git/Lender/target/x86_64-unknown-linux-gnu/debug/test+0x18e3cd) (BuildId: dfcf64882b151fc6fae663c82db25ae798078bbc)
    #29 0x7f86343a0b89 in __libc_start_call_main (/lib64/libc.so.6+0x27b89) (BuildId: 7026fe8c129a523e07856d7c96306663ceab6e24)
    #30 0x7f86343a0c4a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x27c4a) (BuildId: 7026fe8c129a523e07856d7c96306663ceab6e24)
    #31 0x565197ba9d64 in _start (/home/vigna/git/Lender/target/x86_64-unknown-linux-gnu/debug/test+0xdad64) (BuildId: dfcf64882b151fc6fae663c82db25ae798078bbc)

0x5030000000e0 is located 16 bytes inside of 20-byte region [0x5030000000d0,0x5030000000e4)
freed by thread T0 here:
    #0 0x565197c31c96 in free /rustc/llvm/src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:52:3
    #1 0x565197f89a2c in std::sys::unix::alloc::_$LT$impl$u20$core..alloc..global..GlobalAlloc$u20$for$u20$std..alloc..System$GT$::dealloc::hb07d0d70afe288a3 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/unix/alloc.rs:42:9
    #2 0x565197c9047b in __rdl_dealloc /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/alloc.rs:402:18
    #3 0x565197db31cb in _$LT$alloc..alloc..Global$u20$as$u20$core..alloc..Allocator$GT$::deallocate::hc4cb26e24767fe88 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:254:22
    #4 0x565197e9387d in _$LT$alloc..raw_vec..RawVec$LT$T$C$A$GT$$u20$as$u20$core..ops..drop..Drop$GT$::drop::ha5b2cb6ab6f27958 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/raw_vec.rs:531:22
    #5 0x565197d1f51a in core::ptr::drop_in_place$LT$alloc..raw_vec..RawVec$LT$u32$GT$$GT$::h840944dc91834e93 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:507:1
    #6 0x565197c5f849 in core::ptr::drop_in_place$LT$test..TestLast$GT$::hc8ba43cddf7663f5 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:507:1
    #7 0x565197c5cc41 in test::main::ha897e0faa57670ca /home/vigna/git/Lender/lender/src/bin/test.rs:22:10
    #8 0x565197c5f58a in core::ops::function::FnOnce::call_once::h15cc4cb4329d8185 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5
    #9 0x565197c5eb03 in std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h12ad8905f6938aaa /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:166:18
    #10 0x565197f83b9e in std::panicking::try::do_call::h310ad436d5f24204 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:552:40
    #11 0x565197f8a31a in __rust_try std.f61ab866ecd17e83-cgu.12
    #12 0x565197e47d19 in std::panic::catch_unwind::h0e5ad325990ff66f /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:142:14
    #13 0x5651980203b0 in std::rt::lang_start_internal::_$u7b$$u7b$closure$u7d$$u7d$::hf3d106d027d059a6 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:148:48
    #14 0x565197f839e6 in std::panicking::try::do_call::h285724d113369ab6 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:552:40
    #15 0x565197f8a31a in __rust_try std.f61ab866ecd17e83-cgu.12
    #16 0x565197e47ea9 in std::panic::catch_unwind::h6ec74337f6895c3b /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:142:14
    #17 0x56519801fecf in std::rt::lang_start_internal::hf098f510e9aa04a4 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:148:20
    #18 0x565197c5ea5f in std::rt::lang_start::h62fb2d0cf3e8186f /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:165:17
    #19 0x565197c5d3cd in main (/home/vigna/git/Lender/target/x86_64-unknown-linux-gnu/debug/test+0x18e3cd) (BuildId: dfcf64882b151fc6fae663c82db25ae798078bbc)
    #20 0x7f86343a0c4a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x27c4a) (BuildId: 7026fe8c129a523e07856d7c96306663ceab6e24)
    #21 0x565197ba9d64 in _start (/home/vigna/git/Lender/target/x86_64-unknown-linux-gnu/debug/test+0xdad64) (BuildId: dfcf64882b151fc6fae663c82db25ae798078bbc)

previously allocated by thread T0 here:
    #0 0x565197c31f3e in malloc /rustc/llvm/src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:69:3
    #1 0x565197f895fa in std::sys::unix::alloc::_$LT$impl$u20$core..alloc..global..GlobalAlloc$u20$for$u20$std..alloc..System$GT$::alloc::h8a9e9d9619827005 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/unix/alloc.rs:14:13
    #2 0x565197c903ba in __rdl_alloc /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/alloc.rs:394:13
    #3 0x565197c5ba53 in alloc::alloc::alloc::h35666faf49109c3f /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:98:9
    #4 0x565197c5be31 in alloc::alloc::Global::alloc_impl::hfdd202d40065b7d2 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:181:73
    #5 0x565197c5c0f0 in _$LT$alloc..alloc..Global$u20$as$u20$core..alloc..Allocator$GT$::allocate::hf2f2c2e96c040ffc /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:241:9
    #6 0x565197c5b791 in alloc::alloc::exchange_malloc::h973a377ee269724c /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:330:11
    #7 0x565197c5c9cd in test::main::ha897e0faa57670ca /home/vigna/git/Lender/lender/src/bin/test.rs:21:32
    #8 0x565197c5f58a in core::ops::function::FnOnce::call_once::h15cc4cb4329d8185 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5
    #9 0x565197c5eb03 in std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h12ad8905f6938aaa /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:166:18
    #10 0x565197f83b9e in std::panicking::try::do_call::h310ad436d5f24204 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:552:40
    #11 0x565197f8a31a in __rust_try std.f61ab866ecd17e83-cgu.12
    #12 0x565197e47d19 in std::panic::catch_unwind::h0e5ad325990ff66f /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:142:14
    #13 0x5651980203b0 in std::rt::lang_start_internal::_$u7b$$u7b$closure$u7d$$u7d$::hf3d106d027d059a6 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:148:48
    #14 0x565197f839e6 in std::panicking::try::do_call::h285724d113369ab6 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:552:40
    #15 0x565197f8a31a in __rust_try std.f61ab866ecd17e83-cgu.12
    #16 0x565197e47ea9 in std::panic::catch_unwind::h6ec74337f6895c3b /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:142:14
    #17 0x56519801fecf in std::rt::lang_start_internal::hf098f510e9aa04a4 /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:148:20
    #18 0x565197c5ea5f in std::rt::lang_start::h62fb2d0cf3e8186f /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:165:17
    #19 0x565197c5d3cd in main (/home/vigna/git/Lender/target/x86_64-unknown-linux-gnu/debug/test+0x18e3cd) (BuildId: dfcf64882b151fc6fae663c82db25ae798078bbc)
    #20 0x7f86343a0c4a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x27c4a) (BuildId: 7026fe8c129a523e07856d7c96306663ceab6e24)
    #21 0x565197ba9d64 in _start (/home/vigna/git/Lender/target/x86_64-unknown-linux-gnu/debug/test+0xdad64) (BuildId: dfcf64882b151fc6fae663c82db25ae798078bbc)

SUMMARY: AddressSanitizer: heap-use-after-free /home/vigna/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/num.rs:284:38 in core::fmt::num::imp::_$LT$impl$u20$core..fmt..Display$u20$for$u20$u32$GT$::fmt::h69a163923fb7eb1c
Shadow bytes around the buggy address:
  0x502ffffffe00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x502ffffffe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x502fffffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x502fffffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x503000000000: fa fa 00 00 00 fa fa fa fd fd fd fd fa fa fd fd
=>0x503000000080: fd fd fa fa 00 00 00 00 fa fa fd fd[fd]fa fa fa
  0x503000000100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x503000000180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x503000000200: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x503000000280: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x503000000300: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==877186==ABORTING

I'd say MIRI is failing to catch this. Maybe we could report it, it's very easily replicable on nightly with
export RUSTFLAGS=-Zsanitizer=address RUSTDOCFLAGS=-Zsanitizer=address
cargo run -Zbuild-std --bin test  --target x86_64-unknown-linux-gnu

Note that on x86_64 it prints 5. It prints 0 on ARM.

Actually, not—from the README: "In particular, Miri does not check that references point to valid data.".

I feel like I had MIRI catch a dangling pointer before, but I guess nothing beats actual review.
I'm fairly certain that this wouldn't be a breaking change so I'm going to go ahead.

Well, everything is marked EXPERIMENTAL in capital letters everywhere anyway. 🤷🏻♂

For good reason too 😂, it's easy to forget how much of a foot-gun transmute is.
just FYI: With the new Rust release, I'm going to do some poking around with gat-lending-iterator to see if I can't get some more feature-parity.

Go on, but the problem with GAT-based lending iterators is not implementing the utility methods—the problem come up when you try to use them. Apart from quite trivial cases, they never work.

Unfortunately true, but with the new release, the Rust team mentioned starting work on fixing some of the bugs we rely on here. Probably not anytime in the future, but it couldn't hurt to try and develop the GAT-based implementation a little more.

BTW, why not joining https://crates.io/crates/gat-lending-iterator ?

gat-lending-iterator is eventually what I want to be the main lending-iterator crate because it'd have the most support from the Rust team. If we can eventually get it to have as much feature-parity and usability, then I'm definitely not averse to letting it take over this crate's name or anything.
I've also realized that there may be some more unforeseen UB in last if the Lender invalidates any previous lends on even a None, because the Lender is using &mut self and we cannot guarantee the Lender implements perfect short-circuiting.
For example,
fn next(&mut self) ... {
  // invalidate previous lend to buffer
  self.buffer.clear()
  // before short-circuiting
  if self.done {
    return None;
  }
  ...
}

I can't tell what's the best course of action here. What do you think about having an unsafe extension trait for methods which use transmute in a non-verifiable way like last?
unsafe pub trait ShortCircuiting {
  fn last ...
  ...
}

Mmmhhh... removing/deprecating last? I don't even think there's one in Iterator.
It's possible that the GAT version might get more support, but there's no syntax proposal in sight for making them usable. Maybe they'll find another way.
In any case porting code between the two versions is usually trivial.

authors: WanderLanz vigna

repo: WanderLanz/Lender


text:
Doors and Levers

Implement a door and lever functionality that can be interacted with player collision and tongue, I.E player toucher lever to open doors or tongue the lever to open the door. For simplicity, the door must be opened with a lever

Close via #53

authors: Lmh-java TMZero-c


text:
Update to the latest wasi-libc.

This contains two significant changes:

Implement a stub pthreads library for THREAD_MODEL=single (#518)
Initial FTS support (#522)

@kateinoigakukun @sbc100 The build here is failing being unable to find "config.h" when build fts.c. Would you mind taking a look?

@sunfishcode Oops, sorry. I opened a fix for the build breakage: https://github.com/WebAssembly/wasi-libc/pull/544

Subsumed by https://github.com/WebAssembly/wasi-sdk/pull/496 now

repo: WebAssembly/wasi-sdk


text:
Add some wasi-threads tests

(venv) spacetanuki% TOYWASM=~/git/toywasm/b/toywasm python3 test-runner/wasi_test_runner.py -t tests/wat/testsuite -r ~/git/toywasm/test/wasi-testsuite-adapter.py
Test wasi_threads_exit_main_busy passed
Test wasi_threads_exit_nonmain_busy passed
Test wasi_threads_spawn passed
Test wasi_threads_exit_main_block passed
Test wasi_threads_exit_nonmain_block passed

===== Test results =====
Runtime: toywasm v0.0
Suite: WASI wat tests
  Total: 5
  Passed:  5
  Failed:  0

Test suites: 1 passed, 0 total
Tests:       5 passed, 0 total
(venv) spacetanuki%

i've written these while implementing wasi-threads in toywasm.
but nothing in these tests is toywasm-specific as far as i know.

I'll review the tests in details after end of year holidays, but my initial thought was that this should for now live in https://github.com/WebAssembly/wasi-threads? In fact there's one basic test added there already: https://github.com/WebAssembly/wasi-threads/pull/11

I'll review the tests in details after end of year holidays, but my initial thought was that this should for now live in https://github.com/WebAssembly/wasi-threads? In fact there's one basic test added there already: WebAssembly/wasi-threads#11

i haven't noticed that the "basic test" there was for the same test runner.
maybe i will move there.

moved to https://github.com/WebAssembly/wasi-threads/pull/19

authors: loganek yamt

repo: WebAssembly/wasi-testsuite


text:
Clarification regarding multisig OOBI

There has been some discussion on github and discord regarding how multisig OOBI urls work. This issue on signify-ts contains some further references: https://github.com/WebOfTrust/signify-ts/issues/193
Consider a group AID multisig with participants member1 and member2 and their keria agents agent1 and agent2. Currently, when calling GET /oobis/multisig to generate an OOBI url for the group, you have to specify the role as either agent, witness or controller.
So, for example, if member1 would call this endpoint to generate an OOBI url for the group they would specify the role parameter agent and and get a result:
https://keria-url/oobi/<multisig aid>/agent/<agent1 aid>

If another AID, for example a credential issuer resolves this OOBI url and then grants a credential to that AID, only member1 would receive this message.
The current workaround is to construct an URL on the client side by stripping the /agent/<agent1 aid> part of the URL. So you would get:
https://keria-url/oobi/<multisig aid>

See the example scripts in signifypy and signify-ts:

https://github.com/WebOfTrust/signifypy/blob/e15129147c40faf587485e7cd46f8f179672d22b/scripts/multisig-holder.py#L113
https://github.com/WebOfTrust/signify-ts/blob/5be18192520f63eba83011379049f42e83b02ee0/examples/integration-scripts/multisig-holder.test.ts#L396

From our dev meeting:
Only one oobi is being chosen in the signify-ts example. There are a number of options:

Clients can review the agent OOBIs and return the non-role OOBI (like seen in the tests). Does this belong in the logic or API? If this is handled at the API level it would help the user to receive the generic OOBI. @Arsh-Sandhu will send his fix.
Generate an OOBI url with just a role in it
Consumer can resolve all oobis

Here is a reference to a discussion in discord regarding this: https://discord.com/channels/1148629222647148624/1148734044545228831/1194270946215854182

See https://github.com/WebOfTrust/keria/issues/305 and once this is resolved this process will be documented/clear.

repo: WebOfTrust/keria


text:
[Landing]: Update website design #184

Related Issue
The organization rebranded their identity, so the website need to follow it. See discussion #184.
Closes: #164 #148 #125
Describe the changes you've made
Removed completly the old homepage, and freestyling the new one. I used Tailwind/Next.js.
New components:

DiscordButton
ContributeButton
CallToActionButton
Hero

@shuklaritvik06 I added the CallToActionButton component but i think it's too heavy here :

Let's see how we can improve it later!
Type of change
What sort of change have you made:

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Code style update (formatting, local variables)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] Documentation update.
[x] This change requires a documentation update

How Has This Been Tested?

Checklist

[x] My code follows the guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented on my code, particularly wherever it was hard to understand.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[ ] I have added tests that prove my fix is effective or that my feature works.
[ ] Any dependent changes have been merged and published in downstream modules.

Screenshots (if applicable)

Original
Updated

Code of Conduct

[x] I agree to follow this project's Code of Conduct

Awesome! Thank you so much. 🚀 We just need to update various pages and add a few links. 😄
__        Summary: 🏆 This code is awesome  |  Tags: Maintainable

💪! Yup, many little things to fix!


text:
Adds bash example

fixes #33

Thanks for your contribution!

Note that /bin/sh is not always bash.
On MacOS it is typically bash, but on Linux distros (like Ubuntu) it is often dash.
Echo is part of the Posix spec though, so this script should work on all Posix compliant (and even pretty much all non-compliant) shells like bash, dask, zsh, fish, ... However, even though it is typically built into the shell for performance reasons, this is not necessarily the case. Very old shells use an external echo commend.
Just wanted to leave this here for future reference / trivia.

authors: Webd01 gillesdemey seppestas


text:
Not expected result of WhereQuery::whereInReplyTo method

Describe the bug
I try to find inbox emails which are replies on my sent emails. So I sent email

and receive a reply on it.

In the replied email I have header attribute in_reply_to which shows me id of sent email. It equals the id of my sent email.

But if I try to get messages with help of whereInReplyTo method - I'll have empty collection.

Am I do something wrong?
Used config
I've used a default account with my login data.
IMAP_HOST=imap.ukr.net
IMAP_PORT=993
IMAP_ENCRYPTION=ssl
IMAP_VALIDATE_CERT=true
IMAP_USERNAME={my_username}
IMAP_PASSWORD={my_password}
IMAP_DEFAULT_ACCOUNT=default
IMAP_PROTOCOL=imap

Expected behavior
I want to have ability to find replied emails to my messages.
Desktop / Server (please complete the following information):

OS: Ubuntu 18.04 LTS
PHP: 7.2.24
Version: 2.4.0

Hi @alexelev ,
many thanks for the detailed report.
The method WhereQuery::whereInReplyTo() depends on your email server. It can happend that the server doesn't support certain search criteria - but I've never heard of missing In-Reply-To support... You could try to enable the debug option $client->getConnection()->enableDebug() and see if you get any additional clues.
However maybe Message::thread() contains the message you are looking for :)
Best regards,

Thanks for your answer

but I've never heard of missing In-Reply-To support...

Yep, now you can say that you've read about that, because this is true and confirmed by the technical support staff of mail service which was used. In such situation, respectively, Message::thread() also doesn't work :)
When i contacted them they advised me making request for all mails's headers, parse them on my side to find nessesary for me mails and then making request to get data only for this mails, by, for example, Message-Id header. So can I fetch custom set of headers - I think Message-Id and In-Reply-To would be enough for start - with this library help?

Hi @alexelev ,
sorry for the late response. Yes you'll find all these values within the header of a message :)
I'm closing this issue, as this isn't library issue. If I'm wrong or you have any additional comments feel free to comment below or to create a new issue.
Best regards,

authors: Webklex alexelev

repo: Webklex/php-imap


text:
lf0 question about convert phase

Hi,
I wonder why you normalize f0 series before feeding to the f0encoder in convert.py.
However, this kind of normalization for f0 isn't used in preprocessing phase.

Hi, normalizing f0 aims to remove the speaker characteristics. During preprocessing phase, f0 is not normalized, but during training and inference, f0 is normalized as shown below:
https://github.com/Wendison/VQMIVC/blob/851b4f5ca5bb60c11fea6a618affeb4979b17cf3/dataset.py#L45
https://github.com/Wendison/VQMIVC/blob/851b4f5ca5bb60c11fea6a618affeb4979b17cf3/convert_example.py#L53

Hi,
thank you for your explanation!!!
I have another question about perplexity when training the model with another dataset.
I found that the perplexity didn't keep increasing (have run around 360 epochs in the figure), was it reasonable?
And do you have any suggestions to verify this issue?

authors: Wendison powei-C

repo: Wendison/VQMIVC


text:
🛑 Haze is down

In 9bdcddd, Haze (https://hazeband.co.uk) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Haze is back up in 15a233a after 8 days, 19 hours, 17 minutes.

repo: West-Midlands-Media-Group/upptime


text:
Where will I get the pretrained code for moganet?

Checklist

I have searched related issues but cannot get the expected help.
I have read related documents and don't know what to do.

Describe the question you meet
[here]
Post related information

The output of pip list | grep "mmcv\|mmcls\|^torch"
[here]
Your config file if you modified it or created a new one.

[here]

Your train log file if you meet the problem during training.
[here]
Other code you modified in the mmcls folder.
[here]

Hi, @M-SunRise. Thanks for your attention to our MogaNet. Could you please describe your question in detail? We have provided configs and the source code moganet.py, which can be used to reproduce results of MogaNet. As for checkpoints and logs of pre-trained models of MogaNet, we plan to release them a few months later. Please free to ask me if you have further questions.

Hello @M-SunRise, thanks for your attention and patience. We have uploaded the release of weights and logs of MogaNet in moganet-in1k-weights. We hope you will find it useful. I will close this issue in two days if there are no more questions. Please feel free to contact me for discussion.

I closed this issue if there is no more question. You can reopen it or start a new issue if you have more questions. Thanks again for your attention.

repo: Westlake-AI/openmixup


text:
Remove META-INF folder

META-INF is added by Gradle.

Oh ya tru, lemme push my stuff then merge.

You're lucky there even is gradle(That was all me)

authors: Techno-coder WheezyGold7931 okx-code


text:
Header Check sometimes causes PHP notice.

PHP Notice: Undefined offset: 3 in /var/www/lib/WhichBrowser/src/Analyser/Header/Wap.php on line 38

Fixed, will be included in the next update!

authors: NielsLeenheer vityank

repo: WhichBrowser/Parser


text:
older versions of sqlite

Following the guide I can use a customized version of SQLite3 with better-sqlite3, but only for recent versions. Older versions like 3.16.2 fall over with errors like this:
npm ERR! ./src/objects/database.lzz: In static member function 'static void Database::JS_new(const v8::FunctionCallbackInfo<v8::Value>&)':
npm ERR! ./src/objects/database.lzz:182:55: error: 'SQLITE_DBCONFIG_DEFENSIVE' was not declared in this scope; did you mean 'SQLITE_DBCONFIG_LOOKASIDE'?
npm ERR! ./src/objects/database.lzz: In static member function 'static void Database::JS_serialize(const v8::FunctionCallbackInfo<v8::Value>&)':
npm ERR! ./src/objects/database.lzz:285:39: error: 'sqlite3_serialize' was not declared in this scope; did you mean 'sqlite3_strlike'?
npm ERR! ./src/objects/database.lzz: In static member function 'static void Database::JS_function(const v8::FunctionCallbackInfo<v8::Value>&)':
npm ERR! ./src/objects/database.lzz:313:42: error: 'SQLITE_DIRECTONLY' was not declared in this scope; did you mean 'SQLITE_READONLY'?
npm ERR! ./src/objects/database.lzz: In static member function 'static void Database::JS_aggregate(const v8::FunctionCallbackInfo<v8::Value>&)':
npm ERR! ./src/objects/database.lzz:342:42: error: 'SQLITE_DIRECTONLY' was not declared in this scope; did you mean 'SQLITE_READONLY'?
npm ERR! ./src/objects/database.lzz:345:21: error: 'sqlite3_create_window_function' was not declared in this scope; did you mean 'sqlite3_create_function'?
npm ERR! ./src/objects/database.lzz: In static member function 'static void Database::JS_unsafeMode(const v8::FunctionCallbackInfo<v8::Value>&)':
npm ERR! ./src/objects/database.lzz:412:50: error: 'SQLITE_DBCONFIG_DEFENSIVE' was not declared in this scope; did you mean 'SQLITE_DBCONFIG_LOOKASIDE'?
npm ERR! ./src/objects/database.lzz: In static member function 'static bool Database::Deserialize(v8::Local<v8::Object>, Addon*, sqlite3*, bool)':
npm ERR! ./src/objects/database.lzz:427:38: error: 'SQLITE_DESERIALIZE_FREEONCLOSE' was not declared in this scope
npm ERR! ./src/objects/database.lzz:427:71: error: 'SQLITE_DESERIALIZE_RESIZEABLE' was not declared in this scope
npm ERR! ./src/objects/database.lzz:430:34: error: 'SQLITE_DESERIALIZE_READONLY' was not declared in this scope
npm ERR! ./src/objects/database.lzz:440:30: error: 'sqlite3_deserialize' was not declared in this scope; did you mean 'sqlite3_initialize'?
npm ERR! ./src/objects/statement.lzz: In static member function 'static void Statement::JS_new(const v8::FunctionCallbackInfo<v8::Value>&)':
npm ERR! ./src/objects/statement.lzz:98:29: error: 'SQLITE_PREPARE_PERSISTENT' was not declared in this scope
npm ERR! ./src/objects/statement.lzz:110:21: error: 'sqlite3_prepare_v3' was not declared in this scope; did you mean 'sqlite3_prepare_v2'?
npm ERR! ./src/util/custom-table.lzz: At global scope:
npm ERR! ./src/util/custom-table.lzz:45:9: error: too many initializers for 'sqlite3_module'
npm ERR! ./src/util/custom-table.lzz:72:9: error: too many initializers for 'sqlite3_module'
npm ERR! ./src/util/custom-table.lzz: In static member function 'static int CustomTable::xConnect(sqlite3*, void*, int, const char* const*, sqlite3_vtab**, char**)':
npm ERR! ./src/util/custom-table.lzz:200:67: error: 'SQLITE_VTAB_DIRECTONLY' was not declared in this scope; did you mean 'SQLITE_OPEN_READONLY'?

my dockerfile for the above is:
FROM alpine:3.16
RUN apk add --no-cache openrc util-linux haveged nodejs
RUN apk add --no-cache --virtual .build-deps unzip python3 make g++ npm \
  && wget https://www.sqlite.org/2017/sqlite-amalgamation-3160200.zip -O sqlite.zip \
  && unzip -j sqlite.zip \
  && rm sqlite.zip \
  && sed -i '1i#define SQLITE_DQS 0' sqlite3.c \
  && sed -i '1i#define SQLITE_THREADSAFE 0' sqlite3.c \
  && sed -i '1i#define SQLITE_DEFAULT_MEMSTATUS 0' sqlite3.c \
  && sed -i '1i#define SQLITE_DEFAULT_SYNCHRONOUS 0' sqlite3.c \
  && sed -i '1i#define SQLITE_LIKE_DOESNT_MATCH_BLOBS 1' sqlite3.c \
  && sed -i '1i#define SQLITE_OMIT_DEPRECATED 1' sqlite3.c \
  && sed -i '1i#define SQLITE_OMIT_SHARED_CACHE 1' sqlite3.c \
  && sed -i '1i#define SQLITE_USE_ALLOCA 1' sqlite3.c \
  && npm install -g better-sqlite3 --build-from-source --sqlite3=/ \
	&& apk del --no-network .build-deps
ENTRYPOINT ["sh"]

I've been able to compile SQLite 3.16.2 on the same alpine version:
FROM alpine:3.16
RUN apk add --no-cache openrc util-linux haveged sqlite-dev nodejs
RUN apk add --no-cache --virtual .build-deps alpine-sdk python3 npm
RUN wget http://www.sqlite.org/2017/sqlite-autoconf-3160200.tar.gz -O sqlite.tar.gz \
  && mkdir /sqlite \
  && tar -zxvf sqlite.tar.gz -C /sqlite --strip-components=1 \
  && rm sqlite.tar.gz
RUN sed -i '1i#define SQLITE_DQS 0' /sqlite/sqlite3.c \
  && sed -i '1i#define SQLITE_THREADSAFE 0' /sqlite/sqlite3.c \
  && sed -i '1i#define SQLITE_DEFAULT_MEMSTATUS 0' /sqlite/sqlite3.c \
  && sed -i '1i#define SQLITE_DEFAULT_SYNCHRONOUS 0' /sqlite/sqlite3.c \
  && sed -i '1i#define SQLITE_LIKE_DOESNT_MATCH_BLOBS 1' /sqlite/sqlite3.c \
  && sed -i '1i#define SQLITE_OMIT_DEPRECATED 1' /sqlite/sqlite3.c \
  && sed -i '1i#define SQLITE_OMIT_SHARED_CACHE 1' /sqlite/sqlite3.c \
  && sed -i '1i#define SQLITE_USE_ALLOCA 1' /sqlite/sqlite3.c
RUN /sqlite/configure --prefix=/usr --disable-static --enable-fts5 --enable-json1 \
    CFLAGS="-g -O2 -DSQLITE_ENABLE_FTS3=1 -DSQLITE_ENABLE_FTS4=1 -DSQLITE_ENABLE_RTREE=1 -DSQLITE_ENABLE_JSON1" \
  && make \
  && make install
ENTRYPOINT ["sh"]

Is there anything I can do to get old versions compiling with better-sqlite3, or is there a way of linking to the version I'm able to compile independently?

I've got 3.27 working :
  && sed -i '1i#define SQLITE_DIRECTONLY 0' sqlite3.h \
  && sed -i '1i#define SQLITE_VTAB_DIRECTONLY 1' sqlite3.h \
  && sed -i '1i#define SQLITE_ENABLE_DESERIALIZE 1' sqlite3.c \

SQLITE_ENABLE_DESERIALIZE is needed because of a change in defaults:

This option was formerly used to enable the sqlite3_serialize() and sqlite3_deserialize() interfaces. However, as of SQLite 3.36.0 (2021-06-18) those interfaces are enabled by default and a new compile-time option SQLITE_OMIT_DESERIALIZE is added to omit them.

The other two I assume are just new options.

I don't think this approach is going to work for 3.16 as sqlite3_serialize() doesn't exist that far back. I can get 3.15 with v1.3.9 and 3.18 with v2.2.0 but am I correct that the option to compile from source didn't exist until recently so I won't be able to use either of those versions as a base for getting 3.16 working?

Since better-sqlite3 exposes features that only exist in modern versions of SQLite, such as db.serialize, older versions won't work. You would need to fork better-sqlite3 and remove all features that don't exist in the version of SQLite you're using.

Possibly related to https://github.com/WiseLibs/better-sqlite3/issues/855

Thanks @JoshuaWise that makes sense :)

authors: JoshuaWise jackdouglas


text:
parameters destructuring is failing

module.exports = function Handler(productsRepo) {
  this.handle = async function({ message } = ctx) {
    ctx.success()   // <-- Fails here
  }
}

Error:
 ReferenceError: ctx is not defined
     ReferenceError: ctx is not defined
     at Handler.handle

@igorshapiro This is expected behavior
The function definition above destructures ctx into a message variable instead of assigning ctx itself. The = ctx part is just a default parameter assignment but ctx itself is still not defined anywhere.
I think what you are attempting to accomplish here can somewhat be achieved using:
this.handle = async function({ message, ...ctx }) {

This will destructure message and put the rest of the fields into a ctx variable (the ctx variable will not contain message though)

Thanks @tomeresk . Closing this

authors: igorshapiro tomeresk

repo: WisePricer/quadro


text:
configuable drops?

Despite the loot modifier saying 23, they sometimes drop over a stack of emeralds. How would I go about fixing this? Perhaps the amount can be configurable?
I also feel like that have too much health. Can that also be configurable?

Apologies for the wait, this has been a bug on my side.
Health has been configurable for a while using the config.
As for the emerald amount, the Trader was also dropping the cost of the emeralds in the inputs of the trades. This has been corrected, they will only drop the output of the trades, as long as you haven't bought all of the stock of that trade.


text:
fix: Fix support for apispec>=1.0.0b5

Pin to apispec^1.0.0b5
Add pyyaml as a dep, since it is no longer included
with apispec
Update documentation

close #1

Codecov Report

:exclamation: No coverage uploaded for pull request base (dev@0e043a9). Click here to learn what that means.
The diff coverage is n/a.

@@         Coverage Diff          @@
##             dev     #4   +/-   ##
====================================
  Coverage       ?   100%
====================================
  Files          ?      2
  Lines          ?     20
  Branches       ?      0
====================================
  Hits           ?     20
  Misses         ?      0
  Partials       ?      0

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 0e043a9...917d8aa. Read the comment docs.

Just a heads up: you might be able to get rid of the make_plain_datastructure after 1.0.0 final is released because https://github.com/marshmallow-code/apispec/pull/333 removes LazyDict.
It won't hurt anything to keep that function for now, thuogh.

Thanks! I'll check it once 1.0.0 is out!

Prerelease is publish: https://pypi.org/project/starlette-apispec/#history

authors: Woile codecov-io sloria

repo: Woile/starlette-apispec


text:
Inline WL code input boxes

This is really cool! Nice feature. How do you type the inline code?

authors: ConnorGray rhennigan

repo: WolframResearch/Chatbook


text:
Replaced tslint with eslint.

The used eslint config is the same as in the AN custom channel project.

The readme has been updated.

repo: WoodWing/csde-components-validator


text:
Bug - 0.8.5 doesn't show up in OpenUPM

As per Favo Yang

The problem is that the Git tag is mismatched with package.json version.
Tag 0.8.5, package.json 0.8.4 WooshiiDev/HierarchyDecorator@f10ba25/package.json
Tag 0.8.4, package.json 0.8.3 WooshiiDev/HierarchyDecorator@57c0d1b/package.json
Perhaps your CI could bump package.json version first, then create the Git tag?
You can align your Git tag and package.json version with 0.8.6 to fix the issue.
OpenUPM build pipeline section didn't show the actual published version, it just shows the version parsed from the Git tag. Something to improve for us.

https://github.com/openupm/openupm/issues/2927#issuecomment-1104986685

Hi Razen,
I've just released v0.8.6 that has a small bug fix for 2021.2+ and have made sure BEFORE making the package the tag is correct.
I see the build pipelines and versions both showing 0.8.6 correctly.
Could you confirm that it's working correctly for yourself? I'm sorry that I have not been releasing properly so far and making sure versions have been updated.

Works like a charm now, thank you!

authors: Razenpok WooshiiDev

repo: WooshiiDev/HierarchyDecorator