Allow an optional vert at the beginning of a match branch

This was written to provide a formal proposal to allow a leading | at the beginning of a match as was discussed in https://github.com/rust-lang/rfcs/issues/1745. In that thread, it was previously stated the language team is in favor of this change.
Some of the sections I don't know anything about but I tried to fill in what I knew. For such a small topic, this form seems excessive and so a lot of the text seems fairly brief to me. Also, I'm not actually sure all the examples are needed but I thought it wouldn't hurt to add them.
In brief, this is a proposal that the following match syntax be legal:
enum E { A, B, C, D}
use E::*;

match foo {
| A
| B => (),
| C
| D => (),
}

Rendered

@mdinger One nit: in example B, why not include the vert to make all the branches match, rather than calling attention to the lack of one with a comment?
More significantly, the "detailed design" section needs some details.  In that section, you should discuss modifying the grammar for match arms to allow an optional single vertical bar | before the pattern.

Example B was to show it is still legal to be inconsistent in that way but
even in that case, it doesn't make the logic unclear.
I'll looked for the grammar but didn't see it. I'll have to look again
another day.
On Feb 23, 2017 9:33 PM, "Josh Triplett"<EMAIL_ADDRESS>wrote:

@mdinger https://github.com/mdinger One nit: in example B, why not
include the vert to make all the branches match, rather than calling
attention to the lack of one with a comment?
More significantly, the "detailed design" section needs some details. In
that section, you should discuss modifying the grammar for match arms to
allow an optional single vertical bar | before the pattern.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rfcs/pull/1925#issuecomment-282186682, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AD9uOyfW3LuERRep_fXNmEYEqn5y6TjRks5rfkFggaJpZM4MKvkp
.

Actually, example B stemmed from a question on the original thread which I
think highlighted the possible confusion over something like that. So I
didn't think I should disregard it. Maybe it needs more comments
On Feb 23, 2017 9:43 PM, "Matthew Dinger"<EMAIL_ADDRESS>wrote:

Example B was to show it is still legal to be inconsistent in that way but
even in that case, it doesn't make the logic unclear.
I'll looked for the grammar but didn't see it. I'll have to look again
another day.
On Feb 23, 2017 9:33 PM, "Josh Triplett"<EMAIL_ADDRESS>wrote:

@mdinger https://github.com/mdinger One nit: in example B, why not
include the vert to make all the branches match, rather than calling
attention to the lack of one with a comment?
More significantly, the "detailed design" section needs some details. In
that section, you should discuss modifying the grammar for match arms to
allow an optional single vertical bar | before the pattern.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rfcs/pull/1925#issuecomment-282186682, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AD9uOyfW3LuERRep_fXNmEYEqn5y6TjRks5rfkFggaJpZM4MKvkp
.

@mdinger In that case, you may want to show a "before" and "after" for example B: the inconsistent version, and the consistent version.

I think for consistency it should also allow leading ,, like it was suggested in the issue. Still, I think neither of the two notations should become official rust style.

I'm finding it a bit hard to read the examples when I glance over them. The indenting makes it see where each pattern starts or ends, and to spot where each match occurs.
So personally I don't think it would fit with the language unless it used a style like this:
match A {
    | A
    | B => println!("Give me A | B!"),

    | C
    | D => println!("Give me C | D!"),
}

I very much appreciated the ability to have leading | in Ocaml (I've never used F#, though I've often wanted to) and I've also wondered why we don't support them in Rust from time to time, but never bothered to propose it. So I'm basically 👍 on this proposal.
That said, if we're going to accept leading | but not recommend you use them, it seems less exciting. I'd still be in favor, because macros and so on, but less so. Therefore, I'm also interested in the feedback of the "format" team -- I don't know best to cc them, though, so I'll just cc a few members that I can think of off the top of my head: @nrc, @solson, @joshtriplett. I'm not really following a lot of the discussions there, but last time I checked in, it seemed like we were aiming for a "less visual" more "block-oriented" formatting strategy. In that case, I feel like leading | might fit in there. (Also, I remember that rustfmt has some "issues" around match arms, maybe this helps to resolve them.)

@keeperofdakeys Allowing leading vert doesn't specify whether match arms should have a leading indent in addition to the | or not.
@nikomatsakis @rust-lang-nursery/style, because for some reason we put fmt-rfcs under rust-lang-nursery.
Given the availability of leading |, personally, I'd be inclined to recommend using it for any match pattern that contains an alternation.  For consistency, I'd personally suggest using it on the rest of the match patterns if any pattern in the match has an alternation in it.  (If every match arm consists of a single pattern, I don't think using it makes sense to prefix them all with |.)

To clarify, I never intended for this to be a proposal to change the recommended way matches are formatted. Stylistic topics are enormously difficult to push through to communities because everyone has their own preferences, which is okay and not problematic.
My intent was to showcase that allowing the leading vert could be a very valuable addition to some people without hindering understanding for others. If you don't like it, fine, don't use it but that is no reason to hinder others if they like it. The best I probably hoped for was for the vert to be allowed and an example in the docs somewhere include the style so that people could decide if it is good. That is, I don't always wait for rust-lang.org to tell me if I like a coding style. Sometimes, I decide for myself (it's nice to have a menu to show me what my options are though - I'd never have discovered this style if I hadn't seen it in F#).
@keeperofdakeys Styles are mutable. Your entire history in Rust and every other language colors your perception of what looks good. My history works the same way. I don't think I can categorically say that any simple style change of this sort could never look like Rust.

Taking an example from regex: can you identify which lines are match arms in less than a second in the following example?
            match c {
                '\\' => return match self.c() {
                            Some('#') => {self.advance(); Some('#')}
                            _ => Some('\\')
                        },
                '#'  => loop {
                            match self.c() {
                                Some(c) => {
                                    self.advance();
                                    if c == '\n' {
                                        break;
                                    }
                                },
                                None => return None
                            }
                        },
                _    => if !c.is_whitespace() {return Some(c);}
            }

Repeating the example, if I told you every arm started with a vert, could you do it faster? I can. I think they highlight them:
            match c {
                | '\\' => return match self.c() {
                            | Some('#') => {self.advance(); Some('#')}
                            | _ => Some('\\')
                        },
                | '#'  => loop {
                            match self.c() {
                                | Some(c) => {
                                    self.advance();
                                    if c == '\n' {
                                        break;
                                    }
                                },
                                | None => return None
                            }
                        },
                _    => if !c.is_whitespace() {return Some(c);}
            }

I actually think this would be a good addition to the language, I just wanted to point out that I found the RFC examples a bit hard to read. People are free to use a feature how they want, but I think that RFC examples are a good indication of how a feature could/should be used. Ultimately a style rfc is the way to decide how it should be styled though.
@mdinger I agree, it's easier to identify match arms in the second.

When I have more variants than can fit on a line I write my matches like this:
match foo {
    Foo::Bar
    | Foo::Baz
    | Foo::Quux,
    => Whatever::One,
    Foo::Spam
    | Foo::Eggs,
    => Whatever::Two,
}

I would probably write this after this RFC:
match foo {
    | Foo::Bar
    | Foo::Baz
    | Foo::Quux,
    => Whatever::One,
    | Foo::Spam
    | Foo::Eggs,
    => Whatever::Two,
}

When I don't have a situation like this (which is most of the time), I make sure my matchrockets all align.
Most people write their matches differently from me, but I would still like to have the grammar be more flexible.
However, supporting | within patterns is more important, and so I want to make sure this is square with that proposal.

Unfortunately the closing braces in the same column kills it for me right away, along with the more minor issue @keeperofdakeys pointed out where it becomes less clear which lines are the beginnings of patterns and which are not.

@joshtriplett I added some updates to try to address your comments.
@keeperofdakeys I don't know how I can make the examples more clear. Branches always occur where the => points. They always have and they always will. This appears to be finding the syntax unfamiliar and thus feels hard (here's something which technically should be really easy but probably will be really hard). The only example I think is somewhat difficult to parse is the first part of Example C. I find it tricky because the indentation is always changing somewhat how the line below keeps moving. I find the second part more consistent by far and much more straightforward.

To others regarding braces, considering how syntax heavy rust is, I actually find the extra braces just a slight nitpick and isn't even that bad. Compare with the fairly common ))))) which pops up at the completion of function calls.  If Example C was translated to F#, most of the symbols (,{}():: just vaporize). Consider how clean this looks (not valid F#):
    match name
    | Name Franks name =>
        match name
        | Franks Alice
        | Franks Brenda
        | Franks Dave => FavoriteBook
            author: "alice berkley"
            title: "Name of a popular book"
            date: 1982
        | Franks Charles
        | Franks Steve => FavoriteBook
            author: "fred marko"
            title: "We'll use a different name here"
            date: 1960
    | Name Sawyer name  =>
        match name
        | Sawyer Tom => FavoriteBook
            author: "another name"
            title: "Again we change it"
            date: 1999
        | Sawyer Sid
        | Sawyer May => FavoriteBook
            author: "again another name"
            title: "here is a different title"
            date: 1972

I'm not saying all the extra symbols need to go away but when you compare it to something like this which, for the most part, should be somewhat clear (and less heavy-handed), the debate about whether 1 or 2 different braces should be aligned isn't that important. The language is syntax heavy and we do the best we can.

Um... I don't really like the argument "rust is already uglier than F#, so
it shouldn't matter if we make it a tiny bit more ugly here". I see the
advantages of this proposal, but I wonder if we can't find an indentation
style that doesn't make it harder to associate a given closing brace with
its opening.
On Sat, Feb 25, 2017 at 11:18 PM, mdinger<EMAIL_ADDRESS>wrote:

@joshtriplett https://github.com/joshtriplett I added some updates to
try to address your comments.
@keeperofdakeys https://github.com/keeperofdakeys I don't know how I
can make the examples more clear. Branches always occur where the =>
points. They always have and they always will. This appears to be finding
the syntax unfamiliar and thus feels hard (here's
https://upload.wikimedia.org/wikipedia/en/b/b1/Backwards_text_refdesk.png
something which technically should be really easy but probably will be
really hard). The only example I think is somewhat difficult to parse is
the first part of Example C. I find it tricky because the indentation is
always changing somewhat how the line below keeps moving. I find the second
part more consistent by far and much more straightforward.
[image: wavy]
https://cloud.githubusercontent.com/assets/4156987/23336870/c0785aa6-fbaa-11e6-97d7-f17a3f75912c.png
To others regarding braces, considering how syntax heavy rust is, I
actually find the extra braces just a slight nitpick and isn't even that
bad. Compare with the fairly common ))))) which pops up at the completion
of function calls.  If
Example C was translated to F#, most of the symbols (,{}():: just
vaporize). Consider how clean this looks (not valid F#):
match name
| Name Franks name =>
    match name
    | Franks Alice
    | Franks Brenda
    | Franks Dave => FavoriteBook
        author: "alice berkley"
        title: "Name of a popular book"
        date: 1982
    | Franks Charles
    | Franks Steve => FavoriteBook
        author: "fred marko"
        title: "We'll use a different name here"
        date: 1960
| Name Sawyer name  =>
    match name
    | Sawyer Tom => FavoriteBook
        author: "another name"
        title: "Again we change it"
        date: 1999
    | Sawyer Sid
    | Sawyer May => FavoriteBook
        author: "again another name"
        title: "here is a different title"
        date: 1972

I'm not saying all the extra symbols need to go away but when you compare
it to something like this which, for the most part, should be somewhat
clear (and less heavy-handed), the debate about whether 1 or 2 different
braces should be aligned isn't that important. The language is syntax heavy
and we do the best we can.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rfcs/pull/1925#issuecomment-282531877, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAC3n6LhrOgW9LRSgllKDq2B9j6t1RHVks5rgP0fgaJpZM4MKvkp
.

Okay. I think I've done my part trying to defend the stylistic part of the proposal and people who don't like it still won't like it. Having said that, I don't know where the consensus stands as far as the technical part of this being supported by the compiler. I haven't seen any comment which states making this legal is problematic in any fashion aside from something stylistic.
Let me know if I need to update the RFC in any other ways.

If this gets approved, I hope there will be an associated rustfmt RFC to helps folks that may either approve or disapprove this style: https://github.com/rust-lang-nursery/fmt-rfcs

I don't think we would recommend them - we don't recommend a leading comma style, for example. I know @joshtriplett favours leading newlines with punctuation, e.g.,
a + b
+ c + d

// c.f.

a + b +
c + d

But that is not what is being proposed here. I can't think of anywhere we are proposing actually leading with punctuation.
In general, I would be in favour of this RFC - I usually prefer more flexibility in our syntax rather than less, but I don't think we would make this the default style. In particular, the needing a | in the single pattern case seems very weird to me.
(Do we allow trailing |? That seems useful for macros, but I don't think we'd recommend a trailing | either).

@mdinger For the sake of demonstrating the smallest incremental change, I'd suggest changing the examples so they still indent match arms as normal (four spaces in front), rather than outdenting them and treating the vert-and-space as their indent.  We could evaluate the latter as a potential style change, but that leads to the issue with trailing braces.  Let's not conflate that style change and associated brace indentation issue with the minimal grammar proposal.
You could add a section towards the end mentioning that potential style change, move the discussion of the brace problem from the drawbacks to that new section, and punt the actual style, arguing that the grammar change is useful independently.

I don't mind doing that. I might get around to it a day or so but if not then, it might be a few weeks. Might be pretty busy and don't know what my free time will be like.

I think the reason to make this a recommended style would be to avoid the double indentation and so forth. But I agree it's a separate thing-- still it seems like it'd be good to take this idea into account when settling on the best indentation style for matches

In elm you would do something like
match Z
    { A
    | B =>...
    , C
    | D
   ...
}

Which would be legal rust syntax and make everything align.

In the interests of moving this forward:
I'm not seeing any objections to the idea of supporting this in the grammar. I do see some comments about what our recommended style should look like, and in particular whether or not this should replace indentation of match arms.  The thing that's causing those two to be conflated is that the RFC's samples all assume a particular style when writing, and not everyone is a fan of that style.  As far as I can tell, the objections to this all boil down to "the style as shown in the RFC doesn't look appealing", which I wouldn't argue with.
Does anyone object to allowing the optional vert at all?  If not, I would propose that we move to accept this, and then separately determine how it might affect the default style.
(And with my style team hat on, I'd be inclined to not change the recommended indentation, but instead just add the starting vert for alignment purposes when writing a series of patterns one per line.)

I apologize for the delay. I went out of town and haven't looked at this in weeks. I just pushed a flurry of patches pushing this towards grammar improvement and avoiding the style discussion entirely. I additionally added the trailing vert as there is benefit to doing so and little if any detriment to doing so as far as I have seen from this discussion.
I added a macro section and I was hoping someone could supply me with a simple example which would benefit from preceding and/or trailing verts. If not, I can remove it but it seemed useful to include a pertinent example in the RFC.
@vitiral That is clever though kinda quirky.

@joshtriplett In case you missed my last comment, this could still use another review.

@mdinger Just reviewed the updated version.  Looks great to me.
(I don't think I'd ever want to use both the leading and trailing vert, but both independently seem reasonable to me.)

Thanks for reviewing.
If anyone has a macro example which would benefit from this RFC (people suggested macros would benefit), please include it in a comment because it seems useful to include in this RFC but I don't have an example.

@rfcbot fcp merge
OK, I think there isn't much controversy here, so I'm going to move to accept this RFC. In summary, the proposal is to permit a leading| in patterns, primarily because this will make macro generation and so forth easier (every pattern can be emitted as | pat). This may or may not affect the choices that the rustfmt team makes (likely not, based on the comments here).

There are a lot of thumbs down on the opening comment, but little expressed negative feedback.I wonder if anyone wants to  give feedback explaining why they think this shouldn't be accepted?
I think its clear that this isn't going to be the recommended style, but in general we've taken a very liberal approach to the grammar, accepting all kinds of things that would be bad style (as Niko says the most practical reason for this is to make writing macros easier).

I'm not aware of this being a particular difficulty for macros, and I strongly prefer a standard style, so adding a way to write non-standard code without solving some kind of codegen pain means I voted 👎

I don't really like the style, nor am I aware of any macros that this would help. To merge this RFC as is without an example as to where it helps in macros or providing any kind of better justification I think is a mistake. All this RFC seems to do is change the style in a way that serves to scratch a few peoples' itch about something so that things line up. It just seems odd to have something like
match foo {
    A |
    B | => (), // At first glance it seems like a syntax error.
               // Where's the other type for after this |? | implies this pattern or this one match
               // and it's weird to just have => (), come after it
    C |
    D | => (),
}

be legal all for the sake of style. I'm against this personally. If the team does decide to accept it then I feel like the RFC as it stands could be a bit more polished particularly the detailed design part with some mentorship as it seems unsure as to how to implement it. It should also, as I have mentioned before, have examples of the Macros example it claims it would help.

@mgattozzi I'm not a fan of the "trailing vert" approach.  Leading vert, though, does help:
match foo {
    | A
    | B
    | C => {
        ...
    }
    | D
    | E => {
        ...
    }
    | F
    | G => value,
}

@steveklabnik @mgattozzi Your argument makes sense, but I feel that its philosophically misaligned with the way we normally make decisions about the grammar & what I expect to behave.
For example, even though it repeats bounds, contains empty bounds, repeated boiunds, unnecessary parens, trailing +, unused HRTBs, etc this function is grammatically correct & even well typed:
fn foo<T: , U: ToString + ,>()
where
    T:,
    T: ToString + ,
    T:,
    (U): ToString +,
    T: for<'a,> ToString +,
    U:
{ }

I myself would definitely make use of leading | (stylistically recommended or not) not because it 'scratches an itch' but for the same reason I love trailing commas. When I have a 'collating' match, where a bunch of variants are pulled together into a smaller number of arms, it produces cleaner diffs and easier editing (at least with a line-oriented editor) to structure it like this:
match foo {
    | Foo::Bar
    | Foo::Baz
    | Foo::Quux,
    => Whatever::One,
    | Foo::Spam
    | Foo::Eggs,
    => Whatever::Two,
}

It doesn't matter which variant is first if they all begin |. Obviously other people have different opinions on this, just like people have different opinions on trailing commas, but I think rustc should be unopinionated on issues like this and so far that's the position we've tended to take.

That's fine and I totally understand where you're coming from with this. Like you said, we just disagree. I do think you're right in Rust being opinionated about certain things but in this case I just felt the syntax change didn't gain much from being changed like this, especially if we have a tool like rustfmt which is trying to have a consistent style. It just seems a bit at odds in some sense. Though I'm just one person so if a lot more people prefer it (or the core team gives it a go) then I say it should be merged.

I have personally found it annoying that I can only generate | "in between" patterns when writing macros. (Do we support a trailing |?)

@rfcbot concern trailing-vert
I think a number of people do not like supporting trailing vert. I hit the FCP check-box originally thinking that this RFC was solely about adding support for leading vert (because that was the draft I had originally read), but then I double-checked and realized that the RFC author had added trailing vert to the spec as well.

@pnkfelix Oh dear, I also missed that change, and am also concerned about it (and it appears others on thread are as well).

I definitely want leading vert, and very much do not want trailing vert.

Okay, I'll bite... I haven't seen anyone explain why trailing vert is
worse than leading vert.
On Fri, Apr 28, 2017 at 4:05 PM, Nicole Mazzuca<EMAIL_ADDRESS>wrote:

I definitely want leading vert, and very much do not want trailing vert.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rfcs/pull/1925#issuecomment-298094176, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAC3n9-y0PHLx2QTfp1kPFJyZrt9n5O2ks5r0kabgaJpZM4MKvkp
.

@durka style.

@durka There are a few arguments. The most compelling to me is thinking by analogy to e.g. trailing comma, where you get consistency on each line:
StructName {
    field1,
    field2,
    field3,
}

Since we usually write | at the beginning of the next line, the analogous thing is to have an extra one at the beginning of the first line:
match expr {
    | Pattern1 => { .. }
    | Pattern2 => { .. }
    | Pattern3 => { .. }
}

whereas it doesn't make much sense at the end:
match expr {
    Pattern1 = > { .. }
    | Pattern2 = > { .. }
    | Pattern3 => { .. }
    |
}

And of course, to the extent that this is just about macros, either way solves the problem.

@aturon Trailing vert is not my preference, but I think this is more accurate as the ideal style for it:
match expr {
    Pattern1 |
    Pattern2 |
    Pattern3 |
    => { .. }
}

Which has the same consistency benefits.

@solson Understood. What I was trying to get at is, given today's style for | (which I think is very unlikely to change), there's a simple reason to prefer leading, and little reason to allow for both.

Ah, hm, I didn't realize that was the argument. For example, the following looks very normal to me:
match expr {
    Pattern1 |
    Pattern2 |
    Pattern3 => { .. }
}

I guess I'm out of the loop about what "today's style" is.

I see the discussion as conflating two distinct problems.

What should the grammar allow.
What style should be preferred / enforced.

Personally, I would consider the possibility of both trailing and leading | to be a boon for macros and code generation, regardless of the intended style of handwritten code. Besides, aesthetics are hard to evaluate without experience with either variant. Unless there is a compelling reason not to allow it on technical grounds, stylistic discussions are of limited value, as long as there is a tool like cargo fmt that formalizes the "one true coding style".

I tend to agree with @le-jzr. Similarly I wouldn't mind making leading commas grammatic, as abhorrent as I personally find styles like this:
    struct Foo {
    ,   bar: 0
    ,   baz: 0
    }

But I'm also not going to go to bat for either of these so if other people feel strongly that we should only allow trailing commas and leading verts, that's fine with me.

FWIW, when I read people having concern about the trailing vert, I read it as if something really bad could happen if the vert was supported. What is the terribly awful thing that could happen: it is possible people could (no might) use bad style 👻 👻 👻 (spooky)
Also, I don't think I'm a fan of the trailing vert but I also don't see where the dislike of it as a feature comes from. I added it under the understanding macros could benefit from it, it really doesn't hurt anyone else, and some people may like it in other cases as well.

@mdinger Adding leading vert already addresses the macro use case, no? Similarly, we don't permit leading commas.
While permitting "bad" styles isn't such a big deal, there's also little reason to go out of our way to make room for more styles in the grammar, especially given that we're hoping rustfmt will help us, as a community, consolidate our styles.

I just wanted to mention it because this whole thread reads quite fearfully about such things. In regards to the macro case, I assume so because of the conversation up to this point but as I am not as familiar with macros as others and don't know of any specific cases. I had hoped someone would put forth a specific macro example showcasing the benefits but none have surfaced yet.

If we want this merely as a convenience for code generation, and not addition of style options, then we should go with trailing vert and no leading vert, since it's consistent with comma. The only argument for using leading vert over trailing is "I like the way it looks in code", and that's an arbitrary and subjective choice for something we probably don't even want to see in handwritten code.

I do intend to use leading vert in handwritten code.  :)

I rescind my argument. :)

But despite my what I wrote earlier, I do think adding both is entirely unnecessary, and it's always prudent to add only as little as needed. After all, we can add the other case later, but we can't remove it once it's there. There is always gonna be some disagreement -- some want to use leading, some want to use trailing, and some would be unhappy if it was up to choice.

@rfcbot fcp cancel
Given the concerns about leading/trailing bars, I'm going to cancel my request to merge. I'm not really sure what the consensus is now so I think better to restart.

As far as I can tell, there's a consensus supporting leading vert, and I think the intent was to accept an RFC for that. That got derailed by a suggestion to add trailing vert as well, which doesn't have consensus.
Can the author please submit a version of the RFC that only includes leading vert? I think we can quickly FCP and accept that one.
If you feel strongly about trailing vert, or someone else does, let's deal with that in a separate issue, please. I don't think that'll get consensus as easily, though.

@joshtriplett I have updated the RFC as requested and removed the inclusion of the trailing vert. The majority of the RFC remains similar otherwise. Thanks for keeping up with this.

Given that, prior to the concerns about trailing vert, we were at FCP with almost everyone on the lang team agreeing to it, can we go back into FCP directly?

Together with https://github.com/rust-lang/rfcs/pull/1882 it will allow some fun code like
let | a = 10;

, nothing new though, inappropriate use of trailing separators always look weird.

@rfcbot fcp merge

(Sorry, wrong label.)

Weird. (The optional vert at the beginning is not very useful. I double people often writing X|Y|Z => { } many times. In most situations each enum variant need its own match branch, that's why they're different variants. And you can always write X|Y|Z in the same line.)
enum E { X, Y, Z}
use E::*;

match foo {
| X => (),
| Y => (),
| Z => (),
}

@liigo people downvoting it didn't like trailing vert, afaict. Also, you're ignoring:
match foo {
  | X
  | Y
  | Z
  => {
    println!("hi");
  }

That said, if we're going to accept leading | but not recommend you use them, it seems less exciting.

This is exactly what I'm worried about.

When I first encountered this style in F# it was very confusing to me - why begin every match arm with | when it's only single alternatives?
I also believe that it doesn't really pull its weight: Admittedly, I don't write an awful lot of Rust code but after several years, I can't remember a single match pattern with too many alternatives for a single line - which is, as I understand, the only case that directly benefits from leading verts. Correct me if I'm wrong, but isn't the entire reasoning that because it's more consistent in this particular case, we would extend that to every match everywhere? Seems questionable if only, like < 10^-3 of all match arms are improved by this change.

So to summarize, I don't mind leading |, but I do mind a style recommendation that uses it everywhere.

@main-- Now that it's available, we'll be evaluating it within the style team to determine whether and where to recommend it.
Personally, I have no intention of recommending its use for single patterns, only for multiple patterns split across lines.

Just to clarify, I downvoted against both the leading and the trailing |. @ubsan

@ubsan
when matching X|Y|Z along side A, B, C, it still looks wired (either use leading | or not).
match foo {
  | A => {}

  | B
  => {}

  C => {}
  D => {}

  | X
  | Y
  | Z
  => {
    println!("hi");
  }
}

An alternative (and possibly better?) solution is to not mud Rust syntax and give Rust macros the ability to solve this problem.
A nice quote from John Carmack:

Everything that is syntactically legal that the compiler will accept will eventually wind up in your codebase.

The RFC got 9 :+1:  and 14 :-1:. The result should have been considered by the team.
update: now the vote result is: 12 :+1: and 20 :-1: .

update 2 (2017-08-21): 15 :+1: VS 28 :-1:.

This RFC has been merged! Thanks @mdinger for writing it, and everyone else for the discussion.
Tracking issue

@joshtriplett Thanks for seeing that this got followed through with. I don't know how you guys keep your head in it with some of these RFCs. They can be endlessly frustrating. I'd have given up.

@mdinger could you have a look and consider signing off: https://github.com/rust-lang/rfcs/issues/2078

It's too sad that, many people dislike this one (-31 VS +15), but it was still approved.
To the core team, are you still keep open? are you still listening to the community?

@liigo if people do not make their voice heard, we can't help that. It has strong support across the people who care about this stuff.  The thumbs up/thumbs down thing is not a voting system, and expecting us to treat it that way seems unreasonable. The only objection I can see is "it looks weird", which is completely subjective? Otherwise, testing it out seems like a good thing. If people don't like it, we can remove it.

The thumbs up/thumbs down thing is not a voting system, and expecting us to treat it that way seems unreasonable.

Then please remove the voting system now, don't give illusions.

@leonardo-m How? GitHub, AFAIK, doesn't allow us to remove reactions.

How? GitHub, AFAIK, doesn't allow us to remove reactions.

Ignore my comment then, and sorry.

@eddyb github does allow that. Just click at the reaction symbol.

@est31 I meant to disable them. Not someone removing their reaction.

@eddyb ah right, that seems impossible indeed.

We definitely don't make decisions on the basis of thumb counts. Obviously they can have an impact, but we try to make decisions in a more nuanced manner. Here are reasons that I personally think the RFC should be merged:

Despite the thumb count, the comments felt much more positive. What seemed clear is that while many users didn't want this syntax (and maybe wouldn't allow it in their code base), there were some users who very strongly did want this and were willing to press on it. I weighed these strong positive feelings more heavily than the mild negative feelings.

We tend to support a flexible grammar when possible, including things we don't consider idiomatic at all. Philosophically, this is an RFC we are inclined to accept, and there'd probably have to be a pretty strong, practical reason for us not to accept it.

Sort of along the lines of both of the previous points, I have difficulty imagining this having a serious negative impact on any user. You might see some match arms you don't like, maybe find them a little confusing for a moment, but I have difficulty valuing this impact over the positive impact on people who want to write their code this way.

Speaking more general, RFCs are a deliberative process, not an up or down vote. The point of the process is to seek out useful commentary from community members, and while thumbs provide some feedback for decision making, they're limited in their impact in proportion to the amount of information they contain.

@liigo Small procedural note:

To the core team, are you still keep open?

This is not a core team RFC, but a lang team one.

I realize I'm a bit late, but I just saw this on TWiR. I haven't read the following point: from what I understand one of the barriers for people to get into Rust is the syntax, and those people would probably be even more put off if they encounter this kind of style disagreement upfront (this syntax is being approved because people want to use it, and when it is stable it may end up on popular posts and even on official docs) and since they are not into Rust yet, most won't participate in the RFC process.
To summarize that, I think this has some (potentially) negative impact on people outside of Rust who don't participate on the RFC process.
Personally I just find it a bit ugly and confusing, my instinct is to expect something before a | so it looks like a condition is missing. I also think that reasonable style (placing | on the end of the previous line) was already proposed that makes the code align. I get the flexibility argument, for example, one could use leading semicolons, for example, but I also feel that this is a stretch.

I just saw this in TWiR - this is a really weird syntax.....

(Somehow I missed this one in the last couple of weeks of TWiR or I would have commented earlier. I don’t really get the motivation for this and I feel the drawbacks section being empty is unreasonable, but let those pass for now.)
One concern I have about this is the impact on macro rules. As it stands, we have the pat fragment specifier which dovetails well with repeating groups to cover most of match_pat in a very simple pattern—granted, it doesn’t support the guard ([ "if" expr ] ?), but at least it supports multiple patterns (pat [ '|' pat ] *):
$($patterns:pat)|+

If you want to support the [ "if" expr ] ? as well, it’s not too bad: you need to tack on
$(if $guard:expr)*

(Side note: we really need $(…)?.)
After this change, people writing macros that want to accept match patterns will need to prefix $(|)* to make it support the full match_pat grammar. It’s not a big deal, but it’s just one more thing that stands in the way of writing DSLs that behave like proper Rust.
You may say that trailing commas already have this problem (hence the pattern $(x:expr),* $(,)*, the $(,)* part of which I freely admit many don’t know about—so it is already a problem), but I think it’s more severe (though less common) with this one because I don’t expect many people to write match patterns with leading pipes (I never intend to), and so people writing macro libraries are much less likely to think of coping with the optional leading pipe, which will make people that like this pattern grouchy.
One of the main problems with increasing grammar complexity is in macros that wish to support or emulate the full grammar with certain variations of behaviour; unless we have a fragment specifier which handles that part of the grammar, macro rules become steadily more complex, or become incomplete (leading to frustration when the macro doesn’t work with otherwise normal Rust code).
After this RFC is implemented, full support for match patterns in a macro are going to be
$(|)* $($patterns:pat)|+ $(if $guard:expr)*

i really dislike the idea to have many syntax options for the same think. It makes it imo harder for a beginner to understand the language since it raises questions like
“With syntax to use and why?”, “Are there any differences and if not why have the different syntax in the first place?”, “With way will run faster?” and so on

Ppl don't use
match x {
    Hello     |
    World     |
    AndThings => ...,
}

?
You know we have this same "issue" with || and && and so on, right?
Wonders how long until Rust decides to deprecate this
The only nice thing about this is that now you can "convert" C into Rust with a simple s/case [ident]:/| [ident]/ but if that's the only nice thing and everything else sucks then it's not really a good feature now is it?

if
x
|| y
|| z
{

Are we gonna allow this next, for consistency?
if
|| x
|| y
|| z
{

I still prefer the apparently much dreaded
if
x ||
y ||
z {

I have absolutely no idea why this is so dreaded.

I'll take the clippy lint tbh

@warlord500 indeed, inside an expression, leading || means the beginning of a closure with no arguments. So if that's allowed, Rust (and we) will have a bad (as in C++ context-sensitivity level bad) grammar problem.

The feature was stabilized and shipped in the 1.25.0 version of the Rust compiler/language. You won't be able to remove it now due to the stability promise, except of removing it from the 2018 edition but I'd say that is very unlikely... It'd require a separate RFC and good reasoning (not just thumbs). So fuming is a bit pointless I'd say.

@est31

So fuming is a bit pointless I'd say.

I think the fuming should be seen as a signal to the language team that they might want to be more careful about adding such features in the future.
Perhaps the down votes should be seen as a "Hey, let's stop and reevaluate this — out of the people who voted, a vast majority didn't like this idea". A good next step would be to wait until someone presents proper arguments against the idea. Accepting an idea by default seems bad to me.

@mgeisler

Perhaps the down votes should be seen as a "Hey, let's stop and reevaluate this — out of the people who voted, a vast majority didn't like this idea".

That's what @withoutboats did in a comment last year after the first call for FCP:

There are a lot of thumbs down on the opening comment, but little expressed negative feedback. I wonder if anyone wants to give feedback explaining why they think this shouldn't be accepted?

That resulted in re-opening the discussion. Posts between the first and the second FCP mostly addressed concerns about trailing vertical bars. Trailing vertical bars were removed from the RFC.
In the second FCP itself, two people said they were against it. One gave no reason.  The second gave two: that it was weird syntax, and that there were more thumbs down than thumbs up.   The thumbs up/down is not a voting mechanism, and in this case it was also hard to know whether the thumbs down were primarily about leading or trailing vertical bars.
As for the growing number of thumbs down, I can't know whether a new thumbs-down means "I'm against leading vertical bars" or "I'm annoyed with the language team". And neither can the language team. A comment conveys a lot more information than a thumbs-down.
I think the language team did a fine job of listening to the community on this PR. It may be that

it was the wrong decision;
Rust should make syntax changes much more slowly than it has in the past; or
the process for involving the community could be improved.

I don't know the answer to the first two points.  The answer to the third point is of course "Yes, the process could be improved." Because anything can be improved.  And I do think the process is currently excellent.  (I also believe that treating thumbs up/down as a vote would be a move in the wrong direction: online polls are not a good way to count votes, let alone to reach a rough consensus.)

@mgeisler like any kind of feedback, complaining and thumbs down have the most effect the earlier on you are in the process. After a feature has been stabilized and even shortly before it is being stabilized, complaints have the least effect.
You didn't even define what "such features" means... how should the language team know that?
What I suggest for you in the future is that you read the RFCs opened and voice your concerns, or even just :-1: the RFCs you don't like. The try RFC #2388 is on a similar course as this one: the number of :-1: is increasing more rapidly than the number of :+1: 's. But better is to :-1: earlier on in the process.

try / #2388 can still be pulled back, at least, since it's nowhere near stable

I think this thread has outlived its usefulness.


Log all status information about broken waiter

What type of PR is this?
/kind feature
What this PR does / why we need it:
We are not logging whole PodComponentsStatus information. This might be useful to understand what is teh status of failed pods.
/cc @wojtek-t
/assign @mborsz

/lgtm
/approve


[Bug]: Update JAX imports

PyBaMM Version
Develop
Python Version
3.11.5
Describe the bug
While trying solutions for #3617, I discovered that many JAX imports are deprecated. For some reason, this deprecation causes the pytest not to run the tests correctly and pytest only shows deprecation warnings.
I tried fixing a few imports by changing the source code, but it is better to open an issue.
Steps to Reproduce

From the file test_base_submodel.py, run any test using pytest (I ran test_parameter_info_error)
The code I used to run pytest is as follows:

/home/yukinatsu/miniconda3/bin/conda run -n pybamm --no-capture-output pytest /home/yukinatsu/PyBaMM/tests/unit/test_models/test_submodels/test_base_submodel.py::TestBaseSubModel::test_parameter_info_error

You will encounter in total 3 Deprecation Warnings in total (Next warning will come after you solve the previous one)
The following are the warnings:

TWO WARNINGS OF : DeprecationWarning: Accessing jax.config via the jax.config submodule is deprecated.
ONE WARNING OF : DeprecationWarning: jax.linear_util.transformation is deprecated. Use jax.extend.linear_util.transformation instead.
Concerned files:

jax_bdf_solver.py
evaluate_python.py

I changed the imports as needed and there are no further errors and pytest works as intended. I would be happy to take this one.
Relevant log output
No response

Thanks for opening an issue about this @cringeyburger, I'm happy to assign you to it. Looks like I missed some of these deprecation warnings that you have mentioned when I had opened #3644.

@cringeyburger Was this with the latest pybamm? A PR was merged a few hours ago to address the jax_bdf_solver.py warnings (#3671). Just curious if that change was incomplete, if so then feel free to finish it up

Yes, I noticed the recent PR merged by @prady0t, but it seems that a few warnings (solved one was for jax.extend, the jax.config were left out) were left out. I will be opening a PR,


vimPlugins.headlines-nvim: add nvim-treesitter dependency

Description of changes
Add the nvim-treesitter dependency of headlines-nvim.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

The website mentions it being dependent on nvim-treesitter but is that really the case ? on a quick skim, it seems to use vim.treesitter. If it's just to install grammars, might be best to just install grammars directly but since treesitter is such an annoying thing, we would pull an unstable grammar while the user uses stable neovim.
In this peculiar case I wonder if the best thing is not to just do nothing.

In this peculiar case I wonder if the best thing is not to just do nothing.

Indeed, you are right. Closing.


Fix triangles not render correctly on android

I had the same issue mentioned here #9.
So I found a fix and tested on several devices (720x1280, 1080x1920, 1080x2220 and1440x2560) on Android 11.0

Problem resolved hence closed


Unable to test speech in web chat in chrome's ver 60+

Hi
I have a Azure chat bot implemented in a webchat.We are using the botchat.js and botchat.css files to enable speech in Google Chrome browser.
It worked perfectly for the Chrome Ver 59.0 and now when the chrome got upgraded to Ver 60.0  and then to 61 we are not able to test the speech functionality in chat bot.
Also it was not working IE browser, Is there any update that chatbot’s speech functionality will work in IE(Internet Explorer) too.

@shahidkhuram can you verify?

Not sure if related. I have galaxy s8, the speach doesnt work as well. It activates listening but you say something it does nothing.

For speech recognition the WebChat sample provides two options:

Browser based speech recognition (experimental, not supported in all browsers)
Cognitive services speech using this sdk:  https://github.com/Azure-Samples/SpeechToText-WebSockets-Javascript

Neither option is supported in internet explorer and i'm not aware of any plans to add support.
As for the report that speech isn't work in chrome, please clarify whether you're using browser based speech or cognitive services and what specific error you see. I just tried both options in Chrome Version 61.0.3163.91 on Windows and didn't notice any issues.
Please note that if you're opening a local html file, chrome blocks audio access. You can start a server locally via "npm run start" in a clone of the webchat repo, or see the speech sample html for details of how to restart chrome to allow access to the mic to local files.

@shahidkhuram Used cognitive services. Works fine in Desktop Chrome. Doesn't work on mobile device chrome. Using web socket. What information I can provide for you guys to test?
Thanks
Nick

@nicksav Could you try if our Speech sample HTML? Just want to make sure there are problems on our side. You may need to un/comment some code to enable browser speech API scenario.
Then, could you let us know what platform you are on? OS + version + browser version (stable/beta). F12 console dump would be helpful too.

@nicksav WebRTC is required for Cognitive Services and Chrome 62 and iOS 11 start supporting it. Can you see if Cognitive Services work on your side now?

I have had a lot of problems with it too, Im using the next code:
var speechOptions = {
speechRecognizer: new CognitiveServices.SpeechRecognizer({
locale: 'es-ES',
subscriptionKey: 'MY_KEY'
}),
speechSynthesizer: new CognitiveServices.SpeechSynthesizer(
{
subscriptionKey: 'MY_KEY',
gender: CognitiveServices.SynthesisGender.Female,
voiceName: 'Microsoft Server Speech Text to Speech Voice (es-ES, HelenaRUS)'
}
)
}
And the only browser that works for recognition and synthesis is Chrome.
In desktop version, it works well. However in mobile (ZTE Axon 7 - Android 7.1), I get the microphone icon, and voice recognition works well, but speech synthesis only works for the first message, after that, the microphone activates when there are prompts, but I can't hear anything.
In iPhone, microphone icon doesn't appear even using Chrome with the same index.html code.

@DanielTizon Chrome/Edge in iOS is a stripped down version of Safari, a.k.a. WebView. As we verified, WebView in iOS does not support WebRTC, thus it does not show the microphone icon.
I will verify Android scenario to make sure it works in Chrome. I think Android has a better support because AFAIK, their WebView is actually a full-blown version of Chrome.

@yazhinichurchill Chrome recently modified IFRAME sandbox security. You will need to add extra tags to enable WebRTC in IFRAME.

Closing due to inactivity. We can reopen if this is a continuing issue for users.


Track multiple runtime dependencies per transaction

We can also maintain the preprocessed dependencies to recover them when the transaction invalidates.

Closing as:

Early experiments have shown bad results. It's usually better to abort as soon as possible.
We have removed preprocessing and hence don't track the number of dependencies per transaction anymore.


Remove onCommand:type from activation events

Addresses #36575
Activating "onCommand:type" means that all typing in any editor will wait for emmet to activate before proceeding. I suggest emmet removes this activation event. If this doesn't work, activating on * is actually better than on onCommand:type. onCommand:type should be something used by the vim extension which literally wants to block all editor input until it comes up.

With https://github.com/Microsoft/vscode/commit/8bc02c7443305a0db442c11b76e67d6f4929dc0e, emmet will now get activated on *
Emmet can be enabled for any file type if the user adds the required mapping in settings. Emmet has a completion provider that should get triggered in such files when user starts typing. If there was fixed set of file types, then onLanguage activation event would suffice. But since that is not the case, I ended up using * which I then changed to onType in the last release when Jo noticed the Emmet affecting start up time
Will look into getting an activation event for completions which would be perfect for emmet.

@ramya-rao-a An alternative to introducing a new activation event is:

load up only a small part of emmet on * (like the tip of the iceberg)
use the API to read your configuration and determine a set of languages emmet needs to operate on.
use the API to listen to text documents getting created and check their language id against the configuration-determined set.
if needed, load the rest of emmet (the full iceberg).

@alexandrudima
There is one main module that I load for emmet. With https://github.com/Microsoft/vscode/commit/81cca6cc606eeca3443998025bff3893fcfe3ad5, I've made it so that it gets lazy loaded. With this codeLoadingTime taken by emmet during startup is under 50 ms.

Nice!


Dedicated testing doc

Description
This PR adds a dedicated testing doc and moves a couple GUI tests into the right places in the repo, inspired by conovs coming out of #1363.
I added some language about unit tests, integration tests, functional tests from https://www.softwaretestinghelp.com/the-difference-between-unit-integration-and-functional-testing/. Some of this is more "aspirational" then where we are in practice right now as @tlambert03 recently pointed out, but documenting this stuff might help us get there.
I also added a known issues section which is a little thin right now, but maybe @tlambert03 if you wanted to take this PR over and flesh it out that would be great!! (Also feel free to rework the intro).
I added some language in the contributing guide to now point to this new doc.
Let me know what you think!
Type of change

[x] Documentation, refactor

added a few of the additions discussed in #1363

Love the additions @tlambert03 very nice! Maybe @jni can give this a read over before merge?

Actually @tlambert03 should we add more info to this doc about our CI, including what we test: different python versions, different OS versions, different Qt versions, showing the full grid for merge into master, and the partial grid on our PRs?
Also what we've disabled for the various platforms - for example I always keep forgetting what fraction of vispy/ Qt stuff is enabled on windows CI right now (I seem to recall not all) and this would be a great place to document that.
We could rename whole doc Testing and CI. Thoughts?

I don't have strong feelings about this.  I haven't too frequently come across documentation on CI strategies in other projects, and they do change/evolve over time, so it would make another place we have to check each time we make changes (lest it go out of sync).  But if you want to have a place to go to look those values up (and want to make sure that new PRs always update it 😂) then I don't have any objections.


fix: frames filename

lmao, scraping works but, i haven't check the filenames lol.
But this should fix it.


Model Builder reference error

On the CLI my regression model trains without issue, and the FastTreeTweedie is automatically selected as the best performing. In the resulting files produced by the model, in the Model.cs, I am getting an error: "The type or namespace name 'FastTreeTweedieTrainer' could not be found (are you missing a using directive or an assembly reference?) (CS0246) [VesselAnalytics]". This seems to be linked to the ML.FastTree but if you know of a workaround then that would be great, i.e. is there an obscure using reference that isn't automatically inserted by the model I need to insert.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 1b723be0-9b74-15da-b850-2b420c4a31b6
Version Independent ID: 557580d1-4af7-2fb7-9e48-643bcb14c11d
Content: TreeExtensions.FastTreeTweedie Method (Microsoft.ML)
Content Source: dotnet/xml/Microsoft.ML/TreeExtensions.xml
Product: dotnet-ml-api
GitHub Login: @sfilipi
Microsoft Alias: johalex

seems to be a bug in old cli. Looking through the code, the latest Microsoft.ML.CodeGenerator should already fix this.


IMPROVEMENT: Added package to AUR

Please prefix your pull request with one of the following: [FEATURE] [FIX] [IMPROVEMENT].
In raising this pull request, I confirm the following (please check boxes):

[x] I have read and understood the contributors guide.
[x] I have checked that another pull request for this purpose does not exist.
[x] I have considered, and confirmed that this submission will be valuable to others.
[x] I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
[x] I give this submission freely, and claim no ownership to its content.

My familiarity with the project is as follows (check one):

[x] I have never used the project.
[ ] I have used the project briefly.
[ ] I have used the project extensively, but have not contributed previously.
[ ] I am an active contributor to the project.

Added to AUR uwu pls gib open source points thx >///<

Btw there are more badges for AUR: https://shields.io/

you get 3 osp <3


Change default interface to masquerade on functional tests

What this PR does / why we need it:
This PR change the default interface for pod network to masquerade.
This PR will help reduce/eliminate the issue with unsupported 0xFE mac address for libvirt
Fixes #1494
Special notes for your reviewer:
Release note:

NONE

This change is

/test pull-kubevirt-e2e-k8s-multus-1.13.3

/test pull-kubevirt-e2e-k8s-multus-1.13.3

/retest

Is there an issue created outlining what the problem is this PR aims to fix? Since I don't understand the problem, it's unclear if this is a good solution or not.

@davidvossel IIUC it should fix https://github.com/kubevirt/kubevirt/issues/1494

@SchSeba let's not forget that we want to keep one or two tests which explicitly test the direct pod-network integration.

/hold

/test pull-packer-kubevirt-e2e-k8s-1.11.0

/test all

@rmohr @cynepco3hahue @slintes
this test is failing consistently but I think it's unrelated to this change.
Summarizing 1 Failure:
[Fail] Storage Starting a VirtualMachineInstance With Alpine ISCSI PVC [It] should be successfully started
/root/go/src/kubevirt.io/kubevirt/tests/utils.go:344

@phoracek @booxter @vladikr can you please review this?

Let's see what the test run on the next PRs say. Out of the results there we can fix flaky tests which were not caused because of the MAC issue.

Oh, @ILpinto and @SchSeba I actually wanted to ask if all polarion test ids now still match what they are supposed to test.
/cc @ILpinto

@rmohr good question!
I leave 4 tests under the Multiple virtual machines connectivity using bridge binding interface to use bridge

is this something we want to backport to 0.17?
@stu-gott @fabiand

/cherrypick release-0.17

/cherrypick release-0.17

/cherrypick release-0.17


Metric on dependency size

There is already metric for external dependencies, but would be useful to see internal modules as well to have a picture on how much code each module actually depends
Either joining by module name or some preprocessing due to transitive dependencies - might have a challenge of duplicates

Issue comment

Some comment

nah, not worth the effort now


sh: Can't open /home/chronos/user/Downloads/crouton

Please paste the output of the following command here: sudo edit-chroot -all
sudo: edit-chroot: command not found

Please describe your issue:
Trying to install unity crouton onto my Chromebook because I was having trouble with xfce and wanted to try something else.
I install crouton, go into shell, then type in "sudo sh -e ~/Downloads/crouton -t touch,unity" and it comes up with "sh: Can't open /home/chronos/user/Downloads/crouton"
I've redone that step several times now, deleting and reinstalling crouton, going into shell, typing in the same command, and getting the same error in the output.
If known, describe the steps to reproduce the issue:

See this similar post: https://github.com/dnschneid/crouton/issues/3215#issuecomment-298200699, maybe it'll help.

I've re-downloaded several times, and it hasn't worked.

Please show us the output of: ls -l ~/Downloads

chronos@localhost / $ ls -l ~/Downloads
total 0
Is there any chance I might have to format this after download?  I feel like a friend of mine did something with crouton after download when he was initially showing me this, but I'm not sure.

Thanks for your help by the way.

@ExpertSummer328,

I've re-downloaded several times, and it hasn't worked.

You may have changed the default download location in Chrome OS settings so it's getting downloaded to another location. Here's what mine is set to:

chronos@localhost / $ ls -l ~/Downloads
total 0

Your Downloads folder is empty, no crouton or anything else for that matter.
If you know where it is downloaded then use that in the path instead of ~/Downloads.
Hope this helps,
-DennisL

Awesome, thank you!  I checked ask where and made sure it was in downloads and it worked.  Now:
unity is unsupported on ARM for releases after precise.
This came up just now.  Does this mean I have to specify a version of unity Linux, or is it just not compatible with my hardware?

@DennisLfromGA I'm fairly sure I figured out was what was happening.  If you have a dual login, the shell accesses the files from the account you logged into first, regardless of which account the shell is open in.  Therefore if I downloaded crouton in my second account, then tried to access it in the shell in my second account, it wouldn't find crouton and wouldn't work.  Thanks for your help!

@ExpertSummer328,
Yes, your Downloads folder is associated with the first user that logs in, the devil is in the details. ;)
-DennisL


Wrong offset for RTW decoding

Hardware
ESP32
Firmware version
since v2.1.4
Application version
since v2.1.4
What happened? What did you expect to happen?
The RTW frame decoding gives wrong results, they are offset by 1.
void somfy_frame_t::decodeFrame(byte* frame) was changed in commit 74ee9f6f25fe5b63138a3e1d037124c5ba5a1095.
Before:
switch(this->encKey) {
  case 149:
  case 133:
    this->cmd = somfy_commands::My;

...
Then:
else if(this->encKey > 133) {
   this->proto = radio_proto::RTW;
   this->cmd = (somfy_commands)(this->encKey - 133);

As somfy_commands::My == 1, the subtrahend should be 132
How to reproduce it (step by step)
1. Go to log window
2. Click on any button of an RTW remote
...

Logs
{"encKey": 136,
  "address": 7339838,
  "rcode": 2898,
  "command": "My+Up",
  "rssi": -37,
  "bits": 56,
  "proto": 1,
  "valid": true,
  "sync": 4,
  "pulses": [102452,47299,10146,97684,2604,2564,2533,2596,4872,1281,1314,629,660,628,665,1276,1309,644,655,639,656,644,646,1289,648,644,653,636,656,645,644,637,661,624,668,630,1311,1269,681,615,654,643,1300,1291,1294,639,680,618,673,613,683,1273,1305,626,667,1280,657,644,1296,641,649,1269,1336,618,674,1265,1322,634,661,1267,668,634,1311,1268,659,615,1327,1281,657,619,1319,1267,1321,637,658,644,646,1289,1299,633,657,629,671],
  "time": "2024-12-28T17:50:55.385+0100"
},
{"encKey": 133,
  "address": 7339838,
  "rcode": 2899,
  "command": "Unknown(15)",
  "rssi": -42,
  "bits": 56,
  "proto": 1,
  "valid": false,
  "sync": 4,
  "pulses": [70071,32277,102404,102368,99866,2593,175,102356,673,10118,91598,1116,4985,2593,2563,2553,2569,4893,1281,1305,624,682,614,679,617,676,1260,1315,1289,1298,1285,657,642,646,637,661,624,668,631,660,641,1301,630,660,1291,643,633,660,640,1298,1284,1305,1275,1335,620,655,1283,1317,635,658,1270,654,635,1305,649,658,1267,1319,636,656,1269,1333,620,668,1258,664,644,1304,1274,674,613,1310,1270,687,627,1295,1288,1299,632,660,640,674,1272,1311,618,675,639,657],
  "time": "2024-12-28T17:51:00.165+0100"
},
{"encKey": 134,
  "address": 7339838,
  "rcode": 2900,
  "command": "My",
  "rssi": -42,
  "bits": 56,
  "proto": 1,
  "valid": true,
  "sync": 4,
  "pulses": [102400,1109,101262,19864,15995,44000,22577,9484,27918,18916,10128,59637,529,502,650,1371,474,1176,1749,19918,11683,2617,2555,2560,2577,4875,1292,1294,636,661,623,668,631,660,1291,668,609,1310,646,671,1265,672,620,655,639,657,644,1295,642,649,1294,1312,1268,659,641,651,617,1328,624,665,1280,1307,623,682,616,676,1268,1311,643,645,1286,665,621,1306,646,668,1261,1329,625,659,1266,1320,638,657,1271,656,639,1306,1277,659,647,1293,1292,645,649,1309,1270,1304,623,668,657,636,1280,1319,641,651,643,652],
  "time": "2024-12-28T17:51:02.460+0100"
},
{"encKey": 136,
  "address": 7339838,
  "rcode": 2901,
  "command": "My+Up",
  "rssi": -38,
  "bits": 56,
  "proto": 1,
  "valid": true,
  "sync": 4,
  "pulses": [102396,102367,40736,61702,63195,10144,97696,2565,2594,2536,2570,4894,1288,1300,631,660,630,671,1272,1309,643,654,639,655,642,647,1289,649,644,652,639,656,619,1322,639,649,644,654,638,656,1269,683,614,680,617,1323,614,667,1281,656,643,1296,641,648,1295,1311,617,676,1289,645,622,1308,645,669,1258,1306,650,659,1266,1319,639,658,1270,656,640,1316,1271,661,624,1320,1265,672,621,1308,1272,1326,641,643,649,659,1266,1320,614,684,620,670],
  "time": "2024-12-28T17:51:11.174+0100"
}

in time order:
down -> My + up     = 136
My   -> Unknown(15) = 133
up   -> My          = 134
down -> My + up     = 136

Of course also
else if(this->encKey > 133) {
should be changed to > 132 or >= 133

Which motors do you have?  I don't have this equipment and another user tested this and said it was correct.  I'll look at my notes to see if maybe I need another protocol type.


[Modules] Updated Websites Module to enable "publicNetworkAccess" property on Parent module

Description
Updated to set property "publicNetworkAccess" at the higher level required for Azure Policy checks
This is required as part of the "Azure Landing Zones (ALZ) Policy Initiative (PolicySet) - Public network access should be disabled for PaaS services"
Policy: https://www.azadvertizer.net/azpolicyadvertizer/1b5ef780-c53c-4a64-87f3-bb9c8c8094ba.html
Initative: https://www.azadvertizer.net/azpolicyinitiativesadvertizer/Deny-PublicPaaSEndpoints.html
Type of Change

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

Checklist

[x] I'm sure there are no other open Pull Requests for the same update/change
[x] My corresponding pipelines / checks run clean and green without any errors or warnings
[x] My code follows the style guidelines of this project
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation (readme)
[x] I did format my code

@chris5287 thank you for your contribution :) A couple of comments:

The main.json for the module would also need to be generated when adding new parameters to the main.bicep file.
Have you been able to test out the parameter changes?

If you do not have a test environment. Happy to support by merging your changes into a new branch in this repo and test it out

@chris5287 thank you for your contribution :) A couple of comments:

The main.json for the module would also need to be generated when adding new parameters to the main.bicep file.
Have you been able to test out the parameter changes?

If you do not have a test environment. Happy to support by merging your changes into a new branch in this repo and test it out

I do not have a test environment currently, I was not sure how to update the main.json file as I'm doing this edit from a web browser. I'd appreciate if you could help out here :)


Please use Matomo or another open source analytics software.

Since the purpose in #22 is to know about the website visitors, I believe Matomo would be a much better choice for users privacy and would remove our reliance on Google (which I think is bad for reasons that are probably obvious by now).
It just makes sense to me for a free software project to use free software tools as opposed to proprietary tools.
(This would also affect #24 of course)

What we can do better is inform the users, adding a cookie consent bar, for example, or explaining in the privacy page how to configure the web browser to block trackers
Re-reading this, it's worth mentioning that such a solution would be opt-out, what we could do instead is having it be opt-in by only loading the google tracker if the person's accepted.

@jgarciao I've got green light for using Matomo hosted by GNOME Foundation. Ping me on IRC when you're around, I will create an account for you.

@barthalion just gave me access to GNOME's Matomo. I'll be able to take a look and test it in July

@barthalion just gave me access to GNOME's Matomo. I'll be able to take a look and test it in July

Please don't forget about removing other google trackers as well, such as googleusercontent.com.

@barthalion just gave me access to GNOME's Matomo. I'll be able to take a look and test it in July

Please don't forget about removing other google trackers as well, such as googleusercontent.com.

Googleusercontent is not a tracking source, it's an hosting service, I'm unsure why we use it only for certain images but that's another thing.

There are commits to remove Google Analytics (like https://github.com/flathub/linux-store-frontend/commit/f6bcc61d53ae572f4bc89a5d8c3e75961241c0ad), but it's still there:
https://github.com/flathub/linux-store-frontend/blob/855e2cfcb464ac71ae2a905a3f6a615163665c89/src/index.html#L252-L267
What's the reason?

Dear Flathub users. I'm the one who added Google Analytics in the first place and now I'm removing it with PR #270.
I'm sorry it took so long (a year since I added Matomo) but my involvement with this project has been very limited in the last couple of years for multiple reasons.
Thanks for contributing making flathub better with your suggestions. Happy 2021


PhantomJS constantly crashes for some urls

I'm using phantomjs 1.9.1 on my Windows 64bit.
I have dumps but I cannot atache them to the issue - how can I do it?

Please upgrade to PhantomJS 2.0. 1.9.x is no longer supported, and known to have many crasher bugs that are fixed in 2.0.


Improve E2E run times by caching go libs [DO NOT REVIEW]

Description

closes: #5001

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (see CONTRIBUTING.md).
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Code follows the module structure standards and Go style guide.
[ ] Wrote unit and integration tests.
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/).
[ ] Added relevant godoc comments.
[ ] Provide a commit message to be used for the changelog entry in the PR description for review.
[ ] Re-reviewed Files changed in the Github PR explorer.
[ ] Review Codecov Report in the comment section below once CI passes.

closing this PR as not actively working on, we can use it as a reference in the future.


Preparing for migration to numba=0.54

Motivation: keep up with the latest numba release.

Hello @kozlov-alexey! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file sdc/hiframes/pd_series_type.py:

Line 171:1: E402 module level import not at top of file
Line 172:1: E266 too many leading '#' for block comment
Line 187:2: W291 trailing whitespace
Line 194:2: W291 trailing whitespace
Line 199:2: W291 trailing whitespace
Line 202:2: W291 trailing whitespace
Line 205:2: W291 trailing whitespace
Line 211:5: E266 too many leading '#' for block comment

In the file sdc/str_ext.py:

Line 676:1: E266 too many leading '#' for block comment
Line 691:1: E402 module level import not at top of file
Line 692:1: E302 expected 2 blank lines, found 0
Line 828:1: W293 blank line contains whitespace

In the file sdc/tests/test_strings.py:

Line 163:17: E266 too many leading '#' for block comment

@AlexanderKalistratov, I've just updated to current master and pinned numba==0.54.0 in all files. Hopefully when it's released all checks should pass - they did locally when I checked with 0.54.0rc3, e.g.

FAILED sdc/tests/test_basic.py::TestBasic::test_assert - numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
=================================================== 1 failed, 1257 passed, 477 skipped, 32 xfailed in 290.32s (0:04:50) ====================================================

(and test_assert really passes and fails only when l run it's via pytest -n).


Align SLT api with changes in OV.

Align SLT api with changes in OV.

@apankratovantonp this PR requires only approval. It will be merged together with other 2 PRs (API change in OpenVINO and API update for ARM plugin).
There is a change in API for ConvolutionBackprop SLT (output_padding attribute and output_shape input were added link). With this PR I updated ConvolutionBackprop SLT for ARM plugin. I've also created a pipelinewith PRs to merge. All PRs will be merged when I will receive approval for them.

@sdurawa is it targeted for 2021.4 release?

yes, this change is a part of 2021.4 release (https://jira.devtools.intel.com/browse/CVS-37430)

@sdurawa  got it.
Next time, please, create a fork of the repository instead of pushing dev branch to the original repository.
Details are explained here: https://github.com/openvinotoolkit/openvino/wiki/Contribute

@sdurawa please pull the latest changes from master - it should fix arm build on Azure.

@sdurawa I've noticed CVS-37430 you referenced is already closed.
Should we merge this PR?

@alvoron, I converted ticket to draft as I will provide some changes next week into this PR. There is a new approach to resolve plugin dependency which won't break CI builds.

Closing this PR as the new one is created: https://github.com/openvinotoolkit/openvino_contrib/pull/161.


Cleanup exception signatures

Blocked by https://github.com/microsoft/CEDAR.Core.Collector/pull/124

#126 is a better clean version of this PR


PTC Login not working

It seems that PTC login is not done on every app start, instead it is cached for some time (several hours).
Sometimes, i get "Unable to log in" even on playing screen.
Restarting MITM proxy doesn't help.
The only way to fix issue is to disable proxy, restart app so that it can authorize with PTC, then enable proxy (after which restart works)
Also not sure if this is related to MITM proxy or xposed module

Hey @BRZ420, are you using ProxyDruid and have you installed the certificate? Cheers!

Yes, using ProxyDroid, and certificate is installed in system, as MITM obviously works if i get around initial PTC login.

Enabling debug, while pressing login repeatedly shows this in log:
[+++] Connect to  <IP_ADDRESS>:443
[-] HTTPS_CLIENT_ERROR on :
[+++] Connect to  <IP_ADDRESS>:443
[-] HTTPS_CLIENT_ERROR on :
[+++] Connect to  <IP_ADDRESS>:443
[-] HTTPS_CLIENT_ERROR on :
[+++] Connect to  <IP_ADDRESS>:443
[-] HTTPS_CLIENT_ERROR on :
[+++] Connect to  <IP_ADDRESS>:443
[-] HTTPS_CLIENT_ERROR on :
[+++] Connect to  <IP_ADDRESS>:443
[-] HTTPS_CLIENT_ERROR on :
[+++] Connect to  <IP_ADDRESS>:443
[-] HTTPS_CLIENT_ERROR on :

There are some other IP addresses with errors (google, unity), but they don't repeat on each login attempt

Seems to be related to #127
Any chance on adding list of IP addresses to force domain?

@BRZ420 can you test the changes in #145 to see if that helps with your problem? That adds the PTC login server to the list to map to domains. Thanks!

I had same problem after install new version of xposed-pokemon , so try to go for version 1.1 and than reboot your phone normal way (not just software restart from xposed )

Confirmed, working


Refresh is needed to see correct compact DDL for a view with comments

System information:

Operating system (distribution) and version Win10
DBeaver version 7.2.4

Connection specification:

Database name and version Oracle

Describe the problem you're observing:
Refresh is needed to see the correct compact DDL for a view with comments when the compact form DDL was selected in the view editor before closing
Steps to reproduce, if exist:

Open a view (e.g. HR.EMP_DETAILS_VIEW)
Select compact form DDL in the bottom toolbar
Close the view
Open it again.
Expected: DDL without comments is displayed
Actual result: comments are displayed in compact DDL view
Select No storage information
Then select compact form again
Then select No storage information again
Expected: DDL with comments is displayed with  No storage information option
Actual result: comments are not displayed

Fixed in 7.2.5

Still can be reproduced the first part of the issue:

Open a view (e.g. HR.EMP_DETAILS_VIEW)
Select compact form DDL in the bottom toolbar
Close the view
Open it again.

Expected: DDL without comments is displayed
Actual result: comments are displayed in compact DDL view
Workaround: Refresh the view
DBeaver	<IP_ADDRESS>011021435

Still can be reproduced the first part of the issue:
1. Open a view (e.g. HR.EMP_DETAILS_VIEW)

2. Select compact form DDL in the bottom toolbar

3. Close the view

4. Open it again.

Expected: DDL without comments is displayed
Actual result: comments are displayed in compact DDL view
Workaround: Refresh the view
DBeaver <IP_ADDRESS>011021435

Fixed

verified


Respect event delay in output

Delay property is used to simulate timeouts in console output. It's necessary because the Go playground mocks system time and disables timeout functions like time.Sleep and etc.
For instance, let's take the snippet below:
fmt.Println("fizz")
time.Sleep(2 * time.Second)
fmt.Println("buzz")

If you don't simulate timeout between events, both lines will be printed simultaneously.
To fix this issue, it's necessary to add a simple setTimeout between outputs:
const sleep = n => new Promise((res) => setTimeout(res, n);

 for (const event of js.Events || []) {
      // not sure it this is delay in seconds or nanoseconds
      // but let's assume that .Delay is in seconds for demo purposes.
     if (event.Delay > 0) await sleep(event.Delay);
      switch (event.Kind) {
        case 'stdout':
          stdout.innerText += event.Message
          break
        case 'stderr':
          stderr.innerText += event.Message
          break
        case 'system':
          system.innerText += event.Message
          break
      }
    }

Thanks @x1unix :) I was wondering how to deal with event.Delay last night. Now it looks cleary. I'll work on it then :)


I need help

I need help, basically im trying to search for all CVEs related to this windows os (windows_10_21h2:10.0.19044.3930)
but dont understand how to get the response as the cpe search is removed from api 2.0.
i just need to print all related CVEs to the windows_10_21h2:10.0.19044.3930
any help is much appreicated.

Hi! User CPE 2.3 version. The CPE for windows_10_21h2:10.0.19044.3930 is: cpe:2.3:o:microsoft:windows_10_21h2:10.0.19044.3930:::::::*
So, to get all CVEs related to this CPE:
import requests

def get_cves(cpe_name):
    url = f"https://services.nvd.nist.gov/rest/json/cves/2.0"

    try:
        response = requests.get(url, params={'cpeName': cpe_name})
        response.raise_for_status()
        data = response.json()

        cves = []
        if 'result' in data.keys():
            for result in data['vulnerabilities']:
                cve_id = result['cve']['id']
                cves.append(cve_id)

        return cves

    except requests.exceptions.RequestException as e:
        print("Error making request:", e)
        return None

# Replace the CPE name with your desired one
cpe_name = "cpe:2.3:o:microsoft:windows_10_21h2:10.0.19044.3930:*:*:*:*:*:*:*"

cves = get_cves(cpe_name)
if cves:
    print("CVEs associated with the given CPE:")
    for cve in cves:
        print(cve)
else:
    print("No CVEs found for the given CPE.")

Or you can find the Vulnerabilties JSON directly on https://services.nvd.nist.gov/rest/json/cves/2.0?cpeName=cpe%3A2.3%3Ao%3Amicrosoft%3Awindows_10_21h2%3A10.0.19044.3930%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A%3A%2A


chore(release): v0.9.1 🎉

:robot: I have created a release *beep* *boop*
0.9.1 (2022-11-24)
Bug Fixes

types: add a generic for the logic input, for extendability (bfd78c9)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/ehmpathy/with-simple-caching/releases/tag/v0.9.1 :sunflower:


Use mailboxGUID for source and target

Hello, I was wondering if it was possible to use this script to specify a source and target mailbox using the mailbox GUID?
Scenario:
I have some users on EXO that have multiple mailbox locations (auxarchives) and this is causing us issues, so I wanted to basically merge the data from the other aux archives into the primary archive. For example, user<EMAIL_ADDRESS>has 3 mailbox locations
primary - 20gb
archive - 60gb
auxarchive - 24gb
I would like to migrate/merge all the data in the auxarchive to the primary archive (all on exo) and disable the auxarchive. The whole reason for this is because i have to prepare some of my users to be migrated to our new tenant, but since they had auto expanding at one point they are unable to be cutover and this is causing us major headache. help would be appreciated!

Sorry I missed this one.  For the record, EWS has no awareness of aux archives, and sees the whole archive as one mailbox.  Given this, it isn't possible to move items from the aux archive(s) to the primary archive.  It would be possible to move all items back to the primary mailbox (assuming there is space), after which the archives could be reset.


Use Grafana variables in trace panel when querying the Google Cloud Trace data source

As a user of the datasource when querying a specific trace I am unable to use variables.
The ability to use variables to make templates or respond to changes in the dashboard is currently not possible. I would expect a variable such as 'traceId:${traceId}' for the Filter query type or '${traceId}' for the Trace ID query type to resolve the values before querying the datasource. They are however simply passed as text string.

This is fixed in the new version of the plugin


MEV Boost - Censorship | doing small things measures up

Reference:

(This is testnet - for mainnet we offer all https://www.mevboost.org/ relays expect Relayoor for you to pick upon)
"Oh F A C" is what most currently think about the censorship problem the US government infuses into the block space.
Funny enough that doesn't necessarily need to be the case. None of it needs to be.
The Flashbot relay is the most used by far. It is the most subscribed to, and despite them leaving transactions on the table - it is still manages to be the most profitable one. Reason for that is that most block builders use the Flashbots relay for the reason, that most Stakers/MEV Boost users are subscribed to it.
There are multiple fronts how we could do our part. I want to tackle this and hope that even if we can't push the scales by small choices without doing anything drastic (like hurting INFORMED user choice). There are some reasons for users to pick OFAC, for example if they are purely US based.
We want to give Stereum users the best experiences and just removing or resort to even having to hide them would be a mistake on our part. That is not how MEV Boost works. You can, no matter where they come from or what we think personally about their government. That is why that we should push the user to either select all of them, it will resort to the most profitable one, or make other relays more appealing.
So that is where we should start, make it less appealing or likely from a UX standpoint for the user to pick it, and if we have to, move from there down the line:
less appealing > hide the option > make it a free for all under respectable relays (enable all) > remove the option to pick censoring once in the UI all together.
Here are the first small steps we should take:

[ ] make it fairly obvious who are the censoring once. Use ugly colors, like rust - #b7410e and shame them a little.
[ ] make the non censoring new and shiny looking
[ ] Add relayoooor as relay option (https://relayooor.wtf/) & push them with the other non censoring once to the top.

Other ideas & improvements, I would like to discuss:

Add the ability to add Custom relays

(Added you for later) - when you are back from vacation @maxbehzadi82 we are going to do our part from keeping the US government from fucking your home country on Ethereum
https://youtu.be/viaTT859Yk0?t=27

[ ] Here are the missing icons for the MAINNET MEV Boost relays in rc.12 - if you would be so kind and add them when you can @mabasian

Reference in Mainnet

EDEN

RELAYOOR

Suggesting them randomly on selection will be done next and with this, the issue will be closed for now.

Completed with #1066; might get opened again if necessary with rising MEV Boost censorship issues


Fallback to something like homepage/bugs when searching for the GitHub repository of a plugin

e.g. nativescript-couchdb does not have GitHub url although it has the repo url in the package.json homePage propery

AC:

Plugins like https://market.nativescript.org/plugins/nativescript-zip should have their github page extracted from homepage or bugs in package.json
If the homepage is not on github like https://market.nativescript.org/plugins/kinvey-nativescript-sdk it should not be displayed in the marketplace


docker_image should have action :load

The docker_image resource currently supports the :import action, but not the :load action.
These two are different in a subtle way: import will only import the file system itself, while load will import the complete docker image (volumes, entrypoint, cmd, expose, tags).
Or said differently: import is the counterpart to export (on a docker container), while load is the counterpart to save on a docker image.

Can you please post a link to the documentation on this? I'll take a look at implementing it.

The best documentation for this is probably in the man pages for docker-load and docker-import, respectively. A couple more links:
https://github.com/docker/docker/issues/8334
https://docs.docker.com/reference/commandline/import/
https://docs.docker.com/reference/commandline/load/
Hope that helps!

I've just submitted a PR (https://github.com/swipely/docker-api/pull/345) which provides docker load support in docker-api ruby library. I'm willing to implement it in this cookbook as soon as it gets merged

excellent. I have a PR on that repo too... should be a useful release =)

done, it was only 6 lines of code :smile: I'll wait for the docker-api's PR to get merged and then submit a PR here

Since my previous docker-api PR got #stuck (my fault), i've cleaned up and submitted another one (https://github.com/swipely/docker-api/pull/380)

Just a heads up for anyone else trying to use this: this was merged and released in docker 2.6.3 but remains broken as the docker-api dep is stuck on 1.26.2. This functionality requires docker-api >= 1.27.
Tried working around it in my wrapper cookbook but was thwarted by libraries/_autoload.rb which loads its version first when it resolves the dependency at compile time (related #682).
Tried bumping docker-api today to 1.28.0 but r-train is also pinned to 1.26.2.
Ugh!

fixed in v2.6.8
tests added for action :load in this release as well


Create a RawGenesisBlock generation web interface

We want to be able to have a web interface for configuring the genesis block.

During the experiments, the optimal ui was chosen and work with some basic data types was set up. But at the moment there are bugs with ui reactivity.