[Bug]: AttributeError: '_OpNamespace' '_C_cache_ops' object has no attribute 'reshape_and_cache_flash'

Your current environment
Collecting environment information...
PyTorch version: 2.3.0+cu121
Is debug build: False
CUDA used to build PyTorch: 12.1
ROCM used to build PyTorch: N/A

OS: Ubuntu 22.04.4 LTS (x86_64)
GCC version: (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Clang version: Could not collect
CMake version: version 3.28.3
Libc version: glibc-2.35

Python version: 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] (64-bit runtime)
Python platform: Linux-5.15.0-1055-nvidia-x86_64-with-glibc2.35
Is CUDA available: True
CUDA runtime version: 12.4.99
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration:
GPU 0: NVIDIA H100 80GB HBM3
GPU 1: NVIDIA H100 80GB HBM3

Nvidia driver version: 550.54.15
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.9.0.0
/usr/lib/x86_64-linux-gnu/libcudnn_adv.so.9.0.0
/usr/lib/x86_64-linux-gnu/libcudnn_cnn.so.9.0.0
/usr/lib/x86_64-linux-gnu/libcudnn_engines_precompiled.so.9.0.0
/usr/lib/x86_64-linux-gnu/libcudnn_engines_runtime_compiled.so.9.0.0
/usr/lib/x86_64-linux-gnu/libcudnn_graph.so.9.0.0
/usr/lib/x86_64-linux-gnu/libcudnn_heuristic.so.9.0.0
/usr/lib/x86_64-linux-gnu/libcudnn_ops.so.9.0.0
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Architecture:                       x86_64
CPU op-mode(s):                     32-bit, 64-bit
Address sizes:                      52 bits physical, 57 bits virtual
Byte Order:                         Little Endian
CPU(s):                             224
On-line CPU(s) list:                0-223
Vendor ID:                          GenuineIntel
Model name:                         Intel(R) Xeon(R) Platinum 8480CL
CPU family:                         6
Model:                              143
Thread(s) per core:                 2
Core(s) per socket:                 56
Socket(s):                          2
Stepping:                           7
CPU max MHz:                        3800.0000
CPU min MHz:                        800.0000
BogoMIPS:                           4000.00
Flags:                              fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cat_l2 cdp_l3 invpcid_single intel_ppin cdp_l2 ssbd mba ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb intel_pt avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local split_lock_detect avx_vnni avx512_bf16 wbnoinvd dtherm ida arat pln pts hwp hwp_act_window hwp_epp hwp_pkg_req avx512vbmi umip pku ospke waitpkg avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg tme avx512_vpopcntdq la57 rdpid bus_lock_detect cldemote movdiri movdir64b enqcmd fsrm md_clear serialize tsxldtrk pconfig arch_lbr amx_bf16 avx512_fp16 amx_tile amx_int8 flush_l1d arch_capabilities
L1d cache:                          5.3 MiB (112 instances)
L1i cache:                          3.5 MiB (112 instances)
L2 cache:                           224 MiB (112 instances)
L3 cache:                           210 MiB (2 instances)
NUMA node(s):                       2
NUMA node0 CPU(s):                  0-55,112-167
NUMA node1 CPU(s):                  56-111,168-223
Vulnerability Gather data sampling: Not affected
Vulnerability Itlb multihit:        Not affected
Vulnerability L1tf:                 Not affected
Vulnerability Mds:                  Not affected
Vulnerability Meltdown:             Not affected
Vulnerability Mmio stale data:      Not affected
Vulnerability Retbleed:             Not affected
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass:    Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1:           Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:           Vulnerable; IBPB: disabled; STIBP: disabled; PBRSB-eIBRS: Vulnerable; BHI: Vulnerable (Syscall hardening enabled)
Vulnerability Srbds:                Not affected
Vulnerability Tsx async abort:      Not affected

Versions of relevant libraries:
[pip3] numpy==1.24.4
[pip3] nvidia-nccl-cu12==2.20.5
[pip3] onnx==1.15.0rc2
[pip3] optree==0.10.0
[pip3] pytorch-quantization==2.1.2
[pip3] pytorch-triton==2.2.0+e28a256d7
[pip3] torch==2.3.0
[pip3] torch-tensorrt==2.3.0a0
[pip3] torchdata==0.7.1a0
[pip3] torchtext==0.17.0a0
[pip3] torchvision==0.18.0a0
[pip3] transformers==4.41.2
[pip3] triton==2.3.0
[conda] Could not collect
ROCM Version: Could not collect
Neuron SDK Version: N/A
vLLM Version: 0.5.0
vLLM Build Flags:
CUDA Archs: 5.2 6.0 6.1 7.0 7.2 7.5 8.0 8.6 8.7 9.0+PTX; ROCm: Disabled; Neuron: Disabled
GPU Topology:
GPU0    GPU1    NIC0    NIC1    NIC2    NIC3    NIC4    NIC5    NIC6    NIC7    NIC8    NIC9    NIC10   NIC11   CPU Affinity    NUMA Affinity   GPU NUMA ID
GPU0     X      NV18    SYS     SYS     SYS     SYS     SYS     PXB     SYS     SYS     SYS     SYS     SYS     SYS     0-55,112-167    0               N/A
GPU1    NV18     X      SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS     PXB     SYS     SYS     56-111,168-223  1               N/A
NIC0    SYS     SYS      X      SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS
NIC1    SYS     SYS     SYS      X      PIX     SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS
NIC2    SYS     SYS     SYS     PIX      X      SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS
NIC3    SYS     SYS     SYS     SYS     SYS      X      SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS
NIC4    SYS     SYS     SYS     SYS     SYS     SYS      X      SYS     SYS     SYS     SYS     SYS     SYS     SYS
NIC5    PXB     SYS     SYS     SYS     SYS     SYS     SYS      X      SYS     SYS     SYS     SYS     SYS     SYS
NIC6    SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS      X      SYS     SYS     SYS     SYS     SYS
NIC7    SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS      X      PIX     SYS     SYS     SYS
NIC8    SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS     PIX      X      SYS     SYS     SYS
NIC9    SYS     PXB     SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS      X      SYS     SYS
NIC10   SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS      X      SYS
NIC11   SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS     SYS     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
  NIC1: mlx5_1
  NIC2: mlx5_2
  NIC3: mlx5_3
  NIC4: mlx5_4
  NIC5: mlx5_5
  NIC6: mlx5_6
  NIC7: mlx5_7
  NIC8: mlx5_8
  NIC9: mlx5_9
  NIC10: mlx5_10
  NIC11: mlx5_11

🐛 Describe the bug
The script to reproduce the error:
from vllm import LLM, SamplingParams

prompts = [
    "Hello, my name is",
    "The president of the United States is",
    "The capital of France is",
    "The future of AI is",
]
sampling_params = SamplingParams(temperature=0.8, top_p=0.95)

llm = LLM(model="facebook/opt-125m")

outputs = llm.generate(prompts, sampling_params)

# Print the outputs.
for output in outputs:
    prompt = output.prompt
    generated_text = output.outputs[0].text
    print(f"Prompt: {prompt!r}, Generated text: {generated_text!r}")

The error message:
INFO 06-12 10:04:58 llm_engine.py:161] Initializing an LLM engine (v0.5.0) with config: model='facebook/opt-125m', speculative_config=None, tokenizer='facebook/opt-125m', skip_tokenizer_init=False, tokenizer_mode=auto, revision=None, rope_scaling=None, rope_theta=None, tokenizer_revision=None, trust_remote_code=False, dtype=torch.float16, max_seq_len=2048, download_dir=None, load_format=LoadFormat.AUTO, tensor_parallel_size=1, disable_custom_all_reduce=False, quantization=None, enforce_eager=False, kv_cache_dtype=auto, quantization_param_path=None, device_config=cuda, decoding_config=DecodingConfig(guided_decoding_backend='outlines'), seed=0, served_model_name=facebook/opt-125m)
INFO 06-12 10:05:01 weight_utils.py:218] Using model weights format ['*.bin']
INFO 06-12 10:05:01 model_runner.py:159] Loading model weights took 0.2389 GB
INFO 06-12 10:05:02 gpu_executor.py:83] # GPU blocks: 127597, # CPU blocks: 7281
INFO 06-12 10:05:04 model_runner.py:878] Capturing the model for CUDA graphs. This may lead to unexpected consequences if the model is not static. To run the model in eager mode, set 'enforce_eager=True' or use '--enforce-eager' in the CLI.
INFO 06-12 10:05:04 model_runner.py:882] CUDA graphs can take additional 1~3 GiB memory per GPU. If you are running out of memory, consider decreasing `gpu_memory_utilization` or enforcing eager mode. You can also reduce the `max_num_seqs` as needed to decrease memory usage.
[rank0]: Traceback (most recent call last):
[rank0]:   File "/workspace/vllm/tmp.py", line 11, in <module>
[rank0]:     llm = LLM(model="facebook/opt-125m")
[rank0]:   File "/workspace/vllm/vllm/entrypoints/llm.py", line 144, in __init__
[rank0]:     self.llm_engine = LLMEngine.from_engine_args(
[rank0]:   File "/workspace/vllm/vllm/engine/llm_engine.py", line 360, in from_engine_args
[rank0]:     engine = cls(
[rank0]:   File "/workspace/vllm/vllm/engine/llm_engine.py", line 236, in __init__
[rank0]:     self._initialize_kv_caches()
[rank0]:   File "/workspace/vllm/vllm/engine/llm_engine.py", line 326, in _initialize_kv_caches
[rank0]:     self.model_executor.initialize_cache(num_gpu_blocks, num_cpu_blocks)
[rank0]:   File "/workspace/vllm/vllm/executor/gpu_executor.py", line 86, in initialize_cache
[rank0]:     self.driver_worker.initialize_cache(num_gpu_blocks, num_cpu_blocks)
[rank0]:   File "/workspace/vllm/vllm/worker/worker.py", line 195, in initialize_cache
[rank0]:     self._warm_up_model()
[rank0]:   File "/workspace/vllm/vllm/worker/worker.py", line 205, in _warm_up_model
[rank0]:     self.model_runner.capture_model(self.gpu_cache)
[rank0]:   File "/home/enweiz/.local/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 115, in decorate_context
[rank0]:     return func(*args, **kwargs)
[rank0]:   File "/workspace/vllm/vllm/worker/model_runner.py", line 938, in capture_model
[rank0]:     hidden_states = graph_runner.capture(
[rank0]:   File "/workspace/vllm/vllm/worker/model_runner.py", line 992, in capture
[rank0]:     self.model(
[rank0]:   File "/home/enweiz/.local/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1532, in _wrapped_call_impl
[rank0]:     return self._call_impl(*args, **kwargs)
[rank0]:   File "/home/enweiz/.local/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1541, in _call_impl
[rank0]:     return forward_call(*args, **kwargs)
[rank0]:   File "/workspace/vllm/vllm/model_executor/models/opt.py", line 308, in forward
[rank0]:     hidden_states = self.model(input_ids, positions, kv_caches,
[rank0]:   File "/home/enweiz/.local/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1532, in _wrapped_call_impl
[rank0]:     return self._call_impl(*args, **kwargs)
[rank0]:   File "/home/enweiz/.local/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1541, in _call_impl
[rank0]:     return forward_call(*args, **kwargs)
[rank0]:   File "/workspace/vllm/vllm/model_executor/models/opt.py", line 282, in forward
[rank0]:     return self.decoder(input_ids, positions, kv_caches, attn_metadata)
[rank0]:   File "/home/enweiz/.local/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1532, in _wrapped_call_impl
[rank0]:     return self._call_impl(*args, **kwargs)
[rank0]:   File "/home/enweiz/.local/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1541, in _call_impl
[rank0]:     return forward_call(*args, **kwargs)
[rank0]:   File "/workspace/vllm/vllm/model_executor/models/opt.py", line 255, in forward
[rank0]:     hidden_states = layer(hidden_states, kv_caches[i], attn_metadata)
[rank0]:   File "/home/enweiz/.local/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1532, in _wrapped_call_impl
[rank0]:     return self._call_impl(*args, **kwargs)
[rank0]:   File "/home/enweiz/.local/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1541, in _call_impl
[rank0]:     return forward_call(*args, **kwargs)
[rank0]:   File "/workspace/vllm/vllm/model_executor/models/opt.py", line 162, in forward
[rank0]:     hidden_states = self.self_attn(hidden_states=hidden_states,
[rank0]:   File "/home/enweiz/.local/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1532, in _wrapped_call_impl
[rank0]:     return self._call_impl(*args, **kwargs)
[rank0]:   File "/home/enweiz/.local/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1541, in _call_impl
[rank0]:     return forward_call(*args, **kwargs)
[rank0]:   File "/workspace/vllm/vllm/model_executor/models/opt.py", line 105, in forward
[rank0]:     attn_output = self.attn(q, k, v, kv_cache, attn_metadata)
[rank0]:   File "/home/enweiz/.local/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1532, in _wrapped_call_impl
[rank0]:     return self._call_impl(*args, **kwargs)
[rank0]:   File "/home/enweiz/.local/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1541, in _call_impl
[rank0]:     return forward_call(*args, **kwargs)
[rank0]:   File "/workspace/vllm/vllm/attention/layer.py", line 89, in forward
[rank0]:     return self.impl.forward(query, key, value, kv_cache, attn_metadata,
[rank0]:   File "/workspace/vllm/vllm/attention/backends/flash_attn.py", line 288, in forward
[rank0]:     ops.reshape_and_cache_flash(
[rank0]:   File "/workspace/vllm/vllm/_custom_ops.py", line 350, in reshape_and_cache_flash
[rank0]:     torch.ops._C_cache_ops.reshape_and_cache_flash(key, value, key_cache,
[rank0]:   File "/home/enweiz/.local/lib/python3.10/site-packages/torch/_ops.py", line 921, in __getattr__
[rank0]:     raise AttributeError(
[rank0]: AttributeError: '_OpNamespace' '_C_cache_ops' object has no attribute 'reshape_and_cache_flash'

I tried docker images: nvcr.io/nvidia/pytorch:24.03-py3 and pytorch/pytorch:2.3.0-cuda12.1-cudnn8-devel
vllm was installed in an editable mode: pip install -e .
The above workflow can work several weeks ago, but is failing on current main.

Try deleting the compiled libraries (or just clone a fresh repo) and reinstall vLLM from scratch.

I got same error:
k0]:   File "/usr/local/lib/python3.8/dist-packages/vllm/model_executor/models/qwen2.py", line 202, in forward
[rank0]:     hidden_states = self.input_layernorm(hidden_states)
[rank0]:   File "/usr/local/lib/python3.8/dist-packages/torch/nn/modules/module.py", line 1532, in _wrapped_call_impl
[rank0]:     return self._call_impl(*args, **kwargs)
[rank0]:   File "/usr/local/lib/python3.8/dist-packages/torch/nn/modules/module.py", line 1541, in _call_impl
[rank0]:     return forward_call(*args, **kwargs)
[rank0]:   File "/usr/local/lib/python3.8/dist-packages/vllm/model_executor/custom_op.py", line 13, in forward
[rank0]:     return self._forward_method(*args, **kwargs)
[rank0]:   File "/usr/local/lib/python3.8/dist-packages/vllm/model_executor/layers/layernorm.py", line 62, in forward_cuda
[rank0]:     ops.rms_norm(
[rank0]:   File "/usr/local/lib/python3.8/dist-packages/vllm/_custom_ops.py", line 132, in rms_norm
[rank0]:     torch.ops._C.rms_norm(out, input, weight, epsilon)
[rank0]:   File "/usr/local/lib/python3.8/dist-packages/torch/_ops.py", line 921, in __getattr__
[rank0]:     raise AttributeError(
[rank0]: AttributeError: '_OpNamespace' '_C' object has no attribute 'rms_norm'
root@xingzai:/data/llama_sft# python
Python 3.8.10 (default, Nov 22 2023, 10:22:35)
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
torch>>> torch.__version__
'2.3.0'

Might related with torch 2.3? I simply installed vllm from pip.

Please see #5456.

Hi, can u verfify why pip instal vllm not work?

Are you installing vLLM from source, or from PyPI?

As I typed, pip install, of course pypi

Try uninstalling vLLM and then reinstalling it. If that doesn't work, you may have to install vLLM onto a fresh Python environment.

please see https://github.com/vllm-project/vllm/pull/5462

Deleting the *.so files in the vllm folder and then reinstalling can resolve my problem. Thanks!
BTW, I'm surprised to see this issue closed so quickly without any confirmation from bug reporter :)

I deleted and rebuilt stil got some _C undefined symbols error.

Which CUDA version are you using? Make sure it's compatible with what vLLM requires, otherwise you'll have to build from source as described in the docs.

I get the same error, i installed via pip and cuda 11.8. Most speed optimization software does not work at all, or cant be installed such as this one.


Optimize Window Update

Overview
Just general updates to optimize window. Main outstanding change is adding scene analysis for Unity UI elements that have RaycastTarget enabled. Items like labels can generally be disabled which reduces the number of raycastable objects to check in Graphics raycast operations per pointer
Cleaned up content when project setting is correct
Cleaned up code to use scope layout styles
Cleaned up scene analysis for polygon count
Updated documentation

Changes

Fixes: # .

Verification

As a reviewer, it is possible to check out this change locally by using the following
commands (substituting {PR_ID} with the ID of this pull request):
git fetch origin pull/{PR_ID}/head:name_of_local_branch
git checkout name_of_local_branch

/azp run


There is a problem with the details of the UI

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
The minimization button in the upper right corner of the window inside the software is not centered, but the other icons are centered, which makes OCD very uncomfortable

Describe the solution you'd like
A clear and concise description of what you want to happen.
Please center these icons
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

It looks like our framework platform, Eclipse, is suffering from the exact same issue. I'm not sure how we can fix it from our side.

Please open an issue for the Eclipse platform here: https://github.com/eclipse-platform#reporting-issues
it can not be fixed on our side.


Fix issue 23422: Disable uniq backwards iteration if a predicate is passed.

See also the discussion at https://github.com/dlang/phobos/pull/5384
uniq with a predicate may yield entirely different values in backwards iteration than in forwards iteration, albeit values in the same predicate class as the forward ones. As it stands, due to D's lack of a head-mutable container (cough rebindable cough), this is unfixable without making uniq unusable for ranges over const or immutable values or requiring excessive use of save. However, certain built-in ranges such as joiner will use back without the user necessarily being aware or opting into it. This creates bizarre code, such as this example:
auto range = [1, 2].uniq!"true";
assert(range.map!"[a]".joiner.array == [1]); // nope, it's [2]!
assert(range.array.map!"[a]".joiner.array == [1]); // now it passes??

To sidestep this issue, barring necessary language improvements, it's probably best if uniq.back is just disabled if a predicate is passed.
ping @CyberShadow

ping?

Can this be done as a deprecation instead?

@atilaneves @schveiguy, do you have any thoughts about this? We've reached the conclusion that it is better to deprecate uniq(...).back rather than introduce overhead for a use case that's more commonly used by accident rather than directly.
I'm also wondering if the same change which removes/deprecates uniq(...).back should also introduce a true bidirectional version of uniq, maybe controlled by a bool template parameter.

Hm, yeah probably. It should do the right thing with -de. Standing by for more opinions before changing it.

I'm confused by what the actual bug is, since it can't be the literal code above/in the unit tests/issue description.
If the elements compare the same due to the predicate, and the predicate is lying, I don't see where the bug is.

Consider the set of elements A, B, C, D, E, F, and let us postulate a predicate P such that A, B, C are equivalent under P, and D, E, F are equivalent under P (but distinct from A, B, C).  Consider the range: r = [ A, B, C, D, E, F ]; Then r.uniq!P should yield [ A, D ].
The expected result of r.uniq!P.retro is [ D, A ]; however, the current implementation gives [ F, C ], which is equivalent to r.retro.uniq!P.
This is because .popBack is wrongly implemented: it's identical to .popFront except that it calls the incoming range's .popBack instead of .popFront. .popFront uses the first element it sees as the reference element, and skips all subsequent elements that are equivalent to it. The correct implementation of .popBack ought to eagerly consume equivalent elements until it finds a non-equivalent one, then return the last equivalent element seen. I.e., given [ A, B, C ], .popBack should eagerly consume C and B and return A.

Correct. However, that correct implementation is impossible in D, because range elements may be immutable and we need to advance the subrange past the point where range.front is in the equivalence class, which means we need to store range elements, which means we need to mutate a variable of any type T, which is impossible. See https://github.com/dlang/phobos/pull/5384 .

@atilaneves should we move on with this?

I'd still like to see other opinions on what to do with deprecating back, because it will cause joiner to throw a false deprecation warning.

Is it possible to implement it correctly except for immutable elements?

Yeah ... but then you have two completely different behaviors depending on spooky action at a distance.
Can do, sure... do we really want that?

I was thinking of disabling backwards iteration for immutable, but implementing it correctly otherwise.

Right, the point is that then uniq will produce different (though "equivalent") results if you change struct S to immutable struct S.

Right, the point is that then retro.uniq.joiner will produce different (though "equivalent") results if you change struct S to immutable struct S.

Ugh, right. Yeah, that's not good.
I started thinking here though: what if someone implements opEquals "wrong"? We'll have the same problem, no?

That's correct, yes.
The strongest argument I can find: the primary issue here is with actually not with uniq but with retro. The behavior of uniq is, I guess, valid given the (sparse) documentation of its behavior. However, given any range R that supports bidirectionality, barring severe typesystem monkeying such as non-symmetric opEquals, range.retro should yield the elements of range in backwards order. I think that's the main point where a difference arises between messing with opEquals and messing with the uniq predicate: opEquals can be expected to affect the behavior of every value of the type. uniq's predicate should only affect uniq's behavior.

The more I think about this, the more I go back to my original comment: the results aren't different if they compare the same. That is: "should yield the same elements" - it does, they just don't compare equal as seen by opEquals, because that's not what the user asked for.

And I still don't think that this is what the predicate expresses or should express.
The predicate modifies the operator, not the type.

I understand what you're saying - but I don't think I agree.

The annoying thing is that we can't have it both way - because uniq really is the optimal name for either interpretation.

A different name works, and has the added benefit of breaking no code at all.

Gonna close for now.


Resolve #5

factored out the common code in a new common project the prevent the dependencies between both processors.
Resolve broken images links in the documentation
Upgrade tensorflow from 1.1.0 to 1.3.0

Resolves spring-cloud-stream-app-starters/tensorflow#5
Resolves spring-cloud-stream-app-starters/tensorflow#6

Looks good - squashed and merged.


Users response time

I add functions that calculate a buyer's or seller's average response time.
Also, show the response when the users take a buy or sell order.
https://github.com/lnp2pBot/bot/issues/18

Gracias mi pana, merging it !!!


[Bug] v100上lmdeploy 跑awq微调模型出问题

Checklist

[ ] 1. I have searched related issues but cannot get the expected help.
[ ] 2. The bug has not been fixed in the latest version.
[ ] 3. Please note that if the bug-related issue you submitted lacks corresponding environment info and a minimal reproducible demo, it will be challenging for us to reproduce and resolve the issue, reducing the likelihood of receiving feedback.

Describe the bug

本地a6000测试一切正常，配置lmdeploy==0.6.0a0,torch==2.3.1,triton==2.3.1，在v100上跑报如上错。跑的模型是qwen2.5-32b-instruct-awq。
翻历史bug 报告，有个类似的版本，你们提供的帮助是将triton==2.1.0，然而我在v100上重新进行了测试，又报了如下错。
RuntimeError: CUDA error: no kernel image is available for execution on the device
CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect.
For debugging consider passing CUDA_LAUNCH_BLOCKING=1.
Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions.

与那位老哥的报错相似，但是从第一行看上去并不是显存不足的问题，我调小了cache_max_entry_count ，依然没用，救救，请问该如何解决。
Reproduction
1
Environment
1

Error traceback
1

代码如下
  self.TYPE = "lmdeploy"
  backend_config = PytorchEngineConfig(tp=1, adapters=dict(c1=self.LORA_PATH),
                                       cache_max_entry_count=0.2)

  self.LLM = pipeline(model_path=self.MODEL_PATH,backend_config=backend_config,log_level="INFO")

gen_config = GenerationConfig(top_p=0.95,
                              temperature=0.7,
                              max_new_tokens=16, skip_special_tokens=True)
torch.cuda.empty_cache()
responses = self.LLM(prompts, adapter_name='c1')

RuntimeError: CUDA error: no kernel image is available for execution on the device

Mismatched nvidia driver version and cuda kernel.
Please provide Environment and Error traceback as the issue template suggested.

RuntimeError: CUDA error: no kernel image is available for execution on the device

Mismatched nvidia driver version and cuda kernel.
Please provide Environment and Error traceback as the issue template suggested.

Thank you, I have solved this problem by resetting pytorch==2.1.0,torchvision==0.16.0,triton==2.1.0, I think it was because of the original conflict between torch and triton.


[test] Use https instead of ftp to download the matrix

Cleanup Trilinos test removing obsolete workarounds.

Codecov Report

Merging #2210 (00bac27) into master (889d6e0) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2210   +/-   ##
=======================================
  Coverage   85.54%   85.54%
=======================================
  Files          55       55
  Lines        9746     9746
=======================================
  Hits         8337     8337
  Misses       1409     1409

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 889d6e0...00bac27. Read the comment docs.


[Task] shenyu rule cache test case

Description
shenyu rule cache needs test cases including unit test and integration test
Task List

shenyu L1 cache test case
shenyu L2(trie cache) test case

Hello, I really want to participate in shenyu's contribution. Could you please let me complete the corresponding task? I will be happy to do it. 😃

yes, I'm glad you're contributing to this issue, I will assign this task for you!

LGTM, thanks for your contributions!


Interface 'HTMLElement' cannot simultaneously extend types

ERROR in node_modules/typescript/lib/lib.dom.d.ts(6183,11): error TS2320: Interface 'HTMLElement' cannot simultaneously extend types 'Element' and 'HTMLOrSVGElement'.
  Named property 'blur' of types 'Element' and 'HTMLOrSVGElement' are not identical.

TypeScript — 3.2.4

Oh, my fault. This happened because i made my own Element interface with blur property.


make Probation configurable

Finagle's LoadBalancerFactory.EnableProbation param controls whether endpoints are eagerly evicted from service discovery.  we should add a configuration option to the router client config.
I also think we should enable this by default (i.e. in Router.scala).  It's a much safer default behavior that Twitter has not been able to change for legacy reasons.

Question - why enable it in Router.scala instead of putting a default value in LoadBalancerConfig.scala?

There's no difference to the end user -- but really this is something that should be a default in finagle.  If someone were to use the Router type directly as a library -- which is a reasonable expectation -- they should get this default behavior.


ImportError: cannot import name 'transport' from 'ott.tools'

Got this error, trying to run finetuning. I suppose, I should use older version of ott, which contains transport module. Is this correct? What version is recommended?
P.S. thank you for sharing your project

0.3.1 worked fine


[BUG] Pydantic model fields don't display in documentation

Describe the bug
I just saw the issue #9, and it looks like Pydantic models are supported, however I couldn't manage adding a Pydantic model in documentation. I use pytkdocs through mkdocstrings so I didn't install pytkdocs myself, it is installed with mkdocstrings.
Am I doing something wrong?
To Reproduce
I referenced the model like this, (I also tried clearing the filters and enabled inherited_members to see if I can solve myself, but it didn't work anyway.) however only Pydantic's own methods shows up, nothing more.
relay/models.py
from pydantic import BaseModel

class TestModel(BaseModel):
    a : int
    """test"""

    b : str
    """test 2"""

    c : Optional[str] = None

reference2.md
::: relay.models.TestModel
    selection:
      inherited_members: true
      filters: []

Expected behavior
It should display attributes of a Pydantic model.
Screenshots

System (please complete the following information):

pytkdocs version: 0.12.0 (installed automatically with mkdocstrings==0.16.0)
Python version: 3.9.7 (x64)
OS: Windows 10

Additional context

pydantic version: 1.8.2

docs/requirements.txt
mkdocs==1.2.2
mkdocs-material==7.3.0
mkdocs-autorefs==0.3.0
mkdocstrings==0.16.0
mkdocs-static-i18n>=0.19

mkdocs.yml (partial - only mkdocstrings part)
plugins:
- mkdocstrings:
  default_handler: python
  handlers:
    python:
      selection:
        inherited_members: true
        filters:
          - "!^_[^_]"
      rendering:
        show_root_heading: true
        heading_level: 1
        show_root_toc_entry: true
        show_root_full_path: false
        show_source: false
        show_bases: false

I also have a custom CSS to hide keyword arguments:
 .doc.doc-heading > code.highlight.language-python > span:not(:first-child) {
     display: none !important;
 }

Edit: Looks like attributes only shows up as table when I add Attributes section to model's own docstring. But I expected to see all attributes without adding them to model's own docstring.

Hello @ysfchn, my apologies, I realize I never answered to your issue. Please note you can definitely ping me next time if you don't get an answer :sweat_smile:
Did you manage to find a workaround? I kinda stopped working on pytkdocs because I was busy bringing an improved version to life (Griffe).

No problem! I realized the right way to do was defining all attributes in root of class definition instead of adding docstring under every field. So I closed the issue as it is not relevant anymore. I still use mkdocstrings and currently works great so far! 👍

I see, thanks! I'm glad mkdocstrings is working for you :slightly_smiling_face:

Hi, I'm having a similar issue, but the default always says required, I'm assuming that's because there's no __init__ method for it. This happens for all of my pydantic models here: https://icebotyt.github.io/pynoonlight


Clean up DateTime converter samples

Addresses feedback from https://github.com/dotnet/samples/pull/1116 and https://github.com/dotnet/docs/pull/13526.

Is this ready to merge, @layomia and @ahsonkhan. Once it's merged, we can rebuild and do a final review of dotnet/docs#13526.

I've addressed feedback and run the samples locally to ensure correctness. Merging now so we can do final review of dotnet/docs#13526.


Added ReduceLRonPlateau method to reduce overfitting and increase the accuracy

Added ReduceLRonPlateau method to reduce overfitting and increase the accuracy and obtained accuracy of 100%  on mnist dataset #139  @souvikg544

Good one ! @dhruvkej9


Signature ID appears when invalidated (approved set to false) email address

Summary
Signature ID appears when invalidated (approved set to false) email address
Steps

Login admin portal
Search & open SUN project
Click on easycla
Add new Email address under approval list
Now delete email address form approval list

Actual behavior
Signature ID appears when invalidated (approved set to false) email address

Signature ID: cf6b7168-b51d-4bcf-8270-7b1d013e0ce4 invalidated (approved set to false) due to Email<EMAIL_ADDRESS>approval removal for the CLA Group Sun foundation cla group for the project sun for the company Infosys Limited by the user (vthakur) Singh@Thakur.

Screenshots

@thakurveerendras
What should be the correct event summary in this case ?

Submitted the PR
@mlehotskylf @thakurveerendras
https://github.com/communitybridge/easycla/pull/3947

Wrong Approval Criteria appears tooltips

Project link : https://lfx.dev.platform.linuxfoundation.org/foundation/a09P000000DsCE5IAN/cla

@thakurveerendras  This is a existing issue of tool-tip, I have just fixed it.

Additional PR: https://github.com/communitybridge/easycla/pull/3951

@umeshlumbhani247 ,  now no reason string appears at activity log after remove GitHub user from approval list

Still showing no reason in event for GitHub user (User not exist),

Try to delete GitHub user vthakur from approval list

QA in DEV done, waiting for PROD deployment.


send a video/image file in xmpp

Hi all,
Plz somebody help me i am working on xmpp base chat application i want to send a video as well as image like other application how can i do this ihave a code which is sending image only as a file. is this also work for video ? and what is max size of video.
2nd things is how can i receive this and image/video and show this.
Thanks in Adv
Keyideas

@lloydwatkin : The link is broken. Can you provide an updated link?

@sonnyp  ?

@lloydwatkin ?


Moved hooks into dedicated event classes.

Fixes #11.
Hopefully this time for real.

Please fix these two and we're ready to merge. :)

Everything is done. :)


Dependent Decoder

Create a Bayesian decoder that respects dependencies between neurons, rather than treating them as independent.
Two potential approaches to start with:

Use multidimensional firing rate vectors and fit a GMM on the multidimensional distribution to then estimate a probability distribution.
Use PCA on multidimensional firing rate vectors and fit a GMM on the multidimensional distribution to then estimate a probability distribution. Use the PCA transformation vector on the rest segment firing rates to convert to PCA space for testing probability of a taste.

Completing this issue with just approach 1 for now. If needed will re-open with PCA.


KML placemark inline IconStyle overwrites IconStyle from styleUrl

Styling placemarks in KML files can easily done using style IDs.
When inserting placemarks in the KML file, these IDs can be referenced usind the styleURL tag.
This works pretty fine! But for some icons (e.g. arrows) it can be necessary to also set a heading information! This can not be done in the predefined styles as this changes for each placemark.
Therefore it is required to have an inline Style tag that only containes the heading tag for this icon. Unfortunately it is not appending this information to the merged information from the style ID. It seems to overwrite the whole IconStyle information from the style IDs. At least it displays the default hotSpot icon from Google (yellow pin) using the heading information from the inline IconStyle.
To Reproduce
Steps to reproduce the behavior:

Extract demo.zip
to have a minimal example.
Load the contained KML into online Google Earth to see how it should look like.
Now use the same KML and display it as overlay using openlayers.

Expected behavior
The inline IconStyle options should only overwrite the options specified in the IconStyle of the referenced style ID instead of replacing the whole IconStyle.

I'm also affected by this bug. Any chance for a fix soon?

If anyone is able to provide a pull request, we'd be glad to accept the fix.

Wow. Instead of fixing a bug it will automatically close when nobody does anything. That's also a way to get rid of work to be done.

If you want this issue to be fixed, you should to get in touch with a company that provides support for OpenLayers. Some of them are listed on https://www.osgeo.org/service-providers/.
As far that I know, all of the core developers are maintaining the library on their free time.

If you want this issue to be fixed, you should to get in touch with a company that provides support for OpenLayers. Some of them are listed on https://www.osgeo.org/service-providers/.
As far that I know, all of the core developers are maintaining the library on their free time.

I hope you don't use any of the many software products I develop or package in my free time.


[compatibility] update of libusb

Oh, jolly good! I planned to take action on this topic as well. :-)
What is the reason for raising to the latest release available?
Are there any troubles with earlier versions? (I'm thinking about compatibility here).
Should we raise version requirements for unix-based systems as well?
Let me check the current libusb package versions for the most common distributions.
Whatever, we also need to update the documentation together with this change.
As far as I can see this affects /doc/compiling.md.

This is not obligatory changes. They apply only in a rare case when building for windows and libusb not found. For example in CI.
I think at this point of time no need to increase the requirement for libusb versions.

Ok, let me check currently supplied libusb versions from the repos.
I think that we should set the version requirement in such a way that the oldest currently supported operating system versions of common linux/unix distributions are capable of running our stlink tools. This would also define the oldest libusb version to support (unless there is a bug that causes problems of course). I don't assume it to be a good idea to define different libusb versions for different OSs, as it likely raises confusion...

Here is the result from https://pkgs.org/search/?q=libusb (as of Mar 2020):
pine Edge - 1.0.23
Alpine 3.11 - 1.0.23
Alpine 3.10 - 1.0.22
Alpine 3.9 - 1.0.22
ALT Linux Sisyphus - 1.0.23
Arch Linux - 1.0.23
CentOS 8 - 1.0.22 libusbx --> not compatible
CentOS 7 - 1.0.21 libusbx --> not compatible
CentOS 6 - 1.0.9 --> will not be supported
Debian Sid - 1.0.23
Debian 10 (Buster) - 1.0.22
Debian 9 (Stretch) - 1.0.21
Debian 8 (Jessie) - 1.0.19 --> will not be supported
Fedora Rawhide - 1.0.22 libusbx --> not compatible
Fedora 31 - 1.0.22 libusbx --> not compatible
Fedora 30 - 1.0.22 libusbx --> not compatible
FreeBSD 13 - linux_libusb-13.0r358841 --> compatible (?)
FreeBSD 12 - linux_libusb-11.0r261448_4 --> compatible (?)
FreeBSD 11 - linux_libusb-11.0r261448_4 --> compatible (?)
KaOS - 1.0.23
Mageia Cauldron - 1.0.22
Mageia 7.1 - 1.0.22
NetBSD 9.0 - 1.0.22
NetBSD 8.1 - 1.0.22
NetBSD 7.2 - 1.0.22
OpenMandriva Cooker - 1.0.23
OpenMandriva Lx 4.1 - 1.0.23
OpenMandriva Lx 3.0 - 1.0.20
openSUSE Tumbleweed - 1.0.23
openSUSE Leap 15.2 - 1.0.21
openSUSE Leap 15.1 - 1.0.21
OpenWrt 19.07 - 1.0.22
OpenWrt 18.06 - 1.0.22
Slackware Current - 1.0.23
Slackware 14.2 - 1.0.20
Slackware 14.1 - 1.0.9 --> will not be supported
Solus - 1.0.23
Ubuntu 20.04 LTS - 1.0.23
Ubuntu 19.10 - 1.0.23
Ubuntu 18.04 LTS - 1.0.21
Ubuntu 16.04 LTS - 1.0.20
Ubuntu 14.04 LTS - 1.0.17 --> will not be supported
Looking at this may go to libusb 1.0.20 to ensure widespread compatibility.

@Vascom: You are on Fedora right? What do you think about this? Why does Fedora still use libusbx BTW? Is your library that outdated as well?

@Nightwalker-87 I don't know why it still not updated in rawhide. Need to ask maintainer.
But even if this update will be done it will be never updated for current releases of Fedora and RHEL/CentOS.

Looks like starting from this commit https://src.fedoraproject.org/rpms/libusbx/commits/master Fedora switched from libusbx to libusb but don't change the package name.

No.
libusb - for compatibility with 0.1 API.
libusbx - main libusb as I know.

@Vascom Yes. My point is they (Fedora) use sources from libusb-project for libusbx-package

upstream libusbx has merged back with libusb and is now called libusb again
but we already have a libusb package for the old libusb-compat-0.1, renaming
that to libusb-compat while at the same time giving this its name is a bit
tricky, lets stick with the libusbx name for now

Hi there, moved out the started discussion to #897 including all replies. Please continue there otherwise this PR is recycled for a basic discussion of this topic. Cleaning this up now.

For windows the workflow could look like this:

check if libusb is present:

[case 1]: yes --> which version? --> < 1.0.20 ? --> ignore present and install 1.0.23 (newest)
[case 2]: yes --> which version? --> >= 1.0.20 ? --> use present
[case 3]: no: install 1.0.23 (newest)

The version which serves as the condition should be 1.0.20 for now, with the option to raise it at a later time (but then synchronous with the requirement for linux-based systems as proposed in #897).

Feel free to extend this PR with related stuff, I'll leave it open for another while, but will submit own changes afterwards.

That's ok for me : limits.h include sys/limits.h.


Fix flexi_logger error working with local time

Error message:
[flexi_logger][ERRCODE::Time] flexi_logger has to work with UTC rather than with local time, caused by IndeterminateOffset
Documented in:
issue #99 of flexi_logger
rustsec

An easy fix is to simply move to another library. Logging libraries are
dime-a-dozen and I didn't pick flexi for any specific reason.
A segunda, 7 de mar de 2022, 22:26, Tomás Alagoa @.***>
escreveu:

Error message:
[flexi_logger][ERRCODE::Time] flexi_logger has to work with UTC rather
than with local time, caused by IndeterminateOffset
Documented in:
issue #99 of flexi_logger
https://github.com/emabee/flexi_logger/issues/99
rustsec https://rustsec.org/advisories/RUSTSEC-2020-0159
—
Reply to this email directly, view it on GitHub
https://github.com/jmg-duarte/nabu/issues/9, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADVCBSYHQB7M27FHQKMCQV3U6Z7BXANCNFSM5QET3EYQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Ah I see now, a simple change in configuration should suffice. Maybe check how to use UTC time in flexi_logger


[Minor Bug] TypeError when also using Combat Utility Belt

I was poking around inside the Foundry builtin console, and noticed a lot of errors that seemed related to this module (I started looking through the code before you replied to my feature request, so I recognized MultiMediaPopout). It doesn't seem to affect my ability to use this module but it might still be worth explicitly doing nothing in case entity is null, just for the sake of having clean console output.
Relevant portion of the console contents:
foundry.js:4503 Foundry VTT | Rendering SettingsConfig
foundry.js:5956 Foundry VTT | Retrieved and compiled template templates/sidebar/apps/settings-config.html
foundry.js:5956 Foundry VTT | Retrieved and compiled template templates/app-window.html
foundry.js:4503 Foundry VTT | Rendering Compendium
foundry.js:5956 Foundry VTT | Retrieved and compiled template templates/apps/compendium.html
foundry.js:4503 Foundry VTT | Rendering Dialog
foundry.js:5956 Foundry VTT | Retrieved and compiled template templates/hud/dialog.html
foundry.js:4503 Foundry VTT | Rendering MultiMediaPopout
foundry.js:5956 Foundry VTT | Retrieved and compiled template modules/scene-viewer/templates/media-popout.html
foundry.js:2498 Foundry VTT | Error thrown in hooked function
_call @ foundry.js:2498
call @ foundry.js:2481
_render @ foundry.js:4547
async function (async)
_render @ foundry.js:4509
_render @ foundry.js:5157
_render @ foundry.js:17711
async function (async)
_render @ foundry.js:17710
render @ foundry.js:4479
loadImage @ scene-viewer.js:73
(anonymous) @ scene-viewer.js:56
async function (async)
(anonymous) @ scene-viewer.js:54
dispatch @ jquery.min.js:2
v.handle @ jquery.min.js:2
foundry.js:2499 TypeError: Cannot read property 'entity' of null
    at Function._onRenderImagePopout (hide-npc-names.js:243)
    at signal.js:174
    at Function._call (foundry.js:2496)
    at Function.call (foundry.js:2481)
    at MultiMediaPopout._render (foundry.js:4547)
    at async MultiMediaPopout._render (foundry.js:5157)
_call @ foundry.js:2499
call @ foundry.js:2481
_render @ foundry.js:4547
async function (async)
_render @ foundry.js:4509
_render @ foundry.js:5157
_render @ foundry.js:17711
async function (async)
_render @ foundry.js:17710
render @ foundry.js:4479
loadImage @ scene-viewer.js:73
(anonymous) @ scene-viewer.js:56
async function (async)
(anonymous) @ scene-viewer.js:54
dispatch @ jquery.min.js:2
v.handle @ jquery.min.js:2

Using the module "Find the culprit!", I found that "Combat Utility Belt" was ultimately causing this issue in my case. I am using the most up-to-date versions of all modules / systems / stable Foundry (0.7.9).
Thanks again.

I believe that's a CUB issue, rather than something on my end (CUB is
checking for an actor associated with the window, and panicking when it
cant find any entity) - but I'll take a look and see if I can pass
something to make it not throw the error (might not be possible depending
on what it expects to find, since the entire point if this module is that
the scene is not loaded as an entity for everyone).
On Sat, 20 Mar 2021, 02:46 tom-f-oconnell, @.***> wrote:

I was poking around inside the Foundry builtin console, and noticed a lot
of errors that seemed related to this module (I started looking through the
code before you replied to my feature request, so I recognized
MultiMediaPopout). It doesn't seem to affect my ability to use this
module but it might still be worth explicitly doing nothing in case entity
is null, just for the sake of having clean console output.
Relevant portion of the console contents:
foundry.js:4503 Foundry VTT | Rendering SettingsConfig
foundry.js:5956 Foundry VTT | Retrieved and compiled template templates/sidebar/apps/settings-config.html
foundry.js:5956 Foundry VTT | Retrieved and compiled template templates/app-window.html
foundry.js:4503 Foundry VTT | Rendering Compendium
foundry.js:5956 Foundry VTT | Retrieved and compiled template templates/apps/compendium.html
foundry.js:4503 Foundry VTT | Rendering Dialog
foundry.js:5956 Foundry VTT | Retrieved and compiled template templates/hud/dialog.html
foundry.js:4503 Foundry VTT | Rendering MultiMediaPopout
foundry.js:5956 Foundry VTT | Retrieved and compiled template modules/scene-viewer/templates/media-popout.html
foundry.js:2498 Foundry VTT | Error thrown in hooked function
_call @ foundry.js:2498
call @ foundry.js:2481
_render @ foundry.js:4547
async function (async)
_render @ foundry.js:4509
_render @ foundry.js:5157
_render @ foundry.js:17711
async function (async)
_render @ foundry.js:17710
render @ foundry.js:4479
loadImage @ scene-viewer.js:73
(anonymous) @ scene-viewer.js:56
async function (async)
(anonymous) @ scene-viewer.js:54
dispatch @ jquery.min.js:2
v.handle @ jquery.min.js:2
foundry.js:2499 TypeError: Cannot read property 'entity' of null
at Function._onRenderImagePopout (hide-npc-names.js:243)
at signal.js:174
at Function._call (foundry.js:2496)
at Function.call (foundry.js:2481)
at MultiMediaPopout._render (foundry.js:4547)
at async MultiMediaPopout._render (foundry.js:5157)
_call @ foundry.js:2499
call @ foundry.js:2481
_render @ foundry.js:4547
async function (async)
_render @ foundry.js:4509
_render @ foundry.js:5157
_render @ foundry.js:17711
async function (async)
_render @ foundry.js:17710
render @ foundry.js:4479
loadImage @ scene-viewer.js:73
(anonymous) @ scene-viewer.js:56
async function (async)
(anonymous) @ scene-viewer.js:54
dispatch @ jquery.min.js:2
v.handle @ jquery.min.js:2
Using the module "Find the culprit!", I found that "Combat Utility Belt"
was ultimately causing this issue in my case. I am using the most
up-to-date versions of all modules / systems / stable Foundry (0.7.9).
Thanks again.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/BadIdeasBureau/scene-viewer/issues/5, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIVM42HUS4V3VESNPGVKDZTTEQD77ANCNFSM4ZP46T4Q
.

You could very well be right that it's just a CUB issue. I should also say that I encountered this once per attempt at loading a preview, though still I suppose it could just be on the CUB end. I didn't dig deep enough to really say.

Fixed on local version. Will push this out in a release tonight.


I can't get alpha blending to work.

I've been trying for many hours to get alpha blending to work.
So I made a new application to see if it was something wrong elsewhere in my project but I'm still getting the same issue.
My code is here: https://github.com/HumanGamer/game_engine_test
Both shapes have alpha of 0x55 and the state is set with:
bgfx::setState(BGFX_STATE_DEFAULT | BGFX_STATE_BLEND_ALPHA);

They appear as follows:

The colors should blend where they overlap but it's not working.
I tried many many different blend states and none of them cause the blending to work. I also looked at example-19-oit but couldn't get it to work. I tried doing the color.xyz *= color.w thing in the shader but that didn't work either.
I tested with OGL, Vulkan, and DX11 on Windows, and OGL and Vulkan on linux, they all have the same issue.
I'm not sure but this could be a bug in bgfx. Although example-19-oit appears correctly as far as I can tell.
What am I missing? I just can't figure out why it's not working.
PS: if you compile my project linked above, the shader won't compile. I copied it out of the original project I was testing this with. I did include the code though, but you'll have to compile it yourself if you need to edit it. Also working directory needs to be set to the root of the repo for the app to find the shaders.
Oh and also I should mention I'm new to graphics programming, however I asked some friends who know DirectX and OpenGL and they all looked at my code and said that as far as they can tell, it should be working.

Ok I managed to solve it in the latest commit.
For anyone who has the same problem and comes across this in the future here is the problem:
I was setting BGFX_STATE_WRITE_Z and that breaks transparency.
Also alpha blending looked a bit weird until I set the palette color and set it for the view clear.
To Devs: maybe this could be made clearer in docs or an example?


Rewrite to custom widgets

Doing this should have complete backwards compatibility with the previous configs.
Reference gitui.

Somehow I forgot this issue exists. Continued in #349.


Install and Configuration

Added Welcome message with some history to the app
Added Install and Configuration Step by Step

I’d recommend checking it through.
There is more that could be added to the configuration I’m sure but I have hit the extent of my configuration knowledge when it comes to the application. A least this will give people a head start.

Thanks for the update! I left the "Things you may want to cover" section there for future reference. README looks great now, thanks! Is there a feature you want to work on? if you have something in mind let me know. If you are a designer I could use some design help!  I'd like to set up Trello board so that we can keep track of what we are working on. Do yo have a Trello account?

Hi Ken, yes I have a Trello account. It would be great to know what is on the roadmap for the project. I have a few ideas too but I guess it might make sense to pin down the scope of the application first.
I have very limited RoR skills though would love to expand them. My strengths are in design, UX/UI, and some marketing. I enjoy getting into the css.

Great! I just tried adding you to my Trello board by your name but couldn't find you there. Do you mind telling me your email? Mine is<EMAIL_ADDRESS>You can send me a direct email if you want.
And I'd love to hear your ideas for the project. At some point in the future I think we want to go in our own direction in terms of design and functionalities (not copying everything from Medium).


Introducing "ENABLE_NEOLETTER_FORM_BUILDER" - false by default.

Diff best viewed without whitespace changes.
This should only be temporary until Neoletter is enabled by default for all new instances.

Given that the Example App already has features that don't work out of the box (Google Maps Widget) - does it really make sense to hide the full form builder? The only part that's not working without Neoletter is basically fetch(formEndpoint), and the according formEndpoint assignment makes no sense w/o Neoletter. If users of the trial would see what's possible with respect to building forms, wouldn't this be better for our reputation? As long as Neoletter is not available, developers will be willing to connect the submit action to their own form backend.

The user could be of the impression, that the form would work right away (which is at least what I would assume). The user would only be able to see the actual error if he/she submits the form at least once. I don't even know that error message is shown in such a case.
Anyway - the main goal of this PR is to get the code somehow in and not to have the best "in between" state. Hopefully this ENABLE_NEOLETTER_FORM_BUILDER will only live for a short time period.

REVIEW (6075d76)


Adds CloudCode handler for beforeFind

Allows cloud code to modify a query before it is run
Works with promises for a safer environment
Supports modifiying the current query
Supports issuing new queries
Supports rejecting queries

Current coverage is 92.16% (diff: 92.53%)

Merging #2715 into master will decrease coverage by 0.05%

@@             master      #2715   diff @@
==========================================
  Files           102        102
  Lines         12446      12514    +68
  Methods        1559       1566     +7
  Messages          0          0
  Branches       2039       2054    +15
==========================================
+ Hits          11478      11534    +56
- Misses          968        980    +12
  Partials          0          0

Powered by Codecov. Last update f6312a1...6d689ec

@flovilmart updated the pull request - view changes

@flovilmart updated the pull request - view changes

Can you add some docs for this feature as well?

I'll add it to the docs repo :)

@drew-gross : https://github.com/ParsePlatform/docs/pull/376

Looks good.

Current ACL implementation is very limited. For example there's no easy way to grant access dynamically using some logic. It's possible to work around this using cloud code, but it's not optimal. beforeFind hook is still very limited. Are there any plans on adding more powerful hooks?

What do you mean by more powerful hooks?

Sometimes there's need to grant additional access effectively disabling built-in ACLs checks. For example image team. There's a team owner who has access to the team. Now he invites team member who can for example have read-only access to team data (and potentially access can be revoked). Updating ACLs (adding member user) is not an option as there can be many-many thousands of objects. For now I have to write cloud function using useMasterKey: true internally. This is not optimal. I'd like to have a hook which allows granting access dynamically, in my example - team member can access team data without any additional ACLs. Same for update/delete operations. Team member may be allowed to update some fields only.

@virtualtoy you're talking about roles there.

@flovilmart so you suggest creating new roles for different groups of objects?

Updating ACLs (adding member user) is not an option as there can be many-many thousands of objects.

You should assign a role in the ACL for the objects, then add the users for that role. When you want to remove access to those objects for certain users, you can simply remove the user from the role.

@flovilmart thank you for suggestion, yes, I'm aware of roles, but that's not flexible enough for me


fix(config): drop extra '(' in first commit URL in github-keepachangelog

Description
Remove an extra open parenthesis from the PR URL for a new committer.
Motivation and Context
The extra open parenthesis breaks the URL so that it is not properly rendered.
How Has This Been Tested?
After modifying this in my copy of the example configuration, it generates valid URLs
for new contributors.
Types of Changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation (no code change)
[ ] Refactor (refactoring production code)
[x] Other [example configuration]

Checklist:

[x] My code follows the code style of this project.
[ ] I have updated the documentation accordingly.
[ ] I have formatted the code with rustfmt.
[ ] I checked the lints with clippy.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 41.14%. Comparing base (9722784) to head (4ecbf97).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #535   +/-   ##
=======================================
  Coverage   41.14%   41.14%
=======================================
  Files          15       15
  Lines        1038     1038
=======================================
  Hits          427      427
  Misses        611      611

Flag
Coverage Δ

unit-tests
41.14% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


problem with rnn comments regarding dynamic seq length?

I found this in the rnn comments:
  Dynamic calculation returns, at time t:
    (t >= max(sequence_length)
        ? (zeros(output_shape), zeros(state_shape))
        : cell(input, state)

Is this correct? It seems unreasonable to throw away the final state by overwriting it with 0s after it ran over the maximum sequence length. From reading the later code section for _dynamic_rnn_step there's this comment:
  if t >= max_sequence_length:
    return (zero_output, state)
  if t < min_sequence_length:
    return call_cell()

that seems to suggest that the final state is actually the last state before we ran over the maximum sequence length, and only the output is zero-ed out, which would make more sense.
I'm not sure which one is actually being done in the implementation, but these 2 views are not consistent.

see #1016


Include Extension.depends in manifests and sdists by default

Summary of changes
Closes #2565.
According to the documentation, Extension.depends is a "list of files that the extension depends on". The old distutils docs expand on this slightly with a concrete example:

The depends option is a list of files that the extension depends on (for example header files). The build command will call the compiler on the sources to rebuild extension if any on this files has been modified since the previous build.

Currently, this doesn't quite work out of the box, because the files listed in depends may not be included in the sdist. This is because build_ext.get_source_files only considers the Extension.sources attribute. I believe this to be a mistake.
Consider the docstring of get_source_files on the SubCommand protocol:

Return a list of all files that are used by the command to create the expected outputs. For example, if your build command transpiles Java files into Python, you should list here all the Java files. The primary purpose of this function is to help populating the sdist with all the files necessary to build the distribution. All files should be strings relative to the project root directory.

Clearly, Extension.depends are also "necessary to build the distribution" and so they should be included in the sdist.
This PR extends get_source_files to also include Extension.depends.
Pull Request Checklist

[x] Changes have tests
[x] News fragment added in newsfragments/.
(See documentation for details)

P.S. Apparently, the local tests (running tox) fail, unless the local setuptools repo has an origin remote that uses https. Either not having a remote named origin or using ssh (git@github.com:pypa/setuptools) for the remote causes some weird errors in pytest-perf. This should probably be fixed or at least documented in the Developer's Guide.

Oooh! A nice and round PR number. Lucky!

Thank you very much @RuRo. Nice way of using the build.SubCommand protocol.
This would be mostly related to header right?
I haven't tested, but I imagine that the other parts of setuptools already take care if the user tries to use depends=... on a file that is outside of the project directory, right?

P.S. Apparently, the local tests (running tox) fail, unless the local setuptools repo has an origin remote that uses https. Either not having a remote named origin or using ssh (git@github.com:pypa/setuptools) for the remote causes some weird errors in pytest-perf. This should probably be fixed or at least documented in the Developer's Guide.

Yeah, pytest-perf is a bit tricky to use when contributing. I always run tox -- -p no:perf in my local computer to side step that. Maybe we should disable it by default and only use it in the CI...

@abravalheri sorry for my delayed response. Regarding absolute paths or paths outside the project root, I am honestly not sure. It is not clear to me, what such a path should even signify (in either sources or depdends).
When building sdists such paths make absolutely no sense. There is no way to include these paths in the source distribution. I think, that all cases where absolute paths are needed are already covered by include_dirs, library_dirs, etc. Before this PR, adding absolute paths to sources produced an error, and all paths in depends were just ignored. With the changes proposed in this PR, depends will also start giving errors:
  error: Error: setup script specifies an absolute path:

      /path/to/some/dependency.h

  setup() arguments must *always* be /-separated paths relative to the
  setup.py directory, *never* absolute paths.

If you want, we can change it so that get_source_files only adds relative paths from Extension.depends instead of all paths.

When building wheels, such paths also don't make much sense, but I am pretty sure, that build_ext.build_extension and CCompiler.compile already have their own logic for handling sources and depends, and they don't use the build_ext.get_source_files function. So the behaviour for building wheels shouldn't be affected by this PR.

Before this PR, adding absolute paths to sources produced an error, and all paths in depends were just ignored. With the changes proposed in this PR, depends will also start giving errors:
   error: Error: setup script specifies an absolute path:

      /path/to/some/dependency.h

  setup() arguments must *always* be /-separated paths relative to the
  setup.py directory, *never* absolute paths.

Perfect, I think that as long as we have something avoiding the user from adding a file from outside the repo, that should be fine. (As you said, it does not make much sense to have those things in a wheel or sdist). Thank you very much for checking.
I was in doubt, because I have never used depends myself, so I was wondering if there could be chance something like /usr/include/math.h ends up in there. But I did a quick search and that does not seem to be the case (see https://grep.app/search?q=depends%3D&filter[path.pattern][0]=setup.py).
However, I did find a few examples that use files from outside the directory that contains setup.py:
https://github.com/python/mypy/blob/5617cdd03d12ff73622c8d4b496979e0377b1675/mypyc/lib-rt/setup.py#L39. Not sure how to do with that. Do you have any suggestion?

I was in doubt, because I have never used depends myself, so I was wondering if there could be chance something like /usr/include/math.h ends up in there.

As far as my understanding goes, stuff like /usr/include should be specified via include_dirs. The depends argument actually gets appended to the sources list, when passed to the CCompiler and unlike include_dirs, CCompiler seems to expect that all of its sources are "user owned". For example, it will rely on timestamps of these files to determine when to rebuild stuff and then attempt to write .o files next to the provided sources.

But I did a quick search and that does not seem to be the case (see https://grep.app/search?q=depends%3D&filter[path.pattern][0]=setup.py).

Actually, it seems that even absolute paths are sometimes used in depends. For example, here in scipy. Although in this case, it's a path inside the project root that was simply coerced to an absolute path via abspath for some reason.

However, I did find a few examples that use files from outside the directory that contains setup.py: https://github.com/python/mypy/blob/5617cdd03d12ff73622c8d4b496979e0377b1675/mypyc/lib-rt/setup.py#L39.

In this case, it doesn't seem like this package is intended to be distributed in a sdist on its own, so I think that this kind of light abuse is outside the scope of this PR.

Not sure how to do with that, ideally we should not introduce backwards incompatible behaviour. Do you have any suggestion?

I think, that the most safe behaviour would be:

during sdist creation (aka in get_source_files)

try to convert all paths to be relative to setup.py
include all the paths "inside" the project root in manifest and sdist
ignore all paths outside the project root (starting with ../)

during actual build

keep current behaviour or in other words:

keep all the paths exactly as specified by user in setup.py
it is the users' responsibility to ensure that any paths "outside" of the project root exist

This should at the very least not break any currently working builds (even if they do some dark magic/nonsense with depends).
P.S. Do you know, what is the canonical way to obtain the path to the project root (the directory with setup.py/setup.cfg/pyproject.toml)?

I added the slightly more relaxed logic for better backwards compatibility and warning messages as discussed. Although, I used log.warn instead of log.debug. Let me know, if you think, that I should change it to log.debug.

Thank you very much @RuRo, I added a commit that simplifies a little bit the checks and another one changing the changelog entry. I hope that is OK with you.
To be honest I prefer the log messages you have proposed because they give more clear indications to the user. However I am a bit worried that we can have a backlash of the community in the style "don't tell me what to do, I know what I am doing" (after all this is a feature used by power users). Another reason why I made it a oneliner is because projects that use external depends, are likely to have more than one (e.g. mypyc/lib-rt has 2, scipy can also have a couple), and oneliners are OK to repeat multiple times (imho).
Trying to choose the battles to fight and save up the setuptools churn budget for other moments... In this case I don't think we have to prompt the user to change, I just want the logs to have a clear indication of what is happening so people have the chance to debug. In the end of the day, what you said previously is important "building sdists such paths make absolutely no sense".
I plan to add a test that covers both "../xxxxx" paths and "/x/y/z" paths, just for the sake of completeness. But feel free to bit me to that if you have the time.

Regarding log messages, I am fine with whatever level of verbosity you deem appropriate.
Regarding extra tests, I'm unfortunately a bit busy with other stuff right now, so feel free to implement these tests yourself.

Hi @RuRo, thank you very much for the review comments, I will iterate over them once I have the time.

abs_path = (project_root / dep).resolve() # this handles both absolute and relative deps

Regarding the suggestion to use resolve, the reason why I intentionally went with abspath instead is because resolve is going to expand symlinks (right?). At this stage I don't have any personal problems if people want to symlink something like /opt/x/include/y.h to project_root/y.h. Maybe later in the setuptools pipeline there is a check for that, but I don't recall this being a validation requirement (I might be wrong).

Regarding the suggestion to use resolve, the reason why I intentionally went with abspath instead is because resolve is going to expand symlinks (right?).

Yes, and as the docs point out, attempting to do path traversal without resolving symlinks is actually invalid, since foo/symlink/.. should refer to "the parent of whatever symlink points to", not foo.

At this stage I don't have any personal problems if people want to symlink something like /opt/x/include/y.h to project_root/y.h. Maybe later in the setuptools pipeline there is a check for that, but I don't recall this being a validation requirement (I might be wrong).

Yeah, in this case, I see no reason not to include project_root/y.h in the sdist. This example is firmly in the "why would anybody do something like that" territory, but imho it's not worth introducing extra special cases for it (or at the very least outside the scope of this PR).

Yes, and as the docs point out, attempting to do path traversal without resolving symlinks is actually invalid, since foo/symlink/.. should refer to "the parent of whatever symlink points to", not foo.

That is a tricky one... In your original implementation you also used os.path.normpath and os.path.abspath that will resolve the paths using logical operations (instead of traversing the file system), right? So I suppose it is subject to the same shortcomings... (Please correct me if I am wrong).
Let me think about that... what would be the best approach here?
Probably the test case should be something like:
# rushed and probably wrong pseudo-code to express brain dump
mkdir -p /tmp/headers/dir1
touch /tmp/headers/dir1/f.h
ln -s /tmp/headers myheaders
ext_modules=Extension(..., depends=["myheaders/dir1/../dir1/f.h"])

This should be fine, because when producing the sdist we can copy /tmp/headers as myheaders inside the tar.gz. Then later (when creating the wheel from the sdist), myheaders/dir1/../dir1/f.h would translate to <sdist_root>/myheaders/dir/f.h, which would build happily.
Maybe I am overthinking this (and that is probably true). But I am trying to be mindful to not introduce backwards incompatibilities.

That is a tricky one... In your original implementation you also used os.path.normpath and os.path.abspath that will resolve the paths using logical operations (instead of traversing the file system), right? So I suppose it is subject to the same shortcomings... (Please correct me if I am wrong).
Let me think about that... what would be the best approach here?

Yes, my original implementation didn't resolve symlinks before path traversal, and I now believe that to be a mistake (although not a very significant one).

Probably the test case should be something like:
# rushed and probably wrong pseudo-code to express brain dump
mkdir -p /tmp/headers/dir1
touch /tmp/headers/dir1/f.h
ln -s /tmp/headers myheaders
ext_modules=Extension(..., depends=["myheaders/dir1/../dir1/f.h"])

This should be fine, because when producing the sdist we can copy /tmp/headers as myheaders inside the tar.gz. Then later (when creating the wheel from the sdist), myheaders/dir1/../dir1/f.h would translate to <sdist_root>/myheaders/dir/f.h, which would build happily.

With the current implementation, myheaders shouldn't be included in the sdist, because /tmp/headers/dir1/f.h is not inside the project root (and I think, that this is a perfectly sane behaviour for now).

Maybe I am overthinking this (and that is probably true). But I am trying to be mindful to not introduce backwards incompatibilities.

I think that we should keep symlink handling mostly outside the scope of this PR for now. The simple rule of "completely resolve the path specified in depends, if it ends up being inside the project root, include the resolved path in the sdist" should be mostly backwards compatible, and it would cover the most common/sane use case for depends (in-project header files).

Hi @RuRo thank you very much for the comments. Please find my take, inline below.

I think that we should keep symlink handling mostly outside the scope of this PR for now.

I understand the concerns and I agree that we can leave the scope of the PR as slim as possible, but as long as we don't introduce backwards incompatibility in this PR.
(Unfortunately, GitHub is not great for splitting multiple dependent PRs, so splitting compatibility concerns in other PRs is not a good option unfortunately).

With the current implementation, myheaders shouldn't be included in the sdist, because /tmp/headers/dir1/f.h is not inside the project root (and I think, that this is a perfectly sane behaviour for now).

People might have different opinions if it is correct or not, but this is the behaviour we observe nowadays:
> docker run --rm -it python:3.8-bullseye /bin/bash
mkdir -p /tmp/headers/dir1
touch /tmp/headers/dir1/f.h

rm -rf /tmp/headers /tmp/myproj
mkdir -p /tmp/headers/dir1
touch /tmp/headers/dir1/f.h

mkdir /tmp/myproj
cd /tmp/myproj
ln -s /tmp/headers myheaders

cat <<EOF > pyproject.toml
[build-system]
requires = ["setuptools", "Cython"]
build-backend = "setuptools.build_meta"
EOF

cat <<EOF > setup.py
from setuptools import Extension, setup

setup(
    name="myproj",
    version="42",
    ext_modules=[
        Extension("hello", sources=["hello.pyx"], depends=["myheaders/dir1/../dir1/f.h"])
    ],
)
EOF
echo 'print("hello")' > hello.pyx
cat <<EOF > MANIFEST.in
global-include *.h
EOF

python -m venv /tmp/venv
/tmp/venv/bin/python -m pip install build
# ...
# Successfully built myproj-42.tar.gz and myproj-42-cp38-cp38-linux_x86_64.whl
/tmp/venv/bin/python -m build
tar tf dist/*.tar.gz
# myproj-42/
# myproj-42/MANIFEST.in
# myproj-42/PKG-INFO
# myproj-42/hello.pyx
# myproj-42/myheaders/
# myproj-42/myheaders/dir1/
# myproj-42/myheaders/dir1/f.h
# myproj-42/myproj.egg-info/
# myproj-42/myproj.egg-info/PKG-INFO
# myproj-42/myproj.egg-info/SOURCES.txt
# myproj-42/myproj.egg-info/dependency_links.txt
# myproj-42/myproj.egg-info/top_level.txt
# myproj-42/pyproject.toml
# myproj-42/setup.cfg
# myproj-42/setup.py

So they are included without an error.
The implementation in the PR should result in a similar outcome.

The simple rule of "completely resolve the path specified in depends, if it ends up being inside the project root, include the resolved path in the sdist" should be mostly backwards compatible, and it would cover the most common/sane use case for depends (in-project header files).

I am very happy to do that, as long as when sdist runs it does not raise an error for a configuration that previously would be fine.
I think that before merging the PR, we should make sure to not introduce backwards incompatible behaviour. Maybe the approach proposed ("completely resolve the path ...") already covers that.

P.S. symlink handling seems to already be a known problem (https://github.com/pypa/setuptools/issues/415), so I'm leaning heavily towards "don't try to be too clever with symlinks" for now

My take on #415 is that it is asking for a change in behaviour in setuptools. The current behaviour seem to have been implemented via PR, so it is probably deliberate (someone thought it was better that way)[^1]. Changing it might be controversial between groups of users (by Hyrum's law that is very likely someone depends on the current behaviour).
So my approach would be to be compatible with the existing behaviour. Future changes can be implemented when #415 is handled (the how will also be important, a valid outcome of #415 is to have an "opt-out" configuration flag for following symlinks).
[^1]: Due to the migration to GitHub is a bit hard to keep track of PR numbers and links.

I understand the concerns and I agree that we can leave the scope of the PR as slim as possible. But only as long as we don't introduce backwards incompatibility in this PR. (Unfortunately, GitHub is not great for splitting multiple dependent PRs, so splitting compatibility concerns in other PRs is not a good option).

To be clear, I am not suggesting that we split backwards compatibility into a separate PR. I simply don't see, how the presence of symlinks affects backwards compatibility in this case. By just resolving all paths and not adding any special logic for symlinks, we are (AT WORST) not including some of these paths in the manifest by default (just like they aren't included now).

With the current implementation, myheaders shouldn't be included in the sdist, because /tmp/headers/dir1/f.h is not inside the project root (and I think, that this is a perfectly sane behaviour for now).

People might have different opinions if it is correct or not, but this is the behaviour we observe nowadays:

(snip)

cat <<EOF > MANIFEST.in
global-include *.h
EOF

(snip)

So they are included without an error. The implementation in the PR should result in a similar outcome.

The only reason, why myheaders is included in the sdist in your example is that you have manually added *.h to the manifest. This PR doesn't/shouldn't change the behaviour of how the manifest is interpreted, only how the "default" manifest paths are generated based on the contents of Extension.depends.

I am very happy to do that, as long as when sdist runs it does not raise an error for a configuration that previously would be fine.
I think that before merging the PR, we should make sure to not introduce backwards incompatible behaviour. Maybe the approach proposed ("completely resolve the path ...") already covers that.

Yes, I currently don't see any (reasonable) way for this approach to result in an error where none were raised previously. Do you have something specific in mind? Basically, this would have to be a configuration that produces valid sdists today, but that would be broken by adding some in-project file to the manifest.

This is what I did to double check everything:

I added the regression tests 29a00ee65 and tested against main unchanged (passing)
I cherry-picked the original contribution from aefe73b11 to 43abba211 and run the regression tests (passing)
I cherry-picked the changes I added to (817edb4c1 to 44d727fdb) and run the regression tests (passing)
I added the suggestions including Path.resolve (973f7f45b to 87d5e9c51) and run the regression tests (passing)

So far very good, they don't break any existing build, and I am happy with it.

For curiosity I decided to check what would be the outcome of automatically adding depends when using symlinks.
So I added 77a12951c (failing).

We don't necessarily have to support this use case (since it is contrived), but it is a shortcoming of the implementation using Path.resolve (considering that the current behaviour of setuptools is being OK with people using symlinks).

Then I added cf2bda6b1 to see what a solution would look like that adds the automatic inclusion of files even when people use symlinks.
Running the tests again, they pass.

Then I added more tests to check what happens if a given depends does not exist (no symlink here, just checking an edge case for completeness) in 379cbe325.

I think it is completely fine to stop at 4 (we can revert the other commits). I am happy with it because we have regression tests that prove no error occurs.
If we want to go the extra mile, some code is there (77a12951c to cf2bda6b1). We might want to review if it has other flaws. But that is not necessary.

Hi. Sorry to continue bikeshedding this PR, but I have just looked over all the implementation attempts so far (both yours and mine), and I am really not satisfied with any of them. This PR was supposed to be super small and simple (both to implement and to reason about), but I think that we've ended up overcomplicating it quite a bit.
I would like to "start over" by explicitly listing the scope, expectations and requirements for this PR. After we agree on that, we can make sure that we have test coverage for all expected cases. This way, we can make sure that our implementation is actually sane and that we haven't overengineered or overlooked anything.
Again, sorry to block this. I'll try writing up the "spec" later today.

No problems. Thank you very much @RuRo for having a look on this.

Okay, here goes.
I think, that the main thing that I don't like about the current approaches is that we've identified a bunch of cases, where "We currently don't understand, why would anyone do this" and "This doesn't make sense" and yet we are attempting to support these "weird" cases.
In my opinion, this approach is wrong because we have no way of evaluating if what we are doing makes sense. Even more importantly, by adding these files to the manifest and sdist, we are introducing new behaviour that people may start to rely on. If we later decide that we want a different behaviour for one of these "weird" cases, we would be forced to keep compatibility with current behaviour.

Currently, none of the files in Extension.depends are added to the manifest by default. I think, that in this PR we should add to the manifest only those paths from Extension.depends for which we are 100% sure that we understand that we are doing "the right thing™". For all other paths, we do a log.info informing the user, that this file will not be automatically included in the manifest (not a warning, because might be a "valid" condition that doesn't need "fixing" by the user).
In particular, I'd say that "we are 100% sure" that we should include files that satisfy all of these conditions:

the path is a relative path
the path doesn't have any .. path traversal components
the path physically resolves to some path that exists
the resolved path is still located inside the project root

Note, that these are requirements for automatic inclusion in the manifest, not for any other functionality that depends already offers. A path that doesn't satisfy one of the above conditions would be still allowed in Extension.depends and would behave exactly as it does today.
Here are some concrete examples and my justifications for each of these restrictions:

This is already a requirement for sources.
Note, that I am proposing to refuse all absolute paths. Previously, I wanted to allow the case where the absolute path happens to end up referring to a file inside the project. This was an attempt to accommodate cases along the lines of Extension(depends=[os.path.abspath(valid_relative_path)]), but now I think that this was a mistake. We have no way to tell if /home/user/the_project_dir/somefile.h is os.path.abspath("./somefile.h") or just a hardcoded absolute path, so "In the face of ambiguity, refuse the temptation to guess".

This requirement might seem to be overly restrictive, but while testing, I have found that the current manifest logic doesn't really handle paths with .. traversal well. For example, the following example that has a valid path with .. in its manifest actually fails during sdist creation:
mkdir foo
touch bar
touch pyproject.toml

cat <<EOF >MANIFEST.in
include foo/../bar
EOF

python -m build -s .

This means, that we can't just blindly pass unnormalized paths to the manifest system, as that might lead to backwards compatibility problems (the project used to build, but now fails). Fixing such problems in the manifest system is definitely outside the scope of this PR (and I personally currently don't have the time for it).
In addition to this, properly handling .. path traversal when symlinks are involved is surprisingly hard because symlinks are converted to regular folders during sdist creation. For example, imagine that some_symlink points to deep/subfolder/stucture. Then, the user then tries to include some_symlink/../../bar (this file actually exists with the canonical name deep/bar). In this case, there is no way to represent this path in a sdist without symlinks, because logically some_symlink/../.. tries to traverse outside the root of the package.

Adding non-existent paths to the manifest seems to cause them to be silently ignored, but I would still prefer to be conservative here and skip such paths just in case. Additionally, if the path doesn't exist, then we can't be 100% sure that we have resolved the path correctly and so without requirement 3, we can't check for requirement 4.

This requirement is probably the "weakest" in my opinion (meaning that you can probably convince me to relax it, if you can articulate why this should be allowed).
Regarding not including symlinks to absolute paths, the main motivation here is that we should avoid trying to include stuff that we are not sure about. For example, I can totally imagine a case where some_symlink is a helper symlink to something like /opt/cuda and then some dark magic is used to create that symlink at runtime (even during an isolated wheel build). This is basically like specifying an absolute path with extra steps. Why would anybody do such a thing and add it to Extension.depends is an open question, but at this point I think that automatically including these files in the manifest/sdist would most likely be wrong.

We can revisit any of these restrictions if/when we find an actual example "in the wild" where someone wants to include such a non-compliant path in depends (after they explain, what prevents them from making it compliant with the above restrictions).

@abravalheri thoughts?

@abravalheri I pushed an updated implementation with the described logic. I decided not to rewrite the history in case you still need it. Feel free to rebase/squash the commits as you see fit.
I removed the test_auto_include_symlinked_depends test, as it attempts to assert some things that are no longer true in the new implementation. I didn't touch the tests in TestRegressions as they are basically unrelated to the changes introduced in this PR.
I also added a couple of new tests that verify some of the edge cases, that I've outlined in the "spec".

Thank you very much @RuRo. This approach should be fine. Also very happy with the extensive tests.

Ugh. Apparently the stdlib version of distutils.log doesn't use the logging module, but instead just writes directly to stdout/stderr, so we can't easily capture/introspect the logs with caplog.

Thank you very much for the hard work and thoughtful conversations!


Great than matcher and tests

Before submitting this PR, please make sure:

[x] My code follows the style guidelines of this project
[x] Your code builds clean without any errors or warnings
[x] You are using approved terminology
[x] You have added unit tests

Type of change

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

adding great than matcher and tests

@tamar-ot Please remove the old tests from test/expect_to_test_suite.py, test/expect_to_not_test_suite.py and their related stubs.


do not throw on process exit with non-zero code

Related to confirmed bug in nearform/node-clinic#73.
When client process terminates with an exit code > 0 like process.exit(1), an error is thrown by bubbleprof. Clinic terminates, and trace event file is not moved to logging directory. Terminating the client process this way could be intentional and trace output is still useful.
BubbleProf should report the error to the console but not throw. And still move trace event file to the logging directory for visualisation by Clinic.

Fixed in #278.


Fix gas masks to work with air tanks like the medical ones.

About the PR
Gas masks now allow you to turn on internals just like the medical ones.
Why / Balance
Because it not working is a bug, plus it helps tone down the currently very oppressive boiler smokes, especially during hijack.
And if it is not a bug, somebody needs to change the fact that oxygen tanks come in the same crate as gas masks when bought in req.
Technical details
The med gas mask uses the base ss14 gas mask as a parent, which the standard gas mask does too now, allowing you to turn on your internals if you also have an air tank.
Media

[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog

:cl: BramvanZijp

fix: Standard gas masks now allow for the use of internals.

How does this affect Boiler gas? Boiler gas doesn't work through inhalation of surrounding chemicals, atmos simulation isn't run for most things

I stand corrected on that then, but they should still work like the other ones for a few reasons, including blocking consumption, etc.

can confirm that atmos devices arent ticked at all including internals, so if you have 304kpa anesthetic tank it never gets inhaled so stays at 1mpa forever

what do gas masks do against boiler gas in cm13

Nothing :p

lol

can confirm that atmos devices arent ticked at all including internals, so if you have 304kpa anesthetic tank it never gets inhaled so stays at 1mpa forever

We are going to need this for surgery, but maybe we should just bypass the usage of atmos systems and make a simple new one instead.. probably a lot easier and performant than working in atmos.

closing as stale


Define scripts as object

Instead of define the scripts as a list, allow to define it as an object with an hierarchy of commands, this makes it easier to maintain when there's a lot of scripts commands that need to be included.

In this case, I don't want to deviate from the package.json / scripts  model - it's just a list of commands.
To solve this problem, it is better to use special packages (in the case of a hierarchy of commands or a non-linear dependence of one command on another)

The thing is the same, define the scripts as an hierarchy, that later would be flattened by joining paths as prefixes with : as it's common, instead of having to define the prefix in all the entries. This can make it more easy to maintain since they would be grouped, we don't need to stick to the same format used in package.json in on our files.


Issue#16: Adds ability handle audience as string and array

issue#16: Adds ability handle audience as string and array

Had a chat with @etsuo and I did not define this ticket well enough.  The intention of this ticket will be handled in one of the scenarios listed in #13.  I am closing the PR and the Issue.


Want to add network translation function ["PowerToys Run" | "OCR"]

Description of the new feature / enhancement

Supports custom configuration apis
As an extension of the OCR and PowerToys Run features, "Paste Translated content" is displayed in the windows right-click menu, and the translated content is the OCR preferred language by default

Scenario when this would be used?
This can be used when viewing content from other countries, as not all software and services provide translation capabilities and it is not necessary to translate all content; If you can get the translated content through Run or OCR, it will be easier to understand and reduce the burden on the system, which eliminates the need to install any translation software. In particular, using software that does not support the user's native language can really produce a large number of phrases and words that can be translated quickly the first time they are used, which will make the user feel better
Supporting information
No response

/dup #18014


[Documentation] SELinux experimental support

SELinux support will be added as experimental in v1.17.4 as we'd like additional testing from the community. We should document known issues as necessary (release notes and/or in the K3s docs) and we should document any "gotchas" or other information that we are aware of.
This may also be a good place to discuss the disable-selinux flag and necessary config for containerd should you wish to disable selinux in an environment that has it set to Enforcing mode.

Hallo. During install, I have got info:
[ERROR]  Failed to apply container_runtime_exec_t to /usr/local/bin/k3s, please install k3s-selinux RPM
But I', not able to find **k3s-selinux ** RPM. Can you extend documentation about that, or give me a hint how-to continue, please ?

Sorry about that @polachz , the k3s-selinux policy can be installed like the following for now:
yum install -y container-selinux selinux-policy-base
rpm -i https://rpm.rancher.io/k3s-selinux-0.1.1-rc1.el7.noarch.rpm

the selinux policy rpm can also be found at https://github.com/rancher/k3s-selinux/releases
Hopefully in the future we will have a repo & k3s package available which will automatically install the required selinux policy.

Fixed in https://github.com/rancher/docs/pull/2397 including
yum install -y container-selinux selinux-policy-base
rpm -i https://rpm.rancher.io/k3s-selinux-0.1.1-rc1.el7.noarch.rpm

yum install -y container-selinux selinux-policy-base
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirrors.aliyun.com
 * extras: mirrors.aliyun.com
 * updates: mirrors.aliyun.com
Package 2:container-selinux-2.119.1-1.c57a6f9.el7.noarch already installed and latest version
Package selinux-policy-targeted-3.13.1-266.el7.noarch already installed and latest version
Nothing to do

 ⚡ root@es-node01  ~  rpm -i https://rpm.rancher.io/k3s-selinux-0.1.1-rc1.el7.noarch.rpm
warning: /var/tmp/rpm-tmp.8rJIvR: Header V4 RSA/SHA1 Signature, key ID e257814a: NOKEY
	package k3s-selinux-0.1.1-rc1.el7.noarch is already installed

 ✘ ⚡ root@es-node01  ~  curl -sfL https://get.k3s.io | sh -
[INFO]  Finding release for channel stable
[INFO]  Using v1.18.4+k3s1 as release
[INFO]  Downloading hash https://github.com/rancher/k3s/releases/download/v1.18.4+k3s1/sha256sum-amd64.txt
[INFO]  Skipping binary downloaded, installed k3s matches hash
[ERROR]  Failed to apply container_runtime_exec_t to /usr/local/bin/k3s, please install:
    yum install -y container-selinux selinux-policy-base
    rpm -i https://rpm.rancher.io/k3s-selinux-0.1.1-rc1.el7.noarch.rpm

Maybe I need more help here with Centos 7

Hello sir @davidnuzik
yum install -y container-selinux selinux-policy-base
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirrors.aliyun.com
 * extras: mirrors.aliyun.com
 * updates: mirrors.aliyun.com
Package 2:container-selinux-2.119.1-1.c57a6f9.el7.noarch already installed and latest version
Package selinux-policy-targeted-3.13.1-266.el7.noarch already installed and latest version
Nothing to do

 ⚡ root@es-node01  ~  rpm -i https://rpm.rancher.io/k3s-selinux-0.1.1-rc1.el7.noarch.rpm
warning: /var/tmp/rpm-tmp.8rJIvR: Header V4 RSA/SHA1 Signature, key ID e257814a: NOKEY
	package k3s-selinux-0.1.1-rc1.el7.noarch is already installed

 ✘ ⚡ root@es-node01  ~  curl -sfL https://get.k3s.io | sh -
[INFO]  Finding release for channel stable
[INFO]  Using v1.18.4+k3s1 as release
[INFO]  Downloading hash https://github.com/rancher/k3s/releases/download/v1.18.4+k3s1/sha256sum-amd64.txt
[INFO]  Skipping binary downloaded, installed k3s matches hash
[ERROR]  Failed to apply container_runtime_exec_t to /usr/local/bin/k3s, please install:
    yum install -y container-selinux selinux-policy-base
    rpm -i https://rpm.rancher.io/k3s-selinux-0.1.1-rc1.el7.noarch.rpm

Maybe I need more help here with Centos 7

the same error


Fix a small typo in vimtutor

I know it's not much, but I just noticed this while doing the vimtutor and thought why not fix it :)

Not sure why you closed this.  I suppose the change is OK.

In that case, you could add the new commit to your branch. No need to open a new PR.