RFC: Provide feedback on technical merits for CURIE identifier structure

Background
VMC currently uses Identifier objects that consist of a namespace and accession.  These are be (nearly) equivalently represented as JSON (e.g., {"accession": "GA_0123abcd", "namespace": "VMC"}) and as a string (e.g., "VMC:GA_0123abcd"). A VMC accession is constructed as prefix + "_" + digest, where prefix is obtained from a mapping from types to prefixes, such as "VMC:GA_0123abcd" for Alleles, "VMC:GL_0123abcd" for Locations, etc.
The VMC string format is inspired by long-standing conventions of colon-separated namespace:key pairs, which is also consistent with the W3C CURIE syntax and semantics. It is anticipated that future VMC specs will adopt CURIEs as the Identifier format rather than defining its own syntax.
Briefly, a CURIE adds additional meaning to the current namespace:accession scheme (prefix:reference in CURIE parlance): prefix is an alias for a base IRI/URI, and reference is a (possibly) relative IRI/URI. A fully-qualified IRI/URI is constructed by concatenating the prefix and reference, separated by a /. In other words, CURIEs serve to provide a convenient shorthand for an object.
Question
What format should the VMC Identifier have?

There's nothing wrong with the current Identifier AFAICT.
However, as we move to CURIEs, I think there are some advantages (and some disadvantages) to treating the accession (the CURIE reference) as a relative IRI (path). In particular, I propose that we replace the accession prefix (GA, etc) with a relative path prefix instead. For example, "VMC:GA_0123abcd" would become "VMC:allele/0123abcd".
Discussion
The primary advantage is simplified client and server implementation. Under the current scheme, translating an identifier like "VMC:GA_0123abcd" into a URL likehttps://api.somewhere.org/allele/GA_0123abcd requires that either the client or the server peek into the id syntax in order to assess what type of object is requested, which violates the intended opaqueness of the id. This practice entrenches an unfortunate coupling between the allele path component and the GA prefix. In contrast, using a relative path (e.g., allele/0123abcd) as a reference provides a natural translation from CURIE to URI forms (by simple concatenation).
A secondary advantage is extensibility. Current two-character prefixes (GS, GL, GA, GH, GG, etc) have very limited range. In contrast, permitting relative paths enables much more flexibility.
Relative paths are less familiar and more verbose than prefixed identifiers. It is anticipated that more users are familiar with ids like GA_0123abcd than allele/0123abcd. Users might be confused by references that are relative paths rather than prefixes., or might prefer the prefix syntax for aesthetic, stylistic, or familiarity reasons.

@jmcmurry -- I would appreciate your opinion on this question. Thanks!

All good points but there are always tradeoffs. There's no technical prohibition, but I have a strong suspicion that a slash mid ID will result in parsing errors by others when doing curie expansion/contraction.
Your best bet is probably either VMC:GA0123abcd or better yet just VMC:123abcd if the performance is not compromised. You can always redirect to a nested URL if you want to whether
https://api.somewhere.org/allele/123abcd or
https://api.somewhere.org/allele/GA0123abcd
or no nesting:
https://api.somewhere.org/123abcd (requires guarding against collisions across types, and requires type lookups)
https://api.somewhere.org/GA0123abcd
As long as the biological types are durable, coarse, useful and undisputed, baking type into local ID is ok.

@Reece Do we have to have a single VMC namespace? I understand the desire to do this, but maybe it would be okay to consider the idea of something like
VMCGA (or VRGA) - allele
VMCGL (or VRGL) - location
VMCGS (or VRGS) - sequence
etc..
We shouldn't be too married to the VMC acronym. The GA4GH refers to us as the VR group and the VMC (variant modeling collaboration/consortium) is a bit outdated and confusing - possibly.
I'm thinking that it would be reasonable to have several namespaces which target the various classes of things that are digested in the namespace, essentially using the namespace to prevent computed identifier collision. I've never been a big fan of manipulating (prefixing) identifiers in order to jam them into a single namespace, but I get that we also don't want an explosion of namespaces to manage too.
ClinVar and others do the prefixing approach (VCV000x, RCV000x, SCV000x, etc..) which keep all like identifiers/accessions in their one authorizing identifier system. So, I think we should stay with that approach as well.  We could expand to a 3 latter prefix if you are concerned about running out of options.
Not sure if any of that is helpful, but I thought I'd share some thoughts for what its worth.

@reece btw why do we prefix our prefixes with "G"? (is it for "generated"?)

I completely agree with @jmcmurry here; my immediate concerns about switching are precisely captured by her comments above.
I would like to add that a third alternative–dropping the underscore–is preferable in my view, and is in line with @larrybabb's suggestion re: ClinVar practices, as well as those that we see from Ensembl (genes/transcripts/proteins/etc), the ClinGen Allele Registry, dbSNP, and others. Of course, there's nothing wrong with keeping the underscore either (RefSeq style), with the minor exception of the additional bulk from the extra character in ID strings.

@jmcmurry: Thanks for responding so quickly. You're the second person to suspect that CURIE handling in the wild might not support relative paths. That's a shame because rel refs would be useful and because spec clearly says they're permitted. :-( Any idea how we could get a handle on whether this is a widespread problem?
Re: Dropping the prefix (@jmcmurry): Dropping the prefix would require backends to search for objects in each type (or keep a map of these types). Digest collisions between types is not a concern.
Re: Underscore (@jmcmurry, @ahwagner). This is tied to the id prefix discussion. Aesthetically, I also prefer without. I added the underscore to prevent parsing ambiguity between the id prefix and digest. For example, is GAA012abc an allele with id A012abc, or a new type with prefix GAA and id 012abc? Using a rel path in the CURIE reference would be a standards-based way to enable us to distinguish id type prefix and digest.
Re: Prefix: The G prefix was originally for "global" or "GA4GH", depending on when you asked me.
Re: New prefixes (@larrybabb): The conventional interpretation of the namespace/prefix is as the data source. (See https://www.ebi.ac.uk/miriam/main/collections for examples.) Sometimes namespace includes sub-schemas. I don't know of any examples where namespace incorporates a single data type. There are two problems I see with including type in the prefix. ① It creates more burden for developers because they should provide CURIE prefix-to-uri maps, and doing so for every prefix will be tedious. ② Expanding types would require making code aware of associated new prefixes.
Re: Namespace: I'm not wedded to "VMC". But, let's stick with "VMC" as a placeholder for now, then then propose a switch to "GA4GH" closer to ratification. (IMO, "VR" offers no advantage over "VMC".)

So, here are options so far:

namespace:prefix_digest (e.g., GA4GH:GA_0123abcd). Current. No problems.
namespace:prefixdigest (e.g., GA4GH:GA0123abcd). Same as above, but drops the underscore. Since we know that implementations will parse the id, this really boils down to aesthetics and preference for telling people to "take the first two chars" or "take chars up to underscore".
namespace:type/digest (e.g., GA4GH:allele/0123abcd), à la CURIE. Pros and cons in first comment in thread. Basically, a standards-based equivalent to GA4GH:GA_0123abcd with easier implementation.
namespaceprefix:digest (e.g., GA4GHGA:0123abcd). Theoretically workable, but likely to not scale well as new types are created.

Option
My take

namespace:prefixdigest (e.g., GA4GH:GA0123abcd).
This is best; it is also fine to just say take all of the alpha chars up to the first number digit.

namespace:prefix_digest (e.g., GA4GH:GA_0123abcd).
Same as above, but has the underscore. In Monarch, we have observed edge cases in the wild in which local ID underscores cause trouble due to lossiness about the understanding of what the prefix is*

namespace:type/digest (e.g., GA4GH:allele/0123abcd), à la CURIE.
I don't think this will be as robust as you'd like in others hands. In the wild, there's already a lot of variation in the way people represent prefixes, if the local ID has room for differing interpretations, it will likely complicate integration even more. Specifically, you'll end up with equivalents you can't easily collapse because they require more ID munging to discover**

namespaceprefix:digest (e.g., GA4GHGA:0123abcd).
If you have (or will have) a type-agnostic resolving path, embedding your type flag in the prefix can break the 1:1 mapping between resolving path and prefix which is one of the strongest advantages of the CURIE.

If the option exists to have the local IDs be unique even in the absence of a type flag, that is ideal. It is definitely harder to implement as there may be various bodies that need to mint IDs in collaboration. It is also harder for systems that have to work with billions of IDs, so it is not for everyone. If the number of IDs you need is small (millions not billions) you can achieve uniqueness by reserving blocks of IDs for each type. However, obviously I would caution against attempting this unless you are 100% sure you can guarantee uniqueness in the long run (eg. you have control over the full lifecycle of IDs).
Trivia:
'* Underscores are a pervasive stand-in for colons; the underscore to colon works fine, but then you run into trouble on the round trip; which of the two underscores do you re-convert to a colon?
'** If you imagine you have the full URL, it is pretty likely that someone will assume that the fragment after the final slash is the thing that needs to be contracted to a prefix.

Based on advice from @jmcmurry and discussions with @ahwagner , we're going with option 1 in Julie's table (2-char prefix, no underscore).

There's been some post-close chatter on this topic. I'm reopening to solicit 11th-hour feedback.
Here are real examples to try on for size:
ga4gh:VA/_7JERW4UiCUgH8oaro2QmcpTwRBUFnjU
ga4gh:VA__7JERW4UiCUgH8oaro2QmcpTwRBUFnjU
ga4gh:VA_7JERW4UiCUgH8oaro2QmcpTwRBUFnjU
(This digest starts with an underscore.)
Part of this decision is whether the identifier is supposed to be totally opaque, in which case we might as well drop the type prefix altogether, or, instead, it's translucent (encodes type), in which case we want to make the type useful and extensible. / does that best since it's guaranteed to not be part of the digest. (We chose base64url precisely so that the digest could be used in a path.)
My vote is to switch to /-delimited. The spec already says that we use CURIEs, and / is definitely legal in a CURIE. The hypothesized failures of some tools to handle CURIEs correctly should not keep us from doing so.

What about a GA4GH:VA: structure? Solves the underscore problem and provides us extensibility, without introducing potential human errors that @jmcmurry described for /-delimited. While I appreciate the technical elegance of the / delimiter, I agree with her assessment that it won't be robust in the field.

What's an example use case or tool that would be adversely impacted by permitting the use of CURIEs (with slashes)?
This decision is asking us to consider NOT adopting a standard because we fear that t won't work with some tools.
I'm okay with that unfortunate consequence in the name of pragmatism in principle, but let's base it on real data regarding problems and weigh those problems against the lost value of using the CURIE standard.

Truthfully, the use of colons OR slashes are problematic, though I think slashes are more so. Use of these will cause conflicts (or require special handling) when used as query strings in systems that harbor variants under multiple classification schemes and no underlying logic to handle the proposed VR identifiers specifically. Slashes have the additional complexity of being used as path delimiters, both in URLs and local filesystems, requiring
For example, in VICC our webtool uses Kibana on top of ElasticSearch, a common prototyping framework for document searching. ':' and '/' are reserved characters for lucene search, and so these queries cause problems:
https://search.cancervariants.org/#GA4GH:allele/0123abcd
https://search.cancervariants.org/#GA4GH:allele:0123abcd
Notably, an identifier of the type VA_<digest> or GAVA_<digest> doesn't have these issues. The potential conflicts of multiple '_' appearances in such a scheme is an argument for adopting the TRUNC512 hex encoding as well (for reference, this discussion is in #58).
In summary, I propose we adopt the following scheme:
<org-prefix>:<type>_<digest>
e.g. GA4GH:VA_0123abcd
and we follow refget and use hex encodings to avoid the potential parsing conflicts @reece mentioned above.
This has the advantages of:

closer alignment to refget
same structure used by Entrez
minimal lucene search conflicts (same conflicts need addressing as with HGVS queries)
CURIE syntax
in line with best practices as described by @jmcmurry
minimal difference from our current implementation

Based on #56, and regardless of terminology names there, I think we're leaning toward identifying objects with unconstrained strings and RECOMMENDING a structured string to provide external references.
What's the question in this issue?
The question is whether we adopt CURIEs as the id/identifier format. And, if so, provide substructure within the CURIE for GA4GH-specific meaning.
If we're not willing to adopt the full meaning of CURIEs, then we shouldn't use that name. Instead, we need to define a home-grown structure. (And it will likely look like a CURIE but not actually be one.)
How we make this decision
The goal for this decision is an expression that is parseable reliably by software, and preferably in diverse systems. These expressions are not for humans therefore the decision does NOT involve aesthetics to humans.
I will presume that we agree that the decision must be based on technical correctness and non-technical concerns that impact multiple systems, not specific components. I'll also presume that when implementations fail because they or their components don't use (or misuse) standards, the default is that they should adapt.
Decisions to make
Decision #1: CURIEs or home-grown colon-delimited syntax for id structure?
As authors of a standard, we should use existing standards wherever possible. And, we should expect that others will use standards correctly.
CURIEs are designed for our use case and we should use them. That means permitting slashes, and therefore that consumers must tolerate slashes (and colons, and anything else that's in the CURIE spec).
CURIEs consist of a prefix and reference (W3C terminology), which we colloquially call "namespace" and "accession", and [McMurry 2017] calls "namespace" and "local id". I'll use W3C here because I want to be clear that I'm using the terms as they define them.
Decision #2: What CURIE prefix?
The CURIE spec places no requirements on the meaning of prefix. I would like VR to RECOMMEND using identifiers.org as the source of acceptable prefixes. identifiers.org uses lowercase. "ga4gh" is the answer here.
Decision #3: What structure for reference?
For reference, I think we all agree that we want a translucent string, i.e., with an embedded type identifier of some sort. (A transparent string, like an HGVS expression, is not an option. And I think we all agree that a truly opaque string such as a raw digest is also not an option.)
If a reference string has type, we're putting it there to be parsed in some contexts. Our question now is what mechanism is most amenable to parsing?
The options I see:

fixed-width, two characters: Pros: Easy to explain; Cons: non-standard and not extensible.
underscore- and colon- delimited: Pros: familiar; Cons: underscore is a valid member of the pchar characters for URI paths (RFC3986), so simultaneously conflicts with path content and precludes the use of URI libraries to parse that concept from the expression. (I'm not saying that this scheme doesn't work or that it's even wrong in any absolute sense.)
slash-delimited: Pros: Complies with CURIE spec and therefore enables the use of tools; easily extends to subtypes; Cons: Code that doesn't expect CURIEs might be confused.

Response to @ahwagner's implementation issue
RFC3986 permits colons and slashes in fragment identifiers. The example URLs are completely legal. I don't see these URL examples themselves as causing a technical problem by software that obeys standards.
The Lucene issue is solved by correctly escaping reserved characters during querying. This is a common question and many Google responses cover it. Moreover, all software that passes messages must deal with escaping and quoting to prevent message content from conflicting with message structure. So, unless I'm missing something, I would expect a variant of this issue with all software dependencies.
If anything, these examples support the notion that standards prevent confusion and that we shouldn't make up our own scheme.

I advise omitting the extra delimiters unless there is a very strong reason not to. While the spec will technically support all kinds of permutations, Murphy's law will prevail in the wild: someone out there will botch what can be botched. Lowercase prefix is fine.
Eg. ga4gh:VA7JERW4UiCUgH8oaro2QmcpTwRBUFnjU
If you define the type flag as the alpha characters up to the first numeric digit, parsers should not have any trouble. This has the added benefit of being shorter and robust to type flags of varying lengths.

Thanks @jmcmurry. Your ears must have been tingling: we were just talking about this topic and asking you for clarification. In https://github.com/ga4gh/vr-spec/issues/32#issuecomment-479179902, you wrote "... you'll end up with equivalents you can't easily collapse because they require more ID munging to discover**" and "** If you imagine you have the full URL, it is pretty likely that someone will assume that the fragment after the final slash is the thing that needs to be contracted to a prefix."
I think what you mean is that if someone sees ga4gh:VA/blah, they're going to parse out blah, then want prepend VA to it, which just creates confusion. Is that right?

The problem is the the two-delim versions of any compact ID -- when botched in the wild -- are lossy.
GA4GH:VA_0123abcd can get (improperly) converted to GA4GH:VA:0123abcd. Then what? How do you convert it back? Is the local part VA:0123abcd? or 0123abcd? Similarly, what is the prefix and what does it expand to?
Sure, the underscore is not an insurmountable. If people read the fine print in documentation, all works; there are plenty of shops where this is done. But the edge cases are so easily avoided, hardly seems worth the trouble (unless I'm missing something fundamental about the use case).

I'm not inclined to base technical decisions on the myriad ways that people might botch up identifiers.
Honestly, cases like these make me even more convinced of the benefit of using a standard syntax for identifiers so that people eventually stop trying to rewrite, "clean up", or otherwise beautify ids.
We're just not going to be able to prevent people from shooting themselves in the foot. If easily avoided, sure, but I don't see it as our problem to design a spec to protect people from themselves, and especially not if we have to forego other benefits to do so.
Some of those benefits:

Use the prefix (namespace) as a full base URL to an object without server side munging. That is, ga4gh:VA/id becomes https://somewhere/VA/id on the client, rather than requiring client or server to rewrite VA_id as the relative path. That makes life a lot easier for clients and servers.
Clearer semantics. IMO, it's much cleaner to tell people who want the type to "take the first path element" (for which they could use a url parsing library) rather than "take the first 2 chars" or "take the chars up a delimiter".
More extensible. By using /, we can construct paths any way we want. For example, a subtype could be allele/snv/id.

For me, these are all known benefits of using the full power of CURIEs, and, conversely, losses if we don't do so. None of them make-or-break the spec, but I do have a hard time justifying the loss of these benefits against the possibility that people might shoot their own feet.

Summary of today's call re: identifiers:
Larry proposed that we keep the currently implemented /-delimited paths and revisit in two weeks. In that time, we might have real data about the harms of using paths and can better decide between the costs and benefits.
@jmcmurry @larrybabb @ahwagner @rrfreimuth @mbrush @javild

I think we need to get the input from other Driver Projects here–I can tell you that for the VICC this is non-trivial for our current implementation (as mentioned above), and may affect our ability to spin something up in our proposed timeframe. @melissacline, @ronakypatel could we get your input on this?
I can say that this topic has also come up in Cloud, quite recently: https://github.com/ga4gh/data-repository-service-schemas/issues/263 and https://github.com/ga4gh/data-repository-service-schemas/pull/271.
Ultimately, they agreed to keep / in IDs only if it was URL-encoded in the ID, which is obviously not ideal.

We might not face this issue as we are not trying to dereference identifier for sequence. Although we may face an issue with dereferencing the sequence identifier (refget). I am not sure why you want to use slash in the identifier (value), let it be part of the prefix.
namespace: ga4gh.endpoint.org/allele
id: 0123abcd
After thinking I think putting a slash in the id does not feel like an appropriate thing to do. Probable reason why base64URL uses "-" and "_" instead of "+" and "/", making it URL safe.

I have been considering the potential gains of the current /-delimited embedded type ids described above:

Use the prefix (namespace) as a full base URL to an object without server side munging. That is, ga4gh:VA/id becomes https://somewhere/VA/id on the client, rather than requiring client or server to rewrite VA_id as the relative path. That makes life a lot easier for clients and servers.
Clearer semantics. IMO, it's much cleaner to tell people who want the type to "take the first path element" (for which they could use a url parsing library) rather than "take the first 2 chars" or "take the chars up a delimiter".
More extensible. By using /, we can construct paths any way we want. For example, a subtype could be allele/snv/id.

I am concerned that in practice these advantages will rarely be realized, while potentially confounding adoption. I think that this strategy will unnecessarily slow or prohibit adoption of the specification for 3 reasons:
Reason 1: Lack of Motivating Examples
AFAIK there are not other variant representation specifications that have a /-delimited id structure. Are there other biomedical data specifications that do? If we’re going to promote this as a standard (versus an academic exercise) I think it will be necessary to point to example implementations that have used and benefited from ids with prescribed pathing structures built in via /-delimiters. In an ideal GA4GH scenario, these implementations would be (at a minimum) by Driver Projects.
I provided the above exemplar from the VICC Driver Project to demonstrate how this structure (/-delimiters in an id) may cause problems. A reasonably simple strategy for handling these has been identified in this particular case, and will be documented in the VICC implementation in the event this issue resolves with a decision to promote the /-delimited identifiers. However, it is notable that the use of the /-delimited typed identifier did not realize the above cited benefits, and is more challenging to handle than a similar CURIE without embedded / characters. This is because the VICC system treats ids as opaque string objects for searching (alongside other variant representations), and lacking an endpoint to specifically handle the VR object structure does not realize any of these theoretical gains.
Similarly, the ClinGen Allele Registry will not be storing the computed ids, only returning them–thus also not realizing any of the above benefits in the near-term (i.e. before PRC submission), if at all.
Ultimately, I think that this process illustrates a fundamental problem: /-delimiters create a need for implementations to modify or create strategies to handle a rare id structure, and we lack example implementations that have asked for or intend to use this structure for the theoretical benefit. As this issue was also recently raised in the Cloud workstream, it stands to reason that it will catch the attention of the PRC. If we push forward anyway, I think we’ll need concrete evidence that the cited gains are substantial and likely to be realized.
Reason 2: Intrinsic Pathing Advantages Tied to REST APIs
The benefits of identifiers with built-in paths are inherently targeted at REST APIs, but our specification otherwise does not make requirements for API behaviors or endpoints. In the VR 1.0 specification, we do make some requirements about the behavior of implementations, but it is limited to the structure of the VR objects themselves and the methods for computing identifiers on them. By extending our data structures within ids (e.g. the above allele/snv/id) for the purpose of opaque/translucent identifier evaluation, we are essentially defining endpoint structure and API behavior if implementations wish to realize the primary benefit of the /-delimiter design choice.
Reason 3: Downstream munging difficulties
As a variant representation specification, these ids will be used in applications beyond inter-system communications, such as in variation dataset analysis. Consequently, it is certain that data munging efforts will take place for analyzing variation data from one or more datastores. @jmcmurry points out that while /-delimited ids are problematic, so are _-delimited ids, because they (and other identifiers with multiple delimiters) require special care to reconstruct.
Are Embedded Types Needed?
@ronakypatel has also pointed out that there is no apparent reason that the corresponding object type need be embedded in the id itself. In fact, the ideal scenario would be to forgo having the type embedded in the CURIE at all.
As the computed identifier is a value hash for shortcutting queries for VR objects, it stands to reason that:

if a queried typed id does not exist in a datastore, the id-embedded object type is of no value
if a queried typed id does exist in a datastore, the linked object contains the type information
if all ids share the same structure (as untyped ids), they could all be simultaneously queried

So, as far as I can tell, there is no consequence to dropping the embedded type entirely.
Proposal
I suggest we adopt @jmcmurry’s suggestion to do away with type flags altogether as the id digests are unique enough without them. As a side-note, I would also like to add .vr to the namespace for this specification, as it is probable that the GA4GH will define other CURIE ids that are outside of the vr scope. As a result of this, the computed ID for an allele would be:
Namespace: ga4gh.vr
CURIE: ga4gh.vr:<digest>
In summary, by dropping type from the CURIE entirely the proposed opaque representation would:

remain a CURIE, and thus in-line with identifier best practices
maintain or improve upon all of the cited advantages of a /-delimited embedded-type id

Easy adoption by servers/clients: ga4gh.vr:id becomes https://somewhere.org/ga4gh-vr/id
Easiest semantics. Ids are opaque, no parsing/munging needed.
Fully extensible. Type isn’t embedded, so an id can be of any current or future type!

reduce potential data munging errors in downstream efforts
use less space (or equivalent space with less implementation effort) with minimally sized strings
not implicitly define REST API
be identical to refget Checksum Algorithm after re-encoding to base64url, simplifying interchange between formats

future version of refget could adopt this

Thoughts on this from the collective?

I like the style of the last proposal ga4gh.vr:<digest>. It gets rid of most issues mentioned in the thread, it is still easy to convert to a URL, and makes clear the sub-namespace within GA4GH.
My only question is if CURIEs, as proposed by the W3C, are supposed to represent a particular resource type or are completely arbitrary. My impression from reading the recommendation is the latter, in which case I would be okay with dropping the type; otherwise I would also be okay with something like ga4gh.vr.allele:<digest>

I think I broadly agree with @ahwagner @cyenyxe. Just to augment what they said: storing the id with namespace takes extra bytes, without much value. It might be trivial for a few million variants but it is significant for a few billion variants.

During the VR call today the discussion about the use of prefixes (i.e. SQ, VR, VT, etc...) in the computed identifiers came up again. As well as, the contention over the use of the slash to delimit it with respect to the computed digest value itself.  Here some of what was presented by me.
Do we need the prefixes in the final computed identifier at all?
Is there a strong argument to why this is needed. Is there a stronger argument for dropping the prefixes all together and simply having the computed digest be the sole id portion of the identifier and the namespace prefix of the CURIE be set to ga4gh-vr.
Example: ga4gh-vr:Zp8e9tUGfwiTRfIIij7INFQKa_Hc4ep9

If you take no other advice from me, that is OK but please please do not embed the type flag in the prefix. My comment from april above still stands.

The consensus from yesterday's GA4GH Cloud call was to disallow slashes and only allow IETF RFC 3986 § 2.3 unreserved chars [A-Za-z0-9.-_~]
Hope that helps.

@jmcmurry your point in https://github.com/ga4gh/vr-spec/issues/32#issuecomment-500623542 is well taken:

If you take no other advice from me, that is OK but please please do not embed the type flag in the prefix if you include it at all. My comment from april above still stands.

And yes, I agree that the type (if used at all) does not belong in the namespace. I'd like to clarify that the above proposed ga4gh.vr namespace is for the VR specification, not any specific data type (I believe this is what @larrybabb also intended in the following ga4gh-vr proposal from https://github.com/ga4gh/vr-spec/issues/32#issuecomment-500564929). This is to avoid conflict with other standards that ga4gh may build and represent as CURIEs.

Regarding @susheel's comment above. Could you clarify that the consensus decision you made regarding slashes is related to naming concepts related to files and not necessarily about Ids? I read through most of the issues you referenced and it seemed to be mostly about dealing with the representation of hierarchical file system structures and how to flatten them without incurring the cost of including the slash in the names.
If this consensus has a direct impact on constraints related to ids or identifiers (at least the value that is after the namespace) then it would be helpful to know.
I do think the general concern about slashes may apply generally, but I think I lost the direct line of reasoning related to our context.

Today we finished discussion on this issue, and have come to the consensus to adopt @reece's proposal above:
ga4gh:<type>/<digest>
However, we REQUIRE that only the <digest> be used to generate a computed Id. This change is being introduced to allow for future backwards-compatible changes to the id structure.
The use of ga4gh as the namespace is being discussed with GA4GH Work Stream leadership.
As the strongest dissenting vote to adopting this proposal, I want to be clear that there are theoretical advantages to it. My primary objection is that the observed drawbacks of implementing it will outweigh these potential advantages, which I am concerned will not be realized.
In recognition of approaching deadlines for PRC submission, further discussion on this topic will be considered only after submission on June 24th, 2019.


This still does not fix post 30 seconds loops

If problem exists in main lib, I'll have the problem here too.
This is just a basic implementation to test as it came out.
Their save file utility is broken on windows, can't save.
Even if it worked, the defaults are badly set, audio comes out bad, clipping, etc.
I've redone that bit to be a bit better but still has a ways to go.
I'll take a look on the main lib and update here when there are news.

Oh thanks. Wrong repo, sorry. Plese delete this issue (not just close it). Thanks and good luck.


remove proc model deps

As of 8.2.3 we don't need these anymore I think, assuming tests pass (!)

Thanks.  I don't really know why those dependencies were there.

Thanks.  I don't really know why those dependencies were there.


[AutoTVM][RPCRunner] timeout is not passed correctly

If we hand-over the timeout to the constructor of the LocalExecutor, like done in the LocalBuilder class it seems to solve the issue and the timeout is now correctly passed.

relates to this 6924 issue.

@merrymercy as you suggested I set the constructor argument to (timeout * (self.n_parallel + 1)), also changed the self.timeout in the same way. Hope this is the correct way to do it. For n_parallel=None the base class Runner sets to cpu count, which seems to be working correctly. Hope now it's ok.

You should only change the timeout setting in LocalExecutor.
The self.timeout is used in other places and it is correct.

ok, thank you!


Update Buster EOL in debian.md

Use the scheduled support date for Buster LTS in 2024. It seems misleading to show the current EOL as 2022.
Source: https://wiki.debian.org/LTS

Thanks, it's still very confusing because the coverage of LTS isn't easily guessable. Can you add a line about the debian-security-support package as well?

Thanks a lot!💯


Add timeout in clients

Here is the code to make it possible to set a timeout value in xhr.
Any comment or improvement to make to make it in the repo?
Best,
Romain

@romainreuillon Thank you for also updating fetch interpreter. This change would also benefit from tests, I think it should be possible to set up a relevant interaction with stub-server.

@julienrf Thanks for the guideline.
I'm gonna try to implement a few test. I am trying to understand how the test suite works and where the endpoints used by the tests are being implemented.

I implemented a unit test for the timeout. I implemented the timeout in http4s client, fetch and xhr. For these client the test passes.
I didn't find how to implement it in akka-client in a timely manner, could you give me a hand on this one?
Are there other clients that I have missed?

Of course you can also implement timeouts for akka-http client, but then you would need to look into how to implement it, probably this page is relevant - https://doc.akka.io/docs/akka-http/current/common/timeouts.html.

Also you can see in CI logs that sttp-client has also failed, so you need to implement timeouts for it too. Otherwise you could just create a new suite with its new endpoint for timeout testing and only have it implemented by specific interpreters you have implemented the timeouts for. Now your tests are in the main suite, which is implemented by all interpreters, even those you currently have not modified.

sttp-client timeout is now implemented and all test are okay on my computer

I am unsure on how the modification I made triggered this test errors. It seems related to some akka server config... Any idea?

The errors I see for 2.13 workflow seem to be related to @nowarn annotations.

The @nowarn were in the code already. Should I remove them (as it seems unrelated to the timeout implem) ?

Hey @romainreuillon, thank you so much for addressing all the points we’ve made. Yes, it’s true that the @nowarn annotations were there before your changes. I don’t remember why we introduced them, to be honest. It seems that only now they create these compilation errors, so could you try to remove them?

I've just removed them

Anything left preventing to merge this PR?

Dear @julienrf,
thank you for having taken the time to review this PR. I addressed the issue you raised about this PR.
best,
Romain

@julienrf I'm back from vacation. I saw that you requested one change concerning sttp tests. Is that all what is left before merging or did I miss some other points?

Thank you so much Romain for your work! I’ve pushed an additional commit to my fork to resolve the binary compatibility issues (hopefully). Do you mind fast-forward-merging it to your fork?
https://github.com/openmole/endpoints4s/compare/timeout...julienrf:endpoints:timeout

I just fixed the code style, please merge my last commit again: https://github.com/openmole/endpoints4s/compare/timeout...julienrf:endpoints:timeout

Thank you Romain, this has been released in 1.8.0


Add mibeacon2 spec to yeelink.remote.contrl

The action of yeelink.remote.contrl is invalid for me, and it works correctly after add mibeacon2 spec.

Thanks! Probably you using outdated gw firmware

Yes, but the new gw firmware is not supported so I can't update.

What fw do you have?

Xiaomi Multimode Gateway 1.5.0. So maybe I can update fw (to 1.5.6), and use the key already saved in /config/.storage/xiaomi_gateway3/keys.json?

Yes you can. It's better to use fw 1.5.4+

https://github.com/AlexxIT/XiaomiGateway3/releases/tag/v4.0.6


Add is_list_member method

Implementation a bit sloppy, but a method like this would provide a function that matches the is_list_function described in the docs / resolve Issue #697.
Twitter replies to show_list_member with this error when the user isn't in the list:
tweepy.error.TweepError: [{'code': 109, 'message': 'The specified user is not a member of this list.'}]

This seems like an unnecessary convenience function for something the user should handle.
Instead, the documentation should simply be updated to reflect the removal of API.is_list_member.
See #697.


Why plugin install skipped?

Hi guys,
I have a problem about installing plugin.
Fisherman display "1 plugins/s skipped(plugin name)" when I try to install plugin like the below.
$ fisher list
* debug
* spin
> vibrant

$ fisher install pure
1 plugin/s skipped (pure)
No plugins were installed.

Why plugin install skipped?
Fish shell and Fisherman's version:
$ fisher -v
fisher version 1.3.1
$ fish -v
fish, version 2.2.0

Thanks.

@anatoo That means that your fishfile got corrupted somehow. Fisherman thinks pure is already installed, hence it skipped it.
$EDITOR $fisher_file
# remove `pure` and try again

If you still have problems you are welcome aboard join.fisherman.sh.

@bucaran Thanks for quick response.
I removed "pure" from $fisher_file and my problems are resolved!

@anatoo Do you have any recollection of the steps you made that led to the file getting corrupted?
I'll confess I have experienced this a couple of times too, but I have never been able to repro the problem.

@bucaran I uninstalled fisherman several times because fisherman seems to be broken when I installed some bad plugins.
Probably I forgotten to remove "~/.config/fisherman" on uninstalling fisherman.

Ok, I'll see if I can find something, thanks for reporting this.
By the way, which "bad" plugins?

Sorry I forgotten which plugin. Some prompt plugin output many errors after the installation and just seems to be broken.

Alright, perhaps it was one o the git_util plugins that were renamed recently.


How to reset the form after async call

Say I have a login form that submits credentials to my api server. I don't want to call this.reset() in the components submit handler because I'm not sure yet whether the user logged in successfully.
So my form component listens on something like auth.isLoggedIn from global state and in componentWillReceiveProps I check the value of this prop. If nextProps.isLoggedIn is true, I redirect and now I want to reset the form. The trouble is, resetting the form within componentWillReceiveProps leads to an infinite loop. So the question I have is where is the best place to call reset without getting into this issue?!
Thanks!

I'm not sure if this is the suggested way to do it or not. I did something like:
    dispatch({
      type: types.CREATE_POST_SUCCESS,
      post: res.body
    });
    dispatch({
      type: "REDUX_FORM_RESET"
      form: "newPostForm"
    });

The actions are exported now.
import {reset} from 'redux-form';
...
dispatch(reset('myForm'));

In the reducer, how would the resetForm method be called?

Oh, I just realized that just dispatching the reset action is sufficient, I don't have to call resetForm manually.

I'm dispatching reset('myForm'), which successfully resets all of the text input fields but not the files input field. Do I need to do something in particular to reset that?

the textarea component is not cleaning using dispatch(reset('myform')) :(


Add missing license information to your deployed Maven artifact

What module does this apply to?
All
Description what you'd like to happen:
There are tools such as "OSS Licenses Gradle Plugin" (https://github.com/google/play-services-plugins/tree/master/oss-licenses-plugin) or "Gradle License Report" (https://github.com/jk1/Gradle-License-Report) that are used to generate license reports and license screens for apps.  They pull the license information from the Maven Dependency Pom file.  Material Dialogs is one of the few projects that has no licence information in the generated Maven pom file (in our project we have more than 150 dependencies (including transitive dependencies)... and Material Dialogs is 1 of 3 projects (out of the 150+) that is missing licensing information.
Example from Maven Central for Dagger (which includes the correct license info)  (https://search.maven.org/artifact/com.google.dagger/dagger/2.24/jar):
  <licenses>
    <license>
      <name>Apache 2.0</name>
      <url>https://www.apache.org/licenses/LICENSE-2.0.txt</url>
    </license>
  </licenses>

It would also be nice to have the project URL in the pom file too.  Example:
<url>https://github.com/google/dagger</url>

This is probably a bug or something missing from bintray-release, the plugin that publishes releases of this library. I do not generate POMs.
Bintray says the default license for publishing is Apache 2.0, so there should be nothing more for me to do there. I also already specify a website in the publish configuration as well.
https://github.com/afollestad/material-dialogs/blob/f08de3195463847167473fb688e6e82bc34e07ab/bintrayconfig.gradle#L49

You are correct... you don't produce the pom.xml yourself.... you use the bintray plugin (which generates the pom.xml for you).  I don't have experience with the bintray-release plugin (we publish to Maven Central instead), I tried to see what might be missing in the material-dialogs project, but couldn't identify what the issue was... but I noticed that the actual published pom.xml files are missing the license AND website.... but other projects that are published to bintray seem to have licence and website data in their pom.xml files.
Looking at the generated pom.xml on bintray, you can see that the pom.xml file is missing the license information.
pom.xml file for "core":
https://jcenter.bintray.com/com/afollestad/material-dialogs/core/3.1.1/:core-3.1.1.pom
To see all of the published aars and pom.xml files you can browse the files here:
https://jcenter.bintray.com/com/afollestad/material-dialogs
I have wondered if the license part of the bintray-release plugin does not take the default "Apache 2.0" if your groupId starts with "com" (Commercial)...  just a thought...

@afollestad Can you fix this? This is literally the only library I'm using that does not publish it's license.


Scope of NixOS and SELinux

Issue Description
Determine how to get SELinux running under NixOS
Steps to Reproduce (If applicable):
Acceptance Criteria (How do we know when this is done?)
Related Tickets
Additional Info
Output of uname -a:
Environment (physical, VM, cloud provider, etc.):
Other Relevant Info:

@nshalman what is this ticket for?

For actually getting selinux stuff working.


So we don't pretranslate everything

This change is

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

Project coverage is 56.67%. Comparing base (bdf43fa) to head (87388c5).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #519   +/-   ##
=======================================
  Coverage   56.67%   56.67%
=======================================
  Files         299      299
  Lines       15626    15627    +1
  Branches     2154     2155    +1
=======================================
+ Hits         8856     8857    +1
  Misses       6114     6114
  Partials      656      656

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


Token better readability & fix undefined session variable

This commit will fix the undefined session variable issue & will format the token information.

Coverage remained the same at 100.0% when pulling deae56d73e40eab0e8968867c63f2b14b6a8247e on sohelamin:patch-1 into 343d9930bd124319e6d53a8934d3372cb330302e on thephpleague:master.

Coverage remained the same at 100.0% when pulling deae56d73e40eab0e8968867c63f2b14b6a8247e on sohelamin:patch-1 into 343d9930bd124319e6d53a8934d3372cb330302e on thephpleague:master.

Coverage remained the same at 100.0% when pulling deae56d73e40eab0e8968867c63f2b14b6a8247e on sohelamin:patch-1 into 343d9930bd124319e6d53a8934d3372cb330302e on thephpleague:master.


CudaFromNumpy Bottleneck Performance Issues

Hello @dusty-nv !
I have been running performance tests with a sample resnet18 network on images.
Currently there is one bottleneck to the whole system:
Total amount of images = 8006
Image dim = 224x224
Platform = python
CudaFromNumpy (over 8006 imgs)= 26.22 secs
cuda_img = jetson.utils.cudaToNumpy(img)
Resnet18 Total Inference Time (over 8006 imgs)= 16.22 seconds
Overall Total = > 42 sec
We spend more time moving an array to GPU than doing inference!
This is turns converts our 500FPS system --> 190 FPS.
As you can see there is a huge bottle neck when it comes to doing inference == The biggest one being copying the numpy array to the GPU to be used by cuda.
Now I know that usually its smarter to copy larger sized arrays in order to see the speed increases... but its a shame that the biggest bottleneck to the system is moving the arrays around.
Is there a way to speed this up?
Thank you!

@mbufi, using numpy for the data is not the optimal path - where is your data originating from?

@dusty-nv
I am loading the image with cv2.imread()  just to replicate the process of using a baslar camera that converts the image into a numpy array.
Should I not be using numpy? What do you suggest instead? I have to do extra preprocessing to the images such as equalizatio and specific cropping, so numpy worked the best in this case...

It would be preferred to load the image into shared CPU/GPU memory (like jetson.utils.loadImageRGBA() does) and perform extra pre-processing on the GPU, otherwise you are going to be bottlenecked with CPU.

You load in the image to CPU/GPU like so:
img, width, height = jetson.utils.loadImageRGBA(opt.filename)
This requires just passing in the filename. If I were to pass in a numpy array representing the image, would that also work? If I remember correctly, that function didnt allow me to do that.

It would need to do a similar conversion of the data as cudaFromNumpy() does.   If you need the top performance, I recommend that you either use the C++ API to jetson-inference, or dig into the C implementation of the cudaFromNumpy() extension and optimize it for your use-case.

i have the same approach, getting images from cv2 into the tensorRT inference.
maybe someon could help with  a sample-fragment how to convert?
(without saving to disk)
thx alot,
toz


Test

The build is still failing:

Link to latest CI run: https://github.com/famod/quarkus/actions/runs/666106382

Build fixed:

Link to latest CI run: https://github.com/famod/quarkus/actions/runs/666109793

Unfortunately, the build failed:

Link to latest CI run: https://github.com/famod/quarkus/actions/runs/666118907

Build fixed:

Link to latest CI run: https://github.com/famod/quarkus/actions/runs/771975014

Build fixed:

Link to latest CI run: https://github.com/famod/quarkus/actions/runs/771981254

Build fixed:

Link to latest CI run: https://github.com/famod/quarkus/actions/runs/771986573


Suggestion

When you look up a post, you could make it so you can go back to the homepage. Because after you look up a post, your stuck in that page. So a button that allows you to go back to the main page should work.

I'll make a pr with some changes I've made that add this
Test them here: https://repl-customs.codemonkey51.repl.co/ (tell me if any links aren't there)

I linked it in #14

add a back button?

I thought that my or made the icon link to the home page is that good?

When i click on the icon, it does nothing.

Yes ik I'm going to check my pr and some other stuff

@FunnyLamma just checked the repl hasnt been pulled but the code here on github does have the button working

Okay,


Rename some database model fields

Following 1eb67e4bff94da16925540552a9bdb291aa34c7d, there's a few fields I want to rename:
Realm:

restricted_to_domain -> user_emails_restricted_to_domain
show_digest_email -> digest_emails_enabled

Subscription

Delete unused .notifications.
in_home_view -> (! is_muted).  This one is tricky in that it's used in various API places, so we'll need to be thoughtful about migrating properly.

@zulipbot claim

@zy964c for this, do one migration per commit, and start with the easiest (e.g. deleting the unused .notifications), since we'll want to integrate these incrementally.


⚠ Secret Website 3 has degraded performance

In a8fad62, Secret Website 3 ($SECRET_WEBSITE_3) experienced degraded performance:

HTTP code: 200
Response time: 2680 ms

Resolved: Secret Website 3 performance has improved in c226db3.


[FIXED JENKINS-27182]: Allow to test Job DSL scripts (dry run)

In simulation mode run the DSL scripts, print them out to console log but don't actually do anything
This mode allows to test pull requests for compilation errors and allow to verify output manually prior to merging the PR containing DSL

Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests

This is something we're looking for.

+1 for this feature

As I commented on the JIRA ticket, I still think that having unit test style tests is the better option. They can be run locally by each developer, even from the IDE, in a few seconds. The simulation mode would require to commit the changes and then wait for the CI, fix any problems, commit again and so on. That does not sound like a convenient development cycle.
Logging kilobytes of raw XML output to the console log when simulating 100s of jobs does not seem to be convenient for debugging to me. If you want to see the XML, you can do that in unit tests as well. You could even attach a debugger to see what goes wrong.
I agree that the setup is a little bit more complex, but when your Job DSL scripts get more complex, you should invest in unit tests.

@daspilker I've seen your comment but I think we're talking about different things.
Firstly, unit tests are impossible to write for anyone but developers and DSLs exist for people who can't write code. Even for developers testing the DSL is extremely expensive.

Thirdly, staging guards deployment to Jenkins, DSL writer cannot be trusted and the tests should run on the Jenkins server where things are being deployed.
The scenario I'm talking about is as follows:

Jenkins is administered by people other than those writing DSLs. Jenkins admins maintain security and manage credentials.
DSL writers are not coders, they can't write unit tests and don't know Groovy
There are only two manually created jobs in the entire server:

Job Generator from Pull Request in Simulation mode
Job Generator

DSL writer edits DSL, submits pull request. Whether unit tests run on that DSL locally is irrelevant: Jenkins configuration is fluid and unless you have Jenkins configuration locally synchronized at all times there is no guarantee that the jobs generated will actually work. The PR is built in simulation mode and SOME information is presented to the submitting DSL editor allowing her inspect the changes that will happen due to PR.
Someone other than DSL writer merges the PR after review (and there has to be something to review other than DSL, like staging deployment results), Job Generator (re-)generates some or all jobs on the Jenkins.

I hate having to read XML but having simulation mode in its current form is the cheapest implementation way to currently inspect what the jobs will ACTUALLY look on the Jenkins where you're deploying them.
Ideally there would be some job generation failures that would prevent job from being generated when referenced Jenkins resources cannot be found, or we would stage changes by generating disabled jobs with some prefix (e.g. PR<#>-) and some button would allow to drop such staged job, etc etc.
I'm very open to suggestions on how this can be implemented given Jenkins limitations.

So, I guess there are still enough people left, who do not do this "DevOps" thing... :smile:
Let's have a look at your changes. You need to add the simulation mode to all JobManagement methods which modify state, e.g. createOrUpdateConfigFile, createOrUpdateUserContent and queueJob. And the data in javaposse.jobdsl.plugin.DescriptorImpl should not be modified when running a simulation. Then add tests to JenkinsJobManagementSpec and ExecuteDslScriptsSpec.
It would also be helpful to not log the XML for unmodified items. If it can be implemented easily, the log should show a diff of the XML so that changes are visible.

Yes, not everyone can do DevOps and even if you can UnitTest the DSLs to find the syntax errors I would see this as an integration test. Both are valuable and should have a different focus.

I have it in my queue to work on this this week.

@daspilker Quick question - why do you want me to modify the API for createOrUpdateConfigFile, createOrUpdateUserContent and queueJob? This either requires changes in the signatures of all the public APIs and creating overloads for real mode or hundreds of tests have to be modified.
The current implementation assumes that simulation mode is specified at the JobManager level and the above methods would infer their behaviors from that. Would that be acceptable?

@daspilker is there a problem with a build system not picking up the latest sources from the PR?
:job-dsl-plugin:compileJavawarning: [options] bootstrap class path not set in conjunction with -source 1.6
warning: No SupportedSourceVersion annotation found on org.kohsuke.wpc.ProcessorImpl, returning RELEASE_6.
/scratch/jenkins/workspace/plugins/job-dsl-plugin/job-dsl-plugin/build/generated-src/stubs/javaposse/jobdsl/plugin/InterruptibleJobManagement.java:10: error: InterruptibleJobManagement is not abstract and does not override abstract method simulation() in JobManagement
@groovy.transform.ThreadInterrupt() public class InterruptibleJobManagement
                                           ^
Note: /scratch/jenkins/workspace/plugins/job-dsl-plugin/job-dsl-plugin/build/generated-src/stubs/javaposse/jobdsl/plugin/InterruptibleJobManagement.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 error
2 warnings
 FAILED

https://github.com/arcivanov/job-dsl-plugin/commit/432f6c5662d9aa88b02f68d45243c1d34eb6cbf9#diff-307575c50da6b9a9cb9d2e84e7a93297R167

I would prefer to use dry run instead of simulation mode, because that's an established term. Please change the wording.
The dry run flag is only used in JenkinsJobManagement, so it should not be exposed in JobManagement or AbstractJobManagement. Just add a field and a getter/setter to JenkinsJobManagement. Do not change any signatures.
Do not reorder any imports, keep the diff at a minimum.

will do, thanks

Yeah, so there are problems with actual diffs: XML is unstable in Jenkins and produces lots of junk like this. I don't think unified diff will be any better.
Which also means that functionality here doesn't work pretty much ever, since for all practical purposes documents are never identical.
Any thoughts as to what would be less verbose than full printout and but still provide useful diff-ish output @leonard84, @analogj @lanwen ?
Diff (#14): text value
Old node:  <entry ...>
          </entry> at /project[1]/publishers[1]/hudson.plugins.cobertura.CoberturaPublisher[1]/failingTarget[1]/targets[1]/entry[3]/text()[3]
Old value:

New node:  <entry ...>
                    </entry> at /project[1]/publishers[1]/hudson.plugins.cobertura.CoberturaPublisher[1]/failingTarget[1]/targets[1]/entry[3]/text()[3]
New value:

Diff (#14): text value
Old node:  <targets ...>
          </targets> at /project[1]/publishers[1]/hudson.plugins.cobertura.CoberturaPublisher[1]/failingTarget[1]/targets[1]/text()[4]
Old value:

New node:  <targets ...>
                    </targets> at /project[1]/publishers[1]/hudson.plugins.cobertura.CoberturaPublisher[1]/failingTarget[1]/targets[1]/text()[4]
New value:

Diff (#14): text value
Old node:  <entry ...>
            </entry> at /project[1]/publishers[1]/hudson.plugins.cobertura.CoberturaPublisher[1]/failingTarget[1]/targets[1]/entry[4]/text()[1]
Old value:

New node:  <entry ...>
                        </entry> at /project[1]/publishers[1]/hudson.plugins.cobertura.CoberturaPublisher[1]/failingTarget[1]/targets[1]/entry[4]/text()[1]
New value:

Diff (#14): text value
Old node:  <hudson.plugins.cobertura.targets.CoverageMetric ...>METHOD</hudson.plugins.cobertura.targets.CoverageMetric> at /project[1]/publishers[1]/hudson.plugins.cobertura.CoberturaPublisher[1]/failingTarget[1]/targets[1]/entry[4]/hudson.plugins.cobertura.targets.CoverageMetric[1]/text()[1]
Old value: METHOD
New node:  <hudson.plugins.cobertura.targets.CoverageMetric ...>CLASSES</hudson.plugins.cobertura.targets.CoverageMetric> at /project[1]/publishers[1]/hudson.plugins.cobertura.CoberturaPublisher[1]/failingTarget[1]/targets[1]/entry[4]/hudson.plugins.cobertura.targets.CoverageMetric[1]/text()[1]
New value: CLASSES

Can you exclude empty New value:  (Old value:  etc) from output?
Think this enough to understand the main changes

Those are not empty values, those are multi-line whitespace strings that I forgot to quote (I'll fix it). I can try to diff ignoring whitespace, but that may produce non-deterministic results, I guess.
Any other ideas for diff methodologies?

Setting XMLUnit to ignore whitespace might be a first step (from Stackoverflow XMLUnit.setIgnoreWhitespace(true))

@leonard84 :) I am aware on how to use that library.
Ignoring whitespace, however, may cause functional problems for DSL plugin itself, as whitespace may or may not be functionally significant (who knows what any particular plugin does or needs) and XMLUnit may return true from Diff.isIdentical() where there are substantive changes.
Also, as I pointed out, Jenkins configuration files seem not be order-stable (due to people using HashMaps instead of LinkedHashMaps for data storage, I guess) resulting in variable order of elements that is not functionally significant but does pop up in the diffs creating a mess.

@arcivanov Maybe we should split the diffing from this commit into an enhanced version, a simple smoke test style dry-run would be good enough for me. And the diff would also be interesting for the normal mode, so it would make sense to put it into a separate issue/pr.

Makes sense. I am good with simple config dumps as well.
I'll publish the changes with no diffs for now then.

Add more tests, e.g. for ExecuteDslScripts in ExecuteDslScriptsSpec.

@daspilker understood, will fix
Re obsolete code: it's not quite obsolete as scheduled for further implementation (informative diffs).
Have you given it a thought re XML order stability and identical comparison? While it works great in unit tests in vivo it seems that XMLs generated and XMLs actually stored always differ in element order and/or whitespace and that condition is never triggered.

Re XML order stability: the DSL should produce identical XML in two identical run (except for some element which use a random number), so there should be no problem. If that's not the case, we should fix that (in another PR).

I played around with computing diffs and I understand the problems better now. See https://github.com/daspilker/job-dsl-plugin/commit/0c8737be84693abfab2333d29d07db711beb1550 on https://github.com/daspilker/job-dsl-plugin/tree/verbose.
I would like to move the logging to a separate pull request and deal with the problems there. Can you remove the logging stuff from this PR?
And add some tests to ExecuteDslScriptsSpec to the test dry run mode changes for ExecuteDslScripts.

What do you mean by "move the logging to a separate pull request"?

@daspilker ping?

To bad that it wasn't included in 1.40 release.

@leonard84 sorry, but I don't understand what @daspilker wants from this commit anymore.  Without logging dry run mode is useless as you can't see what was actually generated, so I'm standing by for more instructions.

@arcivanov well I would be fine with checking if there are any warnings, e.g. missing/wrong plugin version, wrong credentials id, and so on. Which should mark the dry-run as unstable.

There are still several issues with this pull request.

Logging the config XML to the console output may disclose sensitive information. E.g. the XML can contain passwords or other credentials which should not be logged. Logging is not essential for a dry run and should be moved to another pull request which can then deal with the details.

Executing a script with dry run enabled may fail, but succeed when running the same script with dry run disabled. Run the following examples on a clean installation:

folder('foo')

job('foo/bar')

customConfigFile('myCustomConfigFile') {
  content('test')
}

job('example') {
    wrappers {
        configFiles {
            file('myCustomConfigFile') {
                variable('CONFIG_FILE')
            }
        }
    }
}

The problem is that the folder and config file are not created, but are checked for existence when validating the job creation.

DSL scripts can contain arbitrary code. This code may have side effects, e.g. creating files, sending some data to a REST service. These side effects may be undesirable when performing a dry run. It may be a good idea to inject a {{DRY_RUN}} variable into the script binding so that scripts can detect a dry run and act accordingly. This should also be mentioned in the help text.

Tests for {{ExecuteDslScripts}} are missing. There should be test cases for the examples that I mentioned above, for the {{DRY_RUN}} variable and test that make sure that the descriptor is not modified.

On my CI instance, I solved this with a different method.  I create a folder and generate the CI scripting relative to that folder.   This works quite well and maintains the permissions that each job would get generated with.  The only issue in this case is that newly generated jobs could start running before they get disabled.  I have some changes i the work for this (automatic disabling of jobs)

+1 for this feature

+1 for this feature

+1 for this feature.

+1 for this feature

+1 cc @arcivanov

Can one of the admins verify this patch?

+1 for this feature

+1 cc @arcivanov

This is really a glorified +1, but I think that the move to Jenkins pipelines actually makes this more relevant. I'd love the ability to have PRs on my set of job dsl scripts where I can do some actual validation of them without trying to set up some large dev environment. Specifically I'd really like to do some basic syntax/linting of the groovy scripts and some sanity check through the DSL plugin using a dry-run mode. Without that, it doesn't make any sense to enforce PRs or anything on these scripts - the only way to "test" them is to commit and see what happens, or to try and set up another Jenkins instance in a VM that we run it on.

+1

@daspilker If the pull request was cleaned up with the actions you suggested way back on 13 Nov 2015 would this be acceptable to submit? (turn off logging, add DRY_RUN variable, add ExecuteDslScripts tests)

Build finished.

Any update on this? I want to be able to execute a seed job, have it output to the console what it is going to do, and then wait for user input to confirm- any way of doing that?

Still looking for this in 2020

With the addition of https://github.com/jenkinsci/job-dsl-plugin/wiki/Dynamic-DSL (which in itself is a cool feature) and closing issues like https://issues.jenkins.io/browse/JENKINS-55379 with the reason that it is already supported by the dynamic dsl, having a dry-run is a must.

The dynamic DSL is only supported when running in Jenkins, e.g. it is not available when running from the command line or in the Playground.

@daspilker:

As I commented on the JIRA ticket, I still think that having unit test style tests is the better option. They can be run locally by each developer, even from the IDE, in a few seconds. The simulation mode would require to commit the changes and then wait for the CI, fix any problems, commit again and so on. That does not sound like a convenient development cycle.

Well, if we want to use Dynamic-DSL then unit testing is not possible anymore. The new cycle is to commit and fail the seed job which is much worse then testing the new stuff on a feature branch and having a dry-run.
Another alternative would be to generate the DSL API classes on the fly, like it is already done for the API viewer, and let us download a .jar with the current API.

+1

Is there something we can do to help this PR get merged?


Make sigmoid layer for binary classifiers

Currently, classification is done by just using the sigmoid activation function, which is basically just regression. This could potentially lead to predicted probabilities being outside of [0, 1]. Instead, for classification we should use a normal ELM with ReLU or another activation to get raw predictions and apply the sigmoid to those outputs similar to the way we use a softmax layer for multiclass classification.

Possible options for getting predicted "probabilities" are:
1. Do nothing
        Since the ELM is minimizing the MSE, most of the time this would keep the predictions in [0, 1] but there could be times
        when the predictions fall outside this range, as in a linear probability model.

2. Apply the sigmoid function to the predictions
        This would always constrain the outputs to [0, 1]. However, this would often be problematic because the output from the
        ELM is already in one class or another and applying the sigmoid function would change the predicted class. For example, if
        the threshold is the usual 0.5 and the ELM output a prediction of 0.4, which minimizes the MSE, then applying the sigmoid
        function would give an output of 0.598687660112452, which would be predicting a different class.

3. Use a clipping function.
        This would ensure that all the predictions would be in [0, 1] and it would also not change predicted classes. However, it
        would technically output a probability, like the sigmoid function would. Also, we would have to choose some range like
        [1e-5, 1-1e-5] since no observation will have a probability of exactly 0 or 1.

Overall, using a clipping function is probably the best option because it does not change the optimization problem that the ELM is solving or change the predicted classes, keeps the prediction in [0, 1], and is probably doesn't make much of a difference for predictions outside [0, 1]

It actually doesn't make sense to have categorical treatments or outcomes, so we can get rid of them.


[Platform][There are no documented limits for Input.Number max value]

Platform
What platform is your issue or question related to? (Delete other platforms).

[ ] .NET HTML
[ ] .NET WPF
[ ] Android
[ ] iOS
[ ] JavaScript
[ ] UWP

Author or host
Are you an author (like sending something to Outlook), or a host that is rendering your own cards? If host, please specify the corresponding host (app) name.
Teams app
If you're an author, who are you sending cards to?
Version of SDK
What version are you using? Ex: NuGet 1.0.2, or latest main, etc...
Details
Explain your issue. If you just have a question, please post on StackOverflow instead.
In Teams the input.number is not allowing more than a 10 digit number. This was an arbitrary value picked by our channel. The spec doesn't define the max value allowed for this field. Without a known, well defined value there are different expectations from users on what should work resulting in customer escalation.

We should document our limits here.

tldr; we don't have set limits for max today, so we should do two things:

Add a min / max value across all platforms (which is the same value)
Document this number

Hi @jonmill, @RebeccaAnne , @paulcam206
Is there any update on this issue?
We are also facing this issue
Short Description: Input.Number is not allowing more than 10 numbers
Description:
In mobile number scenario if user enter mobile number more than 10 digit then at the validation time we are trying to show that number on card but Adaptive card not allowing to display that number and throwing exception as number consist of more than 10 digit.


Ip viscosity pep8

Implements Interior Penalty viscosity scheme for discontinuous velocity fields. Also adds (optionally) grad-div term, and makes the -grad(H)/H*stress term optional. Defaults are the same as before, i.e. only include div-grad term but do include -grad(H)/H term. The opposite choice for both, is more standard for SWE coastal models with some sort of turbulence scheme.
Test added to swe2d/test_steady_state_basin_mms.py
Any opinions on option names? Not sure tensor_form (for "div-grad only") is all that standard, so maybe use_div_grad_only_viscosity is better - or have a include_grad_div_viscosity_term instead?

Is the travis failure just a timeout?

What is the factor 2 in the non-tensor form?

Hm, I guess it depends what you compare with. sym() has a half in its definition - so my definition is really div[nu ((grad u)+(grad u)^T)] which for constant nu gives nu [nabla^2 u+grad(div(u)] and so the second term drops out for divergence free flow, giving the expected result.

I  used similar formulation in 3D but without the factor 2 to match with analytical solution.

Not sure - where does the analytical solution come from?

OK, that makes sense. I used a test case where the initial condition for u was a heaviside step. When you apply constant diffusion it turns into an erf function which is easy to check. I'll double the check the test case and get back to you.

About the options, maybe include_grad_div_viscosity_term is the cleanest?

with_grad_div_viscosity ?

Sure.

OK, I've ported the test case to 2D, see
https://gist.github.com/tkarna/f57043f79a88839bdf13
Setting use_tensor_form_viscosity = False seems to diffuse the front a bit too fast, and the solution is closer to the analytical if you drop the factor 2 from the definition of the stress. I don't know if that's expected or not... use_tensor_form_viscosity = True gives solution that matches well with the analytical.

Ah I see now - your analytical solution is not divergence free. So the full viscosity term is:
d/dx_i \nu (d/dx_i u_i + d/dx_j u_i)
Only if \nu is constant we can rewrite this into
\nu \nabla^2 u + \nu grad(div(u))
Thus for incompressible flow the second term drops out and you get the same as 'tensor form' viscosity.


How to use my own test programs?

What linker_script/compiler options should I use for my own C programs? Thanks!

Have you resolved this issue? I have the same question

Here is an example makefile and linker script;
https://github.com/ultraembedded/fpga_test_soc/tree/master/src_c


feat: introduced session timeout check

This PR addresses #28.
It introduces a new SCRATCH_ORG_LOGIN_TIMESTAMP env parameter that tracks session timeout.
When building the Salesforce environment during tests, we'll check for session timeout and halt the process with a clear error message if the session has timed out.
Closes #28

Thank you for your contribution @pozil, hopefully we will be able to review before end of the week and proceed with merging the changes

Thanks for the review, happy to help.


Generate docs for the headlamp-plugin lib

Current situation
The docs are generated from the frontend's plugin files which will be confusing for the user to check when creating the plugins, as they will not be importing things from the frontend directly.
Ideal future situation
Once #388 is merged, the types will be generated from the frontend but present in the headlamp-plugin package together with a new lib/* directory. We should make sure that docs for these are being generated and showing up properly on the docs viewer.

I'll take a look at this after reviewing #388


Unit tests for jodd-vtor module to increase code coverage from 51% to 99%

Hi @igorspasic
This pull request is focused on jodd-vtor module. This pull request increases code coverage of the this module by 48%. Code coverage is measured using JaCoCo.

Metric
Before
After

Coverage%
51%
99%

Lines Covered
208
472

Total Lines
475
475

Please let me know if you have any questions.
Mohd Farid
DevFactory - Code Quality Team.

Just started reviewing :):rocket:

Wohoo!
Thank you, just merged!


[Bug]: Files downloaded with duplicate name are replacing existing files instead of renaming with numbering like filename(1).txt

Minimal, reproducible example
const client = await page.target().createCDPSession()
    await client.send('Page.setDownloadBehavior', {
        behavior: 'allow',
        downloadPath: path.resolve(__dirname, downloadPath),
    });

Error string
none
Bug behavior

[ ] Flaky
[ ] PDF

Background
No response
Expectation
Download duplicate files with a number
Reality
downloading file with same name replaces existing file
Puppeteer configuration file (if used)
No response
Puppeteer version
21.7.0
Node version
v16.16.0
Package manager
npm
Package manager version
8.19.2
Operating system
Linux

This feature is not part of Puppeteer's API as you reach out to the CDP directly. Would you mind filing a feature request for crbug.com and note that https://chromedevtools.github.io/devtools-protocol/tot/Page/#method-setDownloadBehavior is deprecated. Try using Browser.setDownloadBehaviour instead.


productoftwosparsematrix.c

This is my second contribution
This problem is the solution fo  the program multiplication of 2 sparse matrix

You can add your name to the readme file with your GitHub username You can refer to the instructions in the readme for more information, Please don't Add the DSA question to the repository, We are not taking this kind of PR. Thanks


fix console path

@indivisualvj Please pull the newest master and rebase your branch to fix the tests.


Unable to connect to remote server

hello!
i have a macmini. on this, remotebuild is running.
Visual Studio 2017, TACO:
i'm entered IP, Port, Security Mode false, and the PIN in the iOS config.
i'm clicked run , data transfers and on the macmini remotebuild handle the incoming data.
all is okay.
Visual Studio Code (have to use it).
i'm opened the integrated terminal and entered "taco remote add ios".
i'm entered IP, Port and PIN.
after entered PIN i get the error:
TACO5601: Unable to connect to remote server. Make sure that the remotebuild server is running at .....
but why? i saw it works in Visual Studio 2017 few moments later.
is it a bug of the taco cli? or is special flag missing, what is set by Visual Studio 2017?

okay, found solution.
i had to do this command first:
taco remote add   (without plattform)
after this, taco build ios works.


.Net: wrapping AddDimensionDependentDimensionWithVehicleCapacity

Hello All,
I'm trying to build the OR-Tools with some modifications to the SWIG interfaces so I can open up the AddDimensionDependentDimensionWithVehicleCapacity for access in C#. I know people have requested this and it's been an issue to get done, but I was hoping to help solve this. I followed the steps here in my initial builds of each branch https://developers.google.com/optimization/install/dotnet/source_windows.
So far I've been able to successfully build the DLLs and Nuget Packages for OR-Tools using the 6.7.x branch, the stable branch, and the 7.1 version release version. I've come into various issues within each version.
---6.7.x---
I'm able to build the DLLs and I've added them to my solution and they work. Just like before, but regardless of the changes I make to the SWIG interface I can't seem to access the method. I've done as little as just not ignoring the method, and as far as removing all ignores from the wrapper, but I've had no luck.
---7.1---
I'm able to build the Nuget package and add it to my solution. I can see I have access to that method via intellisense, but when I run the program I get a BadImageException that points to a line where the Google.OrTools.runtime.win-x64.dll is being imported in the SWIG generated code.
---stable---
Again I'm able to build the nuget packages and add them to my branch like before. I have access to the method (intellisense), but when I run the program I get a BadImageException that now points Google.OrTools.Dll itself.
For all three, I've tried modifying the csharp/dotnet csproj file in OrTools/dotnet, or OrTools/csharp depending on the version, to remove references to linux and os. I've tried changing how the Google.OrTools.runtime.win-x64dll is found, and lastly I've tried forcing the dlls to compute for a CPU of x64 or x86, neither of which resolved the issue.
Any help would be much appreciated. All I know about SWIG is what I've learned from experimenting with this and I hope that I can help resolve this issue.

few things:

v7.1 is a tag and our release/default branch stable now point on it.

master branch is our development branch any PR must be done against it.

The problem is not to unignore the method but to correctly typemap the arguments.
note: you can see the .cs code generated by swig in ortools/gen/ortools/constraint_solver/RoutingModel.cs IIRC

Thanks for the timely response.
I think I have the typemapping setup correctly, but after building it I get 'The type initializer for 'Google.OrTools.ConstraintSolver.operations_research_constraint_solverPINVOKE' threw an exception.' with an inner exception of 'DllNotFoundException: Unable to load DLL 'Google.OrTools.runtime.win-x64.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)'.
I have the win-x64 Nuget package added, and it contains that dll. I can't seem to figure where that needs to get adjusted. Any idea?

nuget has a local cache for package, we have version number only commit dependent and our makefile may miss few dependencies so sometime dotnet cli will use the wrong package (i.e. the previously build and cached).
Try to do a make clean_dotnet; make dotnet to regenerate the dotnet part only.
note: you can also try dotnet nuget locals all --clear to  only clear the nuget cache (clean_dotnet call it BTW)

mark it duplicate of #339

While I work on this I saw you added this to To do in Kanban 7.2. Does this mean you plan to add/or at least attempt to add this for a 7.2 release this month?

When I build Google.OrTools using make dotnet it doesn't build the path/file ref/netstandard2.0/Google.OrTools.dll into the package. This happens in a fresh stable pull, before I've made my changes, and after I've made changes. I've tried make clean_dotnet and even manually adding the built DLL to the package, but this doesn't compile correctly. Any thoughts?

No, time dependent dimensions is not mature in C++ and too slow.
We have no immediate plans to export this in other languages.


CO-2502_Add_Organization_attribute_to_Role_information_on_CoPerson_canvas

Add Organization attribute to Role information on CoPerson canvas

This is perfect. Will merge.


docker pull access denied

Hi @tankienleong the warnings are normal since the images are built locally using the Dockerfiles. Simply let it proceed and it should build successfully


Fragment 개선

목표: 카톡처럼 완벽하게 만들기

Tracked as https://github.com/brave-people/Dev-Event-Android/issues/27


Graphic Design

Hello can you give me more informations about this project? Im a graphic designer that contributes for opensource projects like yours, so if you need some help to create a logotype or other stuff just say it.
Greetings

Hi, thank you for your interest. :)
This is a common library for our other projects. It contains components and utility functions.
We have a logotype for out main project (check it on our organisation page).
Once again, thank you. :)


There is more than one error it is not working at all screenshots are attached of the errors.

.env.txt

You'll need to copy your .env to the frontend folder as .env.local for running locally.

Ok I will try that thank you.


AttributeError: KEYPOINT_ON

❓ Questions and Help
I have  trained the network with the model : e2e_mask_rcnn_X_101_32x8d_FPN_1x
on a self  created data- set with the following script  I wrote: [coco like dataset]
for instance segmentation task and after the train has saved the last model the following error has occurred :

2019-02-27 02:52:46,742 maskrcnn_benchmark.utils.checkpoint INFO: Saving checkpoint to ./model_0180000.pth
2019-02-27 02:52:47,327 maskrcnn_benchmark.utils.checkpoint INFO: Saving checkpoint to ./model_final.pth
2019-02-27 02:52:47,806 maskrcnn_benchmark.trainer INFO: Total training time: 1 day, 1:54:59.497522 (0.5183 s / it)
Traceback (most recent call last):
File "tools/train_net.py", line 174, in
main()
File "tools/train_net.py", line 170, in main
run_test(cfg, model, args.distributed)
File "tools/train_net.py", line 86, in run_test
if cfg.MODEL.KEYPOINT_ON:
File "/home/portablelinux/anaconda3/envs/maskrcnn25feb19/lib/python3.7/site-packages/yacs/config.py", line 118, in getattr
raise AttributeError(name)
AttributeError: KEYPOINT_ON

how can I test the model ?
thank for the help in advance.

Hi,
I think that there might have been a conflict with your code.
Here is my hypothesis: maybe you have updated the repo while the model was training?
Then, the cfg would have already been created, but when you updated the code, it got reloaded in the evaluation part, and then it was expecting the KEYPOINT_ON flag to be present in the cfg, which wasn't because it was from the old codebase.
Here is my solution to solve this problem: just re-run the evaluation code by pointing to the serialized model, and it should be work fine now.
Let me know if it doesn't solve the problem.

Thank you very much for your help.
thought as  I am not very experienced , I  didn't understood the following :
@fmassa
Here is my hypothesis: maybe you have updated the repo while the model was training?
what does updated the repo  means , I might have done it by a mistake because i don't know how to do it,
and I have done some try and error.
@fmassa

Here is my solution to solve this problem: just re-run the evaluation code by pointing to the serialized model, and it should be work fine now

what is the serialized model ?
how do I rerun the evaluation code and how do I point to the serialized model?

Thank you very much for your help.
thought as  I am not very experienced , I  didn't understood the following :
@fmassa
Here is my hypothesis: maybe you have updated the repo while the model was training?
what does updated the repo  means , I might have done it by a mistake because i don't know how to do it,
and I have done some try and error.
@fmassa

Here is my solution to solve this problem: just re-run the evaluation code by pointing to the serialized model, and it should be work fine now

what is the serialized model ?
how do I rerun the evaluation code and how do I point to the serialized model?

@Idolized22 I think you might have done
git pull

in the maskrcnn-benchmark repo, after you had already started training. This changed the source code of the library, but the code that was training had already loaded most of the code, except the inference code.

@Idolized22 I think you might have done
git pull

in the maskrcnn-benchmark repo, after you had already started training. This changed the source code of the library, but the code that was training had already loaded most of the code, except the inference code.

@fmassa  , it is vert possible that I have done  that.
But I don't understand  How to do what you proposed in order to solve that.
I am very new to the field  so I need a little more detailed explanation  please.
thank you very very much for helping!

@Idolized22 just update the code to the latest version and run the testing again. It should work I believe


Include workitem result files in get-helix-payload

This change includes files uploaded by a workitem (console.log, dumps, etc). This is helpful as that way people can have everything downloaded rather than just the payload and have to figure out where to get a dump or a console log from.
Also as part of this change I changed the meaning of empty workitems as an argument. Before it would just download the correlation payloads, now it downloads the first workitem with a payload it finds. This is feedback people gave me as it is useful if you don't know a workitem name and just want to look at the correlation payload or the workitem structure to make sure you got things right when adding a new run or debugging something weird happening with the payload, etc.
Since I noticed dumps can take a few mins to download or even payloads can take more than 5/10 seconds, I added download progress to the console so that the user knows it is doing work and how much it is left to download.
Also, for people that don't care about the dump to avoid waiting for a few mins for it to download I added a flag to be able to ignore dumps from the download.
cc: @jaredpar @akoeplinger @danmoseley

Also, perhaps fix this error while you are there?
D:\git\runtime>runfo get-helix-payload -h
  -j, --jobid=VALUE          helix job id to download items from.
  -o, --output=VALUE         output directory to download to.
  -w, --workitems=VALUE      comma separated list of workitems to download.
                               Accepted values:
                               empty: download only correlation payload.
                               list: separated by comma.
                               all: download all workitems.
Extra arguments: -h
   at Runfo.OptionSetUtil.ParseAll(OptionSet optionSet, IEnumerable`1 args) in P:\runfo\runfo\OptionSetUtil.cs:line 48
   at Runfo.RuntimeInfo.GetHelixPayload(IEnumerable`1 args) in P:\runfo\runfo\RuntimeInfo.cs:line 1120
   at Runfo.Program.<>c__DisplayClass0_0.<<Main>g__RunCommand|0>d.MoveNext() in P:\runfo\runfo\Program.cs:line 93
--- End of stack trace from previous location where exception was thrown ---
   at Runfo.Program.Main(String[] args) in P:\runfo\runfo\Program.cs:line 53
   at Runfo.Program.Main(String[] args) in P:\runfo\runfo\Program.cs:line 58


warning: permanent hiding is buggy and it causes loss of menubar icons permanantly

i tried out the permanent hiding. it worked. but suddenly i cant see these permanantly hides icons any mor and even not the second devider sign. cant reach these symbols any more - even not after uninstall hidden bar.
help!!!
with every new start of the system these symbols shortly shown up as a menu item, but get lost after a split second.
what can i do - i need them.
a new installation didnt help: now even the other hidden bar symbols are not shown - so i cant do anything...
my system: ventura 13.1 - macbook pro m1 max

Same issue on my end!

The same issue here, all I want is the icons back to uninstall this.
@studiohansen / @patster98  did you find any way to get hidden icons back?

I hit this as well. The only way I could find to get the icons back was to quit Hidden Bar.
Deleting the .app and reinstalling from the app store made the bad behavior persist. I'm not sure where the settings are for this app or I would try deleting them to be able to start over and never enable this problematic setting. I'll just have to keep it uninstalled until I find a solution.

@altano Try right-clicking the "<" button (not the separating bar) when the "hidden" area are expanded might help this issue. (Although I admit it is really buggy)

Whoops, I misunderstood my issue and your right-click suggestion helped me figure it out: the apps didn't get permanently hidden, they just got lost behind my notch. Hidden Bar doesn't work with the notch.

I lost most icons, TopNotch won't work now... It should appear in menu bar but doesn't
The repo/dev should get banned from here.


add Get List of Groups

http://developer.nulab-inc.com/docs/backlog/api/2/get-groups

pull request: https://github.com/mtaniuchi/CSJSONBacklog/pull/107

pull request: https://github.com/mtaniuchi/CSJSONBacklog/pull/108
マージ済み


Specification for: DropdownMenu

Related issues or relevant information?

https://aksel.nav.no/komponenter/interne/dropdown
https://atlassian.design/components/dropdown-menu/examples

Related components:

Header

Design tasks

[ ] Design is fully specified in Figma

[ ] Design component with all relevant states
[ ] Do a accessibility test of the sketches
[ ] Functionality/animation is described and prototyped if relevant
[ ] If there are used any svgs in this component is it available for the developer? [Link]
[ ] Link to Figma design: [Link]
[ ] Pasted screenshot from Figma below :point_down::skin-tone-2:

Development Tasks

[ ] Implement in Storybook
[ ] Make sure all variants/properties is possible to turn on/off
[ ] Make sure the component is usable across different breakpoints/screen sizes

Accessibility tasks

[ ] WCAG-review

https://github.com/digdir/insights-hub/issues/26

This finding might be relevant for this component 😊

Thank you so much for sharing and linking, @indiamaydesign! 🙌

Suggestion from Team Arbeidsflate: DropDownMenu should be more flexible. @ingefossland will describe the needs.

Suggestion from Team Arbeidsflate: DropDownMenu should be more flexible. @ingefossland will describe the needs.

Still work-in-progress, but we are considering a pattern for filtering using dropdowns on desktop, with drawers on mobile. Elements inside can multiple things depending on the filter. (See attached sketches.)
To accommodate for different content and make dropdowns more flexible I would suggest:

Separating the dropdown container from the menu (menu groups and items might make sense elsewhere as well).
Consider removing initial padding on the dropdown container.
Create a pattern for drawers.

The DropdownMenu is ready for use: https://storybook.designsystemet.no/?path=/docs/felles-dropdownmenu--docs


Can't pass country to parse_address

It appears I'm not able to pass in a country-code:
addr_zagat_parse = [parse_address(addr, country='us') for addr in matched_address.addr_zagat]
Gives the error:
`---> 15     return _parser.parse_address(address, language=language, country=country)
TypeError: Parameter must be bytes or unicode`
Using the python binding!

This is a Python specific issue, so it belongs to the pypostal repo :).  I've submitted a fix there.
But, it seems all is in vain, these parameters are not taken into account:
https://github.com/openvenues/libpostal/blob/790e24bc0a42801e43b1025a44d395686885f311/src/address_parser.c#L1696-L1712
I hope to be wrong, tho'