Please invite me to the GitHub Community Organization

Name
Noval Ramdhani
Discord Username (if applicable)
No response
Additional Context
Web programming enthusiast

Check your email or organisation page
Thank you for contribution 🙂
Please contribute in Unique-Github-Profiles


how can  k-means compiled successfully?

There is atomicMin(float *, float) call in k-means，but cuda is not implement this form function，so, why k-means can compiled successfully?

sorry,my fault,thers has an implemention in your code.


Mirror issue: Enable JL plugin for integrating with Git repo

https://issues.redhat.com/browse/RHODS-314

Link to git extension: https://github.com/jupyterlab/jupyterlab-git. Based on the issue's description, I don't see any Elyra specific actions that we need to take. Elyra distributes the git extension but does not own it. Please clarify what the ask is.


Issue with VB.NET

The package can be installe within a VB.NET project and it inserts a C# file which does not work at all.

If anyone comes across this on Google for help with VB.NET.

Create a SwaggerConfig.vb class file in the App_Start of your Web API project
Modify the file as such

Imports System.Web.Http
Imports WebActivatorEx
Imports Swashbuckle.Application
<Assembly: PreApplicationStartMethod(GetType(SwaggerConfig), "Register")>

Public Class SwaggerConfig
    Public Shared Sub Register()
        Dim thisAssembly = GetType(SwaggerConfig).Assembly

        GlobalConfiguration.Configuration.EnableSwagger(Function(c) c.SingleApiVersion("v1", "Your API Name")).EnableSwaggerUi()
    End Sub

End Class

This is the bare minimum. You can follow the annotations in the SwaggerConfig.cs file as well as the readme for any additional options you may want to configure.

I've added that file to my project, however I am getting this error:
Method not found: 'Swashbuckle.Application.SwaggerEnabledConfiguration Swashbuckle.Application.HttpConfigurationExtensions.EnableSwagger(System.Web.Http.HttpConfiguration, System.Action`1<Swashbuckle.Application.SwaggerDocsConfig>)'.
I'm referencing this this library version: Swashbuckle.Core.5.0.0\lib\net40\Swashbuckle.Core.dll
Any Ideas?

Please just detect language and place this file renamed to .vb in project instead of the cs file.
SwaggerConfig.txt


AppleScript actions should know about all the types used internally by ObjC actions

Not sure if the title is clear—basically, I would like the "on get (in)direct types" handlers in AppleScript actions to be able to return strings corresponding to any type QS knows, not just a few specifically made available to AppleScript. I would greatly appreciate a "Get QS Types" action that could be run on an object and would return the relevant types to QS, as well.
The use case here is writing AppleScript actions with extremely specific requirements for their parameters, and allowing the user to drag them high up in the priority list without affecting stuff that they don't actually apply to. There are a number of types this makes sense for, such that it makes more sense IMO to do it generically.

Sorry, hadn't noticed you asked me to file a issue. Now filed as #2199.


Not updating data

I have a problem with updating data. I've try to install every version. The query doesn't work well. It's not updating automatically. Several times a day I have to switch the query button manually and even then it's not updating every time. I'm using the WiFi ecu-r variant. First half of 2023 it al worked fine...

How often do you query the ECU? Is it being queried by one instance of HA? Try a powercycle. You could use an automation to enable the query button again.  Does it help when you position the ECU somewhere else in the room? Did you check the zigbee signal data?

I have the same problem. ECU-R 2160. When I reinstalled the integration it updated a few times but after some time I get the following error:
This error originated from a custom integration.
Logger: custom_components.apsystems_ecur
Source: custom_components/apsystems_ecur/init.py:58
Integration: APSystems PV solar ECU (documentation, issues)
First occurred: 22 January 2024 at 13:10:24 (2 occurrences)
Last logged: 14:37:01
Communication with the ECU failed after 5 repeated attempts.
I used the integration for a year without any problems. Is there a fix for this?

I have running an automation that set the query on every hour. But it's stil strange..

@smidtd It is difficult to anticipate the changing status of different ECUs and their firmware updates. If your ECU has a webui despite the fact that it starts with ID 2160, you can try to see if the software reset works. On line 62 of init.py you will find if (self.cached_data.get("ecu_id", None)[0:3] == "215") or (self.cached_data.get("ecu_id", None)[0 :4] == "2162"): This line checks which type of ECU can apply to the software reset. If you change 2162 at the end of the line to 2160 (and HA restart), the reset procedure is used. This means the ECU will not suffer less from outages, but the ECU will reboot automatically.

@HAEdwin : I have access to the Ecu WiFi (ECU_R_###). How can I test if my ECU has a webui? I tried to connect to it's local IP (<IP_ADDRESS>) but no reply. Does it need a certain port to connect to?
I did get the ECU Manager app to work. In the app was no option for a software reset.

http://x.x.x.x/index.php/hidden
If you are able to reach this page you have an ECU-R pro. What ECU firmware version is installed? Was there a change in you local network configuration (firewall, DHCP)? Do not block the EMA url's, this cause the ECU to stop working.

I don't have the webui so no ECU-R pro. ECU firmware is ECU_R_1.2.27.
No changes in network config (firewall or DHCP).
The ECU Query just stops somewhere during the day. When I switch it back on manually everything works again.
I will build an automation that will trigger the switch after "Device off".
I really like this HACS integration so it would be perfect if another solution would be found.
Thanks @HAEdwin for your replies!
1 February 2024
ECU Query Device turned on triggered by service Switch: Turn on
09:26:18 - 1 hour ago - DdS
31 January 2024
ECU Query Device turned off
17:13:44 - 17 hours ago
ECU Query Device turned on triggered by service Switch: Turn on
16:43:25 - 18 hours ago - DdS
ECU Query Device turned off
14:37:39 - 20 hours ago
ECU Query Device turned on triggered by service Switch: Turn on
12:25:56 - 22 hours ago - DdS

No problem @smidtd
I have the same ECU-R and firmware. It is normal if you are unable to execute the query on the ECU once in a while. After all, the ECU also does IO with the EMA site every 5 minutes and due to timing changes they can meet each other. The integration anticipates this by accessing the cache and trying again in five minutes. However, if it does not work (consecutively) after the set number of attempts, the ECU Query switch flips so that an automation can respond to this by, for example, controlling a smart plug and power cycling the ECU. The placement of the ECU is important, sometimes it helps to move the ECU.
From the start we encountered failing queries and we managed to limit them as much as possible. Each attempt such as re-query after failure led to greater unavailability. Ultimately, using the cache turned out to be the best option and anticipates on all ECU models.
My ECU is placed in the middle between the two small PV panelarrays." It's not very common that I get query errors. Closest accesspoint is 5 meters away, inverters are at 8 meters away from the ECU.

Thanks for the explanation @HAEdwin. That gives a lot more insight.
I've now added an automation to switch back on the query. Let's see what that does for the next days/weeks.
Have a great weekend!

I checked today and with an automation it's working!


Key generation and signer interface

Much like the go counterpart in sigstore/sigstore, implement key generation and a signer interface. This should provide the following:

Generate of a key pair using a provided alg (rsa, ecdsa)
public key derive from private key
Signing interface
Serialisation (handle PEM / DER en/decode etc).

Will keep this open to track Ed25519 and RSA modules

[ ] ecdsa
[ ] Ed25519
[ ] RSA

Many thank @Xynnn007 for taking this on!

@lukehinds Hi, ed25519 has been supported in https://github.com/sigstore/sigstore-rs/pull/87/commits/8314f8f7867e0e80c2e2ca0470a6897f859ae93c

Just going to add one more @Xynnn007 , some examples (for users) would be very useful. See examples in the root folder.

Also, now CosignVerificationKey has the similar semantics with the SigStoreSigner's public key. I'd prefer to add the following for ease

Into trait for SigStoreSigner or KeyPair
From trait for CosignVerificationKey

sounds good @Xynnn007

There might be some refactoring for the key_interface, to deal with the following problems:

Now when users use the signing_key module, they must import the crates into the Cargo.toml, like p256, p384, etc. I'd prefer users do not need to care about the underlying Elliptic Curves. They can directly use sigstore crate without import any other crates to do all the key related operations, thus we need to do some wrapping.
Now we do not have a convenient call routine for a user to import a private key and convert it into a SigStoreSigner. Also SigStoreSigner is somehow overlapped functionally with Signer trait object. I'd like to combine them, and give a more easy way for users to convert a PEM/DER encoded private key into an object who can sign.

@Xynnn007 Strongly agree about not having users import extra crates, thank you!

Yea, in a sense CosignVerificationKey struct has the same issue that when use this we need to import ring crate. How about refactor it into an enum, the enum values will be the same as crypto::signing_key::SigningScheme, s.t.
pub enum SigningScheme {
    // TODO: RSA schemes
    ECDSA_P256_SHA256_ASN1,
    ECDSA_P384_SHA384_ASN1,
    ED25519,
}

Now the interface looks like the following:
use ring::signature;
use sigstore::crypto::verification_key::CosignVerificationKey;

CosignVerificationKey::from_der(der_data: &[u8], verification_algorithm: &'static dyn signature::VerificationAlgorithm);
CosignVerificationKey::from_pem(pem_data: &[u8], signature_digest_algorithm: SignatureDigestAlgorithm);

I prefer to change it into the following:
use sigstore::crypto::verification_key::CosignVerificationKeyWrapper;

CosignVerificationKeyWrapper::ECDSA_P256_SHA256_ASN1.from_der(der_data: &[u8]);
CosignVerificationKeyWrapper::ECDSA_P256_SHA256_ASN1.from_pem(pem_data: &[u8]);

Avoid import ring crate.
Certainly the CosignVerificationKeyWrapper can be other names, like VerificationKey for short.
How do you think about this? @lukehinds @flavio @lkatalin

I used ring back in the days because there was no native support of p384 inside of "RustCrypto ecosystem". This recently changed, hence I'm fine dropping ring support.
As for the proposed API change, I like end users to not worry about which format the key they are importing might be. They just need to know if the data is encoded using PEM or not, and then call CosignVerificationKey::from_pem or CosignVerificationKey::from_der.
You are not proposing to drop CosignVerificationKey and this API, are you?

As for the proposed API change, I like end users to not worry about which format the key they are importing might be. They just need to know if the data is encoded using PEM or not, and then call CosignVerificationKey::from_pem or CosignVerificationKey::from_der.

Partially agree with that.
What a user may use about CosignVerificationKey is from_pem/der() and key.verify(). The two interfaces do not care about the key type.
But as the name CosignVerificationKey shows, this may be something like a public key. And that
public key + digest algorithm + other parameters (like padding alg in RSA-based signing)= Verifier
Here Verifier can have an API verify(sig).

You are not proposing to drop CosignVerificationKey and this API, are you?

I'm not proposing to drop the function of CosignVerificationKey. It is very useful, but need some refactoring. IMO there may be three layers for the verification key abstraction:

InnerPublicKey struct of different type of keys, implemented by generic type.
PublicKey enum that wraps different kinds of public keys : with from_pem/der, to_pem/der API. These API's matches what you've recommended no signing schemes are involved. And they may also have API like try_to_ed25519_verifier(), try_to_ecdsa_verifier(digest_alg),try_to_rsa_verifier(padding, digest_alg)
SigStoreVerifier: enum wraps PublicKey and concrete signing scheme inside. It may have APIs like from_ed25519_public_key(key), from_rsa_public_key(key, padding, digest_alg), from_ecdsa_public_key(key, digest_alg)

The first layer abstraction is to use generic RustCrypto ecosystem of ecdsa.
The second layer abstraction is to avoid import other crates.
The third layer abstraction is to overcome the gap from public key to a specific signing algorithm public key, such as rsa public key -> rsa public key + Sha256 + PKCS1.5 padding
If we agree here, I'd like to do the changes of this function, including drop ring and use RustCrypto ecosystem as you've mentioned, because it is related to signing_key module closely.

Without having delved into the existing code too deeply, I think this makes sense in terms of the APIs and separation between PublicKey vs. Verifier. Can you say more about why the InnerPublicKey struct is necessary? Could whatever that is doing be done with a trait on the PublicKey instead? I would assume the key types themselves are defined somewhere in RustCrypto so we don't need to re-implement them(?) but I have mostly worked with the openssl crate so I'm not sure what's different.

Can you say more about why the InnerPublicKey struct is necessary? Could whatever that is doing be done with a trait on the PublicKey instead? I would assume the key types themselves are defined somewhere in RustCrypto so we don't need to re-implement them(?) but I have mostly worked with the openssl crate so I'm not sure what's different.

The RustCrypto is implemented highly generic. Take ecdsa's VerificationKey for example, it only defines the abstract interfaces with generic parameter, and the concrete implementation is in the crates like p256, p384. I tried to find the defined key types as you'd mentioned, but unfortunately failed.
Back to the reason of InnerPublicKey. There are two:

Avoid duplicated ecdsa key enum.
Different function implementing PublicKey -> Verifier has different parameters.

Let me clarify:
Avoid duplicated ecdsa key enum
The public key used to verify a signature in ecdsa is defined as ecdsa::VerifyingKey<C> in RustCrypto and here C is a generic parameter for different curves.
If we use a PublicKey to directly warp it, it will look like
// case 1
enum PublicKey {
    EcdsaP256(ecdsa::VerifyingKey<p256::NistP256>)
    EcdsaP384(ecdsa::VerifyingKey<p384::NistP384>)
   //...
}

Rather than the following that using a generic parameter
enum PublicKey {
    // Here should be named as Ec, for it is only a key
    Ecdsa(ecdsa::VerifyingKey<C>)
   //...
}

Because any definition with generic parameter is decided when compiled, and we need to add extra crates when coding.
Maybe we prefer something like
enum PublicKey {
    Ecdsa(...)
    Ed25519(...)
    Rsa(...)
   //...
}

Besides, if there more curves, it may seem redundant, like when we implement to_verifier function like
impl PublicKey {
    pub fn to_verifier(&self, ...) -> Result<Verifier> {
        match self {
            EcdsaP256PublicKey(inner) => inner.to_verifier(...),
            EcdsaP384PublicKey(inner) => inner.to_verifier(...),
            EcdsaK256PublicKey(inner) => inner.to_verifier(...),
        }
    }
}

the XXX(inner) => XXX is all same for the same type of public key.
Different function implementing PublicKey -> Verifier has different parameters.
This is the most important reason. If we use InnerPublicKey to wrap, it may look like
pub enum InnerEcdsaPublickey {
    P256(ecdsa::VerifyingKey<p256::NistP256>),
    P384(ecdsa::VerifyingKey<p384::NistP384>),
...
}

And for InnerEcdsaPublickey, we can define to_verifier(&self, digest: SignatureDigestAlgorithm)
For InnerRsaPublickey,  to_verifier(&self, digest: SignatureDigestAlgorithm, padding: PaddingScheme)
They are functions with different parameters.
If we do not use InnerPublicKey but directly use PublicKey enum to wrap them, like the following
enum PublicKey {
    EcdsaP256(..),
    Rsa(..)
   //...
}

The function to_verifier(&self, ...) is hard to define. May look like this
fn to_verifier(&self, Option<SignatureDigestAlgorithm>, Option<PaddingScheme>) {
    match self {
        EcdsaP256 => // use SignatureDigestAlgorithm,
        Rsa=> // use SignatureDigestAlgorithm and PaddingScheme,
    }
}

I am afraid that this looks not good.

I'm not proposing to drop the function of CosignVerificationKey. It is very useful, but need some refactoring. IMO there may be three layers for the verification key abstraction:
[...]
If we agree here, I'd like to do the changes of this function, including drop ring and use RustCrypto ecosystem as you've mentioned, because it is related to signing_key module closely.

Fine with me. I'm happy to remove the ring dependency. Let's just ensure the final refactoring will not degrade the developer experience for the consumers of the crate (translated: let's not require them to have a major on crypto algorithms).

@Xynnn007 Thanks for the detailed explanation. I see the problem you point out with the different number of parameters to turn the different key types into a Verifier. What you propose sounds fine as far as I can tell, especially if the names of the wrappers, etc., are clear and short.

Fine with me. I'm happy to remove the ring dependency. Let's just ensure the final refactoring will not degrade the developer experience for the consumers of the crate (translated: let's not require them to have a major on crypto algorithms).

What I wanted might degrade the developer experience in a sense. Let me firstly propose a new pr to remove ring first, while keeping the original API as possible. Then we can do further refactoring if needed.


Testdir Collision for rstest Parametrized Tests

If you crate is used together with rstest's parametrized tests feature, the directory created by testdir!() in one parametrized test function collides with the one created in a different parametrized test function.
Expected Behaviour
I would expect that the PathBuf returned by testdir!() is always unique and new, and never collides with one created in a different testing function.
Actual Behaviour
If two rstest test function have multiple cases, rstest names the test cases func1::case1, func1::case2 for test function func1, and fun2::case1, func2::case2 for the second one. Tempdir thinks that case1, case2 are the names of the test functions, which are however not unique in a module. This leads to a reuse of the test dir.
Reproduce
Run the unit tests in the following MVE (requires rstest) using cargo test -- --nocapture.
#[cfg(test)]
mod tests {
    use rstest::{fixture, rstest};
    use std::path::PathBuf;
    use testdir::testdir;

    #[rstest]
    #[case(1)]
    #[case(2)]
    #[case(3)]
    fn test_1(#[case] _num: u8) {
        let out = testdir!();
        println!("Creating new tmp_dir {}", out.display());
    }

    #[rstest]
    #[case(1)]
    #[case(2)]
    #[case(3)]
    fn test_2(#[case] _num: u8) {
        let out = testdir!();
        println!("Creating new tmp_dir {}", out.display());
    }
}

I understand that this issue is related to the interplay of your crate with another one. But since rstest is rather popular, it would be great if both would play well together.
Having had a quick lock at the code, it seems like the crate::private::extract_test_name would need to be improved and return testfunc::caseN instead of just caseN for parametrized tests.
What do you think?

Thanks for the detailed report!  Your analysis sounds right, the heuristics to construct the tests names are somewhat difficult and can be messed up by extenstions to basic libtest usage.
I agree rstest support would be nice to add.


About the evaluation

We found some bugs in convlab/evaluator/multiwoz.py. So is the code used in automatic evaluation the same as convlab/evaluator/multiwoz.py? If the code is different, did you fix the bugs such as the bug in issue 79.

@DarrenZhu1103 Could you tell us the bugs you found?

We found that some of the mistakes are due to the "?" in the database. Although you change the line 214 in convlab/evaluator/multiwoz.py, the nlu module of user could not recognize ? in the sentence. And did you check if any submissions replaced the ? with other strings before system output sys_output in the automatic evaluation? In human evaluation, will ? impact the users' experience?

Automatic evaluation just provides some reference for the system performance since 1) we cannot get a perfect NLU model to extract the slot values system expresses and 2) it is difficult to judge if the informed values are correct or are the ones that the user actually wants due to abbreviation, synonym, typos, etc.
The _check_value function in convlab/evaluator/multiwoz.py works well in most cases, though not in all cases. We would not check all the submissions about how they replace "?" with other strings because it is a laborious process.
In human evaluation, the system will be interacted with real users using natural language, and the final ranking will depend on the results of human evaluation.


Fix typo: Expect → Expat

Just what it says in the title :)

Implemented.

Implemented.

For future reference, that was done in commit 7955bfb1affcc752c60eac1a4621feeb0f31ab68.


The notify() function in a WSL environment

Hello,
I'm in a WSL2 environment under Windows 11 in order to launch my Castor commands and with the Castor.PHAR archive for Windows (since it's this one to take even for WSL). I just tried your notification function but it doesn't trigger any notification.
I have checked my notifications options btw, and everything is properly configured. I wonder the reason behind this : is this a WSL related issue which can't communicate properly with Windows ?
#[AsTask(description: 'Suppression des volumes, conteneurs et réseaux créés pour le projet')]
function clean(bool $force = false)
{
    notify('The infrastructure has been destroyed.');
}

Hi,
I had to do a wsl --list --verbose for this (wsl --version just doesn't work and display the wsl help) :

I'm on WSL 2.

Hi,
I had to do a wsl --list --verbose for this (wsl --version just doesn't work and display the wsl help) :

I'm on WSL 2.
[EDIT] Don't pay attention to the docker-data which is stopped, It is usually on and was on during the notification test.

Strange, you have an older version of WSL, I think.
When did you install it, and did you update it? (wsl --update)
Can you attempt to run wsl --status ?
Which distribution do you use? Windows 10 or 11 ?

I'm using Windows 11. It's a professionnal computer delivered by my company in which I have limited rights. But you yeah, you have probably right : my system seems to not be up to date.

I have just few seconds ago activated the necessary additionnal options in Windows Update (as described on the provided screenshot) and I'm waiting for the update to complete. This will probably resolve the issue. I was sure that WSL was already managed by Windows Update, but this is not the case and probably the reason behind this notification command not working.
When done, i'll reply to this thread in order to close it or give your more details about the issue.

Well, wsl 2 is now fully updated, but the notification just doesn't appear when the function is launched. Because I'm on a locked system (limited Windows privileges), I don't if I have to close the ticket or if you would like to investigate further. Maybe the issue is not related to these system limitations and a real issue could really exists in the base code, but maybe not.

Ok good to known, you have been updated to latest and higher Windows version 😄
(10.0.x is OK for W11)
But the strange thing is that on my professional PC I have no problem running notify whatever the executable (Windows or Linux phar/binary).
Except that on my personal PC it doesn't work, and all versions are up-to-date except Windows.
I got an error about the missing sonartoast. But it appeared once and then disappeared.
Now, castor plays the script without errors, but no notification is displayed 😞
What is your use case compared to mine?
Test script:

Error throwed with linux phar/binary (only one time):

When using Windows phar/binary:
Nothing appear (no throw, no notification on Windows)

@lyrixx, @pyrech Did you have any confirmation that the use of Windows phar fix notifications internally at your company ?

I (We) don't use Windows :/


Cannot use AddApiExplorer in minimal API .NET 6

Hi,
I've installed Asp.Versioning.Http preview-3 nuget package and I want to version api and add support for swagger.
I'm trying to inspire from https://github.com/dotnet/aspnet-api-versioning/blob/main/examples/AspNetCore/WebApi/MinimalOpenApiExample/Program.cs but seems that I have error AddApiExplorer does not exist.
var builder = WebApplication.CreateBuilder(args);
var services = builder.Services;

services.AddEndpointsApiExplorer();
services.AddApiVersioning(opts =>
{
    opts.ReportApiVersions = true;
    opts.AssumeDefaultVersionWhenUnspecified = true;
    opts.DefaultApiVersion = ApiVersioningUtils.ApiV1;
    opts.ApiVersionReader = new UrlSegmentApiVersionReader();
}).AddApiExplorer(...);

services.AddSwaggerGen(...);

var app = builder.Build();
app.NewApiVersionSet()
                .HasApiVersions(new[] { ApiV1, ApiV2 })
                .ReportApiVersions()
                .Build();

where ApiV1 and ApiV2:
public static readonly ApiVersion ApiV1 = new ApiVersion(1);
public static readonly ApiVersion ApiV2 = new ApiVersion(2);

There's another nuget to be installed in order to access AddApiExplorer ?

Found by adding another package called Asp.Versioning.OData.ApiExplorer

Only API Explorer for minimal API and support for swagger


Backend Folder Layout

closes #4

Updated Readme for Server Folder
Added Folder Layout with a basic example for Server

LGTM


Track which device file was the basis of an interview and flag devices with outdated interviews

Hash the device file used during a device interview and compare the hash value of current device files at startup. Also export a function so that UIs can call this function after device files are pulled (zjs2mqtt). Flag devices with outdated interviews so that UIs can display a reinterview flag or prompt on the device.
Per prior conversations, we don't want to automatically reinterview because a device could be a battery device or there could be an issue, and all information about a device is lost after triggering a reinterview.

and all information about a device is lost after triggering a reinterview.

That's been fixed?

No, it's lost in the driver. We dump the info when you start an interview.


Describe VRPLIB format

This PR:

[x] Is part of #384.
[ ] Adds and passes relevant tests.
[x] Has well-formatted code and documentation.

Notes:

It is essential that you add a test when making code changes.
This keeps the code coverage level up, and helps ensure the changes work as intended.
When fixing a bug, you must add a test that would produce the bug in the master branch, and then show that it is fixed with the new code.
New code additions must be well formatted. Changes should pass the pre-commit workflow, which you can set up locally using pre-commit.
Docstring additions must render correctly, including escapes and LaTeX.

@leonlan could you have a look at this? I'm not sure if we should say more, and what's really part of PyVRP vs VRPLIB. I'm mostly going for at least an overview of relevant fields for now.

I'll make an attempt to standardize the VRPLIB format when we have more support for heterogeneous fleet, multi-depot, etc.

That's the main reason I'm adding this page now. It's not too bad yet - we only have a few nonstandard fields now - but I suspect we'll need more soon and then it gets messy quick if we don't have a good description of the format somewhere.


agdaPackages.cubical: 0.3pred5030a9 -> 0.3post9bedca9

Motivation for this change
Our current version of cubical is from July 2021, lots of things have happened since then. This pull request updates to upstream HEAD.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Can you rebase since https://github.com/NixOS/nixpkgs/pull/147061 is merged?

I'm not sure what the pred and post in the version name mean.

The post postfix was a misnomer, since corrected.
The prexxxxxxx indicates that version 0.4 has not yet been released and that we are referencing the pre-release version with the specified Git commit. I just copied what we had before :-)
In a couple minutes I'll force-push a new commit, rebased to current nixpkgs master and targeting the lastest cubical HEAD.


MTV-1343 | Add pprof to the controller

Profiling guide:
# Forward the pods profiling port
oc port-forward -n konveyor-forklift pods/forklift-controller-5c99c54dd8-77blm 6060:6060

# Get running goroutines and heap
go tool pprof -http=:9001 localhost:6060/debug/pprof/goroutine
go tool pprof -http=:9002 localhost:6060/debug/pprof/heap

# Get trace over 5s
curl -k http://localhost:6060/debug/pprof/trace\?debug\=1\&seconds\=5 -o cpu-trace.out
go tool trace -http=:9003 ./cpu-trace.out

# List all routines
curl -k -o stage.out http://localhost:6060/debug/pprof/goroutine\?debug\=1

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 16.36%. Comparing base (f08a3a9) to head (af76bef).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1018   +/-   ##
=======================================
  Coverage   16.36%   16.36%
=======================================
  Files         109      109
  Lines       19628    19628
=======================================
  Hits         3212     3212
  Misses      16135    16135
  Partials      281      281

Flag
Coverage Δ

unittests
16.36% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

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


update proxy of 7.0 to tikv master (f0af6ff1f5)

What problem does this PR solve?
Issue Number: close #xxx
Problem Summary:
Split into 2 stages:

merge b82036eae
merge f0af6ff1f5

What is changed and how it works?
Check List
Tests

[ ] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Documentation

[ ] Affects user behaviors
[ ] Contains syntax changes
[ ] Contains variable changes
[ ] Contains experimental features
[ ] Changes MySQL compatibility

Release note

None

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.12 out of 28 committers have signed the CLA.:white_check_mark: Leavrth:white_check_mark: SpadeA-Tang:white_check_mark: fengou1:white_check_mark: joccau:white_check_mark: wshwsh12:white_check_mark: ekexium:white_check_mark: zeminzhou:white_check_mark: LittleFall:white_check_mark: lijie0123:white_check_mark: CalvinNeo:white_check_mark: xuyifangreeneyes:white_check_mark: glorv:x: BusyJay:x: YuJuncen:x: Connor1996:x: nathan-edgar:x: tonyxuqqi:x: 3pointer:x: JmPotato:x: tabokie:x: LykxSassinator:x: pingyu:x: sticnarf:x: v01dstar:x: bufferflies:x: innerr:x: woofyzhao:x: overvenusYou have signed the CLA already but the status is still pending? Let us recheck it.


fix "Inherits all Viewport/View methods"

Background
I could be confused, but OrthographicView is a subclass of View, rather than of Viewport, and the link points to View, too.
Change List

s/Viewport/View/

Thanks


Release prep for 0.6

@bakura10 (only when you time) could you please have a quick peek at these changes  https://github.com/juriansluiman/SlmQueue/pull/182/commits/c210d79b87eefdf2db04e98880e263d9052eb63b
make sense to you?


test: improve coverage

by a small bit

Codecov Report

Merging #38 into master will increase coverage by 0.33%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master     #38      +/-   ##
=========================================
+ Coverage   90.57%   90.9%   +0.33%
=========================================
  Files           1       1
  Lines         297     297
=========================================
+ Hits          269     270       +1
+ Misses         28      27       -1

Impacted Files
Coverage Δ

sdp.js
90.9% <0%> (+0.33%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5462f6d...daf1a08. Read the comment docs.


No node found: Error when setting up from README

Copied the code from the README but when attempting to execute with the require("logsitter").log() function it gives the following error no matter the filetype. Attempted js and lua files.
E5108: Error executing lua: .../pack/packer/start/logsitter.nvim/lua/logsitter/init.lua:88: Vim(echoerr):No node found

stack traceback:
        [C]: in function 'cmd'
        .../pack/packer/start/logsitter.nvim/lua/logsitter/init.lua:88: in function 'log'
        [string "..."]: in function <[string "..."]:0>

Scratch that, I'm dumb and forgot to install the javascript for treesitter with :TSInstall javascript

Might be nice to have a dummy check and nicer error if this comes up.


Categorical generators cannot be created by factories

The method getValue(P) cannot be found by reflection. It has to be implemented in child classes of CategoricalGenerator class.

Fixed.


Fixes typos, word issues in Basic JS, part 2

Touches:
Store Multiple Values in one Variable using JavaScript Arrays
Access Array Data with Indexes
Modify Array Data With Indexes
Manipulate Arrays With pop()
Manipulate Arrays With push()
Manipulate Arrays With shift()
Manipulate Arrays With unshift()
Write Reusable JavaScript with Functions

Rebased and resolved conflicts.


SyntaxError: Unexpected token in JSON at position 23851

Environment data

VS Code version: 1.39.2
Extension version (available under the Extensions sidebar): 2019.10.44104
OS and version: MS Windows 10
Python version (& distribution if applicable, e.g. Anaconda): 3.7.4
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): miniconda
Relevant/affected Python packages and their versions: pytest
Jedi or Language Server? (i.e. what is "python.jediEnabled" set to; more info #3977): N/A

Expected behaviour
Discover all unit tests correctly with no problems as long as pythonFiles/testing_tools/run_adapter.py returns the correct JSON data
Actual behaviour
While discovering, the loading machinery instantiates some dynamic libraries (DLLs) that output to the standard output. Apparently, run_adapter.py tries to capture all the output as the JSON object rather than the relevant return from pytest.
Steps to reproduce:

Create a C/C++ DLL that writes to stdout on load
Create a Python SWIG wrapper for that DLL
Write a pytest unittest that uses the SWIG wrapper
Test discovery fails

Logs
Output for Python Test Log in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python Test log)
python c:\<private path>\ms-python.python-2019.10.44104\pythonFiles\testing_tools\run_adapter.py discover pytest -- -s -n 4 <private project>
Test Discovery failed:
SyntaxError: Unexpected token E in JSON at position 23851

Duplicate of #6594


Configure renovate so that it should be able to pick up pre-commit

pre-commit support is at the moment only in beta test for renovate so it has to be enabled manually in the config for renovate. I'll do that separately.
https://docs.renovatebot.com/modules/manager/pre-commit/

Turns out renovate does not support digest updating for pre-commit yet: https://github.com/renovatebot/renovate/issues/22567


Fix object does not exist error when checking citation file

Fix #28264
DataAsync() will be called twice.
Caused by https://github.com/go-gitea/gitea/pull/27958.
I'm sorry, I didn't completely remove all unnecessary codes.

Do we need to move break in to the if above which has been done in https://github.com/go-gitea/gitea/pull/28314/commits/05d9cff28812f5bce00b700bfab70cac16c6c480?


[Refactor] Rename LocalSettings to LocalOptions

Purpose

Rename LocalSettings to LocalOptions

Does this introduce a breaking change?

[ ] Yes
[ x ] No

Pull Request Type
What kind of change does this Pull Request introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ x ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

What to Check
Verify that the following are valid

All unit test and UI test passing, app remains functional

Other Information

Do we have to update repo docs as well?

Looks good. Are you doing separate PR for repo doc updates?

Yes, because there's lots of renaming/refactoring happening, will update the doc and changelog in separate PR before the beta release


Added a bower description file

Added an bower.json file so that you can release it to the bower package manager.
To release a version, merge the pull request, and tag a branch as described here.

Awesome, thanks! It's now published :)


Using get_polygon() and attempting to access elements of the array causes crash. extends Polygon2D

Godot version
4.0.stable.official.92bee43ad
System information
Mac
Issue description
@tool
extends Polygon2D

func _draw():
	var poly = get_polygon()
	if not len(poly):
		return

	for i in range(1, poly.size() - 1):
		draw_line(poly[i-1], poly[i], outline, width)

Will result in a crash
Steps to reproduce
Please see above
Minimal reproduction project
Please see above

Incorrect reproduction, will update and reopen

I can not replicate this, also where are you getting the values outline and width from?

Hmm let me check that, this was a snippet of code which I found to reproduce it.

These variables are not available when following your instructions, so it will not run

The following code:
@tool
extends Polygon2D

func _draw():
	var poly = get_polygon()
	if not len(poly):
		return

	for i in range(1, poly.size() - 1):
		draw_line(poly[i-1], poly[i], 1, 1)

Crashes my game when using input for the polygon as follows:
# Args:
#   coordinate (Array): The 2D coordinate in array format [x, y]
#
# Returns:
#   Vector2: A Vector2 object with the same x and y values as the input coordinate array.
func coordinate_to_vector2(coordinate: Array) -> Vector2:
	return Vector2(coordinate[0], coordinate[1])

# Args:
#   coordinates (Array): An array of 2D coordinates in array format [x, y]
#
# Returns:
#   PackedVector2Array: A PackedVector2Array object containing Vector2
#   objects with the same x and y values as the input coordinates array.
func coordinates_to_packed_vector2(coords: Array) -> PackedVector2Array:
	if is_holding_array(coords):
		coords = coords[0]

	if "walls" in self.id:
		coords.append(coords[0])

	return coords.map(coordinate_to_vector2)

func _ready():
			var poly = preload("Polygon.gd").new()
			poly.set_polygon(coordinates_to_packed_vector2([[[-790.414, -2106.746], [-585.631, -1889.194], [-691.196, -1639.161], [-696.694, -1497.691], [-552.177, -1397.827], [-498.011, -1202.792], [-514.315, -1049.813], [-357.318, -912.706], [-326.068, -793.694], [-309.054, -680.202], [-403.158, -572.733], [-385.159, -492.73], [-305.721, -439.557], [-246.699, -360.468], [-170.929, -338.05], [-101.088, -256.587], [-117.475, -183.618], [-90.856, -141.479], [4.018, -129.376], [91.072, -120.111], [115.555, -151.142], [123.8, -215.888], [174.108, -257.399], [205.418, -313.623], [269.32, -385.302], [307.055, -463.138], [406.056, -534.026], [350.846, -690.688], [283.65, -776.969], [430.092, -917.012], [568.949, -949.925], [623.791, -1118.706], [669.719, -1216.703], [672.036, -1340.092], [642.029, -1373.2], [474.875, -1468.305], [451.759, -1664.691], [731.303, -1832.365], [696.519, -2133.375], [611.04, -2521.794], [953.949, -2894.9], [615.454, -3205.626], [447.625, -3152.932], [241.162, -2971.791], [86.813, -2975.465], [-423.716, -3159.868], [-429.239, -2835.354], [-489.387, -2539.198], [-718.406, -2381.315], [-802.642, -2253.309]]]))
			self.geometry.append(poly)

These variables are not available when following your instructions, so it will not run

As I mentioned, this was a code snippet, not the original full code as to keep the issue clean.
I reproduced above.

Please make sure your code is valid code though, it doesn't help if it doesn't work right?
Please provide a MRP as your new snippet doesn't give a clear idea of what the code does, what is "geometry", what type is the second part of the code on?
Can you confirm that it is actually the access of get_polygon() that causes this, because I can not replicate this, it is fully functional.

@AThousandShips you're very quick. I didn't even finish editing yet.

I was responding to the comment you posted, I assumed it was finished, my bad

-------------------------------------
Translated Report (Full Report Below)
-------------------------------------
Process:               Godot [69779]
Path:                  /Applications/Godot.app/Contents/MacOS/Godot
Identifier:            org.godotengine.godot
Version:               4.0 (4.0)
Code Type:             X86-64 (Native)
Parent Process:        launchd [1]
User ID:               501
Date/Time:             2023-03-05 23:02:51.2019 +0700
OS Version:            macOS 12.2.1 (21D62)
Report Version:        12
Bridge OS Version:     6.2 (19P744)
Anonymous UUID:        BE2F8F2B-8502-8BD7-6455-CD16A676D8EE
Sleep/Wake UUID:       6FCA6E01-7B41-435E-9E52-779B07308DBF
Time Awake Since Boot: 530000 seconds
Time Since Wake:       4724 seconds
System Integrity Protection: enabled
Crashed Thread:        0  Dispatch queue: com.apple.main-thread
Exception Type:        EXC_BAD_ACCESS (SIGABRT)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Codes:       0x0000000000000001, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY
VM Region Info: 0 is not in any region.  Bytes before following region:<PHONE_NUMBER>
REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
UNUSED SPACE AT START
--->
__TEXT                      10b1d0000-111624000    [100.3M] r-x/r-x SM=COW  ...s/MacOS/Godot
Application Specific Information:
abort() called
Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	    0x7ff80e594112 __pthread_kill + 10
1   libsystem_pthread.dylib       	    0x7ff80e5ca214 pthread_kill + 263
2   libsystem_c.dylib             	    0x7ff80e516d10 abort + 123
3   Godot                         	       0x10b63fefd 0x10b1d0000 + 4652797
4   libsystem_platform.dylib      	    0x7ff80e5dfe2d _sigtramp + 29
5   ???                           	    0x600000e79ef0 ???
6   Godot                         	       0x10c565af3 0x10b1d0000 + 20536051
7   Godot                         	       0x10c562a00 0x10b1d0000 + 20523520
8   Godot                         	       0x10c5605b1 0x10b1d0000 + 20514225
9   Godot                         	       0x10c55fc9c 0x10b1d0000 + 20511900
10  Godot                         	       0x10ebe28c0 0x10b1d0000 + 60893376
11  Godot                         	       0x10ebe50e0 0x10b1d0000 + 60903648
12  Godot                         	       0x10ec34dbd 0x10b1d0000 + 61230525
13  Godot                         	       0x10ec36137 0x10b1d0000 + 61235511
14  Godot                         	       0x10eca9c5e 0x10b1d0000 + 61709406
15  Godot                         	       0x10b691e5b 0x10b1d0000 + 4988507
16  Godot                         	       0x10b63cb33 0x10b1d0000 + 4639539
17  Godot                         	       0x10b668e9d 0x10b1d0000 + 4820637
18  dyld                          	       0x1208784fe start + 462
Thread 1:
0   libsystem_pthread.dylib       	    0x7ff80e5c5fec start_wqthread + 0
Thread 2:
0   libsystem_pthread.dylib       	    0x7ff80e5c5fec start_wqthread + 0
Thread 3:
0   libsystem_pthread.dylib       	    0x7ff80e5c5fec start_wqthread + 0
Thread 4:
0   libsystem_pthread.dylib       	    0x7ff80e5c5fec start_wqthread + 0
Thread 5:
0   libsystem_kernel.dylib        	    0x7ff80e590506 __psynch_cvwait + 10
1   libsystem_pthread.dylib       	    0x7ff80e5caa69 _pthread_cond_wait + 1224
2   libc++.1.dylib                	    0x7ff80e529ec2 std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&) + 18
3   Godot                         	       0x10f47426b _IP_ResolverPrivate::_thread_function(void*) + 139
4   Godot                         	       0x10f340ac9 0x10b1d0000 + 68618953
5   Godot                         	       0x10f340ffc 0x10b1d0000 + 68620284
6   libsystem_pthread.dylib       	    0x7ff80e5ca4f4 _pthread_start + 125
7   libsystem_pthread.dylib       	    0x7ff80e5c600f thread_start + 15
Thread 6:
0   libsystem_kernel.dylib        	    0x7ff80e590506 __psynch_cvwait + 10
1   libsystem_pthread.dylib       	    0x7ff80e5caa69 _pthread_cond_wait + 1224
2   libc++.1.dylib                	    0x7ff80e529ec2 std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&) + 18
3   Godot                         	       0x10f9a9abb 0x10b1d0000 + 75340475
4   Godot                         	       0x10f340ac9 0x10b1d0000 + 68618953
5   Godot                         	       0x10f340ffc 0x10b1d0000 + 68620284
6   libsystem_pthread.dylib       	    0x7ff80e5ca4f4 _pthread_start + 125
7   libsystem_pthread.dylib       	    0x7ff80e5c600f thread_start + 15
Thread 7:
0   libsystem_kernel.dylib        	    0x7ff80e590506 __psynch_cvwait + 10
1   libsystem_pthread.dylib       	    0x7ff80e5caa69 _pthread_cond_wait + 1224
2   libc++.1.dylib                	    0x7ff80e529ec2 std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&) + 18
3   Godot                         	       0x10f9a9abb 0x10b1d0000 + 75340475
4   Godot                         	       0x10f340ac9 0x10b1d0000 + 68618953
5   Godot                         	       0x10f340ffc 0x10b1d0000 + 68620284
6   libsystem_pthread.dylib       	    0x7ff80e5ca4f4 _pthread_start + 125
7   libsystem_pthread.dylib       	    0x7ff80e5c600f thread_start + 15
Thread 8:
0   libsystem_kernel.dylib        	    0x7ff80e590506 __psynch_cvwait + 10
1   libsystem_pthread.dylib       	    0x7ff80e5caa69 _pthread_cond_wait + 1224
2   libc++.1.dylib                	    0x7ff80e529ec2 std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&) + 18
3   Godot                         	       0x10f9a9abb 0x10b1d0000 + 75340475
4   Godot                         	       0x10f340ac9 0x10b1d0000 + 68618953
5   Godot                         	       0x10f340ffc 0x10b1d0000 + 68620284
6   libsystem_pthread.dylib       	    0x7ff80e5ca4f4 _pthread_start + 125
7   libsystem_pthread.dylib       	    0x7ff80e5c600f thread_start + 15
Thread 9:
0   libsystem_kernel.dylib        	    0x7ff80e590506 __psynch_cvwait + 10
1   libsystem_pthread.dylib       	    0x7ff80e5caa69 _pthread_cond_wait + 1224
2   libc++.1.dylib                	    0x7ff80e529ec2 std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&) + 18
3   Godot                         	       0x10f9a9abb 0x10b1d0000 + 75340475
4   Godot                         	       0x10f340ac9 0x10b1d0000 + 68618953
5   Godot                         	       0x10f340ffc 0x10b1d0000 + 68620284
6   libsystem_pthread.dylib       	    0x7ff80e5ca4f4 _pthread_start + 125
7   libsystem_pthread.dylib       	    0x7ff80e5c600f thread_start + 15
Thread 10:
0   libsystem_kernel.dylib        	    0x7ff80e590506 __psynch_cvwait + 10
1   libsystem_pthread.dylib       	    0x7ff80e5caa69 _pthread_cond_wait + 1224
2   libc++.1.dylib                	    0x7ff80e529ec2 std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&) + 18
3   Godot                         	       0x10f9a9abb 0x10b1d0000 + 75340475
4   Godot                         	       0x10f340ac9 0x10b1d0000 + 68618953
5   Godot                         	       0x10f340ffc 0x10b1d0000 + 68620284
6   libsystem_pthread.dylib       	    0x7ff80e5ca4f4 _pthread_start + 125
7   libsystem_pthread.dylib       	    0x7ff80e5c600f thread_start + 15
Thread 11:
0   libsystem_kernel.dylib        	    0x7ff80e590506 __psynch_cvwait + 10
1   libsystem_pthread.dylib       	    0x7ff80e5caa69 _pthread_cond_wait + 1224
2   libc++.1.dylib                	    0x7ff80e529ec2 std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&) + 18
3   Godot                         	       0x10f9a9abb 0x10b1d0000 + 75340475
4   Godot                         	       0x10f340ac9 0x10b1d0000 + 68618953
5   Godot                         	       0x10f340ffc 0x10b1d0000 + 68620284
6   libsystem_pthread.dylib       	    0x7ff80e5ca4f4 _pthread_start + 125
7   libsystem_pthread.dylib       	    0x7ff80e5c600f thread_start + 15
Thread 12:
0   libsystem_kernel.dylib        	    0x7ff80e590506 __psynch_cvwait + 10
1   libsystem_pthread.dylib       	    0x7ff80e5caa69 _pthread_cond_wait + 1224
2   libc++.1.dylib                	    0x7ff80e529ec2 std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&) + 18
3   Godot                         	       0x10f9a9abb 0x10b1d0000 + 75340475
4   Godot                         	       0x10f340ac9 0x10b1d0000 + 68618953
5   Godot                         	       0x10f340ffc 0x10b1d0000 + 68620284
6   libsystem_pthread.dylib       	    0x7ff80e5ca4f4 _pthread_start + 125
7   libsystem_pthread.dylib       	    0x7ff80e5c600f thread_start + 15
Thread 13:
0   libsystem_kernel.dylib        	    0x7ff80e590506 __psynch_cvwait + 10
1   libsystem_pthread.dylib       	    0x7ff80e5caa69 _pthread_cond_wait + 1224
2   libc++.1.dylib                	    0x7ff80e529ec2 std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&) + 18
3   Godot                         	       0x10f9a9abb 0x10b1d0000 + 75340475
4   Godot                         	       0x10f340ac9 0x10b1d0000 + 68618953
5   Godot                         	       0x10f340ffc 0x10b1d0000 + 68620284
6   libsystem_pthread.dylib       	    0x7ff80e5ca4f4 _pthread_start + 125
7   libsystem_pthread.dylib       	    0x7ff80e5c600f thread_start + 15
Thread 14:
0   libsystem_kernel.dylib        	    0x7ff80e5903da __semwait_signal + 10
1   libsystem_c.dylib             	    0x7ff80e4a58a9 nanosleep + 196
2   Godot                         	       0x10c4c9a2b 0x10b1d0000 + 19896875
3   Godot                         	       0x10f52375f 0x10b1d0000 + 70596447
4   Godot                         	       0x10f340ac9 0x10b1d0000 + 68618953
5   Godot                         	       0x10f340ffc 0x10b1d0000 + 68620284
6   libsystem_pthread.dylib       	    0x7ff80e5ca4f4 _pthread_start + 125
7   libsystem_pthread.dylib       	    0x7ff80e5c600f thread_start + 15
Thread 15:: com.apple.NSEventThread
0   libsystem_kernel.dylib        	    0x7ff80e58daba mach_msg_trap + 10
1   libsystem_kernel.dylib        	    0x7ff80e58de2b mach_msg + 59
2   CoreFoundation                	    0x7ff80e691af2 __CFRunLoopServiceMachPort + 319
3   CoreFoundation                	    0x7ff80e6901cb __CFRunLoopRun + 1325
4   CoreFoundation                	    0x7ff80e68f5dd CFRunLoopRunSpecific + 563
5   AppKit                        	    0x7ff81122cfd8 _NSEventThread + 132
6   libsystem_pthread.dylib       	    0x7ff80e5ca4f4 _pthread_start + 125
7   libsystem_pthread.dylib       	    0x7ff80e5c600f thread_start + 15
Thread 16:: AMCP Logging Spool
0   libsystem_kernel.dylib        	    0x7ff80e58daf6 semaphore_wait_trap + 10
1   caulk                         	    0x7ff8170541c0 caulk::mach::semaphore::wait_or_error() + 16
2   caulk                         	    0x7ff81703b08a caulk::concurrent::details::worker_thread::run() + 36
3   caulk                         	    0x7ff81703ad4e void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::)(), std::__1::tuplecaulk::concurrent::details::worker_thread* > >(void) + 41
4   libsystem_pthread.dylib       	    0x7ff80e5ca4f4 _pthread_start + 125
5   libsystem_pthread.dylib       	    0x7ff80e5c600f thread_start + 15
Thread 17:: com.apple.audio.IOThread.client
0   libsystem_kernel.dylib        	    0x7ff80e58daba mach_msg_trap + 10
1   libsystem_kernel.dylib        	    0x7ff80e58de2b mach_msg + 59
2   CoreAudio                     	    0x7ff81021195b HALB_MachPort::SendSimpleMessageWithSimpleReply(unsigned int, unsigned int, int, int&, bool, unsigned int) + 111
3   CoreAudio                     	    0x7ff8100a00ff HALC_ProxyIOContext::IOWorkLoop() + 3937
4   CoreAudio                     	    0x7ff81009ebc1 invocation function for block in HALC_ProxyIOContext::HALC_ProxyIOContext(unsigned int, unsigned int) + 63
5   CoreAudio                     	    0x7ff81026776c HALB_IOThread::Entry(void*) + 72
6   libsystem_pthread.dylib       	    0x7ff80e5ca4f4 _pthread_start + 125
7   libsystem_pthread.dylib       	    0x7ff80e5c600f thread_start + 15
Thread 18:
0   libsystem_kernel.dylib        	    0x7ff80e590506 __psynch_cvwait + 10
1   libsystem_pthread.dylib       	    0x7ff80e5caa69 _pthread_cond_wait + 1224
2   libc++.1.dylib                	    0x7ff80e529ec2 std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&) + 18
3   Godot                         	       0x10c14dabb 0x10b1d0000 + 16243387
4   Godot                         	       0x10c14d942 0x10b1d0000 + 16243010
5   Godot                         	       0x10c14d865 0x10b1d0000 + 16242789
6   libsystem_pthread.dylib       	    0x7ff80e5ca4f4 _pthread_start + 125
7   libsystem_pthread.dylib       	    0x7ff80e5c600f thread_start + 15
Thread 19:
0   libsystem_pthread.dylib       	    0x7ff80e5c5fec start_wqthread + 0
Thread 20:
0   libsystem_pthread.dylib       	    0x7ff80e5c5fec start_wqthread + 0
Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000000  rbx: 0x00000001208f3600  rcx: 0x00007ff7b4d2bf08  rdx: 0x0000000000000000
rdi: 0x0000000000000103  rsi: 0x0000000000000006  rbp: 0x00007ff7b4d2bf30  rsp: 0x00007ff7b4d2bf08
r8: 0x0000000111e23df0   r9: 0x0000000000000000  r10: 0x0000000000000000  r11: 0x0000000000000246
r12: 0x0000000000000103  r13: 0x00007fa73e24ad30  r14: 0x0000000000000006  r15: 0x0000000000000016
rip: 0x00007ff80e594112  rfl: 0x0000000000000246  cr2: 0x00007ff84fdf7890
Logical CPU:     0
Error Code:      0x02000148
Trap Number:     133
Thread 0 instruction stream:
c1 48 83 c1 10 3d ff ff-00 00 74 db f7 d0 0f bc  .H...=....t.....
c0 48 01 c1 48 0f b6 44-0f f0 4c 0f b6 44 0e f0  .H..H..D..L..D..
4c 29 c0 5d c3 90 90 90-90 90 90 90 90 90 90 90  L).]............
90 90 90 90 90 90 90 55-48 89 e5 49 89 fb 49 29  .......UH..I.. H..
48 83 ea 20 72 14 c5 fc-10 06 c5 fc 11 07 48 83  H.. r.........H.
c6 20 48 83 c7 20 48 83-ea 20 48 83 c2 10 7e 0c  . H.. H.. H...~.
Binary Images:
0x7ff80e58d000 -     0x7ff80e5c3fff libsystem_kernel.dylib ()  /usr/lib/system/libsystem_kernel.dylib
0x7ff80e5c4000 -     0x7ff80e5cffff libsystem_pthread.dylib ()  /usr/lib/system/libsystem_pthread.dylib
0x7ff80e495000 -     0x7ff80e51dfff libsystem_c.dylib () <4b160c81-ec52-3243-aaba-49f719bbf617> /usr/lib/system/libsystem_c.dylib
0x10b1d0000 -        0x111623fff org.godotengine.godot (4.0)  /Applications/Godot.app/Contents/MacOS/Godot
0x7ff80e5dc000 -     0x7ff80e5e5fff libsystem_platform.dylib ()  /usr/lib/system/libsystem_platform.dylib
0x0 - 0xffffffffffffffff ??? () <00000000-0000-0000-0000-000000000000> ???
0x120873000 -        0x1208defff dyld () <7de33963-bbc5-3996-ba6e-f1d562c17c95> /usr/lib/dyld
0x7ff80e51e000 -     0x7ff80e576fff libc++.1.dylib (*)  /usr/lib/libc++.1.dylib
0x7ff80e611000 -     0x7ff80eb13fff com.apple.CoreFoundation (6.9) <9b112884-be6c-3c7f-9a2a-a47c491105db> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x7ff811080000 -     0x7ff811f11fff com.apple.AppKit (6.9) <9d3ab204-4858-3120-b002-5c38b02edec4> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
0x7ff817039000 -     0x7ff81705bfff com.apple.audio.caulk (1.0) <0a60f9ec-f83c-388e-bcb1-43b785c997d1> /System/Library/PrivateFrameworks/caulk.framework/Versions/A/caulk
0x7ff80fee9000 -     0x7ff810610fff com.apple.audio.CoreAudio (5.0)  /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
VM Region Summary:
ReadOnly portion of Libraries: Total=1.1G resident=0K(0%) swapped_out_or_unallocated=1.1G(100%)
Writable regions: Total=828.8M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=828.8M(100%)
                            VIRTUAL   REGION

REGION TYPE                        SIZE    COUNT (non-coalesced)
===========                     =======  =======
Accelerate framework               640K        5
Activity Tracing                   256K        1
CG backing stores                 2160K        4
CG image                          4052K        3
ColorSync                          228K       26
CoreAnimation                      116K        8
CoreGraphics                        12K        2
CoreUI image data                  672K        5
Foundation                          16K        1
Kernel Alloc Once                    8K        1
MALLOC                           363.4M      210
MALLOC guard page                   32K        8
MALLOC_NANO (reserved)           384.0M        1         reserved VM address space (unallocated)
OpenGL GLSL                        256K        3
STACK GUARD                       56.1M       21
Stack                             18.2M       21
VM_ALLOCATE                       53.3M    11615
__DATA                            31.2M      383
__DATA_CONST                      20.9M      244
__DATA_DIRTY                      1136K      144
__FONT_DATA                          4K        1
__GLSLBUILTINS                    5176K        1
__LINKEDIT                       648.7M       11
__OBJC_RO                         81.8M        1
__OBJC_RW                         3136K        2
__TEXT                           444.1M      403
__UNICODE                          588K        1
dyld private memory               2048K        3
mapped file                      154.1M       20
shared memory                      772K       16
===========                     =======  =======
TOTAL                              2.2G    13165
TOTAL, minus reserved VM space     1.8G    13165

Full Report
{"app_name":"Godot","timestamp":"2023-03-05 23:02:51.00 +0700","app_version":"4.0","slice_uuid":"c248d6c7-59db-3d44-9867-e410d1e843f3","build_version":"4.0","platform":1,"bundleID":"org.godotengine.godot","share_with_app_devs":0,"is_first_party":0,"bug_type":"309","os_version":"macOS 12.2.1 (21D62)","incident_id":"B8E10B2C-5218-4321-B1D3-0564B06D82D9","name":"Godot"}
{
"uptime" : 530000,
"procLaunch" : "2023-03-05 23:02:47.6549 +0700",
"procRole" : "Foreground",
"version" : 2,
"userID" : 501,
"deployVersion" : 210,
"modelCode" : "MacBookPro15,2",
"procStartAbsTime" :<PHONE_NUMBER>20505,
"coalitionID" : 53782,
"osVersion" : {
"train" : "macOS 12.2.1",
"build" : "21D62",
"releaseType" : "User"
},
"captureTime" : "2023-03-05 23:02:51.2019 +0700",
"incident" : "B8E10B2C-5218-4321-B1D3-0564B06D82D9",
"bug_type" : "309",
"pid" : 69779,
"procExitAbsTime" :<PHONE_NUMBER>08257,
"cpuType" : "X86-64",
"procName" : "Godot",
"procPath" : "/Applications/Godot.app/Contents/MacOS/Godot",
"bundleInfo" : {"CFBundleShortVersionString":"4.0","CFBundleVersion":"4.0","CFBundleIdentifier":"org.godotengine.godot"},
"storeInfo" : {"deviceIdentifierForVendor":"4216EFBF-76D7-52C3-A1A4-5126B30FCC56","thirdParty":true},
"parentProc" : "launchd",
"parentPid" : 1,
"coalitionName" : "org.godotengine.godot",
"crashReporterKey" : "BE2F8F2B-8502-8BD7-6455-CD16A676D8EE",
"wakeTime" : 4724,
"bridgeVersion" : {"build":"19P744","train":"6.2"},
"sleepWakeUUID" : "6FCA6E01-7B41-435E-9E52-779B07308DBF",
"sip" : "enabled",
"vmRegionInfo" : "0 is not in any region.  Bytes before following region:<PHONE_NUMBER>\n      REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL\n      UNUSED SPACE AT START\n--->  \n      __TEXT                      10b1d0000-111624000    [100.3M] r-x/r-x SM=COW  ...s/MacOS/Godot",
"isCorpse" : 1,
"exception" : {"codes":"0x0000000000000001, 0x0000000000000000","rawCodes":[1,0],"type":"EXC_BAD_ACCESS","signal":"SIGABRT","subtype":"KERN_INVALID_ADDRESS at 0x0000000000000000"},
"vmregioninfo" : "0 is not in any region.  Bytes before following region:<PHONE_NUMBER>\n      REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL\n      UNUSED SPACE AT START\n--->  \n      __TEXT                      10b1d0000-111624000    [100.3M] r-x/r-x SM=COW  ...s/MacOS/Godot",
"asi" : {"libsystem_c.dylib":["abort() called"]},
"extMods" : {"caller":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"system":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"targeted":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"warnings":0},
"faultingThread" : 0,
"threads" : [{"triggered":true,"id":6337317,"instructionState":{"instructionStream":{"bytes":[193,72,131,193,16,61,255,255,0,0,116,219,247,208,15,188,192,72,1,193,72,15,182,68,15,240,76,15,182,68,14,240,76,41,192,93,195,144,144,144,144,144,144,144,144,144,144,144,144,144,144,144,144,144,144,85,72,137,229,73,137,251,73,41,243,72,137,248,73,57,211,114,27,72,131,250,96,118,47,72,129,250,0,64,0,0,15,130,203,0,0,0,72,137,209,252,243,164,93,195,72,57,254,116,249,72,1,214,72,1,215,72,131,250,96,15,130,140,1,0,0,233,169,1,0,0,72,131,250,16,118,86,197,248,16,76,22,240,72,131,234,32,118,42,197,252,16,6,197,252,17,7,72,131,198,32,72,131,199,32,72,131,234,32,114,20,197,252,16,6,197,252,17,7,72,131,198,32,72,131,199,32,72,131,234,32,72,131,194,16,126,12],"offset":96}},"threadState":{"r13":{"value":140356278857008},"rax":{"value":0},"rflags":{"value":582},"cpu":{"value":0},"r14":{"value":6},"rsi":{"value":6},"r8":{"value":4595006960},"cr2":{"value":140704468662416},"rdx":{"value":0},"r10":{"value":0},"r9":{"value":0},"r15":{"value":22},"rbx":{"value":4841223680,"symbolLocation":0,"symbol":"_main_thread"},"trap":{"value":133},"err":{"value":33554760},"r11":{"value":582},"rip":{"value":140703369347346,"matchesCrashFrame":1},"rbp":{"value":140701867360048},"rsp":{"value":140701867360008},"r12":{"value":259},"rcx":{"value":140701867360008},"flavor":"x86_THREAD_STATE","rdi":{"value":259}},"queue":"com.apple.main-thread","frames":[{"imageOffset":28946,"symbol":"__pthread_kill","symbolLocation":10,"imageIndex":0},{"imageOffset":25108,"symbol":"pthread_kill","symbolLocation":263,"imageIndex":1},{"imageOffset":531728,"symbol":"abort","symbolLocation":123,"imageIndex":2},{"imageOffset":4652797,"imageIndex":3},{"imageOffset":15917,"symbol":"_sigtramp","symbolLocation":29,"imageIndex":4},{"imageOffset":105553131446000,"imageIndex":5},{"imageOffset":20536051,"imageIndex":3},{"imageOffset":20523520,"imageIndex":3},{"imageOffset":20514225,"imageIndex":3},{"imageOffset":20511900,"imageIndex":3},{"imageOffset":60893376,"imageIndex":3},{"imageOffset":60903648,"imageIndex":3},{"imageOffset":61230525,"imageIndex":3},{"imageOffset":61235511,"imageIndex":3},{"imageOffset":61709406,"imageIndex":3},{"imageOffset":4988507,"imageIndex":3},{"imageOffset":4639539,"imageIndex":3},{"imageOffset":4820637,"imageIndex":3},{"imageOffset":21758,"symbol":"start","symbolLocation":462,"imageIndex":6}]},{"id":6337323,"frames":[{"imageOffset":8172,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":1}]},{"id":6337325,"frames":[{"imageOffset":8172,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":1}]},{"id":6337332,"frames":[{"imageOffset":8172,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":1}]},{"id":6337340,"frames":[{"imageOffset":8172,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":1}]},{"id":6337347,"frames":[{"imageOffset":13574,"symbol":"__psynch_cvwait","symbolLocation":10,"imageIndex":0},{"imageOffset":27241,"symbol":"_pthread_cond_wait","symbolLocation":1224,"imageIndex":1},{"imageOffset":48834,"symbol":"std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&)","symbolLocation":18,"imageIndex":7},{"imageOffset":69878379,"symbol":"_IP_ResolverPrivate::_thread_function(void*)","symbolLocation":139,"imageIndex":3},{"imageOffset":68618953,"imageIndex":3},{"imageOffset":68620284,"imageIndex":3},{"imageOffset":25844,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8207,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":6337348,"frames":[{"imageOffset":13574,"symbol":"__psynch_cvwait","symbolLocation":10,"imageIndex":0},{"imageOffset":27241,"symbol":"_pthread_cond_wait","symbolLocation":1224,"imageIndex":1},{"imageOffset":48834,"symbol":"std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&)","symbolLocation":18,"imageIndex":7},{"imageOffset":75340475,"imageIndex":3},{"imageOffset":68618953,"imageIndex":3},{"imageOffset":68620284,"imageIndex":3},{"imageOffset":25844,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8207,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":6337349,"frames":[{"imageOffset":13574,"symbol":"__psynch_cvwait","symbolLocation":10,"imageIndex":0},{"imageOffset":27241,"symbol":"_pthread_cond_wait","symbolLocation":1224,"imageIndex":1},{"imageOffset":48834,"symbol":"std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&)","symbolLocation":18,"imageIndex":7},{"imageOffset":75340475,"imageIndex":3},{"imageOffset":68618953,"imageIndex":3},{"imageOffset":68620284,"imageIndex":3},{"imageOffset":25844,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8207,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":6337350,"frames":[{"imageOffset":13574,"symbol":"__psynch_cvwait","symbolLocation":10,"imageIndex":0},{"imageOffset":27241,"symbol":"_pthread_cond_wait","symbolLocation":1224,"imageIndex":1},{"imageOffset":48834,"symbol":"std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&)","symbolLocation":18,"imageIndex":7},{"imageOffset":75340475,"imageIndex":3},{"imageOffset":68618953,"imageIndex":3},{"imageOffset":68620284,"imageIndex":3},{"imageOffset":25844,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8207,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":6337351,"frames":[{"imageOffset":13574,"symbol":"__psynch_cvwait","symbolLocation":10,"imageIndex":0},{"imageOffset":27241,"symbol":"_pthread_cond_wait","symbolLocation":1224,"imageIndex":1},{"imageOffset":48834,"symbol":"std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&)","symbolLocation":18,"imageIndex":7},{"imageOffset":75340475,"imageIndex":3},{"imageOffset":68618953,"imageIndex":3},{"imageOffset":68620284,"imageIndex":3},{"imageOffset":25844,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8207,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":6337352,"frames":[{"imageOffset":13574,"symbol":"__psynch_cvwait","symbolLocation":10,"imageIndex":0},{"imageOffset":27241,"symbol":"_pthread_cond_wait","symbolLocation":1224,"imageIndex":1},{"imageOffset":48834,"symbol":"std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&)","symbolLocation":18,"imageIndex":7},{"imageOffset":75340475,"imageIndex":3},{"imageOffset":68618953,"imageIndex":3},{"imageOffset":68620284,"imageIndex":3},{"imageOffset":25844,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8207,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":6337353,"frames":[{"imageOffset":13574,"symbol":"__psynch_cvwait","symbolLocation":10,"imageIndex":0},{"imageOffset":27241,"symbol":"_pthread_cond_wait","symbolLocation":1224,"imageIndex":1},{"imageOffset":48834,"symbol":"std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&)","symbolLocation":18,"imageIndex":7},{"imageOffset":75340475,"imageIndex":3},{"imageOffset":68618953,"imageIndex":3},{"imageOffset":68620284,"imageIndex":3},{"imageOffset":25844,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8207,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":6337354,"frames":[{"imageOffset":13574,"symbol":"__psynch_cvwait","symbolLocation":10,"imageIndex":0},{"imageOffset":27241,"symbol":"_pthread_cond_wait","symbolLocation":1224,"imageIndex":1},{"imageOffset":48834,"symbol":"std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&)","symbolLocation":18,"imageIndex":7},{"imageOffset":75340475,"imageIndex":3},{"imageOffset":68618953,"imageIndex":3},{"imageOffset":68620284,"imageIndex":3},{"imageOffset":25844,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8207,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":6337355,"frames":[{"imageOffset":13574,"symbol":"__psynch_cvwait","symbolLocation":10,"imageIndex":0},{"imageOffset":27241,"symbol":"_pthread_cond_wait","symbolLocation":1224,"imageIndex":1},{"imageOffset":48834,"symbol":"std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&)","symbolLocation":18,"imageIndex":7},{"imageOffset":75340475,"imageIndex":3},{"imageOffset":68618953,"imageIndex":3},{"imageOffset":68620284,"imageIndex":3},{"imageOffset":25844,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8207,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":6337356,"frames":[{"imageOffset":13274,"symbol":"__semwait_signal","symbolLocation":10,"imageIndex":0},{"imageOffset":67753,"symbol":"nanosleep","symbolLocation":196,"imageIndex":2},{"imageOffset":19896875,"imageIndex":3},{"imageOffset":70596447,"imageIndex":3},{"imageOffset":68618953,"imageIndex":3},{"imageOffset":68620284,"imageIndex":3},{"imageOffset":25844,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8207,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":6337359,"name":"com.apple.NSEventThread","frames":[{"imageOffset":2746,"symbol":"mach_msg_trap","symbolLocation":10,"imageIndex":0},{"imageOffset":3627,"symbol":"mach_msg","symbolLocation":59,"imageIndex":0},{"imageOffset":527090,"symbol":"__CFRunLoopServiceMachPort","symbolLocation":319,"imageIndex":8},{"imageOffset":520651,"symbol":"__CFRunLoopRun","symbolLocation":1325,"imageIndex":8},{"imageOffset":517597,"symbol":"CFRunLoopRunSpecific","symbolLocation":563,"imageIndex":8},{"imageOffset":1757144,"symbol":"_NSEventThread","symbolLocation":132,"imageIndex":9},{"imageOffset":25844,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8207,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":6337364,"name":"AMCP Logging Spool","frames":[{"imageOffset":2806,"symbol":"semaphore_wait_trap","symbolLocation":10,"imageIndex":0},{"imageOffset":111040,"symbol":"caulk::mach::semaphore::wait_or_error()","symbolLocation":16,"imageIndex":10},{"imageOffset":8330,"symbol":"caulk::concurrent::details::worker_thread::run()","symbolLocation":36,"imageIndex":10},{"imageOffset":7502,"symbol":"void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::)(), std::__1::tuplecaulk::concurrent::details::worker_thread* > >(void)","symbolLocation":41,"imageIndex":10},{"imageOffset":25844,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8207,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":6337381,"name":"com.apple.audio.IOThread.client","frames":[{"imageOffset":2746,"symbol":"mach_msg_trap","symbolLocation":10,"imageIndex":0},{"imageOffset":3627,"symbol":"mach_msg","symbolLocation":59,"imageIndex":0},{"imageOffset":3311963,"symbol":"HALB_MachPort::SendSimpleMessageWithSimpleReply(unsigned int, unsigned int, int, int&, bool, unsigned int)","symbolLocation":111,"imageIndex":11},{"imageOffset":1798399,"symbol":"HALC_ProxyIOContext::IOWorkLoop()","symbolLocation":3937,"imageIndex":11},{"imageOffset":1792961,"symbol":"invocation function for block in HALC_ProxyIOContext::HALC_ProxyIOContext(unsigned int, unsigned int)","symbolLocation":63,"imageIndex":11},{"imageOffset":3663724,"symbol":"HALB_IOThread::Entry(void*)","symbolLocation":72,"imageIndex":11},{"imageOffset":25844,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8207,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":6337408,"frames":[{"imageOffset":13574,"symbol":"__psynch_cvwait","symbolLocation":10,"imageIndex":0},{"imageOffset":27241,"symbol":"_pthread_cond_wait","symbolLocation":1224,"imageIndex":1},{"imageOffset":48834,"symbol":"std::__1::condition_variable::wait(std::__1::unique_lockstd::__1::mutex&)","symbolLocation":18,"imageIndex":7},{"imageOffset":16243387,"imageIndex":3},{"imageOffset":16243010,"imageIndex":3},{"imageOffset":16242789,"imageIndex":3},{"imageOffset":25844,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":1},{"imageOffset":8207,"symbol":"thread_start","symbolLocation":15,"imageIndex":1}]},{"id":6337414,"frames":[{"imageOffset":8172,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":1}]},{"id":6337415,"frames":[{"imageOffset":8172,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":1}]}],
"usedImages" : [
{
"source" : "P",
"arch" : "x86_64",
"base" :<PHONE_NUMBER>18400,
"size" : 225280,
"uuid" : "c1d58a50-5a4d-3bcb-a1fc-ec0902ce34d3",
"path" : "/usr/lib/system/libsystem_kernel.dylib",
"name" : "libsystem_kernel.dylib"
},
{
"source" : "P",
"arch" : "x86_64",
"base" :<PHONE_NUMBER>43680,
"size" : 49152,
"uuid" : "ee564342-d8f2-396d-b642-40092cf34d82",
"path" : "/usr/lib/system/libsystem_pthread.dylib",
"name" : "libsystem_pthread.dylib"
},
{
"source" : "P",
"arch" : "x86_64",
"base" :<PHONE_NUMBER>02592,
"size" : 561152,
"uuid" : "4b160c81-ec52-3243-aaba-49f719bbf617",
"path" : "/usr/lib/system/libsystem_c.dylib",
"name" : "libsystem_c.dylib"
},
{
"source" : "P",
"arch" : "x86_64",
"base" :<PHONE_NUMBER>,
"CFBundleShortVersionString" : "4.0",
"CFBundleIdentifier" : "org.godotengine.godot",
"size" : 105201664,
"uuid" : "c248d6c7-59db-3d44-9867-e410d1e843f3",
"path" : "/Applications/Godot.app/Contents/MacOS/Godot",
"name" : "Godot",
"CFBundleVersion" : "4.0"
},
{
"source" : "P",
"arch" : "x86_64",
"base" :<PHONE_NUMBER>41984,
"size" : 40960,
"uuid" : "f4a8a6fb-7eb7-3794-9196-39b494573a33",
"path" : "/usr/lib/system/libsystem_platform.dylib",
"name" : "libsystem_platform.dylib"
},
{
"size" : 0,
"source" : "A",
"base" : 0,
"uuid" : "00000000-0000-0000-0000-000000000000"
},
{
"source" : "P",
"arch" : "x86_64",
"base" :<PHONE_NUMBER>,
"size" : 442368,
"uuid" : "7de33963-bbc5-3996-ba6e-f1d562c17c95",
"path" : "/usr/lib/dyld",
"name" : "dyld"
},
{
"source" : "P",
"arch" : "x86_64",
"base" :<PHONE_NUMBER>63744,
"size" : 364544,
"uuid" : "fa3f989d-0003-37ef-a495-36be29bc1552",
"path" : "/usr/lib/libc++.1.dylib",
"name" : "libc++.1.dylib"
},
{
"source" : "P",
"arch" : "x86_64h",
"base" :<PHONE_NUMBER>59072,
"CFBundleShortVersionString" : "6.9",
"CFBundleIdentifier" : "com.apple.CoreFoundation",
"size" : 5255168,
"uuid" : "9b112884-be6c-3c7f-9a2a-a47c491105db",
"path" : "/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation",
"name" : "CoreFoundation",
"CFBundleVersion" : "1856.107"
},
{
"source" : "P",
"arch" : "x86_64",
"base" :<PHONE_NUMBER>53920,
"CFBundleShortVersionString" : "6.9",
"CFBundleIdentifier" : "com.apple.AppKit",
"size" : 15278080,
"uuid" : "9d3ab204-4858-3120-b002-5c38b02edec4",
"path" : "/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit",
"name" : "AppKit",
"CFBundleVersion" : "2113.30.116"
},
{
"source" : "P",
"arch" : "x86_64",
"base" :<PHONE_NUMBER>26400,
"CFBundleShortVersionString" : "1.0",
"CFBundleIdentifier" : "com.apple.audio.caulk",
"size" : 143360,
"uuid" : "0a60f9ec-f83c-388e-bcb1-43b785c997d1",
"path" : "/System/Library/PrivateFrameworks/caulk.framework/Versions/A/caulk",
"name" : "caulk"
},
{
"source" : "P",
"arch" : "x86_64",
"base" :<PHONE_NUMBER>09632,
"CFBundleShortVersionString" : "5.0",
"CFBundleIdentifier" : "com.apple.audio.CoreAudio",
"size" : 7503872,
"uuid" : "d4152db5-e397-3670-b214-350dacb7febf",
"path" : "/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio",
"name" : "CoreAudio",
"CFBundleVersion" : "5.0"
}
],
"sharedCache" : {
"base" :<PHONE_NUMBER>11936,
"size" :<PHONE_NUMBER>8,
"uuid" : "0939015d-8308-3e69-b095-bd928f835202"
},
"vmSummary" : "ReadOnly portion of Libraries: Total=1.1G resident=0K(0%) swapped_out_or_unallocated=1.1G(100%)\nWritable regions: Total=828.8M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=828.8M(100%)\n\n                                VIRTUAL   REGION \nREGION TYPE                        SIZE    COUNT (non-coalesced) \n===========                     =======  ======= \nAccelerate framework               640K        5 \nActivity Tracing                   256K        1 \nCG backing stores                 2160K        4 \nCG image                          4052K        3 \nColorSync                          228K       26 \nCoreAnimation                      116K        8 \nCoreGraphics                        12K        2 \nCoreUI image data                  672K        5 \nFoundation                          16K        1 \nKernel Alloc Once                    8K        1 \nMALLOC                           363.4M      210 \nMALLOC guard page                   32K        8 \nMALLOC_NANO (reserved)           384.0M        1         reserved VM address space (unallocated)\nOpenGL GLSL                        256K        3 \nSTACK GUARD                       56.1M       21 \nStack                             18.2M       21 \nVM_ALLOCATE                       53.3M    11615 \n__DATA                            31.2M      383 \n__DATA_CONST                      20.9M      244 \n__DATA_DIRTY                      1136K      144 \n__FONT_DATA                          4K        1 \n__GLSLBUILTINS                    5176K        1 \n__LINKEDIT                       648.7M       11 \n__OBJC_RO                         81.8M        1 \n__OBJC_RW                         3136K        2 \n__TEXT                           444.1M      403 \n__UNICODE                          588K        1 \ndyld private memory               2048K        3 \nmapped file                      154.1M       20 \nshared memory                      772K       16 \n===========                     =======  ======= \nTOTAL                              2.2G    13165 \nTOTAL, minus reserved VM space     1.8G    13165 \n",
"legacyInfo" : {
"threadTriggered" : {
"queue" : "com.apple.main-thread"
}
},
"trialInfo" : {
"rollouts" : [
{
"rolloutId" : "60da5e84ab0ca017dace9abf",
"factorPackIds" : {
  },
  "deploymentId" : 240000008
},
{
  "rolloutId" : "607844aa04477260f58a8077",
  "factorPackIds" : {
    "SIRI_MORPHUN_ASSETS" : "6103050cbfe6dc472e1c982a"
  },
  "deploymentId" : 240000066
},
{
  "rolloutId" : "602ad4dac86151000cf27e46",
  "factorPackIds" : {
    "SIRI_DICTATION_ASSETS" : "6193d03f2171a2330e561dfc"
  },
  "deploymentId" : 240000303
},
{
  "rolloutId" : "601d9415f79519000ccd4b69",
  "factorPackIds" : {
    "SIRI_TEXT_TO_SPEECH" : "622657ce37186c771d5404ad"
  },
  "deploymentId" : 240000416
},
{
  "rolloutId" : "60356660bbe37970735c5624",
  "factorPackIds" : {

  },
  "deploymentId" : 240000027
},
{
  "rolloutId" : "60186475825c62000ccf5450",
  "factorPackIds" : {

  },
  "deploymentId" : 240000026
},
{
  "rolloutId" : "60f8ddccefea4203d95cbeef",
  "factorPackIds" : {

  },
  "deploymentId" : 240000021
},
{
  "rolloutId" : "63582c5f8a53461413999550",
  "factorPackIds" : {

  },
  "deploymentId" : 240000002
},
{
  "rolloutId" : "5fb4245a1bbfe8005e33a1e1",
  "factorPackIds" : {

  },
  "deploymentId" : 240000021
},
{
  "rolloutId" : "5ffde50ce2aacd000d47a95f",
  "factorPackIds" : {

  },
  "deploymentId" : 240000223
},
{
  "rolloutId" : "5fc94383418129005b4e9ae0",
  "factorPackIds" : {

  },
  "deploymentId" : 240000544
}

],
"experiments" : [
]
}
}

Please provide an MRP, an MRP is a packaged project (zip) that shows the error.
Your code, as it contains a lot of functionality and details that aren't shown, can't be tested

@AThousandShips while I thank you for checking my codebase, The full source is listed above without missing functionality.
I'm a little busy trying to convert numerous libs to Godot4 right now.
Perhaps you can point out what is missing?

I can still not replicate any crash

@tavurth Please upload a minimal reproduction project to make this easier to troubleshoot.

Unfortunately as I mentioned before I don't get any time to do Godot stuff at the moment, maybe in a month or so

Closing for now. This can be reopened once a minimal reproduction project is uploaded.


wlroots: remove broken tag

Motivation for this change
See: https://github.com/NixOS/nixpkgs/issues/38344#issuecomment-432032834
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

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

Success on aarch64-linux (full log)
Attempted: wlroots
Partial log (click to expand)
shrinking /nix/store/lkdvdkj5d67hixcyf15q59bsppcilmsa-wlroots-0.1-examples/bin/screencopy
shrinking /nix/store/lkdvdkj5d67hixcyf15q59bsppcilmsa-wlroots-0.1-examples/bin/layer-shell
shrinking /nix/store/lkdvdkj5d67hixcyf15q59bsppcilmsa-wlroots-0.1-examples/bin/input-method
shrinking /nix/store/lkdvdkj5d67hixcyf15q59bsppcilmsa-wlroots-0.1-examples/bin/text-input
shrinking /nix/store/lkdvdkj5d67hixcyf15q59bsppcilmsa-wlroots-0.1-examples/bin/rootston
strip is /nix/store/p9akxn2sfy4wkhqdqa3li97pc6jaz3r1-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/lkdvdkj5d67hixcyf15q59bsppcilmsa-wlroots-0.1-examples/lib  /nix/store/lkdvdkj5d67hixcyf15q59bsppcilmsa-wlroots-0.1-examples/bin
patching script interpreter paths in /nix/store/lkdvdkj5d67hixcyf15q59bsppcilmsa-wlroots-0.1-examples
checking for references to /build in /nix/store/lkdvdkj5d67hixcyf15q59bsppcilmsa-wlroots-0.1-examples...
/nix/store/955m89xjq78viykd20gmg07jmxwi2qa9-wlroots-0.1

Success on x86_64-linux (full log)
Attempted: wlroots
Partial log (click to expand)
shrinking /nix/store/4j07znaad92amaq2s6qk2p2dr20k0rq8-wlroots-0.1-examples/bin/input-inhibitor
shrinking /nix/store/4j07znaad92amaq2s6qk2p2dr20k0rq8-wlroots-0.1-examples/bin/pointer-constraints
shrinking /nix/store/4j07znaad92amaq2s6qk2p2dr20k0rq8-wlroots-0.1-examples/bin/rotation
shrinking /nix/store/4j07znaad92amaq2s6qk2p2dr20k0rq8-wlroots-0.1-examples/bin/rootston
shrinking /nix/store/4j07znaad92amaq2s6qk2p2dr20k0rq8-wlroots-0.1-examples/bin/input-method
strip is /nix/store/vcc4svb8gy29g4pam2zja6llkbcwsyiq-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/4j07znaad92amaq2s6qk2p2dr20k0rq8-wlroots-0.1-examples/lib  /nix/store/4j07znaad92amaq2s6qk2p2dr20k0rq8-wlroots-0.1-examples/bin
patching script interpreter paths in /nix/store/4j07znaad92amaq2s6qk2p2dr20k0rq8-wlroots-0.1-examples
checking for references to /build in /nix/store/4j07znaad92amaq2s6qk2p2dr20k0rq8-wlroots-0.1-examples...
/nix/store/jsp0jx73z90b3rmlj88v168mmc171qj5-wlroots-0.1


Is it possible to track the current connected satellite id?

Hi,
I’m wondering if it’s possible to identify the satellite currently in use. It appears there was a function, dish_get_context, that could provide the satellite ID, but this call seems to be unavailable now.
Could you provide any alternative methods for identifying the connected satellite?

I'm pretty sure the short answer is no.
The dish_get_context request is still there, but it returns an authorization error when run locally. I'm not even sure it has the actual current satellite ID, anyway. There is also a transceiver_get_telemetry request that does have what might be current satellite ID, but that also returns an authorization error when run locally. It could be that these can only be run remotely, or they might be locked down in some other way.
I suppose it would be technically possible to track the satellites by resetting the obstruction map, examining where new map data fills in, and correlating that with satellite position data, but doing so would require periodically resetting the map and that would probably impact the dish's ability to avoid obstructions.

I'm pretty sure the short answer is no.
The dish_get_context request is still there, but it returns an authorization error when run locally. I'm not even sure it has the actual current satellite ID, anyway. There is also a transceiver_get_telemetry request that does have what might be current satellite ID, but that also returns an authorization error when run locally. It could be that these can only be run remotely, or they might be locked down in some other way.
I suppose it would be technically possible to track the satellites by resetting the obstruction map, examining where new map data fills in, and correlating that with satellite position data, but doing so would require periodically resetting the map and that would probably impact the dish's ability to avoid obstructions.

Thanks for your reply!


How do I inference a file?

As per title, I cannot seem to infer a new project using main.py, and any of the samples projects. Seems to be an error with ph_dur being unable to split due to value being null.
Also I am using a Japanese model (albeit I haven't fixed all of the bugs) with a Japanese dict that I made. Training does seem to run fine, however.

Thank you for your feedback. These sample ds files are replaced with some new files that can be used for no-midi inference. Just pull and try again.
Since we keep improving DiffSinger, these ds files may be incompatible with future releases.

This is because models of MIDI-less mode have no ability to predict phone durations themselves. To run inference, you must specify the phones, durations and f0 explicitly.
Please note that the current samples in this repository are only compatible with Chinese dictionary. If you are using a model trained with your custom dictionary, you must make sure all phonemes are in the phoneme list. Otherwise, an error will be raised.

I see, thank you! By the way, how do I get f0_timestep and f0_seq?

Ds files are generated by OpenSVIP Converter, which can convert the project of other singing voice synthesizer (e.g. svp, svip) to ds file and write f0_timestep and f0_seq into it at the same time. The converter has only Simplified Chinese version, and may not work well with non-Chinese languages like Japanese.

I see, thank you! By the way, how do I get f0_timestep and f0_seq?

The easiest way is to just use OpenUtau for DiffSinger. which is an unofficial support for the DiffSinger renderer. But please note that the voicebank packaging format of this OpenUtau may vary in the future.
If you do want to run inference with PyTorch and your customized ds file, you may have to write some code or scripts since there are no international support from the format converter.

Thanks for the replies~ I'll look into the OpenSVIP Converter. I tried using the OpenUtau for DiffSinger fork, though I cannot seem to convert my model into the ONNX format since it seems to detect my model as not MIDI-less (even though the config is using nomidi... qwq)

All models trained with config and data built with this pipeline, or from this release, should be in MIDI-less mode. If not, there is something wrong with your dataset making, preprocessing or training procedure.
By the way, please do not train models in MIDI mode. Support for any other except MIDI-less may be removed in the future.

It turns out I accidentally used the file wrong qwq
I accidentally pointed the exp to the ckpt instead of the singer name
Though for some reason I had to downgrade my torch ver to 1.8.1 due to an error of

export() got an unexpecte keyword argument 'example_outputs'

It seems like example_outputs is deprecated (unsure) but atleast I got the ONNX file...

Yes, that script only support PyTorch 1.8, due to some bugs caused by TorchScript, or the official ONNX API, or just bugs in my own code (I have not got time to figure out whose fault it is, but PyTorch 1.8 does run well on this).
Anyway, exporting ONNX files does not require a GPU. Installing a CPU PyTorch just for exporting is not very annoying, though.


Drop support for EOL Python 3.4

Upgrade Python syntax with pyupgrade
Update unit test asserts

Python 3.4 is EOL and no longer receiving security updates (or any updates) from the core Python team.

Version
Release date
Supported until

2.7
2010-07-03
2020-01-01

3.4
2014-03-16
2019-03-16

Source: https://en.wikipedia.org/wiki/CPython#Version_history
It's also little used. Here's the pip installs for diff_cover from PyPI for August 2019:

category
percent
downloads

2.7
48.52%
29,539

3.6
31.69%
19,296

3.7
13.06%
7,950

3.5
4.19%
2,551

null
1.99%
1,212

3.4
0.38%
232

2.6
0.06%
35

3.2
0.05%
33

3.3
0.05%
33

3.8
0.00%
1

Total

60,882

Date range: 2019-08-01 - 2019-08-31
Source: pip install -U pypistats && pypistats python_minor diff_cover --last-month

Awesome! Thanks!


Fix charset to utf8

Since tidb use only utf-8 and we need to fix charset to utf-8 instead of jvm default.

This change is

/run-all-tests

LGTM


Fix the portuguese word list to use the correct and accepted version

Implements the correct Portuguese word list (see #385 & https://github.com/bitcoin/bips/pull/998)

I also announced it on https://twitter.com/NicolasDorier/status/1406805465686675458?s=20
That suck... :(

@NicolasDorier I made a tool that makes the conversion of words from one list to another. Check it out https://github.com/johnnyasantoss/bip39-nbitcoin-fixer

@johnnyasantoss  mmh maybe I should add a method as well to convert it.

@johnnyasantoss mmh maybe I should add a method as well to convert it.

I don't see wallets doing this type of recovery, given that it is super specific. I think that people would already be able to find this PR with ease :)


Receipt Validation for fake purchases

I had big issue about fake purchases in my recent project(which I used out libraries for purchasing), people were buying premium stuff with programs like luckypatcher without paying real money. I was able to see them but needed to ban/warn them manually.
I am curious how effective is validateReceiptIos method for stopping fake purchases. I know that I can clearly check the reality of the purchase via google API but in case can I use validateReceiptIos method to stop fake purchases in some level?
Can you please explain details about it? Thank you.

This issue should be further invested to those who need this in advance. Since I've not had worked on this issue yet. Hope you can find some improvement for us (maybe through stackoverflow) and guide us.

I thought you can validate receipt in ios to prevent the fake purchase. Check this repo and see if you can do additional problem solving. I will close this for now since I think there aren't further job currently but please feel free to reopen when you think this should be invested.

Ok yeah you are right, thanks for the answers. But maybe dont close it, let it stay open so people may be more willing to write about it. I guess if we can solve this issue somehow in front end part, this may be much better because we will not need to validate purchases via google api.

@losheredos If you wan't to prevent fake purchases, the only way to do that it is server validation. All other solutions on frontend part are not so effective.


Artwr/erroring if relative is in different dag

@mistercrunch.
Take 2. This does two things :

Make task1._set_relative(task1) act as a noop with just a debug logging. We can remove that if you would like. This would allow us to add a task to the dag and set it after to be downstream of all the roots of the dag.
The new pattern for for email could be :

    dag.add_task(email)
    email.set_upstream(dag.roots)

Suppress does not throw an error if the non matching dag_id is equal to "adhoc_" + owner, which is what was happening for tasks setup without a dag parameter but within a dag definition file. This solves the errors we had with the pattern of setting an email operator at the end, but logs a debug message. The pattern above should not.

Let me know what you think.
(This has been tested on the dev webserver with all the dags in prod)

On another note I also recommend using  email.set_upstream([r for r in dag.roots if not r.adhoc]) for this, as we have set up adhoc tasks like recreating one offs mapping tables, and did not want to have the emails depend on those.

@mistercrunch Sorry for the push -f.
I found a couple more reasons not to add the task automatically in set_relatives. Let's connect tomorrow to see if you agree.


TCGC misrepresents binary payloads

NOTE: this is using the changes in https://github.com/Azure/typespec-azure/pull/6
For reference.
https://github.com/Azure/cadl-ranch/blob/main/packages/cadl-ranch-specs/http/encode/bytes/main.tsp#L246-L274
For the body parameter, the defaultContentType is still application/json and kind is bytes (correct) which has an incorrect encode value of base64 (I don't know what the value should be though).

I have a quick fix with the latest commit in https://github.com/Azure/typespec-azure/pull/6.
For the encode of bytes, the new logic is:
if @encode, honor @encode value, else,
if it is a body with content type application/json, encode will be bytes
if it is a body with other content type, encode will be base64
if it is parameter/properties, encode will be base64
@iscai-msft, could you confirm.

Not sure I follow. IMO, encode should only be set to base64 when the content type is application/json.

Yes, the correct order should be

@encode decorator
bytes + application/json defaults to a bytes type with encoding of base64
bytes + other non-json content types, i.e. application/octet-stream / image/png output a binary payload. We currently represent this as a bytes type with no encoding, but I do want to follow up with the team about this

This is a recurring topic, as we have also scenario where the body is JSON, but we want to treat as bytes (SDK is passthrough), and right now we can't expresse that. There was a discussion to make this a design discussion:
https://teams.microsoft.com/l/message/19:906c1efbbec54dc8949ac736633e6bdf@thread.skype/1700613734908?tenantId=72f988bf-86f1-41af-91ab-2d7cd011db47&groupId=3e17dcb0-4257-4a30-b843-77f47f1d4121&parentMessageId=1700613734908&teamName=Azure SDK&channelName=TypeSpec Discussion 🐮&createdTime=1700613734908

We have solved this for Go by looking at the default content type for a response. If it's not application/json, application/xml, or text/plain (we are loose on the matching), then we assume it to be a binary stream. Does this seem reasonable? It's working so far.

closing in favor of https://github.com/Azure/typespec-azure/issues/614

Reopening as I believe this is distinct from #614 which is about streaming/SSE.
To be clear, this is about "vanilla" binary responses. e.g. https://github.com/Azure/cadl-ranch/blob/main/packages/cadl-ranch-specs/http/payload/content-negotiation/main.tsp. The response types are being modeled as base64-encoded bytes which is clearly incorrect.

@jhendrixMSFT I've added this to the upcoming sprint

@tadelesh what does the fix look like?

the response type is a bytes and the encode is also bytes. see the test here.


Changes to Node.js exports specification

Node.js has changed their exports specification deprecating trailing slash pattern mappings in https://github.com/nodejs/node/pull/40039 and added support for pattern trailers in https://github.com/nodejs/node/pull/39635 so some changes might be required.

This is already supported. The deprecated syntax will continue to be supported because it's still widely used and Node also supports it (and will for a long time as it's part of LTS)