[PROPOSAL] Add optional/required field to SchemaDatasetFacet

Purpose:
Currently SchemaDatasetFacet can represent most of information about dataset fields, like name, type, description, nested structure (if any). But it does not store information that field value is required or not (required/optional for Iceberg and Protobuf, ["int", "null"] for Avro, nullable: boolean for Spark and most of relation DBMS, and so on).
Proposed implementation
Add required: boolean field to SchemaDatasetFacetFields:
{
  "SchemaDatasetFacetFields": {
    "type": "object",
    "properties": {
      "name": {
        "description": "The name of the field.",
        "type": "string",
        "example": "column1"
      },
      "type": {
        "description": "The type of the field.",
        "type": "string",
        "example": "VARCHAR|INT|..."
      },
      "description": {
        "description": "The description of the field.",
        "type": "string"
      },
      "required": {
        "description": "Mark if field is required/non-nullable.",
        "type": "boolean"
      },
      "fields": {
        "description": "Nested struct fields.",
        "type": "array",
        "items": {
          "$ref": "#/$defs/SchemaDatasetFacetFields"
        }
      }
    },
    "required": ["name"]
  }
}

Backward compatibility is preserved.

I think that's a nice idea. Would be nice also to see if we can add some more per-field metadata, for example: if some field is foreign key?

Regarding other metadata, this can be implemented by adding metadata: Map<String, String> field to SchemaDatasetFacetFields. Map content is DB and file format dependent, here can be fully qualified name of Avro or Protobuf classes, foreign key info, primary key info, default/computed clauses, and so on.

Here are few examples.
RDBMS table schema:
{
  "schema": {
    "fields": [
      {
        "name": "id",
        "type": "bigint",
        "optional": false,
        "metadata": {
          "primary_key": true,
          "unique": true,
          "index": true,
          "auto_increment": true
        }
      },
      {
        "name": "name",
        "type": "string",
        "description": "User name",
        "optional": false,
        "metadata": {
          "unique": true,
          "index": true
        }
      },
      {
        "name": "description",
        "type": "string",
        "optional": true
      },
      {
        "name": "parent_id",
        "type": "string",
        "optional": true,
        "metadata": {
          "foreign_key": {
             "table": "db.schema.parent",
             "fields": ["id"]
           }
        }
      }
    ]
  }
}

Avro schema:
{
  "schema": {
    "fields": [
      {
        "name": "id",
        "type": "string",
        "optional": false
      },
      {
        "name": "version",
        "type": "int64",
        "optional": false,
        "metadata": {
          "default": 1
        }
      },
      {
        "name": "subEvent",
        "type": "record",
        "optional": false,
        "metadata": {
          "namespace": "io.openlineage.flink.avro.event",
          "name": "SubInputEvent"
        },
        "fields": [
          {
            "name": "id",
            "type": "string",
            "optional": false
          },
          {
            "name": "subSubEvent",
            "type": "record",
            "optional": true,
            "metadata": {
              "namespace": "io.openlineage.flink.avro.event",
              "name": "SubSubInputEvent"
            },
            "fields": [
              {
                "name": "id",
                "type": "string",
                "optional": false
              },
              {
                "name": "version",
                "type": "int64",
                "optional": false
              }
            ]
          },
          {
            "name": "arr",
            "type": "array",
            "optional": false,
            "fields": [
              {
                "name": "_element",
                "type": "int64",
                "optional": true
              }
            ]
          }
        ]
      }
    ]
  }
}

P.S. Regarding "namespace": "io.openlineage.flink.avro.event", "name": "SubSubInputEvent", I now think this should be used instead of "type": "record".

BTW, for Protobuf/Avro, type should be namespace.name or message/record with namespace and name mentioned in metadata field?

I'm glad to see some discussion about including required/optional/nullable/not-null metadata in schemas. I have use cases where having that in the OpenLineage spec would provide value to my work. I also understand where the desire for capturing free-text metadata like metadata: Map<String, String> on a column comes from as well.
For an open spec like this that will be used broadly across a wide variety of datatypes, I think we can borrow from what RDBMS designers have done successfully. Namely, that columns have names/types, but it's actually the tables themselves that have constraints on things like nullability, uniqueness, primary/surrogate keys, and foreign key relationships. Those table-level constraints then reference the columns in the table itself. This enables you to define constraints that might involve multiple database columns, such as a unique constraint across a pair of columns in a dataset.
I know that OpenLineage can express metadata about things besides an RDBMS, but I think this is actually less about the RDBMS paradigm and more about how tabular data is structured and constrained. Describing the structuring and constraints of tabular data as it's constructed seems (in my opinion at least) to be a core capability of the OpenLineage spec.
Bringing it all together, if this gets traction as a new component of OpenLineage, I implore you to consider a brand new facet such as a DatasetConstraintsFacet that doesn't limit constraints around nullability/uniqueness/etc to being described on a single metadata field (column).

Lineage can be captuted not only on RDBMS, but also on file formats like Parquet, ORC, Avro and so on, which have nullable/optional/required flag for each field, and not for entire file. So different dataset types may have information about field being optional in different facets.

@dolfinus @rileymcdowell
I wonder whether it's really relevant how we express that constraints given that we do it consistently. Is it really relevant that we expose the metadata "as it's constructed"?
I don't have hard feelings about whether to put that type of metadata in some column or table description, but I think having it as part of OL metadata actually allows you to abstract understanding how different systems define those constraints, and just be able to understand for example that the field is nullable by looking at one specified place in OL event.

So different dataset types may have information about field being optional in different facets.

That's why this seems to me as strictly worst solution - it does not allow OL producers or consumers to abstract that problem.

@rileymcdowell rileymcdowell gave the list of:
nullability, uniqueness, primary/surrogate keys, and foreign key relationships

Required/nullability: I believe nullability is a column-level constraint, and I agree with OP that it should remain in the fields section as proposed.

However, I'd avoid the use of the word "required", because when looking at a json template, "required" has a special meaning and it's hard for humans to see the same word in 2 different places meaning 2 different things.
I'd keep it to "nullable" since that's also how it's defined in many RDBMS - e.g. "DEFAULT NULL" or "NOT NULL". And "null" is pretty standard/accepted for semi-structured, un-structured, and flexible-structured data.

I also agree with @rileymcdowell that the last 3 are table-level, and I'd love to see a proposal for those, as they wouldn't be within the fields section.

Right now SchemaDatasetFacet has 3 properties just under "schema": fields, _schemaURL, _producer.
Perhaps an "objects" section? And it would be entirely optional.
@rileymcdowell can you propose a json template and some examples?
My thoughts:
An object has at most one primary key
An object can have many unique keys
An object can have many foreign key relationships

Are foreign key relationships a type of lineage? or is this strictly under the guise of "schema information"?
e.g. would you expect to see this on a lineage diagram?

@Sheeri we're going to roll out a custom facet for this for our internal use at our company. @kirkhansen is the individual doing the work on this at the moment. Give us a few days to build and test it. After that, we'll be happy to share what we come up with for a JsonSchema template and some examples. Depending on the interest from the OL community, we could tweak it from there or just share it for others to use if they want.
@Sheeri My loosely held opinions on your thoughts are below:

An object has at most one primary key

Yes. Additionally, the primary key can be composed of one or more fields. 90% of data will have one field
as primary key, but composite primary keys are common enough to require the schema supports them.

An object can have many unique keys

Yes. And each unique key can be composed of one or more fields.

An object can have many foreign key relationships

Yes. Likewise, foreign key relationships can be composed one or more fields. Foreign keys of multiple columns is
very uncommon, but real. Ex:
CREATE TABLE foo (
  col_1 INT,
  col_2 INT,
  FOREIGN KEY (col_1, col_2) REFERENCES bar (col_1, col_2)
);

I think this issue was originally about nullability of fields. If I'm about to take this discussion off topic and it would be better in a new issue, let me know. I'm happy to open one.

@rileymcdowell great point, let's focus on bullet point 1, nullability, and move everything else to a new issue. That way we can resolve one part while figuring out the others.


SBT.msi for per-user (rather than per-machine) installation

It would be nice to have a way to choose between per-user or per-machine installation.   This may require an alternative MSI and a bundle.

I am closing this due to inactivity.


new and init relationship in CPython and Transcrypt

Hi,
I'm prototyping some isomorphic serialization library (a mix of ideas from pickle and resurrect.js) which requires two-step object creation to deserialize object graphs with cyclic dependencies. The idea is to leave __init__ for new object initialization and provide separate initializer method to restore object from serialized state in the vein of what pickle does.
However it looks like Transcrypt doesn't follow CPython behaviour with regard to class __new__ and __init__ and it's not mentioned in the documentation as explicit limitation.  Specifically I'm talking about the case when __new__ is called explicitly - Transcrypt automatically calls __init__ but CPython actually doesn't.
Are there any plans to fix this behaviour or this is by design and will stay?
BTW thanks for super-awesome tool!

Apparently I've fixed this - it's in my fork for now. I'm going to add tests and make an appropriate PR on the weekend.


Cascading Editor

Hi,
I am having problems getting a Cascading Editor to work. It works when I hard code a value in CascadeValue  but when I use the CascadeFrom option the editor always returns empty.  Is the a way to see what value is passed to the editor when using CasscadeFrom?

CascadeFrom is the name of the editor.

The other one that this one should bind to

This is what I have but it is not working
    [DisplayName("Payment Milestone Project Type Id"), Expression("jPaymentMilestone.[ProjectTypeID]")]

    public Int32? ProjectTypeId

    {

        get { return Fields.ProjectTypeId[this]; }

        set { Fields.ProjectTypeId[this] = value; }

    }

    [DisplayName("Milestone Profile"), Column("PaymentMilestoneID"), NotNull, ForeignKey("[dbo].[tblPaymentMilestoneSetup]", "PaymentMilestoneID"), LeftJoin("jPaymentMilestone"), TextualField("PaymentMilestoneDescription")]

    [LookupEditor(typeof(Entities.PaymentMilestoneSetupRow), CascadeField = nameof(PaymentMilestoneSetupRow.ProjectTypeId),CascadeValue = nameof(ProjectTypeId))]

    public Int32? PaymentMilestoneId

    {

        get { return Fields.PaymentMilestoneId[this]; }

        set { Fields.PaymentMilestoneId[this] = value; }

    }

And
namespace HSSOnline2016.ProjectManagement.Entities
{
using Newtonsoft.Json;

using Serenity;

using Serenity.ComponentModel;

using Serenity.Data;

using Serenity.Data.Mapping;

using System;

using System.ComponentModel;

using System.IO;

[ConnectionKey("HSSDB"), DisplayName("tblPaymentMilestoneSetup"), InstanceName("tblPaymentMilestoneSetup"), TwoLevelCached]

[ReadPermission("ProjectManagement:General")]

[ModifyPermission("Administration")]

[LookupScript("ProjectManagement.PaymentMilestoneSetup")]

public sealed class PaymentMilestoneSetupRow : Row, IIdRow, INameRow

{

    [DisplayName("Project Type Id"), Column("ProjectTypeID"), NotNull, LookupInclude]

    public Int32? ProjectTypeId

    {

        get { return Fields.ProjectTypeId[this]; }

        set { Fields.ProjectTypeId[this] = value; }

    }

    [DisplayName("Payment Milestone Item"), Column("PaymentMilestoneItemID"), ForeignKey("[dbo].[tblPaymentMilestoneItems]", "PaymentMilestoneItemId"), LeftJoin("jPaymentMilestoneItem"), TextualField("PaymentMilestoneItem")]

    public Int32? PaymentMilestoneItemId

    {

        get { return Fields.PaymentMilestoneItemId[this]; }

        set { Fields.PaymentMilestoneItemId[this] = value; }

    }

    [DisplayName("Description"), Size(50), NotNull, QuickSearch]

    public String Description

    {

        get { return Fields.Description[this]; }

        set { Fields.Description[this] = value; }

    }

    [DisplayName("Payment Rule Id"), Column("PaymentRuleID"), NotNull]

    public Int32? PaymentRuleId

    {

        get { return Fields.PaymentRuleId[this]; }

        set { Fields.PaymentRuleId[this] = value; }

    }

    [DisplayName("Payment Milestone Id"), Column("PaymentMilestoneID"), Identity]

    public Int32? PaymentMilestoneId

    {

        get { return Fields.PaymentMilestoneId[this]; }

        set { Fields.PaymentMilestoneId[this] = value; }

    }

    [DisplayName("Payment Milestone Item Subsidy Instrument Id"), Expression("jPaymentMilestoneItem.[SubsidyInstrumentID]")]

    public Int32? PaymentMilestoneItemSubsidyInstrumentId

    {

        get { return Fields.PaymentMilestoneItemSubsidyInstrumentId[this]; }

        set { Fields.PaymentMilestoneItemSubsidyInstrumentId[this] = value; }

    }

    [DisplayName("Payment Milestone Item"), Expression("jPaymentMilestoneItem.[PaymentMilestoneItem]")]

    public String PaymentMilestoneItem

    {

        get { return Fields.PaymentMilestoneItem[this]; }

        set { Fields.PaymentMilestoneItem[this] = value; }

    }

    [DisplayName("Payment Milestone Item Parent Id"), Expression("jPaymentMilestoneItem.[ParentID]")]

    public Int32? PaymentMilestoneItemParentId

    {

        get { return Fields.PaymentMilestoneItemParentId[this]; }

        set { Fields.PaymentMilestoneItemParentId[this] = value; }

    }

    IIdField IIdRow.IdField

    {

        get { return Fields.PaymentMilestoneId; }

    }

    StringField INameRow.NameField

    {

        get { return Fields.Description; }

    }

    public static readonly RowFields Fields = new RowFields().Init();

    public PaymentMilestoneSetupRow()

        : base(Fields)

    {

    }

    public class RowFields : RowFieldsBase

    {

        public Int32Field ProjectTypeId;

        public Int32Field PaymentMilestoneItemId;

        public StringField Description;

        public Int32Field PaymentRuleId;

        public Int32Field PaymentMilestoneId;

        public Int32Field PaymentMilestoneItemSubsidyInstrumentId;

        public StringField PaymentMilestoneItem;

        public Int32Field PaymentMilestoneItemParentId;

        public RowFields()

            : base("[dbo].[tblPaymentMilestoneSetup]")

        {

            LocalTextPrefix = "ProjectManagement.PaymentMilestoneSetup";

        }

    }

}

}
From: Volkan Ceylan<EMAIL_ADDRESS>Sent: 22 May 2016 12:52 PM
To: volkanceylan/Serenity<EMAIL_ADDRESS>Cc: GeorgeBarkhuizen<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [volkanceylan/Serenity] Cascading Editor (#714)
CascadeFrom is the name of the editor.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub https://github.com/volkanceylan/Serenity/issues/714#issuecomment-220826015 https://github.com/notifications/beacon/ARfqn62nlN4y030bvQX6L2ReJK0dWiW8ks5qEDVJgaJpZM4Ij8kK.gif

Dont specify CascadeValue, only CascadeFrom and CascadeField

Changed it to this but still  no luck
    [DisplayName("Milestone Profile"), Column("PaymentMilestoneID"), NotNull, ForeignKey("[dbo].[tblPaymentMilestoneSetup]", "PaymentMilestoneID"), LeftJoin("jPaymentMilestone"), TextualField("PaymentMilestoneDescription")]

    [LookupEditor(typeof(Entities.PaymentMilestoneSetupRow), CascadeField = nameof(PaymentMilestoneSetupRow.ProjectTypeId), CascadeFrom = nameof(ProjectTypeId))]

    public Int32? PaymentMilestoneId

    {

        get { return Fields.PaymentMilestoneId[this]; }

        set { Fields.PaymentMilestoneId[this] = value; }

    }

From: Volkan Ceylan<EMAIL_ADDRESS>Sent: 22 May 2016 04:41 PM
To: volkanceylan/Serenity<EMAIL_ADDRESS>Cc: GeorgeBarkhuizen<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [volkanceylan/Serenity] Cascading Editor (#714)
Dont specify CascadeValue, only CascadeFrom and CascadeField
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub https://github.com/volkanceylan/Serenity/issues/714#issuecomment-220835959 https://github.com/notifications/beacon/ARfqnyLXZv9E-ujpoJ8LuAh8Q4tZzNv2ks5qEGrfgaJpZM4Ij8kK.gif

Omg, you don't have an editor on ProjectTypeId, how do you expect it to work with CascadeFrom

I do not want to display ProjectTypeId  on the form but I still want to filter the PaymentMilestoneId based on ProjectTypeId.  Should I rather use FilterField and FilterValue?
From: Volkan Ceylan<EMAIL_ADDRESS>Sent: 22 May 2016 05:34 PM
To: volkanceylan/Serenity<EMAIL_ADDRESS>Cc: GeorgeBarkhuizen<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [volkanceylan/Serenity] Cascading Editor (#714)
Omg, you don't have an editor on ProjectTypeId, how do you expect it to work with CascadeFrom
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub https://github.com/volkanceylan/Serenity/issues/714#issuecomment-220838603 https://github.com/notifications/beacon/ARfqnzIfqGiv3tO8dWrBqSqLn1iotaGIks5qEHd9gaJpZM4Ij8kK.gif

None will work, only set CascadeField on editor, override LoadEntity and set CascadeValue there.

Or add a hidden editor for ProjectTypeId [Visible(false)]

Thank you,
I added a hidden editor  for ProjectTypeId and now it is working.
From: Volkan Ceylan<EMAIL_ADDRESS>Sent: 22 May 2016 06:09 PM
To: volkanceylan/Serenity<EMAIL_ADDRESS>Cc: GeorgeBarkhuizen<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [volkanceylan/Serenity] Cascading Editor (#714)
Or add a hidden editor for ProjectTypeId [Visible(false)]
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub https://github.com/volkanceylan/Serenity/issues/714#issuecomment-220840571 https://github.com/notifications/beacon/ARfqn2_iMdXo1eeCbqaJR98bhdELZ-TDks5qEH-WgaJpZM4Ij8kK.gif

Hi Volcan,
I am looking for a freelance developer to assist me on a project built on Serenity Framework. Are you able to assist or can you put me in contact with someone that would be interested to work on this project?
From: Volkan Ceylan<EMAIL_ADDRESS>Sent: 22 May 2016 06:09 PM
To: volkanceylan/Serenity<EMAIL_ADDRESS>Cc: GeorgeBarkhuizen<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [volkanceylan/Serenity] Cascading Editor (#714)
Or add a hidden editor for ProjectTypeId [Visible(false)]
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub https://github.com/volkanceylan/Serenity/issues/714#issuecomment-220840571

You can contact me here:
https://www.linkedin.com/in/volkan-ceylan-68a44841

I cannot contact you on LinkedIn. Can you not email me directly?
From: Volkan Ceylan<EMAIL_ADDRESS>Sent: 01 June 2016 10:44 AM
To: volkanceylan/Serenity<EMAIL_ADDRESS>Cc: GeorgeBarkhuizen<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [volkanceylan/Serenity] Cascading Editor (#714)
You can contact me here:
https://www.linkedin.com/in/volkan-ceylan-68a44841
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/volkanceylan/Serenity/issues/714#issuecomment-222930153 , or mute the thread https://github.com/notifications/unsubscribe/ARfqn_RWWqVo_0yYhVBvmyOyiy5W6wP-ks5qHUZQgaJpZM4Ij8kK .


unexpected indent after a line with list slice

my test cases:
a = [1, 2, 3, 4, 5, 6]
a = 'abcdef'
b = a[2:]
    print b # invalid indent
c = a[:-2]
    print c # invalid indent
d = a[0:5:2]
    print d # invalid indent

@linuxlc
Is that with the version from master?
Because at least the first case is working for me.

@blueyed
Yes, master branch with latest version.
The second line is not a case, by the way.

Your test case gets indented to the following for me (gg=G):
a = [1, 2, 3, 4, 5, 6]
a = 'abcdef'
b = a[2:]
print b # invalid indent
c = a[:-2]
print c # invalid indent
d = a[0:5:2]
print d # invalid indent

This seems to be correct, isn't it?
What does :verb set indentexpr? give you?

@blueyed
  indentexpr=GetPythonPEPIndent(v:lnum)
        Last set from ~/.vim/bundle/vim-python-pep8-indent/indent/python.vim
Press ENTER or type command to continue

I'm experiencing the same bug as @linuxlc, it can be reproduced with dicts as well. Pressing o when cursor is on line
foo = {'foo': 1}

leaves the new line indented when it shouldn't be.
And yes, this is on latest master.

@blueyed @audriusk
I may have found the problem here, at indent/python.vim:246.
In previous version(before 7cb9a56c62d3540432cbcf78364569be19eb9e8a), the pattern is
':\s*\%(#.*\)\?$'

which means "a colon followed by nothing but comment", but in current version, the pattern is
':'

which is not strict enough.
change the pattern to the old one seems to solve the problem.

Yeah, you're right - I wasn't using the current master myself.. :/
I don't have time to look into this next days, so you might want to go back to an earlier commit for now.

Sorry for the interruption, and thanks for the report(s).
It is fixed now.


Update user-controls.md

Fix typo.

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


ADD/FIX multiple projects support for ~/.flutter_settings ($HOME/.flutter_settings)

currently flutter config writes its settings to a globally shared ~/.flutter_settings file
Use case
I have Flutter projects A, B,...
all of them have different platforms supported (some platforms are disabled for various reasons)
flutter create --platforms=android,ios project_A
flutter create --platforms=web,linux project_B
flutter config --no-enable-web
and now if I cd into project_B and run flutter build web I get:
"build web" is not currently supported.
even though it was enabled for project_B on creation and it has its project_B/web folder
Proposal
$HOME/.flutter_settings should continue being the default source for settings if they are not overridden by command line flags.
flutter create should make a $PROJECT_DIR/.flutter_settings file based on flutter create (in this case project_A/.flutter_settings and  project_B/.flutter_settings)
..and all following flutter commands should use $PROJECT_DIR/.flutter_settings (falling back to $HOME/.flutter_settings)
flutter config changes ran in a $PROJECT_DIR should be saved to $PROJECT_DIR/.flutter_settings
flutter config changes ran outside of project dirs should be saved to $HOME/.flutter_settings (with a warning that the changes are global)

@jonahwilliams but, if I just set every platform as enabled in $HOME/.flutter_settings to support flutter build and flutter run for each specific project (where some platforms are disabled) and always specifically set the supported platforms in flutter create - that means the platform settings in $HOME/.flutter_settings are overridden most of the time sans the odd flutter create without a platform flag
I think my proposal aligns with Flutters cross-platform philosophy, which implies more than 1 project per developer per lifetime


[aes] Use sparse state encodings for FSMs, trigger alert for invalid states

This PR changes all FSMs inside AES to use sparse state encodings with a minimum Hamming distance of 3 between states. If any FSM enters an invalid state, the AES unit locks and an alert is triggered. The cipher core is prevented from finishing the current operation or starting a new operation. Write to the control register are ignored. The AES unit needs to be reset.
This PR also renames the alert signals. All minor alerts (currently just update errors in shadow registers) are collected in minor. Fatal alerts such as storage errors in shadow registers, entering invalid FSM states trigger a major alert.
This PR only targets the FSMs. Further PRs will follow to also protect e.g. the round counter and mux signals.

FYI @cindychip , @rasmus-madsen , @weicaiyang, I've renamed the alert signals to collect multiple alert sources in a minor and major alert.

FYI @cindychip , @rasmus-madsen , @weicaiyang, I've renamed the alert signals to collect multiple alert sources in a minor and major alert.

Just a point from the side lines: OTBN called these two alerts "fatal" and "recoverable". I know we don't have system-wide guidance yet, but maybe we can organically evolve a shared naming (and understanding) of these alerts. (https://docs.opentitan.org/hw/ip/otbn/doc/index.html#hardware-interfaces). Maybe we can even expand this to the CSR containing the alert cause (FATAL_ALERT_CAUSE in OTBN, a bitfield)?

Just a point from the side lines: OTBN called these two alerts "fatal" and "recoverable". I know we don't have system-wide guidance yet, but maybe we can organically evolve a shared naming (and understanding) of these alerts. (https://docs.opentitan.org/hw/ip/otbn/doc/index.html#hardware-interfaces). Maybe we can even expand this to the CSR containing the alert cause (FATAL_ALERT_CAUSE in OTBN, a bitfield)?

Yes, I've noted that, too. In Ibex (not yet connected to alert handler though) we are using minor and major which is a bit shorter, which is why I went with that. I think it would be great to harmonize this across all IP.
The CSR bitfield in AES is named differently because at some point there will likely come major alerts that are not fatal.

Yes, I've noted that, too. In Ibex (not yet connected to alert handler though) we are using minor and major which is a bit shorter, which is why I went with that. I think it would be great to harmonize this across all IP.
The CSR bitfield in AES is named differently because at some point there will likely come major alerts that are not fatal.

On naming: yes, minor and major are shorter, but also have less meaning. This gets "interesting" when also considering that "there will likely come major alerts that are not fatal.".
In OTBN, we did try to group alerts by the action the system and the software developer is expected to take: on a fatal alert, a system reset is needed. On a recoverable alert, restarting the operation is enough.
It seems to me that in the AES case you (will) have three types of alerts: fatal alerts (system reset required), recoverable alerts (AES restart required), and informative alerts (just FYI, operation is continuing as usual). Currently, "fatal" and "recoverable" are both named "major" alerts for AES, with what I called "informative" being a "minor" alert.
@msfschaffner what's your thinking on that?

On naming: yes, minor and major are shorter, but also have less meaning. This gets "interesting" when also considering that "there will likely come major alerts that are not fatal.".
In OTBN, we did try to group alerts by the action the system and the software developer is expected to take: on a fatal alert, a system reset is needed. On a recoverable alert, restarting the operation is enough.
It seems to me that in the AES case you (will) have three types of alerts: fatal alerts (system reset required), recoverable alerts (AES restart required), and informative alerts (just FYI, operation is continuing as usual). Currently, "fatal" and "recoverable" are both named "major" alerts for AES, with what I called "informative" being a "minor" alert.
@msfschaffner what's your thinking on that?

@silvestrst for visibility

@silvestrst for visibility

I like the classification and naming scheme of @imphil and will go with that :+1:

I like the classification and naming scheme of @imphil and will go with that :+1:

Another thing I wanted to mention: If your state machine is going to have an explicit and terminal error state, you may also want to consider moving it into that state upon assertion of lc_escalate_en, which is the life cycle signal that triggers state wiping features.

Another thing I wanted to mention: If your state machine is going to have an explicit and terminal error state, you may also want to consider moving it into that state upon assertion of lc_escalate_en, which is the life cycle signal that triggers state wiping features.

Update: I've switched the alert naming system as discussed in yesterday's meeting and addressed also all other comments. Some things are IMO out of scope for this PR but I've added them to my AES tracking issue.

Update: I've switched the alert naming system as discussed in yesterday's meeting and addressed also all other comments. Some things are IMO out of scope for this PR but I've added them to my AES tracking issue.

Thanks @cdgori for reviewing and approving this PR.
In this PR we've triggered some good discussions but I don't think we can solve everything in here. More thought is needed to work out some more general guidance on alerts. I am fine to rework the alerts inside AES once we have this guidance but would like to move forward with this PR (and others that depend on it). I'll leave the final word to @msfschaffner .

Thanks @cdgori for reviewing and approving this PR.
In this PR we've triggered some good discussions but I don't think we can solve everything in here. More thought is needed to work out some more general guidance on alerts. I am fine to rework the alerts inside AES once we have this guidance but would like to move forward with this PR (and others that depend on it). I'll leave the final word to @msfschaffner .


about Class Weighted Similarity (CWS)

Hi,
Thanks for your work.
I just didn't find the Class Weighted Similarity (CWS) in the code. Could you please help me locate it ?

https://github.com/DeanChan/NAE4PS/blob/master/lib/model/faster_rcnn_norm_aware.py#L262


feat: support legacy pagination_type "page" to circumvent seemingly infinite loop

Since the new pagination_type search_after is introduced in this client, gathering products from our PIM instance results in seemingly infinite loops.
As I am not the admin of that system, i cannot analyze in detail if this is related to a misconfiguration of that particular system or if it's just related to that specific version of akeneo not yet providing this feature properly.
The current analysis is, that those legacy system do not respond with an error, but rather start to deliver ALL products available, which in turn seems like being stuck in an infinite loop. (For sure this depends heavily on the amount of total products).
This PR solves this issue as it honors the pagination_type param.
By default, still getAllBySearchAfter will be used.
But if necessary, one can switch to the old pagination strategy based on query-level like this:
query: { pagination_type: 'page' }

When digging through the codebase, I also applied some  minor refactorings aiming to increase maintainability. Hopefully these make sense to you as well ;)

@wheinze Thanks for the changes once again. I'll publish a new release later today!


Rust Community Update

added links to YouTube channel,  meetup page and embedded playlist
site now has layout and design
Rust logo added

Add fonts folder back in
update the attributes in the partials to reference the font-family in css
remove css/components and css/main.scss

Add line to .eleventy.js to copy css folder
Update styles in _includes/page.njk to use alfa_slabandfira_sansUpdateincludes/partials/htmlhead.njkto point to the css/stylesheet. Update the body style to usealfa_slab`


test showing the "access tracked struct from previous revision" bug

The test models a situation where we have two files (0, 1), where file 0 has LOW durability and file 1 has HIGH durability. We can query an index for each file, and a definitions from that index (just a sub-part of the index), and we can infer each file. The index and definitions queries depend only on the File they operate on, but the infer query has some other dependencies: infer(0) depends on infer(1), and infer(1) also depends directly on File(0) (this is to model that resolving a module can depend on existence of various files at various durabilities.) The dependency graph is shown below: light color represents low durability, black represents high durability, dark gray are structs and struct fields; I didn't get around to adding their durability to the graph yet. (The diff used to automatically generate the graph is included in the PR too; if we hit many more bugs like this I'll probably clean this code up and try to make it generally reusable.)

The panic occurs because definitions(1) is high durability, and depends on index(1) which is also high durability. index(1) creates the tracked struct Definition(1), and infer(1) (which is low durability) depends on Definition.file(1).
After a change to file 0 (low durability), we only shallowly verify definitions(1) -- it doesn't need deep-verify because it is high durability. So that means we never verify index(1) at all (deeply or shallowly), which means we never mark Definition(1) validated. So when we deep-verify infer(1), we try to access its dependency Definition.file(1), and hit the panic because we are accessing a tracked struct that has never been re-validated or re-recreated in R2.

I think one possible fix is that when we short circuit shallow verify due to durability, we also need to mark-validated not just our own outputs, but also all outputs of all our input queries (which must also be at least as durable as we are.)

I think it's either that, or we modify maybe_changed_after on a tracked struct so that it is valid to call it even if it hasn't been created/validated in the current revision yet, and we first check its durability and maybe validate it. This might be the simpler approach, and I think it's correct.

I've adjusted the test slightly so that it doesn't require input-builders and can run against main-branch Salsa (it still fails there), and I've got a working fix (using the second approach) in https://github.com/salsa-rs/salsa/pull/550

Let's create a PR against this repo as well so that we can go ahead and merge it without having to wait for upstream salsa

Updated to match https://github.com/salsa-rs/salsa/pull/550


Set permissions for GitHub actions

Included permissions for the action. https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions

https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions
https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests
Restrict the GitHub token permissions only to the required ones; this way, even if the attackers will succeed in compromising your workflow, they won’t be able to do much.
Signed-off-by: nathannaveen<EMAIL_ADDRESS>

LGTM, could you add a RELEASE_NOTES=n/a  to your commit message for our changelog system?

Let's try it. If it fails we can undo the change easily.


Fix bad link

Previous link was returning a 404 as it was pointing to https://github.com/airbnb/interferon/blob/master/blob/master/config.example.yaml

Any reason this hasn't been merged?

👍  for merge, just run into it and was about to push the same PR.


Two-level Mutation

When a candidate solution is close to the desired state, at a distance d let's say, then we can start applying mutations that change the gate parameters. We can also use a gradient-based approach to find the correct parameters.

Right now, if an individual has an error less than NEXT_STAGE_ERROR (set to 0.12 by default), we only apply parameterMutation operation which simply iterates over all the gates and if it finds a rotation gate it changes its parameter with probability EMC / len(individual.circuit).
We might wanna change this probabilities later on, we'll see.

It can also go to this stage after a number of generations has passed.


*: add Copy() to transaction.Transaction and payload.P2PNotaryRequest

Close #3288

@AnnaShaleva Let's decide if the current copy implementation is okay before writing tests for all new copy() methods?

@roman-khimov, ready for review.

Do you really need this change? It can break some initializations in existing code.

That was my concern as far, but I've checked the existing code and it seems that this type change doesn't break anything. Anyway, the current version looks better.


Export svelte uncompiled components

Summary
The goal for this PR is to export Svelte uncompiled components, so that they can be used in a SvelteKit app
Changes
I added a svelte field in package.json
exports: { ".": { "import": …; "svelte": …; } seems to confuse rollup and vite (contrary to what the doc suggests). It's be explored in further tests though, this is the right way to export both ESM and umd, something that has been troublesome.
The explicit import of registerable is to avoid tree shaking. I deleted the export the namespace since we actually don't use it, I don't think it had been tested that it worked and was messing up with explicit imports.
Changelog
It's now possible to import svelte uncompiled components to be used in a Svelte app:
<script>
import { Chart } from '@opendatasoft/visualizations';
</script>

<Chart {data} {options} />

Open discussion & test method
Soooooo… hardest one liner of my life. So trick is to have ChartJs work with both SSR and Treeshaking
To test if it's working, create a SvelteKit app and install visiualizations:
npm create svelte@latest my-app
cd my-app
npm install
npm install --save<EMAIL_ADDRESS>npm run dev -- --open

And try to create char. @fpassaniti you can find data and options to try with here

👋 @etienneburdet I'm struggle to render a viz in a Svelte kit project.
First, I had a self is not defined error for the page where I import the visualizations module. To resolve it I set export const ssr = false; in the javascript file associated to the page. (This error seems fair, can't render a graph on the server side)
Then, I had missing dependency error: saas is not defined. I had to install saas as dev dependency
Finally, I'm stuck with a wrong export error: import { geoPath, GeoProjection } from "d3-geo"; No matching export in "node_modules/d3-geo/src/index.js" for import "GeoProjection"
Did you experience any of it?

I had these at some point indeed… Seems like I didn't commit everything then. I'll have a look!

Should be good for testing on 0.24.1-beta.2 @fpassaniti @KevinFabre-ods
I moved sass as a dep (since it's needed on the end user now that we import components with sass) and seperate type import since it wasns't recognized as a TS thing.

0.24.1-beta.2

OK so new error:

TypeError: parent_component is undefined

Did you successfully render a chart? What is your code?
What I'm testing:
<script>
    import {Chart} from "@opendatasoft/visualizations";

    // ...
</script>

<Chart {...args} />

Hello, I rendered a chart on my side, just re-using the code Étienne mentioned:
`
<Chart {data} {options} />`
worked with both a bar chart stacked and an area chart stacked

OK so new error:

TypeError: parent_component is undefined

Did you successfully render a chart? What is your code? What I'm testing:
<script>
    import {Chart} from "@opendatasoft/visualizations";

    // ...
</script>

<Chart {...args} />

If you had beta1 before, you have to delete your node modules and reinstall. It will remove vite prebundled deps. That may be it… maybe not 😬

Thanks I'll try that

@fpassaniti and @manondravet This feature is available in the latest version ➡ 0.25.0


Foundry VTT Warning

Hi
Can you remove the foundry warning?

Just replace in module.json with this:
  "compatibleCoreVersion": "9"
or
  "compatibleCoreVersion": "10"

Same for me, please update :)

Changed it on the foundry package page. That should be enough (i think?)
if it is still there, send me a PR if you want to get it fixed "fast". I'm currently to busy to work on my modules and such i'm not touching them (besides accepting PRs)

yes, until next build

https://github.com/Moerill/fvtt-find-the-culprit/pull/22


[DO NOT MERGE] StreamingDataflowWorker user metrics debugging.

Please add a meaningful description for your change here

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

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

This work is continued in https://github.com/apache/beam/pull/9330


Improve Windows (with WSL2) development support

It should be possible to follow our contributing guidelines on Windows without ifs and buts.

[x] Make Taskfile targets work without gcc for -race.

Use {{if ne OS "windows"}}-race{{end}}?
Use some kind of autoconf-like autodetection?

[ ] Update documentation to mention recommended WSL2 configuration.
[x] Fix golangci lint task (add correct Windows path internal\\wire to .golangci.yml)
[ ] ~Check that task env-up works (and close #297).~

CI / GitHub Actions changes are not in scope.

@w84thesun I think we should have more documentation for contributors on Windows. At the very least, we should mention how to run commands, what works and what doesn't.


dark-light theme button

Pull Request
Related Issues:  #
Fixes #(issue number)
Description: Created a toggle button for dark-light theme and saved the user's preference in local storage.
Checklist:
I have tested my changes.
My code follows the project's coding standards.
I have updated the documentation (if applicable).

Hey @Komal73!
Apologize for late reviewing. I appreciate your contribution.
There might be problem on merging the PR. Actually not problem but some concerns.
So, I'd like to discuss with you some points regarding integration process. So feel free to ping me directly on Discord.


HEAD in select branch dialog & highlighting css bug fix

to #531 + a small bug fix after previous page_diff commits.

Removed refs/heads prefix. Seems like look better. But will need changes if we will support switching to tags once. Also in general branch_list_popup is a bit clunky now :( Not sure how to improve it immediately. But it works :)
plus added normalize_branch_name call in new_branch_popup to substitute space to '-' (space are not supported in branch names if I understand well, guthub also does similarly)

added also some small fixes for html intentation - page_main were not indeting well due to tricky div structure in menu.
Adjusten menu_end logic (hiding the separator at the last item in menu), nwo it is done by CSS

BTW, created a conveient tool for CSS adjusting - https://github.com/sbcgua/abap_w3mi_poller
Saves time on CSS upload in SMW0 ;)


Improve build.rs and some more.

I had some ideas about the newly added build.rs and touched some documentation as well.
What do you think about this change, @Piroro-hs?

How about changing those eprintln!s like this?
    eprintln!(
        "I've just found Rust's string literal support line breaking.\n\
        \n\
        We can keep indentation!!!."
    );

Oh, I've searched for a variation to keep the indentation as well. :smile: Thanks for the tip  :+1:


ROX-20942: Swap midstream images to floating tag iib-pubpending

Description
Swaps to floating iib tag instead of hardcoded image tag
Checklist

[ ] Investigated and inspected CI test results
[ ] Unit test and regression tests added
[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.


DOC: dblquad( ) Function Documentation

I have created a documentation for the dbquad() function from the integrate class of scipy
Issue #7168

# Computing a DOUBLE INTEGRAL

Structure :

scipy.integrate.dblquad(func, a, b, gfun, hfun, args=(), epsabs=1.49e-08, epsrel=1.49e-08)

Parameters :

func : callable
    function to be integrated
a, b : float
    Limits of integration x: a < b

gfun : callable
    The lower boundary curve in y which is a function taking a single
    floating point argument (x) and returning a floating point
    result: a lambda function can be useful here.

hfun : callable
    The upper boundary curve in y (same requirements as gfun).

args : sequence, optional
    Extra arguments to pass to func.

epsabs : float, optional
    Absolute tolerance passed directly to the
    inner 1-D quadrature integration. Default is 1.49e-8.

epsrel : float, optional
    Relative tolerance of the inner 1-D integrals.
    Default is 1.49e-8.

Returns :

res : float
    resultant integral
abserr : float
    estimate of the error

>>> from scipy import integrate

"""
The 'lambda' keyword pre-defines two variables,
namely 'x' and 'y' which constitute the
integrable function 'int_function'
"""
>>> int_function = lambda x, y: x*y

# ---STRUCTURE OF INTEGRATION---
# (x*y) is first integrated w.r.t 'x'
# The initial resultant is in 'y' due to the inner limits
# The initial resultant is integrated w.r.t 'y'
# This integral is done over outer limits
# INTEGRAL(INTEGRAL((x*y) dx, inner_low, inner_up) dy, outer_low, outer_up)

# ---METHOD 1---

# ---DEFINING THE LIMITS---
# The OUTER upper and lower limits
>>> outer_lower_limit = 0
>>> outer_upper_limit = 0.5

# The INNER upper and lower limits
# The inner limits are supposed to be in terms of 'y'
>>> inner_lower_limit = lambda x : 0
>>> inner_upper_limit = lambda x : 1-2*x

# The variable 'result' stores what is returned by the 'dblquad' function
>>> result_1 = integrate.dblquad(
...         int_function,
...         outer_lower_limit,
...         outer_upper_limit,
...         inner_lower_limit,
...         inner_upper_limit
...         )

>>> print('(Resultant Integral, Estimate of Error) :', result_1)

# ---METHOD 2---
"""
For n-fold integration, scipy provides the function nquad.
The integration bounds are an iterable object: either a list of constant bounds,
or a list of functions for the non-constant integration bounds.
The order of integration (and therefore the bounds) is from the innermost
integral to the outermost one.
"""
>>> def function(x,y):
...  return x*y

# Storing the outer bounds in form of an array
>>> def outer_bounds():
...  return [0,0.5]

# Storing the inner bounds in form of an array
>>> def inner_bounds(y):
...  return [0,1-2*y]

>>> result_2 = integrate.nquad(
...        function,
...         [inner_bounds, outer_bounds]
...         )

>>> print('(Resultant Integral, Estimate of Error) :', result_2)

@ss-is-master-chief thanks for tackling this. Note that the examples that gh-7168 is asking for should go in the docstrings of the functions themselves, not in separate files. So for dblquad it would go here: https://github.com/scipy/scipy/blob/master/scipy/integrate/quadpack.py#L509
The quad docstring gives a good example to follow (although the new ones don't have to be as long): https://github.com/scipy/scipy/blob/master/scipy/integrate/quadpack.py#L275
Finally, we don't need/want to document numpy functions here (that should be done in numpy itself if it's missing), so the content for np.average is not needed.

I have prepared the documentation for scipy.cluster.vq.kmeans2 owing to Issue #7168. Please have a look.

@rgommers Thank you for getting back to me Sir. I'll definitely look into the dblquad() issue. Thanks again


feat:[M3-8330] - Improve API flexibility for useToastNotification

Description 📝
We need to enhance the API of this hook to increase its flexibility in handling event notifications. For example, we have a new event, tax_id_invalid. When this event is successful (indicating the tax ID is invalid), we want to display the error variant and ensure the notification persists. Currently, there's no way to easily inverse the toast variant depending on the event.
Changes  🔄

Renamed persistFailureMessage to persist
Added tax_id_invalid event which is feature flagged
Added an invertVariant property to handle scenarios where a successful negative event should be represented as an error variant.
Added new interface:

interface ToastMessage {
  link?: JSX.Element;
  message: ((event: Event) => string | undefined) | string;
  persist?: boolean;
}

Target release date 🗓
7/22
How to test 🧪
Verification steps
(How to verify changes)

Trigger any of the events listed in the hook
Example: Create a volume and observe the multiple toasts that appear
Manually add these properties to volume_create:

invertVariant: true,
persist: 'success',

Observe the success should now be an error toast and it should be persisted.

As an Author I have considered 🤔
Check all that apply

[x] 👀 Doing a self review
[ ] ❔ Our contribution guidelines
[x] 🤏 Splitting feature into small PRs
[x] ➕ Adding a changeset
[ ] 🧪 Providing/Improving test coverage
[ ] 🔐 Removing all sensitive information from the code and PR description
[ ] 🚩 Using a feature flag to protect the release
[ ] 👣 Providing comprehensive reproduction steps
[ ] 📑 Providing or updating our documentation
[ ] 🕛 Scheduling a pair reviewing session
[ ] 📱 Providing mobile support
[ ] ♿  Providing accessibility support

@bnussman-akamai Good suggestions - let me know if there's anything else


Fix make update

Contributor Comments
This fixes make update and also attempts to repair the github actions.
Pull Request Checklist
Thank you for submitting a contribution to easy_infra!
In order to streamline the review of your contribution we ask that you review and comply with the below requirements:

[X] Ensure that make build completes successfully
[X] Rebase your branch against the latest commit of the target branch, which likely should be master
[X] If there is an issue associated with your Pull Request, align your PR title with this documentation

Testing cache

Testing cache

Cache test 2

Cache test 2

Cache test 3

Cache test 3


Can i add travel agency application created  using HTML ,CSS JAVASCRIPT and make it responsive

please star the repository

sure thanks for assigning me


Fix the grammar and punctuation in H1 title

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

@RobStand : Thanks for your contribution to the Azure documentation! The author, @andrewhoh, has been notified to review your proposed change.

#sign-off Thanks for the fix @RobStand!


Runtime Agent Analysis

Add the new component (possibly a different but related project) that uses runtime agent technology (.NET, Java, Node.js) that inspects what components are actually invoked during runtime .
The runtime agent should be able to output a report of all components that were loaded and/or invoked during runtime and whether or not DC found any known vulnerabilities in them. This is similar to how the agent works in Code Pulse. However, I'd also like the agent to perform delta analysis by looking at the components that are actually used verses the components that were resolved during compilation and packaged with the application.
Recently, Contrast Security performed research using Apache Commons HTTP Client v3.1 with real-world applications and component dependencies that use it. They discovered that over 5,700 components use commons-httpclient-3.1.jar, a component that has known vulnerabilities. But their tests went further to look at real-world applications and their supposed use of third-party components. Their findings indicate:

78% of libraries are never even loaded. They’re dependencies of some other library that you’re using.
7.7%  of the libraries deployed are actually used

Dependency management features in Maven and similar build systems are primitive at best and their results should be questioned by security teams. These build systems can also unnecessarily increase an applications attack surface. It's a large undertaking for teams to consistently update every component they ship, especially when statistically speaking, they are likely not using a lot of the components they've packaged.
Besides providing visibility into the components that are used (and unused) it could be used as a way to reduce the attack surface of an application. A common scenario I see is:

Application depends on Component A
Component A depends on Component B
Component B has known vulnerabilities but is not invoked
However, it may be possible to invoke Component B by tricking the Application into doing something it wasn't designed to do.

In this case, not having Component B (which would lead to a ClassNotFoundException) would be preferred over resolving the class and having the Application be exploitable.
In the marketing world, products are designed with Minimum Marketable Features (MMF) for a Minimum Viable Product (MVP). In essence, the Runtime Agent should be able to determine the Minimum Required Components (MRC) necessary for positive runtime results.

Steve - great idea! I've also been looking at things like dependency:analyze for Maven projects as a possible way to find declared, yet unused, dependencies.

@stevespringett would dependency-track able to accept a post of collected evidence for a given JAR and then do the analysis rather then having to do the analysis within the agent?  So the use of the agent would be:

Install ODC agent in container (tomcat, not docker) running App X
Container is started App X is executed with the agent
ODC agent sends information as libraries are loaded to dependency-track for analysis

Step 3 would result in several independent posts to dependency-track. In addition, with this setup you would be testing all applications and Tomcat dependencies as a single unit. As the information on the dependencies would be coming in piecemeal over time one would also need to consider re-deployments that remove dependencies - how would that be conveyed/recorded within dependency-track. Another option might be to run the scan during the build and then the agent would report that it was in use.
Thoughts?

Testing of all applications as a single unit is already something Dependency-Track does. It does this whenever a component is added and every 24 hours as a whole.
Dependency-Track v3, currently in development, will be able to do step 3. Current version (v1) is more of a static asset management system for components without any real APIs to communicate with anything. v3 is a complete rewrite with an API-first design (defined with Swagger 2.0) that is designed to work in this type of dynamic environment.
The separation of components from applications will continue to be a feature in v3. This will allow you to send multiple requests adding in components when necessary, or as a single big request.
I plan on taking the approach that SonarQube does, an all or nothing where history is maintained for the items that exist between builds, but otherwise drop off. So if an application removes use of a component, I'll continue to monitor that component for vulns, but the application associated with it will not be reporting those vulns. Similar to how it works today, but v3 adds in the whole dynamic API aspects.
Also of potential interest is a way to use Dependency-Track as a source of evidence for a future Dependency-Check release., similar to how we use Nexus or Maven Central today. So think about what type of things you'd like here. I'm thinking of two things: MD5/SHA1 hash lookups and evidence to CPE mappings.


chore(deps): upgrade dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-k8s-23-main" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 1578

Questions ?
Please refer to the Backport tool documentation


How long diff length does it support？

I see the code，it will concat the diff as prompt.
So how long diff length does it support？

I see the code，it will concat the diff as prompt. So how long diff length does it support？

Pretty much depends ojn the model token limitation


Make file descriptor accessible

By default, libbpf loads a small xdp program redirecting all traffic to the af_xdp socket. However sometime one don't want all traffic to be redirected. While it's possible to ask this crate to not register libbpf default program (using LibbpfFlags::XSK_LIBBPF_FLAGS__INHIBIT_PROG_LOAD), it's then not possible to register the xsk fd, so the program one loads can't actually send packets to userspace.
Making Fd::id public would be enough to allow this use case (with a bit of documentation)

Hi, apologies for the delay! Makes sense, I will take a look at your PR tomorrow. Thanks for submitting.


Update flake inputs and npins

Manually triggered update.

Closing in the meantime while I figure out how to handle secrets in the workflows.


Fix bug #690: Write epoch string for SPICE with microsecond precision instead of 0.1 second

Tickets addressed: #690
Review: By commit
Merge strategy: Merge (no squash)

Description
The fix was described in #690
Verification
A test case was added to test_unitSpice.py. Unfortunately, before SpiceInterface::initTimeData() is fixed, pytest will just stop the execution before the assert and not print any error. But after the fix, this test case runs successfully.

Thanks for contributing. I’ll take a look at this pool request as soon as possible.

Thanks for the contribution.   Please reduce the length of the first line and move some content to the following lines.  This is the case in both commits.

* add brief statement to release notes to `docs/source/Support/bskReleastNotes.rst`

* be sure to rebase on latest develop so we can merge right after final review

Thanks for the feedback, I addressed these 3 points, rebased onto latest develop and force-pushed.


Automatically comment out mongo-db code in Tests.Dockerfile when using Mac with M1

Is your feature request related to a problem? Please describe.
Today in every branch that I'm using I need to manually comment out mongo-db lines in Tests.Dockerfile.
Describe the solution you'd like
That it will automatically run it depending on the OS architecture (M1 or others).
Describe alternatives you've considered
Leave it as is (and manually comment out this part of the code).
Additional context
https://github.com/noobaa/noobaa-core/blob/6ec43ac7cb3591307fb67d7841b5b3cb28b7b005/src/deploy/NVA_build/Tests.Dockerfile#L22-L26

Closed by #7218


Better heuristic for cutting new chunks

Currently we cut a new chunk at 130 samples. If the sampling frequency fits 140 samples into a block, that results in uneven chunks. There a many similar scenarios causing similar imbalances.
The XOR encoding reaches good comression at 30 samples, near-ideal at 60, and certainly ideal at about 120 (c.f. http://www.vldb.org/pvldb/vol8/p1816-teller.pdf, page 1820).
I would propose to make a decision at the 30th sample of every chunk.  We look at the chunk's average sample frequency so far and extrapolate how many more samples will fit until the end of the block.
We then check how many idealized chunks of 120 samples are necessary to fill it. We round that down to err on the side of better compression and determine the end timestamp of the chunk based on that.
Naive formula:
s  = start time of current chunk
s' = start time of next chunk
m  = max timestamp for the block
r  = time range of chunk so far

s' = s + (m - s) / floor((m - s) / r / 4)

There are probably smarter heuristics. But this one is cheap, just runs once per chunk and does what we want most of the time I think.

Closed via #94


MacOS uuu verification

Need unload MacOS HID driver for special PID/VID, but it need apply a key to do that. The process of apply key is very slow.

@nxpfrankli do you have any plan to apply the key?

We already applied. but it is very slow and complex flow.

Any news on that ? Can't unload HID driver :-/ I just wonder how does Virtual Box manage this. Under it I can assign this HID usb device to guest OS

No update yet.

ping

Last Libusb change claim method. Can you try update libusb?


Making use of github flavoured markdown.

This should make the documentation slightly easier to read.

I have a problem with GH markdown. It makes it less readable as actual text. It's better when formatted as HTML. I agree, it's an improvement. But, markdown is supposed to be a readable text format.
I proposed to CommonMark to support a better format, but it was rejected/ignored.
I appreciate your effort.

https://talk.commonmark.org/t/syntax-highlighting-indented-code/1840/5 was the discussion.

I thought about this issue a bit more, and changed my opinion. So many tools support "```language" code blocks. I still find it less readable... but perhaps it's okay.

Is it less readable because the text is not indented or is it because of the fencing?

Both.


fix some links

on crates.io some links are broken: https://crates.io/crates/rudof

Indeed, something I am currently not sure about is what is the rudof crate at all because the latest version has been published 2 months ago but we are currently not publishing a single rudof crate but more fine-grained crates like rudof-cli or shacl_ast which are more up-to-date.
Which are the links that are broken?

Ho yeah, I have opened this issue just after you changed the name.
So it's mostly here: https://crates.io/crates/rudof
But as it's a not used crate, I suggest:

remove published crates
publish a crate that just redirect to other crate and do right documentation/repository

I think that having an façade rudof crate with a functionality similar to that of the rudof_cli but intended to be used programmatically would make sense
In that way, we could encourage the Rust users to use the methods from that crate trying to define a more stable API on that module.
I am hesitating about the name of the crate, we could call it rudof, but maybe I will call it rudof_lib by now, reserving rudof, and mainly because in that way, the structure of the project I think is cleaner, as we will have a folder for each crate.

For me it can be rudof the main crate.
A crate can be a lib and may includes also a bin folder with some executables (as mentioned here https://doc.rust-lang.org/cargo/reference/cargo-targets.html#binaries).
It means you have only one crate that reference the cli and the lib.

Yes, indeed, I think we could do it. I tried to keep rudof_cli and rudof_lib separated to avoid conflicts, but maybe we should consider grouping them back together.
I will do it once I am sure how to do it properly...


rez-context --diff secondary form

rez-context is super useful to diff rez resolves, but it assumes you're already in one of the rez-created environments to diff.
rez-context --diff needs a secondary form which allows you to diff two contexts while not in an existing resolve.
For example: rez-context --diff /path/to/oldcontext.rxt /path/to/newcontext.rxt

rez-context optionally works on the current context - you can specify a
different one. To diff two contexts that you aren't in, go:
rez-context --diff A.rxt B.rxt

Hth
A
On Wed, Apr 11, 2018 at 1:11 AM, maxnbk<EMAIL_ADDRESS>wrote:

rez-context is super useful to diff rez resolves, but it assumes you're
already in one of the rez-created environments to diff.
rez-context --diff needs a secondary form which allows you to diff two
contexts while not in an existing resolve.
For example: rez-context --diff /path/to/oldcontext.rxt
/path/to/newcontext.rxt
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/nerdvegas/rez/issues/506, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABjqSlNFdH9pv-jdbVqCh0nEFnWnujmOks5tnMu2gaJpZM4TOdST
.


Add tooling/docs to easily reproduce Oasis Core builds

SUMMARY
We should add the necessary tooling and document how to reproduce Oasis Core builds (at the moment, the oasis-node binary).
This is also a prerequisite to be able to verify an Oasis Core build before signing it (#2461).
ISSUE TYPE

Release process
Documentation

ADDITIONAL INFORMATION
Even though Go has great support for reproducible builds (version 1.13 added the -trimpath flag to the go build command), there are still a lot of steps that need to be taken before one is able to reproduce an Oasis Core build:

The used Go compiler must be the same.
The external dependencies (currently libseccomp for oasis-node) must be the same.
The git checkout from which the build is made, must be the same (we use git to infer the version based on previous tags and commits).

Probably the easiest way to achieve reproducible builds is to:

use a well-known Linux container as the basis of a reproducible build environment,
install a particular official Go release inside the container,
install distribution-provided release of libseccomp's headers inside the container,
bind-mount the git checkout into the container,
build a release,
prepare tarballs in a reproducible way.

This should be expanded to include reproducible runtime builds (probably the same environment should be used for both) to ensure that you can reproduce the exact MRENCLAVE.

Probably the easiest way to achieve reproducible builds is to:
* use a well-known Linux container as the basis of a reproducible build environment,
* install a particular official Go release inside the container,
* install distribution-provided release of libseccomp's headers inside the container,

After https://github.com/oasisprotocol/oasis-core/pull/2970, we will be rebuilding Docker images automatically, so it would make sense to create a minimal Docker image, e.g. oasisprotocol/oasis-core-build or oasisprotocol/oasis-core-reproducible, with just the necessary tools to be able to reproducibly build all release artifacts (without other development or testing stuff).

Some more thoughts on the implementation:

create a minimal Docker image, e.g. oasisprotocol/oasis-core-build or oasisprotocol/oasis-core-reproducible, with just the necessary tools to be able to reproducibly build all release artifacts (without other development or testing stuff)
integrate the building of this Docker image with the existing GitHub Actions release workflow so that when a vX.Y version tag is pushed:

the workflow first builds the oasisprotocol/oasis-core-build:X.Y image and pushes it to the registry,
then bind-mounts the vX.Y git tag checkout into the container spawned from the oasisprotocol/oasis-core-build:X.Y image,
and finally, builds the Oasis Core release artifacts via a Make target.

When documenting what people need to do, to reproduce our builds, it should be as easy as obtaining the appropriate oasisprotocol/oasis-core-build:X.Y image, checkout the vX.Y git tag and run a Make command.

@tjanez @kostko I have been working on something that may be of interest to you with regards to reproducible builds, using nix.
There's a current build file (called a nix flake) for oasis-core-tools under https://github.com/sbellem/oasis-core/blob/nix/flake.nix. You can see a ci-reproducibility check sample at https://github.com/sbellem/oasis-core/runs/5417928561. Notice that the expected hash (48d12f80ff734c944d5c44b639069325e8e6b986d9c16c5b5cbae8a3e1eee319) is hardcoded, as the build is expected to be reproducible regardless of when it is built, as long as the source code does not change. Hence the scheduled cron job should always match against this hardcoded hash.
For instance, with nix installed and with flake support, one could check the reproducibility locally by building oasis-core-tools, and checking the hash of the binary against the expected value.
nix build github:sbellem/oasis-core/nix

echo "48d12f80ff734c944d5c44b639069325e8e6b986d9c16c5b5cbae8a3e1eee319 *result/bin/cargo-elf2sgxs" | shasum --algorithm 512256 --binary --strict --check

Likewise, there's a nix flake for cipher-paratime at https://github.com/sbellem/cipher-paratime/blob/nix/flake.nix. An example of reproducibility check can be seen at https://github.com/sbellem/cipher-paratime/runs/5414978510. The provided flake (flake.nix) supports both sgx and non-sgx builds. The binaries can be built like so:
# with sgx support
nix build github:sbellem/cipher-paratime/nix#sgx

# without sgx support
nix build github:sbellem/cipher-paratime/nix#nosgx

CURRENT PROBLEM: For some reason that currently escapes me, the resulting binaries, when built on GitHub CI infrastructure yield different hashes than the ones I obtained on my laptop. I'm still investigating why that is so.

We are using a specific Docker container to build paratimes:

https://docs.oasis.dev/oasis-sdk/runtime/reproducibility/

This container is also used in CI when building images. You can take a look at the exact versions of all components that need to be used (unfortunately not all dependencies are currently pinned, but your approach may actually allow that):

https://github.com/oasisprotocol/oasis-sdk/blob/main/docker/runtime-builder/Dockerfile

We could consider updating the runtime-builder environment to use what you suggest. Thoughts?

We could consider updating the runtime-builder environment to use what you suggest. Thoughts?

I'd rather not, unless our current method doesn't work (and as far as I know it does).  Maybe if all this nix stuff was exiled to inside a docker container, it would be ok, though adding even more complexity and dependencies to the build environment doesn't feel right to me.
What are the benefits of this over what we have currently?
As a side note (and so I'm not just negative):

I have yet to learn how the remote attestation flow works in the oasis network.

At a high level, it is not that complicated.  The runtime descriptor contains a list of allowed MRSIGNER/MRENCLAVE pairs and attestation quote statuses, on a per-runtime version basis, which is cross-checked with the AVR from IAS.
IMO there isn't really all that much to verify here.  If the binary is identical, MRENCLAVE will be identical (by definition, since it is the SHA256 digest of the enclave binary).  Since people doing this will need to get an official build anyway (because they need the signature), just doing a byte-for-byte comparison of the executable is sufficient.  Maximum tinfoil hattery could retreive the runtime descriptor from the on-chain registry, and see if the MRENCLAVE matches what is published for that version.

Thanks @kostko and @Yawning for the feedback! Sorry for the delay in getting back. I'll give you detailed answers a bit later, but for now, the gist, based on what I know, is that achieving reproducible builds (bit-for-bit) may be easier to achieve with nix than with docker (if possible). (As a side note: It's possible to run nix in a docker container.)
One of the challenges when using docker is that when re-building the image, you may pick up new versions of dependencies, or of some of the dependencies of some dependencies.
I'm not familiar with fortanix when it comes down to how the MRENCLAVE is computed. When using the linux-sgx C++ sdk, the MRENCLAVE does not correspond to the sha256sum, which seems to be the case for enclaves built with fortanix.
Are you interested in the case in which an auditing party would want to verify whether the official build corresponds to the claimed source code? Without being able to re-build from source, one is left with having to trust someone for the expected hash, unless I misunderstand something.

Yes, that's what I meant when I said the current process that simply uses a Docker container is not ideal (eg. some deps aren't pinned).
My suggestion was to have this nix-based build inside a Docker container so that people who want to build don't need to deal with nix on their system.

Yes, that's what I meant when I said the current process that simply uses a Docker container is not ideal (eg. some deps aren't pinned).

Why is this and our other build reproducability issues closed then? Are there bugs for fixing this and actually making things reproducible?  Deterministic builds should be a p:0 issue....

My suggestion was to have this nix-based build inside a Docker container so that people who want to build don't need to deal with nix on their system.

After what happened the last time I had to use this, I want nix nowhere near my system, even if they claim that things have gotten better.  In nix's defense, I also want docker/podman/npm nowhere near my system either.

Are you interested in the case in which an auditing party would want to verify whether the official build corresponds to the claimed source code? Without being able to re-build from source, one is left with having to trust someone for the expected hash, unless I misunderstand something.

I mean...
The point of the reproducible builds (and why I pushed for them since the start of the project) is so that anyone can verify official builds, by producing identical ones, since proving binary-equivalence is a substantially harder problem.
What I am saying is that, given that builds are reproducible and deterministic, there is no additional handling required for MRENCLAVE because regardless of what SDK is being used, if the executable that anyone can produce is byte-for-byte identical to the official one, MRENCLAVE will be the same.
Ultimately, as long as I never have to interact with it, and I don't need to install "Yet another package manager", I'm moderately indifferent about how deterministic builds are achieved.  From skimming your branches, this appears to be the case.

Why is this and our other build reproducability issues closed then? Are there bugs for fixing this and actually making things reproducible?

This issue is still open BTW :-)
Runtime builds are reproducible down to MRENCLAVE if you use our specified builder Docker image and there are reproducibility CI tests that make sure this is the case.
But this doesn't mean things can't be improved. I would be interested to see how this nix-based approach would work. My understanding is that this would make it more robust regardless of how the builder image itself is built as long as it can run nix and then the nix-based build process will make sure that all dependencies (e.g. specifically referring to various system libraries) are pinned.

Use vagrant to build the docker image correctly?  My general impression is that "getting consistent docker images" is a long-solved problem.  Unless I'm mistaken, having to grab (or build) a docker image, then initialize nix, and pull down dependencies is more complexity and more points of failure than just building the docker image correctly in the first place.
And a the point where you're building a docker image with nix inside already setup with all the dependencies, that's functionally equivalent to building a docker image with all the inner contents pinned, just with extra tooling...
But if this is the path of least resistance, then sure, as long as it remains something that only CI ever deals with, nix would be fine.

Yes, that's what I meant when I said the current process that simply uses a Docker container is not ideal (eg. some deps aren't pinned).

This tool: https://github.com/Jille/dockpin may help.
According to this blog post Reproducible Builds and Docker Images

The other major issue that affects Docker images is the pinning of packages pulled in by package managers. An awful lot of images are based on Alpine or Debian derivatives, and use apk or apt to install dependencies. These need to have a version specified as otherwise the package manager will just pull in the latest at the time of the build. But this isn’t quite enough: you also need to pin the version of any packages that they depend on, recursively. This means flattening the entire package hierarchy and installing all the packages explicitly and with pinned versions.

My suggestion was to have this nix-based build inside a Docker container so that people who want to build don't need to deal with nix on their system.

Yes, that is possible, e.g.:
docker run --rm nixpkgs/nix-flakes /bin/bash -c \
    "nix build github:sbellem/oasis-sdk/nix#test-runtime-simple-consensus && sha256sum result/bin/*"

To be clear, I don't have any preference towards any tool, and just thought of sharing this work with you in case it may be of some use to the project.
It is not clear to me though whether docker alone can provide the guarantees that may be needed in the context of remote attestation verification and/or audits, where the verifier re-builds the docker image at an arbitrary time. I don't know myself. This blog post On using Nix and Docker as deployment automation solutions: similarities and differences may be useful.


[feat] Support redis call with wasm-rust

Ⅰ. Describe what this PR did
Support redis call with wasm-rust
Ⅱ. Does this pull request fix one issue?

#1297
fixes #908
Ⅲ. Why don't you add test cases (unit test/integration test)?
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews
依赖 https://github.com/higress-group/proxy-wasm-rust-sdk/pull/4

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

Project coverage is 43.60%. Comparing base (ef31e09) to head (fa5b887).
Report is 157 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1417      +/-   ##
==========================================
+ Coverage   35.91%   43.60%   +7.69%
==========================================
  Files          69       76       +7
  Lines       11576    12320     +744
==========================================
+ Hits         4157     5372    +1215
+ Misses       7104     6615     -489
- Partials      315      333      +18

see 69 files with indirect coverage changes

cc @jizhuozhi @Lynskylate


Typo

Application enforced restrictions
....(wehn the device is managed and compliant).

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

ID: 609a0eda-f113-8b77-67ee-c5e8bd94cbac
Version Independent ID: 7468d74e-9a7e-2a11-ba35-da46103a1b80
Content: Session controls in Conditional Access policy - Azure Active Directory
Content Source: articles/active-directory/conditional-access/concept-conditional-access-session.md
Service: active-directory
Sub-service: conditional-access
GitHub Login: @MicrosoftGuyJFlo
Microsoft Alias: joflore

@AndrewMNewton
I've created a PR to update the documentation and will now close out this issue. Please allow some time for the changes to reflect and if you don't see the document update, please let me know.
I will be more than happy to re-open this issue and look into what happened.
Thank you for your time and patience!


Refresh control not working with nativebase components

Same problem. And adding refreshControl prop directly to <content> even causes maximum call stack size exceeded exception

Fixed in 0.5.5

Hey, unfortunately it's not fixed. Waiting for a "maximum call stack exceeded" error before using shallow merge is a very very slow solution. It can take seconds for the stack to fill itself and the exception is raised.
Is there any reason props can't be shallow merged by default? It seems like a normal and sensible approach to me, as you should never mutate the props anyway, so why clone that deep?

Hi, @mariusandra could you send a PR with your proposed solution?

@mariusandra Agree. Actually I'm also confused why use deep merge, and afraid of breaking anything, I just added that try-catch clause in #109 . Yeah, outgoing props shouldn't and cannot be mutated in principal, so using shallow merge by default should be just fine. Why not give it a try :)

The PR is here: https://github.com/GeekyAnts/NativeBase/pull/152 , thanks!

By the way, it seems interesting why the deep merge hangs. Is there a reference loop in the generated React component (as a plain JavaScript object) that causes the infinite clone?

@mariusandra The reason for doing a deep merge was to preserve any other prop which the user might be sending. As we don't want to be losing out on any user sent prop. We can however put in a condition where we check the prop type, if the type is a function, we'll do the shallow merge otherwise we'll stick to merge.

@sankhadeeproy007 Sorry, I'm not sure I follow. How will the props not be preserved with a shallow merge? The way I have understood is that it's always preferred to do a shallow merge, as the props will never be mutated downstream and this is way way faster.
All the code I find these days just uses Object.assign({}, oldState, newState) to shallowly clone and merge props.

@mariusandra With shallow merge, when user sends props containing a top-level key that already exists in the default props, the value of that key will be lost. Say, user passes {myProp : { myKey : 1  }} and we have a {myProp : { defaultKey : 1 }} by default,  we prefer {myProp : { myKey : 1 , defaultKey : 1}} as our result, instead of either one of them.

Ah, I get it now, thanks. What to do then?

As @sankhadeeproy007 says, putting in a condition to check every prop type before merging should solve the problem. Maybe the checking logic should be deep too.

when I put it inside content, it fires and shows the spinner - however I get this error
Exception thrown while executing UI block: -[RCTView contentOffset]: unrecognized selector sent to instance 0x7ff19850cec0

Hi, i found the same issue. How to fix it ?

+1

The same way you would add it inside ScrollView.

I changed it to ScrollView but still get the same error. I know it is not directly related to NativeBase but it is still related somehow. Do you have any working example of RefreshControl inside Content? Or anyone knows why this exception fires?

Well I arrive here with the same problem. Did Anybody solve it?

Hi @Xosmond, check out #1192 for a related bug and see #269 (especially @axsann's) for possible alternatives for you, although none are satisfactory at the moment when TabNavigator is involved.

Hello is there any working example for the same ? where in we can apply the RefreshControl to the 'Content' or 'List' ? I am still facing issues with this. I am using native base '2.6.1' and react native 0.55.4
 <Content refreshControl={this._refreshControl()}>  <List></List> ... </Content>
below is attaching an image for the snippet code.

The Code for Refresh Control is

The consoleLog code is as follows

With this code in place I am getting the error -

Invariant Violation: Maximum update depth exceeded. This can happen when a component repeatedly calls setState inside componentWillUpdate or componentDidUpdate. React limits the number of nested updates to prevent infinite loops.

Can some one point out what is wrong with my code ? or what I need to do to fix it ?

@saurabhabh There are many similar issues provided with solution, you ca n check them across NativeBase github

@SupriyaKalghatgi  Hi I did check them. But None of them seem to work. Hence I am asking if there is a working example with the refresh control added to the 'Content'. As few have suggested that it works in that scenario. Also I have checked it adding to the 'List' yet I am receiving the same error. looked into this as well

Tried this https://github.com/GeekyAnts/NativeBase/issues/348#issuecomment-266285965

https://github.com/GeekyAnts/NativeBase/issues/1720#issuecomment-376062502

How is the code in the 2 mentioned comments different from what I have written ? I have done the same thing and it doesnt work for me . Is it because I have a 'List' inside my 'Content' ?

I would suggest to try both these snippets
with List try this too https://github.com/GeekyAnts/NativeBase/issues/348#issuecomment-269958631

I found the problem. It was a silly issue.

After changing this to the handle of the function it works.
Thanks for the support


Support other well known gamepads like DualShock and DualSense

Is your feature request related to a problem? Please describe
I tested my app and DualSense and DualShock gamepads were not recognized by the Android Subsystem. It seems only XInput gamepads are correctly recognized.
Describe the solution you'd like
Well known 3rd Party gamepads should work inside Apps.
Describe alternatives you've considered
No response
Please specify the version of Windows Subsystem for Android
2209.40000.26.0

Hi. Thanks for the feature request. You are correct that XInput is presently supported. This feature isn't currently on our scheduled roadmap, but we're using community feedback to help prioritize features.

Thanks, this would definitely be an awesome feature to support generic DInput devices. Especially if a user wants to play Android games which supports all different kinds of controllers. I was confused at first why the controller didn't work because I was not aware of that the subsystem only supports XInput at the moment. The subsystem could offer a similar mapping feature for DInput devices similar to the currently existing keyboard mapping feature.


Will the Instance registered by Bind.lazyPut not be deleted?

Describe the bug
Will the Instance registered by Bind.lazyPut not be deleted?
Will this affect performance? Is there a way to delete the Instance registered by Bind.lazyPut from memory?
Screenshots

Flutter Version:
Flutter 3.24.5 • channel stable • https://github.com/flutter/flutter.git
Framework • revision dec2ee5c1f (3 weeks ago) • 2024-11-13 11:13:06 -0800
Engine • revision a18df97ca5
Tools • Dart 3.5.4 • DevTools 2.37.3
Getx Version:
[Enter the version of the Getx you are using](get: ^5.0.0-release-candidate-9.2.1)

same question

(Workaround) I found that, if you add 'fenix: false' when using Bind.lazyPut, the controller will be deleted on closing.

(Workaround) I found that, if you add 'fenix: false' when using Bind.lazyPut, the controller will be deleted on closing.

So why the Bind set the fenix to true as default? I find that in Get.lazyPut, the fenix is false as default.

Thanks for opening this issue.
The problem is with the fenix:true mode setting in the last update.
I'm still deciding if it will be the default.
Many users face problems with dependency not found (although this always happens when they use GetX improperly, starting dependencies in inappropriate places) but performance should be in mind along with ease of use.

Thanks for opening this issue. The problem is with the fenix:true mode setting in the last update. I'm still deciding if it will be the default. Many users face problems with dependency not found (although this always happens when they use GetX improperly, starting dependencies in inappropriate places) but performance should be in mind along with ease of use.

Should I assume that I can set fenix to false for all Bind.lazyPut and get the same effect as Get.lazyPut?

Yes, definetely

Yes, definetely

Thanks for your response.


Bug with Majrusz's Enchantments

When using an axe (or any tool) enchanted with Telekinesis from Majrusz's Enchantments, you will be given a log from the tree when it hasn't been fully chopped. Using this you can get infinite logs without ever fully breaking the tree.

Thanks for reporting! I'll look into it

Should be fixed in 0.19.0 but I haven't tested it. Also in the new version, I think telekensis will grab all blocks from felled trees.

I tested the new version, and the bug is fixed. Telekinesis doesn't collect all blocks, only the block that was broken.

Ok, great! Thanks for confirming


Merge with upstream

Last merge was in February. Seems about time to do it again. There were no conflicts.
I expect this will help with some of the clippy failures, but haven't tested.

Our repo is configured to squash prs but I don't want to squash this upstream history. I will see if I can push it directly.


Does this library support ERC-20?

Absolutely. Just use the Contract object, and give it the ERC-20 ABI, along with your token address and a provider (or a signer, for managing the asset).
An ERC-20 token is just a normal contract, nothing special is required to interact with one. The utils.parseUnits and utils.formatUnits also make it easy to convert between user input to safe values and from safe values to display logic. :)

Oh! So sorry, I thought this was for the ethers.js library. I didn’t notice the repo you posted to.
This library does not easily handle ERC-20. Sorry. :s


feat: adding cyral output var repo_crawler_aws_security_group_id

Summary

Adding the cyral security group id output terraform variable

Details
This exposed the security group id used in the cyral module, without exposing this it makes it more difficult to discover when allowing cyral to talk to specific databases.
Testing

Ran locally in our environment

@ccampo133, could you please tag this module so that it can be synced with the Terraform registry for upstream use? Thank you for your assistance.

@ccampo133 normally the webhook will force a sync to terraform registry, however since it hasn't yet we may need to do so manually according to the docs. Could you sync that on your end?

If your version doesn't appear properly, you may force a sync with GitHub by viewing your module on the registry and clicking "Resync Module" under the "Manage Module" dropdown. This process may take a few minutes. Please only do this if you do not see the version appear, since it will cause the registry to resync all versions of your module.

Thanks, it should be up to date now.

Confirmed. Thank you.


Compatibility with OpenTelemetry semantic conventions and/or Elastic Common Schema

Elastic Common Schema defines a set of attributes for vulnerabilities, certificates, process, users, etc that has an intersection with OCSF. It was also historically actively used for security events.
OpenTelemetry defines a set of semantic conventions that describe specific events, implements distributed tracing, etc.  It also provides extensive tooling to collect information from user applications or cloud providers. It also has a lot of intersection with OCSF around general-purpose data such as cloud resources, host, service, os, network peers, etc
Recently, ECS and OpenTelemetry announced convergence and will eventually provide a common set of attributes.
Given that security events are a subset of the general purpose events and have a lot of general attributes in common with OTel and ECS, what's the vision for OCSF?

OCSF isn't technically limited to security events, in fact much of the Activity classes are not security specific until certain profiles are added to them.  OTel could have used the OCSF dictionary for its body, and ECS was proprietary to Elastic (although public) at the time OTel first considered using it, hence it wasn't a candidate for a fully open schema project.  Since that time, OTel and ECS converged as you said, in fact very recently.
OTel was focused on Observability and is gaining momentum with the leading players in that domain.  Further, there are some intersecting use cases of Observability and Security, where Security systems can make use of Observability metrics for example.
There are no plans at this point to do anything with OTel, unfortunately that ship may have sailed (I had suggested it to the Splunk participants more than a year ago).  However, it is likely that translation or cross-references to the ECS objects is something that could be a useful project (much like with do with D3FEND Artifacts and OCSF objects).

Update: we are working with the OTel and ECS groups to find a way to collaborate on security events.

Weekly call review on 6/18 this looks like its in motion.
Perhaps some OTel samples and a mapping exercise?


MQTT last will  doesn't work

LWT doesn't work because set_will is after connect function . According to MQTT specification  LWT can be set only in connection packet.  I tested this using mosquitto server.

That was something I was looking into but didn't find why it wasn't working. I'll work on a fix.

Fixed in 0.3.1. Let me know if it works for you.

Yes, it works now. Thank You!


Remove whitespace from brew titles on UserPage

This PR resolves #2775.
This PR performs a trim() on all brew titles before they are passed to the base ListPage.

Would it make more sense to do this in the listPage.jsx where we already do other similar "cleanup" of brew titles to aid alphabetical sorting (deburr, etc.)?
https://github.com/naturalcrit/homebrewery/blob/1e004977bea73f112197f959d8dd2a58a4d11ac5/client/homebrew/pages/basePages/listPage/listPage.jsx#L92

Would it make more sense to do this in the listPage.jsx where we already do other similar "cleanup" of brew titles to aid alphabetical sorting (deburr, etc.)?

I'm pretty sure that the whitespace collapses gives the appearance of trimming anyway. I've added it to the ListPage sort as well, as well as the UserPage brew collection generation.

2. This PR also doesn't address the suggestion of "just fix the title before it gets saved". Do we want to _actually change_ brew titles? Or do we only care about making them alphabetically sort in the userpage? I'm not sure it's necessary (maybe some people _want_ random untrimmed spaces.... but I'm not sure.  Thoughts?

I've added a couple of lines to trim the title before the initial save, and to perform a trim before saving updates.
At this stage, I have also expanded this slightly to include trimming the brew's description.


Finalize all sql statements when database gets closed

Without finalizing the sqlite database doesn't get closed accordingly.
rdar://55274300

@swift-ci please smoke test

I don't see a way to actually test for that because there is not method for checking if there're still not finalized prepared statements.
But sqlite3_close returns SQLITE_BUSY if resources are not closed, finalized, finished accordingly. I added an assert for that since it's a development error and a test which opens and closes a connection and should hit this assert if that happens again.

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test

That’s exactly what I had in mind, thanks!

@BenchR267 actually, just noticed: the close shouldn’t be inside the assert, no assert builds will not close the DB! Can you fix?

Oh true! Yes, I'll fix