RFC: Add unboxed, abstract return types

A suggestion - would it be possible to fully unify the syntax for generics and for abstract return types, so that instead of this
fn foo() -> impl Iterator<int>

you write this
fn foo<T: Iterator<int>>() -> T

& equivalently for where clauses. This would imply all sorts of type bounds could be applied to T, but perhaps that's actually possible to implement?

@gulbanana that's a very, very different thing. Rather than being an abstract return type, that's just a normal polymorphic return type which we have today. It's possible that abstract return types want to be impl Sum rather than impl Type, so that one could specify multiple traits which the return type implements.

@gulbanana, it doesn't make sense. impl Iterator<int> means some unknown type (implementing Iterator<int>) which is chosen by this function. <T: Iterator<int>>, however, is a generic type parameter, and it is chosen by the caller of this function. They cannot be unified because they have completely opposite semantics.

that was a pretty half-formed thought, wasn't it? of course you're right, adding 'output generics' to the same parameter list doesn't make sense. the foo::<T,U>() syntax would be particularly impacted.
what i was really trying to grasp at was this: syntactic unification, not semantic, as a shortcut to both definition and implementation of abstract return types. consider a different strawman syntax:
foo<T>(in: T)<U> -> U where T:SomeTrait, U:OtherTrait

the bounds on T would be a constraint on the caller of foo, and the bounds on U would be a constraint for the implementation of foo. if feasible, this would avoid the whole issue of specifying new "impl X" syntax and its presumable variations; you'd apply just the same rules as you do for generics.
i've never looked at how monomorphisation is implemented- something about metadata stored along with the object code for foo, right?- but my wild speculation is that you could store the 'opposite' metadata also, allowing the caller to make use of the returned "impl OtherTrait" via the same static resolution mechanism.

If we go with something like impl Trait or abstract Trait, we could also allow abstract assignments. This is most useful for statics where the type must be declared:
static VAR: impl SomeTrait = construct_some_trait();

However, it could also be useful for safety checking to ensure that a binding implements a certain trait and only implements that trait.
Aside: Personally, I'm against abstract because the returned type is very much concrete (really, I'd prefer concrete over abstract). impl makes it clear that we're returning a concrete implementation.

Nice...I would be excited once this feature is implemented.
And if this change leads to new APIs, some 1.0 libraries will be legacy code, right? Maybe it will lead to fragmentation of the ecosystem.
Wish there will be a way that changes signature of APIs while does not break a single line of existed code written after 1.0.

After thinking about this for a bit, I realized one problem:
fn foo() -> Thing {
    Thing {
        iter: bar(),
    };
}
fn bar() -> impl Iterator<Item = T> {
    // stuff...
}
struct Thing {
    iter: ???
}

`Thing

Functions are supposed to implement all the Fn traits, so <bar::type as Fn>::Output seems like a good way to extract that.
Where value::type is a specific form of typeof value - we could have the whole typeof but I'm not sure how popular that is.
One interesting thing about typeof in Rust is that the following is kinda doable (though maybe not desirable):
fn foo<A: Add<B>, B>(a: A, b: B) -> typeof(a + b) { a + b }

@Stebalien I quite like your third alternative.
Perhaps rather than using union, overload the type keyword instead? Something like this:
type MyIterator: Iterator<Item=i32>;
type MyClosure: FnMut(i32) -> i32;

fn foo() -> MyIterator {
    range(0, 10)
}

fn bar() -> Map<i32, MyClosure> {
    foo().map(|x| x + 1)
}

It works for generics too:
// I'm not sure if these lifetimes are correct :\
type MyClosure<'a, T>: FnMut(T) -> String + 'a;
fn baz<'a, T: Display, I: Iterator<Item=T>>(prefix: &'a str, items: I) -> Map<T, MyClosure<'a, T>> {
    items.map(|x| format!("{}: {}", prefix, x))
}

This solution is pretty much equivalent to the original proposal, but solves the naming problem as well. It also has an intuitive reading ("alias to some unspecified type").
Thoughts?

@Stebalien
Just with the RFC as written, I think your example would be written as:
fn foo() -> Thing<impl Iterator<Item=isize>> {
    Thing {
        iter: bar(),
    }
}
fn bar() -> impl Iterator<Item = isize> {
    // stuff...
}
struct Thing<T: Iterator<Item=isize> {
    iter: T
}

@daboross I know. My point is that Thing doesn't need to be generic. One should be able to write (somehow):
    Thing {
        iter: bar(),
    }
}
fn bar() -> impl Iterator<Item = isize> {
    // stuff...
}
struct Thing<T: Iterator<Item=isize> {
    iter: typeof(bar)::Output // No way to actually get the type of `bar`.
}

Ah, ok - I see your point there.

For what is worth, he way I work around this issue in my implementation is with associated types:
trait Bar {
    type Output;
    fn bar() -> Self::Output;
}

// Sometimes you actually have a meaningful Self type.
// Maybe this should be impl Bar for Thing?
impl Bar for () {
    type Output = impl Iterator<Item = isize>;
    fn bar() -> Self::Output {
        // stuff...
    }
}

fn bar() -> <() as Bar>::Output { <() as Bar>::bar() }

struct Thing {
    iter: <() as Bar>::Output
}

The way this works is that in an impl, an associated type can contain impl Trait types.
These can be accessed by anything that can see the associated type, but they can only be provided with concrete types by methods of the same impl, and those methods have to agree between them on the types.
This scheme could be extended to associated types in a non-trait impl (which aren't a thing right now, for whatever odd reason) and maybe even to module-level type aliases (presumably only functions in the same module could provide the concrete types).
I didn't want to promise anything while I was still busy graduating highschool and getting admitted into university, but there will be some discussions on impl Trait and maybe a new RFC some time this year.
For anyone who wants to check out the rough first implementation from almost two months ago (including a working example with lots of iterators and a certain hack to force 0-sized closures to be Copy), here you go.

@eddyb, could FnOnce (the most general of the Fn* family) be used for this?
fn foo() -> impl Iterator<Item=char> {
    // ...
}
struct Bar {
    baz: <foo as FnOnce>::Output;
}

This would require making the <x as Trait> syntax work for x not only a type but also a function, method, or variable (for closures).

@SimonSapin No, you need typeof or some other disambiguation - @Stebalien was close, but it needs some brackets, i.e. <typeof(foo)>::Output.
Although, before typeof is added to Rust, what's the point, if you can use associated types or maybe even type aliases?

I agree with @lfairy and @eddyb. If we want to refer to a thing multiple times then we should declare a name for it up front like normal, not get at it in some roundabout way with FnOnce::Output or typeof. If, say, you want multiple functions to return the same abstract type, why should one of them be distinguished as the one which all the others get the typeof? typeof feels like a design smell to me, though I couldn't yet precisely explain why.
I like @lfairy's idea of module-level types without explicit definitions (RHSs). Once you start being able to refer to the type in multiple places, it's also useful without any trait bound, in plain type Foo; form, where it's essentially an alternative to a struct with all-private fields. Rather ML-like.
An interesting question is precisely who (which part of the program) actually gets to know the identity of such an abstract type. If I'm intuiting them correctly, under the existing proposals this is restricted to the bodies of the functions which deal in the abstract type (most of the time, return it), and from where the typechecker discovers what the type even is, so it's abstract even to the rest of the module defining it. E.g., if I have type Foo; fn foo() -> Foo { return true; }, then foo() gets to know that Foo = bool, but nothing else does, for instance fn bar() -> i32 { if foo() { 9 } else { 10 } } would be rejected, because bar() may only know that Foo is a type, but not which. But how would this be specified precisely? If it's just based on whether Foo occurs in the type signature of the given function (as a first guess), that seems rather brittle. It seems there might be a desire for actual module-level abstract types, where you do explicitly specify its identity, and the whole mod gets to know about it, and it's abstract to everything outside of it (even more ML-like!). In that case the proposed syntax starts to actually clash with existing type aliases, which are decidedly non-abstract, but that's just syntax and we could solve it however (for instance abstract type Foo = bool;). There are probably similar who-gets-to-know-what distinctions for the associated types case as well, as in @eddyb's example.
I'm starting to think it would be better to actually begin by approaching things from this direction, at least for the design phase, and instead leave impl Trait/abstract Trait, which under this light are just a syntactically sugary special case, for later. In any case the design space looks a whole lot bigger now than when this started out as just a more principled alternative to return type inference.

As usual, I agree with @glaebhoerl. This RFC is trying to serve up type inference and type abstraction as one feature, when they are orthogonal.
Inference-wise, we want to introduce meta-variables/unknowns where we are are not allowed to today.
fn foo() -> _ { ... };
type BigLongIterator = _;

Abstraction-wise, we want to give ourselves more leeway to change our libraries without breaking client code.
mod nsa {
    // Works with any T!
    abs type Iter<T>: Iterator<Item=T> = SnoopWhile<...T...>;
    ...
}

I agree that declaring an abstraction without a binding is brittle and/or confusing because the choice of scope is implicit. Also, if/when we allow returning unsized types so the caller can choose the allocation strategy, the proposed syntax would be confusingly like that.
Coincidentally, I recently ran the following usecase that RFC does not address:
// Not trying to bring in "constraint kinds" to the discussion,
// but would be verbose in my comment not to use this
// type Stm<T> = FnMut(&mut SomeSortOfState) -> Result<T, SomeSortOfError>

abs type Bind<F: Stm<T>, G: FnMut(T) -> Stm<U>>: Stm<U> = _;

fn bind<F, G>(f: F, g: G) -> Bind<F, G>
   where F: Stm<T>,
         G : FnMut(T) -> Stm<U>
{
    | state | {
        let r = try!(f(state));
        g(r)(state)
    }
}

Come to think of it, this would also be nice if we wanted to define the iterator adapters with closures.

@Ericson2314 I agree the RFC itself suffers of feature-creep, though I prefer not to call the feature "inference", but rather "anonymization".
The abstraction part of it is necessary for providing an interface, then again, that interface could be free functions taking the anonymized type (and being in scope to see its "true nature").
As for your example, I believe this would compile on my branch:
trait Bind<F>  {
    type Output;
    fn bind(self, f: F) -> Self::Output;
}

impl Bind<T, U, A, B, F: FnMut(T) -> B> for A
where A: FnMut(&mut State) -> Result<T, Error>,
          B: FnMut(&mut State) -> Result<U, Error>
{
    type Output = impl FnMut(&mut State) -> Result<U, Error>;
    fn bind(self, f: F) -> Self::Output {
        |state | {
            let r = try!(self(state));
            f(r)(state)
        }
    }
}

I don't have a build laying around, but I'll rebase and see if this actually works.

@eddyb Thanks so much for trying that out! It makes sense that binding the type parameters just once (the impl) over both the closure type and bind function will help with inference.

I agree the RFC itself suffers of feature-creep, though I prefer not to call the feature "inference", but rather "anonymization".
The abstraction part of it is necessary for providing an interface, then again, that interface could be free functions taking the anonymized type (and being in scope to see its "true nature").

I'm a little unclear on what you are saying. When _ is used without abstraction, it's just shorthand--no separate interface is needed. Likewise abstraction can be used with a fully written-out type, in which case the programmer just wishes to leave less up to the type checker even though they are not committing to that definition publicly.

@Ericson2314 It works! I had to update my example (and add a bit to it to have something to test).
You can read the full example on my rebased branch.
One thing that I had forgotten about was the lifetimes, I'm using the same defaults as trait objects, so it's either explicit or 'static.
As for your abstract types proposal, I'm unsure how feasible it would be to have the same type alias behave differently depending where it used.
What about the following case?
mod foo {
    struct FooReal;
    pub abs type Foo = FooReal;
    pub fn mk_foo() -> Foo { FooReal }

    fn test() {
        let a = FooReal;
        let b = ::bar::mk_foo_unprivileged();
        // assert that a and b have the same type:
        [a, b];
    }
}
mod bar {
    pub fn mk_foo_unprivileged() -> ::foo::Foo { ::foo::mk_foo() }
}

If that code doesn't compile, it could be because switching between the real type and the anonymized one is done at resolution time, and so bar::mk_foo_unprivileged returns a type that is opaque for everyone, including the foo module.
However, if it does compile, then type unification has to take into account the context within which those types were used, and do privacy checks.
Also, you might run into multi-function inference with abs type T = _;, if you want a function to see the real type (provided by a different function), instead of each function being able to only provide the real type.

@eddyb The intent there would in fact be for it to be explicitly module-scoped, so like privacy, yeah. I think the semantics of both explicit abstract type with explicit RHS as in that example (module-scoped) and fn some_iter() -> impl Iterator1 (everything implicit, single-use, single-function-scoped) are relatively clear-cut. The more "interesting" case is an explicit abstract type with implicit RHS, as you point out.
I wonder if there's even a reason to allow that (in terms of actual expressiveness, rather than mere convenience)... unless I'm missing something the only situation where you couldn't explicitly specify the type (RHS) is if it's a lambda, but two different functions can't really return the same lambda type anyways unless one just forwards to the other, so that's not very useful. But that's just the "multiple producer" case... maybe you could conceivably want something where you have a single function returning an abstract type Foo = _ (which is, in actual reality, a lambda), and then Foo also occurs in function arguments and struct fields and so on? Anyway, this feels like the part of the feature set that would be prudent to defer adding into the indefinite future, at least until there's actual strong demand for it.
1 (Not my preferred syntax, but we should have that discussion separately, I think.)

@glaebhoerl So how would my example behave, then? What determines which type is seen?

Inside foo, you get to know that Foo = FooReal, outside of it, you don't, and Foo is opaque (like a skolem or something). So your example would type-check, because test() is inside foo. On the other hand, if say foo were to also, separately, export FooReal (while keeping Foo abstract), and test() were moved outside of foo, then it wouldn't.

@glaebhoerl That means unification would have to be contextual, which is something I've never heard of before, and I expect it has "interesting" failure modes involving generics, associated types and coherence.

I'm not familiar enough with the details to understand what you mean by unification having to be contextual, but if this kind of thing works for ML-family languages since the 1970s, I don't see why it couldn't work for Rust. It's just an existential.

@eddyb Sorry for not responding earlier after you kindly implemented my example--I haven't had time to build your branch of rustc yet I am afraid.

Also, you might run into multi-function inference with abs type T = _;, if you want a function to see the real type (provided by a different function), instead of each function being able to only provide the real type.

The more "interesting" case is an explicit abstract type with implicit RHS, as you point out.

I actually think the semantics of _ are really boring no matter what. The use of _ instead of something explicit should only effect whether or not type checking completes without errors. It should not affect what types the AST has should type checking succeed, with the possible exception of inference variable defaults.
We can simply make each function provide the type, "refine" the type further after type checking each function, or do full multi-function type checking. Each is backwards-compatible with the last (if two succeed, they agree; everywhere earlier ones succeed, later ones also succeed), so I don't think this puts pressure on us to soup-up the type checker.

I'm not familiar enough with the details to understand what you mean by unification having to be contextual, but if this kind of thing has worked for ML-family languages since the 1970s, I don't see why it couldn't work for Rust. It's just an existential.

I'm going to play the devil's advocate here. I believe this situation can only arise in the ML languages with recursive modules---making bar contain foo wouldn't cut it. I looked up https://www.mpi-sws.org/~rossberg/f-ing/f-ing-jfp.pdf, the go-to for why ML modules aren't really all that crazy, (and paper aturon once mentioned to me fun fact) and was reminded that it did not cover recursive modules, with the disclaimer that the authors think they really do require desugaring to a more powerful type theory than System F.
The upshot is that either enforcing an acylic dependency order on modules with abstract types, or not supporting the "unabstraction" mk_foo_unprivileged()'s return type avoids these issues, but is forwards-compatible with handling things "the right way". One could argue the RFC as written also limits type abstraction to something we know how to handle. But unlike my proposal with one of the above restrictions, moving from the RFC to my-style abstract types leaves us with a now-redundant syntax (impl <trait> types).
Also note that one can do much odder things with recursive ML modules. I am not at all sure whether this case alone touches on the complexity that prevented Dreyer et al. from discussing them.

Also @eddyb, since I don't have time to build your branch yet, how does this work?
trait Bar {
    type Output;
    fn bar() -> Self::Output;
}

impl Bar for () {
    type Output = impl Iterator<Item = isize>;
    fn bar() -> Self::Output {
        if rando() {
            baz()
        } else {
            // <expr> : <explicit concrete iterator type>
        }
    }
}

fn baz() -> <() as Bar>::Output { <() as Bar>::bar() }

@Ericson2314 Could you explain why you believe this
mod foo {
    struct FooReal;
    pub abstract type Foo = FooReal;
    pub fn mk_foo_priv() -> Foo { FooReal }

    fn test() { [FooReal, ::bar::mk_foo_unpriv()]; }
}
mod bar {
    pub fn mk_foo_unpriv() -> ::foo::Foo { ::foo::mk_foo_priv() }
}

is any harder than this?
mod foo {
    struct FooReal;
    pub abstract type Foo = FooReal;
    pub fn mk_foo_priv() -> Foo { FooReal }

    fn test() { [FooReal, mk_foo_priv()]; }
}

In both cases you need to know the same thing (Foo = FooReal), and you need to know it in the same place (foo::test()).
Whether or not they're implicated here, recursive modules are a very good point, and do in fact seem like they would present complications, involving "backpatching" and linear types(!), as commented by @zwarich earlier.
I think impl Trait / abstract Trait (my preferred syntax) is something we would probably want to have as convenient shorthand for a common case, even if we do also have the more general abstract type. It may (or may not) even make sense to implement that part first. But I think we should definitely at least work out the detailed design for the general feature before we charge ahead with adding the specific case to the language. (A network of incrementally designed, subtly inconsistent narrowly-tailored features is a solid way to end up with a complicated language.)

@glaebhoerl Right now unifying two types (for equality/subtyping, potentially associating inference variables with concrete types) works the same regardless of where the unification was required.
There is no context for unification. You would have to add the module where unification originated as a context and somehow contain the impurity of the process.
Aren't ML modules closer to type classes, abstract types being type T: Trait; associated types in our traits?
@Ericson2314 "refining" the type after each function results in order dependence in type-checking, which isn't a thing right now.
Does ML have multi-function inference? That alone might be enough to thwart suggestions along the lines of "if ML can do it, why can't we?".
As for your example, it's currently unhandled. I'm honestly not sure how to handle it, other than by replacing all anonymized types being assigned by the function, with the inference variables used to gather their concrete types, in every type that appears in the function (similar to how associated type projections are normalized).
Your example can be reduced to a single free function:
 fn foo() -> impl Iterator<Item = isize> {
    if rando() {
    baz()
    } else {
        // <expr> : <explicit concrete iterator type>
    }
}

I might try getting this to work, hopefully after the pending refactors to the inference/typing contexts by @jroesch (the last one required me to rewrite most of the deanonymization logic).

@eddyb It is impossible to implement abstract types without scoping the concrete type somehow so that it doesn't escape and destroy the abstraction. How you handle that in your typechecker is an implementation detail.
How will abstract types work relative to child and parent modules? ML gives the user flexibility, because it separates modules and their signatures, and all introduction of abstract types occurs via signature ascription.
How will they work relative to recursive modules? As mentioned earlier in the discussion, getting this right is tricky.
How will they work relative to trait coherence? Coherence requires global knowledge of all trait implementations in a module, but if the type gaining an impl is abstract then exposing the type destroys abstraction. This gets more annoying with generic impls.

@zwarich But multi-function inference is not just an implementation detail, it's an observable change in semantics.

@glaebhoerl with the naive existential encoding, since bar is working from the existential type, it itself uses has an existential type, and the foo looks at bar and also sees an abstracted type that foo has no idea has anything to do with itself.
We can bail ourselves out by making foo : ∃ FooReal. (() -> FooReal) -> { ...}. Then "hoisting" the existential over bar and foo together while doing a letrec to tie the not. In other words, modules can cyclically reference each other in the definition of their terms, but not their types.
My guess is that what I just said is extremely cryptic, but if you read the paper up to the point where they talk about a Monad from hoisting the existential, it should make sense. The order of monadic binds should be a topological sort over the acyclic type-level modules dependencies.

@eddyb

Aren't ML modules closer to type classes, abstract types being type T: Trait; associated types in our traits?

Not sure how much this matters, but our <T as Trait>::Foo  is only abstract iff T is abstract. I.e. every impl of Trait has a concrete Foo. Type Classes / traits are nothing but a special case modules, constrained by the coherence rule, so we can automatically route the right instance/impl.

Does ML have multi-function inference? That alone might be enough to thwart suggestions along the lines of "if ML can do it, why can't we?".

OCaml and SML both use Damas-Milner inference, which is multi-function/global.

"refining" the type after each function results in order dependence in type-checking, which isn't a thing right now.

Correct me if I am wrong, but I believe there is an RFC that rustc's stability guarantees only apply to elaborated code. That way, if previously some complex thing type checks, and later we tweak the algorithm and the code is now ambiguous, we are in the clear. As I said before, we should be able to guarantee that the order that functions are type-checked never affects the inferred types, just whether they are inferred at all. Then we are in the clear.

As for your example, it's currently unhandled....

I intended to show that even with what this RFC proposes, we have the same cyclic module problem. Either that example tragically fails to type check, or we have context-dependent type checking.

@zwarich

It is impossible to implement abstract types without scoping the concrete type somehow so that it doesn't escape and destroy the abstraction.

Yes!

How will abstract types work relative to child and parent modules? ML gives the user flexibility, because it separates modules and their signatures, and all introduction of abstract types occurs via signature ascription.

How will they work relative to recursive modules? As mentioned earlier in the discussion, getting this right is tricky.

As I just wrote above, I think merely keeping the type level acyclic is trivially sound and still pretty expressive.

How will they work relative to trait coherence? Coherence requires global knowledge of all trait implementations in a module, but if the type gaining an impl is abstract then exposing the type destroys abstraction. This gets more annoying with generic impls.

Interesting. I'm reminded of the adapter type in the definition of io::Write::write_fmt. I think imposing on
mod foo: { type Abstract: Bounds; };
impl Trait for ...Abstract... { ... }

the same obligations that are imposed on
impl<T: Bounds> Trait for ...T... { ... }

is a good conservative option.
Oh, and there is a syntax for upcasting child modules. Coincidence, I swear. :)

@Ericson2314 The way I proposed to handle the contextual dependency is to replacing values of that impl Trait type with the inference variable that is used to "collect" the concrete type of the impl Trait.
Arguably, you could expand on this, and be context-dependent inside a function by deanonymizing impl Traits assigned by the function. Or, in your suggestion, abstract types of the same module.
At least that wouldn't affect unification, but instead work similarly to projections (<T as Trait>::Assoc before it's resolved).
But most importantly, you couldn't "witness" the equivalence between the abstract type and its concrete counterpart outside of a function in that module. Would that be good enough?
Multi-function inference can become less painful (read: "less impossible") after the HIR/MIR work, but I wouldn't count on it.
I also fail to see the practical value of such abstract types (emulating parts of a module system we don't have, just for the sake of doing so, doesn't count), whereas returning anonymized types has had applications and a demand for years now.
What can you do with non-inferred abstract types that newtypes don't already handle?
It might be better just to improve on newtypes, if there are rough corners, rather than papering over their issues with a non-orthogonal system borrowed from a world where it is used in a different way (AFAICT, most of its original usecases are handled by traits).
As for inferred abstract types, that's just multi-function inference hiding in sheep's clothing, and should not be treated any differently than any usual debate on multi-function inference.
On the matter of syntax, I've seen abstract being thrown around. That's sad, because impl is too long already.
Remember, we used to dream of fn(A) -> |A| -> |B| -> |C| -> R.
With this RFC, best case would be fn(A) -> impl Fn(A) -> impl Fn(B) -> impl Fn(C) -> R which is somewhat jarring, but not entirely horrible.
OTOH, if we go with abstract: fn(A) -> abstract Fn(A) -> abstract Fn(B) -> abstract Fn(C) -> R -> :-1:.
If we're not afraid of recycling sigils, fn(A) -> ~Fn(A) -> ~Fn(B) -> ~Fn(C) -> R could work nicely.
fn() -> ~Trait would mean exists T~Trait.fn() -> T where T~Trait is just T: Trait.
Binary ~ feels "close enough", though it usually deals with approximation, not subsets.

I would like to add that any of the following are aesthetically pleasing and single-character denotations of abstract types.
fn iter() -> Iterator fn iter() -> ^Iterator fn iter() -> ~Iterator`
I would also like to suggest that such a character be read as "some", i.e. Option<Fn(f32) -> f32>` would be read as "An option over some closure from floats to floats."

Yeah tilde is what we had suggested long ago and I think it'd look very nice and it's concise, and I think its association with "approximation" is useful as a mnemonic for its use.

-1 for sigils. https://xkcd.com/1306/

cmr:

One of my major ergonomic concerns is that the "fast thing" (static dispatch) is more syntax than the slow thing. We should make the fast thing easy and more natural.

+1 x 100

The way I proposed to handle the contextual dependency is to replacing values of that impl Trait type with the inference variable that is used to "collect" the concrete type of the impl Trait.

I'm not exactly sure what you are proposing, but this can only be done within the scope where the the type is transparent: there exists a concrete types that will unify with the inference variable.

Arguably, you could expand on this, and be context-dependent inside a function by deanonymizing impl Traits assigned by the function. Or, in your suggestion, abstract types of the same module.
At least that wouldn't affect unification, but instead work similarly to projections (::Assoc before it's resolved).
But most importantly, you couldn't "witness" the equivalence between the abstract type and its concrete counterpart outside of a function in that module. Would that be good enough?

I'm not sure you mean---this sounds like what you would do outside the scope where the type is transparent / where the type is opaque. Only there does one need to make sure that that equivalence is unobservable. I don't see how to do that without making sure the abstract type and it's concrete definition don't unify.

Multi-function inference can become less painful (read: "less impossible") after the HIR/MIR work, but I wouldn't count on it.

Again, we can always introduce a fresh inference variable for each function in the scope where the type is transparent, and afterwords ensure that that their inferred definitions are the same.

I also fail to see the practical value of such abstract types (emulating parts of a module system we don't have, just for the sake of doing so, doesn't count), whereas returning anonymized types has had applications and a demand for years now.

This is needed for one has multiple functions that return the same abstract type, and both construct the type using it's concrete definition as opposed to one using the other.

What can you do with non-inferred abstract types that newtypes don't already handle?
It might be better just to improve on newtypes, if there are rough corners, rather than papering over their issues with a non-orthogonal system borrowed from a world where it is used in a different way (AFAICT, most of its original usecases are handled by traits).

Granted, ML often uses existentials/abstract types where Haskell and Rust use universals:
open Queue;
foo: ...Queue.t...

fn foo<T>(....) -> ... where T: Queue;

But newtypes are different story. Clearly traits don't help alleviate the need for newtypes---in fact new types are often needed for traits (due to coherence)!
There definitely an overlap betwen "one off" abstract types ("one off" in that since they are part of a module's signature and not a trait, they don't form a "reusable" abstraction) and new types. The most major differences are:

abstract types are more ergonomic
newtypes impose less coherence restrictions on downstream crates
newtypes expose their size (for e.g. transmute) and thus slightly leak

I don't think you can blame my proposal for the overlap, however. Allowing struct MyIter(_); (i.e. the type of the single field is inferred) addresses all the needs this RFC mentions.

On the matter of syntax...
If we're not afraid of recycling sigils...

To be clear, I was only proposing abs / abstract for named abstract types.

+1 For ~.

I'm afraid that ~ may create confusion as these were sugar for Box before. This might create problems with older material on Rust (docs, tutorials and so on).

Another syntax option is -> @Trait where the @ kind of represents the a in @nonymous/@bstract return type.
However to be honest -> impl Trait has grown on me too - it also reuses existing syntax, is fairly clear and saves fancy sigils for other use cases.

Honestly I wish we could just -> Trait (-> TraitA + TraitB + ...) and be done with it (no sigil, no keyword, no nothing).
My second best option would be something like -> R: Trait where R is a generic parameter constrained by a Trait but R itself is not specified (-> R: TraitA + TraitB + ...).
For reasons I don't understand (yet) we can't have any of these and as @eddyb argues above, impl is too much typing/noise for something that should be common and easy.
Since I read the sigil ~ as approx it makes sense to me in this context. But it is not my first option, and I dislike sigils since they are a barrier of entry for newcomers to the language who don't know them. Maybe a better alternative could be to reuse as: -> as TraitA + TraitB + ....

Using -> Trait might work, but that prevents nesting the anonymized type in other types (e.g. Box<impl Trait>) and can't be used in associated types at all, as it already has a meaning in those cases.
Generics can't ever be abused for this because the caller can use any type that implements Trait for R, and R has to be provided either directly or via inference.
The closest syntax that could be used is _: Trait, but AFAICT nobody likes that.

After using impl Trait for a while, it is not so bad at all; here is some example code which uses it: https://github.com/m4rw3r/rust_parser_experiments/blob/ebedd36f2f7e19171c65e38fdee3822d5daa4090/src/main.rs#L235
I agree with you @eddyb regarding generics, not only because it is abuse but also because it creates more noise for the caller. The caller might have to annotate a function, and then the caller either needs to be able to write the type for the generic return (impossible in the case of a closure) or leave a _ in its place which is just unnecessary noise and also something rustc might forbid in some contexts.
_: Trait: to me this looks like you are defining an anonymous generic which implements Trait, since all other uses of _ are anonymous placeholders of some kind.

An interesting point that I think came up in discussion was that traits lose the main utility of associated types when you use abstract return types, since there is no concrete impl to attach the associated types to. Some kind of aliasing functionality may help with that.

-1 for a random sigil. https://xkcd.com/1306/

fn abcd() ⇝ Trait
Here you go: a sigil, not intrusive, hard to spot and most importantly… extremely hard to type.

What I’m trying to say: this RFC was closed more than a year ago and nobody’s getting this feature in without a new RFC. As (my) previous experience shows, people tend to to go all over the same debate on a follow-up/replacement/new RFCs (see the placement-in + <-), therefore discussing syntax for a feature that’s not landing anytime soon looks like mostly a waste of time (people ignore discussions on previous RFCs most of the time).

@nagisa I think most people are aware a new RFC is needed but are just getting some bikeshedding done before the time comes.

@nagisa I've waited more than a month for @aturon and then we had a meeting last week and a new RFC might be coming this month, if that gives you any hope.
The syntax problem is one that will create bikeshed before and after a new RFC, and I'd be glad if we had something optimal before then.

There is a point in making it short, simple, and easy, though, to encourage the programmer to use this over Box (when possible). Naming it AnAbstractUnboxedReturnType does not encourage this. A sigil, on the other side, can also create confusions.

@eddyb

I've waited more than a month for @aturon and then we had a meeting last week and a new RFC might be coming this month, if that gives you any hope.

Sorry! :(
I have a couple other RFCs in my queue, but hope to push them out this week, and then will focus on reviving this one. Thanks again, @eddyb, for your work on this topic.

Here here! Thanks @eddyb and @aturon (and everyone else involved). Personally, this has been one of my most anticipated features - looking forward to seeing what unfolds :+1:

The syntax problem is one that will create bikeshed before and after a new RFC, and I'd be glad if we had something optimal before then.

So here's my two cents: I liked the impl Trait syntax, but I feel uneasy that it doesn't play well with the where clause, and things may get really long. So I propose an alternative, inspired from the pattern matching syntax:
fn factory(num: i32) -> _ @ T where T : Fn(i32) -> i32 {
    move |x| x + num
}

I also liked what @Stebalien proposed here, and here's an alternative:
type X = Cell<_ @ T> where T : Trait1 + Trait2;

during compilation X should be resolvable to a single concrete type.
The downside is that you have to use where clause now!

@critiqjo But that has the wrong semantics: you're requiring that the type implement certain traits but not exposing it.
This is similar to the confusion with generics, and your syntax examples are less ergonomic than even the -> _: Trait syntax, which is the opposite direction of where I'd like this to go.

That's true... :disappointed: But my original concern was to have an option to specify it using where...

@critiqjo I honestly don't see the point, what would where bring?
If it was actual existential syntax, it might be interesting, but it's pretty hard to use existentials for fn declarations because the whole fn is existential, not the return type (which would be a plain -> Trait).

Wow! I see!! (I thought where was just to improve readability... my bad! Sorry for the noise...)

Thanks @glaebhoerl @Ericson2314 @eddyb and others for the insightful discussion since this RFC was closed. I've been thinking about this a fair amount, and after digesting your various comments, wrote up a blog post outlining a couple possible directions.

Nice! Syntax nit. I'd prefer the following over the arrow syntax:
trait IterAdapter: Iterator
    where Self: Clone if Self::Inner: Clone,
          Self: DoubleEndedIterator if Self::Inner: DoubleEndedIterator
{
    type Inner: Iterator;
}

To keep APIs sane, I wouldn't allow the inline version.
Also, this alone probably deserves its own RFC (it seems like it would be useful by itself).

Just thought I'd mention there's further discussion of @aturon 's latest blogpost on reddit also.

@aturon (Going to respond here, because this is where most of the technical discussion has been, and the reddit discussion has fallen off the front pages by now.)
Here are some things which occurred to me while re-reading your post:

If I have my druthers, this feature would also be usable in argument position:
fn map<U>(self, f: ~FnOnce(T) -> U) -> Option<U>

However we end up solving the "abstract return type" use case, I agree it would be nice if it could extend to abstract arguments as well: it bothers me that we currently have to perform the same kind of fn hof<F: FnOnce(...)>(f: F) dance as C++. We should be able to do better.
That said, given the "leaky" semantics of the proposed ~Trait syntax, it seems to me that its analogous behavior in argument position would be much closer to C++ template expansion than to our existing generics:
fn my_print(thing: ~Display) {
    println!("{}", thing + 1)
}
my_print(21); // OK, prints 22
my_print("hi"); // compile error

Here, the fact that my_print can depend on the actual type that the caller chose to call it with, rather than just the specified Display interface, is simply dual to how given fn my_printable() -> ~Display, the caller could depend on the type that my_printable chose -- in either case meaning that a change in the implementation can break clients even while the signatures stay the same.
(Personally, this bothers me quite a bit: this is a question of priorities, but explicit interfaces and non-leaky abstractions would be much closer to hard requirements on my list, along with a clean, orthogonal design.)

It behaves exactly like associated types today.

[...]

This kind of “leakage” is already prevalent – and important! – in Rust today. For example, when you define an abstract type, you give a trait bound which must be fulfilled. But when a client has narrowed to a particular impl, everything about the associated type is revealed:

Could you spell this analogy out in greater detail? I don't quite have the intuition behind it. (One difference I notice is that with associated types, you do write out the actual type in at least one place, unlike with ~Trait - but it's not obvious to me what it corresponds to in the broader analogy.)

The type leakage is, in general, very unlikely to be relied upon. For example, to observe the particulars of an iterator adapter type, you’d have to do something like assign it to a suitably-typed mutable variable:
  let iter: Chain<Map<'a, (int, u8), u16, Enumerate<Filter<'a, u8, vec::MoveItems<u8>>>>, SkipWhile<'a, u16, Map<'a, &u16, u16, slice::Items<u16>>>>;
  iter = some_function();

I don't understand this example... why couldn't you rely on type inference? Why is mutability relevant? Either way, I don't think I agree with the broader point. On the one hand, maybe this is the case to some extent for iterator adapters, simply because these are special-purpose types whose only purpose in life is to adapt iterators, and there's inherently not much else you can do with them. But in general, most types have much broader interfaces. And on the other hand, I thought leakage for things like conditional impls was the whole point!

The basic idea is to introduce a “type abstraction operator” @ that is used to “seal” a concrete type to a particular interface:
pub type File = FileDesc@(Read + Write + Seek + Debug);

This is an intriguing approach, but you don't quite spell it out in the post -- what's the motivation for formulating things this way, rather than e.g. abstract type File: Read + Write + Seek + Debug = FileDesc?

How should these type definitions interact with coherence? Can you implement traits for File? Inherent methods? What if they conflict with traits/methods on FileDesc?

The answer feels like it should be "no", or at least, the rules should be akin to the ones for normal type aliases. You definitely shouldn't be able to give conflicting impls for File and FileDesc -- the owning module, at least, should see these as the same type. I guess it's an interesting question that if you do impl Foo for FileDesc and impl Bar for File, and if both File and FileDesc are exported, then outside the module you should be able to know that FileDesc: Foo and File: Bar, but not FileDesc: Bar or File: Foo (which you'd know inside the module, given you know File = FileDesc). That seems logical enough at least for this simple example, but it's kind of subtle and weird, so it might be a better idea to just forbid trait impls directly on abstract types. (Inherent impls seem more desirable... of course you'd like to provide an external API of things you can do with the abstract type, that's kind of the point. While from the owning module's perspective, it should still behave the same as if you were impling on a type alias.)

How do you deal with bounds where the type isn’t in Self position? For example, there is also an impl of Read and Write for &File that should be exported.

With the abstract type formulation, it seems natural to use a where clause -- pub abstract type File = FileDesc where File: Read+Write+Seek+Debug, &File: Read+Write, or somesuch.

:bell: Just a notice to any thread followers, a possible alternative is being discussed in kimundi's latest RFC.

Some thoughts on impl trait here: http://ncameron.org/blog/abstract-return-types-aka-`impl-trait`/
One thing I don't address there, but think will work is allowing impls to use a concrete type where the trait uses impl Trait. Then allowing callers which know they have exactly that impl to use the concrete return type

Wait, you want OIBITs to leak from the function body?  That seems like an odd abstraction violation.  Why would Sync or Send be different from any other trait in that respect?  Isn't part of the motivation to allow stabilizing APIs where the concrete type may change in the future?

@comex The reasoning is the same as with private fields: they are not exposed in the public API but they affect OIBITs.
If we don't reflect OIBITs through impl Trait, they would have to be explicitly specified, which apart from being an annotation nightmare, it would also require support for conditional bounds (e.g. (Send if T: Sync) or (Sync if 'a: 'static)).
And it wouldn't compose, at all. If a new OIBIT is added, existing impl Trait uses wouldn't have it.
My only concerns were about it requiring global inference to implement, but I believe we can create "global obligations" that are checked after all the types are known.

Why weird names instead of commonly used ones ?
pub fn imp now + etc..
All you do is make it harder for people to learn Rust, people don't just use one language, they use multiple language for multiple purpose, and if you start naming your stuff just to be "unique", then don't expect people to make the effort to choose Rust
Even for OOP, it looks like you all hate OOP, so you won't make the effort to allow it in your design, a language give devs the tools to solve their problems, not yours, if you can't do OOP, X, or Y, that means your language is limited by design
I tried to learn rust but the effort is way to big and it just not worth my time
What you are doing is to force devs to use functional programming, just like how Java force devs to use OOP, this is stupid
Just my 2cents


Your h2 element should be red.

Waypoint: Change the Color of Text. Before I even type my code in I have a red X and it says that your h2 element should be red. When I do type in me code. I get the same result. My code is
CatPhotoApp. What am I doing wrong?

For questions about code that are not specifically a bug with the site, please ask for help in the Help Chat Room - There are plenty of helpful campers waiting to answer your questions.


Add wait_for_participant to mma example

This was already in other VPA examples but missing here. It's not always necessary but improves reliability (e.g. SIP) and seems worth having in the default case.

Hey, this for VPA it is already handled internally. I think we should do the same for MMA

It is already the case actually:
https://github.com/livekit/agents/blob/5fedcfdfce510ce96d34d85b38807f0d03389bfc/livekit-agents/livekit/agents/multimodal/multimodal_agent.py#L232

@theomonnom yeah but still all the VPA examples have a wfp in them - is it really unnecessary?
this could be indicative of some sort of bug with how it's set up - it does seem like that should basically work (although it doesn't wait for subscription from the linked_participant but rather from any participant).  and someone in community reported that SIP didn't work til they added this. might be worth digging into, I agree it feels unnecessary and it would be good to simplify it away in all of the examples.

Seems like wait_for_participant was already added by dz in some previous PRs


How to custom setting?

I want to change some setting, example: remove speaker, add new font, set default font, set default size..., How to do these?

Hi everyone,
I spent like a whole day playing with Folio on Android. I'm far from an Android decent developer, but I'm quite familiar with java.
In order to customize, you need to import the folio reader and the webviewmaker into your project, and then tweak the source.
So, to remove speaker, you need to edit the folio_activity.xml and remove the last ineer LinearLayout (the one with btn_speaker). You may also comment or delete the method which throws an error upon compiling.
Adding new fonts is little more tricky, but playing with existing fonts and size, you need to edit the view_config.xml
Hope this helped.

@anhhtbk good idea. i think, it would be good if we provide some interfaces or params, so developer can change the settings without tweaking FR source..


Support for Cloud Resource Manager v1 API

Thanks! :grin:

Opened against https://github.com/googleapis/googleapis instead.


DEV 9107.4 Update version of kubectl 1.7.2 -> 1.8.0

https://github.com/Shippable/pm/issues/9107

this is done, closing


Introducing credentials_dir variable in order to be able to override it

What this PR is about:

ignore_patterns in the inventory section of ansible.cfg now contains "credentials" so that no warning is shown at playbook start
The credentials_dir variable (default is "{{ inventory_dir }} + /credentials") could be overriden. In multiple sources inventories, the inventory_dir is set on a per host basis, when one of the sources is a script/binary - let's say - ~/bin, the credentials directory is created in ~/bin...

ci check this

rebased

/lgtm

/approve


Dynamically resolve $DOCKER_HOST...

Dynamically resolve $DOCKER_HOST  if it appears in galaxy_url.
Use netstat value plus this idiom.

Just for clarity, you intend to pass galaxy_url = http://$DOCKER_HOST:8080/galaxy (or similar) and then have galaxy.py resolve that?

Exactly.

Yeah, I'd +1 that.

Sounds good to me! Still catching up with all the mails.


Enhancement: Add explosive bombs along with edibles in the game

Prerequisites

[X] I am an Open Source Contributor
[X] I checked to make sure that this issue has not already been filed

Description
Feature Enhancement @ SloP 3.0
I've made an enhancement to the "Click The Edible Game" by introducing bombs and lifelines to the game. Currently, the game is about clicking as many edibles as possible within a set time frame. This enhancement adds a new challenge to the game.
Proposed Changes

[x] Introduce bombs as a part of the game.
[x] Limit the number of active bombs on the screen at any given time (MAX_number of bombs).
[x] When a user clicks an edible, there's a 50% chance a new bomb appears, provided the number of active bombs is below the maximum limit.
[x] Bombs have a limited lifespan, and if they are not clicked within a certain time, they disappear.
[x] Set a rule that if a user clicks on 3 bombs, the game is over, regardless of the remaining time on the timer.
[x] Implement UI elements to display the number of lives left.
[x] Integrate new sound and animation on bomb explosion.

Motivation
This change adds an exciting twist to the game by introducing the risk of bombs. Players need to balance clicking edibles for points and avoiding bombs to stay in the game. It adds an element of strategy and challenges players to manage their moves effectively.
Additional Notes
Please review this enhancement request, and if it aligns with the project's goals and standards, I'd be happy to create a pull request to implement these changes. Your feedback and guidance are highly appreciated.
Screenshots
Screen Shot 1

Screen Shot 2

Screen Shot 3

Code of Conduct

[X] I follow Contributing Guidelines of this project.

Assigned @SoumyadevSaha Proceed!!


Update version.weld to 3.1.9.Final

The latest weld version of the version 3 branch contains fixes regarding JDK 17 (for example WELD-2671). As the version 2 branch of weld-testing does not seem to regularly receive dependency updates, this currently forces us to add weld-se-core as an explicit dependency which we would like to avoid. We currently can't update beyond version 2 of weld-testing as the application server version we're using does not support CDI > 2.

Just like Weld 3, the weld-junit version 2 are not being developed anymore.
I can merge this PR but there is no release planned so it won't make a difference.

add weld-se-core as an explicit dependency which we would like to avoid

That's what you should actually do (except the shaded jar version might be more convenient) for other/newer versions too.
The idea is to explicitly align version used in your testing with the version you use in production app. The releases of weld-testing and weld itself were never dependent on each other.

Thanks for letting me know and also for the advice. I wasn't aware that there are no more releases planned for junit-weld.

Thanks for letting me know and also for the advice. I wasn't aware that there are no more releases planned for junit-weld.

There are going to be releases for newer version for sure - namely for those versions which align with currently developer Weld version (which is Weld 5 and 6).
That being said, I am not strictly against releases for older ones if it fixes some critical issue with weld-testing.


containerapp-compose extension not auto installing

Related command
containerapp compose
Extension name (the extension in question)
containerapp-compose
Description of issue (in as much detail as possible)
In the az containerapp compose doc, it says: "This reference is part of the containerapp-compose extension for the Azure CLI (version 2.15.0 or higher). The extension will automatically install the first time you run an az containerapp compose command. Learn more about extensions."
I am running Azure CLI version 2.39.0 and when I run az containerapp compose I get an error:
'compose' is misspelled or not recognized by the system.

@charris-msft please note that there is no compose sub group support for extension 'az containerapp'
'az containerapp-compose' is a separate extension so please use az container app-compose create as the command to run & use the extension. Thanks!

@panchagnula - It seems like the documentation should be updated then as it is referencing az containerapp compose:

closed it by accident - the help docs should be updated accordingly.

route to CXP team

@charris-msft Thanks for reaching out to us and reporting this issue. I can help in getting the docs updated.
@panchagnula Could you please confirm if the command is right ? Because I couldn't run it as the command wasn't recognized.

naveen@Azure:~$ az extension add -n containerapp-compose
The installed extension 'containerapp-compose' is in preview.

naveen@Azure:~$ az container app-compose create -e MyAppName -g MyRG
'app-compose' is misspelled or not recognized by the system.

Awaiting your reply.

@navba-MSFT - after some additional testing yesterday, the doc just need to be updated to include the action create.
If you don't have the containerapp-compose extension installed, and run the following it will prompt you to install the extension:
az containerapp compose create

Thanks @charris-msft . I will create the PR for the same tomorrow and update this thread.

@charris-msft Apologies for the delay in getting back.
I did some research on this and seems like the approach to file PR is not straight forward.

The above message comes from this templated docs reference pipeline and all the CLI extensions use the same templated message. The CLI page is based on a command group. One page is for a group of commands. So, the page displays the note with the command group 'az containerapp compose' .
I had reached out to the CLi docs team and they said they need to change the docs pipeline to support customized template for each extension. They will inform PM to track this request.
cc: @panchagnula If you have aware of any quick process to get this updated, please feel free to help.

@charris-msft I hope you had a chance to look at my above comment they don't have any ETA on when this would be fixed. We will update this thread once it is addressed.
@panchagnula Are you aware of any quick process to get this docs updated? please let me know.

@charris-msft I have looped you in an email thread with the PM team. That email has the workitem details to track the docs fix for this issue. Archiving this GitHub thread for now.


Ingress: No healthy upstream for headless service

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
If the Ingress is configured with a headless service like below, the response from the Ingress route is coming back as no healthy upstream. Ideally, the request should be coming IP (which is specified in Endpoint object of the headless Service)
apiVersion: v1
kind: Service
metadata:
  name: details-headless
  namespace: default
spec:
  ports:
  - name: http
    port: 9080
    protocol: TCP
    targetPort: 9080
  clusterIP: None
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
---
apiVersion: v1
kind: Endpoints
metadata:
  name: details-headless
  namespace: default
subsets:
- addresses:
  - ip: <IP_ADDRESS> # manually configure this Endpoints resource with valid backend IP
  ports:
  - name: http
    port: 9080
    protocol: TCP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: basic-ingress-headless
  namespace: default
spec:
  ingressClassName: cilium
  rules:
  - http:
      paths:
      - backend:
          service:
            name: details-headless
            port:
              number: 9080
        path: /details
        pathType: Prefix
---

Cilium Version
1.13.x
1.12.x
Kernel Version
N/A
Kubernetes Version
N/A
Sysdump
No response
Relevant log output
No response
Anything else?
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Upon investigating this issue, I found out that endpoint IP is not bumped to Envoy due to below code block, which skipped further processing of Service.
https://github.com/cilium/cilium/blob/07dea5d1da0337ff2e5c27ef993a1e8f5fa41047/pkg/k8s/watchers/watcher.go#L902-L904
Seems like it's a side effect of having shared code between Service watcher and Envoy
https://github.com/cilium/cilium/issues/19698

Move Envoy specifics from pkg/service to pkg/k8s/watchers, see https://github.com/cilium/cilium/pull/18894#discussion_r840633249

The workaround is to add dummy Service IP like below.
apiVersion: v1
kind: Service
metadata:
  name: details-headless
  namespace: default
spec:
  ports:
  - name: http
    port: 9080
    protocol: TCP
    targetPort: 9080
  clusterIP: <IP_ADDRESS> --> dummy IP, this should belong to service CIDR of cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack

Should be fixed by #25105 ?

yes, I am marking the above PR as draft to add e2e test.

@sayboras I'm hitting this problem on the latest v1.15.5. Are there any plans to get this addressed?

Thanks for your comment, the approach in mentioned PR is no longer ideal due to recent refactor and discussion.
I am currently exploring alternative options now.

@sayboras I appreciate the update. I'll be tuned in and please let me know how I can help testing.

Thanks, can you help to test out the changes in https://github.com/cilium/cilium/pull/32644, the image digests can be found in the below CI job:
https://github.com/cilium/cilium/actions/runs/9203017338/job/25314240955?pr=32644

@sayboras just to make sure I'll test it properly.
I need to replace the container image "cilium" by the "cilium-ci", right?
Do I need to replace the operator, clustermesh and all other images too?
Furthermore, I'm running envoy as a dedicated daemonset, but I don't see in that CI job the cilium-envoy. Is that OK?

I need to replace the container image "cilium" by the "cilium-ci", right? Do I need to replace the operator, clustermesh and all other images too?

Yes, you are right. For this change, the operator is not required to be updated, however, no harm to keep them in sync.

Furthermore, I'm running envoy as a dedicated daemonset, but I don't see in that CI job the cilium-envoy. Is that OK?

Cilium Envoy is built from cilium/proxy repo, no change is required.

@sayboras I was going to post on the PR but decided to do here instead. Not sure exactly the reason but this is pretty odd. I'm using a BGP Announcements on my cluster and as soon as changed the operator and the cilium images to CI, I cannot connect to the my HTTP Gateway (however other services exposed via Loadbalancer and shared via BGP are working). It seems something is up with the envoy gateway directly. Check it out:

Images and status

cilium status
    /¯¯\
 /¯¯\__/¯¯\    Cilium:             OK
 \__/¯¯\__/    Operator:           OK
 /¯¯\__/¯¯\    Envoy DaemonSet:    OK
 \__/¯¯\__/    Hubble Relay:       OK
    \__/       ClusterMesh:        OK

DaemonSet              cilium-envoy             Desired: 4, Ready: 4/4, Available: 4/4
Deployment             hubble-ui                Desired: 1, Ready: 1/1, Available: 1/1
Deployment             cilium-operator          Desired: 1, Ready: 1/1, Available: 1/1
Deployment             hubble-relay             Desired: 1, Ready: 1/1, Available: 1/1
DaemonSet              cilium                   Desired: 4, Ready: 4/4, Available: 4/4
Deployment             clustermesh-apiserver    Desired: 1, Ready: 1/1, Available: 1/1
Containers:            cilium-envoy             Running: 4
                       hubble-ui                Running: 1
                       clustermesh-apiserver    Running: 1
                       cilium-operator          Running: 1
                       hubble-relay             Running: 1
                       cilium                   Running: 4
Cluster Pods:          139/139 managed by Cilium
Helm chart version:
Image versions         hubble-ui                quay.io/cilium/hubble-ui:v0.13.0@sha256:7d663dc16538dd6e29061abd1047013a645e6e69c115e008bee9ea9fef9a6666: 1
                       hubble-ui                quay.io/cilium/hubble-ui-backend:v0.13.0@sha256:1e7657d997c5a48253bb8dc91ecee75b63018d16ff5e5797e5af367336bc8803: 1
                       clustermesh-apiserver    quay.io/cilium/clustermesh-apiserver:v1.15.5@sha256:914549caf4376a844b5e7696019182dd2a655b89d6a3cad10f9d0f9821759fd7: 2
                       cilium-operator          quay.io/cilium/operator-generic-ci:a83a327fd6663778cb3af62fb9254f05ef66206d@sha256:5edbb65701aec94e81c89613c0275b9584d7c73897f7c3185f4b6ce44e85fd53: 1
                       hubble-relay             quay.io/cilium/hubble-relay:v1.15.5@sha256:1d24b24e3477ccf9b5ad081827db635419c136a2bd84a3e60f37b26a38dd0781: 1
                       cilium                   quay.io/cilium/cilium-ci:a83a327fd6663778cb3af62fb9254f05ef66206d@sha256:8a6169c94371ec59ac4f3c431dc7c2606a37678b2398498d907a9f18928f0c7d: 4
                       cilium-envoy             quay.io/cilium/cilium-envoy:v1.28.3-31ec52ec5f2e4d28a8e19a0bfb872fa48cf7a515@sha256:bc8dcc3bc008e3a5aab98edb73a0985e6ef9469bda49d5bb3004c001c995c380: 4

Gateway up

kubectl get gateway -n public-gateway
NAME     CLASS    ADDRESS         PROGRAMMED   AGE
public   cilium   <IP_ADDRESS>   True         10d

kubectl get svc -n public-gateway
NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                      AGE
cilium-gateway-public   LoadBalancer   <IP_ADDRESS>   <IP_ADDRESS>   443:32005/TCP,80:30343/TCP   10d

BPG routes correct

cilium  bgp routes
(Defaulting to `available ipv4 unicast` routes, please see help for more options)

Node               VRouter   Prefix              NextHop   Age     Attrs
p53.tatu.home      64552     <IP_ADDRESS>/32    <IP_ADDRESS>   8m13s   [{Origin: i} {Nexthop: <IP_ADDRESS>}]

                   64552     <IP_ADDRESS>/32    <IP_ADDRESS>   8m13s   [{Origin: i} {Nexthop: <IP_ADDRESS>}]

                   64552     <IP_ADDRESS>/32    <IP_ADDRESS>   8m13s   [{Origin: i} {Nexthop: <IP_ADDRESS>}]

                   64552     <IP_ADDRESS>/32    <IP_ADDRESS>   8m13s   [{Origin: i} {Nexthop: <IP_ADDRESS>}]
p70.tatu.home      64552     <IP_ADDRESS>/32    <IP_ADDRESS>   7m52s   [{Origin: i} {Nexthop: <IP_ADDRESS>}]

                   64552     <IP_ADDRESS>/32    <IP_ADDRESS>   7m52s   [{Origin: i} {Nexthop: <IP_ADDRESS>}]

t470n1.tatu.home   64552     <IP_ADDRESS>/32    <IP_ADDRESS>   7m48s   [{Origin: i} {Nexthop: <IP_ADDRESS>}]
                   64552     <IP_ADDRESS>/32    <IP_ADDRESS>   7m48s   [{Origin: i} {Nexthop: <IP_ADDRESS>}]

t470n2.tatu.home   64552     <IP_ADDRESS>/32    <IP_ADDRESS>   8m11s   [{Origin: i} {Nexthop: <IP_ADDRESS>}]
                   64552     <IP_ADDRESS>/32    <IP_ADDRESS>   8m11s   [{Origin: i} {Nexthop: <IP_ADDRESS>}]

Other services exposed working

❯ kubectl get svc -n default postgresql-toca
NAME              TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)          AGE
postgresql-toca   LoadBalancer   <IP_ADDRESS>   <IP_ADDRESS>   5432:30557/TCP   5d21h

❯ psql -h <IP_ADDRESS>
psql (16.2, server 15.2 (Debian 15.2-1.pgdg110+1))
Type "help" for help.

postgres=#

HTTPRoute is accepted

kubectl describe httproutes.gateway.networking.k8s.io  -n mattermost mattermost-public
Name:         mattermost-public
Namespace:    mattermost
Labels:       app.kubernetes.io/instance=mattermost
Annotations:  <none>
API Version:  gateway.networking.k8s.io/v1
Kind:         HTTPRoute
Metadata:
  Creation Timestamp:  2024-05-20T16:33:47Z
  Generation:          7
  Resource Version:    857653081
  UID:                 9164c8f7-3b7b-4877-ba85-7515e5df1ab4
Spec:
  Parent Refs:
    Group:         gateway.networking.k8s.io
    Kind:          Gateway
    Name:          public
    Namespace:     public-gateway
    Section Name:  https-main
  Rules:
    Backend Refs:
      Group:
      Kind:    Service
      Name:    mmtatu-workaround
      Port:    8065
      Weight:  1
    Matches:
      Path:
        Type:   PathPrefix
        Value:  /mmgtest
Status:
  Parents:
    Conditions:
      Last Transition Time:  2024-05-25T14:43:30Z
      Message:               Accepted HTTPRoute
      Observed Generation:   7
      Reason:                Accepted
      Status:                True
      Type:                  Accepted
      Last Transition Time:  2024-05-25T14:43:30Z
      Message:               Service reference is valid
      Observed Generation:   7
      Reason:                ResolvedRefs
      Status:                True
      Type:                  ResolvedRefs
    Controller Name:         io.cilium/gateway-controller
    Parent Ref:
      Group:         gateway.networking.k8s.io
      Kind:          Gateway
      Name:          public
      Namespace:     public-gateway
      Section Name:  https-main
Events:              <none>

But connection is failing to reach out TCP 443

nc -vv <IP_ADDRESS> 443
nc: connect to <IP_ADDRESS> port 443 (tcp) failed: Connection refused

curl -v https://internal.host/mmgtest/
* Host internal.host:443 was resolved.
* IPv6: (none)
* IPv4: <IP_ADDRESS>
*   Trying <IP_ADDRESS>:443...
* connect to <IP_ADDRESS> port 443 from <IP_ADDRESS> port 52498 failed: Connection refused
* Failed to connect to internal.host port 443 after 20 ms: Couldn't connect to server
* Closing connection
curl: (7) Failed to connect to internal.host port 443 after 20 ms: Couldn't connect to server

I also disabled the envoy as a dedicated daemonset and the result was the same.
However, restoring back the original image works again (however, the problem with the headless service remains as expected).
Any ideas?

:wave:
Most likely it's related to BGP Announcements IMO, the CI tests are actually having the similar setup, can you cross check if there is any discrepancy which could cause issue :thinking:
https://github.com/cilium/cilium/blob/c52bee974efe8ae9196355c5ab44d7278468c6d3/.github/workflows/conformance-ingress.yaml#L223

@sayboras :wave:
Yes, I can confirm the issue was related with L2 announcements. I had to disable STP on my switches to get the ARP announcements to work. I was hitting several TCP Spurious Retransmissions but it seems to be better now. Thanks for working on that fix! :1st_place_medal:


#Vulcan-132/Clear parameter value of Parameter select chart on tab change

Problem
Parameter select reports allow interactivity as users can select parameters/values from the autocomplete dropdown. When a parameter is selected, the selection stays active until the browser tab (that is, the dashboard) is closed, no matter if the dashboard tab is changed. So, my users wanted a functionality to set the parameter select chart type that gets cleared when there is a tab change.
Solution
Introduced a clearParameterValueOnTabChange boolean in settings. When this is enabled the value in the parameter is set to empty.
Screenshot

NOTICE:
The program was tested solely for our own use cases, which might differ from yours.
Author Info: Monish<EMAIL_ADDRESS>on behalf of Mercedes-Benz Research and Development India
https://github.com/mercedes-benz/mercedes-benz-foss/blob/master/PROVIDER_INFORMATION.md

Hello @m-o-n-i-s-h, i see that you have a code smell from your SonarCloud, but i can't open it. Could you please check it?

@alfredorubin96 addressed the code smell.


App crashes on initialisation when I release appbundle

Version of flutter_inapp_purchase
0.9.2
Platforms you faced the error (IOS or Android or both?)
Android
I initialise billing as in the example and if I run the app on my device/emulator everything works fine. As soon as I release the app using appbundle I get crash on initialisation. If I build and release apk everything works fine.
Is anyone facing the same issue?

I've posted deprecation note today since I think it is quite useless when official plugin is released.

@hyochan I wish you'd kept this project going it's much better than the offical one. Also the official one has so many bugs :-/ (Cannot continue translation for example)

@hyochan I can only agree with @ollydixon , the 'official' in_app_purchase package is more than useless. My main gripe is the sheer amount of bugs and undocumented behavior and most notably the fact that almost every action (initialization etc.) that previously in your package took only one step now takes several to make it work.

@stemuk and that the official one doesn't even return proper promises or refresh consumerables on iOS (Current major bug). It has a crappy Stream.listen fail..

@stemuk @ollydixon Thanks for the feed back. Alright then I'll try to continue working on it and release you one this weekend.

@hyochan thank you.

@ollydixon @stemuk Sorry that I've had a hard time maintaining other projects so I wasn't able to take my time here. I am back now and I actually want to get the feedback again not to waste my time.
Is the official library still bad? Do you still think this should be maintained?

@hyochan they are still bad but managable. They have many bugs and hard ways to implement things that should be easy.

Please give any other comments on this so I can get motivated to work on this.

Official plugin is unusable man, we need you!

Totally agree with ziggycrane!  My app is ready to be released except for in-app purchases and the official version will not work.  Thanks in advance!

Hi everyone~ I am planning for a new release starting from 2.0.0. Currently work in progress in #94.

Looks like I've just released<EMAIL_ADDRESS>which is a sunrise 🌅 ! Some features are not tested yet but I've tested new purchase flow.

2.0.0+ has raised today. Please feel free to reopen after trying out 2.0.0+5 or above.

Hi - I'm planning to build inApp subscription purchasing - just a few questions :-
a) is this plugin still being maintained
b) is it recommended to use this plugin or the official one ?
c) does this support latest iOS 13 release ?
Lastly what is the recommended way using this plugin to take (say) a 'free/lite' app and expose all FULL features of an app once a subscription has been purchased - I couldnt see any examples of the plugin that showed a technique for this.
Thank you

Looks like the official plugin still does not support basic features like upgrading/downgrading between subscriptions. Please keep working on this! (and maybe we should convince the Google Flutter team to simply adopt this plugin instead of working on their duplicate)

Hope you continue working on this, great work

Hi - I'm planning to build inApp subscription purchasing - just a few questions :-
a) is this plugin still being maintained
b) is it recommended to use this plugin or the official one ?
c) does this support latest iOS 13 release ?
Lastly what is the recommended way using this plugin to take (say) a 'free/lite' app and expose all FULL features of an app once a subscription has been purchased - I couldnt see any examples of the plugin that showed a technique for this.
Thank you

I also would like to know

Just a word to tell you to keep up the amazing work you've been doing, you're saving a lots of us at the moment since the official plugin is unusable on iOS.

Can confirm. Our startup lost an incredible amount of time trying to make the official plugin work. Well, it doesn't, at least for iOS. This does not bode well for Flutter as a platform when the Google developers spend time on porting stuff to the web before make their libraries official code work.
Please, keep up the good work. Until the rest of us are well versed enough in this platform, it is up to you to keep it alive. Thank you.

@averstuyf @schankam I would also like to add to this, usually don't hijack issue forms like this but I had to. We tried to implement the official plugin for more than 9 apps now and we've always had to revert back to this plugin. Keep up the good work, it works flawlessly for us on iOS and Android; what next Web? 😂🥳 (Maybe using a Stripe plugin?)

There are a lot of problems with the official plugin. This plugin is excellent！

Even today, you cannot perform downgrades or upgrades on Android, nor can you handle promo codes through the in_app_purchase. It's incredible.

Is this plugin no longer maintained?
Many questions have been reported for a long time but no one has responded.


make client functions pub so they can be used in other projects

i'd like to include rough time logic in my own rust code rather than have a standalone binary
it would be nice if the client functions were pub

nm i cobbled something together


Return non-zero exit code if failures are detected

I've recently started using Travis CI and noticed uses the exit code to determine whether or not a build/test succeeded. Deliberately breaking one of my tests showed that node-qunit was continuing to return an exit code of 0  with failed tests present.
This gist shows one way to tweak the exit code when failures are detected: https://gist.github.com/1492339
This is an issue with a patch, rather than a pull request, as I'm not sure if calling process.exit() again from within a process' exit event is a recommended thing to do, but it does seem to work.

thanks., will change that


Angular-CLI-Based-Template: It seems that it compiles all TS files for Platform Server

@SteveSandersonMS It seems that the new Angular CLI based template always compiles all TS files for Platform Server.
Angular CLI allows multiple apps to exists in same project through apps array, and usually we don't enable SSR for our complete application rather its mostly enabled for the portion that is safe to run on server side and usually for the sections that are the entry points for users.
If we look at apps array in  .angular-cli it has two apps one for the client app and other for ssr. For app ssr we have "tsconfig": "tsconfig.app-ssr.json", and "main": "main.server.ts",
So as per my understanding, while building server bundles it should start from AppServerModule and recursively process files referenced in this module.
But it seems that it always compiles all files for platform server. Which breaks the app when we debug, and throws error like this.:
NodeInvocationException: Prerendering failed because of error: D:\MyProject\ClientApp\node_modules\ng2-img-cropper\src\imageCropperComponent.js:1
(function (exports, require, module, __filename, __dirname) { import { Component, Input, Renderer, ViewChild, Output, EventEmitter } from '@angular/core';

In this case I am using imageCropperComponent in BrowserAppModule only.

It's set up in the way recommended by Angular CLI docs: https://github.com/angular/angular-cli/wiki/stories-universal-rendering We don't have any further control over how the CLI does the build.
If you think there's a specific different way it should be set up, could you let me know what change you think should be made and why? Thanks!

Thank you @SteveSandersonMS for the clarification, I solved it by adding exclude setting in tsconfig.app-ssr.json


i18n added and used in drawer component

Feature: i18n Internationalisation
This PR implements i18n. A dropdown/picker has been added to select the language. The text on the screen changes as per selected laguage.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Thank you Nice Work!
Can you add the dependencies needed?
Also make sure you test the tv app across different TVs platforms: at least Android TV, tvOS and web.
Check if the component is focusable and navigable by using the remote (or the keyboard in case of web.
As it's a TV app it's important to provide a component usable from the distance and with a TV friendly design.
Check https://developer.android.com/design/ui/tv/samples/jet-stream for some inspiration.

@Neha I have updated the PR as per your comment.

@giolaq @Neha I am getting an error on tvOS simulator
Invariant Violation: requireNativeComponent: "RNCPicker" was not found in the UIManager.
Although I have replaced Picker with RNPickerSelect. I am still trying to find the fix for it.

@giolaq @Neha I am getting an error on tvOS simulator Invariant Violation: requireNativeComponent: "RNCPicker" was not found in the UIManager.
Although I have replaced Picker with RNPickerSelect. I am still trying to find the fix for it.

Thank you @madhushree007 . Can you share where the language selector will be placed? and how the UI will look.

What about putting the language choices in a Setting Screen? I think it's the right place for all the configurations.

@giolaq Do we have a Setting Screen? Or shall I create one?
Perhaps we could have something similar to this

I've created this to implement the Setting Screen


[WIP] Connection result

Please do not merge,
This is the solution I thought about, please have a look,

For example, for users I can imagine something similar to this code :
PS: you are right, I need to fix the style each time.
For the Mavlink class,  you can choose any another name that you find appropriate. Now, it is hidden from the user side.  However, if you have any other ideas about how to expose the Mavlink class, (for example merge it with another classes) I would like to hear from you
int main(int argc, char **argv)
{
    DronecodeSDK dc;
    Connection connect;
    std::string connection_url;
    Connection::Result connection_result;

    if (argc == 2) {
        connection_url = argv[1];
        connection_result = connect.add_any_connection(connection_url);
        //we can rename the above function to the following
        connection_result = connect.create_connection(connection_url);
        connection_result = connect.create_tcp_connection(connection_url);
        connection_result = connect.create_udp_connection(connection_url);

    } else {
        usage(argv[0]);
        return 1;
    }

    if (connection_result != Connection::Result::SUCCESS) {
        std::cout << ERROR_CONSOLE_TEXT
                  << "Connection failed: " << connect.result_str(connection_result)
                  << NORMAL_CONSOLE_TEXT << std::endl;
        return 1;
    }

    // Wait for the system to connect via heartbeat
    while (!dc.is_connected()) {
        std::cout << "Wait for system to connect via heartbeat" << std::endl;
        sleep_for(seconds(1));
    }
   // users can get the system discovered and use the plugin..
  // users code.....
}

So how is dc connected with connect?
To me it seems like we want something like this:
DronecodeSDK dc;
UdpConnection udp_connection(14540);
dc.add_connection(udp_connection);

However, the problem I see here is that we have no return argument for the constructor so we can't communicate that sometimes creating a connection fails. (We could use exceptions but I decided not to use exceptions in this library.)

Also, you should start off with latest develop, otherwise you get conflicts to merge this.

Hmm, Actually I though about moving the connection functions from DronecodeSDK class to another
class that is called Connection as you can see in the merge request.
If you want really to have something like
DronecodeSDK dc;
UdpConnection udp_connection(14540);
dc.add_connection(udp_connection);

I think I need to rethink another solution, because in this case we are implementing the pimpl for the class connection and we are no using it.
Maybe I think I did not understand well your proposal.

I think I need to rethink another solution, because in this case we are implementing the pimpl for the class connection and we are no using it.

We are not using it? I don't understand how dronecode_sdk_impl.cpp is talking to the connection in your case.

I am separating dronecode_sdk_impl.cpp from connection.cpp. Thus, a user is going to use dronecodeSDK only to verify if the system is connected or not, the dronecodeSDK will not manage at all
the connection, even it is going to be a connection Independent.

@shrit ok and how does the SDK get the messages delivered?

Ah, you are right. We need to think about it..

I'm not sure what to do here. Maybe at some point in the future we can revisit the API but I'm closing this for now. Thanks for your contributions nevertheless @shrit!

No problem, I also did not have free time to look at it into details,


Feature request: Allow grouping of items in the QuickPick input just like the git branches view

It would be nice to allow grouping of QuickPickItems.
Currently one can see this in the git checkout branch list. There are the local and the remote branches grouped and separated with a small line.

dupe of  #11468


The image uploader

I'm currently following this tutorial Handling upload image to implement the image uploader. I have trouble with the last step, the docs said I must have to apply this line ContentTools.IMAGE_UPLOADER = imageUploader; into my code. But I don't know where to put this line in my code. My code refers to this post #246 . Could you show me where the line I can put my code? Thanks.

Hello,
I've implemented ContentTools image uploading successfully. After you've included ContentTools, start your own

Hey, I've found the problem. thanks for your help


Undefined symbols for architecture x86_64:  "ds::Device::create(ds::DeviceType, ds::Option)"

just trying to build a simple HelloWorld app using depth sensor.   since i cannot find a documentation or sample anywhere, I just started with some simple code:
#include "DepthSensor.h"

ds::DeviceRef mDevice;

void depthApp::setup()
{
    ds::DeviceType type = ds::DeviceType(0);
    ds::Option option;
    option.enableDepth = true;
    option.enableInfrared = false;

    mDevice = ds::Device::create(type, option);
// mDevice = ds::Device::create(type);

}

this line  mDevice = ds::Device::create(type, option); gives me this error:

Undefined symbols for architecture x86_64:
"ds::Device::create(ds::DeviceType, ds::Option)", referenced from:
depthApp::setup() in depthApp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

The project was freshly built using Tinderbox, the code I posted above is really the only thing I added.
I am not sure if this is caused by the Block or my build settings or my misuse of the library. Since I am relatively new to c++, I apologize if this is not an issue to this repo.

Have you built Cinder-DepthSensor.lib?
https://github.com/jing-interactive/Cinder-DepthSensor#how-to-build

sorry for some reason I overlooked the how-to-build part. after the clone i just went straight to TinderBox, I haven't tried but I think this should fix it!

gonna jump on this thread. I've tried the above code to get started but also running into probelms. I have built, but perhaps theres steps im missing. could you please be more specific on how the build is supposed to be done.
Also do you have any sample/example code just to see how to get up and running


Typo Correction

Fixed typo in second paragraph

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

Looks good; thanks, @robyyo


[BUG] Rewrite how Analyzer Issues are parsed into their respective tasks

The calling code for an incident should not care about the underlying types and should know what to do with them. This should be a class method.

https://github.com/konveyor/kai/blob/main/kai/reactive_codeplanner/task_runner/compiler/maven_validator.py#L120-L143


Add input_binding_is_valid()

input_binding_is_valid(binding, player = 0)
Returns true/false indicating whether the given player (defaulting to 0 if unspecified) is able to use the given binding. The device that this funciton checks against is determined firstly by the type of binding (keyboard/mouse/gamepad) and secondarily by hardware-specific limitations. In the case of gamepads this is simply what buttons/axes are available. In the case of keyboards, what inputs are available is determined as much by per-platform quirks as what keys are on the keyboard.
At any rate, this function will allow for dev-side confirmation of what bindings are reasonable for players. This functionality already exists implicitly in the binding system so exposing it to the dev will allow for more flexible (custom) binding systems to be written for less common use cases.

keyboard key validity: greater than 7, less than 255 (utf8), not blocked
gamepad button/axis validity: gamepad slot nonempty, gamepad not blocked, specified field found in map, or device unmappd

#260

Accepted PR https://github.com/JujuAdams/Input/pull/260


Polish style in setup.py.

CAPITAL symbols should be reserved for constants.
Import things more deeply to keep code itself shorter and more readable.
There's no need to explain what a setup.py is.

(Opening this for Travis because I can't get the tests to pass locally.)

tox -esa should report your style errors, https://travis-ci.org/erikrose/blessings/jobs/60041972
setup.py
Line: 1
pep257: D100 / Missing docstring in public module
Line: 12
pep257: D203 / 1 blank line required before class docstring (found 0)
Line: 33
pep257: D203 / 1 blank line required before class docstring (found 0)
Line: 42
pylint: invalid-name / Invalid constant name "kwargs"

I think we should remove pep257 or at least turn it way down. It's spouting nonsense, and this isn't its first violation. Remember that craziness about __all__ needing to be a tuple? Requiring a docstring in setup.py is like requiring every module to start with a comment saying "This is a Python module".

I am saddened that you feel to throw away pep257 and pep8 conventions for the entire project just because you feel setup.py, or your own stylistic choices are exempt.
How does following style standards hurt? Does 'kwargs' really become more readable than 'KWARGS' or get_extra_kwargs()? does a module-level docstring hurt the readability of the project any?
(And I absolutely feel that __all__ should be a tuple)

Consistent conventions are important—though never more important than human comprehensibilty. Remember that a foolish consistency is the hobgoblin of little minds. In particular, a docstring with no informational content is just noise—worse than no docstring at all. I'm aware that automated style checkers are all the rage at the moment, but, apart from ferreting out the most egregious offenses, they just cause arguments like this one and waste people's time. So I'm not a big fan, but I'm happy to leave them on at some low level if they make you happy.

And making __all__ a tuple does nothing. The pep257 author is not a very experienced Python programmer if he ignores the possibility that __all__ could later be rebound.

I will push ignoring setup.py to prospector.yaml if that satisfies this PR.

I suspect there will be more. Is one of the tools going to object if I remove the skipped line between class names and docstrings, for example at https://github.com/erikrose/blessings/blob/blessed-integration/blessings/terminal.py#L64 ? I'm literally trying to conform to a PEP's example here: https://www.python.org/dev/peps/pep-0257/#multi-line-docstrings. I've never seen anybody format code like that and assume one of the tools forced you into it.

Do whatever you want, man.

I'll see if I can turn the tools down to a less zealous level. (Pointers are welcome; I don't typically use tooling.) I'm happy to meet you halfway to make this merge work, which I think is best for the users.


Detecting BPM without touching the sensor?

This is my code on GitHub: https://github.com/george-i/Adafruit-Flora---PulseSensorAmped
I've adapted the code to work with Flora, however, on the serial it prints various values without even touching the sensor.
After I touch the sensor, it looks like the bpm is adjusting, but then suddenly changes.
Any idea what's going on?

There isn't very much noise reduction in the Pulse Sensor Amped code. So it is reacting to small noise fluctuations in the ambient light when it's not touching your finger. To fix this, you will need to add some noise cancelling code. There is a varialbe, called 'amp' in the interrupt code. That variable is updated every time the Pulse Sensor finds a beat. You can use a threshold on that value to limit the size of the 'pulse' signal that you want the sensor to react to.
This is something that we're working on...

I understand.
On the other hand, when I touch the sensor the value is very high.
I have a strap heart rate monitor and I figured it out that I have to divide to 2, to have similar value.
I don't know why...

what development board are you using with the Pulse Sensor? You may need to
change some of the code to get the bpm right.
Making the world safe for robots

On Wed, Oct 28, 2015 at 2:58 PM, George Ilie<EMAIL_ADDRESS>wrote:

> I understand.
>
> On the other hand, when I touch the sensor the value is very high.
> I have a strap heart rate monitor and I figured it out that I have to
> divide to 2, to have similar value.
> I don't know why...
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/WorldFamousElectronics/PulseSensor_Amped_Arduino/issues/13#issuecomment-151955522>
> .
>

Adafruit Flora, based on ATmega32u4.
I did the changes (detailed here: http://forum.arduino.cc/index.php?topic=355957.0).

You don't need to use the analogReference(EXTERNAL); unless you are using
two different power supplies. If the whole system is running at 3.3V, then
don't include that line of code.
What clock speed is the Flora running at?
J
Making the world safe for robots

On Thu, Oct 29, 2015 at 1:11 AM, George Ilie<EMAIL_ADDRESS>wrote:

> Adafruit Flora, based on ATmega32u4.
> I did the changes (detailed here:
> http://forum.arduino.cc/index.php?topic=355957.0).
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/WorldFamousElectronics/PulseSensor_Amped_Arduino/issues/13#issuecomment-152077074>
> .
>


Describe the bug
npm run build is showing warnings because of react-icon-cloud
To Reproduce
Steps to reproduce the behavior:

Go to terminal
run command: 'npm run build'
it will show warnings
See error

Expected behavior
It shouldn't happen because I have uploaded my app on vercel using github repo and vercel is not able to handle it so showing failed.
Screenshots

Desktop (please complete the following information):

OS: [e.g. Windows 11]
Browser [e.g. chrome]

@vishalqalandari903 Is it fixed, or have you tried removing your node_modules folder and running npm install again? Please try that and let me know if it resolves the issue.


bump wownero to v<IP_ADDRESS>

hard fork scheduled for 1st April (block no. 514,000)

Sorting through an
make[2]: *** No rule to make target '/home/user/src/stack_wallet/crypto_plugins/flutter_libmonero/scripts/linux/cmakefiles/wownero/x86_64/../../../build/prefix_x86_64/lib/wownero/libwallet_api.a', needed by 'libcw_wownero.so'.  Stop.

error here

on Linux desktop*


Updated valid seasons

I was having trouble getting the newest seasons data so I looked up the new season ids and here is a patch. Also, I wanted to pass season around as a string so I added a parse int

thanks!

Oh no problem. Glad I could help :)
On Sat, Apr 25, 2015 at 2:01 AM, Claudio Wilson<EMAIL_ADDRESS>wrote:

thanks!
—
Reply to this email directly or view it on GitHub
https://github.com/claudiowilson/LeagueJS/pull/33#issuecomment-96144819.

--
Jake


Import automation: import progress dashboard frontend client

This PR adds the client for the import progress dashboard at https://dashboard-frontend-dot-datcom-data.uc.r.appspot.com/.
I used create-react-app to bootstrap the app. The only file written (partly) by me is import-table.tsx.
I know very little about React, JavaScript, and TypeScript. I would really appreciate it if you could be direct in what needs to be changed and perhaps give some hints on how.
Thanks for reviewing.

@rsned @shifucun @beets This PR contains JavaScript and needs a review. Would you be willing to review? Thanks


Fix references to undefined relations in a ComputedSubjectSet or TupleToSubjectSet

A ComputedSubjectSet or TupleToSubjectSet rewrite rule shouldn’t be able to reference an undefined relation when updating a namespace configuration. Right now this is a possible, and it will lead to errors.

I see two logical ways to resolve this issue:

Rework Namespace configs altogether such that the namespace config API has put based semantics, and in the event that a relation is removed from a config, any tuples referencing it are ignored in the reachability graph. If the relation were subsequently added back at a later time, any residual tuples referencing it would be reinstated or (alternatively) async cleanup all tuples referencing relations that were removed at up to some time stamp.

2: Only allow relations to be appended and their rewrites updated. No removal of relations once they've been introduced. Validate the relation updates such that they don't introduce references to undefined relations at the revision time stamp.


bump double conversion to 1.1.6

bump double conversion to 1.1.6.
Version 1.1.2 added ARM 64 support, so it's a step to add support for 64bit in RN.
Test Plan:
Everything will build and run as usual

@hramos please merge 😄


README: overhaul file structure

In order to make the README information more clear this patch overhaul
its structure and update its content to match the current state of the
tool.
Signed-off-by: Bruno Meneguele<EMAIL_ADDRESS>Fix #777 .
This PR semantically depends on PR #809 being merged, otherwise some recommendations won't work as expected.

@zaquestion once PR #809 and this one here are merged, could you update the project "About" text dropping the "Lab wraps Git and Hub" part?

Might be worth adding a table of contents while you're at it, Readme has gotta a lot longer since the early days

Oh, sure, I'll add the toc :)

@zaquestion I just realized that GitHub itself has a table of contents in the left of readme's filename:

It was released mid last year. With that I think we don't really need to have a specific toc in our doc.

Lol.. I'm pretty sure a README file change don't affect a build testing:
409 {message: {base: [PG::QueryCanceled: ERROR:  canceling statement due to statement timeout

And I'm almost sure it's not client's problem (error 40x) .. hahaha.

@zaquestion I just realized that GitHub itself has a table of contents in the left of readme's filename:
It was released mid last year. With that I think we don't really need to have a specific toc in our doc.

Does GitLab support that? If not, It's not worth the work IMO, as we are moving soon™ to GitLab.

GitLab requires an explicit toc with [[_TOC_]].
Since it's different for github we can change it once we migrate to GitLab.

@zaquestion once PR https://github.com/zaquestion/lab/pull/809 and this one here are merged, could you update the project "About" text dropping the "Lab wraps Git and Hub" part? I don't have permission to do so.

Can do, feel free to email me if I forget / fail to notice this merge.

@zaquestion once PR #809 and this one here are merged, could you update the project "About" text dropping the "Lab wraps Git and Hub" part? I don't have permission to do so.

Can do, feel free to email me if I forget / fail to notice this merge.

:-) ack! Will do.

@zaquestion, just fyi.. you can now update project's description. I'm hitting the merge button right now.


Spawn quiesces if rabbitmq cannot emit messages.

The rabbitmq network enters an unhappy state if messages are being produced and not consumed. But the cluster is in a very bad state when messages can no longer be produced. When messages are dropped on the floor the cluster can enter an inconsistent state. This automatically quiesces the cluster to minimize the damage. Ref T54274.
This pull request branches from https://github.com/addthis/hydra/pull/168

some of the comments on the other one apply here as well. they look at least more reasonable than before so fine with merging spose


Ignore non-existing /Shading resources during parsing (issue 18765)

Slightly smaller diff with https://github.com/mozilla/pdf.js/pull/18766/files?w=1

/botio test

/botio makeref