python312Packages.anthropic: 0.34.0 -> 0.34.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python312Packages.anthropic is: Anthropic's safety-first language model APIs
meta.homepage for python312Packages.anthropic is: https://github.com/anthropics/anthropic-sdk-python
meta.changelog for python312Packages.anthropic is: https://github.com/anthropics/anthropic-sdk-python/releases/tag/v0.34.1
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.34.1 with grep in /nix/store/23hzjy9mzqxbqm23a8pzpv3kdwgp8zji-python3.12-anthropic-0.34.1
found 0.34.1 in filename of file in /nix/store/23hzjy9mzqxbqm23a8pzpv3kdwgp8zji-python3.12-anthropic-0.34.1

Rebuild report (if merged into master) (click to expand)

41 total rebuild path(s)

41 package rebuild(s)

First fifty rebuilds by attrpath

khoj
open-webui
pentestgpt
python311Packages.anthropic
python311Packages.instructor
python311Packages.langchain
python311Packages.langchain-aws
python311Packages.langchain-azure-dynamic-sessions
python311Packages.langchain-chroma
python311Packages.langchain-community
python311Packages.langchain-core
python311Packages.langchain-huggingface
python311Packages.langchain-mongodb
python311Packages.langchain-openai
python311Packages.langchain-standard-tests
python311Packages.langchain-text-splitters
python311Packages.langgraph
python311Packages.langgraph-checkpoint
python311Packages.langgraph-checkpoint-postgres
python311Packages.langgraph-checkpoint-sqlite
python311Packages.langsmith
python312Packages.anthropic
python312Packages.instructor
python312Packages.langchain
python312Packages.langchain-aws
python312Packages.langchain-azure-dynamic-sessions
python312Packages.langchain-chroma
python312Packages.langchain-community
python312Packages.langchain-core
python312Packages.langchain-huggingface
python312Packages.langchain-mongodb
python312Packages.langchain-openai
python312Packages.langchain-standard-tests
python312Packages.langchain-text-splitters
python312Packages.langgraph
python312Packages.langgraph-checkpoint
python312Packages.langgraph-checkpoint-postgres
python312Packages.langgraph-checkpoint-sqlite
python312Packages.langsmith
shell-gpt

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/23hzjy9mzqxbqm23a8pzpv3kdwgp8zji-python3.12-anthropic-0.34.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python312Packages.anthropic https://github.com/r-ryantm/nixpkgs/archive/b03ba719142b1b92139ea1e2a6ba6053afdd99ff.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/b03ba719142b1b92139ea1e2a6ba6053afdd99ff#python312Packages.anthropic

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/23hzjy9mzqxbqm23a8pzpv3kdwgp8zji-python3.12-anthropic-0.34.1
ls -la /nix/store/23hzjy9mzqxbqm23a8pzpv3kdwgp8zji-python3.12-anthropic-0.34.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages marked as broken and skipped:

khoj
khoj.dist

38 packages failed to build:

open-webui
open-webui.dist
pentestgpt
pentestgpt.dist
python311Packages.langgraph
python311Packages.langgraph-checkpoint-postgres
python311Packages.langgraph-checkpoint-postgres.dist
python311Packages.langgraph.dist
python312Packages.langchain
python312Packages.langchain-aws
python312Packages.langchain-aws.dist
python312Packages.langchain-azure-dynamic-sessions
python312Packages.langchain-azure-dynamic-sessions.dist
python312Packages.langchain-chroma
python312Packages.langchain-chroma.dist
python312Packages.langchain-community
python312Packages.langchain-community.dist
python312Packages.langchain-core
python312Packages.langchain-core.dist
python312Packages.langchain-huggingface
python312Packages.langchain-huggingface.dist
python312Packages.langchain-mongodb
python312Packages.langchain-mongodb.dist
python312Packages.langchain-openai
python312Packages.langchain-openai.dist
python312Packages.langchain-standard-tests
python312Packages.langchain-standard-tests.dist
python312Packages.langchain-text-splitters
python312Packages.langchain-text-splitters.dist
python312Packages.langchain.dist
python312Packages.langgraph
python312Packages.langgraph-checkpoint
python312Packages.langgraph-checkpoint-postgres
python312Packages.langgraph-checkpoint-postgres.dist
python312Packages.langgraph-checkpoint-sqlite
python312Packages.langgraph-checkpoint-sqlite.dist
python312Packages.langgraph-checkpoint.dist
python312Packages.langgraph.dist

40 packages built:

python311Packages.anthropic
python311Packages.anthropic.dist
python311Packages.instructor
python311Packages.instructor.dist
python311Packages.langchain
python311Packages.langchain-aws
python311Packages.langchain-aws.dist
python311Packages.langchain-azure-dynamic-sessions
python311Packages.langchain-azure-dynamic-sessions.dist
python311Packages.langchain-chroma
python311Packages.langchain-chroma.dist
python311Packages.langchain-community
python311Packages.langchain-community.dist
python311Packages.langchain-core
python311Packages.langchain-core.dist
python311Packages.langchain-huggingface
python311Packages.langchain-huggingface.dist
python311Packages.langchain-mongodb
python311Packages.langchain-mongodb.dist
python311Packages.langchain-openai
python311Packages.langchain-openai.dist
python311Packages.langchain-standard-tests
python311Packages.langchain-standard-tests.dist
python311Packages.langchain-text-splitters
python311Packages.langchain-text-splitters.dist
python311Packages.langchain.dist
python311Packages.langgraph-checkpoint
python311Packages.langgraph-checkpoint-sqlite
python311Packages.langgraph-checkpoint-sqlite.dist
python311Packages.langgraph-checkpoint.dist
python311Packages.langsmith
python311Packages.langsmith.dist
python312Packages.anthropic
python312Packages.anthropic.dist
python312Packages.instructor
python312Packages.instructor.dist
python312Packages.langsmith
python312Packages.langsmith.dist
shell-gpt
shell-gpt.dist

Maintainer pings
cc @natsukium for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

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

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python312Packages.anthropic is: Anthropic's safety-first language model APIs
meta.homepage for python312Packages.anthropic is: https://github.com/anthropics/anthropic-sdk-python
meta.changelog for python312Packages.anthropic is: https://github.com/anthropics/anthropic-sdk-python/releases/tag/v0.34.2
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.34.2 with grep in /nix/store/9vyayn2nb05pm3giy27bnk77d9pkm0gn-python3.12-anthropic-0.34.2
found 0.34.2 in filename of file in /nix/store/9vyayn2nb05pm3giy27bnk77d9pkm0gn-python3.12-anthropic-0.34.2

Rebuild report (if merged into master) (click to expand)

42 total rebuild path(s)

42 package rebuild(s)

First fifty rebuilds by attrpath

home-assistant-component-tests.anthropic
khoj
open-webui
pentestgpt
python311Packages.anthropic
python311Packages.instructor
python311Packages.langchain
python311Packages.langchain-aws
python311Packages.langchain-azure-dynamic-sessions
python311Packages.langchain-chroma
python311Packages.langchain-community
python311Packages.langchain-core
python311Packages.langchain-huggingface
python311Packages.langchain-mongodb
python311Packages.langchain-openai
python311Packages.langchain-standard-tests
python311Packages.langchain-text-splitters
python311Packages.langgraph
python311Packages.langgraph-checkpoint
python311Packages.langgraph-checkpoint-postgres
python311Packages.langgraph-checkpoint-sqlite
python311Packages.langsmith
python312Packages.anthropic
python312Packages.instructor
python312Packages.langchain
python312Packages.langchain-aws
python312Packages.langchain-azure-dynamic-sessions
python312Packages.langchain-chroma
python312Packages.langchain-community
python312Packages.langchain-core
python312Packages.langchain-huggingface
python312Packages.langchain-mongodb
python312Packages.langchain-openai
python312Packages.langchain-standard-tests
python312Packages.langchain-text-splitters
python312Packages.langgraph
python312Packages.langgraph-checkpoint
python312Packages.langgraph-checkpoint-postgres
python312Packages.langgraph-checkpoint-sqlite
python312Packages.langsmith
shell-gpt

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/9vyayn2nb05pm3giy27bnk77d9pkm0gn-python3.12-anthropic-0.34.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python312Packages.anthropic https://github.com/r-ryantm/nixpkgs/archive/3a58705b09184cd410a1daa851f6f4b7919fc808.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/3a58705b09184cd410a1daa851f6f4b7919fc808#python312Packages.anthropic

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/9vyayn2nb05pm3giy27bnk77d9pkm0gn-python3.12-anthropic-0.34.2
ls -la /nix/store/9vyayn2nb05pm3giy27bnk77d9pkm0gn-python3.12-anthropic-0.34.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages marked as broken and skipped:

khoj
khoj.dist

30 packages failed to build:

python311Packages.langchain
python311Packages.langchain-aws
python311Packages.langchain-aws.dist
python311Packages.langchain-azure-dynamic-sessions
python311Packages.langchain-azure-dynamic-sessions.dist
python311Packages.langchain-chroma
python311Packages.langchain-chroma.dist
python311Packages.langchain-community
python311Packages.langchain-community.dist
python311Packages.langchain-core
python311Packages.langchain-core.dist
python311Packages.langchain-huggingface
python311Packages.langchain-huggingface.dist
python311Packages.langchain-mongodb
python311Packages.langchain-mongodb.dist
python311Packages.langchain-openai
python311Packages.langchain-openai.dist
python311Packages.langchain-standard-tests
python311Packages.langchain-standard-tests.dist
python311Packages.langchain-text-splitters
python311Packages.langchain-text-splitters.dist
python311Packages.langchain.dist
python311Packages.langgraph
python311Packages.langgraph-checkpoint
python311Packages.langgraph-checkpoint-postgres
python311Packages.langgraph-checkpoint-postgres.dist
python311Packages.langgraph-checkpoint-sqlite
python311Packages.langgraph-checkpoint-sqlite.dist
python311Packages.langgraph-checkpoint.dist
python311Packages.langgraph.dist

49 packages built:

home-assistant-component-tests.anthropic
open-webui
open-webui.dist
pentestgpt
pentestgpt.dist
python311Packages.anthropic
python311Packages.anthropic.dist
python311Packages.instructor
python311Packages.instructor.dist
python311Packages.langsmith
python311Packages.langsmith.dist
python312Packages.anthropic
python312Packages.anthropic.dist
python312Packages.instructor
python312Packages.instructor.dist
python312Packages.langchain
python312Packages.langchain-aws
python312Packages.langchain-aws.dist
python312Packages.langchain-azure-dynamic-sessions
python312Packages.langchain-azure-dynamic-sessions.dist
python312Packages.langchain-chroma
python312Packages.langchain-chroma.dist
python312Packages.langchain-community
python312Packages.langchain-community.dist
python312Packages.langchain-core
python312Packages.langchain-core.dist
python312Packages.langchain-huggingface
python312Packages.langchain-huggingface.dist
python312Packages.langchain-mongodb
python312Packages.langchain-mongodb.dist
python312Packages.langchain-openai
python312Packages.langchain-openai.dist
python312Packages.langchain-standard-tests
python312Packages.langchain-standard-tests.dist
python312Packages.langchain-text-splitters
python312Packages.langchain-text-splitters.dist
python312Packages.langchain.dist
python312Packages.langgraph
python312Packages.langgraph-checkpoint
python312Packages.langgraph-checkpoint-postgres
python312Packages.langgraph-checkpoint-postgres.dist
python312Packages.langgraph-checkpoint-sqlite
python312Packages.langgraph-checkpoint-sqlite.dist
python312Packages.langgraph-checkpoint.dist
python312Packages.langgraph.dist
python312Packages.langsmith
python312Packages.langsmith.dist
shell-gpt
shell-gpt.dist

Maintainer pings
cc @natsukium for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

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

Result of nixpkgs-review pr 337240 run on x86_64-linux 1

2 packages marked as broken and skipped:

khoj
khoj.dist

79 packages built:

home-assistant-component-tests.anthropic
open-webui
open-webui.dist
pentestgpt
pentestgpt.dist
python311Packages.anthropic
python311Packages.anthropic.dist
python311Packages.instructor
python311Packages.instructor.dist
python311Packages.langchain
python311Packages.langchain-aws
python311Packages.langchain-aws.dist
python311Packages.langchain-azure-dynamic-sessions
python311Packages.langchain-azure-dynamic-sessions.dist
python311Packages.langchain-chroma
python311Packages.langchain-chroma.dist
python311Packages.langchain-community
python311Packages.langchain-community.dist
python311Packages.langchain-core
python311Packages.langchain-core.dist
python311Packages.langchain-huggingface
python311Packages.langchain-huggingface.dist
python311Packages.langchain-mongodb
python311Packages.langchain-mongodb.dist
python311Packages.langchain-openai
python311Packages.langchain-openai.dist
python311Packages.langchain-standard-tests
python311Packages.langchain-standard-tests.dist
python311Packages.langchain-text-splitters
python311Packages.langchain-text-splitters.dist
python311Packages.langchain.dist
python311Packages.langgraph
python311Packages.langgraph-checkpoint
python311Packages.langgraph-checkpoint-postgres
python311Packages.langgraph-checkpoint-postgres.dist
python311Packages.langgraph-checkpoint-sqlite
python311Packages.langgraph-checkpoint-sqlite.dist
python311Packages.langgraph-checkpoint.dist
python311Packages.langgraph.dist
python311Packages.langsmith
python311Packages.langsmith.dist
python312Packages.anthropic
python312Packages.anthropic.dist
python312Packages.instructor
python312Packages.instructor.dist
python312Packages.langchain
python312Packages.langchain-aws
python312Packages.langchain-aws.dist
python312Packages.langchain-azure-dynamic-sessions
python312Packages.langchain-azure-dynamic-sessions.dist
python312Packages.langchain-chroma
python312Packages.langchain-chroma.dist
python312Packages.langchain-community
python312Packages.langchain-community.dist
python312Packages.langchain-core
python312Packages.langchain-core.dist
python312Packages.langchain-huggingface
python312Packages.langchain-huggingface.dist
python312Packages.langchain-mongodb
python312Packages.langchain-mongodb.dist
python312Packages.langchain-openai
python312Packages.langchain-openai.dist
python312Packages.langchain-standard-tests
python312Packages.langchain-standard-tests.dist
python312Packages.langchain-text-splitters
python312Packages.langchain-text-splitters.dist
python312Packages.langchain.dist
python312Packages.langgraph
python312Packages.langgraph-checkpoint
python312Packages.langgraph-checkpoint-postgres
python312Packages.langgraph-checkpoint-postgres.dist
python312Packages.langgraph-checkpoint-sqlite
python312Packages.langgraph-checkpoint-sqlite.dist
python312Packages.langgraph-checkpoint.dist
python312Packages.langgraph.dist
python312Packages.langsmith
python312Packages.langsmith.dist
shell-gpt
shell-gpt.dist

Result of nixpkgs-review pr 337240 run on aarch64-darwin 1

4 packages marked as broken and skipped:

khoj
khoj.dist
open-webui
open-webui.dist

76 packages built:

pentestgpt
pentestgpt.dist
python311Packages.anthropic
python311Packages.anthropic.dist
python311Packages.instructor
python311Packages.instructor.dist
python311Packages.langchain
python311Packages.langchain-aws
python311Packages.langchain-aws.dist
python311Packages.langchain-azure-dynamic-sessions
python311Packages.langchain-azure-dynamic-sessions.dist
python311Packages.langchain-chroma
python311Packages.langchain-chroma.dist
python311Packages.langchain-community
python311Packages.langchain-community.dist
python311Packages.langchain-core
python311Packages.langchain-core.dist
python311Packages.langchain-huggingface
python311Packages.langchain-huggingface.dist
python311Packages.langchain-mongodb
python311Packages.langchain-mongodb.dist
python311Packages.langchain-openai
python311Packages.langchain-openai.dist
python311Packages.langchain-standard-tests
python311Packages.langchain-standard-tests.dist
python311Packages.langchain-text-splitters
python311Packages.langchain-text-splitters.dist
python311Packages.langchain.dist
python311Packages.langgraph
python311Packages.langgraph-checkpoint
python311Packages.langgraph-checkpoint-postgres
python311Packages.langgraph-checkpoint-postgres.dist
python311Packages.langgraph-checkpoint-sqlite
python311Packages.langgraph-checkpoint-sqlite.dist
python311Packages.langgraph-checkpoint.dist
python311Packages.langgraph.dist
python311Packages.langsmith
python311Packages.langsmith.dist
python312Packages.anthropic
python312Packages.anthropic.dist
python312Packages.instructor
python312Packages.instructor.dist
python312Packages.langchain
python312Packages.langchain-aws
python312Packages.langchain-aws.dist
python312Packages.langchain-azure-dynamic-sessions
python312Packages.langchain-azure-dynamic-sessions.dist
python312Packages.langchain-chroma
python312Packages.langchain-chroma.dist
python312Packages.langchain-community
python312Packages.langchain-community.dist
python312Packages.langchain-core
python312Packages.langchain-core.dist
python312Packages.langchain-huggingface
python312Packages.langchain-huggingface.dist
python312Packages.langchain-mongodb
python312Packages.langchain-mongodb.dist
python312Packages.langchain-openai
python312Packages.langchain-openai.dist
python312Packages.langchain-standard-tests
python312Packages.langchain-standard-tests.dist
python312Packages.langchain-text-splitters
python312Packages.langchain-text-splitters.dist
python312Packages.langchain.dist
python312Packages.langgraph
python312Packages.langgraph-checkpoint
python312Packages.langgraph-checkpoint-postgres
python312Packages.langgraph-checkpoint-postgres.dist
python312Packages.langgraph-checkpoint-sqlite
python312Packages.langgraph-checkpoint-sqlite.dist
python312Packages.langgraph-checkpoint.dist
python312Packages.langgraph.dist
python312Packages.langsmith
python312Packages.langsmith.dist
shell-gpt
shell-gpt.dist

thank you for your checking


Disable base/max size generation doesn't work

Describe the bug
I can't inpaint with the disable base/max size option checked at all, it seems. Neither with a selection nor with no selection.
I could have expected it to not work because of me painting in a high resolution, but even with a 512x512 area selected it's not managing to produce anything but this error.
Desktop (please complete the following information):

OS: Linux
WebUI commit revision 2c1bb46c7ad5b4536f6587d327a03f0ff7811c5d
Extension commit revision 4b8e719c95a08815efb508cbb617d0fd92c29640

Additional context
`ERROR:    Exception in ASGI application
Traceback (most recent call last):
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/anyio/streams/memory.py", line 94, in receive
return self.receive_nowait()
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/anyio/streams/memory.py", line 89, in receive_nowait
raise WouldBlock
anyio.WouldBlock
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/starlette/middleware/base.py", line 77, in call_next
message = await recv_stream.receive()
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/anyio/streams/memory.py", line 114, in receive
raise EndOfStream
anyio.EndOfStream
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/uvicorn/protocols/http/h11_impl.py", line 407, in run_asgi
result = await app(  # type: ignore[func-returns-value]
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/uvicorn/middleware/proxy_headers.py", line 78, in call
return await self.app(scope, receive, send)
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/fastapi/applications.py", line 270, in call
await super().call(scope, receive, send)
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/starlette/applications.py", line 124, in call
await self.middleware_stack(scope, receive, send)
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/starlette/middleware/errors.py", line 184, in call
raise exc
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/starlette/middleware/errors.py", line 162, in call
await self.app(scope, receive, _send)
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/starlette/middleware/base.py", line 106, in call
response = await self.dispatch_func(request, call_next)
File "stable-diffusion-webui/extensions/auto-sd-paint-ext/backend/app.py", line 394, in app_encryption_middleware
res: StreamingResponse = await call_next(req)
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/starlette/middleware/base.py", line 80, in call_next
raise app_exc
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/starlette/middleware/base.py", line 69, in coro
await self.app(scope, receive_or_disconnect, send_no_error)
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/starlette/middleware/base.py", line 106, in call
response = await self.dispatch_func(request, call_next)
File "stable-diffusion-webui/modules/api/api.py", line 96, in log_and_time
res: Response = await call_next(req)
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/starlette/middleware/base.py", line 80, in call_next
raise app_exc
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/starlette/middleware/base.py", line 69, in coro
await self.app(scope, receive_or_disconnect, send_no_error)
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/starlette/middleware/gzip.py", line 26, in call
await self.app(scope, receive, send)
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/starlette/middleware/exceptions.py", line 79, in call
raise exc
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/starlette/middleware/exceptions.py", line 68, in call
await self.app(scope, receive, sender)
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/fastapi/middleware/asyncexitstack.py", line 21, in call
raise e
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/fastapi/middleware/asyncexitstack.py", line 18, in call
await self.app(scope, receive, send)
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/starlette/routing.py", line 706, in call
await route.handle(scope, receive, send)
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/starlette/routing.py", line 276, in handle
await self.app(scope, receive, send)
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/starlette/routing.py", line 66, in app
response = await func(request)
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/fastapi/routing.py", line 237, in app
raw_response = await run_endpoint_function(
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/fastapi/routing.py", line 165, in run_endpoint_function
return await run_in_threadpool(dependant.call, **values)
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/starlette/concurrency.py", line 41, in run_in_threadpool
return await anyio.to_thread.run_sync(func, *args)
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/anyio/to_thread.py", line 31, in run_sync
return await get_asynclib().run_sync_in_worker_thread(
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/anyio/_backends/_asyncio.py", line 937, in run_sync_in_worker_thread
return await future
File "stable-diffusion-webui/venv/lib/python3.10/site-packages/anyio/_backends/_asyncio.py", line 867, in run
result = context.run(func, *args)
File "stable-diffusion-webui/extensions/auto-sd-paint-ext/backend/app.py", line 225, in f_img2img
width, height = sddebz_highres_fix(
File "stable-diffusion-webui/extensions/auto-sd-paint-ext/backend/utils.py", line 209, in sddebz_highres_fix
width, height = ceil(width / 64) * 64, ceil(height / 64) * 64
UnboundLocalError: local variable 'width' referenced before assignment`

Surprising you didnt run into this earlier considering the fact it was just straight up wrong... When I wrote it, I only tested toggling the thing on & off work, didn't actually try generating anything...


REDI: CustomDependancies

I've ran through all files in dota, and there aren't any custom dependancies.

REDI was deprecated 4 years ago, and we never ran into a file that has it.


Examples\SQL+FillColumns+Pivot\Example.ps1

https://github.com/dfinke/ImportExcel/blob/master/Examples/SQL%2BFillColumns%2BPivot/Example.ps1
Exception calling "Fill" with "1" argument(s): "ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default
driver specified"
At C:\GitHub\ImportExcel\Send-SQLDataToExcel.ps1:122 char:5

Like the other example  in Send-SQLDataToExcel this doesn't work well in a test environment, it relies on a hard code ODBC DSN named "LR" with a SQLLite driver going through to an adobe lightroom catalog database.


Explore workflow editor to create workflows for atleast one integration

The workflow editor of Alloy product has been explored.
Pros

It provides feature to merge multiple datasources
It provides multiple utility functions
Cons
It doesn't return any response to workflow call other than just an acknowledgement.


CMakefile.txt macro issues

if (WIN32)
set(LEVELDB_PLATFORM_NAME LEVELDB_PLATFORM_WINDOWS)
add_definitions(-D_UNICODE -DUNICODE)
else (WIN32)
set(LEVELDB_PLATFORM_NAME LEVELDB_PLATFORM_POSIX)
endif (WIN32)
if (WIN32)
target_sources(leveldb
PRIVATE
"util/env_windows.cc"
"util/windows_logger.h"
)
else (WIN32)
target_sources(leveldb
PRIVATE
"util/env_posix.cc"
"util/posix_logger.h"
)
endif (WIN32)
Very confuse about above script. Is it correct?
I think we need win32 & unix condition

The expressions next to else and endif are optional, and repeat the if condition. https://cmake.org/cmake/help/latest/command/if.html


tst_nccopy4 failing

I'm looking to update both hdf5 to 1.10.7 and netcdf to 4.7.4 in Fedora rawhide.  I'm getting the following test failure with that combo:
$ cat tst_nccopy4.log

*** Testing compound types some more.
*** creating another compound test file tst_comp2.nc...ok.
*** Tests successful!

*** Testing netCDF-4 features of nccopy on ncdump/*.nc files
*** Test nccopy tst_comp.nc copy_of_tst_comp.nc ...
*** Test nccopy tst_comp2.nc copy_of_tst_comp2.nc ...
*** Test nccopy tst_enum_data.nc copy_of_tst_enum_data.nc ...
*** Test nccopy tst_fillbug.nc copy_of_tst_fillbug.nc ...
*** Test nccopy tst_group_data.nc copy_of_tst_group_data.nc ...
*** Test nccopy tst_nans.nc copy_of_tst_nans.nc ...
*** Test nccopy tst_opaque_data.nc copy_of_tst_opaque_data.nc ...
*** Test nccopy tst_solar_1.nc copy_of_tst_solar_1.nc ...
*** Test nccopy tst_solar_2.nc copy_of_tst_solar_2.nc ...
*** Test nccopy tst_solar_cmp.nc copy_of_tst_solar_cmp.nc ...
*** Test nccopy tst_special_atts.nc copy_of_tst_special_atts.nc ...
*** Test nccopy tst_string_data.nc copy_of_tst_string_data.nc ...
*** Test nccopy tst_unicode.nc copy_of_tst_unicode.nc ...
*** Creating compressible test files tst_inflated.nc, tst_inflated4.nc...ok.
*** Tests successful!
*** Test nccopy -d1 can compress a classic format file ...
*** Test nccopy -d1 can compress a netCDF-4 format file ...
*** Test nccopy -d1 -s can compress a classic model netCDF-4 file even more ...
*** Test nccopy -d1 -s can compress a netCDF-4 file even more ...
*** Test nccopy -d0 turns off compression, shuffling of compressed, shuffled file ...
*** Testing nccopy -d1 -s on ncdump/*.nc files
*** Test nccopy -d1 -s tst_comp.nc copy_of_tst_comp.nc ...
*** Test nccopy -d1 -s tst_comp2.nc copy_of_tst_comp2.nc ...
*** Test nccopy -d1 -s tst_enum_data.nc copy_of_tst_enum_data.nc ...
*** Test nccopy -d1 -s tst_fillbug.nc copy_of_tst_fillbug.nc ...
*** Test nccopy -d1 -s tst_group_data.nc copy_of_tst_group_data.nc ...
*** Test nccopy -d1 -s tst_nans.nc copy_of_tst_nans.nc ...
*** Test nccopy -d1 -s tst_opaque_data.nc copy_of_tst_opaque_data.nc ...
*** Test nccopy -d1 -s tst_solar_1.nc copy_of_tst_solar_1.nc ...
*** Test nccopy -d1 -s tst_solar_2.nc copy_of_tst_solar_2.nc ...
*** Test nccopy -d1 -s tst_solar_cmp.nc copy_of_tst_solar_cmp.nc ...
*** Test nccopy -d1 -s tst_special_atts.nc copy_of_tst_special_atts.nc ...
*** Test nccopy -d1 -s tst_string_data.nc copy_of_tst_string_data.nc ...
NetCDF: HDF error
Location: file ../../ncdump/ncdump.c; line 1732
FAIL tst_nccopy4.sh (exit status: 1)

Not sure where to go from here.

I get the same error trying to rebuild the current netcdf 4.7.3 package with hdf5 1.10.7, so it appears to be a change in hdf5 that is triggering it.

Do all of the tests in nc_test4 pass?

Full build log is here: https://download.copr.fedorainfracloud.org/results/orion/hdf5-1.10.7/fedora-rawhide-x86_64/01701010-netcdf/build.log.gz
Looks like the tests fail before it gets to those tests?

Right! If you build with --disable-utilities, or just make check in the nc_test4 directory, that will run those tests.
The nc_test4 tests test the netcdf-c library for netCDF-4 functionality. If one of those tests fails, it is far easier to find and debug the problem, than it is working with a utilities test failure.
Furthermore, a failure in the utilities would clearly be the problem of @DennisHeimbigner but a problem in nc_test4 is much more likely in my code. ;-)

Ok, so lets try to get some more information.
I assume that you are running under *nix of some sort.
So after you run the build and it fails.

enter the directory ncdump
execute the command 'sh -x ./tst_nccopy4.sh'
and post the output.
It should show exactly what command is failing and with what arguments.

Interesting; in a separate issue yesterday I was working with the hdf5 1.10.7 installed via conda, and observed no issues.  I'll try a custom build in my linux VM and see what I observe.

I think this is what you're looking for:
+ echo '*** Test nccopy -d1 -s tst_string_data.nc copy_of_tst_string_data.nc ...'
*** Test nccopy -d1 -s tst_string_data.nc copy_of_tst_string_data.nc ...
+ /home/orion/fedora/netcdf/netcdf-c-4.7.4/build/ncdump/nccopy -d1 -s tst_string_data.nc copy_of_tst_string_data.nc
+ /home/orion/fedora/netcdf/netcdf-c-4.7.4/build/ncdump/ncdump -n copy_of_tst_string_data tst_string_data.nc
+ /home/orion/fedora/netcdf/netcdf-c-4.7.4/build/ncdump/ncdump copy_of_tst_string_data.nc
NetCDF: HDF error
Location: file ../../ncdump/ncdump.c; line 1732

Ok, now try this to get more more info about the HDF error.

export NETCDF_LOG_LEVEL=0
then run that test again.
This may not work if you did not enable logging when building netcdf-c.

So, this is fun.  With --enable-logging I got a build failure which I fixed by applying commit b0e0d81aa922a41d39600291ef4296716edd2ebb.  Compiled and ran tests with export NETCDF_LOG_LEVEL=0 and voila - no more test failure.
So I disabled enable-logging again but kept the patch and the error returned.
I also tried building the latest master but got a build failure that I reported elsewhere.

What the XXX is going on? Setting NETCDF_LOG_LEVEL=0 enables HDF5 detailed
error reporting. That code has not AFAIK changed in a long time.
The only thing I can think of at this point is to run with NETCDF_LOG_LEVEL=5
and see if the error still disappears.
Level 5 provides voluminous tracing of the netcdf and it would help narrow down
where the error occurs. But I am not hopeful because level 5 => level 0 also.
Otherwise, I got nothing.

Perhaps some of this helps:
ncdump output:
netcdf copy_of_tst_string_data {
dimensions:
        line = 5 ;
variables:
NetCDF: HDF error

gdb:
(gdb) bt
#0  nc_strerror (ncerr1=<optimized out>) at ../libdispatch/../../libdispatch/derror.c:202
#1  nc_strerror (ncerr1=<optimized out>) at ../libdispatch/../../libdispatch/derror.c:86
#2  0x0000555555559591 in check (err=<optimized out>, file=0x5555555632b8 "../../ncdump/ncdump.c", line=1732) at ../../ncdump/utils.c:84
#3  0x0000555555560cb2 in do_ncdump_rec (ncid=65536, path=<optimized out>) at ../../ncdump/ncdump.c:1732
#4  0x00005555555584c4 in do_ncdump (path=0x555555569b40 "copy_of_tst_string_data.nc", ncid=65536) at ../../ncdump/indent.c:15
#5  main (argc=<optimized out>, argv=<optimized out>) at ../../ncdump/ncdump.c:2416
(gdb) up
#3  0x0000555555560cb2 in do_ncdump_rec (ncid=65536, path=<optimized out>) at ../../ncdump/ncdump.c:1732
1732          NC_CHECK( nc_inq_varndims(ncid, varid, &var.ndims) );
(gdb) list
1727       memset((void*)&var,0,sizeof(var));
1728
1729       /* For each var, get and print out info. */
1730
1731       for (varid = 0; varid < nvars; varid++) {
1732          NC_CHECK( nc_inq_varndims(ncid, varid, &var.ndims) );
1733          if(var.dims != NULL) free(var.dims);
1734          var.dims = (int *) emalloc((var.ndims + 1) * sizeof(int));
1735          NC_CHECK( nc_inq_var(ncid, varid, var.name, &var.type, 0,
1736                               var.dims, &var.natts) );
(gdb) print var
$1 = {name = '\000' <repeats 255 times>, type = 0, tinfo = 0x0, ndims = 0, dims = 0x0, natts = 0, has_fillval = 0, fillvalp = 0x0, has_timeval = 0, timeinfo = 0x0, is_bnds_var = 0, fmt = 0x0, locid = 0, val_tostring = 0x0}
(gdb) print varid
$2 = 0
(gdb) print nvars
$3 = 1

h5dump output:
$ h5dump copy_of_tst_string_data.nc
HDF5 "copy_of_tst_string_data.nc" {
GROUP "/" {
   ATTRIBUTE "_NCProperties" {
      DATATYPE  H5T_STRING {
         STRSIZE 35;
         STRPAD H5T_STR_NULLTERM;
         CSET H5T_CSET_ASCII;
         CTYPE H5T_C_S1;
      }
      DATASPACE  SCALAR
      DATA {
      (0): "version=2,netcdf=4.7.4,hdf5=1.10.7,"
      }
   }
   DATASET "description" {
      DATATYPE  H5T_STRING {
         STRSIZE H5T_VARIABLE;
         STRPAD H5T_STR_NULLTERM;
         CSET H5T_CSET_UTF8;
         CTYPE H5T_C_S1;
      }
      DATASPACE  SIMPLE { ( 5 ) / ( 5 ) }
      DATA {
      (0): "first string", "second string", "third string", "",
      (4): "last
           "string""
      }
      ATTRIBUTE "DIMENSION_LIST" {
         DATATYPE  H5T_VLEN { H5T_REFERENCE { H5T_STD_REF_OBJECT }}
         DATASPACE  SIMPLE { ( 1 ) / ( 1 ) }
         DATA {
         (0): (DATASET 331 "/line")
         }
      }
      ATTRIBUTE "_FillValue" {
         DATATYPE  H5T_STRING {
            STRSIZE H5T_VARIABLE;
            STRPAD H5T_STR_NULLTERM;
            CSET H5T_CSET_UTF8;
            CTYPE H5T_C_S1;
         }
         DATASPACE  SIMPLE { ( 1 ) / ( 1 ) }
         DATA {
         (0): ""
         }
      }
   }
   DATASET "line" {
      DATATYPE  H5T_IEEE_F32BE
      DATASPACE  SIMPLE { ( 5 ) / ( 5 ) }
      DATA {
      (0): 0, 0, 0, 0, 0
      }
      ATTRIBUTE "CLASS" {
         DATATYPE  H5T_STRING {
            STRSIZE 16;
            STRPAD H5T_STR_NULLTERM;
            CSET H5T_CSET_ASCII;
            CTYPE H5T_C_S1;
         }
         DATASPACE  SCALAR
         DATA {
         (0): "DIMENSION_SCALE"
         }
      }
      ATTRIBUTE "NAME" {
         DATATYPE  H5T_STRING {
            STRSIZE 64;
            STRPAD H5T_STR_NULLTERM;
            CSET H5T_CSET_ASCII;
            CTYPE H5T_C_S1;
         }
         DATASPACE  SCALAR
         DATA {
         (0): "This is a netCDF dimension but not a netCDF variable.         5"
         }
      }
      ATTRIBUTE "REFERENCE_LIST" {
         DATATYPE  H5T_COMPOUND {
            H5T_REFERENCE { H5T_STD_REF_OBJECT } "dataset";
            H5T_STD_I32LE "dimension";
         }
         DATASPACE  SIMPLE { ( 1 ) / ( 1 ) }
         DATA {
         (0): {
               DATASET 685 "/description",
               0
            }
         }
      }
      ATTRIBUTE "_Netcdf4Dimid" {
         DATATYPE  H5T_STD_I32LE
         DATASPACE  SCALAR
         DATA {
         (0): 0
         }
      }
   }
}
}

h5dump output of tst_string_data.nc is the same, though the files are not identical in size.
valgrind output:
==17532== Command: /home/orion/fedora/netcdf/netcdf-c-4.7.4/build/ncdump/.libs/ncdump copy_of_tst_string_data.nc
==17532==
netcdf copy_of_tst_string_data {
dimensions:
        line = 5 ;
variables:
==17532== Conditional jump or move depends on uninitialised value(s)
==17532==    at 0x48BC5E7: UnknownInlinedFun (hdf5open.c:962)
==17532==    by 0x48BC5E7: nc4_get_var_meta (hdf5open.c:1289)
==17532==    by 0x48BD70F: nc4_hdf5_find_grp_var_att (hdf5internal.c:911)
==17532==    by 0x48BDC61: NC4_HDF5_inq_var_all (hdf5var.c:2210)
==17532==    by 0x4876D42: nc_inq_var (dvarinq.c:131)
==17532==    by 0x4876E64: nc_inq_varndims (dvarinq.c:204)
==17532==    by 0x1144D8: do_ncdump_rec.constprop.0 (ncdump.c:1732)
==17532==    by 0x10C4C3: UnknownInlinedFun (ncdump.c:1978)
==17532==    by 0x10C4C3: main (ncdump.c:2416)
==17532==
        string description(line) ;
                string description:_FillValue = "" ;
data:

 description = "first string", "second string", "third string", _,
    "last \n\"string\"" ;
}

The UnknownInlinedFun seems to be:
get_filter_info (var=0x5555555e2b00, propid=720575940379279384) at ../libhdf5/../../libhdf5/hdf5open.c:1289
1289        if ((retval = get_filter_info(propid, var)))
(gdb)
943         if ((num_filters = H5Pget_nfilters(propid)) < 0)
(gdb) n
946         for (f = 0; f < num_filters; f++)
(gdb)
948             if ((filter = H5Pget_filter2(propid, f, NULL, &cd_nelems, cd_values_zip,
(gdb)
951             switch (filter)
(gdb)
954                 var->shuffle = NC_TRUE;
(gdb)
955                 break;
(gdb)
946         for (f = 0; f < num_filters; f++)
(gdb)
948             if ((filter = H5Pget_filter2(propid, f, NULL, &cd_nelems, cd_values_zip,
(gdb) print num_filters
$4 = 2
(gdb) n
951             switch (filter)
(gdb)
962                 if (cd_nelems != CD_NELEMS_ZLIB ||
(gdb) list
957             case H5Z_FILTER_FLETCHER32:
958                 var->fletcher32 = NC_TRUE;
959                 break;
960
961             case H5Z_FILTER_DEFLATE:
962                 if (cd_nelems != CD_NELEMS_ZLIB ||
963                     cd_values_zip[0] > NC_MAX_DEFLATE_LEVEL)
964                     return NC_EHDFERR;
965                 if((stat = NC4_hdf5_addfilter(var,FILTERACTIVE,filter,cd_nelems,cd_values_zip)))
966                     return stat;
(gdb) print cd_nelems
$5 = 1
(gdb) print cd_values_zip
$6 = {21845}

I'm guessing it's this cd_values_zip that isn't being initialized.

You  might try rebuilding netcdf-c with optimization turned off: -g -O0.

Looks like this is fixed in current netcdf master, or at least the test passes and I don't see any valgrind output.

Another note to add to this is that, at least in my case, downgrading HDF5 to 1.10.6 also solves this issue when using the NetCDF 4.7.4 release version.

Another note to add to this is that, at least in my case, downgrading HDF5 to 1.10.6 also solves this issue when using the NetCDF 4.7.4 release version.

This issue reappeared for me on NixOS, with netCDF 4.7.4 and hdf5 1.12.1, on Linux aarch64 only:
https://github.com/NixOS/nixpkgs/issues/115788#issuecomment-900491175
NetCDF: HDF error
Location: file ncdump.c; line 1732
FAIL tst_nccopy4.sh (exit status: 1)

(full build log).

For others facing the same problem, trying to upgrade to netCDF 4.8.0, I get this test failure instead: #1971


Add dark/light mode switch

Before opening the issue, have you...?

[X] Searched for existing issues

Is your feature request related to a problem? Please describe
Apple buried the dark mode switch under control center -> display -> dark mode, or you can go through system settings which is quite annoying
Describe the solution you'd like
I'd like to be able to toggle between dark and light modes fromMonitorControl
Describe alternatives you've considered
I considered adding the display panel to the menu bar, but that clutters an already busy corner of my screen even more
Anything else?
No response

I added this feature to BetterDisplay (you can also define a keyboard shortcut for it), I advise you to try that app. There are no plans to add additional features to MonitorControl as it is considered feature-complete by the team.


Support for HTML in answers

Hi Kevin-
Is it possible to add HTML support for answers? I've noticed that question text currently supports HTML, just not the answers.
Thanks!

If Surveyor supports it, I'll support it too.
At the moment the Surveyor documentation has a section for "Doesn't Do" which includes:
"Consistently support HTML tags in title, text, help_text attributes. We intend to move to markdown support #413 so that same survey definition can be used with nu_surveyor."
Try creating a Surveyor DML file like kitchen_sink.rb.  If you can get Surveyor to show your custom HTML, I'll make sure Surveyor_gui can mirror that behavior.


Improve loc_by_alias doc

Closes https://github.com/pydantic/pydantic/issues/7481

please review

Hmm... I'm not sure this simplifies things 👀

The goal is to make it clear that by enabling the loc_by_alias flag you will get the actual key provided in input data in the error loc instead of alias all the time.
ref: https://github.com/pydantic/pydantic/issues/7481#issuecomment-1723071503


Derive token policy forging keys according to CIP-1855

Issue Number
ADP-1044
Overview

Add new AddressDerivation module implementing policy key derivation described in CIP-1855 (for minting and burning).
Add PolicyK option to the "Depth" enum (for mint/burn policy keys).
Add minimal tests to test the key derivation.

bors r+


Bugfix (temporary) - ordering framework agreements

The SQLAlchemy .order_by clause was not behaving as expected - rather than ordering on the already-joined framework_agreements table it was doing a second outer join with no relationships specified and ordering on that, which gives undefined results.  (Sometimes it works and sometimes it doesn't).
This TEMPORARILY replaces the broken order-by by ordering the SupplierFrameworks using Python, in advance of fixing the API to exclude drafts from current_framework_agreement, at which point we can properly sort this using SQL once an expression for current_framework_agreement can be more easily defined.
The signed_agreement_date_or_millenium method is there to prevent errors when trying to order draft agreements that have None returned-at timestamps - it instead considers al drafts to be a product of the millenium bug.

Not going to do this now.


Retrofit writers to work with partitioning

@ibuenros @liyinan926 can you review?

@ibuenros updated f771eb2

LGTM other than a couple comments.

Updated. @liyinan926 please have a look.

Updated.


[WIP] Demo segfault / heap corruption

This is a demo for segfaulting PHP (Refs #6)
Any help would be much appreciated!

Closed via #6


WIP - DO NOT MERGE - Add scrooge support

Ok, there is a LOT to be desired here... there are a ton of TODOS
BUT IT WORKS
I currently have a project which has two thrift files which depend on each other, BUILDS for them, and then a scala_library which depends on that and the thrifts...it builds. My guess is right now transitive stuff will not work.
So my immediate first goal is to make a test directory with some thrifts and some stuff that depends on them, to make sure that transitive stuff works properly.
After that is just...making it less crazy. I really, really need the guidance of people who have done this... I will put a microscope to everything I did, but I'm finding the "throw structs around with attributes! oh some attributes are missing!" to really resist abstraction and promote hacks...
But it works :) so I will do the above, hopefully refactor with guidance and time, and then will try it on one of our internal repositories.
One thing that I would like to put off, though, is moving it into different files etc. Right now I want to just make sure that we get the flow of everything down properly.

note stripe has signed the CLA.

This is super great! I would like two things:

let's break into two PRs (we can serialize, since one depends on the next): srcjar #2 and then #6
let's add tests for srcjar support in a few cases: srcjar only, srcjar + src, multiple srcjars (with and without src).

Ok, CI passes, though I need to add real tests.
Definitely agree with #2, #1 I agree with but I want to do after I have a couple of passes to answer some of the issues. Without the scrooge stuff, there is no use case that will properly ensure that the srcjars are being used as intended, and that transitive information is passed along properly. Though I have a feeling that if I answer some of your comments above, the decoupling of the 2 PRs will be a lot cleaner.

Ok, so something I want to discuss a little is testing...  it doesn't seem like, as is, there is a way to test if certain targets create (or don't create) certain artifacts. I assume it is ok if I add this to run_test? Nothing crazy, but for the transitive thrift stuff, want to make sure we do/don't make artifacts at the right time.

Ok, this is maturing a lot. There are two things I'd like to do now:

make sure it works with scala binary (which will also ensure that the runtime dependencies work...my guess is right now they aren't)
figure out how we want to deal with the compile time dependencies
split it out into multiple files etc (I'm still unsure that it's worth splitting into two PRs, but am happy to do that eventually...much more focused on getting the implementation working and having something actually use source jars has been invaluable)

On the second point above, I have a comment in there, but the question is really how we want to deal with the compile time dependencies of a source jar...there's no guarantee that the immediate next target will compile it (you can have a string of targets and only the last one will actually do the compiling, this is true of normal sources as well), but the compiler dependencies will only go one level.
thinking on it, what I think we can do is carry along the compile dependencies...UNTIL a compile happens. So "transitive_compile_export" would have the same spirit as today, but it would carry it forward and be removed once a compile actually happens (instead of right now where it is removed by the dependent node). The rest would be the same.
Now that I've written it out, I think that is the right approach to take.

Ah, hm. On further thought, not sure if that will work. Gonna mull on it and explore code...

The fix is being discussed https://github.com/bazelbuild/rules_scala/pull/30, will work on the rest in the meantime

can we split this into three PRs:

support for srcjar
thrift_library (which we might want to move out of this repo one day)
scala_scrooge_library (depends on 1 and 2).

I'm moving in that direction... I'm about to push a change which splits them out into files, but I still want to get it all working, because this is a case where the consumer is going to help me figure out the design of the parent

Hm, something in the rebase broke it. That's what I get >_< will figure it out

So the thrift_library issue is outstanding, but I am going to take this chance to try and split it out into three PRs

Ok, I've split out the two leaf aspects of this
https://github.com/bazelbuild/rules_scala/pull/33
https://github.com/bazelbuild/rules_scala/pull/34
Then I will rebase this

closes https://github.com/bazelbuild/rules_scala/issues/6

I have rebased this with the other branches that have been merged... still need to finish the work potentially using the gen-file-map

Ok… so it does what we want. I am going to spend some time explaining the semantics, because even after our conversation, oscar, parts were not properly thought through. And in explaining this, I’ll explain this “extra_information” thing in scala.bzl… basically, this is a way to let things which depend on scala_library inject information into the graph that they can retrieve later, without scala.bzl having to know.
So, let’s say we have two thrift files, thrift a and its dependency, thrift b
thrift_library_a

src: thrift_a
dep: thrift_library_b

thrift_library_b

src: thrift_b

our goal is that we have some unit which owns the compilation of PART of the thrift graph, not necessarily all…this is desirable for speed (you can cache parts of the dag instead of having to compile everything) and for correctness (you can’t have file conflicts, since only one target will own compilation)
ok, so we have
scrooge_scala_library_a

dep: thrift_library_a, ???

scrooge_scala_library_b

dep: thrift_library_b

and we note that scrooge_scala_library is a macro which creates a scala library name a and a scrooge_scala_srcjar named a_srcjar…
Note the ??? above, that is where I hit a snag. Oscar, per our discussion, it seemed like the goal would be to have
scrooge_scala_library_a

dep: thrift_library_a, scrooge_scala_library_b_srcjar

scrooge_scala_library_b

dep: thrift_library_b

Basically, any scrooge_scala_library “owns” the generation of it’s immediate dependencies (so a for a, and b for b, above). But it also needs to make sure that the transitive dependency graph under a is covered, this is where the dep on scrooge_scala_library_a_srcjar comes in… it knows the transitive dependency graph, and we can check that thrift_library_a’s graph is covered.
But this has an issue! Which is that scrooge_scala_library_b_srcjar doesn’t actually know how to compile the code… only how to generate sources. Which means that in the above setup, scrooge_scala_library_a would compile the code for everything (which is slow), and it won’t really benefit from caching, as scrooge_scala_library_b_srcjar doesn’t have actual code to cache. So what we actually want is…
scrooge_scala_library_a

dep: thrift_library_a, scala_library_b

scrooge_scala_library_b

dep: thrift_library_b

scala_library is what knows how to take sources and turn them into class files, and what we want when we do a scrooge code gen is to generate code for the transitive graph (can’t really avoid that), but only compile the files that we “own”…the rest we can take advantage of caching, and the fact that they are owned by some set of other targets (this is what we held above).
However, this has another issue: scala_library_b has no notion of owning targets! That was a concern of _srcjar target that got created…
So this is the purpose of the extra_information. It’s basically a generic way for you to stuff information into the graph. When is this useful? Well, in any case like this one where you have a new target which depends on/uses scala library, like so: new_target -> scala_library -> new_target. Since we do not want scala_library to have to be modified for new targets, the only way I could come up to support this was to have a way to pass through information.
Open to other ways to resolve the above issue!
Note: I tried using jar to decompress, but the jar command doesn’t let you give it a directory to target. This is why I’m currently using unzip.
OH, also, I added a python file… but I’m not sure if projects depending on this will pick it up. I hope so?? we can reorganize accordingly.

Ok… so it does what we want. I am going to spend some time explaining the semantics, because even after our conversation, oscar, parts were not properly thought through. And in explaining this, I’ll explain this “extra_information” thing in scala.bzl… basically, this is a way to let things which depend on scala_library inject information into the graph that they can retrieve later, without scala.bzl having to know.
So, let’s say we have two thrift files, thrift a and its dependency, thrift b
thrift_library_a

src: thrift_a
dep: thrift_library_b

thrift_library_b

src: thrift_b

our goal is that we have some unit which owns the compilation of PART of the thrift graph, not necessarily all…this is desirable for speed (you can cache parts of the dag instead of having to compile everything) and for correctness (you can’t have file conflicts, since only one target will own compilation)
ok, so we have
scrooge_scala_library_a

dep: thrift_library_a, ???

scrooge_scala_library_b

dep: thrift_library_b

and we note that scrooge_scala_library is a macro which creates a scala library name a and a scrooge_scala_srcjar named a_srcjar…
Note the ??? above, that is where I hit a snag. Oscar, per our discussion, it seemed like the goal would be to have
scrooge_scala_library_a

dep: thrift_library_a, scrooge_scala_library_b_srcjar

scrooge_scala_library_b

dep: thrift_library_b

Basically, any scrooge_scala_library “owns” the generation of it’s immediate dependencies (so a for a, and b for b, above). But it also needs to make sure that the transitive dependency graph under a is covered, this is where the dep on scrooge_scala_library_a_srcjar comes in… it knows the transitive dependency graph, and we can check that thrift_library_a’s graph is covered.
But this has an issue! Which is that scrooge_scala_library_b_srcjar doesn’t actually know how to compile the code… only how to generate sources. Which means that in the above setup, scrooge_scala_library_a would compile the code for everything (which is slow), and it won’t really benefit from caching, as scrooge_scala_library_b_srcjar doesn’t have actual code to cache. So what we actually want is…
scrooge_scala_library_a

dep: thrift_library_a, scala_library_b

scrooge_scala_library_b

dep: thrift_library_b

scala_library is what knows how to take sources and turn them into class files, and what we want when we do a scrooge code gen is to generate code for the transitive graph (can’t really avoid that), but only compile the files that we “own”…the rest we can take advantage of caching, and the fact that they are owned by some set of other targets (this is what we held above).
However, this has another issue: scala_library_b has no notion of owning targets! That was a concern of _srcjar target that got created…
So this is the purpose of the extra_information. It’s basically a generic way for you to stuff information into the graph. When is this useful? Well, in any case like this one where you have a new target which depends on/uses scala library, like so: new_target -> scala_library -> new_target. Since we do not want scala_library to have to be modified for new targets, the only way I could come up to support this was to have a way to pass through information.
Open to other ways to resolve the above issue!
Note: I tried using jar to decompress, but the jar command doesn’t let you give it a directory to target. This is why I’m currently using unzip.
OH, also, I added a python file… but I’m not sure if projects depending on this will pick it up. I hope so?? we can reorganize accordingly.

I think this is ready, but there are some followups that would be good...

more pie in the sky: generalize how we propagate information through the targets... extra_information is the beginning of this, but we generally are passing information through the graph a lot (sometimes transitive, sometimes transitive with rules). We should fully generalize this.
ensure 100% that you can't have the same class file twice. First step is probably just to check and error out, but we want to probably also use extra_information here to make sure that we can't have diamonds (right now it might be possible with overlapping scala_scrooge_library)
more practical: let's get rid of all of the bash scripts, and push it into an actual language (in this case, scala)

@johnynek: anything else? and of course, we should go over it once more

So, looking at this:
https://github.com/twitter/scrooge/blob/develop/scrooge-generator/src/main/scala/com/twitter/scrooge/Compiler.scala#L35
I think we would have includes in scala_scrooge_library and pass the thrift files there. Which is a bit weird, but I guess you can either do deps or includes. deps is relative to the current directory and includes makes the directory magically appear under any path.

@jcoveney see:
https://github.com/twitter/scrooge/blob/develop/scrooge-maven-plugin/src/main/scala/com/twitter/ScroogeRunner.scala#L40
looks like includes is exactly what we are seeing. With include support, we should be good to go.

Ooook...so includes works! There are two new additions that we probably need to discuss... the first is absolute_prefix (I welcome new names!). The issue is this: our thrift usually exists in a hierarchy like src/main/thrift/com/stripe/blah. Absolute imports are with respect to com/stripe/blah, but there's no way (that I can think of?) to just "know" that you should be doing your imports off of src/main/thrift as the "base" for includes. I can't think of a way to do this automatically that wouldn't create the possibility for erroneous includes.
The second one is the so-called "remote_jar"...this one I think we may want to think through a little more. The issue is this: we have thrifts that exist in the world, but not necessarily under the control of bazel. remote_jar is how you tell the codegen that you have the missing thrifts... right now, it assumes that this jar has both thrifts+classpath files (this is how we published them at stripe). This can all be changed, but something we need to sort of decide on. This was instrumental in getting an important internal respository to work with this... and I don't think "convert it all to bazel" will be feasible for many thrift deployments going forward. I think we need something, and it should be correct, and doesn't have to be amazing.

Lots of cleanup just pushed

So it sounds like you're ok with absolute_prefix, and we should at least get a POC that new_git_repository can eliminate the need for remote_jars

One minor comment, then ready to go. Thanks for pushing this through!

So what do we want to do about the remote_jars? Leave them for now, but comment that they may be removed soon? Or get the new_git_repository thing working?

Oh, and re: _jdk, I'm gonna put it back... I totally forgot about https://github.com/bazelbuild/rules_scala/pull/37/ !

so I guess _jdk is a dependency of _jar? hm, I guess we will see :)

crap, I merged your other one and now this won't merge cleanly

I'll fix it now

Fixing it was pretty easy actually... I kept the commits, though it was a rebase, so they'll get new sha's. But hopefully you still get the incremental view?

Awesome!

For your information this has broken ci.bazel.io build (missing dependency). See http://ci.bazel.io/job/rules_scala/105/


Is there a way to run repo insert or update queries in a transaction?

I there a way to run multiple insert/update queries inside a MongoDB transaction, for example when we do a deposit into an account we need to insert the deposit amount in the AccountTransaction and then update the Account balance but that should be a transaction to be able to do a rollback when there is any error.

Currently, BackendMethod runs in a transaction.
I agree that also, api insert and api update should run in a transaction, and I'll implement that soon.

If you run these multiple operations in a BackendMethod they will run in a transaction.
Test it and let me know

I did something like this and the first employee was saved to the DB. Should I do something different?
export class EmployeeController {
  @BackendMethod({ allowed: Allow.authenticated })
  static async testDbTransaction(employee1: Employee, employee2: Employee): Promise<Employee> {
    const e1 = await remult.repo(Employee).insert(employee1);
    if (true) {
      throw Error('Abort DB transaction');
    }
    const e2 = await remult.repo(Employee).insert(employee2);
    return e1;
}

I've reproduced the issue and am working on it now

Hi @grrenier, I've fixed the issue in this release:
https://github.com/remult/remult/releases/tag/v0.20.5
Can you check it out and let me know?

Hi @noam-honig, I tested the version 0.20.5 and it works as expected. You are doing an awesome work in this framework.


release: 0.5.0

last release, mainly to publish the readme with deprecation message to npmjs.

@curbengh
Please don't forget to publish this with deprecate command.

yep, actually I was about to npm-deprecate before this PR, then I remembered the npm's readme is not updated yet.

https://www.npmjs.com/package/hexo-renderer-jade/v/0.5.0
also deprecated the npm package.

@YoshinoriN
Please archive this repo.


Stabilize flaky self animations e2e on Android

Description
Test should wait during delays shorter than 1.5s (driver: JS), running on Detox demo app on Android is very flaky, often breaking builds. Need to see why and stabilize / file an actual bug.
Example: https://jenkins-oss.wixpress.com/job/detox-android-56-master/150/console
Device and verbose Detox logs
Typical test result:
Error: Error: No views in hierarchy found matching: (with tag value: is "UniqueId_AnimationsScreen_afterAnimationText" and view has effective visibility=VISIBLE)

I see now that this also happens on iOS. Might be something with the test's logic.

What is happening on iOS?

@LeoNatan I can't seem to find the sample I came across earlier today. I'll stick with Android for now.
In any case, on Android I seem to be going down the rabbit hole with this one.

From the description, it sounds like a bug in the timers idling resource. I am not familiar with such issues on iOS.

Following a very deep analysis, apparently the explanation lies in just one simple line of code (see PR).
Here's the flow that's causing the e2e to fail:

The test sequence sets up a 400ms animation to start after a 500ms delay (which RN translates to a 500ms timer). When all is done (900ms), RN (JS) rerenders the test component's by changing its internal state (callback to Animated); This time, an after-animation text shows.
Simultaneously, the test (node) sets up an expect to have that after-animation test visible.
On the device, during the 500ms the timers IR (Idling Resource) identifies at least one pending timer, and thus is when interrogated, declares itself busy.
After 500ms, the device enters an intermediate state where overdue timers are still in queue - just about to get popped by RN. Due to naïve logic, the idling resource - when interrogated in that state, declares itself idle (!) All in all, this causes Espresso to think everything is idle. And then...
Should, by chance, the 'expect' assertion has happened to have arrived at DetoxManager within the 500ms window, once the timer effectively expires, the assertion will immediately be validated (to failure...)

The fix here is then to drop the aforementioned naïve condition, thus averting to consider any timer (non-repeating and <1500ms) in queue as holding the system busy. That would cause Espresso to continue interrogating until the timers is busy even after the 500ms effectively pops. Only - by then, the ui manager will be busy handling the animation, which will cause Espresso (and Detox) to first way for the animation to end -- before validation the text component visibility assertion.


Changes for matplotlib3.8

Description
matplotlib3.8 released yesterday morning.

[x] Axes._get_lines.prop_cycler has been removed, instead use Axes._get_lines.get_next_color() (inevitable with private member usage)
[x] plt.hexbin now plots bins ≥mincnt, not >mincnt, which changes the behaviour with the default of 0 (corresponding to None in the signature). I have used np.finfo.tiny to correct this.
[x] tcolors is deprecated, I have lifted the code used to simulate it in matplotlib to restore the test in test_contour_plot_2d().
[x] samples.plot.[fast]kde_2d() now only adds two collections to the axes
[ ] plt.contour colors are out of whack (one weird extra one and the others are slightly different)

The last three are all symptoms of plt.contour returning QuadContourSet (one per level, so usually two for a contour plot) rather than PathCollection.
I'm completely stumped by the last one.
Fixes # (issue)
Checklist:

[ ] I have performed a self-review of my own code
[ ] My code is PEP8 compliant (flake8 anesthetic tests)
[ ] My code contains compliant docstrings (pydocstyle --convention=numpy anesthetic)
[ ] New and existing unit tests pass locally with my changes (python -m pytest)
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have appropriately incremented the semantic version number in both README.rst and anesthetic/_version.py

An extra level of .collections[0] restores the original test, as the first gets at the QuadContour object, and the second gets us to the deprecated API we were using to test before.
The plots at least look identical to the previous matplotlib

Still stumped 😢 using the old api will be deprecated in a couple of minor versions so I'd prefer not to rely on it.
I just can't work out what the five colours from QuadContourSet.get_edgecolor() actually correspond to

Still stumped 😢 using the old api will be deprecated in a couple of minor versions so I'd prefer not to rely on it.

Agreed, how about we add a matplotlib version check to the tests and test both old and new API. In the actual code I'd find that really annoying, but if we limit it to the tests that should be ok, right?

Still stumped 😢 using the old api will be deprecated in a couple of minor versions so I'd prefer not to rely on it.

Agreed, how about we add a matplotlib version check to the tests and test both old and new API. In the actual code I'd find that really annoying, but if we limit it to the tests that should be ok, right?

But what do we do in two matplotlib's time? My concern is I don't understand the QuadContourSet colours

But what do we do in two matplotlib's time?

Keep adding to the tests and we could say anything older than 2 or 3 minor matplotlib versions get's scratched.

My concern is I don't understand the QuadContourSet colours

QuadContourSet.get_edgecolor() should return the colours of the contour lines (so it should be one more than the number of levels). QuadContourSet.get_facecolor() should return the colours of the contourf faces (as many as there are levels). In 3.7 each face and each line was its own PathCollection (that's where the number 5 came from, 2 faces and 3 lines). Now in 3.8 it seems these have been grouped into two QuadContourSet, one for contourf and one for contour.

got it, thanks Lukas 😄 hopefully that's this PR done

Whoops! Left that in from while I was remembering how to check the version


Added API reference docs url

I have added API documentation for users who are new to Chainlit. While the official documentation is already mentioned in the README, I have provided a direct link to the API docs to save time.

Thank you for your contribution! We updated the readme since you opened this PR, can you please rebase to the latest version?

Do I have to close the PR ?

I resolved the conflicts

All conflicts resolved

I would greatly appreciate it if this PR could be merged as soon as possible. Our participation in Hacksquad is ongoing, and it is scheduled to conclude on the 31st of October. Currently, we hold a position 58 in the top 60, and in order to maintain our rank, it is crucial that this PR gets merged promptly. If the proposed changes are approved, kindly proceed with the merge. However, if any further adjustments or modifications are necessary, please inform me, and I will address them accordingly.
Thank You


Avoid copying table's record batches

Fixes #2276

Thanks for fixing it. I actually included a similar fix in #2291 along with some updates in tests
I'm closing this one in favor of #2291 if you don't mind.
Thanks again !


Doing an empty search from global header adds query= to the url query

I think we did something to avoid it in the search hub's searchbar but it hasn't been done for the headers' search bar. Be nice to not have that parameter if the field is empty.

Moving back as I'm trying to figure out if we actually need this function at all.
current status is that @gestchild and I have gone through it and are asking @taceybadgerbroo here  if it's used as we're thinking it should be?


Waypoint mission v2

@MikeWoots it's so much work. Let's chat about this when you get a chance.

@MikeWoots gonna merge since Vic has tested and didn't find any major issues. We can iterate on this.


Landscape/Portrait Feature

Hi, I was wondering if there's any possibilities to pull the new image feature from Instagram, which is the landscape/portrait. Right now, you have resolutions which is great. But I was wondering if we can pull more like, the original landscape/portrait images.

I guess they haven't update their update since the new feature was just released. Hope to hear an update soon!


Merge Coupled branches

Pull Request Test Coverage Report for Build 570

51 of 92 (55.43%)  changed or added relevant lines in 4 files are covered.
12 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.3%) to 62.012%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

cbc/src/main/java/eu/stamp/cbc/calculator/CoupledBranches.java
30
36
83.33%

cling/src/main/java/eu/stamp/cling/fitnessfunction/BranchPairFF.java
19
54
35.19%

Files with Coverage Reduction
New Missed Lines
%

cbc/src/main/java/eu/stamp/cbc/calculator/CoupledBranches.java
12
78.89%

Totals

Change from base Build 565:
-0.3%

Covered Lines:
4468

Relevant Lines:
7205

💛  - Coveralls


Reorganize to hide internals and add start.sh

I put all the project files into a src/ folder to hide the internals and improve the user experience a bit while making things looks a bit neater.
This involved

creating a shell script that automatically creates, activates, and deactivates the venv. It also makes sure requirements are up to date
moved all the .py files into the new src/ folder
made all the imports between .py files relative so it would work as a package
renamed Web_LLM.py __main__.py and created __init__.py so src is treated as a package
update README.md to specify that modelfile can be created in the project root

I also added a small note in the 'configuration' section of the README to dispel any confusion on which model name should be copied into llm_config.py
The program works exactly as it did before, just a little easier to use now.
Let me know if you have any questions.

Thanks @synth-mania. I noticed the following issues with your code:

It doesn't account for the model not being defined in llm_config. I get a 404 error from Ollama if it's not defined.
start.sh needs to have executable permissions or it fails to run with ./start.sh.
start.sh is formatted in CLRF which doesn't work well in Linux and Mac systems. I had to convert it using dos2unix on my Mac.
bash is not always at /bin.  I'm not going to be available for the next couple hours - traveling for Thanksgiving, but I'll try to fix these issues as soon as possible.

Thanks for the work people! Please let me know when you have it functional, I don't wanna repeat deleting the entire functionality of the main by a merge that wasn't great again haha
I'll check this out in a day or so hopefully it'll be working better by then!


#1164: fixed images not showing issue

fixed images not showing on tracks ,home and other pages issue.
test server- https://damp-fjord-94767.herokuapp.com/

Codecov Report

Merging #1165 into development will not change coverage.
The diff coverage is n/a.

@@             Coverage Diff              @@
##           development    #1165   +/-   ##
============================================
  Coverage        62.98%   62.98%
============================================
  Files                8        8
  Lines             1375     1375
  Branches           213      213
============================================
  Hits               866      866
  Misses             509      509

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 247afdf...d4c1dc6. Read the comment docs.

Works Great. Thanks @anu-007


shopify-cli: init at 2.14.0

Description of changes
This PR provides the package shopify-cli
Things done

Built on platform(s)

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

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

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

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.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.

I don't see anything that jumps at me. Thank you for the contribution!


confusing behavior on network fail

When trying to click on a link in menu on dvc.org while network failed it changes address and then does nothing. If you click on some top level menu item other than one you are in then menu works as expected and hide/show animation is shown for a content, but it leaves the content if the last page not new one.

Probably we need to reset the page's content on the client side before even trying to load a new page.

Sorry to come back here, but I still have this issue. No animation now, but nothing happens on click besides address is updated.
Additionally slow network is also confusing: you click, address changes and then nothing happens for some time - no progress/wait indicator, then page is updated with an animation.

@Suor please, feel free to reopen it next time if you see that it's not solved yet!

In current version on navigation then there is no network connection FF and Chrome both correctly shows standard "No Internet" pages.
Created separate ticket for loading indicator discussion #589


cmd/compile: use strings.Builder

The main challenge here is ensuring everything still works when built with 1.4.
Probably build tag protected files, with something like
type buffer struct {
bytes.Buffer
}
for pre-1.10 and
type buffer = strings.Builder
for 1.10+.

I've been thinking we should add a "cmd/internal/polyfill" (or however we want to spell the bikeshed) package that provides interfaces to sort.Slice, strings.Builder, and other recent stdlib additions that we want to use in the toolchain, while maintaining Go 1.4 compatibility.

@mdempsky, you could call the package just "util". ducks

Why stop there? “common”, “shared”, or “base” are all perfectly cromulent package names.

On 15 Feb 2018, at 07:09, Brad Fitzpatrick<EMAIL_ADDRESS>wrote:
@mdempsky, you could call the package just "util". ducks
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

cmd/internal/compat?

In cmd/compile/internal/gc there's these cases:

fmt.Fprintln/fmt.Fprintf writing to a bytes.Buffer
bytes.Buffer plugged into the output of exec.Command
buf.WriteString()
buf.WriteString(fmt.Sprintf())
bufio.NewWriter(&a_bytes.Buffer)

I assume there might be cases of “str” + “str2” or fmt.Sprintf that may be more efficient as a strings.Builder.
https://github.com/golang/go/issues/18990 indicates there are no benchmarks for Builder. I see go tool compile -bench that would allow a comparison of compiler things in ns/op with these changes. Without a clear performance win I don't see a reason to do this.

In any case, the point behind my snark was to make sure that the package does NOT become a "util" package that itself depends on many things the caller of your package may not want.
It might be valid for the first few things, but it'll inevitably grow, and the util-ness bloat will sneak up on us.
It might be best to have N such packages under some "compat" or "future" directory.

cmd/internal/strbuf?

@bradfitz

In any case, the point behind my snark was to make sure that the package does NOT become a "util" package that itself depends on many things the caller of your package may not want.

I was imagining a package that's limited to just providing current standard library functionality, with backwards compatible implementations for bootstrapping under older Go releases. That is, for non-bootstrap builds, the packages don't do anything but pass through calls to the standard library.
It seems like you're suggesting that cmd shouldn't treat std as a single monolithic dependency, but instead should view each standard library package dependency individually. I understand why this is important within std, but it's not clear to me that it extends to cmd too.

I understand why this is important within std, but it's not clear to me that it extends to cmd too.

I personally don't care too much. I'm mostly echoing the objections I've heard about "util" packages in the past.
Practically, it matters less here because this is an internal package and we can therefore audit the fixed number of users of the "util" package and verify they're not pulling in anything unnecessary via the util package they wouldn't depend on otherwise via other paths.

At what point to we bite the bullet and say that you need something newer than 1.4 to build the latest Go release and add an extra step to bootstrapping from C?

At what point to we bite the bullet

As late as humanly possible. Go 2, perhaps.

I can work on this.
I don’t like “util” packages but importing a few extra compatibility types isn’t going to be a big deal here, and we have to have a package since compile is split into horizontally dependent subpackages. I’d just add cmd/internal/compat and have a compat.StringBuffer.
My previous comment is coming from ignorance, sorry about that. Obviously at least the linker is also required, and adjusting the bootstrap is outside the scope of this issue. I’ll assume other commands need the compatibility types too.
Again from ignorance, I’m not seeing package testing style benchmarking (with the stability feature) for the compiler. I was thinking I’ll write cmd/compile/bench_test.go that sets up by compiling the gc dependencies then benchmark loops on main() targeting package gc.
I only have an amd64/linux computer to benchmark on though, are there resources for trying things on other platforms? I’ll just email golang-dev asking for benchmarks with the change if not.

Compiler benchmarking:
https://godoc.org/golang.org/x/tools/cmd/compilebench
https://github.com/josharian/compilecmp

Oh, and I assume that the vast majority of compilation occurs on amd64, so I wouldn’t sweat that.

I’m not seeing a significant performance difference with compilebench+benchstat. I’ll try to modify the cases where a Reader or .Bytes() call is used next, so far I've only done the direct replacement cases.

Based on what I'm reading via Google Search I'll leave these small return concat cases alone:
// fmt.go
return "[]" + tmodeString(t.Elem(), mode, depth)

return t.Etype.String() + "-" + typefmt(t, flag, FErr, depth)

return "[" + strconv.FormatInt(t.NumElem(), 10) + "]" + tmodeString(t.Elem(), mode, depth)

time+alloc benchmarks: https://github.com/golang/go/issues/16897

I’ve submitted two patch sets that are both off what this change should be but I’ve shown that func tconv in cmd/compile/internal/gc/fmt.go is the only potentially worthwhile place to add in strings.Builder. I’m working on a fresh patch set now.

Here’s the time spent when compile (devel +1b1c8b3 Feb 17) is called on cmd/compile/internal/gc:

The tconv things (dumpobj1) account for only 6.6% of the compile time in this case, but garbage collection (runtime.gcDrain) accounts for 18.7%. It’s possible that dumpobj recursive string concatenation generates a significant part of the garbage, so next I’ll try to show where garbage is left. gc.bottomUpVisitor.visitcode, gc.compile, and ssa.Compile are other places to look.

You want to look at memory (allocation) profiles, not CPU profiles, if your goal is to eliminate the creation of garbage. Reducing garbage reduces CPU.

@bradfitz for some reason the pprof heap profile doesn’t show any detail into gc.Main which is why I went to CPU, but I’ll keep trying.

With debug.SetGCPercent(-1) and runtime.MemProfileRate = 1 compiling cmd/compile/internal/gc:

I'm not sure why the dumpobj string concats don't end up here.

I primarily look at -alloc_space. It's space that ultimately triggers collections.

Well I’m not convinced making small changes like replacing some bytes.Buffer use is worth it, for larger changes I think I’ll need a lot more time to understand the compiler and in-flight efforts, and I’m in the middle of some life changes.
I’m unable to work on this more for now.

Thanks for looking into it.


Avoid testing for cover if not a weapon or spell attack

See if we can avoid testing for cover in dnd5e for non-attack spells. E.g., healing.

Addressed in v0.6.5.


Update Particle.pde

Hi 👍
I was trying to run this example and it wasn't running because of a little mistake in the variables names. This PR corrects it and removes the use of a deprecated method.
By the way, thank you for all this material. I'm following your videos and I'm really impressed how a material with so quality is available for free. Really!

Thank you!


Tidy

Refactoring will have caused some breaking changes. Masks and neural networks now have their own modules (masks.py and nn respectively).


Update for new type constructors

[ ] type constructors (<T> => X<T>), including type constraints
[ ] anonymous generic functions (<T>(T t) => t), including type constraints
[ ] type parameters with type parameters

Also a type parameter can now have type parameters of its own.
And don't forget that all these things can have type constraints.

Thanks, updated the issue

Also a type parameter can now have type parameters of its own.

Actually, I can’t find this in Ceylon.g or in the typeconstructors.ceylon test; what do type parameters with type parameters look like?

Ooh, I see, it’s given Box<Value>, in the constraint list.

@gavinking are type constructors still an “experimental feature” in 1.2? If yes, I’ll slip this.

Yes.

@lucaswerkmeister when you do take this on, can you consider doing it in a feature branch for 1.2? I certainly don't want to push you into extra work, so if this doesn't make sense when the time comes, please disregard.

The main reason I like to wait for the spec is that ceylon.ast types are usually named the same as their corresponding spec rules, but if the spec hasn’t been written yet, there’s the danger that I’ll have to rename the ceylon.ast node later.
Other than that… I’m not sure what your asking. Do you mean when I get around to adding type constructors, I should do it on a branch based on the 1.2 tag rather than whatever master is at the time, so you can build yourself a version that’s just 1.2 plus type constructors? I can do that, sure.

Yes, cool, thanks!


Different HW versions have different id ranges for devices

Only have samples from HW 2 and 4 for now, so all other versions will throw an error.
Fixes #21

Already merged into dev


Some lines in bar chart slide to the right, others move vertically

I'm creating a timeline style of graph using line chart where I update the data based on time every x amount of seconds. The issue is that some lines slide to the right, as expected, but other simply move vertically.
Reproduce
  List<LineChartBarData> _getDatas(WidgetRef ref) {
    List<LineChartBarData> datas = [];
    for (final host in hosts) {
      var provider = ref.watch(pingListProvider(host));
      List<FlSpot> points = provider.points;
      var data = LineChartBarData(
        spots: points,
        isStepLineChart: true,
        show: points.isNotEmpty,
        color: CustomColors.fromString(provider.host),
        dotData: FlDotData(
          show: false,
        ),
      );
      datas.add(data);
    }
    return datas;
  }

Video
Video
To Reproduce
Repository

Chart generation code:

LineChart(
            swapAnimationCurve: Curves.easeInOut,
            swapAnimationDuration: const Duration(milliseconds: 250),
            LineChartData(
              minY: minPing == null ? 0 : minPing - 5,
              maxY: maxPing == null ? 0 : maxPing * 1.05,
              gridData: FlGridData(
                horizontalInterval: 25,
                verticalInterval: 5, // 5 seconds
              ),
              titlesData: _getTitlesData(),
              lineBarsData: _getDatas(ref),
              borderData: FlBorderData(
                show: false,
                border: Border.all(
                  color: Colors.grey.shade200,
                ),
              ),
            )

Notes
Strangely, the lines that are above 100 all move vertically, and the lines below 100 slide.
Versions

Flutter 3.16.4
fl_chart: ^0.62.0

It is because of an animation that we have inside the chart.
So when a list changes and the lengths is the same, we lerp through all the elements and animate them. So in this case we should not do that.
For now, you can disable the animations by setting zero in the swapAnimationDuration.
If you or someone else want to work on it, this is a good starting point:
https://github.com/imaNNeo/fl_chart/blob/d1166014244e03df3c38ff8f55fa9e78c4740ecb/lib/src/utils/lerp.dart#L6-L24


Abstraction for publishing with prepared representation

Changelog Description
Unified way of preparing representation data for local and farm publishing.
Additional info

added into traypublisher simple collector
added into nuke collect write

Testing notes:

try publishing and nuke should work as it was before

Dependencies
Changes from this PR were initially implemented in this pull request. However, due to its significant size, we made the decision to divide it into smaller portions.
!!! This PR should be merged after #5496. But before the merge the target branch should be changed to develop !!!

I think there are some conflicts with develop in submit_publish_job.py and openpype/pipeline/publish/publish_plugins.py

@jakubjezek001 can we resolved the comments on this before further testing?

Because we're splitting OpenPype into ayon-core and individual host addons, this PR would have to be re-created to target one of those.
We're closing it down, but we'll he happy for a new PR to ynput/ayon-core or the host addon repository once it's up.


Add Question Painter_partition_In_Binary_Search_folder

Hi @ajay-dhangar
📥 Pull Request
Description
This pull request for Issue #1071 introduces the Painter Partition Problem implementation to the Binary Search directory. The problem is solved using a combination of binary search and a greedy approach to optimize the time required for multiple painters to paint all boards.
Fixes #1071
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] Documentation update

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules

Implementation of Painter Partition Problem In Binary Search Folder for Issue #1071
Description
This pull request for Issue https://github.com/ajay-dhangar/algo/issues/1071 introduces the Painter Partition Problem implementation to the Binary Search directory. The problem is solved using a combination of binary search and a greedy approach to optimize the time required for multiple painters to paint all boards.
Problem Summary:
You are given an array boards[] where each boards[i] represents the length of the i-th board. You have k painters, and each painter takes 1 unit time to paint 1 unit of the board. Each painter can only paint continuous sections of boards. The task is to minimize the time taken to paint all the boards.
Change Summary:
This C++ implementation solves the Painter Partition Problem by combining Binary Search and the Greedy Approach to efficiently find the minimum maximum time needed to paint all the boards while ensuring that no more than k painters are used.
Issue Fixed:
The problem of determining the minimal time required to paint all boards using exactly k painters, while ensuring each painter paints a contiguous block of boards, is solved by the function findLargestMinDistance().
Motivation:
The problem is frequently encountered in situations involving resource allocation, such as dividing workloads evenly among workers while minimizing the maximum time. This solution efficiently handles larger input sizes by using binary search and greedy methods.
Solution Approach:
1.Binary Search: Search for the minimal possible maximum time within a range defined by the largest board size and the total sum of board lengths.
2.Greedy Method: A helper function countPainters() counts the number of painters required for a given time threshold, ensuring no painter exceeds that time limit.
Key Concepts:

Binary Search: Used to find the minimum maximum time required to paint all the boards.
Greedy Approach: The helper function countPainters() assigns boards to painters ensuring the total time doesn't exceed the given limit for that iteration.

Dependencies:
C++ Standard Template Library (STL) for functions like max_element, accumulate, and basic I/O
Files Added:
Painter_Partition_Problem.md: Contains the problem statement, approach, and explanation of the solution using binary search and the greedy method.
Painter_Partition_Problem.cpp: The C++ program implementing the algorithm to solve the Painter Partition Problem.
The file has been placed in the Binary Search folder.
Thank you for your time and consideration!
Best regards,
@khurshed07
GitHub Profile

Hi @ajay-dhangar,
I’ve updated the file content in line with your feedback and as per our contribution guidelines . Could you please review the changes and submit the pull request? Additionally, as per our contribution guidelines, kindly ensure that the code adheres to the syntax and formatting standards.
If you encounter any issues, feel free to let me know.
Thank you!
@khurshed07


Crashes when it cannot send a message

I had logram try to send a message while my Internet was down:
Jan 25 03:06:37 logram[44771]: Error: A network error: error sending request for url (https://api.telegram.org/botXXXX/sendMessage): connection error: Connection reset by peer (os error 104)
Jan 25 03:06:37 logram[44771]: Caused by:
Jan 25 03:06:37 logram[44771]:     0: error sending request for url (https://api.telegram.org/botXXXX/sendMessage): connection error: Connection reset by peer (os error 104)
Jan 25 03:06:37 logram[44771]:     1: connection error: Connection reset by peer (os error 104)
Jan 25 03:06:37 logram[44771]:     2: Connection reset by peer (os error 104)
Jan 25 03:06:37 systemd[1]: logram.service: Main process exited, code=exited, status=1/FAILURE
Jan 25 03:06:37 systemd[1]: logram.service: Failed with result 'exit-code'.

I would love for an option for logram to keep trying to send the message for N amount of time. In my case, the process crashed, and the message was never sent.

Good suggestion, but I think the application should explicitly crash on error. Nevertheless, it should be possible to change this behavior, of course.
I will leave the current error behavior, but add to the configuration the ability to configure retries on error, e.g.
telegram:
  chat_id: 123
  token: abc
  send_retries: 5 # new, 0 by default
  send_retry_interval: 10000 # new

Your PR and issue is a great excuse to shake the dust off this project, thanks!


Revisit icons in Design System

[ ] Align with Figma
[ ] Research whether an icon font is the right way to display icons
[ ] If yes, adjust font sizes so icons are sharper in the UI

Not relevant anymore.


[BEAM-5524] Fix minor issue in style guide.

A long time ago apply was renamed to expand to prevent API confusion.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

R: @Ardagan

Run RAT PreCommit