Azure App Service Deploy task: Typo, should read 'stages' instead of 'steps' in yaml example

I believe there is a typo in the yaml example where the top level item is steps but it should be stages.
Here it is for context, and I've put in a comment where it should read stages instead of steps
pool:
  vmImage: 'windows-latest'

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'

steps: # THIS SHOULD READ STAGES.
 - stage: DeployDevStage
    displayName: 'Deploy App to Dev Slot'
    jobs:
      - job:  DeployApp
        displayName: 'Deploy App'
        steps:
        - task: DownloadPipelineArtifact@2
          inputs:
            buildType: 'current'
            artifactName: 'drop'
            targetPath: '$(System.DefaultWorkingDirectory)'
        - task: AzureRmWebAppDeployment@4
          inputs:
            ConnectionType: 'AzureRM'
            azureSubscription: 'Fabrikam Azure Subscription - PartsUnlimited'
            appType: 'webApp'
            WebAppName: 'partsunlimited'
            deployToSlotOrASE: true
            ResourceGroupName: 'rgPartsUnlimited'
            SlotName: 'Dev'
            packageForLinux: '$(System.DefaultWorkingDirectory)/**/*.zip'

  - stage: DeployStagingStage
    displayName: 'Deploy App to Staging Slot'
    dependsOn: DeployDevStage
    jobs:
      - job:  DeployApp
        displayName: 'Deploy App'
        steps:
        - task: DownloadPipelineArtifact@2
          inputs:
            buildType: 'current'
            artifactName: 'drop'
            targetPath: '$(System.DefaultWorkingDirectory)'
        - task: AzureRmWebAppDeployment@4
          inputs:
            appType: webApp
            ConnectionType: AzureRM
            ConnectedServiceName: 'Fabrikam Azure Subscription - PartsUnlimited'
            ResourceGroupName: 'rgPartsUnlimited'
            WebAppName: 'partsunlimited'
            Package: '$(System.DefaultWorkingDirectory)/**/*.zip'
            deployToSlotOrASE: true
            SlotName: 'staging'

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

ID: 29c94df7-9de9-ea1a-8b77-d1e6023694dc
Version Independent ID: a525989e-2e0a-0399-556e-9011ee95da4e
Content: Azure App Service Deploy task - Azure Pipelines
Content Source: docs/pipelines/tasks/deploy/azure-rm-web-app-deployment.md
Product: devops
Technology: devops-cicd-tasks
GitHub Login: @RoopeshNair
Microsoft Alias: ronai

Thank you, this will be fixed and live today.


0.48.4

A user reported issues with using Rust 1.48 with windows-targets. It is quite difficult to validate as that is such an old version of Rust, but this tweak should address the compatibility concern.
This just flips windows-targets and the arch-specific crates to use Rust edition 2018.

Thanks for checking folks.

I have published 0.48.4 of windows-targets but even now I'm not convinced this actually works. Rust 1.48 is really broken.
When I set rustup default 1.48 and then build an empty project with a dependency on windows-targets it complains about the resolver. 🤷♂

The Cargo.toml that it's using looks like this:
# THIS FILE IS AUTOMATICALLY GENERATED BY CARGO
#
# When uploading crates to the registry Cargo will automatically
# "normalize" Cargo.toml files for maximal compatibility
# with all versions of Cargo and also rewrite `path` dependencies
# to registry (e.g., crates.io) dependencies.
#
# If you are reading this file be aware that the original Cargo.toml
# will likely look very different (and much more reasonable).
# See Cargo.toml.orig for the original contents.

[package]
edition = "2018"
name = "windows-targets"
version = "0.48.4"
authors = ["Microsoft"]
description = "Import libs for Windows"
readme = "readme.md"
license = "MIT OR Apache-2.0"
repository = "https://github.com/microsoft/windows-rs"
resolver = "2"

[target.aarch64-pc-windows-gnullvm.dependencies.windows_aarch64_gnullvm]
version = "0.48.4"

[target."cfg(all(target_arch = \"aarch64\", target_env = \"msvc\", not(windows_raw_dylib)))".dependencies.windows_aarch64_msvc]
version = "0.48.4"

[target."cfg(all(target_arch = \"x86\", target_env = \"gnu\", not(windows_raw_dylib)))".dependencies.windows_i686_gnu]
version = "0.48.4"

[target."cfg(all(target_arch = \"x86\", target_env = \"msvc\", not(windows_raw_dylib)))".dependencies.windows_i686_msvc]
version = "0.48.4"

[target."cfg(all(target_arch = \"x86_64\", target_env = \"gnu\", not(target_abi = \"llvm\"), not(windows_raw_dylib)))".dependencies.windows_x86_64_gnu]
version = "0.48.4"

[target."cfg(all(target_arch = \"x86_64\", target_env = \"msvc\", not(windows_raw_dylib)))".dependencies.windows_x86_64_msvc]
version = "0.48.4"

[target.x86_64-pc-windows-gnullvm.dependencies.windows_x86_64_gnullvm]
version = "0.48.4"

The resolver = 2 line is the problem. If the original toml doesn't have it, then you may have to use an older cargo to publish it.

Thanks, there's no resolver in the original toml but there is one in the workspace for windows-rs. Older versions of cargo just don't work well or at all within the context of a workspace.

Yeah, 1.48 CI also caused us a lot of trouble.

I can fix the 1.48 resolver thing by temporarily deleting the workspace file, publishing, and then restoring it.
I think I'll do that and publish windows-targets 0.48.5 and that will be the final release to support 1.48.
I will then switch everything in windows-rs to use edition 2021 and MSRV 1.56.

Sounds like a good plan to me.

All done. windows-targets 0.48.5 has been published and I've manually confirmed that it builds fine with Rust 1.48.

Thanks @kennykerr!


syntax issue in readme.md File

Hi, in the existing code sample in the wiki page,
namespace :recurring
task init: :environment do
MyTask.schedule!
MyOtherTask.schedule!
if Rails.env.production?
  MyProductionOnlyTask.schedule!
end

end
end
there is a do missing in the wiki page

Thanks!


Set up package and development tooling

adds nird package
adds tests
configures formatting, linting, type-checking
runs tests and checks in GitHub Actions

git clone did not work. probably do url should not have : instead /

micromamba failed to install everything on Windows!
Installing pip packages: ruff, mypy
The system cannot find the path specified.
critical libmamba pip failed to install packages

git clone did not work. probably do url should not have : instead /

Thanks! I added a note with the HTTPS option.

micromamba failed to install everything on Windows!

Can you pull the latest and try again? I think we need pip explicitly as a dependency in the environment.yaml before specifying pip packages to install.

still get an error:
Installing pip packages: ruff, mypy
info     libmamba Calling: C:\Users\...\micromamba\envs\nird\python.exe -m pip install -r C:\Oxford\Research\DAFNI\DAFNI-NIRD\mambaf5NgzkSsTLx --no-input
The system cannot find the path specified.
critical libmamba pip failed to install packages

workaround is to run pip directly
micromamba activate nerd
pip install ruff mypy --editable .


Publisher basic example does not work in Teensy 4.1 after receiving a new docker image micro_ros_static_library_builder Pull

Issue template

Hardware description:  Teensy4.1
RTOS:  No
Installation type:  Arduino IDE (Version : 2.1.0)
Version or commit hash:  humble

Steps to reproduce the issue

(1) code behavior

Create 1 Publisher and 1 Timer on 1 node to publish ros message
Using examples from micro_ros_arduino/examples/micro-ros_publisher

#include <micro_ros_arduino.h>

#include <stdio.h>
#include <rcl/rcl.h>
#include <rcl/error_handling.h>
#include <rclc/rclc.h>
#include <rclc/executor.h>

#include <std_msgs/msg/int32.h>

rcl_publisher_t publisher;
std_msgs__msg__Int32 msg;
rclc_executor_t executor;
rclc_support_t support;
rcl_allocator_t allocator;
rcl_node_t node;
rcl_timer_t timer;

#define LED_PIN 13

#define RCCHECK(fn) { rcl_ret_t temp_rc = fn; if((temp_rc != RCL_RET_OK)){error_loop();}}
#define RCSOFTCHECK(fn) { rcl_ret_t temp_rc = fn; if((temp_rc != RCL_RET_OK)){}}

void error_loop(){
  while(1){
    digitalWrite(LED_PIN, !digitalRead(LED_PIN));
    delay(100);
  }
}

void timer_callback(rcl_timer_t * timer, int64_t last_call_time)
{
  RCLC_UNUSED(last_call_time);
  if (timer != NULL) {
    RCSOFTCHECK(rcl_publish(&publisher, &msg, NULL));
    msg.data++;
  }
}

void setup() {
  set_microros_transports();

  pinMode(LED_PIN, OUTPUT);
  digitalWrite(LED_PIN, HIGH);

  delay(2000);

  allocator = rcl_get_default_allocator();

  //create init_options
  RCCHECK(rclc_support_init(&support, 0, NULL, &allocator));

  // create node
  RCCHECK(rclc_node_init_default(&node, "micro_ros_arduino_node", "", &support));

  // create publisher
  RCCHECK(rclc_publisher_init_default(
    &publisher,
    &node,
    ROSIDL_GET_MSG_TYPE_SUPPORT(std_msgs, msg, Int32),
    "micro_ros_arduino_node_publisher"));

  // create timer,
  const unsigned int timer_timeout = 1000;
  RCCHECK(rclc_timer_init_default(
    &timer,
    &support,
    RCL_MS_TO_NS(timer_timeout),
    timer_callback));

  // create executor
  RCCHECK(rclc_executor_init(&executor, &support.context, 1, &allocator));
  RCCHECK(rclc_executor_add_timer(&executor, &timer));

  msg.data = 0;
}

void loop() {
  delay(100);
  RCSOFTCHECK(rclc_executor_spin_so

Expected behavior

1 timer publishes a ROS message every second.

Actual behavior

Confirm that 1 publisher is created.
The message is not published.

Additional information

The operating system of the Arduino IDE is Windows 10.

In WSL, the precompiled library was built by referring to the following address.
- Reference address 1 : https://github.com/micro-ROS/micro_ros_arduino
- Reference address 2 : https://hub.docker.com/r/microros/micro_ros_static_library_builder

After updating the microros/micro_ros_static_library_builder Docker image using the Docker Pull command around 23.08.17, the code does not work.

The existing image was used around 23.06.29 using the Docker Pull command.

Question: Are there any changes to microros/micro_ros_static_library_builder Docker between 23.06.29 and 23.08.17? Also, is there any cause of the problem that you know about this issue?

Teensy support was updated to match the latest Arduino Teensy Support:

https://github.com/micro-ROS/docker/pull/97
https://github.com/micro-ROS/micro_ros_arduino/pull/1482

Are you using the latest Arduino Teensy support?

Teensy support was updated to match the latest Arduino Teensy Support:

Update teensy compiler docker#97
Fix teensy patch and compiler #1482

Are you using the latest Arduino Teensy support?

Thanks for your help.
When I tested the micro-ros_publisher and micro-ros_reconnection_example examples on the Teensy 4.1 development board as you advised, they worked successfully.
But I have one additional question.
There is a code written in the Arduino IDE that creates and operates 16 Publishers and 8 Subscriptions on one node.
It worked normally in teensy 1.57.2, but when it ran in teensy 1.58.x, a USB error occurred and publisher, subscription, and node were not created during agent reconnection. Have you ever experienced this problem?

Are you rebuilding the library for allowing 16 publishers and 8 subs in the colcon meta?

Are you rebuilding the library for allowing 16 publishers and 8 subs in the colcon meta?

that's right.
I rebuilt the library by creating a colocon.meta file as follows.
{
    "names": {
        "tracetools": {
            "cmake-args": [
                "-DTRACETOOLS_DISABLED=ON",
                "-DTRACETOOLS_STATUS_CHECKING_TOOL=OFF"
            ]
        },
        "rosidl_typesupport": {
            "cmake-args": [
                "-DROSIDL_TYPESUPPORT_SINGLE_TYPESUPPORT=ON"
            ]
        },
        "rcl": {
            "cmake-args": [
                "-DBUILD_TESTING=OFF",
                "-DRCL_COMMAND_LINE_ENABLED=OFF",
                "-DRCL_LOGGING_ENABLED=OFF"
            ]
        },
        "rcutils": {
            "cmake-args": [
                "-DENABLE_TESTING=OFF",
                "-DRCUTILS_NO_FILESYSTEM=ON",
                "-DRCUTILS_NO_THREAD_SUPPORT=ON",
                "-DRCUTILS_NO_64_ATOMIC=ON",
                "-DRCUTILS_AVOID_DYNAMIC_ALLOCATION=ON"
            ]
        },
        "microxrcedds_client": {
            "cmake-args": [
                "-DUCLIENT_PIC=OFF",
                "-DUCLIENT_PROFILE_UDP=OFF",
                "-DUCLIENT_PROFILE_TCP=OFF",
                "-DUCLIENT_PROFILE_DISCOVERY=OFF",
                "-DUCLIENT_PROFILE_SERIAL=OFF",
                "-UCLIENT_PROFILE_STREAM_FRAMING=ON",
                "-DUCLIENT_PROFILE_CUSTOM_TRANSPORT=ON"
            ]
        },
        "rmw_microxrcedds": {
            "cmake-args": [
                "-DRMW_UXRCE_MAX_NODES=1",
                "-DRMW_UXRCE_MAX_PUBLISHERS=16",
                "-DRMW_UXRCE_MAX_SUBSCRIPTIONS=8",
                "-DRMW_UXRCE_MAX_SERVICES=1",
                "-DRMW_UXRCE_MAX_CLIENTS=1",
                "-DRMW_UXRCE_MAX_HISTORY=8",
                "-DRMW_UXRCE_TRANSPORT=custom",
                "-DRMW_UXRCE_MAX_GUARD_CONDITION=10"
            ]
        }
    }
}

So, we need some more details about your code and approach to find out why it is not working.


Incorrect viewport size after window resizing and HDPIMode.Logical

Seems to be caused by commit a5286e70f1ee279859ee8e8cc798b8444d458aaf , specifically where:
gl20.glViewport(0, 0, width, height);
was replaced with
gl20.glViewport(0, 0, getWidth(), getHeight());
This results in the viewport size being set to logical pixels and not true pixels, which results in incorrect dimensions if display scaling is not 1. Some gl operations (viewport, scissor, etc) require true pixels in all cases.
I can reproduce this on my M1 mac (display scale of 2), but it should also happen on other machines with HDPI scaling. As a temporary workaround I can call Gdx.gl.glViewport(0, 0, Gdx.graphics.getBackBufferWidth(), Gdx.graphics.getBackBufferHeight()); in my application's resize method.
Please select the affected platforms

[ ] Android
[ ] iOS
[ ] HTML/GWT
[X] Windows
[X] Linux
[X] macOS

I don't have any machines that I could encounter this on, but maybe @NathanSweet could take a look at the changes he committed and explain what's happening in that code? It used width, height before, changed to getWidth(), getHeight(), and maybe should use the back buffer's width and height instead?

https://github.com/libgdx/libgdx/commit/a5286e70f1ee279859ee8e8cc798b8444d458aaf fixes one of the issues introduced by https://github.com/libgdx/libgdx/commit/76a4e18e5120c8c8e0198707d68101c543b3a2c4, but in turn breaks not only viewport sizes with display scaling, but rendering during resizing as well (see #6808). We need to figure out what the cause for badlogics original bug is (and whether it happens on all platforms and even without the glfw-awt-macos extension). Then we could ideally revert both of those commits.

Maybe HdpiUtils.glViewport() is what we're looking for once we know what motivated the change in the first place.

Use of HdpiUtils is possible here, but it seems unnecessary when LWJGL3 is already providing the width and height in true pixels as part of the resize callback, here's the method header comment for GLFWFramebufferSizeCallback.invoke:
Will be called when the framebuffer of the specified window is resized.
Params:
window – the window whose framebuffer was resized
width – the new width, in pixels, of the framebuffer
height – the new height, in pixels, of the framebuffer

True, that should work if we execute resize() on every callback but what I guess happened here is that after the change to only call resize() once on current frame (skipping any other calls with updated sizes) and delay it with a Runnable to next frame, the size provided by width and height could be wrong in some cases so the way to be consistent was to abotain it from getWidth() and getHeight(). If the fix to skip callback calls is good (I don't know about that) I think the solution is to use HdpiUtils.

Sorry I'm a bit late. The runnable is only posted once (the first time) so we need to get the latest width/height rather than use the method parameters.
getWidth and getHeight return the logical size depending on window.getConfig().hdpiMode. We can use backBufferWidth and backBufferHeight instead:
gl20.glViewport(0, 0, backBufferWidth, backBufferHeight);

@00-Evan did Nate's commit fix this for you?

Just tested with 1.11.1-SNAPSHOT and the issue seems to be resolved, thanks.


Update README.md and build.sh

The README.md step 14 isn't accurate; updated to use the correct commands.
Updated build.sh to create container so that run.sh works.

Would also be great if you could add the link to the article attached you've linked in the issue (#7) to the sources section in README


Add required aria-label prop to VIconButton

Problem

The IconButton component should always have an aria- label unless it is aria-hidden, which it shouldn't probably ever be considering it's an interactive part of the page. Without the label screen readers don't have the necessary information to describe the button to the user.
Description

We should add a required prop for the aria-label attribute to enforce that it is always passed when using this component.
Implementation

[ ] 🙋 I would be interested in implementing this feature.

I would be interested in resolving this bug.

The issue's assigned to you @ramadanomar, thank you.

Just a quick question: Wouldn't it be better to require aria-label as a prop for VButton component as VIConButton is just a VButton with a VIcon. Shouldn't all buttons have an aria label to improve accesibility?
This is how VIconButton template looks like
`

<slot name="default" :icon-size-classes="iconSizeClasses" />
<VIcon
  v-if="iconProps"
  class="pointer-events-none"
  :class="iconSizeClasses"
  v-bind="iconProps"
/>

`

That's a good question. As far as I understand it, aria-label is redundant on a button that has descriptive text. A screen reader will pick and read only one or the other, not both, so they'll need to match (and be sensible) anyway, for a normal button.
The reason it's required for an icon button is because the icon is not interpretable by the screen reader.
If you have a different understanding of aria-label for a textual button though with examples, please let me know. You can see on this WAI-ARIA button examples page, however, that they do not use aria-label for the buttons that have regular text content: https://www.w3.org/WAI/ARIA/apg/example-index/button/button


samples: mesh: nrf52: to solve pending issues

Edited README.rst as per latest changes
Signed-off-by: Vikrant More<EMAIL_ADDRESS>

@jhedberg
Kindly do not merged this. I'm waiting for PTS logs from @MariuszSkamra to solve the pending issues.

@kolodgrz once you're freed up from current PTS testing, could you run the relevant mesh model tests on the latest master branch for samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app/ and report the findings to this PR or a separate issue. @vikrant8051 will then fix them. @vikrant8051 , @kolodgrz is handling PTS testing now for awhile since @MariuszSkamra is away.

@jhedberg I didn't reviewed this app before and don't have test plan for this. So first of all I have to create test plan. Is it somewhere documented, to not double work ?

@jhedberg I didn't reviewed this app before and don't have test plan for this. So first of all I have to create test plan. Is it somewhere documented, to not double work ?

@MariuszSkamra already did a few runs of these tests, but I'm not sure of where his test plan is or if he created any documentation for it.

@kolodgrz Please wait & don't yet execute PTS. I have to change things as per latest feedback received from PTS member from SIG. I will inform you once I do with my changes. Thank You !!

@jhedberg Things are ready. Please review now.

@sjanc @kolodgrz what's the status on running the PTS tests on this?

@carlescufi @jhedberg
After syncing with Main branch, during testing I got this fault:
***** MPU FAULT *****
Instruction Access Violation
***** Hardware exception *****
Current thread ID = 0x20001884
Faulting instruction address = 0x20001c70
Fatal fault in ISR! Spinning...
I'm using buttons to publish messages to Servers running on same board (nrf52_PDK). Before latest sync, everything was working perfectly.
I executed following command for debugging -
/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-addr2line -e /home/vikrant/zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app/build/zephyr/zephyr.elf 0x20001c70
o/p -> :?

@carlescufi @jhedberg
I don't know how, but previously mentioned MPU fault issue has solved !!

Hi, Any update regarding PTS ?
Thank You  !!

@carlescufi @jhedberg
Once again got following fault
***** MPU FAULT *****
Instruction Access Violation
***** Hardware exception *****
Current thread ID = 0x2000188c
Faulting instruction address = 0x20001c5c
Fatal fault in ISR! Spinning...

Enable stack analysis to check stacks usage. I had similar issue some time ago and the reason was too small system workqueue size.

@MariuszSkamra
Thanks for solution. Let me check it !!

@MariuszSkamra
After setting CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096, issue has solved.
Thanks for the solution.

@MariuszSkamra
It come back !! With actual lights (with PWM) getting MPU fault if received message contains transition time & delay fields.
It was not under my observation before syncing with master branch.

List of FAILING test cases:
MMDL/SR/GOO/BV-02-C https://hastebin.com/ahaderunij.cs https://hastebin.com/ositixurik.sql
MMDL/SR/GLV/BV-02-C https://hastebin.com/tatoqimuxo.shell https://hastebin.com/hunozuyuzu.sql
MMDL/SR/GLV/BV-03-C https://hastebin.com/iwutunozuh.shell https://hastebin.com/wofiwucumi.sql
MMDL/SR/GLV/BV-05-C https://hastebin.com/ikevitiduh.cs https://hastebin.com/ezaberujev.sql
MMDL/SR/GLV/BV-06-C https://hastebin.com/ramasiboya.cs https://hastebin.com/rejapigona.php
MMDL/SR/LLN/BV-06-C https://hastebin.com/imizuxepuz.pl https://hastebin.com/mediwoduga.sql
MMDL/SR/LLN/BV-07-C https://hastebin.com/yepigoyuta.pl https://hastebin.com/ajukokoqin.sql
MMDL/SR/LLN/BV-08-C https://hastebin.com/zilosayibe.pl https://hastebin.com/ocayekecul.sql
MMDL/SR/LLN/BV-09-C https://hastebin.com/ayubofabom.pl https://hastebin.com/nekedobewu.sql
MMDL/SR/LLN/BV-10-C https://hastebin.com/fequwelinu.pl https://hastebin.com/afomogiqox.sql
MMDL/SR/LLN/BV-11-C https://hastebin.com/teraratuda.pl https://hastebin.com/uqewahunuk.sql
MMDL/SR/LLN/BV-12-C https://hastebin.com/ujonecefed.pl https://hastebin.com/adexujixak.sql
MMDL/SR/LLN/BV-13-C https://hastebin.com/ataxujakan.pl https://hastebin.com/nuxapejuqa.sql
MMDL/SR/LLN/BV-15-C https://hastebin.com/renomoyuho.shell https://hastebin.com/sajutajihe.sql
MMDL/SR/LLN/BV-16-C https://hastebin.com/okovagohum.shell https://hastebin.com/tajixacuko.sql
MMDL/SR/LLN/BV-17-C https://hastebin.com/jocafararo.pl https://hastebin.com/ehujafequk.sql
MMDL/SR/LCTL/BV-04-C https://hastebin.com/ququdetomo.pl https://hastebin.com/ufagubazim.sql
MMDL/SR/LCTL/BV-05-C https://hastebin.com/afebagasij.shell https://hastebin.com/ibecometax.sql
MMDL/SR/LCTL/BV-06-C https://hastebin.com/onaciyolaz.pl https://hastebin.com/rifamecayi.sql
MMDL/SR/LLNS/BI-01-C https://hastebin.com/ifunopegex.pl https://hastebin.com/zufosejuzo.sql
MMDL/SR/LCTLS/BI-01-C https://hastebin.com/icedihiyes.pl https://hastebin.com/aqobolezof.sql

@MariuszSkamra Thanks for latest logs.

[ ] MMDL/SR/GOO/BV-02-C https://hastebin.com/ahaderunij.cs https://hastebin.com/ositixurik.sql
[ ] MMDL/SR/GLV/BV-02-C https://hastebin.com/tatoqimuxo.shell https://hastebin.com/hunozuyuzu.sql
[ ] MMDL/SR/GLV/BV-03-C https://hastebin.com/iwutunozuh.shell https://hastebin.com/wofiwucumi.sql
[ ] MMDL/SR/GLV/BV-05-C https://hastebin.com/ikevitiduh.cs https://hastebin.com/ezaberujev.sql
[ ] MMDL/SR/GLV/BV-06-C https://hastebin.com/ramasiboya.cs https://hastebin.com/rejapigona.php
[ ] MMDL/SR/LLN/BV-06-C https://hastebin.com/imizuxepuz.pl https://hastebin.com/mediwoduga.sql
[ ] MMDL/SR/LLN/BV-07-C https://hastebin.com/yepigoyuta.pl https://hastebin.com/ajukokoqin.sql
[ ] MMDL/SR/LLN/BV-08-C https://hastebin.com/zilosayibe.pl https://hastebin.com/ocayekecul.sql
[ ] MMDL/SR/LLN/BV-09-C https://hastebin.com/ayubofabom.pl https://hastebin.com/nekedobewu.sql
[ ] MMDL/SR/LLN/BV-10-C https://hastebin.com/fequwelinu.pl https://hastebin.com/afomogiqox.sql
[ ] MMDL/SR/LLN/BV-11-C https://hastebin.com/teraratuda.pl https://hastebin.com/uqewahunuk.sql
[ ] MMDL/SR/LLN/BV-12-C https://hastebin.com/ujonecefed.pl https://hastebin.com/adexujixak.sql
[ ] MMDL/SR/LLN/BV-13-C https://hastebin.com/ataxujakan.pl https://hastebin.com/nuxapejuqa.sql
[ ] MMDL/SR/LLN/BV-15-C https://hastebin.com/renomoyuho.shell https://hastebin.com/sajutajihe.sql
[ ] MMDL/SR/LLN/BV-16-C https://hastebin.com/okovagohum.shell https://hastebin.com/tajixacuko.sql
[ ] MMDL/SR/LLN/BV-17-C https://hastebin.com/jocafararo.pl https://hastebin.com/ehujafequk.sql
[ ] MMDL/SR/LCTL/BV-04-C https://hastebin.com/ququdetomo.pl https://hastebin.com/ufagubazim.sql
[ ] MMDL/SR/LCTL/BV-05-C https://hastebin.com/afebagasij.shell https://hastebin.com/ibecometax.sql
[ ] MMDL/SR/LCTL/BV-06-C https://hastebin.com/onaciyolaz.pl https://hastebin.com/rifamecayi.sql
[ ] MMDL/SR/LLNS/BI-01-C https://hastebin.com/ifunopegex.pl https://hastebin.com/zufosejuzo.sql
[ ] MMDL/SR/LCTLS/BI-01-C https://hastebin.com/icedihiyes.pl https://hastebin.com/aqobolezof.sql

@jhedberg @MariuszSkamra
I've corrected issue with "marked" logs. For that I've moved
state->transition_start_timestamp = k_uptime_get(); from Server's message handler to Server's timer thread. Please review recent changes.
MMDL/SR/LLN/BV-06-C https://hastebin.com/mediwoduga.sql
MMDL/SR/LLN/BV-07-C https://hastebin.com/ajukokoqin.sql
MMDL/SR/LLN/BV-08-C https://hastebin.com/ocayekecul.sql
MMDL/SR/LLN/BV-09-C https://hastebin.com/nekedobewu.sql
MMDL/SR/LLN/BV-10-C https://hastebin.com/afomogiqox.sql
MMDL/SR/LLN/BV-11-C https://hastebin.com/uqewahunuk.sql
MMDL/SR/LLN/BV-12-C https://hastebin.com/adexujixak.sql
MMDL/SR/LLN/BV-13-C https://hastebin.com/nuxapejuqa.sql
MMDL/SR/LCTL/BV-04-C https://hastebin.com/ufagubazim.sql
I think these are exaggerated expectation becase ..
in case of MMDL/SR/LLN/BV-06-C...demands Light_Lightness_Linear status response &
in case of MMDL/SR/LLN/BV-07-C...demands Generic Level status response
after sending "Light Lightness Set".
I don't where this is explained in Mesh Model Specification.

@jhedberg
If possible as of now merge this PR after review. Now if execute PTS again, then it might return
9 issues which are regarding extra status responses + 2 which is due to unable to save Servers state on SoC flash.

@vikrant8051 yep, this PR has gone on for too long IMO. CI passes now, so I'll merge it. We can then sort out remaining issues in a new PR.

@jhedberg Thanks for merging it.
It will be great if we once again execute PTS against this App.
If we get only previously mentioned 9+2 issues, that will confirm current architecture is stable.


[Feature request] Support Match block ordering

From sshd_config(5):

If a keyword appears in multiple Match blocks that are satisified (sic), only the first instance of the keyword is applied.

1.1.2 has been released for this change.


[FunctionalTests] Make localization test more robust

This flag allows us to control the language instead of it getting picked
up from the system.

@swift-ci smoke test


[PIO-66] JIRA and release process for PredictionIO

https://issues.apache.org/jira/browse/PIO-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Hey, what do you think about putting Release Cadence under the Getting Involved section? We should probably clean up the Resources section because it sounds pretty generic.

I think adding a new section like "For Developers" is good for Release Cadence and other documentation for committers. Further, we should clean up the whole index in the left sidebar. Contents are good, but the index is not much kind. I think we can classify them more intelligible.
Anyway, we should do it on an another ticket. How about merging this addition as is and creating a new ticket about re-structuring the documentation?

Currently there isn't section to put documents for committers. It is better to clean up not only Resources section but also the others. It might be a good idea to do it in another task.

@shimamoto @takezoe Yes that sounds good. I'll merge this. Thanks!


Connection is closed per command execution for master node used as slave in readMode = MASTER_SLAVE

This issue leads to performance degradation for master node used as slave.

Fixed

Thanks.


merge: dev to stage

merge: dev to stage

:tada: This PR is included in version 1.8.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Natchez datadog

This adds an integration between Natchez and Datadog. It includes an OVO Specific quirk in that we pass around trace tokens as well as Datadog trace IDs because Datadog IDs must be numeric and none of our existing trace tokens are.
The gist is that the effect type we deal with now is a Kleisli[F, Span[F], A] rather than the old StateT and the Span[F] contains Refs to enable you to set/get tags and also provides functions to create subspans. All the span creation methods return a Resource[F, Span[F]] that on close submits the completed span to a queue which periodically gets sent to the Datadog agent

Have you seen https://github.com/Colisweb/scala-opentracing by any chance? I'm curious how it compares against Natchez...

I did only very briefly, this has been a self indulgent learning exercise 😄 - Natchez is at its core just a couple of type classes we implement here


Add test which reproduces an issue with nested async mappings

Thank you for PR

Hello, and how can I Fix this Issue? It's so powerful option to map like this.


maxDiscarded problem in 1.12.3

Hi all,
We just discovered that upgrading from 1.12.2 to 1.12.3 breaks one of our test that depends on the behavior of maxDiscarded:
it("ScalaCheck property that takes 6 args and generators, which fails, with default maxDiscarded set to 5") {

    // Hides the member
    implicit val generatorDrivenConfig = PropertyCheckConfig(maxDiscarded = 5)

    intercept[GeneratorDrivenPropertyCheckFailedException] {
      var i = 0
      val prop = forAll (famousLastWords, famousLastWords, famousLastWords, famousLastWords, famousLastWords, famousLastWords) { (a: String, b: String, c: String, d: String, e: String, f: String) =>
        i += 1
        (i > 6) ==> { 1 + 1 == (2) }
      }
      check(prop)
    }
  }

It is working correctly with 1.12.2, but not 1.12.3, we tried to look up for behavior change of maxDiscarded/discard in 1.12.3 release note but didn't get any, can we know what has changed in maxDiscarded/discard behavior from 1.12.2 -> 1.12.3?
Thanks in advanced for any help or pointer.

@cheeseng Can you go into some more details on how the behavior differs for you between 1.12.2 and 1.12.3? Would it be possible to demonstrate it in a ScalaCheck-only scenario? The maxDiscarded parameter is not part of ScalaCheck, for example. Only maxDiscardRatio.

Hi @rickynils , thanks for replying, actually we did check last week and found out that the reason behind the failed tests is that maxDiscardRatio will still at least try minSuccessful of time, even if the maxDiscardRatio thresold has been reached, so we modified our tests to adapt to the mentioned behaviour and they're cool now.  :)
Sorry for making the noise, I'll close this issue.


Changing the badge style for README.rst

These badges looks better than the regular ones.

This needs some discussion and approval.

Current ones look good for me, is what we use in all of our repos

@stsewd
I think this can be closed then.
This was just a suggestion and is not of any priority.


Google Service Account credentials | --service-account-file returns error message

Hi there,
I've ran $ drive init --service-account-file client_secret.json ~/gdrive and it returns the message google: read JWT from JSON credentials: 'type' field is "" (expected "service_account")
Click here to see my client_secret.json I have downloaded from Google API Console. Yes, I made sure Drive API is enabled.
The credentials.json is created into ~/gdrive/.gd Click here to see how it looks like.

I have figured it out. I was getting the wrong json file.
I should have gotten the json from https://console.developers.google.com/iam-admin ( click on the Service Account menu option ).

thanks @drupalista-br. this really helped me out in using gdrive! also, I'm betting this drive CLI as well (looks pretty slick)


Upgrade to latest Rust

Replaced closure callback with normal function (See
https://github.com/andelf/rust-sdl2_mixer/issues/19)

Got problems opening files.

:smile:


_ready method is not subject to the inheritance rules like other user methods

Godot version:
v3.2.2.rc.custom_build.36a30f681
OS/device including version:
Windows 10
Issue description:
The _ready method (and other similar methods like _process) is called for both the base class and derived class despite it is not explicitly called in the derived class. This surprised me a bit.
This prevents overwriting the implementation of the base class.
Shouldn't the base class method be called explicitly in derived class? Like this:
func _ready():
	._ready()

_ready() is not a "user method" though, it's inherited from a built-in class. Methods like _ready(), _process() or _input() etc. are called in the whole inheritance tree automatically. AFAIK there are plans for a GDScript rework that gets rid of this behavior, but it won't happen until Godot 4.0/4.1 (because compatibility)

Duplicate of #29271.


Bump version for aeson release

Commit https://github.com/freckle/hspec-expectations-json/commit/4f4fcb212b6acc936654eec3a0be3105a0ad5a9b was accidentally
pushed to main, but did not contain version bump. This commit sends
that version live.

closes https://github.com/freckle/hspec-expectations-json/issues/10

Hmm, looks like there are some build issues in CI with hlint.

Oh, interesting.
So one (negative) result of installing/running hlint/weeder as part of stack-action is that it requires the same dependencies as your project. That's why you have this error.
Moving to distinct actions (see the TTS workflow in megarepo) actually does a nice job avoiding this (modulo Weeder and it's compilation-artifact dependency); so I consider this more evidence that it's better to do it that way.
I would migrate this project to a workflow like that as the fix here.


Support encapsulated tasks

Despite allowed by the type definition, it seems like I just didn't implement (and test) support for encapsulated tasks at all?

Would be nice to see this - are there any plans for it?


delRead callback function is not called

Hello! I can't find where this callback function is called. Can you provide some info?

Hi,
It looks like this depends on what event library you're using, and at as far as I can tell it isn't always being called for all of them.
I don't use the async functionality a great deal so I'm not sure if this is a bug or intended (perhaps it's not required for every library).
Which async adapter are you using?

I think that it doesn't depend on which event loop is used. The whole idea of a callback function is that it is set up by user of the library, but invoked by the library itself at specified condition or point in time. Actually, similar delWrite() function is used (called) by the library, so I wonder where delRead() might be used as well.
The whole story is that I've implemented an asynchronous event loop using Boost.ASIO and provided all necessary callbacks, but during debug session I've encountered error that delRead() callback is not being called, so it continues to read from socket when the redisAsyncContext has been disconnected and even freed by the library by redisAsyncDisconnect() function.
Either I don't understand something or this is actually a weird situation with delRead not being called.

The whole idea of a callback function is that it is set up by user of the library, but invoked by the library itself

Sure, I just mean that I instrumented example adapters to watch when delRead was invoked but the behavior varied for each adapter.
For example for libuv we call delRead explicitly during cleanup which appears to manually stop the read event.
In any case, every time I did see it invoked it happens in __redisAsyncDisconnect, specifically in the _EL_CLEANUP macro but I suspect you know this already.  😅
Are either of these projects useful to show how to handle this in ASIO?
https://github.com/ryangraham/hiredis-boostasio-adapter
https://github.com/basiliscos/cpp-bredis/tree/master/include/bredis

Thanks for the detailed reply!
It seems that I simply don't understand the purpose of these callback functions. I thought that they are called only once a disconnect or an error occurs. But after some short study of the examples I see now that they are possibly called to control the events on socket whether one should be monitored at given time or not.
Maybe it is even possible to ignore them for Boost.ASIO completely as this library enqueues each event listening request separately, and if, for example, hiredis library doesn't have any pending commands then it issues delWrite.

Going to close this issue because I don't think it's a bug in hiredis.
Good luck with your adapter though!


Minimum amount of votes

renamed votes_amount to max_votes_amount
@tsiegleauq The client has to be adopted. I added both min_votes_amount and max_votes_amount and adjusted basic places. But the validation is missing in two places: In the poll form, max_votes_amount must be greater or equal than min_votes_amount (some custom validation). While voting, the check, if at least min_votes_amount votes were selected is missing.

rebased quite heavily, fixed typos, still a lot of bugs.

Ok, whats the state here? I see the python tests are failing - I'll have a look. Is the client ready?

Ok, whats the state here? I see the python tests are failing - I'll have a look. Is the client ready?

Ok, whats the state here? I see the python tests are failing - I'll have a look. Is the client ready?

same as above. WIP, client is not done, server tests are failing, prolly due to new features.

Ok, whats the state here? I see the python tests are failing - I'll have a look. Is the client ready?

same as above. WIP, client is not done, server tests are failing, prolly due to new features.

The server should be fixed now. Attention: I rebased on master again.

The server should be fixed now. Attention: I rebased on master again.

@emanuelschuetze @FinnStutzenstein can be tested

@emanuelschuetze @FinnStutzenstein can be tested


Linking css to local html

Hi,
How do I load css and js files when I generate the html in code
// Start lorca; this opens Chrome with a blank page.
ui, err := lorca.New("", "", 1280, 720)

// Do something, like binding your go code to js.
// ...

// Finally load your HTML file, which will have access to the previous bindings.
myFileContents := // read your file here somehow & modify it incode

// Make your file contents loadable as html
loadableContents := "data:text/html," + url.PathEscape(myFileContents)

// Load your HTML file in Chrome; this replaces the blank page with your page.
err := ui.Load(loadableContents)

I tried the following with no success
     link(href='./main.css' rel='stylesheet')
     link(href='main.css' rel='stylesheet')
     link(href='/main.css' rel='stylesheet')

I got it, you need to specify the url and port in the link function. This means you need to parse this in the html code as the port number is not the same at each run time:
urlAddr := fmt.Sprintf("http://%s", ln.Addr())
html = strings.Replace("<link href="__CSS__/main.css" rel="stylesheet">", "__CSS__", urlAddr , 1)


Problems with MARATHON_APP_LABELS and Docker-Containers

Hi,
adding labels to Marathon makes deployment fail. For example I add image_name and tag_name as labels.
Marathon generates a list and adds it to the environment variable:
--env="MARATHON_APP_LABELS=IMAGE_NAME IMAGE_TAG"
The error I got starting the container is
Error: Could not find or load main class IMAGE_TAG
I can see in the run-cmd of docker: --env="MARATHON_APP_LABEL_IMAGE_TAG=latest"
If I only use one label, it works
Thanks in advance
Marathon 0.14 on Centos7 with Mesos 0.26 and docker 1.9.1

not a marathon bug, error was on the image side of docker


Antrea no longer works with Kind after upgrading to Docker Desktop 4.27.0

Describe the bug
After upgrading to Docker Desktop 4.27.0 (the latest version as the time of writing this), Antrea will no longer install successfully on a Kind cluster. The install-cni container will fail with:
modprobe: FATAL: Module openvswitch not found in directory /lib/modules/6.6.12-linuxkit
Failed to load the OVS kernel module from the container, try running 'modprobe openvswitch' on your Nodes

To Reproduce
Download and install Docker Desktop 4.27.0: https://docs.docker.com/desktop/release-notes/#4270
Install Antrea with helm install -n kube-system antrea antrea/antrea
Look at Pods with kubectl get pods -A
Expected
Antrea should install successfully
Actual behavior
Antrea Agent Pods cannot be created.
Versions:
Tested with Antrea v1.15.0 and v1.14.2, but this is independent of the Antrea version (specific to the Docker Desktop version).
Additional context
There were some major changes to Docker Desktop (and more precisely the LinuxKit VM) in 4.26 and 4.27.
The 2 breaking changes in our case were introduced in 4.27.0:

The openvswitch kernel module is now built-in and no longer a "loadable" module.

see https://github.com/docker/for-mac/issues/7151
this is very similar to the behavior observed when using Docker Desktop with Talos Linux: https://github.com/antrea-io/antrea/issues/5707
the best workaround at the moment is to install Antrea with agent.dontLoadKernelModules=true, but we should probably "fix" our default behavior. The default behavior should probably be to check if openvswitch is "builtin" (by looking at the contents of /lib/modules/$(uname -r)/modules.builtin), and if it is, skip running any modprobe command.

The Kernel configuration was changed, and in particular support for conntrack zones was disabled

see https://github.com/docker/for-mac/issues/7148
because this impacts other projects, such as Istio, I expect that this will be fully reverted soon

Hi @antoninbas, Docker Desktop maintainer typing here! We're so sorry for breaking your workflow.
We've indeed recently made big changes to Docker Desktop's kernel config in order to make it smaller/faster. Sorry that this has a negative impact on you.

Support for conntrack zones will be back soon. As soon as 4.27.1 if we manage to make it part of the hot fix in preparation. Otherwise, it'll for sure be part of 4.28.
openvswitch module will probably stay as it is, as a static module. That's how we hope to install all the kernel modules in the future. Do you think it's possible to change your check to recognise such setup?

@dgageot Thanks for the quick reply.
I also commented at https://github.com/docker/for-mac/issues/7151#issuecomment-1917800592.
Yes, we will enhance our implementation to handle that case and skip calling modprobe when the module is already built into the kernel.

Small update: the conntrack kernel configuration should be fixed in 4.27.2. When that is released (later this month?), we can implement "auto-detection of built-in kernel modules" in the Antrea Agent (for openvswitch) and validate that we can run with Docker Desktop 4.27.2.


current location not showing after searching a city and going back to home page

Ruihang had patched that. Changes will reflect on the next PR.

PR made

Merged


Cannot draw graph with nvd3. Uncaught TypeError: ue.watchTransition is not a function

Make sure these boxes are checked before submitting your issue - thank you!

[Y] I have checked the superset logs for python stacktraces and included it here as text if any
[Y] I have reproduced the issue with at least the latest released version of superset
[Y] I have checked the issue tracker for the same issue and I haven't found one similar

Superset version
Any version on my machine includes airbnb_prod.<IP_ADDRESS>
Expected results
After loading examples, in Slices tab, superset should display any example slice like birth_names normally.
Actual results
Cannot display any graph drawn by nvd3
Steps to reproduce
superset load_examples
superset runserver
login, click slices tab, click birth_names
Below is my stack trace on browser:
Uncaught TypeError: ue.watchTransition is not a function     at SVGGElement.<anonymous> (explorev<IP_ADDRESS>rc2.entry.js:90)     at explorev<IP_ADDRESS>rc2.entry.js:102     at $ (explorev<IP_ADDRESS>rc2.entry.js:100)     at Array.La.each (explorev<IP_ADDRESS>rc2.entry.js:102)     at Array.o (explorev<IP_ADDRESS>rc2.entry.js:90)     at Array.La.call (explorev<IP_ADDRESS>rc2.entry.js:102)     at SVGGElement.<anonymous> (explorev<IP_ADDRESS>rc2.entry.js:87)     at explorev<IP_ADDRESS>rc2.entry.js:102     at $ (explorev<IP_ADDRESS>rc2.entry.js:100)     at Array.La.each (explorev<IP_ADDRESS>rc2.entry.js:102)
I found the exception was thrown by line 381 of nvd3_vis.js airbnb_prod.<IP_ADDRESS>. But I can't fix it.
Below is info of my machine:
macos 10.12.1
chrome 56.0.2924.87 (64-bit) The bug happens on any browser of my machine.
d3 3.5.17
nvd3 1.8.5
It also happened on other graph, I created using nvd3 like pie chart etc.

Possibly this has been fixed in a later version?

Using pip install -r requirements.txt instead of python setup.py install, The error never happened.


bundling the package for production issue

I noticed that when I bundled the package the toast.js file was empty that was included in the npm module. So I created a placeholder file and replaced it, now it bundles properly and exports the Toast class.
It would appear that something is wrong with the build process of the module because when I cloned the repo and built it for myself, the toast.js file was still empty.
Here is what I used to replace the contents of toast.js:
"use strict";
var bodyOutputType_1 = require('./bodyOutputType');
var toaster_config_1 = require('./toaster-config');
var Toast = (function () {
    function Toast() {
    }
    return Toast;
}());
exports.Toast = Toast;
//# sourceMappingURL=toast.js.map

Correct, it would be empty.
toast.ts is simply an interface declaration for strong typing when building the source.  There is no concrete object and there is no Toast class, which is why the toast.d.ts file shows the necessary typing information and the toast.js declaration is empty.  However, by providing the file and the source map, the underlying typed source is still available for debugging if needed.
Is this currently causing a problem in your build process?

That makes sense for typescript typing.
It would build without issue however when the bundle was loaded it threw an error stating that Toast was undefined. When I supplied the empty class to be exported it ran fine with the production bundle.

Can you please provide an example of your build process and how you are consuming the end result?  The file is fully accessible.  This seems to be bundler-centric.

We are experiencing the same issue with our build as well. The build process is running fine but the final bundle.js throws an error "Uncaught TypeError: Cannot read property 'Toast' of undefined".
We are using gulp to build and bundle our project, which reads off systemjs.config.js.
Has something changed recently? We didn't have this kind of problem before.

@ruiwanguk not that I am aware of.  The angular2-toaster.js root file has always exported the Toast interface from the ./lib/toast file.  Can you please provide a stack trace of where it is throwing the error?  That might be useful.

@Stabzs , when we load our webapp, there is no stack track as such. Only the error message "Uncaught TypeError: Cannot read property 'Toast' of undefined, angular2-toaster.js:2"

@Stabzs, btw, we are using version 1.0.0

@ruiwanguk  does the issue persist in 1.0.1?  In addition, are you able to provide a small sample gulp config of how you are bundling just the library source?

@Stabzs  Does this help?
`
var SystemBuilder = require('systemjs-builder');
var argv = require('yargs').argv;
var builder = new SystemBuilder();
builder.loadConfig('systemjs.config.js')
.then(function () {
var outputFile = argv.prod ? 'dist/bundle.min.js' : 'dist/bundle.js';
return builder.buildStatic('src', outputFile, {
minify: argv.prod,
mangle: argv.prod,
sourceMaps: !argv.prod,
sourceMapContents: !argv.prod,
rollup: argv.prod
});
})
.then(function () {
console.log('Bundle successfully built');
});
`

@ruiwanguk I'll let you know.  Thank you!

@ruiwanguk does something like https://github.com/jspm/jspm-cli/issues/1127 address your issue?  If not, it seems like it may be prudent to remove the Toast export from angular2-toaster.js altogether so that it will be available via interface if being source-mapped, but not in the publicly exported library.

@markhatchell are you using SystemJS as well for your module-loading?  And how are you bundling it?


.Net Version 8.0

Type of issue
Missing information
Description
Please mention dotnet version 8.0 is in supported distribution or unsupported distribution
Page URL
https://learn.microsoft.com/en-us/dotnet/core/install/linux-centos
Content source URL
https://github.com/dotnet/docs/blob/main/docs/core/install/linux-centos.md
Document Version Independent Id
26300783-8df5-56a1-4ab6-4b8511e37f51
Article author
@adegeo
Metadata

ID: 577ce9b2-5b48-4ed2-c309-a78880015dd2
Service: dotnet-fundamentals
Sub-service: install

CentOS support from Red Hat ends this month, forever. So we'll be removing this page in a week or so. Because of that, .NET 8 wasn't released for CentOS. You'll have to upgrade to CentOS Stream, or manually install .NET 8 and try to get it to work, but without support, sorry.


feat: Maintain a global configuration instance

I suggest using get_global instead of get_global_configuration. Since the method serves as constructor for the Configuration class - including "configuration" in the method name seems redundant. Leaving it up to you.

I was ready to tell you that it's named that way because of JS crawlee, but there it's called getGlobalConfig. I'm lost :smile:


#22368 Fix identifiers case sensivity in semantical validation

ONE PR FOR TWO ISSUES #22368 #22385
For QA
Please check case sensitivity for identifiers (including quoted identifiers) in various databases (DB2, Snowflake, SQL Server, PostgreSQL, SQLite, MySQL, Oracle, Clickhouse)

Now correct column names in quotes are highlighted as incorrect
https://github.com/dbeaver/dbeaver/assets/82543000/e9dafb6d-fd9d-43c6-bf0d-9ce405ed618a

Verified


Make the "Select environment" prompt when launching a debugger clearer

If you press F5 in a project with no active file, you're prompted to select a debugger like this:

This dialog is quite confusing to Dart/Flutter developers, because when they want to run a Flutter app in Chrome, they must not select Chrome at the top, but rather Dart&Flutter. If they do select Chrome, it creates a launch.json that has "type": "pwa-chrome" which means they are not prompted at all the next time they press F5, the launch just doesn't do what they'd expect. They need to know to manually go and delete the launch.json to resolve the issue.
This has come up a few times:

https://github.com/Dart-Code/Dart-Code/issues/2911#issuecomment-719151009
https://github.com/Dart-Code/Dart-Code/issues/2911#issuecomment-1083392091

I think there are some tweaks that would make this clearer and avoid the confusion:

Don't call this "environment", since that's easily confused with the environment in which you want to run the app. Saying "Select debugger" would be clearer
Use some heuristics to sort the entries.. If the Dart/Flutter extensions are activated it's almost certain that Chrome is the wrong option
Don't create a launch.json by default for pwa-chrome. There are entries on the Debug side bar for creating launch.json, one with default values is pointless and makes it harder to recover from a mistake like this

I will switch to "Select Debugger" right now if no objection from @weinand or @connor4312
Not sure how this would work, and I don't want to hardcode anything for these extensions in particular
Sorry, not sure what you mean for this point. You mean the "Chrome" entry shouldn't show up?

Perhaps this could be influenced by languages? VS code already knows to use the Dart debugger if the active file is Dart, so perhaps it could infer that if a project is 90% Dart (or 90% Python) that it could "suggest" the Dart/Python/whatever extension at the top as a "Suggested debugger"?

I mean selecting the Chrome entry should not create a launch.json unnecessarily. It can be created by the user from the debug side bar if they need to customise it. A lot of debuggers just run without the file altogether now (like Dart). The issue with creating it here is that it forces every subsequent Run/Debug to go through that path, so if the user accidentally picks Chrome (as has happened to at least a few Dart users), it changes future behaviour to do the wrong thing unless they understand exactly what happened here (which is, their bad selection wrote a file that causes that same selection to be made automatically next time).

@isidorn what do you think about my proposal from above?

@weinand I like the push towards reducing the wrong automatic creation of launch.json. Since having a wrong launch.json can put the user in a very hard spot. Also it will be more consistent with the other flow. Auto creation of launch.json was the first step we did before dynamic providing of launch configurations, and now this feels like debt behaviour to me.
While I like your idea to count files and rank debuggers, I am not sure if that would help here. Since both Chrome and Dart are probably interested in same files, so they would most likely be ranked the same. Thus you would still have to ask the user. Or am I missing something?

Since both Chrome and Dart are probably interested in same files, so they would most likely be ranked the same

This probably isn't the case. Flutter projects will likely only have one (or a very small number) of .html files (and probably no .js), and be mostly .dart files.
If there are more .html/.js files in a workspace than .dart, then ranking the Chrome debugger above wouldn't be unreasonable to me (although, whether it should be automatically picked rather than just "suggested" at the top of the list, I'm less certain).
That said - it's possible after running the Flutter: New Project command you'll end up with exactly one .dart file, and exactly one .html file from the default template, so in some cases at least, it might not be a clear winner. For most non-skeleton projects, it's likely there will be more .dart files added (and no additional .html files) though.

@isidorn in order to verify that my proposal actually works, I did an experiment:

I determined the set of "supported languages" for the Dart and Chrome/Edge debuggers:

Dart: "dart"
Chrome/Edge: "javascript", "typescript", "javascriptreact", "typescriptreact", "html", "css", "coffeescript", "handlebars", "vue"

then I connected VS Code to a Dart docker image and created a "Dart Web app".
I found one dart file, one html file, and one css file.

So you are right: Chrome debug would win with 3:1!
However....

As the issue #146956 is closed, allow me to mention our request to this thread:
In C/C++ extension we have two debuggers that we can't combine them into one debugger.
When there are few debuggers from other extensions, it makes sense to ask for "Select environment", but is it possible to not to select the environment when the debuggers are from the same extension?
in other words, Is it possible to skip the step of selecting the debugger type and instead provide a list of configurations across all debugger types in the extension? c.c. @jureid

@elahehrashedi with the strategy sketched above you could contribute languages only for one of your debuggers. This should result in skipping the "select step" (at least if no other C++ debuggers exist in other extensions).

@weinand yesterday I discussed with C++ and I believe your proposal would not solve their problem. Because they want to contribute languages by all their debuggers and can not use when clauses to disable some of the debuggers.
For example on Windows they really want to show the results of all three debuggers combined - and that is what their play button does. There they have full control since it is their action.
I am not sure if there is a good way to solve this for C++. Merging results from multiple debuggers just because they come from the same extension sounds like a workaround.

@elahehrashedi Is there something like a "main" C++ debugger that is always there and contributes the single "smart" play button that can delegate to the other C++ debuggers?
If the answer is "yes" then only this debugger needs to contribute "languages" (and then there will be no selection dialog).
If the answer is "no" and all C++ debuggers contribute the same "languages" then you are creating exactly the problem that requires the selection dialog: the same files can be debugged by different C++ debuggers and users will have to pick the debugger they want.

fyi @bobbrow

I agree, that the second part (the "I like this") is a good first step.
But that does not really solve the first problem: many debug extension authors don't like the first part: the "debugger selector". The real "problem" here is that VS Code has one built-in debugger and that always gets into the way when users just want to debug something that is not JS or TS. Python users doesn't care about JS or TS and if they have created a new Python project and press F5 they just want to debug Python.
How can we avoid the debugger selector in this case?
My proposal tries to eliminate the debugger selector with a heuristics based on the existing static "language" contribution. If it cannot decide what debugger to use it will fall back to the current debugger selector.
Delegating the decision what debugger to use back to some pieces of code running in the installed debugger extensions has the problem that too many extension are activated (which will be slow).
Do you have a better idea how to tackle this?
Here my suggested heuristics come into play.
The problem with the second part (the "I like this") is that we have a built-in debugger ("js-debug") that

@elahehrashedi Is there something like a "main" C++ debugger that is always there and contributes the single "smart" play button that can delegate to the other C++ debuggers?

There is no "main" debugger.  I believe @wardengnaw commented on another issue (I forget which) that bundling the different debug types into a single debugger entry makes it difficult for the debugger team to organize their code.

If the answer is "no" and all C++ debuggers contribute the same "languages" then you are creating exactly the problem that requires the selection dialog: the same files can be debugged by different C++ debuggers and users will have to pick the debugger they want.

We just want to provide all the launch configurations all the time.  If the debuggers we register in package.json could be part of a "group" (new concept) and then we provide all the configurations for that group, I think we could get the behavior we want.  The only thing selecting an environment does for C++ right now is filter our results.  When users click our "play" button, they see all the possibilities at once.  I still think it would be nice if we could bypass the "select environment" prompt altogether, but that might be slightly different from what this issue is asking for and I don't mean for us to hijack the discussion.  Should we open a separate issue for what C++ needs?  (potentially 2 if the debugger "group" idea has merit in your opinion)

The real "problem" here is that VS Code has one built-in debugger and that always gets into the way when users just want to debug something that is not JS or TS.

I don't think it's only the built-in debuggers either. I think debuggers that contribute onDebugDynamicConfigurations are activated when you press F5, so the list could includes additional debuggers from extensions that weren't even activated before then?

@bobbrow sorry that the term "main debugger" was unclear. I was not suggesting to bundle the different debug types into a single debugger entry.
What I meant was: is there one C++ debugger that is available on every platform, e.g. if debugger A and B are used on Windows, and A and C are used on linux, then "A" is the debugger used on both (intersection).
Then the "A" debugger could contribute all the launch configurations and "languages" contributions and the smart "Play" button.

You said:

I still think it would be nice if we could bypass the "select environment" prompt

That's exactly what we are discussing here.
Today we need the "select environment" prompt iff..

there is more than one debugger installed and enabled,
there is no "launch.json", and
no file is open in the editor.

In this case VS Code does not know what debugger to use, so the "select environment" prompt is needed.
Even if we would group the C++ debuggers into one, then we would still have VS Code's builtin JS debugger and would still need the "select environment" prompt.
The C++ extension cannot just "bypass" the "select environment" prompt because that would be unfair to all Non-C++ other debuggers: users would not given a chance to pick the JS or Python debuggers.
Above I've proposed a heuristic to automatically pick a debugger for a given project by matching some project files against file types listed in the "languages" contribution of the debuggers.
But @roblourens pointed out (correctly so) that this introduces some randomness and in-transparency into the behavior of "F5" debugging.
An alternative would be to let the user use the "select environment" prompt only once per folder/project and then remember the answer.
The drawback with this approach is that new users have to answer another question before they can debug...

@DanTup
yes, your observation about dynamic launch configs is probably right and we should address this too...

@weinand  We don't necessarily need to bypass the "select environment" prompt when other debuggers are available. But we would like to group C++ ones together as a single entry in the list.

@elahehrashedi There is always at least one "other debugger" available (js-debug). So the "select environment" prompt will always be there.
"Grouping C++ debuggers" together as a single entry does not make any sense for VS Code. VS Code needs to know which debugger needs to be activated in order to send requests to it. A "group" doesn't help at all.
If there is a "group entry" for all C++ debuggers, should we activate all of them and then send the requests to all of them and sort out or merge what they return? That's not a business VS Code wants to be part of.
If you need this behavior you can introduce a single "umbrella debugger" that delegates to the individual debuggers.
VS Code has used this approach when we introduced a new JS debugger for newer version of node.js: the original debugger was delegating requests to the new version whenever it detected that the new version of node.js was used.

@weinand let's explore the "umbrella debugger" idea. Here are the two debggers in package.json:
"debuggers": [
      {
        "type": "cppdbg",
        "label": "C++ (GDB/LLDB)",
        "languages": [
          "c",
          "cpp",
          "cuda-cpp"
        ],
        // some different args
      },
      {
        "type": "cppvsdbg",
        "label": "C++ (Windows)",
        "when": "workspacePlatform == windows",
        "languages": [
          "c",
          "cpp",
          "cuda-cpp"
        ],
        // some different args
      }
]

Let's say we define the "umbrella debugger" like below:
     {
        "type": "all",
        "label": "C++",
        "when": "workspacePlatform == windows" ,
        "languages": [
          "c",
          "cpp",
          "cuda-cpp"
        ]
      },

I can design this debugger to provide all debug configurations that we need.

However, doing so will create a new debug type all that is not meant to be used by users in their launch.json.
Also, in order to hide the two cppvsdbg and cppdbg debuggers, from the menu 1, I will need to change the "when" clause to "when": "never" for the other two debuggers, to have the menu 2 that we want:

menu 1

menu 2

However, doing this change will result in an error in launch.json, as the other two types are not valid anymore:

Kindly, how did you resolve this issue?
C.C. @isidorn

@elahehrashedi the "umbrella" debugger type must be the type that users see and use in their launch configs. So that will define the "cppdbg" type. The individual sub-debuggers will use private debug types that users should not see or use. The resolveDebugConfiguration hook of the umbrella will rewrite the type to the desired sub-type.

A new ("non-magic") proposal that avoids unintended creation of a launch.json and shows the "select environment" prompt only once:
Given the following situation:

VS Code is in "folder" mode
more than one debugger installed and enabled,
no ".vscode/launch.json" exists,
no file is open in the editor

pressing "F5" (or running the "Start Debugging" command) results in this behavior:

if no debugger is remembered for the workspace folder a "select debugger" prompt is shown. This prompt is the old "select environment" Quickpick but with improved wording: "select environment" -> "select debugger". In addition the Quickpick has a gear icon that allows to create a "launch.json" for the selected debugger.
after user has selected a debugger, this debugger is remembered for the workspace folder and future "select debugger" prompts are not needed
VS Code activates the selected debugger and passes an empty launch config to the "resolveDebugConfiguration" method. This is the same behavior as for the "file is open in editor" case: the debug extension needs to figure out what file or project to debug.

@weinand I think this problem still has the original issue that led me to raise this, but makes it even more difficult to fix:

New user creates a Flutter project and wants to run it on the web
User presses F5 and is prompted to select a debugger - incorrectly picks "Chrome" and gets an error
User presses F5 again and VS Code auto-picks the wrong debugger again

As things are today, the user needs to know the launch.json file that was created is causing the problem. With the new proposal, it seems like the remembered selection is now even less visible than the launch.json (if at all). How would the user discover the issue and fix it so they can then select the Dart&Flutter debugger?

I've changed "environment" to "debugger"
I'd said that this menu shouldn't create a launch.json for Chrome, but we do that because it's not really possible to figure out what the user wants to debug in Chrome without having them configure their launch.json. We discussed asking more questions after the user picks chrome - we can have them enter the server URL or show another set of options which will generate different configs. Python does something like this. And if a Dart user accidentally picks Chrome, that might give them a hint that they are headed the wrong direction. I would also consider renaming it to something like "Web App (Chrome)" but wouldn't use PWA there. That would incidentally sort it to the bottom in alpha order
We can sort the debuggers based on whether the extensions are activated, like you suggested, but that only works the first time since js-debug will get activated by onDebugInitialConfigurations. Then it can also be based on which debuggers have been used.

We discussed searching the workspace for files by language, and I'm not a fan of that, but maybe we could allow debuggers to list something like their workspaceContains patterns for specific patterns, and when matched, that debugger is sorted to the top. The problem is that these patterns can trigger really expensive searches, so it might be limited to static patterns only, or no **

@DanTup do you think that this mainly happens to confused users on their first try, or do users successfully use the Dart debugger then at some point accidentally pick Chrome instead?
Do you recommend users not create a launch.json, or would you want to include one in the default setup so projects will always have a working configuration?

Sent a PR to sort debug extensions that were already activated to the top. And the result is cached before the first debugger activation so it should hopefully just pick up extensions that got activated by workspaceContains or other actions.

We discussed asking more questions after the user picks chrome - we can have them enter the server URL or show another set of options which will generate different configs. Python does something like this. And if a Dart user accidentally picks Chrome, that might give them a hint that they are headed the wrong direction.

That sounds good. If you need that info from the user anyway, I think prompting for it is a better experience than making them go and add it to launch.json (this is what Dart does for Attach, we use an input box to ask for the VM Service URI so it can just be pasted in and we still don't need to create a launch.json - although we do support it there too). It also gives people an opportunity to "cancel" if they realise it's wrong, without it leaving a permanent launch.json to confuse things further next time.

I would also consider renaming it to something like "Web App (Chrome)" but wouldn't use PWA there. That would incidentally sort it to the bottom in alpha order

That would also be good IMO (I used PWA as an example as that's what's in the ID, but anything more explicit would probably help).

We can sort the debuggers based on whether the extensions are activated

That sounds good too. Yes it'll only help the first time, but I suspect the number of times people press F5 without a Dart file open is probably heavily skewed towards the first run. Once they open a Dart file (as they eventually probably will), they won't see the prompt.

The problem is that these patterns can trigger really expensive searches, so it might be limited to static patterns only, or no **

That could help too. It's not uncommon for projects to be nested in Dart, but I suspect people with multiple/nested projects are probably not encountering this for the first time, so probably more likely to make the correct selection. It's likely peoples first experience where the most confusion is.

Sent a PR to sort debug extensions that were already activated to the top. And the result is cached before the first debugger activation so it should hopefully just pick up extensions that got activated by workspaceContains or other actions.

Do you mean that even after other extensions are activated, the earliest one would still be sorted to the top? If so, that sounds great :-)
Out of interest, what causes the "suggested" label in your screenshot? Is it just the top one, or does it only appear after that item has been previously selected?
Thanks!

Filed https://github.com/microsoft/vscode-js-debug/issues/1270 to talk about the first part.
Sent https://github.com/microsoft/vscode-js-debug/pull/1271 to rename the Chrome/Edge DAs.
To explain my change some more - yes, even after other extensions are activated, the ones that were activated before the first debug session still go to the top. The "Suggested" section is these debuggers from extensions that were activated before the first debug session. The next section is everything else. Here's what it will look like in a Dart project.

Something sort of related about this experience that still bugs me, but I am not sure what to do about, so I will just put notes here for now:
The provided "initial" launch configs go under the Run and Debug button, and the "dynamic" configs go under the link text, "Show all automatic debug configurations":

The dynamic configs are like this:

When the user runs a dynamic config, e.g. I pick Node.js > Javascript Debug Terminal, you switch into this UI mode

The blue button is gone, you only have dynamic configs and "Add configuration" so it looks very different from what you had before.

And, the selected dynamic config is remembered for this workspace. After reloading the window, if I press Run and Debug, it runs the last selected dynamic config and I can't see the initial configs that I would have seen before. This might make a user feel stuck. The only way to get unstuck is to use the "Add configuration" button in the dropdown and create a launch.json, but this will be a different workflow than what they had before.
I need to do more research to understand the history but here are some things to investigate that might help make this flow more consistent:

The docs and vscode.d.ts don't quite explain the "initial" launch configs correctly, they imply they are only used for generating a new launch.json. I'm sure it used to work that way but not the dynamic and initial configs seem more similar.
Why remember the selected dynamic launch config, but not the selected initial launch config? Remember both or neither.
When there is no launch.json, and a dynamic launch config has taken over the Run and Debug button, we should show the dropdown so a user can still pick a different config, and this dropdown should also show the initial config options. With this, we can get the behavior of remembering the last F5, but they can also change the selected debugger.

Yeah, I've been caught out by those dynamic entries appearing in the Debug side bar dropdown too. I spent some time trying to find a launch.json that has an unexpected named debug session before I realised where it had come from. It would be nice if the view was more consistent before/after running the first session, and it was clearer in that drop-down what the source of the configurations were.

@roblourens these are cool improvements 👏
For the history behind those decisions feel free to schedule a sync with me. I will be happy to try to help :)

Closing this for this month's improvements - can continue in https://github.com/microsoft/vscode/issues/150663


PlugDiff shows incorrect msg

Explain the problem here ...

After commit 05c898, PlugDiff shows incrrect msg on Windows gvim.
Would you please check it? Thanks!

Type:

[x] Bug
[ ] Enhancement
[ ] Feature Request
[ ] Question

OS:

[ ] All/Other
[ ] Linux
[ ] OS X
[x] Windows

Vim:

[ ] Terminal Vim
[x] GVim
[ ] Neovim

@janlazo Can you look into this? Thanks.

My bad. I noticed that but forgot to handle it. The command is run inside the batchfile so the parser thinks that the passed string for --pretty contains variables.
hdscr came from "%x01%h%x01%d%x01%s%x01%cr"

@winsphinx Can you upgrade vim-plug and see if it's fixed now?

Thanks. It is fixed ..but partly.
2 unnecessary quote was added. one is before commit ID, the other is after time. See below.

Hmm yeah, I can reproduce it even on my macbook.

Can you test again?

Yes, it works perfect.
Thanks all!


DOCK-2468: Improve error message when .dockstore.yml contains a scalar where a list is expected

Description
This PR improves the error message that appears in the GitHub App logs when a single string is supplied to a .dockstore.yml property that requires a list.  Previously, the message was:
No single argument constructor found for interface java.util.List

This PR changes it to something intelligible.
Before deciding on the above solution, I tried to make the parser accept a string where a list was expected, but after a number of hours, stopped.  I can't eliminate the possibility that we could somehow inject some code into SnakeYaml to make it happen, but there's no obvious public hooks, and it appears that we'd be fiddling with its innards to a degree that, IMHO, the danger would outweigh the benefits.  Similarly, we could parse to an intermediate YAML node representation, modify the appropriate scalar property settings to lists, convert back to YAML, then parse as we currently do, but we'd risk mangling our line number information and introducing other issues.  We could do something similar by preprocessing with regexps, similar risks.
This PR is a minimally-invasive solution that probably makes the situation good enough.  There are other ways to make SnakeYaml throw exceptions containing inscrutable messages, but they happen with low enough frequency that it's probably not worth addressing at this point.  If we wanted to make those better, a PR to SnakeYaml might be the most efficient approach.  Or, parsing to an intermediate YAML node representation, then using our own code to build the objects, would give us more control.
Review Instructions
Push a .dockstore.yml that sets a property to a single string value, instead of the expected list.  Wait five minutes, then confirm that the new message appears in the GitHub App logs.
Issue
https://ucsc-cgl.atlassian.net/browse/DOCK-2468
#5683
Security and Privacy
No concerns.
Please make sure that you've checked the following before submitting your pull request. Thanks!

[x] Check that you pass the basic style checks and unit tests by running mvn clean install
[x] Ensure that the PR targets the correct branch. Check the milestone or fix version of the ticket.
[x] Follow the existing JPA patterns for queries, using named parameters, to avoid SQL injection
[x] If you are changing dependencies, check the Snyk status check or the dashboard to ensure you are not introducing new high/critical vulnerabilities
[x] Assume that inputs to the API can be malicious, and sanitize and/or check for Denial of Service type values, e.g., massive sizes
[x] Do not serve user-uploaded binary images through the Dockstore API
[x] Ensure that endpoints that only allow privileged access enforce that with the @RolesAllowed annotation
[x] Do not create cookies, although this may change in the future
[x] If this PR is for a user-facing feature, create and link a documentation ticket for this feature (usually in the same milestone as the linked issue). Style points if you create a documentation PR directly and link that instead.

but there's no obvious public hooks, and it appears that we'd be fiddling with its innards to a degree that, IMHO, the danger would outweigh the benefits.

Upgrade breakage would be a pain too, agreed if there is no obvious hook


Targeting updated to Net7, Net6, Net472 and NetCoreApp3.1 + Cross-Platform Issue Resolved

1.GlobalSuppression file added to suppress irregular naming conventions

Hack workaround to Windows targeted thread affinity in Native32.cs that causes performance issues on certain Amazon image Linux distributions.  The original Windows method remains unchanged.

Solution updated to target Net7, Net6, Net472, and NetCoreapp3.1

@microsoft-github-policy-service agree [company="{your company}"]

@microsoft-github-policy-service agree


Run unit tests for Python-3.10

Description
closes: https://github.com/astronomer/astro-sdk/issues/760
What is the current behavior?
Currently, we run tests in CI for only Python-3.8
What is the new behavior?
Run unit tests for Python-{3.8,3.9,3.10}
Does this introduce a breaking change?
No
Checklist

[ ] Created tests which fail without the change (if possible)
[ ] Extended the README / documentation, if necessary

Do we also need to run integration tests for Python 3.10 ?
If yes, can we create a ticket for that? Otherwise the current ticket will get closed and we will miss running integrations tests for Python 3.10.

I was anticipating that we will run unit tests only but @phanikumv @kaxil can add more to it.

Do we also need to run integration tests for Python 3.10 ?
If yes, can we create a ticket for that? Otherwise the current ticket will get closed and we will miss running integrations tests for Python 3.10.

I was anticipating that we will run unit tests only but @phanikumv @kaxil can add more to it.

What I would like is to run longer term is:

Unit tests for multiple Python versions (3.8-3.10)
Full test suite (Unit + Integration) with the latest Airflow version (2.5 right now)
Selective Integration tests (just example DAGs) for the oldest Airflow version that is an LTS (2.2) from Astro Runtime perspective as described in https://docs.astronomer.io/astro/runtime-version-lifecycle-policy#long-term-support-lts-releases

Do we also need to run integration tests for Python 3.10 ?
If yes, can we create a ticket for that? Otherwise the current ticket will get closed and we will miss running integrations tests for Python 3.10.

I was anticipating that we will run unit tests only but @phanikumv @kaxil can add more to it.

What I would like is to run longer term is:

Unit tests for multiple Python versions (3.8-3.10)
Full test suite (Unit + Integration) with the latest Airflow version (2.5 right now)
Selective Integration tests (just example DAGs) for the oldest Airflow version that is an LTS (2.2) from Astro Runtime perspective as described in https://docs.astronomer.io/astro/runtime-version-lifecycle-policy#long-term-support-lts-releases

Ok, I have created https://github.com/astronomer/astro-sdk/issues/1632 to track it. It is easy to enable even integration tests for Python-{3.8,3.9,3.10} but I'm worried about a few flaky tests that would slow down development efficiency so I'll not enable them in this PR.

It is easy to enable even integration tests for Python-{3.8,3.9,3.10}

No, we don't need to run all integration tests for all Python versions :)


Change ordering in _otel_agent.tpl

Fixes: #633
Bug:

When we use both multilineConfig AND extraOperators in values.yaml, extraOperators will be skipped because multilineConfig will output directly to the clean-up-log-record operator.
To fix this, move extraOperators above multilineConfig in _otel_agent.tpl

@VihasMakwana, thanks for fixing it. Please add a changelog entry

@VihasMakwana, thanks for fixing it. Please add a changelog entry

@dmitryax done. please re-review


dircolors: move help strings to markdown file

#4368
dircolors -h  shows the following.
$ ./target/debug/coreutils dircolors -h
Output commands to set the LS_COLORS environment variable.

Usage: ./target/debug/coreutils dircolors [OPTION]... [FILE]

Options:
  -b, --sh               output Bourne shell code to set LS_COLORS [aliases: bourne-shell]
  -c, --csh              output C shell code to set LS_COLORS [aliases: c-shell]
  -p, --print-database   print the byte counts
      --print-ls-colors  output fully escaped colors for display
  -h, --help             Print help information
  -V, --version          Print version information

If FILE is specified, read it to determine which colors to use for which
file types and extensions.  Otherwise, a precompiled database is used.
For details on the format of these files, run 'dircolors --print-database'

Thanks again! :)


chore: Fix karpenter_nodeclaims_drifted metric

Fixes #N/A
Description
The karpenter_nodeclaims_drifted metric was coming through the karpenter_nodeclaims_disrupted metric due to a typo and a lack of testing around these metrics.
This change adds testing around the disruption metrics and ensures that we correctly fire the karpenter_nodeclaims_drifted metric
How was this change tested?
make presubmit
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
4 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.02%) to 79.944%

Files with Coverage Reduction
New Missed Lines
%

pkg/controllers/disruption/drift.go
2
87.34%

pkg/controllers/provisioning/scheduling/nodeclaim.go
2
88.17%

Totals

Change from base Build<PHONE_NUMBER>:
-0.02%

Covered Lines:
7653

Relevant Lines:
9573

💛  - Coveralls

/lgtm


⚠ TiendaEnLinea has degraded performance

In 58e08a2, TiendaEnLinea (https://www.fahorro.com/) experienced degraded performance:

HTTP code: 200
Response time: 5296 ms

Resolved: TiendaEnLinea performance has improved in 83c2734.


Update Post “2017-10-26-daft-punk.fr”

Automatically generated by Netlify CMS

👷 Deploy Preview for akulina processing.

Name
Link

🔨 Latest commit
ba411e60ad8455123cd0f0f116abeaca4ac41ea0

🔍 Latest deploy log
https://app.netlify.com/sites/akulina/deploys/63a0d4c4fe5aeb0009144ad6


Permission issues during the export job fix

Overview
AWS EMR has some specific settings, which should be used as is.
Export job (and other jobs) overrided some specific settings provided by environment which caused permissions issues (potentially not export job was effected).
Test instructions
Run it on EMR and locally.
 Is it a docker environment or your local setup? As if it's in docker be sure that your jar is inside the container

...it was on the master but not on the driver oops

Now I can't load AWS credentials --

Now I can't load AWS credentials --

See if you can tweak the Vagrantfile to make the .aws mount be:
config.vm.synced_folder "~/.aws", "/home/vagrant/.aws", mount_options: ["fmode=644"]

You'll have to vagrant reload for that to take effect.

That did it, thanks


addSupportForRuntimeReadManyFilter

Issue
Typically for scenarios where in spark flow, customers need to join two datasets/dataframes - one side is relatively small, the other side is reading from CosmosDb and relatively large, it would be nice to have only read necessary data from CosmosDb for the larger datasets based on the smaller datasets, which saves the query time and RU usage.
When the result of the smaller datasets is dynamically computed, the results will not be automatically be used for predicates push down during query plan analysis time. Some customers have been trying to tackle this issue by first loading the data for the smaller datasets, then construct a customized query by using IN Clause, however, due to the limitation of query text cannot be > 2MB for Cosmos DB, this also exposes its limitations.
In this PR, we are trying to optimize for the above scenarios by utilizing the readMany API (which provided in azure-cosmos Java SDK) when the necessary information (id and pk) can be extracted from the smaller datasets.
High level changes
New Cosmos Config:

spark.cosmos.read.runtimeFiltering.enabled: Indicates whether SDK supports dynamic partition pruning. More details can be found in following sections.
spark.cosmos.read.readManyFiltering.enabled: Indicates whether readMany filter is enabled. When this is enabled,

When the container also has the /id as the partitionKey, SDK will automatically use /id as the readMany filtering property
Else, a new _ItemIdentity property will be automatically added in the schema and populated in the final datasets, which is a combination of id & partitionKey. Customers will need to filter or join by this new property to properly trigger readMany filtering. Customers can construct _itemIdentity by using the provided udf function GetCosmosItemIdentityValue.

 spark.udf.register("GetCosmosItemIdentityValue", new GetCosmosItemIdentityValue(), StringType)
 val joinDfWithCosmosIdentity =
     joinDf.withColumn("_itemIdentity", expr("GetCosmosItemIdentityValue(id, pk)"))

There are two major flows where readMany optimization can kick in.
Dynamic partition pruning
PartitionPruning high level understanding
PartitionPruning doc
Spark connector code changes

ItemsScan to support SupportsRuntimeFiltering and SupportsReportStatistics, which leads to three methods being implemented:

filterAttributes(): attributes based on which partitions can be pruned.
filter(filters: Array[Filter]): called for runtime filters. if the runtime filter is based on the readMany filtering property (_itemIdentity or id), then SDK will be prune partitions based on the filter and use readMany internally to fetch all related items.
estimateStatistics: called after operators have been pushed down to datasource. It is a way for the spark optimizer to get a more accurate of the result statistics. However, in SDK, we will not be able to estimate the final result set if there is any filters being pushed down, so for now we will only return collection statistics when no filters being pushed down.

Caveat
During testing, it has been found that in order for partition pruning to kick in, there are few conditions it needs to met:

The join of columns needs to be subsets of what has been returned in filter attributes
Dynamic partition pruning will only kick in if underlying a broadcastHashedJoin can be used
when filter() method being called, it will pass in separate filters for the joined columns. For example, if we have defined "id" and "pk" in the filterAttributes() and innerJoin on them, then the filters being passed in will be In("id", Array()), In("pk", Array()), which will not be very useful to be able to use readMany. And this is one of the reason why we have introduced _itemIdentity
In order for dynamic partition pruning to happen, there needs to be a selective filter on the smaller dataset, this filter may get pushed down during query analysis time. Two issues it can bring up, (1)If the filter can be pushed down to the data source, it will be removed from the spark after-scan filter, hence invalidate the optimization. (2) If the filter can be pushed down, then our SDK can not return accurate statistics, hence we fall back to use Spark estimation. In this case, the optimizer may fallback to use Long.maxValue for the size estimation, which may invalidate the optimization as well.
There are few conditions spark use to decide whether broadcastHashJoin can happen, one of them is based on spark.sql.autoBroadcastJoinThreshold, which by default is 10MB. So it may need to tune this parameter to let dynamic partition pruning happen
The dynamic partition pruning optimization can be invalidated If the underlying broadcastExchange can not be reused, setting spark.sql.optimizer.dynamicPartitionPruning.reuseBroadcastOnly to false may still help to let the runtime filter happen

Filter pushdown during query plan analysis
For cases where customer is able to load the smaller datasets upfront, they can easily craft a IN subquery based on the readMany filtering property, which later can be pushed down during query plan analysis stage. ReadMany optimization can kick in based on whether such filter presents.
Tests

InClauseWithReadMany*: using IN clause on id with readMany optimization enabled

val cfg = Map("spark.cosmos.accountEndpoint" -> cosmosEndpoint,
    "spark.cosmos.accountKey" -> cosmosMasterKey,
    "spark.cosmos.database" -> "SampleDatabase",
    "spark.cosmos.container" -> "GreenTaxiRecords",
    "spark.cosmos.read.runtimeFiltering.enabled" -> "true",
    "spark.cosmos.read.readManyFiltering.enabled" -> "true"
)
val dfAll = spark.read.format("cosmos.oltp").options(cfg).load()

val joinCfg = Map("spark.cosmos.accountEndpoint" -> cosmosEndpoint,
    "spark.cosmos.accountKey" -> cosmosMasterKey,
    "spark.cosmos.database" -> "SampleDatabase",
    "spark.cosmos.container" -> "GreenTaxiRecordsCFSink"
)
val joinDf = spark.read.format("cosmos.oltp").options(joinCfg).load().select("id").collect()

val valuesToFilter = joinDf.map(_.getString(0))
val results = dfAll.where(dfAll("id") isin(valuesToFilter:_*)).collect()

InClausePlain*: using IN clause on id without readMany optimization enabled

val cfg = Map("spark.cosmos.accountEndpoint" -> cosmosEndpoint,
    "spark.cosmos.accountKey" -> cosmosMasterKey,
    "spark.cosmos.database" -> "SampleDatabase",
    "spark.cosmos.container" -> "GreenTaxiRecords"
)
val dfAll = spark.read.format("cosmos.oltp").options(cfg).load()

val joinCfg = Map("spark.cosmos.accountEndpoint" -> cosmosEndpoint,
    "spark.cosmos.accountKey" -> cosmosMasterKey,
    "spark.cosmos.database" -> "SampleDatabase",
    "spark.cosmos.container" -> "GreenTaxiRecordsCFSink"
)
val joinDf = spark.read.format("cosmos.oltp").options(joinCfg).load().select("id").collect()

val valuesToFilter = joinDf.map(_.getString(0))
val results = dfAll.where(dfAll("id") isin(valuesToFilter:_*)).collect()

InnerJoinPlain*: using innerJoin on id

val cfg = Map("spark.cosmos.accountEndpoint" -> cosmosEndpoint,
    "spark.cosmos.accountKey" -> cosmosMasterKey,
    "spark.cosmos.database" -> "SampleDatabase",
    "spark.cosmos.container" -> "GreenTaxiRecords"
)
val dfAll = spark.read.format("cosmos.oltp").options(cfg).load()

val joinCfg = Map("spark.cosmos.accountEndpoint" -> cosmosEndpoint,
    "spark.cosmos.accountKey" -> cosmosMasterKey,
    "spark.cosmos.database" -> "SampleDatabase",
    "spark.cosmos.container" -> "GreenTaxiRecordsCFSink"
)
val joinDf = spark.read.format("cosmos.oltp").options(joinCfg).load().select("id").collect()

val result = dfAll.join(joinDf).where(dfAll("id") === joinDf("id")).collect()

Larger container: 100K RU, id as partitionKey
Smaller container: 50K, id as partitionKey
Find matching 10K items out of 18,710,653 items

Type
Duration
# of Query Requests
Total RU

InClauseWithReadMany
8s
21
1700RU

InClausePlain
7.88s
51
6,996 RU

InnerJoinPlain
1.67 mins
18,739
991,778 RU

Find matching 100K items out of 18,710,653 items

Type
Duration
# of Query Requests
Total RU

InClauseWithReadMany
26.38s
112
14,844RU

InClausePlain
RequestEntityTooLargeException
N/A
N/A

InnerJoinPlain
1.67 mins
18,739
991,619 RU

Find matching 100K items out of 100M items

Type
Duration
# of Query Requests
Total RU

InClauseWithReadMany
27.03s
114
14,847 RU

InClausePlain
RequestEntityTooLargeException
N/A
N/A

InnerJoinPlain
5.89 mins
119,838
15,905,384 RU

Find matching 1M items out of 100M items

Type
Duration
# of Query Requests
Total RU

InClauseWithReadMany
4 mins
1,334
188,166RU

InClausePlain
RequestEntityTooLargeException
N/A
N/A

InnerJoinPlain
6.47 mins
120,977
16,127,792RU

/azp run java - cosmos - tests

/azp run java - cosmos - tests

/azp run java - cosmos - tests

/azp run java - cosmos - spark

/azp run java - cosmos - spark

/azp run java - cosmos - tests