while publishing in cloudflare got this error!!

2023-01-22T11:48:06.414738Z	Cloning repository...
2023-01-22T11:48:07.288817Z	From https://github.com/thamizhnation/astro-notion-blog-1
2023-01-22T11:48:07.289392Z	 * branch            7e74e1e2b4fc151789fa3ea0c533dcedddf84aa5 -> FETCH_HEAD
2023-01-22T11:48:07.289561Z
2023-01-22T11:48:07.345173Z	HEAD is now at 7e74e1e Merge pull request #5 from otoyo/fix-blob-fetch
2023-01-22T11:48:07.345825Z
2023-01-22T11:48:07.496961Z
2023-01-22T11:48:07.524854Z	Success: Finished cloning repository files
2023-01-22T11:48:08.243905Z	Installing dependencies
2023-01-22T11:48:08.255931Z	Python version set to 2.7
2023-01-22T11:48:11.695543Z	Downloading and installing node v16.13.0...
2023-01-22T11:48:12.122746Z	Downloading https://nodejs.org/dist/v16.13.0/node-v16.13.0-linux-x64.tar.xz...
2023-01-22T11:48:12.583402Z	Computing checksum with sha256sum
2023-01-22T11:48:12.711172Z	Checksums matched!
2023-01-22T11:48:16.990151Z	Now using node v16.13.0 (npm v8.1.0)
2023-01-22T11:48:17.390694Z	Started restoring cached build plugins
2023-01-22T11:48:17.404719Z	Finished restoring cached build plugins
2023-01-22T11:48:17.933204Z	Attempting ruby version 2.7.1, read from environment
2023-01-22T11:48:21.58594Z	Using ruby version 2.7.1
2023-01-22T11:48:21.951242Z	Using PHP version 5.6
2023-01-22T11:48:22.116433Z	5.2 is already installed.
2023-01-22T11:48:22.143775Z	Using Swift version 5.2
2023-01-22T11:48:22.144349Z	Started restoring cached node modules
2023-01-22T11:48:22.161875Z	Finished restoring cached node modules
2023-01-22T11:48:22.170448Z	Started restoring cached yarn cache
2023-01-22T11:48:22.186159Z	Finished restoring cached yarn cache
2023-01-22T11:48:22.206789Z	Installing yarn at version 1.22.4
2023-01-22T11:48:22.224739Z	Installing Yarn!
2023-01-22T11:48:22.225087Z	> Downloading tarball...
2023-01-22T11:48:22.269373Z
2023-01-22T11:48:22.269775Z	[1/2]: https://yarnpkg.com/downloads/1.22.4/yarn-v1.22.4.tar.gz --> /tmp/yarn.tar.gz.RT7VRwPBzN
2023-01-22T11:48:22.270433Z	  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
2023-01-22T11:48:22.270991Z	                                 Dload  Upload   Total   Spent    Left  Speed
2023-01-22T11:48:22.558466Z
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100    79  100    79    0     0    274      0 --:--:-- --:--:-- --:--:--   274
2023-01-22T11:48:22.689883Z
100    93  100    93    0     0    221      0 --:--:-- --:--:-- --:--:--   221
2023-01-22T11:48:22.852751Z
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
2023-01-22T11:48:23.197497Z
100 1215k  100 1215k    0     0  1310k      0 --:--:-- --:--:-- --:--:-- 1310k
2023-01-22T11:48:23.197848Z
2023-01-22T11:48:23.198075Z	[2/2]: https://yarnpkg.com/downloads/1.22.4/yarn-v1.22.4.tar.gz.asc --> /tmp/yarn.tar.gz.RT7VRwPBzN.asc
2023-01-22T11:48:23.254162Z
100    83  100    83    0     0   1490      0 --:--:-- --:--:-- --:--:--  1490
2023-01-22T11:48:23.256163Z
100    97  100    97    0     0   1680      0 --:--:-- --:--:-- --:--:--  1680
2023-01-22T11:48:23.386885Z
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
2023-01-22T11:48:23.464943Z
100  1028  100  1028    0     0   3858      0 --:--:-- --:--:-- --:--:--  3858
2023-01-22T11:48:23.51301Z	> Verifying integrity...
2023-01-22T11:48:23.557165Z	gpg: Signature made Mon 09 Mar 2020 03:52:13 PM UTC using RSA key ID 69475BAA
2023-01-22T11:48:23.563289Z	gpg: Good signature from "Yarn Packaging<EMAIL_ADDRESS>2023-01-22T11:48:23.565776Z	gpg: Note: This key has expired!
2023-01-22T11:48:23.566076Z	Primary key fingerprint: 72EC F46A 56B4 AD39 C907  BBB7 1646 B01B 86E5 0310
2023-01-22T11:48:23.566229Z	     Subkey fingerprint: 6D98 490C 6F1A CDDD 448E  4595 4F77 6793 6947 5BAA
2023-01-22T11:48:23.567388Z	> GPG signature looks good
2023-01-22T11:48:23.568739Z	> Extracting to ~/.yarn...
2023-01-22T11:48:23.664855Z	> Adding to $PATH...
2023-01-22T11:48:23.692769Z	> We've added the following to your /opt/buildhome/.bashrc
2023-01-22T11:48:23.693249Z	> If this isn't the profile of your current shell then please add the following to your correct profile:
2023-01-22T11:48:23.69439Z
2023-01-22T11:48:23.694706Z	export PATH="$HOME/.yarn/bin:$HOME/.config/yarn/global/node_modules/.bin:$PATH"
2023-01-22T11:48:23.69486Z
2023-01-22T11:48:24.084685Z	> Successfully installed Yarn 1.22.4! Please open another terminal where the yarn command will now be available.
2023-01-22T11:48:24.489Z	Installing NPM modules using Yarn version 1.22.4
2023-01-22T11:48:25.208127Z	yarn install v1.22.4
2023-01-22T11:48:25.296148Z	[1/4] Resolving packages...
2023-01-22T11:48:25.553835Z	[2/4] Fetching packages...
2023-01-22T11:48:41.255319Z	warning<EMAIL_ADDRESS>The engine "pnpm" appears to be invalid.
2023-01-22T11:48:41.257377Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T11:48:41.257637Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T11:48:41.258626Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T11:48:41.258833Z	info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T11:48:41.258967Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T11:48:41.259084Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T11:48:41.259202Z	info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T11:48:41.259311Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T11:48:41.25942Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T11:48:41.259529Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T11:48:41.259669Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T11:48:41.259783Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T11:48:41.259902Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T11:48:41.260012Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T11:48:41.260119Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T11:48:41.260226Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T11:48:41.260333Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T11:48:41.260442Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T11:48:41.260548Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T11:48:41.260678Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T11:48:41.260789Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T11:48:41.260906Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T11:48:41.261013Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T11:48:41.26112Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T11:48:41.261226Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T11:48:41.261332Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T11:48:41.261438Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T11:48:41.261544Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T11:48:41.26168Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T11:48:41.261789Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T11:48:41.261896Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T11:48:41.262003Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T11:48:41.262108Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T11:48:41.262217Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T11:48:41.262324Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T11:48:41.262432Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T11:48:41.262537Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T11:48:41.262674Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T11:48:41.262793Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T11:48:41.262904Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T11:48:41.26302Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T11:48:41.26322Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T11:48:41.26342Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T11:48:41.263661Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T11:48:41.263859Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T11:48:41.264605Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T11:48:41.264795Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T11:48:41.264991Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T11:48:41.265142Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T11:48:41.265329Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T11:48:41.269201Z	[3/4] Linking dependencies...
2023-01-22T11:48:41.27109Z	warning " ><EMAIL_ADDRESS>has unmet peer dependency "<EMAIL_ADDRESS>|| ^18.0.21".
2023-01-22T11:48:41.271328Z	warning " ><EMAIL_ADDRESS>has unmet peer dependency "<EMAIL_ADDRESS>|| ^18.0.6".
2023-01-22T11:48:41.274328Z	warning "@typescript-eslint/eslint-plugin ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| >= 3.2.0-dev || >= 3.3.0-dev || >= 3.4.0-dev || >= 3.5.0-dev || >= 3.6.0-dev || >= 3.6.0-beta || >= 3.7.0-dev || >= 3.7.0-beta".
2023-01-22T11:48:52.073417Z	[4/4] Building fresh packages...
2023-01-22T11:48:53.493752Z	Done in 28.29s.
2023-01-22T11:48:53.525932Z	NPM modules installed using Yarn
2023-01-22T11:48:53.829871Z	Installing Hugo 0.54.0
2023-01-22T11:48:54.53755Z	Hugo Static Site Generator v0.54.0-B1A82C61A/extended linux/amd64 BuildDate: 2019-02-01T10:04:38Z
2023-01-22T11:48:54.54163Z	Started restoring cached go cache
2023-01-22T11:48:54.562086Z	Finished restoring cached go cache
2023-01-22T11:48:54.721485Z	go version go1.14.4 linux/amd64
2023-01-22T11:48:54.737803Z	go version go1.14.4 linux/amd64
2023-01-22T11:48:54.740843Z	Installing missing commands
2023-01-22T11:48:54.741156Z	Verify run directory
2023-01-22T11:48:54.74139Z	Executing user command: npm run build
2023-01-22T11:48:55.207853Z
2023-01-22T11:48:55.208167Z	><EMAIL_ADDRESS>build
2023-01-22T11:48:55.208314Z	> astro build
2023-01-22T11:48:55.208431Z
2023-01-22T11:48:57.263649Z	11:48:57 AM [build] output target: static
2023-01-22T11:48:57.264058Z	11:48:57 AM [build] Collecting build info...
2023-01-22T11:48:57.265338Z	11:48:57 AM [build] Completed in 35ms.
2023-01-22T11:48:57.266497Z	11:48:57 AM [build] Building static entrypoints...
2023-01-22T11:48:59.676768Z	11:48:59 AM [build] Completed in 2.41s.
2023-01-22T11:48:59.677146Z
2023-01-22T11:48:59.677301Z	 building client
2023-01-22T11:49:05.880946Z
2023-01-22T11:49:05.881295Z	(!) Some chunks are larger than 500 KiB after minification. Consider:
2023-01-22T11:49:05.881462Z	- Using dynamic import() to code-split the application
2023-01-22T11:49:05.881619Z	- Use build.rollupOptions.output.manualChunks to improve chunking: https://rollupjs.org/guide/en/#outputmanualchunks
2023-01-22T11:49:05.881757Z	- Adjust chunk size limit for this warning via build.chunkSizeWarningLimit.
2023-01-22T11:49:05.881879Z	Completed in 6.20s.
2023-01-22T11:49:05.881988Z
2023-01-22T11:49:05.882095Z
2023-01-22T11:49:05.882205Z	 generating static routes
2023-01-22T11:49:06.771913Z	▶ src/pages/index.astro
2023-01-22T11:49:06.78602Z	  └─ /index.html (+14ms)
2023-01-22T11:49:06.78633Z	▶ src/pages/blog/index.astro
2023-01-22T11:49:06.872802Z	@notionhq/client warn: request fail {
2023-01-22T11:49:06.873183Z	  code: 'object_not_found',
2023-01-22T11:49:06.873355Z	  message: 'Could not find database with ID: 63156ec7-4870-4bf9-b55e-33eeaaac0c5e. Make sure the relevant pages and databases are shared with your integration.'
2023-01-22T11:49:06.873487Z	}
2023-01-22T11:49:06.88237Z	@notionhq/client warn: request fail {
2023-01-22T11:49:06.88265Z	  code: 'object_not_found',
2023-01-22T11:49:06.882798Z	  message: 'Could not find database with ID: 63156ec7-4870-4bf9-b55e-33eeaaac0c5e. Make sure the relevant pages and databases are shared with your integration.'
2023-01-22T11:49:06.88293Z	}
2023-01-22T11:49:06.88423Z	@notionhq/client warn: request fail {
2023-01-22T11:49:06.88443Z	  code: 'object_not_found',
2023-01-22T11:49:06.884567Z	  message: 'Could not find database with ID: 63156ec7-4870-4bf9-b55e-33eeaaac0c5e. Make sure the relevant pages and databases are shared with your integration.'
2023-01-22T11:49:06.884712Z	}
2023-01-22T11:49:06.887358Z	@notionhq/client warn: request fail {
2023-01-22T11:49:06.887543Z	  code: 'object_not_found',
2023-01-22T11:49:06.887688Z	  message: 'Could not find database with ID: 63156ec7-4870-4bf9-b55e-33eeaaac0c5e. Make sure the relevant pages and databases are shared with your integration.'
2023-01-22T11:49:06.887809Z	}
2023-01-22T11:49:07.153966Z	 error   Could not find database with ID: 63156ec7-4870-4bf9-b55e-33eeaaac0c5e. Make sure the relevant pages and databases are shared with your integration.
2023-01-22T11:49:07.154564Z	  File:
2023-01-22T11:49:07.154808Z	    /opt/buildhome/repo/node_modules/@notionhq/client/build/src/errors.js:162:16
2023-01-22T11:49:07.154944Z	  Code:
2023-01-22T11:49:07.155098Z	    161 |     if (apiErrorResponseBody !== undefined) {
2023-01-22T11:49:07.155223Z	    > 162 |         return new APIResponseError({
2023-01-22T11:49:07.155353Z	          |                ^
2023-01-22T11:49:07.155474Z	      163 |             code: apiErrorResponseBody.code,
2023-01-22T11:49:07.155602Z	      164 |             message: apiErrorResponseBody.message,
2023-01-22T11:49:07.155739Z	      165 |             headers: response.headers,
2023-01-22T11:49:07.155866Z	  Stacktrace:
2023-01-22T11:49:07.156024Z	APIResponseError: Could not find database with ID: 63156ec7-4870-4bf9-b55e-33eeaaac0c5e. Make sure the relevant pages and databases are shared with your integration.
2023-01-22T11:49:07.156303Z	    at buildRequestError (/opt/buildhome/repo/node_modules/@notionhq/client/build/src/errors.js:162:16)
2023-01-22T11:49:07.156501Z	    at Client.request (/opt/buildhome/repo/node_modules/@notionhq/client/build/src/Client.js:347:54)
2023-01-22T11:49:07.156708Z	    at processTicksAndRejections (node:internal/process/task_queues:96:5)
2023-01-22T11:49:07.156866Z	    at async getAllPosts (file:///opt/buildhome/repo/dist/entry.mjs?time=1674388145881:1946:17)
2023-01-22T11:49:07.157014Z	    at async getPosts (file:///opt/buildhome/repo/dist/entry.mjs?time=1674388145881:1957:20)
2023-01-22T11:49:07.157164Z	    at async Promise.all (index 0)
2023-01-22T11:49:07.157304Z	    at async file:///opt/buildhome/repo/dist/entry.mjs?time=1674388145881:2615:53
2023-01-22T11:49:07.157443Z	    at async renderPage (file:///opt/buildhome/repo/node_modules/astro/dist/runtime/server/render/page.js:89:30)
2023-01-22T11:49:07.157625Z	    at async renderPage (file:///opt/buildhome/repo/node_modules/astro/dist/core/render/core.js:86:20)
2023-01-22T11:49:07.157803Z	    at async generatePath (file:///opt/buildhome/repo/node_modules/astro/dist/core/build/generate.js:285:22)
2023-01-22T11:49:07.157921Z
2023-01-22T11:49:07.201414Z	Failed: build command exited with code: 1
2023-01-22T11:49:08.323966Z	Failed: an internal error occurred

Notionデータベースが見つからないというエラーが出ているようです。
クイックスタート のステップ3, 5, 9の手順を再度確認いただけますでしょうか？
もしわからないところがあればスクショを撮ってコメントいただければと思います。

Yes. 3,5,9 steps are followed
2023-01-22T13:44:57.627053Z	Cloning repository...
2023-01-22T13:44:58.455331Z	From https://github.com/thamizhnation/astro-notion-blog-1
2023-01-22T13:44:58.455987Z	 * branch            7e74e1e2b4fc151789fa3ea0c533dcedddf84aa5 -> FETCH_HEAD
2023-01-22T13:44:58.456217Z
2023-01-22T13:44:58.510243Z	HEAD is now at 7e74e1e Merge pull request #5 from otoyo/fix-blob-fetch
2023-01-22T13:44:58.510799Z
2023-01-22T13:44:58.651128Z
2023-01-22T13:44:58.677055Z	Success: Finished cloning repository files
2023-01-22T13:44:59.344664Z	Installing dependencies
2023-01-22T13:44:59.357709Z	Python version set to 2.7
2023-01-22T13:45:02.838688Z	Downloading and installing node v16.13.0...
2023-01-22T13:45:03.287743Z	Downloading https://nodejs.org/dist/v16.13.0/node-v16.13.0-linux-x64.tar.xz...
2023-01-22T13:45:03.704212Z	Computing checksum with sha256sum
2023-01-22T13:45:03.832071Z	Checksums matched!
2023-01-22T13:45:08.043901Z	Now using node v16.13.0 (npm v8.1.0)
2023-01-22T13:45:08.462408Z	Started restoring cached build plugins
2023-01-22T13:45:08.475543Z	Finished restoring cached build plugins
2023-01-22T13:45:09.006998Z	Attempting ruby version 2.7.1, read from environment
2023-01-22T13:45:12.594478Z	Using ruby version 2.7.1
2023-01-22T13:45:12.9476Z	Using PHP version 5.6
2023-01-22T13:45:13.111821Z	5.2 is already installed.
2023-01-22T13:45:13.139326Z	Using Swift version 5.2
2023-01-22T13:45:13.139807Z	Started restoring cached node modules
2023-01-22T13:45:13.155767Z	Finished restoring cached node modules
2023-01-22T13:45:13.164228Z	Started restoring cached yarn cache
2023-01-22T13:45:13.178619Z	Finished restoring cached yarn cache
2023-01-22T13:45:13.200654Z	Installing yarn at version 1.22.4
2023-01-22T13:45:13.218677Z	Installing Yarn!
2023-01-22T13:45:13.218964Z	> Downloading tarball...
2023-01-22T13:45:13.259721Z
2023-01-22T13:45:13.260017Z	[1/2]: https://yarnpkg.com/downloads/1.22.4/yarn-v1.22.4.tar.gz --> /tmp/yarn.tar.gz.Kbp85dZEkQ
2023-01-22T13:45:13.260741Z	  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
2023-01-22T13:45:13.261089Z	                                 Dload  Upload   Total   Spent    Left  Speed
2023-01-22T13:45:13.503098Z
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100    79  100    79    0     0    325      0 --:--:-- --:--:-- --:--:--   326
2023-01-22T13:45:13.645634Z
100    92  100    92    0     0    238      0 --:--:-- --:--:-- --:--:--   238
2023-01-22T13:45:13.804833Z
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
2023-01-22T13:45:14.143684Z
100 1215k  100 1215k    0     0  1376k      0 --:--:-- --:--:-- --:--:-- 1376k
2023-01-22T13:45:14.144023Z
2023-01-22T13:45:14.144238Z	[2/2]: https://yarnpkg.com/downloads/1.22.4/yarn-v1.22.4.tar.gz.asc --> /tmp/yarn.tar.gz.Kbp85dZEkQ.asc
2023-01-22T13:45:14.17648Z
100    83  100    83    0     0   2605      0 --:--:-- --:--:-- --:--:--  2605
2023-01-22T13:45:14.178914Z
100    96  100    96    0     0   2798      0 --:--:-- --:--:-- --:--:--  2798
2023-01-22T13:45:14.187195Z
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
2023-01-22T13:45:14.268267Z
100  1028  100  1028    0     0   8314      0 --:--:-- --:--:-- --:--:--  8314
2023-01-22T13:45:14.315662Z	> Verifying integrity...
2023-01-22T13:45:14.356987Z	gpg: Signature made Mon 09 Mar 2020 03:52:13 PM UTC using RSA key ID 69475BAA
2023-01-22T13:45:14.36307Z	gpg: Good signature from "Yarn Packaging<EMAIL_ADDRESS>2023-01-22T13:45:14.365636Z	gpg: Note: This key has expired!
2023-01-22T13:45:14.365878Z	Primary key fingerprint: 72EC F46A 56B4 AD39 C907  BBB7 1646 B01B 86E5 0310
2023-01-22T13:45:14.366033Z	     Subkey fingerprint: 6D98 490C 6F1A CDDD 448E  4595 4F77 6793 6947 5BAA
2023-01-22T13:45:14.366798Z	> GPG signature looks good
2023-01-22T13:45:14.366989Z	> Extracting to ~/.yarn...
2023-01-22T13:45:14.457765Z	> Adding to $PATH...
2023-01-22T13:45:14.481687Z	> We've added the following to your /opt/buildhome/.bashrc
2023-01-22T13:45:14.481999Z	> If this isn't the profile of your current shell then please add the following to your correct profile:
2023-01-22T13:45:14.482148Z
2023-01-22T13:45:14.482268Z	export PATH="$HOME/.yarn/bin:$HOME/.config/yarn/global/node_modules/.bin:$PATH"
2023-01-22T13:45:14.482395Z
2023-01-22T13:45:14.863597Z	> Successfully installed Yarn 1.22.4! Please open another terminal where the yarn command will now be available.
2023-01-22T13:45:15.256602Z	Installing NPM modules using Yarn version 1.22.4
2023-01-22T13:45:15.961562Z	yarn install v1.22.4
2023-01-22T13:45:16.049785Z	[1/4] Resolving packages...
2023-01-22T13:45:16.298063Z	[2/4] Fetching packages...
2023-01-22T13:45:31.353753Z	warning<EMAIL_ADDRESS>The engine "pnpm" appears to be invalid.
2023-01-22T13:45:31.355728Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T13:45:31.355977Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T13:45:31.35689Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T13:45:31.357118Z	info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T13:45:31.357265Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T13:45:31.357402Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T13:45:31.357536Z	info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T13:45:31.357671Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T13:45:31.357787Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T13:45:31.357897Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T13:45:31.358017Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T13:45:31.358132Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T13:45:31.358249Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T13:45:31.358366Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T13:45:31.358492Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T13:45:31.358613Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T13:45:31.358763Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T13:45:31.358876Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T13:45:31.35899Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T13:45:31.359107Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T13:45:31.359223Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T13:45:31.359349Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T13:45:31.359874Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T13:45:31.36002Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T13:45:31.360134Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T13:45:31.360243Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T13:45:31.360358Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T13:45:31.360487Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T13:45:31.360608Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T13:45:31.360738Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T13:45:31.360852Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T13:45:31.361012Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T13:45:31.361329Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T13:45:31.361499Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T13:45:31.361654Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T13:45:31.361791Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T13:45:31.361949Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T13:45:31.362086Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T13:45:31.362232Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T13:45:31.362349Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T13:45:31.362476Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T13:45:31.362591Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T13:45:31.362717Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T13:45:31.362833Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T13:45:31.362943Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T13:45:31.363052Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T13:45:31.363174Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T13:45:31.363352Z	info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
2023-01-22T13:45:31.363497Z	info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
2023-01-22T13:45:31.36361Z	info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
2023-01-22T13:45:31.367349Z	[3/4] Linking dependencies...
2023-01-22T13:45:31.369066Z	warning " ><EMAIL_ADDRESS>has unmet peer dependency "<EMAIL_ADDRESS>|| ^18.0.21".
2023-01-22T13:45:31.36929Z	warning " ><EMAIL_ADDRESS>has unmet peer dependency "<EMAIL_ADDRESS>|| ^18.0.6".
2023-01-22T13:45:31.371464Z	warning "@typescript-eslint/eslint-plugin ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| >= 3.2.0-dev || >= 3.3.0-dev || >= 3.4.0-dev || >= 3.5.0-dev || >= 3.6.0-dev || >= 3.6.0-beta || >= 3.7.0-dev || >= 3.7.0-beta".
2023-01-22T13:45:41.512277Z	[4/4] Building fresh packages...
2023-01-22T13:45:42.962732Z	Done in 27.01s.
2023-01-22T13:45:42.99129Z	NPM modules installed using Yarn
2023-01-22T13:45:43.285783Z	Installing Hugo 0.54.0
2023-01-22T13:45:43.965469Z	Hugo Static Site Generator v0.54.0-B1A82C61A/extended linux/amd64 BuildDate: 2019-02-01T10:04:38Z
2023-01-22T13:45:43.969576Z	Started restoring cached go cache
2023-01-22T13:45:43.993403Z	Finished restoring cached go cache
2023-01-22T13:45:44.130327Z	go version go1.14.4 linux/amd64
2023-01-22T13:45:44.145178Z	go version go1.14.4 linux/amd64
2023-01-22T13:45:44.147879Z	Installing missing commands
2023-01-22T13:45:44.148152Z	Verify run directory
2023-01-22T13:45:44.148311Z	Executing user command: npm run build
2023-01-22T13:45:44.590919Z
2023-01-22T13:45:44.591258Z	><EMAIL_ADDRESS>build
2023-01-22T13:45:44.591416Z	> astro build
2023-01-22T13:45:44.591547Z
2023-01-22T13:45:46.607987Z	01:45:46 PM [build] output target: static
2023-01-22T13:45:46.608364Z	01:45:46 PM [build] Collecting build info...
2023-01-22T13:45:46.609655Z	01:45:46 PM [build] Completed in 22ms.
2023-01-22T13:45:46.610524Z	01:45:46 PM [build] Building static entrypoints...
2023-01-22T13:45:49.481595Z	01:45:49 PM [build] Completed in 2.87s.
2023-01-22T13:45:49.482082Z
2023-01-22T13:45:49.48253Z	 building client
2023-01-22T13:45:55.377645Z
2023-01-22T13:45:55.378011Z	(!) Some chunks are larger than 500 KiB after minification. Consider:
2023-01-22T13:45:55.378188Z	- Using dynamic import() to code-split the application
2023-01-22T13:45:55.37831Z	- Use build.rollupOptions.output.manualChunks to improve chunking: https://rollupjs.org/guide/en/#outputmanualchunks
2023-01-22T13:45:55.378443Z	- Adjust chunk size limit for this warning via build.chunkSizeWarningLimit.
2023-01-22T13:45:55.378592Z	Completed in 5.90s.
2023-01-22T13:45:55.378708Z
2023-01-22T13:45:55.378815Z
2023-01-22T13:45:55.378921Z	 generating static routes
2023-01-22T13:45:56.234871Z	▶ src/pages/index.astro
2023-01-22T13:45:56.252745Z	  └─ /index.html (+18ms)
2023-01-22T13:45:56.253068Z	▶ src/pages/blog/index.astro
2023-01-22T13:45:56.349349Z	@notionhq/client warn: request fail {
2023-01-22T13:45:56.349679Z	  code: 'object_not_found',
2023-01-22T13:45:56.349856Z	  message: 'Could not find database with ID: 63156ec7-4870-4bf9-b55e-33eeaaac0c5e. Make sure the relevant pages and databases are shared with your integration.'
2023-01-22T13:45:56.350004Z	}
2023-01-22T13:45:56.357792Z	@notionhq/client warn: request fail {
2023-01-22T13:45:56.358023Z	  code: 'object_not_found',
2023-01-22T13:45:56.358154Z	  message: 'Could not find database with ID: 63156ec7-4870-4bf9-b55e-33eeaaac0c5e. Make sure the relevant pages and databases are shared with your integration.'
2023-01-22T13:45:56.358272Z	}
2023-01-22T13:45:56.364981Z	@notionhq/client warn: request fail {
2023-01-22T13:45:56.365196Z	  code: 'object_not_found',
2023-01-22T13:45:56.365335Z	  message: 'Could not find database with ID: 63156ec7-4870-4bf9-b55e-33eeaaac0c5e. Make sure the relevant pages and databases are shared with your integration.'
2023-01-22T13:45:56.365484Z	}
2023-01-22T13:45:56.506533Z	 error   Could not find database with ID: 63156ec7-4870-4bf9-b55e-33eeaaac0c5e. Make sure the relevant pages and databases are shared with your integration.
2023-01-22T13:45:56.506947Z	  File:
2023-01-22T13:45:56.507177Z	    /opt/buildhome/repo/node_modules/@notionhq/client/build/src/errors.js:162:16
2023-01-22T13:45:56.507394Z	  Code:
2023-01-22T13:45:56.507559Z	    161 |     if (apiErrorResponseBody !== undefined) {
2023-01-22T13:45:56.507773Z	    > 162 |         return new APIResponseError({
2023-01-22T13:45:56.50796Z	          |                ^
2023-01-22T13:45:56.508181Z	      163 |             code: apiErrorResponseBody.code,
2023-01-22T13:45:56.508339Z	      164 |             message: apiErrorResponseBody.message,
2023-01-22T13:45:56.508508Z	      165 |             headers: response.headers,
2023-01-22T13:45:56.508688Z	  Stacktrace:
2023-01-22T13:45:56.508858Z	APIResponseError: Could not find database with ID: 63156ec7-4870-4bf9-b55e-33eeaaac0c5e. Make sure the relevant pages and databases are shared with your integration.
2023-01-22T13:45:56.508977Z	    at buildRequestError (/opt/buildhome/repo/node_modules/@notionhq/client/build/src/errors.js:162:16)
2023-01-22T13:45:56.509128Z	    at Client.request (/opt/buildhome/repo/node_modules/@notionhq/client/build/src/Client.js:347:54)
2023-01-22T13:45:56.509254Z	    at processTicksAndRejections (node:internal/process/task_queues:96:5)
2023-01-22T13:45:56.509365Z	    at async getAllPosts (file:///opt/buildhome/repo/dist/entry.mjs?time=1674395155378:1946:17)
2023-01-22T13:45:56.509501Z	    at async getPosts (file:///opt/buildhome/repo/dist/entry.mjs?time=1674395155378:1957:20)
2023-01-22T13:45:56.509697Z	    at async Promise.all (index 0)
2023-01-22T13:45:56.509841Z	    at async file:///opt/buildhome/repo/dist/entry.mjs?time=1674395155378:2615:53
2023-01-22T13:45:56.510001Z	    at async renderPage (file:///opt/buildhome/repo/node_modules/astro/dist/runtime/server/render/page.js:89:30)
2023-01-22T13:45:56.510115Z	    at async renderPage (file:///opt/buildhome/repo/node_modules/astro/dist/core/render/core.js:86:20)
2023-01-22T13:45:56.510227Z	    at async generatePath (file:///opt/buildhome/repo/node_modules/astro/dist/core/build/generate.js:285:22)
2023-01-22T13:45:56.510343Z
2023-01-22T13:45:56.555499Z	Failed: build command exited with code: 1
2023-01-22T13:45:57.474402Z	Failed: an internal error occurred

Could you share the following information to investigate?

URL of your Notion database which can be retrieved from "Share" in the menu
Screenshot of the page https://www.notion.so/my-integrations
Screenshot of the "Cennections" section in the menu of your Notion database
"Environment variables" page of your Cloudflare Pages project

3 is like fllowing:

https://factual-zinnia-8ad.notion.site/3efde9156ec749b1aa191fa8d99deee2?v=63156ec748704bf9b55e33eeaaac0c5e

4.

Thanks for giving information.
Your secret tokens were visible so I deleted your last screenshot. Please reissue your secret token on the Notion integration page.
You seem to make a mistake to retrieve a database ID.
Take a look at the following screenshot of README.

You use v= value as DATABASE_ID so please use ahead string.

thank you very much it worked!!
Had issue when used blocks like video upload,..

I'm glad to hear that.
Ah, uploaded videos are not supported currently. You can use YouTube video link instead.
Have fun!


Release patch

Relates to #127 (previous release)
Summary
Release v0.3.1

The automated release following this Pull Request failed because the "Release / Validate" job failed due to a missing dependency (while running make verify).
This can be resolved by installing the necessary dependency using:
https://github.com/ericcornelissen/js-regex-security-scanner/blob/d38537aa37b1d47ff0c9fc9655cf16ad7f3453e4/.github/workflows/check.yml#L55-L56


Fix deprecation warning about GLOBAL

This came up on CITGM (https://github.com/nodejs/citgm) and it's
easy to fix.

@jashkenas tag dis


System Preference Panes clarification and/or feature request

I'm trying to understand if there is a difference or purpose in the "Enabled Preference Panes" and "Disabled Preference Panes" selection in the com.apple.systempreferences payload panel in ProfileCreator. It appears that the result would be the same when using one or the other.
I think that the Disabled Preference Pane should be changed to use the HiddenPreferencePanes key. These two screenshots show the difference.
With DisabledPreferencePanes key/array, but HiddenPreferencePanes key/array NOT used

With DisabledPreferencePanes key/array and HiddenPreferencePanes key/array

I'm sorry. I misunderstood when I first read this issues.
It seems that the Hidden key is missing, I will add that, as they are doing different things. Thanks. I'll add and update later today

I've added that updated manifest to the repo, so you can update and use the hidden setting now.


Add icon to chat api and fix some bugs

🥲
List of bugs fixed:

C2S chat messages always reported they were on the client, despite being able to be received on the server
The MODIFY event for server side inbound chat didn't do anything
The MODIFY event for server side outbound profile independent messages didn't do anything
AFTER_PROCESS for server side inbound chat had a small risk of executing out of order

This PR has no API changes, as any behavior changed was broken to the point of being useless in any mod.

Note for myself to act on later: !register_bad needs to be fixed;
Anyway, PR tested! Therefore, it'll enter a FCP period of 3 days!

Note for myself to act on later: !register_bad needs to be fixed;
Not anymore


new.target not supported?

I'm getting no-undef errors trying to lint ES6 new.target with babel-eslint (espree feature 'newTarget'). I guess this is something that must be adressed in babel-eslint?
FWIW, it can be worked around by defining 'new' and 'target' as known globabls.

Which version of eslint and babel-eslint are you using? I was not able to reproduce this with both tools at the latest version.
I did indeed find a problem in espree, but I think this is unrelated.
eslint/espree#274

It's fine on the latest version for me as well. Thanks for the follow-up!


Authors affiliations

Implements https://github.com/libero/libero/issues/145.
Minimal implementation to get the data and templating correct. Additional elements and CSS class names will be considered on a case-by-case basis when styling this component in https://github.com/libero/libero/issues/146

Once the approach is stable, will add sample data for the other usages.

@thewilkybarkid Looks good 👍


Taylor/hash spruce back

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Internal functions appear in API docs

It looks like internal functions are added to our public API documentation.
See below for example.
Tag: @cgranade @KittyYeungQ

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 83db2f0e-fd61-7881-7cd4-41f9925cfd79
Version Independent ID: fcc0bd04-8cb3-b1fa-7839-3c093fddceb5
Content: UpdatedOutputPattern function - Q# reference - Microsoft Quantum
Content Source: api/qsharp/microsoft.quantum.synthesis.updatedoutputpattern.md
Product: quantum
GitHub Login: @ricardo-espinoza

I'm not finding it at the moment, but we had a qsharp-compiler issue open for that as per your previous report. The issue has since been fixed, but we decided not to include that fix in the previous release or any of its hotfixes; as a result, the fix should land in the next release when API docs are next published.


make rabbitmq handle events

we are now needing to have more then one listener per "event" in order to do this we need to start publishing to exchanges.
This change is an opinionated way to do Pub/Sub events using rabbitmq I chose this way so we can have a uniform way to pass messages across the system without worrying about implementation details. This also provides a layer of abstraction between the queue service and the client  (ex we could swap out for redis events or some other event / broker application) We also follow the node style of event emitter because that is what we are building here.
I am adding this new functionality while retaining old methods.
To use this new functionality you need to define the queues up front. I did this for two reasons

We have queue information during initialization
because of above we will fail early if we cannot assert queues.

as part of the options object we will add
publishedEvents and subscribedEvents which are arrays of the names of events we care about.
to publish events we use the same api. client.publish('event', data)
to subscribe to events you also use same api client.subscribe('event', cb)

approach looks good to me. +1 because it doesn't break additional functionality but adds new. Few tiny comments to fix

looks good


Minimize with trust-constr method leads to TypeError if option verbose is set to 2 or 3

When I changed the minimize method to "trust-constr" I got the TypeError. TypeError does not appear if verbose is set to 0 or 1.
Reproducing code example:
cons = ({'type':'ineq','fun': lambda params: params[31]},\
        {'type':'ineq','fun': lambda params: params[-1]})

opts = {'maxiter': 1000, 'verbose': 3, 'factorization_method': 'SVDFactorization'}

result = scipy.optimize.minimize(func_value,params,args=(func_args), method='trust-constr', \
                      options=opts,constraints=cons)

Error message:
   File "C:\ProgramData\Anaconda3\lib\site-packages\scipy\optimize\_minimize.py", line 628, in minimize return _minimize_trustregion_constr(fun, x0, args, jac, hess, hessp,

  File "C:\ProgramData\Anaconda3\lib\site-packages\scipy\optimize\_trustregion_constr\minimize_trustregion_constr.py", line 509, in _minimize_trustregion_constr
    _, result = tr_interior_point(

  File "C:\ProgramData\Anaconda3\lib\site-packages\scipy\optimize\_trustregion_constr\tr_interior_point.py", line 321, in tr_interior_point
    z, state = equality_constrained_sqp(

  File "C:\ProgramData\Anaconda3\lib\site-packages\scipy\optimize\_trustregion_constr\equality_constrained_sqp.py", line 93, in equality_constrained_sqp
    while not stop_criteria(state, x, last_iteration_failed,

  File "C:\ProgramData\Anaconda3\lib\site-packages\scipy\optimize\_trustregion_constr\tr_interior_point.py", line 251, in stop_criteria
    if self.global_stop_criteria(state, x,

  File "C:\ProgramData\Anaconda3\lib\site-packages\scipy\optimize\_trustregion_constr\minimize_trustregion_constr.py", line 449, in stop_criteria
    BasicReport.print_iteration(state.nit,

  File "C:\ProgramData\Anaconda3\lib\site-packages\scipy\optimize\_trustregion_constr\report.py", line 28, in print_iteration
    print(fmt.format(*args))

TypeError: unsupported format string passed to numpy.ndarray.__format__

Scipy/Numpy/Python version information:
1.5.0 1.19.1 sys.version_info(major=3, minor=8, micro=3, releaselevel='final', serial=0)

This looks like a duplicate of https://github.com/scipy/scipy/issues/10880.  But that problem was fixed in SciPy 1.4.0 by https://github.com/scipy/scipy/pull/10946, and you say you are using SciPy 1.5.0.
Can you provide a minimal but complete code example that demonstrates the problem?  It would be helpful to have code that we can simply copy and run to produce the problem.

Also, can you add the lines
import scipy
print("SciPy version", scipy.__version__)

to your code to verify that you are, in fact, running the code with SciPy 1.5.0?

Also, can you add the lines
import scipy
print("SciPy version", scipy.__version__)

to your code to verify that you are, in fact, running the code with SciPy 1.5.0?

I use this code to check my SciPy version. It is for sure 1.5.0.
When it comes to providing the full code it could be problematic, because it is currently rather developed with a lot of nested stuff, however I will try to provide simplified version soon.

Thanks @JacekB104.  It turns out I was able to create a small example that reproduces the problem in both SciPy 1.5.0 and in the latest development version ('1.6.0.dev0+02563b2').  To reproduce the prolem, I had to return a 1-d array from the objective function (instead of a scalar), and make the length of the state vector big enough.   Here's a script that reproduces the error TypeError: unsupported format string passed to numpy.ndarray.__format__.  I only get the error if n is greater than 24.
import numpy as np
from scipy.optimize import minimize

def objective(x):
    return np.array([(np.sum((x + 1)**2))])

cons = {'type': 'ineq', 'fun': lambda x: x[0]}
opts = {'maxiter': 1000, 'verbose': 3}

n = 25
x0 = np.linspace(-5, 5, n)

result = minimize(objective, x0=x0, method='trust-constr',
                  constraints=cons, options=opts)

Thank you for your answer! That can be a case, because my state vector has 58 variables, which is relatively a lot.  My objective function returns a 1-d array. Do you think that changing my objective function to return a scalar will solve the problem?

I edited my previous comment to fix a false conclusion that I jumped to too quickly.  The failure does not seem to occur only for n sufficiently large.  I updated the comment to show that there isn't an obvious pattern for which values of n will generate the error.
@JacekB104, I think ensuring that your objective function returns a scalar should fix the problem.  In the script shown above, I fixed objective  to return a scalar, and ran it with n ranging from 2 up to 60, and the error did not occur.

Ok, so it looks that the objective function return type is a source of an error. I will work with this setting and if I find the error again, I will let you know. Thank you for your help!

To any devs who follow up on this: the error occurs because args[4] (which is the 'tr radius' value) in the args passed to the method print_iteration of the report class ends up as a 1-d array of length 1 instead of a scalar.  I haven't dug any deeper than that.

The PR above uses a slightly modified test case to avoid a grad_delta==0 warning in the tests, otherwise it is very similar to #10880.


Introduce pushdown benchmarks

Description
This is still an early draft and there's a lot of unrelated code that will be refactored and removed later, don't consider any decisions here as final
Closes #2378.

Readiness checklist

[ ] I added/updated unit tests.
[ ] I added/updated integration/compatibility tests.
[ ] I added/updated comments and checked rendering.
[ ] I made spot refactorings.
[ ] I updated user documentation.
[ ] I ran task all, and it passed.
[ ] I ensured that PR title is good enough for the changelog.
[ ] (for maintainers only) I set Reviewers (@FerretDB/core), Assignee, Labels, Project and project's Sprint fields.
[ ] I marked all done items in this checklist.

copilot:all


nixos/systemd/initrd: follow init param symlinks

Description of changes
Fixes an incompatibility between boot.initrd.systemd and boot.loader.generationsDir. Fixes https://github.com/NixOS/nixpkgs/issues/219767.
The initrd-nixos-activation service determines which system closure to activate by inspecting the init kernel parameter. It assumes that the init parameter is a full path to the system closure, such that taking dirname and appending /prepare-root will point to the right script.
However, some boot loaders pass an init path which includes symlinks. For example, on a system using boot.loader.generationsDir, init=/boot/default/init where /boot/default is a symlink to a folder like /boot/system-38, which in turn contains init, a symlink to the init script in the system closure in the Nix store. This setup breaks with boot.initrd.systemd because the initrd-nixos-activation script fails to find and activate the system.
This change resolves symlinks in the init parameter. It does this by repeatedly calling readlink -m because the filesystem is mounted at /sysroot, so absolute symlinks will terminate symlink resolution.

Testing
Tested booting with these configurations:

[x] systemd-boot (init = absolute path)
[x] generationsDir with https://github.com/NixOS/nixpkgs/pull/198728 (init = relative link -> absolute link -> absolute path)

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)

[x] systemd-initrd-simple
[x] systemd-initrd-btrfs-raid
[x] systemd-initrd-networkd

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

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/2467

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/2550

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/2683

Wouldn't it be better to just chroot into /sysroot and run realpath, rather than writing a custom bash loop?

Well, the coreutils in use by initrd should exist in /sysroot, right? So just use the one that's already on PATH, expecting it to exist in /sysroot post-chroot?
I guess it's technically possible that the coreutils in initrd has been overriden or something like such that it isn't part of the system generation's runtime dependencies, but that seems like it isn't worth working around.

Updated to use chroot and re-tested.

I ran into errors related to the chroot change while setting up a new Raspberry Pi. Marking this as draft until I can figure out the cause.

Nevermind, the issue was something else. And now I've tested this change with extlinux.

Is there anything that prevents this PR from being merged?

@ofborg test systemd-initrd-simple

Unrelated error, but otherwise successful.

machine # [    6.995250] dbus-daemon[610]: dbus[610]: Unknown username "systemd-timesync" in message bus configuration file


[Mock Hub] Testing utility V1 for Event hubs

Packages impacted by this PR
Stress tests involving event-hubs
Issues associated with this PR
#27993
Describe the problem that is addressed by this PR
Marks the first release of mock-hub utility library. This package exposes a mock Event Hubs service for use in testing, based on the "rhea" library. Please note that this package is intended for testing purposes only and should not be used in production environments.
The mock service currently represents a single Event Hub within a namespace.
Features

Event Receiving and Storing: The service can receive and store events from a client.
Event Partition Assignment: Supports partition assignment based on partition id, partition key, or round robin.
Event Sending: Capable of sending events to a client while respecting link credits, starting event position (source filter), and tracking last enqueued event properties.
Multiple Consumer Groups: Supports multiple consumer groups.
Event Hub Properties: Can read Event Hub properties and Event Hub partition properties.
Validation/Errors: Includes validation and error handling for various scenarios such as invalid partition id, CBS auth requested for invalid entity, exceeded message size, owner level validation, invalid consumer group, and invalid Event Hub name.
TLS Support: The service supports TLS.

API change check
API changes are not detected in this pull request.


msfirewall/demo-temporary-jumpbox: Template password parameter not working

I just deployed the msfirewall/demo-temporary-jumpbox template.
I have replaced the adminPassword paramater in the deploy-60-servers.parameters.json parameter file beforehand.
I was not able to RDP into the jumpbox due to rejected creds.
I have reset the password in the portal for now and was able to RDP.
Just wanted to track this issue in case it happens to other users.
Thanks
Chadi

Hi chadif,
When you updated the password in deploy-60-servers.parameters.json did you also create a corresponding keyvaults entry back in the demo-core-msfw-nsg\parameters\deploy-40-keyvaults.parameters.json file?
Remember that this "adminPassword": "server2016DefaultPassword", is not actually a password but rather a keyvault secrets pointer.

2nd could also manually create the keyvault secret in the keyvault store via the azure portal and use that new secret name as the parameter in deploy-60-servers.parameters.json.
Bernard

ok I was not aware of that and obviously didn't change the keyvault entries, in fact keyvault was deployed separately first.
So I think the parameter's name will be a little misleading for new users, maybe we should consider a rename or additional comments in the readme or both.

Will make sure we make it clear in the readme.md
Thank you for reporting. This is how we can improve on the current templates and documentation ;-)

Absolutely, and thanks for your great work. I will close the issue for now.


iOS Fixed Position Modal Bug

Bug Report
Description
Editable fields in fixed content (ie Modals) do not behave as expected.  iOS accounts for the keyboard by natively shifting up the view.  When quickly switching between editable fields, it's possible this shifting can get off.  See the attached image below.
Steps to Reproduce

Have an editable field on the page, in a modal
Select the editable field
Quickly deselect, then reselect the field

Note: this doesn't happen every time, and may be more prone to UIWebview and not Safari.  Programmatically blurring and refocusing the element could help reproduce the issue as well.
Additional Context / Screenshots

Expected Behavior
The modal and modal overlay do not shift up when changing focus between editable fields.
Possible Solution
Switching to absolute positioning for the modal and modal overlay resolves the problem.  There are many documented bugs around fixed positioning and how it responds to the keyboard on iOS.
Environment

Component Name and Version: N/A
Browser Name and Version: UIWebview, iOS 11.2, iOS 11.4
Node/npm Version: 9.2.0, 5.5.1
Webpack Version: 4.20.0
Operating System and version (desktop or mobile): Mobile iOS

@ Mentions
@dkasper-was-taken, @tbiethman

@dkschoonover This has been released in<EMAIL_ADDRESS>


CHECK fail in tf.raw_ops.ResourceGather when dtype value is mismatch with dtype value of indices

Click to expand!
Issue Type
Bug
Source
binary
Tensorflow Version
2.10
Custom Code
No
OS Platform and Distribution
Ubuntu 20.04.4 LTS
Mobile device
No response
Python version
3.8
Bazel version
No response
GCC/Compiler version
No response
CUDA/cuDNN version
No response
GPU model and memory
No response
Current Behaviour?
When passing `dtype` value to `tf.raw_ops.ResourceGather` that is not match with the dtype value of `indices`, it will trigger Aborted (core dumped) cause the program termination.

Standalone code to reproduce the issue
from tensorflow.python.eager import context
import tensorflow as tf

input1 = tf.ones(dtype=tf.int32, shape=[1, 0])
indice = tf.raw_ops.VarHandleOp(dtype=tf.int32, shape=[2, 3], shared_name=context.anonymous_name())

tf.raw_ops.ResourceGather(resource=input1,indices=indice,dtype=tf.bool)

Relevant log output
2022-10-26 02:57:29.368524: F tensorflow/core/framework/tensor.cc:719] Check failed: dtype() == expected_dtype (3 vs. 10) bool expected, got int32
--Type <RET> for more, q to quit, c to continue without paging--bt 10

Thread 1 "python" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt 10
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007f175fc14859 in __GI_abort () at abort.c:79
#2  0x00007f1746aaac5c in tensorflow::internal::LogMessageFatal::~LogMessageFatal (this=0x7ffe3a2ccf90,
    __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at tensorflow/core/platform/default/logging.cc:375
#3  0x00007f171b4ef733 in tensorflow::Tensor::CheckType (this=0x1465150, expected_dtype=tensorflow::DT_BOOL)
    at tensorflow/core/framework/tensor.cc:719
#4  0x00007f173823a0ae in tensorflow::Tensor::shaped<bool, 1ul> (this=0x1465150, new_sizes=...)
    at ./tensorflow/core/framework/tensor.h:890
#5  0x00007f1738239660 in tensorflow::Tensor::flat<bool> (this=0x1465150) at ./tensorflow/core/framework/tensor.h:564
#6  0x00007f173ccf9361 in tensorflow::Status tensorflow::EnsureSparseVariableAccess<Eigen::ThreadPoolDevice, bool>(tensorflow::OpKernelContext*, tensorflow::Var*) ()
   from /usr/local/lib/python3.8/dist-packages/tensorflow/python/_pywrap_tensorflow_internal.so
#7  0x00007f173cccf684 in tensorflow::ResourceGatherOp<Eigen::ThreadPoolDevice, bool, long>::Compute(tensorflow::OpKernelContext*) () from /usr/local/lib/python3.8/dist-packages/tensorflow/python/_pywrap_tensorflow_internal.so
#8  0x00007f171b7eac82 in tensorflow::ThreadPoolDevice::Compute (this=0x3e4ed40, op_kernel=0x50bf030, context=0x7ffe3a2cda40)
    at tensorflow/core/common_runtime/threadpool_device.cc:184
#9  0x00007f171b69709c in tensorflow::(anonymous namespace)::SingleThreadedExecutorImpl::Run (this=0x50ce2c0, args=...)
    at tensorflow/core/common_runtime/single_threaded_executor.cc:445

@jdanceze,
Could you please take a look at this comment and also I tried to execute the mentioned code on alternative appraoch and was executed without any issue/error. Kindly find the gist of it here. Thank you!

@tilakrayal Please check internally with the teams how we need to handle assert issues on raw ops after we have declassified these as security bugs.
Cause in the last few days we had many tickets like this one.

@tilakrayal according to your colab, the crash will only trigger when dtype in tf.raw_ops.ResourceGather  is not match with dtype of indice. Hence, if both dtype is tf.int32, it will not trigger crash.

@jdanceze using your code snippet I got error "InvalidArgumentError: Value for attr 'Tindices' of resource is not in the list of allowed values: int32, int64" instead of the "Check failed" in tensor.cc.
Did you intend to use the following example instead? (notice I swapped the definition of input`` and indice`)
from tensorflow.python.eager import context
import tensorflow as tf

input1 = tf.raw_ops.VarHandleOp(dtype=tf.int32, shape=[2, 3], shared_name=context.anonymous_name())
indice = tf.ones(dtype=tf.int32, shape=[1, 0])

tf.raw_ops.ResourceGather(resource=input1,indices=indice,dtype=tf.bool)

@JW1992 Yes, I made the mistake in my code snippet. The crash used to be reproduced from your snippet.

@jdanceze Could you please confirm if this is still an issue ?
Thank you!


Bug: Imports from a Ghost installation: Imported 'Owner' account login not permitted, gives incorrect error message.

Issue Summary
When importing data from a Ghost installation (Blog Old) to a different install of Ghost (Blog New) and then logging out of the Blog New admin account on Blog New a user attempting to log back in to Blog New with the (different) account details for the imported "Owner" account from Blog Old is given an error message saying that the account is "Locked due to too many login attempts.", urging them to use the Forgotten Password link, even though this account has never attempted a log in before on this new installation of Ghost. When user follows through with password reset the account works fine.
Steps to Reproduce
Export Ghost settings and data from one Ghost install, import into a different installation.
Log out of Ghost on the installation which the data was imported into.
Attempt log in with account credentials contained in imported data and settings, see incorrect error message.

Expected behavior
User is given correct error message explaining why they are unable to log in. Or, user is able to log in to imported accounts without any issues when importing from another Ghost installation. If password reset is required on import, a call to action.
Technical details

Ghost Version: Release 0.5.7
Node Version: 0.10.25

@lemur3 Thanks for the bug report. When an import is performed, any imported user account is locked. Although the message isn't quite accurate with regard to there being 'too many login attempts', it is correct in so much as the user needs to use the reset password flow to gain access.
However, it sounds like the main bug here is something slightly different. Can you please clarify the following details:

Are you logging out of, and then logging back into the same account?
Was there only one account on Blog New when you performed the import?
Does Blog Old contain a user with the same email address as the owner on Blog New? If so, is the user on Blog Old also the Owner?

One account on both blogs, each with a different email address and password, both 'Owner'
Logging out of the 'Owner' account created upon install of the 'New' blog (destination of import).
Logging to import destination in using imported user account details from the 'Old' blog.

Ok cool, that's exactly how I would expect it to work. You're creating a new account through an import, so it will require you to do the password reset.
The only thing is the message saying 'due to too many login attempts.'  - we can remove that part of the message and it should work for all forms of account locking.

Good to know that this is the expected way for it to work. I hadn't noticed it in any documentation so I wasn't sure.
Though, perhaps not a bug, and more of a general change request, notifying users (in some way) that imported accounts may be locked by default on import would be good. Informing them that their account is locked only when they try to log in is not as graceful as I imagine Ghost should be.

@lemur3 that's a very valid point, but is also the exact reason why this feature lives on the labs page, and doesn't have it's own home yet - it isn't up to the same standard as other parts of Ghost just yet ;)


Items falling on the floor even if you are not overweight

If I forge Ores it appears that the ingot is created before the ore is removed from the bag, making the ingot fall because you are overweight.
Same thing happens when you cut cloth to make bandages. Also when you buy stuff from a NPC.
Can you guys take a look at it?

issue with ingots and bandages is that sphere does not remove these items before it adds the new thing. So when it tries to add ingots smelted from ore, you still have the weight from the ore in your bag , and the ingots will drop to the floor. Same thing with cloth and making bandages.

Bandage and leather strips should be fixed, i checked the bolt of cloth and they are properly removed before the folded cloth are created.

Can confirm this is fixed.


Slash command

Add slash command support. This will help the bot be more spread and people will use slash commands too! Just a suggestion.

okay, noted


Export .py file to jupyter notebook, .ipynb

I truly love the data science features, but it's not functional.
I want to export a python file to a jupyter notebook (only contains input) , cuz the python interactive in VSCode, is too slow for me, and crashed sometimes.
So that I could use VSCode as my main editor and run cells in jupyter lab.

Btw I have tried ipynb-py-convert, isn't functional too.

Hey @Lips7. If you are having crashing issues with the python interactive window I'd love to help try to resolve those for you.
But if you are just interested in export we totally have that option. Just have a .py file open and use the #%% cell markers to denote where you want the .ipynb cells to be. Then in the VSCode command palette pick either of these two options:
Python: Export Current Python File as Jupyter Notebook
Python: Export Current Python File and Output as Jupyter Notebook
Option 1 will just convert the code, while Option 2 will execute the cells and put the output into the file. When the file is converted it will be there on disk and you'll get a popup if you want to open it in a browser.

We believe that this issue is resolved. Please respond if there's something we missed. Thanks!


Integration tests do not properly update zookeeper port for geoserver plugin

The datastore config is located in:
https://github.com/ngageoint/geowave/blob/master/geowave-test/src/test/resources/mil/nga/giat/geowave/test/gs.zip
And has the value {{ZOOINSTANCE}} for the zookeeper port, which gets replaced by the randomly generated port.
The directory gs.zip is unzipped here:
https://github.com/ngageoint/geowave/blob/40b6cbbce4dc304539835b264e658cad4d2f16a7/geowave-test/src/test/java/mil/nga/giat/geowave/test/GeoServerIT.java#L65
There is a test that is supposto check if the sizes are different, but it does not appear to work properly - on both a win 8.1 system and Ubuntu 14.04 LTS box the file doesn't get over-written.
When a new instance is run, the logic fails to find the term {{ZOOINSTANCE}} to replace (just the localhost:83473 (or whatever port number)).
This results in an old datastore.xml file with an incorrect ZooKeeper port, and thus lots of errors in the logs and failed integration tests.
This issue might be fixed by the upcoming integration test changes (get that binary out of there!) - but will leave the ticket open until then to verify it's fixed.   Otherwise the extracted files could simple be deleted in the teardown method.

Fixed as of  #188


rain, collision & water bug

Hello everybody.
I'm a french student using your mod ( my English is not marvelous ). I like very much your work.
I would like to declare many bugs I've found
1 ) It rain IN ships. The rain cross the ceiling !

I can't climb ladders in ships

3 ) In ships, the water is not really water, we can't swim in.
4 ) 2 ships does not collide between them. A ship is a "ghost" without another ship. But the player is killed.
5 ) When i sit in pilot's seat, i can' t leave it pressing w. I must quit the game and restart to quit or using \tp command
I hope you'll fix them and good luck to you, it's really an incredible work !

5:
Why would it let you leave by moving? The whole point of mounting stuff is exactly to be kept in place
You can leave the pilot chair/seat, just press shift, like you would to unmount from any animal/boat/cart

The first time it works, but the second it failed. I don't understand this behavior... The passenger seat don't seem to have the same problem.

if you want to walk on a ship while it's moving, you should use engines to propel your ship. you just need levers to active/de-active them

Besides the rain, these issues are known and can be found in the github at various places. Thanks for your report, but I'm going to close this since I'm cleaning up old issues right now.
Thanks again!


[IFB] Invalid CIMI filter

Dear support
This issue is encountered when filterting event or service offer, example are only provided for the second.
I would like to get the service offer of the ifb-core-pilot, I follow this documentation ( http://www.dmtf.org/sites/default/files/standards/documents/DSP0263_1.0.0.pdf ) page 14 line 512
I can do
https://nuv.la/api/service-offer?$filter=id='service-offer/03289337-6fa4-4657-9282-896cba082532'
but the following does not work (and should?)
https://nuv.la/api/service-offer?$filter=connector['href']='ifb-core-pilot'
image

Best regards
Bryan

Your filter is not valid.  Section <IP_ADDRESS> of the CIMI spec has the formal grammar; the grammar as implemented in SlipStream has been extended slightly to allow for hierarchical attributes. The levels in the hierarchy should be separated by slashes.  For the href attribute you want to use connector/href.
Please reopen the issue if this doesn't solve your problem.

Thanks !
solution


vaadin-date-picker 1.0

This is the tracking issue for the first version of the vaadin-date-picker element, with the following sub-tasks:
vaadin-date-picker 1.0 milestone

Closing as irrelevant for now. We can think about how we want to track these larger “epics” once we start implementing the date picker.


Adding/approving model repo access via API

System Info
latest
Who can help?
@stevhliu and @MKhalusova
Information

[ ] The official example scripts
[ ] My own modified scripts

Tasks

[ ] An officially supported task in the examples folder (such as GLUE/SQuAD, ...)
[ ] My own task or dataset (give details below)

Reproduction
For a gated repo, is it possible to add users via api?
I'm searching through the docs and not seeing anything.
Thanks.
Expected behavior
Option to add users to a gate repo via api.

@RonanKMcGovern would the solution described in https://github.com/huggingface/huggingface_hub/issues/1535#issuecomment-1614693412 works for you? It is not implemented for now as we got very few requests (and is quite niche atm). If you are talking about something else, please let me know.

You can run it as it is! It will not be implemented/merged in the coming weeks I think as we prefer not to push it officially (low usage and that would constrain us if we want to change the API in the future).
I'll close this issue as duplicate of https://github.com/huggingface/huggingface_hub/issues/1535. Please let me know if you need to reopen.


Fix small CSS issues of Tesoro y Gloria 2 Edition

Submission Checklist
Required

[x] The pull request title clearly contains the name of the sheet I am editing.
[x] The pull request title clearly states the type of change I am submitting (New Sheet/New Feature/Bugfix/etc.).
[x] The pull request makes changes to files in only one sub-folder.
[x] The pull request does not contain changes to any json files in the translations folder (translation.json is permitted)

Changes / Description
Fix a couple of issues regarding the CSS styles of some elements of the sheet.

Character Sheet Info Roll20 Internal Use only.


Is it possible to calculate two kinds of gradient separately in tensorflow

w_1   = tf.get_variable("w_1", shape)
w_2   = tf.get_variable("w_2", shape)
output = tf.mul(w_1, w_2)
.....
.....
optimizer = tf.train.AdamOptimizer(alpha).minimize(self.cost)

As we know, when we run "optimizer", tensorflow will caculate gradient and update w_1 & w_2.
But what i want to do is, first, I want to treat w_1 as a constant, I just want to caculate gradient and update only w_2. Second, treat w_2 as a constant and caculate gradient and update only w_1. I want to take turns to do these things.
Actually, I have seen this  #before: #834. But I use BasicLSTMCell module.  I try this code: print (tf.get_collection(tf.GraphKeys.TRAINABLE_VARIABLES)), it shows there are four kinds of parameter in my neural network, which means besides w_1 and w_2, there are other two parameters in  BasicLSTMCell.
So, if I use such as var_list=[w_1], the other two parameters in BasicLSTMCell  can not be optimized, How can I do it?

I found it. I can use var_list in minimize function

Yes, it is possible, and I added an answer on Stack Overflow that covers your case. Feel free to post any follow-up discussion over there!

Trigger update_date


PDB structure culstering

Hi @a-r-j and @amorehead, I would like to propose a feature: PDB structure clustering. It would be useful for structure-related tasks like structure prediction and generation. Would you be interested in this idea and want to talk about how to implement this feature? I am thinking about using foldseek for clustering and creating metadata containing the clustering information.
It would be great if you guys have any comments on this feature!
Best,
Zhangzhi

Hi @amorehead, I try to reach you by email but got no response. It's possible that my email has ended up in their spam folder or that you have not had the chance to respond yet.
Is there any way to reach you in private?

Yep! Happy to help! I think the first thing is to figure out the exact features we want. I personally have a use case. I want to cluster all pdb structures into N clusters, where N can be very small like 2. In each cluster, we can further cluster them to derive representative samples. Seems like current tools like foldseek does not support that preset num of clusters.

Hmm, what do you think about an approach where you use FoldSeek to get a set of representative clusters, then you can apply some hierarchical clustering method based on the inter-cluster representative structure TM scores?


label size increases with increasing device font size. how to make it fixed ??

Have you tried using
// Use custom text appearance in tab titles.
mBottomBar.setTextAppearance(R.style.MyTextAppearance);

Although it shouldn't be encouraged to have fixed font-sizes, as then the accessibility settings by the device don't have an effect:


Line and paragraph spacing

cc @rfuest (because of this comment)
The current idea would be to provide 2(+1) functions:

line_height
line_spacing
(later a paragraph_spacing similar to line_spacing but it's far off)

Both of these functions would set the distance between baselines, but line_height would use pixels, while line_spacing would use a multiplicative  factor (probably f32 simply because I find fixed point unwieldy) value. The latter would somewhat align to what word processors are doing, while the former doesn't require f32 support.
Internally, line_spacing could be something like a multiply-and-round implementation calling line_height.
Do you have any better idea for line spacing? One drawback is that it would lock paragraph_spacing into using an f32 value without a line_height analogue that would set spacing in pixels (thinking about it some more, a pixel-based paragraph spacing would also be confusing if it had the same meaning as line_height - I can imagine what a surprise it would be if a paragraph_spacing of 12 pixels would result in 4px of space...).

I suppose you mean functions inside the style constructor?
Mixing line_height and line_spacing might get confusing. I would stick with line_height, which is also used in CSS. If line_spacing(self, factor: f32) is only a constructor function, we could replace it by a line_height_percent(self, percent: u32). This could easily be implemented without floating point and setting the line height in percent is very common. A line_height_relative(self, delta: i32), which just adds delta to the default line height, could also be useful.
Paragraph spacing in DTP applications is always additive. If you set the paragraph spacing to 0 the lines just continue as normal, without any additional space. Any value > 0 adds additional space between the first line of the new paragraph and the last line of the previous paragraph. So IMO paragraph_spacing should be an i32, that is added to the y coordinate of the position, before the first line of the next paragraph is drawn.

cc @rfuest (because of this comment)

Feel free to bug me anytime you could use a second pair of eyes to look at e-t code or discuss new features.

Feel free to bug me anytime you could use a second pair of eyes to look at e-t code or discuss new features.

Thanks, I shall do that! :)
What do you think about providing a single line_height function, that takes a LineHeight value, constructed via extensions on u8/u32? Usage would look something like style.line_height(300.percent()) or style.line_height(16.px()) or similar (even 16 * px but after playing around some with that style of code I think I'd not do that).
This way, a single API could cover both relative and absolute line heights, and usage wouldn't be horrible either.
I think I prefer u32 over i32 here. The conversion is trivial, but taking i32 would have some horrible side effects like drawing bottom-to-up where most of the code really doesn't expect that, I think. Using u32, worst case everything gets drawn in a single line.

What do you think about providing a single line_height function, that takes a LineHeight value, constructed via extensions on u8/u32? Usage would look something like style.line_height(300.percent()) or style.line_height(16.px()) or similar (even 16 * px but after playing around some with that style of code I think I'd not do that).
This way, a single API could cover both relative and absolute line heights, and usage wouldn't be horrible either.

So, like similar to this suggestions, which you found too complicated a month ago? :wink:
https://github.com/embedded-graphics/embedded-graphics/pull/534#issuecomment-769205646
I think that the enum instead of different functions in the constructor is a good idea. This should also make it easier to keep the line height and font settings independent from each other, if you e.g. change the font after setting a line height of 150%.
Should we only support absolute pixel heights and percentages or also relative pixel delta, that is added to the default height? I'm not sure how the extensions methods would be called in that case. 16.px() could be interpreted as an absolute line height of 16px or and an increase of the default line height by 16px.

I think I prefer u32 over i32 here. The conversion is trivial, but taking i32 would have some horrible side effects like drawing bottom-to-up where most of the code really doesn't expect that, I think. Using u32, worst case everything gets drawn in a single line.

I agree that line_height and later paragraph_spacing should be u32 to keep things easy. If we add an relative option for the line height, that adds an delta to the default line height, it should be an i32 to be more flexible.  But to keep rendering easy the addition between the default line height and the delta should be clamped to a minimum value of 0.

So, like similar to this suggestions, which you found too complicated a month ago? 😉

Yes, I can see reason eventually :) But only with the extension methods! Without those, the enum still smells clunky.
In this case I'd probably go without relative options and just have absolute and percentage. Working with pixels is the same "now it looks good enough with a value of X" so relative setting sounds a bit redundant. line_height(16.px()) should unambiguously mean "the line will be 16 px high", IMO.

line_height(16.px()) should unambiguously mean "the line will be 16 px high", IMO.

Yes, it does if no relative option exists. It looks good and the only problem I have with this approach is that no other pixel dimension in e-g needs a .px() suffix. Perhaps line_height_px(height: u32), line_height_percent(percent: u32) would be more consistent with the rest of the API, if you don't like line_height(LineHeight::Absolute(123)) and line_height(LineHeight::Percent(123))

There could be an implicit u32 -> LineHeight::Px (fn line_height(height: impl Into<LineHeight>) {...}) conversion in there. A little bit of complexity, though.

IMO the unit of a value should be explicitly specified by the caller if a value can have different units. The automatic conversion from u32 to a pixel height doesn't make the unit obvious.

That makes sense. My problem with the multiple functions approach is that adding a new unit adds a new function to the builder and that inflates the API surface, as well as adds noise to the documentation.
If we were to add an em unit, having 3 methods to set line height and 3 more for paragraph spacing, I think that would be more methods than what the builder currently has.
I think in this case, while a bit weird compared to the rest of the API, the extension method style will in long term result in less duplication, at least.

OK, good point. Let's go with one method per setting that takes an enum argument.
I wouldn't mind to use .line_height(LineHeight::Percent(150)) directly, without an extension trait. Other style properties also use enums, so this doesn't look out of place IMO. But I guess the extension trait won't hurt.
I also want to add line_height support to e-g's TextStyle. Should we add separate LineHeight enums for e-g and e-t or do we want to share one? I think we would have the same supported units at the moment but the feature set might diverge in the future.

For now, we can use the same type. If at any point e-t needs something extra, I (think) can always add a conversion.

OK, I'll try to add the feature soon. How should the enum look like? Like this?
pub enum LineHeight {
    /// Line height in pixels.
    Px(u32),

    /// Line height in percent of the default line height.
    Percent(u32),
}

impl Default for LineHeight {
    // return LineHeight::Percent(100)
}

Hmm I haven't considered Default, that 100% looks reasonable.
I think I prefer Pixels - there is little need to abbreviate the name. The comments sound a bit redundant, to be fair, but I can't do better here either.
You don't have to hurry, there's still work to be done before I could get to this.

I think I prefer Pixels - there is little need to abbreviate the name. The comments sound a bit redundant, to be fair, but I can't do better here either.

I wasn't sure about this one. While I also prefer Pixels as the enum variant, but I would prefer 123.px() over 123.pixels() for the extension trait. And IMO both should be the same.

But perhaps they don't have to be the same. I think the STM32 HALs also use .hz(), but the type is called Hertz.

Naming is hard. I'd go with .px() and Pixels, as well as Percentage and ?? (.pc() or .pct() would be analogous, but confusing, .percent() is fine, but if one is abbreviated and the other is not, well...)

I think px and percent are OK.
Here is a revised version of the API (comments are WIP):
pub enum LineHeight {
    /// Line height in pixels.
    Pixels(u32),

    /// Line height in percent of the default line height.
    Percent(u32),
}

impl LineHeight {
    /// Converts the line height to an absolute pixel distance.
    pub fn to_absolute(self, base_line_height: u32) -> u32 { ... }
}

impl Default for LineHeight {
    // return LineHeight::Percent(100)
}

pub trait U32Ext {
    fn px(self) -> LineHeight;
    fn percent(self) -> LineHeight;
}

impl U32Ext for u32 { ... }

LGTM!

I'm not sure if this is more complicated than it needs to be. As I mentioned before I'm fine with using the LineHeight enum variants directly.
If we want to go down this route we would need to find a common place to put these units to make sure we don't include two different extension traits with the same method names. If we add some units in e-g and some in e-t we run into the risk to add the same units further down the road and get conflicts.

and get conflicts.

True, although I think conflicts may be avoided by some careful versioning.

I'm not sure if this is more complicated than it needs to be.

It sure is. I can see the added complexity, and the potential problems. It would probably be best to not include extension methods in the first round, and maybe we can figure out a way to add them later, somehow. It's not a big deal, but a small quality of life feature. And also I find it cool enough, which probably is a thing to avoid in API design :)

And also I find it cool enough, which probably is a thing to avoid in API design :)

It is definitely cool, but if we adapt units IMO we should go all in and change all styles to use units. Otherwise we have an inconsistent API, where you sometimes need to add .px() and sometimes can use raw integer values. But this would be a considerable effort, because we would also need to implement a lot of math related traits to make expressions like 1.px() + 2.px() possible.

To be fair, that would be a step towards device-dependent point sizes ;) Imagine drawing a 2cm line in e-g! cc @jamwaffles

Maybe in sometime in the future, but at the moment it would just make styles a little harder to use ;)

To be fair, that would be a step towards device-independent dimensions ;) Imagine drawing a 2cm line in e-g!

IMO that's outside e-g's remit and would be better served by an external crate. It's impossible to do e.g. 2.cm() without knowing the pixel density of the target display, etc

Fair enough, I (think) I intended that comment as a lame joke. But I think 2.cm() would already work if one made a simple extension trait and used it consistently everywhere where right now a simple pixel is needed.


Lint sparse_imports

Lint explanation
Detect use statements that are separated with empty lines, and suggest removing them. The reasoning is that imports that don't have empty lines between them are nicely sorted by rustfmt in an alphabetical order.
This does apply to use statements with different visibility.
This lint is rather subjective and should be opt-in.
Example code
Bad
use std::path::Path;

use serde::Deserialize;

Good
use serde::Deserialize;
use std::path::Path;

Notes
marker must have the ability to provide information about whitespace in code to lints to implement this. I know it is not obvious what AST nodes whitespace (just like comments) should be nested under, but this is not very important. Rust-analyzer, for example has a lossless AST, and it attaches the leading whitespace to AST nodes (more details in https://github.com/rust-marker/marker/issues/189#issuecomment-1652862725).

It should be possible to extract the line location from the spans of the use items. That's how Clippy deals with similar lints. Though right now, spans are a bit broken :sweat_smile: rust-marker/marker#175


Update yaml to use correct secret name

Currently, the documentation on creating a secret for pulling from a private docker registry mentions creating a secret of regcred - https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/.  The example further down however, uses a secret name of regsecret.  This updates the secret name to match the one that was created.

This change is

Thanks for the update @charlesdunbar - appreciate the eye for consistency and better understanding. We’ll need you to the sign the CLA to accept the change - you can find the links/notes for how to do so right above on this PR^^
/assign
/approve

Thanks for the quick feedback!  Had to update my git config email, but ideally should be good now.

/retest
(The CI validation test failure looks like a temp failure of TravisCI to pull in a required dependency)

well, I guess the CI testing failure isn't an issue of something temporary. I'm not deeply familiar with it, but it looks like it's attempting to validate the specific YAML entry and there's it doesn't care for there.

Weird, well - #7510 got it updated, so I’ll go ahead and close this one.


get Size not working in Linux appium 1.9.1

The problem
I have hybrid app and Im trying the below method
MobileDriver.FindElement(LocateElement(type, object)).Size which works fine when running in windows machine with appium server 1.9.1 here is the windows gist When I try to run the same code in Linux machine with appium server 1.9.1 it fails with error "Unknown command". Here is the gist for linux appium server linux gist
Environment

Appium version (or git revision) that exhibits the issue: 1.9.1
Last Appium version that did not exhibit the issue (if applicable): 1.8.1
Desktop OS/version used to run Appium: Linux and Windows 10
Node.js version (unless using Appium.app|exe):
Mobile platform/version under test: Android o
Real device or emulator/simulator: real
Appium CLI or Appium.app|exe: CLI for linux and Exe for windows

Details
<add key="AppiumServer" value="<IP_ADDRESS>" />       <add key="AppiumServerPort" value="4723" />       <add key="PlatformName" value="Android" />       <add key="AutomationName" value="uia" />       <add key="PlatformVersion" value="8.0" />       <add key="DeviceName" value="xxxxxxx" />       <add key="AppPackage" value="com.xxx.xxx" />       <add key="AppActivity" value=".MainActivity" />       <add key="AutoWebview" value="true" />

please refer issue https://github.com/appium/appium/issues/11619 for more details


Allows can-import to be used for dynamic imports

This adds the ability of can-import to be used for dynamic imports. The
static form is still supported, but dynamic imports are allowed by
including a closing </can-import> tag and nesting content within.
The viewModel for can-import is a Promise that will resolve with a
value once the module has been imported.

Going to re-open against minor.


chore(RingTheory/OreLocalization/Basic): Split file and to-additivise

If this is really a split, should be chore rather than feat?

In general, it LGTM: thanks! I am going to test the to_additive attribute a bit, and then I will send it to maintainers.

This is because only u is an element of B.
example {A : Type*} [AddMonoid A] {B : AddSubmonoid A} [AddOreLocalization.AddOreSet B]
  {Y : Type} [AddAction A Y] {r₁ r₂ : Y} {s₁ s₂ : B} :
    r₁ -ₒ s₁ = r₂ -ₒ s₂ ↔ ∃ (u : B) (v : A), u +ᵥ r₂ = v +ᵥ r₁ ∧ u + s₂ = v + s₁ :=
  AddOreLocalization.oreSub_eq_iff

I removed the names of instances and incorporated the other suggestions.
Thanks a lot for the thorough review!

Thanks!
bors merge


Renaming selected folder should select "new" folder

When currently selected folder is renamed, once action is completed, folder is no longer selected and message-list is cleared.
Requirements

Currently selected folder must remain selected after renaming


Improve documentation related to timeout

Changing the documentation based on the comments from @DhritiShikhar here:

https://github.com/redhat-developer/build/pull/158#discussion_r424884869
https://github.com/redhat-developer/build/pull/158#discussion_r424885074

/lgtm

/assign zhangtbj

/lgtm
/approve

/lgtm
/approve

/retest


telegram_bot: Support for sending videos

Description:
Telegram python library has a sendVideo function that can be used
similar to sending photos and documents.
Pull request in home-assistant.github.io with documentation (if applicable): https://github.com/home-assistant/home-assistant.github.io/pull/3936
Example entry for configuration.yaml (if applicable):
...
action:
  service: notify.NOTIFIER_NAME
  data:
    title: Send a video
    message: That's an example that sends a video.
    data:
      video:
        - url: http://<IP_ADDRESS>/camera.mp4
          username: admin
          password: secrete
        - file: /tmp/video.mp4
          caption: Video Title xy
        - url: http://somebla.ie/video.mp4
          caption: I.e. for a Title

Checklist:
If user exposed functionality or configuration variables are added/changed:

[x] Documentation added/updated in home-assistant.github.io

If the code communicates with devices, web services, or third-party tools:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass

Ping on this ? :)


Integrating with Symfony testing

Not really an issue, but I wondered how to integrate tests with Symfony and phpspec/phpspec with the extends of ObjectBehaviour ?

Dunno


Random verification errors

Hello,
I am working on a Java implementation of the Cashu protocol, and I am facing an issue with the verification of proofs.
In my test, I mint 100 units (6 x 16 units + 1 x 4 units) but then, melting fails randomly. For example, I have tried to melt 32 units (2 x 16 units), the first proof gets verified but the second fails. I have spent several weeks troubleshooting and refactoring, but I was not able to find the problem.
I have tried yesterday to run my tests with your library, and was also surprised to see that it produces the same results as my library.
Here's my gist: https://gist.github.com/tcheeric/59ed616843bf4efa21032812a9da5969
I'd be grateful if you could have a look, and maybe you have an explanation for the failure?
Thanks.

replied to you in the gist


Add sparse dense conversion graph

Add graphs for performing sparse to dense conversion and dense to sparse conversion
Remove commented code and unnecessary printing statements in parse_dot.py
Update rewrite lookup function so dense scanners are no longer connected to the GLB tile (Dense scanners are basically counters and does not need data from the GLB)

LGTM


cdc: support to sink old value

What problem does this PR solve?
Old Value is the previously written value before a delete/update operation.
To support the new collation format and compatible with TiDB Binlog, TiCDC requires TiKV to output the old value for it.
What is changed and how it works?
Separate from #8071
What's Changed:
Related changes

Should be cherry-picked to release 4.0 after all related PRs got merged.

Check List
Tests

Unit test
Integration test

Side effects

Performance regression

Consumes more CPU
Consumes more MEM

Release note

N/A

/run-build-image

/test

/run-build-image

/run-build-image

/run-build-image

/run-build-image

/run-build-image

/merge

/merge

/merge

/run-all-tests


Automated cherry pick of #2795: add interface fetch resources of snats and dnats

Cherry pick of #2795 on release/2.11.
#2795: add interface fetch resources of snats and dnats

/lgtm

/approve

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/2.11@c8c6708). Click here to learn what that means.
The diff coverage is 0%.

@@              Coverage Diff               @@
##             release/2.11   #2796   +/-   ##
==============================================
  Coverage                ?   7.19%
==============================================
  Files                   ?     470
  Lines                   ?   74665
  Branches                ?       0
==============================================
  Hits                    ?    5372
  Misses                  ?   68840
  Partials                ?     453

Flag
Coverage Δ

#aFlag
7.19% <0%> (?)

Impacted Files
Coverage Δ

pkg/cloudcommon/policy/resources.go
0% <ø> (ø)

pkg/compute/models/natstable.go
3.38% <0%> (ø)

pkg/compute/models/natdtable.go
4.1% <0%> (ø)

pkg/compute/models/natgateways.go
2.93% <0%> (ø)

pkg/compute/models/snapshotpolicy.go
2.4% <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 c8c6708...aee0cd4. Read the comment docs.


Loose type check between  Integer and Float. Both of them are the same in the javascript context.

Hi,
I got the error at loading a toml file below.
position = [51.01973684210527,15]

In JS context, both Float and Integer are the same type - Number, so I think, there is no need to distinguish between them.
I hope you check my change.
Thank you.

@BinaryMuse
Any chance to get this merged?

I'm not 100% sure this is per spec (that arrays can contain both floats and ints if the underlying language treats them the same). Curious if @mojombo has thoughts.
Even if not, I could imagine a "loose mode" or something that might allow this.


Service protocol no longer attaches view names when querying for Isolates

When using the example code in fuchsia_remote_debug_protocol to query for flutter views, previously the output would look like the following:
The following Flutter views are running:
        file://wifi_settings$main-974514931

Now it only shows the file name:
The following Flutter views are running:
        main.dart$main-212048388

With debugging enabled, the service protocol extension prints out the following:
[INFO:service_protocol.cc(95)] Service protcol method: _flutter.listViews
[INFO:service_protocol.cc(96)] Arguments: 0
[INFO:service_protocol.cc(115)] Response: {"type":"FlutterViewList","views":[{"type":"FlutterView","id":"_
flutterView/0x647cd7a6ca98","isolate":{"type":"@Isolate","fixedId":true,"id":"isolates/212048388","name":"main.dart$ma
[02669.192] 08957.32410> in-212048388","number":212048388}},{"type":"FlutterView","id":"_flutterView/0x647dbd7dae18","isolate":{"ty
pe":"@Isolate","fixedId":true,"id":"isolates/430035393","name":"main.dart$main-430035393","number":430035393}}]}

The engine side updates have landed. Flutter runner in topaz needs to be patched on next roll.

Looks like it works!