[v6.0] Rework style system to use padding and margin better and remove init. values

At present, inside lv_obj_create we have:
        /*Set coordinates left top corner of parent*/
        new_obj->coords.x1 = parent->coords.x1;
        new_obj->coords.y1 = parent->coords.y1;
        new_obj->coords.x2 = parent->coords.x1 +
                             LV_OBJ_DEF_WIDTH;
        new_obj->coords.y2 = parent->coords.y1 +
                             LV_OBJ_DEF_HEIGHT;

So the new object ignores parent's area available for drawing. I see 2 issues here:
A. New object's x1 and y1 ignore the inner padding of the parent. This will result in draws insider the inner border of the parent if parent_style->body.padding.inner is set (non-0).
B. New object's x2 and y2 ignore the W and H of the parent. Depending on the actual size of the parent and his inner padding value, this may result in draws inside the inner border of the parent, and, even worse (if the parent's WxH is less than LV_OBJ_DEF_WIDTH or LV_OBJ_DEF_HEIGHT) - in draws outside the parent's client area!
I propose this be fixed via:
    lv_coord_t parent_inner_padding = 0;
    lv_style_t * parent_style = lv_obj_get_style(parent);

    if(parent_style)
    {
        parent_inner_padding = parent_style->body.padding.inner;
    }

    /*Set coordinates left top corner of parent*/
    new_obj->coords.x1 = parent->coords.x1 + parent_inner_padding;
    new_obj->coords.y1 = parent->coords.y1 + parent_inner_padding;
    new_obj->coords.x2 = parent->coords.x2 - parent_inner_padding;
    new_obj->coords.y2 = parent->coords.y2 - parent_inner_padding;

This will result in the object occupying the entire client rect of the parent by default. Yes, in most cases this is not what the caller wants, but neither is all objects to be set to LV_OBJ_DEF_WIDTH x LV_OBJ_DEF_HEIGHT. I think that when creating new objects, the caller should know their dimensions and set them explicitly, instead of relying on some hard coded values, deep inside the library, and completely out of context of things like theme/style used, etc.

Hi,
Let's extend the question to every default value. E.g.

Lables are created with "Text" default text
Drop down list are created with: "Option1, Option2, Option3" options
Buttons also have hardcoded default size which is a reasonable button size
etc

The purpose of these default values is to after just create the objects show something which looks like the object is intended to look like. (E.g. an empty label after creating might be confusing)
What do you think? Are they still reasonable or are there some considerations to take into account?
Using padding for initial position and size might be useful only if the parent also uses the paddings. But for example, the images are not using it.

Hi Gabor
We have discussed many things in the past and often have found new ideas in each other's suggestions, so I am really sorry to tell you that in this particular case I can not agree with anything you're saying... :)
--> Regarding the default string values for Text, Option etc., I don't think that this is a very valid comparison to the problem I am describing, because:

Setting Text or Option1 does not create potential bugs, whereas setting the object default WxH to LV_OBJ_DEF_WIDTH/HEIGHT could.
Setting these text values does not violate the rules of the lvgl library. And one of these rules (if I understand it correctly?) is that the actual area available to the children of the object must take into account the padding of the parent (more on padding in the last paragraph).

--> Regarding the button (or ANY object for that matter...) using a hardcoded default reasonable size:

I do not see the lv_btn constructor setting the button size in any way? I see that it calls the lv_cont constructor, but inside it I also did not see the size being set. Then lv_cont calls lv_obj_create so really it comes down to lv_obj (as far as I could see). I looked on branches beta and master.. maybe it is on some other branch?
I do not agree that an object itself can determine what is a "reasonable" size. Depending on the context a resonable size for a button can be a VERY different thing.
The only component which could have knowledge about the reasonable size for a given GUI element, IMO, is the theme -  because the theme represents the Graphics Designer vision of the GUI as a whole and hence can "know" that in this type of theme/style a button should look like this.
However ...
... default sizes are not currently a part of lv_style (and consequently not part of the theme).
Maybe they should be? If they were, then I would agree completely that some reasonable default value, based on the theme, should be used when creating an object. And it should come from the theme or style of the parent.

--> Regarding creating an object with default values so that the object looks the way it is intended to look like:
This may be reasonable if we are talking about some demo software, e.g. in the context of the pc_simulator.
In the case of a real software which is used in different real world applications I think that this approach does more harm than good:

It is "philosophically" incorrect because it move the knowledge about the GUI look-and-feel from the theme/style to the private code of the object (and not even every object - but the base of all objects!).
It will result in unnecessary loss of memory due to some hardcoded const text strings being added to the app/lib (because in reality people will not use Option1, Option2..);
and unnecessary waste of CPU cycles (to strcpy these strings to objects, when later they will be replaced by real strings).
It teaches people to be lazy by relying on some default values and actually creates a "ticking time bomb" situation. First I say  "Hey I don't need to set anything, it just works, and looks great!".
But then I decide to make my own theme...  and the default values do not work anymore... and there is frustration because   a) it does not look great anymore. and    b) now I have to go and set all the values inmy code properly (something which I should have done in the beginning)

--> Regarding "padding ... useful only if the parent also uses the paddings".
Maybe I don't understand how paddings, margins and borders work in lvgl? If yes - my apologies, and if there is any docs on this - please let me know wher I can read about this?
Looking at the code I got the impression that lvgl's paddings work in the standard accepted way which is like the HTML DOM model and the CSS Box model (https://www.w3schools.com/css/css_boxmodel.asp)?
If the above is true then there are no objects which are "not using padding". There are objects with 0-padding, yes, and that's not a problem because my proposed change accounts for this possibility (x1 + 0 = x1).

Hi,
Not agreeing is great because this way we can improve things :)
Styles:
As you can see the styles describes a lot of thing at the same time. (similarly to CSS) These are general properties and every object picks what it needs. E.g. text.font is not used by a line.  Moreover, a container uses paddings ONLY it the fit or layout is enabled. Else it's just a simple rectangle. However, once fit is enabled the container will fit to involve all children and will keep padding distance. Or when the layout is enabled the padding is taken into account when positioning the children.
Comparing LittlevGL's padding to CSS's padding the main difference is near all HTML element can use the padding. In LittlevGL only those who have something to deal with it.
But there are similarities as well: e.g. in CSS the padding is not inherited by default (https://www.w3schools.com/cssref/pr_padding.asp) but the color (text color) does. So a div doesn't care about color but a label on it inherits and uses the color. It's similar in LittelvGL too but for performance reasons, only the whole style can be inherited and not single properties.
It must be noted CSS is much more complex then LittelvGL's style system (which is designed for small, embedded systems).
I'm totally open to any constructive ideas to make the style system more flexible if we can keep it performance-wise.
Default values:
You are right about "Text" and "Option1, Option2" ... default values have a negative effect on memory footprint and performance. I agree it should have a define in lv_conf.h to enable/disable these initial settings. While playing with the library it's better to have some init values but it's better to avoid them later when you overwrite them anyway.
About basic size:
As we can't guess what user wants, so we can't set the size correctly during the creation of the object. As size must be set to a value, in my opinion,  we can only set a size which is not too small, not too big and just tries to not look ugly. That's why I used LV_DPI to create the objects. This why the result real size (in millimeter on the screen) is known and the screen size and resolution won't affect it.

Just chiming in on this.
I'm not a fan of any of the default width/height/labels.  I would prefer is the default size for everything is 0, and the default text for anything is an empty/null string.
My thought is that the user should be specifying these values.
Today the default label value of "Text" caused me an issue with my actual text not displaying correctly, see #310 and I had to break out the debugger to find out what was going on.

@aenchevich I don't like the idea of width/height being inside a style at all.  CSS uses min-width and min-height which sound a little more reasonable for a style
@kisvegabor and @aenchevich With regards to padding, in CSS there is the MARGIN and PADDING terms which are well understood.  In CSS you have a left/right/top/bottom MARGIN and left/right/top/bottom padding.  In LVGL the terms ver, hor and inner left me digging around in the codebase and I still don't think I understand when, where and why they are used.  ver and hor seems like MARGIN specifications, while inner seems like a PADDING specification that applies vertically and horizontally, but from the variable names themselves you can't tell, you have to read the code that uses them.

@hydra - Regarding the variable names in LvGL: yes initially I also had some difficulties understanding which is which. After reading the code and after Gabor's clarification above ("it is enabled the container will fit to involve all children and will keep padding distance. Or when the layout is enabled the padding is taken into account when positioning the children.") it is more clear to me now.
I agree that using the well-known names for these values  (margin and padding) would probably be better but at present it may not be a good option to change them - too many noise changes in all branches... I'd say - Gabor's call :)
Regarding the default values:
"I don't like the idea of width/height being inside a style at all"  ... ummm... ok... why? If you would like to have a discussion with the hopes of arriving at the best solution for this library and the people who will be using it - can you please specify WHY you don't think it is a good idea.
I personally also prefer 'null' values as default and the users to set them themselves. However there may be cases (especially when themes are involved) where these default values can be very useful and the good looks of the GUI would depend on certain values be used for certain elements. This was the reason why I suggested that default initial values be part of the '.body' structure.
@kisvegabor and @hydra Regarding the parallels which we all drew here to the CSS model:

Just as I was not very clear about how inner, ver and hor work in lvgl, I am also not very clear how border width works in lvgl. Gabor, could you please explain, or point me to some docs?

In that link I gave (CSS box model) there is an example about an object which is specified to have width 320 px and in reality becomes 350 px wide because the widths of margin, border AND(!) padding are added to 320. I personally find this confusing too (why add padding? it should be on the inside of the object!) but oh, well - that's what the w3c consortium decided.
How does it work in lvgl?

Gabor - I did NOT suggest that the object inherits parent's padding. I said that if the parent has non-0 padding the child should respect it and position itself at x1+padding, y1+padding.

CSS boxing model
Now LittelvGL didn't follow the CSS boxing model. Hor/Ver padding means the object should keep that distance from the children. It takes effect only in certain modes (fit, layout, etc.). Inner padding means the distance between the children on the parent.  True story, it's limited in some aspects:

no left/right/top/bottom padding, however, it's intentional to save memory
no separate margin and padding, which really might be confusing  and also limited

Now I'm thinking about the possibilities of following the CSS boxing model. So:

Object size = core_size + padding + margin
Object draw area: core_size + padding
Children can be only on  core_area
The border is now included to core_area. (Not like in CSS where border width is added to it). I feel it reasonable because this way a translucent border can be applied which look well :)
Left/Right/Top/Bottom padding and margin can be introduced as it's only 10 extra bytes/style (8 attributes vs 3)
It would be nice to make possible to overwrite padding and margin defined in the style to enable individual adjustment of objects.

It really looks simple and easy to understand. This way all object can use padding and margin.
It's a very interesting topic! I'm waiting a lot to hear you thoughts!
Default size
On the one hand, I feel inflexible to include size in styles. For example, a progress bar (lv_bar) and a chart (lv_chart) can have the same default style but they need significantly different default size. See their example photos here: https://littlevgl.com/object-types
On the other hand, in some cases it can be useful:

Size of control buttons on lv_window
Knob size of lv_slider
Indicator size of lv_tabview
The middle point of lv_gauge

So for me, it doesn't seem suitable to set the default size of a window and checkbox too because they look very different. But can be very useful to set the size of the "internal" elements of an object.

@all - Firstly - a visual example so it's easier to discuss  :)

Based on the above I think the sizes should be:

Total object size: core_size + border + margin
Object draw area: core_size - padding
Children can be only on core_area
lv_obj_set_size should set the total object size (the area with the green-yellow pattern)
I did not understand your rationale here... I think that under no circumstances should the border go outside the total are of the object (e.g. even if margin is 0 and border is 10). This is the same as what was said in 1.
Regarding "Left/Right/Top/Bottom padding and margin can be introduced" ... yes, sounds good!

Regarding: "It would be nice to [...] overwrite padding and margin defined in the style to enable individual adjustment of objects."  - Absolutely! With all of the fields of the structs public nothing stops you from setting them of course... but maybe some setter/getter functions would be best.
NOTE: What I am suggesting is not blindly following the CSS model.
I think that for lvgl, knowing the TOTAL area which the object may occupy is important. Therefore I am taking into account all the elements of the CSS model, but saying "we are calculating the offsets from the outside - in. We determine the total size/area of the object, then we step 25 pixels inside to respect the margin, then we draw a border 15 pixels wide, then we step in another 5 px to provide padding between our object and the children."

@hydra - Ok I see what you're saying. But in reality the code will probably look something like:
o = lv_something_create( parent, copy );      // this creates an object with default values
lv_obj_set_style( o, some_predefined_style ); // this is optional - if you want to change defaults

OR -

o = lv_something_create( parent, copy );      // this creates an object with default values
// set your_custom_style values however you like, e.g.
your_custom_style.body.padding.inner = 5;
lv_obj_set_style( o, your_custom_style );

So really the logic is not "if this then this unless this..."
Its more like "When creating the object, use some default values, which you can look up in the style definition. Later you can overwrite them if you like."

Thanks for the image. It will be really easier this way :)
I also added a simple image to demonstrate something:

Some text

Earlier I not defined the terms correctly. It seems we think the same but my terms were confusing:

core size: blue in the box model. In CSS the children objects can be only here.
draw area: where the object will draw itself (red rectangle)

So in the example above core size became 100 px because of width in CSS. The draw area  is core_size + padding + border.
The dotted border (the idea is taken from your image) shows well that the element is drawn under the border in CSS too. Just the size of the draw area  needs to be increased by the border width. It's reasonable because in my previous view a 20 px border could cover the children which is not good.
However - in my opinion - unlike CSS, lv_obj_set_width() should set core_size + padding + border (so the draw area). Why? The user thinks: "I want a 100 px wide button." This way he will get it. Let say he wants to set some extra space for the content on the left. To do this he can increase padding-left of the button and the button's size will remain.  For me, it seems more simple.
margin comes to play only in case of layout and alignments. And the margin area is always transparent. It would be strange to me if I decreased the spacing between to buttons (reduce margin) and I would get larger buttons to keep the total size.

Ok so in the box model example you gave there is 4 areas (BLUE, GREEN, YELLOW, ORANGE) and 4 rectangles (BLUE, BLUE+GREEN, BLUE+GREEN+YELLOW, and finally the big one with all 4)  let's define what we call those areas which are important and what they do?
If I understand correctly, your idea is:
Area BLUE - "core_size", or "client [draw] area" (because this is the area which a container provides to its children to place and draw themselves. So if a child obj is a 1x1 pixel object which wants to go to coords (0,0) of the parent it will go to the upper left corner of the blue rect). The oibject paints this area with the background "brush" (color, pattern, image) before drawing the children.
Area GREEN - "padding" - The Parent paints this area with the background "brush" (color, pattern, image) before drawing the children. Nothing else draws there.
Area YELLOW - "border" - The Parent paints this area with the background "brush" (color, pattern, image) after drawing the background. The background shall be visible behind the border if the border has transparent areas.
Area ORANGE - "margin"  - The Parent paints this area with ...? the margin "brush"? Or always leaves it transparent? Is this where the shadow of the object is drawn?

Rect BLUE+GR: not important on its own
Rect BLUE+GRN+YELW: "draw_area"  in your terminology. Will be painted with the backgnd, then with the border. lv_obj_set_size() sets the size of this area (except when the parent container is smaller than this... some discussion on this below). If the object wants to have a border then the border must be drawn on the inside of this area.
Rect BLUE+GRN+YELW+ORNG:  ???
This last one is somewhat unclear. I, personally, completely agree with your logic about the two buttons.
However:

is the margin always transparent? If not then on object invalidate this must be the area provided for redraw, not the "draw_area" (BLUE+GRN+YELW);
what happens if the "draw_area" of the object is OK, but this area is bigger than the client area of the parent?
When positioning an object which point should be taken as origin? The UL corner of this area? Or of the draw_area? If we use UL of draw area as origin ... and we have a 25 px margin ... and our parent has a 5px padding... Not only do we not respect the padding - we also overshoot the entire parent draw_area by 20 pixels!

So I think the proper solution (in order to keep the logic of "object size is object size, and margin has nothing to do with it") is to take the dimensions of the YELLOW rect as object size; and to take the UL of the margin as origin; and to refuse to draw objects, whose total size (i.e. draw_area + margin) would violate the dimensions of the client. Another possibility would be to reduce the client's size until it fits but I don't think it's a "clean" solution - at least when I tell a system to do something, I expect it either to do it exactly as instructed or to throw an error if impossible.

.. oh and one more thing - I would like to disagree that margins only come into play when layouts are used. I think every object has the right to say "I need some space!" even when positioned without layouts :)

... by the way - an example from life just came to my head:
You discover a new island and you decide to live there. So you want to build a house (your object), possibly put a fence around it (the borders) and possibly to have a garden inside the fence (the padding) and possibly even leave some area outside of the fence for some future needs (street, sidewalk, water pipes, electric cables, service road, etc..).
Whatever you do you - it can not be bigger than the island, so everything must fit into the size of the island.
On top of that, you can not build on sand, so you don't touch that area of the island and start building some distance away from the beach (this is the parent's padding).
Anyway, it's a big island and you are not a greedy person so you build a nice house, a garden and a fence, and leave some space outside of the fence for  and there is still lots of space on the island.
Then I come. I build my house next to you. I also can not build on sand and I must respect your fence and garden and also the area which you marked for a street and sidewalk outside your property.
So if I want a 100x100 house, with no fence and no garden and the space that's left is 100x140 - great. But if I also want a 1m fence and a 10m garden everywhere around my house then too bad - I can not build on this island because the W of the available space (100) is less than 1+10+100+10+1.

hmm, the above suggests that objects can not be overlapping. And while at first glance it makes sense maybe you do need overlapping objects? Perhaps it's a good example up to the part where I come to the island, haha :) So basically client draw area must be respected (the area of the island without the beach/padding), but objects can overlap...?

Hi,
Your terminology translation was correct, I meant exactly the same.
So let's summarize what we know so far:

lv_oj_set_size sets core_area + padding + border_width
The object draws its background on core_area + padding + border_width
margin is always transparent
lv_obj_set_pos(child, 0, 0) moves child to the parent's core_area (0;0)
margin is ignored in positioning, so core_area + padding + border_width will be positioned
children can be visible only on the parent's core_area

However, the island example was very nice it not applies to GUI in every case:

There is no reason to forbid overlapping. Moreover, it can be required during animations. For example, if you have a 3 button in a row and want to float them in from the left they might overlap each other during the animations.
It's natural that an object is bigger than its parent. Just think about the lists. If the scrollable area is too large it becomes scrollable.

What do you think?

YES to everything with one little clarification:

If 'core_area' is the blue rectangle then also 'YES' to 4.
Otherwise 4. I think should be:
lv_obj_set_pos(child, 0, 0) moves child to (0;0) of the blue rectangle (i.e. parent padding must be respected!)

... and, yes  - the island example does not apply to all the GUI cases (damn!) :) If you don't mind I will delete my island posts, because, nice as they may be, they just confuse the readers and add noise?

In 4, yes it's the blue area because the parent's padding should be respected.
Please, do not remove the island example because it shows our way of thinking. No problem if we have side tracks.

:+1:

just a follow-up to my earlier statement

I'm not a fan of any of the default width/height/labels. I would prefer is the default size for everything is 0, and the default text for anything is an empty/null string.

I noted today that that default "Text" value causes memory allocation and de-allocation.  Consider:
    lv_obj_t *btnSettingsLabel = lv_label_create(parent, NULL);
    lv_label_set_text(btnSettingsLabel, "My Text");

The default "Text" is copied and allocated during lv_label_create() (as it internally calls lv_label_set_text())
"Text" is freed, "My Text" is copied during lv_label_set_text
Needless memory fragmentation occurs if other allocations occur between the two calls.

Yes, this was addressed by Gabor in one of his early comments:
Default values:
You are right about "Text" and "Option1, Option2" ... default values have a negative effect on memory footprint and performance. I agree it should have a define in lv_conf.h to enable/disable these initial settings. While playing with the library it's better to have some init values but it's better to avoid them later when you overwrite them anyway.
So a define (in lv_conf.h) will govern whether the text objects will be created with some default text (for the lv_example apps) or withe empty strings (for when the lib is used 'in the field').

Regarding usage of themes in an application, the approach that Gabor decided lvgl should use is (below is a quote from an email discussion):

"You should use themes in your app if you want:

coding to be easy (objects are created with default "reasonable" sizes)
graphics to look nice (the theme defines the entire look of your app).

You can build an app without themes, in which case you will need to manage all of this on your own".
It's kinda like using layouts: "hey, you want your life to be easy? Use layouts. You want it to be hard and to manage everything on your own? Don't use layouts."

Remainder based on  #422: Store "focused" styles in the themes

I'm clarifying things to implement in v6.0
In case of this issue, several months have passed but it seems users don't really need a more advanced boxing model (yet). There were some improvements in fit policies. See this comment.
What seems really reasonable and I'm planning to add to v6.0 is to replace her/ver padding with left/right/top/bottom.
If later we decide to go for a more advanced boxing model we already have the ideas here.
Thank you very much for your ideas and contribution!

Thank you for the update!
On Sat, Mar 2, 2019 at 7:42 PM Gabor Kiss-Vamosi<EMAIL_ADDRESS>wrote:

I'm clarifying things to implement in v6.0
In case of this issue, several months have passed but it seems users don't
really need a more advanced boxing model (yet). There were some
improvements in fit policies. See this comment
https://github.com/littlevgl/lvgl/issues/838#issuecomment-466737762.
What seems really reasonable and I'm planning to add to v6.0 is to
replace her/ver padding with left/right/top/bottom.
If later we decide to go for a more advanced boxing model we already have
the ideas here.
Thank you very much for your ideas and contribution!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/littlevgl/lvgl/issues/302#issuecomment-468942438, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AMJ4qFjZ20P-RkpQyK5FPSHTs-JRM8Wkks5vSrf1gaJpZM4VGwec
.

padding.left/right/top/bottom is added to dev-6.0. Still not fully tested but at first look, everything seems working.


[Bug]: transformIgnorePatterns doesn't work with rules_js or rules_jest

What happened?
https://jestjs.io/docs/configuration#transformignorepatterns-arraystring
Jest doesn't transform node_modules by default and if you need to transform a dependency you have to use transformignorepatterns in jest config:
  transformIgnorePatterns: ["/node_modules/(?!(@rjsf|nanoid|antlr4))"],

This doesn't work in rules_js/rules_jest and the files are not transformed, with jest throwing an error.
I was able to fix this by doing:
 transformIgnorePatterns: ["/node_modules/.aspect_rules_js/(?!(@rjsf|nanoid|antlr4))"],

but that will break running jest outside of bazel.
Version
This is using bazel 5.2.0, rules_js 5.8.0 and rules_jest-0.14.3
I see this using rules_jest or running jest-cli using rules_js.
How to reproduce
No response
Any other information?
Might be worth to at least document this as its a fairly common thing to have in jest configs.
Fund our work

[ ] Sponsor our open source work by donating a bug bounty

See the tip explaining how to do the transform-ignore with pnpm: https://jestjs.io/docs/configuration#transformignorepatterns-arraystring (scroll down a bit to the "tip").
Then replace .pnpm with .aspect_rules_js. If you're also using pnpm outside bazel you can do .pnpm|.aspect_rules_js instead, or if you're using npm or yarn instead of pnpm outside bazel I think you can keep the non-pnpm exclusions for a total of 4?
Since the list of packages needs to be repeated 3-4 times I normally put the list of packages in a variable:
const ESM_PKGS = [
  '@rjsf'
  'nanoid'
  'antlr4'
].join('|')

const config = {
  transformIgnorePatterns: [
    // packages within the root pnpm/rules_js package store
    `<rootDir>/node_modules/.(aspect_rules_js|pnpm)/(?!(${ESM_PKGS})@)`,
    // files under a subdir: eg. '/packages/lib-a/'
    `(../)+node_modules/.(aspect_rules_js|pnpm)/(?!(${ESM_PKGS})@)`,
    // packages nested within another
    `node_modules/(?!.aspect_rules_js|.pnpm|${ESM_PKGS})`,
  ],
}

I'll close this issue for now but feel free to continue the discussion here if you're still having issues.

For any future folks who run into this, I ended up with:
transformIgnorePatterns: ["/node_modules/(?!(.aspect_rules_js|@rjsf|nanoid|antlr4))"],


fix: batch delegation collapses two requests with different arguments into a single memoized loader

Originally fixed by @maxbol in the PR https://github.com/ardatan/graphql-tools/pull/5189
Closes  #5188
Fixes #5189

Huge thank you to @ardatan for having a look at this! Corner case, but this means we can stop maintaining our own fork of the batch-delegation library. 🥳

Thank you for the PR again!


Missing 'add ons' after reboot

-->
Version of HACS 0.15.11

Describe the bug
After a resent reboot, whilst using version 0.15.9 HACS took a long time to come back up, When it finally came up id lost all my ‘add ons’ that were displayed in the ‘Overview’ page although everything seems to be working fine in the frontend. Ive now updated to v0.15.11 and the only add ons displayed in the overview page are:
Integrations - 'HACS' and
Plugin - 'Mini Media Player' that I reinstalled after this issue to see if it world resolve the problem, but it didn't.
Debug log
Ive filtered out the logs to show only the 'debug' errors

2019-10-22 17:31:48 DEBUG (MainThread) [hacs] Configuration type: yaml
-------------------------------------------------------------------
HACS (Home Assistant Community Store)

Version: 0.15.11
This is a custom integration
If you have any issues with this you need to open an issue here:
https://github.com/custom-components/hacs/issues
-------------------------------------------------------------------

2019-10-22 17:31:48 DEBUG (MainThread) [hacs.repository.integration.hacs.integration] Checking repository.
2019-10-22 17:31:50 DEBUG (MainThread) [hacs] 4947
2019-10-22 17:31:50 DEBUG (MainThread) [hacs] 2019-10-22 17:31:49
2019-10-22 17:31:50 ERROR (MainThread) [hacs] Validation for hacs/integration failed with GitHub returned 404 for https://api.github.com/repos/hacs/integration.
2019-10-22 17:31:50 DEBUG (MainThread) [hacs] [Unknown error] - Could not load HACS!
2019-10-22 17:31:50 DEBUG (MainThread) [hacs.repository.integration.custom-components.hacs] Checking repository.
2019-10-22 17:31:55 DEBUG (MainThread) [hacs] 4940
2019-10-22 17:31:55 DEBUG (MainThread) [hacs] 2019-10-22 17:31:49
2019-10-22 17:32:02 DEBUG (MainThread) [hacs.data] Saving data
2019-10-22 17:32:02 DEBUG (MainThread) [hacs.backup] Backup for /config/.storage/hacs.hacs, created in /tmp/hacs_backup/hacs.hacs
2019-10-22 17:32:02 DEBUG (MainThread) [hacs.backup] Backup dir /tmp/hacs_backup/ cleared
2019-10-22 17:32:02 DEBUG (MainThread) [hacs.backup] Backup for /config/.storage/hacs.installed, created in /tmp/hacs_backup/hacs.installed
2019-10-22 17:32:02 DEBUG (MainThread) [hacs.backup] Backup dir /tmp/hacs_backup/ cleared
2019-10-22 17:32:02 DEBUG (MainThread) [hacs.backup] Backup for /config/.storage/hacs.repositories, created in /tmp/hacs_backup/hacs.repositories
2019-10-22 17:32:02 DEBUG (MainThread) [hacs.backup] Backup dir /tmp/hacs_backup/ cleared
2019-10-22 17:40:37 DEBUG (MainThread) [hacs.http] Endpoint (overview) called
2019-10-22 17:42:41 DEBUG (MainThread) [hacs.http] Endpoint (repository) called
2019-10-22 17:42:45 DEBUG (MainThread) [hacs.data] Saving data
2019-10-22 17:42:45 DEBUG (MainThread) [hacs.backup] Backup for /config/.storage/hacs.hacs, created in /tmp/hacs_backup/hacs.hacs
2019-10-22 17:42:45 DEBUG (MainThread) [hacs.backup] Backup dir /tmp/hacs_backup/ cleared
2019-10-22 17:42:45 DEBUG (MainThread) [hacs.backup] Backup for /config/.storage/hacs.installed, created in /tmp/hacs_backup/hacs.installed
2019-10-22 17:42:45 DEBUG (MainThread) [hacs.backup] Backup dir /tmp/hacs_backup/ cleared
2019-10-22 17:42:45 DEBUG (MainThread) [hacs.backup] Backup for /config/.storage/hacs.repositories, created in /tmp/hacs_backup/hacs.repositories
2019-10-22 17:42:45 DEBUG (MainThread) [hacs.backup] Backup dir /tmp/hacs_backup/ cleared
2019-10-22 17:43:16 DEBUG (MainThread) [hacs.http] Endpoint (settings) called
2019-10-22 17:44:49 DEBUG (MainThread) [hacs.http] Endpoint (overview) called
2019-10-22 17:44:51 DEBUG (MainThread) [hacs.http] Endpoint (repository) called
2019-10-22 17:48:32 DEBUG (MainThread) [hacs.http] Endpoint (overview) called

/config/.storage/hacs.repositories probably got corrupted after the reboot.
That file contains the information about what you have installed with it.
If you have a backup of that file, you can restore it, if not you need to hit "install" on any missing "add-ons".

I have found a backup of the hacs.repositories file from v0.15.7, rename the current hacs.repositories file and copied over the backup file, restarted hassio but the problem still exists. Would it be best to just reinstall the add ons?

if you still have the problem with that, that means that you had the problem at that point to.
if you have an older backup you can use that, if not "reinstall" is the next thing to do.

Thank you, I've started to reload add-ons and all seems ok


Add filter option in logbook view based on tags

It should be possible to filter the (potentially many) entries in a logbook based on their tags.

By clicking a button in a new bar-like widget of tags the view should only display logbook entries with the selected tags

We have this functionality via defining separate logbook items and defining tags as filters, but now as a filter within the currently display logbook item. Do we want /need to add this functionality also for this case ?

I think this is implemented and can be done here:

Yes, but not directly on the view page (see my question above).

I am not too sure I understand this:

We have this functionality via defining separate logbook items and defining tags as filters, but not as a filter within the currently display logbook item. Do we want /need to add this functionality also for this case ?

One idea would be to add a tickmark to the tag entry fields to selectively filter by the chosen tags, as indicated below. In case of multiple tags one would probably need to define in addition, if the conditions are treated as an "and" or "or" .

We could also replicate the functionality on top, next to the "Logbook View" in order not to confuse entry of data with viewing of data


(low priority) automate CircleCI artifact staging

@oesteban said: the artifacts staging is not automatic in niworkflows, you need to do this in every test. Probably a good investmenat of time to set up a unified tear up callback for this.
https://github.com/poldracklab/niworkflows/blob/d03fb9f/niworkflows/tests/test_reports.py#L35

This is working. Closing


Add a ResNet50 feature extractor

We should add a simple feature extractor network based on the TF ResNet50 model to do feature extraction

@laureho @KristinaUlicna


[WIP] adding a PowerVC service catalog item

@agrare @Fryguy I get the following result from adding the dialog.
Which looks good at first:

But then the second tab doesn't fails:

Any idea why this happens?

:+1: looks like a great start @iv1111


Cannot read property '0' of undefined in weekly planner view

Hello, I'm seeing that after I go through the onboarding flow in the demo app I see the following error:

TypeError: Cannot read property '0' of undefined
at index.js:12
at p (index.js:44)
at d (index.js:63)
at beginWork (react-dom.production.min.js:132)
at o (react-dom.production.min.js:161)
at i (react-dom.production.min.js:161)
at u (react-dom.production.min.js:162)
at E (react-dom.production.min.js:169)
at w (react-dom.production.min.js:168)

The data specification changed a bit. I have updated the code. Can you test it and see if it works for you?
Thanks!

Its working now! Thank you so much for the fast response.


add lint rules for promises without await in test suites

originally this included tests without expectations as well, but in practice these are fine

#130


[MINOR] Generalize case transformation method for string type config entry

Why are the changes needed?

unify config value capitalization for String and Seq[String] configs
Generalize transformToUpperCase and transformToLowerCase for config entry
simplify transformation for configs of kyuubi.authentication  and kyuubi.frontend.protocols

How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[x] Run test locally before make a pull request

Codecov Report

Merging #4812 (13709bb) into master (e112e38) will increase coverage by 0.00%.
The diff coverage is 78.57%.

@@            Coverage Diff            @@
##             master    #4812   +/-   ##
=========================================
  Coverage     58.01%   58.02%
  Complexity       13       13
=========================================
  Files           583      583
  Lines         32548    32556    +8
  Branches       4317     4319    +2
=========================================
+ Hits          18882    18889    +7
- Misses        11849    11851    +2
+ Partials       1817     1816    -1

Impacted Files
Coverage Δ

...i/server/metadata/jdbc/JDBCMetadataStoreConf.scala
97.14% <ø> (-0.08%)
:arrow_down:

...in/scala/org/apache/kyuubi/config/KyuubiConf.scala
97.18% <75.00%> (-0.02%)
:arrow_down:

...scala/org/apache/kyuubi/config/ConfigBuilder.scala
96.77% <80.00%> (-0.71%)
:arrow_down:

.../scala/org/apache/kyuubi/metrics/MetricsConf.scala
97.56% <100.00%> (ø)

... and 14 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Could you have an check on this minor improvement? If it's not so necessary, tell me to close it.  @pan3793

Thanks, merged to master.


Show number of enabled features on extension options page

Description

could look like

Example URLs
chrome-extension://hlepfoohegkhhmjieoechaddaejaokhf/assets/options.html

That number is actually an approximation because it also includes a CSS features, both standalone and small fixes in refined-github.css
Since being exact with this count would make it verbose, I'd rather not, also because I hope people won't disable more than handful anyway.

Your explanation makes sense! I don't want to complicate things just for this minor change.
Just some colour for why I requested this:
I recently installed the extension, and occasionally want to compare a Refined GitHub feature to the original behaviour. There's a few ways to do this:

Disable all the features from the extension options (this takes a few clicks because the button is hidden under "Identify feature" and then "Toggle all features...", which also makes it a bit hard to find)
Disable the extension entirely (this is unfortunately what I ended up doing, but it works!)
Use the Identify feature button (the binary search is awesome, but way too many clicks for this simple purpose)

When I was still doing 1), sometimes I would forget if I had re-enabled all the features. So I'd go into the extension options to check...but there's no visual feedback for that. So I'd just click those 4 buttons again to make sure all the features were enabled.

"Toggle all features" is hidden specifically because it's the nuclear option and it has drawbacks like these. I don’t think adding a counter would be beneficial here.
I think every variation of that is already possible:

you want to see the whole native GitHub:

you disable the extension and re-enable it; It already works, it requires no effort on our part, and it's completely safe (no configuration loss like you get with point 1)

you want to see the native version of single feature:

you disable the single feature

you don't know what's affecting the page:

disable the extension
use "identify feature"

Reopening, the counter can be implemented for the number of features disabled (including hotfixes)

Features: 216 (1 off)


Search box works and collections

Fixes #9351
A few things to note:

The font size changes in the designs, for the text input, require 17px on large screens and 15px on small screens (it currently displays as 20px regardless of screen size).
The text input is a component we use in various places on the site, so changes to it have knock on effects.
The text input component could previously be one of two values 20px or 16px, which never adjusted to the screen size.
In order to get the font size to adjust based on screen size, I'm using our font() function to generate the correct classnames.
The font() method depends on a set of predefined font sizes we use throughout the site (none of which are the 17px and 15px the designs specify)

The upshot of this is that

The text sizes are close to, but not exactly those, defined in the designs
Everywhere we use the TextInput component, the sizes will have slightly changed and will also now respond to screen size.

Is this ok @DominiqueMarshall ?
Also, when the text size reduces on small screens, the input box doesn't align exactly with the submit button:

I started getting into it, but it's not that straight forward to fix and will likely have other knock on effects, so I thought best to get this in and open another issue for that.

@rcantin-w @alexwlchan I've used the form location property to determine whether the input value should be displayed or not. This should replicate the previous behaviour, i.e. we never fill the value if it's the global search in the header.  Thanks for spotting this.

@gestchild it did but it won't allow another value anymore (locally for me anyway), maybe having it in a useEffect but only for header?

@gestchild it did but it won't allow another value anymore (locally for me anyway), maybe clearing it in a useEffect but only for header?

doh, of course!

@rcantin-w have moved the logic inside the useEffect that runs when the router.pathname or router.query change

Looking good! One last thing (and I've already flagged that a little review of search in general might be good so could totally be a part of that) is that on clicking the Header magnifier, the focus stays there when in prod currently it focuses on the field. I'm not actually sure what's, but thought I'd raise!

"...the focus stays there when in prod currently it focuses on the field"
Thanks, I'll take a look

"...the focus stays there when in prod currently it focuses on the field" - fixed
Thanks for spotting it


Optimsation not following acquisition function suggestion.

Hi fmfn,
I want to start by thanking you for this very nice implementation of Bayesian optimisation that I've found very useful.
I've tried to visualise the 'thought process' of this optimisation method, and so tried to follow the code given here. Instead of ucb however, I've been using poi as my acquisition function as it seemed to work better for my specific problem.
Similar to the notebook, I've plotted the utility function underneath, marking the maximal point as that should be the next point probed. However, after the next iteration a different point seems to be probed, even if it has a worse acquisition function value than the other point.
I'm relatively new to the game of black box optimisation, even moreso for BO, so is this intentional or am I doing something wrong? Below I've attached the animation that I've generated to show the method in action [I've zipped it up as .mp4 are not supported here.], and there are certain points where the next best point (as predicted by the poi acquisition function) is not the next point that is actually probed.
Here is the code I am using to create the animation:
    # Define parameters used for the optimisation algorithm.
    acqFunc = "poi"
    acqKappa = 5
    acqXi = 0.1

    # Start by plotting the objective function being optimised. This could take a while.
    xVals = np.linspace(0, 1e4, num = 5000)

    yList = []

    for x in xVals:
            yList.append(BayesianObjective1D(x))

    # Begin the figure plot.
    fig = plt.figure("Optimisation Animation")

    acqAxis = plt.subplot(2, 1, 2)
    yAxis = plt.subplot(2, 1, 1, sharex = acqAxis)

    # Create optimisers.
    inputBounds = {"x1": (0, 1e4)}
    optimiser = BayesianOptimization(BayesianObjective1D, inputBounds, random_state = np.random.randint(1, 1e4), verbose = 0)

    # Initialise optimisation with 1 random point.
    optimiser.maximize(init_points = 1, n_iter = 0, acq = acqFunc, kappa = acqKappa, xi = acqXi)

    # Use points to generate initial prediction graph data.
    mean, stdDev = optimiser._gp.predict(xVals.reshape(-1, 1), return_std = True)
    # The utility function is used to choose the next point to query.
    utilFunction = UtilityFunction(kind = acqFunc, kappa = acqKappa, xi = acqXi)
    util = utilFunction.utility(bVals.reshape(-1, 1), optimiser._gp, 0)
    predictX, predictY = xVals[np.argmax(util)], np.max(util)

    # Create lists to store objects at each iteration.
    # Observed points. To be marked.
    obsList = [(optimiser.space.params.flatten(), optimiser.space.target)]
    # How the optimiser sees the function.
    gpList = [mean]
    # How the optimiser will pick its next point, and the point it picked.
    utilList = [(util, predictX, predictY)]
    # Store the polygons representing the confidence levels at each iteration. We multiply the standard deviation by 1.96 to get the 95% confidence interval.
    confidenceList = [yAxis.fill_between(xVals, mean + (1.96 * stdDev), mean - (1.96 * stdDev), alpha = 0.3, visible = False, color = "c")]

    # Iterate the optimiser to see how it evolves.
    for iteration in range(numIters):
            # Run the same code as above.
            optimiser.maximize(init_points = 0, n_iter = 1, acq = acqFunc, kappa = acqKappa, xi = acqXi)

            mean, stdDev = optimiser._gp.predict(xVals.reshape(-1, 1), return_std = True)
            util = utilFunction.utility(xVals.reshape(-1, 1), optimiser._gp, 0)
            predictX, predictY = xVals[np.argmax(util)], np.max(util)

            # Add the obtained values to the various lists.
            obsList.append((optimiser.space.params.flatten(), optimiser.space.target))
            gpList.append(mean)
            utilList.append((util, predictB, predictFoM))
            confidenceList.append(fomAxis.fill_between(xVals, mean + (1.96 * stdDev), mean - (1.96 * stdDev), alpha = 0.3, visible = False, color = "c"))

    yAxis.set(xlim = (0, 1e4), ylim = (-0.5, 1.1))
    acqAxis.set(xlim = (0, 1e4), ylim = (0, 1.1))
    yAxis.set_ylabel("FoM")
    acqAxis.set_ylabel("Probability of Improvement")
    acqAxis.set_xlabel("Magnetic field strength (Gauss)")

    # Plot the functions that won't change with each frame.
    yAxis.plot(xVals, yList, color = "b", linewidth = 3)

    # Plot the changing graphs with their inital values.
    meanLine = yAxis.plot(xVals, gpList[0], color = "k", linestyle = "--")[0]
    acqLine = acqAxis.plot(xVals, utilList[0][0], color = "purple")[0]
    probedScat = yAxis.scatter(obsList[0][0], obsList[0][1], marker = "v", color = "r")
    predScat = acqAxis.scatter(utilList[0][1], utilList[0][2], marker = "^", color = "r")
    confidenceList[0].set_visible(True)

    def animate(i):
            # Define what the graph does on each frame.
            meanLine.set_ydata(gpList[i])
            acqLine.set_ydata(utilList[i][0])
            probedScat.set_offsets(np.c_[obsList[i][0], obsList[i][1]])
            predScat.set_offsets(np.c_[utilList[i][1], utilList[i][2]])
            confidenceList[i - 1].set_visible(False)
            confidenceList[i].set_visible(True)

            return meanLine, acqLine, probedScat, predScat, confidenceList[i]

    animator = FuncAnimation(fig, animate, frames = len(obsList), interval = 1e3, blit = True)

    # Set up formatting for the movie files
    Writer = writers['ffmpeg']
    writer = Writer(bitrate = 1800)

    animator.save("show_opt.mp4", writer = writer)

show_opt.zip

Try passing the actual current y_max value to util = utilFunction.utility(xVals.reshape(-1, 1), optimiser._gp, 0) instead of 0.

@Bacoknight hallo, Clould you tell me your function BayesianObjective1D how to create

@majichang The BayesianObjective1D function is a python function which has only 1 variable. In my specific case, it's a black box function which calls upon another program that I did not write, but which returns a value that I then change a little bit and it returns a single value. The function could be anything however. This example shows an example of a 1D function which you could use.
Hopefully that answers your question.


Make it possible to select multiple combinations of processors and exporters

I couldn't think of a simple API that would support various combinations of exporters (GRPC, HTTP, Console, InMemory ...) and processors(Batch, simple ...). Do you have some suggestions?
Originally posted by @Vunovati in https://github.com/Vunovati/pino-opentelemetry-transport/pull/1#discussion_r1273448920

A few things:

provide a way to create your pino transport for OTLP based on this one
add support for the more basic cases via options, I would recommend adding HTTP support as it seems more popular


Crash if blank lines in cairis.cnf

If there are blank lines in cairis.cnf an IndexError is thrown.

Pushed an update to BorgFactory that resolves this problem.


MMOD loss may go negative if detection doesn't match a truth box but does match an ignore box

Expected Behavior
MMOD loss never goes negative for valid input.
(Note that what constitutes "valid input" may need to be discussed. In my case, there are correct truth-rects that are very close to each other. They also overlap so much that it does not look like a great idea to try to teach all of them. So I'm setting a stricter overlaps_nms, and setting some of the truth-rects to be ignored. However, I don't want to completely disregard any of them (they contain valuable information), so for different epochs I'm randomly selecting which rects are to be ignored. Thought this should be fine, as long as there are no non-ignored rects that overlap, as per the overlaps_nms that I have set.)
Current Behavior
When there are ignore-rects very close to and overlapping with the (non-ignore) truth-rects, it looks like it's possible that truth_match <= options.truth_match_iou_threshold, while overlaps_ignore_box(*truth, dets[i].rect) == true. In other words, a candidate detection doesn't quite match the (correctly-)best-matching non-ignore rect with > options.truth_match_iou_threshold, but does overlap an ignore-box.
As a result, it seems that the loss may go negative. (Specifically because in this case the candidate detection isn't added to final_dets, and therefore the corresponding out_data isn't added to loss.)
Note that it's not just the loss that goes sour; also the training itself does not really "work", i.e. the gradients are not update correctly it seems. (This seems to hold at least in a real-world project I'm working with, where the network after a long training run eventually detects nothing – whereas a shorter training run works ok. But for this gradient part I don't have how-to-reproduce instructions, at least just yet. However, I guess loss and gradient go hand-to-hand, so possibly fixing the negative loss will fix the gradient updates as well.)
Workarounds
I have tried the following workarounds:

Set options.truth_match_iou_threshold = 0.25 (arbitrary selection).
Change code so that the gradient is not updated for samples for which the contribution to loss would be negative: https://github.com/reunanen/dlib/commit/0d55d3cf1bd9cd082f5bd8361fe551972c92ee61

While these approaches seem to alleviate the problem to some degree at least, I can't say I'm very happy with either of them. (Think they are only band-aid at best.)
Steps to Reproduce
Clone current master branch, and cherry-pick this: https://github.com/reunanen/dlib/commit/781065f62f57ccc4466aa5e110f66642e99bc438
Run the dnn tests – the newly added test should fail.

So while ideally I would like the code to Just Work (tm), also suggestions how to deal with these kinds of situations at the callsite are very welcome. (If parameter tuning is the way to go, then suggestions how to do it programmatically depending on the input truth-boxes would be appreciated.)

The loss should only end up going negative if it's impossible to produce the requested label output, given the settings.  There is some auto-ignoring already in the code when a truth box is obviously outside the area the cnn can find.  If the image_rect_to_feat_coord() method maps a truth box to a point covered by an ignore box maybe it should auto-ignore that truth box too.  That sounds like the root of your problem.  I'm not sure this is such a great idea though.  It's kinda funny to have truth boxes that overlap ignore regions.
Really you should train with the labels you want to detect.  Why can't you do that in your case? Just because the NMS rules it out?  One way or another you have to train with a set of labels that's achievable by the detector.

Thanks for your prompt reply, Davis.

The loss should only end up going negative if it's impossible to produce the requested label output, given the settings.

Yep, have generally understood this for a while already. But guessing had missed that this apparently applies to ignore-rects as well. (Didn't really think ignore-rects were part of "the requested label output".)

If the image_rect_to_feat_coord() method maps a truth box to a point covered by an ignore box maybe it should auto-ignore that truth box too. That sounds like the root of your problem. I'm not sure this is such a great idea though.

Yeah – doesn't sound great to me either. I don't really want to have the truth-boxes ignored in this situation. I do want a detection for the non-ignored truth box. I just don't want to make the network learn that there's nothing in the overlapping rect (because I have to assume that there is). Instead, I wanted the other rect to have no effect whatsoever (in terms of gradient or loss).

Really you should train with the labels you want to detect. Why can't you do that in your case? Just because the NMS rules it out? One way or another you have to train with a set of labels that's achievable by the detector.

Yeah, I guess I need to take a step back maybe. At some point, I was receiving annotations that were overlapping a lot. (When I say "I", I mean an automated system that I've been writing – so I'm not able to tweak parameters manually, and I can't expect that the users will do it either. So the default behaviour should be at least somehow sane, even if the performance can be improved by problem-specific parameter tuning).
I am sure some of these highly overlapping annotations were user errors. On the other hand, some of them appeared to be perfectly valid; but I thought they might be too challenging (if not next to impossible) to learn correctly.
(Think of something like this, for example. Suppose we have a hand detector, which is generally trained by drawing rects tightly around just hands (not arms). Then for the example image it appears that it's not exactly wrong to draw eight almost completely overlapping rects (well all of them might not exactly overlap... but for the sake of argument, let's pretend they do). Now, for a human being it's pretty clear from the context that there are in total 8 hands there, but I'm afraid it might be a bit too much for a neural network to figure out, if there's not extensive training material available. Or what do you think? This picture of hands is a toy example of course, but I think the challenge is still real: objects can overlap a lot in images, so at least such annotations are not incorrect, right? (Regardless of whether it's possible to detect all these objects separately.) Here's another example. While I'm certainly not an expert in the sheep domain, I think a complete set of annotations would overlap a whole lot. Note that I'm not saying I need to detect every individual sheep (although that would be wonderful); instead, I want to have a training process that behaves reasonably, when presented this kind of annotation input. Either with a fixed set of default parameters, or some parameters I can figure out programmatically (given the truth-rects).)
So what I did previously was set NMS to something like 70% by default, although the incoming data would have suggested a much higher value, e.g. 95%. Limiting the NMS threshold by itself created problems, so I started to auto-ignore one from each pair (or two from each triplet, or three from each quadruplet... but alternating from one epoch to another). (Here, by auto-ignoring I mean I set the ignore flag on the application side of it, and not inside dlib.)
But looking at this again now, it seems that it's not enough to simply set those truth rects (which overlap more than what is allowed by overlaps_nms) to be ignored.

I will look more into this, and hopefully come up with some solution / suggestion.


feat: add support for key schemas

Currently we only store the schema of value columns on-chain, while key columns are implicit by the number of keys emitted in the StoreSetRecord event (and always typed bytes32).
This PR adds explicit support for key schemas to Store, World and CLI (tablegen + deploy):

Key schemas follow the same format as value schemas and are stored in the Schema table. This changes the schema of the Schema table to { valueSchema: Bytes32, keySchema: Bytes32 } (used to be just { schema: Bytes32 })

ooc is the world only doing the minimal necessary to bootstrap? It’s not registering userland schemas and systems etc right? That’s done via deploy script?

Correct, the World only sets up its own internal tables (and soon internal systems)


Initialize FastHotStuffConsensus when node is a validator

Initialize FastHotStuffConsensus when node is a validator
Wrap up wiring

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

Current dependencies on/for this PR:

feature/proof-of-stake

PR #875

PR #889

PR #906   👈

This stack of pull requests is managed by Graphite.


libnd4j: Layer norm only supports largest axis, backprop doesn't support 4d?

java.lang.RuntimeException: Op [layer_norm] execution failed

	at org.nd4j.linalg.cpu.nativecpu.ops.NativeOpExecutioner.exec(NativeOpExecutioner.java:1669)
	at org.nd4j.linalg.factory.Nd4j.exec(Nd4j.java:7431)
	at org.nd4j.Temp.testLayerNormNCHW(Temp.java:127)
Caused by: java.lang.RuntimeException: NDArray::applyTrueBroadcast method: the shapes of this and other arrays are not suitable for broadcast operation !
	at org.nd4j.nativeblas.Nd4jCpu$NativeOps.execCustomOp(Native Method)
	at

This broadcast will only work when gain/bias is the last value? i.e., [mb,h,w,c] + [c] works, but obviously [mb,c,h,w] + [c] doesn't... we need [mb,c,h,w]+[c,1,1] at least (or equivalently +[1,c,1,1])
Backprop looks off too for the 4D case:
https://github.com/eclipse/deeplearning4j/blob/master/libnd4j/include/ops/declarable/generic/transforms/layer_norm.cpp#L79
Consider the [n,c,h,w] axis 1 case - we should be summing over axes [0,2,3] not just [0].
And I can't find any 4d test cases in libnd4j either.

Layer norm 4d case forward pass confirmed working and correct for both NCHW and NHWC cases (java tests added here: https://github.com/SkymindIO/deeplearning4j/pull/174)
However, backprop is throwing an exception for both NCHW and NHWC cases. Reproducible with the following test case:
    @Test
    public void testLayerNorm4d() {
        int mb = 3;
        int ch = 4;
        for(boolean nchw : new boolean[]{true, false}) {
            INDArray x = Nd4j.rand(DataType.FLOAT, nchw ? new long[]{mb, ch, 8, 8} : new long[]{mb, 8, 8, ch});
            INDArray gain = Nd4j.rand(DataType.FLOAT, ch);
            INDArray bias = Nd4j.rand(DataType.FLOAT, ch);
            INDArray gradAtOut = x.like();

            INDArray xGrad = x.like();
            INDArray gainGrad = gain.like();
            INDArray bGrad = bias.like();

            Nd4j.exec(DynamicCustomOp.builder("layer_norm_bp")
                    .addInputs(x, gain, bias, gradAtOut)
                    .addOutputs(xGrad, gainGrad, bGrad)
                    .addIntegerArguments(1, 2, 3)
                    .addBooleanArguments(nchw)
                    .build());
        }
    }

o.n.l.c.n.o.NativeOpExecutioner - Failed to execute op layer_norm_bp. Attempted to execute with 4 inputs, 3 outputs, 0 targs,1 bargs and 3 iargs. Inputs: [(FLOAT,[3,4,8,8],c), (FLOAT,[4],c), (FLOAT,[4],c), (FLOAT,[3,4,8,8],c)]. Outputs: [(FLOAT,[3,4,8,8],c), (FLOAT,[4],c), (FLOAT,[4],c)]. tArgs: -. iArgs: [1, 2, 3]. bArgs: [true]. Input var names: [input, gain, bias, layernorm-grad]. Output var names: [input-grad, gain-grad, bias-grad] - Please see above message (printed out from c++) for a possible cause of error.
java.lang.RuntimeException: Op [layer_norm_bp] execution failed
	at org.nd4j.linalg.cpu.nativecpu.ops.NativeOpExecutioner.exec(NativeOpExecutioner.java:1710)

Confirmed fixed, including backprop and gradient checks.


Resolve Google Calendar events location with Faros Geocode API

Description
Resolve Google Calendar events location with Faros Geocode API
Type of change

[ ] Bug fix
[x] New feature
[ ] Breaking change

Issues
https://github.com/faros-ai/airbyte-connectors/issues/216

@Roma-Kyrnis please finish up the tests on this PR


chore: Adapt all pipelineruns to Konflux

Description
This pull request removes all pipelinesruns related with konflux-ci namespace and adapt to a konflux component world.
Issue ticket number and link
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist:

[ ] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added meaningful description with JIRA/GitHub issue key(if applicable), for example HASSuiteDescribe("STONE-123456789 devfile source")
[ ] I have updated labels (if needed)

Do we need to take care of this failure? Otherwise lgtm

@dheerajodha yep, we need to remove https://github.com/redhat-appstudio/infra-deployments/blob/c11156ba7b899ef5f6c19689db3eecf1ac76056f/components/konflux-ci/base/repository.yaml#L22-L28, which should remove this check

@dheerajodha yes, we need to remove cr in infra-deployments from here: https://github.com/redhat-appstudio/infra-deployments/blob/c11156ba7b899ef5f6c19689db3eecf1ac76056f/components/konflux-ci/base/repository.yaml#L22-L28


Add cabal multi cradle

This new cradle type allows you to easily specify all the different parts of a cabal project without
lots of boilerplate.
cradle:
  cabal:
    - path: "./src"
      component: "lib:hie-bios"
    - path: "./test"
      component: "test"

I will add a test as I didn't even try the cradle after writing it.
If there are nested multi-cradles then at each nesting level the most specific path is chosen. They are not flattened together.

If there are nested multi-cradles then at each nesting level the most specific path is chosen. They are not flattened together.

Ok, that is the better behaviour imo as well, but we should document it somewhere.
Other than that, it looks good to me, but I have yet to test the pr myself.

I added the test and some more documentation as you suggested.

We need more tests. Simple tests that could be nice for multi-cradles:
Given a hie.yaml specification and a filepath to some project, what cradle would be used for the file.


go 1.12.7

Fixes #244

oops. just noticed the other PR #239 for this

closing this for now. if needed will reopen

This PR passed CI so I'd go ahead and reopen this.


Remove timeout in awaitable

Closed #650
cc @fyellin

Now that we have eliminated timeouts, I really do hate the fact that we are doing a busy wait.  Would it make sense to do a very slow backoff?  Maybe call poll() ten times in a row, and only then do we start to sleep, say 1ms between calls to poll().
For synchronous calls, I was wondering if it makes sense for us to use poll_wait instead of poll, but it really doesn't.  poll_wait waits until Everything on the queue is done, rather than waiting until just the action we're interested in is done.

It's probably more efficient to invest our time and energy into other things until upstream wgpu-native implements callbacks/futures/promises or something of that nature. Then we can build our polling-free implementation on top.

@Korijn I agree that we (hopefully) eventually get a polling-free implementation, but in the mean time, adding a bit of logic to sleep a bit longer than zero seconds sounds like a good idea to me. Apparently in some cases the future may take over 5 s to resolve, and that's a much longer time to busy-wait that we first anticipated.
@fyellin do you have time to create a pr for that?
Maybe something like:

Yes.  That was pretty much my thoughts exactly.  I didn't mind constant polling when we believed the results would always be returned quickly.  But now that we realize that polling may take 5s or more, than's not reasonable.  I'll come up with something reasonable (and easy to modify if you don't like it) and submit a PR.

It is clear that the use case in #650 is compute shaders right? For real time rendering use cases, results should always be returned quickly.
Regardless, I think both of you are probably right that some kind of back off mechanism is appropriate.

Probably, but not necessarily.
I could imagine someone attempting to do an extremely complicated rendering
with multiple light sources and complicated shadows and rendering this to a
texture rather than the screen.  The only way to get a texture from the GPU
to the CPU is via a buffer.
On Wed, Dec 11, 2024 at 12:23 PM Korijn van Golen @.***>
wrote:

It is clear that the use case in #650
https://github.com/pygfx/wgpu-py/issues/650 is compute shaders right?
For real time rendering use cases, results should always be returned
quickly.
Regardless, I think both of you are probably right that some kind of back
off mechanism is appropriate.
—
Reply to this email directly, view it on GitHub
https://github.com/pygfx/wgpu-py/pull/651#issuecomment-2537046189, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABC2LIJ5UKEIAFXNWR7I6FL2FCNKRAVCNFSM6AAAAABTIWEPQOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZXGA2DMMJYHE
.


How do I set a partial video panorama?

First: your framework is intuitive and robust and I am really thinking about donating coffee :-)
Having done your tutorials, I am now at the last one with video. It works.
I thought about using a GoPro-Video for that. Problem is, it is a partial panorama encoded in a fisheye image. The partial parameters do not work for video. How do I set a partial video panorama?

I've never tried to use a partial video panorama, but I see no reason why it wouldn't work.
However, a GoPro video isn't going to work with reprojecting it, since only equirectangular video is supported. If you convert the video to equirectangular projection, it should work.


Feature/dev 1435 user and policy tests

Adds tests for:

Bad password rejection on user create
Successful user create with groups and password
Add and remove user's groups with update
User delete & inspect
Successful admin create with groups and password
Add and remove admin's groups with update
Admin delete & inspect
Create policies by user
Create policies by group
Allow only authorized users to create volume in namespace
Allow only users in authorized groups to create volume in namespace
Deny namespace create to users

How has this been tested please?

This PR now also corrects some out of date test logic that was causing failures with newer CLI versions.
@andrelucas This has been tested running BATS locally on my machine with CLI_BRANCH=master.
This PR however will break older CLI versions than master  in the following way:
✗ create rule no namespace
   (from function `assert_failure' in file /home/joe/git/vol-test/test/test_helper/bats-assert/src/assert.bash, line 140,
    in test file ./cli-rules.bats, line 27)
     `assert_failure' failed

   -- command succeeded, but it was expected to fail --
   output : default/test-no-namespace
   --
 ✗ create disk -  no namespace
   (from function `assert_failure' in file /home/joe/git/vol-test/test/test_helper/bats-assert/src/assert.bash, line 140,
    in test file ./cli-volume.bats, line 28)
     `assert_failure' failed

   -- command succeeded, but it was expected to fail --
   output : default/nonamespace
   --

This is due to a behaviour change in the CLI.
I think the correct thing to do would be to run BATS with the tip of master (of some other develop branch) to support things like this. However there may be a better way to do this.

After a discussion with @croomes we have decided to use a new release of CLI to get around this issue for now. I have added a commit to this PR to bump the CLI_VERSION number


(probably) Doesn't work with Mac OS X

Probably due to sed difference: http://stackoverflow.com/questions/9744300/sed-command-not-working-in-mac
I get following error messages:
Remove unuseful file error: Error: ENOENT, unlink 'mypage/admin/includes/CMB2/readme.txt'
sed -i '5,54d;5,54d;' /Users/user_name/Work/vagrant/www/wordpress/mypage/web/app/plugins/myplugin/public/assets/js/public.js
stderr: sed: 1: "/Users/user_name/Work/vagra ...": invalid command code j

sed -i '276,305d;276,305d;' /Users/user_name/Work/vagrant/www/wordpress/mypage/web/app/plugins/myplugin/admin/views/admin.php
stderr: sed: 1: "/Users/user_name/Work/vagra ...": invalid command code j

sed -i '61,64d;61,64d;' /Users/user_name/Work/vagrant/www/wordpress/mypage/web/app/plugins/myplugin/admin/assets/css/admin.css
stderr: sed: 1: "/Users/user_name/Work/vagra ...": invalid command code j

And more similar to that.

Ok i can add a check for the Mac OSX


Flutter is an early-stage open-source project.

when the early-stage finish?

Thanks for reaching out! Hard to say, but we're seeing some of our users ship into stores. We have some features available today, and others (like accessibility) that need more work. Please keep an eye on us, via this issue tracker. Thanks!


Car mode

Add a mode where the player controls are fullscreen
Mostlr useful while driving

Shoud it be another state of the shell.xaml triggered by a car button or another option in the menu?

Probably a button somewhere

If possible, should detect bt associated with car and auto switch too.

I created a new state that's triggered by the Car Button in the top left corner of the RootControlGrid.

This is really good

I never used GIT before, is there a way that I can commit my code for @deltakosh to review? When I try to Push I get a 403 error in VS17.

Just fork the repo and you will be able to submit a PR:)

This can be closed.


gulp-browserify is not maintained

Could that be at least changed in the repo?
I mean, it's been blacklisted for over a year, no reason to have bad code here, right?
https://medium.com/hafiz-ismail-sogko/gulp-browserify-the-gulp-y-way-bb359b3f9623

Already done! Or have I missed something?


Change namespaces of update classes

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 100.00%. Comparing base (35ab5b3) to head (4ff7f4b).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff             @@
##              master       #24   +/-   ##
===========================================
  Coverage     100.00%   100.00%
  Complexity       887       887
===========================================
  Files            200       200
  Lines           3160      3160
===========================================
  Hits            3160      3160

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Improve documentation

Initially I started to put the keys that should work in the README, but given that this list is growing, I think it is becoming less convenient.
I think it should be a separate page, with the used keys listed per HomeKit service (and the characteristic they map too).

Probably also need to add a troubleshooting guide (what to do/check if you experience unexpected behavior).
Might help for a first analysis in issues like #14 en #19

Started working on this in a new docs folder on the z2m-exposes branch (where I work on #18). Also see PR #31.
This will be published to https://arno.dev/homebridge-z2m/ using GitHub Pages.

Closing this issue now that #31 is merged.
Still might add a troubleshooting section later on, but I'll have to see what kind of issues arise with this new version first.

Closing this issue now that #31 is merged.
Still might add a troubleshooting section later on, but I'll have to see what kind of issues arise with this new version first.


Weird interaction with asdf version manager

When trying to start an application with overmind s I got this error message: overmind: Can't find tmux. Did you forget to install it?. Of course I do have tmux installed so the message is incorrect.
Turns out that the issue is caused due to some interaction with the asdf-vm: https://asdf-vm.com/#/. I was missing a specific Node version specified in .node-version. After I removed the file or installed the correct version overmind s ran correctly again.
Installed versions

Overmind v2.1.0
Tmux 3.0a
asdf v0.7.6

Overmind does nothing fancy here, it just runs which tmux and expects it to run without errors: https://github.com/DarthSim/overmind/blob/master/start/command.go#L148-L150. If Overmind can't find tmux, try to run which tmux yourself.


C# 9 init-only properties are writable

Steps to reproduce
Add-Type -CompilerOptions '-langversion:preview' -TypeDefinition '
    public class Test
    {
        public int MyInitOnlyProperty { get; init; }
    }'

$test = [Test]@{ MyInitOnlyProperty = 10 }
$test.MyInitOnlyProperty = 30
$test

Expected behavior
# Expect this to work
$test = [Test]@{ MyInitOnlyProperty = 10 }

# Expect this to throw
$test.MyInitOnlyProperty = 30
InvalidOperation: 'MyInitOnlyProperty' is a ReadOnly property.

Actual behavior
$test = [Test]@{ MyInitOnlyProperty = 10 }
$test.MyInitOnlyProperty = 30
$test
# MyInitOnlyProperty
# ------------------
#                 30

Environment data

Name                           Value
----                           -----
PSVersion                      7.1.0-rc.1
PSEdition                      Core
GitCommitId                    7.1.0-rc.1
OS                             Microsoft Windows 10.0.18362
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Other
This is implemented as modreq(System.Runtime.CompilerServices.IsExternalInit) on the setter's return parameter.
$modNames = [Test].GetProperty('MyInitOnlyProperty').
    SetMethod.
    ReturnParameter.
    GetRequiredCustomModifiers().
    FullName

# Type can be embedded in the assembly if targeting netstandard, so name must be used instead of type identity.
$modNames -contains	'System.Runtime.CompilerServices.IsExternalInit'

Technically the binder should be throwing whenever it sees modreqs it doesn't understand, according to EMCA-335.  Not necessarily advocating for that though.

Direct type name comparisons may not be necessary depending on the result of dotnet/runtime#43638

Type can be embedded in the assembly if targeting netstandard, so name must be used instead of type identity.

A bit more details on matching by full name, from https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-9.0/init#metadata-encoding

The compiler will match the type by full name. There is no requirement that it appear in the core library. If there are multiple types by this name then the compiler will tie break in the following order:

The one defined in the project being compiled
The one defined in corelib

If neither of these exist then a type ambiguity error will be issued.

When using the init language feature in a net461 project with a System.Runtime.CompilerServices.IsExternalInit type defined in the project, the produced dll works fine in pwsh, and the returned IsExternalInit type from GetRequiredCustomModifiers() in this case is from that dll:
> Add-Type -Path C:\arena\apps\init\bin\Debug\net461\init.dll
> $s = [init.Class1].GetProperty('MyInitOnlyProperty')
> $t = $s.SetMethod.ReturnParameter.GetRequiredCustomModifiers()
> $t[0].Assembly

GAC    Version        Location
---    -------        --------
False  v4.0.30319     C:\arena\apps\init\bin\Debug\net461\init.dll

We discussed this in the Engine working group (2021/07/22).
We agree that PowerShell should look for and respect the init-only metadata on objects. Without having a deeper look at the code paths involved, we're unsure whether there would need to be special casing applied to usage of hashtable-initialization syntax, which we feel maps closely to C# initialization syntax and should be permitted to set init-only properties (e.g., [TypeName]@{ Property = 'value' })
In all other cases where users attempt to set init-only properties directly from PowerShell, we think PowerShell should prevent this, and throw a similar error to existing cases where a property is not publicly settable.

I had a look at this issue and it appears the best/most appropriate place to handle this might in the type adapter - it specifically affects .NET properties, and all facilities for assignment to properties (which is what we're trying to prevent) rely on adapter metadata anyway. I tried it and found that it actually appears to work perfectly fine:

Cast-initialization still works, (type conversion via parameterless constructors doesn't explicitly check whether all target field/properties are settable, it just fails if assignment does)
Utilities like Get-Member automatically reflects the change
Assignments to init properties in any other context is blocked by ETS:

PS ~> Add-Type 'public class StringShrine { public string Value { get; init; } }'
PS ~> [StringShrine]@{ Value = 'Initial string value' } |Tee-Object -Variable s

Value
-----
Initial string value

PS ~> $s.Value = 'Updated string value'
InvalidOperation: 'Value' is a ReadOnly property.
PS ~> $s |Get-Member Value

  TypeName: StringShrine

Name  MemberType Definition
----  ---------- ----------
Value Property   string Value {get;init;}

@IISResetMe nice work! Does this just need tests added to be a viable PR to be reviewed?

@JustinGrote It needs tests + I want to refactor it to be a bit simpler (we don't necessarily need to surface a new InitOnly trait to the user-facing API, we just need to make sure the "settability" of the affected property is correctly reflected). I'll work on rewriting it this week and then we can open a PR :)

Still Active

Still Active


JP - SE-510 DRY Test.scala

This PR fixes scala-exercises/scala-exercises#510 in this project:

Removes Test.scala file
Updates the Test.scala reference, pointing to the one defined at the definitions artifact.

Please, @dialelo @fedefernandez  could you review?
Keep in mind, this PR should be merged once the new version 0.2.2-SNAPSHOT is released.
Thanks!

Thanks! LGTM!


'Other files' search results node should not have an empty uri

https://github.com/Microsoft/vscode/blob/c8ac8ec30096bdabf1041fd0bdf271d02e3ed4ab/src/vs/workbench/parts/search/common/searchModel.ts#L542
Either give it at least a scheme, like URI.from({scheme: 'empty'})
Or try to refactor so that it doesn't need a URI at all.

Verified that uri.parse('') got removed by code review


LinkBubbleMenu not displayed if your Editor is inside a MUI Dialog modal

Is your feature request related to a problem? Please describe.
LinkBubbleMenu is using MuiPopper wrapper, the problem is with the zIndex value between 3-4 by default (bug?)
Describe the solution you'd like
My expectation is to see the Link bubble menu from anyway, even when executing it inside a Dialog modal (but we see nothing on click)
Describe alternatives you've considered
My temp solution is to add this code to my createTheme to make it work:
createTheme({
MuiPopper: {
styleOverrides: {
root: {
// a fix for the tiptap links inside a modal
zIndex: "1300 !important"
}
}
}
})

I have used like this in createTheme as alternative.
MuiPopper: {
        styleOverrides: {
          root: {
            '&.MuiTiptap-ControlledBubbleMenu-root': {
              zIndex: 'var(--mui-zIndex-drawer)'
            },
            '&.MuiPopper-root[class*="ColorPickerPopper-root"]': {
              zIndex: 'var(--mui-zIndex-drawer)'
            }
          }
        }

There is another approach that's been discussed before here to avoid this problem https://github.com/sjdemartini/mui-tiptap/issues/206#issuecomment-2133851815
But I'll look into changing the default zIndex style too.

I've updated the default z-index of the bubble menus and poppers to use theme.zIndex.tooltip to fix this problem, released in v1.14.0.

@sjdemartini Great, thanks!


[Bug]: iOS 18 Simulator Problem

Platform
iOS 18
Plugin
share_plus
Version
10.0.0
Flutter SDK
3.24.3
Steps to reproduce
I updated my simulator to iOS 18 and now I have very weird problems with simulator.
I have an open issue (https://github.com/flutter/flutter/issues/155535)  about flutter but I noticed this now.
When I use shareXFiles to share my file, the result is unexpected.

Code Sample
Rect? rect = shareButtonRect(shareButtonKey);
Share.shareXFiles([XFile(file)], subject: 'Export', sharePositionOrigin: context.isLargeScreen || context.isMediumScreen ? rect : null);

Logs
UIKeyboardLayoutStar implements focusItemsInRect: - caching for linear focus movement is limited as long as this view is on screen.
Failed to request default share mode for fileURL:file:///Users/bahadirarslan/Library/Developer/CoreSimulator/Devices/AA46777B-F7E7-4683-B1E5-B7C893100CAB/data/Containers/Data/Application/53338742-DD2D-43D5-9804-0EA336AEFDBC/Documents/exports/export_a36ccd37-a40d-40a3-b6b9-ce5118d2c60a.xlsx error:Error Domain=NSOSStatusErrorDomain Code=-10814 "(null)" UserInfo={_LSLine=1734, _LSFunction=runEvaluator}
Only support loading options for CKShare and SWY types.
error fetching item for URL:file:///Users/bahadirarslan/Library/Developer/CoreSimulator/Devices/AA46777B-F7E7-4683-B1E5-B7C893100CAB/data/Containers/Data/Application/53338742-DD2D-43D5-9804-0EA336AEFDBC/Documents/exports/export_a36ccd37-a40d-40a3-b6b9-ce5118d2c60a.xlsx : Error Domain=NSCocoaErrorDomain Code=256 "The file couldn’t be opened."
error fetching item for URL:file:///Users/bahadirarslan/Library/Developer/CoreSimulator/Devices/AA46777B-F7E7-4683-B1E5-B7C893100CAB/data/Containers/Data/Application/53338742-DD2D-43D5-9804-0EA336AEFDBC/Documents/exports/export_a36ccd37-a40d-40a3-b6b9-ce5118d2c60a.xlsx : Error Domain=NSCocoaErrorDomain Code=256 "The file couldn’t be opened."

Flutter Doctor
bahadirarslan@bahadirsmac % flutter doctor -v
[✓] Flutter (Channel stable, 3.24.3, on macOS 14.6.1 23G93 darwin-arm64, locale en-TR)
    • Flutter version 3.24.3 on channel stable at /Users/bahadirarslan/Development/SDKS/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 2663184aa7 (12 days ago), 2024-09-11 16:27:48 -0500
    • Engine revision 36335019a8
    • Dart version 3.5.3
    • DevTools version 2.37.3

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /Users/bahadirarslan/Library/Android/sdk
    • Platform android-35, build-tools 34.0.0
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.9+0-17.0.9b1087.7-11185874)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 16.0)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 16A242d
    • CocoaPods version 1.15.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2023.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.9+0-17.0.9b1087.7-11185874)

[✓] VS Code (version 1.93.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.96.0

[✓] Connected device (6 available)
    • Bahadır’s iPhone (mobile)       • 00008120-00120CC93663C01E            • ios            • iOS 18.0 22A3354
    • iPhone 15 Pro (mobile)          • 62B1A11F-E38A-4906-A556-58EDD416CEEA • ios            • com.apple.CoreSimulator.SimRuntime.iOS-17-5 (simulator)
    • iPhone 16 Pro Max (mobile)      • 3BE587FB-5A67-4CCB-84D5-4A24C6EC42DA • ios            • com.apple.CoreSimulator.SimRuntime.iOS-18-0 (simulator)
    • macOS (desktop)                 • macos                                • darwin-arm64   • macOS 14.6.1 23G93 darwin-arm64
    • Mac Designed for iPad (desktop) • mac-designed-for-ipad                • darwin         • macOS 14.6.1 23G93 darwin-arm64
    • Chrome (web)                    • chrome                               • web-javascript • Google Chrome 128.0.6613.139
    ! Error: Browsing on the local area network for Bahadır's iPad. Ensure the device is unlocked and attached with a cable or associated with the same local area network as this Mac.
      The device must be opted into Developer Mode to connect wirelessly. (code -27)
    ! Error: Bahadır’s Apple Watch needs to connect to determine its availability. Check the connection between the device and its companion iPhone, and the connection between the iPhone and Xcode. Both
      devices may also need to be restarted and unlocked. (code 1)

[✓] Network resources
    • All expected network resources are available.

• No issues found!

Checklist before submitting a bug

[X] I searched issues in this repository and couldn't find such bug/problem
[X] I Google'd a solution and I couldn't find it
[X] I searched on StackOverflow for a solution and I couldn't find it
[X] I read the README.md file of the plugin
[X] I'm using the latest version of the plugin
[X] All dependencies are up to date with flutter pub upgrade
[X] I did a flutter clean
[X] I tried running the example project

Hello, can you explain further on what the issue is? "the result is unexpected" doesn't tell much.

Sorry for the unclearity. As you can see from the screenshot after I press save to files, action sheet opens all empty and mostly I cannot close it without restarting the application. All action sheet is unresponsive even the Browse button. When I press hot restart on VSCode application restarts on the background and action sheet stays open like screenshot.
This error can cause because of some iOS 18 simulator bug but I wanted to be sure.

Looking at the logs, the file file:///Users/bahadirarslan/Library/Developer/CoreSimulator/Devices/AA46777B-F7E7-4683-B1E5-B7C893100CAB/data/Containers/Data/Application/53338742-DD2D-43D5-9804-0EA336AEFDBC/Documents/exports/export_a36ccd37-a40d-40a3-b6b9-ce5118d2c60a.xlsx is not accessible by the app, as it says "The file couldn’t be opened.".
I am not sure if there has been a change in how the Simulator can access files in iOS 18.
In general, the plugin does not manage file access, it takes a file URI provided by the developer and passes it to the platform share method.
My recommendation for you is to investigate further why the file is not accessible, if there has been any changes in iOS 18, and as well to test on a physical device too. As well, you can also ask on Stack Overflow.


nixos/nullmailer: be flexible about time related types

Description of changes
I always kept forgetting to quote the ints, so why not use them as is.
Tested by deploying my config with ints instead of strings.
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

I don't use the changed options in my configs, but the change looks reasonable.

I've set sendtimeout in the past to discard mails that cannot be delivered. When testing things I got a few that where seemingly stuck forever.


Java Keygen EC error?

While I'm removing Themis Server references from Java examples, I've noticed the following — Key gen based on EC keys doesn't work in Java anymore (or I'm doing something wrong).
This works:
    Keypair pair = KeypairGenerator.generateKeypair(AsymmetricKey.KEYTYPE_RSA);
    PrivateKey privateKey = pair.getPrivateKey();
    PublicKey publicKey = pair.getPublicKey();

This returns error:
    Keypair pair = KeypairGenerator.generateKeypair(AsymmetricKey.KEYTYPE_EC);

Running SecureMessage example
Exception in thread "main" com.cossacklabs.themis.KeyGenerationException: failed to generate keypair
	at com.cossacklabs.themis.KeypairGenerator.generateKeypair(KeypairGenerator.java:63)
	at main.encryptDataForMessaging(main.java:50)
	at main.main(main.java:17)

@ilammy take a look? can you reproduce?
env:
macos
brew reinstall libthemis --with-java

libthemis_jni.dylib copied to /Users/<name>/Library/Java/Extensions.
gradle 6.3

can you reproduce?

Yes.

brew reinstall libthemis --with-java

This is the root cause. Our Homebrew distribution is still not updated to use<EMAIL_ADDRESS>instead of faulty openssl@3. Java code works fine for me if OpenSSL 1.1.1 is actually used. OpenSSL 3.0 is known to cause issues with Themis 0.13 when generating EC keys specifically.

this issue is solved by updating openssl.
brew tap cossacklabs/tap
brew reinstall libthemis --with-java

it pours openssl1-1
==> Pouring<EMAIL_ADDRESS>:beer<EMAIL_ADDRESS>8,081 files, 18.5MB
==> Installing cossacklabs/tap/libthemis --with-java

which solves keygen / SM issue:
publicKey1 = [85, 69, 67, 50, 0, 0, 0, 45, 21, 73, 122, 96, 3, -77, -19, 65, 76, 115, -35, 105, 96, 40, 112, 94, -32, 46, -117, 6, -50, 37, -99, 19, -55, -106, 0, 96, 95, 14, 7, -119, 99, 60, 49, -76, -90]
EncodedMessage = ICcEJkMAAAAAAQFADAAAABAAAAAPAAAA/HGUTshiUHGJCWhE891mudMj58HP6zlycHfSEl0c7RD/DRLaCFIOgEDwNw==
DecodedMessage = message to send

I'll close this PR and open new one related to removing themis server.


Introduce "warning" policy; change no-var to a warning

What is the purpose of this pull request? (put an "X" next to item)
[ ] Documentation update
[ ] Bug fix
[x] New feature
[ ] Other, please explain:
What changes did you make? (Give an overview)
Explain the difference between errors and warnings in the FAQ. Prep for releasing 16.0.1.
Which issue (if any) does this pull request address?
https://github.com/standard/standard/issues/633
Is there anything you'd like reviewers to focus on?

Is the explanation about the difference between errors and warnings clear enough?
Does the policy make sense?

@standard/team - can you take a look at this?

I think warnings are a great way to check if a change has impact on newly written modules or existing ones with a high velocity of changes without having to worry about breakage to existing “finished” ones so big 👍 from me

Thanks for the reviews, @mcollina and @mafintosh!

Released as 16.0.1

Awesome work getting this out quickly! 🌟

Thanks @LinusU ❤


chore(main): release iso-filecoin 0.2.4

:robot: I have created a release beep boop
0.2.4 (2023-07-07)
Bug Fixes

iso-filecoin: fix bip39 wordlist import (168478d)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/hugomrdias/iso-repo/releases/tag/iso-filecoin-v0.2.4 :sunflower: