loop-break-value (issue #961)

This is the culmination of recent discussion in issue #961, minus discussion about extensions to for/while/while let (for which there is no clear solution).

Rendered

Btw, I have a scary macro that mostly implements this as well as labeled blocks, in case you want to play around.

Considering the fact that println!("{:?}", panic!()) type-checks, do we really want to require break's expression to converge? AFAIK, diverging expressions are literally allowed everywhere else.

for and while may need something like Python's for-else structure. That could be another RFC I suppose.

@notriddle good point; I have no idea.
@upsuper: already discussed a lot; explicitly not part of the RFC

I think that the requirement for EXPR in break EXPR; to converge, as stated in the RFC text, is unnecessary. Like @notriddle said, the expressions in Rust work even without such requirements, so changing that would be a complication.

break value should be behaving exactly like return value, except producing a value for a loop rather than a function. return break break return break up (please, continue) should therefore compile (presuming a suitable function up and variable please), just as return return return return return works fine now.
I look forward to this compiling:
fn main() {
}

struct X;
type B = Result<(X), (X)>;  // That signature looks scary.
const please: () = ();
macro_rules! escape { ($x:expr, $y:expr) => (()); }
fn out(_: (), _: ()) { }
const now: B = Ok(X);

fn attempt_escape() -> B {
    'prison: loop {
        if break out (please, continue) {
            escape! (oh, yeah?)
        } else {
            return now :(
            // You got caught. Maybe next time you should try wearing cool sunnies like this:
            B)
        }
    }
}

I like this improvement a lot.
Ruby is also an expression-oriented language and allows break EXPR. Even though I don't use the feature all that often in Ruby, it's pretty easy to remember (it has a good analogue with return) and makes code terser without a loss in clarity when it's useful.
I especially like the fact that this is a nice improvement to an existing expression form with minimal and intuitive new syntax.
Like the original issue thread, I have some concerns with other extensions, and am glad this RFC split out just break EXPR so it could be evaluated on its own.

I'm basically 👍 on this. Limiting to loop makes sense to me, at least initially.

Nice. I'm still watching this but from what I gather no changes are needed to the RFC?

Wrong button!

Note that break (0, 0); currently parses as a call. (Result of break expression is called as a function with two arguments.) This RFC will change the parse. Not a big problem, since it can be handled exactly like return (0, 0);.

The result of break expression isn't callable, is it? So even if it parses differently, it won't compile.

@notriddle Correct. It'll be a "type must be known in this context" problem.

I'd like to propose we move this RFC to final comment period (note that there is a change to the RFC acceptance process here to get more consensus from the team before moving to FCP).
Summary: this RFC proposes letting loops take values which are produced by break. That allows loops to be treated as expressions rather than statements. This is a fairly minor change with a small but significant benefit. Response has been positive, but not overwhelming. There are no major sticking points worth highlighting. There is a minor point of uncertainty around divergence, which I expect is affected by the recent acceptance of the !-is-a-type RFC.
I propose moving to FCP with an inclination to accept.
@rust-lang/lang members, please check off your name to signal agreement. Leave a comment with concerns or objections. Others, please leave comments. Thanks!

[ ] @nikomatsakis
[x] @nrc
[ ] @aturon
[ ] @eddyb
[ ] @pnkfelix (on vacation)

@nrc the point of uncertainty around divergence was regarding a prior draft of the RFC, wasn't it? That is, I thought that before d6e1594 people were concerned about a requirement that all expressions given to break converge, but now that is no longer a requirement -- so, is there still uncertainty about ! ?
(In any case, I'm still going to check my name off, since I'm cool with the RFC a currently written.)

🔔 This RFC is entering its final comment period. 🔔

Any thoughts on inference? Is there a way to explicitly specify the type that loop returns in case the type is difficult to infer; or will we have to do something like
{ let x: MyType = loop { /* ... */ }; x }

That's type ascription. It's not supported yet.

@Thiez I agree that these examples seem to needlessly complex. However, when you imagine loops with multiple break points these types of constructs would be necessary.

@Thiez you're right, those examples can be simplified. I wasn't very familiar with the let x; loop { ... { x = y; break; } } pattern when I wrote the RFC. Contrary to what @JelteF says, the pattern even appears to work with multiple break points (though each "break" requires two lines of code).
let computation;
loop {
    if let Some(r) = self.do_something() {
        computation = r;
        break;
    }
}
let computation = computation.do_computation();
self.use(computation);

This example however won't always work with the current lifetime restrictions, since r may contain a reference to self (hence doing r.do_computation() early; this was one of the examples motivating this RFC).

@Thiez actually, on further thought, there may be examples where it's not possible to move function calls like foo(bar) or r.do_computation() into the loop due to further lifetime restrictions, though I'm not sure how realistic such cases are and in any case non-lexical lifetimes should solve these issues.
So I'm not sure how much motivation for this RFC remains. There is still some syntactic improvement, especially in cases with multiple returns, but this RFC is mostly sugar:
    let x;
    loop {
        ...
        if ... {
            x = v1;
            break;
        } else if ... {
            x = v2;
            break;
        }
    }
    now_do_something(x);

becomes
    let x = loop {
        ...
        if ... {
            break v1;
        } else if ... {
            break v2;
        }
    };
    now_do_something(x);

(where now_do_something(x) remains at the end for sequential clarity).

It is syntactic sugar (I always understood it as such, and never really thought about it as a workaround for lexical lifetimes), but it jives so well with the rest of the language that it seems like it should have been there from the beginning.
p.s. @dhardy's second example isn't just shorter, it's also clearer, since there's no way to know that the first example actually fills x in inside the loop without reading the loop body.

It is syntactic sugar (I always understood it as such, and never really thought about it as a workaround for lexical lifetimes), but it jives so well with the rest of the language that it seems like it should have been there from the beginning.

This is basically how I feel. I've always thought of it as syntactic sugar. Moreover, Rust's currently a very "expression-friendly" language, but a lot of the more imperative constructs are perhaps not as well-integrated as they could be. This RFC seems to help mend that gap a bit in a very natural way.

p.s. @dhardy's second example isn't just shorter, it's also clearer, since there's no way to know that the first example actually fills x in inside the loop without reading the loop body.

There is actually a very easy way to know this: because x is not assigned before the loop, and it is used after the loop, then it must have been assigned inside the loop, or the compiler would reject the code for using a possibly uninitialized variable.

Half the time, I'm reading code to figure out why it's not compiling. If I added another break into a loop, which would you rather see:
Variable may not have been initialized:
    now_do_something(x)
    ~~~~~~~~~~~~~~~~~^

Or this:
Expected break of type `T`, found break of type `()`:
        break;
    ~~~~^

@notriddle good point about error messages, but I suspect that the compiler may not always get the type right. Error messages may be more like:
Expected break types to agree; found break of type `str`:
    break "text";
          ~~~~~^
found break of type `()`:
    break;
         ^

It depends... sometimes the output type may be clear (if typed or passed directly into/out of a function), and sometimes it may not be (e.g. if cast with .into()).

Your hypothetical error message is still better than what unassigned variables give us. It points us at the break statement, which is where the problem is, and it points at another break statement, giving an example of how it should have been written. If the loop is being used in an expression context, a no-brainer heuristic would hint that the unit break is probably the wrong one.
The point is that let x = for { break f(); } is explicit, while let x; for { x = f(); break; } is implicit. The error messages are just this extra, explicit information being exploited by the compiler. Even for human readers, figuring out that a variable must have been assigned inside a loop because it's used right afterward requires the person reading the code to do deductive reasoning, whereas figuring out that a loop is being assigned to a variable directly merely requires someone to read it.

I don't think this should be accepted without having the break statement for while and for as well. Having it for only loop would diverge the construct of all 3 even more.
Mostly, I don't understand why this would be invalid:
while n < value {
   if n == 3 {
       break "3";
    }
} else {
       "default"
}

The RFC states that you need else default but it doesn't make sense as to why you would need the extra keyword.

Lots of people were saying else was not clear wording, read
https://github.com/rust-lang/rfcs/issues/961 for details. Loop would not
need an else/default, so that's why this is not opposed.
On 28 Sep 2016 7:57 am, "Garrett Berg"<EMAIL_ADDRESS>wrote:

I don't think this should be accepted without having the break statement
for while and for as well. Having it for only loop would diverge the
construct of all 3 even more.
Mostly, I don't understand why this would be invalid:
while n < value {
if n == 3 {
break "3";
}
} else {
"default"
}
The RFC states that you need else default but it doesn't make sense as to
why you would need the extra keyword.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rfcs/pull/1624#issuecomment-250078823, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABG8JgjwwXT0CcRADSm3cyfLXVnayk6rks5qugHUgaJpZM4Ijc2V
.

@JelteF thanks, left an idea to use !break instead of else

@vitiral For practical purposes, given the (very) long-standing impasse on the syntax to use with while and for, your position amounts to "I don't think this should be accepted". If that's really what you think, then OK.

@glaebhoerl unless we could resolve those conflicts in that thread -- I think loop break values is a useful feature to have, I just don't want the different loop constructs to start diverging.

@vitiral @glaebhoerl is this a suitable solution?
Separate question: is it sufficiently related to integrate into this RFC, potentially delaying the loop case? (I propose: yes, unless there is still significant disagreement over syntax.)

No it's not worth delaying any more. It's been 2 years (?) since this was first proposed.

I think I am for this RFC provided that it has a flag to not be stabilized until the for and while implementations are also finished. Putting it in nightly to get data on the usefulnes is good I think, but I think it would be a mistake to release this without all the loop constructs having this functionality (there shouldn't be special cases).

@dhardy See my earlier comment. I think any of those are fine by me if they work technically and are acceptable to others.

I just don't want the different loop constructs to start diverging.

They're already different. loop {} is the only construct that can be recognized as diverging (it evaluates to ! when there's no break statement). It can also evaluate to () when there is a break statement in it. while and for always evaluate to () no matter what.

Putting it in nightly to get data on the usefulnes is good I think, but I think it would be a mistake to release this without all the loop constructs having this functionality (there shouldn't be special cases).

loop is inherently a special case; it is the one loop structure where the compiler understands that the loop body will execute at least once, so you can do this:
let x;
loop {
    x = 5;
    break;
}
println!("{}", x);

but not this:
let x;
while true {
    x = 5;
    break;
}
println!("{}", x);

I think Java solves this by special-casing while (true) in the compiler.

So I was just about to approve this RFC, but @aturon mentioned he has some concerns. Therefore, I want to try and move this onto the RFC-bot process and start the FCP over. =)
@rfcbot fcp merge

@rfcbot I ❤ you.

@rfcbot concern Cost/benefit and tail calls
As I've chewed on this RFC over time, I've gotten increasingly uneasy. While in general I'm open to syntactic sugar and conveniences, they do come at some complexity cost for the language, and thus should be justified by fairly widespread benefit (and should fit into the language as smoothly as possible).
My specific concerns here are:

There's a very reasonable encoding in terms of delayed let binding, as others have pointed out. While this encoding is slightly harder to follow, the let x; form gives a very clear heads up. I'm just not 100% sure this bit of sugar winds up helping that much.

While I agree with @nikomatsakis that the RFC moves us further in the direction of expression-orientation, it feels like an "incomplete" move, since the change only applies to loop and not our other looping constructs. This is also a source of complexity with the sugar, making the feature somewhat more obscure and introducing edges for its use.

This sort of loop is very naturally encoded via tail recursion; if we ever get tail call optimization, I would probably prefer to right such loops via tail recursion -- making this feature perhaps even more niche?

Overall, I'm sympathetic, but I worry that we have a limited total budget for syntactic sugar, and there are a lot of purchases we might want to make.

Yes, tail recursion is normally the nicer way to express this sort of thing.

There's a very reasonable encoding in terms of delayed let binding, as others have pointed out. While this encoding is slightly harder to follow, the let x; form gives a very clear heads up. I'm just not 100% sure this bit of sugar winds up helping that much.

This is also true for many other cases, including if, match, and unadorned block. The big advantages are in the composability (I can put a loop in the terminal position of an if branch and have the break value just propagate out) and the explicitness (it's not a guess; I know the value is coming from the loop).

While I agree with @nikomatsakis that the RFC moves us further in the direction of expression-orientation, it feels like an "incomplete" move, since the change only applies to loop and not our other looping constructs. This is also a source of complexity with the sugar, making the feature somewhat more obscure and introducing edges for its use.

If you think you can resolve the default value :bike: :house: then be my guest.

This sort of loop is very naturally encoded via tail recursion; if we ever get tail call optimization, I would probably prefer to right such loops via tail recursion -- making this feature perhaps even more niche?

I actually agree with that. If and when we get TCO then I'll consider this use case solved and just relegate loops to the niche situations.

@aturon The issue I have with that is "if we ever get tail call optimization". It seems unlikely to happen in the near (or medium term) future... And, also, imho, let x = loop {...} is much more readable.

Pick between this:
fn factorial(n: u64) {
    become factorial_(n, 1)
}
fn factorial_(n: u64, acc: u64) {
    if n == 0 { acc }
    else { become(n - 1, acc * n) }
}

And this:
fn factorial(mut n: u64) {
    let mut acc = 1;
    loop {
        if n == 0 { break acc }
        acc *= n;
        n -= 1;
    }
}

p.s. I know that the second example works with return instead of break.

@aturon

This sort of loop is very naturally encoded via tail recursion; if we ever get tail call optimization, I would probably prefer to right such loops via tail recursion -- making this feature perhaps even more niche?

I don't really consider tail calls an alternative. For one thing, while of course it's technically true that any loop can be rewritten using a fn, it's not a trivial rewrite in many cases, and which construct "feels right" depends (I think) on the example. In my opinion the actual competitor to this feature is iterators: most of the time that I want to carry a value out of a loop, it's something that I would prefer to write using an iterator chain with an explicit call to next (to get the first item produced). And I think people should do that, it's more explicit. :)
For another, tail calls are actually significantly more complex to add to the language. You have to figure out the interactions with destructors and the C ABI, neither of which play particularly nice with tail calls (destructors because they frequently add "extra" computation after the tail-call, the C ABI because it has the caller allocate space for arguments, so the tail call must use the same amount of stack space). We probably need a new keyword (be).
Still, I don't see this feature as a must have in any respect. I like it because I feel like Rust has gone about 90% of the way in terms of unifying exprs/statements and this seems to push us to 92% (arbitrary statistics, of course, not measuring anything real). I like this unification so going a bit further doesn't bother me. To me it makes the language feel just a bit more rounded.

Overall, I'm sympathetic, but I worry that we have a limited total budget for syntactic sugar, and there are a lot of purchases we might want to make.

Yes, so: I don't see this as a major ergonomics hurdle or something that will boost productivity in particular. Certainly if I have to pick, I would not take this RFC over the things in that thread.
Really the question then is: do we have to pick? I wasn't really viewing this as "syntactic sugar", at least not any more than if cond { v } else { w } is. Basically, when you learn Rust you learn that many things you are accustomed to seeing as statements can be used as expressions. Currently, that set does not include loops. If we take this RFC, that set will include loop (but not while or for).

@aturon

it feels like an "incomplete" move

So if this RFC had a provision that it would not actually be implemented until a design had been accepted and implemented for the remaining looping constructs (with the benefit that those RFCs would not need to re-hash the motivation for doing this) you would be in favour? Or implemented, but behind a feature flag and not stabilised until the other loops were implemented too? It seems an unnecessarily high bar to require a complete design to be accepted in one go.

Just noticed two reasons  let = loop { .. } might be more competitive with delayed let bindings than I first though : First, a delayed let binding need not be mut, which rocks, but actually seems kinda subtle.  Second, loop does not exist in most imperative languages anyways, limiting confusion.

I would be interested in an analysis of how many times people currently use the let some_var; loop { ... some_var = some_value; break; } pattern. How many instances of 'loop { ... }` would even benefit from this sugar?

Yeah right now Rust (and MIR), for better or worse, makes a big distinction between inter- and intra-procedural control flow. On one hand, from a functional background this seems ludicrously arbitrary, on the other hand it's great for compilation (not having to recover first-order control flow, explicitness about what is a machine level "function").
Guaranteed tails calls (this is, strictly speaking not an optimization because the programmer is requiring constant space) would be a big step towards unifying inter- and intra-procedural control flow, and for those reasons above may or may not be good. The alternative is "expression-orient goto", which is basically the same thing but only for intra-procedural control flow and thus obviates concerns about calling convention, destructors, unwinding, etc.
I plan (when, no idea), write an RFC for the latter, "Goto Considered Harmless". At that point, it should be clear that all our looping constructs are skeuomorphisms to lure stodgy C programmers, so there's no aesthetic loss hot-rodding those constructs with more sugar.

For implementing catch a useful pattern might be 'name: { ... break 'name value; ... default }.

@aturon:

There's a very reasonable encoding in terms of delayed let binding

This same argument could be applied to our other structural expressions too - why allow let x = if ...  or match when you can do the let x; thing? It seems this RFC is a move towards uniformity in that respect.

it feels like an "incomplete" move, since the change only applies to loop and not our other looping constructs.

I somewhat agree with this one. I was much happier about this RFC when it was applied to other kinds of loops too. I had hoped we could use the value of the last iteration as the value of the whole loop, but I can see that might be confusing (although, it matches the underlying semantics of break, I believe. Perhaps also back compat concerns?).
Anyway, the way I see this is that there is a set of expressions which are void and a set which take the type of a sub-expression. This is simply moving one expression from the first set to the second. Although one might assume all 'looping' constructs work the same, that is not true, for example of all 'branching' constructs (e.g., if vs if ... else).

This sort of loop is very naturally encoded via tail recursion; if we ever get tail call optimization, I would probably prefer to right such loops via tail recursion -- making this feature perhaps even more niche?

I'm not sure whether this will be true or not. Even with tail recursion, using let x = loop ... feels more Rusty than a recursive function (which feels more like an FP solution). I also share the concerns voiced by others that tail recursion is not even on the horizon at the moment, so seems like a poor reason to delay.

Overall, I'm sympathetic, but I worry that we have a limited total budget for syntactic sugar, and there are a lot of purchases we might want to make.

I don't think that this is true. Whilst I think it makes sense sometimes to think of 'complexity' (however that is defined) in terms of a budget, I think syntactic sugar is much less fungible. It has costs of course, but these are usually very local - we worry about obfuscating semantics etc. in one area,rather than in the language as a whole (obvs, this is a simplification and there is some global interaction, but it is a smaller factor, I think). I think that none of the other sugar/ergonomics proposals touch on control flow in a way that is very similar to this proposal, and so I don't think this proposal would cause us to pass on those others.

I had hoped we could use the value of the last iteration as the value of the whole loop, but I can see that might be confusing

The issue here is that if the loop runs 0 times, there is no last iteration. A proposed solution was to make the type of such loops be Option, but this breaks loops which are currently in tail position, where their types need to be (). And then you're wading into the murk of either fudging it by making the type of the loop depend on whether it contains a break-with-value or a similar "solution", or instead having an additional else clause to provide the default value, but of course not called else because that is highly confusing to approximately 50% of people, but one of the other imperfect possibilities, and so on and so on in https://github.com/rust-lang/rfcs/issues/961.

This is syntactic sugar of the least-harmful kind. While this feature has low value, I don't see any strong reason not to include it.

@nrc:

I had hoped we could use the value of the last iteration as the value of the whole loop, but I can see that might be confusing (although, it matches the underlying semantics of break, I believe. Perhaps also back compat concerns?).

I think the biggest problem with that supposed semantics is that it is ill-defined for the case when a loop has zero iterations.
(Maybe we could find some way to distinguish for loops that guarnatee > 0 iterations by adding some new trait AtLeastOnce: Iterator, so then you could apply that semantics to both for and loop, but you would still be left with while and while let ...)

IMO the only reasonable way of supporting returning a value from a for or while loop is with the for ... else ... syntax where the else clause is only executed if the loop terminated normally (as opposed to a break). Then all you need to do is ensure that the type of the breaks is the same as that of the else clause.
This therefore leaves us with only two options: either only support returning a value for loop, or add else to for and while.

It uses existing keywords, it makes sense, and it has precedent in other languages. It's also wildly controversial at the moment but that hopefully will change once this lands and becomes popular.

I'm not convinced tail-call recursion has much to offer the argument for or against this RFC: Rust is a hybrid language allowing users to program with both functional and imperative features, however they are comfortable. Additionally, sometimes it is not convenient to use a function due to many variable/constant bindings from the current scope being in use.
(@Ericson2314's comment regarding Goto I don't fully understand but sounds intriguing.)
@pnkfelix I really do not like the sound of an AtLeastOnce trait (extra complexity in syntax & in iterators, and you still have to handle the usual case where iterators are not guaranteed to be non-empty).
@Amanieu please see issue 961, there is considerable opposition to simply using the else keyword.
I left for and while out of the RFC since there is no clear consensus, but if it helps with closure on this RFC, my current favourite is Gabor's suggestion:
for elem in elems {
    if pred(elem) {
        break elem
    }
} else {
    break default_value()
}

@Ericson2314

It uses existing keywords, it makes sense, and it has precedent in other languages. It's also wildly controversial at the moment but that hopefully will change once this lands and becomes popular.

I would also like to point out that for ... else is significantly better supported in a language like rust, where it will be used (mostly) to return values and will be much more clear. In python, the use case is much more rare, but in rust -- where the expression can be used to return a value -- it will be much more in sync with how if ... else works

@vitiral you can't tell people how a feature must be used — for sure it would sometimes get used that way. But having a break keyword there does help. I think the above example should have semi-colons terminating the break ... lines:
for name in suggest_names() {
    if like(name) {
        break name;
    }
} else {
    let last_resort = random_name();
    break last_resort;
}

The else does look a little weird here, though the break at the end is a clue as to the purpose. I can't personally tell what proportion of users would find this syntax confusing.

@dhardy I agree that break should have a semi-colon at the end (just like return). However, for clarity I am saying that it would be typically used like this:
let x = for name in suggest_names() {
    if like(name) {
        break name;
    }
} else {
    let last_resort = random_name();
    last_resort // no `break` necessary for else, just like `for ... else`
}

My argument that this is the way it would typically be used is because this is how patterns like this are typically used in rust. The for ... else in python is hardly used and is somewhat confusing precisely because it doesn't return any values.
Some have issues with for ... else because they think that it should work like so:
while x < 10 {
    // do stuff normally, break not required
} else {
    // do stuff here if the while loop was never entered
    // (i.e. if x was already < 10)
}

In other words, it could be replaced with:
if x < 10 {
    while x < 10 {
        // do stuff normally
    }
} else {
     // do stuff here if the while loop was never entered
}

However, this alternate implentation cannot make sense if break must return a value. If break returns a value, then clearly the else clause in while ... else must have something to do with break and nothing to do with whether or not the while loop was never entered.
There is much more ambiguity around what while ... else could do in python. In rust, that ambiguity wouldn't exist.

@vitiral interesting point. But the RFC states that break (); is equivalent to break;, and as I understand it the return value of a statement ending ; is (), so if there is no break in the else block, the Python-esque for ... else ... with no break or return value would be completely legal (I think).
Besides, sometimes side-effects are much more important than return values. TBH I don't understand the Python ambiguity problem very well since it always seemed clear to me (yes, in Python).

the return value of any statement ending in ; is (), so you could write:
for name in suggest_names() {
    if like(name) {
        print!("{}", name);
        break;
    }
} else {
    let last_resort = random_name();
    print!("{}", last_resort);
}

So you don't need a break in the else clause (just like you don't need one in if ... else even though that can return a value)
for ... else with no break value would not be legal in rust, since the for block would not have a return value. This is good, as for ... else without break makes no sense at all -- else would always get executed (assuming you didn't return or panic).

Would it be better if finally (obviously this is open to bikeshedding) was used instead of break? This makes it clearer that this block is only executed if no break occurred in the loop.
let x = for name in suggest_names() {
    if like(name) {
        break name;
    }
} finally {
    random_name()
};

@Amanieu do you mean use finally instead of else? No, I think that would be even worse. For one thing, in python finally means "execute me no matter what".

I'd like to know from the people who object to just using for {} else {} etc on the basis that it's confusing, whether using another keyword instead of else would solve the problem for them, or whether they'd still find it confusing?
If not, there's no point bike-shedding further on alternative names. The choices involving Option or some variation thereof seem to be flawed, so it's a simple choice between else or nothing.

I'm still very pro my suggestion of using !break. I think it really
simply shows the meaning of the second block. Without even reading the loop
body (and seeing that values are being returned with break).
On 3 Oct 2016 11:09 pm, "Diggory Blake"<EMAIL_ADDRESS>wrote:

I'd like to know from the people who object to just using for {} else {}
etc on the basis that it's confusing, whether using another keyword instead
of else would solve the problem for them, or whether they'd still find it
confusing?
If not, there's no point bike-shedding further on alternative names. The
choices involving Option or some variation thereof seem to be flawed, so
it's a simple choice between else or nothing.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rfcs/pull/1624#issuecomment-251227946, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABG8Ju5D5W2cQu0XkSMTYNnKKVJxtV-Cks5qwW8dgaJpZM4Ijc2V
.

Something like the last 10 comments (I didn't count) are reinventing or rehashing ideas, and then the objections to them, almost verbatim from the other thread. Nicely illustrating, if anyone needed it, why that feature was deliberately left out of this RFC.

@rfcbot resolved Cost/benefit and tail calls
I've been persuaded that, on the whole, this RFC moves the language toward greater uniformity, and that in particular proper tall calls are not necessarily a better choice. Let's do it!

🔔 This RFC is entering its final comment period. 🔔

I just created a new issue to discuss other implementation details for returing from for and while than the the name of keywords. This issue can be found here for other people that are interested: https://github.com/rust-lang/rfcs/issues/1767

Just noticed this slightly confusion loop that is not a loop :
let x = 'a loop {
    ...
    if foo { break `a bar; }
    ...
    break `a baz;
};

It's obvious doing this with a closure would be more readable, but that's frequently true for loops too, if one had tail call optimization, so..
Is it desirable to support a less confusing form of this?
let x = 'a {
    ...
    if foo { break `a bar; }
    ...
    baz
};

If so, does continue work in such a block?  I presume no.

@burdges That's the orthogonal (but synergistic) "break from any block" feature, I'm surprised I can't find any existing issue or RFC for it. cc @Ericson2314?

@glaebhoerl I don't think anybody wrote an RFC but we've both brought it up many times (e.g. ? And catch). Maybe it will finally stick :).

@burdges this would not be backwards compatible. If I had code like:
loop {
    // do something
    {
        let foo = Bar();
        if x == foo {
            break;
        }
    }
}

currently this would break out of the loop block, but if we implemented your code it would break out of the inner block (and the loop would continue). I also don't like making break into a kind of goto (even though it often fulfills that role). If we want something like a generalized goto we should reserve a word for it and implement it separately rather than overload break

It's obviously "break from named blocks" @vitiral not literally "break from any block", so no compatibility issues.  I donnot if it's a good idea or not, just thought it might be worth asking.

RFC has been merged!
Further discussion should happen on the tracking issue.


Selenoid UI VNC connection lost after upgrade to 1.4.0

Hello, after upgrade selenoid UI to v 1.4.0, VNC session is lost.
To help you clearly understand the problem I have recorded screencast
https://youtu.be/DiBCDj1kA_4

@SergeyPirogov could you try with aerokube/selenoid-ui:latest?

The issue is gone. Tried to restart selenoid and selenoid-ui. After that, it became to work normally.

Good, closing?


unroll to unitary gate if unitary is in basis

Summary
When the Unroller pass encountered a gate which did not exist in the basis and had no definition, it would raise an error. This PR makes it possible to allow these types of gates if they have a unitary matrix representation and unitary is in the basis, such as for a simulator.
Details and comments

Since this is somewhat of an unusual use case this can probably on hold at this time.


permission template not found

Descriptive summary
App generated by engine_cart gets permission template not found error when saving a GenericWork.
Expected behavior
To be able to save a work.
Actual behavior
Error when saving a work.
Steps to reproduce the behavior

clone hyrax
rake engine_cart:clean
start rails server in .internal_test app
Works -> New Work
Fill in required metadata and add a file
Save

Gets error:  Couldn't find Hyrax::PermissionTemplate
Related work
The same happens when you generate a hyrax app following the README instructions.

I'm hoping there is something off in my environments, or there is a setup step that is missing.  Anyone else seeing this?

Steps to create a hyrax app that got rid of this error...

Install prerequisite software including nodejs or some other javascript runtime
run rails new with template
if using rubyracer for javascript runtime, uncomment in Gemfile and bundle install  (Not needed if using nodejs.  No gem needed for nodejs.)
start servers (solr, fedora, message queue) - several options for message queue, see doc
load workflows with rake hyrax:workflow:load
create default admin set with rake hyrax:default_admin_set:create
NOW - generate a work type
start server and everything should work

@elrayle
I had to run step 6 before step 5 to load the workflows. Can you confirm that and change the steps accordingly?

That makes sense to me, @tap87

NOTE: If doing local testing, replace step 2 with rake engine_cart:generate which creates .internal_test directory with a test app.
If you have made changes and want to regenerate the test app, run rake engine_cart:clean before running generate.


Azure function v2 compatibility

Hello,
Do you plan to implement compatibility with azure functions v2 ?

Hello,
Microsoft changed completely the way to integrate with Azure Functions which do not produce API definitions anymore. That was already a hard work to get it done for v1, now I'm afraid that I won't be able to adapt. I'll have a look but do not count too much on it.
Thanks
Best Regards

Hello,
I have checked and that's kind of a nightmare so I guess, I won't implement it, sorry!
Best Regards


Handle warning on rebar3 over ssl_verify_fun's missing .app description

Any chance this gets merged and tagged?

Any chance this gets merged and tagged?

I was expecting you to merge it as soon as you found it convenient. Aren't these libs (this one, lhttpc, ...) under our collective maintenance? :)


New version: DiffEqCallbacks v2.11.0

Registering package: DiffEqCallbacks
Repository: https://github.com/JuliaDiffEq/DiffEqCallbacks.jl
Created by: @ChrisRackauckas
Version: v2.11.0
Commit: 9f17830b6232f816de0fcdf7132d7eebff66dd5d
Reviewed by: @ChrisRackauckas
Reference: https://github.com/JuliaDiffEq/DiffEqCallbacks.jl/issues/63#issuecomment-572355376

There are all saying it's unable to load since there's a specific order all of these would have to go in, but was all double checked locally so in the interest of time, instead of doing them 1-1, I'm just going to merge them.


[ACS][Communication][Chat] 2024-03-15-preview public preview API spec

Data Plane API - Pull Request

This PR includes previously approved features:

Data retention feature https://github.com/Azure/azure-rest-api-specs/pull/22858 (changes reverted because release date is pushed back)
Image upload feature https://github.com/Azure/azure-rest-api-specs/pull/25697 (approved but not merged because release date is pushed back)

API Info: The Basics
Most of the information about your service should be captured in the issue that serves as your API Spec engagement record.

Link to API Spec engagement record issue:

Is this review for (select one):

[ ] a private preview
[x] a public preview
[ ] GA release

Change Scope
This section will help us focus on the specific parts of your API that are new or have been modified. Please share a link to the design document for the new APIs, a link to the previous API Spec document (if applicable), and the root paths that have been updated.

Design Document: https://microsoft.sharepoint-df.com/:w:/t/IC3SDK/Eb1TFJ62ixxLoMqgZYNGbiYBG54egqfVHF_2u9u4FFNqWA?e=g7XqHl
Previous API Spec Doc: https://github.com/Azure/azure-rest-api-specs/pull/25697
Updated paths:

Viewing API changes
For convenient view of the API changes made by this PR, refer to the URLs provided in the table
in the Generated ApiView comment added to this PR. You can use ApiView to show API versions diff.
Suppressing failures
If one or multiple validation error/warning suppression(s) is detected in your PR, please follow the
Swagger-Suppression-Process
to get approval.
❔Got questions? Need additional info?? We are here to help!

 Contact us!
The Azure API Review Board is dedicated to helping you create amazing APIs. You can read about our mission and learn more about our process on our wiki.

💬 Teams Channel
💌 email

Click here for links to tools, specs, guidelines & other good stuff
Tooling

Open API validation tools were run on this PR. Go here to see how to fix errors
Spectral Linting
Open API Hub

Guidelines & Specifications

Azure REST API Guidelines
OpenAPI Style Guidelines
Azure Breaking Change Policy

Helpful Links

Azure DevTools Wiki

Checks stuck in `queued` state?
If the PR CI checks appear to be stuck in `queued` state, please add a comment with contents `/azp run`.
This should result in a new comment denoting a `PR validation pipeline` has started and the checks should be updated after few minutes.

fix https://github.com/Azure/azure-rest-api-specs/issues/25607

You need to fix the ModelValidation errors as well.

Sorry that got closed. Seems I hit some key sequence accidentally that closes GitHub issues. 😬

/pr Requestmerge

/pr RequestMerge


[$250] Android-Room-After creating room, entering @ not showing contact suggestions

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 1.4.77-0
Reproducible in staging?: y
Reproducible in production?: n
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4585586
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause internal team
Slack conversation:
Action Performed:

Launch app
Tap fab -- start chat
Create a new room
Enter @ and wait few seconds
Navigate to LHN
Navigate to room again
Keep cursor after @

Expected Result:
After creating room, entering @ must show contact suggestions
Actual Result:
After creating room, entering @ not showing contact suggestions but shown on revisit.
Workaround:
unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence
https://github.com/Expensify/App/assets/38435837/73cbaa42-be63-4c4e-a7d3-51d38cba2924

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~016d65d15eadf82bb4
Upwork Job ID:<PHONE_NUMBER>903484928
Last Price Increase: 2024-05-29
Automatic offers:

alitoshmatov | Reviewer | 102529959
ishpaul777 | Contributor | 102529960

Issue OwnerCurrent Issue Owner: @jliexpensify

FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

We think that this bug might be related to #vip-vsb

hmm the site has been pretty slow most of the day, if this relies on a network request that could explain it. or is it pretty consistent that first time @ is type nothing is triggered?

hmm okay was able to reproduce on android only. it doesn't look like you have to create a new room. i'm able to consistently reproduce by just going into any existing room and trying typing @. if i leave and go back into the same room then @ triggers the list of members to show up.

i think the code for this is roughly these components https://github.com/Expensify/App/blob/1490cecd7e099fe41052b2b8d4463ec94eb036ec/src/pages/home/report/ReportActionCompose/ReportActionCompose.tsx#L433
https://github.com/Expensify/App/blob/main/src/pages/home/report/ReportActionCompose/SuggestionMention.tsx
https://github.com/Expensify/App/blob/main/src/pages/home/report/ReportActionCompose/Suggestions.tsx
I don't really see any recent changes in those files though.
There are these 2 PRs that had changes to the ReportActionCompose.tsx component but neither stand out to me as the root cause
https://github.com/Expensify/App/pull/42180
https://github.com/Expensify/App/pull/42615

Issue is no longer reproduced after revert https://github.com/Expensify/App/pull/42843.
https://github.com/Expensify/App/assets/93399543/4949f773-0e5d-4e3e-8f19-ba3b4c3d715e

@jliexpensify going to assign to you to double check and make sure payments are sorted.
I think we only really need to pay @ishpaul777 here, @alitoshmatov wasn't online so didn't get a chance to really dive in and review anything. @puneetlath and @ishpaul777 basically worked through everything ❤

Thanks for the heads up! In that case, lets unassign @alitoshmatov from this issue.
Payment Summary

C+: @ishpaul777 $250

Upwork job

Hmm not overdue, right? Waiting for it to be deployed?

Can I apply for this job? Thanks

There were no Android-specific changes between<EMAIL_ADDRESS>and 0.1.76 so I have no idea what could have caused this regression.

I quote Skalakid comment.

After a quick investigation I found out that the live markdown parser is using a different commit of expensify-common than E/App.

After a quick investigation I found out that the live markdown parser is using a different commit of expensify-common than E/App. Live Markdown parser uses a newer version of ExpeniMark that contains changes that block blockquote creation without space after

I will create PR that bumps the version in the Expensify App
I pulled the latest main and E/App has a newer version of expensify-common than live markdown. I can't reproduce this issue now

Maybe with the latest version of expensify-common and react-native-live-markdown the issue will not reproduce anymore. I will verify this on Monday (unluckily now I have other commitments). Thanks

Thanks @tomekzaw and @fabOnReact let me know if you need anything from me.

I tested and I can not reproduce this issue anymore.

There wasn't an actual regression here right? Also, what's the original PR? Melvin hasn't updated the date so just want to check everything has been deployed.

PR - https://github.com/Expensify/App/pull/42843
Will pay out today, confirmed with Bondy no checklist needed.

Paid and job closed.


Button "Connection with twich"

Hello, I am a beginner of Laravel.
I would like to create a "Connect with Twich" button. The goal is to retrieve the twitch id and twitch username of the user who wants to connect.
I followed your documentation but I cannot create my controller using your code.
I have correctly set the "clientid", "clientsecret", "redirect" information.
Can you explain the procedure to me in detail?
I work with Laravel 8.
Thank you so much.

If you're using Laravel to authenticate users through Twitch, you should use Laravel Socialite with the Socialite Twitch Provider.
I would not recommend to implement it yourself using this library if you're a beginner.

Hello.
Thank you very much for your advice !


Update develop with Release v1.1 changes

The PR from main -> develop showed the same 27 commits with 1 extra commit for the merge commit that resolved the conflicts. This PR has 1 extra commit to resolve the 1 conflict.
The main branch has already been updated to include the changes from release_v1.1, so I added a commit to the release_v1.1 branch to revert the python package versions in setup.py to use relative versions instead of the exact versions used for the release. That change is reflected in this PR.
Expected Differences

[X] Do these changes modify the system output in any way? [No]

Pull Request Testing

[X] Describe testing already performed for these changes:
N/A
[X] Recommend testing for the reviewer(s) to perform, including the location of input datasets, and any additional instructions:

Review changes in case there are any changes that shouldn't be merged into develop.

[X] Do these changes include sufficient documentation updates, ensuring that no errors or warnings exist in the build of the documentation? [Yes]

[X] Do these changes include sufficient testing updates? [Yes]

[X] Will this PR result in changes to the test suite? [No]

[X] Please complete this pull request review by 8/1/2023.

Pull Request Checklist

[X] Review the source issue metadata (labels, project, and milestone).
[X] Complete the PR definition above.
[X] Ensure the PR title matches the feature or bugfix branch name.
[X] Define the PR metadata, as permissions allow.
Select: Reviewer(s)
Select: Project
Select: Milestone as the version that will include these changes
Select: Development to link to the original development issue.
[ ] After the PR is approved, merge your changes. If permissions do not allow this, request that the reviewer do the merge.
[ ] Close the linked issue and delete your feature or bugfix branch from GitHub.

@georgemccabe - Will we delete release_v1.1 branch after this is complete then? Just want to make sure we don't have issues down the road if we needed to do something with this release and the branch is still there but without the static versions. If we needed a bug fix, we would just create a new release branch for that bug fix version off of main branch then, right?

@fossell, we shouldn't need the release branch anymore. The branch was actually automatically deleted by GitHub after I merged the release_v1.1 -> main pull request. I had to click the restore button to get it back for the next pull request into develop.
If we need to apply a bugfix, we would create a bugfix branch off of main.

@hahnd - Will take a quick look and approve too?


Support MapType in FFI

Which issue does this PR close?

Closes #2037.
Rationale for this change

What changes are included in this PR?

Are there any user-facing changes?

cc @sunchao


Unable to SSH into server (Invalid Password)

Hi,
I'm trying to SSH into my linux server and it's giving me incorrect password.
It's correct as iTerm lets me in no dramas, and I tried putting in the password 8 times.
Am i doing something wrong?
Running: ssh<EMAIL_ADDRESS>

Does it contain any special characters? It might be related to https://github.com/shockone/black-screen/issues/351

Nope no special characters. Just abc and 123 on a standard US keyboard

Are you able to enter your password with different commands? I just tried it with sudo (unfortunately, have no server to SSH into) and it worked.

I can do "sudo ls" and enter my password, which works fine. However my mac's password, and my SSH's server is different.
I've noticed when it prompts for a password, the blinking cursor sits on the previous line, and not where it's asking for the password (I'm aware that it doesn't show characters).
Quick update - I updated my servers password to "12345678", works no problems. I tried "apple123" also works. I also tried "APPLEFRUIT", and it doesn't work.  I changed it to "BANANA123" and it also does not work. It seems to be an issue with capitals.

Hopefully all of that helps you!

@joelwmale, could you please verify it works in v0.0.42?

Still does not sadly. I use capitals and numbers. Such as AP12PLE.

Any updates on this issue? I am still having trouble "ssh"ing with passwords that have capital letters 😕


Add an "Edit This Page" on GitHub link

Acceptance Criteria

Display a link at the bottom of each page to make editing and fixing errors easier
The link should take people to the GitHub repo

Bonus Points

Link directly to the page you're editing on GitHub so that people don't need to search the repo

A few things to consider with this one:

I think only users with permissions on the repo will be able to edit files
It will be difficult to check the linting and formatting when editing through the github UI, which will likely lead to failed builds

I am going to close this because of derryks comments


Triple Store implementation design

@Treesarj @quaat @jesper-friis I am unsure about the current triple store implementation.
It is implemented as a Data Cache-like Python class in oteapi-core, but also with a separate endpoint in #97 to fetch data from it.
Unlike the redis service in this repository and the data cache in oteapi-core, this makes the triple store span over both repositories, which I don't think is desireable.
While it might not be desireable, it may also be unavoidable.
Hence, I'd like to go over the design of how the triple store should be implemented again, and possibly update it - hopefully keeping it only in one of the repositories or as an alternative have a clear separation of what is the backend implementation and what is the general CRUD interface to do triple store transactions.

closing this issue because : https://github.com/EMMC-ASBL/oteapi-services/issues/397


Do you have plan to update lastest taquito_local_forging.js for local forging?

Saw that the taquito local forging javascript library has released some newer versions recently: https://www.npmjs.com/package/@taquito/local-forging
Do you have any plan to update the file taquito_local_forging.js in your source code?

@hvthhien thanks for pointing that out, didn't notice. I've just finished the feature I was working on, so i'll have a look at this today. I'll nudge them again to see can I get them to automate producing the mobile friendly JS.  Will be sometime until I cut a new release on main, as currently still producing many breaking changes.
Also posted a link to the new fork of taquito, with the webpack config required to produce the code, on the previous issue I created about this. Hopefully they'll integrate it and make it easier for native mobile: https://github.com/ecadlabs/taquito/issues/441


Achievements broken in right-to-left languages

Hello @nicolas-raoul, I am an outreachy applicant and I want to work on this issue.Could I take this?

@silkypriya Yes, it is yours :-)
Let us know about your progress like every two days at least, thanks!

Hello @nicolas-raoul
Made pull request #2557 fixing this issue.Kindly review.
would love your feedback.
Thank you!


Pod network extra args

Support extra keys in pod network annotation
Acorrding to the de-facto standard documentation-
"All key names that do not include a period character are reserved to ensure this specification
may be extended in the future. Implementations that write keys other than those defined in this
specification must use reverse domain name notation (eg " org.foo.bar.key-name ") to
name the non-standard keys."
This PR extends the NetworkSelectionElement with a key-value map (string->string)
containg the extra, non-stadnard keys passes in the pod network annotation.
(Note - only keys wih a period character are considered as extra keys).
The extra keys and their values are passed to the relevant cni plugin via the CNI_ARGS
environment variable using the following format -
$CNI_ARGS=$CNI_ARGS;key.1=value1;key.2=value2;

Pull Request Test Coverage Report for Build 545

23 of 41 (56.1%)  changed or added relevant lines in 3 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.05%) to 52.373%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

types/conf.go
0
4
0.0%

k8sclient/k8sclient.go
6
12
50.0%

multus/multus.go
17
25
68.0%

Files with Coverage Reduction
New Missed Lines
%

multus/multus.go
1
54.92%

Totals

Change from base Build 539:
-0.05%

Covered Lines:
651

Relevant Lines:
1243

💛  - Coveralls

I change the extra name on the test.
related to https://github.com/containernetworking/cni/issues/608

@SchSeba @AlonaKaplan the spec doesn't say anything about restrictions on the content of the extra args fields. But obviously you can't pass that through environment variables like CNI_ARGS, so this PR doesn't allow things that the spec does allow.
Also, CNI_ARGS is deprecated upstream. You could fix both issues by using the CNI 'args' key in the JSON that gets passed to each plugin via stdin, which is the replacement for CNI_ARGS. That has no restrictions on content because JSON allows values to be escaped.

@dcbw sure I can work on that just to be sure how the args key should look
type DelegateNetConf struct {
	Conf          types.NetConf
	ConfList      types.NetConfList
	...
	// Raw JSON
	Bytes []byte
        Args map[string]string
}

something like that?

@dcbw ping?

@dcbw Some thing like this ?
type NetArgs struct {
	types.CommonArgs
}

so the CNI looks like
{
  "cniVersion": "0.4.0",
  "name": "pci",
  "type": "ovs",
  // type (plugin) specific
  "bridge": "ovs0",
  "vxlanID": 42,
  "ipam": {
    "type": "dhcp",
    "routes": [ { "dst": "<IP_ADDRESS>/16" }, { "dst": "<IP_ADDRESS>/16" } ]
  }
  // args may be ignored by plugins
  "args": {
    "labels" : {
        "appVersion" : "1.0"
    }
  }
}

Example: https://github.com/containernetworking/plugins/blob/fb7a24405e1dfc33bd10be4df5a16609d648db7e/plugins/meta/tuning/tuning.go#L47

Hey,
Im building a NFV platform on top of ovs-dpdk and faucet sdn controller, I need this feature for passing extra attributes to the ovs interfaces..
its possible to get this PR merged?
Thanks

I am not sure how to continue here.
@dcbw @s1061123 can you describe to me how you prefer to implement the extra args field/struct so I can update this PR?

Currently we stop to use environment variable for CNI_ARGS and changed to json cni-args.
https://github.com/containernetworking/cni/blob/master/CONVENTIONS.md#args-in-network-config
And with 'cni-args` option is standardized in spec and multus.
https://github.com/intel/multus-cni/blob/master/types/types.go#L142
https://github.com/k8snetworkplumbingwg/multi-net-spec/blob/master/v1.1/[v1.1] Kubernetes Network Custom Resource Definition De-facto Standard.pdf
Hence I close the issue.


fix(api-v2): Don't allow an invalid cardinality on a boolean property (DSP-1236)

resolves DSP-1236

[x] Don't allow adding an invalid cardinality on a boolean property.
[x] Allow startup even if ontologies are invalid.
[x] Add test.

Thanks for the review!

Thanks for the review!


Gradle refactor

Don't merge yet!
This is a work-in-progress PR currently. I am working towards replicating the pom.xml content entirely, while improving some aspects of the build. Feedback is always welcome!

Coverage increased (+0.08%) to 86.119% when pulling 0f1ce93c34fbf02a6bcf0d0b94941db293d43978 on magneticflux-:gradle-shipkit-refactor into 57e38d08754ab2ec247b06b9e20fc2ef88676218 on magro:master.

@magro Unfortunately, Shipkit only supports publishing to Bintray currently. The good news is that you can still forward builds from Bintray to Sonatype if so desired!


Fixes #30

#30 Closes: #[30]
Added the labels

No of contributors

Issues opened

Issues closed

PRs open

PRs closed

Repo Size

Built By developers

Built with Love

Give a clear description what modifications you have made
Type of change
What sort of change have you made:

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Code style update (formatting, local variables)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Mention any unusual behaviour of your code (Write NA if not)
Any unusual behaviour of your code
N/A
Additional Info (optional)
Any additional information you want to give
Checklist:

[x] My code follows the guidelines of this project.
[x] I have performed a self-review of my own code.
[ ] I have commented my code, particularly whereever it was hard to understand.
[x] My changes generate no new warnings.
[ ] Any dependent changes have been merged and published in downstream modules.

@SHAIMA-HAQUE please fix this issue by the end of the day and also add Built By developers and Built with Love just below the other labels .
If u won't be able to complete by the end of the day , this PR will be closed

Please check if it is alright now

Could you please check now ,sir
I am new to this, so I wanted to ask that I just had to commit the change to my branch ,right?

Could you please check now ,sir
I am new to this, so I wanted to ask that I just had to commit the change to my branch ,right?

yes mam!

Hello @SHAIMA-HAQUE, although the PR is complete as Adash said, but I would like you to squash your commits into a single commit. It's pretty simple:
# here we want to squash 3 commits
git reset --soft HEAD~3

# add changes (BTW they are already staged)
git stage -A

# Add  new commit message
git commit -m "Added labels in Readme.md"

# force push
git push -f origin 30-update-readme

No problem if you can't as we can squash from our side too, it is just a learning opportunity if you don't know already. Also, remember to put only as many commits as the number of absolute changes.

@avinal Thank you so much for letting me know.


Updating 'six package' to latest version.

Pyvalid has an outdated version of dependency package six. This is causing other dependency installations to fail.
tensorflow 2.3.0 requires six>=1.12.0, but you'll have six 1.10.0 which is incompatible.
tox 3.20.0 requires six>=1.14.0, but you'll have six 1.10.0 which is incompatible.
rootpath 0.1.1 requires six>=1.11.0, but you'll have six 1.10.0 which is incompatible.

So version of 'six package' needs to be updated in requirements.txt.

PR has been merged, I'll deploy new version on pypi.
Thanks @ankitagarwal and @Aparna-BS for your help!


Compiler stack overflow with nested lambda functions

Aim
We (https://github.com/FuzzingLabs) found that the compiler ends up overflowing its stack when you nest too many lambda functions.
Expected Behavior
No panic should occur.
Bug
In the given example, after 18 nested lambda functions, the compiler ends up overflowing its stack. 18 was the minimum needed to trigger the overflow with 64GB of RAM. Only lambda functions seem to have this issue. Things like for loops or function calls can be nested as much as desired.
The issue occurs with the latest compiler version on the master branch. The error message is as follows:
thread '<unknown>' has overflowed its stack
fatal runtime error: stack overflow
Abandon (core dumped)

To Reproduce
fn main() {
let lambda = || {
let lambda = || {
let lambda = || {
let lambda = || {
let lambda = || {
let lambda = || {
let lambda = || {
let lambda = || {
let lambda = || {
let lambda = || {
let lambda = || {
let lambda = || {
let lambda = || {
let lambda = || {
let lambda = || {
let lambda = || {
let lambda = || {
let lambda = || {
};
};
};
};
};
};
};
};
};
};
};
};
};
};
};
};
};
};
}

Project Impact
None
Impact Context
No response
Workaround
None
Workaround Description
No response
Additional Context
The computer used has 64GB of RAM. This may impact how many lambda functions are needed to trigger the overflow of the stack.
Installation Method
None
Nargo Version
No response
NoirJS Version
No response
Would you like to submit a PR for this Issue?
None
Support Needs
No response

This compiles on the new parser #6180 so I'm going to close this issue.


[bazel,rust] fix stale anyhow crate version

A stale version for the anyhow crate was causing the util/prep-bazel-airgapped-build.sh script to error out. This fixes the issue by bumping the version.
Signed-off-by: Timothy Trippel<EMAIL_ADDRESS>Note: this depends on #12389. Just review the last commit.

PR dependency removed.

Additionally a RV compliance test bug fix was added to make the bazel build pass.


notion database have Duplicate items

checked "sync when items are modified"
version:0.2.1
Duplicate entries appear in the notion database when documents are moved into the watch folder

Thanks for reporting this, @panyuz. I have a few questions to help me narrow down the cause:

If you modify an item in Zotero, does it create another duplicate in Notion, or does it update an existing one?
Did you happen to delete the Notion link attached to the items in Zotero?
Did you originally sync the items to a different Notion database, or have you always been using the same database?

Zotero status:

I have a folder named "privacy sens", which have 34 items. And all items were synced to notion.
checked "sync when items are modified"
version:0.2.1

If you modify an item in Zotero, does it create another duplicate in Notion, or does it update an existing one?
it update an existing one

Did you happen to delete the Notion link attached to the items in Zotero?
Maybe. I seem to have deleted the notion link for some entries. Not all entries in Notion are duplicated, so I think this should be the main reason for duplicate entries. I will test more

Did you originally sync the items to a different Notion database, or have you always been using the same database?
NO. I always sync to the same database.

Thanks for the additional info, @panyuz.

Maybe. I seem to have deleted the notion link for some entries. Not all entries in Notion are duplicated, so I think this should be the main reason for duplicate entries.

I think this is likely the cause of the issue. The current implementation relies on those Notion links in order to keep track of which Notion page each Zotero item corresponds to. Without that link, Notero ends up creating a new page in Notion rather than updating the existing one.
Let me know if that seems to be what's happening for you!

From a comment on #6:

if you add documents in bulk (5 entries), duplicate entries will still appear. I think it should be emphasized in the usage instructions to avoid such usage.

@panyuz would you mind sharing more about how you added these documents? Did you import 5 PDFs into Zotero? I'd like to see if I can recreate the issue to see if it can be solved. Thanks!

has this been resolved? is there a way for Notion to check for duplicates in a database? thanks!

Hi @domhicks, can you share more about what you're encountering? Is Notero producing duplicate pages in your database? If so, does it happen consistently, or are there certain conditions under which duplicates are created? Thanks!

Hi David,
I was just wondering if it is possible to have the notion database
recognize duplicates in a database so they can be deleted. Thanks!
ᐧ
Am Do., 13. Apr. 2023 um 07:00 Uhr schrieb David Hoff-Vanoni <
@.***>:

Hi @domhicks https://github.com/domhicks, can you share more about what
you're encountering? Is Notero producing duplicate pages in your database?
If so, does it happen consistently, or are there certain conditions under
which duplicates are created? Thanks!
—
Reply to this email directly, view it on GitHub
https://github.com/dvanoni/notero/issues/27#issuecomment-1506348225, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/A67A7JHHQJIMG3HGAN52EQDXA6CAPANCNFSM5LLMYFEA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hi @domhicks! I think it may be possible to build this. I've just pulled it out into a new feature request (#252) so I can keep track of it.

Hi @dvanoni,
My Notero database also has duplicates. See below my answers to your questions:
If you modify an item in Zotero, does it create another duplicate in Notion, or does it update an existing one?
It updates an existing one. Only one of the two get updated
Did you happen to delete the Notion link attached to the items in Zotero?
No I did not
Did you originally sync the items to a different Notion database, or have you always been using the same database?
** Always to the same database**

Any idea how this is possible? Can I just delete the article that does not update when I change something in Zotero?
Also, I would also love a duplates identifier in Notero.

Hi @jchutten, thanks for sharing those details.
I'm not entirely sure how this happens. It could possibly be caused by some sort of network hiccup or a strange timing issue between when items are modified vs synced. Do you remember seeing any error messages as you were syncing items?
And yes, it should be safe to delete the pages in Notion that don't update when you change things in Zotero.
If I come up with an approach for detecting duplicates, I'll be sure to share an update in #252, so please follow along there.


Make clib build reproducible by sorting sources

Summary of changes
Sort sources in build_clib command.
Closes https://github.com/pypa/setuptools/issues/3678
Pull Request Checklist

[ ] Changes have tests
[ ] News fragment added in [changelog.d/].

Hi @danigm thank you very much for the contribution.
Please note that any changes in the setuptools/_distutils directory need to be proposed in the https://github.com/pypa/distutils repository.
Would you like to propose this change to pypa.distutils?

Hi @danigm thank you very much for the contribution.
Please note that any changes in the setuptools/_distutils directory need to be proposed in the https://github.com/pypa/distutils repository.
Would you like to propose this change to pypa/distutils?

Thanks for the info. I've removed that change from the PR, that's not "needed" because the build_libraries method overrides the base class functionality, so it should work as expected just with this change.


RBACPerRoute configuration not working!

Per route RBAC configuration not working.
Description:

Everything looks ok envoy is running but RBAC doesn't work. Here is the configuration.

direct_response:
  body:
    inline_string: Hello world
  status: '200'
match:
  case_sensitive: false
  prefix: "/test"
typed_per_filter_config:
  envoy.filters.http.rbac:
    "@type": type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBACPerRoute
    rbac:
      rules:
        action: DENY
        policies:
          general-rules:
            permissions:
            - any: true
            principals:
            - any: true

Is there something i missed?
Resolution:
This is should be in http filter. Also RBACPerRoute not disable global RBAC for specific route if using direct_response
name: envoy.filters.http.rbac

Hey,
i am facing a similar problem and i cannot get the end of it.
So this is my config right now. My expectation is that all requests on /products will be dropped, unless they are GET requests.
But this doesn't work, and i have tried pretty much everything. It is also funny that i do not get any stats regarding RBAC. It is almost as it would ccompletely ignore my rbac config
Would you please take a look at my config file, maybe i am missing on something.
Thx a lot!
- "@type": type.googleapis.com/envoy.config.listener.v3.Listener
  name: http
  address:
    socket_address:
      address: <IP_ADDRESS>
      port_value: 443
  filter_chains:
  - filters:
    - name: envoy.filters.network.http_connection_manager
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
        stat_prefix: ingress_http
        route_config:
          name: local_route
          virtual_hosts:
          - name: all
            domains:
            - "*"
            routes:
            - name: myroute
              match:
                prefix: "/client"
              route:
                #host_rewrite_literal: www.envoyproxy.io
                cluster: targetCluster
            - name: products
              match:
                prefix: "/products"
              direct_response:
                status: 403
                body:
                  inline_string: "denied\n"
              typed_per_filter_config:
                envoy.filters.http.rbac:
                  "@type": type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBACPerRoute
                  rbac:
                    rules:
                      action: ALLOW
                      policies:
                        "policy1":
                          permissions:
                          - and_rules:
                              rules:
                              - header: { name: ":method", exact_match: "GET" }
                              - url_path:
                                  path: { prefix: "/products" }
                          principals:
                          - any: true
        http_filters:
        - name: envoy.filters.http.router
        access_log:
        - name: envoy.access_loggers.file
          typed_config:
            "@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
            path: /var/log/envoy/envoy-access.log
            json_format:
              timestamp: "%START_TIME(%Y/%m/%dT%H:%M:%S%z)%"
              method: "%REQ(:METHOD)%"
              path: "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%"
              protocol: "%PROTOCOL%"
              response: "%RESPONSE_CODE%"
              response_flags: "%RESPONSE_FLAGS%"
              bytes_rcv: "%BYTES_RECEIVED%"
              bytes_snt: "%BYTES_SENT%"
              duration: "%DURATION%"
              ups_svc_time: "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%"
              x-fwd_for: "%REQ(X-FORWARDED-FOR)%"
              user_agent: "%REQ(USER-AGENT)%"
              req_id: "%REQ(X-REQUEST-ID)%"
              req_authority: "%REQ(:AUTHORITY)%"
              upstream: "%UPSTREAM_HOST%"
              details: "%RESPONSE_CODE_DETAILS%"
              route: "%ROUTE_NAME%"
              source: "%DOWNSTREAM_REMOTE_ADDRESS%"
              orig_source: "%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%"
    transport_socket:
     name: envoy.transport_sockets.tls
     typed_config:
       "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
       common_tls_context:
         tls_certificates:
           certificate_chain:
              filename: /etc/httpd/ssl/wildcard.mydom.com.crt
           private_key:
              filename: /etc/httpd/ssl/wildcard.mydom.com.key```

Hey,
i am facing a similar problem and i cannot get the end of it.
So this is my config right now. My expectation is that all requests on /products will be dropped, unless they are GET requests.
But this doesn't work, and i have tried pretty much everything. It is also funny that i do not get any stats regarding RBAC. It is almost as it would ccompletely ignore my rbac config
Would you please take a look at my config file, maybe i am missing on something.
Thx a lot!
- "@type": type.googleapis.com/envoy.config.listener.v3.Listener
  name: http
  address:
    socket_address:
      address: <IP_ADDRESS>
      port_value: 443
  filter_chains:
  - filters:
    - name: envoy.filters.network.http_connection_manager
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
        stat_prefix: ingress_http
        route_config:
          name: local_route
          virtual_hosts:
          - name: all
            domains:
            - "*"
            routes:
            - name: myroute
              match:
                prefix: "/client"
              route:
                #host_rewrite_literal: www.envoyproxy.io
                cluster: targetCluster
            - name: products
              match:
                prefix: "/products"
              direct_response:
                status: 403
                body:
                  inline_string: "denied\n"
              typed_per_filter_config:
                envoy.filters.http.rbac:
                  "@type": type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBACPerRoute
                  rbac:
                    rules:
                      action: ALLOW
                      policies:
                        "policy1":
                          permissions:
                          - and_rules:
                              rules:
                              - header: { name: ":method", exact_match: "GET" }
                              - url_path:
                                  path: { prefix: "/products" }
                          principals:
                          - any: true
        http_filters:
        - name: envoy.filters.http.router
        access_log:
        - name: envoy.access_loggers.file
          typed_config:
            "@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
            path: /var/log/envoy/envoy-access.log
            json_format:
              timestamp: "%START_TIME(%Y/%m/%dT%H:%M:%S%z)%"
              method: "%REQ(:METHOD)%"
              path: "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%"
              protocol: "%PROTOCOL%"
              response: "%RESPONSE_CODE%"
              response_flags: "%RESPONSE_FLAGS%"
              bytes_rcv: "%BYTES_RECEIVED%"
              bytes_snt: "%BYTES_SENT%"
              duration: "%DURATION%"
              ups_svc_time: "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%"
              x-fwd_for: "%REQ(X-FORWARDED-FOR)%"
              user_agent: "%REQ(USER-AGENT)%"
              req_id: "%REQ(X-REQUEST-ID)%"
              req_authority: "%REQ(:AUTHORITY)%"
              upstream: "%UPSTREAM_HOST%"
              details: "%RESPONSE_CODE_DETAILS%"
              route: "%ROUTE_NAME%"
              source: "%DOWNSTREAM_REMOTE_ADDRESS%"
              orig_source: "%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%"
    transport_socket:
     name: envoy.transport_sockets.tls
     typed_config:
       "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
       common_tls_context:
         tls_certificates:
           certificate_chain:
              filename: /etc/httpd/ssl/wildcard.mydom.com.crt
           private_key:
              filename: /etc/httpd/ssl/wildcard.mydom.com.key```

I faced the same problem, but managed to solve it by adding RBAC filter to http_filters, then overriding it per route
filters:
          - name: envoy.filters.network.http_connection_manager
            typed_config:
              '@type': type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
              stat_prefix: ingress_http
              access_log:
                - name: envoy.access_loggers.stdout
                  typed_config:
                    '@type': type.googleapis.com/envoy.extensions.access_loggers.stream.v3.StdoutAccessLog
              upgrade_configs:
                - upgrade_type: websocket
              codec_type: AUTO
              server_header_transformation: PASS_THROUGH
              http_filters:
                - name: envoy.filters.http.rbac
                  typed_config:
                    '@type': type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBAC
                    rules:
                      action: DENY
                      policies:
                        'per-route-rule':
                          permissions:
                            - any: true
                          principals:
                            - any: true

per route:
- name: cluster
  domains:
    - 'xxxxxxxxxxx'
  routes:
    - match:
        prefix: '/'
      route:
        cluster: some_cluster
  typed_per_filter_config:
    # enforce JWT token
    envoy.filters.http.jwt_authn:
      '@type': type.googleapis.com/envoy.extensions.filters.http.jwt_authn.v3.PerRouteConfig
      requirement_name: 'default_req'
    envoy.filters.http.rbac:
      '@type': type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBACPerRoute
      rbac:
        rules:
          action: ALLOW
          policies:
            'allow-user':
              permissions:
                - any: true
              principals:
                - metadata:
                    filter: envoy.filters.http.jwt_authn
                    path:
                      - key: payload
                      - key: sub
                    value:
                      string_match:
                        exact: 'xxxxxxxxx'


RCNConfigExperiment is incorrectly flagging valid experiment JSON payloads as invalid

[REQUIRED] Step 1: Describe your environment

Xcode version: 12.2
Firebase SDK version: 7.0.0
Installation method: Carthage
Firebase Component: RemoteConfig

[REQUIRED] Step 2: Describe the problem
Since we upgraded from 6.18.0 to 7.0.0, we're seeing RemoteConfig log "Experiment payload could not be parsed as JSON."  I didn't count, but it's probably being logged once for each of our experiments. The result of this is that our A/B tests seem to have completely stopped getting updated values from the server.
Steps to reproduce:
It's easy to reproduce in RCNConfigExperiement.testLoadExperimentFromTable if you add an additional assertion to verify that the payloads were handled properly...
XCTAssertEqualObjects(_payloadsData, _configExperiment.experimentPayloads);

That assertion will fail before the fix and succeeds after the fix (see below)
Relevant Code:
I looked around in the FirebaseRemoteConfig source code and pinned down the issue (I have a PR ready to go as well).
As part of the change in this pull request (https://github.com/firebase/firebase-ios-sdk/pull/5890/files)
RCNConfigExperiment.m changed how it did JSON validation from...
NSError *error;
id experimentPayloadJSON = [NSJSONSerialization JSONObjectWithData:experiment options:kNilOptions error:&error];
if (!experimentPayloadJSON || error) {

to...
if (![NSJSONSerialization isValidJSONObject:experiment]) {

isValidJSONObject is meant to receive an NSArray or NSDictionary to test if that collection can be converted into JSON data (source). Passing it data causes it to return false every time. The previous implementation is the correct way to test if NSData can be converted to JSON.

@philviso-reverb Thanks for the bug report and investigation.
@christibbs Please review the referenced change from #5890

@philviso-reverb Sorry for the delay. Just added #7269 which I assume is identical to your PR!

@philviso-reverb Sorry for the delay. Just added #7269 which I assume is identical to your PR!

Thanks for the update! Yep, that's identical to what I did.


"_" in the name of display causes errors

Having an '_' character in the name of the display method causes errors. Suggestion is to raise an error that is more meaningful.

Yeah, I just figured this out myself, but I had to search through the library. Is this a non-python constraint causing this?

Hey!
Yeah, this is a non-python constraint. Greppo uses the name as an unique identifier to bind it with the API.
The underscores are used for internal processing and can conflict with how this is done.


add turbo support

https://www.honeybadger.io/blog/hb-turbolinks-to-turbo/
https://github.com/hotwired/turbo-rails/blob/main/UPGRADING.md
https://hotwired.dev/#screencast
https://turbo.hotwired.dev/handbook/introduction


Synchronization script also synchronizes tags

Describe the Bug
When executing npm run sync also all created tags from the upstream Camunda Modeler will be synchronized and pushed. This leads to a lot of wrong tags which does not belong to the Zeebe Modeler
Steps to Reproduce

npm run sync
git tag --> see lots of Camunda Modeler tags created
with next push these tags will be created on origin

Expected Behavior
Do not synchronize tags.
Additional Context
We have to fetch the tags in order to be able to sync to Camunda Modeler releases, cf. https://github.com/zeebe-io/zeebe-modeler/commit/248bacd0ec858952d3655055099f0975240e8018

Closed via 618070b631f3398b7565458b080054cc86a3933e


Long running instance has old title

Current title for long-running instance: Model Asset Exchange Microservice
To be changed: MAX Audio Classifier

Looking at the changes since the last release this has been fixed but not released. So this can be solved by cutting a new release and updating the long running instance's version. Instructions for a release are here: https://github.ibm.com/CODAIT/MAX-development-guide/blob/master/VERSIONING.md and instructions for updating the instance are here: https://github.ibm.com/CODAIT/MAX-development-guide/blob/master/IBM_CLOUD_GUIDE.md


Remove read pool

What have you changed? (mandatory)
This PR removes the read pool, so that coprocessor / storage component will depend less on the server component. According to the diff, the code deletion is more than code addition.
What are the type of the changes? (mandatory)

Engineering (engineering change which doesn't change any feature or fix any issue)

How has this PR been tested? (mandatory)
Existing tests are modified.

/run-all-tests

Great work
How about the compiling time?

@siddontang Introduced Full error for all FuturePools. By default there is no limit (i.e. safe to unwrap() ).
About compiling time, I don't think there could be any differences since it does not change crate relations and only modifies a few LOC.

/run-all-tests

can you split your PR into two?
one is to support the task limited future pool, the other is to remove readpool?
@breeswish

@siddontang The change of supporting task limited future pool is very few, only 20 lines of code (and is copied from the previous ReadPool): https://github.com/tikv/tikv/pull/5220/files#diff-7aec89bf97143ed35d6305fb3fda14e5R58  I think the separation may not help review much.

@breeswish
I still insist on that we should do one thing in one PR, IMO, there are two things in your PR.

@siddontang Extracted to https://github.com/tikv/tikv/pull/5301 now.

Please fix the conflicts.

/run-all-tests


Is the code complete?

I can't find the high-level item recommender

Me too. Could you please update the code? @modriczhang

Aside from the design of the reward, low-level channel selector and high-level item recommender are not different at the network structure level. The reason why the high-level item recommender is not uploaded is that the mini-batch data has not undergone an internal data security audit. I am very sorry for the trouble caused to you.


Access to Dynamic World segmentation masks

Hello.
I attach a screenshot of my geemap report if it is useful.

Description
I'm looking for the Dynamic World segmentation masks, i.e. either a mask with a class number per pixel, or a mask with a probability to belong to each class per each.
I found one use case here, and a sort of description of the function I use here.
However the outputs are not easy to understand and in any case, I can't access directly the segmentation masks.
What I Did
Here is a quick example of what I'm doing
import ee
import geemap
import numpy as np

ee.Initialize()
start_date = '2021-01-01'
end_date = '2022-01-01'
region = ee.Geometry.BBox(-89.7088, 42.9006, -89.647, 42.9167)

landcover_hillshade = geemap.dynamic_world(region, start_date, end_date, return_type='hillshade')
landcover_array_hillshade = geemap.ee_to_numpy(landcover_hillshade, region=region)

landcover_class = geemap.dynamic_world(region, start_date, end_date, return_type='class')
landcover_array_class = geemap.ee_to_numpy(landcover_class, region=region)

landcover_probability = geemap.dynamic_world(region, start_date, end_date, return_type='probability')
landcover_array_probability = geemap.ee_to_numpy(landcover_probability, region=region)

landcover_visualize = geemap.dynamic_world(region, start_date, end_date, return_type='visualize')
landcover_array_visualize = geemap.ee_to_numpy(landcover_visualize, region=region)

We have landcover_array_hillshade.shape which is (246, 689, 3): it's a beautiful image with a fancy visualization of the segmentation, but it cannot be used as is.
Then landcover_array_class.shape is (1, 1, 1): I would expect this one to be (246, 689, 1) with an integer in each pixel corresponding to the class, but it is not the case. It is just a single value (4).
The landcover_array_probability is (246, 689, 1): it seems to be a binary probability (I don't know of what) but it can't be related to the segmentation mask. Since we have 9 classes, I would expect (246, 689, 9) with the output of a softmax, i.e. summing to 1 through the third dimension.
And landcover_array_visualize.shape is (1, 1, 3): there are three values (228, 150,  53) and I don't understand what there are.
This is an example but the outputs have always the same shapes when I change the coordinates.
I guess there are a few problems around, it is not clear which return_type value should return what I'm looking for.
I hope my question is clear: how to access the segmentation masks with a class or a probability to belong to a class at each pixel?
Thanks for your help.

I think it is a projection issue. See this.  Feel free to reopen the issue if the problem persists.

Great to hear that. Thank you for providing the solution.


官方中文BERT权重的链接好像不对

Download the Google's BERT base model for Chinese from BERT-Base, Chinese (Chinese Simplified and Traditional, 12-layer, 768-hidden, 12-heads, 110M parameters), and decompress it.
这里应该是chinese_L-12_H-768_A-12

谢谢关注与指出，已经更正。


Intelligent search update

Did a few things here,
First, in Core::shutdown() it now accepts an array of things not to do when shutting down, like running scheduled jobs or disable logging stuff
This is useful for certain things like in the jobs tools where that could create an endless loop or in this case the intelligent search menu where we want it to be snappy and not bogged down waiting for jobs to run.
I PSR'd 1 file
I moved the intelligent search tools to routes

@aembler any reason the tools had session_write_close() twice? I asked @KorvinSzanto and he didn't know why they were in there

Once this gets merged ill make another request to change the jobs over to the new shutdown method signature

Weird, not that I know of.

Thanks, nice cleanup.


Feature Request: Add system:properties and system:env as sources

I would like to be able to specify system properties and/or environment variables as one potential source for properties in addition to files, especially when using the MERGE load type.  Mainly I want to be able to conveniently override default values with system parameters.
Currently it is easy to add ALL system properties or environment variables to a config object.  But I'd like to be able to specify the system as one potential source, rather than bloating my config object with everything.
Currently this can be done with a utility class, which checks if a property is in the config object before including new properties from the system.  But it would be great if this was supported natively.
Specifically, I would like to be able to do something like the following.
@LoadPolicy(LoadType.MERGE)
@Sources({
  "system:properties",
  "system:env",
  "file:~/myconfig.properties",
  "file:/etc/myconfig.properties",
  "classpath:/myconfig.properties" })
public interface MyConfig extends Config {
  ...
}

In this case I would like the properties to be taken first from system properties, other from environment variables, otherwise from ~/myconfig.properties, etc.

Hmm... that commit doesn't seem to do very much?

I merged this pull request #122:
a2b914d 	Revert LoadStrategyTest
083a539 	Put FIRST and MERGE strategies into new test class
c6acd56 	Add test system properties hot reload
5d5e855 	make all tests pass
3f48e86 	remove header template
85436e7 	resolve #110

ahh ok... the close activity just looked weird because it only referenced the last commit. Sorry about that.

No problem; myself would have been confused as well.

@StFS please double check the code and the feature to ensure your use case is covered. If you (or @gintau) have time, some documentation on owner-site module, would be useful.


Fix helmignore for .*

The first rule matching entry for top level dir will be empty string, the .* rule will then incorrectly match and filter the chart.
Skip this entry as it's not needed for processing.
Closes #1779

Don't know whats up with the CLA thing, but I've signed up with same email as the commit.


1.17-pre4 client stuff

Main changes:

Blocklist changed once again. isBlocked is isAllowed now.
Keyboard: while the color yellow may suggest a warning, it seems like this is used in non-warning situations; thus renamed. processDebugKeys is probably F3 related but it looks like a dead code.
Some rendering maps, probably related to glowing signs
Mapped init
Mapped lambda params
etc
Did I do too much?

LOL, seems like I overworked too much, the prerelease version bumped 😛


Running crunchy-cli in a docker container

Hi,
I wanted to run crunchy-cli without installing it on my M1 mac. I've read about issues with the M1 runners and decided to create a docker image and a docker compose file to run it in a docker container.
I have created a repository with my result and wanted to share my solution:
https://github.com/l0westbob/crunchy-cli
Thanks for creating crunchy-cli !
Have a good day :)

I'm closing this. The recommended way to build crunchy-cli is using cargo (as described in the README). People who want to run this in docker/want to build this in docker are probably experienced enough to install cargo and compile it themself so I won't add a build docker file. And if they want to use docker nevertheless they may find this issue via the GitHub search and adapt it.


Make CLI client Python 3 only

A first try to make the NIPAP CLI client Python 3 only, hopefully avoiding more unicode errors in the future. Consider this a work in progress!
At https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef#codecs it's mentioned that the following could be done to safely write unicode to STDOUT with LC_ALL=C:
sys.stdout = io.TextIOWrapper(sys.stdout.detach(), encoding='UTF-8', line_buffering=True)

I'm a bit hesitant to whether we should add it. Not adding it causes this to be written when trying to write non-ASCII characters with LC_ALL=C, as the C locale is considered ASCII only:
Crazy encoding for prefix <IP_ADDRESS>/24

From what I remember an annoyance was that you'd get unicode errors when redirecting output containing non-ASCII characters. I've not seen this behaviour in the Python 3 version.
I also made some changes to the Debian packaging config (incorporating recommendations from https://wiki.debian.org/Python/LibraryStyleGuide) which probably can be refined a bit. Many warnings are displayed the package is built.

Most of the changes are to update to print() instead of old style print.. I can't say I've looked at each and every one in detail but it looks good overall after a cursory look.
The iteration over a dict with key and value using .items() seems to now be wrapped in list(), after the 2to3 tool had its way, which I don't understand how it could work.
Travis-CI is failing because nipap_cli is imported from nipaptest.py and is thus run with Python2. The actual issue is that print statement that doesn't conform to py2. Can this be fixed through from __future__ import print_statement?? We can potentially run the whole tests using py3.. they are currently executed with "nosetests ....py" and nosetests will be run with whatever is specified by the Travis-CI build matrix but I think we can override that.

In Python 3 the .items()-method no longer returns a list. I guess 2to3 wraps all uses of .items() in a list() to be sure that it doesn't introduce some bug due to this. In our case I'd say we can remove the list()-functions. I fix.
I'm not sure from __future__ import print_statement will solve the testing issue, and even if it does I guess we need to ask ourselves if we want to keep the CLI code both Python 2 and Python 3-compatible. When I initiated the transition of the CLI from Python 2 to Python 3 I worked under the assumption that we'd go for Python 3 only, but at that time I wasn't aware that the tests imported both CLI and backend modules.

Ok, list() seems redundant, please remove. I think it's cleaner looking without. http://stackoverflow.com/questions/17695456/why-python-3-needs-wrap-dict-items-with-list
No, I don't really aim for py2 compatibility of the CLI but simply adding that import will probably make the tests pass. nipaptest.py is big, perhaps too big. In addition to importing and testing the CLI it also imports backend stuff, which we know is NOT py3 compatible. So unless you want to take on fixing the backend too, we would need to try and make CLI py2 compatible. If it's as simple as the import statement then let's just do it.  I think there's a distinction between hacking it to run py2 for CI and making it py2 compatible for all users (more utf-8 hackery n stuff).
If import statement doesn't fix it then I think we need to split up nipaptest.py into smaller parts - that might be a good idea regardless.

OK, after a bit of wrestling with Travis-CI the tests are run and passes again.
As the python environment causes problems when part of the project is Python 2 and part of the project is Python 3 I chose to avoid the python-specific build environments and use a generic image instead. This, naturally, introduced some new problems but I think I've been able to address them all.
Two issues regarding postgresql authentication turned up, and I honestly don't understand why it bacame an issue now, or rather, why it did work before.

When doing the venv-installation, I needed to explicitly set the PGPASSWORD environmental variable to the hard-coded password used during the tests.
When doing the apt-installation, the db_host config variable was set to "" by the postinst script when the database host provided to debconf is "localhost". This causes postgresql to use peer authentication, and as the tests are not run as the user nipap this failed. To address this, I chose to simply rewrite the db_host variable in nipap.conf to localhost in the Travis-CI config, befort executing the tests.

Also, as the Travis image runs Ubuntu Trusty, which is shipped with an ancient version of psutil, I had to implement a work-around to support both old (pre 2.0.0) and new versions.

LGTM


Add simplified status in kubectl columns

When interacting with compositions it's often difficult to tell which state they are in without squinting at the status properties for a while. This change adds a simple string representation of the composition's status and adds it as a kubectl column.

I'm going to merge this one myself - I'll walk Mariano through the code next week when he's back. But for now we need to unblock testing with a real image release.


Reactive key unwrapping

The hashQueryKeyByOptions function returns a queryHash without unwrapping, so the queryKey check becomes false.
const QUERY_KEY = 'test';
const page = ref(1);
const queryKey = reactive([QUERY_KEY, { page }]);

const query = useQuery(queryKey, fetch);
....

queryClient.refetchQueries(queryKey, { active: true, exact: true });

UPD: version ^1.20.0

This should not be the case as useQuery should already unwrap the queryKey.
Could you re-test it with
const queryKey = [QUERY_KEY, { page }];

?
Also minimal reproducible example would help with debugging

I have run your example and it seems to work as expected. You might need to provide reproduction repository to narrow down the issue.

I may have missed an important detail. This is reproduced when linking Vue2 + CompositionAPI.
Reproduction link

Actually it was broken for both Vue 2 and 3. And it worked for me due to specific setup. Should be fixed in v1.22.2

It works, thanks @DamianOsipiuk)


llava-phi3-mini conversion to gguf format

How can I convert from Llama LLM or official LLaVA format or HuggingFace LLaVA format to gguf format?

@nakoeni I'm sorry, the conversion process is rather cumbersome, so we haven't provided that for now.