Weeding Screw skips weeds

While doing field tests with u6 we sometimes saw no action from the weeding screw despite detections being available:

The field_friend.automations.implements.weeding_screw.json config looks ok:
{
    "with_drilling": false,
    "with_chopping": false,
    "chop_if_no_crops": false,
    "cultivated_crop": null,
    "weed_screw_depth": 0.14,
    "crop_safety_distance": 0.02,
    "max_crop_distance": 0.08
}

The first three entries are a relict from the "chop and screw" implement still sitting in the base class. They have no relevance for the weeding screw implement.
Also field_friend.automations.plant_provider.json looks like expected:
{
    "match_distance": 0.1,
    "crop_spacing": 0.18,
    "predict_crop_position": false,
    "prediction_confidence": 0.3,
    "crop_confidence_threshold": 0.3,
    "weed_confidence_threshold": 0.1
}

And field_friend.automations.plant_locator.json too:
{
    "minimum_weed_confidence": 0.05,
    "minimum_crop_confidence": 0.2,
    "autoupload": "disabled",
    "tags": []
}

The Log file is not to helpful:
2024-06-28 14:12:07.313 [INFO] rosys/rosys.py:69: automation started
2024-06-28 14:12:07.316 [INFO] field_friend/automations/implements/weeding_implement.py:50: start weeding ['coin', 'weed', 'big_weed', 'thistle', 'orache', 'kamille'] with Weed Screw ...
2024-06-28 14:12:07.318 [INFO] field_friend/hardware/z_axis_canopen_hardware.py:110: enabling h motors
2024-06-28 14:12:08.320 [INFO] field_friend/hardware/z_axis_canopen_hardware.py:116: activating velocity mode
2024-06-28 14:12:09.824 [INFO] field_friend/hardware/z_axis_canopen_hardware.py:136: moving to end_t stop
2024-06-28 14:12:13.588 [INFO] field_friend/hardware/z_axis_canopen_hardware.py:146: moving out of end_t stop
2024-06-28 14:12:14.698 [INFO] field_friend/hardware/z_axis_canopen_hardware.py:156: moving slowly to end_t stop
2024-06-28 14:12:16.632 [INFO] field_friend/hardware/z_axis_canopen_hardware.py:166: moving slowly out of end_t stop
2024-06-28 14:12:17.936 [INFO] field_friend/hardware/z_axis_canopen_hardware.py:178: zaxis referenced
2024-06-28 14:12:17.938 [INFO] field_friend/hardware/z_axis_canopen_hardware.py:180: actual position: -0.00065, and steps: -2600
2024-06-28 14:12:18.139 [INFO] field_friend/hardware/y_axis_canopen_hardware.py:109: enabling h motors
2024-06-28 14:12:19.167 [INFO] field_friend/hardware/y_axis_canopen_hardware.py:115: activating velocity mode
2024-06-28 14:12:20.667 [INFO] field_friend/hardware/y_axis_canopen_hardware.py:135: moving to end_r stop
2024-06-28 14:12:22.802 [INFO] field_friend/hardware/y_axis_canopen_hardware.py:145: moving out of end_r stop
2024-06-28 14:12:23.904 [INFO] field_friend/hardware/y_axis_canopen_hardware.py:155: moving slowly to end_r stop
2024-06-28 14:12:25.816 [INFO] field_friend/hardware/y_axis_canopen_hardware.py:165: moving slowly out of end_r stop
2024-06-28 14:12:27.128 [INFO] field_friend/hardware/y_axis_canopen_hardware.py:180: yaxis referenced
2024-06-28 14:12:27.129 [INFO] field_friend/hardware/y_axis_canopen_hardware.py:182: actual position: -0.12944920000011018, and steps: 918
2024-06-28 14:12:27.130 [INFO] field_friend/automations/navigation/straight_line_navigation.py:29: Setting target pose to 12.472, 0.237, 1.4 deg
2024-06-28 14:12:27.131 [INFO] field_friend/automations/navigation/straight_line_navigation.py:30: Activating Weed Screw...
2024-06-28 14:12:27.149 [INFO] field_friend/automations/puncher.py:130: Clearing view...
2024-06-28 14:12:27.149 [INFO] field_friend/hardware/y_axis.py:47: moving yaxis to -0.125 with speed 300
2024-06-28 14:12:27.150 [INFO] field_friend/hardware/y_axis_canopen_hardware.py:76: moving to steps: 8333
2024-06-28 14:12:28.649 [INFO] field_friend/hardware/y_axis_canopen_hardware.py:89: yaxis moved to -0.125
2024-06-28 14:12:28.650 [INFO] field_friend/automations/plant_locator.py:131: resuming plant detection
2024-06-28 14:12:29.023 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:29.189 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:29.370 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:29.558 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:29.735 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:29.900 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:30.078 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:30.256 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:30.412 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:30.617 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:30.814 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:31.027 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:31.578 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:31.653 [INFO] field_friend/automations/implements/weeding_implement.py:77: checking for plants...
2024-06-28 14:12:31.855 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 2.495, -0.000, 1.4 deg with factor 0.002
2024-06-28 14:12:31.865 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:32.021 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:32.385 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:32.465 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 2.516, 0.000, 1.2 deg with factor 0.002004271306361429
2024-06-28 14:12:32.586 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:33.073 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 2.541, 0.001, 0.9 deg with factor 0.002009261245492229
2024-06-28 14:12:33.197 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:33.702 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 2.568, 0.001, 0.6 deg with factor 0.00201468339943148
2024-06-28 14:12:33.847 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:34.080 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:34.306 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 2.591, 0.001, 0.4 deg with factor 0.0020194142260010393
2024-06-28 14:12:34.331 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:34.910 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 2.616, 0.002, 0.5 deg with factor 0.0020246242913138654
2024-06-28 14:12:35.516 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 2.641, 0.002, 0.5 deg with factor 0.002029698074816147
2024-06-28 14:12:36.121 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 2.667, 0.002, 0.6 deg with factor 0.002034969465614345
2024-06-28 14:12:36.395 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:36.754 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 2.692, 0.002, 0.8 deg with factor 0.0020401968865643287
2024-06-28 14:12:36.919 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:37.168 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:37.380 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 2.719, 0.003, 0.8 deg with factor 0.0020457992110589985
2024-06-28 14:12:37.400 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:37.733 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:37.910 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:37.987 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 2.743, 0.003, 0.9 deg with factor 0.0020509531119428204
2024-06-28 14:12:38.440 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:38.562 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:38.590 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 2.768, 0.004, 0.9 deg with factor 0.0020561898879996993
2024-06-28 14:12:38.694 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:39.142 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:39.200 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 2.792, 0.004, 0.9 deg with factor 0.0020613723512847384
2024-06-28 14:12:39.380 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:39.609 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:39.727 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:39.811 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 2.817, 0.004, 1.0 deg with factor 0.002066628505955463
2024-06-28 14:12:39.963 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:40.424 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 2.842, 0.005, 1.0 deg with factor 0.0020719077718545737
2024-06-28 14:12:40.633 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:40.991 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:41.028 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 2.867, 0.005, 1.1 deg with factor 0.002077367748681368
2024-06-28 14:12:41.339 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:41.594 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:41.632 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 2.893, 0.006, 1.2 deg with factor 0.0020828784831094815
2024-06-28 14:12:42.227 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:42.240 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 2.919, 0.006, 1.3 deg with factor 0.0020885285571915113
2024-06-28 14:12:42.354 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:42.355 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:42.469 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:42.590 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:42.789 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:42.847 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 2.943, 0.007, 1.3 deg with factor 0.002093868197026541
2024-06-28 14:12:42.927 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:43.069 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:43.071 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:43.185 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:43.360 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:43.464 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:43.497 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 2.969, 0.008, 1.4 deg with factor 0.0020996161741986858
2024-06-28 14:12:43.574 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:43.694 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:43.874 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:44.084 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:44.117 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 2.995, 0.008, 1.5 deg with factor 0.0021054437660200376
2024-06-28 14:12:44.246 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:44.247 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:44.345 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:44.460 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:44.603 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:44.605 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:44.707 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:44.726 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.022, 0.009, 1.6 deg with factor 0.0021112780939937527
2024-06-28 14:12:44.822 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:44.923 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:45.045 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:45.146 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:45.262 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:45.335 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.045, 0.010, 1.7 deg with factor 0.0021165758327072685
2024-06-28 14:12:45.378 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:45.471 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:45.583 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:45.584 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:45.676 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:45.771 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:12:45.955 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.072, 0.010, 1.8 deg with factor 0.002122537094806564
2024-06-28 14:12:46.480 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:46.560 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.096, 0.011, 1.7 deg with factor 0.0021280685803179633
2024-06-28 14:12:46.588 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:47.164 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.122, 0.012, 1.6 deg with factor 0.0021339024892894558
2024-06-28 14:12:47.416 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:47.773 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.146, 0.013, 1.7 deg with factor 0.0021394643135960057
2024-06-28 14:12:48.377 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.172, 0.013, 1.6 deg with factor 0.0021452478573368186
2024-06-28 14:12:48.982 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.196, 0.014, 1.5 deg with factor 0.0021509789363424402
2024-06-28 14:12:49.587 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.222, 0.015, 1.6 deg with factor 0.0021570201198710106
2024-06-28 14:12:50.192 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.246, 0.015, 1.5 deg with factor 0.0021624519863248496
2024-06-28 14:12:50.519 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.262, 0.016, 1.5 deg with factor 0.0021661684383720244
2024-06-28 14:12:50.837 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.278, 0.016, 1.5 deg with factor 0.002169912861852328
2024-06-28 14:12:51.156 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.296, 0.017, 1.4 deg with factor 0.002174288150303353
2024-06-28 14:12:51.460 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.312, 0.017, 1.4 deg with factor 0.0021781058735564833
2024-06-28 14:12:51.649 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:51.765 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.329, 0.018, 1.4 deg with factor 0.002182032429832672
2024-06-28 14:12:52.099 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.344, 0.018, 1.4 deg with factor 0.002185638975082573
2024-06-28 14:12:52.117 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:52.305 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:52.402 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.362, 0.018, 1.3 deg with factor 0.0021899674601002766
2024-06-28 14:12:52.707 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.379, 0.019, 1.3 deg with factor 0.002193969697797171
2024-06-28 14:12:53.009 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.394, 0.019, 1.3 deg with factor 0.002197641706784146
2024-06-28 14:12:53.316 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.410, 0.019, 1.3 deg with factor 0.0022016321198446284
2024-06-28 14:12:53.619 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.427, 0.020, 1.2 deg with factor 0.0022057844228071184
2024-06-28 14:12:53.942 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.445, 0.020, 1.2 deg with factor 0.002209995389996537
2024-06-28 14:12:53.953 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:54.245 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.460, 0.021, 1.2 deg with factor 0.0022137288746255745
2024-06-28 14:12:54.549 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.476, 0.021, 1.2 deg with factor 0.002217799802383766
2024-06-28 14:12:54.852 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.493, 0.021, 1.2 deg with factor 0.0022218148310813915
2024-06-28 14:12:55.155 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.509, 0.022, 1.2 deg with factor 0.00222594181825534
2024-06-28 14:12:55.468 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.526, 0.022, 1.1 deg with factor 0.0022300537692771746
2024-06-28 14:12:55.668 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:55.811 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.544, 0.022, 1.2 deg with factor 0.002234563225792337
2024-06-28 14:12:56.124 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.562, 0.023, 1.2 deg with factor 0.0022389366503989946
2024-06-28 14:12:56.748 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.589, 0.023, 1.2 deg with factor 0.002245809798243537
2024-06-28 14:12:56.958 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:57.370 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.613, 0.024, 1.3 deg with factor 0.002251822592390628
2024-06-28 14:12:57.975 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.637, 0.024, 1.3 deg with factor 0.00225788446315217
2024-06-28 14:12:58.579 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.662, 0.025, 1.3 deg with factor 0.0022642844415537173
2024-06-28 14:12:58.710 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:12:59.215 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.685, 0.025, 1.3 deg with factor 0.002270296456157538
2024-06-28 14:12:59.845 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.712, 0.026, 1.4 deg with factor 0.0022771965429276703
2024-06-28 14:13:00.017 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:13:00.169 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:13:00.338 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:13:00.436 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:13:00.448 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.736, 0.027, 1.5 deg with factor 0.002283468495917744
2024-06-28 14:13:00.558 [INFO] field_friend/automations/plant_locator.py:118: thymian not in categories
2024-06-28 14:13:00.559 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:13:00.996 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:13:01.056 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.763, 0.027, 1.3 deg with factor 0.0022905884719059038
2024-06-28 14:13:01.114 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:13:01.272 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:13:01.420 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:13:01.554 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:13:01.662 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.787, 0.028, 1.3 deg with factor 0.0022969266336361083
2024-06-28 14:13:01.673 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:13:01.852 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:13:02.225 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:13:02.269 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.811, 0.028, 1.3 deg with factor 0.0023033115899282245
2024-06-28 14:13:02.358 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:13:02.464 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:13:02.685 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:13:02.892 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:13:02.902 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.838, 0.029, 1.3 deg with factor 0.0023105513774068207
2024-06-28 14:13:03.229 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:13:03.514 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.863, 0.030, 1.3 deg with factor 0.0023170546910178157
2024-06-28 14:13:03.822 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:13:03.983 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:13:04.119 [INFO] field_friend/automations/navigation/straight_line_navigation.py:41: driving to local target 3.889, 0.030, 1.4 deg with factor 0.0023240249869878517
2024-06-28 14:13:04.203 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:13:04.494 [INFO] rosys/rosys.py:69: automation stopped because stop button was pressed
2024-06-28 14:13:04.521 [ERROR] field_friend/automations/plant_locator.py:100: could not generate floor point of detection, calibration error
2024-06-28 14:13:04.539 [INFO] field_friend/automations/plant_locator.py:125: pausing plant detection

The could not generate floor point of detection, calibration error are expected. Any detection outside the calibrated area will produce this message. We verified calibration is ok with manual punching and visualization of the grid.

I created pull request #101 to see if the weeds are raising above the configured threshold in the Plant Provider.


SpnegoWebflowConfigurer has String constant rather than variable

https://github.com/apereo/cas/blob/4.2.x/cas-server-support-spnego-webflow/src/main/java/org/jasig/cas/web/flow/SpengoWebflowConfigurer.java#L34
has the private variable from line 19 as String rather than the variable meaning Spnego can't be configured to use any of the client selection strategies.

@sisutcliffe Would you be willing to submit a PR to get this fixed?


python312Packages.types-deprecated: <IP_ADDRESS>40311 -> <IP_ADDRESS>41117

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 357801

x86_64-linux

:white_check_mark: 16 packages built:

python311Packages.cirq
python311Packages.cirq-rigetti
python311Packages.cirq-rigetti.dist
python311Packages.cirq.dist
python311Packages.pyquil
python311Packages.pyquil.dist
python311Packages.types-deprecated
python311Packages.types-deprecated.dist
python312Packages.cirq
python312Packages.cirq-rigetti
python312Packages.cirq-rigetti.dist
python312Packages.cirq.dist
python312Packages.pyquil
python312Packages.pyquil.dist
python312Packages.types-deprecated
python312Packages.types-deprecated.dist


Go redundant type cleanup.

Cleaning up some stylistic warnings about redundant types. No actual changes to behavior.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[x] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

R: @lostluck (feel free to merge if there's no comments)

Run Go PostCommit


godot_4: 4.2.2 -> 4.3

Description of changes

https://godotengine.org/releases/4.3/
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Duplicated. Please review #334868

@Haskellered FYI whenever bumping Godot 4 you have to also bump the templates. Or else it will just fail for everyone.

@Haskellered FYI whenever bumping Godot 4 you have to also bump the templates. Or else it will just fail for everyone.

Oh sorry I forgot about the templates.


BarChartView style in dark mode didn't respect set up

BarChartView(data: ChartData(values: [("cool",1918), ("cool",11991), ("cool",13260), ("cool",14539), ("cool",16539)]), title: "HP", style: Styles.barChartStyleNeonBlueDark, form: ChartForm.medium)

Description
The color is always orange in dark mode (But switch to light mode, this issue is fixed)
Expected Behavior
The color should be blue
Actual Behavior
The color is always orange

Your Environment

Version of this package used: 1.5.1
Device/Simulator: iPhone 11 Pro, 13.5
Operating System and version: Xcode 11.5, mac os 10.15.5

self.darkModeStyle = style.darkModeStyle != nil ? style.darkModeStyle! : Styles.barChartStyleOrangeDark

Seems like a intented behavior rather than a bug

Duplicate for #72.
You find the right solution;) To force the color in DarkMode you need to set them up manually.
It will be fixed in V2.

Thanks for the response, I'll close this one.


slowly-test: org.apache.pulsar.broker.service.ReplicatorTest

Search before asking

[X] I searched in the issues and found nothing similar.

Motivation
This test run took more than 5 minutes

https://github.com/apache/pulsar/actions/runs/3045941219/jobs/4908748120
Solution
Make the test run faster
Alternatives
No response
Anything else?
No response
Are you willing to submit a PR?

[ ] I'm willing to submit a PR!

There is no more room for optimization in this test


Rate Limit Quota

This is an alternative to existing RLS, redesigned for streaming.
Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

@tyxia As discussed IRL, please take a look.

/assign @tyxia

We need a non-Googler to do API review here as well. Unassigning myself as API shepherd. Suggest @mattklein123 takes a look as someone with rate limit domain experience.

I have a high level question before diving into the review. Should this be built into the existing global rate limit filter? It seems like there is a lot of overlap? If this has been discussed somewhere else please let me know and I can take a look. Thank you.

Matt, what we're building here wound up being a whole new protocol with somewhat different semantics to the existing RLS protocol.  I think it makes more sense to make it a new filter rather than trying to shoe-horn it into the existing one.  I suspect the two would not have much code in common.

@markdroth @mattklein123 I'm trying to figure out how to best move forward with this extensions. Looking at the protocols as they now, they are quite different and I do not see an easy way to make them compatible. There are maybe some way to make bucket and descriptor specification compatible, not sure how much would be gained from this.
Would it make sense to then brand this filter such that it is Google specific? I.e. GcpRateLimit or GoogleCloudRateLimit? Without reference implementation for the rate limit server that supports this protocol, nobody would be able to use this extension outside of GCP.

hmm I would rather not brand it Google specific. I don't think the protocol is that complicated and I would imagine people will implement it themselves or possibly also implement it in the existing reference ratelimit service.

Thanks for bringing up this @yanavlasov！I am also looking at how to move forward(more specifically, implementation part) while API is under review.
@markdroth @mattklein123 @yanavlasov Looks like a separate new implementation is cleaner than trying to plumb this into existing ratelimit code. If so, a practical issue is naming and how to organize the new impl files:)
How about appending quota to the end of the name as the high level principle for new implementation to differentiate existing ratelimit. e.g.:
For the class/variable names,  we use RateLimitQuota and RateLimitQuotaFilter?   For the new files, we just put them under a new folder called rate_limit_quota`.

Note: force-push was for a rebase against the latest main.

Unassigning myself for now. Please reassign when not a draft.

This is ready for review now.

@mattklein123, I think this is now ready for API review.  Thanks!

Sorry regarding my LGTM comment can you please go through all my comments and update the PR text to clarify also? Thank you.

@mattklein123 Addressed all your comments. Resolved trivial comment threads. Please take another look. Will be happy to address any other comments.

@sergiitk please don't force push. It makes reviews much more difficult. Thank you!

@mattklein123

@sergiitk please don't force push. It makes reviews much more difficult. Thank you!

Sorry about that. Please note that at this point the only reason I force-push is to add the missing signoff. There's no force-pushes that changes the diff itself.

Sorry about that. Please note that at this point the only reason I force-push is to add the missing signoff. There's no force-pushes that changes the diff itself.

It still unfortunately breaks code review. Please don't do it. If we need to fix DCO we can just do it at the end. Thank you!

It still unfortunately breaks code review. Please don't do it. If we need to fix DCO we can just do it at the end. Thank you!

Got it, thanks! Sorry for the inconvenience.

@mattklein123 All set!  Ready for another round.


TypeError: forward() takes 3 positional arguments but 5 were given

When I try to predict the word using the model(BiLSTM) I generate by myself, it occurs the following error:
File "train.py", line 662, in predictwords
encoder_hidden, encoder_hiddens = encoder(rt, re, rm, init_hidden)
File "/home/zhangzhenchang/anaconda3/lib/python3.6/site-packages/torch/nn/modules/module.py", line 491, in call
result = self.forward(*input, **kwargs)
TypeError: forward() takes 3 positional arguments but 5 were given
What's the function of "encoder" mean, how can I fix this problem.
Thanks,
Zhang

Traceback (most recent call last):
File "E:/audio data/AI-writer_Data2Doc-master/train/small_evaluate.py", line 52, in
for idx, text in enumerate(text_generator):
File "E:\audio data\AI-writer_Data2Doc-master\train\train.py", line 776, in evaluate
beam_size)
File "E:\audio data\AI-writer_Data2Doc-master\train\train.py", line 670, in predictwords
out, encoder_hidden = encoder(rt, re, rm, encoder_hidden)
File "D:\anaconda\envs\pytorch\lib\site-packages\torch\nn\modules\module.py", line 477, in call
result = self.forward(*input, **kwargs)
TypeError: forward() takes 3 positional arguments but 5 were given

man, you gotta post your code, not just the error itself.

Traceback (most recent call last):
File "E:/audio data/AI-writer_Data2Doc-master/train/small_evaluate.py", line 52, in
for idx, text in enumerate(text_generator):
File "E:\audio data\AI-writer_Data2Doc-master\train\train.py", line 776, in evaluate
beam_size)
File "E:\audio data\AI-writer_Data2Doc-master\train\train.py", line 670, in predictwords
out, encoder_hidden = encoder(rt, re, rm, encoder_hidden)
File "D:\anaconda\envs\pytorch\lib\site-packages\torch\nn\modules\module.py", line 477, in call
result = self.forward(*input, **kwargs)
TypeError: forward() takes 3 positional arguments but 5 were given

Hi Novegetate, have you solved the problem? I met the same issue. I am thinking whether it is because of the difference of pytorch's version.

I found the solution. You should combine rt,re, rm into one dictionary inputs
like inputs = {'rt': rt, 're': re, 'rm': rm}
Then you only need input three arguments instead of five.


Fix dependency conflict for issue

#1179

@norhh
Could you please help me review this issue?
Thank you very much!
BTW, dependency conflict problems are very common in practice in python ecosystem.
I have encountered the issues several times. What's your oppinion on the challenges of detecting and repairing such issues?
And how to avoid dependency conflict problems among python projects, especially from the ecosystem's perspective?

Thanks for the PR @NeolithEra
I have encountered the issues several times. What's your opinion on the challenges of detecting and repairing such issues? One terrible way would be to fix all the versions to a hard coded value(with ==) and update them when necessary, but it's not always feasible but on a positive note we only have to deal with indirect dependency problem.


ImportError GLIBC_2.33 round two

Problem Description
I have run into the same issue as:
https://github.com/mitmproxy/mitmproxy/issues/6831
But, the proposed root cause (wrong python version) is not the issue.
I am also trying to run Mitmproxy on a Raspberry Pi Zero W with Rasbpian Bullseye. As Raspian Bullseye comes with python 3.9 it typically would no longer be supported. But, I upgraded my python version with pyenv to 3.10.15 and I am still getting this GLIBC version error stating it is required by mitmproxy_rs.abi3.so. All of the release notes for Mitmproxy only state a minimum GLIBC version of 2.31, which is the version on the Pi zero with Rasbpian Bullseye. Since GLIBC affects the entire system it is not possible to upgrade from 2.31 to 2.33.
Any ideas why the requirement of GLIBC 2.33 is never mentioned in the release notes and what specific Mitmproxy version would not require 2.33 and would run on 2.31? I could tell pipx to install that specific version instead of the newest.
Steps to reproduce the behavior:

Install Raspbain Bullseye on Pi Zero W
Upgrade Python to 3.10+
Install mitmproxy
Run any Mitmproxy binary

System Information
"mitmproxy --version" doesn't run and also outputs the same ImportError.
But here's the output from the install that shows the Mitmproxy and Python version.

admin@viessmann-gw:~ $ pipx install mitmproxy
installed package mitmproxy 10.4.2, installed using Python 3.10.15
These apps are now globally available
- mitmdump
- mitmproxy
- mitmweb
done! ✨ 🌟 ✨

Python version from prompt:

admin@viessmann-gw:~ $ python -V
Python 3.10.15

GLIBC Version:

admin@viessmann-gw:~ $ ldd --version
ldd (Debian GLIBC 2.31-13+rpt2+rpi1+deb11u11) 2.31
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

Traceback from Mitmproxy:

admin@viessmann-gw:~ $ mitmproxy --version
Traceback (most recent call last):
File "/home/admin/.local/bin/mitmproxy", line 5, in
from mitmproxy.tools.main import mitmproxy
File "/home/admin/.local/share/pipx/venvs/mitmproxy/lib/python3.10/site-packages/mitmproxy/tools/main.py", line 15, in
from mitmproxy import master
File "/home/admin/.local/share/pipx/venvs/mitmproxy/lib/python3.10/site-packages/mitmproxy/master.py", line 5, in
from .addons import termlog
File "/home/admin/.local/share/pipx/venvs/mitmproxy/lib/python3.10/site-packages/mitmproxy/addons/init.py", line 3, in
from mitmproxy.addons import block
File "/home/admin/.local/share/pipx/venvs/mitmproxy/lib/python3.10/site-packages/mitmproxy/addons/block.py", line 5, in
from mitmproxy.proxy import mode_specs
File "/home/admin/.local/share/pipx/venvs/mitmproxy/lib/python3.10/site-packages/mitmproxy/proxy/mode_specs.py", line 34, in
import mitmproxy_rs
File "/home/admin/.local/share/pipx/venvs/mitmproxy/lib/python3.10/site-packages/mitmproxy_rs/init.py", line 1, in
from .mitmproxy_rs import *
ImportError: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.33' not found (required by /home/admin/.local/share/pipx/venvs/mitmproxy/lib/python3.10/site-packages/mitmproxy_rs/mitmproxy_rs.abi3.so)

After looking into the mitmproxy_rs project, I notice that is basically for the Wireguard and Local Redirect Modes, both of which I do not need on my Raspberry Pi. So, any way to install mitmproxy without requiring mitmproxy_rs?
My last resort could potentially be to just install a version of mitmproxy prior to the introduction of these two redirection modes. As far as I can tell, that would be version 8 since WireGuard Mode was introduced in v9.
That's pretty old and missing a lot of functionality I suppose. So, any way of telling which version of mitmproxy_rs doesn't require GLIBC 2.33 and would work with 2.31?

So, any way to install mitmproxy without requiring mitmproxy_rs?

No, mitmproxy_rs is a hard dependency. It's heavily integrated already (e.g., everything UDP-based depends on it), and will be more heavily integrated going forward.

ImportError: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.33' not found (required by /home/admin/.local/share/pipx/venvs/mitmproxy/lib/python3.10/site-packages/mitmproxy_rs/mitmproxy_rs.abi3.so)

I'm curious why this is happening. Supposedly we should build with manylinux2024 compatibility here, which would be glibc 2.17. Something in that process clearly is not working.

Hm - this here - from https://pypi.org/project/mitmproxy-rs/0.6.3/#files - looks correct:
$ objdump -p mitmproxy_rs.abi3.so

mitmproxy_rs.abi3.so:     file format elf64-little

[...]

Version References:
  required from libm.so.6:
    0x06969197 0x00 04 GLIBC_2.17
  required from libpthread.so.0:
    0x06969197 0x00 03 GLIBC_2.17
  required from libc.so.6:
    0x06969197 0x00 02 GLIBC_2.17
  required from libdl.so.2:
    0x06969197 0x00 05 GLIBC_2.17
  required from ld-linux-aarch64.so.1:
    0x06969197 0x00 06 GLIBC_2.17

OK, so the issue is actually that mitmproxy_rs requires the system to be 64bit. Raspberry pi zero W (not v2) is 32bit only.
I had read something about this in another thread, but the wording did not sound like mitmproxy_rs is a requirement.
Can you say what version of mitmproxy introduced mitmproxy_rs? Maybe a very early version prior to this requirement could still accomplish what I want. I basically only want to decipher a specific API communication that is of course over HTTPS. I have confirmed that the app does not do certificate pinning and will work if the client trusts the certificate of the proxy. So, there may be a chance that a very early version of mitmproxy still fits my needs.
Thanks.

The last release without Rust should be mitmproxy 8 I think. Happy for you
if that works for you, just for the record it's unsupported otherwise. :)
My general Raspi recommendation would be to use our arm docker images,
although the Zero in your case is armv6 only, which won't work AFAIK.
On Fri, Sep 27, 2024, 00:23 ckpt-martin @.***> wrote:

OK, so the issue is actually that mitmproxy_rs requires the system to be
64bit. Raspberry pi zero W (not v2) is 32bit only.
I had read something about this in another thread, but the wording did not
sound like mitmproxy_rs is a requirement.
Can you say what version of mitmproxy introduced mitmproxy_rs? Maybe a
very early version prior to this requirement could still accomplish what I
want. I basically only want to decipher a specific API communication that
is of course over HTTPS. I have confirmed that the app does not do
certificate pinning and will work if the client trusts the certificate of
the proxy. So, there may be a chance that a very early version of mitmproxy
still fits my needs.
Thanks.
—
Reply to this email directly, view it on GitHub
https://github.com/mitmproxy/mitmproxy/issues/7209#issuecomment-2378587039,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHY2PRFU7QNHEKF3O227LLZYUBWJAVCNFSM6AAAAABO4UKOGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZYGU4DOMBTHE
.
You are receiving this because you commented.Message ID:
@.***>

OK, I'll try 8.1.1. If that still doesn't work then I'll have to try to do this via a different system hosted separate to the pi zero. Basically I am using the pi zero as a Wifi access point for the application that is doing the API communication. So, I thought it would be great if I could do TLS interception right on the access point since it is physically between the client and the server. But, if it doesn't work on the pi, then I'll have to either intercept on the client itself (e.g. via HTTP Catcher) or redirect the traffic on the pi zero to another system that can run mitmproxy.


add relationship for k8s pod and host for otel

Relevant information

Add Relationship for k8s Otel to infra host k8sHostContainsPodOtel

Checklist

[x] I've read the guidelines and understand the acceptance criteria.
[x] The value of the attribute marked as identifier will be unique and valid.
[x] I've confirmed that my entity type wasn't already defined. If it is I'm providing an explanation above.

Blocked for now since it needs a more careful deployment together with the rest of the new OTel rules.
The JIRA ticket to follow the progress on this one is NR-299836.


fix(op): add reth-node-api optimism feature + unscope cfg_with_handler_cfg

fixes https://github.com/paradigmxyz/reth/issues/6592 and makes https://github.com/paradigmxyz/reth/pull/6593 work as intended
blocks are being built successfully again with this commit

closing in favor of https://github.com/paradigmxyz/reth/pull/6598


NSTabView add_tab helper

Thought I'd add this as a separate PR to the OS X fixes, as I wasn't sure if additional control helper methods were wanted in the main gem or not...
This is a simple addition to support adding tab items nested beneath a tab view, and which then allows you to use the rest of the brilliant MotionKit DSL to setup and configure the corresponding view for a tab as you would any other view, so you can create a fairly complicated set of tabs all from within your MotionKit layout.
It came about while trying to make a section of my book a bit more concise - let me know if it's better off in (or as) a separate gem, or if it needs any tweaking though.

Oh, and I should say that although I added the two separate PRs, this one was based off of the OS X fixes branch, so contains all of those changes too, as well as a spec for the new NSTabView helper.

Thanks @ejdraper !

@colinta , when you're back and working again, we should discuss the impact that the new MK would have on OS X developers. Perhaps MK OSX should live on in its current form, since RedPotion will be iOS only.

Agreed - can't leave out the OS X devs.

On Jul 9, 2015, at 5:41 AM, Jamon Holmgren<EMAIL_ADDRESS>wrote:
@colinta , when you're back and working again, we should discuss the impact that the new MK would have on OS X developers. Perhaps MK OSX should live on in its current form, since RedPotion will be iOS only.
―
Reply to this email directly or view it on GitHub.

No problem - if I can help at all, especially on the OS X side of things, let me know and I'll see what I can do.


Import "links" element from Fahrplan, join multiple values with whitespace

This information is useful in the releasing process, where the links can be rendered into the description for example.

Are we sure links are always properly escaped? I don't have a good feeling about space separation – this is already kind of a hack with multiple persons.

I'm unsure about XSD of schedule.xml format, wether it defines some constraint on the content of that field or not.
As long as the tracker has no concept of multivalue properties, there is no other way than using a defined separation character. At the end, this might only produce broken links in the worst case.

What about storing some actual (and sanely parsed/handled) HTML/XML?
Like a property value of Link name1Link name2...
I know it's still a hack, multivalue properties would solve that, but this is a variation of the "separation character" approach and might be usable elsewhere.
And if you don't like HTML, what about Markup? [[URL1|Link name1]][[URL2|Link name2]]
At least something with already defined rules, how to store/interpret.

What about storing some actual (and sanely parsed/handled) HTML/XML?

HTML sounds like the most reasonable approach yet. I would refrain from introducing another markup that has then to be parsed by API consumers.
What are our chances to implement multi-value properties?

I'd only start thinking about adding the level of complexity required for multi-value properties, if we have enough use-cases. Having multiple persons or links attached to a ticket, which both won't really parsed by neither tracker nor crs scripts, is a valid use-case, but not a strong one.
If we don't find more, we can think about allowing a simple array syntax or said HTML as property value.

A simple array syntax, maybe like space separated values that must not contain spaces per definition?


IndexError: too many indices for tensor of dimension 2

how to fix this problem
outputs = outputs[:, -self.args.pred_len:, f_dim:] IndexError: too many indices for tensor of dimension 2

Hello, thank you for your comment, but could you please provide some more detailed information, such as the name of the script you executed, relevant configurations, and error location.

Thank you for your feedback. We have just completed the merging of the model.

set output_attention == False ,will solve this problem.


Improve search by removing all whitespaces from fields and the query …

…string

Look good 👍 Thanks for your contribution!
In the future feel free to create a branch in ukrainski-dom/housing-app repository. Then I can provide review changes in code.

Oh... I can commit changes in pull request 🎉 @bartoszkp merged! Thanks!

Thanks Jacek!


[SDL-0234] Proxy Library RPC Generation

Fixes #1090
This PR is [ready] for review.
Risk
This PR makes [no] API changes.
Testing Plan

[x] I have verified that I have not introduced new warnings in this PR
[x] I have run the unit tests with this PR
[x] I have tested Android, Java SE, and Java EE

Unit Tests
Covered by unit tests and PyLint
Summary
According to [SDL-0234] Proxy Library RPC Generation proposal, this PR adds the Python generator script based on XML Parser from smartdevicelink/rpc_spec linked to the repository as Git submodule
Changelog
Enhancements

Added utils/generator/rpc_spec submodule pointed to develop branch of smartdevicelink/rpc_spec repository
Created Proxy RPC Generator based on Python 3.5 and linked with parser from the utils/generator/rpc_spec submodule
Added README.md with usage description and transformation rules for Proxy RPC Generator

CLA

[x] I have signed the CLA

@theresalech @joeljfischer @joeygrover
Based on this conversation https://github.com/smartdevicelink/sdl_java_suite/issues/1090#issuecomment-586310102 we'd like to notify here that we have found missing parameters in 3 enums that exist in XML but don't exist in the current code:
FunctionID.RESERVED
AppInterfaceUnregisteredReason.UNSUPPORTED_HMI_RESOURCE
Result.CHAR_LIMIT_EXCEEDED

This leads to the failed result when we try to check the generated code with existing unit tests. Because they are part of the current MOBILE API specification, it seems missing parameters should be included in the current RPC code and unit tests should be adjusted.

@kshala-ford exception of *Response added, all suggested changes accepted, questions answered. Please take a look.

@theresalech I approve this pull request.

@vladmu, if this is ready for Livio review, can you please update the PR description from This PR is **[not ready]** for review. to This PR is **[ready]** for review.?  Thanks!

@theresalech done, the PR is ready for Livio review. Thank you!

Thanks, @vladmu for implementing the PR. I am just wondering if there is a specific reason for making the files in templates/scripts/ have the .groovy extension ? can we make them use .java instead? because they are snippets from java files.

Hello, @bilal-alsharifi I completely agree with your point. Will do this now.

Thanks, @ksologubov for making the changes.

As it was discussed in the iOS issue, no mappings for corner cases should be specified in the generator. Generic rules are fine (like replacing “sync” with “sdl” for example). The script should use the RPC specs without any case by case handling. Even if that would generate a different code than what the Java Suite currently has. Handling RPCs on case by case basis will make the scripts hard to maintain. Some examples of how things in the current mappings can be removed are:

Enum values can always use the name attribute and completely ignore the internal_name.  This, I believe, will get rid of the use for the kind (simple, custom, complex) attribute that is specified for the enums in mapping.json. More generic rules can be added to make the variable accepted by the compiler like always adding _ if the names start with a number.
Float can always be used if the RPC spec says so. It doesn’t need to be replaced with Double.
Because FunctionID is very different than any other enum, it shouldn’t be generated by the generator. We can always manually modify it.
No need to add any methods that do not come directly from the spec (examples: format(), valueForString() ...)
Imports shouldn’t be specified as corner cases. I think that would be possible after removing the corner cases methods as mentioned previously.

The previous list just gives some examples and it is not comprehensive. But the important part is to avoid making special cases for each item.

@theresalech Please add an agenda item about SDL-0234 implementation to the next steering committee meeting. The requested changes here and the discussion in sdl_ios are not compliant to the accepted proposal.

@kshala-ford Sure, we can include this on next week's agenda.  Livio will continue to review the implementation PRs (for Java Suite and iOS) as planned in the meantime as to stay on track with the current release timeline.

@theresalech Please add an agenda item about SDL-0234 implementation to the next steering committee meeting. The requested changes here and the discussion in sdl_ios are not compliant to the accepted proposal.

@kshala-ford @theresalech respecting the committee decided to remove the following section from the proposal downsides:

The generator could produce bad RPC classes, however, the library authors will ensure that this is not the case and that the first version of the generated code matches what already exists, and the unit tests will continue to pass.

It would be appreciated if you could summarize and define action points for us here regarding what we should do in this PR to follow the SDLC decision. Would it be enough to remove all custom mappings from the generator? Do we need to remove the customization tool itself? Etc.

@vladmu please address @bilal-alsharifi's review comments regarding removing custom mapping.  To answer your question specifically, you should remove the customization tool/logic.

@vladmu I do want to clarify, customization can and should still occur in general cases that can be applied to everything of a particular type, e.g. all enum names that start with a number need to be prefixed by a _. If that necessitates that your customization logic remains, then so be it, but if the customization logic is only for corner case logic, then it can be removed.

@vladmu I do want to clarify, customization can and should still occur in general cases that can be applied to everything of a particular type, e.g. all enum names that start with a number need to be prefixed by a _. If that necessitates that your customization logic remains, then so be it, but if the customization logic is only for corner case logic, then it can be removed.

@joeljfischer thank you for clarification, that's clear. General rules are defined in the code and don't relate to the custom mappings tool. My questions were exactly about the customizations which were applied before for corner cases to make the generated code compatible with the old one.

There is following discussion in sdl_ios pull request about all params with name "id" should be renamed to "${rpcName}Id"
https://github.com/smartdevicelink/sdl_ios/pull/1556#issuecomment-592521294 (point 7)

The struct TouchEvent has a parameter called id. This is a keyword in objc. The scripts should never use this keyword. A rule should be added if the param name is id the generated objc property should be called "${rpcName}Id" so in the example of touch event it should be touchEventId.
I'm fine with that approach to keywords. We should define a list of keywords to do this approach with, and do the same for Java_Suite.
Bilal, could you please confirm you are agree with that and I should make this change?

@bilal-alsharifi
I finished working on all review comments. Could you please check once more

could you please confirm you are agree with that and I should make this change?
I don't think that is needed in java suite. Because we add get & set before the getters and setter names.

@ksologubov could you please merge the latest develop into your branch? there was an issue in Github Actions setup that making the CI not getting triggered if the PR is from a fork. That has been just fixed and merged #1297.

@bilal-alsharifi sure, merged, github actions build is in progress

@ksologubov thanks for merging develop. The CI actions work well now 👌
I am noticing an issue with ShowConstantTBT RPC. When the script overwrites what we already have. It names the class correctly ShowConstantTBT however, the file name stays ShowConstantTbt.java which makes the file not a valid java file because of the naming difference.

@bilal-alsharifi But ShowConstantTBT is not present currently in sdl_java_suite as I see. I believe ShowConstantTbt.java (camel case) is leftover from previous runs of generator when mapping was present. Are you using Windows machine? Because in this case ShowConstantTbt.java and ShowConstantTBT.java is the same file and generator replacing content and leaving name as is. I'm going to add explicit file removal to get rid of this issue on Windows.

This issue reproduced only on case-insensitive filesystems, e.g. on Windows. Same will be for OASISAddress. I'm going to fix it with explicit file removal before overwriting file content.

Could you please try now

Thanks for the very quick response and fix. I am using Mac OS which should be case-sensitive but I agree it is strange why the issue was happening. Your fix though that deletes the file before overwriting it fixed it 👌

It looks like the script is still using the internalName for enums. To make it simpler, as discussed here, we can completely ignore the internalName tag from the RPC spec:

If the name in the RPC spec doesn't start with a number, we can use that name with no modifications and ignore the internalName in the RPC spec. For example, HMILevel will be:

public enum HMILevel {
    FULL,
    LIMITED,
    BACKGROUND,
    NONE,
    ...
}

If the name in the RPC spec starts with a number, we can use that name as a value for the enum, and add _ as a prefix for the developer-facing value. This is still not using the internalName from RPC spec. For example:

public enum BitsPerSample {
    _8_BIT("8_BIT"),
    _16_BIT("16_BIT");

    private final String VALUE;
    ...
}

If the value tag already exists in the RPC spec, we can keep using it as we do now (the script is handling that case in a correct way). For example:

public enum LightName {
    FRONT_LEFT_HIGH_BEAM(0),
    FRONT_RIGHT_HIGH_BEAM(1),
    FRONT_LEFT_LOW_BEAM(2),
    ...

    private final int VALUE;
    ...
}

@bilal-alsharifi

If the name in the RPC spec doesn't start with a number, we can use that name with no modifications and ignore the internal_name in the RPC spec.

in case when name contains character -, e.g. enum Language should we take name and replace - with _ to avoid java compiling error?

Language has "-" but not in the beginning so it would be generated like
@bilal-alsharifi the question exactly just in your confirmation that - converted to _ is the correct rule for this. We did not use this before as all such cases were covered by internal_name attribute. Do you confirm we could use this rule?

Language has "-" but not in the beginning so it would be generated like
@bilal-alsharifi the question exactly just in your confirmation that - converted to _ is the correct rule for this. We did not use this before as all such cases were covered by internal_name attribute. Do you confirm we could use this rule?

Oh, my bad I misunderstood the question initially, in that case, we can use the name attribute and then replace - with _ for the developer-facing value. but the actual value should never change. Language, for example, should be:
public enum Language {

    EN_US("EN-US"),
    ES_MX("ES-MX")
    ...

    private final String VALUE;

    private Language(String value) {
        this.VALUE = value;
    }
}

@bilal-alsharifi we managed all comments, do you have additional remarks for this PR? Or could you proceed with the approval/merge?

@vladmu We are waiting for the iOS PR to be done in case the iOS team suggested a change that applies to the java suite one. We would like to make sure that the two PRs align before merging them.

Also, we found out that the generated CancelInteraction RPC doesn't compile because it has a method called getFunctionID() that clashes with the method in RPCMessage.
We will probably need to put a list of reserved keywords to fix that case. We are discussing that with the iOS team to see the best way to handle that. We will keep you updated.

Because of the getFunctionID() issue that we mentioned in the previous comment and some other  similar name conflicting issues in iOS, we added a list of reserved keywords that RPC Generators in all platforms (iOS, Java Suite, JavaScript Suite) should avoid using by following these rules:

If the generator needs to create a variable or method and the name was one of the names in the reserved keyword, the generator should append the suffix Param to it. For example getFunctionID  > getFunctionIDParam
Any empty line in the reserved keywords file should be ignored
Any line in the reserved keywords file that starts with one or more # symbols then space should be considered a comment and ignored (like #<space> or ##<space> or ###<space> …). Note that some reserved keywords have a # without a <space> so it can't just check for #.
Reserved keywords matching should be case insensitive
Although the reserved keywords list has a section for each platform, the generator for each platform should avoid using any of the keywords whether it belongs to that platform or another one.

The reserved keywords list is part of the rpc_sepc repo so all generators can access it. Please look at this PR for more info about the reserved keywords.

Also after a discussion with the iOS and Core teams, we found out that all handling of "numeric" enums should be removed because Core expects string values. This has already been done in the iOS RPC Generator and should be reflected in Java Suite in a similar way. Please look at this comment for more details.

Thanks @bilal-alsharifi. Corrected all cases.

Can we put the RPC generator code in /generator directory instead of utils/generator to make it more aligned with sdl_ios and sdl_javascript_suite?

Can we put the RPC generator code in /generator directory instead of utils/generator to make it more aligned with sdl_ios and sdl_javascript_suite?

Ok, done

Because of the getFunctionID() issue that we mentioned in the previous comment and some other similar name conflicting issues in iOS, we added a list of reserved keywords that RPC Generators in all platforms (iOS, Java Suite, JavaScript Suite) should avoid using by following these rules:

If the generator needs to create a variable or method and the name was one of the names in the reserved keyword, the generator should append the suffix Param to it. For example getFunctionID  > getFunctionIDParam
Any empty line in the reserved keywords file should be ignored
Any line in the reserved keywords file that starts with one or more # symbols then space should be considered a comment and ignored (like #<space> or ##<space> or ###<space> …). Note that some reserved keywords have a # without a <space> so it can't just check for #.
Reserved keywords matching should be case insensitive
Although the reserved keywords list has a section for each platform, the generator for each platform should avoid using any of the keywords whether it belongs to that platform or another one.

The reserved keywords list is part of the rpc_sepc repo so all generators can access it. Please look at this PR for more info about the reserved keywords.

@bilal-alsharifi Keywords logic was applied to PR. Could you please check from your side?

Thanks, @ksologubov for making the changes. It looks like at some point in the recent updates to the PR. The script stopped setting the default OUTPUT_DIRECTORY automatically.  So when I run this command now:
python3 ./generator.py -y

I get this message:
usage: generator.py [-h] [-v] [-xml SOURCE_XML] [-xsd SOURCE_XSD] -d
                    OUTPUT_DIRECTORY [-t [TEMPLATES_DIRECTORY]]
                    [-r REGEX_PATTERN] [--verbose] [-e] [-s] [-m] [-y] [-n]
generator.py: error: the following arguments are required: -d/--output-directory

It should always default to the correct OUTPUT_DIRECTORY if no other directory is specified using the -d argument

@ksologubov While I am testing the new changes, I found that in a lot of cases, the generator appends "Param" when it shouldn't. Here are a few examples:
Example 1:
public class HapticRect extends RPCStruct {
    public static final String KEY_ID_PARAM = "idParam";
}

Note: The JSON values should never change:
Example 2:
public GetAppServiceDataResponse(@NonNull Boolean successParam, @NonNull EnumSubset resultCodeParam) {
    this();
    setSuccessParam(successParam);
    setResultCodeParam(resultCodeParam);
}

Note: These params/setters shouldn't have "Param" since they are calling methods in predefined base classes. Also I am not sure why result is of type EnumSubset instead of Result

Example 3:
public class CancelInteraction extends RPCRequest {
    public static final String KEY_FUNCTION_IDPARAM = "functionID";
}

Note: The key should be KEY_FUNCTION_ID_PARAM not KEY_FUNCTION_IDPARAM

The aforementioned snippets are just samples and not a comprehensive list. I recommend using a directory comparison tool (I use Meld) to compare the RPC output before the reserved keywords changes and after them to confirm that only cases that actually need to be changed have changed.

Example 2:
public GetAppServiceDataResponse(@NonNull Boolean successParam, @NonNull EnumSubset resultCodeParam) {
    this();
    setSuccessParam(successParam);
    setResultCodeParam(resultCodeParam);
}

* Note: These params/setters shouldn't have "Param" since they are calling methods in predefined base classes. Also I am not sure why result is of type `EnumSubset` instead of `Result`

@bilal-alsharifi Bilal, get/setSuccess and get/setResultCode both explicitly specified in keywords list. From what you said it should not be there. What should we do in this case? I believe better to remove them from keywords list.

I understand the confusion. In that example, they are calling methods from the base class. The reserved keywords rules apply to APIs in the subclasses (RPCs) but don't apply to APIs in base classes (RPCMessage, RPCStruct, RPCNotification, RPCRequest, RPCResponse). The setSuccess(), setResultCode() are APIs in the base class so they should not be affected by the reserved keywords rules.
public GetAppServiceDataResponse(@NonNull Boolean success, @NonNull Result resultCode){
	this();
	super.setSuccess(success);
	super.setResultCode(resultCode);
}
`

@bilal-alsharifi but according to https://github.com/smartdevicelink/rpc_spec/pull/232

If the generator needs to create a variable or method and the name was one of the names in the reserved keyword, the generator should append the suffix Param to it. For example getFunctionID > getFunctionIDParam
In this case generator working exactly as proposal says by replacing setSuccess keyword in method name with setSuccessParam and so on. "super" was not used in original library implementation so I'm not sure why you provided it above. Please clarify why setSuccess/setResultCode/success/resultCode should not be removed from keyword list if it should not be replaced. I don't see how it's used in any other cases except calling methods from RPCResponse base class from response type functions.

@ksologubov I think you are right. I removed info, success, resultCode from reserved keywords. I will do another review and let you know if there is any more feedback.

@ksologubov I see set/getFunctionId() inside the class CancelInteraction are still not affected by the reserved keywords. They should be set/getFunctionIdParam() as they are the main reason for adding the reserved words.

Can we also pull the latest changes for the rpc_spec submodule after removing the response keywords?

@bilal-alsharifi thanks for removing extra keywords. All above problems was fixed, and suggestions was applied, I checked classes diff with Meld and they looking good from my side, could you please check from your side?

@ksologubov Thanks for making the changes. I have reviewed and tested the PR. It looks good now.

@bilal-alsharifi thank you very much for reviews


jsonpb: Unmarshal error for Oneof field with Capital First Letter

In test_objects.proto I changed the field names to have a first letter as a capital.
message MsgWithOneof {
  oneof union {
    string Title = 1;
    int64 Salary = 2;
  }
}

This produces an error
unknown field "salary" in jsonpb.MsgWithOneof

So technically the fieldname isn't salary anymore, it is Salary, but this is what it marshals to and this is what the tags say it should be
type MsgWithOneof_Salary struct {
	Salary int64 `protobuf:"varint,2,opt,name=Salary,json=salary,oneof"`
}

We actually saw this issue, as well. It was very odd, as it only worked with the specific package from the unit tests. Once MsgWithOneof is pulled out of the package, it will not deserialize the json with a oneof field.
If more details are required, please let me know.
cc @aluzzardi

jsonpb is specified to accept either the .proto original name, or the camelCase name. In this case, that means the acceptable set should be {Salary,salary}. It does indeed sound like a bug.
It looks like a bug specific to oneofs.


Issue with lookup API of digital twin registry

When registering a DT in the central DTR (incl. externalSubjectIDs), customer is not able to lookup the twin via specificAssetID when using the SAME user (tenant) which he used while creating it. When using a different user (tenant), which is mentioned in externalSubjectIDs, client could successfully lookup the twin via specificAssetID.
Current deployed version is 0.2.0-M13-multi-tenancy.

In the currently deployed version, We are also facing delay in lookup api response. When there are 13000 twins, time taken to lookup is more than 1.5 minutes. In the earlier version v0.2.0-M12-multi-tenancy performance of the lookup api was faster. The idea behind using above version was "Digital Twin Registry will not be visible by default unless you explicitly enable them."

This slowness behaviour was observed after the hot fix was deployed
Please advice if we need to upgrade to any specific or latest version to fix these two issues.

Error can be replicated in 3.1 and fixed internally. Further tests in INT (Beta) will happen:
https://semantic-hub.int.cofinity-x.com/semantics/registry/swagger-ui/index.html
We will also fix this issue for the next release 23.12 in the decentralized DTR as enablement service.

We have done the performance improvements in the decentral DTR and released the latest image(v0.3.17).

Issue will be closed. In case of perfomance issues with the newest version, please create a new issue.


Home page refer the wrong twitter account

https://github.com/microsoft/botbuilder-dotnet  (github)  page refer the wrong twitter account (@botframework) , It should be account : @msbotframework

Thanks for the issue and the PR @rvinothrajendran!
@darrenj / @garypretty / @cleemullins , can you please review and check if we need to change this in other repos?
Thanks

@gabog
https://github.com/microsoft/botbuilder-python and
https://github.com/Microsoft/botbuilder-js should be update the same.
Will create a PR for this.

Closing this issue as the PRs are up.

@Virtual-Josh sorry, not get why this PR gets closed

@rvinothrajendran I'm fine to leave this one open so it can be closed on the PR is merged in.


fix: No module named 'six' #1042

As mentioned in https://github.com/pypa/setuptools/pull/1043/files I don't think this makes sense - since six is already used elsewhere in setuptools, why not use it for this as well? It's just the import which needs to be fixed up.

@The-Compiler you are totally right. Thanks!

Duplicate of #1043.


improving logging for FastLogger errors

Logs more information for #1245.

@mamaso -- this is a continuation of the change i made in the SDK: https://github.com/Azure/azure-webjobs-sdk/pull/1095


bug(breadcrumbs): increse visibility of displayBinding in TdBreadcrumbComponent

Bug Report
When building a prod release of an application that consumes CovalentBreadcrumbsModule, the build fails with the following error:
Directive ɵa, Property 'displayBinding' is private and only accessible within class 'TdBreadcrumbComponent'.
Most likely the @HostBinding decorator can only be used on public members/getters.
At the moment, the property mentioned in the error message is private
What is the expected behavior?
Build should not fail, the decorated getter should be public
Which version of Angular and Material, and which browser and OS does this issue affect?
angular: 6.1.x
angular/material,ckdk: 6.4.x
covalent/core: 2.0.0-beta.3

Thanks for the bug report @jotatoledo

Ill submit the PR, please review as soon as you can 👍

will do 👍


Fix broken links in Core v3.0.0 beta-4

Fix broken links in the following pages:
setup/binary.html
setup/source.html

The issue was already solved in another PR.


Search-AzGraph not returning full JSON

The command  Search-AzGraph -Query "where type =~ 'Microsoft.Compute/virtualMachines' | limit 1"   does not return the full JSON like stated in this article

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: f6215348-a08e-86bc-a329-295a233b880e
Version Independent ID: e69d4508-fda7-1f35-fa71-af4eba4098f2
Content: Explore your Azure resources - Azure Resource Graph
Content Source: articles/governance/resource-graph/concepts/explore-resources.md
Service: resource-graph
GitHub Login: @DCtheGeek
Microsoft Alias: dacoulte

@garybushey Thanks for the feedback! I have assigned the issue to the content author to evaluate and update as appropriate.

@garybushey Thanks for the feedback.  You are correct that PowerShell returns a PSCustomObject instead of JSON. To convert the results to the JSON, you can use ConvertTo-Json. The full command would look like Search-AzGraph -Query "where type=~'microsoft.compute/virtualMachines' | limit 1" | ConvertTo-Json. This should provide you the results similar to what is documented.  I'll get this fixed so that the command in the doc uses ConvertTo-Json to show results in an apples-to-apples comparison.  Thanks!
@MicrosoftDocs/azure-cxp-triage #in-progress

Additionally for any finding this item, ConvertTo-Json has a Depth parameter with a default value of 2. If not specified, the cmdlet only converts the first 2 levels of the PSCustomObject into JSON. To avoid this mixed state, specify -Depth 100 when using ConvertTo-Json in this case to avoid the issue. The doc update with both of these items is scheduled to publish this morning.
@garybushey Thank you again for the question and the feedback! Please continue filing Issues when you see something else that doesn't work or doesn't make sense.


Windows: Freshly created package with executable target builds with error 0: error: missing required module 'SwiftShims'

Description
Windows: Freshly created package with executable target builds with error 0: error: missing required module 'SwiftShims'
Expected behavior
Freshly created package should build without errors
Actual behavior
Windows: Freshly created package with executable target builds with error 0: error: missing required module 'SwiftShims'
c:\Users\1\Documents\tmp>swift package init --type executable
Creating executable package: tmp
Creating Package.swift
Creating .gitignore
Creating Sources/
Creating Sources\main.swift

c:\Users\1\Documents\tmp>swift build
error: 'tmp': Invalid manifest (compiled with: ["C:\\Library\\Developer\\Toolchains\\unknown-Asserts-development.xctoolchain\\usr\\bin\\swiftc.exe", "-L", "C:\\Library\\Developer\\Toolchains\\unknown-Asserts-development.xctoolchain\\usr\\lib\\swift\\pm\\ManifestAPI", "-lPackageDescription", "-sdk", "C:\\Library\\Developer\\Platforms\\Windows.platform\\Developer\\SDKs\\Windows.sdk", "-libc", "MD", "-I", "C:\\Library\\Developer\\Platforms\\Windows.platform\\Developer\\Library\\XCTest-development\\usr\\lib\\swift\\windows", "-I", "C:\\Library\\Developer\\Platforms\\Windows.platform\\Developer\\Library\\XCTest-development\\usr\\lib\\swift\\windows\\x86_64", "-L", "C:\\Library\\Developer\\Platforms\\Windows.platform\\Developer\\Library\\XCTest-development\\usr\\lib\\swift\\windows\\x86_64", "-use-ld=lld", "-swift-version", "5", "-I", "C:\\Library\\Developer\\Toolchains\\unknown-Asserts-development.xctoolchain\\usr\\lib\\swift\\pm\\ManifestAPI", "-package-description-version", "5.8.0", "C:\\Users\\1\\AppData\\Local\\Temp\\TemporaryDirectory.fYGiNk\\manifest.swift", "-Xfrontend", "-disable-implicit-concurrency-module-import", "-Xfrontend", "-disable-implicit-string-processing-module-import", "-o", "C:\\Users\\1\\AppData\\Local\\Temp\\TemporaryDirectory.TxK9Yr\\tmp-manifest.exe"])
<unknown>:0: error: missing required module 'SwiftShims'

Steps to reproduce
Run commands:

swift package init --type executable
swift build

Swift Package Manager version/commit hash
Swift Package Manager - Swift 5.8.0
Swift & OS version (output of swift --version && uname -a)
Swift 5.8
swift --version
compnerd.org Swift version 5.8 (swift-5.8-RELEASE)
Target: x86_64-unknown-windows-msvc

WIndows 10 Pro 10.0.19045

cc @compnerd

Given that this is 5.8, I would hazard a guess that you have failed to repair the installation after an update of Visual Studio.

You are right. Documentation at https://www.swift.org/getting-started/ has paragraph:

Repairing after Visual Studio Updates
If Visual Studio is updated, you may have to repair the installation. See Microsoft’s instructions for repairing installed programs.

It's not clear exactly what has to be "repaired" and how.
Here are the steps.

Launch Control Panel.
In Control Panel launch Programs and Features.
In Programs and Features find Swift Developer Package for Windows x86_64.
Right click on Swift Developer Package for Windows x86_64 and click Change in contectual menu.
In launched installer click Repair and follow instructions.

After these steps swift build builds package normally.
Probably, in does make sense update documentation with these "repair" steps. Does it?

cc @compnerd

@valeriyvan yeah, I think that it makes sense as 5.8 was just released so it is the current stable release.  Would you mind making a PR against apple/swift-website for that?

I don't think that we should do this anymore.  The toolchain will no longer modify the VS installation and instead injects a VFS to map the module in to the build.  This will properly remove this along with the necessity for administrator privileges (other than to instal to a system directory).


[SECURITY] Accepting and storing an unlimited number of CRYPTO frames within a single connection

Aioquic may infinitely receive CRYPTO frames within a single connection, rapidly depleting memory and subsequently being forcefully closed by the operating system, leading to a denial of service attack.
In line 1613 of quic/connection.py, the server only checks offset + length < 2^62 - 1 when processing CRYPTO frames, and then stores their contents in QuicConnection._crypto_streams[Epoch.ONE_RTT] , resulting in memory consumption.
To validate the effect, I simulated an attacker sending CRYPTO frames with an Offset set to 0x1000, but with a length of only 0x200 to prevent some memory merging operations. As shown in the graph, within the 90s of the attack occurrence, aioquic consumed 100GB of memory and will be killed soon by the operating system.

This should be fixed now, thanks for your report.


Failed to load JavaScript Standard Style library on Visual Studio Code

What version of this package are you using? 17.0.0
What operating system, Node.js, and npm version? 6.14.17
What happened? Failed to load JavaScript Standard Style library on Visual Studio Code Plugin
What did you expect to happen? load successfully
Are you willing to submit a pull request to fix this bug? no
I have installed the newest JS Standard plugin on visual studio code and installed the engine globally.
However, it failed to load. Visual Studio Code version 1.72.1. I have reopen VS code after installation.
[Info  - 6:41:32 a.m.]
Failed to load the JavaScript Standard Style library for the document /home/user/test.js

To use JavaScript Standard Style please install JavaScript Standard Style by running 'npm install standard' in the workspace folder sdmc
or globally using 'npm install -g standard'. You need to reopen the workspace after installing JavaScript Standard Style.

Alternatively you can disable JavaScript Standard Style for the workspace folder sdmc by executing the 'Disable JavaScript Standard Style' command.
[Info  - 6:41:32 a.m.]
Failed to load the JavaScript Standard Style library for the document /home/user/test.js

To use JavaScript Standard Style please install JavaScript Standard Style by running 'npm install standard' in the workspace folder sdmc
or globally using 'npm install -g standard'. You need to reopen the workspace after installing JavaScript Standard Style.

Alternatively you can disable JavaScript Standard Style for the workspace folder sdmc by executing the 'Disable JavaScript Standard Style' command.

$ sudo npm -g list --depth=n

npm WARN invalid config depth="n" set in command line options

npm WARN invalid config Must be one of: null, numeric value

/usr/local/lib

├──<EMAIL_ADDRESS>
└──<EMAIL_ADDRESS>
    "standard.enable": true,
    "standard.enableGlobally": true,
    "standard.autoFixOnSave": true,
    "standard.usePackageJson": false

Also, tried to uninstall VS code from 1.72.1 and updated 1.72.2. Have the same error.

If I installed with npm install standard instead of --globally.
The following error shows
[Info  - 7:12:36 a.m.] JavaScript Standard Style server stopped.
[Info  - 7:12:36 a.m.] JavaScript Standard Style server is running.
[Info  - 7:12:36 a.m.] JavaScript Standard Style library loaded from: /home/user/node_modules/standard/index.js
TypeError: callback is not a function
    at /home/cyrus/.vscode/extensions/standard.vscode-standard-2.1.2/server/out/server.js:667:17
TypeError: callback is not a function
    at /home/cyrus/.vscode/extensions/standard.vscode-standard-2.1.2/server/out/server.js:667:17
TypeError: callback is not a function
    at /home/cyrus/.vscode/extensions/standard.vscode-standard-2.1.2/server/out/server.js:667:17
TypeError: callback is not a function
    at /home/cyrus/.vscode/extensions/standard.vscode-standard-2.1.2/server/out/server.js:667:17

updated to node v16.18.0, solve the Failed to load JavaScript Standard Style library error.
Now, only having the problem with
TypeError: callback is not a function
    at /home/cyrus/.vscode/extensions/standard.vscode-standard-2.1.2/server/out/server.js:667:17

Will keep on track for this ticket. https://github.com/standard/vscode-standard/issues/465


feat: add UnwarpOr and UnwarpOrDefault to pointer pkg

When I try to use Unwarp in the pointer package, it panics when I pass it a nil pointer.
This is not what I want; I want it to return a zero value of the pointer's type.
Or the fallback value I provide.
So I created two new functions, UnwarpOr and UnwarpOrDefault, to do this.

If the pointer is nil, UnwarpOr will return the fallback value.
If the pointer is nil, UnwarpOrDefault will return the zero value of the type of the pointer.

Codecov Report
Patch coverage: 100.00% and project coverage change: +0.02 :tada:

Comparison is base (154ec56) 80.55% compared to head (d30aabe) 80.57%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #116      +/-   ##
==========================================
+ Coverage   80.55%   80.57%   +0.02%
==========================================
  Files          63       63
  Lines        6422     6431       +9
==========================================
+ Hits         5173     5182       +9
  Misses        960      960
  Partials      289      289

Impacted Files
Coverage Δ

pointer/pointer.go
100.00% <100.00%> (ø)

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

cool, will merge it and release in v2.2.4


cookbook stagnated?

@rigrassm there are a slew of pull requests to fix bugs right now, and some outstanding issues.
If noone is bothering to curate this, would you mind turning it over to someone who will? I'm volunteering as I have a vested interest in this for my environment.

@sjsadowski Just sent the tranfer ownership request to you through the Chef Supermarket.

@rigrassm Thanks, I accepted it.

@rigrassm lmk if you want me to fork this or transfer it - I'd prefer transfer to keep the issues and history intact, but I can move forward either way.

I just sent the repo transfer to you. @sjsadowski

@rigrassm Thanks very much - I've now transferred the cookbook and completed transfer of this repo.


Switching to "main mirror" now a no-op?

https://github.com/msys2/msys2-autobuild/blob/a0a0b3f47b5c5e9e09e42ae9261ee230dfbd2da6/.github/workflows/build.yml#L125-L126
This will not match anymore now that the include lines are all mirrorlist.mingw.  Given that nobody noticed, this may not actually be necessary anymore now that mirror.msys2.org is the 'default' mirror?

There is a tiny chance that after an update of repo.msys2.org we parse the repo, but mirror.msys2.org still doesn't know about it and redirects to an outdated mirror, so in theory it is still needed, though very unlikely that there are any bad consequences.


Injectable wrappers

Summary: Accessor singleton to allow swapping real wrappers with mocks
Type: Feature
Test Plan: UT, CT, Native Build
Jira: RIALTO-405

https://jenkins.code.rdkcentral.com/job/github-triggered/44382/ started

https://jenkins.code.rdkcentral.com/job/build-component/82970/ started.

https://jenkinsrdkm.cmf.code.rdkcentral.com/job/github-triggered/10066/ started

https://jenkins.code.rdkcentral.com/job/github-triggered/44384/ started

https://jenkins.code.rdkcentral.com/job/build-component/82972/ started.

https://jenkinsrdkm.cmf.code.rdkcentral.com/job/github-triggered/10068/ started

https://jenkinsrdkm.cmf.code.rdkcentral.com/job/build-component-platform/15319/ started.

https://jenkins.code.rdkcentral.com/job/github-triggered/44386/ started

https://jenkinsrdkm.cmf.code.rdkcentral.com/job/github-triggered/10069/ started

https://jenkins.code.rdkcentral.com/job/build-component/82973/ started.

https://jenkinsrdkm.cmf.code.rdkcentral.com/job/build-component-platform/15320/ started.

https://jenkinsrdkm.cmf.code.rdkcentral.com/job/build-component-platform/15321/ started.

build-rpi-refapp2 Console Log uploaded to Gist URL: https://gist.github.com/rdkcmf-jenkins/476d091cb7132a59a9d847f2fe1d019d

build-rpi-mc-wpe-dunfell Console Log uploaded to Gist URL: https://gist.github.com/rdkcmf-jenkins/fb43517d5034ac943f84c84ff93b6f5f

build-rpi-hybrid-wpe-dunfell Console Log uploaded to Gist URL: https://gist.github.com/rdkcmf-jenkins/e096d64483b0ee5eef28b8eae9129563

build-rpi4-mc Console Log uploaded to Gist URL: https://gist.github.com/rdkcmf-jenkins/fd2ec8fd7f556de9b490b84c8ac211a1

build-rpi-mc-wpe-dunfell Console Log uploaded to Gist URL: https://gist.github.com/rdkcmf-jenkins/446a547ac102b92613b69f2b02ef6ac5

build-rpi-refapp2 Console Log uploaded to Gist URL: https://gist.github.com/rdkcmf-jenkins/1061cc329e556e162512e180966576c9

build-rpi-hybrid-wpe-dunfell Console Log uploaded to Gist URL: https://gist.github.com/rdkcmf-jenkins/e08b02ef37277d87cc2bf086e93dcd79

build-rpi-mc-wpe-dunfell Console Log uploaded to Gist URL: https://gist.github.com/rdkcmf-jenkins/1abac8538c159d7958abb2f4cb86e3c8

build-rpi-hybrid-wpe-dunfell Console Log uploaded to Gist URL: https://gist.github.com/rdkcmf-jenkins/9959a2665158f9dc67e5243b67eb2d00

build-rpi4-hybrid Console Log uploaded to Gist URL: https://gist.github.com/rdkcmf-jenkins/0512057cb1b59e54411533b6b93760f8

build-rpi-refapp2 Console Log uploaded to Gist URL: https://gist.github.com/rdkcmf-jenkins/772276542167358196f0af28e12eebd4

build-rpi4-mc Console Log uploaded to Gist URL: https://gist.github.com/rdkcmf-jenkins/0c9cdd2fc191f3480f0d5c41bfcd21a9

build-rpi4-mc Console Log uploaded to Gist URL: https://gist.github.com/rdkcmf-jenkins/c00a01743f8c0958e37893034c0171f6

build-rpi4-hybrid Console Log uploaded to Gist URL: https://gist.github.com/rdkcmf-jenkins/ae733b830b632b6a581223f33c61813a

Component build fix:
https://gerrit.teamccp.com/#/c/801099/

build-brcm-refboard2 Console Log uploaded to Gist URL: https://gist.github.com/rdkcmf-jenkins/f0eca869281a43200ed9042f3faad5c3

https://jenkins.code.rdkcentral.com/job/build-component/83195/ started.

https://jenkinsrdkm.cmf.code.rdkcentral.com/job/build-component-platform/15533/ started.

build-rpi4-hybrid Console Log uploaded to Gist URL: https://gist.github.com/rdkcmf-jenkins/92588becd3c14f7a957063c96bd320eb

build-rpi4-mc Console Log uploaded to Gist URL: https://gist.github.com/rdkcmf-jenkins/d236f2a36b1ccb7065b65d730387eb6e

https://jenkinsrdkm.cmf.code.rdkcentral.com/job/github-triggered/10230/ started

https://jenkinsrdkm.cmf.code.rdkcentral.com/job/build-component-platform/15573/ started.


docs: set up Astro Starlight docs site

PR Checklist

[x] Addresses an existing open issue: fixes #405
[x] That issue was marked as status: accepting prs
[x] Steps in CONTRIBUTING.md were taken

Overview
Revamps the site to be a full Astro Starlight site.
Co-authored-by: @delucis

@all-contributors please add @delucis for doc.

🤖 Beep boop! This comment was added automatically by all-contributors-auto-action.
Not all contributions can be detected from Git & GitHub alone. Please comment any missing contribution types this bot missed.
...and of course, thank you for contributing! 💙

@all-contributors please add @joshuakgoldberg for doc.

🤖 Beep boop! This comment was added automatically by all-contributors-auto-action.
Not all contributions can be detected from Git & GitHub alone. Please comment any missing contribution types this bot missed.
...and of course, thank you for contributing! 💙


ArgumentOutOfRangeException

For anyone trying this tool out and encountering similar issue.
Problem:
While testing on a very small scale, I encounterent ArgumentOutOfRangeException in CloneGorups.cs:line 47.
Cause:
If there are very 2 entries in duplicationFactors variable, meaning there are only 2 unique clone clusters, then the midpoint becomes 1. Then the duplicationFactors[midpoint + 1] is causing an index out of range exception.
Solution:
Use on bigger projects and assume that the duplicationFactors includes more entries or add a special case to the code where duplicationFactors.Count == 2.
Error log:
Unhandled Exception: System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
   at System.Collections.Generic.List`1.get_Item(Int32 index)
   at NearCloneDetector.CloneGroups..ctor(IEnumerable`1 clonePairs) in /near-duplicate-code-detector/DuplicateCodeDetector/CloneGroups.cs:line 47
   at NearCloneDetector.CloneDetectorCli.DetectClones(IDictionary`2 arguments) in /near-duplicate-code-detector/DuplicateCodeDetector/CloneDetectorCli.cs:line 68
   at NearCloneDetector.CloneDetectorCli.Main(String[] args) in /near-duplicate-code-detector/DuplicateCodeDetector/CloneDetectorCli.cs:line 30

Hi @hsellik,
Thanks for reporting this!
@mdrafiqulrabin provided a solution, which I just merged. Hope this works for you. Feel free to reopen the issue if this isn't resolved. And of course, feel free to submit new issues if you bump into any problems!