qt: Redesign BitcoinAmountField

This PR ist part of a series of +-25 PRs related to UI redesigns. Its ancestor is #3568, its successor is  #3570. I did not screenshot every single PR and its changes, instead i made "walk through all screen" videos with the result of this PR series and also with the 0.15 UI. If there are any concrete screenshots wanted, just let me know. To build with the full set of changes you can build from the branch xdustinface:pr-ui-redesign which always contains all changes.
 -> Walk through 0.15
 -> Walk through Redesign
I tried to give the commits enough text to make things obvious without a lot description for each PR. Also here, if you want more description for this specific PR, let me know.
About this PR
This PR gives the BitcoinAmountField a redesign. It removes the spinbox and the unit selector. Result is just a line edit with the same validation and background functionality. Its still possible to change the input unit by changing the global unit selector to the desired unit.

Ready for review!


nodejs-webhook: Error

Hi,
I'm trying to run webhook sample through ngrok tunnel.  After loging into the microsoft online the app connects to sample app registered but when returns back to localhost, I'm seeing a unexpected token..."SyntaxError: Unexpected token" as shown below.
Express server listening on port 3000
GET / 304 8.723 ms - -
GET /css/fabric.min.css 304 2.541 ms - -
GET /css/fabric.components.min.css 304 1.857 ms - -
GET /signin 302 15.009 ms - 394
POST /listen?validationToken=ZTc4MGRjNDgtM2M3NC00YWRmLWE4YTQtNjFlNzk0MTVkMTVj 200 11.700 ms - 48
undefined:1
{
^
SyntaxError: Unexpected token
at Object.parse (native)
at IncomingMessage. (/Users/girishkb/O365/nodejs_webhooks/nodejs-webhooks-rest-sample/helpers/requestHelper.js:36:23)
at emitNone (events.js:72:20)
at IncomingMessage.emit (events.js:166:7)
at endReadableNT (_stream_readable.js:921:12)
at nextTickCallbackWith2Args (node.js:442:9)
at process._tickCallback (node.js:356:17)
npm ERR! Darwin 13.2.0
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "start"
npm ERR! node v4.6.0
npm ERR! npm  v2.15.9
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>start: mocha ./tests/confTest.js && node ./bin/www
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script 'mocha ./tests/confTest.js && node ./bin/www'.
npm ERR! This is most likely a problem with the o365-nodejs-webhook package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     mocha ./tests/confTest.js && node ./bin/www
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs o365-nodejs-webhook
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!
npm ERR!     npm owner ls o365-nodejs-webhook
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /Users/girishkb/O365/nodejs_webhooks/nodejs-webhooks-rest-sample/npm-debug.log
Any idea as to why this unexpected error is thrown ?
Regards,
Girish BK

Hi @girishkumarbk
That line should process the error response. It looks like the error is not returned in JSON format. Unfortunately, I can't repro the error. I tried with node v4.6.0 but no luck.
Would you mind adding the following line right before line 36 in helpers/requestHelper.js to inspect the error data?
console.log(subscriptionData);

This should give us more information.

Hi Recardo,
After putting console log ... this is what is logged on screen as below.
Any idea where am I going wrong ?
Thank You,
/Girish BK
Express server listening on port 3000
GET / 304 4.948 ms - -
GET /css/fabric.min.css 304 1.841 ms - -
GET /css/fabric.components.min.css 304 0.526 ms - -
GET /signin 302 7.019 ms - 394
POST /listen?validationToken=OGIwM2M3OGEtMTYwMC00NTJjLWFmOTQtNzc1OTkyODQwN2Zm 200 2.422 ms - 48
{
"error": {
"code": "ExtensionError",
"message": "An error occurred when creating an entity. Exception: Server Error. Status Code: NotFound, Reason: Not Found",
"innerError": {
"request-id": "7f60ca13-3177-4105-8831-498cbef7d4f8",
"date": "2016-10-19T15:04:15"
}
}
}
undefined:1
{
^
SyntaxError: Unexpected token
at Object.parse (native)
at IncomingMessage. (/Users/girishkb/O365/nodejs_webhooks/nodejs-webhooks-rest-sample/helpers/requestHelper.js:37:23)
at emitNone (events.js:72:20)
at IncomingMessage.emit (events.js:166:7)
at endReadableNT (_stream_readable.js:921:12)
at nextTickCallbackWith2Args (node.js:442:9)
at process._tickCallback (node.js:356:17)
npm ERR! Darwin 13.2.0
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "start"
npm ERR! node v4.6.0
npm ERR! npm  v2.15.9
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>start: mocha ./tests/confTest.js && node ./bin/www
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script 'mocha ./tests/confTest.js && node ./bin/www'.
npm ERR! This is most likely a problem with the o365-nodejs-webhook package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     mocha ./tests/confTest.js && node ./bin/www
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs o365-nodejs-webhook
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!
npm ERR!     npm owner ls o365-nodejs-webhook
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /Users/girishkb/O365/nodejs_webhooks/nodejs-webhooks-rest-sample/npm-debug.log

Mmm looks like an error in the service when the sample is trying to create the subscription. Can you confirm that your app registration has the Send mail as a user delegated permission?
Also, could you send an email to the account you're using and verify that the message is in the account's inbox?

It looks like you are right!  Actually, I don't have outlook app in my account :)  I'll rerun the app after installing applications on my account.  Will revert back soon if I get through this error...
Thanks

You probably should follow the principle of least privilege. Your app should only request and access the resources required to do its work.
However, there might be scenarios where the app should access resources even without user consent and that's one of the reasons why admin consent exists.
You should carefully review what permissions your app needs. I'm afraid I can't just say stick to user consent because your app might have a legitimate reason to request for admin consent.
Not very helpful, I know, but this is one of those topics that don't have an easy answer.


Revert "Moved "parallel" feature gate outside of cfg_iter_*"

Reverts arkworks-rs/utils#16
See https://github.com/arkworks-rs/utils/pull/16#issuecomment-756571960
cc @rozbb

the issue is that the import is only within the scope of the macro, so something like this doesn't work:
	cfg_iter!(a).zip(b)....

Because you need the rayon traits imported for the zip call to work

the issue is that the import is only within the scope of the macro, so something like this doesn't work:
	cfg_iter!(a).zip(b)....

Because you need the rayon traits imported for the zip call to work

I see, that makes sense

I see, that makes sense


Implement correct error handling in native runtime code [ECR-4054]

Overview

runtime::error::Error enum is slightly changed. OtherJniError renamed to JniError, IncorrectArtifactId replaced with IllegalArgument.
New helper function get_exception_cause to call Throwable#getCause
New exception handlers in runtime module: ILLEGAL_ARGUMENT for IllegalArgumentException and TX_UNEXPECTED for UnexpectedTransactionExecutionException.
New method jni_call_transaction to be used in execute, before_transactions and after_transactions methods.
jni_call_default handles IllegalArgumentException additionally.

See: https://jira.bf.local/browse/ECR-4054
Definition of Done

[x] There are no TODOs left in the code
[ ] Change is covered by automated tests
[x] The coding guidelines are followed
[x] Public API has Javadoc
[x] Method preconditions are checked and documented in the Javadoc of the method
[x] Changelog is updated if needed (in case of notable or breaking changes)
[ ] The continuous integration build passes

Coverage remained the same at 86.32% when pulling 9daa9629d1abffeee394ab773fc3e4c0cdf08caa on vitvakatu:ecr-4054-error-handling into 56f0fce54b99f994b90aeeef93e20a4a658fad92 on exonum:master.

To reviewers: methods from proxy/runtime module are moved to runtime/error module without any semantic changes.

It is still unclear what happens with errors in 'initialize' (we have an incorrect documentation stating it is saved in call errors, but there is no corresponding CallInBlock variant): https://jira.bf.local/browse/ECR-4098


System module

Implement System module
From the Substrate docs:

The System module provides low-level access to core types and cross-cutting utilities. It acts as the base layer for other pallets to interact with the Substrate framework components.

System module exposes similar functions to that of Executive module:

Initialization
Prepares the necessary environment for the block initialization. Receives header as an argument and sets following temporary values into the storage: ExecutionPhase, extrinsic_index, block_number, extrinsics_root, block_hash, parent_hash, digest.

Finalization
Removes some values from the storage, such as ExecutionPhase, extrinsicsCount, etc. Moves the block hash pruning and performs other necessary finalization steps.

Phase
Enum that is used by the ExecutionPhase. Has three values: ApplyExtrinsic, Finalization, Initialization.

Other methods
extrinsic_index, extrinsic_count, etc.

For more details about the module, please refer to the Rust implementation of the System module.

[x] Initialization
[x] Finalization
[x] Phase
[ ] Other methods


ima: Use seek() to get to the last known last entry

Use seek() to get to the last known last entry in the IMA measurement
list. Track the size of the IMA measurement list two last known number
of entries in a singleton class that helps us seek to the last entry
and return the tail of the measurement list at the n-th entry as re-
quested by the caller.
We have to remember the last two known number of entries and file sizes
since the validator may not get a quote containing the last entry but
that of the previous last entry and will on the next attestation request
again ask for the same entry.
Signed-off-by: Stefan Berger<EMAIL_ADDRESS>

The reasons given in #769 drove the changes to this PR after some more testing. The 'key' in testing was to trigger the situation where the IMA log has n entries but the TPM hasn't been extended with the n-th entry yes, so only has n-1 PCR extensions. In this case the verifier will ask for the (n-1)-th entry again and we need to know the offset in the IMA measurement log where that was, so need to remember that offset along the n-th entry's offset.


ROX-17683: Enable telemetry by default in roxctl

Description
A detailed explanation of the changes in your PR.
Feel free to remove this section if it is overkill for your PR, and the title of your PR is sufficiently descriptive.
Checklist

[ ] Investigated and inspected CI test results
[ ] Unit test and regression tests added
[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.
Testing Performed
TODO(replace-me)
Use this space to explain how you tested your PR, or, if you didn't test it, why
you did not do so. Valid reasons include, for example, "CI is sufficient",
"No testable changes". Feel free to attach JSON snippets, curl commands,
screenshots.
In addition to reviewing your code, reviewers must also review your testing
instructions and make sure they are sufficient.

Current dependencies on/for this PR:

master

PR #6420

PR #6453   👈

This comment was auto-generated by Graphite.


Transform Class with Templated Spaces - RFC

Having submitted the PRs which removed the old Transform utility classes, I may have come full circle.
This Transform class won't compile if you try to use incompatible spaces.
This is just an idea. I think it could be worth pursuing, but I am keen to see what people think.
Another benefit is that we get to keep the concise variable names, without losing ambiguity as to what a letter means - for example, f can be foot or field, but it's clear using this system.
One thing I am considering is (and this does sound ghastly, but hear me out), instead of using an enum for the spaces, making a namespace called space, then defining constexpr ints, one for each space. This feels a bit dirty, but the benefit is that you can do
using utility::math::space::TORSO;
// instead of:
using utility::math::Space;

for the current enum setup.
The difference is that when you use the enum values, you always have to prepend Space, making it like
auto Htc = Transform<double, Space::TORSO, Space::CAMERA>(); // TORSO, CAMERA are enum values from the Space enum
// instead of (using ints):
auto Htc = Transform<double, TORSO, CAMERA>(); // TORSO, CAMERA are defined as ints

If we did opt to keep using the enum, I would make it into a smart enum :tm: too.

How do we feel about people not using Eigen normally in terms of learning how to use Eigen bc it's a popular library?

Can we use https://en.cppreference.com/w/cpp/language/enum#Scoped_enumerations instead of constexpr ints?

Can we use https://en.cppreference.com/w/cpp/language/enum#Scoped_enumerations instead of constexpr ints?

If you can use using declarations on those values, for sure. Otherwise, there'd be no point

@TrentHouliston has raised an interesting alternative - we could enforce that transforms have compatible spaces with a clang-tidy check. Basically just a regex rule which says that the letters have to match up. This gets around potential concerns of having a mega-size Space enum, whilst still enforcing correctness (down to the correctness of the letters, which can be incorrect or ambiguous themselves).
Benefits:

No mega Space enum
Zero friction from having to add an extra field if you want to add a space. (IMO this isn't an issue, because I personally don't think that there are that many spaces that we use. For cases like Htx, which is a list of transforms each with different spaces, we could use Space::OTHER, or some other solution)

Downsides:

Overloaded letters like f aren't covered and they could introduce bugs the proposed transform class would catch
It has to wait on clang-tidy being a thing we regularly use (this isn't so much a downside as a "we can't do this until that roadblock is removed")
We don't get the added benefits of the proposed Transform class disambiguating what a given letter means (again, not necessarily a downside, because this is something that should be addressed properly in documentation)\

@TrentHouliston, does that steelman your point sufficiently? Anything to add?

@Bidski @TheCoolKidsTable @CMurtagh-LGTM @ysims I am keen to hear if you think this is actually a good idea. Is this something you think we should do? Do you prefer the clang-tidy check?

How do we feel about people not using Eigen normally in terms of learning how to use Eigen bc it's a popular library?

I am ambivalent about this. A plus of this is that it could insulate us if Eigen's interface updates or we stop using Eigen (both seem unlikely right now of course). A minus is that Eigen is "worth"
learning if people want to do more stuff in their career outside NUbots though. That doesn't seem like it's a concern rivaling potential bugs caught by a Transform class like this though, IMO.

I dont see a reason not to use an enum to be honest. You arr basically trying to use one without explicitly using one anyway

I think that having a Transform class is more explicit and that the clang-tidy check may confuse people.

I dont see a reason not to use an enum to be honest. You arr basically trying to use one without explicitly using one anyway

It would strictly be for more concise usage. Space::TORSO is simply more verbose than TORSO. The cost is just a slightly dirty list of constants and extra using declarations

I dont see a reason not to use an enum to be honest. You arr basically trying to use one without explicitly using one anyway

It would strictly be for more concise usage. Space::TORSO is simply more verbose than TORSO. The cost is just a slightly dirty list of constants and extra using declarations

Enums put their members into the parent scope. Wrap that in a namespace and you have the same effect as your constexprs

How do we feel about people not using Eigen normally in terms of learning how to use Eigen bc it's a popular library?

I am ambivalent about this. A plus of this is that it could insulate us if Eigen's interface updates or we stop using Eigen (both seem unlikely right now of course). A minus is that Eigen is "worth"
learning if people want to do more stuff in their career outside NUbots though. That doesn't seem like it's a concern rivaling potential bugs caught by a Transform class like this though, IMO.

As a reminder of how widely used eigen is industry. The people who made armadillo (csiro/data61) use eigen

Code that makes sense without documentation sounds better to me. The Transform class has high readability imo, which is part of the point? I dunno, I'm kind of leaning towards Transform class. The learning thing isn't a big deal if it makes our systems easier to use (there's already plenty other stuff for peeps to learn lol).

I dont see a reason not to use an enum to be honest. You arr basically trying to use one without explicitly using one anyway

It would strictly be for more concise usage. Space::TORSO is simply more verbose than TORSO. The cost is just a slightly dirty list of constants and extra using declarations

Enums put their members into the parent scope. Wrap that in a namespace and you have the same effect as your constexprs

You can't do using declarations for enum members though. You have to qualify them

I dont see a reason not to use an enum to be honest. You arr basically trying to use one without explicitly using one anyway

It would strictly be for more concise usage. Space::TORSO is simply more verbose than TORSO. The cost is just a slightly dirty list of constants and extra using declarations

Enums put their members into the parent scope. Wrap that in a namespace and you have the same effect as your constexprs

You can't do using declarations for enum members though. You have to qualify them

You using the surrounding namespace which gives you access to the symbols that are in that namespace which includes the enum amd its members

I'm not a big fan of the Transform class idea for a number of reasons.
I think it's going to add maintenance overhead and not really pay for itself.
So often we have new spaces that we need to define, and they're not always fixed.
For example @ysims we would have a space for the swing foot and the support foot. Also one for the left foot, right foot. Ground space, torso space etc.
Then you end up with other intermediate spaces like observation space in the visual mesh.
Every module that is written could end up adding new spaces to this giant list. And since the enums aren't local to the file I can guarantee that this file will grow without bound and cause more confusion.
Basically, you'll have a god file with hundreds of spaces which won't help people code and look up what space they're using, it'll just make things more confusing. Now instead of having to just look at one file, I have to look at multiple files.
A very important concept in code is to keep the definitions and meanings of what you're doing as close to the code it's relevant to as possible. In the case of the spaces, define them in the module that you're writing, the only spaces that have meaning across multiple files are the ones in the messages, which should be documented well because they're messages!
I also don't like that you'll constantly be having to "break the rules" when you try to assign the "left foot space" to a "swing foot space". With a clang-tidy rule that's a warning, you can silence to say "I know what I'm doing". With a Transform class, it's a compile error that you have to deal with any time you want to do spaces, and therefore it will be more code you have to write every time you want to do something, it will make it much harder to rapidly prototype since you'll need casts everywhere. You can't just do the whole, I'll write this quickly and fix the warnings when I'm done.
And if you solve this by having an "Other" space you're falling into the classic trap of software engineering. You cannot make code better by making exceptions, if it's too hard people will just use Other for everything because it's too hard to work out the spaces. Or you'll end up with problems because people will use Other for two separate spaces and think they can use them just fine. With a clang-tidy warning you can leave the warnings for the end. With Other hacks you might miss them in review and they'll end up in the codebase.
The way I see it there are two problems that need to be solved here.

We need to make sure that people are doing the math according to the rules on the math page
People need to know what each letter represents in terms of spaces

I think 1 should be solved using a clang-tidy rule that enforces our math rules based on the variable names. Once you write some code that takes the variable names and understands them, it's fairly straightforward to work out what operations would convert them to and make sure they're correct.
I think 2 is a documentation problem, which you are trying to solve by having a god file with all the spaces documented there as code enums.
I personally think that approach is worse than just having a NUbook page or just a comment at the top of a module saying what each letter represents. You're taking local information to a module and pushing it out to a global spaces file.

Thanks for C++20 magic, I have made it so that the Spaces are literal strings. This way they are completely local to the class, while still retaining the expressiveness of the enum approach. I think this mostly addresses the issues @TrentHouliston had, but I am keen for more feedback.

I'm still not really a fan of this. While I agree that something like this is probably needed, I don't think this is actually going to solve the problem. I also don't think you have really addressed all of the issues that @TrentHouliston has raised.
Using the string literals isn't all that much more expressive than using a single character and doesn't resolve the issue of space aliasing (not that I think there is going to be a clean solution to this). So we will still have to have explicit casts in any place that we are doing this. I think it also needs to be remembered that embedding the spaces into template-space is going to create a lot of icky template compiler errors.
While I think Trent's idea of a clang-tidy regex-based check would resolve this issue better, I am not convinced that we could craft a regular expression that is expressive enough to properly meet our usage requirements. On top of this, if you only make such a check  a warning then people will likely ignore it as it is only a warning. If you make it an error then I am worried that people will just // NOLINTNEXTLINE everything for exactly the same reasons that people would just use Space::Other everywhere.
We also need to remember that unless me move to clang as our main compiler the only ways people will be able to see that they have got the naming wrong is by either explicitly running clang-tidy via cmake (needing a complete rebuild using clang/clang-tidy) or by pushing their changes and making a (draft) PR and waiting for the CI checks to complete. Both of these options are annoying and painful, and if they are developing in one of the NUC docker images then they can't actually run clang-tidy until they swap to the generic image.
Ultimately, I think more thorough documentation, both about the common spaces we use and how our mathematical notation is used, is the only thing that will "resolve" this issue.

Using the string literals isn't all that much more expressive than using a single character and doesn't resolve the issue of space aliasing (not that I think there is going to be a clean solution to this). So we will still have to have explicit casts in any place that we are doing this. I think it also needs to be remembered that embedding the spaces into template-space is going to create a lot of icky template compiler errors.

I agree template compiler errors are annoying, however I personally would prefer a compiler error when you do an incompatible multiplication than no error at all.
In terms of the concern of casting in places where we have more dynamic spaces like the swing-foot case, I would argue that the current solution is as bad or worse, in those limited cases. The letters have to change (or the letters suffer from the exact same issue of casting/reassignment) when you change from left-foot to swing-foot anyway. I don't understand how having it templated changes this.

While I think Trent's idea of a clang-tidy regex-based check would resolve this issue better, I am not convinced that we could craft a regular expression that is expressive enough to properly meet our usage requirements. On top of this, if you only make such a check a warning then people will likely ignore it as it is only a warning. If you make it an error then I am worried that people will just // NOLINTNEXTLINE everything for exactly the same reasons that people would just use Space::Other everywhere.

I think the clang-tidy check is a great idea too. I think it would sit on top of this solution quite well - we don't have to have an exclusive-or choice between the two. The naming convention of Hab transforms is retained with this solution and the clang-tidy solution is valid whether we add this or not.
In terms of people just ignoring the check: that's what code review is for. Once we fix all of the clang-tidy warnings existing in the codebase, we'll turn clang-tidy on in the CI (along with -Werror, soon^TM), which means that people will be forced to use // NOLINT if they want to do naughty things, which is super easy for reviewers to catch. I don't think this will be an issue once clang-tidy and -Werror are on for CI builds.

We also need to remember that unless we move to clang as our main compiler the only ways people will be able to see that they have got the naming wrong is by either explicitly running clang-tidy via cmake (needing a complete rebuild using clang/clang-tidy) or by pushing their changes and making a (draft) PR and waiting for the CI checks to complete. Both of these options are annoying and painful, and if they are developing in one of the NUC docker images then they can't actually run clang-tidy until they swap to the generic image.

People should be running clang-tidy before they merge things. They can turn on CI_BUILD in configuration and get a build which perfectly matches the CI build - that's the benefit of that CMake variable. Yes, it's annoying! I completely agree. But, it's way way better if we go through that effort to catch potential bugs before they get merged and are in the codebase for 10 years.

Ultimately, I think more thorough documentation, both about the common spaces we use and how our mathematical notation is used, is the only thing that will "resolve" this issue.

100% with you on documentation. It should certainly be improved. I am thinking a NUbook section with the list of spaces and their corresponding letters is necessary, so people can do a look-up of a letter if they're not sure.
One benefit of this class is that it gives a direct indication of what the Transform objects are. It's self-documenting in multiple ways - it clearly states the spaces involved, giving an intuitive look at the mechanics of the naming scheme (the naming scheme makes a lot more sense with a bit more context, which this provides, right at the location of the code), and it clearly indicates what the transform is - Transform<double, "Camera", "Torso"> is much more helpful that the typename Eigen::Affine3d.
At the end of the day, all of your points are valid. Template errors are annoying (the static_assert for the * operator does provide a helpful error though - if I do say so myself - and that's where nearly all of the template errors will come from). The hypothetical clang-tidy check will prevent bugs, even if clang-tidy requires extra builds. Documentation should be improved.
I don't think any of those really outweigh the immediate benefits that this construction could give us though: no incorrect space manipulations (huge!!), and clear, self-documenting space assignment, as well as providing insight into the naming scheme.
IMO, those factors combined outweigh the issue of a potentially having a few extra casts in a couple of spots in the codebase, and potentially having verbose compiler errors (which also prevent you from making mistakes). I started lukewarm on this, but now I am more and more keen the more I think about it. If you @Bidski and @TrentHouliston both think that this isn't worth it, I'll close the PR, but I really think this could help us.

I'll convert a couple of reactors on a branch off this one, and we can see if it seems good when we use it. I will do it for sensorfilter and the Quinticwalk

I agree template compiler errors are annoying, however I personally would prefer a compiler error when you do an incompatible multiplication than no error at all.

Compiler errors are good until they are unreadable. I'm not saying this will create such errors (perhaps your static_assert will mask the pain, this waits to be seen), I'm just cautious of this.

In terms of the concern of casting in places where we have more dynamic spaces like the swing-foot case, I would argue that the current solution is as bad or worse, in those limited cases. The letters have to change (or the letters suffer from the exact same issue of casting/reassignment) when you change from left-foot to swing-foot anyway. I don't understand how having it templated changes this.

 This is why we are here. Honestly, I don't think there is a workable solution to this, apart from refactoring the offending code, but I don't think that is possible either. I am mainly venting and hoping someone else has an awesome brainwave.

I think the clang-tidy check is a great idea too. I think it would sit on top of this solution quite well - we don't have to have an exclusive-or choice between the two. The naming convention of Hab transforms is retained with this solution and the clang-tidy solution is valid whether we add this or not.

Having both may not be smart. It means you have two tightly-coupled systems that need to be maintained that are both trying to do the same job.

In terms of people just ignoring the check: that's what code review is for. Once we fix all of the clang-tidy warnings existing in the codebase, we'll turn clang-tidy on in the CI (along with -Werror, soon^TM), which means that people will be forced to use // NOLINT if they want to do naughty things, which is super easy for reviewers to catch. I don't think this will be an issue once clang-tidy and -Werror are on for CI builds.

Code review is only as good as the reviewers. If the reviewers aren't downloading and compiling the code themselves to check the warnings, or if they aren't trawling through the buildkite (or github actions) output to check for any warnings, and they miss it in the code then all of our "checks" have come to naught. If this issue is as severe as we think it is (or want it to be) then it can't be something that is easily bypassed/missed.

People should be running clang-tidy before they merge things. They can turn on CI_BUILD in configuration and get a build which perfectly matches the CI build - that's the benefit of that CMake variable. Yes, it's annoying! I completely agree. But, it's way way better if we go through that effort to catch potential bugs before they get merged and are in the codebase for 10 years.

That is my point though. If it's hard/annoying to do people won't do it. The only "nice" part about this situation is that we have a CMake variable for it.

100% with you on documentation. It should certainly be improved. I am thinking a NUbook section with the list of spaces and their corresponding letters is necessary, so people can do a look-up of a letter if they're not sure.

No, that is way too much. That would make the documentation page as bad as what @TrentHouliston said the Spaces namespace was going to be. You would have this one documentation page that could be getting updated frequently and which is a "long distance" from the code you are looking at for you to look it up. The documentation page should be short, simple, and sweet. Just list some of the most common spaces we use (torso, camera, field, world, not sure there are too many others worth a special mention). The maths page can also expand more on the notation with how and why we use it (maybe even an extra page that just lists the notation we use so it isn't lost in the rest of the maths).

One benefit of this class is that it gives a direct indication of what the Transform objects are. It's self-documenting in multiple ways - it clearly states the spaces involved, giving an intuitive look at the mechanics of the naming scheme (the naming scheme makes a lot more sense with a bit more context, which this provides, right at the location of the code), and it clearly indicates what the transform is - Transform<double, "Camera", "Torso"> is much more helpful that the typename Eigen::Affine3d.

Yes, that is nice. However, clear commenting also serves that purpose (which people should be doing anyway). Also understand that Transform can also be considered to be vague. What sort of transform? Is it affine? projective? isometry? rotation? translation? scaling? perspective? Some other sort of non-affine transformation? Is it 2D transformation? 3D? 4D? ND? Transform could apply equally to all of these while Eigen::Affine3d can only apply to 3D affine transformations. Your Transform class also only wraps 3D affine transformations, but we have been trying to introduce 2D affine transformations as well, will you create a wrapper for that? How will it differ from this one?

I don't think any of those really outweigh the immediate benefits that this construction could give us though: no incorrect space manipulations (huge!!), and clear, self-documenting space assignment, as well as providing insight into the naming scheme.

We clearly are disagreeing on this point. While there may potentially be some benefits to this construct I can also see some detriments and I am not convinced that the benefits outweigh the detriments. I can also see other ways to achieve the same/similar benefits and I am seeing no clear winners.

IMO, those factors combined outweigh the issue of a potentially having a few extra casts in a couple of spots in the codebase, and potentially having verbose compiler errors (which also prevent you from making mistakes). I started lukewarm on this, but now I am more and more keen the more I think about it. If you @Bidski and @TrentHouliston both think that this isn't worth it, I'll close the PR, but I really think this could help us.

At the moment I am on the fence about this. As much as I am for the clang-tidy check. I can't see that this extra complexity (in either case) is going to provide clear benefits that make maintaining the complexity worth it. I am also concerned that our space aliasing is going to result in a lot of casts/NOLINTNEXTLINEs (I don't know how extensively we alias spaces so this may not be an important point, but if there are a lot then that will just be annoying).

I'll convert a couple of reactors on a branch off this one, and we can see if it seems good when we use it. I will do it for sensorfilter and the Quinticwalk

Sure, lets see where this leads us.
I am also really annoyed that the C++20 "improvement" is only for string literals .....

I have pushed a branch based off this branch which replaces AffineXd usage with Transform usage for Sensorfilter and QuinticWalk. The branch compiles as is.
Heres SensorFilter.cpp: link
and QuinticWalk.cpp: link
and the branch, for general browsing: all relevant changes in last two commits
I am a fan :stuck_out_tongue_closed_eyes:
For reference, here is a picture of what it looks like when the spaces are incompatible for a multiplication. The line number is directly above the word error in red. It was a very quick fix with the line number.

It seems like we won't reach a consensus in favour of this change. Closing.

I think that there is still merit in this.

Code review is only as good as the reviewers. If the reviewers aren't downloading and compiling the code themselves to check the warnings, or if they aren't trawling through the buildkite (or github actions) output to check for any warnings, and they miss it in the code then all of our "checks" have come to naught.

The build fails, the creator of the code reads the error log, fixes the error. No need for reviewer to read the logs.

We also need to remember that unless me move to clang as our main compiler the only ways people will be able to see that they have got the naming wrong is by either explicitly running clang-tidy via cmake (needing a complete rebuild using clang/clang-tidy) or by pushing their changes and making a (draft) PR and waiting for the CI checks to complete. Both of these options are annoying and painful, and if they are developing in one of the NUC docker images then they can't actually run clang-tidy until they swap to the generic image.

Better than guessing :shrug:, and I think it is important that broken code should fail in CI.

Compiler errors are good until they are unreadable.

A compiler error is better than a runtime error or logic error, even if it is unreadable.
Now I do think that we should move away from the Transformation name, as that name is too generic.
Some new ideas :stuck_out_tongue_closed_eyes:
We should make explicit space objects rather than having string literals.
We could have common spaces as constant expressions e.g. constexpr Space torso{};,
have temporary spaces like Space cool_space_only_in_this_scope{}
And have space aliases like Space swing_foot = SpaceAlias(Space::foot)
I'll make a PR


error on defining a hook inside of a hook for<EMAIL_ADDRESS>

🐛 Bug Report

After updating repository to use jest v27, it does not allow to define a hook inside a hook which previously worked fine.
To Reproduce
Created the given files and trying to run the test
For the given test -
app.ts
export const func= (val: Number) => new Promise((resolve, reject) => {
	resolve(val)
})

app.test.ts
import {func} from './index'

beforeAll(() => {
	beforeAll(() => {
		console.log('hello')
	})
})
describe('test func', () => {
		console.log('hello')
		test('return 10', async () => {
				expect(await func(10)).toBe(10)
		})
		test('return 10', async () => {
				expect(await func(20)).toBe(20)
		})
})

throws error -
  ● Test suite failed to run

    Cannot add a hook after tests have started running. Hooks must be defined synchronously.

      2 |
      3 | beforeAll(() => {
    > 4 |       beforeAll(() => {
        |       ^
      5 |               console.log('hello')
      6 |       })
      7 | })

      at eventHandler (node_modules/jest-circus/build/eventHandler.js:114:11)
      at src/app.test.ts:4:2

Expected behavior

I expect that since we are just adding a hook which runs before the tests, the test blocks should technically wait while the nested hook executes which in turns console logs a statement. this was possible to do on v26.1.0 but gives the error I mentioned above now.
Link to repl or repo (highly encouraged)

please use https://github.com/asthemus/jestHooksError to reproduce the given error
envinfo

  System:
    OS: macOS 10.15.7
    CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
  Binaries:
    Node: 14.15.4 - /usr/local/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 6.14.10 - /usr/local/bin/npm
  npmPackages:
    jest: ^27.0.0 => 27.0.4

P.S
Please guide if it is some intended change. cannot find it on release notes

Why would you do beforeAll in beforeAll?

In my code, we were calling an imported method which injects beforeAll hook. so technically that's calling beforeAll inside beforeAll. Basically I wanted to understand if this is any intended change. because if it's not then it's probably a bug since it was working fine in previous versions. To me it feels pretty obvious that we should be executing everything inside a hook before the tests start, irrespective of what is passed as callback to the hook.

yeah but you are not executing beforeAll in beforeAll, you are registering a beforeAll callback in beforeAll which looks really wrong practice in my opinion
I am glad jest 27 fixed that if that is the case

it's not mentioned as a fix in there release notes on anywhere

are you using jest-circus or jest-jasmine2 as a runner?
In case you are on a jest-circus, it is for some time in jest, since 2018 I think and you would need to look bit more than just changelog for 27 release

Good call @fatso83, this is working as intended 👍


data in docker

where is the data when using miniflux with docker? if i need to update, can i just pull the new image and run it again?

Docker image provide a VOLUME you can use to map a local filesystem inside the container for data persistence.
More informations on my image documentations:
https://hub.docker.com/r/lcaflc/miniflux/

oh, i used the miniflux/miniflux image. alright, i will look into yours. thanks.

It works the same way with the official image, it is just not documented you must look at the Dockerfile to find information.

The Dockerfile is not written properly. It needs an extra container for the database. I'm going to fix that in the next days. And document it.


Have server return JSON for 404s

Currently, the server (probably ever since the html page change) returns html instead of json for 404s.  Change it to return a 404 json error object.

Fixed in #167


[Bug] BetterDiscord does only show the settings button after a refresh on the plugins page if getSettingsPanel is set after the plugin loads

Describe the Bug
BetterDiscord does not add the settings button if the getSettingsPanel property is set after the plugin starts. To demonstrate this. lets grab a basic plugin example:
module.exports = class {
   start() {

   }
   stop() {

   }
};

This is the structure of a plugin. Since it is a class, you can do class declarations anywhere inside the plugin
module.exports = class {
   start() {
      this.hello = "hi"
   }
};

But what if you set a getSettingsPanel property? This is where the issues comes in
module.exports = class {
   start() {
      this.getSettingsPanel = () => BdApi.React.createElement("div", {}, "uwu")
   }
};

Since BetterDiscord does look to that property when it loads the plugin, and not when it starts, BetterDiscord does actually add a settings page, but it won't display the settings button until you hit it.
To Reproduce
1- Set getSettingsPanel when starting a plugin
2- Notice that the button isn't loaded
3- Refresh the plugins page (by going to the themes page for example)
4- See the button
Expected Behavior
It should update the UI and show the settings button
Screenshots
https://user-images.githubusercontent.com/27961224/187093454-746dc0e1-e87c-44f3-a129-7e7a8502891c.mp4
Discord Version
Stable, Canary, PTB. Any of them can work

This is intentional. getSettingsPanel should exist as a function alongside start and stop as per the documentation https://docs.betterdiscord.app/plugins/introduction/structure#optional-functions. It is not called if the plugin is not enabled so I don't see the benefit to supporting this method.


Bug: CultureInfo isn't passed when parsing

StringTypeConverterBase<> does not pass along the incoming culture to its abstract Parse method. It should, and derived types should pass it along to the DateOnly.Parse and TimeOnly.Parse methods.
Because of the current behavior, properties such as RangeAttribute.ConvertValueInInvariantCulture and RangeAttribute.ParseLimitsInInvariantCulture have no effect when using ASP.NET ModelState binding/validation. The parsing happens in the "current" culture, which is the OS-level regional settings of the web server that the application is running on. It should be possible to avoid that by parsing using the invariant culture. That way, the web application can be deployed to servers all over the world and behave the same.

For reference, see: https://github.com/dotnet/runtime/blob/main/src/libraries/System.ComponentModel.TypeConverter/src/System/ComponentModel/DateOnlyConverter.cs#L48

Thanks for filing this! I'll look into this over the coming week, or you can create a PR if you'd like

Thanks for the offer, but I have too many things going on right now to create a PR. There's no urgency from my side to get this fixed, so if you can look into it somewhere next week, that would be great.

Hm, okay, there's type converter and json converter. If I change type converter to respect provided culture, they would behave differently. And it seems like json converter from the runtime does use invariant culture:
https://github.com/dotnet/runtime/blob/4af855b0101bad16a4e25a7ec3c4c6a2f2984fb0/src/libraries/System.Text.Json/src/System/Text/Json/Serialization/Converters/Value/DateOnlyConverter.cs#L61
Do you have some context on why are they implemented differently? This way if DateOnly is passed as a query argument - current culture will be used, and if it's passed in the request's body - it wouldn't be. Or maybe I'm missing something

They are supposed to behave differently. JSON prescibes how numbers and dates are formatted, irrespective of culture. TypeConver is typically used to bind objects to UI controls, where using the current culture by default makes sense. To make TypeConverter not use the current culture (ie when parsing a query string), feed it a fixed culture, such as invariant.

Could you try v2.1.1, and see if it resolved the issue?

Yes, that solves the problem. Thanks for the fix!


Documentation

I found the getting started topic in the white paper. Can be there is a more complete version(tutorials, api reference, good practices, etc)?

Hi @NeoAnomaly,
Getting started in the white paper is a bit outdated. We are planning to release new version after the Siggraph. In the meantime you can use reference renderer to study best practices (at least I hope it is using best practices:))

Any progress with the documentation?

Hi @JaniKallankari ,
Still working on it, will hopefully have something next week.

Hi @yozhijk
I'm also looking forward for an up to date documentation.
Thanks :-)

Is there any plans to improve documentation in 2017?

@JaniKallankari Yes, I am currently doing significant changes in reference renderer in scene-interface branch. Will put the doc once I merge it in.


MQ - Initial implementation

Closes #3601
All Terraform tests pass with this implementation.
Error scenarios have been tested against AWS.
No EC2 integration exists yet w.r.t. security groups or subnets

Codecov Report

Merging #4789 (8c29217) into master (d679a73) will increase coverage by 0.04%.
The diff coverage is 99.15%.

@@            Coverage Diff             @@
##           master    #4789      +/-   ##
==========================================
+ Coverage   95.02%   95.07%   +0.04%
==========================================
  Files         580      586       +6
  Lines       61353    61928     +575
==========================================
+ Hits        58303    58877     +574
- Misses       3050     3051       +1

Flag
Coverage Δ

servertests
36.24% <29.68%> (-0.06%)
:arrow_down:

unittests
95.01% <99.15%> (+0.04%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

moto/backend_index.py
100.00% <ø> (ø)

moto/mq/models.py
98.23% <98.23%> (ø)

moto/__init__.py
98.43% <100.00%> (+0.01%)
:arrow_up:

moto/mq/__init__.py
100.00% <100.00%> (ø)

moto/mq/configuration.py
100.00% <100.00%> (ø)

moto/mq/exceptions.py
100.00% <100.00%> (ø)

moto/mq/responses.py
100.00% <100.00%> (ø)

moto/mq/urls.py
100.00% <100.00%> (ø)

moto/efs/models.py
88.21% <0.00%> (-0.36%)
:arrow_down:

moto/ses/utils.py
100.00% <0.00%> (ø)

... and 14 more

Continue to review full report at Codecov.

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


How to pass Environment based parameters in jasmine framework to protractor test

Hi,
I want to pass the arguments to the browser in jasmine frame work configuration file.
like " multiCapabilities: [{
'browserName': 'chrome',
maxInstances: 1,
name:'chrome',
'args': ['user=user1']
}, {
'browserName': 'firefox',
shardTestFiles: true,
maxInstances: 1,
name:'firefox',
'args': ['user=user2']
}
],
and also read in the test file how to read and use according to the browser.

@aidaeology  for me its not working i have tried
capsPromise.then(function(caps){
var browserName = caps.caps_.browserName.toUpperCase();
var browserVersion = caps.caps_.version;
var platform = caps.caps_.platform;
var prePendStr = browserName + "" + browserVersion + ""+ platform+ "_";});


Add COLUMN NUMBERS to ":" commands ":line1,line2[col1,col2]cmd"

I run into issues arising from the fact that you can only run commands on lines and not on the actual selection quite frequently and since I could not find an issue about it I thought I would make one.
For example see how wv$:s/./\?/g behaves differently than wv$r? or how w!$ is the same as doing !!.
There is also a short entry in the todo file about this.
https://github.com/vim/vim/blob/4c5d815256099b50eca2ec5bf8f9aaa67a890211/runtime/doc/todo.txt#L3696-L3697

todo link is wrong (because it's using master which keeps changing). Should be: https://github.com/vim/vim/blob/4c5d815256099b50eca2ec5bf8f9aaa67a890211/runtime/doc/todo.txt#L3696-L3697

thanks, i fixed it.


fix/IllegalStateException_on_adding_mediaView

Fix Issue 238.   Here is the stack trace.
 Caused by java.lang.IllegalStateException
The specified child already has a parent. You must call removeView() on the child's parent first.
android.view.ViewGroup.addViewInner (ViewGroup.java:5226)
android.view.ViewGroup.addView (ViewGroup.java:5055)
com.facebook.react.views.view.ReactViewGroup.addView (ReactViewGroup.java:516)
android.view.ViewGroup.addView (ViewGroup.java:4995)
android.view.ViewGroup.addView (ViewGroup.java:4968)
com.applovin.reactnative.AppLovinMAXNativeAdView.setMediaView (AppLovinMAXNativeAdView.java:388)
com.applovin.reactnative.AppLovinMAXNativeAdViewManager.setMediaView (AppLovinMAXNativeAdViewManager.java:148)

It seems that the native setter methods are called twice because the same ad is reloaded, or JS somehow tries to update the props twice.  With this fix, the native setter methods can be called multiple times.

I can merge and push


exit earlier if no data

Fix to avoid warn message when query region has no data

Thanks Sarah, it's a bit late to go live. I suppose we can try to sneak it in later.

No problem - this is a non-urgent fix. It doesn't change what a user
sees but means you don't get a warn in the logs if they query for a
region with no data.
On 31/03/2015 15:00, Kieron Taylor wrote:

Thanks Sarah, it's a bit late to go live. I suppose we can try to
sneak it in later.
—
Reply to this email directly or view it on GitHub
https://github.com/Ensembl/ensembl-rest/pull/45#issuecomment-88098293.

it can go into next release though
thanks for the change


Resolve xnet package CVE-2023-45288

The issue resolved by this Pull Request:
Resolves https://issues.redhat.com/browse/RHOAIENG-5450
Description of your changes:

Resolves this High Level CVE in go.mod
Testing instructions

Imported my fork in synk and made sure the relevant CVEs were fixed with this update.
Updated package versions locally based on what versions are compatible with each other and ran go mod tidy.
Ran go build locally to make sure no errors were introduced due to any breaking changes arising from package version upgrades.
Pushed changes to my fork and ensured the CVEs were resolved.
Checklist

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

A new image has been built to help with testing out this PR: quay.io/opendatahub/data-science-pipelines-operator:pr-629
An OCP cluster where you are logged in as cluster admin is required.
To use this image run the following:
cd $(mktemp -d)
git clone git@github.com:opendatahub-io/data-science-pipelines-operator.git
cd data-science-pipelines-operator/
git fetch origin pull/629/head
git checkout -b pullrequest d2c710cbece9b01252e9845c8233a62c7f8d43f1
oc new-project opendatahub
make deploy IMG="quay.io/opendatahub/data-science-pipelines-operator:pr-629"

More instructions here on how to deploy and test a Data Science Pipelines Application.


Codegenerator float to double check

c code has been fixed and lk fixed. All other languages updated  but not tested - see https://github.com/NREL/SAM/issues/222
https://github.com/NREL/SAM/issues/217
https://sam.nrel.gov/forum/forum-general/2958-sam-to-matlab-code-errors-generic-system-and-battery.html
"New SDK library with GCC" user support email chain

There have also been several questions about this issue in MATLAB on the SAM forum, for example:
https://sam.nrel.gov/forum/forum-sdk/2949

Go through Matlab issues and fix mex libpointer calls for all inputs and outputs. Also, modify code generation to copy the latest sscapi.h which is included in all platforms in the application path. Fix in SAM_280 branch of SAM and update ssc cmakelists for post build events on windows. Build and test and merge into patch and develop branches

For example, Matlab case for Generic-battery Residential results

Fix will be included in 2020.2.29 Revision 2 ssc version 240


java.lang.NullPointerException: Exception in server tick loop

I have been living in an RFTools Dimension for quite some time now. It was working fine yesterday but today I get a crash when I try to start my server.
Crash Report: http://pastebin.com/0WsxnXiL
Log: fml-server-latest.txt

Did you update any mods? Anything significant changed?

Seems somehow dimension 4 got lost:
[14:23:44] [Server thread/INFO] [STDERR/]: [net.minecraftforge.common.DimensionManager:initDimension:223]: Cannot Hotload Dim: Could not get provider type for dimension 4, does not exist

Did you update or change pams harvestcraft?

Well before yesterday I was taking a break for about a month, so yesterday I updated 30+ mods, and added some more.
Pam's harvestcraft was among them, yes.

Problem is that the dimension was generated with something specific from pam's harvestcraft that no longer exists. I will see if I can add some protection for that to avoid the crash

Interesting, yesterday, when I launched the server for the first time after updating everything it should have delete all those items when forge prompted for it.

yes but that's not the problem. The problem is that rftools dimension itself also keeps information and stores its as block ids. If too much changes the ids can change and this is probably what happened. I'll see what I can do about this

I made a fix which will hopefully make your world loadable again. I am not able to test this though.
Also made the code more robust so that for new dimensions this should no longer occur. Will release fix for this shortly

Perfect, it works! thank you.

Scratch that, it messed up the IDs:

Okay, I tried using a backup of the world from yesterday with this new version of RFTools dimensions and it didn't mess up the IDs, which means it was something else that corrupted my old world.
This is all too weird, I have no idea what's happening anymore. I'm afraid it will bug once again when I close the server.

Yep, the server crashed when I tried to close it:
fml-server-latest.txt

Now I still have no idea what's actually causing the crash when closing the server, I am looking at the log but I'd lie if I said I understood half of it, I have to ask for your help once more, could you point me in the right direction?

I let @elec332 look at this as it seems to be caused by eleccore

Is this solved now with latest ElecCore?


Get-DbaBackupInformation - new switch RestoreTime

Feature Request
Get information on what files we need to restore database to given date/time from msdb.
This may save us time to get files from tape, or, just supply files list to Restore-DbaDatabase this will save time consuming step to read backup headers from disk.
Problem to solve
Save time

isn't that a feature already present for get-dbabackuphistory ? if you have to go to msdb, use the history, if you don't have it, go to get-dbabackupinformation

I think you're asking for what Select-DbaBackupInformation does? That filters down backups to those needed to get to RestoreTime
What you actually want is a 'Only scan files newer than this' parameter?

@niphlod nope GDBI don't give as info for RestoreTime, just last full/diff/log and since some date, but what I want, I home, will make GDBI all around command for backup information.
@Stuart-Moore, I'll take a look at Select-DbaBackupInformation

If you pipe Get-DbaBackupHistory output into Restore-DbaDatabase with the -TrustDbBackupHistory switch it skips GDBI (so all header scans) and just dumps it into Select-DbaBackupInformation to build a history up.
If someone wants to reduce the number of files being scanned there's the option to do this:
Gci c:\mybackups  -recurse | ?{$_.LastWriteTime -gt (Get-Date).AddDays(-2) | Restore-DbaDatabase .....

Same works with GDBI as well. Thinking is that if someone wants to do something that complex it's probably better they work with standard PS components and then we take over, rather than writing overly complex code that won't be right for everyone

Thank you guys for help!
Get-DbaBackupInformation and Select-DbaBackupInformation is what I need =)


Fix: Reject duplicate layer names

This PR

[x] rejects duplicate layer names

💁♂ Not sure if is by design, but I can't see a reason why anyone would need to define multiple layers with the same name. Instead they probably want to define multiple collectors.

Build failure appears to be unrelated.

Build failure appears to be unrelated.

Thank you, @localheinz!

Thank you, @smoench!


Do/Will MoltenVK support maxImageArrayLayers>1 stereoscopic 3D?

Is it possible to use MoltenVK to present stereoscopic 3D images when appropriate monitor or TV set is connected?

Not yet. I've asked Apple for this feature, but they've yet to implement it in CAMetalLayer.


What is a JWT

Checklist

[ ] Define the outcome (value) that the post will have for the reader (i.e. what will they learn or gain)

[ ] Who is it for? (i.e. someone building auth - junior / senior, previous knowledge required etc, specific tech stacks)

[ ] Level of depth on the topic

[ ] Define real world application / relevance. Why is this topic important?

[ ] Writing the post

[ ] Define article title

[ ] Define meta title, meta description, meta image tags (for social)

[ ] Define meta title, meta description, meta image tags (for SEO)

[ ] Proof read

[ ] Adding title meta

[ ] Adding description meta

[ ] Adding OG meta

[ ] Adding analytics

[ ] Adding to sitemap.xml

[ ] Release on test

[ ] Check landscape and portrait view of blog

[ ] Check for SEO (via SEO agent)

[ ] Release to prod

[ ] Clone the blog on

[ ] Medium
[ ] Hackernoon
[ ] Codementor
[ ] Dev.to
[ ] Dzone
[ ] Hashnode
[ ] lobste.rs
[ ] For each of these platforms, remember to put in the seo  title, meta description, OG image and adding canonical tags.

[ ] Distribute on

[ ] Reddit
[ ] LinkedIn
[ ] HN
[ ] Slack (YC channel)
[ ] Medium

From SEO point of view, be sure to write about:

jwt rejected: user authentication failed (1k people searching this monthly) and it's insanely easy to rank for (0/100 - easiest score possible)
this jwt token doesn t support required scopes (1.1k people searching)
JWT decode (a whopping 42k people searching this and 8.6k for "JWT token decoder")

I think one good way to do this would be to add a section on "common problems with JWT" or something similar, and then list these as h2 or h3s

Example of a JWT's creation, signing and verification process
1) Create a JSON
Let's take the following JSON:
{
    "userId": "abcd123",
    "expiry":<PHONE_NUMBER>301
}

Notice that we have also added an expiry field (in milliseconds since epoch). We will see how this field is used during the verification process.
2) Create a JWT signing key and decide the signing algorithm
First, we need a signing key and an algorithm to use. We can generate a signing key using any secure random source. For the purpose of this post, let's use:

Signing key[^1]: NTNv7j0TuYARvmNMmWXo6fKvM4o6nv/aUi9ryX38ZH+L1bkrnD1ObOQ8JAUmHCBq7Iy7otZcyAagBLHVKvvYaIpmMuxmARQ97jUVG16Jkpkp1wXOPsrF9zwew6TpczyHkHgX5EuLg2MeBuiT/qJACs1J0apruOOJCg/gOtkjB4c=
Signing algorithm: "HMAC + SHA256" or HS256.

3) Creating the "Header"
This contains the information about which signing algorithm is used. Like the payload, this is a also a JSON and will be appended to the start of the JWT (hence the name header):
{
    "typ": "JWT",
    "alg": "HS256"
}

4) Create a signature

First we remove all the spaces from the payload JSON and then base64 encode it to give us eyJ1c2VySWQiOiJhYmNkMTIzIiwiZXhwaXJ5IjoxNjQ2NjM1NjExMzAxfQ. You can try pasting this string in an online base64 decoder to retrieve our JSON.
Similarly, we remove the spaces from the header JSON and base64 encode it to give us: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.
We concatenate both the base 64 strings, with a . in the middle like <header>.<payload>, giving us eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiJhYmNkMTIzIiwiZXhwaXJ5IjoxNjQ2NjM1NjExMzAxfQ. There is no special reason to do it this way other than to set a convention that the industry can follow.
Now we run the Base64 + HMACSHA256 function on the above concatenated string and the secret to give us the signature:Base64URLSafe(
    HMACSHA256("eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiJhYmNkMTIzIiwiZXhwaXJ5IjoxNjQ2NjM1NjExMzAxfQ", "NTNv7j0TuYARvmNMmWXo6fKvM4o6nv/aUi9ryX38ZH+L1bkrnD1ObOQ8JAUmHCBq7Iy7otZcyAagBLHVKvvYaIpmMuxmARQ97jUVG16Jkpkp1wXOPsrF9zwew6TpczyHkHgX5EuLg2MeBuiT/qJACs1J0apruOOJCg/gOtkjB4c=")
)

Results in:
3Thp81rDFrKXr3WrY1MyMnNK8kKoZBX9lg-JwFznR-M

We base64 encode it only as a industry convention.

5) Creating the JWT
Finally, we append the generated secret like <header>.<body>.<secret> to create our JWT:
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiJhYmNkMTIzIiwiZXhwaXJ5IjoxNjQ2NjM1NjExMzAxfQ.3Thp81rDFrKXr3WrY1MyMnNK8kKoZBX9lg-JwFznR-M

6) Verifying the JWT
Once the client sends the JWT back to the server, the server does the following steps:

Fetches the header part of the JWT (eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9).
Does base64 decoding on it to get the plain text JSON: {"typ":"JWT","alg":"HS256"}
Verifies that the typ field's value is JWT and the alg is HS256. If not, it would reject the JWT.
Fetches its secret key and runs the same Base64URLSafe(HMACSHA256(...)) operation as step number (4) on the header and body of the incoming JWT. Note that if the incoming JWT's body is different, this step will generate a different signature than in step (4).
Checks that the generated signature is the same as what signature in the incoming JWT. If it's not, then the JWT is rejected.
We base64 decode the body of the JWT (eyJ1c2VySWQiOiJhYmNkMTIzIiwiZXhwaXJ5IjoxNjQ2NjM1NjExMzAxfQ) to give us {"userId":"abcd123","expiry":1646635611301}.
We reject the JWT is the current time (in milliseconds) is greater then the JSON's expiry time (since the JWT as expired).

We can trust the incoming JWT only if it passes all of the checks above.

To summarize, a JWT is a token that is sent from the server to the client, so that the client can be identified in a secure and trusted manner when making API calls. The security and trust comes due to the signing and verification process.

https://docs.google.com/document/d/1rmHi1nn7Q0A5luwdxWvARE8FGNnIBw5mixHF39KCGP8/edit


Use Block Kit to shorten the Slack stats output

This PR re-formats the Slack stats output using Slack's Block Kit API and the nathanheffley/laravel-slack-blocks package, condensing the size of the message. See #23 for more details.
Screenshots:

Fixes #23.

@sbine 🙌


DNS Resolve ambiguity in which DNS servers are used during resolution

Motivation:
Recently DnsServerAddressStreamProvider was introduced to allow control for each query as to which DNS server should be used for resolution to respect the local host's default DNS server configuration. However resolver-dns also accepts a stream of DNS servers to use by default, but this stream is not host name aware. This creates an ambiguity as to which method is used to determine the DNS server to user during resolution, and in which order. We can remove this ambiguity and provide a more general API by just supporting DnsServerAddressStreamProvider.
Modifications:

Remove the fixed DnsServerAddresses and instead only accept a DnsServerAddressStreamProvider.
Add utility methods to help use DnsServerAddressStreamProvider for a single entry, a list of entries, and get the default for the current machine.

Result:
Fixes https://github.com/netty/netty/issues/6573.

@tomasherman - PTAL.

@trustin PTAL as well

4.1 (e074df2)
I will merge this change now and I can add back the deprecated method as a followup if you guys feel strongly about it.


14783 Lots of changes esp Business Name section + Review and Confirm page

Issue #: bcgov/entity#14783, bcgov/entity#14812 and bcgov/entity#15289
Description of changes:

updated NameRequestInfo whitespace
moved some formatting methods to CommonMixin
moved NameTranslation out of NameRequestInfo into own component
fixed EmptyAddress imports
updated Stepper with new getter
hid company name in SummaryDefineCompany for restorations
fixed "B.C. Ltd." -> "B.C. LTD."
implemented ApprovalType (shim for shared component)
implemented BusinessName (shim for shared CorrectName component)
implemented BusinessType component
deleted local CorrectCompanyName, CorrectNameOptions, CorrectNameRequest and CorrectNameToNumber components
refactored RestorationType for proper layout, validation, etc
implemented SummaryRestoreBusiness
deleted some local enums
deleted some local interfaces
cleaned up misc interfaces
added formatting methods to CommonMixin
misc cleanup to FilingTemplateMixin
deleted local NameRequestMixin
deleted obsolete resource properties
updated restoration resources (completing party properties)
added misc actions, mutations and getters
added ApprovalType (from Karim's PR)
implemented Request Type
imported shared CorrectName
imported shared AccountTypes enum
imported shared ApprovalTypes enum
imported shared NameChangeOptions enum
imported shared AddressIF
imported shared EmptyAddress object
deleted unneeded CorrectNameOptionIF
imported shared EmptyNameRequest object into each component ( NB: doesn't work in index file)
imported shared NrApplicantIF
imported shared NrNameIF
imported NameRequestIF
imported shared NameRequestMixin
misc cleanup
added BusinessName test suite (WIP)
added NameTranslations test suite
added SummaryRestoreBusiness test suite (WIP)
updated misc unit tests
includes Review and Confirm (14812)
includes Approval Type (15289)
app version = 4.6.0

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the bcrs-entities-create-ui license (Apache 2.0).

Wow, @severinbeauvais there's lots of great work here.  You've had to modify a large number of files to make these changes.

Wow, @severinbeauvais there's lots of great work here. You've had to modify a large number of files to make these changes.

Yes, a lot of untangling. Some of these changes will also be moved to the shared repo.

You know the domain better than I do. My gut feel is that the following logic would be better placed in a getter. Having this logic {{ getNameRequestApprovedName || '[Incorporation Number] B.C. LTD.' }} inside a template means that we can't test without instantiating the component and all the associated requirements.

I don't mind putting "simple" logic like this in the template, otherwise I definitely use local getters (computed).
As for testing, in which cases would we test this component without instantiating (mounting) it? And I'm not sure how we could test anything without providing its requirements. Open to new ideas...

Rather than passing a prop and event for each form field, what do you think of passing the entire "ApprovalTypeShared" object? If we're separating concerns, the parent shouldn't have to know the fields contained within a shared component and should have to know when we add or remove a field inside the shared component.

What do you mean, "passing the entire shared component object"?
If you mean passing an object of properties instead of individual properties then I think sure, why not.
The components here are:
|
+ RestorationBusinessName.vue (step 1)
   |
   + ApprovalType.vue (this component, which is a shim to the shared component)
      |
      + ApprovalTypeShared.vue (actually ApprovalType but renamed in parent)

The top parent doesn't handling any props or events for its child.
The shim handled the store interactions and the props/events for its child.
The bottom component does the UI work and doesn't (and shouldn't) know about the store stuff.
How would you improve this?

I love the way that JavaScript makes functions first class citizens -- this is such a powerful technique! Do we plan to pass in different functions, if so, can you provide some examples?

Different functions for this scenario (CorrectNameOptions.vue) ? No,  just the one function. But I pass it in so the child can use it as a black-box service. Meanwhile the parent can deal with axios and whatever.
I didn't bother with a full type for this function, and almost use "any" for it. I only typed the return value for the child's benefit.
If I didn't answer your question, what are you thinking here?

Is there an opportunity to separate the code associated with each filingType? I don't know if this would work, but I'd like to try diverting the logic by filingType early so we can simplify our code and reduce the number of times where we have to write a series of if-then, if-then-else or switch statements.

Yes but not the code you attached your comment to. This particular code does a conditional restore of each field, so it doesn't overwrite the initial store value if the draft filing (JSON) doesn't contain it.

@severinbeauvais what you do think about using a standard validation library like "VeeValidate" rather than exposing an event that the parent component must listen to? If I remember correctly, VeeValidate handles progressive form disclosure really well so that the parent doesn't need to know which form elements have been displayed and which are hidden. The parent shouldn't know which form elements have been renderd in order to know if the form is hidden.

We should look at this more deeply. I've played with VeeValidate before but didn't love it then. But we do have difficulty currently with progressive form disclosure. There's a ticket to look at form validation in more detail but it's not on anyone's radar. If you could champion this -- maybe after our current high-priority features are done -- that would be great.

Sure, I'd be happy to create a demo for your evaluation.  Let's revisit this after the high-priority features are complete.

I love the way that JavaScript makes functions first class citizens -- this is such a powerful technique! Do we plan to pass in different functions, if so, can you provide some examples?

Different functions for this scenario (CorrectNameOptions.vue) ? No, just the one function. But I pass it in so the child can use it as a black-box service. Meanwhile the parent can deal with axios and whatever.
I didn't bother with a full type for this function, and almost use "any" for it. I only typed the return value for the child's benefit.
If I didn't answer your question, what are you thinking here?

If we have a plan to pass different functions into CorrectNameOptions to achieve different behaviors, then passing a function as an argument is the right approach.  In this case, I wonder if you would consider dispatching a store action instead?  Actions are specifically designed to handle API calls.  By moving the fetchAndValidateNr() method to the store it allows for other components to use it too and it removes business logic from components.

If we have a plan to pass different functions into CorrectNameOptions to achieve different behaviors, then passing a function as an argument is the right approach. In this case, I wonder if you would consider dispatching a store action instead? Actions are specifically designed to handle API calls. By moving the fetchAndValidateNr() method to the store it allows for other components to use it too and it removes business logic from components.

I don't have a plan to pass in a different function. I just wanted the child (which is a shared repo component) to not need to know how to fetch a name request nor have to deal with possible validation errors. I'm thinking those are all "parent" concerns, not the child's, even though the child is prompting for the NR number. These components are not a great architecture atm but I didn't want to reinvent them completely, especially since the plan is to slot them back into Edit UI.
Are you OK with this callback function as-is?

Rather than passing a prop and event for each form field, what do you think of passing the entire "ApprovalTypeShared" object? If we're separating concerns, the parent shouldn't have to know the fields contained within a shared component and should have to know when we add or remove a field inside the shared component.

What do you mean, "passing the entire shared component object"?
If you mean passing an object of properties instead of individual properties then I think sure, why not.
The components here are:
|
+ RestorationBusinessName.vue (step 1)
   |
   + ApprovalType.vue (this component, which is a shim to the shared component)
      |
      + ApprovalTypeShared.vue (actually ApprovalType but renamed in parent)

The top parent doesn't handling any props or events for its child.
The shim handled the store interactions and the props/events for its child.
The bottom component does the UI work and doesn't (and shouldn't) know about the store stuff.
How would you improve this?

I would suggest that ApprovalTypeShared.vue should talk to the store.  We pass ApprovalTypeShared a store location (so it can be reused anywhere) and ApprovalTypeShared gets its status from the store and mutates the store as the user interacts with it.  ApprovalType.vue doesn't have to know anything about the inner workings of the ApprovalTypeShared.  We're free to add and remove fields from ApprovalTypeShared without having to make changes to ApprovalType.vue.
If you're uncomfortable with the idea of using the store, an alternative approach is to use v-model to set / get the ApprovalTypeShared object.   Using v-model objects is a little tricky (as we've discussed previously), but it's another way of encapsulating the ApprovalTypeShared without having to set individual field propos and emit individual field updates.

You know the domain better than I do. My gut feel is that the following logic would be better placed in a getter. Having this logic {{ getNameRequestApprovedName || '[Incorporation Number] B.C. LTD.' }} inside a template means that we can't test without instantiating the component and all the associated requirements.

I don't mind putting "simple" logic like this in the template, otherwise I definitely use local getters (computed).
As for testing, in which cases would we test this component without instantiating (mounting) it? And I'm not sure how we could test anything without providing its requirements. Open to new ideas...

I agree, it is simple logic, but it's business logic that I would suggest is better not in the template.  One reason is that many (all?) code editors can only show lines covered by tests when they're inside the

I see what you mean about comments added as part of a PR can't be replied to!  That's super irritating!  I won't do that again. Thanks for the tip @severinbeauvais

Rather than passing a prop and event for each form field...

What do you mean, "passing the entire shared component object"?

If you're uncomfortable with the idea of using the store, an alternative approach is to use v-model to set / get the ApprovalTypeShared object. Using v-model objects is a little tricky (as we've discussed previously), but it's another way of encapsulating the ApprovalTypeShared without having to set individual field propos and emit individual field updates.

I created ticket 15429 to look at this later. OK?

@jonathan-longe OK if I merge this? It will make it easier to finish the work in a subsequent PR.

Amazing amount of work here @severinbeauvais .   Thanks for the opportunity to review.


problem of trainer.fit() in run_imputain.py

Hello, I encountered the error of ' 'method' object is not iterable' when i ran the run_imputation.py, i tried many methods, but none of them solved. Do you know the reason?

i found the problem was in tsl.data.batch.py:
for k in elem.keys:
the elem.keys is actually the keys () method in the Data object, not an iterative object that can be iterated directly.