HarmonyLib.PatchProcessor.Patch()

Good Morning,
with Version 20.1.602 i have following Error before Login!
Security Strategie Complex, XpandRole and XpandUser
If i use XpandPermissionPolicyRole, i dont get this Error.
Can you assist me, what i can do!?
You can only patch implemented methods/constructors. Path the declared method virtual System.Object DevExpress.ExpressApp.Security.AuthenticationStandard::Authenticate(DevExpress.ExpressApp.IObjectSpace objectSpace) instead.
at HarmonyLib.PatchProcessor.Patch()
at HarmonyLib.Harmony.Patch(MethodBase original, HarmonyMethod prefix, HarmonyMethod postfix, HarmonyMethod transpiler, HarmonyMethod finalizer)
at Xpand.XAF.Modules.Reactive.RxApp.<>c__DisplayClass17_0.b__0(XafApplication )
at System.Reactive.Linq.ObservableImpl.Do`1.OnNext..OnNext(TSource value) in /_/Rx.NET/Source/src/System.Reactive/Linq/Observable/Do.cs:line 38

without a sample I cannot help much

Good Morning,
ok, if you change to AuthenticationStandard, you will get this Error.
See the Code below:
Comes from RXApp.cs Line 112-122
static IObservable<XafApplication> PatchAuthentication(this XafApplication application) =>             application.WhenSetupComplete()                 .Do(_ => {                     var harmony = new Harmony("aaa");                     if (application.Security.IsInstanceOf("DevExpress.ExpressApp.Security.SecurityStrategyBase")){                         var methodInfo = ( application.Security)?.GetPropertyValue("Authentication")?.GetType().GetMethod("Authenticate");                         if (methodInfo != null){                             harmony.Patch(methodInfo, new HarmonyMethod(GetMethodInfo(nameof(Authenticate))));	                         }	                     }                 });

Good Morning,
exactly same Error here

this code is EasyTested and called from our TestApplication however it works there and all tests are green. Please try on an empty XAF solution where u install all nuget packages you use in your solution and configure init parts such as security. Post the sample for examination. Note I do not accept solutions reference directly the assemblies, only the nuget packages cause they contain logic we might miss.
Thanks for the understanding

I found a related case hopefully it same as yours with a custom AuthenticationActiveDirectory, the bot will notify u once fixed

The pre-release <IP_ADDRESS> in the DevExpress.XAF lab branch  includes commits that relate to this task:

Authentication patching failure #752

To minimize version conflicts we recommend that you use the Xpand.XAF.Core.All, Xpand.XAF.Win.All, Xpand.XAF.Web.All packages. Doing so, all packages will be at your disposal and .NET will add a dependecy only to those packages that you actually use and not to all.

Released packages:
1. [Xpand.Extensions.Office.Cloud v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Extensions/Xpand.Extensions.Office.Cloud)
 1. [Xpand.XAF.Core.All v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules)
 1. [Xpand.XAF.Modules.AutoCommit v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/AutoCommit)
 1. [Xpand.XAF.Modules.CloneMemberValue v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/CloneMemberValue)
 1. [Xpand.XAF.Modules.GridListEditor v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/GridListEditor)
 1. [Xpand.XAF.Modules.HideToolBar v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/HideToolBar)
 1. [Xpand.XAF.Modules.LookupCascade v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/LookupCascade)
 1. [Xpand.XAF.Modules.MasterDetail v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/MasterDetail)
 1. [Xpand.XAF.Modules.ModelMapper v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/ModelMapper)
 1. [Xpand.XAF.Modules.Office.Cloud.Google v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/Office.Cloud.Google)
 1. [Xpand.XAF.Modules.Office.Cloud.Google.Tasks v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/Office.Cloud.Google.Tasks)
 1. [Xpand.XAF.Modules.Office.Cloud.Microsoft v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/Office.Cloud.Microsoft)
 1. [Xpand.XAF.Modules.Office.Cloud.Microsoft.Calendar v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/Office.Cloud.Microsoft.Calendar)
 1. [Xpand.XAF.Modules.Office.Cloud.Microsoft.Todo v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/Office.Cloud.Microsoft.Todo)
 1. [Xpand.XAF.Modules.OneView v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/OneView)
 1. [Xpand.XAF.Modules.PositionInListView v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/PositionInListView)
 1. [Xpand.XAF.Modules.ProgressBarViewItem v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/ProgressBarViewItem)
 1. [Xpand.XAF.Modules.Reactive v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/Reactive)
 1. [Xpand.XAF.Modules.Reactive.Logger v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/Reactive.Logger)
 1. [Xpand.XAF.Modules.Reactive.Logger.Client.Win v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/Reactive.Logger.Client.Win)
 1. [Xpand.XAF.Modules.Reactive.Logger.Hub v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/Reactive.Logger.Hub)
 1. [Xpand.XAF.Modules.Reactive.Win v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/Reactive.Win)
 1. [Xpand.XAF.Modules.RefreshView v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/RefreshView)
 1. [Xpand.XAF.Modules.SequenceGenerator v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/SequenceGenerator)
 1. [Xpand.XAF.Modules.SuppressConfirmation v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/SuppressConfirmation)
 1. [Xpand.XAF.Modules.ViewEditMode v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/ViewEditMode)
 1. [Xpand.XAF.Modules.ViewItemValue v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/ViewItemValue)
 1. [Xpand.XAF.Modules.ViewWizard v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules/ViewWizard)
 1. [Xpand.XAF.Web.All v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules)
 1. [Xpand.XAF.Win.All v.<IP_ADDRESS>](https://github.com/eXpandFramework/DevExpress.XAF/tree/master/src/Modules)

Please update the related Nuget packages and test if issues is addressed. These are nightly nuget packages available only from our NugetServer.
If you do not use these packages directly but through a module of the main eXpandFramework project, please wait for the bot to notify you again when integration is finished or update the related packages manually.
Thanks a lot for your contribution.

with actual lab v<IP_ADDRESS> problem is solved for me
thanks

Thanks alot, great Work apobekiaris! I will try today and check

Closing issue for age. Feel free to reopen it at any time.
.Thank you for your contribution.


docker run  secure_registry:latest error

in 'Configure TLS on a registry server' step
after build secure_registry. when i run
"docker run -p 5000:5000 secure_registry:latest"
log for this error
"configuration error: error parsing cmd/registry/config.yml: yaml: line 20: found character that cannot start any token
usage: registry
-version=false: show the version and exit
"
what's the problem?

oooo，my fault，forget to switch branch。

Ok, closing then :)

what was the issue? How did you fix it? I downloaded the source available at  https://github.com/docker/distribution/archive/v2.0.0.tar.gz , extracted it and then compiled it using docker build command.
No issues were encountered during build process, but when I try to start registry contain, I also get above error.
I am not sure what you are talking about switch branch.

@sa-shukla you should stick with the official image for the registry (see documentation).
There is almost no reason to build your own registry from source.
If you really, really want to compile from source still, please use the latest version and follow the build docs.

@sa-shukla That error message means there is a format problem with the configuration. If you examine the message carefully, you'll see it is a syntax error at line 20. With yaml this, is likely a problem with spacing.


Fix formatting selected table cells

Closes #4989

@zurfyx this is similar to my previous PR related to issue #4880 which you reviewed. Please check this one out as well and I can pick up another issue.


QuaggaJS and Angular

I'm looking at a QuaggaJS examples. But looking at the examples, I'm not sure how to adapt it to Angular. Can someone post something?

https://www.npmjs.com/package/ngx-barcode-scanner#demo it is mainly made with quagga

I've tried use this one but doesn't have demo and examples, I dont know how to use :(

I've tried use this one but doesn't have demo and examples, I dont know how to use :(

The readme.md has a complete angular demo. Simply copy and paste into a new component and it'll magically work :open_mouth: @Fernyan

I tried again and work! Tks for the response ❤


Playground UI/UX

Hi 👋
It would be better if the buttons (copy, delete, share, etc) were only visible when hovering over their parent box.

The delete button overlays on the log content which is a bit annoying.
(I can open a PR)

I think the buttons should be visible right away. This improves the UX in my eyes. But I understand the problem with the "delete" button. I do not have a perfect solution at the moment. As a workaround, you could just click the "execute" button twice, since the "delete" button only covers the first line.


Change terms - acceptedNameUsageID, parentNameUsageID, originalNameUsageID

Change term

Submitter: John Wieczorek @tucotuco (based in initial proposal by Markus Döring @mdoering)
Justification (why is this change necessary?): Clarity
Proponents (who needs this change): Everyone

Current Term definition: https://dwc.tdwg.org/terms/#dwc:acceptedNameUsageID
Proposed new attributes of the term:

Term name (in lowerCamelCase): acceptedNameUsageID
Organized in Class (e.g. Location, Taxon): Taxon
Definition of the term: An identifier for the name usage (documented meaning of the name according to a source) of the currently valid (zoological) or accepted (botanical) taxon.
Usage comments (recommendations regarding content, etc.): This term should be used for synonyms or misapplied names to refer to the taxonID of a Taxon record that represents the accepted (botanical) or valid (zoological) name.
Examples: tsn:552479, https://www.gbif.org/species/2435099
Refines (identifier of the broader term this term refines, if applicable): None
Replaces (identifier of the existing term that would be deprecated and replaced by this term, if applicable): http://rs.tdwg.org/dwc/terms/version/acceptedNameUsageID-2017-10-06
ABCD 2.06 (XPATH of the equivalent term in ABCD or EFG, if applicable): not in ABCD

Change term

Submitter: John Wieczorek @tucotuco (based in initial proposal by Markus Döring @mdoering)
Justification (why is this change necessary?): Clarity
Proponents (who needs this change): Everyone

Current Term definition: https://dwc.tdwg.org/terms/#dwc:parentNameUsageID
Proposed new attributes of the term:

Term name (in lowerCamelCase): parentNameUsageID
Organized in Class (e.g. Location, Taxon): Taxon
Definition of the term: An identifier for the name usage (documented meaning of the name according to a source) of the direct, most proximate higher-rank parent taxon (in a classification) of the most specific element of the scientificName.
Usage comments (recommendations regarding content, etc.): This term should be used for accepted names to refer to the taxonID of a Taxon record that represents the next higher taxon rank in the same taxonomic classification.
Examples: tsn:552375, https://www.gbif.org/species/2435098
Refines (identifier of the broader term this term refines, if applicable): None
Replaces (identifier of the existing term that would be deprecated and replaced by this term, if applicable): http://rs.tdwg.org/dwc/terms/version/parentNameUsageID-2017-10-06
ABCD 2.06 (XPATH of the equivalent term in ABCD or EFG, if applicable): not in ABCD

Change term
Current Term definition: https://dwc.tdwg.org/terms/#dwc:originalNameUsageID

Term name (in lowerCamelCase): originalNameUsageID
Organized in Class (e.g. Location, Taxon): Taxon
Definition of the term: An identifier for the name usage (documented meaning of the name according to a source) in which the terminal element of the scientificName was originally established under the rules of the associated nomenclaturalCode.
Usage comments (recommendations regarding content, etc.): This term should be used to refer to the taxonID of a Taxon record that represents the original combination of the name (the protonym in zoology, the basionym in botany).
Examples: tsn:506607, https://www.gbif.org/species/2435098
Refines (identifier of the broader term this term refines, if applicable): None
Replaces (identifier of the existing term that would be deprecated and replaced by this term, if applicable): http://rs.tdwg.org/dwc/terms/version/originalNameUsageID-2017-10-06
ABCD 2.06 (XPATH of the equivalent term in ABCD or EFG, if applicable): not in ABCD

Original comment from Markus Döring (@mdoering):
The definition of dwc:acceptedNameUsageID does not clearly specify what values it expects and how they relate to other dwc terms. Currently: "An identifier for the name usage (documented meaning of the name according to a source) of the currently valid (zoological) or accepted (botanical) taxon."
In order to correctly establish relation to the accepted usage it should be clear to which property this id relates. In GBIF and all implementations I am aware of this is the dwc:taxonID property. For example see this issue from the dwca validator: https://github.com/gbif/dwca-validator/issues/3
The definition or at least comments of acceptedNameUsageID (and similar parentNameUsageID and originalNameUsageID) should be changed to mention this. This is a common cause of referential integrity problems for taxonomic datasets we see at GBIF.

Now that the commentaries are separate from the normative definitions of the terms, this recommendation can be added without the full public review process. @mdoering  What exactly would you propose for the comment to say?

A first suggestion would be:

acceptedNameUsageID should be used for synonyms or misapplied names to refer to the taxonID of an existing Darwin Core Taxon record that represents the accepted (botanical) or valid (zoological) name.

Similarily a comment should exist for parentNameUsageID:

parentNameUsageID should be used for accepted names to refer to the taxonID of an existing Darwin Core Taxon record that represents the next higher taxon of their taxonomic classification.

and originalNameUsageID

originalNameUsageID should be used to refer to the taxonID of an existing Darwin Core Taxon record that represents the original combination, i.e. protonym (zoology) or basionym (botany) of the name.

@mdoering are these definitions or usage notes?

proposed comments, not normative definitions

I have added the templated term change proposal for all three terms in the first comment in this issue. I have added examples from ITIS. It would be good to have equivalents from Catalogue of Life and to be sure that the GBIF examples are apt to include.

I strongly support this clarification.  Note that the "Usage Comments" for parentNameUsageID and originalNameUsageID were reversed in the original proposal, but correctly represented in the subsequent comment by @mdoering.

All of these are "ID" terms without dwciri: namespace analogs.

I see no remaining problems in the discussion for the proposed changes in this issue, but rather clarifications that ought to be made in scientificName and nameAccordingTo. If that is not the case, please let me know. The ideas for clarifying scientificName and nameAccordingTo can be made in this same public review without holding anything up if they are non-normative change requests (comments and/or examples).

I have added the templated term change proposal for all three terms in the first comment in this issue. I have added examples from ITIS. It would be good to have equivalents from Catalogue of Life and to be sure that the GBIF examples are apt to include.

I don't see the link to the examples.  I am looking for clarity on what is expected for originalNameUsage (original combination or protonym).  Should the name be the original spelling even if incorrect? Or should it be the corrected original spelling.
Should the name include joining words such as "var." or should all joining words be cleaned from the protonym.

This issue is not about originalNameUsage, but originalNameUsageID and the other 2 ID terms.
Still the question then concerns the scientificName of the related Taxon record.
In botany a basionym must be a legitimate name.
I would expect the protonym in zoology to be the original spelling, but maybe not for incorrect names? @deepreef any guidance here?
In botany with various infraspecific ranks you clearly include rank markers as var. with the name. I would recommend to do the same in zoology if it is not considered a subspecies. The term definition of scientificName already gives some examples.

The term 'protonym' is not used in the Zoological Code and it would be best if it did not end up in any Darwin Core definitions, as it has been used in mycology in a different sense and that is the sense in which it is defined in David Hawkworth's 'Terms used in Bionomenclature'.

Yes, that's one of the reasons why we decided to use the not overloaded and code agnostic originalName in Darwin Core.

Zoological names only have one infraspecific rank, so do not use a prefix.

Only in recent editions of ICZN so not necessarily in original publications of older names. So the question whether the original spelling should be used or some emendation still stands. Personally I prefer the original spelling, but I guess this does not need to be prescribed by Darwin Core at all.

I would expect the protonym in zoology to be the original spelling, but maybe not for incorrect names? @deepreef any guidance here?

As noted by @nielsklazenga, the word "Protonym" has no official definition in zoology.  It actually has several general definitions in the context of taxonomy/nomenclature, but I imagine the one you are referring to is the one that I use (defined here).  The definition of protonym in this sense is somewhat different from basionym.  First, basionyms apply to names below the rank of genus, whereas protonym (in my sense) applies to all ranks, up to kingdom/domain, etc..  Second, original combinations are not "born" as basionyms -- they only become basionyms when a subsequent publication establishes a new combination (Protonyms are born upon first usage, regardless of whether there are any subsequent usages).  Third, I believe (as you note) that basionyms represent the first "legitimate" (sensu Code) use/spelling/combination of the name, whereas Protonyms are the first chronological usage of a name, independent of Code compliance.  Protonyms have a literal spelling as a property, but they are not defined by this spelling.

In botany with various infraspecific ranks you clearly include rank markers as var. with the name. I would recommend to do the same in zoology if it is not considered a subspecies. The term definition of scientificName already gives some examples.

Again, as noted by @nielsklazenga, only subspecies are allowed under the ICZN Code (no other infraspecific ranks).  Historically they have been used; some converted to subspecies; others rejected as infrasubspecific.  Thus, in zoology, trinominals are assumed to be subspecies, and an indicator of such (e.g., "ssp." or "subsp.") is not encouraged.
I think originalNameUsage is probably the best candidate (not originalName, which implies a text string, rather than a usage instance), and I'd be willing to abandon "protonym" for that term.  However, that would require a revised definition for those terms (originalNameUsage/originalNameUsageID), to eliminate the "when first established under the rules of the associated nomenclaturalCode" part.  I suspect such a change in definition would be met with substantial resistance, however.  If the DwC definition cannot be changed to liberate the concept from "rules of associated nomenclaturalCode", then we'll need a new term, and I suspect in that case that a carefully defined term protonym would then become the next best candidate.
I would like to see these technical issues sorted out within the TCS-2 task group, then framed as the next iteration of terms organized within the Taxon class of DwC.  The most important thing, I think, will be to lock in the definition of the instance of a DwC Taxon class as a usage instance (not a text string, and not a taxon concept per se).

@mdoering - I recall that in a DwC-A the implementations all expect these IDs to be local foreign keys and will fail with referential integrity checks if not present.
If that is the case, can you please state this in the usage comments when making the change? I am aware at least of at least one recent example where an external ID was used without carrying the record within the DwC-A.

Yes, that makes sense. I would propose an addition to the current proposal:

Comments: This term should be used for accepted names to refer to the taxonID of a Taxon record that represents the next
higher taxon rank in the same taxonomic classification.

Suggested update:
Comments: This term should be used for accepted names to refer to the taxonID of a Taxon record that represents the next higher taxon rank in the same taxonomic classification. For Darwin Core Archives the related record should be present locally in the same archive.

That wording seems OK to me for parentNameUsageID, but would need to be tweaked for the other two:
originalNameUsageID:
Comments: This term should be used to refer to the taxonID of a Taxon record that represents the usage of the terminal element of the scientificName as originally established under the rules of the associated nomenclaturalCode. For Darwin Core Archives the related record should be present locally in the same archive.
[*Note: this wording is modified from the proposed text to reflect the recent discussion on basionym/protonym.]
acceptedNameUsageID:
Comments: This term should be used for synonyms or misapplied names to refer to the taxonID of a Taxon record that represents the accepted (botanical) or valid (zoological) name. For Darwin Core Archives the related record should be present locally in the same archive.

I have added examples from ITIS. It would be good to have equivalents from Catalogue of Life and to be sure that the GBIF examples are apt to include.

Indeed the GBIF species URLs are not used as identifiers at GBIF. It is the integer only that is the taxonID. I would propose to change that, but it would be good to also include a true global URI identifier as one of the examples. I suggest to add IPNI LSID examples for this and update ITIS, GBIF & COL to all point to Poa (parentNameUsageID) or Poa annua L. (acceptedNameUsageID & originalNameUsageID):

ITIS: tsn:41107
IPNI: urn:lsid:ipni.org:names:320035-2
GBIF: 2704179
COL: 6W3C4

Summary of the current proposal of term changes, listing changes only:
parentNameUsageID
Comments: This term should be used for accepted names to refer to the taxonID of a Taxon record that represents the next higher taxon rank in the same taxonomic classification. For Darwin Core Archives the related record should be present locally in the same archive.
Examples: tsn:41074 (ITIS),urn:lsid:ipni.org:names:30001404-2 (IPNI),2704173 (GBIF), 6T8N (COL)
acceptedNameUsageID
Comments: This term should be used for synonyms or misapplied names to refer to the taxonID of a Taxon record that represents the accepted (botanical) or valid (zoological) name. For Darwin Core Archives the related record should be present locally in the same archive.
Examples: tsn:41107 (ITIS),urn:lsid:ipni.org:names:320035-2 (IPNI),2704179 (GBIF), 6W3C4 (COL)
originalNameUsageID
Comments: This term should be used to refer to the taxonID of a Taxon record that represents the usage of the terminal element of the scientificName as originally established under the rules of the associated nomenclaturalCode. For Darwin Core Archives the related record should be present locally in the same archive.
Examples: tsn:41107 (ITIS),urn:lsid:ipni.org:names:320035-2 (IPNI),2704179 (GBIF), 6W3C4 (COL)

I would think it is wise though to have also the nomenclatural terms basionym and protonym in the usage comments, as this otherwise just repeats the definition and is a bit hard to understand for casual users.
How about we change the comments for originalNameUsageID to be more like the one for acceptedNameUsageID?
Comments: This term should be used to refer to the taxonID of a Taxon record that represents the usage of the protonym (zoology) or basionym (botany).

@mdoering :
Please note that "Protonym" is not the zoological counterpart to "Basionym".  These two terms have two different meanings, and both terms have relevance to all names under all Codes.  The concept of "basyonym" (the relationship between a subsequent combination and its Code-compliant original combination) exists in Zoology just as it does in Botany, but that term is not used in zoology or defined in the ICZN Code because new combinations are not considered as Code-governed nomenclatural acts.  But it still has the same conceptual meaning in zoology.
Similarly, the concept of "Protonym" as you use it here (it has been defined in at least three different ways in the context of taxonomy & nomenclature) applies equally to names governed by zoological and botanical and bacteriological Codes.
In summary:
Basionym:

Refers to the first Code-compliant combination of a species-group name
Represents the relationship between a subsequent combination and its original combination (new species-group names are not "born" as basionyms -- they only become basionyms when the epithet is used in a different combination)
Has Code-relevance in the scope of ICNafp and bacteriological Code, but not zoological Code

Protonym:

Refers to the first chronological usage of a name at any rank, in any Code (regardless of whether that usage represents the Code-compliant establishment of the name)
Represents a usage (TNU) itself, independent of combination, and Protonyms are "born" as such the moment they are first documented in a Reference (regardless of subsequent usages)
Has no Code-relevance in any Code, but is a very powerful/useful concept for managing relationships among TNUs in an informatics context.

Therefore, I would recommend:
"Comments: This term should be used to refer to the taxonID of a Taxon record that represents the taxonomic name usage that first established a name in compliance with the relevant Code of nomenclature. For example, for names governed by the ICNafp, this term would establish the relationship between a record representing a subsequent combination and the record for its corresponding basionym.  Unlike basionyms, however, this term can apply to scientific names at all ranks."
I think it's important to clarify that originalNameUsageID refers to the first Code-compliant usage ("...the usage of the terminal element of the scientificName as originally established under the rules of the associated nomenclaturalCode.").  This is not always the same as Protonym, so perhaps best not to confuse the issue by using that term here.

@deepreef's usage comment goes in the right direction, but it is important to note that a botanical name cannot be its own basionym (I think that is what makes that basionym cannot be used at all ranks), while originalNameUsage can. Also, in botany we also have the 'replaced synonym', which is to an avowed substitute (nom. nov.) what a basionym is to a new combination (comb. nov.). So originalNameUsage can be (a use of) the basionym, the replaced synonym, or the scientific name itself. originalNameUsage just combines a few different types of relationships, it does not establish them.

I am happy to use Rich's comment as it clearly mentions basionyms which is my main point that we should use common terminology in the usage comments.
If replacement names are actually covered by originalNameUsage I am in doubt though. I had thought so, but if I read the definition I think they are not, because the terminal epithet is actually a different one. It has been replaced:

An identifier for the name usage (documented meaning of the name according to a source) in which the terminal element of the scientificName was originally established under the rules of the associated nomenclaturalCode.

I would even think a replacement name is a protonym itself and does not have the replaced name as its protonym.
Clarifying this in the comments might also be a good thing.

@mdoering, you are right, that definition (which is the definition of originalNameUsageID) indeed excludes replaced synonyms. That is a terrible definition and completely different from that for originalNameUsage, which already has 'basionym' in it.
A replacement name can be an originalNameUsage if the name it replaces is illegitimate. If the replaced name is legitimate, however, the replaced synonym will be the originalNameUsage and the basionym for future combinations (if the combination is available). Protonyms as defined in Hawkesworth (2017) are invalid, so cannot be originalNameUsages. As @deepreef suggested, it is better to avoid that term.
Go with @deepreef's usage comment.

Wow, I only know realize that the 2 definitions are not matching up at all:
originalNameUsage

The taxon name, with authorship and date information if known, as it originally appeared when first established under the rules of the associated nomenclaturalCode. The basionym (botany) or basonym (bacteriology) of the scientificName or the senior/earlier homonym for replaced names.

originalNameUsageID

An identifier for the name usage (documented meaning of the name according to a source) in which the terminal element of the scientificName was originally established under the rules of the associated nomenclaturalCode.

I guess we cannot change the definition of originalNameUsageID anymore in this round to be inline with the one for originalNameUsage?

The taxon name ... as it originally appeared when first established...

That definition is less clear than the one for the ID:

name usage in which the terminal element of the scientificName was originally established

It depends what you consider a name which we don't all agree on. As a botanist I would not say Pinus abies L. is the same name as Picea abies (L.) H.Karst.. Therefore I would prefer to change the definition of originalNameUsage instead the one for originalNameUsageID. This would work:
The name, with authorship and date information if known, of the name usage (documented meaning of the name according to a source) in which the terminal element of the scientificName was originally established under the rules of the associated nomenclaturalCode.
But then we exclude replacement names. Which I don't mind as long as its clear what an originalNameUsage is and the definitions of originalNameUsageID matches up.

@mdoering , yes, I guess we should try to do what we can with the usage comments for now and deal with the definitions later.
I am actually more comfortable with the definition for originalNameUsage than that for originalNameUsageID, as I think names are established as a whole, not as individual parts. I guess that is a botanist thing (I had to look up what a replacement name is too). The definition of originalNameUsageID looks very zoological to me.

I agree. It is not simple to provide a definition that reads well in the eye of zoologists and botanists. And a name being just the epithet for (most) zoologists and the entire combination in the mind of a botanist is the biggest challenge. originalNameUsage I still think was a good term name for that purpose.
On the other hand dwc:scientificName is not supposed to be just the epithet alone, but the full "name" even including authorship. So in that regard the originalNameUsage definition fits better into the DwC universe.
Shall we create a new issue to redefine the definition some other time so we don't lose it?

Yes, maybe just a place holder and then sort it out after TCS 2.

I would not use originalNameUsage / originalNameUsageID to establish relationships between replacement names and the names they replace.  My perspective on this is in line with what @mdoering wrote above.
Hawksworth's definition of Protonym is not the same as my definition (Taxonomer data model), or Dubois' definition.  Hawksworth is actually repeating an earlier definition used in fungi, which Paul Kirk encouraged me to ignore.  These are the three definitions of "Protonym" (Mycological, Taxonomer, Dubois), and I believe @mdoering was referring to the Taxonomer definition.  In any case, best to avoid this term until we have a single agreed-upon definition.
The terms originalNameUsage / originalNameUsageID originally emerged from a series of GNA NOMINA meetings, which had as much representation from the botanical Code (Paul Kirk, Greg Whitbread, Nicky Nicolson) as from the Zoological Code (me, Paddy Patterson, Stan Blum); so it was framed in a way that would work for both Codes equally.
The reason for the "Usage" qualifiers on these terms was specifically to liberate the terms from the botanical vs. zoological biases for what is meant by "name".  We can all agree on what a usage is, regardless of whether a "name" represents a full combination, or the individual elements of a combination.
I agree with @nielsklazenga that we should sort this out when reconciling the outcomes of TCS 2 with dwc:Taxon terms.

Does this mean we should table all the usage comments suggested here for a future release, or is there consensus that we can move forward with these. If the latter, I would appreciate if that can be stated so I can proceed with the pursuit of ratification.

I have created a new issue #360 to discuss the future change of definitions.
@tucotuco I think we can all agree to change the usage comments to the following, complying with their current definitions:
parentNameUsageID
Comments: This term should be used for accepted names to refer to the taxonID of a Taxon record that represents the next higher taxon rank in the same taxonomic classification. For Darwin Core Archives the related record should be present locally in the same archive.
Examples: tsn:41074 (ITIS),urn:lsid:ipni.org:names:30001404-2 (IPNI),2704173 (GBIF), 6T8N (COL)
acceptedNameUsageID
Comments: This term should be used for synonyms or misapplied names to refer to the taxonID of a Taxon record that represents the accepted (botanical) or valid (zoological) name. For Darwin Core Archives the related record should be present locally in the same archive.
Examples: tsn:41107 (ITIS),urn:lsid:ipni.org:names:320035-2 (IPNI),2704179 (GBIF), 6W3C4 (COL)
originalNameUsageID
Comments: This term should be used to refer to the taxonID of a Taxon record that represents the usage of the terminal element of the scientificName as originally established under the rules of the associated nomenclaturalCode. For example, for names governed by the ICNafp, this term would establish the relationship between a record representing a subsequent combination and the record for its corresponding basionym. Unlike basionyms, however, this term can apply to scientific names at all ranks. For Darwin Core Archives the related record should be present locally in the same archive.
Examples: tsn:41107 (ITIS),urn:lsid:ipni.org:names:320035-2 (IPNI),2704179 (GBIF), 6W3C4 (COL)

Excellent, thank you.
On Wed, Jun 16, 2021 at 7:01 PM Markus Döring @.***>
wrote:

I have created a new issue #360 https://github.com/tdwg/dwc/issues/360
to discuss the future change of definitions.
@tucotuco https://github.com/tucotuco I think we can all agree to
change the usage comments to the following, complying with their current
definitions:
parentNameUsageID
Comments: This term should be used for accepted names to refer to the
taxonID of a Taxon record that represents the next higher taxon rank in the
same taxonomic classification. For Darwin Core Archives the related record
should be present locally in the same archive.
Examples: tsn:41074 (ITIS),urn:lsid:ipni.org:names:30001404-2 (IPNI),
2704173 (GBIF), 6T8N (COL)
acceptedNameUsageID
Comments: This term should be used for synonyms or misapplied names to
refer to the taxonID of a Taxon record that represents the accepted
(botanical) or valid (zoological) name. For Darwin Core Archives the
related record should be present locally in the same archive.
Examples: tsn:41107 (ITIS),urn:lsid:ipni.org:names:320035-2 (IPNI),
2704179 (GBIF), 6W3C4 (COL)
originalNameUsageID
Comments: This term should be used to refer to the taxonID of a Taxon
record that represents the usage of the terminal element of the
scientificName as originally established under the rules of the associated
nomenclaturalCode. For example, for names governed by the ICNafp, this term
would establish the relationship between a record representing a subsequent
combination and the record for its corresponding basionym. Unlike
basionyms, however, this term can apply to scientific names at all ranks.
For Darwin Core Archives the related record should be present locally in
the same archive.
Examples: tsn:41107 (ITIS),urn:lsid:ipni.org:names:320035-2 (IPNI),
2704179 (GBIF), 6W3C4 (COL)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tdwg/dwc/issues/105#issuecomment-862758267, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AADQ72Z4XZOQJITH2Z46EGLTTENKFANCNFSM4BOQM67Q
.

Done.


Timer, TooltipPanel and TooltipLabel objects created in random places in SceneTree

I was just studing my SceneTree for some memory leaks in Info tab, and what I've noticed is a lot of stange objects that I did not make. There is a lot ot Timers, TooltipPanels and TooltipLabels a it's child - they are always together. Where do they come from? They are like in many different, quite random places.

I can confirm the bug, though in my small game I don't get too many of them, but I do get some. In the attached screenshot there are children of a hidden Label, and if I go to the main menu, I also get the same bundle of Timer, TooltipPanel and TooltipLabel objects as children of the menu's Node2D.

I believe those are internal to the engine and must be needed for some work. What would be good is an option to hide them or, better yet, hide them by default and add an option to show'em.

they are hidden by default, but shown in the sene tree inspector, the fact they start with @ shows they are internal nodes. I'm closing as I belive this is a non issue

It was indeed not an issue, but I believe @reduz just fixed it nevertheless in 07e7909.


Any way I can adjust the volume of the input in the codes?

I compare the audio file I got from Chrome and Safari and found out that the volume in Chrome is really low. Does anybody notice this?
So is there any way I can adjust the volume in the code to make it louder?
Thanks

Currently, there is no way to adjust the volume.
If we allow custom media constraints (as requested in this issue), you'd be able to use volume. That said, this is a deprecated setting though, since it's invasive to the user.


Skip API review for tools

The variable to skip API review is set in the pipeline directly. This change is no longer required.


Bump the version

This is in preparation of changed coming in from https://github.com/GoogleCloudPlatform/spark-bigquery-connector/pull/29.

@pmkc


Inaccurate predictions using biomedical NER models

Hi,
I just experimented with the specialised NER models for the biomedical and found some rather strange annotation artifacts. Especially, there seems to be an issue if two entities occur consecutively.  For example, see the following sentence from the BioNLP13-CG corpus and the predicted entities (using en_ner_bionlp13cg_md):

METHOD: The intratumor microvessel density (IMVD), apoptotic index (AI) and vascular endothelial growth factor (VEGF) expression were detected by immunohistochemistry SABC and terminal uridine deoxynucleotidyl transferase mediated nick end labeling(TUNEL) methods in34 LSCC patients.
-> intratumor microvessel(TISSUE)
-> IMVD(GENE_OR_GENE_PRODUCT)
-> vascular endothelial growth factor(GENE_OR_GENE_PRODUCT)
-> VEGF(GENE_OR_GENE_PRODUCT)
-> LSCC patients(CANCER)

Normally it should be LSCC (CANCER) and patients (SPECIES/ORGANISM). The latter should be easily recognizable by the model.

Hi @mariosaenger ,
The bionlp13cg model does not have a SPECIES/ORGANISM entity type. So this is likely the reason. You might have better luck with the general mention detector in the main models, and then using the entity linker to identify types.

Hi @DeNeutoy ,
may I was a bit misleading. I meant ORGANISM, however this entity type is called SPECIES in other corpora. According to https://allenai.github.io/scispacy/, bionlp13cg should have this entity type and there over over 100 occurrences of "patients" as ORGANISM in the training set of the corpus.
Additionally, I found such issues (with two entities that occur consecutively) in several other cases, e.g.

In this work, we show that an 11-amino acid peptide derived from the second immunoglobulin-like domain of Flt-1 functions as an angiogenic inhibitor in chick chorioallantoic membrane and inhibited VEGF-induced vascular permeability in Miles' assay without binding to VEGF directly.
-> ...
-> chick chorioallantoic membrane(ORGANISM)
-> ...
Here, "chick" is ORGANISM and chorioallantoic membrane is MULTI-TISSUE_STRUCTURE.

Taken together , our studies , based on a molecular imaging approach for semiquantitative detection of micrometastases , point to an important role of tumor lymphatics in the metastatic process of human prostate cancer .
-> ...
-> human prostate cancer(ORGANISM)
-> ...
Here, "human" is ORGANISM and "prostate cancer" is CANCER

DNA of the non-tumorigenic cell hybrids transformed Rat-1 cells to anchorage-independent proliferation as expected for the transforming human Ha-ras gene present in the donor DNA.
-> ..
-> human Ha-ras(ORGANISM)
-> ..
Here, "human" is ORGANISM and "Ha-ras" is GENE_OR_GENE_PRODUCT

Hi @mariosaenger thanks for the additional info.
It seems like this is an annotation design in the original data which is a bit unfortunate:
https://github.com/cambridgeltl/MTL-Bioinformatics-2016/blob/master/data/BioNLP13CG-IOB/train.tsv#L2167
It annotates noun modifiers here as separate entities, which in some cases can be correct, but makes using a practical NER model substantially harder. For example in the line linked above, I don't really think that "human" refers to an entity - it's being used in an abstract sense, to modify the cell type. The word "human" in this sentence has no agency.
Not only is this kind of dubious annotation, but it is also inconsistent:
https://github.com/cambridgeltl/MTL-Bioinformatics-2016/blob/master/data/BioNLP13CG-IOB/train.tsv#L2450
Here only some of the noun modifiers are included in the entity. For me this is pretty damning and likely the reason that the F1 performance on this dataset is not that high.
Even within this phenomena of annotating organism modifiers as entities, it is done inconsistently:
https://github.com/cambridgeltl/MTL-Bioinformatics-2016/blob/master/data/BioNLP13CG-IOB/train.tsv#L7570
here, it's pretty hard to argue that "amphibian" shouldn't also be an ORGANISM.
This is actually quite interesting, but it's kind of tricky to fix without a bit of effort cleaning up the training data. However, that's probably not too difficult, to go through and filter entity boundaries which are modifiers or something.

Hi @DeNeutoy ,
sorry for the late response. I agree with the issues you mentioned - some of these annotations are worth discussing.


Fixing org.opensearch.repositories.azure.AzureBlobContainerRetriesTests and org.opensearch.action.admin.cluster.node.stats.NodeStatsTests

Description
Fixing org.opensearch.repositories.azure.AzureBlobContainerRetriesTests and org.opensearch.action.admin.cluster.node.stats.NodeStatsTests
Issues Resolved
Closes https://github.com/opensearch-project/OpenSearch/issues/1389 and https://github.com/opensearch-project/OpenSearch/issues/1388
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[X] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

another flaky one? First time I see it...

I've seen this failure before. It's sporadic and needs deeper investigation so I opened #1396
Rerunning gradle check here...


Password Length

Password Length
User Story
AS AN employee with access to sensitive data
I WANT to randomly generate a password that meets certain criteria
SO THAT I can create a strong password that provides greater security
Acceptance Criteria
GIVEN I need a new, secure password
WHEN prompted for the length of the password
THEN I choose a length of at least 8 characters and no more than 128 characters

password length defined in prompt


Add MagicMapper in Parsing section

Add MagicMapper in Parsing section
Project URL
https://github.com/adrianitech/magic-mapper-swift
Description
Add MagicMapper in Parsing section
Why it should be included to awesome-ios (optional)
Checklist

[x] Only one project/change is in this pull request
[x] Addition in chronological order (bottom of category)
[x] Supports iOS 9 / tvOS 10 or later
[x] Supports Swift 3
[x] Has a commit from less than 2 years ago
[x] Has a clear README in English

@adrianitech, first, fix conflicting file.

@miguelarauj1o Solved!

          1 Warning

:warning:
Please rebase to get rid of the merge commits in this Pull Request

  Generated by :no_entry_sign: Danger


[GOBBLIN-1696] Implement file based flowgraph that detects changes to the underlying…

… filesystem and updates dynamically
Dear Gobblin maintainers,
Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!
JIRA

[ ] My PR addresses the following Gobblin JIRA issues and references them in the PR title. For example, "[GOBBLIN-XXX] My Gobblin PR"

https://issues.apache.org/jira/browse/GOBBLIN-1696

Description

[x] Here are some details about my PR, including screenshots (if applicable):
Gobblin-as-a-Service only has a Git based flowgraph, which is difficult to build CI/CD around.
This is an alternate flowgraph that watches for file changes and applies updates.
Unlike the git based flowgraph, changes in this flowgraph are atomic with respect to one deployment of the flowgraph, which is an update of multiple files.
This also requires an enhancement to the PathAlterationObserver to notify listeners if there is any change on a root level.

Tests

[x] My PR adds the following unit tests OR does not need testing for this extremely good reason:

Commits

[x] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Codecov Report

Merging #3548 (400b12f) into master (d90d196) will decrease coverage by 3.32%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master    #3548      +/-   ##
============================================
- Coverage     46.64%   43.32%   -3.33%
+ Complexity    10460     2036    -8424
============================================
  Files          2087      406    -1681
  Lines         81670    17541   -64129
  Branches       9106     2145    -6961
============================================
- Hits          38095     7599   -30496
+ Misses        40055     9093   -30962
+ Partials       3520      849    -2671

Impacted Files
Coverage Δ

...eptionCatchingPathAlterationListenerDecorator.java
0.00% <0.00%> (ø)

...util/filesystem/PathAlterationListenerAdaptor.java
0.00% <0.00%> (ø)

...obblin/util/filesystem/PathAlterationObserver.java
0.00% <0.00%> (ø)

...main/java/org/apache/gobblin/util/HadoopUtils.java
29.54% <0.00%> (-0.65%)
:arrow_down:

...pache/gobblin/configuration/ConfigurationKeys.java

...bblin/service/modules/flowgraph/BaseFlowGraph.java

...rvice/modules/flowgraph/BaseFlowGraphListener.java

...ervice/modules/flowgraph/GitFlowGraphListener.java

...obblin/service/monitoring/GitFlowGraphMonitor.java

...etention/HivePartitionVersionRetentionCleaner.java

... and 1676 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Fixes clear method for storageApi (for fake)

While running jest test I’ve noticed that clear / clearAll methods where not working. After some research I have found a typo in clear method (it was using list property, not items).

Thanks for catching this! Next time, just leave the version bump and dist update to me, if you would. :)

Okey 👍


BUG HvEptHookWriteAbsoluteJump

In ept.c
/* Write an absolute x64 jump to an arbitrary address to a buffer. */
VOID HvEptHookWriteAbsoluteJump(PCHAR TargetBuffer, SIZE_T TargetAddress)
{
/* mov r11, Target */
TargetBuffer[0] = 0x49;
TargetBuffer[1] = 0xBB;

/* Target */
*((PSIZE_T)&TargetBuffer[2]) = TargetAddress;

/* push r11 */
TargetBuffer[10] = 0x41;
TargetBuffer[11] = 0x53;

/* ret */
TargetBuffer[12] = 0xC3;

}
r11 is usually used to save rsp at the beginning of the function.
win7 x64 NtCreateFile:
PAGE:000000014037EE5C 4C 8B DC....................................mov     r11, rsp
PAGE:000000014037EE5F 48 81 EC 88 00 00 00.............sub     rsp, 88h
PAGE:000000014037EE66 33 C0............................................xor     eax, eax
PAGE:000000014037EE68 49 89 43 F0............................... mov     [r11-10h], rax;<--------first 16 bytes
PAGE:000000014037EE6C C7 44 24 70 20 00 00 00......mov     [rsp+88h+var_18], 20h
PAGE:000000014037EE74 89 44 24 68................................mov     dword ptr [rsp+88h+var_20], eax
PAGE:000000014037EE78 49 89 43 D8...............................mov     [r11-28h], rax;<---------use r11,BSOD
PAGE:000000014037EE7C 89 44 24 58...............................mov     [rsp+88h+var_30], eax
VOID HvEptHookWriteAbsoluteJump(PCHAR TargetBuffer, SIZE_T TargetAddress)
{
/**
 *   Use 'push ret' instead of 'jmp qword[rip+0]',
 *   Because 'jmp qword[rip+0]' will read hooked page 8bytes.
 *
 *   14 bytes hook:
 *   0x68 0x12345678 ......................push 'low 32bit of TargetAddress'
 *   0xC7 0x44 0x24 0x04 0x12345678........mov dword[rsp + 4], 'high 32bit of TargetAddress'
 *   0xC3..................................ret
 */

UINT32  Low32;
UINT32  High32;

Low32 = (UINT32)TargetAddress;
High32 = (UINT32)(TargetAddress >> 32);

/* push 'low 32bit of TargetAddress' */
TargetBuffer[0] = 0x68;
*((UINT32*)&TargetBuffer[1]) = Low32;

/* mov dword[rsp + 4], 'high 32bit of TargetAddress' */
*((UINT32*)&TargetBuffer[5]) = 0x042444C7;
*((UINT32*)&TargetBuffer[9]) = High32;

/* ret */
TargetBuffer[13] = 0xC3;

}
BOOL HvEptHookInstructionMemory(PVMM_EPT_PAGE_HOOK Hook, PVOID TargetFunction, PVOID HookFunction, PVOID* OrigFunction)
{
replace 13 to 14
}

Hello! Thank you for the find and fix. Can you submit a pull request so you get appropriate credit? Thank you!

Thank you for the code, it is very useful to me, has been submitted.

Merged #29


Default remove should just remove torrent, not ask if you want to remove the files aswell.

Would love if you could split the remove option up.
99% of the times I delete a torrent I want to keep my files. Quite annoying when I have to select that I want to keep the files every time I remove a torrent, with the risk of hitting the wrong one and removing the files. I'm used to having two delete options on dropdown, "Remove" and "Remove and delete files". Del button should bind to remove and keep files and shift+del should bind to remove and delete files. If possible :)
Love your work!

Great suggestion :) I've had this request from other users as well.
I'll add a checkbox to the remove dialog which you can mark to remember your choice. The default choice will also be editable in the preferences dialog.


Add psetv2 support

This adds support for psetv2, which looks more similar to the go-elements implementation rather than the existing psbt (psetv0) package.
This is done on purpose in order to have a clear separation between the 2 packages, and also to have a clear separation of the "roles" as described in the spec.

Pset, Input, Output and Global are the classes for the inner representation of a partial transaction.
Creator, Updater, Blinder, Signer, Finalizer and Extractor are the classes to manipulate a partial transaction according to the spec.

NOTE: To prevent having secp256k1-zkp as a direct dependency, the Blinder role makes use of 2 interfaces BlindingGenerator and BlindingValidator (similarly to what is done in go-elements) to generate blinding data for the last  output of the last blinder, and to validate all blinding data before adding to the partial transaction.
confidential.ts, instead, contains ZKPGenerator and ZKPValidator that are the implementations of such interfaces.
BONUS:

This fixes AssetHash and adds tests for it, and similarly, this introduces ElementsValue replacing the deprecated satoshiToConfidentialValue|confidentialValueToSatoshi.
Adds name to existing network interfaces.
Adds and exports new method to get type of output script.

TODO:

[x] Taproot support (should be done here or in a next PR?)
[x] Fix import path of secp256k1-zkp in package.json as soon as #27 is merged.

Closes #32.
Closes #51.
Please @tiero review this.

You can look in bitcoinJS PR for test vectors, I aaked them to make.simple calculator bside also CHECKSIG

To prevent having secp256k1-zkp as a direct dependency,

But having comfidential.ts file being exported fron liquidjs basically still requires zkp lib to be a direct dependency.
If we want to detach completely (ie. Being a devDep for test only) this file should be a dedicated npm pkg we import in projs ike tiny-secp in bitcoinjs?

What's the status of this? @altafan

@tiero With the latest commits there are still some problems with parsing the pset with elements CLI (Elements Core RPC client version elements-<IP_ADDRESS>) when it contains confidential inputs.
In general, the psetv2 support should be compliant with the spec except for the input's serialization, for which we still need to understand the necessary fix(es).
Do we want to merge this and open a dedicated issue to keep track of the work that needs to be done?

some problems with parsing the pset with elements CLI

Did you test with this branch? https://github.com/ElementsProject/elements/pull/1121
But I guess the only thing we care about now is making sure GDK's sign_psbt works, so I would focus on making anything necessary to be able to test with that

Did you test with this branch? https://github.com/ElementsProject/elements/pull/1121

No, I didn't yet. I have to compile the binary for that version in order to test against it, there doesn't seem to be any available.

But I guess the only thing we care about now is making sure GDK's sign_psbt works, so I would focus on making anything necessary to be able to test with that

Right now, a pset in base64 format containing only unconfidential inputs made with this new package can be successfully decoded with the elements CLI's decodepsbt RPC.
This makes me think that at least for this kind of txs we're 100% spec-compliant and that GDK too should be able to parse the pset.


ItemPasswordRemote doesn't toggle block lever is attached to

Place redstone dust, place block above, place lever on block. Bind remote to lever. Activate remote, lever flips but redstone doesn't get powered.
The BlockLever class from Minecraft includes calls to notifyNeighborOfStateChange that aren't included as part of ItemPasswordRemote.trigger(ItemStack,World,EntityPlayer).
I believe the code below will fix the issue but I'm new to Minecraft modding and have had trouble getting Single Player to start after building Cyclic (client starts but crashes when trying to join game). ItemLever places the similar code immediately after the sound effect.
Code is:
worldIn.notifyNeighborsOfStateChange(pointer, blockState.getBlock(), false);
EnumFacing enumfacing = ((BlockLever.EnumOrientation)blockState.getValue(BlockLever.FACING)).getFacing();
worldIn.notifyNeighborsOfStateChange(pointer.offset(enumfacing.getOpposite()), blockState.getBlock(), false);

Ah thanks. Yeah looks like its not sending a block update to the neighbours... you are on the right track.

notifyNeighborsOfStateChange was the right function, but i had to pass 'true' to the last argument. Also i had to trigger this on the lever position and in all 6 directions, so .up(), .east(), etc

This should work, let me know how it goes https://minecraft.curseforge.com/projects/cyclic/files/2395255

Works perfectly, thanks!


Use FQDNs for hardcoded commercial API endpoints

Uses fully-qualified domain names (including trailing periods) for the
API endpoints for commercial notification providers, where they are
already hard-coded. This prevents Kubernetes-hosted Alertmanagers from
first trying to resolve the endpoints on the internal Kubernetes DNS,
i.e. it forces https://events.pagerduty.com to resolve to
https://events.pagerduty.com. and not throw NXDOMAIN errors when it
tries to resolve
https://events.pagerduty.com.namespace.svc.cluster.local.

/not-stale

Closing to clean up my open PRs.
Will be happy to re-open if someone wants it.