[BUG] Mistral/Mixtral generate nonsense past 4096 tokens in prompt

If the prompt contains more than 4k tokens, the model will begin generating nonsense. This seems to be true for both Mistral and Mixtral. I launched the engine at both 32k and 8k max model lengths for testing. Tested with the latest vllm release.

Tested using SillyTavern. No issues with the prompt (I manually inspected, and it works perfectly fine with other models).
CC @WoosukKwon @zhuohan123 because this seems like an important bug.

I have noticed the same thing. I'm running from docker, and tried with both the latest and built from source, with no difference.
docker run -it --gpus all -e HUGGING_FACE_HUB_TOKEN=$token --ipc=host -p 8080:8080 -v $volume:/root/.cache/huggingface docker.io/vllm/vllm-openai --model $model --tensor-parallel-size 8 --port 8080 --load-format pt
As far as I can tell I'm not doing anything special, and the same setup works with hf tgi, so it doesn't appear to be a model issue.

I am having the same issue with Mistral 7b.

I am having the same issue, was wondering if it has something to do with the sliding_window config, I'm running it using vLLM

@dev-mush what value did you update it to?

@dev-mush what value did you update it to?

32k, mistral team says that it should theoretically support up to 128k context, but the problem went away as soon as I got it to 8k...I'm having troubles understanding how the sliding_window affects the quality of the output to be honest, so any hint is well appreciated ☺

with 32k, I am getting rpc error: code = DeadlineExceeded desc = context deadline exceeded%
8k is working though, but the garbage is still there for me :/
full traceback here:
Traceback (most recent call last):▉| 12.1G/12.1G [05:32<00:00, 40.6MB/s]
  File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main]
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/usr/local/lib/python3.10/dist-packages/vllm/entrypoints/openai/api_server.py", line 729, in <module>
    engine = AsyncLLMEngine.from_engine_args(engine_args)
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/async_llm_engine.py", line 495, in from_engine_args
    engine = cls(parallel_config.worker_use_ray,
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/async_llm_engine.py", line 269, in __init__
    self.engine = self._init_engine(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/async_llm_engine.py", line 314, in _init_engine
    return engine_class(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/llm_engine.py", line 107, in __init__
    self._init_workers_ray(placement_group)
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/llm_engine.py", line 194, in _init_workers_ray
    self._run_workers(
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/llm_engine.py", line 750, in _run_workers
    self._run_workers_in_batch(workers, method, *args, **kwargs))
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/llm_engine.py", line 727, in _run_workers_in_batch
    all_outputs = ray.get(all_outputs)
  File "/usr/local/lib/python3.10/dist-packages/ray/_private/auto_init_hook.py", line 24, in auto_init_wrapper
    return fn(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/ray/_private/client_mode_hook.py", line 103, in wrapper
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/ray/_private/worker.py", line 2563, in get
    raise value.as_instanceof_cause()
ray.exceptions.RayTaskError(ChunkedEncodingError): ray::RayWorkerVllm.execute_method() (pid=7598, ip=<IP_ADDRESS>, actor_id=9a702c3d2722e46a47e1444101000000, repr=<vllm.engine.ray_utils.RayWorkerVllm object at 0x7f1781fa3d90>)
  File "/usr/local/lib/python3.10/dist-packages/urllib3/response.py", line 833, in _raw_read
    raise IncompleteRead(self._fp_bytes_read, self.length_remaining)
urllib3.exceptions.IncompleteRead: IncompleteRead(4963331015 bytes read,<PHONE_NUMBER> more expected)

The above exception was the direct cause of the following exception:

ray::RayWorkerVllm.execute_method() (pid=7598, ip=<IP_ADDRESS>, actor_id=9a702c3d2722e46a47e1444101000000, repr=<vllm.engine.ray_utils.RayWorkerVllm object at 0x7f1781fa3d90>)
  File "/usr/local/lib/python3.10/dist-packages/requests/models.py", line 816, in generate
    yield from self.raw.stream(chunk_size, decode_content=True)
  File "/usr/local/lib/python3.10/dist-packages/urllib3/response.py", line 934, in stream
    data = self.read(amt=amt, decode_content=decode_content)
  File "/usr/local/lib/python3.10/dist-packages/urllib3/response.py", line 905, in read
    data = self._raw_read(amt)
  File "/usr/local/lib/python3.10/dist-packages/urllib3/response.py", line 811, in _raw_read
    with self._error_catcher():
  File "/usr/lib/python3.10/contextlib.py", line 153, in __exit__
    self.gen.throw(typ, value, traceback)
  File "/usr/local/lib/python3.10/dist-packages/urllib3/response.py", line 729, in _error_catcher
    raise ProtocolError(f"Connection broken: {e!r}", e) from e
urllib3.exceptions.ProtocolError: ('Connection broken: IncompleteRead(4963331015 bytes read,<PHONE_NUMBER> more expected)', IncompleteRead(4963331015 bytes read,<PHONE_NUMBER> more expected))

During handling of the above exception, another exception occurred:

ray::RayWorkerVllm.execute_method() (pid=7598, ip=<IP_ADDRESS>, actor_id=9a702c3d2722e46a47e1444101000000, repr=<vllm.engine.ray_utils.RayWorkerVllm object at 0x7f1781fa3d90>)
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/ray_utils.py", line 32, in execute_method
    return executor(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/vllm/worker/worker.py", line 72, in load_model
    self.model_runner.load_model()
  File "/usr/local/lib/python3.10/dist-packages/vllm/worker/model_runner.py", line 36, in load_model
    self.model = get_model(self.model_config)
  File "/usr/local/lib/python3.10/dist-packages/vllm/model_executor/model_loader.py", line 124, in get_model
    model.load_weights(model_config.model, model_config.download_dir,
  File "/usr/local/lib/python3.10/dist-packages/vllm/model_executor/models/mixtral.py", line 519, in load_weights
    for name, loaded_weight in hf_model_weights_iterator(
  File "/usr/local/lib/python3.10/dist-packages/vllm/model_executor/weight_utils.py", line 201, in hf_model_weights_iterator
    hf_folder, hf_weights_files, use_safetensors = prepare_hf_model_weights(
  File "/usr/local/lib/python3.10/dist-packages/vllm/model_executor/weight_utils.py", line 141, in prepare_hf_model_weights
    hf_folder = snapshot_download(model_name_or_path,
  File "/usr/local/lib/python3.10/dist-packages/huggingface_hub/utils/_validators.py", line 118, in _inner_fn
    return fn(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/huggingface_hub/_snapshot_download.py", line 238, in snapshot_download
    thread_map(
  File "/usr/local/lib/python3.10/dist-packages/tqdm/contrib/concurrent.py", line 69, in thread_map
    return _executor_map(ThreadPoolExecutor, fn, *iterables, **tqdm_kwargs)
  File "/usr/local/lib/python3.10/dist-packages/tqdm/contrib/concurrent.py", line 51, in _executor_map
    return list(tqdm_class(ex.map(fn, *iterables, chunksize=chunksize), **kwargs))
  File "/usr/local/lib/python3.10/dist-packages/tqdm/std.py", line 1170, in __iter__
    for obj in iterable:
  File "/usr/lib/python3.10/concurrent/futures/_base.py", line 621, in result_iterator
    yield _result_or_cancel(fs.pop())
  File "/usr/lib/python3.10/concurrent/futures/_base.py", line 319, in _result_or_cancel
    return fut.result(timeout)
  File "/usr/lib/python3.10/concurrent/futures/_base.py", line 451, in result
    return self.__get_result()
  File "/usr/lib/python3.10/concurrent/futures/_base.py", line 403, in __get_result
    raise self._exception
  File "/usr/lib/python3.10/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/local/lib/python3.10/dist-packages/huggingface_hub/_snapshot_download.py", line 213, in _inner_hf_hub_download
    return hf_hub_download(
  File "/usr/local/lib/python3.10/dist-packages/huggingface_hub/utils/_validators.py", line 118, in _inner_fn
    return fn(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/huggingface_hub/file_download.py", line 1461, in hf_hub_download
    http_get(
  File "/usr/local/lib/python3.10/dist-packages/huggingface_hub/file_download.py", line 541, in http_get
    for chunk in r.iter_content(chunk_size=DOWNLOAD_CHUNK_SIZE):
  File "/usr/local/lib/python3.10/dist-packages/requests/models.py", line 818, in generate
    raise ChunkedEncodingError(e)
requests.exceptions.ChunkedEncodingError: ('Connection broken: IncompleteRead(4963331015 bytes read,<PHONE_NUMBER> more expected)', IncompleteRead(4963331015 bytes read,<PHONE_NUMBER> more expected))
consolidated.01.pt: 100%|██████████| 12.1G/12.1G [05:32<00:00, 36.5MB/s]
rpc error: code = DeadlineExceeded desc = context deadline exceeded%

@dev-mush wouldn't it affect it if we increase the sliding window to 8k? Since it's trained with windows of 4k, the overall scales of attention output would change.
I wonder why using a 4k sliding window would be a problem since it is a "sliding window." Even if the context size is 8k, it would still only attend to the previous 4k tokens, hence having the same effect as with 4k.

Hi @AlpinDale Thanks for reporting the bug. We just fixed it in #2088. Please install vLLM from source until we publish a new release.

@WoosukKwon that seems to have fixed the issue, but not quite. Now, the model completely ignores any tokens past the 4096 context window. Perhaps it'd be best if the sliding window value was aligned with the max model length? As in, the max_model_len arg would also change the sliding window value. Manually setting it to 32k in the config.json fixes this issue.

@AlpinDale Could you provide a reproducible example?

I ran Mixtral Model using vLLM! I found Error!

Can anyone know why?

with 32k, I am getting rpc error: code = DeadlineExceeded desc = context deadline exceeded% 8k is working though, but the garbage is still there for me :/
full traceback here:
Traceback (most recent call last):▉| 12.1G/12.1G [05:32<00:00, 40.6MB/s]
  File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main]
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/usr/local/lib/python3.10/dist-packages/vllm/entrypoints/openai/api_server.py", line 729, in <module>
    engine = AsyncLLMEngine.from_engine_args(engine_args)
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/async_llm_engine.py", line 495, in from_engine_args
    engine = cls(parallel_config.worker_use_ray,
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/async_llm_engine.py", line 269, in __init__
    self.engine = self._init_engine(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/async_llm_engine.py", line 314, in _init_engine
    return engine_class(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/llm_engine.py", line 107, in __init__
    self._init_workers_ray(placement_group)
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/llm_engine.py", line 194, in _init_workers_ray
    self._run_workers(
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/llm_engine.py", line 750, in _run_workers
    self._run_workers_in_batch(workers, method, *args, **kwargs))
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/llm_engine.py", line 727, in _run_workers_in_batch
    all_outputs = ray.get(all_outputs)
  File "/usr/local/lib/python3.10/dist-packages/ray/_private/auto_init_hook.py", line 24, in auto_init_wrapper
    return fn(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/ray/_private/client_mode_hook.py", line 103, in wrapper
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/ray/_private/worker.py", line 2563, in get
    raise value.as_instanceof_cause()
ray.exceptions.RayTaskError(ChunkedEncodingError): ray::RayWorkerVllm.execute_method() (pid=7598, ip=<IP_ADDRESS>, actor_id=9a702c3d2722e46a47e1444101000000, repr=<vllm.engine.ray_utils.RayWorkerVllm object at 0x7f1781fa3d90>)
  File "/usr/local/lib/python3.10/dist-packages/urllib3/response.py", line 833, in _raw_read
    raise IncompleteRead(self._fp_bytes_read, self.length_remaining)
urllib3.exceptions.IncompleteRead: IncompleteRead(4963331015 bytes read,<PHONE_NUMBER> more expected)

The above exception was the direct cause of the following exception:

ray::RayWorkerVllm.execute_method() (pid=7598, ip=<IP_ADDRESS>, actor_id=9a702c3d2722e46a47e1444101000000, repr=<vllm.engine.ray_utils.RayWorkerVllm object at 0x7f1781fa3d90>)
  File "/usr/local/lib/python3.10/dist-packages/requests/models.py", line 816, in generate
    yield from self.raw.stream(chunk_size, decode_content=True)
  File "/usr/local/lib/python3.10/dist-packages/urllib3/response.py", line 934, in stream
    data = self.read(amt=amt, decode_content=decode_content)
  File "/usr/local/lib/python3.10/dist-packages/urllib3/response.py", line 905, in read
    data = self._raw_read(amt)
  File "/usr/local/lib/python3.10/dist-packages/urllib3/response.py", line 811, in _raw_read
    with self._error_catcher():
  File "/usr/lib/python3.10/contextlib.py", line 153, in __exit__
    self.gen.throw(typ, value, traceback)
  File "/usr/local/lib/python3.10/dist-packages/urllib3/response.py", line 729, in _error_catcher
    raise ProtocolError(f"Connection broken: {e!r}", e) from e
urllib3.exceptions.ProtocolError: ('Connection broken: IncompleteRead(4963331015 bytes read,<PHONE_NUMBER> more expected)', IncompleteRead(4963331015 bytes read,<PHONE_NUMBER> more expected))

During handling of the above exception, another exception occurred:

ray::RayWorkerVllm.execute_method() (pid=7598, ip=<IP_ADDRESS>, actor_id=9a702c3d2722e46a47e1444101000000, repr=<vllm.engine.ray_utils.RayWorkerVllm object at 0x7f1781fa3d90>)
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/ray_utils.py", line 32, in execute_method
    return executor(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/vllm/worker/worker.py", line 72, in load_model
    self.model_runner.load_model()
  File "/usr/local/lib/python3.10/dist-packages/vllm/worker/model_runner.py", line 36, in load_model
    self.model = get_model(self.model_config)
  File "/usr/local/lib/python3.10/dist-packages/vllm/model_executor/model_loader.py", line 124, in get_model
    model.load_weights(model_config.model, model_config.download_dir,
  File "/usr/local/lib/python3.10/dist-packages/vllm/model_executor/models/mixtral.py", line 519, in load_weights
    for name, loaded_weight in hf_model_weights_iterator(
  File "/usr/local/lib/python3.10/dist-packages/vllm/model_executor/weight_utils.py", line 201, in hf_model_weights_iterator
    hf_folder, hf_weights_files, use_safetensors = prepare_hf_model_weights(
  File "/usr/local/lib/python3.10/dist-packages/vllm/model_executor/weight_utils.py", line 141, in prepare_hf_model_weights
    hf_folder = snapshot_download(model_name_or_path,
  File "/usr/local/lib/python3.10/dist-packages/huggingface_hub/utils/_validators.py", line 118, in _inner_fn
    return fn(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/huggingface_hub/_snapshot_download.py", line 238, in snapshot_download
    thread_map(
  File "/usr/local/lib/python3.10/dist-packages/tqdm/contrib/concurrent.py", line 69, in thread_map
    return _executor_map(ThreadPoolExecutor, fn, *iterables, **tqdm_kwargs)
  File "/usr/local/lib/python3.10/dist-packages/tqdm/contrib/concurrent.py", line 51, in _executor_map
    return list(tqdm_class(ex.map(fn, *iterables, chunksize=chunksize), **kwargs))
  File "/usr/local/lib/python3.10/dist-packages/tqdm/std.py", line 1170, in __iter__
    for obj in iterable:
  File "/usr/lib/python3.10/concurrent/futures/_base.py", line 621, in result_iterator
    yield _result_or_cancel(fs.pop())
  File "/usr/lib/python3.10/concurrent/futures/_base.py", line 319, in _result_or_cancel
    return fut.result(timeout)
  File "/usr/lib/python3.10/concurrent/futures/_base.py", line 451, in result
    return self.__get_result()
  File "/usr/lib/python3.10/concurrent/futures/_base.py", line 403, in __get_result
    raise self._exception
  File "/usr/lib/python3.10/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/local/lib/python3.10/dist-packages/huggingface_hub/_snapshot_download.py", line 213, in _inner_hf_hub_download
    return hf_hub_download(
  File "/usr/local/lib/python3.10/dist-packages/huggingface_hub/utils/_validators.py", line 118, in _inner_fn
    return fn(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/huggingface_hub/file_download.py", line 1461, in hf_hub_download
    http_get(
  File "/usr/local/lib/python3.10/dist-packages/huggingface_hub/file_download.py", line 541, in http_get
    for chunk in r.iter_content(chunk_size=DOWNLOAD_CHUNK_SIZE):
  File "/usr/local/lib/python3.10/dist-packages/requests/models.py", line 818, in generate
    raise ChunkedEncodingError(e)
requests.exceptions.ChunkedEncodingError: ('Connection broken: IncompleteRead(4963331015 bytes read,<PHONE_NUMBER> more expected)', IncompleteRead(4963331015 bytes read,<PHONE_NUMBER> more expected))
consolidated.01.pt: 100%|██████████| 12.1G/12.1G [05:32<00:00, 36.5MB/s]
rpc error: code = DeadlineExceeded desc = context deadline exceeded%

Hello !
I have the same error and I still don't know how to solve the problem. I'm using 2 A100 GPUs...


Pass NormalizedRepoURL in place of string url throughout

Currently the url that is passed around the code could be normalized or not. It would be much safer and clearer to pass a normalized url from the very beginning so we know that we are always working with the same url.

Changed  NormalizedRepoURL to RepoURL


Added hover effect to  Register buttons

Thank you for your contribution 🤩🤩

Please mention the following in order to get PR merged  🙌🏻🙌🏻

Kind of change this PR introduce : Hover effect is added to the create account and skip button and their font is also changed
Issue it resolves : #47
Screenshots & GitHub Page Link :

Thank you for your contribution 🤩🤩

Please mention the following in order to get PR merged 🙌🏻🙌🏻
1. Kind of change this PR introduce : Hover effect is added to the create account and skip button and their font is also changed

2. Issue it resolves : [register buttons hover #47](https://github.com/2024-SANDHYA/Blood-Buddy/issues/47)

3. Screenshots & GitHub Page Link :

Provide github page link

https://geetika005.github.io/Blood-Buddy/

can you please tell how to create that link?

can you please tell how to create that link?

You have not made any changes in the code, so they are not reflected, link is okay

Mam i had made changes in register.css file ,you can check my commits

The changes are reflected in my side

Please don't use these colors, use some contrast colors, you can refer to this to match the color contrast https://www.canva.com/colors/color-wheel/

Please check

A big no !! The colors do not look at all !! Both of them blue makes no sense with red and then the previous one too in the yellowish base. Please use some contrast knowledge maintain the theme

on hovering create account


SliceUnique: fix test line length errors reported by revive

I forgot we don't have CI integration and missed this from revive:
 ⚠  https://revive.run/r#line-length-limit  line is 130 characters, out of limit 100
  slices_test.go:13:0

v0.7.0 tagged


Cant launch any example from kubernetes

Rancher Version:
1.10
Docker Version:
1.10
OS and where are the hosts located? (cloud, bare metal, etc):
centos 7
Setup Details: (single node rancher vs. HA rancher, internal DB vs. external DB)
signle node
Environment Type: (Cattle/Kubernetes/Swarm/Mesos)
Kubernetes
Steps to Reproduce:
First i was experiencing this -> https://github.com/rancher/rancher/issues/5316#issuecomment-230128804
After few recreation of node hosts ( using same settings nothing changed) i got a setup that launched and have all service in working state ( well at least thats what rancher saying)
But then i tried to launch guestbook example and rabbitmq example. And it didnt worked.
No errors,but nothing worked.
The proper record appeared in Kubernetes\Services and Kubernetes\Replication Controllers.
E.g.
 frontend	LoadBalancer	<IP_ADDRESS>	0	80:80/tcp	name=frontend
 kubernetes	ClusterIP	<IP_ADDRESS>	0	443:443/tcp	None
 rabbitmq	ClusterIP	<IP_ADDRESS>	0	5672:5672/tcp	provider=rabbitmq
 redis-master	ClusterIP	<IP_ADDRESS>	0	6379:6379/tcp	name=redis-master
 redis-slave	ClusterIP	<IP_ADDRESS>	0	6379:6379/tcp	name=redis-slave

But they all listing 0 pods. And Kubernetes/pods also show nothing.
Im just trying to see some basic thing and how rancher works, but running into this issues. Is it so unstable?
In kubectl logs im seeing following:
 FailedCreate   Error creating: pods "redis-slave-" is forbidden: no API token found for service account default/default, retry after the
 token is automatically created and added to the service account

Dont have idea how to fix it,and what is wrong since all setup was done using rancher web interface..

I am able to unproduce this issue. I have no issues with launching examples.
Can you try changing your environment to cattle and changing it back to k8s? It will re-launch the k8s system services to see if that fixes it.

@aldarund If you still have issues, please reopen.


trulens-core 1.0.7 :snowflake:

trulens-core 1.0.7 :snowflake:
Destination channel: Snowflake
Links

PKG-5816
dev_url:        https://github.com/truera/trulens/tree/trulens-1.0.4
conda_forge:    None
pypi:           https://pypi.org/project/trulens-core/1.0.6
pypi inspector: https://inspector.pypi.io/project/trulens-core/1.0.6
related PR:

https://github.com/AnacondaRecipes/trulens-feedback-feedstock/pull/1

Explanation of changes:

new version number

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_5dp2k3epk2/clone` failed. (See above for error)
The following problems have been found:
===== ERRORS =====

clone/recipe/meta.yaml:53: missing_license_family: The recipe is missing the about/license_family key.
===== Final Report: =====
1 Error and 0 Warnings were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_c7_czkrtkq/clone` failed. (See above for error)
The following problems have been found:
===== ERRORS =====

clone/recipe/meta.yaml:21: remove_python_pinning: On arch specific packages, python deps should not be constrained.
===== Final Report: =====
1 Error and 0 Warnings were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_f6426wu3y3/clone` failed. (See above for error)
The following problems have been found:
===== ERRORS =====

clone/recipe/meta.yaml:21: remove_python_pinning: On arch specific packages, python deps should not be constrained.
===== Final Report: =====
1 Error and 0 Warnings were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_59vubr0xjg/clone` failed. (See above for error)
The following problems have been found:
===== ERRORS =====

clone/recipe/meta.yaml:21: remove_python_pinning: On arch specific packages, python deps should not be constrained.
===== Final Report: =====
1 Error and 0 Warnings were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_44ykwg9i0h/clone` failed. (See above for error)
The following problems have been found:
===== ERRORS =====

clone/recipe/meta.yaml:21: remove_python_pinning: On arch specific packages, python deps should not be constrained.
===== Final Report: =====
1 Error and 0 Warnings were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_97c5jxfi9s/clone` failed. (See above for error)
The following problems have been found:
===== ERRORS =====

clone/recipe/meta.yaml:21: remove_python_pinning: On arch specific packages, python deps should not be constrained.
===== Final Report: =====
1 Error and 0 Warnings were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_ea5gixuxh4/clone` failed. (See above for error)
The following problems have been found:
===== ERRORS =====

clone/recipe/meta.yaml:21: remove_python_pinning: On arch specific packages, python deps should not be constrained.
===== Final Report: =====
1 Error and 0 Warnings were found


providers: Set the size of EC signature on s390.

The s390x provides its custom implementation for the creation of the
ed448 and ed25519 signatures. Unfortunately it does not set the size.
Users that rely of this return parameter end up with wrong values and
will compare wrong sizes of signature.
Set the proper size of the returned signature on success. Set an error
if the signing operation fails.
Fixes: #18912
Signed-off-by: Sebastian Andrzej Siewior<EMAIL_ADDRESS>

I didn't add a test for that. If someone gives me a tiny hint where/ how this can added, probably by extending an additional ed25519 / ed448 test then I will follow ;)

Nice catch.  Looks good to me.

I didn't add a test for that. If someone gives me a tiny hint where/ how this can added, probably by extending an additional ed25519 / ed448 test then I will follow ;)

I imagine that resetting gotlen to 0 in between the first and second calls to EVP_DigestSign in the following test would have caught this:
https://github.com/openssl/openssl/blob/4842a27b902660b672d72d2ed23e941461ca481c/test/evp_test.c#L3400-L3429
For bonus points making the same change between the first and second calls to EVP_DigestSignFinal in the following code might catch the same problem in other algs.
https://github.com/openssl/openssl/blob/4842a27b902660b672d72d2ed23e941461ca481c/test/evp_test.c#L3318-L3351

Setting got_len 0 fails because for edd25519 it must not be less than what is expected. Doubling works and it detects the s390 bug.

@tmshort I added the "branch: 3.0" label, since the original report (#18912) specifically mentions that branch as having the problem. Can you reconfirm that you are ok to backport this to 3.0?

@mattcaswell, I'm good with 3.0.

This pull request is ready to merge

Merged to master and openssl-3.0 branches. Thank you for your contribution!


any plugins to keep two tabs open at same time for demo purpose?

No idea.
You might get better answers on the Zeit Slack. They have a dedicated channel for Hyper.


[BUG] lombok.NonNull handled differently from checkerframework.NonNull

Describe the bug
Hi. lombok.NonNull is handled differently from checkerframework.NonNull. lomboks @NonNull works on Constructors and method parameters. Checkerframeworks @NonNull only works on constructors.
To Reproduce
Given this class:
import lombok.Value;
import org.checkerframework.checker.nullness.qual.NonNull;

@Value
class Test {
    @lombok.NonNull String lombokNonNull;
    @NonNull String checkerNonNull;

    public void<EMAIL_ADDRESS>String foo) {
        System.out.println(foo);
    }

    public void checkerNonNull(@NonNull String foo) {
        System.out.println(foo);
    }
}

This
new Test(null, "non-null");

fails with a NPE, expected and great. (testing lomboks @NonNull on ctor)
This
new Test("non-null", null);

also fails with a NPE, which proves that lombok has some handling of checkerframeworks @NonNull. (testing checkerframeworks @NonNull on ctor)
this:
new Test("", "").lombokNonNull(null);

fails with a NPE, expected and great. (testing lomboks @NonNull on methods)
But:
new Test("", "").checkerNonNull(null);

doesn't fail with a NPE. (testing checkerframeworks @NonNull on methods)
Expected behavior
I would expect that checkerframeworks @NonNull either works on the constructor and on the method or it doesn't work in either case. That it works on constructor but not on methods is strange.
It would be great if the checkerframework @NonNull is applicable everywhere where lomboks @NonNull works.
Version info (please complete the following information):

Lombok 1.18.12
javac OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.7+10, mixed mode)

I agree that this behaviour is a little bit confusing. In general lombok only modifies/creates stuff that is annotated and  checkerNonNull is actually a normal method that works without lombok.
I think there are multiple solutions:

Use Accessors (this might work only in this example)
Use both annotations at the same time
Remove the generated null check for non-lombok @NonNull annotations. This will most likely break some stuff.
Modify lombok to also add null checks for all the other annotations. This might be even more confusing as it modifies classes without a single lombok annotation.
Modify lombok to add @NonNull checker framework annotation if its own @NonNull annotation is present. Thats something thats already there for some other handlers.
Use meta annotations (#557)

Disclaimer: I'm not a project owner.

So far, our reasoning was:

If a field is annotated with any NonNull, the intention is 100% clear. We can add null-checks to constructors and setters.
If we would insert null-checks for external NonNull annotations, we're not 100% certain that that's what expected.

Currently, if you've configured you're using the checker framework in lombok.config, we generate a lot of checker framework annotations to help with static analysis. I'm not sure if the org.checkerframework.checker.nullness.qual.NonNull is one of them, but we could.


Memory leak loading keras model in loop

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): No
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Ubuntu
TensorFlow installed from (source or binary): binary
TensorFlow version (use command below):2.2
Python version:3.7

Problem Statement
Running the following code:
import tensorflow as tf
def process_start():
  model = tf.keras.models.load_model(r"/large/model/file")
while True:
  process_start()

Crashes my VM after some time due to OOM. Takes about 40m with a 4gb VM.

I also get these messages:
Two checkpoint references resolved to different objects (<tensorflow.python.keras.layers.core.Dense object at 0x7f24557770d0> and <tensorflow.python.keras.layers.core.Dropout object at 0x7f2455771750>).
WARNING:tensorflow:Inconsistent references when loading the checkpoint into this object graph. Either the Trackable object references in the Python program have changed in an incompatible way, or the checkpoint was generated in an incompatible program.

Describe the expected behavior
Should be able to run this in loops as needed.
More info
I saw from https://github.com/tensorflow/tensorflow/issues/24695 that Keras Layers are numbered globally within the Python process. My guess is that every time the model is loaded it's assigning some variables that don't get properly cleaned up.
I believe this is a bug. Is there a suggested workaround or advice here?

@danzafar
Please share all dependencies for us to replicate the issue faced, I ran the code shared and face this error.


Update _reference.mdx

🚀 Deployed on https://66b29c6de3458b08399c2732--cozy-fox-0defec.netlify.app


Design balancio v0.7 with lower center of mass and higher moment of inertia

[x] Design
[x] Test

Works great!


black screen instead of video screen

Do you want to request a feature or report a bug?
Bug.

What is the current behavior?
When I'll insert a video in Augmented Reality only a black screen appears on the display. The video doesn't appear.
If the current behavior is a bug, please provide the steps to reproduce.
In the next message my code is given

Please mention other relevant information such as the browser version, Operating System and Device Name
Chrome: Version 80.0.3987.163 (Offizieller Build) (64-Bit), Windows 10 Education,
What is the expected behavior?
I don't know
If this is a feature request, what is motivation or use case for changing the behavior?

Hello I have a probleme. When I'll insert a video in Augmented Reality only a black screen appears on the display.
Can you help me, please?
There's my code:
<!doctype HTML>
<html>
<script src="https://aframe.io/releases/0.6.1/aframe.min.js"></script>
<script src="https://cdn.rawgit.com/jeromeetienne/AR.js/1.5.0/aframe/build/aframe-ar.js">
</script>

<body style='margin : 0px; overflow: hidden;'>
    <a-scene embedded arjs>
        <a-marker preset="hiro">
            <a-video position='0 0.1 0' rotation='270 0 0' scale='1 0.5 1' src='/sv.mp4'></a-video>
        </a-marker>
        <a-entity camera></a-entity>
    </a-scene>
</body>

</html>

I am just getting a black screen instead of video.

I'd look at the video example in the examples folder, I wouldn't load in the video via src and use the a-assets component instead. You'd also need to make sure it's muted for it to autoplay due to browser limitations.


Titer table correction, redo map and map plots with corrected table

Prior table had duplicated sample names, resulting in different GMTs from the titer table than from the excel sheet. That is corrected now and maps, landscapes, were redone with the corrected titer table.
The fold drop from homologous plot was adapted to not estimate fold drops, but calculate them from the data, and to also show the drop combining pseudo types and live-virus neutralisation data.

Fold change in LV, PV now calculated per study and mean is taken from there. Not estimated or calculated as GMT fold change (before). 95%CIs are shown in the figure.


Introducing auto_install.sh

Objective:
This PR introduces an automated setup script (auto_install.sh) designed to streamline the installation process of Axolotl. It addresses common challenges faced by users not utilizing Docker, particularly in configuring the correct CUDA, PyTorch versions, and related dependencies. This enhancement is motivated by community feedback highlighting difficulties in manual setup processes.
Features and Implementation:

Conda Environment Setup: Automatically checks for an existing Conda installation and proceeds to install Conda if it's not found, ensuring a controlled setup environment.
CUDA Version Management: Installs a specific CUDA version within the Conda environment tailored for compatibility, addressing common version mismatch issues.
PyTorch Ecosystem Compatibility: Ensures the installation of PyTorch, TorchAudio, and TorchVision that are compatible with the selected CUDA version, mitigating dependency conflicts.
Axolotl Dependencies: Automatically installs all required dependencies for Axolotl, facilitating a smoother setup experience.

Planned Enhancements:

OS-Specific Installation: Currently it supports Linux only however, future iterations will aim to automatically identify the operating system and adjust the CUDA installation and other dependencies accordingly.
Docker Support Argument: Incorporate an option to install Docker if required by the user, enhancing flexibility for users preferring containerized environments.
Installation Validation: Introduce a simple test script capable of running a small model on a dataset of 500 samples to verify the correctness of the installation and operational integrity of Axolotl post-setup.

Note: This script presents an additional option for users seeking an easier installation route without mandating its use. Users retain the freedom to choose their preferred installation method. The primary goal of this script is to reduce setup time and complexity, offering an alternative to manual configuration.

I am a bit opposed to the auto install being at the root, while it covers the "common" use case, there is a growing variety of setups (ROCm, MPS, XPU...)
I also think that there is no need for such a script as the docker images cover the difficult part of setting it up. So I am not sure who this helps, power users already have a conda install and most likely the correct pytorch version. End users should just pull the docker image.

I am a bit opposed to the auto install being at the root, while it covers the "common" use case, there is a growing variety of setups (ROCm, MPS, XPU...)
I also think that there is no need for such a script as the docker images cover the difficult part of setting it up. So I am not sure who this helps, power users already have a conda install and most likely the correct pytorch version. End users should just pull the docker image.

You make a fair case that the Docker images likely cover much of the complexity for many users. However, as you rightly mentioned, not all users currently utilize Docker. I recently came across several incidents on Discord and elsewhere where users faced issues installing Axolotl, for example this popular  Reddit post Reddit post, where a user faced frustration while installing Axolotl. This inspired me to consider simplifying the initial setup process for those who could benefit.
Moreover, it would just serve as an additional option for users - they could follow other methods if they prefer

Gemma config change and auto setup should be two different PR, so they don't go in together.
Also, please add some documentation that this autoconfig is only for linux.

Gemma config change and auto setup should be two different PR, so they don't go in together.
Also, please add some documentation that this autoconfig is only for linux.

Done!

Thanks @monk1337, I do find value in having this script as having docker adds another layer of complexity over a native install. I do worry that having a script adds another point of maintenance/testing/support. Currently our docker images are well tested as we typically run tests against the built images themselves.
I think a good compromise would be to indicate that the install script itself is "beta" and have a date somewhere where it was last updated/tested, just for visibility to end users.


make ThreadLocalBuildableTestHelper deal with inherited fields

@speezepearson there appear to be some tests. Are there some that are missing?

Nope! That comment was just out of date: coverage made me add them.


add feature kconnect logout

Describe the solution you'd like:
Provide option to logout from current logged-in cluster. $ kconnect logout should just clear the auth creds, e.g. in EKS just clear AWS sts token.
Why do you want this feature:
kconnect helps connecting multiple clusters & sometime unintentionally kubectl run might cause unintentional change to the existing cluster. kconnect logout can help cluster admins to logout from cluster.
Anything else you would like to add:
No

Great idea :)

Thanks @ashishapy - a very good idea.


Can't get replaced input with "only" method

Laravel Version: 5.3.30
PHP Version: 5.6.4
Database Driver & Version: MySQL & MariaDB 10.1.17

Description:
When trying to get replaced input with $request->only() method it returns the original value.
Steps To Reproduce:
In form request.
public function all()
{
        $input = parent::all();
        $input['birthday'] = 'Replaced Value';
        $this->replace($input);
        return parent::all();
}

In controller.
$request->input('birthday'); // returns replaced value, works fine
$request->only('birthday'); // returns original value

Because you return return parent::all(); at the end of your overridden all().
Please ask on the forums, this repo is for bug reporting only.

All right. Sorry for bothering you but what about this?
The original all() method of Illuminate\Http\Request is below.
public function all()
{
        return array_replace_recursive($this->input(), $this->allFiles());
}

If we are talking about inheritance. This override should work as I expected. Bu it is not.
public function all()
{
        $input = array_replace_recursive($this->input(), $this->allFiles());
        $input['birthday'] = 'Replaced Value';
        $this->replace($input);
        return array_replace_recursive($this->input(), $this->allFiles());
}

This seem odd to me. Anyway, I ve done it differently.  Peace :v:


Group hasn't lights property

class Group check lights attribute, but don't hold it.
if (!this._attributes.lights) {
   throw new ApiError('Missing a valid lights attribute for the Group');
}

It's a normal behavior, or a bug?

I think any type of group has a lights attribute. Maybe getter for lights should be in Group class?

Group is abstract, it has specializations, and only those are instantiable. The specializations have the lights attribute, which changes based on the type, e.g. room does not require any lights to be defined, where as a light group does.
How are you encountering this error?

I do not consider this a mistake.
This check
Just this code return array with abstract Groups. But abstract Group hasn't lights attribute. But all real classes has. I think it would be more convenient to provide get lights to group interface.
For example
const groups = await hueApi.groups.getAll(); // Array<Groups> without .lights

It is a mistake, as I transitioned group to be abstract. The 4.x versions should not ever return a base group instance. That check is there to ensure that the instances implement the correct constraints on a group.
How are you managing to get this error, as the api should only ever return an implementation of one of the specializations.

Sorry. I didn't get error. It works fine. Just model Group hasn't lights getter. But all derived classes have. And abstract Group "knows" about light attribute. I think that make get lights() in class Group is a good idea, despite the fact that all derived classes reimplement it. Because get lights() is a part of Group interface.

This is intentional, a user should never get one of these instances now, as the types from the bridge itself will be instantiated.
It is done this way due to the lights attribute being required in some groups and not others, but without a lot of hacking of the type system in use to support this one edge case, where I would like to toggle the required state on the attribute, it is just considerably easier to ensure that the concrete classes pass the attribute for the lights configured to what it wants.
This is in line with what I had to do in some of the sensor based objects as well.

I understand. Thanks for fast answer.

Its the TypeScript definition that is not right here, I will update it.
Thanks.

Updated in 4.0.3


屏蔽warning

怎样屏蔽这些碍眼的warning，另外fool也警告了，需要注意哦。
np_quint8 = np.dtype([("quint8", np.uint8, 1)])
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/tensorboard/compat/tensorflow_stub/dtypes.py:543: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
_np_qint16 = np.dtype([("qint16", np.int16, 1)])
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/tensorboard/compat/tensorflow_stub/dtypes.py:544: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
_np_quint16 = np.dtype([("quint16", np.uint16, 1)])
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/tensorboard/compat/tensorflow_stub/dtypes.py:545: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
_np_qint32 = np.dtype([("qint32", np.int32, 1)])
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/tensorboard/compat/tensorflow_stub/dtypes.py:550: FutureWarning: Passing (type, 1) or '1type' as a synonym of type is deprecated; in a future version of numpy, it will be understood as (type, (1,)) / '(1,)type'.
np_resource = np.dtype([("resource", np.ubyte, 1)])
WARNING: Logging before flag parsing goes to stderr.
W0804 17:59:34.962490<PHONE_NUMBER>98080 deprecation_wrapper.py:119] From /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/fool/predictor.py:32: The name tf.gfile.GFile is deprecated. Please use tf.io.gfile.GFile instead.
W0804 17:59:34.962846<PHONE_NUMBER>98080 deprecation_wrapper.py:119] From /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/fool/predictor.py:33: The name tf.GraphDef is deprecated. Please use tf.compat.v1.GraphDef instead.
W0804 17:59:35.032593<PHONE_NUMBER>98080 deprecation_wrapper.py:119] From /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/fool/predictor.py:53: The name tf.Session is deprecated. Please use tf.compat.v1.Session instead.
2019-08-04 17:59:35.033006: I tensorflow/core/platform/cpu_feature_guard.cc:142] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2 FMA

tensorflow 的版本太高


MM-39148 -subscription page, for flat fee plan details not show user/month, show only /month

Summary
This PR fixes a typo so in the cloud subscription pages, for the flat fee products, like starter, when defining the billing schema show only price / month.
Ticket Link
https://mattermost.atlassian.net/browse/MM-39148
Screenshots
Release Note
NONE

/cherry-pick cloud

Error trying doing the automated Cherry picking. Please do this manually
+++ Updating remotes...
Fetching upstream
Failed to add the RSA host key for IP address '<IP_ADDRESS>' to the list of known hosts (/app/.ssh/known_hosts).
From github.com:mattermost/mattermost-webapp
   5e8a49c9c..3ee29f896  MM-25966               -> upstream/MM-25966
   e4e0905ae..3f368b8aa  MM-38134-change-first-purchase-success-screen-texts -> upstream/MM-38134-change-first-purchase-success-screen-texts
   c1914f953..967d2af7b  MM-38239-10-4-progress -> upstream/MM-38239-10-4-progress
   efdb1f8be..10c839486  MM-38289               -> upstream/MM-38289
   d3dac06eb..2384e52a3  MM-38957               -> upstream/MM-38957
   834deaa00..cf7df50d4  bugfix/e2e_accessibility-label-fix -> upstream/bugfix/e2e_accessibility-label-fix
   6527051a5..d218444c7  channel-license-check-fix -> upstream/channel-license-check-fix
   4d9a82276..dc36a7048  cloud                  -> upstream/cloud
   70235a623..85d679909  master                 -> upstream/master
   02b210b5f..3f85c6c5b  release-6.0            -> upstream/release-6.0
   abd9d1103..723679a2a  small-ux-bugs          -> upstream/small-ux-bugs
   e517aea8c..c6fea7fd7  time                   -> upstream/time
Fetching origin
Failed to add the RSA host key for IP address '<IP_ADDRESS>' to the list of known hosts (/app/.ssh/known_hosts).
+++ Updating remotes done...
!!! 'upstream/`cloud`' not found. The second argument should be something like upstream/release-0.21.
    (In particular, it needs to be a valid, existing remote branch that I can 'git checkout'.)

+++ Returning you to the master branch and cleaning up.


CI/CD related documentation suggestion

Is your feature request related to a problem? Please describe.
We experienced following situation on our project which uses the Continuous Deployment feature and tag manager:

the tag manager was successfully deployed on production environment
we configured some tracking scripts on production environment
after next production deployment done by CI/CD pipeline all tracking scripts were lost

The issue was caused by the CD restore. We fixed it by ignoring kenticotagmanager.channelcodesnippet and kenticotagmanager.channelcodesnippetitem in CD repository.config file.
Because there are usually some differences between production a dev site tag manager configurations this situation could happen to other developers.
Describe the solution you'd like
Add a friendly warning to the readme.md, which tells developers to consider excluding the kenticotagmanager objects in CD repository.config.

Hi! Thanks for sharing your problem and a solution! We'll take a look at it soon and consider adding it to the original integration.

The suggestion has been added in the following pr: https://github.com/Kentico/xperience-by-kentico-tag-manager/pull/36


[Slider] Touch - Increased touch area of the slider handler

Part of #2943

@alexdrel the styles you removed for when the handle is in percent zero are part of the material design specs.

@newoga  What do you think about this PR? It removed some of the styles that were part of the spec for the slider. The way it increases the slider using a padding area works, but maybe it is a little bit intrusive, I mean:
rippleWhenPercentZero: {
 -        top: -this.getTheme().trackSize,
 -        left: -this.getTheme().trackSize,
 +        top: this.getTheme().handleSize,
 +        left: this.getTheme().handleSize,

Since now the handle has padding, the styles need to take that in consideration as above. For example, for what I understand from this part of the code, the trackSize is two pixels wide, and the border used in the handle when it is at percent zero is also 2 pixels wide (that is why originally we move it -2px on the top and left). Since the border was removed in this PR (going against the specs) and a padding of the size of the handle was added the code needs to become what you see above. To sum it up, if we use this padding approach and add the border again we would have something like (didn't test it though):
top: this.getTheme().handleSize - this.getTheme().trackSize,
left: this.getTheme().handleSize - this.getTheme().trackSize

Thats is why I consider the padding approach intrusive.

@felipethome Thanks for reviewing this PR! :+1:
Yeah, that's a valid point. I can see this being error prone/tougher to maintain. I'm not sure if there are any other approaches unless we solve this with JS event handlers instead of styles (something that I think would be an overkill). I'll have to think about this some more but if you have any ideas let me know.

I just tested the slider examples on the docs site on an iPad and can confirm that the thumb is really hard to move around. I think we need to do something about this. I found generally clicking the "slider line" to change the value was pretty difficult too.

Well actually the PR #3128 solves it in a nice way. It creates a div that is child of the handle and gives to it negative top, left, bottom and right values. A lot of people (like me before seeing the other PR) think that when you use top and left, you can't use right and bottom for example. It turns out you can and what the browser do is stretch the element from outside the parent frontiers. I believe it is a nice idea, though as I said in the other PR I think it is more valid to increase the slider areas for the entire component (track and handle) and let the user choose how much pixels wide he would like to be the touch/click area.

Oh sorry, I totally forgot we had a second PR for this. Thanks for investigating this and indeed that approach seems like a better alternative. I'll look into that PR and your link.

Closing in favour of #3128.
@alexdrel Thanks for contributing :+1: and sorry we couldn't use this.


Add support for attributes

As far as I can tell, this library does not include support for reading/writing/deleting attributes ( https://www.hdfgroup.org/HDF5/doc1.6/UG/13_Attributes.html )
While it's not clean or complete, I was able to create attributes of type Double on groups by adding this code to Group.swift:
    /// Create an attribute
    public func createAttribute(name: String) -> hid_t {
        let dataspace = Dataspace.init(dims: [1, 1])
        let datatype = Datatype(type: Double.self)!
        let attributeId = name.withCString{
            return H5Acreate2(id, $0, datatype.id, dataspace.id, 0, 0)
        }
        return attributeId
    }

    /// Write an attribute
    public func writeAttribute(attributeId: hid_t, value: Double) {
        let datatype = Datatype(type: Double.self)!
        var cValue = CDouble(value)
        H5Awrite(attributeId, datatype.id, &cValue)
    }

    /// Close an attribute
    public func closeAttribute(attributeId: hid_t) {
        H5Aclose(attributeId)
    }

Done!

How to get the attribute name (key) and values for each File instance?


use pydantic tagged unions to more quickly validate the result document

In our result document JSON document, we use unions in a few places, such as freeze.features.Feature:
https://github.com/mandiant/capa/blob/c409b2b7ed7f5f2a9c3b9efc9e75dd5779205576/capa/features/freeze/features.py#L351

I've learned that to validate incoming data against this union, pydantic will loop through each case and then use the best match. because there are lots of cases, pydantic does a lot of work.
we should be able to improve performance by using tagged unions. there's a bit of documentation here:
https://docs.pydantic.dev/latest/concepts/unions/#discriminated-unions
and a PyCon US '24 talk here: https://www.youtube.com/watch?v=Qvj5e9xtaSE
we should investigate using tagged unions and see if it improves performance of loading serialized result documents. granted, this isn't a common operation, but the data model would be more correct regardless.

I think this would do it:
Feature = Annotated[Union[
    OSFeature,
    ArchFeature,
    ...
    BasicBlockFeature,
], Field(discriminator='type')]


Question about Racon Rounds

Hello, I have a naive question about Ra.
How many rounds of Racon does it implement during the whole process of assembly construction ?
Thank you for your time

Hello,
Ra employs two iterations of Racon with long reads, and one iterations with short reads if present.
Sorry for the late reply!
Best regards,
Robert

Thank you for your reply


sell all Inventory bug

Inventory sales do not count if any fish is on your sales menu and ends up excluding what is inside and only what is in the inventory is sold.

Hi there, apologies for the late response, this is fixed in the latest build and will be included in the next spigot release. Thank you very much for reporting it though :) If you'd like the build earlier feel free to message me on the discord server or compile the code yourself.

Oheers


Problem with g-image when building in Netlify

Description
Hi guys,
I'm developing my blog using Gridsome and Netlify.
However, I have a problem when using g-image.
Locally everything works fine, when I do a query, all the image data is retrieved.
However, when the site is building on Netlify servers, an error appears if the source for the g-image is used because it has a value null.
Everything else is fine.
Expected result
This is what I get locally and what I should retrieve when building on Netlify servers.
"id": "43333a7b67f6f37dcd60b7efd9934d46",
"path": "/gallery/gallery-2/",
"title": "gallery-2",
"cover": {
    "type": "image",
    "mimeType": "image/jpeg",
    "src": "/assets/static/static/galleries/gallery-2/Indonesie-4.jpg?width=1500&fit=cover&key=345c148",
    "size": {
                "width": 1500,
                "height": 1125
              },
    "sizes": "(max-width: 1500px) 100vw, 1500px",
    "srcset": [
                "/assets/static/static/galleries/gallery-2/Indonesie-4.jpg?width=480&fit=cover&key=345c148 480w",
                "/assets/static/static/galleries/gallery-2/Indonesie-4.jpg?width=1024&fit=cover&key=345c148 1024w",
                "/assets/static/static/galleries/gallery-2/Indonesie-4.jpg?width=1500&fit=cover&key=345c148 1500w"
              ],
    "dataUri": "data:image/svg+xml,%3csvg fill='none' viewBox='0 0 1500 1125' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink'%3e%3cdefs%3e%3cfilter id='__svg-blur-ef963766ede03ea9f8454992983feecb'%3e%3cfeGaussianBlur in='SourceGraphic' stdDeviation='40'/%3e%3c/filter%3e%3c/defs%3e%3cimage x='0' y='0' filter='url(%23__svg-blur-ef963766ede03ea9f8454992983feecb)' width='1500' height='1125' xlink:href='data:image/jpeg%3bbase64%2c/9j/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcUFhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAARCAAwAEADASIAAhEBAxEB/8QAHAAAAgIDAQEAAAAAAAAAAAAABQYDBAECCAcA/8QALxAAAgEDAgQEBQQDAAAAAAAAAQIDAAQRBRIGEyExByJBUUJhcYGRFDKh0VKi4f/EABkBAAIDAQAAAAAAAAAAAAAAAAABAgMFBP/EAB8RAAMAAgICAwAAAAAAAAAAAAABAgMREiETQTFRUv/aAAwDAQACEQMRAD8ANeJl8dH4K1K8t5WjnMYiiZGwys5ABH5NCPBHVb294XMl3eSzTR3DxBpX3NtwpAyevqaWfHC/ZeHNPtCTvuLgu2T3VF/thVzwHhmn4XvVjj3ot2csO6%2bRTRvU7ZLjutI9vjuE5KyTbVkzgAnvX1xOzIGwME9MVDbcJ3MtrHKkoKsu7axzVL9DPaTIGjZ1HoSR%2bKissjeCiS6l2oVXqx7/ACpfvJpBnB6e1HZHPUcnPp3oZc28jHcU2/IUK%2bx1j66AjK7q2717ULuoWBwVP3pkePb5s9RVC7jEgOSBViopcHNut8RarrkkT6vI9yYgQm5QAoPfAAGKZeAfEDUuD4ZUsbW3mglk5rpLuBzjHQg9untSIsheLLgq3XoDW0UzJCGweYfhJocprTJqmntHf/DWoi%2b4f066gnws8KTbUUAeZQ3370QuOVcJtmwR9a5o8EeP7iGzuNI1Od3itkV7YnqVTsU%2bg6EV6Y/H%2bnC9FqZ2E3J537em3dt7%2b%2bazL8kU50auPx3Krloep7e2jUlIwT8qX74MWIEPloHLxxY9jcqCffNV5eLrJu9ylCq/ok5x/pE9zbPk4Qj6mhV1aM37io%2blR6jxZp1tbmee6VIshd2CepOB2%2bZqrdaxblSecMe9XTde0UXjj0zlkwliJCwxjoM1kOrFZQWwg7VGJgWMYXoB9qzbFjMEAGzHWu4zRg0a/k04zTW/leVRl2z0BYEj/UfmiUnF0r6yb0W8C5h5OzcxAGc5oJYtGHkSZtyN0GPhBHeq1xaGC4wWWRf8l9f6oGOtrxHztG5M0iR3UQCbj3kGCSR/FD9M19nv3N02yOTs27JTA7fxQKOB5xm0jEuB5selarbXCsA1uUB%2bJhgD70tIPkN8T6w9wxtoHJhUht%2bciQ9CCPkMUYj1qCbTv1LS7X25kTOSp/7SBeb43JGa0gkYvtJAB6HOcUxNH//Z' /%3e%3c/svg%3e"
            }

Actual result
However, this is what I get when building.
"id": "43333a7b67f6f37dcd60b7efd9934d46",
"path": "/gallery/gallery-2/",
"title": "gallery-2",
"cover": null

Environment
Here is the component in which the data acquired from the query is used.
<template>

{{ gallery }}

</template>

The commented part is what I actually want to do, but it triggers the error so I commented it and I displayed galleries in order to see what is retrieved by the query and what is displayed on the web page is what I added under Actual result.
Here is the query I make:
<page-query>
query{
 galleries: allGallery{
    edges{
      node{
        id
        title
        path
        cover
      }
    }
  }
}
</page-query>

Gridsome info:
System:
    OS: macOS 10.15.2
    CPU: (8) x64 Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
  Binaries:
    Node: 12.4.0 - /usr/local/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.4 - /usr/local/bin/npm
  Browsers:
    Firefox: 75.0
    Safari: 13.0.4
  npmPackages:
    @gridsome/plugin-google-analytics: ^0.1.0 => 0.1.0
    @gridsome/remark-prismjs: ^0.2.0 => 0.2.0
    @gridsome/source-filesystem: ^0.6.0 => 0.6.2
    @gridsome/transformer-remark: ^0.3.0 => 0.3.4
    gridsome: ^0.7.0 => 0.7.13

Hope I wrote the issue in an appropriate way. It is one of my first time writing one.
Many thanks in advance!

Well, after looking all day and after writing this issue I finally found the problem. ^^
It turns out that your images should not be in the static folder but in another directory at the root of your project if you are using g-image.
This worked for me, maye it'll help someone else with same problem.
I guess I can close the issue now :)


fix(ffe-checkbox-react): Fix hidden label boxes

The first iteration of the <Checkbox> component with the hiddenLabel
modifier replaced the <label> element with a <span>. This of course
breaks the link between the label and the input element meaning no click
event was ever going to make it to it's intended destination.

Coverage decreased (-0.03%) to 80.019% when pulling f6d5c7f19faf635835f0568d719be4235822c771 on ivarni:fix-checkbug into 6a12c672deb84c8c21b1ad15b4ef7f48302a5223 on SpareBank1:develop.

So.. is that coverage check a tad bit strict?

Ah, that one was subtle. Thanks for the fix.
Regarding the coverage requirement, seems like it's too strict in this case. The coverage for the component is still 100% :/ OTOH I'd rather not reduce it to avoid "death by a thousand cuts" if coverage for a component does in fact go down. An admin can override it - I'll just do that in this case.


The implementation of Feature Envy is not correct

I noticed that a very large portion of methods is flagged as Feature Envy.
Looking at the implementation of MethodLocalityRatioCalculator
it seems you are aggregating the method calls to all foreign classes.
(foreign is not a proper name btw)
protected Double computeValue(ASTNode target) {
		MethodCallLocalityVisitor visitor = new MethodCallLocalityVisitor(declaringClass);
		target.accept(visitor);
		Double localCalls = visitor.getLocalMethodsCallCount().doubleValue();
		Double foreignCalls = visitor.getForeignMethodsCallCount().doubleValue();
		if ((localCalls + foreignCalls) == 0) {
			return null;
		}
		return localCalls / (localCalls + foreignCalls);
}

Instead a proper implementation should simply compare if the method calls to each individual foreign class are more than the internal method calls.
Additionally, it's not clear if foreign calls include only system classes or even external library classes.
The classes that do not belong to the system under analysis should be excluded.

Thanks for reporting. I'll fix the bug.

Finally I could spend some time in this. Now I think the algorithm is correct. Details of the implementation can be found in the commit message.


Added randomized selection algorithm

Have you read the Contributing Guidelines on Pull Requests?
YES
(Write your answer here.)
Description
Added Randomized_Select.cpp in C-Plus-Plus/search and updated the appropriate README.md file
(Write your answer here.)
Checklist

[x] I've read the contribution guidelines.
[x] I've checked the issue list before deciding what to submit.
[x] I've edited the README.md and link to my code.

Related Issues or Pull Requests
#471
(Write your answer here.)

This pull request is as a participant of CH20

I have solved the merge conflict and added sample input/output. Please review the changes.

Resolve the merge conflict so that I can merge this PR.

Resolved the conflicts. Please accept my apologies for responding so late.


@Page[] enricher in Actor notes

Is your feature request related to a problem? Please describe.
Using the @Page[] enricher in an Actor's notes does not insert the linked journal page.
Describe the solution you'd like
It would be really great if this worked. I have journal entries for all my NPC characters, and I'd like to insert that page into their Actor notes so it can easily be see in both places.

Hey, I'm sorry for the late response. I'll look into that as soon as I'm able to work on LMJE again, thank you for your bugreport!

 P1: @Page[] doesn't work in Character Sheets


LeaderElection related bug on version 4.0.3

Bug Report

What did you do?

I just tried to stop running operator.

It is integrated with Spring Boot 2.7.3
Version of java-operator-sdk is 4.0.3.
It has a leader election configuration like below.

val operator = Operator(kubernetesClient) {
    it.withLeaderElectionConfiguration(
        LeaderElectionConfiguration(
            LEASE_NAME,
            POD_NAMESPACE,
            POD_NAME,
        ),
    )
}

What did you expect to see?

Should be shut down without error message like below. (Below logs are generated from Operator SDK 3.2.3)
2022-10-31 17:06:51.409  INFO 32006 --- [ionShutdownHook] io.javaoperatorsdk.operator.Operator     : Operator SDK 3.2.3 is shutting down...
2022-10-31 17:06:51.409  INFO 32006 --- [ionShutdownHook] i.j.o.p.e.s.informer.InformerManager     : Stopping informer io.javaoperatorsdk.operator.processing.event.source.informer.InformerManager@3878a961 -> io.javaoperatorsdk.operator.processing.event.source.informer.InformerWrapper@718e157f
2022-10-31 17:06:51.410  INFO 32006 --- [ionShutdownHook] i.j.o.p.e.s.informer.InformerManager     : Stopping informer io.javaoperatorsdk.operator.processing.event.source.informer.InformerManager@6891ce7c -> io.javaoperatorsdk.operator.processing.event.source.informer.InformerWrapper@5381736d
2022-10-31 17:06:51.410  INFO 32006 --- [ionShutdownHook] i.j.o.p.e.s.informer.InformerManager     : Stopping informer io.javaoperatorsdk.operator.processing.event.source.informer.InformerManager@1fc3b1b9 -> io.javaoperatorsdk.operator.processing.event.source.informer.InformerWrapper@768877d5

What did you see instead? Under which circumstances?

Operator framework throws an error message "Unable to update LeaseLock" like below.
2022-10-31 16:51:55.476  INFO 30444 --- [ionShutdownHook] io.javaoperatorsdk.operator.Operator     : Operator SDK 4.0.3 is shutting down...
2022-10-31 16:51:55.476  INFO 30444 --- [ionShutdownHook] i.j.o.p.e.s.informer.InformerManager     : Stopping InformerManager [samples.sample.navercorp.com/v1alpha1] watching: [JOSDK_ALL_NAMESPACES] selector:
2022-10-31 16:51:55.478  INFO 30444 --- [ionShutdownHook] i.j.o.p.e.s.informer.InformerManager     : Stopping InformerManager [configmaps/v1] watching: [JOSDK_ALL_NAMESPACES] selector: app.kubernetes.io/managed-by=sample-operator-20220929-181845
2022-10-31 16:51:55.478  INFO 30444 --- [ionShutdownHook] i.j.o.p.e.s.informer.InformerManager     : Stopping InformerManager [statefulsets.apps/v1] watching: [JOSDK_ALL_NAMESPACES] selector: app.kubernetes.io/managed-by=sample-operator-20220929-181845
2022-10-31 16:51:55.758 ERROR 30444 --- [ionShutdownHook] i.f.k.c.e.leaderelection.LeaderElector   : Exception occurred while releasing lock 'LeaseLock: sample-operator - sample-operator-leader-election (local)'

io.fabric8.kubernetes.client.extended.leaderelection.resourcelock.LockException: Unable to update LeaseLock
	at io.fabric8.kubernetes.client.extended.leaderelection.resourcelock.LeaseLock.update(LeaseLock.java:102) ~[kubernetes-client-api-6.2.0.jar:na]
	at io.fabric8.kubernetes.client.extended.leaderelection.LeaderElector.release(LeaderElector.java:139) ~[kubernetes-client-api-6.2.0.jar:na]
	at io.fabric8.kubernetes.client.extended.leaderelection.LeaderElector.stopLeading(LeaderElector.java:120) ~[kubernetes-client-api-6.2.0.jar:na]
	at io.fabric8.kubernetes.client.extended.leaderelection.LeaderElector.lambda$null$1(LeaderElector.java:94) ~[kubernetes-client-api-6.2.0.jar:na]
	at java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:863) ~[na:na]
	at java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:841) ~[na:na]
	at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510) ~[na:na]
	at java.base/java.util.concurrent.CompletableFuture.cancel(CompletableFuture.java:2480) ~[na:na]
	at io.fabric8.kubernetes.client.extended.leaderelection.LeaderElector.lambda$null$0(LeaderElector.java:92) ~[kubernetes-client-api-6.2.0.jar:na]
	at java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:863) ~[na:na]
	at java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:841) ~[na:na]
	at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510) ~[na:na]
	at java.base/java.util.concurrent.CompletableFuture.cancel(CompletableFuture.java:2480) ~[na:na]
	at io.javaoperatorsdk.operator.LeaderElectionManager.stop(LeaderElectionManager.java:98) ~[operator-framework-core-4.0.3.jar:na]
	at io.javaoperatorsdk.operator.Operator.stop(Operator.java:118) ~[operator-framework-core-4.0.3.jar:na]
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:na]
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[na:na]
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:na]
	at java.base/java.lang.reflect.Method.invoke(Method.java:568) ~[na:na]
	at org.springframework.beans.factory.support.DisposableBeanAdapter.invokeCustomDestroyMethod(DisposableBeanAdapter.java:319) ~[spring-beans-5.3.21.jar:5.3.21]
	at org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(DisposableBeanAdapter.java:253) ~[spring-beans-5.3.21.jar:5.3.21]
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:587) ~[spring-beans-5.3.21.jar:5.3.21]
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.java:559) ~[spring-beans-5.3.21.jar:5.3.21]
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.destroySingleton(DefaultListableBeanFactory.java:1163) ~[spring-beans-5.3.21.jar:5.3.21]
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingletons(DefaultSingletonBeanRegistry.java:520) ~[spring-beans-5.3.21.jar:5.3.21]
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.destroySingletons(DefaultListableBeanFactory.java:1156) ~[spring-beans-5.3.21.jar:5.3.21]
	at org.springframework.context.support.AbstractApplicationContext.destroyBeans(AbstractApplicationContext.java:1106) ~[spring-context-5.3.21.jar:5.3.21]
	at org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:1075) ~[spring-context-5.3.21.jar:5.3.21]
	at org.springframework.boot.web.reactive.context.ReactiveWebServerApplicationContext.doClose(ReactiveWebServerApplicationContext.java:147) ~[spring-boot-2.6.9.jar:2.6.9]
	at org.springframework.context.support.AbstractApplicationContext.close(AbstractApplicationContext.java:1021) ~[spring-context-5.3.21.jar:5.3.21]
	at org.springframework.boot.SpringApplicationShutdownHook.closeAndWait(SpringApplicationShutdownHook.java:145) ~[spring-boot-2.6.9.jar:2.6.9]
	at java.base/java.lang.Iterable.forEach(Iterable.java:75) ~[na:na]
	at org.springframework.boot.SpringApplicationShutdownHook.run(SpringApplicationShutdownHook.java:114) ~[spring-boot-2.6.9.jar:2.6.9]
	at java.base/java.lang.Thread.run(Thread.java:833) ~[na:na]
Caused by: io.fabric8.kubernetes.client.KubernetesClientException: Failure executing: PUT at: https://<IP_ADDRESS>:6443/apis/coordination.k8s.io/v1/namespaces/sample-operator/leases/sample-operator-leader-election. Message: Operation cannot be fulfilled on leases.coordination.k8s.io "sample-operator-leader-election": the object has been modified; please apply your changes to the latest version and try again. Received status: Status(apiVersion=v1, code=409, details=StatusDetails(causes=[], group=coordination.k8s.io, kind=leases, name=sample-operator-leader-election, retryAfterSeconds=null, uid=null, additionalProperties={}), kind=Status, message=Operation cannot be fulfilled on leases.coordination.k8s.io "sample-operator-leader-election": the object has been modified; please apply your changes to the latest version and try again, metadata=ListMeta(_continue=null, remainingItemCount=null, resourceVersion=null, selfLink=null, additionalProperties={}), reason=Conflict, status=Failure, additionalProperties={}).
	at io.fabric8.kubernetes.client.KubernetesClientException.copyAsCause(KubernetesClientException.java:238) ~[kubernetes-client-api-6.2.0.jar:na]
	at io.fabric8.kubernetes.client.dsl.internal.OperationSupport.waitForResult(OperationSupport.java:517) ~[kubernetes-client-6.2.0.jar:na]
	at io.fabric8.kubernetes.client.dsl.internal.OperationSupport.handleResponse(OperationSupport.java:551) ~[kubernetes-client-6.2.0.jar:na]
	at io.fabric8.kubernetes.client.dsl.internal.OperationSupport.handleUpdate(OperationSupport.java:347) ~[kubernetes-client-6.2.0.jar:na]
	at io.fabric8.kubernetes.client.dsl.internal.BaseOperation.handleUpdate(BaseOperation.java:680) ~[kubernetes-client-6.2.0.jar:na]
	at io.fabric8.kubernetes.client.dsl.internal.HasMetadataOperation.lambda$replace$0(HasMetadataOperation.java:167) ~[kubernetes-client-6.2.0.jar:na]
	at io.fabric8.kubernetes.client.dsl.internal.HasMetadataOperation.replace(HasMetadataOperation.java:172) ~[kubernetes-client-6.2.0.jar:na]
	at io.fabric8.kubernetes.client.dsl.internal.HasMetadataOperation.replace(HasMetadataOperation.java:113) ~[kubernetes-client-6.2.0.jar:na]
	at io.fabric8.kubernetes.client.dsl.internal.HasMetadataOperation.replace(HasMetadataOperation.java:41) ~[kubernetes-client-6.2.0.jar:na]
	at io.fabric8.kubernetes.client.dsl.internal.BaseOperation.replace(BaseOperation.java:1043) ~[kubernetes-client-6.2.0.jar:na]
	at io.fabric8.kubernetes.client.dsl.internal.BaseOperation.replace(BaseOperation.java:88) ~[kubernetes-client-6.2.0.jar:na]
	at io.fabric8.kubernetes.client.extended.leaderelection.resourcelock.LeaseLock.update(LeaseLock.java:100) ~[kubernetes-client-api-6.2.0.jar:na]
	... 33 common frames omitted
Caused by: io.fabric8.kubernetes.client.KubernetesClientException: Failure executing: PUT at: https://<IP_ADDRESS>:6443/apis/coordination.k8s.io/v1/namespaces/sample-operator/leases/sample-operator-leader-election. Message: Operation cannot be fulfilled on leases.coordination.k8s.io "sample-operator-leader-election": the object has been modified; please apply your changes to the latest version and try again. Received status: Status(apiVersion=v1, code=409, details=StatusDetails(causes=[], group=coordination.k8s.io, kind=leases, name=sample-operator-leader-election, retryAfterSeconds=null, uid=null, additionalProperties={}), kind=Status, message=Operation cannot be fulfilled on leases.coordination.k8s.io "sample-operator-leader-election": the object has been modified; please apply your changes to the latest version and try again, metadata=ListMeta(_continue=null, remainingItemCount=null, resourceVersion=null, selfLink=null, additionalProperties={}), reason=Conflict, status=Failure, additionalProperties={}).
	at io.fabric8.kubernetes.client.dsl.internal.OperationSupport.requestFailure(OperationSupport.java:709) ~[kubernetes-client-6.2.0.jar:na]
	at io.fabric8.kubernetes.client.dsl.internal.OperationSupport.requestFailure(OperationSupport.java:689) ~[kubernetes-client-6.2.0.jar:na]
	at io.fabric8.kubernetes.client.dsl.internal.OperationSupport.assertResponseCode(OperationSupport.java:640) ~[kubernetes-client-6.2.0.jar:na]
	at io.fabric8.kubernetes.client.dsl.internal.OperationSupport.lambda$handleResponse$0(OperationSupport.java:576) ~[kubernetes-client-6.2.0.jar:na]
	at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:646) ~[na:na]
	at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510) ~[na:na]
	at java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2147) ~[na:na]
	at io.fabric8.kubernetes.client.dsl.internal.OperationSupport.lambda$retryWithExponentialBackoff$2(OperationSupport.java:618) ~[kubernetes-client-6.2.0.jar:na]
	at java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:863) ~[na:na]
	at java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:841) ~[na:na]
	at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510) ~[na:na]
	at java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2147) ~[na:na]
	at io.fabric8.kubernetes.client.okhttp.OkHttpClientImpl$4.onResponse(OkHttpClientImpl.java:277) ~[kubernetes-httpclient-okhttp-6.2.0.jar:na]
	at okhttp3.RealCall$AsyncCall.execute(RealCall.java:174) ~[okhttp-3.14.9.jar:na]
	at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32) ~[okhttp-3.14.9.jar:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[na:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[na:na]
	... 1 common frames omitted

2022-10-31 16:51:55.758  INFO 30444 --- [ionShutdownHook] i.j.operator.LeaderElectionManager       : Stopped leading for identity: local. Exiting.

In above state, operator is still in STOPPING state.

It is not completely stopped.
Therefore, operator Pod can't be restarted immediately.

Environment
Kubernetes cluster type:

$ Mention java-operator-sdk version from pom.xml file

4.0.3

$ java -version
openjdk version "17.0.5" 2022-10-18
OpenJDK Runtime Environment Temurin-17.0.5+8 (build 17.0.5+8)
OpenJDK 64-Bit Server VM Temurin-17.0.5+8 (build 17.0.5+8, mixed mode)

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.1", GitCommit:"e4d4e1ab7cf1bf15273ef97303551b279f0920a9", GitTreeState:"clean", BuildDate:"2022-09-14T19:49:27Z", GoVersion:"go1.19.1", Compiler:"gc", Platform:"darwin/arm64"}
Kustomize Version: v4.5.7
Server Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.1", GitCommit:"e4d4e1ab7cf1bf15273ef97303551b279f0920a9", GitTreeState:"clean", BuildDate:"2022-09-14T19:42:30Z", GoVersion:"go1.19.1", Compiler:"gc", Platform:"linux/amd64"}

Possible Solution

Additional context

cc @shawkins - this looks like more an issue with the leader election in client, are you aware of such issue?
this looks like a simple optimistic locking error from the client

@csviri is there just a single elector?  Unfortunately it seems possible for this to occur in that case as there's no explicit locking - just a volatile variable to track the latest record.  So a cancel could occur in between an update operation and setting the latest record.

@shawkins thx, I see. So what is happening that the record it not read again on cancel, so there is an optimistic locking issue if someone changed the resource meanwhile. I have some questions:

@hoony9x what do you mean it is not completely stopped? If I understand correctly based in the client:
https://github.com/fabric8io/kubernetes-client/blob/26b8ce7eec3311d9a4a296ebaf8b3421347856fc/kubernetes-client-api/src/main/java/io/fabric8/kubernetes/client/extended/leaderelection/LeaderElector.java#L122-L125
The stop callback should be made and in the JOSDK side:
https://github.com/java-operator-sdk/java-operator-sdk/blob/fb9dc1aeef2a5b0c9faf69286d39f16409f332f7/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/LeaderElectionManager.java#L74-L80
Should stop the process / pod.  By it is " you mean the operator is still running? You mean the pod is still running, or the lock is not removed?

@shawkins would not make sense to refresh the Lock before cancel?

@shawkins if there are two instances ? the other should not do updates on the lock, or it is expected that the other - non leader - does some updates on the lock?

@csviri I mean, operator "looks like" stopped, but process is not terminated.

@shawkins would is make sense to refresh the Lock before cancel?

No, the leader election logic just needs some synchronization.

@shawkins if there are two instances ? the other should not do updates on the lock, or it is expected that the other - non leader - does some updates on the lock?

It is possible that someone else assumed leadership by the time this call is being made.  The exception would be the same, but it wouldn't matter as the leadership is already lost.

I mean, operator "looks like" stopped, but process is not terminated.

@hoony9x are you able to take a thread dump and see what non-daemon threads are still running?

@csviri I mean, operator "looks like" stopped, but process is not terminated.

That is strange as you can see here:
https://github.com/java-operator-sdk/java-operator-sdk/blob/fb9dc1aeef2a5b0c9faf69286d39f16409f332f7/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/LeaderElectionManager.java#L74-L80
System.exit(1) is called right after thsi log message.
Could you pls check inspect the container status of the pod? And see what is happening there on pod level?

No, the leader election logic just needs some synchronization.

By refresh I meant lead the latest version.

@shawkins @csviri
I tested it again on my private Kubernetes Cluster and Pod is terminated without delay.

Previous result was my mistake.

Errror message I already described above still shows up when I tried to stop operator.

As @shawkins explained that actually might be expected, also see an improvement on this:
https://github.com/fabric8io/kubernetes-client/pull/4548

Since there was already an improvement on this since, and the mentioned error is expected in some situations, will close this issue, and reopen in case there are still some issues.


validation: leaf field selection

implement leaf field selection spec

I've opened a PR to partially implement this validation: https://github.com/apollographql/apollo-rs/pull/464

I've opened a PR for this: https://github.com/apollographql/apollo-rs/pull/465

thanks @yanns! I'll take a look

closed by #465


support azure storage table

Do we have any plan to support azure storage table?

Thanks for your interest! We actually have an SDK in development:
Current development progress: https://github.com/Azure/azure-sdk-for-python/issues/12311
PR: https://github.com/Azure/azure-sdk-for-python/pull/12766
Rather than Storage Table - it will likely be published as azure-data-tables - and we are hoping to ship the first preview in September.

Thanks for your reply. Looking forward to that SDK.


Display as blank in 'Rename' dialog when renaming a blob container

Storage Explorer Version: 20180424.5(1.0.0)
OS Version: Win10/Mac/Linux
Regression: Not a regression
Steps to Reproduce:

Launch Storage Explorer and expand Storage Accounts.
Right click one blob continer and select 'Rename...'.
Check the Rename dialog.

Expected Experience:
Display as 'Rename Blob Container' in 'Rename' dialog.
Actual Experience:
Display as blank in 'Rename' dialog.

Fix merged into master.


Added link to Silex provider

Thanks to RJ for hinting me on how to do this myself!

Thanks @ExplicitDev !


Use the http crate

Once the http crate (announced here) gets a release on crates.io we should replace some of the bespoke types in here with it.
It's also an opportunity to support Bytes in more places and avoid copying data when it's not necessary.
This will need to be supported in reqwest, and probably hyper before we can go too far with it here though.

http now has a release, but we'll still need this to propagate through to reqwest before we can start using it.


<EMAIL_ADDRESS>Module not found: Can't resolve '@babel/runtime/helpers/builtin/assertThisInitialized'

Followed the installation instructions, but on npm start this error comes up:

<EMAIL_ADDRESS>Module not found: Can't resolve '@babel/runtime/helpers/builtin/assertThisInitialized' in 'C:\MyApps\material-dashboard-react-v1.4.0\node_modules@material-ui\core\ButtonBase'

Tried the proposed solutions but nothing helped. Installing babel-runtime didn't help either. Anyone else getting this error? How could it be resolved? Thanks!

Hi , when build from version 1.4.0, issue also appeared to me.I fixed it and it effect with me

first you can create new folder "builtin" under 'node_modules/@babel/runtime/helpers/'
copy all .js file from 'helpers' to new created folder
you may also need change
'var _typeof = require("../helpers/typeof");' to 'var _typeof = require("./typeof");' in
<EMAIL_ADDRESS>

Hello guys, you can also check this issue here: https://github.com/creativetimofficial/ct-material-dashboard-pro-react/issues/62

builtin

There is no runtime folder under @babel.
Please help me to solve this issue.


ISSUE: Multiple Locks makes too many entities and tanks HA. Also completely messes up the NabuCasa Integration

Describe the bug
Because of all the input booleans being made it causes a HUGE lockup when you add new locks. People should disable input booleans being auto-added to the NabuCasa integration to prevent this issue.
Environment (please complete the following information):

OS: HassOS
Type of system that HA is running on: HyperV Official Appliance VM
Home Assistant version: 2020.3.3
Hassio: Latest
Component version: [e.g. 0.1.2]
Z-Wave integration name: zwave_js
Lock make and model: n/a

Edit:
So I have 6 locks in my house. My front door is to be the parent lock. I added 3 childs and it is just completely tanking my HA installation. I had to remove the integration as this ended up making close to 2400+ entities and automations. My HA box is running on a server with a Threadripper and I have 24 cores + 32GB RAM allocated to it. It just crashes the HA box.

There has to be a better way to go about this without making so many entities and automations. The only thing I am going to try next is limiting myself to only 10 code slots even though my locks support 30.

Possibly a duplicate of #265


2.0-rc1: server.sh MAXDISKCACHE parameter causes startup error

It's near the end of the file, if you put in the value "8192" as suggested in the comment you get an error "Error: Could not find or load main class 8192"

One followup question: there's also a setting for this in orientdb-server-config.xml, so if it is set in both places which one is used?  Shouldn't it be documented and used in just one place rather than 2, that seems confusing.  I guess I don't understand why it was added to server.sh when it was already working fine in the ...config.xml?

You could set this in orientdb-server-config.xml, but there isn't in default cfg. We prefer to keep storage.diskCache.bufferSize and JVM -Xmx in the same place to make this tuning easier.

The comment in server.bat as of 2.0.12 is still misleading (though server.sh is fixed), as are the recommendations from the server when you are using too much disk cache.

Changed in 2.0.13


Minor theme and Widgets styles fixes

UI fixes found due the migration job done in carto-react-templates project.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 71.351%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1950

Relevant Lines:
2514

💛  - Coveralls


omegaconf

Hi Lars
I thought this information may be useful to you.   I figured it out why my initial installation of lightning-trainable was not working.
After tracing the code, I found that I have to remove my installed package OmegaConf, otherwise torch lightning will use omegaconf to save trainer parameters which may contradict to the definition of AttributeDict in lightning-trainable.
JB

Hi JB, thanks for the heads-up!


Update readme

Update readme with new version and download instructions.

Since the svg/svg-gui has been marked obsolete, I think that explaining how to get new builds will help less proficient users.

thx a lot


Improve on transparency and define governance

It needs some clarification on how is this project governed, by whom, what is the approval process for contributions and by whom.
We can of course look at the list of contributors, take a peek at the @TODOGroup page, but that does not really explains much beyond that this is a project of group of X people from X companies.
Example governance information from IO.JS https://github.com/nodejs/io.js/blob/master/GOVERNANCE.md

I agree, essentially @todogroup/owners have the commit bit and make the final decision.
We will add a CONTRIBUTING.md to make this more clear. No need for a crazy governance document yet outside of stating what expectations are for contributing and committing in the CONTRIBUTING.md and then linking it off the README.md

Nobody outside the @todogroup/owners can actually see who is in that team. :)

We will make things clearer in the CONTRIBUTING.md

See https://github.com/todogroup/opencodeofconduct/issues/84.


📝 Add warning about lifecycle events with AsyncClient

Improve docs as suggested in #2003.

📝 Docs preview for commit 8f37575f631795bc21e44426b457af9ee1c05588 at: https://a8648b88.fastapitiangolo.pages.dev

Nice, thank you @andrew-chang-dewitt! 🙇
And thanks for the review @Kludex! 🚀


Unwrap UV2 for Lightmap/AO option causes mesh to turn into black cube

Godot version
4.2.rc1
System information
Godot v4.2.rc1 - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3070 (NVIDIA; <IP_ADDRESS>99) - AMD Ryzen 5 3600 6-Core Processor (12 Threads)
Issue description
When attempting to generate UV2 for lightmapping when using the mesh drop down menu on the toolbar, the mesh turns into a black cube. The UV's do seem to generate correctly though

Steps to reproduce

Import a mesh as a .gltf
In Godot, right click that mesh and choose New Inherited Scene
In the new inherited scene, select the mesh instance
In the inspector, click the drop down next to mesh (directly under MeshInstance3D) and choose Make Unique
With the mesh instance still selected, click the Mesh menu on the toolbar
Click Unwrap UV2 for Lightmap/AO

The mesh should turn into a black cube, but the original orange bounding box can still be seen. The UV2 will have still been successfully generated. Instancing this scene in another scene still shows it as a black cube.
Minimal reproduction project
UV_Unwrap_MRP.zip

The correct approach to generating UV2 in an imported 3D scene is to use the Import options to use the Static + Lightmaps GI mode (or do so in the Advanced Import Settings dialog for more granular options). The Mesh menu should only be used in specific cases, not for imported scenes.


Fix modifying Map in policies is not thread safe

#9711
Motivation
The policies of the namespace contains Map, and when we modify the Policies, the Map API will be called. If we use HashMap, it will cause thread safety issues.
Modifications
HashMap changed to ConcurrentHashMap
Verifying this change
After jackson serialization and deserialization, the type of map is still ConcurrentHashMap

Great work @315157973 , really elegant.

It's great that the thread safely of the data structures is now handled so we won't run into infinite loops which would happen with plain HashMaps. With the ConcurrentHashMaps, it will also be possible to handle data consistency issues.
There are some remaining data consistency ("lost update") issues when mutating AuthPolicies maps, for example here:
https://github.com/apache/pulsar/blob/e24645852edeee6aa0850ce814384bedd6518e7a/pulsar-broker/src/main/java/org/apache/pulsar/broker/admin/impl/NamespacesBase.java#L691-L694
https://github.com/apache/pulsar/blob/1fab5aa69446b4c2eaebb615d35fe9f5a509ba4c/pulsar-broker-common/src/main/java/org/apache/pulsar/broker/authorization/PulsarAuthorizationProvider.java#L296-L299
https://github.com/apache/pulsar/blob/782372d8f51984f18de3b102cfb3c00c6dedb2bb/pulsar-broker-common/src/main/java/org/apache/pulsar/broker/authorization/PulsarAuthorizationProvider.java#L344-L356
https://github.com/apache/pulsar/blob/76883d455b44b7b0b73684d0212002397dbb9b2c/pulsar-broker/src/main/java/org/apache/pulsar/broker/admin/impl/PersistentTopicsBase.java#L324-L331
https://github.com/apache/pulsar/blob/76883d455b44b7b0b73684d0212002397dbb9b2c/pulsar-broker/src/main/java/org/apache/pulsar/broker/admin/impl/PersistentTopicsBase.java#L391-L395
There might be some other locations besides the ones above.
Would it help to use Map.compute instead of .get(..).removeAll(...) and .put(..,..) for mutations? Isn't Map.compute atomic for ConcurrentHashMap? WDYT?
@315157973 are you thinking of addressing the mutations of the AuthPolicies maps in this PR or separately?

It's great that the thread safely of the data structures is now handled so we won't run into infinite loops which would happen with plain HashMaps. With the ConcurrentHashMaps, it will also be possible to handle data consistency issues.
There are some remaining data consistency ("lost update") issues when mutating AuthPolicies maps, for example here:
https://github.com/apache/pulsar/blob/e24645852edeee6aa0850ce814384bedd6518e7a/pulsar-broker/src/main/java/org/apache/pulsar/broker/admin/impl/NamespacesBase.java#L691-L694
https://github.com/apache/pulsar/blob/1fab5aa69446b4c2eaebb615d35fe9f5a509ba4c/pulsar-broker-common/src/main/java/org/apache/pulsar/broker/authorization/PulsarAuthorizationProvider.java#L296-L299
https://github.com/apache/pulsar/blob/782372d8f51984f18de3b102cfb3c00c6dedb2bb/pulsar-broker-common/src/main/java/org/apache/pulsar/broker/authorization/PulsarAuthorizationProvider.java#L344-L356
https://github.com/apache/pulsar/blob/76883d455b44b7b0b73684d0212002397dbb9b2c/pulsar-broker/src/main/java/org/apache/pulsar/broker/admin/impl/PersistentTopicsBase.java#L324-L331
https://github.com/apache/pulsar/blob/76883d455b44b7b0b73684d0212002397dbb9b2c/pulsar-broker/src/main/java/org/apache/pulsar/broker/admin/impl/PersistentTopicsBase.java#L391-L395
There might be some other locations besides the ones above.
Would it help to use Map.compute instead of .get(..).removeAll(...) and .put(..,..) for mutations? Isn't Map.compute atomic for ConcurrentHashMap? WDYT?
@315157973 are you thinking of addressing the mutations of the AuthPolicies maps in this PR or separately?

The solution I thought of:
I will start a new PR to add zk version to the policies cache.
When the policies cache in some thread is dirty(with old version), writing to zk will report an error. At this time, the latest cache will be read, and then this Function will be called again to ensure that the dirty cache will not overwrite the new data.

The solution I thought of:
I will start a new PR to add zk version to the policies cache.
When the policies cache in some thread is dirty(with old version), writing to zk will report an error. At this time, the latest cache will be read, and then this Function will be called again to ensure that the dirty cache will not overwrite the new data.

Yes, I think that it's a good idea to handle the ZK and distributed updates issues separately. Please create a new issue for the data consistency issues around ZK and distributed modifications since that is a broader scope than #9711.
My previous question was about preventing the "lost updates" problems that happen in the local data structures. I consider that problem a part of #9711.
Please take a look if you could change the mutation logic to prevent the "lost updates" issue in the locations that were listed in my previous comment.
@315157973 Could you resolve the local "lost updates" issues as part of this current PR, since after that I think it's ok to close 9711 with this PR? WDYT?

I thought of these solutions:
1 Tag Policies with the version of zk, lock them when reading the cache, and clone a copy of Policies. When updating to zk, if the version is incorrect, re-read the latest cache of zk and redo the modification, and then update.
2 In the unit of namespace, all namespace operations are put into orderExecutor, and each namespace is processed by a fixed thread. Then call back.
I tend to use method 2, and this PR will be closed
@lhotari

I thought of these solutions:
1 Tag Policies with the version of zk, lock them when reading the cache, and clone a copy of Policies. When updating to zk, if the version is incorrect, re-read the latest cache of zk and redo the modification, and then update.
2 In the unit of namespace, all namespace operations are put into orderExecutor, and each namespace is processed by a fixed thread. Then call back.
I tend to use method 2, and this PR will be closed

Sounds good. It would be useful to write a separate issue which explains the current challenges in updating policies in a distributed setup with multiple brokers.
The only problem with this approach is that we cannot close 9711 before the other PRs are delivered. I can  provide a fix for 9711 in the meantime (before the ZK & single writer approach is delivered) using Map.compute. That could become obsolete later, but it doesn't cause any harm to do that as an intermediate step since it would fix 9711.

I thought of these solutions:
1 Tag Policies with the version of zk, lock them when reading the cache, and clone a copy of Policies. When updating to zk, if the version is incorrect, re-read the latest cache of zk and redo the modification, and then update.
2 In the unit of namespace, all namespace operations are put into orderExecutor, and each namespace is processed by a fixed thread. Then call back.
I tend to use method 2, and this PR will be closed

Sounds good. It would be useful to write a separate issue which explains the current challenges in updating policies in a distributed setup with multiple brokers.
The only problem with this approach is that we cannot close 9711 before the other PRs are delivered. I can provide a fix for 9711 in the meantime (before the ZK & single writer approach is delivered) using Map.compute. That could become obsolete later, but it doesn't cause any harm to do that as an intermediate step since it would fix 9711.

If it is single-threaded processing, there is no competition problem, and my PR will fix your problem.
I will submit a PR this week

If it is single-threaded processing, there is no competition problem, and my PR will fix your problem.

Yes, it will eventually fix it. It would be helpful if you could create a separate issue about the ZK issues that you are planning to address since that is beyond #9711. Are you fine with that?


Swift 4 Update

This PR includes an updated version of Swamp using Swift 4.

Thank you! 👍

👍  this is great


istioctl wait race condition leads to hangs

Push v1
Start pushing v2, but its a skip. Record
Envoy ACKs v1

We do not wait for ACK to start a new push. So we are stuck with 'v1' as latest version

If we avoid the condition of a skip push for v2, should ACKS always come back in the order of their messages?  I can imagine how to handle this particular edge case, but if ACKS can come back in any order, we will have a larger problem...

I believe ACKs always come in order. Is the solution you were thinking of to maintain some queue of un-acked messages or something and pop them off as they come in? If so I suspect that would work, although I bet we will run into some edge case where we end up leaking memory... Envoy restart for example could plausibly cause a permanently lost ack

This code is removed. If we add back equivilent, fixing this should be considered


fix(addon-table): eyes not draggable

Closes #6902 https://github.com/taiga-family/taiga-ui/issues/6902

@AndreiSachuk Could you add cherry pick to v3.x?