Joke’s on you, the docs don’t exist or are so outdated that they don’t even compile
That’s vibe coding.
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.
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
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.
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
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.
I find myself saying this about 35 times a day, at nearly every turn, with about everything I interact with.
deleted by creator
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
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.
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.
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.
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=bor is itflipflop -throw 10 -f -b? The docs show both work for setting the force to 10 and target to buttocks
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.
Tbf, often there either is no proper one, or you don’t know where to find it. Or there is just tons to unpack, because one thing leads to another and suddenly you have to read like 10.
To give you an example: I just wanted to create a new btrfs software RAID and dissolve my old one, but without loosing the data or redundancy in the process. To do so, I had to create a new partition table, of course not before using tools to find the right device, add a LUKS2 partition, find its UUID, unlock that partition, add a btrfs partition, mount that partition, copy all data over, then generate a keyfile for auto-unlock, add that to the LUKS, add the according crypttab line, remove a drive from the former raid, not before running a balance of course, then also create LUKS on that, find the UUID again, open that as well, add the keyfile again, add another crypttab line, adding the mapper to the btrfs partition, running a balance that creates a RAID 10, adding an fstab entry for auto-mount, runnning dracut and set up btrfs maintenance.
Even just describing the process is a chore. Imagine trying to learn every stept, one by one, from the manuals.
Edit: Some fixes and steps I skipped added. In case anyone is wondering what the heck I’m doing: I am moving from a RAID 1 with 2 disks to an encrypted RAID 10 with eventually 4
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
