text:
Tracking issue for text rendering changes

~[ ] Add FrameText #483~
[ ] Imprt BDF code into embedded-bdf repo
[ ] Fix text examples
The changes in PR #510 will break the examples
[ ] Add text alignment example
~[ ] Use FrameText in analog clock example~
[ ] Update builtin monospaced fonts or add additional fonts as separate repo
[ ] Try to distribute BDF fonts as crates
[ ] Improve docs #480
[ ] Add simple external font renderer example to e-g docs
[x] Create repo for seven segment font renderer #481

I've been thinking about strikethrough and underlined text support in e-g. Because fonts can look whatever, just dashing a 1px line through them is suboptimal, and so this should be supported on a per-renderer basis. This would remove the responsibility out of e-t to try and guess these decorations, which I consider a good thing. This also means I don't have to knock on your doors to publish MonoFont's pixel iterator :)
For MonoFont, at least for 6x8 it means the following:

For underlined text to look good, underlined characters are 1 px taller than otherwise
We could add the decoration programatically, as it is currently done in e-t. This works for 6x8 but may require multiple lines for bigger fonts to look good, something I haven't checked yet. This poses the problem of describing the decoration in the font data.
We could add 3 (ul, st, ul+st) new glyphs for the fonts and overlay those during rendering. Depending on the font, the underline may require making the glyphs taller, and I'm not sure what would be the nicest solution here - 6x9 glyphs in the 6x8 font sounds fishy, after all.

I've been thinking about strikethrough and underlined text support in e-g. Because fonts can look whatever, just dashing a 1px line through them is suboptimal, and so this should be supported on a per-renderer basis. This would remove the responsibility out of e-t to try and guess these decorations, which I consider a good thing. This also means I don't have to knock on your doors to publish MonoFont's pixel iterator :)
For MonoFont, at least for 6x8 it means the following:

For underlined text to look good, underlined characters are 1 px taller than otherwise
We could add the decoration programatically, as it is currently done in e-t. This works for 6x8 but may require multiple lines for bigger fonts to look good, something I haven't checked yet. This poses the problem of describing the decoration in the font data.
We could add 3 (ul, st, ul+st) new glyphs for the fonts and overlay those during rendering. Depending on the font, the underline may require making the glyphs taller, and I'm not sure what would be the nicest solution here - 6x9 glyphs in the 6x8 font sounds fishy, after all.

I agree that underlining and strikethrough can't be handled generically for all text renderers and therefore should be handled by the individual renderers.
IMO strikethrough should be implemented differently: Instead of changing some pixels to text_color during the glyph rendering I would draw the line after the glyph is rendered. This would cause some overdraw, but has two advantages IMO: Most text doesn't use strikethrough, so we wouldn't need to slow down rendering of normal text by the additional strikethrough logic. And if we add alpha support later it would be possible to draw a semi transparent strikethrough with the text visible behind the stroke.
To make the semi transparent strikethrough possible we would need to add color settings for strikethrough and underline, which would be a nice to have feature anyway IMO. Perhaps as a custom enum: None, TextColor, BackgroundColor, Custom(C).

I agree that underlining and strikethrough can't be handled generically for all text renderers and therefore should be handled by the individual renderers.
IMO strikethrough should be implemented differently: Instead of changing some pixels to text_color during the glyph rendering I would draw the line after the glyph is rendered. This would cause some overdraw, but has two advantages IMO: Most text doesn't use strikethrough, so we wouldn't need to slow down rendering of normal text by the additional strikethrough logic. And if we add alpha support later it would be possible to draw a semi transparent strikethrough with the text visible behind the stroke.
To make the semi transparent strikethrough possible we would need to add color settings for strikethrough and underline, which would be a nice to have feature anyway IMO. Perhaps as a custom enum: None, TextColor, BackgroundColor, Custom(C).

Is transparent strikethrough a common feature we should support? For me it sounds esoteric enough for us to ignore, we are targeting resource-constrained systems, after all. Third party renderers may do as they wish, especially if it's as complicated as drawing a line over the text, so extending MonoFont wouldn't probably be terribly difficult here.
You make a good point with the overhead.
A bit different question that came up:
e-t currently renders on a per-character basis. Since font renderers are only required to provide a render_line(..., &str) to draw text, I need to rework how e-t draws text.
This is mostly fine, as I can take substrings and render those. However, e-t supports fully justified alignment, which means whitespace width isn't constant, so I can't simply call render_line(" ") for those. While I can probably work around this using a clipped draw target, if renderers could provide a way to fill a space with whatever, it would be a big help. If we ever want to do text decoration, e-t can't just use a rectangle, unfortunately.

Is transparent strikethrough a common feature we should support? For me it sounds esoteric enough for us to ignore, we are targeting resource-constrained systems, after all. Third party renderers may do as they wish, especially if it's as complicated as drawing a line over the text, so extending MonoFont wouldn't probably be terribly difficult here.
You make a good point with the overhead.
A bit different question that came up:
e-t currently renders on a per-character basis. Since font renderers are only required to provide a render_line(..., &str) to draw text, I need to rework how e-t draws text.
This is mostly fine, as I can take substrings and render those. However, e-t supports fully justified alignment, which means whitespace width isn't constant, so I can't simply call render_line(" ") for those. While I can probably work around this using a clipped draw target, if renderers could provide a way to fill a space with whatever, it would be a big help. If we ever want to do text decoration, e-t can't just use a rectangle, unfortunately.

Is transparent strikethrough a common feature we should support?

No, IMO strikethrough itself is already pretty uncommon. But if we draw the line after the glyph this would just work if we add alpha support.

This is mostly fine, as I can take substrings and render those. However, e-t supports fully justified alignment, which means whitespace width isn't constant, so I can't simply call render_line(" ") for those. While I can probably work around this using a clipped draw target, if renderers could provide a way to fill a space with whatever, it would be a big help. If we ever want to do text decoration, e-t can't just use a rectangle, unfortunately.

Why would you need a clipped draw target in this case? Couldn't you call render_line for each word? Perhaps we should rename the method to render_text and add another method to get the line height instead of returning it from render_line.

Is transparent strikethrough a common feature we should support?

No, IMO strikethrough itself is already pretty uncommon. But if we draw the line after the glyph this would just work if we add alpha support.

This is mostly fine, as I can take substrings and render those. However, e-t supports fully justified alignment, which means whitespace width isn't constant, so I can't simply call render_line(" ") for those. While I can probably work around this using a clipped draw target, if renderers could provide a way to fill a space with whatever, it would be a big help. If we ever want to do text decoration, e-t can't just use a rectangle, unfortunately.

Why would you need a clipped draw target in this case? Couldn't you call render_line for each word? Perhaps we should rename the method to render_text and add another method to get the line height instead of returning it from render_line.

Why would you need a clipped draw target in this case?

I need to draw the whitespace if the user sets background color, and strikethrough/underline should also be rendered there. I can do this by repeatedly drawing a single space, but if the justified layout calculates that a space should be 1.25 characters wide, well I need to clip a whole space somehow :)

Why would you need a clipped draw target in this case?

I need to draw the whitespace if the user sets background color, and strikethrough/underline should also be rendered there. I can do this by repeatedly drawing a single space, but if the justified layout calculates that a space should be 1.25 characters wide, well I need to clip a whole space somehow :)

Ah, that makes sense. Would an additional draw_whitespace(point, width) method, that draws the background and lines, work for e-t?

Ah, that makes sense. Would an additional draw_whitespace(point, width) method, that draws the background and lines, work for e-t?

Yes, I believe it would work.

Yes, I believe it would work.

@bugadani Do you think that we could make e-t completely renderer agnostic?
I think it would help to split the TextBoxStyle into two styles instead of duplicating all settings in MonoTextStyle or similar types from other renderers. This would make the API a bit more complicated to use, but would cleanly split character from paragraph styling, which is common in word processors and DTP applications. To help with this split I would suggest to move the horizontal and vertical alignment settings from MonoTextStyle to Text, because they aren't used by e-t and don't belong to the character styling.

@bugadani Do you think that we could make e-t completely renderer agnostic?
I think it would help to split the TextBoxStyle into two styles instead of duplicating all settings in MonoTextStyle or similar types from other renderers. This would make the API a bit more complicated to use, but would cleanly split character from paragraph styling, which is common in word processors and DTP applications. To help with this split I would suggest to move the horizontal and vertical alignment settings from MonoTextStyle to Text, because they aren't used by e-t and don't belong to the character styling.

@rfuest certainly. Work has already been started in https://github.com/embedded-graphics/embedded-text/pull/90 - the PR is probably not even close to what it should look like, but it's an attempt at least in this direction.
For MonoFont and the likes, the task is actually not that difficult. There are only a few requirements and so far embedded-text did all the other work:

Measuring a character
Drawing a character
Drawing whitespace

The current string-based rendering provided by e-g is actually a lot more flexible, where the font renderer itself handles special characters (like \r or a soft hyphen). It could also make support for fancier features, like connecting cursive characters, possible. The core of e-t isn't up to this task, currently, as I need to change the implementation to work in terms of strings instead.
There are a lot of open questions if we are to make e-t into something of a general package. How does escape sequence styling affect text rendering? Take for example a cursive font renderer that connects characters - what if, inside a word, someone changes font color? e-t will need to issue two different draw calls, how will it communicate the connection between characters? I'm quite sure we need a time-generality tradeoff somewhere.
I'm not sure what you mean by "horizontal alignment ... aren't used by e-t". The alignment settings aren't the same, but they are certainly used. At any rate, e-t never relied upon MonoTextStyle's alignment settings to it seems fine to me.
Long story short:

I'm working on it
I'm trying to make use of whatever e-g provides (assuming e-g will implement draw_whitespace :) ).
We'll probably need several iterations in the future on how the interface will need to look.

@rfuest certainly. Work has already been started in https://github.com/embedded-graphics/embedded-text/pull/90 - the PR is probably not even close to what it should look like, but it's an attempt at least in this direction.
For MonoFont and the likes, the task is actually not that difficult. There are only a few requirements and so far embedded-text did all the other work:

Measuring a character
Drawing a character
Drawing whitespace

The current string-based rendering provided by e-g is actually a lot more flexible, where the font renderer itself handles special characters (like \r or a soft hyphen). It could also make support for fancier features, like connecting cursive characters, possible. The core of e-t isn't up to this task, currently, as I need to change the implementation to work in terms of strings instead.
There are a lot of open questions if we are to make e-t into something of a general package. How does escape sequence styling affect text rendering? Take for example a cursive font renderer that connects characters - what if, inside a word, someone changes font color? e-t will need to issue two different draw calls, how will it communicate the connection between characters? I'm quite sure we need a time-generality tradeoff somewhere.
I'm not sure what you mean by "horizontal alignment ... aren't used by e-t". The alignment settings aren't the same, but they are certainly used. At any rate, e-t never relied upon MonoTextStyle's alignment settings to it seems fine to me.
Long story short:

I'm working on it
I'm trying to make use of whatever e-g provides (assuming e-g will implement draw_whitespace :) ).
We'll probably need several iterations in the future on how the interface will need to look.

I'm currently working on moving the text renderer API to the core crate. This first version should contain everything that is required to render simple fonts. We will probably need to extend or change the API when we want to support advanced features, like ligatures, in the future, but I don't want to over complicate the first version.

I'm not sure what you mean by "horizontal alignment ... aren't used by e-t".

That e-t didn't use the settings in MonoTextStyle. The MonoTextStyle vertical alignment is different from the e-t version, because it only sets the position of the first line and not the vertical alignment of the entire paragraph (I'm considering to change the name to baseline to match the related CSS property). But IMO these settings shouldn't be present in MonoTextStyle if they are ignored by e-t.

I'm working on it

:+1:

I'm trying to make use of whatever e-g provides (assuming e-g will implement draw_whitespace :) ).

I'm working on it :wink:

We'll probably need several iterations in the future on how the interface will need to look as I don't want to be the reason to delay e-g 0.7 a lot longer.

I agree that this will probably need tweaks later, but I think we should get some basic version ready for the 0.7 release, whenever that will be.

I'm currently working on moving the text renderer API to the core crate. This first version should contain everything that is required to render simple fonts. We will probably need to extend or change the API when we want to support advanced features, like ligatures, in the future, but I don't want to over complicate the first version.

I'm not sure what you mean by "horizontal alignment ... aren't used by e-t".

That e-t didn't use the settings in MonoTextStyle. The MonoTextStyle vertical alignment is different from the e-t version, because it only sets the position of the first line and not the vertical alignment of the entire paragraph (I'm considering to change the name to baseline to match the related CSS property). But IMO these settings shouldn't be present in MonoTextStyle if they are ignored by e-t.

I'm working on it

:+1:

I'm trying to make use of whatever e-g provides (assuming e-g will implement draw_whitespace :) ).

I'm working on it :wink:

We'll probably need several iterations in the future on how the interface will need to look as I don't want to be the reason to delay e-g 0.7 a lot longer.

I agree that this will probably need tweaks later, but I think we should get some basic version ready for the 0.7 release, whenever that will be.

But IMO these settings shouldn't be present in MonoTextStyle if they are ignored by e-t.

Agreed.
Currently, e-t wraps the font's style into the textbox's style. Perhaps e-g should do something similar to that with Text. I believe this is exactly what you proposed, so I'm just stating the obvious, am I not? :)

But IMO these settings shouldn't be present in MonoTextStyle if they are ignored by e-t.

Agreed.
Currently, e-t wraps the font's style into the textbox's style. Perhaps e-g should do something similar to that with Text. I believe this is exactly what you proposed, so I'm just stating the obvious, am I not? :)

Currently, e-t wraps the font's style into the textbox's style. Perhaps e-g should do something similar to that with Text. I believe this is exactly what you proposed, so I'm just stating the obvious, am I not? :)

I'm not quite sure about the exact implementation yet, so it might not be totally obvious ;). At the moment I'm considering to add the alignment options directly to the Text struct instead of wrapping the style inside another style. Text::new("abc", pos) would create a text with the default alignement and Text::with_alignment("abc", pos, h_algin, v_align) could be used set another alignment.

Currently, e-t wraps the font's style into the textbox's style. Perhaps e-g should do something similar to that with Text. I believe this is exactly what you proposed, so I'm just stating the obvious, am I not? :)

I'm not quite sure about the exact implementation yet, so it might not be totally obvious ;). At the moment I'm considering to add the alignment options directly to the Text struct instead of wrapping the style inside another style. Text::new("abc", pos) would create a text with the default alignement and Text::with_alignment("abc", pos, h_algin, v_align) could be used set another alignment.

I think I'd prefer a style for that - maybe even if it means one for the font, one for the "target". I would like to see Text and TextBox be similar in this regard and TextBox certainly has more options, which I wouldn't like to (re)do as a huge array of constructors :) Maybe Text will have some as well in the future, who knows?

I think I'd prefer a style for that - maybe even if it means one for the font, one for the "target". I would like to see Text and TextBox be similar in this regard and TextBox certainly has more options, which I wouldn't like to (re)do as a huge array of constructors :) Maybe Text will have some as well in the future, who knows?

OK, that makes sense. I'll try to implement this in my next PR.

OK, that makes sense. I'll try to implement this in my next PR.

I've opened an draft PR for the new version of the text renderer API. It should contain most changes required for e-t, but it still requires some polish and needs to be tested with other renderers.

I've opened an draft PR for the new version of the text renderer API. It should contain most changes required for e-t, but it still requires some polish and needs to be tested with other renderers.

The BDF font renderer is now partially ported to the new text renderer API: https://github.com/embedded-graphics/embedded-bdf/pull/5 It still need some work, but the basics work, without having to implement any special drawables, like before.

The BDF font renderer is now partially ported to the new text renderer API: https://github.com/embedded-graphics/embedded-bdf/pull/5 It still need some work, but the basics work, without having to implement any special drawables, like before.

Just wanted to chime in that the recent changes cover everything necessary to bring embedded-text up to date with embedded-graphics. Still quite a lot of work to be done on my end, but at least now the project can compile and passes the tests using latest alphas.

That sounds great! I'll try to not break the API too many times until the 0.7 release ;)

not sure this is the right place for it but, related to breaking text rendering API changes and y'all may already have a plan to solve this?
have y'all considered dynamic bounds on the font / styles etc., rather than the type parameters on everything? at the moment if you want to say, render in more than one style, you have to do rebuild the style / everything else because they're technically different types, where they could instead take a reference to an impl of the relevant trait (Font, for example)?
also in few places, like alignment, these types would appear to be representable as an enum rather than a type/trait to simplify the container further? in some instances it's possible to write container enums to mitigate this, however, where associated constants are used this becomes impossible. The Font trait is a particularly tricky candidate as the associated constants would appear to preclude loading of external fonts (as they need a container type with matching constants).
as an example, to abstract over multiple font sizes, ts, tb, 'a', 'v', and 'h' are distinct types thus cannot be stored in the same place, so one must exponentially expand this for all possible fonts -and- styles (alignments etc.):
FontKind::Font8x16 => {
                let ts = TextBoxStyleBuilder::new(Font8x16)
                    .text_color(BinaryColor::On)
                    .height_mode(h)
                    .alignment(a)
                    .vertical_alignment(v)
                    .build();

                let tb = tb.into_styled(ts);

                tb.draw(&mut self.display).unwrap();

                tb.size()
            }
            FontKind::Font12x16 => {
                let ts = TextBoxStyleBuilder::new(Font12x16)
                    .text_color(BinaryColor::On)
                    .height_mode(h)
                    .alignment(a)
                    .vertical_alignment(v)
                    .build();

                let tb = tb.into_styled(ts);

                tb.draw(&mut self.display).unwrap();

                tb.size()
            }
... repeat for every font and style you may wish to render

Extensibility is one aspect - if embedded-graphics were to provide a Fonts enum, I don't see how third parties could define their own fonts. Same is true for alignments, "height modes" (an example is the Scrolling alignment that was added to the set, it's possible there are other useful algos that aren't currently implemented in the crate).
A known limiatation in embedded-text is that while in principle it could render text with different fonts at the same time, it's not easy to describe that on the type level.
I suppose it's possible to group Fonts together into FontFamily enums and define a font renderer for those - however, I'm not sure how we should do that currently.
An idea I'm considering would be to implement a FontFamily as an n-tuple of fonts, but I'll need some experimentation to see what's even possible.
This is definitely something I want to do for embedded-text, but requires time to come up with a solution that won't need to rearchitect the world one more time (ideally, not changing embedded-graphics at all).

I've been recently working on a draft PR that converts the MonoFont trait into a struct. This would make all monospaced fonts have the same type. This should help with some of these problems.

also in few places, like alignment, these types would appear to be representable as an enum rather than a type/trait to simplify the style container further?

This only applies to embedded-text, the internal TextStyle already uses enums for the alignment settings. I would also prefer to use enums in both cases to remove some generics and provide a more consistant API in e-t and e-g.

Do you expect that other crates will extend the formatting options in e-t or why do you think that an enum based solution will be less extensible?

Once I was convinced the alignment options were done, I got a request for a new one. I know I can't think of everything :) But I actually have an idea how to work around this. Or maybe I could just go doen the route of feature requests. Anyway, consistency would be a plus here.

Adding a non_exhaustive attribute to the enums might be a good idea. This would make adding new alignment options non breaking changes.

I've been recently working on a draft PR that converts the MonoFont trait into a struct. This would make all monospaced fonts have the same type. This should help with some of these problems.

A MonoFont struct that is consistent for all the monospace fonts would be excellent, perhaps paired with a Font trait that this implements for rendering? This would simplify the use of monospace stuff, while ideally allowing others to implement different fonts / renderers.
Rather than an enum for all the fonts, a dynamic trait binding&dyn Whatever in place of generics would mitigate this as you could then refer to static Font instances (which actually sorta makes sense in this context I think) without changing the object -types-, or wrap a bunch of fonts in an enum and re-implement the trait over it if this was desirable, and you can still use dynamic dispatch without Box without it being an issue.

Once I was convinced the alignment options were done, I got a request for a new one. I know I can't think of everything :) But I actually have an idea how to work around this. Or maybe I could just go doen the route of feature requests. Anyway, consistency would be a plus here.

One option is to maintain the alignment trait, implemented over an enum rather than a set of types in the library, and use that as a default type bound so unless you're using something custom the types are all consistent, but if you want something custom you can drop that in instead?

Out of curiousity, could you describe your use case, please?

I'm trying to use it in a sorta customisable / composable manner, basically exposing a higher-level API for rendering out a pages / windows / window-stacks, but, so long as the type signatures differ (and the traits are non-genericisable) it's proving to be a struggle. My hope is to replicate some of the higher-level composition that pebble used to have with WindowStacks (which was the best setup for embedded GUIs I have ever come across) and I long-ago partially replicated in C.

Sorry for the late reply.

...perhaps paired with a Font trait that this implements for rendering?

e-g 0.7 adds a TextRenderer trait, which can implemented for text style objects to add support for other text renderers. We have started to implement two external renderers for BDF fonts and a scalable seven segment font: https://github.com/embedded-graphics/bdf and https://github.com/embedded-graphics/eg-seven-segment

...but the traits would need to be reworked to be dispatch-able (no associated constants).

Do you have an idea how we could make the TextRenderer trait object safe? Here is an abbreviated version of the trait:
pub trait TextRenderer {
    type Color: PixelColor;

    fn draw_string<D>(
        &self,
        text: &str,
        position: Point,
        baseline: Baseline,
        target: &mut D,
    ) -> Result<Point, D::Error>
    where
        D: DrawTarget<Color = Self::Color>;
}

The associated type shouldn't be a problem, because we can &dyn TextRenderer<Color = C> where the trait is used. But I don't see a good way to get rid of the generic type D on the drawing function. If DrawTarget would be object safe we could also use dynamic dispatch for the target parameter, but we couldn't use custom error types anymore:
pub trait TextRenderer {
    type Color: PixelColor;

    fn draw_string(
        &self,
        text: &str,
        position: Point,
        baseline: Baseline,
        target: &mut dyn DrawTarget<Color = Self::Color>,
    ) -> Result<Point, ???>;
}

And making DrawTarget object safe would mean that iterators would be passed by using dynamic dispatch, which will probably have a higher performance impact (just an untested assumption).

Also please feel free to tag / message in other places if I can be of any help in designing / reviewing any of these things, I have a wee bit of experience with designing traits / abstractions as a maintainer on embedded-hal, and this is an awesome library / effort!

Thanks for that offer, it's really appreciated.

Sorry for the late reply.

nw! life is busy / fully expect the same from me eh.

Do you have an idea how we could make the TextRenderer trait object safe? Here is an abbreviated version of the trait:

how about inverting this perhaps? then it doesn't need to be object safe but also could be. Generally the draw target and colour will be constant for a given system, much more so than the font / text, so associated types for target / colour types, and I think with colour extracted the font may not even need to be dynamic dispatched because the function call will just get monomorphized at the call site.
something like:
impl <E, D, C> TextRender for D
where
  D: DrawTarget<Error=E>,
  C: Colour,
  E: Debug,
{
  fn draw_string<F: Font>(
        &mut self,
        text: &str,
        position: Point,
        baseline: Baseline,
        font: &F,
        colour: &C,
    ) -> Result<Point, E>
}

The fonts traits should (imo) still be made object-safe, which could be via swapping to methods to grab the associated constants and having the TextRender impl do the rendering (including converting from bits to colours so fonts don't need to be generic over colour), and there might be cases in which dynamic would help but, it's hard to know without playing with em.

And making DrawTarget object safe would mean that iterators would be passed by using dynamic dispatch, which will probably have a higher performance impact (just an untested assumption).

I believe the performance implications of dynamic dispatch are not overly significant, at least with c++ the vtable perfomance was sometimes surprising, but, it seems this may or may not actually be required depending on the font implementation.

... so the font would provide an api that lets it set bits for a given character that is then translated via the renderer. that might take some playing with...

oh, this would pretty much just be Drawable but simpler / mediated by the Display/TextRender impl rather than taking a Display object.

The idea of implementing a TextRender for DrawTargets is interesting and I'll play with it.

(including converting from bits to colours so fonts don't need to be generic over colour, which makes sense i think as fonts are not different per-colour?)

I think I left out some important details in my abbreviated version. TextRenderer is implemented for text style object. These can contain additional colors, e.g. as a background color or to underline the text.

i believe the performance implications of dynamic dispatch are not overly significant, at least with c++ the vtable perfomance was sometimes surprising, but, it seems this may or may not actually be required depending on the font implementation.

That might be the case. One of my goals for e-g 0.8 is to do more testing/benchmarking on actual target hardware to get a better idea about the performance of e-g.

Is there anything left to do on this ticket? I'm a bit tired to read through the comments but it looks like the remaining TODO items can either be moved to new issues as future feature additions (larger font, integer scaling, etc) or marked as complete (improve docs).

@rfuest Right now it looks like everything but TextStyleBuilder implements From<Style>. Was TextStyle left out of this intentionally, or is this something that was missed?

Is there anything left to do on this ticket? I'm a bit tired to read through the comments but it looks like the remaining TODO items can either be moved to new issues as future feature additions (larger font, integer scaling, etc) or marked as complete (improve docs).

I think you are right. I'll move the future features to other issues and close this one.

@rfuest Right now it looks like everything but TextStyleBuilder implements From<Style>. Was TextStyle left out of this intentionally, or is this something that was missed?

No, this was unintentionally missed.

I'm going to close this ticket, as most of it has been implemented/discussed at this point.
I've opened #593 and #594 to track the remaining items.
Thanks for the contributions everyone!

authors: bugadani jamwaffles rfuest ryankurte

repo: embedded-graphics/embedded-graphics


text:
leaderboard v2 - add autoupdate

Seems like we currently need to manually update the MTEB leaderboard (@orionw I believe you fixed the old one. I believe we really only need to restart the space daily)

Yes, definitely! I'm trying to figure out how it get's it data, seems like there's a function in MTEB now that provides the results, is that right? (also cc'ing @x-tabdeveloping). The way I restarted it daily before was by updating the results file in the repo daily and then the results repo would re-start.
If I understand correctly, would the best way to do this be to auto-restart the leaderboard on MTEB merges? Or perhaps MTEB results github merges? I don't see the connection to the results github, but I haven't traced it all the way back yet.

Totally works great :) Do you mind pointing me to that step? I can work out how to get the leaderboard to refresh after it.

@x-tabdeveloping if you have any pointers :)

source: gharchive/issue

authors: KennethEnevoldsen orionw

repo: embeddings-benchmark/mteb

license_type: permissive

license_source: github-api


text:
Add David badge to README

We're going to pass on this.

source: gharchive/pull-request

authors: kriswill lukemelia

repo: ember-cli/ember-cli-deploy

license: mit

license_source: bigquery


text:
addon no longer works when declared as a "dependency" from an addon with v0.1.4 and DOES work with v0.1.3

in _applyDecoratedDescriptor code of the component in built version the decorator is undefined for 0.1.4 and it works for 0.1.3
setup is ember-cached-decorator-polyfill declared as a 'dependency' in a shared addon
decorator used in app that includes the shared addon.
I can create a reproduction if required, but I can confirm it used to work on version 0.1.3

I think the behavior you’re describing would be part of the bug fixed in the cross linked PR.
To me (note: this could be checked with a maintainer), ember-cached-decorator-polyfill should be present in the project that makes use of the cached decorator.
If you write an addon and use the cached decorator in the addon’s code, the polyfill should be in the addon’s dependencies.
If you write an app and use the cached decorator in the app’s code, the polyfill should be in the app’s dependencies.
This allows us to run the Babel plugin only on the code that makes use of the cached decorator.
Unfortunately there was a bug in 0.1.3. When the ember-cached-decorator-polyfill was in the dependencies of an addon, the Babel plugin was not registered to transpile the addon’s code but the host app’s instead.
So, to upgrade to 0.1.4 you would have to:

remove ember-cached-decorator-polyfill from the shared addon (provided you don’t use the cached decorator in the addon)
bump to 0.1.4 in your app AND add ember-cached-decorator-polyfill in the app’s dependencies

@dcyriller I'm trying really hard to not manage the version of cache decorators in all 7+ other apps and addons; that the "bug" of <0.1.4 has enabled us to use it the decorator for.
It's not a maintainable solution to add the decorator to every one of our apps, so with that in mind I will attempt to set it as a peerDependencies and see how far I get.

I hear it is painful for you (and other users) to add the dependency in every one of your apps. When you want to upgrade the polyfill, you have to bump it in 7+ apps.
A possible solution would be to register the babel plugin for both the addon tree and the host app tree. On the plus side, it would solve this issue. On the minus side, it sounds vaguely odd from a performance perspective. Indeed, every app depending on an addon depending on the polyfill would get transpiled with the babel plugin. As more and more addons are starting to use this polyfill (ember-data will start using it in 3.18), it means that more and more apps would get transpiled with the babel plugin.

It's not a maintainable solution to add the decorator to every one of our apps

Sorry, don't want to sound ignorant, but I genuinely don't understand what the problem is? Adding one line to package.json?
The semantics of dependencies, especially for build-time transforms like polyfills, is pretty consistent: when you need it, you need to declare it a dependency. When you need Babel transpilation in your app (all do), the app needs ember-cli-babel. Doesn't help if an addon depends on it, that's only for the addon's concerns. Same for ember-cli-htmlbars, all those polyfills etc. Even for plain imports when using ember-auto-import or Embroider: you can only import what you depend on.

Sorry, don't want to sound ignorant, but I genuinely don't understand what the problem is? Adding one line to package.json?

it's desired that between the 7 (and growing number) of apps that make use of the decorator they all share the same version.
in that scenario adding 1 line to the package json of each app, while doable is long term maintenance heavy. this gets compounded by a number of other packages that would require the same treatment if delivering them through an addon was not possible which brings me to the second point you made

The semantics of dependencies, especially for build-time transforms like polyfills, is pretty consistent: when you need it, you need to declare it a dependency. When you need Babel transpilation in your app (all do), the app needs ember-cli-babel. Doesn't help if an addon depends on it, that's only for the addon's concerns. Same for ember-cli-htmlbars, all those polyfills etc. Even for plain imports when using ember-auto-import or Embroider: you can only import what you depend on.

if I read this correctly importing something from the app that is not declared in the dependencies of the app should not work. while putting Embroider aside for a second, I can 100% say that it does work for all of the packages we're using from lodash-es to other ember addons.
what that allows us to do is have only 1 internal addon that manages the versions of a dozen or so packages and the other apps only depend on that internal addon for updates. this also ensures that we avoid packages overriding themselves with different versions in the monorepo.
for clarity the lodash-es package mentioned above is declared only in the addon as a dependency but used from the apps

authors: dcyriller simonihmig void-mAlex

license: MIT


text:
Fail integration test when the same span is exported more than once

Goal

Testing

Release Notes

WHAT:
WHY:

#1527  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @bidetofevil and the rest of your teammates on  Graphite

Merge activity

Oct 16, 2:58 PM EDT: A user started a stack merge that includes this pull request via Graphite.

repo: embrace-io/embrace-android-sdk


text:
Fix slow startup

Goal

Testing

Release Notes

WHAT:
WHY:
WHO:

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

Current dependencies on/for this PR:

master

PR #391

PR #392

PR #393   👈

This stack of pull requests is managed by Graphite.

Merge activity

Feb 12, 2:44 PM EST: @bidetofevil started a stack merge that includes this pull request via Graphite.


text:
Test Polly with multiple backend stores

Polly needs to be tested across multiple backend stores.

@dvonthenen Can you briefly document the backend store support?

@clintonskitson will get to this shortly

PR https://github.com/emccode/polly/pull/78 submitted for this issue.

Merged supported backing stores

authors: clintonskitson dvonthenen

repo: emccode/polly


text:
How to use 'predict' ?

I see the'predict' in modle.py.
so, running command: aocr predict xx.png ,it said 'open file fail'.
How to use 'predict' ?

See [__main__.py](https://github.com/emedvedev/attention-ocr/blob/master/aocr/__main__.py#L312): after you've trained the model, you can predict by passing the file list to stdin line by line.

repo: emedvedev/attention-ocr


text:
Plot boxed zoom

Hello,
Very happy to make my first contribution here!
This adds boxed zooming feature on plots.
demo: https://www.youtube.com/watch?v=oUSWUgdFBCs
To allow the feature to work I added:

Plot::allow_boxed_zoom(bool). Default true
Plot::boxed_zoom_pointer(PointerButton). Default: Secondary
PlotMemory::last_click_pos_for_zoom: Option<Pos2>, Default None
ScreenTransform::bounds_mut(&mut self) -> &mut PlotBounds

Also changelog has been updated, check.sh is passing. And next time I will make sure to create an issue first.
I had a little non related issue in check.sh so double check for me please.
Regards,

This is a great feature! 👍
I wonder, if instead of a bool yes/no, it would make sense to have different modes?
enum RegionZoom {
   None,     // disallow
   Rect,     // rect/box, like current PR
   XRange,   // only horizontal, along X axis
   YRange,   // only vertical, along Y axis
}

The X/Y ones are for scaling only along one axis:

@emilk tests are passing my side, I updated with all your comments.
Let me know if we need additional update on this.
:+1:

authors: Bromeon nongiach

repo: emilk/egui


text:
epoll_release

Hi, I'm planning to use this. Just wanted to ask if this was still being actively maintained.
Also on a cursory glance, i couldn't find a mapping to epoll_release, which is think is helpful in gracefully shutting down the blocking-wait of epoll event loop (and hence exit that thread) from another (most probably the main) thread ? Otherwise we might have to set a timeout and keep checking some flag which is not optimal. Thanks.

Ah brilliant, thanks - we need reliability and congestion control on top of UDP so I suspect we might be heavily using this rust binding to UDT; nice to know it's active. Thanks !

repo: eminence/udt-rs


text:
[RFE] Set UOR specific mediatype on UOR Manifests

What is the problem you're trying to solve
The UOR manifests need a unique mediatype
Describe the solution you'd like
Set UOR Collection manifests to application.vnd.uor.manifest.v1+json mediatype

@afflom Is this still relevant, or is a custom media type for the manifest config sufficient?

We might want to hold off until the dust settles from this: https://github.com/opencontainers/wg-reference-types/issues/64

looks like they voted to include artifactType in artifact manifests. Not sure what that means for us in this situation.

Closing this. A media type for manifest are specified in the collection-spec repository.

repo: emporous/emporous-go


text:
Emqtt Version 3 Dockerfile

[ ] BUG REPORT
[X] FEATURE REQUEST

FEATURE REQUEST

Missing feature
emqtt version 3 Dockerfile
Justification
Tell us why you would like to see this feature added.
Because it is the latest version of emqtt available.
Workarounds
Are there any workarounds you currently have in place because the feature is missing?
I have created a Dockerfile by myself, I want to see is there any chance of this getting merge or the fixes I have to apply in order to get it merged.
FROM erlang:21.1.1-alpine

RUN apk add build-base git wget

COPY . /emqttd
RUN cd /emqttd \
    && make \
    && mkdir -p /opt && mv /emqttd/_rel/emqttd /opt/emqttd \
    && cd / && rm -rf /emqttd \
    && mv /start.sh /opt/emqttd/start.sh \
    && chmod +x /opt/emqttd/start.sh \
    && ln -s /opt/emqttd/bin/* /usr/local/bin/ \
    # removing fetch deps and build deps
    && apk --purge del .build-deps .fetch-deps \
    && rm -rf /var/cache/apk/*

WORKDIR /opt/emqttd

# start emqttd and initial environments
CMD ["/opt/emqttd/start.sh"]

RUN adduser -D -u 1000 emqtt

RUN chgrp -Rf root /opt/emqttd && chmod -Rf g+w /opt/emqttd \
      && chown -Rf emqtt /opt/emqttd

USER emqtt

VOLUME ["/opt/emqttd/log", "/opt/emqttd/data", "/opt/emqttd/lib", "/opt/emqttd/etc"]

# emqttd will occupy these port:
# - 1883 port for MQTT
# - 8883 port for MQTT(SSL)
# - 8083 for WebSocket/HTTP
# - 8084 for WSS/HTTPS
# - 8080 for mgmt API
# - 18083 for dashboard
# - 4369 for port mapping
# - 6000-6999 for distributed node
EXPOSE 1883 8883 8083 8084 8080 18083 4369 6000-6999

Looks like there is already a 3.x dockerfile here, just that's it's not in master yet: emqx30

Thank you for the code you contributed. As you can see, we already have a branch of emqx30. You can also get the latest image on the docker hub.

authors: Tabrizian cocowalla zhanghongtong

repo: emqx/emqx-docker


text:
feat: ✨ initial rustfmt config and files are formatted

Initial config for rust formatting by using rustfmt (A tool for formatting Rust code according to style guidelines.)
URL : https://github.com/rust-lang/rustfmt

@emrecancorapci  friendly ping for review check*

@onuralpszr Hey. I was on a trip. Just wanted to check the configs. Merging now. Thanks for the contributions.

authors: emrecancorapci onuralpszr

repo: emrecancorapci/krustie


text:
Feat/advance search api

Q
A

Bug fix?
n

New feature?
y

BC breaks?
n

Deprecations?
n

Fixed tickets
n

Expose more endpoints in the search api

Already approved by @Davidmattei

repo: ems-project/EMSCoreBundle


text:
Split brotli package into two

Fix https://github.com/emscripten-forge/recipes/issues/782

Fix #782

To actually fix #782, looks like we'll probably need to remove https://github.com/emscripten-forge/recipes/tree/main/recipes/recipes_emscripten/requests-wasm-polyfill as well?

Let's go with this for now. At some point we may want to use a multi-outputs recipe (and make sure the update bot supports it)

OK thanks for looking into this!

authors: jtpio martinRenou

repo: emscripten-forge/recipes


text:
endatix hub: login screen

Overview:
Complete the basic authentication flow for the Endatix Hub
Scope:

Implement login screen in Endatix Hub - username/password  must have
Issue cookie on successful authentication must have
Show errors on credentials failure  must have
Show client side validation errors  must have
Add sign out option  must have
Redirect all unauthenticated users to Login screen  must have

Acceptance Criteria (AC):

Unauthenticated users are redirected to Login screen
Users can go to Login screen, enter valid credentials and obtain a session
On entering wrong credentials error is shown to the user
On obtaining a successful session, users are redirected to the Home page or previously requested page nice-to-have
Client side validation will check email format and password strength nice-to-have
Logged in users can access protected Endatix APIs using their managed JWT token (managed by Next.js)
On JWT token expiration Endatix Hub users will be asked to re enter their credentials
Users can click sign out button and on success will be redirect to the Login screen

Proposed Solution:
Use Next.js guide (https://nextjs.org/docs/pages/building-your-application/authentication) and make server side request to Endatix API to validate user and issue JWT on success. Protect the Endatix JWT server-side and use recommended Cookie for the Endatix Hub session.
Diagram:

Deliverables:

Login screen => happy path + error modes
Sign Out button
Bonus (basic create user screen) - out of scope
Documentation if required

Risks/Challenges:

Sign out can be a challenge
Lifetime of the Next.js session should be aligned with the lifetime of the JWT. JWT is the root user validation mechanism and Next.js's user validation should be built around that
Safely validating the JWT token server-side on each request - is this the best approach - secure, performance and Next.js recommended practices. I believe it is, but let's think it through again during implementation

Resources:

https://nextjs.org/docs/pages/building-your-application/authentication

Originally posted by @PeterMarinov in https://github.com/endatix/endatix/issues/88#issuecomment-2325004452

Update PR ready - feat: Endatix Hub add Login screen and Session Management, Login and Logout functionality
#118

repo: endatix/endatix


text:
Simplifies the publication of assets to github

Only the contents of the $(ArtifactStagingDirectory)/Release folder get published to Github.
Renamed staging folder for nuget packages to $(ArtifactStagingDirectory)/NuGet

Ah, I assumed that was going to be optionally up to the parent template.

My view was that if we're going to opinionatedly assume that there are NuGet packages to be published, we should also assume they should be part of the release.

Updated to copy NuGet folder into the Release folder.


text:
[Suggestion] Lets remove shorthand examples

As we almost solved all shorthand related problems it might be much better
not to mention it in examples inCONTRIBUTING.md
This will be less confusing for the new contributors
@BiNZGi @captn3m0

In rare cases the shorthand data can be used in changelogTemplate. CONTRIBUTING.md is used as documentation and to stay complete we should leave it there. From my view the remarks above the entries are explaining the details enough. It could be useful to improve the remarks to make less confusion for new contributors. Do you have some ideas?

As long as it’s marked as optional in the docs clearly, don’t see it as a concern. Long-term, I see stripping it out completely in the same PR where we fix the sorting order (manual sorting only). -NemoOn 05-Oct-2022, at 15:31, BiNZGi @.***> wrote:
In rare cases the shorthand data can be used in changelogTemplate. CONTRIBUTING.md is used as documentation and to stay complete we should leave it there. From my view the remarks above the entries are explaining the details enough. It could be useful to improve the remarks to make less confusion for new contributors. Do you have some ideas?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

authors: BiNZGi captn3m0 usta


text:
[godot] New version + update support information

Add version 3.5 released in early august and update the support information of older versions according to the release policy page

And btw thank you for your first contribution :+1: :100: :1st_place_medal: :tada:

authors: Welteam usta


text:
[pan-gp] Added new version GlobalProtect 6.2

Added new release for GlobalProtect.
https://docs.paloaltonetworks.com/globalprotect/6-2/globalprotect-app-release-notes

They just remove it.  😕

:laughing:

authors: adriens mrjcap


text:
Update nscplugin, sbt-scala-native, ... to 0.4.11

About this PR
📦 Updates

org.scala-native:nscplugin
org.scala-native:sbt-scala-native
org.scala-native:scala3lib
org.scala-native:scalalib
org.scala-native:test-interface

from 0.4.4 to 0.4.11
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-native" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scala-native" }
}]

labels: library-update, early-semver-minor, semver-spec-patch, commit-count:1

Superseded by #1150.


text:
Relicense under dual MIT/Apache-2.0

This issue was automatically generated. Feel free to close without ceremony if
you do not agree with re-licensing or if it is not possible for other reasons.
Respond to @cmr with any questions or concerns, or pop over to
#rust-offtopic on IRC to discuss.
You're receiving this because someone (perhaps the project maintainer)
published a crates.io package with the license as "MIT" xor "Apache-2.0" and
the repository field pointing here.
TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that
license is good for interoperation. The MIT license as an add-on can be nice
for GPLv2 projects to use your code.
Why?
The MIT license requires reproducing countless copies of the same copyright
header with different names in the copyright field, for every MIT library in
use. The Apache license does not have this drawback. However, this is not the
primary motivation for me creating these issues. The Apache license also has
protections from patent trolls and an explicit contribution licensing clause.
However, the Apache license is incompatible with GPLv2. This is why Rust is
dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for
GPLv2 compat), and doing so would be wise for this project. This also makes
this crate suitable for inclusion and unrestricted sharing in the Rust
standard distribution and other projects using dual MIT/Apache, such as my
personal ulterior motive, the Robigalia project.
Some ask, "Does this really apply to binary redistributions? Does MIT really
require reproducing the whole thing?" I'm not a lawyer, and I can't give legal
advice, but some Google Android apps include open source attributions using
this interpretation. Others also agree with
it.
But, again, the copyright notice redistribution is not the primary motivation
for the dual-licensing. It's stronger protections to licensees and better
interoperation with the wider Rust ecosystem.
How?
To do this, get explicit approval from each contributor of copyrightable work
(as not all contributions qualify for copyright, due to not being a "creative
work", e.g. a typo fix) and then add the following to your README:
## License

Licensed under either of

 * Apache License, Version 2.0, ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)

at your option.

### Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any
additional terms or conditions.

and in your license headers, if you have them, use the following boilerplate
(based on that used in Rust):
// Copyright 2016 energy-monitor-rs Developers
//
// Licensed under the Apache License, Version 2.0, <LICENSE-APACHE or
// http://apache.org/licenses/LICENSE-2.0> or the MIT license <LICENSE-MIT or
// http://opensource.org/licenses/MIT>, at your option. This file may not be
// copied, modified, or distributed except according to those terms.

It's commonly asked whether license headers are required. I'm not comfortable
making an official recommendation either way, but the Apache license
recommends it in their appendix on how to use the license.
Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these
from the Rust repo for a plain-text
version.
And don't forget to update the license metadata in your Cargo.toml to:
license = "MIT OR Apache-2.0"

I'll be going through projects which agree to be relicensed and have approval
by the necessary contributors and doing this changes, so feel free to leave
the heavy lifting to me!
Contributor checkoff
To agree to relicensing, comment with :
I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

Or, if you're a contributor, you can check the box in this repo next to your
name. My scripts will pick this exact phrase up and check your checkbox, but
I'll come through and manually review this issue later as well.

[ ] @connorimes
[ ] @frewsxcv

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

authors: cmr connorimes frewsxcv

repo: energymon/energy-monitor-rs


text:
Add OpenAI model for in .env template

The chat route does not work without adding:
PUBLIC_OPENAI_MODEL=gpt-3.5-turbo (or whatever model)
to .env
(Other noobs like myself will find this helpful for this to work out of the box.)

Thank for this. I updated the .env.example file to make this more clear. Good catch.

authors: engageintellect kcverde

repo: engageintellect/spatz


text:
WWDMM: player created names are being cutoff in voting screen

someone typed their name as Ronald Reagan. The game displayed this name fine except when it was recorded as a vote. I think this has to do with the way it breaks the line. We should simply limit the name on the login screen to a set amount of characters

To be more clear, what I am referring here is on the vote round results screen when the score is displayed. due to the line break, it pushes the score down and overlaps onto the other name.

I limited the player names to be 15 characters, and increased the height of the votes so that they do not overlap, even if someone's name is Ronald Reagan!

repo: engagementgamelab/emerging-citizens


text:
Unable to reset password

Hi. Some of my colleagues and I are unable to reset our password. After clicking reset password, I never got an email.  I also tried to log on too many times because I couldn't reset my password, and it says that my user is blocked.

Thank you for reporting this problem geojohannes.
I'll try to take a look at the mail service as soon as possible.
Just tested it, and I also do not get any email when trying to reset the password.

Any updates on this @poi33?

I put this on high priority.. yet not given any time to work on it.
I'll try to take a look at this as soon as I'm done with my current assignment. This is not really acceptible to have down for such a long time.

I think i found the issue.
I was able to create an account and ask for a password reset. Tell me if you still have issues.

I tried to reset the password on my current account, and I still don't get any email.

@eithe @geojohannes Could you try to reset your passwords now? We found the issue, but it might not be fixed yet.
@geojohannes i send an email to verify your email, it was a test to see if the accounts and email system worked. No need to pay any attention to that email.

It worked now. Thanks!
However, I can't log on with the same password on my mobile. It says after trying with the same password "Unable to configure verification page."
I had the same bug before, that's what got me to reset the password in the first case.
Do you want me to open a new issue?

Looks like this is an issue with third party cookies, and seems that iOS devices are more prone to this error.
We would have bigger changes to the login system if this is to be prevented.
If you have turned third party cookies off on your device, you can turn these on to avoid htis issue.

Thanks, that worked

authors: eithe geojohannes poi33

repo: enonic/app-office-league


text:
JSON artifacts are not included into the npm module

To enable, pleased do the following

Please add node_module into .npmignore file like this
Please add prepublishOnly job like this
Test installing the package and make sure that CONTRACT.json files are generated under node_modules/@ensdomains/ethregistrar/build/contracts

@makoto the prepublish is pretty much the same. Except of the missing npm compile which isn't necessary.

authors: decanus makoto

repo: ensdomains/ethregistrar


text:
Show type information under selection (not under point)

In Scala If there's a line that says:
myRepository.getMergeCommitParents(myCommit.id).map(_.map(_.id).toList)

The return type getMergeCommitParents(CommitId) is a List[Commit]
The return type of the whole line is List[CommitId]
When I run EnType while on getMergeCommitParents I get a List[Commit]
There's no way I can run EnType on the whole line selection, neither there is a different command that does type information under selection.
You can see what I am referring to in intelliJ by invoking Alt+ = (Ctrl+ Shift+ P for Mac)

I agree, this is a handy feature to have.
Currently the implementation is limited to operate with the word under the cursor, it totally ignores the current selection. But the good news is that the limitation is on Vim's side, we can fix it and make it work on the selection since the server message already supports offset ranges.
I'll give it a try when I get a chance.

@ktonga That is good news indeed. This one feature is literally the only thing keeping me from using vim + ensime on daily basis at work specially with. I'm thrilled to know it's somehow doable, Thank you!
I am happy to contribute if there's some low hanging tasks that I could do.

We tend to track all outstanding work in issues and make use of labels such as help wanted and low-hanging fruit take a look and see if there is one you would like to do. Help is always welcome.

authors: ktonga sherifkandeel

repo: ensime/ensime-vim


text:
Update Project Manager Protocol

Pull Request Description

Closes #1149
Important Notes

Checklist
Please include the following checklist in your PR:

[ ] The documentation has been updated if necessary.
[ ] All code conforms to the Scala, Java, and Rust style guides.
[ ] All documentation and configuration conforms to the markdown and YAML style guides.
[ ] All code has been tested where possible.

Some notes on the current state of protocol update:
I tried to make the update backwards compatible:

There are added message types, but they do not have to be used yet.
The project/open and create were modified, but by adding an optional field, so it is compatible.
New error types were added.

So I will be able to create infrastructure for the new protocol version that will just ignore the unimplemented features and the IDE does not have to change the protocol yet, being able to wait until the features are actually usable.
Installing Components
I propose the following way of handling missing components:

The IDE can by default send an open/create request with installMissingComponents = false.
If the engine is installed, it will just do the thing.
If the engine is not installed, it will result in a specific error: MissingComponentError.
The IDE can check for this error, and for example ask the user '$errorMessage \n Do you want to install the missing engine?'.
If the user answers affirmative, the request is sent again, this time with installMissingComponents = true, triggering installation of the missing component.

(Or if by some coincidence it has been installed in the meantime, it will just proceed with opening).

Progress Bars
The installation may take some time, so the CLI displays progress bars, at least for some of these longer steps.
Each progress bar has a lifecycle of first being initialized with task/started (which contains a UUID for the task), being updated with task/progress-update and finalized with task/finished.
task/finished may include an error (but please note that regardless of the task-related error, the error will also be reported for the original request associated with the task, for example as ComponentInstallationError returned for the project/open request that triggered the installation).
task/progress-update includes a done value, which depending on context may mean for example processed bytes and an optional total value which indicates for example the total expected bytes.
If total is present, it can be used to compute a percentage to show. total may be missing if the total cannot be estimated (like when downloading a file without size specified in headers or just waiting for a lock to be released) - in this case some indeterminate progress bar can be displayed.
Multiple Sub-Tasks
Currently the installation consists of two to four parts that may display a progress bar:

downloading the engine package
extracting the engine package
downloading and extracting the runtime if it was not installed yet

The concept of progress bars is taken directly from the CLI and so these progress bars are treated independently, i.e. with the current architecture the communication will be following:

-> project/open request
<- task/started (download)
many <- task/progress-update (download)
<- task/finished (download)
<- task/started (extracting)
many <- task/progress-update (extracting)
<- task/finished (extracting)
<- project/open response

So while all progress updates happen within the project/open response-request (up to possible reordering of messages), the two sub-tasks of download and extract are completely independent.
Is that okay or do we want to somehow connect them by creating a notion of sub-tasks?
I would suggest staying with that is there for now, as the progress bars can simply show up and disappear, a bit like progress bars associated to background tasks in IntelliJ and if needed the grouping may be added later to keep things simple for now, but I would like to ask for feedback on that.
Progress Unit
Most of the time done means processed bytes, but that is not always the case. If the client knows the unit, it may use that to compute things like throughput in bytes per second. Do you think that the progress updates should include the unit (for now a union of bytes or unknown) making it more meaningful to the client or should that be left out for a later extension?

I don't have any opinions on the protocol itself, but the documentation is very high quality!

I have updated the documentation according to the discussion, highlights:

version is optional for compatibility.
Added better explanation for the 'task' notification workflow.
Added the unit field, currently allowing bytes or other.
Moved total to task/started and changed taskName to relatedOperation.
The errors may include an additional data field, the upgrade error contains data.minimumRequiredVersion.

I think that the only thing left to discuss is how we want to handle engine/list.

authors: iamrecursion radeusgd

repo: enso-org/enso


text:
404 on https://www.laravel-enso.com/login

This is  a bug | question.
Hi,
I see there are some "404" UI Reponses (not actual http responses) on UI when doing:

Login on https://www.laravel-enso.com/login.
Open new tab.
Open again https://www.laravel-enso.com/login (like a existing bookmark).
Look at the tab titles - at some point 404 will be displayed.

Is this because once logged in, the route /login is no longer accessible by authenticated users, therefore 404 (only guests)?
or another:

Be sure you do not have a session opened (logout)
access https://www.laravel-enso.com/
A redirect will be made to /login
In the redirect process the tab will shortly display 404.

Is this normal?

PS: initially I thought it's because of the missing favicon.png, which is missing from resources/images (Missing favicon.png (minor) https://github.com/laravel-enso/enso/issues/382)
Thank you,

fixed with https://github.com/enso-ui/ui/commit/c84b3609d6afc50899c16ebded1ecd23e233ae61

authors: aocneanu robbykrlos

repo: enso-ui/auth


text:
Fix logic for no matching rule

If a source group produces no warnings, failures, or successes, we want to raise an error as that is a no-op and likely indicates a typo in the policy configuration.
This commit fix the check by ensuring the total number of matching rules is computed after the exclude/include from the policy config is applied.
Ref: EC-583

Had to update one of the acceptance tests after all since it was actually relying on the bug to succeed.

repo: enterprise-contract/ec-cli


text:
In some circumstances Umbraco creates relative URLs for a site when the site's hostname matches the hostname of the backoffice

Some customers experience that the URLs send to the Enterspeed Ingest API is relative, even though the site node's Culture and hostname setting only contains one hostname.
A work around is to not use any of the public hostnames for the Umbraco backoffice, but I would suspect that the Enterspeed Integration could be updated to handle this case for the customers.

@Malthebp @msoelvsteen Let me know if you have any insights to this? Also I would like you input on how often we would run into this problem?


text:
TicketClass resource

It would be great if Eventbrite::TicketClass was implemented.
https://www.eventbrite.com/developer/v3/formats/event/#ebapi-std:format-ticket_class

Yeah, it's quite annoying not being able to get ticket data too.
No promises, but I'll try to see if I can implement this feature myself somehow.

It took me 3 months to get around to it, but here we are.

repo: envoy/eventbrite


text:
Update protobuf to v3.9.1.

Built using:
git clone https://github.com/protocolbuffers/protobuf
cd protobuf
git checkout v3.9.1
git clone https://github.com/kwonoj/protobuf-wasm patches
git apply patches/*.patch
sh autogen.sh
emconfigure ./configure CXXFLAGS="-O3"
emmake make
with Emscripten 1.38.46 (fastcomp).
Signed-off-by: Piotr Sikora piotrsikora@google.com

@jplevyak since .wasm files are built using 1.38.46, 1 test is broken under WAVM (see: #213), but we don't exercise tests under WAVM on the CI... Let me know if you prefer that I regenerate everything using 1.38.45, where everything works.

Yes, please regerate so that WAVM is not broken.  I am trying to find the problem.

Did the image work?  I am concerned that the protobuf patch doesn't work cleanly (I have had problems with it before).

Regenerated everything with Emscripten 1.38.45 (fastcomp).

Yes, please regerate so that WAVM is not broken. I am trying to find the problem.

Done.

Did the image work? I am concerned that the protobuf patch doesn't work cleanly (I have had problems with it before).

I didn't use any image. I only updated the Emscripten version number there.

Could you test the resulting image?

Switched back to 1.38.46, since all tests pass with WAVM now.
The Docker image built fine, and I verified that it can regenerate .wasm files using scripts provided in #210.

authors: PiotrSikora jplevyak

repo: envoyproxy/envoy-wasm


text:
Support "envoyproxy/envoy-distroless" image in arm64

Title:  Support "envoyproxy/envoy-distroless" image in arm64
Description:
In the doc, it shows Support "envoyproxy/envoy-distroless" image in arm64.

But in the docker hub, there are no arm64 image.

So , is there something wrong.

hi @yankay this was fixed in https://github.com/envoyproxy/envoy/pull/21134
the docs you posted are for latest - i dont think the 1.20 branch has the fix
im thinking it would probably not be so difficult to backport it

correction to above - i think i misread the issue - there is a fix in the pipeline for this - more information can be seen here #22261

closing as that issue has more information and associatied fixes/backports

authors: phlax yankay

repo: envoyproxy/envoy


text:
Envoy is failing with Bazel@HEAD

https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/3202#0189a9b6-75b5-44c3-b395-c4864f10c8ce
Platform : Linux
Logs:
ERROR: /var/lib/buildkite-agent/.cache/bazel/_bazel_buildkite-agent/88bf210a2b284b3a14eecfe4138c4fc3/external/com_google_protobuf/BUILD.bazel:275:11: Target '@com_google_protobuf//src/google/protobuf/compiler:importer' contains an error and its package is in error and referenced by '@com_google_protobuf//:protobuf'
(02:18:08) ERROR: Analysis of target '//test/integration:filter_manager_integration_test' failed; build aborted: Analysis failed
(02:18:08) INFO: Elapsed time: 7.569s
(02:18:08) INFO: 0 processes.
(02:18:08) ERROR: Build did NOT complete successfully

Steps :
git clone  https://github.com/envoyproxy/envoy.git
git reset 1b01f90c074a410393cea6cb2fdf0ee077416957 --hard
export USE_BAZEL_VERSION=f771739efcdde7b08de46c746d8dd909ae59fc83
bazel test --config=remote-clang-libc++ --config=remote-ci --define=wasm=disabled --jobs=75  //test/common/common/... //test/integration/... //test/exe/...

CC  Greenteam @meteorcloudy

@sgowroji Can you try to bisect and identify which Bazel commit caused the breakage?

A bisect points to https://github.com/bazelbuild/bazel/commit/c061e57a7004a88eeb2f84d094d9a88b56c146b6, which matches the error message:
ERROR: /var/lib/buildkite-agent/.cache/bazel/_bazel_buildkite-agent/88bf210a2b284b3a14eecfe4138c4fc3/external/com_google_protobuf/src/google/protobuf/compiler/BUILD.bazel:140:13: @com_google_protobuf//src/google/protobuf/compiler:protoc_aarch64_test_genrule: no such attribute 'exec_tools' in 'genrule' rule (did you mean 'executable'?)

Yes, you should do this migration: https://github.com/bazelbuild/bazel/issues/19132

closing this as we have now updated the exec_tools throughout the codebase

authors: katre meteorcloudy phlax sgowroji


text:
[ext_proc] let ext_proc filter follows the grpc spec, wait for trailers before continue the filter chain upon last main stream end_stream=true event.

If you are reporting any crash or any potential security issue, do not
open an issue in this repo. Please report the issue via emailing
envoy-security@googlegroups.com where the issue will be triaged appropriately.
Title: One line description
Description:

In Grpc, the trailers carries the grpc-status header terminates a rpc stream. Our current flow ignores the trailers by closeStream and resetStream all together, the later resetStream call would signal the remote server a CANCEL, while clean the sidestream and ignore any possible trailers that might have been sent by ext_proc server.

Instead, for the last de/encode{Headers,data} call, ext_proc filter should fire a half-close (closeStream), and wait until the trailers come back, then call continueProcessing().
In PR #37083 we moved one step towards this goal: split half-close from reset(), but we would like to move the half-close earlier to the filter callbacks, before onDestroy gets called.
Noteworthy that there are special case in GRPC: Headers only response carries grpc-status in response headers, in which case we should proactively close the side stream as well.

Note: The Envoy_collect tool
gathers a tarball with debug logs, config and the following admin
endpoints: /stats, /clusters and /server_info. Please note if there are
privacy concerns, sanitize the data prior to sharing the tarball/pasting.

Admin and Stats Output:

Include the admin output for the following endpoints: /stats,
/clusters, /routes, /server_info. For more information, refer to the
admin endpoint documentation.

Note: If there are privacy concerns, sanitize the data prior to
sharing.

Config:

Include the config used to configure Envoy.

Logs:

Include the access logs and the Envoy logs.

Note: If there are privacy concerns, sanitize the data prior to
sharing.

Call Stack:

If the Envoy binary is crashing, a call stack is required.
Please refer to the Bazel Stack trace documentation.

hey @tyxia/ @yanavlasov could you put a
"no stalebot" mark on this issue?


text:
EDS Clusters: Add Support for Static Endpoint Fallback

Title: EDS Clusters: Add Support for Static Endpoint Fallback
Description
Current Behavior
EDS cluster types currently ignore any statically configured endpoints. When running Envoy in Kubernetes, this could be helpful for falling back to the ClusterIP service for upstreams while waiting for EDS to become available.
Proposed Change
Add support for EDS clusters to consider statically provided endpoints as a fallback mechanism until EDS endpoints are received. This would allow traffic to flow through statically configured endpoints (e.g., ClusterIP services) while bootstrapping until EDS is available and initializes.
Implementation Details
I was thinking on the lines of this following change where we would initialize EDS clusters with static endpoints before starting the EDS subscription:
https://github.com/agrawroh/envoy/blob/main/source/extensions/clusters/eds/eds.cc#L62
void EdsClusterImpl::startPreInit() {
  if (cluster().has_load_assignment()) {
    // Initialize with static endpoints
    onConfigUpdate({std::make_shared<const envoy::config::endpoint::v3::ClusterLoadAssignment>(
                       cluster().load_assignment())},
                   {}, "");
    onPreInitComplete();
  }

  // Continue with regular EDS initialization
  subscription_->start({edsServiceName()});
}

Thoughts on this?

Seems a bit risky, IMHO, as this will silently-fail, the client will take much longer to receive the assignment, and may strain the statically defined endpoints.
If possible, I think this should be solved on the route level, as it also allows some flexibility in terms of rate-limiting when the dynamic cluster has no endpoints or its endpoints are unhealthy.

@adisuissa Thanks for your response! In our use case, having the individual weighted endpoints from EDS is primarily an optimization. The bigger concern is if EDS experiences delays or outages, which is why we currently rely on an aggregated cluster with EDS alongside a statically defined cluster as a fallback. However, this setup cause another set of complications.
For example,

Stateful Sessions no longer function properly, as the aggregated cluster lacks visibility into individual endpoints.
Metrics emission becomes excessive since we now have three clusters for each upstream, which adds unnecessary overhead.

Would it make sense to introduce a feature flag, like enable_static_fallback in eds_config and conditionally implement this behind that flag?

authors: adisuissa agrawroh


text:
gzip filter: support chunked transfer encoding

Title: grpc-web: compress response for service methods with non-streaming response
Description:
I have a setup with a frontend making requests to our backend using grpc/grpc-web[^1] via the envoy grpc-web filter.
Currently a response to a simple request-response service method is never compressed, but this is accepted by the grpc-web client and thus should be possible.
I have enabled the envoy.gzip plugin and added application/grpc-web-text+proto and application/grpc-web-text in content_types.
The content being sent by the grpc-web protocol is Base64 encoded proto bytes[^2], meaning the reduction in response size should be significant.
The request headers:
Host: <host-name>
User-Agent: <user-agent>
Accept: application/grpc-web-text
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: <referer>
authorization: <auth-value>
Content-Type: application/grpc-web-text
X-User-Agent: grpc-web-javascript/0.1
X-Grpc-Web: 1
Content-Length: 12
DNT: 1
Connection: keep-alive
TE: Trailers

The response headers:
HTTP/2.0 200 OK
content-type: application/grpc-web-text+proto
grpc-encoding: identity
grpc-accept-encoding: gzip
x-envoy-upstream-service-time: 83
date: <date>
server: <server>
strict-transport-security: max-age=31536000
X-Firefox-Spdy: h2

The only missing requirement for the gzip filter to compress a response[^3] seems to be a missing content length. Unfortunately I can't see the response returned by the various filters (even with --log-level=trace) so I can't be sure this is what is missing.
Relevant Links

[^1] https://github.com/grpc/grpc-web
[^2] Unless the grpc services are compiled with mode=grpcweb but that completely disables all streaming calls (see README.md)
[^3] https://www.envoyproxy.io/docs/envoy/latest/configuration/http_filters/gzip_filter

@fengli79 any thoughts on this?

It seems that it is not easy to add content-length in grpc_web filter.  encodeHeaders() doesn't have the response data. encodeData() could be called multiple times.

@qiwzhang this seems related to the recent https://github.com/envoyproxy/envoy/issues/6600.

@fengli79 any thoughts on this?

I feel this is more like getting gzip filter support chunked transfer encoding. grpc web filter may write back response multiple time, in case of response streaming. In that case, gzip filter should go ahead to compress the content without the content length, and later on, envoy may chunk them back.

Can this be reopened?

help wanted
same problem

@stanley-cheung

@mjduijn I'm facing the same problem, did you ever come to a resolution on this?

I did not, however I switched jobs and haven't used grpc-web in over a year

@kim-nguyenkhn @wenbozhu @fengli79 @stanley-cheung  Is there an update on this? Would be great to support this so grpc-web responses can be compressed.

Looks like Envoy 1.18 solved this? compression: extended the compression allow compressing when the content length header is not present. This behavior may be temporarily reverted by setting envoy.reloadable_features.enable_compression_without_content_length_header to false.: https://www.envoyproxy.io/docs/envoy/latest/version_history/v1.18.0#new-features

authors: akan annismckenzie anupkrish24 fengli79 htuch kim-nguyenkhn mjduijn qiwzhang sunjayBhatia wenbozhu


text:
[tls] Add a custom listener handshaker for TLS.

Signed-off-by: James Buckland jbuckland@google.com
Commit Message: [tls] Add a custom listener handshaker for TLS.
Additional Description: This CL introduces a mechanism for modifying the behavior a TLS socket uses to handshake. It moves the existing implementation into a default HandshakerImpl and introduces an extension for injecting custom handshaker behavior.
Risk Level: Low, the default handshaking behavior in unmodified Envoy is unchanged.
Testing: All existing unit/integration tests use the default handshaking behavior (as before). The existing handshaker implementation also gains unit tests.
Docs Changes: None -- I think the API comments will generate documentation.
Release Notes: n/a

What's the use case for a custom handshaker?

@rojkov We want to be able to modify TLS termination to perform crypto operations outside of the Envoy binary.

We want to be able to modify TLS termination to perform crypto operations outside of the Envoy binary.

Probably a custom PrivateKeyMethodProvider could be suitable for your needs.

I got the impression PrivateKeyMethodProvider lets you inject behavior before a handshake. My motivation for this change is to override behavior within a handshake.

@ggreenway @PiotrSikora @lizan could you folks take a look at this? Thanks.

Probably a custom PrivateKeyMethodProvider could be suitable for your needs.

For some use cases, yes. But custom handshaker allows you to offload more than just private key operations.

One option for a Handshaker implementation would be to write an integration with https://github.com/cloudflare/gokeyless. Although I don't know if the license actually allows that (it's not a standard open-source license).

/wait

I've added a test in handshaker_test.cc which has an example/reference implementation of a Handshaker which performs its SSL_* method calls in another thread, as an example of (and test of) how the std::move() callbacks for bssl::UniquePtr should work.

Since Handshaker now takes ownership of the bssl::UniquePtr<SSL>, I was able to remove the HandshakerCallbacks for HandOff() and HandBack() (and the initialize() method, and the test demonstrating handoff/handback). I also added a representative handshaker_test.cc test case demonstrating an alternative impl to the Handshaker interface, with behavior it would be difficult to inject in via hooks, i.e. special case error handling in the SSL_ERROR_* space. I think this makes a clearer argument for why someone might want to use this extension point to override the default Handshaker behavior.

I got the impression PrivateKeyMethodProvider lets you inject behavior before a handshake. My motivation for this change is to override behavior within a handshake.

@ambuc: Well, PrivateKeyMethodProviders don't really inject behavior before handshakes, but they override the private key cryptographic operations inside the handshake. We are using them for HW cryptography acceleration, but the basic concept was also designed to work with things like HSM. You can do out-of-process handshake crypto operations (RSA and ECDSA, sign() and decrypt()) in a PrivateKeyMethodProvider: it's just BoringSSL which calls the custom operations stub instead of Envoy.
Private key methods don't allow handshakes without certificates though (it seems that you have that in mind with the requireCertificates() method). Can you tell bit more about the use case you have?

BTW, one interesting use case for this might be writing an external OpenSSL handshaker which could utilize the various existing OpenSSL engines such as engine_pkcs11.

/wait

Closing this PR. Will continue work in https://github.com/envoyproxy/envoy/pull/12571 and a follow-up PR. PTAL at https://github.com/envoyproxy/envoy/pull/12571 instead.

authors: PiotrSikora ambuc ggreenway htuch ipuustin rojkov


text:
tcp: add FilterState hash policy for TcpProxy and other network filters

Adds a new variant to type.v3.HashPolicy to generate a hash from an object in FilterState. This implementation mirrors what already exists for HTTP filters (see RouteAction.HashPolicy.FilterState), and is usable by network filters such as TcpProxy.
Risk Level: low
Testing: none - I could not find any existing tests covering HashPolicyImpl, including tcp_proxy_test... If somebody can point me in the right direction, I'd appreciate the help.
Docs Changes: N/A
Release Notes: added an entry under tcp
Platform Specific Features: N/A
Signed-off-by: Dan Rosen mergeconflict@google.com

attn @rshriram

/assign-from @envoyproxy/first-pass-reviewers

authors: htuch mergeconflict


text:
Bump WAMR version to WAMR-1.1.2

Commit Message: Bump WAMR to WAMR-1.1.2
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

/lgtm deps


text:
quic: remove runtime guard and code for legacy cert handling

Fixes #36612

Code coverage for source/common/quic is lower than limit of 93.6 (93.3) because I removed some covered code. I'll resolve. /wait

may need a main merge for CI though
/retest

ooh crud I was going to ask for a main merge for https://github.com/envoyproxy/envoy/pull/36762 too
@mattklein123 if you see a permafail due to these two conflicting lmk and I'll fix

authors: alyssawilk ggreenway


text:
Fix incorrect dependency preventing remote import

Bazel uses the prefix @com_envoyproxy_protoc_gen_validate to decide whether the Build rule is to be found locally, or remotely. As it was absent before this commit, blaze build would try to resolve //:validate locally and fails.
Fix #555
Fix #557

Looks like this also fixes #557 (5c5e169005dd9b4b70691105b5e95530e7dd5383 specifically).

Looks like this also fixes #557 (5c5e169 specifically).

Added! Thanks.

authors: attilaolah qdii

repo: envoyproxy/protoc-gen-validate


text:
Enyo-2368 Change property name for better readability

Signed-off-by: David Joonho Um david.um@lge.com

Closing in favor of #2456

authors: DavidUM ryanjduffy

repo: enyojs/moonstone


text:
149

closes #149
@h1alexbel take a look, please

Codecov Report
Patch coverage: 100.00% and project coverage change: +0.15 :tada:

Comparison is base (da2bc2c) 85.40% compared to head (9d5bfc8) 85.56%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@             Coverage Diff              @@
##             master     #230      +/-   ##
============================================
+ Coverage     85.40%   85.56%   +0.15%
  Complexity       78       78
============================================
  Files            39       39
  Lines           185      187       +2
============================================
+ Hits            158      160       +2
  Misses           27       27

Impacted Files
Coverage Δ

...cqrs/kafka/consumer/settings/KfConsumerParams.java
100.00% <ø> (ø)

.../main/java/io/github/eocqrs/kafka/data/KfData.java
100.00% <ø> (ø)

...n/java/io/github/eocqrs/kafka/data/KfDataized.java
100.00% <ø> (ø)

...n/java/io/github/eocqrs/kafka/fake/FkConsumer.java
0.00% <ø> (ø)

...n/java/io/github/eocqrs/kafka/fake/FkProducer.java
0.00% <ø> (ø)

...ithub/eocqrs/kafka/parameters/AutoOffsetReset.java
100.00% <ø> (ø)

...github/eocqrs/kafka/parameters/KfAttrEnvelope.java
100.00% <ø> (ø)

.../io/github/eocqrs/kafka/parameters/KfFlexible.java
100.00% <ø> (ø)

...ub/eocqrs/kafka/parameters/KfFlexibleEnvelope.java
70.00% <ø> (ø)

.../kafka/parameters/PartitionAssignmentStrategy.java
100.00% <ø> (ø)

... and 7 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

@rultor merge

@rultor merge

@h1alexbel OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge

@h1alexbel Done! FYI, the full log is here (took me 2min)

@l3r8yJ thanks!

repo: eo-cqrs/eo-kafka


text:
Edpub 1185 automate db updates

Description
Makes the DB update script automatically run if there is a change
Spec
See Ticket: EDPUB-1185

Validation

Build the branch in bamboo and confirm the rds_update lambda does not run
Commit a change to the rds_updates lambda
Rebuild the branch in bamboo and confirm it runs

Change Log
Makes the DB update script automatically run if there is a change

[Add _____](link to commitid)

More discussion to occur during next dev tag up meeting on Feb. 1 to best facilitate management of automated db updates

Blocking this until we investigate more about integrating database updates with CICD. I found https://aws.amazon.com/blogs/opensource/rds-code-change-deployment/ but I'd like to reach out to other NGAP teams/projects to see what their solutions are before we dive to far into a wrong direction

The endpoint used in the pr no longer functions in a compatible way.  This PR should be close.

authors: DavisGauntUAH camposeddie

repo: eosdis-nasa/earthdata-pub-api


text:
[Integration] Error in console and DIAL hangs if to drag&drop folder with chats into another folder

Create folder1, folder2
Create chat and move to folder2
Drag&drop folder2 into folder1 -> error in console appear -> bug
DIAL hangs, need to refresh browser to continue working

Verified on staging successfully

repo: epam/ai-dial-chat


text:
feat(chat-e2e): update playwright v1.48.0

Description:
update playwright v1.48.0
Checklist:

[x] the pull request name complies with Conventional Commits
[x] the pull request name starts with fix(<scope>):, feat(<scope>):, feature(<scope>):, chore(<scope>):, hotfix(<scope>): or e2e(<scope>):. If contains breaking changes then the pull request name must start with fix(<scope>)!:, feat(<scope>)!:, feature(<scope>)!:, chore(<scope>)!:, hotfix(<scope>)!: or e2e(<scope>)!: where <scope> is name of affected project: chat, chat-e2e, overlay, shared, sandbox-overlay, etc.
[ ] the pull request name ends with (Issue #<TICKET_ID>) (comma-separated list of issues)
[x] I confirm that do not share any confidential information like API keys or any other secrets and private URLs

/deploy-review


text:
Upgrade OpenSearch Stack to Latest Stable Version

Pull Request Template
Description
Please include a summary of the change and why it is needed.
Fixes #83
Type of change

[ ] Bug fix (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 not to work as expected)

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce.
Checklist:

[ ] I have performed a self-review of my own code
[ ] I have commented on my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Pull Request contains one commit. I squash my commits.

Screenshots (if appropriate):
Additional context
Add any other context or screenshots about the feature request here.

Fixed in https://github.com/epam/edp-cluster-add-ons/issues/83

repo: epam/edp-cluster-add-ons


text:
Remove setting of Content-Length by default

This is to allow users to use Rack::ContentLength if they wish to set Content-Length by default.
context
Since Rails 5.0, it is noted that Rack::ContentLength is no longer part of the Rack spec.

see https://github.com/rails/rails/commit/56903585a099ab67a7acfaaef0a02db8fe80c450

As such, i think we do not need to set the Content-Length by default too.
In any case, users can simply make use of the Rack::Content-Length to set that if needed (regardless of Rails 5.0 or older)

Thanks for your contribution @mt-kelvintaywl !

cheers @eparreno thanks for making and maintaining this library :)
I was wondering if you'd be making a release soon? :)

authors: eparreno mt-kelvintaywl

repo: eparreno/rack-jwt


text:
Problem with DisplayUsing()

Am I doing something wrong here or is DisplayUsing() not supported?
Works fine outside JSON.
Select::make('Effect', 'kw')
    ->rules('required')
    ->options([
        '0.18' => '0.18',
        '0.25' => '0.25',
        '0.37' => '0.37',
        '0.55' => '0.55',
    ])
    ->help('Effect in kW, only numbers.')
    ->displayUsing(function ($kw) {
        return $kw.' kW';
    }),

Fixed in https://github.com/epartment/nova-dependency-container/commit/dddd8a470d57d0885d6ec2531e6c7cc801d45b58

repo: epartment/nova-dependency-container


text:
translations for v0.2.0

closes #244

Coverage remained the same at 80.096% when pulling d4678b0990e1de8f89e15cf3416df4c9533988e5 on translations/release-0.2.0 into 0094f7970b1a546c0fbd8d8681dcfc68de7fa816 on main.

Coverage remained the same at 80.096% when pulling d4678b0990e1de8f89e15cf3416df4c9533988e5 on translations/release-0.2.0 into 0094f7970b1a546c0fbd8d8681dcfc68de7fa816 on main.

authors: coveralls jeriox

repo: ephios-dev/ephios


text:
Card component

Zeplin: https://zpl.io/agrvXAD https://zpl.io/amynYpe

Essentially card is style component with slots for its different parts.
You MAY use existing componenent as a base. You'll need to dispose carefully of bootstrap styles and perform style checks if you decide so.

References

vuetify - https://vuetifyjs.com/en/components/cards

Confirm design as required.

Task is not remotely close to be finished at the moment.

repo: epicmaxco/vuestic-admin


text:
Set up GTM Properly

Once GTM included into Vuestic it is necessary to enable History Mode to be able to track page transitions.
After History Mode enabled it is necessary to update server config as well.

It's likely not. See GTM docs.
Consult with @NikitaMatveev to test if it's done correctly

authors: alexanderrudnik asvae


text:
UK HPI Home icon on Internet Explorer showing incorrectly

The UK HPI home icon on the main page layout is too big so the text runs on to the next line.
Screenshot attached

For reference, this is how it looks on Chrome and Firefox

@marklunn @MalcolmShazell Any more details on reproducing this? On my IE edge it looks fine. Does this occur on a specific version of IE, or do I need to do something else to provoke it?

Actually, it's OK - I've found that I can reproduce it on IE11. I'll try to work on a fix (other than "user should upgrade their browser" :) )

@marklunn @MalcolmShazell I can't remember if this has been fixed. I'll leave it open, but it would be good to confirm if it's still an open issue.

@ijdickinson I'm afraid it is still displaying the oversized icon in IE11. Unfortunately for us we still have to support win 11 so it will need a fix applied a some point in the future - we can schedule it into the work about to start

@MalcolmShazell We should definitely support IE 11, so yes, we need to keep this open.

displaying correctly in the new app

authors: MalcolmShazell ijdickinson marklunn

repo: epimorphics/ukhpi


text:
My tasks: missing skip button when moderating multiple tasks

Steps to reproduce:

Navigate to a user's My tasks page (containing multiple tasks)
Click the blue select button on three tasks, then click the moderate selected button
According to eqos-1898 we should expect to see "XofYtasks selected" and "Skip". But Skip is currently missing

@abidingotter is the test case true, is there meant to be a skip button?

There used to be a prev / next... See screenshot

Fixed

authors: abidingotter doolse mrblippy

repo: equella/Equella


text:
error fetching ISO via minio client

There have been some reports that the latest minio client is causing the ISO to fail to download correctly.
It has been suggested that a fix is to replace https://github.com/equinix/terraform-metal-vsphere/blob/b96face0faa50cf565281e8be5aac6c1e9fc1920/templates/download_vcenter.sh#L32 with a tagged release, for example:
curl -Lo mc https://dl.min.io/client/mc/release/linux-amd64/archive/mc.RELEASE.2022-01-07T06-01-38Z

Currently awaiting confirmation that this is a real bug or working solution.
Regardless, pinning to a fixed version of assets will provide greater reliability - verifying that asset against a known checksum would be even better.

Change is good.  I just verified with a fresh pull + change as above

The upstream issue is https://github.com/minio/mc/issues/3938

authors: displague michaelheinsfo

repo: equinix/terraform-metal-vsphere


text:
chore(main): release 1.4.1

:robot: I have created a release beep boop
1.4.1 (2024-01-09)
Other

Python 3.12 support (#21) (0571ea8)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/equinor/atmos-validation/releases/tag/v1.4.1 :sunflower:

repo: equinor/atmos-validation


text:
Refactor Navigation App launcher to Typescript

Create typings for [Navigation App launcher](https://eds.equinor.com/components/navigation-app launcher/)

Closing this as we don’t have an App Launcher component

repo: equinor/design-system


text:
Investigate predefined options for "Related content/More on this topic"

For things to look consistent across pages and articles it might be a good idea to use some predefined options for the related content header instead of using a text field.

Investigate
Define header options

We decided to not go with this.

repo: equinor/energyvision