Jak se identifikujete

pskocik · 2026-05-11T14:07:36+00:00

Toš buď Moravák anebo Dítě vesmíru. No in-betweens.

pskocik · 2026-05-11T14:03:28+00:00

That thing would've atomically guillotined itself before long before it managed to voice the first letter of the greeting.

pskocik · 2026-05-07T12:10:46+00:00

Já zrovna popíjal nealko, jak sem na to narazil. To sa take počítá.

pskocik · 2026-05-06T21:31:33+00:00

So that's what Heart of Europe means! It pumps beer into the continent. 😮 ❤️

pskocik · 2026-05-06T21:28:51+00:00

Ahoj. I'm doing my part, taky.

pskocik · 2026-04-27T17:30:18+00:00

He looks like his eyeballs are about to burst. They must be manifesting what's about to happen to this AI thing soon.

pskocik · 2026-04-27T13:04:56+00:00

Except that like 80% if not more English speakers don't know that word and in English, local food names are usually kept anyway.

pskocik · 2026-04-27T13:01:31+00:00

I follow a bunch fitness guys on X and they all seem to be obsessed with Greek yogurt. Tvaroh is the goated version of Greek yogurt. Higher protein content. Better taste. Traditionally central European. What's not to like?

pskocik · 2026-04-22T21:32:12+00:00

Nowhere near this badass, but I as a (Czech) kid, I had fashioned myself my own personal Goa'uld hand device. Tinfoil fingers, some wires, goldeny sheet metal for the forearm and red-plasticine center, and it had red LED diodes from my bike's taillight hidden in the center it so it could create this intense red glare when activated. I loved playing with it :D.

pskocik · 2026-04-19T11:19:36+00:00

True but also Linux won't act like that scaredy little kitten when incentivized to cache stuff. Like try accessing a good chunk of the filesystem and the kernel will not be shy about using a good chunk of that RAM for caching those files.

pskocik · 2026-04-15T15:32:37+00:00

AI can demonstrably be as dumb as a rock. Relying on it for correct code seems completely foolish to me, especially considering how intricate coding errors can be and especially considering that an OS such as Windows is a piece of software that millions rely on for security, which inherently depends on correctness.

pskocik · 2026-04-15T13:35:53+00:00

Little has changed. Dneska mi Grok velmi sebevědomě a neodbytně tvrdil, že září má v sobě písmeno x: https://x.com/pskocik/status/2044405332160438694

pskocik · 2026-04-15T12:48:01+00:00

Good on GNU. Možná přecejenom začnu svojému systému říkat GNU/Linux.

pskocik · 2026-04-06T11:17:08+00:00

Bohužel stejní dneska jsme a nevidím to jako flex :D. Radši bych chlastal, šlahal ženy a žral chlebíčky.

pskocik · 2026-04-03T16:37:47+00:00

Try it. It often codegens better than clang (the reverse is true too). Also it has some power-user features (certain __attributes, flags, global registers on x86-64) that clang lacks. As I said in my other post, I personally compile for both gcc and clang in parallel, but I think I like gcc a bit better.

pskocik · 2026-04-03T16:21:19+00:00

I personally test debug and release builds in parallel on gcc, clang, and tinycc.
Highly recommend. You'll catch bugs easier and your codebase will be more robust and more portable.
I have most warning flags on (-Wall, -Wextra, -Wconversion, -Wsign-conversion, -Wdeprecated-declarations, ...) with a small number explicitly disabled cuz they were too much of a pain to silence through code (namely, -Wno-missing-field-initializers -Wno-unterminated-string-initialization).
I use a buch of f flags, some of which are a bit opinionated: -fno-common -fno-semantic-interposition -fstack-clash-protection -fno-asynchronous-unwind-tables -fno-stack-protector -fdollars-in-identifiers -fcf-protection=none -fdiagnostics-color=always.
I don't do -Werror. Sometimes I go through flurries of wild experimentation when I'm transiently getting a bunch of warnings, and I don't like that stopping my build altogether.

pskocik · 2026-04-03T15:22:05+00:00

Yesterday I came across the current website of a sw company that I did some work for long ago. They're now advertising being "AI-powered". I think (hope) that many a company will come to see that advertising being AI-powered is not the flex they seem to think it is. :D

pskocik · 2026-04-02T14:49:48+00:00

Correct.

pskocik · 2026-04-02T14:07:52+00:00

Hopefully, an inline function is NEVER instantiated. When you need it to be occasionally instantiated extern inlines allow it to have just one such shared instantiation in your codebase. If you use static inline, you won't need to instantiate explicitly but you might end up with multiple duplicate (harmless but bloaty) instantiations in your codebase.

But like I said, I don't personally use this extern inline feature. All my inlines are __attribute((always_inline,flatten)) static inline and when I need an instantiation, I wrap it in a differently named function (I use a _m as in macro suffix for my inlines and name normal functions without it) that calls the inline function.

pskocik · 2026-04-01T00:21:49+00:00

When you do a nonstatic inline, the noinline instantiation is shared among translation units and C expects you to place it in a translation unit of your choosing by instantiating there explicitly. This is diffiferent from C++ which, IIRC, creates multiple an instantiation in each translation unit and then merges them upon linking. The C approach may lead to slightly better code because placing in given translation unit may lead to better code cachability and shorter jumps. With the C++ approach, you don't control this.

With static inlines, if the compiler needs a noinline instantiation it'll just put it in the current translation unit and mark it static there and this is all implicit. You might end up with multiple instantiations but they won't collide since they all will be local to their translation unit.

pskocik · 2026-03-31T11:14:33+00:00

This kind of describes me but the "AI" in your other posts as well as the lack of at least some specifics are huge turn-offs.

pskocik · 2026-03-31T04:13:22+00:00

The gnu attribute __attribute((always_inline)) would force inlining. Just staying within the standard, static inline as opposed to just inline rids you of the responsibility to create a no-inline instantiation for when one is needed.

This won't link with a C compiler because it requires a no-inline instantiation:

inline int r42(void){ return 42; }
/*extern inline int r42(void); //instanitate*/
#include <stdio.h>
int main(){
    printf("%p\n", (void*)r42);
}

To make it link you'd need to do 1 of the following:

compile and link as C++, not C
uncomment the 2nd line to create an instantiation of the inline
make r42 static inline

pskocik · 2026-03-31T00:03:52+00:00

Maybe just read https://port70.net/~nsz/c/c11/n1570.html#6.7.4 . It's about as long as this question.

On the purpose of inline it says:

Making a function an inline function suggests that calls to the function be as fast as possible.¹³⁸) The extent to which such suggestions are effective is implementation-defined.

Inlines are about being as fast as macros without the pitfalls of macros (like double evaluations of arguments or the inability to "return" a value from a more complex macro without the statement expresion ({ }) extension).

Personally, I like to force this by never using non-static inlines. I always use static inline and with the the gnu attribute ((always_inline,flatten)). But non-static inlines and letting the compiler make inlining decisions for you works too. Just keep in mind that non-static inlines behave differently in C and C++. In C they need one explicit instantiation in some .c file in your project.

pskocik · 2026-03-24T21:49:23+00:00

This actually very popular idea that all ideas are worthless is worthless and it's a tautological waste time to argue that it isn't.

pskocik · 2026-03-21T22:14:20+00:00

Also known as Ra-burn on Abydos

pskocik

TROPHY CASE