Types for enum variants

Edit: this RFC is now only about variant types, the unions stuff is removed in favour of #1444
This is something of a two-part RFC, it proposes

making enum variants first-class types,
untagged enums (aka unions).

The latter is part of the motivation for the former and relies on the former to
be ergonomic.
In the service of making variant types work, there is some digression into
default type parameters for functions. However, that needs its own RFC to be
spec'ed properly.

#[repr(union)]
enum X {
    A {
        alpha: u8,
    },
    B(u8),
}

struct Y {
    x: X,
}

Given y: Y, how do I access alpha?

@mahkoh
fn foo(y: Y) {
    let a = unsafe { y.x as X::A };
    println!("alpha: {}", a.alpha);
}

@nrc This means that modifying any field in a union in a struct requires

Copying the union field out of the struct,
Making the modification,
Copying the field back into the struct.

In the presence of nested unions, repeat. This seems to be extremely inefficient and unergonomic since unions are very often used as struct fields.

Furthermore, what happens if the union doesn't implement Copy?

Should work by reference too:
fn foo(mut y: Y) {
    let a = unsafe { &mut y.x as &mut X::A };
    *a = 42;
}

I should add casts of the reference types to the RFC too.

Also I believe that one of your arguments against the other RFC was that it requires unsafe code even if you already know the variant. This can be easily solved by taking the idea from this RFC and applying it to the other RFC:
union X {
    f1: T1,
    f2: T2,
}

let x: X = ...
let y: &T1 = unsafe { &x as &T1 };

Let's look at a simple example of a union I already deal with in winapi.
https://github.com/retep998/winapi-rs/blob/master/src/wincon.rs#L17-L25
The original in C looks like:
typedef struct _KEY_EVENT_RECORD {
    BOOL bKeyDown;
    WORD wRepeatCount;
    WORD wVirtualKeyCode;
    WORD wVirtualScanCode;
    union {
        WCHAR UnicodeChar;
        CHAR   AsciiChar;
    } uChar;
    DWORD dwControlKeyState;
} KEY_EVENT_RECORD;

Under this RFC in Rust it would look like:
STRUCT!{struct KEY_EVENT_RECORD {
    bKeyDown: ::BOOL,
    wRepeatCount: ::WORD,
    wVirtualKeyCode: ::WORD,
    wVirtualScanCode: ::WORD,
    uChar: KEY_EVENT_RECORD_uChar,
    dwControlKeyState: ::DWORD,
}}
#[repr(union)] enum KEY_EVENT_RECORD_uChar {
    UnicodeChar(::WCHAR),
    AsciiChar(::CHAR),
}

Since I cannot conveniently import UnicodeChar into the global namespace (union variants are not in the global namespace in C so there may be other identifiers with the same name) that means users would have to fully specify that type, which is kinda ugly:
let x: KEY_EVENT_RECORD = ...;
let y = x.uChar as KEY_EVENT_RECORD_uChar::UnicodeChar;

Meanwhile in C someone could just do x.uChar.UnicodeChar. They can even mutate the variant in place instead of having to do x.uchar = KEY_EVENT_RECORD_uChar::UnicodeChar(foo).

@retep998 I don't think that direct field access is a very Rust-y solution - it's an unsafe operation which doesn't indicate why/in what way it is unsafe. I think the casting should extend to (mutable) references, and within a scope you can bring in enum variants as types, so you have a clear two line solution instead of an unclear one solution, which seems not too bad:
fn foo(x: KEY_EVENT_RECORD) {
    use KEY_EVENT_RECORD_uChar::*;

    let y = unsafe { &mut x.uChar as &mut UnicodeChar };
    y.0 = 42;
}

You could stick that all on one line if you like, but I admit that gets pretty ugly.

I don't think that direct field access is a very Rust-y solution - it's an unsafe operation which doesn't indicate why/in what way it is unsafe

The same applies to calling an unsafe method.

You could stick that all on one line if you like

You have to do either that or introduce another scope due to lexical lifetimes. More realistically, the code would look like this:
fn f(mut x: Struct1) {
    x.f1 = 0;
    {
        use KEY_EVENT_RECORD_uChar::*;

        let y = unsafe { &mut x.f2 as &mut Variant1 };
        y.0 = 42;
    }
    g(&x);
}

And when you have nested enums then it gets really funny.

Tbqh, if this is the union accepted union implementation, then I'll just continue to do what I do right now: Add two methods per variant (variant, variant_mut) and transmute the passed reference. Code like that already works and it will be shorter than this. The only thing gained by this implementation is that one can have a type with the correct size and alignment. But once ctfe becomes better, that will be possible without this implementation too.

I love this proposal, thank you for coming up with it. It still needs a little work, but it is the best thing I've seen so far and works well in the fledgeling memory model that will be released soon.

Here is an alternative proposal for syntax on unions, anything but final but as a rough idea:
struct KEY_EVENT_RECORD {
    bKeyDown: ::BOOL,
    wRepeatCount: ::WORD,
    wVirtualKeyCode: ::WORD,
    wVirtualScanCode: ::WORD,
    uChar: KEY_EVENT_RECORD_uChar,
    dwControlKeyState: ::DWORD,
}

c_union KEY_EVENT_RECORD_uChar {
    unicode_char: ::WCHAR,
    ascii_char: ::CHAR,
}

// Accessing:
let mut record = foo();
{
    // Immutable Ref
    let unicode_c = unsafe { record.wChar.as_unicode_char() };
}
{
    // Mutable Ref
    let ascii_c = unsafe { record.wChar.as_ascii_char_mut() };
}

Setting is still undetermined. My main issue with this syntax would be that adding methods feels too magic-y for rust, but I feel they're important to communicate what's unsafe about what's being done. I want to try to fit in a #[derive(_)] in there to mitigate that, but c_union wouldn't have any use without the derive so it feels wrong to add it.

I could see this going a few ways:
// This is a simplified struct from WinAPI
#[repr(union)]
enum tagVARIANTvariant {
    llVal(LONGLONG),
    lVal(LONG),
    bVal(BYTE),
    iVal(SHORT),
}

#[repr(union)]
enum tagVARIANTtag {
    __tagVARIANT {
        vt: VARTYPE,
        variant: tagVARIANTvariant,
    },
    // other fields here I've taken out
}

struct tagVARIANT {
    tag: tagVARIANTtag,
}

fn test() {
    let x: tagVARIANT;
    // This is the safest bet. However, it's also a pain to use, and it's unlikely that FFI people
    // will go along with it
    (x.tag as tagVARIANTtag::__tagVARIANT).vt = LLVAL;
    (x.tag as tagVARIANTtag::__tagVARIANT).variant = tagVARIANTvariant::llval(100);

    // We could also automatically import the types. This is backwards compatible in the `as` field,
    // although I'm less certain about the = field. This would also make normal enums nicer to use,
    // and I've heard talk of doing this with match statements.
    (x.tag as __tagVARIANT).vt = LLVAL;
    (x.tag as __tagVARIANT).variant = llval(100);

    // This is the last suggestion, and my least favorite. However, if we can't find a solution, we
    // may have to go with it :/
    x.tag.__tagVARIANT.vt = LLVAL;
    x.tag.__tagVARIANT.variant = tagVARIANTvariant::llval(100);
}

To clarify what I'm talking about with match statements, some have talked about:
enum E {
    Var0,
    Var1,
}

match E { // this would be okay, despite never `use`ing Var0 or Var1
    Var0 => {},
    Var1 => {},
}

There is also a need for non-anonymous variants. E.g.
#[repr(C)]
struct TagVariant {
    vt: VARTYPE,
    variant: tagVARIANTvariant,
}

#[repr(union)]
enum tagVARIANTtag {
    __tagVARIANT: TagVariant,
    // other fields here I've taken out
}

@mahkoh That's covered by tagVARIANTvariant.

@ubsan So every access additionally requires a .0?

@mahkoh If you're doing it that way, yes, I assume.

This RFC deals with two orthogonal issues:

Allowing enum variants to be used as types
Allowing the discriminant to be removed from enums

Therefore it should be split into two RFCs.

I agree with @mahkoh, as I believe that enum variants as types is less controversial of a feature, and it's an important step towards empowering ADT hierarchies.

There is a lot here. I'll just try to write some comments as I digest (and catch up on the already lengthy comment thread).
First, I'm not a big fan of foo as Variant downcasting. It's good for unions but kind of "bad style" elsewhere and I'm not sure we need to add it; I'd prefer to encourage people to write if let or match, just as they do today.
Second, I would love to have variants be types, but the integration described in the RFC sounded a bit rougher than I would like. I guess I have to process it more, as the RFC has a number of particular mechanisms, and it's hard for me to judge if they are good choices or not. This may also be something we can also expect to hammer on and experiment with in the implementation phase, but it'd be good to think hard about the rough edges that we expect to emerge.
Finally, on the topic if unions in particular. It's certainly the case that a #[repr(union)] annotation feels more natural on an enum than on a struct, but I also find something in #1444 very appealing. Certainly it's a much more targeted addition, which I like. I also like that you use field projection foo.bar to select which variant you want -- it feels like an "active selection", whereas matching does not. (as, admittedly, feels good too -- but then as seems to be sugar for match, and match feels wrong, since I expect that in a match the compiler will pick which arm, not me.)

My two cents, from the perspective of a PLT hobbyist:

The idea of treating enum branches as their own types is well-founded in theory. If you treat tags as type constructors, they have the particularity that two non-equal tags construct two provably disjoint types. Then enums are simply unions of provably disjoint types, and structs are simply intersections of provably disjoint types.

From the above perspective, a C-style union is a union of possibly overlapping types where discriminating between the types is handled by the programmer (and hence unsafe); an unsafe enum of sorts. There is a dual construction of unsafe struct: a struct with potentially overlapping fields whose construction is unsafe, but whose observation (field access) is safe.

Treating tags as first-class type constructors opens the way for structural subtyping of enums and structs, whether safe or unsafe. For an example of how this can be done, look up OCaml's row polymorphism - an implementation of structural subtyping of structs.

PLT-wise, my single biggest gripe against Rust is not implementing the above perspective on enums and structs.

structs are not intersections of types, but a Cartesian product of types. The difference small, but important.

Ticki: can you explain how an intersection of types differs from a cartesian product of types in the case where the underlying types are disjoint?

Fixed, thanks.

I have decided I was wrong and that unions are better represented as structs than enums. The reason is that accessing unions with field access rather than casting (itself an innovation) is more ergonomic in all circumstances I can think of. The sole advantage of the enum approach seems to boil down to declaring a whole data structure inline, which seems not so important.
My intuition now is that the distinguishing feature of a data type should not be its representation but its access pattern - accessed via matching means it's an enum, accessing via field access means it's a struct. We can't match on a union, and field access is better than casting. Put another way, we layout structs in many ways already, we are just adding another way (albeit a more dramatic change). Others have said all of this in the thread on #1444. I'll update this RFC to purely be about variant types.

One thing I'm not clear on regarding impl's on variant types.
enum Foo {
    Bar(i32),
    Baz(f32),
}

impl Foo::Bar {
    fn parity(&self) -> bool { self.0 & 1 == 0 }
}

fn main() {
    let x: Foo = ...;
    // Under what circumstances is x.parity() callable?
}

Specifically:

Is x.parity() callable inside of a match arm that witnesses Foo::Bar?
Is x.parity() always callable, and the compiler generates a match that may panic (partial matching, feels iffy)?
Is x.parity() callable if and only if the compiler can prove x holds the Bar variant?
Is x.parity() not callable?

@eternaleye AFAIK, the answer is at most "on a @ binding" (or a binding with type ascription).
Keep in mind that Foo::Bar is a type by itself and you can hold it between creation and until it needs to become Foo.
Also, once you have that binding of a Foo::Bar type, you could pass it around with that type as much as you want.

@eternaleye only on an @ binding, even then the compiler probably needs some further hint to infer the correct type (I'm not actually sure if the compiler will use method calls as part of type inference).
So, fn parity(x: Foo::Bar) would work in either a match arm with @ or after let x = Foo::Bar;. Not sure about your parity method example. But certainly your options 2 and 4 are not true. Option 3 is only true in the sense that the proof must come from a type annotation somewhere, via inference.

I would like this, in fact I actually assumed this was already the case. Here's my use case, if it helps:
I'm modeling a value from a dynamically typed language (specifically JSON from JavaScript) with an enum that resembles implementations from rustc-serialize and serde_json. I'd like to add methods to different types with an impl Value::String for example. Something I'd really like to do is implement traits for certain enum variants. MongoDB's BSON format for example has a Document type, I'd like to have a matching pair of impl From<Document> for Value::Object and impl Into<Document> for Value::Object. I'd also like to have an iterator of only one type, so Iterator<Item=Value::Object> for instance. The enum I'm currently using is below.
enum Value {
  Null,
  Boolean(bool),
  I64(i64),
  F64(f64),
  String(String),
  Object(LinearMap<Key, Value>),
  Array(Vec<Value>)
}

To have enum variants as first class types in rust would be very nice, thanks everyone 😊

This is good, really good, but can this be shipped before the removal of #![allow(private_in_public)]? Otherwise I won't be able to ship this hack after the removal of private_in_public but while waiting for this feature, and I kinda rely on that hack...

This would be really really useful. Right now you have to write a lot of boilerplate to achieve the same.

oh, pretty cool! i wanted that when trying to represent a XML dialect as rust types

An update on where we are at here: we discussed this a bit at last weeks lang team meeting, which was just @nikomatsakis and I. We're still keen, but there are issues with the interaction with default type parameters, etc.:

The type of variant constructor functions uses default type parameters, but we are not sure that we can support these (c.f., default type parameters on data types).
Even if allowed, exactly what the rules would look like is currently unclear.
We still haven't made much progress deciding the efficient inheritance question, which might affect things here.

We discussed the details of type checking. Assuming enum Foo {Bar, Baz}, when we find let x = Foo::Bar; we will assign a fresh type variable (say $0) as the type of x, this type variable is constrained to the two types Foo and Foo::Bar. If inference unifies $0 with either Foo or Foo::Bar, then inference is done. If we unify with both, there is a type error. If we unify with neither, then we fallback to Foo.
Note that we do not infer based on impls, so if we have x.m() where m is only defined for an impl of Foo::Bar, then there will be a method not found error because we will fallback to Foo for which there is no m. This can be fixed by using let x: Foo::Bar = Foo::Bar;.
Further note, that there is another issue with default type parameters here:
enum Foo { Bar, Baz }
struct Qux<T = Foo::bar>(T);
fn main() {
    let y = Qux(Foo::Bar);
}

Clearly, y has type Qux<_>, but what is the type parameter? There are conflicting defaults: Foo from the variant type fallback, and Foo::Bar from the default type parameter on Qux.
To summarise, progress on this RFC is blocked on at least progress on the default type parameter question, and perhaps also efficient inheritance.

The  macros named EnumFromInner' and ' EnumInnerAsTrait' from the wonderful rust-custom-derive` crate solves some of the inconvieniences  that lead to this RFC. Perhaps they should be discussed under alternatives.

https://danielkeep.github.io/rust-custom-derive/doc/enum_derive/index.html
https://github.com/DanielKeep/rust-custom-derive

Note to self, following discussion on IRC, I should remove downcasts - can always use match/if let.
To check: do we need implicit 'upcast' coercions?

Just to clarify: what @nrc and I were discussing was basically the idea of adding a new kind of inference variable, roughly analogous to integer literal variables, to represent an "enum variant variable". This would indicate that the type is not free to be anything but must be some variant of a given enum type.
(It seems like in general there may be more than two choices, though, since one could have nested enums -- if not in this RFC, then potentially in the future.)

I am wary of this feature. I feel like its hard to convincingly justify my objection, but here's an attempt.
I suspect that many of the use cases of this feature are actually antipatterns and that Rust should discourage them. I'm not sure what the correct way to describe the antipattern code authors may fall into - perhaps "leaky abstraction" or "violating parametricity." In my head, I describe it as "variegated polymorphism" - a polymorphic abstraction is applied unevenly across the code.
As an example of what I mean, someone is writing a chess simulator, and comes up with the Piece abstraction. The procedure for handling a moving a piece works something like this (these examples are psuedocode that look a lot like Rust):
// Move the piece to that position
piece.move_to(position);
// Remove any enemy piece in that position
if let Some(piece) = enemy_pieces.find(|piece| piece.position() == position) {
    piece.remove();
}

Of course, this doesn't account for en passant. So the code author produces something like this instead:
// Move the piece to that position
piece.move_to(position);
// En passant handling
if let pawn: Pawn = piece {
    if pawn.could_en_passant() {
        ...
    }
}
// Remove any enemy piece in that position
if let Some(piece) = enemy_pieces.find(|piece| piece.position() == position) {
    piece.remove();
}

A procedure that was supposed to deal with every piece using the piece abstraction now has special code for handling pawns. I think it would be much better if the code author had refactored the Piece abstraction in order to be able to account for en passant.
In other languages, different forms of ad hoc polymorphism are often used in this way. I think traits are a very awesome feature specifically because they avoid this problem, and I'm glad that Rust doesn't feature the traditional 'ad hoc' polymorphisms of object oriented languages.
Currently, Rust provides two ways of defining the "piece" abstraction - enums and traits. Enums allow you to reflect over the piece type wherever you want, because they can always be matched into their variants. Traits, on the other hand, require you to treat all implementing types consistently, compelling you to fix your abstraction when it doesn't cover all the possibilities.
Often as code grows in complexity, code authors realize an enum has become unwieldy, and they want to refactor it into a set of types with trait relationships, parameterizing different code paths as appropriate. I'm worried that this RFC would encourage users not to upgrade their enum to a trait, and instead just implement methods on individual variant types, pushing them toward variant reflecting conditional pasta.

@withoutboats:
As a counterpoint, I'll point to the differences in API between Haskell's Language.C AST, and Clang's AST.
Language.C very much works according to the "enum" model, while Clang's works very much in the "trait" model (or rather, trait object). The enum model is wonderful for totality and extracting information, but requires quite a bit of boilerplate if you are operating on a single known variant. Meanwhile. the trait model works very well for operating on one type if you can downcast, but even then is quite painful in terms of enumeration and totality.
Moreover, in Rust, downcasting is... really not much of a thing. The closest is TryInto<T>, which is decidedly unergonomic - you wind up needing to pull out an enum, match against it to figure out what the type is, then TryInto. Collections of traits are also quite painful.
However, with enum-variants-as-types, the situation changes quite a bit - one has the ease of enumeration and extracting data from the enum model, but once one has matched the variant, one can treat it as a perfectly ordinary type.
To be honest, I think this RFC would really come into its own if we had anonymous/hierarchical sum types of some sort - not only allowing enums to be decomposed into types, but composed from them.
The ability to do something like this:
enum Foo<T, E> {
    Bar(i32),
    Baz: enum {
        Qux,
        Corge(usize),
    },
    Grault: Result<T, E>,
}

would, in my opinion, make almost any AST-like task considerably more ergonomic (where one could refer to Foo::Baz::Qux, say), as opposed to the current situation - and with hierarchical sum types like this, the ability to treat members as types becomes much more useful.

Moreover, in Rust, downcasting is... really not much of a thing. The closest is TryInto, which is decidedly unergonomic - you wind up needing to pull out an enum, match against it to figure out what the type is, then TryInto. Collections of traits are also quite painful.

However, with enum-variants-as-types, the situation changes quite a bit - one has the ease of enumeration and extracting data from the enum model, but once one has matched the variant, one can treat it as a perfectly ordinary type.

I think you've misunderstood me. I understand and agree that this is what enums make it easier to do, but my point is that usually making use of this 'feature' tends toward code which is coupled in deep and non obvious ways, and therefore more difficult to maintain, extend, and refactor. For this reason I think that this is probably a misfeature.

No, I get that, but I disagree - and plain enums, absent the ability to write code that takes only one vartant at the type level, force me to write match boilerplate repeatedly - almost as much as downcast boilerplate would!

and plain enums, absent the ability to write code that takes only one vartant at the type level, force me to write match boilerplate repeatedly

Which I perceive usually as a positive pressure to refactor. :-)

My argument is that there is no ergonomic form to refactor to, as it stands.

I would like this with downcasts being done with an @-binding on a match.
Upcasts being coercions works fairly well, but seeing the backwards-compat hacks we would have to make almost convinces me that we want proper covariant subtyping (e.g. subtyping would solve the variant constructor problem) - it would not be very terrible, as the subtyping action is still restricted to scalars.
OTOH, variant inference defaulting is basically subtyping sans variance, and might work fairly well (with the type Option<_> being Option<_, Variant=⊤>, Option::Some being an <T, variant V> where variant Some: variant V. fn(T) -> Option<T, Variant=V>). In the interesting cases, trait inference or whatever would force the choice - treating the variant as a separate type variable should allow inference to proceed unless someone adds impls that branch on it.
Critical here is that the relation variant Foo: variant Bar is treated like a trait relationship, and is delayed. When coercing, Foo<Variant=X> should always be converted to Foo<Variant=$v0> where variant $v0: variant X.
BTW, do we want to do this on deref-coercions too? Otherwise you can't pass a &Option::Some<u32> to a function expecting an &Option<u32>. But this brings us very close to subtyping.
One further annoying issue is that in
match foo {
    ref mut x @ Some(_) => {},
   ...
}

Either foo or foo as Some is borrowed, leading to the types &mut Option<_,, Variant=∅> or  &mut Option<_,, Variant=Some>, and obviously neither is a subtype of the other. This should be resolved at the MIR level, but it is an exception to patterns not being ambiguous.

@withoutboats This is not about extensible or abstracted code in the public interface of libraries.
It's about non-extensible ADT hierarchies in applications (or the private implementations of libraries).
Every bit of rustc or servo is deeply coupled with every other bit, that's its nature.
There's no need for them to be extensible, they have one job and they must do it well.
For example, it's impossible to support new types (e.g. impl Trait) in rustc or new DOM classes in servo in a pluggable way - every piece of logic in the application needs new custom behavior - in some places it may be similar to another existing feature, in other places to a different one.
Making all of that extensible would be a pointless exercise in performance loss only to appease some expression problem ideal.
Getting rid of boilerplate makes code easier to read and maintain, as long as you know "the house rules",
which right now are much worse than they could be with a streamlined ADT hierarchy.

Also, I think using nested enums with variants-as-types provides a very useful model of a closed 'tree' of types, which one can traverse downwards by matching.

Indeed - enums, even with some sort of "subtyping", are still not classes, because of the non-extensible nature of their variant set and that is good.
Effectively, a closed set of types that you can partition however you want (eventually) and you get to choose the behavior for every combination of "type" (variant) and operation that you need to perform.
Every of those behaviors can be accounted for and that is good.
Maybe that "good" qualifier only applies in large enough applications and Rust is too biased against
small projects? That is a point you could make, yes, although nothing is being removed here.

Which I perceive usually as a positive pressure to refactor. :-)

What would you suggest we refactor the ADTs used in rustc (ASTs, the typesystem, MIR, etc.) to?

This should be resolved at the MIR level, but it is an exception to patterns not being ambiguous.

I don't see how the type is not &mut {Option<_>, Option<_>::Some}, with inference picking something based on how it's used, or where it comes from.

I don't see how the type is not &mut {Option<_>, Option<_>::Some}, with inference picking something based on how it's used, or where it comes from.

Because today patterns are always definite about the type they return. I don't think it will be much of a problem.

@eternaleye To be fair, I've written code with many nested enough which incurs no performance or totality penalty, but makes every literal/match take way more constructors.

This is not about extensible or abstracted code in the public interface of libraries.
It's about non-extensible ADT hierarchies in applications (or the private implementations of libraries).

Every bit of rustc or servo is deeply coupled with every other bit, that's its nature.
There's no need for them to be extensible, they have one job and they must do it well.

I don't work on rustc or servo, so I can't comment on those applications in particular, but this seems to be a general comment about the design of application code, and its one that I could not disagree with more strongly. I'm shocked by it, honestly!
Decoupling the components of your system from one another and making your system extensible are essential for effectively and productively adapting your system to evolving requirements. Its an effort to avoid technical debt and spaghetti code. It has nothing to do with writing libraries.

Language ASTs and the DOM are a sort of exceptional situation; most applications aren't dealing with highly irregular tree structures like these that inherently lend themselves to large, nested enums. I don't work on code that uses structures like this, so I can't really comment on this example. But I believe that in most cases, for most users, their problem domain is not inherently a big irregular tree, but that this feature will encourage the bad practice of representing their problem in that way.

Another benefit of this is that enum switching in the MIR is closer to being made safe. See https://github.com/Ericson2314/a-stateful-mir-for-rust#enum-switch . That also leads the way to dynamic drop being desugared into stack vars Option.

@withoutboats
But not many problems are described by a set of computation-bearing objects either. Enums are natural when you want to model your world as data with functions and procedures operating over it. Objects are natural when you want to model your world as a set of objects that need to be taken care of.

@arielb1 We're talking about traits vs enums, not necessarily objects (I've evolved an enum to a trait without introducing any additional dynamic dispatch to the system).  The important thing is that as your system grows the language pressures you to move toward parametric abstractions.

@withoutboats I would argue the more parametric approach isn't always the better approach. Often, it is more complicated, with little reward.

Heterogeneous containers can only be manipulated with ADTs (closed set) or dynamic dispatch (open set). Anything that deals with mixing a closed set of possible choices has to make a tradeoff between performance and extensibility - and the latter is completely unnecessary in many situations, so you'd lose performance for no real gain.

@ubsan of course! My claim is that as systems grow larger, the more parametric approach becomes much better for maintenance, but that users are reluctant to perform that refactor, because it is often dramatic. My concern with this feature is that it would give users an 'easy out' to the pressures that are telling them to refactor, extending the enum approach beyond its appropriate bounds, and (in the worse case) creating a tangle that is now much more difficult to refactor because of how it has grown.
@eddyb The first sentence your comment is definitely true. I'm interested in finding paths toward closed sets of instances that allows them to be avoid virtualization costs while still maintaining the advantages that traits have. That said, I would contend, as many did on the dyn trait RFC, that this 'performance penality' is usually not relevant (even in Rust's domain space) and you should use benchmarks to find out if trait objects are actually a bottleneck for your use case.

@withoutboats: It's not the performance overhead.  It's that you now cannot avoid allocation for heterogeneous containers. You can't have a Vec of any unsized type, so they need to be allocated elsewhere, which means you either use Box, or you use references and now have to juggle lifetimes, and the ergonomics go straight down the toilet for zero benefit whatsoever.

I don't understand, avoiding allocations is a performance optimization, so it is the performance overhead.
We're talking past each other, and I'm not particularly enjoying hearing what I think is important for good design dismissed as "zero benefit," "no real gain," "a pointless exercise." I think there are larger disagreements about programming and languages which this RFC is not an ideal venue for hashing out.

Having made such an argument against this, I now of course have a case where I want it (or a more targeted subset of it perhaps).
I have some types and statics with roughly this shape:
enum Foo {
    Bar,
    Baz(char),
}

static DEFAULT_FOO: &'static Foo = &Foo::Bar;

struct FooCollection(Vec<Foo>);

impl Index<usize> for FooCollection {
    type Output = Foo;
    fn index(&self, idx: usize) -> &Foo {
        self.0.get(idx).unwrap_or(DEFAULT_FOO)
    }
}

Now I want to add a variant to Foo:
enum Foo {
    Bar,
    Baz(char),
    Quux(RefCell<String>),
}

This introduces an error, because Foo is now !Sync. It would be unsound to provide the impl Sync for Foo, because the Quux variant is not Sync. But the variant that needs to be Sync, the Foo variant, is.
My only solution right now is to replace the RefCell with a RwLock. But I woud be fine with Foo not being Sync, so long as I could still have a static reference to a variant that would be Sync.

@withoutboats Use const instead of static - what you have isn't really a static usecase anyway.

There are a couple issues around enums where people seemingly want zero boilerplate, but the proposals seem warty and maybe just "thoughtfully" making the boilerplate "canonical" might help.
In this case, there are situations where you do not want to represent a known variant with the full enum, although maybe they just want a nicer vesion of the wrapped_enum macro.
I could imagine deriving  impls for a VariantOf<E> trait making enums like
struct FooT(...);
struct BarT { ... };

#[derive(variant_of)]
enum FooBar {
    Foo(FooT),
    Bar(BarT),
}

#[derive(variant_of)]
enum FooBarBaz {
    Foo(FooT),
    Bar(BarT),
    Baz { ... }
}

Now if your function wants an explicit variant then it wants the bound VariantOf<E>.  If otoh it wants any variant then it wants another bound VariantsOf<E> that roughly corresponds to VariantOf<E> + E, maybe
pub trait VariantsOf<E> {
    fn as_a_variant(Self) -> E;
}
default impl<T> VariantsOf<T> for T { ... }
default impl<T> VariantsOf<E> for T where T: VariantOf<E> { ... }

It's not necessarily bad that you must explicitly write out
impl VariantsOf<FooBarBaz> for FooBar;

ping @nrc
Status?

While we may want to do something along these lines eventually, given the roadmap I think there is more pressing work on the language side, and this RFC has stalled. Thus:
@rfcbot fcp postpone

IMO, this falls clearly under the ergonomics category of the roadmap. However, this is blocked on further investigating default type params, so it probably makes sense to postpone for now.

default type params

NOOOOOO 😭

So, I have a plan for handling defaults in the newer trait system in a semi-sane way. It's not I guess all that different from what we do now -- basically we would run to a steady state with no extra heuristics, than have various heuristics we can use to go into our list of pending work and make semi-arbitrary choices (i.e., if you have a coercion ?X := i32 and ?X is unconstrained, we might decide that ?X = i32 and then attempt to make progress). Combined with what I hope will be a reasonable strategy for caching work and thus helping with incremental computation, this could make everything work out relatively nicely. It seems readily applicable here: the type of a variant would be a variable which (when things stall) gets heuristically set to the enum itself.

@nikomatsakis What's the ordering oracle? For coercions, I thought an easy way to get backwards-compatibility was to always default the first in AST order (that is, the one we'd reach first today).

(From https://users.rust-lang.org/t/enum-variants-as-types/9196 ). A code example of handling enum variants as types:
enum Foo { A, B(u32) }

fn bar1() -> Foo::A {
    Foo::A
}

fn bar2(x: Foo::A) {
}

impl Foo {
    fn bar3(&mut self: Foo::B(ref mut)) {
        match self {
            &mut Foo::B(ref mut x) => *x += 1;
        }
    }
}

fn main() {}

This code means that (unlike Haskell) you can't call bar2() with a Foo. You must call it with a Foo::A.
This feature can speed up some code (because some unwrap() get removed or become a no-op), make some code more provably correct (because you have more static information about the values, so you don't need to handle some impossible cases), and can avoid some usages of Option/Result (because the code has to handle less impossible cases).

fn main() {
    let mut f: Foo = Foo::A;
    match f {
        Foo::A => (),
        x @ Foo:B(_) => f.inc(), // flow typing?
    }
}

Wouldn't that mostly be covered by the @ syntax already?

@skade No, x is of type Foo, not of type Foo::B.

@withoutboats must that be the case with this RFC?
From my stateful MIR, I am interested in full flow-sensative typing / typestate / whatever you want to call it, but this seems like a good, intuitive first step rather than huge leap! :)

@withoutboats That seems to contradict this post from @nrc, which says that exactly the syntax @skade used would in fact allow Foo::B methods to be called on x. (And that it may in fact be one of the only ways to do so.)

@Ericson2314 @eternaleye Well, but thinking further, @withoutboats might be right, as this might give rise to a subtle subtyping relationship, if Foo:B declares a method of the same name as Foo.

One can always repack and pack a variant, but stuff like the following is especially interesting:
match f {
    x @ &mut Foo::A(..) => ... (x: &mut Foo::A) ...,
    x @ &mut Foo::B(..) => ... (x: &mut Foo::B) ...,
}

Sorry, I was confused about the context. I thought @skade was saying that @ covers the use case of this RFC.

I don't have need for unions, but I came here to cheer for the enum types.
struct Celsius(i32);
struct Fahrenheit(i32);

enum Temperature {
     Celsius(i32),
     Fahrenheit(i32),
}

I'd love if this just worked and the structs were interchangeable with the enum variants.

I'm going to go ahead and close this as postponed. I think it's pretty clear we'll want to revisit this design space in the future, but we have higher priorities right now.

In the language community I came from, devs of course work on the higher priorities, but they don't randomly close down valid issues (especially ones being actively discussed on), like this one. So I don't agree with closing this down. This discourages discussions, development of ideas and other volunteers working in parallel to the main devs.

@leonardo-m People should absolutely feel free to continue discussing on the http://internals.rust-lang.org/ forum. But in the Rust community, RFCs represent a specific, concrete proposal for a change, and we try to respond to those proposals with some amount of clarity on their likelihood of being accepted, which is connected to their priority. (See the roadmap for the community's priorities in 2017.)
I'll note also that this closure wasn't "random": it began a month ago, with the formal FCP process (https://github.com/rust-lang/rfcs/pull/1450#issuecomment-271042602), which involves a signoff from everyone on the language subteam -- including the author of this RFC. There's only so much bandwidth and complexity budget available, and the team is responsible for managing that balance.

I concur with @bchallenor... this seems like a highly desirable feature, and one that we're at a good point to implement, if I'm not mistaken.

The "postponed" issue for this RFC was never created, so I've made one - https://github.com/rust-lang/rfcs/issues/2347.

Any chance of this being revisited soon?

For the sake of posterity. The following pattern combined with crates such as https://github.com/JelteF/derive_more and https://github.com/DanielKeep/rust-custom-derive allows you to do some of the stuff mentioned in the RFC.
struct Variant1( i32, String );
struct Variant2 { f1: i32, f2: String };

pub enum Foo {
    Variant1(Variant1),
    Variant2(Variant2),
}

So if the RFC is revived, then the pattern should probably be discussed under alternatives.

@nrc Any chance of getting this RFC reopened now, and potentially merged soon? I have a couple of things I'm working on now, but I'd be willing to take this on afterwards perhaps.

@alexreg You'd probably need to ask @nikomatsakis about the status of what'd be needed to implement this.

Okay, hopefully @nikomatsakis will see this comment and reply here.

"Safe unions", non-lexical &move liveness, and non-lexical enum variant type are all related. I'd love to have all 3!

I have a question regarding enum variants as types, is this correct?
fn main() {
    use std::mem::size_of;
    assert_eq!(size_of::<Option<u32>>(), 8);
    assert_eq!(size_of::<Some<u32>>(), 4);
}

@leonardo-m I don't think so, since we'd want to allow coercing &Some<u32> to &Option<u32>, which means it must already be the full size of the enum and have the tag set to 1.

@Ericson2314 Is there a proposal for "safe unions"? I don't know what that means. Unless perhaps it's similar to one of the ideas suggested here. No idea what the other two mean either. :-P

I would love to see this get in at some point in the future. Allowing for variants to impl traits on their own would be a nice alternative to requiring a match to essentially do the same.
I'm beginning to use enum variants to help represent states in a state machine and this would go a long way in making the experience a bit better, mainly with regard to code organization.
The pattern referenced above by @nielsle is valid and I have tried it out. IMO it's not nearly as readable/understandable or even maintainable as supporting variants as first class types would be. I've actually stuck with using pure enum variants as opposed to that pattern because of this.

@jeffreydecker 	I think a bunch of us would like the feature! Fancy writing an RFC? ;-) You could easily get some help from folks here or on Discord, I reckon.

The blocking thing for this feature is properly understanding default type parameters and the interaction with the various kinds of fallbacks to defaults (e.g., numeric fallbacks). I think once we understand that a bit better, then we could re-open this RFC (or something like it).

Ah, fair enough.

There is another concern in that refinement types would ideally extend enum variant types and be useful for formal verification, so an RFC would ideally consider those possible future directions.

I think that would be coming a very long way off, if ever... probably not worth much thought at this point.

I've submitted an RFC to follow up on this one and permit enum variants to be treated as types:
Enum variant types


option to enable/disable adaptiveStream for an element

By default adaptiveStream can be enable/disable using global variable. In certain case may need to disable/enable adaptive steam for single tracks. For example one video element need to put in PiP but because of adaptiveStream if user move to another tab or window then the stream will be pause. To prevent this I had made stopObservingElement public & another new function startObservingElement for triggering the element manually.

Yes, that will be fine. But I think have option to manually trigger to stop/start observation will be also good idea. In certain case it will be helpful. Also the changed I have done won't affect any other code of this library.

@lukasIO any thoughts on this? I can't use pip.

Hi jibon,
sorry for the late reply! Very happy to add the PiP event listeners to make adaptive stream aware of it, but I'm not entirely convinced that exposing the methods in this PR is the right move.
It will increase API surface for a very narrow use case, plus a bunch of testing would be needed to make sure that every call sequence would still behave as expected. On top of that we would arguably have to introduce additional state that makes adaptiveStream a track based setting (because that's what watching/unwatching does effectively) while currently it's a room level setting.

@jibon57 opened https://github.com/livekit/client-sdk-js/pull/622 to address this and also noticed that you should probably work around the issue completely when setting { adaptiveStream: { pauseVideoInBackground: false } } on the room options

@lukasIO having option to disable adaptive Stream for any video track would be helpful for certain cases not just for pip. It's fine for me as I can do customization for my application.


Add an example CMakeLists.txt for building projects and add it to documentation

We need to add an example CMakeLists.txt for the projects, say for hello_world, and explain in the docs how to use it for building the project and the arguments to cmake.

@mode89 can you please help us with this?

Hi @hkashyap. Sure, I'll do it the next week.


suggestion: separate object deletion commands

kubectl delete deployment,svc mysql is not a viable command and could be confusing for learners trying to clean their workspace.
Separating the command into two lines simplifies the clean-up process for readers.

Thanks @alex-pakalniskis for your suggestion, mentioned page - https://kubernetes.io/docs/tasks/run-application/run-single-instance-stateful-application/#deleting-a-deployment.

@alex-pakalniskis, There are many more examples like kubectl delete deployment,svc mysql in Kubernetes docs, I think most users are already accustomed to these commands.

/retitle Split a combined deletion command in "Run a Single-Instance Stateful Application"


Could not evaluate: undefined method `[]' for nil:NilClass

Affected Puppet, Ruby, OS and module versions/distributions

Puppet: puppetserver-7.12.0-1.el8.noarch; puppet-agent 7.25.0-1focal
Ruby: ruby-2.7.8-139.module+el8.8.0+1320+d2449f6f.x86_64; the one that comes with puppet-agent
Distribution: rocky linux 8/ubuntu focal fossa
Module version: straight from git, up to date with master.

How to reproduce (e.g Puppet code you use)
  sysctl { 'kernel.yama.ptrace_scope':
    ensure => present,
    value  => '0',
    target => '/etc/sysctl.d/10-ptrace.conf',
    comment => 'Closes #24182',
  }

  sysctl { 'kernel.core_pattern':
    ensure => present,
    value  => 'core-%p-%E',
    target => '/etc/sysctl.d/10-core_pattern.conf',
    comment => 'Closes #28134',
  }

What are you seeing
Error: /Stage[main]/Buildhost/Sysctl[kernel.yama.ptrace_scope]: Could not evaluate: undefined method `[]' for nil:NilClass
Error: /Stage[main]/Buildhost/Sysctl[kernel.core_pattern]: Could not evaluate: undefined method `[]' for nil:NilClass

What behaviour did you expect instead
Output log
Any additional information you'd like to impart

ok, scratch that. Updating the rest of the modules fixed the issue.


Added a convinence wrapper for making IOptions instances

Useful for passing poco TOptions to APIs that take IOptions<TOptions>

#106
/cc @HaoK @divega @DamianEdwards

Issues may arise if users register IOptions<T> in the container. It'll overwrite the OptionsManager<T> implementation.

I think it might be okay as they would likely register IOptions<MyOptions> not IOptions<> which would only override a specific option type perhaps?

@HaoK True.

:up: :date:

A bit orthogonal to this, we should maybe rename the normal implementation class OptionsManager => SingletonOptions if we are going to have multiple IOptions implementations by default now.
SingletonOptions<>
OptionsWrapper<>
OptionsMonitor<>
Options.Create<>

SharedOptions sounds good actually.

Ok I can do the rename to SharedOptions in a seperate PR

:shipit: looks good to me

Why does SharedOptions sound good?
I like three change otherwise, registering a closed generic was always intended as a way to "take control" if you have a special case.

@lodejard is ConfigurableOptions<T> better?

I was just trying to suggest some names that give a bit more meaning to what OptionsManager does.
OptionsManager is a very generic name that doesn't convey any of the usage semantics, not as big a deal when it was the only IOptions, but now that we also have OptionsWrapper...
OptionsManager is really the shared/cached implementation of IOptions, while the wrapper is a stand alone instance of IOptions that you would use when you don't want to cache...
OptionsMonitor aka Reloadable options is kind of a third implementation but it doesn't implement IOptions yet (we have an issue tracking whether it makes sense to unify IOptionsMonitor/IOptions https://github.com/aspnet/Options/issues/100)


fix: random fixes, mostly medium severity issues

@IlCallo, all looks good (went through the code changes, and tested the ui), I left you a comment in the code. We have a misbehaving dense header between viewports 600px (xs-max) and 900px.

Will fix, I need to rebase to include the theme switcher anyway


vscode setting warning  'Matches multiple schemas when only one must validate.'

settings.json:
"stylusSupremacy.sortProperties": "grouped",
file: 'file:///Users/sldobri/Library/Application%20Support/Code/User/settings.json'
severity: 'Warning'
message: 'Matches multiple schemas when only one must validate.'
at: '130,37'
source: ''

add issue in https://github.com/ThisIsManta/vscode-stylus-supremacy/issues/13


cupy.cuda.compiler.CompileException: nvrtc: error: failed to load builtins

First of all thanks you did an amazing job!
I've tried to run the repo, CPU version is running normally took 553 sec fr 1080p image. But GPU version is giving me below error. Can you help?
Traceback (most recent call last):
  File "generate.py", line 45, in <module>
    y = model(x)
  File "/home/kadia/Documents/chainer-fast-neuralstyle-resize-conv/net.py", line 55, in __call__
    h = self.b1(F.elu(self.c1(x)))
  File "/usr/local/lib/python2.7/dist-packages/chainer/functions/activation/elu.py", line 116, in elu
    return ELU(alpha=alpha).apply((x,))[0]
  File "/usr/local/lib/python2.7/dist-packages/chainer/function_node.py", line 258, in apply
    outputs = self.forward(in_data)
  File "/usr/local/lib/python2.7/dist-packages/chainer/function_node.py", line 367, in forward
    return self.forward_gpu(inputs)
  File "/usr/local/lib/python2.7/dist-packages/chainer/functions/activation/elu.py", line 34, in forward_gpu
    x[0], self.alpha)
  File "cupy/core/elementwise.pxi", line 592, in cupy.core.core.ElementwiseKernel.__call__
  File "cupy/util.pyx", line 39, in cupy.util.memoize.decorator.ret
  File "cupy/core/elementwise.pxi", line 443, in cupy.core.core._get_elementwise_kernel
  File "cupy/core/elementwise.pxi", line 13, in cupy.core.core._get_simple_elementwise_kernel
  File "cupy/core/elementwise.pxi", line 33, in cupy.core.core._get_simple_elementwise_kernel
  File "cupy/core/carray.pxi", line 146, in cupy.core.core.compile_with_cache
  File "/usr/local/lib/python2.7/dist-packages/cupy/cuda/compiler.py", line 135, in compile_with_cache
    base = _preprocess('', options, arch)
  File "/usr/local/lib/python2.7/dist-packages/cupy/cuda/compiler.py", line 98, in _preprocess
    result = prog.compile(options)
  File "/usr/local/lib/python2.7/dist-packages/cupy/cuda/compiler.py", line 245, in compile
    raise CompileException(log, self.src, self.name, options)
cupy.cuda.compiler.CompileException: nvrtc: error: failed to load builtins

Closing this issue. Solved by just reconfiguring the CUDA on system

@neelkadia What did you do to solve the issue? By re-configuring you mean re-installing? I am facing the same error, can you please guide me.

Try export LD_LIBRARY_PATH="/usr/local/cuda/lib64:$LD_LIBRARY_PATH"

@Orkat  thanks for your answer ，but why this work？

@neelkadia  How did you solve this question ？I have met same issue

LD_LIBRARY_PATH is not supposed to be used in a production setting. This is not a good option.


Unhandled Rejection TypeError

Unhandled rejection TypeError: Cannot read property 'controls' of undefined     at Client.<anonymous> (C:\Users\david\Desktop\interactive-keyboard\index.js:512:32)     at Client.tryCatcher (C:\Users\david\Desktop\interactive-keyboard\node_modules\beam-client-node\node_modules\bluebird\js\main\util.js:26:23)     at Promise._settlePromiseFromHandler (C:\Users\david\Desktop\interactive-keyboard\node_modules\beam-client-node\node_modules\bluebird\js\main\promise.js:510:31)     at Promise._settlePromiseAt (C:\Users\david\Desktop\interactive-keyboard\node_modules\beam-client-node\node_modules\bluebird\js\main\promise.js:584:18)     at Async._drainQueue (C:\Users\david\Desktop\interactive-keyboard\node_modules\beam-client-node\node_modules\bluebird\js\main\async.js:128:12)     at Async._drainQueues (C:\Users\david\Desktop\interactive-keyboard\node_modules\beam-client-node\node_modules\bluebird\js\main\async.js:133:10)     at Immediate.Async.drainQueues [as _onImmediate] (C:\Users\david\Desktop\interactive-keyboard\node_modules\beam-client-node\node_modules\bluebird\js\main\async.js:15:14)     at processImmediate [as _immediateCallback] (timers.js:383:17)
That is the error I am having

Not having this error anymore, had the wrong version.


Update linked-list to remove outdated instructions

This is an addition to pull request #188 which has already been merged. As mentioned by @NobbZ there and in issue #193, the track specific instructions for Elixir and Erlang mentioned an incorrect alternative solution.
I left these instructions in during the rewrite because I wasn't sure how relevant or important they were for those tracks.
This PR removes the outdated/incorrect paragraph.

Thanks!


Sco transactions update

SCO transaction changes:
SCO.14: Change Delegator ID argument to non-optional
add SCO.16

Hey @relatko , I believe this PR is missing implementation of the Staking Collection version of the Update Networking Address transaction located here => https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/update_networking_address.cdc

Hmm, i thought, that SCO.16 is this, as it is a Staking collection transaction a and its name is Update Networking Address. But the scripts are indeed different. If this is the case, i do not have manifest for the correct Update Networking Address. We should discuss it on slack.

I added TH.25 and modified SCO.16 according to the new manifest


Composer nightly build won't start bots

Describe the bug
The latest nightly build hangs on starting a bot

Version
Version:  2.0.0-nightly.240913.4390cd8
Electron: 8.2.4
Chrome: 80.0.3987.165
NodeJS: 12.13.0
V8: 8.0.426.27-electron.0
OS

[ ] Windows

To Reproduce
Steps to reproduce the behavior:

Get the nightly version mentioned above
Create an empty bot
Try to start it, it won't

@gabog We have a rogue nightly in the pipeline. Pushing a stable nightly in a few minutes.


Changing "Default Action Key" freezes Godot after closing Project Settings

The problem
If you change the "Default Action Key" in Dialogic settings, and then open and close Godot's Project Settings, Godot will freeze up with the dark overlay it has while editiing the Project Settings.
To Reproduce
Steps to reproduce the behavior:

Go to Dialogic->Settings
Under Input Settings, Change Default action key (You can even select the same key already set).
On Godot's menu bar, go to Project->Project Settings
Close the Project Settings
See the issue

Expected behavior
Godot doesn't freeze upon closing Project Settings
System (please complete the following information):

OS: Windows 10
Godot Version: 3.4.2
Dialogic Version: 1.4

Solutions
Workaround
Closed Godot via closing the console window (since main window wasn't responding).

Cannot recreate.

I did a little bit more testing, and I think it's tied to having the Left Mouse Button setup as the ui_accept button.  The issue went away when I removed it, and came back when I added it again.

Alright I think the issue is cause by this line

I do not know why it is in there, and I don't think it's supposed to be called in the editor. I will investigate if there was a reason it was added, because so far removing it has not seemed to change anything.

This has turned out to be much more annoying then I thought it would be. Although I will still try to fix it, I would mainly suggest not to use the build in ui_* actions for anything and also not to modify them, because it will mess with the control nodes in your game (and currently also in the editor if you change the action in the dialogic settings).
If possible, I would suggest zo create a new dialog default input action when dialogic is created and use that one.

I do believe I have found a way to get the list differently. I will try it out this evening if I can. I think I will also create an issue though, because this should not be that annoying to do.


Let analyzer detect out of scope references in all comments

I often use [reference] in my comments to refer to fields or variables. Sometimes when I refactor the analyzer helps to remind me that I have to update some comments. Unfortunately this does not work for non-documentation comments (i.e. //).

CC @jcollins-g

CC @jcollins-g

this is something I do too.  It would be nice if all comments were treated as documentation comments for this purpose, as sometimes even if it will not result in documentation, having the links for code navigation in IDEs is nice.

this is something I do too.  It would be nice if all comments were treated as documentation comments for this purpose, as sometimes even if it will not result in documentation, having the links for code navigation in IDEs is nice.


Support docutils 0.18.x

docutils 0.18.x has been with us for quite some time and it has finally started gaining support of major documentation projects, including Sphinx 5.x. Could you also start supporting that version?

In Fedora, I manually relaxed the docutils version requirement and built the package as RPM against the version 0.18.1 & Sphinx 5.0.2.
Please note, we patch our package (especially fonts), so my findings may not be a complete list.
I compared the rendered package documentation to the one build on docutils 0.17 and Sphinx 4.5.0 and found those issues:

Field list is rendered with two colons instead of one:

Footnotes and citations not visually rendered, functionality (references) without changes:

@befeleme :

Field list is rendered with two colons instead of one:

This issue has been fixed in Sphinx and will be released in version 5.0.3

This issue has been https://github.com/sphinx-doc/sphinx/issues/10594 and will be released in version 5.0.3

The change to Sphinx' style sheet has been released in Sphinx 5.1.0 already. However, sphinx-rtd-theme' style sheet also needs a change like this. Two colons are still rendered with sphinx-rtd-theme and Sphinx 5.1.0.

I'm trying to update the dev dependencies for coverage.py, and get a conflict on docutils, partly because of the requirement in sphinx_rtd_theme:
Could not find a version that matches docutils<0.18,<0.20,<0.21,>=0.14,>=0.19,~=0.18.0 (from doc8==1.0.0->-r doc/requirements.in (line 10))
Tried: 0.3, 0.3.5, 0.3.7, 0.3.9, 0.4, 0.5, 0.6, 0.7, 0.8, 0.8.1, 0.9, 0.9.1, 0.10, 0.11, 0.12, 0.12, 0.13.1, 0.13.1, 0.14, 0.14, 0.15, 0.15, 0.15.1.post1, 0.15.2, 0.15.2, 0.16, 0.16, 0.17, 0.17, 0.17.1, 0.17.1, 0.18, 0.18, 0.18.1, 0.18.1, 0.19, 0.19
Skipped pre-versions: 0.14rc1, 0.14rc2, 0.16b0.dev0, 0.16b0.dev0, 0.16rc1, 0.16rc1, 0.17b1, 0.17b1, 0.17.1b1.dev0, 0.17.1b1.dev0, 0.18b1, 0.18b1, 0.18.1b0, 0.18.1b0, 0.19b1, 0.19b1
There are incompatible versions in the resolved dependencies:
  docutils<0.18 (from sphinx_rtd_theme==1.0.0->-r doc/requirements.in (line 14))
  docutils<0.21,>=0.19 (from doc8==1.0.0->-r doc/requirements.in (line 10))
  docutils~=0.18.0 (from sphinx-tabs==3.4.1->-r doc/requirements.in (line 15))
  docutils<0.20,>=0.14 (from sphinx==5.1.1->-r doc/requirements.in (line 12))

Can we loosen this requirement?


Can't query page context fields of pages created in gatsby-node.js

I'm using gatsby-node.js to create a bunch of pages which I would like to search through using your plugin. I'm passing all the needed data into the pagecontext during the creation of the pages.
My query looks like this:
 query: `
      {
        allSitePage {
          edges {
            node {
              path
              context {
                id__normalized
                market_cap_rank
                name
                symbol
              }
            }
          }
        }
      }
        `,

The error says: Cannot query field "context" on type "SitePage".
I'm not really sure if this just isn't supported or whether I am overlooking something here. The only thing that I can see that seems fishy to me is that the "success create pages" message in the console comes after the error, which makes me think that the pages don't exist yet when I'm trying to query them.
Any hints would be much appreciated! :)

This is a known thing: https://www.gatsbyjs.com/docs/reference/release-notes/migrating-from-v3-to-v4/#field-sitepagecontext-is-no-longer-available-in-graphql-queries


Add alertify to the "Gotify" section of the "Alertmanager Webhook …

…Receiver" docs
@brian-brazil
Signed-off-by: Scott Wallace<EMAIL_ADDRESS>

Thanks for your PR. To avoid splitting the community and continuously re-inventing the wheel, we generally will only list one entry for a given integration. If there are features you feel the existing listing is missing, please work with them to improve it.

No problem.


Make the process for adding data clear within the application

Make the process for adding data clear within the application as opposed to requiring the user to read the wiki.

@donnerlt, thanks for contributing, but we've already documented this in #127. If you feel that issue is missing something, please comment there.
In the future, please search existing open issues before creating new ones.


Unattended installation silent mode

What are commands for file batch?
I'm using windows xp, seven and 8.1 for old computer (gaming or old application)

Unfortunately I had forgotten about implementing an unattended mode. But I shall do so in the future.


SAK-50057 Samigo remove unnecessary dropdown initialization

I don't really understand this .... CC: @bgarciaentornos

I don't really understand this .... CC: @bgarciaentornos

Let's ask @JuanDavid102


missing requirements.txt

missing requirements.txt
a requirements.txt would make it much easier to setup this repo

I apologize for the delay in answering this. The project is quite old now, so I don't quite remember all package versions very well, but python 2.7, tensorflow 0.10, and Keras 1.2.2 are the main package versions.


More improvements to dash-example.html

Hey - this looks interesting, i'm a bit out of the loop but curious. I see another user on discord who maybe might actually be asking for something potentially similar to this.
Do you have any example screenshots or some ELI5 type intro into exactly what this gives you? Maybe something super obvious that we could just add after the 1st paragraph in the readme.
I might try and figure this out and play with it myself over the break as am curious.

Sweet! got it working myself - adding image here that i will link to in the README to make it super obvious to anyone interested.

Might add one or two little small notes to the readme to make it as easy as possible for less technical people (like me :) ) to get it working.

Love this, let me know if anything i can do to help. I'm ML guy so don't really know HTML or javascript or anything but happy to help test or anything.
Would be nice if there was an option to hide the gridlines (white ones below sort of make it harder for my eyes) and/or overall dark theme vs light theme (not sure if that's easy in the charts api or not).

being able to flip the layout between horizontal (one row per host) and vertical (one column per host) would be cool too.
ok, apologies for the feature requests :)

First, let me say I'm so happy you are enjoying the dash page! It has been a lot of fun for me to make and I use it every day. Also happy to see you were able to figure out how to set it up, even with the room for improvement in the documentation. Can I ask if you are using the version from this PR or from the main branch?

Would be nice if there was an option to hide the gridlines (white ones below sort of make it harder for my eyes)

I can look into this. Are you wanting to hide the vertical, horizontal, or both?

overall dark theme vs light theme (not sure if that's easy in the charts api or not).

I'll have to check regarding the charts themselves. The rest of the application is pretty easy to theme (in this PR) using the first


why POST request instead of GET

Just curious, why POST request is used instead of GET request?
I'm asking this because currently javascript SSE implementation only support GET request.
Besides, some opinion about SSE is GET request only
I know I can still use a reverse proxy to convert the request, but just wish to know the intention using POST request.

well , great . now i confirm that , i modify the service file del one path , /etc/webhook.env is better .

then I had a new problem , I use github to  post a request , then i got “ Request
We couldn’t deliver this payload: Service Timeout” , I try to set the  WHD_HOOK_TIMEOUT ，then it don't work , i still got the msg ... is the shell script execution time too long ? how can i fix it .....


Missing cors header on preflight request

Do you want to request a feature or report a bug?

Bug

What did you do?

I'm trying to move my cors logic into traaefik, to avoid to maintain it in my codebase. But i'm facing an unwanted issue with preflight.
What did you expect to see?
I expect traefik to return preflight request with defined cors headers.
HTTP/2 200
access-control-allow-headers: AUTHORIZATION
access-control-allow-methods: GET
access-control-allow-origin: <url>
cache-control: max-age=0
content-type: text/html; charset=UTF-8
date: Sun, 12 Apr 2020 10:00:37 GMT
expires: Sun, 12 Apr 2020 10:00:37 GMT
referrer-policy: same-origin
server: nginx
strict-transport-security: max-age=63072000; includeSubDomains; preload
vary: Accept-Encoding
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 1; mode=block

What did you see instead?
HTTP/2 200
content-length: 0
date: Sun, 12 Apr 2020 09:54:50 GMT

Also note the request is not forwarded to nginx backend, it's what i expect to see.
Output of traefik version: (What version of Traefik are you using?)
Version:      2.2.0
Codename:     chevrotin
Go version:   go1.14.1
Built:        2020-03-25T17:32:57Z
OS/Arch:      linux/amd64

What is your environment & configuration (arguments, toml, provider, platform, ...)?
version: '3.7'
services:

  nginx:
    image: <placeholder>:${CI_COMMIT_SHORT_SHA:-latest}
    build:
      context: .
      dockerfile: Dockerfile
      target: nginx
    restart: unless-stopped
    expose:
      - 80
    networks:
      - nginx-proxy
      - backend
    environment:
      NGINX_HOST: ${APP_URI}
      ERROR_LOG_LEVEL: ${ERROR_LOG_LEVEL}
    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=nginx-proxy"
      - "traefik.http.routers.${COMPOSE_PROJECT_NAME}-insecure.rule=Host(`${APP_URI}`) || Host(`www.${APP_URI}`)"
      - "traefik.http.routers.${COMPOSE_PROJECT_NAME}-insecure.entrypoints=web"
      - "traefik.http.routers.${COMPOSE_PROJECT_NAME}-insecure.middlewares=${COMPOSE_PROJECT_NAME}-https-only,${COMPOSE_PROJECT_NAME}-ratelimit,${COMPOSE_PROJECT_NAME}-headers,${COMPOSE_PROJECT_NAME}-compress"
      - "traefik.http.routers.${COMPOSE_PROJECT_NAME}.rule=Host(`${APP_URI}`) || Host(`www.${APP_URI}`)"
      - "traefik.http.routers.${COMPOSE_PROJECT_NAME}.entrypoints=websecure"
      - "traefik.http.routers.${COMPOSE_PROJECT_NAME}.tls.certresolver=myhttpchallenge"
      - "traefik.http.routers.${COMPOSE_PROJECT_NAME}.middlewares=${COMPOSE_PROJECT_NAME}-https-only,${COMPOSE_PROJECT_NAME}-ratelimit,${COMPOSE_PROJECT_NAME}-retry,${COMPOSE_PROJECT_NAME}-error-check,${COMPOSE_PROJECT_NAME}-headers,${COMPOSE_PROJECT_NAME}-compress"
      - "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-headers.headers.stsSeconds=63072000"
      - "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-headers.headers.stsIncludeSubdomains=true"
      - "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-headers.headers.stsPreload=true"
      - "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-headers.headers.forceSTSHeader=true"
      - "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-headers.headers.contentTypeNosniff=true"
      - "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-headers.headers.sslRedirect=true"
      - "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-headers.headers.referrerPolicy=same-origin"
      - "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-headers.headers.frameDeny=true"
      - "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-headers.headers.browserXssFilter=true"
      - "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-headers.headers.accessControlAllowMethods=GET,OPTIONS,POST,PUT,PATCH,DELETE"
      - "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-headers.headers.accessControlAllowOriginList=*"
      - "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-headers.headers.accessControlMaxAge=63072000"
      - "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-headers.headers.accessControlAllowCredentials=true"
      - "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-headers.headers.accessControlAllowHeaders=Authorization,Origin,Content-Type,Accept"
      - "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-headers.headers.addVaryHeader=true"
      #- "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-headers.headers.sslProxyHeaders=https"
      - "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-compress.compress=true"
      - "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-https-only.redirectscheme.scheme=https"
      - "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-https-only.redirectscheme.permanent=true"
      - "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-retry.retry.attempts=4"
      - "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-error-check.circuitbreaker.expression=ResponseCodeRatio(500, 600, 0, 600) > 0.30 || NetworkErrorRatio() > 0.10"
      #- "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-limit.buffering.maxRequestBodyBytes=20000000" # 20 Mb
      #- "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-limit.buffering.memResponseBodyBytes=20000000" # 20 Mb
      - "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-ratelimit.ratelimit.average=1000"
      - "traefik.http.middlewares.${COMPOSE_PROJECT_NAME}-ratelimit.ratelimit.burst=500"

networks:
  backend:
  nginx-proxy:
    external: true
  database-network:
    external: true

global:
  checkNewVersion: false

entryPoints:
  web:
    address: ":80"
  websecure:
    address: ":443"

providers:
  docker:
    endpoint: "unix:///var/run/docker.sock"

providers:
  docker:
    exposedByDefault: false
    network: nginx-proxy

log:
  level: DEBUG

api:
  dashboard: true
  insecure: true

certificatesResolvers:
  myhttpchallenge:
    acme:
      email: <email>
      storage: /letsencrypt/acme.json
      httpChallenge:
        # used during the challenge
        entryPoint: web

tls:
  options:
    default:
      sniStrict: true
      minVersion: VersionTLS12
      cipherSuites:
        # https://ssl-config.mozilla.org/#server=traefik&version=2.1.2&config=intermediate&guideline=5.4
        - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
        - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
        - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
        - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
        - TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
        - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
    mintls13:
      minVersion: VersionTLS13

My issue looks like this one : https://community.containo.us/t/problem-with-headers-probably-forwarding/1804/13

Hi! I'm Træfiker :robot: the bot in charge of communication regulation.
Thanks for your interest in Traefik!
We dedicate the issue tracker to bug reports and feature requests only. My advanced AI has spotted that your issue might be a configuration problem or relates to something that doesn't look like a bug.
To confirm this, please join our Community Forum and reach out to us on the Traefik section.
In case I'm wrong (well, that would be embarrassing :sweat_smile:), my developers will re-open the issue and fix me!
In the meantime, you can double check Traefik's documentation.


Get individual params value with respect to name

Hi, How to get values of params name ie. method.Params._addr returns the value 0x839C6f5a014cbfA319e8fDFA01AaC186638945A8
right now it outputs,
{_name 小明 string}
{_age<PHONE_NUMBER>00000000000000000000000000000 uint256}
{_addr 0x839C6f5a014cbfA319e8fDFA01AaC186638945A8 address}

Can we get the individual values out of it?

param name maybe empty, so we cannot get param value by param name.

Hi, How to get values of params name ie. method.Params._addr returns the value 0x839C6f5a014cbfA319e8fDFA01AaC186638945A8
right now it outputs,
{_name 小明 string}
{_age<PHONE_NUMBER>00000000000000000000000000000 uint256}
{_addr 0x839C6f5a014cbfA319e8fDFA01AaC186638945A8 address}

Can we get the individual values out of it?

param name maybe empty, so we cannot get param value by param name.

Hi, How to get values of params name ie. method.Params._addr returns the value 0x839C6f5a014cbfA319e8fDFA01AaC186638945A8
right now it outputs,
{_name 小明 string}
{_age<PHONE_NUMBER>00000000000000000000000000000 uint256}
{_addr 0x839C6f5a014cbfA319e8fDFA01AaC186638945A8 address}

Can we get the individual values out of it?


inputAccessoryView breaks this implementation.

Here is an image of an inputaccessoryview visible from one of the tabs. It is a disaster.
Additionally, I'm not selecting that tab. The recent change that made it so views are just 'hidden' so they don't rebuild when you switch away means that the view loads its inputAccessoryView even when the tab is not selected

Could you please provide more detailed information? How did you obtain this view?


b1-rosecurrency

Node ID is at 548dbf7
Log summaries of the run and system report are at 2914453

confirmed:B1
node:e12390602a3738e0


Update WebView2 .NET Framework support to 4.5

We support .NET Framework back to 4.5 and mentioned this in our release notes, but forgot to update the info on the Supported page.

Docs Build status updates of commit b67c096:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

microsoft-edge/webview2/index.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 8b1e71d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

README.md
:white_check_mark:Succeeded

microsoft-edge/accessibility/build/index.md
:white_check_mark:Succeeded
View

microsoft-edge/accessibility/test.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/accessibility/emulate-vision-deficiencies.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/accessibility/focus.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/accessibility/navigation.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/accessibility/preferred-color-scheme-simulation.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/accessibility/reduced-motion-simulation.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/accessibility/reference.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/beginners/css.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/beginners/html.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/command-menu/index.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/console/api.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/console/index.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/console/javascript.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/console/live-expressions.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/console/log.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/console/reference.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/console/utilities.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/coverage/index.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/css/grid.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/css/index.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/css/print-preview.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/css/reference.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/customize/dark-theme.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/customize/index.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/customize/localization.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/customize/placement.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/customize/shortcuts.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/device-mode/geolocation.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/device-mode/index.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/device-mode/orientation.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/device-mode/override-user-agent.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/device-mode/testing-other-browsers.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/dom/index.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/evaluate-performance/index.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/evaluate-performance/performance-reference.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/evaluate-performance/reference.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/experimental-features/index.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/ie-mode/index.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/includes/audits-panel-note.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/index.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/inspect-styles/animations.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/inspect-styles/edit-fonts.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/issues/index.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/javascript/background-services.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/javascript/breakpoints.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/javascript/disable.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/javascript/guides/mark-content-scripts-library-code.md
:white_check_mark:Succeeded
View

microsoft-edge/devtools-guide-chromium/javascript/index.md
:white_check_mark:Succeeded
View

This comment lists only the first 50 files in the pull request.
For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Getting error while downloading genefamilyabundance data of "AsnicarF2021"

I was trying to download "AsnicarF_2021"  data from the command line with CuratedMetagenomicData. I successfully downloaded the pathway abundance and species abundance data, but I am unable to download the genefamilyabundance data. I am using the following command:
deep@deep:~/Desktop/Asnicar_2021$ curatedMetagenomicData -m "2021-03-31.AsnicarF_2017.gene_families"

I am getting the following error:
Datasets to be downloaded:
2021-03-31.AsnicarF_2017.gene_families.tsv
Working on 2021-03-31.AsnicarF_2017.gene_families
snapshotDate(): 2021-05-18
Error in h(simpleError(msg, call)) :
  error in evaluating the argument 'x' in selecting a method for function 'rbind2': invalid class 'NA' to dup_mMatrix_as_geMatrix
Calls: rbind ... rbind2 -> rbind2 -> rbind2 -> .handleSimpleError -> h
Execution halted

Can you please tell me how can I download the data?
Many Thanks,
Deep Chanda

Hi @DPC7, I am going to transfer this issue to the curatedMetagenomicDataCLI repo and we will help you solve it there.


feat: system os light/dark mode option 🔦

Pull Request Checklist

[x] Description: Briefly describe the changes in this pull request.
[x] Changelog: Ensure a changelog entry following the format of Keep a Changelog is added at the bottom of the PR description.

[x] Dependencies: Are there any new dependencies? Have you updated the dependency versions in the documentation?

Description
Add support for system OS light and dark themes to the web application, improving the user experience and providing a more seamless integration with the user's preferences. Closes https://github.com/open-webui/open-webui/issues/1065

Changelog Entry
Added

Added System option to the theme menu which automatically detects the system's color scheme (light or dark) and applies it as the default theme. This ensures a consistent user experience that aligns with the user's system settings
Dynamic Theme Switching: The application dynamically updates its theme when the system's color scheme changes. This ensures that the application's appearance remains consistent with the system's settings even when they are altered while the application is running.

Changed

Refactor - moved the theme logic to its own applyTheme function

https://github.com/open-webui/open-webui/assets/45186464/ddc57fc7-f6b1-4ce0-8180-1f4757de014b

This one any closer to merging @dannyl1u?
found bugs during testing, WIP @justinh-rahb

@dannyl1u what are the bugs? Works for me in Win 11.

@jannikstdl after setting to theme to system in settings, and clicking save, once user returns to settings it will show the theme as either light or dark when it should be showing system

Updated to work with the latest UI updates, ready for review
@jannikstdl @justinh-rahb @tjbck
https://github.com/open-webui/open-webui/assets/45186464/6021549a-e125-447e-a186-399bd1c38431

LGTM!

Very nice!

Great job! Thank you very much for implementing this as a feature for all to enjoy! 😀

I'm not sure how many Dark Mode enthusiasts will be suddenly surprised by the darkening of their UI, since I've rarely met one that doesn't immediately go looking for the toggle in any app they use 😆 However this will be one less step for them going forward 🙌

Thanks for the PR! Just did some refac and removed a good majority of unnecessary parts, please test it and let me know if I broke anything.
@dannyl1u Also, I just wanted to mention that it would be great if we could stick to the conventions already used in our repo. I realise I should have provided more information about these conventions earlier, but couldn't find the time 😅. You can use the refactored code as a reference for future work. Please feel free to review the changes I've made, and if you have any questions, don't hesitate to reach out!

LGTM!


Upgrade rustfmt and clean rustfmt.toml

Because of inactivity in this repo the rustfmt-nightly versions have been lagging behind. Here I upgrade it to the latest.
I also remove two directives from the format config:

reorder_imported_names - It is now true by default, so no need to specify it.
take_source_hints - Removing this makes no difference. So I don't see the reason to keep it. I tried removing it from talpid_core locally as well and it does no difference. So we can probably survive without it.

This change is

The slight reformat that did happen was just from the version upgrade, not from the change in formatter settings.

I added the chmod stuff in hopes it would solve the file permission issue. This was the same build error we had on talpid_core. Here they might occur because we run the tests as sudo though.

Reviewed 3 of 3 files at r1, 1 of 1 files at r2.
Review status: all files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

rustfmt.toml, line 3 at r2 (raw file):

# Activation of features, almost objectively better ;)
reorder_imports = true
reorder_imported_names = true

Wasn't this nice?

Comments from Reviewable

Review status: all files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

Comments from Reviewable

Review status: all files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

rustfmt.toml, line 3 at r2 (raw file):
Previously, pronebird (Andrei Mihailov) wrote…
Wasn't this nice?

As I said in the description of the PR: This is already true by default now, no no need to specify it manually.

Comments from Reviewable


DOM collection

I suggest that .at (or whatever name is used) also be supported on DOM collection objects so that the same name can be used consistently.

At least that will be easy to polyfill: NodeList.prototype.at = Array.prototype.at


Update parsing of API result into frontend Result class

What is the expected enhancement?
The format of the results is going to need some changes due to the introduction of Qobj in 0.6. The Result class needs to be updated to be able to cope with the changes - actually, it will need to understand both the new format and the old format during the transition.

Self-assigned and expanded a bit the description. The slightly trick part is going to be being able for both formats to coexist during this phase, as the Result class is too tightly coupled with the old format - I'll take the chance to decouple it a bit, while keeping the public API of that class intact (hopefully :crossed_fingers: ).


Cannot open shared object file libjsoncpp.so

I'm getting this error code while trying to start polybar
[daniel@laptop ~]$ polybar main
polybar: error while loading shared libraries: libjsoncpp.so.11: cannot open shared object file: No such file or directory

However jsoncpp should be installed.
[daniel@laptop ~]$ yaourt jsoncpp
1 extra/jsoncpp 1.8.3-1 [installed]
    C++ library for interacting with JSO

You have to recompile polybar, see #871

Thanks! It seems like the AUR package has been fixed too.

This problem just popped up again.

The fix for it didn't change. You have to recompile polybar.
On Fri, Feb 2, 2018, 03:36 Dessalines<EMAIL_ADDRESS>wrote:

This problem just popped up again.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/jaagr/polybar/issues/885#issuecomment-362468146, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACVqRgjUTeHpzWTf5I1NJ-4Yt5DnFbqWks5tQnS2gaJpZM4Q0Q3c
.

Uninstalling and reinstalling works as well.

@yn5 reinstalling the AUR package? I tried that:
$ sudo pacman -R polybar
$ cd ~/aur/polybar
$ makepkg -si

Still getting the same error. Unsure how that was suppose to update the linking to the library though. Please elaborate.

Reinstalling only works, if it actually recompiles polybar. You'll have to pass the -f flag to makepkg or remove the already built binaries from your ~/aur/polybar/ folder

@yn5 note that reinstalling using AUR is exactly that: the whole app is recompiled

@Jezorko, I don't believe I ever said it isn't, but thanks for the note :blush:

Rebuilding doesn't work in my case on Arch. I did three times pikaur -S --rebuild polybar.
Resulting Error when starting polybar is every time the missing libjsoncpp shared object.
Not sure if this build informations are relevant (if not, say so, I'll edit and delete)
Targets:
[X]   polybar-msg
[ ]   testsuite
 Module support:
[X]   alsa (1.1.7)
[X]   curl (7.62.0)
[X]   i3
[ ]   mpd
[X]   network (3.4.0)
[X]   pulseaudio (12.2)
[X]   xkeyboard (1.13.1)
 X extensions:
[X]   xcb-randr (1.13.1)
[X]   xcb-randr (monitor support) (1.13.1)
[ ]   xcb-render
[ ]   xcb-damage
[ ]   xcb-sync
[ ]   xcb-composite
[X]   xcb-xkb (1.13.1)
[X]   xcb-xrm (1.3)
[X]   xcb-cursor (0.1.3)

Build process also puts missing fonts in output. But seems like an info rather than an error.

Same thing again - libjsoncpp was updated. Recompiling fixes the issue.

I'm sorry, this is probably not the best place to ask this, but how exactly updating a library can break a package, and why recompiling fixes it?

@PonasKovas I think this is why:
https://github.com/polybar/polybar/wiki/Known-Issues#error-while-loading-shared-libraries-libjsoncpp

Isn't this a bug in libjsoncpp that the install / update script doesn't create a link to the newest version of the library?

I checked the symlink after updating and seeing this error. There was already a link to the new library version, exactly as recommended in that "known issues" section. I don't know why it didn't work. But re-compiling fixed it.

When jsoncpp introduces possibly breaking changes to its library, it will bump the so called SONAME field in the library. If you compiled polybar with jsoncpp 1.8.4, polybar was linked against libjsoncpp.so.20. So everytime the polybar exectuable is run, the operating system will search for the libjsoncpp.so.20 file for dynamic linking. Now if you update jsoncpp to version 1.9.1, which comes with libjsoncpp.so.21, the OS can no longer find libjsoncpp.so.20 when running polybar and will crash with the mentioned error message.
This is neither a bug in polybar nor in jsoncpp @Jezorko. This is one of the downsides of polybar not being pre-packaged on many platforms because you can update jsoncpp without needing to re-link polybar.

I was able to solve this on Arch 5.2.14-arch2-1-ARCH using yay. I simply ran yay -S polybar, waiting for the reinstallation/compilation to finish, and polybar was back to working as expected (for me at least).

I was able to solve this on Arch 5.2.14-arch2-1-ARCH using yay. I simply ran yay -S polybar, waiting for the reinstallation/compilation to finish, and polybar was back to working as expected (for me at least).

@ginglis13 Yeah, because, just as it was mentioned multiple times before, recompiling fixes the issue.

Just ran into this myself..
Why is it that polybar links to libjsoncpp.so.XX instead of libjsoncpp.so?

@Cory-Watson

Why is it that polybar links to libjsoncpp.so.XX instead of libjsoncpp.so?

This is guided by linker internals. If you link to a shared library, the linker will actually link to the SONAME which is libjsoncpp.so.XX, nothing we can do about that I think.
Also linking directly to libjsoncpp.so isn't a good idea because the whole point of SONAME is to prevent running an executable with a library that is incompatible (has a different SONAME). For that reason creating the symlink is also not a good idea. In the case of jsoncpp it's probably fine, but imagine libjsoncpp.so.21 is completely different from libjsoncpp.so.20, now you run polybar which is linked to libjsoncpp.so.20 with the symlink that points to libjsoncpp.so.21. In the best case, polybar won't even start because of a linker error, in the worst case the calls that polybar makes to jsoncpp have malformed inputs and produce unexpected outputs or undefined behavior.

I just had the same problem. Reinstalling polybar worked for me. Thanks.

Already got the same problem few months ago and completely reinstalling from the AUR worked well but this time it doesn't fix the problem, I've tried with polybar and polybar-git
polybar: error while loading shared libraries: libjsoncpp.so.22: cannot open shared object file: No such file or directory

Same problem here, recompiled and installed the jsoncpp package (on Arch) and still not working.

Installing jsoncpp and then reinstalling polybar-git worked for me (on Arch)

Same, reinstalling jsoncpp and switching to polybar-git worked for me as well

Same, reinstalling jsoncpp and switching to polybar-git worked for me as well

Still doesn't solve the issue for me

Had this issue again today but now reinstalling polybar from AUR didn't work, neither switching to polybar-git nor reinstalling jsoncpp

I have locked this issue because it was generating too much noise.
The fix is (and has been the same for years) to recompile polybar. Just reinstalling is often not enough because it generally doesn't recompile polybar.
This is also described on the Known Issues page.


Module not found: Can't resolve 'swr'

Describe the bug
Error when no 'swr' package is installed.
Error message: Module not found: Can't resolve 'swr'
To Reproduce
If possible, open a PR with a failing test. Otherwise, describe how to reproduce the behavior:

Follow installaction instruction
Run 'yarn dev'
Error occurs when using one of the features (useQuery, ...)

Expected behavior
SWR will be installed as dependency. Or installation description metiones that swr package needs to install manually.

Hey! Thanks for opening the report. SWR (as well as postgrest-js) is jut a peer dependency. If your package manager does not install those automatically, you have to add them manually to your package.json. I will add a hint to the installation instructions.


Handle ValueErrors in when comparing org trees

https://www.pivotaltracker.com/story/show/148436359

when comparing org levels (e.g. comparing staff and patient orgs during check_role()), properly handle ValueErrors, so that, among other things, we properly handle patients who just belong to org id=0 ('None of the above').

Clean fix.  thanks.


[bug] Dapp browser error in TokenPoket on iPhone XR, iPhone 11 Pro.

Is there an existing issue for this?

[X] I have searched the existing issues

Package Version
0.2.24
Current Behavior
https://github.com/tmm/wagmi/tree/main/examples/next
I am using the above example project to display the page properly in the TokenPoket Dapp browser for iPhone XR, iPhone 11Pro, and iPhone 11. Using JSConsole debugging, I can't see any obvious error messages.
Detailed steps:

I pulled down this example project. https://github.com/tmm/wagmi/tree/main/examples/next
run npm install Node.js: v14.17.5 npm：6.14.14
run npm run dev
When accessing TokenPoket's Dapp browser on iPhone XR and iPhone 11 Pro, the page is blank, and the following error is reported using JSConsole debugging.

Expected Behavior
No response
Steps To Reproduce
No response
Link to Minimal Reproducible Example (CodeSandbox, StackBlitz, etc.)
https://github.com/tmm/wagmi/tree/main/examples/next
Anything else?
No response

Just loaded up the next example (using<EMAIL_ADDRESS>in TokenPocket (version 1.7.9) on iOS 15.4 and no issues.

I'm sorry, but unless there is an easy, repeatable way to reproduce, I cannot spend any more time on this issue. This looks like a Next.js SSR error more than an issue with wagmi.