Executing multiple trajectories with different controllers is not supported

Description
Hi,
I'm trying to move 4 move groups on 1 robot simultaneously.  I have found out that it is not easy to do so as all of the 4 motion plans pipe into the same action server. However there were some suggestions to use the async_move() function of the move_group class which should provide this functionality. This can be activated by setting group.go(wait=False). However executing this did not change any behavior, all of the 4 groups are still moved one after another. Any help will be appreciated.
Your environment

ROS Distro: Melodic
OS Version: Ubuntu 18.04
Source or Binary build? Source
If binary, which release version?
If source, which branch?

Expected behaviour
Groups should be moved simultaneously
Actual behaviour
Same behavior as with wait=True, groups move one after another

I'm trying to move 4 move groups on 1 robot simultaneously.

What sort of robot is this? An industrial robot with multiple motion groups on a single controller, or a custom job with multiple controllers?

I am using 4 Panda Arms which I have attached to a plane which works as a base link (just as a simulation in Gazebo).
This is my controller file: ros_controllers.txt
For each move group (panda arm) there is 1 controller configured.

So multiple controllers?
I'm a bit puzzled by this part of your description:

I have found out that it is not easy to do so as all of the 4 motion plans pipe into the same action server.

If you have multiple pandas, with multiple controllers, and are not using a combined hw ros_control setup/the multi-robot support in the Franka software (or something similar), wouldn't you have multiple action servers?

Yes indeed. I have 4 action servers to give commands to the controllers, thats why I am able to control them each on its own. I just read https://answers.ros.org/question/317028/how-run-multiple-move_group-for-different-robots-in-single-system/ and assumed that MoveIt is going to pipe each motion plan into an action server (which might be wrong) before adressing the controller action servers. Sorry for the unclear description.

I can't help you with the async_move(..) I'm afraid, but each Franka driver instance exposes an action server.
So MoveIt would submit action goals to each individual action server.
With such a setup, synchronous execution of trajectories would be inherently impossible.
If "somewhat simultaneous" would be enough, that should be possible.

If you need them actually synchronized, I would suggest using a single planning group with all your pandas inside it.
Are you sure that 4 move_group nodes are started up? Or are you only starting 4 move_group_interfaces in your code?

Thanks anyways @gavanderhoorn. What I am trying to create is a robot with 4 arms that simulates an improved process of additive manufacturing. The goal of reducing the manufacturing process time is the reason that all of the 4 arms need to be working at the same time. If they have a delay of a few seconds behind each other that won't be a problem but obviously if there is only 1 arm working at all times there is no reason to use 4 of them.
@felixvd It looks like by default the moveit_config package generates 1 move_group action server, in my script I create 4 instances of the MoveGroupCommander class one for each arm. Is this a wrong approach?

Well, not "wrong", but you won't be able to run 4 robots asynchronously with that setup. I assume this is what happened:

You have 8 different planning groups set up inside your moveit_config (one for each Panda and one for each hand)
You roslaunch moveit_planning_execution.launch or move_group.launch, which creates one move_group instance
Your script node creates 4 instances of the MoveGroupCommander class, which all connect to the same move_group
When you call async_move through one of the MoveGroupCommander objects, your move_group connects to one of the robot controllers (follow_joint_trajectory) and waits for the trajectory to be executed.
You attempt to call async_move through another MoveGroupCommander object, but your move_group is busy waiting on the robot controller, so it either pre-empts that action or ignores your new command (I think it is the former, but I am not sure)

If you want to run the 4 robots asynchronously in the way you describe, my understanding is that you will need to launch 4 move_group nodes, so that each can connect to their own robot. The moveit_config and the planning groups defined in the package can be the same – you just have to be careful on your own not to use the same robot with two move_groups at the same time (this would be actually dangerous, please avoid). Each move_group will not consider the other move_group's plans, although each will be updated with the current position of all the robots. You should make doubly sure that the start state of your plan/trajectory is actually the robot's current state.
The "cleanest" way is probably to namespace the move_group launch file and remap the /joint_states to each of your namespaces so they each receive the robots' states. I am not sure if they can all live in the same namespace. In fact, now that I look at move_group_interface (the MoveGroupCommander just binds to this C++ class), you can't pass in the namespace. I guess you could run a node that creates one MoveGroupCommander in each move_group's namespace, but that seems unnecessarily messy. The other option I can see is to add a ros_namespace argument to the move_group_interface/MoveGroupCommander so that the move_action_client an execute_action_client connect to the correct move_group instance.
I haven't tried this and don't know anyone who has, but I know running planning groups simultaneously is a desirable feature. Pinging @henningkayser, @v4hn to correct if I wrote something completely off the mark. I also wonder if #2078 is related.

Ok I understand a bit better now what the problem is, thanks! You are right, I am launching 1 move_group but 4 MoveGroupCommanders. I have launched the move_group launch file in 4 different namespaces now, however I had to also namespace the joint_state_publisher and robot_state_publisher. The controller_spawner node inside the ros_controllers launch file does not work for now due multiple nodes named the same. Are launchfiles inside launchfiles not automatically launched under the aforementioned namespace?
As in both cases I will have to run 4 move_group nodes is it better to run 4 nodes or launch 4 times the move_group launch file? And regarding the ros_namespace argument, will this have to be added into the source code of the MoveGroupCommander or is there another way?
#2078 looks like it is adressing this issue, hope this feature is available soon.
Thanks again, you already helped a lot!

The controller_spawner node inside the ros_controllers launch file does not work for now due multiple nodes named the same. Are launchfiles inside launchfiles not automatically launched under the aforementioned namespace?

I don't know if the <group ns=... parameter can be nested and if it works for launch files, although I assumed/hoped it would. You should not have to namespace the controllers though. Keep them wherever they were, and try namespacing only the move_group nodes. I'm not sure you need to launch joint_state_publisher and robot_state_publisher in the namespace either if you use remap.

regarding the ros_namespace argument, will this have to be added into the source code of the MoveGroupCommander or is there another way?

As far as I can see, yes, but it should be as simple as adding the namespace in front of the move_group::MOVE_ACTION etc. parameters here. Then you just add a constructor that sets it. The MoveGroupCommander is defined here, but you would edit the wrapped C++ constructor here. Feel free to try it locally. I think it is the easiest way for what you are trying to do, and it would probably be worth a PR if it works well.
I do think this is a workaround though, and I think the move_group should be able to execute multiple trajectories simultaneously if the joint_model_groups are independent. Would like to hear @henningkayser's thoughts since he is one of the most familiar with that part of the codebase I believe.

I don't know if the <group ns=... parameter can be nested and if it works for launch files, although I assumed/hoped it would. You should not have to namespace the controllers though. Keep them wherever they were, and try namespacing only the move_group nodes.

The problem with the controllers is that it seems to be looking for the /move_group action server, which is now called /move_group1/move_group/[...] , /move_group2/move_group/[...] etc. due to the namespaces. Remapping all the topics and the action server back to /move_group from inside the move_group launch file so that the controller client can find it is unefficient but remapping the /move_group server to the 4 new-named instances of move_group from inside the controller launch file is not even possible from my understanding. So in conclusion the controllers can't find the move_group action server after namespacing it and I am not sure how to solve this if I let the controller launch file live in the namespace where it currently is.

As far as I can see, yes, but it should be as simple as adding the namespace in front of the move_group::MOVE_ACTION etc. parameters here. Then you just add a constructor that sets it. The MoveGroupCommander is defined here, but you would edit the wrapped C++ constructor here. Feel free to try it locally. I think it is the easiest way for what you are trying to do, and it would probably be worth a PR if it works well.

With this approach I will still need 4 move_group nodes which will lead to the same problem with the controllers or does this work with only one move_group too?

The controllers advertise follow_joint_trajectory actions, which move_group uses to execute trajectories. Why would they be looking for a /move_group action server? Can you paste the error? Have you tried launching the controllers in each namespace as well?

With this approach I will still need 4 move_group nodes which will lead to the same problem with the controllers or does this work with only one move_group too?

Yes, you will still need 4 move_group nodes if you want to execute 4 trajectories simultaneously (although it would be nice if this limitation was solved in the future).

[ INFO] [1599482396.609129695, 3.730000000]: Failed to call service get_planning_scene, have you launched move_group or called psm.providePlanningSceneService()?
[ INFO] [1599482396.609518646, 3.730000000]: Constructing new MoveGroup connection for group 'printer_arm1' in namespace ''
[ WARN] [1599482402.573232859, 5.233000000]: Waiting for printer/printer_arm1_controller/follow_joint_trajectory to come up
[ERROR] [1599482426.627978181, 10.203000000]: Unable to connect to move_group action server 'move_group' within allotted time (30s)
[ INFO] [1599482426.634298254, 10.204000000]: Constructing new MoveGroup connection for group 'printer_arm1' in namespace ''
[ WARN] [1599482431.020203508, 11.233000000]: Waiting for printer/printer_arm1_controller/follow_joint_trajectory to come up
[ERROR] [1599482455.143529187, 17.233000000]: Action client not connected: printer/printer_arm1_controller/follow_joint_trajectory
[ERROR] [1599482456.657825789, 17.636000000]: Unable to connect to move_group action server 'move_group' within allotted time (30s)
[ INFO] [1599482456.658144226, 17.636000000]: Constructing new MoveGroup connection for group 'printer_arm1' in namespace ''
This is the error I get which will come up for every controller that I am trying to launch.
Haven't tried out launching them in each namespace yet but thats what I was going to try out next.

Yes, try that. And note that you can format code with ```, if you paste more terminal output.

Did you manage to get this running or were there more difficulties?

I have not been able to test it yet because of an unrelated error that popped up but I will come back to this as soon as it's fixed.

I do think this is a workaround though, and I think the move_group should be able to execute multiple trajectories simultaneously if the joint_model_groups are independent. Would like to hear @henningkayser's thoughts since he is one of the most familiar with that part of the codebase I believe.

AFAIK, there is no way to do this with MoveGroup for several reasons:

The MoveGroupAction is run by a SimpleActionServer only supporting one request at a time
The TrajectoryExecutionManager only runs a single execute thread at a time
The MoveGroup's planning scene is read locked for each planning request because changes like motions of other groups could invalidate the computed trajectory
Executing multiple trajectories at the same time can easily lead to collisions because there is no trajectory validation/monitoring in place that accounts for already running motions

The single MoveGroup way to solve this would really be to define a planning group that includes all arms. Of course you need an IK solver and a planner to support this or you need to merge the different trajectories by hand. Otherwise, running multiple MoveGroup nodes should work with proper namespacing, but there could still be some issues with global parameters or topics. Keep in mind that arm-to-arm collision checking and syncing of the planning scenes can still be tricky and error-prone.
Another thing that might be worth looking into is to execute preplanned trajectories directly by sending FollowJointTrajectory actions to the ros controllers (of course you have to rule out arm-to-arm collisions first). This would bypass MoveGroup's trajectory execution manager so you won't have any trajectory monitoring in this case, but to me this seems like the easiest and safest solution.

Thanks for posting here as well, after the discussion in the meeting. This is a very interesting topic and this post got sort of long. Sorry in advance.
You mentioned that the TrajectoryExecutionManager only runs a single thread. I have read some of the code today, and it is true that only one thread is launched at a time - in pushAndExecute or execute. But the fact that execution is in a separate thread makes me think that much of the heavy lifting towards simultaneous execution is already done.
As you said, the MoveGroup's move and execute capabilities only run a SimpleActionServer, which only support one request. While it is true that each new goal causes the old action to be preempted, and thus a SimpleActionClient waiting on the previous goal would return, we could check which joints are part of the new goal, and keep executing the previous trajectory if the new one does not use any of the same joints. We would then return from the newest goal only when all trajectories have been executed.
The plan service capability does get a planning_scene_monitor::LockedPlanningSceneRO, which locks the PlanningScene. But while that would affect simultaneous planning and execution, it should not be an obstacle to executing multiple trajectories.
It is also true that there is currently no trajectory validation/monitoring for motions that are being executed. But there is executeAndMonitor which is connected to the "Replanning" checkbox in our Rviz panel, does monitor the remaining path of a trajectory for collisions and has this entertaining comment questioning if it should live in trajectory_execution_manager. It seems to me that this part of the code is orphaned but could be made useful again. Maybe @BryceStevenWilley can justify using some hours from Realtime Robotics for this :) For this sort of optimized use case, I think the user should be responsible for ensuring that the trajectory is not dangerous, but their controller is fast enough that this monitoring would work at sufficient speed.

Otherwise, running multiple MoveGroup nodes should work with proper namespacing, but there could still be some issues with global parameters or topics. Keep in mind that arm-to-arm collision checking and syncing of the planning scenes can still be tricky and error-prone.

It has been a long time since I have tried that, but my lasting impression was that move_group is not trivial to put into a namespace. You need to pipe robot_description and the joint state updates to it somehow (as well as the other groups' planning scenes??), and I don't know if anyone has ever made a good tutorial. The smoothest solution I found (and have been using since) is to put all the robots into the robot_description and separate them into planning groups. For humanoid robots and other naturally multi-arm robots (including work cells), I think that this is still the most sensible method. It also seems to me the most sensible way forward to give move_group the tooling to move multiple groups at once, and then (maybe, one day) methods to update the robot/scene for events like end effector changes.
At least, that seems more feasible to me than namespacing each arm of a humanoid robot and trying to keep their planning scenes synchronized. But anyone with opinions about this architecture choice is warmly invited to comment.

Another thing that might be worth looking into is to execute preplanned trajectories directly by sending FollowJointTrajectory actions to the ros controllers (of course you have to rule out arm-to-arm collisions first). This would bypass MoveGroup's trajectory execution manager so you won't have any trajectory monitoring in this case, but to me this seems like the easiest and safest solution.

Just for the record, I agree, and this is part of what I will be trying next myself.

Thanks for answering to this. I think in my case sending preplanned trajectories directly to the controllers seems very viable as I am able to split the space for the arms into 'workspaces' so that they won't collide with each other ideally. I think I even saw a function to define these workspaces in the MoveGroupCommander. However, the purpose is to 'print' filament by adding flat boxes along the followed cartesian path. From my understanding that won't be possible because the planning scene needs to be locked if I use the mentioned approach. Additionally I was thinking to use the Perception feature for dynamic collision avoidance so that the arms would stop the trajectory if another arm enters a foreign workspace. Would that still be possible? Is locking the scene even necessary if the robot is split into workspaces and the (ideally) few cases of possible collisions are filtered out by perception?

Hello guys, this issue seems to join lots of features, it took me a while to read all the documentation related to it.

Additionally, I was thinking to use the Perception feature for dynamic collision avoidance so that the arms would stop the trajectory if another arm enters a foreign workspace.

I took a look at the tutorial for Perception  and I wonder if it would be necessary to add the arm as a collision object for this to work. It can be a nice implementation, but I think the solution, as pointed out in GSoC's proposal of project is to do this avoidance dynamically.
Is there a way to extract the arm's movement functions without spoiling the simulation? My concern about this is creating lag or weird bugs.

Let's assume a single URDF with two robot arms (planning groups). Both arms are already part of the collision environment, so they don't need to be added as collision objects.
I'm not sure what you mean by "movement functions" or "spoiling the simulation". If you mean the trajectory, the TrajectoryExecutionManager would know all trajectories that are being executed, so you could access the current and future position of all planning groups relatively easily.

Hello, going through the comments, it seems that the agreed upon way for simultaneous trajectory execution is by sending FollowJointTrajectory actions to the ros controllers.

The TrajectoryExecutionManager would know all trajectories that are being executed, so you could access the current and future position of all planning groups relatively easily.

If I interpret this correctly, this means that by leveraging the TrajectoryExecutionManager we can check for all potential cases of
collision between multiple arms. Up until this point things look pretty straight forward, is there something else that I need to consider before I start digging into the nitty-gritty of the implementation details?

Hello, going through the comments, it seems that the agreed upon way for simultaneous trajectory execution is by sending FollowJointTrajectory actions to the ros controllers.

This interface will definitely not change, yes.

The TrajectoryExecutionManager would know all trajectories that are being executed, so you could access the current and future position of all planning groups relatively easily.

If I interpret this correctly, this means that by leveraging the TrajectoryExecutionManager we can check for all potential cases of
collision between multiple arms. Up until this point things look pretty straight forward, is there something else that I need to consider before I start digging into the nitty-gritty of the implementation details?

A few thoughts, not only for you:

Yes, when a new trajectory is to be executed, TEM should check for collisions with the currently active trajectories.
The simplest way to implement this seems to be:

When a new trajectory is to be executed and other trajectories are active, create a new "merged" robot trajectory, used only for collision checking.
The merged trajectory should contain the remaining parts of the active trajectories + the new one. This merging will need to be done from scratch I believe.
The merged trajectory can be checked with the isPathValid method of the PlanningScene.

Collision is checked for each sample, so safety is not strictly guaranteed. Bullet offers continuous collision checking, but that's another story. Padding should be used.
The positions of the robots executing active trajectories will not be perfectly accurate, due to delays in each controller and the physical execution. This is another reason to use padding.
Padding might cause collisions with the environment, even though incoming trajectories should have been checked for that already. We could ignore environment collisions by modifying the AllowedCollisionMatrix of the PlanningScene object. (By "environment" I mean stationary robot links)

Finally, importantly:

It is great to start reading and trying, but don't forget that there is no guarantee that a GSoC slot for the project will be assigned to you. Fixing smaller issues first also makes your case and avoids potentially duplicated work.

A few thoughts, not only for you:

Yes, when a new trajectory is to be executed, TEM should check for collisions with the currently active trajectories.

The simplest way to implement this seems to be:

When a new trajectory is to be executed and other trajectories are active, create a new "merged" robot trajectory, used only for collision checking.
The merged trajectory should contain the remaining parts of the active trajectories + the new one. This merging will need to be done from scratch I believe.
The merged trajectory can be checked with the isPathValid method of the PlanningScene.

Collision is checked for each sample, so safety is not strictly guaranteed. Bullet offers continuous collision checking, but that's another story. Padding should be used.

The positions of the robots executing active trajectories will not be perfectly accurate, due to delays in each controller and the physical execution. This is another reason to use padding.

Padding might cause collisions with the environment, even though incoming trajectories should have been checked for that already. We could ignore environment collisions by modifying the AllowedCollisionMatrix of the PlanningScene object. (By "environment" I mean stationary robot links)

Thank you for the pointers, especially the idea of using merged trajectories, I will try to keep them in mind while coming up with a solution.

Finally, importantly:

It is great to start reading and trying, but don't forget that there is no guarantee that a GSoC slot for the project will be assigned to you. Fixing smaller issues first also makes your case and avoids potentially duplicated work.

Got it, as mentioned earlier(discord), I have been able to run multiple robot arms. I will proceed to write a short tutorial for this and open a PR against #465

I did not read this thread before because the name did not at all represent the discussed problem, but @felixvd pointed me here in another related issue.
Missing support for multiple simultaneous trajectories It is a (among maintainers) well-known shortcoming of the execution engine. As mentioned here multiple times, clearly, it should be possible to send trajectories to different controllers and sending them directly to the controllers is possible.
Path and execution monitoring could benefit from bundling the requests through, especially to avoid collisions due two multiple arms moving.
Henning mentioned many points above, but from my perspective the main limiting factor is the current choice to implement ExecuteTrajectory as a SimpleActionServer. It provides such a neat abstraction over the general action server design that very few people using ROS have actually ever seen a NonSimple ActionServer. But it structurally limits the interface to one request at a time and we it's wrong for this interface.
I believe the best way forward would be to implement the action as a general ActionServer and work your way down from there.
It is true that the TrajectoryExecutionManager only handles one trajectory at a time, but it's no big deal to change that.
I would expect other changes are required as well, but you only find out once you're there.

I have been able to execute multiple trajectories asynchronously using separate instances of the TrajectoryExecutionManager running in their own thread launched with the std::package_task  construct. An overly simplified snippet of that is as follows:
// declare type aliases
using ExecStatus = moveit_controller_manager::ExecutionStatus;

// declare and initialize moveitcpp
 moveit::planning_interface::MoveItCppPtr planning_interface_ = ... ; // MoveItCpp is only used to gain access to the robot model and planning scene monitor
...

// declare trajectories and controller names
std::vector<moveit_msgs::RobotTrajectory> trajectories = ...
std::vector<std::string> controller_name = {"fake_arm1_controller", "fake_arm2_controller", ...};

// declare vector for storing futures
std::vector<std::shared_future<ExecStatus>> exec_futures;

for(std::size_t i =0; i < trajectories.size(); i++)
{
auto traj = trajectories[i];
std::string controller_name = controller_names[i];

// instantiate controller
trajectory_execution_manager::TrajectoryExecutionManagerPtr traj_exec_mngr = std::make_shared< trajectory_execution_manager::TrajectoryExecutionManager>(
            planning_interface_->getRobotModel(), planning_interface_->getPlanningSceneMonitorNonConst()->getStateMonitorNonConst(), false);

// create packaged task with lambda that executes the trajectory
std::packaged_task< ExecStatus ()> async_task ([traj_exec_mngr, traj, controller_name]() -> ExecStatus{
  traj_exec_mngr->push(traj.joint_trajectory, controller_name);
  traj_exec_mngr->execute([](const moveit_controller_manager::ExecutionStatus& st){
    ROS_INFO_COND(st,">>>> Trajectory completed");
    ROS_ERROR_COND(!st,"Trajectory failed");
  });
  moveit_controller_manager::ExecutionStatus st = traj_exec_mngr->waitForExecution();
  traj_exec_mngr->stopExecution(true); // don't know if this is necessary
  traj_exec_mngr->clear();
  return st;
});

// get shared future and store
exec_futures.push_back(std::shared_future<ExecStatus>(async_task.get_future()));

// move task into new thread
std::thread t(std::move(async_task));
t.detach();
}

// wait for threads to complete
while(ros::ok() && loop_pause.sleep())
{
  if(std::all_of(exec_futures.begin(), exec_futures.end(),[](std::shared_future<ExecStatus>& f){
    std::future_status st = f.wait_for(std::chrono::duration<double>(0.01));
    return st == std::future_status::ready;
  }))
  {
    break;
  }
}

Does this give you an advantage over sending the trajectory directly to the robot driver? It would still leave you without collision checking between the trajectories from what I can see.

Does this give you an advantage over sending the trajectory directly to the robot driver?
It would still leave you without collision checking between the trajectories from what I can see.

It's only a partial way out, but at least it gives you the usual monitoring / online validity checking for each trajectory separately.
It should even find potential future collisions if one robot moves into the executing future trajectory of the other one.

Does it? I read this line to mean that collisions are only re-checked if a collision object is added or changed, since UPDATE_STATE is not included here.

You are right. UPDATE_STATE would have to be added there, but the flag should probably only signal if joints outside the executing JointModelGroup change.
I'm unsure about the resulting computational overhead, so I won't propose to add that logic there just now.
It would be a nice option to have though.
So the only thing you really gain when using the upstream repository is monitoring of the trajectory duration (mostly to catch controllers that fail to respond), but it's just a few lines to get partial collision checking too :cat2:

I've been thinking lightly about this. Instantiating multiple TrajectoryExecutionManagers seems feasible (although I don't know where they would live, since every context only owns one), but either way we need a way to check that a trajectory is safe to execute alongside the current ones, before we change the execute_trajectory action server. To me that is the main limiting factor.
In plan_execution.cpp, isRemainingPathValid steps through an ExecutableMotionPlan to check collisions. If this function took a vector of ExecutableMotionPlan objects as input* and stepped through all of them simultaneously, it could at least roughly check for collisions. "Roughly" because the collisions are checked at each waypoint of the trajectory, and I am not sure if any density on those is guaranteed.
I guess it would be plan_execution::PlanExecution::arePathsColliding(const std::vector<ExecutableMotionPlan>& plans, const std::vector<std::pair<int, int>>& path_segments).
*In an earlier post I thought about merging two ExecutableMotionPlan objects into one to step through them together, but I don't think this makes sense, since each robot would still have its own RobotTrajectory inside.

I was playing around with the idea of @jrgnicho to spawn one TrajectoryExecutionManagers per trajectory and manage their execution in plan_execution, but this would change the logic of the MoveGroupContext (it would need to store a vector of TEMs instead of only one) and probably cause a lot of uncomfortable downstream changes. If the logic was contained within the TrajectoryExecutionManager, migration would be much easier.
Reading the TrajectoryExecutionManager in more detail, it seems like there are two redundant entry points: execute and pushAndExecute. Each uses a thread to walk through a vector of TrajectoryExecutionContext, but they are both separate. Strangely, pushAndExecute cannot ever have more than one element in its continuous_execution_queue_, so I am assuming that it is orphaned code. I also think that no one is using the push functionality of the TEM (which allows multiple trajectories to be executed in a row), and users are waiting for the MGI's move or execute functions to return instead.
Seeing as there is already functionality in TEM to work through a queue of trajectories, extending it appears to be the best option. Instead of executing the trajectories one-by-one, the continuous_execution thread should check if the next trajectory in the queue can be executed safely in parallel to the currently executed ones, and start its asynchronous execution. This requires the executePart, waitForExecution functions to be thread-safe and refer to a specific group, but the default behavior could be compatible with the original API.
My only concern is that the TEM currently does not have a notion of safety, but it would need to be able to check if two robot trajectories collide or not. But it owns a robot_state, so we could add such a function there.

Dear all,
I am working with two real panda robots. I built a MoveIT package for interface with the two panda robots and it works fine in the simulator. Then, I configured the controllers.yaml to act with the real two robots via the combined_panda/effort_joint_trajectory_controller and I can read and visualize the robots state/joints values (/combined_panda/joints) in the Rviz.
I have three planning groups in the moveIT package.
1- panda_1 (panda_1_joint1 … panda_1_joint7)
2- pnada_2 (panda_1_joint1 … panda_2_joint7)
3- combined_panda (panda_1_joint1 … panda_1_joint7 … panda_2_joint1 … panda_2 _joint7)
From rviz, I can control both robots (combined_panda planning group) to reach different/random poses, and it is working fine. But I can not control one robot separately (I can not use ( panda_1 planning group or panda_2 planning group), it gives the following error,
franka_comined_control “ERROR: joints on incoming goal don’t match the controller joints”
So, I run different move_groups on a script:
1- for panda_1
2- for panda_2
and execute the two move_goups as two threads in the script. But it still doesn’t work.
When I worked with the combined group (14 joints → which has the two subgroups (panda_1 and panda_2)), and I set a target pose for every robot (panda_1 and panda_1) and execute them from one planning group by setting the pose target and gripper link of every robot. It give me these error:
‘’ Unable to solve planning problem’’
‘’ More than one constraint is set. If your move_group does not have multiple end effector/arms, this is unusual. and a move_group interface and forgetting to call clearPoseTargets () or equivalent?’’
Can anyone help me in this regard ?

If multiple move groups (robots) are combined under a single move group (let's call it all_groups) such as discussed here, would the following approach work to address the main topic of this thread?

Plan for all_groups which should (?) account for potential collisions between individual robots. I guess it would be the end_effector_link argument of MoveGroupInterface methods like setPoseTarget that determined which robot to plan for while the plan result for the other robots don't matter.
Don't execute the plan but rather replace the remaining trajectory for the joints of the robot that you just planned for by using the trajectory replacement method by directly sending the trajectory to the trajectory controller.

The original topic of the thread was the simultaneous execution of multiple trajectories (of disjoint groups).
This is not supported currently. However, there is a pending PR: https://github.com/moveit/moveit/pull/3243.
The referenced trajectory replacement method will just replace an old trajectory with the new one (with a smooth transition).
This will not help for the original issue.


Switching branch to master in VS2019 ist working VS not responding. Need to kill the process

Every time i switch from Branch to Master my visual studio gets stuck and needs to be killed. After that i can start VS again and the Branch got switched.
Im using VS 16.0.4.
Ach probably wrong Git project. Im using the OOTB VS git integration.

Sorry, that's not the support forum of Visual Studio


Game crashes when rednet is placed down

So whenever i have a full working reactor and i add a rednet controller block to the multiblock my game crashes and im just trying to get like a computercraft program to work can someone please help me.

Do you have the crash log?

Im sorry but i had this problem along time ago and since haven't used the mod for awhile since mabey september so im sorry for the inconvience and have a good day


separate tags with commas as indicated in action doc

@erichgess found that https://github.com/apache/pinot/pull/10528 broke the codecov coverate.
In fact coverage was uploaded, but tags were incorrectly configured and therefore they are not uploaded with the expected metadata.
As indicated in https://github.com/codecov/codecov-action, different tags should be separated by commas.

Codecov Report

Merging #11303 (7b23f93) into master (6fa4268) will increase coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master   #11303     +/-   ##
=========================================
  Coverage    0.11%    0.11%
=========================================
  Files        2231     2157     -74
  Lines      120139   116982   -3157
  Branches    18218    17772    -446
=========================================
  Hits          137      137
+ Misses     119982   116825   -3157
  Partials       20       20

Flag
Coverage Δ

integration1temurin11
?

integration1temurin17
?

integration1temurin20
?

integration2temurin11
?

integration2temurin17
?

integration2temurin20
?

java-20
0.11% <ø> (?)

temurin
0.11% <ø> (?)

unittests1temurin11
?

unittests1temurin17
?

unittests1temurin20
?

unittests2
0.11% <ø> (?)

unittests2temurin11
?

unittests2temurin17
?

unittests2temurin20
?

Flags with carried forward coverage won't be shown. Click here to find out more.
see 76 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Can some documentation be provided on how to build the TensorFlow C++ library from source to use TFRA custom ops in the TensorFlow C++ API?

We use TFRA for offline training, and the online service uses rpc + Tensorflow dynamic link library.
I encountered some problems during the joint compilation phase of TFRA and TF. I tried to compile it referring to this link, but was unsuccessful: https://github.com/tensorflow/recommenders-addons/issues/103.
Can some documentation be provided on how to build the TensorFlow C++ library from source to use TFRA custom ops in the TensorFlow C++ API?

Hi @WangShengguang, thank you for your feedback! Please refer to the comment: https://github.com/tensorflow/recommenders-addons/issues/103#issuecomment-867606225

You may try:
./configure
bazel build -c opt --config=numa --copt="-O3" //tensorflow:libtensorflow_cc.so //tensorflow:libtensorflow_framework.so //tensorflow:install_headers

Then install the *.so and headers in /usr/local/
To use TFRA custom ops, just preload the TFRA so:
LD_PRELOAD="/usr/local/lib/_cuckoo_hashtable_ops.so /usr/local/lib/_math_ops.so" ./your_app

You may try:
./configure
bazel build -c opt --config=numa --copt="-O3" //tensorflow:libtensorflow_cc.so //tensorflow:libtensorflow_framework.so //tensorflow:install_headers

Then install the *.so and headers in /usr/local/
To use TFRA custom ops, just preload the TFRA so:
LD_PRELOAD="/usr/local/lib/_cuckoo_hashtable_ops.so /usr/local/lib/_math_ops.so" ./your_app

Hi @WangShengguang, could you please help check if this solution works for you? Thank you!

You may try:
./configure
bazel build -c opt --config=numa --copt="-O3" //tensorflow:libtensorflow_cc.so //tensorflow:libtensorflow_framework.so //tensorflow:install_headers

Then install the *.so and headers in /usr/local/
To use TFRA custom ops, just preload the TFRA so:
LD_PRELOAD="/usr/local/lib/_cuckoo_hashtable_ops.so /usr/local/lib/_math_ops.so" ./your_app

Hi @WangShengguang, could you please help check if this solution works for you? Thank you!

@thorneliu @WangShengguang  Thanks for answering my question. But there are some new things recently, it may take a few days.

You may try:
./configure
bazel build -c opt --config=numa --copt="-O3" //tensorflow:libtensorflow_cc.so //tensorflow:libtensorflow_framework.so //tensorflow:install_headers

Then install the *.so and headers in /usr/local/
To use TFRA custom ops, just preload the TFRA so:
LD_PRELOAD="/usr/local/lib/_cuckoo_hashtable_ops.so /usr/local/lib/_math_ops.so" ./your_app

Hi @WangShengguang, could you please help check if this solution works for you? Thank you!

@thorneliu @rhdong Thanks for answering my question. But there are some new things recently, it may take a few days.

Hi @WangShengguang, is there any update? :)

Hi @WangShengguang , we are relatively sure that the solution from @thorneliu can solve the issue. We will close this issue first. If any problem please feel free to reopen it, thank you for your feedback!


Add ctrl-alt-left, ctrl-alt-right, ctrl-alt-tab changes in

Add ctrl-alt-left, ctrl-alt-right, ctrl-alt-tab changes to enable key binding
behavior in FreeRDP/X11 to behave same/similar as OS key bindings.
Make life easier...
http://unix.stackexchange.com/questions/123208/exclude-certain-key-combinations-from-being-passed-via-rdesktop
From patch submitted to rdesktop project, #178 Send some hotkeys to local windows manager instead of remote.

@freerdp-bot test.

Maybe exactly what i need! Want to View Unity Launcher and start a programm (which should then appear in front), without minimizing xfreerdp in fullscreen-mode.

This patch works for me. Tested on Puppy Linux Slacko64 6.3.2 based on Slackware 14.1.
Only a note: Ctrl-Alt-Left is not sufficient, I must press Ctrl-Alt-Left+Left (or Ctrl-Alt-Right+Right).

Hi,
why is this Issue still open when so many people want this feature and a solution is available and works for some people?

@frruit There is already the options of pressing Right Ctrl to ungrab


Tests failing with ParamTools 0.16.0

Tests are failing with ParamTools 0.16.0.  Model seems to run fine, but there is an incompatibility with cached Specifications objects used in tests (created with an older version of ParamTools) and the new version.
We'll need to figure out how to have old object conform with new ParamTools, or save new Specifications objects for testing.

@jdebacker Sorry about this. I tested against Tax-Calculator, CCC, Tax-Brain, and Tax-Cruncher. For the sake of my computer, I skipped OG-USA. What are the error messages?

@hdoupe I wouldn't expect you to test against OG-USA!  This will happen, but I appreciate you chiming in here as maybe you can suggest a quick fix.
Here's the traceback:
____________ ERROR collecting ogusa/tests/test_parameter_tables.py _____________
66
ImportError while importing test module '/home/runner/work/OG-USA/OG-USA/ogusa/tests/test_parameter_tables.py'.
67
Hint: make sure your test modules/packages have valid Python names.
68
Traceback:
69
/usr/share/miniconda/envs/ogusa-dev/lib/python3.7/importlib/__init__.py:127: in import_module
70
    return _bootstrap._gcd_import(name[level:], package, level)
71
ogusa/tests/test_parameter_tables.py:15: in <module>
72
    os.path.join(CUR_PATH, 'test_io_data', 'model_params_baseline.pkl'))
73
ogusa/utils.py:364: in safe_read_pickle
74
    obj = pickle.load(f, encoding='latin1')
75
E   ModuleNotFoundError: No module named 'paramtools.tree'

Oh, the tree module was removed in 0.16.0...you may be able to dump the parameter values and load them with the new version of paramtools:
conda install "paramtools==0.15.1" -c conda-forge

obj = pickle.load(f, encoding='latin1')

with open("model_params_baseline.json", "w") as f:
    f.write(
        json.dumps(obj.specification(use_state=False, meta_data=False, serializable=True))
    )

and then:
conda install "paramtools==0.16.0" -c conda-forge

params = Specifications()

params.adjust("model_params_baseline.json")

However, this will only work if all parameter values are updated using adjust. I think there are some places where OG-USA just updates the parameter value directly like this:
https://github.com/PSLmodels/OG-USA/blob/54d5807fcf398fda05bc142c910ff52b8630082d/ogusa/parameters.py#L131-L145

This issue was resolved in PR #674, which updated the 6 pickle files that contain Specifications objects with those created using ParamTools 0.16.0.
Note that there were issues reading pickle files created in Python 3.8 in Python 3.7 for the tests run via GitHub actions.  GH Actions now only tests against Python 3.8 (Travis CI continues to test against 3.7 and 3.8).


[Question] What is the best flow for performing runtime geometry updates?

What is the recommended way of performing updates to the geometry of map lanelets at runtime. If a vehicle senses a construction zone and there is a shifted lane. How should the map be updated to reflect that to minimize the re-computation of search trees, centerlines, etc.? What functions are important to call to ensure the map remains valid?

Updating existing maps is still a todo, sorry. It is doable to implement it but until now nobody needed that feature. it's also not trivial to implement because all the elements in the map that use the modified primitive would have to be updated recursively as well.
The only approach currently available is to create a completely new map that contains all the elements from the old map you are interested in.

@poggenhans Thanks for clarifying that. I suspected that might be the case. Is this something you plan to work on at all in the near future or is it a long way off?

Hm, it might be something we might squeeze into our lanelet2_ros release. But right now I cannot give you a good ETA. It might be two months, but it might very well be more. I'll keep this issue open as a "friendly reminder".


GlobalShap method getting error.

How can I use the global shap method with my code?

For global shap, OmniXAI v1.2.3 needs to be installed. Here is an example: https://github.com/salesforce/OmniXAI/blob/main/omnixai/tests/explainers/shap/test_shap_tabular_global.py.

@yangwenz Thank you it worked for me.


Better git error

A nice and long error message and fetching the git author name the same way real git does it.
I'm not 100% happy with the code and the error message could be improved as well.

It should have a test before merging.
Also: We need better error handling. String is really not that good here. Will work on that before this is ready.

@badboy Can this be merged or is there work to be done first?

I'm not 100% satisfied with the user-visible error message. Gonna rewrite that and then merge it

3256a8c2c430a93a99b4be94fcca08c78560894c now has a much nicer error message, which I took from man git-commit-tree (and slightly modified).
14ad9f0303145b7a92e6f80194220b9aae2f910c removes support for the GIT_AUTHOR_* variables as I think it is too confusing and a single variable per setting is good enough.
If you agree with all (and tests are green): Ready to merge.

Forgot to remove one sentence, fixed in b278629b8a03cb9094e29344484396dc9635ad22


Changing the content of a html.Div dynamically

Is it possible to change the content of a "html.Div" dynamically?
Something like:
def load():
    with div_to_modify:
        html.P("Hello world!")

with html.Div():
    with vuetify.VBtn(
        click=(load, ""),
    ):
        vuetify.VIcon("mdi-plus-circle")

with html.Div() as div_to_modify:
    pass

I know that the code above does not work.
What I want to do is, load data after a button click and modify the content of another div based on the data. I think "v_if" and "v_show" are not appropriate for this functionality, because at the moment of starting the app I don't know the content of the data.

I found out that a vuetify component has an add_child method and it seems to possible to add components dynamically. However, the added components are not visible. Thus, I assume the parent component has to be update or synchronized with the client.
What has to be done after using the add_child method to update the gui?

Thanks. I will give the templating infrastructure a try.


Proposal for layer options (settings file)

In the spirit of "not invented here", because OpenCL Layers are following the success of Vulkan layers, it makes sense to follow the same format and locations for setting settings on how layers should behave when loaded.
File structure example
# Comments start with #
# settings (by convention) are prefixed by layer name
layer.setting1 = 10
# Empty lines are ignored, trailing and leading whitespace is trimmed

layer.setting2 = true # Line comments

In general this is a direct translation of vk_layer_settings.txt
$VARIABLE is used for environment variables.
Search locations for the file
The order of precedence through which config files are found are as follows:

If $OPENCL_LAYERS_SETTINGS_PATH is set to a path to a directory, use the file cl_layer_settings.txt file from it. Otherwise if set it should be set to the file name to read the settings from.
If $OPENCL_LAYERS_SETTINGS_PATH is not set search for platform specific directories listed below.
If no settings are found in any of the platform specific locations, then fall back to cl_layer_settings.txt in the current working directory.

Platform specific locations
Linux and MacOS

$XDG_DATA_HOME/settings.d/opencl/cl_layer_settings.txt

if $XDG_DATA_HOME is not set try with $HOME/.local/share

Windows

If {HKEY_LOCAL_MACHINE}\Software\Khronos\OpenCL\Settings has key with zero value, the the name of
the key is used as filename.
Non admin only: HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE

Android
The vulkan validation layers use the same locations as in linux, but environment variables are
replaced by properties.

Sounds good to me.
Just a few comments/thoughts:

We should have a defined naming convention to map layer options to environment variables
Do we need a way to communicate those options from the loader to the layers? Or are layers responsible for fetching the file and finding their respective options (in this case we may want to provide helpers)? The more I think about it the more is favor the later, but this is not an easy choice.
We should add new cl_layer_info enum values:

CL_LAYER_NAME, this one is straightforward
CL_LAYER_OPTIONS, this one format is to be determined. Returning a pointer to a null terminated array of versioned structs filled with pointers to strings describing the option name and possible values comes to mind but I have not thought this one through.

We should add a mechanism to list the layers that would be loaded by the loader, their name and available options, and the value they would have (default or set by configuration file or environment)

Am I missing anything?

We should have a defined naming convention to map layer options to environment variables

It seems that #6 already includes this. It uses a simple scheme where <layer_name>.<setting_name> is translated to CL_<LAYER_NAME>_<SETTING_NAME>, which should be a decent enough 1:1 mapping. Perhaps using OPENCL_ as prefix would be better though, just so that it is similar to the already existing OPENCL_LAYERS and OPENCL_LAYERS_SETTING_PATH.

Do we need a way to communicate those options from the loader to the layers? Or are layers responsible for fetching the file and finding their respective options (in this case we may want to provide helpers)? The more I think about it the more is favor the later, but this is not an easy choice.

The simplest solution is to just let every layer handle this themselves. This is also the solution that was chosen for the Vulkan layers, since the LunarG layers and Khronos layers contain their own implementation of the setting loader.

We should add a mechanism to list the layers that would be loaded by the loader, their name and available options, and the value they would have (default or set by configuration file or environment)

I can see two basic ways to implement this; either as a standalone program or as a separate layer that simply prints the options available for the other layers. In both cases, it would reuse the code already present in #6.

@Snektron Thanks for the feedback:

We should have a defined naming convention to map layer options to environment variables

It seems that #6 already includes this. It uses a simple scheme where <layer_name>.<setting_name> is translated to CL_<LAYER_NAME>_<SETTING_NAME>, which should be a decent enough 1:1 mapping. Perhaps using OPENCL_ as prefix would be better though, just so that it is similar to the already existing OPENCL_LAYERS and OPENCL_LAYERS_SETTING_PATH.

I am terrible at naming things, but you may be correct that OPENCL_ might be a better prefix.

Do we need a way to communicate those options from the loader to the layers? Or are layers responsible for fetching the file and finding their respective options (in this case we may want to provide helpers)? The more I think about it the more is favor the later, but this is not an easy choice.

The simplest solution is to just let every layer handle this themselves. This is also the solution that was chosen for the Vulkan layers, since the LunarG layers and Khronos layers contain their own implementation of the setting loader.

I agree, this is simpler, and more flexible.

We should add new cl_layer_info enum values:

CL_LAYER_NAME, this one is straightforward
CL_LAYER_OPTIONS, this one format is to be determined. Returning a pointer to a null terminated array of versioned structs filled with pointers to strings describing the option name and possible values comes to mind but I have not thought this one through.

We should add a mechanism to list the layers that would be loaded by the loader, their name and available options, and the value they would have (default or set by configuration file or environment)

I think there are a few approaches possible here:
* A standalone program similar to clinfo, which simply queries `clGetLayerInfo`.

* A separate layer which does the same. This has the added caveat that it would print its "own" information, but it can be used in conjunction with a users existing program (they would only need to append `libPrintLayerInfo.so` to their `OPENCL_LAYERS` variable).

* An environment variable which instructs layers to print settings and options. This would make each layer responsible for printing its own information.

The first option seems the most flexible to me. Additionally, if CL_LAYER_OPTIONS is some kind of dynamic string array rather than a structure with standardized fields for every option, it would allow other people to implement new layers without having the standard modified.

I think we agree on this as well. The only constraint here is that this tool is hosted and distributed with the icd loader, so that code can be shared between the two, ensuring that both behave identical WRT layers loading.

Hello,
I am drafting the additional queries to the clGetLayerInfo of the cl_loader_layers extension.
For the options reporting mechanism I had 2 variants in mind:

Using 'null' terminated (empty terminated would be more exact) array of structures pointing to static strings (my initial idea):

typedef struct {
  const char *name; // name == null is list terminator
  const char *value; // Option current value after reading configuration files and environment variables
  const char *default_value;
  const char *description;
} cl_layer_option;

This departs quite a bit from the way OpenCL usually handle info queries, where usually a pointer to the drivers internal data is never returned (as far as I can tell). We could make it so that the buffer required from the user would hold both the list and the strings. This is not an especially difficult scheme to implement. We also may want to add more entries to the structure to avoid having to extend it later on.

Using several queries to return buffers of null terminated strings:

CL_LAYER_NUM_OPTIONS
CL_LAYER_OPTION_NAMES
CL_LAYER_OPTION_VALUES
CL_LAYER_OPTION_DEFAULT_VALUES
CL_LAYER_OPTION_DESCRIPTIONS

This would for instance return "optiona\0optionb\0" for CL_LAYER_OPTION_NAMES if optiona and optionb are supported. This is easier on the layer implementer and easier to extend, but a bit more cumbersome for the user to parse than 1.
@Snektron where you thinking of something else?


[stable/nginx-ingress] added feature flag to enable hostPort for daemonset

#872

I signed it!

@k8s-bot ok to test

@21stio can you bump the chart version? thanks!

closed in favor of #894 as I messed up my fork


Ubuntu: Fix install problem.

[39/39] Install the project...
-- Install configuration: ""
CMake Error at lib/cmake_install.cmake:36 (file):
  file INSTALL cannot find
  "/opt/mull/BuildNinja/lib/CMakeFiles/CMakeRelink.dir/libmull.so".
Call Stack (most recent call first):
  cmake_install.cmake:37 (include)

@stanislaw is it still the case?

Not sure :(

I just checked it and it works.


Please confirm these before moving forward

[X] I have searched for my issue and not found a work-in-progress/duplicate/resolved issue.
[X] I have not been informed if the issue is resolved in a preview version of the winget client.

Category of the issue
Other
Brief description of your issue

2.3 is beta but winget does not have a beta tag on it and stable (2.2) is not available either - https://github.com/hxseven/Remove-Empty-Directories/releases
the short name RED should be included in the name

Steps to reproduce
n/a
Actual behavior
n/a
Expected behavior
n/a
Environment
Windows: Windows.Desktop v10.0.19044.4412
Systemarchitektur: X64
Paket: Microsoft.DesktopAppInstaller v1.22.11261.0

Screenshots and Logs
No response

Other than the version number, is there any indication that 2.3 is a beta?
Its tagged Pre-Release on Github. The website ( https://www.jonasjohn.de/red.htm ) also says its beta.

Related #27049.
For version v2.2, the package requires .NET Framework 3.5 Windows Feature to be enabled. Currently Dependencies.[*].WindowsFeatures hasn't been implemented.
Also, .NET Framework 3.5 didn't available in winget source. Maybe we can try adding it to the repository as PackageDependency.

Related #27049.
For version v2.2, the package requires .NET Framework 3.5 Windows Feature to be enabled. Currently Dependencies.[*].WindowsFeatures hasn't been implemented.
Caution
Microsoft provides an *.exe installer for .NET Framework 3.5 Windows Feature. But the installer wizard doesn't support silent install.
We have to wait for Dependencies.[*].WindowsFeatures to be available.

To my knowledge, this feature is available. A list of available feature names can be found with Get-WindowsOptionalFeature -Online.
Dependencies:
  WindowsFeatures:
    - netfx3
Installers:

I see it was renamed to JonasJohn.RED.Beta - but stable ist not available, is it? So I would not agree that this is "completed"


Fixed invalid canvas_item:COLOR initialization in shaders

!COLOR_USED condition in canvas.glsl will be applied only if "COLOR = [some vec4]" is performed, COLOR.rgb or COLOR.a will not attract this as well as COLOR (+=, *=, /= etc) .
Fix #25009

Implementation looks good. However, I don't agree with the change.
The reason is, this change will force users to always overwrite vertex color with texture color. However, there are plenty of valid use cases where the user may intend access the vertex-color rather than the texture color.
For example, consider a shader that chooses a texture based on vertex color
void fragment() {
    COLOR = mix(texture_a, texture_b, COLOR.r);
}

The above shader would mix between texture_a and texture_b based off texture(TEXTURE, UV).r rather than COLOR.r coming from the vertex shader.


Standalone emulators and other cores for n64 broken in ArkOS after last update (R36S)

All N64 cores (except the default parallel) have stopped working. After attempting to launch, the screen goes black and I am back in my N64 gamelist. In retroarch you can't even load the core.
I quickly reinstalled everything on a second SD card (with the RG351M-Arkos image) and installed the update again (via the online function in the system options) - then it didn't work again.
For final clarification, I reinstalled everything on an SD card, but then blocked the N64 cores for updates using the retroarch settings. After the system online update, the games continue to start regularly via Mupen - so it must be the core / some config things that the Arkos update breaks.

(I am not the only one with this problem. There are some new reddit threads with the same problem:
https://www.reddit.com/r/SBCGaming/s/KHmymXs33t
https://www.reddit.com/r/SBCGaming/s/OZcjf5V0iD

This is due to the way the stock ArkOS image provided with the R36s provisions some items which causes the update to not place the right files .  Updating from the RG351MP image should have worked though so not sure what happened there.  Try restoring the following file.  This should resolve the N64 standalone issues.

Take the attached compressed file (arkosbackup.tar.gz) and put it in your roms/backup folder. Do not uncompress the contents! Just place the file as is in your roms/backup folder. If you don't have a backup folder in the roms folder, just create it.

Then go into the Emulationstation Menu, scroll to Options, hit A, then go to Advanced, hit A, then scroll all the way down to Restore Settings, hit A.

Once completed, you should be able to launch your n64 games using the standalone emulators.

arkosbackup.tar.gz
Also note, a community member by the name of Aeolus has an image specifically built for the R35s and R36s units with these fixes in place for those units.  The links for those images are available here:
ArkOS_R35S-R36S_v2.0_12222023 (By Aeolus)
https://drive.google.com/file/d/10z7j7IZ7WX3y10ZJBW_a2-agcIe1Dx9m/view?usp=drive_link
https://www.mediafire.com/file/da4193t5vsjfsbr/ArkOS_R35S-R36S_v2.0_12222023.img.xz/file
More information about this image and further discussion and further developments related to the R35s/R36s units are available on the Retro Handheld Discord.  https://discord.gg/retrohandhelds

Thank you for the quick reply and your solution to the problem. I assume that this "restore-backup" method could also be used for other cores (i.e. also the mupen64plus-next) if the corresponding folder paths are taken into account? Unfortunately, this also causes Retroarch to crash (also only since the update).
When I look in the corresponding folders, Mupen seems to have spread quite widely on my system anyway. :D

The contents of that mupen64plus folder indicates to me that the update didn't know what to do with that device.  Best to to load that community members 's updated ArkOS image that I linked above.

This is due to the way the stock ArkOS image provided with the R36s provisions some items which causes the update to not place the right files . Updating from the RG351MP image should have worked though so not sure what happened there. Try restoring the following file. This should resolve the N64 standalone issues.
1. Take the attached compressed file (arkosbackup.tar.gz) and put it in your roms/backup folder. Do not uncompress the contents! Just place the file as is in your roms/backup folder. If you don't have a backup folder in the roms folder, just create it.

2. Then go into the Emulationstation Menu, scroll to Options, hit A, then go to Advanced, hit A, then scroll all the way down to Restore Settings, hit A.

3. Once completed, you should be able to launch your n64 games using the standalone emulators.

arkosbackup.tar.gz
Also note, a community member by the name of Aeolus has an image specifically built for the R35s and R36s units with these fixes in place for those units. The links for those images are available here:
ArkOS_R35S-R36S_v2.0_12222023 (By Aeolus) https://drive.google.com/file/d/10z7j7IZ7WX3y10ZJBW_a2-agcIe1Dx9m/view?usp=drive_link https://www.mediafire.com/file/da4193t5vsjfsbr/ArkOS_R35S-R36S_v2.0_12222023.img.xz/file
More information about this image and further discussion and further developments related to the R35s/R36s units are available on the Retro Handheld Discord. https://discord.gg/retrohandhelds

hi cristian, im having an issue writing these 2 files (erroring at 90%), tried etcher and win32diskmanager.

Head to the gameconsole-r35s-r36s channel in the Retro Handhelds Discord for assistance with that image.  It's not one I maintain or support.

This is due to the way the stock ArkOS image provided with the R36s provisions some items which causes the update to not place the right files . Updating from the RG351MP image should have worked though so not sure what happened there. Try restoring the following file. This should resolve the N64 standalone issues.

Take the attached compressed file (arkosbackup.tar.gz) and put it in your roms/backup folder. Do not uncompress the contents! Just place the file as is in your roms/backup folder. If you don't have a backup folder in the roms folder, just create it.
Then go into the Emulationstation Menu, scroll to Options, hit A, then go to Advanced, hit A, then scroll all the way down to Restore Settings, hit A.
Once completed, you should be able to launch your n64 games using the standalone emulators.

arkosbackup.tar.gz
Also note, a community member by the name of Aeolus has an image specifically built for the R35s and R36s units with these fixes in place for those units. The links for those images are available here:
ArkOS_R35S-R36S_v2.0_12222023 (By Aeolus) https://drive.google.com/file/d/10z7j7IZ7WX3y10ZJBW_a2-agcIe1Dx9m/view?usp=drive_link https://www.mediafire.com/file/da4193t5vsjfsbr/ArkOS_R35S-R36S_v2.0_12222023.img.xz/file
More information about this image and further discussion and further developments related to the R35s/R36s units are available on the Retro Handheld Discord. https://discord.gg/retrohandhelds

Hi,
Thank you for the support. I am new in the handheld emulation world so sorry if my question sounds dumb. After updating the ArchOS for my r36s; it stopped starting standalone emulators; so would this method also work for psx and dreamcast? Thank you!

Yes.  Also, don't use the sd cards that came with the unit.  They will fail quickly.  Source your own good quality SD cards that are known to work with the r36s.  The unit is sensitive to sd cards so refer to the compatibility list here for known good working SD cards for the unit.

Yes. Also, don't use the sd cards that came with the unit. They will fail quickly. Source your own good quality SD cards that are known to work with the r36s. The unit is sensitive to sd cards so refer to the compatibility list here for known good working SD cards for the unit.

Thank you so much!


amount of a paiement

Hello !
Thank you for your code.
I have a question about:
      stripeOptions: {
        // see https://stripe.com/docs/stripe.js#element-options for details
      }

I don't find the amount of the paiement in the document. Can you give me an example of a simple transaction ?
Thanks !

i found the solution with https://github.com/cartalyst/stripe-laravel/tree/master in php laravel with the token of this project vue.js
Thanks


Nits in CI

Description of changes

Build the relevant cedar-examples branch during testing (cedar-examples release branch added in cedar-examples#68)
Add a README badge for the nightly cargo audit

Disclaimer
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Update: I believe the CI failure will be resolved by cedar-examples#67. Will re-run once merged.


make osqp-eigen cmake fetch friendly

Pre-fixes includes and sources with current source dir, removes headers from library target, ref #116
Copy pastes AddUninstallTarget.cmake from robotology/ycm/issues/169, ref #115

reset CMake to default, see https://github.com/robotology/osqp-eigen/issues/116#issuecomment-1066599697. #115 still persists

Thanks! Good for me (even if we need to merge with squash to avoid problems).

cc @GiulioRomualdi

Thank you @mhubii! I'm going to merge it with squash


Vnode lifecycle

With the following code, lifecycle events oninit, oncreate, onbeforeremove and onremove are never called on the <p> with key omytta:
var data = {
  flag: false
}

var App = {
  view: function (v) {
    return [
      m('p', `Click the button and watch the console:`),
      m('button[type=button]', {
        'onclick': () => data.flag = !data.flag
      },
        `Toggle flag`
      ),
      (data.flag ?
        m('p', {
          key: 'omytta',
          oninit        : function (v)    {console.log('oninit') },
          onbeforeupdate: function (v, o) {console.log('onbeforeupdate') },
          oncreate      : function (v)    {console.log('oncreate') },
          onupdate      : function (v)    {console.log('onupdate') },
          onbeforeremove: function (v)    {console.log('onbeforeremove') },
          onremove      : function (v)    {console.log('onremove') },
        },
          `Flag is true.`
        )
        :
        m('p', {
          key: 'kjfklej'
        },
          `Flag is false.`
        )
      )
    ]
  }
}

m.mount(document.body, App)

Expected output:
oninit
oncreate
onbeforeremove
onremove

Actual output:
onbeforeupdate
onupdate

Fiddle here.

This ties into #1713 and #1720, keys only work in list context, which Mithril implicitly creates in some instances. #1720 as it is would not fix this case, though.

as @barneycarroll explains in #1713 wrapping the ternary in an array solves it. https://jsfiddle.net/dy36s92z/4/

@andraaspar Actually, I had missed it but you are mixing keyed and unkeyed nodes, which is not supported.
https://jsfiddle.net/dy36s92z/6/ runs the hooks as you'd expect.
var data = {
  flag: false
}

var App = {
  view: function (v) {
    return [
      m('p', `Click the button and watch the console:`),
      m('button[type=button]', {
        'onclick': () => data.flag = !data.flag
      },
        `Toggle flag`
      ),
      [(data.flag ? // <========  note the bracket here ========
        m('p', {
          key: 'omytta',
          oninit        : function (v)    {console.log('oninit') },
          onbeforeupdate: function (v, o) {console.log('onbeforeupdate') },
          oncreate      : function (v)    {console.log('oncreate') },
          onupdate      : function (v)    {console.log('onupdate') },
          onbeforeremove: function (v)    {console.log('onbeforeremove') },
          onremove      : function (v)    {console.log('onremove') },
        },
          `Flag is true.`
        )
        :
        m('p', {
          key: 'kjfklej'
        },
          `Flag is false.`
        )
      )] // <===========  and here ===========
    ]
  }
}

m.mount(document.body, App)

Closing this since it is actually not a Mithril bug. This doesn't change the fact that it would be nice to have keyed nodes work also in non-list contexts. but we'll discuss that in #1720..


debug toolbar slowing down postman API requests

I’ve just realised that the debug toolbar is very much slowing down my postman API requests (25s. vs 2-3s. without)... it’s due to the SQL queries tracker I believe... same problem on the website but I can deactivate SQL... how to deactivate it as well when receiving API calls?

You can write your own custom function for SHOW_TOOLBAR_CALLBACK that would exclude it.


Bug in exporting depth images using ns-render

Describe the bug
I found exporting RGB images works well, but when it comes to depth images, it may fail.
I think the error comes from the code for saving depth.
When we save RGB images, variable image is a numpy array with shape (H, W, 3), and its range is 0~1, so it works well.
However, when we are saving depth images, image is a numpy array with shape (H, W, 1), and its range is >0 (but may larger than 1).
I think maybe we could save depth by scaling up real depth values by a large factor (e.g. 1000), and then save it in uint16 format?
To Reproduce
I checked this error by inspecting the image variable as shown below:

An example:
device=0
attr = "depth"
ckpt_dir = "reproduce_output"

CMD_RENDER = f"""CUDA_VISIBLE_DEVICES={device} ns-render \
--load-config {ckpt_dir}/config.yml \
--rendered-output-name {attr} \
--traj filename \
--camera-path-filename ./experiments_nerfs/scannet_blender/cameras.json \
--output-path {ckpt_dir}/render_{attr}/output.mp4 \
--output-format images"""

I found adding image = image.squeeze() before saving may temporarily address the issue, but it saves in uint8 and losses the precision. Maybe we should write extra codes for saving depth images??

Duplicate #862


Cannot Load Config

Loading OCI config:
File "C:\Users*\Desktop\oci_auto.py", line 61, in
config = oci.config.from_file(file_location="/config")
File "C:\Users*\AppData\Local\Programs\Python\Python310\lib\site-packages\oci\config.py", line 107, in from_file
raise ConfigFileNotFound("Could not find config file at {}, please follow the instructions in the link to setup the config file https://docs.cloud.oracle.com/en-us/iaas/Content/API/Concepts/sdkconfig.htm".format(expanded_file_location))
Getting this error when I run the python script. The script, config file, and .pem are all sitting on my desktop, but it looks like line 61 invokes the OCI config file? I'm not sure whats happening. Did I miss a step?

Changed line 61 from /config to double escaped absolute path of my config


Add clang-tidy to continuous integration

clang-tidy throws a few warnings that I'm not sure if we should fix, or ignore

Can you elaborate on the which warnings you are talking about and links to the code they triggers on?

Can you elaborate on the which warnings you are talking about and links to the code they triggers on?

In particular use of "magic" numbers in Zivid Settings initialization, such as:
https://github.com/zivid/cpp-extra-samples/blob/fb211e2b8daa8fcac2a0a4b995214952fe1865c8/source/Camera/Basic/CaptureHDRCompleteSettings/CaptureHDRCompleteSettings.cpp#L26
throws https://dev.azure.com/zivid-devops/cpp-extra-samples/_build/results?buildId=3049&view=logs&j=78522f12-3432-53d9-a26c-09281b784bba&t=00999172-2923-5109-b879-17c38f1330bd&l=5789
Also error: do not use array subscript when the index is not an integer constant expression; use gsl::at() as in (line 45)
https://github.com/zivid/cpp-extra-samples/blob/fb211e2b8daa8fcac2a0a4b995214952fe1865c8/source/Camera/Basic/CaptureHDRCompleteSettings/CaptureHDRCompleteSettings.cpp#L41-L45

I would disable the magic number test and just not use C-arrays at all.

You can use vector or array and the .at() member function that do bounds checking.

This is now clean in local CI.
Some decisions have been discussed on Teams, for example disabling magic-number rule.
Two rules are disabled that I didn't want to:
-cppcoreguidelines-pro-bounds-pointer-arithmetic,

disabled because CameraUserData (basic sample copied from SDK) uses argv. An alternative is to use Clipp. I have another PR for that. It seems a bit excessive to ask customers to download the .hpp file and add path. I wonder if we can simply host it.

-cppcoreguidelines-pro-type-union-access,

PCL library has defined it's point access a bit unfortunate. This causes to use union member to access the variable. We could probably rewrite it and compose the float it maps to, but that code is not going to be pretty.

This is now clean in local CI.
Some decisions have been discussed on Teams, for example disabling magic-number rule.
Two rules are disabled that I didn't want to:
-cppcoreguidelines-pro-bounds-pointer-arithmetic,

disabled because CameraUserData (basic sample copied from SDK) uses argv. An alternative is to use Clipp. I have another PR for that. It seems a bit excessive to ask customers to download the .hpp file and add path. I wonder if we can simply host it.

-cppcoreguidelines-pro-type-union-access,

PCL library has defined it's point access a bit unfortunate. This causes to use union member to access the variable. We could probably rewrite it and compose the float it maps to, but that code is not going to be pretty.

Is it possible to ignore these per code line for the lines that cause them (and then enable in general)? Would that be ugly?

Just pushed a commit that allows us to bring back cppcoreguidelines-pro-bounds-pointer-arithmetic. We can probably do //NOLINT for the union usage errors. Was only a handful number of lines

Suggestion:
for(size_t i = 0; i < cloud.points.size(); ++i)
{
    auto point = pointCloud.operator()(i);

    cloud.points[i].x = point.x;       // NOLINT(cppcoreguidelines-pro-type-union-access)
    cloud.points[i].y = point.y;       // NOLINT(cppcoreguidelines-pro-type-union-access)
    cloud.points[i].z = point.z;       // NOLINT(cppcoreguidelines-pro-type-union-access)
    cloud.points[i].r = point.red();   // NOLINT(cppcoreguidelines-pro-type-union-access)
    cloud.points[i].g = point.green(); // NOLINT(cppcoreguidelines-pro-type-union-access)
    cloud.points[i].b = point.blue();  // NOLINT(cppcoreguidelines-pro-type-union-access)
}

Branch CI is now clean. If we complete the review then I can rebase and fix the final problems.

I am not sure if you are waiting for me or plan to do more before this is ready for review again. If you are waiting for me let me know.
This branch is out of date, update it before next review round.


FATA[0000] Failed to build operator binary: failed to exec []string

Bug Report

What did you do?

I'm trying to execute the command (docker push <DOCKER_REGISTRY_URL>/<USER_NAME>/siddhi-operator:) but it's failing with below error.
`panic: modindex.GetPackage called with empty modroot
goroutine 19 [running]:
cmd/go/internal/modindex.GetModule({0x0, 0x0})
/usr/local/Cellar/go/1.19.3/libexec/src/cmd/go/internal/modindex/read.go:157 +0x125
cmd/go/internal/modindex.GetPackage({0x0, 0x0}, {0xc0000ee680, 0x7e})
/usr/local/Cellar/go/1.19.3/libexec/src/cmd/go/internal/modindex/read.go:135 +0x31
cmd/go/internal/modload.scanDir({0x0?, 0x7e?}, {0xc0000ee680, 0x7e}, 0x0?)
/usr/local/Cellar/go/1.19.3/libexec/src/cmd/go/internal/modload/load.go:2105 +0x4b
cmd/go/internal/modload.(*loader).load(0xc000155380, {0x172f930, 0xc0000b2000}, 0xc000155520)
/usr/local/Cellar/go/1.19.3/libexec/src/cmd/go/internal/modload/load.go:1734 +0x35f
cmd/go/internal/modload.(*loader).pkg.func1.1()
/usr/local/Cellar/go/1.19.3/libexec/src/cmd/go/internal/modload/load.go:1517 +0x29
cmd/go/internal/par.(*Queue).Add.func1()
/usr/local/Cellar/go/1.19.3/libexec/src/cmd/go/internal/par/queue.go:58 +0x7d
created by cmd/go/internal/par.(*Queue).Add
/usr/local/Cellar/go/1.19.3/libexec/src/cmd/go/internal/par/queue.go:56 +0x225
FATA[0000] Failed to build operator binary: failed to exec []string{"go", "build", "-o", "/Users/kailash.patil/Downloads/operator-sdk-v0.19.0/operator-sdk/vendor/github.com/siddhi-io/siddhi-operator/build/_output/bin/siddhi-operator", "-gcflags", "all=-trimpath=/Users/kailash.patil/Downloads/operator-sdk-v0.19.0/operator-sdk/vendor/github.com/siddhi-io", "-asmflags", "all=-trimpath=/Users/kailash.patil/Downloads/operator-sdk-v0.19.0/operator-sdk/vendor/github.com/siddhi-io", "-mod=vendor", "Users/kailash.patil/Downloads/operator-sdk-v0.19.0/operator-sdk/vendor/github.com/siddhi-io/siddhi-operator/cmd/manager"}: exit status 2 `
What did you expect to see?

Command executed successfully and image is created.
What did you see instead? Under which circumstances?

Encountered issue while executing the command.
Environment
Operator type:

/language go

Kubernetes cluster type:

docker-desktop
$ operator-sdk version

operator-sdk version: "v0.19.0", commit: "8e28aca60994c5cb1aec0251b85f0116cc4c9427", kubernetes version: "v1.18.2", go version: "go1.13.10 darwin/amd64"
$ go version (if language is Go)

go version go1.19.3 darwin/amd64
$ kubectl version

Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.6", GitCommit:"dff82dc0de47299ab66c83c626e08b245ab19037", GitTreeState:"clean", BuildDate:"2020-07-15T16:58:53Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"darwin/amd64"}
Possible Solution

Additional context

@KailashPatilKP do you have to use Operator SDK version v0.19.0? That is a version we no longer support and I would highly recommend trying to upgrade and use the latest release of Operator SDK which is version v1.25.2.
If you absolutely need to use Operator SDK version v0.19.0 it seems like this is related to using a Go version that wasn't intended to be used when building it from source. From the version information it seems to me that Operator SDK v0.19.0 is intended to be built with Go v1.13, but it appears you are attempting to build it with Go v1.19. My recommendation would be to try building the binary with Go v1.13 and see if that works.
I hope this helps!

Additionally, I would also highly recommend to either scaffold the project in the GOPATH or activate module support. This error usually happens in Go when it assumes that the package is outside a module (https://cs.opensource.google/go/go/+/refs/tags/go1.19.3:src/cmd/go/internal/modindex/read.go;l=157). However, maintaining the supported SDK+Go version compatibility will be helpful to avoid any unexpected errors.


Windows Audio Device Graph Isolation High CPU/High RAM

OS: Windows 10
Issue Descriptions:  Windows Audio Device Graph Isolation is eating CPU and RAM when GPMDP is running. It usually sits at 3.6 gb of RAM when I notice it. It happens every time  I use the program.
Steps to Reproduce: Using the GPMDP and listening to music causes high RAM usage. I think it also may have something to do that I have Dolby Digital Plus on my Laptop. I have Lenovo Y50-70.

This is one of those "Out of my control can't really fix" issues.  You're probably correct and it is something to do with DDP or your audio drivers or maybe even an issue at the Windows level.  But if it isn't even one of my processes eating up the resources there is absolutely nothing I can do about it 😢


HBASE-24221 Support bulkLoadHFile by family

Support bulkLoadHFile by family to avoid long time waiting of bulkLoadHFile because of compacting at server side

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 31s
Docker mode activated.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
4m 33s
the patch passed

+1 :green_heart:
compile
1m 15s
the patch passed

+1 :green_heart:
javac
1m 15s
the patch passed

-1 :x:
shadedjars
5m  1s
patch has 10 errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 53s
hbase-server in the patch failed.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
4m  0s
the patch passed

+1 :green_heart:
compile
1m  6s
the patch passed

+1 :green_heart:
javac
1m  6s
the patch passed

+1 :green_heart:
shadedjars
5m 33s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 51s
hbase-server in the patch failed.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
3m 58s
the patch passed

+1 :green_heart:
compile
1m  5s
the patch passed

+1 :green_heart:
javac
1m  5s
the patch passed

+1 :green_heart:
shadedjars
5m 20s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 39s
hbase-server in the patch failed.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
4m 36s
the patch passed

+1 :green_heart:
compile
1m 15s
the patch passed

+1 :green_heart:
javac
1m 15s
the patch passed

+1 :green_heart:
shadedjars
6m  7s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 50s
hbase-server in the patch failed.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
4m 34s
the patch passed

+1 :green_heart:
compile
1m 16s
the patch passed

+1 :green_heart:
javac
1m 16s
the patch passed

+1 :green_heart:
shadedjars
6m  6s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 49s
hbase-server in the patch failed.


Generate full manifest last

The makefile calls kustomize twice in the manifests directory, and
leaves the last kustomization.yaml file there when it finishes. This
change swaps the order so that the more useful file (the one that
generates hnc-manager.yaml) is the one that's left so that developers
can play with it if necessary.
Tested: both yaml files are still created and the expected
kustomization.yaml file is left behind.

/assign @yiqigao217
/assign @GinnyJI
/cc @rjbez17

/lgtm
/hold
/assign @yiqigao217


new header system strange behaviour

Short description of the problem:
wrong z-index of headers on layout like this:
tabs page with header -> tab with header -> nav.push page with header on android
also when i change pages with setRoot from side menu "hamburger icon flickering (hide+show new) appears"
What behavior are you expecting?
nav of sub sub page at the top, but not at bottom of z-index stack
not flickering menu/back icon
Steps to reproduce:

create ion-tabs page with header and nav in it
create ion-tab pages with headers and nav in it
create subpage from one of the on-tab pages with header and nav in it

possible temporary solution
ion-header + ion-tabs {
    z-index: 11;
}

Which Ionic Version? 1.x or 2.x
2.beta 10
Plunker that shows an example of your issue
http://plnkr.co/edit/FXwvyk38oqdG1yiuXCrj?p=preview
Run ionic info from terminal/cmd prompt: (paste output below)
Cordova CLI: 6.1.1
Gulp version:  CLI version 3.9.1
Gulp local:   Local version 3.9.1
Ionic Framework Version: 2.0.0-beta.10
Ionic CLI Version: 2.0.0-beta.30
Ionic App Lib Version: 2.0.0-beta.16
OS: Windows 8.1
Node Version: v5.3.0

Hello, thanks for opening an issue with us! At this time it is not possible to use <ion-tabs> with other components. ion-tabs is meant to be used as a root component, in the sense that the template that has the ion-tabs should not have any other html. For an example of this you can start a tabs starter by running ionic start TabsExample tabs --v2 and looking at the tabs.html file in the tabs folder. We are considering creating a standalone tab bar that will be able to be used anywhere in an ionic 2 app, but at this time it is not on our roadmap officially. This should have not worked before beta.10, and is something that was fixed by the beta.10 refactor, so i am sorry for any confusion this causes. Thanks for using Ionic!

@jgw96 is there a way to move searchbar under tab-bar?
here is screen https://drive.google.com/file/d/0B-f6Y6ba1-_QMUlaQzFqV2w5aXM/view?usp=drivesdk
it's setRoot(TodayPage) where today page is:
<ion-tabs [preloadTabs]="false" [selectedIndex]="mySelectedIndex" business-law-2>   <ion-tab [root]="tab1Root" tabTitle="Задачи" tabIcon="clipboard" [tabBadge]="notificationsCount.tasks" tabBadgeStyle="business-law-1"></ion-tab>   <ion-tab [root]="tab2Root" tabTitle="Уведомления" tabIcon="notifications" [tabBadge]="notificationsCount.documents" tabBadgeStyle="business-law-1"></ion-tab>   <ion-tab [root]="tab3Root" tabTitle="Просроченное" tabIcon="alarm" [tabBadge]="notificationsCount.late" tabBadgeStyle="danger"></ion-tab> </ion-tabs>
and header of inner tab page is:
`

Просроченные

<ion-toolbar business-law-2 *ngIf="showSearch == true" no-border-top>
<ion-searchbar
[debounce]="10"
[(ngModel)]="queryText"
(ionInput)="updateSchedule(false)"
[hideCancelButton]="shouldHideCancel"
placeholder="Поиск"
>

...`
i can move tab bar to bottom, but it's not so materialish it's more ios-like


Add support for AutoEnzyme(mode=nothing)

Extensions

Add AutoEnzyme{Nothing} to the dispatches for forward mode in the following operators: pushforward, jacobian
Add AutoEnzyme{Nothing} to the dispatches for reverse mode in the following operators: pullback, gradient
Make AutoEnzyme pick the mode field from the backend object in more cases

Tests

Add first-order tests for AutoEnzyme(mode=nothing)

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

Project coverage is 95.90%. Comparing base (5161e56) to head (aed76a5).

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #211      +/-   ##
==========================================
- Coverage   96.39%   95.90%   -0.50%
==========================================
  Files          65       15      -50
  Lines        3554     1562    -1992
==========================================
- Hits         3426     1498    -1928
+ Misses        128       64      -64

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


config_path() does not exist in Lumen

See service provider:
https://github.com/HipsterJazzbo/Landlord/blob/master/src/LandlordServiceProvider.php
I don't think config_path() is available in Lumen at all.

Maybe something like:
return app()->basePath() . '/config' . ($path ? '/' . $path : $path);
Not sure how other package maintainers do it.

I think this project is abandoned. Too long for an answer or a fix. The package description says Lumen but it's not compatible at all.

This package is most certainly not abandoned, I use it in a dozen projects. Apologies for the delay this month, I've been really sick.
Fixed in v2.0.3 (cf3a456e1d6d4e2f201ddc06cf49415270279f06).


Allowed submission per day hack

You can bypass the restriction of allowed submissions per day or per person by deleting your submissions.

Using the resources interface? Is that allowed for non-admins?

Using the resources interface? Is that allowed for non-admins?

Yes, if you are admin, you can delete a submission

Seems not a problem now as only admins can delete submissions.


Warn against AsyncNotifier.update misuses

class Example extends AsyncNotifier<int> {
 ...

  void fn() {
    state = AsyncLoading(); // KO, "update" will likely never complete
    update((data) => ...);
  }

  void fn() {
    update((data) {
      state = AsyncLoading(); // OK
       ...
    });
  }

  void fn() {
    update((unused) => ...); // the parameter should be used. Otherwise use AsyncValue.guard
  }

}

@rrousselGit
I am trying to update the state of a FamilyAsyncNotifier partially, I just want to know whether I am doing it right. Also in this case of updating a asyncvalue partially, I want to know what's differences in using whenData, AsyncGuard.value and update method . It would be a immense help, if you provide some clarity on this.
update((state) async {
List students =
await ref.read(collegeProvider).getCollegeById(id: this.arg);
return state.copyWith(students: students);
});

With mutations, this is really low-priority. Closing


alchemy/zippy: "^0.3" forces minimum PHP to 7.1

The dependency alchemy/zippy: "^0.3" includes doctrine/collections: "~1.0" which slides up to current doctrine/collections version 1.5 which has a hard requirement for PHP 7.1.
As far as I can tell, alchemy/zippy works great for doctrine/collections <1.5.
So, two options going forward:

This project just has a hard dependency on PHP 7.1, no support for PHP 5.6
We do some composer ju-ju to force this "grandchild" dependency of doctrine/collections to <1.5.

Noting here that installing via
composer install --no-interaction --ignore-platform-reqs

blasts past this issue.

I let the zippy project know over here: https://github.com/alchemy-fr/Zippy/issues/136

Same problema here!


Figure: Haplotype ages and inference of spread

Revisit the figure using haplotype age distributions within outbreaks to present evidence for direction of spread. Revisions for partner review.

Resolved via #93.


build failed by undefined: gitlab.ListDescendantGroupsOptions on branch projectgroups

I want use your create group feature https://github.com/zaquestion/lab/pull/450.
But when I run go build on branch projectgroups. The error throws:
xx@xxs-MacBook-Pro lab % go get
go: downloading github.com/inconshreveable/mousetrap v1.0.0
go: downloading google.golang.org/appengine v1.6.6
go: downloading github.com/golang/protobuf v1.4.2
go: downloading google.golang.org/protobuf v1.25.0
# github.com/zaquestion/lab/internal/gitlab
internal/gitlab/gitlab.go:769:27: lab.Groups.ListDescendantGroups undefined (type *gitlab.GroupsService has no field or method ListDescendantGroups)
internal/gitlab/gitlab.go:769:62: undefined: gitlab.ListDescendantGroupsOptions

I can't figure out how to resolve this..

Hi @huhuang03,
This branch/merge request is outdated wrt go-gitlab version that contains the Groups.ListDescendantGroups support.
Try to change the following line:
https://github.com/zaquestion/lab/blob/62523a3a712276b9a532e2ce92418a3dc6a7c476/go.mod#L25
to point to version 0.38.2 instead.

This issue should be solved by the current state of the pull request.


Migrate glib to 2.64.6 and add ppc64le build

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

CC @ryanvolz

Thanks!


[WIP] JS refactor->rename for named variables, members and functions in a single file

This PR implements "rename" functionality in JS mode to enable intelligent rename feature by using Terns scope analysis and inference functions. Renaming across multiple files has been intentionally blocked for the time being as we are not analyzing all the JS files in current project root right now. Once the other PR #11948 is merged, we can leverage on the JS analysis in node and include all files to build symbol table.
The rename function works by selecting a variable def/ref or placing cursor in and using Ctrl+R.
Know issues
In a particular case Tern inference engine is picking up wrong hit. For example -
function fn1(error) {
     error.a = "abc";
     var a = "test";
     console.log(a);
}
If we try to rename a in line 3 or 4 , Tern picks up fake ref from line 2 as well.
Yet to be done

[ ] To enable context menu option for rename
[ ] Update JS doc and minor code cleanup
[ ] Couple of bug fixes ( one mentioned above and another to center primary selection )

Thanks a lot @petetnt for the quick review. I will try to address the comments asap. I would urge all of you to use the feature as well and let me know if it's helpful.

From the code, this seems to work only for javascript files. I assume languages that derive from javascript in CodeMirror are NOT supported (for example json, typescript, ...)
Is it possible for extensions to easily override this behaviour so to support other languages?

@ficristo Yes, it's targeted for javascript mode.  So if CM identifies any block of code as javascript,  this would work there.  That includes script blocks in html,  any modes derived from JS by CodeMirror.  BTW,    is there any extension available today which implements this feature?

@ficristo Yes, it's targeted for javascript mode.  So if CM identifies any block of code as javascript,  this would work there.  That includes script blocks in html,  any modes derived from JS by CodeMirror.  BTW,    is there any extension available today which implements this feature?

@swmitra  Can you post a gif of how this works?

@abose I am not able to post a gif right now as I dont have access to any computer for a few days.  But what you can do is - put the cursor on top of the token you want to rename.  Then press ctrl+r . This will put selection on all the occurrences after doing a scope analysis.  Now just type the new name.  You will see multi cursor in action and should be able to rename all the occurrences.

👍 Cool feature

is there any extension available today which implements this feature?

Looking at #11658 maybe ternific?


Support deep-linking with a github repo link.

Would be awesome to be able to paste a github url into the Enter a github repo link and then get a share type link which changes the URL of the page.
Can send to someone with a copy/paste and share the invalid package.json result with others...

That would be great, accepting PRs!
Note that per #79, the webpage linked in the repository's About is no longer active. But you can still clone this repository locally and serve index.html with something like npx serve.


Fix: Remove unused imports

This PR

[x] removes unused imports

+1 thanks for helping clean up.


slow with batch size > 1

Hi,
I set max_batch_size = 3 and I want to speed up model with 3 input image as parallel instead serial,
But I converted the model with batch_size = 3 correctly, when I run trt_ssd.py, I achieve this results:
for 1 batch_size : process time is 0.002 sec with 1080 TI,
for 3 batch_size : process time is 0.006 sec with 1080 TI,
That means the system process as serial not parallel, why?

Does your processing time include image preprocessing?  (Do you get a different result with trt_ssd_async.py?)

time is only for trt_ssd.detect(img, 0.3).
I don't test with trt_ssd_async.py.
I do following steps:
1- change input size from (1,3,300,300) to (3,3,300,300)
2- change to builder.max_batch_size = 3
4- change self.context.execute_async(
batch_size=3,
bindings=self.bindings,
stream_handle=self.stream.handle)
Notice that when I comment self.stream.synchronize() in the ssd.py, I get first few result with 0.002 sec and then the time is growing then reach to 0.06, and then the line self.stream.synchronize() remain uncomment, I get 0.06 for all result, why?

Instead of timing the whole trt_ssd.detect() function, I think it makes more sense for you to only time the "cuda.memcpy_xxx"s, "context.execute_async" and "cuda.stream.synchronize" in that function.
By the way, the "self.stream.synchronize" call cannot be commented out.  Otherwise, you cannot be sure GPU has finished processing the image.

This is my OCR custom model when I use batch_size = 1, I get 0.02 sec and when I use batch_size= 10, I get 0.2 sec, which means, this batch_size is done as serializing, not parallel, why?

All Time:  0.2079782485961914
Copy:  0.20590543746948242
75U72866
All Time:  0.20735740661621094
Copy:  0.2055220603942871
75U72866
All Time:  0.20698094367980957
Copy:  0.20568513870239258
75U72866
All Time:  0.2071824073791504
Copy:  0.1931319236755371
75U72866
All Time:  0.19458580017089844
Copy:  0.004555463790893555
75U72866
All Time:  0.00600123405456543
Copy:  0.4196054935455322
75U72866
All Time:  0.4210531711578369
Copy:  0.2052767276763916
75U72866
All Time:  0.20674490928649902
Copy:  0.20600008964538574

Duplicated issue: https://github.com/jkjung-avt/tensorrt_demos/issues/106