Issue with Handling Categories Containing Path-like Structures in Names

Problem Description
I've encountered an issue with the current implementation of category handling in the parts import tool, specifically when dealing with categories that contain path-like structures in their names. An example of such a category is Crystals, Oscillators, Resonators/Pin Configurable/Selectable Oscillators, where Configurable/Selectable Oscillators is intended to be a distinct category rather than a path division.
Note that my instance of inventree contains the Digikey schema as published here:
https://github.com/silverXnoise/digikey-part-category-schema
The current approach uses string splitting on the "/" character to construct category keys. This method incorrectly interprets categories with path-like names as multiple nested categories, leading to inaccuracies in the representation of our inventory's structure.
Suggested Solution
To resolve this, I suggest revising the code to utilize the getParentCategory method for each PartCategory. This approach will accurately reflect the hierarchy by building category keys based on actual parent-child relationships rather than relying on string manipulation, which can be prone to errors with our current naming conventions.
A proposed solution has been drafted as follows:
def build_category_key(category):
    """Recursively build the category tuple using getParentCategory."""
    parents = []
    while category is not None:
        parents.insert(0, category.name)
        category = category.getParentCategory()
    return tuple(parents)

part_categories = {}

for part_category in PartCategory.list(inventree_api):
    part_categories[key] = build_category_key(part_category)

This adjustment should ensure that categories are accurately represented and organized within our system, regardless of how their names are formatted.
Thank you for considering this issue and proposed solution!

Hey, thanks for checking out the tool!
I've actually thought about this before and decided against this supposed solutiong, because the tiny problem with it is that that results in an API call per category. Which could result in like a minute of initialization time which is not bearable.
The real problem here is that the InvenTree API returns the path as a string in the first place imo, so that's probably what should be resolved.

I was aiming for the quick fix, I have to admit, and I didn't realize that the categories were refreshed every single time the tool was launched... and with thousands of categories it is obvious that the solution doesn't work well.

Yep, no worries. I'll see if I can find some time to make a PR to get things going on the InvenTree side the next few days.

I didn't get a chance to explore the API, but calling GET /api/part/category/ should return a list that already contains all the categories and from there, assembling the path locally wouldn't require several round trip for each sub category.

In the meantime, and because it was extremely inefficient, I've rewritten my code to make better use of the fact that we have a full list of category objects available. Short of having a "getParentKey" method that returns the primary key of the parent, I am accessing the _data member directly here. It's dirty, but it will do the trick until a final solution makes it to the code base.
So I created this method.
def build_category_hierarchy(categories):
    """
    Build a dictionary mapping each category's pk to a tuple of category names from root to the category itself.

    Args:
        categories (list of dicts): A list of PartCategory objects represented as dicts.

    Returns:
        dict: A dictionary with category pks as keys and tuples of category names as values.
    """
    category_map = {category['pk']: category for category in categories}

    def get_category_names(pk):
        if pk is None:
            return ()
        category = category_map.get(pk)
        if not category or 'parent' not in category or category['parent'] is None:
            return (category['name'],)
        parent_names = get_category_names(category['parent'])
        return parent_names + (category['name'],)

    result = {}
    for category in categories:
        category_names = get_category_names(category['pk'])
        result[category['pk']] = category_names

    return result

And I'm using it as follow
    part_categories = {}
    inventree_categories = PartCategory.list(inventree_api)
    inventree_hierarchy = build_category_hierarchy(inventree_categories)
    for part_category in inventree_categories:
        key = inventree_hierarchy[part_category['pk']]
        part_categories[key] = part_category

I'm thinking that each inventree API could implement an option to cache results in the first place (disabled unless requested since existing consumers likely assume fresh data on each call, and also possibly having some expiry built-in), but this system is very new to me and the suggestion possibly doesn't even align with the current architecture design.
Anyhow, thank you for this tool; it did pave the way for me to quickly build an inventory of parts for which I had lost control already!

I didn't get a chance to explore the API, but calling GET /api/part/category/ should return a list that already contains all the categories and from there, assembling the path locally wouldn't require several round trip for each sub category.

Oh yeah, actually you're right. That's what the PartCategory.list(...) call already returns and all the data required is already there (aka there's no need to call part_category.getParentCategory()).

Yeah, handling this is pretty easy actually. I ended up with something similar to your first proposed solution, thanks!

Sweet! Thank you!


CSS Hyphen Support for Chromium

Further information: https://www.chromestatus.com/feature/5642121184804864

This is not correct, sadly.

Blink enables the following values on all platforms: "manual" - the initial value. "none" - disables soft hyphens. and the following value on Android and Mac: "auto" - enables the automatic hyphenation for languages where the underlying operating system has dictionaries.

Also see #2925.
Therefore it probably should be y for Android, but partial with comment for desktop.

Oh shoot, how did I miss that?!
Thanks for the comment. I'll look into that later.


Help

Expected behavior
Actual behavior
Information about the Issue
Steps to reproduce the behavior

...
...

No information provided or steps to replicate - Closing


There's no way to return an error from MemoryBlockIterator

In C, a YR_MEMORY_BLOCK_ITERATOR  can set last_error from its iteration functions in order to return an error, but this doesn't seem to be accessible from go.

Guilty as charged. ;-) I think this was added to YARA for 4.1.0,  after I had done the iterator code. Just like file_size.
I have added another interface, MemoryBlockIterator in the iterator-last-error branch. Would you like to have a look if this works for you – and maybe contribute a test case for this? Thanks!

Making First, Next return an error would break the API. Perhaps for version 5.0.

doesn't adding a new method to the interface also break the API?

doesn't adding a new method to the interface also break the API?

No. For code using go-yara, implementing the extra interface is optional.
Even though this is not the most (Golang-)idiomatic way to signal an error, I can't think of a better alternative. Would you like to contirbute a test case?


Not able to access discount resource

I can access discount/discount_code APIs using my own call but using the GEM I am not able to access it. Discount code is no more under shopify plus. What am I missing here?

Thanks :). It is resolved.


fix(deps): update terraform-module

This PR contains the following updates:

Package
Type
Update
Change

terraform-ibm-modules/cos/ibm (source)
module
patch
7.5.0 -> 7.5.1

terraform-ibm-modules/kms-all-inclusive/ibm (source)
module
patch
4.8.3 -> 4.8.4

terraform-ibm-modules/resource-group/ibm (source)
module
patch
1.1.4 -> 1.1.5

terraform-ibm-modules/scc/ibm (source)
module
minor
1.1.3 -> 1.2.0

Release Notes

terraform-ibm-modules/terraform-ibm-cos (terraform-ibm-modules/cos/ibm)
v7.5.1
Compare Source
Bug Fixes

Don't output bucket name until it exists (#559) (697ccc3)

terraform-ibm-modules/terraform-ibm-kms-all-inclusive (terraform-ibm-modules/kms-all-inclusive/ibm)
v4.8.4
Compare Source
Bug Fixes

deps: update terraform ibm to latest for the deployable architecture solution (#425) (803a7a4)

terraform-ibm-modules/terraform-ibm-resource-group (terraform-ibm-modules/resource-group/ibm)
v1.1.5
Compare Source
Bug Fixes

extend the required terraform version to < 1.7 (#581) (5552c65)

terraform-ibm-modules/terraform-ibm-scc (terraform-ibm-modules/scc/ibm)
v1.2.0
Compare Source
Features

Added support to create SCC attachment using the new attachment submodule (#30) (6eb98ba)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

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

GitHub release
v1.1.1

Your semantic-release bot :package::rocket:


Questions about Face Verification

Hi, thanks for your work.
I am doing some experiments on LFW dataset for my paper, finding your experiments on Face Verification are interesting but unclear. And I could not reproduce the same result as yours.
Could you share your Face verification codes with me?
Thank you very much.

Hi, do you reproduce the results on face verification?


Use plugin.Name instead of string in all plugin configurations

Standardize on the use of plugin.Name type for all plugin configs, instead of string.
This provides a common, standardized handling of plugin references and makes the code easier to read.
Signed-off-by: David Chung<EMAIL_ADDRESS>

Current coverage is 65.15% (diff: 72.22%)

Merging #362 into master will increase coverage by 10.74%

@@             master       #362   diff @@
==========================================
  Files            19         45     +26
  Lines           816       2167   +1351
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits            444       1412    +968
- Misses          314        610    +296
- Partials         58        145     +87

Powered by Codecov. Last update 5a6c860...b09aadd


Cat Handler

PLS ACCEPT
Adds a command to get ai generated cat images from https://thiscatdoesnotexist.com/. Not sure if it works...

#glorious


CI: make source cache dependant on run number

Summary
This attempts to solve a problem where sometimes the source cache is being downloaded from Linux/Mac jobs as empty. I suspect it happens when the workflow runs again.
Impact
CI
Testing
Test via CI of this PR itself

@v01d can you just remove the use of the cache for the source.  With the new github cache infra the cache is never ready in time and it make this more complex.

So I should just leave the source passing between jobs via artifacts as it happens on cache miss?

So I should just leave the source passing between jobs via artifacts as it happens on cache miss?

Yeah, we can also move from actions/upload-artifact@v1 to actions/upload-artifact@v2  (and the download) and drop having the extra create source bundle step where the tar.gz is created.  That will improve the performance on that step as well.
V2 supports directory and not just file uploads https://github.com/actions/upload-artifact#upload-an-entire-directory

Ok, I can do that. Just checked the v2 and this is a bit concerning if the directory is used instead of tar: https://github.com/actions/upload-artifact#case-insensitive-uploads
If you don't think it is a problem I can follow your suggestion.

I just updated the PR to reflect the new way

Ok, I can do that. Just checked the v2 and this is a bit concerning if the directory is used instead of tar: https://github.com/actions/upload-artifact#case-insensitive-uploads
If you don't think it is a problem I can follow your suggestion.

Good catch.  Mostly on the permissions bit limitation.  I think it makes sense to just do the tar not tar.gz as they show, that way we do not compress twice.

Ok, I just pushed without the tar, I can bring it back.

Looks like uploading a directory is a bad idea, they seem to be streaming each file.  So yeah lets move back to tar as it was before.

Yup, I added the tar step and moved back to v1 as it failed with a permission problem.

Ok, should be good to merge.


AttributeError: type object 'RestEndpoint' has no attribute '_registry'

How to fix that?
Traceback (most recent call last):
File "/home/gpaquin/.local/bin/ledfx", line 7, in
from ledfx.main import main
File "/home/gpaquin/.local/lib/python3.5/site-packages/ledfx/main.py", line 26, in
from ledfx.core import LedFxCore
File "/home/gpaquin/.local/lib/python3.5/site-packages/ledfx/core.py", line 11, in
from ledfx.http import HttpServer
File "/home/gpaquin/.local/lib/python3.5/site-packages/ledfx/http.py", line 6, in
from ledfx.api import RestApi
File "/home/gpaquin/.local/lib/python3.5/site-packages/ledfx/api/init.py", line 8, in
class RestEndpoint(BaseRegistry):
File "/home/gpaquin/.local/lib/python3.5/site-packages/ledfx/utils.py", line 137, in no_registration
del cls._registry[name]
AttributeError: type object 'RestEndpoint' has no attribute '_registry'

Try python 3.6
On Sat, Nov 9, 2019, 3:11 PM Gilbert Paquin<EMAIL_ADDRESS>wrote:

How to fix that?
Traceback (most recent call last):
File "/home/gpaquin/.local/bin/ledfx", line 7, in
from ledfx.main import main
File "/home/gpaquin/.local/lib/python3.5/site-packages/ledfx/main.py",
line 26, in
from ledfx.core import LedFxCore
File "/home/gpaquin/.local/lib/python3.5/site-packages/ledfx/core.py",
line 11, in
from ledfx.http import HttpServer
File "/home/gpaquin/.local/lib/python3.5/site-packages/ledfx/http.py",
line 6, in
from ledfx.api import RestApi
File "/home/gpaquin/.local/lib/python3.5/site-packages/ledfx/api/init.py",
line 8, in
class RestEndpoint(BaseRegistry):
File "/home/gpaquin/.local/lib/python3.5/site-packages/ledfx/utils.py",
line 137, in no_registration
del cls._registry[name]
AttributeError: type object 'RestEndpoint' has no attribute '_registry'
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ahodges9/LedFx/issues/54?email_source=notifications&email_token=ALHKYG3QEIHR22QYJVG45EDQS4ROZA5CNFSM4JLJSU52YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HYGNNJQ,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALHKYG33JGEI7BBSEMJGFCTQS4ROZANCNFSM4JLJSU5Q
.


Add new primitive to example

Need to edit this example so as to include the newly added primitive, ellipsoid.
Though the version of p5.js should be updated first.

Ellipsoid was added to example but not to the library at p5js.org/js/p5.min.js.
Hence the reference http://p5js.org/reference/#/p5/ellipsoid is throwing an exception of ellipsoid not found.

just updated the library, should be working now, thanks!


Claims checks need to scope to an account

[ ] Uniqueness validator in Dashboard https://github.com/aptible/ember-cli-aptible-shared/blob/master/app/validators/uniqueness.js
[ ] App and Database claims in API https://github.com/aptible/api.aptible.com/blob/master/app/services/claims/base.rb

If we start passing multiple properties through the validators, perhaps this would allow us to fix another somewhat annoying bug: right now, when you create an app (or DB), the screen flashes the "handle is already taken" message after you save your app (because your app took the handle).
I'm not entirely sure whether Dashboard updates its representation of the app (or DB, etc.) after saving it, but if that's the case, then perhaps we could have Dashboard send, Resource ID, Resource Handle, and Account ID, and have the claims check only fire an error if the handle is already in use within the account by a resource with a different ID.

We should also be mindful that not everything in Aptible supports having multiple objects with the same handle within one organization.
For example, Dumptruck expects an app handle to be unique, and will feed you logs for the wrong app (if logs work on your stack) because it'll look for the app via its handle. This can be fixed by passing HREFs instead of handles (see this PR for an example: https://github.com/aptible/broadwayjoe/pull/37).
Do we have other tools that make the assumption that handles are unique? cc @fancyremarker

@krallin: Apart from Dumptruck/BroadwayJoe (and earlier versions of aptible-cli), I don't believe there are client apps that assume global handle uniqueness.

For the record; I fixed this in Dumptruck a little while ago: https://github.com/aptible/dumptruck/pull/14


Installation on AMD GPU with ROCm / HIP:  error: use of undeclared identifier 'CUDART_VERSION'

I checked the issues in this Repo and searched the error on search engines and forums but found nothing helpful.

Hi there, thanks for releasing this amazing work!
I am trying to run MMLab's Open Tracking. Part of this is the installation of GroundingDino, where I run into difficulties.
When not setting CUDA_HOME of course the typical NameError: name '_C' is not defined error occurs when running the model.
Since my PC has an AMD GPU I am not sure if I set the environment variable correctly.

Details about my environment

Running mmdetections ``mmdet/utils/collect_env.py``
/bin/sh: 1: /opt/rocm-6.0.2/bin/nvcc: not found
sys.platform: linux
Python: 3.9.19 (main, Mar 21 2024, 17:11:28) [GCC 11.2.0]
CUDA available: True
MUSA available: False
numpy_random_seed:<PHONE_NUMBER>
GPU 0: AMD Radeon RX 6800 XT
CUDA_HOME: /opt/rocm-6.0.2
NVCC: Not Available
GCC: gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
PyTorch: 2.4.0.dev20240501+rocm6.0
PyTorch compiling details: PyTorch built with:
  - GCC 9.3
  - C++ Version: 201703
  - Intel(R) oneAPI Math Kernel Library Version 2022.2-Product Build 20220804 for Intel(R) 64 architecture applications
  - Intel(R) MKL-DNN v3.3.6 (Git Hash 86e6af5974177e513fd3fee58425e1063e7f1361)
  - OpenMP 201511 (a.k.a. OpenMP 4.5)
  - LAPACK is enabled (usually provided by MKL)
  - NNPACK is enabled
  - CPU capability usage: AVX512
  - HIP Runtime 6.0.32830
  - MIOpen 3.0.0
  - Magma 2.7.2
  - Build settings: BLAS_INFO=mkl, BUILD_TYPE=Release, CXX_COMPILER=/opt/rh/devtoolset-9/root/usr/bin/c++, CXX_FLAGS= -D_GLIBCXX_USE_CXX11_ABI=0 -fabi-version=11 -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -DNDEBUG -DUSE_KINETO -DLIBKINETO_NOCUPTI -DUSE_FBGEMM -DUSE_QNNPACK -DUSE_PYTORCH_QNNPACK -DUSE_XNNPACK -DSYMBOLICATE_MOBILE_DEBUG_HANDLE -O2 -fPIC -Wall -Wextra -Werror=return-type -Werror=non-virtual-dtor -Werror=bool-operation -Wnarrowing -Wno-missing-field-initializers -Wno-type-limits -Wno-array-bounds -Wno-unknown-pragmas -Wno-unused-parameter -Wno-unused-function -Wno-unused-result -Wno-strict-overflow -Wno-strict-aliasing -Wno-stringop-overflow -Wsuggest-override -Wno-psabi -Wno-error=pedantic -Wno-error=old-style-cast -Wno-missing-braces -fdiagnostics-color=always -faligned-new -Wno-unused-but-set-variable -Wno-maybe-uninitialized -fno-math-errno -fno-trapping-math -Werror=format -Wno-stringop-overflow, LAPACK_INFO=mkl, PERF_WITH_AVX=1, PERF_WITH_AVX2=1, PERF_WITH_AVX512=1, TORCH_VERSION=2.4.0, USE_CUDA=OFF, USE_CUDNN=OFF, USE_CUSPARSELT=OFF, USE_EXCEPTION_PTR=1, USE_GFLAGS=OFF, USE_GLOG=OFF, USE_GLOO=ON, USE_MKL=ON, USE_MKLDNN=ON, USE_MPI=OFF, USE_NCCL=1, USE_NNPACK=ON, USE_OPENMP=ON, USE_ROCM=ON, USE_ROCM_KERNEL_ASSERT=OFF,

TorchVision: 0.19.0.dev20240501+rocm6.0
OpenCV: 4.9.0
MMEngine: 0.10.4
MMDetection: 3.3.0+16e0ccd

Running pytorch's ``torch.utils.collect_env``
/home/zupan/miniconda3/envs/venv_pythia/lib/python3.9/runpy.py:127: RuntimeWarning: 'torch.utils.collect_env' found in sys.modules after import of package 'torch.utils', but prior to execution of 'torch.utils.collect_env'; this may result in unpredictable behaviour
  warn(RuntimeWarning(msg))
Collecting environment information...
PyTorch version: 2.4.0.dev20240501+rocm6.0
Is debug build: False
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: 6.0.32830-d62f6a171

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: Could not collect
Libc version: glibc-2.35

Python version: 3.9.19 (main, Mar 21 2024, 17:11:28)  [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-6.5.0-28-generic-x86_64-with-glibc2.35
Is CUDA available: True
CUDA runtime version: Could not collect
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration: AMD Radeon RX 6800 XT (gfx1030)
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: 6.0.32830
MIOpen runtime version: 3.0.0
Is XNNPACK available: True

CPU:
Architecture:                       x86_64
CPU op-mode(s):                     32-bit, 64-bit
Address sizes:                      39 bits physical, 48 bits virtual
Byte Order:                         Little Endian
CPU(s):                             16
On-line CPU(s) list:                0-15
Vendor ID:                          GenuineIntel
Model name:                         11th Gen Intel(R) Core(TM) i9-11900K @ 3.50GHz
CPU family:                         6
Model:                              167
Thread(s) per core:                 2
Core(s) per socket:                 8
Socket(s):                          1
Stepping:                           1
CPU max MHz:                        5300.0000
CPU min MHz:                        800.0000
BogoMIPS:                           7008.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 sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx avx512f avx512dq rdseed adx smap avx512ifma clflushopt intel_pt avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid fsrm md_clear flush_l1d arch_capabilities
L1d cache:                          384 KiB (8 instances)
L1i cache:                          256 KiB (8 instances)
L2 cache:                           4 MiB (8 instances)
L3 cache:                           16 MiB (1 instance)
NUMA node(s):                       1
NUMA node0 CPU(s):                  0-15
Vulnerability Gather data sampling: Mitigation; Microcode
Vulnerability Itlb multihit:        Not affected
Vulnerability L1tf:                 Not affected
Vulnerability Mds:                  Not affected
Vulnerability Meltdown:             Not affected
Vulnerability Mmio stale data:      Mitigation; Clear CPU buffers; SMT vulnerable
Vulnerability Retbleed:             Mitigation; Enhanced IBRS
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:           Mitigation; Enhanced / Automatic IBRS, IBPB conditional, RSB filling, PBRSB-eIBRS SW sequence
Vulnerability Srbds:                Not affected
Vulnerability Tsx async abort:      Not affected

Versions of relevant libraries:
[pip3] numpy==1.26.4
[pip3] pytorch-triton-rocm==3.0.0+bbe6246e37
[pip3] torch==2.4.0.dev20240501+rocm6.0
[pip3] torch-tb-profiler==0.4.3
[pip3] torchaudio==2.2.0.dev20240501+rocm6.0
[pip3] torchdata==0.7.1+8e84488
[pip3] torchvision==0.19.0.dev20240501+rocm6.0
[conda] libopenvino-pytorch-frontend 2023.2.0             h59595ed_0    conda-forge
[conda] libtorch                  2.1.2           cpu_mkl_hcefb67d_103    conda-forge
[conda] mkl                       2023.2.0         h84fe81f_50496    conda-forge
[conda] numpy                     1.26.4           py39heeff2f4_0
[conda] numpy-base                1.26.4           py39h8a23956_0
[conda] pytorch-triton-rocm       3.0.0+bbe6246e37          pypi_0    pypi
[conda] torch                     2.4.0.dev20240501+rocm6.0          pypi_0    pypi
[conda] torch-tb-profiler         0.4.3                    pypi_0    pypi
[conda] torchaudio                2.2.0.dev20240501+rocm6.0          pypi_0    pypi
[conda] torchdata                 0.7.1            py39h50156ae_3    conda-forge
[conda] torchvision               0.19.0.dev20240501+rocm6.0          pypi_0    pypi

I  export CUDA_HOME=/opt/rocm-6.0.2/ and tried to install GroundingDINO
git clone git+https://github.com/IDEA-Research/GroundingDINO.git
cd GroundingDINO
pip install -v -e .

Unfortunately I get the following warning and errors during the installation:
...
  76 warnings generated when compiling for gfx1030.

...
    groundingdino/models/GroundingDINO/csrc/hip_version.hip:6:10: error: use of undeclared identifier 'CUDART_VERSION'
      return CUDART_VERSION;
             ^
    1 error generated when compiling for gfx1030.
    error: command '/opt/rocm-6.0.2/bin/hipcc' failed with exit code 1

 Content of ``hip_version.hip``
// !!! This is a file automatically generated by hipify!!!
#include <hip/hip_runtime_api.h>

namespace groundingdino {
int get_cudart_version() {
  return CUDART_VERSION;
}
} // namespace groundingdino

I tried  export CUDART_VERSION=60032831 as an environment variable using python:
from cuda import cudart
cudart.cudaRuntimeGetVersion()
# (<hipError_t.hipSuccess: 0>, 60032831)

to no avail.
Do I use the environment variables correctly or are there other requirements when using AMD/ROCm/HIP?
If more information is required, please let me know what you need (and how to get the information).
Any help or pointers in the right direction would be appreciated.

Hi, I have same issue, anyone found any workaround ?

No, unfortunately I haven't found anything useful. For now I have given up on investigating further, but if you come across something, please let me know. Good luck!

I made it run with defining CUDART_VERSION explicitly in path "Grounded-Segment-Anything/GroundingDINO/groundingdino/models/GroundingDINO/csrc/cuda_version.cu". As below;
namespace groundingdino { int get_cudart_version() {   //return CUDART_VERSION;   return 6032831; //your cuda version } } // namespace groundingdino

It worked for me as well. Makes sense that replacing the code part in the .hip file didn't work as it gets generated and overwritten. Thank you!


chore(package): update eslint-config-airbnb-base to version 11.0.1

Closes #47
https://greenkeeper.io/

Coverage remained the same at 100.0% when pulling c18447d779a72098b17c1af168525eef39339726 on greenkeeper/eslint-config-airbnb-base-11.0.1 into 239349ce065da3433a055cbc91a4110a62963de2 on master.

Coverage remained the same at 100.0% when pulling c18447d779a72098b17c1af168525eef39339726 on greenkeeper/eslint-config-airbnb-base-11.0.1 into 239349ce065da3433a055cbc91a4110a62963de2 on master.


[BUG] CartLineQuantityAdjustButton overwrites attributes added by AddToCartButton

Describe the bug
When adding items to the shopping cart with AddToCartButton using attributes passed through the attributes prop, the attributes later appear to be overridden and removed if the quantity for that cart line is adjusted using CartLineQuantityAdjustButton.
To Reproduce
https://stackblitz.com/edit/shopify-hydrogen-n3hfqc
I have minimally modified this to pass attributes through the AddToCartButton in ProductForm.client.jsx, and to display any attributes in the CartLineItem.client.jsx.  To reproduce the bug, add an item to the shopping cart.  It should show the attribute 'Test: Testing' when you open the shopping cart.
Once the quantity is increased, the 'Test: Testing' attribute disappears.
Expected behaviour
I expected attributes to be retained unchanged when the quantity of the cart line item is adjusted.
Screenshots
If applicable, add screenshots to help explain your problem.

Describe the bug When adding items to the shopping cart with AddToCartButton using attributes passed through the attributes prop, the attributes later appear to be overridden and removed if the quantity for that cart line is adjusted using CartLineQuantityAdjustButton.
To Reproduce
https://stackblitz.com/edit/shopify-hydrogen-n3hfqc
I have minimally modified this to pass attributes through the AddToCartButton in ProductForm.client.jsx, and to display any attributes in the CartLineItem.client.jsx. To reproduce the bug, add an item to the shopping cart. It should show the attribute 'Test: Testing' when you open the shopping cart.
Once the quantity is increased, the 'Test: Testing' attribute disappears.
Expected behaviour I expected attributes to be retained unchanged when the quantity of the cart line item is adjusted.
Screenshots If applicable, add screenshots to help explain your problem.

I'm having the same issue. I used the out-of-the-box Shopify Hydrogen project and:

Updated the  component with the attributes={[{ key: "previewImageUrl", value: "anyimage.url" }]}
Added the product to cart and logged the attributes for the line (this works)
Increased the quantity of the line in the cart
Logged the new attributes - the attributes array is now empty

Recommendation
The CartLineQuantityAdjustButton needs to be updated to include the attributes


qa.vb map: histogram of count of traps throws 500

To reproduce: I filtered by species "Aedes", then made a histogram for "counts of traps".

Rserve error:
2024-03-24 00:04:36.464773 Determined bin width slider min, max and step values.
Error in veupathUtils::cut_width(xVP, binWidth, boundary = min(xVP)) :
Less than two breaks in utils-cut.R
In addition: Warning messages:
1: replacing previous import ‘veupathUtils::toJSON’ by ‘jsonlite::toJSON’ when loading ‘plot.data’
2: In veupathUtils::nonZeroRound(binSliderMax, avgDigits) :
Input is already zero and cannot be rounded to a non-zero number.
3: In veupathUtils::nonZeroRound(binSliderMin, avgDigits) :
Input is already zero and cannot be rounded to a non-zero number.
4: In veupathUtils::nonZeroRound(((binSliderMax - binSliderMin)/1000),  :
Input is already zero and cannot be rounded to a non-zero number.

This is the request body:
{
	"config": {
		"barMode": "stack",
		"binSpec": {
			"type": "binWidth",
			"value": 4
		},
		"outputEntityId": "OBI_0000659",
		"valueSpec": "count",
		"xAxisVariable": {
			"entityId": "OBI_0000659",
			"variableId": "EUPATH_0043046"
		}
	},
	"filters": [
		{
			"entityId": "EUPATH_0000609",
			"stringSet": [
				"Aedes <genus>"
			],
			"type": "stringSet",
			"variableId": "OBI_0001909"
		},
		{
			"entityId": "GAZ_00000448",
			"max": 81.14748070499664,
			"min": -58.26328705248602,
			"type": "numberRange",
			"variableId": "OBI_0001620"
		},
		{
			"entityId": "GAZ_00000448",
			"left": -170.15624999000002,
			"right": -170.15625000000003,
			"type": "longitudeRange",
			"variableId": "OBI_0001621"
		}
	],
	"studyId": "VBP_MEGA"
}

@d-callan why do you say this binWidth (4) is nonsensical?

fwiw, this is the post body without filters:
{
	"config": {
		"barMode": "stack",
		"binSpec": {
			"type": "binWidth",
			"value": 4
		},
		"outputEntityId": "OBI_0000659",
		"valueSpec": "count",
		"xAxisVariable": {
			"entityId": "OBI_0000659",
			"variableId": "EUPATH_0043046"
		}
	},
	"filters": [
		{
			"entityId": "GAZ_00000448",
			"max": 81.14748070499664,
			"min": -58.26328705248602,
			"type": "numberRange",
			"variableId": "OBI_0001620"
		},
		{
			"entityId": "GAZ_00000448",
			"left": -170.15624999000002,
			"right": -170.15625000000003,
			"type": "longitudeRange",
			"variableId": "OBI_0001621"
		}
	],
	"studyId": "VBP_MEGA"
}

I do get a success response with this, so the filter is partly responsible for the 500.

How should the client determine the appropriate bin width size?

I think the idea is that it shouldn't. It should let the back end figure out an appropriate bin width

It shouldn't. If you pass nothing for bin width the backend will find the default for that subset,  as well as return appropriate bin slider specs.

The same issue happens in regular eda, fwiw

@d-callan @bobular can one of you propose rules for when the front-end should send a bin width? It almost sounds like "never", but that seems too easy

Also, this should be a 400 response, not a 500

i mean it should pass one if the user modifies the default, but by default it should only pass a bin width in the filter menu (to the distributions endpoint, rather than histogram) and never in the floaters.
and yea i know a 500 isnt ideal, but its a bit non-trivial, and there are other issues floating around the place about that.

Ok, so the default bin width for visualizations should be empty. I will make an issue in web-monorepo for this

could just update the title of this one no?

I would rather close this and make a new one, for future reference


Bump minimum supported Go version to 1.19

Google Go Client Libraries are bumping minimum supported version to 1.19 to match the policy of supporting latest 3 major versions.

Closed by #394


Window position as hint

Should we provide window position before creating it?
glfwWindowHint(GLFW_POSITION_X, 100); glfwWindowHint(GLFW_POSITION_Y, 120);

You can create a hidden window, position as you wish and then show it.

Agreed, and it may be a good thing to add to glfwCreateWindow in the next API revision.

I've got this implemented in a basic way on my fork.
This was just done with window.c so it should work will all platforms. This also allows for the default location of either X or Y to be applied if only one of the hints was given.
There is the problem that for the first few frames (usually 4 main loops for me) the window would be in the default location. This creates an obvious jump.
I have been trying (and will continue) to get rid of this initial jump. It would appear to me that this requires setting up this implementation in each _glfwPlatformCreateWindow function.  I'm on Ubuntu and was experimenting but could not seem to get X11 to respect the values I passed in during XWindowCreate, perhaps because of the defaults being set later during _glfwPlatformShowWindow.
If the changes I made on my fork seem acceptable I'll turn it into a PR. Otherwise I would not mind any ideas or guidance on how to remove the jitter. I'll continue looking into this for a little while longer.
I'll also mention, I feel like adding this to glfwCreateWindow would be convenient, it might be getting to cluttered as a signature. Also forcing the user to chose a position could be awkward as  most of the time the window system chooses a specific position.

The html docs on the website don't document this feature, perhaps it should be added there too?

@flysand7 Done. Thanks!


Automatically enable requesting broadcast reply on ipvlan

The dhcpcd.conf manual states:
     broadcast
             Instructs the DHCP server to broadcast replies back to the client.  Normally this is only set for non-Ethernet interfaces, such as FireWire and InfiniBand.  In most cases, dhcpcd will set this automatically.

Would it be possible to do this for ipvlan interfaces as well?
Unicast packets don't make it through the device unless it's configured. I don't know if this can be worked around, but by design it only demuxes based on layer 3 data.

I don't see a reason why not.
We would need a way to detect if the interface is ipvlan or not.
Do you would how this could be achieved?
We would also need to adjust the default IAID for the interface as well as the MAC address is shared.
https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/dhcpcd.c#L471

I'm having a hell of a time figuring ipvlans out myself, so I don't really know. How do you detect the other stuff?

/sys/class/net might have something.
dhcpcd works out bridge and tap devices like that:
https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/if-linux.c#L166
https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/if-linux.c#L328

The ipvlan source is here if that helps any https://github.com/torvalds/linux/tree/master/drivers/net/ipvlan

While these are in /sys/class/net, I thought this kind of information generally came from a combination of if_nameindex and AF_NETLINK.  For the latter, there's a library (iirc, called libnl) that has plenty of examples of using AF_NETLINK for finding other kinds of interfaces, route info, etc.  Based on the ipvlan code @deliciouslytyped linked, it looks like you can also get information about an ipvlan interface from netlink on Linux.
https://man7.org/linux/man-pages/man7/netlink.7.html

The specific info around whether broadcast via ipvlan is available might be in rtnetlink.

You have a good point in that broadcast isn't available in all ipvlan modes IIUC, I forgot about that because I've only been using the L2 mode. The initial problem was that I wasn't able to get the DHCP replies at all over unicas;  because you can't receive to IPs that aren't yours (IIUC).

IFF_BROADCAST     Valid broadcast address set.
Doesn't mean that we need to set the broadcast bit in DHCP messages sadly.

While it has a lower_eth0 symlink, at least upon first glance, I don't see anything promising in /sys/class/net/eth0ipvl1 to identify the interface as ipvlan. iproute2 seems to use netlink to detect ipvlan. I'll probably have to do the same on Linux hosts.

You can base new code on the netlink code to get the wireless SSID found here:
https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/if-linux.c#L1405

The initial problem was that I wasn't able to get the DHCP replies at all over unicast;  because you can't receive to IPs that aren't yours (IIUC).

I just want to make sure I understand your setup here, because your statement here is making me question whether this is solvable with DHCP broadcast replies.
Disclaimer just to get the obvious out of the way: ipvlan shares a MAC address with its parent interface.  This makes DHCP tricky.  macvlan does not have this problem, and may be a cleaner choice for you depending on your setup, since each interface would then have its own MAC address.
Help me replicate your setup, so that I can get a sense if this will work or not, can you share how your interfaces are configured?
Also:

Which ipvlan mode are you using? (Note: L2 responds to ARP for the child interface IP address(es) and can receive bcast. L3 and L3S modes do not receive broadcast traffic and rely on the default netns nftables rules to get traffic out or in/out, respectively.)
The DHCP unicast replies are arriving at the host/parent interface because it shares a MAC address with the ipvlan interface(s) running the DHCP client(a), right?  Can you see the DHCP unicast replies (e.g. offer) on the parent interface with tcpdump, but not on the container's ipvlan interface?
Is the problem that you don't have a good way to get those unicast DHCP replies to the correct container/netns interface that requested them in the first place?  Furthermore, if you own the container host, and you're willing to use L3S mode, isn't there a way to get the inbound DHCP packets from the parent interface to the ipvlan interfaces using the host firewall (iptables/nftables/bpf) table?

That is why we need to set the broadcast bit in the DHCP message we sent to instruct the server to broadcast the reply rather than unicasting it.
https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/dhcp.c#L790
We need to set the flag somewhere here for ipvlan interfaces:
https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/dhcpcd.c#L435

That is why we need to set the broadcast bit in the DHCP message we sent to instruct the server to broadcast the reply rather than unicasting it.
https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/dhcp.c#L790

I was able to get that working with L2 mode, but with L3/L3S mode ipvlan interfaces, it looks like broadcast packets are not copied from/to the ipvlan interfaces depending on configuration, so I want to make sure I understood @deliciouslytyped's specific interface configuration to replicate it.  The outbound DHCP DISCOVER never makes it to the physical switch interface in ipvlan L3 mode, for example, despite the interface being labeled as supporting broadcast.
For example, I saw a container networking implementation a couple years ago that did stateful DHCP relaying between the container interfaces and external DHCP server by tracking DHCP XIDs or (where available) client-IDs, which seems like a strategy that'd work for all three modes (L2/L3/L3S) and wouldn't require broadcast replies, just a relay/forwarding program.

We need to set the flag somewhere here for ipvlan interfaces:
https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/dhcpcd.c#L435
OR just set the flag in the DHCP code linked above.

Thanks for the pointer, that saved me a couple of greps. 😄

I just figured it would be reasonable to detect ipvlan additionally to the other two cases, because unicast doesn't work with L2 mode ipvlan unless you already have the IP you're being assigned. (I don't understand how this works with other device either though...)

For L2 ipvlan, setting the broadcast flag makes sense, and I'm planning to put that patch forward.

If you have any good suggestions how to work around this, that would be great, because I didn't understand the suggested workarounds yet, or they don't look very good. The document says macvlan has the same problem though?

I'm looking for alternatives that will work for unicast DHCP OFFERs if you know the container hostnames/client-IDs (not IPs), or are willing to be stateful (DHCP XIDs) and can inject the DHCP replies you're seeing on the host interface into the ipvlan interfaces.  That alternative would work across all types of ipvlan interfaces, but requires further research.
The reason one might want to have unicast OFFERs where possible is that with broadcast, all neighboring containers and hosts in the broadcast domain would see the new container.  Depending on one's threat model, that may not be desired.  (For example, if you allow containers from different untrusted third parties on the same host, that could introduce crosstalk between parties that shouldn't exist.)
macvlan does not share a MAC address with the host interface, so it does not have the same problem - the DHCP OFFER packets destined for the macvlan interface MAC address get bridged over to the macvlan interface MAC address from the physical port.  The host interface may need to be in promiscuous mode, or require some ebtables configuration, but it's possible without a DHCP relay or inspecting the DHCP packet beyond the destination MAC.  Hope that clears it up.
In the case of an ipvlan, the destination MAC of the DHCP OFFER is the MAC address of the host interface and ipvlan interfaces, so the decision of which interface to send the packet to can't be made by the host based on the destination MAC alone.  And since the ipvlan interface doesn't yet have an IP address, as you point out, you'd need an alternative method to forward them into the container's ipvlan interface, for example based on deeper inspection of the DHCP OFFER - e.g. client ID, hostname, or XID...  That's what I was investigating.

The DHCP unicast replies are arriving at the host/parent interface because it shares a MAC address with the ipvlan interface(s) running the DHCP client(a), right? Can you see the DHCP unicast replies (e.g. offer) on the parent interface with tcpdump, but not on the container's ipvlan interface?

Yes the packets are visible on the host interface. (IIUC - they were definitely visible somewhere, which is part of how I figured out that I needed this in the first place)

Excellent, then there is some hope we can forward them into the container somehow... :-D

Is the problem that you don't have a good way to get those unicast DHCP replies to the correct container/netns interface that requested them in the first place? Furthermore, if you own the container host, is there a way to get the inbound DHCP packets from the parent interface to the ipvlan interfaces using the host firewall (iptables/nftables/bpf), for example by using the DHCP hostname (option 12) field to route them to the appropriate ipvlan interface? (One approach that looks promising is to use a different DHCP client-ID on each ipvlan interface to differentiate them and route the DHCP offer replies back to the correct interface (e.g. using netfilter rules) on that basis.)

This is partially answered by the above, but also, I have no idea how to move packets around with iptables. If you have any recommended literature, I'd be happy to hear. It might help alleviate the "master can't talk to slave" problem. (I don't understand why they can "external" packets but not ones hitting the master interface from the same machine?)
I did manually set a client ID, but I don't know if it's strictly needed (or if dhcpcd sets a unique one automatically). containernetworking/cni#17 (comment) brought the setting to my attention, and it makes sense, so I set it. That guy seems to have a clue about how this works.

It looks like we're reading more or less the same things.  They're implementing more or less what I'm suggesting above with client IDs.  If there were an iptables conntrack extension for DHCP, that would come in super useful here, since you could conntrack by DHCP XID or client ID across ipvlan interfaces, and everything would work out...seems like that's the missing piece for getting L3/L3S ipvlan working properly with unicast (and maybe even L2).  (Obviously out of scope for dhcpcd, but if you're feeling pioneering...)

For example, I saw a container networking implementation a couple years ago that did stateful DHCP relaying between the container interfaces and external DHCP server by tracking DHCP XIDs or (where available) client-IDs hostname (option 12), which seems like a strategy that'd work for all three modes (L2/L3/L3S) and wouldn't require broadcast replies, just a stateful relay (e.g. in netfilter).

I don't know how containers work internally, but it seems there are some basic features, which get combined into what ends up being called "containers". I use systemd-nspawn, because some infrastructure is already provided by my linux distro. I don't know any details but it seems thinner than stuff like docker, so probably pretty minimal. Any daemon or such, I would have to use in addition.
Once you're limited to L3 stuff, I think you start using dhcp relay daemons?

Or iptables-/ebpf-based options with to forward DHCP packets into the ipvlan interfaces (from the host) based on DHCP client ID, etc.

This whole project of mine came from trying to run a proxyDHCP (weird name for what it does?) server so I could run a PXE server in a container, and it works now :)
I actually had a pretty hard time finding my way around tooling in the dhcp space.

For what it's worth, I also use systemd-nspawn or lxc, and prefer to avoid heavier container orchestration systems (e.g. Docker) because of their attack surface.

I'm not sure I understood this correctly, and it complicates setup (but sounds like it makes it possible at all); a slave device could be added in the "host" environment next to the master device, and then routing done?

It should be doable without another child interface, using netfilter/XDP/eBPF, or possibly even just a relay agent of some sort listening on the master interface and injecting packets into the ipvlan interface.
Anyhow, a draft of the broadcast patch is available in #33.  I'm still cleaning it up but it should be functional now, if you want to try it out.   Note that you will need to explicitly set the IAID or client ID for ipvlan interfaces in the current version of the patch, because it will otherwise pick up the MAC address to generate the IAID, which for ipvlan will be the same as the IAID of the parent interface and therefore get you the same IP address in the DHCP OFFER as the parent interface...
Unfortunately, for properly namespaced ipvlan interfaces that have the same interface name (e.g. eth0) and MAC address as the parent interface, I think finding a way to generate a unique (and stable across reboots) IAID will be challenging.
I'm thinking about migrating to an approach that generically tracks "child" and "parent" interface relationships and enables broadcast + alternate default IAID when their MAC addresses are the same, but for now moving forward with ipvlan-specific code.

If it detects ipvlan it could bail/leave a lot message about needing an id set?

If it detects ipvlan it could bail/leave a log message about needing an id set?

A log message seems fair.  However, if we're going to bail when the ipvlan interface doesn't have an IAID configured, we might as well also suggest they configure broadcast for the ipvlan interface in the same message and not set it for the user...  So, I'm looking into how I might solve this without any configuration required by the user, and without bailing on ipvlan interfaces by default for a little longer first... :-)
Also, thanks for the reminder, the current patch does not yet check if the interface is configured, and should probably only set broadcast if the interface isn't configured (i.e. if_noconf).

Yeah on second though, I just realized it's kind of all-or-nothing, because if broadcast gets set automatically but the client ID isn't set, something weird could happen? So a sane default needs to be found, or you cant really do this automatically? Good luck.

If it's ipvlan then default the IAID to the interface name if 4 chars or less, otherwise index.
It's the best we can do. No it's not stable across reboots without configuration and this is how dhcpcd configures other interfaces lacking hardware address.
https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/dhcpcd.c#L524

If it's ipvlan then default the IAID to the interface name if 4 chars or less, otherwise index.
It's the best we can do. No it's not stable across reboots without configuration and this is how dhcpcd configures other interfaces lacking hardware address.
https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/dhcpcd.c#L524

I was playing around with hashing the network namespace + interface name, but I think you're right.  Unfortunately, the likely outcome here will be that a very common setup will result in a conflict: Suppose you have two "containers" (network namespaces) with an ipvlan interface in each one named eth0, and a physical/lower interface named eth0 in the init netns (outside the "containers").  The IAIDs of the ipvlan interfaces will conflict in this case.  This seems too much like magic that will surprise the user in unexpected ways, so I'll output a warning message when we see an ipvlan interface to the effect of strongly recommending that they set a custom IAID.

I don't know what kind of things it's appropriate to do here, if you want to avoid conflicts wouldn't it be better to set a random suffix per boot and recommend setting an ID if the user wants stability? or is DHCP space exhaustion if you reboot a lot bad too?
To prevent churn you could then save the suffix to a state file.

Another option is to ignore the interface unless there is a configuration for it as we do for tap and bridge interfaces on Linux:
https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/if.c#L555
https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/if-linux.c#L351

Brief update - haven't forgotten about this - going to implement your suggestions @rsmarples.


Serde needs a community.

Serde needs a community, because a lot of people ask questions when something don't work. And they could discuss Serde in this community.

Oh, Serde don't need.


For DEV only:  Auto-generate fake ctf data

See title  @x64x6a

I just committed a demo json database dump.
To load it, we can just run this once the dev container is loaded:
./manage.py loaddata scripts/databases/demo.json

I wouldn't want to add this to the dev container script in case we're developing something outside the scope of the demo data.
Another issue with this this method is the graph might look funny a few days after I created it.
Maybe we should modify the graph to not show new data that hasn't changed.
I think it would end up like this, except the long lines would be even longer:


Set ServiceBinding .spec.name to the CFServiceBinding's displayName

Is there a related GitHub Issue?
Issue: https://github.com/cloudfoundry/korifi/issues/2285
What is this change about?
Some service binding libraries (such as the Oauth2 connector in Spring Cloud Bindings) use a Service Binding's name as a configuration value. This does not always place nicely with the Service Instance GUID that Korifi currently sets for the Service Binding's name.
This change allows users to override the .spec.name property of a Service Binding during binding creation using the cf bind-service --binding-name parameter. If --binding-name is omitted then the ServiceBinding continues to use the Service Instance GUID as its name.
Does this PR introduce a breaking change?
No, it should only impact new service bindings.
Acceptance Steps

Push the golang test app (tests/e2e/assets/golang): cf push test-app
Create an UPSI: cf cups my-upsi -p '{"secret": "credential"}'
Bind the service and specify a name: cf bind-service test-app my-upsi --binding-name my-custom-binding
curl the /servicebindings or /servicebindingroot endpoint to see that the binding name is reflected in the app container

Tag your pair, your PM, and/or team
@akrishna90 since this builds on those service binding tests you added :)

Here you go @alexbarbato 🙂


Update localhost URL in Web USB article to use code formatting.

@beaufortfrancois since this is your post. :-)


Explore using Gatsby v4

Gatsby 4 is coming... ❄
Acceptance Criteria

[ ] Confirm when beta version is available for Gatsby 4

[ ] Determine What portion of New Relic's docs site would you envision applying

DSG and Why?
SSR and  Why?

[ ] Share feedback with Gatsby  PM: Patrick Sullivan

[ ] Update a branch of the Doc Site to test it out

[ ] report any weird findings

Effort
Impact

TBD
TBD

@aswanson-nr spent some time on this yesterday and we definitely want to upgrade to G4 as soon as it's out of beta as we can leverage SSR for our searching needs on the I/O site.


Fixed agenda numbering. Fixed #1892.

Please fix the tests. The code looks ok

Please review carefully this new code.

One proposal. Merge if you like


⚠ Bofrost.nl has degraded performance

In 4f85aa4, Bofrost.nl (https://www.bofrost.nl) experienced degraded performance:

HTTP code: 200
Response time: 1321 ms

Resolved: Bofrost.nl performance has improved in a5e4fe0.


Connect Wallet Visual Update

Little visual update, colors outlines and added balance + current network.
I like how this looks now, but we can wait until we get updated chain icons to display if you like.
As for switching networks, I'm not sure it's the best idea for a game connect wallet prefab as most games will be on a specific chain + will require tinkering with the prefab to remove it.
Switching network as a separate prefab later on perhaps?

Will add Prefab_SwitchNetwork as a separate prefab and append it to connect wallet so people can just set it inactive if they don't want it. It'll be on a simple > icon near current network.

Chain enum instead of strings in the editor, has chain ID built in, and a dictionary in case you need the string identifier, in ThirdwebManager
Added switching networks to the connect wallet prefab, there's a bool on whether you want to support it or not which auto turns off its UI
Added supported networks to ThirdwebManager, when switching network only those will display
Prefab_NFTLoader now scales with the screen
Other minor improvements

Updated and restructured a little

@0xFirekeeper a bit too much to have all the chain icons i think, can we just keep the ones from the chains we support, and maybe only the high res version for each?

last thing i noticed too : on the dropdown when con

nected, the current network still has the placeholder icon

Ah good catch, fixing

Should be good now


Doctrine queries are shared across steps and always performed

I have a 3-step form, each step has some entity field types, step 3 doesn't have any at all. Excerpt:
    public function buildForm(FormBuilderInterface $builder, array $options) {
        switch ($options['flow_step']) {
            case 1:
                $builder
                    ->add('scope', 'entity', array(
                        'required' => true,
                        'expanded' => true,
                        'class' => 'AppBundle:Scope',
                    ))
                    ->add('mounting_type', 'entity', array(
                        'required' => true,
                        'expanded' => true,
                        'class' => 'AppBundle:MountingType'
                    ))
                break;
            case 2:
                #...
                break;
            case 3:
                $builder
                    ->add('comment', 'textarea', array(
                    ))
                    ->add('captcha', 'captcha', array(
                    ))
                ;
                break;
        }

I checked the database profiler on each step. Every step will also include the the combined queries of the former steps.
Can we prevent this?

Which version of the bundle are you using?

Never mind, I thought about something different.
There's no way to avoid building the forms of previous steps because they're needed to progressively "fill" the data class, otherwise the data of previous steps would be lost.

For my small form this isn't a performance problem.
Is there a way to lazy load choices in Doctrine?

http://api.symfony.com/2.6/Symfony/Component/Form/Extension/Core/ChoiceList/LazyChoiceList.html
E.g. using Proxies?

I don't see how lazy loading choices could change anything.


Building documentation with docfx

Addresses #104
Install docfx with choco install docfx. Docfx is an open source tool used by Microsoft for generating static docs sites.
Generate the docs with the following command from repository root:
docfx docs\docfx.json

Test the site by running:
docfx docs\docfx.json --serve

Then visit http://localhost:8080
The generated docs go into the docs_site folder. The contents of which can be copied to the repository root in the gh-pages branch. The gh-pages branch is an orphan branch that only has the generated documentation site in it. That will be checked in as a separate commit. It doesn't make sense to review it as a PR. Ideally, the build pipeline would refresh the documentation for us.
To see an example of the documentation (still in progress): https://dmetzgar.github.io/corewf/api/Microsoft.CSharp.Activities.CSharpReference-1.html

Going a different direction with this. We don't have /// comments in the source code. It would be better to document what's different, how to use, etc.


e2e: fix test file names in tests/compute

Signed-off-by: Igor Bezukh<EMAIL_ADDRESS>What this PR does
the suffix of the files was _test which made some
confusion with Ginkgo and Bazel, as a result the compute package wasn't built into tests.test binary.
Before this PR:
tests in tests/compute didn't run as part of tests.test ginkgo binary
After this PR:
tests in tests/compute will be built and run by Ginkgo
Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[ ] Design: A design document was considered and is present (link) or not required
[ ] PR: The PR description is expressive enough and will help future contributors
[ ] Code: Write code that humans can understand and Keep it simple
[ ] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[ ] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[ ] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[ ] Community: Announcement to kubevirt-dev was considered

Release note

NONE

/hold
@dhiller Sure, thanks for looking into this. I will further investigate it

/close in favor of https://github.com/kubevirt/kubevirt/pull/11169

in favor of https://github.com/kubevirt/kubevirt/pull/11169


Error in running align_example.py

Hi,
I am getting the following error while executing the align_example.py
/home/sriram/anaconda3/envs/simalign/lib/python3.7/site-packages/torch/cuda/__init__.py:52: UserWarning: CUDA initialization: Found no NVIDIA driver on your system. Please check that you have an NVIDIA GPU and installed a driver from http://www.nvidia.com/Download/index.aspx (Triggered internally at  /pytorch/c10/cuda/CUDAFunctions.cpp:100.)
  return torch._C._cuda_getDeviceCount() > 0
2020-12-29 12:04:07,522 - simalign.simalign - INFO - Initialized the EmbeddingLoader with model: bert-base-multilingual-cased
Traceback (most recent call last):
  File "align_example.py", line 7, in <module>
    result = model.get_word_aligns(source_sentence, target_sentence)
  File "/home/sriram/anaconda3/envs/simalign/lib/python3.7/site-packages/simalign/simalign.py", line 211, in get_word_aligns
    vectors = self.embed_loader.get_embed_list([src_sent, trg_sent]).cpu().detach().numpy()
  File "/home/sriram/anaconda3/envs/simalign/lib/python3.7/site-packages/simalign/simalign.py", line 66, in get_embed_list
    inputs = self.tokenizer(sent_batch, is_pretokenized=True, padding=True, truncation=True, return_tensors="pt")
  File "/home/sriram/anaconda3/envs/simalign/lib/python3.7/site-packages/transformers/tokenization_utils_base.py", line 2371, in __call__
    **kwargs,
  File "/home/sriram/anaconda3/envs/simalign/lib/python3.7/site-packages/transformers/tokenization_utils_base.py", line 2556, in batch_encode_plus
    **kwargs,
  File "/home/sriram/anaconda3/envs/simalign/lib/python3.7/site-packages/transformers/tokenization_utils.py", line 526, in _batch_encode_plus
    ids, pair_ids = ids_or_pair_ids
ValueError: too many values to unpack (expected 2)

Can you please help to resolve this issue?
Thanks,
Sriram

I could resolve it by downgrading the transformer from 4.1.1 to 3.1.0.
Thanks,
Sriram

Hello Sriram,
Thank you for using our tool.
We are still using Transformers 3.1.0. We will update it to > 4.1 soon.

Hi @masoudjs, Sorry to reopen. I am still getting this error with transformers 4.2.2. Is 4.1 supported already? Do I need to downgrade to 3.1.0?
Thanks

Hi @mzeidhassan, no worries. I think it should be fixed now - I tested it with transformers 4.3.0, but it should work with any recent version. Let me know if you have any issues.

4.3.0

I solve this issure by upgrading transformers to 4.3.0


additionalproperties issue

We might have an issue with associations and additional properties = false. When I created a sample from a ver 1.3 ninjs it still accepted the description_text thing but should really have complained because in 2.x it should be descriptions: [array].
My quick googling gave the answer that it is hard to combine anyOf with additionalProperties=false.

The issue seemed solved in json schema 2019-09

Alternative proposal in earlier schema versions:
{
"anyOf": [
{
"type": "object",
"properties": {
"a": {
"type": "string"
}
}
},
{
"type": "object",
"properties": {
"x": {
"type": "string"
}
}
}
],
"properties": {
"a": true,
"x": true
},
"additionalProperties": false
}

https://stackoverflow.com/questions/73843324/how-to-merge-two-json-schema-without-additional-properties

Another alternative would be to add name to the core schema, but I don't like that either. We have talked about moving to a newer schema version, so this might be the reason to do so.

And now when I test I can't repeat the problem.

Brendan could replicate the bug in unit tests. And when working more with oXygen I can verify that the problem is there. oXygen seem to demand that you have a validated copy before testing. Because if it is marked as wrong it seems to stay that way even if you switch schema to validate against.

Update: after the meeting, @jeremybrooks solved the JSON Schema problem so we can go with solution 1 above!


Fix/single doc collection navigation

Fixes issue where single document collections would not open contextual editing.

@logan-anderson what is the __typename that is not Document & not Folder?

@logan-anderson what is the __typename that is not Document & not Folder?

While looking at it __typename appeared to be the name of the document type in came cases. For example "Post" or "Global".


[Runtime] Extend Metadata::dump for existential type metadata.

Dump whether it's class bounded, the protocols it contains, and the superclass constraint if there is one.

@swift-ci please smoke test and merge

@swift-ci please smoke test os x platform

@swift-ci please smoke test os x platform


Failed to set media type at start: 0x800706bf

Describe the bug
When starting the color camera, Media Foundation returns of 0x800706bf (RPC_S_CALL_FAILED_DNE) when attempting to call SetNativeMediaType()
To Reproduce

Call k4a_device_start_cameras.

Expected behavior
The cameras should start successfully.
Logs
[...] [error] [...] [Color] Failed to set media type at start: 0x800706bf
[...] [error] [...] [K4A] D:\a\1\s\extern\Azure-Kinect-Sensor-SDK\src\color\color.cpp (182): color->m_spCameraReader->Start(width, height, fps, config->color_format, &color_capture_available, color) returned failure in color_start()
[...] [error] [...] [K4A] D:\a\1\s\extern\Azure-Kinect-Sensor-SDK\src\sdk\k4a.c (710): color_start(device->color, config) returned failure in k4a_device_start_cameras()

Desktop (please complete the following information):

OS with Version: Windows
SDK Version:  1.1.0
Firmware version:  Any

This issue was caused by a 3rd party driver. The driver was causing FrameServer to crash when starting up the sensor and resulted in the RPC server being gone.
Use Event Viewer to identify the failing component and uninstall the program or driver.


Composition Renderer does not handle dirty rects correctly

Describe the bug
Somehow after #8105 not all dirty rects are handled correctly, i.e. there are visuals left that should not be there.
To Reproduce
There are several ways to do.
Way 1: Open the control catalog on DataGrid page and select more than one row with [Ctrl] pressed. Notice that the current cell adorner gets not cleared. It will be cleared once you move your mouse over the row. See screenshot 1
Way 2: Open Dev tools and move your mouse fast over the rows. See that the hover brush does not always disappear. See screenshot 2
Expected behavior
Visuals should be updated correctly
Screenshots

Desktop (please complete the following information):

OS: Windows
Version: latest master

Additional context
@robloo  saw similar issues and reported them on telegram channel.
Unfortunately I have no idea where to look. So I think I'm not able to fix it on my own.
One more hint: I only saw the issues related to the DataGrid, but it may be also an issue for other controls.
/cc @kekekeks

Just noticed that the DatePicker has similar issues. I can record a video if that helps further, but tbh I think it's related.

The new ColorPreviewer combined with property editing in DevTools is another good example of this.
https://user-images.githubusercontent.com/17993847/179367080-2e887bf5-0289-40f4-89a8-b6f67149828a.mp4

In ControlCatalog navigate to the ColorPicker page and select the far right previewer (stand-alone one)
Open DevTools with the ColorPreviewer selected
Change the property IsAccentColorsVisible from True to False
Notice that the drop shadow persists while the control otherwise properly updates (shown in above screen recording)
Change the property IsAccentColorsVisible from False to True
The control doesn't update at all

This was all working yesterday before the composition branch was merged in.


error on brew cu

Error: cannot load such file -- cask/all
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in require' /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in require'
/usr/local/Homebrew/Library/Taps/buo/homebrew-cask-upgrade/lib/bcu.rb:4:in <top (required)>' /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in require'
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in require' /usr/local/Homebrew/Library/Taps/buo/homebrew-cask-upgrade/cmd/brew-cu.rb:32:in <top (required)>'
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in require' /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in require'
/usr/local/Homebrew/Library/Homebrew/utils.rb:19:in require?' /usr/local/Homebrew/Library/Homebrew/brew.rb:95:in '
~ ▶ brew cask doctor
==> Homebrew-Cask Version
Homebrew-Cask 1.7.3
Homebrew/homebrew-cask (git revision 02f179; last commit 2018-09-05)
==> macOS
10.13.6
==> SIP
Enabled
==> Java
N/A
==> Homebrew-Cask Install Location

==> Homebrew-Cask Staging Location
/usr/local/Caskroom
==> Homebrew-Cask Taps:
/usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask (4045 casks)
==> Contents of $LOAD_PATH
/Library/Ruby/Gems/2.3.0/gems/did_you_mean-1.0.0/lib
/Library/Ruby/Site/2.3.0
/Library/Ruby/Site/2.3.0/x86_64-darwin17
/Library/Ruby/Site/2.3.0/universal-darwin17
/Library/Ruby/Site
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/vendor_ruby/2.3.0
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/vendor_ruby/2.3.0/x86_64-darwin17
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/vendor_ruby/2.3.0/universal-darwin17
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/vendor_ruby
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/x86_64-darwin17
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/universal-darwin17
/usr/local/Homebrew/Library/Homebrew/cask/lib
/usr/local/Homebrew/Library/Homebrew
==> Environment Variables
LC_ALL="en_US.UTF-8"
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/Homebrew/Library/Homebrew/shims/scm"
SHELL="/bin/bash"

Hmm, it looks like this is caused by #110 ?

Do i need to do anything? to fix?

@hmstanley: do this
$ cd "$(brew --repo)
$ git fetch
$ git reset --hard origin/master
$ brew update

That worked.  Please close.

On Sep 5, 2018, at 9:26 AM, y0y0z<EMAIL_ADDRESS>wrote:
@hmstanley https://github.com/hmstanley: do this
$ cd "$(brew --repo)
$ git fetch
$ git reset --hard origin/master
$ brew update
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/buo/homebrew-cask-upgrade/issues/112#issuecomment-418793946, or mute the thread https://github.com/notifications/unsubscribe-auth/AA9MaBHTZq5ma5pUW1SZQupsKpT7DZ45ks5uX_sjgaJpZM4WbN7J.

@hmstanley Why close this issue? You are not the only one affected, and there needs to be a better fix than nuking the git repo.

Oh, fair enough.. sorry.. was just pointing out that it fixed it for me.

@hmstanley That's cool.
Also, the first line in the proposed workaround is incorrect. You need to omit the double quotes (").
The correct command is cd $(brew --repo)

yea. Fixed that myself.. but yes.

On Sep 5, 2018, at 11:10 AM, Mark Richman<EMAIL_ADDRESS>wrote:
@hmstanley https://github.com/hmstanley That's cool.
Also, the first line in the proposed workaround is incorrect. You need to omit the double quotes (").
The correct command is cd $(brew --repo)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/buo/homebrew-cask-upgrade/issues/112#issuecomment-418827496, or mute the thread https://github.com/notifications/unsubscribe-auth/AA9MaPGBFXLKz568DgT0xIZOjesFjsUMks5uYBODgaJpZM4WbN7J.

Just came here because of this. Thanks for the fix!

Thank you for the quick fix!

Thx, fixed!

Thanks!

Thanks!

I followed the workaround, but now the error is:
ijhack:Homebrew jhack$ brew cu -ay
Error: uninitialized constant Hbc
/usr/local/Homebrew/Library/Taps/buo/homebrew-cask-upgrade/lib/extend/hbc.rb:3:in `<top (required)>'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.7/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.7/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/usr/local/Homebrew/Library/Taps/buo/homebrew-cask-upgrade/lib/bcu.rb:6:in `<top (required)>'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.7/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.7/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/usr/local/Homebrew/Library/Taps/buo/homebrew-cask-upgrade/cmd/brew-cu.rb:32:in `<top (required)>'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.7/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.7/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/usr/local/Homebrew/Library/Homebrew/utils.rb:19:in `require?'
/usr/local/Homebrew/Library/Homebrew/brew.rb:95:in `<main>'

Same here. Workaround leads into: Error: uninitialized constant Hbc

Yeah, there was another rename happening, there is already a fix for that waiting in PR https://github.com/buo/homebrew-cask-upgrade/pull/114
Just waiting for @buo to merge that.
Meanwhile feel free to use my branch from that PR

@ondrejfuhrer

Meanwhile feel free to use my branch from that PR

How?

@Fischmuetze If you don't know, would be better if you wait until the master branch gets updated. It involves some knowledge about git and be able to fix potential issues. Therefore I would strongly recommend right now for you to wait 🙂

Thanks a lot ... hopefully the fix it will be available soon

@ondrejfuhrer: any idea what keeps it from being merged if it fixes the issue?

@y0y0z I'm guessing that @buo simply hasn't had the time to review it yet; he approved another PR that @ondrejfuhrer created for this general issue.

@buo: we all love you, could you please help us out with the merge? :) :shipit:


Add container

Hi,
I generated a Docker container from the environment file so that we can use a container instead of the conda.

@idfarbanecha: Should now be OK for merging


Integration is using deprecated DEVICE_CLASS_* constants

Version of the custom_component

All
Configuration
n/a

Describe the bug
This custom integration uses deprecated DEVICE_CLASS_* constants in its codebase.
The DEVICE_CLASS_* constants have been deprecated and replaced in Home Assistant Core 2021.12 (over a year ago). I would highly suggest updating/migrating this integration to the new enums.
For example, for the device classes supported by the sensor platform, there is now a SensorDeviceClass enum. So if a sensor previously used the DEVICE_CLASS_ENERGY constant, it should now use SensorDeviceClass.ENERGY. Other platforms (like binary_sensor, and number) provide similar enumerations for their supported device classes.
The migration thus only consists of replacing constants with an enumeration member and is, therefore, very low impact and should be fairly straightforward.
If I can help resolve any questions regarding this change or migration, feel free to ask or respond to this issue. I'm happy to help!
Kindest regards,
../Frenck
Debug log

n/a

Thanks for the details, and sorry for the delay in replying.
It is fixed and it will be in the next version.
Thanks again!

Thanks for addressing this @pcourbin 👍
../Frenck


range(at:) has been renamed to rangeAt(_:)

SwiftDate version:  4.5.1
Xcode version: Version 9.2 (9C40b)
I got the error:
 'range(at:)' has been renamed to 'rangeAt(_:)'
 'range(at:)' was introduced in Swift 4

Can anyone please provide a bit more clarity to this issue?
My project is using swift 4 and I'm still seeing this when I update to the latest SwiftDate.

6+ months and this still hasn't been fixed, @malcommac?


Small fix on Redis section on rails.md

Actually Redis needs to specify the url: parameter when using the URL, otherwise
needs to specify host:, port: so I kept the original example using the URL, but
now with the :url option

I'd leave the sidekiq section our of this documentation since it is too specific. Other change seems good.
Thanks

hey @rafaelfranca thank you for the feedback... removed the last commit, so I think now its ok

:heart: :green_heart: :blue_heart: :yellow_heart: :purple_heart:

thanks :heart: :green_heart: :blue_heart: :yellow_heart: :purple_heart:


SoftwareSerial library creates DCF77 error

When trying to run the SoftwareSerial examples I get the following error:
Error: Could not find Timezone dependency for DCF77 library

platformio lib install DCF77

Library Storage: ****
Looking for DCF77 library in registry
Found: http://platformio.org/lib/show/169/DCF77
LibraryManager: Installing id=169
Downloading  [####################################]  100%
Unpacking  [####################################]  100%
DCF77 @ 1688eaab55 has been successfully installed!
Installing dependencies
Looking for Time library in registry
Found: http://platformio.org/lib/show/44/Time
LibraryManager: Installing id=44
Downloading  [####################################]  100%
Unpacking  [####################################]  100%
Time @ 18ce15b202 has been successfully installed!
Looking for Timezone library in registry
Found: http://platformio.org/lib/show/76/Timezone
LibraryManager: Installing id=76
Downloading  [####################################]  100%
Unpacking  [####################################]  100%
Timezone @ 510ae2f6b6 has been successfully installed!

Please try again and reopen this issue if you still have problems


Aligned Dropdowns

The dropdowns are aligned for large screens. Radical Collaboration redirects to /adding-projects-to-the-index. After this PR is merged, I will create a new issue so that menu headers are bold if the user is on any of the parents' links.

@maxskewes you might need to update header.spec.js to account for your updates to the header dropdown link lists.  You mentioned that the dropdown parents may not be links anymore right?

@bruceplai I don't know what header.spec.js is - it doesn't show up when I search for it but if it's affecting the header please let me know where I can find it. This PR was merely meant to fix the aligning of the dropdowns from the large display; it's the parents from the small display that are not links, I don't think they ever were. I'm waiting for this to get merged so I can create an issue for making the parent pages bold through Router which may make me configure things a little differently and may have them acting as links though it didn't seem like that was necessary when we discussed it last night.

@maxskewes spec files are unit test files that we can run cypress on manually (npx cypress run) or it's hooked into the repo on github and run automatically every time we create/update a PR (See the step titled "Build and Test Pull Requests & Main Syncs / build (pull_request)" )
If something failed during the unit tests it can mean that we actually created a bug or we changed a page layout so much that the unit test can't find elements that we changed anymore.  I'm betting that it's the second case for your header updates.  You can find header.spec.js in   cypress/integration/components

@maxskewes You might just need to change a few lines in header.spec.js to find the elements that you changed.


Human Reference Genome questions

Hello, thank you very much for open-sourcing your work. I have a couple of questions about the Human Genome Reference dataset.
[Q1] In your instructions for downloading Human Reference Genome you mention:

First step is download the Human Reference Genome data. It's comprised of 2 files, 1 with all the sequences (the .fasta file), and with the intervals we use (.bed file).
However, you'll need to have a GCP account to download the exact files we used (from the Enformer), and it cost a little to download. At some point we'll try to upload somewhere to share that data.

As far as I know Enformer was using a mix of Basenji dataset and Human Reference Genome. Specifically in their paper they say:

We modified the Basenji2 dataset by extending the input sequence to 196,608bp from the original 131,072bp using the hg38 reference genome.

In the filenames for Human Reference Genome you also have reference to Basenji, i.e.

Download fasta (.fa format) file (of the entire human genome) into hyena-dna/data/hg38. ~24 chromosomes in the whole genome (merged into 1 file), each chromosome is a continuous sequence, basically
gsutil -u hai-gcp-hippo cp gs://basenji_barnyard/hg38.ml.fa.gz ./ && gunzip hg38.ml.fa.gz

Hyena-DNA paper does not contain any reference to Basenji. So I wonder how do these two datasets relate to each other? Do you train on mix of them as Enformer or only on Human Reference Genome? Also in the Appendix you mention:

For pretraining, we use a single human reference genome (Genome Reference Consortium, 2013), and leverage the training and validation intervals (start and end) from (Avsec et al., 2021).

Does it imply that you use completely the same data as Enformer and the same train/val splits?
[Q2] Since accessing the data on GCP incurs a cost, you mentioned plans to make the data more accessible. Do you have a timeline for this? Maybe there is script to convert the original data into Enformer format?

We follow the procedure that Enformer uses in retrieving train/test intervals from Basenji on the reference genome.  Basenji hosts the data (the intervals), yes.  The HG38 file itself is public, and can be retrieved from many places.
Sorry, we don't host the data, but it must cost just cents, or a couple of dollars with a GCP account to download.  This is just something we chose to do, but there's nothing wrong with just sampling randomly from the HG38 fasta file, you don't need Enformer/Basenji intervals.


Don't Merge! PR real time test for webhook case

Docs Build status updates of commit cbf60dc:
:clock10: Pending: waiting for processors (15 builds ahead of you)
:warning: Docs Build is busy, currently there are 15 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit cbf60dc:
:clock10: Full build: the average full build time is 6 min(s) 2 sec(s), this is based on the last 540 build(s) for this repository.

Docs Build status updates of commit cbf60dc:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details
Dependent Files

docs-ref-conceptual/testing.md
:white_check_mark:Succeeded
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Possible with JSON items?

I'm working on an app that has pdf urls in a json response, but the library doesn't seem to work with those.  Do you possibly have a potential workaround and use for this?

Can you put your JSON here and how you are trying to use URLs please let me know.

Apologies, I got it working correctly! I guess I had something wrong


ltrace: fix warnings and bugs using patches from debian

For details on the patches applied, see:
https://sources.debian.org/patches/ltrace/0.7.3-6/
Disabling '-Werror' may be a problem in the future again,
but for now keep things simple now that they're fixed.

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

Failure on aarch64-linux (full log)
Attempted: ltrace
Partial log (click to expand)
/nix/store/a4qslf0yfs44mhnbagarn232sjnckhy0-bash-4.4-p19/bin/bash: line 17: cd: aarch64: No such file or directory
make[3]: *** [Makefile:382: all-recursive] Error 1
make[3]: Leaving directory '/build/ltrace-0.7.3/sysdeps/linux-gnu'
make[2]: *** [Makefile:299: all-recursive] Error 1
make[2]: Leaving directory '/build/ltrace-0.7.3/sysdeps'
make[1]: *** [Makefile:741: all-recursive] Error 1
make[1]: Leaving directory '/build/ltrace-0.7.3'
make: *** [Makefile:447: all] Error 2
builder for '/nix/store/wrq6365r2ql9i29gyhzh18w3vrxda6cm-ltrace-0.7.3.drv' failed with exit code 2
error: build of '/nix/store/wrq6365r2ql9i29gyhzh18w3vrxda6cm-ltrace-0.7.3.drv' failed

For the curious, looks like aarch64 build already failed.
As future work someone might want to look through ubuntu's patches[1] which apparently fix on aarch64 and some other things.
[1] https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/ltrace/trusty/files/head:/debian/patches/


Make the use of servlet optional

Making the servlet optional will let those users who do not want to use servlet reuse the common code instead; I'd still like to keep a servlet there spo that something is available OOB, should be ok given that the servlet api is provided

Servlet technically isn't provided though. There's no spec dependency on Servlet from JAX-RS, so it is possible that a JAX-RS container isn't built on Servlets

HttpServletRequest/Response as well as ServletContext/Config are supported injectable contexts in JAX-RS; though may be I'm missing the point :-). I can remove this servlet altogether now or later, I just thought about starting to separate the servlet from the actual Health collection code

One thing which is I'm finding useful in keeping the servlet inside small rye health is that without it the implementation will be incomplete, even though I did push most of Health accumulation code into a standalone bean, setting 503 status on the http response in case of DOWN is still needed. So at least in those cases where the 3rd party containers can rely on Servlet it just works OOB.
Only in cases where for example we have Undertow handlers or JAX-RS one would still need to set 503 manually, while reusing SmallRyeHealthReporter bean, the fact the small rye health code ships SmallRyeHealthReporter won't affect for example Undertow integration where no Servlet API is supported because this API is optional at the pom level

For this situation I almost think the servlet should be added to the TCK to facilitate passing it, and that's it.
Currently the servlet spec is "provided" which means it's lack of presence in a runtime situation would cause a failure to start because of a ClassNotFoundException.
It's for that reason I think the use of servlet needs to be removed. At least for now. In the future we could look to adding some kind of SPI maybe for offering that behavior that can then be implemented by a runtime however they want

It just works with the servlet with Thorntail v2 and v4 so I'm not sure when it would not work, and when the users would want to depend on servlet and it won't work the users will just add the servlet api to their poms. Or are you saying that even if the users do not use this Servlet some containers will still try to load it ?
I'm not sure about SPIs either. If the users do not like the way small rye builds the health response then may be they will be better of just building their own library or do a custom health handler given that the only real work the small rye does is it builds the standard MP Health response ?
The only thing which varies now, with moving most of the code to a non-servlet aware bean is the way 503 is set as it is indeed specific to servlets, JAX-RS or Undertow.
I guess I will go ahead then and remove the servlet, but that would mean the implementation will immediately become incomplete. Should we still keep the servlet, at least for now :-), and remove it immediately when someone sees a problem ? Or you'd really prefer to get it removed now ?
thanks

I think the WildFly folks want to use direct Undertow handlers, below the Servlet level.

I think it's fine to be "incomplete", as I don't expect most SmallRye impls to work without some level of integration.
In some cases that means adding the necessary integration into testing the TCK to make sure it passes.
And then likely documenting what integration is required to make it work

Hi Bob, yes, I believe this is what I did, see
https://github.com/sberyozkin/smallrye-health/blob/1b83863dfdc7045ce408e02295f16673b6b2436c/implementation/src/main/java/io/smallrye/health/SmallRyeHealthServlet.java
so the servlet is there but my understanding it won't interfere with Undertow handlers where to use only the bean the way this servlet does.
Hi Ken, ok, I'll just move this servlet to the TCK
thanks

I've removed the servlet

@sberyozkin thanks for looking at this!


Title: Enhance Body Parts Categories UI with GIFs

#40
Currently, the UI for the body parts categories displays static images, which could be further improved to create a more engaging user experience. I suggest replacing these static images with GIFs that demonstrate exercises for each body part. Not only will this make the interface more visually appealing, but it will also provide users with dynamic content that showcases exercises in action, ultimately enhancing their overall experience.
Proposed Changes:
GIF Integration: Replace static images with relevant GIFs for each body part category. I have GIFs available in the .json file that can be utilized for this purpose.
User Experience: This change will not only attract users' attention but will also help them visualize the exercises better, potentially increasing user engagement and satisfaction.
I want to enhance this UI part.

I want to contribute this issue under hactoberfest and GSOC-EXT
I am willing to work on this.Kindly assign it to me.

@rajlakshmi18704 go ahead👍
Your level may change based on the quality of your work when merging pull requests.

#40 Currently, the UI for the body parts categories displays static images, which could be further improved to create a more engaging user experience. I suggest replacing these static images with GIFs that demonstrate exercises for each body part. Not only will this make the interface more visually appealing, but it will also provide users with dynamic content that showcases exercises in action, ultimately enhancing their overall experience.
Proposed Changes: GIF Integration: Replace static images with relevant GIFs for each body part category. I have GIFs available in the .json file that can be utilized for this purpose.
User Experience: This change will not only attract users' attention but will also help them visualize the exercises better, potentially increasing user engagement and satisfaction.
I want to enhance this UI part.
I want to contribute this issue under hactoberfest and GSOC-EXT
I am willing to work on this.Kindly assign it to me.

hello @rajlakshmi18704 whatever gif you are willing to add, keep updating the json files also,


Bbox type incompatible with @types/geojson

Hi, thanks for making this!
I'm having trouble getting a polygon parsed with zod-geojson to be accepted as a GeoJSON.Polygon as defined in the @types/geojson package. It looks like the problem might be that @types/geojson defines a bbox as a tuple of 4 or 6 numbers:
export type BBox = [number, number, number, number] | [number, number, number, number, number, number];

while this lib defines it as an array of 4 or more elements:
export type GeoJSONBbox = [number, number, number, number, ...number[]];

Is there any reason for that flexibility as opposed to expecting 4 or 6 elements?

My implementation follows the RFC:
https://datatracker.ietf.org/doc/html/rfc7946#section-5

A GeoJSON object MAY have a member named "bbox" to include
information on the coordinate range for its Geometries, Features, or
FeatureCollections.  The value of the bbox member MUST be an array of
length 2*n where n is the number of dimensions represented in the
contained geometries, with all axes of the most southwesterly point
followed by all axes of the more northeasterly point.  The axes order
of a bbox follows the axes order of geometries.

So a bbox can have: 4, 6, 8, 10, ... elements depending on the dimension of the geojson. So it does seem like @types/geojsonis incorrect in this regard. If you need a specific dimension then you can try using GeoJSON2DPolygonSchema or GeoJSON3DPolygonSchema 🙂

And the RFC gives examples of 2- and 3-dimensional data. In what science-fiction universe does geospatial data include a fourth dimension?
In any event, I get the same error using GeoJSON2DPolygonSchema; it doesn't seem to refine the output bbox type for some reason.

Hi @graue, you're right it doesn't make much sense, but I tried to implement this to be as compatible with other implementations as possible. The RFC states the following:

Implementations SHOULD NOT extend positions beyond three elements
because the semantics of extra elements are unspecified and
ambiguous.

Since it phrases this as "should not" and not "must not" I did not want to make this library unusable by anyone who has defined some fourth dimension for their internal geojson structure. E.g:

Historically, some implementations have used a fourth
element to carry a linear referencing measure (sometimes denoted as
"M") or a numerical timestamp, but in most situations a parser will
not be able to properly interpret these values.  The interpretation
and meaning of additional elements is beyond the scope of this
specification, and additional elements MAY be ignored by parsers.

I guess since it states that I may ignore additional elements. I may simplify the typings to not force myself to have to support this. I will let you know when it's fixed. Thanks for bringing this to my attention!

That makes sense! Thanks. It would be helpful for me to have the parsed types compatible with @types/geojson.

I just released version 0.0.3, there are still some issues with the @types/geojson package which I cannot solve with zod-geojson without compromising the correctness. You can find more details here: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/71066

0.0.3 does solve my issue! Thank you :pray: Appreciate your careful attention to correctness.


Add Linter

Examples that should create Warnings or Errors:

Anything that will not be accepted by a prometheus server
rate(sum(...))
(if possible in a sane way) http_requests_total{code="5.."}

quasi duplicate of #48


RKE2 Node's external IP is set as the internal IP

Rancher Server Setup

Rancher version: 2.6head commit id: 11a7451
Installation option (Docker install/Helm Chart): docker install

Information about the Cluster

Kubernetes version: v1.21.9+rke2r1
Cluster Type (Local/Downstream): Linode node driver cluster - 1 etcd, 1 cp and 3 worker nodes. Container network - Cilium

User Information

What is the role of the user logged in? (Admin/Cluster Owner/Cluster Member/Project Owner/Project Member/Custom) Standard user

Describe the bug
Node's external IP is set as the internal IP
To Reproduce

Deploy an RKE2 cluster Linode
Wait for the cluster to come up Active.
Navigate to Cluster Explorer --> Nodes --> External and Internal IP
The nodes have 1 IP address and the Internal IP addresses are set. The external IP addresses = None
Yaml of the node also has the internal IP set

status:
  addresses:
  - address: Ip
    type: InternalIP
  - address: sowmya-cilium-pool1-83e7c181-xwv4t
    type: Hostname

Expected result:
The Ip is the external IP.

@sowmyav27 , is this affecting the functioning of the cluster or more of a display issue?

@snasovich What can I check to make sure the cluster is working fine? All network checks ? I am not sure how ext vs internal IPs are used in the cluster

@sowmyav27 , I would say "it's fine" as long as pods get properly scheduled and they are able to communicate with the "outside" world (e.g. if cattle-cluster-agent pods are scheduled on downstream cluster and communicate back to local Rancher cluster).

RKE2 Linode cluster is functional on latest 2.6-head. Moving this issue to 2.6.5

@sowmyav27 Would it be possible to create an environment for devs to poke around in as we do not have Linode access?

Ticket #36507 - Test Results
With Docker on single-node instance:
Reproduced on rancher v2.6-11a7451ffee557897197fc624af03ac6fd34a9f0-head:

Fresh install of rancher v2.6-head
As admin, create a standard user
Logout admin, login standard user
Provision an RKE2 Linode Node driver cluster with k8s v1.21.11+rke2r1 and Cilium as the container network
Once cluster is provisioned and Active, navigate to Cluster Explorer => Nodes => External/Internal IP
Reproduced - External IP address is not set; Internal IP address is set

Screenshots:
Cluster Explorer => Nodes

YAML file for a single node in cluster

Verification - Awaiting PR merge to resume verification testing


How do you do secret key rotation?

How do you do secret key rotation?

The library doesn’t directly support key rotation. An option would be
needed to accept—and attempt—multiple keys.
On Mon, Sep 18, 2017 at 1:14 AM Edgar<EMAIL_ADDRESS>wrote:

How do you do secret key rotation?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/goji/csrf/issues/11, or mute the thread
https://github.com/notifications/unsubscribe-auth/AABIcApxnW6av0nj9is1GIV7AVhfJZx4ks5sjiZ-gaJpZM4Pajxh
.

I am working on that now. I hope i have something by this weekend. It kinda sucks not to have this and i need it.The gogi one seems to be a fork of the gorilla one. I will try to update both. In any case i hope to post back within a week.