mbel

Or we’re just getting used to it.

Unless your code targets some exotic architecture, like idk x86.

Yeah, totally, just one more year.

Nobody would say „trujący wąż” (poisonous snake) or „jadowity grzyb” (venomous mushroom). The distinction is similar to English. There are exceptions and contexts where it can be used interchangeably but arguably the same is true for English.

Not really, we have both „jad” (venom) and „trucizna” (poison).

The primary use case that I can see is following: you use your second phone — the communicator — to chat, while watching endless stream of tiktoks/reels/shorts on the first one.

> In terms of CPU? The other way around.

That depends on your architecture and access pattern. In case of sequential access, packed bools may perform better due to arithmetic being usually way cheaper than memory operations.

> It’s less simple than many systems languages because it has a very strong type system.

I don’t think that’s the case, somehow most ML derived languages ended up with stronger type system and cleaner syntax.

In this case there is both time a distance limit to the gesture. If the gesture is too fast the switcher won’t appear even if the distance was long enough.

That said, personally I’ve always found the gesture navigation very intuitive.

It feels like a stretch to call this a parser. It’s looks like a typical lexer?

Probably the compilation time is better than it would be with LLVM. On the other hand I doubt that codegen and therefore performance is on par with LLVM.

Definitely a weird thing to advertise.

This is mostly an issue with MSVC which refuses to become compliant with c99 standard. Their support for c11 and c17 also has some gaps around features that were introduced in c99.

Most popular languages would prevent this. In this case it’s as simple as having more sensible reader API than sscanf in standard library and forcing variables to be initialized.

To be honest the implementation looks surprisingly readable… at least compared to other horrors like the standard library implementation.

While there are some new rules regarding arguments naming, the new syntax doesn’t feel more complex than the default lambda syntax.

So all in all I would say the most horrifying thing here is the fact that the language allows such extensions in the first place ;)

It's explained under the first link from the article [0]:

"A new type of interpreter has been added to CPython. It uses tail calls between small C functions that implement individual Python opcodes, rather than one large C case statement."

[0] https://docs.python.org/3.14/whatsnew/3.14.html#whatsnew314-...

Yup, they most likely do. After all everything is LLVM based nowadays.

It seems to work similarly as in C, i.e. you call malloc manually, there is some form of automatic size deduction though:

https://github.com/galileolajara/cp1/blob/main/examples/04-v...

For Intel you can just look into sources: https://github.com/intel/intel-graphics-compiler ;) Also AMDGPU and NVPTX targets in LLVM might be interesting.

Standard word which implies some level of analysis into causes of the incident. This brief note doesn’t live up to industry practice either.

It's not. 0x8000 is the smallest (-32,768) integer that can be represented with 16-bits and two's complement.

I see, thanks for clarification! I glanced though their website and expected a standard set of features including IMAP.

It’s an email service, the app isn’t really needed.

Here's an attempt at doing that: https://dreamfusionpaper.github.io/

Using intrinsics is much more sensible option than dropping to inline asm. Each CPU with SIMD or any kind of specialised instructions provides an intrinsics library for C.

Interesting that CSV is supported but XML is missing. Is it finally dead?

There is, it’s called „dialekt małopolski” ;)

Cathedral 3-D (https://store.steampowered.com/app/1091590/Cathedral_3D/). It's a retro-ish FPS, basically an arena shooter where you have to survive incoming waves of enemies.

It's using my custom game engine, that was developed from scratch in C, the only dependencies are SDL2 and OpenGL. The engine and game were developed for the last 6 or so years (with breaks) in the evenings/weekends as my evergreen side project. The game was released last Halloween. I still support the game with patches after the release (both new features and fixes), one of them is expected to come out very soon. And to be honest I plan to do so in coming years. I was fun to develop and still is.

The first one obviously.

While it's true that there are some artifacts, I think that they can be mitigated with some tricks like: avoiding sudden head movements by the actor or artificially decreasing the quality of the video. Low quality photos of big foot entertained people for years.

I generally agree though that with time we will learn to see red flags like this and treat video as probably fake.

With deep fakes easily available I believe the pornographic video material ultimately will have the same weight as a rumor, it's somewhat true for photos today. We definitely need a common way to propagate trusted information, but keeping videos as absolutely trustworthy is not possible anymore.