And then you read the docs and it turns out to be something you already tried.
But now it works.
Like the USB superposition
🙂🙃🙂
It doesn’t work the first time but you copy paste from the docs example instead of typing the example and it works now
I’ve had times where I was going through my code and the docs code step by step to see where they logically differed and found that I was doing all the same things, but my code didn’t work and copy-pasting their code did. Make it make sense!
Let me count the ways it has been for me… Capitalization, using -, not using -, wrong quotes, mismatched quotes, no quotes, reading the command the same wrong way about five times and typing it that way. Well this could take forever to list them all.
I just copy paste first now. That way I learn none of the commands or syntax at all
I find myself saying this about 35 times a day, at nearly every turn, with about everything I interact with.
Been there, found undefined behavior where there should not be any. Imagine a function that takes a bool param with the following code, but neither branch gets executed:
if (b) doStuffForTrue(); if (!b) doStuffForFalse();
In a function that is passed an uninitialized bool parameter, in gcc compiler, both branches can get executed even when b is const. Reason: uninitialized bool in gcc can have values of a random integer, and while if(b) {} else ({} is guaranteed to execute only one branch, bool evaluations of a bool value take a “shortcut” that only has defined behavior with an initialized bool.
Same code with an uninitialized integer works as expected, btw.
Don’t blame this on gcc or the library/function author - it is 100% user (i.e. programmer) error. Uninitialised memory of any type is undefined behaviour in the C and C++ abstract machine. That means optimising compilers can assume it does not exist.
For example, the compiler could see that your ‘b’ is never initialised. Therefore, using it would be undefined behaviour. So, the optimiser can assume it is never used, and it is as if that code simply does not exist: the behaviour you saw.
I’m not saying that is what happened, nor that it will always happen, but it is a possibility.
Don’t blame this on gcc or the library/function author - it is 100% user (i.e. programmer) error. Uninitialised memory of any type is undefined behaviour in the C and C++ abstract machine. That means optimising compilers can assume it does not exist.
I absolutely do blame this on the C++ standard being not specific enough, specifically for the way in how I learned about this: When writing a trivial function, you would never expect that - for a bool parameter - an “if (b)” branch can be executed as well as an “if (!b)” branch.
So basically, this mechanic sabotages input data validation in functions that test whether plausible parameters were provided. The problem is that a function you write that is bug-free and “perfect code” - despite input data validation - can exhibit undefined behavior due to an uninitialized bool type parameter. Something that can not happen with other uninitialized trivial (numeric) data types (int, float). Simply due to the way boolean checks are translated to x86 assembly:
Here’s an example: https://godbolt.org/z/T3f9csohd
Note the assembly lines 176-182: The only difference for the “if (!b)” check is that the lowest bit of the boolean is flipped with an xor - which assumes about the implementation that a boolean can never hold values other than 0 or 1. Which I - as a naive user - also assumed until this happened. Correction: I assumed that negating a bool would result in the inverse boolean value.
So the problem boils down to: The value range of any given (built-in) numerical data type fully encloses the value range that an uninitialized variable of that type can have. This is not necessarily true for boolean: In g++, the value range is [0;1] and the range of an uninitialized bool is [0;255].
Accordingly, I would expect the C++ standard to fix this by stating that an uninitialized bool must have a value for which only one of two conditions evluates to true: b or !b, but not both.
Ohhh, so that’s why it’s called Docker!
As in “It works on my system” so they just copied and pasted the commands for you.
deleted by creator
Then you pick up the manual:
To use, start using. If you get an error, try again
Reconfabulate the tridepodictaphone by nabulizing the fromgulan with kreevus. If stufingus brawes, then hyfangle the natriuminutaur.
Basic 17th year psycoders can do this.
Joke’s on you, the docs don’t exist or are so outdated that they don’t even compile
Looking at you Microsoft.
The funniest thing to me is that any good manual would just say “DO NOT USE SOCKS AND FLIP FLOPS SIMULTANEOUSLY”
what if i want to embarrass my nieces and nephews
Finger-pulls and 'remember when…'s
What about tabi socks and setta?
I’m not sure there is a correct way to do this
That looks like an XY problem.
Finally, thanks I’ve been trying to remember the name of this for ages
Timtowtdi, doesn’t say there’s necessarily a correct one.
That’s vibe coding.
The documentation is usually dog shit.
The corporate culture does not allow appropriate time for the documentation as it is considered something that cost money without a quantifiable gain.
It permeates in the FOSS space as well since writing good documentation is a skill and it is not fostered in corporations. So devs start great projects with terrible documentation.
One way to contribute to FOSS is to improve bad documentation. You are correct, of course, and lazy devs write bad code if they do not cultivate good documentation - imho.
Then they don’t learn the skill for themselves lmao, can’t win
Does anyone know of any good resources on writing good documentation? It’s a thing I’m weirdly passionate about and absolutely want to get better at for my own sanity and for others as well if I can contribute.
But it seems like it’s a very under discussed subject…
Veronica Explains has a really good video talking about how much of a dead skill it is now from the standards it used to be.
WTF is going on in panel 2? Did they cut a hole in the sock?
Step 1: cut a hole in the sock
Step 2: put your sandal in that sock
Then you look back at your notes a couple years later and you’re like “I still don’t understand wtf I did it that way”.
It works, DON’T TOUCH IT.
that does look less painful than reading documentation
then documentation instructs it must be used for spanking
Man page me daddy.
Hold on… Is it
flipflop -throw -f=10 -t=b
or is itflipflop -throw 10 -f -b
? The docs show both work for setting the force to 10 and target to buttocks
It amazes me to see people do everything except 1) rtfm or 2) contact the support line that’s already paid for.
Edit: apparently my coworkers are in this thread.
The manual: poorly written; indecipherable
Support: reads the manual to you
As if the goddamn support knew their asses from their asserts.
“as viewed by the original dev who knows it inside and out”
I enjoy it more to figure out on my own. Kinda like disassembling stuff to see how it works and then put it back together. Reading the manual is like copying answers
Then the doc is so complicated that you spend hours reading stuff just to understand if the page is actually related or not. Then at some point you get bored try something randomly and it works.
The manual is probably outdated either way
Beat me to it.
What’s the meme for when the documentation is two years out of date?
Or when the documentation IS up to date… but the last 4 versions of the docs are still online and look exactly like the new version with no obvious sign of which version they are? (Looking at you, Microsoft)