Run Keyword And Warn On Failure keyword

Hello,
A useful feature (that we have already implemented in our framework, but might be useful for everyone) is a "Run Keyword And Warn On Failure" keyword - same thing as Run Keyword And Continue On Failure, but KW passes, and issues a warning.
our current implementation in Robot Framework is:
Run Keyword And Warn On Failure
    [Arguments]  ${kw}  @{args}
    [Documentation]    When keyword fails, this passes, but a warning is issued.
    ${state}  ${output}=  Run Keyword And Ignore Error  ${kw}  @{args}
    Run Keyword If  '${state}'!='PASS'  Log  Warning: Keyword failed: ${kw} @{args}{\n}${output}  WARN
    [Return]  ${output}

This should work like Run Keyword And Ignore Error but also report possible failure as a warning, right? I guess it would be useful where you absolutely don't want the keyword to fail but don't want it fail silently either.
I want to be fairly conservative when accepting new BuiltIn keywords, but perhaps this would be useful enough. An alternative is making it somehow possible to configure the existing Run Keyword And Ignore Error to support this. What do others think? If we agree this keyword should be added, would someone be interested to provide a pull request implementing it?

I think the best keyword to add the warning option is the Run Keyword And Continue On Failure not the Run Keyword And Ignore Error.

I don't see why this would be so useful with Run Keyword And Continue On Failure. It doesn't hide the failure. It just allows execution to continue afterwards. If we decide to support this functionality by configuring existing keywords, adding such support also to that keyword wouldn't hurt. Adding a new keyword, like originally proposed, may be easier and clearer, though.

Yes, I agree that there might be some confusion on a keyword that would be Run Keyword And Ignore Error But Warn or the like.
If it is to be added, I think it's quite clear what  Run Keyword And Warn On Failure means, so it should probably be added as-is.

I have implemented the keyword in python, but I haven't been able to understand the testing framework on how to create relevant unit tests (other than a simple one issuing a failure and expecting the test case to pass). Should I do the pull request, and wait for others to fill in?

Did you read atest/README.rst?

Yes I did, unfortunately I don't have the experience required to follow the acceptance framework.

Any new info about this? I'm fine adding the requested keyword but we need a pull request. See contribution guidelines for more details.

One use case for this keyword would be turning failing suite teardowns to warnings to avoid all tests being marked failed. A benefit of that instead of using Run Keyword And Ignore Error is that you'd still see the warning in the log file. If someone would be interested to implement this, this could be added already in RF 3.1.
As a somewhat related enhancement, we could also add some kind of a note in the report that there are failures in the log file. Currently you can't see that at all in report, so warnings in logs may be accidentally ignored. This obviously requires a separate issue.

This was implemented in PR #3670 by @cristii006. Thanks for contribution!

This was implemented in PR #3670 by @cristii006. Thanks for contribution!

YM #3679.

True, this was implemented by #3679.


Fix padding byte to be compliant with spec

To document what was incorrect before: the initial padding byte value of 0x80 (128 in decimal) did not correspond to sumhash's specified padding method of "a 1 bit, then enough 0 bits to fill the block." The proper byte value is 0x01 (1 in decimal).
This is because in this implementation, bytes are interpreted least-significant bit first, for consistency with the LSB convention used in the sumhash spec and in SHA-3/SHAKE (NIST FIPS 202). In particular, byte 0x01 in LSB format is the bit string 10000000, which is how the padding should begin.


c-lightning Backup

Hello everyone. I have a problem with my c-lightning wallet or my channels. When I load the backup file, the channels are displayed on RTL, as soon as the wallet is 100% synchronized, they disappear again. I've done it three times with the result described above. The backup was created under v10.2cr2. I'm currently using v0.10.2. Could that be the problem, why do channels go away when they're 100% synced? Ps. I use Raspiblitz v1. 7.1

The channels were likely force closed as you restored the backup (possibly an outdated state).
Will need to rescan to restore the onchain balance:
https://github.com/rootzoll/raspiblitz/blob/v1.7/FAQ.cl.md#rescan-the-chain-after-restoring-a-used-c-lightning-wallet

Duplicate of https://github.com/ElementsProject/lightning/issues/4923 and also discussed on the c-lightning Discord: https://discord.com/channels/899980449231814676/899989729183940629/914655501076287550


spinbox does not support select bool

A useful feature of the textbox is that you can run "select(true)" to highlight the text. This does not appear to be possible with the spinbox, and would be a nice feature to have.
As Per:
https://qpcr4vir.github.io/nana-doxy/html/de/d10/classnana_1_1textbox.html
void 	select (bool)
Selects/unselects all text.
Yet: https://qpcr4vir.github.io/nana-doxy/html/d7/d43/classnana_1_1spinbox.html
error: ‘class nana::spinbox’ has no member named ‘select’
spbox.select(true);

Thanks for your feedback! A new commit has been checked into develop branch for this feature.


yosys: 0.22 -> 0.23

Description of changes
https://github.com/YosysHQ/yosys/releases/tag/yosys-0.23
The protobuf backend was removed in https://github.com/YosysHQ/yosys/pull/3508.
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

nixpkgs-review happy, aarch64-linux


Remove Basic-Auth requirement for staging API

...if the referrer is staging.
That will let us use the staging site to make data queries without getting API auth errors.

dupe of #63


Dockerfuse won't work on distroless containers

Investigate why and fix it, if possible.

tested, it works great actually :)


Action dim not match

In the training dataset which you provide, action dims are like:
--------------------------------------------------
Action
pose0_position : (2, 3)
pose0_rotation : (2, 4)
pose1_position : (2, 3)
pose1_rotation : (2, 4)
--------------------------------------------------

But the in the trajectory I generate by oracle, action dims are like:
--------------------------------------------------
Action
pose0_position : (2, 2)
pose0_rotation : (2, 4)
pose1_position : (2, 2)
pose1_rotation : (2, 4)
--------------------------------------------------

so are the dims of the action space of environment.
In your vima-bench, the action dims of pose0_position and pose1_position are 2, but in your training dataset, the corresponding action dims are 3.
So that the action in the traing dataset can't be used in the vima-bench environment and don't match the corresponding dim in the models you provide.
But I notice that when the dims of action['pose0_position'] and action['pose1_position']  are 3, the action can still be used in the environment,  so I'd like to ask if it means the third dim in the actions of datasets is useless and I can just ignore it. If not, how to solve this question so that the dataset can be utilized.
Thanks!

can you run the vima? I get some problems and can't run it. But i can run  vima-bench

it means the third dim in the actions of datasets is useless and I can just ignore it

yes since the primitive actions are 2D.


Security Issue (severity: medium) - jquery 2.1.1

Hello,
I used RetireJS to check for known JavaScript vulnerabilities. Can you please update to a new version of jquery or remove the dependency completely?

$ retire
Loading from cache: https://raw.githubusercontent.com/RetireJS/retire.js/master/repository/jsrepository.json
Loading from cache: https://raw.githubusercontent.com/RetireJS/retire.js/master/repository/npmrepository.json

/myapp/node_modules/hammerjs/tests/unit/assets/jquery.min.js
 ↳ jquery 2.1.1 has known vulnerabilities: severity: medium; issue: 2432, summary: 3rd party CORS request may execute; https://github.com/jquery/jquery/issues/2432 http://blog.jquery.com/2016/01/08/jquery-2-2-and-1-12-released/

any news on that?

ah I see. Its only during testing and is transitively hidden in hammerjs/jquery.hammer.js - I am going to try to upgrade it over there first

Could you remove the jQuery.min.js from test folder?
It is not need for runtime.
If someone needs to run the test, he/she could copy jQuery.min.js in the test folder.

Inactive - closing ticket


chore: disable confidential compute by default

In this PR, I disabled confidential compute org policy by default and added an example to show how FIs can use exclusion lists while enabling it.

@Ramneekkhurana I added some org policy in https://github.com/bankoncloud/terraform-example-foundation-sgmy-fsi/pull/26 to show that FIs can actually implement these controls (confidential compute, storage retention policy)
For confidential compute, I left it disabled by default although FIs can choose to enable it and add specific folders or projects to be excluded from this constraint


Output parser fails sometimes when output_schema is set.

Description
Sometimes the langchain output parser complains about parsing issues. A suggestion here is to use a smaller model that can do structured outputs from text instead of the outputparser that is notoriously unreliable.
Steps to reproduce
n/a
Acknowledgements

[X] My issue title is concise, descriptive.
[X] I have searched the existing issues to make sure this bug has not been reported yet.
[X] I am using the latest version of superagent.
[X] I have provided enough information for the maintainers to reproduce and diagnose the issue.

@homanp Can you provide some input/output examples that failed in case of you? So I can validate it is fixed.

@homanp Can you provide some input/output examples that failed in case of you? So I can validate it is fixed.

It happens radomly.


Minimize - Icon is missing in the TaskBar (lower right)

When Minimizing the Cybits-Wallet, and minimizing, the icon doesn't show up in the Taskbar bottom right tray.
Only an empty icon

Linux wallet won't minimise to the taskbar. Not on Cinnamon anyway...

Empty Icon Fixed in Windows.  I will need to test this in Linux


Nuget dependencies not complete (eg.: Newtonsoft.Json)

Instead of just touch coreApp.sln, create the sln file with dotnet and add the project to the solution:
dotnet new sln
dotnet sln add coreApp.csproj

Now you can get completion etc.

Same problem, no completion.

You didn't add the NuGet reference to your .csproj file in that example

dotnet new sln -o coreApp
cd coreApp
dotnet new console
dotnet sln add coreApp.csproj
dotnet add coreApp.csproj package "Newtonsoft.Json"
dotnet restore
vim Program.cs

Line 5 adds the Newtonsoft.Json reference, just as you manually added it to coreApp.csproj in your first example

Well then I'm stuck. I've tested those commands a couple of times now and it works fine for me with dotnet --version 2.1.101.
Could you try to create a valid program using Newtonsoft and see if it can build? Something like this:
using System;
using Newtonsoft.Json;
using Newtonsoft.Json.Linq;

namespace coreApp
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(JObject.Parse("{'Hello':'world'}").ToString(Formatting.Indented));
        }
    }
}

Then do dotnet run and see if it works?

Runs correctly, Netonsoft related completion still doesn't work.

My dotnet version is 2.1.101 too.

OK! Looking to YCM third_party directory, I see that it's using OmniSharpServer and not this omnisharp-roslyn.
I'll need ask to YCM to support omnisharp-roslyn.

https://github.com/Valloric/YouCompleteMe/issues/2959

Since it's not a roslyn problem, do you want to close the issue @DavidUser?


no cookie-cache specified for newsblur cryptic message is displayed

Newsboat version (copy from newsboat -v):
newsboat 2.10.2 - https://newsboat.org/
Copyright (C) 2006-2015 Andreas Krennmair
Copyright (C) 2015-2017 Alexander Batischev
Copyright (C) 2006-2017 Newsbeuter contributors
Copyright (C) 2017 Newsboat contributors

newsboat is free software and licensed under the MIT License.
Type `newsboat -vv' for more information.

newsboat 2.10.2
System: Linux 4.13.0-45-generic (x86_64)
Compiler: g++ 7.2.0
ncurses: ncurses 6.1.20180127 (compiled with 6.0)
libcurl: libcurl/7.58.0 GnuTLS/3.5.18 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3 (compiled with 7.57.0)
SQLite: 3.22.0 (compiled with 3.21.0)
libxml2: compiled with 2.9.4

Steps to reproduce the issue:

config file contains:

urls-source "newsblur"
cookie-cache "~/.newsboat/cookie-cache"
newsblur-login "<whatever>"
newsblur-passwordfile "~/.newsboat/newsblur_passwd"

config file does not contain cookie-cache

Starting newboat:

Starting newsboat 2.10.2...
Loading configuration...done.
Opening cache...done.
 is inaccessible and can't be created

Other info you think is relevant:
cookies from https://github.com/newsboat/newsboat/blob/master/src/controller.cpp#L289
is not set and results in cryptic message here
https://github.com/newsboat/newsboat/blob/master/src/controller.cpp#L292

Thanks for the report!
But I'm a bit confused: in step 1 you show a config with cookie-cache but in step 2 you say there's no such setting in the config file. Is that just a mistake, or am I completely misunderstanding the issue?
I just added another message that will be displayed if the setting is not set or is set to an empty value. This change will be released in 2.13 in September. Does that resolve the issue?

You're right, I messed it up, the line with cookie-cache should not be there. I did change the description.
And btw. thanks, you do awesome work!


Make a more robust README and user instructions

We know how to use the code, but Carlos (or another group) might not. Make the instructions clear, so that we can be sure people use it right.

Added extension instructions.


Suspected bug in Quaternion.to_matrix()

I have seen some suspicious behavior in the new Quaternion objects when generating rotation matrices. I've noticed very small changes in the Quaternion can produce very large changes in the transformed vector.
Every other part of the Quaternion I've worked with so far appears to be working. There are unit tests implemented for this function so I think there might be a gap in my test coverage. More work required.

Here is an example of a suspicious case.
vector = Vector3D(1, 0, 0)
orientation = Quaternion(0.7071067811865476, 0.0, 0.0, -0.7071067811865475)
transformed_vector => Vector3D(0.0, -1.0, -1.1102230246251565e-16)
new_orientation = Quaternion(0.6731265316174981, 0.02371918119564304, -0.0074266863424779506, -0.739109543441279)
transformed_vector => Vector3D(0.018625673666602283, 0.5757300372634384, 0.8174276778242251)
The amount of change in the vector for a small change in the quaternion is suspicious. I suspect the transform matrix mathematics in incorrect.

Turns out there isn't a bug. There was a misdirection in my test case that was leading to the bogus result. I've now independently verified this method with an alternative calculation.
Quaternion.transform_vector()
This vector performs the transformation directly using the equation q * v * q_star, where q_star is the complex conjugate. I will add this alternative calculation as its potentially more computationally efficient.

As proof, here is the corrected test case:

new_orientation = Quaternion(0.6731265316174981, 0.02371918119564304, -0.0074266863424779506, -0.739109543441279)
new_orientation.transform_vector(Vector3D(1, 0, 0))
Vector3D(-0.09267614575201093, -0.9953807967621223, -0.02506394713037894)


question: is it possible to further shrink wasm size using wasm-opt?

I just got a 1MB sized wasm, which might be too big for my application.

Got answer from @alexcrichton in Zulip that wasm-opt does not support component model for now

@chaosprint jco opt subcommand feeds each core Wasm into wasm-opt and then puts it back together as a component.
https://github.com/bytecodealliance/jco/

@chaosprint jco opt subcommand feeds each core Wasm into wasm-opt and then puts it back together as a component.
https://github.com/bytecodealliance/jco/

works like a charm. thank you!


Confusing wording Every author on this blog on settings page

The wording Every author on this blog on the general settings page has already led to confusion three times while I was observing people from organizations during the plugin-setup.
I would suggest to either replace it with Every user account on this WordPress site that can publish posts or add a tool-tip info button to clarify this even better.
(Accidentally reported here: https://github.com/pfefferle/wordpress-webmention/issues/497)

What version of the plugin do you currently use? Because the latest version already says:
Every author on this blog (with the activitypub capability) gets their own ActivityPub profile. You can add/remove the capability in the [user settings.](https://pfefferle.org/wp-admin/users.php) Select all the users you want to update, choose the method from the drop-down list and click on the "Apply" button.

I will close this for now, please re-open if I am referring to the wrong example!

Ah, sorry my attention was on the that can publish posts instead of the beginning of the sentence, so I have not seen the different wording there. I have no strong feelings about whether to use "user account" or "authors", so I am fine with changing it.
that can publish posts on the other hand is no longer true, because it is handled by the capability now and that can be added to every user regardless if the can publish posts or not.


All vendored artifacts need to be included in the final package

fixes #793

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
301 unchanged lines in 24 files lost coverage.
Overall coverage decreased (-3.8%) to 76.606%

Files with Coverage Reduction
New Missed Lines
%

src/main/python/pybuilder/pip_utils.py
1
94.16%

src/main/python/pybuilder/pluginloader.py
1
87.1%

src/main/python/pybuilder/plugins/python/remote_tools/init.py
1
45.24%

src/main/python/pybuilder/terminal.py
1
75.47%

src/main/python/pybuilder/plugins/python/core_plugin.py
2
89.74%

src/main/python/pybuilder/plugins/python/unittest_plugin.py
2
80.68%

src/main/python/pybuilder/plugins/core_plugin.py
3
87.88%

src/main/python/pybuilder/plugins/python/integrationtest_plugin.py
3
43.45%

src/main/python/pybuilder/plugins/python/coverage_plugin.py
4
51.83%

src/main/python/pybuilder/execution.py
5
91.44%

Totals

Change from base Build<PHONE_NUMBER>:
-3.8%

Covered Lines:
4652

Relevant Lines:
5906

💛  - Coveralls


Test fails when  is an element inside the component

For the following component the test fails but succeeds when i remove the <router-view></router-view>
Teams.vue
<template>

                        Teams

                            {{team.name}}
                            <input type="text" class="form-control" v-model="team.name" v-show="team.editing" />

                            <router-link :to="modalFor(team)">Edit</router-link>

        <router-view></router-view>

</template>


[Polymetis] Joint Locking Issues

Type of Issue
When doing joint control (both qpos control and qvel control) the joints frequently freeze because a joint position or joint velocity limit was exceeded.
Description
I think it's great that Polymetis has checks for this, but they way the code handles it is extremely irritating.
For example, when I am doing everything via joint position control, rather than having the joint impedance controller clamp the outputted joint velocities and torques to a safe limit, they send them out, and then the safety controller freezes the whole robot because a safety constraint was violated. And, because I have no access to the outputted velocity/torque values, I can't clamp them myself.
Expected Behavior
I think it would be much more helpful if the safety controller just made the robot move slower and softer, and didn't force it to freeze up for a few seconds.
Steps to reproduce
Lmk if this is needed.

On a similar note, I'm working on an IK solver that tries to work around these issues. It is backed by dm_robotics, so it could be of interest to the dev's
Although it can avoid the joint limit errors, I can't do anything about the velocity and torque errors since it's the low level controller outputting those
real_robot_ik.zip

Good point, thanks for the feedback!
For now, a quick fix would be to limit your pose updates to be within a proximity of the current pose.
If that doesn't work, you should be able to clamp them yourself by writing a custom controller. A similar example can be found here, and you can also copy / inherit from our current joint impedance controller here

Hey Austin! I tried out the new controller, and it is SO MUCH better! Thank you so much for all your hard work!!!
The only major remaining roadblock I have in using this controller for large scale demo collection is the joint locking issue. I think I've found a solution to half of it (wanted to run it by you since you're an awesome roboticist), and would love your help in solving the other half.
I believe there are two causes of joint locks:

Hitting a joint limit and using updates of the form desired_new_pos = desired_current_pos + action. Once you violate a joint limit, its very hard to un-violate it with such an update rule. I've fixed it by projecting the desired_new_pose into a feasible space, and using that instead in the next update rule:

EXAMPLE
def update_desired_ee_pose_local(
    self,
    position: torch.Tensor = None,
    orientation: torch.Tensor = None,
) -> int:
    """Update the desired EE pose used by the Cartesian position control mode.
    Requires starting a Cartesian impedance controller with `start_cartesian_impedance` beforehand.
    """
    joint_pos_current = self.get_joint_positions()
    ee_pos_current, ee_quat_current = self.get_ee_pose()
    ee_pos_desired = ee_pos_current if position is None else position
    ee_quat_desired = ee_quat_current if orientation is None else orientation

    joint_pos_desired, success = self.solve_inverse_kinematics(
        ee_pos_desired, ee_quat_desired, joint_pos_current
    )

    if success:
        feasible_pos, feasible_quat = self.robot_model.forward_kinematics(joint_pos_desired)
    else:
        log.warning(
            "Unable to find valid joint target. Skipping update_desired_ee_pose command..."
        )
        feasible_pos, feasible_quat = self.robot_model.forward_kinematics(joint_pos_current)

    self.update_desired_joint_positions(joint_pos_desired)

    return feasible_pos, feasible_quat

Then Later: desired_current_pos = [feasible_pos, feasible_quat]
EXAMPLE

As discussed above, the outputted joint velocities and positions can break Polymetis's safety constraints. We can fix this by clamping the outputted low level joint velocities and positions (however, I can't figure out where I should be doing this in Polymetis), and then (similar to above) returning the feasible_pose after clamping. Another option which is probably harder is if there was some robot_interface function that allowed you to pass in desired commands (joint or cartesian) and then returned a feasible_and_safe version of it.

Looking forward to your reply :)

One other issue that's relatively small but frequent. The new controller oscillations around certain desired poses rather than converging. I've included an example video:
https://user-images.githubusercontent.com/30299984/184045697-f8112133-59bc-4b67-ac92-cd95f9ba6cdf.MOV

Hi Alexander! Glad you liked our new controllers!
Joint locks & limits
I completely understand that constantly triggering safety constraints out of nowhere can be frustrating, but we also don’t want to modify user commands too much behind the curtains either. We will be iterating on what the ideal user interfaces should be, which will take some time, but you are helping us to do so immensely by sharing your detailed experiences in these issues!
Projecting the commanded position into a feasible space might be desirable and a handy functionality to have, but as the feasible space is non-convex I don’t know how to do it off the top of my head. Also I’m not sure I understand what your script is trying to do. It seems like you are simply using the current pose if the target pose is not feasible.
If the action space of your policy is delta positions & orientations, I would simply constrain the action space to a reasonable magnitude (ex: no more than 10cm and 5 degrees per second, so like 5mm if you’re controlling at 50hz). This should be enough to not trigger any velocity & torque constraints. Combine that with desired_pose = current_pose if unfeasible else desired_pose to prevent hitting joint limits and you should be good.
IK
Our IK implementation currently is indeed quite naive, implemented as simply a gradient descent on forward kinematics. We will be focusing on improving on that aspect next, and will also consider the implementation in dm_control. The line of work will be tracked in #1336.
Oscillations
The controller oscillations is concerning, can you share the joint positions at which this is happening so I can try to repro? However, it does look like you are controlling the arm at a rather awkward pose near certain joint limits, and thus moving the manipulated objects farther away from the robot would definitely help.

My proposed solution:

My logic here was to project the pose into what's feasible joint wise. However, on closer inspection, I think the real benefit here is coming from using feasible_pose instead of desired_pose when an IK solution is not found (hence keeping the process in feasible space)

Action Velocity is not the only (or main) cause of joint locking:

I have tried changing the norm of my actions to be unreasonably small, but the issues I'm experiencing are still just as present. I've included an example video below.
I have one possible theory: Maybe when a nearby solution is not found, the IK finds a solution that is very far in joint space and that abrupt commanded movement is the source of these issues?

Uploading small_video.mov…
Oscillations:

After some investigation, I think this might have been the fault of my stack (action norms too big?). I'll update you on if I see this issue again :)

We're also facing similar joint limit reached issues in our setup. It would be really helpful if we can identify the root cause of the problem.

Which functionalities are you using that are causing the joint limit issue?
The root cause should be quite straight forward -- the joints are running into their limits (the limits we impose within Polymetis is only a few degrees stricter than the hardware limits.
If you are using move_to_joint_positions or update_desired_joint_positions, then you are probably commanding it to joint positions that exceed the limits. (Hardware limits can be found here)
If you are using move_to_ee_pose or update_desired_ee_pose to command the robot, then it might be due to limitations of our current IK planner, or due to the fact that you are commanding it to an infeasible pose.

Hello all, I hope you've been well! We have begun our data collection process, and the #1 comment back from our beta testers was complaints about the joint locking issues. A solution of any kind to this problem (even a short term solution) would be extremely appreciated :)

One idea is a function which tells us is_ee_pose_feasible(pos, quat), which tells us if it's reachable / won't lock joints if we send it. This would be enough for now :)

Also, do there happen to be any updates on progress for this?

@AlexanderKhazatsky @mohanksriram

Can you specify what limits are you hitting? Is it joint position, joint velocity, joint torques, Cartesian soft limits, Cartesian hard limits, self-collision? This should be a fairly comprehensive list; please paste the server logs when you encounter the joint-locking behavior.
How are you generating the desired joint positions/velocities? From your video, it does look like you're asking for pretty pretty awkward joint configurations.
a. If you ask for infeasible joint states, the hardware itself (i.e. libfranka) refuses to continue; Polymetis may "lock up" by attempting to reinitiate the control loop, but there's basically nothing we can do if you request infeasible joint states. You can customize the limits if you want, but they're pretty close to the hardware-defined limits.
b. You can run arbitrary torch policies with Polymetis, so it's very simple to add a clamping function at any step you want. Read the TorchControl docs for the details; if you have controllers that work better, we're very happy to take contributions!
c. In particular, if you have a precise function definition of "feasible ee pose", please do share the code. We currently have soft limits which push the end-effector when it nears the edges of the workspace (defined here), but we aren't doing any self-collision checking or anything more complicated. Our default joint-space planners take into account velocity limits by computing a reasonable time_to_go such that we avoid violating velocity limits. If you have a better definition of feasible, please share!

In particular:

If you want to clamp joint torques, that's just the output of the forward function for every controller (e.g. HybridImpedanceControl).
If you're using the output of a joint-space planner, you have direct access to the desired trajectory (e.g. here).
If you're using the update_desired_*_positions paradigm, you can clip the desired values before sending them to the update function.

I am hitting joint position limits (probably because IK uses real joint limits instead of the padded joint limits. This seems like a simple fix. I am also (this is the hardest to solve) hitting joint velocity limits. This happens with no correlation to actual commanded speed (ie. it occurs even with minute delta movements). Maybe the IK planner commands large joint changes under the hood? Typically the violations are by a very small amount. If it would still be helpful to post the logger outputs I'm happy to do this.
2a. I slightly reduced the occurrence by clamping there desired commanded angles between -pi/2 and pi/2 (which I think should be a reasonable request). However, the issues are still very much present. I would like a way to operate within this cartesian space without running into joint locking issues. If a certain pose would cause issue, I would just like the command to return a message me telling me so, and this will fix my problem.
2b. Clamping torque output helped a little bit, but didnt solve the issue entirely, while also making the robot unreasonably slow :(
2c. When I request a "feasible ee pose", I am referring specifically to a use case for the cartesian impedance controller, which is where I encounter these joint locking issues. I would really appreciate some function "feasible ee pose" which just tells me whether or not sending a certain cartesian impedance command will cause a joint lock. An equivalent function for sending a joint impedance commands would also be fine. Then I can just not take this step and my problem will be solved :)

In response to your second comment, the issue still happens when clipping desired values. Are you guys encountering it on your side?

We're not using continuous Cartesian control much, so maybe that's why we haven't been experiencing these issues.
If the IK is commanding large joint movements for small EE movements, do you think you can try clamping the IK solution to within a certain range of the current joint pose? This will sacrifice some accuracy, but should eliminate joint locking caused by velocity limits. Also, the arm should ultimately get to the commanded pose if it is feasible over multiple updates.
I have a feeling this might resolve all joint-locking problems, as this will also prevent user commands from overpowering our safety controllers, which safeguard the joint position limits.

Hi Austin! So by VERY pessimistically clamping the qvel outputted by the IK (aka qpos_output - qpos_current), and clamping the resulting qpos to valid range (padded a bit to account for the safety controller) the issue seems to be gone. This is great, but movement is noticeably slower and less accurate unfortunately (although not unusable). Also, the IK can still be pretty crummy and does a bad job at keeping joints centered (which would make this clamping required a lot less often). In practice, I had to clamp qvel by 0.1 * qvel_limit to completely avoid the issue.
If you can provide any of the following updates to the code, it would be enormously appreciated:

Add an option for the IK to use the safety joint limits instead of those in the URDF
Add an IK solver that has a regularizer term for staying near joint centers
Add an IK solver that can be constrained to a max qvel

I think the dm_control IK has all these, and with very pessimistic values also works as a fix.  More generally, I think a quadratic programming based solver which can take all these things into consideration might be more intelligent than what is available now.
Thank you as always!

On another note, I confirmed the oscillations were coming from my code and fixing it removed it entirely :)

Glad to hear the oscillations are gone.
It seems like you're looking for a better IK library; packaging a nicer IK library into Polymetis is definitely something on our roadmap, since our IK implementation is rudimentary. Besides dm_robotics, are there any others you'd suggest looking at? We've looked at ikpy, trac_ik_python, and some others. ikpy in particular is fairly hackable. Let's follow up on #1336 for tracking this.

Hello all, I spent some time with the dm_control IK today, and it actually seems to elegantly solve all the issues. It has parameters for staying near joint centers and also for restricting joint deltas. The new controller seems to be able to smoothly move through complex orientations without ever joint locking.
I can share my wrapper for it, along with a use example. I think it could be worthwhile to look into adding it to polymetis :)

real_robot_ik.zip
Example Usage:
self._robot = RobotInterface(ip_address="localhost")
self._ik_solver = RobotIKSolver(self._robot, control_hz=20)
desired_qpos, success = self._ik_solver.compute(desired_pos, desired_quat)
self._robot.update_desired_joint_positions(desired_qpos)

Hey! We are going to start spreading our control scheme across labs involved in our data collection process, and I was wondering if this might be Incorperated soon :)

Hi @AlexanderKhazatsky! I took a look through the IK solver, and although the solution looks good it introduces large dependencies (especially MuJoCo, which is non-trivial to wrap in Conda) and requires additional MJCF robot files to run. Given the amount of work needed, we currently don't have many cycles to work on it but I'll update this issue if anything changes.

That’s totally valid! Although I just used mujoco because they wrap all the math for me. I think it would be very possible to look through the code and purely pluck out their optimization procedure for IK conditioned on a set of hyperparameters.
We’ve been using polymetis + this more advanced IK at our lab for some time now and had seen a ton of benefits (namely that joints stay in safer positions and reach limits less, joints never lock anymore no matter the command, and IK is very customizable for getting rid of case by case behaviors you want to avoid). I think it could certainly be worth the investment, but I understand you guys are busy :)


Bug: enable MFA error while calling it via nodejs SDK

I'm trying to set MFA via SDK and catch the following error.
I'm calling the same endpoints as it is on the UI:

initiate
response:

{
  status: 'ok',
  msg: '',
  sub: '',
  name: '',
  data: {
    enabled: false,
    isPreferred: false,
    mfaType: 'email',
    recoveryCodes: [ '5823d499-7fd2-4c0b-afec-6517c3a1a685' ]
  },
  data2: null
}

enable
response:

{
  status: 'error',
  msg: 'recovery codes is missing',
  sub: '',
  name: '',
  data: null,
  data2: null
}

Upd: Payloads the same as it is on the UI

@dshilovprpl If you use sdk to call the API, please set a time interval between calls, such as 200 ms. The beego framework has some bugs in its session when processing concurrent requests.

@leo220yuyaodog
I tried it, but still the same. I split calls to different endpoints and wait about minute before the call enable

@dshilovprpl Have you update your Casdoor version to V1.536.0 ? I use API to enable the MFA of user successfully.

@leo220yuyaodog
Yeah, I'm using latest (V1.536.0) version.

I used not built-in organization - I created organization and created cert for it.
I used node js SDK.

I think, that you have used admin token for the making requests.
Maybe cause of issue on difference between authorization and access rights for the admin and SDK auth via cert?
Or maybe it is using another session and system can't find recovery codes?

@leo220yuyaodog Yeah, I'm using latest (V1.536.0) version.

I used not built-in organization - I created organization and created cert for it.
I used node js SDK.

I think, that you have used admin token for the making requests. Maybe cause of issue on difference between authorization and access rights for the admin and SDK auth via cert? Or maybe it is using another session and system can't find recovery codes?
UPD: Installation - k8s with redis

I think it may be the session problom, you need to set cookie in nodejs sdk and send request to mfa/setup/enable with the sessionId in the response of mfa/setup/initiate. Because Casdoor uses session to store the recovery codes. I'm not sure if the nodejs sdk sets cookie automatically. In the browser and postman, it default has the cookie.

@leo220yuyaodog Thank you! You right. I prepared PR for the nodejs SDK: https://github.com/casdoor/casdoor-nodejs-sdk/pull/48


Added JDK 7 source compatibility

Original Issue: #11

Upgraded Gradle to version 2.9
Added Java 1.7 source compatibility
Upgraded Android Plugin to 1.5.0
Removed Gradle wrapper task(simply run gradle wrapper) to upgrade the wrapper

I guess just running gradlew wrapper is okay. The reason I usually like to explicitly set the task is so that I get everything and not just the binaries of the Gradle version.

@vanniktech If you want everything, change the wrapper.propteries from:
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-2.9-bin.zip

To:
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-2.9-all.zip

Yeah I know but with the old configuration ./gradlew wrapper just did all of that for me and I only had to change the number


Delta Operation incomplete generation

I found that it cannot be rebuilt properly for a specific file during use.
How to reproduce
It occurs in the line 310 io.ReadAtLeast return value of 0 and EOF in the CreateDelta function.
This is closely related to the configuration of RSync.BlockSize and the size of new files.
n, err = io.ReadAtLeast(source, buffer[validTo:validTo+r.BlockSize], r.BlockSize)

I made a simple modification based on the ExempleRsync method in exemple_test.go to show this situation.
package rsync_test

import (
	"io"
	"os"
	"strings"
	"testing"

	"github.com/minio/rsync-go"
	"github.com/stretchr/testify/assert"
)

func Test_Rync(t *testing.T) {
	oldContent := "1234"
	newContent := "123456789123456"
	blockSize := 3

	oldReader := strings.NewReader(oldContent)
	rs := &rsync.RSync{
		BlockSize: blockSize,
	}

	// here we store the whole signature in a byte slice,
	// but it could just as well be sent over a network connection for example
	sig := make([]rsync.BlockHash, 0, 10)
	writeSignature := func(bl rsync.BlockHash) error {
		sig = append(sig, bl)
		return nil
	}
	rs.CreateSignature(oldReader, writeSignature)

	var currentReader io.Reader = strings.NewReader(newContent)

	opsOut := make(chan rsync.Operation)
	writeOperation := func(op rsync.Operation) error {
		opsOut <- op
		return nil
	}

	go func() {
		defer close(opsOut)
		rs.CreateDelta(currentReader, sig, writeOperation)
	}()

	var newWriter strings.Builder
	oldReader.Seek(0, os.SEEK_SET)

	rs.ApplyDelta(&newWriter, oldReader, opsOut)

	result := newWriter.String()
	assert.Equal(t, result, newContent)
}

How to solve
Comment out lines 320 through 322
	n, err = io.ReadAtLeast(source, buffer[validTo:validTo+r.BlockSize], r.BlockSize)
	validTo += n
	if err != nil {
		if err != io.EOF && err != io.ErrUnexpectedEOF {
			return err
		}
		lastRun = true

		data.head = validTo
	}
	//if n == 0 {
	//	break
	//}

I'm not sure this raises any other questions

If the modifications are reasonable, I can provide PR and supplement relevant tests.

I think there is an issue with the rsync algo itself (or I'm missing something in its expected behavior).
I've build a fuzzing test and I saw several examples of failure.
Failures happen when BlockSize is smaller than the size of the whole data to sync.
I tried to comment the lines as said in the previous comment but it still fail.
I tried the same fuzzing test on https://github.com/jbreiding/rsync-go and it fails too.
go version go1.22.6 darwin/amd64
package rsync_test

import (
	"bytes"
	"io"
	"math/rand/v2"
	"testing"

	"github.com/minio/rsync-go"
	"github.com/stretchr/testify/assert"
	"github.com/stretchr/testify/require"
)

func FuzzSync(f *testing.F) {
	f.Fuzz(func(t *testing.T, message []byte) {
		if len(message) == 0 {
			return
		}

		rs := &rsync.RSync{
			BlockSize: 1 + rand.IntN(len(message))*2,
		}

		n := 1 + rand.IntN(len(message))
		if n > len(message) {
			n = len(message)
		}

		mode := "expand"
		oldContent := message[:n]
		newContent := message
		if rand.IntN(2) == 0 {
			mode = "shrink"
			oldContent = message
			newContent = message[:n]
		}

		result := sync(t, rs, oldContent, newContent)
		assert.Equalf(t, newContent, result,
			"%d,%s:\t%#v\noldContent:\t%#v\nnewContent:\t%#v",
			rs.BlockSize, mode, message, oldContent, newContent)
	})
}

func sync(t *testing.T, rs *rsync.RSync, oldContent, newContent []byte) []byte {
	oldReader := bytes.NewReader(oldContent)

	// here we store the whole signature in a byte slice,
	// but it could just as well be sent over a network connection for example
	sig := make([]rsync.BlockHash, 0, 10)
	writeSignature := func(bl rsync.BlockHash) error {
		sig = append(sig, bl)
		return nil
	}
	err := rs.CreateSignature(oldReader, writeSignature)
	require.NoError(t, err)

	var currentReader io.Reader = bytes.NewReader(newContent)

	opsOut := make(chan rsync.Operation)
	writeOperation := func(op rsync.Operation) error {
		opsOut <- op
		return nil
	}

	go func() {
		defer close(opsOut)

		err := rs.CreateDelta(currentReader, sig, writeOperation)
		require.NoError(t, err)
	}()

	var buf bytes.Buffer
	oldReader.Seek(0, io.SeekStart)

	err = rs.ApplyDelta(&buf, oldReader, opsOut)
	require.NoError(t, err)

	return buf.Bytes()
}

A race condition is detected in the fuzzing test, I'll dig it, it may be the test itself.

It was a race condition in rsync.go


Add support for OpenTracing error/message

This module should relay any failures it gets from Redis into the active Span. This helps to detect errors, rather then letting failing spans continue silently.

Solved as v0.3.0 of a5a6b68dba7482a77e13389186b1a2faeb2479b0


Rationalise repo labels

See https://github.com/SciTools/python-stratify/labels

@bjlittle I don't see the value in having the "New: Pull Request" label. Surely it just applies to all new PR's, and isn't applied or removed automatically.

@bjlittle I don't see the value in having the "New: Pull Request" label. Surely it just applies to all new PR's, and isn't applied or removed automatically.

@HGWright  Yeah, I kinda agree. I'd take the opportunity to purge any labels that exist and are never used.
I love the automation approach, as it's almost legitimizing the need for each label.
So tidy-up and purge as you see fit. Go for it!
At the end of the day, we can always reinstate a label if we eventually realise that it has genuine value.

I think the "New: Pull Request" label was to help Peloton keep track of what we'd looked at.

I think the "New: Pull Request" label was to help Peloton keep track of what we'd looked at.

Yes, but despite best efforts we would reliably forget to remove the label once the pull request had been discussed. So over time ALL pull requests ended up with the label.

Ok, the "New: Pull Request" label has been removed as it is no longer necessary. It is however used by some of the reusable workflows but I believe that would cause any problems as some other SciTools repos don't have the label but still use the workflows.


IWebXRHitTestOptions should expose options to hit test against XRHitTestTrackableType instead of assume a default implementation

Is your feature request related to a problem? Please describe.
When hit testing against real world geometry (e.g. through ARKit/ARCore), the hit test seems to be very specific to a particular implementation.
E.g. On the ARCore implementation [Source link], this is XRHitTestTrackableType.mesh which seems to be the most restrictive.
            // Iterate over the results and pull out only those that match the desired TrackableType.  For now we are limiting results to
            // just hits against the Plane, and further scoping that to Poses that are contained in the polygon of the detected mesh.
            // This is equivalent to XRHitTestTrackableType.mesh (https://immersive-web.github.io/hit-test/#hit-test-trackable-type-enum).

For apps looking to build an app using BabylonJS as its XR abstraction, it is desirable to be able to configure the specifics of what hit testing would be against.
Describe the solution you'd like
When configurating a WebXRHitTest, a XRHitTestTrackableType option (through IWebXRHitTestOptions ?) should be exposed.
Discussion
https://github.com/BabylonJS/BabylonReactNative/issues/53

Sure! makes sense. I have already added entityType to the webxr.d.ts file, it is a matter of exposing it in the configuration. Also noticed the mesh type is missing, will add that as well


Workaround for Error Messages

Under certain conditions, Rscript gives a warning message of:
WARNING: ignoring environment value of R_HOME

When there seems to be a (valid but unusual) setup of R_HOME.  As a
result, the command to determine the endianess of the system returns
WARNING: ignoring environment value of R_HOME little

instead of just “little”. causing this script to think it is little
endian when it isn’t.  This pull changes the configure script to
remove this warning message before checking the endianness.

The tests are failing due to a recent change in the pandas library unrelated to this pull, and the master branch currently fails tests as well.
The tests do pass on version 0.18 of Pandas but not on the new 0.19 version released 4 days ago.  I would like to get this fix added to the CRAN package, would it help the merge if I changed requirements.txt to specify version 0.18 of pandas?

Current coverage is 80.76% (diff: 100%)

Merging #237 into master will not change coverage

@@             master       #237   diff @@
==========================================
  Files            12         12
  Lines           915        915
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits            739        739
  Misses          176        176
  Partials          0          0

Powered by Codecov. Last update dca1a34...bfb870d

Saw the tests were fixed and rebased on master.

I am hitting this issue as well, will this fix be merged?

Sorry fro for the delay, merging.


Cannot connect to remote Mongo server

This driver seems very nice. I use it in my elixir project.
This is my code to connect to my remote mongo server. But it returns error.
iex> :mongo.connect("db_name", "account", "password", "safe", "master", [{"host", "example.com"}, {"port", 27017}])
** (EXIT from #PID<0.88.0>) {:errmsg, "auth failed", :code, 18}

(I've tried to connect by my local mongo client and it works.)
Is this right format of the :mongo.connect/6 command when use in elixir?
Please help me!

According to spec of connect :
-spec connect(database(), bson:utf8(), bson:utf8(), write_mode(), read_mode(), proplists:proplist()) -> {ok, pid()}.

Database should be binary or atom, UserName and Password should be binaries, write and read modes should be atoms.
Correct your connect code and try again. I think it is a problem.

Thank you a lot for response soon!
I've tried to modify the code as below:
iex> :mongo.connect(:db_name, "account", "password", :safe, :master, [{"host", "example.com"}, {"port", 27017}])
** (EXIT from #PID<0.88.0>) {:errmsg, "auth failed", :code, 18}

And still face the same error.
Do you have any idea about this problem?

We've solved the connection issue by modify code to this:
:mongo.connect(:db_name, "account", "password", :safe, :master, [{:host, 'example.com'}, {:port, 27017}])

Thank for your supporting.
Anw, could you make the api more consistent for Elixir? It will be much more helpful.


Prototype Update - Intake Process w AXIS Integration

Title of ticket: Prototype Update - Intake Process w AXIS Integration
Description
Updating prototype based off of discuss with Abin about options with AXIS Integration for Intact Team to ensure they are duplicate as little work as possible.
Dependencies

[x] Meeting with Abin about Integration options for Intake Process

DOD

[x] Update Design
[x] Push to Prototype

https://jacklyn808742.invisionapp.com/console/share/3W2O64AP5C/874445059


Allow routes to be registered to a protocol handler.

Adding a protocol to an existing class/instance in our application is much more useful than the DPLRouteHandler.
Thoughts?  I think this gives us everything we need :)

Interesting. We started with a protocol, then opted for a class to provide default behavior. At quick glance, it looks like you've combined the two concepts. I like the flexibility that provides. I'll take a deeper look later.


Simplify the Python code for  'Writing your own stateful application'

Simplify the Python code for  'Writing your own stateful application'.
Is this a bug, feature request, or feedback?
Feedback.
What is the current behavior?
I found it a bit unintuitive
that self.votes was a dictionary of the form {alphabet:object(alphabet,votes),......} ... i.e., storing the alphabet twice!
What is the expected behavior?
You could consider getting rid of the class Votes and simply make self.votes to be a dictionary of the form {alphabet:votes,......}.
Eliminating the class Votes will also help the flow of the 'Partitioned Stateful Application' where you could introduce the class Votes as a replacement for one large state object (class AllVotes).
What OS and version of Wallaroo are you using? If you have a stacktrace and/or steps to reproduce the issue, that also helps a lot.
Version=0.5.0. OS details are not useful here.

This seems like a reasonable change. @SeanTAllen do you remember if there was any reason we stored a Votes object in the dictionary rather than only storing the count? The only reason that I can see for doing it like that is that it more closely matches what we do in the next section, "Writing your own partitioned stateful application", but I may be missing some other good reason for doing this.
This code is from examples/python/alphabet, so if we change it in the documentation we should probably change it in the example as well.

I do not remember. @jtfmumm would be a better person to ask.

I have no objection to that change.


Add set_peer_timeout to NetworkedMultiplayerENet.

Closes #35349 (superseded). Added docs, error messages.
Fixes #20056 .
Probably worth a cherry-pick, should auto-merge.

Thanks!

Cherry-picked for 3.2.4.

is this fix now included in the v3.x branch? you removed the cherrypick label

Yes, it was cherry-picked on March 1, so it's included in 3.2.4 RC 4 and later.

thanks ;) i downloade RC_8 and it works like a charm

Was this removed from Godot 4.2?

I believe in 4.0+ this is ENetPacketPeer::set_timeout.


test app::components::preview_file::tests::works_with_one_arg hangs and does not finish

When I run cargo test I just get : test app::components::preview_file::tests::works_with_one_arg has been running for over 60 seconds and it hangs
(Also I'm writing a PKGBUILD for addition to the Arch User Repository, is that okay ?)

Whoops. I think this is a weird subtlety between cargo-nextest and cargo test, because nextest doesn't hang somehow. I'll fix the test, and thanks for letting me know! Thanks for writing something for the Arch User Repository, too!

Should be fixed with bf57de8822e068c1b9b83e19565518756e18c1a0! Let me know if the issue persists.

Don't really want to open a whole issue just for that but this program is now on the AUR !

Thanks for your work! I don't really know how to contribute to something on the AUR, but after quickly scanning the PKGBUILD of the non -git version; it looks like I can update the version number and recompute the shasum. I don't have an account for Arch Linux though, and I can't get one because of the captcha.
Or, I see the "flag package-out-of-date", which I assume just notifies the maintainer.

Yeah, I can do it, no problem
If you manage to get an AUR account I can still put you as maintainer
Yes the out of date flag notifies the maintainer and marks it when installing it through a AUR helper

Good to know! I was able to get an AUR account, under the name of "dzfrias". Thanks again for the work you've done!

I updated the packages on the AUR. I'll add you as a maintainer ! (I can still do the maintaining job, it doesn't bother me at all :relieved: )

Sounds good!


fix Set DYLD_LIBRARY_PATH for macOS in be startup script

Description

Added logic to set DYLD_LIBRARY_PATH for macOS in the setup_java_env function of the startup script.
This change ensures that the necessary Java dynamic libraries are correctly loaded on macOS.

Changes

Modified setup_java_env function to include DYLD_LIBRARY_PATH setup for macOS.

run buildall


Add start_date to  sources have incremental streams

Description

Provide description here

Type of change

[ ] Bug fix
[x ] New feature
[ ] Breaking change

Related issues

Fix #1

Migration notes

Describe migration notes if any

Extra info

Add any additional information

@huongtn We decided to keep the convention we established in our feeds to use relative dates (e.g. 90 days ago) instead of absolute dates in our configs. Please convert these start_date params in this PR to accept an integer value representing how many past days of data to collect, just like how our feeds operate.

@huongtn We decided to keep the convention we established in our feeds to use relative dates (e.g. 90 days ago) instead of absolute dates in our configs. Please convert these start_date params in this PR to accept an integer value representing how many past days of data to collect, just like how our feeds operate.

ok @cjwooo , let me update

@cjwooo I updated for the request, please help to review

Will merge after I update the configs used in the source acceptance tests.


[v1.31] Markdown preview not working

Description:
The markdown extension doesn't seem to work anymore on the Arch (Linux) version. This only happens in version 1.31
Whenever it is called a command 'markdown.[command]' not found message shows up. The extension is properly installed however and is loaded correctly.
I've also tried to make a clean install, removing all user files, settings and extensions, but the problem persisted.
Additional info:

Version: 1.31.0
Commit: bb1e228e30ce43ebb361c84fdf2f0d4fb7fda6ce
Date: 2019-02-09T14:23:42.615Z
Electron: 2.0.16
Chrome: 61.0.3163.100
Node.js: 8.9.3
V8: 6.1.534.41
OS: Linux x64 4.20.6-arch1-1-ARCH

Steps to reproduce:
Simply open a markdown file and try opening the preview, either via keyboard shortcuts or the preview button on the upper right.

I can confirm, same configuration

@MatteoCampinoti94 Please try checking the developer console for errors:

The run Developer: Toggle developer tools command in VS Code. This should open developer tools
Open the developer tools console.
Please share any errors or stack traces printed in that console

Done, it seems to be a regexp error.
[Extension Host] Here is the error stack:  SyntaxError: Invalid regular expression: /(\p{Alphabetic}|\p{Number})+/: Invalid escape
	at new RegExp (<anonymous>)
	at t.activate (/usr/lib/code/extensions/markdown-language-features/dist/extension.js:1:49711)
	at Function.t._callActivateOptional (/usr/lib/code/out/vs/workbench/services/extensions/node/extensionHostProcess.js:741:354)
	at Function.t._callActivate (/usr/lib/code/out/vs/workbench/services/extensions/node/extensionHostProcess.js:741:25)
	at /usr/lib/code/out/vs/workbench/services/extensions/node/extensionHostProcess.js:740:206
	at <anonymous>

@bpasero This error seems related to the electron update. Our previous version of node did not support unicode classes in regular expressions but Node 10 should

Updated to 1.31 and on Arch Linux as well, here are my error output if it helps.
Error: command 'markdown.showPreviewToSide' not found
    at Proxy.t._tryExecuteCommand (workbench.main.js:3226)
    at workbench.main.js:3225
    at <anonymous>
t.onDidNotificationChange @ workbench.main.js:2561
(anonymous) @ workbench.main.js:2561
e.fire @ workbench.main.js:81
t.notify @ workbench.main.js:2621
t.error @ workbench.main.js:3778
t.onError @ workbench.main.js:3211
(anonymous) @ workbench.main.js:3211
Promise rejected (async)
(anonymous) @ workbench.main.js:3210
setTimeout (async)
t.runAction @ workbench.main.js:3210
t.run @ workbench.main.js:3210
e.run @ workbench.main.js:1066
t.elementSelected @ workbench.main.js:1129
(anonymous) @ workbench.main.js:1123

@mjbvz can you try to reproduce in standalone Electron running as node?

@bpasero It will take me time to setup an arch linux machine with gui. Can't find a pre-build container
@MatteoCampinoti94 Back in the developer tools, can you please share the output of running process.versions in the developer console:

@mjbvz Here it is

I've also tried to install the binary from Microsoft via the AUR and that version does work properly. I'm starting to think the error might be in the Arch package itself, I've checked its PKGBUILD and it seems it's using the lts version of nodejs (which is at version 8.9 if I remember correctly).

Thanks. Looks like that package is still using electron 2 https://www.archlinux.org/packages/community/x86_64/code/ but VS Code 1.31 requires electron 3.
Since I believe code package is maintained by the community, please file an issue against them so that they can pick up electron 3

Yeah, seems like it. Thanks for the help, I'll send a bug report to the maintainer and build the package myself for the time being.

Discussion for the update to electron 3 has already started  https://bugs.archlinux.org/task/61691

The updated package using electron 3 has now been released to the archlinux community repository.

Thank you for the update @eli-schwartz !

Thank'you, I can confirm that now it works

Yup, that fixes it for me. Thank you for the quick turnaround!


Getting EF Core to use DbLoggerCategory  with NLogLoggerProvider

I am trying to log information from Entity Framework Core and we use NLog for all our logging. I want to have information from EF logged using NLog. What I have found so far (and it works) is to define a static LoggerFacctory:
public static readonly LoggerFactory m_myLoggerFactory = new LoggerFactory(new[] { new NLogLoggerProvider()});
I then load the NLog LogManager with the NLog configuration file:
NLog.LogManager.LoadConfiguration("nlog.config");
I then set the DbContextOptionsBuilder to use the logger factory:
options = new DbContextOptionsBuilder<PublixInventoryContext>()
         .UseLoggerFactory(m_myLoggerFactory)
         .UseSqlServer(connectionStr,
              x => x.MigrationsAssembly("PublixInventory.DataAccess"))
         .Options

The issue is that this logs all information from EF. In many cases this is too much information and I have a hard time finding what I am looking for in the logs. What I would like to do is allow the message level to be set to a DbLoggerCategory level. For example:
public static readonly Microsoft.Extensions.Logging.ILoggerFactory _myLoggerFactory =
        new LoggerFactory(new[] { new
         Microsoft.Extensions.Logging.Console.ConsoleLoggerProvider((category, level) =>
              level >= LogLevel.Trace
         , false, false)
});

The problem is I do not see away to set EF to this log level when I am using the NLogLoggerProvider. How do I set EF to the DbLoggerCategory level I wish to use for EF logging?
Thank You,
David Demland

Yes the `NLogLoggerProvider´ contains no filtering, but expects the filtering to happen through the NLog-LoggingRules in the NLog-Configuration.
You can ofcourse create your own wrapper around the `NLogLoggerProvider´, where you can explicit specify the LogLevel.

I am sorry, but I do not understand how to make either of these solutions work. First of all, it seems that the NLog-LoggingRules assume NLog level settings. Based off of the information at: https://www.entityframeworktutorial.net/efcore/logging-in-entityframework-core.aspx Entity Framework filtering of:
DbLoggerCategory.Database.Command
DbLoggerCategory.Database.Connection
DbLoggerCategory.Database.Transaction
DbLoggerCategory.Infrastructure
DbLoggerCategory.Migrations
DbLoggerCategory.Model
DbLoggerCategory.Query
DbLoggerCategory.Scaffolding
DbLoggerCategory.Update
is based off of object types. I do not see how NLog can map from these object types to NLog levels. Also, I do not understand how creating a wrapper around the NLogLoggerProvider will allow NLog to see these objects types as NLog levels either. Could you please explain how I can achieve either of these mappings so that I can control the logging level within Entity Framework?

NLog LoggingRules depends on the Logger-names and the LogLevel-severity. Ex:
<nlog>
<targets>
       <target name="logconsole" xsi:type="Console" />
</targets>
<rules>
       <logger name="LoggerName*" minlevel="Info" writeTo="logconsole" />
</rules>
</nlog>

Look at the output of the ${logger} to recognize what Logger-names that EF-Core is using, then update the <rules> to match those Logger-names.

NLogLoggerProvider implements ILoggerProvider. If going down the road of creating your own wrapper with implicit LogLevel-filter, then would do like this:
class MyWrapperProvider : ILoggerProvider
{
    public MyLoggerProvider(NLogLoggerProvider wrapped, LogLevel filterLevel)
    {
    }
}

And then override the necessary methods for performing filtering according to the input filterLevel, and when the LogEvents matches the filter, then forward to the wrapped-loggerprovider.

Thank you so much. I have it figured out and I can now log EF message I want when I want. You have been a life save.
David

Closing issue as resolved


Issues to be addressed with NBS format version 6

Overview
Since the transition from MCNBS to ONBS, many updates to the .nbs format have been released. While those updates were necessary to support new features being added to the program, new NBS versions have been, so far, released on an "as necessary" basis, without any specific criteria or public notice prior to the official release.
Ideally, releasing a new version of a widely adopted format should be preceded by public discussions with its users. In the case of the NBS format, these would include plugin developers, as well as anyone creating software based on the format. The release schedule should also include an adaptation period, so developers have enough time to update plugins to comply with the new version.
In practice, this was never the case with the format versions released to this date. This impairs the widespread adoption of the format and causes plugins to be automatically outdated as a new version is released, to the detriment of their users and the NBS ecosystem as a whole.
Starting in NBS version 6, the project should strive to be as clear and transparent as possible about the upcoming changes, as well as take community input into consideration as much as possible. This way, future changes to the format can be bundled up in fewer version updates released as sparingly as possible.
This issue is an attempt to gather all the current issues with the NBS format as of version 5, as well as suggestions for new features that could potentially be included in version 6. Keep in mind this is only an overview of the current issues -- where necessary, more detailed write-ups on each of these issues may be written, including their possible workarounds.
If you're a developer creating something based on the .nbs format and would like to suggest a change, feel free to send it in the comments below!
Current issues

[ ] The 'Layer lock' field, originally intended to be a boolean, may actually assume values 0-2 (0= unlocked, 1=locked, 2=solo). This is currently undocumented in the NBS specification, and is caused by an incorrect variable (one that takes solo into account) being saved to the file.
[ ] Instruments have no property to link them to Minecraft sound events. Currently, what many plugins (and even the built-in data pack export) do is to use the 'Instrument name' property as a sound event. This usage is not documented in the NBS specification.
[ ] As the song tempo is stored in ticks per second, there's not enough granularity to store precise values in beats per minute (BPM). Currently, only multiples of 0.15 BPM are stored properly, so values such as 110 get rounded to 109.95 on song load. (0.01 t/s = 0.15 BPM) (see #306)
[ ] It's not possible to pick which Minecraft version a song is aimed at, so the number of default instruments is always reliant on the Note Block Studio version that the song was saved in. This can be worked around by implementing "Future instruments" (to support opening newer songs in an older version), and allowing the Minecraft save version to be picked per song (unlocking access to 5, 10, or 16 custom instruments).
[ ] The current way strings are encoded can only store ASCII characters. Non-ASCII characters only have the first byte of their UTF-16 representation written to the file, causing mojibake to appear when the song is reloaded. When the byte written to the file lies within the ASCII charset (0x00-0x7F), the equivalent ASCII character is displayed; otherwise, the displayed character is whatever ANSI character Windows maps that codepoint to.
[ ] The binary nature of NBS files causes any change in the file structure to render the file incompatible with existing parsers. As .nbs files were never intended to be versioned, they don't conform to any particular standard, such as JSON or NBT; as such, it's not possible to "know" what's ahead without tightly following the most recent NBS specification. Ideally, a way should exist to "skip" unknown fields so any future .nbs files can be read by existing implementations. It's a technical challenge to make the format future-proof while avoiding major changes to the file structure.
[ ] Formally, there's no restriction put in place to the number of instruments, layers or ticks a song can have. Each version of the program, however, has limits regarding that count (e.g. songs with >200 layers, >18 custom instruments or >32,000 ticks can possibly crash certain versions of NBS). A survey must be made regarding the soft and hard limits of each Note Block Studio version, and, if deemed necessary, these limits should be enforced in the NBS specification.

First of all, I definitely support the idea of the format discussion and I think it may bring some really good things to the .nbs format.

Instruments have no property to link them to Minecraft sound events. Currently, what many plugins (and even the built-in data pack export) do is to use the 'Instrument name' property as a sound event. This usage is not documented in the NBS specification.

This is definitely interresting issue and as far as I remember it is also inconsistently used. NoteBlockAPI use the 'Sound file' property for custom instrument's since there is lower probabilty that it will be in incorrect format (OpenNoteBlockStudio's default custom instrument name is not allowed in Minecraft).

The current way strings are encoded can only store ASCII characters. Non-ASCII characters only have the first byte of their UTF-16 representation written to the file, causing mojibake to appear when the song is reloaded. When the byte written to the file lies within the ASCII charset (0x00-0x7F), the equivalent ASCII character is displayed; otherwise, the displayed character is whatever ANSI character Windows maps that codepoint to.

Most of the songs I came across didn't even have their metadata field filled but I agree that on the specification level this may be a problem. The first obvious idea is to switch to UTF-8 which is completely universal when it comes to letters, symbols and whatever may user enter. However, it's decoding is definitely more complicated than ASCII since it's not only multibyte but also with different count of bytes per symbol. For Java parsers like NoteBlockAPI this shouldn't be a problem.

The binary nature of NBS files causes any change in the file structure to render the file incompatible with existing parsers. As .nbs files were never intended to be versioned, they don't conform to any particular standard, such as JSON or NBT; as such, it's not possible to "know" what's ahead without tightly following the most recent NBS specification. Ideally, a way should exist to "skip" unknown fields so any future .nbs files can be read by existing implementations. It's a technical challenge to make the format future-proof while avoiding major changes to the file structure.

I think that the fact that NBS files are binary is a good thing and I would definitely stick to it because any textual format would make the files a lot bigger. The solution to the issue of future proof implementation also is not as complicated and have been used in many file formats over the years. The NBS file is already splited into blocks (metadata block, note blocks, layer blocks, custom instrument blocks) if you add a length information in bytes to the beginning of each block, you can later add any field you want to the end of the block and properly implemented parsers should simply seek to the end of the block and ignore these new fields.

Formally, there's no restriction put in place to the number of instruments, layers or ticks a song can have. Each version of the program, however, has limits regarding that count (e.g. songs with >200 layers, >18 custom instruments or >32,000 ticks can possibly crash certain versions of NBS). A survey must be made regarding the soft and hard limits of each Note Block Studio version, and, if deemed necessary, these limits should be enforced in the NBS specification.

Actually, this is not really true. There are hard limits in the NBS specification. Since e.g. song's length is signed short in the specification you simply can't have a song longer than 32 767 ticks even if your parser would be able to handle it. And the same holds for every numeric field. I think that especially numbers like song's length (short), instrument's identifier (byte), custom instrument's count and identifier (both byte) should be changed to at least int or short.
From the point of view of the NoteBlockAPI developer, the rest of the issues is not very important for me. Layer lock was ignored  so far because it doesn't make much sense to lock some layer in the exported song (and there is also no reason why would you export song with multiple layers but only want to play only one layer). Since the tempo is stored as ticks per second in file the issue with BPM is also not relevant for me. NoteBlockAPI already supports future instruments so that is also not an issue for me.

The 'Layer lock' field, originally intended to be a boolean, may actually assume values 0-2 (0= unlocked, 1=locked, 2=solo). This is currently undocumented in the NBS specification, and is caused by an incorrect variable (one that takes solo into account) being saved to the file.

I believe this would be a great feature to keep and document, as I and many others mute incomplete sections of the song. The lack of documentation creates inconsistencies between ONBS, NoteBlockAPI, NBS.js, and whatever other .nbs parsers are out there. For example, NBAPI ignores layer lock status as stated above. NBS.js, however, does not.

Instruments have no property to link them to Minecraft sound events. Currently, what many plugins (and even the built-in data pack export) do is to use the 'Instrument name' property as a sound event. This usage is not documented in the NBS specification.

I believe this is up to the library developers and users to deal with. Every implementation of the format would be different either way. NBAPI would have to map to Minecraft's sound events, NBS.js has to load instruments from an ArrayBuffer somehow, etc. The only solution I'd have in mind is to include the instrument files directly in the file, but that'd add an extreme amount of bloat fast. Potentially a way to export the song and its instruments separately from saving the song?

The binary nature of NBS files causes any change in the file structure to render the file incompatible with existing parsers. As .nbs files were never intended to be versioned, they don't conform to any particular standard, such as JSON or NBT; as such, it's not possible to "know" what's ahead without tightly following the most recent NBS specification. Ideally, a way should exist to "skip" unknown fields so any future .nbs files can be read by existing implementations. It's a technical challenge to make the format future-proof while avoiding major changes to the file structure.

Saving with a JSON-like format would be much easier to read, manipulate, and write. However, as @koca2000 said, the file size would explode. While I was working on the playlist feature of NBSPlayer, I attempted to save the loaded songs as their loaded JSON form. The resulting file was megabytes larger than all the loaded .nbs files combined. Keeping the format binary would be the best course of action for the sake of storage.
There's most likely a better way to keep the format future-proof while sticking with the binary format. For example, containing "version" blocks at the end of the file, such as a "v1" block, "v2", and so on. The parser can stop when it's finished reading all the version data it needs, and won't run into issues with any unimplemented versions.

Thank you @koca2000 and @Encode42 for your input! It's great to have different perspectives on the problem.

NoteBlockAPI use the 'Sound file' property for custom instrument's since there is lower probabilty that it will be in incorrect format (OpenNoteBlockStudio's default custom instrument name is not allowed in Minecraft).

For example, NBAPI ignores layer solo and lock status as stated above. NBS.js, however, does not.

This goes to show how important proper standardization is. We've had two different implementations having to come up with workarounds for issues with the format in their own way!

I think that the fact that NBS files are binary is a good thing and I would definitely stick to it because any textual format would make the files a lot bigger.

I can confirm we won't be moving to a different format. Not only the increased file size would be undesirable, but this would mean an added difficulty for plugin makers to maintain two different formats. That being said, JSON could be used in the future for an intermediate format for saving project files (I'll get back to this!)

The first obvious idea is to switch to UTF-8 which is completely universal when it comes to letters, symbols and whatever may user enter.

This is probably the solution we're gonna go with. Though, we must also clearly determine how existing songs have to be interpreted, as for example pynbs crashes when reading a field containing non-ASCII characters due to not specifying an encoding (see vberlier/pynbs#3).

Potentially a way to export the song and its instruments separately from saving the song?
This is planned as a separate file format! See #239.

if you add a length information in bytes to the beginning of each block, you can later add any field you want to the end of the block and properly implemented parsers should simply seek to the end of the block and ignore these new fields.

For example, containing "version" blocks at the end of the file, such as a "v1" block, "v2", and so on.

These are both great ideas, but I'm wondering if they can be implemented in a successful way, given the kinds of changes we might have to make.
For example, if you look at the kinds of fields that have been added over the past few NBS versions, not all of them are simply part of a block, but they are compound fields that appear once for every instance of an element (e.g. layer lock, note block pitch). So to make this work while allowing new fields to be added anywhere -- even in note blocks or layers --, we would probably have to repeat this procedure on multiple levels.
Not only this, but some of the changes could even modify the way some fields are interpreted: see, for example, @Encode42's suggestion:

This could be easily solved by making BPM the primary tempo format.

Considering changes of this nature could be needed even after the future-proof update, no change in the file structure would account for this in a way that would avoid the need for parser updates, unless we marked the existing field as deprecated and re-added it later in the file.
Accounting for all of this would increase the format's complexity in such a way that it makes me wonder whether it's worth to make the format future-proof at all. On the long term it would be a wise idea, but on the other hand, the number of fields we could potentially still add is so small that it possibly doesn't justify such a large structural change.

Layer lock was ignored so far because it doesn't make much sense to lock some layer in the exported song

And this brings me to the third point: NBS files are already kinda saturated with features. Anything we could add further on from this point would probably be irrelevant for NBS players -- as mentioned by @koca2000, features such as layer lock already are.
There are two solutions for this: one is to delay NBS version 6 so we have enough time to think of all features that could potentially cause breaking changes, and add them to the format in that version.
The other, and more ideal, one, would be to split responsibilities: create a new type of file called .nbsproj to hold all data that's relevant to project files (this could be a JSON file since it's much more likely to suffer changes over time), and keep .nbs as a distribution format. This is a long-term goal that would likely only be pursued on the Python rewrite.

So, here are the key takeaways of this:

Some of these issues are complex and require further discussion so we can come up with an ideal solution, raising the need for separate tickets to be opened.
After these changes are completed, it would be wise to mark NBS files as feature-complete, and this would avoid the need for further changes.
Any further changes, if necessary, should belong in a new format that will solve the issue of needing an NBS format change for every tiny feature added to the program. Then, the way the program interprets those features may change, but the way it's written on NBS files will always be the same.
Since we can't change files that are already saved and support for them must be kept, these caveats resulting from the current issues could go in a new section of the NBS spec page, "Issues", mentioning all current issues and the suggested way(s) of fixing them.

NB: in the past, I've done a detailed write-up on both character encoding and layer lock, but on both occasions I've lost them as due to typing directly on the GitHub form. :(


openhcl: Track outstanding servicing state mesh ids that are not finalized

          I'm not sure we have anything in particular. I think we need to be vigilant/add it to our release checklist though.

Or perhaps we should take the stance that these must have corresponding GH issues in the comment?
Originally posted by @chris-oo in https://github.com/microsoft/openvmm/pull/450#discussion_r1881145924

We don't yet have policy for this, so lets use this issue to decide what we want to do. For now, this tracks the 3 outstanding that we have.


Audit static site links

Description
There are several links on the static site that lead to outdated resources or pages. This ticket will serve as a place to collect those links.
Additionally, when deleting pages from the static site, we need to redirect them as well. The static site persists pages even after they've been deleted, so it's important to update their links either to the new version or the 404 page.

#2335

@emmastephenson can we do a global redirect for all resources links that have /resources and those that don't? I forget which is the old vs. new, but one is an old URL format. One example:

https://simplereport.gov/using-simplereport/manage-users/manage-user-permissions/

https://simplereport.gov/resources/using-simplereport/manage-users/manage-user-permissions/

@emmastephenson can we do a global redirect for all resources links that have /resources and those that don't? I forget which is the old vs. new, but one is an old URL format. One example:

https://simplereport.gov/using-simplereport/manage-users/manage-user-permissions/
https://simplereport.gov/resources/using-simplereport/manage-users/manage-user-permissions/

I think the /resources is the old format, we should be able to redirect those links to the new version!

@LGFranklin since we're only sending this out via email now and this is not the updated PDF, can we delete this URL from search?
https://simplereport.gov/assets/resources/Bulk_person_upload_guide.pdf

I was actually thinking that we should just update the link. It’s a bit easier for support to send as a link to users v attaching every single time
Sent from my iPhone

On Sep 2, 2021, at 7:33 AM, Rebecca-LM @.***> wrote:

@LGFranklin since we're only sending this out via email now and this is not the updated PDF, can we delete this URL from search?
https://simplereport.gov/assets/resources/Bulk_person_upload_guide.pdf
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

In that case @emmastephenson please replace with this updated PDF SimpleReport bulk upload guide.pdf

https://skylight-hq.slack.com/archives/C019PRYMR0Q/p1630691263069800

@Rebecca-LM will clean this up so the list is more obvious/ easier to find

#4 is complete
#3 finished for one page, not sure if all are done


Move to Java 11

Description
As keycloak itself is now on java 11 it would be nice to pin this project also to java 11+ so build environments can drop java8 for the keycloak environment.
If you agree I will provide a PR
Discussion
No response
Motivation
No response
Details
No response

@bs-matil Please. I hope we don't have issues with scala/gatling.

@pedroigor I will give it a try


k8s: add ingress metadata fields

Test by running the below and checking the UI:
kubectl create -f tests/k8s/ingress.yaml

run skydive-scale-tests


Teamwork

Hi @UBC-STAT/stat545 TA's! I've put together a proposed teamwork document -- a document describing how we will work as a team.
Can we undergo a review process for this document via this pull request? So, please comment and propose changes as you see fit. The idea is to set up a working environment that makes everyone feel empowered to be part of the team, and that's why I'd like your input -- I doubt I've covered everything or written everything in a way that's agreeable to everyone.
Once we get this document to a state where everyone approves, I'll go ahead and merge this PR -- but, in reality, this is a living document that should evolve as we figure out better ways of working together.

Just added the point on google calendar -- not sure if this is ideal for everyone, though.

Needs level of authority for Week guidance specification

Add that the person who previously did a task will be the reviewer for the next week (with each category)
Week guidance will be reviewed by the person delivering the lecture (probably Vincenzo)


User has many identities

Hi,
Is it possible to consider the option that a user has more accounts associated? For example, that can log in with his Facebook, Google or Apple account. There would have to be an extra table that has provider, uid, and user_id.
What do you think? Thanks!

Hum… It is reasonable, I can implement it some day…
1 - User
2 - Account - User
3 - Account - Identity - User

I think this would really be a nice addition. When multiple providers are currently use, it can lead to issues because while the provider/uuid is unique, the email is already in use. Also, I think is a rather common scenario to add multiple providers (and users forgetting which one they used).
I think it would be a good solution to add an extra model as suggested. I took the liberty to fork the repo and made an example on how this could work here: https://github.com/reinventit/authentication-zero
Would be happy to contribute to the project and work on a PR.

Hum… It is reasonable, I can implement it some day, but I need create a test infrastructure first 1 - User 2 - Account - User 3 - Account - Identity - User

@lazaronixon I don't know if using Account is what we really want. In Basecamp, for example, Account represents an account that can have many people (Person). Each person has a personable_type that can be User. This User is the one that could have many identities, so that it can log in with Apple or Google, for example. The user is the one who is authenticated, not the account. What do you think?

@brunoprietog I agree 100%. While we all know naming is the hardest part... In the fork I have used a 1-to-many to a table named 'authorizations' that contain the provider/uuid combinations.

So... this would be the second situation that I've proposed... Account - User....
1 - User
2 - Account - User
3 - Account - Identity - User

@reinventit I like that modeling, although personally I think identities makes more sense to the name of that extra table. Authorizations I feel is a concept related to the actions a user is authorized to do, such as read/write permissions.

It could be something simpler like:
class User < ApplicationRecord
  has_many :identities
end

class Identity < ApplicationRecord
  belongs_to :user
  # id, provider, uid, user_id
end

Yeah, maybe... let's see after rails 7.1, there are some features I want to add, then we can work on that.

As mentioned in the inviting users issue, I'd be happy to share how I accomplished this. Particularly since these two concepts are so tightly related.

@reinventit I understood what you said, it is about the OAuth option. 🤦♂ Yes, please... I would like to have multiple providers.

Just for reference how to implement multiple providers
https://github.com/omniauth/omniauth/wiki/managing-multiple-providers


Feature: Component based translation tables

This ability/feature might already exist but I've done some googling and seen stuff about "asynchronous loading" as well as partialLoader but I'd figure since I couldn't find someone with the same sort of problem I'm having (or figure out how to solve it myself), I figured I'd create an issue:
I'm working on a project with a typical component structure:
app
-- components
---- header
------ header.jade
------ header.js
---- footer
------ footer.jade
------ footer.js

The typical pattern for locale files is to put a single language file with all of the translations in there. For example, this is a typical en.json file:
app/locals/en.json
header: {
  title: 'My app'
},
footer: {
  someLink: 'Some link text'
}

This pattern above though doesn't really follow suit with a component/module organization based approach like I showed I'm doing above.
I'd love to either have the translations in my controller file (header.js/footer.js):
header.js
class HeaderController {
    constructor() {
        // somehow attach my translations in here by extending/merging the existing translations table
    }
}

angular.module('Header', [])
    .controller('HeaderCtrl', HeaderController);

Or as an external file next to the the rest of the component files, such as:
app
-- components
---- header
------ header.jade
------ header.js
------ header.json // this would contain the translations
---- footer
------ footer.jade
------ footer.js
------ footer.json // this would contain the translations

and then header.js would load in the file. Any help would be greatly appreciated, thanks!

I'm quite not sure why this idea would not fit with the partial loader.

@knalli could you explain how you'd use the partial loader here?

Given your last example, a possible partial name would be components.header.header.

I'm also having problems figuring out how to use the partial loader with this kind of app structure too :disappointed:
How do I insert more content into the same language when a new component is loaded?
The main goal is to be able to copy the hole component folder into another project, and all the translations specific/default to that component just goes with it. Without the need to copy a separate file or copy/paste the keys into a main translation file.
ty

@shinrox  This is a nice idea, but it requires two things

you have defined such a structure and organize all contents fitting this (components, language texts, ...)
you have such a component texts loader which is following your self made structure

And again: If you have defined such a layout, you can try to use the built-in partial loader.
$translateProvider.useLoader('$translatePartialLoader', {
  urlTemplate: '/app/components/{part}/{}part.{lang}.json'
});

Unless the built-in is okay, you can make your own loader.

@knalli hmmm, what if my languages are angular constants and not json files?
This is the structure that I use, and everything is bundled together with gulp, and again I can import the modules on different projects
# app.coffee
angular.module('myModule.constants', [])
angular.module('myModule.services', []) #etc...

# load everything to one module
angular.module('myModule.scripts', [
  'myModule.constants' #etc...
  'pascalprecht.translate'
])

# main module depends on the 'module aggregator'
app.module('myModule', [
  'myModule.scripts'
])

I use this structure cause I think it's easier to test separate parts and stuffs :stuck_out_tongue_winking_eye:
Anyway, I want to define my module languages like this
# constants.coffee
angular.module('myModule.constants')
.constant 'myModule_enUS', {
  en_US : {
    MYMODULE:
      TITLE: 'My title'
      TEXT: 'My text'
  }
}

angular.module('myModule.constants')
.constant 'myModule_ptBR', {
  pt_BR : {
    MYMODULE:
      TITLE: 'Meu título'
      TEXT: 'Meu texto'
  }
}

How can I add those parts to the translate service, so I can use it like this without worrying about the module languages in every project?

{{'MYMODULE.TITLE' | translate}}

{{'MYMODULE.TEXT' | translate}}

I did it like this, but I'm not quite sure if it's the best way or even the correct one
# separate file to hold all keys and load on config
angular.module 'HolmesScanAssistant.constants'
.constant 'translations', {}

# factory to reload based on the translations constant above
angular.module 'myModule.factories'
.factory 'i18nLoader', ($q, translations)->
  loader = (options)->
    deferred = $q.defer()

    if translations[options.key]?
      deferred.resolve(translations[options.key])
    else
      deferred.reject('no translations found')

    return deferred.promise

  return loader

# service that add new keys to the constant based on others

angular.module 'HolmesScanAssistant.services'
.service 'i18nService', ($translate, translations)->

  service =
    addTranslation: (lang, values)->
      if !translations[lang]? # if first time adding language
        translations[lang] = {}

      angular.merge translations[lang], values

      $translate.refresh()

  return service

# controller
angular.module 'myModule.controllers'
.controller 'Ctrl', (i18nService, myModule_enUS, myModule_ptBR, $language)->
  # just to illustrate the use but I'm adding keys depending on language ...

  i18nService.addLanguage('pt_BR', myModule_ptBR)
  i18nService.addLanguage('en_US', myModule_enUS)

# app config
angular.module 'myModule'
  .config [ '$translateProvider', ($translateProvider) ->

    $translateProvider.useLoader('i18nLoader', {})
    $translateProvider.useMissingTranslationHandlerLog()
    $translateProvider.useSanitizeValueStrategy('escaped')
    $translateProvider.preferredLanguage('pt_BR')

  ]

Sorry about the long post, but I hope I could illustrate what I'm trying to do :P
ty

I was able to figure out how to achieve what I wanted to do (component-based locale files) via $translatePartialLoader
$translateProvider.useLoader('$translatePartialLoader', {
    urlTemplate: '{part}/locale-{lang}.json'
});

with this kind of folder structure
app
-- components
---- header
------ header.jade
------ header.js
------ locale-en.json
------ locale-es.json
------ locale-de.json
------ locale-jp.json

Ok by me.
But my question continues about the constant mode that I've posted.

What is your question? Of course you can build an own custom loader which is not actually loading but using something else (i.e. constants). It's up to you.

My question was if my approach is ok, or if there's any other better way of doing with constants. =)

Well, I'm not sure. I'd not make such things, pushing such stuff into the AJS context.
If someone comes up with a nice idea of doing this...


Missing package.json in language server implementation

Facing issues in setting up the language server implementation on OS X. Following the steps mentioned in the CONTRIBUTING.md guide here.
On executing dotnet build, I am getting the following error:
Couldn't find 'project.json' in current directory

Is there something I am missing?
EDIT : executing this from python-language-server/src/LanguageServer/Impl

You need to build solution, so dotnet build from python-language-server/src.

@MikhailArkhipov , thanks for your reply, but there isn't a package.json file in python-langugage-server/src either, and hence, dotnet build, as you'd expect, doesn't work.

dotnet build recognizes VS solutions.

Usually we build from VS during development. Automated pipeline does dotnet publish src/LanguageServer/Impl/Microsoft.Python.LanguageServer.csproj

Tried on Mac, result is identical

Figured it out, thanks for your help @MikhailArkhipov !


Add option to print yaml logs to Stdout

Problem
Multiversion linting error logs need to be parsed and are currently printed to stdout in a human readable format
Solution
Update the writeLintReport function to print YAML to stdout if given a '-' as a file path
Update the completeEither function to take an optional 'silence' parameter to silence human readable logs when printing the YAML to stdout

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Crash running on Dedicated Server but not client. Version 1.10

Hello, love the mod, but i have a strange issue with a error on the server side, the mod loads fine if it's on a client but otherwise crashes. I've attached the log file.
error_log.txt

Please provide the fml-server-latest.log.

You can grab the new version fixing this bug here:
http://minecraft.curseforge.com/projects/turret-mod-rebirth/files/2311009


toforeground method not working in ios

Hello Team,
I am using toforeground method in ios but it is not working, I am not able to get the classname & package name in ios.
Here is my code:
toForeground("MainActivity", "com.ionicframework.crosswalkdriver917525", function(data) {
        console.error('Success Foreground', data);
      }, function(e){
        console.error('Error Foreground', e);
});

It is working perfectly in android but not in ios.
Thanks in advance.

This plugin doesn't have any of the code necessary to work in iOS. You would essentially need to duplicate the functionality in src/ToForeground.java but for iOS platforms.