Update Copy-SPTaxonomyGroups.md

Removed SharePoint Server 2010 applicability. Updated missing text. Most missing text pulled from cmdlet example on SharePoint Server 2016.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

sharepoint/sharepoint-ps/sharepoint-server/Copy-SPTaxonomyGroups.md
:white_check_mark:Succeeded
View (sharepoint-ps)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

sharepoint/sharepoint-ps/sharepoint-server/Copy-SPTaxonomyGroups.md
:white_check_mark:Succeeded
View (sharepoint-ps)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


apm changes home and thus ignore regulare .gitconfig

HOME environment has been set to %USERPROFILE%.atom.node-gyp during plugin installation, which may provock an failure in plugin installation

Thanks for reaching out!
We require the template to be filled out on all new issues and pull requests. We do this so that we can be certain we have all the information we need to address your submission efficiently. This allows the maintainers to spend more time fixing bugs, implementing enhancements, and reviewing and merging pull requests.
Thanks for understanding and meeting us half way :grinning:


[Dubbo-1054][Baiji-9] add "send consumer application name to provider " feature   #1054

What is the purpose of the change
resolve the issue -- Provider cannot get the application parameter of consumer's url #1054
Brief changelog
Add an internal filter to add consumer application name to Invocation attachements.In the provider endpoint,use RpcContext to get consumer application name.
Verifying this change
Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Make sure there is a GITHUB_issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[ ] Run mvn clean install -DskipTests & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
[ ] If this contribution is large, please follow the Software Donation Guide.

I think it would be better to move this extension to https://github.com/dubbo/dubbo-samples/tree/master/dubbo-samples-attachment

I saw dubbo-samples-attachment already merge another way to set attachement(use RpcContext in consumer endpoint),but my method is set attachment in Invocation,I don't know how to merge two way in dubbo-samples-attachement.

Oh, I see.
I think to use your Filter extension to pass application key is better. So let me change the example to pass other key difference with application.

I have checked and found that teh sample use another key name. You can transfor this implementation to there directlly and give the users another option.

https://github.com/dubbo/dubbo-samples/pull/26


apis: add node recommendation and Mid tier api

Ⅰ. Describe what this PR does

Add apis for node recommendation and Mid tier.
Ⅱ. Does this pull request fix one issue?

Part of #1361.
Ⅲ. Describe how to verify it
Ⅳ. Special notes for reviews
V. Checklist

[ ] I have written necessary docs and comments
[ ] I have added necessary unit tests and integration tests
[ ] All checks passed in make test

/cc @hormes @zwzhang0107 @eahydra

will there be a proposal for recommendation feature?

Yes. The proposal will be submitted in another PR.

/hold

/lgtm
/approve


Redesigning the Vscode Extension.

@Aditya-eddy When I am running npm run rollup or compile its giving me the following errors -

Were you able to do the same ?

@Aditya-eddy Can you check an extra test folder is getting created inspite of already having my test folder in the root directory. This is causing the command to fail as there will be no tests in that file.

And API call also failed in the starting .


CMake Error at /usr/share/cmake-3.16/Modules/CMakeFindDependencyMacro.cmake:47 (find_package):   Could not find a configuration file for package "ignition-common3-graphics"   that exactly matches requested version "3.6.0".

Hello,
I am getting this issue over and over again while I am compiling packages using catkin_make after cloning the packages from git clone -b noetic-devel https://github.com/ROBOTIS-GIT/turtlebot3_simulations.git. error showed below
`CMake Error at /usr/share/cmake-3.16/Modules/CMakeFindDependencyMacro.cmake:47 (find_package):
Could not find a configuration file for package "ignition-common3-graphics"
that exactly matches requested version "3.6.0".
The following configuration files were considered but not accepted:
/usr/lib/x86_64-linux-gnu/cmake/ignition-common3-graphics/ignition-common3-graphics-config.cmake, version: 3.5.0
/lib/x86_64-linux-gnu/cmake/ignition-common3-graphics/ignition-common3-graphics-config.cmake, version: 3.5.0

Call Stack (most recent call first):
/usr/lib/x86_64-linux-gnu/cmake/ignition-common3/ignition-common3-config.cmake:203 (find_dependency)
/usr/lib/x86_64-linux-gnu/cmake/gazebo/gazebo-config.cmake:209 (find_package)
turtlebot3_simulations/turtlebot3_gazebo/CMakeLists.txt:23 (find_package)
-- Configuring incomplete, errors occurred!
See also "/home/shavista/catkin_ws/build/CMakeFiles/CMakeOutput.log".
See also "/home/shavista/catkin_ws/build/CMakeFiles/CMakeError.log".
make: *** [Makefile:2980: cmake_check_build_system] Error 1
Invoking "make cmake_check_build_system" failed`
I don't know how to resolve this issue, can you please help me out

Sorry, I found the problem, it is at my side. I couldn't do properly sudo apt-get upgrade. After running this, I  am able to solve the issue

Sorry, I found the problem, it is at my side. I couldn't do properly sudo apt-get upgrade. After running this, I  am able to solve the issue


feat(event_handler): enhance Response class with compress parameter

Issue number: #2513
Summary
Changes
Use case: Customers can use the exception_handler decorator to handle 4xx/5xx errors, and in case of a response other than 2xx, the response should not be encoded.
This pull request aims to improve the Response class by adding the compress parameter. The compress parameter allows enabling or disabling response data compression and can override the compress parameter defined in the route.
User experience
BEFORE
import json

from aws_lambda_powertools.event_handler import (
    APIGatewayRestResolver,
    Response,
    content_types,
)
from aws_lambda_powertools.utilities.typing import LambdaContext

app = APIGatewayRestResolver()

@app.exception_handler(NameError)
def handle_invalid_params(ex: NameError):
    response = Response(
            status_code=500,
            content_type=content_types.APPLICATION_JSON,
            body=json.dumps({"ex": str(ex)})
        )
    return response

@app.get("/hello", compress=True)
def hello():
    raise NameError("Error")

def lambda_handler(event: dict, context: LambdaContext) -> dict:
    return app.resolve(event, context)

AFTER
import json

from aws_lambda_powertools.event_handler import (
    APIGatewayRestResolver,
    Response,
    content_types,
)
from aws_lambda_powertools.utilities.typing import LambdaContext

app = APIGatewayRestResolver()

@app.exception_handler(NameError)
def handle_invalid_params(ex: NameError):
    response = Response(
            status_code=500,
            content_type=content_types.APPLICATION_JSON,
            body=json.dumps({"ex": str(ex)}),
            compress=False
        )
    return response

@app.get("/hello", compress=True)
def hello():
    raise NameError("Error")

def lambda_handler(event: dict, context: LambdaContext) -> dict:
    return app.resolve(event, context)

Checklist
If your change doesn't seem to apply, please leave them unchecked.

[x] Meet tenets criteria
[x] I have performed a self-review of this change
[x] Changes have been tested
[x] Changes are documented
[x] PR title follows conventional commit semantics

Is this a breaking change?
RFC issue number:
Checklist:

[ ] Migration process documented
[ ] Implement warnings (if it can live side by side)

Acknowledgment
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

looking

quick comment: Update the example not to send stacktrace to prevent data leak; log the stack trace instead, and return another message instead back to the client.

Codecov Report
Patch coverage: 100.00% and project coverage change: -0.03 :warning:

Comparison is base (460aaa0) 97.19% compared to head (2b2b82f) 97.17%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #2544      +/-   ##
===========================================
- Coverage    97.19%   97.17%   -0.03%
===========================================
  Files          158      158
  Lines         7348     7353       +5
  Branches       531      532       +1
===========================================
+ Hits          7142     7145       +3
- Misses         159      160       +1
- Partials        47       48       +1

Impacted Files
Coverage Δ

aws_lambda_powertools/event_handler/api_gateway.py
100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes

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


cannot locate element to like post or comment

          I cloned the newest version and the issue is still persisting.

Originally posted by @digitizesuccess in https://github.com/shine-jayakumar/insta-likecom-bot/issues/87#issuecomment-1688580043

Please share the logs because I am running the same version and it's working.

any updates?

v.3.0.4 out. Please check if the problem persists.


setup_assistant launch files don't work

Description
I've used the setup_assistant to create a moveit_config package from my urdf file (of a meca500), but I can't launch anything.
I'm pretty certain the urdf file is fine, since the assistant doesn't complain and it worked in ROS1.
One of the problems i encountered is this one  #1814 i've used the workaround mentioned there, that might impact the other results though.
Your environment

ROS Distro: Humble (& Jazzy)

OS Version: Ubuntu 22.04 (& 24.04)

Source or Binary build?: Source Build (%& binary build)

If binary, which release version?: 2.10.0-1noble.20240719.210749

If source, which branch? : Iron

Which RMW (Fast DDS or Cyclone DDS)? : ROS2 default

I mostly work with humble, but due to the lackluster support for python i also did some test with jazz to see if it was fixed in the mean time (as far as i can tell it wasn't)

Steps to reproduce

install moveit2
get an URDF file
launch setup assiastan `ros2 launch moveit_setup_assistant setup_assistant.launch.py``
launch the generated launch files

e.g. ros2 launch meca_moveit2_config demo.launch.py
e.g. ros2 launch meca_moveit2_config move_group.launch.py

Expected behaviour
RViz should lauch with the robot model and the moveit nodes should be spawned
Actual behaviour
RViz launches without the model and the moveit nodes do not appear
Backtrace or Console output
In case of ros2 launch meca_moveit2_config demo.launch.py  :
[rviz2-4] Warning: class_loader.impl: SEVERE WARNING!!! A namespace collision has occurred with plugin factory for class rviz_default_plugins::displays::InteractiveMarkerDisplay. New factory will OVERWRITE existing one. This situation occurs when libraries containing plugins are directly linked against an executable (the one running right now generating this message). Please separate plugins out into their own library or just don't link against the library and use either class_loader::ClassLoader/MultiLibraryClassLoader to open.
[rviz2-4]          at line 253 in /opt/ros/humble/include/class_loader/class_loader/class_loader_core.hpp
[spawner-7] [INFO] [1721997461.939915429] [spawner_joint_state_broadcaster]: Waiting for '/controller_manager' node to exist
[ros2_control_node-5] [INFO] [1721997462.153337706] [controller_manager]: Loading controller 'joint_state_broadcaster'
[spawner-7] [INFO] [1721997462.215030818] [spawner_joint_state_broadcaster]: Loaded joint_state_broadcaster
[ros2_control_node-5] [INFO] [1721997462.216510785] [controller_manager]: Configuring controller 'joint_state_broadcaster'
[ros2_control_node-5] [INFO] [1721997462.216600127] [joint_state_broadcaster]: 'joints' or 'interfaces' parameter is empty. All available state interfaces will be published
[spawner-7] [INFO] [1721997462.514558611] [spawner_joint_state_broadcaster]: Configured and activated joint_state_broadcaster
[INFO] [spawner-7]: process has finished cleanly [pid 240080]
[rviz2-4] [ERROR] [1721997464.218080710] [moveit_2326694259.moveit.ros.motion_planning_frame]: Action server: /recognize_objects not available
[rviz2-4] [INFO] [1721997464.254434545] [moveit_2326694259.moveit.ros.motion_planning_frame]: MoveGroup namespace changed: / -> . Reloading params.
[rviz2-4] [ERROR] [1721997474.520481676] [rviz]: Could not find parameter robot_description_semantic and did not receive robot_description_semantic via std_msgs::msg::String subscription within 10.000000 seconds.
[rviz2-4] Error:   Could not parse the SRDF XML File. Error=XML_ERROR_EMPTY_DOCUMENT ErrorID=13 (0xd) Line number=0
[rviz2-4]          at line 715 in ./src/model.cpp
[rviz2-4] [ERROR] [1721997474.542100358] [moveit_2326694259.moveit.ros.rdf_loader]: Unable to parse SRDF
[rviz2-4] [ERROR] [1721997474.565024350] [moveit_2326694259.moveit.ros.planning_scene_monitor]: Robot model not loaded

In case of ros2 launch meca_moveit2_config move_group.launch.py  :
[move_group-1] [INFO] [1721997672.534403688] [move_group.moveit.moveit.ros.rdf_loader]: Loaded robot model in 0.033171 seconds
[move_group-1] [INFO] [1721997672.534762827] [move_group.moveit.moveit.core.robot_model]: Loading robot model 'meca_500_r3'...
[move_group-1] [INFO] [1721997672.575961874] [move_group.moveit.moveit.kinematics.kdl_kinematics_plugin]: Joint weights for group 'meca_arm': 1 1 1 1 1 1
[move_group-1] [INFO] [1721997672.576678089] [move_group.moveit.moveit.kinematics.kdl_kinematics_plugin]: Joint weights for group 'meca': 1 1 1 1 1 1
[move_group-1] Stack trace (most recent call last):
[move_group-1] #14   Object "", at 0xffffffffffffffff, in
[move_group-1] #13   Object "/home/***/meca_ros2_workspace/build/moveit_ros_move_group/move_group", at 0x55c657191094, in _start
[move_group-1] #12   Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x7f9b3a50de3f, in __libc_start_main
[move_group-1] #11   Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x7f9b3a50dd8f, in
[move_group-1] #10   Object "/home/***/meca_ros2_workspace/build/moveit_ros_move_group/move_group", at 0x55c65719021e, in main
[move_group-1] #9    Object "/home/***/meca_ros2_workspace/install/moveit_ros_planning/lib/libmoveit_cpp.so.2.10.0", at 0x7f9b3ae3ad5a, in moveit_cpp::MoveItCpp::MoveItCpp(std::shared_ptr<rclcpp::Node> const&, moveit_cpp::MoveItCpp::Options const&)
[move_group-1] #8    Object "/home/***/meca_ros2_workspace/install/moveit_ros_planning/lib/libmoveit_cpp.so.2.10.0", at 0x7f9b3ae3a71b, in moveit_cpp::MoveItCpp::loadPlanningSceneMonitor(moveit_cpp::MoveItCpp::PlanningSceneMonitorOptions const&)
[move_group-1] #7    Object "/home/***/meca_ros2_workspace/install/moveit_ros_planning/lib/libmoveit_planning_scene_monitor.so.2.10.0", at 0x7f9b3ad41231, in planning_scene_monitor::PlanningSceneMonitor::PlanningSceneMonitor(std::shared_ptr<rclcpp::Node> const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
[move_group-1] #6    Object "/home/***/meca_ros2_workspace/install/moveit_ros_planning/lib/libmoveit_planning_scene_monitor.so.2.10.0", at 0x7f9b3ad411a6, in planning_scene_monitor::PlanningSceneMonitor::PlanningSceneMonitor(std::shared_ptr<rclcpp::Node> const&, std::shared_ptr<planning_scene::PlanningScene> const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
[move_group-1] #5    Object "/home/***/meca_ros2_workspace/install/moveit_ros_planning/lib/libmoveit_planning_scene_monitor.so.2.10.0", at 0x7f9b3ad40d74, in planning_scene_monitor::PlanningSceneMonitor::PlanningSceneMonitor(std::shared_ptr<rclcpp::Node> const&, std::shared_ptr<planning_scene::PlanningScene> const&, std::shared_ptr<robot_model_loader::RobotModelLoader> const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
[move_group-1] #4    Object "/home/***/meca_ros2_workspace/install/moveit_ros_planning/lib/libmoveit_planning_scene_monitor.so.2.10.0", at 0x7f9b3ad3fa84, in planning_scene_monitor::PlanningSceneMonitor::initialize(std::shared_ptr<planning_scene::PlanningScene> const&)
[move_group-1] #3    Object "/home/***/meca_ros2_workspace/install/moveit_core/lib/libmoveit_planning_scene.so.2.10.0", at 0x7f9b3a092bd5, in planning_scene::PlanningScene::PlanningScene(std::shared_ptr<moveit::core::RobotModel const> const&, std::shared_ptr<collision_detection::World> const&)
[move_group-1] #2    Object "/home/***/meca_ros2_workspace/install/moveit_core/lib/libmoveit_planning_scene.so.2.10.0", at 0x7f9b3a09206e, in planning_scene::PlanningScene::initialize()
[move_group-1] #1    Object "/home/***/meca_ros2_workspace/install/moveit_core/lib/libmoveit_robot_state.so.2.10.0", at 0x7f9b3a3f2945, in moveit::core::RobotState::~RobotState()
[move_group-1] #0    Object "/home/***/meca_ros2_workspace/install/moveit_core/lib/libmoveit_robot_state.so.2.10.0", at 0x7f9b3a3f283a, in moveit::core::RobotState::clearAttachedBodies()
[move_group-1] Segmentation fault (Address not mapped to object [0x40])
[ERROR] [move_group-1]: process has died [pid 241068, exit code -11, cmd '/home/***/meca_ros2_workspace/install/moveit_ros_move_group/lib/moveit_ros_move_group/move_group --ros-args --params-file /tmp/launch_params_t_2_4ps_ --params-file /tmp/launch_params_t_e0684e'].

These outputs are on humble but they are pretty identical on jazzy exept for the cases i run into [ERROR] [launch]: Caught exception in launch (see debug for traceback): 'capabilities' on jazzy cause there i have the binary package and can't easily apply the workaround

I've graduated to the next wierd error message
[move_group-1] terminate called after throwing an instance of 'pluginlib::LibraryLoadException' [move_group-1]   what():  Failed to load library /opt/ros/jazzy/lib/libsdformat_urdf_plugin.so. Make sure that you are calling the PLUGINLIB_EXPORT_CLASS macro in the library code, and that names are consistent between this macro and your XML. Error string: Could not load library dlopen error: libsdformat14.so.14: cannot open shared object file: No such file or directory, at ./src/shared_library.c:99 from ros2 launch meca_moveit2_config move_group.launch.py (source build main branch on jazzy)

Description
I've used the setup_assistant to create a moveit_config package from my urdf file (of a meca500), but I can't launch anything. I'm pretty certain the urdf file is fine, since the assistant doesn't complain and it worked in ROS1. One of the problems i encountered is this one #1814 i've used the workaround mentioned there, that might impact the other results though.
Your environment

ROS Distro: Humble (& Jazzy)
OS Version: Ubuntu 22.04 (& 24.04)
Source or Binary build?: Source Build (%& binary build)
If binary, which release version?: 2.10.0-1noble.20240719.210749
If source, which branch? : Iron
Which RMW (Fast DDS or Cyclone DDS)? : ROS2 default
I mostly work with humble, but due to the lackluster support for python i also did some test with jazz to see if it was fixed in the mean time (as far as i can tell it wasn't)

Steps to reproduce

install moveit2

get an URDF file

launch setup assiastan `ros2 launch moveit_setup_assistant setup_assistant.launch.py``

launch the generated launch files

e.g. ros2 launch meca_moveit2_config demo.launch.py
e.g. ros2 launch meca_moveit2_config move_group.launch.py

Expected behaviour
RViz should lauch with the robot model and the moveit nodes should be spawned
Actual behaviour
RViz launches without the model and the moveit nodes do not appear
Backtrace or Console output
In case of ros2 launch meca_moveit2_config demo.launch.py  :
[rviz2-4] Warning: class_loader.impl: SEVERE WARNING!!! A namespace collision has occurred with plugin factory for class rviz_default_plugins::displays::InteractiveMarkerDisplay. New factory will OVERWRITE existing one. This situation occurs when libraries containing plugins are directly linked against an executable (the one running right now generating this message). Please separate plugins out into their own library or just don't link against the library and use either class_loader::ClassLoader/MultiLibraryClassLoader to open.
[rviz2-4]          at line 253 in /opt/ros/humble/include/class_loader/class_loader/class_loader_core.hpp
[spawner-7] [INFO] [1721997461.939915429] [spawner_joint_state_broadcaster]: Waiting for '/controller_manager' node to exist
[ros2_control_node-5] [INFO] [1721997462.153337706] [controller_manager]: Loading controller 'joint_state_broadcaster'
[spawner-7] [INFO] [1721997462.215030818] [spawner_joint_state_broadcaster]: Loaded joint_state_broadcaster
[ros2_control_node-5] [INFO] [1721997462.216510785] [controller_manager]: Configuring controller 'joint_state_broadcaster'
[ros2_control_node-5] [INFO] [1721997462.216600127] [joint_state_broadcaster]: 'joints' or 'interfaces' parameter is empty. All available state interfaces will be published
[spawner-7] [INFO] [1721997462.514558611] [spawner_joint_state_broadcaster]: Configured and activated joint_state_broadcaster
[INFO] [spawner-7]: process has finished cleanly [pid 240080]
[rviz2-4] [ERROR] [1721997464.218080710] [moveit_2326694259.moveit.ros.motion_planning_frame]: Action server: /recognize_objects not available
[rviz2-4] [INFO] [1721997464.254434545] [moveit_2326694259.moveit.ros.motion_planning_frame]: MoveGroup namespace changed: / -> . Reloading params.
[rviz2-4] [ERROR] [1721997474.520481676] [rviz]: Could not find parameter robot_description_semantic and did not receive robot_description_semantic via std_msgs::msg::String subscription within 10.000000 seconds.
[rviz2-4] Error:   Could not parse the SRDF XML File. Error=XML_ERROR_EMPTY_DOCUMENT ErrorID=13 (0xd) Line number=0
[rviz2-4]          at line 715 in ./src/model.cpp
[rviz2-4] [ERROR] [1721997474.542100358] [moveit_2326694259.moveit.ros.rdf_loader]: Unable to parse SRDF
[rviz2-4] [ERROR] [1721997474.565024350] [moveit_2326694259.moveit.ros.planning_scene_monitor]: Robot model not loaded

In case of ros2 launch meca_moveit2_config move_group.launch.py  :
[move_group-1] [INFO] [1721997672.534403688] [move_group.moveit.moveit.ros.rdf_loader]: Loaded robot model in 0.033171 seconds
[move_group-1] [INFO] [1721997672.534762827] [move_group.moveit.moveit.core.robot_model]: Loading robot model 'meca_500_r3'...
[move_group-1] [INFO] [1721997672.575961874] [move_group.moveit.moveit.kinematics.kdl_kinematics_plugin]: Joint weights for group 'meca_arm': 1 1 1 1 1 1
[move_group-1] [INFO] [1721997672.576678089] [move_group.moveit.moveit.kinematics.kdl_kinematics_plugin]: Joint weights for group 'meca': 1 1 1 1 1 1
[move_group-1] Stack trace (most recent call last):
[move_group-1] #14   Object "", at 0xffffffffffffffff, in
[move_group-1] #13   Object "/home/***/meca_ros2_workspace/build/moveit_ros_move_group/move_group", at 0x55c657191094, in _start
[move_group-1] #12   Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x7f9b3a50de3f, in __libc_start_main
[move_group-1] #11   Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x7f9b3a50dd8f, in
[move_group-1] #10   Object "/home/***/meca_ros2_workspace/build/moveit_ros_move_group/move_group", at 0x55c65719021e, in main
[move_group-1] #9    Object "/home/***/meca_ros2_workspace/install/moveit_ros_planning/lib/libmoveit_cpp.so.2.10.0", at 0x7f9b3ae3ad5a, in moveit_cpp::MoveItCpp::MoveItCpp(std::shared_ptr<rclcpp::Node> const&, moveit_cpp::MoveItCpp::Options const&)
[move_group-1] #8    Object "/home/***/meca_ros2_workspace/install/moveit_ros_planning/lib/libmoveit_cpp.so.2.10.0", at 0x7f9b3ae3a71b, in moveit_cpp::MoveItCpp::loadPlanningSceneMonitor(moveit_cpp::MoveItCpp::PlanningSceneMonitorOptions const&)
[move_group-1] #7    Object "/home/***/meca_ros2_workspace/install/moveit_ros_planning/lib/libmoveit_planning_scene_monitor.so.2.10.0", at 0x7f9b3ad41231, in planning_scene_monitor::PlanningSceneMonitor::PlanningSceneMonitor(std::shared_ptr<rclcpp::Node> const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
[move_group-1] #6    Object "/home/***/meca_ros2_workspace/install/moveit_ros_planning/lib/libmoveit_planning_scene_monitor.so.2.10.0", at 0x7f9b3ad411a6, in planning_scene_monitor::PlanningSceneMonitor::PlanningSceneMonitor(std::shared_ptr<rclcpp::Node> const&, std::shared_ptr<planning_scene::PlanningScene> const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
[move_group-1] #5    Object "/home/***/meca_ros2_workspace/install/moveit_ros_planning/lib/libmoveit_planning_scene_monitor.so.2.10.0", at 0x7f9b3ad40d74, in planning_scene_monitor::PlanningSceneMonitor::PlanningSceneMonitor(std::shared_ptr<rclcpp::Node> const&, std::shared_ptr<planning_scene::PlanningScene> const&, std::shared_ptr<robot_model_loader::RobotModelLoader> const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
[move_group-1] #4    Object "/home/***/meca_ros2_workspace/install/moveit_ros_planning/lib/libmoveit_planning_scene_monitor.so.2.10.0", at 0x7f9b3ad3fa84, in planning_scene_monitor::PlanningSceneMonitor::initialize(std::shared_ptr<planning_scene::PlanningScene> const&)
[move_group-1] #3    Object "/home/***/meca_ros2_workspace/install/moveit_core/lib/libmoveit_planning_scene.so.2.10.0", at 0x7f9b3a092bd5, in planning_scene::PlanningScene::PlanningScene(std::shared_ptr<moveit::core::RobotModel const> const&, std::shared_ptr<collision_detection::World> const&)
[move_group-1] #2    Object "/home/***/meca_ros2_workspace/install/moveit_core/lib/libmoveit_planning_scene.so.2.10.0", at 0x7f9b3a09206e, in planning_scene::PlanningScene::initialize()
[move_group-1] #1    Object "/home/***/meca_ros2_workspace/install/moveit_core/lib/libmoveit_robot_state.so.2.10.0", at 0x7f9b3a3f2945, in moveit::core::RobotState::~RobotState()
[move_group-1] #0    Object "/home/***/meca_ros2_workspace/install/moveit_core/lib/libmoveit_robot_state.so.2.10.0", at 0x7f9b3a3f283a, in moveit::core::RobotState::clearAttachedBodies()
[move_group-1] Segmentation fault (Address not mapped to object [0x40])
[ERROR] [move_group-1]: process has died [pid 241068, exit code -11, cmd '/home/***/meca_ros2_workspace/install/moveit_ros_move_group/lib/moveit_ros_move_group/move_group --ros-args --params-file /tmp/launch_params_t_2_4ps_ --params-file /tmp/launch_params_t_e0684e'].

These outputs are on humble but they are pretty identical on jazzy exept for the cases i run into [ERROR] [launch]: Caught exception in launch (see debug for traceback): 'capabilities' on jazzy cause there i have the binary package and can't easily apply the workaround

Hi, how did you fix the (Unable to parse SRDF error) exactly? I am getting the same error with Jazzy on Ubuntu 24.04.

With some Voodoo everything works now (except the "capabilities" thing). Unfortunately I don't quite understand and therefore can't tell you how exactly to solve it poor soul who googles the problem next.

I didn't it fixed itself or something


custom field not work

I use custom field like the wiki, but it not work.
vue 2
custom field components
<!-- fieldAwesome.vue -->
<template>
    <input
        class="form-control"
        type="text"
        v-model="value"
        :disabled="disabled"
        :maxlength="schema.max"
        :placeholder="schema.placeholder"
        :readonly="schema.readonly" >
</template>

<script>
import VueFormGenerator from "vue-form-generator";

   export default {
       name:"fieldAwesome",
         mixins: [ VueFormGenerator.abstractField ]
   };
</script>

import VueFormGenerator from "vue-form-generator";
import "vue-form-generator/dist/vfg-core.css";
import fieldAwesome from "./fieldAwesome";
export default {
    name: "autoform",
    components: {
        "vue-form-generator": VueFormGenerator.component,
        "fieldAwesome":fieldAwesome
    }

form style  was get from backend (python)
  form = [
        {
       "type": "awesome",
       "label": "Awesome (custom field)",
       "model": "userName"
   }]

Only the label show, and had warn
[Vue warn]: Unknown custom element: <field-awesome> - did you register the component correctly? For recursive components, make sure to provide the "name" option.

found in

---> <VueFormGenerator>
       <ElForm>
         <Autoform> at src/views/project/components/autoform.vue`

You may have to register the field as a global component

You need to tell Vue to register it as a component:
// Somewhere where the field is being used, or where it's been imported from
import Vue from "vue";
import fieldAwesome from "./fieldAwesome.vue";

Vue.component("fieldAwesome", fieldAwesome);

@jewbetcha is correct - Custom fields need to be registered globally.  We may have a fix for this in VFG v3 with a built-in registration system, but not in v2.


Update LICENSE_HEADER.md

Just adding some copy and paste ability for the generic header.

Description
Adding some more examples that include the comment tokens for the generic licence header.
Motivation and Context
Had to go and open an editor add the comments, then copy and paste thought I would save some people some time.
How Has This Been Tested?
I copy and pasted from the preview :D
Screenshots (if appropriate):
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] I have signed the Adobe Open Source CLA. (I am an adobe employee, so don't think I have to?)
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Thanks @jaredwy


How to save current tab's scene and state?

Version
Tell us which versions you are using:

react-native-router-flux v3.38.0
react-native v0.42.3

Expected behaviour
In my one tab, I have nested scenes and I want to save my current scene and state for that tab when I switched to other tabs then came back to the first tab.
Actual behaviour
Switching between tabs lose route scenes in that specific tabs.

Check out Issue 1686


[BUG] fatal error LNK1104 in Windows 10 GH agent while building Cython Plex Scanners

Hello,
I am not sure this is the right place for this bug report, please forgive me if I am creating this issue in the wrong place.
A build in GitHub Workflows that used to work 10 days ago building a Cython extension (and that is still working with Python 3.7 and Python 3.8), started failing only with Python 3.9 and only on Windows agents.
The error is happening when installing Cython.
I am opening the bug report here because it's related to Cython\Plex\Scanners.obj - I didn't see any existing issue related to Python 3.9
    creating build\temp.win-amd64-3.9\Release\Users\runneradmin\AppData\Local\Temp\pip-install-hn2vpsc8\cython_a04d89e9f611470cb057e2699b376df3\Cython\Plex
    C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.28.29333\bin\HostX86\x64\cl.exe /c /nologo /Ox /W3 /GL /DNDEBUG /MD -Ic:\hostedtoolcache\windows\python\3.9.0\x64\include -Ic:\hostedtoolcache\windows\python\3.9.0\x64\include -IC:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.28.29333\ATLMFC\include -IC:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.28.29333\include -IC:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um -IC:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\ucrt -IC:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\shared -IC:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um -IC:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\winrt -IC:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\cppwinrt /TcC:\Users\runneradmin\AppData\Local\Temp\pip-install-hn2vpsc8\cython_a04d89e9f611470cb057e2699b376df3\Cython\Plex\Scanners.c /Fobuild\temp.win-amd64-3.9\Release\Users\runneradmin\AppData\Local\Temp\pip-install-hn2vpsc8\cython_a04d89e9f611470cb057e2699b376df3\Cython\Plex\Scanners.obj
    Scanners.c
    C:\Users\runneradmin\AppData\Local\Temp\pip-install-hn2vpsc8\cython_a04d89e9f611470cb057e2699b376df3\Cython\Plex\Scanners.c(3534): warning C4996: '_PyUnicode_get_wstr_length': deprecated in 3.3
    C:\Users\runneradmin\AppData\Local\Temp\pip-install-hn2vpsc8\cython_a04d89e9f611470cb057e2699b376df3\Cython\Plex\Scanners.c(7925): warning C4996: '_PyUnicode_get_wstr_length': deprecated in 3.3
    C:\Users\runneradmin\AppData\Local\Temp\pip-install-hn2vpsc8\cython_a04d89e9f611470cb057e2699b376df3\Cython\Plex\Scanners.c(7941): warning C4996: '_PyUnicode_get_wstr_length': deprecated in 3.3
    C:\Users\runneradmin\AppData\Local\Temp\pip-install-hn2vpsc8\cython_a04d89e9f611470cb057e2699b376df3\Cython\Plex\Scanners.c(8416): warning C4996: 'PyUnicode_FromUnicode': deprecated in 3.3
    C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.28.29333\bin\HostX86\x64\link.exe /nologo /INCREMENTAL:NO /LTCG /DLL /MANIFEST:EMBED,ID=2 /MANIFESTUAC:NO /LIBPATH:c:\hostedtoolcache\windows\python\3.9.0\x64\libs /LIBPATH:c:\hostedtoolcache\windows\python\3.9.0\x64\PCbuild\amd64 /LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.28.29333\ATLMFC\lib\x64 /LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.28.29333\lib\x64 /LIBPATH:C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\lib\um\x64 /LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.19041.0\ucrt\x64 /LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.19041.0\um\x64 /EXPORT:PyInit_Scanners build\temp.win-amd64-3.9\Release\Users\runneradmin\AppData\Local\Temp\pip-install-hn2vpsc8\cython_a04d89e9f611470cb057e2699b376df3\Cython\Plex\Scanners.obj /OUT:build\lib.win-amd64-3.9\Cython\Plex\Scanners.cp39-win_amd64.pyd /IMPLIB:build\temp.win-amd64-3.9\Release\Users\runneradmin\AppData\Local\Temp\pip-install-hn2vpsc8\cython_a04d89e9f611470cb057e2699b376df3\Cython\Plex\Scanners.cp39-win_amd64.lib
    LINK : fatal error LNK1104: cannot open file 'build\temp.win-amd64-3.9\Release\Users\runneradmin\AppData\Local\Temp\pip-install-hn2vpsc8\cython_a04d89e9f611470cb057e2699b376df3\Cython\Plex\Scanners.cp39-win_amd64.exp'

If this can be interesting for you, please find here the link to a recent build that started failing: build run.

Cython==0.29.14
Python 3.9
Windows 10 agent in GitHub Actions

I suppose the problem is within the GH Agent itself, but it might still be relevant for Cython.

I'm not sure exactly why you're having this issue but if it's blocking anything important you could add --install-option="--no-cython-compile" to the Cython line in your requirements.txt. Cython doesn't need to be compiled to run, and you may well be wasting more time compiling it than you're saving by having a compiled version.

Thank You! The build works using the solution you recommended. When it comes to compiling Cython itself, I think it's something that changed in the Windows agent here in GitHub or maybe Python 3.9 minor release. I'll close this issue.


[SPARK-41567][BUILD] Move configuration of versions-maven-plugin to parent pom

What changes were proposed in this pull request?
SPARK-41544 make test-dependencies.sh to use specified version of versions-maven-plugin to run build/mvn versions:set command,  but except for
test-dependencies.sh, release-build.sh and release-tag.sh also use the build/mvn versions:set command.
release-build.sh:
https://github.com/apache/spark/blob/90120f0ae4b472e2517c8288ea53baf6bcb38c22/dev/create-release/release-build.sh#L420
https://github.com/apache/spark/blob/90120f0ae4b472e2517c8288ea53baf6bcb38c22/dev/create-release/release-build.sh#L445
release-tag.sh:
https://github.com/apache/spark/blob/90120f0ae4b472e2517c8288ea53baf6bcb38c22/dev/create-release/release-tag.sh#L77
https://github.com/apache/spark/blob/90120f0ae4b472e2517c8288ea53baf6bcb38c22/dev/create-release/release-tag.sh#L99
So this pr move the configuration of versions-maven-plugin to parent pom to make the whole Spark project use same version of versions-maven-plugin.
Why are the changes needed?
Make the whole Spark project use same version of versions-maven-plugin
Does this PR introduce any user-facing change?
No
How was this patch tested?
Pass GitHub Actions and manually check the script is executable

Thanks @dongjoon-hyun


ukmm: 0.11.1 -> 0.12.1

Description of changes
https://github.com/NiceneNerd/UKMM/releases/tag/v0.12.1
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

fails to run for me (I'm on x11)
$  results/ukmm/bin/ukmm
thread 'main' panicked at /build/cargo-vendor-dir/xkbcommon-dl-0.4.2/src/x11.rs:59:28:
Library libxkbcommon-x11.so could not be loaded.
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
An unrecoverable error occured. Error details: Library libxkbcommon-x11.so could not be loaded.

Oh thanks for the heads up! I haven't been testing this on X11. It looks like the dependency was added in 0.10.1 -> 0.11.0: https://github.com/NiceneNerd/UKMM/pull/166/files#diff-13ee4b2252c9e516a0547f2891aa2105c3ca71c6d7a1e682c69be97998dfc87eR5764-R5775

Sorry the first force push was from the wrong base commit and left off the update commit - it should be good now though!

thank you


[maistra-2.2] OSSM-1206: Make ServiceEntries with duplicated host names reachable

This is a backport of @yannuil's commit from upstream.
I had to slightly refactor this implementation, because service entries in Istio 1.12.z have only IPv4 address.

/retest

/retest


Sql backend

What this PR does
Fixes #40. In this PR, I provide the foundations for pacsanini to have a SQL backend. Overall, I have implemented all what was set out in #40 except for the C-MOVE part. This is because the integration of a SQL backend would necessitate the Storescp server to support plugins/callbacks (see #8 ). Once this is possible, I will create an issue that will have the C-MOVE operations be compatible with the C-MOVE backend.
SQLAlchemy is now a new dependency of the project. I have also added their license in the LICENSES folder.
Submission checklist

[x] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
[x] I have updated the documentation.
[x] I have updated relevant tests, if applicable.
[x] I have listed any additional dependencies that are needed for this change.

Thank you for contributing!

A minor change was made in the pacsanini.db.crud.DBWrapper.conn method so that the functools.lru_cache call would become compatible for python 3.7+


fix vulnerability in istio proxy_init image.

Similar to https://github.com/istio/istio/pull/8494
Fix vulnerability issues in istio proxy_init image:

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: greghanson
If they are not already assigned, you can assign the PR to them by writing /assign @greghanson in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pilot/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: gyliu513
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: greghanson
If they are not already assigned, you can assign the PR to them by writing /assign @greghanson in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pilot/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@morvencao: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e-envoyv2-v1alpha3.sh
c592b331b7af7088f367a750702c6fef25802a5b
link
/test istio-pilot-e2e-envoyv2-v1alpha3

prow/istio-pilot-multicluster-e2e.sh
c592b331b7af7088f367a750702c6fef25802a5b
link
/test istio-pilot-multicluster-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: gyliu513, sdake
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: greghanson
If they are not already assigned, you can assign the PR to them by writing /assign @greghanson in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pilot/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/test istio-pilot-e2e-envoyv2-v1alpha3

/assign @greghanson

@GregHanson can you give this an /approve?
Cheers
-steve

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: gyliu513, linsun, sdake
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pilot/OWNERS [linsun]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@morvencao should we create a PR for this in 1.0 too?

@linsun +1 to cherry-pick this to 1.0, but one question is if we chery-pick some fixes to 1.0, do we need to increase the chart version? Based on helm chart policy, the chart version should be updated if there are new changes to a released chart.
@sdake @costinm for more comments for how to maintain the chart version.

what is the issue of getting this in 1.0.3 and use 1.0.3 as the chart version?  Sorry I'm not understanding your concern.


Feature Request: support assertions in failFast condition

The introduction of untilAsserted() was great, because intermediate states that don't cause outright failure can be logged with .conditionEvaluationListener(), eventual failures are obviously reported as well, but failFast() conditions still only have access to a Predicate, which comes out as Fail fast condition triggered (not very informative), and optionally a hardcoded String error message, which is better, but still tells me nothing about the actual problem.
It would be great if failFast() could be overloaded to accept an assertion lambda as well, which would then report the assertion message in case of failure, allowing much greater detail in the error message. Another option would be failFast(Supplier<String> errorMessageSupplier, Callable<Boolean> condition), which would also allow me to construct a more detailed failure reason after the fact, when actual failure parameters are known.
In my particular case I am trying to assert that a workflow with many steps completes some number of steps successfully, with a failFast condition if the workflow itself fails. Something along the lines of:
await()
    .atMost(1, MINUTES)
    .failFast("workflow failed", this::isWorkflowFailed)
    .untilAsserted(() -> stepShouldBeSuccessful("firstStep"));
await()
    .atMost(1, MINUTES)
    .failFast("workflow failed", this::isWorkflowFailed)
    .untilAsserted(() -> stepShouldBeSuccessful("secondStep"));
...

but if the workflow ever does fail, then the await() call that was in progress doesn't report the most recent assertion error, only workflow failed or Fail fast condition triggered, both of which are kinda useless. I'm having to work around this by catching the TerminalFailureException and logging the particular failure myself, which I feel should be the responsibility of an assertion.
If I could instead write
await()
    .atMost(1, MINUTES)
    .failFast("workflow failed", this::workflowShouldBeRunning)
    .untilAsserted(() -> stepShouldBeSuccessful("firstStep"));
...
void workflowShouldBeRunning() {
    assertThat(workflow.get("phase"))
        .overridingErrorMessage(() -> "Workflow failed. Last known state:\n" + workflow.toPrettyString());
        .isNotEqualTo("Failed");
}

that would be great.

I agree that this would be nice. Currently I am "simulating" this by:
await()
    .atMost(1, MINUTES)
    .failFast(() -> {
        assertThat(...);
        return false;
      })
    .untilAsserted(() -> <...main assertions...>);

That's a neat idea. I might steal that for myself until this gets implemented. I might even wrap it in a utility method, along the lines of:
await()
    .atMost(1, MINUTES)
    .failFast(ifAssertionFails(this::shouldSatisfySomeProperty)
    .untilAsserted(() -> <...main assertions...>);
}
...
static Callable<Boolean> ifAssertionFails(ThrowingRunnable r) {
  try {
    r.run();
    return true;
  } catch (Exception e) {
    LOG.error(e.getMessage(), e);
    return false;
  }
}

This is a great idea.

I have like an hour or so, I'll see what I can do.

It should work now!


Introduce AsyncWriter which batches and transmits entries in the background

This is an attempt to address issue #898 by providing a way for Logger to make non-blocking calls. Please feel free to critique the approach. The idea is to provide an object that queues up log entries and writes them in batches from a background thread.

@blowmage @quartzmo Wanted to see what feedback you have on this.
So far I've heard from Mike that: currently the Logger still uses blocking calls by default, and you have to opt-in to use AsyncWriter's non-blocking calls. Sounds like Mike would rather Logger use non-blocking by default. That SGTM, I can do that. (Project#logger would by default first create an AsyncWriter and then use it to construct the Logger.)
Anything else?

I do think this should be the default behavior of the Ruby Logger provided by Google Cloud Logging. I can't think of a reason why we would not want this, as long as it doesn't load GRPC into a rails app's main thread. Seems like a win to me.

@dazuma Sorry for the delay in responding. I also like the idea of the Logger being non-blocking by default, since it sounds like the right choice for most users. For cases in which it is not the right choice, what do you think about adding documentation that discusses environments in which the background thread likely won't work, and what steps (if any) must be taken to switch to blocking calls (or some other possible workaround)?
For example, I'm wondering about deployments on Unicorn (see Implementing worker threads in Rails - Forking Servers.) But is this even a valid scenario? What are the deployment scenarios in which application might want to write to Stackdriver Logging?

Thanks Mike and Chris. I'll update the PR to make Logger use non-blocking calls by default (unless explicitly configured otherwise). I'll also investigate the forking issue and come up with a resolution. Yes, using Unicorn is a valid use case, as are threaded servers like Puma.

There are some interesting errors in the Travis CI build, linked above.
For example:
  1) Error:
Google::Cloud::Logging::AsyncWriter::mock_logging#test_0001_writes a single entry:
ThreadError: current thread not owner
    /Users/travis/.rvm/rubies/ruby-2.1.9/lib/ruby/2.1.0/monitor.rb:246:in `mon_check_owner'
    /Users/travis/.rvm/rubies/ruby-2.1.9/lib/ruby/2.1.0/monitor.rb:147:in `broadcast'
    /Users/travis/build/GoogleCloudPlatform/google-cloud-ruby/google-cloud-logging/lib/google/cloud/logging/async_writer.rb:150:in `block in write_entries'
    /Users/travis/.rvm/rubies/ruby-2.1.9/lib/ruby/2.1.0/monitor.rb:211:in `mon_synchronize'
    /Users/travis/build/GoogleCloudPlatform/google-cloud-ruby/google-cloud-logging/lib/google/cloud/logging/async_writer.rb:143:in `write_entries'
    /Users/travis/build/GoogleCloudPlatform/google-cloud-ruby/google-cloud-logging/test/google/cloud/logging/async_writer_test.rb:68:in `block (2 levels) in <top (required)>'

@quartzmo Yeah I noticed. Turns out I'd used the wrong method to test thread status. Should be fixed now.

Just wondering (don't consider this a request by any means), but would it be possible and would there be any value in a mechanism that would force the AsyncWriter to block while it writes its entire queue to the backend? Something akin to flush...

Do you want to add a sentence or two about the background thread to the Logging guide section on writing entries?

Re: an AsyncWriter#flush call. It's possible, but there are several possible semantics, and without some use cases it's not yet clear to me which is the useful one.
For example: If the semantics are that the queue is empty when the call completes, then it would have to block not only the call itself, but also any other concurrent calls to write_entries (which could otherwise cause the call to take an arbitrary amount of time by continually adding to the queue.) Alternatively, we could get around that issue by weakening the guarantee: for example, that only the entries added previously by the same thread have been flushed.
I'll take a look at the guide.

Re: AsyncWriter#flush, sounds good, I just wanted to bring up the idea since it occurred to me. I don't think it needs to be done for this PR. Thanks for the thoughtful answer!

@dazuma Hmmm, your additions to the guide make perfect sense, but I now wonder if the existing content needs to be revised. The problem is that under the heading "Writing log entries", we offer logging.write_entries entry as the preferred approach. However, this now feels like a lower-level usage that gets underneath the new preferred mechanism of the AsyncWriter. The following section, "Creating a Ruby Logger implementation", is more in the spirit of easy async logging that just works. Should we move this section above "Writing log entries", and begin it with the vanilla (canonical) async example, then discuss setting async_writer: false, and then follow with the lower-level discussion about write_entries?
If this is a bit hard to follow, I can easily provide a gist with the edits.

@quartzmo I'm actually inclined to leave the guide's flow as it is, with AsyncWriter and the Logger implementation as secondary to the "raw" API. My reasoning:

All the other google-cloud-* libraries are focused on being a client for the API first. Logging is a bit special in that it also offers integration with the standard Ruby logging "framework" (i.e. the Logger class). However, that capability could arguably be more closely connected with what we're doing on the stackdriver side (i.e. integrating with Rails and other frameworks). It doesn't fit as well with the overall paradigm of being an API client, so I'm hesitant to put it front and center in this library.
AsyncWriter, although it's perhaps "preferred" in that it's non-blocking, still involves increased complexity over logging.write_entries simply because you have to think a bit about concurrency (e.g. the fact that you don't get errors back from your API calls.) It also covers only a subset of the API (write_entries only, not any of the query methods). As such, I also think it's better considered an optional add-on rather than putting it first.

That said, maybe just one or two sentences at the top of the guide to the effect of "if you just want to log to the google logging service, consider the Logger class described further down; otherwise read on to learn about the API client" would accomplish what you're looking for? What do you think?

@dazuma Makes sense, I think you're right! We can keep the focus on the simpler, lower-level usage, and then explain the more complex options. Adding a couple of opening sentences to provide context sounds good.

Sounds good, I'll make those additions.

LGTM! I'll give @blowmage the chance to review and merge, however.

Thanks again @dazuma, this is really impressive work!!!


CORS Issue after Implementing Watchdog

Description
It looks like Watchdog Overrides the CORS policy defined, so I am getting CORS Error for each API Calls
string WatchDogUserName = builder.Configuration.GetSection("WatchDog:WatchDogUserName").Value.ToString();
string WatchDogPassword = builder.Configuration.GetSection("WatchDog:WatchDogPassword").Value.ToString();
app.UseWatchDogExceptionLogger(); // Add Exception logging
app.UseWatchDog(options =>
{
    options.WatchPageUsername = WatchDogUserName;
    options.WatchPagePassword = WatchDogPassword;

});

If I Comment above line the CORS policy issue disappeared and APIs are working fine on the Origins which are defined in the CORS Policy
Project Type: Web API
Framework Version [.NET 6]
WatchDog Version [1.3.2]
Database [Default]

Hi @shyamjith-fingent
Have you tried switching the middleware order?
Let app.UseCors() come before/after watchdog middleware
If that doesn’t work, share a sample of your middleware order and cors policy so we can replicate on our end and fix if necessary

@IzyPro : The issue is weird , It started working after adding app.UseCors()  before and after  watchdog middleware

Hi @shyamjith-fingent
A new property (CorsPolicy) has been added to .UseWatchDog() in the just released v1.3.3 that let’s you pass the name of your policy
Do check it out and let us know how it goes


Focus issue on version prior to Mojave ?

I've seen a weird bug on my old Macbook Air that's stuck on 10.13.6. When you open Aerial preferences, the preferences sheet doesn't have focus. The biggest hint is that the tab bar is grey instead of blue (in focus) :

This used to be of little impact in older versions, but with more recent ones, apart from the color thing, you simply can't type in any text field, which is an issue for custom messages, brightness duration and longitude/latitude.
Does anyone else experience this on any version of macOS prior to Mojave or is it just on my system ? I've rolled back to 1.2 and the issue was already there, I tried a few things to fix it but no luck.

Interesting, hopefully we'll get more data on this !

Yes I don't know why it works that way🤨

I too am seeing this problem on my iMac17,1 (Retina 5K, 27-inch, Late 2015) in macOS 10.13.6.

Thanks for confirmation. Been trying to look onto that one all day with no success so far.

Please see here for the workaround : https://github.com/JohnCoates/Aerial/issues/606#issuecomment-434813082


add script_runner method in fuels-test-helpers

I added script_runner method in fuels-test-helpers so it can be used in SDK testing.

Add a section in the book about running a simple script please!


Picture orientation detection not working for iPhone Selfie Camera

If you want to use the automatic ratios for cropping and the source is a iPhone selfie camera picture mantis only suggest rations for landscape pictures, even if source is a portrait one. Also the usage of “original”-ratio use a landscape one.

@cfmedicus
Thanks for pointing it out.
I will fix it in the next release.

It is fixed in Mantis 2.15.0.


Unsupported engine version in GKE Deployment template

Describe the bug
GKE Deployment template uses unsupported version of GKE engine (1.9.7-gke.1) which causes GKE Deployment to fail.
Expected behavior
Following Quick start guide should not result in an error.
Steps to reproduce the bug

Follow instructions in https://istio.io/docs/setup/kubernetes/quick-start-gke-dm/
Section https://istio.io/docs/setup/kubernetes/quick-start-gke-dm/#launch-deployment-manager step 1 launches GKE Deployment manager with template https://raw.githubusercontent.com/istio/istio/release-0.8/install/gcp/deployment_manager/istio-cluster.jinja. This template uses GKE engine version 1.9.7-gke.1

Deployment fails with the error
master version "1.9.7-gke.1" is unsupported
Equivalent command-line option gcloud container clusters create istio-quick-start --cluster-version=1.9.7-gke.1 --zone europe-west4-b --num-nodes 3 fails with the same error.
Changing GKE version to 1.9.7-gke.3 solves the problem, so it looks like the template used by the QuickStart needs to be updated.
Version
Istio 0.8.0
Is Istio Auth enabled or not?
MTLS is disabled, RBAC is disabled
Environment
Google Cloud

@ymesika I ran into this issue today, I pulled and configured for 1.10.4-gke.2. What do you think about upgrading the PR to match with latest? Perhaps it will be supported for longer than 1.9.7-gke.3, although the rate goggle is going this might be void.

@ymesika I don't think there is such thing as a LTS GKE, see https://cloud.google.com/kubernetes-engine/versioning-and-upgrades

@ymesika Some people are saying that 1.10 is not supported, I found that the following two bugs have been resolved taken from the notes:
# NOTE: Due to a bug in kubectl (https://github.com/kubernetes/kubectl/issues/384
# https://github.com/istio/issues/issues/261) we have to force an earlier
# version of kubectl than 1.10.0.

I am spinning up another GKE cluster using latest, it did work so I will test and give feedback here.

Thanks @apettey.
I meant that maybe we specify just a major version instead of being very picky about the exact one.
I believe that minimum requirement for 1.0 will be 1.9 so we can just use that tag.

To finalize, everything works great right now using latest instead of 1.9.7-gke.3 and 1.10.4-gke.2. General tests and everything is running, this is still using kubectl 1.9.6.
My view is that latest can be considered a bit dangerous however with the current upgrade paths of Kubernetes and GKE it is more than likely the best solution right now. Short term it will reduce the number of PR's for each version of GKE that is deprecated.

With #6909 we will get in 1.0 the latest available 1.9.


[DR-3369] ApiClients share RestTemplates

https://broadworkbench.atlassian.net/browse/DR-3369
Each DrsProvider will still have new ApiClients made on request, but now they will all share the same backing RestTemplate. This brings behavior in line with the caching present at our last successful scale test in August '23, without sharing headers between requests (the impetus for the rollback).
Performance Testing
Note: our most recent 20k DRS URI dev-tier scale test in Grafana shows a peak request rate of 54 requests / second.
I added in two new performance test configurations for testing 50 and 100 concurrent TDR DRS URI resolution user journeys, respectively.
These performance tests can be run off of a local DrsHub (I filed https://broadworkbench.atlassian.net/browse/DR-3380 in response to the discovery that DrsHub perf deployment no longer exists).
I saw modest improvements to latency when running these tests off of this feature branch versus running them off of dev, assessed via running curl http://localhost:9098/actuator/prometheus | grep /api/v4/drs/resolve after completion.  This is enough to feel comfortable moving forward with merging this PR but as the infrastructure and test are different enough from the workflow scale test, I am not positive what the outcome of that test will be after merge.

Note: CodeCov has flagged that unit test coverage has gone down in this PR.  I've reviewed the report, and the driving factor here is breaking out RestTemplate creation into RestTemplateFactory and mocking it in DrsApiFactoryTest rather than calling the real methods.
https://app.codecov.io/gh/DataBiosphere/terra-drs-hub/pull/92
I do not see how the existing coverage provided us with real value, and also don't think that writing RestTemplateFactoryTests to make up the coverage would provide us with real value either.  RestTemplate creation is an opaque process and we'd be limited in our ability to verify behaviors.
So, I'd like to merge anyway despite the drop in coverage.  But please let me know if you have other preferences!  CC: @pshapiro4broad , @nmalfroy , @samanehsan

Thanks for looking.  I'm ok with going ahead and merging. I agree that sometimes the code cov ratchets aren't helpful and this is one of those cases

I'm also OK to override the codecov warnings for this PR.


Removed old links, updated Linux info, spelling

Fixes
Description of the changes:

Linux is now supported, so updated that
Removed links to old download info
"proprietary" was misspelled

Before submitting a Pull Request:

[x] I reviewed CONTRIBUTING.md
[ ] I built my changes locally
[ ] I ran the unit tests
[ ] I ran the functional tests with a device
[ ] I ran the performance tests with a device

I tested changes on:

[ ] Windows
[ ] Linux

/azp run


Does not encode / into %2F

Given:
var encodeUrl = require('encodeurl')

const token = "ylq421jn47GHAW/4qa%){}S881";

encodeUrl(token)

Result:
ylq421jn47GHAW/4qa%25%29%7B%7DS881

/  should be encoded to -> %2F
Should be encode to:
ylq421jn47GHAW%2F4qa%25%29%7B%7DS881

That is correct, it only encodes what is outlined in the readme.

Oh sorry! Thanks. Good hint to add the label "question", for someone else I can suggest the following library https://medialize.github.io/URI.js/docs.html#static-encode to encode a token complete.


$.extend - TypeError: setting a property that has only a getter

Hello,
I have the following DOM element selected with cash 1.0.0:
var baseElement = $(".editform");

and further down the line I need to change css on elements inside the element. Doing this with jQuery was by using find as I'm trying to do with cash:
baseElement.find(".plain").css({display: "none"});

When this script executes the following errors are reported:
Firefox
...reports the following error: TypeError: setting a property that has only a getter in $.extend (https://github.com/kenwheeler/cash/blob/master/src/util.js#L27)
Chrome
Uncaught TypeError: Cannot set property length of #<NodeList> which has only a getter
cash.extend.fn.extend @ cash.js:91
fn.extend.find @ cash.js:602
enableEditMode @ bidrageditor.js:17
toggleEditMode @ bidrageditor.js:12
onclick @ (index):56

Does this still happen if you dont call the css method?


Building DBeaver with correct execution environment / JDK?

Description
For updating DBeaver on Void Linux I had to update the Java version from openjdk11, so I picked the latest available on Void, openjdk17. Now the build log is full of this type of warnings:

[INFO] --- tycho-compiler-plugin:3.0.0:compile (default-compile) @ org.jkiss.dbeaver.ext.test ---
[WARNING] Using JavaSE-17 to fulfill requested profile of JavaSE-11 this might lead to faulty dependency resolution, consider define a suitable JDK in the toolchains.xml

The build succeeds, but looking at this Tycho issue, I think this shouldn't happen?
DBeaver Version
Community Edition 22.2.3
Operating System
Void Linux
Database and driver
N/A
Steps to reproduce
Build with mvn package -P all-platforms (as in the Void build template).
Additional context
No response

Hi @ar-jan,
Thank you for the report. We're aware of these warnings. We're working on it.
At the same time, want to assure you that these warnings do not interfere with the DBeaver successful builds and stable work.


unsupported operand type

Hello
I have one more error message from breakmer that I am reporting here
Traceback (most recent call last):
  File "/extscratch/apps/BreaKmer/breakmer.py", line 71, in <module>
    RUN_TRACKER = breakmer_analysis.RunTracker(params.ParamManager(PARSER.parse_args()))
  File "/extscratch/apps/BreaKmer/breakmer/params.py", line 51, in __init__
    self.set_params(arguments)
  File "/extscratch/apps/BreaKmer/breakmer/params.py", line 105, in set_params
    self.set_insertsize_thresh()  # Set the expected insert size threshold from the properly mapped read pairs.
  File "/extscratch/apps/BreaKmer/breakmer/params.py", line 263, in set_insertsize_th
resh
    isSD = utils.stddev(utils.remove_outliers(insertSizes))  # Calculate the standard deviation of the sample read pairs inser
t sizes.
  File "/extscratch/apps/BreaKmer/breakmer/utils.py", line 95, in remove_outliers
    H = 1.5 * (qnt2 - qnt1)
TypeError: unsupported operand type(s) for -: 'NoneType' and 'NoneType'

any ideas ?

anything on this issue ?

Which release of Breakmer are you running?  Can you send me a copy of your config file?


unsupported signal SIGQUIT

C:/Ruby192/lib/ruby/gems/1.9.1/gems/shotgun-0.9/bin/shotgun:142:in `trap': unsupported signal SIGQUIT (ArgumentError)
    from C:/Ruby192/lib/ruby/gems/1.9.1/gems/shotgun-0.9/bin/shotgun:142:in `block in <top (required)>'
    from C:/Ruby192/lib/ruby/gems/1.9.1/gems/shotgun-0.9/bin/shotgun:141:in `each'
    from C:/Ruby192/lib/ruby/gems/1.9.1/gems/shotgun-0.9/bin/shotgun:141:in `<top (required)>'
    from C:/Ruby192/bin/shotgun:19:in `load'
    from C:/Ruby192/bin/shotgun:19:in `<main>'

This is what I get when running shotgun on Win 7 x64.

Sorry, Shotgun isn't supported on Windows. If you can come up with something, I'd love to see it.

I'm having this issue.
Since SIGQUIT is a problem in windows could this method be used in shotgun: stereobooster/guard@cbe2cb353c82ce38caf3f58185dd7fb46897f554 ?


Add disable flag to shared sg customizer

This flag allows the shared sg to be disabled in yaml

LGTM; feel free to ignore my comment - no strong feelings. Will merge once jenkins finishes.


Allow external psql database support

At present chart does not allow to easily use external database - it requires overwriting of $ENV variables.
This feature adds support for external PostgreSQL database.

@redzioch: I have implemented this feature in #134 in another way. Please see this blog post to understand the reasons why.


DOC: add agg nunique example

[NA] Tests added / passed
[NA] Passes black dask / flake8 dask

Closes #6280

Friendly ping

This looks great! Thanks @raybellwaves!


chore: update stylelint dependency

Update to stylelint 11.0.0 (latest, see changelog) to avoid unknown rules error due to new introduced rules in v11

The test fails here.
I guess due to the new introduced rules in v11.
Could you please check?

The broken unit test is due to a change in how stylelint inform about unknown rules. Instead of emitting an error, it now emits warnings.
I fixed the unit test, however I don't want to mess up the discussion by creating a new branch or pull request. @fuhlig here is the diff to solve the test, and I can commit the changes in your branch if you like.
unit-tests.patch.zip

Added you as a collaborator. I could commit it as well, but you did the work and know what happened and can set the commit message accordingly ;)
Thanks for the effort, good job!

Hi guys,
Any update on this?
I'm looking forward to this update and am happy to help if time is an issue.

The PR is blocked by the decreased code-coverage if I'm not mistaken.
Eventhough I opened the PR to update the dependency, it required work on the tests by @shinnn and @alejandroclaro so I can't do much here right now.

@shinnn The changes are ready, the coverage has been fixed. Could you take a look to the PR, please?

Looks like @shinnn may unfortunately have abadoned their Github account (or, hopefully, is just taking a break from it) in the wake of this incident. Their account hasn't been active since then:

They also appear to have deactivated their Twitter account.
This PR is pretty essential to me as well -- wondering if it's worth considering forking this? Unfortunately stylelint-vscode and vscode-stylelint would need to be forked, and the former would need to be republished as a new extension (or someone would need to report the issue to whoever's maintaining the VS Code extension registry).

@reflector-six Thank you for the detailed update!

Thanks for the update.
I'm afraid that the vscode extensions will be out of date soon as stylelint is pretty well maintained with regular major updates which might cause incompatibility issues.
I'm not firm with the licenses, but would it be possible to fork the repos and re-distribute / publish them to npm and the extension registry?
If the dust settles on the inactivity of the original maintainer, it might continue as before.

The license states that we can modify it as long as we keep the original license.

So what do you think how we should proceed?

Notwithstanding a clear way to contact @shinnn beyond the mentions we've already tried to send, probably a fork is the way to go? I unfortunately won't have time to contribute to setting it up, but maybe someone else can?
As for the Marketplace extension listing, I think the "Report" link on the extension page is the email to contact to ask how to proceed. I suspect they'll suggest pushing a new extension rather than handing over the existing one, but who knows.

FWIW: To manually update stylelint in the VS Code extension:

cd ~/.vscode/extensions/shinnn.stylelint-0.51.0/node_modules/stylelint-vscode
npm i stylelint@latest

Looks like this issue is unfortunately getting progressively worse, with the release of stylelint@12 in the past few days.
For anyone considering forking this, instead of bundling a version maybe the ideal approach would be to require stylelint to be installed either locally or globally, like vscide-eslint does.


Spike:  Getting access to sharepoint files via API

Description:
This ticket is to help refine #2160.  It is to test if we can do an api call to the sharepoint site so that we can ingest the master spreadsheet from there.

[x] Successful api call to sharepoint site where the master spreadsheet resides
[x] Refined #2160

A POC has been created in which the master spreadsheet is read from SharePoint. Nevertheless, authentication is currently not figured out but a mock authentication with a hard coded token is being used.
Uses Microsoft Graph API v1.0 using Sites, reference: https://learn.microsoft.com/en-us/graph/api/overview?view=graph-rest-1.0
Microsoft Graph also provides functionality to read Excel data directly without having to ingest the binary file and parse it with XLSX library using the worksheet endpoints, a demo of this is also included. Reference: https://learn.microsoft.com/en-us/graph/api/worksheet-usedrange?view=graph-rest-1.0&tabs=http
To get the data from SharePoint IDS need to be used for the site, document library (drive), workbook and optionally the worksheet (name also works for this). The mapping of this will placed on the Teams channel.

Currently blocked on authentication, waiting for CITZ IMB Ticket #85371.

Upon further investigation there are other avenues that can get this working, in order of less approvals:
Using a "delegated" approach

This is possible using the v1 and direct SharePoint connection, requires user to login to SharePoint before any requests can happen.
Would not allow automatic import but rather a "Click to import" on demand approach that can be triggered by users
Does not require any involvement from IT Support or any iStores, easy to implement

Using a "service account" IDIR

Allows direct authentication to SharePoint online, not clear if Graph or v1 SharePoint API would need to be used
Would likely require further approval due to the nature of the IDIR
Regular IDIR accounts cannot login through any "unmanaged" process

** Request an Azure Service Consultation **

iStore request for the Azure Client to be created
Cost unknown, would be consultation + implementation
Might be denied

Using a service account has been proven working, need to rework code to use SharePoint v1 API, no v2/Graph currently working as it requires an Azure Client to exchange token against which is currently not supported.
Moving this ticket to sprint done, starting work on #2213


Alternative colors for county chart

I tried used a diverging color scheme from https://colorbrewer2.org/#type=diverging&scheme=PiYG&n=5 but ended up revering to the original colors.
My main change was to pair the two reds and the two greens according to county, rather than according to data source. That way both the lines and the bars contrast more. Curious what you-all think, though - I've been known to make bad questionable design choices in the past.

For convenience, here are the two pngs:
Old:

Proposed:

@b-mohler any thoughts on whether this is an improvement?

@PhilipMathieu definitely! It looks perfect


arc-green theme code display bug

Gitea version (or commit ref): 1.12.5
Git version: 2.25.1
Operating system: Ubuntu 20
Database (use [x]):

[ ] PostgreSQL
[ ] MySQL
[ ] MSSQL
[ X] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[X ] No - appears to have been fixed in newer base.less style sheet

Description
The code lines don't line up with the line numbers when using Chrome and the Arc-Green theme. I've traced the problem down to Chrome's built in style-sheet using "vertical-align: inherit;" as default for the  tag. Adding the following css to the arc-green theme would resolve the issue.
.lines-code{vertical-align: top}
Screenshots
screen shot included

@wolfpackmars2 does this also happen for standard (non arc-green) theme?

no, only arc-green. Doesn't seem to happen on the test server running 1.14 dev - maybe fixed in a newer version?

I confirmed this is fixed in 1.13.0-rc1

@wolfpackmars2 awesome! thanks for checking :)


[BUG] weird translation error

in version 1.1 everything worked, in 1.2 these errors in the log:
2023-03-27 16:56:10,128 INFO    - Console window hidden. If it is not hidden (only minimized), try changing your default windows terminal to windows cmd. (Main.py:50) [MainThread]
2023-03-27 16:56:10,128 INFO    - Booting up... (Main.py:1019) [MainThread]
2023-03-27 16:56:10,254 DEBUG   - Available Theme to use: ['vista', 'sv-light', 'sv-dark'] (Main.py:157) [MainThread]
2023-03-27 16:56:10,254 DEBUG   - Setting theme: sv-dark (Style.py:28) [MainThread]
2023-03-27 16:56:10,273 DEBUG   - Setting custom dark theme style (Style.py:49) [MainThread]
2023-03-27 16:56:13,442 INFO    - Checking for update on start (About.py:100) [MainThread]
2023-03-27 16:56:14,118 INFO    - Checking for update... (About.py:125) [MainThread]
2023-03-27 16:56:14,431 INFO    - No update available (About.py:145) [Thread-5 (req_update_check)]
2023-03-27 16:56:35,352 INFO    - Start Process (FILE) (Record.py:1015) [Thread-6 (from_file)]
2023-03-27 16:56:35,399 DEBUG   - Translating... (Record.py:701) [Thread-7 (cancellable_tl)]
2023-03-27 16:56:35,400 DEBUG   - Translating with whisper (Record.py:714) [Thread-7 (cancellable_tl)]
2023-03-27 16:56:35,406 DEBUG   - Source Language: polish (Record.py:715) [Thread-7 (cancellable_tl)]
2023-03-27 16:58:48,499 ERROR   - string indices must be integers (Record.py:828) [Thread-7 (cancellable_tl)]
Traceback (most recent call last):
File "speech_translate\utils\Record.py", line 759, in cancellable_tl
File "speech_translate\utils\Helper_Whisper.py", line 44, in whisper_result_to_srt
TypeError: string indices must be integers
TL Wait (133.34s)
???

sorry, it seems like i put the wrong variable into the whisper_result_to_srt function. That's why it make that error
will fix asap

This should be fixed in the next release version (1.2.2)


Sketch-Plugin-Manage can't use proxy.

Description
Sketch-Plugin-Manage can't use proxy to download the plug-ins.
BTW:where are source code of Sketch-Plugin-Manager.app of the bundle? I wish i could modify and submit a pull requests.
OS X Version
[//]: # 10.12.6
Sketch Plugin Manager Version
[//]: # 1.6
Screenshot

Sorry I didn't get back to you sooner, it's been a while since I've been able to give this project my attention.
I don't believe there's anything that can be done to allow this to use a proxy. I'm using the Objective-Git library and I don't believe they have an option for that, but I could be wrong.
The Swift source code is in another repo that is private, but there's no reason why I couldn't open it up. The code is a bit messy as I was still learning some things when I wrote it, so you can look at it at your own risk :-) I'll try to open it up later this week after I fix some bugs and will let you know when that happens.


Running the code on a VPS with a cronjob

Hello,
I am aware this isn't the best place to ask this but I have no idea where else to do it.
I never used Java before, but I have plenty of experience with PHP. I managed to write the code and all is working fine on my Windows machine.
Now I need to put it on a VPS and have a cronjob run it every few seconds. I have an account with DigitalOcean so maybe I can do it there.
I'm not looking for a full tutorial, just need someone to point me in the right direction as I'm completely lost.
So how do I go about getting this code into a VPS and have it run automatically there?
Thank you!

Look at springboot.
It can run cron jobs.

install java 8
sudo yum install java-1.8.0
copy your jar across
 rsync -azv --progress -e "ssh -i [pem file]" [full path to jar] [ssh user]@[host dns name]:.
create a shell script that will start your jav process (give the correct exeuction permsisions to the user that will run it)
#!/bin/sh cd "[jar location]" source [any user profiles cat /dev/null > nohup.out PRGCOU=ps -eaf | grep -i java | grep [jar name] | grep -v grep | wc -l if [ $PRGCOU -eq 0 ] then java [java parmas and jar location] &  sleep 5 exit fi
open crontab editor
crontab -e
add a cron job to run every x mins
*/x * * * * [location of run script]


The links to download sticker sheets on the Resources page do not work.

The links to download the various sticker sheets do not work on the Grommet/Design/Resources page (http://grommet.usa.hp.com/docs/hpe/design/resources)

Fixed


Index reconstruction

Changing this to draft, because the index reconstruction in tezos does not work yet (it fails with stack overflow). I'll keep working on this, but if anyone wants to try the tezos branch to test this is here.

I've rebased this branch; now looking at integrating it with irmin-fsck. @icristescu, is there anything to block this from being merged?

I've rebased this branch; now looking at integrating it with irmin-fsck. @icristescu, is there anything to block this from being merged?

it's good for me 👍


show help page if dotnet sdk version is insufficient

If the user's SDK version wasn't sufficient an error toast is shown indicating that, but it can go unnoticed and isn't really actionable.  This PR will show a rendered markdown file that is more visible, has more information, and has actionable links.  Eventually this feature can be expanded to include a host of various fixes.
This will be particularly useful given that we're about to ship a version of the extension that will require a newer SDK.
Example:

Future work will be to detect multiple different issues and dynamically build a help page that can be used as a check list, but since the only issue we currently detect is a bad SDK, I opted to not add that complexity just yet.

NOICE SEND IT


Context id retrieval from native store is slow

See NativeSailStore line 542 and further - context identifiers are currently retrieved by scanning all triples, which is very inefficient. We should look into a separate cache or persistence mechanism to store context identifiers for quick reference/retrieval.

I'll have a look at implementing this in backward-compatible manner - the behavior is poor enough that I think we can consider this a bug.


the "open anchor app" button is not working

A User reported that they are unable to sign in to discussions.app via anchor desktop because the "Open Anchor App" in the sign in dialogue doesn't work.
They are running Arch Linux, Firefox, KDE Plasma 5.x and using Anchor 1.0.5

This is most likely due to https://github.com/greymass/anchor/issues/833, where the AppImage isn't working as it should. There's a manual fix in the issue, otherwise installing the deb version should work out of the box.
Until we get the AppImage fix, we'll probably stop publishing it because this is a pretty common problem people face.
Going to close this one out and keep #833 open until we get it fixed. Feel free to reopen this issue if the the neither of the above resolve the issue.


Added bond graphing

Closes #154
Discussion
Added bond graphing in mesh rendering graph (toggles will be added in next task)
Testing

[ ] Run build.sh and make sure new dependencies install in .venv
[ ] Open up the notebook (make sure using the .venv Python kernel)
[ ] Execute the cells, an in the meshes tab, toggle visibility of the atoms, making sure the bond lines are graphed properly.

Nice! I'm thinking we could add a bond menu option for visibility, its a little hidden rn.


Input zoom

On mobile, the inputs that get focused zoom in

This isn't an issue with Bubbles, just the suer setting content settings the html head


[terra-clinical-label-value-view] Update color to use rgba values instead of hex.

Summary
Updated secondary text colors to use rgba values instead of hex.

Closes #691
Deployment Link

https://terra-clinical-deployed-pr-#.herokuapp.com/
Testing

Additional Details

Thank you for contributing to Terra.
@cerner/terra

@saket2403 why are we making this change?


Stub not working

Somehow the following stub for an internal class of my cms doesn't work like expected. Normally I would bootstrap the cms with the include_once, so all internals are correctly loaded and set up. But even by using a custom autoloader, like described in the docs, and creating new instances of those classes the method isn't stubed.
Am I missing something here?
use kahlan\plugin\Stub;

// include_once "../index.php";

describe("Test Stubing", function() {

	it("should be saveable", function () {
		$page = new NullPage();
		$instance = new Pages();
		$reason = '';
		Stub::on($instance)->method('isSaveable')->andReturn(true);
		expect($instance->isSaveable($page, $reason))->toBe(true);
		var_dump($reason);
	});

});

string(39) "Pages of type NullPage are not saveable"
  ✘ it should be saveable
    expect->toBe() failed in `/spec/TrainerInvoices/TrainerInvoicesSpec.php` line 20

in kahlan-config.php
Filter::register('mycustom.namespaces', function($chain) {

	$this->autoloader()->addPsr4('', __DIR__ . '../wire/core');
	return $chain->next();

});

Filter::apply($this, 'namespaces', 'mycustom.namespaces');

Edit:
I've checked another class in my custom namespace and it got stubed without problem.

Patching only work inside classes loaded by Composer. For example if you try to Stub or Monkey patch something which has been loaded by a custom loader, it won't work. However if your project structure is PSR-0 compatible, disabling the custom autoloader and adding something like you did:
Filter::register('mycustom.namespaces', function($chain) {

	$this->autoloader()->addPsr4('', __DIR__ . '../wire/core');
	return $chain->next();

});

Filter::apply($this, 'namespaces', 'mycustom.namespaces');

It should work out of the box.
If you're still stuck, feel free to update your https://github.com/LostKobrakai/kahlan-debug-repo repo with your example so I can take a look.

I got it, thanks for your help and patience. The classes where still loaded because I had the same include statement in another spec file and not because of the autoloader correctly loading the files. I'll close this, but I've still one question:
If the autoloader does correctly detect those classes, can I still stub instances, which where instanciated somewhere in the cms, which (also) loaded the classes by a custom autoloader? All the classnames and paths and so on should be the same.

By default you'll be able to stub all classes loaded by the composer autoloader, i.e the ones defined in your composer.json file.
However if all classes your project are not managed by composer (not recommanded imo), you'll still be able to manually add some PSR-0/PSR-4 namespaces or class map through the kahlan config file.
Anyhow the easy way is to disable/remove all custom autoloaders and let composer do all the autoloading. All others situations will need to be solved on a case-by-case basis but may lead to some unnecessary extra complexity.


Bench nomad

New workbench backend based on nomad/podman
Add multi-backend support using make BACKEND=nomad shell
Using nix2container to build the OCI images for performance issues

This needs:

a description
history cleanup for the latter commits

bors merge


Provisioning improvements

Add active field to node
remove redundant latch from config,
synchronize master tasks by etcd cluster readiness

Coverage increased (+3.0%) to 41.385% when pulling 2080c2117eede5dee52b5799e76f1d9e8e079aa5 on stgleb:node_active into 11bbcf83168abee3087b0f6e4168a55aabd8fd0c on supergiant:master.


Can't solve "Cannot use import statement outside a module"

Describe the bug
When testing with jest it displays "Cannot use import statement outside a module"
To Reproduce
Steps to reproduce the behavior:
I added the library with npm install nordigen-node --save, wrote code to substitute direct API calls with the methods in the library as the quickstart guide showed, called them in my code and then proceeded in testing the files.
Expected behavior
I expected to solve this error by either adding type:module to package.json, installing babel/nodemon, or in general by specifying that the library must not be executed as a commonjs, but nothing solves the error
Screenshots

I have exactly the same problem, running in a node backend with typescript (nrwl + nestjs).

This issues is caused because of node-fetch starting from v3 is using only ESM modules, we replaced it with axios, could you try it again with the latest library version

Hey @victory-sokolov , trying it with 1.2.1 and having the same issue.

How can it take more than 3 Months to fix this issue?
Just use my fork or create your own fork and copy my last two commits...
npm install jannikhst/nordigen-node

@victory-sokolov Is there any update on this issue?
Happy to use @jannikhst fork for now but would be ideal to get this fixed.

Hi Nordigen Team - I've got my main developer completely stuck with this and as I understand it, it's a ten min fix at your end. Before we move over to Plaid, can we get a positive response that someone will be fixing this in the the next 48hrs pls?

@conor-deegan @ShivPool @sebastiankunn
Sorry for the delay. We've made a fix, could please try with latest version 1.2.2

Oh wow thank you Viktor! Conor will work on installation asap.
———————————
Shiv Malik
CEO
pooldata.io
+44 7843 248 134
———————————
Data For Everyone
On Thu, Feb 16, 2023 at 12:22 PM Viktor Sokolov @.***>
wrote:

@conor-deegan https://github.com/conor-deegan @ShivPool
https://github.com/ShivPool @sebastiankunn
https://github.com/sebastiankunn
Sorry for the delay. We've made a fix, could please try with latest
version 1.2.2
—
Reply to this email directly, view it on GitHub
https://github.com/nordigen/nordigen-node/issues/34#issuecomment-1433006458,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AVPBHG7TFP3T6FBC35XRVNDWXYLX3ANCNFSM6AAAAAASOONVG4
.
You are receiving this because you were mentioned.Message ID:
@.***>

@victory-sokolov , thank you.
There seems to be a small bug with accessing the types.
In current package.json, types is declared as:
"types": "dist/index.d.ts",

This leads to 'Could not find a declaration file for module 'nordigen-node'. '/Users/username/project/node_modules/nordigen-node/dist/index.cjs' implicitly has an 'any' type.
Try npm i --save-dev @types/nordigen-node if it exists or add a new declaration (.d.ts) file containing declare module 'nordigen-node';'
However, updating your package.json to:
  "types": "dist/types/index.d.ts",

works.
Could this be added?

@conor-deegan Thanks for noticing. Should be fixed now

@victory-sokolov  Working. Thank you


WIP: demo of attching metadata to Frames

@stuwilkins @danielballan
exploiting the pims md field (maybe)

Part of the goal of this handler_override is to avoid using this kind of thing. As I told @stuwilkins today, despite having adding this to PIMS myself, I have become skeptical of its value because it hard to propagate the metadata through mathematical operations. Better to carry about parallel structures.
So my advice is:

Try to capture all metadata in Events.
If you forget to include something, use handler_override to grab it out of the file.

Closing as maybe a bad idea.


Add option to allow absolute paths.

I'm using the latest release win64 binary and whenever i try to use any absolute file path i get
terminate called after throwing an instance of 'std::filesystem::__cxx11::filesystem_error'
  what():  filesystem error: cannot make absolute path: Invalid argument []
```
I made this issue because the other tool im using only outputs absolute paths and i felt like i might not be the only one with this issue.

I fixed up the logic for detecting absolute paths on Windows in 0b7fa7eb3ad097b17361b384d150ae4b78317449, previously it would construct a broken path otherwise when combining it with the current work directory.
However, I'm not sure if that is the issue that you are describing here. Please check whether your issue is resolved when using binaries from the latest CI run (available to logged-in users in the "Actions" tab, after selecting the latest run and downloading the artifacts archive). In case it isn't fixed, please elaborate on where and how you are using an absolute path that breaks the tool.

Still getting the error, this is what I'm trying to do, sorry for the vague initial issue.
C:\Users\USERNAME\Downloads\gmod-lua-runner-0.1.1-win64>runner.exe "D:\test.lua"
terminate called after throwing an instance of 'std::filesystem::__cxx11::filesystem_error'
  what():  filesystem error: cannot make absolute path: Invalid argument []

Looks like is not actually related to the path that is passed as an argument, but rather to the fact that getting the parent path of "runner.exe" results in an empty string, and Windows' implementation of "make this path absolute" considers that invalid.
In any case, please check again if this is fixed once the latest CI run finishes.

C:\Users\USERNAME\Downloads\gmod-lua-runner-0.1.1-win64>runner.exe D:\test.lua
Access is denied.

That is a local misconfiguration, your file permissions very likely aren't set properly. Neither switching to an elevated console nor disabling the antivirus will help with that.

Turns out my antivirus was still messing with it even after i turned it off, it quarantined it thinking it was a virus.
Works now though! thanks!


Use statically compiled amd64 kubectl v1.2

Install a statically compiled version of the kubectl amd64 version. Somewhere between kubectl 1.1.7 and 1.2.0, the build process changed. The 1.1.7 versions are dynamically linked with libc (which doesn't work on Alpine).
Switching to the amd64 version of kubectl 1.2.0 will fix the problem. This can be verified by using kubectl exec -it manager-XXXX sh and then running /bin/kubectl manually. That will when the manager instance has 1.1.7, but succeed if the manager has 1.2.0.

Yes, good catch. That issue was exposed by the move to alpine:3.3 base images.
Already fixed it yesterday, however, in #543 by using i386 version of selected ${KUBE_VERSION}, which is statically linked, and pushed the updated images.

Is this issue redundant with #542?

I'm thinking that we should move to k8s 1.2, including this change. Before we do, however, we should confirm that all works as it does now (i.e., no regressions). Suggest that we continue waiting for the e2e tests to run clean before moving, just to keep the number of moving pieces down. When they're in, then let's move to 1.2 across the board, including kubectl.


Project renaming XP-225

Do we want to name our custom logger as xain logger?

@Robert-Steiner and @atymoshchuk requested changes applied

Please change path in comment here: https://github.com/xainag/xain/blob/tanertopal/project_renameing-XP-225/xain_fl/datasets/stats/main.py#L19
Would be better to be more generic here: https://github.com/xainag/xain/blob/tanertopal/project_renameing-XP-225/xain_fl/logger.py#L1
For example: This module contains custom logging configuration and Line 8 accordingly.

Can you please double check Readme file and correct project name as well, thanks.


Possible bug in IE11 and Nuxt.js

Is it possible to use this with SSR with Nuxt.js?
When I check the source code, I see the literal tag in the source:
<Scroll-View offset="100" tag="div" data-v-b22faea4 data-v-64ea40b6></Scroll-View>
In Chrome (MacOS) the JS works fine with this, but in IE11 Windows, it takes issue with this.

Hi, thanks for taking the time to bring this up!
I've actually done 0 testing as far as SSR goes, so it's not really supported. However, I'm totally open to getting that up and running.
Could you give me a bit more detail about your use case and what you're looking to accomplish?

can confirm vue-scrollview is compatible with nuxt, however must be configured as a client-side only plugin in nuxt.config.js. SSR is not supported because scrollview directly relies on browser globals.
see: https://nuxtjs.org/guide/plugins#client-side-only

My mistake. Turns out configuring scrollview as client-side only does not work because any slotted components will not be rendered. Client-side hydration will fail resulting in a full re-render.
Will be pushing up a fix soon.

SSR support added in 2.2.0


How to sell gfx-rs

I'm just trying to think of as how a novice would see GFX. I mean the first though is, why use this over bare opengl or HGL? Might be a marketing question more then a technical question. - @csherratt

I'm very positive about the low-level interface that gfx-rs provides at the moment. We have a narrow but pretty definite scope, which gives a chance to produce a high quality library for that domain. A small piece to do its thing right - abstract the device, put it into its own thread, provide safe interface for drawing stuff. - @kvark

It's safe, it's bindless, it supports multiple backends to help support older architectures. It gives the user a mult-threaded render. - @csherratt

triaged: I think we can still improve our messaging in README


add kmeans parallel++

distributed mode in kmeans-init currently does not support parallelPlusPlus method. Needs to be added.

Added in 44c8d96ac31d1a05fdef63c21ced465fffd479fd


what infrastructures can be built/ would be needed by odyssey ?

Can you please expand on your question? I'm not sure I quite understand:)

I am looking at building infrastructure for the odyssey ecosystem, so looking for ideas on infrastructures


update GDC to CCDH conversion.ipynb

GDC to CCDH conversion.ipynb does not currently run to completion.

needs ccdh/ccdhmodel.py to be copied in from https://github.com/cancerDHC/example-data/pull/11
needs to use string dumpers from linkml runtime

This should be working now (as of PR #14). Could you please recheck when you have the time and make sure it's working for you? pipenv run jupyter notebook should work now.

yes, theGDC to CCDH conversion notebook in branch main does run to completion as long as the local ccdh model is loaded as
from ccdh import ccdhmodel as ccdh
but not from PyPI with
import crdch_model.crdch_model as ccdh
I think we're all aware of this now, so I'm closing the issue.