Draft RFC for Configurable Lints [WIP]

Purpose
Today, the only facts that are provided to ZLint are those that are present within the target x509 certificate. That is to say, the only input to the linter is the certificate itself. This works fairly well, in general, due to the fact that most requirements refer to data encoded within the certificate itself.
This is not, however, universally true. A lint may require access to the full certificate chain in order to deterministically come to a conclusion (#491, Ocsp eku check for non tls certificates). Or language may specify that the requirement only takes effect if certain conditions regarding the certificate's cross signer are true (#619, Lint that the EKU values within a SubCA certificate comply with CABF_BR <IP_ADDRESS> letter g)). And ETSI lints have had a history of being inaccurate due to requirement outside  data (#581, Bug: ESI lints are not consistent with ETSI EN 319 412-5 requirements regarding non-qualified certificates)
Proposal
This proposal is to introduce a second, optional, input file into the ZLint command line interface as well as a supporting framework for transporting relevant configurations to lints. It SHOULD be for an operator to discover and set all releveant configurations for their certificates.
Goals

Non-breaking change. All current invocations of ZLint, as well as all extant lints, MUST remain valid.
Operators SHOULD be able to easy discover, and generate, configurations relevant to the lints that they are target.
Lint authors SHOULD NOT be required to add or edit any further files than they already do. That is, lints should stay localized to their individual files and tests.
Lints that are configurable MUST have a testing framework available to them so that they may construct unit tests against any number of arbitrary configuration combinations.

Code Interface
Lints may implement a new, optional, interface - Configurable...
type Configurable interface {
    Configure() interface{}
}

...where the returned interface{} is a pointer to the target struct to deserialize your configuration into.
If a lint is Configurable then a new step is injected at the beginning of its lifecycle.

Non-Configurable Lifecycle

CheckApplies
CheckEffective
Execute

Configurable Lifecycle

Configure
CheckApplies
CheckEffective
Execute

Example Lints
Contrived Examples
The following is a set of complete examples showcasing how one might write lints to utilize this configuration framework.
package cabf_br

import (
	"github.com/zmap/zcrypto/x509"
	"github.com/zmap/zlint/v3/lint"
	"github.com/zmap/zlint/v3/util"
)

type LintItselfIsConfigurable struct {
	BottlesOfBeerOnTheWall int `comment:"This MUST be set to the number of bottles of beer that were on the signing CAs wall at the time of issuance."`
	ISpyWithMyLittleEye    struct {
		Descriptions []string `comment:"Any number of descriptions that are valid for the subject."`
		Subject      string
	} `toml:"i_spy_with_my_little_eye"`
}

func init() {
	lint.RegisterLint(&lint.Lint{
		Name:          "e_ca_too_few_beers",
		Description:   "CA Certificates MUST have at least 99 beers.",
		Citation:      "BRs: <IP_ADDRESS>.1",
		Source:        lint.CABFBaselineRequirements,
		EffectiveDate: util.CABV148Date,
		Lint:          NewLintItselfIsConfigurable,
	})
}

func NewLintItselfIsConfigurable() lint.LintInterface {
	// Go code encourages that the zero value for a struct be valid, however
	// if you wish for your Lint to have non-zero defaults then your constructor is
	// the place to do so. The value initialized in this constructor WILL appear
	// in the example configuration printed through the `-exampleConfig flag`.
	return &LintItselfIsConfigurable{ISpyWithMyLittleEye: struct {
		Descriptions []string `comment:"Any number of descriptions that are valid for the subject."`
		Subject      string
	}{Descriptions: []string{"larger than a bread box", "smaller than a barn"}, Subject: "A car"}}
}

// In this case, the struct that is the lint itself is the target for configuration.
func (l *LintItselfIsConfigurable) Configure() interface{} {
	return l
}

func (l *LintItselfIsConfigurable) CheckApplies(c *x509.Certificate) bool {
	return util.IsCACert(c)
}

func (l *LintItselfIsConfigurable) Execute(c *x509.Certificate) *lint.LintResult {
	if l.BottlesOfBeerOnTheWall < 99 {
		return &lint.LintResult{Status: lint.Error}
	} else {
		return &lint.LintResult{Status: lint.Pass}
	}
}

package cabf_br

import (
	"github.com/zmap/zcrypto/x509"
	"github.com/zmap/zlint/v3/lint"
	"github.com/zmap/zlint/v3/util"
)

type LintEmbedsAConfiguration struct {
	configuration                        embeddedConfiguration
	SomeOtherFieldThatWeDontWantToExpose int
}

type embeddedConfiguration struct {
	IsWebPKI bool `toml:"is_web_pki" comment:"Indicates that the certificate is intended for the Web PKI."`
}

func init() {
	lint.RegisterLint(&lint.Lint{
		Name:          "w_web_pki_cert",
		Description:   "CA Certificates SHOULD....something....about the web pki",
		Citation:      "BRs: <IP_ADDRESS>.1",
		Source:        lint.CABFBaselineRequirements,
		EffectiveDate: util.CABV148Date,
		Lint:          NewLintEmbedsAConfiguration,
	})
}

// A pointer to an embedded struct may be passed to the framework
// if the author does not wish to expose certain fields in their primary struct.
func (l *LintEmbedsAConfiguration) Configure() interface{} {
	return &l.configuration
}

func NewLintEmbedsAConfiguration() lint.LintInterface {
	return &LintEmbedsAConfiguration{configuration: embeddedConfiguration{}}
}

func (l *LintEmbedsAConfiguration) CheckApplies(c *x509.Certificate) bool {
	return util.IsCACert(c)
}

func (l *LintEmbedsAConfiguration) Execute(c *x509.Certificate) *lint.LintResult {
	if l.configuration.IsWebPKI {
		return &lint.LintResult{Status: lint.Warn}
	} else {
		return &lint.LintResult{Status: lint.Pass}
	}
}

Operators can then generate a sample configuration which contains the defaults for every lint that is configurable.
./zlint -exampleConfig

[e_ca_too_few_beers]
# This MUST be set to the number of bottles of beer that were on the signing CAs wall at the time of issuance.
BottlesOfBeerOnTheWall = 0

[e_ca_too_few_beers.i_spy_with_my_little_eye]
# Any number of descriptions that are valid for the subject.
Descriptions = ["larger than a bread box", "smaller than a barn"]
Subject = "A car"

[w_web_pki_cert]
# Indicates that the certificate is intended for the Web PKI.
is_web_pki = false

Note that comments declared in the provided structs ARE present within example configuration generated by for operators. As such, lint authors SHOULD provide comments describing the purposes of the fields as well as the impact that those fields have on their given lint.

Higher Scoped Configurations
Lints may embed within theselves either pointers or structs to the following definitions
type Global struct {}
type RFC5280Context struct{}
type RFC5480Context struct{}
type RFC5891Context struct{}
type CABFBaselineRequirementsContext struct {}
type CABFEVGuidelinesContext struct{}
type MozillaRootStorePolicyContext struct{}
type AppleRootStorePolicyContext struct{}
type CommunityContext struct{}
type EtsiEsiContext struct{}

NOTE:  These structs are currently empty and the following are merely examples of the sort of data that may be stored in them. For the sake of maintainability and predictability these structs do not allow for arbitrary key:value mappings at runtime. New fields may be added to these structs on a case-by-case bases when there is a consensus that a particular configuration may be valuable to share among many lints of a particular class.

Doing so allows for the reuse of common configurations among entire classes of lints.
some_global = true
some_other_global = "So long and thanks for all the fish"

[etsi_esi]
is_web_pki = true

[e_plus_some_additional_fields]
was_sunny_during_signing_ceremony = true

type LintCaresAboutWebPKI struct {
    Etsi lint.EtsiEsiContext
}

type LintAlsoCaresAboutWebPKIAndGlobal struct {
    Etsi    lint.EtsiEsiContext
    Global  lint.Global
}

type LintMustBeGoodWeather struct {
    Etsi EtsiEsiContext
    WasSunnyDuringSigningCeremony bool `toml="was_sunny_during_signing_ceremony" comment="It MUST be a nice day"`
}

Lints receive copies of higher scoped configurations (even in the event of embedding a pointer) in order to avoid surprising mutations across many lints.

Live Example
The following example implementation is derived from #619. It serves as real world, and immediate, usecase for these new configuration facilities.
package cabf_br

import (
	"github.com/zmap/zcrypto/x509"
	"github.com/zmap/zlint/v3/lint"
	"github.com/zmap/zlint/v3/util"
)

func init() {
	lint.RegisterLint(&lint.Lint{
		Name:          "e_sub_ca_eku_incompatible_values",
		Description:   "Subordinate CA extkeyUsage: if serverAuth is present, then emailProtection, codeSigning, timeStamping, and anyExtendedKeyUsage MUST NOT be present.",
		Citation:      "BRs: <IP_ADDRESS>",
		Source:        lint.CABFBaselineRequirements,
		EffectiveDate: util.CABFBRs_1_7_1_Date,
		Lint:          NewSubCAEkuIncompatibleValues,
	})
}

type subCAEkuIncompatibleValues struct {
	CrossSignerPEM string `comment:"Section <IP_ADDRESS>: For Cross Certificates that share a Subject Distinguished Name and Subject Public Key with a Root Certificate operated in accordance with these Requirements, this extension MAY be present. If present, this extension SHOULD NOT be marked critical. This extension MUST only contain usages for which the issuing CA has verified the Cross Certificate is authorized to assert. This extension MAY contain the anyExtendedKeyUsage [RFC5280] usage, if the Root Certificate(s) associated with this Cross Certificate are operated by the same organization as the issuing Root Certificate."`
}

func (l *subCAEkuIncompatibleValues) Configure() interface{} {
	return l
}

func NewSubCAEkuIncompatibleValues() lint.LintInterface {
	return &subCAEkuIncompatibleValues{}
}

func (l *subCAEkuIncompatibleValues) CheckApplies(c *x509.Certificate) bool {
	return util.IsSubCA(c) && util.IsExtInCert(c, util.EkuSynOid)
}

func (l *subCAEkuIncompatibleValues) Execute(c *x509.Certificate) *lint.LintResult {
	// Check if l.CrossSigner was provided.
	// Parse to cert.
	// Do appropriate checks against section <IP_ADDRESS>
	...
}

This structure generates the following configuration.
[e_sub_ca_eku_incompatible_values]
# Section <IP_ADDRESS>:  For Cross Certificates that share a Subject Distinguished Name and Subject Public Key with a Root Certificate operated in accordance with these Requirements, this extension MAY be present. If present, this extension SHOULD NOT be marked critical. This extension MUST only contain usages for which the issuing CA has verified the Cross Certificate is authorized to assert. This extension MAY contain the anyExtendedKeyUsage [RFC5280] usage, if the Root Certificate(s) associated with this Cross Certificate are operated by the same organization as the issuing Root Certificate.
CrossSignerPEM = ""

With the cross signer certificate filled in...
[e_sub_ca_eku_incompatible_values]
CrossSignerPEM = """
-----BEGIN CERTIFICATE-----
MIIBBDCBrKADAgECAgEBMAoGCCqGSM49BAMCMAAwIhgPMDAwMTAxMDEwMDAwMDBa
GA85OTk4MTEzMDAwMDAwMFowADBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABDaq
E7tJ1D0lKPlIYcMylZ47WsEAFypRlBVUni+Q8ZY4S+NPVHFDxpZ/Qzx8qnXmHvf6
8caqXJthylrSzH1HVGGjEzARMA8GA1UdEwEB/wQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgJklSU+eEIOc+oUHa/ugiNsBpTsrrrJudXuZ41hayNQsCIEwxc3quig63
ZI7LhYni7wlyXJBiXUlQkuacCGdqkv+/
-----END CERTIFICATE-----
"""

Example CLI Usages
Retrieving an Example Configuration
$ ./zlint -exampleConfig > config.toml
$ cat config.toml
[e_sub_ca_eku_incompatible_values]
CrossSignerPEM = ""

Running Against a Configuration.
$ cat >> config.toml << EOF
[e_sub_ca_eku_incompatible_values]
CrossSignerPEM = """
-----BEGIN CERTIFICATE-----
MIIBBDCBrKADAgECAgEBMAoGCCqGSM49BAMCMAAwIhgPMDAwMTAxMDEwMDAwMDBa
GA85OTk4MTEzMDAwMDAwMFowADBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABDaq
E7tJ1D0lKPlIYcMylZ47WsEAFypRlBVUni+Q8ZY4S+NPVHFDxpZ/Qzx8qnXmHvf6
8caqXJthylrSzH1HVGGjEzARMA8GA1UdEwEB/wQFMAMBAf8wCgYIKoZIzj0EAwID
RwAwRAIgJklSU+eEIOc+oUHa/ugiNsBpTsrrrJudXuZ41hayNQsCIEwxc3quig63
ZI7LhYni7wlyXJBiXUlQkuacCGdqkv+/
-----END CERTIFICATE-----
"""
EOF
$ ./zlint -config config.toml /path/to/cert/to/lint

Testing
The linting test package provides the convenience function test.TestLint(lintName string, testCertFilename string).
func TestCaCommonNameNotMissing(t *testing.T) {
	inputPath := "caCommonNameNotMissing.pem"
	expected := lint.Pass
	out := test.TestLint("e_ca_common_name_missing", inputPath)
	if out.Status != expected {
		t.Errorf("%s: expected %s, got %s", inputPath, expected, out.Status)
	}
}

In addition to the above, a new facility shall be added that allows for the execution of a test against an arbitrary TOML string - test.TestLintWithCtx(lintName string, testCertFilename string, context string).
func TestCaCommonNameNotMissing22(t *testing.T) {
	inputPath := "caCommonNameNotMissing.pem"
	expected := lint.Pass
	ctx := `
            [e_ca_common_name_missing]
            some_field = true
	`
	out := test.TestLintWithCtx("e_ca_common_name_missing", inputPath, ctx)
	if out.Status != expected {
		t.Errorf("%s: expected %s, got %s", inputPath, expected, out.Status)
	}
}

Choice of TOML
vs. JSON
JSON does not allow for comments in its documents. This alone is the primary disqualifier.
Comments from lint authors to CAs are very important for conveying the purpose and impact of individual fields. Additionally, it is likely that CAs will version control (and possibly even template) their own configurations, in which case it is an attractive proposition that CAs be able to leave comments in their internal configurations  in order to track their own policy decisions.
vs. YAML
YAML allows for comments. However, it is a far richer (and thus far more complex) lanuage than TOML is. It is not uncommon for humans to have difficulty writing and editing YAML by hand.
Should use cases arise such that the complexity of YAML becomes desirable then it may be a consideration for usage.
Noted Dissatisfactions
Long Single Line Comments
Lint authors provide comments in their configurations via the comment:"<text>" Go tag. Unfortunately, Go does not allow for multiline tags nor does it all for usages of const or var strings within tags - all tags must be string literals. This means that, as is, it is very likely that majority of comments are going to break code style rules simply by being even reasonably descriptive. This is seen immediately in the example provided in Live Example.
There may be remediation to this. One is to have an implicit, reflective, interface.

Find all public fields within the struct.
For every public field, attempt to find a public method named <Field>Comment that returns a string.

type MyLint struct {
    CrossSigner string
}

func CrossSignerComment() string {
    return `
For Cross Certificates that share a Subject Distinguished Name and
Subject Public Key with a Root Certificate operated in accordance
with these Requirements, this extension MAY be present. If present,
this extension SHOULD NOT be marked critical. This extension MUST
only contain usages for which the issuing CA has verified the
Cross Certificate is authorized to assert. This extension MAY contain
the anyExtendedKeyUsage [RFC5280] usage, if the Root Certificate(s)
associated with this Cross Certificate are operated by the same
organization as the issuing Root Certificate.
`
}

However, spike work has not yet been done on accomplishing an interface such as this. As such it is not yet known how conducive our TOML framework would be towards being extended in such a way.
Manual Certificate Parsing
The TOML serde framework does not have a notion of x509 certificates and, as such, lint authors are backed into the wall of declaring string
fields and documenting that they MUST be properly formatted PEMs and then do the parsing and error handling themselves. This is seen in the Live Example.
Possible remediations include:

Providing a shim struct that both knows how to deserialize from TOML and how to convert itself into a *x509.Certificate.

type MyLint struct {
    CrossSigner *TomlCertificate
}

func (m *MyLint) Execute() {
    var cert *x509.Certificate = m.CrossSigner.GetCertificate()
}

Provide utils facilites.

type MyLint struct {
    CrossSigner string
}

func (m *MyLint) Execute() {
    var cert *x509.Certificate = utils.CertificateFromToml(m.CrossSigner)
}

Just ACKing that I have seen it, I feel bad for not having meaningfully commented yet, and that I'm still noodling this (in part, to think of counterfactuals or edge cases to sort through)

It's good @sleevi, there's a fair amount here. And regardless I wanted to figure out that the "higher scoped configurations" problem was at least technically feasible without being too filthy with reflection. I think I have some reasonable enough code local that I'm comfortable pitching the idea as something that can actually be delivered reasonably well.

Howdy folks @sleevi @cpu @robplee @zakird. I've reached a point where I have enough of a complete working example on my local of the above proposal that I am comfortable in taking the [WIP] tag away and discussing concrete details and alternatives.
My goal is for this to be a non-breaking change, however it is a large change with user impact for both consumers of the CLI tool as well as lint authors. As such, I am eyeing getting this proposal out onto the mailing list by the end of the month so that I may solicit UX feedback from the community'/s stakeholders. I would appreciate a quick scan for anything that is glaringly bad or obtuse before doing so.

@christopher-henderson Thanks for the long - and detailed - comment on the design!
I'll be honest, I'm not too familiar with the Go idioms to be able to usefully comment on the implementation strategy, so this may feel a bit of 'high level' feedback without much concrete actionable, directed change. I definitely think getting feedback from CAs is useful, and I think the most useful feedback from them is from the sort of ergonomic example you mentioned re: #619 . In the W3C, we use the term for this of explainers, to sort of capture "problems to solve" / "possible shapes of solution" and use that to iterate on the understanding, before drilling down into the implementation details.
To the topic of ergonomics, I think we should look at existing CA software, to see how it's likely integrated. Far and away, the most common CA software implementation seems to be EJBCA in some variation. EJBCA has a configuration known as post-processing validators. Validators can be configured either for all certificates issued from a given CA, or only for particular certificates for a given profile.
So when we think about something like #619, it's likely to imagine that there is a "Subordinate CA Certificate" profile existing under the Root Certificate. And this profile will be used for multiple sub-CAs. As such, I'm a little concerned that a lint design like that outlined would be difficult - you wouldn't want to create a configuration-per-cert you're issuing, but instead want something dynamic. For example, for this lint to be useful, we'd probably want something like a filename of "all (existing) sub-CAs", such that CheckApplies and friends can open the file, and see if any certificates match the subject / issuer, and apply rules from there.
This suggests that we need a signal mechanism for invalid configurations - e.g. what if the file can't be loaded? But, naively, the design I suggest above also seems to have a problem: it fails open (i.e. if no matching certificate is found, it assumes it's not cross-signed) rather than fails closed (i.e. requires explicit confirmation/manual review that the condition holds).
Iterating on that design, then, it seems like a lint for #619 would say require that the configuration for this lint might be a list of (encoded) DNs, and an affirmative statement by the CA as to which state the DN is in (i.e. "This DN is not cross-certified" vs "This DN is cross-certified"). Any attempt to issue a new DN would cause the lint to fail (for a non-allowlisted DN), which would then prompt a manual review, and a manual reconfiguration of the lint, to explicitly state which it was.
For something like #491 , though, we might do something similar to what you proposed: for example, because we assume responders will only be for the CAs own certificate, have a file that contains every CA certificate from a given CA organization, and then the idea being the responder-validating lint could look up in that file to see all the issuers that match, see if any have the serverAuth bit, and determine from there.
Taking a step back, then, from these detailed cases, I guess my questions are:

Do we have a way to good way signal configuration validation errors? Especially with semantic concepts like "certificates we can parse" or "files on the filesystem that we need to open"
Is this current configuration optimized for "per-certificate invocation" (as the real world example read), or am I right in reading that it's flexible enough for the EJBCA-like configuration of "All certificates from this CA" and/or "All certificates according to this CA profile"?

Thank you @sleevi! The Explainers...explanation...seems like it'll be useful, even in general. As in, it's just a good way to speak with other people.

Do we have a way to good way signal configuration validation errors?

It sounds like you are referring to semantic validation, right? As in, yeah, you gave me a file path, but I'm telling you it's just not there? In that case, I reckon that if the lint in question has taken on the burden of opening files (which, at this point, it would have to without putting in significantly more work on the surrounding infrastructure) that it can signal such a semantic failure from within its Execute method via lint.Fatal.
That is, we have the following lint statuses available to us:
const (
	// Unused / unset LintStatus
	Reserved LintStatus = 0

	// Not Applicable
	NA LintStatus = 1

	// Not Effective
	NE LintStatus = 2

	Pass   LintStatus = 3
	Notice LintStatus = 4
	Warn   LintStatus = 5
	Error  LintStatus = 6
	Fatal  LintStatus = 7
)

Of which I believe Fatal is intended for exactly this sort of thing (if not, then we can always add more).
type MyLint struct {
    config MyConfiguration
}

type MyConfiguration struct {
    subordinate string
}

func (l *MyLint) Execute(cert *x509.Certificate) {
    bytes, err := ioutil.ReadAll(l.config.subordinate)
    if err != nil {
        return &lint.LintResult{Status: lint.Fatal, Details: "I don't think so, Tim"}
    }
}

This could extend out to pretty much any ad-hoc validation error that could occur (parse failures, certificates that appear to be completely unrelated to the lint, stringly typed validation errors, and so on).

Is this current configuration optimized for "per-certificate invocation" (as the real world example read), or am I right in reading that it's flexible enough for the EJBCA-like configuration of "All certificates from this CA" and/or "All certificates according to this CA profile"?

In my mind, it would be easy enough to build configurations that can apply to a whole cache of certificates.
[some_lint]
web_pki =  false

[some_lint]
web_pki =  true

.
└── certs
    ├── internal_pki
    │   ├── cert1.crt
    │   ├── cert2.crt
    │   ├── cert3.crt
    │   └── config.toml <--- web_pki = false
    └── web_pki
        ├── cert1.crt
        ├── cert2.crt
        ├── cert3.crt
        └── config.toml <--- web_pki = true

You can even express hierarchies by concatenating/merging TOML documents. Let's take the following where some certs are intended for the web PKI but are not cross signed, and some certs are both intended for the web PKI and are cross signed.
.
└── certs
    └── web_pki
        ├── cert1.crt
        ├── cert2.crt
        ├── cert3.crt
        ├── config.toml
        └── cross_signed
            ├── cert1.crt
            ├── cert2.crt
            ├── cert3.crt
            └── config.toml

Let's say that certs/web_pki/config.toml is the following:
[some_lint]
web_pki = true

..and that certs/web_pki/cross_signed/config.toml is the following:
[some_other_lint]
cross_signed_by = "/path/to/cert.crt"

Well, the simple concatenation of those two config files is itself a valid config file.
[some_lint]
web_pki = true
[some_other_lint]
cross_signed_by = "/path/to/cert.crt"

In that way you can achieve a hierarchy through some simple bash scripting.
MERGED=$(mktemp)
cat web_pki/config.toml web_pki/cross_signed/config.toml > "${MERGED}"
for cert in web_pki/cross_signed/*.crt; do
    zlint --config "${MERGED}" "${cert}"
done

Alternatively, zlint can always take in a list of configurations and merge them internally.
zlint --configList confg1.toml,config2.toml,config3.toml cert.crt

It sounds like you are referring to semantic validation, right? As in, yeah,
you gave me a file path, but I'm telling you it's just not there?

Yes. Just trying to think of the ergonomics for how misconfiguration is
signaled, and minimizing the risk of “fail open” implementation errors. I
suppose dozens of lints failing is a useful signal.
func (l *MyLint) Execute(cert *x509.Certificate) {

bytes, err := ioutil.ReadAll(l.config.subordinate)

if err != nil {

    return &lint.LintResult{Status: lint.Fatal, Details: "I don't think so, Tim"}

}

}
Right; the alternative is an explicit method (like Configure or Validate)
that checks that. Not saying I’m opposed, just making sure to discuss the
design and make sure we’re not overlooking anything.

In my mind, it would be easy enough to build configurations that can apply
to a whole cache of certificates.

Is this the right way to be thinking about how linting works? That is, our
two main use cases for linting are CAs doing pre-issuance lints and
observers doing post-issuance lints.
I mentioned the EJBCA design, to make sure we’ve got the right mental model
here: issuance profiles, which are associated with “logical” CAs, and each
logical CA may have many CA certificates (with the same Subject/SPKI).
We have lints configured for all certificates from a given CA, and lints
that may be associated with a given profile. Linters are generally
configured via command-line parameters.
The filesystem layout approach seems very error prone, and implicit
configuration (the existence or absence of a file) rather than explicit
configuration.

Well, the simple concatenation of those two config files is itself a valid
config file.
[some_lint]
web_pki = true
[some_other_lint]
cross_signed_by = "/path/to/cert.crt"
This seems like a dangerous design pattern - for example, if I concatenate
two files, one with web_pki = true, with web_pki = false, the behavior
there is going to determine on the order of concatenation, as well as
whether or not it uses first or last value. JSON libraries at least have
this problem in spades - I would be shocked if TOML doesn’t as well.

Alternatively, zlint can always take in a list of configurations and merge

them internally.
zlint --configList confg1.toml,config2.toml,config3.toml cert.crt
Yeah, my gut is either we explicitly support multiple configurations,
which means defining things predictably (and presumably, the ability to
dump/debug the logical view), or we just KISS and say you need to merge all
of this beforehand.

I’d be useful to hear from some of the CAs if they have a preference. I
lean towards KISS, even though it does mean greater work for CAs to
reconfigure lints; hopefully they have good processes in place by now for
that.

Is this the right way to be thinking about how linting works? That is, our
two main use cases for linting are CAs doing pre-issuance lints and
observers doing post-issuance lints.

Well perhaps change the word cache to class and that might help. As in, this is the configuration we use for all new issuances of <some category>.

or we just KISS and say you need to merge all of this beforehand.

You are absolutely right in that duplicate keys/sections become very difficult to reason with regard to which one would take affect. If I were using this system I would do what you mention, which seems to be simply writing your different configuration files for different classes of certs, be done with it, and go on vacation. I suppose that I was trying to show was that operators could get clever with this should they find the need, although I would not necessarily recommend doing so.


Generate ros model from components data struct

fixes https://github.com/ipa320/rosgraph_monitor/issues/13

@ipa-hsd please review https://github.com/ipa-hsd/rosgraph_monitor/pull/1 and https://github.com/ipa-hsd/ros_model_parser/pull/1 , it will be great if we can merge together all the fixes.


mc: 4.8.20 -> 4.8.21

Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg  build mc

Success on x86_64-linux (full log)
Attempted: mc
Partial log (click to expand)
/nix/store/vl7dbwkq8ncvjpm4fnynrfj6jvhrdhlf-mc-4.8.21/libexec/mc/ext.d/image.sh: interpreter directive changed from "/bin/sh" to "/nix/store/qckzjk3406va7h6s40cy9s75z2w715rq-bash-4.4-p19/bin/sh"
/nix/store/vl7dbwkq8ncvjpm4fnynrfj6jvhrdhlf-mc-4.8.21/libexec/mc/ext.d/package.sh: interpreter directive changed from "/bin/sh" to "/nix/store/qckzjk3406va7h6s40cy9s75z2w715rq-bash-4.4-p19/bin/sh"
/nix/store/vl7dbwkq8ncvjpm4fnynrfj6jvhrdhlf-mc-4.8.21/libexec/mc/ext.d/sound.sh: interpreter directive changed from "/bin/sh" to "/nix/store/qckzjk3406va7h6s40cy9s75z2w715rq-bash-4.4-p19/bin/sh"
/nix/store/vl7dbwkq8ncvjpm4fnynrfj6jvhrdhlf-mc-4.8.21/libexec/mc/ext.d/video.sh: interpreter directive changed from "/bin/sh" to "/nix/store/qckzjk3406va7h6s40cy9s75z2w715rq-bash-4.4-p19/bin/sh"
/nix/store/vl7dbwkq8ncvjpm4fnynrfj6jvhrdhlf-mc-4.8.21/libexec/mc/ext.d/doc.sh: interpreter directive changed from "/bin/sh" to "/nix/store/qckzjk3406va7h6s40cy9s75z2w715rq-bash-4.4-p19/bin/sh"
/nix/store/vl7dbwkq8ncvjpm4fnynrfj6jvhrdhlf-mc-4.8.21/libexec/mc/ext.d/misc.sh: interpreter directive changed from "/bin/sh" to "/nix/store/qckzjk3406va7h6s40cy9s75z2w715rq-bash-4.4-p19/bin/sh"
/nix/store/vl7dbwkq8ncvjpm4fnynrfj6jvhrdhlf-mc-4.8.21/libexec/mc/ext.d/text.sh: interpreter directive changed from "/bin/sh" to "/nix/store/qckzjk3406va7h6s40cy9s75z2w715rq-bash-4.4-p19/bin/sh"
/nix/store/vl7dbwkq8ncvjpm4fnynrfj6jvhrdhlf-mc-4.8.21/libexec/mc/ext.d/web.sh: interpreter directive changed from "/bin/sh" to "/nix/store/qckzjk3406va7h6s40cy9s75z2w715rq-bash-4.4-p19/bin/sh"
/nix/store/vl7dbwkq8ncvjpm4fnynrfj6jvhrdhlf-mc-4.8.21/etc/mc/edit.indent.rc: interpreter directive changed from " /bin/sh" to "/nix/store/qckzjk3406va7h6s40cy9s75z2w715rq-bash-4.4-p19/bin/sh"
checking for references to /build in /nix/store/vl7dbwkq8ncvjpm4fnynrfj6jvhrdhlf-mc-4.8.21...

Success on aarch64-linux (full log)
Attempted: mc
Partial log (click to expand)
/nix/store/8j792gmdiv0xvriw4yrj8p7llaj7fw3b-mc-4.8.21/libexec/mc/extfs.d/audio: interpreter directive changed from " /bin/sh" to "/nix/store/9rv2bzx7jz6wjbaxij5qq580qvzksj4i-bash-4.4-p19/bin/sh"
/nix/store/8j792gmdiv0xvriw4yrj8p7llaj7fw3b-mc-4.8.21/libexec/mc/extfs.d/u7z: interpreter directive changed from " /bin/sh" to "/nix/store/9rv2bzx7jz6wjbaxij5qq580qvzksj4i-bash-4.4-p19/bin/sh"
/nix/store/8j792gmdiv0xvriw4yrj8p7llaj7fw3b-mc-4.8.21/libexec/mc/extfs.d/trpm: interpreter directive changed from " /bin/sh" to "/nix/store/9rv2bzx7jz6wjbaxij5qq580qvzksj4i-bash-4.4-p19/bin/sh"
/nix/store/8j792gmdiv0xvriw4yrj8p7llaj7fw3b-mc-4.8.21/libexec/mc/extfs.d/rpm: interpreter directive changed from " /bin/sh" to "/nix/store/9rv2bzx7jz6wjbaxij5qq580qvzksj4i-bash-4.4-p19/bin/sh"
/nix/store/8j792gmdiv0xvriw4yrj8p7llaj7fw3b-mc-4.8.21/libexec/mc/extfs.d/patchsetfs: interpreter directive changed from "/bin/sh" to "/nix/store/9rv2bzx7jz6wjbaxij5qq580qvzksj4i-bash-4.4-p19/bin/sh"
/nix/store/8j792gmdiv0xvriw4yrj8p7llaj7fw3b-mc-4.8.21/libexec/mc/extfs.d/gitfs+: interpreter directive changed from "/bin/sh" to "/nix/store/9rv2bzx7jz6wjbaxij5qq580qvzksj4i-bash-4.4-p19/bin/sh"
/nix/store/8j792gmdiv0xvriw4yrj8p7llaj7fw3b-mc-4.8.21/libexec/mc/extfs.d/changesetfs: interpreter directive changed from "/bin/sh" to "/nix/store/9rv2bzx7jz6wjbaxij5qq580qvzksj4i-bash-4.4-p19/bin/sh"
/nix/store/8j792gmdiv0xvriw4yrj8p7llaj7fw3b-mc-4.8.21/libexec/mc/extfs.d/bpp: interpreter directive changed from " /bin/sh" to "/nix/store/9rv2bzx7jz6wjbaxij5qq580qvzksj4i-bash-4.4-p19/bin/sh"
checking for references to /build in /nix/store/8j792gmdiv0xvriw4yrj8p7llaj7fw3b-mc-4.8.21...
/nix/store/8j792gmdiv0xvriw4yrj8p7llaj7fw3b-mc-4.8.21

Success on x86_64-darwin (full log)
Attempted: mc
Partial log (click to expand)
/nix/store/1mpndn6nz1b2wsbs4ii2i8lfcyp0g707-mc-4.8.21/libexec/mc/extfs.d/uarj: interpreter directive changed from " /bin/sh" to "/nix/store/9gghkkqhn6v7dvpf2319qvrxkkw03vwr-bash-4.4-p19/bin/sh"
/nix/store/1mpndn6nz1b2wsbs4ii2i8lfcyp0g707-mc-4.8.21/libexec/mc/extfs.d/u7z: interpreter directive changed from " /bin/sh" to "/nix/store/9gghkkqhn6v7dvpf2319qvrxkkw03vwr-bash-4.4-p19/bin/sh"
/nix/store/1mpndn6nz1b2wsbs4ii2i8lfcyp0g707-mc-4.8.21/libexec/mc/extfs.d/uarc: interpreter directive changed from " /bin/sh" to "/nix/store/9gghkkqhn6v7dvpf2319qvrxkkw03vwr-bash-4.4-p19/bin/sh"
/nix/store/1mpndn6nz1b2wsbs4ii2i8lfcyp0g707-mc-4.8.21/libexec/mc/extfs.d/iso9660: interpreter directive changed from " /bin/sh" to "/nix/store/9gghkkqhn6v7dvpf2319qvrxkkw03vwr-bash-4.4-p19/bin/sh"
/nix/store/1mpndn6nz1b2wsbs4ii2i8lfcyp0g707-mc-4.8.21/libexec/mc/extfs.d/gitfs+: interpreter directive changed from "/bin/sh" to "/nix/store/9gghkkqhn6v7dvpf2319qvrxkkw03vwr-bash-4.4-p19/bin/sh"
/nix/store/1mpndn6nz1b2wsbs4ii2i8lfcyp0g707-mc-4.8.21/libexec/mc/extfs.d/audio: interpreter directive changed from " /bin/sh" to "/nix/store/9gghkkqhn6v7dvpf2319qvrxkkw03vwr-bash-4.4-p19/bin/sh"
/nix/store/1mpndn6nz1b2wsbs4ii2i8lfcyp0g707-mc-4.8.21/libexec/mc/extfs.d/urar: interpreter directive changed from " /bin/sh" to "/nix/store/9gghkkqhn6v7dvpf2319qvrxkkw03vwr-bash-4.4-p19/bin/sh"
/nix/store/1mpndn6nz1b2wsbs4ii2i8lfcyp0g707-mc-4.8.21/libexec/mc/extfs.d/rpm: interpreter directive changed from " /bin/sh" to "/nix/store/9gghkkqhn6v7dvpf2319qvrxkkw03vwr-bash-4.4-p19/bin/sh"
/nix/store/1mpndn6nz1b2wsbs4ii2i8lfcyp0g707-mc-4.8.21/etc/mc/edit.indent.rc: interpreter directive changed from " /bin/sh" to "/nix/store/9gghkkqhn6v7dvpf2319qvrxkkw03vwr-bash-4.4-p19/bin/sh"
/nix/store/1mpndn6nz1b2wsbs4ii2i8lfcyp0g707-mc-4.8.21


Move to pre-draw call handler in DX11

Previous discussion on this was in https://github.com/gfx-rs/gfx/pull/2203#discussion_r199642175
Now that the backend is a bit further along and we use more internal programs to implement features, a problem that has come up quite a bit is state clobbering (overwriting API state). To avoid this we would need to locally cache set state, eg:
push_state();
internal.clear_partial_attachments(...);
pop_state();

There's also a lot of api calls in vulkan that dont map quite as nice to DX, which require some caching until the right state has been set (vertex buffers, skip binding stage resources if pipeline doesn't have stage).
A solution to this would be to have a dirty flag and set the required state at draw calls.
Pros:

Easier/less complex implementation
Less API calls

Cons:

Adds (some) overhead in a high-frequency function

I think the overhead of a dirty flag would be largely offset by the amount of caching and reduction of api calls that it allows for. here is an example of the assembly overhead.

@fkaa note that in Metal backend we still aren't using pre-draw handler. Things seem to be good so far.


How about that scroll?

How about scrolling actually scrolls the graph instead of zooming in and out? Not sure how zoom should be applied though.

@kristiany Isn't that implemented now?

@ashpool I think you can now close this issue.

It's done


findContours returns different results on same image

I have run into the following issue when working with open-cv python library 4.1, on python 3.7 . It might be a bug related to open-cv in general rather than the python library only.

Please report the issue to the upstream OpenCV repository: https://github.com/opencv/opencv/issues
There might be a bug somewhere but it cannot be fixed here since the Python bindings are autogenerated from the C++ code.


Does R.identical() try to fix JavaScript?

When using strings with R.identical() it's documentation is wrong:

Values are identical if they reference the same memory.

Eg. identical individual strings that do not share the same memory (Even so, we could never find that out in JavaScript anyway):
R.identical("TEST".toLocaleLowerCase(), "test") // true

This is because JavaScript's === operator works this way. Which is fine because everybody is familiar with it. 😄
However, looking at it's implementation R.identical() does some things different than the well known === operator:

a
b
R.identical(a, b)
a === b

0
-0
false
true

NaN
NaN
true
false

I fear that that this list may be incomplete and therefore I cannot rely to know what R.identical(() does without every time looking at the implementation. Second I don't want to provide my own isIdentical => (a, b) => a === b for FP style JavaScript.
I'd wish that in the future Ramda's API is not diluted with functions which just try to fix JavaScript and carry unnecessary mental overhead (We already have to tell R.equals, === and == apart). But perhaps R.identical() is a dinosaur from the early days of Ramda and a bad example for Ramda's API.

This does not try to fix JS.  It's duplicating the logic of Object.is.  It's specified by the SameValue algorithm, which is unfortunately different from the SameValueZero one used for object keys.
Granted, the description should be more artfully phrased.  The logic sounds reasonable, though.

Thank you  👍
I did not know that in JavaScript you need something even stricter than === because apparently even that operator is crap. (MDN has a fine equality comparison matrix)
So in summary: R.identical() is simply ES6' Object.is(). (polyfilled because Internet Explorer <= 11 and older node.js' don't have it.)
I am not sure to be glad that the ES6 committee did not pick the quadruple equal ==== operator but instead opted for Object.is() which at one point was supposed to be Object.egal() which is very funny if you are German because egal in German simply means whatever which would be a ridiculous choice for naming an equality operator 🙈


update all dockcross scripts via dockcross-xxx update

Dockcross scripts installed locally have been updated using ./docker/dockcross-<xxx> update

Thanks for the update. Merged


Fix: SequencerRepair: wait for patch to apply before validating it.

Signed-off-by: Javier Ron<EMAIL_ADDRESS>

LGTM. CI failing?

CI is failing because Sorald's version that is compatible with Java 8 is no longer available in the repository. Same issue as in #1172.

We have a chicken and egg problem. Trying to fix with https://github.com/eclipse/repairnator/pull/1192

Merged #1192, restarted build.

#1192 fixed CI, CI is green here, patch merged, thanks @javierron !


MacOS: Pubspec data not available until after it is needed

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Steps to reproduce
Attempt to access a value defined in Pubspec.yaml in main before runApp.
Expected results
Get the value
I need to get access to the version declared in pubspec.yaml.
The supplied code runs perfectly on Windows.
On MacOS I get the word salad error message.
Actual results
Crash
The "instance" getter on the ServicesBinding binding mixin is only available once that binding has been initialized. Typically, this is done by calling "WidgetsFlutterBinding.ensureInitialized()" or "runApp()" (the latter calls the former). Typically this call is done in the "void main()" method. The "ensureInitialized" method is idempotent; calling it multiple times is not harmful. After calling that method, the "instance" getter will return the binding. In a test, one can call "TestWidgetsFlutterBinding.ensureInitialized()" as the first line in the test's "main()" method to initialize the binding. If ServicesBinding is a custom binding mixin, there must also be a custom binding class, like WidgetsFlutterBinding, but that mixes in the selected binding, and that is the class that must be constructed before using the "instance" getter.)
Code sample
Code sample
clkass MyClass {
  static Future<String> getVersion() async {
    PackageInfo packageInfo = await PackageInfo.fromPlatform();
   return "Version: ${packageInfo.version}";
  }
}
:
:
Future<void> main() async {
   var version = await MyClass.getVersion();
  runApp(const MyApp());

:
:
}

Screenshots or Video

Screenshots / Video demonstration
[Upload media here]

Logs
Logs
[Paste your logs here]

Flutter Doctor output
Doctor output
% flutter doctor -v
[✓] Flutter (Channel stable, 3.13.5, on macOS 13.4 22F66 darwin-arm64, locale en-AU)
    • Flutter version 3.13.5 on channel stable at /Users/user/Documents/Flutter/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 12fccda598 (9 days ago), 2023-09-19 13:56:11 -0700
    • Engine revision bd986c5ed2
    • Dart version 3.1.2
    • DevTools version 2.25.0

[✗] Android toolchain - develop for Android devices
    ✗ Unable to locate Android SDK.
      Install Android Studio from: https://developer.android.com/studio/index.html
      On first launch it will assist you in installing the Android SDK components.
      (or visit https://flutter.dev/docs/get-started/install/macos#android-setup for detailed instructions).
      If the Android SDK has been installed to a custom location, please use
      `flutter config --android-sdk` to update to that location.

[✓] Xcode - develop for iOS and macOS (Xcode 14.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 14E222b
    • CocoaPods version 1.12.1

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

[!] Android Studio (not installed)
    • Android Studio not found; download from https://developer.android.com/studio/index.html
      (or visit https://flutter.dev/docs/get-started/install/macos#android-setup for detailed instructions).

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

[✓] Connected device (3 available)
    • iPad (mobile)   • 00008103-000229CE1E31001E • ios            • iOS 16.6.1 20G81
    • macOS (desktop) • macos                     • darwin-arm64   • macOS 13.4 22F66 darwin-arm64
    • Chrome (web)    • chrome                    • web-javascript • Google Chrome 117.0.5938.88

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

! Doctor found issues in 2 categories.

The supplied code runs perfectly on Windows.

Because the plugin you are calling has completely different implementations on Windows and macOS; the latter uses platform channels, and the former does not.

On MacOS I get the word salad error message.

I'm not sure what about the error message constitutes "word salad"; it explains exactly what the problem is:

The "instance" getter on the ServicesBinding binding mixin is only available once that binding has been initialized. Typically, this is done by calling "WidgetsFlutterBinding.ensureInitialized()" or "runApp()"

You are trying to call a plugin that uses platform channels—and thus ServicesBinding—before runApp() has been called. The solution is to call WidgetsFlutterBinding.ensureInitialized()` first.
Closing as this is not a bug, and there is already a specific and actionable error message. If you have constructive feedback about how to improve the error message, please feel free to file an issue about that.

Because the plugin you are calling has completely different implementations on Windows and macOS; the latter uses platform channels, and the former does not.

This is a bug.
I do not care about plugins, I want to access data defined in a file that is allways there.
I have to jump through special hoops to do that.
It is brain dead.
It is wrong
It is a bug

Because the plugin you are calling has completely different implementations on Windows and macOS; the latter uses platform channels, and the former does not.

This is a bug.

Feel free to report it as such to the developers of package_info_plus, which is a third-party package.

I have struck this again:  The name: field in pubspec.yaml is unavailable at compile time or runtime.
Third party packages, that do not work properly, are not a solution to this.
The issue, the bug, is that the environment that Flutter sets up, that is always present, is unavailable to the programme itself.
As a programmer using this system this is continual sand in the gears.


Add shell check pre commit hook

Checklist

[ ] I have added tests
[ ] I have updated the docs and cheatsheet
[ ] I have not broken the cheatsheet

Likely worth adding a playground exclude for this too, since the playground file from https://github.com/cursorless-dev/cursorless/pull/2058 will probably fire a bunch too


Version 0.4.0

Add support for the following Java 11 JVMs:

AdoptOpenJDK 11
Oracle and OpenJDK 11
SAP Machine 11

Add support for the following Java 8 JVMs:

AdoptOpenJDK 8
Pivotal JVM 8

Also, improve test harness and upgrade Gradle version to support Java 11.

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


Testing: Add E2E project for create-analog

Which scope/s are relevant/related to the feature request?
create-analog
Information
Need an E2E test that ensures create-analog generates a working application. This would help ensure against upgrades with external dependencies like Nx and the @nrwl/vite package.
The E2E test would:

Run the node packages/create-analog/index.js script to generate a new app
Start up the application and run an E2E test against the running app
Maybe have modes for client/ssr mode

Describe any alternatives/workarounds you're currently using
No response
I would be willing to submit a PR to fix this issue

[ ] Yes
[ ] No

I think the nx-plugin-e2e can serve as a blueprint for that. There's a method that allows us to run not just Nx commands!

Yep. We can run direct CLI commands also
 import { ensureDirSync } from 'fs-extra';
 import { runCommand, tmpProjPath } from '@nrwl/nx-plugin';

 ensureDirSync(tmpProjPath());
 runCommand(`yarn create analog test-project`);
 // ...

Fixed in https://github.com/analogjs/analog/pull/478


[BUG] cuML notebooks need to be updated for new numpy API

Describe the bug
PCA_demo, TSVD_demo, and holtwinters_demo_full all should be updated to work with numpy 1.17, or numpy 1.16 with NUMPY_EXPERIMENTAL_ARRAY_FUNCTION=1
(all cudf Series used in these NBs should be converted using something like cudf.series.to_gpu_array() )
Steps/Code to reproduce bug
Run the above notebooks in an environment with numpy 1.17 installed, or numpy 1.16 with NUMPY_EXPERIMENTAL_ARRAY_FUNCTION=1 and observe errors such as:
no implementation found for 'numpy.allclose' on types that implement __array_function__: [<class 'numpy.ndarray'>, <class 'cudf.core.series.Series'>]

Expected behavior
In the same environment, the above error should not be present.
cc @dantegd @cjnolet

I believe this PR should solve these issues #255

@rlratzel ,  can you confirm that PR #255  closes this issue? @Salonijain27

Closing as it seems to have solved it.  Please reopen if anything new crops up!


About training ViT on Market1501

I've trained the transformer-based model as shipped with the code, it seems that there's nothing outperforming the CNN models?  Correct me if I were wrong.
[08/18 15:07:26 fastreid.evaluation.testing]: Evaluation results in csv format:
| Dataset    | Rank-1   | Rank-5   | Rank-10   | mAP   | mINP   | metric   |
|:-----------|:---------|:---------|:----------|:------|:-------|:---------|
| Market1501 | 94.12    | 98.04    | 99.05     | 86.19 | 62.11  | 90.16    |

  | Rank-1 | Rank-5 | Rank-10 | mAP | mINP | metric |
|:-----------|:---------|:---------|:----------|:------|:-------|:---------|
|R50 | 94.45 | 98.16 | 98.78 | 85.08 | 56.78 | 89.76 |
|R50-ibn | 95.07 | 98.37 | 99.05 | 86.82 | 61.06 | 90.94 |
|R101-ibn | 95.58 | 98.43 | 99.08 | 88.20 | 65.34 | 91.89 |
|S50 | 94.77 | 98.31 | 98.99 | 86.91 | 61.27 | 90.84 |
|ViT | 94.12 | 98.04 | 99.09 | 86.19 | 62.11 | 90.16 |

Yes, I also found there is not much gain.

I've trained the transformer-based model as shipped with the code, it seems that there's nothing outperforming the CNN models? Correct me if I were wrong.
[08/18 15:07:26 fastreid.evaluation.testing]: Evaluation results in csv format:
| Dataset    | Rank-1   | Rank-5   | Rank-10   | mAP   | mINP   | metric   |
|:-----------|:---------|:---------|:----------|:------|:-------|:---------|
| Market1501 | 94.12    | 98.04    | 99.05     | 86.19 | 62.11  | 90.16    |

  | Rank-1 | Rank-5 | Rank-10 | mAP | mINP | metric |
|:-----------|:---------|:---------|:----------|:------|:-------|:---------|
|R50 | 94.45 | 98.16 | 98.78 | 85.08 | 56.78 | 89.76 |
|R50-ibn | 95.07 | 98.37 | 99.05 | 86.82 | 61.06 | 90.94 |
|R101-ibn | 95.58 | 98.43 | 99.08 | 88.20 | 65.34 | 91.89 |
|S50 | 94.77 | 98.31 | 98.99 | 86.91 | 61.27 | 90.84 |
|ViT | 94.12 | 98.04 | 99.09 | 86.19 | 62.11 | 90.16 |

could you provide the configuration file for vit?


Added arch exploration files

Architecture exploration files allow FPGA to auto size to design. Updated vpr_arch file and shell scripts.

Should be ready to merge into master now. Should I keep working on this branch for BRAM or merge this and start a new one?


Git Hook for Validating Branch Naming

Find and implement a Git Hook, that can be used inside of pre-commit, to validate the name of a branch during it's creation.

https://www.devwithimagination.com/2020/04/13/git-commit-hooks-for-branch-naming-pre-commit/


Tables: CombiTimeTable with spline interpolation and borderline slopes

Reported by beutlich on 20 Mar 2013 15:27 UTC
Consider the following table model with spline interpolation
model ProblematicAkima
  parameter Real eps=0.1;
  Modelica.Blocks.Sources.CombiTimeTable t_old(
    table=[0+eps,5;1,3;2,1;3,1;4,1;5,3],
    smoothness=Modelica.Blocks.Types.Smoothness.ContinuousDerivative) annotation(Placement(transformation(extent={{-100,60},{-80,80}})));
end ProblematicAkima;

As long as eps is small but greater than zero we get similar curves for the interpolated values. For eps = 0 there is a behavioral changeover of the interpolated values that suddenly result in values less than one for time in (2,3).
Should an alternative variant of the Akima spline interpolation be used that interpolates (for eps = 0) linearly between time in ![1,2] with the drawback of a discontinuous derivative at time = 2?

Migrated-From: https://trac.modelica.org/Modelica/ticket/1039

Comment by otter on 26 Mar 2013 11:13 UTC
This is most likely not the only case where the Akima spline might result in slightly non-intuitive interpolation, since there are no guarantees about monotonic behavior. Therefore, one would have to analyse all possible cases. I would suggest to stick to the pure Akima spline and do not handle the case above specially.
My goal is to make a new call for enhanced table interpolation features once MSL3.2.1 is released. One of the new features should be monotone spline interpolation, such as "Fritsch F.N. and Carlson R.E. (1980): Monotone piecewise cubic interpolation. SIAM J. Numerc. Anal., Vol. 17, No. 2, April 1980, pp. 238-246", which is, e.g., already used in Modelica.Fluid.Utilities.regRoot2 (if table points are monotone, then all interpolated values are also monotone; interpolation is performed with third order polynomials and the first derivative is continuous).

Comment by dietmarw on 26 Mar 2013 19:15 UTC
This is not really fixed and should be kept open until we have a solution.

Comment by otter on 27 Mar 2013 07:30 UTC
The Akima spline will not be changed, it will stay as it is also in the future. Therefore, this ticket should be closed. However, the plan is to introduce another type of interpolation in the future with other properties. However, how this is done should be discussed in the MAP-LIB group and the sketch above is just one option. So, the right way would be to open a new ticket for a future extension. However, I would open a new ticket only after the discussion in the group once all planned extensions for the tables are clarified.

Comment by dietmarw on 27 Mar 2013 11:35 UTC
Still this ticket can not be seen as fixed but rather you decided this is going to be a "wontfix"

Comment by dietmarw on 27 Mar 2013 11:36 UTC
Closing as wontfix since library officer decided to not fix this yet.

Modified by dietmarw on 3 Jun 2013 08:09 UTC

Comment by beutlich on 11 May 2015 18:34 UTC
See #1717 for the enhancement proposed by comment:1.


Uncaught TypeError: Cannot read properties of undefined (reading 'parent')

What is your Scenario?
I have a window that is generated by a ajax call and I keep getting the same problem with hammerhead.js

on testcafe 3.0.1
What is the Current behavior?
test failure
What is the Expected behavior?
test success
What is your public website URL? (or attach your complete example)
test it not public
What is your TestCafe test code?
test is not public
Your complete configuration file
No response
Your complete test report
No response
Screenshots
No response
Steps to Reproduce

generate a window using ajax

TestCafe version
3.0.1
Node.js version
18.16.0
Command-line arguments
testcafe chrome
Browser name(s) and version(s)
chrome 114
Platform(s) and version(s)
windows 10
Other
No response

Hi @gemal,
TestCafe v3.0.0 works with a faster and more stable Native Automation mode by default. We are actively working on this mode, but, currently, it doesn't support multiple windows. You can track updates about supporting the multiple windows in Native Automation mode in this issue: https://github.com/DevExpress/testcafe/issues/7661
As a workaround, I recommend you separate your TestCafe tasks into two:

Use Native Automation for general purposes.
Do not use Native Automation for specific tests that use multiple windows.


build: docker-build with correct version in git worktrees.

When we're docker-building images in a git worktree, version detection (which uses git-describe in the end) does not work correctly, since inside the docker build context .git refers to a non-existent git repo directory. Therefore pass version info to docker-build as build args.

I'm not sure I understand what is being fixed. Currently when running make, binaries get tagged correctly with the correct BuildID and even after the change it is still the same. Before: (version v0.4.0-24-gbef4f46, build bef4f46)

Yes, if you build from your main cloned repo... But if you build from a worktree (which in my workflow is 99.9% of cases) version detection does not work in the docker build. And you can easily see why if you do a cat .git in a worktree then look at any of cmd/plugins/*/Dockerfile (worktree gets copied into build context, main repo not`).
Try first without this patch git worktree add ../test; cd ../test; make images then try it again with this patch in place...


ThreadLocals not cleared with Hooks.enableAutomaticContextPropagation(), same TraceId for every request

I originally opened this issue in reactor: reactor/reactor-core#3584, but it turned out that this is an issue in micrometer-tracing instead.
Worked in: 1.1.4
Broken in: 1.1.5, 1.1.6-SNAPSHOT, 1.2.0-SNAPSHOT
Also related: #356

Expected Behavior
Automatic context propagation (enabled with Hooks.enableAutomaticContextPropagation()) should clear the thread-locals afterwards.
Actual Behavior
After the first request handled by a particular thread, every subsequent request handled by that thread will reuse the same traceId.
Steps to Reproduce
Demo project: reproducer.zip
@SpringBootApplication
public class Demo1Application {

    public static void main(String[] args) {
        System.setProperty("reactor.netty.ioWorkerCount", "1");
        Hooks.enableAutomaticContextPropagation();
        SpringApplication.run(Demo1Application.class, args);
    }

}

@RestController
@RequiredArgsConstructor
class MyController {

    private final Tracer tracer;

    @GetMapping("/")
    public String traceId() {
        return Thread.currentThread().getName() + '-' + tracer.currentSpan().context().traceId();
    }

}

Run it and issue a few requests to localhost:8080, the output will be something like this:
With reactor.netty.ioWorkerCount=1:
C:\>curl localhost:8080
reactor-http-nio-1-65102dd571ea1cb67a25a401c93412b0
C:\>curl localhost:8080
reactor-http-nio-1-65102dd571ea1cb67a25a401c93412b0
C:\>curl localhost:8080
reactor-http-nio-1-65102dd571ea1cb67a25a401c93412b0
C:\>curl localhost:8080
reactor-http-nio-1-65102dd571ea1cb67a25a401c93412b0
C:\>curl localhost:8080
reactor-http-nio-1-65102dd571ea1cb67a25a401c93412b0
C:\>curl localhost:8080
reactor-http-nio-1-65102dd571ea1cb67a25a401c93412b0

With reactor.netty.ioWorkerCount=2:
C:\>curl localhost:8080
reactor-http-nio-1-65102d16b3d992cb7131386bf683cd9e
C:\>curl localhost:8080
reactor-http-nio-2-65102d0dc6d2b48f307d67a6db6fde3a
C:\>curl localhost:8080
reactor-http-nio-1-65102d16b3d992cb7131386bf683cd9e
C:\>curl localhost:8080
reactor-http-nio-2-65102d0dc6d2b48f307d67a6db6fde3a
C:\>curl localhost:8080
reactor-http-nio-1-65102d16b3d992cb7131386bf683cd9e
C:\>curl localhost:8080
reactor-http-nio-2-65102d0dc6d2b48f307d67a6db6fde3a

With reactor.netty.ioWorkerCount=3:
C:\>curl localhost:8080
reactor-http-nio-2-65102dfc81d58e1d99c2f64353b410a6
C:\>curl localhost:8080
reactor-http-nio-3-65102dfc7b1ff1d38702f4b2e4cb94a6
C:\>curl localhost:8080
reactor-http-nio-1-65102dfde7c20d2604248dd885469458
C:\>curl localhost:8080
reactor-http-nio-2-65102dfc81d58e1d99c2f64353b410a6
C:\>curl localhost:8080
reactor-http-nio-3-65102dfc7b1ff1d38702f4b2e4cb94a6
C:\>curl localhost:8080
reactor-http-nio-1-65102dfde7c20d2604248dd885469458

As we can see, requests handled by a thread will always reuse the same traceId, indicating that thread-locals popuplated by automatic context propagation are not cleared/reset after each request.
Without automatic context propagation, tracer.currentSpan() returns null.
Your Environment

Reactor version(s) used: 3.5.10
Other relevant libraries versions (eg. netty, ...):

Spring Boot 3.1.4
Spring Framework 6.0.12
Micrometer Tracing: 1.1.5 (Also broken in 1.1.6-SNAPSHOT, 1.2.0-SNAPSHOT)
Micrometer Observation: 1.11.4

JVM version (java -version):

openjdk version "<IP_ADDRESS>" 2023-08-24
OpenJDK Runtime Environment Temurin-<IP_ADDRESS>+1 (build <IP_ADDRESS>+1)
OpenJDK 64-Bit Server VM Temurin-<IP_ADDRESS>+1 (build <IP_ADDRESS>+1, mixed mode, sharing)

I think I am also hitting this issue after upgrading to SB 3.1.4 (Micrometer Tracing 1.1.5). The traces for actuator endpoints are using the same trace ID and becoming child traces instead of independent traces.

I might faceing a similar issue. i'm using spring boot 3.1.4 and micrometer-tracing 1.1.5. The context propagation for org.springframework.web.reactive.function.client.WebClient header values seems to work but not for mdc (BaggageField)  values.

Fixed via https://github.com/micrometer-metrics/tracing/commit/5a750bbe644398fc5c4d5700b7c9c02b49acaa73

Looking at the commit that resolved this, it doesn't appear there's anything preventing a regression like this from sneaking back in.
As this is quite a fundamental thing, could you ensure it's properly tested?

Yes, we should definitely do that. I've opened #397 to track it. Pull requests welcome.

I think I am also hitting this issue after upgrading to SB 3.1.4 (Micrometer Tracing 1.1.5). The traces for actuator endpoints are using the same trace ID and becoming child traces instead of independent traces.

Think I am also seeing this: https://github.com/micrometer-metrics/tracing/issues/410

@vpavic #421 is my proposed test for this case. @shakuzen @jonatan-ivanov I tested it against 1.1.5 and it fails due to the scope invalidation following an Observation stop signal.

Thanks for the ping @chemicL.
Test case in your PR is focused on Reactor scenario, and while this issue also is, the root cause behind it really isn't tied to Reactor and it affected a broader set of users (we're not using Reactor in any of our projects).
Not a critique of your PR by any means just an observation that the tests covering this should probably also include something that's not specific to a certain runtime.

@vpavic understood :) The interesting thing about it is the unique setup which reactor creates with the support for context propagation that we introduced. It was hard to replicate without the reactor in the equation, yet not impossible. Have you experienced this bug without reactor? I'd argue here that using reactor is both a means to an end – creating an environment in which we can reliably replicate the issue, and a validation that where the bug has surfaced is also covered by the tests.
If you have an idea that avoids using reactor in the test for this feature, I think it would be valuable to add.

this is happing without reactor too. for me this is happing when I createBaggageInScope,
Thank you
`        Span span = this.tracer.nextSpan();
try (Tracer.SpanInScope ws = this.tracer.withSpan(span.start())) {
try (BaggageInScope baggage = this.tracer.createBaggageInScope("mybaggage", "my-baggage-value")) {
        }
    }
    finally {
        span.end();
    }
        }
    }
    finally {
        span.end();
    } `


Update readme, add instructions for payment permit locally

This PR doesn't resolve an existing issue.
This PR does the following:

update outdated instructions in the readme file
add a manual method to setup payment permits and private keys related to it for a local instance of ubiquibot

Why didn't I add an automatic method?
It appears the automatic method https://pay.ubq.fi/onboarding is for clients who are using an official instance of ubiquibot. Because it doesn't provide x25519_PRIVATE_KEY for the encrypted private key which is needed in a local instance.
QA-part1: https://github.com/web4er/ubiquibot/issues/79
QA-part2: https://github.com/web4er/ubiquibot/issues/78

It appears the automatic method https://pay.ubq.fi/onboarding is for clients who are using an official instance of ubiquibot. Because it doesn't provide x25519_PRIVATE_KEY for the encrypted private key which is needed in a local instance.

Exactly

I have made the required changes. This PR is ready for a new review. @pavlovcik @whilefoo

Need to approve this if you think your concerns have been addressed. @whilefoo @pavlovcik

@rndquu please approve this PR so that it can be merged.


Incorrect displaying long chips on a mobile device

There is a problem with displaying long chips on a mobile device.
Good situation when we use a the tablet, for ex. iPad Pro.

But if we use for ex. iPhone 5/6 we have a trouble.

Long text wraps to a second line.
Therefore, I propose the following solution: you can crop the text to fit into the screen size. Put "..." at the end of the text and display the full text on hover.

This problem is old, but it still exists in version 1.0.0 beta,
The following solution works well for me in this version.
.chip { position:relative;padding-right:36px;border-collapse:collapse;white-space:nowrap;overflow:hidden;text-overflow:ellipsis; }
.chip .close { position:absolute;top:0;right:0;padding:0 8px }
@media only screen and (min-width:992px) {
    .chip { overflow:inherit }
}


2 instalar akka criar hello world com akka e scala

added Akka Actor dependency
implemented a simple "greeter" actor, proving that akka is working

This last commit added a simple functionality to the GreeterActor, logging that the App is being started.

added com.typesafe.config dependency
added app.version and boot.message in application.conf


False positive testnet address detection

Is this in prod? I thought we discussed not showing these notifications this way? If so I guess I'll just open a new ticket with my suggestion.

Is this in prod? I thought we discussed not showing these notifications this way? If so I guess I'll just open a new ticket with my suggestion.

This false positive behavior has been resolved, closing issue. @jeffdomke if you have suggestions, please do open a new ticket.

This false positive behavior has been resolved, closing issue. @jeffdomke if you have suggestions, please do open a new ticket.


Update dependencies to the latest releases (+preview=in)

CC @wilzbach , if I can also get a tag for this it'd be great :)

Also wanted to clear up the deprecations, but went down the rabbit hole, and it led me back to DMD.

CC @wilzbach , if I can also get a tag for this it'd be great :)

https://github.com/rejectedsoftware/ddox/releases/tag/v0.16.17

Also wanted to clear up the deprecations, but went down the rabbit hole, and it led me back to DMD.

Yikes.  At least open an issue in Bugzilla, s.t. it's not entirely lost in abyss?

Thanks! Regarding the bug I'll give it 24 hours to be discussed and then bring it to Bugzilla


CP Chat can't see any code

Type: Bug
GH Copilot Chat doesn't seem to be able to see my code in this workspace. I was using it earlier today on another workspace without a problem.
Steps:

open workspace
select code
open chat
type '@workspace / explain' and hit enter
CP shows "Used 1 reference: main.ts:1-638"
CP responds "I'm sorry, but there seems to be a misunderstanding. I can't see any code in your message. Could you please provide the code you want me to explain?"

this is a TS file, just like the other workspace that works
the selected file is not in .gitignore nor in .copilotignore

Extension version: 0.13.0
VS Code version: Code 1.87.0 (019f4d1419fbc8219a181fab7892ebccf7ee29a2, 2024-02-27T23:42:51.279Z)
OS version: Darwin arm64 23.3.0
Modes:

System Info

Item
Value

CPUs
Apple M1 Pro (8 x 24)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: enabled_ondirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_graphite: disabled_offvideo_decode: enabledvideo_encode: enabledwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
2, 3, 3

Memory (System)
16.00GB (0.08GB free)

Process Argv
--crash-reporter-id e4cf1f20-48ac-4d23-8cff-ed9de6772c2b

Screen Reader
no

VM
0%

A/B Experiments
vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscoreces:30445986
vscod805cf:30301675
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:30899288
vscaac:30438847
c4g48928:30535728
azure-dev_surveyone:30548225
962ge761:30959799
pythongtdpath:30769146
welcomedialogc:30910334
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
pythontestfixt:30902429
pythonregdiag2:30936856
pyreplss1:30897532
pythonmypyd1:30879173
pythoncet0:30885854
h48ei257:30968133
pythontbext0:30879054
accentitlementsc:30887149
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
bf62j303:30959262
cppperfcontrol:30979541
d34g3935:30971562
edj9j583:30969295
a89i1917:30973842
dsvsc020:30976470

Seems to work for me. Please share a project and specific selection  in it that causes this to happen

Works for me now too 🤷
On Wed, Mar 20, 2024, 7:29 PM Matt Bierner @.***> wrote:

Seems to work for me. Please share a project and specific selection in it
that causes this to happen
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode-copilot-release/issues/998#issuecomment-2010899077,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD4S4CYZLKZVZ6BWPOPEMUDYZILUBAVCNFSM6AAAAABEF43F3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJQHA4TSMBXG4
.
You are receiving this because you authored the thread.Message ID:
@.***>

I do think that's it. I've encountered it again once or twice now and it
has always been with really large selections/files. Probably just exceeds
the token limit for GPT or something.
On Thu, Apr 11, 2024, 10:26 AM Matthieu-Pesnot-Pin @.***>
wrote:

I had the same issue, in my case it appears the error is occuring when the
selected code - or the file - is too large.
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode-copilot-release/issues/998#issuecomment-2049819623,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD4S4C75MFFMELC7PC5MFKDY42MQJAVCNFSM6AAAAABEF43F3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBZHAYTSNRSGM
.
You are receiving this because you authored the thread.Message ID:
@.***>


add --cleanup flag to helm test cmd

As an option to automatically clean up test pods after test suite completion.  See https://github.com/kubernetes/helm/pull/1777#discussion_r99491030
(Requires https://github.com/kubernetes/helm/pull/1777)

+1 but aside from this, it seems like we should also have a new test run clobber the old completed pod perhaps?
For example, the below result was unexpected:
~/g/s/k/helm (master=) ./bin/helm test quieting-coral
RUNNING: quieting-coral-service-test
ERROR: pods "quieting-coral-service-test" already exists

Or maybe we should have the test pods use some auto-generated name suffix? Thoughts?

@foxish the current plan/implementation in the linked PR (https://github.com/kubernetes/helm/pull/1935) is to enable this functionality explicitly from the user via a flag, e.g. helm test --cleanup <release>.  If it's decided we'd rather have cleanup be the default, it should be a simple change.
As for naming test pods with, say, a random suffix, I believe we've decided to leave that up to the test template author.  For example, something like this should work:
...
metadata:
  name: "{{.Release.Name}}-service-test-{{randAlphaNum 6}}"
...


[Docs] Add MIT license

Adding MIT license to the repo.

@adshmh I'm going to bypass E2E test this one time (to unblock the license) but will be looking into them later today.


fix: make clean work on windows

Fixes #830

[x] npm test succeeds
[x] Pull request has been squashed into 1 commit
[x] I did NOT manually make changes to anything in apis/
[x] Code coverage does not decrease (if any source code was changed)
[x] Appropriate JSDoc comments were updated in source code (if applicable)
[x] Appropriate changes to readme/docs are included in PR

Great catch.  You were totally right.  Verified for real on my windows VM this time.  Also opening a bug to run CI on appveyor ;)


NodeContent as HTML element instead of HTML as string

First of all thanks , it looks great 👍
Describe the solution you'd like
As a developer using org-chart library, I would like to append HTML elements to each node DIV element instead of pure HTML as string.
That is very helpful when working with frameworks such as Angular, React, Vue, Svelte ...  which components can be attached to the chart nodes without missing all the power of the framework.
Describe alternatives you've considered
I found a workaround that allows me to attach an element to each Node DIV Element, it looks like that:
(angular context)
      .nodeContent((node, i, arr, attrs) => {
        const component = factory.create(this.injector);
        component.instance.hierarchy = node.data.data;
        component.changeDetectorRef.detectChanges();
        const content = component.location.nativeElement;
        /**
         * NOTE: We can not attach the angular component to the DOM yet.
         * so we return node content as empty string ''
         * After the renderization, we attach every component instance
         * to its own Node HTMLDivElement
         */
        setTimeout(() => {
          const nodeHTMLElement = (arr[i] as HTMLDivElement);
          nodeHTMLElement.innerHTML = '';
          nodeHTMLElement.appendChild(content);
        });
        return '';
      })

Additional context
It would be great to have an alternative method which append framework agnostic HTML Elements.

Hello @angelfraga ,
I was wondering if you had a simple angular example in stackblitz where your snippets of code commented above works? I am trying to make each node a component as well.

Hello @bumbeishvili and @angelfraga!
First of all, thanks for the tips!
I followed them to create an org chart with nodes as angular components.
However, it seems that nodeUpdate runs every time even just collapsing children from a node.
That way, the org chart floods the runtime with angular components that represent the same nodes.
Do you guys have any idea of how to optimize this behavior?

However, it seems that nodeUpdate runs every time even just collapsing children from a node

That's true and I don't see this behaviour changing in the near future, so I don't know how to optimise it

Want to use more react and less d3? check out this stackblitz link
https://stackblitz.com/edit/d3-org-chart-react-integration-hooks-2chluf?file=index.js,OrgChart.js
Instead of striping everything react away in the chart (React.renderToString) we were able to use this org chart but keep all react functionality by drawing the graph and linking react components to it by using createPortal
Now you get the benefits of using this library to draw the graph but get all the benefits of react. We've been using this route for about 2 months now and have not run into any issues. We do use the basics of this graph (just draw the graph and thats it) although we do plan to implement some other functionality this library provides (centering, expanding, etc)

Hey @marcellino-ornelas, it looks like upon expanding or collapsing a node in your example, the nodes are now empty. Did you ever come up with a solution ?

@alkanna I personally haven't tried expanding or collapsing the nodes yet. The farther I went with this was being able to add new nodes.
https://stackblitz.com/edit/d3-org-chart-react-integration-hooks-hdgvst?file=index.js,OrgChart.js,Counter.tsx
I worked on this in another issue and wrote some of my findings over there
https://github.com/bumbeishvili/org-chart/issues/131#issuecomment-1458870346

@alkanna I tried this out tonight but didn't go so well.
I got react updating the data to add a _expanded property on the data.
initially, if you set _expanded: true on all the data everything will be expanded and vise versa withfalse

@alkanna got nodes to collapse and update but the solution is a little hacky in my opinion 🤷🏽♂
https://stackblitz.com/edit/d3-org-chart-react-integration-hooks-wmkv7k?file=index.js,OrgChart.js,Counter.tsx

I've tried library to be as hackable as possible 🤷🏽♂


Issuance rate parameterization under adversarial conditions

Thanks @Mikerah for initial discussions on this.
#251 provided some initial discussion on issuance rate, but does not discuss how to avoid the two extremes presented in the design rationale, namely:

two common models, (i) fixed reward rate, and (ii) fixed total reward

Each can be solved individually, but let's consider the first case for now:

The main argument against (i) is that it imposes too much uncertainty on the network of two kinds: uncertainty of the total level of issuance, and uncertainty of the total level of deposits (as if a fixed reward rate is set too low then almost no one will participate, threatening the network, and if a rate is set too high then very many validators will participate, leading to unexpectedly high issuance).

The solution to the above two extreme cases is a mid-way compromise of inverse-square root issuance based on the total balance. The design rationale states that "The inverse-square-root approach compromises between the two and avoids the worst consequences of each one," but I argue that it does not, continuing discussion from #832 in this comment. In the worst case, an inv-sqrt scaling on rewards does not solve the problem of having set the parameter too low. To actually solve it would require an inverse-exponential function, where the rewards increase to infinite with no validators.
A compromise solves neither problem, and instead leaves the worst case scenario for both intact. How can the rewards be scaled in a way that we have rigorous proofs of how the system performs in adversarial conditions?
Is there actually a real, provable problem with using a linear scaling reward function, other than the optics that inflation is too high?

A compromise solves neither problem, and instead leaves the worst case scenario for both intact.

Huh? That's definitely not true. First of all, y = 1/sqrt(x) is unbounded with y approaching infinity as x approaches zero, so it is the case that if the parameter set is too low it will still reach an equilibrium with a significant number of validators. Second, as my paper on discouragement attacks shows, using a square root formula instead of a simple y = 1/x does make discouragement attacks 2x weaker, to the point where it does possibly solve the issue (see "this implies we need p < 1/2 for epsilon attacks to be unprofitable" on page 6).

Hmm. Sorry for jumping the gun on a proposed solution. I'll try to articulate my thoughts here, please correct if they're wrong.
There are two problems we have to consider:
(i) What if we set our parameters too low? Then no one will validate.
(ii) Is our system vulnerable to discouragement attacks?
The first suggestion for a reward rate is constant, independent of the total validating stake, i.e., B = k * Di. The problem with this is what it does not solve (i), since we may have set our parameter k too low. Let's consider the case of the inv-sqrt rewards, i.e., B = k * Di / sqrt(Dtotal).
Yes the inv-sqrt goes to infinity when Dtotal = 0, but I'll argue that this is not what should be looked at. When a validator is looking to enter the system, and they check what rate they are going to get, we need to consider the rewards they would get after they enter the system. In other words, we only care about how the value of B after Dtotal = 1 (if we normalize deposits to units) or Dtotal = 32 (if we don't normalize and instead take raw rewards). Under a Dtotal > 0, B with inv-sqrt is a finite number, a function of the parameter k. What if we set this k too low, then no one will validate? Therefore the inv-sqrt does not solve the problem of having set parameters too low. An equilibrium exists where no one validates because rewards are too low.
Now, I argue if we can solve (i). Based on the above, the reward for Dtotal = 1 should be infinite, then we're sure we haven't set our constants too low. We can apply this argument iteratively for all values of Dtotal. The only way to be sure we haven't set the parameters too low is to have infinite rewards always. Of course this isn't a useful solution, but proves that this problem is impossible to solve.
To address whether the inv-sqrt solves discouragement attacks, I'm not convinced that the linked paper proves a tight upper bound on p of 1/2, but rather only shows that discouragement attacks are profitable (?) at p > 1/2. As mentioned, setting p = 1/2 (i.e., inv-sqrt) probably solves discouragement, but we're not sure of this. It's optimistic to assume this paper covers all forms of discouragement attacks too.
By the above, we can't solve the problem of having set the parameters too low, and inv-sqrt isn't guaranteed to solve the discouragement attacks. Constant rewards (i.e., set B = k * Di) do not solve the problem of having set parameters too low (same as with inv-sqrt), but do trivially make discouragement attacks non-profitable.

I'm also not sure there's any justification for an issuance rate that's "too high." What is "too high"? 10%? 1%? It would be nice to have some justification on that end as well.

Probably the max "too high" would be the current inflation on the eth1 chain. Given that PoS validation is more efficient wrt security per unit issued than PoW, the max inflation should arguable less than the current eth1 chain

(i) What if we set our parameters too low? Then no one will validate.

There seems to be broad consensus that targeting a max of 2^21 ETH annual issuance when the total effective balance is 2^17 ETH is a reasonable first shot. This is implemented here. If issuance is too low (e.g. we don't reach the 2M ETH as fast as we'd like) we can always review it upwards.

(ii) Is our system vulnerable to discouragement attacks?

I think this boils down to what @djrtwo said: "general approach is large enough initial v-set, honest assumption, and forced deposits". If there are discouragement attacks then the honesty assumption is flawed and we're in much deeper trouble.
Feel free to reopen an issue or PR if you feel strongly :)


Write the controller function to change user's password

Request Structure is present here

Note

You'll have to check user's old password before setting new one.
Also verify recaptcha.
You'll have to write the function in controllers > user.controller.js.

Make sure to pull before starting your work.
For any doubts or difficulty, you can ping me on discord, I'll try to help you out as soon as possible.
All the Best!!

Claim

Assigned to @SanyamAgrawal07


It broke scroll-list.lua functionality

https://github.com/CogentRedTester/mpv-scroll-list
I use chapter-list.lua
Scroll wheel and UP, DOWN were used to scroll among chapters.
UP, Down and Scroll Wheel are now just changing volume.

can you share your input.conf?

input.conf isn't required since just dropping inputevent.lua to my scripts folder makes chapterlist.lua to ignore
add_keys(o.key_scroll_down, 'scroll_down', function() list:scroll_down() end, { repeatable = true })
add_keys(o.key_scroll_up, 'scroll_up', function() list:scroll_up() end, { repeatable = true })
add_keys(o.key_move_pageup, 'move_pageup', function() list:move_pageup() end, {})
add_keys(o.key_move_pagedown, 'move_pagedown', function() list:move_pagedown() end, {})
add_keys(o.key_move_begin, 'move_begin', function() list:move_begin() end, {})
add_keys(o.key_move_end, 'move_end', function() list:move_end() end, {})
add_keys(o.key_open_chapter, 'open_chapter', open_chapter, {})
add_keys(o.key_close_browser, 'close_browser', function() list:close() end, {})

But it doesn't hamper mp.register_script_message("toggle-chapter-browser", function() list:toggle() end) since it is in my input.conf TAB script-message-to chapter_list toggle-chapter-browser.
Maybe it can be fixed by adding them in input.conf? But then again I use UP, DOWN and scroll wheel for volume. And their function is only different when toggle-chapter-browser is in focus.

Weird, I just add script-message-to chapter_list toggle-chapter-browser too.
Can you show your shift+i 4? See what's taking up wheel_up.

Also I just noticed, I can click on timeline with left click now.
I had buttons in uosc as some binds even they stopped working, though I can use them using keybinds
Almost everything broke.

You can scroll down this page to find the wheel_up and wheel_down.
Does everything work well if you delete inputevent.lua?

Does everything work well if you delete inputevent.lua?

Yes.

Any error or warning in console? " ` " <- default tothis key

I have no idea what's happening here.
Can you upload your mpv.conf?
If you delete this part (at end of inputevent.lua), does everything works?

Upon closer inspection, this seems to be an issue of another script/or maybe mpv.
Sorry for wasting your time.


C++ PassThrough with dual-mode endpoints (C++ or JS)

Initial working implementation of a C++ based PassThrough which also acts as a "transform" between the C++ and JS API, being able to pass through to either API.
Currently comes with an potential C++ abstract interface, but that doesn't currently function due to how C++ interface classes work.
This follows how I developed the JS API (class / object based) but it is possible that we will land on something more 'functional' in a future iteration.
Also changes the JS status passing to use an enum / number statuses.
cc @addaleax, @jasnell, @mcollina, @trevnorris - if any of you want to take a peek before I squash and merge in a few days.

What kind of feedback are you looking for?


jbt failing with TypeError on Linux

{0}% lldb -- /home/rrix/Uber/node/node_g --perf-basic-prof app.js
Current executable set to '/home/rrix/Uber/node/node_g' (x86_64).
(lldb) command script import /bin/jbt.py
break listThe jit symbol resolver command `jbt` has been initialized and is ready for use.
(lldb) break list
Current breakpoints:
1: name = 'v8::internal::PerfBasicLogger::LogRecordedBuffer', locations = 1
    Breakpoint commands:
      return jbt.jit_break(frame, bp_loc, internal_dict)

  1.1: where = node_g`v8::internal::PerfBasicLogger::LogRecordedBuffer(v8::internal::Code*, v8::internal::SharedFunctionInfo*, char const*, int) + 29 at log.cc:285, address = 0x0000000000da94c5, unresolved, hit count = 0

(lldb) r
Process 13540 launched: '/home/rrix/Uber/node/node_g' (x86_64)
(lldb) Traceback (most recent call last):
  File "temp.py", line 7, in lldb_autogen_python_bp_callback_func__0
  File "/usr/lib/node_modules/lldb-jbt/jbt.py", line 88, in jit_break
    name        = "%.*s" % (length, name_var.GetSummary().strip('"'))
TypeError: * wants int
Process 13540 stopped
* thread #1: tid = 13540, 0x0000000000da94c5 node_g`v8::internal::PerfBasicLogger::LogRecordedBuffer(this=0x0000000003690b20, code=0x00002ff6b1a06001, (null)=0x0000000000000000, name=0x0000000003690b44, length=15) + 29 at log.cc:285, name = 'node_g', stop reason = breakpoint 1.1
    frame #0: 0x0000000000da94c5 node_g`v8::internal::PerfBasicLogger::LogRecordedBuffer(this=0x0000000003690b20, code=0x00002ff6b1a06001, (null)=0x0000000000000000, name=0x0000000003690b44, length=15) + 29 at log.cc:285
   282                                         SharedFunctionInfo*,
   283                                         const char* name,
   284                                         int length) {
-> 285    DCHECK(code->instruction_start() == code->address() + Code::kHeaderSize);
   286
   287    base::OS::FPrint(perf_output_handle_, "%llx %x %.*s\n",
   288                     reinterpret_cast<uint64_t>(code->instruction_start()),

{0}% yum info lldb
Loaded plugins: langpacks, refresh-packagekit
Installed Packages
Name        : lldb
Arch        : x86_64
Version     : 3.4
Release     : 12.fc20
Size        : 26 M
Repo        : installed
From repo   : updates
Summary     : Next generation high-performance debugger
URL         : http://llvm.org/
License     : NCSA
Description : LLDB is a next generation, high-performance debugger. It is built as a set
            : of reusable components which highly leverage existing libraries in the
            : larger LLVM Project, such as the Clang expression parser and LLVM
            : disassembler.

{0}% sudo npm i -g lldb-jbt
[sudo] password for rrix:
npm http GET https://registry.npmjs.org/lldb-jbt
npm http 200 https://registry.npmjs.org/lldb-jbt
npm http GET https://registry.npmjs.org/lldb-jbt/-/lldb-jbt-0.3.0.tgz
npm http 200 https://registry.npmjs.org/lldb-jbt/-/lldb-jbt-0.3.0.tgz
/bin/jbt -> /lib/node_modules/lldb-jbt/jbt
/bin/jbt.py -> /lib/node_modules/lldb-jbt/jbt.py
<EMAIL_ADDRESS>/lib/node_modules/lldb-jbt

should be fixed now, can you try again?


Windows support?

Can it run under Windows system， and how?

Hey @wangdemo,
It can indeed run on Windows, as there aren't system-dependent parts of the package and folks have previously done this https://github.com/alvinwan/neural-backed-decision-trees/pull/17. However, I don't own a Windows machine myself so unfortunately don't have specifics. If you have access to a Terminal-esque window, just run the installation command in the README (pip install nbdt) and follow the getting started guide there.


Fix Json parse problem with multibyte characters

this is rebased on master, to fix the CI build

I was hoping for an easy win, and for the other CI fixes to fix this, but alas no.
So I will have to dig into this encoding bussiness later.


Update templates from eventing

Copying https://github.com/knative/eventing/pull/2601 plus the rest of the eventing templates, since these haven't been updated when the eventing ones changed.
/cc @vaikas @lionelvillard

@grantr can you also add this to our beloved knative-gcp?

https://github.com/google/knative-gcp/pull/559

Thanks!!!
On Wed, Feb 19, 2020 at 10:21 AM Grant Rodgers<EMAIL_ADDRESS>wrote:

google/knative-gcp#559 https://github.com/google/knative-gcp/pull/559
—
You are receiving this because you commented.

------------------------------------
---- Linting the markdown files ----
------------------------------------
---- Thu Feb 20 09:46:05 PST 2020
------------------------------------
.github/ISSUE_TEMPLATE/bug.md:19: MD036 Emphasis used instead of a header

A detailed description of the rules is available at https://github.com/markdownlint/markdownlint/blob/master/docs/RULES.md
.github/issue-template.md:1: MD002 First header should be a top level header

A detailed description of the rules is available at https://github.com/markdownlint/markdownlint/blob/master/docs/RULES.md
.github/pull-request-template.md:5: MD002 First header should be a top level header
.github/pull-request-template.md:7: MD003 Header style
.github/pull-request-template.md:34: MD014 Dollar signs used before commands without showing output
.github/pull-request-template.md:7: MD022 Headers should be surrounded by blank lines
.github/pull-request-template.md:23: MD036 Emphasis used instead of a header
.github/pull-request-template.md:38: MD036 Emphasis used instead of a header

in this pr, add this file to eventing-contrib: https://github.com/knative/eventing/blob/master/test/markdown-lint-config.rc

This is essentially blocked until https://github.com/knative/test-infra/pull/1726 gets in.

/retest

Now with #957 the github issue and PR templates won't be markdown linted anymore. This is RFAL.

/lgtm


just to clarify, here 10 sweep means aggregate 10 frames of lidar data right?

The one without flip augmentation https://drive.google.com/drive/folders/1OazJ7wULZcDtE-grW2AKBkMnA0h1Co98?usp=sharing  (66.8 NDS val performance)
The one with flip augmentation https://drive.google.com/drive/folders/14TvJegUV1BPCw5oWqEwR0AvXM8tjLsQt?usp=sharing (68.5 NDS val performance)
Originally posted by @tianweiy in https://github.com/tianweiy/CenterPoint/issues/249#issuecomment-1015891599

yes


TOKEN_MISSING

I am using Yelp Fusion API for a native Android application, utilizing Retrofit for making requests. I have repeatedly ensured that I am passing my API_KEY as a header in a GET request in the below format:
"Authorization: Bearer <API_KEY>"
I even printed out the headers of ongoing requests, and they are exactly as I stated above. I can request and successfully retrieve results via curl and Postman, but not from Android. I have considered that it might be an issue regarding Retrofit, but I've found no mistakes in that.
When I send the request, I get a 200 code and this error:

{"error": {"code": "TOKEN_MISSING", "description": "An access token must be supplied in order to use this endpoint."}}

I'm not sure where to turn at this moment, but can someone try pointing me in the right direction?

Interesting. A couple questions that might help in debugging:

What is your client ID? (remember this is NOT the api key, which should never be posted publicly)
Could you please copy-paste in an excerpt of the headers you printed out for the Retrofit request (please redact any sensitive information, i.e. the api key)?
What is the curl request you used to compare that against? (again, please redact any sensitive information, i.e. the api key)

Firstly, sorry for posting in the wrong section!

My client ID is : ewYK-P0U1jzAtU-dGrm3bw
I am using an interceptor to modify the outgoing request with the headers. Note: I have also attempted to set headers both statically and dynamically. I have verified that the request definitely contains the headers because it correctly prints out 'Authorization: Bearer MY_API_KEY'.

`OkHttpClient.Builder okHttpBuilder = new OkHttpClient.Builder();
okHttpBuilder.addInterceptor(new Interceptor() {
    @Override
    public okhttp3.Response intercept(Interceptor.Chain chain) throws IOException {
        Request original = chain.request();

        // Request customization: add request headers
        Request.Builder requestBuilder = original.newBuilder()
                .addHeader("Authorization", "Bearer MY_API_KEY");
        Request request = requestBuilder.build();

        return chain.proceed(request);
    }
});

//Yelp Client init
yelpRetrofit = new Retrofit.Builder()
        .baseUrl("https://api.yelp.com/v3/")    /*the rest of the endpoint is in a Retrofit client class*/
        .client(okHttpBuilder.build())
        .addConverterFactory(GsonConverterFactory.create())
        .build();
yelpClient = yelpRetrofit.create(YelpClient.class);`

This is the curl request I sent

 curl -H "Authorization: Bearer MY_API_KEY" "https://api.yelp.com/v3/businesses/search?latitude=MY_LATITUDE&longitude=MY_LONGITUDE"

We are in the process of archiving this API v2 github repository, and as part of that are closing out all issues.

Announcement:
As of June 30, 2018, the API v2 has been discontinued and v2 endpoints no longer work. It has been replaced by Yelp's Fusion API. This github repository is archived. There is a new Yelp Fusion-specific github repository at https://github.com/Yelp/yelp-fusion.


[FYI] Notes uneditable with old web-browser

Hello,
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
In "Notes mode" (Notes layer ON), note icon is visible but not content. So, unclickable, uneditable and so on.
It's a bug-(veryveryold)browser-specific, I guess and maybe unuseful to be fixed. So my issue is only FYI ^^

Thanks for flagging this @deuzeffe - does this work with a more recent version of Firefox?
I think Firefox 52 is not that old really and I'd expect it to work, so this might be worth investigating.

Test on Firefox Extended Support Release (ESR 52) (--> https://www.mozilla.org/en-US/firefox/organizations/) shows same result here: hovering over the "Notes" icon won't change the cursor and in general has no impact at all. It's like the notes icon doesn't even exist in the first place.

Yes, it works with a Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:56.0) Gecko/20100101 Firefox/56.0 eg (no more recent browser > 56.0 available here, sorry).


Filter

Challenges 1-6 pass!

Challenges 1-5 pass! unfortunately, based on your submission date, there is a point subtraction for the late submission.


Use pyenv's virtualenv capabilities.

Add pyenv virtualenv or virtualenvwrapper support. I know it's two things for one PR, but they are so closely related that I couldn't resist. Now, I know this is a duplicate of #785 but honestly, I don't think #785 was going to work.
There's a couple of things to mention here:

Pyenv's virtualenvs work anyways without this feature, but they aren't activated. Basically this means, that the prompt wouldn't change for them.
I've checked prezto's prompt for virtualenvs and it works the same for pyenv's virtualenvs.
Pyenv virtualenv messes up with precmd hooks, so until they merge https://github.com/yyuu/pyenv-virtualenv/pull/77 or solve it another way, prezto's prompt is going to break after eval "$(pyenv virtualenv-init -)"
Virtualenvwrapper crashes if pyenv is initialized, unless https://github.com/yyuu/pyenv-virtualenvwrapper is used.

yyuu/pyenv-virtualenv has now fixed it's problems with hooks, so initializing it shouldn't no longer affect prezto.

Thanks for your contribution. This has been superseded by #1305 so I can consolidate the work from a number of other PRs.


Feat: TestId changes in Collapsible and KeyValuePairInfo

Motivation
To improve testing, the testId must be in the most parent element.
In KeyValuePairInfo that means that the Collapsible should have the test id.
Changes

Add prop testId in Collapsible.
KeyValuePairInfo passes testId to parent Collapsible.

Screenshots

No new tests required.

@peterpeterparker @dskloetd please review

@dskloetd please review

FYI: I tried the component with nns-dapp and collapsible looks the same in different use cases.