New and improved IK in Skeleton3D

This pull request lays the groundwork for the new and improved IK in Godot. This includes behind the scene changes, as well as the IK code itself.

Note: See this branch for the verbose commit log for commits 1-7: https://github.com/TwistedTwigleg/godot/tree/GSOC_2020_Working_Branch_IK_VERBOSE_ARCHIVE
The first 7 commits are squashed changes from the verbose log, bringing the commit count from 91 to just 7. Commits after commit 7 are new changes added on top of the changes in the verbose archive linked above.

Below is a list of everything that has been added, removed, or otherwise changed. The list is in no particular order.

Changes:

Added a SkeletonModifier3D class

This class, which extends Resource, will be the basis of the new IK solvers in Godot, and potentially even the PhysicalBone3D. This class is a virtual class that is intended to be extended.
Because the SkeletonModifier3D class extends Resource, it should be able to be saved to a file. This should make it easier for imported skeletons.
All of the new IK solvers will use this class, allowing IK to be nicely managed by the Skeleton3D node.
The Skeleton3D class has new functions to allow for adding, removing, and changing SkeletonModifier3D resources.
The Skeleton3D has a single slider that controls the interpolation for the modifications attached to it. This could change in the future.
In theory, it should also be extendable through GDScript, however this is not required to use the SkeletonModification3D classes.

I can now confirm, this indeed does work! This should make it possible for Godot users to make custom SkeletonModification3Ds that work alongside the existing, built-in solutions.

SkeletonModification3D resources can be applied in the Editor, through newly exposed properties. The process should be easy and straightforward.
Ideally, all SkeletonModification3D resources are compatible with each other, allowing for configurable, fully-body IK solutions.
Has a clamp_angle function, taken from the 2D IK PR. This is used by CCDIK to constrain the angles. Potentially, it may be possible to use with other modifications.
The modifications can be configured to run in either _process or _physics_process. Some modifications have options that only are available in _physics_process.

This was previously a modification stack setting, but now its been moved to each individual modification. This allows for mixing and matching modification execution modes.

|

Added a SkeletonModifierStack3D class

This class, which extends Resource, holds all of the SkeletonModification3D resources that are going to be applied to a Skeleton3D.
Contains the global settings, like the strength the modifications are applied at, whether all of the modification are enabled, etc.
Because this class extends Resource, it can be saved to a file! This allows for easily saving SkeletonModification3D data, which is especially important for imported Skeletons3D nodes.
When duplicated, the modification stack will be made unique and so will all of its modifications. This is so IK and modifications work with instanced scenes, as each modification stack needs to only execute on a single Skeleton3D node in order to work.

This is a limitation of using Resource as the base class for the modifications and modification stack. However, in game development projects using IK, you often want it to be unique to each instance anyway, unless you are looking to mirror the animation across a bunch of different meshes (a very niche use case).

|

Added a SkeletonModifier3DLookAt class

The simplest of the bone modifiers but can be very helpful. This modifier rotates a bone to look at a target.
Because of its relatively simplicity, it has been extremely helpful for debugging and implementation purposes.
Has options for applying additional rotation, or ignoring rotation on certain axes.

|

Added a SkeletonModification3DCCDIK.

Uses the CCDIK algorithm to solve the IK chain. CCDIK is ideal for joints that are generally more robotic or have relatively mechanical motion requirements.
The SkeletonModification3D_CCDIK operates as a chain of bones, rather than each individual modification being for a single bone. Each CCDIK joint in the chain, where each joint is a single bone in the Skeleton3D, has options that can be fully configured in the Godot editor.
Has fully functioning hinge-constraints, which have configurable angle settings. The constraints can also be inverted, allowing for full, 360 degree control over the hinge constraint and how it restricts the CCDIK joints.
Has an option to enable or disable high quality mode. This is enabled by default.

High quality mode iterates over each joint in the chain, solving it and all it's children joints before moving onto the next. This gives a nicer, more natural looking result, at the cost of being more computationally expensive. Because of this, it can be disabled to save performance, though the results may not look as good.

I've rewritten the solver three times! Yikes! I'm hoping, fingers crossed, that the current implementation stays stable and continues to work moving forward. CCDIK is kinda finicky to implement, but I think I've finally nailed it. The results look very similar to my GDScript-powered prototype now and the code is similar to the working 2D CCDIK solver.

|

Added SkeletonModification3DFABRIK.

Uses the FABRIK algorithm to solve the IK chain. FABRIK is ideal for all sorts of situations, and is the same algorithm as the one used in the SkeletonIK node (though I implemented it slightly differently).
The joints in the FABRIK chain are easily configurable, with sane defaults to make getting FABRIK running quick and easy.

For all but the leaf/tip bones in the chain, the modification can auto calculate the bone length using the information provided from the Skeleton. For leaf/tip bones, the length can either be entered manually or a "tip" node (like a BoneAttachement3D) can be used to calculate the length.
The chain tolerance and max iterations are configurable from the editor, with defaults that resemble those seen in SkeletonIK. This allows for lowering the iterations and raising the threshold for projects that do not require precise IK solving, improving performance.

Has configurable magnet positions for all but the origin bone in the FABRIK chain.
The final joint in the chain can use the target's Basis rather than have FABRIK calculate it, similar to the SkeletonIK node.
Exposes settings for adjusting the roll (or twist) of the bones, since FABRIK does not take the existing bone roll/twist into account when solving. This allows the user to control the roll/twist used in the final result.

|

Added SkeletonModification3DJiggle

Uses jiggle physics to move the joint relative to a target. Helpful for long hair, edges of clothing, etc. Is primarily used for complementary, dynamic animations.
Works in a chain, just like FABRIK and CCDIK. Has default options that are applied to each joint in the chain, though these can be overridden on a per joint basis.
Has physics collider/shape support! It will not rotate into physics objects.

Uses raycasting to check for colliders/shapes. Exposes a collision mask to allow for defining which colliders/shapes are taken into account.

Exposes settings for adjusting the roll (or twist) of the bones, since the Jiggle modifier does not take the existing bone roll/twist into account when solving. This allows the user to control the roll/twist used in the final result.

|

Added SkeletonModification3DTwoBoneIK

A simpler, general more stable solver that only operates on two bones using the law of cosigns to solve.
Is great for arms, legs, and any other joint that is usually only composed of two joints.
Joint lengths can be auto calculated or manually inputted, making it easy to get it setup and working.
Has an option for setting a node as a pole vector, controlling the bend direction.

This should, when finished, make the TwoBoneIK solver much more usable for arms, legs, etc.

Exposes settings for adjusting the roll (or twist) of the bones, since TwoBoneIK does not take the existing bone roll/twist into account when solving. This allows the user to control the roll/twist used in the final result.

|

Added SkeletonModification3DStackHolder

This is a simple modification that allows users to use more than one modification stack with a single skeleton. Can be helpful for organization and modification reuse.
Known limitation: A stack holder modification can only execution modifications in the stack it's holding if the modification execution mode lines up with the stack holder modification's mode.
I'm not 100% positive how much use it will get though, but I can see how if you need it for your project, it would be helpful to have. The code is also pretty simple and straightforward, so adding and maintaining it shouldn't be difficult. It did create the necessity to have per-modification execution modes though.

|

The Bone struct now includes a local_pose_override.

The new local_pose_override transform works just like the global_pose_override transform, but the transform is assumed to be a transform relative to the parent rather than a global position.

This makes it much easier to rotate bones with IK, but still have them properly attached (no dislocated bones!)

Functions have be added to manipulate this transform, including getting the transform. There is also now a new function for getting the transform used in global_pose_override, for consistency.
Functions have been added to convert a local bone pose (like pose, rest, and local_pose_override) to a global bone pose, and vice versa. These functions make working with the bone transforms much easier, especially when used in conjunction with the helper functions added in #39126.
Initially, I was going to use a special transform akin to the global_pose_override, called modification_pose, but I found this led to dislocated bones that floated in the air. Additionally, it basically was just another global_pose_override. Using the new local_pose_override fixed the dislocation issue and the code is just as usable.
Functions very similarly to the global_pose_override, just uses a local bone pose instead of a global one. Has the same functions and capabilities.

|

The Bone struct now keeps track of its children bones, if it has any.

This is a rather large underlying change that required a fair amount of code refactoring, but in my testing, everything works exactly as before. However, this PR should probably be consider as compatibility breaking until heavily tested due to this change.
Functions have been added to take advantage of this change. In addition to there being functions for adding, removing, and retrieving bone children, there are also functions for updating the skeleton transforms from that bone down.

The function for updating a bone's transform and all of the children bones and their transforms is required for decent performance with iterative IK solvers, as the alternative would be to go through the entire skeleton each time.

This change removes the need to have a process list, as now the skeleton can be updated via going down the skeleton tree from a root, parent-less bone.
This change should also make generating the process order/list much more efficient, as it no longer needs to use a bubble sort. The generation and child assignment process only visits each bone once.

|

The process_list functions and related code have been removed.

They can be added back as deprecated functions though, if needed. Ideally, moving forward, code should take advantage of the bones being aware of their children.
The Skeleton3D editor gizmo that draws the bones in the editor still works as expected and now takes advantage of the parent-child information. Additionally, the Skeleton3D inspector also now correctly uses the parent-child information stored in the bones.

|

Refactored the BoneAttachment3D node.

Now Skeleton3D is not responsible for updating the BoneAttachment3D nodes! Once the PhysicalBone3D changes are also done, this will make the Skeleton3D class only responsible for being a Skeleton3D. The BoneAttachment3D node now handles updating itself to the correct bone positions.
The BoneAttachment3D node now updates based on a new signal, bone_pose_changed, which is emitted when the bone changes. From a end-user perspective, the node should function exactly the same as before.

The function that keeps the transform updated, on_bone_pose_update, is virtual. This allows GDScript users to extend it if needed. The reason behind this is that it allows users to offset BoneAttachment3D nodes via GDScript, something I have seen request a few times.

The BoneAttachment3D node now exposes the bone index, along with the bone name. This allows for setting the bone either through the dropdown, or by manually inputting the bone index.
The functions for binding nodes to bones, like bind_child_node_to_bone, in Skeleton3D have been removed! This is because they are no longer needed, were already marked as deprecated, and were not really used anywhere in the code base. For projects that use or need these functions, the new signal and a tiny bit of code should be usable to replicate the functionality. Technically this is compatibility breaking, but I do not believe very many projects used the binding functions directly.
BoneAttachment3D nodes can now override bone poses! This allows for modifying the bone poses from the node in real time.

This property is disabled by default, so any projects using BoneAttachment3D do not have to change anything.
This property may help eliminate confusion, as now it is obvious that when the property is disabled, it will NOT override the bone pose. I have seen confusion in beginners with the BoneAttachment3D node and modifying it, so hopefully adding this functionality and exposing it as a property will help.
Additionally, this makes it easier to move bones for those who do not want and/or understand the transform conversion system. It also gives a runtime option for manipulating bones that does not require the Godot editor (unlike bone gizmos or the Skeleton3D inspector, both which require the Godot editor to function)
The modes currently implemented are global_pose_override, local_pose_override, and custom_pose. The remaining poses could be added in the future if wanted/needed with relative ease.
An unintended feature: When set to local_pose_override, you can actually directly modify the results of IK in the editor! This gives an interesting level of control over how IK operates that was entirely accidental, but its a cool added bonus feature.
To keep overridden bones in the proper positions, overriding BoneAttachment3D nodes should be children of a BoneAttachment3D node that is following (not overriding) the parent bone. See scene nine in the test project for a working scene example.

The BoneAttachment3D node can now use external skeletons, no longer requiring it to be a direct child of a Skeleton3D node.

This is helpful for instanced scenes from 3D files, as now the BoneAttachement3D nodes can externally linked so they are not lost on re-import.
This property is disabled by default, so newly created BoneAttachement3D nodes expect to be children of a Skeleton3D node and function like they did previously.
This also allows BoneAttachment3D nodes to be children of other BoneAttachment3D nodes.
When the external skeleton property is enabled, if the BoneAttachment3D node is a child of another BoneAttachment3D node and a NodePath to a Skeleton3D has not already been assigned, it will automatically use the parent BoneAttachment3D's parent Skeleton3D node.

BoneAttachment3D now shows a configuration warning when it is not properly setup.

|

Added functions to Skeleton3D for getting the forward vector using the information stored in the rest pose for the bones. Also added a function for taking a Z-forward basis and converting it to the correct forward direction, allowing LookAt to be used with bones more easily.

Also added a signal that emits when a bone pose changes. The signal passes the index of the bone that changed along with it. This is a major part of how I was able to decouple the BoneAttachment3D node from Skeleton3D. This also has the benefit of allowing GDScript users to use the signal if needed, which can be helpful for Skeleton3D plugin creation (for example).

|

Added a function called rotate_to_align to Basis

This function works just like the rotate_from_vector_to_vector function I previously added in Quat, but uses a Basis instead.
This function can, and should probably, be optimized, as noted in the GitHub gist that the function is based on.
Exposed to GDScript and class reference for the function included.

|

Everything added, changed, or otherwise touched by this PR should be also be documented in the class reference.

|

Probably other little changes I have forgot! This is a rather big PR with lots of changes, and it is getting difficult to manage this post. I will try, however, to keep this list as accurate as possible.

Todo:

Convert the SkeletonIK node's code to a SkeletonModification3D Not needed! The SkeletonIK node will likely need to stick around for awhile so projects can be migrated.

A thought, and I have no idea how hard this would be: to make migration easier, have the SkeletonIK node work as a holder for a single SkeletonModification3D, kinda like a little independent-ish ModificationStack. Not sure how feasible or useful this would be though. Something to think about I suppose.

Investigate converting the PhysicalBone3D so it can function as a SkeletonModification3D (Paused for now)

This will involve making PhysicalBone3D a fully functioning, standalone node that works with the Skeleton3D node. See the 2D IK PR for a 2D version of what I plan to do for the PhysicalBone3D node.
Write a modification that mirrors the existing API for physical bones currently in the Skeleton3D node.
Add additional features!

Note the list above is in no particular order.
Known bugs/errors/problems:

Saving a scene with SkeletonModification3D resources attached to a Skeleton cause them to no longer work in the editor. Functionality returns upon reloading the scene, and this only occurs in the editor. Fixed/Workaround-found!

Possibly related to #24646. This PR, even with the fix/workaround, does not solve the problem in the linked issue, but rather it solves the problem just for the SkeletonModificationStack3D.

GDScript modifications do not work with @tool mode in the Godot editor, as you cannot assign them. If you remove @tool, you can assign it correctly but it will not work in the editor until you add @tool, in which case it will work from that point on.

I think this is a GDScript issue, but I'm not 100% certain.

The test project I am using can be found here. This project will evolve as I continue to work.
Disclaimer: This work is part of the GSOC 2020 program.

Reserved, in case the opening post gets too big

Rebased with the latest version of master, which removes the overlap with #39126.

// TODO: for now, fail silently because otherwise, the log is spammed with this error when saving the resource.
// however, in the future, see if there is a way to work around this.

You can use ERR_PRINT_ONCE.

Godot's PI constant is Math_PI in math_defs.h.

Godot Engine coding style uses PascalCase.

SkeletonModification3D_CCDIK
SkeletonModification3D_LookAt
SkeletonModification3D_FABRIK

There's an extra underscore.

@fire said:
You can use ERR_PRINT_ONCE.

Yeah, that might not be a bad idea for now. Ideally, I just need to fix the issue that causes that condition to fail, but until then, having an error print couldn't hurt.

Godot's PI constant is Math_PI in math_defs.h.

Awesome! That should fix AppVeyor not building then. I'll make the necessary adjustments.

Godot Engine coding style uses PascalCase.

Yeah. The only issue I have with using PascalCase with the modifications is that it makes it hard to read. For example:

SkeletonModification3D_FABRIK becomes SkeletonModification3DFABRIK

That said, I probably should change it, to stay consistent. I might leave it for a bit, just to make sure I do not make too many big (potentially breaking) changes at once. I will add renaming the classes to PascalCase to the TODO list though!

Missed one :D .\scene/resources/skeleton_modification_3d.h(190): error C2065: 'M_PI': undeclared identifier

Good eye! I'll fix it in the next commit :)

Good news, only formatting changes! Not errors. CICD green go-go.

Great! Now I just need to get FABRIK fixed (right now it's not working), implement two bone IK, fix the naming issue, and then I can open this PR up and start fixing bugs :smile:

I've been using the term effector to mean tip.
Rotation in a 360 fashion is named rotation
While rotation on the axis is called twist.
Naming things gets confusing with all the terms.

Alright, I think it's ready now! :tada:

There are still some minor bugs, and I'm sure more will pop up, but the groundwork is all there and everything seems to be working in my test project. With basically everything on the 3D side implemented and at least 90+ percent working, I figure now is a good time to open the PR up. I still am planing to continue to bug fix and polish things up though :+1:

Looking at the amount of commits, I wonder how I should squash them. I am definately going to make a backup PR once I start working on squishing things, as I really do not want to accidentally mess something up.
Maybe it would be easier to make another PR once everyone is happy with the changes? The first commit could be the changes to Skeleton3D, adding the base modification stuff, and any other non-modification related change, then each subsequent commit could be just a single modification. Or I suppose I could just squish everything together in a single commit.

Im excited to play with this, going to try to build later today or tomorrow. Do you think its possible to add spherical collisions or other collisions to jiggle bone. I found the below which seems to make it look simple. I would try to add it but I dont think im quite at the skill yet.
https://github.com/unity3d-jp/UnityChanToonShaderVer2_Project/blob/master/Assets/UnityChan/Scripts/SpringBone.cs
and the script that its based off of.
https://web.archive.org/web/20190705072513/http://rocketjump.skr.jp/unity3d/109
Thanks for the hard work :)

Thanks @NHodgesVFX!
It might be possible, and I do agree that the code linked does make it look relatively simple. The only part I'm not quite sure about is how to pass the colliders to the Jiggle bone, that and whatever may pop up when actually trying to implement the collision code. It may be possible to make the joints use a small physics aware sphere, and then use that to detect colliders...
No promises on whether it will be added or not, but I'll add it to the TODO list so I do not forget to take a look at implementing it! :)
Thanks again!

Thanks @NHodgesVFX!
It might be possible, and I do agree that the code linked does make it look relatively simple. The only part I'm not quite sure about is how to pass the colliders to the Jiggle bone, that and whatever may pop up when actually trying to implement the collision code. It may be possible to make the joints use a small physics aware sphere, and then use that to detect colliders...
No promises on whether it will be added or not, but I'll add it to the TODO list so I do not forget to take a look at implementing it! :)
Thanks again!

I just built the branch, haven't played with it much but its seems to work well. I was going to try out fabrick but it seems to crash every time i add a target.  As far as how to add the colliders you could add an array of target nodes, all you need from them would be their position. Then for each target node you need to specify a radius. I think that would give enough info to solve for collisions. The only issue with this is you would need to draw the radius so the user could see it.

Thanks @NHodgesVFX!
It might be possible, and I do agree that the code linked does make it look relatively simple. The only part I'm not quite sure about is how to pass the colliders to the Jiggle bone, that and whatever may pop up when actually trying to implement the collision code. It may be possible to make the joints use a small physics aware sphere, and then use that to detect colliders...
No promises on whether it will be added or not, but I'll add it to the TODO list so I do not forget to take a look at implementing it! :)
Thanks again!

I just built the branch, haven't played with it much but its seems to work well. I was going to try out fabrick but it seems to crash every time i add a target.

Hmm, that shouldn't be happening. I'll add it to the list of known bugs/issues and will see if I can figure out what is going on soon.

 As far as how to add the colliders you could add an array of target nodes, all you need from them would be their position. Then for each target node you need to specify a radius. I think that would give enough info to solve for collisions. The only issue with this is you would need to draw the radius so the user could see it.

That could work. For drawing the radius, I will need to find a way to have the modifications draw gizmos anyway, so while I am tackling that, I could probably add support for drawing the radius.

@TwistedTwigleg I was trying to roll all the bone so they go from the parent to the child. Did you implement that? This was my failed attempt. https://github.com/fire/godot/tree/parent-to-child
Not sure how to contact you.

@TwistedTwigleg I was trying to roll all the bones so the bone directions go from the parent to the child. Did you implement that? This was my failed attempt. https://github.com/fire/godot/tree/parent-to-child

No, I have not made anything like that. I'm a little confused on what you are exactly looking to achieve though. Can you please clarify?
The reason I'm confused is that, no matter what rotation you apply, you are almost certainly going to affect the position of the child bones and therefore it will not be aligned with them.
If you rotate bones on the twist axis (the forward axis for the bone), then you will not move any bones whose position is in parallel with the twist axis and are on the same line as the parent bone. For swing rotation (rotation not on the forward axis) or with Skeletons that have bones offset from the forward axis (like finger bones connected to a hand, for example), the children bones will have their transforms changed when you rotate the parent bone. If you want to rotate the parent bone to look at a child bone, you will need to work around the issue of children bones being offset and inheriting the transform from the parent bone.
There are a couple options I can think of to solve the issue, off the top of my head.
The first is to detach the child bones, perform the rotation, and then reattach them. This will allow you to adjust the parent bone as needed without modifying any of the transforms of the child bones.
The second option is to rotate the parent bone as needed and track the rotations you have applied. Once you are finished rotating the bone, you apply the inverse rotations to all of the children bones. This should rotate the child bones back into the positions they were prior to rotating the parent bone, but the parent bone will still have whatever rotations you added applied to it.
Again though. I'm not sure what this would achieve.
If you are just wanting to get the direction from the parent to child, then you just need to get the origin of the rest pose and normalize it, since the rest pose is the offset the bone has from it's parent. You likely do not want to rotate the parent bone to the child, as that would mess up any animations baked since you have changed the offsets/rotations of the parent bone and its children. That said, it is entirely possible I am misunderstanding what you are looking to achieve.

Not sure how to contact you.

You can contact me here on GitHub, on the IRC (though on weekends I'm not very active and this is not my preferred way to communicate), through Twitter DMs, on the Godot Community Forums, or through email. Whichever floats your boat works with me. 👍

I haven't gotten a chance to play with the latest version yet. But I was wondering what the status of this was and when it might be merged into master? I watched the showcase video and it looks like its come a long when since I last tried it. :)

I haven't gotten a chance to play with the latest version yet. But I was wondering what the status of this was and when it might be merged into master? I watched the showcase video and it looks like its come a long when since I last tried it. :)

Thanks @NHodgesVFX!
(Side note: Thanks for watching the video!)
The only biggish thing that still needs work is CCDIK. I rewrote the algorithm for the 3rd time on Monday (31st) because CCDIK was not working when I recorded the showcase video the day before. While the current version is much closer to how it functions in my prototype, it does have some minor differences from my GDScript version when solving. I recorded and added the working CCDIK clip to the showcase video the day of releasing the video, just a few hours before publishing. 🤪
I'm think angle constraints for CCDIK also need to be fixed, but I do not expect it to take very long or be hard to adjust. After that, I just need to fix any quirks or bugs introduced by the new CCDIK algorithm.
Outside of CCDIK, it's just bug fixes and polishing that should be left to do. FABRIK has a small issue where the chain goes a little wild when the target is farther than the max distance, but that's just a matter of doing a quick condition to work around the issue. There are still features and adjustments I'd like to add in the future (like gizmos to show angle constraints for CCDIK, magnet positions for FABRIK, etc), but they can always be added in the future.
As far as when it may be merged into master, I do not know. The code likely needs to be reviewed and tested prior to merging, in addition to the changes I've made being approved. Outside of that, I'm not sure what else needs to be done for merging into master.
Starting Monday (7th) I can start working on it again since final evaluations will be over due to the GSoC being finished. While my time will be a bit more limited going forward, I plan to continue to work and maintain this PR (and the 2D PR) in my spare time.

So - I've been playin' around with this a bit (mostly FABRIK) and I noticed that all of the methods that are exposed start by with fabrik_joint_.... It would probably be better to make it a bit less jarring when reading. So, for example, instead of fabrik_joint_get_length, it would be get_fabrik_joint_length. Or instead of fabrik_joint_get_bone_index, get_fabrik_joint_bone_index.
It would be much more intuitive, as well as more consistent with other parts of the engine. All of that said, awesome job on the actual documentation aspect.

@Duroxxigar - Thanks for looking at the PR! I made the change, so now all joint setters and getters use set_joint_property instead of joint_property_set. The class reference has also been updated accordingly.
I'll update the 2D PR soon with the same changes in function names.

@fire - Does the name not changing the ID occur with an external skeleton or when the BoneAttachment3D is a child of a Skeleton3D node? Also, was the node bound or not? When the node is first created, it's ID is always set to -1 because it is not bound to anything. It should change when you select one of the bone names from the dropdown though.
(Previously it wouldn't automatically make the dropdown when using an external Skeleton3D, but I have fixed that in the latest commit)

@akien-mga @JFonS - This PR should be ready to go! Everything I said I would add in my proposal is implemented and it all seems to be working in my test project.
I've been working on trying to get simple constraint support implemented in LookAt, but I have not got anything working reliably. The only thing I got sort of working is constraint support for LookAt when the solver is constrained to a axis, but it is inconsistent and I was hoping to get something for non-plane-constrained LookAt solves too. I guess there's a reason there is not many constrained 3D IK solvers.
I figure I can always add constraint support to LookAt later as an additional PR in the future if I find a working solution.
Regardless, both the 2D IK PR and this PR should be good for review now :smile:

Can you rebase on master?

Rebased with the master branch to fix merge conflicts!

Reduz
iFire: odino should probably review it, not me

I'll add @AndreaCatania to the reviewers list then. @akien-mga

@TwistedTwigleg Can you once again prepare the pr to pass cicd. Sorry about the delay.

No problem.
I will try to get it rebased later today (worse case it will be sometime tomorrow)

@fire - The pull request has been rebased and the merge conflict resolved. :+1:

I was able to have a contributor work on 3d gizmos, so that will be a pr separated from this.

https://github.com/godotengine/godot/pull/45699

@TwistedTwigleg Can you rebase this again? I think it would also make sense to squash the commits, 28 is a lot.

@aaronfranke - I can rebase it if needed. Right now I'm waiting on the 2D IK PR to be reviewed so I can make the adjustments I've made to that PR to this PR as well, so there's less duplicate work and the review process is easier. If you need it rebased for PR review, I can rebase it for you.
As for the commit number, I'm not sure. While its quite a few commits, this PR also adds over 5,000 new lines of code. I also have already squished the commits down from 100+ to the 28 it is now, so I'm not sure how much more squishing I could do without making each commit monstrously large (in that case, it might as well just be squished into a single commit on merge then).

The cicd builds are failing.

Does anyone know where this PR being blocked. If we could list the blockers, we could try resolving them this weekend.

If you have trouble with the diff tool on Windows.
Applying this patch can solve the static checks.
patch.diff.txt

Does anyone know where this PR being blocked? ...

I'm working on the fixes, it's just slow because I need the CI to fail so I can see what needs fixing. It's just going to take some time.
For the PR itself, it will need a review to make sure the code is good and everyone is happy with the changes. After everyone is good with it, I'll make a squished version, like I did for the 2D IK PR, so it can be merged in a single commit.

... If we could list the blockers, we could try resolving them this weekend.

With all due respect, do not assume how much time I do or do not have. If someone wants to list the blocks I will try to get to them when I have the chance, but it may or may not be this weekend.

If we could list the blockers, we could try resolving them this weekend.

With all due respect, do not assume how much time I do or do not have.

Additionally, any time I've seen Godot devs make an estimate of "this week(end)" it's almost always wrong. Things end up taking months or years. I think we should just stop giving estimates like that. It's very rude to assume that other people (including the PR author and other Godot devs) will squeeze this into their schedule, especially without even having a list of the blockers.

Let me try this again, as part of the animation team, I wanted to squeeze this into my weekend today Saturday, 2021-06-26 since I have an opening for the entire morning.
Even though I would other members of the team's approval such as @pouleyKetchoupp 's agreement, I wanted to see if I can remove any blocks that are in my control.
I wanted to offer my morning today and it seems like I'm making things worse...

@TwistedTwigleg Do you accept prs on your branch? There's a process where I can submit a pr on https://github.com/TwistedTwigleg/godot for GSOC_2020_Working_Branch_IK.
Using stacked branch prs can make collaboration and reviewing changes easier while keeping TwistedTwigleg's absolute control over the git branch.

Let me try this again, as part of the animation team, I wanted to squeeze this into my weekend today Saturday, 2021-06-26 since I have an opening for the entire morning.
Even though I would want other members of the team's approval such as @pouleyKetchoupp 's agreement, I wanted to see if I can remove any blocks that are in my control.
I wanted to offer my morning today and it seems like I'm making things worse...
So it is annoying to say I can't squeeze my effort into this.

That's fine, but do not volunteer my time just because you can squeeze something into your time. It is disrespectful to assume, directly or indirectly, that because you have time that you want to spend on this PR that I do as well.
It is disrespectful regardless of what team you are on, what contributor status you have, whether you have time or not, whether it's annoying to be unable to work on it, or any other factor. I am donating my time and effort into Godot, just like you or any other contributor.
As far as the blocks go, I do not think anyone has a list or anything for people to consult on this PR. If there is a list, I am certainly not aware of it. If there are blocks on this PR in the internal Godot teams, than that is something that is completely beyond my control and ability to discover unless these teams decide to inform me of the issues. If the animation team has not relayed information about blocks on this PR to you, then it sounds like it's an internal team communication issue.
Regardless, the blocks is not the issue I had with the post nor was I misunderstanding that the post was indirectly offering to help. The issue was the assumption that "we could try resolving them this weekend" because "it seems like TwistedTwigleg has some time".

@TwistedTwigleg Do you accept prs on your branch? There's a process where I can submit a pr on https://github.com/TwistedTwigleg/godot for GSOC_2020_Working_Branch_IK.
Using stacked branch prs can make collaboration and reviewing changes easier while keeping TwistedTwigleg's absolute control over the git branch.

If you are reviewing please use the normal GitHub code review process for doing so and I will make adjustments when I have the time. That way, all the reviews are in one place and I can tackle issues/changes/suggestions as they come up.
If you have additional features/changes/etc you want to introduce, please either write them down here for consideration or after the PR is merged make a proposal on the Godot proposal repository. However, please note I am currently not looking to make additional changes beyond what is already implemented in this PR and am just looking to get it where it can be merged.

I don't know of "blocks on this PR" aside from the fact that we decided to focus on getting the 2D PR merged first, and then update the 3D PR accordingly before merging it.
There might be more work needed but this needs to stem from an in-depth review or testing from interested contributors :)

Okay, the PR is in a merge-ready state and can be reviewed now :slightly_smiling_face:
If everyone is cool with it and there's no review changes, then I'll make a squished PR like I did for the 2D IK PR.

Are you able to find time to rebase on master? We added subgizmos.

Thanks @fire! The PR has been rebased (CI builds pending) and I adjusted the code based on the review feedback :+1:

Thanks. For the single PR, I’ll look at trying to get it into a squashed PR next weekend.
For the TODOs, I’d need to look and see, but probably I won’t be able to tackle them and they’ll need to be handled at a later date and/or by someone else. I can at very least pull them out, remove them from the PR and make an enhancement proposal. I’ll look at trying to get this processing going next weekend as well.

Closing this PR, as I made a squashed version here: https://github.com/godotengine/godot/pull/51368
The squashed PR is still in draft form as I need to still go through and cull out the TODOs, but once I have that done I'll change its status.


Correctly validate Slack field as optional

Hypha hides the Slack field for users with non-staff roles. This reflects that by checking for it using an optional get (which will default to None) instead of trying to access the key directly.
Fixes #2714

Thanks for this! I have seen this error from time to time but never got so far as to actually fix it.


Support categorical data in GPU weighted sketching.

Related: https://github.com/dmlc/xgboost/issues/6503 .

Codecov Report

Merging #6508 (42135cc) into master (afc4567) will increase coverage by 0.11%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #6508      +/-   ##
==========================================
+ Coverage   80.23%   80.34%   +0.11%
==========================================
  Files          13       13
  Lines        3551     3552       +1
==========================================
+ Hits         2849     2854       +5
+ Misses        702      698       -4

Impacted Files
Coverage Δ

python-package/xgboost/training.py
95.90% <0.00%> (-0.18%)
:arrow_down:

python-package/xgboost/callback.py
79.95% <0.00%> (+0.24%)
:arrow_up:

python-package/xgboost/core.py
80.88% <0.00%> (+0.26%)
:arrow_up:

python-package/xgboost/tracker.py
95.11% <0.00%> (+1.12%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update afc4567...42135cc. Read the comment docs.


OSError: cyenc.dll: cannot open shared object file: No such file or directory

I have the latest update, ubuntu 14.10 and cyenc.dll is in direcotory
root@xyz:~/pyposter# python3 pyposter.py alt.binaries.test2 parts.pyc
Traceback (most recent call last):
File "pyposter.py", line 2, in
import parts
File "/root/pyposter/parts.py", line 4, in
cyenc = ctypes.CDLL("cyenc.dll")
File "/usr/lib/python3.4/ctypes/init.py", line 351, in init
self._handle = _dlopen(self._name, mode)
OSError: cyenc.dll: cannot open shared object file: No such file or directory

Why are you trying to run a program obviously made for windows on a linux machine? what? if you want to run it on linux you're going to have to compile cyenc yourself.


 But when i use the older commits the pipeline get passed. May be a debug is required for which commit the pipeline gets killed.

checking in edge if it also has the same problem: https://github.com/cs3org/reva/pull/3803 with this PR

The bad commit changes that has stuck the pipeline is because of this PR changes in PR https://github.com/owncloud/ocis/commit/1a31aba659f7b148eecf0677bbb3491394331fef.

https://github.com/cs3org/reva/actions/runs/4804580793/jobs/8550227128?pr=3776
failed to remove network docker_default: Error response from daemon: error while removing network: network docker_default id ab95f490ea59f25884bbfcda14fc61c2bda8ba7bb1818dcbeb1cb14b824aa25b has active endpoints
make: *** [Makefile:130: docker-clean] Error 1

failure seems unrelated to the actual acceptance tests.

@labkode @glpatcern @gmgigi96 please review.
We needed to touch .drone.star so GitHub wants a code-owner review.


TS-SE-Tool Ats Not Working

So i recently use this tool for edit my ets2 save data , ets2 save data is working, so i buy ats , so when i tried to edit my ats save data
there is say no profiles found

so i tried to fix that with add custom folder so i tried to add my profile folder then it shows this

can someone help me or the developer fix this, this is not important cause i can enjoy with ets2

It seems that with update 1.38 they changed the location for steam profiles.
I changed the path from remote/profiles to steam_profiles and the profiles were shown again, unfortunately there are additional errors

I am unable to add steam_profiles as a custom folder, the folder selection dialogue works, but the radio buttons and the "Add" button remain greyed out.

I am unable to add steam_profiles as a custom folder, the folder selection dialogue works, but the radio buttons and the "Add" button remain greyed out.

I have to add that i did change to path through code, that functionality to add custom folders did not work for me either.

AFAIK the tool looks for the InstallPath onto HKEY_LOCAL_MACHINE\SOFTWARE\Valve\Steam
However, in my Win10 x64 version 2004 the key is: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Valve\Steam
Best

@dean-lowfps @adroslice @BamButz
Steam folders in Docments contains only settings files. Save file leaves in "...\Steam\userdata...\227300..."
Because of that program doesn't let you add such folders =) (it looks for profile\save files)
@pgfiore
Some recent changes in Steam added "ac" folder.
Fixed.

The profile does not load for me, can someone help me, I have already deleted everything and installed everything again and nothing


Added the 2 DHE for backward compatibility

Added the 2 DHE for backward compatibility
The backwards-compatible DHE cipher suites are disabled by the “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002\Functions” registry value. To restore them at the lowest priority, add them to the end of the list:

@JingyingWu : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off


remove @adobe/commerce-events-ext-tpl as requested in #1183

npm package name
@adobe/commerce-events-ext-tpl

requested from a maintainer in #1183


refactor: replacing version enum with assembly version

BREAKING CHANGE: Version removed, use MirageVersion.Version instead

Dont merge: Going to rename MirageVersion.Version to Version.Current first


Force to declare types in methods definitions and return types

I think types in methods helps to document and understand better the code and will make the compiler to be faster, duck typing is hard to mantain an for implementing this it can be used the GoLang approach of interfaces.
class Array(A)
  def map(f : A -> B) : Array(B)
  end
end

It's easier to understand and will avoid the compiler slow performance problems

Pretty sure this violates this goal:

Statically type-checked but without having to specify the type of variables or method arguments.

I read another thread to force to declare the type of the instance variables to make the compiler faster so that goal is gonna be violated.

Not really. That's a comparatively minor change compared to this.

Ooops, I added a thumbs up a bit to quickly, clarification:
I think this is good practice for all methods in stdlib.
I think this is bad baaad as a requirement in the language!

It's easier to understand and will avoid the compiler slow performance problems

This is not actually true. With the change to force typing global/class/instance vars, the compilation time is now basically linear on the number of methods and allows for caching of type inferences. I don't think there is an advantage performance-wise to force types on arguments and returns.
And most importantly: this is one of the nicest characteristics of Crystal, the global type inference.
Although I agree it is good for the stdlib, and the only reason is for documentation (and better errors).

Well it'll be good to leave it as optional if there is no performance problems, personally I'll use types, it is a matter of taste. It'll be good to suggest use types for third party libraries and use it in the stdlib

Forcing types on methods will actually slow down things and will necessarily make the language mrore complex. Check for example this:
def max(x, y)
  x > y ? x : y
end

First, what are the types of x and y? You will need to do x : T and then introduce the idea of interfaces/protocols and have types implement them, etc. When invoking such method that compile will have to check that all of that is satisfied. Now it's just about searching the > method in x and if that succeeds the method can be typed.
So although adding type annotations is probably good for documentation and cleaner errors, we will never make them mandatory.


Upload Page points to http://www.nuget.org instead of https://...

I noticed a small "bug". On the upload page you show the URL without https which might confuse people.

The part seems to be in your configuration:
https://github.com/NuGet/NuGetGallery/blob/e72e08ab541b0b47fafc7f6e1139644258b52004/src/NuGetGallery/Views/Packages/UploadPackage.cshtml#L14
I'm not sure if this is a typo in your configuration or if this is more like an internal URL. I could imagine that the SSL handling is managed by a proxy and behind that proxy you are using HTTP and thats why this internal config entry points to http://www.nuget.org

Thanks for reporting @robertmuehsig ! It's a config issue


Fixes for issues 40,41,42 and new rule #49

Added new rule as per #49
Also fixed issues #40
#41
#42
@kmnithyame please validate and close those issues if found working.

Tested all the issues filed (#40,#41,#42) and all got resolved
Thanks


add support for ENC data

Hi,
In my puppetserver (Puppet 4), I have an ENC which defines the global variable $::included_classes. It's an array which contains all classes to apply  to the current node. If this array is empty or if the variable is undefined, the code in site.pp raises an error and stop the puppet run. It's a wanted feature in my site.pp code.
The consequence is that puppet-repl triggers an error at each command (even with an empty command):
[0]<EMAIL_ADDRESS>23:46 ~ # lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 14.04.4 LTS
Release:	14.04
Codename:	trusty

[0]<EMAIL_ADDRESS>23:47 ~ # prepl
Ruby Version: 2.1.8
Puppet Version: 4.3.2
Puppet Repl Version: 0.0.4
Created by: NWOps<EMAIL_ADDRESS>Type "exit", "functions", "facts", "reset", "help" for more information.

>> a = 1
 => Evaluation Error: Error while evaluating a Function Call, Sorry, the node must have a
`$::included_classes` global variable defined (for instance by the ENC) and it must be an
non-empty array of elements with this form `[ '<author>', '<fully-qualified-class-name>' ]`
at /etc/puppetlabs/code/environments/production/manifests/site.pp:123:3
>>
 => Evaluation Error: Error while evaluating a Function Call, Sorry, the node must have a
`$::included_classes` global variable defined (for instance by the ENC) and it must be an
non-empty array of elements with this form `[ '<author>', '<fully-qualified-class-name>' ]`
at /etc/puppetlabs/code/environments/production/manifests/site.pp:123:3
>>

Anyway, thx for this promising tool.
Regards.

At this time the repl does load the site.pp as its extremely helpful for setting topscope variables during development and playing with the language.
In order to support ENC data the repl would have to call out to the ENC with a context (node info) in order to get the data from the ENC and set the top scope based on the returned data.  I would much rather leverage puppet to perform those actions than create some hooks to perform the same functionality.
This is definitely something the repl will need to support going forward.

@flaf do you have time to try the devel branch out?  I have fixed this in #14 but have only tested with a PE rig.  You would need to do the following.
gem build puppet-repl.gemspec
gem install puppet-repl-0.2.0.gem
prepl -n node_name
```

Note: this would reach out to the puppet server configured in your local puppet.conf and essentially run `puppet node find node_name --terminus rest`

The site.pp on the master does not evaluated since your local site.pp as defined in your puppet.conf is evaulated instead.  So it really only pulls in the remote node data and still evaluates everything locally.

You will also need to do the following to allow API access to the the node objects

See #17 for more info.

@logicminds, is it what you want?
<EMAIL_ADDRESS>01:14 ~# git clone https://github.com/nwops/puppet-repl.git
Cloning into 'puppet-repl'...
remote: Counting objects: 546, done.
remote: Compressing objects: 100% (121/121), done.
remote: Total 546 (delta 63), reused 0 (delta 0), pack-reused 421
Receiving objects: 100% (546/546), 905.41 KiB | 678.00 KiB/s, done.
Resolving deltas: 100% (298/298), done.
Checking connectivity... done.

<EMAIL_ADDRESS>01:16 ~ # cd puppet-repl/

<EMAIL_ADDRESS>01:16 ~/puppet-repl # git checkout devel
Branch devel set up to track remote branch devel from origin.
Switched to a new branch 'devel'

<EMAIL_ADDRESS>01:17 ~/puppet-repl # gem build puppet-repl.gemspec
WARNING:  open-ended dependency on puppet (>= 3.8) is not recommended
  if puppet is semantically versioned, use:
    add_runtime_dependency 'puppet', '~> 3.8'
WARNING:  open-ended dependency on facterdb (>= 0) is not recommended
  if facterdb is semantically versioned, use:
    add_runtime_dependency 'facterdb', '~> 0'
WARNING:  open-ended dependency on awesome_print (>= 0) is not recommended
  if awesome_print is semantically versioned, use:
    add_runtime_dependency 'awesome_print', '~> 0'
WARNING:  open-ended dependency on pry (>= 0) is not recommended
  if pry is semantically versioned, use:
    add_runtime_dependency 'pry', '~> 0'
WARNING:  See http://guides.rubygems.org/specification-reference/ for help
  Successfully built RubyGem
  Name: puppet-repl
  Version: 0.2.0
  File: puppet-repl-0.2.0.gem

<EMAIL_ADDRESS>01:17 ~/puppet-repl # gem install puppet-repl-0.2.0.gem
Fetching: awesome_print-1.6.1.gem (100%)
Successfully installed awesome_print-1.6.1
Fetching: coderay-1.1.1.gem (100%)
Successfully installed coderay-1.1.1
Fetching: method_source-0.8.2.gem (100%)
Successfully installed method_source-0.8.2
Fetching: slop-3.6.0.gem (100%)
Successfully installed slop-3.6.0
Fetching: pry-0.10.3.gem (100%)
Successfully installed pry-0.10.3
Successfully installed puppet-repl-0.2.0
Parsing documentation for awesome_print-1.6.1
Installing ri documentation for awesome_print-1.6.1
invalid options: -SNw2
(invalid options are ignored)
Parsing documentation for coderay-1.1.1
Installing ri documentation for coderay-1.1.1
Parsing documentation for method_source-0.8.2
Installing ri documentation for method_source-0.8.2
Parsing documentation for pry-0.10.3
Installing ri documentation for pry-0.10.3
Parsing documentation for puppet-repl-0.2.0
Installing ri documentation for puppet-repl-0.2.0
Parsing documentation for slop-3.6.0
Installing ri documentation for slop-3.6.0
Done installing documentation for awesome_print, coderay, method_source, pry, puppet-repl, slop after 7 seconds 6 gems installed

<EMAIL_ADDRESS>01:25 ~/puppet-repl # ./bin/prepl puppet.athome.priv
Ruby Version: 2.1.8
Puppet Version: 4.4.2
Puppet Repl Version: 0.2.0
Created by: NWOps<EMAIL_ADDRESS>Type "exit", "functions", "vars", "krt", "facts", "resources", "classes",
     "play", "classification", "reset", or "help" for more information.

/root/puppet-repl/lib/puppet-repl/cli.rb:186:in `filename': No such file or directory @ rb_sysopen - puppet.athome.priv (Errno::ENOENT)
	from /root/puppet-repl/lib/puppet-repl/cli.rb:186:in `start'
	from ./bin/prepl:4:in `<main>'

<EMAIL_ADDRESS>01:26 ~/puppet-repl # puppet node find puppet.athome.priv --terminus rest
(works fine, I have big json in the output)

Need to use the '-n'  prepl -n node_name

So if that loads correctly you should be able to use
classification or vars or facts and anything else.
Also added support for variable and function name auto completion

Ooops, sorry:
<EMAIL_ADDRESS>01:43 ~/puppet-repl # ./bin/prepl -n puppet.athome.priv
Ruby Version: 2.1.8
Puppet Version: 4.4.2
Puppet Repl Version: 0.2.0
Created by: NWOps<EMAIL_ADDRESS>Type "exit", "functions", "vars", "krt", "facts", "resources", "classes",
     "play", "classification", "reset", or "help" for more information.

>> a = 1
Fetching node puppet.athome.priv
/root/puppet-repl/lib/puppet-repl/support/scope.rb:29:in `rescue in create_scope': undefined method `parse_error' for #<PuppetRepl::Cli:0x000000042534c0> (NoMethodError)
	from /root/puppet-repl/lib/puppet-repl/support/scope.rb:26:in `create_scope'
	from /root/puppet-repl/lib/puppet-repl/support/scope.rb:12:in `scope'
	from /root/puppet-repl/lib/puppet-repl/cli.rb:45:in `puppet_eval'
	from /root/puppet-repl/lib/puppet-repl/cli.rb:111:in `handle_input'
	from /root/puppet-repl/lib/puppet-repl/cli.rb:158:in `read_loop'
	from /root/puppet-repl/lib/puppet-repl/cli.rb:196:in `start'
	from ./bin/prepl:4:in `<main>'

Looks like you may not have changed your auth.conf  see #17
Also I have an error in the code, otherwise you would have seen a better error message

Reproducing now and will push changes shortly

Here is my /etc/puppetlabs/puppetserver/conf.d/auth.conf after modification (I have replaced "$1" by "*"):
<EMAIL_ADDRESS>02:05 ~/puppet-repl
# cat /etc/puppetlabs/puppetserver/conf.d/auth.conf
authorization: {
    version: 1
    rules: [
        {
            # Allow nodes to retrieve their own catalog
            match-request: {
                path: "^/puppet/v3/catalog/([^/]+)$"
                type: regex
                method: [get, post]
            }
            allow: "$1"
            sort-order: 500
            name: "puppetlabs catalog"
        },
        {
            # Allow nodes to retrieve the certificate they requested earlier
            match-request: {
                path: "/puppet-ca/v1/certificate/"
                type: path
                method: get
            }
            allow-unauthenticated: true
            sort-order: 500
            name: "puppetlabs certificate"
        },
        {
            # Allow all nodes to access the certificate revocation list
            match-request: {
                path: "/puppet-ca/v1/certificate_revocation_list/ca"
                type: path
                method: get
            }
            allow-unauthenticated: true
            sort-order: 500
            name: "puppetlabs crl"
        },
        {
            # Allow nodes to request a new certificate
            match-request: {
                path: "/puppet-ca/v1/certificate_request"
                type: path
                method: [get, put]
            }
            allow-unauthenticated: true
            sort-order: 500
            name: "puppetlabs csr"
        },
        {
            match-request: {
                path: "/puppet/v3/environments"
                type: path
                method: get
            }
            allow: "*"
            sort-order: 500
            name: "puppetlabs environments"
        },
        {
            # Allow nodes to access all file services; this is necessary for
            # pluginsync, file serving from modules, and file serving from
            # custom mount points (see fileserver.conf). Note that the `/file`
            # prefix matches requests to file_metadata, file_content, and
            # file_bucket_file paths.
            match-request: {
                path: "/puppet/v3/file"
                type: path
            }
            allow: "*"
            sort-order: 500
            name: "puppetlabs file"
        },
        {
            # Allow nodes to retrieve only their own node definition
            match-request: {
                path: "^/puppet/v3/node/([^/]+)$"
                type: regex
                method: get
            }
            allow: "*"
            sort-order: 500
            name: "puppetlabs node"
        },
        {
            # Allow nodes to store only their own reports
            match-request: {
                path: "^/puppet/v3/report/([^/]+)$"
                type: regex
                method: put
            }
            allow: "$1"
            sort-order: 500
            name: "puppetlabs report"
        },
        {
            match-request: {
                path: "/puppet/v3/status"
                type: path
                method: get
            }
            allow-unauthenticated: true
            sort-order: 500
            name: "puppetlabs status"
        },
        {
            match-request: {
                path: "/puppet/v3/static_file_content"
                type: path
                method: get
            }
            allow: "*"
            sort-order: 500
            name: "puppetlabs static file content"
        },
        {
          # Deny everything else. This ACL is not strictly
          # necessary, but illustrates the default policy
          match-request: {
            path: "/"
            type: path
          }
          deny: "*"
          sort-order: 999
          name: "puppetlabs deny all"
        }
    ]
}

I have restarted the puppetserver and:
<EMAIL_ADDRESS>02:05 ~/puppet-repl # ./bin/prepl -n puppet.athome.priv
Ruby Version: 2.1.8
Puppet Version: 4.4.2
Puppet Repl Version: 0.2.0
Created by: NWOps<EMAIL_ADDRESS>Type "exit", "functions", "vars", "krt", "facts", "resources", "classes",
     "play", "classification", "reset", or "help" for more information.

>> a = 1
Fetching node puppet.athome.priv
/root/puppet-repl/lib/puppet-repl/support/scope.rb:29:in `rescue in create_scope': undefined method `parse_error' for #<PuppetRepl::Cli:0x00000003a56e20> (NoMethodError)
	from /root/puppet-repl/lib/puppet-repl/support/scope.rb:26:in `create_scope'
	from /root/puppet-repl/lib/puppet-repl/support/scope.rb:12:in `scope'
	from /root/puppet-repl/lib/puppet-repl/cli.rb:45:in `puppet_eval'
	from /root/puppet-repl/lib/puppet-repl/cli.rb:111:in `handle_input'
	from /root/puppet-repl/lib/puppet-repl/cli.rb:158:in `read_loop'
	from /root/puppet-repl/lib/puppet-repl/cli.rb:196:in `start'
	from ./bin/prepl:4:in `<main>'

Cool, I just pushed an update if you want to pull and rebuild the gem and try again.

<EMAIL_ADDRESS>02:12 ~/puppet-repl
# ./bin/prepl -n puppet.athome.priv
Ruby Version: 2.1.8
Puppet Version: 4.4.2
Puppet Repl Version: 0.2.0
Created by: NWOps<EMAIL_ADDRESS>Type "exit", "functions", "vars", "krt", "facts", "resources", "classes",
     "play", "classification", "reset", or "help" for more information.

>> a = 1
Fetching node puppet.athome.priv
 => Evaluation Error: Operator '[]' is not applicable to an Undef Value. at /etc/puppetlabs/code/environments/production/manifests/site.pp:58:4

a = 1 is not valid puppet code.  Try anything else: $a = '1' or classes

or classification

Oh sorry, of course a = 1 is not valid. ;)
# ./bin/prepl -n puppet.athome.priv
Ruby Version: 2.1.8
Puppet Version: 4.4.2
Puppet Repl Version: 0.2.0
Created by: NWOps<EMAIL_ADDRESS>Type "exit", "functions", "vars", "krt", "facts", "resources", "classes",
     "play", "classification", "reset", or "help" for more information.

>> $a = 'foo'
Fetching node puppet.athome.priv
 => Evaluation Error: Operator '[]' is not applicable to an Undef Value. at /etc/puppetlabs/code/environments/production/manifests/site.pp:58:4
>> classes
 => Evaluation Error: Operator '[]' is not applicable to an Undef Value. at /etc/puppetlabs/code/environments/production/manifests/site.pp:58:4

Are you able to share your site.pp code?  Whats on line 58?
/etc/puppetlabs/code/environments/production/manifests/site.pp:58:4

It's if $::facts['os']['family'].downcase == 'debian' {

Also what ENC are you using?

PE console
Foreman
Some script
hiera

My ENC is a personal Ruby script.
<EMAIL_ADDRESS>02:21 ~/puppet-repl # /etc/puppetlabs/code/environments/enc puppet.athome.priv
{
  "environment": "production",
  "parameters":
  {
    "included_classes": [["flaf", "::roles::puppetserver"]],
    "datacenter": "vboxhome",
    "groups": ["puppetserver"],
    "groups_0": "puppetserver",
    "groups_1": "NOT_AVAILABLE",
    "groups_2": "NOT_AVAILABLE",
    "groups_3": "NOT_AVAILABLE",
    "groups_4": "NOT_AVAILABLE",
    "datacenters": ["vboxhome"],
  }
}

Just pushed a new update.  Can you pull, rebuild and try again?
There is an issue with the puppet node face not populating the $::facts variable so I retrofitted it in.

Hi,
During the command gem install puppet-repl-0.2.0.gem, some files in /opt/puppetlabs/puppet/bin/ are overwritten. Is it normal? No problem here because it's a VM with a snapshot.
[0]<EMAIL_ADDRESS>15:38 ~/puppet-repl
# gem install puppet-repl-0.2.0.gem
Fetching: facter-2.4.6.gem (100%)
facter's executable "facter" conflicts with /opt/puppetlabs/puppet/bin/facter
Overwrite the executable? [yN]  y
Successfully installed facter-2.4.6
Fetching: json_pure-1.8.3.gem (100%)
Successfully installed json_pure-1.8.3
Fetching: hiera-1.3.4.gem (100%)
hiera's executable "hiera" conflicts with /opt/puppetlabs/puppet/bin/hiera
Overwrite the executable? [yN]  y
Successfully installed hiera-1.3.4
Fetching: puppet-3.8.7.gem (100%)
puppet's executable "puppet" conflicts with /opt/puppetlabs/puppet/bin/puppet
Overwrite the executable? [yN]  y
Successfully installed puppet-3.8.7
Fetching: jgrep-1.4.0.gem (100%)
Successfully installed jgrep-1.4.0
Fetching: facterdb-0.3.5.gem (100%)
Successfully installed facterdb-0.3.5
Fetching: awesome_print-1.6.1.gem (100%)
Successfully installed awesome_print-1.6.1
Successfully installed puppet-repl-0.2.0
Parsing documentation for awesome_print-1.6.1
Installing ri documentation for awesome_print-1.6.1
Parsing documentation for facter-2.4.6
Installing ri documentation for facter-2.4.6
Parsing documentation for facterdb-0.3.5
Installing ri documentation for facterdb-0.3.5
Parsing documentation for hiera-1.3.4
Installing ri documentation for hiera-1.3.4
Parsing documentation for jgrep-1.4.0
Installing ri documentation for jgrep-1.4.0
Parsing documentation for json_pure-1.8.3
Installing ri documentation for json_pure-1.8.3
Parsing documentation for puppet-3.8.7
Installing ri documentation for puppet-3.8.7
Parsing documentation for puppet-repl-0.2.0
Installing ri documentation for puppet-repl-0.2.0
Done installing documentation for awesome_print, facter, facterdb, hiera, jgrep, json_pure, puppet, puppet-repl after 37 seconds
8 gems installed

And now I have this:
[0]<EMAIL_ADDRESS>15:46 ~/puppet-repl
# ./bin/prepl -n puppet.atwork.priv
Ruby Version: 2.1.8
Puppet Version: 4.4.2
Puppet Repl Version: 0.2.0
Created by: NWOps<EMAIL_ADDRESS>Type "exit", "functions", "vars", "krt", "facts", "resources", "classes",
     "play", "classification", "reset", or "help" for more information.

>> $a = '1'
Fetching node puppet.atwork.priv
 => Evaluation Error: Unknown variable: '::server_facts'. at /etc/puppetlabs/code/environments/production/modules/puppetagent/functions/data.pp:6:6 in Evaluation Error: Unknown variable: '::server_facts'. at /etc/puppetlabs/code/environments/production/modules/puppetagent/functions/data.pp:6:6
>> exit

Here is the line of my /etc/puppetlabs/code/environments/production/modules/puppetagent/functions/data.pp:
function puppetagent::data {

  # Warning: the $server_facts will be defined for the node
  #          only if the parameter `trusted_server_facts`
  #          is set to true in the puppet.conf of the server.
  if $::server_facts {              #  <==== line 6 here

  ...

@flaf I have updated the branch (force push) if you want to delete the repo and try again.
I ended up having to duplicate the server_facts on the "client side" as the server does not expose those facts to via the puppet node indirector.
Example: https://www.puppet-repl.com/play?content=vars

released with v0.2.0


Add an achievements section

The achievements section would be the place to showcase your hackathon victories, event wins or anything you're proud of. It would have cards similar to that of project cards with a title like "Winner at MLH Hackathon" and when you achieved it.

Hey @wrussell1999! If the issue sounds good, we ( me, @PayasSingh and @PrateekSane ) will work on this.


use a faster merge duplicate chunks algorithm

What kind of change does this PR introduce?
performance

Did you add tests for your changes?
existing tests

If relevant, link to documentation update:
n/a

Summary
use a faster merge duplicate chunks algorithm

Does this PR introduce a breaking change?
no

Other information

#5718


Error type for from_env_ext function

Continue implementing #51. The previous PR wasn't finished and cleaned up.
If we want to discern different errors and treat them differently, more specific return type would be more convenient.
If this's going to be merged, probably there'll be some changes from current version. If it's possible, i'd like to clean up results before merging.

ping @alexcrichton for merging
ping @weihanglo in case you have any additional comments
(So far this PR has consensus between me, @NobodyXu and @belovdv.)

The FromEnv structure feels pretty unidiomatic as it's a struct-containing-a-Result which breaks ? usage and requires filling out fields that may not always make the most sense.

? is not exactly broken because Client::from_env_ext().client? would still work.
But it's not too important anyway, this function is called ~once in a program, and if someone is calling Client::from_env_ext() instead of Client::from_env() he's likely going to inspect and/or log all those errors and env vars.
FromEnv::var is not inside the Result because it may exist regardless of the client being successfully constructed or not.

I'll reiterate the second part of my comment above. I realize that this is a minor crate which is not really all that heavily used. That being said I do not want to personally maintain the idioms introduced here, nor do I necessarily have the time or energy to walk through the review process towards something I would be willing to maintain. If updating this PR requires lots of feedback from me, or if this PR would rather not be updated, then I think it's best to look for a different maintainer of this crate to transfer ownership to.

This PR would rather not be updated.
I'll make a proposal to move this crate to rust-lang organization.


Fix missing libz and libm linker symbols

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Change content looks good; merge on test passage.


fix: LSP server crashing in case of error in schema

Added try-catch block around handleWatchedFilesChangedNotification handler to prevent server crash on schema update.

fixes #3429
/claim tailcallhq/tailcall#579

thank you for this fix! this code looks and feels messy because it needs to be rewritten. the graphqlcache schema loader should handle this internally without bubbling up the exception to MessageProcessor, but this is a sufficient patch until we can get that right.

oh shoot, there is no changeset, need to revert

@A-N-uraag can you re-do this PR with a changeset as per the bot request?


0.1.7

0.1.7

Code Clean-up:
Unused variables, indentation, etc...
Hierarchy implementation:
Params (Default Configurations) -> Scaleio (User Configurations) -> Modules (inherits)
Configuration check:
Array, string, integer, boolean, etc...
install.pp
Installation of ScaleIO packages adopting O.S Repository
Created Vagrant for testbed under tests folder

Thanks for the PR Victor.  Looks like you put in some good time on this one.  We will review it shortly!


Pool JsonSerializer for Output formatting

Partial fix for #3550

The fix for JsonInputFormatter isn't so simple. Will follow up on that separately.

:shipit:


Editing metadata shouldn't force a full DB refresh

This is a pretty big work item, but supporting incremental modification to the music database would be a pretty huge improvement to usability when doing metadata editing

Make the changes in MusicScanner.ts, function is called "UpdateSongMetadata".

Make the changes in MusicScanner.ts, function is called "UpdateSongMetadata".

Song-specific changes are minimized, now, though they still strictly take place on the main process, and update the render process. I wonder if the entire "send the database to the render process in one swell foop" thing should be changed to just operate like a database instead... At some point maybe I should just learn how to some kind of official indexed DB-like thing for realsies...

Song-specific changes are minimized, now, though they still strictly take place on the main process, and update the render process. I wonder if the entire "send the database to the render process in one swell foop" thing should be changed to just operate like a database instead... At some point maybe I should just learn how to some kind of official indexed DB-like thing for realsies...

The Audio Database supports removing and adding of files. I think doing that should be sufficient. I should verify that it works that way some day...

Yup. Works alright.


Add timebounds to listBackups API

In building out a backup process, I want an API to evaluable existing backups to determine if a new backup is necessary. I'm thinking of using a time threshold to take a backup if one does not exist created in the last X hours (ie: 48 or 72).
At some point, we'll want to delete or remove old backups, but in the meantime, adding a time bound to our listBackups API, so we can ignore backups taken before some period (in the code creating new backups). This time bounds can also be used by a process monitoring for backups that are too old, issuing delete commands.

Codecov Report

Merging #624 into master will increase coverage by <.01%.
The diff coverage is 90.9%.

@@             Coverage Diff              @@
##             master     #624      +/-   ##
============================================
+ Coverage     83.16%   83.17%   +<.01%
- Complexity      954      957       +3
============================================
  Files            65       65
  Lines          4224     4232       +8
  Branches        522      523       +1
============================================
+ Hits           3513     3520       +7
- Misses          467      468       +1
  Partials        244      244

Impacted Files
Coverage Δ
Complexity Δ

...bv2/mt/mappers/sharedtable/SharedTableBuilder.java
86.83% <100%> (ø)
59 <1> (+1)
:arrow_up:

...ers/sharedtable/impl/MtSharedTableBackupManager.kt
90.67% <90.47%> (-0.1%)
61 <5> (+2)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ce09012...629ab43. Read the comment docs.


derivative (L) matrix should have a square basis

It seems to me that the derivative L matrix should be square (mxm where m is the number of columns of A) for order 0 (i.e., square identity matrix) and decreasing rows for higher orders, rather than the shape of A. At least, that is what is needed for my data-smoothing application. I have made the necessary changes here:
https://github.com/jjstickel/RegularizationTools.jl/commit/604f359cc05833fee585456f3861b96b7519138d
Does this seem reasonable? Or are there cases when L should correspond to both dimensions of A? All the existing tests pass, but from what I can tell, they all use a square A. I'll make a PR later after I have worked out additional code I might want to add.

Thanks for the comment. After some testing with a non-square system I agree  that L matrix should be square. In fact, the way it is implemented in the current version,  L'L is missing  terms in the last rows/columns, which leads to a corresponding lack or regularization at the edge of the domain. The changes mentioned above fix this, and thus also improve the package. A PR would be very welcome.

Great, thanks for looking at this. I'll submit a PR in the next few days. Still working on some other concepts that may go in this PR or in a second one at a later time.


Add support of sort-includes parameter for clang-format

created the issue because didn't find proper .clang-format file key.


Tic Tac Toe Game in JS

Would like to add a tic-tack Game in Js under HCSSOC.

This issue is successfully resolved and merged, now it can be closed.

@Ayush7614 This issue is successfully resolved and merged, now it can be closed.


Request for WPF/UWP Native Custom Sign-in Screen in XAML

It would be great if we could develop sign-in forms/screen in XAML for our WPF/UWP apps. Not a fan of having to build a HTML/CSS UI; it is not a great experience.

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

ID: 0205d9f7-de2b-3469-f990-1ab3ec434654
Version Independent ID: 5ae4a3cc-7ff1-4418-35f4-2ad27afef5bb
Content: Tutorial - Grant access to a Node.js web API from a desktop app using Azure Active Directory B2C
Content Source: articles/active-directory-b2c/active-directory-b2c-tutorials-desktop-app-webapi.md
Service: active-directory
GitHub Login: @davidmu1
Microsoft Alias: davidmu

Thanks for the feedback! We are looking into this and will get back to you shortly.

Excellent 😉
Sent from my Windows 10 phone
From: Marilee Turscak -<EMAIL_ADDRESS>Sent: Thursday, July 26, 2018 10:24
To<EMAIL_ADDRESS>Cc: Tavi<EMAIL_ADDRESS><EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/azure-docs] Request for WPF/UWP Native Custom Sign-in Screen in XAML (#12401)
Thanks for the feedback! We are looking into this and will get back to you shortly.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/azure-docs/issues/12401#issuecomment-408172029, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFbdjNUr6c1OwpeIB2vKw3A-hMK38RK2ks5uKftMgaJpZM4VhLEv.

@TaviTruman Please post this as a feedback https://feedback.azure.com/forums/169401-azure-active-directory This will allow the community to Upvote and for the product team to include into their plans. We also have the "Give Product Feedback" button in our documents now to take you directly to the appropriate feedback page.

Done


Improve logon with 2FA (#114)

V0.1.3 beta (#113)

Fixes #108 add authn ldap support (#109)

Fixes #106 Adding 6 CEM sub-commands (#105) (#111)

Co-authored-by: Quincy Cheng<EMAIL_ADDRESS>Co-authored-by: Joe Garcia<EMAIL_ADDRESS>
Improve logon with 2FA

Currenly when trying to autenticate against a CyberArk with 2FA enabled the
request request fails with the following error:
Failed to Logon to the PVWA. Failed to authenticate to the PAS REST API.
Received non-200 status code '500'

In function httpjson.SendRequestRay the response body isn't returned, so
the caller function never finds the correct error code.
After the previous fix, the second call, the one with the otp code still fails
with 403. Debugging it seems that we need to store the cookies between the
two logon calls. So a go context is added to the functions.

Fix lint errors and add missing file from previous commit

This commit fixes the go  lint error related to key type in context and it
adds a missing file from previous commit not uploaded by error.

Fix type error in comment

Missing comment on Cookie function

Added missing comment

Fix panic when body response is nil

Try to catch nil response body on httpjson.SendRequestRaw function
Co-authored-by: Andrew Copeland<EMAIL_ADDRESS>Co-authored-by: Quincy Cheng<EMAIL_ADDRESS>Co-authored-by: Joe Garcia<EMAIL_ADDRESS>

Hi @infamousjoeg, I was trying to get cybr-cli working with an MFA/RADIUS protected instance and found this and #114 while troubleshooting. The issues fixed in the original PR seem to still be present and prompts for MFA challenges just get 403s. It's been a while, and I'm not sure why this didn't make the original merge, but any chance on getting this actually merged in?

@Infraded,
Let's continue this over on #214 where I added this code into the current code base.  I am hoping you can help test the build.


warning about arguments to 'min' (becomes macro) on windows/vs2019

warning is "view.hpp(229,21): warning C4003: not enough arguments for function-like macro invocation 'min' (compiling source file App.cpp)"
also on line 1400 of registry.hpp
Fixed either by putting parenthesis around the function (std::min)(arg1, arg2), or warning windows users to use the correct define (NOMINMAX) before windows.h.

The FAQ already contains a note about this.

Thanks; I now realize last time I read the docs I was on Linux.

:smile: You're welcome. I'm using EnTT on Linux too, so the (-) solution risks to be fragile because I cannot guarantee on it. I'm pretty sure I'll forget to add parentheses the next time I use min or max. :joy:


Document state of desktop (Windows) Chromium wrt Origin Trial

(Also see https://github.com/jpchase/OriginTrials/issues/24 - as a pointer of how to clarify so folks know the current status.)


Specify exact files to process in ktlint run

This PR improves ktlint support: it explicitly specifies the files to process.
Without that current mill.kotlinlib.ktlint.KtlintModule/checkFormatAll run, for example, will go through the files under the out folder, which is useless and pollutes logs.
Also this PR removes redundant flags from reformatAll and checkFormatAll: former will always be with format=true by definition, the latter will always be with format=false.

Thanks!


Avoid issue with slice shortcut

Codecov Report

Merging #77 (7a01b28) into main (e8f7972) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##               main      #77   +/-   ##
=========================================
  Coverage     99.56%   99.57%
- Complexity      436      448   +12
=========================================
  Files            30       30
  Lines          1158     1171   +13
=========================================
+ Hits           1153     1166   +13
  Misses            5        5

Impacted Files
Coverage Δ

src/Cache/Directory.php
100.00% <ø> (ø)

src/Environment/StubbedEnvironment.php
100.00% <ø> (ø)

src/Cache/Cache.php
100.00% <100.00%> (ø)

src/Cache/CacheEncoder.php
100.00% <100.00%> (ø)

src/Cache/CacheFileHandler.php
100.00% <100.00%> (ø)

src/Cache/FileCacheManager.php
100.00% <100.00%> (ø)

src/Cache/Signature.php
100.00% <100.00%> (ø)

src/Config/ConfigResolver.php
100.00% <100.00%> (ø)

src/Sniff/OperatorSpacingSniff.php
100.00% <100.00%> (ø)

src/Token/Tokenizer.php
100.00% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Did sbt-typelevel-0.4.20 eat us?

#182, #183 both failing on a MiMa issue, and MiMa was upgraded in that release.  I am slightly afraid I'm at fault via https://github.com/lightbend/mima/pull/743.

From #183:
[error] (core-commonJVM / mimaReportBinaryIssues) Failed binary compatibility check against org.typelevel:otel4s-core-common_2.13:0.2.1 (e:info.apiURL=https://***/service/local/repositories/snapshots/archive/org/typelevel/otel4s-docs_2.13/0.2.1-2-31aa229-SNAPSHOT/otel4s-docs_2.13-0.2.1-2-31aa229-SNAPSHOT-javadoc.jar/!/index.html, e:info.versionScheme=early-semver)! Found 1 potential problems
[error] (testkitJVM / mimaReportBinaryIssues) not a directory or jar file: /home/runner/work/otel4s/otel4s/testkit/all/jvm/target/scala-2.13/classes

It did not eat us.  Just needed to do the close and open do-si-do.


RHOAIENG-4533: Add images based on Python 3.11

https://issues.redhat.com/browse/RHOAIENG-4533
Description

Add images based on Python 3.11
How Has This Been Tested?

Notebook tests plus manual sanity checks on some images. We can handle issues separately if we find them afterward.
Merge criteria:

[x] The commits are squashed in a cohesive manner and have meaningful messages.
[ ] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[ ] The developer has manually tested the changes and verified that the changes work

/lgtm
these addition are not breaking the 2024a and 2023b images, so it should be harmless to add this to the branch (after the manual sanity checks are done)

https://github.com/opendatahub-io/notebooks/pull/635 will be applied to this PR shortly.

/lgtm

Thanks @harshad16! All in in https://github.com/opendatahub-io/notebooks/pull/659/commits/87c6b1d73fda69912ef2d2fe6a55cd73b4821eea

/ltgm

/hold
I'm double-checking some things

https://github.com/opendatahub-io/notebooks/pull/667 will be applied to this PR shortly.

/lgtm

/lgtm

@harshad16 any other request from your side?

/lgtm
However, I recommend merging this PR into a feature branch instead of the main branch.
The main branch is currently in sync with the 2024a release, however these changes (python 3.11) are intended for the upcoming 2024b release. Merging directly into the main branch could disrupt the current workflow. What do you think?
@harshad16

@atheo89 We had that discussion last week and the conclusion is that we can merge this code to main as long as we don't touch the manifests. Do you see any other issues with this approach?

Thank you for the heads up! These changes don't affect the 2024a builds, so we are good!
/lgtm

Merging directly into the main branch could disrupt the current workflow. What do you think?

as shared, this discussed and the conclusion was to keep them in main for consistent development.
Thank you for the work
/lgtm
/approve

/override ci/prow/images ci/prow/rocm-notebooks-e2e-tests


Make supervisors use Elixir 1.5-based specs

This should be backward compatible as far as APIs go (assuming people didn't add children to Instruments.Probe.Supervisor without using the helper function.

Could I get a stamp please?


[FEATURE] Move Dependencies

Is your feature request related to a problem? Please describe.
Installing python packages in setup script
Describe the solution you'd like
Use  the following command and keep each package's set up tools up to date
python setup.py install

Describe alternatives you've considered
What we do now with installing deps in install script.

@benjaminwp18 Your thoughts?

@benjaminwp18 To properly utilize this we would probably need to switch out order of operations for installing. It would probably require us cloning the repo then running the install script rather than curling it off of github. Would this be acceptable?


Garmin VO2max with decimals (feature wish)

Thanks for your great work, I love strautomator and purchased lifetime right away!
I read somewhere that Garmins VO2max value can be found in their .fit files with 2 decimal values.
Everywhere in Garmin Connect you can only find the rounded VO2max value, so it would be a really cool feature if you could add a $(garmin.vo2max) tag that gives the VO2max with 2 decimals (e g. 56.78).
Best regards

Hi @aslan91 , first of all thanks for the support, really appreciated!
About the decimals, that would be a very niche feature to have. At the moment I try to keep data fully in sync with what Strava / Garmin / Wahoo do, so if you see something with no decimals in Garmin Connect, you should also see no decimals on Strautomator. Also... I don't think Garmin is accurate enough for VO2Max, so these decimals variations are still way below the margin of error.
What I could do, is having an extra endpoint to get the raw values from parsed FIT activities. I'll check what's needed to do that and let you know if I decide to get it implemented.

That's a nice idea, thank you very much @igoramadas !


[Snyk] Security upgrade proper-url-join from 2.1.1 to 2.1.2

Snyk has created this PR to fix 1 vulnerabilities in the yarn dependencies of this project.
Snyk changed the following file(s):

ui/packages/lib/package.json

Note for zero-installs users
If you are using the Yarn feature zero-installs that was introduced in Yarn V2, note that this PR does not update the .yarn/cache/ directory meaning this code cannot be pulled and immediately developed on as one would expect for a zero-install project - you will need to run yarn to update the contents of the ./yarn/cache directory.
If you are not using zero-install you can ignore this as your flow should likely be unchanged.

⚠ Warning
Failed to update the yarn.lock, please update manually before merging.

Vulnerabilities that will be fixed with an upgrade:

Issue
Score

Denial of Service (DoS) SNYK-JS-DECODEURICOMPONENT-3149970
  159

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
Max score is 1000. Note that the real score may have changed since the PR was raised.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Denial of Service (DoS)

🎉 Snyk hasn't found any issues so far.
✅ code/snyk check is completed. No issues were found. (View Details)


Make it well documented!

Effects, and many more stuff are not explained even tho its not hard to find and implement but some people will have a hard time.

Thank you, I will try to add more documentation of them.

I added an additional explanation for Shape and Effect on README.md.
Thank you for the Issue.


Build Cubit for Coreform Cubit version 2021.11

Coreform release Cubit 2021.11 recently and we don't yet to have a plugin built for this version.
I believe that it is fairly straight forward to update the Github Action scripts so that the Svalinn Plugin for this new version of Cubit can be included in the next release.

The release action for linux appears to be failing when servers are not responding
I've rerun it 3 times in cases it is an unlucky glitch but still different individual runs are failing with this error
Run svenstaro/upload-release-action@v2
/usr/bin/docker exec  54c166f3dcbdceb6890607dd672a6352ec897d6ad00bc8a7a5f9cc6bbca66813 sh -c "cat /etc/*release | grep ^ID"
Error: request to https://uploads.github.com/repos/svalinn/Cubit-plugin/releases/55456771/assets?name=svalinn-plugin_ubuntu-21.04_cubit_2021.4.tgz& failed, reason: read ECONNRESET

Does it matter that this is pointing to version 2021.4 rather than 2021.11?

Oh that is just the specific version that failed for that github action run, it builds 9 different combinations on the linux yml.
It would be ideal if they all build and get uploaded. I know we have the older 2021.4 on the previous release but it would be nice to get them all for each release


Fix the user session

At present, Samsara Aquarius is using Play's global cache to save user session, but there is something wrong about the logic. So in next version we should find a more appropriate way to implement this.

Fixed

Fixed, but need a timestamp to implement expiration


Fix #828, Spacecraft ID sample set to historical value (0x42)

Describe the contribution
Fix #828 - set spacecraft ID in sample targets.cmake to 0x42
Testing performed
Nominal build and test
Expected behavior changes
Spacecraft ID back to historical value (some toolchains depend on it).  Verified at PSP startup, reported as 66 (0x42).
System(s) tested on

Hardware: cFS Dev Server
OS: Ubuntu 18.04
Versions: bundle main (w/ cfe/osal main) + this commit

Additional context
None
Third party code
None
Contributor Info - All information REQUIRED for consideration of pull request
Jacob Hageman - NASA/GSFC

CCB 2020-08-26 - APPROVED

Instructions for this merge:

Create new branch based on 6.8.x
Merge this PR into that branch
Create PRs to merge that branch into main
Create PR to merge that branch into 6.8.x

I can rebase this on 6.8.x if you want.

This one is good to go onto 6.8.x, I'll create the PR for 7.0 next.


Reading incorrect memory on TPU (ft. flax.linen.transforms.scan)

Problem you have encountered:
Simple RNNLM-esque example (based on distributed seq2seq example) seems to read wrong/unallocated memory, resulting in nondeterminism on Google Colab TPUs. Using flax.linen.transforms.scan and jax.value_and_grad, both seem necessary to get this behavior, as is the sketchy looking use of multiple LSTM cells after one another (LMCell.__call__)...
What you expected to happen:
I defined a function that looks determinstic, triggered no errors or warnings, and acts "properly" on CPU and GPU, wrapped it in jax.value_and_grad (full code in notebook):
class LMCell(nn.Module):
    @functools.partial(
        nn.transforms.scan,
        length=SEQUENCE_LENGTH-1,
        variable_broadcast='params',
        split_rngs={'params': False},
    )
    @nn.compact
    def __call__(self, lstm_states):
        inputs = self.param('stuff', nn.initializers.zeros, VOCAB_SIZE)
        new_lstm_states = []
        for lstm_state, lstm in zip(lstm_states, [nn.LSTMCell() for _ in range(3)]):
            new_lstm_state, inputs = lstm(lstm_state, inputs)
            new_lstm_states.append(new_lstm_state)
        logits = inputs
        return new_lstm_states, logits

class LM(nn.Module):
    @nn.compact
    def __call__(self):
        lstm_states = [(jnp.zeros(HIDDEN_SIZE, jnp.float32),) * 2] * 3
        _, logits = LMCell()(lstm_states)
        return -jnp.sum(logits)

params = LM().init(
    {'params': jax.random.PRNGKey(0)},
)['params']

@jax.value_and_grad
def f(params):
    return LM().apply(
        {'params': params},
        rngs={'lstm': jax.random.PRNGKey(0)},
    )

I now would expect this snippet should print the same value twice:
print(f(params)[0])
x = jnp.log(-jnp.ones((20000, 20000)))
print(f(params)[0])

...but on TPUs we get 0.0 and nan in the linked Colab.
(Also, as a bonus, trying to remove the kind of useless intermediary module (LM) makes the code shorter and simpler... but also sometimes doesn't seem to terminate? And if it does yields different but still non-deterministic results? Didn't try to isolate or analyze this one much though, so feel free to ignore.)
Logs, error messages, etc:
None.
Steps to reproduce:
https://colab.research.google.com/drive/18Tcz0gQp7Eride_cFbw09FNDFPVIoScv?usp=sharing
(works the same on stable and master)

Hello and welcome @sjmielke! Wow, this is an odd issue, let me ask some folks that know more about JAX and TPUs to see if can start teasing this apart. A bunch of folks are on vacation now, so perhaps it will take a bit of time.
Have you been able to find any workaround? Or are you using GPUs for now?

I tinkered with your Colab and by adding jax.jit outside of jax.value_and_grad, it seems to work. (I changed __call__ to use jnp.ones so that I see a non-zero value). Not the most satisfying answer, but please let me know if this unblocks you.

Interesting... First of all I should've said I'm not in a hurry at all---there's plenty other stuff to be done for this project, I probably got some old pretrained RNNLMs lying around I can just swap in and even if not GPUs are indeed just fine for training the little LM I need---but thanks for the quick take up!
My predominant worry with this issue is that this looks like I did something I "wasn't supposed to" that isn't prohibited and warned about; in particular the three LSTMs seem very sketchy cause... What are the dimensions in the middle? Aren't they un(der)defined?

Nothing seems obviously wrong to me in your code, though I've never personally trained an LSTM! I'm assuming you plan to actually pipe through inputs to your layers (now you seem to be defining the inputs as parameters inside of them?)
All built-in modules use shape inference. In this case, LSTMCell deduces its output parameter shapes based on the last dimension of the hidden state passed in, and the input parameter shapes are deduced by shape inference in Dense based on the last dimension of the input passed in.
(You can always define modules with explicit in_features and avoid using nn.compact altogether, which would be pretty similar to PyTorch. But many of our users find that tedious, and we're happy to "own" the complexity in the library to avoid requiring specifying input dimensions, and allowing using flow control like conditionals and loops in forward pass functions, like in your example.)

Yeah, the original code had a bunch more complexity and was vmapping and all of that fun, I tried to reduce as much as possible, hence the nonsensical setup ;)
And of course, the hidden states! I had completely forgotten, those do determine things! Nice! Thanks!

Looks like an XLA TPU bug to me.
A pretty strange one though. I can reproduce it only with the number of LSTM stacks being >= 3.
Using jit seems like a sensible workaround but it is good to report this bug with the repro to JAX as well so they can take a closer look at the miscompilation (or autograd bug but that seems unlikely to me).

My predominant worry with this issue is that this looks like I did something I "wasn't supposed to" that isn't prohibited and warned about; in particular the three LSTMs seem very sketchy cause... What are the dimensions in the middle? Aren't they un(der)defined?

LSTMs are a little funny because the output features can be inferred from the carry shape unlike Dense or Conv where we can only infer the input features from the input arguments.

Looks like an XLA TPU bug to me.
A pretty strange one though. I can reproduce it only with the number of LSTM stacks being >= 3.
Using jit seems like a sensible workaround but it is good to report this bug with the repro to JAX as well so they can take a closer look at the miscompilation (or autograd bug but that seems unlikely to me).

My predominant worry with this issue is that this looks like I did something I "wasn't supposed to" that isn't prohibited and warned about; in particular the three LSTMs seem very sketchy cause... What are the dimensions in the middle? Aren't they un(der)defined?

LSTMs are a little funny because the output features can be inferred from the carry shape unlike Dense or Conv where we can only infer the input features from the input arguments.

@blakehechtman suggested that it may be a silent TPU OOM bug that isn't captured correctly. @jheek 's point about it not reproducing with smaller nets may suggest this as well. Probably the 20000x20000 array, the negative and the log are filling up device memory (1.5GB each)

@blakehechtman suggested that it may be a silent TPU OOM bug that isn't captured correctly. @jheek 's point about it not reproducing with smaller nets may suggest this as well. Probably the 20000x20000 array, the negative and the log are filling up device memory (1.5GB each)

I'll close this since JAX is the right place to discuss this, and there's a workaround for now. (https://github.com/google/jax/issues/5355). Thanks @sjmielke for reporting!

I'll close this since JAX is the right place to discuss this, and there's a workaround for now. (https://github.com/google/jax/issues/5355). Thanks @sjmielke for reporting!


Demo & Documentation Link in README.md is dead

404 - http://toopay.github.io/bootstrap-markdown/

Sorry guys, this has been fixed. New CNAME has been added, and it now lives at http://www.taufanaditya.com/bootstrap-markdown/