Line 7, Column 3: [Warning-xref-not-found] Cross reference not found: 'builtins.object'.
Line 39, Column 7: [Warning-xref-not-found] Cross reference not found: 'azure.core.credentials.TokenCredential'.
Line 98, Column 5: [Warning-xref-not-found] Cross reference not found: 'azure.security.attestation.AttestationPolicyCertificatesResult'.
Line 192, Column 7: [Warning-xref-not-found] Cross reference not found: 'Tuple'.
Line 231, Column 7: [Warning-xref-not-found] Cross reference not found: 'Union'.
Line 278, Column 7: [Warning-xref-not-found] Cross reference not found: 'Tuple'.
Line 283, Column 11: [Warning-xref-not-found] Cross reference not found: '~azure.security.attestation.AttestationTokenValidationException'.
Line 361, Column 7: [Warning-xref-not-found] Cross reference not found: 'Tuple'.
Line 361, Column 20: [Warning-xref-not-found] Cross reference not found: 'List'.
Line 361, Column 32: [Warning-xref-not-found] Cross reference not found: 'List'.
Line 477, Column 7: [Warning-xref-not-found] Cross reference not found: 'Tuple'.
Line 510, Column 7: [Warning-xref-not-found] Cross reference not found: 'Union'.
Line 570, Column 7: [Warning-xref-not-found] Cross reference not found: 'Tuple'.
Line 575, Column 11: [Warning-xref-not-found] Cross reference not found: '~azure.security.attestation.AttestationTokenValidationException'.
Line 606, Column 7: [Warning-xref-not-found] Cross reference not found: 'Union'.
Line 668, Column 7: [Warning-xref-not-found] Cross reference not found: 'Tuple'.
Line 673, Column 11: [Warning-xref-not-found] Cross reference not found: '~azure.security.attestation.AttestationTokenValidationException'.

docs-ref-autogen/azure-security-attestation/azure.security.attestation.AttestationClient.yml

Line 7, Column 3: [Warning-xref-not-found] Cross reference not found: 'builtins.object'.
Line 52, Column 7: [Warning-xref-not-found] Cross reference not found: 'azure.core.credentials.TokenCredential'.
Line 65, Column 31: [Warning-xref-not-found] Cross reference not found: 'AttestationToken'.
Line 65, Column 56: [Warning-xref-not-found] Cross reference not found: 'AttestationSigner'.
Line 173, Column 31: [Warning-xref-not-found] Cross reference not found: 'AttestationToken'.
Line 173, Column 56: [Warning-xref-not-found] Cross reference not found: 'AttestationSigner'.
Line 206, Column 7: [Warning-xref-not-found] Cross reference not found: 'Tuple'.
Line 302, Column 31: [Warning-xref-not-found] Cross reference not found: 'AttestationToken'.
Line 302, Column 56: [Warning-xref-not-found] Cross reference not found: 'AttestationSigner'.
Line 335, Column 7: [Warning-xref-not-found] Cross reference not found: 'Tuple'.
Line 380, Column 7: [Warning-xref-not-found] Cross reference not found: 'Dict'.
Line 380, Column 31: [Warning-xref-not-found] Cross reference not found: 'Any'.
Line 394, Column 7: [Warning-xref-not-found] Cross reference not found: 'List'.

docs-ref-autogen/azure-security-attestation/azure.security.attestation.aio.AttestationAdministrationClient.yml

Line 7, Column 3: [Warning-xref-not-found] Cross reference not found: 'builtins.object'.
Line 33, Column 7: [Warning-xref-not-found] Cross reference not found: 'azure.core.credentials_async.AsyncTokenCredential'.
Line 97, Column 5: [Warning-xref-not-found] Cross reference not found: 'azure.security.attestation.aio.AttestationPolicyCertificatesResult'.
Line 191, Column 7: [Warning-xref-not-found] Cross reference not found: 'Tuple'.
Line 233, Column 7: [Warning-xref-not-found] Cross reference not found: 'Union'.
Line 280, Column 7: [Warning-xref-not-found] Cross reference not found: 'Tuple'.
Line 285, Column 11: [Warning-xref-not-found] Cross reference not found: '~azure.security.attestation.AttestationTokenValidationException'.
Line 364, Column 7: [Warning-xref-not-found] Cross reference not found: 'Tuple'.
Line 364, Column 20: [Warning-xref-not-found] Cross reference not found: 'List'.
Line 364, Column 32: [Warning-xref-not-found] Cross reference not found: 'List'.
Line 389, Column 5: [Warning-xref-not-found] Cross reference not found: 'azure.security.attestation.aio.AttestationPolicyCertificateResult'.
Line 481, Column 7: [Warning-xref-not-found] Cross reference not found: 'Tuple'.
Line 514, Column 7: [Warning-xref-not-found] Cross reference not found: 'Union'.
Line 569, Column 21: [Warning-xref-not-found] Cross reference not found: 'azure.security.attestation.aio.AttestationPolicyResult'.
Line 572, Column 7: [Warning-xref-not-found] Cross reference not found: 'Tuple'.
Line 596, Column 7: [Warning-xref-not-found] Cross reference not found: 'Union'.
Line 658, Column 7: [Warning-xref-not-found] Cross reference not found: 'Tuple'.
Line 663, Column 11: [Warning-xref-not-found] Cross reference not found: '~azure.security.attestation.AttestationTokenValidationException'.

docs-ref-autogen/azure-security-attestation/azure.security.attestation.aio.AttestationClient.yml

Line 7, Column 3: [Warning-xref-not-found] Cross reference not found: 'builtins.object'.
Line 46, Column 7: [Warning-xref-not-found] Cross reference not found: 'azure.core.credentials_async.AsyncTokenCredential'.
Line 204, Column 18: [Warning-xref-not-found] Cross reference not found: 'azure.security.attestation.aio.AttestationResult'.
Line 207, Column 7: [Warning-xref-not-found] Cross reference not found: 'Tuple'.
Line 336, Column 18: [Warning-xref-not-found] Cross reference not found: 'azure.security.attestation.aio.AttestationResult'.
Line 339, Column 7: [Warning-xref-not-found] Cross reference not found: 'Tuple'.
Line 385, Column 7: [Warning-xref-not-found] Cross reference not found: 'Dict'.
Line 385, Column 31: [Warning-xref-not-found] Cross reference not found: 'Any'.

docs-ref-autogen/msal/msal.oauth2cli.oauth2.Client.yml

Line 21, Column 43: [Warning-xref-not-found] Cross reference not found: 'msal.oauth2cli.oauth2.initiate_auth_code_flow'.
Line 43, Column 13: [Warning-xref-not-found] Cross reference not found: 'msal.oauth2cli.oauth2.obtain_token_by_auth_code_flow'.
Line 99, Column 61: [Warning-xref-not-found] Cross reference not found: 'msal.oauth2cli.oauth2.obtain_token_by_auth_code_flow'.
Line 159, Column 7: [Warning-xref-not-found] Cross reference not found: 'collections.Iterable'.
Line 223, Column 7: [Warning-xref-not-found] Cross reference not found: 'collections.Iterable'.
Line 228, Column 21: [Warning-xref-not-found] Cross reference not found: 'msal.oauth2cli.oauth2.obtain_token_by_refresh_token'.
Line 304, Column 7: [Warning-xref-not-found] Cross reference not found: 'Callable'.

docs-ref-autogen/msrest/msrest.serialization.Model.yml

Line 7, Column 3: [Warning-xref-not-found] Cross reference not found: 'builtins.object'.
Line 32, Column 7: [Warning-xref-not-found] Cross reference not found: 'function'.

docs-ref-mapping/reference-preview.yml

Line 88, Column 10: [Warning-xref-not-found] Cross reference not found: 'azure.python.sdk.landingPage.services.digitaltwins.pre'.
Line 151, Column 10: [Warning-xref-not-found] Cross reference not found: 'azure.python.sdk.landingPage.services.Purview.pre'.
Line 172, Column 12: [Warning-xref-not-found] Cross reference not found: 'azure.python.sdk.landingPage.services.ResourceGraph.Management.pre'.
Line 180, Column 12: [Warning-xref-not-found] Cross reference not found: 'azure.python.sdk.landingPage.services.ResourceMover.Management.pre'.

docs-ref-mapping/reference.yml

Line 339, Column 10: [Warning-xref-not-found] Cross reference not found: 'azure.python.sdk.landingPage.services.DataBox.EdgeGateway'.
Line 379, Column 10: [Warning-xref-not-found] Cross reference not found: 'azure.python.sdk.landingPage.services.Deployment.Manager'.
Line 396, Column 10: [Warning-xref-not-found] Cross reference not found: 'azure.python.sdk.landingPage.services.digitaltwins'.
Line 564, Column 10: [Warning-xref-not-found] Cross reference not found: 'azure.python.sdk.landingPage.services.Kusto'.
Line 572, Column 10: [Warning-xref-not-found] Cross reference not found: 'azure.python.sdk.landingPage.services.LabServices'.
Line 580, Column 10: [Warning-xref-not-found] Cross reference not found: 'azure.python.sdk.landingPage.services.loganalytics'.
Line 602, Column 10: [Warning-xref-not-found] Cross reference not found: 'azure.python.sdk.landingPage.services.ManagedServices'.
Line 643, Column 10: [Warning-xref-not-found] Cross reference not found: 'azure.python.sdk.landingPage.services.netapp'.
Line 651, Column 10: [Warning-xref-not-found] Cross reference not found: 'azure.python.sdk.landingPage.services.Purview'.
Line 755, Column 12: [Warning-xref-not-found] Cross reference not found: 'azure.python.sdk.landingPage.services.ResourceGraph.Management'.
Line 763, Column 12: [Warning-xref-not-found] Cross reference not found: 'azure.python.sdk.landingPage.services.ResourceMover.Management'.

docs-ref-services/preview/synapse-accesscontrol-readme.md

Line 2, Column 1: [Warning-title-missing] Missing required attribute: 'title'. Add a title string to show in search engine results.
Line 2, Column 1: [Warning-ms-prod-and-service] Only one of the following attributes can exist: 'ms.prod', 'ms.service'. Use ms.prod for on-premise products, or ms.service for cloud services.
Line 9, Column 16: [Warning-ms-prod-technology-invalid] Invalid value for 'ms.technology': 'azure' is not valid with 'ms.prod' value 'azure'.
Line 11, Column 13: [Warning-ms-service-subservice-invalid] Invalid value for 'ms.service': 'synapseanalytics'.
Line 14, Column 1: [Warning-duplicate-h1s] H1 'Microsoft Azure SDK for Python' is duplicated with other articles: 'docs-ref-services/preview/ai-anomalydetector-readme.md(14,1), docs-ref-services/preview/cognitiveservices-anomalydetector-readme.md(14,1), docs-ref-services/preview/cognitiveservices-knowledge-qnamaker-readme.md(14,1), docs-ref-services/preview/cognitiveservices-language-luis-readme.md(2,1), docs-ref-services/preview/cognitiveservices-vision-customvision-readme.md(14,1),...'. First level headings must be unique within a docset.
Line 14, Column 1: [Warning-duplicate-titles] Title 'Microsoft Azure SDK for Python' is duplicated in: 'docs-ref-services/preview/ai-anomalydetector-readme.md(14,1), docs-ref-services/preview/cognitiveservices-anomalydetector-readme.md(14,1), docs-ref-services/preview/cognitiveservices-knowledge-qnamaker-readme.md(14,1), docs-ref-services/preview/cognitiveservices-language-luis-readme.md(2,1), docs-ref-services/preview/cognitiveservices-vision-customvision-readme.md(14,1),...'. Titles must be unique within a docset.
Line 21, Column 1: [Warning-multiple-h1s] Multiple H1s(H1 'Usage') are not allowed. You can only have one top-level heading.
Line 21, Column 1: [Warning-duplicate-h1s] H1 'Usage' is duplicated with other articles: 'docs-ref-services/preview/ai-anomalydetector-readme.md(22,1), docs-ref-services/preview/cognitiveservices-anomalydetector-readme.md(21,1), docs-ref-services/preview/cognitiveservices-knowledge-qnamaker-readme.md(21,1), docs-ref-services/preview/cognitiveservices-language-luis-readme.md(9,1), docs-ref-services/preview/cognitiveservices-vision-customvision-readme.md(21,1),...'. First level headings must be unique within a docset.
Line 29, Column 1: [Warning-multiple-h1s] Multiple H1s(H1 'Provide Feedback') are not allowed. You can only have one top-level heading.
Line 29, Column 1: [Warning-duplicate-h1s] H1 'Provide Feedback' is duplicated with other articles: 'docs-ref-services/preview/ai-anomalydetector-readme.md(28,1), docs-ref-services/preview/cognitiveservices-anomalydetector-readme.md(27,1), docs-ref-services/preview/cognitiveservices-knowledge-qnamaker-readme.md(27,1), docs-ref-services/preview/cognitiveservices-language-luis-readme.md(15,1), docs-ref-services/preview/cognitiveservices-vision-customvision-readme.md(27,1),...'. First level headings must be unique within a docset.
Line 2, Column 1: [Suggestion-description-missing] Missing required attribute: 'description'.
Line 26, Column 24: [Suggestion-docs-link-absolute] Absolute link 'https://docs.microsoft.com/python/api/overview/azure/' will be broken in isolated environments. Replace with a relative link.

docs-ref-services/preview/synapse-artifacts-readme.md

Line 2, Column 1: [Warning-title-missing] Missing required attribute: 'title'. Add a title string to show in search engine results.
Line 2, Column 1: [Warning-ms-prod-and-service] Only one of the following attributes can exist: 'ms.prod', 'ms.service'. Use ms.prod for on-premise products, or ms.service for cloud services.
Line 9, Column 16: [Warning-ms-prod-technology-invalid] Invalid value for 'ms.technology': 'azure' is not valid with 'ms.prod' value 'azure'.
Line 11, Column 13: [Warning-ms-service-subservice-invalid] Invalid value for 'ms.service': 'synapseanalytics'.
Line 14, Column 1: [Warning-duplicate-h1s] H1 'Microsoft Azure SDK for Python' is duplicated with other articles: 'docs-ref-services/preview/ai-anomalydetector-readme.md(14,1), docs-ref-services/preview/cognitiveservices-anomalydetector-readme.md(14,1), docs-ref-services/preview/cognitiveservices-knowledge-qnamaker-readme.md(14,1), docs-ref-services/preview/cognitiveservices-language-luis-readme.md(2,1), docs-ref-services/preview/cognitiveservices-vision-customvision-readme.md(14,1),...'. First level headings must be unique within a docset.
Line 14, Column 1: [Warning-duplicate-titles] Title 'Microsoft Azure SDK for Python' is duplicated in: 'docs-ref-services/preview/ai-anomalydetector-readme.md(14,1), docs-ref-services/preview/cognitiveservices-anomalydetector-readme.md(14,1), docs-ref-services/preview/cognitiveservices-knowledge-qnamaker-readme.md(14,1), docs-ref-services/preview/cognitiveservices-language-luis-readme.md(2,1), docs-ref-services/preview/cognitiveservices-vision-customvision-readme.md(14,1),...'. Titles must be unique within a docset.
Line 21, Column 1: [Warning-multiple-h1s] Multiple H1s(H1 'Usage') are not allowed. You can only have one top-level heading.
Line 21, Column 1: [Warning-duplicate-h1s] H1 'Usage' is duplicated with other articles: 'docs-ref-services/preview/ai-anomalydetector-readme.md(22,1), docs-ref-services/preview/cognitiveservices-anomalydetector-readme.md(21,1), docs-ref-services/preview/cognitiveservices-knowledge-qnamaker-readme.md(21,1), docs-ref-services/preview/cognitiveservices-language-luis-readme.md(9,1), docs-ref-services/preview/cognitiveservices-vision-customvision-readme.md(21,1),...'. First level headings must be unique within a docset.
Line 29, Column 1: [Warning-multiple-h1s] Multiple H1s(H1 'Provide Feedback') are not allowed. You can only have one top-level heading.
Line 29, Column 1: [Warning-duplicate-h1s] H1 'Provide Feedback' is duplicated with other articles: 'docs-ref-services/preview/ai-anomalydetector-readme.md(28,1), docs-ref-services/preview/cognitiveservices-anomalydetector-readme.md(27,1), docs-ref-services/preview/cognitiveservices-knowledge-qnamaker-readme.md(27,1), docs-ref-services/preview/cognitiveservices-language-luis-readme.md(15,1), docs-ref-services/preview/cognitiveservices-vision-customvision-readme.md(27,1),...'. First level headings must be unique within a docset.
Line 2, Column 1: [Suggestion-description-missing] Missing required attribute: 'description'.
Line 26, Column 24: [Suggestion-docs-link-absolute] Absolute link 'https://docs.microsoft.com/python/api/overview/azure/' will be broken in isolated environments. Replace with a relative link.

docs-ref-services/preview/synapse-managedprivateendpoints-readme.md

Line 2, Column 1: [Warning-title-missing] Missing required attribute: 'title'. Add a title string to show in search engine results.
Line 2, Column 1: [Warning-ms-prod-and-service] Only one of the following attributes can exist: 'ms.prod', 'ms.service'. Use ms.prod for on-premise products, or ms.service for cloud services.
Line 9, Column 16: [Warning-ms-prod-technology-invalid] Invalid value for 'ms.technology': 'azure' is not valid with 'ms.prod' value 'azure'.
Line 11, Column 13: [Warning-ms-service-subservice-invalid] Invalid value for 'ms.service': 'synapseanalytics'.
Line 14, Column 1: [Warning-duplicate-h1s] H1 'Microsoft Azure SDK for Python' is duplicated with other articles: 'docs-ref-services/preview/ai-anomalydetector-readme.md(14,1), docs-ref-services/preview/cognitiveservices-anomalydetector-readme.md(14,1), docs-ref-services/preview/cognitiveservices-knowledge-qnamaker-readme.md(14,1), docs-ref-services/preview/cognitiveservices-language-luis-readme.md(2,1), docs-ref-services/preview/cognitiveservices-vision-customvision-readme.md(14,1),...'. First level headings must be unique within a docset.
Line 14, Column 1: [Warning-duplicate-titles] Title 'Microsoft Azure SDK for Python' is duplicated in: 'docs-ref-services/preview/ai-anomalydetector-readme.md(14,1), docs-ref-services/preview/cognitiveservices-anomalydetector-readme.md(14,1), docs-ref-services/preview/cognitiveservices-knowledge-qnamaker-readme.md(14,1), docs-ref-services/preview/cognitiveservices-language-luis-readme.md(2,1), docs-ref-services/preview/cognitiveservices-vision-customvision-readme.md(14,1),...'. Titles must be unique within a docset.
Line 21, Column 1: [Warning-multiple-h1s] Multiple H1s(H1 'Usage') are not allowed. You can only have one top-level heading.
Line 21, Column 1: [Warning-duplicate-h1s] H1 'Usage' is duplicated with other articles: 'docs-ref-services/preview/ai-anomalydetector-readme.md(22,1), docs-ref-services/preview/cognitiveservices-anomalydetector-readme.md(21,1), docs-ref-services/preview/cognitiveservices-knowledge-qnamaker-readme.md(21,1), docs-ref-services/preview/cognitiveservices-language-luis-readme.md(9,1), docs-ref-services/preview/cognitiveservices-vision-customvision-readme.md(21,1),...'. First level headings must be unique within a docset.
Line 29, Column 1: [Warning-multiple-h1s] Multiple H1s(H1 'Provide Feedback') are not allowed. You can only have one top-level heading.
Line 29, Column 1: [Warning-duplicate-h1s] H1 'Provide Feedback' is duplicated with other articles: 'docs-ref-services/preview/ai-anomalydetector-readme.md(28,1), docs-ref-services/preview/cognitiveservices-anomalydetector-readme.md(27,1), docs-ref-services/preview/cognitiveservices-knowledge-qnamaker-readme.md(27,1), docs-ref-services/preview/cognitiveservices-language-luis-readme.md(15,1), docs-ref-services/preview/cognitiveservices-vision-customvision-readme.md(27,1),...'. First level headings must be unique within a docset.
Line 2, Column 1: [Suggestion-description-missing] Missing required attribute: 'description'.
Line 26, Column 24: [Suggestion-docs-link-absolute] Absolute link 'https://docs.microsoft.com/python/api/overview/azure/' will be broken in isolated environments. Replace with a relative link.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Closing in favor of https://github.com/MicrosoftDocs/azure-docs-sdk-python/pull/1415


Update create-a-gpg-key.html.md

I followed the docs but got the following error when sending to the default keyserver (from gpgtools):
gpg: sending key XXXX to hkps server hkps.pool.sks-keyservers.net
gpgkeys: HTTP post error 60: SSL certificate problem: Invalid certificate chain

Updates the docs with a hint for anyone else running into this...

🔑


Add additional build costs to cost model 2

In GitLab by @hlux on Apr 21, 2021, 15:43
Summary
We have identified some buildings/faciclities as missing in the current cost model =2 these will need to be added after an appropriate cost model has been derived.
Checklist
After implementing issue do the following

[ ] Run test suite
[ ] Does it change the output? If so, give justifications.
[ ] Does it change the baseline 2019 run? (you may need to run on Freia)
[ ] Merge request created

There is no detail about the problem or what is to be done. I am closing this issue.


add functions to AssetLoaderService to check if an asset exists

add functions to AssetLoaderService to check if an asset exists in order to support dynamic logic when loading assets

Could you provide more details on the use case?
Current design of the asset loader is based on the fact that the requested asset always exists at runtime. If it does not, then that's a developer error. Therefore, there is no need to check if an asset exists.

Sorry, I left a note in the gitter, but I should have also put more details here.
My use case is that I want to load animations made from n number of discrete images, without having know what n is up front in every case.
Here is my current sample code: https://github.com/wakingrufus/praxis/blob/master/game/src/main/kotlin/com/github/wakingrufus/rpg/AssetUtil.kt
Right now, i have to attempt to load each image (letting an exception occur), then check if the result is the dummy image.
this seems like it would be cleaner (and not generate the extra WARN logs) with minimal changes to FXGL code, but I am sure a more elegant solution could be designed if you want this to be a first class supported use case.

Thanks for the details. This is usually handled with some metadata available upfront for each animation, which conforms to the design above (i.e. developer knows what assets are available). I appreciate that it may not always be beneficial to generate or store such metadata, so I suggest that you check for asset (I guess "texture" specifically) availability directly in your AssetUtil, something along these lines:
javaClass.getResource("/assets/textures/$assetName") != null

Based on the above design, I am not ready to merge this yet.

I think i will switch to LPC spritesheets instead, since that is somewhat of a standard, and the framework supports it better:
https://github.com/jrconway3/Universal-LPC-spritesheet

Yeah it's a nice sprite sheet generator. I'm using it for my rpg game too: https://www.youtube.com/watch?v=L6A6n1kqDCE


How to add custom validation to Materialize

@Dogfalo
I was looking through the materialize library, and was wondering whether it would be possible to add custom validation, for different types other than the built in, text, number etc..
Any help or idea from anyone would be great :)
Haven't been able to work this out myself work this out myself :(

check #595
that one has a possible solution

(leaving this here for posterity's sake)
It would depend on what stack you're using. I just finished adding some pretty nice validations using Angular 2 built in form controls. Using its conditional class application I simply apply valid or invalid to the field accordingly.
E.g.
<input
        type="text"
        id="name"
        formControlName="name"
        [class.invalid]="!complexForm.controls['name'].valid && complexForm.controls['firstName'].touched"
        [class.valid]="complexForm.controls['name'].valid && complexForm.controls['firstName'].touched"
      >

Of course how you write the validations and how you apply the classes will be different depending on how you're structuring your app the basic principle of "write your own validations then add/remove the valid and invalid classes to invoke Materialize's design" should work well.

It would be nice to add some custom rules similar to jQuery's validate plugin. I'd like to validate that 2 password fields match. Using the validate plugin it would be as simple as
`$('#password_1').validate({
rules:{
equalTo: '#password_2'
}
});
$('#password_2').validate({
rules:{
equalTo: '#password1'
}
})`


Replace TODO() with ProblemDeclaration nodes

Change to Node: add addtionalProblems field.
Replace TODOs with ProblemDeclarations.

Looks good to me. Since this changes node properties... Maybe a second opinion @konradweiss @KuechA

I'm also fine with the changes but we should fix the comment above


Create bankers_algorithm_safe_state.cpp

Please star this repository to show your support, in the meantime I am reviewing your code.

I starred the repository. I hope the code is fine.


What Next and Ideas for Beginner Projects hyperlinks lead to blank page

I downloaded the New Year's release for Windows and worked through it. It's awesome, thanks so much! But a couple issues with links leading only to blank pages: 1. On the last page/last chapter, the What Next hyperlink leads to a blank page, 2. On the home page once all chapters are completed, the Ideas for Beginner Projects hyperlink also leads to a blank page.

Oh interesting. Thanks for reporting this! I'll look into it when I get the chance.

Fixed in #208 ✨


Add support for "optional" re-exports

[!NOTE]
See #31 for an alternative. Differences between the two PRs are marked with 🔎

export optional { foo, bar } from "./there.js"

This PR adds a new keyword for exports, 🔎optional, to mark export ... from statements as three-shakeable. It has the following properties:

optional re-exports are only loaded if they are imported
optional exports are always evaluated later than the module that imported them (modulo cycles)

this guarantees that a module's behavior does not depend on any of its optional re-exports running. This is important because which optional re-exports run and which do not doesn't depend by the module itself, but by its consumers

export * from cannot be optional

this is because optional re-exports must explicitly define which bindings they are exporting, so that the re-exported file doesn't need to be loaded to know it

🔎 the optional modifier is indipendent from modifier that affect how the imported module is represented, so all the following variations are valid:

export optional * as x from "x" - only load x if the consumer is importing it. Eagerly link/execute it and build the namespace object.
export defer * as x from "x" - always load x and its dependencies, eagerly execute it's asynchronous subgraphs, and only execute the rest on property access on the namespace object
export optional defer * as x from "x" - only  load x if the consumer is importing it. If it gets loaded, eagerly execute it's asynchronous subgraphs, and only execute the rest on property access on the namespace object.
export optional source x from "x" - only load x if the consumer is importing it, and do so as defined in https://github.com/tc39/proposal-source-phase-imports

An optional re-export is considered to be used if the consumer of the module is:

importing with import * as (🔎 or import defer * as)
importing with import { ... } and listing the optional binding
importing with import(...) (🔎 or import.defer(...))

A follow-up proposal might introduce some syntax to mark which bindings will be used in namespace imports, such as import { foo, bar } as partialNamespace from "x" and import("x", { bindings: ["foo", "bar"] }).
A bundler/transpiler can re-write optional re-exports to these exact semantics by moving them to the consumer module:

OriginalRewritten

// main.js
import { val, bar } from "./dep.js";
import "other";

// dep.js
export let val = 2;
export { foo } from "a";
export optional { bar } from "b";
export optional { baz } from "c";

// main.js
import { val } from "./dep.js";
import { bar } from "b";
import "other";

// dep.js
export let val = 2;
export { foo } from "a";

// main.js
import * as ns from "./dep.js";

// dep.js
export let val = 2;
export { foo } from "a";
export optional { bar } from "b";
export optional { baz } from "c";

// main.js
import * as _n1 from "./dep.js";
import * as _n2 from "b";
import * as _n2 from "c";

const ns = Object.freeze({
  __proto__: null,
  get val() { return _n1.val; },
  get foo() { return _n1.foo; },
  get bar() { return _n2.bar; },
  get baz() { return _n3.baz; },
})

// dep.js
export let val = 2;
export { foo } from "a";

🔎
// main.js
import defer * as ns from "./dep.js";

// dep.js
export let val = 2;
export { foo } from "a";
export optional { bar } from "b";
export optional { baz } from "c";

// main.js
import defer * as _n1 from "./dep.js";
import defer * as _n2 from "b";
import defer * as _n2 from "c";

const _run = () => { _n1.val, _n2.val, _n3.val; }
const ns = Object.freeze({
  __proto__: null,
  get val() { _run(); return _n1.val; },
  get foo() { _run(); return _n1.foo; },
  get bar() { _run(); return _n2.bar; },
  get baz() { _run(); return _n3.baz; },
})

// dep.js
export let val = 2;
export { foo } from "a";

Rendered preview: https://nicolo-ribaudo.github.io/proposal-defer-import-eval/branch/optional-exports.html

I really like this framing of a new keyword for optional, I think point (4) in https://github.com/tc39/proposal-defer-import-eval/pull/31 already speaks to why this makes more sense semantically and in how it might compose with the other phases.
The idea of a partial deferred namespace is very interesting and I remember Yulia wanting to see something like this in the past. Would be interesting to explore that design space further as well!


Would be really nice to reprocess prep if you make a mistake without reloading and unlinking data

e.g. select 16S, should be 18S;

select the wrong preprocess option e.g. 16S, should be 18S

Would be much cleaner if prep-template is fine and data is fine to just reprocess with different options (rev comp) or for different target gene (16S, 18S, ITS)

@ackermag I think there are 2 issues here:

be able to redefine the data type in a prep info file, which should be propagated to all artifacts from that prep info file
be able to reprocess the same prep-info/raw-data using different parameters: this is currently possible

If you agree, I'll change the issue name.

I think this goes back to the fact that from the system point of view there is no difference between 16S, 18S or ITS - it doesn't affect anything on the processing pipeline. We should allow changing that as long as they are under the same type (i.e. we can change the description to target_gene.{16S,18S,ITS} and allow to change it as long as is in the target_gene.X series).

Right, do we have that definition somewhere or is that something we have to do? If we need to do, should that be a different issue?

@josenavas, ping! What do you think?

Renaming the issue for clarity.

How do we want to handle this? To be fair, the plugins don't even care about it, as it is applied in a per artifact basis. However, we can wrap this information as part of the type decorators that we were talking so plugins are aware of them, but let's revisit this after tomorrow's meeting.

Possible. Let's discuss during the Qiita meeting. Moving to Alpha 0.4.


wrong function called from module when using wasmtime loader

using wasm_module.wat:
(module
  (type (;0;) (func (result i32)))
  (func $func1 (type 0) (result i32)
    i32.const 1)
  (func $func2 (type 0) (result i32)
    i32.const 2)
  (table (;0;) 1 1 funcref)
  (memory (;0;) 16)
  (global (;0;) (mut i32) (i32.const 1048576))
  (global (;1;) i32 (i32.const 1048576))
  (global (;2;) i32 (i32.const 1048576))
  (export "memory" (memory 0))
  (export "func1" (func $func1))
  (export "func2" (func $func2))
  (export "__data_end" (global 1))
  (export "__heap_base" (global 2)))

when loaded as a python module, calling func1 returns 2 instead of 1.
this is because func2 is called instead, can be verified by modifying func2
tested with this script:
from wasmtime import Store, Module, Instance, Func, FuncType, loader
import wasm_module

store = Store()
module = Module(store.engine, open("wasm_module.wat").read())

instance = Instance(store, module, [])
func1 = instance.exports(store)["func1"]
assert func1(store) == wasm_module.func1(), f"from instance {func1(store)}, from loader {wasm_module.func1()}"

the error message is
Traceback (most recent call last):
  File "/home/user/Documents/test/test.py", line 9, in <module>
    assert func1(store) == wasm_module.func1(), f"from instance {func1(store)}, from loader {wasm_module.func1()}"
AssertionError: from instance 1, from loader 2

tested with wasmtime-0.29.0.dev168

Thanks for the report! This bug is probably around here and probably me not understanding how scoped variables work in Python. I'm not sure if that lambda expression works as I'm expecting by creating a new one each time with new captures...

Indeed that was the issue, should be fixed in https://github.com/bytecodealliance/wasmtime-py/pull/66


runtime: SIGSEGV while handling SIGSEGV

It appears that my program is segfaulting (receiving a sigsegv) while handling
a sigsegv.
I was having some GC issues and a coworker recommended trying go1.6beta1 to see
if it would fix the GC issues. It didn't (I've resolved them in other ways) but
it did start causing my program to segfault.
Sadly I can't share the actual binary or core dump but I can share other
information which should hopefully assist in tracking it down.
The segfault occurs after 12-24 hours of running. The program is network IO
intensive. Taking UDP packets on one side and streaming TCP on the other.
CC: @rsc and @ianlancetaylor I was told this would be of interest to you two.
Version
$ go version
go version devel +505fa7b Tue Jan 12 17:31:01 2016 +0000 darwin/amd64

I also had this occur with go1.6beta1, I'm attempting beta2 now, but it won't
be till tomorrow at the earliest that I know.
Do you use cgo or unsafe?
I don't believe so and no unsafe.
tarrant@box-name:~$ ldd canal
not a dynamic executable
GDB StackTrace
#0  0x000000000044930e in runtime.sigtrampgo (sig=11, info=0xc820d3dbb0, ctx=0xc820d3da80) at /usr/local/Cellar/go/HEAD/libexec/src/runtime/signal_sigtramp.go:27
#1  0x0000000000469995 in runtime.sigtramp () at /usr/local/Cellar/go/HEAD/libexec/src/runtime/sys_linux_amd64.s:234
#2  0x00000000004699a0 in runtime.sigtramp () at /usr/local/Cellar/go/HEAD/libexec/src/runtime/sys_linux_amd64.s:235
#3  0x0000000000000001 in ?? ()
#4  0x0000000000000000 in ?? ()

Go stacktrace
INFO[0000] normal-program logging here
Segmentation fault (core dumped)

Memory info from gdb:
(gdb) print #2
Invalid character '#' in expression.
(gdb) print g
$1 = (runtime.g *) 0x0
(gdb) print g.m
Cannot access memory at address 0x30

Registers
$ info registers
rax            0xc820001380<PHONE_NUMBER>04
rbx            0xc820d3da58<PHONE_NUMBER>04
rcx            0xc820d3da58<PHONE_NUMBER>04
rdx            0xc820d3da80<PHONE_NUMBER>44
rsi            0x128    296
rdi            0xc820d3da80<PHONE_NUMBER>44
rbp            0xc820d3da48    0xc820d3da48
rsp            0xc820d3d9c8    0xc820d3d9c8
r8             0x0    0
r9             0xc820d3dbb0<PHONE_NUMBER>48
r10            0x20    32
r11            0xc820802024<PHONE_NUMBER>48
r12            0x0    0
r13            0x2    2
r14            0xa74ec4    10964676
r15            0x1    1
rip            0x44930e    0x44930e <runtime.sigtrampgo+190>
eflags         0x10202    [ IF RF ]
cs             0x33    51
ss             0x2b    43
ds             0x0    0
es             0x0    0
fs             0x0    0
gs             0x0    0

Object Dump
go tool objdump -s '^runtime\.sigtrampgo$'
...
	signal_sigtramp.go:22	0x4492f9	c3			RET
	signal_sigtramp.go:26	0x4492fa	488d9c2490000000	LEAQ 0x90(SP), BX
	signal_sigtramp.go:26	0x449302	4889d9			MOVQ BX, CX
	signal_sigtramp.go:27	0x449305<PHONE_NUMBER>		MOVQ AX, 0x30(SP)
	signal_sigtramp.go:27	0x44930a	4c8b4030		MOVQ 0x30(AX), R8
	signal_sigtramp.go:27	0x44930e	4d8b4050		MOVQ 0x50(R8), R8
	signal_sigtramp.go:27	0x449312	498b18			MOVQ 0(R8), BX
	signal_sigtramp.go:27	0x449315	48894c2428		MOVQ CX, 0x28(SP)
	signal_sigtramp.go:27	0x44931a	4839cb			CMPQ CX, BX
	signal_sigtramp.go:27	0x44931d	7773			JA 0x449392
...

Thanks for the report.  Unfortunately I don't see enough here to know what to fix.  Are you saying that the Go program simply crashes with "Segmentation fault (core dumped)" and doesn't print anything else?  That should (of course) never happen.
There is something odd here.  Your go version output says darwin/amd64, but your backtrace says sys_linux_amd64.s.  Which is it?
The backtrace line suggests that the crash is because g != nil but g.m == nil or g.m.gsignal == nil.  Not sure how that could happen.
If you can figure out the arguments in the core dump, you can determine where the first SIGSEGV occurred by looking at the ctx argument to sigtrampgo.  It will be a pointer to a sigcontext struct, defined in runtime/defs_linux_amd64.go.  The rip field should point to the instruction that got the error.

I'm cross compiling from darwin to linux, so compiler is darwin/amd64 and runtime is sys_linux_amd64. Should have mentioned that.
env GOOS=linux go build -o bin/canal example.com/path/canal

Yes the go program simply crashes with Segmentation fault (core dumped). No additional info.
I'll poke and see if I can figure out where the first sigsegv is occurring.

Does your program crash if you compile it natively on the target Linux
machine?
On Sat, 16 Jan 2016, 10:23 tarrant<EMAIL_ADDRESS>wrote:

I'm cross compiling from darwin to linux, so compiler is darwin/amd64 and
runtime is sys_linux_amd64. Should have mentioned that.
env GOOS=linux go build -o bin/canal example.com/path/canal
Yes the go program simply crashes with Segmentation fault (core dumped).
No additional info.
I'll poke and see if I can figure out where the first sigsegv is occurring.
—
Reply to this email directly or view it on GitHub
https://github.com/golang/go/issues/13978#issuecomment-172124733.

I've reproduced the issue with a linux built binary. This also happened to test it with go1.6beta2.

Can you please paste the full stack trace from the crash.
On Mon, Jan 18, 2016 at 3:18 AM, tarrant<EMAIL_ADDRESS>wrote:

I've reproduced the issue with a linux built binary. This also happened to
test it with go1.6beta2.
—
Reply to this email directly or view it on GitHub
https://github.com/golang/go/issues/13978#issuecomment-172346290.

The go stacktrace (doesn't really exist) but here is what it prints out:
INFO[0000] PacketDecoder started
INFO[0000] PacketDecoder started
INFO[0000] PacketDecoder started
INFO[0000] PacketDecoder started
INFO[0000] PacketDecoder started
Segmentation fault (core dumped)

gdb:
tarrant@rep-testing-826198:~$ gdb canal-1453060415 core-1453060415
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /home/users/tarrant/canal-1453060415...done.

warning: core file may not match specified executable file.

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./canal -log debug
Program terminated with signal 11, Segmentation fault.
#0  0x0000000000446ddf in runtime.sigtrampgo (sig=11, info=0xc820095bb0, ctx=0xc820095a80)
    at /usr/local/go/src/runtime/signal_sigtramp.go:27
27      /usr/local/go/src/runtime/signal_sigtramp.go: No such file or directory.
warning: Missing auto-load scripts referenced in section .debug_gdb_scripts
of file /home/users/tarrant/canal-1453060415
Use `info auto-load-scripts [REGEXP]' to list them.
(gdb) bt
#0  0x0000000000446ddf in runtime.sigtrampgo (sig=11, info=0xc820095bb0, ctx=0xc820095a80)
    at /usr/local/go/src/runtime/signal_sigtramp.go:27
#1  0x000000000046533b in runtime.sigtramp () at /usr/local/go/src/runtime/sys_linux_amd64.s:234
#2  0x0000000000465340 in runtime.sigtramp () at /usr/local/go/src/runtime/sys_linux_amd64.s:235
#3  0x0000000000000001 in ?? ()
#4  0x0000000000000000 in ?? ()
(gdb)

I don't understand. There should be a panic from Go, especially for SEGV.
Are you sure there is no cgo in your project ? If you're doing packet
decoding are you using a library which is linking against libpcap? Is the
source of your project available ?
On Mon, Jan 18, 2016 at 7:57 AM, tarrant<EMAIL_ADDRESS>wrote:

The go stacktrace (doesn't really exist) but here is what it prints out:
INFO[0000] PacketDecoder started
INFO[0000] PacketDecoder started
INFO[0000] PacketDecoder started
INFO[0000] PacketDecoder started
INFO[0000] PacketDecoder started
Segmentation fault (core dumped)
gdb:
tarrant@rep-testing-826198:~$ gdb canal-1453060415 core-1453060415
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
http://bugs.launchpad.net/gdb-linaro/...
Reading symbols from /home/users/tarrant/canal-1453060415...done.
warning: core file may not match specified executable file.

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by ./canal -log debug Program terminated with signal 11, Segmentation fault. #0  0x0000000000446ddf in runtime.sigtrampgo (sig=11, info=0xc820095bb0, ctx=0xc820095a80)     at /usr/local/go/src/runtime/signal_sigtramp.go:27 27      /usr/local/go/src/runtime/signal_sigtramp.go: No such file or directory. warning: Missing auto-load scripts referenced in section .debug_gdb_scripts of file /home/users/tarrant/canal-1453060415 Use info auto-load-scripts [REGEXP]' to list them.
(gdb) bt
#0  0x0000000000446ddf in runtime.sigtrampgo (sig=11, info=0xc820095bb0, ctx=0xc820095a80)
at /usr/local/go/src/runtime/signal_sigtramp.go:27
#1  0x000000000046533b in runtime.sigtramp () at /usr/local/go/src/runtime/sys_linux_amd64.s:234
#2  0x0000000000465340 in runtime.sigtramp () at /usr/local/go/src/runtime/sys_linux_amd64.s:235
#3  0x0000000000000001 in ?? ()
#4  0x0000000000000000 in ?? ()
(gdb)
—
Reply to this email directly or view it on GitHub
https://github.com/golang/go/issues/13978#issuecomment-172379757.

We're unfortunately not able to share the source code for the program. There's no cgo in this program outside of the core net and runtime/race packages. The packet processing is done on UDP packets in pure Go, not on SOCK_RAW with libpcap. The race detector has not found any data races in the program.
The program crashes with SIGSEGV in runtime.sigtrampgo, apparently because either g.m or g.m.gsignal is nil. The sig argument to sigtrampgo is 11, indicating that it was called in response to a SIGSEGV from elsewhere in the program. The ctx argument should point to a runtime.sigcontext struct, so we look at the memory it points to. The rip field in the core dumps is indeed a pointer, but not to a valid instruction. We have an example of it pointing into the .rodata section (to the string "GC worker (idle)"), and an example of it pointing to a runtime.g value (with 0xfffffffffffffade showing up after 16 bytes, where we'd expect the runtime.g's stackguard0 field to be).
I suspect that the instruction pointer for the first SIGSEGV is being accurately reported; that is, the original SIGSEGV is caused by an attempt to execute non-executable memory. I think this is likely due to memory corruption in the scheduler's datastructures.
How can we hunt down corruption in the scheduler's memory? Does corruption there sound like a plausible explanation for the crashes we see?

Can you reproduce the problem on previous versions of Go 1.5.3 or 1.4.2?

How can we hunt down corruption in the scheduler's memory? Does corruption there sound like a plausible explanation for the crashes we see?

Possible, but unlikely, corruption of this sort usually comes from data races in the program.
If you suspect that your tests do not exercise possible racy paths, could you build a race enabled version of your program and deploy it ? go build -race $PKG will do it.

Can you run the process under gdb? That should stop at the point of the first segfault rather than when go's handler breaks and may be easier to find out what's going on. Alternatively, I guess, you could disable go's handling of SIGSEGV entirely.
As to figuring out why you're jumping into the weeds, I guess if you're lucky you're jumping via CALL and the address you jumped from is on the top of the stack. If not, you might still be able to figure out where you were in the code by looking through the stack, though of course if the jump is from runtime·gogo or something like that this won't help.

The program has been running with the race detector for the past hour with no races reported. It hasn't encountered the SIGSEGV yet, but all other periodic code paths should have been exercised a few hundred times.
We can run the process under gdb, though it may take a day before we see the crash again. Disabling Go's SIGSEGV handling to force an immediate core dump sounds attractive. Can this be done via signal.Ignore(syscall.SIGSEGV), or does it require calling sigaction(2) directly?

We can run the process under gdb, though it may take a day before we see the crash again. Disabling Go's SIGSEGV handling to force an immediate core dump sounds attractive. Can this be done via signal.Ignore(syscall.SIGSEGV), or does it require calling sigaction(2) directly?

I don't actually know the answer to this. I was thinking of hacking out the runtime code that installs the SIGSEGV handler...

The goroutine that's segfaulting is one of the GC's background mark workers. Both usable core dumps we have show the same thing (below). runtime.sigtrampgo is called with the sig argument set to 11 for SIGSEGV, and the contents of the info argument indicate signal 11 with si_code SEGV_MAPERR indicating that the fault is due to an unmapped address and the fault address is 0xd8.
go tool objdump indicates that the result of the call to getg is stored in the AX register.
$ gdb {program,core}-1452891329
[snip]
Program terminated with signal 11, Segmentation fault.
#0  0x000000000044930e in runtime.sigtrampgo (sig=11, info=0xc820d3dbb0, ctx=0xc820d3da80) at /usr/local/Cellar/go/HEAD/libexec/src/runtime/signal_sigtramp.go:27
[snip]
(gdb) p info.si_signo
$1 = 11
(gdb) p info.si_code
$2 = 1
(gdb) p/x info.si_addr
$3 = 0xd8
(gdb) info symbol (('runtime.g'*)$rax).gopc
runtime.gcBgMarkStartWorkers + 159 in section .text of /path/to/program-1452891329
(gdb) info symbol (('runtime.g'*)$rax).startpc
runtime.gcBgMarkWorker in section .text of /path/to/program-1452891329

$ gdb {program,core}-1453060415
[snip]
Program terminated with signal 11, Segmentation fault.
#0  0x0000000000446ddf in runtime.sigtrampgo (sig=11, info=0xc820095bb0, ctx=0xc820095a80) at /usr/local/go/src/runtime/signal_sigtramp.go:27
[snip]
(gdb) p info.si_signo
$1 = 11
(gdb) p info.si_code
$2 = 1
(gdb) p/x info.si_addr
$3 = 0xd8
(gdb) info symbol (('runtime.g'*)$rax).gopc
runtime.gcBgMarkStartWorkers + 147 in section .text of /path/to/program-1453060415
(gdb) info symbol (('runtime.g'*)$rax).startpc
runtime.gcBgMarkWorker in section .text of /path/to/program-1453060415

I think I've found the cause of our issues. The G that runs the GC background mark worker is sometimes running without an M. When that goroutine calls runtime.acquirem, it's unable to dereference _g_.m, which leads to a SIGSEGV at address 0xd8 when running the following instructions:
FS MOVQ FS:0xfffffff8, AX
MOVQ 0x30(AX), CX
MOVL 0xd8(CX), R8

The ctx argument to sigtrampgo doesn't point right to a *runtime.sigcontext - it points to 40 bytes before a *runtime.sigcontext, so all of the field names were wrong. Adding 0x28 to the pointer results in much more believable register contents, such as 1) an instruction pointer that points to an instruction in the text segment, and 2) a stack pointer that points to an address between stack.lo and stack.hi:
Crash<PHONE_NUMBER>, built on darwin/amd64 to run on linux/amd64 at go version devel +505fa7b Tue Jan 12 17:31:01 2016 +0000
$ gdb {program,core}-1452891329
[snip]
(gdb) p/x (('runtime.g'*)$rax).stack.lo
$1 = 0xc82024c000
(gdb) p/x (('runtime.g'*)$rax).stack.hi
$2 = 0xc82024c7e0
(gdb) p/x (('runtime.sigcontext'*)(ctx+0x28)).rsp
$3 = 0xc82024c740
(gdb) p/x (('runtime.sigcontext'*)(ctx+0x28)).rip
$4 = 0x41f9f8
(gdb) info symbol (('runtime.sigcontext'*)(ctx+0x28)).rip
runtime.gcBgMarkWorker + 376 in section .text of /path/to/program-1452891329
(gdb) p/x (('runtime.sigcontext'*)(ctx+0x28)).rcx
$5 = 0x0

$ go tool objdump /path/to/program-1452891329 | grep -C 3 '0x41f9f8'
	mgc.go:1469	0x41f9ea	c3			RET
	mgc.go:1390	0x41f9eb	64488b0425f8ffffff	FS MOVQ FS:0xfffffff8, AX
	mgc.go:1390	0x41f9f4	488b4830		MOVQ 0x30(AX), CX
	mgc.go:1390	0x41f9f8	448b81d8000000		MOVL 0xd8(CX), R8
	mgc.go:1390	0x41f9ff	41ffc0			INCL R8
	mgc.go:1390	0x41fa02	448981d8000000		MOVL R8, 0xd8(CX)
	mgc.go:1390	0x41fa09	4c8b4030		MOVQ 0x30(AX), R8

Crash<PHONE_NUMBER>, built on linux/amd64 to run on linux/amd64 at go version go1.6beta2
$ gdb {canal,core}-1453060415
[snip]
(gdb) p/x (('runtime.g'*)$rax).stack.lo
$1 = 0xc8202a7800
(gdb) p/x (('runtime.g'*)$rax).stack.hi
$2 = 0xc8202a7fe0
(gdb) p/x (('runtime.sigcontext'*)(ctx+0x28)).rsp
$3 = 0xc8202a7f20
(gdb) p/x (('runtime.sigcontext'*)(ctx+0x28)).rip
$4 = 0x434514
(gdb) info symbol (('runtime.sigcontext'*)(ctx+0x28)).rip
runtime.gopark + 36 in section .text of /path/to/program-1453060415
(gdb) p/x (('runtime.sigcontext'*)(ctx+0x28)).rax
$5 = 0x0

$ go tool objdump /path/to/program-1453060415 | grep -C 3 '0x434514'
	proc.go:248	0x434503	4883ec20		SUBQ $0x20, SP
	proc.go:249	0x434507	64488b0c25f8ffffff	FS MOVQ FS:0xfffffff8, CX
	proc.go:249	0x434510	488b4130		MOVQ 0x30(CX), AX
	proc.go:249	0x434514	8ba8d8000000		MOVL 0xd8(AX), BP
	proc.go:249	0x43451a	ffc5			INCL BP
	proc.go:249	0x43451c	89a8d8000000		MOVL BP, 0xd8(AX)
	proc.go:249	0x434522	488b6930		MOVQ 0x30(CX), BP

So to summarize, our program is crashing because a GC background mark worker is running with g.m set to nil. This causes a segfault, which causes the signal handler to run, which in turn encounters a segfault when it tries to dereference g.m, resulting in an immediate and unceremonious crash of the program.

The 40 byte offset is because I'd been misinterpreting the meaning of the ctx argument to runtime.sigtrampgo. It's an unsafe.Pointer to a runtime.ucontext value which on amd64 includes a runtime.sigcontext value at a 40-byte offset (rather than a pointer directly to a runtime.sigcontext value). runtime/signal_linux_amd64.go shows how to correctly interpret the contents.
I don't have any further answers for why the GC worker is running without an M.

It looks like this is the same bug as #13363, although the CPU profiler was not involved with these crashes. /cc @aclements

@rhysh thanks for the good investigative work.
@RLH @aclements it appears that in some (uncommon) case gcBgMarkWorker can be started up without an m.

Crash<PHONE_NUMBER> on go version 505fa7b comes in the middle of runtime.gcBgMarkWorker during a call to runtime.acquirem. This isn't the first call to runtime.acquirem in that function, which means that the worker must have had an m when it started and then lost it (otherwise we'd see a segfault at the first call).
Crash<PHONE_NUMBER> on go version go1.6beta2 comes at the call to runtime.acquirem at the start of runtime.gopark. I looked through the stack of the crashed goroutine for instruction addresses and found a 64-bit aligned value of 0x000000000041f0fc at address 0xc8202a7f40, between the stack.hi value of 0xc8202a7fe0 and the rsp value of 0xc8202a7f20. The instruction address corresponds to the return from runtime.gopark at the top of runtime.gcBgMarkWorker's for loop. If I've unwound the stack correctly, this means that gcBgMarkWorker calling gopark calling acquirem led to the second crash.
$ go tool objdump /path/to/program-1453060415 | grep -C 3 '0x41f0fc'
	mgc.go:1378	0x41f0e9	c644242014		MOVL $0x14, 0x20(SP)
	mgc.go:1378	0x41f0ee	48c744242800000000	MOVQ $0x0, 0x28(SP)
	mgc.go:1378	0x41f0f7	e8f4530100		CALL runtime.gopark(SB)
	mgc.go:1383	0x41f0fc	488b6c2470		MOVQ 0x70(SP), BP
	mgc.go:1383	0x41f101	4883fd00		CMPQ $0x0, BP
	mgc.go:1383	0x41f105	0f845d050000		JE 0x41f668
	mgc.go:1383	0x41f10b	488b9d10120000		MOVQ 0x1210(BP), BX

The gcBgMarkWorker goroutines had an m when they were created, but had their execution resumed at some point without an m.

Nice debugging! I agree that this is almost certainly the same failure as #13363. You're positive that CPU profiling wasn't enabled? Is it possible the application is receiving other asynchronous signals? (I would love to rule out async signals as a possible cause.)

pprof is installed, but I was not actually calling any of the pprof endpoints for most of the crashes. Many of them I'd start the process close the screen session and then go home for the day to have it crash the next morning.
I don't think any async signals are being called, though they may be under the hood. Most of the syscalls are read/write to network fds.
I'll poke and see if I can find any others but I seriously doubt it.

I can think of a few hypotheses:

The background mark worker goroutine was resumed from preemption with g.m == nil.
The background mark worker was running and something it did set g.m to nil (without stopping the G).
The background mark worker was running and another thread concurrently set g.m to nil.
The background mark worker was running and a signal (running synchronously) returned with g.m set to nil.
Memory corruption.

We may be able to disprove 1 by looking at where the SIGSEGVs happen relative to possible preemption points. The background mark worker has fairly limited preemption points and since the goroutine can only resume at a preemption point, if there are any successful accesses to g.m between the crash and the previous preemption point, we can rule out 1.
My case from #13363 does not disprove 1. In fact, since we resume from an involuntary preemption at the call to morestack, the crash happened just a few instructions after a possible resume point. This lends support to theory 1, but does not prove it.
@rhysh, in<PHONE_NUMBER>, do you know which acquirem crashed?
Crash<PHONE_NUMBER> would seem to disprove 1. As of the acquirem in gopark, the goroutine hasn't been preemptible for quite a while. On all of the code paths that lead from disabling preemption to gopark (of which I think there are three: function entry, regular looping around, and looping around from the gcMarkDone condition), we've done our own acquirem, which would indicate g.m != nil since the last preemption point.
Further evidence against 1 is that execute itself would crash if g.m were nil. However, there are other calls to gogo that wouldn't crash if g.m were nil.
For 2 and 3, we need to consider the places that modify g.m. Ignoring places where we assign g0.m or gsignal.m, there are four: newextram, execute, dropg, and goexit0. newextram always sets it to non-nil (and immediately uses it), so we can discount it. Likewise, execute would crash if g.m were nil. dropg and goexit0 do set g.m to nil.
@rhysh or @tarrant, could you have GDB dump the whole current G?
For 2, it's almost certainly not goexit0. For 3, it could conceivably be goexit0. However, in #13363, it's definitely not goexit0 because the status is _Grunning and the waitstatus is set. Likewise, all of the calls to dropg are immediately preceded by setting the status to something other than _Grunning. Most paths back to _Grunning would crash if g.m were nil, but I'm not sure all of them would. This would be a useful place to dig deeper.
For 4, I'm pretty sure there's nothing specific in the signal code that modifies g.m and I don't think it can call any of the functions I mentioned above. So 4 seems unlikely.
I hope it's not 5.

gdb {canal,core}-1453060415
...
(gdb) print/x *g
$1 = {stack = {lo = 0xc8202a7800, hi = 0xc8202a7fe0}, stackguard0 = 0xc8202a7ad0, stackguard1 = 0xffffffffffffffff, _panic = 0x0, _defer = 0x0, m = 0x0, stackAlloc = 0x800,
  sched = {sp = 0x0, pc = 0x434653, g = 0xc8203dc300, ctxt = 0x0, ret = 0x0, lr = 0x0, bp = 0x0}, syscallsp = 0x0, syscallpc = 0x0, stkbar = {array = 0xc8202a7fe0, len = 0x0,
    cap = 0x2}, stkbarPos = 0x0, stktopsp = 0xc8202a7fb8, param = 0x0, atomicstatus = 0x2, stackLock = 0x0, goid = 0x232, waitsince = 0x0, waitreason = {str = 0x9bf1e0,
    len = 0x10}, schedlink = 0x0, preempt = 0x0, paniconfault = 0x0, preemptscan = 0x0, gcscandone = 0x1, gcscanvalid = 0x0, throwsplit = 0x0, raceignore = 0x0,
  sysblocktraced = 0x0, sysexitticks = 0x0, sysexitseq = 0x0, lockedm = 0x0, sig = 0x0, writebuf = {array = 0x0, len = 0x0, cap = 0x0}, sigcode0 = 0x0, sigcode1 = 0x0,
  sigpc = 0x0, gopc = 0x41ef63, startpc = 0x41efd0, racectx = 0x0, waiting = 0x0, gcAssistBytes = 0x0}

Thanks for looking into this, Austin.
The acquirem call in<PHONE_NUMBER> is the one towards the top of gcBgMarkWorker's for loop: https://github.com/golang/go/blob/505fa7b/src/runtime/mgc.go#L1390
I've collected quite a few core dumps from reproducing #13363, which show five different call stacks at the time of the crash. I'm building binaries of the runtime/pprof test for linux/amd64 with go version devel +01b8640 Sat Jan 16 03:35:23 2016 +0000 darwin/amd64, with a toolchain built with GOEXPERIMENT=framepointer and with the pprof frequency set to 500Hz. I have a gdb script that uses the frame pointer to unwind the stacks.
$ for core in ./core-* ; do gdb --batch --command unwind.gdb ./pprof.test $core 2>/dev/null | grep -A 2 '^\$' | sed -n -e 's/ in section .*//p' | sed -e 's/ //g' | tac | tr '\n' ';' | sed -e 's/;$/\n/' ; done | sort | uniq -c | sort -n -r
     38 runtime.goexit+1;runtime.gcBgMarkWorker+1273;runtime.gcMarkDone+62;runtime.semacquire+46
     30 runtime.goexit+1;runtime.gcBgMarkWorker+1273;runtime.morestack+13
     24 runtime.goexit+1;runtime.gcBgMarkWorker+321;runtime.gopark+46
      1 runtime.goexit+1;runtime.gcBgMarkWorker+718;runtime.gcDrain+277;runtime.(*gcWork).balance+148;runtime.handoff+162
      1 runtime.goexit+1;runtime.gcBgMarkWorker+321;runtime.gopark+432;runtime.writebarrierptr+129;runtime.writebarrierptr_nostore1+27

stress command:
./stress sh -c "GODEBUG=gcstackbarrierall=1,gcstackbarrierall=0 GOGC=1 ./pprof.test -test.run TestStackBarrierProfiling"

gdb script:
$ cat unwind.gdb
printf "\n"
p/x (('runtime.sigcontext'*)(ctx+0x28)).rip
i sym (('runtime.sigcontext'*)(ctx+0x28)).rip
set $ptr = (long *)(('runtime.sigcontext'*)(ctx+0x28)).rbp

while $ptr != 0
  printf "\n"
  set $instr = *($ptr+1)
  p/x $instr
  i sym $instr
  set $ptr = *(long **)($ptr)
end

changes to core packages to make reproducing easier, per #13363:
diff --git a/src/runtime/pprof/pprof.go b/src/runtime/pprof/pprof.go
index d32b315..f1d8cbb 100644
--- a/src/runtime/pprof/pprof.go
+++ b/src/runtime/pprof/pprof.go
@@ -577,7 +577,7 @@ func StartCPUProfile(w io.Writer) error {
        // system, and a nice round number to make it easy to
        // convert sample counts to seconds.  Instead of requiring
        // each client to specify the frequency, we hard code it.
-       const hz = 100
+       const hz = 500

        cpu.Lock()
        defer cpu.Unlock()
diff --git a/src/runtime/pprof/pprof_test.go b/src/runtime/pprof/pprof_test.go
index c241b54..6d83236 100644
--- a/src/runtime/pprof/pprof_test.go
+++ b/src/runtime/pprof/pprof_test.go
@@ -103,7 +103,7 @@ func parseProfile(t *testing.T, bytes []byte, f func(uintptr, []uintptr)) {
        }

        hd, val, tl := val[:5], val[5:l-3], val[l-3:]
-       if hd[0] != 0 || hd[1] != 3 || hd[2] != 0 || hd[3] != 1e6/100 || hd[4] != 0 {
+       if hd[0] != 0 || hd[1] != 3 || hd[2] != 0 /*|| hd[3] != 1e6/100*/ || hd[4] != 0 {
                t.Fatalf("unexpected header %#x", hd)
        }

That is, 38 core dumps where the currently running goroutine had a stack of runtime.goexit+1 -> runtime.gcBgMarkWorker+1273 -> runtime.gcMarkDone+62 -> runtime.semacquire+46, which corresponds to a stack of:
runtime.gcBgMarkWorker https://github.com/golang/go/blob/01b8640/src/runtime/mgc.go#L1459
runtime.gcMarkDone https://github.com/golang/go/blob/01b8640/src/runtime/mgc.go#L1042
runtime.semacquire https://github.com/golang/go/blob/01b8640/src/runtime/sema.go#L68
30 core dumps with a stack of runtime.goexit+1 -> runtime.gcBgMarkWorker+1273 -> runtime.morestack+13, meaning:
runtime.gcBgMarkWorker https://github.com/golang/go/blob/01b8640/src/runtime/mgc.go#L1459
runtime.morestack https://github.com/golang/go/blob/01b8640/src/runtime/asm_amd64.s#L324
24 of runtime.goexit+1 -> runtime.gcBgMarkWorker+321 -> runtime.gopark+46:
runtime.gcBgMarkWorker https://github.com/golang/go/blob/01b8640/src/runtime/mgc.go#L1382
runtime.gopark https://github.com/golang/go/blob/01b8640/src/runtime/proc.go#L249
One of runtime.goexit+1 -> runtime.gcBgMarkWorker+718 -> runtime.gcDrain+277 -> runtime.(*gcWork).balance+148 -> runtime.handoff+162:
runtime.gcBgMarkWorker https://github.com/golang/go/blob/01b8640/src/runtime/mgc.go#L1412
runtime.gcDrain https://github.com/golang/go/blob/01b8640/src/runtime/mgcmark.go#L826
runtime.(*gcWork).balance https://github.com/golang/go/blob/01b8640/src/runtime/mgcwork.go#L245
runtime.handoff https://github.com/golang/go/blob/01b8640/src/runtime/mgcwork.go#L461
One of runtime.goexit+1 -> runtime.gcBgMarkWorker+321 -> runtime.gopark+432 -> runtime.writebarrierptr+129 -> runtime.writebarrierptr_nostore1+27:
runtime.gcBgMarkWorker https://github.com/golang/go/blob/01b8640/src/runtime/mgc.go#L1382
runtime.gopark https://github.com/golang/go/blob/01b8640/src/runtime/proc.go#L256
runtime.writebarrierptr https://github.com/golang/go/blob/01b8640/src/runtime/mbarrier.go#L143
runtime.writebarrierptr_nostore1 https://github.com/golang/go/blob/01b8640/src/runtime/mbarrier.go#L110

I think that last crash may be the most interesting, as it happens within runtime.gopark after a successful call to acquirem.
The write to mp.waitunlockf invokes a write barrier which calls acquirem and hits a SIGSEGV.
func gopark(unlockf func(*g, unsafe.Pointer) bool, lock unsafe.Pointer, reason string, traceEv byte, traceskip int) {
	mp := acquirem() // getg().m is non-nil when this line executes
	gp := mp.curg
	status := readgstatus(gp)
	if status != _Grunning && status != _Gscanrunning {
		throw("gopark: bad g status")
	}
	mp.waitlock = lock
	mp.waitunlockf = *(*unsafe.Pointer)(unsafe.Pointer(&unlockf)) // SIGSEGV here during write barrier
	gp.waitreason = reason
	mp.waittraceev = traceEv
	mp.waittraceskip = traceskip
	releasem(mp)
	// can't do anything that might move the G between Ms here.
	mcall(park_m)
}

Thanks @tarrant, it looks like that G is very similar to the one from #13363. It's in state _Grunning and the wait reason is set, so the same conclusions apply.
@rhysh, you're right that that last crash is really interesting. What makes it even more interesting is that there's also a write barrier on the previous line that would have crashed if g.m was nil on that line.
That strongly suggests that either the write barrier itself can somehow clear g.m, or something is concurrently clearing it. It's hard to say for sure, but I don't think any of the other stack traces are obviously incompatible with the theory that the write barrier itself is doing it. Though my hunch is that something is concurrently clearing it since there are so many different stacks and the write barrier itself is fairly deterministic.

I may know how this is happening. In the gcMarkDone case of the mark worker, the worker disassociates with the P and makes itself preemptible, and then later attempts to reassociate with the P. If the scheduler moved the worker to a different P while it was preemptible (and a new worker hasn't been started for the original P), then as soon as the worker reassociates with the original P, the scheduler on that P can run the worker. It may do so before the worker has fully parked itself, at which point the worker G is effectively running on two Ms simultaneously.
The sequence of steps is something like:

The worker on P1/M1 makes itself preemptible and enters gcMarkDone.
The scheduler moves the worker to P2/M2.
On P2, the worker reassociates itself as the worker for P1.
On P2, the worker calls gopark, which calls park_m, which cas's the G's status to _Gwaiting.
On P1, the scheduler selects the worker to run, cas's its status from _Gwaiting to _Grunnable, calls execute, which cas's its status from _Grunnable to _Grunning, and begins executing at whatever point in the worker was left in the sched buffer (which should be wherever it got preempted during gcMarkDone).
On P2, park_m calls dropg, which clears the worker G's m.
On P1, the worker crashes at whatever next touches the m.

@rhysh or @tarrant, can you give https://go-review.googlesource.com/18741 a try? It's not a good fix, but it should test if I'm right about the cause.

Hmm. The trybots are indicating that maybe you don't want to try CL 18741. It seems my "XXX This is definitely not ideal." is actually "XXX This causes random deadlocks all over the place." However, this does confirm that the workers really do migrate between Ps sometimes in this code path.

This time for real. @rhysh or @tarrant, can you give https://go-review.googlesource.com/18761 a try? I think that's actually the right fix (and it passes the trybots).

Sweet, I've gotten a patched version of go setup and the binary is built and running. I'll let it run for a few days and if nothing happens we can almost safely say this is fixed.

I think there's a bug in my CL that causes it to deadlock occasionally, but
any results you can come up with are useful.

Yea looking like a deadlock.
$ sudo perf top -p `pgrep canal`
Events: 2M cycles
 29.33%  canal             [.] runtime.findrunnable
 16.41%  [kernel]          [k] __ticket_spin_lock
  7.40%  canal             [.] runtime.runqgrab
  6.34%  canal             [.] runtime/internal/atomic.Load
  3.34%  canal             [.] runtime/internal/atomic.Xadd64
  3.29%  canal             [.] runtime/internal/atomic.Xadd
  2.80%  canal             [.] runtime.runqsteal
  2.73%  canal             [.] runtime.lock
  2.50%  canal             [.] runtime/internal/atomic.Xchg
  2.34%  canal             [.] runtime.fastrand1
  2.26%  canal             [.] runtime.gcFlushBgCredit
  1.54%  canal             [.] runtime.procyield
  1.42%  canal             [.] runtime/internal/atomic.Cas
  0.96%  canal             [.] runtime.(*gcControllerState).findRunnableGCWorker.func1
  0.87%  canal             [.] runtime.gcmarkwb_m
  0.66%  canal             [.] runtime.schedule
  0.65%  canal             [.] runtime.gcBgMarkWorker
  0.59%  canal             [.] runtime.writebarrierptr_nostore1
  0.57%  canal             [.] runtime.systemstack
  0.56%  canal             [.] runtime.mallocgc
  0.55%  canal             [.] runtime.execute
  0.50%  [kernel]          [k] __wake_up_common
  0.49%  [vdso]            [.] 0x7ffdbd1d870c
  0.48%  canal             [.] runtime.heapBitsForObject
  0.39%  [kernel]          [k] gup_pte_range

Doesn't look like any time is being spent in my code, instead its just spinning trying to find a thread to run.

Actually, it was spinning waiting for a dead thread to enter the "waiting" state, which, needless to say, was never going to happen. :)
But I think I've fixed the problem and it's passing my stress tests. Could you try the new version of CL 18761?

This one seems to run better, but my program is still spending most of its time spinning.
Events: 273K cycles
 18.41%  [kernel]          [k] __ticket_spin_lock
 18.12%  canal             [.] runtime.findrunnable
  8.89%  canal             [.] runtime.runqgrab
  7.41%  canal             [.] runtime/internal/atomic.Load
  3.74%  canal             [.] runtime/internal/atomic.Xadd
  3.56%  canal             [.] runtime/internal/atomic.Xadd64
  3.36%  canal             [.] runtime.runqsteal
  3.01%  canal             [.] runtime.lock
  2.85%  canal             [.] runtime.fastrand1
  2.71%  canal             [.] runtime/internal/atomic.Xchg
  2.52%  canal             [.] runtime.gcFlushBgCredit
  1.69%  canal             [.] runtime.procyield
  1.53%  canal             [.] runtime/internal/atomic.Cas
  1.30%  canal             [.] runtime.gcBgMarkWorker
  1.13%  canal             [.] runtime.(*gcControllerState).findRunnableGCWorker.func1
  0.80%  canal             [.] runtime.gcmarkwb_m
  0.70%  canal             [.] runtime.mallocgc
  0.66%  canal             [.] runtime.writebarrierptr_nostore1
  0.63%  canal             [.] runtime.systemstack
  0.63%  canal             [.] runtime.gcDrain
  0.57%  [vdso]            [.] 0x7ffd809b370c

@tarrant, interesting. What does the profile look like without the CL?

It would look a lot better if I had frame pointers enabled. But:
Events: 295K cycles
 73.83%  canal (deleted)   [.] 0x3e9d4
 14.63%  [kernel]          [k] __ticket_spin_lock
  0.74%  [kernel]          [k] gup_pte_range
  0.69%  [vdso]            [.] 0x7ffccd34f70c
  0.49%  [kernel]          [k] get_futex_key
  0.46%  [kernel]          [k] __wake_up_common
  0.41%  [kernel]          [k] __wait_on_bit_lock
  0.40%  [kernel]          [k] put_page
  0.38%  [kernel]          [k] prepare_to_wait_exclusive
  0.30%  [kernel]          [k] __schedule
  0.29%  [kernel]          [k] get_user_pages_fast
  0.28%  [kernel]          [k] __ticket_spin_unlock
  0.25%  [kernel]          [k] get_futex_key_refs.isra.11
  0.25%  [kernel]          [k] __wake_up_bit
  0.25%  [kernel]          [k] native_write_msr_safe
  0.24%  [kernel]          [k] wake_bit_function
  0.24%  [kernel]          [k] try_to_wake_up
  0.21%  [kernel]          [k] update_curr
  0.21%  [kernel]          [k] copy_user_generic_string
  0.20%  [kernel]          [k] unlock_page
  0.18%  [kernel]          [k] wake_affine
  0.18%  [kernel]          [k] effective_load.isra.57
  0.18%  [kernel]          [k] page_waitqueue
  0.16%  [kernel]          [k] drop_futex_key_refs.isra.14
  0.15%  [kernel]          [k] io_schedule

Thanks @tarrant. Unfortunately, I can't compare these profiles because there aren't any Go symbols in the second one. It looks like it's spending roughly the same amount of time in __ticket_spin_lock, but, for instance, I don't know if runtime.findrunnable has become more expensive with my CL.

Hopefully this will help. Its still a perf top. If there is a better way to let you see what is going on let me know and I'll do my best.
Events: 267K cycles
  4.18%  [kernel]          [k] __ticket_spin_lock
  3.48%  canal             [.] runtime.mallocgc
  3.16%  canal             [.] runtime.scanobject
  2.03%  canal             [.] runtime/internal/atomic.Xchg
  1.71%  canal             [.] runtime.pcvalue
  1.71%  canal             [.] runtime.greyobject
  1.59%  canal             [.] runtime.heapBitsForObject
  1.54%  canal             [.] runtime.memmove
  1.38%  canal             [.] runtime/internal/atomic.Cas64
  1.38%  canal             [.] runtime.readvarint
  1.32%  canal             [.] runtime.gcDrain
  1.28%  canal             [.] runtime.findrunnable
  1.23%  canal             [.] runtime.heapBitsSetType
  1.20%  canal             [.] runtime/internal/atomic.Load
  1.17%  canal             [.] runtime.lock
  1.15%  canal             [.] runtime.procyield
  1.10%  canal             [.] runtime.selectgoImpl
  1.06%  canal             [.] sync/atomic.CompareAndSwapUint32
  1.05%  canal             [.] runtime/internal/atomic.Load64
  1.05%  canal             [.] runtime.gentraceback
  1.03%  canal             [.] runtime/internal/atomic.Xadd
  1.02%  canal             [.] runtime.step
  0.90%  canal             [.] sync/atomic.AddUint32
  0.88%  canal             [.] runtime.systemstack

Hi @tarrant. I haven't been able to reproduce any performance problems with this CL with either the go1 benchmarks or the x/benchmarks garbage benchmark. Are you sure those profiles are comparable? Do you have end-to-end benchmark numbers that show a problem?
$ benchstat log.b203f88 log.fa839a1
name                     old time/op    new time/op    delta
BinaryTree17-4              2.98s ± 2%     3.00s ± 3%    ~     (p=0.690 n=5+5)
Fannkuch11-4                2.81s ± 3%     2.67s ± 3%  -5.03%  (p=0.016 n=5+5)
FmtFprintfEmpty-4          56.5ns ±14%    53.8ns ± 4%    ~     (p=0.310 n=5+5)
FmtFprintfString-4          176ns ±21%     165ns ± 3%    ~     (p=0.365 n=5+5)
FmtFprintfInt-4             162ns ± 1%     160ns ± 2%    ~     (p=0.556 n=4+5)
FmtFprintfIntInt-4          264ns ± 6%     253ns ± 2%  -4.02%  (p=0.032 n=5+5)
FmtFprintfPrefixedInt-4     241ns ± 2%     239ns ± 1%    ~     (p=0.325 n=5+5)
FmtFprintfFloat-4           339ns ± 5%     336ns ± 1%    ~     (p=0.913 n=5+5)
FmtManyArgs-4              1.07µs ± 5%    1.03µs ± 3%    ~     (p=0.056 n=5+5)
GobDecode-4                8.23ms ± 5%    8.08ms ± 2%    ~     (p=0.222 n=5+5)
GobEncode-4                6.97ms ± 2%    6.90ms ± 1%    ~     (p=0.151 n=5+5)
Gzip-4                      346ms ± 1%     356ms ±11%    ~     (p=0.690 n=5+5)
Gunzip-4                   41.3ms ± 3%    40.9ms ± 4%    ~     (p=0.421 n=5+5)
HTTPClientServer-4         66.3µs ± 6%    64.2µs ± 0%    ~     (p=0.151 n=5+5)
JSONEncode-4               18.0ms ± 2%    17.8ms ± 2%    ~     (p=0.095 n=5+5)
JSONDecode-4               52.2ms ± 1%    52.8ms ± 1%    ~     (p=0.063 n=5+4)
Mandelbrot200-4            4.19ms ± 0%    4.21ms ± 2%    ~     (p=0.286 n=4+5)
GoParse-4                  3.65ms ± 1%    3.64ms ± 3%    ~     (p=0.310 n=5+5)
RegexpMatchEasy0_32-4       113ns ± 3%     113ns ± 4%    ~     (p=0.460 n=5+5)
RegexpMatchEasy0_1K-4       204ns ± 3%     205ns ± 4%    ~     (p=1.000 n=5+5)
RegexpMatchEasy1_32-4      91.3ns ± 2%    91.1ns ± 2%    ~     (p=0.524 n=5+5)
RegexpMatchEasy1_1K-4       386ns ± 5%     381ns ± 1%    ~     (p=0.484 n=5+5)
RegexpMatchMedium_32-4      139ns ± 1%     139ns ± 0%    ~     (p=1.000 n=5+5)
RegexpMatchMedium_1K-4     42.5µs ± 3%    41.9µs ± 0%    ~     (p=0.111 n=5+4)
RegexpMatchHard_32-4       2.26µs ± 8%    2.19µs ± 2%    ~     (p=0.548 n=5+5)
RegexpMatchHard_1K-4       66.3µs ± 1%    66.3µs ± 5%    ~     (p=0.365 n=4+5)
Revcomp-4                   628ms ±28%     580ms ±20%    ~     (p=0.421 n=5+5)
Template-4                 59.2ms ± 1%    59.9ms ± 1%    ~     (p=0.413 n=4+5)
TimeParse-4                 343ns ± 1%     337ns ± 1%    ~     (p=0.063 n=4+5)
TimeFormat-4                348ns ± 0%     349ns ± 0%    ~     (p=0.333 n=4+5)

I'm going to go ahead and push this CL so we can get it out there, but please open a new issue if it causes performance problems for your workload.

Just tried go1.6rc1 and am having zero issues. I'm going to chalk up my issues to some oddity in how I was patching or compiling.
Thanks a ton for your help in getting this all sorted out and fixed.
-T

Thanks to you and @rhysh for all the help debugging!


Remove unnecessary code pertaining to licensing/leasing/etc

What is all this whitelab, turbo, and leased stuff?

  If you are curious:

whitelabel - an option to remove all mentions of the geo company or software name from the admin.  IIRC they were approached by some big company that wanted that option in the past.
leased - they offered leased license for a while.  Think of it like "software as a service" - Where you would pay monthly, it was slightly less than what you would pay if you kept up to date with both downloads access and paid support, but if you stopped paying, it would expire the license and you would be locked out.  Thus "leased".  A few used it but not enough so they stopped offering it to new clients.
Turbo: not sure, I think that was something they added after I left
print: for a while they were working on making a "print ad" edition of the software.  Where you basically used it to keep track of classifieds, but it had no "browsing" built in.  It was meant to export the listings that you would then feed in to your own in-house software for adding them into a newspaper or magazine or whatever.  Not sure if it was ever finished or sold but I am not sure that it was.

What I would do is remove the front end parts that are not used or needed, then look at what was removed, look at the back end and remove the stuff that tries to set it.
When I'm doing a search and destroy like this, I find it helps to keep notes.  Like I make a checklist, if I remove a thing I add it to the checklist.  Once I'm done I go over the checklist items, searching the code for places that still use each one.  If I find one and it turns out it is still needed, I leave it.  If I find another use but that other place maybe is not needed, I add it to the list and keep going.  It involves lots of going over the same items until you either remove all the sub-parts then the thing itself, or you run into a place that needs it to stay so you check it off that way.
Since it is pretty heavy with the old licensing checks, I can take this one over if you want.  I also have access to the original git repo so I can look at the history that might help determine if something is still needed or not.  Just let me know.
Originally posted by @jonyo in https://github.com/geodesicsolutions-community/geocore-community/issues/147#issuecomment-1061806267

See also #92


Support non-consecutive offsets as they might be present in compacted topics

@Astrac thanks for submitting the PR. We have added it into our internal work backlog. We should be able to address it latest by next month.

Hi @Astrac sorry it took us a while. For the change, I think the original condition of consecutive offset have some values in validating non-compacted topics. As such, I would propose to add a config property instead to indicate whether the topic is compacted or not. If the topic is compacted, then we skip the check of consecutive offset. What do you think?

Hi @Astrac, Is this still being worked upon?


Fix comparison against pd.Series

fixes #4596

[x] Tests added / passed
[x] Passes flake8 dask

We switched to using is_series_like in order to support objects that looked like Pandas objects, but were not like cudf or, in some future, arrow.

The underlying issue may be resolved in https://github.com/dask/dask/pull/4533

No, even with #4533 merged the test added in this PR fails. The comment two lines above my change suggests that in this place, a different code path shall be taken for dask Series than for pandas series and similar. But is_series_like evaluates to True both for dask and pandas series, so it doesn't seem suitable here.

Thanks @amerkel2 .  This is in!
Also, I notice that this is your first code contribution to this repository.  Welcome!

Thank you, it's a pleasure!


Add Getting Started page for dart

Add Getting Started page for dart.
The preview failure must be because of missing links. This is being merged to a separate branch

You will also want to add Dart to the Guides shown on the main page (i.e. add it here: src/components/home/Guides.tsx)


Add a DEBUG flag so we can wholly remove code from production build

Not sure if this is something we want to do, but it is something that React does to get their production/minified builds smaller. The idea is that there are certain classes of errors that are really useful while developing, (e.g. build/syntax errors, invalid calls) but that shouldn't happen in production and can thus be turned off to save on size.
This checkin shaves about 150 bytes off of Mithril and paves the way for people more familiar with the codebase to turn off other dev-only features.

Nice feature :+1:

The idea is that there are certain classes of errors that are really useful while developing, (e.g. build/syntax errors, invalid calls) but that shouldn't happen in production and can thus be turned off to save on size.

Yes, they "shouldn't" happen in production, but sometimes they do, and having meaningful error messages helps debug production code.
My opinion:
I'm :-1: with the flag being called DEBUG, but I wouldn't be opposed to it being called something else. To me, having it being called DEBUG imposes the removed of those error messages in production code.

To my mind this is the job of a precompiler to run at deployment according to your own requirements. Javascript AST parsing has become incredibly sophisticated over the past year, to the point where Babylon (Babel's parser) can identify very specific nodes of code and run any number of transformations on them.
Removing descriptive errors can save you a few bytes, but pre-executing m() calls (returning compiled virtual DOM structures rather than having the view recompute the developer-friendly syntax on every redraw) is a likely to be far better for overall preformance. Then again, this would result in a larger payload over the wire. So this is all opinionated stuff which ultimately shouldn't sit in the codebase itself but with external tools, IMO

I use a product that does this via something they call build options. You
can create one or more components that have a set "build option". Then when
you release builds these can be turned on and off.
On Fri, Nov 20, 2015 at 9:23 AM, Barney Carroll<EMAIL_ADDRESS>wrote:

To my mind this is the job of a precompiler to run at deployment according
to your own requirements. Javascript AST parsing has become incredibly
sophisticated over the past year, to the point where Babylon (Babel's
parser) can identify very specific nodes of code and run any number of
transformations on them.
Removing descriptive errors can save you a few bytes, but pre-executing
m() calls (returning compiled virtual DOM structures rather than having the
view recompute the developer-friendly syntax on every redraw) is a likely
to be far better for overall preformance. Then again, this would result in
a larger payload over the wire. So this is all opinionated stuff which
ultimately shouldn't sit in the codebase itself but with external tools, IMO
—
Reply to this email directly or view it on GitHub
https://github.com/lhorie/mithril.js/pull/833#issuecomment-158465339.

but pre-executing m() calls (returning compiled virtual DOM structures rather than having the view recompute the developer-friendly syntax on every redraw) is a likely to be far better for overall preformance.

This has been very successful for us, I wrote mithril-objectify to safely transform m() calls.

^ @tivac sorry I forgot to mention that. IMO that thing is an order of magnitude better than the "pretend it's HTML" trend.
@casajarm could you elaborate on your solution?

@barneycarroll no worries, I'm happy to keep pushing it at everyone until it gains traction :laughing:

Woah. Hey, good feedback everyone.
The idea here isn't so much to get rid of these specific exceptions in production (though I am doing that), so much as to pave the way for doing this sort of thing more extensively. Using React, it has been very helpful to have complex (and moderately expensive) logic while in development-mode that warns me when I'm doing something I shouldn't (calling deprecated methods, passing invalid arguments, etc).
Adding a flag/build option like this allows us to do this sort of thing in Mithril.
@Naddiseo what about 'DEVMODE' instead of 'DEBUG'?

@chrisdavies, the flag name is bike-shedding at this point; the real issue is whether mithril should have flags in the code to enable/disable certain code paths.
After reading @barneycarroll's comment, I've changed my mind, I think there shouldn't be flags littered throughout the code: this is the sort of thing that should be left to precompilers because it's a developer preference issue, not a library issue. Having fine grained flags that can be set as build options may allow each developer the flexibility to build the end product how they wish, instead of having a catch-all DEVMODE/DEBUG flag, but, then you run into the problem of there being too many options.
Using a custom ast transform allows each developer using mithril to be as fine/coarse-grained as they want about what production code is emitted, without having intrusive conditional statements in the code.

BTW was just reading the recently released Babel plugin handbook. This would be an excellent place to find how to build a transformation that could perform this optimisation not just on Mithril, but any bunch of Javascript. babel-transform-no-error-messages?

My 2 cents here... I don't like to have to configure a specific minifier for every project. I always download the uncompressed version in dev and minify/combine myself with common tools when deploying to prod. It would be a shame to have to minify with a specific tool just for mithril to save what, a couple of ifs and a couple of bytes? I prefer well designing my site and put effort on something that would have more impact performance wise.

@mikegleasonjr For what it's worth, precompiling the templates actually increases the size. And this idea would be best implemented in Mithril itself (i.e. two separate versions), not in userland config.
But I'm against merging this until that part's done (and this redone against current next).

@isiahmeadows I am not talking about precompiling, but configuring my local grunt to tell it to remove the DEBUG portions of the code. I don't want to do that. I am not linking to the compressed version either since I combine mithril with something else and I use the latest commit ;). For me, 0.15kb is not worth the effort to have 2 separate versions of the code (dev and prod). Also, throwing errors in prod is good to know exactly what happens. If we don't throw, the lib is in an invalid state anyway and an error will happen anyway down the path and it will be harder to debug.
I am pre-compiling though since the mithril library is so small I like the speed/size trade-off. Again, 1-2kb is nothing compared when my designer tries to put a 150kb hero image in my page.
But again, this is my 2 cents, I will live with it if you decide to include the debug flag, I will just leave it there in prod!

@mikegleasonjr I'm aware. Also, the only compelling reason to me is speed more than memory. Unnecessary conditions can slow things down a lot, although in Mithril's case, I don't think that would be a problem, since none of the assertions are done in hot code paths.

And given my above comment + @mikegleasonjr's comment + the claimed size reduction of only 150 bytes, I don't see any compelling reason to accept this PR. Closing.

Yeah. This PR wasn't about speed nor size for this initial checkin. It was to make a way moving forward for Mithril to begin to have much more robust debugging tools when in dev mode and strip those tools away when in production mode. This is what React does, and it does it in a similar way to the way I did here.

@chrisdavies I know. React kinda needs it more, though, since its dev version doesn't strip its internal assertions, either. Mithril is simple enough that it doesn't need very many of them, and it also relies more on duck typing than React, so it doesn't need type assertions nearly as much. Not saying they don't help, but Mithril is programmed in such a way that most errors are either caught in the unit tests or just outright throw or something similarly obvious (which will soon become a unit test).


[Backport 2.x] Fix Indices Request Cache ITs from flaking and timing out (#14369)

Backporting https://github.com/opensearch-project/OpenSearch/pull/14369 from main to 2.x

❌ Gradle check result for 486f371: FAILURE
Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

Test Result (no failures)


Asset caching using a script does not work

Describe the bug
When trying to use the asset caching tweaking e.g. the instructions from Creating a x-script Asset Caching source for NuGet to my usecase (using a python script), vcpkg fails when trying to execute the script.
On Windows, I just get
Downloading 7zip...
https://github.com/ip7z/7zip/releases/download/23.01/7z2301-extra.7z->C:\tools\vcpkg\downloads\7z2301-extra.7z
error: Failed to download from mirror set
error: Launching <mirror-script>: error: calling CreateProcessW failed with 2 (The system cannot find the file specified.)
linux I get a more verbose output, the relevant part of which:

on Linux the message is slightly more verbose
[DEBUG] 1000: execute_process( "/usr/bin/python3 /builds/team-b/crescendomd/tools/nexus/cache_vcpkg_assets.py https://github.com/catchorg/Catch2/archive/v3.3.2.tar.gz 3d0c5666509a19be54ea0c48a3c8e1c4a951a2d991a7c9f7fe6d326661464538f1ab9dc573b1b2647f49fb6bef45bbd866142a4ce0fba38545ad182b8d55f61f /tools/vcpkg/downloads/catchorg-Catch2-v3.3.2.tar.gz.263.part")
sh: 1: /usr/bin/python3 /builds/team-b/crescendomd/tools/nexus/cache_vcpkg_assets.py https://github.com/catchorg/Catch2/archive/v3.3.2.tar.gz 3d0c5666509a19be54ea0c48a3c8e1c4a951a2d991a7c9f7fe6d326661464538f1ab9dc573b1b2647f49fb6bef45bbd866142a4ce0fba38545ad182b8d55f61f /tools/vcpkg/downloads/catchorg-Catch2-v3.3.2.tar.gz.263.part: not found
[DEBUG] 1000: cmd_execute_and_stream_data() returned 127 after      808 us
error: Failed to download from mirror set
error: <mirror-script> failed with exit code: (127).
sh: 1: /usr/bin/python3 /builds/team-b/crescendomd/tools/nexus/cache_vcpkg_assets.py https://github.com/catchorg/Catch2/archive/v3.3.2.tar.gz 3d0c5666509a19be54ea0c48a3c8e1c4a951a2d991a7c9f7fe6d326661464538f1ab9dc573b1b2647f49fb6bef45bbd866142a4ce0fba38545ad182b8d55f61f /tools/vcpkg/downloads/catchorg-Catch2-v3.3.2.tar.gz.263.part: not found
[DEBUG] /mnt/vss/_work/1/s/src/vcpkg/base/downloads.cpp(1029):

Note that the variable X_VCPKG_ASSET_SOURCES is set to
x-script,C:/Python311/python.exe C:\builds\team-b\crescendomd/tools/nexus/cache_vcpkg_assets.py {url} {sha512} {dst};x-block-origin

As far as I can tell, it seems that vcpkg takes the X_VCPKG_ASSET_SOURCES variable, replaces the placeholders with data and  passes the result directly to CreateProcessW or sh as a single argument. So, e.g., sh  tries looking for an executable called  /usr/bin/python3 /builds/team-b/crescendomd/tools/nexus/cache_vcpkg_assets.py https://github.com/catchorg/Catch2/archive/v3.3.2.tar.gz 3d0c5666509a19be54ea0c48a3c8e1c4a951a2d991a7c9f7fe6d326661464538f1ab9dc573b1b2647f49fb6bef45bbd866142a4ce0fba38545ad182b8d55f61f /tools/vcpkg/downloads/catchorg-Catch2-v3.3.2.tar.gz.263.part instead of looking for /usr/bin/python3 and passing the rest as commandline arguments.
This will obviously fail with file not found error.

I can easily reproduce it on version 2024-01-12. The issue seems to be fixed on master.


Automatically attach uploaded files to model output

Due to the way the API is designed, a file must first be uploaded, then attached to a model output in 2 discrete calls.
We implement this with the methods/CLI:

upload_files (or some variant thereof)
attach_files_to_model_output

This will become tedious once scripted in conjunction with benchcab.
I suggest we add optional arguments to the upload routines to specify a model output that does little more than issue the attach command immediately after the upload.
I'm in discussions with UNSW as to the ramifications of this approach.

Initial implementation, waiting on #42 to incorporate changes across all upload options.


8Muses ripper cuts portion of album name

Ripme version: 1.7.63
Java version: 1.8.0_171
Operating system: Win10 Version 1803
Exact URL you were trying to rip when the problem occurred: https://www.8muses.com/comics/album/Seiren_com_br-Comics/Another-Chance-2/Part-1

Expected Behavior
When downloading albums without the 'Save album titles' option enabled, the album name should be included with the part/issue
Actual Behavior
When downloading the album linked above, the output folder is named 'Part-1-' instead of 'Another-Chance-2---Part-1'
This only happens when the sub folders use the name 'Part-#' instead of the usual 'Issue-#'
For example, when downloading https://www.8muses.com/comics/album/MilfToon-Comics/Mom-Know-Best/Issue-1, the output is named 'Mom-Know-Best---Issue-1 instead of just 'Issue-1'

I can't reproduce this. Ripping https://www.8muses.com/comics/album/Seiren_com_br-Comics/Another-Chance-2/Part-1 puts the images in 8muses_Another_Chance_2_Part_1/Part-1-

When I rip https://www.8muses.com/comics/album/Seiren_com_br-Comics/Another-Chance-2/Part-1 with the 'Save album titles' config option disabled, the images are put in '8muses_Seiren_com_br-Comics\Part-1-' without the 'Another-Chance-2' portion of the album name

It saves a step i guess
When i download frequently updated comics from there with that option is disabled, it just dumps the new pages of the gallery into the parent folder so that i don't have to move and replace files.


add react-toolbox dependency + test-example using it

added react-toolbox as a dependency, and various setup

sample theming + yarn toolbox target for generating style
sample page, to see that it is possible to use the components
unit test, testing the sample page
started some development docs, with reasons for the dependencies in package.json

sweet .Noting that we need to rewrite the toolbar and the current search-autocomplete. #35 , #36


using websockets through port 80 and 443. I can add that for you if you like?

So I noticed that you have a separate web socket server that you fire up using port 8181 and port 8431. (I wasn't able to get wss working but I did get ws working). The firewall has to be opened for this to work.
IIS 7.5 with .net 4.5 allows for web sockets directly through IIS using the default ports. I have done just this in one of my own projects.
I have just started taking a look at RemoteSessionSocketServer to see how it works but if you can give me some pointers that would be great :)

Yes, myrtille do use a custom websocket server (Fleck, open source written in C#) because in 2011, when I added HTML5 support to the product which preceeded myrtille, we were working with Windows Server 2008, IIS 7.0 and .NET 4.0. It was even working on Windows Server 2003, but when I upgraded from VS2010 to VS2015 lately, the MS VC++ 2015 redistributables refused to work under this OS...
Even if Fleck works very well, it's a good idea to use the native IIS 7.5+ features (and don't have to open ports on the firewall), so yes I would be glad to receive some help on that matter.
RemoteSessionSocketServer.cs is the actual myrtille websocket server implementation; it's used to received the client (browser) inputs (keyboard, mouse and touchscreen events) and pass them to the RemoteSessionManager.cs class (which, in turn, pass them to the rdp client (freerdp) through named pipes). The display updates are received by RemoteSessionManager.cs from the rdp client (also through named pipes) then sent to the client using the same, duplex, websocket (as the one used for inputs reception).
I didn't worked with IIS websockets but it would be basically the same logic (without the RemoteSessionSocketServer.cs class).
To get the wss working actually, if the port 8431 is opened, you have to check if you have an SSL certificate defined for the web application and a .pfx file (exported from the certificate) under the myrtille "ssl" folder. This is normally automatically done by the installer in the latest version (1.0.6, with a self signed certificate). You also have to access the myrtille homepage with "https://" instead of "http://".

I've started creating a myrtille.mvc project that supports web api. First I am going to replicate your default.aspx page using mvc and fleck and then I will replace the fleck server.
I'm currently away for a wedding and will be back on Tuesday to start coding. :)
Troy

On Jul 28, 2016, at 1:51 AM, cedrozor<EMAIL_ADDRESS>wrote:
Yes, myrtille do use a custom websocket server (Fleck, open source written in C#) because in 2011, when I added HTML5 support to the product which preceeded myrtille, we were working with Windows Server 2008, IIS 7.0 and .NET 4.0. It was even working on Windows Server 2003, but when I upgraded from VS2010 to VS2015 lately, the MS VC++ 2015 redistributables refused to work under this OS...
Even if Fleck works very well, it's a good idea to use the native IIS 7.5+ features (and don't have to open ports on the firewall), so yes I would be glad to receive some help on that matter.
RemoteSessionSocketServer.cs is the actual myrtille websocket server implementation; it's used to received the client (browser) inputs (keyboard, mouse and touchscreen events) and pass them to the RemoteSessionManager.cs class (which, in turn, pass them to the rdp client (freerdp) through named pipes). The display updates are received by RemoteSessionManager.cs from the rdp client (also through named pipes) then sent to the client using the same, duplex, websocket (as the one used for inputs reception).
I didn't worked with IIS websockets but it would be basically the same logic (without the RemoteSessionSocketServer.cs class).
To get the wss working actually, if the port 8431 is opened, you have to check if you have an SSL certificate defined for the web application and a .pfx file (exported from the certificate) under the myrtille "ssl" folder. This is normally automatically done by the installer in the latest version (1.0.6, with a self signed certificate). You also have to access the myrtille homepage with "https://" instead of "http://".
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Thanks for your help :)


Use WiX makable release candidate version

Wix using package version should be modified into buildable version number.
This is one of the possible prerelease version implementation.
Signed-off-by: Hiroshi Hatake<EMAIL_ADDRESS>

By the way, do we need to assume rc and public release in the same day? or multiple releases in the same day) if so, Time.now.strftime("%m%d") may not be appropriate...

By the way, do we need to assume rc and public release in the same day? thus multiple releases in the same day) if so, Time.now.strftime("%m%d") may not be appropriate...

If release candidate and release package in the same day(2020/06/28), 4.0.0~rc1 should be interpreted as <IP_ADDRESS>8 for release candidate version and release version should be remove ~rc1. Then,4.0.0 is used for released package version number. Conflicts between prerelease version and rc version does not occur.


Build(deps-dev): Bump @babel/core from 7.18.10 to 7.18.13 (#3926)

Pull request opened by the merge tool on behalf of #3926

Merged in e521ce3822fac9467f2b5b8ab3caffc4a2f14019