0020 XLS-20d Non-Fungible Token Support (native)

Discussed in https://github.com/XRPLF/XRPL-Standards/discussions/46

Originally posted by nbougalis May 24, 2021

  Title:        Non-Fungible Token Support
  Revision:     9 (2022-03-23)

  Author:       David J. Schwartz
                Aanchal Malhotra
                Nikolaos D. Bougalis
  Affiliation:  Ripple

1. Non-Fungible Token Support
1.1. Abstract
The XRP Ledger offers support for tokens (a.k.a. IOUs or issued assets). Such assets are, primarily, fungible. They can be easily traded between users for XRP or other issued assets on the XRP Ledger's decentralized exchange. This makes them ideal for payments.
Such objects can also be used to implement non-fungible tokens (NFTokens), as seen in an example implementation by the XRPL Labs team.
Non-fungible tokens serve to encode ownership of physical, non-physical or purely digital goods, such as works of art and in-game items.
This proposal introduces extensions to the XRP Ledger that would support a native non-fungible token type, along with operations to enumerate, purchase, sell and hold such tokens.
While other proposals (some of which are extremely interesting) have been made, the authors believe that this proposal represents a strong commitment to supporting NFTs on the XRP Ledger, and adds a rich set of flexible primitives that can be used by token issuers.
The non-fungible tokens proposed are:

Indivisible;
Unique; and
Not used for payments.

1.1.1. Advantages and Disadvantages
Advantages

NFT-specific configurations and options such as transfer fees and burnable/non-burnable tokens allow for flexibility.
An efficient storage mechanism, capable of storing a large number of NFTs.

Disadvantages

Requires an amendment to the XRP Ledger protocol, which increases complexity and adds more types of data that must be tracked and maintained as part of the ledger indefinitely.
New transaction and data types require new implementation code from client libraries and wallets to read, display, and transact with NFTs.

1.2. Creating and Transferring Tokens on XRPL
1.2.1. On-Ledger Data Structures
We propose two new objects and one new ledger structure:

An NFToken is a new object that describes a single NFT.
An NFTokenOffer is a new object that describes an offer to buy or sell a single NFToken.
An NFTokenPage is a ledger structure that contains a set of NFToken objects owned by the same account.

<IP_ADDRESS>. The NFToken object
The NFToken object represents a single NFT and holds data associated with the NFT itself. NFTs are created using the NFTokenMint transaction and can, optionally, be destroyed by the NFTokenBurn transaction.
<IP_ADDRESS>.1. Fields
An NFToken object can have the following required and optional fields. Notice that, unlike other objects no field is needed to identify the object type or current owner of the object, because NFTs are grouped into pages that implicitly define the object type and identify the owner.

Field Name
Required?
JSON Type
Internal Type

NFTokenID
:heavy_check_mark:
string
UINT256

This composite field uniquely identifiers a token; it contains a set of 16 bits that identify flags or settings specific to the NFT, 16 bits that encode the transfer fee associated with this token, if
any, the 160-bit account identifier of the issuer, a 32-bit issuer-specified taxon, and an
(automatically generated) monotonically increasing 32-bit sequence number.
The 16-bit flags and transfer fee fields, and the 32-bit taxon and sequence number fields are stored in big-endian format.
<IP_ADDRESS>.1.1 Flags
A set of flags indicating properties or other options associated with this NFToken object. The type specific flags proposed at this are:

Flag Name
Flag Value
Description

lsfBurnable
0x0001
If set, indicates that the issuer (or an entity authorized by the issuer) can destroy the object. The object's owner can always do so.

lsfOnlyXRP
0x0002
If set, indicates that the tokens can only be offered or sold for XRP.

lsfTrustLine
0x0004
If set, indicates that the issuer wants a trustline to be automatically created.

lsfTransferable
0x0008
If set, indicates that this NFT can be transferred. This flag has no effect if the token is being transferred from the issuer or to the issuer.

lsfReservedFlag
0x8000
This proposal reserves this flag for future use. Attempts to set this flag should fail.

These flags are immutable: they can only be set during the NFTokenMint transaction and cannot be changed later.
:memo: The lsfTrustLine field is useful when the token can be offered for sale for assets other than XRP and the issuer charges a TransferFee. If this flag is set, then a trust line will be automatically created, when needed, to allow the issuer to receive the appropriate transfer fee. If this flag is not set then an attempt to transfer for token for an asset that the issuer does not have a trustline for will fail.
<IP_ADDRESS>.1.2 TransferFee
The value specifies the fee, in tenths of a basis point, charged by the issuer for secondary sales of the token, if such sales are allowed at all. Valid values for this field are between 0 and 50,000 inclusive and a value of 1 is equivalent to 1/10 of a basis point or 0.001%, allowing transfer rates between 0% and 50%. A TransferFee of 50,000 corresponds to 50%.
<IP_ADDRESS>.1.3 Taxon Scrambling
An issuer may issue several NFTs with the same taxon; to ensure that NFTs are spread across multiple pages we lightly mix the taxon up by using the sequence (which is not under the issuer's direct control) as the seed for a simple linear congruential generator.
From the Hull-Dobell theorem we know that f(x)=(m*x+c) mod n will yield a permutation of [0, n) when n is a power of 2 if m is congruent to 1 mod 4 and c is odd.
This proposal fixes m = 384160001 and c = 2459.  Changing these numbers after this proposal is implemented and deployed would be a breaking change requiring, at a minimum, an amendment and a way to distinguish token IDs that were generated with the old code.
<IP_ADDRESS>.1.4 Example
For example, the NFTokenID 000B013A95F14B0E44F78A264E41713C64B5F89242540EE2BC8B858E00000D65 would uniquely identify the token with Taxon 146,999,694 and Sequence 3,429, issued by rNCFjv8Ek5oDrNiMJ3pw6eLLFtMjZLJnf2. The TransferFee is 3.14% and the Flags associated with the token are: lsfBurnable, lsfOnlyXRP and lsfTransferable:
000B 0C44 95F14B0E44F78A264E41713C64B5F89242540EE2 BC8B858E 00000D65
+--- +--- +--------------------------------------- +------- +-------
|    |    |                                        |        |
|    |    |                                        |        `---> Sequence: 3,429
|    |    |                                        |
|    |    |                                        `---> Taxon: 146,999,694
|    |    |
|    |    `---> Issuer: rNCFjv8Ek5oDrNiMJ3pw6eLLFtMjZLJnf2
|    |
|    `---> TransferFee: 314.0 bps or 3.140%
|
`---> Flags: 12 -> lsfBurnable, lsfOnlyXRP and lsfTransferable

:information_source: Notice that the scrambled version of the taxon is 0xBC8B858E: the scrambled version of the taxon specified by the issuer. But the actual value of the taxon is the unscrambled value.

Field Name
Required?
JSON Type
Internal Type

URI

string
BLOB

A URI that points to the data and/or metadata associated with the NFT. This field need not be an HTTP or HTTPS URL; it could be an IPFS URI, a magnet link, immediate data encoded as an RFC2379 "data" URL, or even an opaque issuer-specific encoding. The URI is NOT checked for validity, but the field is limited to a maximum length of 256 bytes.
:memo: In the interest of reducing the size of NFT objects and their impact on the ledger as a whole as well as maximizing flexibility, this implementation recommends (but does not require) that this field be avoided. Not only does this field increase the amount of data that must be stored on ledger, but it is also immutable, which means that, if specified, it commits the issuer to hosting the data and/or metadata associated with the NFT at the specified location. See the Retrieving NFToken Data and Metadata section below for details on alternatives.
<IP_ADDRESS>.2.1. Example NFToken JSON
{
    "NFTokenID": "000B013A95F14B0044F78A264E41713C64B5F89242540EE208C3098E00000D65",
    "URI": "ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf4dfuylqabf3oclgtqy55fbzdi"
}

Retrieving NFToken Data and Metadata
In the interest of (a) minimizing the footprint of an NFT but without sacrificing utility or functionality; and (b) imposing as few restrictions as possible, this specification does not allow an NFT to hold arbitrary data fields. Instead, such data, whether structured or unstructured, is maintained separately and referenced by the NFT. This proposal recommends using one of the following two approaches to provide external references to obtain NFToken data and/or metadata.

URI field: We propose an optional URI field in the NFToken object. Implementations MAY choose to use this field to provide an external reference to:

The immutable content for Hash.
Mutable metadata, if any, for the NFToken object.

The URI field is especially useful for referring to non-traditional Peer-to-Peer (P2P) URLs. For example, a NFTokenMinter wishing to store NFToken data and/or metadata using the Inter Planetary File System (IPFS) MAY use URI field to refer to data on IPFS in different ways, each of which is suited to different use-cases. For more context on types of IPFS links that can be used to store NFT data, see here.

Domain field: Alternative to the above approach, issuers of NFToken objects may set the Domain field of their issuing account to the correct domain and offer an API for clients that want to lookup the data and/or metadata associated with a particular NFT. This proposal recommends the use of DNS TXT records as a customization point, allowing the issuer to specify the URL to be used by providing a properly-formatted TXT record.

Note that using this mechanism requires the NFTokenMinter to acquire a domain name and set the domain name for their minting account, but does not require the NFTokenMinter to necessarily operate a server
or other service to provide the ability to query this data; instead, a NFTokenMinter can easily "redirect" queries to a data provider (e.g., to a marketplace, registry or other service).
Implementations should attempt to check for the presence of URI field first to retrieve the associated data and/or metadata. In case URI field does not exist, implementations should check for the presence of Domain field. Nothing happens, if neither of the fields exist. Implementations should be prepared to handle HTTP redirections (e.g., using HTTP responses 301, 302, 307 and 308) from the URI.
TXT Record Format:
xrpl-nft-data-token-info-v1 IN TXT "https://host.example.com/api/token-info/{:NFTokenID:}"

The string {:NFTokenID:} should be replaced with the requested tokens' NFTokenID, as a 64 byte hex string when attempting to query information.
Implementations should check for the presence of TXT records and use those query strings if present. If no string is present, implementations should attempt to use a default URL. Assuming the domain was example.com, the default URL this proposal recommends would be:
https://example.com/.well-known/xrpl-nft/{:nft_id:}
The NFTokenPage ledger entry
This object represents a collection of NFToken objects owned by the same account. It is important to note that the NFToken objects themselves reside within this page, instead of in a dedicated object entry in the SHAMap. An account can have multiple NFTokenPage ledger objects, which form a doubly-linked list (DLL).
In the interest of minimizing the size of a page and optimizing storage, the Owner field is not present since it is encoded as part of the object's ledger identifier (more details in the NFTokenPageID discussion).
Fields
An NFTokenPage object may have the following required and optional fields:

Field Name
Required?
JSON Type
Internal Type

LedgerEntryType
:heavy_check_mark:
string
UINT16

Identifies the type of ledger object. This proposal recommends the value 0x0050 as the reserved ledger entry type.

Field Name
Required?
JSON Type
Internal Type

PreviousPageMin

string
UINT256

The locator of the previous page, if any. Details about this field and how it should be used are outlined below, after the construction of the NFTokenPageID is explained.

Field Name
Required?
JSON Type
Internal Type

NextPageMin

string
UINT256

The locator of the next page, if any. Details about this field and how it should be used are outlined below, after the construction of the NFTokenPageID is explained.

Field Name
Required?
JSON Type
Internal Type

PreviousTxnID

string
HASH256

Identifies the transaction ID of the transaction that most recently modified this NFTokenPage object.

Field Name
Required?
JSON Type
Internal Type

PreviousTxnLgrSeq

number
UINT32

The sequence of the ledger that contains the transaction that most recently modified this NFTokenPage object.

Field Name
Required?
JSON Type
Internal Type

NFTokens
:heavy_check_mark:
object
TOKEN

The collection of NFToken objects contained in this NFTokenPage object. This specification places an upper bound of 32 NFToken objects per page. Objects should be stored in sorted order, from low to high with the low order 96 bits of the NFTokenID used as the sorting parameter.

TokenPage ID Format
Unlike other object identifiers on the XRP Ledger, which are derived by hashing a collection of data using SHA512-Half, NFTokenPage identifiers are constructed so as to specfically allow for the adoption of a more efficient paging structure, ideally suited for NFTs.
The identifier of an NFTokenPage is derived by concatenating the 160-bit AccountID of the owner of the page, followed by a 96 bit value that indicates whether a particular NFTokenID may be contained in this page.
More specifically, and assuming that the function low96(x) returns the low 96 bits of a 256-bit value, an NFT with NFTokenID A can be included in a page with NFTokenPageID B if and only if low96(A) >= low96(B).
For example, applying the low96 function to the NFT described before, which had an ID of 000B013A95F14B0044F78A264E41713C64B5F89242540EE208C3098E00000D65 the function low96 would return 42540EE208C3098E00000D65.
This curious construct exploits the structure of the SHAMap to allow for efficient lookups of individual NFToken objects without requiring iteration of the doubly-linked list of NFTokenPages.
Example TokenPage JSON
{
    "LedgerEntryType": "NFTokenPage",
    "PreviousTokenPage": "598EDFD7CF73460FB8C695d6a9397E907378C8A841F7204C793DCBEF5406",
    "PreviousTokenNext": "598EDFD7CF73460FB8C695d6a9397E9073781BA3B78198904F659AAA252A",
    "PreviousTxnID": "95C8761B22894E328646F7A70035E9DFBECC90EDD83E43B7B973F626D21A0822",
    "PreviousTxnLgrSeq": 42891441,
    "Tokens":
        {
            {
                "NFTokenID": "000B013A95F14B0044F78A264E41713C64B5F89242540EE208C3098E00000D65",
                "URI": "ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf4dfuylqabf3oclgtqy55fbzdi"
            },
            /* potentially more objects */
       }
}

How do NFTokenPage objects work?
The page within which an NFToken entry is stored will be formed as described above. This is needed to find the correct starting point in the doubly-linked list of NFTokenPage objects if that list is large. This is because it is inefficient to have to traverse the list from the beginning if an account holds thousands of NFToken objects in hundreds of NFTokenPage objects.
Searching an NFToken object
To search for a specific NFToken, the first step is to locate the NFTokenPage, if any, that should contain that NFToken. For that do the following:
Compute the NFTokenPageID using the account of the owner and the NFTokenID of the token, as described above. Then search for the ledger entry whose identifier is less than or equal to that value. If that entry does not exist or is not an NFTokenPage, the NFToken is not held by the given account.
Adding an NFToken object
An NFToken object can be added by using the same approach to find the NFTokenPage it should be in and adding it to that page. If after addition the page overflows, find the next and previous pages (if any) and balance those three pages, inserting a new page as/if needed.
Removing an NFToken object
An NFToken can be removed by using the same approach. If the number of NFTokens in the page goes below a certain threshhold, an attempt will be made to consolidate the page with a previous or subsequent page and recover the reserve.
Reserve for NFTokenPage object
Each NFTokenPage costs an incremental reserve to the owner account. This specification allows up to 32 NFToken entries per page, which means that for accounts that hold multiple NFTs the effective reserve cost per NFT can be as low as R/32 where R is the incremental reserve.
The reserve in practice
The value of the incremental reserve is, as of this writing, 2 XRP. The table below shows what the effective reserve per token is, if a given page contains 1, 8, 16, 32 and 64 NFTs:

Incremental Reserve
1 NFT
8 NFTs
16 NFTs
32 NFTs
64 NFTs

5 XRP
5 XRP
0.625 XRP
0.3125 XRP
0.15625 XRP
0.07812 XRP

2 XRP
2 XRP
0.25 XRP
0.125  XRP
0.0625 XRP
0.03125 XRP

1 XRP
1 XRP
0.125 XRP
0.0625 XRP
0.03125 XRP
0.01562 XRP

Transactions
This proposal introduces several new transactions to allow for the minting, burning and trading of NFTs. All transactions introduced by this proposal incorporate the common transaction fields
that are shared by all transactions. Common fields are not document in this proposal unless needed because this proposal introduces new possible values for such fields.
Transactions for minting and burning NFTs on XRPL
We define two transactions: NFTokenMint and NFTokenBurn for minting and burning NFTs respectively on XRPL.
The NFTokenMint transaction
The NFTokenMint transaction creates an NFToken object and adds it to the relevant NFTokenPage object of the NFTokenMinter. A required parameter to this transaction is the Token field specifying the actual token. This transaction is the only opportunity the NFTokenMinter has to specify any token fields that are defined as immutable (e.g., the TokenFlags).
If the transaction is successful, the newly minted NFToken will be owned by the account (the NFTokenMinter account) which executed the transaction. If needed, a new NFTokenPage is created for this account and a reserve is charged as described earlier.
Transaction-specific Fields

Field Name
Required?
JSON Type
Internal Type

TransactionType
:heavy_check_mark:
string
UINT16

Indicates the new transaction type NFTokenMint. The integer value is 25.

Field Name
Required?
JSON Type
Internal Type

Account
:heavy_check_mark:
string
ACCOUNT ID

Indicates the account which is minting the token. The account MUST either:

match the Issuer field in the NFToken object; or
match the NFTokenMinter field in the AccountRoot of the Issuer field in the NFToken object.

Field Name
Required?
JSON Type
Internal Type

Issuer

string
ACCOUNT ID

Indicates the account that should be the issuer of this token. This value is optional and should only be specified if the account executing the transaction is not the Issuer of the NFToken object. If it is present, the NFTokenMinter field in the AccountRoot of the Issuer field must match the Account, otherwise the transaction will fail.

Field Name
Required?
JSON Type
Internal Type

NFTokenTaxon
:heavy_check_mark:
number
UINT32

Indicates the taxon associated with this token. The taxon is generally a value chosen by the NFTokenMinter of the token and a given taxon may be used for multiple tokens.  Taxons have a valid range range from 0x0 to 0xFFFFFFFF.

Field Name
Required?
JSON Type
Internal Type

Flags

number
UINT32

Specifies the flags for this transaction. In addition to the universal transaction flags that are applicable to all transactions (e.g., tfFullyCanonicalSig), the following transaction-specific flags are defined and used to set the appropriate fields in the NFT:

Flag Name
Flag Value
Description

tfBurnable
0x00000001
If set, indicates that the lsfBurnable flag should be set.

tfOnlyXRP
0x00000002
If set, indicates that the lsfOnlyXRP flag should be set.

tfTrustLine
0x00000004
If set, indicates that the lsfTrustLine flag should be set.

tfTransferable
0x00000008
If set, indicates that the lsfTransferable flag should be set.

Field Name
Required?
JSON Type
Internal Type

TransferFee

number
UINT16

The value specifies the fee to charged by the issuer for secondary sales of the Token, if such sales are allowed. Valid values for this field are between 0 and 50,000 inclusive, allowing transfer rates of between 0.000% and 50.000% in increments of 0.001.
The field MUST NOT be present if the tfTransferable flag is not set. If it is, the transaction should fail and a fee should be claimed.

Field Name
Required?
JSON Type
Internal Type

URI

string
BLOB

A URI that points to the data and/or metadata associated with the NFT. This field need not be an HTTP or HTTPS URL; it could be an IPFS URI, a magnet link, immediate data encoded as an RFC2379 "data" URL, or even an opaque issuer-specific encoding. The URI is NOT checked for validity, but the field is limited to a maximum length of 256 bytes.
Embedding additional information
If NFTokenMinters need to specify additional information during minting (for example, details identifying a property by referencing a particular plat, a vehicle by specifying a VIN, or other object-specific descriptions) they should use the memo functionality that is already available on the XRP Ledger as a common field. Memos are a part of the signed transaction and are available from historical archives, but are not stored in the ledger.

Example NFTokenMint transaction
{
  "TransactionType": "NFTokenMint",
  "Account": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
  "Issuer": "rNCFjv8Ek5oDrNiMJ3pw6eLLFtMjZLJnf2",
  "TransferFee": 314,
  "Flags":<PHONE_NUMBER>,
  "Fee": 10,
  "URI": "ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf4dfuylqabf3oclgtqy55fbzdi"
  "Memos": [
        {
            "Memo": {
                "MemoType": "687474703A2F2F6578616D706C652E636F6D2F6D656D6F2F67656E65726963",
                "MemoData": "72656E74"
            }
        }
    ],
}

This transaction assumes that the issuer, rNCFjv8Ek5oDrNiMJ3pw6eLLFtMjZLJnf2, has set the NFTokenMinter field in its AccountRoot to rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B, thereby authorizing that account to mint tokens on its behalf.
Execution
In executing, this transaction will examine the MintedNFTokens field in the account root of the Issuer and use it to construct the NFTokenID for the token being minted. If the field does not exist, the field will be assumed to have the value 0; the value of the field will then be incremented by exactly 1.
The NFTokenBurn transaction
The NFTokenBurn transaction is used to remove an NFToken object from the NFTokenPage in which it is being held, effectively removing the token from the ledger ("burning" it).
If this operation succeeds, the corresponding NFToken is removed. If this operation empties the NFTokenPage holding the NFToken or results in the consolidation, thus removing an NFTokenPage, the owner’s reserve requirement is reduced by one.
Transaction-specific Fields

Field Name
Required?
JSON Type
Internal Type

TransactionType
:heavy_check_mark:
string
UINT16

Indicates the new transaction type NFTokenBurn. The integer value is 26.

Field Name
Required?
JSON Type
Internal Type

Account
:heavy_check_mark:
string
ACCOUNT ID

Indicates the AccountID that submitted this transaction. The account MUST be either the present owner of the token or, if the lsfBurnable flag is set in the NFToken, either the issuer account or an account authorized by the issuer, i.e., NFTokenMinter.

Field Name
Required?
JSON Type
Internal Type

NFTokenID
:heavy_check_mark:
string
UINT256

Identifies the NFToken object to be removed by the transaction.
Example NFTokenBurn JSON
{
      "TransactionType": "NFTokenBurn",
      "Account": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
      "Fee": 10,
      "NFTokenID": "000B013A95F14B0044F78A264E41713C64B5F89242540EE208C3098E00000D65"
}

1.3. Account Root modifications
This proposal introduces 3 additional fields in an AccountRoot:

The NFTokenMinter field;
The MintedNFTokens field; and the
The BurnedNFTokens field.

1.3.1 NFTokenMinter
It is likely that issuers may want to issue NFTs from their well-known account while, at the same time wanting to delegate the issuance of such NFTs to a mint or other third party. To enable this use case, this specification introduces a new, optional, field in the AccountRoot object.

Field Name
Required?
JSON Type
Internal Type

NFTokenMinter

string
AccountID

The NFTokenMinter field, if set, specifies an alternate account which is allowed to execute the NFTokenMint and NFTokenBurn operations on behalf of the account.
The AccountSet transaction should be augmented to allow the field to be set or cleared.
Note: Previous versions of this spec used the term MintAccount for this field.
1.3.2 MintedNFTokens
To ensure the uniqueness of NFToken objects, this proposal introduces the MintedNFTokens field. This field is used during the NFTokenMint transaction and used to form the NFTokenID of the new object. If this field is not present the value 0 is assumed.
1.3.3 BurnedNFTokens
To provide a convenient way to determine how many NFToken objects issued by an account are still active (i.e., not burned), this proposal introduces the BurnedNFTokens field. If this field is not present the value 0 is assumed. The field is incremented whenever a token issued by this account is burned.  So this field will be present and non-zero for any account that has issued at least one token and one or more of those tokens have been burned.
:memo: An account for which the difference between the number of minted and burned tokens, as stored in the MintedNFTokens and BurnedNFTokens fields respectively, is non-zero cannot be deleted.
1.4. Transferability of Tokens (NFTs)
Tokens which have the lsfTransferable flag set can be transferred among users. This is achieved by way of offers.
1.4.1. The NFTokenOffer ledger entry
The NFTokenOffer ledger entry represents an offer to buy, sell or transfer an NFToken object. An NFTokenOffer object is created as a result of NFTokenCreateOffer transaction by the owner of the NFToken.
<IP_ADDRESS>. NFTokenOfferID Format
The unique ID, a.k.a NFTokenOfferID of the NFTokenOffer object is the result of SHA512-Half of the following values concatenated in order:

The NFTokenOffer space key; this proposal recommends using the value 0x0074;
The AccountID of the account placing the offer; and
The Sequence (or Ticket) of the NFTokenCreateOffer transaction that will create the NFTokenOffer.

Fields

Field Name
Required?
JSON Type
Internal Type

Owner
:heavy_check_mark:
string
AccountID

Indicates the Owner of the account that is creating and owns the offer. Only the current Owner of an NFToken can create an offer to sell an NFToken, but any account can create an offer to buy an NFToken.

Field Name
Required?
JSON Type
Internal Type

LedgerEntryType
:heavy_check_mark:
string
UINT16

Indicates the type of ledger object. This proposal recommends using the value 0x0074.

Field Name
Required?
JSON Type
Internal Type

Flags
:heavy_check_mark:
number
UINT32

A set of flags associated with this object, used to specify various options or settings. This proposal only defines one flag at this time, used to determine if this is a Buy
or Sell offer:

Flag Name
Flag Value
Description

lsfSellToken
0x00000001
If set, indicates that the offer is a sell offer. Otherwise, the offer is a buy offer.

Field Name
Required?
JSON Type
Internal Type

PreviousTxnID
:heavy_check_mark:
string
Hash256

Indicates the identifying hash of the transaction that most recently modified this object.

Field Name
Required?
JSON Type
Internal Type

PreviousTxnLgrSeq
:heavy_check_mark:
number
UINT32

Indicates the index of the ledger that contains the transaction that most recently modified this object.

Field Name
Required?
JSON Type
Internal Type

NFTokenID
:heavy_check_mark:
string
UINT256

Specifies the NFTokenID of the NFToken object being referenced by this offer.

Field Name
Required?
JSON Type
Internal Type

Amount
:heavy_check_mark:
object or string
AMOUNT

Indicates the amount expected or offered for the NFToken. If the token has the lsfOnlyXRP flag set, the amount MUST be specified in XRP.
Sell offers that specify assets other than XRP must specify a non-zero amount. Sell offers which specify XRP can be 'free' (i.e., the Amount field may be equal to "0").

Field Name
Required?
JSON Type
Internal Type

Expiration

number
UINT32

Indicates the time after which the offer is no longer active. The value is the number of seconds since the Ripple Epoch.

Field Name
Required?
JSON Type
Internal Type

Destination

string
Account ID

Only allowed if the lsfSellToken flag is set.  Indicates the AccountID that this sell offer is intended for (either a buyer or a broker).  If present, only that account can accept the sell offer.

Field Name
Required?
JSON Type
Internal Type

OwnerNode

string
UINT64

Internal bookkeeping, indicating the page inside the owner directory where this token is being tracked. This field allows of the efficient deletion of offers.

Field Name
Required?
JSON Type
Internal Type

NFTokenOfferNode

string
UINT64

Internal bookkeeping, indicating the page inside the token buy or sell offer directory, as appropriate, where this token is being tracked. This field allows of the efficient deletion of offers.
1.5. How does NFTokenOffer work?
Unlike regular offers on XRPL, which are stored sorted by quality in an order book and are automatically matched by an on-ledger mechanism, an NFTokenOffer is not stored in an order book and will never be automatically matched or executed.
A buyer must explicitly choose to accept an NFTokenOffer that offers to buy an NFToken. Similarly, a seller must explicitly choose to accept a specific NFTokenOffer that offers to buy an NFToken object that they own.
1.5.1. Locating NFTokenOffer objects
Each token has two directories, one containing offers to buy the token and the other containing offers to sell the token. This makes it easy to find NFTokenOffer for a particular token. It is expected that off-ledger systems will be used to retrieve, present, communicate and effectuate the creation, enumeration, acceptance or cancellation of offers. For example, a marketplace may offer intuitive web- or app-based interfaces for users.
1.5.2. NFTokenOffer Reserve
Each NFTokenOffer object costs the account placing the offer one incremental reserve. As of this writing the incremental reserve is 2 XRP. The reserve can be recovered by cancelling the offer.  The reserve is also recovered if the offer is accepted, which removes the offer from the XRP Ledger.
1.5.3. NFTokenOffer Transactions
There are three defined transactions:

NFTokenCreateOffer
NFTokenCancelOffer
NFTokenOfferAccept

All three transactions have the generic set of transaction fields, some of which may be ommitted from this proposal for the sake of clarity.
1.5.4. NFTokenCreateOffer transaction
The NFTokenCreateOffer transaction creates either a new Sell offer for an NFToken owned by the account executing the transaction or a new Buy offer for NFToken owned by another account.
Each offer costs one incremental reserve.
<IP_ADDRESS>. Fields

Field Name
Required?
JSON Type
Internal Type

TransactionType
:heavy_check_mark:
string
UINT16

Indicates the new transaction type NFTokenCreateOffer. The integer identifier is 27.

Field Name
Required?
JSON Type
Internal Type

Account
:heavy_check_mark:
string
AccountID

Indicates the AccountID of the account that initiated the transaction.

Field Name
Required?
JSON Type
Internal Type

Owner

string
AccountID

Indicates the AccountID of the account that owns the corresponding NFToken.

If the offer is to buy a token, this field must be present and it must be different than Account (since an offer to buy a token one already holds is meaningless).
If the offer is to sell a token, this field must not be present, as the owner is, implicitly, the same as Account (since an offer to sell a token one doesn't already hold is meaningless).

Field Name
Required?
JSON Type
Internal Type

Flags
:heavy_check_mark:
number
UINT32

A set of flags that specifies options or controls the behavior of the transaction. This proposal only defines one flag at this time:

Flag Name
Flag Value
Description

tfSellToken
0x00000001
If set, indicates that the offer is a sell offer. Otherwise, it is a buy offer.

Note that the Flags field includes both transaction-specific and generic flags. This proposal only specifies the transaction-specific flags; all currently valid generics flags (e.g., tfFullyCanonicalSig) are applicable, but not listed here.
The transactor SHOULD NOT allow unknown flags to be set.

Field Name
Required?
JSON Type
Internal Type

NFTokenID
:heavy_check_mark:
string
Hash256

Identifies the NFTokenID of the NFToken object that the offer references.

Field Name
Required?
JSON Type
Internal Type

Amount
:heavy_check_mark:
Currency Amount
AMOUNT

Indicates the amount expected or offered for the Token.
The amount must be non-zero, except where this is an offer is an offer to sell and the asset is XRP; then it is legal to specify an amount of zero, which means that the current owner of the token is giving it away, gratis, either to anyone at all, or to the account identified by the Destination field.

Field Name
Required?
JSON Type
Internal Type

Expiration

number
UINT32

Indicates the time after which the offer will no longer be valid. The value is the number of seconds since the Ripple Epoch.

Field Name
Required?
JSON Type
Internal Type

Destination

string
AccountID

Only valid if the tfSellToken flag is set.  If present, indicates that this offer may only be accepted by the specified account (either a broker or a buyer). Attempts by other accounts to accept this offer MUST fail.
If succesful, NFTokenCreateOffer transaction results in the creation of NFTokenOffer object.
1.5.5. NFTokenCancelOffer transaction
The NFTokenCancelOffer transaction can be used to cancel existing token offers created using NFTokenCreateOffer.
<IP_ADDRESS> Permissions
An existing offer, represented by an NFTokenOffer object, can be cancelled by:

The account that originally created the NFTokenOffer;
The account in the Destination field of the NFTokenOffer, if one is present; or
Any account if the NFTokenOffer specifies an expiration time and the close time of the parent ledger in which the NFTokenCancelOffer is included is greater than the expiration time.

This transaction removes the listed NFTokenOffer object from the ledger, if present, and adjusts the reserve requirements accordingly. It is not an error if the NFTokenOffer cannot be found, and the transaction should complete successfully if that is the case.
Fields

Field Name
Required?
JSON Type
Internal Type

TransactionType
:heavy_check_mark:
string
UINT16

Indicates the new transaction type NFTokenCancelOffer. The integer identifier is 28.

Field Name
Required?
JSON Type
Internal Type

NFTokenOffers
:heavy_check_mark:
array
VECTOR256

An array of ledger entry IDs, each identifying an NFTokenOffer object, which should be cancelled by this transaction.
It is an error if an entry in this list points to an object that is not an NFTokenOffer object. It is not an error if an entry in this list points to an object that does not exist.

1.5.6. NFTokenOfferAccept transaction
The NFTokenOfferAccept transaction is used to accept offers to buy or sell an NFToken. It can either:

Allow one offer to be accepted. This is called direct mode.
Allow two distinct offers, one offering to buy a given NFToken and the other offering to sell the same NFToken, to be accepted in an atomic fashion. This is called brokered mode.

<IP_ADDRESS>. Brokered vs. Direct Mode
The mode in which the transaction operates depends on the presence of the NFTokenSellOffer and NFTokenBuyOffer fields of the transaction:

NFTokenSellOffer
NFTokenBuyOffer
Mode

:heavy_check_mark:
:heavy_check_mark:
Brokered

:heavy_check_mark:
:x:
Direct

:x:
:heavy_check_mark:
Direct

If neither of those fields is specified, the transaction is malformed and shall produce a tem class error.
The semantics of brokered mode are slightly different than one in direct mode: The account executing the transaction functions as a broker, bringing the two offers together and causing them to be matched but does not acquire ownership of the involved NFT, which will, if the transaction is successful, be transferred directly from the seller to the buyer.
<IP_ADDRESS>. Execution Details
<IP_ADDRESS>.1. Direct Mode
In direct mode, NFTokenOfferAccept transaction MUST fail if:

The NFTokenOffer against which NFTokenOfferAccept transaction is placed is an offer to buy
the NFToken and the account executing the NFTokenOfferAccept is not, at the time of execution, the current owner of the corresponding NFToken.
The NFTokenOffer against which NFTokenOfferAccept transaction is placed is an offer to sell
the NFToken and was placed by an account which is not, at the time of execution, the current owner of the NFToken.
The NFTokenOffer against which NFTokenOfferAccept transaction is placed is an offer to sell
the NFToken and was placed by an account which is not, at the time of execution, the Account in the recipient field of the NFTokenOffer, if there exist one.
The NFTokenOffer against which NFTokenOfferAccept transaction is placed specifies an expiration time and the close time field of the parent of the ledger in which the transaction
would be included has already passed.
The NFTokenOffer against which NFTokenOfferAccept transaction is placed to buy or sell the NFToken
is owned by the account executing the NFTokenOfferAccept.

If the transaction is executed successfully then:

The relevant NFTtoken will change ownership, meaning that the token will be removed from the NFTokenPage of the existing owner and be added to the NFTokenPage of the new owner.
Funds will be transferred from the buyer to the seller, as specified in the NFTokenOffer. If the corresponding NFToken offer specifies a TransferRate, then the issuer receives the specified percentage, with the balance going to the seller of the NFToken.

<IP_ADDRESS>.2. Brokered Mode
In brokered mode, NFTokenOfferAccept transaction MUST fail if:

The buy NFTokenOffer against which NFTokenOfferAccept transaction is placed is owned by the account executing the transaction.
The sell NFTokenOffer against which NFTokenOfferAccept transaction is placed is owned by the account executing the transaction.
The account which placed the offer to sell the NFToken is not, at the time of execution the current owner of the corresponding NFToken.
Either offer (buy or sell) specifies an expiration time and the close time field of the parent of the ledger in which the transaction would be included has already passed.

<IP_ADDRESS>. Fields

Field Name
Required?
JSON Type
Internal Type

TransactionType
:heavy_check_mark:
string
UINT16

Indicates the new transaction type NFTokenOfferAccept. The sequence number of a previous NFTokenCreateOffer transaction. The integer identifier is 29.

Field Name
Required?
JSON Type
Internal Type

NFTokenSellOffer

string
UINT256

Identifies the NFTokenOffer that offers to sell the NFToken.
:memo: In direct mode this field is optional, but either NFTokenSellOffer or NFTokenBuyOffer must be specified. In brokered mode, both NFTokenSellOffer and NFTokenBuyOffer MUST be specified.

Field Name
Required?
JSON Type
Internal Type

NFTokenBuyOffer

string
UINT256

Identifies the NFTokenOffer that offers to buy the NFToken.
:memo: In direct mode this field is optional, but either NFTokenSellOffer or NFTokenBuyOffer must be specified. In brokered mode, both NFTokenSellOffer and NFTokenBuyOffer MUST be specified.

Field Name
Required?
JSON Type
Internal Type

NFTokenBrokerFee

object or string
AMOUNT

This field is only valid in brokered mode and specifies the amount that the broker will keep as part of their fee for bringing the two offers together; the remaining amount will be sent to the seller of the NFToken being bought. If specified, the fee must be such that, prior to accounting for the transfer fee charged by the issuer, the amount that the seller would receive is at least as much as the amount indicated in the sell offer.
This functionality is intended to allow the owner of an NFToken to offer their token for sale to a third party broker, who may then attempt to sell the NFToken on for a larger amount, without the broker having to own the NFToken or custody funds.
:memo: If both offers are for the same asset, it is possible that the order in which funds are transferred might cause a transaction that would succeed to fail due to an apparent lack of funds. To ensure deterministic transaction execution and maximimize the chances of successful execution, this proposal requires that the account attempting to buy the NFToken is debited first and that funds due to the broker are credited before crediting the seller or issuer.
:note: In brokered mode, The offers referenced by NFTokenBuyOffer and NFTokenSellOffer must both specify the same NFTokenID; that is, both must be for the same NFToken.

This needs to be checked against actual implementation and be converted to a non-draft standard, according to README.md.

Can one use this standard be used for fractional NFT? If not, what other strategies can use to achieve it


⚠ ClamAV has degraded performance

In cbfec27, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 68 ms

Resolved: ClamAV performance has improved in c1696c5.


Is there any plugin version for UE 5.3?

I'm really impressed with the UEAzSpeech! Unfortunately, I'm currently using Unreal Engine 5.3.  Is there an older version of the plugin available that works with UE 5.3, or are there any workarounds I can try?

Also, there seems like the repo has reached a quota for LFS Files, so i am unable to clone the repo also and do any changes, kindly add LFS Quota.


GoNeovim crashes when connecting two clients to one server

OS Version: Linux 5.0.0-37-generic 40~18.04.1-Ubuntu SMP Thu Nov 14 12:06:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Neovim version: NVIM v0.5.0-279-ge922576bd
GoNeovim version: 0.4.2
GoNeovim crashes when trying to connect two GoNeovim clients to a single neovim server. Steps to reproduce:

Start GoNeovim
Get the server address with :echo $NVIM_LISTEN_ADDRESS
Connect to that address with goneovim --server=…

This results in the following error message:
msgpack/rpc: session closed
read unix @->/tmp/nvimmaxcCN/0: read: connection reset by peer
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x971276]

goroutine 14 [running]:
github.com/neovim/go-client/nvim.(*Nvim).call(0x0, 0xd07231, 0xc, 0x0, 0x0, 0xc00027a480, 0x1, 0x1, 0xc0000163a8, 0xe1ada0)
        github.com/neovim/go-client/nvim/nvim.go:406 +0x26
github.com/neovim/go-client/nvim.(*Nvim).Command(0x0, 0xcff6d6, 0x3, 0xc000233690, 0x830e96)
        github.com/neovim/go-client/nvim/apiimp.go:740 +0xb6
created by github.com/akiyosi/goneovim/editor.(*MiniMap).exit
        github.com/akiyosi/goneovim/editor/minimap.go:157 +0x5b

Hi :D
Thanks for this issue report. Thanks also for the informative discussion in the gitter.
I made a fix at commit number b00298249e15198151e0916a85453652ea5caaf8 to improve this problem.
This problem will be improved in the next release.

This problem has been fixed in v0.4.4
Is it possible to confirm the problem?

Yup, I can confirm that this is fixed with Goneovim-0.4.4 :)


rand_meth_st structure is wrong in 1.1.1 docs @ https://www.openssl.org/docs/man1.1.1/man3/RAND_get_rand_method.html

The current structure def for rand_meth_st is not documented correctly online.
The code level def in 1.1.1 shows the seed function returning an int however on the documentation page, it's a void return.
Also, the add function now takes a double as the 3rd argument however the docs still show an int.
I couldn't find a commit for an explanation as to why this was changed, so maybe a blurb describing the expected range of values in the return for the seed function would be good.
Thanks!
Jake

The add function was introduced in commit eb952088f in January 2000 with an int as the entropy estimate value - and the docs were written at that time. It was changed a month later by commit 853f757e in order to "Allow for higher granularity of entropy estimates by using 'double' instead of 'unsigned' counters.", but the documentation wasn't updated at the same time....and no one noticed for nearly 20 years. :-)
The return type of the seed function was changed by commit b6dcdbfc which had this CHANGES entry:

Extensive audit of libcrypto with DEBUG_UNUSED. Fix many cases where
return value is ignored. NB. The functions RAND_add(), RAND_seed(),
BIO_set_cipher() and some obscure PEM functions were changed so they
can now return an error. The RAND changes required a change to the
RAND_METHOD structure.
[Steve Henson]

That commit was in September 2009 and neglected to update the documentation...and no one noticed for 10 years!

Ouch! Well... Hopefully I can make some headway here. I'm actually considering reverting the seeding change in our customized code just to get around a build error until I can find a way to implement the return value in a way that makes sense. Thanks for the prompt response!
On another note, the history for the file ended in 2015 in the git branch so it was hard to peek back further in time. Do you have any suggestions for how to better come up to speed on openssl commit history?

I assume you are referring to rand.h which was moved into its current location in 2015. If instead of git log you use git log --follow git will give the log all the way back in history even through file renames/moves and you can go all the way back to its original import into the repo from the precursor SSLeay project back in 1998.

Thanks Matt! Much appreciated!

git log --follow

Thanks for the hint!


you are not qualified to write a book

People spend their entire lives getting Phds and doing research to write books, who do you think you are?

+1

Thanks for the suppe @benhgreen

I wanted to try it! I didn't say I was going to write an amazing book. Just something I wanted to try to get all my notes out in a meaningful way.

I'm closing this! Stop being negative @faiq !


Fix:fortigate firewall cpu changes

Relevant information
Removed from specific attribute name from golden metric,
updated dashboard widget to use latest instead of max
Checklist

[x] I've read the guidelines and understand the acceptance criteria.
[x] The value of the attribute marked as identifier will be unique and valid.
[x] I've confirmed that my entity type wasn't already defined. If it is I'm providing an
explanation above.

@Mesverrum is this PR correct? the content & the description don't seem to align

I see what you mean,  in the file changes I see the GM change and not the dashboard update,  but the commit history contains both.   I'll double check but possibly I had already merged in the dashboard change in an earlier pr.

Ok i'll merge this one but the same file has other references to kentik/fortinet-fortigate that have not been removed. Is that expected?

Ok i'll merge this one but the same file has other references to kentik/fortinet-fortigate that have not been removed. Is that expected?

Yes that is expected, we only changed the CPU metric name


Support for Automatically Generating Code for Multiple Directories and Packages in sqlc

What do you want to change?
Question:
Hi, I’m using sqlc in my project, and I have a modular service structure like this:
service/
├── auth/
├── customers/
├── products/
├── orders/

Each service has its own queries.sql file, and I would like the generated Go files (e.g., auth.sql.go, customers.sql.go, etc.) to be placed in their respective directories with the correct package name.
Currently, I need to create separate blocks in the sqlc.yml file for each service manually, like this:
- engine: "postgresql"
  schema: "./cmd/migrate/migrations/schema.sql"
  queries: "./service/auth/queries.sql"
  gen:
    go:
      package: auth
      out: "./service/auth"

This works, but it can get repetitive as the number of services grows.
My question is:
Does sqlc plan to support a way to automatically detect and generate code for multiple directories and packages based on the queries.sql file location? For example, if queries.sql is in service/customers/, the generated code would automatically go to service/customers/ with the customers package name.
If not, is this something that could be considered for future releases?
What database engines need to be changed?
No response
What programming language backends need to be changed?
No response

Its not that bad if you exploit yaml defaults. You just add "override" lines for each service.
sql:
  - &default
    engine: "postgresql"
    schema: "./db/schemas/auth.sql"
    queries: "./service/auth/query"
    gen:
      go: &go_defaults
        emit_json_tags: true
        json_tags_case_style: "camel"
        emit_interface: true
        emit_pointers_for_null_types: true
        package: "repository"
        out: "./service/auth/repository"
       ....
  - <<: *default
    schema: "./db/schemas/customers.sql"
    queries: "./service/customers/query"
    gen:
      go:
        <<: *go_defaults
        out: "./service/customers/repository"
  - <<: *default
    schema: "./db/schemas/products.sql"
    queries: "./service/products/query"
    gen:
      go:
        <<: *go_defaults
        out: "./service/products/repository"

But I agree it would be nice to just point to "service" directory.


not working with rails 5

in rails 5.1.1 not working
gems/send_file_with_range-1.0.0/lib/send_file_with_range/controller_extension.rb:5:in included': undefined method alias_method_chain' for ActionController::DataStreaming:Module (NoMethodError)

@metalels has fixed this in his fork, although for some reason he hasn't submitted a PR.
As a temporary fix you can add this to your Gemfile
gem 'send_file_with_range', git: 'https://github.com/metalels/send_file_with_range.git', branch: 'rails51'

I have it working on rails 5.1.3 & ruby 2.4.1


Fix how usage is called

Fixes this problem with https://github.com/alphagov/digitalmarketplace-frontend-toolkit/pull/293.

👍


1-digit year of 0 or 1 as 1900 or 1901 instead of 0 AD or 1 AD

Describe the bug
Getting 1900 or 1901 instead of 0 AD or 1 AD, when picking 0 or 1 year.
To Reproduce
Steps to reproduce the behavior:

Set :year-range="[0, 10000]".
Pick year 0 or 1 in the year picker.
Get 1900 or 1901.

Expected behavior
Picking 0 or 1 year the result must be 01/01/0000 or 01/01/0001.
Screenshots
no
Desktop & mobile (please complete the following information):

Browser [all]
Library version [8.1.1]

This adds so much complexity, that it is not worth doing it as it will require a full rewrite. Here is a good read


Add changelog

Awesome project!
It would be nice to add a CHANGELOG file.

@rayrutjes - thanks for the suggestion:
https://github.com/wilmoore/php-version/blob/master/changelog.md


Set favorites web page is not available. (404)

Description
as a user, i can't start using your tutorials ((( set favorites tab is not available
STR:

Go to https://docs.microsoft.com/en-us/vsts/user-guide/?view=vsts and navigate to Step-by-Step Tutorials article
Click on link 'Set favorites'

Expected behavior
web page with content is opened.
Screenshot

Desktop

OS: [Windows]
Browser [chrome]
Version [latest]

stranges:
this web page is opened in ru locale, but i use en-us locale.

@BoiarynovQA Your issue is transferred to vsts team. They will help you there.


bug: Docker build failing for Mac M1

Bug Report
Papyrus version:
6ae90e27
Current behavior:
building docker file for MacM1 is returning error
executor failed running [/bin/sh -c rustup target add x86_64-unknown-linux-musl &&     CARGO_INCREMENTAL=0 cargo build  --target x86_64-unknown-linux-musl --release --package papyrus_node &&     CARGO_INCREMENTAL=0 cargo build   --target x86_64-unknown-linux-musl --release --package papyrus_load_test]: exit code: 137

Expected behavior:
Docker image should get created
Steps to reproduce:

Related code:

insert short code snippets here

Other information:

we need to use this specific commit version because we are on a custom app chain on starknet and we are getting issues related to 0x errors while trying with latest version / release tag
we are unable to build docker image for Mac M1 platform however able to run the node locally

The reported issue involves building a Docker image for the Papyrus version 6ae90e2 on a Mac M1 platform, resulting in an exit code 137. To resolve this, it is suggested to check and adjust resource allocations in Docker settings, ensure correct configurations for Rustup and Cargo targeting the x86_64-unknown-linux-musl platform, review the Dockerfile for proper architecture specifications, and consider using Docker Buildx for multi-platform support. Additionally, investigating commit-specific changes and seeking community support for the Papyrus project may provide insights into resolving the issue.


add duration to jobs view in jupyter

Finished adding duration column in jobs table display. Calculating based on compeltion - creation datetime or currentitme - creation datetime when running.

Merged with main.


BeginEditAt not working in enum fields.

beginEditAt(x,y) - its working fine in other fields except in enum fields. I want to list available options directly while calling beginEditAt but it requires one extra click after calling beginEditAt in enum types.

This is a known problem.  There is apparently no way to cause the select drop downs to programmatically open.  If you know of a way to do this I would love to add it here.  I think the only solution is to replace the standard select with a HTML/JS widget that behaves like a select.


Update charging-stats.json

Updated to address https://github.com/adriankumpf/teslamate/issues/528#
Added case statement to adjust to show kWh at non decimal level and MWh at the 3 decimal point level. Cannot address directly within grafana so used case statement. Removed grafana sorting so can be sorted properly in SQL since not a direct # now for grafana to sort.

Forgot to show what it looks like for quick reference.

I think it looks great and does exactly what I was after! Thank you @Dulanic :+1: I would be really happy if this is merged!


Add support for armed_night state

Home Assistant supports the armed_night state. This PR adds support for this state to the Alarm card.

We had troubles with .includes, #63 people use tileboard on IE. I think will be better create separate function in main controller (something like isDisarmed?) and use .indexOf instead.

Isn't armed_home identical to armed_night ?

We had troubles with .includes, #63 people use tileboard on IE. I think will be better create separate function in main controller (something like isDisarmed?) and use .indexOf instead.

Good one, I did not think to check that. I will refactor accordingly.

Isn't armed_home identical to armed_night ?

That depends I guess... They are implemented separately in Home Assistant. For my personal use case, they differ in use as well: armed_home is used for an extra sense/layer of security when someone is home alone, whereas armed_night is used (as the name suspects) to trigger on some other stuff as well during the night time.

@Juggels thank you. I've moved changes from .css file to .less (we use .less for developing, .css is basically translation)


Document what happens on entity state changes

From @Wain123 on July 11, 2018 14:29
When I manually set the state of an entity to Unchanged, the CurrentValues automatically get set to be equal to the OriginalValues. This makes sense but isn't documented in EntityEntry.State metadata.
Are there any other undocumented side effects of setting EntityEntry.State that I might have missed?
Copied from original issue: aspnet/EntityFrameworkCore#12631

@Wain123 I cannot think of any other side effects that could be unexpected. I am going to move this issue to our documentation repo so that we can track adding conceptual topics about managing state with these APIs.

Duplicate of #786


Topshelf.Linux doesn't appear to be working`

Hi,
I've added the Topshelf.Linux nuget package to my solution and attempting to load my service from the commandline. Is there any further configuration that I need to do, or a particular command line switch?
Error is the same as pre-installation (may not be Topshelf.Linux related...!)
Topshelf v<IP_ADDRESS>, .NET Framework v4.0.30319.17020
Default Error: 0 : Unable to get parent process (ignored) System.EntryPointNotFoundException: CreateToolhelp32Snapshot
at (wrapper managed-to-native) Topshelf.Runtime.Windows.Kernel32:CreateToolhelp32Snapshot (uint,uint)
at Topshelf.Runtime.Windows.WindowsHostEnvironment.GetParent (System.Diagnostics.Process child) [0x00000] in :0
Default Error: 0 : The service terminated abnormally System.NotImplementedException: The requested feature is not implemented.
at System.ServiceProcess.UnixServiceController.GetServices () [0x00000] in :0
at System.ServiceProcess.ServiceController.GetServices (System.String machineName) [0x00000] in :0
at System.ServiceProcess.ServiceController.GetServices () [0x00000] in :0
at Topshelf.Runtime.Windows.WindowsHostEnvironment.IsServiceInstalled (System.String serviceName) [0x00000] in :0
at Topshelf.Hosts.ConsoleRunHost.Run () [0x00000] in :0
at Topshelf.HostFactory.Run (System.Action`1 configureCallback) [0x00000] in :0

So you add Topshelf and Topshelf.Linux libraries with nuget and then define HostFactory.Run method and after that what ? If I start the application from MonoDevelop in debug mode all things are good but what I want to do is to start application in background so If I close the terminal the application would still running. Running the application with mono-service would give me an ouput like this:
mono-service -l:test.lock --no-daemon RDLService.exe -port:27015
Topshelf.HostFactory Error: 0 : An exception occurred creating the host, Topshelf.HostConfigurationException: The service was not properly configured:  [Failure] Command Line An unknown command-line option was found: DEFINE: l = test.lock [Failure] Command Line An unknown command-line option was found: ARGUMENT: RDLService.exe [Success] Name RDLService-Nancy-SelfHost [Success] DisplayName RDLService Nancy-SelfHost Service [Success] Description RDLService Nancy-SelfHost [Success] ServiceName RDLService-Nancy-SelfHost   at Topshelf.Configurators.ValidateConfigurationResult.CompileResults (System.Collections.Generic.IEnumerable1[T] results) [0x0002b] in <1c618df2ec3c41f28e50fc16c6be4d5b>:0
at Topshelf.HostFactory.New (System.Action1[T] configureCallback) [0x00052] in <1c618df2ec3c41f28e50fc16c6be4d5b>:0  Topshelf.HostFactory Error: 0 : The service terminated abnormally, Topshelf.HostConfigurationException: The service was not properly configured:  [Failure] Command Line An unknown command-line option was found: DEFINE: l = test.lock [Failure] Command Line An unknown command-line option was found: ARGUMENT: RDLService.exe [Success] Name RDLService-Nancy-SelfHost [Success] DisplayName RDLService Nancy-SelfHost Service [Success] Description RDLService Nancy-SelfHost [Success] ServiceName RDLService-Nancy-SelfHost   at Topshelf.Configurators.ValidateConfigurationResult.CompileResults (System.Collections.Generic.IEnumerable1[T] results) [0x0002b] in <1c618df2ec3c41f28e50fc16c6be4d5b>:0
at Topshelf.HostFactory.New (System.Action1[T] configureCallback) [0x00052] in <1c618df2ec3c41f28e50fc16c6be4d5b>:0

@George02 Please, try to append a minimum sample .cs file in order to repro your issue. And maybe open an independent issue here at github.
Regards

Btw, this is a excerpt code from a Program.cs using Topshelf.Linux:
                         //Start the container
                        using (var container = new WindsorContainer())
                        {
                                var settings = new SettingsAdapter().Create<ISettings>(ConfigurationManager.AppSettings);

                                container.Install(
                                        new Startup.MainInstaller(settings),
                                        new Startup.RebusInstaller(settings),
                                        new Startup.MediatRInstaller()
                                );

                                var service = container.Resolve<DaemonService>();

                                //Start the service
                                HostFactory.Run(x =>
                                {
                                        x.UseNLog();
                                        x.UseLinuxIfAvailable();
                                        x.SetServiceName(ProgramName);
                                        x.SetDescription("Sample Daemon Service");
                                        x.StartAutomatically();
                                        x.RunAsLocalSystem();
                                        x.Service(() => service);
                                });

                                container.Release(service);
                        }


Entity

Hi. Its possible to save Entities in setting field ?
dmishh_settings:
    settings:
        project_filter:
            type: entity
            options: {class: AppBundle:Project, multiple: true, choice_label: name}

In this config it save, but then on form load (/settings/global) symfony throw error

Entities passed to the choice field must be managed. Maybe persist them in the entity manager?

Solved
choice_value: id
dmishh_settings:
    settings:
        project_filter:
            type: entity
            options: {class: AppBundle:Project, multiple: true, choice_label: name, choice_value: id}


Implement multi-tenancy support

Remaining items:

[ ] X.509 client certs
[ ] Publish multi Kafka topics
[ ] Fixing up command and control

Remaining items:

[ ] X.509 client certs
[ ] Publish multi Kafka topics
[ ] Fixing up command and control


Expose implementations of platform specific identities

Currently putting this into the broker package, I thought this was an okay place because callers already need to import the broker package to get the request context struct. Implementation is based on the spec definition.
(edit: including the link to OSB API Definitions)

Depends on #9 to use the new constants in v2/constants.go from pmorie/go-open-service-broker-client#111

@shawn-hurley Seem like that PR was merged, now you can bump up the dep on the client to 0.0.5 and then we can re-review this?

@LiliC If you look at #9 that has the code to bump the vendor. If that could be merged first then this should be good.

@shawn-hurley Sorry about that, misread the comment above!

@LiliC @pmorie just a ping to let you know the dependent PR has been merged

Also another thing is would be great to have an example use case in the osb-starter-pack broker for this. WDYT?

to have an example use case in the osb-starter-pack broker for this

I think that makes sense. The question I have is should that be added to the starter-pack after this is added to the lib and is released or should we create the example now with a dependency on this PR? I think developing that might be harder than the first way IMO

I think that makes sense. The question I have is should that be added to the starter-pack after this is added to the lib and is released or should we create the example now with a dependency on this PR? I think developing that might be harder than the first way IMO

IMO after this is released should be fine.

@LiliC @pmorie @n3wscott @kibbles-n-bytes @jmrodri
I have updated the implementation if you all could take a look and see if this is what you were expecting.

LGTM now

lgtm, what's left here?


DrawerKit 0.4.1

Fixed a bug whereby the drawer's shadow might not respect the round nature of the drawer's upper corners.

I'm going to temporarily close this PR to change how the borders and shadows are implemented.


resize-observer: window is not defined

Describe the bug
In my Next.js project, after updating to 2.x of resize-observer, my project won't build. The resulting js seems to assume "window" is defined, but the server-side compiling that happens in their system doesn't have window defined I guess. Sorry for the lack of details and clarification.. I am not really a web guy and barely understand what's going on here.
However, when this check
 to make sure window is defined was removed, it seems that broke whatever next.js is doing. Would it be possible for a check like this to be added back?

https://github.com/jaredLunde/react-hook/issues/314

ah, whoops! didn't see that. thanks :)


Eventually we should just use some or another CLI lib

wrt https://github.com/peggyjs/peggy/pull/70/files#diff-373018ba4534661dac9c14da96561406479fbdfadef98eed966f9697372eb469R104
... ew
Everybody argues about what CLI to use.  I kind of like commander but I'm open to most things
Whatever it is should build cleanly under rollup on all three major platforms, bare minimum

See https://github.com/peggyjs/peggy/discussions/31

oh


Add more unittest

Codecov Report

Merging #76 into release-0.2 will increase coverage by 2.43%.
The diff coverage is 100%.

@@                Coverage Diff                @@
##             release-0.2      #76      +/-   ##
=================================================
+ Coverage          43.72%   46.16%   +2.43%
- Complexity           540      557      +17
=================================================
  Files                111      111
  Lines               3524     3522       -2
  Branches             258      258
=================================================
+ Hits                1541     1626      +85
+ Misses              1859     1779      -80
+ Partials             124      117       -7

Impacted Files
Coverage Δ
Complexity Δ

...com/webank/wecross/stub/remote/RemoteResource.java
93.86% <ø> (+41.13%)
23 <0> (+8)
:arrow_up:

...stub/remote/RemoteTransactionResponseCallback.java
53.84% <100%> (+38.46%)
2 <1> (+1)
:arrow_up:

...ava/com/webank/wecross/p2p/engine/P2PResponse.java
60.86% <0%> (+60.86%)
8% <0%> (+8%)
:arrow_up:

Continue to review full report at Codecov.

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


Add setting where to place currency symbol

I noticed that while using the USD $ symbol, it is placed before (left side) the numbers. But when I tried selecting a couple other currency symbols - I tried IDR/id (as it's my local currency) and a few of the EUR ones - they are placed behind (right side) the numbers.
Especially for the Euro-symbol ones, there are some that have the symbols on the left side 🤔.
I've taken a look at numbro, but there doesn't seem to be any config about the symbol placement.
Would it be possible to have a setting to allow users to choose where the symbols are placed?
Thanks!

Oh, I just dug a bit deeper and found that in numbro there is in fact a way to specify postfix or prefix.
I'll try to create a issue / PR there to adjust this

For now, it should at least follow the standard format per country/currency. The only config I've modified is the mantissa which is defined to 2. If you feel like the default currency format is wrong, you can submit an issue on numbro  instead.
I'm closing this temporarily but happy to reopen this if there's a lot of users that needs this particular issue.

I have opened a PR over in numbro specific for my local currency, but I couldn't really get a solid reference material - at least not online - on where the symbols should be placed for my local currency :thinking:
anyway, thanks for the clarification!


Fast timeout operator when leader changed

Feature Request
Describe your feature request related problem:

If the leader changed cause by TiKV(maybe too busy or network probme), the operator cannot step to the final state, such as
PD:
try to remove peer 24
TiKV:
reject remove peer 24 because it is a leader.

Then the operator needs 10mins to timeout, which may cause the rule sync learner became slow.
Describe the feature you'd like:

Describe alternatives you've considered:

We can check if the peer is the leader then fast timeout the operator.
Teachability, Documentation, Adoption, Migration Strategy:

Go

Looks too tricky. How about TiKV attach some info in heartbeat to cancel the operator explicitly?

In my patch, I will check the step safety before sending it to TiKV. If the step is to remove the peer and the region leader is the same as the peer,  we can cancel the operator. but it only solves this one situation.


[FLINK-1720] Integrate ScalaDoc into JavaDoc

This uses genjavadoc to generate Fake Java Source that only serves as a proxy for the Scala code. ScalaDoc syntax in the original will be converted to JavaDoc syntax in the Fake Code.
This is only executed in the docs-and-source profile, so normal build behaviour is not affected.

Looks good, will merge this...


Feature/regex matching

We would like to be able to match using regex. I'm opening this as a draft since we plan to continue working / redesigning before trying to get our changes merged in :).
Example use case:
nrohn-a01 nr $ BBL_IAAS=aws ./leftovers -f "pull-1408.*security" --aws-secret-access-key=*** --aws-access-key-id=***  --aws-region=*** --dry-run --filter-as-regex
[EC2 Security Group: nat_security_group (Name:pull-1408-nat-security-group, Environment:pull-1408, Application:Cloud Foundry)]
[EC2 Security Group: ops_manager_security_group (Environment:pull-1408, Application:Cloud Foundry, Name:pull-1408-ops-manager-security-group)]
[EC2 Security Group: web_lb_security_group (Name:pull-1408-lb-security-group, Environment:pull-1408, Application:Cloud Foundry)]
[EC2 Security Group: rds_security_group (Application:Cloud Foundry, Name:pull-1408-rds-security-group, Environment:pull-1408)]
[EC2 Security Group: tcp_lb_security_group (Environment:pull-1408, Application:Cloud Foundry, Name:pull-1408-tcp-lb-security-group)]
[EC2 Security Group: ssh_lb_security_group (Name:pull-1408-ssh-lb-security-group, Environment:pull-1408, Application:Cloud Foundry)]
...

This PR also reorders some AWS resource deletion by their type, and adds waits to a couple resources so we don't fail improperly (especially important for RDS, which takes ~10 minutes to delete)
Thanks!
cc @ciriarte

TODO: I need to remove a few debugging lines

Hi @genevieve, if we wanted to get this merged upstream I assume we'll need to reintroduce vendoring and add more test coverage? Would you also want us to refactor the regex filter flag? We can also maintain our own fork if that's preferable. Thank you!!

Hey Nick! Yes, if you wouldnt mind reintroducing vendoring and adding more test coverage, we can merge these changes!

Thanks! I'll try to get it ready to be merged in a couple weeks.

Thank you for the review @rowanjacobs. I still need to get around to getting this ready for merge. I'm trying to find time


18842 Antoine Mapp

Not sure if Robeson - Human Serv HS is the same as Paul Roberson
staff signature date missing

it is.
Use application date if apporoval date is missing.


[docs] Update the contribution guide to reflect changes in the docs workflow

\cc @DevExpress/testcafe-docs @Nuarat @miherlosev
Updated the contribution guide with details on how to contribute to documentation.

Let's show it to Dirk before we merge


openssl 3.0.6 fails to build on 10.8.5 with Xcode 5.1.1 clang: rsaz-x86_64.s:: error: invalid instruction mnemonic 'adcxq'

The bug was reported back in openssl 1.0.2, but apparently never fixed: https://github.com/openssl/openssl/issues/494
The current openssl3 still fails on 10.8.5 with the same:
rsaz-x86_64.s:418:2: error: invalid instruction mnemonic 'adcxq'

etc.
https://trac.macports.org/ticket/64037

The original issue was supposedly fixed by e780ed0336, so I suspect that this is something slightly different.
Do we know what clang -v reports on this platform?

Is it possibly a regression from https://github.com/openssl/openssl/pull/19352?

Is it possibly a regression from #19352?

Hardly, as it doesn't touch the same file.  However, it's probably the same problem, just elsewhere.  #19352 is a quick fix that only covers the issue reported, I didn't do a thorough search for other places that might or might not have the same sort of problem.
However, this issue indicates that such a thorough search might be necessary.
I can take that, since I've already done the grunt of the work...

The original issue was supposedly fixed by e780ed0, so I suspect that this is something slightly different.
Do we know what clang -v reports on this platform?

10:~ svacchanda$ clang -v
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.6.0
Thread model: posix
10:~ svacchanda$ which clang
/usr/bin/clang

@catap Tagging you just in case.

openssl 1.1.1r also fails in the same manner.
main.log


Outline plans to write the record indexing Dag

I put an outline in the Write the indexer DAG issue: https://github.com/ucldc/rikolti/issues/515

Ready for review @bibliotechy


A performance comparison

Would you like to provide some tcp echo server code so I can add a comparison into our project.

There are two benchmark tests:
https://github.com/jbaldwin/libcoro/blob/main/test/bench.cpp#L348 for using a thread pool to handle connections and https://github.com/jbaldwin/libcoro/blob/main/test/bench.cpp#L553 for handling requests inline in the event loop.  Is this what you are looking for?

closing since this hasn't had any movement since july


Kip 866 part 1

More detailed description of your change,
if necessary. The PR title and PR message become
the squashed commit message, so use a separate
comment to ping reviewers.
Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

This work was split up and merged in a few different commits.


Add missing row key

This should fix the warning thrown by VirtualizedTable saying that the row key is missing.
@vidyanambiar

Chatted with @fhlavac offline - he is going to investigate adding a fallback ID if data.id is not present (using a RFC UUID tool and much earlier in the table instantiation). Otherwise we could get row-undefined for some data types. :shipit:

/lgtm

/approve

Codecov Report

Merging #145 (e0a5135) into main (3826d37) will not change coverage.
The diff coverage is 0.00%.

@@           Coverage Diff           @@
##             main     #145   +/-   ##
=======================================
  Coverage   16.64%   16.64%
=======================================
  Files          41       41
  Lines        1490     1490
  Branches      407      407
=======================================
  Hits          248      248
  Misses       1242     1242

Impacted Files
Coverage Δ

...ib-utils/src/components/table/VirtualizedTable.tsx
0.00% <0.00%> (ø)

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


Update windows-in-place-upgrade.md

Set-AzsSubscription used in azurestack powershell module , this change to help the customers understand the right command to use in azure powershell module

@cynthn
IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team


Fix for issue with VRS fetching

Resolves #1 : This pull request should fix the fetching of the VRSs. In the current version, the wrong url is called: .../vscs/ID/vrs . This should be .../vscs/ID/vrss

Hi,
Thanks for the PR, but this is not the correct way to do. It will work until we release a patch, in vspk but this is a bug in auto generation.
A better approach for fixing it right now is to modify the nuvrs.py file and implement the method
    @classmethod
    def is_resource_name_fixed(cls):
        return True

This will avoid the auto pluralization of the resource name
Bambou should not have to know related to vsd and its object model.
Thanks

I was wondering if it was the right way or not, so sure :). I understand the reasoning why bambou should not know about the VSD structure.
However, your solution won't work. The problem is that vrs is not being pluralised, while it has to be pluralised. Your solution will just force it to never being pluralised, which is the opposite of what is required.

It seems like you have three options here:

Use this work around
Change https://github.com/nuagenetworks/vspk/blob/master/vsdk/v3_2/nuvrs.py  (and the v3_1, v3_0 ones) and add __rest_name__ = u"vrss"
Update/Fix auto generate (i have no idea where to do that).

you are correct, I misread the error. "vrss" didn't sound very obvious at a glance :)
There is a better way then, I'll comment in the PR in vspk repo. thanks


Qualitative analysis: what kind of lead art is it? (photo, illo, chart, video)

To make this more expedient, I thought checking the EXIF of the asset would help distinguish photos from others, and while this information does exist during asset creation, it's stripped for Seamus publishing. Boo.
Ariel tells me there is Seamus metadata associated with the asset that contains the info stripped from the EXIF. So possibly worthwhile checking (I don't have access).
Another thing we could do just to make the qualitative review easier could be checking the assets with source "* for NPR" and review those first as most illustrations will be in this group, followed by "Stock".


add users

nothing major but I've just followed along and had issues adding multiple users as per your step 7. Create a user/password in the pwfile
Could you refresh the wording that the -c creates the file but to add users you drop the -c flag?
found that solution/answer here; https://answers.launchpad.net/mosquitto/+question/226477

Thank you. I will check and update it soon.

@PrometheusWannaB3
Thanks for the tip. Updated now :)


MNIST test accuracies differ drastically with --gpu flag on and off on Apple M3

I've installed the latest mlx (mlx==0.17.0) with pip in a conda environment. After running the mnist example with and without --gpu, I find the results differ drastically (and with gpu on it is somehow slower).

I believe the test accuracy should be exactly the same.
Some of the context:

My OS Version: MacOS 14.5
MLX Version 0.17.0
My Chip: Apple M3
Complete conda info:

It's a bug in boolean all reduce that was introduced by the reduction refactoring. Submitted a PR (https://github.com/ml-explore/mlx/pull/1355), it should be merged and released in a few minutes.

It is now fixed and PyPI updated, so please run pip install -U mlx and reopen if there is any issue.


Remove renv files

Tried this but realised the gh-action refers to renv so reverted PR and updated renv.

renv is causing me some issues with contributing to this repo.  I don't routinely use renv, so am not sure how to.  I get renv errors when rendering the book locally though, so I'm struggling to contribute.  Do you have any advice @Lextuga007?

For anyone else with similar issues, renv::deactivate() allowed me to render and work locally.  The project doesn't seem to need the packages renv is trying to install.

All removed 😃


Use secrets.GITHUB_TOKEN and clean up workflows

Hi ! This will increase the rate limit on
bufbuild/buf-setup-action@ usage.
I also removed the comments which are useless now
Signed-off-by: Matthieu MOREL<EMAIL_ADDRESS>

Thanks!


Guardian authorship dataset

A new dataset: Guardian news articles for authorship attribution
tests passed:
python nlp-cli dummy_data datasets/guardian_authorship --save_infos --all_configs
RUN_SLOW=1 pytest tests/test_dataset_common.py::LocalDatasetTest::test_load_dataset_all_configs_guardian_authorship
Tests failed:
Real data: RUN_SLOW=1 pytest tests/test_dataset_common.py::LocalDatasetTest::test_load_real_dataset_guardian_authorship
output: init() missing 3 required positional arguments: 'train_folder', 'valid_folder', and 'tes...'
Remarks: This is the init function of my class. I am not sure why it passes in both my tests and with nlp-cli, but fails here. By the way, I ran this command with another 2 datasets and they failed:

_glue - OSError: Cannot find data file.
*_newsgroup - FileNotFoundError: Local file datasets/newsgroup/dummy/18828_comp.graphics/3.0.0/dummy_data.zip doesn't exist

Thank you for letting us contribute to such a huge and important library!
EDIT:
I was able to fix the dummy_data issue. This dataset has around 14 configurations. I was testing with only 2, but their versions were not in a sequence, they were V1.0.0 and V.12.0.0. It seems that the testing code generates testes for all the versions from 0 to MAX, and was testing for versions (and dummy_data.zip files) that do not exist. I fixed that by changing the versions to 1 and 2.

Hi ! Glad you managed to fix the version issue.
The command  python nlp-cli dummy_data datasets/guardian_authorship --save_infos --all_configs is supposed to generate a json file dataset_infos.json next to your dataset script, but I can't see it in the PR.
Can you make sure you have the json file on your side and that you have pushed it ?

Done!

Is there anything else that I should do? and would the new dataset be available via the NLP package now?

Sorry I forgot to merge this one ! Doing it now

Thanks for the heads up ;)

No worries, this is my first contribution to an online package, and I feel very proud it's part of this library :) Thank you very much!


Move mapref processing to beginning of preprocess

This will simply keyref processing and also enable easier implementation of DITA 1.3 branch filtering because all processing can be done on a single map.

We should check whether this PR and/or #1962 fixes these issues (at least, there may be others):

#1482
#1605
#1861


doc: Fix typo in "unix-block" description

Fix the description of the "unix-block" device type to talk about block
devices rather than character devices.

This pull request didn't trigger Jenkins as its author isn't in the whitelist.
An organization member must perform one of the following:

To have this branch tested by Jenkins, use the "ok to test" command.
To have a one time test done, use the "test this please" command.

Those commands are simple Github comments of the format: "jenkins: COMMAND"

Thanks!


Revert "Bump rack from 2.0.7 to 2.2.3 in /docs"

Reverts zooniverse/panoptes#3355
this breaks the doc builds due to Content-Length header was 10952, but should be 10964 - downgrading the gem is the only solution i could find quickly.
Looks likely related to Change MockRequest#env_for to rely on the input optionally responding to #size instead of #length
 error  build/stylesheets/screen.css
Content-Length header was 10952, but should be 10964
/usr/local/bundle/gems/rack-2.1.4/lib/rack/lint.rb:22:in `assert'
/usr/local/bundle/gems/rack-2.1.4/lib/rack/lint.rb:695:in `verify_content_length'
/usr/local/bundle/gems/rack-2.1.4/lib/rack/lint.rb:719:in `each'
/usr/local/bundle/gems/rack-2.1.4/lib/rack/response.rb:236:in `buffered_body!'
/usr/local/bundle/gems/rack-2.1.4/lib/rack/mock.rb:173:in `initialize'
/usr/local/bundle/gems/rack-2.1.4/lib/rack/mock.rb:78:in `new'
/usr/local/bundle/gems/rack-2.1.4/lib/rack/mock.rb:78:in `request'
/usr/local/bundle/gems/rack-2.1.4/lib/rack/mock.rb:59:in `get'
/usr/local/bundle/gems/middleman-core-4.2.1/lib/middleman-core/builder.rb:232:in `block in output_resource'
/usr/local/bundle/gems/activesupport-<IP_ADDRESS>/lib/active_support/notifications.rb:166:in `instrument'
/usr/local/bundle/gems/middleman-core-4.2.1/lib/middleman-core/util.rb:21:in `instrument'
/usr/local/bundle/gems/middleman-core-4.2.1/lib/middleman-core/builder.rb:225:in `output_resource'
/usr/local/bundle/gems/contracts-0.13.0/lib/contracts/method_reference.rb:43:in `send_to'
/usr/local/bundle/gems/contracts-0.13.0/lib/contracts/call_with.rb:76:in `call_with'
/usr/local/bundle/gems/contracts-0.13.0/lib/contracts/method_handler.rb:138:in `block in redefine_method'
/usr/local/bundle/gems/parallel-1.19.2/lib/parallel.rb:508:in `call_with_index'

It would be good to add a dry-run docs build to the Jenkinsfile to catch this in the future.


[polskieradio] Download skips first nine files in playlist.

DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

[X] I understand that I will be blocked if I intentionally remove or skip any mandatory* field

Checklist

[X] I'm reporting that yt-dlp is broken on a supported site
[X] I've verified that I'm running yt-dlp version 2023.10.13 (update instructions) or later (specify commit)
[X] I've checked that all provided URLs are playable in a browser with the same IP and same login details
[X] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[X] I've searched known issues and the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue
[ ] I've read about sharing account credentials and I'm willing to share it if required

Region
No response
Provide a description that is worded well enough to be understood
The download starts from the 10th file in the playlist. Skip the first 9.
Provide verbose output that clearly demonstrates the problem

[X] Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
[ ] If using API, add 'verbose': True to YoutubeDL params instead
[X] Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output
[debug] Command-line config: ['-vU', '--max-downloads', '1', 'https://trojka.polskieradio.pl/audycja/6568']
[debug] Encodings: locale cp1250, fs utf-8, pref cp1250, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version<EMAIL_ADDRESS>[b634ba742] (win_exe)
[debug] Python 3.8.10 (CPython AMD64 64bit) - Windows-10-10.0.19045-SP0 (OpenSSL 1.1.1k  25 Mar 2021)
[debug] exe versions: none
[debug] Optional libraries: Cryptodome-3.19.0, brotli-1.1.0, certifi-2023.07.22, mutagen-1.47.0, sqlite3-3.35.5, websockets-11.0.3
[debug] Proxy map: {}
[debug] Loaded 1890 extractors
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
Available version<EMAIL_ADDRESS>Current version<EMAIL_ADDRESS>Current Build Hash: 13d6a04ef6678dc61cb6e2d42eb53e69486bd2f52b8e5d778db029ccd4c600b4
yt-dlp is up to date<EMAIL_ADDRESS>[polskieradio:audition] Extracting URL: https://trojka.polskieradio.pl/audycja/6568
[polskieradio:audition] 6568: Downloading webpage
[download] Downloading playlist: AnagrammarganA
[polskieradio:audition] 6568: Downloading article list page 1
[polskieradio:audition] 6568: Downloading article list page 2
[polskieradio:audition] 6568: Downloading article list page 3
[polskieradio:audition] 6568: Downloading article list page 4
[polskieradio:audition] 6568: Downloading article list page 5
[polskieradio:audition] 6568: Downloading article list page 6
[polskieradio:audition] 6568: Downloading article list page 7
[polskieradio:audition] 6568: Downloading article list page 8
[polskieradio:audition] 6568: Downloading article list page 9
[polskieradio:audition] 6568: Downloading article list page 10
[polskieradio:audition] 6568: Downloading article list page 11
[polskieradio:audition] 6568: Downloading article list page 12
[polskieradio:audition] 6568: Downloading article list page 13
[polskieradio:audition] 6568: Downloading article list page 14
[polskieradio:audition] 6568: Downloading article list page 15
[polskieradio:audition] 6568: Downloading article list page 16
[polskieradio:audition] 6568: Downloading article list page 17
[polskieradio:audition] 6568: Downloading article list page 18
[polskieradio:audition] 6568: Downloading article list page 19
[polskieradio:audition] 6568: Downloading article list page 20
[polskieradio:audition] 6568: Downloading article list page 21
[polskieradio:audition] 6568: Downloading article list page 22
[polskieradio:audition] 6568: Downloading article list page 23
[polskieradio:audition] 6568: Downloading article list page 24
[polskieradio:audition] 6568: Downloading article list page 25
[polskieradio:audition] 6568: Downloading article list page 26
[polskieradio:audition] 6568: Downloading article list page 27
[polskieradio:audition] 6568: Downloading article list page 28
[polskieradio:audition] 6568: Downloading article list page 29
[polskieradio:audition] 6568: Downloading article list page 30
[polskieradio:audition] 6568: Downloading article list page 31
[polskieradio:audition] 6568: Downloading article list page 32
[polskieradio:audition] 6568: Downloading article list page 33
[polskieradio:audition] 6568: Downloading article list page 34
[polskieradio:audition] 6568: Downloading article list page 35
[polskieradio:audition] 6568: Downloading article list page 36
[polskieradio:audition] 6568: Downloading article list page 37
[polskieradio:audition] Playlist AnagrammarganA: Downloading 322 items of 322
[download] Downloading item 1 of 322
[PolskieRadio] Extracting URL: https://trojka.polskieradio.pl/artykul/3252342,AnagrammarganA-1-pazdziernika-godz-0006
[PolskieRadio] 3252342: Downloading webpage
[download] Downloading playlist: AnagrammarganA 1 października godz. 00:06
[PolskieRadio] Playlist AnagrammarganA 1 października godz. 00:06: Downloading 1 items of 1
[download] Downloading item 1 of 1
[debug] Formats sorted by: hasvid, ie_pref, lang, quality, res, fps, hdr:12(7), vcodec:vp9.2(10), channels, acodec, size, br, asr, proto, vext, aext, hasaud, source, id
[debug] Default format spec: best/bestvideo+bestaudio
[info] e73612ee-5031-450c-b6da-896e10578f78: Downloading 1 format(s): 0
[debug] Invoking http downloader on "https://static.prsa.pl/e73612ee-5031-450c-b6da-896e10578f78.file"
[debug] File locking is not supported. Proceeding without locking
[download] Destination: AnagrammarganA 1 października godz. 00_06 [e73612ee-5031-450c-b6da-896e10578f78].mp3
[download] 100% of  211.12MiB in 00:00:19 at 10.86MiB/s
[info] Maximum number of downloads reached, stopping due to --max-downloads
Aborting remaining downloads

The items returned by the extractor may not necessarily be in the same order as they are on the webpage. Try not passing --max-downloads 1 and seeing if the "skipped" videos are extracted later on in the playlist

Checked the proposed changes and it is now working fine !
Added a PR to fix the issue!


account details: Add error handling for unknown time zones

Fixes #3816
Before: App crashed when viewing profile of a user whose timezone was invalid ( i.e Deprecated ).
Now: App does not display the user's local time, and does not crash.

Merged (with slight emendation to include more detail about why). Thanks!

Thanks @agrawal-d and @ray-kraesig for this fix!
A small comment on this bit for future reference:

The fact that the app does crash probably doesn't deserve mention here, since it's dependent on nonlocal information

I agree the crash shouldn't be mentioned in the comment, for the reason Ray described.
OTOH the fact that this was causing a crash is a perfect tidbit to mention in the commit message.

The comments in the code are for understanding the code as it is. The fact that unrecognized timezones can exist is already a good enough reason that we should handle them correctly, regardless of what the exact consequences of getting them wrong would be.

The commit message describes the change between the old and new code. When thinking about the change, the fact that it fixes a crash is quite an interesting one! It's part of the "why" of the commit -- it's always good to know why the change matters.
We do often fix bugs even when we discovered them purely from (re)reading the code and it's probable that nobody has ever actually hit the bug, and even when something at another layer means they have no user-visible effect at all. But when reading the history to understand what changed, it's good to know which commits are like that and which are fixing a live bug, and in particular a crash.


Fix configuration load error due to prefix

Describe what this PR does / why we need it
Same here: #3562

 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.huangxiao seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Please check the failed tests:
Error:  Failures:
Error:    NacosConfigurationNewTest.contextLoads:160->checkoutDataLoad:209
expected: "dev"
 but was: "runner"
Error:    NacosConfigurationNoSuffixTest.contextLoads:187->checkEnvironmentProperties:191
expected: null
 but was: "value-no-suffix-2"
Error:    NacosConfigurationTests.contextLoads:157->checkoutDataLoad:206
expected: "dev"
 but was: "runner"
[INFO]
Error:  Tests run: 34, Failures: 3, Errors: 0, Skipped: 0

fixes https://github.com/alibaba/spring-cloud-alibaba/issues/3561

@youngledo
Please check the failed tests:
Error:  Failures:
Error:    NacosConfigurationNewTest.contextLoads:160->checkoutDataLoad:209
expected: "dev"
 but was: "runner"
Error:    NacosConfigurationNoSuffixTest.contextLoads:187->checkEnvironmentProperties:191
expected: null
 but was: "value-no-suffix-2"
Error:    NacosConfigurationTests.contextLoads:157->checkoutDataLoad:206
expected: "dev"
 but was: "runner"
[INFO]
Error:  Tests run: 34, Failures: 3, Errors: 0, Skipped: 0

It seems that this submission does not involve unit testing, so I am not sure how to fix it. Is there an example?


Change extensions to plugins

As a user of OpenSCD I want to see consistency in terminology.
We often use the word plugin as functionality we can add to OpenSCD, but if we want to add or enable a plugin it is called extensions in the side menu.

Can extensions be renamed to plugins to avoid the risk of questions about this (ie what's the difference between plugins and extensions)

Changing the name from Extensions to Plugins is fine.

Still makes sense todo to prevent confusion.

See:
https://github.com/openscd/open-scd/issues/1429

https://github.com/openscd/open-scd/issues/1429


[WIP] Implicit plugins

Description here...
Checklist (if applicable):

[ ] Tested (manually, unit tested, etc.)
[ ] Changelog updated
[ ] Docs updated

There are massive changes w.r.t. @apascal07 is working on in next branch.


wishart_rng accepts non-positive definite scale matrices

Description
In supplying a scale matrix (parameter) to wishart_rng, one can use a matrix that is not positive definite and obtain results. Is this expected behavior? It differs from a function like multi_normal_rng, which checks whether or not the supplied covariance matrix is positive definite and fails if not.
Example
The zip file contains an R file and stan file. The R file runs the stan file and illustrates the issue:
testwish.zip
Expected Output
I expected behavior similar to multi_normal_rng, which fails when a non-positive definite covariance matrix is supplied.
Current Version:
Here is my R sessionInfo():
R version 4.0.0 (2020-04-24)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.4 LTS
Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1
locale:
[1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8       LC_NAME=C
[9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base
other attached packages:
[1] rstan_2.19.3         ggplot2_3.3.0        StanHeaders_2.21.0-1
loaded via a namespace (and not attached):
[1] Rcpp_<IP_ADDRESS>       magrittr_1.5       tidyselect_1.1.0   munsell_0.5.0
[5] colorspace_1.4-1   R6_2.4.1           rlang_0.4.6        fansi_0.4.1
[9] dplyr_0.8.5        tools_4.0.0        parallel_4.0.0     pkgbuild_1.0.8
[13] grid_4.0.0         gtable_0.3.0       loo_2.2.0          cli_2.0.2
[17] withr_2.2.0        matrixStats_0.56.0 ellipsis_0.3.1     assertthat_0.2.1
[21] tibble_3.0.1       lifecycle_0.2.0    crayon_1.3.4       processx_3.4.2
[25] gridExtra_2.3      purrr_0.3.4        callr_3.4.3        vctrs_0.3.0
[29] ps_1.3.3           inline_0.3.15      glue_1.4.1         compiler_4.0.0
[33] pillar_1.4.4       prettyunits_1.1.1  scales_1.1.1       stats4_4.0.0
[37] pkgconfig_2.0.3

Thanks much for reporting with a reproducible example.  That's indeed a bug.  We should be checking for positive definiteness after its factored.  I just checked the code and see that we're not.


Adds loading indicator for processing uploads.

Added loading indicator to data processing step (on upload) and stopped the image section from printing 'Please make a selection' when new data is uploaded without refreshing first.
Closes Issue #27, though we still need to address upload size. Uploading a 3.3MB CSV is slow, but does work when hosted locally. Interactions between graphs are slow at this size as well, but this should be resolved with sever-store branch.

I like the loading circle 👍