New display() and get_prev_menu_component_num() method

The get_prev_menu_component_num() method returns the previous menu index. This is useful for detecting which direction the user is scrolling. I am using this method in a project to print an arrow on the current row selection in an LCD menu.
The display() method just makes sense. In the current library implementation, there is no easy way to draw sub menu's in a different way. By tying a callback method that is responsible for drawing in with a menu object it makes it super easy to draw each menu differently. Furthermore, in my implementation, thanks to NULL pointer checking and default arguments, my changes will not break any code written with the current version of the library.
Let me know what you think,
Aaron

I added some checks for empty_menu_components arrays inside Menu object. Without this, program crashes with a NULL pointer deference if activate(), next(), or prev() is called on an empty Menu.

Thanks for the pull request. This is an interesting idea. I need to take a good look to see if this is generic enough and whether it has a negative impact on library size.

Feel free. The additional overhead for each menu object is only a uint8_t and a function pointer, only a few bytes.

Just a question:
when next() and prev() is called on a menu where _cur_menu_component_num already is at  the end limit; _prev_menu_component_num will be equal to _cur_menu_component_num, is this intentional?
@jonblack  Oh, and another thing.. now that ASCII displays are becoming more and more rare. It would be nice to have a (polymorphic) hookup for the menuitems to draw themselves. Think of it as a get_composite_name() but for graphics.
The default implementation would do nothing, Because we can't assume anything about the display API. But the end users can extend the base classes, and implement the proper graphics calls.
So the user defined display() (mentioned above), could prepare the display, set position and call MenuComponent::draw(...) on the items it wants to display.

It would be nice to have a (polymorphic) hookup for the menuitems to draw themselves. Think of it as a get_composite_name() but for graphics.

I was thinking the same. The broad view is that the library should provide an interface for all rendering, but leave it up to the client to determine how it's done.

The default implementation would do nothing, Because we can't assume anything about the display API. But the end users can extend the base classes, and implement the proper graphics calls.
So the user defined display() (mentioned above), could prepare the display, draw some decorations, set position and call MenuComponent::render(...) on the items it wants to display.
So my question is: can we add a virtual void MenuComponent::render() {} method?

So there'd be two ways to customise rendering: one via a callback in display, and the other by extending a MenuItem class? I think it's possible to define one solid interface for this (be it via callbacks or inheritance), and I think it's confusing to use both. Can you think of a specific need for both approaches?
I think I'm leaning toward extending because we can encapsulate the buffer, which is nice. This makes it easier to move away from String.
We should also add automatic rendering. By that I mean that whenever the menu state changes, the rendering methods are called. This means the client in most cases doesn't need to explicitly call display (although it is still needed). Perhaps we need a way to signal that the menu doesn't need re-rendering when the state changes, but that's an optimisation to consider later.

So there'd be two ways to customise rendering: one via a callback in display, and the other by extending a MenuItem class? I think it's possible to define one solid interface for this (be it via callbacks or inheritance), and I think it's confusing to use both. Can you think of a specific need for both approaches?

As I imagined the gist of this PR, the display() callback would display/render the content of a menu, while Menu::render() will just display the title of a (sub)menu. I.e. display() is iterating over the current menu, calling render() on the items. This is assuming we're talking about graphical displays.
For ASCII displays, display() would just iterate over each item, calling get_composite_name() and printing that.

Just a question:
when next() or prev() are called on a menu where _cur_menu_component_num already is at the end limit; _prev_menu_component_num will become equal to _cur_menu_component_num, is this intentional?

This is intentional,it lets you distinguish between reaching the end of the menu while scrolling, versus people reaching the end of the menu while scrolling and calling next() again.

So my question is: can we add a virtual void MenuComponent::render() {} method?

I personally am against this, I think a callback is the way to go. First of all, every time someone wants to create a menu that is drawn differently they will need to subclass the Menu class. To people just getting started with programming (ie. many Arduino users), a callback makes much more sense, then working with OOP ideas such as inheritance and polymorphism and creating a bunch of derived classes.
Furthermore, drawing the menu requires the subclass having knowledge of how to draw to the LCD/Display and would require mixing display specific implementation details into a class that should only be for managing menus. Thus, simply implementing a virtual display() method would probably not be sufficient. The subclass would also have to override the Menu constructor to take additional arguments (such as an LCD object) and store it in some new attribute the user would add in their Menu subclass. And if you truly wanted to stick with OOP, you would make an LCDMenu subclass (with the constructor to take the LCD object), then have subclasses of this that would implement a display method(). To me this sounds like an unnecessary hassle, nobody wants to create 3 subclasses to accomplish what could be done with one callback method.

I hear what you are saying, and it's true every bit. But I am also much more willing to take shortcuts in an Arduino sketch that I would not dream of using professionally. One of those shortcuts would be to use global data. Eg. a global reference to the current LCD object. So most of the hassle you mentioned can be solved the quick and dirty way. The trick is not to let the quick and dirty hacks spill over to the reusable library components.
And about the display callback vs a render method: I didn't imagine that the virtual render method should replace the display callback, I suggested that an empty render method should be part of the MenuComponent so that users could  extend on it if they needed. (That was at least my mindset in the first post, it seems like I drifted off a bit in the second)
Let's look at an example: if you look at the current  serial_nav.ino example you will see that there is a custom menuitem that has two modes. In one mode it just displays name+value and in the other it displays some ASCII graphics together with a value.
If I wanted to replace the ASCII graphics with proper graphics i would be hesitant to place that block of code in the display() callback because it is so inherently tied to the internal state of the menuitem itself.
It would be better to make a local, custom subclass that implements the render() method.
The display() callback would then need to call the render method when it wants to display that menuitem.
If all of the MenuItems used by the sketch are objects that implements the render method the display() callback would be quite simple. Yes, that's an overhead cost in programming effort. But its just a few lines for the basic, plain text, components (MenuItem and Menu)

I tidied some things up so it conforms to the existing code and have updated the serial_nav example to use the new display method.
I've left out the idea of a polymorphic method for rendering menu items. I think the problem should be solved but I agree with @wizard97 that the OOP route is a bit tedious.

Awesome, thanks! Now I no longer need to use a custom version of the library for my project.

You sure can. :) To be clear, it's not released yet so won't show up in the Arduino Library Manager.

Any suggestion on how to write a display function that behaves differently depending on the type of the MenuComponent? I would, for example, like to add graphics to the edit mode of the NumericMenuItems.
It would be possible yo use typeid(aMenuComponent).name() if arduino didn't use -fno-rtti when compiling.
One possibility would be to use a switch:case over each know MenuComponent instance, but that's such a hack.

Why not just register a different display callback with each different type of MenuComponent that needs to be drawn differently? That was the purpose with this PR. Say if there are three types of MenuComponents that need to be drawn differently, I would write 3 different callback functions and register each one with the appropriate MenuComponent.

Wait a minute, isn't the display function set per Menu object? So all MenuItems are under one Menu is using the same display function? That's what I'm seeing in the current code at least.
Maybe that wasn't your intention.

Sorry, you are absolutely correct, I forgot how the library worked for a moment. Yeah, if the compiler supports it we could use some C++ rtti features.
Either way though, I think we might need a better solution. It violates OOP principles to have code that looks like:
MenuItem *o;
if (o instanceof MenuItemA) {
// Do something
} else if (o instanceof MenuItemB) {
// Do something else
} else if (o instanceof MenuItemC) {
// Do something else
}

Obviously this is pseudocode, but it will get really messy as more sublcasses are added. Since on the Arduino platform it is unlikely that there will be to many MenuItem subclasses it might not be an issue, but it is definitely something to consider.
I think the correct way to do it is create a polymorphic interface that MenuItem objects must follow. Maybe functions like const char *getItemData() or const char *getDisplayData() which will always be implemented by MenuItem subclasses, and thus it will always be safe to call (no downwards casting). This way, it abstracts away the display callback having to know details about the MenuItem subclasses, all it needs to know is the interface.

I think the correct way to do it is create a polymorphic interface that MenuItem objects must follow.

Hm, this sounds familiar. Almost like the polymorphic render() method i proposed some time back, but now with a decoupling between the lcd drawing code and the MenuItem itself.
The question is if it's possible to specify a datatype (char* in your example) that can contain enough information to draw the menuitem, but still have a minimal footprint.
I'd like to be able to render MenuItems with lots of quirks, like:

value dependent colour, when the value is outside some range it should be painted red.
graphics, a slider is specially useful when editing values.
possibly some simple animation, like a flashing cursor (if the lcd supports it)

By coupling the raw lcd drawing code together with the MenuItem in a render() method I gained some creative freedom and simplicity (not restrained by anything but the capabilities of the lcd itself). It might not be the ideal OOP solution and it does require some boilerplate code for the lcd specific subclasses. ssd1306 example, st7735 example.
I'm not proposing that we must implement a render() like method, I'm not even sure it's the best way forward. I do, however, feel that it is important to discuss all options.

I looked at your example and it definitely makes it easy to draw MenuItems differently. However, the extern oled business does not look very elegant. Obviously if you moved it in the .ino file you wouldn't need the extern, but regardless I don't think it is the best practice to make the class rely on certain objects being defined globally.
I just can't think of a clean way to let a MenuItem have a function that when called from the display() callback draws the particular MenuItem. Depending on the MenuItem subclass it could need different arguments. You limit your arguments to being virtual void render(int x, int y) const {};, this is not generic.
I strongly believe that we should not make people subclass Menu and MenuItem to contain LCD displaying logic. Your solution avoided this by relying on classes having access to globally defined LCD objects, but I still think there is a cleaner solution.
Perhaps I can modify you solution a bit to solve the issues I have with it. We could have something like a virtual drawItem() function defined in MenuItem which would be called from within the Menu display() callback function. The drawItem function could take a void pointer as an argument, that way you could pass it whatever data/arguemnts/LCD objects you want (you might have to pack it in a struct). This would work pretty well as it is generic and would allow the user to pass whatever they wanted to each.
In your particular SSD1306 example you would pass something like:
struct displayItemData
{
int x;
int y;
U8GLIB_SSD1306_128X64 *oled;
}

This would be cast to a void pointer, then from within the displayItem() function cast back into a struct displayItemData. This works great because I could equally pass something like:
struct displayItemData
{
char *foo;
int line_num;
LiquidCrystal *lcd;
}

I would not have to modify the library at all, all I would have to do is subclass the abstract MenuItem class and implement the displayItem(void *data).

@eadf raises a good point about trying to render MenuComponent's differently. The display() callback does make this difficult. I agree with @wizard97 that using rtti information to decide how to draw should be avoided. In fact, I go as far to say that if that's what people start doing, it's a sign of an inflexible design.
I'm beginning to think we need to decouple drawing from the components. The visitor design pattern is perfect for this. Users of the library can create custom components and custom drawing without interfering with one another.
There are some concerns to this approach:

Users need to subclass to provide drawing.
Can we provide some default implementations?
Highly likely to be less efficient in terms of both memory use and processing

The same approach could also be used for when items (and menus for #20) are selected.
I'm really interested to know what you both think.

I've implemented a prototype using the visitor pattern and it works really well. Here's the gist of it:
All clients need to subclass the following class. This is the Visitor part of the design pattern.
class MenuComponentRenderer
{
public:
    virtual void render_menu_item(MenuItem const* cp_menu_item) = 0;
    virtual void render_back_menu_item(BackMenuItem const* cp_menu_item) = 0;
    virtual void render_numeric_menu_item(NumericMenuItem const* cp_menu_item) = 0;
    virtual void render_menu(Menu const* cp_menu) = 0;
};

All MenuComponent's now have:
virtual void render(MenuComponentRenderer* renderer) = 0;

Where the concrete component calls the correct method on the renderer. For example, the NumericMenuItem's implementation looks like this:
void NumericMenuItem::render(MenuComponentRenderer* renderer)
{
    renderer->render_numeric_menu_item(this);
}

Because the renderer has a method for each concrete type, it has access to the concrete type's data. This is super-useful!
The on_display callback is still used. This allows the client to customise what it displayed. It would be the whole menu or just a single item. The requirement is that in the callback they use their subclass of MenuComponentRenderer to render the items:
class MyRenderer : public MenuComponentRenderer
{
    virtual void render_menu_item(MenuItem const* cp_menu_item)
    {
        Serial.print(cp_menu_item->get_name());
    }

    virtual void render_back_menu_item(BackMenuItem const* cp_menu_item)
    {
        Serial.print(cp_menu_item->get_name());
    }

    virtual void render_numeric_menu_item(NumericMenuItem const* cp_menu_item)
    {
        String buffer;
        Serial.print(cp_menu_item->get_composite_name(buffer));
    }

    virtual void render_menu(Menu const* cp_menu)
    {
        Serial.print(cp_menu->get_name());
    }
};

MyRenderer my_renderer;

void display_menu(Menu* p_menu)
{
    Serial.print("\nCurrent menu name: ");
    Serial.println(p_menu->get_name());
    String buffer;
    MenuComponent const* cp_menu_sel = p_menu->get_current_component();
    for (int i = 0; i < p_menu->get_num_menu_components(); ++i)
    {
        MenuComponent* cp_m_comp = const_cast<MenuComponent*>(p_menu->get_menu_component(i));
        cp_m_comp->render(&my_renderer);
        if (cp_menu_sel == cp_m_comp)
            Serial.print("<<< ");
        Serial.println("");
    }
}

I still have a few more improvements to make before committing it to a feature branch so you can take a look. Here's what I'm thinking:

Remove the on_display callback and provide a render method in the renderer interface which is called from MenuSystem::display. This makes the renderer completely responsible for rendering.
Remove get_composite_name. This can be achieved in the custom renderer. No more String! yay!
const all of the display/rendering methods. Rendering should never allow state change.
Make items away of whether or not they are currently selected. This makes it easier for render methods to highlight the item.

I hope this makes sense and I haven't missed anything out.

I think the visitor pattern does a great job of handling the displaying of different subclasses of MenuComponent's. It also makes it easy to add custom subclasses of MenuComponents by subclassing the  MenuComponentRenderer.
I do have one big issue that I mentioned several comments ago. In many cases a MenuComponent does not have enough information to draw itself when the appropriate render method from MenuComponentRenderer is called. I will give you an example. In my current project I have a 16x2 LCD screen that can only display two rows at once. In your current implementation when render is called on a MenuComponent, the render_xxx method (from MenuComponentRenderer) will have no idea if it needs to draw to the first row or the second row the LCD, this is not an issue with the Serial monitor example you gave above.
The only way to accomplish this would to store some sort of state information inside the MenuComponentRenderer subclass which could get quite complicated as it would also need to know when certain actions such as back() or select() was called on the MenuSystem.
The point of my display callback PR, was the display() method would supervise the rendering of the MenuComponent items. Since the display callback had access to all the MenuComponents it could easily determine things such as what row on the LCD a particular MenuComponent should be drawn. This is no longer trivial with your current changes.
Hope that made sense, let me know if you can find a clean way to resolve my concerns.

Thanks for the feedback.
Does a MenuComponent need to know that? Doesn't the display callback (or Renderer::render()) decide what needs to be rendered while the render_xxx decides how its concrete component is renderered?
Here's something I wrote this morning which uses the propose Renderer::render instead of a display callback. Really it's the same thing except the code is part of the renderer.
class MyRenderer : public MenuComponentRenderer
{
    virtual bool render(Menu const* cp_menu)
    {
        Serial.print("\nCurrent menu name: ");
        Serial.println(cp_menu->get_name());
        String buffer;
        MenuComponent const* cp_menu_sel = cp_menu->get_current_component();
        for (int i = 0; i < cp_menu->get_num_menu_components(); ++i)
        {
            MenuComponent* cp_m_comp = const_cast<MenuComponent*>(cp_menu->get_menu_component(i));
            cp_m_comp->render(this);

            if (cp_menu_sel == cp_m_comp)
                Serial.print("<<< ");
            Serial.println("");
        }
    }

    virtual void render_menu_item(MenuItem const* cp_menu_item)
    {
        Serial.print(cp_menu_item->get_name());
    }

    virtual void render_back_menu_item(BackMenuItem const* cp_menu_item)
    {
        Serial.print(cp_menu_item->get_name());
    }

    virtual void render_numeric_menu_item(NumericMenuItem const* cp_menu_item)
    {
        String buffer;
        Serial.print(cp_menu_item->get_composite_name(buffer));
    }

    virtual void render_menu(Menu const* cp_menu)
    {
        Serial.print(cp_menu->get_name());
    }
};

The render method orchestrates all the rendering, deciding what is rendered; it delegates how the components are rendered to the other renderer methods via the double dispatch system of the visitor pattern (which imo is kinda cool).
That render method could be anything. If you can only display two components at a time, it will be different. You're right that this would mean storing state in the renderer but that seems like the right place for it. The menu system shouldn't know anything about the implementation details of rendering.
In the callback only approach how would you manage the state for a two line LCD?

@wizard97, @eadf
I've pushed a branch called render which contains a bunch of changes with the visitor solution. The serial_nav example has been updated to show it working.
It was not as trivial as I'd hoped to get the CustomNumericMenuItem to work. Custom components are quite an advanced use-case though. I expect most people will want to customise the rendering for existing componenets.
The code is super messy and there are lots of TODO's scattered around. The branch is there so you can take a look and let me know if the idea is silly. :smile:
I'll wait for feedback before doing anything else with this.

Maybe one of us is misunderstanding each other. Based on what you wrote, here is how I understand how it works.

MenuSystem::display() is called which calls MyRenderer::render() for the current menu.
MyRenderer::render() figures out which components need to be drawn, and calls render() on all of them.
The corresponding render_xxx() is then called for each MenuComponent, and each one draws the particular item.

Is this correct?
If so, my concern comes between steps 2 and 3. In the case of my LCD example where I call MenuComponent::render() twice (since I have 2 rows), I have no clean way to pass arguments into the  render_xxx() method, particularly arguments on what row of the LCD to draw to. The Renderer::render() can only tell menu items to draw themselves, it can't directly pass it information on how to render (such as location or row number). The only way would be to store arguments in class attributes of MyRenderer right before I call render() on the MenuComponent. This isn't a huge deal now that I think about it more, but it is something to think about. Other than that though, I think you solution is quite good.
You asked what my approach would be. Clearly you are an experienced OOP. Sometimes though I feel it is better to sacrifice some OOP ideals for a solution that simpler and has less overhead (we are programming microcontrollers after all). I would avoid the visitor class, not because it isn't a clean solution, but because it adds an extra layer of overhead and makes the barriers to entry for using this library higher (there isn't even documentation at this point). All I would do is make a MenuComponent::render(void *args) that is virtual and the user would implement. When the display_callback fires, it will call the render method directly for the correct MenuComponents. This way the display callback can directly communicate with the method that is actually doing the rendering for the MenuItem. For my LCD example I would pass in something like:
struct RenderArgs
{
LiquidCrystal *lcd;
int row_num;
}

This way, my rendering logic is limited to only one method that is a subclass of the particular MenuItem.
Obviously this is your library. Your solution is certainly quite good, but I just want to weigh in before you make the final decision.

Maybe one of us is misunderstanding each other.

You seem to understand me very well. I think I misunderstood you but it's a lot clearer now: although render can determine what needs to be drawn, it can't tell render_xxx anything about how to draw it, and in some cases render_xxx doesn't know itself.
You're right that this is something to take into consideration but it can indeed be solved by giving the renderer more information about drawing. I'm not sure if that will become convoluted.

You asked what my approach would be.

This idea crossed my mind as well. I'm not sure if the overhead is an issue but it's an understandable assumption; the entry barrier is indeed greater. That said, I think the separation of concerns makes sense.
I'm still leaning towards visitor because it's a clean solution but I'll implement the render method and see how it feels. I also have a two row LCD display so I can implement your use case in both methods to get a good overview. If you have some code lying around that'd be a big help.

there isn't even documentation at this point

Yeah this is a problem that I'm going to address before the next release regardless of the solution. This is issue #34.

Obviously this is your library. Your solution is certainly quite good, but I just want to weigh in before you make the final decision.

Correct but I want this library to be useful for everyone and bouncing ideas around like this really helps. Thanks!

I've taken a quick look at implementing a variadic render method and I'm not a fan:

Using a c-style implementation (e.g. render(int n_args, ...); or the style proposed (e.g. render(void *args);) offer no type-safety: the compiler will not be able to check that the variadic arguments are being used correctly;
Using C++11's variadic templates provide type-safety but require either a recursive implementation or something like a lambda function to access the variable arguments. I have trouble understanding this when I read it (perhaps I don't understand it), so beginners will really struggle.

So far I don't think variadic arguments are meant for solving the problem we have. It's nice that it means overriding one method, but I think it ends up either more complex (variadic templates) or unsafe (c-style ...).
There is still an element of 'unsafety' in the visitor pattern when implementing the render_xxx method for a custom menu component (a static_cast is required) but I find that much easier to understand.
Feel free to correct me on anything I've written above.
I'll concentrate on replicating your use-case with the visitor pattern for now to see if anything more can be done for giving the render functions more information.

In many cases I would agree it could be dangerous to pass something like (void *args), I think the issue is less significant than you think. Since you are using it to pass in arguments, all MenuItems' render(void *args) must accept the same type for args. It wouldn't make sense to pass in different types under different circumstances. Thus inside the proposed render(void *args), you will always cast the void pointer into the same type, and for this reason I don't think this issue is the real reason to not consider this implementation.
To go back to my LCD use case, all render(void *args) would take this:
struct RenderArgs
{
    LiquidCrystal *lcd;
    int row_num;
};

Never would there be a case where I wouldn't pass this in, or else I would loose the whole polymorphic interface that the render method is providing. As long as this is followed, the following downcast inside render will always be safe:
void render(void *args)
{
   struct RenderArgs *ra = (* struct RenderArgs)args;
  // use ra below
}

I would completely agree with your concern if there was a use case where different types were being passed in to args, but I personally can't think of one. In my opinion the real questions to consider when comparing this to your design are the following (from most important to least important):

Is it more or less versatile that your visitor pattern?
For a beginning programmer (beginning Arduino user), what is more intuitive?
Which requires less boilerplate?
Which is easier to debug?
Which has a smaller footprint?

I might of forgotten some questions, but here is how I would answer each one:

Up for debate
Depends what is harder for beginners: C++ subclassing or working with C pointers
I would argue my design requires less
Could go either way (kinda relates back to 2.)
Probably my design by an insignificant amount

I would love to hear your opinion.

Here's how I would answer those questions. Note I'm referring to it as "the void* args" approach vs "the visitor approach" because otherwise it sounds like it's you against me :smile:

Agree. This is up for debate and I think you'd probably get a split depending on developers' preferred programming style.
Both solutions require subclassing (subclassing a component vs a renderer) and pointers (void argument pointer vs renderer pointer). I also want to avoid focusing too much on beginners. Subclassing and pointers are standard concepts in programming. We can help them with good documentation;
The void* args approach requires subclassing a component to override render; the visitor approach required overriding the renderer class. When multiple components are used, the void* args approach requires more subclassing. When custom menu components are used, the void* args method doesn't change much but the visitor method requires subclassing a component as well. So I disagree that the void* args approach requires less boiler plate code.
Agree.
Depends. Subclassing might play a big role and in this. Depending on the components used, the void* args approach might need more subclasses. Really hard to say.

What makes this really hard is that neither approach stands out and it makes it hard to make a decision. I'm still leaning towards the visitor approach (sorry) but I want to check the difference between memory use because if it's a big difference, the decision is made for me. The serial_nav example using the visitor approach comes out at the following (this is in the renderer branch):
AVR Memory Usage
----------------
Device: atmega328p

Program:   10980 bytes (33.5% Full)
(.text + .data + .bootloader)

Data:       1003 bytes (49.0% Full)
(.data + .bss + .noinit)

The data part is because of the strings in the example so that can be ignored, but the program size is quite high. Issue #35 will improve this (e.g. using int instead of float for NumericMenuItem frees up 2k) but that's besides the point. I'll get this working with the void* args approach and see where we stand.
On another note, I tried to hook up an LCD to re-create your use case yesterday but the display seems to be broken and I don't have another. :disappointed:

I've implemented the void* arg variant in the render_method_only branch. Can you check if it's what you were expecting? In any case, your assumption about memory use was spot on:
AVR Memory Usage
----------------
Device: atmega328p

Program:   10780 bytes (32.9% Full)
(.text + .data + .bootloader)

Data:       1027 bytes (50.1% Full)
(.data + .bss + .noinit)

It uses 0.6% less memory. :smile:

Well I guess that answers it for you :)
I looked at your new branch and it is exactly what I was thinking. You also showed how a NULL pointer is passed in the case you don't need any arguments passed to the render function.
As for your LCD, did you play around with the contrast pot? When mine don't work it is usually because I forgot to dial in the contrast.

It uses 0.6% less memory. Better but indeed insignificant.
Yeah, I knew  it wouldn't be much less. I think that 0.6% is coming mostly from the vtable footprint in the visitor class.

Anyways, your mind seems to be made up. Before you make your final decision, I would like to hear input from other people using the library and see what they think.

As for your LCD, did you play around with the contrast pot?

First thing I tried :smile: . The back of the display was REALLY hot, so I think it's busted. I'll order one soon. I need a new soldering iron as well anyway.

Anyways, your mind seems to be made up. Before you make your final decision, I would like to hear input from other people using the library and see what they think.

Yeah my mind is mostly made up but I'd love to hear from others as well. Have to wait and see. I've made improvements to the renderer branch and it's looking really nice now.

I've merged the renderer branch with master now. It's pretty much complete, although the examples still need updating. I'll do that when other issues are implemented. It's a bit more time consuming because I need to hook up components for it :(

First thing I tried 😄 . The back of the display was REALLY hot, so I think it's busted. I'll order one soon. I need a new soldering iron as well anyway.

Does not sound like a great sign, at least no magic smoke :)

I've merged the renderer branch with master now. It's pretty much complete, although the examples still need updating.

Yeah good examples are definitely a necessity, when I get the chance I might make an 2 row LCD example. No promises though.
Thanks again!


Upgrade from edgetpu to pycoral

Hi !
The EdgeTPU library is deprecated ; can you please upgrade to the new PyCoral API ?
Thanks !

Hi. I'll try to change this code, but I have no much time right now. You can see newer version here - https://github.com/step305/pyFaceRec_jetson_nano


fix(blackbox): make capability setting idempotent

Recently, the "Ensure blackbox exporter binary has cap_net_raw capability" task has reported a change for every pipeline run. This PR contains two changes to fix this behavior.

An old bug in community.general.capabilities, which is caused by naive comparison between requested state and observed state, will indicate a change if the operation is anything besides =. This PR changes from cap_net_raw+ep to cap_net_raw=ep to fix this.

A recent PR set changed_when: "'molecule-idempotence-notest' not in ansible_skip_tags", which translates to changed_when: true, causing this task to appear as changed no matter what. This PR removes this line.

With these changes, our pipeline reports no change if the cap_net_raw is as wanted, and reports change otherwise.

This wouldn't case Prometheus to restart, only the blackbox_exporter.

This needs a DCO sign-off. You can use git commit -s --amend to add it.

I noticed some idempotence checks failed. Previously, those tests would en effect have changed_when: false, as molecule-idempotence-notest was part of ansible_skip_tags in Molecule's idempotence checks.
I just added molecule-idempotence-notest as part of the tags, in order to skip this task completely. Hopefully, the effect should be the same as before.

The failing CI tests will be fixed with #440


Proposal details: handle selectable text and hyperlinks for description.

🗃 Github Issue Or Explanation for this PR. (What is it supposed to do and Why is needed)
#951
✅ Checklist

[x] Github issue details are up to date for people to QA.
[x] I have tested all my changes.

🕵♂ Notes for Code Reviewer
New widget added not sure if it must be a global component.
Note: url pattern regex requires to be improved
🙈 Screenshots

### 👯♀ Paired with
"nobody"

Was just looking at this package doing this
https://pub.dev/packages/flutter_linkify
But doing it ourselves has some advantages also

Was just looking at this package doing this
https://pub.dev/packages/flutter_linkify

I will check the package, but my approach only needs to improve the REGEX.

But doing it ourselves has some advantages also

Yes, In general, I'm not a big fan of using libraries if it's something I can do myself.

Nice Raul, I really like this feature. I did notice that if we have a word follow by a "." te color change even if is not a link.

Si literalmente publique este issue con mi solución en el dev channel, tambien lo puse la descripcion del PR.
Es el Regex que detecta un url, este no es perfecto necesita ser mejorado y yo no soy bueno en REGEX.
PD: sorry me confundi y edite tu comentario en vez del reply jaja

Nice Raul, I really like this feature. I did notice that if we have a word follow by a "." te color change even if is not a link.

Si literalmente publique este issue de mi solución en el dev channel, tambien lo puse la descripcion del PR.
Es el Regex que detecta un url, este no es perfecto necesita ser mejorado y yo no soy bueno en REGEX.
PD: sorry me confundi y edite tu comentario en vez del reply jaja

ok, dale I will try to make it better after is merge, I used this on the TextinputFormater

@n13 @gguij004
In fact now I see the Regex works as expected since it is detecting bare domains like google.com, facebook.com and so on.
So what happens is that if they are not these domains they are not very common typing errors anyway if it is not a url, no problem it will not crash.
But in order to only detect https urls I put one more condition that can be easily removed to allow again bare domains.
PD: I also checked these libraries (flutter_likify and its dependency linkify) and they have many bugs and have not been updated since May of this year.


Refresh Ventures for Shared Prosperity page

Existing: https://ideas42ventures.netlify.app/ventures-for-shared-prosperity/
Content: https://docs.google.com/document/d/151pk_yJ0veFZ9nGRLH1QZLYvi3Rtw0yJC0BsJBonjoI/edit?usp=sharing
Primary goal
Update the content on the page to match the updated content doc
Secondary/longer term goal
This page needs to feel a bit more like "a thing". This is a cohort page, so it will likely expand over time. And we'll have future cohorts that have similar pages. We need to find ways to make these feel distinct from regular site pages.

closing for better described issue


Terraform 2

Выполнено ДЗ № 8

[X] Основное ДЗ
[X] Задание со *

В процессе сделано:

Were configured explicit and implicit dependencies between resources
Were separated templates for creating db instance, app instance, network configuration and were created two instances from these templates
Were created tree modules - app, db, vpc for multiple usage this code and parametrized these modules for more flexible
Were created two work environments prod and stage using modules
Was added usage module storage-bucket for storing remote state
For last task I didn't have time =(

Как запустить проект:

Cloning repo https://github.com/Otus-DevOps-2018-02/Win32Sector_infra
Enter directory "terraform" execute command terraform init
Execute command terraform apply
ATTENTION! YOU MUST HAVE GCP ACCOUNT TO TEST THIS PROJECT!

Как проверить работоспособность:

After terraform apply, will be created gcp infrastructure with two instances reddit-app and reddit-db. You can see it's in your gcp console.

PR checklisk

[x] Выставил label с номером домашнего задания
[x] Выставил label с темой домашнего задания

Алилуйя! Я нашел лишний пробел!!! :godmode:


RFQ: supporting RISC-V architecture based Milk-V Duo

Milk-V Duo is an ultra-compact embedded development platform based on the CV1800B chip with two RISC-V Cores, one C906 running Linux and one C906 running RTOS.

Integrated CVITEK TPU for smart detection.
Supports H.264/H.265 video encoding, up to 2880x1620@20fps
Features a 16-pin FPC interface for 2-lane MIPI camera input
Up to 4M Pixel ISP support

We(Milk-V) are very happy to donate Duos and Cameras to have OpenIPC support. If the team is interested, please contact me at<EMAIL_ADDRESS>.

Good afternoon
Thank you very much for your suggestion.
We as a team will think about it, read the documentation and I will contact you a little later.

Yes! Support for MilkV would be amazing! Really looking forward to it!

Hi! Any success with that? :D


KFP CICD Labs: modified variables for Cloud Build

Labs

Changed Cloud Build configuration file location from labs to solution (to use the yaml file in labs dir, need to git push to the repo beforehand )
Changed _ENDPOINT variable to avoid confusion

Solution

Changed _ENDPOINT variable to avoid confusion

The _ENDPOINT variable changes are clear, lgtm.
To reroute the cloudbuild.yaml to the labs version, I understand the problem you describe about the push! However, I am just not convinced yet if this solution is the right way -- after all, now if a student incorrectly sets up their cloudbuild.yaml file during the exercise, they'll now mistakenly think that they did id correctly, or am I missing something?
I'd ask @BenoitDherin once he's back to maybe review this thanks!

@danielsparing
Actually I agree.
I initially wrote codes to push labs yaml to repo, but change the strategy checking the vertex ai version which is also leading to solution.
https://github.com/GoogleCloudPlatform/asl-ml-immersion/blob/master/notebooks/kubeflow_pipelines/cicd/labs/kfp_cicd_vertex.ipynb
Personally I prefer pushing the labs yaml file. What do you think?

Ah interesting, the solutions link comes from the Vertex work? Sorry I missed that.
I think this would be great (and maybe this means the Vertex one has to be changed this way too?), but still would prefer if @BenoitDherin OK'd it too next week. Let's get back to it next week!

Let me bump this up for your review! @BenoitDherin

@BenoitDherin Thanks for the comment. It makes sense from the security perspective.
I changed the code cell to a comment. So could you review it again?
CC @danielsparing

Was this supposed to be merged? iirc @takumiohym the  pull request  here had the right approach vs #53 , right?

@takumiohym @conchitagoogle I am reverting this for now since the code for this is really old from November 2021 and we haven't tested this recently.

Hi Santana!!
I think is my fault not takumi.
Sorry for that! I was confused this morning and posible did a mistake.
Thanks for revert that.
Conchita
El vie, 25 feb 2022 21:34, Sanjana L Reddy @.***>
escribió:

@takumiohym https://github.com/takumiohym @conchitagoogle
https://github.com/conchitagoogle I am reverting this for now since the
code for this is really old from November 2021 and we haven't tested this
recently.
—
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/asl-ml-immersion/pull/53#issuecomment-1051237877,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQKD7JQHJUHOFUEKRNU4VSTU47RWVANCNFSM5DYLN2GQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

No worries at all! Thanks for clarifying @conchitagoogle :)


Wrong YAML key order

The order of keys in the encoded POSEIDON.yml file is arbitrary and therefore confusing. It should be strictly defined.
The solution suggested here for Aeson did not work for me. Other solutions might build upon Data.Yaml.Pretty or Data.Yaml.Builder.

I would vote to not define the order. We deliberately chose YAML as the format for this file, and it feels to me like tacking on an order restriction will be something that we enforce outside of the format specification. It feels weird to me. Open to discussing, obviously, and don't feel strong about it, but I would say that I could live with the fact that some YAML files will have different order.
Nothing stops us from recommending implicitly a specific order, simply by using a consistent order in all of our GitHub-backed files, as well as in our help messages. But I wouldn't enforce it

I would vote to not define the order. We deliberately chose YAML as the format for this file, and it feels to me like tacking on an order restriction will be something that we enforce outside of the format specification. It feels weird to me. Open to discussing, obviously, and don't feel strong about it, but I would say that I could live with the fact that some YAML files will have different order.
Nothing stops us from recommending implicitly a specific order, simply by using a consistent order in all of our GitHub-backed files, as well as in our help messages. But I wouldn't enforce it

Right - ok - the wording above is misleading. The input order does not matter, but trident should always return files in a certain order. Just as it is now implemented in #29. Please check if you agree if this implementation.

Right - ok - the wording above is misleading. The input order does not matter, but trident should always return files in a certain order. Just as it is now implemented in #29. Please check if you agree if this implementation.

I agree.

I agree.


Business Licenses & Permits

Don't think we need any of this.

The State of Michigan does not have a generic business license. Several occupations and industries/services are required to be licensed by the State of Michigan. Depending on the specific type of business or manufacturing operation, some type of certification, license or permit may be required. Access the State License Search site for licensed occupations information (search) online at: www.michigan.gov/statelicensesearch

I thought it may be worthy to find an organization that is similar to us and search but couldn't think of any off the top of my head. Looked on http://www.michigan.gov/statelicensesearch/0,4671,7-180-24786-81461--,00.html but didn't see anything we needed.

I am going to close this out. We may need a license for certain fundraising activities.


AML Registry Only

Retrying fresh build on new PR

/test

:robot: pr-bot :robot:
:runner: Running tests: https://github.com/UCLH-Foundry/FlowEHR/actions/runs/4807680658 (with refid 5ee3b2ea)
(in response to this comment from @damoodamoo)

/test-force-approve
had approvals on previous PR: https://github.com/UCLH-Foundry/FlowEHR/pull/284

:robot: pr-bot :robot:
:white_check_mark: Marking tests as complete (for commit 79199bae1c81c77c0ad8949d7cd289e50cf4afb7)
(in response to this comment from @damoodamoo)


Compare to Flow runtime?

Flow has different methods helpful for enum usage: https://flow.org/en/docs/enums/using-enums/#toc-methods

cast
isValid

It will be wonderful to include some helpers with strict type safety in TS:
v = SomeEnum.cast(raw) // v type inference: SomeEnum | null

Yes, it's a useful feature but I'm worried about how ADT enums will work with those mehods.


OpenAPI security fields

I'm really liking apistar, thanks for creating it!
I would like to be able to declare "security" fields in the OpenAPI "schema". That would let me use Swagger-UI directly with its integrated authorization functionality as I'm doing for example in this project generator (using Flask and Flask-apispec, Docker based): https://github.com/tiangolo/full-stack
I'm not talking about integrated authentication / authorization within API Star, I would still expect to develop the functionality in each individual app or with external plug-ins, as apistar-jwt.
But with the current code it's not possible to modify or add more data to the OpenAPI schema. So, it's not possible to add the "security" fields that would be required for that.

I just read the full OpenAPI spec yesterday to check in the code if it was actually possible with the current code, but I see there are some changes required.
And very recently I read the full spec of OAuth2, to implement all that in my Flask APIs with Swagger 2.0. But I would love to use API Star.
I'm willing to help, but I would like to first know if there is any plan with respect to that and if that would be something desirable for the project (I certainly hope so).
Some of the changes I think that are neede are:
In apistar/openapi.py:

This line ('security', validators.Ref('SecurityRequirement')), needs to be validators.Array(validators.Ref('SecurityRequirement'))) as used below in other section. In OpenAPI
This line should be updated to be one security requirement and not an Array, although I'm still not completely sure what is the role of the additional_properties compared to the properties, so I might be misunderstanding it.
Components should be able to also contain securitySchemes and not only schemas. In OpenAPI.
There should be a definition for a SecurityScheme that would be referenced in Components and possibly in the operators (get, post in each route). In OpenAPI.

There should be a way to pass the SecuritySchemes to App, probably on instantiation, to be put beside the schemas, under Components.
There should be a way to pass a security field referencing the name of one of the SecuritySchemes to each route-method pair. Probably as a keyword argument in Route().

Again, I don't expect API Star to handle security iself, authentication and authorization, etc. At most validation of fields. The rest would be handled in each app specific code or with plug-ins, but that would provide a way to declare in OpenAPI the security definitions that could then be used with an integrated UI like Swagger-UI.
BTW, Swagger-UI could be used as a separate front-end app (e.g. in a separate Docker container) or integrated into API Star. Here's an example of how it looks like: http://petstore.swagger.io/ . And it's already built, and API Star is already almost completely compatible with it.
The "Authorize" button allows you to authenticate with the API and use the documented endpoints without having to copy and paste tokens or passwords for each request.
That's what I do with https://github.com/tiangolo/full-stack, but it is based on Flask, and I would love to be able to take advantage of all the new Python typing functionality as with API Star.

What are your thoughts on all this?

Thanks for the detailed and well thought through issue!
So there's a whole bunch of different fields that OpenAPI doesn't generate - the security ones being one of them. (Something like "callbacks" being an example of another.) We could find way to include these from the codebase - eg. include them from the Route. However we end up in a position of having to eventually expand to handling the entire OpenAPI spec from within API Star codebases. I'd rather that we instead consider something like dumping out the schema, and allowing developers to include additional annotations in there, and then keep the schema in-sync as the project develops.

Thanks for your response and considerations @tomchristie !
Actually, I see there are very little pieces from OpenAPI missing in API Star, at least from the schema validation.

Thinking about parsing and modifying the full schema dump.
Do you see a way an API Star "Component" could modify something in the complete OpenAPI schema? For the security global field and the securitySchemes in the components.
At the same time, do you see how that same API Star "Component" could modify something in the specific schema for each route it is being used in? For each specific path securitySchemes field.
For example, in apistar-jwt.
I'm trying to figure out how that would be implemented, as it seems to me it would be quite non-trivial to only use the full schema dump and modify it after it is generated.

Here's an idea, what if most of the OpenAPI schema is included in the validation (almost as it is right now), and whatever is too complex to be included, or too unrelated to the core project's objectives (let's say, the "callbacks"), is just declared as any, so that developers can use it without having validation problems, but is up to the developers to use and create those sections correctly.
And then, in the code that ends up generating parts of the schema, for example the Route, or Components, there's a way to declare other fields of the schema section they modify. Those sections are not checked to be valid, to reference whatever they should be referencing, etc. It's all up to the developers.
But that would give a greater fexibility and simplicity for developers to add whatever custom code they need to include additional OpenAPI generated schema parts, without having to parse the full dumped schema and finding for the sections that have to be modified, etc.

That's more or less how Flask-apispec works, it is not documented anywhere how to use the security fields, but there's a way to add any additional schema field required.
Note: these examples are with Swagger 2.0, not 3.0 (OpenAPI).
You can configure a Flask app with:
security_definitions = {
    'bearer': {
        'type': 'oauth2',
        'flow': 'password',
        'tokenUrl': f'{config.API_V1_STR}/login/access-token',
    }
}

app.config.update({
    'APISPEC_SPEC':
    APISpec(
        title='Example Project',
        version='v1',
        plugins=('apispec.ext.marshmallow', ),
        securityDefinitions=security_definitions),
    'APISPEC_SWAGGER_URL':
    f'{config.API_V1_STR}/swagger/'
})

The important part is here:
APISpec(

        securityDefinitions=security_definitions
)

...the securityDefinitions passed to APISpec is not even declared as a parameter, is just part of the "Optional top-level keys", like a **kwargs.
That modifies the global level schema fields.
And then in each route that uses security you can do something like:
@docs.register
@doc(description='Test access token', tags=['login'], security=security_params)
@app.route(f'{config.API_V1_STR}/login/test-token', methods=['POST'])
@use_kwargs({'test': fields.Str(required=True)})
@marshal_with(UserSchema())
@jwt_required
def route_test_token(test):
    current_user = get_current_user()
    if current_user:
        return current_user
    else:
        abort(400, 'No user')
    return current_user

The important part is here:
@doc(                  security=security_params)

... the security parameter is not declared in the doc definition, is just passed directly to the schema generation.
That modifies each route level schema section.
That way, although Flask-apispec and Apispec are not designed to "support" OpenAPI (Swagger) security, it's very easy to add it in an app using them.

Do you think that having some very simple way to extend the schema generated by each API Star part, in a similar way to what is done in Apispec, would be possible / feasible?


Add support for Podman users to run DoChat Out-of-box

This pull request adds a new boot script (dochat_podman.sh) and a patch file (dochat_podman.patch) for Podman users to use DoChat without any modification.
Podman is a daemonless container engine that can run on Linux systems. I have tested the new script on my Ubuntu 22.04 and Arch Linux laptop, and it works well.
The patch file shows the differences between the original dochat.sh and the new dochat_podman.sh. It can also be used for the CI/CD in the future.
I hope this pull request can be merged to the main branch and benefit more Podman users. Thank you.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


fix(onboarding): update ocp and aws providers once on source creation

fixes #907
In general, I added another check that makes sure koku-ui won't sent more than 1 request per provider type when onboarding is completed successfully.
By using prev props I can tell if a new source was added succesfully and in that moment to send a request.

Codecov Report

Merging #908 into master will decrease coverage by 0.01%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #908      +/-   ##
==========================================
- Coverage   72.74%   72.72%   -0.02%
==========================================
  Files         200      200
  Lines        3746     3747       +1
  Branches      692      693       +1
==========================================
  Hits         2725     2725
- Misses        931      932       +1
  Partials       90       90

Impacted Files
Coverage Δ

src/app.tsx
60% <0%> (-0.87%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update afab283...8ba1807. Read the comment docs.

Thanks @dlabrecq


Strange behavior of ol.layer.Vector.getFeatures(pixel) while dragging

Describe the bug
It seems that hit detection considers only initial position of feature (which was before the start of the drag), and not the current position.
To Reproduce

Open the test case https://vkgeo.github.io/test/
Move the mouse over the feature. The tooltip should be shown when mouse cursor is over the feature;
Move the cursor slightly away from the feature (for example, a few pixels on the left), press left mouse button and start dragging towards the feature;
Feature will move away to the right (as it should be), but when the mouse cursor will be over the old feature's position, you will see the tooltip again. This shouldn't be happening.

Expected behavior
Hit detection should consider only the actual position of the feature while dragging, not the old one.

You may want to skip hit detection during a drag interaction.
if (event.dragging) {
  return;
}

Yes, I can add this as a workaround, thanks! But is the current behavior of getFeatures() intentional?

The map and the hit detection image are redrawn at animation frames. pointermove events may happen more frequently. So while the map's internal state is updated during dragging it is not immediately rendered and a call to getFeatures will use an outdated image to detect features.
So this may happen by design.
An alternative would be the Map#forEachFeatureAtPixel. It's slower but should be more accurate.

The map and the hit detection image are redrawn at animation frames. pointermove events may happen more frequently. So while the map's internal state is updated during dragging it is not immediately rendered and a call to getFeatures will use an outdated image to detect features.

It seems however that hit detection image isn't updated at all until I release the mouse button.

This can be controlled by the updateWhileInteracting option of ol/layer/Vector

Yeah, I added "updateWhileInteracting": true and now I see just a rarely flickering tooltip (apparently due to less frequently redrawn hit detection image). Thank you!


More detail about WRL_CONFIGURATION_LEGACY

This adds clarification to exactly what WRL_CONFIGURATION_LEGACY  changes.

@BenJKuhn,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot


View Edit History

If a post is edited the ability to see the edit history when clicking the "edited" link

Thanks, I considered adding this but I wasn't sure if it's worth the effort. We'll need to implement the popover menu for the list of edits, and also the modal that shows the edit content. Plus, I don't know how hard it would be to render the diff.
If anyone's up for this, feel free to send a PR. Otherwise, I'll add this to the backlog and maybe implement it if I have the time.

Perhaps a placeholder "View edit history on GitHub" link could be used as a stopgap measure in the meantime?


Round Robin load balancing fails for non-shared store

When using a load balancing proxy, socket.io is unable to keep a "sticky" connection to a server, causing the 2nd transport request to go to a different  machine than the original handshake request. In order to get around this, it would be nice if there was a way to detect the incoming handshake as attempting to upgrade to socket.io, and some response headers to tell socket.io not to close the connection. This would mean keep-alive only transports would work in the proxy, however, this gets around the issue of round robin balancing when there are multiple requests before transport.
Something like:
X-Protocol-Hanshake: socket.io

X-Protocol-Accept: keep-alive-only

related: #682

In engine.io we include a session id from the client as part of every URL that makes sticky load balancing trivial.
Simply inspect the qs, get that id, balance. Please track the progress of the 1 branch
For now, you could do the same when you connect from the client (by adding a random id as part of the path), or based on Cookie (like it's typically done for regular website session load balancing)


Stashes: missing "created" field?

Expected Behavior
Uchiwa expects "created" field which should be present in Sensu stash.
Current Behavior
Uchiwa displays "Invalid" date" at field "Created".
I am not sure if Uchiwa design is wrong or Sensu stash is missing "created" field.
Possible Solution
N/A
Steps to Reproduce (for bugs)

Create stash via API
Check newly created sthash via Uchiwa
Do API GET for given stash

Context
If stash is designed as it is, I'll open Uchiwa issue.
Anyway, it could be nice if stash had timestamp of creation.
Your Environment

Sensu version used: 0.29
Active Sensu extensions (e.g. WizardVan 0.1.0):
Operating System and version (e.g. Ubuntu 14.04):
Transport and runtime versions (e.g. RabbitMQ 3.6.2 on Erlang 18.2): RabbitMQ

Well, it bit weird but "timestamp" must be present as a content of stash - which is, from my perspective, fully custom space. I expected to have timestamp as option of stash, same as "expire".


Alerts triggered only on state change, despite not using stateChangesOnly()

Hi,
This tick script looks at a certain field which happens to be at 0 all the time in normal situations. The points are collected by Telegraf every 60s using the redis input plugin. It should alert every time with INFO level (this is on purpose, to continuously communicate state to an external system), but it's only alerting when there's a stage change (I shift the lambda logic between info() and crit() to simulate).
However, what's odd is that I'm not using stateChangesOnly. There are no errors being detected, it's as if the lambdas in the alert node are being ignored because they match a saved state (which I thought was what stageChangesOnly is actually required for).
I'm using Kapacitor 1.5.1 with InfluxDB 1.6.2 (CentOS 7)
Code:
dbrp "telegraf"."autogen"
var db = 'telegraf'
var rp = 'autogen'
var measurement = 'redis'
var groupBy = ['host', 'port']
var whereFilter = lambda: TRUE
var name = 'Redis: Rejected Connections'
var idVar = name + ':{{.Group}}'
var message = 'EMPTY MESSAGE'
var idTag = 'alertID'
var levelTag = 'level'
var messageField = 'message'
var durationField = 'duration'
var outputDB = 'chronograf'
var outputRP = 'autogen'
var outputMeasurement = 'alerts'
var triggerType = 'threshold'
var crit = 0
var x_host = 'ng.metric.redis.rejected_connections'

var data = stream
    |from()
        .database(db)
        .retentionPolicy(rp)
        .measurement(measurement)
        .groupBy(groupBy)
        .where(whereFilter)
    |eval(lambda: "rejected_connections")
        .as('value')
    |eval(lambda: "host" + '_' + "port", lambda: x_host)
        .keep('value')
        .as('x_test', 'x_host')
        .tags('x_test', 'x_host')

var trigger = data
    |alert()
        .info(lambda: "value" == 0 )
        .crit(lambda: "value" > 0 )
        .message(message)
        .id(idVar)
        .idTag(idTag)
        .levelTag(levelTag)
        .messageField(messageField)
        .durationField(durationField)
        .exec('/etc/kapacitor/exec/x_alert.py', '2m')

trigger
    |eval(lambda: float("value"))
        .as('value')
        .keep()
    |influxDBOut()
        .create()
        .database(outputDB)
        .retentionPolicy(outputRP)
        .measurement(outputMeasurement)
        .tag('alertName', name)
        .tag('triggerType', triggerType)

trigger
    |httpOut('output')

Task info:
DOT:
digraph redis_rejected_connections {
graph [throughput="0.00 points/s"];

stream0 [avg_exec_time_ns="0s" errors="0" working_cardinality="0" ];
stream0 -> from1 [processed="10734"];

from1 [avg_exec_time_ns="20.463µs" errors="0" working_cardinality="0" ];
from1 -> eval2 [processed="10734"];

eval2 [avg_exec_time_ns="15.082µs" errors="0" working_cardinality="6" ];
eval2 -> eval3 [processed="10734"];

eval3 [avg_exec_time_ns="24.413µs" errors="0" working_cardinality="6" ];
eval3 -> alert4 [processed="10734"];

alert4 [alerts_inhibited="0" alerts_triggered="0" avg_exec_time_ns="50.057µs" crits_triggered="0" errors="0" infos_triggered="0" oks_triggered="0" warns_triggered="0" working_cardinality="6" ];
alert4 -> http_out7 [processed="0"];
alert4 -> eval5 [processed="0"];

http_out7 [avg_exec_time_ns="0s" errors="0" working_cardinality="0" ];

eval5 [avg_exec_time_ns="0s" errors="0" working_cardinality="0" ];
eval5 -> influxdb_out6 [processed="0"];

influxdb_out6 [avg_exec_time_ns="0s" errors="0" points_written="0" working_cardinality="0" write_errors="0" ];

Thanks.

The problem was in kapacitor.conf [smtp] section.
global was set to true, as well as state-changes-only...
Dangerous setting!


Fix headers regression breaking resource dropdown

Description
There was a regression in https://github.com/dotnet/aspire/pull/6192 that broke selecting resources in dialogs. I took a look and made some improvements:

width: 100vw isn't good on the page header because the page header is nested inside other content with margins and padding. That forces horizontal scroll bar, which forced the need for overflow: hidden, which created the bug: resource dropdown is now hidden when expanded.
Wrap on any character instead of by word. No choice is better all the time, but this stops bad behavior when there is a very long word.
The trace id wasn't visible. Fixed by putting it inside the h1.

Before:

After:

(note the trace id is now visible when there is wrapping)

Checklist

Is this feature complete?

[x] Yes. Ready to ship.
[ ] No. Follow-up changes expected.

Are you including unit tests for the changes and scenario tests if relevant?

[ ] Yes
[x] No

Did you add public API?

[ ] Yes

If yes, did you have an API Review for it?

[ ] Yes
[ ] No

Did you add <remarks /> and <code /> elements on your triple slash comments?

[ ] Yes
[ ] No

[x] No

Does the change make any security assumptions or guarantees?

[ ] Yes

If yes, have you done a threat model and had a security review?

[ ] Yes
[ ] No

[x] No

Does the change require an update in our Aspire docs?

[ ] Yes

Link to aspire-docs issue:

[x] No

Microsoft Reviewers: Open in CodeFlow

/azp run

/azp run


[Bug/Crash] Game crash with CMM version 1.7

Hi lumien,
Having a crash with CMM...
Minecraft 1.7.10
Forge <IP_ADDRESS>8
CMM Version 1.7
JSON File: http://paste.ee/p/6bA5d
Crash Report: http://paste.ee/p/ArRfy

Whoops, 1.7 makes every gui without a splash text crash. Will upload the fixed version today.

Thx @lumien231


Cody Gray: Watch learncsharpythoncheap.blogspot.com

Cody Gray requests the watch of the watch_keyword learncsharpythoncheap\.blogspot\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

learncsharpythoncheap\.blogspot\.com has been seen in 0 true positives, 0 false positives, and 0 NAAs.

Approved by Spevacus in Charcoal HQ


Adds cache to github actions builds

This PR adds the following:

Generates a Cargo.lock file manually
Adds a cache for the matrixed builds using the matrix name alongside the lockfile
Adds a cache for clippy lint
Adds a cache for benchmark
adds restore_keys array to retrieve cache from most recent build if one does not exist for current lock
Adds workflow dispatch, which allows manually triggering the build on branches or just replaying an existing build; can remove this if asked

Time gains can be seen from:
https://github.com/Eein/livesplit-core/actions/runs/1392897119
to
https://github.com/Eein/livesplit-core/actions/runs/1392944530
Edit: allowing a build to complete here:
https://github.com/Eein/livesplit-core/actions/runs/1393008609
Edit 2: Run with more unique cache keys
https://github.com/Eein/livesplit-core/actions/runs/1393099509
Notes:

There was some issues with mac builds in my branch, but I do not think its related to this PR and likely some licensing/secrets.
There's some windows builds are very inconsistent in how long they may take and recompile anyways. Keys may need to be more specific to avoid using caches with the same target name that aren't useful to their context
cargo packages loaded from git must be recompiled

closes #297

Mmh, since there's many (indirect) dependencies I don't think the Cargo.lock will last very long, causing the caches to last probably much less than a day.

Sounds good!
If this doesn't provide any immediate value, Id be happy to have this PR closed.
Can always be picked up later if something changes

Alright, closing this for now. Thanks for looking into this anyway.


Is it time to enable c++17 to the C++ library?

At the moment, the C++ library supports gcc, clang and msvc compilers at the same time with C++11 enabled. To keep up with the pace of modern c++ standards, we can enable c++17 or even c++20 by default. We should be careful with public headers as they are dependent by various downstream projects. Elsewhere we can enjoy new language features internally in the library.
However, this requires us to lift the minimum versions supported for the compilers listed below:

gcc: at least gcc5 is required (https://gcc.gnu.org/projects/cxx-status.html#cxx17)
clang: at least clang5 is required (https://clang.llvm.org/cxx_status.html#cxx17)
msvc: at least Visual Studio 2017 version 15.3 (https://learn.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version?view=msvc-170#c-standards-support)

Thoughts? @dongjoon-hyun @williamhyun @guiyanakuang @stiga-huang @coderex2522

+1 for Apache ORC 1.9.0.

This is resolved via https://github.com/apache/orc/pull/1295


The details of "--model=gray"

Hi, in the README text, you said "--model=gray: According to our further experiments after paper acceptance, we are able to get a slightly better model by tuning parameters, even without LSTM. This model should produce visually sharper and quantitatively better results.". Could you please tell me the details of this model? What's the difference from the accepted paper?

We just removed the LSTM module. Other parts are the same.
You can refer to our source code for more details.


[Release-1.26] - The server flag should be skipped or present an error during a cluster-reset

Backport fix for The server flag should be skipped or present an error during a cluster-reset

#8488

Validated on Version:
-$  k3s version v1.26.9+k3s-3483aa87 (3483aa87)

Environment Details
Infrastructure
Cloud EC2 instance
Node(s) CPU architecture, OS, and Version:
NAME="SLES"
VERSION="15-SP4"
Cluster Configuration:
3 node servers
Steps to validate the fix

Install rke2 and join 2 other server nodes
Run rke2-killall.sh on the initial server node and one other server node
Attempt cluster-reset on the remaining server node:

$ sudo systemctl  stop k3s
$ sudo K3S server --cluster-reset

Validation Results:

$ sudo systemctl  stop k3s
$ sudo K3S server --cluster-reset

~> k3s -v
k3s version v1.26.9+k3s-3483aa87 (3483aa87)
go version go1.20.8

> sudo k3s  server --cluster-reset
FATA[0000] cannot perform cluster-reset while server URL is set - remove server from configuration before resetting


feat: op stack integration

Description

The goal is to add a new option to deploy an OP stack rollup inside our package.
To deploy the default OP stack rollup, you can use:
deployment_stages:
  deploy_optimism_rollup: true

You can also customize the rollup:
deployment_stages:
  deploy_optimism_rollup: true

optimism_package:
  chains:
    - participants:
      - el_type: op-geth
        cl_type: op-node
      - el_type: op-reth
      - el_type: op-erigon
      - el_type: op-nethermind

References (if applicable)

Ticket: https://polygon.enterprise.slack.com/lists/T8VPLGV4Z/F07AWFULS49?record_id=Rec081C9R81SB
OP package: https://github.com/ethpandaops/optimism-package
Fork of OP package with feature to deploy to an external L1: https://github.com/leovct/optimism-package/tree/feat/deploy-to-external-l1

I can see the finalized_l2 number incrementing when running this setup. It seems like the OP components are working and the op-batcher is correctly sending sequenced batches to L1 for verification.

Cool, thanks for checking this. By the way, I added a new monitor for OP rollups to check if L2 blocks are finalized after some time.


Wrong translation ids in german translation file

source: zendframework/zend-i18n-resources/languages/de/Zend_Validate.php
right: File has an incorrect mimetype of '%type%'
wrong: File has a false mimetype of '%type%'
right: The mimetype could not be detected from the file
wrong: The mimetype of file could not be detected
and some others

This repository has been closed and moved to laminas/laminas-i18n-resources; a new issue has been opened at https://github.com/laminas/laminas-i18n-resources/issues/6.


Remove success flash when updating brief response

https://trello.com/c/FGm8bi13/3-2-suppliers-may-be-missing-out-on-opportunities-due-to-misleading-banner
We believe that this success flash message is misleading some suppliers. We have some evidence to suggest that they think the flash message means that they've successfully submitted their brief response. This means that they don't press the button to submit their application.
Our evidence here is not definitive - we've got a pattern of support requests, but we've not done any user research or proper analysis.
We don't need this flash, however. Users can see on the page that their information has been updated.
For this reason, we're just going to go ahead and remove the flash. We'll check back in a few weeks to see what effect it's had on the rate of submitted brief responses and support requests.
This screenshot shows the green flash message that this PR removes:

I've checked, and can't find any functional tests that test for the presence of the flash message.


Unrealistic result of StdNormalGen.

My code:
#include <iostream>
#include <functional>

#include <Eigen/Dense>
#include <EigenRand/EigenRand>

using namespace std;
using namespace Eigen;

int main()
{
	Rand::Vmt19937_64 urng{4212};

	Rand::StdNormalGen<float> stdnorm;
	for (int i = 0; i < 10; ++i)
	{
		cout << stdnorm.generate<Matrix<float, 4, -1>>(4, 1, urng) << endl;
	};
};
``
Returning result:

  -0

-6.42001
8.3635
-6.50135
1.90169
2.42386e-38
2.94601e-38
2.49921e-38
-0
0
-0
0
0.783801
0.534232
1.48888
0.844737
4.74061
7.18897
-0
-5.66121
1.59769e-38
2.74603e-38
0.594965
2.17096e-38
-1.74388
-0
-0
3.80259
6.58371e-39
0.81791
0.762132
1.40474e-38
-0
-2.30039
-0
-12.4106
1.05125
8.62637e-39
0.706428
4.00838e-38

One can see that there are many values very close to 0. It's unlikely that these values obey normal distribution.

I'm using EigenRand in 64bit Ubuntu and my CPU has AVX and SSE flags.

Hi, @kilasuelika , thank you for your interest in my package.
Can you share your environment more detail including your Ubuntu version, compiler version and compile options?

I have upload a RepEigenRand.zip to my fork. It contains all necessary files to run.
I'm using G++ 10.2 with cxx_std_20 on Ubuntu 20.04.
I tested on my single core server and home computer. Results are the same. These two computers have same Ubuntu OS version and toolchain.

Hi, @kilasuelika , thank you for your interest in my package.
Can you share your environment more detail including your Ubuntu version, compiler version and compile options?

I have upload a RepEigenRand.zip to my fork. It contains all necessary files to run.
I'm using G++ 10.2 with cxx_std_20 on Ubuntu 20.04.
I tested on my single core server and home computer. Results are the same. These two computers have same Ubuntu OS version and toolchain.

I have a similar problem. Specifically, when I use the AVX2 instruction set to generate random numbers uniformly distributed between -1 and 1, a large number of 1 and -1 appear. Here is my code:
int main() {
  Eigen::Rand::Vmt19937_64 urng(0);
  Eigen::VectorXd mat =
      Eigen::Rand::uniformReal<Eigen::VectorXd>(7, 1, urng, -1, 1);
  std::cout << mat << std::endl;
  return 0;
}

And here is the  output
0.0272327
-0.282532
-0.675817
 0.410987
       -1
        1
        1

This phenomenon only occurs when generating non-[0, 1) uniformly distributed random numbers，and for standard uniform distributions, random number generation is right. For generating random numbers conforming to a gaussian distribution has a similar situation . I guess this problem is related to the SIMD instructions. I am using AMD 7950X, and here is my cmake file:
cmake_minimum_required(VERSION 3.10)
project(learning)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fopenmp -DEIGEN_DONT_PARALLELIZE -march=native")
set(CMAKE_CXX_FLAGS_DEBUG "-O0 -ggdb")
set(CMAKE_CXX_FLAGS_RELEASE "-fPIC -Ofast -flto=auto -DEIGEN_NO_DEBUG")
set(CMAKE_POLICY_DEFAULT_CMP0148 NEW)
find_package(Eigen3 CONFIG REQUIRED)
set(CMAKE_POLICY_DEFAULT_CMP0077 NEW)
set(EIGENRAND_BUILD_TEST OFF)
set(EIGENRAND_BUILD_BENCHMARK OFF)
add_subdirectory(EigenRand)

add_executable(main eigen_rand_testing.cpp)
target_link_libraries(main PRIVATE EigenRand::EigenRand)
target_include_directories(main PRIVATE ${EIGEN3_INCLUDE_DIR})


AssertionError on class creation if typing.Type is used

Bug | Feature request
When I create model and using typing.Type annotation, AssertionError gets raised immediately:
from typing import Type, Any
from pydantic import BaseModel

class Model(BaseModel):
    obj: Type[Any]  # Could be any type there, e. g. Type[str]

Traceback (most recent call last):
    class Model(BaseModel):
  File "pydantic/main.py", line 209, in pydantic.main.MetaModel.__new__
  File "pydantic/fields.py", line 135, in pydantic.fields.Field.infer
  File "pydantic/fields.py", line 112, in pydantic.fields.Field.__init__
  File "pydantic/fields.py", line 177, in pydantic.fields.Field.prepare
  File "pydantic/fields.py", line 238, in pydantic.fields.Field._populate_sub_fields
AssertionError

AssertionError is raised on this line, origin is type here:
https://github.com/samuelcolvin/pydantic/blob/18d4b2bb2ac9790bd58780dba67947a088725731/pydantic/fields.py#L252
Upd:
Also just discovered that if we replace Type[Any] with type, will get this:
Traceback (most recent call last):
    class Model(BaseModel):
  File "pydantic/main.py", line 209, in pydantic.main.MetaModel.__new__
  File "pydantic/fields.py", line 135, in pydantic.fields.Field.infer
  File "pydantic/fields.py", line 112, in pydantic.fields.Field.__init__
  File "pydantic/fields.py", line 178, in pydantic.fields.Field.prepare
  File "pydantic/fields.py", line 269, in pydantic.fields.Field._populate_validators
  File "pydantic/validators.py", line 475, in find_validators
RuntimeError: no validator found for <class 'type'>

This can be bypassed by setting Confif.arbitrary_types_allowed to True

OS: Ubuntu 18.10
Python version: 3.7.3 (default, Apr  9 2019, 04:56:51)  [GCC 8.3.0], (same on 3.6.8)
Pydantic version: 0.30 (same on 0.30.1)

I guess Currently this "type" is not supported, PR welcome to implement it.

Maybe replace AssertionError with TypeError(f'Type {origin} is currently not supported')?

yes agreed.

Seems to be fixed by #678

[joke mode on, don't take it too seriously]
@MrMrRobat is this one of those recursion jokes? -> Your comment on a fix (https://github.com/samuelcolvin/pydantic/issues/678#issuecomment-538802546) is linking to the same issue, this one to be exact ;)
[joke mode off]
On a serious note - is the fix in some other place?

Another serious question, what is typing.Type used for? I've not seen that, and instead usually see the bare type, e.g. value: str or value: Any, etc.

well, the same stuff it's used for in the python docs - defining class types, rather than instances.


[Bug]: GSheet | Learn more does not give any results

Is there an existing issue for this?

[X] I have searched the existing issues

Description
From Release - CE

From Production:

Steps To Reproduce

Open a new GSheet DS
Click on Learn more
Observe No results are returned
Expected - Users should get some appropriate helping documents when Learn more is clicked from anywhere within the app

Public Sample App
No response
Environment
Release
Issue video log
No response
Version
Prod/Release v1.9.26

Also, searching for any documentation from the omnibar does not give any results. And on click on Documentation icon does nothing
https://www.loom.com/share/3c9ebe8eb76a465898a93d337ee3b3f9

@shwetha-ramesh This was removed purposely. More details can be found here: https://theappsmith.slack.com/archives/C040LHZN03V/p1688369927255419?thread_ts=1688367423.304759&cid=C040LHZN03V
CC: @hetunandu


Ability to create SQL table logic from schema without doing a "migrate"

Problem
We use the SQL file generated by Prisma Migrate directly, without having Prisma migrate the database itself.  We do this so we can apply the SQL table generation logic in our test suites to generate ten or hundreds of schemas rapidly, on-demand.  Calling out to the Prisma executable is very slow (3-5 seconds per schema) whereas by directly applying the SQL in a Query (Postgres in our case) we can create our schemas in a fraction of a second.  Currently we have a build process that first destroys the files under Migrate, then asks Prisma Migrate (with ---create-only --skip-generate --name generate) to do the "migration", and then we then need to scan the migrations folder to find the generated SQL file.  This is a bit hacky, and more importantly, slow.  With this change, we reduced our test time from 4-6 seconds per test down to 0.5-1 second.
Suggested solution
Adjust the new Prisma DB PUSH command to offer a feature that does not talk to the database and let's us specify the target location of the full SQL schema generation file.  For example:
prisma db push --preview-feature --sql-only --sql-name ./sql/generate-schema.sql

Calling out to the Prisma executable is very slow (3-5 seconds per schema)

That sounds unwanted and unexpected. Can you please also create an issue for this so we can look into it? Thanks.

That sounds unwanted and unexpected. Can you please also create an issue for this so we can look into it?

I'm not sure I understand why 3-5 seconds is unexpected for the Prisma CLI to do a migration, and I'd rather not create an issue on it unless for some reason others find it is radically faster.
We call it using (execSync) - perhaps there is an API that we can consume that Prisma CLI uses to generate the SQL instead?  That would be even faster/better.
Thanks!

I'm not sure I understand why 3-5 seconds is unexpected for the Prisma CLI to do a migration, and I'd rather not create an issue on it unless for some reason others find it is radically faster.

I thought you gave the reason yourself - running the generated SQL file manually is much faster than calling our CLI.

I'm sorry I'm not being clear.  Right now, as best I am aware, the CLI only generates a SQL file with full table definitions, when it is asked to do a migration  - where there are no prior migrations and creating the SQL file is an unknown subdirectory under the 'migrations' folder.
I am asking for a feature where I can ask the CLI to generate a SQL file with full table definitions on-demand and specify where that file should be placed, where it does not make be destroy my prior migration entries to do so (and would also not need to talk to my database to examine it for matching schema).
My point about it being slow isn't that the CLI is slow, it's that it is slow to use it tens or hundreds of time on every test run.  By asking it once to create the SQL file, that file can be easily played into the target database efficiently in the test harness.
So the ask isn't to improve performance, it is to add an option to db push (or migrate) to create a SQL rather directly, rather than pushing it into a database, or making me remove the existing migrations to get it.
Hopefully this makes more sense.  Sorry for the confusion.

Ah, I did indeed not get that fully before - sorry. Thanks for clarifying.
If I understood correctly there are effectively two parts to your suggestion:

Be able instruct the command to assume you have an empty database (and not try to talk to the database to figure out if that is actually true)
Instead of trying to execute that file towards the database, just write it to a file to be used in any way you want it to.

The second point can already kinda be achieved with prisma migrate dev --create-only - but it will always try to figure out the current state of the database first.

Yes, that's it!   Plus perhaps:

Ignore the existing migration folder and files, and allow the SQL file to be written to any path

I do use --create-only today ... and assuming I delete the migration folders, it all works.  Felt like an obvious extension to the db push feature rather than migrate,  and one that didn't seem too difficult (easily said when I'm not the author)!

Hey, I know it's been a couple of months since you asked for this @cmidgley, but we now have a solution that we believe will work for you with two new migrate commands released in 3.9 https://github.com/prisma/prisma/releases/tag/3.9.0.
If I understood you correctly you want the full SQL to get from an empty database to the state of your Prisma schema.
 npx prisma migrate diff --preview-feature --from-empty --to-schema-datamodel ./schema.prisma --script > script.sql
will give you this.
The second command will apply this to a database.
 npx prisma db execute --preview-feature --url "$DATABASE_URL_PROD" --file script.sql
Please let us know when you had the opportunity to try this out.


for #2273 Add ShardHook in BaseShardingEngine

Pull Request Test Coverage Report for Build 7799

29 of 29 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.06%) to 55.622%

Totals

Change from base Build 7798:
0.06%

Covered Lines:
8751

Relevant Lines:
15733

💛  - Coveralls


[Help required] Blocked on building a dapr docker image with the devcontainer

I've been following the developer guide and I'm blocked on the building the container image step here
make docker-build produces the following error output
Building docker.io/<redacted>/dapr:dev docker images ...
docker run --privileged --rm tonistiigi/binfmt:qemu-v7.0.0 --install all
{
  "supported": [
    "linux/arm64",
    "linux/amd64",
    "linux/riscv64",
    "linux/ppc64le",
    "linux/s390x",
    "linux/386",
    "linux/mips64le",
    "linux/mips64",
    "linux/arm/v7",
    "linux/arm/v6"
  ],
  "emulators": [
    "arm",
    "i386",
    "mips64",
    "mips64le",
    "ppc64le",
    "riscv64",
    "rosetta",
    "rosetta-wrapper",
    "s390x",
    "x86_64"
  ]
}
docker buildx create --use --name daprbuild_multi --platform linux/arm/v7,linux/arm64/v8,linux/amd64
unknown flag: --use
See 'docker --help'.

Usage:  docker [OPTIONS] COMMAND

A self-sufficient runtime for containers

Common Commands:
  run         Create and run a new container from an image
  exec        Execute a command in a running container
  ps          List containers
  build       Build an image from a Dockerfile
  pull        Download an image from a registry
  push        Upload an image to a registry
  images      List images
  login       Authenticate to a registry
  logout      Log out from a registry
  search      Search Docker Hub for images
  version     Show the Docker version information
  info        Display system-wide information

Management Commands:
  builder     Manage builds
  container   Manage containers
  context     Manage contexts
  image       Manage images
  manifest    Manage Docker image manifests and manifest lists
  network     Manage networks
  plugin      Manage plugins
  system      Manage Docker
  trust       Manage trust on Docker images
  volume      Manage volumes

Swarm Commands:
  swarm       Manage Swarm

Commands:
  attach      Attach local standard input, output, and error streams to a running container
  commit      Create a new image from a container's changes
  cp          Copy files/folders between a container and the local filesystem
  create      Create a new container
  diff        Inspect changes to files or directories on a container's filesystem
  events      Get real time events from the server
  export      Export a container's filesystem as a tar archive
  history     Show the history of an image
  import      Import the contents from a tarball to create a filesystem image
  inspect     Return low-level information on Docker objects
  kill        Kill one or more running containers
  load        Load an image from a tar archive or STDIN
  logs        Fetch the logs of a container
  pause       Pause all processes within one or more containers
  port        List port mappings or a specific mapping for the container
  rename      Rename a container
  restart     Restart one or more containers
  rm          Remove one or more containers
  rmi         Remove one or more images
  save        Save one or more images to a tar archive (streamed to STDOUT by default)
  start       Start one or more stopped containers
  stats       Display a live stream of container(s) resource usage statistics
  stop        Stop one or more running containers
  tag         Create a tag TARGET_IMAGE that refers to SOURCE_IMAGE
  top         Display the running processes of a container
  unpause     Unpause all processes within one or more containers
  update      Update configuration of one or more containers
  wait        Block until one or more containers stop, then print their exit codes

Global Options:
      --config string      Location of client config files (default
                           "/home/dapr/.docker")
  -c, --context string     Name of the context to use to connect to the daemon
                           (overrides DOCKER_HOST env var and default context set
                           with "docker context use")
  -D, --debug              Enable debug mode
  -H, --host list          Daemon socket to connect to
  -l, --log-level string   Set the logging level ("debug", "info", "warn",
                           "error", "fatal") (default "info")
      --tls                Use TLS; implied by --tlsverify
      --tlscacert string   Trust certs signed only by this CA (default
                           "/home/dapr/.docker/ca.pem")
      --tlscert string     Path to TLS certificate file (default
                           "/home/dapr/.docker/cert.pem")
      --tlskey string      Path to TLS key file (default "/home/dapr/.docker/key.pem")
      --tlsverify          Use TLS and verify the remote
  -v, --version            Print version information and quit

Run 'docker COMMAND --help' for more information on a command.

For more help on how to use Docker, head to https://docs.docker.com/go/guides/

make: [docker/docker.mk:126: docker-build] Error 125 (ignored)
docker buildx inspect daprbuild_multi --bootstrap
unknown flag: --bootstrap
See 'docker --help'.

Usage:  docker [OPTIONS] COMMAND

A self-sufficient runtime for containers

Common Commands:
  run         Create and run a new container from an image
  exec        Execute a command in a running container
  ps          List containers
  build       Build an image from a Dockerfile
  pull        Download an image from a registry
  push        Upload an image to a registry
  images      List images
  login       Authenticate to a registry
  logout      Log out from a registry
  search      Search Docker Hub for images
  version     Show the Docker version information
  info        Display system-wide information

Management Commands:
  builder     Manage builds
  container   Manage containers
  context     Manage contexts
  image       Manage images
  manifest    Manage Docker image manifests and manifest lists
  network     Manage networks
  plugin      Manage plugins
  system      Manage Docker
  trust       Manage trust on Docker images
  volume      Manage volumes

Swarm Commands:
  swarm       Manage Swarm

Commands:
  attach      Attach local standard input, output, and error streams to a running container
  commit      Create a new image from a container's changes
  cp          Copy files/folders between a container and the local filesystem
  create      Create a new container
  diff        Inspect changes to files or directories on a container's filesystem
  events      Get real time events from the server
  export      Export a container's filesystem as a tar archive
  history     Show the history of an image
  import      Import the contents from a tarball to create a filesystem image
  inspect     Return low-level information on Docker objects
  kill        Kill one or more running containers
  load        Load an image from a tar archive or STDIN
  logs        Fetch the logs of a container
  pause       Pause all processes within one or more containers
  port        List port mappings or a specific mapping for the container
  rename      Rename a container
  restart     Restart one or more containers
  rm          Remove one or more containers
  rmi         Remove one or more images
  save        Save one or more images to a tar archive (streamed to STDOUT by default)
  start       Start one or more stopped containers
  stats       Display a live stream of container(s) resource usage statistics
  stop        Stop one or more running containers
  tag         Create a tag TARGET_IMAGE that refers to SOURCE_IMAGE
  top         Display the running processes of a container
  unpause     Unpause all processes within one or more containers
  update      Update configuration of one or more containers
  wait        Block until one or more containers stop, then print their exit codes

Global Options:
      --config string      Location of client config files (default
                           "/home/dapr/.docker")
  -c, --context string     Name of the context to use to connect to the daemon
                           (overrides DOCKER_HOST env var and default context set
                           with "docker context use")
  -D, --debug              Enable debug mode
  -H, --host list          Daemon socket to connect to
  -l, --log-level string   Set the logging level ("debug", "info", "warn",
                           "error", "fatal") (default "info")
      --tls                Use TLS; implied by --tlsverify
      --tlscacert string   Trust certs signed only by this CA (default
                           "/home/dapr/.docker/ca.pem")
      --tlscert string     Path to TLS certificate file (default
                           "/home/dapr/.docker/cert.pem")
      --tlskey string      Path to TLS key file (default "/home/dapr/.docker/key.pem")
      --tlsverify          Use TLS and verify the remote
  -v, --version            Print version information and quit

Run 'docker COMMAND --help' for more information on a command.

For more help on how to use Docker, head to https://docs.docker.com/go/guides/

make: *** [docker/docker.mk:127: docker-build] Error 125

it seems to be complaining about the docker buildx create --use and --bootstrap flags.

running docker info within the dev container produces the following :
Client: Docker Engine - Community
 Version:    27.3.1
 Context:    default
 Debug Mode: false

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 1
 Server Version: 27.3.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7f7fdf5fed64eb6a7caf99b3e12efcf9d60e311c
 runc version: v1.1.14-0-g2c9f560
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.10.4-linuxkit
 Operating System: Debian GNU/Linux 11 (bullseye) (containerized)
 OSType: linux
 Architecture: aarch64
 CPUs: 10
 Total Memory: 15.6GiB
 Name: docker-desktop
 ID: 97084835-c164-4b08-9a6c-0255bfbf4afd
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  <IP_ADDRESS>/8
 Live Restore Enabled: false

As you can see the docker engine version is the latest with 27.3.1

Does anyone have any ideas on whats happening here?

Hey Oli. Can you try setting these env variables?
export GOOS=linux
export DAPR_REGISTRY=myregistry
export DAPR_TAG=edge
export TARGET_OS_LOCAL=linux
export TARGET_OS=linux
export TARGET_ARCH=arm64


Issue with Select Interpreter / Create Terminal after creation of new virtualenv

Steps to cause the bug to occur

Create a new pyenv-virtualenv in the vscode terminal pyenv virtualenv 3.7.6 my-virtual-env- 3.7.6
F1 Python: Select Interpreter and choose the newly created my-virtual-env- 3.7.6
F1 Python: Create Terminal (or start a Jupyter notebook)

Actual behavior
Starts the wrong interpreter
Expected behavior
Start the right interpreter
It seems to be caching the interpret list and not being aware it's been changed from underneath. Restarting vscode fixes the issue

@david-waterworth, thanks for letting us know about this.  We will work on fixing the issue as soon as we can.

It also doesn't seem to be 100% deterministic. Today I created a new pyenv-virtualenv from the vscode terminal. It didn't show up at all in the list of interpreters until I restarted vscode. Then it appeared but the first time I tried to enable an error was raised. Then it worked
Command 'Python: Select Interpreter' resulted in an error (command 'python.setInterpreter' not found)

Fixed in latest release of extension.


fix #2953, fix #2952

fix #2953 Unable to close a 'table input' edit window due to incorrect connection name
fix #2952 Unwanted "Invalid connection" message on not existing connections

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Run mvn clean install apache-rat:check to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.
[x] If you have a group of commits related to the same change, please squash your commits into one and force push your branch using git rebase -i.
[x] Mention the appropriate issue in your description (for example: addresses #123), if applicable.

To make clear that you license your contribution under the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

[x] I hereby declare this contribution to be licensed under the Apache License Version 2.0, January 2004
[ ] In any other case, please file an Apache Individual Contributor License Agreement.

Still doesn't work on table input transform, and inconsistent on other transforms. for example blank connection name on Insert / update also gives an error