Reduce X.509 RAM usage through parsing on demand

Overview
Context/Problem: The structure mbedtls_x509_crt used by Mbed TLS to represent X.509 CRTs is 560 byte / 312 byte long on a 64-bit / 32-bit system. Further, it contains references to dynamically allocated linked lists of instances of the 64 byte / 32 byte wide structure mbedtls_x509_name, one for each name component in the name of the CRT's issuer or subject, as well as two dynamically allocated linked lists of instances of the 32 byte / 16 byte wide structure mbedtls_x509_sequence, one for each entry in the CRT's ExtendedKeyUsage or SubjectAlternativeName extensions. Finally, it contains an mbedtls_pk_context PK context, which for ECDSA e.g. references a 344 byte / 172 byte wide mbedtls_ecp_keypair. All these structures are management overhead that comes on top of the actual raw CRT and key data. In summary: A single CRT consumes a lot of RAM -- too much for some ressource constrained devices -- and that's mainly because of the way Mbed TLS stores CRTs, as opposed to the size of the raw CRT itself.
Goal: Reduce RAM usage of the X.509 module by shortening/removing structures involved in representing X.509 CRTs in Mbed TLS, and/or by allocating them only when needed.
Summary: This PR provides a new compile-time option MBEDTLS_X509_ON_DEMAND_PARSING, disabled by default, which reduces the permanent RAM usage of an X.509 CRT outside of the raw data down to 40 bytes on a 32-bit system by essentially only storing pointers to the raw data, and allocating and potentially caching the PK context and/or a compact structured presentation of the CRT of size ~160 Bytes when needed. It also adds a compile-time option MBEDTLS_X509_ALWAYS_FLUSH, enabled by default and available and meaningful regardless of the state of MBEDTLS_X509_ON_DEMAND_PARSING, which controls whether X.509 CRT caches should be flushed whenever a CRT is not in use (details: the PR introduces the use of CRT caches regardless of the state of MBEDTLS_X509_ON_DEMAND_PARSING, but only changes mbedtls_x509_crt in case the new option is set; to keep the permanent RAM overhead small in this case, and because setting up the CRT cache from the legacy mbedtls_x509_crt is fast, MBEDTLS_X509_ALWAYS_FLUSH is enabled by default in this case).
API/ABI breaks: The PR unconditionally modifies the ABI, and it unconditionally modifies functions with external linkage from x509.c, which however are documented as internal and therefore not considered as part of the public API. Enabling the new MBEDTLS_X509_ON_DEMAND_PARSING option breaks the structure API by removing most fields from mbedtls_x509_crt, but it keeps the existing public function API. Regardless of whether MBEDTLS_X509_ON_DEMAND_PARSING is set or not, the X.509 API is extended by multiple convenience getter functions (unused outside of debugging and test code in the library) that help users remove direct field accesses.
Dependencies: The PR is based on both #2421 and (merged) #2443.
Design
Goals
The following design goals are considered, in order of priority:

Memory usage: The primary goal of the PR is to reduce RAM usage of the X.509 module.
Code-size: While the primary goal of this optimization is RAM usage, the introduction of   MBEDTLS_X509_ON_DEMAND_PARSING should not lead to significant code-size increase, because the latter is a limited resource, too. The code-size of the library with MBEDTLS_X509_ON_DEMAND_PARSING disabled (default) may increase to a larger extend.
Code-sharing: For ease of maintenance, most code should be the same regardless of whether
MBEDTLS_X509_ON_DEMAND_PARSING is enabled or disabled.
Ease of adaptation: While changing mbedtls_x509_crt necessarily breaks the API, it should be straightforward for users to adapt their code.
Efficiency: Some CRTs are heavily used, foremost the trusted CAs, whose structure fields and PK context are needed for every connection. Ideally, those CRTs should not be re-parsed on every usage, but kept ready for use.
Concurrency: The trusted CRTs and the user's own CRT are part of the SSL configuration which may be concurrently accessed by multiple SSL contexts. If X.509 are setup/destroyed on-demand, care needs to be taken to not introduce race conditions resulting in dangling pointers or memory leaks.

Approaches for structure compactification
The following approaches aim at reducing the size of a full structured presentation of an X.509 CRT. They are all independent, and each of them is applied to some extend in this PR; details to follow:

No dynamic memory: As mentioned above, each mbedtls_x509_crt currently references four dynamically allocated linked lists to store the issuer and subject names, as well as the ExtendedKeyUsage and SubjectAlternativeNames extensions. The PR suggests to remove these lists altogether and to instead traverse the raw ASN.1 data whenever needed.
Remove unnecessary data: Adapt the structured presentation to what the library needs internally and what users might sensibly want to look at - remove everything else. For example, currently mbedtls_x509_crt contains 10 instances of mbedtls_x509_buf, which typedefs to mbedtls_asn1_buf, which in turn is a triple of an ASN.1 tag, data pointer and length. The tag value is stored as an int, hence tag values usually account for 40 bytes of data in mbedtls_x509_crt. Apart from the serial number (for which we accept an IMPLICIT tagging as well as an INTEGER tag, for reasons I don't know), all tags are fixed and need not be stored; and even where there's flexibility, I can't think of a reason why a user would want to know the exact tag. The PR suggests not to store ASN.1 tags at all in the structured presentation of a CRT.
Use smaller fields: Don't use fields that are wider than necessary to represent the set of possible values. For example, the current mbedtls_x509_crt stores the version and CA-bit as an int each. Similarly, one can consider storing buffer lengths by types narrower than size_t, such as uint16_t, if the limitation of not supporting CRTs beyond 64K seems acceptable; currently, however, the PR doesn't do this.
Consider structure layout: Order fields in a way that avoids padding. Also, while not changing the size of the structure, order fields from small to big to allow single-instruction access on Thumb2 -- this turns out to make a massive code-size difference compared to small fields being scattered throughout the structure, even if padding is avoided.

Approaches for on-demand parsing
The following is a list of potential approaches to implement on-demand allocation of structured CRT presentations and evaluates them in light of the above design constraints.

Function-based field access: Introduce an internal function abstraction layer by not accessing structure fields of mbedtls_x509_crt directly, but only through getter functions. If on-demand parsing is disabled, these functions may be simply implemented as field access. If it is enabled, they may perform necessary parsing and perhaps caching, and return the extracted value.
Let's consider this in light of the above constraints: For code-sharing, the approach is good because functions building on the internal abstraction layer don't need any change when switching the underlying implementation. It's also good for ease of adaptation, because users just need to go through their code and replace every field access by the corresponding function access. Also for concurrency and efficiency it's fine, because necessary locking and caching can be handled within the getter functions. However, I consider this approach unsuitable because I expect it to lead to code which is both larger (in assembly) and harder to read. This is because every getter function might fail: The parsing might fail, or a necessary allocation might fail with an out-of-memory error, or similar. Consequently, what was a simple field access becomes a call which needs to be checked for its return value, and the return value handled accordingly.

Direct field access after explicit parsing calls: Provide a pointer to an optional 'parsed' structure structure giving access to a structured presentation of the CRT, and access its members directly after making sure the pointer is valid by issuing a respective parsing call beforehand. So, reading crt->field turns into reading crt->parsed->field after calling a parse() function to ensure that crt->parsed is valid.
Consider again the constraints, beginning with code-sharing: If the parsed structure shares the necessary fields with the legacy CRT structure, one could switch between directly accessing the legacy crt and the new crt->parsed structure, established on demand, through a compile-time switch. In the extreme case, the legacy CRT structure equals the parsed structure, so the legacy mbedtls_x509_crt_legacy would replaced by something like struct { data_t raw; mbedtls_x509_crt_legacy *parsed; }; - what was the legacy structure becomes the parsed
structure established on demand. This extreme-case would already be useful in its own right, but it wouldn't align well with non-trivial optimizations to the parsed CRT structure such as those mentioned above. Apart from that, the approach is fine for code-size, ease of adaptation (internally and for users), and efficiency, but some thought needs to go into concurrency: If the parsed structure is established and cached on-demand, and assume there's some means of freeing the cache, what's the lifetime of the parsed structure in a multithreaded context? One thread might establish the parsed structure in preparation for some field accesses (e.g. for CRT verification) at the same time as another thread decides to flush the parsing cache; in that case, the first thread might access a dangling pointer. To make this work, every access to the parsing structure must happen in some kind of acquire-release block. That's acceptable, but the main issue of incompatibility with structure optimizations remains.

Direct field access to structure returned from parsing calls: Provide a function to acquire a 'parsed' structure and access the latter through direction field access afterwards.
As in the first (entirely function-based) approach, this allows code-sharing by rewriting code to only use fields from the parsed structure. The code-size overhead in this approach stems from the following: (a) In legacy mode, the parsed structure needs to be made available from the legacy structure, which requires some copying code. (b) Every request for the parsed structure might fail. Care needs to be taken to minimize the number of requests, but keeping field access to CRTs concentrated in a few places. The main drawback of this approach is memory usage in legacy mode: A parsed structure needs to be setup from a legacy structure, which means that either the parsed structure gets permanently added to the legacy structure, or it is allocated on demand with every 'acquire' call.

Choice
The PR implements all options for structure compactification mentioned above (in some form), and chooses variant 3 (Direct field access to structure returned from parsing calls) to implement on-demand parsing.
Unconditional API extensions: The following are the concrete extensions to the API from the user's perspective. They are all unconditional, i.e. independent of whether MBEDTLS_X509_ON_DEMAND_PARSING is enabled or not.

CRT inspection is done through the following CRT 'frame' structure:

typedef struct mbedtls_x509_crt_frame
{
    /* Keep these 8-bit fields at the front of the structure to allow them to
     * be fetched in a single instruction on Thumb2; putting them at the back
     * requires an intermediate address calculation. */

    uint8_t version;                        /**< The X.509 version. (1=v1, 2=v2, 3=v3)                          */
    unsigned char ca_istrue;                /**< Optional Basic Constraint extension value:
                                             *   1 if this certificate belongs to a CA, 0 otherwise.            */
    unsigned char max_pathlen;              /**< Optional Basic Constraint extension value:
                                             *   The maximum path length to the root certificate.
                                             *   Path length is 1 higher than RFC 5280 'meaning', so 1+         */
    unsigned char ns_cert_type;             /**< Optional Netscape certificate type extension value:
                                             *   See the values in x509.h                                       */

    unsigned int key_usage;                 /**< Optional key usage extension value: See the values in x509.h   */
    uint32_t ext_types;                     /**< Bitfield indicating which extensions are present.
                                             *   See the values in x509.h.                                      */

    mbedtls_md_type_t sig_md;               /**< The hash algorithm used to hash CRT before signing.            */
    mbedtls_pk_type_t sig_pk;               /**< The signature algorithm used to sign the CRT hash.             */

    mbedtls_x509_time valid_from;           /**< The start time of certificate validity.                        */
    mbedtls_x509_time valid_to;             /**< The end time of certificate validity.                          */

    mbedtls_x509_buf_raw raw;               /**< The raw certificate data in DER.                               */
    mbedtls_x509_buf_raw tbs;               /**< The part of the CRT that is [T]o [B]e [S]igned.                */

    mbedtls_x509_buf_raw serial;            /**< The unique ID for certificate issued by a specific CA.         */

    mbedtls_x509_buf_raw pubkey_raw;        /**< The raw public key data (DER).                                 */

    mbedtls_x509_buf_raw issuer_id;         /**< Optional X.509 v2/v3 issuer unique identifier.                 */
    mbedtls_x509_buf_raw issuer_raw;        /**< The raw issuer data (DER). Used for quick comparison.          */

    mbedtls_x509_buf_raw subject_id;        /**< Optional X.509 v2/v3 subject unique identifier.                */
    mbedtls_x509_buf_raw subject_raw;       /**< The raw subject data (DER). Used for quick comparison.         */

    mbedtls_x509_buf_raw sig;               /**< Signature: hash of the tbs part signed with the private key.   */
    mbedtls_x509_buf_raw sig_alg;

    mbedtls_x509_buf_raw v3_ext;            /**< The raw data for the extension list in the certificate.
                                             *   Might be useful for manual inspection of extensions that
                                             *   Mbed TLS doesn't yet support.                                  */
    mbedtls_x509_buf_raw subject_alt_raw;   /**< The raw data for the SubjectAlternativeNames extension.        */
    mbedtls_x509_buf_raw ext_key_usage_raw; /**< The raw data for the ExtendedKeyUsage extension.               */

} mbedtls_x509_crt_frame;

Note: This is the goal, but the current state of the PR still uses a few more fields which however are expected to go away soon.
This structure contains parsed values of primitive CRT fields such as the version, and pointers to raw data otherwise. In particular, it does not contain any references to dynamically allocated memory.
The new structure mbedtls_x509_buf_raw is a sibling of the existing of mbedtls_x509_buf which however omits the ASN.1 tag (see Remove unnecessary data above):
typedef struct mbedtls_x509_buf_raw
{
    unsigned char *p;
    size_t len;
} mbedtls_x509_buf_raw;

Note: I am considering to replace size_t len; by unsigned char *end; here, in the expectation that it will lead to significantly smaller code; all ASN.1 parsing functions take start / end pointer pairs instead of length values, and lots of arithmetic would hopefully go away using the end pointer instead of len.
Users can query for the CRT frame through the following new public API:
/**
 * \brief           Request CRT frame giving access to basic CRT fields
 *                  and raw ASN.1 data of complex fields.
 *
 * \param crt       The CRT to use. This must be initialized and setup.
 * \param dst       The address of the destination frame structure.
 *                  This need not be initialized.
 *
 * \note            mbedtls_x509_crt_frame does not contain dynamic
 *                  references and hence need not be freed. Users may
 *                  e.g. allocate an instance of mbedtls_x509_crt_frame
 *                  on the stack and call this function on it, in which
 *                  case no allocation/freeing has to be done.
 *
 * \return          \c 0 on success. In this case, \p dst is updated
 *                  to hold the frame for the given CRT.
 * \return          A negative error code on failure.
 */
int mbedtls_x509_crt_get_frame( mbedtls_x509_crt const *crt,
                                mbedtls_x509_crt_frame *dst );

Access to the public key within a CRT is done through the following new public API (fixing also #2294):
/**
 * \brief           Request a PK context for the public key within a CRT.
 *
 * \param crt       The CRT to use. This must be initialized and setup.
 * \param dst       The address of the destination PK context to fill.
 *                  This must be initialized via mbedtls_pk_init().
 *
 * \return          \c 0 on success. In this case, the user takes ownership
 *                  of the destination PK context, and is responsible for
 *                  calling mbedtls_pk_free() on it once it's no longer needed.
 * \return          A negative error code on failure.
 */
int mbedtls_x509_crt_get_pk( mbedtls_x509_crt const *crt,
                             mbedtls_pk_context *pk );

When users need to inspect the raw ASN.1 data (the issuer or subject, or one of the recognized extensions, or an unrecognized extension), they may either (a) use the ASN.1 parsing API for that, or (b) use one of the following newly introduced API functions which replace direct access to the structure fields issuer, subject, ext_key_usage, subject_alt_names that are present in the legacy mbedtls_x509_crt, but no longer in mbedtls_x509_crt_frame:
/**
 * \brief           Request the subject name of a CRT, presented
 *                  as a dynamically allocated linked list.
 *
 * \param crt       The CRT to use. This must be initialized and setup.
 * \param dst       The address at which to store the address of the
 *                  first entry of the generated linked list holding
 *                  the subject name.
 *
 * \note            Depending in your use case, consider using the raw ASN.1
 *                  describing the subject name instead of the heap-allocated
 *                  linked list generated by this call. The pointers to the
 *                  raw ASN.1 data are part of the CRT frame that can be queried
 *                  via mbedtls_x509_crt_get_frame().
 *
 * \return          \c 0 on success. In this case, the user takes ownership
 *                  of the name context, and is responsible for freeing it
 *                  through a call to mbedtls_x509_name_free() once it's no
 *                  longer needed.
 * \return          A negative error code on failure.
 */
int mbedtls_x509_crt_get_subject( mbedtls_x509_crt const *crt,
                                  mbedtls_x509_name **subject );

/**
 * \brief           Request the subject name of a CRT, presented
 *                  as a dynamically allocated linked list.
 *
 * \param crt       The CRT to use. This must be initialized and setup.
 * \param dst       The address at which to store the address of the
 *                  first entry of the generated linked list holding
 *                  the subject name.
 *
 * \note            Depending in your use case, consider using the raw ASN.1
 *                  describing the subject name instead of the heap-allocated
 *                  linked list generated by this call. The pointers to the
 *                  raw ASN.1 data are part of the CRT frame that can be queried
 *                  via mbedtls_x509_crt_get_frame().
 *
 * \return          \c 0 on success. In this case, the user takes ownership
 *                  of the name context, and is responsible for freeing it
 *                  through a call to mbedtls_x509_name_free() once it's no
 *                  longer needed.
 * \return          A negative error code on failure.
 */
int mbedtls_x509_crt_get_issuer( mbedtls_x509_crt const *crt,
                                 mbedtls_x509_name **issuer );

/**
 * \brief           Request the subject alternative name of a CRT, presented
 *                  as a dynamically allocated linked list.
 *
 * \param crt       The CRT to use. This must be initialized and setup.
 * \param dst       The address at which to store the address of the
 *                  first component of the subject alternative names list.
 *
 * \note            Depending in your use case, consider using the raw ASN.1
 *                  describing the subject alternative names extension
 *                  instead of the heap-allocated linked list generated by this
 *                  call. The pointers to the raw ASN.1 data are part of the CRT
 *                  frame that can be queried via mbedtls_x509_crt_get_frame().
 *
 * \return          \c 0 on success. In this case, the user takes ownership
 *                  of the name context, and is responsible for freeing it
 *                  through a call to mbedtls_x509_sequence_free() once it's
 *                  no longer needed.
 * \return          A negative error code on failure.
 */
int mbedtls_x509_crt_get_subject_alt_names( mbedtls_x509_crt const *crt,
                                            mbedtls_x509_sequence **subj_alt );

/**
 * \brief           Request the ExtendedKeyUsage extension of a CRT,
 *                  presented as a dynamically allocated linked list.
 *
 * \param crt       The CRT to use. This must be initialized and setup.
 * \param dst       The address at which to store the address of the
 *                  first entry of the ExtendedKeyUsage extension.
 *
 * \note            Depending in your use case, consider using the raw ASN.1
 *                  describing the extended key usage extension instead of
 *                  the heap-allocated linked list generated by this call.
 *                  The pointers to the raw ASN.1 data are part of the CRT
 *                  frame that can be queried via mbedtls_x509_crt_get_frame().
 *
 * \return          \c 0 on success. In this case, the user takes ownership
 *                  of the name context, and is responsible for freeing it
 *                  through a call to mbedtls_x509_sequence_free() once it's
 *                  no longer needed.
 * \return          A negative error code on failure.
 */
int mbedtls_x509_crt_get_ext_key_usage( mbedtls_x509_crt const *crt,
                                        mbedtls_x509_sequence **ext_key_usage );

These functions are meant to provide convenience but introduce a memory overhead: Every time the user queries the CRT frame or PK context, a new frame / PK context will be setup. Similarly, querying the dynamic linked list presentations for issuer/subject/extended key usage/subject alternative names introduces a memory overhead. For these reasons, the library itself does not use them at all outside of debugging and test routines (such as mbedtls_x509_crt_info() or the X.509 test suites), and users are discouraged from doing so in case they want to safe memory.
Instead, there is the following more efficient, but slightly more complex-to-use API for querying CRT frames and PK contexts:
int mbedtls_x509_crt_frame_acquire( mbedtls_x509_crt const *crt,
                                            mbedtls_x509_crt_frame **frame_ptr );

void mbedtls_x509_crt_frame_release(
    mbedtls_x509_crt const *crt,
    mbedtls_x509_crt_frame *frame );

int mbedtls_x509_crt_pk_acquire( mbedtls_x509_crt const *crt,
                                               mbedtls_pk_context **pk_ptr );

void mbedtls_x509_crt_pk_release( mbedtls_x509_crt const *crt,
                                                mbedtls_pk_context *pk );

The acquire functions are very similar to the get functions above, but with the essential difference that the user does not own the frame / PK context they return. Moreover, the latter is only valid until the corresponding release function is called. While not strictly required, implementations of these functions should not re-compute frame / PK context every time they are called, but provide some means of 'caching' the results so that they can be quickly returned to the user in case of multiple successive invocations. However, on a very memory-contrained system, one might want to flush the caches with every release call. To flush the internal cache of a CRT (if present), the following API is introduced:
void mbedtls_x509_crt_flush_cache( mbedtls_x509_crt const *crt );

Note: On a single-threaded system, release may be a no-op (and be declared static inline to avoid overhead), but on a multithreaded system, the acquire/release pairs have to take care of necessary locking to ensure that on-demand establishing of CRT frame / PK context as well as flushing them does not lead to race conditions.
Conditional API changes: When MBEDTLS_X509_ON_DEMAND_PARSING is enabled, the legacy mbedtls_x509_crt is replaced by the following structure:
typedef struct mbedtls_x509_crt
{
    int own_buffer;                     /**< Indicates if \c raw is owned
                                         *   by the structure or not.        */
    mbedtls_x509_buf raw;               /**< The raw certificate data (DER). */
    mbedtls_x509_crt_cache *cache;     /**< Internal parsing cache. */

    struct mbedtls_x509_crt *next;     /**< Next certificate in the CA-chain. */
} mbedtls_x509_crt;

(The referenced mbedtls_x509_crt_cache is defined in x509_crt.h but not part of the public API, and should not be used directly by users. It's current definition is hence detailed below.)
Implementation details
We first describe the implementation, and afterwards discuss it's pros and cons.
Parsing: The core CRT parsing routine x509_crt_parse_der_core() has been rewritten on top of a new parsing routine x509_crt_parse_frame() which sets up a CRT frame from raw CRT data. Once the frame is established, most of it's fields get copied to the legacy mbedtls_x509_crt. What remains are the four dynamic linked lists for subject, issuer, subject alt names and ext key usage, as well as the PK context. The PK context is setup from the frame's pk_raw field, and the four dynamic linked lists are setup through adaptations of the existing parsing routines.
CRT and Cache structure: The legacy mbedtls_x509_crt is extended in the following way:
/**
 * Container for an X.509 certificate. The certificate may be chained.
 */
typedef struct mbedtls_x509_crt
{
    int own_buffer;                     /**< Indicates if \c raw is owned
                                         *   by the structure or not.         */
    mbedtls_x509_buf raw;               /**< The raw certificate data (DER).  */
    mbedtls_x509_crt_cache *cache;      /**< Internal parsing cache.          */

    struct mbedtls_x509_crt *next;     /**< Next certificate in the CA-chain. */

#if !defined(MBEDTLS_X509_ON_DEMAND_PARSING)
   /* LEGACY FIELDS */
#endif /* !MBEDTLS_X509_ON_DEMAND_PARSING */
}
mbedtls_x509_crt;

typedef struct mbedtls_x509_crt_cache
{
#if defined(MBEDTLS_THREADING_C)
    mbedtls_threading_mutex_t frame_mutex;
    mbedtls_threading_mutex_t pk_mutex;
#endif
    mbedtls_x509_buf_raw pk_raw;
    mbedtls_x509_crt_frame *frame;
    mbedtls_pk_context *pk;
} mbedtls_x509_crt_cache;

Note that the new mbedtls_x509_crt is API compatible with the old one; it was only extended by a cache pointer.
The cache is once and for all allocated at CRT setup time; logically, it can hence be considered as embedded in mbedtls_x509_crt. However, it cannot actually be embedded in it because it requires modification in reading routines that are logically const on the input CRT (such as mbedtls_x509_crt_check_extended_key_usage()). The latter is the only reason why mbedtls_x509_crt_cache isn't embedded in mbedtls_x509_crt.
Cache implementation:

In 'legacy mode' (i.e. when MBEDTLS_X509_ON_DEMAND_PARSING) is disabled, acquireing the CRT frame allocates a new mbedtls_x509_crt_frame from the heap and sets it up by copying the respective fields from the legacy mbedtls_x509_crt. When acquireing the PK context, a mbedtls_pk_context is allocated on the heap but shallow-copied from the PK context embedded in the legacy mbedtls_x509_crt.
If MBEDTLS_X509_ON_DEMAND_PARSING is enabled, acquireing the CRT frame allocates a new mbedtls_x509_crt_frame and sets it up through x509_crt_parse_frame(). acquireing the PK context allocates a new mbedtls_pk_context and parsed the contents remembered in pk_raw. Note: The pk_raw buffer is present both in mbedtls_x509_crt_cache and in mbedtls_x509_crt_frame, but it comes at the benefit of being able to query for the PK context without having a CRT frame in memory at the same time. The pk_raw field in mbedtls_x509_crt_cache is set during initial parsing time of the CRT, where frame and PK are built to check structural sanity of the input data.

Efficiency considerations:

The main drawback of the present implementation is that, in legacy mode, we have a RAM overhead of the size of mbedtls_x590_crt_frame whenever a CRT is accessed. I don't like that, but I still consider it to be the best among the options described and evaluated above.
There is code-size overhead for every invocation of the acquire API, which is unavoidable to some extend if we don't know whether the part of the CRT we want to access is already cached or not. The current halfway static inline implementation of mbedtls_x509_crt_acquire_{frame|pk}() performs the != NULL check in the inline part, the original reason for which was to allow compilers to optimize the code away in case they can argue that the cache is setup. Specifically, the hope would be that multiple directly consecutive acquire/release pairs would be collapsed to a single one by the compiler, but I haven't yet tried that. In any case, it should be measured what impact this halfway inline implementation of mbedtls_x509_crt_acquire_{frame|pk}() has on the code-size. The most robust way of reducing the code-size is to localize the uses of CRTs, that is, have as few blocks as possible where CRT fields are accessed. The PR reorders some code to make improvements in this direction, but it is still not optimal: For example, at the beginning of the CRT chain verification, we check whether the peer CRT's subject name matches the ServerName settings, and in the first iteration of the chain verification loop, we consider its validity and subject name again; these two directly consecutive code-paths (which, however, are handled in different [static] functions) could be unified to acquire/release the frame for the peer's CRT only once.

Todo

[x] Add ChangeLog entry
[x] Add tests to all.sh
[x] Rebase on top of development.
[x] Study and fix CI failures.
[x] Consider replacing the len field by an end pointer in mbedtls_x509_buf_raw; this should be done in this PR because changing it later would be an API change even in the default configuration.
[ ] Run all.sh locally with MBEDTLS_X509_ON_DEMAND_PARSING enabled throughout.
[x] Improve cache implementation in legacy mode by setting up mbedtls_x509_crt_frame from mbedtls_x509_crt by copying, not re-parsing.
[x] Implement caching strategies; there should be a sensible default caching strategy (e.g., flushing the peer's CRT frame after a parent has been found in the verification process, but not flushing trusted CA CRTs [?]), a no-flush strategy which never flushes by default, or an always-flush strategy which flushes the cache with every invocation of release.
[x] Document that MBEDTLS_X509_ON_DEMAND_PARSING doesn't promise a stable API (yet).
[x] Avoid having both issuer_raw and issuer_raw_no_hdr in mbedtls_x509_crt; initially, I preferred issuer_raw_no_hdr, which omits the ASN.1 SEQUENCE header for the name, but actually the raw ASN.1 subject name data of the trusted CAs, including the headers, is needed in the server's CertificateRequest message.

Enabling the new MBEDTLS_X509_ON_DEMAND_PARSING option [...] adds to the public X.509 API multiple convenience getter functions (unused outside of debugging and test code in the library) that help users remove direct field accesses.

Why not make those getters accessible unconditionally? It would help people migrate their code away from direct field access, which is a good think independently from on-demand parsing (eg for when we make the structs opaque).

Note: github says this has a conflict with development in library/x509_crt.c.

@mpg Sorry, the wording is misleading; the getter functions are unconditional, and it is exactly encouraged to use them to gradually convert user-code to a state where it applies to MBEDTLS_X509_ON_DEMAND_PARSING. See the Unconditional API extensions section below.

Ok, great, thanks!

CI failures for MBEDTLS_SSL_ASYNC_PRIVATE; I am looking at it.

@mpg I wonder if we should rename the option to something generic as MBEDTLS_X509_OPTIMIZED or similar, because this would more accurately reflect my intention of using this option to also implement future, potentially again API-breaking optimizations on X.509 -- for example, similar improvements CRLs and CSRs as those made to CRTs.

I am waiting for @mpg's feedback before doing further work on this PR. While, to the best of my knowledge and intentions, the PR could go in as-is - especially considering that the new API is marked unstable - there one thing I am not yet fully happy with:
Code-size overhead from acquire/release pairs. With parsing on-demand, it is unavoidable that we have some code-size stemming from checking whether the CRT cache is populated or not. However, the number of invocations of acquire/release can potentially be minimized by restructuring code in a way that CRTs are inspected in as few places as possible. Currently, especially the CRT verification code is not optimal in that regard: For example, the top-level function mbedtls_x509_crt_verify_restartable() inspects the child's CRT frame, and so does the first iteration of x509_crt_verify_chain(). Also, when searching for a parent, the parent's PK is acquired and released both in x509_crt_find_parent_in() (to check the signature) as well as in x509_crt_verify_chain() (to check whether the PK type matches the profile). It would reduce code-size -- and likely also improve code-clarity -- if we could restructure the chain verification code to use each CRTs frame and PK exactly once.

This looks great. Kudos for detailed background design work documentation and user manuals.
I did some experiments, please see numbers below:
Original heap (current + peak) usage of MCC after bootstrap & registration, mbed-os-5.12:
**** current_size: 19452
**** max_size    : 24831

With this PR and just MBEDTLS_X509_ON_DEMAND_PARSING enabled:
**** current_size: 16498
**** max_size    : 22997

With this PR, MBEDTLS_X509_ON_DEMAND_PARSING enabled and client calls to mbedtls_x509_crt_parse() replaced with mbedtls_x509_crt_parse_der_nocopy():
**** current_size: 15333
**** max_size    : 21832

So in practice with minimal changes in client side the standby heap usage was reduced by 4KB, and peak usage by 3KB.

@TeroJaasko Thank you for your input!
As you can see from this post, you can also undefine MBEDTLS_SSL_KEEP_PEER_CERTIFICATE which should also save you some RAM ( unless your replacements to mbedtls_x509_crt_parse_der_nocopy() include inside the library as well )

At the moment, I have one comment on the HLD:
int mbedtls_x509_crt_get_subject_alt_names( mbedtls_x509_crt const *crt,
                                            mbedtls_x509_sequence **subj_alt );

Subject Alternative Names are defined as following:
   id-ce-subjectAltName OBJECT IDENTIFIER ::=  { id-ce 17 }

   SubjectAltName ::= GeneralNames

   GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

   GeneralName ::= CHOICE {
        otherName                       [0]     OtherName,
        rfc822Name                      [1]     IA5String,
        dNSName                         [2]     IA5String,
        x400Address                     [3]     ORAddress,
        directoryName                   [4]     Name,
        ediPartyName                    [5]     EDIPartyName,
        uniformResourceIdentifier       [6]     IA5String,
        iPAddress                       [7]     OCTET STRING,
        registeredID                    [8]     OBJECT IDENTIFIER }

   OtherName ::= SEQUENCE {
        type-id    OBJECT IDENTIFIER,
        value      [0] EXPLICIT ANY DEFINED BY type-id }

   EDIPartyName ::= SEQUENCE {
        nameAssigner            [0]     DirectoryString OPTIONAL,
        partyName               [1]     DirectoryString }

And mbedtls_x509_sequence is defined as mbedtls_asn1_sequence which is defined as
typedef struct mbedtls_asn1_sequence
{
    mbedtls_asn1_buf buf;                   /**< Buffer containing the given ASN.1 item. */
    struct mbedtls_asn1_sequence *next;    /**< The next entry in the sequence. */
}
mbedtls_asn1_sequence;

mbedtls_asn1_buf, as a triplet of tag len and raw data. This fits some of the simple Subject Alternative Names, which only have an OCTET STRING or IA5String, such as dNSName and iPAdress, but it doesn't fit a bit more enhanced types, such as EDIPartyName or otherName. At the moment we only support dNSName, but once we decide to enhance support for other Alternative Names, we will probably need some API change. I prefer to avoid that, if possible.
I think that if we are already changing \ adding API, we should consider introducing a new type for subject alternative name:
typedef struct mbedtls_x509_subject_alternative_name
{
   union{
        mbedtls_asn1_buf buf;                   /**< Buffer containing the given ASN.1 item. */
        mbedtls_asn1_sequence san;        /**< Sequence containing the SAN. */
    }
    struct mbedtls_x509_subject_alternative_name *next;    /**< The next entry in the sequence. */
}
mbedtls_x509_subject_alternative_name;

Note that #2530 already adds support for another Alternative Name.

@RonEld Thanks for your comment! Two points:

A general point on design philosophy: mbedtls_x509_crt_get_subject_alt_names() is not meant to be used anymore, at least in memory constrained contexts. Calling it deprecated would perhaps go a bit far, but the new design definitely supports working on the raw data over building these RAM-heavy linked lists. In particular, Mbed TLS itself does not use mbedtls_x509_crt_get_subject_alt_names(), so link time optimization will remove it if the user doesn't need it.

Now, given that we (or at least I) don't intend to put effort into extending this legacy API, I could live with keeping mbedtls_x509_crt_get_subject_alt_names() as-is, and documenting that it just returns dNSName entries, and cannot be used for other types. For other types, the user must manually use mbedtls_asn1_traverse_sequence_of() as done in the implementation https://github.com/ARMmbed/mbedtls/blob/19b3c76444deb5e27bb2c8f275b53e3dc40eb618/library/x509_crt.c#L874-L885 of mbedtls_x509_crt_get_subject_alt_names().
That would be acceptable in theory, provided your PR isn't merged first.

@hanno-arm Thanks for your clarifications, I probably misread.
I assume your point 2 is only an example

@RonEld I rebased this on top of development, including your recent X.509 PRs. Waiting for CI now.

@RonEld Thanks again for your review!
In regards to your suggestion to have a type mbedtls_x509_subject_alternative_name, I think this is trade-off between convenience for the user and code-size. Currently, I am strongly inclined to keep the code simple by having get_subject_alt_name() return an ASN.1 sequence as before, and have the user check the tag and handle it appropriately. If we do that, I'd suggest we don't do any filtering of name types, but simply return the entire list of names (as opposed to only returning the list of dNSName [and later hardwareModuleName] entries).

@RonEld Thank you very much for your review! I have replied to your comments, indicating those where I'll follow up with a change.

@Patater Thanks for your first bunch of review comments! I believe I have replied to all of them and indicated if and where they lead to a change in the PR.

@RonEld FYI have pushed commits addressing your comments; I indicated those comments where I don't intend to make a change for now (but discussions may of course go on).

@hanno-arm Thanks for addressing my comments!
I still think that the new public API regarding SAN should be changed to support future types of SAN, even if they are not supported yet.  I am not saying we need to add support for them here, only that we shouldn't add something that we know is not correct.
However, public API, once introduced, is less likely to change, so I would really like it to be as much future compatible as possible

@RonEld I have replied to your comments and concerns about the API - please let me know your thoughts, so we can continue progressing this in a direction which suits both the main goals of this PR and the subsequent introduction for support of more complex SAN types.
Also, are you going to prepare a rebase of #2530 on top of this PR?

@hanno-arm
My only concern is that we should add support for future complex SAN types, in the public API. This means the public API should fill a structure other than mbedtls_x509_sequence

Also, are you going to prepare a rebase of #2530 on top of this PR?

Yes, I am rebasing, and will create a new PR. I would like to continue reviewing #2530, in case this PR doesn't make it on time, as it's big.

@Patater Do you have time to progress your review?

@andresag01 Thank you very much for your first chunk of review comments - thorough as usual! I believe to have replied to and addressed most of them - could you please have a look?

I rebased this PR on top of development to resolve CI failures stemming from the known problem that the Mbed Crypto submodule used to build non-crypto files using Mbed TLS' headers, and hence changes in non-crypto headers could break the submodule build. With the removal of the non-crypto files from Mbed Crypto, this is no longer an issue - as long as the crypto submodule commit is recent enough, which is what the rebase ensures.

@andresag01 Thanks for your feedback, I believe to have addressed it. Please re-review.

I performed a zero-diff force-push, doing some cleanup of the history to ease any furhter review.

I have rebased this PR on top of development. The ASN.1 related changes have been moved to Mbed Crypto as https://github.com/ARMmbed/mbed-crypto/pull/263.

@Patater Please add this PR into your review queue. It took very long to do this rebase and adapt the original work on top of @RonEld's changes, and I'd appreciate if we could avoid this happening again.


Ghidra fails to decompile after renaming a type

Describe the bug
When renaming an (auto generated) type of a parameter, the decompiler of Ghidra seems not to be aware of the refactoring that took place. Instead, it produces a low level error stating it cannot resolve the type with the original name anymore.
To Reproduce

Open a subroutine with at least one parameter.
Right click on the parameter and click "Auto Create Structure"
Right click again on the parameter and click "Edit Data Type"
In the window that pops up, change the name of the data type and press "Apply editor changes".
Observe how the decompiler now fails to decompile the subroutine.

Expected behavior
Expected behaviour is that Ghidra refactors the code properly and uses the new name in the decompiled source code.
Screenshots
Step 3:

Step 4:

Step 5:

GIFv of the entire process:
https://i.imgur.com/s8h6ZWC.gifv
Environment (please complete the following information):

OS: Windows 10
Java Version: 11.0.2
Ghidra Version: 9.0.2

EDIT:
** Additional information **
It seems this does not always happen, but it fails usually on the "this" parameter of a __thiscall subroutine.

You should to change class name (Symbol Tree → Classes) also or to edit prototype of function (should check Use Custom Storage for changing datatype of this parameter).


Change "List Repos" to also give repo name"

To be useful, the "list repos" route should also give the repo name so that users can see which repo they are choosing.
Modification of #5

This change has been made. /api/unstable/giants-project/repos now returns a JSON array of JSON objects with {"repo_id": repo_id, "repo_name": repo_name}.

This change has been made. /api/unstable/giants-project/repos now returns a JSON array of JSON objects with {"repo_id": repo_id, "repo_name": repo_name}.


Custom plugin monitor always states it timed out, even if cancelled correctly

In https://github.com/kubernetes/node-problem-detector/blob/master/pkg/custompluginmonitor/plugin/plugin.go#L178 there is no check that the context was cancelled (via the defer cancel()) and the logs will keep incorrectly stating the plugin timed out.
I think you want to add a call to Err() in https://golang.org/pkg/context/#Context to check if the context is Canceled or DeadlineExceeded and only attempt killing the plugin on the later.

Looks like this is noted in the PR at https://github.com/kubernetes/node-problem-detector/pull/456#discussion_r556493559.

Looks like this is noted in the PR at https://github.com/kubernetes/node-problem-detector/pull/456#discussion_r556493559.

@ZYecho can you fix this?

@ZYecho can you fix this?

will fix it.

will fix it.

Just to be clear, is this to address the following error?
Feb 01 22:28:22 4229e6fc961d08d92f5d8522fbb73970 node-problem-detector[76420]: E0201 22:28:22.334132   76420 plugin.go:178] Error in running plugin timeout "/root/node-problem-detector/config/plugin/check_ntp.sh"
Feb 01 22:28:22 4229e6fc961d08d92f5d8522fbb73970 node-problem-detector[76420]: E0201 22:28:22.336340   76420 plugin.go:185] Error in kill process 78392, no such process

Just to be clear, is this to address the following error?
Feb 01 22:28:22 4229e6fc961d08d92f5d8522fbb73970 node-problem-detector[76420]: E0201 22:28:22.334132   76420 plugin.go:178] Error in running plugin timeout "/root/node-problem-detector/config/plugin/check_ntp.sh"
Feb 01 22:28:22 4229e6fc961d08d92f5d8522fbb73970 node-problem-detector[76420]: E0201 22:28:22.336340   76420 plugin.go:185] Error in kill process 78392, no such process

yep


Returns an Object of Data from the Links

Rather than having a single link, it will now return an object which can be traversed for more control over the data.

I would really need help in the unit tests....


cerebral infarct

If this is a request for a new term, please provide us with the following information.

Preferred term label (e.g., asplenia)

cerebral infarct

Synonyms (e.g., absent spleen)

brain infarct, cerebrum infarct

Textual definition (the definition should be understandable even for non-specialists. Include a PubMed ID or URL(s) to refer to any relevant article(s) that provides information about the suggested term).

a necrotic lesion in the cerebrum resulting from a sudden insufficiency of arterial or venous blood supply due to emboli, thrombi or mechanical factors

Any additional notes to clarify the meaning or use of the term. Please provide a PubMed ID or URL(s) for the source of this information.

https://jamanetwork.com/journals/jamaneurology/fullarticle/776636
DOI: 10.1001/archneur.57.6.869

Suggested parent term (Please look in the hierarchy of the MP using the MP Browser or other browsers such as OLS and find the place in the MP where the new term best fits)

brain lesion, abnormal cerebral hemisphere morphology

If you would like a nanoattribution, please indicate your ORCID id or provide a label such as MGI:sbello (organization, first initial-last name)

https://orcid.org/0000-0003-2307-1226

review existing infarction size terms these should be infarct not infarction

MP:0021003

Per Sue's comment:
Reopened ticket to review existing infarction size terms and change decreased/increased cerebral infarction size and decreased/increased myocardial infarction size to use infarct rather than infarction in the term label.
infarct is (pathology) an area of dead tissue caused by a loss of blood supply; a localized necrosis while infarction is (pathology) the process which causes an infarct (see https://wikidiff.com/infarct/infarction)


Add validator draft3/draft4 schema unique check missed case

Currently having a field with a type { "type": "array", "uniqueItems": false } fails with a function clause during validation. I added a missed function case.

Thanks! (and the obvious Sorry for the long feedback loop!)


changes in navbar, footer,etc.

changes in navbar, footer, and some content fonts sizes, color, adjustment, etc. in all webpages

Please resolve it

Resolve the conflict and create a new PR


Svelte + Framework7 Sheet Bug

Framework7 version: 7.0.5
Svelte version: 3.48.0
Platform and Target: All Platforms
Live Link or JSFiddle/CodeSandbox: https://github.com/osmancoskun/f7-sheet-bug

Describe the bug
When trying to use sheet on framework7, we saw a bug which is annoying and make application unusable. When you run application and click on next page, you will see a button. Button only opens sheet. if you open it only once, there is no problem.
But if you follow these steps, application gives closeByBackDropClick error and make application unusable.
To Reproduce
Steps to reproduce the behavior:

Go to  page with button on main screen.
Click on Open Sheet and close it few times.
Go back to previous page with backlink
Try to go to page again.
See error on browser console.

Expected behavior
Sheet to work as expected
Actual Behavior
Cannot open sheet few times.
Screenshots

It happens because you open sheet and then its content is changed, which can lead to sheet re-render/re-creation in a bit wrong way. Just call open sheet within 0 timeout, after its content upated like so:
<Button
    fill
    on:click={() => {
      modalTitle = "Vladimir";
      setTimeout(() => {
        f7.sheet.open(".test");
      })
    }}>Open Sheet</Button
  >


Add modes of variability script to setup.py

This adds the modes of variability driver to setup.py.

@gleckler1  @lee1043 A quick PR to get MOV driver installed to help with Jiwoo's notebook and my CMEC work.

@acordonez thank you!


error 400

First, thank you for this repository !
I run into error 400 in fun createImageEdit(...)  and in fun createImageVariation(...)

do you have an idea, what's wrong here ?

my fault


Added Wealth of Nations example

@SylvainCorlay @stonebig This is in reference to #151 . A recreation of Mike Bostock's Wealth of Nations.

@dmadeka awesome!
Can you post a screenshot in the PR?
To include this, we might need to elaborate on the source of the data.

@SylvainCorlay I updated the LICENSE file

To do:

[ ] Add Label on bottom right corner of Figure ala d3 example
[ ] Add line drawn on hovered point for the entire path of the country

Hi. I just tested:

on chrome, it works, just:
. didn't notice a mouse-over explanation of the bubble,
. the automatic animation is slow and showing only 1 every 7 years (maybe a bigger pc is needed to make it smooth ?)
. using the bottom slider, the animation is looking much better !?!
on firefox... basically firefox seems to lock-up, doesn't work (or dead slow ?).

By Order of priority:

I would like to get the mouse-over details, ("China", "USA", ...)
is there something to improve the automatic experience ? if it can work great manually, the automation should not feel bad.

@stonebig Please look at #142 . This is being fixed but the Tooltip displays on the bottom left of the Figure for right now. You can change the animation speed by changing the sleep time in the for loop.

About the automatic animation, it seems its hard to get the sleep to work with the animation_duration attribute of the Figure. We are trying to resolve this right now, but the IntSlider is the way to make it smooth.

For Firefox please see #149

I don't see any tooltip appring on the bottom left, let suppose this is my screen size, and anyway being fiexed.

@rmenegaux If you think its good, let's merge this?

@rmenegaux ping

@rmenegaux Rebased

Fixed the commit history and update the doc
@rmenegaux

Related to this is this new PR upstream to improve the play button mechanism. https://github.com/ipython/ipywidgets/pull/633

a stable beta would have been nice, tonight.


Adding Docker and .NET Core 2.1 support

Issues# 61.
This is a starting point for Docker and .NET Core 2.1.2 transition.

Max, I'm new to Docker. Does using Docker dictate that we must use Docker in production? Or is this just for local environments?

We do not need to have containers inside of Azure for now, the deployment still can continue as Web App for Azure. I believe you are using Publish to accomplish that. So keep it the same way. If you don't want to use Docker locally simply set up Chavah project as start up.

Sometimes you need to restart Docker and it refreshes the issue with this message.

Max, are you able to startup the Chavah.NetCore project locally? After merging this request, I can't start the project; it exits immediately. Are you seeing this?


Show progress bar during cloning

This would be helpful when cloning large repos.

This is probably still necessary, even given #55. It still takes 14 seconds to clone Bazel to one commit.
Maybe just print the output from git clone?


Custom data set training using pre-trained weights

Hi there, thank you so much for your hard work for release.
Could you please provide a tutorial for custom data training using pre-trained weights?
And is it possible at the moment to fine-tune DINO with Swin backbones?

Hi there, thank you so much for your hard work for release. Could you please provide a tutorial for custom data training using pre-trained weights? And is it possible at the moment to fine-tune DINO with Swin backbones?

Hi! We will release some converted or detrex pretrained DINO-Swin weights recently, and the tutorials for custom datasets will be coming soon. You can also check detectron2 custom dataset tutorials here: documentation

@rentainhe thank you for the fast reply! I have a bit of experience with detectron2 already, is the usage of detrex the same? in detectron2 I would do something like this to train:
register_coco_instances()
cfg = get_cfg()
cfg.merge_from_file()
cfg.MODEL.WEIGHTS = model_zoo.get_checkpoint_url()
# etc.
trainer = DefaultTrainer(cfg)
trainer.train()

or did you mean I only need to register data?

@rentainhe thank you for the fast reply! I have a bit of experience with detectron2 already, is the usage of detrex the same? in detectron2 I would do something like this to train:
register_coco_instances()
cfg = get_cfg()
cfg.merge_from_file()
cfg.MODEL.WEIGHTS = model_zoo.get_checkpoint_url()
# etc.
trainer = DefaultTrainer(cfg)
trainer.train()

or did you mean I only need to register data?

Yes, we use the same training engine as detectron2. But we've adopted the newly designed LazyConfig config system which we believe will work better than the old yacs config system.
After registering your own datasets, maybe you can train DETR on your custom datasets as follows:

Modify dataloader configs here: data_detr.py, if your datasets have the same format as COCO, I guess you can directly use the default API provided in detectron2, e.g., get_detection_dataset_dicts, build_detection_test_loader. Or you may need to write your own dataset_mapper follows DetrDatasetMapper.
Import your new dataloader config in dab_detr_r50_50ep.py, using DAB-DETR as an example.

This way may take you some time to learn the dataloader API designs in detectron2. However, with the help of LazyConfig, there's another way for you to use your own datasets.
You can hack into train_net.py and implement your own datasets and dataloader there. As you can see, in train_net.py, we directly pass the instantiated dataloader into Trainer. Maybe you can instantiate your own dataloader here
# example

# train_loader = instantiate(cfg.dataloader.train)
train_loader = your_own_train_loader

@rentainhe thank you for the fast reply! I have a bit of experience with detectron2 already, is the usage of detrex the same? in detectron2 I would do something like this to train:
register_coco_instances()
cfg = get_cfg()
cfg.merge_from_file()
cfg.MODEL.WEIGHTS = model_zoo.get_checkpoint_url()
# etc.
trainer = DefaultTrainer(cfg)
trainer.train()

or did you mean I only need to register data?

To put it simply, register datasets -> create your own dataset mapper if needed -> update data config

@rentainhe thank you for the fast reply! I have a bit of experience with detectron2 already, is the usage of detrex the same? in detectron2 I would do something like this to train:
register_coco_instances()
cfg = get_cfg()
cfg.merge_from_file()
cfg.MODEL.WEIGHTS = model_zoo.get_checkpoint_url()
# etc.
trainer = DefaultTrainer(cfg)
trainer.train()

or did you mean I only need to register data?

If you are not in a rush, we will provide tutorials about training on custom datasets as soon as possible.

@rentainhe
When will you release the fully trained DINO pre-trained weights? I can only find the 12-epoch ones.

@rentainhe When will you release the fully trained DINO pre-trained weights? I can only find the 12-epoch ones.

We will release DINO training results in the future version if you're not in a rush. We will also provide the converter for the users to convert the weight trained from the original repo later, maybe you can use the pretrained 24 and 36epochs results by converting them from the official repo.  @VCBE123

@rentainhe hey there! I managed to start a custom training with the new DINO weights you guys released yesterday; thank you so much for that!
However, I couldn't figure a way to start a hard-negatives training i.e. do NOT filter empty annotations out.
Now while training I'm getting the following message:
[10/19 15:45:10 d2.data.build]: Removed 1194 images with no usable annotations. 821 images left.
I added the next line in the config.py I use for training following the way you would do it for Detectron2:
dataloader.filter_empty_annotations= False
but it did not change anything.
Your help would be much appreciated!

@rentainhe Thank you so much! It worked. However, I have another issue now with inference. Could you please provide an example of custom image inference for the fine-tuned weights?
I'm trying to follow this issue, but it's not working out well so far. I'm getting an error message while trying to instantiate a LazyConfig as suggested here:
---> [28] cfg = get_config('/home/data/detrex/output/2110_0730/config.yaml')
NameError: name 'get_config' is not defined

hello @alrightkami ! The get_config() functions will automatically get the config from configs/common after building detrex.
you need to add your config here~, then you can load your own config file by using get_config(), however, the better way is to directly add a new config.py in your projects.
I'm reproducing your problems now and try to solve it~

@rentainhe Thank you for trying to help! I still wasn't able to fix the issue today and run inference.
Could you please provide a code snippet of how to do inference for fine-tuned weights on your own data?
This would be very helpful.

@rentainhe Thank you so much! It worked. However, I have another issue now with inference. Could you please provide an example of custom image inference for the fine-tuned weights? I'm trying to follow this issue, but it's not working out well so far. I'm getting an error message while trying to instantiate a LazyConfig as suggested here:
---> [28] cfg = get_config('/home/data/detrex/output/2110_0730/config.yaml')
NameError: name 'get_config' is not defined

Update: things I tried 1) I was trying to find where the get_config() comes from and finally figured it out: cfg = model_zoo.get_config('/home/data/detrex/output/2110_0730/config.yaml')
However, it's expecting the config file to be from Detectron2's ModelZoo: RuntimeError: /home/jovyan/data/kamila/detrex/output/graffiti2/2110_0730/config.yaml not available in Model Zoo!
2) I also looked into the model_zoo.py code and tried to import config as follows:
cfg_path = '/home/data/detrex/output/2110_0730/config.yaml'
cfg = get_cfg(cfg_path)

but got: TypeError: get_cfg() takes 0 positional arguments but 1 was given
3) LazyConfig also doesn't work here for me:
cfg = LazyConfig.load(cfg_path)

I'm getting:
ConstructorError: while constructing a Python object
cannot find module 'None' (No module named 'None')
  in "/home/data/detrex/output/2110_0730/config.yaml", line 103, column 106

4) When I'm trying to use detrex's config:
from detrex.config import get_config
cfg = get_config("common/data/coco_detr_graffiti.py")
cfg.train.init_checkpoint = trained_model

I'm also getting an error:
----> [9] cfg.train.init_checkpoint = trained_model
ConfigAttributeError: Missing key train
    full_key: train
    object_type=dict

for the 4-th one, you can try to use:
from detrex.config import get_config
cfg = get_config("common/data/coco_detr_graffiti.py").train
cfg.train.init_checkpoint = trained_model

@rentainhe I tried it, but it didn't change anything, I'm still getting the same error

you need to add your config here~, then you can load your own config file by using get_config(), however, the better way is to directly add a new config.py in your projects.

FYI: I added the config file in the configs/common, but it's not a pretty solution because it causes the problem with imports:
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
/tmp/ipykernel_58675/3920766154.py in <module>
      1 path_to_imgs = "..."
      2 output_folder = "..."
----> 3 draw_labels(path_to_imgs, output_folder)

/tmp/ipykernel_58675/1565024436.py in draw_labels(path_to_imgs, output_folder, save_originals)
     27     # initialise configuration (has to be the same as in the training)
     28     # cfg = get_config("common/data/coco_detr_graffiti.py").train
---> 29     cfg = get_config("common/data/dino_swin_large_384_4scale_12ep_graffiti.py")
     30     cfg.train.init_checkpoint = trained_model
     31     model = instantiate(cfg.model)

/home/jovyan/data/kamila/detrex/detrex/config/config.py in get_config(config_path)
     50     if not os.path.exists(cfg_file):
     51         raise RuntimeError("{} not available in detrex configs!".format(config_path))
---> 52     cfg = LazyConfig.load(cfg_file)
     53     return cfg

/home/jovyan/data/kamila/detrex/detectron2/detectron2/config/lazy.py in load(filename, keys)
    209                 # 1. make filename appears in stacktrace
    210                 # 2. make load_rel able to find its parent's (possibly remote) location
--> 211                 exec(compile(content, filename, "exec"), module_namespace)
    212
    213             ret = module_namespace

/home/jovyan/data/kamila/detrex/detrex/config/configs/common/data/dino_swin_large_384_4scale_12ep_graffiti.py in <module>
      1 import datetime
      2 from detrex.config import get_config
----> 3 from .models.dino_swin_large_384 import model
      4 # from detrex.projects.dino.configs.models.dino_swin_large_384 import model
      5

/home/jovyan/data/kamila/detrex/detectron2/detectron2/config/lazy.py in new_import(name, globals, locals, fromlist, level)
    138             and (globals.get("__package__", "") or "").startswith(_CFG_PACKAGE_NAME)
    139         ):
--> 140             cur_file = find_relative_file(globals["__file__"], name, level)
    141             _validate_py_syntax(cur_file)
    142             spec = importlib.machinery.ModuleSpec(

/home/jovyan/data/kamila/detrex/detectron2/detectron2/config/lazy.py in find_relative_file(original_file, relative_import_path, level)
    125             cur_file += ".py"
    126         if not PathManager.isfile(cur_file):
--> 127             raise ImportError(
    128                 f"Cannot import name {relative_import_path} from "
    129                 f"{original_file}: {cur_file} has to exist."

ImportError: Cannot import name models.dino_swin_large_384 from /home/jovyan/data/kamila/detrex/detrex/config/configs/common/data/dino_swin_large_384_4scale_12ep_graffiti.py: /home/jovyan/data/kamila/detrex/detrex/config/configs/common/data/models/dino_swin_large_384.py has to exist.

I fixed it when I changed from .models.dino_swin_large_384 import model
to from projects.dino.configs.models.dino_swin_large_384 import model

you need to add your config here~, then you can load your own config file by using get_config(), however, the better way is to directly add a new config.py in your projects.

FYI: I added the config file in the configs/common, but it's not a pretty solution because it causes the problem with imports:
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
/tmp/ipykernel_58675/3920766154.py in <module>
      1 path_to_imgs = "..."
      2 output_folder = "..."
----> 3 draw_labels(path_to_imgs, output_folder)

/tmp/ipykernel_58675/1565024436.py in draw_labels(path_to_imgs, output_folder, save_originals)
     27     # initialise configuration (has to be the same as in the training)
     28     # cfg = get_config("common/data/coco_detr_graffiti.py").train
---> 29     cfg = get_config("common/data/dino_swin_large_384_4scale_12ep_graffiti.py")
     30     cfg.train.init_checkpoint = trained_model
     31     model = instantiate(cfg.model)

/home/jovyan/data/kamila/detrex/detrex/config/config.py in get_config(config_path)
     50     if not os.path.exists(cfg_file):
     51         raise RuntimeError("{} not available in detrex configs!".format(config_path))
---> 52     cfg = LazyConfig.load(cfg_file)
     53     return cfg

/home/jovyan/data/kamila/detrex/detectron2/detectron2/config/lazy.py in load(filename, keys)
    209                 # 1. make filename appears in stacktrace
    210                 # 2. make load_rel able to find its parent's (possibly remote) location
--> 211                 exec(compile(content, filename, "exec"), module_namespace)
    212
    213             ret = module_namespace

/home/jovyan/data/kamila/detrex/detrex/config/configs/common/data/dino_swin_large_384_4scale_12ep_graffiti.py in <module>
      1 import datetime
      2 from detrex.config import get_config
----> 3 from .models.dino_swin_large_384 import model
      4 # from detrex.projects.dino.configs.models.dino_swin_large_384 import model
      5

/home/jovyan/data/kamila/detrex/detectron2/detectron2/config/lazy.py in new_import(name, globals, locals, fromlist, level)
    138             and (globals.get("__package__", "") or "").startswith(_CFG_PACKAGE_NAME)
    139         ):
--> 140             cur_file = find_relative_file(globals["__file__"], name, level)
    141             _validate_py_syntax(cur_file)
    142             spec = importlib.machinery.ModuleSpec(

/home/jovyan/data/kamila/detrex/detectron2/detectron2/config/lazy.py in find_relative_file(original_file, relative_import_path, level)
    125             cur_file += ".py"
    126         if not PathManager.isfile(cur_file):
--> 127             raise ImportError(
    128                 f"Cannot import name {relative_import_path} from "
    129                 f"{original_file}: {cur_file} has to exist."

ImportError: Cannot import name models.dino_swin_large_384 from /home/jovyan/data/kamila/detrex/detrex/config/configs/common/data/dino_swin_large_384_4scale_12ep_graffiti.py: /home/jovyan/data/kamila/detrex/detrex/config/configs/common/data/models/dino_swin_large_384.py has to exist.

I fixed it when I changed from .models.dino_swin_large_384 import model to from projects.dino.configs.models.dino_swin_large_384 import model

Yes, we use absolute import path here because we want to use a unified train_net for all the models

You can use the demo to inference your custom image or video using the pretrained weights. And more info can be found in the documentation: Inference demo with the pretrained weights.
As there is no more activity, I am closing the issue~ Feel free to reopen it if necessary. Or you can leave a new issue if you meet some other problems. @alrightkami


Arnej/add distance threshold

I confirm that this contribution is made under the terms of the license found in the root directory of this repository's source tree and that I have the authority necessary to make this contribution on behalf of its copyright owner.
@geirst please review

@geirst PTAL
i think it's enough to just test some simple cases.

@geirst PTAL
i think it's enough to just test some simple cases.

Note: this breaks the query serialization protocol.

Note: this breaks the query serialization protocol.

@geirst now added the hack with flag in allow_approximate

@geirst now added the hack with flag in allow_approximate


Low Image quality in IE / wrong size selection

Hi Alexander,
I wish you could help me with this issue. It seems that the images of the the news list are not loaded correctly in IE 11. I wasn't able to figure out the reason.
http://goo.gl/nOGxd0
Maybe you can have a look at it.
Thank you so much.

Just to let you know: I have now fixed this issue quick & dirty by deleting the lower quality media sources to force IE to load an acceptable image size. This works because IE seems to load the lowest image size always. That's not a solution, but I want to let you know, just in case you take a look at it. Thanks Alex

try to alter the code using this one :
`var getWidth = function(elem, parent, width){
// width = width || elem.offsetWidth;
width =  parent.offsetWidth;
        while(width < lazySizesConfig.minSize && parent && !elem._lazysizesWidth){
            width =  parent.offsetWidth;
            parent = parent.parentNode;
        }

        return width;
    };`

I would need a simplified testcase on codepen, jsfiddler, jsbin or what you want.

Hi Alexander,
we, too, believe are experiencing the same / a similar issue. It looks like the combination responsive / data-src attribute is the problem (we deliberately use the lower quality image, because of an improved Google Page Speed score).
Example:
[https://www.vacando.com/ticino/switzerland/]
I would be very thankful if you could take a look!
Also, thanks for this great plugin!

@crealistiques
I just looked into your example and I can not replicate your issue. In my case testing with IE11, the image size was 1100px and the 1140w image candidate was choosen (Although there were smaller candidatets 555w/737w candidates). In my eyes this is the best candidate to choose for this size.
Please give me a testcase or more/better instructions to replicate the problem.
@ibischofer
No, your problem has to do with the fact that you are not using a polyfill like the respimg polyfill plugin or picturefill and IE11 does not support srcset.
In this case the browser will always load the src/data-src attribute. You can either use one of these polyfills. Or change your markup so that the data-src has a higher quality something like this:
<img src="very-small.jpg" data-src="medium.jpg" data-srcset="very-small.jpg 100w, small.jpg 250w, medium.jpg 500w, large.jpg 800w" />

@aFarkas case of RTFM, sorry for stealing your time. Many thanks!

@aFarkas
Thank you very much for you time and effort. Actually it's hard for me to provide a simplified test case at the moment. I guess you checked the big header image on the given site where the problem does not occur. The wrong size selection only happens for me for the smaller list images down below. As already mentioned I fixed this q&d by removing the smaller source variants to ensure a proper display of the images at the given size. Thanks again Alex for your engagement!

@crealistiques
I have not forgotten you. I'm just ill. Will be the first thing I will looking into, if I get better.

Hi Alex,
take your time, as mentioned I have found a temporary solution.
Thank you, I hope you will be fine soon.
Steffen

Crealistiques.
 I'm just ill. Will be the first thing I will looking into, if I get better.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@crealistiques
This issue should be fixed now. Thanks for your bug report.

@aFarkas don't know whether to open a new issue because I've experienced the same with IE, it just chooses the candidate right before the right one. In particular with the most left image in screenshot, which looks right in other browsers
Any idea what's wrong? Thank you

@dotBits
You have two errors in your markup:

Your width descriptors are broken:
``https://images.musement.com/default/0001/19/colosseum-roman-forum-and-palatine-hill-skip-the-line-tickets_header-18714.jpeg?w=290&q=60&fit=crop&h=245 320w, https://images.musement.com/default/0001/19/colosseum-roman-forum-and-palatine-hill-skip-the-line-tickets_header-18714.jpeg?w=335&q=60&fit=crop&h=245 640w, https://images.musement.com/default/0001/19/colosseum-roman-forum-and-palatine-hill-skip-the-line-tickets_header-18714.jpeg?w=690&q=60&fit=crop&h=420 960w```

The 290 image has a descriptor of 320w, the 335 has a descriptor of 640w and the 690 has a descriptor of 960w.

you do art direction with srcset alone (for the first image in a row), but you should use picture  here instead (or use the object-fit/parent-fit plugin instead (object-fit as polyfill for IE and parent-fit to add object-fit calculation to data-sizes="auto"). Or build a special plugin for this art direction purpose.

This should fix your issues.


Fix VAT Calculator JS returns zero tax for business country code

Fixes #45 , by loading the (global) config in the constructor and create
a new instance that passes the config as argument.

Codecov Report

Merging #46 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #46   +/-   ##
=======================================
  Coverage   95.16%   95.16%
=======================================
  Files           5        5
  Lines         186      186
=======================================
  Hits          177      177
  Misses          9        9

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 41f19f7...faeb67d. Read the comment docs.

Thank you!


ImageCache类初始化方法中没必要将fileManager的初始化放在IOQueue上执行吧？应该不会引起多线程问题吧！

ioQueue.sync { fileManager = FileManager() }

For now, it should be fine since the file manager delegate is not in use. However, the decision of using a unique file manager instead of the shared one in another thread might cause problems if later we want to inspect some events. The FileManager class is not thread-safe after all.
According to the documentation, I think it would be better to create it within the using thread as well.


port to docker-data-science pipeline to v2.x workflow

Hello @arshul! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file workflows/docker-data-science/docker/app.py:

Line 31:80: E501 line too long (84 > 79 characters)

In the file workflows/docker-data-science/docker/generate_figures.py:

Line 5:1: E402 module level import not at top of file
Line 10:80: E501 line too long (97 > 79 characters)
Line 28:80: E501 line too long (84 > 79 characters)


Removed useAppContext parameter from private IsEnabledAsync

The useAppContext argument was only being passed from the contextual overload of IsEnabledAsync. It seems like the state represented by useAppContext could be determined based on whether appContext is null or non-null.

If the user passes a null value for appContext this breaks. The contextual feature filter is no longer run.

I see. I guess it seems unintuitive to me that a null would constitute useful appContext for contextual filter logic so why even run the filter?


Discussion: Let's talk about impact vectors

What is it?
This is probably something we should just discuss in meeting tomorrow, but I'm kinda confused by the notion of an impact vector:
Vectors are typically just a quantity and a direction (https://www.merriam-webster.com/dictionary/vector). We seem to also add a bunch of constraints around time and normalization and stuff that don't seem vector-like, but I'm still brainstorming for a different name.
I think you're trying to describe a way to compare impact metrics across a group of projects? Can't we just stick to "impact metric"? An impact metric can just be a normalized version of another impact metric. And impact metrics are already aggregated over a discrete period of time.

Here's my mental model, curious if it fits with what you guys think:
A metric is a single quantity (e.g. like commits)
A vector (like in linear algebra) is a group of metrics + the project_id + the time. Basically a row of our KPI table or metrics table.

@ryscheng made some edits #1022 - let me know if you have further improvements. I looked into expressing it mathematically, but was dissuaded by needing to import KaTeX


[NL] smaller charts

shrink charts down to 160px tall, and 3 charts wide (also removed legends, margins, etc)
also fixes chart / block titles with plurals

i'll merge and can fix comments in a follow up!


[Error 404: NOT FOUND] Deployment cannot be found

The link in the description https://admin-nexus-eight.vercel.app/, is not live. Lead to a broken page with the following error:

We need to fix this deployment link.

@shubhansu-kr
Hey thanks for pointing it out.
i changed the deployment link and it didn't got updated here. will do that


Error response from daemon: client version 1.40 is too new. Maximum supported API version is 1.38

After updating my local docker to the latest version (<IP_ADDRESS>) using brew update && brew upgrade, I get this error when entering  e.g. docker ps in the console:
Error response from daemon: client version 1.40 is too new. Maximum supported API version is 1.38

Because of the still open issue #290 I'm using the v18.06.1-ce boot2docker iso image for my parallels vm.
Now, I'm in a dead end :-(
The only way to get out of it is:
brew unlink docker
brew install https://raw.githubusercontent.com/Homebrew/homebrew-core/8a947170e0ebffed2e4369e1fb9c9c31a81d2f30/Formula/docker.rb

This installs docker 19.03.06 again, where this problem doesn't exists.
To avoid future automatic updates this could also be helpful:
brew pin docker

I'm not sure how #230 could be related, did you mean to link to a different issue?

I mean #290. Already fixed it in my issue description.

Meanwhile I updated to the newest docker version coming with brew (19.03.11) and the problem was solved.
So, I think this issue could be closed.


Setup basic gulp stack

Create base gulpfile with watch and scss tasks. (trash existing gulpfile).
Move CSS authoring to a SCSS structure in resources/assets/scss.

Done.


Source Generated RegEx

RegEx changed to Source Generated to improve perfomance:

.NET regular expression source generators
Regular Expression Improvements in .NET 7

Very nice PR!!!


Heatmap clean tree

Purpose:
#424 But healthier tree

I see you decided to merge anyways

I see you decided to merge anyways

Yeah, sorry, I just now saw your responses. I think the chaos was caused by me updating from master -- I didn't realize those updates would appear as changed files in the PR. Sorry for the confusion!


make deployment idempotent

While was deploying this program to aws, I encountered an error as I did not setup sufficient permission. When I deploy the second time, I encountered various deploy error like
 Serverless Error ---------------------------------------

  An error occurred: IamRoleLambdaExecution - bitwarden-serverless-prod-us-east-1-lambdaRole already exists.

and
 Serverless Error ---------------------------------------

  An error occurred: FoldersTable - bitwarden-serverless-prod-folders already exists.

I have to delete the all the tables and roles before continue. Is it possible to check if bitwarden-serverless-prod-folders is empty before directly aborting the deployment? The deployment process should be idempotent.

I think this is a limitation of serverless framework itself. Maybe somehow need to configure it better.
I'm happy for any contributions here.


Fix enter button opening JSColor popup

When you click enter on the top text, the jscolor selector popup shows at the top left of the screen.

The default behavior of a  is submit, so by adding type="button" to the  tag, chrome recognizes it as such.


Symbol with underscores on either side in url breaks linkify

With this set of sample URLs:
https://en.wikipedia.org/wiki/Jesse_Hughes_(musician)#/media/File:Eagles_of_Death_Metal_$_Steel_Blue_Oval_(1_3_2010)_(4416148631).jpg

https://en.wikipedia.org/wiki/Jesse_Hughes_(musician)#/media/File:Eagles_of_Death_Metal_%_Steel_Blue_Oval_(1_3_2010)_(4416148631).jpg

https://en.wikipedia.org/wiki/Jesse_Hughes_(musician)#/media/File:Eagles_of_Death_Metal_@_Steel_Blue_Oval_(1_3_2010)_(4416148631).jpg

https://en.wikipedia.org/wiki/Jesse_Hughes_(musician)#/media/File:Eagles_of_Death_Metal_A_Steel_Blue_Oval_(1_3_2010)_(4416148631).jpg

https://en.wikipedia.org/wiki/Jesse_Hughes_(musician)#/media/File:Eagles_of_Death_Metal_a_Steel_Blue_Oval_(1_3_2010)_(4416148631).jpg

https://en.wikipedia.org/wiki/Jesse_Hughes_(musician)#/media/File:Eagles_of_Death_Metal_1_Steel_Blue_Oval_(1_3_2010)_(4416148631).jpg

https://en.wikipedia.org/wiki/Jesse_Hughes_(musician)#/media/File:Eagles_of_Death_Metal_-_Steel_Blue_Oval_(1_3_2010)_(4416148631).jpg

Paste this source into the markdown-it and linkify-it demos. The link breaks when it encounters a symbol in the markdown-it demo between two underscores, but does not for the linkify-it demo.
I believe this has something to do with em being applied before linkify. I've tried to write a rule to circumvent this behavior, but modifying tokens after they've already been parsed to the needed degree gets pretty messy. Any insight is appreciated.

That's s known issue that can't be fixed. You markup link directly with <...> to avoid collision


Checkout Problem - "Forbidden"

I tried multiple forms of payment and keep getting a "Forbidden" error when attempting to pay by credit card to upgrade to Pro.

Dupe of #3072


Update action client goal callback signature

The signature was removed in https://github.com/ros2/rclcpp/commit/6815022909086487f2b8dc14c0540b00d4cf61a0.
It was deprecated for the galactic release, see https://github.com/ros2/ros2_documentation/blob/galactic/source/Releases/Release-Galactic-Geochelone.rst#action-client-goal-response-callback-signature-changed.

Example job failing in the buildfarm https://build.ros2.org/view/Rbin_uJ64/job/Rbin_uJ64__rclc__ubuntu_jammy_amd64__binary/26

Thanks a lot @ivanpauno!


Notice: Undefined offset: 1 in HttpClient.php on line 244

Hi,
A notice appears when you update/create a product. I think it happens on all post/put method.
Problem: automattic/woocommerce/src/WooCommerce/HttpClient/HttpClient.php on line 244
list($key, $value) = \explode(': ', $line);
The header contains a line HTTP/1.1 200 OK and this string doesn't contains :.

Fixed in #12


Bind not work on Genymotion with Android 4.1.1

Perfect Worked in Android 5.1.1
on Android 4.1.1 viewRoot is null.
on Samsung tablet with 4.4.2 It does not work
compile 'com.jakewharton:butterknife:7.0.1'

@Bind(R.id.root)
    View viewRoot;
@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_splash);
    ButterKnife.setDebug(true);
    ButterKnife.bind(this);
    int padding = getResources().getDimensionPixelSize(R.dimen.activity_generic_margin);
    viewRoot.setPadding(padding, getStatusBarHeight(), padding, padding);
}

proguard:

-keep class butterknife.** { ; }
-dontwarn butterknife.internal.*
-keep class *$$ViewBinder { ; }
-keepclasseswithmembernames class * {
@butterknife. ;
}
-keepclasseswithmembernames class * {
@butterknife. ;
}

logs:
Looking up view binder for app.logistic.kz.logistic.activities.SplashActivity
Not found. Trying superclass android.app.Activity
MISS: Reached framework class. Abandoning search.

I guess it's multidex problem, some (at least those that were generated by
ButterKnife) of your classes were placed in another dex file because you
had exceeded 65k methods limit and on Android 4 you didn't load other dex
files.
Please check the documentation about multidex.
13 июля 2015 г. 8:51 AM пользователь "Askar"<EMAIL_ADDRESS>написал:

Perfect Worked in Android 5.1.1
on Android 4.1.1 viewRoot is null.
compile 'com.jakewharton:butterknife:7.0.1'
@Bind(R.id.root)
View viewRoot;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_splash);
ButterKnife.setDebug(true);
ButterKnife.bind(this);
int padding = getResources().getDimensionPixelSize(R.dimen.activity_generic_margin);
viewRoot.setPadding(padding, getStatusBarHeight(), padding, padding);
}
proguard:
-keep class butterknife.** {
; } -dontwarn butterknife.internal.*
-keep class *
$$ViewBinder { ; } -keepclasseswithmembernames class * { @butterknife.
;
}
-keepclasseswithmembernames class * {
@butterknife. ;
}
logs:
Looking up view binder for
app.logistic.kz.logistic.activities.SplashActivity
Not found. Trying superclass android.app.Activity
MISS: Reached framework class. Abandoning search.
—
Reply to this email directly or view it on GitHub
https://github.com/JakeWharton/butterknife/issues/311.

I forgot to add the inheritance

public class MyApplication extends MultiDexApplication{
...
}

Thanks, Artem.


label on leaf node

Would it be possible to put the name of the predicted class on a leaf node instead of just the color?

how do I turn this on, what is the magic parameter?

It is on by default


Implement union database

UnionDatabase is a database containing all records in the PublicDatabase
and all PrivateDatabase. This database is only intended for admin user and
ACL settings do not apply.
The preprocessor is also modified to allow client to select a union database. A private database can be selected by ID if the client is authenticated with master key.

@rickmak This pull request is updated to support the union database and inject db preprocessor update


Fixes for pulsechain

Latest version of the pulse chain script that resolves the latest issues.
Results below.

Now mine is 92. Let me work on this some more. I gotta hunt down some data bugs.

Hey @korkey128k , I'm getting different results - 15659, which again doesn't look good


📃 #12 — We should only bring down the statuses that don't exist in the SQLite database

I would love this; can I help get this over the finish line?

Hey @phildini! It would be awesome if you would like to take over this PR. Is there anything you need from my end?

Do you think we should be trying to fetch the latest object from the DB if it exists? Or make people put in the latest every time?


FancyZones must be disabled and enabled at every restart

Microsoft PowerToys version
0.49.1
Running as admin

[X] Yes

Area(s) with issue?
FancyZones
Steps to reproduce
Every restart Fancy Zones does not work, I have to turn it off and on again to make the zones appear.
✔ Expected Behavior
Automatically be enabled at startup
❌ Actual Behavior
Zones do not appear until FancyZones is turned off and on again.
Other Software
No response

Duplicate of #13214

Thanks for reporting this. This issue is a duplicate.
I'm linking this issue to #13124 to centralize the discussion thread for tracking.
Thanks for your help to make PowerToys a better piece of software!


Add section on each plugin page to indicate if it was made with Meltano SDK

Migrated from GitLab: https://gitlab.com/meltano/hub/-/issues/125
Originally created by @tayloramurphy on 2021-10-01 21:07:10

Related to #124.
Long-term we want a badge, but for now a bit of text would go a long way.

View 2 previous comments from the original issue on GitLab


How do you make @link link to the type you want?

I have a file with an exported alias called Tournament and an exported class called Tournament in another file.
In another file I then do ... see {@link Tournament} but it takes me to the alias called Tournament and not the class i wanted it to link to. Is there a way to resolve this and force the link to link to the right thing/

I just created https://typedoc.org/guides/doccomments/ to document TypeDoc's link resolution process.
You can probably fix the link by using "file-name-with-quotes".Tournament as your link target.
If you are using --mode file, there is currently no way to disambiguate the links. Once we adopt TSDoc, you will be able to use :type to specify the type alias. See #1266, there's quite a bit of work to do before we get there unfortunately.


Adding ARM section to the template

This will help service teams be better informed about the ARM API review process and add the required labels.
Latest improvements:
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[ ] The OpenAPI Hub was used for checking validation status and next steps.

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-python

Automation for azure-sdk-for-js

Can one of the admins verify this patch?

Automation for azure-sdk-for-java

Automation for azure-sdk-for-go

Automation for azure-sdk-for-node

Look good, the only thing is, do you have a quick link to the onCall? you might wanna add it there to avoid three billion emails asking how to get to that LOL


Altscreen enter and exit messages

Right now the only way to enter and exit the altscreen (full window mode) is via Program.EnterAltScreen() and Program.ExitAltScreen(). This means that, without employing hacks, one can only enter and exit when starting and quitting programs. It probably makes sense to have library-level messages, similar to tea.Quit, for entering and exiting the altscreen to give Bubble Tea programs the opportunity to jump in and out of the altscreen in-program.

This is a good idea. So we should provide 2 Msg tea.EnterAltScreen and tea.ExitAltScreen. User can trigger them in Update if they want to change the alt screen mode.
I think I can submit a PR if you haven't done this.

That would be awesome, @kiyonlin. Please do feel free to submit a PR. I’d probably call them tea.EnterAltScreenMsg and tea.ExitAltScreenMsg for naming consistency (like tea.KeyMsg and tea.WindowSizeMsg).

Actually, @kiyonlin; there’s a branch I should merge before you do this. I’ll do that in a few minutes and let you know when it’s in.

Dw, I will do it tomorrow (9 hours later) 😃

@kiyonlin Alright, go for it. There are some small changes in how the alt screen is set in #61 (just merged) but it shouldn't change your implementation.

Oh, just one more thought: realizing we'll also need two commands in addition to messages which I'd probably call tea.EnterAltScreen and tea.ExitAltScreen.

This has been merged and was released in v0.13.0.