Add Jetson support

Added Jetson (Tegra) support to gpu.go. Added a module to hook into libcudart.so to query device properties on Tegra devices. Updated llama.cpp generation to support Tegra environment, if detected. Fixed needing to manually set "num_gpu=999" for Tegra devices.
Device used to test:
Jetson Orin Nano 8Gb
Jetpack 5.1.2, L4T 35.4.1
CUDA 11-8
CUDA Capability Supported 8.7
Go version 1.26.1
Cmake 3.28.1
nvcc 11.8.89

Resolves #1979

@dhiltgen I don't know if you're the right contact for this, but I'm having issues getting the correct memory amounts for GetGPUInfo() on Jetsons. Since they are iGPU, the memory is shared with the system (8Gb in my case). The free memory reported by cudaGetMem and the memory reported by Sysinfo aren't necessarily even the correct free memory as the Jetsons use a portion of RAM as flexible cache. There is a semi-accurate way to get "available memory" but the only decent way I've seen to get that information is to run free -m or to read /proc/meminfo as the kernel has some fancy maths it does to give a semi-accurate reprensentation of available information.

The 'buff/cache' field and 'available' field aren't reported by sysinfo (or cudaGetMem), and even the "/usr/bin/free" binary does an fopen() call on /proc/meminfo. For now I'm just setting it to report the greater of cudaGetMem or sysinfo free memory as the current "free memory".
Do you have any ideas for the best way to report this information to the application? I tried putting in some overhead but the Jetson kept falling back to CPU due to memory even though there was extra memory available in the cache.

Changed this to a draft while working memory issues.

@dhiltgen I think this version meets the criteria for step #1, what do you think?

I have tested this PR on the following device:
Device used to test:
Jetson AGX Orin Developer Kit 64GB
Jetpack 6.0DP, L4T 36.2.0
CUDA 12.2.140
CUDA Capability Supported 8.7
Go version 1.21.6
Cmake 3.22.1
nvcc 12.2.140
CUDA libraries are detected and used, generation uses 100% GPU. After installation in /usr/loca/bin/ollama there were permission issues when starting it as a service under the ollama user. I don't think that has anything to do with the code on this branch though. Still looking into it in issue #1979 .

I propose a change to the file scripts/install.sh to make sure the ollama user is also added to the video group. On my Jetson, the system service needed this to be able to use the CUDA cores.
On line 87, where the ollama user is added to the render group, I propose we add these lines:
    if getent group video >/dev/null 2>&1; then
        status "Adding ollama user to vide group..."
        $SUDO usermod -a -G video ollama
    fi

I propose a change to the file scripts/install.sh to make sure the ollama user is also added to the video group. On my Jetson, the system service needed this to be able to use the CUDA cores.
On line 87, where the ollama user is added to the render group, I propose we add these lines:
    if getent group video >/dev/null 2>&1; then
        status "Adding ollama user to video group..."
        $SUDO usermod -a -G video ollama
    fi

I just checked my own jetson deployment and the service for it, and I ran into the same issue with my Jetson. For some reason, it has both a render and a video group, and the service didn't work until the ollama user was added to the video group. I'll add logic for it in the script in my PR as part of the Jetson compatibility.

I'm rewriting the NVIDIA-Jetson tutorial to match the situation after your PR is applied. I'll add it as a Gist here to see if we can also add that to the PR.

I'm rewriting the NVIDIA-Jetson tutorial to match the situation after your PR is applied. I'll add it as a Gist here to see if we can also add that to the PR.

I've automated most of the things in the build process for getting this to work on Jetson to where if you have your lib paths properly updated you should be able to just pull it, go generate ./... && go build . and be ready to go. I'm waiting for feedback from @dhiltgen before inquiring about whether their backend build process supports the Jetson-specific changes or if there needs to be a Jetson-specific binary on top of MacOS/Windows/WSL/Linux_x64/Linux_aarch64. The main driver for this is the standard CUDA build adds AVX/AVX2 support, but AVX/AVX2 support breaks ARM compatibility. At the same time, do we really want to add the additional overhead of including a "CUDA with AVX/AVX2" and a "CUDA without AVX/AVX2" by default?

@remy415 thanks!  I'll try to take a look within the next few days.  (I've been a bit distracted with the imminent Windows release)

@remy415 thanks! I'll try to take a look within the next few days. (I've been a bit distracted with the imminent Windows release)

Oh I completely understand, no rush from my side. Thank you for your help and support!

@remy415 : Here's a suggestion to replace the docs/tutorials/nvidia-jetson.md file: https://github.com/jhkuperus/ollama/blob/edefca7ef3b1b13a8a60744b4511c48dd6e1b396/docs/tutorials/nvidia-jetson.md

@remy415 : Here's a suggestion to replace the docs/tutorials/nvidia-jetson.md file: https://github.com/jhkuperus/ollama/blob/edefca7ef3b1b13a8a60744b4511c48dd6e1b396/docs/tutorials/nvidia-jetson.md

Thank you for writing that up. I would advise on a couple things:

this PR is the first of 3 steps to begin loading the prepackaged shared libraries instead of querying the host. Once that is accomplished, the tutorial will be outdated.
on Jetson devices, CUDA toolkit is preinstalled. Also, the method for updating requires adding the Jetson specific nvidia repos. This will likely change again once JP6 is officially released as well.

@dhiltgen My apologies for the giant commit spams on this, I'm trying to keep my branch updated with ollama main while integrating the libcudart changes.
I think this commit may fulfill the objective of adding libcudart support. Jetson users will possibly need to include environment variables on build, but given the nature of Jetson devices as development boards, I believe they should be equipped to do so anyway. I also included logic to disable AVX extensions in the CUDA build within gen_linux.sh if the architecture is arm64 as those chips don't support it in general.

@dhiltgen I think it's in a pretty good place for step 1 of getting the libcudart support integrated. The only thing is it needs to be tested on machines with multiple GPUs to see if the code for the meminfo lookup works correctly on those systems (and I'd need to swap the priority for nvml/cudart as I put it back to loading nvml first).

I pulled the newest version of this PR, ran go clean, go generate ./.. and go build again, but the new binary crashes when loading any model. Here's the first bit of logging where it segfaults:
Mar 06 09:32:13 yoinkee-1 ollama[205621]: time=2024-03-06T09:32:13.254+01:00 level=INFO source=cpu_common.go:18 msg="CPU does not have vector extensions"
Mar 06 09:32:13 yoinkee-1 ollama[205621]: time=2024-03-06T09:32:13.255+01:00 level=INFO source=gpu.go:200 msg="[libcudart.so] CUDART CUDA Compute Capability detected: 8.7"
Mar 06 09:32:13 yoinkee-1 ollama[205621]: time=2024-03-06T09:32:13.255+01:00 level=INFO source=cpu_common.go:18 msg="CPU does not have vector extensions"
Mar 06 09:32:13 yoinkee-1 ollama[205621]: time=2024-03-06T09:32:13.255+01:00 level=INFO source=gpu.go:200 msg="[libcudart.so] CUDART CUDA Compute Capability detected: 8.7"
Mar 06 09:32:13 yoinkee-1 ollama[205621]: time=2024-03-06T09:32:13.255+01:00 level=INFO source=cpu_common.go:18 msg="CPU does not have vector extensions"
Mar 06 09:32:13 yoinkee-1 ollama[205621]: time=2024-03-06T09:32:13.311+01:00 level=INFO source=dyn_ext_server.go:90 msg="Loading Dynamic llm server: /tmp/ollama2209804735/cuda_v12/libext_server.so"
Mar 06 09:32:13 yoinkee-1 ollama[205621]: time=2024-03-06T09:32:13.311+01:00 level=INFO source=dyn_ext_server.go:150 msg="Initializing llama server"
Mar 06 09:32:13 yoinkee-1 ollama[205621]: SIGSEGV: segmentation violation
Mar 06 09:32:13 yoinkee-1 ollama[205621]: PC=0xfffefc285928 m=16 sigcode=1
Mar 06 09:32:13 yoinkee-1 ollama[205621]: signal arrived during cgo execution
Mar 06 09:32:13 yoinkee-1 ollama[205621]: goroutine 38 [syscall]:
Mar 06 09:32:13 yoinkee-1 ollama[205621]: runtime.cgocall(0x944740, 0x40004ce698)
Mar 06 09:32:13 yoinkee-1 ollama[205621]:         /usr/local/go/src/runtime/cgocall.go:157 +0x44 fp=0x40004ce660 sp=0x40004ce620 pc=0x407e94
Mar 06 09:32:13 yoinkee-1 ollama[205621]: github.com/jmorganca/ollama/llm._Cfunc_dyn_llama_server_init({0xfffed4003f50, 0xfffefc285550, 0xfffefc277b40, 0xfffefc279100, 0xfffefc294204, 0xfffefc282ba4, 0xfffefc2>
Mar 06 09:32:13 yoinkee-1 ollama[205621]:         _cgo_gotypes.go:286 +0x30 fp=0x40004ce690 sp=0x40004ce660 pc=0x775810
Mar 06 09:32:13 yoinkee-1 ollama[205621]: github.com/jmorganca/ollama/llm.newDynExtServer.func7(0xa77804?, 0xc?)
Mar 06 09:32:13 yoinkee-1 ollama[205621]:         /mnt/data/forked_ollama/ollama/llm/dyn_ext_server.go:153 +0xe0 fp=0x40004ce780 sp=0x40004ce690 pc=0x776a60
Mar 06 09:32:13 yoinkee-1 ollama[205621]: github.com/jmorganca/ollama/llm.newDynExtServer({0x40004a8db0, 0x2f}, {0x400059f3b0, 0x65}, {0x0, 0x0, _}, {_, _, _}, ...)
Mar 06 09:32:13 yoinkee-1 ollama[205621]:         /mnt/data/forked_ollama/ollama/llm/dyn_ext_server.go:153 +0x904 fp=0x40004cea20 sp=0x40004ce780 pc=0x776774
Mar 06 09:32:13 yoinkee-1 ollama[205621]: github.com/jmorganca/ollama/llm.newLlmServer({{0xf5796b000, 0xcdbc03000, 0x1}, {_, _}, {_, _}}, {_, _}, {_, ...}, ...)
Mar 06 09:32:13 yoinkee-1 ollama[205621]:         /mnt/data/forked_ollama/ollama/llm/llm.go:158 +0x308 fp=0x40004cebe0 sp=0x40004cea20 pc=0x7737e8
Mar 06 09:32:13 yoinkee-1 ollama[205621]: github.com/jmorganca/ollama/llm.New({0x4000304900, 0x15}, {0x400059f3b0, 0x65}, {0x0, 0x0, _}, {_, _, _}, ...)
Mar 06 09:32:13 yoinkee-1 ollama[205621]:         /mnt/data/forked_ollama/ollama/llm/llm.go:123 +0x4fc fp=0x40004cee60 sp=0x40004cebe0 pc=0x77332c
Mar 06 09:32:13 yoinkee-1 ollama[205621]: github.com/jmorganca/ollama/server.load(0x4000179680?, 0x4000179680, {{0x0, 0x800, 0x200, 0x1, 0xffffffffffffffff, 0x0, 0x0, 0x1, ...}, ...}, ...)
Mar 06 09:32:13 yoinkee-1 ollama[205621]:         /mnt/data/forked_ollama/ollama/server/routes.go:85 +0x308 fp=0x40004cefe0 sp=0x40004cee60 pc=0x922f28
Mar 06 09:32:13 yoinkee-1 ollama[205621]: github.com/jmorganca/ollama/server.ChatHandler(0x400058c400)
Mar 06 09:32:13 yoinkee-1 ollama[205621]:         /mnt/data/forked_ollama/ollama/server/routes.go:1175 +0x8fc fp=0x40004cf720 sp=0x40004cefe0 pc=0x92cbdc
Mar 06 09:32:13 yoinkee-1 ollama[205621]: github.com/gin-gonic/gin.(*Context).Next(...)
Mar 06 09:32:13 yoinkee-1 ollama[205621]:         /root/go/pkg/mod/github.com/gin-gonic/gin@v1.9.1/context.go:174
Mar 06 09:32:13 yoinkee-1 ollama[205621]: github.com/jmorganca/ollama/server.(*Server).GenerateRoutes.func1(0x400058c400)
Mar 06 09:32:13 yoinkee-1 ollama[205621]:         /mnt/data/forked_ollama/ollama/server/routes.go:945 +0x78 fp=0x40004cf760 sp=0x40004cf720 pc=0x92b638
Mar 06 09:32:13 yoinkee-1 ollama[205621]: github.com/gin-gonic/gin.(*Context).Next(...)
Mar 06 09:32:13 yoinkee-1 ollama[205621]:         /root/go/pkg/mod/github.com/gin-gonic/gin@v1.9.1/context.go:174

Not sure what the problem is though.

@jhkuperus Which Jetson device do you have and which Jetpack version you are running? I haven’t tested it with JP6 yet. If you’re not running JP6, you should clean your installation as JP5 and below are not compatible with CUDA 12. Ensure you aren’t installing any new video drivers or any new CUDA toolkit software, other than the 11.8 compatibility as referenced on the Tegra support pages (it should work without this though).
In the mean time I’ll run some tests and see if I messed up this last merge.

@jhkuperus I executed a fresh build on my Jetson Orin Nano running JP5 and didn't run into the same segfault issue you had. I would guess your issue is either something present in JP6 that I haven't tested yet, or something like the JP5 + CUDA12 issue I referenced earlier.

Model: NVIDIA Jetson AGX Orin Developer Kit - Jetpack 6.0 DP [L4T 36.2.0]

Module: NVIDIA Jetson AGX Orin (64GB ram)
Libraries:
CUDA: 12.2.140
cuDNN: <IP_ADDRESS>
TensorRT: <IP_ADDRESS>
VPI: 3.0.10
Vulkan: 1.3.204
OpenCV: 4.8.0 - with CUDA: NO

I tested an earlier build from this PR a week or two ago. That one works just fine. Tell me if running it with some sort of verbose-flags or debugging will help you find out what the problem is. I'll gladly help.

I removed the entire repo, checked it out anew and ran the build again. It's working and I also know where my snag was. I ran go generate ./.. instead of go generate ./.... I now have a version that is also capable of running Gemma. Forget my segfault-notice earlier, the branch is still working fine under JP6 with Cuda12.

@dhiltgen I think I may have figured out the issue with having to set specific architectures on Jetson devices.
It may be related to an upstream llama.cpp issue fixed here, and somewhat explained here:

There are a couple patches applied to the legacy GGML fork:

fixed __fp16 typedef in llama.h on ARM64 (use half with NVCC)
parsing of BOS/EOS tokens (see https://github.com/ggerganov/llama.cpp/pull/1931)
Seems like the issue is related to fp16 typedef in llama.h for ARM64 platforms. Confirmed (somewhat) when I unset CMAKE_CUDA_ARCHITECTURES (thus compiling the default), and set "-DLLAMA_CUDA_F16=off". It compiled (though took quite a bit longer than it did previously); I think either turning off the f16 cuda option in the gen_linux.sh file or including the referenced patch from dustynv should shore this issue up and reduce overall changes. I'll defer to your judgement on this one.

Update:
I've done more digging into the F16 issue. I'm not sure why my particular compiler is having this issue, but it would seem the crux of the problem is somewhat alluded to here:
CUFFT:  FP16 computation requires a GPU with Compute Capability 5.3 or later (Maxwell architecture).
Also here has some references:
The 32-bit __half2 floating-point version of atomicAdd() is only supported by devices of compute capability 6.x and higher.
The 16-bit __half floating-point version of atomicAdd() is only supported by devices of compute capability 7.x and higher.
Additionally, when I tried to compile with LLAMA_CUDA_F16=on and CMAKE_CUDA_ARCHITECTURES="50;52;61;70;75;80", I receive this error:
/home/tegra/ok3d/ollama-container/dev/ollama/llm/llama.cpp/ggml-cuda.cu(6324): error: more than one conversion function from "__half" to a built-in type applies:
            function "__half::operator float() const"
/usr/local/cuda/targets/aarch64-linux/include/cuda_fp16.hpp(204): here
            function "__half::operator short() const"
/usr/local/cuda/targets/aarch64-linux/include/cuda_fp16.hpp(222): here
            function "__half::operator unsigned short() const"
/usr/local/cuda/targets/aarch64-linux/include/cuda_fp16.hpp(225): here
            function "__half::operator int() const"
/usr/local/cuda/targets/aarch64-linux/include/cuda_fp16.hpp(228): here
            function "__half::operator unsigned int() const"
/usr/local/cuda/targets/aarch64-linux/include/cuda_fp16.hpp(231): here
            function "__half::operator long long() const"
/usr/local/cuda/targets/aarch64-linux/include/cuda_fp16.hpp(234): here
            function "__half::operator unsigned long long() const"
/usr/local/cuda/targets/aarch64-linux/include/cuda_fp16.hpp(237): here
            function "__half::operator __nv_bool() const"
/usr/local/cuda/targets/aarch64-linux/include/cuda_fp16.hpp(241): here

This error goes away if I change CMAKE_CUDA_ARCHITECTURES="61;70;75;80" and everything works swimmingly.
@dhiltgen do you know why -DLLAMA_CUDA_FORCE_MMQ=on was enabled? I was under the impression that it was preferred to not force MMQ which will enable Tensor cores to be used; compile & GPU execute worked fine either way for me, I haven't tested performance though.

It also seems like llama.cpp upstream changed they way they included __half support for ARM devices several times in the last few months:
Aug 2023 PR
Sep 2023 Commit
Jan 2024 Issue
Jan 2024 PR with Quote:

Jan 20, 2024: Thanks for the discussion - IMO the fundamental issue is that ggml_fp16_t is exposed through the public ggml API in the first place. It's something to fix in the future, but for now will merge this workaround

Feb 2024 Commit

This error goes away if I change CMAKE_CUDA_ARCHITECTURES="61;70;75;80" and everything works swimmingly.

Just to clarify: If CUDA Architecture is "50;51", setting LLAMA_CUDA_F16=off allows it to compile. CMAKE_CUDA_ARCHITECTURES="61;70;75;80" properly supports CUDA_F16.

do you know why -DLLAMA_CUDA_FORCE_MMQ=on was enabled?

This was needed to add support for older GPUs and based on the testing we did at the time, didn't seem to have a major performance impact for newer GPUs.

Okay so I guess the takeaway is for ARM-based CUDA builds, leave architectures at default and disable f16 support, and it should be golden.

@dhiltgen I merged the PR with the latest Ollama release removing most of the AMD code from 'gpu.go'. I tested the build on my ARM and WSL+CUDA setups, and it looks like it's still good to go.
I also adjusted the memory overhead section to better align with the original code by setting overhead to 0 if the L4T env variable is detected. I know it would be preferred to leave in an overhead buffer, but the L4T OS automatic caching messes with the reported free memory (it is reported lower than it actually is) so sometimes when loading 7B models, the free memory reported is less than is needed by the model loader and it falls back to CPU. Maybe we can add a flag somewhere to just have the user manually disable overhead buffer assignment and leave it on by default? Not sure how to handle this.
Anyway, other than that the PR is ready for review with the latest release merged.

Great job!
On Fri, Mar 8, 2024 at 11:34 AM Jeremy @.***> wrote:

@dhiltgen https://github.com/dhiltgen I merged the PR with the latest
Ollama release removing most of the AMD code from 'gpu.go'. I tested the
build on my ARM and WSL+CUDA setups, and it looks like it's still good to
go.
I also adjusted the memory overhead section to better align with the
original code by setting overhead to 0 if the L4T env variable is detected.
I know it would be preferred to leave in an overhead buffer, but the L4T OS
automatic caching messes with the reported free memory (it is reported
lower than it actually is) so sometimes when loading 7B models, the free
memory reported is less than is needed by the model loader and it falls
back to CPU. Maybe we can add a flag somewhere to just have the user
manually disable overhead buffer assignment and leave it on by default? Not
sure how to handle this.
Anyway, other than that the PR is ready for review with the latest release
merged.
—
Reply to this email directly, view it on GitHub
https://github.com/ollama/ollama/pull/2279#issuecomment-1986014388, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ARYO7J2ATT5QASJMPRVSXF3YXHR7TAVCNFSM6AAAAABCRS3NICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBWGAYTIMZYHA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

@dhiltgen all set, I think. Sorry, this is my first time working with a PR.

@dhiltgen I see AssetsDir() referenced in gpu.go, but in the current ollama build there is no AssetsDir() defined in assets.go. Can you help me reconcile the differences between the current assets.go and the one referenced in your branch here?

Sorry about that.  I should have left some comments to aid in the rebase.
Use PayloadsDir https://github.com/ollama/ollama/blob/main/gpu/assets.go#L21
We're reshuffling things more with #3218 so depending on when we get this vs. that PR merged there may be some more rebase adjustments necessary.

@dhiltgen I tested this on my Jetson and it compiled. Running a WSL test now. Should be good to go from here.

@dhiltgen Thank you for your support!

This is forcing everyone else to use cudart now starting with 1.30.0. This shouldn't of been merged as-is.

@buroa The intent is to shift NVidia users to using embedded cudart driver and phase-out libnvidia-ml.so completely once the transition is stable.
Unless you mean non-CUDA users are forced to use cudart?

@buroa cudart is bundled into the released binaries, and we should gracefully handle failures to dynamically load this library.  Systems without nvidia GPUs shouldn't see a hard dependency on cudart.  If you think we missed some corner case, please let us know more details.

Can ollama support the GPU operation on Jetson now? I followed the tutorial to run it on the Jetson Orin Nano, but it still shows 0% GPU utilization. I’m using JetPack 5.1.1.

@Czhazha yes but you need to compile it yourself for now, or after running ollama serve you need to manually delete the embedded CUDA libraries that were extracted in the /tmp folder /tmp/ollama####/runners, then execute ollama run <model>
Working on fixing this

@Czhazha yes but you need to compile it yourself for now, or after running ollama serve you need to manually delete the embedded CUDA libraries that were extracted in the /tmp folder /tmp/ollama####/runners, then execute ollama run <model>
Working on fixing this

Thank you. After following your process, I encountered a new error message when running it again. CUDA error: CUBLAS_STATUS_ALLOC_FAILED.
...
llama_kv_cache_init:      CUDA0 KV buffer size =   384.00 MiB
3月 30 23:22:57 nvidia ollama[7927]: llama_new_context_with_model: KV self size  =  384.00 MiB, K (f16):  192.00 MiB, V (f16):  192.00 >
3月 30 23:22:57 nvidia ollama[7927]: llama_new_context_with_model:  CUDA_Host  output buffer size =   300.75 MiB
3月 30 23:22:58 nvidia ollama[7927]: llama_new_context_with_model:      CUDA0 compute buffer size =   300.75 MiB
3月 30 23:22:58 nvidia ollama[7927]: llama_new_context_with_model:  CUDA_Host compute buffer size =     8.00 MiB
3月 30 23:22:58 nvidia ollama[7927]: llama_new_context_with_model: graph nodes  = 868
3月 30 23:22:58 nvidia ollama[7927]: llama_new_context_with_model: graph splits = 2
3月 30 23:22:58 nvidia ollama[7927]: CUDA error: CUBLAS_STATUS_ALLOC_FAILED
3月 30 23:22:58 nvidia ollama[7927]:   current device: 0, in function cublas_handle at /go/src/github.com/ollama/ollama/llm/llama.cpp/g>
3月 30 23:22:58 nvidia ollama[7927]:   cublasCreate_v2(&cublas_handles[device])
3月 30 23:22:58 nvidia ollama[7927]: loading library /tmp/ollama3449089709/runners/cuda_v11/libext_server.so
3月 30 23:22:58 nvidia ollama[7927]: GGML_ASSERT: /go/src/github.com/ollama/ollama/llm/llama.cpp/ggml-cuda.cu:193: !"CUDA error"
3月 30 23:22:58 nvidia ollama[8189]: Could not attach to process.  If your uid matches the uid of the target
3月 30 23:22:58 nvidia ollama[8189]: process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
3月 30 23:22:58 nvidia ollama[8189]: again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf
3月 30 23:22:58 nvidia ollama[8189]: ptrace: Operation not permitted.
3月 30 23:22:58 nvidia ollama[8189]: No stack.
3月 30 23:22:58 nvidia ollama[8189]: The program is not being run.
3月 30 23:22:58 nvidia ollama[7927]: SIGABRT: abort
...

@Czhazha okay you’re getting the same error we are. You may need to build it yourself until we figure out the CUDA build issue, please reference the build instructions in #3406


Unify Interval/PeriodicInterval code

There's a lot of redundant code

Should domains include topological information?


Order tracking

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

Project coverage is 100.00%. Comparing base (3456c12) to head (fce855c).
Report is 11 commits behind head on demo-fn-19-07.

Additional details and impacted files
@@               Coverage Diff               @@
##           demo-fn-19-07       #35   +/-   ##
===============================================
  Coverage         100.00%   100.00%
===============================================
  Files                  1         1
  Lines                  4         4
  Branches               1         1
===============================================
  Hits                   4         4

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


update auth test

Test plan

Changelog

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#5026  👈
#5025
#5024
#4999
#5003
#4992
#4993
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @RXminuS and the rest of your teammates on  Graphite


Attaching files to a finding

Is there a way to attach files (like crash file) to a finding?

I've just found a corresponding API /api/v2/findings/{id}/files/. Is there an example of code that uses it to upload a file?


pivccu-dkms fails to build with Linux 6.11

Build log as follows:
In file included from /var/lib/dkms/pivccu/1.0.84/build/pl011_raw_uart.c:36:
/var/lib/dkms/pivccu/1.0.84/build/generic_raw_uart.h:136:17: error: initialization of 'void (*)(struct platform_device *)' from incompatible pointer type 'int (*)(struct platform_device *)' [-Werror=incompatible-pointer-types]
  136 |       .remove = __##__raw_uart_driver##_remove,
                \
      |                 ^~
/var/lib/dkms/pivccu/1.0.84/build/pl011_raw_uart.c:331:1: note: in expansion of macro 'module_raw_uart_driver'
  331 | module_raw_uart_driver(MODULE_NAME, pl011_raw_uart, pl011_raw_uart_of_match);
      | ^~~~~~~~~~~~~~~~~~~~~~
/var/lib/dkms/pivccu/1.0.84/build/generic_raw_uart.h:136:17: note: (near initialization for '__raw_uart_driver_platform_driver.<anonymous>.remove')
  136 |       .remove = __##__raw_uart_driver##_remove,
                \
      |                 ^~
/var/lib/dkms/pivccu/1.0.84/build/pl011_raw_uart.c:331:1: note: in expansion of macro 'module_raw_uart_driver'
  331 | module_raw_uart_driver(MODULE_NAME, pl011_raw_uart, pl011_raw_uart_of_match);
      | ^~~~~~~~~~~~~~~~~~~~~~
  CC [M]  /var/lib/dkms/pivccu/1.0.84/build/dw_apb_raw_uart.o
cc1: some warnings being treated as errors
make[3]: *** [/usr/src/linux-headers-6.11.5+bpo-common/scripts/Makefile.build:249: /var/lib/dkms/pivccu/1.0.84/build/pl011_raw_uart.o] Error 1
make[3]: *** Waiting for unfinished jobs....
/var/lib/dkms/pivccu/1.0.84/build/generic_raw_uart.c:824:5: warning: no previous prototype for 'generic_raw_uart_get_gpio_index' [-Wmissing-prototypes]
  824 | int generic_raw_uart_get_gpio_index(struct device *dev, char *con_id, unsigned int idx)
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/var/lib/dkms/pivccu/1.0.84/build/generic_raw_uart.c:839:5: warning: no previous prototype for 'generic_raw_uart_get_led_gpio_index' [-Wmissing-prototypes]
  839 | int generic_raw_uart_get_led_gpio_index(struct generic_raw_uart_instance *instance, struct device *dev, enum generic_raw_uart_led led)
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/var/lib/dkms/pivccu/1.0.84/build/generic_raw_uart.c:971:5: warning: no previous prototype for 'generic_raw_uart_probe_rtc_device' [-Wmissing-prototypes]
  971 | int generic_raw_uart_probe_rtc_device(struct device *dev, bool *rtc_detected)
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /var/lib/dkms/pivccu/1.0.84/build/dw_apb_raw_uart.c:39:
/var/lib/dkms/pivccu/1.0.84/build/generic_raw_uart.h:136:17: error: initialization of 'void (*)(struct platform_device *)' from incompatible pointer type 'int (*)(struct platform_device *)' [-Werror=incompatible-pointer-types]
  136 |       .remove = __##__raw_uart_driver##_remove,
                \
      |                 ^~
/var/lib/dkms/pivccu/1.0.84/build/dw_apb_raw_uart.c:414:1: note: in expansion of macro 'module_raw_uart_driver'
  414 | module_raw_uart_driver(MODULE_NAME, dw_apb_raw_uart, dw_apb_raw_uart_of_match);
      | ^~~~~~~~~~~~~~~~~~~~~~
/var/lib/dkms/pivccu/1.0.84/build/generic_raw_uart.h:136:17: note: (near initialization for '__raw_uart_driver_platform_driver.<anonymous>.remove')
  136 |       .remove = __##__raw_uart_driver##_remove,
                \
      |                 ^~
/var/lib/dkms/pivccu/1.0.84/build/dw_apb_raw_uart.c:414:1: note: in expansion of macro 'module_raw_uart_driver'
  414 | module_raw_uart_driver(MODULE_NAME, dw_apb_raw_uart, dw_apb_raw_uart_of_match);
      | ^~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors

Sorry, just saw #533 should fix this.


[Fine-tuning] what to do with adapter_model.safetensors after fine-tuning

Question
I finally managed to fine-tune LLaVA on a custom dataset (LLaVA-1.5-7b on Google Colab using a single A100 GPU)
The output I got was mostly an adapter_model.safetensors file (610MB) -- and a bunch of other log (?) files
What should I do with the safetensors file? Incorporate it into the base model -- how?
Thanks!

This is what exactly I'm looking for!
I can't find any straightforward document or tutorial!

The adapter_model.safetensors file is a key part of the PEFT (Parameter-Efficient Fine-Tuning) framework, specifically related to methods like LoRA (Low-Rank Adaptation) or other adapter-based fine-tuning techniques. This file contains the weights of the adapter layers that have been fine-tuned, separate from the original model weights.
How it Works

Adapters:
Adapters are small neural network layers added to the original model. During fine-tuning, instead of updating all the weights of the large model, only the weights of these adapter layers are updated. This significantly reduces the number of parameters that need to be trained, making fine-tuning more efficient.

Integration with the Base Model:
When you fine-tune a model using adapters, the adapter_model.safetensors file stores the updated weights of these adapter layers. The base model remains unchanged, and the adapter weights are loaded and integrated with the base model during inference.

Using adapter_model.safetensors
To use the adapter_model.safetensors file, you need to load it along with the base model. Here is an example of how to do this:
from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import PeftModel, PeftConfig

MODEL_NAME = 'meta-llama/Meta-Llama-3-8B'
ADAPTER_PATH = 'path/to/adapter_model.safetensors'

# Load base model
model = AutoModelForCausalLM.from_pretrained(MODEL_NAME, trust_remote_code=True, device_map='auto')
tokenizer = AutoTokenizer.from_pretrained(MODEL_NAME)

# Load adapter configuration and model
adapter_config = PeftConfig.from_pretrained(ADAPTER_PATH)
model = PeftModel.from_pretrained(model, adapter_config, adapter_path=ADAPTER_PATH)

# Now you can use the model with the fine-tuned adapter
input_ids = tokenizer("Your input text here", return_tensors="pt").input_ids
output = model.generate(input_ids)
print(tokenizer.decode(output[0], skip_special_tokens=True))


Bug when set Plot.Axes.DateTimeTicksBottom()

Issue: When the image is continually shrunk after DateTimeTicksBottom() is set, the ScottPlot will brake
ScottPlot Version: 5.0.37
ScottPlot.Plot myPlot = new();
myPlot.Plot.Axes.DateTimeTicksBottom();

After write the code, continuously shrink the image in the window, the ScottPlot will be broken.
After broken, there is no x-axis and y-axis display only one number

Hi @mcxufly, I suspect this has been fixed by #3607 and will be in the next release! 👍


Proposal: link to internal doc by id

What problem will this feature address?
There are cases where we reference many internal documents using links such as:
Please refer to the [Developer Guide](/docs/developer-guide).

However, when files are moved, it becomes challenging to track where these relocated files were referenced in order to update the corresponding links.
Describe the solution you'd like
I'm thinking about adding a global unique ID to the frontmatter of each document:
---
id: developer-guide
title: Developer Guide
description: The guide for developers
---

## ...

We can then reference these documents using their IDs:
Please refer to the [developer-guide].

During the build process, this syntax will automatically convert to:
Please refer to the [Developer Guide](/docs/developer-guide).

Additionally, we can have a doc link card:
Please refer to:

<DocLinkCard id="developer-guide" />

which will translate to:
Please refer to:

<Card href="/docs/developer-guide" title="Developer Guide" description="The guide for developers" />

Describe alternatives you've considered
N/A
Additional context
Let me know what you think. I can help work on this.

I want to avoid adding additional syntax to Markdown/MDX as much as possible, to keep the migrating experience simple (from other frameworks to Fumadocs, or from Fumadocs to other frameworks), and have no learning cost for authors who only know Markdown or simple MDX.

Why don't make and use your own remark/rehype plugin? You can build a community project around that, and Fumadocs's utility can handle that perfectly.

For example, make your custom link/card component wrapper, pass it to MDX components (MDXContent). The wrapper takes an id prop and find the relevant node with id (using source.getPages() or your own implementation), and render the card with information of corresponding page.


⚠ Bofrost.lu has degraded performance

In b2d366d, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1113 ms

Resolved: Bofrost.lu performance has improved in a144f7c after 11 minutes.


Add a new contributors page done ! #777

Hello, PR
Add new feature - #777
Add Contributors page done -
https://github.com/user-attachments/assets/f20e18ad-97ce-4d6a-b27b-caa8e9459fd4
Page link -

Type of change
What sort of changes have you made:

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

Checklist

[x] My code follows the code style of this project.
[x] I have followed the contribution guidelines
[x] I have performed a self-review of my own code.
[x] I have ensured my changes don't generate any new warnings or errors.
[x] I have updated the documentation (if necessary).
[x] I have resolved all merge conflicts.

@somyadipghosh Done
Please merge my PR with Level 3,

Thank You

@somyadipghosh

@somyadipghosh please merge my PR with level 3, otherwise i can't able to do another task


Backport "fix(#i18645): overload ext method body in braces didn't compile" to LTS

Backports #19651 to the LTS branch.
PR submitted by the release tooling.
[skip ci]

No regressions detected in the community build up to lts-19080.
Reference


Deploy Kyverno to check provenance of Tekton

Signed-off-by: pxp928<EMAIL_ADDRESS>Updated to deploy Kyverno first to check provenance of Tekton installation. Address initial trust the builder piece for Issue #182

Updated kyverno policy
I had to update tekton pipelines in my branch as it fails the attestation policy check but can rebase once Brad's PR is merged.
Allow for build systems to be trusted before other pipelines are initiated

We should probably consider updating the order in the readme files: e.g. https://github.com/buildsec/ssf/blob/main/docs/content/docs/getting-started/quick-start.md?plain=1#L51

We should probably consider updating the order in the readme files: e.g. https://github.com/buildsec/ssf/blob/main/docs/content/docs/getting-started/quick-start.md?plain=1#L51

Ah good catch. Fixed

We should probably consider updating the order in the readme files: e.g. https://github.com/buildsec/ssf/blob/main/docs/content/docs/getting-started/quick-start.md?plain=1#L51

Ah good catch. Fixed

Other locations:
https://github.com/buildsec/ssf/blob/main/examples/go-pipeline/README.md?plain=1#L20
https://github.com/buildsec/ssf/blob/main/examples/gradle-pipeline/README.md?plain=1#L14
https://github.com/buildsec/ssf/blob/main/examples/ibm-tutorial/README.md?plain=1#L10
https://github.com/buildsec/ssf/blob/main/examples/maven/README.md?plain=1#L14
https://github.com/buildsec/ssf/blob/main/examples/sample-pipeline/README.md?plain=1#L20


Sensor array cannot compile anymore

Some time ago, ive successfully used this library to read multiple sensors MAX6675.
Library version 0.1.2, 0.1.3 compiling and working fine.
Library version 0.2.0, 0.3.0 i have compilation errors. First error is in declaration line.
I use array, and use in for() statements.
// declaration
MAX6675 ThermoCouples[ThermoCouplesNum];

// initialisation
ThermoCouples[i].begin(MAXclockPin, THCselectPins[i], MAXmisoPin);
ThermoCouples[i].setSPIspeed(MAX6675SPIClockSpeed);

//access
int status = ThermoCouples[THCnumber].read();
int temperature = ThermoCouples[THCnumber].getTemperature()

(...)\MAX6675_softSPI_array_Serial_LCD\MAX6675_softSPI_array_Serial_LCD.ino:34:39: error: no matching function for call to 'MAX6675::MAX6675()'
MAX6675 ThermoCouples[ThermoCouplesNum];
^
In file included from (...)MAX6675_softSPI_array_Serial_LCD\MAX6675_softSPI_array_Serial_LCD.ino:24:0:
(...)\Documents\Arduino\libraries\MAX6675/MAX6675.h:60:3: note: candidate: MAX6675::MAX6675(uint8_t, uint8_t, uint8_t)
MAX6675(uint8_t select, uint8_t miso, uint8_t clock);
^~~~~~~
(...)\Documents\Arduino\libraries\MAX6675/MAX6675.h:60:3: note:   candidate expects 3 arguments, 0 provided
(...)\Documents\Arduino\libraries\MAX6675/MAX6675.h:58:3: note: candidate: MAX6675::MAX6675(uint8_t, SPIClass*)
MAX6675(uint8_t select, SPI_CLASS * mySPI);
^~~~~~~
(...)\Documents\Arduino\libraries\MAX6675/MAX6675.h:58:3: note:   candidate expects 2 arguments, 0 provided
(...)\Documents\Arduino\libraries\MAX6675/MAX6675.h:54:7: note: candidate: constexpr MAX6675::MAX6675(const MAX6675&)
class MAX6675
^~~~~~~
(...)\Documents\Arduino\libraries\MAX6675/MAX6675.h:54:7: note:   candidate expects 1 argument, 0 provided
(...)\Documents\Arduino\libraries\MAX6675/MAX6675.h:54:7: note: candidate: constexpr MAX6675::MAX6675(MAX6675&&)
(...)\Documents\Arduino\libraries\MAX6675/MAX6675.h:54:7: note:   candidate expects 1 argument, 0 provided
(...)MAX6675_softSPI_array_Serial_LCD\MAX6675_softSPI_array_Serial_LCD.ino: In function 'void ThermoCouplesBegin()':
(...)MAX6675_softSPI_array_Serial_LCD\MAX6675_softSPI_array_Serial_LCD.ino:194:69: error: no matching function for call to 'MAX6675::begin(const int&, int&, const int&)'
ThermoCouples[i].begin(MAXclockPin, THCselectPins[i], MAXmisoPin);
^
In file included from (...)MAX6675_softSPI_array_Serial_LCD\MAX6675_softSPI_array_Serial_LCD.ino:24:0:
(...)\Documents\Arduino\libraries\MAX6675/MAX6675.h:62:12: note: candidate: void MAX6675::begin()
void     begin();
^~~~~
(...)\Documents\Arduino\libraries\MAX6675/MAX6675.h:62:12: note:   candidate expects 0 arguments, 3 provided
exit status 1
Compilation error: no matching function for call to 'MAX6675::MAX6675()'
Arduino IDE 2.3.2
Why in new versions this happened?
(updated a bit for readability)

Thanks for your question,
Will investigate this afternoon and come back.

From CHANGELOG.md
## [0.3.0] - 2024-01-19
- Fix #9, improve handling SPI dependency.

----

## [0.2.0] - 2023-11-28
- refactor constructor/begin interface - breaking changes.   //  <<<<<<<<<<<<<<<<
  - minimize conditional code. -- create SPI_CLASS macro to solve it.
- update readme.md
- update examples

The constructor  begin interface has changed as all my (SPI based) libraries got a wider audience and needed to be able to run on more and different boards. To make that possible the constructor and begin() function were changed to have far less conditional code. This reduces the complexity and improves code quality and maintainability.
That explained, still a breaking change.

@rkierzek
Wrote a small example that compiles (1.8.19), I do not have HW nearby to test.
Please give it a try and let me know if it works
In the example I use a mix of HW SPI and SW SPI, and you have to adjust that to your configuration.
Note that the select pins should be unique.
//
//    FILE: MAX6675_array.ino
//  AUTHOR: Rob Tillaart
// PURPOSE: demo array of thermocouples
//     URL: https://github.com/RobTillaart/MAX6675
//     URL: https://github.com/RobTillaart/MAX6675/issues/11

#include "MAX6675.h"

const int ThermoCouplesNum = 4;

MAX6675 ThermoCouples[ThermoCouplesNum] =
{
  MAX6675(3, &SPI),   //  HW SPI
  MAX6675(4, &SPI),   //  HW SPI
  MAX6675(5, 6, 7)    //  SW SPI
};

uint32_t start, stop;

void setup()
{
  Serial.begin(115200);
  Serial.println(__FILE__);
  Serial.print("MAX6675_LIB_VERSION: ");
  Serial.println(MAX6675_LIB_VERSION);
  Serial.println();
  delay(250);

  SPI.begin();

  for (int i = 0; i < ThermoCouplesNum; i++)
  {
    ThermoCouples[i].begin();
    ThermoCouples[i].setSPIspeed(4000000);
  }
}

void loop()
{
  delay(100);

  for (int THCnumber = 0; THCnumber < ThermoCouplesNum; THCnumber++)
  {
    start = micros();
    int status = ThermoCouples[THCnumber].read();
    stop = micros();
    float temp = ThermoCouples[THCnumber].getTemperature();

    Serial.print(millis());
    Serial.print("\tID: ");
    Serial.print(THCnumber);
    Serial.print("\tstatus: ");
    Serial.print(status);
    Serial.print("\ttemp: ");
    Serial.print(temp);
    Serial.print("\tus: ");
    Serial.println(stop - start);

    delay(1000);
  }
}

//  -- END OF FILE --

Output on an UNO  looks like:

zero temp due to no sensors
device 2 is a SW SPI which is much slower than HW SPI

MAX6675_LIB_VERSION: 0.3.0

351	ID: 0	status: 0	temp: 0.00	us: 32
1351	ID: 1	status: 0	temp: 0.00	us: 32
2353	ID: 2	status: 0	temp: 0.00	us: 256
3453	ID: 0	status: 0	temp: 0.00	us: 32
4455	ID: 1	status: 0	temp: 0.00	us: 28
5456	ID: 2	status: 0	temp: 0.00	us: 260
6557	ID: 0	status: 0	temp: 0.00	us: 32
7558	ID: 1	status: 0	temp: 0.00	us: 28
8559	ID: 2	status: 0	temp: 0.00	us: 256

@RobTillaart RobTillaart
After RobTillaart code change:
MAX6675 ThermoCouples[ThermoCouplesNum] =
{
  MAX6675(4, 3, 2),
  MAX6675(5, 3, 2),
  MAX6675(6, 3, 2)
};

sketch compliled and flashed OK. But hardware not working as i want.
Readings output example:
09:45:48.313 -> MAX6675_LIB_VERSION: 0.3.0
09:45:48.313 ->
09:45:48.673 -> 356	ID: 0	status: 0	temp: 0.00	us: 260
09:45:49.677 -> 1357	ID: 1	status: 0	temp: 0.00	us: 260
09:45:50.671 -> 2359	ID: 2	status: 0	temp: 0.00	us: 260
09:45:51.676 ->
09:45:51.770 -> 3460	ID: 0	status: 0	temp: 0.00	us: 264
09:45:52.749 -> 4461	ID: 1	status: 0	temp: 0.00	us: 264
09:45:53.751 -> 5463	ID: 2	status: 0	temp: 0.00	us: 260

sometimes(rare case about 1of100) status or temp is different than 0.
Same HW setup with old lib version working fine.
Maybe (long shot) a SPI CPOL/CPHA MODE must be other?

Ok, good feedback
Can you test MAX6675_test.ino with a single TC?

But hardware not working as i want.

This is unclear for me - what do mean with as I want?

sometimes(rare case about 1of100) status or temp is different than 0.

So mostly it just reads zero's

Maybe (long shot) a SPI CPOL/CPHA MODE must be other?

Not I'm aware of.
Did it change in the library since your working version?
If so can you point where it did?

@rkierzek
Possibly swapped pins 2 and 3?
MAX6675(uint8_t select, uint8_t miso, uint8_t clock)

Pins MISO and CLK in correct connection.

Hello, again.
I tested new library with success! All 10 modules together.
Software part is OK. Unfortunately hardware setup is problem.
Connecting additional electrolytic capacitors every couple (3/4/5) MAX6675 modules completely eliminated problems with the stability of readings of some modules. For some reason, unknown to me, I did not immediately notice the problems in the previous library, because not all thermocouples were always analyzed, and not always occur.
Ultimately, the problems I noticed after adapting the code to the new version of the library were hardware related, the fault was all mine.
I am very sorry for the confusion.
The library is very good and useful.

Good to hear it all works now as intended.
If I understand the problem, it was noise on the powerline?
Can you post your schema for future reference?

As the issue is solved I close this issue.
Feel free to post your schema how you solved it for future reference.


Add support for glTF/glb tile content

This is a WIP implementation of 3DTILES_content_gltf targeting the 3d-tiles-next staging branch.
glTF and glb content is loaded as Gltf3DTileContent which is a slimmed down version of Batched3DModel3DTileContent. Support for EXT_feature_metadata will be in a future PR.
Sandcastle

Thanks for the pull request @lilleyse!

:heavy_check_mark: Signed CLA found.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.
[ ] Works (or fails gracefully) in IE11.

Thanks for the pull request @lilleyse!

:heavy_check_mark: Signed CLA found.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.
[ ] Works (or fails gracefully) in IE11.

I tried the sandcastle (and also tried the glb model as well), both are working as far as I can tell!

I tried the sandcastle (and also tried the glb model as well), both are working as far as I can tell!

Merging. Thanks @lilleyse!


Document npm install workaround

We depend on<EMAIL_ADDRESS>which has a build issue which can be worked around as described.
better-sqlite is not actually needed, it's just a transitive depedency: secp256k1_hash_to_curve_circom > circom-helper ><EMAIL_ADDRESS>The best solution is to edit secp256k1_hash_to_curve_circom so that we can import the circuits and typescript helpers without also importing the testing infrastructure, which better-sqlite3 is needed for. The workaround should be redundant once the dependencies are fixed.

Hi! Would it be helpful if we moved circom-helper to devDependencies in https://github.com/geometryresearch/secp256k1_hash_to_curve/blob/main/circuits/package.json ?


Cloudbuild SA uses wrong project

I have used tfengine to create the org_foundation modules.
I then manually created a new module/folder called policies, added "policies" to the managed_dirs inside the tfengine config, and reran tfengine. Then I ran terraform apply inside the CICD module.
The policies module has the following main.tf:
terraform {
  required_version = ">=0.14"
  required_providers {
    google      = "~> 3.0"
    google-beta = "~> 3.0"
    kubernetes  = "~> 1.0"
  }
  backend "gcs" {
    bucket = "my-terraform-state"
    prefix = "policies"
  }
}

resource "google_monitoring_alert_policy" "db_cpu_utilization_alert_policy" {
  project      = "my-project"
  display_name = "Database Mem Usage Alert"
  combiner     = "OR"
  conditions {
    display_name = "Cloud SQL Database - Memory utilization"
    condition_threshold {
      filter          = "resource.type = \"cloudsql_database\" AND metric.type = \"cloudsql.googleapis.com/database/memory/utilization\""
      duration        = "60s"
      comparison      = "COMPARISON_GT"
      threshold_value = ".8"
      aggregations {
        alignment_period   = "300s"
        per_series_aligner = "ALIGN_MEAN"
      }
    }
  }

  notification_channels = var.notification_channels
}

After creating and merging a PR,  Cloudbuild throws an error saying that the Monitoring API has not been enabled for the project "my-devops". It appears that it is trying to create the policies in the devops project and not the project specified
When I run terraform apply locally, it successfully creates the policy inside of "my-project"
I also tried setting user_project_override = false for google-beta but it did not help

Hi @electricBonfire, sorry for the delay.
"If the service account needs to access resources in other projects, you usually must enable the APIs for those resources in the project where you created the service account." as in https://cloud.google.com/iam/docs/creating-managing-service-accounts#creating. In order to for the Service Account in the devops project used by Cloud Build jobs to manage your monitoring related resources, the Monitoring API should also be enabled in the devops project. In your devops template, please also add the Monitoring API to the list of APIs to enable. Once that is done, please redeploy devops folder manually, and it should work fine afterwards.


Crash when searching for single byte hex string

Binary Ninja Version
2.4.3008-dev
Describe the bug
Searching an entire binary for a single byte hex string crashes the program (it was a typo, I'm not actually trying to index a gazillion instructions). Below is a screenshot of the search settings.
To Reproduce
Steps to reproduce the behavior:
See screenshot for search settings to reproduce.
Expected behavior
Program hangs for a second and then silently crashes.
Screenshots
http://puu.sh/IdNM8/5a540c10a7.png
Version and Platform (required):

Binary Ninja: 2.4.3008-dev
OS: Windows 10
Version 10.0.19043 Build 19043

Additional context
Binary being reversed is windows x86

Also, can you share what bv.segments looks like for that particular file?


Remove AMP does not work

Describe the bug
I have enabled Remove AMP, but it does not work when I opened amp.reddit.com links from Google search.
To Reproduce
Steps to reproduce the behavior:

Enable Remove AMP in settings
Open https://www.google.com/search?q=amp+reddit in Kiwi Browser.
Open the second search result.
The AMP page
https://amp.reddit.com/r/explainlikeimfive/comments/ecrzvp/eli5_what_are_amp_pages_and_whats_bad_about_them/
is opened.

Expected behavior
The browser should remove AMP and show the normal version of the webpage.
https://www.reddit.com/r/explainlikeimfive/comments/ecrzvp/eli5_what_are_amp_pages_and_whats_bad_about_them/
Screen recording
https://user-images.githubusercontent.com/34395942/127593891-c41f63c3-d228-4e6f-979d-f0087cb36902.mp4
Smartphone (please complete the following information):

Device: Xiaomi POCO M3
Android Version : Android 10
Kiwi Browser Version 93.0.4577.18

Thank you very much, your reports are very very nicely done ! I will prepare a fix for AMP in the coming days

I think I found the issue: in PersonalizeResults, when you get shouldRemoveAmp, the getBoolean for "avoid_amp_websites" has a second parameter of true instead of false.

@kiwibrowser Some websites, for example the register.com uses AMP, not amp in their urls, so you have to account for upper and lowercase.

There's also AdguardTeam/DisableAMP that work well as a usercript (with violentmonkey/violentmonkey for example).

Hi, download the latest build from here:
https://github.com/kiwibrowser/src.next/releases
and revert if the issue still occurs, else you can close this issue.


pw - improve playwright tests

⚠⚠⚠ Since we do not accept all types of pull requests and do not want to waste your time. Please be sure that you have read pull request rules:
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma
Tick the checkbox if you understand [x]:

[x] I have read and understand the pull request rules.

Description
This pull request improves the test suites by adding step() markers across tests for better debugging in the future. I also refactored the code to follow the DRY principle, reducing redundancy and improving maintainability.
Type of change

Code refactor (applying DRY principle)
This change requires a documentation update

Checklist

[x] My code follows the style guidelines of this project
[x] I ran ESLint and other linters for modified files
[x] I have performed a self-review of my own code and tested it
[x] I have commented my code, particularly in hard-to-understand areas (including JSDoc for methods)
[x] My changes generates no new warnings
[ ] My code needed automated testing. I have added them (this is optional task)

Screenshots (if any)
Please do not use any external image service. Instead, just paste in or drag and drop the image here, and it will be uploaded automatically.

Hi thanks for the PR. I have left a few comments below

Thank you for the feedback! I'm learning and practicing as I go, and I’ve made the updates based on your suggestions. I hope everything looks good now, but feel free to let me know if anything else needs adjustment. Great working together on this :)


SQL-183 GitHub Deps Graph

SQL-183 Add clojure deps to GitHub deps graph

It looks like we might need to combine the pom.xml and package-lock.json as manifests in a single snapshot for this to work correctly, which is challenging.


Add a training recipe of ConvTasNet on LibriMix dataset and provide pre-trained weights.

🚀 Feature

Motivation
In torchaudio.models, we supported ConvTasNet, a convolutional network for speech separation that outperforms the ideal ratio masks. However, the pre-trained weights are missing that makes it difficult to validate the performance of the model.
Thanks to Asteroid, we have plenty of speech separation models and utility functions to reproduce the results🚀 🚀 . It will be great to add a training recipe for ConvTasNet into torchaudio so that we make sure the model structure is good to use. Also users will benefit from it by: 1) using the pre-trained weights directly provided by torchaudio; 2) use the training recipe as a baseline for their research.

Pitch

Add a LibriMix dataset. Different from wsj0-mix, LibriMix is based on LibriSpeech and it's purely open-source. It'll attract more researchers to develop their methods and compare with the ConvTasNet baseline.
Add a training recipe for ConvTasNet. This includes a PyTorch-Lightning trainer, a training pipeline and an evaluation step.
After we achieves an identical performance as Asteroid, we can provide a pre-trained weight to let users directly use it instead of training the model from scratch.

Again, shout out to Asteroid people @mpariente @popcornell @JorisCos @jonashaag for building an amazing library for speech separation and enhancement!

Finished by #1757 #2411. #2440, and #2675


auto width/height?

I don't see a way to make this slider automatically fit the container. CSS changes aren't working. I'd like it to fit height or width wise, whichever limit it comes up against on a device, and keep the images proportional. Right now, it's "responsive" as far as width goes, it seems, but the height has to be set. That's a problem for varying size images.

Never mind, found the "fill mode" setting in the options, adjusting to 1.


Add SCB methods to enable/disable exceptions

Some exceptions might be disabled by default which means that the
HardFault handler will be called instead of the exception handler. This
commit adds methods on the SCB peripheral that use the SHCSR register to
enable/disable exceptions.
Signed-off-by: Hugues de Valon<EMAIL_ADDRESS>

r? @ithinuel
(rust_highfive has picked a reviewer for you, use r? to override)

One comment, otherwise I'm happy with this. Thank you for the PR!

This was ready to be merged, any updates?

Sorry for the wait!
On the whole I think this is good. I had a few thoughts as I looked over it...

Should it be unsafe to disable the exception handlers? I think that since disabled exceptions propagate into HardFaults it's OK to allow safely disabling them. One reason we require that (for example) enabling interrupts be unsafe is to help enforce our invariant that interrupts won't fire within a CriticalSection closure, which could otherwise break our memory model. I don't think the same reasoning applies here since the exceptions would always cause a jump to the HardFault handler.

Since the methods already contain a critical section, should they be static methods on SCB, instead of requiring an &mut? I think they probably could be without loss of safety, but haven't given it enough thought to really be sure. If possible, static methods are easier to use without requiring the user obtain the SCB instance.

State checks in each method. Is there a requirement to check if the exception handler is enabled or not before setting/clearing it? I didn't see any requirement in the ARM. If so, perhaps we could remove the check and just execute the register modify, which also ensures the state doesn't change between us checking and us modifying the register.

Thanks for the review 😃

Should it be unsafe to disable the exception handlers? I think that since disabled exceptions propagate into HardFaults it's OK to allow safely disabling them. One reason we require that (for example) enabling interrupts be unsafe is to help enforce our invariant that interrupts won't fire within a CriticalSection closure, which could otherwise break our memory model. I don't think the same reasoning applies here since the exceptions would always cause a jump to the HardFault handler.

I would think so too because these methods do not enable/disable interrupts per say, but only modify their routing to the specific handler or HardFault. That is ensured (I think), because the read-modify-write sequence is done during a critical section (modifying other bits of the same register would set interrupts as active or pending).

Since the methods already contain a critical section, should they be static methods on SCB, instead of requiring an &mut? I think they probably could be without loss of safety, but haven't given it enough thought to really be sure. If possible, static methods are easier to use without requiring the user obtain the SCB instance.

I was not sure of what was the idiomatic thing to do! It is indeed easier to use static methods. I now realise that I used &mut for is_enabled that only read the SCB and could only take a reference to self.
I don't think I am qualified enough to say if it is safe to directly access the register by doing something like *Self::ptr(). I am worried if static methods might break the ones using ownership, if for example the SCB peripheral is instantiated as immutable to be used only with methods taking &self but there are also static methods that can modify its state. Not sure at all!

State checks in each method. Is there a requirement to check if the exception handler is enabled or not before setting/clearing it? I didn't see any requirement in the ARM. If so, perhaps we could remove the check and just execute the register modify, which also ensures the state doesn't change between us checking and us modifying the register.

I don't think there are any requirements ; it was done for performance to avoid going through a critical-section set-up if it is actually not needed! If you think this is not needed, I can remove it indeed.

Out of your three points, I think we agreed on the first one that unsafe is not needed. What about the other two?

using static SCB instead of using a reference -> I am happy to do that change in my PR if you think this is safe
state checks -> I am happy to remove them if the performance cost is minimal

Sorry for the wait (again!). We had a chat about this at today's meeting (logs are here). I'm cautious about merging this without enough consideration because how interrupts are handled is such an important part of our safety story and one of the hardest bits to get right.
Safety
This still seems like a point of concern, especially in relation to critical sections/mutexes. It might be related #196 as well. However I think this argument offers a way out:

MemManage, BusFault, UsageFault are configurable priority exceptions, so they are not taken if they occur during one of our critical sections (where PRIMASK is 1).
Instead they are promoted to HardFaults and the HardFault handler is taken
This is the same as the default behaviour when the exception handlers are not enabled
So, entering a critical section (which is safe) has the same effect as disabling these handlers
Consequently other user code cannot rely on these handlers being active: a hardfault might always occur instead (the default behaviour), which hopefully prevents anyone's safety invariants relying on the exception handler being called
Likewise, enabling one of these handlers does not change the exclusivity of a critical section: they won't run in it, we don't get #196-esque contention, but instead a HardFault occurs

I think this means we can keep them safe.
Static SCB and state checks
If we use &mut to ensure we have exclusive access to SCB, I don't think we need the critical section inside this code, because nothing else can have written to the register anyway, and software cannot clear the pending/active bits in the register. So I think the best course of action would be to keep the &mut self for modify (and swap to &self for reads), remove the critical sections, and remove the state checks. What do you think?
cc @japaric who's probably thought about this stuff the most...

Thanks a lot for putting that issue as a topic during last meeting 💯

I think this means we can keep them safe.

Agree with your points and the conclusion.

So I think the best course of action would be to keep the &mut self for modify (and swap to &self for reads), remove the critical sections, and remove the state checks. What do you think?

That seems like a good option and I agree that the ownership rules are better suited/more efficient to prevent data races than disabling exceptions.

Removed the critical sections and the state checks.
I am all-in about using references to peripherals in their methods to enforce the ownership rules but one thing which is weird is that in the following code:
    #[inline]
    #[cfg(not(any(armv6m, armv8m_base)))]
    pub fn enable(&mut self, exception: Exception) {
        if let Some(shift) = SCB::shcsr_enable_shift(exception) {
            // The mutable reference to SCB makes sure that only this code is currently modifying
            // the register.
            unsafe { self.shcsr.modify(|value| value | (1 << shift)) }
        }
    }

changing &mut self to &self will still compile, even if the method modify self. One need to be careful to not rely on the compiler to check for those!

Thanks!

changing &mut self to &self will still compile

The reason for this is we don't require &mut self to call modify on registers; they're treated as a sort of interior mutability. Since &self isn't Send or Sync, we know it will only be used from one thread of execution, so even multiple &self references can't race each other to perform a read-modify-write. This is convenient for sharing device peripherals I guess.
However in cortex-m we've used &mut self for pretty much all methods that modify the registers; I don't think there's any particular reason for that but it's what we've got at the moment. I guess we could consider changing it for a 1.0 release but for now it's simpler to keep these methods &mut too.

Guess we're good to go!
bors merge

Hmm, @thejpster please could you approve the changes or dismiss your review? Looks like it still being open is blocking bors.

Let's see whether that did the trick.
bors r=adamgreig

Damn, did not. That's so silly.

Maybe try the close and re-open dance?

Nope.

Pushing a new commit should dispose of the old reviews

Pushing a new commit should dispose of the old reviews

Yes, but only the approvals (if configured in the GH branch protection rules), not the change requests.


signaling pattern recognition receptor activity disambiguation and true path violations

defined
GO:0008329  signaling pattern recognition receptor activity
Combining with a pathogen-associated molecular pattern (PAMP), a structure conserved among microbial species, or damage-associated molecular pattern (DAMP), an endogenous molecule released from damaged cells), and transmitting a signal to initiate a change in cell activity.
this is clearly the term for a PAMP receptor, when a host receptor binds to a pathogen cell surface molecule  called a PAMP
However, it has children that are  NOT specific to PAMPs
lipoarabinomannan receptor activity
lipopolysaccharide receptor activity
lipoteichoic acid receptor activity
peptidoglycan receptor activity
polysaccharide receptor activity
or at least not defined as being specific for PAMPS....

Suggest, in addition to fixing the  descendants,
renaming this
"pathogen-associated molecular pattern receptor activity"
so that it cannot be misused.

@addiehl  Could you have a look at this one too? Thanks!!

will do

Thanks Alex, no hurry for this. I found enough bugs  in the tool not need to pursue testing for a while.
Id also  be interested whether you know about the location of these. According to this plant paper, PMID:20601497
I think that the pathogenic fungi that is recognised by the   "pattern recognition receptor" is recognising the  cell surface of the pathogen (a fungi) , but it is inside the host (plant leaf cell). I don't think it's a cell surface receptor but I could be wrong.....

Agree with @ValWood suggestion of renaming/defining term to "pathogen-associated molecular pattern receptor activity".
We have also been looking at the pattern recognition pathway process terms, which we think could do with some revision along the same lines, and some rewiring. We are thinking about them wrt to Drosophila - which I need to discuss with the rest of our group next week.

See you've openned a discussion on pathways here #16615

Yes, I got a bit lost down there to be honest, it isn't very consistent with how we are supposed to annotate pathways. You could describe everything in about 20  different ways!

Good point. Ant suggestions?
I worry about "molecular pattern recognition receptor"
because "molecular pattern" is a bit vague  (although I guess this could be covered in the def?).
Or, separate DAMP and PAMP receptors?
Or  just use "signalling receptor activity"
Since the type will become obvious from "has_input" and part_of connection to the process.

@ukemi
@pgaudet
thoughts how best to do this?

Perhaps it would be good to separate out PAMPs and DAMPs - think that it would be a shame to lose them from the GO, as there is a lot of interest in these types of activities wrt disease. For DAMPs, the has_input won't make it obvious as these can be things like mtDNA fragments.

Listening to immunologist colleagues talk, I get the impression that the "molecular pattern" terminology arises because they want their own distinctive way of describing the behavior  of a receptor (TOLL or other) with a broad and incompletely described specificity for ligands. And the DAMP - PAMP distinction is at least in part a way of specifying what the ultimate result of receptor activation will be: innate responses to set off a full immune reaction to a pathogen, or innate responses that lead to autoimmunity. At the level of describing the molecular details of a receptor:ligand interaction, this distinction may be out of scope. But a real cellular immunologist should jump in here; I'm pout of date and guessing to fill in gaps. You might ask<EMAIL_ADDRESS>.

That's a nice summary of expectations.
Maybe we  should do this by
signalling receptor activity  part_of GO:0080185 effector dependent induction by symbiont of host immune response (or whatever).
I'm happy to go either way.....

Note that GO:0038187 is not currently positioned under "innate immune receptor"


wont work?

Challenge Nest an Anchor Element within a Paragraph has an issue.
User Agent is: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36.
Please describe how to reproduce this issue, and include links to screenshots if possible.
My code:

<link href="https://fonts.googleapis.com/css?family=Lobster" rel="stylesheet" type="text/css">

CatPhotoApp

  view more

cat photos

Kitty ipsum dolor sit amet, shed everywhere shed everywhere stretching attack your ankles chase the red dot, hairball run catnip eat the grass sniff.

Purr jump eat the grass rip the couch scratched sunbathe, shed everywhere rip the couch sleep in the sink fluffy fur catnip scratched.

Thank you for reporting this issue.
This is a standard message notifying you that this issue seems to be a request for help. Instead of asking for help here, please click the "Help" button on the challenge on freeCodeCamp, which will take you to the help chatroom for that specific challenge. You can also view our full list of official chatrooms.
If you think I'm wrong in closing this issue, please reopen it and add further clarification. Thank you, and happy coding.


[libunifex] Update to 2023-06-07 (v0.3.0)

[x] Changes comply with the maintainer guide
[x] SHA512s are updated for each updated download
[ ] The "supports" clause reflects platforms that may be fixed by this new version
[ ] Any fixed CI baseline entries are removed from that file.
[ ] Any patches that are no longer applied are deleted from the port's directory.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

This is great, hopefully we can get it in soon :).

All features are tested successfully in the following triplet:
x86-windows
x64-windows
x64-windows-static

Thanks for the update!


Fix some settings in the application

I made two minor modifications to make the application easier to use:

Modified the hash-bang line to get perl from /usr/bin/env.  This helps on platforms (e.g., Mac), where perl may not be in the standard location.
Updated @INC using FindBin.  Previously, unless the lib/ directory for this program was in @INC, it couldn't find its own library files.

I didn't realize that was how the system was supposed to be installed (not mentioned in the README), so I just cloned this to ~/src and then symlinked bin/svn-bisect to ~/bin/svn-bisect.  After the above 2 changes it worked fine.


fix: fix random open stream fail

fix #297
In the case of strict message order, the introduction of inconsistent queues will cause inconsistent concurrency order
yank 0.2.9-10 yamux

need a unit test to prevent regressions

need a unit test to prevent regressions

need a unit test to prevent regressions

The modified code cannot construct such a test, but before the modification, can do it

need a unit test to prevent regressions

The modified code cannot construct such a test, but before the modification, can do it

need a unit test to prevent regressions

The modified code cannot construct such a test, but before the modification, can do it

The regression test case means when the code changes back, the test case will fail.

need a unit test to prevent regressions

The modified code cannot construct such a test, but before the modification, can do it

The regression test case means when the code changes back, the test case will fail.


Expose FileSpanExporter

The FileSpanExporter implementation here is handy, and there doesn't appear to be a standard filesystem exporter in the rest of the opentelemetry-js ecosystem.
Would you be open to any of these options?

Contributing it to open-telemetry/opentelemetry-js, alongside ConsoleSpanExporter
Releasing it separately, so it can be used on its own
Exporting it, so it can be imported from @lumigo/opentelemetry

Hi @drob thanks for the interest in the exporter!
Though we'd be interested in contributing it to the upstream community, we don't have the bandwidth right now for such an effort.
As an interim solution, would you be willing to propose a PR exporting it so it can be imported from @lumigo/opentelemetry until its contributed? Thanks


Mark events with entrance fees

We need a way to mark events with entrance fees

Is now part of #458


Feature/currency conversion

Description
Fixes # (issue)
Adds currency conversion support to developer and client routes
Type of change

[x] New feature (non-breaking change which adds functionality)

Change Status

[ ] Complete, tested, ready to review and merge
[x] Complete, but not tested (may need new tests)
[ ] Incomplete/work-in-progress, PR is for discussion/feedback

How Has This Been Tested?

[ ] Test A
[ ] Test B

Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] My code has been reviewed by at least one peer
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[x] There are no merge conflicts

Need to update to support local Postgres testing


Error botocore , EFS mount via IP

I m trying to build superset using  template for my POC, i m getting below , this is because i have different DNS options set for my existing VPC since it creates its own private DNS zone which doesn't have forward in our DNS,  if can mount via that will be solution but  got an error for botocore
ResourceInitializationError: failed to invoke EFS utils commands to set up EFS volumes: stderr: Failed to resolve "--" - check that your file system ID is correct, and ensure that the VPC has an EFS mount target for this file system ID. See https://docs.aws.amazon.com/console/efs/mount-dns-name for more detail. Attempting to lookup mount target ip address using botocore. Failed to import necessary dependency botocore, please install botocore first. : unsuccessful EFS utils command execution; code: 1

I was able to resolve this error by adding ingress on port 2049 to the superset SG.
  Default2049Ingress:     Properties:       CidrIp: <IP_ADDRESS>/0       Description: efs:2049/tcp on default network       FromPort: 2049       GroupId:         Ref: DefaultNetwork       IpProtocol: TCP       ToPort: 2049     Type: AWS::EC2::SecurityGroupIngress


Semantic Versioning of the Application

http://semver.org/
I think we need to be strict on doing some semantic versioning so that we know what version is being used by people when they report bugs. This way we know if they are using an old version or not. We need to mention the version in the console logs for people to identify version.
So, we need to make sure we bump the patch number when we fix known bugs. And bump minor version when we add functionality like add new API endpoints. And then bump major version when we change implementation of existing functionality by enhancing it and stuff, like changing an API endpoint's implementation

We also need to release the source code when we bump versions, including patches too

@karuppiah7890 This is something we'll do from this point onwards. In the earlier days, @4iar and I were purely concerned with implementing features and disregarded this but it's something that we'll take heed of from this point forward. Please email me as a follow up to this comment.


Add humans.txt icon

Type

[X] File icon
[ ] Folder icon

Context and associations
humans.txt
References
Like the robots.txt icon but with a little human instead? I don't really like the official https://humanstxt.org/ logo...

i tried to make one myself, but it's really hard to make it not cluttered while maintaining original design

Just the "h" without the face would work imo (the outlined 1st version you made @eye-wave )

Closed by #150.


push/pull already in progress

Error: Unknown Error (400): {"detail":"push or pull localhost:5555/test-509786421 is already in progress"}

https://ci.deis.io/job/workflow-test-pr/4684/console

Seen again here - https://ci.deis.io/job/workflow-test-pr/4801/console
@kmala @arschles thoughts?

Hasn't been seen in a few months - Lets reopen if it happens again


restore support for IP subnet authz on actuators (#5523)

Backport to 6.6.x for more compatibility with previous releases.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


module.suspend not called if module does not have dom content

Please only submit reproducible issues.
If you're not sure if it's a real bug or if it's just you, please open a topic on the forum: https://forum.magicmirror.builders/category/15/bug-hunt
Problems installing or configuring your MagicMirror? Check out: https://forum.magicmirror.builders/category/10/troubleshooting
When submitting a new issue, please supply the following information:
Platform: Ubuntu Mate on ODROID xu4
Node Version: v6.14.2
MagicMirror Version: 2.3.1
Description: my modules, which have no dom content (and no position specified in config) do not receive the suspend notification.
Steps to Reproduce: create the default module as defined in the doc, but only supply the  module name in config.js
at this point issue a module.hide() against this module, but its suspend method will not be called.
Expected Results: module suspend() function should be called
Actual Results: suspend not called (resume is)
Configuration: ```
{
module: "ImageScheduler",
},
{
module: "ImageService",
},

**Additional Notes**: Provide any other relevant notes not previously mentioned. This is optional.

this is due to the test for dom content in js/main.js/hideModule()

var moduleWrapper = document.getElementById(module.identifier);
    if (moduleWrapper !== null) {

there should be an else, to invoke the (post fade timeout)callback setup in js/module.js/hide()

}
else
     if (typeof callback === "function") { callback(); }

Thanks. Feel free to send a PR.

pr merged july 2018,
https://github.com/MichMich/MagicMirror/pull/1309


Upgrade docker-client dep from 3.3.4 to 3.5.1

Fixes #143

@davidxia seems like docker:client:3.5.1 is not in maven central?

Yea I'm waiting for it to be indexed.
On Friday, January 15, 2016, Matt Brown<EMAIL_ADDRESS>wrote:

@davidxia https://github.com/davidxia seems like docker:client:3.5.1 is not
in maven central
https://search.maven.org/#search|gav|1|g%3A"com.spotify" AND a%3A"docker-client"?
—
Reply to this email directly or view it on GitHub
https://github.com/spotify/docker-maven-plugin/pull/178#issuecomment-172092617
.

--
David Xia
Software Engineer
<EMAIL_ADDRESS>

@mattnworb @rohansingh

:+1:


feat: expand the notification details on tap

Description:
what are the changes you implemented?
Adapting this https://github.com/OfirMatasas/Notify/pull/109 to the new UI.
Type of change:

[ ] Bug fix
[x] New feature
[x] Fix/new infrastructure

The ticket this PR closes:
https://ofirlindekel.atlassian.net/browse/NOTIFY-188?atlOrigin=eyJpIjoiM2ZhOTYwYTllOWYzNDZiOGIzOWVkNDdhMDY2Y2QwMzciLCJwIjoiaiJ9
Scenarios that were tested during this implementation:
Tapping on a notification when the app is minimized and getting the relevant notification details in the expander.

Works when the application is minimized and the notification page needs to be on 'All notifications'.

I changed it to open with "All notifications"
If you want you can open a new ticket to make it work when the app is closed.


types not specified in package.json

The typescript type definition for the index.d.ts is not specified in package.json as "types": "src/index.d.ts" and so is inaccessible to typescript. The fix is to release the exact same code with a "types" field in package.json

@Bkucera Thanks for this awesome package! It works like a charm to test accessibility in our current project. However the typecheck fails due to this issue. I saw that the fix has already been pushed but hasn't been released yet. Will there soon be another release so that this can be closed?


AngularFire2 Google Login in android not working when Native-Firebase or Native-FCM plugins are installed

Whenever i try to implement any firebase push notification feature, Google-Plus Login stopped working on android device without trowing any errors,
Here i have described my error in stack-overflow
I have implemented the google plus sign in method in try catch method and found the entire try catch method is not running at all.
First i installed native firebase plugin and then native FCM plugin and both had same issue, remove it and started working again.


feat: incorporate async python

Description
Change Python SDK implementation to be async base
References

Close https://github.com/openfga/sdk-generator/issues/24
See https://github.com/openfga/python-sdk/pull/1 for the actual code change

Review Checklist

[ ] I have clicked on "allow edits by maintainers".
[ ] I have added documentation for new/changed functionality in this PR or in a PR to openfga.dev [Provide a link to any relevant PRs in the references section above]
[x] The correct base branch is being used, if not main
[ ] I have added tests to validate that the change in functionality is working as expected

Corresponding doc changes - https://github.com/openfga/openfga.dev/pull/214


TC1, TC2 for capacitor

Codecov Report

Merging #59 into development will increase coverage by 0.1%.
The diff coverage is 78.26%.

@@              Coverage Diff               @@
##           development      #59     +/-   ##
==============================================
+ Coverage        75.38%   75.48%   +0.1%
==============================================
  Files              283      283
  Lines            13615    13634     +19
==============================================
+ Hits             10264    10292     +28
+ Misses            3351     3342      -9

Impacted Files
Coverage Δ

SpiceSharp/Components/RLC/CAP/BaseParameters.cs
64.28% <33.33%> (-8.45%)
:arrow_down:

...iceSharp/Components/RLC/CAP/ModelBaseParameters.cs
77.77% <60%> (+77.77%)
:arrow_up:

...iceSharp/Components/RLC/CAP/TemperatureBehavior.cs
66.66% <93.33%> (+14.16%)
:arrow_up:

...ceSharp/Simulations/Behaviors/SetupDataProvider.cs
60% <0%> (+5%)
:arrow_up:

SpiceSharp/Components/RLC/CAP/Capacitor.cs
56.25% <0%> (+6.25%)
:arrow_up:

SpiceSharp/Simulations/Base/LoadStateEventArgs.cs
100% <0%> (+20%)
:arrow_up:

SpiceSharp/Components/RLC/CAP/CapacitorModel.cs
100% <0%> (+100%)
:arrow_up:

Continue to review full report at Codecov.

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


updateSbtClassifiers fails when scalaOrganization is set to org.typelevel

steps
Create a minimal project with scalaOrganization in ThisBuild := "org.typelevel"
Run sbt updateSbtClassifiers
problem
The task fails with the following error:
[error] (*:updateSbtClassifiers) sbt.ResolveException: unresolved dependency: org.typelevel#scala-library;2.10.6: not found
[error] unresolved dependency: org.typelevel#scala-compiler;2.10.6: not found
[error] unresolved dependency: org.typelevel#scala-reflect;2.10.6: not found
[error] unresolved dependency: org.typelevel#scalap;2.10.6: not found

expectation
The task should resolve the scala 2.10 artifacts for sbt from the org.scala-lang organization
notes
sbt 0.13.13
I could not find a report of this problem, but it looks very similar to #2686, which was fixed in #2692.
Also, I have uploaded a minimal repro build in https://github.com/chwthewke/sbt-typelevel-updateSbtClassifiers
Thanks in advance

introduced by https://github.com/sbt/sbt/pull/2703 @milessabin and impacts sbt-ensime

I'm pretty sure https://github.com/sbt/sbt/issues/2786 and the conversation therein is relevant to this issue and how to go about to fix it.

A workaround:
scalaOrganization in updateSbtClassifiers := "org.scala-lang"

Ha! Nice, I'll try that

Still a problem with SBT 1.0.2.
I used the following workaround:
scalaVersion in updateSbtClassifiers in ThisBuild := "2.11.11"
scalaOrganization in updateSbtClassifiers in ThisBuild := "org.scala-lang"

@sp-niemand I had a similar problem, but to get things to work with intellij, I had to remove the in ThisBuild part.  That may mess things up I'm not expecting, but since it's still only in updateSbtClassifiers I think it'll be okay.


Sign_In and Sign_Up

Designing the Frontend of Sign_In and Sign_Up on the DietMe website and applying CSS to them

Done Frontend


[META] Release 2.0.0 version for clients

This is a meta issue for tracking the release for 2.0.0 version for the clients.

[x] opensearch-java - https://github.com/opensearch-project/opensearch-java/issues/159
[x] opensearch-py - https://github.com/opensearch-project/opensearch-py/issues/166
[x] opensearch-ruby - https://github.com/opensearch-project/opensearch-ruby/issues/68
[x] opensearch-js - https://github.com/opensearch-project/opensearch-js/issues/245
[x] opensearch-go - https://github.com/opensearch-project/opensearch-go/issues/110
[x] opensearch-php - https://github.com/opensearch-project/opensearch-php/issues/56
[x] opensearch-dsl-py -  https://github.com/opensearch-project/opensearch-dsl-py/issues/50
[x] opensearch-rs - https://github.com/opensearch-project/opensearch-rs/issues/51

Targeted release dates for the clients:

Client
Target Release Date

opensearch-py
2022-05-26

opensearch-js
2022-05-26

opensearch-go
2022-05-26

opensearch-ruby
2022-05-31

opensearch-java
2022-05-31

opensearch-rs
2022-06-01

opensearch-dsl-py
2022-06-01

Clients released for 2.0.0:
opensearch-go

https://github.com/opensearch-project/opensearch-go/releases/tag/v2.0.0

opensearch-php
https://packagist.org/packages/opensearch-project/opensearch-php
https://github.com/opensearch-project/opensearch-php/releases/tag/2.0.0
opensearch-ruby

https://rubygems.org/gems/opensearch-ruby/versions/2.0.0
https://rubygems.org/gems/opensearch-api/versions/2.0.0
https://rubygems.org/gems/opensearch-transport/versions/2.0.0
https://rubygems.org/gems/opensearch-dsl/versions/0.2.0
https://github.com/opensearch-project/opensearch-ruby/releases/tag/v2.0.0

opensearch-py

https://pypi.org/project/opensearch-py/2.0.0
https://github.com/opensearch-project/opensearch-py/releases/tag/v2.0.0

opensearch-java

https://repo1.maven.org/maven2/org/opensearch/client/opensearch-java/2.0.0/
https://github.com/opensearch-project/opensearch-java/releases/tag/v2.0.0

opensearch-js

<EMAIL_ADDRESS>https://github.com/opensearch-project/opensearch-js/releases/tag/2.0.0

opensearch-rs

https://crates.io/crates/opensearch/2.0.0
https://github.com/opensearch-project/opensearch-rs/releases/tag/v2.0.0

opensearch-dsl-py

https://pypi.org/project/opensearch-dsl/2.0.1/
https://github.com/opensearch-project/opensearch-dsl-py/releases/tag/v2.0.0


Improvements to APIView/Java tooling

A number of fixes to the Java APIView tooling, discovered and developed as I went about creating APIView reviews for the Java Semantic Kernel library. You can see the generated APIView reviews for these libraries here:
https://apiview.dev/Assemblies/Review/8aa5b4eae87c47a9996bf9c80163812e
https://apiview.dev/Assemblies/Review/f52ac2e951734ee0a2c010481892fe32
https://apiview.dev/Assemblies/Review/73736094cf044f70b82a0618a97776f4
Here are the changes I have made:

Support for when a pom.xml does not explicitly state a groupId or version - look up in parent, if it is available.
Don't analyse files in META-INF, as some builds put .java files in there, and they are not always valid Java.
Fixing issue where not all inner types are discovered when calling getClasses. This also resulted in some additional bugs being identified in diagnostics, where the reported issue was at the parent type rather than the child type, so I fixed those.
Add new diagnostic to warn developers to use proper casing for enum constant values.
Made it so that Azure SDK specific errors are only applied to libraries with com.azure package namespaces.

Merging now - Praveen has offered to do the version increments when he does the next APIView release.


Unable to create afdEndpoints with missing parameter error although parameter is exist in Bicep file

Bicep version
Bicep CLI version 0.4.1272 (a69022dd2c)
Describe the bug
When I define autoGeneratedDomainNameLabelScope paramater in 'Microsoft.Cdn/profiles/afdEndpoints@2021-06-01' resource I see below error
{"status":"Failed","error":{"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.","details":[{"code":"BadRequest","message":"{\r\n  \"error\": {\r\n    \"code\": \"InvalidResource\",\r\n    \"message\": \"The request field is required. Could not find member 'autoGeneratedDomainNameLabelScope' on object of type 'AfdEndpoint'. Path 'properties.autoGeneratedDomainNameLabelScope', line 1, position 108.\",\r\n    \"target\": null\r\n  }\r\n}"}]}}
Here is my code which is getting error.
resource frontDoor 'Microsoft.Cdn/profiles@2021-06-01' = {
  name: profileName
  location: frontDoorLocation
  tags: tags
  sku: {
    name: skuName
  }
  properties: {
    identity: {
      type: frontDoor_properties.identity.type
    }
    originResponseTimeoutSeconds: frontDoor_properties.originResponseTimeoutSeconds
  }
}

resource endpoint 'Microsoft.Cdn/profiles/afdEndpoints@2021-06-01' = {
  name: afdEndpoints.name
  parent: frontDoor
  location: frontDoorLocation
  tags: tags
  properties: {
    autoGeneratedDomainNameLabelScope: 'NoReuse'
    enabledState: afdEndpoints.properties.enabledState
  }
}

Below is the code snippet that works perfectly as expected
resource frontDoor 'Microsoft.Cdn/profiles@2021-06-01' = {
  name: profileName
  location: frontDoorLocation
  tags: tags
  sku: {
    name: skuName
  }
  properties: {
    identity: {
      type: frontDoor_properties.identity.type
    }
    originResponseTimeoutSeconds: frontDoor_properties.originResponseTimeoutSeconds
  }
}

resource endpoint 'Microsoft.Cdn/profiles/afdEndpoints@2021-06-01' = {
  name: afdEndpoints.name
  parent: frontDoor
  location: frontDoorLocation
  tags: tags
  properties: {
    enabledState: afdEndpoints.properties.enabledState
  }
}

To Reproduce
Steps to reproduce the behavior:
az deployment group create --name sampledeployment--resource-group frontdoor --template-file front-door.bicep   --parameters @front-door.parameters.json
Additional context
Usage of autoGeneratedDomainNameLabelScope parameter  were explicitly defined in below documentation
https://docs.microsoft.com/en-us/azure/templates/microsoft.cdn/profiles/afdendpoints?tabs=bicep#afdendpointproperties
And here is the url of Microsoft.Cdn/profiles/afdEndpoints@2021-06-01  template included autoGeneratedDomainNameLabelScope parameter
https://docs.microsoft.com/en-us/azure/templates/microsoft.cdn/profiles/afdendpoints?tabs=bicep#template-format

Does not look to be a bicep specific issue. This is coming from the adfEndpoint API. I'm going to move this to a discussion in case someone knows why ADF is throwing this error, but the best thing to get a concrete answer would be to open a support case and get it routed to the ADF team.


Error after reload

Hi
Editing an old style csproj file I receive attached image after project is reloaded ...
I am using vs2022

Regards

Hi @tdsrhh, this is a known behavior (or expected behavior). Because VS doesn't allow openning an old style csproj file in editor, the workaound EditProject used is, creating a temp file (which is printed in your screenshot) for it and use VS edit the temp file, and watching the temp file, once it's changed, replace the csproj file with it. For the whole process to work, the extension needs to maintain a few mapping status and events in memory, if VS reboot, all these data are lost.


Cannot read property '$swiper' of undefined

code:
import { Swiper, SwiperSlide, directive } from 'vue-awesome-swiper'
import 'swiper/css/swiper.css'

<swiper ref="mySwiper">
......
</swiper>

computed: {
      swiper () {
        return this.$refs.mySwiper.$swiper
      }
},
activated () {
      this.swiper.slideNext(1000)
}

error:

vue.esm.js?65d7:628 [Vue warn]: Error in activated hook: "TypeError: Cannot read property '$swiper' of undefined"

According to the official instructions configuration, do not know why can not find

beacuse of different version, when i use v3.1.3, it's swiper, when i use v4.1.1, it's $swiper

Getting the same error in 4.1.1. Have tried .swiper and .$swiper with no luck

Is there any solution ? I got same error. I m using nuxt js.

Swiper version :  "vue-awesome-swiper": "^4.1.1",

Any update on this?

+1

Is there any solution ? I got same error. I m using nuxt js.

Swiper version : "vue-awesome-swiper": "^4.1.1",

It’s not a bug. $swiper instance appears on “mounted” hook, but “computed” calculates some early. Also using $refs in computed is not good idea, cause it’s not reactive var, so computed going not to recalc after $swiper instance change.
Use something like
mounted () {
this.swiperInstance = this.$swiper
}

现在解决了吗？

现在解决了吗？

要指定下载对应的版本，swiper5.x,另外vue-awesome-swiper4.x,应该就好了，不然问题一堆，感觉吧swiper不友好，很多莫名的bug，居然还没有vue2.x的swiper对应教程demo,研究起来累。

现在解决了吗？

要指定下载对应的版本，swiper5.x,另外vue-awesome-swiper4.x,应该就好了，不然问题一堆，感觉吧swiper不友好，很多莫名的bug，居然还没有vue2.x的swiper对应教程demo,研究起来累。
我发现了，不能写在v-if里
只要外面任何一层套了v-if, 就拿不到$swiper


Version 1.1.1, Add nuget target .NETPlatform5.0, New project for Dotnet target, Upgrade Nuget

This allow the use of the lib in projects using Dotnet 5, Asp.net5, Dnxcore50

@omar Please review

Apologies for the delay. This has been published. Thank you for the contribution.

Thanks !


Support Distributed writes with EEL

Support Distributed writes with EEL

N writers via JdbcSource -> KafkaSink
N Writers via HiveSink/KuduSink/HBaseSink
Now what if the HiveSink and others that use a LinkedBlockingQueue to service multiple writer threads could do this in a distributed fashion by wrapping the LinkedBlockingQueue interface, i.e. an implementation that wraps a Kafka topic - default one would still remain as threads?
The gotcha is that when you  are out-of-process you lose control on how to partition the data into reasonable sizes
However for row oriented storage systems like Kudu and HBase it's perfect - the same usage pattern would even work for the JdbcSink

What do you think?

I don't understand sorry. At the moment HiveSink has multiple writers, through multiple threads. Are you meaning something else?

Probably not such a great idea as there maybe better approaches.
I understand the multiple thread writers but what if you could flip a switch to share the writes over stateless worker processes, i.e. spin up Kafka/YARN workers

Each YARN worker accepts rows over say Kafka and uses EEL to write

You can, but its then no longer a standalone in process API and turning more into spark.


Fix API endpoints for related media and provider stats

Fixes

This PR fixes the endpoints to fetch related media, updates to use the new endpoints for provider stats, and removes fallback default provider data that was hardcoded into the repo, which can give false assurances that things are working.
We'll need to test API changes on the front-end much more closely moving forward.
Noting that in production, the related API endpoint is still seemingly broken, although my local instance of the API is working.
Description

Some additional low-hanging cleanup here:

Fix audio endpoints from 'audios' to 'audio'
Remove unused provider collection endpoints
Add some jsdoc annotations for axios
Fix error handling of getProviderStats, which wouldn't actually catch exceptions
Start the work to make the Sources page media-type agnostic (it still doesn't actually fetch the audio providers)

Testing Instructions

Run locally and observe the provider list on the 'sources' page and in the results filter sidebar is visible.
Run tests and ensure they work
Bonus: Run a local instance of the API and change the nuxt.config.js to point to it (don't forget v1 at the end of the endpoint!). Confirm that locally configured sources are visible.

Checklist

[x] My pull request has a descriptive title (not a vague title like Update index.md).
[x] My pull request targets the default branch of the repository (main) or a parent feature branch.
[x] My commit messages follow best practices.
[x] My code follows the established code style of the repository.
[ ] I added or updated tests for the changes I made (if applicable).
[ ] I added or updated documentation (if applicable).
[x] I tried running the project locally and verified that there are no visible errors.

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

I get the 400 error for related endpoint, it is caused by pagination error in the API:
https://github.com/WordPress/openverse-api/blob/13673ee8c196c9a6b786a1322d6d65b97c6ca708/openverse_api/catalog/api/utils/pagination.py#L29


Request-level dashboard

Let me know how you want to add more detail here, should we get on a call with Duygu for this?

I added request level filtering to the sample table so you can now display all samples associated with a reqest. We can demo this and add a new story if there's anything else required.