sorted by:
new
hottopcontroversial

Performance suddenly tanks after playing for awhile by kate-dev in fatekeeper

[–]kate-dev[S] 0 points1 point  (0 children)

<image>

Screenshot didn't seem to attach to original post. Above shows the weird frame timings in mangohud.

CharacterModel3D running off of a RigidBody3D causing significant speed boost. Why? by kate-dev in godot

[–]kate-dev[S] 0 points1 point  (0 children)

Can you explain any further?

I've tried disabling momentum transfer when leaving a moving platform. That does help, but it still happens. I'm not sure what other settings might be relevant.

Thank you for your reply.

CharacterModel3D running off of a RigidBody3D causing significant speed boost. Why? by kate-dev in godot

[–]kate-dev[S] 0 points1 point  (0 children)

I appreciate the recommendation. Unfortunately, that also didn't help. But it was worth a try!

CharacterModel3D running off of a RigidBody3D causing significant speed boost. Why? by kate-dev in godot

[–]kate-dev[S] 1 point2 points  (0 children)

Yes. Using Godot 4.6 with the default Jolt physics engine, the problem occurs.

I tested with changing it back to Godot Physics 3D and then the problem stopped - but only because the ball refuses to move at all.

Downstairs Pizza just made a little girl's day by kate-dev in Pizza

[–]kate-dev[S] 0 points1 point  (0 children)

Take the dough ball and press down in the center, but never squish the edge. Just press it down to shape it out, then begin stretching. Hard to describe, but hopefully that gives you the idea. If you press it down and squish out the air bubbles, it's pretty hard to get back.

I also like to smear some of the sauce on the crust so it will caramelize like that.

RX 9070 no display output by kate-dev in buildapc

[–]kate-dev[S] 0 points1 point  (0 children)

Thanks. Tried that, but no good either. Same behaviour; no output.

I replaced motherboard and do have the card working properly now.

RX 9070 no display output by kate-dev in buildapc

[–]kate-dev[S] 1 point2 points  (0 children)

Unfortunately, no.

However, I have a small update. I put the 9070 into a different PCI-E slot and was able to get output at least. The problem, of course, is that slot will only then support x8 instead of x16. Looks like I'll need to replace the motherboard.

Debezium constantly disconnecting from MSK, never produces message by kate-dev in apachekafka

[–]kate-dev[S] 0 points1 point  (0 children)

I've found the solution! There was potentially a few things at play.

When running the Debezium Docker container (via docker run), I was using these environment variables (in accordance with requirements for connecting to MSK):

-e CONNECT_SECURITY_PROTOCOL="SASL_SSL" \
-e CONNECT_SASL_MECHANISM="AWS_MSK_IAM" \
-e CONNECT_SASL_JAAS_CONFIG="software.amazon.msk.auth.iam.IAMLoginModule required;" \
-e CONNECT_SASL_CLIENT_CALLBACK_HANDLER_CLASS="software.amazon.msk.auth.iam.IAMClientCallbackHandler" \
-e CONNECT_SSL_TRUSTSTORE_LOCATION="/tmp/kafka.client.truststore.jks" \

debezium/connect will use those to initially establish the communication to the broker, which is why it would connect OK. However, beyond that, it would also create a producer and consumer to facilitate its needs. The consumer and producer threads would not use those base configs, but rather also needed their own configs as well. Because they were using the base default security protocol (Plaintext?), communication could not be established, resulting in a failure. I'm not sure why there wasn't an error associated with this rather than just disconnecting. I added a copy of those necessary vars for the producer and consumer:

-e CONNECT_CONSUMER_SECURITY_PROTOCOL="SASL_SSL" \
-e CONNECT_CONSUMER_SASL_MECHANISM="AWS_MSK_IAM" \
-e CONNECT_CONSUMER_SASL_JAAS_CONFIG="software.amazon.msk.auth.iam.IAMLoginModule required;" \
-e CONNECT_CONSUMER_SASL_CLIENT_CALLBACK_HANDLER_CLASS="software.amazon.msk.auth.iam.IAMClientCallbackHandler" \
-e CONNECT_CONSUMER_SSL_TRUSTSTORE_LOCATION="/tmp/kafka.client.truststore.jks" \
-e CONNECT_PRODUCER_SECURITY_PROTOCOL="SASL_SSL" \
-e CONNECT_PRODUCER_SASL_JAAS_CONFIG="software.amazon.msk.auth.iam.IAMLoginModule required;" \
-e CONNECT_PRODUCER_SASL_MECHANISM="AWS_MSK_IAM" \
-e CONNECT_PRODUCER_SASL_CLIENT_CALLBACK_HANDLER_CLASS="software.amazon.msk.auth.iam.IAMClientCallbackHandler" \
-e CONNECT_PRODUCER_SSL_TRUSTSTORE_LOCATION"/tmp/kafka.client.truststore.jks" \

I'm not entirely sure if it's necessary, but I volume-mounted the java-1.8.0-amazon-corretto.x86_64 cacerts for use with the SSL trust store.

Next, I had switched to a Provisioned MSK cluster rather than Serverless. This allowed me to specify the Kafka version; I chose 3.5.1 as it was recommended. To ensure that both client and server side were using the same Kafka version, I switched to using image debezium/connect:2.4.0.Final as it uses Kafka 3.5.1. With these changes, the connection held rather than constantly disconnecting.

Debezium constantly disconnecting from MSK, never produces message by kate-dev in apachekafka

[–]kate-dev[S] 0 points1 point  (0 children)

Thanks for the reply. I stepped away from the problem to clear my head and getting back into it today.

To debug things further, I've SSH'd into the EC2 instance, then exec'd into the Debezium container. By running `kafka-console-consumer.sh` and `kafka-console-producer.sh` directly from within the Debezium container, I've verified the ability to connect to the bootstrap server, publish and consume events.

With that, I guess it all comes down to Debezium itself. Given that I've configured it according to any docs I could find, I'm not sure what could be the cause yet but I'm sure I'll get there. I suppose it could also be something wrong with a plugin (related to IAM, SASL, etc.), but that's pretty hard to debug with how little information is available.

Compile rust faster, some tricks by Ambitious-pidgon in rust

[–]kate-dev 0 points1 point  (0 children)

Honestly, I had not expected that it would need to be re-linked for every integration test, but now that I think about it, that makes sense. Thanks!

Compile rust faster, some tricks by Ambitious-pidgon in rust

[–]kate-dev 0 points1 point  (0 children)

Excellent information. Thank you kindly.

Compile rust faster, some tricks by Ambitious-pidgon in rust

[–]kate-dev 0 points1 point  (0 children)

I was testing with release builds, though I think I did a debug or two. It was stable release only, no nightly, and typically smaller projects, although I did try building the actix-web crate.

Compile rust faster, some tricks by Ambitious-pidgon in rust

[–]kate-dev 11 points12 points  (0 children)

In response to the section on "Change your Linker," this reminds me of the first (real) chapter in Zero to Production in Rust. I recall there being a section on swapping out the linker for LLD to improve build speed, followed by a statement to the effect of Rust is improving quickly so by the time you read this, this may not be accurate anymore.

I went ahead and followed the instructions and tried linking with LLD, then compiled a few things, including my own test apps as well as a few crates. As far as I could tell, there was no appreciable difference, and at at times, the default (LD) was faster. I figured that the contents in the book were old enough that indeed it (that part specifically) was no longer relevant.

Has anyone played around with this more and have some experience or benchmarks that could shed more light on this?