Gamma optimizations and benchmarks

Turns out that pre-computing constants and type-hinting functions has a big performance gain:

(gamma 2.5) 77.40% speedup (execution mean 4.889986 µs → 1.104972 µs)
(log-gamma 10) 63.92% speedup (execution mean 4.845715 µs → 1.748155 µs)
(log-gamma-1p -0.05) 76.86% speedup (execution mean 4.981068 µs → 1.152443 µs)
(inv-gamma-1pm1 -0.05) 77.85% speedup (execution mean 4.582663 µs → 1.015241 µs)
(lanczos-approximation 170) 73.15% speedup (execution 4.276010 µs → 1.148002 µs)

Did this for math.gamma and math.utils. Also experimenting with a way to define and run benchmarks like tests: Benchmarks are defined in the /benchmark directory, then functions to benchmark are tagged with ^:benchmark and profiled with Criterium. Just run bb benchmark:clj to compute benchmarks! See gamma_benchmark.cljc for an example.

@sritchie I addressed the comments and benchmark now ride on test runner, boom.
I'm assuming that when a benchmark test runs, we want it to fail if it diverged within some threshold of a baseline. To define a baseline, it seems reasonable to have something like this:
(def ^:no-doc ^:const lanczos-approximation-baseline
  [{:n 15
    :x 9
    :mean 3.127368933269932E-6
    :variance 1.5780434242573877E-14
    :lower-q 2.984515105404977E-6
    :upper-q 3.320172412426692E-6}
   {:n 15
    :x 100
    :mean 2.0160584455226908E-7
    :variance 7.928671640576774E-18
    :lower-q 1.9907849968797706E-7
    :upper-q 2.0489675953499433E-7}
   {:n 15
    :x 170
    :mean 2.040524636004644E-7
    :variance 5.795520133553684E-18
    :lower-q 2.0120967339244923E-7
    :upper-q 2.0719692107157572E-7}])

and then the actual benchmark test just maps over entries in the baseline and runs crit/quick-benchmark, like so:
(deftest ^:benchmark lanczos-approximation-benchmark
  []
  (let [f (fn[b]
            (let [n (:n b)
                  x (:x b)
                  mean (:mean b)
                  variance (:variance b)
                  lower-q (:lower-q b)
                  upper-q (:upper-q b)
                  stats (crit/quick-benchmark
                         (dotimes [_ n]
                           (g/lanczos-approximation x)) {})]
              (testing "against lanczos approximation baseline"
                (with-comparator (within 1e-3)
                  (is (ish? mean (first (:mean stats))) x)
                  (is (ish? variance (first (:variance stats))) x)
                  (is (ish? lower-q (first (:lower-q stats))) x)
                  (is (ish? upper-q (first (:upper-q stats))) x)))))]
    (run! f lanczos-approximation-baseline)))
    ```

    This is implemented right now, so you can run `bb benchmark:clj` to see it work.

@sritchie yep, i responded—lmk if that explanation about :benchmark metadata makes sense!

💥


omniscient player

Current coverage is 93.07% (diff: 15.62%)

Merging #109 into master will decrease coverage by 6.92%

@@           master       #109   diff @@
========================================
  Files          10         11     +1
  Lines         358        390    +32
  Methods         0          0
  Messages        0          0
  Branches        0          0
========================================
+ Hits          358        363     +5
- Misses          0         27    +27
  Partials        0          0

Powered by Codecov. Last update 944e824...af5b97e


Wrong color types for buffers when decoding for plain pbm and pam BW

Follow-up to #794 and #796 , implement the fixes there for the other decoders returning color types with depth of 1. Blocked by #799 which also changes the pbm ascii decoder.

@philipc I would integrate this as well and would ask you to review when it is ready.

This affects read actions that return color type Gray(1) but at the same time return a byte for each bit instead of packing them by-line. We should probably update documentation in DecodingResult to make this clearer.


How to generate annotations_attributes for custom dataset

Hello, great work @ykotseruba and team!
I was trying to use the piepredict model on custom dataset to predict pedestrian intention,but I am not sure how did you generate the annotation_attributes.zip (under pi dataset),using cvat tool.
I was able to generate the annotations using cvat tool ,but I am wondering how to get annotation_attributes.
Any suggestion is greatly appreciated!
Thanks.

Hi @poornimajd,
You don't need to use cvat to create attribute annotations. You can make a table (e.g. excel spreadsheet) and then convert it to XML or create an XML directly. For each pedestrian track, you need to define a set of attributes as explained in PIE annotations readme. If some of the attributes are missing in your dataset, provide a dummy value to avoid modifying the pie_data.py interface.

Thanks for the quick and detailed reply!


estimated time for TODOs

Hi Scott. First off, I just wanted to extend a thanks for your work. Great job. Second part was curious to know your timeline for implementation of these two features?

fully implement the reporting API
implement all available CRUD API calls

I think after baking these two features, especially the remaining CRUD it will be locked and ready to go. This will lead into a second issue I will open.

I'm looking at the project as free time permits.  Recruiting a little help will help ;-)  As this is my first API client, I'm thinking about whether to just go down the path of wrapping a function around every API call or making the client a little higher level and easier to use.
I suppose, as I put this in writing, implementing all the API calls comes first, and then taking the implementation up a level with some higher level capabilities comes next.  Thoughts?
Do you have any good resources for the "right" way to implement a robust api client that's maintainable over time?

@scottbri this is more of a CLI than an API Client.
I wouldn't worry about wrapping a function around every API because that would be way too much time. I would pick the top 10 or 20 that are going to be used the most. After that, you should have a basic boiler plate that if people see this later it should be relatively easy for them to add in those methods.
I'm not sure what higher levels you are talking about, so I can't really give you a direction or advice. :)
As for doing things the "right" way, there is no standard way. The most standard way to do things is to go Prog -> Noun -> Verb -> Adverb or Options
Such as pyvmax create volume --size 10 --iops 2000 or whatever it would be. As for maintainability, just take care of as many methods/APIs as you can and it should be able to pick up legs if people want to use it. APIs will be added and deprecated over time. Nature of the way things are.
Keep up the good work.

Mwahahaha
I've implemented about 90% of all the API calls at this point.


Support for additional dev boards

Can you please consider adding support for the following boards:
ESP-WROVER-KIT with 320x240 SPI without touch
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/hw-reference/esp32/get-started-wrover-kit.html
Makerfabs ESP32-S3 with 480x320 parallel 3.5"
https://www.makerfabs.com/esp32-s3-parallel-tft-with-touch-ili9488.html

@ammaree
For WROVER_KIT, create a file called conf_wrover_kit.h in the main folder and with below content. LovyanGFX should autodetect the board LCD + Touch with this.
// filename 'conf_wrover_kit.h'

#define LGFX_ESP_WROVER_KIT        // ESP-WROVER-KIT

// Portrait
#define TFT_WIDTH   320
#define TFT_HEIGHT  480

#define TOUCH_ENABLED
#define SD_ENABLED

#include <LovyanGFX.h>
#include <LGFX_AUTODETECT.hpp>

Please keep in mind, I don't have these boards so its untested.
For SD card using shared SPI bus, you should check the file inside main folder called helper_storage.hpp

@sukesh-ak
Just remember the ESP-WROVER-KIT does not have any touch.
As far as SD is concerned have not used up to now, believe there might be hardware/pins conflict between LCD and SDcard?

@sukesh-ak
Just remember the ESP-WROVER-KIT does not have any touch.
As far as SD is concerned have not used up to now, believe there might be hardware/pins conflict between LCD and SDcard?

SD card works with LCD with shared SPI using a different CS PIN for both.
You can see an example here.
https://github.com/sukesh-ak/ESP32-LVGL8x-SDSPI/blob/master/main/conf_FeatherS3_ILI9341.h

I worked with @lovyan03 to fix a bug related to shared SPI bus earlier. So it works.
https://github.com/lovyan03/LovyanGFX/issues/248

@ammaree
I have added a request for Makerfabs ESP32-S3.
https://github.com/lovyan03/LovyanGFX/issues/285
If this is done, it will be easy like above without much configuration.

Thanks


Correction for raw affiliation Université Côte d'Azur, Inria, France

Correction needed for raw affiliation Université Côte d'Azur, Inria, France
raw_affiliation_name: Université Côte d'Azur, Inria, France
new_rors: 019tgvf94
previous_rors:
works_examples: W2555293749;W2510523461;W2560412331;W2512578409
contact: c75acaa530d16ece21aa371ca258e057:54f96c919cffae92b0f4423284 @ univ-cotedazur.fr

This issue was accepted and ingested by the OpenAlex team on 2024-10-10. The new affiliations should be visible within the next 7 days.


Problem: inconsistent bucket configuration across components

Describe the bug
Enduro bootstraps instances of *blob.Bucket in several places, e.g. watcher, upload or location. *blob.Bucket is an abstraction provided by gocloud.dev that we've adopted to interact with blobstore.
These are some issues observed with the current approach:

Lack of a shared configuration struct embeddable in different contexts (appconfig, databases, etc),
Lack of support for URL-based buckets (useful during testing, e.g. mem:// or simpler config),
Use of AWS SDKv1 (end of support announced), should use v2 instead!

Additional context
I'm planning to suggest the introduction of a new bucket package providing a shared configuration struct and a simple function to open a *blob.Bucket given such configuration. Future iterations could focus on deeper integration with the new facilities, e.g. watcher.MinioConfig to make use of the new config struct to define the bucket configuration.

I think you solved this issue @sevein but, could this package be moved to the gotools repository? I think it will be useful for other projects.

Could this package be moved to the gotools repository? I think it will be useful for other projects.

Done<EMAIL_ADDRESS>


Added Language support for Hindi in language selection dropdown

My First Pull Request to this Project !

Added a new option for Hindi Language in language selection dropdown in bottom right corner.

On selecting the hindi Option from the dropdown,the tooltip text for encryption shield icon (bottom left ) changes to hindi text.

Please suggest any changes . Thank you.

Hey! Could you update this PR? The translations are ready.


Add an option for executing timeout

Checklist

[X] I have filled out the template to the best of my ability.
[X] This only contains 1 feature request (if you have multiple feature requests, open one feature request for each feature request).
[X] This issue is not a duplicate feature request of previous feature requests.

Is your feature request related to a problem? Please describe.
My chime_tts runs, and it generates the cache file, but it stops because of error
 Service call to chime_tts.say timed out after 15 seconds.

Describe the solution you'd like
Because of the machine which I'm running homeassistant isn't powerful enough
I notice in the source code, the 15 second timeout is constant
result = await asyncio.wait_for(task, 15)

maybe can provide a property timeout  in options to overwrite the default 15 seconds
Describe alternatives you've considered
Not applicable
Additional context
Not applicable

Hi @iapYang, that you for your feedback. I have included in the latest version (v0.9.0) an option to adjust the timeout in the configuration dialog for Chime TTS:

You can view the configuration dialog by navigating to:
Settings --> Devices & services --> Chime TTS --> CONFIGURE
Please let me know if this addresses the issue 👍

@nimroddolev thanks a lot, it works! I'm gonna close this issue.


Possible bug in getCrossCheckMatches

I got the following images using getCrossCheckMatches. There seems to be a bug because it should be strictly impossible for two matches to contain the same keypoint, since the crosscheck implies they are the mutually best result. The only explanation would be that the keypoints have strictly the same score.

Additionnally, I accidentally inverted some variables in the crosscheck function. It should be fixed now.

The bug was that when doing the crosscheck match, the variable names are inverted. I compared both sourceIndex and both destinationIndex instead of crossing them.


SoftwareTrigger is in the wrong module

I just noticed that SoftwareTrigger is in the instrument module, which is not the right place for it. Instrument is for the software model that describes the hardware, not for algorithms.  It should go into its own module perhaps.
This could happen during the larger module refactoring in CEP-4 #2489
This is also related to #2606 , where we might want to have a selectable set of algorithms for software triggering.

As a side note, is this really required for prod6 and beyond? There should be flag set describing the trigger type and one would select those events only with LST hardware trigger set (to e.g., suppress the few mono LST trigger in the simulation files)


Provide a service ingest-api can use to validate an upload

This could be a modified version of the existing call.  It needs to:

provide a workflow name for the new facility
the call will include an 'upload' rather than a 'dataset'
after testing, the run needs to return the results via an API call on ingest-api

The part of app.py making the incoming call is: https://github.com/hubmapconsortium/ingest-api/blob/9a22f8724af0d4685c1723cb743feabb9619a926/src/app.py#L1377-L1401

Waiting on a PR review


Can't use nested dictionaries

Can't add nested dictionaries to the replit database.

Sorry I'm going to fix this bc it's sending it as data so it needs to be a str so I'll make it auto convert you'll need to import json and use json.loads(client.view()) to get the json but it I don't encode everything as strs it will break

When I do json.loads(client.view()) with the key name as the argument, it still doesn't work.

yes bc rn it passes exactly what you sent im going to make it stringify it first now

has been fixed in 0.0.13 (no longer use json.loads it auto does that)

make sure to update the package tho (on repl remove  and then add the package in the package tab)

that version broke ill try to fix

release should be fixed

error has not been fixed miscall

finally been fixed lol

make sure your on <IP_ADDRESS>

Ok, so fixed.


Local Testing (with GTX1080) - error creating driver: failed to create device library: failed to locate driver libraries: error locating "libnvidia-ml.so.1"

Hi,
I was following the tutorial to get DRA running and so initially everything was working as expected until the installation of the driver.
The kubelet plugin directly fails with:
Error: error creating driver: failed to create device library: failed to locate driver libraries: error locating "libnvidia-ml.so.1"

Some extra information:
In order for the cluster to be able to mount the cdi device, I needed to change the name/path from runtime.nvidia.com/gpu/all to nvidia.com/gpu/all as I only see this as CDI device.
➜  k8s-dra-driver git:(main) ✗ sudo nvidia-ctk cdi list
INFO[0000] Found 1 CDI devices
nvidia.com/gpu=all

Here some details about my setup:
GPU: GTX 1080
OS: Windows/WSL
nvidia-container-toolkit version:
NVIDIA Container Toolkit CLI version 1.17.0
commit: 5bc031544833253e3ab6a36daec376dc13a4f479

runtime config:
➜  k8s-dra-driver git:(main) ✗ nvidia-ctk runtime configure --dry-run
INFO[0000] Loading config from /etc/docker/daemon.json
{
    "default-runtime": "nvidia",
    "runtimes": {
        "nvidia": {
            "args": [],
            "path": "nvidia-container-runtime"
        }
    }
}

nvidia-smi command on host:
➜  k8s-dra-driver git:(main) ✗ nvidia-smi
Tue Nov 12 20:54:32 2024
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 565.57.02              Driver Version: 566.03         CUDA Version: 12.7     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce GTX 1080        On  |   00000000:01:00.0  On |                  N/A |
|  0%   58C    P0             45W /  210W |    1907MiB /   8192MiB |      3%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI        PID   Type   Process name                              GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|  No running processes found                                                             |
+-----------------------------------------------------------------------------------------+

nvidia-smi command on node:
root@k8s-dra-driver-cluster-worker:/# nvidia-smi
Tue Nov 12 19:55:46 2024
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 565.57.02              Driver Version: 566.03         CUDA Version: 12.7     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce GTX 1080        On  |   00000000:01:00.0  On |                  N/A |
|  0%   61C    P0             46W /  210W |    1903MiB /   8192MiB |      3%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI        PID   Type   Process name                              GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|  No running processes found                                                             |
+-----------------------------------------------------------------------------------------+

Any help would be highly appreciated!
I already saw a similar behavior in this issue, but it s not the same: https://github.com/NVIDIA/k8s-dra-driver/issues/65

After some more investigation and adjusting the cdi file manually I have now the following problem:
➜  k8s-dra-driver git:(main) ✗ k logs -n nvidia nvidia-dra-driver-k8s-dra-driver-kubelet-plugin-5pzdd
Error: error creating driver: error enumerating all possible devices: error enumerating GPUs and MIG devices: error initializing NVML: Not Supported

My current /etc/cdi/nvidia.yaml looks as follows - with the containerPaths manually adjusted:
cdiVersion: 0.3.0
containerEdits:
  env:
  - NVIDIA_VISIBLE_DEVICES=void
  hooks:
  - args:
    - nvidia-cdi-hook
    - create-symlinks
    - --link
    - /usr/lib/wsl/drivers/nvmdi.inf_amd64_8de72197f4c7fa03/nvidia-smi::/usr/bin/nvidia-smi
    hookName: createContainer
    path: /usr/bin/nvidia-cdi-hook
  - args:
    - nvidia-cdi-hook
    - update-ldcache
    - --folder
    - /usr/lib/wsl/drivers/nvmdi.inf_amd64_8de72197f4c7fa03
    - --folder
    - /usr/lib/wsl/lib
    hookName: createContainer
    path: /usr/bin/nvidia-cdi-hook
  mounts:
  - containerPath: /usr/lib64/libdxcore.so
    hostPath: /usr/lib/wsl/lib/libdxcore.so
    options:
    - ro
    - nosuid
    - nodev
    - bind
  - containerPath: /usr/lib64/libcuda.so.1.1
    hostPath: /usr/lib/wsl/drivers/nvmdi.inf_amd64_8de72197f4c7fa03/libcuda.so.1.1
    options:
    - ro
    - nosuid
    - nodev
    - bind
  - containerPath: /usr/lib64/libcuda_loader.so
    hostPath: /usr/lib/wsl/drivers/nvmdi.inf_amd64_8de72197f4c7fa03/libcuda_loader.so
    options:
    - ro
    - nosuid
    - nodev
    - bind
  - containerPath: /usr/lib64/libnvdxgdmal.so.1
    hostPath: /usr/lib/wsl/drivers/nvmdi.inf_amd64_8de72197f4c7fa03/libnvdxgdmal.so.1
    options:
    - ro
    - nosuid
    - nodev
    - bind
  - containerPath: /usr/lib64/libnvidia-ml.so.1
    hostPath: /usr/lib/wsl/drivers/nvmdi.inf_amd64_8de72197f4c7fa03/libnvidia-ml.so.1
    options:
    - ro
    - nosuid
    - nodev
    - bind
  - containerPath: /usr/lib64/libnvidia-ml_loader.so
    hostPath: /usr/lib/wsl/drivers/nvmdi.inf_amd64_8de72197f4c7fa03/libnvidia-ml_loader.so
    options:
    - ro
    - nosuid
    - nodev
    - bind
  - containerPath: /usr/lib64/libnvidia-ptxjitcompiler.so.1
    hostPath: /usr/lib/wsl/drivers/nvmdi.inf_amd64_8de72197f4c7fa03/libnvidia-ptxjitcompiler.so.1
    options:
    - ro
    - nosuid
    - nodev
    - bind
  - containerPath: /sbin/nvcubins.bin
    hostPath: /usr/lib/wsl/drivers/nvmdi.inf_amd64_8de72197f4c7fa03/nvcubins.bin
    options:
    - ro
    - nosuid
    - nodev
    - bind
  - containerPath: /sbin/nvidia-smi
    hostPath: /usr/lib/wsl/drivers/nvmdi.inf_amd64_8de72197f4c7fa03/nvidia-smi
    options:
    - ro
    - nosuid
    - nodev
    - bind
devices:
- containerEdits:
    deviceNodes:
    - path: /dev/dxg
  name: all
kind: nvidia.com/gpu

@wenzel-felix one thing to note is that you're running on WSL2 which has not been tested in the context of the k8s-dra-driver. There also seems to be unexpected behaviour using the runtime.nvidia.com/gpu=all device in the NVIDIA Container Runtime for this case.
In order to provide some more context, could you confirm how you are installing docker? Are you running docker-ce in your WSL2 distribution, or are you using Docker Desktop?

Hi @elezar , I'm aware that it was not tested with WSL2, I was just investigating myself if I could get it running.
I'm using docker-ce in WSL2 - installed according to the official docker installation.
➜  ~ apt-cache policy docker-ce
docker-ce:
  Installed: 5:27.3.1-1~ubuntu.22.04~jammy
  Candidate: 5:27.3.1-1~ubuntu.22.04~jammy
  Version table:
 *** 5:27.3.1-1~ubuntu.22.04~jammy 500
        500 https://download.docker.com/linux/ubuntu jammy/stable amd64 Packages
        100 /var/lib/dpkg/status

I just thought it would be an interesting use case for easy showcasing the basic DRA feature as some probably run Windows with WSL2.
So, if you deem it not interesting we can also close the issue 👍🏼


Filter takes time to apply

Hi, such a nice library for image editing.
I am facing one issue, While image edit with "Filter" option, it's taking time to apply selected filter on image(about 1 min). can you help me with this?
Thanks in advance

You should provide, OS version, device version, any filter information.

it's not working with iOS 11
i have attached screenshot

Simulator ?
Cordialement,
Claude Bezeaud.

Le 9 nov. 2017 à 07:18, pinkal<EMAIL_ADDRESS>a écrit :
it's not working with iOS 11
i have attached screenshot
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

On real device it’s working like a charm
Cordialement,
Claude Bezeaud.

Le 9 nov. 2017 à 07:18, pinkal<EMAIL_ADDRESS>a écrit :
it's not working with iOS 11
i have attached screenshot
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

The processing of filter tool is very heavy in the simulator. Please try with real device.


Command::new("clear") panics on windows, consider using crossterm?

Windows uses cls, so one hacky solution would be to use conditional compilation to run Command::new("cls") when building for windows. Using the crossterm crate for that instead is probably ideal, though. crossterm would also get you other features like the alternate screen and better input handling for your menus.

Yes, maybe it's a good solution. Do you want to make a pull request? I will look at the crossterm crate for more info about it.

Sure, I could work on that. It might be a few days at least before I find the time, though

Ok, awesome. If you need something let me know.


F# Support

I would love to be able to publish my F# projects using this library! (Currently it can't find the project)

Sure, I'll get it done 👍

You are a legend, however F# using PackageVersion instead of Version (so your version regex is out of date), I have also noticed if I do a series of commits and then push it will sometimes fail to detect the change and upload (I believe this is due to the use of the diff to get the version difference)

You are a legend, however F# using PackageVersion instead of Version (so your version regex is out of date)

The regex looks at Version as it's the most commonly used one, do you actually intend for a Version & PackageVersion divergence? 😕

I have also noticed if I do a series of commits and then push it will sometimes fail to detect the change and upload (I believe this is due to the use of the diff to get the version difference)

Got it, a fix is on the way 🔧


Test bruteforce - fix relaxedMode in unary.cpp

Fixes #817

Travis builds are passed . Looks like status cannot be refreshed.


http response after POST

Hi,
When I send a feature through the Http Post, the widget get the correct update, but it does not send any response,  so the application that send the post detect it as a "Error connecting to HTTP server"
Thanks

I have a widget which submits data via HTTP POST, triggered by JavaScript in the user's browser -- it works fine for me.
How are you sending the request and what kind of response are you expecting back?
This is the response header that my jQuery.post happily accepts, resolving the Deferred:
HTTP/1.1 204 No Content
Date: Wed, 20 May 2015 00:43:35 GMT
Server: thin
X-Content-Type-Options: nosniff
Content-Length: 0
Connection: close
Content-Type: text/plain; charset=UTF-8

Like @tylermauthe said, you should be receiving 204's:
https://github.com/Shopify/dashing/blob/master/lib/dashing/app.rb#L108

When I put a wrong auth_token, I receive the 404 status but when I send the correct one, the widget gets the update but my application (Mirth Connect) say failed, it could be possible that it is expecting a status 204 like the status 404 on failure.

If this application thinks that a 204 means failure, it is not interpreting HTTP correctly. Please submit a support request to them, this is not an issue with Dashing.
Thank you and good luck with your issue.


Issue for Running as CMD script in "Scripts to run whenever a user logs on for the first time" Section

When I copy my CMD lines for execution to "Scripts to run whenever a user logs on for the first time" section they get executed as powershell and not as batch. I can even see the PS window as opposed to the CMD one I could previously view. Tried to put the code in every box 1, 2, 3,and 4 and manually select "as a .cmd file." but the result is the same and gets executed as PS.
For .reg is OK, as I have a regkey that I also put in "Scripts to run whenever a user logs on for the first time" and sets "Visual Effects" to some custom settings and it gets applied on my test OS without any issue, as before.

Test OS is Windows 10 LTSC 2021

Browser from where I run the "Generate autounattend.xml files" service is Firefox

The autounattended.xml generator had no such issues approx. 2 week ago when I created an .xml and tested with same OS and same environment. Maybe it's related somehow to latest feature additions? I noticed some new features added lately.

Your observation is correct, but this is the intended behavior, which was introduced via https://github.com/cschneegans/unattend-generator/commit/dcf3ea46feb5aa82b562c4531f1a4475f57ce0bf.
Previously, you might have seen multiple windows popping up when a user logs on for the first time. All RunOnce commands (including those provided by custom scripts) are now run from a single PowerShell process. Furthermore, output from these commands is collected in %TEMP%\UserOnce.log for debugging purposes.
.reg and .cmd custom scripts are still properly executed, and your autounattend.xml file will contain elements like these:
<RunSynchronousCommand wcm:action="add">
  <Order>…</Order>
  <Path>reg.exe load "HKU\DefaultUser" "C:\Users\Default\NTUSER.DAT"</Path>
</RunSynchronousCommand>
<RunSynchronousCommand wcm:action="add">
  <Order>…</Order>
  <Path>reg.exe add "HKU\DefaultUser\Software\Microsoft\Windows\CurrentVersion\RunOnce" /v "UnattendedSetup" /t REG_SZ /d "powershell.exe -NoProfile -Command \"Get-Content -LiteralPath 'C:\Windows\Setup\Scripts\UserOnce.ps1' -Raw | Invoke-Expression;\"" /f</Path>
</RunSynchronousCommand>
<RunSynchronousCommand wcm:action="add">
  <Order>…</Order>
  <Path>reg.exe unload "HKU\DefaultUser"</Path>
</RunSynchronousCommand>

<File path="C:\Windows\Setup\Scripts\UserOnce.ps1">
  & {
    Get-Content -LiteralPath 'C:\Windows\Setup\Scripts\SetColorTheme.ps1' -Raw | Invoke-Expression;
    Get-Content -LiteralPath 'C:\Windows\Setup\Scripts\SetWallpaper.ps1' -Raw | Invoke-Expression;
    reg.exe import "C:\Windows\Setup\Scripts\unattend-01.reg";
    C:\Windows\Setup\Scripts\unattend-02.cmd;
  } *>&1 >> "$env:TEMP\UserOnce.log";
</File>


Incorrect image size

Steps to Reproduce
Take an image with the example project, front camera and 4:3 aspect ratio.
Expected results
Using full sensor size for the image as in the stock camera application.
Actual results
Receive a cropped in image.
Comparison from the exact same spot:

About your device

Brand
Model
OS

Google
Pixel 6a
13

Your flutter version
Run this in your command line
Flutter 3.10.0 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 84a1e904f4 (3 months ago) • 2023-05-09 07:41:44 -0700
Engine • revision d44b5a94c9
Tools • Dart 3.0.0 • DevTools 2.23.1

Does anyone have any workaround for this at the moment to get the image using the full sensor?

Unfortunately, I have no workaround. I currently test the package for use in a project, and realized this same problem, I think. When using 16:9, it seems to work. Will there be a fix for this?
This is a great package, very impressive, really!

16:9 also not working. For bigger sizes phone camera displayed is bigger than 16:9

Any estimates for this issue, it's rly blocker

I'm having a fix but I'm not sure it's working on all phones.
The CameraX api has a little changed and I think that is the issue.

Hi @g-apparence,
I am currently experiencing a similar issue. Can you guide me on how to fix it?


show all station logos

its great that station logos are decoded form SPI :-)
It would be great if all station logos could be displayed:

32x32
112x32
128x128
320x240
600x600 (RadioDNS)

Also it would be fine if there is an indication where the logos come from (SPI or RadioRNS)

The second idea is good! We could add it to the mouser over text.
But regarding the pics: We already have them in all sizes, just see the temporary folder on your hard disk.

You can store all objects from SPI application to directory you can select. Timestamp is not supported as a tag, but you can see creation time a file size in filesystem. More info is here https://github.com/KejPi/AbracaDABra?tab=readme-ov-file#user-application-data-storage
Main goal of the app is still radio listening, not data collection and logging. I will follow this target also for future.


Laravel 11.x Compatibility

This is an automated pull request from Shift to update your package code and dependencies to be compatible with Laravel 11.x.
Before merging, you need to:

Checkout the l11-compatibility branch
Review all comments for additional changes
Thoroughly test your package

If you do find an issue, please report it by commenting on this PR to help improve future automation.

:warning: Shift detected a dependency for the laravel/framework. Unless you have a special requirement for depending on the entire Laravel framework, it's recommended to add dependencies for the specific illuminate packages instead.

:alembic: Using this package? If you would like to help test these changes or believe them to be compatible, you may update your project to reference this branch.
To do so, temporarily add Shift's fork to the repositories property of your composer.json:
{
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/laravel-shift/nova-translations-loader.git"
        }
    ]
}

Then update your dependency constraint to reference this branch:
{
    "require": {
        "optimistdigital/nova-translations-loader": "dev-l11-compatibility",
    }
}

Finally, run: composer update

@Tarpsvo would you mind taking a look at this PR to support Laravel 11 in this package? :)


Websocket invocation doc does not have information on using query params for auth

Description:
From apim version 3.0.0 onwards users can provide the access token for a websocket api invocation as a query parameter named "access_token". We need to add this to the documentation as an alternative way to invoke websocket apis.

Fixed in

https://github.com/wso2/docs-apim/pull/782/commits/64b1b1e5990b470bd0304fcdcdfc17fd0553ea3b
https://github.com/wso2/docs-apim/pull/782/
https://apim.docs.wso2.com/en/latest/learn/tutorials/create-and-publish-websocket-api/#step-3-invoke-a-websocket-api


Support AWS KMS for signing and verifying pipelines

Description
This adds AWS KMS support to pipeline signing, it is a work in progress and I am pushing this up for some feedback.
Context
To outline how this will look I have put together a list of commands with the new AWS KMS option added.
The updated agent start command with a KMS key alias which is used to sign and verify pipelines.
buildkite-agent start --signing-aws-kms-key alias/ES256test --debug --debug-signing

To upload and sign a pipeline with a specific AWS KMS key specified. Note this can be omitted if your key is configured in the agent.
buildkite-agent pipeline upload --signing-aws-kms-key alias/ES256test --debug-signing --debug .buildkite/pipeline.yaml

The updated sign and upload command stored in buildkite with a KMS key alias.
buildkite-agent tool sign --aws-kms-key alias/ES256test \
    --graphql-token bkua_XXXXX --organization-slug bk-whatever --pipeline-slug build-golang-sample \
    --update --debug --debug-signing

This table provides a mapping for the supported KMS KeySpec to JSON Web Algorithms (JWA).

"alg" Param Value
Digital Signature Algorithm
KMS KeySpec

ES256
ECDSA using P-256 and SHA-256
ECC_NIST_P256

ES384
ECDSA using P-384 and SHA-384
ECC_NIST_P384

ES512
ECDSA using P-521 and SHA-512
ECC_NIST_P521

RS256
RSASSA-PKCS1-v1_5 using SHA-256
RSASSA_PKCS1_V1_5_SHA_256

RS384
RSASSA-PKCS1-v1_5 using SHA-384
RSASSA_PKCS1_V1_5_SHA_384

RS512
RSASSA-PKCS1-v1_5 using SHA-512
RSASSA_PKCS1_V1_5_SHA_512

So to create a KMS key which supports JSON Web Algorithms (JWA) ES256 we run the following command. Note the --key-usage SIGN_VERIFY is required to support signing of pipelines.
aws kms create-key --key-spec ECC_NIST_P256 --key-usage SIGN_VERIFY

Changes

Testing

[ ] Tests have run locally (with go test ./...). Buildkite employees may check this if the pipeline has run automatically.
[ ] Code is formatted (with go fmt ./...)

Some nits for you

Amazing, I have been through and addressed all your feedback 🙇🏻


🚧 Dev ➾ Fix vsce workflow to correctly publish the extension for prerelease and release

🔗 Epic|Feature Link
No response
🚥 Definition of Done

[ ] 🎯 Planning and Design
[ ] 🏎 Dev Implementation
[ ] 🏁 Test Plan Executed
[ ] 🛩 Documentation Updated
[ ] 🏟 Peer / User Reviewed
[ ] 🏆 Validated and Accepted

✅ To Do

[ ] Update the vscode-extension.yml workflow and fix the condition on L96

🔭 Scope
No response
🧰 Work Description
Currently there is an issue with the workflow where the extension does not get published when we do a prerelease. This is because of the condition that checks if the event is a publish event. When we do a prerelease the event is a push.tag event and not a publish.
⚖ Acceptance Criteria

[ ] The extension is published when we do a prerelease

🎢 Test Plan
No response
🎆 Release Notes
No response
🦄 Sizing
1
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Done!


Make translate functionality optional and tree-shakable

This is improved version of the #99 which was merged and then reverted by #102 because this caused errors in app generated by generator-jhipster if i18n was disabled (TranslateService was not found in dependency injection).
If this change will be accepted and new version of ng-jhipster released then before new version can be used in generator-jhipster, the jhipster/generator-jhipster#10069 must be merged.
Starting from Angular 6 no more needed to include services in the module providers section.
Removing services from module providers section makes them tree-shakable (https://blog.angularindepth.com/tree-shakable-dependencies-in-angular-projects-5aaa7012b9e7).
If JHipster app is generated without i18n support then translation functionality is now excluded in this case.
Tested these ng-jhipster changes with jhipster/generator-jhipster#10069 and no errors found. Some notes from testing:

tested both with and without i18n
JhiLanguageService is now singleton (before every lazy loaded module had it's own version)
translation keys are now loaded only once (before every lazy loaded module downloaded it's own version)
TranslateService in JhiAlertService is now optional and is null in runtime if i18n is disabled, this is not problem because this is used only if i18nEnabled=true
JhiLanguageService is now not used at all if i18n is disabled so no need to add Optional to TranslateService
paging is working fine
alert is working fine

ping @wmarques
ping @vishal423

Nice ! I'll focus on my PR to be merged before and then we can merge yours, thanks :)

If i18n disabled then errors were in metrics page, because files under src/component/metrics are using jhiTranslate (in generated app this directive is removed if i18n is disabled) and so TranslateService must be Optional in JhiTranslateDirective.
I committed this fix.

Thanks @kaidohallik. You are really helping a lot on the angular part


Return Session Token from CloudCode

I don't know if this is the proper place, but this is the issue I'm having:
I want to implement my own authentication method (integrating with a 3rd party service), and for that I have Cloud Function that logs the user in and returns the session token, so that on the client I can call become and effectively log that user in.
Before I enabled revokable sessions this worked fine because I was able to get the user then call user.getSessionToken() and return it.
But after rovocable sessions were enabled the session tokens are always undefined.
The only solution I was able to find is to manually re-login the user in CloudCode, but in order to do that I needed to know the user's password.
So the only was I was able to do it was by changing the user's password to a new random string every login so I could do it in CloudCode and return the session token?
I don't think it is a very good solution and I'm sure there has to be a better way.
Thanks!

The issue is that with revocable sessions, the relationship between User and Session is one-to-many. Therefore, fetching a User object can't return a specific session token, because there are many.
Today, if you want to do what you're describing, you have to do something hacky with passwords like you describe (I recommend setting it to the unique identifier you typically receive from oauth-type services). However, enabling developers to easily implement their own third-party auth is something we're actively working on! It'll let you use cloud functions to perform third-party auth from your devices.

Thank you @andrewimm. I was previously creating a random password but the unique identifier is better since the password doesn't have to be changed.
Still if the user wanted to be able to login using traditional email/password this would be a problem, so looking forward to the future improvements.

I'm having a similar issue wherein I have  register and login methods defined in Cloud Code and accessing them on iOS/Android.
After logging in/registering, upto Parse SDK v1.5.0 I was able to get the Session Token via Parse.User.current()._sessionToken
But ever since updating post 1.6.x the sessionToken is undefined. Is there any way to use cloud code functions and have login and register functions to work?
In my opinion after successful login/registration via the .logIn or .signUp the returned user object should itself include sessionToken, I'm not sure why this isn't by default.


feat(tree): Implement TreeView v2 API

Description
Implements portions of the v2 schema evolution API which have general agreement. See #20450 for original proposal (which also has some APIs that aren't yet implemented).
See the changeset associated with this PR or adjustments to SharedTree documentation for details.

putting this in draft while I do actions outlined here.


This only works with the new version.

Fixes the image importer somewhat.

fudge, I don't think I noticed this pull request - I think I have the change implemented in base MPL, though, but let me know if it's not


Add a new "dumeta" command to compute table disk usage

This new command differs from the existing command in that it will scan
the Accumulo metadata table for files to compute the usage vs scanning
HDFS files on the file system.. The scan is also done on the client
side instead of on a tablet server. The new command should be
significantly faster than the existing version to compute disk usage
in large clusters.
This closes #2820

@EdColeman - Here is the version version of the new command. There could be some more enhancements done either on this PR or a follow on. Some other stuff we could add includes adding pagination to the command output, computing disk usage breakdown by tablets (if you think that's useful but may be too fine grained) and possibly renaming this command to be "du" and renaming the old one to something else.

I think it would be better to just add an option to the existing du command. It shouldn't be too difficult to make the existing command take an option called -meta that will perform this scan instead of the legacy one.

@milleruntime The basic question is there value in the current command? While it is very through in the calculation it is also unusable on large tables. What information is the current command providing that if it can run, is not provided by this new version?

Yes, the current shell command just calls the Java API. I am suggesting to add an option to improve the current shell command. If there is a problem with the API then we should deprecate it and modify the shell command to call the new scan. There is no need for a new shell command that returns the same information.

If the new command is sufficient - then my position would be to have it named du and replace the current command.  If there is a reason to keep the current command, then I'd suggest that it be renamed and deprecated and then eventually removed - otherwise it could be removed / replaced now.
That decision can be made after this code is reviewed.

If the new command is sufficient - then my position would be to have it named du and replace the current command. If there is a reason to keep the current command, then I'd suggest that it be renamed and deprecated and then eventually removed - otherwise it could be removed / replaced now.
That decision can be made after this code is reviewed.

Since du command is unusable on large clusters, we should just make du use the new metadata scan by default and add an option like du -hdfs to preserve the current technique.

The -hdfs option is attractive - but am thinking the specific question should be addressed: what value is provided by the current command that is not addressed with the new approach?
I am concerned that I could be missing the utility of the current approach - are there specific use cases where that approach is necessary? Can they be addressed in another fashion?  This is a general question that should be used to guide how a replacement / improvement is handled.
I am not saying the current approach is unnecessary - I just don't understand the complexity behind it and if that is necessary to provide a command that provides the hdfs space used by a table (or group of tables)

My vote would be to make this new command the new du command and just remove the old one entirely if the outputs are the same. The only reason to keep the old one would be is if they might differ but I haven't found that to be the case. Granted my knowledge is still limited as I'm new to this so someone else migt have an example of when they differ. If there is a good reason to keep it then I like the idea of making the new version the default and having a flag like -hdfs to use the old version.

The file sizes stored in the metadata table are estimates.  I see 2 options:

Create a new option to the du command to call the new API method (something like du -meta or du -estimate)
Change the behavior of DUCommand to make it always scan the metadata. If we do this, we should add an option to call the current getDiskUsage() API (something like du -hdfs) and document in the release notes.

The file sizes stored in the metadata table are estimates. I see 2 options:

Create a new option to the du command to call the new API method (something like du -meta or du -estimate)
Change the behavior of DUCommand to make it always scan the metadata. If we do this, we should add an option to call the current getDiskUsage() API (something like du -hdfs) and document in the release notes.

Option number 2 seems like the best option to me. One thing would be is if we combine the two commands then i'd have to update the old command as well to output in the new format. We don't have to do that but the old command doesn't do the calculation total by table, etc in the same format.

I think that both the old approach and the new approach of getting disk usage are both estimations. Unless you have ceased all write activity on the cluster, there is a good chance on a busy cluster that something will be written between the time you started the command and the time it returns the result to you. Given that, I would suggest that we could replace the existing Accumulo command to scan the metadata table and state in the documentation that it's an estimation. If the user wants really accurate disk usage information, they can quiesce the cluster and run the hadoop fs du -s <dir> command.

I think I like the idea of just dropping the old command entirely and having people just use the hadoop command directly if they really want the hdfs size. The estimation from the new updated command should be sufficient.
Besides having to maintain 2 commands that do nearly the same thing (which may confuse users) the old command would need some work on the RPC/thrift side to send back new data to match the format of the new command I did or we'd have the commands returning different slightly different outputs. The new metrics I added would need to be incorporated and sent back over Thrift and right now all that is sent back is shared table data.
Also, considering the old command doesn't even work on large clusters (which was the entire point of doing this in the first place) I think it just makes sense to remove it. I don't really see much of a use case to want or need to scan HDFS directly and you can't just query the cluster directly using hadoop.

@ctubbsii - Thanks for the detailed feedback, that's very helpful to get some more background. My comments are below to address each of your points.

I agree that we should just have 1 command and no flag. This will make it a lot simpler for the user and less confusing. I will rework my PR to make my changes just the "du" command going forward. I think that scanning the metadata should certainly be faster and a worthwhile change for capturing the size information but we would need to benchmark on a large enough cluster to be sure.
In regards to how the existing command works with computing the size data used exclusively and shared across tables, I didn't change how any of that logic works and my new command still prints that so this should not be a concern. I just moved it under a verbose flag but this can be changed. I refactored that logic into an abstract class so the computation and output is exactly the same as the old command. The only difference is the source of the size data. Below is a sample from the new command and the old command:

Existing:
root@uno t1> du -p t.*
                     310 [t1]
                     270 [t2, t3]
                     232 [t3]

New:
root@uno t1> dumeta -p t.* -v
t1  1  used total: 310  hdfs://localhost:8020/accumulo: 310  has_shared: false
t2  2  used total: 270  hdfs://localhost:8020/accumulo: 270  has_shared: false
t3  3  used total: 502  hdfs://localhost:8020/accumulo: 502  has_shared: true  shared with:  [2]

Shared usage between tables:
310 [t1]
270 [t2, t3]
232 [t3]

In regards to detecting exact or approximate size values how would we detect if it was exact or approximate and does it matter that much? Will the approximate value ever be that far off from the real value to matter?

For size missing entirely would there just be a size of 0 in the metadata for the size value for the file and what would trigger this? I'm assuming maybe bulk ingest but I need to dive into the code to see when this could happen. I'm trying to think out how we can approach this if you wanted to make sure to capture missing data still. If it's missing entirely than maybe we look it up from HDFS then. I would likely need to make a new RPC call to the server with a list of file(s) to query from HDFS to get size data back to fill in the missing gaps.
If the data is not missing and just approximate I think we can still use it (assuming it should be close) but just make sure we document it's an approximation.

The existing DU command works by computing the storage used exclusively by each table provided, as well as computing the storage used by any combination of tables.

A bit of background. The du command was created when the ability to clone tables was added to Accumulo.  It was created to allow someone to know how much clones had diverged in terms of storage space.
As far as using the estimates in the metadata table instead of going to hdfs, below is an example to be aware of that shows how the metadata table estimates behave over time.

Table foo is created with tablet T1.
A minor compaction creates a file F1 in T1 of size 100M.  This size is recorded in the metadata table.
Running du on table foo using metadata table estimated sizes reports 100M.
Tablet T1 splits into T2 and T3 both referencing file F1.  T2 has a guestimated size of 30M for F1 and T3 has a guestimated size of 70M for file F1.
Running du on table foo using metadata table estimated sizes reports 100M.
Tablet T3 compacts file F1 into file F2 resulting in a 10M file.
Running du on table foo using metadata table estimated sizes reports 40M.  However the actual files (F1 and F2) referenced by the table use 110M.
Tablet T2 compacts file F1 into file F3 resulting in a 33M file.
Running du on table foo using metadata table estimated sizes reports 43M.  This agrees with HDFS.

This example illustrates the fact that in Accumulo after a tablet splits that the sum of the estimates of the children is correct until one of the tablets compacts. After a single child of a split compacts, the sum of the estimated sizes is suspect.  After both tablets compact, the estimated sizes will be correct again.  Intuitively I feel like these estimate discrepancies across tablets will cancel each other out resulting in a sum that is still in the neighborhood.  Some of the estimates will be high and others will be low.  Not sure how to prove this yet, but using the metadata estimates seems good to me based on this intuition.

@keith-turner - Thanks so much for that detailed explanation and example of how things could be an estimate. I had mostly been looking at bulk imports and hadn't gotten as far to see how the values could be an estimate with compactions. It seems that the values will be eventually correct (at least in this example) so that is good but there is a period of time when it would be not the same as the file system. So I guess the main question to answer is whether or not everyone agrees that the estimate is acceptable or not.

@milleruntime, @EdColeman  and @ctubbsii - I pushed an update, let me know what you think. It updates the documentation to make it clear that the results are an estimate. The commit also deprecates the old way of computing disk usage with HDFS and updates the "du" command to just use the metadata scan. Lastly I fixed up some of the tests for the Shell as the output has been changed based on suggestions from @EdColeman . You can see the old output with the -v flag for shared usage.

I think we should discuss using the new output format / information.  It seems to present more information that may be of interest.  If one is interested in sizes shared between tables, then providing additional information that inform where the sharing is occurring seems like a value added.
The use case would be when table creation / table management is handled separately that system administration.   If an administrator was tasked with table clean-up, they might not know the provenance of a table or its history.

@ctubbsii - So I've made a few comments already as I'm sure you saw but just to summarize there are 2 main things that need to be decided/agreed on so I can move forward and make changes.

Do we keep the output the same or update it?  @EdColeman was the one who initially suggested the format changes and from his recent comment he still is in favor of it for the reasons provided. We could make any format changes a follow on Issue if we wanted to do that to keep the scope of this PR smaller but as part of those changes I had to add extra logic and tracking and a new API to return the extra information to be displayed. getEstimatedDiskUsage() was added and returns the new object I created TableDiskUsageResult which supports the new format. If we don't intend to change the output then I can certainly just drop the new api/object and re-use the old API as suggested. I could go either way, mostly I would say the output should be whatever is most useful to the people who would be using the command. So really just need to make sure we are on the same page and then I can update this to do whatever.
As noted, old implementation is server side vs client side for the Metadata scan currently. If we just want to it simple and just drop the HDFS implementation for getting file sizes and go with Metadata and not change command output then what should we do about the existing Thrift server call that wouldn't be needed?

The change to add more information in the output seems out of scope. I'm not necessarily opposed, but it's getting muddled with the minimal change needed to accomplish the original goal, and should be considered separately.
As for the thrift API... I guess I'd expect only the server-side implementation to change... rather than convert this to a client-side operation. This leaves the most flexibility in terms of changing the implementation later if we want, and keeps all the changes minimal.

Thanks for the clarification, I'll work on an update today to simply things greatly and just use the metadata for size but keep the current API and command output and i'll move the scan to the server.
We can create a follow on issue after this to discuss changes to the du command in terms of what it outputs and the format of it. It would be good to get everyone on the same page on what the format changes will be (if we decide to change it at all) before proceeding. We'd likely need to update the server API to return more information or a different format to support the changes but we'd need to first figure out what we want to return/display before deciding on any API changes so that could all be addressed in the follow on issue.

@ctubbsii - I reduced the scope of this significantly and pushed an update, it's now ready for review again. I will create another issue when I get a chance for proposed future format changes to the du command.


Give me the code Link is not working

Quick start
The link is not working.

This is now fixed: https://developers.google.com/codelabs/maps-platform/places-101-android-kotlin#2


Add image list description

Describe what this PR does / why we need it

Does this pull request fix one issue?

Describe how you did it
Describe how to verify it
Special notes for reviews

Codecov Report
Base: 17.51% // Head: 17.51% // No change to project coverage :thumbsup:

Coverage data is based on head (a85edfa) compared to base (2a3bad8).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1953   +/-   ##
=======================================
  Coverage   17.51%   17.51%
=======================================
  Files         103      103
  Lines        9139     9139
=======================================
  Hits         1601     1601
  Misses       7325     7325
  Partials      213      213

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Update quick-start to run test

Signed-off-by: Jael Gu<EMAIL_ADDRESS>

Changes implemented in #60.

@fzliu Missing the image I uploaded


[Experimental] Support Cross encoder models

This PR contains a proof of concept to add support for Cross Encoder models reusing most of what was done to support embedding models, as well as the chat embeddings API. It's a bit hacky, but I think it helps to have something concrete to iterate and refine the design.
curl -X 'POST'   'http://localhost:8000/v1/embeddings'   -H 'accept: application/json'   -H 'Content-Type: application/json'   -d '{
  "model": "cross-encoder/ms-marco-MiniLM-L-6-v2",
  "encoding_format": "float",
  "messages": [{
    "role": "user",
    "content": "What is the capital of France?"
  },
  {
    "role": "user",
    "content": "The capital of France is Paris."
  }]
}'

Response:
{
  "id": "embd-49858b4f279b4f19939ac832e85de528",
  "object": "list",
  "created": 110449,
  "model": "cross-encoder/ms-marco-MiniLM-L-6-v2",
  "data": [
    {
      "index": 0,
      "object": "embedding",
      "embedding": [
        9.265625
      ]
    }
  ],
  "usage": {
    "prompt_tokens": 17,
    "total_tokens": 17,
    "completion_tokens": 0,
    "prompt_tokens_details": null
  }
}

I've added a new model type and a new task type. From the point of view of the models and the model runner, this is not strictly necessary at this level because the inputs and outputs are compatible with the embedding models. However at the serving level we need to know that the model has a different task to be able to know for sure that we have to use the text_pair parameter of the tokenizer instead trying to apply a chat template.
What's still missing:

Support for cross encoding in the LLM class
Tests comparing with sentence-transformers
CPU support
Roberta cross encoder models

cc: @DarkLight1337 @flaviabeo

Can you add an example script to show how to use this API?

Yes, I've added one in the PR description but it's a good idea to add it to the documentation.

QQ: Why do we have to define a separate "cross_encoding" task for this? I think we can keep using "embedding" task if we just override the pooler method instead of defining a new classification_output method.

I thought about this, and the only reason I kept it that way was that in the serving layer I need to know what task is being done because I need to call the tokenizer with tokenizer(text=text1, text_pair=text2). If instead of reusing the chat embeddings API we had a new endpoint just for cross encoding, this wouldn't be necessary. Or perhaps we can add an attribute to some of the config classes to tell the although the task is "embedding", the model is actually a "BertModelForSequenceClassification"

I think it may be better to make this a separate flag, similar to how we have a flag for multimodal models, rather than creating a new task for it.

I think it may be better to make this a separate flag, similar to how we have a flag for multimodal models, rather than creating a new task for it.

I think having a separate API for this would be cleaner as well - maybe a Scoring API where we output a single score?

I think having a separate API for this would be cleaner as well - maybe a Scoring API where we output a single score?

I've removed the "cross_encoding" task and added a is_cross_encoder property to the ModelConfig class. I've also added support for Roberta models.
Pending TODOs:

Add Scoring API
Support for cross encoding in the LLM class
Tests comparing with sentence-transformers
CPU support

I've added a score() method to the LLM class and added tests for it. I've also fixed the CPU support.
Pending TODOs:

Add Scoring API
Test Scoring API comparing with sentence-transformers

This PR already supports the BAAI/bge-reranker-v2-m3 model https://github.com/vllm-project/vllm/issues/8022

@DarkLight1337 , thank you so much for guiding this PR along the way. It's ready for review now

Also @robertgshaw2-neuralmagic are we ready to add BERT and RoBERTa to the list of supported models in the docs?

Wait, we still need to update the OpenAI page under /docs

The tests that aren't failing do to hugginface.co timeout are doing so because of a JSON serialization problem. I've opened a tentative fix here: https://github.com/vllm-project/vllm/pull/10580

@DarkLight1337 I have included in this last commit of mine, some documentation for the score API in the OpenAI Compatible Server page. Would this be the right place to add it?

#10581 should fix it, please merge from main again.

@DarkLight1337 I have included in this last commit of mine, some documentation for the score API in the OpenAI Compatible Server page. Would this be the right place to add it?

I think we can move this up one section so that parameters are shown after all API mentions.


feat: Add new popups, (Create/Edit schedule, View schedule) by new design

Version

v0.9.0
Development Environment

Mac
Chrome
Current Behavior

We don't have any popup to create, edit, view a schedule internally. Those are responsible for service code.
Expected Behavior

The default popups of creating, editing and viewing a schedule should be provided.
Creating and editing a schedule popup.

Viewing a schedule popup.

Finished on v1.0.0


Cannot asynchronously load bundles built by webpack into another webpack build

Do you want to request a feature or report a bug?
Bug
What is the current behavior?
Loading modules in a specific order will either not load one module at all, or load it and execute it twice.
If the current behavior is a bug, please provide the steps to reproduce.
Here's a repo that showcases the problem with instructions how to build and reproduce: https://github.com/maciej-gurban/multi-app/tree/webpack-err
What is the expected behavior?

Modules should load regardless of order they are requested in
All modules specified to be imported asynchronously should always be able to load
Each module's code should execute the code once, not multiple times

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.
OSX 10.12.4 (16E195)
npm 3.10.8
node v6.9.1
webpack 2.5.1

@maciej-gurban Problem still exists? can you try with latest webpack (i.e. 4)?


no map with 'use_nav_sat = true'

Hello,
The 3D-SLAM (Livox Horizon LiDAR, 90° HFOV) works fine with 'use_nav_sat = false' (starts generating map for a small 20x20m garden area) ...

...but does nothing if I change it to 'use_nav_sat = true' (empty map).

I'm using ublox f9p cm-precise GPS (RTK) data @ 5 Hz (for that small 20x20m garden area).
Cartographer seem to get the first RTK position:
[ INFO] [1624910382.882780944,<PHONE_NUMBER>.750821826]: I0628 21:59:42.000000 28388 sensor_bridge.cc:88] Using NavSatFix. Setting ecef_to_local_frame with lat = 52.2674, long = 8.60921.

I can see the changing RTK positions with 'rostopic echo /fix'.

However, no map is generated (empty map).
Any ideas? :-) Is there any example bag file using LiDAR and GPS?
Thanks!

Got it working (https://www.youtube.com/watch?v=4t9IMHhMD-Q). However somehow the 'base_link' is 'ahead' of the LiDAR data after some time...

This issue can be closed - solved it by reducing 'voxel_filter_size' and 'submaps.num_range_data'   :-)


feat[Gameplay]: Player move, jump, dash, crouch and run added

The basic movements of the player are implemented to be able to pass the level.

isOnPlayMode is used to manage when scripts are activated.
The module player is left only as the upload and download manager of the player.
A script is created with the player's main mobility. In addition, a dash is added as an ability, the possibility of double jumping and crouching.

If you want to test the branch you need to run it in debugGame mode by putting the CantinaWithMovScript scene and the scene module in the corresponding lib folder.

After trying it a bit more, maybe the jump feels weird, but maybe that's more a gravity issue? idk, the player falls really slowly


Next.js 5

5.0.1-canary.2 works, but 5 not.
https://github.com/zeit/next.js/issues/3828

canary7 is ok


MultiSelect/MultiSelectFiltered: Toggling is not working properly

Description
When creating a Direct Message, the toggle functionality in MultiSelectFiltered (component) is not working correctly.
Clicking the toggle button does not dismiss the list if it is already open.
Steps to reproduce
Insert an image/gif

Thanks.
I'll refer it to the team. it may take some time before it is looked at so you need to be very patient.

Hi @thepiyush-303 I think fuselage's maintainers are planning to replace these components entirely as stated in this PR. I reported a similar issue here


Add SPI Interface ApplicationLifecycleManager for dubbo-core refactor

What is the purpose of the change
Through the new SPI interface, the life cycle management method of each module in dubbo-config is dispersed back to each module itself, so as to minimize the dubbo-config dependency.
Brief changelog

Add SPI interface ApplicationLifecycleManager and its implements.
Add new protocol wrapper: ProtocolRegistryEventWrapper.

Call sequence of lifecycles

Codecov Report

Merging #12750 (c2d454c) into 3.3 (29d9c07) will increase coverage by 2.28%.
Report is 10 commits behind head on 3.3.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                3.3   #12750      +/-   ##
============================================
+ Coverage     65.79%   68.07%   +2.28%
  Complexity        6        6
============================================
  Files          1836     1712     -124
  Lines         73545    70264    -3281
  Branches      10441    10189     -252
============================================
- Hits          48388    47832     -556
+ Misses        20442    17763    -2679
+ Partials       4715     4669      -46

see 214 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

@AlbumenJ  PTAL :)

@qinliujie PTAL


implement the Unwrap method for custom error types

Description
Since the introduction of error wrapping in Go 1.13, more and more Go errors implement the Unwrap method to work with the new error checking paradigm using errors.{Is,As}. This PR is to implement such an Unwrap method for custom error types defined in this library that wrap around a private Error. By implementing Unwrap that returns the private Error, these custom errors will be automatically seen by the Go standard library as wrappers of the private Error. Here's some sample code enabled by this PR:
var cloudflareErr cloudflare.Error
if errors.As(err, &cloudflareErr) {
	fmt.Printf("HTTP status code: %d", cloudflareErr.StatusCode)
}

This is extremely useful when trying to distinguish "errors from the Cloudflare API itself" and "errors due to other reasons (e.g., network errors)". Also, for reasons, only cloudflare.Error implements the ErrorMessageContains method. In sum, the Unwrap function gives users a clean interface to retrieve the private Error that works very well with the current Go standard library.
Has your change been tested?
Not yet. I'm worried a test involving errors.As would not run on platforms using older Go compilers.
Types of changes
What sort of change does your code introduce/modify?

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

Checklist:

[x] My code follows the code style of this project.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

I see that the 2.x library already has all the goodies. Perhaps this PR can be seen as an attempt to make 0.x more usable before completely abandoning it.

when it comes to the Cloudflare errors, you really don't want to be using Unwrap as it is here since it may contain multiple errors and you need to handle that in something like Error() to get the nicer formatting/handling. i.e. https://github.com/cloudflare/terraform-provider-cloudflare/blob/b33577b3af8207bc41b5ab4ae3ffe66f53ee8ff7/internal/sdkv2provider/resource_cloudflare_access_keys_configuration.go#L57-L64
we can add this here, however, going forward, we limiting what we do in 0.x as it detracts effort from the automatically generated versions.


The account popover makes it too easy to unfollow someone

Describe the bug
The popover that shows up when you hover over someone's avatar has a "follow" button. When you're already following that person, that button unfollows them when you press it, and it's very easy to accidentally press it when you're just moving the mouse around the page and the popover appears unexpectedly.
To Reproduce
Steps to reproduce the behavior:

Hover the cursor over Shreyan's avatar in the feed.
Accidentally press the gray "Following" button
You've just unfollowed Shreyan and you might have not even noticed it. If you did notice it, you can refollow him, but then Shreyan gets a follow notification and he will definitely notice it.

Expected behavior
Not sure - some kind of confirmation dialog when you press the unfollow button there, asking if you really want to unfollow them?
It's also possible to accidentally follow someone, but that's probably less problematic because then you'll probably quickly see them in the following feed and notice it.
Screenshots

Details

Platform: web

Does Twitter do anything there? Like a confirmation or maybe removing the button.

Doesn't ask for confirmation either, but changes like this on hover:


Type docs fix

Changes for #11346

Added @internal and @ignore for logger, isError, toAmqpAnnotatedMessage to hide from jsdoc
Renamed SubQueue type to _SubQueue as suggested here and also added @ignore and @internal modifiers.

Yes, sorry for the confusing screenshot.
cd31929 in this PR is good and is enough, please revert b97b682.

Yes, sorry for the confusing screenshot.
cd31929 in this PR is good and is enough, please revert b97b682.

Reverted the commit b97b682


Websocket handshake error

Most of the time I get the Websocket handshake error when trying to connect to streaming quotes. Only out of 10 or more attempts it succeeds once.
Any clue on why it's happening? or Is it only me?
  self.streamConnection.connect(did=self.wb._get_did())   File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/webull/streamconn.py", line 166, in connect     self.client_streaming_quotes.connect('wspush.webullbroker.com', 443, 30)   File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/paho/mqtt/client.py", line 937, in connect     return self.reconnect()   File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/paho/mqtt/client.py", line 1107, in reconnect     sock = WebsocketWrapper(sock, self._host, self._port, self._ssl,   File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/paho/mqtt/client.py", line 3556, in __init__     self._do_handshake(extra_headers)   File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/paho/mqtt/client.py", line 3640, in _do_handshake     raise WebsocketConnectionError("WebSocket handshake error") paho.mqtt.client.WebsocketConnectionError: WebSocket handshake error

I am also getting this error every time now...

I am also getting this error every time now...

Try deleting did.bin file or see if you’re running any proxy

It is happening pretty intermittently for me hence closing it.


urxvt_bidi: init at 2.15

Motivation for this change
Add a very useful plugin to urxvt - https://github.com/mkamensky/Text-Bidi .
Things done
All things done below were tested with #70310 merged, hence it's a requirement for this to get merged.

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

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[X] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

Notify maintainers
cc @rnhmjoj as you are the maintainer of urxvt.

Thank you, I've just tested and it works. Everything looks good.
I'm not sure about enabling it by default, the closure increase is pretty small (≈1MB), though.

TBH I wouldn't care much, it's just that it's a little bit nontrivial for this package to be added to the plugin's list because of the perlDeps which needs to have urxvt_bidi as well. I wanted to show for anyone who may read the definition of rxvt_unicode-with-plugins and that may want to specify his own plugins in his config, that this is needed.
Would you be satisfied if I would leave an appropriate comment instead?

TBH I wouldn't care much, it's just that it's a little bit nontrivial for this package to be added to the plugin's list because of the perlDeps which needs to have urxvt_bidi as well.

Yes, definitely: I intend to rewrite the plugin system to handle dependencies for this reason.

Would you be satisfied if I would leave an appropriate comment instead?

No, you're right: It's better this way until there is a way for a plugin to export perl dependencies, not many people look at the source code anyway.

Oh right so I'll leave it as is. Do you have write permissions to the nixpkgs?

Oh right so I'll leave it as is. Do you have write permissions to the nixpkgs?

No, sorry. I'll try to get attention.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/61

@GrahamcOfBorg build rxvt_unicode-with-plugins urxvt_bidi


Build failure: Seige

###Steps To Reproduce
#Steps to reproduce the behavior:
nix develop

Build log
direnv: loading ~/messaging-dispatcher-server/.envrc
direnv: using flake
warning: Git tree '/Users/jayyy/messaging-dispatcher-server' is dirty
warning: Ignoring setting 'auto-allocate-uids' because experimental feature 'auto-allocate-uids' is not enabled
warning: Ignoring setting 'impure-env' because experimental feature 'configurable-impure-env' is not enabled
[1/0/6 built] building siege-4.1.6 (configurePhase): checking for suffix of executables...direnv: ([/opt/homebrew/bin/direnv export zsh]) is taking a while to execute. Use CTRL-C to give up.
error: builder for '/nix/store/aqc9xxdl862253qx2gs6vz9yaawpnl0l-siege-4.1.6.drv' failed with exit code 2;
       last 25 log lines:
       > ./setup.h:99:5: warning: a function declaration without a prototype is deprecated in all versions of C and is treated as a zero-parameter prototype in C2x, conflicting with a previous declaration [-Wdeprecated-non-prototype]
       > int strcasecmp();
       >     ^
       > 1 warning generated.
       > clang -DHAVE_CONFIG_H -I. -I../include   -I/nix/store/f2h8rd0ma4ml9hrqqdvdj5vhxilx1pfl-zlib-1.3-dev/include/zlib -I/nix/store/f2h8rd0ma4ml9hrqqdvdj5vhxilx1pfl-zlib-1.3-dev/include -I/nix/store/rl8550bfqka2y6fz61xvjki9yxdfvq74-openssl-3.0.12-dev/include/openssl -I/nix/store/rl8550bfqka2y6fz61xvjki9yxdfvq74-openssl-3.0.12-dev/include -I/nix/store/f2h8rd0ma4ml9hrqqdvdj5vhxilx1pfl-zlib-1.3-dev/include/zlib -I/nix/store/f2h8rd0ma4ml9hrqqdvdj5vhxilx1pfl-zlib-1.3-dev/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -W -Wall -Wunused-value -DOPENSSL_NO_KRB5  -g -O2 -c cookies.c
       > In file included from cookies.c:12:
       > ./setup.h:99:5: warning: a function declaration without a prototype is deprecated in all versions of C and is treated as a zero-parameter prototype in C2x, conflicting with a previous declaration [-Wdeprecated-non-prototype]
       > int strcasecmp();
       >     ^
       > cookies.c:69:11: error: incompatible pointer to integer conversion initializing 'size_t' (aka 'unsigned long') with an expression of type 'pthread_t _Nonnull' (aka 'struct _opaque_pthread_t *') [-Wint-conversion]
       >   size_t  id    = pthread_self();
       >           ^       ~~~~~~~~~~~~~~
       > cookies.c:120:23: warning: comparison between pointer and integer ('size_t' (aka 'unsigned long') and 'pthread_t' (aka 'struct _opaque_pthread_t *')) [-Wpointer-integer-compare]
       >     if (cur->threadID == id) {
       >         ~~~~~~~~~~~~~ ^  ~~
       > cookies.c:148:23: warning: comparison between pointer and integer ('size_t' (aka 'unsigned long') and 'pthread_t' (aka 'struct _opaque_pthread_t *')) [-Wpointer-integer-compare]
       >     if (cur->threadID == id) {
       >         ~~~~~~~~~~~~~ ^  ~~
       > cookies.c:172:10: error: incompatible pointer to integer conversion initializing 'size_t' (aka 'unsigned long') with an expression of type 'pthread_t _Nonnull' (aka 'struct _opaque_pthread_t *') [-Wint-conversion]
       >   size_t id = pthread_self();
       >          ^    ~~~~~~~~~~~~~~
       > 3 warnings and 2 errors generated.
       > make[1]: *** [Makefile:439: cookies.o] Error 1

Notify maintainers
@iynaix
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"aarch64-darwin"`
 - host os: `Darwin 23.3.0, macOS 14.3`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.20.1`
 - channels(root): `"nixpkgs"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixpkgs`

Add a :+1: reaction to issues you find important.

Not really sure why I have been tagged because I'm not the maintainer of this package. :sweat_smile:

Not really sure why I have been tagged because I'm not the maintainer of this package. 😅

oh my bad 😅, I wasn't sure who is the maintainer of this package so I checked the latest issue and you were tagged in it so I thought you might be able to help me out. But can you tell me how to check who's the maintainer of this package or perhaps tag them for me? thanks.

You can see who the maintainer(s) are in the nixos package search under more package details. For this package, that would be @7c6f434c

Hmm, builds with clangStdenv on Linux, so I assume that's a macOS-specific failure and then I have no idea (and I avoid having access to macOS machines)

@NixOS/darwin-maintainers does it look like some known common issue?

@NixOS/darwin-maintainers does it look like some known common issue?

Try env.NIX_CFLAGS_COMPILE = lib.optionalString stdenv.cc.isClang "-Wno-error=int-conversion";

Probably stdenv.isDarwin for the condition?

The Linux default is gcc anyway, and I guess clang conditional is better for typo-checking the option from the Linux side? But if experienced Darwin users think otherwise, the impact from the Linux-gcc point of view is the same, so I have no stake.

I'm new to using nix, nixpkg and nixenv. Thank you for the suggestions and comments, but I'm still unsure how to resolve the issue. Could you please tell me what and where to update in my flake.nix or any other relevant file? If you need my flake.nix file, please let me know. Thank you!

Thank you for the suggestions and comments, but I'm new to using nix, nixpkg and nixenv so I'm still unsure how to resolve the issue. Could you please tell me what and where to update in my flake.nix or any other relevant file? If you need my flake.nix file, please let me know. Thank you!


Error: ENAMETOOLONG on building

Version
3.0.2
Node and OS info
Node 10.9.0 / npm 6.4.0 / Ubuntu 18.04
Steps to reproduce
Run NODE_ENV=production vue-cli-service build on my code.
What is expected?
Application is built like yesterday.
What is actually happening?
Error:

Error: ENAMETOOLONG: name too long, open '/mnt/Entwicklung/docemur/public/js/chunk-0621_0f05_0f0f_1041_111b_1257_1a2d_1bac_220e_242e_25b4_285e_29fb_30c8_3414_3789_3818_3eda_46b4_470f_48a0_4d8c_4fcb_54eb_57d6_5b01_5c69_5d89_6286_6b5c_6b9a_6dee_6f6c_7168_8057_833e_8860_89ea_8db3_9380_950a_97d3_9f74_a029_a2db_a738_ab74_b190_b343_b6da_b767_b8ce_b92f_ba51_bcdf_bfcb_c2b6_c2e4_c3fc_c452_c6cf_c87c_cb84_cc45_d000_d018_d7ee_da53_dc46_dd61_e6c3_e7a6_e8a9_e93d_e9a7b_f7d3_fe50.d8c0742b.js'

Everything went fine yesterday and I didn't touch any client specific code. There are many long files like that at the built directory.

have you whiped node_modules and reinstalled?

Yes!

any changes to the default configuration?
this doesn't happen in our CI, so we have to get something to reproduce this from you.

I'm having the exact same issue on node 10.10.0 / yarn 1.9.4 / MacOS 10.13.6. I reverted the cli-service package back to 3.0.1 and builds correctly again, all other packages are upgraded to latest.
Creating a project from scratch using vue create and using my project's vue.config.js builds just fine as well. I'll keep trying to dissect my code base to find the culprit.

Closing on favor of #2490

Has it been solved


Saa 1776 localstack integration tests

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

Project coverage is 84.30%. Comparing base (19921d0) to head (2c6c2c0).

Additional details and impacted files
@@            Coverage Diff            @@
##               main    #1148   +/-   ##
=========================================
  Coverage     84.30%   84.30%
  Complexity     3721     3721
=========================================
  Files           383      383
  Lines         12613    12613
  Branches       1096     1096
=========================================
  Hits          10633    10633
  Misses         1476     1476
  Partials        504      504

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


[flutter release] failed to install Xocde error on 3.19.1 beta branch

Feel free to dedupe this against an infra issue if already exist.
context: https://chat.google.com/room/AAAAc_4rqiI/z-rjx6xh4cE
engine post submit builds are failing on beta branch due to failure to install Xcode. sample failure

affected by the cache state of the bot, a cherry pick might be needed

The xcode installation is from the 12 when the dart-internal service account didn't have access to the xcode packages. That issue has been fixed since then.


Update League of Legends deletion info

Just a snarky comment: it took roughly 10 emails to have my account deleted, then a waiting period of a few months before it was scheduled for deletion.

Hello @Arvife and @reclaimer ,
This repo is not being maintained anymore, but we are trying to keep it alive on a detached fork here, would you kindly submit your PR there and close this one here? :)


Incremental PSyclone

Makes the PSyclone step "incremental", i.e uses prebuilt files and hashes to avoid reprocessing on subsequent runs.

Analyses x90 with prebuilds, recording kernel dependencies.
Updates Fortran analyser to record kernel hashes.
Calls psyclone with prebuilds.

todo:

[x] merge smaller chunks we've pulled out from this branch

[x] #202
[x] #204
[x] #205

[x] go through the todos in this pr
[x] don't record and hash the pulled-out names, simply hash the pre-sanitised x90
[x] ~discuss: "test cleanup of prebuild files" comment - spin out ticket?~
[x] System test TestPsyclone passes on its own, fails when run with all system tests
[x] tidy up - remove more unnecessary stuff

[x] run config changes - into separate pr as they're useful?
[x] there's some unnecessary processing of kernel hashes into used_kernel_hashes to look into

[x] We probably shouldn't be adding hash functions to mutable objects, which I think was just so we can put them into sets. Might want to spin this out into a separate ticket as it extends beyond these psyclone changes.

Merging the analysis result classes pr separately has removed roughly over 1k additions and 600 deletions from this pr.
Also worth pointing out that the sample run configs are not part of the fab source, more just development aids and example ideas for users.

I've raised a ticket to think about dependency versions.


8300013 - Gershwin Creek

[x] Nearby crossings have fish obs, downstream crossing has very high value habitat. Seems like this stream likely has fish. Added to comments, "Good candidate for replacement given the surrounding crossings have fish observations and good habitat."

mmm. just a wee little guy. will swap with mainstem Gershwin crossing on railway for follow up 8302869 - Gershwin Creek here https://github.com/NewGraphEnvironment/fish_passage_skeena_2023_reporting/issues/24


Swagger webjars don't work

Version of javalin-openapi-plugin and javalin-swagger-plugin is 5.1.4
I have the following OpenAPI and swagger config:
      OpenApiConfiguration openApiConfiguration = new OpenApiConfiguration();
      openApiConfiguration.setInfo(applicationInfo);
      openApiConfiguration.setSecurity(new SecurityConfiguration()
          .withSecurityScheme(OPENAPI_IAM_KEY, new OAuth2(OPENAPI_IAM_KEY)
              .withFlow(oAuth2Flow))
          .withSecurity(new Security(OPENAPI_IAM_KEY)
              .withScope("openid")
              .withScope("roles")));
      javalinConfig.plugins.register(new OpenApiPlugin(openApiConfiguration));

     javalinConfig.plugins.register(new SwaggerPlugin(new SwaggerConfiguration()));

Swagger UI doesn't work. It tries to load swagger webjars by https://webjars/... instead of https://host/webjars/...

Do you use custom context path for routing plugin?

No, should I?

No, but this is related to the fact I've added support for it in 5.1.4. You can downgrade to 5.1.3 for now and I'll take a look on that in the evening.

It's fixed in 5.1.4-1, should be available in Maven Central up to an hour.


Fix snapshot_download

Adds repo_type argument so it doesn't try to download as model

Nice catch! Looks good to me, thanks 👍


update partition name and cuda version

PR Summary
Darwin has moved nodes from the power9 partition and it only has 2 nodes left, we need to move to the new one, so the CI jobs won't hang all the time.
Also, carrying over the cuda update Richard proposed in spiner MR (https://github.com/lanl/spiner/pull/63)

PR Checklist

[ ] Adds a test for any bugs fixed. Adds tests for new features.
[ ] Format your changes by using the make format command after configuring with cmake.
[ ] Document any new features, update documentation for changes made.
[ ] Make sure the copyright notice on any files you modified is up to date.
[ ] After creating a pull request, note it in the CHANGELOG.md file
[ ] If preparing for a new release, update the version in cmake.

Thanks, @ktsai7 !


Automatically generate the default profile from istio/installer using manifest migrate

manifest migrate should be able to migrate the istio/installer default values.yaml into IstioControlPlane.

Still WIP for this issue, it is necessary to automate this process

Partly fixed in https://github.com/istio/operator/pull/393, just need to integrate it with run_update_charts.sh (or where appropriate).