michaelni changed the topic of #ffmpeg-devel to: Welcome to the FFmpeg development channel | Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg | This channel is publicly logged | FFmpeg 6.1.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
vtorri has quit [Ping timeout: 268 seconds]
<cone-611>
ffmpeg Haixia Shi master:e664f4465ab0: doc/utils: fix atan2 parameter order
rvalue has quit [Ping timeout: 268 seconds]
vtorri has joined #ffmpeg-devel
rvalue has joined #ffmpeg-devel
<cone-611>
ffmpeg aybe aybe master:36b402f80d0a: avcodec/mdec: DC reading for STRv1 is like STRv2
<cone-611>
ffmpeg Michael Niedermayer master:278fea3664f3: avutil/eval: Use even better PRNG
<elenril>
C11 is the final version of C as the spaghetti monster intended
<courmisch>
C11 does not have checked arithmetic, so obviously not
<elenril>
does it have more users than c11 threads?
<courmisch>
are you for real? have you tracked how many times FFmpeg has open-coded checked arithmetic?
<jamrial>
atomics
<courmisch>
atomics are in C11 though. Does C23 add notify/wait?
<courmisch>
looks like it does not
<courmisch>
but <stdckdint.h> would be massively useful in FFmpeg
<elenril>
send patches?
<elenril>
or does your religion forbid you from working on anything besides risc-5
<courmisch>
I can't be bothered to write stdckdint.h for the ancient compilers that FFmpeg supports
kekePower has quit [Read error: Connection reset by peer]
<elenril>
I've been pondering about requiring c11 for building
<jamrial>
we could bump minimum compiler req to c11
Krowl has quit [Read error: Connection reset by peer]
<courmisch>
and I am not looking to divert my attention from life, unlike you
<elenril>
the only blocker was msvc IIRC
<jamrial>
no one using old compilers should bother with ffmpeg > 6.1, really
<elenril>
courmisch: my point was that I'd like LESS stuff on my plate, not more
<courmisch>
I agree but I don't want to be fighting that argument on the mailing list
<jamrial>
afaik, msvc 2019 added c11 save atomics, and msvc 2022 added atomics
<elenril>
and nobody should be using msvc anyway
<elenril>
a separate question is whether we start using c11 features in public headers
<elenril>
anonymous unions would be nice
kekePower has joined #ffmpeg-devel
<courmisch>
don't they break C++ interop?
<jamrial>
building the libraries for windows applications is probably easier with msvc than mingw
<jamrial>
elenril: yes, we could do that. old gcc (pre c11) is why we don't
<elenril>
courmisch: do they?
<courmisch>
elenril: don't they?
<elenril>
I have no idea about c++
<elenril>
that way lies madness
<courmisch>
do I look like I do? I'm offended
<courmisch>
I only acknowledge C and Rust as worthy of me
<elenril>
eew, rust
frankplow has quit [Quit: Goodbye]
<kierank>
I wish there were new programming languages without cults attached
<elenril>
yeah...
kekePower has quit [Read error: Connection reset by peer]
<elenril>
i had such hopes for rust
<kierank>
and also de facto forced package managers
<elenril>
and zig maybe, but it also suffers from ^
kekePower has joined #ffmpeg-devel
<courmisch>
nobody would adopt a new language that did not have a package manager, so that's contradictory
<elenril>
my distro already has a package manager
<elenril>
and adoption is overrated anyway
<courmisch>
not for source dependencies
<Lynne>
no new language wants to standardize its ABI
<elenril>
cowards
<kierank>
courmisch: sure, but it's a de facto forced package manager
<courmisch>
C is the defacto lingua franca. No point even trying to stnadardise an ABI
<kierank>
lol speaking too much to dav1d developers
<kierank>
ABIs are for wimps
<Lynne>
C has an actual standardized ABI, since 2004 IIRC, before that it was more of a de-facto standard
<courmisch>
except you need one actual ABI per ISA
<courmisch>
and since ISA only standardise their C ABI, that's that
<Lynne>
ISAs don't standardize their ABIs?
<courmisch>
kierank: you don't have to configure cargo to automatically fetch stuff if you don't want to
<courmisch>
Lynne: they do but only for C
<Lynne>
they don't, x86 has like 5 ABIs
<courmisch>
but it has 0 Rust ABIs
<Lynne>
arm64 is mostly standard across all arches, except for x17, which is reserved on most with varying degrees
<courmisch>
what would even be the point in standardising a Rust ABI, if it can only be used from Rust
dellas has joined #ffmpeg-devel
<courmisch>
PR is x18
<Lynne>
a standardized rust ABI would make packaging rust in binary package managers actually possible
patricia_ has joined #ffmpeg-devel
<courmisch>
no it wouldn't, since Rust uses LTO *always*
<elenril>
generics were a mistake
<courmisch>
also making defining an ABI for type-generic stuff is insane. That was a huge mistake in C++.
<courmisch>
Rust defines a subset that is ABI-safe, but that's pretty much a mapping of the C ABI
patricia_ has quit [Client Quit]
<Lynne>
lto doesn't prevent ABI stability for an external ABI, but that's something that can be standardized into the spec
<elenril>
isn't LTO a meme anyway?
vtorri has joined #ffmpeg-devel
kekePower has quit [Read error: Connection reset by peer]
<courmisch>
elenril: for Rust, it's really not. Type specialisation and constant propagation are obvious uses
kekePower has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<courmisch>
Lynne: yes but you *can* easily definite external ABI-safe symbols in Rust (if you want to make a dynamic library for instance). I don't see the problem here
<courmisch>
define*
<courmisch>
elenril: also the LTO guarantee is how you get rid of header files
<elenril>
courmisch: I've never heard of LTO being clearly useful for anything
<elenril>
especially given how many new issues it adds
<courmisch>
it does not add issues if the language was always meant to work with it
<courmisch>
and again, at the very least, it avoids the big mess known as header files
<elenril>
I love header files and wish more languages had them
<elenril>
people who think otherwise are objectively wrong
kekePower has quit [Read error: Connection reset by peer]
<courmisch>
stockholm syndrome
<courmisch>
Rust has native support for public, hidden and private, and proper namespacing. You don't need header file tricks
<elenril>
separating interface from implementation is a good thing and you won't convince me otherwise
<elenril>
you could do it better than C does, sure, but few languages try
kekePower has joined #ffmpeg-devel
<courmisch>
I mean Rust does it without needing error-prone headers
<elenril>
with rust you need the entire source of all your dependencies at build-time, no?
<courmisch>
ultimately header files exist only because back in Ye Ol' days, C compilers couldn't handle more than one module at a time
<courmisch>
elenril: you need the Rust static import libraries (rlib). Though needing the sources wouldn't be so bad for OSS conformance IMO
<courmisch>
Java was able to do away with headers without needing sources already in the 90s. it's not exactly rocket science (and this hilights my point that it's pure 60-80s legacy in C)
<elenril>
it's distasteful
<courmisch>
you sound like a grumpy old bigot. I too had my reservations about the language before I learnt it, but while not perfect, it's actually pretty damn good for C programmers
<courmisch>
unlike C++, it's not trying to be everything, just a modern system level programming language
<elenril>
I could take that as CoC violation, but I'll take it as a compliment instead
<elenril>
kids these days should get off my lawn
<courmisch>
AFAIK, I have longer experience with C than you do, lol
<elenril>
which is why you calling me an old bigot is such high praise
<courmisch>
but hey, keep all the C everywhere. Since youngsters don't learn it, that's better job security for me
<courmisch>
I mean your objections are pretty lame. You could have used actual arguments like how much slower it is to compile or how it does not have a proper spec
<courmisch>
or prosaically that is not as well known as C and takes time to learn[3~
<elenril>
oh, I didn't realize I was supposed to present a full polemic against rust
<elenril>
sadly I have neither the time nor the willpower for it atm
<elenril>
(nor do I see much point in it)
ngaullier has quit [Quit: Leaving.]
j45 has joined #ffmpeg-devel
j45 has joined #ffmpeg-devel
j45 has quit [Changing host]
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 264 seconds]
<j-b>
good morning
j45_ is now known as j45
j45 has joined #ffmpeg-devel
j45 has quit [Changing host]
* another|
puts coffee on the table
<courmisch>
it's 6 hours too late for coffee
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 264 seconds]
<gnafu>
another|: Hey, stop making a mess! Next time, put the coffee in a mug or a pot or something.
<another|>
heh. oops
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
kekePower7 has joined #ffmpeg-devel
kekePower has quit [Ping timeout: 245 seconds]
kekePower has joined #ffmpeg-devel
<elenril>
snorting coffee straight from the table is what the cool kids do
<elenril>
say no to cocaine
kekePower7 has quit [Read error: Connection reset by peer]
vtorri has quit [Ping timeout: 245 seconds]
kekePower has quit [Read error: Connection reset by peer]
dellas has quit [Remote host closed the connection]
kekePower has joined #ffmpeg-devel
vtorri has joined #ffmpeg-devel
kekePower4 has joined #ffmpeg-devel
kekePower has quit [Ping timeout: 245 seconds]
kekePower has joined #ffmpeg-devel
kekePower4 has quit [Ping timeout: 245 seconds]
kekePower has quit [Quit: Ping timeout (120 seconds)]
kekePower has joined #ffmpeg-devel
j45 has left #ffmpeg-devel [Leaving.]
MisterMinister has joined #ffmpeg-devel
ccawley2011 has quit [Read error: Connection reset by peer]
kurosu has quit [Quit: Connection closed for inactivity]