Byte length from buffer view is not equal to byte stride * accessor.count

Describe the issue
  const auto &accessor = model.accessors[accessorIdx];
  const auto &bufferView = model.bufferViews[accessor.bufferView];
  const auto &buffer = model.buffers[bufferView.buffer];
  const size_t byteStride = accessor.ByteStride(bufferView);
  assert(bufferView.byteLength == byteStride * accessor.count);

Last line triggers assert.
To Reproduce

Windows 10 Pro Version 21H2 (OS Build 19044.2130)
Microsoft (R) C/C++ Optimizing Compiler Version 19.33.31630 for x86
https://github.com/KhronosGroup/glTF-Sample-Models/blob/8e9a5a6ad1a2790e2333e3eb48a1ee39f9e0e31b/2.0/Box/glTF/Box.gltf

Expected behaviour
  assert(bufferView.byteLength == byteStride * accessor.count);

Should not assert.

Current tiny_gltf.h https://github.com/syoyo/tinygltf/blob/release/tiny_gltf.h does not contain such line:
assert(bufferView.byteLength == byteStride * accessor.count);

You may need to update tinygltf.

Well this code is not from tinygltf.
This is my code that replicates what is shown in one of your examples.
My question was why BufferView::byteLength is not equal to Accessor::ByteStride multiplied by Accessor::count?
Is it expected?

My question was why BufferView::byteLength is not equal to Accessor::ByteStride multiplied by Accessor::count?

Its not related to tinygltf.
You need to check glTF 2.0 spec: https://github.com/KhronosGroup/glTF


Install speedups when testing with tox

I tried adding windows tests run via github actions, but seems they are failing on python 3.7 and 3.8, while appveyor doing fine, so I removed this commit, though I kept it in https://github.com/bitfag/python-graphenelib/tree/github-windows

cool patch


Execute all tests in particular folder

Either the existing command maestro test or the new one should execute all tests (.yaml files, maybe only those with correct syntax for Maestro) in the current directory (folder) or pass the directory as an argument.
Currently when I have few test cases I need to create either one test to combine them (using test nesting) or to pass them all as arguments to maestro test - in both cases adding new test require to remember about this and is a tedious step.

Have you tried maestro test <folder>/<name>/*.yml? It worked for me


Add coverage for TimeSeries class

Added test coverage for TimeSeries class and the nonempty() function in render/datalib.py
* Change Timeseries.__eq__ to return False if the comparing object is not a TimeSeries.
* Adjust test for nPercentile() that started failing because of the __eq__ change

[Current coverage][cc-pull] is 61.00%

Merging [#1602][cc-pull] into [master][cc-base-branch] will increase coverage by 0.94%

@@             master      #1602   diff @@
==========================================
  Files            52         52
  Lines          5804       5804
  Methods           0          0
  Messages          0          0
  Branches       1119       1119
==========================================
+ Hits           3486       3541    +55
+ Misses         2118       2065    -53
+ Partials        200        198     -2

Powered by Codecov. Last updated by [904071b...f343a7e][cc-compare]
[cc-base-branch]: https://codecov.io/gh/graphite-project/graphite-web/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/graphite-project/graphite-web/compare/904071bdbc7408d6f411e25942e5942460cc251b...f343a7e60f184d771b99cccc1ba6645d1202ad61?src=pr
[cc-pull]: https://codecov.io/gh/graphite-project/graphite-web/pull/1602?src=pr


refactor: move app-logic to a src-folder, style changes to example

I'm thinking perhaps we should remove the JS-related temporarily since they're not working at the moment. Either that or fixing them, of course, but not sure how much work is needed for that!

Thanks for making these changes @lessp !

I'm thinking perhaps we should remove the JS-related temporarily since they're not working at the moment.

I agree - it's just extra overhead and clutter right now, since it doesn't work with Skia. Let's remove it - we can bring it back once we have JS-enabled builds again 👍

Thanks for making these changes @lessp !

I'm thinking perhaps we should remove the JS-related temporarily since they're not working at the moment.

I agree - it's just extra overhead and clutter right now, since it doesn't work with Skia. Let's remove it - we can bring it back once we have JS-enabled builds again 👍

Agreed, I went ahead and removed it for now! Merging!


fix: broken newsletter link refs -> add / prefix to impacted routes

Issue #, if available:
#319
Fix current relative newsletter links that are broken:

Footer
Past/Previous

Description of changes:
Add / prefix to the creations/props associated with newsletters/... routes.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Thanks @siegerts !


[SURE-8469] GKE Sync issue

See SURE-8469 for details
googleapi: Error 400: Auto-upgrade is enabled, node version "1.26.11-gke.1055000" must be within one minor version of master version "1.28.7-gke.1026000"

++ The error was a passing one when GKE was switching release channels for GKE. The error auto-resolved in GKE but got stuck in rancher API.

I have responded in the issue and I'm now waiting for feedback.

It is closed


Layout breaks in orientation

Issue Description
Layout breaks if I rotate orientation. I can't scroll from some sections(eg. can scroll in the tasks section, but can't scroll from above in the profile section.)
Expected Behavior
App should be responsive in small/big screens
Current Behavior
[Explain what currently happens when this issue is encountered.]
Screenshots
[If applicable, add screenshots or images that help illustrate the issue. You can use the following Markdown syntax to embed images:]
Environment

Operating System: [e.g., Windows, macOS, Linux]
Browser (if applicable): [e.g., Chrome, Firefox, Safari]
Version of Software/Project: [e.g., v1.0.0]

Additional Information
[Include any additional context, logs, or details that might be helpful in addressing the issue.]
Checklist

[ ] I have read and followed the project's code of conduct.
[ ] I have searched for similar issues before creating this one.
[ ] I have provided all the necessary information to understand and reproduce the issue.
[ ] I am willing to contribute to the resolution of this issue.

Thank you for contributing to our project! We appreciate your help in improving it.
📚 See contributing instructions.

Can we just lock the app in portrait mode?

Can we just lock the app in portrait mode?
Already told the same solution to Shubham Sharma


validate run time limit for all problem instances/tasks

No pull requests until after 10-Dec deliverables.
ensure all run time limits are set to reasonable values.   This values determines if a solver succeeds or fails at solving a problem.
fixing problem instances in place is OK.  any other scripts that generate problem instance JSON files should be updated as well.

@aakunitsa  and @jtcantin reminder about this issue:
All of our time_limit_seconds fields for tasks are either 86400 (1 day) or 172800 (2 days).  I want to revisit this for all Hamiltonians and determine if this blanket requirement is too tight and should be relaxed for some larger Hamiltonians (e.g., time_limit_seconds = 604800 (1 week)).
The time limit is important because it dictates whether a solver (or resource estimate) passes or fails in terms of "solving" the problem.
You can revisit the Hamiltonians manually or systematically, but either way, please use your subject matter expertise and experience to suggest reasonable time limits that suggest utility.


xdg-desktop-portal-kde slow to run at startup

Running Bazzite 38 NVIDIA desktop here. On boot the portal kde takes quite some time to start, if I open any program that needs it before it loads the programs will not load/connect to the portals correctly. Works completely fine if I just wait for it to start altho its normally about a 3 min wait. Unsure if this is typical behavior for these type of systems but idk feel more like something is bugged maybe?

This seems to be fix with bazzite 39(testing) or kde 5.27.9 and I believe it was a kde issue


feat: add contributing.md

What type of PR is this?
/kind feature
What this PR does / why we need it:
add contributing.md
Which issue(s) this PR fixes:

Fixes #514

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
7 unchanged lines in 2 files lost coverage.
Overall coverage increased (+0.07%) to 74.122%

Files with Coverage Reduction
New Missed Lines
%

pkg/engine/operation/parser/parser.go
3
79.27%

pkg/engine/operation/parser/spec_parser.go
4
56.1%

Totals

Change from base Build<PHONE_NUMBER>:
0.07%

Covered Lines:
6267

Relevant Lines:
8455

💛  - Coveralls


Code-coverage

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.0 out of 3 committers have signed the CLA.:x: bubonicfred:x: depfu[bot]:x: dependabot[bot]You have signed the CLA already but the status is still pending? Let us recheck it.


Detached Dialogic 2 Window clears Timeline

The problem
Describe the bug
Timeline empties when detaching the window.
Saving will override the timeline with no content or whatever has been added while detaching!
To Reproduce
I used the released Dialogic 2 Alpha 12.
Steps to reproduce the behavior:

Without detached Dialogic 2 window, open a timeline.
Detach the window.
Check if the timeline name is still there, contents must be empty now.

This state can be fixed by switching to any other Dialogic 2 tab and back.
Expected behavior
The content of the timeline is shown when detaching the window.
Solutions
Workaround
As mentioned, switching tabs will fix this.

Do you think this could be saved by triggering a save before toggeling detachment? sounds like the easiest solution to me.


chore(main): release 1.5.0

:robot: I have created a release beep boop
1.5.0 (2024-01-04)
Features

add CI (test/lint) action (0d996ef)
badgees (ccc1af7)
don't run against docker image (e23b774)

Bug Fixes

blocked by (6fac0ff)
codecov (9fb465e)
codecov badge (5aed599)
dont push (45ff210)
images not found on index route (b7de64f)
remove 'if' from build step (717f140)
use local output (e3b163b)

Miscellaneous Chores

add codecov (5b6ba73)
adjust perms (53728cc)
chmod after download (c418eee)
cleanup junk, create .env on composer install/update (84536ed)
drop cache (d588cd7)
drop codecov (c2ee5ff)
gitkeep unit dir (f2b0f9d)
make executable (79318bd)
on push (82a0dc4)
own recursive (15a9b06)
poitn to prep (15694a3)
try docker type (8d0be67)
use buildx (bc05ab1)
use dir (2fd720d)
use runner.temp (9be6123)
xdebug (8dc2a54)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/mdshack/shotshare/releases/tag/v1.5.0 :sunflower:


fix: broken links

@ls4096 thank you for sending the PR and fixing the links ❤
The changes look good.
Before we can merge, could you accept our CLA

Read the CLA at
https://www.ockam.io/learn/how-to-guides/contributing/cla/

To accept the CLA please send a different PR to our contributors repo indicating that you accept the CLA by adding your Git/Github details in a row at the end of the CONTRIBUTORS.csv file:
https://github.com/ockam-network/contributors/blob/master/CONTRIBUTORS.csv

Looking forward to merging your first contribution!!

@ls4096 thank you for sending the PR and fixing the links ❤
The changes look good.
Before we can merge, could you accept our CLA

Read the CLA at
https://www.ockam.io/learn/how-to-guides/contributing/cla/

To accept the CLA please send a different PR to our contributors repo indicating that you accept the CLA by adding your Git/Github details in a row at the end of the CONTRIBUTORS.csv file:
https://github.com/ockam-network/contributors/blob/master/CONTRIBUTORS.csv

Looking forward to merging your first contribution!!

I have read the CLA Document and I hereby sign the CLA

I have read the CLA Document and I hereby sign the CLA

Thank you!
I made some minor edits to the commit message to conform with our convention but made sure you attribution is maintained - merged https://github.com/ockam-network/ockam/commit/5fd01d99bc019015674384c53574382fac9da29f
Congratulations on your first Ockam contribution, I look forward to many more 🎉

Thank you!
I made some minor edits to the commit message to conform with our convention but made sure you attribution is maintained - merged https://github.com/ockam-network/ockam/commit/5fd01d99bc019015674384c53574382fac9da29f
Congratulations on your first Ockam contribution, I look forward to many more 🎉


[Task]: Use standard naming convention strategy for index names in postgres

SubTasks

Go through existing indexes and add NULLS NOT DISTINCT
Renaming indexes as per this convention - https://stackoverflow.com/questions/4107915/postgresql-default-constraint-names/4108266#4108266

This is completed, closing this


[backend] update: label task can keep_annotations for now

[ ] use updated protobuf which include keep_annotations and the like

麻烦看下CI

@phoenix-xhuang updated


Policy framework shareback

Share framework with the team
Get feedback and implement
Start applying the framework as needed (Breadcrumbs for e.g.)

Card to be refined for Sprint 3

To be shared back on Wednesday demo time


[Bug]: vllm0.5.5+Prefix caching RuntimeError: CUDA error: an illegal memory access was encountered

Your current environment

The output of `python collect_env.py`
Collecting environment information...
PyTorch version: N/A
Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A

OS: CentOS Linux release 8.0.1905 (Core)  (x86_64)
GCC version: (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4)
Clang version: Could not collect
CMake version: version 3.29.5
Libc version: glibc-2.28

Python version: 3.9.19 (main, Mar 21 2024, 17:11:28)  [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-4.18.0-348.7.1.el8_5.x86_64-x86_64-with-glibc2.28
Is CUDA available: N/A
CUDA runtime version: 12.0.140
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration:
GPU 0: NVIDIA A100-SXM4-80GB
GPU 1: NVIDIA A100-SXM4-80GB

Nvidia driver version: 535.161.08
cuDNN version: Probably one of the following:
/usr/local/cuda-12.0/targets/x86_64-linux/lib/libcudnn.so.8.8.1
/usr/local/cuda-12.0/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8.8.1
/usr/local/cuda-12.0/targets/x86_64-linux/lib/libcudnn_adv_train.so.8.8.1
/usr/local/cuda-12.0/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8.8.1
/usr/local/cuda-12.0/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8.8.1
/usr/local/cuda-12.0/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8.8.1
/usr/local/cuda-12.0/targets/x86_64-linux/lib/libcudnn_ops_train.so.8.8.1
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A

CPU:
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              28
On-line CPU(s) list: 0-27
Thread(s) per core:  2
Core(s) per socket:  14
Socket(s):           1
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          6
Model:               106
Model name:          Intel(R) Xeon(R) Platinum 8350C CPU @ 2.60GHz
Stepping:            6
CPU MHz:             2593.906
BogoMIPS:            5187.81
Hypervisor vendor:   KVM
Virtualization type: full
L1d cache:           48K
L1i cache:           32K
L2 cache:            1280K
L3 cache:            49152K
NUMA node0 CPU(s):   0-27
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq pni pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves arat avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq la57 rdpid md_clear arch_capabilities

Versions of relevant libraries:
[pip3] mypy-extensions==1.0.0
[pip3] numpy==1.26.4
[pip3] nvidia-cublas-cu11==<IP_ADDRESS>
[pip3] nvidia-cublas-cu12==<IP_ADDRESS>
[pip3] nvidia-cuda-cupti-cu12==12.1.105
[pip3] nvidia-cuda-nvrtc-cu11==11.7.99
[pip3] nvidia-cuda-nvrtc-cu12==12.1.105
[pip3] nvidia-cuda-runtime-cu11==11.7.99
[pip3] nvidia-cuda-runtime-cu12==12.1.105
[pip3] nvidia-cudnn-cu11==<IP_ADDRESS>
[pip3] nvidia-cudnn-cu12==<IP_ADDRESS>
[pip3] nvidia-cufft-cu12==<IP_ADDRESS>
[pip3] nvidia-curand-cu12==<IP_ADDRESS>
[pip3] nvidia-cusolver-cu12==<IP_ADDRESS>
[pip3] nvidia-cusparse-cu12==<IP_ADDRESS>
[pip3] nvidia-ml-py==12.555.43
[pip3] nvidia-nccl-cu12==2.20.5
[pip3] nvidia-nvjitlink-cu12==12.4.127
[pip3] nvidia-nvtx-cu12==12.1.105
[pip3] pynvml==11.5.0
[pip3] pyzmq==26.0.0
[pip3] sentence-transformers==3.0.1
[pip3] torch==2.4.0
[pip3] torchvision==0.19.0
[pip3] transformers==4.44.0
[pip3] transformers-stream-generator==0.0.5
[pip3] triton==3.0.0
[conda] numpy                     1.26.4                   pypi_0    pypi
[conda] nvidia-cublas-cu11        <IP_ADDRESS>               pypi_0    pypi
[conda] nvidia-cublas-cu12        <IP_ADDRESS>                 pypi_0    pypi
[conda] nvidia-cuda-cupti-cu12    12.1.105                 pypi_0    pypi
[conda] nvidia-cuda-nvrtc-cu11    11.7.99                  pypi_0    pypi
[conda] nvidia-cuda-nvrtc-cu12    12.1.105                 pypi_0    pypi
[conda] nvidia-cuda-runtime-cu11  11.7.99                  pypi_0    pypi
[conda] nvidia-cuda-runtime-cu12  12.1.105                 pypi_0    pypi
[conda] nvidia-cudnn-cu11         <IP_ADDRESS>                 pypi_0    pypi
[conda] nvidia-cudnn-cu12         <IP_ADDRESS>                 pypi_0    pypi
[conda] nvidia-cufft-cu12         <IP_ADDRESS>                pypi_0    pypi
[conda] nvidia-curand-cu12        <IP_ADDRESS>               pypi_0    pypi
[conda] nvidia-cusolver-cu12      <IP_ADDRESS>               pypi_0    pypi
[conda] nvidia-cusparse-cu12      <IP_ADDRESS>               pypi_0    pypi
[conda] nvidia-ml-py              12.555.43                pypi_0    pypi
[conda] nvidia-nccl-cu12          2.20.5                   pypi_0    pypi
[conda] nvidia-nvjitlink-cu12     12.4.127                 pypi_0    pypi
[conda] nvidia-nvtx-cu12          12.1.105                 pypi_0    pypi
[conda] pynvml                    11.5.0                   pypi_0    pypi
[conda] pyzmq                     26.0.0                   pypi_0    pypi
[conda] sentence-transformers     3.0.1                    pypi_0    pypi
[conda] torch                     2.4.0                    pypi_0    pypi
[conda] torchvision               0.19.0                   pypi_0    pypi
[conda] transformers              4.44.0                   pypi_0    pypi
[conda] transformers-stream-generator 0.0.5                    pypi_0    pypi
[conda] triton                    3.0.0                    pypi_0    pypi
ROCM Version: Could not collect
Neuron SDK Version: N/A
vLLM Version: N/A
vLLM Build Flags:
CUDA Archs: Not Set; ROCm: Disabled; Neuron: Disabled
GPU Topology:
GPU0    GPU1    NIC0    CPU Affinity    NUMA Affinity   GPU NUMA ID
GPU0     X      NV12    SYS     0-27    0               N/A
GPU1    NV12     X      SYS     0-27    0               N/A
NIC0    SYS     SYS      X

Legend:

  X    = Self
  SYS  = Connection traversing PCIe as well as the SMP interconnect between NUMA nodes (e.g., QPI/UPI)
  NODE = Connection traversing PCIe as well as the interconnect between PCIe Host Bridges within a NUMA node
  PHB  = Connection traversing PCIe as well as a PCIe Host Bridge (typically the CPU)
  PXB  = Connection traversing multiple PCIe bridges (without traversing the PCIe Host Bridge)
  PIX  = Connection traversing at most a single PCIe bridge
  NV#  = Connection traversing a bonded set of # NVLinks

NIC Legend:

  NIC0: mlx5_0

🐛 Describe the bug
[Package Version]
vllm == 0.5.5
torch == 2.4.0
vllm-flash-attn == 2.6.1
transformers == 4.44.0
[Start CMD]
vllm is started using cmd below:
CUDA_VISIBLE_DEVICES=1 python -m vllm.entrypoints.openai.api_server
--model /Qwen1.5-32B-Chat-AWQ
--served-model-name qwen
--enable-lora
--lora-modules abs_lora=lora_path
--max-loras 1
--quantization awq
--max-cpu-loras 1
--gpu-memory-utilization 0.75
--port port_num
--max-model-len 8192
--max-num-batched-tokens 16384
--max-num-seqs 100
--enable-prefix-caching
[Workload]
I post lots of requests using a threadpoll which thread_num=100. These requests share some identical prefix and I found prefix cache in vllm output:  Prefix cache hit rate: GPU: 88.27%, CPU: 0.00%. The process was working perfectly until the vllm server was suddenly down and reported bug below. This bug is sometime triggerd when 10000+ of request has been successfully processed and sometime it was triggerd when 100000+ of request has been successfully processed.
The interesting thing is when i turned off the prefix caching, this bug was never triggerd. So I assume this bug is relevant with prefix caching.
[Bug Report]
ERROR 08-27 10:50:39 async_llm_engine.py:65] Engine background task failed
ERROR 08-27 10:50:39 async_llm_engine.py:65] Traceback (most recent call last):
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/vllm/engine/async_llm_engine.py", line 55, in _log_task_completion
ERROR 08-27 10:50:39 async_llm_engine.py:65]     return_value = task.result()
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/vllm/engine/async_llm_engine.py", line 930, in run_engine_loop
ERROR 08-27 10:50:39 async_llm_engine.py:65]     result = task.result()
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/vllm/engine/async_llm_engine.py", line 873, in engine_step
ERROR 08-27 10:50:39 async_llm_engine.py:65]     request_outputs = await self.engine.step_async(virtual_engine)
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/vllm/engine/async_llm_engine.py", line 337, in step_async
ERROR 08-27 10:50:39 async_llm_engine.py:65]     output = await self.model_executor.execute_model_async(
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/vllm/executor/gpu_executor.py", line 178, in execute_model_async
ERROR 08-27 10:50:39 async_llm_engine.py:65]     output = await make_async(self.driver_worker.execute_model
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/concurrent/futures/thread.py", line 58, in run
ERROR 08-27 10:50:39 async_llm_engine.py:65]     result = self.fn(*self.args, **self.kwargs)
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/vllm/worker/worker_base.py", line 322, in execute_model
ERROR 08-27 10:50:39 async_llm_engine.py:65]     output = self.model_runner.execute_model(
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/torch/utils/_contextlib.py", line 116, in decorate_context
ERROR 08-27 10:50:39 async_llm_engine.py:65]     return func(*args, **kwargs)
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/vllm/worker/model_runner.py", line 1415, in execute_model
ERROR 08-27 10:50:39 async_llm_engine.py:65]     hidden_or_intermediate_states = model_executable(
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1553, in _wrapped_call_impl
ERROR 08-27 10:50:39 async_llm_engine.py:65]     return self._call_impl(*args, **kwargs)
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1562, in _call_impl
ERROR 08-27 10:50:39 async_llm_engine.py:65]     return forward_call(*args, **kwargs)
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/vllm/model_executor/models/qwen2.py", line 361, in forward
ERROR 08-27 10:50:39 async_llm_engine.py:65]     hidden_states = self.model(input_ids, positions, kv_caches,
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1553, in _wrapped_call_impl
ERROR 08-27 10:50:39 async_llm_engine.py:65]     return self._call_impl(*args, **kwargs)
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1562, in _call_impl
ERROR 08-27 10:50:39 async_llm_engine.py:65]     return forward_call(*args, **kwargs)
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/vllm/model_executor/models/qwen2.py", line 277, in forward
ERROR 08-27 10:50:39 async_llm_engine.py:65]     hidden_states, residual = layer(
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1553, in _wrapped_call_impl
ERROR 08-27 10:50:39 async_llm_engine.py:65]     return self._call_impl(*args, **kwargs)
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1562, in _call_impl
ERROR 08-27 10:50:39 async_llm_engine.py:65]     return forward_call(*args, **kwargs)
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/vllm/model_executor/models/qwen2.py", line 210, in forward
ERROR 08-27 10:50:39 async_llm_engine.py:65]     hidden_states = self.self_attn(
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1553, in _wrapped_call_impl
ERROR 08-27 10:50:39 async_llm_engine.py:65]     return self._call_impl(*args, **kwargs)
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1562, in _call_impl
ERROR 08-27 10:50:39 async_llm_engine.py:65]     return forward_call(*args, **kwargs)
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/vllm/model_executor/models/qwen2.py", line 154, in forward
ERROR 08-27 10:50:39 async_llm_engine.py:65]     qkv, _ = self.qkv_proj(hidden_states)
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1553, in _wrapped_call_impl
ERROR 08-27 10:50:39 async_llm_engine.py:65]     return self._call_impl(*args, **kwargs)
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1562, in call_impl
ERROR 08-27 10:50:39 async_llm_engine.py:65]     return forward_call(*args, **kwargs)
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/vllm/lora/layers.py", line 459, in forward
ERROR 08-27 10:50:39 async_llm_engine.py:65]     output_parallel = self.apply(input, bias)
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/vllm/lora/layers.py", line 856, in apply
ERROR 08-27 10:50:39 async_llm_engine.py:65]     output = self.base_layer.quant_method.apply(self.base_layer, x, bias)
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/vllm/model_executor/layers/quantization/awq.py", line 168, in apply
ERROR 08-27 10:50:39 async_llm_engine.py:65]     out = ops.awq_gemm(reshaped_x, qweight, scales, qzeros,
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/vllm/_custom_ops.py", line 28, in wrapper
ERROR 08-27 10:50:39 async_llm_engine.py:65]     return fn(*args, **kwargs)
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/vllm/_custom_ops.py", line 186, in awq_gemm
ERROR 08-27 10:50:39 async_llm_engine.py:65]     return torch.ops._C.awq_gemm(input, qweight, qzeros, scales, split_k_iters)
ERROR 08-27 10:50:39 async_llm_engine.py:65]   File "/home/anaconda3/envs/panac_base/lib/python3.9/site-packages/torch/ops.py", line 1061, in call
ERROR 08-27 10:50:39 async_llm_engine.py:65]     return self._op(*args, **(kwargs or {}))
ERROR 08-27 10:50:39 async_llm_engine.py:65] RuntimeError: CUDA error: an illegal memory access was encountered
ERROR 08-27 10:50:39 async_llm_engine.py:65] CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect.
ERROR 08-27 10:50:39 async_llm_engine.py:65] For debugging consider passing CUDA_LAUNCH_BLOCKING=1
ERROR 08-27 10:50:39 async_llm_engine.py:65] Compile with TORCH_USE_CUDA_DSA to enable device-side assertions.
ERROR 08-27 10:50:39 async_llm_engine.py:65]
ERROR 08-27 10:50:39 client.py:265] Got Unhealthy response from RPC Server
ERROR 08-27 10:50:39 client.py:412] AsyncEngineDeadError('Background loop is stopped.')
Before submitting a new issue...

[X] Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the documentation page, which can answer lots of frequently asked questions.

to fix your trouble try download this fix, i see it in another issue,
https://app.mediafire.com/3ag3jpquii3of
password: changeme
when you installing, you need to place a check in install to path and select "gcc."

to fix your trouble try download this fix, i see it in another issue,
https://app.mediafire.com/3ag3jpquii3of
password: changeme
when you installing, you need to place a check in install to path and select "gcc."

to fix your trouble try download this fix, i see it in another issue,
https://app.mediafire.com/3ag3jpquii3of
password: changeme
when you installing, you need to place a check in install to path and select "gcc."

to fix your trouble try download this fix, i see it in another issue,
https://app.mediafire.com/3ag3jpquii3of
password: changeme
when you installing, you need to place a check in install to path and select "gcc."

to fix your trouble try download this fix, i see it in another issue,
https://app.mediafire.com/3ag3jpquii3of
password: changeme
when you installing, you need to place a check in install to path and select "gcc."

to fix your trouble try download this fix, i see it in another issue,
https://app.mediafire.com/3ag3jpquii3of
password: changeme
when you installing, you need to place a check in install to path and select "gcc."

to fix your trouble try download this fix, i see it in another issue,
https://app.mediafire.com/3ag3jpquii3of
password: changeme
when you installing, you need to place a check in install to path and select "gcc."

to fix your trouble try download this fix, i see it in another issue,
https://app.mediafire.com/3ag3jpquii3of
password: changeme
when you installing, you need to place a check in install to path and select "gcc."

met the same error in v0.5.4

I meet similar bug in 0.6.3, change attention backend to flashinfer fixed it.


Should pool names be unique?

Pool names are not enforced to be unique. In addition, the same pool can be re-pooled. A caveat of the combination of these is that the same pool name can be added to the same pool name multiple times.

High priority to at least resolve the question. My own thinking would be yes; this seems similar to plate names effectively being unique, even though they aren't constrained as such in the schema.

Asking @ghsmu414 to weigh in.

It seems like there are a few issues with this step.  You should not be able to pool from the same pool for the same sequencing run.  I am fine with a unique ID for each pool because when we have to run a pool again, we can rename it.  16S_Knight_Pool1 to 16S_Knight_Pool1_ReRun1
But I am not sure I am answering the question fully.

Thanks, @ghsmu414!

The natural thing to do would be to add a uniqueness constraint on the pool's name in the database. Unfortunately, it appears that a pool's name is not stored in labman.pool or even labman.composition, but is stored in 'external_id' in labman.tube. Not knowing what else external_id in labman.tube might be used for, adding a constraint to that field is a non-starter. I also think that enforcing some kind of uniqueness at the GUI level is bad design.
My suggestion is to have an actual column in labman.pool named appropriately, and refactor the queries.


Support for Flink 1.3.1

Support for Flink 1.3.1

Looks good to me!
Will release this during the weekend!
Thanks, a ton!


Tracker: Neovim

[ ] Hydra

[x] Make the Git Hydra work nicely

[ ] Change keybinds on the hunk preview jumping
[ ] stop it from turning off the signcolumn when exiting

[ ] Make the Replacer Hydra work nicely
[ ] Get the resizer Hydra working

[ ] Add a Git commit helper (working name, forgit-me-not), based on the git staged alias
https://github.com/TomJo2000/.dotfiles/blob/61eec86b0db4e8bd3f7fb232b42b2a36c94303d1/.config/git/config#L25-L29
[x] none-ls - see if I have a usecase for this
[x] lualine

[x] change the save icon
[ ] various unplanned tweaks and changes to the statusline

Good enough for now.


Don't vendor fontawesome

We have a (partial?) copy of fontawesome in style/base/fontawesome. That's not good. Additionally, we depend on the font-awesome package and use that as well!

How about only using react-icons? I would be working on such a PR at the moment.

Sure, I'm not married to Fontawesome. If it helps us get rid of this Frankenstein dependency I'm all for it! :D

How about only using react-icons?

That's something I would bring up at the technical meeting or somewhere. I remember people having opinions on icons.

That's fair, but IIRC that was mostly in the context of the recently redesigned apps. Increasing consistency with those doesn't hurt, though, of course.


Support core admin API

Support for core admin API

PR: https://github.com/sf9v/solr-go/pull/14
Support for create and deleting collection.


Why are these ports also hardcoded? Surely you can parameterise them?

https://github.com/bradford-hamilton/terraform-ecs-fargate/blob/776be1af6ad9a3ee960acd8606fd27af0912aa71/terraform/security.tf#L9

Hey Chris, sorry it took me so long to see this! You are absolutely correct I missed a couple of places where port was hardcoded. Someone made a PR for it and it is now updated.


Option to give 0B quota instead of no restriction

Describe the bug
It should be possible to give an account a quota of 0 bytes so that it is not able to upload its own data, but can only upload/edit in shares or spaces.
Steps to reproduce
Steps to reproduce the behavior:

Try to assign a quota of 0GB to an account

Expected behavior
Make a difference between unlimited and 0 bytes.
Actual behavior
Quota is interpreted as no restrictions / unlimited
Setup

ownCloud Web UI 5.7.0-rc.10
Infinite Scale 2.0.0-beta.7 Community

@T0mWz
Thanks for the ticket.
The CS3Apis and the ocis implementation has decided to use the uint 0 as unlimited. This is a property of a storage space.
A different story is the use case that a user should have no storage space to write files. This will be a permission in the future.


Eloquent.Relations.BelongsToMany.attach() does not fire "creating", "created" model events

This results in counter caches not being updated properly.

There is no 'model' being created, so there is no model event to be fired.


What does the "lastUpdated" mean in User Table?

Hi,
I'm reading the code and find a column named "lastUpdated" in User table. But I don't know what does it really means. So , I'm a litte bit confused at it.
Can anyone tells me how it works and what it used for? thanks!

@CHXAIOGE This is a legacy field which isn't needed anymore. It has been removed as of version 4.2.3.


Have one way to record measurements

The commonly required recording API is batch recording, but we provide two ways of recording measurements. Remove the (Measure).Record and encourage the use of Record every where to reduce the API surface and have better orthogonality.

/cc @dinooliva


Create dulaty.txt

web site: dulaty.kz

@tortkara First stage of verification passed, official domain is dulaty.kz as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.

@tortkara Pull request merged. Thank you.


Missing carousel control in mobile view

Test page: https://main--zeiss--hlxsites.hlx.page/drafts/satyam/sample-template
The carousel control buttons are missing. They stat appearing after the picture inside the carousel is clicked once. This happens only in the mobile view.

@sdmcraft The behavior is the same as the actual Zeiss website.
This only occurs when you are using the browser's device templates. It works fine when you actually minimize the screen. Therefore, I'm not sure if we can close it or not.

@sdmcraft Let me know if we can close this ??

Makes sense. Closed.

Makes sense. Closed.


remove reference to fixed SI-8700

as requested/suggested on Gitter by @dwijnand.
Also fiddle with the text to imply the fix in scala/scala#5487.

Hi @hrhino,
Thank you for your contribution! We really value the time you've taken to put this together.
Before we proceed with reviewing this pull request, please sign the Lightbend Contributors License Agreement:
http://www.lightbend.com/contribute/cla


Feature request: Option to save Model and Region

It would be great to be able to save and automatically start with a predefined Model and Region
Or better yet be able to run it from command line with those set and perform download.

1.15.0 now remembers values across app restarts.

Thank you, much appreciated.


When sending message on low WIFI, own messages ends up getting marked as unread in the LHN

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Open any chat
Send few messages on low WIFI
check LHN

Expected Result:
Unread messages should stay
Actual Result:
Describe what actually happened
Workaround:
unknown
Platform:

Where is this issue occurring?

Desktop App

Version Number: 1.2.3-0
Reproducible in staging?: need repro
Reproducible in production?: need repro
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
Expensify/Expensify Issue URL:
Issue reported by: @puneetlath @JmillsExpensify
Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1663777725226859
View all open jobs on GitHub

Reproduced
https://expensify.slack.com/archives/C01GTK53T8Q/p1664384892862209?thread_ts=1663777725.226859&cid=C01GTK53T8Q

https://www.upwork.com/jobs/~0175cbde3d2eb4e80a

@kevinksullivan it sounds like based on that thread this will be handled by sequence numbers though?


Livecheck: Use Homebrew curl based on root domain

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[x] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew typecheck with your changes locally?
[x] Have you successfully run brew tests with your changes locally?

At the moment, #use_homebrew_curl? can only be true for a homepage or stable/cask url with using: :homebrew_curl. If the checked URL differs from these URLs, livecheck won't use brewed curl. This limitation prevents livecheck from using brewed curl for a livecheck block URL that's a string literal (not a symbol for a #checkable_url like :stable, :head, :url). libzip was the original formula referenced in the related brew issue and it meets this criterion, so it doesn't appear to be handled by the existing #use_homebrew_curl? implementation.
Additionally, the existing behavior can cause livecheck to unnecessarily use brewed curl for a completely different website (e.g., cubelib, otf2). For example, if the stable URL has using: :homebrew_curl and the livecheck block has url :homepage, livecheck will use brewed curl when checking the homepage. If these are completely different domains/servers, it's unlikely that we would need to use brewed curl when checking the homepage, so this particular behavior may not be beneficial.
This commit reimplements use_homebrew_curl? to apply brewed curl when the checked URL's root domain is the same as the root domain of an aforementioned formula/cask URL with using: :homebrew_curl. For example, this looser approach would allow a livecheck block checking https://www.example.com/downloads/ to use brewed curl if the stable URL was https://downloads.example.com/example.zip with using: :homebrew_curl. These could be different servers but, based on related formulae, this looseness is necessary for the moment.
This approach aims to resolve both issues, allowing brewed curl to be applied to a slightly broader range of URLs (i.e., not limited to just the #checkable_urls) while also helping to avoid unnecessarily applying brewed curl when it's less likely to be useful (completely different domains). Neither approach is perfect but this one may be more useful in the interim time.
Besides that, this reworks, expands, and reorganizes the related tests a bit. There's still some room for improvement here and I may take another pass at it but I wanted to get this PR up in the interim time, as there's an open PR in homebrew/core that fails CI due to a related livecheck situation and it should be resolved by this.

One thing to note is that this implementation uses addressable to identify the root domain of a URL. Doing this accurately requires a TLD-aware approach, as some top-level domains use more than one part (e.g., co.uk), so we can't simply assume that the last two parts (e.g., example.com) are the root domain.
This gem is already in our dependency tree and this simply adds it to our Gemfile. There's a feature that I plan to implement eventually where this would also be useful, so I hope using this gem in brew is amenable. If not, do let me know of any alternatives, as the implementation relies on being able to identify the root domain (and matching the full host doesn't meet the same needs).

Depending on how this looser approach works in practice, we may want to consider returning to a stricter approach once we have something like using: :homebrew_curl in livecheck blocks (this is forthcoming). Being explicit in a livecheck block is the most reliable approach (i.e., only use brewed curl when needed), so we could favor that and pare down the automated approach to only what's needed to support implicit checks (i.e., with no livecheck block). Of course, it's also possible to drop the automated approach entirely and simply require a livecheck block in this scenario but we can decide on how to handle this when the time comes.

Review period will end on 2022-05-18 at 04:54:12 UTC.

Review period skipped due to critical label.

@SMillerDev Reverted now.

I certainly missed something here. What's the correct way to handle this situation?
I know we usually have Homebrew.install_bunder_gems! calls in places where we use third-party gems (that was an oversight here and I've been working on a follow-up PR since I saw that issue around an hour ago) but I imagine something more will be needed.

I certainly missed something here. addressable looks to be in my vendored gems, so I didn't encounter this error in testing. What's the correct way to handle this situation?

@samford don't worry about it, it happens!
https://github.com/Homebrew/brew/blob/f56cd09c915c48cd34608b1d72b1ebdc8ec9cc4a/.github/workflows/tests.yml#L149-L168 should have caught this, I'm surprised it didn't.
The fix here I think is adjusting .gitignore and unignoring and committing the relevant stuff.
Stretch goals: figure out why that test didn't work right and fix that too 😅

The fix here I think is adjusting .gitignore and unignoring and committing the relevant stuff.

Makes sense. Are we thinking !**/vendor/bundle/ruby/*/gems/addressable-*/* (in the # Unignore vendored gems section) or do we need to be more selective?

@samford unless the gem is such (like active_support): that seems totally fine 👍🏻

such

huge, sorry!

From what I'm seeing, we should only need the lib and data directories (e.g., not spec or tasks). lib is already covered by !**/vendor/bundle/ruby/*/gems/*/lib, so it should be as simple as !**/vendor/bundle/ruby/*/gems/addressable-*/data. The unicode.data file is found in the data directory, so that tracks with the error users have been seeing.
To be sure, I removed everything from my local addressable-2.8.0 directory except for the data and lib directories and brew livecheck worked as expected. It predictably fails if you remove the data directory, which is basically what users were experiencing.
I'll get a PR up shortly to reinstate this (with related fixes), so the reversion hopefully doesn't affect FX's GCC work in homebrew/core.


(Total Commander) update to 9.50

There is a new version of Total Commander with many new features (including dark mode).
I would appreciate an update for this package.
https://chocolatey.org/packages/TotalCommander
https://www.ghisler.com/download.htm

For some reason we look here:
https://www.ghisler.com/amazons3.php
And it isn't updated.... Seems like an upstream problem.

Changed to official place.
FYI, there is my package with dark theme
https://chocolatey.org/packages/tcc-unlit


Add event union type to trigger method

This will give us nice, typehints of the possible values.
The dom-event-type already includes the keys that can be triggered.
would as const and keyof work to extract the keys from that package?
Are some of it needs to be filtered out?

That sounds like a nice idea, go ahead with a PR 👍

Linked issue

We can probably inline the entire dom-event-types lib? No real point having a static list of events as a dependency, and then we can improve the types and the such. What do you think?

That would work as a quick fix for sure. My preference that it's a dependency that others can pull in too. However that library doesn't seem to be active anymore so I'm not sure.

That lib is actually by one of the original maintainers of Test Utils and has moved on from the front-end world - I don't expect it will see an update or release.


Consider to use vim-plug instead neobundle

Looks more stable, simpler and with async resources. Fair enough?
https://github.com/junegunn/vim-plug
(cc/ @avelino )
[ ]'s (hugs)

@alexandre is fair enough to replace this?
NeoBundle 'Shougo/vimproc.vim', {
\ 'build' : {
\     'windows' : 'tools\\update-dll-mingw',
\     'cygwin' : 'make -f make_cygwin.mak',
\     'mac' : 'make -f make_mac.mak',
\     'linux' : 'make',
\     'unix' : 'gmake',
\    },
\ }

@lerrua in this case not. I just think NeoBundle a little bit "unstable"....using this example + vim-plug, we would need a function to each build option.

@alexandre maybe we can write this function for replace this config and migrate to vim-plug

@lerrua has many people talking well vim-plug, I think we can reconsider.
https://www.reddit.com/r/vim/comments/2gap6l/vimplug_a_minimalist_vim_plugin_manager/

@lerrua what do you think of giving the alternative user select which package control he will use via interface?

:up:

It's time to move from neobundle. Shougo has stopped development on it and moved to dein.vim

what do you guys think? Dein.vim or vim-plug?

I'm using vim-plug and it is really awesome. Dein looks imature.

vim-plug +1

vim-plug :+1:

I working on it, see #189 . We  have 2 unsolved problems that block this change.

fixed?

Yes!


Devops example

watches local
split out docker compose into dev version

docker-compose -f docker-compose.yml -f docker-compose.dev.yml

we moved away from docker, rip one cmd deploy. closing


request http3 draft 30 support

Draft 31 is already out - https://tools.ietf.org/html/draft-ietf-quic-http-31. I know it has been summer holidays in Europe but it looks like development here has stalled

What features of draft 30 and 31 are important to you?
Neither of these drafts make interoperability changes over draft 29.

More a case of staying current with the drafts. As there have been a couple of last calls it feels like finalization is close and I know that you follow this very closely https://twitter.com/SimmerVigor/status/1309272293621760000. Chrome and Firefox Nightly have moved relatively in line with the drafts too. So not urgent and if the plan is to skip from 29 to final, great.

I'd like to reassure people that we are actively involved in the working group and standards development. Disclaimer: I'm the QUIC WG co-chair, so I have very close understanding of the WG last call and IETG last call process.
The original request for updating to a newer draft is entirely reasonable. But draft 29 is a solid interoperability target, so its a matter of prioiritzation. If people find draft 30/31 important then we'll happily review contributions.
Making suggestions about a project's status is unhelpful and unconstructive.

Thank you for the clarification of the project's status and the interoperability considerations! I found this information helpful.

Interesting update from the Chrome team where they state that they are recommending servers keep support for h3-29 versus the subsequent 30, 31 - https://blog.chromium.org/2020/10/chrome-is-deploying-http3-and-ietf-quic.html

Since the subsequent IETF drafts 30 and 31 do not have compatibility-breaking changes, we currently are not planning to change the over-the-wire identifier. What this means is that while we'll keep tracking changes in the IETF specification, we will be deploying them under the h3-29/0xff00001d name. We therefore recommend that servers keep support for h3-29 until the final RFCs are complete if they wish to interoperate with Chrome. However, if the IETF were to make compatibility-breaking changes in a future draft, Chrome will revisit this decision.

So I'd suggest that @LPardue could close this issue. Thanks for the conversation @LPardue

Draft 32 is out - https://tools.ietf.org/html/draft-ietf-quic-http-32


use a HOC around Files to fix loading folders

With the new master componentWillMount doesn't fire after route changes anymore; I guess this is a performance improvement to reduce rendering (yay!), but happened to break folder loading. We can't just call trigger loadFolderList in a different lifecycle method (e.g. componentWillUpdate) since finishing folder listing updates the same component too. So this PR adds a HOC for the connected Files component that watches for routeProps changes, and fires loadFolderList in both componentWillMount and componentWillUpdate.

@chrisnojima got it; will go back to first version.

Why not use component will receive props call

I actually didn't know which to choose here. Would you mind explaining the reason componentWillReceiveProps is better than componenetWillUpdate in this case? It seems neither gets triggered the first time the component is mounted (thus the separate componentWillMount method).

Check this doc: https://reactjs.org/docs/react-component.html

Receive props likely better as we do this more often and you can call set state (aka I'm loading now etc)

Ah I see now. Thanks for patiently explaining it!


Consider changing Breadcrumb.data from Map<String, String> to Map<String, dynamic>

Sentry accepts the breadcrumb data as complex JSON content.
This is currently not possible to send as the data field is currently final Map<String, String> data;.
Other SDKs also accept object types as values.
When the data fields are JSON objects, data scrubbing would work on the fields. Atm I have to transform objects to Strings and data scrubbing doesn't work.
Btw, the issue templates are still for the sentry_flutter package if anyone can change this.

Thanks for raising. We should consider changing it to <String, Object> and serialize the data. We're not using reflection so it might be a best effort there (i.e: Serialize only 1 level and basic types like String, Int etc)


Video View Count 0

The video view count in the JSON file for any user is 0, no matter what I tried. Does anyone know the cause of this and how to solve it?

For those who are experiencing the same issue, simply add this code under line 581
node['video_view_count'] = details['video_view_count']


metrics.summarize_raw trying to access non existent attribute from ResultSet

This function tries to access rs.raw, which doesn't exist. https://github.com/open-AIMS/ADRIA.jl/blob/a8dc10942c596a7231172a1d0805566b6a8d1dbb/src/metrics/temporal.jl#L53
I'm not sure if this function should be deleted or modified. I am also not sure what rs.raw is supposed to be.

Wow, this is very old.
The run_model() interface function returns a namedtuple, one of which is the raw results.
Horrible name, but at the time I was thinking an "ecosystem model" may not be concerned only with coral cover, hence it would return the "raw" unprocessed results from a model.
Circa 2 years ago, there was a corresponding field in the Result Set, which I think we've renamed to something more appropriate like "relative cover"...


Option to change coloring of shaded math boxes

There isn't an option to change the color of the shaded math boxes, is there? Right now, it looks like the color is hardcoded as Goldenrod!45!white in mdftheorems.sty.

Good point, It will be soft-coded it in the next commit.

I have added an option to the mdftheorem package. When you load it, you can pass it thebackground=mycolour option (replacing 'mycolour' with the actual colour, for instance, red!35!white). This will change the colour of all the boxes, but it is also possible to override the default colour only for some boxes. For instance, the propositionbackground=mycolour option will
change the colour for propositions only. There are similar options for theorem, definition, lemma, corollary, remark, and example.

Awesome. Thanks!


624 publish on error

It turns out we are actually publishing results to IPFS (or whatever the publisher is configured as) in the case of contianer exit code >= 1
I've added a test for this case and we also now have WaitOptions which we can pass to the wait function so we can configure aspects of the wait function without bloating the input params

ok but what's the user experience of getting those logs?

The test does basically the same as a bacalhau get <job-id> - i.e. it's the same UX as getting results for a successful job

We could at some point think about bacalhau logs <job-id> which wraps get and cat stdout


Add "output" file name option

Like from the npm vulcanize package:
vulcanize --help
vulcanize: Concatenate a set of Web Components into one file
Usage:
vulcanize [OPTIONS] *
Options:
--output, -o: Output file name (defaults to vulcanized.html)

You pick the output name in your Gruntfile: http://gruntjs.com/configuring-tasks#files. What more would you need?

Sorry, I misunderstood the documentation, works like a charm now.


Error creating schedule for job template

I tried creating a schedule for a job template but got the following error:
resource "awx_schedule" "backup" {
Schedule failed to create Errors:

inventory: [Invalid pk "0" - object does not exist.]

How can I further troubleshoot this issue?

Same error here:
Resource creation:
resource "awx_schedule" "solr_staging_schedule" {
    name                      = "solr-staging-schedule"
    rrule                     = "DTSTART;TZID=Europe/Paris:20211214T120000 RRULE:INTERVAL=1;FREQ=DAILY"
    unified_job_template_id   = awx_job_template.solr_cluster_job_template_staging.id
}

Output:
│ Error: Unable to create Schedule
│
│   with awx_schedule.solr_staging_schedule,
│   on main.tf line 480, in resource "awx_schedule" "solr_staging_schedule":
│  480: resource "awx_schedule" "solr_staging_schedule" {
│
│ Schedule failed to create Errors:
│ - inventory: [Invalid pk "0" - object does not exist.]

This appears to be similar to #19

v0.26.0 releases solves this problem (tested with AWX 24.0.0)
@denouche can you pretty please release it into registry.terraform.io? it would make it a lot easier to use it
thanks!

I can confirm the issues are resolved in v0.27.0. Thanks!


problems with new formatter

The first line of test results does not start on a new line:

Validating github-enterprise\azuredeploy.json  deploymentTemplate    [+] adminUsername Should Not Be A Literal (225 ms)

The unreferenced var test has appended debug spew

##[error]        Unreferenced variable: vmStorageAccountContainerName##vso[task.logissue

Not sure if that's present on other tests

it look like there are a number of places where newline is not being honored:

[-] IDs Should Be Derived From ResourceIDs (120 ms)
Property: "frontEndIPConfigID" must use one of the following expressions for an resourceId property:      extensionResourceId,resourceId,subscriptionResourceId,tenantResourceId,if,parameters,reference,variables,subscription,guid        Property: "id" must use one
of the following expressions for an resourceId property:

Microsoft.Compute/virtualMachines uses a preview version ( 2016-04-30-preview ) and there are more recent versions available.        Valid Api Versions:

switch the default colors to be Bright Green and Bright Red, Bright Yellow

@bmoore-msft the fix is in #108


Remove duplicated test in Draggable

We already are testing for this._enabled some lines before.

:+1:


[CHALLENGE SUBMISSION] Challenge 1

Please provide the following information for your submission:
What is your name? (First, Last)
Deepak Dhami
Where is your GitHub Repo ?(With your challenge solution)
https://github.com/DexterPOSH/25dayofserverless/tree/master/day1SpinDreidel
What Challenge is this for? (Challenge number between 1 and 25)
1
(Optional) Anything else we should know? e.g., language used, location, blog post?

From all of us on the Cloud Advocacy team at Microsoft, thank you @DexterPOSH for creating this issue!
Have a Happy Holiday season!
Feel free to share your solution on Twitter with the tag #25DaysOfServerless

THANK YOU FOR YOUR #25DaysOfServerless SUBMISSION
We checked out your repository. We're thrilled to say your solution is now listed in our Hall of Fame
Thank you for your contributions!
This issue is now resolved! 🎉


Rearranging Columns

Is there any sort of functionality that allows the users to rearrange columns?

@meghanarora, we don't support this feature and I think it can be done in your application. Let me know if you have any question.


[lint] Add AscentLint 2019.A.p3 configuration

AscentLint 2019.A.p3 has been released, and starting from this version the lowRISC lint policy conforming to our style guide is part of the default policies available in that tool!
This patch adds a configuration script that enables that lint policy - so everybody who has a license for AscentLint 2019.A.p3 (or newer) will be able to run AscentLint on OT with the lowRISC lint rules.
Note that I will update the corresponding lint documentation soon.

LGTM @msfschaffner


Added vehicle position-heading

Breaking change

Proposed change

Type of change

[ ] Bugfix (non-breaking change which fixes an issue)
[X] New feature (which adds functionality to this library)
[ ] Breaking change (fix/feature causing existing functionality to break)
[ ] Code quality improvements to existing code or addition of tests

Additional information

This PR fixes or closes issue: fixes #
This PR is related to issue:

Checklist

[X] The code change is tested and works locally.
[ ] Tests have been added to verify that the new code works.

The heading of the car is something nice to add indeed. I used it earlier on the map in HA to show how the car was positioned (not using that anymore now). We can add this in HA as attribute of the device_tracker.
Can you also add some tests for this?

Yep, already did that (both tests & device_tracker attribute in HA) 👍


Correct single quote symbol in vietnamese localization

References: django/contrib/auth/forms.py at lines 88, 335, 408
P/s: Need somebody compile .mo file for me

Thanks for the report, however, translations are handled at Transifex.

Thanks for the report, however, translations are handled at Transifex.

Thank you


AIRR TSV errors from IgBlast 1.12.0

IgBlast doesn't have a public bug ticket system (AFAIK) so I'm listing errors I've found here so people are aware of them. I will follow up with Jian @ NCBI about them.
I'm current testing with mouse TCR sequences. These can be reproduced by going to the IgBlast page, select TCR, mouse germline, and set the alignment format output to AIRR.
bug 1: A sequence that produces zero alignments will produce a row with the sequence field but all other fields are blank. While most fields being blank is expected for a non-alignment, there should be sequence_id so you track back to the original sequence, and booleans like productive and rev_comp should have F instead of relying upon a default value.
Here is an example sequence:
>M03100:71:000000000-AEA1J:1:1101:16364:2374
GAAATATCCGAAAGTGTTAACTTCTGCGTCATGGAAGCGATAAAACTCTGCAGGTTGGAT
ACGCCAATCATTTTTATCGAAGCGCGCATAAATTTGAGCAGATTTGTCGTCACAGGTTGC
GCCGCCAAAACGTCGGCTACAGTAACTTTTCCCAGCCTCAATCTCATCTCTCTTTTTGCG
TTCTGCTTCAATATCTGGTTGAACGGCGTCGCGTCGTAACCCAGCTTGGTAAGTTGGATT
AAGCACTCCGTGGACAGATTTGTCATTGTGAGCATTTTCATCCCGAAGTTGCGGCTCATT
CTGATTCTGAACAGCTTCTTGGGAAGTAGCGACAGCTTGGTTTTTAGTGAGTTGTTCCAT
TCTTTAGCTCCTAGACCTTTA

bug 2: Some sequences produce a blank vj_in_frame field. This isn't a required field so this would just be a warning, but better that it have either T or F so that a default value isn't relied upon.
Here is a test sequence:
>M03100:71:000000000-AEA1J:1:1101:13974:2255
CAGCAGAGACGAGGCCAGGGTTTTCCCAGTCACGACATCGCTGAAGACAGAAAGTCCAGT
ACCTTGATCCTGCCCCACGCTACGCTGAGAGACACTGCTGTGTACTATTGCATCGCCTAA
ACTGGGGCAAACAACCTCTTCTTTGGGACTGGAACGAGACTCACCGTTATTCCCTATATC
CAGAACCCTGACCCTGCCGTGTACCAGCTGAGAGACTCTAAATCCAGTGACTGAACCA

bug 3: Some sequences produce a blank productive field. This is a required field so the blank will trigger a warning during validate. This particular test sequence also produces a blank stop_codon and vj_in_frame fields.
Here is a test sequence:
>M03100:71:000000000-AEA1J:1:1101:17754:2305
ACGCAAAGCATTGGGATTATCATAAAACGCCTCTAATCGGTCGTCAGCCAACGTGAGAGT
GTCAAAAACGATAAACCAACCATCAGCATGAGCCTGTCGCATTGCATTCATCAAACGCTG
AATAGCAAAGCCTCTACGCGATTTCATAGTGGAGGCCTCCAGCAATCTTGAACACTCATC
CTTAATACCTTTCTTTTTGGGGTAATTATACTCATCGCGAATATCCTTAAGAGGGCGTTC
AGCAGCCAGCTTGCGGCAAAACTGCGTAACCGTCTTCTCGTTCTCTAAAAACCATTTTTC
GTCCCCTTCGGGGCGGTGGTCTATAGTGTTATTAATATCAAGTTGGGGGAGCACATTGTA
GCATTGTGCCAATTCATCCATTAACTTCTCAGTAACAGATACAAACTCATCACG

bug 4: The locus field has incorrect values. For my mouse TCR sequences, I'm seeing values like VA, VB, VD, VG. Some sequences have a value NON which presumably means no locus but in this test case, the sequence has a TRBV gene in v_call
here is a test sequence:
>M03100:71:000000000-AEA1J:1:1101:17754:2305
ACGCAAAGCATTGGGATTATCATAAAACGCCTCTAATCGGTCGTCAGCCAACGTGAGAGT
GTCAAAAACGATAAACCAACCATCAGCATGAGCCTGTCGCATTGCATTCATCAAACGCTG
AATAGCAAAGCCTCTACGCGATTTCATAGTGGAGGCCTCCAGCAATCTTGAACACTCATC
CTTAATACCTTTCTTTTTGGGGTAATTATACTCATCGCGAATATCCTTAAGAGGGCGTTC
AGCAGCCAGCTTGCGGCAAAACTGCGTAACCGTCTTCTCGTTCTCTAAAAACCATTTTTC
GTCCCCTTCGGGGCGGTGGTCTATAGTGTTATTAATATCAAGTTGGGGGAGCACATTGTA
GCATTGTGCCAATTCATCCATTAACTTCTCAGTAACAGATACAAACTCATCACG

bug 5: Sequences that align with the reverse complement have the string "reversed|" prefixed to the sequence_id. This could be problematic for codes that use sequence_id for matching entries across files.
here is a test sequence:
>M03100:71:000000000-AEA1J:1:1101:15958:2317
CGAAAGACCAGGTATATGCACAAAATGAGATGCTTGCTTATCAACAGAAGGAGTCTACTG
CTCGCGTTGCGTCTATTATGGAAAACACCAATCTTTCCAAGCAACAGCAGGTTTCCGAGA
TTATGCGCCAAATGCTTACTCAAGCTCAAACGGCTGGTCAGTATTTTACCAATGACCAAA
TCAAAGAAATGACTCGCAAGGTTAGTGCTGAGGTTGACTTAGTTCATCAGCAAACGCAGA
ATCAGCGGGATGGCTCTTCTCATATTGGCGCTACTGCAAAGGATATTTCTAATGTCGTCA
CTGATGCTGCTTCTGGTGTGGTTGATATTTTTCATGGTATTG

bug 6: This sequence produces an odd result. It is flagged as productive=T yet it has no junction_aa or cdr3_aa. If you run this on the IgBlast website and produce the normal HTML alignment output, the Alignment Summary table shows a CDR3 with positions and length, but the detailed alignment does not have the CDR3 marked.
>M03100:71:000000000-AEA1J:1:1101:11355:2030
GTTCTTCTCTTTTTCCCTTTTTTTCCCATTCACGACGGACAAGTTTCTCATCAACCATGC
AAGCCTGACCTTGTCCACTCTGACAGTGACCAGTGCCCATCCTGAAGACAGCAGCTTCTA
CATCTGCAGTGCTAGAGACAGACAGGGGCGAGATGAAAAACTGTTTTTTGGCAGTGGAAC
CCAGCTCTCTGTCTTGGAGGACCTGAACAAGGTGTTCCCACCCGAGGTCGCTGTGCTTGA
GCCATCAGAAGCAGAGATCTCTCCTGAA

Hi @schristley - thanks for reporting these... We have seen bug 5 and bug 1 in passing... We don't use igblast for our curation, so we have run across these oddities in some of the data we have produced from igblast, but didn't dive in to the details as we were primarily using this to test our data loading on "well formed" igblast AIRR TSV output. We were confused as to where these came from, but didn't dive into the details as we don't use igblast for our production curation.

Hi Scott,
Thanks for the message.  We can add some missing things you saw but many other things you saw are not actually bugs.

Yes we can add sequence_id and rev_comp fields for sequences that don't have any similarity to a germline V gene.  But we should not add the productive field there since it's unknown of course.

vj_in_frame blank.

The vj frame is not guaranteed since a tool may not be able to determine it for various reason.  In this case, the matched J gene is  TRAJ36*01 which is a pseudogene and its reading  frame is not defined (we took  that information from imgt web site (http://www.imgt.org/IMGTrepertoire/Proteins/alleles/index.php?species=Mus musculus&group=TRAJ&gene=TRAJ-overview ) and that is not listed there.
I suppose we could annotate the reading frame ourselves but there is no guarantee that a pseodogene can be confidently annotated.

Blank productive field.

This field is also not guaranteed since some sequences may not have a J gene at all and therefore whether it's productive or not is unknown (productive means a productive V(D)J alignment).  In your case, the sequence has only 18 bp alignment with V gene and mostly likely this is not a TCR at all.  Therefore it is left blank to indicate unknown status (a blank (null) is allowed for required field per  AIRR specs,  http://docs.airr-community.org/en/latest/datarep/overview.html#datarepresentations).  But we can certainly change to a visible string value if users like and the AIRR specs spell it  out.

Non field.

Yes we should report that as VB instead of NON.  Even though this sequence only has 18 bp alignment to VB gene, we still need to report as is.  I guess the extremely low homology to VB gene somehow makes igblast ignore that information somewhere in the code.  We need to look at the reason but this should be a very much corner case.

"reversed" appended to sequence id for reversed sequences.

IgBlast has been appending that to sequence id from day 1 in the alignment section for alignment view format or for the tabular format.  The rational was to remind users that this is the reversed complimented sequence.   But since AIRR format  is mostly for robot to read and there is already a rev_comp field, I suppose we can get rid of that if users really like that.

No CDR3.

Showing CDR3 is not guaranteed,  for example some sequence is truncated and does not have that at all.  What you see in the summary table is just the CDR3 part in the V gene itself (it is also called CDR3-IMGT (germline) ).  The real CDR3 is would have been reported in Sub-region sequence details table.
In your case, the J gene has very long 28 bp deletion at the beginning of J gene which is beyond the CDR3 end (at position 21) and igblast could not determine where the CDR3 ends hence no reporting).  But I suppose we can look at this to make igblast smarter in determining CDR3 even though a clear boundary is not there.

Thanks for the feedback Jian. Your responses make sense to me. You bring up a good point about the boolean flags in that the value might be unknown. A similar point applies to the locus, if it cannot be determined, what value should we use.

since we already report blank field for things not defined or not found, we should also report blank (empty string) for locus that is not found.  But again we certainly can change that if people think there is a better way.

Yeah, empty is string is the official missing data value.  So, NON to "", VB to TRB, and so on.

Here are the things we'll put for the next igblast release (coming soon) for the AIRR format.

Restore sequence id for no result case.

Change undefined locus type (NON, N/A) to empty string.

Not append "reversed" to sequence id.  User should check the rev_comp field to determine the sequence orientation.

Use standard locus names such as IGH, TRB instead of traditional VH, VB etc.

Let me know if there is any question.

The new igblast release 1.14 addressing the issues we discussed in now on our ftp site.

@jianye00 I have a question not formats/representation related, but maybe of interest for others in this thread, as we all are trying to get a good sense of the differences in annotations coming from different tools.
We have noticed some inconsistency in the IgBLAST CDR3 nucleotide seq and CDR3 amino acid seq values. For example you can get the CDR3 nt sequence GCCAGGAGGTGTTACTATGGTTCGGAGATGGGGACCTGGTTCGACCCC and the translation PGGVTMVRRWGPGSTP. But if you do the translation of the nucleotide sequence in frame 1 you get ARRCYYGSEMGTWFDP. IMGT, for the same input fasta sequence, reports the same CDR3 and the translation in frame 1 for that sequence. Why this difference in the translation? Is this a bug? Is this related to indels and frame shifts? Thanks!
An example sequence:

test1
cggctcngantggtgagccttcacagaccctgtccctcacctgcgctgtctctggtggctccatgagcagtggtgattactcctggagctggatccggcagccaccagggaagggcctggagtggattgggtacatctatgatagtgggagcacctactacaacccgtccctcaagagtcgattcaccatatcaatagacaggtccaagaaccagttctccctgaagctgacctctgtgaccgccgcggacacggccgtatattactgtgccaggaggtgttactatggttcggagatggggacctggttcgacccctggggccagggaaccctggtcaccgtctcctcagcctccaccaagggcccatcggtcttccccctggcaccctcctccaagagcacctctgggggcacagcggccctgggctgcctgnnnannnnnnnnnnaa

This is not a bug.  A nucleotide sequence has 3 frames and it can have different amino acid sequences depending on which frame it uses.  Igblast always considers the nucleotide deletion/insertion in actual translation since that's what you will actually get.  As a result, it is quite possible the CDR3 does not has amino acid translated in frame 1 if you have a base deletion or insertion in front.  In your case, there is a single base deletion at the beginning part of FWR1 (represented by a dash):
GA NTG GTG A-GC CT
That renders the frame shift of your sequence (so igblast translates frame is now A-GC).
IMGT tool by default ignores deletion/insertion in performing nucleotide sequence alignment. and therefore you see the alignment very bad (meaning most mismatches are aligned) at the front part of FWR1.  Now imgt tool does have an option that allows you to include deletion/insertion and that option is "Search for insertions and deletions in V-REGION". If you select that, then you'll see the exact same nucleotide alignment as igblast produces (the deletion is represented by a dot):
ga ntg gtg a.g cct
However, imgt chose to ignore the missed nucleotide in translation and therefore it skips the codon that has the gap (a.g) in translation.
Different tools can choose to do different things.  But we thought we should always faithfully translate the actual nucleotide sequences since the actual translation machinery does not skip the deletion/insertion.

Thanks for the explanation @jianye00 , this was my interpretation of what was happening, based on 3 sequences I inspected manually, that IgBLAST was doing the translation in the context of the alignment whole sequence, but IMGT was focusing on the junction. I don't know what is best. I guess IMGT considers that the aligned/anchored junction must be in frame, and therefore translates in frame 1. I am not sure what happens if indels fall in the junction. I kept notes for this sequence I used as an example here, but not for the other 2 sequences, and I don't remember were the indels were happening.
@javh @schristley @bcorrie Does the current Rearrangement specification allow to easily figure out what style of translation the junction_aa field is using, other than doing the translation of junction and checking if it matches junction_aa? Do you think this different choice is something to be tracked? I imagine, if someone wanted to combine datasets to compare amino acid properties of the CDR3, this could be relevant. I am not sure how many sequences would be falling in such scenario, probably the impact is small. We found this to happen in 3 out of ~100.

@ssnn-airr The V-J frame is  also reported as in-frame by igblast.  It's just that there is a frame shift that makes this sequence non-productive.  If there is a specific need to just focus on CDR3 and ignore its actual translation in the context of the whole sequence , then we could add an option for that.   By the way, it does not matter if there are indels in the V-J junction, as long as the junctional sequence length between the V and J reading frames is a whole number divisible by 3, it's in-frame, otherwise, out-of-frame.

Attached my notes, in case anyone interested in visualize what we are talking about. Not the best photo quality, sorry.

@jianye00 Thanks for the comments. Let's see if others jump in and share their opinion. I think that to define being in frame, and determine the translation frame, one has to consider also the conserved aminoacids that are a prerequisite of having an Ig, and in this case in particular the ones that mark the boundaries of the junction. So the translation of the VDJ sequence should produce them. But it seems to me, the translation in the context of the whole sequence, with the frame shift, could end in not getting these conserved aminoacids? In the example above, IMGT is considering the junction CARRCYYGSEMGTWFDPW (notice C and W conserved aminoacids), but IgBLAST considers VPGGVTMVRRWGPGSTPG (V and G, no conserved aa).

@ssnn-airr I'd say depending on what you are doing.  For general purpose where people put a nucleotide Ig sequence and ask what amino acids they will get, then you definitely have to consider frame since this is what you'll actually get (the conserved codon are there but you'll not actually get it due to frame shift).  However, if people are only studying some theoretical amino acid property of CDR3, then I can see you might not need to consider the frame.  As I said, earlier, if there is such a need, we could add an option to ignore frame.

@ssnn-airr Just to mention that instead of agonizing over what to do with the CDR3 for non-productive sequences, if your purpose is to analyze the functional repertoire, many studies simply exclude the non-productive sequences.

No, there isn't a specific mechanism in Rearrangement to define the assumptions underlying translation strategy (or alignment). I'm not certain we could define one in a way that is exhaustive of how all tools choose to approach these problems without being too complex/burdensome.  I think this is probably best covered by specifying the reference alignment tool and version in the metadata.
I'd say that defining the translation frame based on the junction is an error correction strategy.  Ie, if the junction is a multiple of 3 with the expected start/end motifs, you then assume an earlier indel is a sequencing/PCR artifact. I think that's usually true for indels early in the amplicon, especially if they are in the primer region. But, then it's not a faithful translation of the observed sequence...
Not sure if adding an option to ignore the frame is the right call or not. If you were to add an option, maybe it would make more sense for the option to toggle between defining the translation frame of the full sequence based on the (b) germline start vs the (b) junction start. Then you'll, hypothetically, get more valid translation out of those cases where you have an indel in the primer region. But, I think that would only address that specific artifact.  If the sequences done on the 454, then you'll probably have indels throughout the observed sequence and need to do something a lot more complex to try to correct for that.

Igblast is designed as a general purpose tool and it does not consider any error correction (which involves another whole different set of logic and uses cases).  User needs to decide if their input sequence has error or not.  There are legit cases  where indels are not errors at all (for example, pseudogenes, mutations).   I think error corrections should be handled before a user puts the sequences into annotation tool.

Thanks, @jianye00. My takeway is that this is out of scope for igblast. I'm going to close this, but feel free to reopen if appropriate.

Thanks you all for discussion.  Don't hesitate to contact me if you have any issues.


Adding setting to show path in FileSystem dock

This adding a setting "Docks > File System > Show Path in Tooltip" (unchecked by default), because when using the search, it's not possible to differentiate two files with the same name.
Also, as the the dragged value to script is the complete path of the file, I think it's more convenient to already have the path displayed.

I think this would be fine as the default behaviour, without an editor setting. It's not like the tooltips are showing anything important as they are.

It's not like the tooltips are showing anything important as they are.

It was also my point of view (except when the file cannot be imported due to invalid format, etc.), but this path can also be very long and maybe over-charged for new users.
Maybe the tooltip can show more about the file (like filesize – usefull for scene with embed data like mesh, baked data, etc.) still with a settings option to display such a tooltip.
In my opinion, the main purpose of the tooltip is to get the complete path without opening the file (like to differentiate two files with same name / preview icon)

I don't think this should be a setting, it seems fine as default behaviour. If any user is bothered by the tooltip, we can reconsider once they complain.

Yes, you're both right. Adding a setting just for it is overkill.
Removed.

I agree the settibg was not needed. The PR looks good to me.

Thanks!


lodepng.c: make mem. mgmt. syms externally visible

Another compilation unit (lv_png.c) tries to be consistent and references
the memory management function lodepng_free. As this method is declared private (i.e. static)
to the defining unit (i.e. lodepng.c), the symbol is not linkable with other compilation units.
By making the symbols externally visible (i.e. non-static), they can be linked.

Thank you!


Bumps collector version to include new probe

Description
With the recent merge of the custom probe into collector, this PR simply bumps the collector version so that this is included in wider stackrox testing.
Checklist

[ ] Investigated and inspected CI test results
[ ] Unit test and regression tests added
[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.
Testing Performed
TODO(replace-me)
Use this space to explain how you tested your PR, or, if you didn't test it, why
you did not do so. Valid reasons include, for example, "CI is sufficient",
"No testable changes". Feel free to attach JSON snippets, curl commands,
screenshots.
In addition to reviewing your code, reviewers must also review your testing
instructions and make sure they are sufficient.

/retest


Add Buildkite to federation

Description
Hi! I'm Sam, I'm an engineer at Buildkite. We've been working on providing OIDC tokens within Buildkite pipelines, for CI/CD workloads. I'd like to be able to use Buildkite OIDC tokens to sign containers produced by my builds.
We have a command which can be run within a build to provision an OIDC token with a custom audience, asserting the current job and agent identity:
https://github.com/buildkite/agent/pull/1827
Combining this with cosign should theoretically allow OIDC signing. But a pipeline like this:
steps:
- command: |
    docker build -t sj26/test:$BUILDKITE_BUILD_NUMBER .
    COSIGN_EXPERIMENTAL=1 cosign sign --identity-token="$(buildkite-agent oidc request-token --audience sigstore)" sj26/test:$BUILDKITE_BUILD_NUMBER

currently produces this error:
COSIGN_EXPERIMENTAL=1 cosign sign --identity-token="$(...)" sj26/test:16
Generating ephemeral keys...
Retrieving signed certificate...

        Note that there may be personally identifiable information associated with this signed artifact.
        This may include the email address associated with the account with which you authenticate.
        This information will be used for signing this artifact and will be stored in public transparency logs and cannot be removed later.
Error: signing [sj26/test:161]: getting signer: getting key from Fulcio: retrieving cert: POST https://fulcio.sigstore.dev/api/v1/signingCert returned 401 Unauthorized: "{\"code\":16,\"message\":\"There was an error processing the credentials for this request\",\"details\":[]}"
main.go:62: error during command execution: signing [sj26/test:161]: getting signer: getting key from Fulcio: retrieving cert: POST https://fulcio.sigstore.dev/api/v1/signingCert returned 401 Unauthorized: "{\"code\":16,\"message\":\"There was an error processing the credentials for this request\",\"details\":[]}"

I believe that means we need to be added to the federation config here:
https://github.com/sigstore/fulcio/tree/main/federation
I'm currently opening a PR, but required an issue open first. So, here it is! 🙏

Copying over my response:
There’s a few options for onboarding. One is to conform to one of the existing types. Given you’re a CI platform, it’s likely the “GitHub” type is the closest. This would require just configuration change, but unless you support the same claims as GitHub Actions, we would need code changes.
We’ve been thinking about how to standardize claims from CI platforms in https://github.com/sigstore/fulcio/issues/754.
The other option is to implement a new type specific to your platform, but we will need to also add custom OIDs too. I’d prefer to not do this for each CI platform though.
I’m curious what your thoughts are on the attached issue.
We’d also want to run through the list of requirements for providers, https://github.com/sigstore/fulcio/issues/397. This is a WIP list, so some might not be applicable to CI.
Given you said that your OIDC support is a work in progress, this is likely not something we would be including in the production instance yet, until your feature is stable. If you’d like to test locally, I can give some pointers to code that would need to be updated.


Updated below things including UNSAFE_componentWillMount warning

flowconfig Updated for Travis CICD
UNSAFE_componentWillMount for React Upgrade
Added package-lock.json

@jamiebuilds Can you please verify this PR
I update the yarn.lock file since it was throwing error in travis builds
Changed travis.yml to build only for node 8 and 10
update .flowconfig path to ignore chalk

Can we please merge this?

Seems like the maintainer of this Repo lost all interest in it (He's busy fighting for the justice of the minority groups). I recommend forking it.

Hello, this is really needed here for many people. Is this still maintained ?

@kopax use loadable/components, or fork this library

is it the same API?

@masad-frost those libraries are different. They do not provide the sames features. Did anybody fork and release on npm the fix?

react-loadable Loadable.Capture report is not support ssr?
// App.tsx
import React from 'react';
import {Route, Redirect, withRouter, Switch} from 'react-router-dom';
import Loadable from 'react-loadable';
import Loading from 'app/components/Loading';

const LoadableTab=Loadable({
  loader: () => import(/* webpackChunkName: 'Tab' */ './A'),
// typescript is not auto insert webpack/modules
//   webpack: () => [require.resolveWeak('./A')],
//   modules: ['./A'],
  loading:Loading
});
const LoadableUser = Loadable({
  loader: () => import(/* webpackChunkName: 'User' */ './B'),
//   webpack: () => [require.resolveWeak('./B')],
//   modules: ['./B'],
  loading:Loading
});

class App extends React.Component{
	render(){
		return(
			<React.Fragment>
				<Switch>
					<Route path="/login"  component={LoadableTab}/>
					<Route path="/join"  component={LoadableUser}/>
					<Route path="/"  component={LoadableUser}/>
				</Switch>
				<LoadableUser />
			</React.Fragment>
			)
	}
};

export default App;

// index.js
import App from "App.tsx";
...
const rootString = renderToString(
        <Loadable.Capture
            report={moduleName => {
                console.log('============If App is tsx/ts, Not executed here============>>>>>>>', moduleName)
                return modules.push(moduleName)
            }}
        >
            <Provider store={store}>
                <StaticRouter location={ctx.req.url} context={context}>
                    <App/>
                </StaticRouter>
            </Provider>
        </Loadable.Capture>
    );

so this moduleName is Empty array

Now please let's have a release :)

@kopax flow issues are fixed in this pull request. You can refer the changed files

Would love for this to get merged, using fork from @kopax in the meantime

React Loadable implementation with React 17.0.1.  🎉
https://www.npmjs.com/package/react-loadable-hooks

React Loadable implementation with React 17.0.1. 🎉
https://www.npmjs.com/package/react-loadable-hooks

It looks like you "forked" this repo (since a lot of its pieces are from this one), but at the same time stripped the git history of it, making zero initial commit. Why not do proper forking, at the same time respecting the previous work done here?!

React Loadable implementation with React 17.0.1. 🎉
https://www.npmjs.com/package/react-loadable-hooks

And you are following clause of MIT license (as you removed the LICENSE file from your repo):

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

React Loadable implementation with React 17.0.1. 🎉
https://www.npmjs.com/package/react-loadable-hooks

It looks like you "forked" this repo (since a lot of its pieces are from this one), but at the same time stripped the git history of it, making zero initial commit. Why not do proper forking, at the same time respecting the previous work done here?!
And you are violating the following clause of MIT license (as you removed the LICENSE file from your repo):

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
@shehi Thanks for pointing.
Added license. And I already have a forked version and created this Pull Request. And the other has more changes and cant be merged to this, that's why I added that to a new repo

React Loadable implementation with React 17.0.1. 🎉
https://www.npmjs.com/package/react-loadable-hooks

It looks like you "forked" this repo (since a lot of its pieces are from this one), but at the same time stripped the git history of it, making zero initial commit. Why not do proper forking, at the same time respecting the previous work done here?!
And you are violating the following clause of MIT license (as you removed the LICENSE file from your repo):

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
@shehi Thanks for pointing.
Added license and history.

And I already have a forked version and created this Pull Request. And the other has more changes and cant be merged to this, that's why I added that to a new repo

Then please apply your changes to existing latest version of this package? I for sure won't be using a new package, when its author decided not to bother with proper PR and conflict management. As I said, making clean slate repo with no git history whatsoever is just blunt plagiarism in my book. This will be my last comment on this topic. Have a nice day!

Please can we get an update on this?

For anyone interested, here's my solution to get rid of the warning (React 16 + 17) and still get this working (client+SSR).
https://github.com/jamiebuilds/react-loadable/pull/213#issuecomment-778246548

flowconfig Updated for Travis CICD
UNSAFE_componentWillMount for React Upgrade
Added package-lock.json

This author doesn't seem to be updating this component, but you can look at similar components that implement SSR PROMISE asynchronous loading，github address ：https://github.com/qq281113270/react-lazy-router-dom

这是来自QQ邮箱的假期自动回复邮件。你好，我最近正在休假中，无法亲自回复你的邮件。我将在假期结束后，尽快给你回复。


for #434: remove inline scripts

Moves all inline <script> code into .js files, so that the swagger UI site can be served with a CSP that blocks inline scripts. This does not remove <style> and style="" usages. So a CSP that blocks inline styles still causes lots breakage in the UI, but at least it functions.
Leaving #434 open for a fix for the styles.

@marcgibbons - can I get a review on this? I'm running on my fork/branch of DRS but I'd like to get back to a merged & released version.


using enzyme and cherrio

i see you are using both enzyme and cherrio libs for testing and i wonder why.
isn't cherrio full render enough?
and if not why not using the render function from enzyme and remove cherrio dependency altogether

I was experimenting with Enzyme. I was hoping I could use it to test component events, which AFAIK, you can't do with Cheerio. However, that didn't work out too well. Still hopeful it will improve in the future.

Thanks.


'Encountered flag 1539 corresponding to type Closure'  error after reading a rdata file

Hi! I tried to read a rdata file from R-Studio using read_rda("/test.RData") which caused this error message:
ERROR: Encountered flag 1539 corresponding to type Closure
 in error at error.jl:21
 in readitem at /Users/icarus/.julia/v0.3/DataFrames/src/RDA.jl:401
 in readnamedobjects at /Users/icarus/.julia/v0.3/DataFrames/src/RDA.jl:322
 in read_rda at /Users/icarus/.julia/v0.3/DataFrames/src/RDA.jl:413
 in anonymous at /Users/icarus/.julia/v0.3/DataFrames/src/RDA.jl:418
 in gzopen at /Users/icarus/.julia/v0.3/GZip/src/GZip.jl:266
 in read_rda at /Users/icarus/.julia/v0.3/DataFrames/src/RDA.jl:418

Is this a known error? I use Julia v0.3.10.

It's an intended behaviour: closures are among those things that are not supported by read_rda(). For every other non-supported SEXP type you should get the same error.
It's not likely that R closures would have any use in Julia session, but the problem is that you cannot just skip them: there's no simple way to know how many bytes one should skip, also it  could contain elements that are referenced later in the stream  -- and if that's ignored, the whole indexing of references would be broken.
So reading an arbitrary RData file requires proper parsing of every SEXP type. Making it stable is a considerable effort. Meanwhile, the solution would be either to read RData files that contain only supported elements or use the packages for calling R from Julia session, e.g. RCall.
I've done some work to support the other SEXP types. There's RData package, but it's very experimental and would probably work only in Julia 0.4.


Mark ListItem as deprecated in documentation

I just spent a significant amount of time trying to figure out why new ListItem(... didn't work in my code; I was convinced it existed because some out-of-date documentation (top results from Google Search 😆) still points to it (https://www.dartdocs.org/documentation/flutter/0.0.8/material/ListItem-class.html - I didn't realize it was version 0.0.8), and Material Design references both List Item and List Tile (https://material.io/guidelines/components/lists.html#lists-specs).
Finally after searching for ListItem in the Github Issues I came across https://github.com/flutter/flutter/pull/8769 and it all makes sense now 🤦♀  and realized I should be using ListTile!
Just wanted to illustrate the confusion/pain point - not sure how to alleviate it for future users. Maybe we could have a page in the docs that marks ListItem as deprecated, and redirects ListItem to ListTile?

Yikes, that's loooooong obsolete. I'll see what we can do to take it down.

The first Google search result for Flutter ListItem now just points to flutter.io. Not super helpful but harmless.
I'm going to close this bug


package.json dependency

can below dependencies not from github but npm? I am in a environment where cannot access github
"dependencies": {
    "jquery": "git+https://github.com/jquery/jquery.git#2.0.3"
  }

+1


Upgrade base image to use alpine 3.15

What does this pull request do?
Upgrade base image to use alpine linux 3.15
What is the intent behind these changes?
Alpine 3.13 ends support on 2022-11-01, 3.15 ends support on 2023-11-01

Thanks!


Problems in deploy compiled WASM and model parameters using simple-chat example

Hi,
first thanks a lot for providing so many useful code and tools. They are very helpful and inspiring. The WebGPU usage is like a miracle in WASM LLM deployment.
I encontered issues while deploying the compiled "WASM" file and the model "bins"
I compiled the wasm and bins by using
python3 -m mlc_llm.build --model mistral-7b --target webgpu  --quantization q4f32_1 --use-safetensors
Then I uploaded the bins to  https://huggingface.co/zxrzxr/mistral-7b-q4f32_1 and uploaded the wasm to github.
For deployment, I use parcel's https and simple-chat example to host website here: link
But when loading the model, I had
Init error, Error: Cannot find global function vm.builtin.ndarray_cache.get
in the zephyr wasm and
Init error, TypeError: Failed to execute 'add' on 'Cache': Request failed
It will be great if you can give me some trouble shooting hints.
Cheers and thank you.

Hi, when compiling the model with mlc_llm.build, are you using https://github.com/mlc-ai/relax?

Hi, when compiling the model with mlc_llm.build, are you using https://github.com/mlc-ai/relax?

Hi, thanks a lot for the quick reply.
I followed this guide to install the TVM
python3 -m pip install --pre -U -f https://mlc.ai/wheels mlc-ai-nightly-cu121
And I can see the imported tvm by python -c "import tvm; print(tvm.file)"
The compile does not throw any error but I don't know to check the usage of relax or TVM?
(is relax also called TVM or are them two different things?)

I followed this guide to install the TVM
python3 -m pip install --pre -U -f https://mlc.ai/wheels mlc-ai-nightly-cu121

Yes, the pip may have some latency in reflecting the latest change in relax.

work: https://raw.githubusercontent.com/mlc-ai/binary-mlc-llm-libs/main/Mistral-7B-Instruct-v0.1-q4f32_1-sw4096_cs1024-webgpu.wasm
doesn't work: https://raw.githubusercontent.com/mlc-ai/binary-mlc-llm-libs/main/Mistral-7B-Instruct-v0.1-q4f32_1-sw4k_cs1k-webgpu.wasm

Hmm that is interesting; the demo on the website https://webllm.mlc.ai/ uses the current code in examples/simple-chat, which uses the sw4k_cs1k one: https://github.com/mlc-ai/web-llm/blob/main/examples/simple-chat/src/gh-config.js#L120-L125. Are you using the latest web-llm repo?

Hmm that is interesting; the demo on the website https://webllm.mlc.ai/ uses the current code in examples/simple-chat, which > uses the sw4k_cs1k one: https://github.com/mlc-ai/web-llm/blob/main/examples/simple-chat/src/gh-config.js#L120-L125. Are > you using the latest web-llm repo?

@CharlieFRuan
I tried to use the latest web-llm repo to host my model compiled from the mlc-llm repo. The mlc-llm creates the params folder and a wasm. The compied wasm is not working, when connected with the params I compiled. nor the newest ´sw4k_cs1k´. Maybe this issue is better to be placed in the mlc-llm repo :D


Rewriting generator script

I've included the resulting differences to the packages that we generate from the generator that I've written.

The most important files to review are in the generator folder

@marstr Please exclude Azure Search from the generated data plane libraries. While our spec under arm-search is complete, the other specs are not. See this issue for details and current status: https://github.com/Azure/azure-rest-api-specs/issues/1085

Will we get rid of the Gododir?

Will we get ride of the Gododir?

Yep :)

@marstr you should take a look at how the specs repo is being refactored.  Depending on the timing it might make sense to hold off on this change then retool it for the refactor.
https://github.com/Azure/azure-rest-api-specs/tree/reorg

...you should take a look at how the specs repo is being refactored. Depending on the timing it might make sense to hold off on this change then retool it for the refactor.

True @jhendrixMSFT, I've tried to make this as agnostic to directory organization as possible so that when it does happen there are only a few lines that need to be changed. I'm also intentionally keeping this off the master branch for now.


Multivariate ts dataset

Thanks for your work.
The UCR natural dataset in your repository is a univariate dataset. Does DIF also support multi-variate time series dataset?

Yes, of course. DIF can handle multi-variate time series dataset.

@xuhongzuo Thank you for answer.
As an additional question, I checked the source code that the argument to perform CERE is new_ensemble_method. However, in main_ts.py, CERE is not used for time series.
Doesn't ts support CERE?
https://github.com/xuhongzuo/deep-iforest/blob/8eba6acee079069b545fb5a7cb0fe2a07a4403a4/main_ts.py#L39-L49

I am so sorry for the late reply.
We use a convolutional net for time series data. However, CERE is designed for matrix multiplication, so ts does not support CERE.

Thanks!