Add methods for converting from bool to Option<T>

Rendered.
The following pattern is prevalent in typical Rust code.
if some_condition {
    Some(t)
} else {
    None
}

Here, I propose new methods for converting a bool to an Option<T>, abstracting this pattern, to aid in readability and reducing repetition.
impl bool {
    fn to_option<T>(self, t: T) -> Option<T>;
    fn to_option_with<T, F: FnOnce() -> T>(self, f: F) -> Option<T>;
}

This supersedes https://github.com/rust-lang/rfcs/pull/2180, which was closed due to concerns about the suggested names and resolves https://github.com/rust-lang/rfcs/issues/2606.

Adding the language team since the actual implementation of this requires the addition of a language item #[lang = "bool"]. This should also be noted in the reference text of the RFC.

@varkor I think it would also be good to add a few examples of before/after for real world use-cases, e.g. in the compiler or elsewhere, that would have benefited from this RFC.
I think it would also be worth noting that this encourages the use of more closures. This ostensibly has the drawback of longer compile-times. On the flip-side, it also is a good idea due to the restrictions imposed on imperative control flow (return & friends). Such restrictions may improve local reasoning and is helpful towards creating closures that may be refactored into stand-alone functions over time. So the RFC may be a boon for maintainability.

There's now a reference implementation at https://github.com/rust-lang/rust/pull/64255.

I remember previous discussions on similar topics have regularly brought up the question of symmetry; aka "what about when self is false". is it something that should be mentioned/discussed in the RFC? is it future enhancement? is it worth adding the dual false.unthen() or should there be a false.not().then() or does !false.then() have the correct precedence (I believe not because it has to be looser than method calls for most things), or is (!false).then() acceptable?

@fbstj https://doc.rust-lang.org/nightly/std/ops/trait.Not.html
I think foo.not().then(...) or (!foo).then(...) is fine.

Very often you can rewrite a condition to avoid negation, and if that's not convenient (if the condition is used elsewhere, for instance), negation with ! or .not() seems no less readable, so I don't think we need extra methods for this.

..., so I don't think we need extra methods for this.

And on the off chance we do, we are free to add more methods later, so this feels very safe. ;)

I think the existing methods that are closest to the ones being proposed here are:
x.ok();  // Result<T, E> → Option<T>
x.err(); // Result<T, E> → Option<E>

x.ok_or(y);            // Option<T> → Option<T, E>
x.ok_or_else(closure); // Option<T> → Option<T, E>

x.and(y); x.and_then(closure); // Result<T, E> → Result<U, E>
x.or(y); x.or_else(closure);   // Result<T, E> → Result<T, F>

x.and(y); x.and_then(closure); // Option<T> → Option<U>
x.or(y); x.or_else(closure);   // Option<T> → Option<T>

I've noticed that the first four methods, which transform between different "monad kinds", explicitly mention the variant to transform to. The rest (and/and_then/or/or_else), on the other hand, stays within Option and Result respectively.
Based on this precedent, I think that methods which convert from bool to Option<T> should also contain the word "some" in their name, whatever the concrete choice is.

I've noticed that the first four methods, which transform between different "monad kinds", explicitly mention the variant to transform to.

Unfortunately, they're not that consistent. Both the methods from Option to Result and Result to Option are named after the Result (i.e. ok and err). This naming scheme in general does not extend well to other type combinations. I read some people state that some would be confusing, because it's either Some or None.

Seeing the name debate, I just want to ask why not to_option and to_option_with?  I imagine this was discussed elsewhere, but in terms of "what does this do" when you don't know them, my_bool.then(5) is cryptic, my_bool.to_option(5) isn't.  The former might have nice systemic math-like implications but the latter is very clear about what it does at least in my opinion.

Sorry, I skimmed through the discussion and didn't see it, but has something along the the following lines been considered??
Some(x).test(boolvar) // Some(x) or None

I don't know if there's a general rule against using test as a function name though (didn't see it in the keyword list). I was thinking ok might work as well, but then there's a small chance of confusion with ok_or and ok_or_else due to the different return types.
Presumably a lazy version would be a bit verbose though, which might make it a non-starter
Some(()).test(boolvar).and_then(|_| expensive_expression)

I'm not sure why this is tagged T-lang; this is entirely a libs decision.

Ah, just saw @Centril's comment (which was marked as resolved).
For the sake of simplicity, I'd suggest treating the questions orthogonally; can we just ask if anyone on @rust-lang/lang objects to the creation of this lang item for bool, and if not, leave the rest of the decision entirely to T-libs?

As for the "prior art" section, Scala 2.13 has Option.when (and Option.unless for the inverse): https://www.scala-lang.org/api/2.13.x/scala/Option$.html
Option.when(true)(0) // Some(0)
Option.when(false)(0) // None

Though in this case the T value is always lazily evaluated. The equivalent in Rust would be something like:
Option::when(true, 0)
Option::when_with(true, || 0) // but probably with a less awkward-sounding function name

I'm not a fan of then as the name because we typically use _then/_else as suffixes to indicate that a closure is used instead of a direct value. then_with seems particularly awkward.
Also, personally when I know I'm dealing with Option or Result types I'm already in the mindset to look for these kind of monadic operations, so names like and_then are not too surprising. This is not the case with bool.
@camlorn's suggestion of to_option/to_option_with seems much clearer.

Quick bikeshed addition: this also seems to be in line with how and_then() is used in other places.

@nugend We already have Option::filter that works just like your suggestion.
Some(x).filter(|_x| boolvar) // Some(x) or None

For the sake of simplicity, I'd suggest treating the questions orthogonally; can we just ask if anyone on @rust-lang/lang objects to the creation of this lang item for bool, and if not, leave the rest of the decision entirely to T-libs?

@joshtriplett In the future, please talk to me privately if you want to remove T-Lang from something. I usually have a good reason for doing adding T-Lang.
I'm fine with the addition of the language item for the purposes of what this RFC wants to achieve (since I think it's a reasonable and consistent addition) but I'm not fine with the language item for whatever. However, this RFC should not be taken as precedent for relying on lang items without the T-Lang's approval.

@tesaguri Oh, good point!
I guess having it right on the bool would save some finger motion if you needed to write it over and over.

I just want to ask why not to_option and to_option_with?

I'm happy with the names to_option and to_option_with, if there seems to be a rough consensus.

@rust-lang/libs: discussion seems to have stilled on this RFC. What are the next steps?

I like this feature, and the names to_option and to_option_with feel very reasonable and unsurprising to me. As far as I can tell naming was the only remaining question, so let’s
@rfcbot fcp merge

I see that this feature is already implemented as unstable since PR https://github.com/rust-lang/rust/pull/64255 and tracked at https://github.com/rust-lang/rust/issues/64260.
@rust-lang/libs how does it sound to make this FCP about stabilization? Or should we move it to the tracking issue?

https://github.com/rust-lang/rust/pull/65195 still needs to land before stabilization / or the stabilization can be rolled into that PR.

I sympathize with desire for an easy postfix bool to Option conversion -- but skimming the uses of to_option in rust-lang/rust#65195, I find practically all of them quite confusing relative to the original straightforward code.
For example:
- if path.is_absolute() {
-     Some(PathBuf::from(path))
- } else {
-     None
- }
+ path.is_absolute().to_option_with(|| PathBuf::from(path))

^ Obviously this is fewer lines, but if you read the line on the bottom does it actually make sense? The original code is crystal clear in contrast.
So with that I say the naming question still isn't settled.
To give an example of naming that I think reads more clearly, I would be on board with:
let _ = path.is_absolute().then(|| PathBuf::from(path));
let _ = path.is_absolute().then_some(path_buf);

@rfcbot concern :(

To give an example of naming that I think reads more clearly, I would be on board with:

So with that I say the naming question still isn't settled.

The difficulty here is that this is entirely a bike-shedding issue. Many varied names were suggested, and objections have been raised by various groups for most options. to_option seemed the least controversial (and, to me, most obvious). It's certainly more intuitive than some existing methods like and_then.
Regarding then, this was the name I had originally, but many people agreed that to_option was more intuitive. I'm not quite sure how to address this objection 😕

Maybe, if the naming can only lead to ambiguity in at least some cases, then it would be better to just not provide such a method, and keep the if / else everywhere? (No strong opinions on my side, just that I see mostly complaints that all the suggested names are hard-to-understand in some cases)

I don't think the naming to_option leads to ambiguity. Just like other function names, if the meaning isn't immediately obvious to you, then it is learnt, just like many other functions in the standard library. I think the benefits of having this method outweigh having to learn one more name. (I think there are many combinators on Option and Result in particular that have to be learnt, and this is a significant improvement.)

@varkor: my position matches what @Ekleog pointed out — if the logic that you want to factor out can't be given an intuitively readable name, then we shouldn't be factoring it out at all costs. I believe your PR rust-lang/rust#65195 makes all the code that was changed to use to_option worse than it was before the change.
I basically don't find the linked comment about then vs to_option at all compelling because it's based on my_bool.to_option(5) rather than looking at real code, which we now have in rust-lang/rust#65195 and can tell from it that the result is not good. FWIW I could not have told this confidently before looking at the usage in real code, so unfortunately any naming discussion that happened before this was not that useful.
From typing out some of the real code snippets from the PR using then_some / then (not your original then / then_with), I would be prepared to accept those names.

I believe your PR rust-lang/rust#65195 makes all the code that was changed to use to_option worse than it was before the change.

FWIW I could not have told this confidently before looking at the usage in real code, so unfortunately any naming discussion that happened before this was not that useful.

I see — in that case, I'm happy to revert the naming to then/then_with if the libs team agree with that change.

I think the trouble with to_option in context was that the name contains "to" but it wasn't clear that there isn't anything serving the role of "from". From other methods like to_owned and to_string we are used to there being a thing we convert "from" and a thing we convert "to", but the methods here are more about if/then rather than from/to. In toy examples it was easy to look like we are converting "from" the boolean, but that perspective ended up not making sense in real code where the boolean is just a condition and it would be confusing to think of converting "from" it.

path.is_absolute().then_some(path_buf) means: if path.absolute() then Some(path_buf).
.then_some(path_buf)
      ^^^^^^^^^^^^^^ what you see is what you get

path.is_absolute().then(|| PathBuf::from(path)) means: if condition is true then here is what to do. The "thing to do" (closure) either runs or not, and correspondingly you receive the Some if it ran or the None if it did not run.

Okay, I'm happy enough with then_some/then.

Couldn't it be considered confusing that Option::then() takes a value, but bool::then() takes a closure? I'm wondering about the mental overlap here, since Option is involved in both functions.

@troiganto: there is no Option::then method so I don't understand what you are referring to. There is Option::and which takes a value and Option::and_then which takes a closure, so the use of ending-then for a closure is absolutely consistent with my recommended names. Your objection applies to @varkor's old names of then (value) / then_with (closure) but be aware that my names are then_some (value) / then (closure).
As a side note, English is hard so there are multiple meanings of "then". In the case of bool::then it means if/then -- if cond then do. In the case of Option::and_then it means first/then -- first acquire some value then do thing with it.
Finally, everyone is welcome to keep pointing out objections, but understand that the point isn't to find a set of names without downsides. If you know such names, by all means tell us, but otherwise the point is to have names that make code clearer when used, which then_some / then achieve but to_option does not (as seen in https://github.com/rust-lang/rust/pull/65195).

Ah, that was a mix-up on my part, sorry for the noise. You'll hear no further objections from me :+1:

I've updated the names in the RFC to then_some and then, following @dtolnay's suggestion.

@rfcbot concern :((
Not sure whether to maintain this concern or not. I don't really feel optimistic that I can convince the Rust community these combinators are obscure and unhelpful, and I'm mostly resigned to std being full of them, since I will just never use them myself.
Like @dtolnay, I think the changes in #65195 made the code less clear, but unlike @dtolnay, I don't think changing the method name would help. Comparing this example:
if found { Some(cur) }
else { None }

found.then(cur)

The second in my view is totally opaque, now I need to figure out the type of found, and know what its then method does, to figure out what this code is doing. I think the theoretical arguments for to_option are pretty compelling in this example, but the best solution is to just not use a method: with the if statement, everything is just right there for you: you know that found is a boolean and that the statement evaluates to an option without looking elsewhere.
I think the main objection that leads people to want these methods is that rustfmt styles these if statements awfully (readers will note I styled the above code irregularly), so you end up with things like this:
if fn_like {
    Some(FnLikeNode {
        node,
    })
} else {
    None
}

Whereas it will allow you to write the method form in a single line. This is the sort of reason I don't use rustfmt or any other automatic code formatter when I write code. I realize "don't use rustfmt" is a losing argument, but it seems rather misguided to make your code less self-evident because the your formatter is making it less pleasing, seems like a really clear failure of the formatter to me in this case.
I don't know what to do here. I'm probably inclined to just let this be stabilized under whatever name other people can reach consensus on and then personally almost never use this method. But I am really at odds with the attitude this method improves on the corresponding if statements in every or even most cases.

@rfcbot resolve :((
Don't think its worth blocking.

@withoutboats since you're alluding to "these combinators", do you mean you (would have) oppose(d) many of the combinators in std? I'd be interested in your broader argument/viewpoint on this, if you'd care to elaborate (not sure this is the best venue for it).
And, in thinking about the comments from withoutboats and dtolnay, I came up with one more color for the bikeshed that I don't think has been mentioned: Option::from_bool(path.is_absolute(), || path_buf). This has the advantage that the conversion is much more explicit since both Option and bool are called out explicitly. It also only has one variant, always taking the closure, at the downside of taking slightly more syntax for the direct expression case. (One alternative name that I came up with is inflate(), but that's probably too idiosyncratic for something like this.)

And, in thinking about the comments from withoutboats and dtolnay, I came up with one more color for the bikeshed that I don't think has been mentioned: Option::from_bool(path.is_absolute(), || path_buf). This has the advantage that the conversion is much more explicit since both Option and bool are called out explicitly.

Option::from_bool largely negates the chaining benefits that .then(...) comes with combined with being more verbose. I think that puts it under the threshold of usefulness to justify the addition of a lang item.

I agree that a non-chaining associated function would this less an improvement over the status quo, perhaps to the point .
However I don’t think the lang item itself should require a lot of justification. That the standard library can define inherent methods on primitive types is an established fact that is not gonna change. We already have 21 lang items for this and they all work the same way. While coordinating with the compiler team and the language team when adding one more sounds fine, doing so would not add significant complexity to the compiler or the language. So the lang item count alone shouldn’t be an argument against a proposed addition to the standard library.

I tend to agree with @SimonSapin that lang team already "authorized" adding inherent methods to primitive types; I think that the libs team ought to be generally trusted to add appropriate methods. If this requires adding a lang item (I think that would be for the inherent impl?), that doesn't seem like a big deal in and of itself to me.

@withoutboats since you're alluding to "these combinators", do you mean you (would have) oppose(d) many of the combinators in std? I'd be interested in your broader argument/viewpoint on this, if you'd care to elaborate (not sure this is the best venue for it).

I'm not against adding this API (which is why decided to remove my concern) and I'm not against having the Option and Result combinator APIs in std overall, but I definitely do not think the message should be "anywhere you can use a combinator, you should." They usually do not make code easier to understand. Occasionally they do, and that's when people should use them. But in my experience that's very rare.

Just a thought to contribute. I think there are broadly two types of programmers.  Let's call them combinator programmers and imperative programmers (I don't want to use the word functional here because it's not exactly functional programming that I mean).  I think that code in one style seems bad to people in the other camp but that neither style is bad as such in itself.  I'm not trying to play the middle of an argument or somesuch because this is actually an important point in my opinion.  Rust chose to support both styles of programming, and I think that therefore broadly speaking Rust should continue to support both styles of programming--in effect adding combinators where combinators can be added, but also improving the imperative constructs (though for the most part I view the imperative constructs as "finished" because overall I'm not sure what could be added).
For examples of languages which broadly chose one path over the other, Go chose imperative and JS promises/async stuff chose combinators (at least, for a long time until async/await happened).
If anyone's wondering I'm in the combinator camp/strategy.

I concur with @withoutboats concerns here.
I don't think this is a question of combinators vs no combinators, as @camlorn framed it. I love to use them.
I do think that this is a case of a combinator that is helpful to have when looked at in isolation, but makes code more opaque and confusing in practice.
The naming is also somewhat contrarian to what is common in Rust: to_ methods are always used for direct, unconditional conversion, without requiring additional input.
I think the bar for entering std should be high, and additions should only be accepted if there is no clear downside.

@dtolnay I believe @varkor addressed your concerns, so ping. :)

I tend to agree with @SimonSapin that lang team already "authorized" adding inherent methods to primitive types; I think that the libs team ought to be generally trusted to add appropriate methods. If this requires adding a lang item (I think that would be for the inherent impl?), that doesn't seem like a big deal in and of itself to me.

Well I agree that this lang item in particular is not a big deal (because as @SimonSapin notes, we already have a bunch of those for primitive types, and so in terms of spec complexity there's nothing novel here). However, I think it's important that institutional hindrances exist against the addition of lang items, and the language team is a good check on that. That said, as for adding a non-method, I didn't make a point about teams -- just that I personally didn't think it was worth it -- and it seems like there's agreement on that, so that's great. :)

@rfcbot fcp cancel

Proposing FCP to introduce unstable methods on bool for conditionally creating an Option::Some or running a closure.
This RFC has been unusual compared to other libs RFCs in that whether we accept these methods hinges on whether we can settle on sufficiently clear names for the behavior; it isn't like e.g. MaybeUninit where we know we need the functionality and we'll pick a name one way or another. As such, mostly the FCP is to confirm that we are interested in gathering experience using this set of names—if it seems to work out then we'll follow up in the tracking issue with a separate FCP to stabilize later.
impl bool {
    fn then_some<T>(self, t: T) -> Option<T> {
        if self {
            Some(t)
        } else {
            None
        }
    }

    fn then<T, F: FnOnce() -> T>(self, f: F) -> Option<T> {
        if self {
            Some(f())
        } else {
            None
        }
    }
}

This is the same functionality as from the earlier FCP in https://github.com/rust-lang/rfcs/pull/2757#issuecomment-542176970, but new names as motivated in https://github.com/rust-lang/rfcs/pull/2757#issuecomment-544437510.
@rfcbot fcp merge

@rfcbot concern :((
Registering withoutboats's concern from https://github.com/rust-lang/rfcs/pull/2757#issuecomment-545418392.

@rfcbot resolve :((

Just to note, currently, I’m using the try-guard crate to do exactly that. I was happy to see that coming to std but it looks like it will not.

Just a thought to contribute. I think there are broadly two types of programmers. Let's call them combinator programmers and imperative programmers (I don't want to use the word functional here because it's not exactly functional programming that I mean). I think that code in one style seems bad to people in the other camp but that neither style is bad as such in itself.

Yes, I agree with that statement. However, as you said it, both styles are useful. I’m a Haskeller and use lots of combinators, but I also use lots of imperative statements. It’s not a “pick one; stick to it” decision. Especially, I use bool -> Option<T> / bool -> Result<T, E> to guard and verify pre-conditions and early-returns in functions. But for other common check, I tend to use if / else statements.
After reading the pro and cons arguments from this thread, I’m not sure what the best decision should be (I’m not saying that I’m against the decision of closing, I just haven’t made up my mind about how I feel about it). After all, we can still have those combinators in lib crates. The best comparison to me is, again, Haskell, because I know it a lot, but Haskell has that kind of functions in base (MonadZero) but the Haskell ecosystem is also using a lot libraries such as either, errors, etc.

Proposing FCP to introduce unstable methods on bool for conditionally creating an Option::Some or running a closure.

Landing unstable methods has already happened in https://github.com/rust-lang/rust/pull/64255 (tracked in https://github.com/rust-lang/rust/issues/64260) so I’m not sure what this FCP is for. Deciding on names (or removal) is basically the only thing left to do.

As a datapoint, this feature turns out pretty useful in proc macros, and IMHO the current naming reads nicely: ruma/ruma-api@cb00188

Another use that would benefit from this is iterators (especially in long chains):
let x = iter.filter_map(|(foo, condition)| condition.then(foo));

The alternatives include:
let x = iter.filter_map(|(foo, condition)| {
    if condition {
        Some(foo)
    } else {
        None
    }
);

and:
let x = iter
    .filter(|(_, condition)| condition)
    .map(|(foo, _)| foo)

Landing unstable methods has already happened in rust-lang/rust#64255 (tracked in rust-lang/rust#64260) so I’m not sure what this FCP is for. Deciding on names (or removal) is basically the only thing left to do.

The most recent nightly still has then/then_with naming which I wouldn't want to stabilize (https://github.com/rust-lang/rfcs/pull/2757#issuecomment-544277420). @varkor: could you send a PR to rust-lang/rust with the then_some/then naming suggested in https://github.com/rust-lang/rfcs/pull/2757#issuecomment-544437510? I'll cancel the proposed FCP here and we can do an FCP to stabilize in the tracking issue.

The renaming PR has been sent to the bors queue. :)

...and @bors has merged the renaming PR. :)

Looks good to me. :) Thanks @varkor! We can follow up with an FCP to stabilize in https://github.com/rust-lang/rust/issues/64260 after a few releases once we have some real world use cases outside of rustc to look at.

@rfcbot cancel

I tried using these combinators for some code that looked like this:
let prev = if path.exists() {
    ThinLTOImportMaps::load_from_file(&path).ok()
} else {
    None
};

Unfortunately, since the closure fed to for then has the signature FnOnce() -> T instead of FnOnce() -> Option<T>, I had to resort to code that looked like this:
let prev = path.exists().then(|| ThinLTOImportMaps::load_from_file(&path).ok()).flatten();

and at that point I decided that was obscure enough that it wasn't worth trying to adopt these combinators.
Given that the signatures of and_then in the standard library (as well as std::cmp::Ordering::then) always take a closure, is it worth considering having fn then_some here also always take a closure, and have the difference between fn then_some and fn then not be about whether it takes a closure or not, but instead about what that closure's signature is?
That is, I'm suggesting this API:
impl bool {
    pub fn then_some<T, F: FnOnce() -> T>(self, f: F) -> Option<T> {
        if self { Some(f()) } else { None }
    }
    pub fn then<T, F: FnOnce() -> Option<T>>(self, f: F) -> Option<T> {
        if self { f() } else { None }
    }
}

If people want to keep a closure-less method in the API, I suggest fn and_some, so that then consistently means "invoke a higher order function"
pub fn and_some<T>(self, t: T) -> Option<T> {
    if self { Some(t) } else { None }
}

(oh, whoops; I guess the current conversation regarding the names is in rust-lang/rust#64260 )

For anyone coming from a search engine, bool::then is stable as of rust 1.51, and bool::then_some is available on nightly.

Actually, bool::then() became stable in 1.50:
https://blog.rust-lang.org/2021/02/11/Rust-1.50.0.html


Fix code scanning alert - Inclusion of functionality from an untrusted source

Tracking issue for:

[ ] https://github.com/Astraxx04/LearnZ/security/code-scanning/5

Fixed by PR #44


"Color Changing sliders" don't work

What should happen? I only see red or black text on a white background.

I'm gonna close this issue as the sliders section is removed until further notice (and until I have time for that) due to the update that broke  everything related to slides.


Export from back-office does not list UGent promoters / supervisors as UGent for all publications.

Bug description
Export from back-office does not list UGent promoters / supervisors as UGent for all publications.
In front-office, this is correct.
When looking for publications that have not been matched to the right supervisor (in this case https://telefoonboek.prd.rad.ugent.be/nl/people/801000630658), one of our reviewers discovered that the export does not always show the right information.
Steps to Reproduce
Examples:
Record 7902170 = wrong

Supervisor is linked in back-office, as UGent https://backoffice.biblio.ugent.be/publication/7902170?redirect-url=%2Fpublication%3Fq%3D7902170%26sort%3Ddate-updated-desc&show=contributors
Supervisor is shown in front-office https://biblio.ugent.be/publication/7902170
Supervisor is not shown in export of back-office

Other records that are wrong:

5843089
4337021

Record 8575126 = correct

Supervisor is linked in front-office https://biblio.ugent.be/publication/8575126
Supervisor is linked in back-office https://backoffice.biblio.ugent.be/publication/8575126?redirect-url=%2Fpublication%3Fq%3D7902170%26sort%3Ddate-updated-desc&show=contributors
Supervisor is shown in export of back-office

Other records that are correct:

01GXB99J92KG4JX0Q02YJHV3P5
01GXBAB0KAYFFPJBYWCR1TJWSX
8575126
8577555

Additional context

Records that have been edited recently are usually correct.
Records that have not been edited recently, with following information seem to be incorrect:

"System update 10 months ago. Legacy"
"Last edit 10 months ago by Peter Reyniers."

Sometimes, records without a recent edit that were wrong, have "Rudi Beyaert" as a UGent-author but without the correct IDs.

Example without IDs https://backoffice.biblio.ugent.be/publication/5843085?redirect-url=%2Fpublication%3Fq%3D5843085%26sort%3Ddate-updated-desc&show=contributors

Example with IDs https://backoffice.biblio.ugent.be/publication/8575126?redirect-url=%2Fpublication%3Fq%3Dbeyaert%26sort%3Ddate-updated-desc&show=contributors

Also has to do with outdated information in the contributor list of the biblio-backoffice.
In this case, the contributor has an id (and therefore recognized) as an ugent member,
but the ugent_id is not in the list. Manually editing this will assign live data and "fix" this.
See also that new grpc command that should update all of these outdated records.
The biblio frontend is correct because it adds this information from the authority table person (based on the id),
even if the biblio-backoffice does not store it.

How do we move on from here @nicolasfranck? Is the gRPC command ready soon?

@mietcls the commando is ready, and probably already deployed (right @nics ?) to production, but it is a command to be executed manually. It introduces a lot, lot of changes, something we were waiting for?

@nicolasfranck can we plan this next week on Monday at 10:00, so I can let GISMO know in time?

What does this mean @nicolasfranck? I cannot log in on that link. When I export that record, it looks like the UGent supervisors have been exported as UGent supervisor – as expected.
I've ran some tests, it looks good. I do notice some people are labelled external in the back-office that should have been UGent, but they just have not been flagged as UGent by the person editing the record.

never mind, did read it wrong


Add further examples for valid Cucumber files to pretty-print

Summary
Following up on the changes for cucumber/gherkin-utils#4, via cucumber/common#1725 and cucumber/common#1985, we're still missing some key areas of improvement for pretty-printing, in which I'd be hesitant to recommend folks use this until they're resolved - or at least we better document what "expected" behaviour is.

Details

Motivation and Context
See above summary.

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

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

Checklist:

[x] The change has been ported to Java.
[ ] The change has been ported to Ruby.
[ ] The change has been ported to JavaScript.
[ ] The change has been ported to Go.
[ ] The change has been ported to .NET.
[ ] I've added tests for my code.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have updated the CHANGELOG accordingly.

CC @nddipiazza @aslakhellesoy

Just raising this for visibility, be great if either of you fancies picking this up :pray:

@jamietanna thanks for this contribution! We're migrating the code for gherkin-utils into a separate repo (https://github.com/cucumber/gherkin-utils)
Would you mind making this same PR against that repo? I don't think I have the power to transfer it for you unfortunately.

@jamietanna Should this be moved into gherkin-utils ? As this will be integrated into Spotless, some additional users would encounter these limitations.

Yes, feel free to - I'm unfortunately not going to be able to get round to this - happy to share some more examples from my library that may be of interest, where there's a few more of the complex examples that we should handle

Dine in https://github.com/cucumber/gherkin-utils/pull/20
I may have a look if you have other specific broken cases.


Populate user name fields in Django users from Azure AD

Is it possible to populate the first and last name fields in Django from the users Azure AD name?
Is there a way to ensure new Django users are not automatically made staff members on the site?

Thanks for pointing this out. A new version has been released with new commits.
ref:

I added two new fields for the last_name and first_name (auth_utils.py):
--def get_django_user(email, create_new=True, is_staff=True): ++def get_django_user(email, create_new=True, is_staff=True, first_name="", last_name=""):
And then in the callback funtion in views.py:
user = get_django_user(email=ms_user.get("mail") or ms_user.get("userPrincipalName"), first_name=ms_user.get("givenName"), last_name=ms_user.get("surname"))


Build alternative Script Builder - directly build the fem file

As all info is available I should be able to parse a simple .fem file myself.
Benefit: No need for the slow tcl executing process

done  - was rather successful


Remove all Admin Legacy preview functionality

Previews from Admin Legacy are no longer used and need to be removed.
There is functionality to enhanceYouTubeVideoLinks, but manually testing this, it doesn't seem to be replacing anything, could be due to how we are rendering the preview panel.
Either way, these files are not included in application.js so isn't included in the asset bundle to go to production anyways, hence currently doesn't seem to have any use.
https://trello.com/c/r8eG9T6o/2240-remove-bootstrap
⚠ This repo is Continuously Deployed: make sure you follow the guidance ⚠
Follow these steps if you are doing a Rails upgrade.

Have tested the Youtube Link embedding on integration - this change does not seem to affect the rendering of Youtube Videos on the frontend, but maybe raises a question of whether or not we should be doing the same embedded video rendering upon preview.
Regardless, this change does not affect anything in that aspect.


Bug Report: adding new datasource not possible in UI

Expected Behavior
It should be possible to add a new datasource in Grafana.
Current Behavior
The API Key needs to be in UUID format. Even then when pressing "save&test" in Grafana it results in a "502 Bad Gateway" error.
Relevant log output
No response
Steps to Reproduce

Install the stack
Add a new customer in yaml with using

customers:
   testcustomer: testKey
3. create a new datasource and press "save&test"

### Context (Environment)

This is required to use a different MQTT topic instead of factoryinsight and to access the data.

### Possible Solution

_No response_

### Version

v0.8.x

### Anything else?

_No response_

only works when additionally (not exclusevly!!!) specifying
dashboards: {}
  dashboardsConfigMaps: {}
  datasources:
    datasources.yaml:
      apiVersion: 1
      datasources:
      - access: proxy
        editable: false
        isDefault: false
        jsonData:
          apiKey: $FACTORYINSIGHT_PASSWORD
          apiKeyConfigured: true
          customerId: $FACTORYINSIGHT_CUSTOMERID
          serverURL: http://united-manufacturing-hub-factoryinsight-service/
        name: umh-datasource
        orgId: 1
        type: umh-datasource
        url: http://united-manufacturing-hub-factoryinsight-service/
        version: 1
      - access: proxy
        editable: false
        isDefault: true
        jsonData:
          apiKey: ddddddddddddddddddddddd
          apiKeyConfigured: true
          customerId: ddddddddddddddd
          serverURL: http://united-manufacturing-hub-factoryinsight-service/
        name: umh-datasource-dddddddddddd
        orgId: 1
        type: umh-datasource
        url: http://united-manufacturing-hub-factoryinsight-service/
        version: 1

@JeremyTheocharis I can't find the yaml key "customers", so i can't replicate this issue

@JeremyTheocharis I can't find the yaml key "customers", so i can't replicate this issue

You should replicate it even without. To fix it you can add this key, which is not in the yaml by default.


how to user embedded config-server with secrrity

Dear spring-cloud team:
I use embedded config-serve in my config-client,everything works as expected but security。I add  spring-boot-starter-security  in my pom.xml. And I configure  security.user.name, security.user.password  and  coressponding  spring.cloud.config.username , spring.cloud.config.password, but when I start up my project,any endpoint need me to input username and password。I don't know where I had a mistake, so please help my,thank you~。
the following is my bootstrap.properties:
spring.application.name=edu-fin-api
spring.application.index=${random.uuid}
management.security.enabled=false
server.port=8299
spring.cloud.config.server.bootstrap=true
spring.rabbitmq.host=<IP_ADDRESS>
spring.rabbitmq.port=5672
security.user.name=user
security.user.password=123

the following is my bootstrap.yml:
encrypt:
    key: key1
spring:
  cloud:
     config:
       server:
         git:
           uri: git@gitmylab.365ime.com:liuxiang/springcloud-config-server.git
           search-paths: /**
           basedir: /data/${spring.application.name}
           clone-on-start: true
          prefix: /ime-config
          encrypt:
            enabled: false
       label: master
       username: user
       password: 123

of course,Once security is added, all requests must carry user and password.You can remove security.It seems wrong to see the information you've written.

I am a little confused .Why would Config Client's endpoint  be protected ? Can you submit a project which reproduces the issue you are talking about.

@indraneelb1903 If is't not protected,everyone can get properties,and use /decrypt endpoint to decrypt the value.It's not safe。

Can u post a minimal verifiable sample which reproduces the issue you are talking about.

@a561066192 look me sample

@bingbingll I suppose you are a chinese?how can i contact with you and so i can communicate with you in chinese to show this issue.

@bingbingll  here is a sample . https://github.com/a561066192/embedded-config-server.git

@indraneelb1903  here is a sample . https://github.com/a561066192/embedded-config-server.git

252356745 qq 明天可以联系
发自网易邮箱大师
On 7/12/2018<EMAIL_ADDRESS>wrote：
@bingbingll I suppose you are a chinese?how can i contact with you and so i can communicate with you in chinese to show this issue.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Thanks , I will try to take a look today.

Is this still an issue after looking at the sample?

If you use spring.cloud.config.server.bootstrap=true (which is missing in your bootstrap.yml example) in your config, you do not need Security, because with spring.cloud.config.server.bootstrap=true  an embedded config server with no endpoint will start. And attention, don't use  @EnableConfigServer in your code, this will switch on the Config Server endpoints.
And Security can switched off by removing the dependency spring-boot-starter-security. So remove maven/gradle dependency spring-boot-starter-security . After that you can also remove obsolete username/password properties.

But if I do not use @EnableConfigServer, how can I refresh my config when the application is running?
发送自 Windows 10 版邮件应用
发件人: moerker
发送时间: 2018年9月26日 22:30
收件人: spring-cloud/spring-cloud-config
抄送: a561066192; Mention
主题: Re: [spring-cloud/spring-cloud-config] how to user embeddedconfig-server with secrrity (#1078)
If you use spring.cloud.config.server.bootstrap=true (which is missing in your bootstrap.yml example) in your config, you do not need Security, because with spring.cloud.config.server.bootstrap=true an embedded config server with no endpoint will start. And attention, don't use @EnableConfigServer in your code, this will switch on the Config Server endpoints.
And Security can switched off by removing the dependency spring-boot-starter-security. So remove maven/gradle dependency spring-boot-starter-security . After that you can also remove obsolete username/password properties.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

To update the config, you can restart the application with embedded ConfigServer or use Spring Boot Actuator (Dependency springframework.boot:spring-boot-starter-actuator) and needed to be enabled via management.endpoints.web.exposure.include=refresh in the local application.properties. If properties have now been changed, with a simple curl localhost:8080/actuator/refresh -d {} -H "Content-Type: application/json" the application can be triggerd to reload the config.

I will try it and thank you very very much！
On 09/27/2018 15:57, moerker wrote:
To update the config, you can restart the application with embedded ConfigServer or use Spring Boot Actuator (Dependency springframework.boot:spring-boot-starter-actuator) and needed to be enabled via management.endpoints.web.exposure.include=refresh in the local application.properties. If properties have now been changed, with a simple curl localhost:8080/actuator/refresh -d {} -H "Content-Type: application/json" the application can be triggerd to reload the config.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Closing this due to inactivity. Please re-open if there's more to discuss.


DocsArchive-<IP_ADDRESS>Auto archive content

Please don't merge this PR until target archive repo PR https://github.com/OPS-E2E-PPE/docs-archive-test-target_3062e40f-5da5-4445-858c-b386eb5fadbb/pull/1 is merged into live branch.
Auto archive content to https://github.com/OPS-E2E-PPE/docs-archive-test-target_3062e40f-5da5-4445-858c-b386eb5fadbb.git

Docs Build status updates of commit 5d76f3b:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error]

Cannot sync git repo to specified commit because branch Archive_master_2019-10-11-13-33-43 has been deleted or has been force pushed: fatal: Couldn't find remote ref Archive_master_2019-10-11-13-33-43

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


Mitaka nfp 03 june 2016

Observed the following error in ATF run. This is unrelated to the changes and also observed on mitaka_21st_march_base branch also. Merging this code.


Error running posh-git when GitHub is not installed

When I open Console2 with posh-git, it says,

Resolve-Path : Cannot find path 'C:\Users{username}\AppData\Local\GitHub\shell.ps1' because it does not exist.
At D:\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1:1 char:16

. (Resolve-Path <<<<  "$env:LOCALAPPDATA\GitHub\shell.ps1")

Do I have to install GitHub for Windows to use posh-git? Or is it an entirely unrelated problem?

Fixed after commenting out the first 2 lines in the profile script and reinstalling poshgit.


Some weird lines with CRN files

Reported on IRC today by @sweet235.
JPEG:

CRN:

I noticed it with other textures in the past, on my end the glitch changes with the distance.
The bug is there since years. I suspect a bug in the mipmapping code.
The mipmap images are already part of the CRN file. When I convert CRN to DDS with crunch (that I assume to only change the container, not recompress the file), and load the DDS in GIMP, I see no issue in the precomputed mip-map images. So I assume this is a bug in our renderer.

Forcing a specific mipmap level (no interpolation) might help identify the issue.

Using Forlorn's floor texture as my testbed, I tried the 0.52.1 engine with recent assets and the bug was there. But 0.52.1 engine with 0.52.1 assets does not have the bug. So this suggests the possibility of an asset pipeline bug.
It does seem to be specific to certain mip levels. Setting various values of r_picmip or r_imageMaxDimension resulted in either the lines going away, or becoming bigger (due to lower resolution).

So this suggests the possibility of an asset pipeline bug.

This seems to be the case. I see similar lines with for textures/shared_ex_src/light2. When I convert the corresponding 5 png images to crn using crunch commit 4c4a009, the lines disappear.

I discovered a cvar r_exportTextures which causes the engine to dump all images it loads, including all mip levels, as KTX files. I tested with a 256x256 floor texture which looks the same as the one from OP screenshot (but the map was Forlorn). When opened in a KTX viewer program, the 128x128 mip level shows several black lines, and the 32x32 level shows one.

So every 16 texels it seems like.

From dev channel:

simply re-converting form png to crn fixes this
So I suppose we can close this as not-an-engine-bug.

Yes, I have a full-asset rebuild on my end and I can't reproduce the bug anymore.


2.12 build: replace harrah/browse with sbt/sxr

the latter receives light maintenance, the former is abandoned
(I discovered the latter only after putting together the changes in https://github.com/harrah/browse/pull/27)

@eed3si9n I'm going to close this ticket as not worth the effort unless/until sxr maintainers or community start actively supporting Scala 2.12


Vue 2 support

What problem does this feature solve?
Continue to create safe and secure applications with Vue 2.x
What does the proposed API look like?
I've seen the statements and the roadmap here:
https://github.com/vuejs/vue/projects/6#card-16117796
https://v2.vuejs.org/lts/
I have a large application made with Vue 2 and Vuetify 2. I cannot migrate the application until Vuetify 3 components are ready and mature. I'd like to request to continue support for Vue 2 till the ecosystem is ready to allow migration. The migration is a long and expensive process. Clients don't like buggy applications. Being a small startup, we can't afford to lose the market.
Can I know if you will be able to extend the support for Vue 2.x in favor of people who are in similar situation like me?
Thanks,
Gajendra Kashyap

Duplicate


add rbac rule to fix system:serviceaccount:kube-system:default can no…

add rbac rule.

This change is

Coverage remained the same at 44.342% when pulling da76b1199247bff2f393d83784ac2e23440e0251 on shenyu1997:master into 26fccdc48b5a218d7c6f084ea526de5e993eb8d8 on kubernetes:master.

cool, this fix my problem.
thanks

Closing. Please reopen when you signed the CLA


Linking to a post that is already linked to another post fails silently

What I did:

Site A

Post 1

Site B

Post 1
Post 2

Link B1 -> A1
Link B2 -> A1

This results in

B2 remains unlinked.
Each time you try this a duplication of the original link B1->A1 appears in the DB:

ml_source_blogid
ml_source_elementid
ml_blogid
ml_elementid
ml_type

2
1
1
1
post

2
1
2
1
post

2
1
1
1
post

2
1
1
1
post

2
1
1
1
post

...
...
...
...
...

I wonder what the solution for this would be?
-Just filter out posts that are already linked from the list of selectable posts.
-Remove the original link and replace it
I think the former makes more sense.

If filtering connected posts out of the list one would need to add this here.
Thinking about it you'd either replace the get_posts call with a custom query or do a separate query earlier for a list of IDs to exclude. Probably the latter.

Thanks for this.
Yes, it seems there is a UI flaw - and we simply shouldn't list remote posts that are already linked to some other post of the current blog.
Just a side note: We already have planned a complete refactor of the Content Relations for the next major release. So, duplicate entries won't be a problem in the future.

On the sidenote: Let me know if I can be of any help there.

Closed with 00ae884f509f2f754ca51da66e5680578cfa5ee2.


Solo Enabler adds Firewall entries, but is not blocking matchmaking.

The issue started around 2-3 days ago. I had not used Solo Enabler for around a week more or less and that last time it was working perfectly.

Seems to have been resolved by returning Firewall settings to Restore Defaults or just clicking on Recommended Settings. Will continue checking if it works with no issues.

Glad you got it sorted out.


feat: Add sea-dark theme

Description
Added new sea-dark theme.
Type of change

[x] Updated documentation (updated the readme, templates, or other repo files)

How Has This Been Tested?

[ ] Tested locally with a valid username
[ ] Tested locally with an invalid username
[ ] Ran tests with composer test
[ ] Added or updated test cases to test new features

Checklist:

[x] I have checked to make sure no other pull requests are open for this issue
[x] The code is properly formatted and is consistent with the existing code style
[ ] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings

Screenshots

I kind of feel the white part seems out of place and would maybe be better with a dark color such as a dark blue or black.
Maybe something like #00546F would look good for the stroke?

Again, up to you. Let me know what you think.

Okay.

Ready.

I don't know why, but after I updated the branch to DenverCoder1/github-readme-streak-stats:main, the Prettier task failed in both pull requests.

Thanks!


Clicking Done on questionnaire should set active question to the first question

Open the questionnaire
Answer every question, clicking Next for each
On the last question, answer and click Done to finish the questionnaire
Observe the "you have new recommendations" alert
Observe that you're taking to the home screen
Click to open the questionnaire again
Observe that you're taken to the last question in the questionnaire
Expected is that you're taken to the first question, since you completed it before.
Acceptance Criteria

[x]  Change behaviour on clicking "Done" on the questionnare, so that next time, the questionnaire opens on the first question

The action to close the questionnaire needs to take the current region as part of its payload, so that the questionnaire reducer can set active question to the first question for the given region.

Alternatively, closing the questionnaire could set the active question to undefined. buildDefaultStore() should then also set active question to undefined. The selector pulling out the questionnaire will then need to get test for active question being undefined, pull the region from the store and initialize the active question to the first question for the region.

questionnaire opens on first question


Is there any plan to get this hosted on https://

Just created a set of great timelines for a new website launched on https:// which now can't embed these over http:// . Any plan to change this?

Not unless someone starts paying us for timemapper maps :-)


Fix style warnings in the webapp extension

This commit primarily fixes the style warnings (azdev style webapp)
upload_source_code parameter list was missing the command param. This commit fixes that.
Another change to functionality is that OneDeploy async deployments don't poll for the operation completion now. This behavior can be toggled for development purposes using the poll_async_deployment_for_debugging flag in code

This checklist is used to make sure that common guidelines for a pull request are followed.

For new extensions:

[x] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your PR is merged into master branch, a new PR will be created to update src/index.json automatically.
The precondition is to put your code inside this repo and upgrade the version in the PR but do not modify src/index.json.

@qwordy  - The failed checks seem unrelated to my PR. Can you check and let me know if they look related to my changes?

@jvano

webapp

@yonzhan  - All PR validations seem to be failing currently with the same errors. Is this being investigated?

@qwordy could you help with above?

/azp run

https://github.com/Azure/Azure-cli/pull/16306
We have a problem recently. It is fixed now.

hi @qwordy is this PR ok to merge now?


Add CNI focussed node-density workloads

Signed-off-by: Sai Sindhur Malleni<EMAIL_ADDRESS>Description
e2e scripts to impleemnt the new kubelet-density workloads in https://github.com/cloud-bulldozer/benchmark-operator/pull/727

@dry923 @rsevilla87 Let me know if there's anything still holding this back please.

need to update this PR with changes proposed here https://github.com/cloud-bulldozer/kube-burner/pull/165


Adding Timelapse GIF to the map

Hi There!
I'm working on  app which enables the user to create timelapse from Sentinel-1 SAR.  When I try to add the gif to the app map, it doesn't show on the existing map, and to show it,  I need to use map.to_streamlit again to show any updates on the map and that generate a new map. So finally, I have two maps: the app map and another map with the gif created.
Is there anyway to add the gif to the map?
Also, after using the geemap.Map method (to_streamlit), the map instance loses all its interactive fuctionalities. I can't add any ipyleaflet controls or any widget control.

Streamlit does not support map bidirectional functionality. The map rendered in streamlit is just a static HTML file. All custom ipyleaflet controls won't show up on the map. If you want bidirectional functionality, try voila. Check out the links below.

https://geemap.org/notebooks/27_timelapse_app/
https://geemap.org/notebooks/28_voila/
https://www.youtube.com/playlist?list=PLAxJ4-o7ZoPccOFv1dCwvGI6TYnirRTg3


MAVSDK -- Import a QGroundControl missions in JSON .plan format.

Hello,
First time working with MAVSDK. Made a flight mission on Q-Ground Control and saved it to the JSON .plan format and want to import it to MAVSDK to run it. I am having trouble on how to approach this. I took a look at the documentation for the MAVSDK-Python docs but am a little stuck here. Any help would be appreciated!
Thank you

Try this: http://mavsdk-python-docs.s3-website.eu-central-1.amazonaws.com/plugins/mission_raw.html#mavsdk.mission_raw.MissionRaw.import_qgroundcontrol_mission

@julianoes Thank you for the suggestion.  Would it resemble something like below? Also what does it take to run the QGC mission plan from mavsdk?
async def import_qgroundcontrol_mission(self, qgc_plan_path):

    qgc_plan_path = 'C:\\Users\\QGC_FLIGHT.plan'

    request = mission_raw_pb2.ImportQgroundcontrolMissionRequest()

    request.qgc_plan_path = qgc_plan_path

    response = await self._stub.ImportQgroundcontrolMission(request)

    result = self._extract_result(response)

    if result.result != MissionRawResult.Result.SUCCESS:
        raise MissionRawError(result, "import_qgroundcontrol_mission()", qgc_plan_path)

    return MissionImportData.translate_from_rpc(response.mission_import_data)

Thanks

I would say that's exactly something that Python async allows you to do, check the docs: https://docs.python.org/3/library/asyncio-task.html#coroutines
I tried it and came up with this, I think that's what you wanted:

task = asyncio.create_task(drone.mission_raw.upload_mission(mission_import_data.mission_items))
print("Mission uploading in background...")
# do something else here...
await task
print("Mission uploaded.")

@kennethakiti1 next time, please create a new issue so that it's easier to find them for others.

sorry would do that thanks

Is there a way to import an strucutre scan .plan? i read in doc that it isn't supported, maybe it isn't updated and there's a feature to do it. If it isn't supported could be good to implement that.

Hi, I am wondering if you are aware that the import function it's NOT currently working as excepted.
I'm currently developing a computer companion module with your SDK and the problem is the following. The system is commanded to load a mission previously acquired through QGroundControl. The mission in question it's really simple, just a few points to go through. The problem arises at the moment the system is commanded to upload the mission, because the error shows the invalid argument description. I researched in this repo the details of this issue and the I encountered that such a problem usually happens when the sequence is bad and/or the current number is more than one in the entire mission. Then I printed the items processed by the SDK and then I found a double zero at the first two items, differents frames that really shouldn't be a problem, current value in the second item, and the param 4 is zero at the first item. The first item apparently is taken from the planned home position of the Qgroundcontrol plan which only has 3 values corresponded to the drone's 3D position. So I'm currently bypassing that first item but I'm looking forward to a solution in this matter.

Qgroundcontrol mission plan:
{
    "fileType": "Plan",
    "geoFence": {
        "circles": [
        ],
        "polygons": [
        ],
        "version": 2
    },
    "groundStation": "QGroundControl",
    "mission": {
        "cruiseSpeed": 1,
        "firmwareType": 3,
        "hoverSpeed": 5,
        "items": [
            {
                "AMSLAltAboveTerrain": null,
                "Altitude": 0,
                "AltitudeMode": 1,
                "autoContinue": true,
                "command": 16,
                "doJumpId": 1,
                "frame": 3,
                "params": [
                    0,
                    0,
                    0,
                    0,
                    -2.1157681120467093,
                    -79.9385202714547,
                    0
                ],
                "type": "SimpleItem"
            },
            {
                "AMSLAltAboveTerrain": null,
                "Altitude": 0,
                "AltitudeMode": 1,
                "autoContinue": true,
                "command": 16,
                "doJumpId": 2,
                "frame": 3,
                "params": [
                    0,
                    0,
                    0,
                    null,
                    -2.1158699615280367,
                    -79.93851893061948,
                    0
                ],
                "type": "SimpleItem"
            },
            {
                "AMSLAltAboveTerrain": null,
                "Altitude": 0,
                "AltitudeMode": 1,
                "autoContinue": true,
                "command": 16,
                "doJumpId": 3,
                "frame": 3,
                "params": [
                    0,
                    0,
                    0,
                    null,
                    -2.116022744157194,
                    -79.93852294714648,
                    0
                ],
                "type": "SimpleItem"
            }
        ],
        "plannedHomePosition": [
            -2.295260803823127,
            -79.7604224,
            0
        ],
        "vehicleType": 10,
        "version": 2
    },
    "rallyPoints": {
        "points": [
        ],
        "version": 2
    },
    "version": 1
}

Thanks for reading and sorry for the trouble.

@igoutta can you please create a new issue and give all the context for me to look into.

Nevermind, that's what you did.


Moved the rendered component into its own div

May not be the cleanest implementation, but seems to keep the styling right and it no longer affects the component. Addresses #33
Also surrounded maxWidth:100% with quotes to remove build error caused by previous patch.

Ok. it was my fault in last PR.

@mnmtanish, Do I need to make any changes to this PR to have it merged?

@jschloer sorry for the delay, I'll merge this PR now.

Published v3.0.10


New feature implementation of writing AAF files from otio files in the AAF adapter

This is an initial implementation of the AAF writer in AAF adapter.
Co-authored-by: Shahbaz Khan<EMAIL_ADDRESS>

This is ready for a review!

Codecov Report

Merging #432 into master will decrease coverage by 0.6%.
The diff coverage is 78.44%.

@@            Coverage Diff             @@
##           master     #432      +/-   ##
==========================================
- Coverage   86.52%   85.92%   -0.61%
==========================================
  Files          66       67       +1
  Lines        6233     6734     +501
==========================================
+ Hits         5393     5786     +393
- Misses        840      948     +108

Impacted Files
Coverage Δ

...neio_contrib/adapters/advanced_authoring_format.py
90.09% <55.55%> (-2.48%)
:arrow_down:

...elineio_contrib/adapters/aaf_adapter/aaf_writer.py
67.94% <67.94%> (ø)

...elineio_contrib/adapters/tests/test_aaf_adapter.py
97.47% <97.86%> (+0.24%)
:arrow_up:

Continue to review full report at Codecov.

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


Prolog-wrapper for the C++ URDF parser.

@daniel86 as discussed last week, here comes the prolog URDF parser. It covers all documented elements of links and joints of an URDF robot. Unit tests and doc-strings are also there.

It seems the master branch is targeting ROS Indigo. I developed the urdf parser for ROS Kinetic. Hence, I will close this pull request, and open a new one targeting the Kinetic branch.


Change namespace form cebe\yii2openapi to phpopenapi\yii2openapi or pertinent

All classes of this lib have namespace cebe\yii2openapi\...
Since the repo https://github.com/cebe/yii2-openapi (archived) is forked to https://github.com/php-openapi/yii2-openapi (this repo, currently maintained), change in namespace is required.
It should be changed to phpopenapi\yii2openapi\... or pertinent.

This is a massive BC break, even though it sounds logical to do that I would prefer not to.


Added new metric ecs_cpu_percent

Added a new metric to compute CPU utilization as a percentage.
This is done along the same logic as in here

In general, exporters should avoid doing calculations like this. Instead, they should provide necessary metrics so that this can be computed in PromQL.

Yes, this is not how things are handled in Prometheus exporters.


Fix Use Case End Not Shown Issue

Codecov Report

Merging #310 (745369f) into master (ffbea57) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #310   +/-   ##
=========================================
  Coverage     70.78%   70.78%
  Complexity      905      905
=========================================
  Files           111      111
  Lines          3632     3632
  Branches        358      358
=========================================
  Hits           2571     2571
  Misses          966      966
  Partials         95       95

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 ffbea57...745369f. Read the comment docs.


[v2] Mysql database table not generating

export const database = {
name: "default",
type: "mysql",
host: "localhost",
port: 3306,
username: "root",
password: "",
database: "test",
synchronise: true
};

Thanks for trying it out and letting us know how you got on! The initial database setup handling - including having to specify synchronise: true on first run - definitely needs work


Changelog and update for 2.1.6.

Current coverage is 91.62%

Merging #989 into master will not affect coverage as of a2f9d99

@@            master    #989   diff @@
======================================
  Files           73      73
  Stmts         4432    4432
  Branches       888     888
  Methods          0       0
======================================
  Hit           4061    4061
  Partial         10      10
  Missed         361     361

Review entire Coverage Diff as of a2f9d99

Powered by Codecov. Updated on successful CI builds.


Switch from BinaryProvider to _jll

This should make test pass on Windows for Julia 1.8

Codecov Report

Merging #25 (1b24258) into master (0341c85) will increase coverage by 0.70%.
The diff coverage is n/a.

:exclamation: Current head 1b24258 differs from pull request most recent head ed227ff. Consider uploading reports for the commit ed227ff to get more accurate results

@@            Coverage Diff             @@
##           master      #25      +/-   ##
==========================================
+ Coverage   29.78%   30.49%   +0.70%
==========================================
  Files           1        1
  Lines         564      564
==========================================
+ Hits          168      172       +4
+ Misses        396      392       -4

Impacted Files
Coverage Δ

src/RNGTest.jl
30.49% <ø> (+0.70%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


build: update shelljs dependencies to "^0.8.5"

Update shelljs dependencies to ^0.8.5 to fix a vulnerability reported to shelljs.

This doesn't merge cleanly to patch. I'll merge it just to master right now and do a manual cherry pick to the patch branch.

Manual cherry pick to patch landed in https://github.com/angular/angular-cli/commit/fc698c6662788f916d7199b59d1b4d65715517ee.


Clair integration

Signed-off-by: liangchenye<EMAIL_ADDRESS>Works in my test: add put/get interface to scan docker v2 image.
TODO:

we need to add a specific clair upstream version to 'Godeps'
take to @ChengTiesheng about the integrate with his work.

And there will be other patches to support:

v1 image
aci image

@MabinGo  Godeps & channel are all added, works in my test :)

FYI @Quentin-M

@liangchenye  Thanks, LGTM


How to Change Layout to Custom Rails Template?

I'm trying to make app/views/layouts/application.html.erb the default layout container. I see this is done here: https://github.com/modeset/apitome/blob/master/lib/generators/apitome/install/templates/initializer.rb#L20
However, this...
config.layout = 'app/views/layouts/application.html.erb'
... does not seem to work:
ActionView::MissingTemplate at /
Missing partial apitome/docs/_head with {:locale=>[:en], :formats=>[:html], :variants=>[], :handlers=>[:erb, :builder, :raw, :ruby, :coffee, :jbuilder]}. Searched in:
  *<EMAIL_ADDRESS>  * "/Users/jcursi/Sites/vault/app/views"
  *<EMAIL_ADDRESS>  *<EMAIL_ADDRESS>
What is the proper entry for this config key? Thanks!

I think you'd just want to change it to "application".

@jejacks0n okay, that seems to be the correct way to call the application layout. However, application.html.erb has references to other partials (i.e. header, footer) to help build out the overall template, and it seems like Apitome can't load those?
For example, it contains a reference as such: <%= render partial: 'head' %> which is causing this error: Missing partial apitome/docs/_head


Hungarian translation of title template, headings, labels

Summary
Add Hungarian (hu) translations of title template, headings, labels, etc for locale code hu.
Potential Contributors
Only the StatConfig.py needs to be modified to implement this. Look for a comment block that has a list of steps necessary to contribute a locale. Start by creating a fork. Then create a branch in your fork for the new feature.
Please don't edit the README with the new locale code, despite the Pull Request template requesting that documentation is updated. Changes to the README automatically go live in the GitHub Marketplace listing for the action. I'll take care of updating README with the new locale code in the list of locales when I create the release that contains it to ensure that documentation is consistent with latest release.

I would like to work on this issue as I'm a native Hungarian speaker, could you please assign it to me?


Np/ma tracking

This commit was meant to incorporate the tracking methodology from "Towards Practical Large-Scale Randomized Iterative Least Squares Solvers through Uncertainty Quantification" by Pritchard and Patel into the library. This tracking method allows for the random blocks to be used for tracking rather than needing to access the entire matrix. The changes that were made to accomplish this were:

LSLogFullMA is a log to store the tracking information.
LSStopMA a stopping criterion for the moving average.
A function get_uncertainty which computes the uncertainty sets.
A function get_SE_constants! computes sub-Exponential  and  parameters for the defined sampling methods. I have not yet done this for the uniform method because I need to still run experiments to determine what the values should be.
LSStopThreshold which stops the solver when a specific threshold is achieved.
Tests for all of these types.
An example for the moving average tracking.

@npritch928 @vp314 I think this would benefit of a new entry in the Manual (Documenter.jl).

@npritch928  I would recommend updating the PR to reflect the name changes that (I believe) were made in the codebase.


new buffer is deprecated

https://github.com/entria/graphql-mongoose-loader/blob/master/src/ConnectionFromMongoCursor.js#L7

done here https://github.com/entria/graphql-mongoose-loader/pull/29


Can you support objective-c

Can you support objective-c

Hello @MengLiMing
Yes, it's in the work right now, it's a main part of 1.2 version.
Sincerely, Alex

This issue was moved to matterinc/web3swift#10

dupe #192

Hello, @MengLiMing
This is outdated repository.
Here is a reference to our public announce, that was deleted:
fd6e78b#diff-04c6e90faac2675aa89e2176d2eec7d8
We are working hard on OBJ-C support. It's almost done in matterinc/web3swift#54

Hello @skywinder have you guys given support for Objective-C? I want to use my own server instead of Geth, Will it be possible in objective-C SDK?


Roll promises are being swallowed by add promises

The recently updated roll and add methods now return a promise, but not all promises are being resolved correctly. I'm seeing issues when trying to add dice on a setInterval timer. This needs some rework

Also easily demonstrable with
Box.roll('3d6').then(()=>console.log('first'))
Box.add('3d6').then(()=>console.log('second'))

Only 'second' promise callback is triggered.

Fixed in version 0.6. Roll and Add both return proper promises and so do Reroll and Remove. I normalized all the return data to be formatted the same. Readme documentation has been updated to explain that more. All four methods can now accept arrays of notations as well, but roll and add are still the only two that accept string notations.


De-incubate useExpectContinue on HttpBuildCache

De-incubating isUseExpectContinue and setUseExpectContinue methods on HttpBuildCache introduced in 7.2

@bot-gradle test qfl

OK, I've already triggered the following builds for you:

QuickFeedbackLinux build

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

LGTM

@bot-gradle test and merge

Your PR is queued. See the queue page for details.

OK, I've already triggered a build for you.


[Don't merge] Feature/update client interface architecture

We should mind it, but not at that time....


(AzureCXP) MicrosoftDocs/azure-docs#88799

The default private zone listed in the doc is  '(New) privatelink.azurewebsites.net.'
However, Data Factory has 2 private endpoints dataFactory and portal.
Each has it default dns zone name
dataFactory - 'privatelink.datafactory.azure.net'
portal - 'privatelink.adf.azure.com'

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

@lrtoyou1223 , Please review the changes .

#label:"aq-pr-triaged"

#signoff

#sign-off

@ShaikMaheer-MSFT: I'm sorry - only the author of this article, @lrtoyou1223, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

189075

#89152

#89152 #101625 #101620 #101624 #101615


[ALLUXIO-3110] Use null pointer analysis to discover potential NPEs in our codebase

https://alluxio.atlassian.net/browse/ALLUXIO-3110
** WIP

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/18780/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/18787/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/18788/
Test FAILed.

Merged build finished. Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/18789/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/18793/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/18800/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/18802/
Test FAILed.

@pavelsimo thanks for taking this improvement! Let me know when this PR is ready for review.

@yupeng9 Sure, I am still missing couple of errors from the module core-common.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/18869/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/18886/
Test FAILed.

@yupeng9  @aaudiber
When you have some time please take a quick look at this initial effort to use the Checker Framework,
I made the module Alluxio Core - Common Utilities compile under the framework checks.
Here are some important highlights of my experience so far:
1.- I was surprised about how easy is to miss an NPE, I see a lot of value of adding this framework to the Alluxio code base.
2.- I encounter some problems with checkstyle while trying to use @Nullable over arrays (e.g. bytes[]),
I suppress using @SuppressWarnings("nullness"), this is a temporal workaround.
3.- I suppressed the constructor initialization errors, The Checker Framework required to explicitly add
a value all member variables in the constructor (-AsuppressWarnings=uninitialized).
4.- At the moment I am not using classes stubs, this are a way of defining a @Nullable annotations for code that is not part of your code base. When the Checker Framework complain about an error in an external library I silent it with the option -AskipUses.
5.- I am excluding all the test code from the Checker Framework tests, as well as alluxio.proto and alluxio.thrift generated code.
6.- It's definetly more work for the developer, some times the Checker Framework give you false positives about some part of the code it's not possible to have a null value, and it's kind of annoying to work around this... In those cases, you need to add assertions telling the Checker Framework that you know better, and please skip the check.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/18890/Build result: FAILURE[...truncated 1531 lines...][JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/protobuf/target/alluxio-core-protobuf-1.8.0-SNAPSHOT.jar to org.alluxio/alluxio-core-protobuf/1.8.0-SNAPSHOT/alluxio-core-protobuf-1.8.0-SNAPSHOT.jar[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/protobuf/target/alluxio-core-protobuf-1.8.0-SNAPSHOT-sources.jar to org.alluxio/alluxio-core-protobuf/1.8.0-SNAPSHOT/alluxio-core-protobuf-1.8.0-SNAPSHOT-sources.jar[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/keyvalue/pom.xml to org.alluxio/alluxio-keyvalue/1.8.0-SNAPSHOT/alluxio-keyvalue-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/pom.xml to org.alluxio/alluxio-parent/1.8.0-SNAPSHOT/alluxio-parent-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/keyvalue/server/pom.xml to org.alluxio/alluxio-keyvalue-server/1.8.0-SNAPSHOT/alluxio-keyvalue-server-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/underfs/oss/pom.xml to org.alluxio/alluxio-underfs-oss/1.8.0-SNAPSHOT/alluxio-underfs-oss-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/client/hdfs/pom.xml to org.alluxio/alluxio-core-client-hdfs/1.8.0-SNAPSHOT/alluxio-core-client-hdfs-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/keyvalue/common/pom.xml to org.alluxio/alluxio-keyvalue-common/1.8.0-SNAPSHOT/alluxio-keyvalue-common-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/checker/pom.xml to org.alluxio/alluxio-checker/1.8.0-SNAPSHOT/alluxio-checker-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/client/fs/pom.xml to org.alluxio/alluxio-core-client-fs/1.8.0-SNAPSHOT/alluxio-core-client-fs-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/common/pom.xml to org.alluxio/alluxio-core-common/1.8.0-SNAPSHOT/alluxio-core-common-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/common/target/alluxio-core-common-1.8.0-SNAPSHOT.jar to org.alluxio/alluxio-core-common/1.8.0-SNAPSHOT/alluxio-core-common-1.8.0-SNAPSHOT.jar[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/common/target/alluxio-core-common-1.8.0-SNAPSHOT-sources.jar to org.alluxio/alluxio-core-common/1.8.0-SNAPSHOT/alluxio-core-common-1.8.0-SNAPSHOT-sources.jar[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/common/target/alluxio-core-common-1.8.0-SNAPSHOT-tests.jar to org.alluxio/alluxio-core-common/1.8.0-SNAPSHOT/alluxio-core-common-1.8.0-SNAPSHOT-tests.jar[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/server/worker/pom.xml to org.alluxio/alluxio-core-server-worker/1.8.0-SNAPSHOT/alluxio-core-server-worker-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/logserver/pom.xml to org.alluxio/alluxio-logserver/1.8.0-SNAPSHOT/alluxio-logserver-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/client/pom.xml to org.alluxio/alluxio-core-client/1.8.0-SNAPSHOT/alluxio-core-client-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/examples/pom.xml to org.alluxio/alluxio-examples/1.8.0-SNAPSHOT/alluxio-examples-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/pom.xml to org.alluxio/alluxio-core/1.8.0-SNAPSHOT/alluxio-core-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/server/proxy/pom.xml to org.alluxio/alluxio-core-server-proxy/1.8.0-SNAPSHOT/alluxio-core-server-proxy-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/shell/pom.xml to org.alluxio/alluxio-shell/1.8.0-SNAPSHOT/alluxio-shell-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/tests/pom.xml to org.alluxio/alluxio-tests/1.8.0-SNAPSHOT/alluxio-tests-1.8.0-SNAPSHOT.pomchannel stoppedArchiving artifacts
Test FAILed.

@yupeng9  @aaudiber Thank you for taking the time to give me some feedback, I will address your comments as soon as possible.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/19021/
Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/19079/Build result: FAILURE[...truncated 1249 lines...][JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/protobuf/target/alluxio-core-protobuf-1.8.0-SNAPSHOT.jar to org.alluxio/alluxio-core-protobuf/1.8.0-SNAPSHOT/alluxio-core-protobuf-1.8.0-SNAPSHOT.jar[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/protobuf/target/alluxio-core-protobuf-1.8.0-SNAPSHOT-sources.jar to org.alluxio/alluxio-core-protobuf/1.8.0-SNAPSHOT/alluxio-core-protobuf-1.8.0-SNAPSHOT-sources.jar[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/keyvalue/pom.xml to org.alluxio/alluxio-keyvalue/1.8.0-SNAPSHOT/alluxio-keyvalue-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/pom.xml to org.alluxio/alluxio-parent/1.8.0-SNAPSHOT/alluxio-parent-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/keyvalue/server/pom.xml to org.alluxio/alluxio-keyvalue-server/1.8.0-SNAPSHOT/alluxio-keyvalue-server-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/underfs/oss/pom.xml to org.alluxio/alluxio-underfs-oss/1.8.0-SNAPSHOT/alluxio-underfs-oss-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/client/hdfs/pom.xml to org.alluxio/alluxio-core-client-hdfs/1.8.0-SNAPSHOT/alluxio-core-client-hdfs-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/keyvalue/common/pom.xml to org.alluxio/alluxio-keyvalue-common/1.8.0-SNAPSHOT/alluxio-keyvalue-common-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/checker/pom.xml to org.alluxio/alluxio-checker/1.8.0-SNAPSHOT/alluxio-checker-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/client/fs/pom.xml to org.alluxio/alluxio-core-client-fs/1.8.0-SNAPSHOT/alluxio-core-client-fs-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/common/pom.xml to org.alluxio/alluxio-core-common/1.8.0-SNAPSHOT/alluxio-core-common-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/common/target/alluxio-core-common-1.8.0-SNAPSHOT.jar to org.alluxio/alluxio-core-common/1.8.0-SNAPSHOT/alluxio-core-common-1.8.0-SNAPSHOT.jar[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/common/target/alluxio-core-common-1.8.0-SNAPSHOT-sources.jar to org.alluxio/alluxio-core-common/1.8.0-SNAPSHOT/alluxio-core-common-1.8.0-SNAPSHOT-sources.jar[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/common/target/alluxio-core-common-1.8.0-SNAPSHOT-tests.jar to org.alluxio/alluxio-core-common/1.8.0-SNAPSHOT/alluxio-core-common-1.8.0-SNAPSHOT-tests.jar[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/server/worker/pom.xml to org.alluxio/alluxio-core-server-worker/1.8.0-SNAPSHOT/alluxio-core-server-worker-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/logserver/pom.xml to org.alluxio/alluxio-logserver/1.8.0-SNAPSHOT/alluxio-logserver-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/client/pom.xml to org.alluxio/alluxio-core-client/1.8.0-SNAPSHOT/alluxio-core-client-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/examples/pom.xml to org.alluxio/alluxio-examples/1.8.0-SNAPSHOT/alluxio-examples-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/pom.xml to org.alluxio/alluxio-core/1.8.0-SNAPSHOT/alluxio-core-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/server/proxy/pom.xml to org.alluxio/alluxio-core-server-proxy/1.8.0-SNAPSHOT/alluxio-core-server-proxy-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/shell/pom.xml to org.alluxio/alluxio-shell/1.8.0-SNAPSHOT/alluxio-shell-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/tests/pom.xml to org.alluxio/alluxio-tests/1.8.0-SNAPSHOT/alluxio-tests-1.8.0-SNAPSHOT.pomchannel stoppedArchiving artifacts
Test FAILed.

Build finished. Test FAILed.

Build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/19081/Build result: FAILURE[...truncated 1249 lines...][JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core-protobuf/1.8.0-SNAPSHOT/alluxio-core-protobuf-1.8.0-SNAPSHOT.jar[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core-protobuf/1.8.0-SNAPSHOT/alluxio-core-protobuf-1.8.0-SNAPSHOT-sources.jar[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-keyvalue/1.8.0-SNAPSHOT/alluxio-keyvalue-1.8.0-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-parent/1.8.0-SNAPSHOT/alluxio-parent-1.8.0-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-keyvalue-server/1.8.0-SNAPSHOT/alluxio-keyvalue-server-1.8.0-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-underfs-oss/1.8.0-SNAPSHOT/alluxio-underfs-oss-1.8.0-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core-client-hdfs/1.8.0-SNAPSHOT/alluxio-core-client-hdfs-1.8.0-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-keyvalue-common/1.8.0-SNAPSHOT/alluxio-keyvalue-common-1.8.0-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-checker/1.8.0-SNAPSHOT/alluxio-checker-1.8.0-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core-client-fs/1.8.0-SNAPSHOT/alluxio-core-client-fs-1.8.0-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core-common/1.8.0-SNAPSHOT/alluxio-core-common-1.8.0-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core-common/1.8.0-SNAPSHOT/alluxio-core-common-1.8.0-SNAPSHOT.jar[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core-common/1.8.0-SNAPSHOT/alluxio-core-common-1.8.0-SNAPSHOT-sources.jar[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core-common/1.8.0-SNAPSHOT/alluxio-core-common-1.8.0-SNAPSHOT-tests.jar[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core-server-worker/1.8.0-SNAPSHOT/alluxio-core-server-worker-1.8.0-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-logserver/1.8.0-SNAPSHOT/alluxio-logserver-1.8.0-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core-client/1.8.0-SNAPSHOT/alluxio-core-client-1.8.0-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-examples/1.8.0-SNAPSHOT/alluxio-examples-1.8.0-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core/1.8.0-SNAPSHOT/alluxio-core-1.8.0-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core-server-proxy/1.8.0-SNAPSHOT/alluxio-core-server-proxy-1.8.0-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-shell/1.8.0-SNAPSHOT/alluxio-shell-1.8.0-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-tests/1.8.0-SNAPSHOT/alluxio-tests-1.8.0-SNAPSHOT.pomchannel stoppedArchiving artifacts
Test FAILed.

@aaudiber @yupeng9 PTAL, thanks!

@pavelsimo any updates on this PR?

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/19352/Build result: FAILURE[...truncated 1178 lines...][JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/protobuf/target/alluxio-core-protobuf-1.8.0-SNAPSHOT.jar to org.alluxio/alluxio-core-protobuf/1.8.0-SNAPSHOT/alluxio-core-protobuf-1.8.0-SNAPSHOT.jar[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/protobuf/target/alluxio-core-protobuf-1.8.0-SNAPSHOT-sources.jar to org.alluxio/alluxio-core-protobuf/1.8.0-SNAPSHOT/alluxio-core-protobuf-1.8.0-SNAPSHOT-sources.jar[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/keyvalue/pom.xml to org.alluxio/alluxio-keyvalue/1.8.0-SNAPSHOT/alluxio-keyvalue-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/pom.xml to org.alluxio/alluxio-parent/1.8.0-SNAPSHOT/alluxio-parent-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/keyvalue/server/pom.xml to org.alluxio/alluxio-keyvalue-server/1.8.0-SNAPSHOT/alluxio-keyvalue-server-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/underfs/oss/pom.xml to org.alluxio/alluxio-underfs-oss/1.8.0-SNAPSHOT/alluxio-underfs-oss-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/client/hdfs/pom.xml to org.alluxio/alluxio-core-client-hdfs/1.8.0-SNAPSHOT/alluxio-core-client-hdfs-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/keyvalue/common/pom.xml to org.alluxio/alluxio-keyvalue-common/1.8.0-SNAPSHOT/alluxio-keyvalue-common-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/checker/pom.xml to org.alluxio/alluxio-checker/1.8.0-SNAPSHOT/alluxio-checker-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/client/fs/pom.xml to org.alluxio/alluxio-core-client-fs/1.8.0-SNAPSHOT/alluxio-core-client-fs-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/common/pom.xml to org.alluxio/alluxio-core-common/1.8.0-SNAPSHOT/alluxio-core-common-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/common/target/alluxio-core-common-1.8.0-SNAPSHOT.jar to org.alluxio/alluxio-core-common/1.8.0-SNAPSHOT/alluxio-core-common-1.8.0-SNAPSHOT.jar[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/common/target/alluxio-core-common-1.8.0-SNAPSHOT-sources.jar to org.alluxio/alluxio-core-common/1.8.0-SNAPSHOT/alluxio-core-common-1.8.0-SNAPSHOT-sources.jar[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/common/target/alluxio-core-common-1.8.0-SNAPSHOT-tests.jar to org.alluxio/alluxio-core-common/1.8.0-SNAPSHOT/alluxio-core-common-1.8.0-SNAPSHOT-tests.jar[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/server/worker/pom.xml to org.alluxio/alluxio-core-server-worker/1.8.0-SNAPSHOT/alluxio-core-server-worker-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/logserver/pom.xml to org.alluxio/alluxio-logserver/1.8.0-SNAPSHOT/alluxio-logserver-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/client/pom.xml to org.alluxio/alluxio-core-client/1.8.0-SNAPSHOT/alluxio-core-client-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/examples/pom.xml to org.alluxio/alluxio-examples/1.8.0-SNAPSHOT/alluxio-examples-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/pom.xml to org.alluxio/alluxio-core/1.8.0-SNAPSHOT/alluxio-core-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/server/proxy/pom.xml to org.alluxio/alluxio-core-server-proxy/1.8.0-SNAPSHOT/alluxio-core-server-proxy-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/shell/pom.xml to org.alluxio/alluxio-shell/1.8.0-SNAPSHOT/alluxio-shell-1.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/tests/pom.xml to org.alluxio/alluxio-tests/1.8.0-SNAPSHOT/alluxio-tests-1.8.0-SNAPSHOT.pomchannel stoppedArchiving artifacts
Test FAILed.

@yupeng9  Sorry for the delay in this PR...
@aaudiber

About disabling the Checker for quick iteration: I was thinking to make the Checker Framework optional by using a Maven profile, This way we can work in applying the Checker Framework to other modules without affecting the build. What are your thoughts?

About the @Initialized checking: at the moment, not all the @Initialized errors can be silenced, for example calling a class member method from a constructor, for those, I am using warning suppressions.

About avoiding the usage of @SuppressWarnings("nullness"): Agree, at the moment there are just four @SuppressWarnings left, almost all related to @Initialized type of errors.

About commenting the usage of assert var != null : "@AssumeAssertion(nullness)": Yes, I will try to add some comments to clarify the usage of those assertions.

@pavelsimo Sounds good. For places that need @SuppressWarnings it would be good to include a comment to help people reading the code.
I think the next step is adding comments to the annotations, then updating the JIRA ticket with the null checking guidelines we discussed here

@aaudiber Thank you, I will work on your suggestions, BTW, did you noticed I upgrade the current version of checkstyle?
I ran into some issues while using the Checker Framework to check array nullness together with checkstyle.
Briefly, the Checker Framework support two types of nullness checks for arrays:

@Nullable String[]  - The elements of the array can be null.
String @Nullable []  - The array itself can be null.

In the second case, the current checkstyle version 2.17 reported parsing errors, seems to be related to not supporting the new Java 8 annotations. I wanted to ask you if it's ok to upgrade to the newest version of checkstyle (version 3.0.0)?

@pavelsimo Upgrading to the newest version of checkstyle is good, thanks

Can one of the admins verify this patch?

This PR is pretty old and doesn't seem to have any recent activity. I'm going to close it for now. Please re-open it if you're able to resolve the conflicts.


Feature/swap combine with rxswift

I love this package and need/want to get it working on Linux.
This swap from Combine to RxSwift is a pretty lightweight changeset that facilitates this.
From the discussions it sounds like you may be heading towards going full async/await - which is fine.
But RxSwift is a great step in that direction since it gets us better platform compatibility whilst maintaining a pretty similar API. So by moving to RxSwift we don't make it any more difficult to make the change to async/await when that time comes.

Unfortunately this is a completely different direction to the intended design. The current API will be changing considerably to adopt async/await and will no longer be compatible with something like rxSwift.
What may be possible (later on) is an add-on where we adopt Combine, OpenCombine or RX for those that are more comfortable with those approaches.
However its likely never going to be a design goal for this project I'm afraid.


Eliminate compilation warnings

To solve warning: variable 'res' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized].
How about this PR?
I just wanna use clang to compile the project without warning.

Thank @sunshaoce for contributing!

And thanks for your help.


[eventshub] Allow defining a custom response body for skipped events

This is needed for testing https://github.com/knative-sandbox/eventing-kafka-broker/pull/2374
Signed-off-by: Pierangelo Di Pilato<EMAIL_ADDRESS>
Changes

Allow defining a custom response body for skipped events

/kind enhancement

/cc @matzew @egorlepa

/cherry-pick release-1.6


Installing Frigate integration does not add it to available integrations

Version of the custom_component
 Frigate Custom Component v2.2.2. HA core core-2022.4.7 - Supervisor supervisor-2022.04.0
Configuration

Add your logs here.

Describe the bug
A clear and concise description of what the bug is.
after installing integration via HACS, restart HA, Configuration - Add integration : No frigate integration available
Debug log

No entries related to Frigate in log file
Add your logs here.

****

You likely need to use ctrl + F5 or CMD + R (depending on computer) to hard refresh the browser then it will be there

Indeed that did the trick ! Thank you so much Nick !

Refreshing the browser (Edge) did the trick!