Restart is potentially dangerous

Currently, restarting relies on stopping ECS tasks. If you blindly restart an entire application, all of the current ECS tasks will be stopped. Ideally, ECS would provide a method to do a rolling restart of some tasks, but that's not a feature at the moment. A potential work around would be to re-submit the service with a new task definition to trigger a rolling restart of all of the tasks.

Was this resolved by #543?

Yep. Closing.


Problems on Google Colab

Hi !! First of all I would like to congratulate you on the project..... It increases the productivity of a BERT-SQUAD application.  Could you extract a requirements.txt?
I believe that the problem is related with TensorFlow version.
Thanks

I have a problem running the notebook in colab. The i get the following error "TypeError: iterate_inbound() got an unexpected keyword argument 'include_arguments'"

Please take a look at https://github.com/artitw/text2text and ask questions there if necessary.


Document flutter.yaml

From @sethladd on November 20, 2015 17:15

What is this file?
What is it used for?
What do I put in it?

See also https://github.com/flutter/flutter/issues/300
Copied from original issue: flutter/website#92

@qchong needs this for the hackathon.

Partially documented here:
https://github.com/flutter/website/search?l=markdown&q=flutter.yaml&utf8=✓
What I imagined as a resolution of this bug is something like this:
https://www.dartlang.org/tools/pub/pubspec.html
Even if its just dumped into this bug for later formatting by @qchong


Update mutant dependency

Dunno if you guys actively use mutant.

Not explicitly pull the mutant dependency, as shown in the installation instructions
If I fuck up dependencies in a way (less likely the next month, because of me working on a commercial ruby project) mutant prevents parser updates: Raise a ticket, or drop mutant from this repo.

we do, right now we're riding on rspec-3-3 branch, I don't have a problem with using master. we can switch to the released version later :)


Export more types for typography

for feature #19572

export useful TS types for typography which were hard to discover
Remove unused code

[x] I have followed (at least) the PR section of the contributing guide.

Form how I understood it, the idea what to expose more variables from createMuiTheme, for instance, the ones we import deep in https://material-ui.com/guides/typescript/? I don't understand why the types of the Typography component needs to be changed.

@oliviertassinari Ah i defiantly misunderstood that, but can do that if you would like. Would you want me to just import/export them straight from index.d.ts?

@aleccaputo Did you have the time to look at the issue? :)

@oliviertassinari @eps1lon how's that look?

@aleccaputo Thank you for the cooperation!


Failed to load node 'visual_odometry_node' when running 02-realsense_camera example

Steps to reproduce:

I followed the directions to launch the RealSense camera tutorial.
The final command as instructed is docker run --runtime nvidia --network host --privileged rbonghi/isaac-ros-tutorial:realsense-camera

Expected Result:
The following 3 nodes are expected to run:

visual_odometry_launch_container
robot_state_publisher
realsense2_camera_node

Actual Result:
Only these two nodes actually run:

robot_state_publisher
realsense2_camera_node

The  visual_odometry_launch_container errors out with the following message:
[component_container-1] [ERROR] [1648158183.458867921] [camera.visual_odometry_launch_container]: Could not find requested resource in ament index
[ERROR] [launch_ros.actions.load_composable_nodes]: Failed to load node 'visual_odometry_node' of type 'isaac_ros::visual_odometry::VisualOdometryNode' in container '/camera/visual_odometry_launch_container': Could not find requested resource in ament index
I'm not very confident with my understanding about how ROS2 overlay / underlay environments work, but I suspect this is related to issue I'm experiencing.

Upon further investigation, I believe the package name changed from isaac_ros_visual_odometry to isaac_ros_visual_slam which would explain why these examples no longer work as expected
Here is a link to the new packages:
https://github.com/NVIDIA-ISAAC-ROS/isaac_ros_visual_slam

Hi @KohlhardtC , there are updates to do on this repo with the latest packages for Isaac ROS
I will update soon

Repository updated.
Now all images work with the latest Isaac ROS and JP4.6.1


Set MAC Address

Allows you to optionally set the source and destination MAC addresses for each flow.

This fixes #7


Fix/split autoware msgs config can

Status
PRODUCTION / DEVELOPMENT
Description
This PR only splits the CAN and configuration messages so it's easier to merge sooner.
Related PRs
List related PRs against other branches:

branch
PR

develop
#1408

Steps to Test or Reproduce
cd ros
./catkin_make_release

It seems that some more autoware_msgs should be renamed to autoware_config_msgs.
Sorry for just a comment. I want to get more time...
An compile error occued at d506ccc:
/home/autoware/Autoware/ros/src/computing/perception/detection/vision_detector/packages/vision_darknet_detect/src/vision_darknet_detect.h:52:37: fatal error: autoware_msgs/ConfigSsd.h: No such file or directory

After fixing above error,
/home/autoware/Autoware/ros/src/computing/perception/localization/packages/lidar_localizer/nodes/approximate_ndt_mapping/approximate_ndt_mapping.cpp:160:34: error: ‘autoware_msgs’ does not name a type
static void param_callback(const autoware_msgs::ConfigApproximateNdtMapping::ConstPtr& input)
                                 ^
/home/autoware/Autoware/ros/src/computing/perception/localization/packages/lidar_localizer/nodes/approximate_ndt_mapping/approximate_ndt_mapping.cpp:160:76: error: expected unqualified-id before ‘::’ token
static void param_callback(const autoware_msgs::ConfigApproximateNdtMapping::ConstPtr& input)
                                                                           ^
/home/autoware/Autoware/ros/src/computing/perception/localization/packages/lidar_localizer/nodes/approximate_ndt_mapping/approximate_ndt_mapping.cpp:160:76: error: expected ‘)’ before ‘::’ token
/home/autoware/Autoware/ros/src/computing/perception/localization/packages/lidar_localizer/nodes/approximate_ndt_mapping/approximate_ndt_mapping.cpp:160:76: error: expected initializer before ‘::’ token
/home/autoware/Autoware/ros/src/computing/perception/localization/packages/lidar_localizer/nodes/approximate_ndt_mapping/approximate_ndt_mapping.cpp: In function ‘int main(int, char**)’:
/home/autoware/Autoware/ros/src/computing/perception/localization/packages/lidar_localizer/nodes/approximate_ndt_mapping/approximate_ndt_mapping.cpp:961:82: error: ‘param_callback’ was not declared in this scope
  ros::Subscriber param_sub = nh.subscribe("config/approximate_ndt_mapping", 10, param_callback);
                                                                                ^
Scanning dependencies of target queue_counter
[ 97%] Building CXX object computing/perception/localization/packages/lidar_localizer/CMakeFiles/queue_counter.dir/nodes/queue_counter/queue_counter.cpp.o
/home/autoware/Autoware/ros/src/computing/perception/localization/packages/lidar_localizer/nodes/ndt_mapping/ndt_mapping.cpp:179:34: error: ‘autoware_msgs’ does not name a type
static void param_callback(const autoware_msgs::ConfigNdtMapping::ConstPtr& input)
                                 ^
/home/autoware/Autoware/ros/src/computing/perception/localization/packages/lidar_localizer/nodes/ndt_mapping/ndt_mapping.cpp:179:65: error: expected unqualified-id before ‘::’ token
static void param_callback(const autoware_msgs::ConfigNdtMapping::ConstPtr& input)
                                                                ^
/home/autoware/Autoware/ros/src/computing/perception/localization/packages/lidar_localizer/nodes/ndt_mapping/ndt_mapping.cpp:179:65: error: expected ‘)’ before ‘::’ token
/home/autoware/Autoware/ros/src/computing/perception/localization/packages/lidar_localizer/nodes/ndt_mapping/ndt_mapping.cpp:179:65: error: expected initializer before ‘::’ token
/home/autoware/Autoware/ros/src/computing/perception/localization/packages/lidar_localizer/nodes/ndt_mapping/ndt_mapping.cpp: In function ‘int main(int, char**)’:
/home/autoware/Autoware/ros/src/computing/perception/localization/packages/lidar_localizer/nodes/ndt_mapping/ndt_mapping.cpp:1051:70: error: ‘param_callback’ was not declared in this scope
  ros::Subscriber param_sub = nh.subscribe("config/ndt_mapping", 10, param_callback);

@kfunaoka thanks for checking, I think the rebase missed a few changes from #1590 I'm building locally and will fix the errors.

@kfunaoka this now builds fine locally, I'm just waiting for Travis to finish.

Travis just built this PR successfully.

@esteve @amc-nu I've submitted https://github.com/esteve/Autoware/pull/3 fixing vision_darknet_detect. Travis could not detect the error because Travis does not have CUDA.

@amc-nu @esteve About naming convention such as SSD, DPM, etc, we have two choices:

Merge this pull request as is
Merge this pull request with name fixing

Because the purpose of this pull request is to split autoware msgs, the first choice also works fine, I think. This pull request has a lot of line changes, how about 1st choise to merge this pull request ASAP?

@kfunaoka @amc-nu I'd rather merge this as is. There are other naming issues that need to be addressed as well (e.g. Ros vs ROS), but I think they're out of scope here. I changed CanInfo because there were already two other messages with a different naming convention (CANData and CANPacket).

@kfunaoka @amc-nu I'd rather merge this as is. There are other naming issues that need to be addressed as well (e.g. Ros vs ROS), but I think they're out of scope here. I changed CanInfo because there were already two other messages with a different naming convention (CANData and CANPacket).

@kfunaoka @amc-nu I'd rather merge this as is. There are other naming issues that need to be addressed as well (e.g. Ros vs ROS), but I think they're out of scope here. I changed CanInfo because there were already two other messages with a different naming convention (CANData and CANPacket).

@amc-nu @kfunaoka I've pushed #1633 which applies the changes that were mentioned here. Let me know if there's any other naming change that should go in. Thanks.

Travis failed to start the Kinetic job (Indigo built this PR just fine), but I'm going to merge this anyway.


Autoupdate from upstream

Auto-generated PR

Lots of changes from upstream in this release. Test upgrades in a non-production environment first,


POST (multipart) arguments are skipped when field name is not in quotes

Multipart/form-data messages have field name listed in Content-Disposition header field. It's something like name="field1". Libhtp parses such messages just fine. However, at least some platforms also accept name=field1, without double quotes (for example, Apache/PHP). Libhtp skips such parameters.
Steps to reproduce:

Change test with the following patch:

diff --git a/test/files/17-multipart-1.t b/test/files/17-multipart-1.t
index 7c083c6..5fface7 100644
--- a/test/files/17-multipart-1.t
+++ b/test/files/17-multipart-1.t
@@ -16,7 +16,7 @@ Content-Disposition: form-data; name="field1"

<PHONE_NUMBER>
 -----------------------------41184676334
-Content-Disposition: form-data; name="field2"
+Content-Disposition: form-data;   name=field2

<PHONE_NUMBER>
 -----------------------------41184676334

(additional spaces were added to keep content length the same. They are not significant for the issue.)

Run tests (make test)

Expected results:
Test succeeds.
Actual results:
Test fails.

I will have a look, thanks.

Is this still an issue ?

Is this still an issue?

The test still fails.

How are you using libhtp ? With Suricata ?

but likely not for Suricata's usage

This is a potential bypass vector. Combined with HTTP Parameter Pollution this may be used to feed some innocent parameter values to detectors in Suricata, but allow to pass malicious payloads to the protected application.

This is a potential bypass vector.

Yes, but Suricata does not use libhtp multipart code, and has its own (which had similar bugs fixed recently)

Suricata does not use libhtp multipart code

Oh... okay.


Missed packets using RaspberryPi and nRF24L01.

Hello!
I'm experimenting with Raspberry Pi Zero 2 W and SPI-connected nRF24L01 module.
I use Python library https://github.com/bjarne-hansen/py-nrf24 which uses pigpio (pigpiod).
In nRF24L01 promiscuous mode I see some data on RX, but I definitely don't see packets from my Logitech mouse.
I checked with other project https://github.com/DigitalSecurity/raspjack which uses RPi.GPIO (https://pypi.org/project/RPi.GPIO/) and spidev (https://pypi.org/project/spidev/). Everything works as expected there.
I analyzed py-nrf24 library that I'm using, experimented with different parameters, compared libs outputs, nRF24L01 registers states, etc. It seems that the problem with pigpio library.
Would be appreciated for hints where to start digging to solve the problem!
P.S.: I don't have a logic analyzer.

Sure.  Let's start with some basic testing.  Since I've never used the Pi Zero 2 W, please run the Python x_pigpio.py test to verify the installation and that everything works on this platform.
wget https://github.com/joan2937/pigpio/raw/master/x_pigpio.py
sudo pigpiod # if not already running
sudo python x_pigpio.py

All tests should pass:  "TEST x.y PASS (blah blah)"

Also, please report the header output.  For example, my header is:

Testing pigpio Python module 1.78
Python 3.9.2 (default, Feb 28 2021, 17:03:44)  [GCC 10.2.1 20210110]
pigpio version 79.
Hardware revision 12595477.

Good.  Can you tell me more about what you did.  In particular why you think it's a problem with the lib.

I analyzed py-nrf24 library that I'm using, experimented with different parameters, compared libs outputs, nRF24L01 registers states, etc. It seems that the problem with pigpio library.

I compared registers states for both scripts (mine and raspjack) and they have equal values.

So, does this mean the issue can be closed?

I compared registers states for both scripts (mine and raspjack) and they have equal values.

So, does this mean the issue can be closed?

The problem still exists. Despite setups and debug outputs (registers, SPI speeds, etc) for the both scripts are looking the same, I don't see packets from my Logitech mouse while using py-nrf24 and pigpiod.
You can close the issue. I will use another library for my project.
Thanks a lot!

Yeah, given there's nothing more specific to go by and you've got a working solution, I'll close this.


python310Packages.bimmer-connected: 0.10.2 -> 0.10.3

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.bimmer-connected is: "Library to read data from the BMW Connected Drive portal"
meta.homepage for python310Packages.bimmer-connected is: "https://github.com/bimmerconnected/bimmer_connected"
meta.changelog for python310Packages.bimmer-connected is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.10.3 with grep in /nix/store/f77a8j0mxcfsxggqjq03d7qbj2k8b8xz-python3.10-bimmer-connected-0.10.3
found 0.10.3 in filename of file in /nix/store/f77a8j0mxcfsxggqjq03d7qbj2k8b8xz-python3.10-bimmer-connected-0.10.3

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

3 package rebuild(s)

First fifty rebuilds by attrpath
home-assistant-component-tests.bmw_connected_drive
python310Packages.bimmer-connected
python39Packages.bimmer-connected

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/f77a8j0mxcfsxggqjq03d7qbj2k8b8xz-python3.10-bimmer-connected-0.10.3 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python310Packages.bimmer-connected https://github.com/r-ryantm/nixpkgs/archive/6853b4235ce201f74a3244f195e8f36200d16f48.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/f77a8j0mxcfsxggqjq03d7qbj2k8b8xz-python3.10-bimmer-connected-0.10.3
ls -la /nix/store/f77a8j0mxcfsxggqjq03d7qbj2k8b8xz-python3.10-bimmer-connected-0.10.3/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

3 packages built:

home-assistant-component-tests.bmw_connected_drive
python310Packages.bimmer-connected
python39Packages.bimmer-connected

Maintainer pings
cc @dotlambda for testing.

Result of nixpkgs-review pr 190393 run on x86_64-linux 1

3 packages built:

home-assistant-component-tests.bmw_connected_drive
python310Packages.bimmer-connected
python39Packages.bimmer-connected


updated tf.identity and tf.zeros_like

Updated tf.identity and tf.zeros_like with examples

Closing this PR as this not against master, please open a new PR against master
CC @mihaimaruseac


进程被杀死

Thanks for your error report and we appreciate it a lot.
Checklist

I have searched related issues but cannot get the expected help.
The bug has not been fixed in the latest version.

Describe the bug
A clear and concise description of what the bug is.
在使用模型对大量图像进行连续预测后，进程被杀死
Reproduction

What command or script did you run?

A placeholder for the command.

Did you make any modifications on the code or config? Did you understand what you have modified?
What dataset did you use?

Environment

Please run python mmdet/utils/collect_env.py to collect necessary environment infomation and paste it here.
You may add addition that may be helpful for locating the problem, such as

How you installed PyTorch [e.g., pip, conda, source]
Other environment variables that may be related (such as $PATH, $LD_LIBRARY_PATH, $PYTHONPATH, etc.)

Error traceback
If applicable, paste the error trackback here.
A placeholder for trackback.

Bug fix
If you have already identified the reason, you can provide the information here. If you are willing to create a PR to fix it, please also leave a comment here and that would be much appreciated!

Maybe CPU or GPU is OOM, if you still meet this problem, please feel free to create a new issue.


How to get the content downloaded from whois server

like

w.text  # the content downloaded from whois server
u'\nDomain Name: EXAMPLE.COM
Registry Domain ID: 2336799_DOMAIN_COM-VRSN
...'

yes i have been thinking about how to add the raw output of the whois command to the output of whois.query.
it is not 100% possible but in most cases it should be possible to also add the raw output , i will implement that in the next change

should become possible after #237 has been merged, the text field can then be requested with the boolean flag: include_raw_whois_text set to True

Thanks for the work.


Installer CRD proto definition

Initial proto definition which is basically just a wrapper around values.yaml schematized in https://github.com/istio/operator/pull/2.
The only exceptions are:

kubernetes resources are structured and defined in terms of k8s official protos
component enablement and namespaces are structured by feature and component, per Istio building blocks and new installer charts.

Quick question, why is this going into 1.1 release branch and not master?

Values.yaml v1.1 definitions are stable so first bunch of code going in will be against istio 1.1. I'll cherry pick many of these back into master.

Sorry but what is the purpose of having operator release-1.1 branch?   I had thought it is for master and 1.2 only. :)

This is 1.1 because we're starting with values.yaml v1.1 "schema". I'll cherry pick this and other PRs into master once v1.1 installation is mostly working.

After more discussion, istio-installer is probably stable enough to start using now. In that case, going straight to master and we'll start working against 1.2 immediately.

Afaik the current proposal is to dedup mesh config and values.yaml - so
this should go inside mesh config.
On Thu, May 16, 2019, 08:26 Lin Sun<EMAIL_ADDRESS>wrote:

@linsun commented on this pull request.
In pkg/apis/istio/v1alpha1/istioinstaller_types.proto
https://github.com/istio/operator/pull/3#discussion_r284766101:

// Version tag for docker images e.g. 1.0.6

string tag = 102;
+}

+// Configuration options for traffic management.
+message TrafficManagementFeatureSpec {

// Selects whether traffic management is installed.
// Must be enabled to enable any sub-component.
google.protobuf.BoolValue enabled = 1;
// Namespace that all traffic management components are installed into.
string namespace = 2;

// Component specific config.
PilotComponentSpec pilot = 30;
ProxyComponentSpec proxy = 31;
SidecarInjectorComponentSpec sidecar_injector = 32;

I think we should move sidecar injector out of traffic management as it is
not directly related. You can use side car injector when you are not using
traffic management.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/istio/operator/pull/3?email_source=notifications&email_token=AAAUR2V5IMAL7PFIQCMGWGDPVV4LFA5CNFSM4HLVZBMKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOBY3MFOI#discussion_r284766101,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAUR2SSCNNJ7H2EILZXJYDPVV4LFANCNFSM4HLVZBMA
.

Thanks @ostromart - I think I'm good with this as the first pass.
I know @rcernich has some concerns in a few places, so I 'll hold off my lgtm in case it got the PR merged.


how to cite your work

Dear author,
I like your work and hope to improve the work by modifying and changing some components. Just wondering how to cite this piece of work?
Thanks!

Hi. Thanks for your interest. But this work has no related publication.
I don't know either about how to cite this work.

Hi Feiyu,
Thank you for your information! We will probably use a different approach but your work is definitely valuable. Have you included this project in your thesis project so we may cite your thesis instead?
Best regards,
Mary

From: Feiyu Chen<EMAIL_ADDRESS>Sent: Monday, 28 September 2020 14:56
To: felixchenfy/Realtime-Action-Recognition<EMAIL_ADDRESS>Cc: Mary-xl<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [felixchenfy/Realtime-Action-Recognition] how to cite your work (#59)
Hi. Thanks for your interest. But this work has no related publication.
I don't know either about how to cite this work.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/felixchenfy/Realtime-Action-Recognition/issues/59#issuecomment-699769197, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AMLTC3DXK42LOMEHYASI77LSIAJRVANCNFSM4RUP63TA.

No, I don't have a thesis....
( sorry I didn't see your message)


Write errors from HotChocolate.Fusion.CommandLine to stderr instead of stdout

Product
Hot Chocolate
Is your feature request related to a problem?
Detecting errors in CI/CD is a little bit difficult, because both successful and unsuccessful commands write to standard out but do not write to standard error.
The solution you'd like
I would prefer if the fusion command line tool would write errors to standard error instead of standard out.

We've encountered a similar issue with HotChocolate.AspNetCore.CommandLine when running the schema export command in GitHub Actions.
The CI pipeline continues running despite the unhandled exception stack trace being written to stdout. I believe the reason for this is actually because the command is returning a zero exit code despite having failed, instead of a non-zero exit code to indicate a failure. But I also agree that using stderr for error messages would be a useful enhancement.

Good point. I only mentioned stderr because we are using Azure DevOps and that has a failOnStderr option.

+1 for this and a bit of extra emphasis on changing the status code from zero to non-zero on error. Not all environments have a failOnStdErr option.

+1 to this. We are currently considering adopting Fusion for a distributed graph solution. However, we can't generate schema files for our existing services, even when everything's updated to the latest HotChocolate prerelease version.
Not having error output means we can't investigate the issue, and it seems risky to bet on this for anything business critical.

@dkAnBlWo shall we setup a call to see what the issue is you guys are having? Send us an email to: contact at chillicream.com
Closing the issue as we fixed the stderr.

@tobias-tengler can this be closed?


string starting with "-0x" not working in hex_to_int256

Describe the bug
As title
To Reproduce
Execute simple query
select hex_to_int256('-0x11');

Expected behavior
We should have got
select hex_to_int256('-0x11');
----
-17

But we got
select hex_to_int256('-0x11');
ERROR:  QueryError: Expr error: Parse error: failed to parse hex '-0x11', invalid digit found in string

Additional context
Implemented in #9146

I think we don't expect users to use - to represent negative numbers, cc @shanicky

For our hex_to_int256, we put the sign bit in hex after "0x", so we do not support representations such as "-0xff" as it can cause confusion.

Please update it into e2e_test https://github.com/risingwavelabs/risingwave/blob/66bab914e4396c0a55bf441f694acdd3cfc0d49f/e2e_test/batch/types/int256.slt.part#L65

Please update it in e2e_test
https://github.com/risingwavelabs/risingwave/blob/66bab914e4396c0a55bf441f694acdd3cfc0d49f/e2e_test/batch/types/int256.slt.part#L65

It seems to be an outdated branch. Which branch did you see the test?

I got it in https://github.com/risingwavelabs/risingwave/pull/9146/files#diff-bc958632e02167d83b4fb100daac1827e12ada7308c4ddad53d82dc4d1ef07a4


Test isolate/spawn_uri_multi_test/01 times out on x64 dartium

The test
isolate/spawn_uri_multi_test/01
is timing out flakily on the x64 dartium bot.
When the test doesn't time out, it takes less than 3 seconds.  When it times out, it takes over 1 minute.
Updated in status file.
The error is:
FAILED: none-dartium-checked release_x64 isolate/spawn_uri_multi_test/01
Expected: Pass
Actual: Timeout
CommandOutput[dartium]:
stdout:
message:
Dom could not be fetched, since the test timed out.

Seems to work in Dart 1.24.2 Stable (Dartium 50) will re-enable.


Verifying Publisher confirms

I have been trying to port code written to use a previous lapin version to make it use v0.20.0, but I'm stuck with a compilation error.
It's when calling basic_publish() and applying and_then() on it.
The documentation here: https://docs.rs/lapin-futures/0.20.0/lapin_futures/struct.Channel.html#method.basic_publish says:

pub fn basic_publish(
&self,
exchange: &str,
routing_key: &str,
payload: Vec,
options: BasicPublishOptions,
properties: BasicProperties
) -> ConfirmationFuture<()>
publishes a message on a queue
the future's result is:
Some(true) if we're on a confirm channel and the message was ack'd
Some(false) if we're on a confirm channel and the message was nack'd
None if we're not on a confirm channel

The prototype (returning ConfirmationFuture<()>) seems to imply that the parameter that gets passed to the lamda function for and_then() will be the unit type (), and not an Option<> type and indeed this is what my compiler tells me:

|

259 |                                             .and_then(move |confirm| match confirm {
|                                                                            ------- this match expression has type ()
260 |                                                 Some(ack) => {
|                                                 ^^^^^^^^ expected (), found enum std::option::Option
|
= note: expected type ()
found type std::option::Option<_>

Have you got an example of how to how to verify confirms? I couldn't find one in the test or examples folder.
I've been only a few months into Rust, so apologies if I'm overlooking something.

Hello,
The doc seems outdated indeed, could you maybe update it and make a PR ?
The correct way now is to call wait_for_confirms which returns a list of
nacked messages.
This better matches what other clients do and follows official rabbitmq
recommendations not to wait for confirm for every message
On Wed 3 Jul 2019 at 20:46, fourlightyears<EMAIL_ADDRESS>wrote:

I have been trying to port code written to use a previous lapin version to
make it use v0.20.0, but I'm stuck with a compilation error.
It's when calling basic_publish() and applying and_then() on it.
The documentation here:
https://docs.rs/lapin-futures/0.20.0/lapin_futures/struct.Channel.html#method.basic_publish
says:
pub fn basic_publish(
&self,
exchange: &str,
routing_key: &str,
payload: Vec,
options: BasicPublishOptions,
properties: BasicProperties
) -> ConfirmationFuture<()>
publishes a message on a queue
the future's result is:
Some(true) if we're on a confirm channel and the message was ack'd
Some(false) if we're on a confirm channel and the message was nack'd
None if we're not on a confirm channel
The prototype (returning ConfirmationFuture<()>) seems to imply that the
parameter that gets passed to the lamda function for and_then() will be the
unit type (), and not an Option<> type and indeed this is what my compiler
tells me:
|
259 | .and_then(move |confirm| match confirm {
| ------- this match expression has type ()
260 | Some(ack) => {
| ^^^^^^^^ expected (), found enum std::option::Option
|
= note: expected type ()
found type std::option::Option<_>
Have you got an example of how to how to verify confirms? I couldn't find
one in the test or examples folder.
I've been only a few months into Rust, so apologies if I'm overlooking
something.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/sozu-proxy/lapin/issues/186?email_source=notifications&email_token=AABWNXSBPXOPFVDTPJ75E3TP5TXWXA5CNFSM4H5IUGRKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G5GSXNA,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABWNXWHGHSIVOZ2LQGHJBTP5TXWXANCNFSM4H5IUGRA
.

Thanks. I could update it (src/channel.rs), but I'm wondering how to do so in such a way that the update appears for each version (from v0.19,0 unitl v0.24.0 I believe) in docs.rs. Obviously, I could do it just for the head, but the documentation will only be correct for versions from v0.25.0 onward.
Okay, after writing the above, I see that the lib version resides in Cargo.toml. So, if I make the change for v0.19.0 and merge it into my local copy of v0.20.0 and then merge that to the next version, and so on, assuming that docs.rs will probe the repository for the latest changeset corresponding to a Cargo.toml version, will that do?  In this case, since the documentation for wait_for_confirms() and basic_publish() hasn't changed there should hopefully be no merge conflicts, or any conflicts should be easily merge-able.

Yeah, we cannot change documentation for previous versions.
I edited the comments in 0.24.0
On Fri 5 Jul 2019 at 13:59, fourlightyears<EMAIL_ADDRESS>wrote:

Thanks. I could update it (src/channel.rs), but I'm wondering how to do
so in such a way that the update appears for each version (from v0.19,0
unitl v0.24.0 I believe) in docs.rs. Obviously, I could do it just for
the head, but the documentation will only be correct for versions from
v0.25.0 onward.
Okay, after writing the above, I see that the lib version resides in
Cargo.toml. So, if I make the change for v0.19.0 and merge it into my local
copy of v0.20.0 and then merge that to the next version, and so on,
assuming that docs.rs will probe the repository for the latest changeset
corresponding to a Cargo.toml version, will that do? In this case, since
the documentation for wait_for_confirms() and basic_publish() hasn't
changed there should hopefully be no merge conflicts, or any conflicts
should be easily merge-able.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/sozu-proxy/lapin/issues/186?email_source=notifications&email_token=AABWNXXVEJAULZXXABRQ7TTP54ZQFA5CNFSM4H5IUGRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZJLBFY#issuecomment-508735639,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABWNXUNOLU5FZ6BEHYHCBLP54ZQFANCNFSM4H5IUGRA
.


Find a way to separate the manifest for chrome and the manifest for mozilla

Chrome doesn't need the scripting permission. The functionallity is provided by the content script. But in mozilla firefox the scripting permission is required because it does not support content scripts.

Done with browser specific manifests

chrome: https://github.com/SimonStnn/pop-a-loon/blob/abaa97fd2b71da7700601820d14f21b98304a1cc/manifest.chrome.json
firefox: https://github.com/SimonStnn/pop-a-loon/blob/abaa97fd2b71da7700601820d14f21b98304a1cc/manifest.firefox.json

And a general manefest: https://github.com/SimonStnn/pop-a-loon/blob/abaa97fd2b71da7700601820d14f21b98304a1cc/manifest.json


Add container settings

Fixes spring-cloud/spring-cloud-dataflow-admin-yarn#17
Add resource priority, cpu and mem settings.
Add javaOpts
Make all those configurable via servers.yml
For tasks, these settings can be configured during
a deployment after shell is starting do support passing
in deployment properties.
For streams all settings are coming from servers.yml because
we still have limitation to be able to run only one app
at a time. That work is done in #2 which needs some tweaks to
how module deployer spi works.

Don't think this breaks anything, so merging soon


NOJIRA: add RIW sim news to front page

I noticed when starting the CISL news item that the RIW sim didn't have an item on the front page. Since it's quick to do so, I've added it with this PR.

@waharnum I think this was merged with your other pull request, right?

That's correct.
On Fri, Feb 8, 2019, 3:41 PM Michelle<EMAIL_ADDRESS>wrote:

@waharnum https://github.com/waharnum I think this was merged with your
other pull request, right?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/fluid-project/floeproject.org/pull/81#issuecomment-461939871,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFCNSzD7XyVXAdI60bXy7xr93v4dFx3fks5vLeDngaJpZM4anYDJ
.


Screen of the app randomly blanking while using the Wayland Window Manager

Type: Bug
In Fedora 39 with the Gnome desktop environment, launch in the Wayland-enabled Gnome version and open VS Code. The app will randomly black screen when both in fullscreen and windowed mode.
VS Code version: Code 1.85.1 (0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2, 2023-12-13T09:47:11.635Z)
OS version: Linux x64 6.6.9-200.fc39.x86_64
Modes:

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-10400 CPU @ 2.90GHz (12 x 3999)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okvideo_decode: enabledvideo_encode: disabled_softwarevulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: disabled_off

Load (avg)
0, 0, 0

Memory (System)
15.48GB (13.16GB free)

Process Argv
--unity-launch --crash-reporter-id 2aae8724-177c-441b-82c5-c728066ca684

Screen Reader
no

VM
0%

DESKTOP_SESSION
gnome

XDG_CURRENT_DESKTOP
GNOME

XDG_SESSION_DESKTOP
gnome

XDG_SESSION_TYPE
wayland

Extensions (2)

Extension
Author (truncated)
Version

python
ms-
2023.22.1

vscode-pylance
ms-
2023.12.1

(1 theme extensions excluded)

Please check if the issue is present with our insiders version as well https://code.visualstudio.com/insiders/

After restarting my device and launching with Xorg, all of the Insider version bugs no longer persisted.


Modify to use Multi stage docker image

There is currently some issue with the OpenSSL compiled into the binary.
pr_demon_1  | [2017-06-16T05:05:42-0000][ERROR]  Error preparing PR Transformer: Error requesting for VCS fetch https://xxx/app/rest/latest/vcs-root-instances/checkingForChangesQueue?locator=buildType(id:bgp_UnitTests): The OpenSSL library reported an error: The OpenSSL library reported an error: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:

Probably related to https://github.com/japaric/cross/issues/119


Improvements for windows

[x]  Fix issue where command-line process would stay alive after exiting the app in certain cases
[x]  Fix issue where app title would be lowercase ("sidekick" instead of "Sidekick")
[x]  Fix issue where the default icon would appear when hovering over the app instead of the sidekick logo
[x]  Fix not being able to move or close the app when there is a DB error screen
[x] Improve winUI appearance to fit more windows apps
[x] Add mica effect to windows 11
[ ] Support automated release to MS Store
[ ] Disable Automatic updates on MS Store version

@aguilaair the fix I just made seems it was a previous regression for some fixes. It seems that the button to maximize and so on have disappeared on the mac

Okay so we have two options here.
We can either add the window control buttons to the sidekick UI or we can just not set the window as frameless on macos
What do you prefer?

Should be fixed now @leoafarias


Support Android Gradle Plugin 3.6.3 (Lint Level 6)

Probably as simple as updating these two?
https://github.com/littlerobots/rxlint/blob/c78d0b054faf47f02d053c2f090f65ea11d69efc/build.gradle#L12
https://github.com/littlerobots/rxlint/blob/c78d0b054faf47f02d053c2f090f65ea11d69efc/build.gradle#L20

This is tied to the lint API, correct and usually bumping that is enough. If you want to give it a go and PR it that would be appreciated, otherwise I'll take a look later!

Don't have much time, thanks for the quick response.
Note: please don't skip this in favor of #2, please release both separately as there could be projects who can't move yet to 4.0.

Quick testing looks like bumping the lint dependencies to the latest version should still work with 3.6.3, so bumping to latest shouldn't be an issue. I've pushed 1.7.6-SNAPSHOT to https://oss.sonatype.org/content/repositories/snapshots/ if you want to confirm this.

Please publish a version of RxLint for 3.6.3, because we cannot update to 4.0.0 yet and having a newer version also gives the same Lint warning:

I'm going to close this and not do anything for 3.5.x. The warning is just a warning and since there's no broken functionality I'd recommend to stay on 1.7.5 with the warning until you're able to upgrade to AGP 4.x and 1.7.6 which I will release in a bit.


Thanks for nothing. Made me laugh a bit. Keep this attitude and I'm sure you will have a lovely life ;)

Hi @Can-Sahin, just wanted to bring some balance here, and mention that in my company we have forked this boilerplate from the times it was not a cra template and we are keeping it up to date (it is now a cra template). This project has been invaluable to our org and we have started numerous projects, perhaps towards 20 that we still maintain. Basically this boilerplate has enabled us to become a 'growth team' for the analytics portion of our company.
Keep up the great work.
@Wasoop I have reported your account, I hope I never get to work with someone like you.


Change Sheet.sequences to an array

TODO
working on adding multiple sequences

Closing in favor of the upcoming expressions feature


Feature/kql functional tests 7

please merge to Kusto-phase2 , not Kusto-phase2-fixbug-1119

Sure, I just wanted to have a meaningful diff until your branch hadn't been merged.


traccar server

hi I read all the comments about traccar server, I download traccar for windows and traccar server which as soon as I download and run the traccar, server automatically comes in the traccar file. I can run traccar in the localhost:8082 with no problem. I wanna run it on my computer server. I did load the apache server and checked it runs.. I made my external ip static and my computer ip static.. and over my static computer ip I did forward ports (80, 443, 5005). so I don't know where to put traccar server files?? to run over my computer server.. seems like it I create a server and did everything right.. I want to be able to reach to my computer server to open traccar.. how that works pls help help

Closing as stale. Feel free to reopen if there are still some questions.


(1201b) Allow long audience tags

Context

Following the upgrade to govuk-frontend@5, the govuk-tag class includes a max width. In our prototype, longer tags are on two lines in the case list (for statuses), but audience tags are always on one line regardless of length
Changes in this PR

Add an audience-tag class to retain the single-line audience tags

Screenshots of UI changes
Before

After

Release checklist
Release process documentation
As part of our continuous deployment strategy we must ensure that this work is
ready to be released once merged.
Pre-merge

[ ] There are changes required to the Accredited Programmes API for this change to work...

[ ] ... and they have been released to production already

Post-merge

[ ] This adds, extends or meaningfully modifies a feature...

[ ] ... and I have written or updated an end-to-end test for the happy path in the Accredited Programmes E2E repo

[ ] This makes new expectations of the API...

[ ] ... and I have notified the API developer(s) of changes to the contract tests (Pact), or the API is already compliant

[ ] Manually approve release to preprod
[ ] Manually approve release to prod

 Upgrade govuk-frontend to v5 (S)

 UI Build - Dependency Issue (duplicate)


Release tracking PR: bitcoin 0.33.0-alpha.0

Needs release notes but there are 20 pages of them, that feels like too many to go through manually.

FTR this is the filter: https://github.com/rust-bitcoin/rust-bitcoin/pulls?q=is%3Apr+merged%3A>2024-04-23+

@tcharding what do you think we should do here? Want to write the release notes, or just say "it's an alpha release, whatever".
For transitioning from 0.32.x to 1.0 I think we're going to want to write a small book (or add a chapter to the existing book).

Would it be acceptable to put into the release nots links to the repo with filters e.g., https://github.com/rust-bitcoin/rust-bitcoin/pulls?q=is%3Aopen+is%3Apr+sort%3Aupdated-desc+Replace+Foo+with+foo  ?
If so we could list the important things individually then say "you might like to take a quick read of these PRs: filter-URL". Perhaps even a few different filters URLs

Yeah, I think that for an alpha release that's fine.
But I think we should work toward having a detailed "migration doc" so as we try upgrading projects to use it, we should take careful notes.

Ah if it has to be done I'll do it now. Definitely agree to writing the update notes as we test. I"ve started them already in the CHANGELOG and will continue to add to them.

Note for when we do the next alpha release:

Use search filter is:pr merged:>2024-04-23 (https://github.com/rust-bitcoin/rust-bitcoin/pulls?page=1&q=is%3Apr+merged%3A>2024-04-23)
The changelog in this PR includes everything up to #3689

This really seems like the kind of thing that should've failed before we got to the publishing stage..

Ouch, most definitely. I'll investigate why it wasn't caught earlier.

What happened is that we forgot to release base58ck but because of the patched repository manifest it was unnoticed by CI.
One way to catch this would be running cargo publish --dry-run before as part of doing release tracking PRs. And it turns out I can run it even though I don't have publish perms.


Test data sets

We need to develop a test data sets that can be used to ensure that changes to VIC do what they are supposed to do and do not have any unintended side consequences. I will open a series of issues for this, since we'll need different test datasets for different use cases. This issue will serve as the parent issue that can be closed when all the test data sets have been developed. Note that these test cases may need to be updated as we update VIC.
Eventual goal: Something that would allow us to run a series of automated tests after source code changes have been made to VIC (somewhat analogous to travis for compilation).
Note that:

Simplifying the number of options that are used within VIC will facilitate this testing configuration.

Small tests that test specific behaviors would be ideal (so they can help in isolating problems).

Test cases:

no change in output format or calculated values:

Comparison with prior VIC output

change in output format but no change in calculated values:

Comparison with prior VIC output

no change in output format but change in calculated values:

Comparison with prior VIC output
Comparison with observations

I'm getting close to being done with this work for this issue. How do we feel about putting these datasets in new github repo (https://github.com/UW-Hydro/VIC_test_data)? Total size of the datasets is about 1GB and I'd like to use git-lfs to store the data on github.
I currently have four datasets formatted into netCDF4 ready for the test module:

Stehekin sample dataset
Snotel (from Chiyu Lin)
Ameriflux towers
Rosemount sample dataset

Sounds good to me.
On Thu, Jul 23, 2015 at 11:12 AM, Joe Hamman<EMAIL_ADDRESS>wrote:

I'm getting close to being done with this work for this issue. How do we
feel about putting these datasets in new github repo (
https://github.com/UW-Hydro/VIC_test_data)? Total size of the datasets is
about 1GB and I'd like to use git-lfs https://git-lfs.github.com/ to
store the data on github.
I currently have four datasets formatted into netCDF4 ready for the test
module:

Stehekin sample dataset
Snotel (from Chiyu Lin)
Ameriflux towers
Rosemount sample dataset

—
Reply to this email directly or view it on GitHub
https://github.com/UW-Hydro/VIC/issues/79#issuecomment-124191346.

Same here - git-lfs may also be a good place for the SUMMA test data. I wasn't aware that they already started this (I know it was in the works)

partially completed by #387
follow up PRs will add science and release test datasets.

@dgergel's science testing PR has just been merged (#544).  With that done, we just have to put all the test datasets together in one place. I'll work with @dgergel to pull this together.  For now, let's just create a directory on our groups FTP.  We'll want to put the science and release data in there so we can all start using it.


[Bug] Truncated Data Label in Datazoom component

Version
5.3.2
Link to Minimal Reproduction
https://codesandbox.io/s/xvivf1?file=/index.js
Steps to Reproduce
add datazoom-slider to a chart
Current Behavior
Data label is truncated when there's no enough space

Expected Behavior
Data labels should be shown adaptively. When there's no enough space to the left of the handle, the data label should be shown on the right, and vice versa, just like the pic below.

Environment
- OS:win 11
- Browser: chrome 111.0.5563.111

Any additional comments?
No response

Not a fix, but a relief, is to use dataZoom: [{ textStyle: { width:77, overflow: 'break' } }]

Seems still need some solution, for example echarts demo


Update multiple connector configmaps

Hi,
I tried add,update,delete multiple connector configmaps in the same git commit but the connect-operator did not execute all configmaps that were changed. The operator only process the first event in the binding-context. I can create pull request to enhance the connect-operator.
Thanks

@oun LMK if you'd like me to look at any issues you found w/ the connect-operator.  Thank you for evaluating the project

I have multiple configmaps. For example:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
configMapGenerator:
  - name: source-connector
    files:
      - source-connector.json=source-connector.json
  - name: sink-connector
    files:
      - sink-connector.json=sink-connector.json
  - name: outbox-connector
    files:
      - outbox-connector.json=outbox-connector.json
generatorOptions:
  disableNameSuffixHash: true
  labels:
    destination: connect

When I update all connector config files and apply it to cluster, the connect operator did not update all the connectors. I found that the binding context contained multiple events but the hook::run function get only the first object in the binding context.
Thank you

I have multiple configmaps. For example:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
configMapGenerator:
  - name: source-connector
    files:
      - source-connector.json=source-connector.json
  - name: sink-connector
    files:
      - sink-connector.json=sink-connector.json
  - name: outbox-connector
    files:
      - outbox-connector.json=outbox-connector.json
generatorOptions:
  disableNameSuffixHash: true
  labels:
    destination: connect

When I update all connector config files and apply it to cluster, the connect operator did not update all the connectors. I found that the binding context contained multiple events but the hook::run function get only the first object in the binding context.
Thank you

Thank you @oun, let's keep this issue open and I will attempt to resolve it at a later time.  Maybe it could be solved by "exploding" the array and running the bash functions instead of just indexing to the first item

We have this problem as well.


Feature/ndc country document dropdown

This PR adds a dropdown that selects a document from the country NDC page

The Full document link is now always a button that is linked to the document selection
Both summary and accordion data is updated with the document selection
When we start without a document the last document available is filled into the URL param. This is necessary for the filtering and the link
The dropdown is only showing the English documents as we only have the information in English for this page. Once on the full page, you can select different languages.

Try: Go to an NDC country page and change the document, country, tab, go to the full document, ...

Is the FIRST option descriptive enough? Shouldn't we set FIRST NDC or something?

Let's merge this. I think the 'First' problem is about a wrong data. It should be 'first-ndc' translated to 'FIRST NDC'


fix gc log variable judge in jdk8

Motivation
The judge sentences of if is reversed, can not work in jdk8.
Modifications
Fix the judge sentences.

/pulsarbot run-failure-checks


Nflog support MVP

Hello
This adds the support for basic use of the nflog protocol. There are still some parts missing, but I'd prefer to have a feedback about it sooner than later and I tried to make sure all the missing pieces can be added without breaking API.
I've also tried to structure it in a way that makes it possible/natural to add all the other netfilter protocols over time (NFQUEUE, CONNTRACK).
There are, however, few things I'm not entirely happy about or don't know how to handle properly. I'll probably open separate issues to discuss them one by one, if there's some nice solution for them. But I'll still list my worries here first.

When receiving messages over the socket, I have to specify into what type I want them to deserialize. But this might depend on the type. This can be seen on the added example, sometimes I get a message with type 3 ‒ which I think corresponds to NLMSG_DONE. I'm not sure if I should make it part of the new NetfilterMsg enum, but that would still not help much, because it would still try to deserialize the rest as LogPacket. This doesn't currently fail, but is kind of wrong. It would be great if I could somehow specify a nl-type => parse type relation. Unlike NlAttr<_, Vec<u8>>, the Nlmsghdr<_, Vec>` doesn't have methods to parse as one or another type.
Some of the structs/messages are ever sent in only one direction. So it makes no sense to provide eg. serialize for the LogPacket. For now, I've put unimplemented in them, but it kind of doesn't feel right. Would it make sense to split the Nl trait into reading and writing halves?
The crate uses the Vec type quite generously. For example, when parsing a message, it allocates a Vec as the receive buffer, then it allocates a Vec for all the attributes and, as they have diffferent types, each one is a smaller Vec... As the Vec contains a heap allocation, it might turn somewhat expensive. This probably doesn't matter for things like manipulating the routing table, but with the NFLOG, the number of packets received per second can be quite huge. It would be great if there was a way to use the library with smaller number of allocations (some of my ideas could get down to 0 per packet).
The impl_* macros don't want to let me put documentation onto the individual variants. I've tried to poke at them a little bit, but I've managed to only break existing code, so I've given up for now.

Anyway, if I'm missing anything important here, or if there's any way to improve the code or interface, I'm happy to hear it. I'd then add some fixup commits and rebuild the branch before merging.

Linking here #37, the macros...

CI can't compile libc :-(.

Note to self. I've just discovered methods like u32::to_be. This means all the htons are not necessary and I'll get rid of them in a fixup some time soonish.

Restart CI here too.

CI is fixed.

Hi @vorner, thanks for your other contribution. I've merged that PR so can you rebase onto master and force push here? I'll do one final review before merging.


Extend svg.arc.padAngle parameters.

Description of the change
The padAngle function accepted a single number previously, but now accepts an array of two values too, in which case the left and right pad angle are set separately as specified in the array. This allows for the creation of sunburst charts with straight separation edges. Of course, the padAngle can still return an accessor function, that can return an array.
Reason for the change
This was something I needed in a project, but it was not possible to do this without changing D3 code. Hopefully, my changes can (after some feedback) be of use to others too.
The fundamental problem is that when one applies a gap between arcs in a partition using some definition in radians, a wedge-shaped gap is formed. The existing padAngle implementation handles this nicely already, by making the inner and outer padding slightly different, so that a straight edge gap is formed. However, it is not possible to extend this gap to outer rings, because a segment always has a padding both to the left and right of it. This change makes it possible to set the padding for the left and right side of a segment separately.
Demo / application of the change
This bl.ocks.org demo demonstrates what I needed in my project, using some made up data. Notice how the padding between segments in the inner ring extends to the outer ring, while the segments in the outer ring do not have inner padding.
Remarks
I noticed how there is a lot of functionality stuffed in that function already ( :-) ), so some things may not work well together with this change (like rounded segment corners). However, all existing tests still pass. I am just not really sure how to write tests, so I would really appreciate some pointers if tests are desired (and I assume they are).
All feedback is appreciated and I am definitely willing to make (big) changes if necessary :-)

I took a stab at this for 4.0 in d3/d3-shape#42. Before:

After:

There’s still some work to-do, and I need to think through whether this is the right API. Also, there’s the issue that applying constant padding to arcs disproportionately penalizes small arcs, so it makes me wonder if the partition layout should support padding so as to preserve relative areas. (See d3/d3-hierarchy#19 for a description of a similar problem with the treemap layout.)

Thank you for considering this change!
Indeed the API could be better, as it was for personal use only I just went with this. Very interesting to see the changes you are making, it looks promising. I agree with the penalizing of small arcs, it would be awesome to have D3 take care of that. At the moment I am kind of busy, but if there is anything I can help with, tinker around a bit, just let me know :-)

Merging into d3/d3-shape#42.


Add manifest entries in jar to make it a valid OSGi bundle

assertj-core is a valid OSGi bundle, assertj-guava is not.
Only a few headers must be added in the MANIFEST.MF file.
This would allow to use assertj-guava in an OSGi environment!

agreed


unused-variable (N806) false positive on non-global type aliases

Foo = int | str # no error

def foo():
    Bar = int | str # error: Variable `Bar` in function should be lowercase

We can probably only support avoiding this when marked as Bar: TypeAlias (which I'd recommend).


[FEA] Nice to have: resource spec generation to be platform independent

https://github.com/rapidsai/rapids-cmake/blob/965321ee8323f77ffaa1bd6ff825d12245d55cd3/rapids-cmake/test/generate_resource_spec.cmake#L80
Can we make this platform independent? (to support windows compilation)
Here is a suggestion.
    set(pre_cmd ";")
    if(MSVC)
      set(pre_cmd "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Auxiliary\\Build\\vcvars64.bat")
    endif()

    execute_process(COMMAND "${pre_cmd}" "&&" "${compiler}" "${eval_file}" ${compile_options} ${link_options} -o
                            "${eval_exe}" OUTPUT_VARIABLE compile_output
                    ERROR_VARIABLE compile_output COMMAND_ECHO STDOUT)

Related https://cmake.org/pipermail/cmake/2016-June/063685.html

We can't encode the location of vcvars64 like that since the location is selected by the user ( and also based on the MSVC version ). The && aren't supported in execute_process as you aren't in a shell.
You should execute rapids-cmake from a shell that already has vcvars64.bat invoked, e.g. a Visual Studio developers shell.


New style square function

This PR implements new style square function.
I also fixed unary_math_function_test decorator to support testing FunctionNode.
I think this is transitional; once https://github.com/chainer/chainer/pull/3499 got merged, it is better to rewrite tests with the new function test template.

We should follow API compat policy for unary_math_function_test, so my previous comment does not suit.

Ok, thank you for confirmation!

It would be more natural for Chainer to let unary_math_function_test take a Python function instead of a FunctionNode object as @beam2d mentioned on slack.
https://github.com/chainer/chainer/compare/master...takagi:fix-test-math-function
Here unary_math_function_test accept a Function object just for backward compatibility and we would be able to deprecate it in the future major bump. (I will update the docstring shortly)
How about this?

Thank you for the suggestion, it looks good to me.

I posted a PR to fix unary_math_function_test to support new style functions as #3603. Would you rebase your change on top of it after it will have been merged into the master? Before that, you can leave this PR.

Rebased.

LGTM!


idrisPackages.build-idris-package: Install binaries

Motivation for this change
https://discourse.nixos.org/t/buidling-hello-world-in-idris/2793
Things done

[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"
[ ] 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)
[ ] Assured whether relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

This pull request has been mentioned on Nix community. There might be relevant details there:
https://discourse.nixos.org/t/buidling-hello-world-in-idris/2793/2


Cont. More query tests

make use of a xUnit Collection Fixture to stop and start the test database.
it now starts the DB in memory mode as we do not want to keep the data after the tests have completed.
Also added some more test, some are failing

@all-contributors add @Du-z for bug ideas

@ProphetLamb
Left on my list for tests are:

Multiple result set handing
Converters testing
Add a few more types to the roundtrip test

DateTimeOffset
DateOnly
TimeOnly
Arrays
Objects


Adding feedback form

Create a feedback form to collect user input and improve website features. The form should include the following:
Input fields for name, email, and feedback message.
A star rating system for user satisfaction.
Form validation to ensure all fields are correctly filled before submission.
A responsive design that works seamlessly on all devices.
A success/failure message after form submission.

Please assign this task to me.

i want to work on this issue .assign me this project


Moving from NSwag to Swashbuckle

This is not so much of an issue, as a report of an attempt to move a nontrivial API with generics and inheritance from NSwag (13, 14-preview) to Swashbuckle 6.5.0 and describe the problems we had to solve to make the OpenAPI.json generation and the Swagger UI working "almost" as expected. Even after these problems were solved, issues remain.
Ambiguous types
The schema IDs of nested types and templated types are problematic with Swashbuckle (NSwag doesn't have this problem, but sometimes appends a number to the type name, which is confusing.)
After examining various solutions, we came up with this:
            c.CustomSchemaIds(SwashBuckleUtils.ToSchemaId);

The source for SwashBuckleUtils is shown at the end of this text. This seems to resolve most of our issues.
Inheritance and polymorphism
We first tried with:
            c.UseAllOfForInheritance();
            c.UseOneOfForPolymorphism();

The net effect is that the SwashBuckleUtils.ToSchemaId got called over 1500 times with almost all runtime types and generic types that our API ever used. When we tried:
            c.EnableAnnotations(enableAnnotationsForInheritance: true, enableAnnotationsForPolymorphism: true);

... it appeared to work correctly, even though setting both parameters to true ends up calling both c.UseXxxxForYyy methods.
It took a while before we figured out that in addition, the EnableAnnotations also calls:
                options.SelectSubTypesUsing(AnnotationsSubTypesSelector);
                options.SelectDiscriminatorNameUsing(AnnotationsDiscriminatorNameSelector);
                options.SelectDiscriminatorValueUsing(AnnotationsDiscriminatorValueSelector);

This limits the types greatly. But the delegate methods are private and cannot be called by user code.
Another problem is that NSwag automatially handles KnownTypeAttribute. In SwashBuckle, we needed to write:
        c.SelectSubTypesUsing(SwashBuckleUtils.AnnotationsKnownTypesSelector);

The source code can be found below.
Enum serialization
By default, ASP.NET Core serializes enums as their underlying scalar value (usually int). And yet, they are specified correctly in the generated OpenAPI.json document. Generated C# clients will reproduce the enums with their correct values.
Switch to Swashbuckle changing nothing else, the enums will be specified according to the way they are serialized. This means that a type like LogLevel will appear like this:
public enum LogLevel
    {
        _0 = 0,
        _1 = 1,
        _2 = 2,
        _3 = 3,
        _4 = 4,
        _5 = 5,
        _6 = 6,
    }

The only way to change that is to change the way enum is serialized in the API:
        services.AddControllers(opt =>
        {
            ...
        })
            .AddJsonOptions(options =>
            {
                // we need to add this to have the same behavior in SwashBuckle as NSwag
                options.JsonSerializerOptions.Converters.Add(new JsonStringEnumConverter());
            });

... but this means that all enums will now be strings, which are usually larger and therefore the data transfer will be larger as well!
No solution was found for this problem.
Closing thoughts
Issues remain. The generated OpenAPI inists on including System.TimeSpan and we don't understand why. There are other things with nullable types we cannot explain.
The ability to generate OpenAPI specifications from an ASP.NET Core API is one of the cornerstones of the current way we develop software and publish API's. It seems that we only have two options today: NSwag and Swashbuckle.
Both initiatives were started and are maintained by courageous and extremely smart people. It's complex software that needs to solve a complex problem. It seems strange to us that Microsoft doesn't realize this, and tries to help either (or both!) in achieving usage and feature parity with each other, and move both projects forward. They both have merit.
They did this with Json serialization (James Newton-King works for Microsoft now, and Microsoft has System.Text.Json). The did it with Polly (it's now integrated as part of their resilience features in .NET 8). They've integrated zlib (for ZIP/GZ (de)serialization.
It is a puzzle to us why they can't help out more for NSwag/Swashbuckle.
In any case, I hope this little experience overview and the source code below is of use to somebody.
Source code of SwashBuckleUtils:
static class SwashBuckleUtils
{
    private static readonly Dictionary<Type, string> _map = new Dictionary<Type, string>();

    private static string ToSchemaId(Type type, bool skipDeclaringType)
    {
        if (!_map.TryGetValue(type, out var name))
        {
            if (type.IsGenericType && !type.IsGenericTypeDefinition)
            {
                var genericTypeName = type.GetGenericTypeDefinition().Name;
                // Check if it's a real generic type. Non-generic types nested in generic types will also have IsGenericType() == true but won't have a '`' in their name
                // "Real" generic type names must be trimmed to exclude everything after '`' including that character.
                int p = genericTypeName.IndexOf('`');
                if (p > 0)
                    genericTypeName = genericTypeName[..p];
                name = $"{genericTypeName}Of{string.Join("And", type.GetGenericArguments().Select(t => ToSchemaId(t, skipDeclaringType: true)))}";
            }
            else
            {
                // the .Replace() handles the case of nested types, since '+' is not a valid schema id character
                name = type.Namespace + '.' + type.Name.Replace('+', '_');
                if (type.DeclaringType is not null && !skipDeclaringType)
                    name = ToSchemaId(type.DeclaringType) + '_' + name;
            }
            _map[type] = name;
        }
        return name;
    }

    public static string ToSchemaId(Type type)
    {
        var name = ToSchemaId(type, skipDeclaringType: false);
        return name;
    }

    public static IEnumerable<Type> AnnotationsKnownTypesSelector(Type type)
    {
        var subtypes = new List<Type>();

        foreach (var knownTypeAttribute in type.GetCustomAttributes(false).OfType<KnownTypeAttribute>())
        {
            if (knownTypeAttribute.Type is not null)
                subtypes.Add(knownTypeAttribute.Type);
            else if (knownTypeAttribute.MethodName is not null)
                throw new InvalidOperationException($"{type}: KnownType(\"{knownTypeAttribute.MethodName}\") is not supported");
        }

        return subtypes;
    }
}

Hi @vvdb-architecture
Honestly I'm not sure you can recommend switching at this point, this repository has not seen a commit in 11 months, it might be going out of support (we don't know).

Have you tested with https://github.com/Havunen/DotSwashbuckle https://www.nuget.org/packages/DotSwashbuckle.AspNetCore ?

If you still experience issues after trying out DotSwashbuckle, I might be able to fix those issues if you open separate issue for each of them with enough information and expected result defined

I've been comparing Swashbuckle and NSwag here: https://github.com/harvzor/swashbuckle-vs-nswag
@Havunen I appreciate that someone is attempting to take over the reigns when it comes to Swashbuckle maintenance but I'm not sure if it's worth getting people to switch over to a new repo which has less than a week of development on it - it could become abandoned just like Swashbuckle 😬
I really wish Microsoft or some other large company would come in to take care of Swagger in dotnet

FYI: https://github.com/domaindrivendev/Swashbuckle.AspNetCore/discussions/2778


Adds: delete edge-app command - same as screen deletion

Refs https://phorge.wireload.net/T7415
Same as screen deletion - ask for name promt before deletion
screenly edge-app delete

@vpetersson discussed with @sergey-borovkov and decided not to do it.
Let me know if we actually want to do this.

What's the rational? We currently don't enforce app name to be unique, right?

Right so then we can't use this approach. We much change it to use the app id. Id say @MuratUrsavas suggestion plus app id seems reasonable.

@vpetersson I'm not sure I'm following.

suggestion from @MuratUrsavas was in another PR, https://github.com/Screenly/cli/pull/95 and it is cause PR description was wrong - update uses '--name=' of course not 'name=', so it is not relevant.

Deletion already happens by app_id - either '--app_id=' or if not passed, from manifest in current folder. Name input is just to confirm deletion and not allow it happen instantaneusly when calling delete command for instance accidently.

So only question left is if we need to delete screenly.yml on delete or delete app_id there or delete whole folder.
@sergey-borovkov said we shouldn't, I don't have strong opinion here - let me know if we should.

Right so then we can't use this approach. We much change it to use the app id. Id say @MuratUrsavas suggestion plus app id seems reasonable.

The name is just for confirmation. You delete with id.
I don't think we should remove anything from the disk. Makes no sense to me to be honest.


Add UF2 output file generation

Various devices are now shipping w/ UF2 compatible bootloaders. We've been hacking this into Zephyr ourselves w/ per-board post build commands for ZMK, but this adds proper upstream support for building UF2 files as part of the output, and adds support for the seeeduino_xiao board which has the BOSSA UF2 bootloader.
Tested locally building the samples/basic/blinky sample, double tapping reset, then cp build/xiao/zephyr/zephyr.uf2 /run/media/peter/Arduino and it is happily blinking away.
Adds new BUILD_OUTPUT_UF2_FAMILY_ID Kconfig setting for the family ID needed: https://github.com/Microsoft/uf2#family-id
The only thing I have an open question about would be the west.yml changes. I assume before merging the standard is to fork the upstream project into zephyrproject-rtos?
TIA!

AFAICT this would enable Zephyr on a large number of Adafruit Nordic boards @carlescufi.
If true, I'd very much like to see this merged.  Let me know if there's something I can do to help.

AFAICT this would enable Zephyr on a large number of Adafruit Nordic boards @carlescufi.
If true, I'd very much like to see this merged.  Let me know if there's something I can do to help.

AFAICT this would enable Zephyr on a large number of Adafruit Nordic boards @carlescufi.
If true, I'd very much like to see this merged. Let me know if there's something I can do to help.

That is correct. This is based on our initial hacky post build command work we've done in https://github.com/zmkfirmware/zmk for now to support boards using that exact bootloader. Trying to "do this right" by getting this merged into Zephyr proper.

AFAICT this would enable Zephyr on a large number of Adafruit Nordic boards @carlescufi.
If true, I'd very much like to see this merged. Let me know if there's something I can do to help.

That is correct. This is based on our initial hacky post build command work we've done in https://github.com/zmkfirmware/zmk for now to support boards using that exact bootloader. Trying to "do this right" by getting this merged into Zephyr proper.

Will review after @tejlmand's blocking change requests are addressed, as testing before that won't be much use.

Will review after @tejlmand's blocking change requests are addressed, as testing before that won't be much use.

My plan is to rework this once #30904 is in.

My plan is to rework this once #30904 is in.

My plan is to rework this once #30904 is in.

It's in now @petejohanson

My plan is to rework this once #30904 is in.

It's in now @petejohanson

My plan is to rework this once #30904 is in.

It's in now @petejohanson

@carlescufi I think we also need a Zephyr fork, as mentioned: https://github.com/zephyrproject-rtos/zephyr/pull/31066#pullrequestreview-566146871

My plan is to rework this once #30904 is in.

It's in now @petejohanson

@carlescufi I think we also need a Zephyr fork, as mentioned: https://github.com/zephyrproject-rtos/zephyr/pull/31066#pullrequestreview-566146871

@tejlmand @pabigot @carlescufi @pabigot
Ok, I've just reworked this based on the new modules work.
Since we don't yet have the fork of the uf2 repo, the west.yml changes are still as is.
This assumes the following:

Checkout this PR.
Run west update
mkdir tools/uf2/zephyr
Add tools/uf2/zephyr/module.yml file with cmake-ext and kconfig-ext set to True
Build w/ the seeeduino_xiao, e.g. west build -d build/xiao -b seeeduino_xiao samples/basic/blinky

I've only updated the XIAO for this, since it is one known good board in upstream Zephyr that comes OOTB w/ a UF2 enabled bootloader.
If everyone is happy, and can get the uf2 repo forked into Zephyr's org, I can update the west.yml appropriately.
Thanks again!

@tejlmand @pabigot @carlescufi @pabigot
Ok, I've just reworked this based on the new modules work.
Since we don't yet have the fork of the uf2 repo, the west.yml changes are still as is.
This assumes the following:

Checkout this PR.
Run west update
mkdir tools/uf2/zephyr
Add tools/uf2/zephyr/module.yml file with cmake-ext and kconfig-ext set to True
Build w/ the seeeduino_xiao, e.g. west build -d build/xiao -b seeeduino_xiao samples/basic/blinky

I've only updated the XIAO for this, since it is one known good board in upstream Zephyr that comes OOTB w/ a UF2 enabled bootloader.
If everyone is happy, and can get the uf2 repo forked into Zephyr's org, I can update the west.yml appropriately.
Thanks again!

Any thoughts on this?

Any thoughts on this?

Any thoughts on this?

A lot of us are pretty focused on the stabilization phase for 2.5 right now, so we may not get to this until 2.5.0 closer to being ready for the release in the second week of February.  (At least, I probably won't look at this until then.)

Any thoughts on this?

A lot of us are pretty focused on the stabilization phase for 2.5 right now, so we may not get to this until 2.5.0 closer to being ready for the release in the second week of February.  (At least, I probably won't look at this until then.)

Any thoughts on this?

Could you please state which repository exactly you need forked, what it provides to Zephyr and which changes do you expect to have in it?

Any thoughts on this?

Could you please state which repository exactly you need forked, what it provides to Zephyr and which changes do you expect to have in it?

Repo: https://github.com/microsoft/uf2
Why needed: It contains a python script, https://github.com/microsoft/uf2/blob/master/utils/uf2conv.py that can convert a bin/hex to a UF2 file. This is as authoritative a conversion tool that I've found, and being python, is easy for us to use.
The only modification needed is the creation of one file zephyr/module.yml which should contain;
build:
  cmake-ext: True
  kconfig-ext: True

This is based on the work in #30904.
With this in place, the extra CMakeLists.txt added in this PR will work along w/ the few extra Kconfig settings, to build UF2 files as an extra post build step.

@carlescufi  please make the zephyr/module.yml file as:
name: uf2

build:
  cmake-ext: True
  kconfig-ext: True

Repo: https://github.com/microsoft/uf2
Why needed: It contains a python script, https://github.com/microsoft/uf2/blob/master/utils/uf2conv.py that can convert a bin/hex to a UF2 file. This is as authoritative a conversion tool that I've found, and being python, is easy for us to use.

Thanks for explaining. But does it make sense to fork a whole repo just for that single scripts in a utils/ folder?

I don't particularly care. The only advantage I would see would be easier integration of future changes upstream. If you take a look, that script had updates 15 days ago to add the RP2040 family, so changes to support more families would require occasional updates to the version we integration into Zephyr.
Whether those updates take the form of a repo fork, or a copy of a single file into Zephyr, I'll defer to others.

I don't particularly care. The only advantage I would see would be easier integration of future changes upstream. If you take a look, that script had updates 15 days ago to add the RP2040 family, so changes to support more families would require occasional updates to the version we integration into Zephyr.
Whether those updates take the form of a repo fork, or a copy of a single file into Zephyr, I'll defer to others.

OK. I will mark this particular PR with the TSC label, since we are coincidentally discussing this very matter there.

Any possibility of asking microsoft to stick this in pip?

Any possibility of asking microsoft to stick this in pip?
microsoft/uf2#42

Yeah, this would be a much nicer way of handling this. Curious what they say. Given the 2.5 timeframe... Is there some temporary measure possible pending pip publish? (those 'p's were fun to write!)

Yeah, this would be a much nicer way of handling this. Curious what they say. Given the 2.5 timeframe... Is there some temporary measure possible pending pip publish? (those 'p's were fun to write!)

This is already too late for 2.5 at this point.  We're in bug fix only phase.

Thanks for explaining. But does it make sense to fork a whole repo just for that single script in a utils/ folder? It's also a pretty simple script, why not just take it and place it in our scripts/ folder in the main tree?

Good point, I didn't notice that it's only a single file we need for this purpose.
In that case, if this gets solved https://github.com/microsoft/uf2/issues/42 that would be a much nicer approach, and until then a local copy of the script under scripts might be the cleanest solution, as there will be no need for creation of an extra project in peoples west workspaces, just to end with a dangling repo when later switching to PyPI and that repo is removed from west.yml.

Thanks for explaining. But does it make sense to fork a whole repo just for that single script in a utils/ folder? It's also a pretty simple script, why not just take it and place it in our scripts/ folder in the main tree?

Good point, I didn't notice that it's only a single file we need for this purpose.
In that case, if this gets solved microsoft/uf2#42 that would be a much nicer approach, and until then a local copy of the script under scripts might be the cleanest solution, as there will be no need for creation of an extra project in peoples west workspaces, just to end with a dangling repo when later switching to PyPI and that repo is removed from west.yml.

I'm happy to do this. If we go this route, can I just integrate the build changes into the core CMake stuff as it was before, and skip the module approach?

I'm happy to do this. If we go this route, can I just integrate the build changes into the core CMake stuff as it was before, and skip the module approach?

Correct, and thank you for your patience.

Any possibility of asking microsoft to stick this in pip?
microsoft/uf2#42

Yeah, this would be a much nicer way of handling this. Curious what they say. Given the 2.5 timeframe... Is there some temporary measure possible pending pip publish? (those 'p's were fun to write!)

@petejohanson In the meantime, could you please remove the changes to west.yml and import the script directly in scripts/?

@petejohanson we agreed in the TSC to move forward with this with the uf2conv.py imported manually into zephyr's scripts/ folder.

@tejlmand @carlescufi Done and done, Only modifications I made to the script was to add a license identifier comment, and a comment indicating the exact sha1 and location where the script was copied from.
Thanks again.

So... is there a way to make the compliance the license checks happy with this?
I've just read through https://docs.zephyrproject.org/latest/contribute/index.html#identifying-contribution-origin and updated the commit that brings in uf2conv.py to hopefully have all the correct metadata in the commit body.

So... is there a way to make the compliance the license checks happy with this?

Add an entry to CODEOWNERS for this file:

ERROR   : Test Codeowners failed: New files added that are not covered in CODEOWNERS:
scripts/uf2conv.py

Maybe disable the pylint warnings using # pylint: disable=<warning> , as this script originates from another place.

ERROR   : Test pylint failed: ************* Module uf2conv
Running pylint           tests in /home/runner/work/zephyr/zephyr ...
scripts/uf2conv.py:203:0: W1401: Anomalous backslash in string: '\s'. String constant might be missing an r prefix. (anomalous-backslash-in-string)
scripts/uf2conv.py:84:11: C0121: Comparison to None should be 'expr is None' (singleton-comparison)
2 checks failed
scripts/uf2conv.py:104:4: C0200: Consider using enumerate instead of iterating with range and len (consider-using-enumerate)
scripts/uf2conv.py:177:15: C0121: Comparison to None should be 'expr is None' (singleton-comparison)
scripts/uf2conv.py:221:8: W0702: No exception type(s) specified (bare-except)
scripts/uf2conv.py:306:15: C0121: Comparison to None should be 'expr is None' (singleton-comparison)

So... is there a way to make the compliance the license checks happy with this?

You can just have someone with merge rights merge and not worry about the compliance issues with the python script.

So... is there a way to make the compliance the license checks happy with this?

Add an entry to CODEOWNERS for this file:

ERROR   : Test Codeowners failed: New files added that are not covered in CODEOWNERS:
scripts/uf2conv.py

Maybe disable the pylint warnings using # pylint: disable=<warning> , as this script originates from another place.

ERROR   : Test pylint failed: ************* Module uf2conv
Running pylint           tests in /home/runner/work/zephyr/zephyr ...
scripts/uf2conv.py:203:0: W1401: Anomalous backslash in string: '\s'. String constant might be missing an r prefix. (anomalous-backslash-in-string)
scripts/uf2conv.py:84:11: C0121: Comparison to None should be 'expr is None' (singleton-comparison)
2 checks failed
scripts/uf2conv.py:104:4: C0200: Consider using enumerate instead of iterating with range and len (consider-using-enumerate)
scripts/uf2conv.py:177:15: C0121: Comparison to None should be 'expr is None' (singleton-comparison)
scripts/uf2conv.py:221:8: W0702: No exception type(s) specified (bare-except)
scripts/uf2conv.py:306:15: C0121: Comparison to None should be 'expr is None' (singleton-comparison)

Done, and done. Thanks.

@petejohanson nice!
Can I suggest you consider adding a mass storage runner which takes advantage of this so west flash does the right thing here? I haven't had time to do this and I think it'd be pretty cool.
You would need to add a uf2_file field in the RunnerConfig tuple in zephyr/scripts/west_commands/runners/core.py, then add a runner which copies that file to the "right" mass storage device.
I don't know how these devices appear on the platforms you're interested in. I would hope there'd be a cross-platform way to discover the potential ones at runtime and either flash to the only one that's present, or prompt the user to pick one, similarly to now the nrfjprog runner runs nrfjprog --ids to figure out which J-Link devices are candidates for flashing an nRF board.
Just spitballing potential future improvements. I am definitely not trying to block this PR, which I know you've been patiently waiting for merge on for a while.

@petejohanson nice!
Can I suggest you consider adding a mass storage runner which takes advantage of this so west flash does the right thing here? I haven't had time to do this and I think it'd be pretty cool.

Yes, this has definitely been on my radar as a next step.

You would need to add a uf2_file field in the RunnerConfig tuple in zephyr/scripts/west_commands/runners/core.py, then add a runner which copies that file to the "right" mass storage device.
I don't know how these devices appear on the platforms you're interested in. I would hope there'd be a cross-platform way to discover the potential ones at runtime and either flash to the only one that's present, or prompt the user to pick one, similarly to now the nrfjprog runner runs nrfjprog --ids to figure out which J-Link devices are candidates for flashing an nRF board.

Yeah, I've been pondering this aspect too. On my Fedora laptop, they end up auto mounted at /run/media/peter/FOO, Windows some device letter, macOS not sure. Hoping maybe there is an existing python library I could leverage.

Just spitballing potential future improvements. I am definitely not trying to block this PR, which I know you've been patiently waiting for merge on for a while.

No worries!

I think this is a good enhancement that will make Adafruit boards a lot easier to use in Zephyr.

There's quite a few other boards supporting UF2 natively now, including the RP2040, which support UF2 from their default/onboard bootloader.

Please fix the commit messages:
feat(build): Add UF2 family IDs for registered SoCs.

is not how we format these.
soc: Add UF2 family IDs for supported SoCs

It's also unusual to make the commit messages lists of changes.  Free-form text is standard.
The Purpose: and Maintained-By: lines should be removed from the cmake:  commit; the purpose should be in the description, and once it's in Zephyr its Zephyr that maintains it.  The commit message could/should document that the expectation is this is unmodified from the source repository version.

Will do.

I think this is a good enhancement that will make Adafruit boards a lot easier to use in Zephyr.

There's quite a few other boards supporting UF2 natively now, including the RP2040, which support UF2 from their default/onboard bootloader.

OK.  BTW my block is solely on this stuff:

Please fix the commit messages:
ory version.

Will do.

For the other point of contention (defaulting BUILD_OUTPUT_UF2_FAMILY_ID based on SOC) , based on all discussion so far just putting the defaults as text identifiers in Kconfig.zepyhyr where config BUILD_OUTPUT_UF2_FAMILY_ID is introduced seems the most maintainable.  It's not like it's hundreds of lines.
But if it has to be squirreled away in an include file under modules/ that's not something I'd block on.  (I would block on using the hex constants instead of the text identifiers from the uf2 script, unless we actually need the hex constants explicitly.)

But if it has to be squirreled away in an include file under modules/ that's not something I'd block on.  (I would block on using the hex constants instead of the text identifiers from the uf2 script, unless we actually need the hex constants explicitly.)

I was going to comment on this. It seems like going with the family name alias, instead of the actual hex value ties us to an implementation detail of uf2conv.py, which seemed good to avoid. The actual hex value seems to be a fixed thing, is the friendly name alias?
I don't care strongly either way, just a thought.
Should a wait for concensus on where to put the defaults?

I was going to comment on this. It seems like going with the family name alias, instead of the actual hex value ties us to an implementation detail of uf2conv.py, which seemed good to avoid. The actual hex value seems to be a fixed thing, is the friendly name alias?

Is there a registry of known identifiers that is more canonical than the uf2conv script?  In a quick search I didn't find one.
Is there an alternative to uf2conv.py that has any market share?
If the answers are "no" and "no", then for now I'd say that script is the reference definition, and using the names it supports should be pretty stable.

Should a wait for concensus on where to put the defaults?

Couldn't say.  I'm not sure if @tejlmand is open to anything other than what he's proposed, but that solution is something I'm willing to accept.  So I guess just run with it and see if we can get this merged before my Clue boards arrive this week.

I was going to comment on this. It seems like going with the family name alias, instead of the actual hex value ties us to an implementation detail of uf2conv.py, which seemed good to avoid. The actual hex value seems to be a fixed thing, is the friendly name alias?

Is there a registry of known identifiers that is more canonical than the uf2conv script? In a quick search I didn't find one.

Actually, yes. The toplevel README.md in the uf2 repository lists more chosen IDs than have aliases in the uf2conv.py script. In particular, the ESP32 family ID (0x1c5f21b0) doesn't have a corresponding alias. This may be oversight, on the part of the maintainers there, but it points to a bit of a disconnect.

Is there an alternative to uf2conv.py that has any market share?

No that I've seen, but I haven't gone looking.

If the answers are "no" and "no", then for now I'd say that script is the reference definition, and using the names it supports should be pretty stable.

Should a wait for concensus on where to put the defaults?

Couldn't say. I'm not sure if @tejlmand is open to anything other than what he's proposed, but that solution is something I'm willing to accept. So I guess just run with it and see if we can get this merged before my Clue boards arrive this week.

I'm going to update to put them inline in Kconfig.zephyr to start, it's easy enough to then move that to a separate (single) file if requested.

@pabigot @tejlmand Ok, pushed a rebased/updated version.

Defaults put in Kconfig.zephyr. Let me know if there is consensus on a different location, I'll happily move it.
Fixes up commit message based on @pabigot feedback.
Does not switch to the "friendly name" for the family ID defaults, pending some continued discussion w/ @pabigot. I don't have a strong opinion on this, just answering some follow up questions before switching. @pabigot if you still want me to switch to the name alias for those the script supports, let me know.

I'm fine with the hex constants under the argument that the canonical source for the mapping is the identified URL.  You need to add a signed-off-by to that commit.
Also my comments on commit format also applied to the third commit, which still has feat(board) with a list-format body.

I'm fine with the hex constants under the argument that the canonical source for the mapping is the identified URL. You need to add a signed-off-by to that commit.
Also my comments on commit format also applied to the third commit, which still has feat(board) with a list-format body.

Thanks. missed that when I was rebasing. Hopefully all good now, from a commit message perspective.

1. Defaults put in `Kconfig.zephyr`. Let me know if there is consensus on a different location, I'll happily move it.

I think this is a good current solution.
I'm not really fond of any of the discussed alternative, and even though it does clutter Kconfig.zephyr, it's ok for now.
In Toolchain WG, it has been discussed to make a more proper Kconfig tree for the toolchain and compiler settings in general, and that work itself will clean up Kconfig.zephyr, so let's have the UF2 directly there, and we can see if the build outputs in general will deserve its own Kconfig.

Implementation looks good now; thanks.

AFAICT this would enable Zephyr on a large number of [Adafruit Nordic boards]
That is correct.

For some definition of "large". From this:

Only Adafruit Express boards and the Trinket M0 and Gemma M0 boards ship with the UF2 bootloader installed. Feather M0 Basic, Feather M0 Adalogger, and similar boards use a regular Arduino-compatible bootloader, which does not show a boardnameBOOT drive.

So it's not clear whether this helps me.

There's been some decent activity on https://github.com/adafruit/tinyuf2 recently, so maybe hope moving forward more of their boards will ship w/ uf2 out of the box?

Implementation looks good now; thanks.

AFAICT this would enable Zephyr on a large number of [Adafruit Nordic boards]
That is correct.

For some definition of "large". From this:

Only Adafruit Express boards and the Trinket M0 and Gemma M0 boards ship with the UF2 bootloader installed. Feather M0 Basic, Feather M0 Adalogger, and similar boards use a regular Arduino-compatible bootloader, which does not show a boardnameBOOT drive.

So it's not clear whether this helps me.

There's been some decent activity on adafruit/tinyuf2 recently, so maybe hope moving forward more of their boards will ship w/ uf2 out of the box?

cc: @tannewt

There's been some decent activity on https://github.com/adafruit/tinyuf2 recently, so maybe hope moving forward more of their boards will ship w/ uf2 out of the box?

That could help.
I really wanted Zephyr on the Clue, but it only supports DFU/serial programming, and the bootloader is placed in high flash with a configuration register overwritten to make the system start there, so the chance of bricking the device during porting is really high.  SWD pins are provided only on unlabeled test points, so there seems no solution but to throw the boards into a box or donate them to somebody who understands Arduino or CircuitPython.
Too bad: it would have been a really cool Zephyr platform.

Only Adafruit Express boards and the Trinket M0 and Gemma M0 boards ship with the UF2 bootloader installed. Feather M0 Basic, Feather M0 Adalogger, and similar boards use a regular Arduino-compatible bootloader, which does not show a boardnameBOOT drive.

So it's not clear whether this helps me.

Sorry about this text. It's old. All nRF boards from Adafruit should have a UF2 bootloader.

There's been some decent activity on https://github.com/adafruit/tinyuf2 recently, so maybe hope moving forward more of their boards will ship w/ uf2 out of the box?

Generally we ship UF2 bootloaders on all of our boards. All SAMD51 and nRF boards will. The text above is for M0, SAMD21 boards only. Basically ones designed before UF2 may not have it. (It depends on if the test jig gets updated.)
It's less urgent for us on boards with ROM bootloaders (ESP32-S2, iMX RT, STM32) so the first batches may not have it because the UF2 bootloader isn't ready yet. Our long term goal is to always have UF2 to ensure a consistent experience for all of our boards. (Once UF2 is ready, it depends on updating the test jig.)
tinyuf2 is my hope for the future. We have separate SAMD and nRF implementations that have been a pain to keep consistent. tinyuf2 builds on top of tinyusb to bring the uf2 bootloader to all of the same platforms. (CircuitPython builds on tinyusb for the same purpose.)

I really wanted Zephyr on the Clue, but it only supports DFU/serial programming, and the bootloader is placed in high flash with a configuration register overwritten to make the system start there, so the chance of bricking the device during porting is really high.

Mine has a UF2 bootloader. Just double tap reset. The UF2 bootloader (source) may assume the soft device is present though.
If you do brick it during porting I can get you a new one.

SWD pins are provided only on unlabeled test points, so there seems no solution but to throw the boards into a box or donate them to somebody who understands Arduino or CircuitPython.

The Feather nRF52840 is the best board if you want 2x5 SWD. It should work similar enough to the clue if you need SWD to debug a bad crash. If you need SWD on the clue you can solder from the test points to a larger pad and then use a micro:bit breakout to get it to a bread board. Eagle files for it are here: https://github.com/adafruit/Adafruit-CLUE-PCB (To figure out which test point is which.)
You should try CircuitPython if you haven't. It's very easy to get started. This is the setup guide: learn.adafruit.com/welcome-to-circuitpython and the API overview is here: https://learn.adafruit.com/circuitpython-essentials/

Too bad: it would have been a really cool Zephyr platform.

It would be!

Is there an alternative to uf2conv.py that has any market share?

Not that I know of. We use uf2conv.py. Raspberry Pi has their own converter I think.

Scancode error:

Error: * scan/scripts/uf2conv.py is not apache-2.0 licensed: mit

Since this is a script that does not end in the firmware, I believe this can be considered acceptable.