namark @namark@qoto.org

old code new question: can you spot the undefined behaviour? omg! and how can I ever recover from this?

#cpp

false dichotomy - rejected half the time

false equivalence relation - rejected once per the number of equivalence classes

false total order - accepted most of the time

unnecessary indirection,
unnecessary allocation,
unnecessary bound checks,
runtime type information,
overuse of abstractions,
global state in libraries,
long names.
repeated half-assed reference counting,
repeated half-assed implementations of common data structures/algorithms,
tons of fragile platform specific code.

#programming

Alternatively you can avoid changing the iterator concept by changing the algorithms, leaning onto the elementwise logical negation operator ~.

For this to make sense you have to introduce a new type: an array of bools with an associated reduction operation - conjunction or disjunction, that would represent the equality comparison in each dimension and contextually convert to a boolean, by performing the reduction. The == operator will return such an array with conjunciton, since that's what makes more sense for the tuple in general. Now the logical ! in order to also remain sensible will need to negate the elements of the array AND change the conjunction to a disjunciton, adhering to De Morgan's law. The elementwise ~ however has no such obligations of logical consistency (it's wavy, it's chaotic, it's insaneee) and can happily just negate the elements leaving the reduction operation untouched. This coincidentally is both exactly what we need for loop conditions and exactly what we always had when working with integer types as bit vectors (so hopefully it shouldn't be that alien of a syntax). What I'm getting at is that the range based for loop and algorithms should use ~(first == last) instead of (first != last) as a loop condition. Unfortunately the (fisrt == last) for early returns and such, will turn into ~(first != last) with this approach... that's double negation... disgusting... and I forgot the #cpp in OP -_-

stumbled upon another type of multi-dimensional iterator that you just can't have in STL in it's current form :
https://github.com/ClaasBontus/miterator

Goal: Iterate over multiple containers in tandem.
Solution: Iterator tuple wrapper that applies all relevant operations to it's elements.
Problem: the range based for loop, the algorithms library, and the whole concept of iterators relies on equality comparison. The loops increment the first(begin) iterator while it's not equal to last(end) iterator, some algorithms exit early if first == last, etc. In this case we want the iteration to stop when one of the ranges is exhausted, therefore the inequality of the tuple must be implemented as a conjunction of element-wise inequality comparisons, that is the tuples will be unequal only if all their corresponding elements are all individually unequal. The tragedy is that this makes absolutely no sense in any other context and is a bonkers way to implement inequality for a tuple (or any other vector/collection type), since any two tuples that have only one element in common will be considered equal. Alas this is what you have to do to satisfy the standard library. The only solution to this would be to change the iterator concept to use a different function (maybe called std::reaches(first, last)), that will just default to equality comparison unless specialized for a given type. The use of equality comparison is already conceptually dubious for ranges that use sentinel end iterators (like input streams, lazy generators, or when you want to do less than because some overflow is allowed and expected), but when you try to up the dimensions even in the trivial cases it just completely breaks apart.

string? what does that even mean? why is it not called a char_array or something? and then null terminated string? You mean random_access_char_stream? Who came up with this nonsense? and everyone is gobbling it up!

#programming

don't put maple syrup on things

xfce: you can setup as many panels as you want!
also xfce: https://forums.linuxmint.com/viewtopic.php?t=296092

fresh windows: *constantly crashing cause cause no chipset driver*
also fresh windows: *can't install chipset driver cause constantly crashing*

unity game: *installed in games folder*
Games folder: *exists*
unity game: *can't find data files in Games folder, won't start*
me: *removes Games folder*
unity game: *starts*

how do you even manage to do that? Are you capitalizing every path component? Are you case insensitive searching for em? spectacular...

how do you even make a puzzle game...
https://f-droid.org/en/packages/com.bytehamster.flowitgame/

#actually_good_fosg

what do you call an operation that is inequality(!=), addition(+) and substraction(-) all in one?

who are these clowns coming up with prepositional logic courses that downplay xor and never even mention zhegalkin?

https://gist.github.com/nevack/6b36b82d715dc025163d9e9124840a07

ok, cool thread, but the dongle works on Linux trisquel 4.15.0-142-generic just fine without any such workarounds and doesn't work on anything past 5.4 with or without these such workarounds...

wow these bozos were quick to cash in on MY IDEA
https://battlebeavercustoms.com/products/ps4-d-buttons

who would by that though, are PS4 dpads made of adamantium or something?

joke's on me, spend the whole day to find this troll of a bug
https://gitlab.com/xboxdrv/xboxdrv/-/issues/144

nevermind random crashes, constant misconfigurations and irreconcilable video driver issues, just sitting there for 60 seconds has gotta be the most infuriating bug ever... go ahead and figure out why nothing is working when everything is right... low priority, cause wait a minute... it still works

this actually worked, feels and plays better than any dpad I ever tried, and that's for any type of game, other than maybe some hypothetical no tolerance rhythm game where you'd need to develop muscle memory for quick and precise diagonals. The shape and the position of the buttons is really important, but them being a one piece is just defective design.

manjaro I have: drm + kernel can't figure out how to 2 monitors or who's fault it is

trisquel I want: "not an absolutely ancient gpu? nope!"

guix I want: failed to install itself with a cryptic lisp stack trace and borked my grub

xubuntu LTS I get - just works

my granma is on xubuntu and I'm on xubuntu cause xubuntu just works

fixed it

here is how you do it properly
https://yewtu.be/watch?v=zAT4YzVoAqU
you mount the buttons sideways, press them by pushing a lever around and get proper feedback when changing directions, especially from axial to diagonal. I'm pretty sure I had a tiny knob version of this on a flight stick, much smaller than most dpads.

Laying them flat is cheaper? Sure, but then stop gluing them together and pretending you made a stick.

what's the deal with dpads? It's like you wanted to make a crispy 8 directional joystick, but decided in advance that you are going to fail...

each logical component of a library should have:

smol brain: one file to represent it

big brain: one interface file and one implementation file to represent it

huge brain: one interface file, one type generic implementation file and one type specific implementation file to represent it

galaxy brain: one interface file, one type generic implementation file, one type specific inline implementation file, and one compilation unit file to rule them all, find them all, bring them all and in the darkness bind them all.

#cpp