Development discussion. Logged to https://ddnet.tw/irclogs/ Connected with DDNet's IRC channel, Matrix room and GitHub repositories — IRC: #ddnet on Quakenet | Matrix: #ddnet-developer:matrix.org GitHub: https://github.com/ddnet
Between 2022-09-21 00:00:00Z and 2022-09-22 00:00:00Z
Yes. There is one lock guarding everything that is cross thread inside CHttpRunner. Multiple unique_locks to make sure things get unlocked properly on unexpected early exits from blocks
I hope people didn't "rekt" him about things that are runtime constrained, calling an internal function with impossible values isn't fair criticism as long as he never calls them like such
The language this guy uses doesn't remove the possibility of memory management errors, ofc he had to fix mistakes. Don't rust users make any mistakes on classes of mistakes possible in their language?
I don't quite get how a fixed mistake is an own. Sorry
15:00
Doesnt mean I don't understand the value of Rust's memory guarantees. I just don't get how one person making and catching a mistake they made has anything wrong with it
It actually isn't that simple and that's why you use Rust instead of languages with much stricter guarantees
15:04
Ada has guarantees about deadlocks not existing, bounds checking, contracts, at the cost of performance. Haskell is provable at the cost of ergonomics.
15:04
These are general purpose languages. There are DSLs with even stricter guarantees that only allow you to do a very specific subset of things
15:05
Rust is just a great compromise. It trades off some ergonomics for memory safety
15:07
I honestly don't get these religious wars about programming languages. Most all of them have a place
No I personally don't care. You can joke all you want. But a lot of the people that have been trying to sell me rust in the past have actually went that route
Anyway, the place of C in the current era is the universal interface. Since no one is going t get together to make a proper ffi, it'll just stay like that for a decade or two
The complexities of modern languages don't deal well with how simple the underlying hardware is. It sends around bytes, it doesn't understand what a std::HashMap is
I mean I've had a better time exposing rust functionality through the ffi and consuming it through the ffi then trying to link together a rust binary and a rust library
15:15
Specifically when one was compiled with a different version of rust. There are some breaking changes you need to keep track of to do it properly
15:16
Even more specifically I was working on a plugin system of sorts
macOS (and iOS) has a concept of universal binaries which contain code for multiple CPU architectures in the same file. Apple is migrating from x86_64 to aarch64 CPUs, so for the next few years it ...
if you'd allow me to do that, I'd be very interested
17:17
another bug I'm currently facing:
17:18
the https register connects via IPv6 (or at least re-uses IPv6 connections wherever they came from) even though it explicitly requests CURL_IPRESOLVE_IPV4
17:18
I stepped through it in the debugger to see that it really sets CURL_IPRESOLVE_IPV4
17:19
and I quickly looked at the documentation, it seems to indicate that CURL_IPRESOLVE_IPV4 will only attempt IPv4 connections. comments in the curl source code suggest, that this also applies for reusing connections
In some situations, it was possible that a transfer was setup to
use an specific IP version, but due do DNS caching or connection
reuse, it ended up using a different IP version from requested.
Th...
macOS (and iOS) has a concept of universal binaries which contain code for multiple CPU architectures in the same file. Apple is migrating from x86_64 to aarch64 CPUs, so for the next few years it ...
19:40
for me it looks more like a nice to have than a actual blocker
This works around, i.e. fixes #5858 for curl versions < 7.77.0, as long
as the servers are only registered via IPv4 OR IPv6.
The bug that's being worked around is this:
https://github.com/curl/curl/commit/84d2839740ca78041ac7419d9aaeac55c1e1c729.
The bug makes curl reuse IPv6 connections when it is being requested to
connect via IPv4, making the registering fail. This commit works around
that by letting the server only register after having completely read
the config, so any `s...
Since netobjects are easier to extend now, and since EntityEx still has its issues/limitations, it can perhaps be considered to move the info from entityex (i.e. switch number) to DDNetLaser, DDNetProjectile, and so on.
Some thoughts/proposals:
Adding the switch number to DDNetLaser. It would also be nice to distinguish both between all the laser types (this is already added in ddnetlaser, but only for the door type), and to add a "SubType" field to further distinguish for example types...
4f2f3f4 Only start registering once the server is fully started - heinrich5991
884cf75 Stop server if started with old curl and incompatible sv_register - heinrich5991
f7c7852 Merge #5859 - bors[bot]