Line: Reduce boilerplate for styling Line

It's not uncommon to write code like this:
    let mut text: Vec<Line> = vec![];
    text.push(
      Line::from(vec![
        "Press ".into(),
        Span::styled("j", Style::default().fg(Color::Red)),
        " or ".into(),
        Span::styled("k", Style::default().fg(Color::Red)),
        " to ".into(),
        Span::styled("increment", Style::default().fg(Color::Blue)),
        " or ".into(),
        Span::styled("decrement", Style::default().fg(Color::Blue)),
        ".".into(),
      ]),
    );
    f.render_widget(Paragraph::new(text), rect)

With style shorthands:
    let mut text: Vec<Line> = vec![];
    text.push(
      Line::from(vec![
        "Press ".into(),
        "j".red(),
        " or ".into(),
        "k".red(),
        " to ".into(),
        "increment".blue(),
        " or ".into(),
        "decrement".blue(),
        ".".into(),
      ]),
    );
    f.render_widget(Paragraph::new(text), rect)

However, I believe this can be made simpler with a macro:
    let mut text: Vec<Line> = vec![];
    text.push(styled_line!("Press {j:Red} or {k:Red} to {increment:Blue} or {decrement:Blue}."));

Here's an example of the macro that works for the above case and just 3 colors:
macro_rules! styled_line {
  ($text:expr) => {{
    let mut elements: Vec<Span> = Vec::new();
    let regex = regex::Regex::new(r"\{([^:]+):([^}]+)\}").unwrap();
    let mut last_end = 0;

    for cap in regex.captures_iter($text) {
      let start = cap.get(0).unwrap().start();
      let key = cap.get(1).unwrap().as_str();
      let value = cap.get(2).unwrap().as_str();

      if start > last_end {
        elements.push(Span::styled(&($text[last_end..start]), Style::default()));
      }
      elements.push(Span::styled(
        key,
        match value {
          "Red" => Style::default().fg(Color::Red),
          "Blue" => Style::default().fg(Color::Blue),
          "Green" => Style::default().fg(Color::Green),
          _ => Style::default(),
        },
      ));

      last_end = cap.get(0).unwrap().end();
    }

    if last_end < $text.len() {
      elements.push(Span::styled(&($text[last_end..]), Style::default()));
    }

    Line::from(elements)
  }};
}

This issue is to discuss whether it makes sense to include such a macro into ratatui. Including this functionality increases the maintenance burden however it will decrease boilerplate for users. If it does make sense to include such a macro, what syntax should it support?

What syntax do other crates use for similar macros (crossterm, the various ANSI terminal crates etc.)
One thing I'd love to be able to do is use something like that macro in unit tests e.g.:
assert_bufffer_eq!(
  buffer,
  buffer::with_lines(vec![line!("{hello:blue} {world:green,bold}")]),
);

and for errors to be printed in the same format:
expected: vec![
  line!("{hello:blue} {world:green,bold}"
],
actual: vec![
  line!("{goodbye:orange} {mars:red,bold}"),
],
diff:
...

Here's some options:

In the style described in this comment:

line!["Fuzzy Find {darkgray:(Press} {bold:{gray:/}} {darkgray:to start} {bold:{gray:ESC}} {darkgray:to finish)}"]

the style of stilo's macro

line!("Hello": Red);

let world = "World!";
line!("Hello {}": Green + i+b, world));

In the style of tui-markup-ansi-macro:

line!(
    "Press <keyboard Space> to <action Jump> over the <enemy fox>",
    "keyboard" => "blue",
    "action" => "cyan",
    "enemy" => "bg:yellow,i",
);

line!("You got a <yellow Coin>");

In the style of ansi-colors-macro:

line!("{green Done}");

line!("{red.bold this} is red");

In the style of colored:

line!("[<green>{level}</green>] (<blue>{timestamp}</blue>): <bold>{message}</bold>");

line!("<red>all red <yellow>yellow <blue>now to blue</blue> back to yellow</yellow> back to red</red>")

In the style of stylish:

line!("Hello {:(fg=red)}", "Ferris")

In the style of ansi_brush:

line!("{} {}", "Hello,".light_cyan().bold(), "World!");
line!("Bold".bold())
line!("Faint".faint())
line!("Italic".italic())
line!("{}", "Goodbye, Mars!".bg_red().underline().italic());

In the style of vari

line!("[$blue]Hello, [$green]World![$/]")

line!("[$[114, 119, 39]]#727727![$[66, 4, 32]] Do you see it?[$/]")

line!("{}Bold and Italic :O{}", "[$bold][$italic]", "[$/]")

line!("{}Backgroundssss{}[$/]", "[bg$magenta]", "[bg$[188, 188, 188]]World![$/]")

line!("[$#ffffff]Hello, [$#000000]World![$/]")

In the style of ansiform

line!("It {;green,bold}!"), "works")

line!("Warning: {:#?;yellow}!"), "warning")

I personally think, in order for it to be intuitive, we should build off an existing syntax or convention. I also think if it supported some kind of nested syntax, that'll be the most flexible, since that most closely maps to how the terminal ansi codes work. We should also consider implementation complexity, features that users will like to use and expect to work.
Implementation complexity aside, I personally would like a line! macro that works almost exactly like the Rust's built-in format string macro. That is what I believe would be most intuitive for users too.

Implementation complexity aside, I personally would like a line! macro that works almost exactly like the Rust's built-in format string macro. That is what I believe would be most intuitive for users too.

Same. I think our issue getting to point is that we always want Line to be a vec of Spans, and we want inline styling as well as easy variable interpolation. So something like the following might be cool:
let greeting = "Hello".red(); // a span
let name = "josh" // a str
// all should be equivalent => Line::from(vec!["Hello".red(), " ".into(), "josh".bold()])
line!("{greeting} {name:bold}");
line!("{} {:bold}", greeting, name);
line!("{foo} {bar:bold}", foo = hello, bar= name);

I think perhaps stylish, ansi_brush and ansiform are close
I'm not a fan of angle brackets styles (mostly they seem out of place)

One thing I'd love to be able to do is use something like that macro in unit tests e.g.:

This inspired the following https://github.com/ratatui-org/ratatui/pull/494
use crate::style::Stylize;
let mut buf = Buffer::empty(Rect::new(0, 0, 10, 10));
buf.set_string(0, 0, "foo", Style::new().red());
buf.set_string(0, 1, "bar", Style::new().blue());
assert_eq!(buf, Buffer::with_lines(vec!["foo".red(), "bar".blue()]));

Now we'd just need the Debug format to change to something that just sees the lines as lines like this... and we can ditch assert_buffer_eq! and just use assert_eq! (alternatively: assert_widget!(Paragraph::new("foo").red(), vec!["foo".red()]); might be neat too.

I think perhaps stylish, ansi_brush and ansiform are close

ansi_brush is the closest to our existing Stylize trait too.

Hmm, i wonder if i could make a cline macro in comat, that expanded to use Style.
I wasnt aware so many format string to ansi macro crates, existed, but i think it would be fun to add support for that.
What do you think of the syntax of that crate?

ANSI crates are definitely oversaturated in rust - there's one for every style of doing color / styling :)
https://crates.io/search?q=ansi&sort=downloads it's worth checking a bunch and seeing if they come close to your idea.
One crate I'd consider looking at for some inspiration (for this issue) is https://crates.io/crates/nu-ansi-term / ansi-term mainly for the way that it composes things into an AnsiString rather than just slapping the escapes into the string - see https://docs.rs/nu-ansi-term/0.49.0/nu_ansi_term/#combining-successive-colored-strings

For what it's worth - we're porting Ratatui to PHP and recently added support for Span::parse('<fg=green bg=red options=bold,italic>some</> thing') link which is based on the Symfony framework's markup.

I just saw the tui_markup crate, and think it mostly implements this (though for tui-rs). Submitted a Ratatui PR: https://github.com/7sDream/tui-markup/pull/1

@joshka This is the syntax we want?
I wonder, though, if its possible to make a runtime function to convert ansi to a Line, so that I can use the syntax I like.

@joshka This is the syntax we want?

No, tui_markup isn't my preferred syntax. I mentioned it in case anyone was looking for an already working approach to this problem.
My preference is for something like https://github.com/ratatui-org/ratatui/issues/493#issuecomment-1714903746
I want a syntax that:

Looks similar to existing format! usages (which probably means that "{some_var:bold}" should work
allows formatting both string literals and variables in the same syntax (this is difficult to combine with 1.
(low priority) allows nesting formats maybe
(mid priority) allows applying custom styles e.g. "{error_message:warning}" (where warning = Style::new().white().on_red() or similar
Feels like idiomatic obvious rust (this is a really subjective one)

Hello,  I'm the author of tui-markup. Very happy to hear that finally ratatui will have a quick way to generate styles text. I had previously planned to contribute this functionality to tui-rs, but due to inactive/transfer of the original project, as well as my own shift in focus, this did not happen.
I create tui-markup mainly to solve an issue I met when building a terminal game. I want the help page to be colorful but easy to change text and style in development stage. You can preview the result(In connex-tui section) generated from the source plain text file.
I believe that unless it's purely for testing, defining a style and reusing it is more common than setting different styles each time. This is like CSS classes, where you can define the classes first and then use code to set their styles at "compile" time. So, I designed the custom tag, which is the custom style that joshka mentioned above. When I was writing tui-markup, there should have been no other similar libraries supporting this feature. I mention this to emphasize its importance, I personlly think this feature is high priority.
If only custom style is supported, the syntax of tui-markup would be <{style}>{content}</{style}>. However, temporary styles are also very useful. If the syntax mentioned above is used, the close tag for temporary styles is hard to write, <green,b,i>Hello</???>, repeating the style list seems unnecessary. So, I finally chose the syntax without a close tag, where the content is written directly after style, <{style} {content}>.
Now, I'm not very satisfied with this syntax. I think the format! syntax is indeed good. But it still needs to consider whether it supports the temporary style of setting multiple styles at the same time, such as {a:green,bold,italic}. Or we need nest like {{{a:green}:bold}:italic}? tui-markup supports multi style and nesting, as <green,b,i a> and <green <b <i a>>> both works.

Thanks for providing this context @7sDream. To be clear above, my preference to avoid the specific syntax you've used is not a criticism of your work. In fact it's the opposite. I can see how you got to something excellent and I want to improve on that for something that's built-in to Ratatui. I would recommend your crate as a great option until then though. :)

Yes, I'd love to see ratatui support this feature directly. I don't take your comments as criticism, I comment here to participate in the community discussion and provide some information and  my opinions, not to defend my earlier work 😃

I'm experimenting with writing a proc macro for this (and will probably live in a separate crate for now to see if people find it useful).
Here's some initial options for syntax that I'm considering:
Option 1:
String literal syntax:
  style_line!("Press {j:red} or {k:red} to {increment:blue} or {decrement:blue}");

For variables, we could get something like this to work:
  style_line!("Press {j:red;bold} or {} to {increment:blue} or {decrement:blue}", "k".red().bold());

Another example:
  let i = "increment";
  let d = "decrement";
  let c = Color::Blue;
  style_line!("Press {j:red;bold} or {} to {} or {}", "k".red().bold(), i.fg(c), d.fg(c));

Option 2:
Raw token syntax:
  style_line!([ Press {"j".red()} or {"k".red()} to {"increment".blue()} or {"decrement".blue()} ]);

This syntax will always interpolates anything inside {...}, and it has to be a valid Span.
  style_line!([ Press {"j".red().bold()} or {"k".red().bold()} to {"increment".blue()} or {"decrement".blue()} ]);

Another example:
  let i = "increment";
  let d = "decrement";
  let c = Color::Blue;
  style_line!([ Press {"j".red().bold()} or {"k".red().bold()} to {i.fg(c)} or {d.fg(c)} ]);

I think the first option feels like more idiomatic Rust, so that's what I'm leaning toward implementing.
I'm also leaning toward not allowing nesting.
And I'm planning to use \{ and \} to escape the curlies.
Let me know if you have feedback or other ideas.

I'm experimenting with writing a proc macro for this (and will probably live in a separate crate for now to see if people find it useful).

+1 to making this outside and then bringing it inside once battle tested. Why a proc macro though?

Option 1:
String literal syntax:
  style_line!("Press {j:red} or {k:red} to {increment:blue} or {decrement:blue}");

The issue with this syntax is that I'd expect that to render a variables named j as red, k as red, increment as blue, not the text j, k, increment, decrement.

For variables, we could get something like this to work:
  style_line!("Press {j:red;bold} or {} to {increment:blue} or {decrement:blue}", "k".red().bold());

Another example:
  let i = "increment";
  let d = "decrement";
  let c = Color::Blue;
  style_line!("Press {j:red;bold} or {} to {} or {}", "k".red().bold(), i.fg(c), d.fg(c));

I think this syntax has a problem that it takes away existing format syntax (named variables). This makes it unique (in the bad sense).

Option 2:
Raw token syntax:
  style_line!([ Press {"j".red()} or {"k".red()} to {"increment".blue()} or {"decrement".blue()} ]);

This syntax will always interpolates anything inside {...}, and it has to be a valid Span.
  style_line!([ Press {"j".red().bold()} or {"k".red().bold()} to {"increment".blue()} or {"decrement".blue()} ]);

Another example:
  let i = "increment";
  let d = "decrement";
  let c = Color::Blue;
  style_line!([ Press {"j".red().bold()} or {"k".red().bold()} to {i.fg(c)} or {d.fg(c)} ]);

I think the first option feels like more idiomatic Rust, so that's what I'm leaning toward implementing. I'm also leaning toward not allowing nesting. And I'm planning to use \{ and \} to escape the curlies.

yeah, that {"j"....} seems odd from a rust perspective. The first option does seem more rust-like (though with the problems noted)
Nesting. This seems like an important thing to have
Escapes. Consider {{ instead. https://doc.rust-lang.org/std/fmt/index.html

Let me know if you have feedback or other ideas.

I think perhaps it might be worth considering keeping the variable interpolation syntax from format! as is, but adding some extra surrounds. Some brainstorming some ideas:
// "Hello joshka. Welcome to Ratatui!. Counter: 0001"
// unstyled
format!("Hello {name}. Welcome to Ratatui!. Counter: {:04}", state.counter);
// 1
styled!("Hello {name:**bold}. Welcome to **red,italic(Ratatui!)**. Counter: {:04**on_blue}", state.counter);
// 2
styled!("Hello {name:**bold}. Welcome to **red,italic**Ratatui!**. Counter: {:04**on_blue}", state.counter);
// 3
styled!("Hello {name:@bold}. Welcome to @red,italic<EMAIL_ADDRESS>Counter: {:04@on_blue}", state.counter);
// 4 (I like this one)
styled!("Hello {name:_bold}. Welcome to __Ratatui!__red_italic__. Counter: {:04_on_blue}", state.counter);
// 5
styled!("Hello {name:!!bold}. Welcome to !!Ratatui!!red,italic!!. Counter: {:04!!on_blue!}", state.counter);
// 6 need some way to provide variable style, so extending the $ syntax from format!:
let style = Style::new().red().italic()
styled!(
    "Hello {name:_$}. Welcome to __Ratatui!__style$__. Counter: {:04_counter_style$}",
    Style::new().bold(),
    state.counter,
    counter_style = Style::new().on_blue());
// 7 the problem with __ is that it doesn't open and close, so can't nest, but I like that the _ makes it easy to spot the styling
styled!("Hello {name:_[bold]_}. Welcome to _[Ratatui!:red,italic]_. Counter: {:04_[on_blue]_}", state.counter);
// 8 kebab styling
styled!("Hello {name:-[bold]-}. Welcome to -[Ratatui!:red,italic]-. Counter: {:04-[on_blue]-}", state.counter);
// 8 + style - might be ambiguous with https://doc.rust-lang.org/std/fmt/index.html#sign0
styled!("Hello {name:+[bold]}. Welcome to +[Ratatui!:red,italic]. Counter: {:04+[on_blue]}", state.counter);
// 9
styled!("Hello {name:&[bold]}. Welcome to &[Ratatui!:red,italic]. Counter: {:04&[on_blue]}", state.counter);
// 10 I dislike angle brackets, but... (might be ambiguous with https://doc.rust-lang.org/std/fmt/index.html#fillalignment)
styled!("Hello {name:<bold>}. Welcome to <Ratatui!:red,italic>. Counter: {:04<on_blue>}", state.counter);
// 11 I dislike angle brackets, so let's double them 😢
styled!("Hello {name:<<bold>>}. Welcome to <<Ratatui!:red,italic>>. Counter: {:04<<on_blue>>}", state.counter);
// 11 =
styled!("Hello {name:=bold}. Welcome to ==Ratatui!==red,italic==. Counter: {:04=on_blue}", state.counter);
// 12
styled!("Hello {name:=[bold]}. Welcome to =[Ratatui!=red,italic]=. Counter: {:04=[on_blue]}", state.counter);

So, thinking these through, some constraints come to mind:

It would be nice to surround the items with open and close to make it clear where the styling starts and ends. This avoids confusion. "Some red_red_and_bold_bold_text"
I think we should prefer to avoid breaking existing variable syntax, so avoiding the built-in characters in https://doc.rust-lang.org/std/fmt/index.html would be good
I like the characters used to be visible so you can easily see the styled parts (which precludes some characters)
I like there to be similarity in the variable interpolation and static text
It's worth considering style interpolation (i.e. the style$ approach)

Why a proc macro though?

I'm using a proc macro approach for now since I can control nuances in the syntax more easily. I know I can handle any syntax with a proc macro with minimal changes so it is faster for prototyping, counter intuitively. Prototyping even small changes in a declarative macro can mean rewriting the macro to get it to work. Also format_args! is a compiler built-in, and other implementations of format_args! use a proc macro, so I figured I'd start there to be on the safe side.
I think once we figure out the exact syntax we want I can look into implementing it with a declarative macro since that will be the lowest maintenance cost and make it more likely for inclusion in this project.

(low priority) allows nesting formats maybe
Nesting. This seems like an important thing to have

Can you clarify if you think nesting is important? In a previous comment you mention it is low priority. I think nesting is not really required because people can either unroll the nested styles while writing it or build it with the current manner. The macro is for creating a Line quickly and I was not expecting it to cover every use case. My goal was to make something that covers most common cases and optimizes for those.

I think perhaps it might be worth considering keeping the variable interpolation syntax from format! as is, but adding some extra surrounds.

Allowing variables in the curlies that can also be styled makes the implementation more complex and also makes it harder to understand for users (imo).
For example, should both of these work?
let name = "Ratatui";
let line = styled!("{name:bold}: One of the TUIs of all time");

let name = "Ratatui".bold();
let line = styled!("{name:italic}: One of the TUIs of all time");

I'm also of the opinion that we don't need styled! to have the same semantics as format!. We don't need to support everything that format! does. We just want something to make it easier to create a Line object.

I'm using a proc macro approach for now

makes sense

Can you clarify if you think nesting is important?

I was thinking about it mostly for places like status bars / header bars where you might have things where a background changes, and then within that background there is a highlighted keyboard shortcut and then the rest of the word.
"_[ _[Q:red]_uit :black,on_white]"

For example, should both of these work?

I hadn't thought about that specifically, but It sure would be neat if it did :)

Allowing variables in the curlies that can also be styled

No more than making curlies take on two tasks really.
One thing I didn't think of was that we could leave the curly syntax alone and use square brackets or some other delimiter for style
// 13
styled!("Hello [{name}:bold]. Welcome to [Ratatui!:red,italic]. Counter: [{:04}:on_blue]", state.counter);
// 14
styled!("Hello [_{name}_bold_]. Welcome to [_Ratatui!_red,italic_]. Counter: [_{:04}_on_blue_]", state.counter);
// 15
styled!("Hello <{name}:bold]> Welcome to <Ratatui!:red,italic>. Counter: <{:04}:on_blue>", state.counter);

One thing I didn't think of was that we could leave the curly syntax alone and use square brackets or some other delimiter for style

I like this idea a lot.
For now, ignore the delimiter choice (we can switch it out for anything in the future), I'm going to paste some examples here for discussion using angle brackets.
If we did want to support nesting (not a priority but would be nice to leave room in the syntax to support it in the future), this is what it might look like:
styled!("<Hello <{name}:bold> Welcome to <Ratatui!:red,italic>:on_yellow>. Counter: <{:04}:on_blue>", state.counter);

Seeing this example makes we want to put the style before, like in the style of tui_markup_ansi_macro:
styled!("<on_yellow Hello <b {name}> Welcome to <red,i Ratatui!>>. Counter: <on_blue {:04}>", state.counter);

tui_markup_ansi_macro supports custom styles with the following syntax:
use tui_markup_ansi_macro::ansi;

let generated = ansi!("Press <blue Space> to <cyan Jump> over the <bg:yellow,i fox>");
let hardcode = "Press \u{001b}[34mSpace\u{001b}[0m to \u{001b}[36mJump\u{001b}[0m over the \u{001b}[3;43mfox\u{001b}[0m";
// Those two are equivalent.
assert_eq!(generated, hardcode);

// Use custom tag
let generated = ansi!(
    "Press <keyboard Space> to <action Jump> over the <enemy fox>",
    "keyboard" => "blue",
    "action" => "cyan",
    "enemy" => "bg:yellow,i",
);
assert_eq!(generated, hardcode);

println!("{}", generated);

Not sure about this feature since it overlaps in syntax with the second arguments like `state.counter.
I think we'd also want hex RGB colors to be supported:
styled!("<on_#f0f0f0 Hello <b {name}> Welcome to <red,i Ratatui!>>. Counter: <on_blue {:04}>", state.counter);

After re-thinking and re-reading the tui-markup syntax, I think I'm actually sold on it. There's a couple of small things I'd change, but basically without intending to I accidentally came to pretty much the same format. :D

I think escaping would work better by doubling the angle brackets.
I'm not sure about s being the shortcut for strike-through
RGB is supported, but I'd prefer to require the # prefix rather than bare
Do we want to perhaps shortcut <blue:white blue on white text>?
The custom tags format could be similar to the usual format variables approach. Could this allow you to pass either Spans or text? E.g.:styled!(
    "<title Ratatui> is the <silly GOATUIs>. Good {}, {name}",
    "morning", name = self.name, title = "red", silly = CUSTOM_THEME.silly
);

We could also though just use {title} for injecting custom tags like this (easy to do with text, more difficult to do with a Style)styled!(
    "<{title} Ratatui> is the <{silly} GOATUIs>. Good {}, {name}",
    "morning", name = self.name, title = "red", silly = CUSTOM_THEME.silly
);

I think escaping would work better by doubling the angle brackets.

I might defer this choice to implementation complexity and number of corner cases in both implementations.
I can see people wanting to style something like this:
"This is the >>greatest<< thing in the world"

Which one of these is more intuitive:
styled!("This is the \>\>greatest\<\< thing in the world")
// OR
styled!("This is the >>>>greatest<<<< thing in the world")

Do we want to perhaps shortcut <blue:white blue on white text>?

I like it. We could also write this then <:white just on white text>.

A bare > doubled or not shouldn't have any effect without a prior opening < so the example should just work as is.
Just like `format!("}}foo{{") does.

Right now as I'm just writing frame.render_widget(Line::from(format!(...)), area), this leads me to really want this as line!() instead of styled() - mainly because it's important to note the output type for this - is it Span, Line or Title.
let [display_name, ...] = frame.size().split(&layout);
frame.render_widget(line!("Display Name: {}", self.display_name", display_name)

There's unfortunately already a rust macro called line! that seems to be exported by default: https://doc.rust-lang.org/std/macro.line.html

There's unfortunately already a rust macro called line!

That's super interesting btw

You can import-over macros though? nothing stops macro_rules! line from happening.

Weird! I thought I tried making it line! and got a linter error. But I just tried it as a macro_rules! and it works with use ratatui_macros::line and use ratatui_macros::*.
I would prefer naming it line!, span! and style! (or even s! since it is more common) for respective functionality.

or even s! since it is more common

plz avd abbrvtns kthxbi ;)
More thoroughly, abbreviations like this often seem cool and convenient, but they add to the cognitive load of someone reading the code without context.

After experimenting some with proc macros, I found some tradeoffs in implementation for the line! macro.
Take the following suggested syntax from earlier:
let name = "John";
let project = "Ratatui";
line!("<on_#f0f0f0 Hello <b {name}> Welcome to <red,i {}!>>", project);

There's two ways we can implement parsing the following with a proc macro

We can parse it at compile time.

This requires keeping track of all the arguments and splicing it into the appropriate string that is constructed for the respective Span. The implementation for this got hairy very quickly although I believe it could be done with some effort. However, maintaining a proc macro of that complexity doesn't seem appealing to me.

We can interpolate the format! string arguments and parse the string at run time.

This is far more easier to implement and I had a mostly working implementation, however, the way this worked was walking through the string character by character at runtime to build new String objects that were then cobbled together to form a Line object. Here's the equivalent code that the macro would expand out into:
// this
line!("<on_#f0f0f0 Hello <b {name}> Welcome to <red,i {}!>>", project);
// expands to this
parse_into_line("<on_#f0f0f0 Hello <b John> Welcome to <red,i Ratatui!>>".to_string());

I didn't like this approach as well because of the runtime tradeoffs.

While working on this, I came to the realization that the semantics of Line is much closer to Vec, and a line! macro closer to a vec! macro might be a good fit. I implemented a proof of concept in https://github.com/ratatui-org/ratatui-macros/pull/29/
I personally like this a lot more. We lose the string formatting functionality that we were discussing in this PR but there are now additional macros that can help with that.
With this new macro, you'd write the equivalent code to the above like so:
let name = "John";
let project = "Ratatui";
line![
    "Hello ",
     name.bold(),
    "Welcome to ",
    raw!("{}!", project).red().italics()
].bg(
    Color::from_str("#f0f0f0")
);

Granted it is much more verbose but it is easy to understand, easy to explain and probably most importantly easy to maintain.
Another example from the first post:
line![
  "Press ", "j".red(), " or ", "k".red(), " to ", "increment".blue(), " or ", "decrement".blue(), ".",
]

I think a styled_line! macro can still be added in the future using proc macro features.
Thoughts?

LGTM, I have a vague recollection of thinking something similar at some point in the past.
Perhaps:
line![
    "Hello".blue(),
    span!("{name}").green(),
    span!("{}/{}/{}", day, month, year).red(),
];

// maybe let a style be appended after a semi-colon?
span!("{name}"; theme.name_style);

// do we want to shortcut line with format string interpolation perhaps?
line!("Hello {name}"; style)

Perhaps there's two+ ways to do style with the macros like this:

delimited (i.e. semicolon)
first parameter type check == style / Into

I think line! would be pretty useful even without format! ing included

line![
    "Hello".blue(),
    span!("{name}").green(),
    span!("{}/{}/{}", day, month, year).red(),
];

Right now this already works (thanks to the macros you wrote):
line![
    "Hello".blue(),
    raw!("{name}").green(),
    raw!("{}/{}/{}", day, month, year).red(),
];

// maybe let a style be appended after a semi-colon?
span!("{name}"; theme.name_style);

This also works at the moment with the styled! macro:
styled!(theme.name_style, "{name}")

It's not possible to do it the other way around because of the way declarative macros work. This was the reason I wanted to leave the styled! macros in a separate crate. But I think I've come around to this syntax.

// do we want to shortcut line with format string interpolation perhaps?
line!("Hello {name}"; style)

I don't want to do this for a few reasons.

line![raw!("Hello {name}")].style(style) is still easy to read and write
the ; is used for vec![expr; n] like behavior at the moment, i.e. line!["Hello"; 2] does the equivalent of Line::from(vec!["Hello".into(), "Hello".into()])
Supporting formatting in the line! macro makes it not convenient to have multiple spans in a line!. It would also have to be implemented with a proc macro which gets into the issues above.

Right now this already works (thanks to the macros you wrote):

I think I forgot I did that...

I don't want to do this for a few reasons.

Makes sense

This also works at the moment with the styled! macro:

Would it be possible to collapse this into a single span! macro that handles both raw and styled? I think that would be a nicer ergonomic fit (as line => Line, span => Span and because Line and Text both have raw and styled methods, so reading it without previous knowledge of the macros doesn't lend itself to obvious assumptions)

Without some sort of extra thing to make it obvious that the style is not the first string argument, it doesn't seem to be compatible with the ($($arg:tt)*) branch of the macro, but adding a single character prefix (or suffix probably) works:
#[macro_export]
macro_rules! span {
    (@$style:expr, $($arg:tt)*) => { ratatui::text::Span::styled(format!($($arg)*), $style) };
    ($($arg:tt)*) => { ratatui::text::Span::raw(format!($($arg)*)) };
}

let span = span!(@Color::Green, "test {content}");
assert_eq!(span, Span::styled("test content", STYLE));

let span = span!(@Modifier::BOLD, "test {content}");
assert_eq!(span, Span::styled("test content", Style::new().bold()));

Or maybe:
#[macro_export]
macro_rules! span {
    ($style:expr => $($arg:tt)*) => { ratatui::text::Span::styled(format!($($arg)*), $style) };
    ($($arg:tt)*) => { ratatui::text::Span::raw(format!($($arg)*)) };
}

let span = span!("test {content}");
assert_eq!(span, Span::raw("test content"));

let span = span!(Color::Green =>"test {content}");
assert_eq!(span, Span::styled("test content", Style::new().green()));

let span = span!(Modifier::BOLD => "test {content}");
assert_eq!(span, Span::styled("test content", Style::new().bold()));

let span = span!(@Modifier::BOLD, "test {content}");

It is shorter to type this:
let span = span!("test {content}").bold();

In practice, even if we supported the first argument as a style syntax, I'd probably use the post fix function because I'm typing the context of what I want and then .<TAB> to figure out what the styling should be.
My first thought when I was doing this was to suggest removing styled! and renaming raw! to span!.
w.r.t to whether we even need raw! since format! does the same thing, I think there's still a benefit to having raw! because if you use format! you have to use .into() in some contexts.
let spans = vec![
    format!("hello {}", "world").into(),
    span!("hello {}", "world")
]

To be a bit more clear, this is future looking and thinking about how to pass common / theme styles - less about specific inline styles
e.g. what is currently:
let line = Line::from(vec![
  Span::styled("foo:", LABEL_STYLE),
  Span::raw(" "),
  Span::styled(format!("{value:?}"), VALUE_STYLE),
]);

span!("{value:?}").style(VALUE_STYLE) is still a bit long for taste, so I'm searching for something neat that hides away all the extra syntax like:
let line = line![
  span!(LABEL_STYLE => "foo"),
  span!(" "),
  span!(VALUE_STYLE => "{value:?}")),
]

Lots of possible ways  to delimit the style info , but maybe the answer is just raw (or span) and styled?
let line = line![
  span!(LABEL_STYLE, "foo"),
  raw!(" ")
  span!(VALUE_STYLE, "{value:?}")),
]

Should we have more than one macro to create a Span?

I'm ok with 1 or 2 for this

What is the name of the macro(s) to create a single Span?

I think it's reasonable to want a macro that is named span!, as if I saw a line! macro, I'd intuitively want to reach for a span! macro. (Principal of least surprise)
I think the more common / useful use should be span!, the secondary use should be named something different if we go with two macros. Because there are 2+ ways to do raw spans that are succinct (" ", format!("{}"...)) , purposing span! as the styled variation makes the most sense to me rather than the opposite you're proposing. This also aligns with your thinking that "Span is a String + Style".

What is the syntax we'd like to support for the macro(s)?

With 2 macros:

span!(style, "Hello {}", name)
raw_span!("Hello") (I'd settle for just raw)

I'd like to keep complexity of the implementation low unless the value added with a more complex implementation is significantly high

All of the above examples were real implementations, with very little complexity (1-2 LoC). A proc macro is not necessary.
If we want just a single span macro, then there are two questions:

should the style be before or after the content?
What delimiter to use between things (, won't work when we go to a single macro as the macro syntax can't distinguish the args from the style without some extra punctuation.

For a single macro, we can use any of the following options. All these are simple and working that are 2-4 lines of macro code:

use a delimiter between the style expression and the other args (valid are =>, , or ; but , can't work)

span!(style; "Hello {}", name) or
span!(style => "Hello {}", name)

use a prefix character from !@#%^&*=<> etc. before the style or parens surrounding it

span!(#style, "test {name}")
span!(=style, "test {name}")
span!(%style, "test {name}")
span!((style); "test {name}")

Of these options, I think really only using 2 macros (span, raw), or a single macro where the style is specified asspan!(style; "Hello {}", name) really seems to feel intuitive / simple to me.

a single macro where the style is specified as span!(style; "Hello {}", name) really seems to feel intuitive / simple to me.

This seems good to me!


docs: add netlify open source plan requirements to documentation

Satisfy the requirements in the Netlify Open Source Plan Policy: https://www.netlify.com/legal/open-source-policy/

Adds a link to our code of conduct in the Readme and Documentation Site
Adds a Netlify badge to the doc site footer

Coverage remained the same at 88.578% when pulling b6807919a54bd986b200b477b51c5d198ce92386 on abutterworth/netlify-open-source-requirements into 1ebf9e48140bed85dc6c5c8773670e4a4d08ddd8 on master.

:tada: This PR is included in version 11.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Allow multiple parameters to be sent from STP to _sp API

Currently there is no way to pass multiple parameters to the _sp API from the STP process (though the _sp API does support this).
There is a case where a number of fields need to be pre-calculated to provide the correct params to _sp to execute efficiently

Merged a fix for Retry.scala to accept multiple http parameters

_sp could always accept multiple parameters. However Retry.scala could not work with HTTP request parameters (the current sp.pid and sp.path were handled from a lambda function passed in)
A merge has already been made to allow Retry.scala to handle HTTP GET request parameters. The next change was to STP. This is to allow sparqlToRoot to bind more than one variable. At present it is assumed you are working with an orgId which will subsequently become the path of the main query.
This change allows us to bind multiple values from the sparqlToRoot query into a set of named key value pairs. This allows us to effectively pre-query STP so we can work with targeted result sets.
The attached yaml/sparql is a configuration which will allow us to test. Note the new currencyID variable bound in the sparqlToRoot and later used in the main SPARQL file in the path.
Note - if sparqlToRoot binds one variable logic works as it does presently. More than one and the above logic will work.

multivars.yaml.txt
multivar.sparql.txt


[Feature]: 1.19 Compatibility

Feature Details
Compatibility for 1.19+; AllTheOres and AllTheModium are already in 1.19.
Compressium has attempted to add custom compressed blocks via .json, but it isn't implemented yet.

AllTheCompressed has been released for 1.19.2.


Please add Boost license text

The file cxxheaderonly/progress_display.hpp is under the Boost license (SPDX BSL-1.0):
https://github.com/cr-marcstevens/snippets/blob/e01ae885cdbef3af265341110a434f6fa7b8e8ac/cxxheaderonly/progress_display.hpp#L1-L4
The text of the referenced license is reproduced below:
Boost Software License - Version 1.0 - August 17th, 2003

Permission is hereby granted, free of charge, to any person or organization
obtaining a copy of the software and accompanying documentation covered by
this license (the "Software") to use, reproduce, display, distribute,
execute, and transmit the Software, and to prepare derivative works of the
Software, and to permit third-parties to whom the Software is furnished to
do so, all subject to the following:

The copyright notices in the Software and this entire statement, including
the above license grant, this restriction and the following disclaimer,
must be included in all copies of the Software, in whole or in part, and
all derivative works of the Software, unless such copies or derivative
works are solely in the form of machine-executable object code generated by
a source language processor.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.

Since the Boost license requires that not only the copyright notices, but also the entire license text, must be included in copies and derivative works, please add a file containing the Boost license text to this repository.
For further context: https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text

Hi Ben,
Thanks for the issue!
This file indeed seems to be the exception and has Boost license in contrast to the MIT license the rest of the files have.
I want to fix this by including the Boost license text in this header file instead of a seperate file.
I did not expect a linux distribution to take interest in these files, are these included somewhere in a package?

The thread_pool.hpp library is vendored in fplll, which is packaged in Fedora Linux as libfplll. I was looking at packaging the snippets separately to unbundle them from libfplll. I don’t know of any other Fedora packages that would use them at the moment.


Index Toolpad docs in the Algolia search

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Summary 💡
Search bar is essential for our users to navigate well between MUI products.
Initially there is no need to show Toolpad docs in the search results. This is a task for future.
Stemmed from: https://github.com/mui/mui-toolpad/issues/1124
Approach:

Similar to how X docs isolate their search from core, we will provide a search for Toolpad-only
Ask Jun for a getting started

I think that the important next step will be to monitor all the no results searches and fix them; one by one.

Currently been investigating searches with no result. It is not possible to filter them by the "product" attribute, which makes it quite cumbersome to get toolpad specific data out of Algolia. Will have to investigate whether Algolia analytics unlocks this for us.

Closing this as we can now filter Algolia search analytics by product.


Feature request: Add in support for smile.amazon.com links

Hello r7kamura,
Would you kindly consider extending this functionality to also support smile.amazon.com url link shortening, please.
EG: Taking links like this one (https://smile.amazon.com/10TB-Elements-Desktop-Drive-WDBWLG0100HBK-NESN/dp/B07G3QMPB5/?th=1) and shortening it down to this (https://smile.amazon.com/dp/B07G3QMPB5/), would be fantastic.
Thank you in advance for creating this Chrome extension and for listening to my suggestion.

Thank you for creating the Issue.
I've made the changes to support smile.amazon.com at #18 and submitted a new version to the Chrome Web Store so you can try it out when it is released 👍

The new version is released at chrome web store 🎉
https://chrome.google.com/webstore/detail/amazon-url-shortener/bonkcfmjkpdnieejahndognlbogaikdg
I'll close this issue, but if you have any problem about smile.amazon.com yet, please reopen it 👋

Came back to say new version (1.3.0) is working great!  Thank you for the quick update to a fine extension.


helm install hangs with 'Error: no available release name found'

Hi all,
I am trying to use Helm with my Kubernetes cluster but when I attempt to install packages it just hangs and gives me the error 'no available release name found'. Any ideas would be appreciated. I assume this is most likely an RBAC issue or connectivity problem, I am running helm and kubectl out-side of my cluster, so it could be a blocked port.
Output of helm version:
calvinh@calvinh-MacBookPro:~$ helm version
Client: &version.Version{SemVer:"v2.9.0-rc2", GitCommit:"08db2d0181f4ce394513c32ba1aee7ffc6bc3326", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.0-rc2", GitCommit:"08db2d0181f4ce394513c32ba1aee7ffc6bc3326", GitTreeState:"clean"}

Output of kubectl version:
calvinh@calvinh-MacBookPro:~$ kubectl version
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.6", GitCommit:"9f8ebd171479bec0ada837d7ee641dec2f8c6dd1", GitTreeState:"clean", BuildDate:"2018-03-21T15:21:50Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.6", GitCommit:"9f8ebd171479bec0ada837d7ee641dec2f8c6dd1", GitTreeState:"clean", BuildDate:"2018-03-21T15:13:31Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.): Canonical Kubernetes v1.9.3
Output from logs within tiller container:
[main] 2018/04/05 23:12:42 Storage driver is ConfigMap
[main] 2018/04/05 23:12:42 Max history per release is 0
[tiller] 2018/04/05 23:23:11 preparing install for
[storage] 2018/04/05 23:23:11 getting release "loping-echidna.v1"
[storage/driver] 2018/04/05 23:23:41 get: failed to get "loping-echidna.v1": Get http://localhost:8080/api/v1/namespaces/default/configmaps/loping-echidna.v1: dial tcp: i/o timeout
[tiller] 2018/04/05 23:23:41 info: generated name loping-echidna is taken. Searching again.
[storage] 2018/04/05 23:23:41 getting release "nonplussed-antelope.v1"
[storage/driver] 2018/04/05 23:24:11 get: failed to get "nonplussed-antelope.v1": Get http://localhost:8080/api/v1/namespaces/default/configmaps/nonplussed-antelope.v1: dial tcp: i/o timeout
[tiller] 2018/04/05 23:24:11 info: generated name nonplussed-antelope is taken. Searching again.
[storage] 2018/04/05 23:24:11 getting release "opinionated-sloth.v1"
[storage/driver] 2018/04/05 23:24:41 get: failed to get "opinionated-sloth.v1": Get http://localhost:8080/api/v1/namespaces/default/configmaps/opinionated-sloth.v1: dial tcp: i/o timeout
[tiller] 2018/04/05 23:24:41 info: generated name opinionated-sloth is taken. Searching again.
[storage] 2018/04/05 23:24:41 getting release "harping-wolverine.v1"
[storage/driver] 2018/04/05 23:25:11 get: failed to get "harping-wolverine.v1": Get http://localhost:8080/api/v1/namespaces/default/configmaps/harping-wolverine.v1: dial tcp: i/o timeout
[tiller] 2018/04/05 23:25:11 info: generated name harping-wolverine is taken. Searching again.
[storage] 2018/04/05 23:25:11 getting release "ornery-meerkat.v1"
[storage/driver] 2018/04/05 23:25:41 get: failed to get "ornery-meerkat.v1": Get http://localhost:8080/api/v1/namespaces/default/configmaps/ornery-meerkat.v1: dial tcp: i/o timeout
[tiller] 2018/04/05 23:25:41 info: generated name ornery-meerkat is taken. Searching again.
[tiller] 2018/04/05 23:25:41 warning: No available reease names found after 5 tries
[tiller] 2018/04/05 23:25:41 failed install prepare step: no available release name found

Hey! Yes this is most likely an RBAC issue. Have you taken a look at the documentation to set up Tiller with RBAC? https://docs.helm.sh/using_helm/#role-based-access-control goes into detail about this. :)

Closing as a duplicate of #3055.

@bacongobbler FYI I managed to resolve it by installing a previous version, which lead me to believe this is an actual bug with 2.9.0r2 and k8s 1.9.3. We're now shipping k8s 1.10 at Canonical so I'll try that and report back, but something weird was going on between the versions.


lfs remote can't be renamed the "normal" way

Pardon the <snip> censorship, this is from a private repo:
[15:15:21] ✔ jroelofs@galois build$ git remote rename origin github
[15:15:29] ✘ jroelofs@galois build$ git checkout <snip>
Downloading <snip> (28.13 MB)
Error accessing media: <snip> (274e002077deb9794db0d44e21a24f19c5e299feec24cb2c0b88b656e215c180)

Errors logged to .git/lfs/objects/logs/20160218T151550.808785338.log
Use `git lfs logs last` to view the log.
error: external filter git-lfs smudge %f failed 2
error: external filter git-lfs smudge %f failed
fatal: <snip>: smudge filter lfs failed
[15:15:50] ✘ jroelofs@galois build$ git lfs logs last
git-lfs/1.1.0 (GitHub; darwin amd64; go 1.5.1; git 258acf1)
git version 2.5.4 (Apple Git-61)

$ git-lfs smudge <snip>
Error accessing media: <snip> (274e002077deb9794db0d44e21a24f19c5e299feec24cb2c0b88b656e215c180)

Post objects/batch: unsupported protocol scheme ""
goroutine 1 [running]:
github.com/github/git-lfs/lfs.Stack(0x0, 0x0, 0x0)
	/Users/rick/go/src/github.com/github/git-lfs/lfs/errors.go:557 +0x80
github.com/github/git-lfs/commands.logPanicToWriter(0xd641c0, 0xc820030148, 0x8965c0, 0xc820010be0)
	/Users/rick/go/src/github.com/github/git-lfs/commands/commands.go:184 +0xf7f
github.com/github/git-lfs/commands.logPanic(0x8965c0, 0xc820010be0, 0x0, 0x0)
	/Users/rick/go/src/github.com/github/git-lfs/commands/commands.go:148 +0x421
github.com/github/git-lfs/commands.handlePanic(0x8965c0, 0xc820010be0, 0x0, 0x0)
	/Users/rick/go/src/github.com/github/git-lfs/commands/commands.go:123 +0x4e
github.com/github/git-lfs/commands.LoggedError(0x8965c0, 0xc820010be0, 0x55a620, 0x1e, 0xc820147c98, 0x2, 0x2)
	/Users/rick/go/src/github.com/github/git-lfs/commands/commands.go:73 +0x82
github.com/github/git-lfs/commands.smudgeCommand(0x75d060, 0xc820077990, 0x1, 0x1)
	/Users/rick/go/src/github.com/github/git-lfs/commands/command_smudge.go:77 +0xd89
github.com/github/git-lfs/vendor/_nuts/github.com/spf13/cobra.(*Command).execute(0x75d060, 0xc8200778e0, 0x1, 0x1, 0x0, 0x0)
	/Users/rick/go/src/github.com/github/git-lfs/vendor/_nuts/github.com/spf13/cobra/command.go:477 +0x403
github.com/github/git-lfs/vendor/_nuts/github.com/spf13/cobra.(*Command).Execute(0x75e0a0, 0x0, 0x0)
	/Users/rick/go/src/github.com/github/git-lfs/vendor/_nuts/github.com/spf13/cobra/command.go:551 +0x46a
github.com/github/git-lfs/commands.Run()
	/Users/rick/go/src/github.com/github/git-lfs/commands/commands.go:88 +0x23
main.main()
	/Users/rick/go/src/github.com/github/git-lfs/git-lfs.go:34 +0x12e

ENV:
LocalWorkingDir=.
LocalGitDir=.git
LocalGitStorageDir=.git
LocalMediaDir=.git/lfs/objects
TempDir=.git/lfs/tmp
ConcurrentTransfers=3
BatchTransfer=true
GIT_DIR=.git
GIT_WORK_TREE=.
GIT_PREFIX=build/

Workaround: clean up the partial checkout, and rename it back:
[15:16:27] ✔ jroelofs@galois build$ git remote rename github origin
[15:16:46] ✘ jroelofs@galois build$ git stash
Saved working directory and index state <snip>
gHEAD is now at 9783474 <snip>
[15:16:51] ✔ jroelofs@galois build$ git stash drop
Dropped refs/stash@{0} (fc5c926d8a7ed10115e0c5935c6c6ec412751308)
[15:16:56] ✔ jroelofs@galois build$ git checkout <snip>
Downloading <snip> (28.13 MB)

Is it because you have a git config value of remote.origin.lfsurl? Unfortunately, I'm not sure there's a lot we can do about renaming remotes other than adding a wrapper like git lfs rename-remote.

$ git config --list | grep remote\.origin\.lfsurl | wc -l
       0

If git remote rename can't be made to DTRT, then... never mind, I guess.
I'll volunteer to write the doc that explaining that renaming doesn't work if you point out the right place for that.

Ohhh, I know what's going on. This is an unfortunate side effect of how the clean/smudge filters work in Git. git checkout runs tracked files through git lfs smudge, which downloads the file from LFS and writes it to the working directory. The problem is that git checkout is completely separate from git fetch or git pull, so it has no idea what remote you're working in.
I think you can do this by turning off the smudge filters with git lfs install --skip-smudge. This means that you will have to run git lfs pull <remote> to get the files from the correct git host. I thought Git LFS was able to detect a branch's tracking remote, but I guess not.


Table cache will be nil when sidekiq restarting

I use dynamoid on ActiveJob with sidekiq.
But I caught unexpected error when sidekiq worker restarting.
gems/dynamoid-2.0.0/lib/dynamoid/adapter_plugin/aws_sdk_v2.rb:762:in `describe_table': undefined method `[]' for nil:NilClass (NoMethodError)
    from gems/dynamoid-2.0.0/lib/dynamoid/adapter_plugin/aws_sdk_v2.rb:464:in `query'
    from gems/dynamoid-2.0.0/lib/dynamoid/adapter.rb:176:in `query'
    from gems/dynamoid-2.0.0/lib/dynamoid/criteria/chain.rb:150:in `block in records_via_query'
    from gems/dynamoid-2.0.0/lib/dynamoid/criteria/chain.rb:130:in `each'
    from gems/dynamoid-2.0.0/lib/dynamoid/criteria/chain.rb:130:in `each'
    from gems/dynamoid-2.0.0/lib/dynamoid/criteria/chain.rb:130:in `each'

It seems that #describe_table method was called before #connect! method calling or adapter.respond_to?(:connect!) had return false.
What happen to the dynamoid when the sidekiq restarting?
I need anyone help. Thank you.
https://github.com/Dynamoid/Dynamoid/blob/56429229147b9a2e03481ca9b88b8d8ea7a7344c/lib/dynamoid/adapter_plugin/aws_sdk_v2.rb#L761-L765
https://github.com/Dynamoid/Dynamoid/blob/56429229147b9a2e03481ca9b88b8d8ea7a7344c/lib/dynamoid/adapter_plugin/aws_sdk_v2.rb#L55-L58
https://github.com/Dynamoid/Dynamoid/blob/56429229147b9a2e03481ca9b88b8d8ea7a7344c/lib/dynamoid/adapter.rb#L28-L36
My environments are following.

dynamoid 2.0.0
ruby 2.4.3
rails 5.1.0
sidekiq 5.0.5

Are you able to reproduce the issue?
Could you try to reproduce it on this branch? https://github.com/Dynamoid/Dynamoid/tree/fix-describe-table-issue-230

Thank you for your response! Let me see.

I tried reproduces the error many times but I couldn't.
I will report again if it reproduces and I can provide more information.
Thank you for your quick response.

Thanks.  Will reopen if you report back with a recurrence.

@andrykonchin we should open a PR for that branch?

@pboling I think no. It's not a fix, just removing some legacy logic. I will add it to the first my PR

I report that I've occurred same exception again with dyanmoid v3.2.0.
I'm using jenkins on deploy, but when it's failure starting sidekiq with some condition, the value of table_cache sometimes will be nil not {}. It was probably the similar situation as before.
It's quite rare case so I think no need fix it, just a reporting.
gems/dynamoid-3.2.0/lib/dynamoid/adapter_plugin/aws_sdk_v3.rb:603:in `describe_table': undefined method `[]' for nil:NilClass (NoMethodError)
    from gems/dynamoid-3.2.0/lib/dynamoid/adapter_plugin/aws_sdk_v3.rb:491:in `block in query'
    from gems/dynamoid-3.2.0/lib/dynamoid/criteria/chain.rb:194:in `each'
    from gems/dynamoid-3.2.0/lib/dynamoid/criteria/chain.rb:194:in `each'
    from gems/dynamoid-3.2.0/lib/dynamoid/criteria/chain.rb:194:in `block in pages_via_query'
    from gems/dynamoid-3.2.0/lib/dynamoid/criteria/chain.rb:155:in `each'
    from gems/dynamoid-3.2.0/lib/dynamoid/criteria/chain.rb:155:in `each'
    from gems/dynamoid-3.2.0/lib/dynamoid/criteria/chain.rb:155:in `each'
    from gems/dynamoid-3.2.0/lib/dynamoid/criteria/chain.rb:155:in `each'
    from gems/dynamoid-3.2.0/lib/dynamoid/criteria/chain.rb:155:in `each'
    from gems/dynamoid-3.2.0/lib/dynamoid/criteria/chain.rb:155:in `each'

https://github.com/Dynamoid/dynamoid/blob/a64b8e155c0fe44b5998f0004caccf2266e10c54/lib/dynamoid/adapter_plugin/aws_sdk_v3.rb#L602-L606

The issue should be fixed in https://github.com/Dynamoid/dynamoid/pull/373


Extent SQL Editor

Hi,
The SQL editor has a toolbar on top (with buttons to open or change connections). Is there a way to add  my own button to that toolbar?  And is there a way I can get the current DB connection of that SQL editor ?
Thanks in advance

Which SQL editor are you referring to here? Do you have an extension installed that provides SQL editing capabilities? Also, are you asking to add a button using the new out of proc extensibility model (VisualStudio.Extensibility) or the in proc VSSDK model?

Hi Tina,
I was referring to the t sql editor that probably gets installed with SSDT?
It doesn't matter if this is for the out or in proc extensibility. It's just I can't find any recent documentation of the TSQL editor. So any example that works in vs 2022 would be great to get me started.
Get Outlook for Androidhttps://aka.ms/ghei36

From: Tina Schrepfer @.>
Sent: Thursday, September 21, 2023 1:50:41 AM
To: microsoft/VSExtensibility @.>
Cc: Pascal Dutilleul | dutilsoft @.>; Author @.>
Subject: Re: [microsoft/VSExtensibility] Extent SQL Editor (Issue #264)
Which SQL editor are you referring to here? Do you have an extension installed that provides SQL editing capabilities? Also, are you asking to add a button using the new out of proc extensibility model (VisualStudio.Extensibility) or the in proc VSSDK model?
—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/VSExtensibility/issues/264#issuecomment-1728565715, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAX6B2ULRN2PHZSQNUMEUB3X3N6NDANCNFSM6AAAAAA43C4KZE.
You are receiving this because you authored the thread.Message ID: @.***>


Switch back to .mllib to produce .cmxa file.

I think this change is not a good idea. Be aware of the motivations to introduce mlpack and double-link problems.

I have no idea of what you're talking about :)
The problem was that Janno couldn't make it work with the mlpack. We need to find out why (it is working for me).
In any case, this is unrelated to the problem I posted just now con Coq's gitter, right?

In any case, this is unrelated to the problem I posted just now con Coq's gitter, right?

Right.

The problem was that Janno couldn't make it work with the mlpack.

I was guessing he was having linking problems due to packing, but then he was doubly-linking in the first place maybe?

I just encountered the same problem: with mlpack now Mtac2 can't find camlMunify.

Maybe you need to do open Unicoq [or Unicoq_plugin, I forgot] mllpack puts plugin modules under packing.

Are you using the MTAC port I submitted?

a modified version by Janno, but essentially yes

I'll have a look.


AoC 2022, Day 02, Java

Create solution for Advent of Code 2022, Day 02 in Java

Closed by 7101a26


TPCDS query 7 & 59 reports wrong result precision using postgres accelerator

Close by: https://github.com/datafusion-contrib/datafusion-table-providers


MM-18186 - Direct Messages filtered search results not in alphabetical order

Summary
fixed profile ordering
Ticket Link
Fixes https://mattermost.atlassian.net/browse/MM-18186

Creating a new SpinWick test server using Mattermost Cloud.

Mattermost test server created! :tada:
Access here: https://mattermost-webapp-pr-4207.test.mattermost.cloud

Account Type
Username
Password

Admin
sysadmin
Sys@dmin123

User
user-1
User-1@123

Test server destroyed

Hi @reflog - I'm trying to set up an old test server with existing users to test this PR but it's not working at the moment.  Carlos will take a look a little later.

Setup Old Test Server label detected. Spinmint test server created if build succeeds (checks pass and no conflicts with base branch).

Spinmint test server created at: https://i-04b782d1f5031a383.test.spinmint.com
Test Admin Account: Username: sysadmin | Password: sysadmin
Test User Account: Username: user-1 | Password: user-1
Internal IP: <IP_ADDRESS>
Instance ID: i-04b782d1f5031a383

Test server destroyed


Server to class

In order to have multiple server instances in a single python interpreter, the Server logic had to be merged into a class.
What do you think?
By the way, I really like your library, is simple and very useful.

This looks like a breaking change. Any ideas on making this backwards compatible?

Yes, we could have a Server instance and assign its register and serve methods into variables:
server = RPCServer()
serve = server.serve
register = server.register

Okay, I have implemented backwards compatibility


Support the --no-wait flag for cf continue-deployment [v8]

Description of the Change
Supports the --no-wait flag for the cf continue-deployment command.
Why Is This PR Valuable?
It brings the continue-deployment command into alignment with other commands that deal with deployments (e.g. cf push, cf restage).
How Urgent Is The Change?
Urgent, as we'd like to include this in our pending release.
Related PRs

#3123

@weresch and @joaopapereira I believe I've now incorporated all of your feedback. Please let me know if I've missed anything! Thanks.


Webapi stopped pulling Data after 401 from Senecs Website

Hey @marq24 i an running 3.0.6-test-04 since yesterday, today at 12:33 the integration stopped pullling data, and i got this error message in log:
2023-09-04 12:33:38.375 ERROR (MainThread) [custom_components.senec] Error requesting senec data: 401, message='', url=URL('https://mein-senec.de/auth/oauth2/authorize?response_type=code&client_id=endkunde-portal&scope=endkunde&state=randomid&redirect_uri=https://mein-senec.de/endkunde/login/oauth2/code/endkunde-portal')
After an reload of senec_WEBAPI it is now working fine. Maybe we could do limited number of retries here if we get an error from senecs website?

Thanks for sharing this...
This 401 during login is caused by a (IMHO) bug in the cookie implementation of aiohttp client - I have created a local patch... but this implies, that no other code will "reset" the used CookieJar for the HTTP Session(s)...
Looks like that this happens at your system (that some code is resetting the client-session - and my patched CookieJar is not used anylonger)... We will see, if I manage to "check" what JAR is currently in use (and "force" mine)... OR if it's faster, that aiohttp team will accept my PR (https://github.com/aio-libs/aiohttp/pull/7577) that I just have submit...

@neubi4 can you please install - https://github.com/marq24/ha-senec-v3/releases/tag/3.0.6-test-05 this one will force the SenecCookieJar when ever the code accessing the web-api... I am courious, if you will see at a certain point of time in the log:
WARNING CookieJar is not of type MySenecCookie JAR any longer... forcing CookieJAR update

I have installed the test-05. To get test-07 do I have to deinstall the integration completely or is there a way of updating it? Like to know if there still is the 401 in test-07.

update works as "usual" via HACs - you man choose "install it again" ... and then select the new build

It worked a little longer with the 07 version so the energy dashboard started showing some numbers. But then I got the 401 problem again:
Logger: custom_components.senec
Source: helpers/update_coordinator.py:229
Integration: SENEC.Home (documentation, issues)
First occurred: 06:48:25 (2 occurrences)
Last logged: 06:54:14
Error requesting senec data: 401, message='', url=URL('https://mein-senec.de/auth/oauth2/authorize?response_type=code&client_id=endkunde-portal&scope=endkunde&state=XXX&redirect_uri=https://mein-senec.de/endkunde/login/oauth2/code/endkunde-portal')
Error requesting senec data: 401, message='', url=URL('https://mein-senec.de/auth/oauth2/authorize?response_type=code&client_id=endkunde-portal&scope=endkunde&state=YYY&redirect_uri=https://mein-senec.de/endkunde/login/oauth2/code/endkunde-portal')

... and did you saw the mentioned warning in ha log? ['CookieJar is not of type MySenecCookie JAR any longer... forcing CookieJAR update']...
the "good" thing is, that since yesterday my SENEC was also updated to the STATISTICS missing version - so I need to use the WEB integration too :-D - My one is running since 23:00 o'clock yesterday so we will see, how this going to develop... I guess with a restart of HA (or just the integration - if that is possible?!) solves the current situation... but obviously the "plan" was something different - should try to auto-re-login if there is any response != 200...

At first thank you very much for your quick replies and your commitment in hellping us senec guy. Unfortunately I am not so deep into HA to answer every question as quick as you can. ;-)
I tried to find the cookie warning but I couldn't. Neither under System/Log (where I find the 401 warning) nor in file system under /config/home-assistant.log Are those spots the right ones to look for die cookie warning?
When I restart the integration manually things are running for a while but then they fail. Interesting: I restarted the integration  13 minutes ago and it's still fine. That is more I ever had since installing the 07 version. Keep your fingers crossed! :-)

... IF they are present, then you find them here... https://[YOUR_HA_ROOT]/config/logs...
But when you say, that 13minutes are already a long period, then I have to check something (in general) - since I would had expect, that this problem would occur after 24h (or later)

Short update: System is running for nearly an hour now. Don‘t know why it didn‘t do this before. I let you know tomorrow morning if it is still alive. And investigate my log files a little more… Thank you!!!

I knock on wood...  ;-)

Good Morning - yesterday evening I released a new (beta) version https://github.com/marq24/ha-senec-v3/releases/tag/3.0.6-test-08 - this include code that should handle possible 401's... this might not be required - but who knows...
Here locally my system had not any 401's so far - BUT since I am obviously test the released before they go live this does not mean that much (probably my system never run's 24h without a restart)

Systems are still up and running. :-) No cookie mentioning anywhere but the 24 hour line is not crossed yet. Thank you for the next release. I will install it the next days.

Version 07 still working as hell more than 24 hours after restart. Nevertheless I will switch to 08 on sunday. Kudos for @marq24 again! 😊

@neubi4  @scottgoo con we consider this as solved?

I think so. Thank you very much!

I was on 3.0.6-test-07 since 5 days and had no issues anymore, so i think this can be closed.


modify dos and pdos

Thank you for your implementation, @uemoto1 san. And thank you for your advice, @shunsuke-sato san. But I found that top and bottom dos are cut when I use lorentzian function for C2H2 case. This is what @yabana sensei said. I'd like to modify the code as following.

I enlarge energy ranges for the DOS and PDOS plot.
Since out_dos_start and out_dos_end in std input is no longer used, I remove them. But they remain as SALMON global variables.
According to the coding rules, I modify from out_dos_nenergy to iout_dos_nenergy.

People who check may disagree above modification. In that case, I'll modify. So please do not hesitate to comment on this PR.

I forgot to say one thing. I tested for the ARTED part and the GCEED part as much as I consider.

Thank you for contribution, @mn2007 san.
I understand your point and agree to use iout_dos_nenergy to obey of the coding rules.   This PR also modified estimation method which provides the much wider range than all electron eigenenergies. I agree it is better than the previous one to understand the entire DoS structure from one plotted graph.
On the other hand, I guess there is a merit to specify the upper and lower bound for usabilities.
Therefore, I have an idea to add the lines below:
if (out_dos_start <= 1.d+10) out_dos_start = ene_min-0.25d0*(ene_max-ene_min)
if (out_dos_end >= 1.d+10) out_dos_end = ene_max+0.25d0*(ene_max-ene_min)

or
out_dos_start = max(out_dos_start, ene_min-0.25d0*(ene_max-ene_min))
out_dos_end = min(out_dos_end, ene_max+0.25d0*(ene_max-ene_min))

.
I prefer using the implementation as above; it makes possible to coexist both of @mn san's method and previous range specification in the same code.
I think this PR is mainly available to merge.
If you need immediate merging, please told it to me.

Thank you for your comment, @uemoto1 san. I would like to implement latter one you suggested. So could you wait until I implement?

Thank you for consideration, I will looking for the next upload.

I finished the implementation. I checked with setting and not setting out_dos_start and out_dos_end for both the ARTED part and the GCEED part, and I obtained results which are satisfied.

If @uemoto1 san judges that it's acceptable to merge, could you merge this PR immediately? Thanks in advance.

Thank you @mn2007 for modification.
I have checked the DoS calculation in ARTED part works well, and it is available to merge to develop branch.


How can I use this package on other environments?

Hi, this packages is awesome, how can I use it to other environments?
To run COMA or other algorithms,
python3 src/main.py --config=coma_smac --env-config=sc2

I found in src/envs, there is a __init__.py file,
from functools import partial
from smac.env import MultiAgentEnv, StarCraft2Env
import sys
import os

def env_fn(env, **kwargs) -> MultiAgentEnv:
    return env(**kwargs)

REGISTRY = {}
REGISTRY["sc2"] = partial(env_fn, env=StarCraft2Env)

if sys.platform == "linux":
    os.environ.setdefault("SC2PATH",
                          os.path.join(os.getcwd(), "3rdparty", "StarCraftII"))

I found I can register set my environment by
REGISTRY["my_env"] = partial(my_env_fn, env=MyEnv)

is it the right way?

That's the intended way. :+1:


oversized-object.js conclusion is incorrect

I run the command（memlab run --scenario ~/memlab/scenarios/oversized-object.js）and find the data and graphics are correct, but the conclusion is incorrect(No leaks found, MemLab found 0 leak(s)).

By default, large objects are not flagged as memory leaks since they could be caches created by the web app. However, if you want to identify large objects using MemLab, use the --trace-object-size-above option.
For example, you can set the flag to check objects larger than 1KB:
memlab run --scenario ~/memlab/scenarios/oversized-object.js --trace-object-size-above 1000

MemLab also supports self-defined leak detector with the leakFilter callback.
You can start with marking all objects allocated as leak and then refine the leak detector based on your app:
leakFilter(node, snapshot, leakedNodeIds) {
  return true;
}

Note: the callback could also be defined in the scenario file.
Please also check out this doc:
https://facebook.github.io/memlab/docs/guides/guides-find-leaks


Validator not displaying results

Hi there,
It looks like the validator is no longer working, can you take a look please?  When I load a tag to check, the results come up blank.
Thanks!
Heather

Looking into it now. Will post when I have more info.
clc
On Wed, Jul 5, 2017 at 10:38 AM, pinkblink32<EMAIL_ADDRESS>wrote:

Hi there,
It looks like the validator is no longer working, can you take a look
please? When I load a tag to check, the results come up blank.
Thanks!
Heather
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/InteractiveAdvertisingBureau/HTML5-AdValidator/issues/16,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAoucttcCyzkL3g3YtYvponI4wTojJDsks5sK8n5gaJpZM4OOpcQ
.

Resolved as a disk space issue. The validator is now working again. Thanks for your report, and you should be back online.


Void motor can't work across dimensions

Version: createutilities-0.1.4+1.20.1 Forge
The void chest and void tank can work across dimensions

It is behaving as expected. Unfortunatly, Create relies too heavily on a kinetic network being one single dimension. Changing that would be too unstable and cause alot of unforeseen problems, specially with other addons. I apologise for the inconvenience.


FIX: Refactor objectPutPart API

Fixes refactoring part of #153

Call metadata.getBucket directly and perform validation checks in the API.
Remove calls to services.metadataValidateAuthorization, services.metadataValidateMultipart, and services.getMPUBucket.
Remove doStore function and instead call services.dataStore and services.metadataStorePart directly in API.
Remove extraneous code after the above changes.

@ironman-machine

Hello @bennettbuchanan
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "SCALITY_S3_BRANCH": "fix/objectPutPart", "DEFAULT_BRANCH": "master"}
Please follow http://ci.ironmann.io/gh/scality/Integration/6612 for CI status.

Looks like you committed dump.rdb file by mistake. Can you remove it?

Thanks @rahulreddy! I've removed it.

So much clearer.  Just a few remaining questions/comments.  thanks!!

@ironman-machine

Hello @bennettbuchanan
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "SCALITY_S3_BRANCH": "fix/objectPutPart", "DEFAULT_BRANCH": "master"}
Please follow http://ci.ironmann.io/gh/scality/Integration/7121 for CI status.

@ironman-machine after log.trace object deletion

Hello @bennettbuchanan
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "SCALITY_S3_BRANCH": "fix/objectPutPart", "DEFAULT_BRANCH": "master"}
Please follow http://ci.ironmann.io/gh/scality/Integration/7122 for CI status.

@ironman-machine with POC

Hello @bennettbuchanan
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "SCALITY_S3_BRANCH": "fix/objectPutPart", "DEFAULT_BRANCH": "master"}
Please follow http://ci.ironmann.io/gh/scality/Integration/7154 for CI status.

@ironman-machine
CI_AGGRESSOR_FORCE_BUILD=true

Hello @bennettbuchanan
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "CI_AGGRESSOR_FORCE_BUILD": "true", "SCALITY_S3_BRANCH": "fix/objectPutPart", "DEFAULT_BRANCH": "master"}
Please follow http://ci.ironmann.io/gh/scality/Integration/7165 for CI status.

@ironman-machine

Hello @bennettbuchanan
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "SCALITY_S3_BRANCH": "fix/objectPutPart", "DEFAULT_BRANCH": "master"}
Please follow http://ci.ironmann.io/gh/scality/Integration/7168 for CI status.

@ironman-machine

Hello @bennettbuchanan
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "SCALITY_S3_BRANCH": "fix/objectPutPart", "DEFAULT_BRANCH": "master"}
Please follow http://ci.ironmann.io/gh/scality/Integration/7175 for CI status.

@ironman-machine hey Jarvis

Hello @bennettbuchanan
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "SCALITY_S3_BRANCH": "fix/objectPutPart", "DEFAULT_BRANCH": "master"}
Please follow http://ci.ironmann.io/gh/scality/Integration/7177 for CI status.

end-to-end passed with a variable declaration change in storeObject.js. The dataStore function has been refactored accordingly and a new function checkHashMatchMD5 added.

@ironman-machine

Hello @bennettbuchanan
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "SCALITY_S3_BRANCH": "fix/objectPutPart", "DEFAULT_BRANCH": "master"}
Please follow http://ci.ironmann.io/gh/scality/Integration/7240 for CI status.

end-to-end rebuilt and passed here:
http://ci.ironmann.io/gh/scality/Integration/7246

@ironman-machine

Hello @bennettbuchanan
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "SCALITY_S3_BRANCH": "fix/objectPutPart", "DEFAULT_BRANCH": "rel/6.3"}
CI message: "Branch not found"
Please follow the last build of ultron/rel/6.3 for CI status.

@ironman-machine sorry, ultron/rel/6.3 branch wasnt created on Integration. Should be better now.

Hello @DavidPineauScality
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "SCALITY_S3_BRANCH": "fix/objectPutPart", "DEFAULT_BRANCH": "rel/6.3"}
Please follow http://ci.ironmann.io/gh/scality/Integration/7406 for CI status.

Hi @DavidPineauScality, thanks for checking this. 😸

@ironman-machine after latest rebase

Hello @bennettbuchanan
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "SCALITY_S3_BRANCH": "fix/objectPutPart", "DEFAULT_BRANCH": "rel/6.3"}
Please follow http://ci.ironmann.io/gh/scality/Integration/7470 for CI status.

@ironman-machine after rebase onto master

Hello @bennettbuchanan
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "SCALITY_S3_BRANCH": "fix/objectPutPart", "DEFAULT_BRANCH": "master"}
Please follow http://ci.ironmann.io/gh/scality/Integration/7471 for CI status.


Missing SHASUMS256.txt in uploaded version 14.17.6

node gyp build is currently failing because the recently uploaded version of node is generating a 404 for the file at https://nodejs.org/download/release/v14.18.0/SHASUMS256.txt

I've the same problem but for the headers node-v14.18.0-headers.tar.gz:
https://github.com/nodejs/node/issues/40309

I queued a cdn purge and the link appears to be working for me now. Please could you try again?

resolved and an explanation posted @ https://github.com/nodejs/node/issues/40309#issuecomment-934030197
sorry for the inconvenience


One-off 'pdftops not found' error after install

This is the same problem that I reported in #183, but I'd forgotten about it.  I'm raising it again because, even if it's no big deal/not easily fixed, it's probably worth warning users.
After a new install, on the first attempt to export with -eps, I got:
Error running pdftops:
/bin/bash: pdftops: command not found
I think this arises from lines 148/149 of pdftops.m, but couldn't confirm because it only happens once ... so when I put some debug output in and tried again, there was no longer a problem.

Fixed


Consider redirecting LC Instructor page

What is the problem?
Consider removing the section here on Apply to be an instructor (https://librarycarpentry.org/get_involved/#Apply) and redirecting to go to The Carpentries Become an Instructor page instead (https://carpentries.org/become-instructor/).
@karenword  If you agree, I can make the change.
Location of problem (optional)
No response

lgtm!


Container restart policies may fail on linked containers after engine restart

Description of problem: When running several linked containers with --restart=always, some containers may not come back up after an engine restart.
docker version:
Client:
 Version:      1.9.0-rc1
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   9291a0e
 Built:        Wed Oct 14 03:04:22 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.0-rc1
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   9291a0e
 Built:        Wed Oct 14 03:04:22 UTC 2015
 OS/Arch:      linux/amd64

Experienced on at least 1.6.2, 1.8.2, 1.8.3 as well.
docker info:
Containers: 37
Images: 409
Engine Version: 1.9.0-rc1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 485
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-39-generic
Operating System: Ubuntu 14.04.1 LTS
CPUs: 2
Total Memory: 1.955 GiB
Name: vagrant-ubuntu-trusty-64
ID: 3YCN:IHBG:FR4D:TDIK:EL4I:YIIY:YUSE:BX73:DTYO:JQOO:A7HL:ZNK2
Username: brianbland
Registry: https://index.docker.io/v1/
WARNING: No swap limit support

uname -a:
Linux vagrant-ubuntu-trusty-64 3.13.0-39-generic #66-Ubuntu SMP Tue Oct 28 13:30:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Environment details (AWS, VirtualBox, physical, etc.):
Ubuntu 14.04 VirtualBox (vagrant)
How reproducible:
Seems to happen ~1/3 of the time when running Docker Trusted Registry (1.0 - 1.3.3), but I have been unable to find a simpler container configuration that commonly reproduces this issue
Steps to Reproduce:

Install/run Docker Trusted Registry: docker run docker/trusted-registry:1.3.3 install | bash
Restart the engine: service docker restart

Actual Results:
$ docker ps -q | wc -l
6
$ sudo service docker restart
docker stop/waiting
docker start/running, process 31683
$ docker ps -q | wc -l
6
$ sudo service docker restart
docker stop/waiting
docker start/running, process 32127
$ docker ps -q | wc -l
4

The two containers that did not restart were linked to other containers in this stack.
Expected Results:
All of the containers running before the engine restart are once again running.
Additional info:
Relevant engine logs:
Waiting for /var/run/docker.sock
INFO[0000] API listen on /var/run/docker.sock
INFO[0000] [graphdriver] using prior storage driver "aufs"
INFO[0000] Firewalld running: false
WARN[0000] Your kernel does not support swap memory limit.
/var/run/docker.sock is up
INFO[0000] Loading containers: start.
...............................ERRO[0000] Failed to load container b68e5d0a08034373459bd7ab7a88e67773887b778a912ae5eda7f0f145e1a5f2: open /var/lib/docker/containers/b68e5d0a08034373459bd7ab7a88e67773887b778a912ae5eda7f0f145e1a5f2/config.json: no such file or directory
...........................................................WARN[0000] Could not connect container 7aca6e27e3950064df00fb2dfb630360e69457410426f87693b1d42fb4e7876a : nosuchcontainer: no such id: 28dcf8584e35003d559ff1166cae820e5e8a43400adb7057e88d10f5f4c2c640
ERRO[0000] failed to umount /var/lib/docker/containers/7aca6e27e3950064df00fb2dfb630360e69457410426f87693b1d42fb4e7876a/shm: invalid argument
ERRO[0000] failed to umount /var/lib/docker/containers/7aca6e27e3950064df00fb2dfb630360e69457410426f87693b1d42fb4e7876a/mqueue: invalid argument
ERRO[0000] 7aca6e27e3950064df00fb2dfb630360e69457410426f87693b1d42fb4e7876a: Failed to umount ipc filesystems: failed to cleanup ipc mounts:
invalid argument
invalid argument
ERRO[0000] Failed to start container 7aca6e27e3950064df00fb2dfb630360e69457410426f87693b1d42fb4e7876a: nosuchcontainer: no such id: 28dcf8584e35003d559ff1166cae820e5e8a43400adb7057e88d10f5f4c2c640
ERRO[0000] failed to umount /var/lib/docker/containers/7191c0055251105be6c21645badc9848124a0caab5e4b7200a8fa914d1ec7929/shm: invalid argument
ERRO[0000] failed to umount /var/lib/docker/containers/7191c0055251105be6c21645badc9848124a0caab5e4b7200a8fa914d1ec7929/mqueue: invalid argument
ERRO[0000] 7191c0055251105be6c21645badc9848124a0caab5e4b7200a8fa914d1ec7929: Failed to umount ipc filesystems: failed to cleanup ipc mounts:
invalid argument
invalid argument
ERRO[0000] Failed to start container 7191c0055251105be6c21645badc9848124a0caab5e4b7200a8fa914d1ec7929: linknotrunning: Cannot link to a non running container: /docker_trusted_registry_admin_server AS /docker_trusted_registry_load_balancer/admin_server

INFO[0000] Loading containers: done.
INFO[0000] Daemon has completed initialization
INFO[0000] Docker daemon                                 commit=9291a0e execdriver=native-0.2 graphdriver=aufs version=1.9.0-rc1

Is this a regression from 1.8.x?

No, this behavior was seen in 1.8.2 and 1.6.2 as well.

I'm pretty sure there have never been guarantees to prevent linked containers from starting before their parents. However, before 1.7, containers started in order, which might have given the false perspective of starting in the right order. We change the restarting logic in 1.7 to start all containers in parallel, allowing plugin containers to boot without being blocked by those containers that depend on the plugins. This change might have made this bug more prominent.
All in all, I don't think we should add this to 1.9, or maybe we should not fix it at all. AFAIK, you can probably stop using links in favor of the new networking stack.

I also get this all the time on 1.9.1. Plus is this a duplicate of #17611?

I didn't have this issue before, but started experiencing it after setting up docker on a new server. The error shown is:

Error response from daemon: Cannot restart container some_container_name: Cannot link to a non running container: /postgres AS /some_container_name/postgres

However, the postgres container is running and actively used by other containers without problems.
$ docker version
Client:
 Version:      1.11.2
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   b9f10c9
 Built:        Wed Jun  1 22:00:43 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.2
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   b9f10c9
 Built:        Wed Jun  1 22:00:43 2016
 OS/Arch:      linux/amd64

$ docker info
Containers: 11
 Running: 11
 Paused: 0
 Stopped: 0
Images: 2313
Server Version: 1.11.2
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 2740
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 4.4.0-22-generic
Operating System: Ubuntu 16.04 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 11.73 GiB
Name: rs217328
ID: A7W2:3ZT4:H2EM:55BR:F7W6:QIZ3:HOKU:6MY5:6PMA:H52X:MC6G:7NBJ
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Username: pgrm
Registry: https://index.docker.io/v1/
WARNING: No swap limit support

all containers are running with --retstart="always" and it hasn't been an issue before. The only way I can resolve it right now is to restart the server. Any ideas?

I am running node containers on my raspberrypi, and am facing the extreme opposite behavior: when the device reboots due to power outage, I see 3 or 4 different instances of the node container being restarted! The only work-around is do a 'docker rm -f XXXXX' on each running container, do a clean reboot, and then have the device functioning again.

I'm going to close this, as this was resolved in 1.10 where docker will defer starting any containers with it's links have been started.
In 1.11.2 it was also added to wait for the daemon discovery to be ready before trying to start containers (making sure overlay networking was ready).
Any other issue should be addressed separately, and indeed is most likely a configuration error, but happy to discuss on another issue.
Thanks all.


Friendlier error message on missing package.json

Just saw your comment here and wanted to take for a spin! I too agree that Relay has some onboarding issues.
One issue I just encountered was after running  npx @tobiastengler/create-relay-app and then getting the error Error: package.json file is missing. I initially thought that this would bootstrap whatever framework the user chose before setting up the Relay bits (eg, npx create-next-app), so seeing that issue was a bit confusing. Maybe something like
Error: package.json file is missing. Did you remember to setup <create-react-app|next|vite> before running this command?

Would fix the issue.

Thank you for the feedback, I'll incorporate it :)

The error message reads now as follows:

👌


[FIX] Update scripts to make TPU example work

The old dependencies don't work anymore. Make the necessary updates to fix the errors.

/gcbrun

/gcbrun


Add further reading to tutorial

Type of PR

[ ] BUG
[ ] FEAT
[ ] MAINT
[X] DOC

Is your Pull Request linked to an existing Issue or Pull Request?

Give a brief description for the solution you have provided

Add signposting to other parts of the docs throughout the tutorial
PR Checklist

[ ] Added documentation for changes
[ ] Added feature to example notebooks at tutorial in splink_demos (if appropriate)
[ ] Added tests (if appropriate)
[ ] Made changes based off the latest version of Splink
[ ] Run the linter

Typo in the file docs/demos/tutorials/02_Exploratory_analysis.ipynb on line 2638:
"we have begin to" should be
"we have begun to"


Documentation 0.9

Hello
I started to write an application with version 0.9 and I can no longer find the documentation for this version. I would say it would be complicated and expensive to migrate to 0.10. Is there a way to check the documentation for version 0.9?
Regards,

Currently, our documentation only accounts for the latest version of Clarity. We have an issue open to make older version docs available ( #1370 ).
Your best option at this time is to either clone our repo, set it to a previous version, and run the docs locally or to review the docs through the code here on github.
Please subscribe to issue #1370 for updates.
Closing this as a duplicate.

@Dejahna - which version of Clarity 0.9x are you using?

0.9.13